OpenSCADA у програмованому логічному контролері (ПЛК)
Ім'я: ПЛК |  |
1. Вступ
Сучасні системи автоматизованого керування технологічними процесами (АСК ТП) є достатньо складними. Умовно ієрархію АСК ТП можна поділити на два рівня: нижній та верхній рівень. Нижній рівень АСК ТП містить польова обладнання (датчики та виконавчі механізми), а також програмовані логічні контролери (ПЛК). Верхній рівень представляє з себе систему оперативної візуалізації та контролю за технологічним процесом — SCADA-система. ПЛК становить відповідальну частину АСК ТП, яка виконує функцію збору даних польового обладнання, обчислення та видачу керувальних, блокувальних та інших дій на керувальні органи польового обладнання.
OpenSCADA є відкритою реалізацією SCADA-системи, яку засновано на модульній архітектурі, що дозволяє будувати кінцеві рішення під різноманітні вимоги. Цільовим призначення OpenSCADA є системи верхнього рівня, однак висока ступінь модульності, і як наслідки масштабованості, дозволяють вирішувати широке коло задач суміжних областей.
2. Промислові програмовані логічні контролери
Ринок ПЛК насичено широким спектром виробів різної архітектури та конструкції. Архітектурно ПЛК можна поділити на три умовні групи:
- жорстко-програмовані ПЛК та модульні пристрої погодження з об'єктом (ППО);
- високоінтелектуальні комерційні ПЛК;
- PC-сумісні ПЛК.
Жорстко-програмовані ПЛК за звичай будуються на основі одно-кристальних мікроЕОМ або мікросхемах програмованої логіки. Програма таких контролерів або прошивається єдиноразово, надаючи можливість програмної параметризації, або ж формується спеціалізованими засобами, які наділено функціями компіляції бінарної прошивки середовища виконання з програмою користувача, наприклад 
ISaGRAF або LabView. У якості представника такого ПЛК можна у приклад привести модулі розподіленого ППО фірми Advantech.
Високоінтелектуальні комерційні ПЛК за звичай будуються на базі більш потужного обладнання з архітектурою, близькою до повноцінного PC-комп'ютеру. Основною відмінністю від стандартного PC-сумісного ПЛК є закрита програмна, а часто і апаратна архітектури. Програмне оточення таких контролерів за звичай базується на операційній системі реального часу, яка планує декілька потоків користувача з поділом їх за пріоритетом. Користувальницьке програмування таких ПЛК здійснюється роботою у фірмовому програмному оточенні, яке формує у якості результату бінарний код потоку ПЛК. У якості представника такого обладнання можна навести ПЛК серії S7 фірми Siemens.
PC-сумісні ПЛК - це група скоріше не ПЛК, прямо сумісних з PC, а ПЛК, які не містять інтегрованого середовища виконання і часто постачаються без операційної системи. Архітектура таких ПЛК може бути різною, починаючи від економічних рішень архітектури x86 та закінчуючи архітектурними рішеннями ARM та MIPS. Середовище виконання таких ПЛК за звичай формують з ПЗ того ж класу, що і у випадку з жорстко програмованими ПЛК у вигляді бінарного файлу для виконання під одну з розповсюджених, масштабованих або спеціалізованих ОС (DOS, QNX, Linux, WinCE, VxWorks). Часто зустрічаються і спеціалізовані під задачу рішення. У якості представників цього класу можна розглядати ПЛК формфактору PC/104.
Варіанти конструктивного виконання ПЛК можна умовно поділити на моно-блочні та модульні. Моно-блочні ПЛК надають фіксовану конфігурацію ППО, спеціалізовану під обмежене коло завдань. Модульні конструкції надають можливість легкого розширення конфігурації ППО під потрібне завдання. Існують також і гібридні конструкції, які представляють із себе моно-блок, спроможний розширювати своє ППО за рахунок зовнішніх блоків ППО, які підключаються по одному з стандартних інтерфейсів, наприклад, за RS-485.
3. OpenSCADA як середовище виконання ПЛК
Архітектура системи OpenSCADA дозволяє створювати кінцеві рішення під різні вимоги та ресурси шляхом модульного розширення. Ця можливість виявляється корисною у світлі обмеженості ресурсів ПЛК. Крім того, враховуючи постійний розвиток апаратного забезпечення, а також безперервне підвищення інтеграції та економічності сучасних мікропроцесорних рішень, OpenSCADA дозволяє послідовно розширювати функціональність ПЛК, зберігаючи наступність зі старими рішеннями. Наприклад, на основі системи OpenSCADA можна будувати рішення з мінімальними вимогами на рівні: CPU 100 МГц, пам'ять та флеш диск по 30 Мб.
Як було зазначено вище ресурси сучасних ПЛК можуть коливатися у достатньо великих межах, причому ПЛК фіксованого типу, побудовані на однокристальних мікроЕОМ, все далі відтискаються у вузько-спеціалізовані області розвиненими PC-архітектурами. Така тенденція робить все більш цікавою можливість створення уніфікованої відкритої платформи для реалізації середовища виконання ПЛК на основі уніфікованих PC-платформ.
OpenSCADA дозволяє реалізувати ідею створення відкритої платформи для реалізації середовища виконання ПЛК. Вже зараз можна реалізувати оточення ПЛК, яке небагато чим поступається комерційним інтелектуальним контролерам, а багато у чому і перевершує їх за рахунок можливості інтегрування функцій, характерних для SCADA систем, у оточення ПЛК, розширюючи функціональні та користувацькі характеристики ПЛК та приводячи його на єдину зі SCADA кодову базу, а також оптимізуючи вартість кінцевого рішення.
Перелічимо функції які вирішуються OpenSCADA у межах оточення ПЛК:
- збір даних різного спектру обладнання у синхронному, асинхронному або блочному режимах;
- користувальницькі процедури обробки даних та видача керуючих дії на Java-схожій мові високого рівня та на формальнім мові блочних схем;
- архівація даних, починаючи від тимчасових буферів у пам'яті та закінчуючи повноцінними архівами на файловій системі або у БД різної дискретизації та глибини;
- інтеграція у інфраструктуру АСК ТП шляхом реалізації стандартних протоколів взаємодії (ModBus, SNMP, OPC UA ...);
- інтеграція з СКБД для експорту даних, збереження конфігурації або архівів;
- вільна конфігурація та адміністрування мережі ПЛК як за посередництвом оперативного інтерфейсу станції адміністрування, так і за посередництвом Web-інтерфейсу;
- можливість реалізації панелей оператора з інтерфейсом контролю та керування на вбудованій Touch-панелі;
- надання Web-інтерфейсів оперативного та диспетчерського контролю.
4. Прошивка та створення програмного оточення ПЛК архітектури x86
Перед реалізацією прошивки ПЛК ставилися наступні вимоги:
- Компактність. У зв'язку з прямою залежністю ціни на промислові флеш-диски від їх об'єму, а також реальною відсутністю потреби частого оновлення, образ прошивки потрібно упаковувати, досягнувши рівня компактності 8-50Мб на середовище виконання ПЛК у оточенні повноцінної ОС.
- Уніфікований вихідний репозиторій. Оскільки прошивка не є чимось немодифікованим, не розширюваним та остаточно фіксованим, то у її основі має лежати реальний репозиторій пакетів ОС який розвивається. Це дозволить довгий час формувати обновлення та розширення, не підтримуючи при цьому опосередкованого репозиторію.
- Відлагоджена та проста процедура збору. Враховуючи той факт, що конфігурація прошивки може деякий час стабілізуватися, крім того у компонентах ОС та OpenSCADA будуть знаходитися та усуватися помилки, то процедура збору прошивки не має бути обтяжливою, а напроти - легко адаптованою.
- Прозора реалізація режиму запису до дерева ОС. Хоча прошивка і має на увазі створення упакованого немодифікованого образу прошивки, однак специфіка роботи середовища виконання ПЛК передбачає модифікацію БД та ведення архівів. Крім того, наявність можливості корекції вихідної конфігурації є важливою вимогою.
- Надійність та стійкість до раптових вимикань. Специфікою експлуатації ПЛК є, як правило, відсутність можливості коректного виключення, а також практична реальність ситуацій миттевого та непередбачуваного пропадання живлення. ПЛК у таких випадках має зберігати працеспроможність, у сенсі того що містити журнальовану ФС та забезпечувати її перевірку та автоматичне усунення помилок.
- Умовний поділ конфігурації ПЛК на два типа:
- ПЛК без локального дисплею, можливо з простим текстовим табло.
- Touch-панелі з функцією ПЛК.
4.1. Інструменти та збірка робочих оточень
Враховуючи вищенаведені вимоги, для створення прошивки було вибрано репозиторій пакетів дистрибутиву ОС Linux ALTLinux та інструмент створення дистрибутивів mkimage. mkimage - інструмент для збору штампів Sisyphus-based системи за шаблоном. У якості вихідного набору шаблонів було взято набір шаблонів формування дистрибутивів ALTLinux за адресою git://git.altlinux.org/people/boyarsh/packages/mkimage-profiles-desktop, командою:
За основу формування PLC шаблону було взято стандартний "rescue", як найбільш компактний та близький до цільової задачі ПЛК.
4.1.1. Створення
У першу чергу створювалась конфігурація ПЛК без локального дисплею у зв'язку з наявністю обладнання такого типу та відсутності обладнання для Touch-панелей.
Новий шаблон ПЛК було названо "plc" та він тестувався на платах формфактору PC/104 MOPSlcdLX фірми Kontron, ATH400-128 фірми Diamond Systems та модульного ПЛК LP-8781 фірми ICP DAS. Архів результуючого дерева mkimage з шаблоном "plc" можна завантажити тут ftp://ftp.oscada.org/OpenSCADA/PLC (шаблони та матеріали окремих контролерів розміщено у власних директоріях).
Ключовим моментом конфігурації нового шаблону стало написання скрипту ініціалізації (rc.sysinit), скрипту післяінсталяційної конфігурації штампу прошивки та переліку пакетів у штампі прошивки. Перший скрипт оформлено у вигляді пакету "startup-plc". Другий скрипт вкладено до шаблону "plc" за шляхом: profiles/plс/image-scripts.d/01system. Перелік пакетів вкладено до шаблону "plc" за шляхом: profiles/pkg/lists/plс.in
Процедура створення прошивки з шаблону наступна:
В результаті отримаємо вихідну директорію у profiles/out/ виглядом:
4.1.2. Інсталяція
Завантажувати прошивку можна на: USB-flash, IDE-flash и HDD. Однак, у випадку з USB-flash можуть бути проблеми з очікуванням ініціалізації USB-підсистеми та потрібно буде трохи побігати по діалогам завантажувача.
Файлова система може бути fat або ext2/ext3. У випадку з ext3 монтування ФС відбувається як ext2, через проблеми у ініціалізаторі. У випадку з ext2/ext3 потрібно буде використовувати не завантажувач syslinux, а extlinux, конфігурація якого власне майже нічим не відрізняється.
Далі монтуємо носії та розміщуємо на ньому файли з вихідної директорії наступним чином.
У випадку з fat та syslinux:
У випадку з ext2/ext3 та extlinux:
Для забезпечення надійного функціонування робочі дані розміщуються у файлі "work" з файловою системою ext3. Файлова система цього файлу перевіряється на цілісність під час ініціалізації. Створюється цей файл наступним чином:
У випадку з файловою системою ext2/ext3 на цільовому диску можна файл "work" не створювати. Тоді робочі дані будуть розміщуватися безпосередньо у директорії "root" цільового диску. Увага. Це ненадійне рішення, оскільки файлова система цільового диску становиться нестатичною, а перевірити її немає можливості, у зв'язку з раннім монтуванням у "ro" та потенційною ненадійністю перевірки ФС, змонтованої у "ro", а також неможливості перемонтування як ext3.
Наступним етапом є конфігурація та ініціалізація завантажувача. Для конфігурації завантажувача потрібно відредагувати файл syslinux/syslinux.cfg або extlinux/extlinux.conf наступним чином:
У випадку вибору ідентифікації завантажувального розділу за ідентифікатором дізнатися його для нашого розділу можна командою: blkid.
У випадку з міткою це завдання дещо складніше оскільки робиться це для різних файлових систем по різному.
Для файлових систем ext2/ext3 це робиться утилітою e2label. Наприклад, так: "e2label /dev/sdb1 PLС"
Для файлової системи FAT це робиться низкою утиліт з комплекту mtools наступним чином:
Тепер можемо ініціалізувати завантажувач:
На цьому з завантаженням та ініціалізацією прошивки все. Якщо отриманий диск не завантажується тоді:
- Відсутній прапорець завантаження на робочому розділі.
- Некоректний або пошкоджений "MBR". Перевірити та відновити його можна за допомогою утиліти "ms-sys".
- Розділи носія створено за допомогою parted. Ця утиліта незрозумілим чином вирівнює розділи, що не дозволяє з них завантажуватися на USB-flash. Потрібно носій перерозмітити за допомогою fdisk.
- Завантаження також може не працювати на старих системах, які не вміють завантажуватися з USB-HDD. Для них потрібно буде адаптувати геометрію диска, налаштовуючи під USB-ZIP або щось подібне.
4.1.3. Результат
У результаті отримаємо прошивку розміром від 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).
4.1.4. 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).
4.1.5. Деталі реалізації
В цьому розділі розглянемо деталі дерева ОС прошивки, скрипт ініціалізації rc.sysinit.plc та скрипт приготування дерева ОС прошивки.
Для побудови прошивки ПЛК було використано наступний перелік пакетів:
Перелік модулів ядра системи завантажувача з метою зменшення розміру штампу ініціалізации було зменшено до переліку:
До скрипту приготування дерева було додано функції:
- зміни найменування дистрибутива;
- заміщення скрипту ініціалізації на inittab.plc;
- створення користувача-адміністратора "admin" та встановлення паролів по замовченню у "123456" для користувачів "root" та "admin";
- ініціалізація /etc/fstab;
- встановлення локалі у uk_UA.UTF-8;
- конфігурація мережі;
- встановлення годинника;
- включення потрібних сервісів;
- видалення: документації, сторінок допомоги та інформації, іконок, RPM-БД та кеша apt;
- видалення непотрібних локалей та перекладів, залишені en_US, ru_RU та uk_UA;
- додано код для відбору тільки використаних модулів ядра та видалення всіх інших; по замовченню виключено та може бути включено для приготування фінальної прошивки під конкретне обладнання;
- видалення теки з ядром (/boot), у зв'язку з виносом його у корінь завантажувального розділу.
Скрипт ініціалізації (rc.sysinit.plc) було наділено функціями:
- перемонтування корневого розділу у режим RW;
- перевірка та підключення файлової системи (/image/root) робочих даних користувача (файл work);
- відображення тек ПЛК які підлягають модифікації (/etc, /var, /root, /home, /mnt и /lib) на файлову систему з робочими даними користувача (/image/root) за посередництвом файлової системи "aufs" або "unionfs";
У результаті цих дії таблиця монтування кінцевого дерева ПЛК прийняла вигляд:
4.1.6. Налаштування графічного інтерфейсу
Один з варіантів прошивки збирається з графічним інтерфейсом, який, однак, потрібно налаштувати для отримання автоматичного запуску з середовищем візуалізації OpenSCADA. Крім того, потрібно відзначити, що прошивка з графічним інтерфейсом не містить всіх драйверів та може потребувати її перебудови під потрібне обладнання.
Після завантаження та входу до консолі потрібно сконфігурувати XServer, автоматичний графічний вхід, запуск графічного оточення та автоматичний запуск OpenSCADA із оточення IceWM:
4.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.
5. Прошивка та створення програмного оточення ПЛК архітектури 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 наведено нижче:
Коренева файлова система містить типове UNIX-дерево з робочими програмами, бібліотеками та іншими файлами. Основою будь якої програми або бібліотеки є системні бібліотеки GLibC або UClibc. OpenSCADA адаптовано для збірки та роботи з "GLibC" версії >= 2.3. "UClibC", створена як полегшена версія "GLibC" для вбудованих систем, містить низку обмежень та до цих пір не реалізує або містить помилки у реалізації для низки функцій.
КФС та програмне оточення на основі Linux може постачатися разом із ARM-обладнанням та містити закриті бінарні бібліотеки, модулі ядра Linux та т.п. У такому випадку незалежна збірка та заміна первинного програмного оточення становиться непрактичною оскільки призводить до втрати первинної функціональності. Однак часто зустрічається ситуація постачання обладнання ARM без первинного програмного оточення або з оточенням, яке не містить закритого коду та яке може бути замінено. Прикладом першого випадку є контролер LP-5141 та схожі фірми "ICP DAS", які містять бінарну збірку бібліотеки API спеціалізованого обладнання (libi8k) та модулі ядра Linux для його ініціалізації. Прикладом другого випадку є одноплатний комп'ютер Тіон-Про270, створення програмного оточення та побудова OpenSCADA для архітектури ARM якого будемо розглядати нижче.
5.1. Інструменти збірки ядра Linux та робочих оточень під різні цільові архітектури
Сформувати Linux КФС можна на основі готових пакунків існуючого бінарного дистрибутива, пакунків вихідних текстів існуючого дистрибутиву, а також побудувати із оригінальних вихідних текстів за посередництвом ToolChain у одній із збіркових систем.
Побудова програм або цілої КФС для архітектур відмінних від x86 та x86_64 зазвичай здійснюється за посередництвом кроскомпіляції із використанням утиліт (ToolChain) для збірки, лінковки та налаштування під цільову архітектуру ARM. Для автоматизації цього процесу створено низку інструментів збірки готових КФС.
5.1.1. BuildRoot
Ця система збірки є частиною проекту створення альтернативної бібліотеки функцій мови "C" UClibc тому в основному націлена на побудову оточень із "UClibc", з відповідними обмеженнями. BuildRoot гарно показав себе у роботі на хостових системах різних версій та дозволяє без особливих проблем збирати програмні оточення на основі Linux.
Отримати архів BuildRoot потрібної версії можна за посиланням http://buildroot.uclibc.org/downloads. Далі його потрібно розпакувати у домашній директорії звичайного користувача та здійснити конфігурацію, налаштування та збірку:
У процесі збірки можуть виникнути проблеми наступного роду:
- Неможливість завантаження архівів програм.
- Помилки збірки програм.
5.1.2. PTXDist
Універсальний інструмент збірки ядер, ToolChain та програмних оточень на основі Linux, фірми "Pengutronix". PTXDist є потужним та гнучким інструментом однак старі його версії мають проблеми на сучасних хостових системах, що ускладнює завдання збірки програмних оточень для порівняно старих, але все ще розповсюджених, апаратних платформ. Наприклад, зараз (2012 рік) можна зустріти нове обладнання з процесорами ARM XScale, ARM9 (ARMv5) часів 2003 року. Однак новими версіями PTXDist непогано підтримуються старі платформи, про що можна дізнатися з таблиці підтримки за посиланням: http://www.pengutronix.de/oselas/toolchain/index_en.html.
Для збірки програмного оточення (КФС) за допомогою PTXDist потрібно:
- отримати архів інструментарію складальника (разом з проектами найближчих версій, http://www.pengutronix.de/software/ptxdist/download), зібрати та встановити його;
- отримати архів вихідних файлів (тієї-ж або близької версії як PTXDist, http://www.oselas.com/oselas/toolchain/download) та зібрати ToolChain;
- клонувати-створити та зібрати проект КФС.
Тепер детальніше, в командах:
5.2. Тион-Про270
Одноплатний комп'ютер "Тіон-Про270" представляє собою високоінтегровану обчислювально-керуючу систему на базі процесору Marvell PXA270 із ARM ядром родини XScale від фірми ЗЕО. Цю плату було передано розробникам проекту OpenSCADA Олексієм Попковим з метою адаптації OpenSCADA.
Всі матеріали по збірці програмного оточення з OpenSCADA та готові збірки для плати Тіон-Про270 можна отримати за посиланням: ftp://ftp.oscada.org/OpenSCADA/PLC/TionPro270
Плата постачається виробником обладнання з предвстановленим програмним оточенням на основі Linux™ або Windows CE©. Крім того всі вихідні матеріали програмних оточень доступні на Wiki-ресурсі виробника.
У первинному вигляді плата потрапила до розробників з мінімальним програмним оточенням, для якого не було можливості зібрати OpenSCADA, тому програмне оточення було повністю завантажено з нуля. Завантаження програмного оточення до flash-пам'яті здійснювалося за допомогою JTAG-адаптеру OLIMEX ARM-USB-OCD та програми OpenOCD версії 0.5.0, збірку якої потрібно конфігурувати з параметром "--enable-ft2232_libftdi".
Для завантаження до флеш-пам'яті плати було використано готові збірки завантажувача UBoot-1.3.3 (файл образу u-boot-1.3.3_svn886_520mhz_tion_pro270_64m.bin) та ядра Linux-2.6.22.19. Образ файлової системи JFFS2 КФС збирався за допомогою "BuildRoot" та "PTXDist", про що нижче.
Прошивка обладнання за допомогою "OpenOCD" здійснюється від особи суперкористувача командою:
При цьому сценарій прошивки "tion270.cfg" та файли образів програмного оточення, вказані у сценарії прошивки "tion270.cfg", мають знаходитися у поточній теці. Сценарій прошивки "tion270.cfg" містить:
5.2.1. Збірка КФС у BuildRoot
З метою уникнути виникнення безлічі проблем збірки, пов'язаних зі збіркою із самого початку, була взята конфігурація "buildroot-2009.08" безпосередньо від виробника обладнання, із Git-репозиторію: http://zao-zeo.ru/media/files/linux/buildroot-2009.08.git. З метою збірки у оточені "BuildRoot" були створені конфігурації у директорії "./package/ для бібліотеки "LibGD" та OpenSCADA.
Отриману після збірки КФС було завантажено до флеш-пам'яті плати та з успіхом запущено. Однак при запуску виявилося, що версія "uCLibс" 0.9.30.3 не містить реалізації функції clock_nanosleep(), а також падає у функції timer_settime(), для типу повідомлення SIGEV_THREAD. Якщо функцію clock_nanosleep() можна замінити на nanosleep() то вирішити проблему функції timer_settime(), у межах даної версії "uCLibс", можливості немає.
Далі було взято образ поточної версії "BuildRoot", на 16.01.2012, та здійснено збірку OpenSCADA з "uCLibs" версії 0.9.32.1. Збірка пройшла вдало, після деякої адаптації збіркового оточення. OpenSCADA запустилася вдало з деякими проблемами, які було усунено.
У переліку нижче наведено проблеми які виникли під час збірки та роботи OpenSCADA на uCLibC різних версій:
- У типовій конфігурації відсутня реалізація функцій usleep() та msleep() — створено та повсюдно використано загальносистемна, для OpenSCADA, функція sysSleep() з реалізацією на основі nanosleep().
- < 0.9.32: не збирається у зв'язку із відсутністю низки функцій, а також OpenSCADA не запускається:
(-) 0.9.30.3: падіння на функції timer_settime(), для типу повідомлення SIGEV_THREAD — Актуально.
- 0.9.32: збірка пройшла вдало, з деякими вирішуваними проблемами під час запуску OpenSCADA:
(+) Функції сімейства printf() некоректно обходять проблему висячих символів '%' — виправлено рядок повідомлення "Last: %s. Load: %3.1f% (%s from %s)".
(+) Відмінна від GLibC обробка взаємоблокувань у межах одного потоку, у функціях RW-lock — виправлено взаємоблокування у модулі OpenSCADA.UI.WebVision, а функцію перевірки сеансів винесено до процедури сервісного виклику.
5.2.2. Збірка КФС у PTXDist
Освоєння PTXDist для збірки оточення на TionPro270 здійснювалося за посередництвом вивчення досвіду викладеного за посиланням http://www.emb-linux.narod.ru/tion-pro-270/index.html. Однак статтю написано доволі давно та для збірки використовувалася версія ptxdist-1.1.1, яка на сучасному програмному оточені фактично не працює, а крім того частина бібліотек, потрібних для OpenSCADA, там просто не збираються. В результаті за основу було взято версію ptxdist-2011.11.0 та на ній здійснено збірку.
Перед безпосередньою збіркою КФС для цієї плати було створено конфігурацію ToolChain "arm-xscale-linux-gnueabi_tion270.ptxconfig" на основі існуючої "arm-xscale-linux-gnueabi_gcc-4.6.2_glibc-2.14.1_binutils-2.21.1a_kernel-2.6.39-sanitized.ptxconfig" з версіями програм:
- GLIBC_ENABLE_KERNEL="2.6.19", оскільки реальне ядро версії 2.6.22 та для роботи GLibC з ним має бути вказано меншу або рівну версію;
- KERNEL_HEADERS_VERSION="2.6.30.5", версія ядра для заголовків;
- CROSS_GCC_VERSION="4.5.2".
Далі було створено клон проекту PTXDist "OSELAS.BSP-Pengutronix-Generic" у директорії "TionPro270_RootFS" з конфігурацією платформи "arm-qemu-2011.01.0". Для збірки OpenSCADA створено конфігурацію в особі файлу openscada.in та openscada.make, які було розташовано у директорії локальної конфігурації проекту rules/. Крім OpenSCADA було адаптовано конфігурація програми udev, версія якої виявилася дуже великою для вихідної версії ядра Linux-2.6.22, тобто використану версію udev було опущено до 141. Нові файли конфігурації udev також було розташовано у директорії rules/ тим самим визначивши їх використання замість вихідної конфігурації.
Збірка КФС пройшла вдало та було отримано образ ФС jffs2. Отриману КФС було вдало завантажено на плату та вона запрацювала. OpenSCADA також коректно запустилася та функціонує.
5.2.3. Адаптація
Ця плата містить низку апаратних інтерфейсів адаптація яких цікава для OpenSCADA, тому у даному розділі буде концентруватися інформація по їх адаптації.
Плата містить мікросхему перетворення рівнів сигналу із RS232 в RS485, яка однак не є прозорою для надсилання запитів із програмного забезпечення. А саме:
- для надсилання запиту потрібно встановити в нуль сигнал інтерфейсу RS232 "RTS";
- потрібно читати інтерфейс на предмет очікування відлуння посилки від запиту, після отримання якого встановити сигнал RS232 "RTS", відкинути відлуння посилки та продовжити чекати безпосередньо відповіді.
Для вирішення цієї особливості модуль OpenSCADA Transport.Serial було доопрацьовано на предмет підтримки такого роду апаратного керування потоком.
Використовуючи отримане розширення було здійснено перевірку та підтверджено наявність проблеми програмного оточення контролера LP-5141.
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 підключення.
Для збірки вихідного програмного оточення розробником було використано раніш розглянутий інструментарій PTXDist версії 1.99.12. Зібрати ToolChain, вгадуючи профіль, використаний для збірки вихідного програмного оточення, не потребувалося оскільки на сайті виробника доступне повне збіркове середовище, оформлення у вигляді образу ОС Linux для віртуальної машини VMWare. Із цього образу було отримано готовий ToolChain профіль "gcc-4.3.2-glibc-2.8-binutils-2.18-kernel-2.6.27-sanitized". Оскільки не потрібно було збирати КФС повністю вирішено було зібрати OpenSCADA використовуючи готовий ToolChain окремо. Для збірки OpenSCADA попередньо було зібрано бібліотеки "pcre-8.12" та "sqlite-3.7.6.2" Далі OpenSCADA збиралась наступним чином:
В результаті було сформовано архів збірки OpenSCADA, який можна вивантажити на панельний комп'ютер SMH2Gi та там розпакувати. Отримане програмне оточення OpenSCADA налаштовано на автоматичний запуск при запуску контролера за посередництвом скрипту ініціалізації "/etc/init.d/openscada". Збірку OpenSCADA було вдало запущено.
У відношенні програмного оточення панельного контролера SMH2Gi в цілому потрібно зробити декілька зауважень. У контролері використано ядро Linux 2.6.29 з розширенням жорсткого реального часу, що дозволяє утримувати періодичні інтервали часу до 100 мкс. Крім того всі критичні системні потоки запущені з політикою керування планування реального часу. При цьому, хоча процесор не має математичного сопроцесора, емуляція виконана оптимально у вигляді SoftVFP. Все це дозволяє у OpenSCADA виконувати високо-детерміновані завдання керування з періодичністю до 100 мкс та прийнятною обчислювальною продуктивністю.
6. Рішення ПЛК
У цьому розділі міститься інформація про моделі ПЛК реально побудованих або проектованих на основі розробленого середовища виконання и прошивки ПЛК.
| Компоненти PLC | Ціна, $ | Зауваження |
| PC/104 | ||
| CPU: Kontron MOPSlcdLX | 430 | AMDGeodeLX800(i686)-500МГц, 0°-60°C, 5Вт, Video |
| CPU: Diamond ATHM500-256A | 1275(1160) | VIA Mark(i686)-500МГц, 256Мб, -40°-85°C, 10Вт, Video, 16AI, 4AO, 24DIO |
| CPU: Diamond ATHM500-256N | 889(807) | VIA Mark(i686)-500МГц, 256Мб, -40°-85°C, 10Вт, Video |
| CPU: Rhodeus | ? | AMDGeodeLX800(i686)-500МГц, -20°-70°C, 5Вт, Video |
| CPU: Tri-M VSX104 | 380 | Vortex x86SX(i486sx)-300МГц, 128Мб, -40°-85°C, 2Вт, не випробовано |
| MEM: DDR-SODIM-256M | 15 | для Kontron MOPSlcdLX |
| Flash Disk: Kontron chipDISK/1000-IDE | 100 | 1Гб, 0°-70°C |
| Flash Disk: M-Systems MD1171-D1024 | 42 | 1Гб, 0°-70°C |
| Flash Disk: M-Systems MD1171-D256 | 22 | 256Мб, 0°-70°C |
| Flash Disk: M-Systems MD1171-D128 | 18 | 128Мб, 0°-70°C |
| Flash Disk: Diamond systems FD-128-XT | ? | 128Мб, -40°-85°C |
| Flash Disk: Diamond systems FD-1G-XT | ? | 128Мб, -40°-85°C |
| Box: PB-300-K | 118(96) | |
| Box: PB-EAP-300-K | 275(248) | |
| Box: CT-4 | 171(162) | |
| БП: MMEANWELL DR-4505 | 30 | |
| IO: DMM-16-AT (16AI, 4AO, 16DIO) | 744(597) | -40°-85°C |
| IO: DMM-32X-AT (32AI, 4AO, 24DIO) | 883(742) | -40°-85°C |
| RS485: EMM-OPT4-XT | 396(376) | -40°-85°C |
| ICP DAS LP-8x81 | ||
| CPU: LP-8781 | 945 | |
| IO: I-8017HW (8AI DE, 16AI SI) | 215 | Паралельна шина, збір до 30 КГц |
| IO: I-87019RW (8AI) | 205 | Додатковий захист від перенапруги, підтримка термопар та термометрів опору. |
| IO: I-87024W (4AO) | 210 | Вихід по току і напрузі. |
| IO: I-8042W (16DI + 16DO) | 125 | Паралельна шина. |
| IO: I-87057W (16DO) | 100 | Послідовна шина, функції сторожового таймеру для сеансу зв'язку. |
7. Посилання
- Матеріали для створення прошивки для x86: ftp://ftp.oscada.org/OpenSCADA/PLC/
- Повідомлення про помилки завантажувача (propagator): https://bugzilla.altlinux.org/show_bug.cgi?id=17416
- Матеріали для створення програмного оточення та прошивки для різного ARM обладнання: TionPro270, SMH2Gi