# PLC AI Studio без галлюцинаций: как провести ИИ через вентиляцию, ИТП и пожарку одного объекта Каноническая страница: https://plainews.ru/posts/plc-ai-studio-multi-project-route-windows Опубликовано: 2026-06-10T07:01:20.855Z Как 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. **Взаимосвязи** — зависимости и блокировки внутри самой установки: что от чего зависит, какие режимы, какие защиты. 2. **Критические запреты** — что обязательно запрещено. Например: «запрещено пускать вентилятор при сработавшем термостате защиты от замерзания». 3. **Понимание системы** — сводка перед генерацией: загружено ли ТЗ, есть ли теги, выбран ли сценарий, заданы ли взаимосвязи и запреты. Инженер подтверждает — и только потом идёт генерация. Эти данные не остаются «для галочки»: они подмешиваются в задание для ИИ явным блоком — и в одиночном провайдере, и в мультиагентном потоке. ИИ получает их напрямую, а не угадывает из контекста. --- ## Многопроектный режим: шаг за шагом Кнопка **Комплекс** открывает расширенный маршрут. Логика такая: **Шаг 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-таблицах. ## Источники - Habr ML: PLC AI Studio, часть 2: многопроектный режим и маршрутные окна — как провести ИИ через целый объект