Виртуализация в операционной системе промышленного контроллера: когда она действительно необходима

Почему возникает необходимость в виртуализации

Типичный промышленный контроллер одновременно выполняет несколько классов задач:

• управление в режиме реального времени — циклы регулирования, обработка сигналов, алгоритмы безопасности (Safety) с жесткими временными ограничениями;
• коммуникационные функции — OPC UA, MQTT, HTTP/REST, диагностический интерфейс, обновление конфигурации;
• прикладные сервисы — HMI, визуализация, edge-аналитика, архивирование и журналирование данных.

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

Что дает виртуализация

На практике в промышленных контроллерах обычно применяется гипервизор первого типа (Type-1, bare-metal), позволяющий запускать несколько полностью изолированных гостевых операционных систем на одном процессоре.
Наиболее распространенная архитектура включает два независимых домена:

• домен реального времени — RTOS (VxWorks, QNX, Zephyr, FreeRTOS) либо bare-metal приложение, которому выделяются отдельные ядра процессора, гарантируется прямой доступ к периферии и предсказуемое планирование;
• домен общего назначения — Linux с полноценным сетевым стеком, OPC UA сервером, средствами удаленного обслуживания и сервисной инфраструктурой.

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

Преимущества такого подхода

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

Функциональная безопасность
При разработке систем в соответствии с требованиями IEC 61508 и ISO 13849 необходимо подтвердить, что несертифицированное программное обеспечение не способно повлиять на выполнение функций безопасности.
Гипервизор формирует границу разделения (Freedom from Interference), благодаря чему существенно упрощается процесс сертификации. Кроме того, сокращается объем программного обеспечения, подлежащего оценке: сертифицируются только RTOS-домен и сам гипервизор, а не вся программная платформа.

Информационная безопасность

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

Консолидация оборудования

Еще одним преимуществом является возможность отказаться от нескольких отдельных вычислительных модулей (контроллер, коммуникационный процессор, HMI) в пользу одного многоядерного SoC.
Это позволяет уменьшить стоимость аппаратной платформы (BOM), снизить энергопотребление, сократить габариты устройства и количество потенциальных точек отказа.

Когда виртуализация оказывается избыточной

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

• контроллер выполняет единственную задачу реального времени при минимальной сетевой функциональности;
• используется одноядерный микроконтроллер или платформа с ограниченным объемом оперативной памяти;
• критичным является даже небольшое увеличение задержек междоменного взаимодействия (обмен через shared memory или virtio обычно добавляет единицы или десятки микросекунд);
• дополнительные затраты на сопровождение гипервизора, его обновление и возможную сертификацию превышают ожидаемый эффект.

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

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

Впрочем, сама по себе виртуализация не решает прикладных задач — она лишь обеспечивает изоляцию вычислительных доменов. Следующий вопрос, который неизбежно возникает при проектировании подобной архитектуры, — каким программным стеком наполнять домен общего назначения. На практике одной из ключевых функций Linux-домена становится промышленная коммуникация, прежде всего реализация OPC UA сервера или клиента.

Open Source OPC UA для промышленных контроллеров: обзор зрелых реализаций

При выборе open-source реализации OPC UA для промышленного контроллера сегодня доступно несколько зрелых проектов, отличающихся архитектурой, ресурсными требованиями и целевыми сценариями применения.
open62541 (C, MPL 2.0)
На сегодняшний день open62541 является одной из наиболее зрелых реализаций OPC UA для встроенных и промышленных систем.

Основные преимущества:

• реализация на чистом C (C99), обеспечивающая минимальные зависимости и простую кросс-компиляцию для ARM, MIPS и других архитектур;
• небольшой ресурсный footprint — ядро занимает всего десятки килобайт оперативной памяти;
• поддержка серверной и клиентской частей, PubSub, Discovery, современных механизмов Security и исторических данных;
• ориентированность на прохождение OPC Foundation Compliance Test, наличие промышленно сертифицированных продуктов на его основе;
• активное развитие проекта и широкое сообщество;
• возможность работы как на bare-metal, так и под RTOS (FreeRTOS, Zephyr, VxWorks, QNX), Linux и Windows.

OPC Foundation UA-.NETStandard (C#, MIT)

Эталонная реализация, поддерживаемая OPC Foundation. Следует отметить, что ранее проект распространялся по лицензии GPL 2.0 / коммерческой лицензии, однако в настоящее время используется лицензия MIT.
Преимущества:

• максимально полная реализация спецификации OPC UA;
• высокая совместимость с другими продуктами экосистемы.

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

Eclipse Milo (Java, EPL 2.0)

Качественная реализация OPC UA на Java, развиваемая Eclipse Foundation.
Она хорошо подходит для edge-решений и промышленных ПК. При соответствующей оптимизации Java может использоваться и во встроенных устройствах, однако особенности работы сборщика мусора (GC) и связанные с этим задержки делают Eclipse Milo менее предпочтительным выбором для систем с жесткими требованиями к детерминированности.

Systerel S2OPC (C, Apache 2.0)

Если требуется реализовать исключительно OPC UA клиент, заслуживает внимания проект S2OPC.
Его ключевые особенности:

• ориентация на формальную верификацию и безопасность;
• отсутствие динамического выделения памяти в критических участках;
• компактная кодовая база;
• детерминированное поведение;
• хорошая переносимость на RTOS;
• лицензия Apache 2.0, удобная для коммерческого применения.

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

Практические рекомендации

Для реализации OPC UA сервера на промышленном контроллере наиболее сбалансированным выбором остается open62541. Проект сочетает минимальные требования к ресурсам, реализацию на чистом C, активное развитие и подтвержденный опыт промышленной эксплуатации.

Специалисты ЦПР РТСофт обладают практическим опытом использования расширенных возможностей данной платформы при создании высокопроизводительных OPC UA серверов edge-уровня, включая поддержку исторических данных и механизмов горячего резервирования.

Если же речь идет о создании программируемого логического контроллера (Soft PLC), стоит учитывать, что открытая референсная реализация ForgeLogic Runtime (компания «Северсталь») уже включает OPC UA сервер и клиент. Кроме того, OPC UA сервер (реализация на Python 3) входит в состав открытого проекта OpenFB.
ЦПР РТСофт разрабатывает промышленный софт, нацеленный на решение актуальных производственных и финансовых вызовов вашего предприятия. Мы накопили значительный опыт в таких сферах, как энергетика, металлургия и нефтехимия, предлагая промышленным компаниям и корпорациям продуманный дизайн и интеграцию надежных программных решений.

Если перед вами стоит вопрос объединения разных систем управления, миграции на открытые архитектуры или обеспечения совместимости оборудования от различных поставщиков, отправьте запрос на info@list.dev.rtsoft.ru. Мы приложим все усилия, чтобы предложить вам работающий вариант решения.