EnglishУкраїнськаРocсийский
Вхід/Новий
01.02.2012 08:54 Давність: 7 yrs

Автор: Роман Савоченко

OpenSCADA у програмованому логічному контролері (ПЛК)

Ім'я: ПЛК

Засновано: жовтень 2008р

Версія: 1.0.0

Статус: GPL

Учасники: Роман Савоченко

Опис: Проект присвячено створенню: середовища виконання ПЛК, прошивки ПЛК та апаратних конфігурацій спеціалізованих PLC. Розглянуто вбудовані системи на основі архітектур x86 та ARM, а також окреме обладнання вбудованих рішень:

  • Diamond Systems: ATH400-128;
  • Kontron: MOPSlcdLX;
  • «A-TEX» Ltd: iROBO-Fanless;
  • ICP DAS: LP-8781;
  • ZAO ZEO: Тіон-Про270;
  • Segnetics: SMH2Gi.

Матеріали: ftp://ftp.oscada.org/OpenSCADA/PLC


Одноплатний PC/104 комп'ютер

Сучасні системи автоматизованого керування технологічними процесами (АСК ТП) є достатньо складними. Умовно ієрархію АСК ТП можна поділити на два рівня: нижній та верхній рівень. Нижній рівень АСК ТП містить польова обладнання (датчики та виконавчі механізми), а також програмовані логічні контролери (ПЛК). Верхній рівень представляє з себе систему оперативної візуалізації та контролю за технологічним процесом — SCADA-система. ПЛК становить відповідальну частину АСК ТП, яка виконує функцію збору даних польового обладнання, обчислення та видачу керувальних, блокувальних та інших дій на керувальні органи польового обладнання.

OpenSCADA є відкритою реалізацією SCADA-системи, яку засновано на модульній архітектурі, що дозволяє будувати кінцеві рішення під різноманітні вимоги. Цільовим призначення OpenSCADA є системи верхнього рівня, однак висока ступінь модульності, і як наслідки масштабованості, дозволяють вирішувати широке коло задач суміжних областей.

1. Промислові програмовані логічні контролери

Ринок ПЛК насичено широким спектром виробів різної архітектури та конструкції. Архітектурно ПЛК можна поділити на три умовні групи:

  • жорстко-програмовані ПЛК та модульні пристрої погодження з об'єктом (ППО);
  • високоінтелектуальні комерційні ПЛК;
  • PC-сумісні ПЛК.

Жорстко-програмовані ПЛК за звичай будуються на основі одно-кристальних мікроЕОМ або мікросхемах програмованої логіки. Програма таких контролерів або прошивається єдиноразово, надаючи можливість програмної параметризації, або ж формується спеціалізованими засобами, які наділено функціями компіляції бінарної прошивки середовища виконання з програмою користувача, наприклад ISaGRAF або LabView. У якості представника такого ПЛК можна у приклад привести модулі розподіленого ППО фірми Advantech.

Високоінтелектуальні комерційні ПЛК за звичай будуються на базі більш потужного обладнання з архітектурою, близькою до повноцінного PC-комп'ютеру. Основною відмінністю від стандартного PC-сумісного ПЛК є закрита програмна, а часто і апаратна архітектури. Програмне оточення таких контролерів за звичай базується на операційній системі реального часу, яка планує декілька потоків користувача з поділом їх за пріоритетом. Користувальницьке програмування таких ПЛК здійснюється роботою у фірмовому програмному оточенні, яке формує у якості результату бінарний код потоку ПЛК. У якості представника такого обладнання можна навести ПЛК серії S7 фірми Siemens.

PC-сумісні ПЛК - це група скоріше не ПЛК, прямо сумісних з PC, а ПЛК, які не містять інтегрованого середовища виконання і часто постачаються без операційної системи. Архітектура таких ПЛК може бути різною, починаючи від економічних рішень архітектури x86 та закінчуючи архітектурними рішеннями ARM та MIPS. Середовище виконання таких ПЛК за звичай формують з ПЗ того ж класу, що і у випадку з жорстко програмованими ПЛК у вигляді бінарного файлу для виконання під одну з розповсюджених, масштабованих або спеціалізованих ОС (DOS, QNX, Linux, WinCE, VxWorks). Часто зустрічаються і спеціалізовані під задачу рішення. У якості представників цього класу можна розглядати ПЛК формфактору PC/104.

