Когда мы говорим про ПЛК, обычно представляем достаточно закрытое устройство. Подключили модули ввода-вывода, написали программу на 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 возьмет на себя работу с данными, интеграцию и дополнительные приложения. Но для этого нужно четко разделять ресурсы и зоны ответственности двух сред.
Источник: https://habr.com/ru/articles/1070250/
🔗 ПЛК перестает быть закрытой коробкой. Зачем контроллеру Linux?