From OpenSCADAWiki
Jump to: navigation, search
This page is a translated version of the page Sub-projects/Embedding and PLC and the translation is 100% complete.
Other languages:
English • ‎mRussian • ‎Українська
Назва Заснування Стан Учасники Іконка
Загальне вбудовування OpenSCADA та програмовані логічні контролери (ПЛК). Адаптація OpenSCADA до апаратної платформи ARM. Жовтень 2008 Впроваджено у багатьох вбудованих рішеннях та продовжується впровадження у нових, доповнюється на предмет: Роман Савоченко OrangePi.png
Опис
Проєкт присвячено загальній концепції вбудовування OpenSCADA до різного обладнання та створенню: оточення виконання ПЛК, прошивок ПЛК та апаратних конфігурацій спеціалізованих ПЛК. Розглядається вбудовування до систем, заснованих на архітектурах x86 та ARM. Посилання:

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

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

1 Програмовані Логічні Контролери

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

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

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

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

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

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

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

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

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

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

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

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

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

Архітектура x86 порівняно недавно стала позиціюватися як вбудована та реальні рішення на її основі у цій галузі рідко мають ресурси "< i386", яких недостатньо для виконання повноцінної ОС та розвинутого оточення. З цієї причини, а також з причини більшої уніфікації архітектури, індивідуальні збірки ядра Linux та базових програм оточення ОС здійснюються достатньо рідко, що за звичай характерно для архітектури ARM. Більш цікавим та практичним для x86, для широкого кола обладнання, є збірка прошивок зі стисненою кореневою файловою системою (КФС). Однак все ще можлива індивідуальна збірка прошивок за допомогою систем складання на кшталт "BuildRoot" або "PTXDist", нижче. Також можлива і пряма установка дистрибутиву Linux.

3.1 Дистрибутив ALTLinux, інструменти для збірки робочих оточень прошивок зі стиснутою КФС

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

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

Враховуючи вищенаведені вимоги для створення прошивки було обрано інструмент створення дистрибутивів mkimage ALTLinux. mkimage — інструмент для складання, за шаблоном, штампів системи заснованої на Sisyphus. У якості вихідного набору шаблонів було взято набір шаблонів формування дистрибутивів 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", як найбільш компактний та близький до цільової задачі ПЛК.

Первинне складання здійснювалось на основі пакетної бази дистрибутиву ALTLinux 5.1, де присутнє ядро реального часу від XENOMAI. Для отримання низки специфічних пакетів потрібно підключити репозиторій "ALTLinux 5.1" від проєкту OpenSCADA: 

rpm ftp://ftp.oscada.org/ALTLinux/5.1 openscada main

3.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.

Процедура створення прошивки з шаблону наступна: 

# Створення скрипту конфігурації "configure"
./autoconf
# Конфігурація складання для генерації образів дисків
./configure --with-imagetype=flash
# Складання штампу
make plc.cd

У результаті отримаємо вихідну теку у "profiles/out/" з виглядом: 

syslinux/       # тека завантажувача
  alt0/         # файли завантажувача
    full.cz     # штамп системи первинної ініціалізації
    vmlinuz     # ядро ОС Linux
  syslinux.cfg  # конфігураційний файл завантажувача
plс             # штамп робочої системи з ОС, OpenSCADA та іншими утилітами

3.1.2 Інсталяція

Завантажувати прошивку можна на: USB-flash, IDE-flash та HDD. Однак, у випадку із USB-flash можуть бути проблеми з очікуванням ініціалізації USB-підсистеми та потрібно буде трохи "побігати" по діалогам завантажувача.

Файлова система може бути FAT або EXT2/3. У випадку з EXT3 монтування ФС відбувається як EXT2, через проблеми у ініціалізаторі. У випадку із EXT2/EXT3 потрібно буде використовувати не завантажувач syslinux, а extlinux, конфігурація якого власне майже нічим не відрізняється.

Надалі монтуємо носій та розміщуємо на ньому файли з вихідної теки, наступним чином.

У випадку із FAT та syslinux: 

syslinux/       # тека завантажувача "syslinux"
  alt0/         # файли завантажувача
    full.cz     # штамп системи первинного завантаження
    vmlinuz     # ядро ОС Linux
  syslinux.cfg  # конфігураційний файл завантажувача
plс             # штамп упакованої кореневої файлової системи з ОС, OpenSCADA та іншими утилітами
work            # файлова система EXT3 з робочими даними

У випадку із EXT2/3 та extlinux: 

extlinux/       # тека завантажувача "extlinux" (перейменувати "syslinux")
  alt0/         # файли завантажувача
    full.cz     # штамп системи первинної ініціалізації
    vmlinuz     # ядро ОС Linux
  extlinux.conf # конфігураційний файл завантажувача (перейменувати syslinux.cfg)
plс             # штамп упакованої кореневої файлової системи з ОС, OpenSCADA та іншими утилітами
work            # файлова система EXT3 з робочими даними

Для забезпечення надійного функціонування робочі дані розміщуються у файлі "work" з файловою системою EXT3. Файлова система цього файлу перевіряється на цілісність під час ініціалізації. Створюється цей файл наступним чином: 

# Створення файлу робочих даних на 200МБ
dd if=/dev/zero of=./work bs=1024 count=204800
# Створення файлової системи EXT3 у файлі
mkfs.ext3 -m 0 work

У випадку з файловою системою EXT2/3 на цільовому диску можна файл "work" не створювати. Тоді робочі дані будуть розміщуватися безпосередньо у теці "root" цільового диску. At.png Це ненадійне рішення, оскільки файлова система цільового диску становиться нестатичною, а перевірити її немає можливості, у зв'язку з раннім монтуванням у "ro" та потенційною ненадійністю перевірки ФС, змонтованої у "ro", а також неможливості перемонтування як EXT3.

Наступним етапом є конфігурація та ініціалізація завантажувача. Для конфігурації завантажувача потрібно відредагувати файл "syslinux/syslinux.cfg" або "extlinux/extlinux.conf" наступним чином: 

default plc
prompt 1
timeout 200
implicit 1

label plc
  kernel alt0/vmlinuz
# Використовувати у випадку ідентифікації завантажувального розділу за міткою
  append initrd=alt0/full.cz live lowmem fastboot stagename=plc showopts automatic=method:disk,label:PLC
# Використовувати у випадку ідентифікації завантажувального розділу за ідентифікатором
#  append initrd=alt0/full.cz live lowmem fastboot stagename=plc showopts automatic=method:disk,uuid:4824-271E

У випадку вибору ідентифікації завантажувального розділу за ідентифікатором дізнатися його для нашого розділу можна командою: blkid.

У випадку з міткою це завдання дещо складніше оскільки робиться це для різних файлових систем по різному.

Для файлових систем EXT2/3 це робиться утилітою e2label. Наприклад, так: $ e2label /dev/sdb1 PLС.

Для файлової системи FAT це робиться низкою утиліт із комплекту mtools або за допомогою parted, що простіше. За допомогою mtools це робиться наступним чином: 

# Редагуємо /etc/mtools.conf на предмет додання рядка: drive c: file="/dev/sdb1"
# Де /dev/sdb1 завантажувальний розділ цільового диску
# Встановлюємо мітку розділу
mlabel c:PLС

Тепер можемо ініціювати завантажувач: 

# Для "syslinux"
syslinux /dev/sdb1  #попередньо розділ потрібно розмонтувати
# Для "extlinux" (шлях вказує на точку монтування розділу цільового диску /media/PLС)
extlinux --install /media/PLС/extlinux

На цьому з завантаженням та ініціюванням прошивки все. Якщо отриманий диск не завантажується тоді:

  • Відсутній прапорець "Завантажувальний" на робочому розділі.
  • Некоректний або пошкоджений "MBR". Перевірити та відновити його можна за допомогою утиліти "ms-sys": $ ms-sys -s /dev/sdb.
  • Розділи носія створено за допомогою parted. Ця утиліта незрозумілим чином вирівнює розділи, що не дозволяє з них завантажуватися, на USB-flash. Потрібно носій перерозподілити за допомогою fdisk.
  • Завантаження також може не працювати на старих системах, які не вміють завантажуватися з USB-HDD. Для них потрібно буде адаптувати геометрію диска, налаштовуючи під USB-ZIP або щось подібне.

3.1.3 Результат

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

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

3.1.4 OpenSCADA

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

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

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

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

3.1.5 Деталі реалізації

У цьому розділі розглянемо деталі дерева ОС прошивки, скрипт ініціалізації rc.sysinit.plc та скрипт приготування дерева ОС прошивки.

Для побудови прошивки ПЛК було використано наступний перелік пакетів: 

interactivesystem

### Startup
kernel-image-@KERNEL@
rootfiles
startup
startup-plc
SysVinit

hwclock

### Common
coreutils
glibc-locales
glibc-nss
glibc-utils
glibc-timezones
sysfsutils
sysklogd
util-linux
schedutils

### Disk utils
hdparm

### Applications
binutils
pciutils
procps
shadow-suite

### Applications/Archiving
gzip

### Applications/File
less

### Filesystem utils
e2fsprogs

### Applications/Networking
etcnet
iputils
mailx
openssh-server
dhcpcd
ntpd

### Applications/Shells
bash
mc

udev
dbus
hal
libgd2-noxpm
fonts-ttf-liberation
lm_sensors
nut
nut-driver
nut-server
watchdog

### OpenSCADA Console
#openscada-plc
                                                                                                                             
## OpenSCADA GUI
openscada-visStation
autologin
icewm
wm-select
xorg-x11-server
#xorg-drv-geode
xorg-x11-utils
fonts-ttf-dejavu
fonts-bitmap-terminus

Перелік модулів ядра Linux, стадії попередньої ініціалізації, з метою зменшення розміру штампу ініціалізації було зменшено до переліку: 

