Вступление: Linux пришёл в ПЛК не ради командной строки

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

Сегодня один шкаф должен не только включать двигатель и удерживать температуру. От него ждут обмена по OPC UA и MQTT, веб-диагностики, архивов, VPN, базы данных, удалённого обновления, обработки вибрации, связи с MES и иногда даже локального машинного обучения. Втиснуть всё это в монолитную проприетарную RTOS можно, но цена каждого нового драйвера, протокола и сервиса быстро становится неприятно заметной.

Linux оказался удобен не потому, что он «бесплатный» или модный. Его сильная сторона — зрелое управление многоядерными процессорами, драйверами, сетевыми стеками, файлами, пользователями и параллельными сервисами. Однако обычное ядро Linux само по себе не превращает компьютер в ПЛК. Между операционной системой и физическим процессом всё равно нужен детерминированный слой управления, проверенная работа с вводом-выводом и понятная стратегия отказа.

Поэтому главный вопрос звучит не «Linux или ПЛК?», а «какие задачи должны выполняться в реальном времени, какие можно вынести в сервисный слой и как изолировать эти среды друг от друга».

1. Почему классическому ПЛК стало тесно в прежней архитектуре

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

Проблема появляется, когда контроллер превращается в узел цифровой инфраструктуры. Тогда одновременно работают десятки сущностей: циклические задачи, коммуникационные драйверы, OPC UA-сервер, архив, веб-интерфейс, синхронизация времени, VPN, журнал событий, диагностика модулей, сервис обновлений и пользовательские приложения. Для многоядерной системы требуется уже не только быстрый планировщик, но и полноценная операционная среда.

• Управление процессом. Сканирование I/O, ПИД-регулирование, последовательности, блокировки и противоаварийная логика.
• Промышленные сети. PROFINET, EtherCAT, Modbus TCP/RTU, CANopen, Ethernet/IP и синхронизация времени.
• Интеграция с IT. OPC UA, MQTT, REST API, базы данных, файловый обмен, сертификаты и централизованная авторизация.
• Диагностика и сопровождение. Журналы, удалённый доступ, резервные копии, контроль версий и обновления.
• Edge-приложения. Фильтрация данных, расчёт показателей состояния, локальные модели аналитики и подготовка данных для MES/SCADA.

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

2. Из каких программных слоёв состоит Linux-контроллер

Полезно перестать воспринимать Linux-контроллер как единый программный блок. В реальном изделии это набор слоёв, каждый из которых отвечает за свою часть поведения.

• Аппаратная платформа. Многоядерный ARM или x86-процессор, оперативная и энергонезависимая память, промышленные Ethernet-интерфейсы, watchdog, защищённое хранение ключей, шины локального ввода-вывода.
• Загрузчик и доверенная загрузка. Проверка подписи прошивки, выбор раздела, восстановление после неудачного обновления и запуск ядра.
• Ядро Linux. Распределяет процессорное время, память, устройства, сетевые интерфейсы и права доступа.
• Слой реального времени. PREEMPT_RT, отдельное сокоядро, проприетарный RT-runtime или аппаратно изолированная среда.
• PLC runtime. Исполняет IEC 61131-3-программу, управляет задачами, переменными, I/O и коммуникационными объектами.
• Драйверы полевых сетей и ввода-вывода. Связывают логические переменные с реальными модулями, приводами, датчиками и распределёнными станциями.
• Сервисный слой. SSH, веб-интерфейс, журналирование, базы данных, OPC UA/MQTT, обновления, резервное копирование.
• Контейнеры и пользовательские приложения. Изолированные сервисы аналитики, шлюзы, Node-RED, Python/C++-программы и приложения производителя.

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

3. Реальное время: почему средняя скорость ничего не гарантирует

В автоматизации реальное время — это не максимальная производительность, а способность завершить действие до заданного крайнего срока. Обычный компьютер может в среднем выполнять цикл за 200 мкс, но один раз в час задержаться на 30 мс из-за драйвера, обслуживания памяти или фонового процесса. Для офисной программы это незаметно. Для синхронизации осей, быстрого отключения или управления импульсным оборудованием — уже аварийный сценарий.

