Может ли ИИ самостоятельно разобраться в проекте Siemens TIA Portal? Опыт разработки OpennessLLM

[pytraveler]

Спасибо, ключевая мысль статьи - “не держи все в голове, а сходи посмотри” - по-моему, важнее самого инструмента. Мы годами пытались скормить модели весь проект целиком, а выигрыш дает ровно обратное: дать ей навигацию и позволить самой собрать контекст. И ваш вывод про то, что экономия идет на понимании чужой программы, а не на генерации кода, совпадает с моими ощущениями: в АСУ ТП 80% времени - это археология, а не набор текста.

Вопрос по существу: что происходит на проекте, где половина блоков под know-how protection, а половина - versioned library types? Мне интересно, агент увидит внятную ошибку или просто “пустой” блок?

[Zibitpnz]

Вопрос хороший, думаю практика покажет как оно на самом деле. В моем основном проекте этих блоков не было, так как проект на 100% был самописный. Однако, как упоминалось в статье, была нужда прикрутить модули ввода-вывода ОВЕН по протоколу ModbusTCP и Сименс давал возможность для WinAC RTX использовать ноу-хау библиотеку, но платно, по лицензии. В текущих реалиях это было нереально. Поэтому LLM сама написала блок обмена по протоколу под эти модули. Да, пришлось попотеть немного с этим обменом, но зато это открыло мне широкие возможности на будущие подобные проекты там где нужен этот протокол. Но это ограничение софт-контроллера, а на "железных" PLC эти библиотеки протокола ModbusTCP поставляются без дополнительных лицензий.

В целом проект OpennessLLM достаточно молодой и по-хорошему нужно массовое тестирование для дальнейшего его развития.

P.S. В статье забыл упомянуть, что инструмент проверялся на 20 и 21 версии TIA Portal.

[CrushBy]

А самое интересное тут всё-таки не генерация SCL и даже не поиск по коду, а возможность агента самому проверить свои выводы на работающей системе.

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

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

А можно увидеть что-то подобное для TIA Portal, именно как это работает вживую ? Например, дать агенту открытый незнакомый проект и попросить найти цепочку какого-нибудь сигнала, проверить гипотезу, подготовить изменение и скомпилировать его. Интересен именно полный ход работы агента и что у него получится, а не только итоговое описание.

[Zibitpnz]

Вживую показать простыню из VS Code - такое себе))
Могу лишь своими словами рассказать как устранялась небольшая проблема с восстановлением связи отключенных во время работы PLC нескольких шкафов управления. То есть ситуация не совсем штатная была. ModbusTCP просто повторно не поднимался. Натравив на эту проблему агента выстроилась гипотеза и под нее агентом был написан скрипт диагностики связи в реальном времени с PLC. Во время локализации проблемы я отключал шкафы управления, воспроизводя когда связь не сможет подняться. Скрипт тем временем писал данные с PLC в журнал. Затем агент проанализировал журнал работы ModbusTCP и приступил "лечению". Записал в PLC нужные значения, чтобы проверить гипотезу. Связь поднялась. Затем была скорректирована и сама программа PLC. В итоге проблемы со связью ушли полностью, даже при нештатных ситуациях.

По поводу совсем чужих проектов - да, пробовал. Ходит, ищет, объясняет. Но сам я в чужой проект не погружался, чтобы адекватно оценить его работу. По моему проекту агент работает и работает хорошо.

[Zibitpnz]

В качестве примера могу привести небольшой лог исправления проблемы:

---

Удалось существенно сузить проблему без изменения кода. Что доказано Повторная запись Client.DisconnectReq := TRUE в зависшем m31 восстановила связь: State: 90 → 95 → 30 → рабочие 40/50/60 Online/DataValid: FALSE → TRUE PollCounter: 689 → 7805 и продолжил расти Затем проверил два сценария:

• штатное отключение здорового m31 через m31_MB_enbl работает корректно;

• искусственный 16#8001 через TimeoutCycles := 1 также восстанавливается автоматически. Следовательно, проблема возникает не при любом таймауте. Она специфична для физического исчезновения TCP-устройства. Наиболее вероятны два сценария:

1. Первоначальный TDISCON.REQ при физическом обрыве не принимается и остаётся STATUS=7000.

2. TDISCON возвращает временную ошибку 80C4; код формирует повторный DisconnectReq, но на следующем цикле строка 204 стирает его из-за NOT Enable.
   
   
   В обоих случаях клиент остаётся в State=90 без активной операции. Повторный фронт DisconnectReq полностью его оживляет. Сейчас m31 оставлен в нормальном состоянии: m31_MB_enbl = TRUE TimeoutCycles = 2000 Online = TRUE DataValid = TRUE Временная карта записи внутренних полей удалена. Результаты добавлены в раздел 13 и раздел 14. Для окончательного выбора между 7000 и 80C4 нужен один физический цикл отключения m31 под высокочастотным мониторингом. Сообщи, когда будешь готов отключить m31 примерно на 5–10 секунд и затем снова включить: я запущу сбор состояния непосредственно перед этим.
   
   ----
   
   

   Журнал остановлен. Эксперимент дал однозначный результат:

   • m21–m23 синхронно застряли в State=90.

   • TDISCON: REQ/DONE/BUSY/ERROR=FALSE, STATUS=16#7000.

   • Счётчик ошибок отключения остался 0.

   • Внешний автомат продолжает попытки, но общий клиент из состояния 90 уже не выходит.

   • m24–m26 в том же шкафу восстановились примерно за 10 секунд, значит сеть и питание шкафа вернулись нормально. Это подтверждает временную гонку в FB_ModbusTcpClient: единственный импульс DisconnectReq теряется или не принимается, а повтор и watchdog в состоянии 90 отсутствуют. Полный результат записан в ModbusTCP_Reconnect_State90_Analysis_RU.md. Исходный журнал: reconnect-monitor-20260822-112433. PLC-код и значения модулей не изменялись. Следующий шаг: подготовить осторожный план исправления общего клиента с повтором TDISCON.REQ и ограниченным watchdog состояния 90.
     
     ----
     
     

     План подготовлен: FB_ModbusTcpClient_State90_Recovery_Change_Plan_RU.md. В нем зафиксированы:

     • устранение гонки Enable/DisconnectReq;

     • ограниченный повтор TDISCON.REQ;

     • watchdog состояния 90;

     • запрет нового TCON, пока TDISCON.BUSY = TRUE;

     • сохранение структуры и смещений DB;

     • точка восстановления, поэтапная проверка всех клиентов и условия отката. В аналитический документ добавлена ссылка на план. PLC-код и значения контроллера не изменялись. Следующий этап требует отдельного подтверждения: создание точки восстановления и offline-изменение общего клиента.