loop.ko
mtouch.ko
pcmcia_core.ko
rsrc_nonstatic.ko
yenta_socket.ko
scsi_mod.ko
libusual.ko
ide-disk.ko
ide-core.ko
sd_mod.ko
usbcore.ko
ehci-hcd.ko
ohci-hcd.ko
uhci-hcd.ko
appletouch.ko
usbhid.ko
usbtest.ko
usb-storage.ko
mbcache.ko
jbd.ko
ext2.ko
ext3.ko
fat.ko
nls_base.ko
nls_cp866.ko
nls_koi8-r.ko
nls_utf8.ko
zlib_inflate.ko
squashfs.ko
unionfs.ko
vfat.ko
pata_cs5536.ko
amd74xx.ko

До скрипту приготування дерева було додано функції:

  • зміна найменування дистрибутива;
  • заміщення скрипту ініціалізації на "inittab.plc";
  • створення користувача-адміністратора "admin" та встановлення паролів по замовченню у "123456" для користувачів "root" та "admin";
  • ініціалізація /etc/fstab;
  • встановлення локалі у "en_US.UTF-8";
  • конфігурація мережі;
  • встановлення годинника та зони у "/usr/share/zoneinfo/Europe/Kiev", для зміни потрібно замінити файл "/etc/localtime" у потрібну зону;
  • включення потрібних сервісів;
  • видалення: документації, сторінок допомоги та інформації, іконок, RPM-БД та кеша apt;
  • видалення непотрібних локалей та перекладів, залишені en_US, uk_UA та ru_RU;
  • відбір тільки використаних модулів ядра та видалення всіх інших; по замовченню вимкнено та може вмикатися для приготування фінальної прошивки під конкретне обладнання;
  • видалення теки з ядром (/boot), у зв'язку із виносом його у корінь завантажувального розділу.

Скрипт ініціалізації (rc.sysinit.plc) було наділено функціями:

  • перемонтування кореневого розділу у режим RW;
  • перевірки та підключення файлової системи (/image/root) робочих даних користувача (файл "work");
  • відбиття тек ПЛК, які підлягають модифікації (/etc, /var, /root, /home, /mnt та /lib) на файлову систему з робочими даними користувача (/image/root) за посередництвом файлової системи "aufs" або "unionfs".

У результаті цих дій таблиця монтування кінцевого дерева ПЛК набула вигляду: 

cat /etc/mtab
#rootfs / rootfs rw 0 0
#udev /dev tmpfs rw,size=10240k,mode=755 0 0
#/dev/hda1 /image vfat rw,fmask=0022,dmask=0022,codepage=cp866,iocharset=utf8,check=r 0 0
#/dev/loop0 / squashfs ro 0 0
#/proc /proc proc rw 0 0
#sysfs /sys sysfs rw 0 0
#tmpfs /tmp tmpfs rw 0 0
#/dev/loop1 /image/root ext3 rw,noatime,nodiratime,errors=continue,data=ordered 0 0
#/image/root/etc /etc unionfs rw,dirs=/image/root/etc=rw:/etc=ro 0 0
#/image/root/var /var unionfs rw,dirs=/image/root/var=rw:/var=ro 0 0
#/image/root/root /root unionfs rw,dirs=/image/root/root=rw:/root=ro 0 0
#/image/root/home /home unionfs rw,dirs=/image/root/home=rw:/home=ro 0 0
#/image/root/mnt /mnt unionfs rw,dirs=/image/root/mnt=rw:/mnt=ro 0 0
#/image/root/lib /lib unionfs rw,dirs=/image/root/lib=rw:/lib=ro 0 0
#devpts /dev/pts devpts rw,nosuid,noexec,gid=5,mode=620 0 0
#shmfs /dev/shm tmpfs rw,nosuid 0 0


3.1.6 Налаштування графічного інтерфейсу

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

Після завантаження та входу до консолі потрібно сконфігурувати XServer, автоматичний графічний вхід, запуск графічного оточення та автоматичний запуск OpenSCADA із оточення IceWM: 

# Завантаження шаблону конфігураційного файлу XOrg ftp://ftp.oscada.org/OpenSCADA/PLC/xorg.conf,
# розташування його у теці /etc/X11
# !! Редагування файлу /etc/X11/xorg.conf під власні потреби.

# Додання перемикання розкладок клавіатури: Англійська, Українська, mRussian
echo "-option grp:lctrl_lshift_toggle -variant ,winkeys,winkeys -layout us,ua,ru -model pc104" > /etc/X11/xinit/Xkbmap

# Випробувальний запуск
startx

# Конфігурація автоматичного графічного входу шляхом створення файлу /etc/sysconfig/autologin із вмістом:
echo "AUTOLOGIN=yes" > /etc/sysconfig/autologin
echo "USER=admin" >> /etc/sysconfig/autologin
echo "EXEC=/usr/bin/startx" >> /etc/sysconfig/autologin

# Увімкнення запуску графічної підсистеми під час завантаження
chkconfig dm on

# Запуск графічної підсистеми
service dm start

# !! Подальші дії відбуваються у терміналі з графічним оточенням

# Створення конфігураційного файлу автоматичного запуску OpenSCADA із оточення IceWM
mkdir ~/.icewm
echo "#!/bin/sh" > ~/.icewm/startup
echo "xset -dpms; xset s off" >> ~/.icewm/startup
echo "/usr/bin/openscada_start" >> ~/.icewm/startup

3.1.7 Пакетна база ALTLinux T6

Наступним етапом у створені прошивок став перехід на пакетну базу дистрибутиву ALTLinux T6. В цілому процедуру створення прошивки було збережено, з низкою змін, але при цьому було додано деякі покращення та розширення:

  • Використано нову функція "propagator" (система попередньої ініціалізації обладнання, пошуку та завантаження штампів ФС) пошуку/створення розділу EXT2/3/4 з міткою "alt-live-storage" для формування кореневого розділу "root" з можливістю модифікації. Ця функція надає повноцінну можливість встановлення додаткових пакетів прямо із репозиторія дистрибутива, а також оновлення упакованих у прошивку пакетів, виключаючи ядро та низку системних сервісів.
  • Додано можливість створення прошивки у вигляді комбінованого ISO-штампу, який можна (окрім запису на CD/DVD) прямо, за допомогою утиліти dd, записати на USB-flash, HDD, SSD та отримати робоче оточення із розділом "alt-live-storage", відбиття "root", на вільне місце носія.
  • Для можливості збірки нових прошивок під "LP-8x81" від ICP DAS було здійснено перенесення ядра реального часу "rt-up" із репозиторію "ALTLinux 5.1" у "ALTLinux T6". Ядро "rt-up" з успіхом адаптовано та отримано робочу прошивку на пакетній базі "T6" для "LP-8x81".

Оскільки з'явилася можливість легко довстановлювати потрібні пакети безпосередньо із репозиторія то відпала потреба у окремій збірці прошивок із GUI. Тобто можна легко довстановити потрібний менеджер вікон (WM) або оточення робочого столу із потрібними драйверами, чим створювати окрему прошивку із обмеженим переліком драйверів.

Скрипт "startup-plc" виявився непотрібним у нових прошивках оскільки перемонтування на запис кореневої ФС "root" здійснюється раніше, на стадії первинної ініціації. Скрипт "profiles/plс/image-scripts.d/01system" перейменовано у "profiles/plс/image-scripts.d/init1-PLC", оскільки змінено та розширено. Перелік пакетів прошивки залишено у "profiles/pkg/lists/plс.in" та дещо змінено.

Для отримання низки специфічних пакетів потрібно під'єднати репозитірий "ALTLinux T6" від проєкту OpenSCADA: 

rpm ftp://ftp.oscada.org/ALTLinux/t6 openscada main

Процедура створення прошивки із шаблону фактично не змінилась: 

# Створення скрипту конфігурації "configure"
./autoconf
# Конфігурація складальника для генерації штампів дисків. Ключ "--with-imagetype" можна встановити у "iso", або опустити,
# для створення комбінованого ISO-штампу
./configure --with-distro=kdesktop --with-branding=altlinux-kdesktop --with-version=6.0 --with-language=en_US --with-imagetype=flash
# Збірка штампу
make plc.cd

Вміст вихідної теки із штампом та встановлення прошивки на файлову систему FAT та EXT2/3/4 відрізняється тільки перейменуванням файлу архіву ФС із "plc" у "live". Встановлення ISO-штампу на USB-flash, HDD, SSD виконується командою dd: 

dd if=LP8x81-ALTLinuxT6-OpenSCADA_0.8.0.6-i586-plc.iso of=/dev/sd{x} bs=4096

Замість файлу "work" потрібно створити розділ EXT3 з міткою "alt-live-storage", якщо це не ISO-штамп. Створювати новий розділ можна за допомогою fdisk, якщо FAT розділ було створено не на всьому доступному просторі диску, або за допомогою parted, де розділ FAT можна зменшити. За деталями створення розділу відішлемо до документації на fdisk або parted.

Конфігурація файлів "syslinux/syslinux.cfg" та "extlinux/extlinux.conf" не змінилася, окрім зміни ім'я архіву ФС із "plc" на "live".

У результаті отримано прошивку розміром від 60МБ, яка забезпечує:

  • Завантаження протягом 25 секунд від включення контролеру, включаючи ініціацію BIOS.
  • Перевірку та відновлення журналу робочої файлової системи "root" у "alt-live-storage".
  • Зберігання користувацьких даних та змін прошивки, а також нових та оновлених пакетів програм, у розділі "alt-live-storage".
  • Автоматичне налаштування мережі за DHCP (або 192.168.0.1), для першого інтерфейсу.
  • Доступ до контролеру по SSH та зручний інтерфейс роботи, включаючи mc. Паролі відсутні, а користувач "root" має доступ для підключення за SSH.
  • Синхронізацію часу за посередництвом NTP.
  • Виконання OpenSCADA із доступом за посередництвом мережевих інтерфейсів:
    • конфігурація та середовище виконання через Web (порт 10002);
    • інтерфейс управління OpenSCADA (порт 10005).