• Время цикла. Период запуска управляющей задачи: например, 1, 5, 10 или 100 мс.
• Джиттер. Разброс фактического момента запуска относительно заданного расписания.
• Наихудшее время выполнения. Максимальное время, за которое задача гарантированно завершится при заданной конфигурации.
• Задержка I/O. Время от изменения физического сигнала до реакции исполнительного механизма с учётом сети, модулей и программы.
• Пропуск срока. Случай, когда расчёт или передача завершились слишком поздно, даже если результат математически верен.

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

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

4. Три способа совместить Linux и детерминированное управление

4.1. Единое ядро Linux с PREEMPT_RT

В этой архитектуре и управляющие задачи, и сетевые сервисы работают внутри одного ядра Linux. Реал-тайм потоки получают высокий приоритет, критичные прерывания выполняются в управляемом контексте, а ядра процессора можно закрепить за определёнными задачами. PREEMPT_RT уже является частью основной ветки Linux и имеет отдельную официальную документацию [1].

Преимущество — единая среда разработки и сопровождения. Драйверы, сетевые стеки, мониторинг и приложение используют стандартные Linux-интерфейсы. Недостаток — общая судьба: ошибка драйвера ядра, некорректная настройка приоритетов или перегрузка ресурсов способна повлиять и на управление, и на сервисы.

• Подходит для циклов, требования к которым подтверждены испытаниями на целевом оборудовании.
• Требует настройки приоритетов, affinity, IRQ, энергосбережения процессора и сетевых очередей.
• Не следует считать жёстким real-time только по наличию слова RT в названии дистрибутива.

4.2. Двухъядерная программная архитектура: Linux плюс co-kernel

В Xenomai и сходных подходах рядом с обычным Linux работает отдельное реал-тайм ядро. Оно перехватывает критичные события раньше основной системы и планирует задачи, которым нужна ограниченная сверху задержка. Linux получает процессор, когда высокоприоритетная RT-работа завершена. Официальное описание Xenomai называет это dual-kernel architecture и подчёркивает необходимость использовать специальный API внутри критического контекста [2].

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

4.3. Разделение сред гипервизором или выделенными ядрами

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

Похожая идея применяется в промышленных ПК, где real-time runtime работает рядом с виртуальными машинами. Например, Beckhoff описывает TwinCAT/BSD Hypervisor как средство одновременного выполнения TwinCAT real-time приложений и виртуальных машин с сохранением real-time свойств [11]. Это не Linux-архитектура в чистом виде, но показательный инженерный принцип: сервисную ОС лучше отделять от контура управления не обещанием, а механизмом изоляции.

5. CODESYS и SoftPLC: логика отделяется от конкретного железа

Стандарт IEC 61131-3 описывает языки и модель программирования, но не привязывает проект к конкретному процессору. CODESYS использует эту идею как переносимый runtime: одна и та же прикладная логика может выполняться на классическом ПЛК, промышленном ПК или Linux-устройстве при наличии совместимого целевого пакета.

Важно различать продукты и их гарантии. CODESYS Control for Linux SL позиционируется производителем как SoftPLC с мягкими real-time свойствами и прямо рекомендуется для задач без жёстких требований к реальному времени [3]. Это полезная оговорка: установка runtime на мощный IPC не делает приложение автоматически пригодным для motion или противоаварийной защиты.

Практическая ценность SoftPLC — возможность сочетать привычные языки LD, FBD и ST с обычными приложениями C/C++, Python, базами данных и сетевыми сервисами. Инженер АСУ ТП сохраняет прозрачную логику блокировок, а разработчик IT-профиля получает стандартную среду для аналитики и интеграции.

• IEC-программа. Управляет оборудованием, состояниями, уставками, блокировками и диагностикой.
• Сервис на C++ или Python. Обрабатывает спектры вибрации, выполняет оптимизацию, формирует отчёты или взаимодействует с внешним API.
• OPC UA/MQTT-шлюз. Передаёт наружу только нужные теги и агрегированные показатели.
• Контейнер. Изолирует зависимые библиотеки и облегчает развёртывание, но не заменяет real-time runtime.

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

6. Контейнеры и виртуальные ПЛК: удобство без магии

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

CODESYS Virtual Control SL предназначен для контейнерных и гипервизорных сред и может разворачиваться на x86- и ARM-платформах в нескольких экземплярах [4]. Это уже не просто SoftPLC на одном IPC, а модель виртуальных контроллеров, где вычислительная мощность выделяется программно.

Однако виртуализация меняет структуру отказов. В обычной распределённой системе отказ одного физического ПЛК останавливает одну установку. Если десять vPLC размещены на одном сервере, отказ питания, коммутатора, гипервизора или общей сетевой карты способен остановить сразу десять установок.