Варіанти конструктивного виконання ПЛК можна умовно поділити на моно-блочні та модульні. Моно-блочні ПЛК надають фіксовану конфігурацію ППО, спеціалізовану під обмежене коло завдань. Модульні конструкції надають можливість легкого розширення конфігурації ППО під потрібне завдання. Існують також і гібридні конструкції, які представляють із себе моно-блок, спроможний розширювати своє ППО за рахунок зовнішніх блоків ППО, які підключаються по одному з стандартних інтерфейсів, наприклад, за RS-485.

2. OpenSCADA як середовище виконання ПЛК

Архітектура системи OpenSCADA дозволяє створювати кінцеві рішення під різні вимоги та ресурси шляхом модульного розширення. Ця можливість виявляється корисною у світлі обмеженості ресурсів ПЛК. Крім того, враховуючи постійний розвиток апаратного забезпечення, а також безперервне підвищення інтеграції та економічності сучасних мікропроцесорних рішень, OpenSCADA дозволяє послідовно розширювати функціональність ПЛК, зберігаючи наступність зі старими рішеннями. Наприклад, на основі системи OpenSCADA можна будувати рішення з мінімальними вимогами на рівні: CPU 100 МГц, пам'ять та флеш диск по 30 Мб.

Як було зазначено вище ресурси сучасних ПЛК можуть коливатися у достатньо великих межах, причому ПЛК фіксованого типу, побудовані на однокристальних мікроЕОМ, все далі відтискаються у вузько-спеціалізовані області розвиненими PC-архітектурами. Така тенденція робить все більш цікавою можливість створення уніфікованої відкритої платформи для реалізації середовища виконання ПЛК на основі уніфікованих PC-платформ.

OpenSCADA дозволяє реалізувати ідею створення відкритої платформи для реалізації середовища виконання ПЛК. Вже зараз можна реалізувати оточення ПЛК, яке небагато чим поступається комерційним інтелектуальним контролерам, а багато у чому і перевершує їх за рахунок можливості інтегрування функцій, характерних для SCADA систем, у оточення ПЛК, розширюючи функціональні та користувацькі характеристики ПЛК та приводячи його на єдину зі SCADA кодову базу, а також оптимізуючи вартість кінцевого рішення.

Перелічимо функції які вирішуються OpenSCADA у межах оточення ПЛК:

  • збір даних різного спектру обладнання у синхронному, асинхронному або блочному режимах;
  • користувальницькі процедури обробки даних та видача керуючих дії на Java-схожій мові високого рівня та на формальнім мові блочних схем;
  • архівація даних, починаючи від тимчасових буферів у пам'яті та закінчуючи повноцінними архівами на файловій системі або у БД різної дискретизації та глибини;
  • інтеграція у інфраструктуру АСК ТП шляхом реалізації стандартних протоколів взаємодії (ModBus, SNMP, OPC UA ...);
  • інтеграція з СКБД для експорту даних, збереження конфігурації або архівів;
  • вільна конфігурація та адміністрування мережі ПЛК як за посередництвом оперативного інтерфейсу станції адміністрування, так і за посередництвом Web-інтерфейсу;
  • можливість реалізації панелей оператора з інтерфейсом контролю та керування на вбудованій Touch-панелі;
  • надання Web-інтерфейсів оперативного та диспетчерського контролю.

3. Прошивка та створення програмного оточення ПЛК архітектури x86

Перед реалізацією прошивки ПЛК ставилися наступні вимоги:

  • Компактність. У зв'язку з прямою залежністю ціни на промислові флеш-диски від їх об'єму, а також реальною відсутністю потреби частого оновлення, образ прошивки потрібно упаковувати, досягнувши рівня компактності 8-50Мб на середовище виконання ПЛК у оточенні повноцінної ОС.
  • Уніфікований вихідний репозиторій. Оскільки прошивка не є чимось немодифікованим, не розширюваним та остаточно фіксованим, то у її основі має лежати реальний репозиторій пакетів ОС який розвивається. Це дозволить довгий час формувати обновлення та розширення, не підтримуючи при цьому опосередкованого репозиторію.
  • Відлагоджена та проста процедура збору. Враховуючи той факт, що конфігурація прошивки може деякий час стабілізуватися, крім того у компонентах ОС та OpenSCADA будуть знаходитися та усуватися помилки, то процедура збору прошивки не має бути обтяжливою, а напроти - легко адаптованою.
  • Прозора реалізація режиму запису до дерева ОС. Хоча прошивка і має на увазі створення упакованого немодифікованого образу прошивки, однак специфіка роботи середовища виконання ПЛК передбачає модифікацію БД та ведення архівів. Крім того, наявність можливості корекції вихідної конфігурації є важливою вимогою.
  • Надійність та стійкість до раптових вимикань. Специфікою експлуатації ПЛК є, як правило, відсутність можливості коректного виключення, а також практична реальність ситуацій миттевого та непередбачуваного пропадання живлення. ПЛК у таких випадках має зберігати працеспроможність, у сенсі того що містити журнальовану ФС та забезпечувати її перевірку та автоматичне усунення помилок.
  • Умовний поділ конфігурації ПЛК на два типа:
    • ПЛК без локального дисплею, можливо з простим текстовим табло.
    • Touch-панелі з функцією ПЛК.

