PLC AI Studio без галлюцинаций: как провести ИИ через вентиляцию, ИТП и пожарку одного объекта
Как PLC AI Studio ведёт ИИ через десятки систем одного объекта: GVL, контракты интерфейсов, ко-симуляция и маршрутные окна пошагово.
Первая часть PLC AI Studio закрывала одну установку — один IOLIST, одно ТЗ, один ST-файл на выходе. Реальный объект так не работает. Здесь рассказываю, как инструмент теперь справляется с десятком взаимосвязанных систем — и почему для этого пришлось переделать саму навигацию.
Почему «одна установка» — это не проект, а черновик
Возьмём типичный производственный корпус: приточно-вытяжная вентиляция (П1, П2, ...), индивидуальный тепловой пункт (ИТП), пожарная сигнализация, дымоудаление, подпор воздуха, конвейер, водоподготовка. Каждая система живёт в своём ТЗ и нередко в своём ПЛК.
Но они работают в единой цепочке. При пожаре сигнализация останавливает приточки и запускает дымоудаление. Приточка с водяным калорифером ждёт готовности теплоносителя от ИТП. Конвейер не стартует, пока вентиляция зоны не вышла на режим. Эти связи — самое важное и самое хрупкое в проекте. Инженер держит их в голове или в Excel. Когда системы программируют по отдельности, межсистемная блокировка ломается первой.
Многопроектный режим PLC AI Studio — попытка вытащить эти связи на свет, явно подтвердить их с инженером и только потом генерировать код.
Термины, без которых дальше не разобраться
Несколько понятий, которые встретятся в шагах ниже.
GVL (Global Variable List) — список глобальных переменных, видимых всем программам проекта в CODESYS и аналогичных средах. Именно через GVL одна система передаёт сигнал другой. Например, gFIRE_ALARM пишет пожарная сигнализация, а читают приточки и дымоудаление.
Межсистемная блокировка — логическая связь, при которой состояние одной системы влияет на работу другой. Классика: «при пожаре закрыть противопожарный клапан и остановить вентилятор».
Топологический порядок — порядок обработки систем, при котором «производитель» сигнала идёт раньше «потребителя». Пожарная сигнализация и ИТП производят сигналы, которые потребляют приточки, — значит, они обрабатываются первыми.
Контракт интерфейсов — формализованное описание: какие межсистемные сигналы существуют, какого типа, кто производит, кто потребляет. Раньше это жило только в голове инженера.
Ко-симуляция — совместный прогон нескольких программ в одном расчётном цикле через общую таблицу сигналов. В отличие от проверки одной POU (программной единицы), ко-симуляция показывает, как системы реагируют друг на друга.
Маршрутные окна: навигация вместо хаоса
Когда базовый режим оброс разбором задания, тремя агентами и двумя ступенями проверки, возникла банальная проблема: в программе стало легко потеряться. Что нажимать первым? Что обязательно?
Решение — маршрутное окно: вертикальная панель-чеклист сбоку, которая подсвечивает следующий шаг. Не модальное окно, не блокировщик — панель живёт рядом с рабочей областью, её можно скрыть или потянуть за угол, чтобы изменить ширину.
Маршрутных окна теперь два, переключаются кнопками в заголовке проводника:
- Объект — одиночный проект, одна установка
- Комплекс — многосистемный режим для целого объекта
Панели взаимно исключают друг друга: открыли одну — вторая прячется.
Что изменилось в одиночном режиме
Одиночный маршрут тоже стал длиннее. Перед генерацией добавились три шага:
- Взаимосвязи — зависимости и блокировки внутри самой установки: что от чего зависит, какие режимы, какие защиты.
- Критические запреты — что обязательно запрещено. Например: «запрещено пускать вентилятор при сработавшем термостате защиты от замерзания».
- Понимание системы — сводка перед генерацией: загружено ли ТЗ, есть ли теги, выбран ли сценарий, заданы ли взаимосвязи и запреты. Инженер подтверждает — и только потом идёт генерация.
Эти данные не остаются «для галочки»: они подмешиваются в задание для ИИ явным блоком — и в одиночном провайдере, и в мультиагентном потоке. ИИ получает их напрямую, а не угадывает из контекста.
Многопроектный режим: шаг за шагом
Кнопка Комплекс открывает расширенный маршрут. Логика такая:
Шаг 1. Добавить системы. Каждая система — отдельная запись: своё ТЗ, свой IOLIST, свой сценарий генерации. Системы можно добавлять, удалять и переименовывать прямо в панели.
Шаг 2. Задать межсистемные связи. Здесь инженер явно описывает, какой сигнал какой системы влияет на другую. Это и есть контракт интерфейсов — инструмент предлагает форму, где указывается источник, потребитель, имя переменной и тип.
Шаг 3. Подтвердить топологический порядок. PLC AI Studio строит граф зависимостей и предлагает порядок обработки систем. Инженер может скорректировать его вручную.
Шаг 4. Сгенерировать GVL. На основе контракта интерфейсов инструмент формирует файл глобальных переменных — единый для всего объекта. Пример фрагмента:
``iecst VAR_GLOBAL gFIRE_ALARM : BOOL; (* Пожарная сигнализация → все системы *) gITP_READY : BOOL; (* ИТП → приточные системы *) gVENT_P1_READY : BOOL; (* П1 → конвейер *) END_VAR ``
Шаг 5. Генерация по системам в топологическом порядке. Каждая система генерируется отдельно, но ИИ получает контракт интерфейсов целиком — он знает, какие глобальные переменные читать и писать.
Шаг 6. Ко-симуляция. После генерации всех систем запускается совместный прогон. Общая таблица сигналов эмулирует GVL: можно подать gFIRE_ALARM = TRUE и посмотреть, как реагируют приточки, дымоудаление и подпор — в одном цикле.
Шаг 7. Финальный аудит и отчёт. Как и в одиночном режиме, последнее слово за инженером: сводный отчёт по всем системам, статусы проверок (Tier S — программный симулятор, Tier H — компилятор matiec), список незакрытых замечаний.
Где это ломается
Неполный контракт интерфейсов. Если инженер не описал какую-то межсистемную связь на шаге 2, ИИ её не угадает — сгенерирует код без нужной блокировки. Контракт нужно заполнять тщательно, не надеясь на «ИИ сам разберётся».
Конфликты имён переменных. Когда систем много, легко получить два gReady от разных источников. Инструмент пока не проверяет уникальность имён автоматически — следить нужно вручную.
Ко-симуляция не заменяет реальный ПЛК. Совместный прогон проверяет логику, но не тайминги, не аппаратные задержки, не поведение при потере связи между контроллерами. Это инструмент для раннего обнаружения ошибок, не финальная приёмка.
Большие объекты — большой контекст. Чем больше систем, тем длиннее контракт интерфейсов и тем больше токенов уходит в каждый запрос. На объектах с 10+ системами стоит следить за лимитами модели.
Что попробовать дальше
Инструмент проходит тестирование — релиза ещё нет. Если вы инженер-практик и работаете с объектами, где несколько ПЛК взаимодействуют через сигналы, — это хороший момент, чтобы подать обратную связь автору до того, как архитектура зафиксируется. Особенно интересны кейсы, где межсистемные блокировки сейчас живут только в голове или в неформальных Excel-таблицах.