• Сервер и сеть должны резервироваться как элементы системы управления, а не как обычная офисная инфраструктура.
• Полевой Ethernet должен иметь прогнозируемую задержку и понятное поведение при потере связи.
• Обновление контейнера требует стендовой проверки и стратегии отката; «перезапустить за секунду» не равно «не повлиять на технологию».
• Аппаратная безопасность и SIL-функции допустимы только в сертифицированной архитектуре. Наличие контейнера само по себе ничего не доказывает.
• Нужен независимый механизм безопасного состояния: аппаратные цепи, safety PLC, локальные регуляторы или автономные защиты приводов.

Для safety-задач уже появляются специализированные виртуальные решения. Например, CODESYS заявляет Virtual Safe Control SL с сертификацией IEC 61508 SIL3 [12]. Но это не повод переносить в контейнер любую защиту: применимость определяется сертификатом, системной архитектурой и требованиями конкретного проекта.

7. Edge Computing: что имеет смысл считать прямо в шкафу

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

• Вибродиагностика. Вместо непрерывной передачи высокочастотного сигнала контроллер рассчитывает RMS, пик-фактор, спектральные признаки и тренды.
• Энергомониторинг. Локально вычисляются интервальные значения, дисбаланс, коэффициент мощности и признаки нештатного режима.
• Контроль качества. Камера или датчик профиля обрабатывается рядом с машиной, чтобы результат успел повлиять на текущую деталь.
• Предиктивное обслуживание. Модель оценивает состояние оборудования и формирует предупреждение до достижения аварийной уставки.
• Буферизация. При потере связи данные сохраняются локально и передаются после восстановления канала.

Правильный edge-алгоритм не должен становиться единственной защитой механизма. Модель машинного обучения может подсказать, что подшипник деградирует, но аварийный перегрев всё равно должен отрабатывать через проверенный порог и независимую логику. Аналитика улучшает обслуживание; она не отменяет защиту.

Обработка на месте также уменьшает трафик. Сотни датчиков могут генерировать поток, который бессмысленно хранить в полном объёме. Контроллер передаёт максимум, минимум, среднее, дисперсию, число выбросов и диагностические события — именно те данные, с которыми реально работает диспетчер или аналитик.

8. Примеры промышленных платформ на Linux

Рынок не предлагает единственного «правильного Linux-ПЛК». Производители по-разному балансируют открытость, real-time, сертификацию и свободу пользователя. Ниже — типовые подходы, а не рейтинг.

8.1. Phoenix Contact PLCnext

PLCnext построен вокруг Linux-ядра и объединяет IEC 61131-3 с высокоуровневыми языками. Производитель указывает real-time выполнение как для IEC-кода, так и для C/C++ и модельных инструментов, а также поддерживает открытую экосистему приложений [5]. Это пример платформы, где Linux является не только сервисной оболочкой, но и частью общей модели разработки.

8.2. WAGO PFC200

PFC200 использует embedded Linux и CODESYS, поддерживает промышленные интерфейсы и расширение сторонними приложениями. WAGO отдельно указывает наличие Docker-интерфейса для интеграции дополнительных сервисов [6]. Такая архитектура удобна для средних задач управления, шлюзов и локальной обработки данных.

8.3. Revolution Pi

Revolution Pi развивает идею открытой промышленной платформы на базе Raspberry Pi Compute Module. Операционная система основана на Debian/Raspberry Pi OS, а устройство может использоваться как Linux SoftPLC с CODESYS, Python, Node-RED и контейнерами [7]. Это сильный вариант для IIoT, прототипирования и компактных систем, но конкретный цикл и допустимый джиттер всё равно нужно подтверждать испытаниями.

8.4. Промышленный ПК с SoftPLC или гипервизором

IPC даёт максимальную вычислительную свободу: несколько сетевых карт, NVMe, большой объём памяти, аппаратная виртуализация и ускорители. На нём можно разместить PLC runtime, HMI, базу данных и edge-приложения. Одновременно IPC создаёт риск чрезмерной консолидации: чем больше функций собрано на одном узле, тем важнее резервирование и строгая граница отказов.

9. Кибербезопасность: цена открытости

