Нейросеть пишет программу или ТЗ на АСУ: что инженер обязан проверить до пуска

В пятницу вечером в чат проекта прилетает «почти готовое ТЗ» на насосную: красивые разделы, таблица сигналов, перечень блокировок, даже формулировки FAT. Автор - не технолог и не ГИП, а коллега, который «сэкономил выходные» запросом к модели. В понедельник в репозитории появляется ST на три станции: комментарии ровные, имена похожи на правду, компилятор молчит. На стенде насос стартует. На объекте выясняется, что «сухой ход» смотрит не тот дискретный, единицы расхода перепутаны с процентами открытия, retain-уставки после download сбросились, а в ТЗ так и не было согласовано, имеет ли оператор право обойти блокировку с панели. Модель не виновата: она не подписывает акт. Подписывает инженер.

Статья - чек-лист ответственности до пуска, когда ТЗ, ST, FBD или карта Modbus родились из нейросети (в том числе из помощника в среде разработки). Это не обзор, хороша ли генерация, и не разбор конкретного Copilot-сценария внутри одной IDE. Фокус - что человек обязан сверить с объектом, с технологом и с версией проекта, прежде чем линия получит этот текст или этот код.

Короткий ответ

Сгенерированные ТЗ и программа - черновик. До пуска инженер проверяет не «красиво ли написано», а стык с реальностью: блокировки и направление fail-safe, retain и поведение после download, единицы и масштабы, граничные условия и обрывы датчиков, соответствие версии проекта физическому шкафу и карте адресов.

ТЗ, которое не видел технолог, нельзя считать ТЗ: модель не знает, что на этой площадке «резервный насос» запускают иначе, чем в учебнике. Код, который компилируется, не равен коду, который безопасно запускает агрегат. На FAT гоняют сценарии человека по чек-листу, а не демонстрацию «нейросеть тоже умеет». Ответственность, Git-тег и подпись в акте остаются на инженере, независимо от того, CODESYS это или MasterSCADA 4D.

Ответственность не переезжает в модель

Помощник в IDE, чат с моделью, генерация по PDF опросного листа - разные входы, одна ловушка: текст выглядит законченным. У законченного вида нет владельца рисков. Владелец - тот, кто грузит runtime, сдаёт SAT и отвечает за блокировку, которая не сработала.

Имеет смысл разделить артефакты. ТЗ и таблица cause-and-effect - договор с технологией. Программа ПЛК - реализация договора. Карта Modbus/OPC - договор с соседней системой. HMI-тексты аварий - договор со сменой. Модель может набросать любой из четырёх. Сверка каждого - разный человек: технолог, программист АСУ, интегратор связи, эксплуатация. Если все четыре файла пришли из одного запроса и их «утвердил» один автор за вечер, это не проект, это черновик с высоким риском внутренней несогласованности.

Генерация внутри среды (в том числе помощники уровня PLC Copilot в CODESYS) ускоряет набор ST и комментариев. Это не отменяет ревью перед пуском и не заменяет трассировку к схеме. Среда - CODESYS или MasterSCADA 4D - здесь ни при чём: оба runtime выполняют то, что им дали, оба одинаково равнодушны к происхождению строк.

Юридически и по здравому смыслу: в журнале изменений пишут «сгенерированный черновик, ревью Иванов, дата». В Git - отдельный коммит до ревью и тег после. Смешивать «модель написала» и «мы сдали» в одном сообщении - способ потерять след, когда через год будут искать, кто утвердил обход блокировки.

ТЗ, которое выглядит готовым

Самый дорогой пропуск - не в ST, а в задании. Модель собирает правдоподобный документ из общеотраслевых шаблонов: «предусмотреть блокировку сухого хода», «архивировать ключевые параметры», «предусмотреть ручной режим». На конкретной площадке сухой ход - это реле в шкафу насоса, а не расходомер на общем коллекторе. Ручной режим - ключ на двери, а не бит на HMI. Архив «ключевых» - спор, который технолог и главный механик не заканчивали три года.

Что проверить в сгенерированном ТЗ до того, как оно станет приложением к договору.

Источник требований. Каждая блокировка и каждая уставка должны опираться на опросный лист, регламент цеха, паспорт агрегата или протокол совещания. Фраза «по лучшим практикам» без ссылки - кандидат на вычёркивание или на явное согласование.

