Генерация кода ПЛК на Structured Text с помощью ИИ: архитектура, проверка, реальные результаты

Дисклеймер: Это статья о том, что я строю и как это работает. Инструмент проходит тестирование на реальных проектах. Публикую сейчас, чтобы услышать мнение инженерного сообщества — что учесть, где слабые места, каких граблей избежать.

Откуда всё началось

Однажды мне потребовалось написать программу на Structured Text для системы автоматизации. И, как любой инженер, который слышит про искусственный интеллект ^[1], я в какой-то момент спросил себя: а мог бы ИИ написать код вместо меня?

Попробовал с ChatGPT. Дал ему задание: центральный кондиционер, IOLIST на 40 точек, простое ТЗ на три страницы. Получил код. Красивый. Даже синтаксически правильный. И абсолютно бесполезный.

ИИ выдумал уставки из головы — вместо температуры притока 18°C из моего ТЗ поставил 20°C. Перепутал нормально-замкнутые и нормально-разомкнутые контакты на реле давления. Проигнорировал добрую половину сигналов из IOLIST — просто не заметил их или забыл. Код компилировался, но никакого отношения к реальной установке не имел. Типичный «уверенный галлюцинатор».

Проблема не в том, что ИИ плохо пишет ST. Проблема в том, что его никто не заставляет разобраться в задаче перед тем, как начать писать. И никто не проверяет результат после.

Именно это я и решил исправить!

Несколько слов о терминах — для тех, кто не каждый день работает с программным обеспечением

Прежде чем рассказывать о том, как устроен инструмент, хочу объяснить несколько понятий. Они будут встречаться по всей статье, и важно понимать, что за ними стоит.

Structured Text (ST) — это один из пяти стандартных языков программирования ПЛК по международному стандарту МЭК 61131-3. Выглядит как обычный текст, похож на Pascal. Именно на нём написано большинство прикладных программ для современных ПЛК — ОВЕН, WAGO, Siemens и других.

МЭК 61131-3 — международный стандарт, который описывает пять языков для программирования ПЛК: Structured Text (ST), Ladder Diagram (LD — релейная логика ^[2]), Function Block Diagram (FBD — блочная схема), Instruction List (IL) и Sequential Function Chart (SFC — диаграмма состояний). Большинство сред программирования — CODESYS, TIA Portal и другие — реализуют именно этот стандарт.

IOLIST (список ввода-вывода) — таблица всех сигналов системы автоматизации: датчиков, исполнительных механизмов, дискретных входов и выходов. Обычно это Excel-файл со столбцами: тег сигнала, адрес в ПЛК, тип (дискретный вход DI / дискретный выход DO / аналоговый вход AI / аналоговый выход AO), описание, диапазон шкалирования.

ИИ / LLM (Large Language Model) — большая языковая модель. Это и есть тот самый «ИИ», который умеет писать текст и код. Примеры: ChatGPT, Claude, DeepSeek. Они обучены на огромных массивах текста и кода, поэтому умеют писать синтаксически правильный ST. Но без правильной постановки задачи они «галлюцинируют» — выдумывают данные, которых нет в задании.

POU (Program Organization Unit) — программная единица в МЭК 61131-3. Это может быть программа (PROGRAM), функциональный блок (FUNCTION_BLOCK) или функция (FUNCTION). Реальная программа ПЛК состоит из нескольких POU, каждый отвечает за свою часть логики: один управляет насосом, другой — клапаном, третий — аварийной защитой.

SFC (Sequential Function Chart) — диаграмма последовательных состояний. Графический способ описать пошаговую работу установки: шаги (Step), переходы между ними (Transition) и действия (Action). Хорошо подходит для описания технологических последовательностей: пуск, выход на режим, нормальная работа, останов.

NC/NO контакты — нормально-замкнутый (NC, Normally Closed) и нормально-разомкнутый (NO, Normally Open) контакт датчика или реле. Принципиально важная вещь в схемотехнике, и именно в этом ИИ без специальной подготовки часто ошибается.

RAG (Retrieval-Augmented Generation) — подход, при котором перед генерацией ответа система сначала ищет похожие примеры в базе знаний и подкладывает их в контекст языковой модели. Результат — модель не «выдумывает», а ориентируется на реальные проверенные примеры. В нашем случае это похожие программы ПЛК из ваших предыдущих проектов.

