BOM Voyage

Large language models for high-level computer-aided process planning in a distributed manufacturing paradigm

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

Авторы не используют большую универсальную языковую модель. Они обучают с нуля небольшую модель (SLM а не LLM) на основе архитектуры GPT на специальном «языке производства». Геометрия детали, её особенности, требования к точности и параметры заказа представляются последовательностью условных обозначений, как и технологические операции. Проектирование маршрута сводится к предсказанию следующей операции. Для обучения создан синтетический набор из 7840 деталей и допустимых маршрутов на основе экспертных правил. При этом модель содержит всего около 200 тысяч параметров и не требует значительных вычислительных ресурсов.

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

Ещё одно — Adaptive task planning and coordination in multi-agent manufacturing systems using large language models
Там уже про LLM-управляемую многоагентную производственную систему, агент в ней интерпретирует ранее неизвестные требования к изделию, динамически получает знания о доступных производственных возможностях, подбирает ресурсы и преобразует требования в исполняемые операции. В испытательном стенде система смогла обрабатывать требования, которые заранее не были заложены в модели агентов.

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

И наконец, не про ИИ, но интересно A STEP-NC-based post-process simulation system for closed-loop machining — про замыкание CAPP/CAM в обратную связь с производством. На основе STEP-NC связали каждый workingstep с фактическими сигналами выполнения, которые дополняют технологическую модель реальными результатами обработки и затем используют байесовскую оптимизацию для изменения параметров следующего цикла.

В экспериментах оптимизация улучшила результат для всех 12 исследованных операций; среднее превышение лучшего исходного результата составило 24,33%. Это не то, чтобы ИИ (однако очень просится в эту схему), но архитектурно направление очень важное: цифровой двойник перестает только отображать производство и начинает возвращать опыт реального выполнения непосредственно в технологический процесс.

—————

Кстати, «СПРУТ-Технология» недавно как раз показали своего ИИ-помощника технолога СКАТ в СПРУТ-ТП-Нормирование. Он умеет генерировать технологический процесс по текстовому заданию, восстанавливать ТП из сканированных документов, строить его по чертежу и переносить результат непосредственно в структуру технологического процесса.
https://rutube.ru/video/5e90995f470180dfbde0f403d94662f5

В РФ это вроде бы первый такой пример. На западе это есть например как Manufacturing Planning Agent в Teamcenter Manufacturing Easy Plan 2606
https://blogs.sw.siemens.com/teamcenter-manufacturing/2026/07/28/whats-new-in-teamcenter-manufacturing-easy-plan-2606/

или CAM Assist для GibbsCAM
https://www.cloudnc.com/news-room/cam-assist-the-first-ai-plug-in-for-cam-is-now-available-for-gibbscam

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

Для CAD/CAE/CAPP/PLM это особенно важно: изменение редко остаётся внутри одной системы. Геометрия может затронуть EBOM и MBOM, технологию, материалы, расчёты, закупки и документацию. Поэтому предложение агента должно быть проверяемым решением: что меняется, на каких данных оно основано и чем подтверждены выводы. Для CAE важен не только итог расчёта, но и версия геометрии, сетка, граничные условия, материалы и настройки решателя. Инженер должен согласовывать воспроизводимое обоснование, а не текстовый ответ. Между агентами и корпоративными системами потребуется слой контроля, который собирает контекст из разных источников и оставляет человеку только то, где требуется инженерное суждение. Ревизии, состояния объектов, связи, ограничения и численные пороги лучше проверять автоматически. По мере накопления доверия типовые изменения смогут всё чаще выполняться без участия человека, а инженер будет разбирать главным образом исключения и рискованные случаи. Однако сначала доверие надо будет накопить, это не будет происходить автоматически, стартовать будет с позиций явного скептицизма и открытого сопротивления.

Особую ценность из-за этого получает история решений, их трассируемость, прозрачность. Важно сохранять не только факт утверждения, но и исходные данные, доказательства, альтернативы, причины выбора и иной контекст. Формировать человевекочитабельную сводку и развёрнутое представление. Скорее всего PLM придут к хранению не только то, что изменилось, но и причин изменения, контекста в том состоянии в каком изменение производилось. При этом CAD, PLM, ERP, MES, QMS и другие системы могут оставаться владельцами своих данных: необязательно собирать всё в одной базе, важнее уметь сформировать доверенный и версионированный контекст решения.

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

Класс таких систем можно назвать
Engineering Decision Control — EDC
Engineering Decision Assurance — EDA
или
«Система управления инженерными решениями», «Система контроля инженерных решений», «Платформа инженерных решений», «Инженерный контур доверия» в русскоязычном варианте.

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

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

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

Такой слой необязательно должен становиться новой системой хранения. Он может работать поверх Teamcenter, IPS, Windchill, Лоцман, Aras, T-Flex, 3DEXPERIENCE, PDM, ERP, CAD и других систем, оставляя их владельцами данных, но предоставляя агенту общую модель деталей, документов, требований, конфигураций и изменений. Это отличает его от обычного MCP-сервера: MCP даёт инструменты, а «PLM для агентов» задаёт пространство допустимых инженерных действий и гарантии их корректности.

В основании такой системы может лежать универсальная модель управляемых объектов, типизированных связей, версий, состояний, наборов изменений, политик, полномочий и происхождения данных. Тогда PLM становится одной из специализаций более общего runtime для управляемых действий. В AI-native архитектуре именно эта исполняемая модель может стать ядром системы, а UI — лишь одним из клиентов наряду с агентами, CAD, скриптами и корпоративными приложениями.

^^

И есть ещё одна область где пространственное мышление совершенно необходимо - автономные роботы.

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