Граница ПАЗ и технологической АСУ. Модель любит смешать аварийный останов, технологическую блокировку и предупреждение. Если на объекте есть контур безопасности, его не проектируют абзацем в общем ТЗ без оценки SIL и документов.

Права оператора. Имеет ли смена право обойти блокировку, с какой роли, с каким журналом. Модель часто ставит «возможность обхода для обслуживания» без двухролевого подтверждения и без срока действия bypass.

Единицы, диапазоны, направление 4–20 мА. «Давление 0–16 бар» в тексте и датчик 0–10 бар в спецификации КИП. Это не мелочь: уставка 12 бар в программе при живом датчике 10 бар - вечный Bad или вечный верх.

Что считается готовностью к пуску. Сгенерированное ТЗ любит «система должна работать устойчиво». Нужны сценарии: пуск, стоп, потеря датчика, потеря связи, питание шкафа, ручной, сервисный bypass. Иначе FAT не к чему привязать.

Согласование с технологом - не «ознакомился», а постраничные замечания на таблицу сигналов и cause-and-effect. Пока технолог не поставил имя под блокировками, программировать рано. Иначе вы отлаживаете чужой учебник.

Программа: блокировки, retain, единицы, границы

Когда черновик уже в ST или FBD, проверка другая. Компилятор ловит синтаксис, не смысл. Справочник по синтаксису ST не заменяет вопрос «этот IF вообще про наш насос».

Блокировки. Один источник правды на разрешение пуска. Модель часто дублирует условие в двух POU «для надёжности»: потом правят одно место, второе остаётся. Сверить с матрицей cause-and-effect построчно. Направление при обрыве: нет сигнала концевика - запрет, не разрешение. Нейросеть по умолчанию пишет «если датчик = 1, то авария» и молчит про обрыв цепи, обрыв 4–20, Bad Quality.

Retain и persistent. Уставки, выбранный режим, наработка, положение шагового автомата - должны пережить цикл питания так, как задумано в ТЗ. Модель ставит retain «на всякий случай» на всё или не ставит нигде. Оба края опасны: либо после download уезжают технологические уставки, либо после freeze шаговый автомат стартует с середины фазы. Проверка: обесточить, включить, сменить проект с download, посмотреть, что осталось. Не на симуляторе, на целевом runtime.

Единицы и масштабы. Литры в минуту против кубов в час, градусы против процентов клапана, бар против кПа. Генерация по таблице Excel часто берёт заголовок колонки и игноривает примечание «в ПЛК - бар, на HMI - кПа». Сверить три точки: сырой код АЦП / инженерная величина в ПЛК / подпись на экране. Расхождение здесь даёт ложные PID и ложные аварии, не «некрасивый текст».

Граничные условия. Индекс массива, пустой рецепт, нулевой знаменатель в расходе, первый цикл после старта, одновременный пуск двух насосов, команда стоп во время разгона. Модель пишет счастливый путь. Инженер обязан добавить несчастный: что при i > MAX, что при делении на ноль, что если HMI прислал уставку вне LIMIT. Это ровно те места, где ST удобен инженеру - и где черновик модели дырявый.

Ложные датчики. Залипший дискрет, обрыв аналога, «замороженное» значение при потере модуля. ТЗ могло требовать контроль достоверности, код - нет. Или наоборот: код ставит фильтр на 30 с, который прячет реальный сухой ход. Сверить с паспортом датчика и с тем, как смена отличит «нет воды» от «нет сигнала».

Версия против объекта. Сгенерированный фрагмент мог родиться из чужого примера: другая корзина I/O, другие адреса %IW, другой Unit ID. Компиляция на стенде с другим модулем это не ловит. Сверка: паспорт шкафа, маркировка клемм, карта адресов, версия проекта в Git, версия на контроллере. Версионирование проектов ПЛК здесь не про красоту репозитория, а про ответ на вопрос «что сейчас в шкафу».

FBD, ST, карта Modbus: разные дыры одного черновика