Компилятор matiec — это открытый компилятор языков МЭК 61131-3, разработанный в рамках проекта Beremiz. Он умеет скомпилировать Structured Text в код на языке C. Если в ST есть синтаксические или типовые ошибки ^[3] — компилятор их обнаружит, как это делает любой настоящий компилятор.

Что такое PLC AI Studio

PLC AI Studio — это рабочий инструмент инженера АСУ ТП. Не чат-бот, не «нажми и получи что-то». А инженерный конвейер с проверкой на каждом шаге.

Вы загружаете два документа, которые и так есть в любом проекте автоматизации:

• IOLIST — ваш список ввода-вывода (Excel, CSV или JSON)

• Техническое задание — описание работы системы (PDF, DOCX, TXT или ZIP-архив проекта целиком)

Программа выдаёт:

• Готовый код на Structured Text по стандарту МЭК 61131-3

• Графические схемы: SFC (диаграмма состояний), LD (релейная логика), FBD (функциональные блоки)

• Технологическую SCADA-мнемосхему для согласования с заказчиком

• Пояснительную записку по ГОСТ 21.408-2013

Всё это работает полностью офлайн — единый .exe под Windows, никакого облака. Ваши данные и технические задания никуда не уходят. API-ключи к облачным ИИ-провайдерам, если вы их используете, хранятся только на вашем компьютере.

Ключевой принцип, который пронизывает всю систему: не угадывать — проверять фактами. Сгенерированный код не отдаётся инженеру сразу. Он проходит несколько независимых слоёв проверки.

Как работает конвейер: от ТЗ до готового кода

Разберём каждый шаг подробно.

Шаг 1. Загрузка и разбор входных данных

Программа читает IOLIST самостоятельно. Не нужно настраивать, «где у вас заголовки» — она сама находит строку заголовков в первых 20 строках Excel по ключевым словам: TAG, ADDRESS, TYPE, AI/AO/DI/DO. Это работает с большинством реальных форматов IOLIST, которые используются в российских проектах.

Техническое задание принимается в любом формате: .pdf, .docx, .txt, .md, .html, .rtf. Можно загрузить ZIP-архив проекта целиком — программа разберёт его автоматически и вытащит нужные файлы. Если расширение файла не совпадает с содержимым (бывает) — тип определяется по внутренней сигнатуре файла.

Текст из PDF извлекается через pdfplumber с лимитом 120 000 символов — это примерно 60–80 страниц технического задания, чего с избытком хватает для большинства реальных проектов.

Одна техническая деталь, о которой стоит знать: кириллические имена тегов транслитерируются перед передачей в языковую модель. Переменная Насос_1 становится Nasos_1. Это не потеря информации — это практическая мера: языковые модели стабильнее работают с латиницей при генерации идентификаторов в коде. После генерации имена можно вернуть к исходным.

Шаг 2. Разбор задания: сначала понять, потом писать

Это самый важный шаг, который отличает систему от «голого» ChatGPT.

Прежде чем написать хоть строку кода, система делает следующее:

Из IOLIST локально, без ИИ, извлекается:

• Список всех тегов с их типами (DI, DO, AI, AO)

• Адреса точек ввода-вывода

• Для каждого дискретного входа — признак NC или NO (нормально-замкнутый или разомкнутый)

• Для аналоговых каналов — диапазон шкалирования (например, 4–20 мА → 0–16 бар)

Это делается детерминированно — программным парсером, без участия ИИ. Потому что в этой части нет никакой неопределённости: IOLIST — это таблица с чёткой структурой, и разбирать её нужно точно, а не «приблизительно».

Из ТЗ, с помощью языковой модели, извлекается:

• Все числовые уставки: температуры, давления, времена задержек, пороги срабатывания защит

• Пошаговый алгоритм работы установки

• Перечень необходимых функциональных блоков (POU)

• Явный список, какие контакты нормально-замкнутые — это критично для защитной логики

Ключевое: ИИ берёт уставки из вашего документа, а не выдумывает их. Если в ТЗ написано «защита по перегреву при +85°C» — именно это значение попадёт в код. Не какое-то «типичное».

Всё это объединяется в технический бриф — структурированный план программы. Он показывается инженеру на экране перед тем, как начнётся генерация.

Инженер читает бриф, проверяет и подтверждает. Только после этого запускается следующий шаг.