Закрытая RTOS не является автоматически безопасной, а Linux не является автоматически опасным. Разница в другом: открытая платформа содержит больше стандартных компонентов и чаще имеет сервисные интерфейсы — SSH, веб-сервер, пакетный менеджер, контейнерный runtime, библиотеки и учётные записи. Каждый компонент нужно учитывать как актив и сопровождать в течение всего жизненного цикла.

NIST SP 800-82 Rev. 3 рекомендует строить защиту OT с учётом требований к надёжности, безопасности и непрерывности процесса, а не копировать офисные меры без адаптации [8]. Для Linux-контроллера это означает управляемое обновление, сегментацию, контроль удалённого доступа и тестирование изменений до внедрения.

• Минимизация сервисов. Отключить неиспользуемые демоны, порты, web-панели, отладочные интерфейсы и стандартные учётные записи.
• Сегментация. Отделить PLC/IO-сеть от корпоративной сети, организовать DMZ для обмена с MES, ограничить направления и протоколы firewall-правилами.
• Управление патчами. Вести перечень версий ядра, runtime, библиотек и контейнеров; проверять обновления на стенде и иметь план отката. CISA публикует отдельные рекомендации по patch management для систем управления [9].
• Контроль доступа. Именные учётные записи, минимальные привилегии, ключи вместо паролей, многофакторная аутентификация для удалённого доступа, журналирование действий.
• Подпись и целостность. Secure Boot, подписанные пакеты, проверка образов контейнеров и запрет запуска неподтверждённого кода.
• Резервное копирование. Хранить не только PLC-проект, но и образ ОС, конфигурацию сети, сертификаты, контейнерные манифесты, лицензии и инструкции восстановления.
• Мониторинг уязвимостей. Следить за advisory производителя устройства и поставщика runtime. CODESYS ведёт отдельный список security advisories и выпускает исправления для компонентов Control [10].

Особая ошибка — считать промышленный контроллер «неинтересным для атаки», потому что у него нет прямого доступа в интернет. Достаточно ноутбука наладчика, общей инженерной станции, VPN подрядчика или заражённого обновления. Поэтому граница доверия должна проходить не по стене цеха, а по каждому каналу доступа.

10. Практический блок: как выбрать архитектуру для проекта

Выбор начинается не с бренда и не с желания «перейти на Linux». Сначала нужно описать временные, функциональные и эксплуатационные требования. После этого становится понятно, какая открытость действительно нужна.

10.1. Вопросы до выбора контроллера

1. Каков минимальный цикл управления и допустимый джиттер для каждой задачи?
2. Какие функции относятся к safety и должны иметь отдельную сертифицированную архитектуру?
3. Какие промышленные сети и профили устройств обязательны?
4. Нужно ли выполнять Python/C++, контейнеры, базы данных или локальную аналитику?
5. Что произойдёт при остановке Linux-сервиса, PLC runtime, сетевого коммутатора или всего контроллера?
6. Можно ли обновлять систему только во время планового останова и сколько длится допустимый откат?
7. Кто будет сопровождать Linux: служба АСУ ТП, IT, производитель оборудования или интегратор?
8. Какой срок поддержки ядра, образа ОС, runtime и библиотек нужен объекту?
9. Какие резервные копии и запасные части должны находиться на площадке?
10. Как будет доказано соблюдение временных характеристик: расчётом, стендовым тестом и испытаниями под нагрузкой?

10.2. Когда Linux-контроллер особенно уместен

• ПЛК одновременно работает как промышленный шлюз, edge-узел или локальный сервер данных.
• Нужно использовать открытые библиотеки, нестандартные протоколы или собственные алгоритмы C++/Python.
• Требуется быстро разворачивать несколько изолированных сервисов и обновлять их независимо от PLC-проекта.
• Система должна глубоко интегрироваться с OPC UA, MQTT, REST, SQL, MES и корпоративными средствами мониторинга.
• Временные требования подтверждаются выбранным RT-слоем и испытаниями, а не только паспортом процессора.

10.3. Когда классический ПЛК проще и надёжнее

• Задача сводится к стандартному вводу-выводу, блокировкам и нескольким ПИД-контурам без сложной IT-интеграции.
• Объект обслуживает персонал, которому нужна максимально закрытая и предсказуемая среда.
• Срок эксплуатации измеряется десятилетиями, а обновления и Linux-администрирование на площадке не предусмотрены.
• Нужно минимизировать число программных компонентов и общих точек отказа.
• Есть жёсткие требования по сертификации, резервированию или safety, которые проще закрыть готовой платформой производителя.