FBD, сгенерированный по текстовому описанию, часто выглядит «как в учебнике»: блоки в ряд, EN/ENO по умолчанию, порядок слева направо не проверен. Сигнал, который должен участвовать в блокировке на этом же цикле, уезжает на следующий из-за порядка сетей. Это не поймаешь чтением комментария. Нужна трассировка критичного пути и тест на стенде с осциллографом или трендом цикла. База про FBD как язык известна; перед пуском важнее не синтаксис блока, а то, что модель могла вставить лишний EN и тем самым отключать ветку молча.

ST от модели любит длинные IF без ELSE и магические числа. Уставка 1500 без единицы в комментарии и без именованной константы. Через месяц никто не вспомнит, это 15,00 бар в масштабе x100 или 1500 л/ч. Вынести в именованные константы и сверить с ТЗ.

Карта Modbus - отдельный праздник галлюцинаций. Модель перенумеровывает регистры «логично», сдвигает holding/input, путает 0-based и 1-based, забывает масштаб и слово статуса качества. Соседний участок при этом уже шил свою SCADA под старую карту. Сверка: таблица «имя - адрес - тип - масштаб - качество» с обеих сторон, тест Bad Quality при обрыве, тест граничных значений. Карта, которую «дописали нейросетью к ТЗ», не имеет силы, пока её не подписали оба владельца обмена.

HMI-тексты и теги. Модель генерирует имена Pump3_Alarm_General. Смена должна увидеть «насос 3, сухой ход, закрыть задвижку 12, не сбрасывать до появления давления». Связь картинки с ПЛК проверяют как на живом проекте, не по списку имён.

Стенд, FAT, объект: три разных «вроде работает»

Симулятор IDE подтверждает, что POU выполняется. Не подтверждает адреса, модули, времена фильтров на живом АЦП, поведение retain после freeze, гонки с HMI.

Стенд с реальным контроллером лучше, но часто без полевого кабеля и без «грязного» датчика. Сгенерированный антидребезг 20 мс на стенде с кнопкой проходит, на концевике в масле - нет, или наоборот душит импульс.

FAT должен гонять не демо «нейросеть написала пуск насоса», а сценарии согласованного ТЗ: отказ датчика, Bad Quality, повторный пуск, стоп на разгоне, обрыв связи с панелью, download с проверкой retain, роль оператора против роли наладчика. Это обычная дисциплина FAT и SAT, только в программу испытаний добавляют явную строку: «код/ТЗ частично сгенерированы, ревью по чек-листу приложено». Заказчик имеет право увидеть diff и список принятых/отвергнутых кусков модели.

SAT на объекте ловит то, чего не было в опросном листе, из которого кормили модель: другой насос, другой дискрет «готовой к пуску», ручной ключ, который в ТЗ назван иначе. Здесь снова технолог, не чат.

Порядок ревью: не «прочитать глазами», а пройти объект

Практичная последовательность, которую можно вставить в регламент бюро до пуска. Она одинакова, пришёл ли черновик из чата, из помощника IDE или из «перепиши нам ТЗ подрядчика».

Сначала заморозить входные документы: опросный лист, однолинейка, спецификация КИП, паспорт шкафа, действующая карта обмена. Сгенерированный текст сверяют с ними, а не наоборот. Если модель «улучшила» адресацию, это дефект, пока соседний участок не подписал новую карту.

Дальше таблица cause-and-effect: каждая строка - имя технолога или явный отказ («этой блокировки на объекте нет»). Без этой таблицы ST ревьюить рано: не с чем сравнивать.

Потом код относительно таблицы, не относительно собственного ощущения «логично». Для каждой критичной блокировки - где в проекте единственная точка, какой fail-safe при обрыве, какой bypass, какой журнал. Для аналогов - три точки масштаба. Для шаговых автоматов - поведение после freeze и после download.

Потом стенд на целевом runtime: не симулятор ПК наладчика как финальный аргумент. Обесточивание, обрыв датчика, Bad Quality, неверная уставка с HMI, повторный пуск, роль оператора.

Потом сверка версии: тег, что в Git, что в контроллере, что в as-built, что на шильдике корзины. Сгенерированный пример с чужого проекта чаще всего ломается здесь, не в IF.

Наконец - сценарии FAT из согласованного ТЗ, не из «демо пуска», которое модель сама же и придумала. Если в ТЗ нет сценария потери модуля ввода, его либо добавляют осознанно, либо фиксируют как непроводимый. Молчаливый пропуск - дыра.

