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 • ‎российский • ‎українська
Назва Заснування Стан Учасники Опис Іконка
Загальне вбудовування OpenSCADA та програмовані логічні контролери (ПЛК) Жовтень 2008 At.png Постійне доповнення на предмет: Роман Савоченко

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

PLC Kontron MOPSlcdLX.png

Сучасні системи автоматизованого керування технологічними процесами (АСУ ТП) є достатньо складними. Умовно ієрархію АСУ ТП можна поділити на два рівня: нижній та верхній рівень. Нижній рівень АСУ ТП містить польове обладнання (давачі та виконавчі механізми), а також програмовані логічні контролери (ПЛК). Верхній рівень представляє себою систему оперативної візуалізації та контролю за технологічним процесом — 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 та 10004);
    • інтерфейс управління 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 та 10004);
  • інтерфейс управління 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".

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

[root@localhost ~]# 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 під власні потреби.

# Додання перемикання розкладок клавіатури: Англійська, Російська, Українська
$ echo "-option grp:lctrl_lshift_toggle -variant ,winkeys,winkeys -layout us,ru,ua -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 та 10004);
    • інтерфейс управління 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 та може ще чогось), вимикається та мережа працює у режимі "Pool", що повільніше. Можливо вимкнення цього переривання відбувається і з "via_rhine", а він не може працювати у режимі "Pool", чому і пакети у/із мережі не ходять. Проблема пов'язана із відмовою та генерацією необроблених переривань одним із обладнань на переривані 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 Дистрибутив 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 Ви можете знайти за цим посиланням.

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

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

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

6.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/{назва пакету}/"

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

7 Вимірювання продуктивності

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