3.1. Інструменти та збірка робочих оточень

Враховуючи вищенаведені вимоги, для створення прошивки було вибрано репозиторій пакетів дистрибутиву ОС Linux ALTLinux та інструмент створення дистрибутивів mkimage. mkimage - інструмент для збору штампів Sisyphus-based системи за шаблоном. У якості вихідного набору шаблонів було взято набір шаблонів формування дистрибутивів ALTLinux за адресою git://git.altlinux.org/people/boyarsh/packages/mkimage-profiles-desktop, командою:

git clone git://git.altlinux.org/people/boyarsh/packages/mkimage-profiles-desktop

За основу формування PLC шаблону було взято стандартний "rescue", як найбільш компактний та близький до цільової задачі ПЛК.

3.1.1. Результат

У результаті отримаємо прошивку розміром від 30 до 100Мб, яка задовольняє фактично всім заявленим вимогам та забезпечує:

  • Завантаження протягом 27 сек від включення контролера та включаючи ініціалізацію BIOS.
  • Перевірку та відновлення робочої файлової системи у файлі work.
  • Збереження даних користувача та змін прошивки у файлі work.
  • Автоматичне налаштування мережі за посередництвом DHCP (або 192.168.0.1).
  • Доступ до контролеру за посередництвом SSH та зручний інтерфейс роботи, включаючи mc. Паролі по замовченню (root:123456; admin:123456).
  • Синхронізацію часу за посередництвом ntp.
  • Виконання OpenSCADA з наявними мережевими інтерфейсами:
    • конфігурація через Web (порти: 10002 та 10004);
    • середовище виконання через Web (порти: 10002 та 10004);
    • інтерфейс керування OpenSCADA (порт 10005).

3.1.2. OpenSCADA

У якості середовища виконання ПЛК використано систему OpenSCADA. Для цього випадку візьмемо збірку з окремими пакетами на кожний модуль та вкажемо для встановлення віртуальний пакет openscada-plc, який містить залежності на всі пакети OpenSCADA, які за звичай використовуються для даної конфігурації. Пакет графічної бібліотеки gd2 було перезібрано без підтримки формату графічного файлу xpm та який отримав назву libgd2-noxpm. Перезбірка робилася для того щоб виключити тяжкі залежності на бібліотеки графічного інтерфейсу XOrg.

У результаті отримано середовище виконання ПЛК з підтримкою:

  • БД:
    • SQLite
  • Архівування:
    • на файлову систему
  • Джерело даних:
    • обчислювач функціональних блоків
    • обчислювач на Java-схожій мові високого рівня
    • контролери логічного рівня
    • різноманітні ПЛК за протоколом ModBus (RTU,ASCII,TCP)
    • дані ОС
  • Транспорт:
    • послідовні інтерфейси;
    • TCP, UDP та UNIX сокети;
    • безпечний шар сокетів (SSL).
  • Транспортні протоколи:
    • HTTP
    • власний протокол контролю OpenSCADA
  • Інтерфейс користувача:
    • рушій середовища візуалізації та керування (СВК)
    • візуалізатор СВК на основі Web-технологій
    • конфігуратор OpenSCADA на основі Web-технологій

Конфігурація OpenSCADA запускається у режимі демону та у локалі uk_UA.UTF-8 з використанням локальної БД SQLite, надаючи по замовченню мережеві сервіси:

  • конфігурація через Web (порти: 10002 та 10004);
  • середовище виконання через Web (порти: 10002 та 10004);
  • інтерфейс керування OpenSCADA (порт: 10005).

3.2. iROBO-3000a