Для побудови прошивки ПЛК використовувався наступний перелік пакетів: 

# INIT 3
#
acl
usbutils
screen
acpid
acpi
anacron
vim-minimal
mc
sound-scripts
alsa-utils
apt
udev
udev-initramfs
dbus
schedutils
pciutils
setserial
lm_sensors3
rsync
interactivesystem
su
system-report
mtools
netcat
strace
binutils
syslogd
glibc-utils
glibc-gconv-modules
glibc-nss
glibc-timezones
glibc-locales
shadow-utils
keyutils
lsof
sudo

# INIT3: BLOCK DEVICES
#
hdparm
fdisk
ms-sys
syslinux
dosfstools
e2fsprogs

#network
etcnet
dhcpcd
xinetd
iftop
lftp
wget
iptables
ntp
ntpd
ntpdate
tcpdump
multipath-tools
openssh-clients
openssh-server
ppp-pppoe

#### LP
kernel-modules-icp-@KERNEL_MOD@

#### Console OpenSCADA
libgd2-noxpm
openscada-plc
openscada-DAQ.DiamondBoards
openscada-DAQ.ICP_DAS
openscada-DAQ.Comedi

Перелік модулів ядра Linux, стадії попередньої ініціалізації, був дещо змінений та склав: 

loop.ko
mtouch.ko
pcmcia_core.ko
rsrc_nonstatic.ko
yenta_socket.ko
scsi_mod.ko
libusual.ko
ide-disk.ko
ide-core.ko
ide-gd_mod.ko
sd_mod.ko
usbcore.ko
ehci-hcd.ko
ohci-hcd.ko
uhci-hcd.ko
appletouch.ko
usbhid.ko
usbtest.ko
usb-storage.ko
mbcache.ko
jbd.ko
ext2.ko
ext3.ko
fat.ko
nls_base.ko
nls_cp866.ko
nls_koi8-r.ko
nls_utf8.ko
zlib_inflate.ko
squashfs.ko
unionfs.ko
aufs.ko
vfat.ko
pata_via.ko
pata_cs5536.ko
amd74xx.ko

Скрипт підготовки дерева "profiles/plс/image-scripts.d/init1-PLC" виконує функції:

  • зміна найменування дистрибутива;
  • відкриття входу від "root" через SSH, без пароля;
  • встановлення локалі у "en_US.UTF-8";
  • конфігурація мережі для використання DHCP або встановлення "192.168.0.1" для першого інтерфейсу;
  • встановлення годинника та зони у "/usr/share/zoneinfo/Europe/Kiev", для зміни потрібно замінити файл "/etc/localtime" у потрібну зону;
  • увімкнення потрібних сервісів;
  • видалення: документації, сторінок допомоги та інформації, іконок;
  • видалення непотрібних локалей та перекладів, залишено en_US, uk_UA та ru_RU;
  • відбір тільки використаних модулів ядра та видалення всіх інших; по замовченню вимкнено та може вмикатися для приготування фінальної прошивки під конкретне обладнання; уніфіковано для зазначення модулів за групами підсистем ядра та специфічними для обладнання;
  • видалення тек з ядром (/boot), у зв'язку із виносом його у корінь завантажувального розділу.

3.1.8 Ядро реального часу

Для низки задач ПЛК важливим, часто і критичним, критерієм оточення є його рівень забезпечення реального часу (RealTime), тобто можливість роботи задач згідно із пріоритетами реального часу та забезпечення реакції на повідомлення згідно цим приорітетам.

Ядро Linux, саме по собі, надає POSIX політики планування за реальним часом "SCHED_FIFO" та "SCHED_RR" із діапазоном пріоритетів (0...100). Однак важливий критерій "Частота таймеру та час реакції на нього" до версій ядер Linux 2.6.24 були дуже низькими, за мірками систем реального часу. У сучасних ядрах Linux (> 2.6.24) забезпечено підтримку таймерів високої роздільної здатності (HPET), що зменшило час реакції на таймер до рівня 100 мікросекунд, однак стабільність цього часу реакції не забезпечено. Для забезпечення стабільності реакції на таймер на рівні 60 мікросекунд, а також низки інших критеріїв реального часу, на цей час ядро потрібно складати із одним із розширень реального часу.

У дистрибутивах ALTLinux помічено ядро 2.6.29-rt-up, яке зібрано із розширенням реального часу XENOMAI. У інших дистрибутивах, наприклад OpenSuSE, помічено навіть продукти з такими розширеннями.

На цей час більш високі показники реального часу забезпечує розширення The Real Time Preempt Patch, при увімкнені повної підтримки (CONFIG_PREEMPT_RT), процес складання та результати роботи Linux ядер з якими будуть відстежуватися у цьому розділі.

Для тестування рівня реального часу тих або інших ядер будемо користуватися утилітою "Cyclictest", типовий рядок виклику та аргументи будуть такими: "$ cyclictest -t1 -c1 -p 80 -n -i 200 -l 100000". Де:

  • -t1 — один потік тестування;
  • -с1 — використовувати годинник реального часу CLOCK_REALTIME;
  • -p 80 — пріоритет потоку тестування;
  • -n — використовувати функцію "clock_nanosleep";
  • -i 200 — інтервал виклику потоку тестування: 200 мкс, як близький до середнього значення 50 мкс;
  • -l 100000 — кількість ітерацій тестування.

Пара вимірювань для ядер Linux загального призначення:

  • Стандартне ядро дистрибутиву ALTLinux T6 (3.0.79-std-def, LP-8781):
    • навантаження 0%: Avg: 37 us; Max: 152 us
    • навантаження 100%: Avg: 37 us; Max: 191 us
  • Ядро дистрибутиву ALTLinux T6 (3.4.45-un-def, LP-8781):
    • навантаження 0%: Avg: 53 us; Max: 217 us
    • навантаження 100%: Avg: 40 us; Max: 183 us
3.1.8.1 kernel-image-rt-up-2.6.29

Це ядро міститься у дистрибутиві ALTLinux 5.1, а також перенесено до локального репозиторію проєкту OpenSCADA, для ALTLinux T6. Це ядро зібрано із розширенням XENOMAI та AUFS, що дозволяє використовувати його у прошивках із упакованою КФС, що і зроблено для ПЛК LP-8x81.

Результати тестування цього ядра із різними патчами реального часу та без:

  • LP-8781 (XENOMAI)
    • навантаження 0%: Avg: 26 us; Max: 136 us (помічено скиди до 1 мс, схоже через нестабільність джерела годинника "tsc", причому "acpi_pm" тут ще гірше)
    • навантаження 100%: Avg: 24 us; Max: 3655 us
  • LP-8781 (CONFIG_PREEMPT_NONE)
    • навантаження 0%: Avg: 29 us; Max: 71 us
    • навантаження 100%: Avg: 28 us; Max: 117 us (помічено зісковзування на безперервне нарощування)
  • LP-8781 (CONFIG_PREEMPT_RT)
    • навантаження 0%: Avg: 29 us; Max: 64 us
    • навантаження 100%: Avg: 29 us; Max: 82 us
  • AMD Turion Neo X2 L625 (CONFIG_PREEMPT_RT)
    • навантаження 0%: Avg: 57 us; Max: 74 us
    • навантаження 100%: Avg: 57 us; Max: 78 us

Як видно із результатів тесту, патч XENOMAI не забезпечує пристойного рівня реального часу при використані стандартних механізмів планування реального часу POSIX, в той час як ядра версії 3 навіть без наявності особливих розширень реального часу забезпечують помітно кращий результат.

Потреба складання саме цього ядра із патчем/параметром CONFIG_PREEMPT_RT стоїть через наявність низки бінарних модулів від ICP_DAS, для "LP-8x81". Також стоїть питання збірки ядра 2.6.33 з тієї-ж причини, але для "LP-8x81 Atom". Попередні збірки ядер 2.6.29 та 2.6.33 виявили низку проблем, які будуть тут описані. Розглядається також варіант збірки сучасного ядра із CONFIG_PREEMPT_RT, а потім запит на збірку бінарних модулів у "ICP DAS".

