• Как устроен открытый Linux-контроллер

• Что здесь означает «открытый»

• Что такое embedded Linux

• Зачем контроллеру edge-функции

• Реальные примеры использования

• Преимущества и риски

• Российские варианты

• Перспективы

Когда мы говорим про ПЛК, обычно представляем достаточно закрытое устройство. Подключили модули ввода-вывода, написали программу на ST или LD, загрузили проект и получили контроллер, который годами выполняет один и тот же цикл.

Это понятная и вполне рабочая модель. Более того, во многих системах ничего другого и не требуется.

Но если посмотреть на современные линейки производителей, можно заметить другой класс устройств: WAGO PFC200, Phoenix Contact PLCnext Control, Bosch Rexroth ctrlX CORE, Opto 22 groov EPIC, KUNBUS Revolution Pi, российский ОВЕН ПЛК210 и другие.

Устроены они по-разному, но общая идея примерно одна. Внутри есть обычный PLC-runtime, промышленные интерфейсы и цикл управления. А рядом работает Linux, на котором можно запускать дополнительные приложения.

Например, MQTT-клиент, базу данных, VPN, Node-RED, web-сервис, программу на Python или C++, а иногда и контейнеры Docker или Podman.

В результате получается не совсем ПЛК и не совсем промышленный компьютер. Скорее, это попытка совместить оба устройства в одном корпусе.

Сразу оговорюсь: наличие Linux еще не делает контроллер открытым. Иногда пользователь получает root-доступ и обычный пакетный менеджер. Иногда ему разрешают устанавливать только подписанные приложения из магазина производителя. А иногда Linux вообще спрятан внутри прошивки и никак не меняет привычную работу с ПЛК.

Поэтому давайте разберемся, что именно здесь открыто, зачем это нужно и кому такой контроллер действительно может пригодиться.

Как устроен открытый Linux-контроллер

В основе открытого контроллера остаются привычные вещи:

• дискретные и аналоговые входы и выходы;

• полевые шины и промышленный Ethernet;

• циклические и событийные задачи;

• IEC 61131-3: ST, LD, FBD и SFC;

• retain-память, watchdog и диагностика.

То есть управлять насосом, конвейером, вентиляционной установкой или небольшой машиной такой контроллер умеет так же, как обычный ПЛК.

Помимо PLC-runtime, в таком контроллере есть Linux-среда, в которой можно решать задачи, плохо подходящие для языков IEC 61131-3.

Допустим, нужно получить производственное задание через REST API, разобрать JSON, записать часть данных в локальную базу, сформировать отчет и отправить агрегированные значения в MQTT. Все это, конечно, можно попытаться реализовать внутри проекта ПЛК. Но довольно быстро программа управления начинает превращаться в смесь технологической логики, работы с текстом, сетевых протоколов и обработки ошибок.

В Linux эти задачи можно вынести в отдельное приложение и написать на подходящем языке. PLC-runtime продолжит управлять оборудованием, а пользовательский сервис будет заниматься данными и интеграцией.

Как именно производитель разделяет эти части, зависит от конкретной платформы. PLC-runtime может быть процессом с повышенным приоритетом, отдельной изолированной средой или программным контроллером, работающим рядом с основной ОС.

Что здесь означает «открытый»

Единого определения у таких контроллеров нет. Производители используют названия Open Controller, Open Automation Platform, Linux-based PLC, Edge PLC и PAC.

На мой взгляд, открытым такой контроллер можно называть тогда, когда пользователь штатно может добавить в него собственную функциональность за пределами PLC-проекта.

Это может быть:

• установка обычных Linux-пакетов;

• запуск собственного приложения через SDK;

• развертывание контейнера;

• использование Python, C/C++, JavaScript или Node-RED;

• доступ к данным PLC-runtime через документированный API.

Но степень открытости бывает очень разной.

У Wiren Board 8, например, используется Debian, есть root-доступ и возможность устанавливать пакеты через apt. Это довольно близко к обычному Linux-компьютеру в промышленном исполнении.

У ctrlX CORE пользователь работает через модель приложений и экосистему ctrlX. Платформа расширяемая, но системная среда остается под контролем Bosch Rexroth.

У Siemens есть CPU 1518(F)-4 PN/DP MFP, где классический S7-runtime дополнен GNU/Linux-средой для C/C+±приложений. Но и здесь речь идет не о свободном Debian, а о контролируемой подсистеме с инструментами Siemens.

