ЖУРНАЛ СТА №4/2026

О Б З О Р Ы 50 www.cta.ru СТА 4/2026 Доменная архитектура Вполне возможно , что наиболее инте - ресная архитектура будущего промыш - ленного компьютера будет выглядеть как модель нескольких изолированных вычислительных доменов ( рис . 3). Фактическая реализация будет зави - сеть от конкретной платформы : это могут быть отдельные runtime, контей - неры , виртуальные машины , привязка процессов к процессорным ядрам , специ - ализированные ядра realtime и другие механизмы . Суть архитектуры заклю - чается в другом . Разные типы вычисли - тельных задач должны получать разные ресурсы и гарантии : PLC нужен предска - зуемый runtime, AI нужна вычислитель - ная мощность , Vision может требовать GPU, Historian нужен стабильный доступ к накопителю , OPC UA и другие комму - никационные сервисы требуют сетевых ресурсов , Cybersecurity требует изоляции и контроля доступа . И всё это может использовать одну физическую вычис - лительную платформу . Следовательно , промышленный компьютер перестаёт быть просто местом для запуска PLC. Он становится вычислительной системой управления . И снова о времени Предположим , PLC должен выполнять технологическую задачу каждые 10 мс . В традиционном контроллере произ - водитель « держит в руках » практичес - ки всю вычислительную цепочку : PLC task → runtime → CPU → I/O. В Virtual PLC она может выглядеть значительно слож - нее : PLC task → runtime → scheduler → → virtual CPU → ОС / гипервизор → physical CPU. А если I/O находятся удалённо , сюда добавляется : runtime → network stack → тией реального времени , поскольку он использует ядро хостовой операцион - ной системы , а его временны́е характе - ристики зависят от всей системы : пла - нировщика , конфигурации CPU, драй - веров , механизмов изоляции ресурсов , сетевого стека , самого PLC runtime и аппаратной платформы . Но из этого и не следует , что контейнер и real-time несовместимы . Beckhoff, например , ис - пользует собственный дистрибутив Linux с real-time kernel для TwinCAT Runtime for Linux и заявляет стабильное real-time управление , одновременно под - держивая Docker, Podman и LXC. Иными словами , детерминизм обеспечивается не самим контейнером , а специальной комбинацией runtime, ядра , аппаратуры и настроек системы . Виртуальная машина создаёт вир - туализированную аппаратную среду , в которой может работать собствен - ная гостевая операционная система . Контейнер же изолирует приложение и его пользовательское пространство , при этом используя ядро хостовой ОС ( табл . 1). Но для промышленной автоматизации вопрос выбора нельзя свести к простому сравнению в пользу контейнера или VM, так как возможна и комбинированная архитектура , когда контейнер развора - чивается внутри виртуальной машины . Такой подход позволяет разделить раз - личные классы приложений , но одно - временно добавляет новые программные уровни . Следовательно , задача инженера заключается в поиске такой комбинации механизмов изоляции , которая обеспечи - вает требуемые предсказуемость , отказо - устойчивость , безопасность и удобство эксплуатации . ещё не обязательно означает полную независимость от « железа ». Конкрет - ная программная реализация может быть жёстко связана с определённым IPC ( промышленным компьютером ), операционной системой , драйверами или аппаратным интерфейсом . Virtual PLC описывает более высо - кий архитектурный уровень абстрак - ции : насколько функция управления отделена от конкретного физического контроллера и насколько свободно она может быть размещена в универсальной вычислительной инфраструктуре . К при - меру , Siemens непосредственно исполь - зует термин Virtual PLC для S7-1500V, называя его аппаратно - независимым контроллером и предоставляя его как приложение Industrial Edge. Компания также подчёркивает совместимость с TIA Portal и централизованное управление экземплярами Virtual PLC. Контейнеризация же отвечает совсем за другое : каким способом программный компонент упаковывается , изолируется и разворачивается . PLC runtime может находиться внутри контейнера вместе с необходимыми для работы и специально протестированными на совместимость библиотеками и конфигурациями . Это упрощает воспроизводимое развёртыва - ние , обновление , управление версиями и перенос приложения между совмести - мыми средами . Поэтому контейнеризи - рованный PLC не является отдельной от Virtual PLC сущностью . На практике все эти подходы вполне могут сочетаться . Например : на Industrial PC под Linux в контейнере работает PLC runtime. Или : на Industrial Edge в вир - туальной среде работает Virtual PLC + HMI + аналитика . Или : на Industrial PC размещено несколько контейнеров , а в них несколько PLC runtime + vision + AI. Кстати , Beckhoff уже предлагает именно такую комбинацию : TwinCAT Runtime for Linux поддерживает кон - тейнерные технологии Docker, Podman и LXC, а несколько TwinCAT Runtime могут выполняться на одном промышленном компьютере . Компания связывает это с аппаратной консолидацией и более эффективным использованием вычис - лительной мощности . Контейнер и детерминированность Термин « контейнеризированный PLC» легко создаёт ложное ощущение про - мышленной надёжности – такая само - достаточная программная коробочка , однако контейнер не является гаран - Критерий Контейнер Виртуальная машина Основной уровень абстракции Пользовательское пространство ОС Виртуализированная аппаратная среда Собственное ядро ОС Как правило , нет Да Накладные расходы Обычно ниже Обычно выше Скорость запуска Обычно высокая Обычно ниже Изоляция Зависит от конфигурации ядра и runtime Обычно более выраженная на уровне V Управление ресурсами Средствами ОС и container runtime Гипервизором и гостевой ОС Реальное время Не гарантируется самим контейнером Не гарантируется самой VM Типичное преимущество Модульность и быстрое развёртывание Изоляция и независимость программной среды Таблица 1. Сравнение контейнеризации с VM