Процес складання та тестування:

  1. Патчі CONFIG_PREEMPT_RT та AUFS часів 2.6.29 конфліктують на функції "debug_mutex_set_owner()", у CONFIG_PREEMPT_RT видалена — замінено на "mutex_set_owner()".
  2. При складанні виявлено низку проблем із "# typedef void irqreturn_t;" — замінено на "#include <linux/irqreturn.h>".
  3. Перший запуск із CONFIG_PREEMPT_RT, але без AUFS, пройшов вдало — результат вище.
  4. Запуск із AUFS виявив проблему виділення пам'яті AUFS у "aufs_mmap()" — робочий код AUFS взято цілком із попередньої збірки "rt-up-2.6.29.alt2".
  5. Запуск із AUFS виявив проблему зависання на корінні ФС у AUFS, схоже через можливість зациклювання/блокування RT-задачі — встановлено CONFIG_PREEMPT_NONE, на LP-8781 та "AMD Turion" проблем не виявлено (можливо ця проблема через відсутність HPET на PLX8).
  6. На перший погляд ядро працює нормально, але помічено зісковзування на безперервне нарощування часу запізнення.
  7. Виконано адаптацію ядра для бінарної сумісності із модулями "slot" та "icp" від ICP_DAS. Модуль "8250_linpac" падає при завантажені, а "icpdas_8250" має безліч нерозв'язаних символів — потрібно ці модулі перескладати або пробувати інтерфейси > COM2 ініціювати через setserial — модулі перескладено, завдяки Golden Wang (тех. підтримка ICPDAS).
  8. Нове ядро встановлено під високе навантаження, конфігурацією проєкту САУ кульових барабанних млинів:
  • Збій мережі із драйвером "via_rhine", після 4 діб роботи — збій очікуваний, зібрано драйвер "rhinefet", випробування продовжено.
  • На драйвері "rhinefet" система під навантаженням пропрацювала три тижні. Однак помічено, що переривання 11, на якому висить майже все стандартне обладнання (USB, Ethernet та може ще чогось), вимикається та мережа працює у режимі "Опитування", що повільніше. Можливо вимкнення цього переривання відбувається і з "via_rhine", а він не може працювати у режимі "Опитування", чому і пакети у/із мережі не ходять. Проблема пов'язана із відмовою та генерацією необроблених переривань одним із обладнань на переривані 11.
  • Виправлено виключенням вимкнення переривань за допомогою параметра ядра Linux "noirqdebug".
  • Адаптацію вдало завершено та прошивки на основі цього ядра готові до промислової експлуатації!
  • 01.03.2015: Замість функції EnableWDT() використано EnableSysWDT(), у зв'язку із обмеженням до 30 секунд та циклічних перевантажень якщо не завантажується за 30 секунд (до трьох перевантажень).
  • 17.03.2015: При участі служби підтримки ICP_DAS виправлено проблему драйверу послідовних інтерфейсів більш за COM2, яка призводила до "замерзання" ядра Linux (схоже у зв'язку із блокуванням переривань) після закриття одного порту та активності на хоча-б одному іншому.
  • 29.07.2015: Виявлено ще одну проблему із мережею із схожими симптомами вимкнення переривання 11, але: переривання 11 не вимикається та всі інші пристрої на ньому працюють, відтворюється тільки на конфігураціях із використанням обох інтерфейсів мережі, причому можливе "гальмування" тільки одного із них. Проблема вирішується тільки перевантаженням "загальмованого" мережевого інтерфейсу, командою: ifdown eth0; ifup eth0. Для виявлення та перезапуску рекомендується на рівні OpenSCADA додавати контроль трафіку та безпосереднє перевантаження інтерфейсу за його відсутністю.
  • 21.11.2016: Драйвер "rhinefet" адаптовано на предмет запобігання блокування переривань та вимкнення вектору переривань оскільки режим SHARE використовується. Наразі драйвер працює однак 19.12.2016 також було помічено гальмування мережі із двома цими адаптерами після біля двох тижнів роботи.
At.png Відтак це обладнання зламане для роботи двох адаптерів та у цьому ПЛК ви можете використовувати лише один, для стабільної роботи!
  • 06.09.2017: Неповне виправлення у послідовному драйвері ICP-DAS, призводить до непрацедатності використання більш двох послідовних портів, схоже вже повністю виправлено у останіх версіях, що спостерігалось на LX-8x31.

At.png Отримане ядро, перейменоване у "kernel-image-rt1-up-2.6.29.alt1", можна використовувати для PLC із HPET або таймером високої роздільної здатності, а також у "LP-8x81" та "LP-8x81 Atom" (тільки одне ядро)!спостерігалось

3.1.8.2 kernel-image-rt-up-2.6.33

Складання ядра версії 2.6.33 потрібне для контролерів фірми "ICP DAS" LP-8x81 та LP-8x81 Atom з причини наявності саме для нього, із патчем CONFIG_PREEMPT_RT, бінарних драйверів "ICP DAS", для LP-8x81 Atom.

Результати тестів цього ядра:

  • AMD Turion Neo X2 L625
    • навантаження 0%: Avg: 65 us; Max: 86 us
    • навантаження 100%: Avg: 57 us; Max: 72 us
  • LP-8781
    • навантаження 0%: Avg: 37 us; Max: 88 us
    • навантаження 100%: Avg: 34 us; Max: 108 us
  • LP-8781-Atom (оригінальна збірка ядра 2.6.33.7-rt29-ICPDAS)
    • навантаження 0%: Avg: 17 us; Max: 50 us
    • навантаження 100%: Avg: 12 us; Max: 32 us

Процес складання та тестування:

  1. Збірка ядра із вихідних "ICP DAS" (2.6.33.7) та конфігурацією, успадкованою з ядра 2.6.29 (вихідні тексти містять підозріло багато *.rej файлів, а також "staging/comedi" не може бути складений) — вантажиться та в цілому працює; модулі "ipic" та "slot" вантажаться; модуль "8250_linpac" падає у функції "platform_device_add"; низка програм зависає на операціях із ФС, з повідомленням: "task openscada:2153 blocked for more than 120 seconds".
  2. Заміна AUFS на версію із 2.6.29-rt1 — падає у rtmutex прямо на завантажені; заміна на офіційну із git показала такий-же результат, від початку використано патч "aufs+sqfs4lzma-2.6.33.patch" від DLink.
  3. Збірка оригінального ядра з патчами CONFIG_PREEMPT та AUFS — проблема знову з AUFS, але тепер він "/sbin/mingetty" у кінці знайти не може.
  4. Збірка оригінального 2.6.33.9 ядра з патчами CONFIG_PREEMPT та AUFS — проблеми ті-ж.
  5. Збірка із вихідних "ICP DAS" (2.6.33.7) для SMP — модуль OpenSCADA DAQ.JavaLikeCalc падає за незрозумілою причиною.
  6. Збірка оригінального ядра з патчами CONFIG_PREEMPT та AUFS для SMP — та-ж проблема, що і без SMP, хіба-що тільки не одразу, а на приблизно п'ятому потоці.

At.png На цей момент ядро 2.6.33 у зв'язці із CONFIG_PREEMPT_RT та AUFS неробоче. Відповідно якщо потрібна буде робота на "LP-8x81 Atom" то рекомендується використовувати оригінальне Linux оточення, зібравши та встановивши OpenSCADA туди.

3.2 Дистрибутив Debian, інструменти для збірки робочих оточень прошивок зі стиснутою КФС

At.png Очікування формування

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

Широке розповсюдження у вбудованих рішеннях отримала архітектура ARM завдяки її порівняно високій продуктивності у поєднані із низьким енергоспоживанням та ціною. З метою виконання планового завдання забезпечення апаратної багатоплатформності OpenSCADA було адаптовано до збірки та роботи на обладнані ARM-архітектури. Так було виконано проєкти збірка проєкту OpenSCADA для мобільних пристроїв фірми Nokia (N800, N900, N950) та та прошивки для 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 майже на порядок. Порівняти продуктивність обчислень із плаваючою точкою на різних архітектурах, процесорах та способах емуляції можна у розділі "Продуктивність обчислювальних систем".

Типове програмне оточення на основі ОС 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 для його ініціалізації. Прикладом другого випадку є одно-платний комп'ютер Tion-Pro270, для якого це програмне оточення та побудова OpenSCADA було здійснено з нуля.

5 Архітектура MIPS

Архітектуру MIPS отримано оскільки вона зустрічається у вбудованих рішеннях на кшталт бездротових маршрутизаторів і для щільного вбудування туди OpenSCADA. Наразі ця архітектура не особливо цікава через те, що у Березні 2021, MIPS (компанія розробник) анонсувала завершення розробки архітектури MIPS оскільки вони перемкнулися на RISC-V.

Оскільки CPU у LE порядку байтів, то немає різниці у функціюванні OpenSCADA порівняно із ARM, окрім відсутності прискорення операцій із плаваючою точкою.

6 Дистрибутив OpenWrt

OpenWrt це високо-розширюваний GNU/​Linux дистрибутив для вбудованих пристроїв ​(зазвичай це роутери бездротових мереж). На різницю від інших дистрибутивів для роутерів, OpenWrt збирається із самих основ щоб бути повнофункційною та легко модифікованою операційною системою для Вашого роутеру. На практиці це означає, що на різницю від більшості інших дистрибутивів Ви можете мати всі функції, які Вам треба, без розпухання та з найновішим ядром Linux.

OpenWrt переважно розповсюджується у готових прошивках або предвстановленим на відповідне обладнання. Для складання та перескладання з вихідних текстів прошивки в цілому або окремих пакетів цей проєкт надає SDK, засноване на дещо зміненій складальній системі "BuildRoot". Для використання цього SDK Ви можете попередньо побудувати її з нуля та з потрібним ланцюгом інструментів (toolchain) або отримати готовий для відповідної версії OpenWrt та платформи щодо чого Ви можете прочитати у деталях тут.

OpenWrt використовує пакети IPKG та утиліту пакетного менеджеру "opkg", відтак Ви можете встановити готові пакети, попередньо їх завантаживши на це обладнання, наступним чином: 

opkg install openscada_0.9+r2517-1_mxs.ipk

Оскільки складальну систему BuildRoot було дещо змінено для OpenWrt та переважно у описі пакетів та доданням репозиторію "feeds", правила складання OpenSCADA потребували та були повністю переписані. Ви наразі можете завантажити їх пакет за цим посилання та розпакувати у теці "package". Для складання OpenSCADA та її пакету IPKG із приготованої та готової для цього теки BuildRoot цього SDK, з правилами OpenSCADA у теці "package", Ви маєте дотримуватися наступної інструкції: 

# Очистка складання пакету, може бути опущено при першому складані
make package/openscada/clean
# Завантаження та приготування архіву вихідних текстів OpenSCADA, ці команди викликаються автоматично за наступною командою "compile" відтак можуть бути також опущені
make package/openscada/download
make package/openscada/prepare
# Компіляція OpenSCADA, всі залежні пакети збірки OpenSCADA перед цим етапом мають бути автоматично завантажені та скомпільовані
make package/openscada/compile
# Встановлення та складання IPKG пакету, який Ви можете отримати звідси "bin/{paltform}/packages/base"
make package/openscada/install

Згідно до використання BuildRoot бібліотеки "uCLibC" мови "C" OpenSCADA потребувала деякої адаптації до uCLibC версії 0.9.33.2 після останнього складання із uCLibC версії 0.9.32.1 у 2011 році:

  • коректна перевірка "resourcesAllow" для складання без ресурсів (теки "data" та "doc"), переважно через проблему виконання тут automake;
  • змінено перевірку librt з функції clock_gettime() на clock_nanosleep();
  • для перевірки libcrypt використано функцію "crypt";
  • включення <stdarg.h> у "src/tmess.h";
  • перевірка на __UCLIBC__ у TUser::auth();
  • буфер iconv встановлено у "const char *".

Вперше OpenSCADA для OpenWrt було зібрано, вдало запущено та використано на 3G роутері "TELEOFIS RTU968" від АО "ТЕЛЕОФІС" для платформи "Freeescale i.MX23/28".

Всі матеріали довкола OpenWrt для OpenSCADA Ви можете знайти за цим посиланням.

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

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

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

7.1 BuildRoot

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

Отримати архів BuildRoot потрібної версії можна за посиланням http://buildroot.uclibc.org/downloads. Далі його потрібно розпакувати у домашній теці звичайного користувача та здійснити конфігурацію, налаштування та збірку: 

# Початкова конфігурація відносно попередньої, наприклад, після зміни версії BuildRoot
make oldconfig
# Конфігурація із псевдографічного меню
make menuconfig
# Запуск збірки
make
# Очищення оточення збирання цілком
make distclean

У процесі збірки можуть виникнути проблеми наступного роду:

  • Неможливість завантажити архіви програм.
(+) Потрібно вказаний пакет завантажити окремо та розташувати його у теці "./dl" або "./output/dl".
  • Помилки збірки програм.
(+) Однозначного рішення цієї проблеми немає та потрібно розбиратися з помилками збірки окремо для програми. Помилка збірки може бути пов'язана, наприклад, з відсутністю вибору окремого параметра під час конфігурації або з проблемою збірки програми у цьому оточені. Патчі виправлення збірки можна розташовувати безпосередньо у теці опису програми "./package/{назва пакету}/"

7.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;
  • клонувати-створити та зібрати проєкт КФС.

Тепер детальніше, в командах: 

# Встановлення та побудову складальника потрібно здійснювати від звичайного користувача, у його домашній теці.
# Вихідні архіви завантажено у ~/Downloads
mkdir ~/proj/ptxdist; cd ~/proj/ptxdist
tar xvjf ~/Downloads/ptxdist-2011.11.0.tar.bz2
tar xvzf ~/Downloads/ptxdist-2011.01.0-projects.tgz
# Переносимо вміст архіву проєктів у директорію робочої версії, якщо версії різняться.
cp -r ptxdist-2011.01.0/* ptxdist-2011.11.0/; rm -rf ptxdist-2011.01.0
# Збірка та встановлення інструментарію
cd ptxdist-2011.11.0; ./configure --prefix=/home/roman/proj/ptxdist; make install
# Встановлення змінної оточення "PATH" для виклику файлу інструментарію "ptxdist"
export PATH=$PATH:/home/roman/proj/ptxdist/bin

# Розпакування, обрання конфігурації та збірка Toolchain
cd ~/proj; tar xvjf OSELAS.Toolchain-2011.11.0.tar.bz2
# Обрання потрібної конфігурації toolchain
cd OSELAS.Toolchain-2011.11.0
ptxdist select ptxconfigs/arm-xscale-linux-gnueabi_gcc-4.6.2_glibc-2.14.1_binutils-2.21.1a_kernel-2.6.39-sanitized.ptxconfig
# Запуск збірки ToolChain.
# Результат збірки буде розташовано у теці /opt/OSELAS.Toolchain-2011.11.0 для чого потрібно надати повний доступ від ім'я суперкористувача до теки /opt.
sudo chmod a+rwX /opt
ptxdist go

# Клонування-створення проєкту КФС
# Попереднє налаштування загальної конфігурації ptxdist, наприклад, шляхи до теки проєктів (зазвичай не потрібно)
ptxdist setup
# Перевірка наявності та видимості проєктів для клонування
ptxdist projects
# Клонування одного із доступних проєктів
cd ~/proj; ptxdist clone OSELAS.BSP-Pengutronix-Generic New_RootFS
# Обрання конфігурації платформи та раніш зібраного ToolChain для нашого проєкту
cd ~/proj/New_RootFS
ptxdist platform configs/arm-qemu-2011.01.0/platformconfig
ptxdist toolchain /opt/OSELAS.Toolchain-2011.11.0/arm-xscale-linux-gnueabi/gcc-4.5.2-glibc-2.14.1-binutils-2.21.1a-kernel-2.6.30.5-sanitized/bin
# Решта налаштувань архітектури, обрання програм та формування результату конфігурується у псевдографічному конфігураторі
ptxdist menuconfig
# Збірка КФС та формування образів
ptxdist go
ptxdist images
# Конфігурацію збірки додаткових програм потрібно розташовувати у теці "rules" у вигляді двох файлів pkg.in та pkg.make.
# Для того щоб нова програма з'явилася у меню псевдографічного конфігуратору її потрібно додати
# до файлу ~/proj/ptxdist/lib/ptxdist-2011.11.0/rules/Kconfig

8 Вимірювання

8.1 Процесорних систем

Обладнання ЦП Вхід до JavaLikeCalc, мкс Операція sin(Pi) [у JavaLikeCalc], мкс Операція pow(Pi,2) [у JavaLikeCalc], мкс Модель АГЛКС [Vision, головна мнемосхема], %(ядро) Додаткові тести та зауваження
Segnetics SMH2Gi ARMv5, ARM926EJ-S, 400 MHz, 65nm, SoftVFP, 199 BogoMIPS 3.4 11.1 [14.9] 4.4 [7.9] -
Router 3G TELEOFIS RTU968 ARMv5, ARM926EJ-S, 454 MHz, 65nm, OpenWrt, uCLibC, SoftVFP, 226 BogoMIPS 2.45 7.2 [9.75] 2.02 [5.45] -
NetGear R6220 MIPS1004Kc, MediaTek MT7621ST, 55nm, 880 MHz, 2 Threads 0.84 13 [14.5] 0.99 [4.09] - Productivity of the mathematical operations is VERY low.
ICP DAS LP-5141 ARMv5, PXA270, 520 MHz, FPA 100 [200]* 51 [152]*
ZAO ZEO TionPro270 ARMv5, PXA270, 520 MHz, SoftVFP, uCLibC-0.9.32.1, -Os, 519.37 BogoMIPS 22 [51]* 14 [41]* - Minimum power consumption: 1.27 W
ZAO ZEO TionPro270 ARMv5, PXA270, 520 MHz, SoftVFP, GLibC-2.14.1, -O2, 519.37 BogoMIPS 5.92 [8.26] 1.74 [4.08] - Updated: 30.10.2013
Cyrix Geode(TM) x86, 232 MHz 7 [44]* 11 [52]* -
VIA Nehemiah x86, 400 MHz, 130nm 2.9 [5.8] 2.4 [5.8] -
Nokia N800 ARMv6, TI OMAP2420, 90nm, 400 MHz, 397 BogoMIPS 2.32 2.93 [6.29] 2.11 [6.98] -
Raspberry Pi ARMv6, BCM2708, 700 MHz 1.15 [4.57] 1.28 [4.60] -
Raspberry Pi Zero ARM v6Z ARM1176JZF, BCM2835, 65nm, 1 GHz 1.66 0.862 [1.4] 0.979 [2.29] >100 Minimum power consumption (on 700MHz): 0.4W, 0.6W(+WIFI)
RT-tests:[!] precision_test[!] OpenSCADA[!]
Linux 4.19.66+ 0.353+3.04 [0.052] 0.494+1.362, 0.53+1.375
AMD K6-2 x86, 450 MHz, 250nm, 900 BogoMIPS, SDRAM-85MB/s 1.76 0.964 [2.14] 1.84 [2.84] -
VIA Nehemiah x86, 667 MHz, 130nm 2.7 [5.6]* 2.4 [6.1]* -
AMD Geode LX800, ICP-DAS LP-8x81 x86, 500 MHz, 130nm, 1000 BogoMIPS, DRAM-450MB/s 1.09 1.15 [1.57] 1.87 [2.33] 97
RT-tests:[!] precision_test[!] OpenSCADA[!]
Linux-3.2.78 0.07+0.73 [0.038] 0.337+4.12, 0.303+3.21
Linux-2.6.29-rt1-up 0.046+0.164 [0.037] 0.089+0.095, 0.090+0.093
AMD K6-2+ x86, 600 MHz, 180nm, 1202 BogoMIPS, SDRAM-99MB/s 1.73 0.69 [0.97] 1.2 [1.72] -
RDC R3600, ICP-DAS LX-8x31 x86, 1.0 GHz, 2 Cores 0.72 (1.52) 1.14 (2.06) -
Nokia N900 ARM Cortex-A8, TI OMAP3430, 65nm, 600 MHz, 598.9 BogoMIPS 1.07
0.64 		1.59 [1.79]
0.96 [1.06] 		0.89 [1.32]
0.53 [0.76] 		>100 600 MHz
1000 MHz
Updated: 15.07.2023
BL-5J Grand: 4.1mA (1.24Ah/300h), 7.2mA (+SIM, 1.238Ah/171h), 11mA (+WLAN, 1.226Ah/116h)
Nokia N950, N9 ARM Cortex-A8, TI OMAP3630, 45nm, 1 GHz 0.52 0.91 [1.68] 0.6 [0.91] >100
Segnetics SMH4 ARMv7 Processor rev 2, 1 GHz, 996 BogoMIPS 0.477 1.1 [1.323] 0.51 [0.723] -
Raspberry Pi 2 ARM Cortex-A7, BCM2836, 40nm, 900 MHz, 4 Cores 0.77 0.688 [0.95] 0.447 [0.83] 100 [165] Minimum power consumption (on 600MHz): 1.02W, 1.14W (+Eth), 1.33W(+WIFI)
RT-tests:[!] precision_test[!] OpenSCADA[!]
Linux 4.9.35-v7+ 0.23+4.18 [0.016] 0.385+0.918, 0.484+4.772
Orange Pi Zero ARM Cortex-A7, Allwinner H2(+), 40nm, 1.2 GHz, 4 Cores 0.616 0.489 [0.554] 0.625 [0.734] ** - Updated: 04.03.2023
Minimum power consumption (on 240MHz): 0.89W, 1.02W(+Eth), 1.15W(+WIFI)
Performance for 1.29W, 240MHz: GPIO 1.2us
RT: The realtime policies SCHED_RR and SCHED_OTHER are completely missing
Siemens IOT2050 ARM Cortex-A53, TI Sitara AM6548 HS, 28nm, 4 Cores 0.511 0.459 [0.589] 0.45 [0.609] 67 [110] ARM64
Pentium 3 x86, 700 MHz, 180nm, SDRAM-223MB/s 0.546 0.383 [0.875] 0.51 [1.1] 90
RT-tests:[!] precision_test[!] OpenSCADA[!]
Linux-3.2.78-686-pae 1.73+7.22 [0.037] 0.429+32, 0.825+60.7
Linux-3.2.78-rt-686-pae 0.11+0.15 [0.041] 0.125+0.184, 0.079+0.17
Intel(R) Atom(TM) CPU Z520, ICP-DAS LP-8x81 Atom x86, 1.33 GHz, 1[2] Cores, 45nm 0.39 (1.14) 0.53 (1.12) -
Intel Atom N270 x86, 1.6 GHz, 1[2] Cores, 45nm, DDR2-533-1.2GB/s 0.441 0.392 [0.616] 0.403 [0.712] 73 [135]

Starting time (PATA SSD), seconds: 6+28+6(AGLKS), 65(Boiler)

RT-tests:[!] precision_test[!] OpenSCADA[!]
Linux-4.9.210-686-pae 112.0+112.1 [0.037] 112.0+112.0, 113.3+113.3
Linux-4.9.210-rt-686-pae 0.126+0.199 [0.032] 0.102+0.164, 0.097+0.162
Raspberry Pi 3 ARM v8 Cortex-A53, BCM2837, 40nm, 1.2 GHz, 4 Cores 0.44
0.33 		0.372 [0.436]
0.303 [0.4] 		0.335 [0.443]
0.304 [0.41] 		54 [94] ARMHF
ARM64
Updated: 03.03.2023
Minimum power consumption (on 600MHz and indifferent to enabled WIFI or Bluetooth): 1.14W, 1.39W(+Eth), 1.5W(+WIFI)
Performance for 1.8W, 600MHz: GPIO 0.3us

Starting time (JGM-T001), seconds: 14+42+5(AGLKS), 98(Boiler)

RT-tests:[!] precision_test[!] OpenSCADA[!]
Linux 4.9.35-v7+ 0.045+0.102 [0.088] 0.492+0.514, 0.456+0.657
PinePhone ARM v8 Cortex-A53, Allwinner A64, 40nm, 1.15 GHz, 4 Cores 0.369 0.316 [0.393] 0.311 [0.390] 50 [80] Mobian 12 ARM64
Intel(R) Celeron(R) CPU 847 x86, 1.1 GHz, 2 Cores, 32nm 0.23 [0.675] 0.25 [0.76] 50 [64]
AMD GX-209JA x86, 1.0 GHz, 2 Cores, 28nm, DDR3-533-2GB/s 0.203
0.411 		0.204 [0.427]
0.283 [0.659] 		0.175 [0.397]
0.34 [0.84] 		48 [87]
65 [110] 		x86_64
686
HTC Desire 820G ARM Cortex-A7, MediaTek MT6592, 28nm, 1.7 GHz, 8 Cores 0.420 0.233 [0.298] 0.204 [0.337] -
KIVI 32F710 ARMv7, MediaTeK m5621, 1.3 GHz, 4 Cores 0.243 0.262 [0.272] 0.229 [0.257] -
AMD Phenom(tm) 9600 Quad-Core x86, 2.3 GHz, 4 Cores, 65nm 0.17 [0.45] 0.14 [0.35] -
AMD Athlon 64 3000+ x86, 2 GHz, 130nm 0.15 [0.43] 0.16 [0.49] 23 [31]
Intel(R) Celeron(R) CPU N2840 x86, 2.16GHz, 2 Cores, 22nm 0.175 [0.389] 0.165 [0.385] 33 [60]
Intel(R) Pentium(R) 4 CPU x86, 3 GHz, 1[2] Cores, DDR-400 0.198 0.152 [0.206] 0.157 [0.253] 45 [77]
Google Asus Nexus7 II ARM Cortex-A15, Qualcomm Snapdragon APQ8064-1AA, 28nm, 1.5 GHz, 4 Cores 0.321 0.134 [0.239] 0.122 [0.264] 54 [82]

armv7-a, Soft, VFP, Extra tests.
Updated: 15.05.2023
Starting time, seconds: 10+21+6(AGLKS), 49(Boiler)

Intel(R) Core(TM)2 Duo CPU T5470 x86, 1.6 GHz, 2 Cores, 65nm 0.179 0.143 [0.18] 0.129 [0.197] 27.6 [54]
AMD Turion L625 x86, 1.6GHz, 2 Cores, 65nm, DDR2-555 0.096 0.125 [0.251] 0.096 [0.219] 28 [50]
Intel(R) Core(TM) i3-3217U CPU x86, 1.8 GHz, 2[4] Cores, 22nm 0.105 [0.277] 0.148 [0.305] 21 [26]
Intel(R) Pentium(R) CPU U5400 x86, 1.2 GHz, 2 Cores, 32nm, DDR3-1333-2.3GB/s 0.141 0.119 [0.177] 0.088 [0.125] 29 [55]
Intel(R) Core(TM) i3 CPU U 380 x86, 1.33 GHz, 2[4] Cores, 32nm, DDR3-1333 0.11 0.11 [0.138] 0.087 [0.101] 33 [58]
Intel(R) Celeron(R) CPU E1200 x86, 1.6 GHz, 2 Cores, 65nm 0.159 0.126 [0.131] 0.078 [0.087]
AMD Athlon X2 3600+ x86, 2 GHz, 2 Cores, 65nm 0.0898 0.095 [0.148] 0.0743 [0.150] 20 [41]
Google Pixel XL ARMv8, Qualcomm Snapdragon 821, 14nm, 2.15 GHz, 4 Cores 0.125 0.054 [0.083] 0.087 [0.117] - Updated: 07.03.2023
Starting time, seconds: 5+10+2(AGLKS), 26(Boiler)
Intel(R) Xeon(R) CPU E5-2603 x86, 1.8 GHz, 4 Cores, 32nm 0.074 [0.178] 0.068 [0.173] -
Intel(R) Xeon(R) CPU X5560 x86, 2.8 GHz, 4[8] Cores, 45nm 0.056 0.054 [0.117] 0.043 [0.118] 27 [41]
AMD Phenom(tm) II X4 900e x86, 2.4 GHz, 4 Cores, 45nm, DDR2-800-3GB/s 0.069
0.06 		0.075 [0.082]
0.076 [0.096] 		0.056 [0.076]
0.0567 [0.088] 		12 [21]
17 [32] 		x86_64
686
Intel(R) Celeron(R) CPU J3355 x86, 2.0-2.5 GHz, 2 Cores, 14nm, DDR3-1600 0.069 0.066 [0.089] 0.051 [0.077] 19 [34]
Intel(R) Core(TM) i5-3610ME CPU x86, 2.7 GHz, 2[4] Cores, 22nm 0.05 [0.132] 0.0376 [0.122] -
Intel(R) Xeon(R) CPU E5-2420 x86, 1.9 GHz, 32nm, DDR3-10GB/s 0.058 0.056 [0.075] 0.053 [0.075] -
Xiaomy 11 Lite 5G NE ARM Cortex-A55, Qualcomm Snapdragon 778g SM7325, 6nm, 4x2.4 GHz + 4x1.8 GHz 0.0491 0.0325 [0.0415] 0.0511 [0.0689] -
Intel(R) Xeon(R) CPU E5-2680 v3 x86, 2.5 GHz, 32nm, DDR3-9.3GB/s 0.061 0.042 [0.053] 0.031 [0.038] -
AMD A8-6500 APU x86, 3.5 GHz, 4 Cores, 32nm, DDR3-1866-12.8GB/s 0.048
0.058 		0.0394 [0.057]
0.055 [0.1] 		0.029 [0.0394]
0.037 [0.089] 		13 [22]
13 [24] 		x86_64
VBox

Starting time (DT01ACA050), seconds: 3+2+1(AGLKS), 8(Boiler)

Intel(R) Pentium(R) CPU G3260 x86, 3.30GHz, 2 Cores, 22nm, DDR3-1400 0.0485 0.0373 [0.0363] 0.0244 [0.0279] 6.3 [13.3]
Intel(R) Core(TM) i3-4330 CPU x86, 3.5 GHz, 2[4] Cores, 22nm 0.03 [0.08] 0.023 [0.073] -
Intel(R) Core(TM) i7-5600U x86, 2.6->3.2 GHz, 2[4] Cores, 14nm, DDR3-1600-15GB/s 0.04
0.051 		0.027 [0.0304]
0.0488 [0.065] 		0.027 [0.03]
0.0447 [0.068] 		9 [16]
12 [22] 		x86_64
686

Starting time (ST320LT007), seconds: 3+2+1(AGLKS), 6(Boiler)

Intel(R) Core(TM) i7-7700HQ CPU x86, 2.8 GHz, 14nm, DDR-20GB/s 0.036 0.024 [0.029] 0.040 [0.046] **
  • * — включає у себе дворазовий час виклику функції gettimeofday().
  • ** — pow(Pi,2) виміряно у середовищі із GLibC > 2.31 (як то Debian 11), де продуктивність обчислення цієї функції деградована на [46...60]%.
  • "Вхід до JavaLikeCalc" — вхід до процедури на мові JavaLikeCalc також означає вхід до критичної секції та запит на читання RW блокування, відтак цей час переважно відображає продуктивність операції блокування. Цей час виключено із відповідних значень у стовпчиках з JavaLikeCalc.
  • "DDR3-1600-{N}GB/s" — де N отримується програмою sysbench (не memtest, яка часто помиляється), із типовою командою виклику sysbench --test=memory --memory-total-size=3G --memory-block-size=1M run для систем з розміром пам'яті [4...15] ГБ.
  • "precision_test" — проста програма проєкту OpenSCADA для тестування затримки виклику потоків у політиці реального часу Round-robin та пріоритеті 80. 100% навантаження здійснюється програмою highload та активність ВФС командою dd if=/dev/zero of=/var/tmp/test.zero bs=1048576 count=1000; dd if=/var/tmp/test.zero of=/dev/null bs=1048576;.

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

Метода вимірювання для таблиці вище наступна:

1. Оцінка часу обчислення операцій: загального блокування критичної секції, sin(Pi), pow(Pi,2). У другому, третьому та четвертому стовпчиках відповідно. Операції sin() і pow() обрано у якості показових для оцінки продуктивності сопроцесору та загальних маніпуляцій із реальними числами. Значення у квадратних дужках характеризує ступінь накладених витрат під час обчислення всередині віртуальної машини OpenSCADA та продуктивність цілочисельних обчислень довкола зразкових операцій. Тобто, основне значення характеризує продуктивність процесору у операціях із плаваючою точкою (математичний сопроцесор або емуляція), а у квадратних дужках у цілочисельних операціях (центральний процесор) як різниця часу операцій із плаваючою точкою. Метода вимірювання:
a) забезпечуємо стабільність частоти центрального процесору шляхом встановлення політики її керування у ПРОДУКТИВНІСТЬ;
b) запускаємо OpenSCADA без навантаження — проєкт по замовчанню або з порожньою конфігурацією, з конфігуратором UI.QTCfg, UI.WebCfg або UI.WebCfgD;
c) відкриваємо об'єкт функції sin(), а потім pow(), модуля бібліотеки математичних функцій;
d) переходимо до вкладки "Виконати", встановлюємо "Включено", вводимо значення аргументам "X" у 3.14159 та "Ступінь" у 2 (для pow()), встановлюємо кількість запусків у 1000 — для більшої репрезентативності можна збільшити, порядками, до загального часу операції не більш 10 секунд;
e) натискаємо "Виконати" та отримуємо час виконання;
f) натискаючи "Виконати" здійснюємо обчислення декілька разів, чим домагаємося мінімального значення;
g) фіксуємо мінімальне значення яке ділимо на 1000 (кількість запусків) та отримуємо основне значення часу одного обчислення у мікросекундах;
h) переходимо до об'єкту модуля внутрішніх обчислень OpenSCADA (DAQ.JavaLikeCalc);
i) створюємо там об'єкт бібліотеки функцій "test" і функцію "test" у ній, які вмикаємо;
j) у вкладці "Програма" вводимо текст команд послідовно із вимірюванням їх часу: ПОРОЖНЬО, y=sin(3.14159), y=pow(3.14159, 2);
k) вимірювання здійснюємо тричі у вкладці "Виконати" і за методою у пунктах "d."-"g.";
l) перший отриманий результат для ПОРОЖНЬО записуємо у другому стовпчику та вважаємо допоміжним для подальших; другий і третій результати записуємо у квадратних дужках відповідно третього та четвертого стовпчика, і після віднімання значення першого-допоміжного результату.
2. Комплексна оцінка продуктивності, п'ятий стовпчик, здійснюється шляхом виконання моделі технологічного процесу (ТП) АГЛКС на цільовій архітектуру. Цей тест може виконуватися тільки на обчислювальних системах із порівняно високою продуктивністю або із кількістю ядер більш за одне, які спроможні виконувати модель, та із пристроєм виводу графічної інформації — дисплей (виконання серверу візуалізації не розглядається). Основне значення навантаження процесору характеризує виконання динамічної моделі ТП, а додаткове додає формування та виконання графічного інтерфейсу. Метода вимірювання:
a) забезпечуємо стабільність частоти центрального процесору шляхом встановлення політики її керування у ПРОДУКТИВНІСТЬ;
b) із меню оточення робочого простору запускаємо модель АГЛКС;
c) запускаємо емулятор терміналу (наприклад, "konsole"), де набираємо "top", натискаємо Shift+H (дивимося процес в цілому) та Shift+P (сортуємо за навантаженням на процесор);
d) знімаємо покази у колонці "%CPU" напроти процесу "openscada", відбираємо типове значення для декількох оновлень та фіксуємо його як основне значення;
e) повертаємося до вікна OpenSCADA та запускаємо середовище візуалізації, а потім проєкт інтерфейсу "АГЛКС".
f) повертаємося до емулятору терміналу та знімаємо додаткове значення, як у пункті "d.".

Отримані результати можете надіслати на електронну пошти для розміщення у цій таблиці!

8.2 Сховища (вбудовані, HDD, SSD, CF, SD, ...)

У цьому розділі міститься інформація про продуктивність сховищ, з якими та на яких працювали та працюють рішення OpenSCADA.

Обладнання Реальний розмір, ГБ/ГіБ Читання/Запис, МБ/с Зауваження
SSD
PATA SSD, Ver2.M0J (Acer Aspire One 110) 41.2/15.8
SSD: GoodRAM Play 32GB 2.5" SATA2, MLC (SSD32G25S2MGYSM2244) 238/45
SSD: GoodRAM C40 60GB 2.5" SATA3, MLC (SSDPR-C40-060) 498/467
SSD: GoodRAM C40 120GB 2.5" SATA3, MLC (SSDPR-C40-120) 480/330 for EXT4
SSD: GoodRAM CX200 120GB 2.5" SATA3, TLC (SSDPR-CX200-120) 120/111 497/118 fast overheating on write 30+10 °С
SSD: GoodRAM IRIDIUM 120GB 2.5" SATA3, MLC (SSDPR-IRID-120) 120/111 499/201 heating 33+3/11 °С
SSD: TOSHIBA THNSNJ512GCSU 512GB 2.5" SATA3, MLC (JULA0101) 512/477 525/517 heating 32+4/10 °С
SSD: GoodRAM IRDM PRO 1TB 2.5" SATA3, 3D TLC (IRP-SSDPR-S25C-01T) 1024/954 533/509 heating 25+5/10 °С
SSD: KODAK SSD X120 PRO 1TB 2.5" SATA3, 3D TLC (EKSSD1TX120K) 1024/954 505/427 heating 31+2/6 °С
power 0.7+0.2/0.4 W
HDD. Typical environment: Read/Write: raw 50GB by blocks 1MiB, into the hard disk end
HDD 3.5": SAMSUNG SP2004C 200/186 39/38.5 heating 27+11/13.5/15°С
HDD 3.5": TOSHIBA DT01ACA050 500/466 110/109 heating 25+12/16/17°С
HDD 3.5": WDC WD10EZRX-00D8PB0 1000/931 77.7/77.5 +9°С, noisely seek
HDD 3.5": Seagate ST1000VM002-1ET1 1000/931 87.1/86.9 heating 27+7/9/10 °С; power ~5.6 W
HDD 2.5": Seagate ST320LT007-9ZV142 320/298 70.5/70.1 heating 25+10/17/18 °С; power 1.4+1.6/1.6 W
HDD 2.5": WDC WD5000BEVT-22A0RT0 500/466 44.7/43.5 heating 33+3/9/13 °С; power 1.0+1.9/2.3 W
HDD 2.5": WDC WD20SPZX-22UA7T0 2000/1863 63.2/62.3 heating 33+9/13/15 °С; power 1.26+1.74/1.74 W
Internal flashes of the devices
Flash: ICP_DAS LP-8x81 Internal 4GB 8/4
Card flashes (CF)
CF: ICP_DAS LP-8x81 8GB, MLC 27/(19...15)
CF: ICP_DAS LP-8x81 8GB, MLC-N-233x 44/12.5
CF: ICP_DAS LP-8x81 8GB, pSLC 47/44
Flash Disk IDE44: Kontron chipDISK/1000-IDE 3/5.7

SD, MiniSD, MicroSD, MMC. Typical environment. 30°C, Read/Write: raw 1GB by blocks 1MiB.
Card Readers: [ Grand X CRX45 USB2; Realtec USB 2.0 multicard reader; Transcend M3; GoodRam USDRSGRBL10; Raspberry Pi3,2 EXT4; RTS5227 PCI-E ]

MicroSD: Transcend 8GB Class 2, 378010 7.94/7.40 [14.6/3.4; 9/3.5; 14.3/3.7; 14.3/3.7]
MicroSD: EMTEC 8GB Class 4 7.96/7.41 [18.0/0.8; 12.3/1.8; 17.2/1.8; 17.0/1.9] early and apparently overheat and hang in long time on write
MicroSD: Kingston 8GB Class 4, SDC4/8GB 7.74/7.21 [16.7/0.756; 15.1/1.8; 16.4/1.8; 16.5/1.9] early and apparently overheat and hang in long time on write
MicroSD: Transcend 8GB Class 4, A31213 7.94/7.40 [17.8/4; 18.0/4.1; 18.8/4.2; 17.9/3.0]
MicroSD: Transcend 32GB Class 4, 9161BA 19.7/6.7
MicroSD: Transcend 4GB Class 6, 9153BA 4.03/3.75 [15.7/6.7; 15.9/7.6; 18.5/9.3; 17.9/9.5]
SD: Team 8GB Class 10, CT8G02XTVCC1118N 8.03/7.47 [16.7/10.3; 14.1/12.2; 18.5/14.0]
MicroSDHC: Toshiba 16GB UHS-1 Class 10, SD-C016UHS1(BL5A) 15.7/14.6 [16.2/5.9; 16.7/7.4; 18.4/9.1; 17.6/8.8; 16.9/11.3]
MicroSDHC: Toshiba 16GB UHS-1 Class 10, SD-C016UHS1(6A) 15.5/14.5 [14.4/6.7; 17.3/8.1; 18.6/9.9; 17.9/10.0; 19.5/13.0]
MicroSDHC/MicroSDXC: Kingston 16GB UHS-1 Class 10, SDC10G2/16GB 15.5/14.4 [18.6/6.0; 16.3/6.7; 18.5/10.5; 18.1/10.1; 17.1/8.6]
MicroSDHC: Transcend 16GB UHS-1 Class 10, C93858 15.9/14.8 [17.2/10.6; 18.6/9.6; 18.5/11.1; 17.7/10.8; 22.5/11.1]
MicroSDHC: SP 32GB, SP032GBSTH010V10 31.1/28.9 [18.1/8.0; 14.8/7.3; 18.7/10.8; 17.9/9.8; 19.4/11.1]
MicroSDHC: SanDisk Ultra 32GB, SDSQUNB-032G-GN3MN 31.1/28.9 [17.1/7.0; 14.8/7.5; 18.4/11.0; 18.1/10.4; -]
MicroSDHC: Transcend 32GB UHS-1 Class 10, Premium 400x D24035 31.7/29.5 [17.6/14.7; 17.8/9.6; 18.8/9.9; 17.8/14.1; 22.4/10.5; 21.5/15.3]
MicroSDHC: JGM-T001 16GB UHS-1 Class 10 15.6/14.6 [18.6/19.3; 16.1/12.7; 19.6/17.4; 15.7/18.4; 13/11.8; 58.4/41.7]
MicroSDHC: Samsung EVO Plus 64GB UHS-1 Class 10 (MB-MC64H) 64.1/59.7 [19.0/19.8; 18.8/11.6; ; ; 21.7/16.3; 93.7/28.6]
MicroSDHC: Samsung EVO Plus 128GB UHS-3 Class 10 (MB-MC128H) 128/119 [19.1/18.9; ; ; ; 22.1/17.8; 90.5/44.8]
MicroSDHC: Samsung PRO Plus 128GB UHS-3 Class 10, A2, V30 (MB-MD128KA) 128/119 [ ; ; ; ; 22/18.1; 92.6/49.0]

9 Промислові рішення — ПЛК+ВВ, Панельні ПК

У цьому розділі міститься інформація про моделі ПЛК та Панельних ПК, реально побудованих або проєктованих на основі розробленого середовища виконання та прошивки ПЛК.

Компоненти ПЛК Ціна (DDP), $ Зауваження
PC/104
CPU: Kontron MOPSlcdLX 430 AMDGeodeLX800(i686)-500MHz, 0°-60°C, 5W, Video
CPU: Diamond ATHM800-256A 1229 VIA Mark(i686)-800MHz, 256Mb, -40°-85°C, 10W, Video, 16AI, 4AO, 24DIO
CPU: Diamond ATHM800-256N 842 VIA Mark(i686)-800MHz, 256Mb, -40°-85°C, 10W, Video
CPU: Rhodeus RDS800-LC 414 AMDGeodeLX800(i686)-500MHz, -20°-70°C, 5W, Video
CPU: Helios HLV800-256AV 772 Vortex86DX(i486)-800MHz, 256Mb, -40°-85°C, 5.4W, Video, 16AI, 4AO, 40DIO
CPU: Helios HLV800-256DV 387 Vortex86DX(i486)-800MHz, 256Mb, -40°-85°C, 4.5W, Video
CPU: Tri-M VSX104 380 Vortex86SX(i486sx)-300MHz, 128Mb, -40°-85°C, 2W
MEM: DDR-SODIM-256M 15 for Kontron MOPSlcdLX
Flash Disk: Kontron chipDISK/1000-IDE 100 1Gb, 0°-70°C, read=3MB/s, write=5.7MB/s
Flash Disk: M-Systems MD1171-D1024 42 1Gb, 0°-70°C
Flash Disk: M-Systems MD1171-D256 22 256Mb, 0°-70°C
Flash Disk: M-Systems MD1171-D128 18 128Mb, 0°-70°C
Flash Disk: Diamond systems FD-128R-XT 82 128Mb, -40°-85°C
Flash Disk: Diamond systems FD-1GR-XT 168 128Mb, -40°-85°C
Box: PB-300-K 108
Box: PB-EAP-300-K 250
Box: CT-4 156
Power unit: MMEANWELL DR-4505 30
IO: DMM-16-AT (16AI, 4AO, 16DIO) 581 -40°-85°C
IO: DMM-32X-AT (32AI, 4AO, 24DIO) 689 -40°-85°C
RS485: EMM-OPT4-XT 396 -40°-85°C
RS232->RS485 10
ICP DAS LP-8x81
CPU: LX-9781 ~1500 E3845 4Core-1.91GHz, -25°-60°C, 20.4W, 32GB SSD, 16GB CF, 4GB DDR3, Video, 2xEthernet1G, 4xUSB2, 7-slots, 1xRS-232, 1xRS-485, 2xRS-232/485
CPU: LP-9821 ~1000 CortexA8-1.0GHz, -25°-75°C, 9.6W, 512MB flash, microSD slot (up to 32GB), 512MB DDR3, Video, 2xEthernet1G, 2xUSB2, 8-slots, 2xRS-232, 1xRS-485, 1xRS-232/485
CPU: LX-8731 ~1100 x86 2Core-1.0GHz, -25°-75°C, 16.8W, 32GB SSD, 16GB CF, 2GB DDR3, Video, 2xEthernet1G, 2xUSB2, 7-slots, 2xRS-232, 1xRS-485, 1xRS-232/485
CPU: LP-8821 ~650 CortexA8-1.0GHz, -25°-75°C, 9.6W, 512MB flash, microSD slot (up to 32GB), 512MB DDR3, Video, 2xEthernet1G, 2xUSB2, 8-slots, 2xRS-232, 1xRS-485, 1xRS-232/485
CPU: LP-8381 (deprecated) 974 AMDGeodeLX800(i686)-500MHz, -25°-75°C, 14W, 4GB flash (R/W: 8/4 MB/s), 8GB CF (R/W: 29/19 MB/s), 1GB SRAM, Video, 2xEthernet, 2xUSB, 3-slots, 2xRS-232, 1xRS-485, 1xRS-232/485
CPU: LP-8781 (deprecated) 1025 AMDGeodeLX800(i686)-500MHz, -25°-75°C, 16W, 4GB flash (R/W: 8/4 MB/s), 8GB CF (R/W: 29/19 MB/s), 1GB SRAM, Video, 2xEthernet, 2xUSB, 7-slots, 2xRS-232, 1xRS-485, 1xRS-232/485
CPU: LP-8781-Atom (deprecated) 1438 IntelAtomZ520-1.3GHz, -25°-75°C, 18W, 8GB flash, 1GB DDR2, Video, 2xEthernet, 4xUSB, 7-slots, 2xRS-232, 1xRS-485, 1xRS-232/485
IO_BOX: I-87K9 ~124 IO box for 9 modules series I-87k accessible by DCON
IO: I-8017HW (8AI DE, 16AI SI) 230 Parallel bus, acquisition up to the 30 kHz
IO: I-8042W (16DI + 16DO) 121 Parallel bus.
IO: I-87017ZW (20/10AI) 209 Serial bus. Overvoltage support up to 240V.
IO: I-87019RW (8AI) 213 Serial bus. Additional surge protection, support for thermocouples and resistance thermometers.
IO: I-87024W (4AO) 204 Serial bus. Output of current and voltage.
IO: I-87026PW (6AI, 2AO, 2DI, 2DO) 215 Serial bus. Combined module.
IO: I-87040W (32DI) 121 Serial bus. Isolated.
IO: I-87041W (32DO) 109 Serial bus. Isolated. Watchdog function for communication.
IO: I-87057W (16DO) 82 Serial bus. Watchdog function for communication.
Panel PC and Displays
cMT-iPC15 ~1200 WEINTEK Panel PC 15" (1024x768), -0°-50°C, 32 GB (SSD), 4GB, Intel Atom E3827, Ethernet1G, 3xUSB
cMT-iPC10 ~790 WEINTEK Panel PC 9.7" (1024x768), -0°-50°C, 32 GB (SSD), 4GB, Intel Atom E3827, Ethernet1G, 3xUSB
PPC-L106T ~880 Advantech Panel PC 10.4" (800x600@262K), AMDGeodeLX800(i686)-500MHz, 65W, Ethernet, 3xRS-232, 1xRS-232/485, 4xUSB
PPC-L61T ~600 Advantech Panel PC 6.4" (640x480@262K), AMDGeodeLX800(i686)-500MHz, 65W, Ethernet, 3xRS-232, 1xRS-232/485, 4xUSB
FPM-7151T-R3AE ~960 Industrial display 15".
Retrieved from "http://oscada.org/wiki/index.php?title=Sub-projects/Embedding_and_PLC/uk&oldid=87241"