В офисе интегратора на ноутбуке крутится тот же проект, что потом загрузят в шкаф на объекте: цикл 10 мс, Modbus опрашивается, авария срабатывает. Коллега спрашивает: «Зачем тогда железо? Поставим виртуальный ПЛК на сервер в ЦОД». На совещании заказчик слышит от вендора про софт-контроллер без корзины модулей и экономию на шкафу. На пуске насосной станции инженер принципиально требует аппаратный контроллер в шкафу у насосов: «Сервер в здании администрации не переживёт грозу вместе с кабелем в канале». В 2026 году виртуальный ПЛК - не фантазия и не замена всему; это инструмент с чёткими границами.
Разбираем, что в промышленной автоматизации называют виртуальным (программным) ПЛК, где его уже ставят на реальных объектах, а где оставляют классический аппаратный контроллер: тест, обучение, часть некритичных контуров, верхний уровень сбора. Фокус на времени цикла, джиттере, привязке к I/O, сертификации и эксплуатации. Не продаём «сервер вместо всех шкафов» и не повторяем базовый урок по установке CODESYS - предполагаем знакомство со средой разработки.
Виртуальный ПЛК в 2026 году - это среда исполнения проекта автоматизации (runtime) на промышленном ПК или сервере без отдельного специализированного контроллера в шкафу: тот же IEC 61131-3 код, опрос I/O через Ethernet или полевые карты, часто на базе Linux RT или эквивалентной ОС реального времени.
Его уже ставят для стендов FAT, обучения, симуляции, диспетчерских шлюзов, некритичных контуров учёта и агрегации данных, пилотных зон, где отказ не останавливает технологию. Аппаратный ПЛК оставляют там, где нужны предсказуемый цикл на миллисекундах, работа рядом с исполнительными механизмами, компактный шкаф без серверной, соответствие требованиям функциональной безопасности и привычная эксплуатация «один блок - один IP» у местного персонала.
Граница проходит не по названию в КП, а по последствиям отказа, требованиям к джиттеру, способу подключения I/O и сертификации. Виртуальный контур без расчёта времени цикла и без теста под нагрузкой на стенде - эксперимент на объекте. Сравнение Linux RT и Windows runtime показывает, что «программный» не значит «без требований к ОС».
Виртуальный ПЛК - не эмулятор на рабочем столе программиста, хотя граница размыта. Рабочие определения на объектах 2026 года:
Runtime на промышленном ПК или сервере в шкафу или в машинном зале с проектом, загруженным как служба, с привязкой к реальным или виртуальным I/O.
Soft PLC в составе гипервизора - реже на среднем заводе из-за сложности квалификации и ИБ; чаще в лабораториях и ЦОДах с отдельной дисциплиной эксплуатации.
Контроллер в облаке / удалённый - для телеметрии и аналитики, почти никогда для прямого управления критичными клапанами без автономного нижнего уровня.
Отличие от SCADA: виртуальный ПЛК исполняет циклическую логику регулирования и межблокировок с детерминизмом, близким к аппаратному ПЛК, а не только отображает и архивирует. Отличие от симулятора: связь с полем или с эмуляцией I/O для полноценного FAT, а не только для отладки экранов.
Стенд интегратора и FAT до выезда. Проект гоняют на виртуальном runtime с эмуляцией I/O, затем переносят на железо. Сокращает время на объекте, если процедура переноса версионирована и проверена.
Обучение персонала заказчика. Симуляторы и учебные стенды без риска для линии; оператор отрабатывает аварии на той же логике, что в шкафу.
Шлюз и агрегатор на границе участка. Сбор с нескольких Modbus устройств, преобразование в OPC UA, ограниченная логика (не полноценный ПИД на 5 мс, а разрешения и суммирование). Виртуальный контур на промышленном ПК с Linux RT часто дешевле отдельного «маленького ПЛК» по функционалу шлюза.
Некритичные контуры учёта и энергомониторинга. Опрос счётчиков, расчёт удельных показателей, передача наверх. Потеря узла не останавливает насос или печь.
Пилотные зоны при модернизации. Новый алгоритм сначала на виртуальном контуре параллельно со старым аппаратным, затем переключение.
Диспетчерский сервер с встроенной логикой. Редкие разрешения, расписания, агрегация аварий - при жёстком разделении с контуром ПАЗ.
В этих сценариях виртуальный ПЛК экономит шкаф, ускоряет разработку и упрощает клонирование среды на второй стенд.
Критичные технологические контуры. ПИД температуры, координация приводов, межблокировки с требованием времени реакции десятки миллисекунд. Здесь важны фиксированный цикл, аппаратный watchdog, локальная работа при обрыве связи с сервером.
Шкаф у агрегата без серверной рядом. Компактный контроллер с модулями I/O на DIN-рейке, питание 24 В, IP в шкафу. Тянуть виртуализацию в ЦОД - лишние кабели, точки отказа, вопросы к ИБ.
Функциональная безопасность и ПАЗ. Сертифицированный контур SIL по практике на объекте - отдельная история; обычный виртуальный ПЛК на сервере не подставляется без соответствующего сертификата на весь программно-аппаратный комплекс.
Суровая среда и электромагнитные помехи. Аппаратный контроллер с экранированным шкафом и проверенной EMC-схемой предсказуемее ПК в неподготовленной стойке.
Эксплуатация местным персоналом без ИТ-отдела. Замена контроллера «снял-поставил» понятнее, чем восстановление ВМ из снапшота.
Мобильные и машинные зоны. Вибрация, температура, ограниченное место - классическое железо с встроенным I/O.
Виртуальный ПЛК живёт на общем процессоре с ОС, драйверами сети, антивирусом (если его не отключили по регламенту), фоновыми службами. Даже на Linux RT остаётся риск джиттера при пиковой нагрузке Ethernet или диска.
На стенде измеряют не средний цикл, а худший случай за смену: загрузка CPU, одновременный опрос Modbus, запись архива, сканирование HMI. Если 99-й перцентиль цикла выходит за уставку технологии - виртуальный контур не подходит без изоляции ресурсов или более мощного железа.
Аппаратный ПЛК тоже не идеален, но десятилетия опыта на объектах с одним назначением железа. При выборе виртуального варианта закладывают запас по CPU и запрещают «по пути поставим ещё видеонаблюдение на тот же сервер» без пересчёта.
Связь с полем: виртуальный ПЛК часто опрашивает удалённые I/O по Ethernet. Задержка сети входит в цикл. Аппаратный ПЛК с локальной корзиной модулей короче по пути сигнала.
Без физической корзины ввода-вывода виртуальный ПЛК зависит от удалённых модулей, полевых шлюзов или карт в промышленном ПК. Каждый стык - ещё один протокол и точка отказа. На объекте считают: сколько hop от датчика до логики регулирования.
Для шлюзовой задачи это приемлемо. Для быстрого контура температуры печи - часто нет. Дискретные и аналоговые сигналы рядом с контроллером остаются аргументом в пользу аппаратного ПЛК в том же шкафу, что и исполнительные механизмы.
Виртуальный контур тянет за собой политику обновлений ОС, резервного копирования ВМ, антивируса, прав доступа к гипервизору. ИБ-служба относится к серверу иначе, чем к ПЛК в OT-сегменте. Нужен регламент: кто перезагружает, кто ставит патчи, как откатывают.
Сертификация «как ПЛК» для произвольного сервера без готового доверенного ПАК - долгий путь. На КИИ и значимых объектах виртуальный ПЛК часто ограничивают некритичными функциями, пока поставщик не предлагает комплект с документами.
Аппаратный контроллер поставляют с паспортом изделия, известным сроком службы и ремонтом. Виртуальный - с паспортом сервера плюс лицензия runtime; при смене железа проверяют совместимость драйверов I/O.
| Сценарий | Виртуальный / аппаратный | Аргумент |
|---|---|---|
| FAT и отладка проекта до выезда | Виртуальный (симуляция I/O) | Безопасно, быстрые итерации; перенос на железо по регламенту |
| Обучение операторов | Виртуальный | Та же логика без риска для производства |
| ПИД и межблокировки < 50 мс | Аппаратный | Предсказуемый цикл, локальные модули I/O |
| Шлюз Modbus - OPC UA, логика «разрешений» | Виртуальный на пром. ПК | Гибкость, не нужна корзина модулей в каждом шкафу |
| Насосная без серверной в здании | Аппаратный в шкафу | Автономность, простая замена, EMC |
| Контур ПАЗ / SIL | Аппаратный сертифицированный | Виртуальный общего назначения не заменяет без сертификата комплекса |
| Энергоучёт, опрос счётчиков | Виртуальный | Отказ не останавливает технологию |
| Пилот нового алгоритма параллельно legacy | Виртуальный + аппаратный | Параллельный контур с переключением по FAT |
| Краевой узел у станка с [Linux RT](https://psve.ru/blog/linux-rt-plk-vs-runtime-windows-perenos-proekta) | Зависит от цикла | Короткий цикл - аппаратный ПЛК; агрегация - виртуальный |
Soft PLC на «голом» промышленном ПК с Linux RT - одна история. Soft PLC в виртуальной машине на сервере в ЦОД - другая. Второй вариант в 2026 году встречается на крупных площадках с сильным ИТ-отделом и редко на среднем заводе без выделенной команды.
Гипервизор добавляет слой: миграция ВМ, снапшоты, совместное использение CPU с корпоративными сервисами, политика резервного копирования. Каждый плюс для ИТ - вопрос для инженера АСУ: что будет с циклом ПЛК во время live migration, кто разрешает патч хоста в окно останова.
Если виртуальный ПЛК всё же в ВМ, в договоре фиксируют выделенные ядра CPU, запрет oversubscription, регламент восстановления из снапшота с проверкой версии проекта и лицензии runtime. FAT включает перезагрузку хоста и измерение worst-case цикла после неё.
На насосной в поле проще обосновать аппаратный контроллер, чем стойку с гипервизором. В диспетчерской здания завода виртуальный шлюз на промышленном ПК без лишней виртуализации часто оптимален.
Путаница в терминах дорого стоит на пуске. Симулятор в IDE - для логики и отладки экранов, часто без реальных таймингов полевой шины. Soft PLC на стенде - для FAT с эмуляцией I/O или подключением к реальным модулям через Ethernet. Аппаратный ПЛК в шкафу - для автономной работы у агрегата.
Цепочка 2026 года: симулятор в офисе, soft PLC на промышленном ПК для интеграционных испытаний, затем target на аппаратном контроллере на объекте. Пропуск средней ступени допустим для простых объектов; для сложного обмена по Modbus RTU over TCP soft PLC на стенде ловит ошибки Unit ID и таймаутов до выезда бригады.
Отладка HMI с симуляцией не заменяет измерение цикла на целевом железе. Оператор может отработать квитирование на симуляторе; технолог должен видеть реальный ПИД на нагрузке.
В КП виртуальный контур выигрывает на строке «нет корзины модулей». TCO считают шире: промышленный ПК или сервер, ИБ-лицензии, резервное железо, квалификация ИТ, риск простоя при конфликте патчей, лицензия runtime на каждый узел.
Аппаратный ПЛК в шкафу: одна линия поддержки от вендора, понятная замена модуля, меньше соседей по CPU. На некритичном учёте виртуальный узел часто дешевле. На линии с остановом в миллионы рублей в час экономия на корзине несопоставима с риском джиттера.
Сравнивать варианты по одной таблице затрат на пять и десять лет, включая обучение персонала. Эксплуатация, которая умеет только «перезагрузить контроллер», на виртуальном контуре без ИТ будет платить каждый вызов интегратора.
Один и тот же проект в CODESYS или аналоге часто компилируется под разные target: симулятор, soft PLC, встроенный контроллер. Перенос не автоматический: меняются драйверы I/O, адреса, иногда задачи по приоритетам. Первый старт и документация напоминают проверять device tree после смены target.
Правило 2026 года: в Git хранят ветку «объект» с фиксированным target; симулятор - отдельная ветка или конфигурация, merge только после теста на стенде. Загрузка в виртуальный ПЛК на объекте без повторного FAT после изменений - тот же риск, что и на железе.
При использовании MasterSCADA 4D и CODESYS как взаимозаменяемых сред на одном аппаратном контроллере виртуальный контур часто живёт в другой среде на сервере - не смешивать без явной карты тегов.
Чек-лист переноса: совпадение версии runtime, проверка retain и persistent переменных, прогон аварийных сценариев, замер цикла под нагрузкой, обновление as-built с указанием target. Документ хранят у заказчика вместе с пакетом пусковой документации.
На стенде интегратора виртуальный runtime ускоряет отладку логики и обмена по Modbus до сборки шкафа. На объекте насосной или котельной в шкафу у агрегата по-прежнему ставят аппаратный контроллер с локальными модулями: автономность при обрыве связи с диспетчерской и привычная замена для эксплуатации. Стык между ними - документированный OPC UA или Modbus TCP, а не надежда, что «и так сойдётся».
Перенести на сервер весь шкаф без расчёта цикла. Джиттер на пике нагрузки сети - останов или качество.
Один сервер на виртуальный ПЛК, SCADA, видео и 1С. Конкуренция за ресурсы; разделение по политике или отказ от виртуального ПЛК на этом железе.
Считать симулятор на ноутбуке равным FAT на промышленном ПК. Разные драйверы, разное время.
Не прописать в договоре, что критичный контур остаётся аппаратным. Заказчик услышал «виртуализация» и ждёт нулевых шкафов.
Игнорировать ИБ при появлении гипервизора в OT. Патч во вторник ломает пуск в среду.
Виртуальный ПЛК дешевле аппаратного?
На стенде и шлюзе - часто да. На критичном контуре с запасом по железу и сертификацией - не всегда; считают TCO на 10 лет.
Можно ли один проект крутить и на симуляторе, и в шкафу?
Да, при одной среде и регламенте target; I/O и тайминги перепроверяют на каждом переходе.
Нужен ли Linux RT для виртуального ПЛК?
Для логики с жёстким циклом - предпочтительно. Для медленного опроса счётчиков - иногда достаточно промышленного ПК с настроенным приоритетом процессов, но с измерением джиттера.
Заменяет ли виртуальный ПЛК SCADA?
Нет. Разные роли: циклическая логика нижнего уровня против визуализации, архива и интеграции с ERP.