Зачем это нужно? Потому что именно здесь можно поймать недопонимание. Если ИИ неправильно интерпретировал условие из ТЗ — это будет видно в брифе. Лучше исправить план на этом этапе, чем потом разбираться в 500 строках ST.

Шаг 3. Генерация — несколько движков параллельно

После подтверждения брифа запускаются выбранные AI-движки. Не один — несколько, одновременно. Каждый получает в контекст:

• Технический бриф из шага 2

• Образцы из памяти ^[4]: три наиболее похожих успешных генерации из прошлых проектов (подробнее о памяти ниже)

• Интерфейсы ваших библиотечных функциональных блоков, если они загружены

• Отраслевой системный промпт — специализированный под тип объекта

Отраслевые промпты: почему ПВУ и конвейер — это разные инженерные миры

В программе хранится 9 категорий сценариев: HVAC/приточно-вытяжная установка, конвейер, водоподготовка, холодоснабжение, пожарная автоматика и другие.

Это не просто «другой текст инструкции». Это разный инженерный контекст:

• Для ПВУ типичная логика — каскадное ПИД-регулирование температуры притока, блокировки по противоморозной защите, управление рекуператором. Характерные переменные — rTempSupply, rTempReturn, xFrostProtection.

• Для конвейера это совсем другое: секвенсоры пуска, блокировки по натяжению ленты, контроль скольжения, аварийный останов с фиксацией причины.

• Для водоподготовки — управление насосами подкачки, контроль уровней в баках, дозирование химреагентов, управление фильтрами.

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

Доступные AI-провайдеры

Облачные модели подключаются API-ключом инженера (ключи хранятся только на вашем компьютере):

• DeepSeek — рекомендуется как оптимальный по соотношению цена/качество для генерации ST

• OpenAI GPT-4 — сильная общая логика рассуждений

• Anthropic Claude — аккуратная обработка сложных многоуровневых требований

• Google Gemini — гибкий, используется в том числе для авто-тегирования проектов

Все модели можно запускать одновременно: один запрос уходит параллельно во все движки. Вы получаете несколько вариантов кода на одну и ту же задачу и выбираете лучший — или сравниваете их в режиме аудита (один ИИ проверяет код другого).

Три специализированных агента

Помимо прямого вызова языковых моделей, в систему встроены три инженерных агента. Агент — это не просто «ещё один ИИ». Это организованная цепочка шагов с проверками, которая управляет тем, как именно ведётся генерация.

R2-PLCGen: имитация работы проектной группы

Этот агент строит код не «одним куском», а по цепочке ролей. Идея в том, что хорошая программа ПЛК проектируется в несколько этапов — так же, как делает опытная команда.

Роль 1 — Архитектор.
Анализирует задачу и составляет план программы:

• Имя программы

• Перечень POU (какие функциональные блоки нужны)

• Порядок их вызова в главном цикле

• Правила безопасности: что в случае потери связи, что при ошибке датчика

Роль 2 — Генератор.
Берёт план архитектора и пишет черновик ST-кода. Параллельно — SFC-диаграмму (не менее 4 состояний: минимально это «Готов», «Пуск», «Работа», «Останов»).

Роль 3 — Верификатор.
Запускает три независимые проверки:

1. Семантический анализ — ловит логические ошибки

2. Компилятор matiec — настоящий компилятор, не имитация

3. Проверка SFC — корректность диаграммы состояний

4. Сверка: все ли POU из плана архитектора присутствуют в коде?

Роль 4 — Рефлектор.
По замечаниям верификатора вносит точечные правки. Если остаются ошибки — цикл повторяется.

Особая защита: если исправленный код стал заметно короче черновика — это подозрительно. Скорее всего, ИИ где-то «срезал» логику, выбросив блоки, которые не мог исправить. Система это обнаруживает и откатывается к предыдущей версии.

Agents4PLC: генерация по образцам

Этот агент работает по принципу «сначала найди похожее — потом пиши». Это важная идея: вместо того чтобы каждый раз «придумывать» программу с нуля, лучше взять проверенный образец и адаптировать его под конкретную задачу.

Встроенный каталог покрывает типовые задачи АСУ ТП:

• Пуск/останов насоса с блокировками

• Управление клапаном с контролем положения

• ПИД-регулирование температуры (пропорционально-интегрально-дифференциальный регулятор)

• Секвенсор: автоматическая последовательность шагов

• Watchdog-таймер: контроль «живости» программы

