Від керування, орієнтованого на ПЛК, до автоматизації, визначеної програмним забезпеченням
Промислова автоматизація виходить за межі традиційної моделі спеціалізованих ПЛК, мікроконтролерів і машин із фіксованими функціями. Сучасні системи дедалі частіше поєднують керування на основі ПЛК із високопродуктивними MPU та SoC для роботи з HMI, машинним зором, периферійною аналітикою, підключенням, цифровими двійниками та робочими навантаженнями ШІ.
Ця еволюція не робить традиційні архітектури керування застарілими. Натомість вона створює багаторівневу архітектуру, у якій ПЛК можуть і надалі виконувати детерміноване керування на польовому рівні, тоді як високопродуктивні обчислювальні платформи виконують супервізорні, аналітичні функції, візуалізацію та функції ШІ.
З інженерної точки зору важливо не просто додати обчислювальну потужність. Справжній виклик полягає в тому, щоб гарантувати: додаткові робочі навантаження не можуть порушити часові характеристики, доступність або цілісність усталених функцій керування.
Фізичний ШІ створює новий виклик для автоматизації
Запровадження фізичного ШІ ускладнює архітектуру системи, оскільки інформація, згенерована ШІ, може впливати на фізичне обладнання та операційні рішення.
Модель ШІ може виявити ненормальний стан машини, виявити візуальну аномалію, підтримати прогнозне інспектування або виявити стан, пов’язаний з оператором. Однак результат логічного висновування ШІ є лише однією частиною повного ланцюга автоматизації.
Система все одно має отримувати інформацію від датчиків, виконувати модель ШІ, перевіряти робочий контекст, застосовувати заздалегідь визначені політики керування та передавати отриманий стан відповідній програмі або оператору.
Тому, на мою думку, промисловий ШІ слід розглядати як робоче навантаження для підтримки прийняття рішень або контрольованого реагування, а не як ізольований інтелектуальний рівень. Навколишня платформа автоматизації визначає, чи можна обробити інформацію від ШІ та вжити заходів на її основі в межах необхідних часових і безпекових обмежень.
Робочі навантаження зі змішаною критичністю потребують справжньої ізоляції
Сучасні багатоядерні процесори дають змогу об’єднати функції, для яких раніше були потрібні окремі апаратні платформи. Тепер одна обчислювальна система може підтримувати керування в режимі жорсткого реального часу, служби HMI, мережеві функції, діагностику, журналювання подій, машинний зір, аналітику та логічне висновування ШІ.
Ці робочі навантаження не мають однакових вимог.
Завдання керування в режимі жорсткого реального часу може мати суворий кінцевий термін виконання. HMI може допускати інші часові характеристики, тоді як процес логічного висновування ШІ може потребувати значних ресурсів ЦП. Мережеві служби також створюють зовнішні канали зв’язку, які не повинні мати необмеженого доступу до критичних ресурсів.
Отже, просте розміщення кількох застосунків на багатоядерному процесорі автоматично не створює відмовостійкої архітектури.
Операційне середовище має забезпечувати механізми для часового розділення, захисту пам’яті, контролю ресурсів та ізоляції несправностей.
Консолідація апаратного забезпечення не дорівнює відмовостійкості
Консолідація апаратного забезпечення може зменшити кількість обчислювальних платформ, спростити підключення та посилити інтеграцію. Однак вона також створює потенційну спільну точку відмови.
Якщо непов’язані робочі навантаження спільно використовують той самий процесор і операційне середовище, несправний драйвер, некерований застосунок, помилка пам’яті або скомпрометована служба можуть вплинути на інші функції, якщо програмна архітектура не встановлює належних меж.
Це один із найважливіших аспектів модернізації застарілих систем автоматизації.
Мета не повинна полягати лише в розміщенні більшої кількості функцій на меншій кількості процесорів. Мета полягає в консолідації робочих навантажень без створення неприйнятних залежностей між ними.
Операційна система стає рівнем забезпечення виконання вимог
В архітектурі автоматизації, визначеній програмним забезпеченням, операційна система вже не є лише платформою, на якій виконуються застосунки.
Вона визначає, як плануються процеси, як захищається пам’ять, як здійснюється доступ до апаратних ресурсів і як окремі служби взаємодіють одна з одною. Ці механізми безпосередньо впливають на здатність системи продовжувати роботу в разі відмови окремого компонента.
Тому відмовостійка архітектура повинна забезпечувати ізоляцію несправної служби та, якщо це допускає проєкт системи, відновлення цієї служби без перезапуску непов’язаних застосунків.
Цей підхід особливо актуальний для промислових систем, де повне перезавантаження системи може перервати операції керування, візуалізації, зв’язку або виробництва.
Чому мікроядерна архітектура має значення
Звичайна монолітна операційна система зазвичай розміщує багато служб, драйверів, файлових систем і мережевих компонентів у високо привілейованому середовищі ядра.
Мікроядерна архітектура використовує інший архітектурний підхід. У ядрі зберігається менший набір фундаментальних функцій, водночас багато драйверів, стеків протоколів, файлових систем і системних служб можуть виконуватися як окремі процеси в захищених адресних просторах.
Для промислової автоматизації ця архітектура може забезпечити кілька корисних властивостей:
- Ізоляція несправностей: Несправний драйвер або служба можуть бути ізольовані від непов’язаних процесів.
- Контрольоване відновлення: Окремі служби можна перезапускати без обов’язкового перезавантаження всієї системи.
- Зменшення обсягу привілейованого коду: Меншій кількості компонентів потрібно працювати з найвищими системними привілеями.
- Ізоляція пам’яті: Захищені адресні простори допомагають запобігти прямому втручанню однієї програми в роботу іншої.
- Підтримка змішаної критичності: Завдання керування в реальному часі можуть співіснувати з робочими навантаженнями HMI, мережевих служб, аналітики та ШІ.
- Технічне обслуговування протягом життєвого циклу: Модульні служби можуть спростити обслуговування та оновлення на рівні компонентів.
Мікроядро не усуває дефектів програмного забезпечення чи вразливостей кібербезпеки. Його цінність полягає у встановленні архітектурних меж, які можуть обмежити наслідки окремих відмов або компрометацій.
Детермінованість у реальному часі залишається фундаментальною вимогою
Промислова модернізація не повинна дозволяти вимогам ШІ та високопродуктивних обчислень затьмарювати вимоги до детермінованого керування.
Для систем керування питання полягає не лише в тому, який обсяг обчислювальної потужності доступний. Система також має забезпечувати передбачувану поведінку планувальника та обмежені характеристики часу відгуку для функцій із визначеними вимогами до часу виконання.
Це особливо важливо, коли робочі навантаження ШІ або аналітики споживають значні обчислювальні ресурси.
На мою оцінку, практична архітектура - це не «ШІ замінює керування», а радше детерміноване керування, що працює поряд із інтелектуальністю вищого рівня в умовах контрольованих ресурсних меж.
Дія кібербезпеки має охоплювати весь життєвий цикл продукту
Технічна ізоляція - лише одна зі складових кіберстійкості.
Виробникам промислового обладнання також потрібні процеси для ідентифікації програмних компонентів, моніторингу вразливостей, перевірки оновлень, контролю постачання програмного забезпечення та обслуговування продукції протягом усього періоду її експлуатації.
Серія стандартів ISA/IEC 62443 надає орієнтовану на життєвий цикл структуру, особливо актуальну для систем промислової автоматизації та керування. Інші стандарти, зокрема ISO/SAE 21434, демонструють, як структуроване управління ризиками кібербезпеки може охоплювати етапи від розроблення до експлуатації, технічного обслуговування та виведення з експлуатації.
Європейський акт про кіберстійкість також підвищує важливість управління кібербезпекою протягом життєвого циклу продуктів, на які поширюється його дія.
Для виробників промислового обладнання це означає, що кібербезпеку не можна обґрунтовано розглядати як сертифікацію на завершальному етапі. Склад програмного забезпечення, реагування на вразливості, механізми оновлення, управління постачальниками та обслуговування продукції потрібно враховувати під час розроблення системи.
Архітектура безпеки має підтримувати відновлення, а не лише запобігання
Традиційні обговорення кібербезпеки часто зосереджуються на запобіганні несанкціонованому доступу. Промислова стійкість потребує ширшого підходу.
Скомпрометований або несправний компонент усе ж може виникнути попри превентивні засоби контролю. Тому архітектура має обмежувати здатність компонента впливати на критичні функції та забезпечувати визначений шлях відновлення.
Це формує три взаємодоповнювальні інженерні цілі:
- Запобігати несанкціонованій або ненавмисній поведінці.
- Локалізувати відмови та скомпрометовані компоненти.
- Відновлювати роботу уражених сервісів, зберігаючи функціонування неуражених операцій.
Для промислової автоматизації це поєднання практичніше, ніж покладатися лише на запобігання.
QNX як базова платформа реального часу
QNX забезпечує архітектуру операційної системи реального часу на базі мікроядра, призначену для систем, у яких важливі передбачуване виконання, ізоляція процесів і контрольований доступ до ресурсів.
У межах архітектури промислової автоматизації QNX може забезпечувати базове середовище виконання для застосунків, драйверів, стеків протоколів і файлових систем, що працюють у захищених адресних просторах. Планування на основі пріоритетів може підтримувати навантаження з різними вимогами до часу виконання.
Ця архітектура може доповнювати керування на базі PLC, а не замінювати його.
Практична система може зберігати PLC для усталеного керування на польовому рівні, водночас використовуючи обчислювальні платформи на базі MPU або SoC з операційною системою реального часу для HMI, машинного зору, підключення, аналітики, наглядових функцій і навантажень, пов’язаних зі штучним інтелектом.
Практична архітектура модернізації промислових систем
Отже, сучасну промислову систему можна розглядати як кілька взаємодіючих рівнів:
- Польовий рівень: датчики, виконавчі механізми, приводи та інше фізичне обладнання.
- Рівень керування: PLC і контролери, що виконують детерміновану автоматизацію.
- Обчислювальний рівень: платформи MPU/SoC, що забезпечують додаткову обчислювальну потужність.
- Рівень інтелекту: машинний зір, аналітика, виконання AI-моделей та інші обчислювальні навантаження.
- Рівень нагляду: HMI, діагностика, керування подіями та операційні застосунки.
- Рівень підключення: промислові мережі та зовнішні комунікаційні сервіси.
- Базовий програмний рівень: операційна система реального часу, ізоляція, планування, керування ресурсами та механізми відновлення.
Ключова інженерна вимога полягає у визначенні меж між цими рівнями, а не в розгляді всього обчислювального середовища як єдиного недиференційованого простору застосунків.
Модернізація має зберігати наявні інвестиції в системи керування
Промислове обладнання часто залишається в експлуатації багато років. Заміна усталеного керування на основі ПЛК лише тому, що стали доступними нові обчислювальні можливості, не завжди є технічно чи економічно виправданою.
Практичніша стратегія модернізації полягає в тому, щоб зберегти перевірені функції керування, додавши навколо них обчислювальні ресурси.
Платформи на основі MPU і SoC можуть забезпечити обчислювальну потужність, необхідну для сучасних HMI, ШІ, аналітики, візуалізації та підключення, тоді як наявні ПЛК продовжують виконувати детерміноване керування.
Такий підхід дає виробникам змогу впроваджувати нові можливості без зайвого втручання в усталені архітектури керування.
Мій інженерний погляд: стійкість починається з архітектури
Найважливіший урок цього переходу полягає в тому, що стійкість неможливо додати після того, як систему вже консолідовано.
Коли керування, мережеві функції, HMI, аналітика та ШІ використовують спільні обчислювальні ресурси, механізми ізоляції та відновлення мають бути частиною початкової архітектури.
Сам по собі потужний процесор не створює стійкої системи автоматизації. Так само модель ШІ не робить систему автоматизації інтелектуальною, якщо платформа навколо неї не може отримувати дані, виконувати модель, перевіряти її результати, забезпечувати дотримання заздалегідь визначених політик і реагувати в межах необхідних експлуатаційних обмежень.
Отже, наступне покоління промислової автоматизації залежатиме не лише від вищої обчислювальної продуктивності, а й від того, наскільки ефективно програмна архітектура керує взаємодією між навантаженнями.
Висновок
Промислова автоматизація переходить до архітектури, у якій ПЛК, високопродуктивні процесори, ШІ, підключення та програмно визначені функції дедалі частіше працюють спільно.
Це створює значні можливості для модернізації, але водночас запроваджує нові залежності й режими відмови.
Стійка архітектура має поєднувати детерміноване виконання, ізоляцію процесів, захист пам'яті, контрольований доступ до ресурсів, локалізацію відмов, управління життєвим циклом кібербезпеки та визначені механізми відновлення.
Операційні системи реального часу на основі мікроядер, такі як QNX, є одним з архітектурних підходів до цих вимог. Використовуючи такі платформи разом із наявними ПЛК і контролерами, можна створити програмну основу, необхідну для інтеграції сучасних обчислювальних навантажень, водночас зберігаючи чіткі межі навколо критично важливих функцій автоматизації.