iROBO-3000a представляє з себе безвентиляторний промисловий комп'ютер з встановленим Intel Atom D425 1.8 GHz із VGA, 2xGb LAN, 4xCOM, 4xUSB, 1GB RAM, 1x2.5" SATA HDD 120GB, Mini-PCIe, 4x4 DIO, CF слот, SIM Card слот, Audio, WDT, робочий діапазон температур -5..+55°С. Продуктивності даного комп'ютера достатньо для виконання як функцій серверу збору, контролю та керування, так і функцій станції візуалізації. Однак у зв'язку із використанням непродуктивного процесору родини Atom виконання математичних моделей технологічних процесів потребує всіх ресурсів процесору. Наприклад, при виконанні математичної моделі АГЛКС процесор навантажується на 86%. Контролер має сертифікат "УкрСЕПРО", що може бути важливим для багатьох користувачів на території України.

Робоче оточення OpenSCADA для цього комп'ютера будувалося на основі пакетної бази дистрибутиву ALTLinux T6, а також свіжо-зібраного оточення стільниці Trinity (TDE). Збірка оточення здійснювалася на основі вищенаведеної концепції за допомогою оновленого профілю "mkimage". У новий профіль також було додано мету "plc", однак її сутність змінилася фактично ставши копією мети "live", що стало можливим завдяки впровадженню на етапі первинної ініціалізації прозорого монтування розділу з міткою "alt-live-storage" як відображення упакованої файлової системи із довільним доступом на модифікацію. В цілому це дозволило створити фіксоване ядро прошивки з базовим набором програмного оточення, розміром 300Мб, та можливістю вільного розширення шляхом довстановлення потрібних пакетів із дистрибутиву.

У якості оточення стільниці було обрано Trinity з причини наявності проблеми фонового артифактингу у зв'язці XOrgServer 1.10 + QT4, а також малої ресурсомісткості TDE при високій розвинутості та стабільності.

Архів профілів збірки нового оточення отримав назву mkimage-profiles-6-kdesktop-plc.tgz, а остання збірка прошивки ALTLinux6-OpenSCADA_0.7.2-i586-plcUI_TDE-generic.flash.tar.

4. Прошивка та створення програмного оточення ПЛК архітектури ARM

Широке розповсюдження у вбудованих рішеннях отримала архітектура ARM завдяки її порівняно високій продуктивності у поєднані із низьким енергоспоживанням та ціною. З метою виконання планового завдання забезпечення апаратної багатоплатформності систему OpenSCADA було адаптовано до збірки та роботи на обладнані ARM-архітектури. Так було виконано проекти збірка проекту OpenSCADA для мобільних пристроїв фірми Nokia (N800, N900, N950) (RU) та Збірка OpenSCADA та прошивки для ARM-контролерів фірми ICP DAS (LP-5141). Метою даного розділу є систематизація методик та відстеження проблем створення збірок OpenSCADA та прошивок програмного оточення в цілому для різного вбудованого обладнання архітектури ARM.

Особливістю ARM архітектури є відсутність обов'язкової апаратно-залежної програмної системи первинної ініціалізації та конфігурації обладнання, характерної для, x86 архітектур — BIOS, а структура апаратної конфігурації зазвичай містить: центральний процесор (CPU), вбудовану оперативну та флеш-пам'ять, а також низку вбудованого обладнання на стандартних шинах системного рівня. При цьому флеш та оперативна пам'ять знаходяться у загальному адресному сегменті. Ініціалізація такої системи програмним оточенням здійснюється завантаженням виконуваного коду безпосередньо на вбудовану флеш-пам'ять.

Для роботи обчислювальних функцій OpenSCADA та і багатьох супутніх бібліотек та програм важлива продуктивність обчислень із плаваючою точкою. Особливістю процесорів архітектури ARM є простота ядра процесору та необов'язкова наявність розширень на зразок математичного сопроцесору. Як наслідки продуктивність на операціях з плаваючою точкою сильно залежить від конкретно взятого процесору, а також способу емуляції обчислень з плаваючою точкою, у випадку відсутності сопроцесору взагалі. На процесорах ARM-архітектури зустрічаються два формати роботи з плаваючою точкою: FPA та VFP. Формат FPA є застарілим та зустрічається у вигляді апаратної реалізації з ядрами ARM до родини StrongARM(ARMv4). Ядра ARM родини XScale(ARMv5TE) взагалі не комплектувалися математичним сопроцесором. А ядра ARM починаючи із родини ARM11(ARMv6) комплектуються математичним сопроцесором формату VFP. У той же час ARM процесори з архітектурою версії ARMv5 до цих пір широко розповсюджені, тобто питання продуктивності математичних обчислень для них зводяться до продуктивності емуляції формату FPA або VFP. У випадку із оточенням ОС Linux, емуляція FPA зазвичай здійснюється ядром Linux, шляхом обробки виключень процесору під час виклику FPA команд. Програмна емуляція у математичній бібліотеці за звичай зустрічається з форматом VFP, для чого потрібна перебудова всіх програм. При цьому емуляція FPA за посередництвом виключень гірше за продуктивністю програмної емуляції VFP майже на порядок. Порівняти продуктивність обчислень із плаваючою точкою на різних архітектурах, процесорах та способах емуляції можна із таблиці нижче:

Обладнання

Операція sin(Пі) [у JavaLikeCalc], мкс

Операція pow(Пі,2) [у JavaLikeCalc], мкс

ARM

ICP DAS LP-5141 (PXA270, FPA)

100 [200]

51 [152]

ZAO ZEO TionPro270 (PXA270, SoftVFP, uCLibc-0.9.32.1, -Os)

22 [51]

14 [41]

ZAO ZEO TionPro270 (PXA270, SoftVFP, GLibC-2.14.1, -O2)

15 [33]

12 [31]

Segnetics SMH2Gi (ARM926EJ-S, SoftVFP)

23 [44]

12 [31]

Nokia N800 (400 МГц)

6 [15]

6 [17]

Nokia N900 (1ГГц), N950 (1ГГц)

3 [6]

2 [6]

x86

AMD Geode LX800 (500 МГц)

3 [7]

4 [9]

AMD Athlon X2 3600+

3 [3]

3 [3]

AMD Turion L625 1.6

3 [4]

3 [4]

Intel Core2 Duo 1.6

2 [2]

2 [3]

 

Різниця у часі обчислення при прямому виклику математичної операції та із віртуальної машини JavaLikeCalc пов'язана із впливом частоти ядра процесору (частоти на якій воно працює) та яким виконується частина команди до передачі її математичному сопроцесору. Продуктивність математичного сопроцесору зазвичай не пов'язана безпосередньо із продуктивністю та частотою ядра процесору.