OPC UA, MQTT или web-сервер сами по себе еще не говорят об открытости. Это всего лишь интерфейсы. Поэтому главный вопрос здесь: можно ли штатно установить свое приложение и как оно будет взаимодействовать с программой управления?

Что такое embedded Linux

В описании таких контроллеров часто встречается термин embedded Linux.

Это Linux, собранный под конкретное устройство. Обычно в нем нет рабочего стола, лишних драйверов и привычного набора настольных программ. Система рассчитана на определенный процессор, flash-память, сетевые интерфейсы и способ обновления.

Управлять ею можно через web-интерфейс, SSH или инструменты производителя.

В промышленном устройстве к этому добавляются watchdog, защита файловой системы, восстановление после отключения питания, управление сертификатами и обновление прошивки.

Но embedded Linux не означает real-time. И уж тем более не означает, что пользователь может менять в системе все что угодно.

Зачем контроллеру edge-функции

Слово edge сейчас добавляют почти к любому устройству, которое стоит не в облаке. Но идея достаточно простая: данные обрабатываются рядом с оборудованием, до передачи в SCADA, сервер или ЦОД.

Например, контроллер опрашивает 50 счетчиков раз в секунду. Вместо передачи всех значений наверх он может локально считать минутные максимумы, средние значения и расход за смену. В SCADA отправляется уже готовый результат.

Или связь с сервером пропала на несколько часов. Контроллер продолжает управлять процессом, складывает данные в локальный архив, а после восстановления канала передает пропущенные записи.

Сам по себе edge-компьютер не обязан быть ПЛК. Особенность открытого контроллера в том, что обе роли находятся рядом: одна часть управляет процессом, другая занимается данными.

Чем это отличается от классической архитектуры

Обычно дополнительные задачи решаются установкой дополнительных устройств.

ПЛК управляет оборудованием. Шлюз преобразует Modbus RTU в OPC UA или MQTT. Промышленный компьютер ведет архив и выполняет пользовательские приложения. Роутер обеспечивает VPN.

Такая архитектура понятна и хорошо разделяет ответственность. Если промышленный компьютер зависнет, программа ПЛК продолжит работать.

Но вместе с устройствами появляются дополнительные блоки питания, сетевые соединения, лицензии, резервные копии и точки отказа.

Открытый контроллер позволяет часть этой схемы собрать внутри одного устройства.

Это не означает, что отдельные шлюзы и промышленные компьютеры (IPC, Industrial PC) теперь не нужны. Если архив большой, аналитика тяжелая, а требования к резервированию высокие, отдельное оборудование никуда не денется.

Но в небольшой локальной системе объединение функций может оказаться вполне разумным.

Кому вообще нужен такой функционал

Безусловно, ПАЗ и крупные распределенные АСУ ТП массово на подобные контроллеры не перейдут. Там важны сертификация, резервирование, длительная валидация и очень четкое разделение функций.

Для простой системы открытая платформа тоже может оказаться избыточной. Если контроллеру надо только опрашивать десяток входов и включать три двигателя, Linux, контейнеры и база данных не добавят системе особой ценности.

А вот в локальных системах все становится интереснее.

Допустим, отдельной SCADA нет. Контроллер управляет вентиляцией небольшого цеха, насосной станцией или инженерными системами здания. На нем же можно собрать данные, вывести несколько дашбордов и дать обслуживающему персоналу удаленный просмотр через браузер.

Или нужно связать старый станок по Modbus RTU с новой SCADA по OPC UA. Вместо отдельного шлюза контроллер может прочитать один протокол, преобразовать данные и передать их дальше.

Еще один потребитель — производитель серийного оборудования. Он может поставить заказчику машину с готовым удаленным сервисом, web-интерфейсом, журналом работы и интеграцией с MES, не добавляя в шкаф отдельный промышленный компьютер.

Вариантов много. Но во всех случаях Linux нужен не сам по себе. Он нужен там, где рядом с управлением появляется работа с данными.

Как это используют на реальных объектах

Чтобы не оставлять все на уровне условной насосной станции, посмотрим на опубликованные кейсы производителей.

Буровые установки и WAGO PFC200

У компании Patterson-UTI на буровых установках использовались разные системы, работающие по Modbus и PROFIBUS. Они находились в отдельных сетях, но данные из них требовалось собирать и передавать заинтересованным пользователям.

WAGO PFC200 использовали как IIoT-шлюз. Контроллер агрегировал данные, сохранял разделение сетей и передавал нужную информацию через OPC UA и MQTT в AWS.

В этом случае PFC200 не заменял основной ПЛК буровой. Он заменил отдельный преобразователь протоколов и edge-шлюз.

