В начале 2024 года казалось, что LLM скоро заменят половину инженерной работы. Сейчас, когда первые эксперименты прошли, картина трезвее: где-то ChatGPT сэкономил часы, где-то подсунул красиво написанную ошибку в логике безопасности, и никто этого сразу не заметил. Истина предсказуемо посередине, но конкретика важна.
Эта статья про опыт применения LLM в реальных задачах АСУ ТП, а не про “искусственный интеллект меняет промышленность”.
Короткий ответ
LLM хорошо работает как ускоритель рутины: документирование, шаблоны кода, разбор лог-файлов, перевод спецификаций. Там, где нужна верификация логики безопасности или точное знание вендор-специфики, модель галлюцинирует с уверенным видом и проверять надо обязательно.
Самое очевидное применение — документирование. Инженер пишет функциональный блок, скармливает его модели и получает читаемое описание: что делает, какие входы/выходы, какие ограничения. То, на что раньше уходил час в конце смены, делается за три минуты. Качество достаточное для внутренних вики и комментариев к коду.
Похожая история с разбором лог-файлов и аларм-журналов. Если дать модели несколько сотен строк из historian или SCADA и попросить найти паттерн, она справляется на уровне джуниора: выделяет повторяющиеся события, предлагает гипотезы. Это не замена инженерному анализу, но хорошая точка старта.
Генерация шаблонного кода — ещё одна рабочая зона. Структура функционального блока на ST, обёртка для Modbus-запроса, процедура бэкапа в скрипте — всё это модель делает быстро и достаточно аккуратно, особенно если дать ей контекст: вендора, версию, ограничения. Дальше инженер правит детали, а не пишет с нуля.
Хорошо работает и переформулировка технических требований. Часто ТЗ написано так, что из него непонятно, что именно должен делать ПЛК. LLM помогает структурировать требования, задаёт уточняющие вопросы и предлагает варианты интерпретации — по сути берёт на себя работу системного аналитика для первого прохода.
Где LLM не помогает или создаёт иллюзию помощи
Проблемы начинаются, как только задача требует точного знания конкретного вендора. Попросите ChatGPT написать логику для Siemens S7-1500 с учётом ограничений OB35 и поведения при CPU restart — модель напишет что-то похожее, уверенным тоном, но детали будут неточными. Это не потому что она “не знает Siemens”, а потому что у неё нет актуальной версии документации и нет механизма неуверенности в своём ответе.
Аналогично с расследованием инцидентов, где важны точные временны́е метки и причинно-следственные связи. LLM строит логичную историю, но она может быть правдоподобной выдумкой, а не реальной цепочкой событий.
Регуляторные документы и стандарты — ещё одна ловушка. Модель уверенно цитирует требования IEC 61511 или ГОСТ, но конкретные пункты, даты редакций и формулировки может перепутать. Для официальных документов исходник обязателен.
Где LLM опасен — зона с красными флажками
Самый серьёзный риск — когда LLM применяют к логике безопасности без строгого ревью. Модель может написать interlock, который выглядит правильно, но не учитывает edge case: что происходит при потере связи, при одновременных отказах, при ручном override. Это не баг модели, это её природа: она оптимизирует правдоподобность, а не корректность.
Вторая опасная зона — решения, которые идут в прод без проверки. Если команда привыкает доверять выводу LLM “потому что звучит правдиво”, риск накапливается незаметно. Один незамеченный баг в алгоритме аварийной остановки стоит больше, чем вся сэкономленная документация за год.
Таблица: задача → что даёт LLM
Как использовать LLM без иллюзий
Рабочий режим: LLM как старший черновик, инженер как финальный судья. Модель ускоряет создание первой версии, а человек проверяет логику, соответствие вендору и граничные сценарии. Это не “доверяю или не доверяю”, это смена привычки — проверять выход LLM так же серьёзно, как стажёрский код.
Второе правило: давать модели контекст. “Напиши блок для ПЛК” и “Напиши функциональный блок на ST для Siemens S7-1500 TIA Portal v18, управление насосом с защитой от сухого хода, сигнал от датчика давления 4–20мА, блокировка при P < 1.5 бар” дают принципиально разный результат. Чем конкретнее промт, тем ближе к рабочему коду выход.
Что будет дальше
Производители PLC IDE уже интегрируют LLM внутрь сред разработки: Siemens, Rockwell, Schneider начали встраивать AI-ассистентов напрямую в engineering tools. Это принципиально меняет контекст — модель будет видеть проект, схемы и документацию вендора, а не только текст в диалоге. Тогда часть сегодняшних ограничений уйдёт. Пока этого нет, работает простое правило: рутина — LLM, критика — инженер.
Где уместен СТАБУР
В командах с несколькими объектами и потоком документации LLM ускоряет типовые задачи — особенно там, где нужно стандартизировать описания, адаптировать шаблоны и структурировать требования. В проектах на базе решений СТАБУР это работает как инструмент скорости, но не замены инженерного суждения.
Заключение
LLM — это не волшебный инженер в облаке и не бесполезная игрушка. Это инструмент со своими зонами силы и зонами риска. Инженер, который понимает эти границы, получает реальное ускорение. Тот, кто верит красиво написанному тексту без проверки, рано или поздно прогоняет это через аварийную остановку или аудит.
FAQ
Можно ли доверять LLM для разработки логики ESD?
Нет. Логика аварийной защиты требует верифицированного ревью, независимо от того, кто написал первый черновик.
Какая модель лучше для задач АСУ ТП?
Разница между топовыми моделями меньше, чем качество промта. Давайте контекст, и результат улучшается на порядок быстрее, чем при смене модели.
Стоит ли обучать LLM на внутренней документации?
Для крупных команд — да, если данные можно отдать в fine-tuning или RAG без нарушения конфиденциальности.
Что делать, если LLM написал код, а никто не понял как проверить?
Это сигнал, что инструмент применяется раньше, чем команда готова к нему. Начинать надо с менее критичных задач.
Стоит ли запрещать LLM в проектной команде?
Запрет не работает — люди используют сами. Лучше ввести явный регламент: что можно делегировать, что требует ревью, что под запретом.