SCADA на объекте - это не только мнемосхемы. В MasterSCADA и ряде других отечественных сред часть логики живёт в скриптах на ST-подобном языке: расчёты, агрегаты, переходы режимов, обработка аварий на уровне оператора. Код выглядит знакомым после CODESYS, но компилятор и рантайм - другие: другие типы, другие библиотеки, другой цикл вызова. Отсюда типичная боль: «скопировал из ПЛК - не собирается» или «на стенде работает, на объекте тег мёртвый».
Ниже - общими словами, без юридических сравнений продуктов: чем диалект ST в SCADA отличается от ПЛК, как отлаживать скрипты, как не утонуть в версиях экранов и как выстроить связку с ПЛК по OPC и Modbus. В конце - таблица «проблема → причина → как проверить» и расширенная перелинковка по уже накопившейся базе материалов.
ST в SCADA и ST в ПЛК: похожие буквы, разный контекст
IEC 61131-3 задаёт идею Structured Text, но конкретная SCADA реализует подмножество синтаксиса и свои расширения. На ПЛК в справочнике ST вы привыкли к VAR, PROGRAM, жёсткому циклу задачи и адресуемым %I/%Q. В SCADA чаще работают привязки к тегам, вызовы встроенных функций визуализации, таймеры и строки в логике отчётов - без прямого доступа к железу.
Практические отличия, которые ловят на каждом втором проекте:
•Типы времени и строк могут называться иначе или иметь другие литералы; TIME# из ПЛК не всегда копируется один в один.
•Нет тех же FB из библиотеки CODESYS - нужны эквиваленты SCADA или обёртки над тегами.
•Порядок выполнения скрипта привязан к циклу опроса/обновления экрана, а не к 10 мс задачи ПЛК; логика «каждый цикл ПЛК» в SCADA превращается в гонки и мерцание на HMI.
•REAL и сравнения с порогом без эпсилона дают ложные срабатывания на мнемосхеме, хотя в ПЛК тот же код выглядел нормально.
Имеет смысл завести в проекте короткий глоссарий диалекта: что разрешено в скриптах SCADA, что сознательно оставлено только на ПЛК. Общая матрица выбора языка ПЛК помогает не переносить в SCADA то, что должно жить в конечном автомате на CODESYS.
Отладка скриптов: не только «поставил breakpoint»
Отладка в SCADA - это цепочка тег → драйвер → скрипт → экран. Скрипт «правильный», но тег в Bad - на мнемосхеме будет ноль или старое значение. Сначала смотрят качество связи и время последнего обновления, потом уже текст ST.
Рабочий порядок на объекте:
1.Изолировать скрипт на тестовой мнемосхеме с фиксированными входами, без продакшен-разрешений на запись.
2.Логировать промежуточные переменные в отдельный тег или журнал событий (кратко, без спама каждый цикл).
3.Сверить часовой пояс и метку времени сервера SCADA с ПЛК - расхождение ломает суточные отчёты и сменные архивы.
4.При подозрении на сеть - не гадать по ST, а пройти диагностику Modbus TCP или режимов RTU/TCP; для полевой шины - CAN vs RS-485.
Если используете GenAI для черновиков ST, в SCADA действуют те же ограничения, что в корпоративной политике LLM: не загружать проект с адресами объекта во внешние сервисы.
Версионирование экранов и проекта
Мнемосхемы меняются чаще, чем ПЛК. Без дисциплины оператор видит одну версию, наладчик - другую, заказчик - третью. Минимум, который стоит заимствовать из промышленного CI/CD: номер ревизии в свойствах проекта, экспорт в архив перед выездом, запрет правки «на живой» сервер без бэкапа.
Для экранов полезны правила именования уровней и шаблонов - те же идеи, что в FBD на больших проектах: префикс участка, версия формата, кто владелец изменения. Крупные переделки HMI лучше вести через копию проекта и FAT на стенде, а не через ночное сохранение на работающей линии.
Связка с документацией шкафа: маркировка и ревизия схем и экраны кабелей не заменяют версии SCADA, но помогают при расследовании «после замены кабеля перестал приходить тег».
Интеграция с ПЛК: OPC и Modbus на уровне архитектуры
OPC UA (и ранее Classic в legacy-участках) удобен, когда нужен иерархический namespace, подписки и единая модель для нескольких ПЛК. Modbus остаётся рабочим вариантом для простых карт регистров и шлюзов; выбор протокола на объекте разбирали в сравнении PROFINET / EtherNet/IP / Modbus TCP.
High-level правила для связки SCADA - ПЛК:
•Один источник правды для уставки и interlock - ПЛК; SCADA не дублирует критичную логику без явного ТЗ.
•Имена тегов согласованы с маркировкой и комментариями в CODESYS, иначе поиск дефекта затягивается.
•Граница сети: SCADA-сервер в сегменте с ACL и jump-host, не «в одной VLAN с офисом».
•Для контроллеров СТАБУР цепочка часто выглядит как CODESYS на ПЛК + SCADA по OPC/Modbus; стартовый маршрут по железу и среде - в руководстве первого старта CODESYS.
Архивирование в historian или lakehouse-контур строят поверх уже стабильных тегов SCADA, а не вместо исправления драйвера.
Таблица: проблема в проекте ST в SCADA → типичная причина → как проверить
Отечественный контур и СТАБУР
На площадках с импортозамещением часто стоят отечественная SCADA (в том числе линейки MasterSCADA) и ПЛК под CODESYS, в том числе СТАБУР. Выигрыш - единый язык для команды и предсказуемая связка «ПЛК - SCADA» при дисциплине тегов и версий. Проигрыш - если ST из ПЛК копируют в SCADA без границы ответственности и без проверки на стенде.
FAQ
Можно ли переносить библиотеку FB из CODESYS в MasterSCADA автоматически?
Обычно нет в лоб; переносят логику идеи, переписывая под теги и API SCADA.
OPC UA или Modbus для нового объекта?
Если ПЛК и SCADA поддерживают OPC UA с нужной моделью - чаще удобнее для сопровождения; Modbus - когда карта регистров уже зафиксирована и проста.
Кто владеет уставкой - SCADA или ПЛК?
Для безопасности и повторяемости процесса - ПЛК, если иное не оформлено в ТЗ и функциональной безопасности.
Внутренняя перелинковка
Языки и ПЛК: ST: синтаксис и ошибки · FBD, LD, ST: матрица · LD в 2026 · FBD: иерархия и ревью · Конечные автоматы CODESYS 3.5 · СТАБУР: первый старт CODESYS · PLCopen Motion / SoftMotion
Шкаф и сеть: Экраны и ЭМС · Функциональное заземление · Маркировка клемм · VLAN в OT · OT глубже VLAN · OT/IT-конвергенция
Данные, процесс, ИБ: Historian 2026 · Lakehouse для производства · ISA-88 batch · GenAI и ST · LLM в АСУ ТП · Supply chain OT · Промышленный CI/CD · IEC 61508 / 61511 / 13849 · Граница ПЛК и Safety PLC
Обсуждение