10.4. Минимальный план испытаний

• Нагрузка процессора. Одновременно запустить PLC-задачи, полевые сети, архив, web/HMI, контейнеры и резервное копирование.
• Латентность. Измерить не среднее, а максимум и распределение задержек за длительный период.
• Сетевые отказы. Отключить кабель, коммутатор, DNS, NTP, верхний уровень и проверить реакции.
• Отказ сервисов. Остановить контейнер, переполнить журнал, исчерпать дисковое пространство, перезапустить OPC UA/MQTT.
• Обновление и откат. Проверить обновление ОС/runtime, сохранность лицензий и восстановление предыдущей версии.
• Холодный старт. Оценить время до безопасного управления после потери питания и поведение при повреждённом разделе.
• Кибербезопасность. Проверить открытые порты, учётные записи, сертификаты, права файлов, правила firewall и журнал событий.
• FAT/SAT. Зафиксировать критерии приёмки и приложить результаты измерений к исполнительной документации.

11. Типичные ошибки

• «Процессор мощный — значит real-time обеспечен». Мощность уменьшает среднее время выполнения, но не гарантирует отсутствие редких задержек.
• «Docker изолирует всё». Контейнер изолирует процессы и зависимости, но обычно разделяет ядро ОС и общие аппаратные ресурсы.
• «Linux можно обновлять как сервер». В OT обновление должно проходить стендовую проверку, согласованное окно, резервное копирование и план возврата.
• «Один IPC заменит все шкафы». Консолидация снижает количество устройств, но увеличивает масштаб одного отказа.
• «Открытый код автоматически безопаснее». Открытость помогает анализу и исправлению, но безопасность появляется только при управляемом сопровождении.
• «Python можно поставить в быстрый цикл». Высокоуровневый сервис полезен для аналитики, но критичный цикл лучше оставлять в предсказуемом runtime и проверенной задаче.
• «ПЛК не нуждается в администраторе». Linux-контроллер требует владельца процесса обновлений, учётных записей, сертификатов и резервных копий.

Заключение

Linux меняет архитектуру ПЛК не отменой классической автоматики, а разделением ролей. Детерминированный контур продолжает управлять физическим процессом, а полноценная ОС берёт на себя сети, данные, диагностику, приложения и интеграцию с IT. Чем чётче граница между этими слоями, тем больше пользы даёт открытая платформа.

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

Главный инженерный вывод прост: Linux в ПЛК — не готовая гарантия гибкости, реального времени или безопасности. Это инструмент. Надёжность появляется тогда, когда инструмент встроен в проверенную архитектуру, измерен под нагрузкой и обеспечен понятным процессом обновления и восстановления.

Авторитетные источники и техническая основа

• [1] Linux Kernel Documentation. Real-time preemption — official Linux kernel documentation — механизмы PREEMPT_RT и отличия real-time ядра
• [2] Xenomai Project. Xenomai 4 Overview: a dual-kernel architecture — co-kernel, приоритет RT-ядра и ограничения API
• [3] CODESYS Group. CODESYS Control for Linux SL — SoftPLC для Linux с soft real-time свойствами
• [4] CODESYS Group. CODESYS Virtual Control SL — контейнерные и гипервизорные виртуальные ПЛК
• [5] Phoenix Contact. PLCnext Technology — Linux-платформа, IEC 61131-3 и high-level languages в real-time среде
• [6] WAGO. PFC200 Controller — embedded Linux, CODESYS и Docker-интерфейс
• [7] Revolution Pi / KUNBUS. Industrial Software Development & IIoT — Linux SoftPLC, CODESYS, Python, Node-RED и контейнеры
• [8] NIST. NIST SP 800-82 Rev. 3: Guide to Operational Technology Security — защита OT с учётом требований надёжности и безопасности
• [9] CISA. Recommended Practice for Patch Management of Control Systems — процесс тестирования и внедрения исправлений в ICS/OT
• [10] CODESYS Group. Latest CODESYS Security Advisories — актуальные уязвимости, версии и меры устранения
• [11] Beckhoff Automation. TwinCAT/BSD Hypervisor — изоляция виртуальных машин и real-time приложений
• [12] CODESYS Group. CODESYS Virtual Safe Control SL — виртуальная safety-платформа с заявленной сертификацией IEC 61508 SIL3