Слой рассуждений: LLM, агенты и MCP

Практическое руководство для системных интеграторов, OEM-производителей и инженеров по автоматизации — часть 2

В партнерстве с Томасом Стриглом, генеральным директором realvirtual.io

Об авторе: Томас Стригл является генеральным директором realvirtual.io и имеет более чем 18-летний опыт разработки программного обеспечения для моделирования и автоматизации.

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

В первой части этой серии электронных книг была представлена архитектурная основа современной машинной информационной системы: конвергенция динамических сигналов машин, контекста MES, структурированной документации и пространственных 3D-интерфейсов в единую рабочую поверхность. Также было рассмотрено, как новый регламент ЕС по машинному оборудованию и новые стандарты, такие как оболочка управления активами (AAS), переводят машинную документацию в структурированные машиночитаемые форматы. Именно эти основы — данные, связанные с компонентами, версионная документация и контекстуализированное состояние машины — позволяют использовать агенты искусственного интеллекта и большие языковые модели в промышленных средах.

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

Проблема с заземлением

Обычный первый подход к внедрению больших языковых моделей в промышленный контекст заключается в добавлении чат-бота к существующей системе — веб-сайту, порталу поддержки или HMI. На практике этот подход имеет ограничения.

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

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

Четырехуровневая архитектура, описанная в части 1, достаточно хорошо соответствует этому требованию. Сигналы обеспечивают текущее состояние. MES обеспечивает операционный контекст. Документация предоставляет авторитетные справочные материалы. Трехмерная сцена обеспечивает пространственный кадр, в котором все это может быть представлено.

MCP как модель интеграции

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

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

Для промышленного цифрового двойника особенно актуальны три категории серверов MCP:

• Сервер состояния компьютера, отображающий значения сигналов в реальном времени, состояния аварийных сигналов, положения дисков и недавнюю историю на основе существующего сигнального слоя (OPC UA, Beckhoff ADS, MQTT, S7 или потокового слоя на основе WebSocket).
• Сервер MES, предоставляющий заказы, пакеты, ключевые показатели эффективности и записи о качестве, поддерживаемый API-интерфейсами REST, брокерами сообщений или прямыми запросами к базе данных.
• Сервер документации, на котором представлен структурированный цифровой набор документации — инструкции по эксплуатации, схемы, декларации соответствия, версии программного обеспечения, процедуры обслуживания — с возможностью поиска и извлечения по идентификатору компонента, коду неисправности или естественному языку.

LLM, подключенный к этим трем серверам, имеет основу для обоснованных ответов. Такой вопрос, как «почему линия 3 остановилась?» На это можно ответить, прочитав состояние аварийного сигнала, определив неисправный компонент, извлекая соответствующий раздел по устранению неполадок из руководства и представив результат, указав затронутый компонент в 3D HMI. Выходные данные основаны на реальных системах, а не на обучающих данных модели.

Эталонная архитектура из раздела 6, описанная в части 1 этой серии электронных книг, относится непосредственно к этому слою. Описанные здесь службы обработки сигналов, MES и документации объединены серверами MCP, которые предоставляют им доступ через единый интерфейс. К этим серверам подключается среда выполнения LLM или агента, работающая локально, на пограничном сервере или в частном облаке, в зависимости от политики данных клиента. Полученные ответы основаны на текущем состоянии, текущем контексте и авторитетной документации.

3D HMI занимает первое место в стеке и обслуживает двух потребителей: оператора и любые инструменты на основе искусственного интеллекта. Инструменты искусственного интеллекта используют его как в качестве поверхности презентации (выделение компонентов, относящихся к ответу), так и в качестве поверхности подтверждения (отображение предлагаемых действий для проверки человеком). HMI написан на языке Unity и охватывает импорт САПР, кинематику, отображение сигналов и метаданные компонентов, которые будет использовать среда выполнения, и поставляется либо в виде встроенной в Unity сборки для настольных компьютеров, планшетов, AR/VR или промышленных ПК, либо в виде браузерного 3D-HMI на основе Three.js для развертываний WebGL. Один и тот же файл сцены, созданный Unity, экспортированный в GLB с одинаковыми идентификаторами компонентов, служит обеим целям доставки.

Открытая среда Unity на языке C# поддерживает обработку логических выводов напрямую — через Sentis и ONNX, как описано в электронной книге «Проектирование, моделирование, развертывание »: Почему Unity важна для Industrial Digital Twins и для работы в качестве интерфейса для внешних сред выполнения. Для большинства проектов интеграторов более простым подходом является отделение среды выполнения агента от HMI, а граница интеграции обеспечивается MCP.

