Linux в промышленном контроллере: как открытая ОС меняет архитектуру ПЛК

Инженер, который десять лет назад писал программу для контроллера, работал в одной операционной среде: цикл сканирования, детерминированный такт, минимум абстракций между кодом и железом. Сегодня в корпусе того же ПЛК может стоять четырёх- или восьмиядерный процессор, и первый вопрос при проектировании новой системы звучит иначе - не "как ускорить логику", а "какая операционная система будет распределять ресурсы между ядрами, сетевыми интерфейсами и периферией".

От разделения ядер к разделению сред

Многоядерная архитектура ПЛК возникла как ответ на рост вычислительной нагрузки: одно ядро отвечает за жёсткий реал-тайм контроль исполнительных механизмов, другое - за сетевые протоколы, диагностику и обмен с верхним уровнем.

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

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

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

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

Почему выбор падает именно на Linux

У проприетарной RTOS долгие годы было неоспоримое преимущество - встроенный детерминизм. Закрытая система с минимумом лишних процессов и предсказуемой задержкой отклика идеально подходила задаче жёсткого управления сервоприводом или клапаном.

Но у этой предсказуемости была цена: разработчик привязан к инструментарию одного вендора, и любая интеграция с внешними IT-сервисами превращается в отдельный дорогостоящий проект, потому что готовых библиотек для нестандартной RTOS просто не существует.

Linux решает эту проблему за счёт своей экосистемы. Драйверы для большинства промышленных интерфейсов - Ethernet, USB, различные шины расширения - уже написаны и поддерживаются сообществом, а не одним вендором. Сетевые стеки TCP/IP, OPC UA, MQTT не нужно создавать заново под каждый новый контроллер.

Контейнеризация через Docker позволяет разворачивать и обновлять прикладные сервисы без остановки всей системы, а наличие Python и C++ на уровне операционной системы открывает доступ к тысячам готовых библиотек для аналитики, машинного обучения и интеграции с облаком.

Цена открытости - расширенная поверхность атаки. MaxPatrol VM от Positive Technologies отдельно отслеживает уязвимости в ядре Linux и связанных компонентах, которые производители встраивают в прошивки ПЛК Siemens Simatic и Schneider Electric Modicon именно потому, что подобные компоненты стали типичной точкой входа для атаки.

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

Технические способы совместить реал-тайм и открытость

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

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

Это снижает непредсказуемые задержки в критичных участках кода, но сама архитектура остаётся единым ядром Linux - просто более отзывчивым. С сентября 2024 года PREEMPT_RT окончательно вошёл в основную ветку ядра начиная с версии 6.12, что закрыло почти двадцатилетний путь разработки этого патчсета для архитектур x86, x86_64, RISC-V и ARM64.

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

Второй путь - гипервизоры реального времени вроде Xenomai. Здесь логика иная: рядом с обычным Linux запускается отдельное сокоядро (co-kernel), которое перехватывает прерывания раньше основной системы и выполняет реал-тайм задачи в изолированном контексте, а Linux используется как "гостевая" среда для всего остального.

Такой подход даёт более жёсткие гарантии по задержке, чем PREEMPT_RT, потому что реал-тайм слой физически не зависит от загрузки основной операционной системы, но требует поддержки специфического API и усложняет разработку драйверов.

Третий путь - аппаратное разделение ядер гипервизором на уровне процессора, когда одно физическое ядро полностью отдаётся под RTOS или "голый" реал-тайм слой, а остальные ядра загружают стандартный Linux без модификаций. Именно так устроен PLCnext Technology от Phoenix Contact: логика ПЛК и приложения на C++ работают в единой реал-тайм среде, при этом открытая платформа с модульным программным обеспечением и глобальной разработческой экосистемой построена вокруг Linux-ядра.

CODESYS как переводчик между стандартами

CODESYS остаётся связующим звеном между классическим программированием по МЭК 61131-3 и новыми Linux-платформами. Один и тот же проект, написанный на лестничной логике или структурированном тексте, можно выполнить и на традиционном контроллере, и на промышленном компьютере под Linux - благодаря стандартизированному runtime, который CODESYS предоставляет для десятков аппаратных платформ, включая ARM-устройства и x86.

Runtime CODESYS Control for Linux SL работает как soft-PLC с поддержкой интегрированных сетевых стеков CANopen, EtherCAT, PROFINET и Modbus, при этом IEC-приложение можно привязать к конкретному ядру процессора через настройки affinity, что сохраняет детерминизм даже в многоядерной системе с общей операционной средой.

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

Обратная сторона этой универсальности - концентрация риска в одном компоненте. Уязвимость в CODESYS Control SoftPLC версии 3.5.14.30, оценённая в 9,9 балла по шкале CVSS, позволяла обходить встроенную песочницу выполнения программы и запускать произвольный код на контроллере.

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

Soft PLC отрывает логику от конкретного железа

Виртуализация идёт дальше простого переноса контроллерной логики на Linux: она перестаёт быть привязана к конкретному физическому устройству и разворачивается как виртуальная машина или Docker-контейнер на промышленном сервере.

CODESYS Virtual Control SL - показательный пример этой логики: runtime устанавливается на любую архитектуру с поддержкой контейнеров, столько раз, сколько требуется проекту, и масштабируется под нагрузку, включая сертифицированную функциональную безопасность в контейнеризированном виде через отдельный продукт Virtual Safe Control SL.

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

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

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

Такая архитектура требует избыточного резервирования самой сети - как минимум дублирования каналов связи и коммутаторов - и повышенного внимания к кибербезопасности сервера, потому что взлом одной виртуальной машины теоретически открывает путь к остальным через общую гипервизорную среду.

Edge Computing на месте, а не в облаке

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

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

Такая обработка на месте связана и с задачами интеграции ПЛК в MES и SCADA системы верхнего уровня: контроллер отправляет наверх уже агрегированные, а не сырые данные, что снижает объём трафика и упрощает работу диспетчерских систем, которые иначе захлёбывались бы в потоке телеметрии с сотен датчиков.

Кто уже выпускает такие контроллеры

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

Revolution Pi построен на основе Raspberry Pi Compute Module и ориентирован на максимальную открытость - пользователь получает почти обычный Linux с промышленным корпусом и модулями расширения для ввода-вывода.

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

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

История с уязвимостью CVE-2018-5459 в этой серии контроллеров, связанной именно с CODESYS Runtime внутри прошивки, наглядно показала обе стороны такой открытости - удобство интеграции и одновременно новую поверхность для атаки, закрытую производителем патчем уже после обнаружения проблемы.

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

PLCnext Technology от Phoenix Contact идёт ещё дальше в сторону открытой экосистемы: платформа построена как набор открытого оборудования и модульного программного обеспечения с собственным программным магазином и глобальным сообществом разработчиков, где логика ПЛК на IEC 61131-3 и приложения на C++ выполняются в единой реал-тайм среде под управлением Linux.

Куда движется архитектура ПЛК

Смена процессоров на многоядерные и смена операционных систем на Linux - это два эпизода одной и той же истории технологического развития.

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

Открытость решает проблему стоимости разработки и доступа к готовым библиотекам, но одновременно расширяет поверхность атаки - каждый открытый компонент, от ядра Linux до runtime CODESYS, становится потенциальной точкой входа, как показывают реальные уязвимости в контроллерах WAGO, Schneider Electric и Rockwell.

Именно кибербезопасность Linux-контроллеров в промышленных сетях - сегментация, управление патчами, контроль доступа к сервисным портам - становится следующим логичным вопросом для отдельного разбора.

Андрей Повный