Обладнання Вхід до JavaLikeCalc, мкс** Операція sin(Pi) [у JavaLikeCalc], мкс Операція pow(Pi,2) [у JavaLikeCalc], мкс Модель АГЛКС [Vision, головна мнемосхема], %(ядро) Додаткові тести та зауваження
ARM
Segnetics SMH2Gi (ARM926EJ-S, 400 MHz, 65nm SoftVFP, 199 BogoMIPS) 3.4 11.1 [14.9] 4.4 [7.9] -
Router 3G TELEOFIS RTU968 (ARM926EJ-S, 454 MHz, 65nm, OpenWrt, uCLibC, SoftVFP, 226 BogoMIPS) 2.45 7.2 [9.75] 2.02 [5.45] -
ICP DAS LP-5141 (PXA270, 520 MHz, FPA) 100 [200]* 51 [152]*
ZAO ZEO TionPro270 (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 (PXA270, 520 MHz, SoftVFP, GLibC-2.14.1, -O2, 519.37 BogoMIPS) 5.92 [8.26] 1.74 [4.08] - Last update: 30.10.2013
Nokia N800 (TI OMAP2420, ARMv6, 90nm, 400 MHz, 397 BogoMIPS) 2.32 2.93 [6.29] 2.11 [6.98] -
Raspberry Pi (BCM2708, ARMv6, 700 MHz) 1.15 [4.57] 1.28 [4.60] -
Nokia N900 (TI OMAP3430, CortexA8, 65nm, 600 MHz, 598.9 BogoMIPS) 1.23 1.55 [1.9] 0.932 [1.38] >100
Nokia N950 (TI OMAP3630, CortexA8, 45nm, 1 GHz) 0.90 [2.02] 0.552 [1.81] >100 Last update (Turbo N900): 02.11.2013
Raspberry Pi 2 (BCM2836, ARMv7, 1 GHz, 4 Cores) 0.525 0.615 [0.955] 0.41 [0.875] 85 [154] Minimum power consumption (on 600MHz): 1.02, 1.14 (+Eth), 1.33(+WIFI)
Orange Pi Zero (Allwinner H2(+), Cortex A7, 1.2 GHz, 4 Cores) 0.483 0.497 [0.757] 0.33 [0.627] - Minimum power consumption (on 240MHz): 0.89, 1.02(+Eth)
Raspberry Pi 3 (BCM2837, ARMv8, 1.2 GHz, 4 Cores) 0.379 0.43 [0.496] 0.295 [0.389] 75 [130] Minimum power consumption (on 600MHz and indifferent to enabled WIFI or Bluetooth): 1.14, 1.39(+Eth)
HTC Desire 820G (MediaTek MT6592, Cortex-A7, 28nm, 1.7 GHz, 8 Cores) 0.416 0.237 [0.315] 0.236 [0.342] -
Asus Nexus7 II (Qualcomm Snapdragon APQ8064-1AA, Cortex-A15, 28nm, 1.5 GHz, 4 Cores) 0.497 0.161 [0.306] 0.126 [0.341] 54 [82] armv7-a, Soft, VFP. Extra tests.
x86
Cyrix Geode(TM) (232 MHz) 7 [44]* 11 [52]* -
VIA Nehemiah (400 MHz, 130nm) 2.9 [5.8] 2.4 [5.8] -
AMD K6-2 (504 MHz, 250nm, 1008 BogoMIPS, BUS 112 MHz) 1.136 [4.66] 1.602 [5.63] -
AMD Geode LX800, ICP-DAS LP-8x81 (500 MHz, 130nm, 1000 BogoMIPS) 1.04 1.27 [1.66] 2.03 [2.61] -
VIA Nehemiah (667 MHz, 130nm) 2.7 [5.6]* 2.4 [6.1]* -
RDC R3600, ICP-DAS LX-8x31 (1.0 GHz, 2 Cores) 0.72 (1.52) 1.14 (2.06) -
Intel(R) Atom(TM) CPU Z520, ICP-DAS LP-8x81 Atom (1.33 GHz, 1[2] Cores, 45nm) 0.39 (1.14) 0.53 (1.12) -
Intel Atom N270 (1.6 GHz, 1[2] Cores, 45nm, DDR2-533-1.6GB/s) 0.374 0.416 [0.613] 0.418 [0.686] 82 [151]
Intel(R) Celeron(R) CPU 847 (1.1 GHz, 2 Cores, 32nm) 0.23 [0.675] 0.25 [0.76] 50 [64]
AMD Phenom(tm) 9600 Quad-Core (2.3 GHz, 4 Cores, 65nm) 0.17 [0.45] 0.14 [0.35] -
AMD Athlon 64 3000+ (2 GHz, 130nm) 0.15 [0.43] 0.16 [0.49] 23 [31]
AMD Athlon X2 3600+, (2 GHz, 2 Cores, 65nm) 0.145 [0.42] 0.153 [0.46] 25 [47]
Intel(R) Celeron(R) CPU N2840 (2.16GHz, 2 Cores, 22nm) 0.175 [0.389] 0.165 [0.385] 33 [60]
Intel(R) Pentium(R) 4 CPU (3 GHz, 1[2] Cores, DDR-400) 0.198 0.152 [0.206] 0.157 [0.253] 45 [77]
Intel(R) Core(TM)2 Duo CPU T5470 (1.6 GHz, 2 Cores, 65nm) 0.179 0.143 [0.18] 0.129 [0.197] 27.6 [54]
AMD Turion L625 (1.6GHz, 2 Cores, 65nm, DDR2-555-1.8GB/s) 0.096 0.125 [0.251] 0.096 [0.219] 28 [50]
Intel(R) Core(TM) i3-3217U CPU (1.8 GHz, 2[4] Cores, 22nm) 0.105 [0.277] 0.148 [0.305] 21 [26]
Intel(R) Core(TM) i3 CPU U 380 (1.33 GHz, 2[4] Cores, 32nm, DDR3-1333-4.8GB/s) 0.104 [0.257] 0.0985 [0.244] 36 [52]
Intel(R) Xeon(R) CPU E5-2603 (1.8 GHz, 4 Cores, 32nm) 0.074 [0.178] 0.068 [0.173] -
AMD Phenom(tm) II X4 900e (2.4 GHz, 4 Cores, 45nm, DDR2-800) 0.067 0.099 [0.1] 0.0567 [0.126] 17 [32]
Intel(R) Core(TM) i5-3610ME CPU (2.7 GHz, 2[4] Cores, 22nm) 0.05 [0.132] 0.0376 [0.122] -
AMD A8-6500 APU (3.5 GHz, 4 Cores, 32nm, DDR3-1866-5.8GB/s) 0.0581 0.0425 [0.0572] 0.028 [0.0442] 14 [24]
Intel(R) Core(TM) i7-5600U (2.6->3.2 GHz, 2[4] Cores, 14nm, DDR3-1600-15GB/s) 0.0445 0.0288 [0.0326] 0.0266 [0.0306] 13.6 [20.5]
Intel(R) Core(TM) i3-4330 CPU (3.5 GHz, 2[4] Cores, 22nm) 0.03 [0.08] 0.023 [0.073] -
* — Включає в себе дворазовий час виклику функції gettimeofday().
** — Вхід до процедури на мові JavaLikeCalc також означає вхід до критичної секції та запит на читання RW замку відтак цей час переважно відображає продуктивність цієї операції. Цей час виключено з відповідних значень у стовпчиках з JavaLikeCalc.

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

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

7.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 °С
HDD. Typical environment: Read/Write: raw 50GB by blocks 1MiB, into end of the hard disk
HDD 3.5": SAMSUNG SP2004C 200/186 39/38.5 heating 27+11/13.5/15°С
HDD 3.5": TOSHIBA DT01ACA050 85.4/84.4 +18°С
HDD 3.5": WDC WD15EARX-00PASB0 43/45.5 +11°С
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 °С
HDD 2.5": WDC WD5000LPVX-22V0TT0 497/463 62.1/61.7 heating 33+5/9/11 °С
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 USB 2.0 multicard reader; Realtec USB 2.0 multicard reader; Transcend Multi-Card Reader M3; GoodRam MicroSD USDRSGRBL10; Raspberry Pi2 MicroSD for EXT4 ]

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]


8 Рішення ПЛК

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

Компоненти ПЛК Ціна (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: LP-8381 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 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 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 155 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.
Segnetics SMH 2Gi
CPU: SMH 2Gi-0020-31-2 335 ARM9-200MHz, LCD-display, 1xRS-485, 1xRS-232, 2xUSB, 1xEthernet, 3DO
IO: MC-0402-01-0 (8AI, 4AO, 9DI, 10DO) 176 Single MC RS-485 serial bus.
IO: MR-120-00 (12DI[opt]) 92 Multiple MR RS-485 serial bus.
IO: MR-800-00 (8DO[rel]) 103 Multiple MR RS-485 serial bus.
IO: MR-810-00 (8DI[opt,~]) 82 Multiple MR RS-485 serial bus.
IO: MR-061-00 (6DO[sim,opt]) 84 Multiple MR RS-485 serial bus.
IO: MR-602-00 (6DO[rel], 2AO[opt]) 120 Multiple MR RS-485 serial bus.
IO: MR-504-00 (5DO[rel], 4AO[opt]) 120 Multiple MR RS-485 serial bus.