• Шкалирование аналогового сигнала 4–20 мА в инженерные единицы

• Фильтр нижних частот (для «грязных» аналоговых сигналов)

• Каскадное регулирование (внешний контур по давлению, внутренний — по расходу)

• Управление частотным преобразователем

• Аварийный останов категорий SS1/SS2 (по ГОСТ Р МЭК 62061)

По ключевым словам задачи агент подбирает три ближайших образца, передаёт их модели как примеры — и модель пишет код для вашей конкретной задачи по этому образцу.

truST Platform: строгий стиль и аудитор

Этот агент работает в двух режимах.

Режим генерации — код пишется в строгом инженерном стиле:

• Венгерская нотация имён переменных: x — BOOL (булева), r — REAL (вещественная), i — INT (целая), w — WORD, t — TIME. Это соглашение о наименованиях, которое делает код читаемым без комментариев: увидел rTempSupply — сразу ясно, что это вещественная переменная температуры притока.

• Обязательный заголовок-комментарий у каждого POU: название, назначение, автор, версия.

• Фиксация фронтов только через R_TRIG / F_TRIG — стандартные блоки обнаружения переднего/заднего фронта. Никаких самодельных детекторов «предыдущее значение XOR текущее».

• Явный сброс выходов в начале каждого скана — чтобы не было «залипших» выходов при ошибках.

Режим аудитора — агент выступает как старший инженер: анализирует чужой код и выдаёт перечень замечаний, не переписывая его. Это важно: аудит — не переработка, а рецензия. Инженер сам решает, какие замечания учитывать.

Шаг 4. Проверка сгенерированного кода

Это сердце принципа «не угадывать — проверять фактами». Сгенерированный ST не отдаётся инженеру сразу — он проходит два уровня независимой проверки.

Tier S — программный симулятор ПЛК

Симулятор исполняет ST по сканам без настоящего компилятора. Он отслеживает состояния выходов, поведение ^[5] функциональных блоков, обнаруживает неизвестные блоки (если ИИ «изобрёл» FB, которого не существует).

Это поведенческая проверка: симулятор проверяет не то, правильно ли написан код формально, а то, что делает программа при разных входных условиях. Например: «если датчик перегрева срабатывает, выключается ли насос?»

Tier H — настоящий компилятор matiec

Здесь код компилируется в C — это настоящий компилятор, не имитация. Если в ST есть ошибки — компилятор их найдёт.

Когда matiec выдаёт ошибку, система:

1. Разбирает сообщение об ошибке — номер строки, описание

2. Формирует «fix-промпт»: «в строке 47 ошибка: переменная EN зарезервирована, переименуй её»

3. Отправляет в языковую модель на исправление

4. Повторяет — до трёх попыток или до returncode=0 (успешная компиляция)

После прохождения обоих уровней результаты сравниваются между собой — кросс-валидация. Расхождение (симулятор говорит «ОК», компилятор видит ошибку) — отдельный сигнал для инженера.

Детерминированный ремонт — без ИИ

Некоторые ошибки исправляются без участия языковой модели — алгоритмически, точно и предсказуемо.

Пример: стандарт МЭК 61131-3 резервирует имена EN и ENO как стандартные входы/выходы «разрешение» функциональных блоков. ИИ иногда объявляет переменную с таким именем в обычном VAR-блоке — это гарантированная ошибка компилятора. Детерминированный ремонт находит такую переменную и переименовывает её точно, не трогая легитимные вызовы EN := ... как параметра вызова функционального блока.

Принцип простой: там, где нет неопределённости — не нужно тратить ИИ. Детерминированный ремонт срабатывает первым, до отправки в языковую модель. Это быстрее, дешевле и надёжнее.

Шаг 5. AI-Аудит и цикл исправления

После генерации и проверки компилятором инженер может запустить AI-Аудит: один ИИ рецензирует код, сгенерированный другим.

Аудитор выдаёт перечень замечаний. По кнопке «Исправить» — код правится и повторно проходит аудит в том же окне. Аудит не закрывается после первого исправления — цикл продолжается, пока инженер не удовлетворён результатом.

Любой из провайдеров может выступать аудитором для кода другого. Например: DeepSeek генерирует, Claude проверяет — потому что у них разные «взгляды» на правильность кода. Это даёт дополнительный независимый взгляд.

Шаг 6. Контроль инженера — финальное решение всегда за вами