Это, пожалуй, один из самых понятных сценариев применения открытого контроллера: подключиться к старому оборудованию, собрать данные и аккуратно передать их в современную систему.

Приемка зерна и Phoenix Contact PLCnext

Компания Xtreme Automation автоматизировала приемку зерна в фермерском кооперативе. Машины с зерном взвешивали, проверяли влажность, после чего оператор выбирал, куда направить продукт: в сушилку, бункер или на площадку хранения.

Две линии использовали общее оборудование и должны были учитывать общие датчики безопасности. Кроме обычного управления, системе требовались база данных, удаленная запись информации, настройка приводов через HMI и отправка уведомлений.

В этом проекте PLCnext одновременно выполнял PLC-логику и работал с данными. Для части обработки использовался высокоуровневый язык, запущенный рядом с ladder-программой.

Получился хороший пример локальной системы, где отдельная SCADA и серверная инфраструктура были бы заметным усложнением.

Контроль качества сварки без замены существующего ПЛК

На предприятии по выпуску автомобильных компонентов возникли проблемы с качеством сварки. Основной ПЛК, робот и сварочный контроллер уже работали, поэтому полностью перестраивать систему не требовалось.

PLCnext AXC F 2152 добавили как edge-устройство. Он забирал данные из существующей системы и отправлял их через MQTT в AWS. Там информация объединялась с изображением от камеры и использовалась для анализа качества сварного шва.

Здесь открытый контроллер вообще не управлял всей линией. Он стал мостом между существующей автоматикой, камерой и облачной аналитикой.

На мой взгляд, это важный сценарий. Открытая платформа может не заменять ПЛК, а расширять уже работающую систему.

Опреснительная установка на острове и groov EPIC

FCI Watermakers производит установки обратного осмоса для яхт, отелей, промышленных объектов и удаленных территорий.

В одном из проектов groov EPIC использовали для управления опреснительной установкой на островном курорте в южной части Тихого океана. Контроллер управлял процессом, обеспечивал локальную визуализацию и удаленный доступ.

Производитель мог через браузер контролировать давление, расход и качество воды, помогать персоналу с настройкой и удаленно обновлять систему. Руководители объекта видели состояние установки со смартфонов.

То есть один контроллер выполнял сразу несколько функций: ПЛК, HMI, удаленный сервис и средство сбора данных.

Для производителя оборудования, которое разъезжается по удаленным объектам, такая возможность выглядит вполне практично.

Тренажер с сервоприводами и ctrlX CORE

У Bosch Rexroth есть пример с высокотехнологичным спортивным тренажером. Внутри него находятся сервоприводы, двигатели и механическая система, создающая нагрузку для пользователя.

ctrlX CORE управляет осями через EtherCAT и ctrlX MOTION. При этом внешнее приложение получает доступ к контроллеру через REST API.

Это уже другой тип задачи. Здесь важны одновременно точное управление движением и удобная интеграция с программной частью самого тренажера.

Обычный ПЛК справился бы с приводами. Но для связи с пользовательским приложением, учетными записями и результатами тренировок, скорее всего, потребовался бы еще один компьютер.

Основные преимущества открытой платформы

Первое и самое очевидное - меньше отдельных устройств.

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

Второе - возможность реализовать нестандартную функцию без ожидания библиотеки от производителя.

Если нужного протокола нет, его можно написать на C++ или Python. Если корпоративная система принимает особый JSON, проще сформировать его в отдельном сервисе. Если требуется локальная база данных, не надо изображать ее массивами внутри PLC-проекта.

Третье - обработка данных рядом с оборудованием.

Можно фильтровать измерения, считать показатели, хранить буфер при потере связи и передавать наверх только нужную информацию.

И, наконец, контейнеры позволяют упаковать приложение вместе с зависимостями. Одну и ту же версию можно проверить на стенде, а затем развернуть на нескольких контроллерах.

Звучит удобно. Но у этой свободы есть обратная сторона.

Где начинаются проблемы

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

У открытого контроллера к этому добавляются операционная система, пользователи, SSH-ключи, сертификаты, пакеты, контейнеры, базы данных и журналы.

Все это надо резервировать, обновлять и восстанавливать.

Если пользовательское приложение начнет бесконечно писать лог, оно может заполнить файловую систему. Если сервис займет все процессорное время, пострадает цикл управления. Если оставить стандартный пароль или открыть SSH в общую сеть предприятия, удобство быстро превратится в проблему безопасности.

