Началось всё с обычного чата. Копируешь кусок SCL, описываешь задачу, получаешь объяснение или готовую функцию. На мелочах это работает нормально, спорить не буду.

Но модель видит только то, что ей показали. Если ошибка сидит в одном блоке, этого хватает. В реальном проекте так почти не бывает: сигнал формируется в одном месте, проверяется в другом, сохраняется в DB, участвует в куче условий и в итоге влияет на что‑то третье. И начинается беготня: скопировал блок, вставил; модель просит DB, пошёл нашёл, вставил; просит место, где сигнал сбрасывается, опять ищешь. Через полчаса понимаешь, что ты уже не инженер, а курьер между TIA Portal и чатом.

В какой‑то момент надоело. Почему модель вообще должна ждать, пока я принесу ей очередной кусок? Пусть сама лазит. Так появился OpennessLLM.

Почему хорошего знания SCL мало

SCL модели знают прилично. Таймер, конечный автомат, обработку аварий, обмен по Modbus напишут без вопросов. Но это будет код из вакуума. Модель не в курсе, что в вашем проекте аварии оформлены вот так, что состояния механизмов лежат в отдельном DB, что номера блоков до такой‑то цифры уже заняты и что половина красивых решений из документации у вас считается лажей, за которую потом спрашивают с автора.

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

Мне нужен был не генератор фрагментов, а помощник, способный сам собрать контекст внутри проекта.

Что это технически

OpennessLLM это программа под Windows, которая через официальный TIA Portal Openness API даёт агенту доступ к проекту. Своей нейросети в ней нет и ничего она не придумывает: прослойка плюс набор команд, которые дергает LLM‑агент.

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

Первый запуск

Хотелось, чтобы установка тоже не делалась руками. Открываешь рабочую папку в агенте и пишешь примерно так: поставь OpennessLLM с гитхаба и подключись к открытому проекту TIA Portal. Дальше модель сама находит репозиторий, скачивает, собирает, запускает внутреннюю проверку, подбирает PublicApi под вашу версию TIA Portal и лезет подключаться.

Один нюанс, о котором лучше знать заранее: пользователь Windows должен состоять в локальной группе Siemens TIA Openness. Если его там нет, подключение падает. Модель, правда, сама разберёт ошибку и объяснит, что делать, но после добавления в группу всё равно придётся перелогиниться в Windows, иначе новые права не подхватятся. Это единственное место, где участие человека неизбежно, и тут я Siemens понимаю: безопасность есть безопасность.

И вообще команды OpennessLLM по задумке интерфейс для агента, а не для инженера. Человеку не нужно помнить их синтаксис: он формулирует задачу обычным языком, а нужные действия модель выбирает сама.

Почему не «выгрузить всё в XML и отдать модели»

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

XML у TIA Portal чудовищный: служебные атрибуты, GUID на каждый чих, обёртки ради обёрток. Проект среднего размера разворачивается в файл, который и человеком‑то не читается, а контекстное окно не резиновое. Но даже если бы влезало, редактировать такой XML по догадкам опасно: внутри связи по внутренним идентификаторам, тронул не то и здравствуй, битый проект.

Поэтому OpennessLLM строит локальное файловое представление: исходники PLC‑блоков, их типы и номера, кто в какой группе лежит, какие instance DB к каким FB относятся, контрольные суммы, отчёт о состоянии. Модель сначала получает общую картину, потом открывает только то, что нужно под конкретную задачу. Разбираемся с одним сигналом: она находит, где он упоминается, читает связанные блоки и постепенно восстанавливает цепочку, а не глотает весь проект.

По сути это навигационный слой. Не «держи всё в голове», а «сходи посмотри», как живой инженер ходит по кросс‑ссылкам.

Разбор существующей программы

Самая полезная для меня часть. Та самая работа, где раньше часами ходишь по блокам туда‑сюда.

Запрос выглядит примерно так: разберись, где формируется этот сигнал, от чего он зависит и что может мешать его установке. Дальше агент сам ищет упоминания, открывает блоки, смотрит присваивания, лезет в структуры данных. Не всегда попадает с первого раза, бывает, что первая гипотеза оказывается мимо. Но разница с обычным чатом принципиальная: модель не просит принести ещё кусочек, а идёт и проверяет сама.

Отдельно скажу про сравнение однотипных кусков. В проектах с несколькими похожими механизмами блоки выглядят почти одинаково, а отличаются одним условием где‑то в середине, и вот из‑за него один конвейер живёт не так, как остальные. Глазом это ловится отвратительно, а тексты исходников модель сравнивает прилично.

