(Архитектура «умного» завода нового поколения: конвергенция OT, IT и ИИ, подтвержденная практикой)

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

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

Решение состоит не в создании очередного изолированного острова, а в построении трехуровневой архитектуры замкнутого цикла, объединяющей OT, IT и ИИ:

• Уровень восприятия (данные): Преобразование разрозненных данных в структурированные «состояния среды»;
• Уровень мышления (интеллект): Обеспечение способности машин рассуждать и планировать действия в рамках семантики и структур;
• Уровень исполнения (действие): Гарантия безопасного и прозрачного внедрения решений в реальных условиях.

Это не просто красивая презентация, а прототипы и решения, которые мы уже реализовали на симуляторах (NLDF Simulator, Factory Agent) и действующих предприятиях (завод в Фуяне).

Только представьте:

«Я почти заполнен, приостанавливаю подачу».
«Принято, подожду один цикл».

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

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

Теоретическая база

Человеческий интеллект основан на простом, но мощном замкнутом цикле: Восприятие → Мышление → Действие.

• Восприятие позволяет нам видеть мир, преобразуя внешние стимулы в информацию;
• Мышление позволяет нам придавать смысл, формируя суждения и планы;
• Действие позволяет нам изменять окружающую среду и совершенствовать наше познание посредством обратной связи.

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

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

Исходя из фундаментальных принципов, надежная система интеллектуальных агентов должна удовлетворять трем универсальным законам:

1. Восприятие должно быть пригодным для использования – Данные существуют не для накопления или хранения, они должны быть структурированы и смоделированы так, чтобы стать «состоянием мира», понятным и доступным для интеллектуальных агентов.

2. Интеллект должен быть объяснимым – Решения не должны быть результатами работы «черного ящика», они должны преобразовываться из языка в структурированные планы с прослеживаемой логикой и контекстом.

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

Таким образом, предлагаемая нами трехуровневая философская концепция — это не просто техническая архитектура, а универсальная абстракция для систем интеллектуальных агентов:

• Уровень восприятия (Данные): Организует фрагментированные данные в удобные для использования «состояния мира»;
• Уровень мышления (интеллект): Позволяет машинам рассуждать и планировать в рамках семантики и структур;
• Уровень действия (исполнение): Обеспечивает безопасное и прозрачное внедрение решений в реальном мире.

Это потребность не только завода, но и принцип, применимый к любой системе, пытающейся внедрить ИИ в физический мир.

«Без понятного восприятия нет объяснимого интеллекта; без контролируемого исполнения нет надежного замкнутого цикла».

Обзор архитектуры

Теперь мы можем использовать объяснимый, контролируемый и эволюционирующий «трехуровневый замкнутый цикл (восприятие–мышление–действие)» для объединения семантического восприятия → формирования решений → автоматизированного исполнения в сквозную промышленную интеллектуальную агентную систему.

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

Анализ многоуровневой архитектуры + соответствующие продукты для каждого уровня (общая таблица)

Уровень восприятия: от информационных разрозненностей к удобным для использования состояниям мира

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

Основная проблема: разрозненность данных

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

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

В результате с таким трудом собранные данные вместо того, чтобы стать «понятными и полезными ресурсами», превращаются в невозвратные затраты.

Единое пространство имен (UNS) — семантическая основа для устранения разрозненности данных

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

Техническая реализация UNS: семантическая организация на основе модели ISA-95

UNS (Unified Namespace) обычно использует древовидную модель для построения унифицированной семантической структуры данных, организуя сложные заводские объекты, производственные процессы и точки данных иерархическим и естественным образом. Модель ISA-95, являющаяся международным стандартом промышленной автоматизации, служит типичной парадигмой для реализации этой древовидной модели в UNS. Для достижения семантической организации модель ISA-95 широко применяется при построении иерархических физико-пространственных структур (например, предприятие, площадка, зона, рабочая ячейка, производственная линия), где каждое оборудование или линия связаны с данными о состоянии в реальном времени, данными о действиях или аналитическими данными (например, OEE), что упрощает навигацию и контроль. Семантическая организация UNS не только значительно сокращает количество информационных разрывов и несоответствий форматов, но и предоставляет интуитивно понятную «семантическую карту» для LLM-агентов, позволяя им применять «избирательное внимание» и «удержание контекста» к релевантным потокам данных в зависимости от их роли.

