По мотивам материала Bill Lydon, Automation.com
Когда мы говорим об открытой АСУ ТП, обычно представляется полярный мир: с одной стороны — тотально закрытые проприетарные DCS (РСУ), с другой — Linux, Codesys и чистый open-source. Но прямо сейчас на рынке ПЛК побеждает третья, модель — Gated Ecosystem (Охраняемая или управляемая экосистема).
Крупные вендоры ПЛК давно поняли, что воевать с открытыми стандартами бессмысленно. Они охотно внедрили Ethernet/IP, MQTT, OPC UA и перевели контроллеры на Linux-ядра. Но вместо реальной открытости они создали аналог Apple App Store в промышленном масштабе.
В чем суть концепции Gated Ecosystem? Вендор пускает сторонних разработчиков софта и модулей ввода-вывода в свою экосистему только после жесткого коммерческого аудита, лицензирования и выплаты роялти. Для конечного заказчика это выглядит как победа прогресса: в каталоге («маркетплейсе») автоматизатора появляются сотни готовых плагинов, библиотек и приложений от сторонних стартапов.
Где здесь подвох для концепции Открытой АСУ ТП? Такая модель полностью блокирует две главные цели открытых систем:
Multivendor code portability (Переносимость кода): Вы по-прежнему не можете безболезненно перенести написанный софт и логику на контроллер другого производителя. Вы привязаны к среде разработки и рантайму конкретного вендора.
Hardware interchangeability (Взаимозаменяемость железа): Вы не можете «на горячую» заменить вышедший из строя контроллер аналогом от конкурента, даже если они оба работают на условном Linux.
⛓ Современные «открытые» линейки контроллеров от мейджоров рынка — это не шаг к Open Process Automation. Это классическая «золотая клетка». Вендоры лишь упаковали старый проприетарный lock-in в красивую обертку из ИТ-терминов, сохранив полный контроль над маржой и привязкой клиента к платформе. Настоящая открытость начнется только там, где софт полностью отвязан от железа (hardware-independent), а не там, где к ПЛК можно подключить сторонний датчик по MQTT.
Как экономия памяти в ПЛК породила современную софтверную автоматизацию
По материалу Beyond the hardware tree: structured tags and AOIs redefine PLC programming
Иногда полезно оглянуться назад, чтобы заметить тектонические сдвиги в архитектуре промышленных программ, которые сегодня воспринимаются как должное. Статья Рика Райса наглядно показывает, через какую эволюцию прошла логика управления и как код постепенно забирал приоритет у аппаратной части.
🧱Эпоха «тупых» блоков данных
В период ранних полевых шин (DeviceNet, Profibus, старый Remote I/O) обмен данными с удаленным шасси или частотным преобразователем строился на передаче фиксированных пакетов памяти — жестких массивов слов (INT). Даже если удаленная корзина ввода-вывода была заполнена лишь на четверть, контроллер непрерывно гонял туда-обратно весь блок. Частотник управлялся строго по схеме: слово команд, слово частоты, слово статуса, слово обратной связи. Память ПЛК тратилась в огромных объемах просто на поддержание этих плоских массивов, что жестко ограничивало емкость и гибкость всей системы.
Шаг первый:
Рождение UDT и изоляция от адресов Переход к структурированным тегам (User-Defined Tags) во многом случился из-за дефицита памяти, но в корне изменил подход к проектированию. Возможность упаковать в одну 🖨структуру разнородные типы данных (Boolean, INT, REAL) оторвала логику от физических адресов регистров.
Следом появились профили устройств — Add-on Profiles (AOP). Раньше, чтобы изменить рампу разгона на приводе или вытащить специфическую диагностику, инженеру приходилось либо запускать отдельное ПО от вендора, либо настраивать параметры вручную с лицевой панели устройства. Профили интегрировали эти данные напрямую в аппаратное дерево проекта контроллера.
Шаг второй:
Программа выходит за рамки «железного дерева» Главный посыл автора вынесен в заголовок: программирование ПЛК окончательно вышло «за рамки аппаратного дерева». Благодаря параметризируемым инструкциям (AOI) код перестал быть придатком конкретных клеммников и модулей.
Современный подход позволяет создавать универсальные, автономные алгоритмы (например, комплексное управление конвейерной линией со встроенной логикой фильтрации датчиков и режимами энергосбережения), которые привязываются к физике процесса исключительно через входные и выходные параметры. Автоматизация прошла путь от обслуживания конкретных плат расширения к полноценной программной инженерии (Software Engineering), где софт живет по собственным архитектурным правилам, независимым от физической топологии распределенного ввода-вывода.
Источник: openapc.ru