Документация и заземление

Существует заметное совпадение между нормативным руководством и техническими требованиями к обоснованному выпуску LLM.

Исторически стоимость документации была вполне достижимой: она создавалась по мере необходимости, и к ней обращались относительно редко. Согласно Регламенту (ЕС) 2023/1230, документация может поставляться в цифровом виде, а если и есть, ее необходимо структурировать, использовать в интерактивном режиме и поддерживать в рабочем состоянии не менее 10 лет или в течение срока службы машины (обычно последний срок эксплуатации), учитывая, что промышленное оборудование редко выводится из эксплуатации по истечении установленного законом минимального срока. Как только документация представлена в такой форме, она также обладает свойствами, позволяющими использовать ее в качестве базового материала для языковых моделей: она структурирована, идентифицируется по компоненту или коду неисправности и наделена полномочиями производителя.

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

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

LLM как ускорители развития

Снижение стоимости интеграционных работ

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

Создание интегрированного цифрового двойника требует значительного объема работы, которая технически проста, но требует много времени. Код адаптера между сигнальным слоем и 3D-сценой. Клиенты REST или OPC UA для MES. Таблицы сопоставления переменных ПЛК и идентификаторов компонентов. Графики для конкретных проектов, информационные панели и небольшие компоненты пользовательского интерфейса в HMI. Работа со схемами для согласования разделов документации с компонентами сцены. Ни одна из этих задач не является особенно сложной; они выполняются вручную, повторяются и зависят от конкретного проекта.

Инструменты кодирования с помощью LLM позволяют сократить трудозатраты, необходимые для выполнения такой работы — создание адаптеров для нового MES API, составление компонентов каркасных диаграмм, составление сопоставлений между таблицами сигналов и кинематическими иерархиями. В результате интеграторы не перестают писать код, а в том, что рутинная работа по интеграции занимает меньше времени. Это важно в промышленном контексте, потому что использование небольших клеевых кодов, ориентированных на конкретные проекты, исторически было одной из основных причин дороговизны интеграционных проектов.

Почему стандартизированные интерфейсы важны

Этот эффект усиливается при стандартизации базовых интерфейсов. Серверы MCP, предоставляющие сведения о состоянии машины, данные MES и документацию, легче использовать для разработки с помощью LLM, чем специализированные API. Сочетание стандартизированных интерфейсов и разработки с помощью LLM снижает порог создания интегрированных цифровых двойников.

Пределы кода, генерируемого LLM

Стоит отметить два ограничения. Код, созданный LLM, представляет собой черновик, а не результат; для кода, относящегося к безопасности или системе управления, применяются те же процессы проверки и валидации, что и для любого другого кода. И это ускорение относится в первую очередь к работе по интеграции и визуализации, а не к базовой логике управления, за которую по-прежнему отвечают инженеры по автоматизации, использующие проверенные инструменты.

Разделение разработки и доставки во время выполнения

В этом контексте полезным архитектурным шаблоном является отделение среды разработки от доставленного артефакта. Средой разработки является Unity — признанная платформа для промышленных цифровых двойников, используемая в качестве редактора, в котором машиностроитель импортирует САПР, определяет кинематику, конфигурирует модели поведения и связывает документацию с компонентами. Unity предоставляет широкий набор инструментов, конвейер импорта САПР, поддержку кинематики и физики, а также многоплатформенные цели сборки, необходимые промышленным проектам. Однако поставленный артефакт работает в среде заказчика в течение всего срока службы машины и имеет преимущество в том, что он открыт и доступен для самостоятельного размещения: программа просмотра в браузере, созданная на основе стандартной веб-технологии (Three.js, TypeScript) и использующая стандартный формат сцены (GLB). Веб-просмотрщик realvirtual.io со стеком разработки на базе Unity, использующим веб-среду выполнения с открытым исходным кодом, лицензированную AGPL, является одним из примеров этой модели, используемой в настоящее время в производстве.

Более широкое значение для Индустрии 4.0

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

Агенты в цехе — спектр A

Термин «агент» охватывает ряд моделей поведения с совершенно разными профилями риска. Полезно уточнить, что имеется в виду.

