Пакетная SCADA или заказная разработка｜выбор технического пути для ПО верхнего уровня

Четыре ограничения, которые при выборе часто пропускают

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

• Интеллектуальная собственность: проект SCADA зависит от runtime-лицензии вендора; исходный проект обычно нельзя публиковать отдельно от этой платформы. Авторские права и форму поставки заказного кода можно зафиксировать в договоре. Если машиностроитель отгружает ПО вместе с типовой машиной, этот пункт прямо решает, можно ли продавать изделие
• Тиражирование: когда тот же тип машины идёт десятками единиц, проект SCADA копируют по числу тегов или по runtime-лицензии. Заказная разработка позволяет оформить ядро логики как настраиваемый продукт и лицензировать по типу машины, а не пересобирать экраны
• Глубокая связь с оборудованием линии: экраны мониторинга в основном читают состояние и пишут немного уставок. Как только технологические алгоритмы, смена рецептов и решения по блокировкам поднимаются с ПЛК в АРМ, скрипты SCADA быстро упираются в предел
• Потом менять самим: линия сдвинула пост, добавила прибор — объект хочет править экраны своими силами. В этом сила пакетной SCADA. Если ядро логики лежит в зашифрованном проекте или в скриптах, которые трудно сопровождать, инженеры объекта не могут к нему подойти, и работа снова уходит подрядчику

У этих четырёх пунктов нет «правильно / неправильно» — есть совпадение с формой поставки. Диспетчерская водоканала или энергообъекта и АРМ, которое отгружается вместе с типовым агрегатом, — это один класс ПО, но разные ограничения.

Когда пакетная SCADA подходит

Сила пакетной SCADA в том, что инженерия мониторинга уже сделана: драйверы, аварии, тренды, права, резервирование можно брать в работу сразу, а правки экранов на объекте идут быстро. Глубокая работа с несколькими брендами сама по себе является способностью поставки — можно продолжать на платформе, которая уже стоит на объекте, а не заставлять менять стек.

• Потребность — в основном мониторинг, операторские действия, аварии, тренды и отчёты; технологические решения остаются в ПЛК
• Объект уже назвал mainstream-пакет SCADA, либо центральная диспетчерская и мониторинг инженерных систем уже работают на этой платформе
• Экраны часто меняются после реконструкции линии, и инженеры цеха должны править их сами, не возвращая каждое изменение команде разработки
• Проект — мониторинг одного завода или одной линии, а не ПО, которое тиражируется вместе с оборудованием
• Экраны мониторинга и таблицу тегов нужно поднять за короткий цикл; приёмка смотрит, работают ли экраны и аварии

Когда заказная разработка / .NET подходит

Заказная разработка — не «SCADA более высокого класса». Меняется состав поставки: исходный код, конфигурация и инсталлятор по договору могут принадлежать машиностроителю или заводу, а ядро алгоритмов можно развивать как продукт. C#/.NET, VB и LabVIEW сочетают по сценарию, потому что стенды, типовые машины и клиенты у линии предъявляют разные требования к реальному времени, интерфейсу и приборам.

• ПО отгружается вместе с типовой машиной, интеллектуальная собственность должна остаться у машиностроителя и не должна быть привязана к runtime одного вендора
• Тот же тип машины нужно тиражировать: ядро логики меняется настройкой, без правки кода, лицензия — по типу машины, а не через пересборку проекта
• Технологические алгоритмы, рецепты, блокировки или шаги испытаний поднимаются с ПЛК в АРМ, управление и контроль в одном контуре
• Нужны глубокие интерфейсы к MES, прослеживаемости, зрению, приборам стенда; скрипты SCADA эту нагрузку не держат
• У завода или машиностроителя есть команда ПО, и последующие изменения логики и модулей не должны упираться в лицензии платформы и пределы скриптов

Таблица: измерение, пакетная SCADA, заказной АРМ

Если «подходит / не подходит» свести в таблицу, на совещании по выбору проще совпасть. Ниже не оценка функций, а сопоставление ограничений: в одной строке оба пути работоспособны; разница — в форме лицензии и в том, кто потом может менять систему.

Смешанный путь: SCADA для мониторинга, ядро алгоритмов — в АРМ

На объектах чаще не «или — или», а разделение по слоям. Пакетная SCADA берёт экраны мониторинга, аварии, тренды и права, проверенные драйверы и резервирование остаются. Ядро технологических алгоритмов, смена рецептов, решения по блокировкам, интерфейсы к MES или зрению размещают в АРМ или службе на .NET. Стороны обмениваются значениями тегов и событиями через OPC UA, промежуточную базу или канал сообщений.

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