Реальный проект: адресные накопители и конвейеры

Всё это обкатывалось на моём проекте управления адресными накопителями и адресными конвейерами.

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

Синтаксические ошибки искать неинтересно, их компилятор найдёт и без LLM. Ценность была в логике. Неочевидная ошибка никогда не выглядит как «вот неправильная строка»: каждый кусок по отдельности корректен, а не работает всё вместе, при определённой последовательности состояний или сочетании условий.

Работа выглядела так: я описываю наблюдаемое поведение, модель лазит по проекту, выдвигает гипотезу, проверяет связанные места. Что‑то подтверждается, что‑то нет. Итерации. Кнопки «найти ошибку» не было и нет. Но ручной сбор контекста для модели исчез, и скорость анализа заметно выросла.

А ещё был побочный эффект, которого я не ожидал: свежий взгляд. Когда месяцами ковыряешь одну программу, часть решений становится «ну а как ещё», и вопросов к ним ты уже не задаёшь. Модель не знает, что «оно всегда так работало», и иногда тычет ровно в то условие, на которое ты давно забил.

Новые блоки с нуля

Там же, в этом проекте, с нуля написаны блоки обмена между Soft‑PLC Siemens WinAC RTX и модулями ввода‑вывода ОВЕН по Modbus TCP.

Казалось бы, чего проще: попроси любой чат написать Modbus TCP на SCL, получишь что‑то очень похожее на пример из документации. Только в живой проект такое не вставишь. Надо знать, как в проекте устроены типы, где лежат состояния обмена, как оформлена диагностика связи, кто и в каком порядке всё вызывает и куда данные уходят дальше. Тут и пригодилось, что модель видела не только техническое задание, но и сам проект: смотрела, как оформлены соседние блоки, и писала в том же стиле. В результате блоки не валялись отдельным фрагментом из чата, они сразу создавались с учётом окружающей программы.

Дальше обычный цикл: подготовили исходники, передали изменения в TIA Portal, скомпилировали, диагностические сообщения вернулись модели, она поправила, снова компилируем. Архитектуру и финальные решения определял я, но рутину написания и вылизывания кода она тащила сама.

Как вносятся изменения и почему я не отдал модели всё

Читать проект безопасно. Записывать в него уже нет. Давать LLM право молча перезаписывать всё, что она сочла правильным, я не собирался: ошибка в обычной программе это упавший тест, ошибка в автоматизации это уже про железо и людей.

Поэтому всё идёт через локальную рабочую копию. Модель читает актуальное состояние, предлагает план, правит локальные исходники. Перед применением OpennessLLM сам проверяет, какие блоки затронуты, нет ли конфликтов, не изменился ли проект в TIA Portal после последнего чтения и не пытается ли модель сделать потенциально опасную операцию. Если я успел руками поправить тот же блок, применение останавливается: иначе автоматизация затёрла бы свежую правку. В реальный проект ничего не пишется до явного разрешения, а также делаются резервные копии. После применения запускается компиляция, сообщения возвращаются модели, и она с ними разбирается.

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

Что осталось за человеком

Ограничения никуда не делись.

Модель не знает физику процесса, пока не объяснишь: она может идеально проследить программную цепочку и при этом неправильно понять, зачем сигнал нужен. Качество анализа зависит от имён: осмысленные названия и комментарии помогают не только людям. И нельзя верить результату только потому, что он уверенно сформулирован, проверять и тестировать по‑прежнему руками.

С графическими языками всё грустно. LAD, FBD и GRAPH в SCL не конвертируются, поэтому OpennessLLM их просто не воспринимает: работаем с текстовыми исходниками.

Нужен просто установленный TIA Portal, OpennessLLM его не заменяет и библиотек Siemens не содержит. В моём проекте стояла панель Weintek, так что про Siemens HMI сказать нечего: не пробовал, врать не буду.

Зачем опубликовал

Писал для себя, чтобы перестать использовать LLM как справочник и генератор фрагментов. Выросло в систему, на которой уже можно нормально работать, и после реального проекта стало понятно, что это может пригодиться не только мне. Проект лежит здесь: https://github.com/zibitpnz/OpennessLLM

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

Вместо заключения

Может ли LLM самостоятельно разобраться в чужом проекте TIA Portal? Смотря что называть «самостоятельно». Спроектировать систему, понять физику процесса, оценить требования безопасности не может. Найти нужный код, собрать контекст, проверить догадку, подготовить правку и разобрать, что сказал компилятор, может.

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