Поэтому правильнее говорить не «открытость снижает безопасность», а «открытость добавляет новые объекты защиты».

Еще один вопрос - real-time.

Linux сам по себе не гарантирует, что задача выполнится строго в нужный момент. Для этого используют PREEMPT_RT - режим ядра с уменьшенными задержками, назначают приоритеты задач, выделяют ядра процессора или изолируют PLC-runtime от пользовательской среды.

Но даже наличие PREEMPT_RT ничего не гарантирует без измерений. Время цикла и джиттер надо проверять на реальном контроллере с подключенными I/O, сетевым обменом, контейнерами и архивированием.

И самое важное: критичную технологическую логику не стоит переносить в случайный Python-скрипт только потому, что теперь это возможно.

Блокировки, аварийные алгоритмы, управление приводами и детерминированный обмен должны оставаться в предназначенном для этого runtime. Linux-приложение может упасть, перезапуститься или обновиться, не нарушая безопасное состояние оборудования.

Какие варианты есть в России

Наиболее открытый отечественный пример - Wiren Board 8. На контроллере работает Debian Linux, есть root-доступ, apt и возможность установки Python, Node.js, Docker и других пакетов.

Но здесь есть важная оговорка. Wiren Board по умолчанию не является CODESYS-ПЛК в привычном понимании. CODESYS Runtime устанавливается отдельно и требует отдельного лицензирования. Поэтому устройство правильнее рассматривать как открытый промышленный Linux-контроллер, который при необходимости можно дополнить PLC-runtime.

ОВЕН ПЛК210 тоже работает на Linux с RT-патчем и предоставляет доступ по SSH. Основа системы - OpenWrt, а стороннее ПО можно устанавливать в виде подготовленных пакетов opkg.

Это уже более контролируемая среда. Возможности расширения есть, но подход отличается от обычного Debian с произвольной установкой пакетов.

Segnetics SMH4 производства российской компании Segnetics совмещает ПЛК, HMI и Debian Linux. НПФ «КРУГ» использует Linux в контроллере DevLink-C1000.

Однако и здесь наличие Linux не отвечает на вопрос о степени открытости. Перед выбором надо уточнить, можно ли штатно устанавливать свои приложения, какой SDK поддерживается производителем и сохраняется ли гарантия при изменении системной конфигурации.

На что смотреть при выборе

Первым делом я бы проверял не объем памяти и количество контейнеров, а границу между PLC-runtime и Linux-приложениями.

Что произойдет с управлением, если пользовательское приложение зависнет? Можно ли ограничить ему CPU и RAM? Как осуществляется обмен данными с программой ПЛК? Есть ли документированный API?

Дальше стоит проверить более привычные вещи:

• поддерживаемые I/O и полевые шины;

• минимальное и максимальное время цикла;

• диагностику, retain и watchdog;

• возможность резервного копирования всего устройства;

• процедуру обновления ОС и PLC-runtime;

• срок поддержки модели и выпуск исправлений безопасности;

• лицензии на runtime, контейнеры и дополнительные приложения.

Отдельный вопрос - восстановление после отказа.

Архива PLC-проекта уже недостаточно. Нужны образ ОС, конфигурация контейнеров, версии пакетов, сертификаты, ключи и инструкция, по которой новый контроллер можно привести к тому же состоянию.

Если такой инструкции нет, открытая платформа легко превращается в устройство, которое умеет обслуживать только его разработчик.

Перспективы открытых Linux-контроллеров

Говорить, что открытые Linux-контроллеры вытеснят обычные ПЛК, я бы не стал.

Для простой системы закрытый контроллер часто удобнее. В нем меньше компонентов, проще проверить поведение и понятнее организовать сопровождение.

Но требования к автоматизации меняются. От контроллера все чаще хотят не только управлять сигналами, но и работать с данными: хранить, фильтровать, преобразовывать, показывать и передавать их в другие системы.

Именно поэтому производители постепенно превращают ПЛК в программные платформы.

В общем можно точно сказать, что Linux не заменит классический ПЛК, но может стать его хорошим дополнением. PLC-runtime останется отвечать за управление оборудованием, а Linux возьмет на себя работу с данными, интеграцию и дополнительные приложения. Но для этого нужно четко разделять ресурсы и зоны ответственности двух сред.

*Кстати, еще у меня есть Telegram-канал «Автоматизаторы». Там я время от времени делюсь историями из практики, интересными решениями и новостями о промышленной автоматизации, АСУ ТП, контроллерах и роботах. Если вам близки эти темы - буду рад вашей подписке.