Решение: трехуровневая архитектура «Сбор → Организация → Представление»

Основная задача уровня восприятия (Sense Layer) заключается не просто в «захвате» данных, а в предварительном проектировании семантической структуры, системы именования и контекстных связей данных с учетом того, как их будут использовать потребители. Это критически важно для того, чтобы данные не становились разрозненными, а превращались в «язык и память» интеллектуального уровня, поддерживая принятие реальных решений и выполнение действий.

Традиционные промышленные системы часто используют бинарные протоколы или проприетарные форматы данных. Однако модели LLM лучше справляются с обработкой структурированной и осмысленной информации. Структура «ключ-значение» в JSON в высокой степени соответствует тому, как LLM обрабатывают связи и смыслы, что значительно раскрывает потенциал LLM за счет обеспечения семантической насыщенности, контекстуальной релевантности и возможностей иерархического мышления. В то же время топики MQTT предоставляют LLM-агентам самоописываемые пути к информации, позволяя им интеллектуально фильтровать и фокусироваться на нужных потоках данных, реализуя переход от традиционных механизмов опроса к событийно-ориентированным подходам, что значительно снижает информационную перегрузку.

Для достижения вышеуказанных целей уровень восприятия подразделяет обработку данных на следующие три основных этапа:

1. Сбор

Сбор данных из различных источников: ПЛК, датчиков, MES/ERP, журналов контроля качества и т. д. Сложность заключается в разрозненности протоколов и форматов, поэтому для доступа обычно используются стандартные интерфейсы, такие как OPC UA, шлюзы и API. В этом процессе ключевую роль также играют инструменты предварительной обработки на периферии, например Node-RED.

2. Организация

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

3. Представление

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

Данные будут храниться в трех типах баз данных:

• TSDB (база данных временных рядов): хранит высокочастотные данные с датчиков и исторические графики, поддерживая запросы в реальном времени и по историческим данным.
• Озеро данных (Data Lake): хранит мультимодальные данные (изображения, видео, документы, журналы), поддерживая офлайн-обучение, историческое моделирование и анализ воспроизведения. В сочетании с концепцией «облачного облегченного заводского Lakehouse» , подчеркивающей его легковесность и облачную архитектуру.
• Реляционная база данных: хранит структурированные бизнес-данные и метаданные.

Практики и кейсы платформы SupOS

SupOS — это платформа данных, использующая концепцию UNS и включающая следующие архитектурные компоненты:

• Source Flow: Построен на базе Node-RED и выступает в роли конвейера, соединяющего устройства и системы, преобразуя данные протоколов реального времени в JSON-пакеты.
• Namespace: Ядро SupOS, семантический MQTT-брокер и парсер на основе UNS, моделирующий данные с помощью иерархий топиков и структурированных JSON-пакетов.
• Sink: Уровень хранения, где данные Namespace временных рядов сохраняются в специализированных БД (TimescaleDB, TDengine), а реляционные данные — в PostgreSQL, что обеспечивает эффективное сжатие и быстрый поиск.
• Event Flow: Координирует данные Namespace, интегрируя их в потоки событий и информации более высокого уровня, а также поддерживает объединение JSON-пакетов и добавление системных промптов для оптимизации с помощью LLM.

Реальный кейс интеграции: На примере интеграции данных о заказах (ERP), статусе оборудования (ПЛК) и показателях качества (Excel), платформа SupOS сначала определяет четкую структуру через Namespace (например, Equipment/CNC1, Order/orderInfo, Quality/orderQualitylog). Затем узлы Node-RED в Source Flow используются для парсинга, форматирования (в JSON) и отправки данных из REST API, Modbus ПЛК и файлов Excel в соответствующие Namespace. Наконец, Event Flow связывает данные о заказах и качестве в реальном времени с LLM для анализа первопричин, записывая результаты в Quality/qualityAnalysis, тем самым обеспечивая сквозную интеграцию данных и интеллектуальное применение.

Резюме

Ценность уровня восприятия (Sense Layer) заключается не в простом «перемещении данных», а в их преобразовании в упорядоченное, семантически понятное и готовое к использованию «цифровое состояние мира». Это похоже на превращение разрозненного сырья в библиотеку деталей, аккуратно расставленных по полкам, что позволяет интеллектуальному уровню в любой момент обращаться к ним, собирать их и анализировать.