• Самыми ограниченными возможностями являются диагностические инструменты, доступные только для чтения. Они наблюдают за состоянием, читают документацию и отвечают на вопросы. Они не пишут в системы управления. Оператор спрашивает, почему линия остановилась; система считывает состояние тревоги, ищет код в руководстве и объясняет. Это разумная отправная точка, а для ряда случаев использования также разумная конечная точка.
• В середине расположены консультативные инструменты. Они наблюдают за состоянием и предлагают действия — изменение заданного значения, задание на техническое обслуживание, корректировку параметров — но не выполняют их. Оператор подтверждает или отклоняет каждое предложение. 3D HMI может служить поверхностью подтверждения, отображая затронутый компонент и предлагаемое изменение пространственного контекста до начала записи. Эта модель позволяет человеку принимать решения в процессе принятия решений и при этом использовать искусственный интеллект для диагностики.
• Наименее ограниченными возможностями являются системы принятия мер, которые пишут на ПЛК, изменяют рецепты или отправляют заказы без одобрения человека на каждое действие. В некоторых случаях это технически возможно, но в соответствии с новым регламентом по машинному оборудованию возникают дополнительные соображения. Кибербезопасность теперь является важным требованием по охране труда и технике безопасности в соответствии с Приложением III, а функции безопасности на основе искусственного интеллекта прямо входят в перечень оборудования с высокой степенью риска, предусмотренный нормативным актом, что требует более строгой оценки соответствия. Любой путь, который позволяет системе, управляемой LLM, записывать данные в систему управления, также является потенциальным путем атаки. Такие системы, как правило, должны разрабатываться с такой же тщательностью, как и любой другой компонент системы управления с доступом к записи, включая обязательства по регистрации и записи данных, которые регламент устанавливает для программного обеспечения, связанного с безопасностью.

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

Практическая отправная точка для интеграторов

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

Первая практическая реализация могла бы включать:

• Использование существующего проекта станка: Начните с машины, на которой уже есть 3D-HMI и пакет структурированной документации, который готовится в соответствии с Регламентом (ЕС) 2023/1230.
• Предоставление документации через сервер MCP: Оберните набор документации на одном сервере MCP, поддерживающем поиск по идентификатору компонента.
• Подключение 3D HMI к службам документации: Настройте существующий 3D HMI так, чтобы при выборе компонента автоматически возвращался соответствующий раздел руководства.
• Добавление заземленного интерфейса AI: Добавьте к трехмерному виду панель чата с использованием универсального LLM, основанного на сервере документации MCP.

Ожидаемые результаты

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

Для интеграторов, которые хотят увидеть, как такая система может выглядеть на практике, на web.realvirtual.io/demo доступна публичная демонстрация 3D-HMI на базе браузера, использующего данные сигналов в реальном времени. Базовая архитектура — Unity в качестве среды разработки, открытый веб-стек для доставки и стандартная система управления версиями, такая как Gitea, для хранения доставленного пакета в течение десяти лет, установленных законодательством, — представляет собой паттерн, который интеграторы могут использовать и адаптировать к своим собственным проектам.

С этой отправной точки можно постепенно добавлять дальнейшие шаги. Сервер MCP сигнального уровня позволяет задавать вопросы о текущем состоянии. Подключение к MES позволяет задавать вопросы о текущих заказах. Консультативные рекомендации с подтверждением оператора в 3D HMI еще больше расширяют систему без изменения основного профиля рисков. Каждый шаг тестируется и обратим сам по себе.

Архитектура, поддерживающая соответствие требованиям и искусственный интеллект

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

В настоящее время интеграторы сходятся в двух сроках. Положение о машинном оборудовании известно с 2023 года, но практическая работа по подготовке заявки к дате подачи заявки 20 января 2027 года — новые обязательные положения о кибербезопасности и теперь уже явная опция структурированной цифровой документации с сопровождением жизненного цикла — переходит от планирования к исполнению. Параллельно инструменты искусственного интеллекта создают спрос на структурированные и обоснованные данные. Их можно решать как отдельные проекты, но основная работа в значительной степени дублирует друг друга. Четырехуровневая архитектура, описанная в части 1, поддерживает как оператора, так и любые инструменты искусственного интеллекта, добавленные позже. Структурированная цифровая документация, подготовленная для соответствия нормативным требованиям, также полезна в качестве справочного материала. 3D HMI может служить единой поверхностью для всех этих задач.

Эксплуатационные преимущества, описанные в части 1, — более быстрая диагностика, снижение порога экспертных знаний, контекстуализированная доставка информации, эффективная удаленная поддержка — применимы независимо от нормативного контекста. Интеграторы за пределами ЕС или работающие над системами, не подпадающими под регулирование в области машинного оборудования, получают те же эксплуатационные преимущества благодаря одной и той же архитектуре без необходимости соблюдения установленных нормативных сроков. Архитектура основывается только на эксплуатационной целесообразности; в регламенте просто четко определены сроки выхода на европейский рынок.

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