Такой порядок длиннее, чем «код вроде читается». Он короче, чем разбор аварии, где блокировка смотрела не тот дискрет, потому что в пятницу вечером все устали.

Насосная как мини-пример, без иллюзии универсальности

Возьмём типовой черновик: два насоса, сухой ход, ЧРП, давление на выходе, ручной/автомат. Модель напишет пуск по очереди, блокировку по «нет потока», переключение при аварии, уставку давления. Инженер до пуска обязан закрыть вопросы, которых в красивом тексте нет.

Какой дискретный сухой ход на каждом насосе, а какой - общий на коллекторе. Что, если реле сухого хода залипло в «норма». Есть ли охлаждение/смазка, без которой пуск запрещён, и попала ли она в ТЗ. Разрешён ли пуск второго при аварии первого автоматически, или только ключом. Что делает ЧРП при обрыве 4–20 задания: стоп, выбег, удержание. Где retain: выбранный насос, уставка давления, разрешение автомата. Кто на HMI имеет право снять блокировку и на сколько минут. Какой регистр отдаёт соседнему участку «насос в работе», и не сдвинула ли модель карту на слово.

Ни один из этих пунктов модель не обязана угадать. Угадывание - как раз источник ложной готовности. Человек либо достаёт ответы из цеха, либо не грузит программу.

В пакет документов при вводе кладут утверждённое ТЗ, as-built карту, тег релиза, протокол FAT. Черновик из чата с моделью туда не кладут, если он не прошёл ревью. Класть его как «исходник требований» - способ через год спорить с текстом, который никто не подписывал.

Таблица: артефакт, что проверить, типичный пропуск модели

Типовые ошибки

Скормить модели чужое ТЗ и считать его своим. Совпадут названия насосов, не совпадёт дискрет готовности и политика bypass.

Принять компиляцию и симулятор за ревью. Компилятор не знает ваш концевик.

Не пометить сгенерированные куски в Git. Через месяц нельзя отделить ручную правку от повторной генерации, которая затёрла блокировку.

Согласовать ТЗ с руководством, минуя технолога. Руководство видит структуру документа, технолог видит, что сухой ход смотрит не туда.

Смешать ПАЗ и технологию в одном сгенерированном POU. Потом нельзя доказать независимую реализацию контура безопасности.

Обновить карту Modbus «для красоты нумерации» без соседа. Соседняя SCADA остаётся на старых адресах, пуск срывается на обмене, не на логике насоса.

Доверять единицам из комментария модели. Комментарий не участвует в масштабировании. Смотреть код и калибровку.

Вопросы при работе

Можно ли вообще отдавать модели черновик ТЗ?
Можно как заготовку оглавления и формулировок. Нельзя как документ к договору без построчной сверки с опросным листом и подписи технолога.

Чем проверка до пуска отличается от проверки перед download в IDE?
Перед download ловят синтаксис, библиотеки, грубые адреса. До пуска - смысл относительно объекта: датчики, роли, retain, карта обмена, сценарии FAT/SAT. Второе шире и не заменяется первым.

Нужна ли отдельная процедура, если код писал человек, а ТЗ - модель?
Да. Риск тогда в требованиях: программа может честно реализовать вредное задание. Ревью ТЗ не слабее ревью ST.

CODESYS и MasterSCADA 4D проверяют по-разному?
Инструменты разные, чек-лист смысла один: блокировки, retain, единицы, границы, версия, карта обмена. Среда не снимает ответственность.

Что писать в акте FAT, если часть кода сгенерирована?
Факт ревью человеком, тег версии, перечень сценариев, которые прогнали, список отвергнутых фрагментов. Не писать «система создана ИИ» как знак качества или как отговорку.

Кто виноват, если модель перепутала fail-safe, а инженер «просмотрел»?
Инженер и организация, допустившая пуск без чек-листа. Модель не сторона акта.

Ссылки по теме

• Версионирование проектов ПЛК: практика Git;
• FAT и SAT: приёмка АСУ ТП без сюрпризов на пуске;
• Structured Text: почему его выбирают инженеры ПЛК;
• Функциональные блоковые диаграммы FBD;
• Structured Text IEC 61131-3: справочник синтаксиса и ошибок;
• Функциональная безопасность SIL: практика оценки и документы.