Коротко говоря, уровень восприятия открывает путь для данных от OT-устройств и IT-систем к AI-аналитике, предоставляя промышленному искусственному интеллекту «глаза» и «сеть данных» для всестороннего восприятия завода.

Уровень мышления / Think

Определение: Этап «мышления» — это процесс превращения необработанных данных, собранных и обработанных на этапе «восприятия», в практические выводы. Уровень мышления (Think Layer) — это «мозг» интеллектуальных агентов, отвечающий за понимание намерений, генерацию решений и планирование действий. После того как уровень восприятия предоставляет информацию о состоянии среды или намерениях пользователя, уровень мышления анализирует её, определяет цель, которую необходимо достичь, и формирует соответствующие решения. Эти решения обычно имеют «структурированный» вид: уровень мышления переводит требования на естественном языке в исполняемые планы, такие как блок-схемы, последовательности вызовов функций или инструментов, либо код логики управления. Это равносильно подготовке «плана действий» для уровня исполнения.

Основные вызовы и возможности для агентов

Традиционное промышленное принятие решений сильно зависит от эмпирической интуиции и пассивных программных систем. В эпоху нехватки кадров и быстрых перемен эта модель не только нежизнеспособна, но и демонстрирует свои ограничения при работе с огромными объемами информации и в сложных динамических средах. Поэтому будущее промышленного ИИ выходит за рамки простого RAG (генерации с дополнением поиска), чат-ботов или пассивных систем ответов на вопросы; оно требует создания замкнутых агентных систем, способных проактивно принимать решения, выполнять команды и нести ответственность за результат. Этот сдвиг позволяет искусственному интеллекту преодолеть разрыв между «мышлением» и «действием», обеспечивая глубокую конвергенцию интеллекта и исполнения.

Factorio: идеальный полигон для интеллектуальных агентов

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

1. Глубоко тестировать промышленные LLM-системы в сложных средах с физической достоверностью: Она предоставляет высокореалистичную микромодель завода, имитирующую реальные промышленные элементы, такие как ресурсы, производственные цепочки и логистика, позволяя LLM-агентам обучаться и проверять гипотезы в условиях, близких к реальным сценариям.
2. Визуализировать решения агентов и их последствия в режиме реального времени, достигая принципа «что задумано, то и видно»: Каждая операция агента (например, строительство, демонтаж, настройка оборудования, оптимизация планировки) может мгновенно отображаться в визуальном интерфейсе, что значительно повышает прозрачность и интерпретируемость процесса принятия решений.
3. Экспериментировать с различными стратегиями автоматизации с низкими затратами и высокой эффективностью: По сравнению с затратами на метод проб и ошибок на реальных заводах, Factorio предлагает бесконечное пространство для экспериментов, позволяя агентам смело пробовать, быстро итерировать и ускорять проверку и оптимизацию инновационных стратегий.
4. Проверять возможности ИИ по планированию и оптимизации на основе установленных промышленных механизмов, ускоряя развертывание моделей: Платформа обеспечивает строгий цикл обратной связи для планирования, диспетчеризации и оптимизации моделей ИИ, гарантируя, что агенты могут не только «думать», но и воплощать свои мысли в эффективные и измеримые физические действия, значительно ускоряя цикл исследований и разработок промышленных ИИ-приложений.

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

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

Взаимодействие мультиагентных систем и вызов инструментов