Система принципиально не пытается принять решение за инженера. После всех проверок вы видите:

• Результат каждого движка — можно сравнить несколько вариантов

• Схемы SFC / LD / FBD с возможностью редактирования

• Матрицу трассируемости требований (о ней ниже)

• Кнопки для запуска дополнительного аудита, экспорта в нужный формат, формирования отчёта по ГОСТ

Код можно редактировать прямо в программе, потом снова отправить на компиляцию и аудит. Цикл «правка → проверка → аудит» не ограничен.

Визуальные редакторы: SFC, LD, FBD и SCADA-мнемосхема

Все четыре редактора — полноценные графические, работают офлайн.

SFC — диаграмма последовательных состояний

Программа строит SFC двумя способами:

Диаграмма состояний (Mermaid-граф) — наглядная схема переходов: из какого состояния в какое, при каких условиях.

Графический редактор — интерактивная SFC-схема: шаги, переходы с условиями, действия с квалификаторами (N — непрерывное, S — установить, R — сбросить, P — по фронту), параллельные (AND) и альтернативные (OR) ветви. Структура автоматически разбирается из CASE-автомата в ST-коде и строится как схема.

LD — релейно-контактная схема

Для инженеров, привыкших к схемам релейной логики: контакты (НО/НЗ, по фронту), катушки (обычная / инверсная / Set / Reset), таймеры и счётчики. Ступени с одинаковым условием объединяются с параллельными катушками — как в настоящей LD-схеме. Можно редактировать и экспортировать обратно в ST.

FBD — функциональные блоки

Каталог блоков: логика (AND, OR, NOT, XOR), триггеры (SR, RS, R_TRIG, F_TRIG), таймеры (TON, TOF, TP), счётчики (CTU, CTD), арифметика и сравнение. Блоки соединяются проводами, граф раскладывается слева направо автоматически (с защитой от циклических зависимостей).

SCADA-мнемосхема

Это технологическая схема «как работает система» — не для программирования, а для показа заказчику и согласования.

ИИ читает ТЗ и извлекает структуру установки: перечень аппаратов, датчиков, исполнительных механизмов. Программа строит схему детерминированно: аппараты расставляются по ходу потока среды (например, для ПВУ: заслонка → камера смешения → фильтр → калориферы → охладитель → увлажнитель → вентилятор), датчики КИП показываются на выносках, защиты и аварии выносятся отдельной группой.

Режим «▶ Поток» — схема «оживает»: значения датчиков начинают меняться. Удобно для демонстрации логики работы заказчику на приёмке.

RAG-память: программа учится на ваших проектах

RAG (Retrieval-Augmented Generation — генерация с поиском по базе знаний) — это один из ключевых механизмов повышения качества.

Порог похожести — ≥ 0.15, минимальное качество для использования как образца — ≥ 2 звезды. Это фильтрует случайные или некачественные примеры.

Простая логика: чем дольше инструмент работает на ваших типовых объектах — тем точнее становятся генерации. Если вы постоянно делаете приточные установки одного типа, система постепенно накапливает ваши проверенные решения и воспроизводит их стиль.

Память можно редактировать и чистить. Если пример оказался неудачным — его можно удалить, чтобы он не «портил» будущие генерации.

Свои библиотеки функциональных блоков

В каждой организации за годы работы накапливаются проверенные и отлаженные функциональные блоки: ваш FB управления насосом, ваш FB диагностики клапана, ваш FB масштабирования под конкретные типы датчиков.

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

Экспорт под конкретные контроллеры

Программа не «заливает» код в контроллер по сети — для этого нужны закрытые фирменные SDK, которые у каждого вендора свои. Вместо этого она адаптирует код под диалект конкретной среды и выдаёт файл, готовый к импорту.

Систему драйверов можно расширять: положите .py-файл коннектора в папку drivers рядом с программой — он подхватится без пересборки.

Brownfield: анализ чужого кода без документации

Отдельный режим для ситуации, которая знакома многим: вам передали проект, в котором 2000 строк ST, документации нет или она устарела, и нужно разобраться, что вообще делает эта программа.

Программа анализирует существующий ST, реконструирует требования — что, по всей видимости, делает этот код — и сравнивает с загруженным ТЗ. Результат: перечень расхождений.

• Что реализовано корректно

• Что пропущено (в ТЗ есть, в коде нет)