Типове програмне оточення на основі ОС Linux, для обладнання на основі ARM, представляє із себе: Завантажувач UBoot, Ядро Linux та Кореневу Файлову Систему (КФС). Завантажувач UBoot вантажиться до нульового сектору флеш-пам'яті, а його налаштування зберігаються у першому. Із другого сектору завантажується код ядра, а безпосередньо після нього КФС. КФС зазвичай оформлюється у вигляді файлової системи JFFS2 або UbiFS, які оптимізовано для роботи на блокових пристроях — флеш пам'яті, з обмеженим ресурсом запису. Приклади розбивки блокового пристрою (флеш-пам'яті) для LP-5141 та TionPro270 наведено нижче:

# LP-5141

$ cat /proc/mtd

dev: size erasesize name

mtd0: 00040000 00020000 "Bootloader"

mtd1: 00040000 00020000 "Bootloader Param"

mtd2: 00280000 00080000 "Kernel"

mtd3: 03c80000 00080000 "JFFS2 Filesystem"

# TionPro270

$ cat /proc/mtd

dev: size erasesize name

mtd0: 00080000 00040000 "Bootloader"

mtd1: 00400000 00040000 "Kernel" mtd2: 01b80000 00040000 "Filesystem"

Коренева файлова система містить типове UNIX-дерево з робочими програмами, бібліотеками та іншими файлами. Основою будь якої програми або бібліотеки є системні бібліотеки GLibC або UClibc. OpenSCADA адаптовано для збірки та роботи з "GLibC" версії >= 2.3. "UClibC", створена як полегшена версія "GLibC" для вбудованих систем, містить низку обмежень та до цих пір не реалізує або містить помилки у реалізації для низки функцій.

КФС та програмне оточення на основі Linux може постачатися разом із ARM-обладнанням та містити закриті бінарні бібліотеки, модулі ядра Linux та т.п. У такому випадку незалежна збірка та заміна первинного програмного оточення становиться непрактичною оскільки призводить до втрати первинної функціональності. Однак часто зустрічається ситуація постачання обладнання ARM без первинного програмного оточення або з оточенням, яке не містить закритого коду та яке може бути замінено. Прикладом першого випадку є контролер LP-5141 та схожі фірми "ICP DAS", які містять бінарну збірку бібліотеки API спеціалізованого обладнання (libi8k) та модулі ядра Linux для його ініціалізації. Прикладом другого випадку є одноплатний комп'ютер Тіон-Про270, створення програмного оточення та побудова OpenSCADA для архітектури ARM якого будемо розглядати нижче.

4.1. Інструменти збірки ядра Linux та робочих оточень під різні цільові архітектури

Сформувати Linux КФС можна на основі готових пакунків існуючого бінарного дистрибутива, пакунків вихідних текстів існуючого дистрибутиву, а також побудувати із оригінальних вихідних текстів за посередництвом ToolChain у одній із збіркових систем.

Побудова програм або цілої КФС для архітектур відмінних від x86 та x86_64 зазвичай здійснюється за посередництвом кроскомпіляції із використанням утиліт (ToolChain) для збірки, лінковки та налаштування під цільову архітектуру ARM. Для автоматизації цього процесу створено низку інструментів збірки готових КФС.

4.1.1. BuildRoot

Ця система збірки є частиною проекту створення альтернативної бібліотеки функцій мови "C" UClibc тому в основному націлена на побудову оточень із "UClibc", з відповідними обмеженнями. BuildRoot гарно показав себе у роботі на хостових системах різних версій та дозволяє без особливих проблем збирати програмні оточення на основі Linux.

4.1.2. PTXDist

Універсальний інструмент збірки ядер, ToolChain та програмних оточень на основі Linux, фірми "Pengutronix". PTXDist є потужним та гнучким інструментом однак старі його версії мають проблеми на сучасних хостових системах, що ускладнює завдання збірки програмних оточень для порівняно старих, але все ще розповсюджених, апаратних платформ. Наприклад, зараз (2012 рік) можна зустріти нове обладнання з процесорами ARM XScale, ARM9 (ARMv5) часів 2003 року. Однак новими версіями PTXDist непогано підтримуються старі платформи, про що можна дізнатися з таблиці підтримки за посиланням: www.pengutronix.de/oselas/toolchain/index_en.html.

4.2. Тион-Про270

Одноплатний комп'ютер "Тіон-Про270" представляє собою високоінтегровану обчислювально-керуючу систему на базі процесору Marvell PXA270 із ARM ядром родини XScale від фірми ЗЕО. Цю плату було передано розробникам проекту OpenSCADA Олексієм Попковим з метою адаптації OpenSCADA.

Всі матеріали по збірці програмного оточення з OpenSCADA та готові збірки для плати Тіон-Про270 можна отримати за посиланням: ftp://ftp.oscada.org/OpenSCADA/PLC/TionPro270

Плата постачається виробником обладнання з предвстановленим програмним оточенням на основі Linux™ або Windows CE©. Крім того всі вихідні матеріали програмних оточень доступні на Wiki-ресурсі виробника.

5.3. SMH2Gi

Вільнопрограмований панельний контролер "SMH2Gi" представляє собою високоінтегровану обчислювально-керуючу систему на базі процесору iMx27 з ядром ARM926EJ-S від фірми Сегнетікс. Адаптація та збірка OpenSCADA для цього контролера знадобилося у межах проекту створення автоматизованої системи керування вакуумної технологічної установки (RU).

Всі матеріали по збірці програмного оточення з OpenSCADA та готові збірки для панельного контролеру можна отримати за посиланням: ftp://ftp.oscada.org/OpenSCADA/PLC/Segnetics-SMH2Gi

Панельний контролер постачається виробником обладнання з передвстановленим програмним оточенням на основі Linux™ та власним оточенням виконання контролера "SMLogix". Роль OpenSCADA для даного контролера розглядалася як розширене середовище програмування контролеру, інтегроване та програмоване із станції верхнього рівня на основі OpenSCADA. Для збереження можливості надання та контролю даними отриманих у OpenSCADA на вбудованому дисплеї, при цьому мінімізувавши працевитрати на адаптацію, вирішено було зберегти вихідне середовище виконання "SMLogix" для виконання завдання представлення даних на внутрішньому дисплеї, а дані транслювати до/із неї за посередництвом локального ModBus/TCP підключення.

У відношенні програмного оточення панельного контролера SMH2Gi в цілому потрібно зробити декілька зауважень. У контролері використано ядро Linux 2.6.29 з розширенням жорсткого реального часу, що дозволяє утримувати періодичні інтервали часу до 100 мкс. Крім того всі критичні системні потоки запущені з політикою керування планування реального часу. При цьому, хоча процесор не має математичного сопроцесора, емуляція виконана оптимально у вигляді SoftVFP. Все це дозволяє у OpenSCADA виконувати високо-детерміновані завдання керування з періодичністю до 100 мкс та прийнятною обчислювальною продуктивністю.


3687