Промышленные системы часто требуют совместной работы нескольких специализированных интеллектуальных агентов. Комбинация JSON и MQTT, реализованная через семантический обмен сообщениями, обеспечивает прозрачное взаимодействие между агентами. Например, в кризисной ситуации в Factorio агенты, отвечающие за загрязнение, производство и ресурсы, могут выполнять независимый анализ, подписываясь на соответствующие шаблоны тем (например, factorio/pollution/#, factorio/production/#), и публиковать структурированные решения в формате JSON через такие темы, как factorio/coordination/crisis_response , для достижения скоординированного отклика. Так, в случае поломки печи агенты могут договориться о запуске резервных производственных линий, развертывании модулей эффективности и корректировке распределения ресурсов. Этот механизм обеспечивает семантическую прозрачность и временную гибкость, позволяя сложным системным оптимизациям возникать на основе общей контекстной информации между специализированными агентами.

Более того, для расширения возможностей принятия решений уровень мышления (Think Layer) также обладает мощными функциями доступа к инструментам, подключаясь к численным решателям, моделям машинного обучения, внешним API и т. д. для динамического выполнения таких операций, как запрос к базам данных или расчет графиков. Например, функция вызова инструментов OpenAI в сочетании с фреймворком LangChain с открытым исходным кодом позволяет LLM при необходимости обращаться к заводским базам данных или MES-системам, обеспечивая автономное принятие решений и действий. Для повышения доверия к решениям используется метод цепочки рассуждений (Chain-of-Thought), который позволяет моделям пошагово обосновывать свои выводы, тем самым формируя объяснимые процессы принятия решений.

Проекты и практические примеры: В этой области мы реализовали такие проекты, как Factory Agent, симуляции заводских процессов, Node-RED Copilot и BIS (Business Intelligence Assistant) в качестве промышленного помощника (Copilot). Среди них BIS может автоматически генерировать бизнес-процессы MES (Manufacturing Execution System) на основе введенных пользователем документов с требованиями к продукту (PRD), а также предоставлять интеллектуальные инсайты и рекомендации по оптимизации, значительно повышая эффективность проектирования и разработки MES-систем.

Уровень исполнения / Действие

Его также можно рассматривать как «IDE для исполнения», предназначенную для совместной работы ИИ и человека. Уровень исполнения — это «руки и ноги» интеллектуальных агентов, чья роль заключается в преобразовании структурированных языковых решений, выданных уровнем мышления, в реальные управляющие воздействия. Когда уровень мышления принимает решение (например, предлагает изменить параметры станка или запланировать партию логистических перевозок), уровень исполнения отвечает за выдачу команд и реализацию действий, управляя оборудованием, программным обеспечением или персоналом для выполнения решения, тем самым замыкая цикл «восприятие — мышление — действие». Суть уровня исполнения заключается в отображении абстрактных цифровых решений в конкретные физические или цифровые действия. Например, план «снизить температуру для увеличения производительности», созданный интеллектуальным уровнем, может потребовать от уровня исполнения вызова API системы промышленной автоматизации для снижения температуры нагревательной печи на 5°C или отправки инструкций через систему планирования для заблаговременной доставки сырья с помощью AGV.

Протокол контекста модели (MCP) и движок потоков Node-RED

Для надежного выполнения инструкций в сложных гетерогенных средах уровень исполнения внедряет унифицированный протокол вызовов (MCP, Model Context Protocol) в качестве стандартного интерфейса. Протокол MCP предоставляет общий язык для исполнения команд интеллектуальными агентами; он инкапсулирует форматы сообщений, контекстную информацию и планы выполнения, гарантируя, что различные подсистемы смогут понимать инструкции агента и правильно на них реагировать. Короче говоря, MCP позволяет интеллектуальным агентам взаимодействовать с различными системами и устройствами в стиле высокоуровневого диалога, подобно тому, как сотрудничают люди, избегая негибкости традиционных жестких API-вызовов. Его расширенные ключевые функции включают:

• Получение и обновление потоков Node-RED через MCP.
• Предоставление системы резервного копирования потоков с поддержкой версионности и проверкой целостности.
• Добавление подробных описаний аргументов для инструментов, что лучше подходит для LLM и выполнения сложных задач.
• Получение информации о доступных узлах (имя, справка, имя модуля) вместо необработанного кода.
• Установка новых модулей узлов с помощью LLM, а также управление состояниями модулей и узлов.
• Поддержка управления вкладками, отдельными узлами, поиск узлов, доступ к настройкам и состоянию среды выполнения, а также удаленный запуск узлов типа inject.

Инструменты протокола контекста модели (MCP)

Инструменты MCP дополнительно подразделяются на инструменты потоков (управление потоками), инструменты узлов (управление узлами), инструменты резервного копирования (управление бэкапами), инструменты настроек (системные параметры) и вспомогательные инструменты, обеспечивая комплексные возможности управления Node-RED.

Экспериментальные функции supOS MCP: для дальнейшего улучшения взаимодействия с LLM, supOS предоставляет экспериментальные функциональные возможности MCP. Они позволяют LLM получать доступ к содержимому UNS в режиме реального времени и интерпретировать его через встроенный сервер и клиент MCP. Поддерживаемые инструменты включают get-model-topic-tree (получение структуры дерева топиков), get-model-topic-detail (получение метаданных топика), get-topic-realtime-data (получение данных в реальном времени для указанного топика) и get-all-topic-realtime-data (получение данных в реальном времени для всех связанных топиков). Эти инструменты значительно расширяют возможности восприятия и взаимодействия LLM на платформе SupOS, позволяя создавать более интеллектуальных агентов.

Если вам интересно, как агенты LLM могут глубоко взаимодействовать с промышленными системами, такими как Node-RED, приглашаем вас посетить наш репозиторий с открытым исходным кодом node-red-mcp-server на GitHub (https://github.com/supcon-international/node-red-mcp-server), чтобы лично опробовать этот мощный интерфейс взаимодействия с промышленным ИИ.

Механизм потоков Node-RED

Важным компонентом архитектуры уровня исполнения является механизм потоков Node-RED. Node-RED организует логику выполнения с помощью визуальных потоков данных, что делает его идеально подходящим для быстрой настройки многошаговых процессов управления в промышленных условиях. Благодаря разработке специализированных плагинов для Node-RED, структура решений агента (например, блок-схемы, созданные упомянутым ранее Copilot) может быть напрямую внедрена в Node-RED для выполнения. Затем Node-RED берет на себя взаимодействие с базовыми устройствами и службами, реализуя low-code выполнение процессов. Таким образом, решения, выданные интеллектуальным уровнем, превращаются в последовательность узлов в Node-RED (например, считывание данных датчиков, принятие решений, выполнение действий), которые затем фактически «запускаются» на уровне исполнения. В данном контексте поток означает конкретную структуру рабочего процесса, которая может представлять собой поток узлов Node-RED, процесс BPMN (нотация моделирования бизнес-процессов) или последовательность пользовательских скриптов.

Node-RED Dev Copilot: IDE для исполнения, созданная для людей и ИИ

Node-RED Dev Copilot — это инновационное применение протокола MCP на уровне исполнения. Это плагин-боковая панель для ИИ-помощника по программированию, предоставляющий мощную поддержку ИИ при разработке в Node-RED. Его основные функциональные возможности включают:

• Поддержка ИИ на различных платформах: Совместимость с OpenAI, Google Gemini, DeepSeek и пользовательскими API, совместимыми с OpenAI.
• Потоковая передача в реальном времени (SSE): Обеспечивает мгновенную обратную связь за счет потоковых ответов.
• Интеграция протокола MCP: Автоматически обнаруживает и вызывает инструменты MCP, обеспечивая мощную поддержку ИИ при разработке в Node-RED.
• Интеллектуальный вызов инструментов: ИИ автоматически выбирает и выполняет соответствующие инструменты в зависимости от поставленных задач.
• Боковая панель и переключение между узлами: Можно использовать непосредственно в редакторе Node-RED, что позволяет свободно переключаться между узлами LLM.
• Безопасное хранение и история сеансов: Безопасно хранит ключи API с помощью механизма управления учетными данными Node-RED и поддерживает историю многоходовых диалогов.

Благодаря Node-RED Dev Copilot уровень исполнения (Execution Layer) превращается в полноценную среду разработки (IDE), предназначенную как для людей, так и для ИИ, что значительно повышает эффективность разработки и уровень интеллектуальности автоматизированных процессов.

Если вам интересно, как Node-RED Dev Copilot помогает в программировании с использованием ИИ, приглашаем вас посетить наш репозиторий с открытым исходным кодом на GitHub (https://github.com/supcon-international/node-red-dev-copilot), чтобы лично опробовать эту среду разработки для людей и ИИ.

MQTT-коммуникация и стандартизация команд

Уровень исполнения взаимодействует с различными протоколами и интерфейсами нижнего уровня, такими как команды ПЛК, REST API, операции с базами данных, инструкции по управлению роботами и т. д., сопоставляя каждый шаг в потоке (Flow) с конкретными действиями. Для обеспечения надежной доставки этих действий в реальном времени уровень исполнения обычно использует легковесные шины обмена сообщениями, такие как MQTT, в качестве канала управления, сочетая модель «издатель/подписчик» для мгновенной рассылки команд и получения обратной связи о статусе.

При обмене данными между агентами и средой на виртуальном производстве архитектура тем (Topic) MQTT и формат сообщений JSON строго стандартизированы. Например, команды, отправляемые агентами, должны соответствовать следующему формату JSON:

{
  "command_id": "str (Optional field, used for recording decision process)",
  "action": "str (Must be one of the supported actions)",
  "target": "str (Target device ID for the action, optional)",
  "params": {
    "key1": "value1", ...
  }
}

А ответные сообщения от системы выглядят следующим образом:

{
  "timestamp": "float (Simulation timestamp)",
  "command_id": "str (From the player's command_id)",
  "response": "str (Feedback information)"
}

Поддерживаемые команды действий включают move (перемещение AGV), charge (зарядка AGV), unload (разгрузка AGV), load (загрузка AGV) и get_result (получение результатов KPI). Такая стандартизация обеспечивает четкость, контролируемость и отслеживаемость команд.

Практические сценарии и аспекты проектирования

На уровне исполнения мы фокусируемся на том, как безопасно и эффективно претворять решения ИИ в реальные действия на объекте. Например, в системе планирования AGV: после того как интеллектуальный уровень определяет последовательность доставки для нескольких AGV, уровень исполнения должен выдавать задачи каждому из них и контролировать их выполнение. Мы разработали плагин управления AGV для Node-RED, который взаимодействует с диспетчерским контроллером AGV, автоматически преобразуя план планирования интеллектуального уровня в конкретные маршрутные инструкции для AGV. Затем они публикуются через MQTT для централизованного управления парком AGV. В управлении производственными процессами уровень исполнения отправляет оптимизированные параметры в систему управления DCS через протокол MCP и отслеживает обратную связь, чтобы подтвердить применение параметров. При работе с промышленными роботами или оборудованием производственных линий уровень исполнения также часто должен учитывать защитные блокировки и механизмы ручного вмешательства.

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

05｜Реальные сценарии применения и кейсы

1. Симулятор SUPCON NLDF (фабрика, управляемая естественным языком)

Симулятор SUPCON NLDF: «Стэнфордский городок» для промышленных агентов — масштабируемая и измеримая открытая платформа для промышленного бенчмаркинга

Симулятор SUPCON NLDF — это гибко настраиваемая среда имитации дискретного производства, реализованная на базе SimPy. Она не только моделирует сложные задачи планирования и распределения ресурсов, характерные для реальных производств, но и служит открытой платформой для тестирования агентных технологий, позволяя исследовать возможности взаимодействия и непрерывного развития в промышленной сфере.

В этом цифровом промышленном мире, подобном «Стэнфордскому городку», мы создали динамическую экосистему, включающую 3 производственные линии, склад сырья и склад готовой продукции. Каждая линия оснащена рабочими станциями A, B, C и станцией контроля качества, соединенными интеллектуальными конвейерными лентами и сетью AGV. Игрокам (или разработчикам интеллектуальных агентов) предстоит управлять 6 автоматизированными транспортными средствами (AGV), координируя производство и оптимизируя процессы, гибко реагируя на случайные сбои и нештатные ситуации, чтобы достичь максимально возможного совокупного показателя KPI.

Основная концепция проектирования: внешний интерфейс JSON, внутреннее управление на основе естественного языка, достижение бесконечной масштабируемости. Взаимодействие между средой симуляции и агентами игроков осуществляется через стандартизированные сообщения JSON. Мы требуем, чтобы игроки создавали в своих агентах надежные механизмы обработки естественного языка, формируя полноценный JSON -> NL -> JSON цикл принятия решений. Это не только позволяет машинам понимать друг друга, сотрудничать, адаптироваться и принимать автономные решения с помощью языка, подобно людям, но, что более важно, создает развивающуюся, итеративную и открытую арену, где исследователи и игроки со всего мира могут вносить свой вклад и совершенствовать систему. Симулятор NLDF призван стать динамическим эталоном промышленного интеллекта, постоянно поднимая планку возможностей принятия решений и координации промышленных ИИ-агентов в сложных реальных условиях за счет внедрения новых задач, более изощренных сценариев и передовых механизмов оценки. Игроки могут постоянно оптимизировать своих агентов, обмениваться стратегиями и коллективно строить непрерывно развивающуюся экосистему промышленного интеллекта.

KPI и система оценки:

Система оценки использует 100-балльную шкалу, где эффективность производства (40 баллов), затраты на качество (30 баллов) и эффективность работы AGV (30 баллов) имеют соответствующие весовые коэффициенты. Это делает симулятор NLDF эталоном для количественной оценки способностей LLM-агентов к принятию решений и координации в сложных промышленных условиях.

Мы открыли исходный код этой части и приглашаем всех посетить репозиторий на GitHub (https://github.com/supcon-international/25-AdventureX-SUPCON-Hackathon), чтобы лично познакомиться с этим «Рузвельт-тауном» в промышленной сфере и ощутить масштаб и загадочность индустриального мира.

2. Factory Agent + Factorio: визуализированная практика интеллектуального управления

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

Вот три сценария интеллектуального управления в Factorio и ключевые выводы по ним:

2.1 Сценарий 1: Оптимизация эффективности солнечной энергии

Цель: Максимизировать выходную мощность на единицу площади в ограниченном пространстве и обеспечить стабильное электроснабжение в режиме 24/7.

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

2.2 Сценарий 2: Эффективная добыча меди

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

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

2.3 Сценарий 3: Баланс между эффективностью и экологичностью

Цель: Поддержание высокой производительности при уровне загрязнения ниже 500 ppm во избежание экологических штрафов.

В этом сценарии агент продемонстрировал способность к адаптивному поиску компромиссов. Он не просто оптимизировал один показатель, а сбалансировал конкурирующие цели: производственную эффективность и экологическую устойчивость. Процесс принятия решений включал наблюдение за исходным состоянием «высокая производительность, высокий уровень загрязнения», выдвижение гипотезы о необходимости «баланса между производством и экологией» и формулирование стратегии «корректировки комбинаций модулей и переключения источников энергии». Комбинируя модули (эффективности и производительности) и выбирая источники энергии (солнечные панели + резервный уголь), агент успешно удержал уровень загрязнения ниже порогового значения, сохранив при этом высокую производительность. Это показывает, что LLM-агенты способны согласовывать и балансировать несколько целей, предоставляя обоснованные и понятные решения.

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

Мы также открыли исходный код для Factory Agent в Factorio и приглашаем всех посетить репозиторий на GitHub (https://github.com/supcon-international/Factorio-Agent), чтобы лично познакомиться с этим игровым индустриальным миром.

3. Умная фабрика Supcon Fuyang: внедрение агентов в реальных условиях

Умная фабрика Supcon Fuyang — это пример реального внедрения архитектуры полного цикла «восприятие-мышление-действие». Всемирный экономический форум отмечает, что ИИ-агенты реального времени могут повысить производительность на 14% и сократить время принятия решений на 80% — именно такая трансформация происходит на заводе Fuyang. Здесь развернуто множество Factory Agents для повышения оперативной гибкости и уровня интеллектуальности производственной линии.

• Агент 1: Интеллектуальное планирование AGV. Этот агент автономно управляет парком автоматизированных транспортных средств (AGV), интерпретируя события о состоянии оборудования в реальном времени, что обеспечивает интеллектуальную и эффективную транспортировку материалов.
• Агент 2: Мониторинг и оптимизация OEE в реальном времени. Этот агент непрерывно отслеживает показатели общей эффективности оборудования (OEE), выявляет неэффективные звенья и немедленно предлагает планы оптимизации. Это превращает «сырые» данные машин в практические рекомендации, помогая инженерам быстрее реагировать, повышать пропускную способность и снижать ручную нагрузку.

Опыт завода Fuyang, включая такие достижения, как предиктивное обслуживание и отслеживаемые карты качества, полностью демонстрирует, как Factory Agents могут воплотить в жизнь концепцию интеллектуальных операций, основанных на данных, в реальной промышленной среде, служа моделью глубокой интеграции OT, IT и ИИ. Кроме того, на заводе изучается использование обучения с подкреплением для настройки параметров, что еще больше расширяет возможности самоадаптивной оптимизации производственной линии.

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

Взгляд в будущее

Фабрика больше не является просто «набором машин», выполняющих инструкции.

Это «живая система», способная воспринимать, оценивать и принимать решения.

Мы создаем «мозг и нервную систему», а также «руки и ноги» для будущих промышленных систем.

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

Именно в этом заключается ценность трехуровневой архитектуры «Sense-Think-Do» (восприятие-мышление-действие), которую мы создали и постоянно совершенствуем, решая актуальные проблемы промышленного сектора. Это не просто теоретическая концепция, а решение, подкрепленное рядом продуктов и кейсов, которые уже внедрены на практике и продолжают развиваться.

Часть контента в этом документе была отключена

‍