• Что реализовано иначе, чем написано в ТЗ

• Что реализовано, но в ТЗ не описано (недокументированная логика)

Формируется отчёт в DOCX. Не нужно читать 2000 строк вручную, чтобы понять общую картину.

Матрица трассируемости требований

Каждое требование из ТЗ привязывается к конкретному фрагменту сгенерированного кода. Видно: в каком именно POU реализовано требование «защита от перегрева», где в коде обрабатывается «блокировка при низком давлении».

Это одновременно:

• Внутренняя проверка полноты: если требование ни к чему не привязалось — значит, оно не реализовано, и это сигнал

• Документация для сдачи проекта: часть заказчиков (особенно в промышленной автоматизации с жёсткими требованиями) просят такой документ при приёмке

Отчёт по ГОСТ

Одной кнопкой формируется пояснительная записка в DOCX по ГОСТ 21.408-2013 («Системы автоматизации технологических процессов»): титульный лист, шифр проекта, стадия, структура документа.

Готовый файл открывается в Word и дорабатывается под конкретного заказчика. Шаблон соответствует требованиям ГОСТ — не нужно каждый раз собирать структуру вручную.

Что дальше: многосистемный режим

Всё описанное выше работает для одной установки: один IOLIST + одно ТЗ → один ST-файл. Для большинства задач этого достаточно.

Но реальный крупный объект — это не одна установка. Это N – колличество систем с разными ПЛК, которые работают в единой цепочке:

• ПВУ зоны сборки не пускает конвейер, пока не вышла на режим

• Пожарная тревога переводит ПВУ в режим дымоудаления и останавливает конвейер

• Водоподготовка продолжает работать автономно

• Система холодоснабжения реагирует на загрузку конвейера

Каждая система живёт в своём техническом задании, но связи между ними нигде толком не формализованы. Инженер держит это в голове или, в лучшем случае, в Excel.

Я разрабатываю многосистемный режим. Он позволит загрузить ZIP-архив с папками систем (в каждой — своё ТЗ и IOLIST) и пройти расширенный маршрут:

1. Распознавание систем — разбор архива, реестр всех систем и точек ввода-вывода

2. Категоризация — ИИ предлагает категорию каждой системы (bms_hvac, conveyor, water_treatment, …), инженер подтверждает или правит. Это определяет, какой доменный промпт получит каждая система при генерации

3. Карта связей — на основе общего ТЗ взаимодействий ИИ строит граф зависимостей. Инженер верифицирует его перед генерацией

4. Критические запреты — правила уровня объекта, которые обязательны для всех систем. Подмешиваются в промпт каждой системы

5. Распределение по контроллерам — какие системы в какой ПЛК. Определяет, какие POU объединяются в один проект, какие GVL-переменные нужны для межсистемного обмена

6. Ревью-гейт — инженер подтверждает всю картину: системы, связи, группировку, список запретов — и только потом генерация

После ревью-гейта каждая система генерируется с общим контекстом всего объекта. GVL-переменные (глобальные переменные для обмена между системами) создаются автоматически на основе карты связей. Кросс-валидация проверяет, что переменные, которые одна система должна передавать другой, корректно объявлены с обеих сторон.

Это не «пусть ИИ угадает связи». Это «инженер явно верифицирует понимание системы, прежде чем нажать кнопку».

Вопросы к сообществу

Именно ради этого я публикую статью сейчас, до окончания разработки. Мне важно услышать инженеров-практиков.

По базовому режиму (одна установка):

• Какие типовые ошибки вы видели при попытках использовать «голый» ИИ для написания ST? Что чаще всего ломается?

• Матрица трассируемости требований — это полезно для ваших проектов, или лишний overhead? Требуют ли заказчики такой документ при приёмке?

• Brownfield-анализ: насколько часто в реальности приходится разбираться в чужом коде ПЛК без документации?

• Какие категории установок чаще всего встречаются в вашей практике — может, каких-то нет в девяти существующих промптах?

По многосистемному режиму:

• Как вы сейчас документируете межсистемные зависимости? Есть какой-то стандарт, или это всегда «как получилось»?

• Распределение систем по ПЛК: это решение проектировщика, или чаще определяется вендором комплектации?

• Как часто в одном проекте CODESYS оказывается несколько технологических систем? Как вы тогда структурируете POU и GVL?

Жду ваших комментариев — особенно критических. Отвечу на всё.