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 или «Система управления инженерными решениями», «Система контроля инженерных решений», «Платформа инженерных решений», «Инженерный контур доверия» в русскоязычном варианте.

Вебинарчик https://plmgroup.eu/events/model-and-simulate-low-frequency-electromagnetics-with-cst/

Концепт «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, скриптами и корпоративными приложениями.

Опубликовали «дорожную карту» MCP (Model Context Protocol), в которой обозначили переход от простой схемы «модель вызвала инструмент — получила ответ» к инфраструктуре для корпоративных агентных систем. Особое внимание уделено готовности к корпоративному применению: агентам нужны собственная идентичность, ограниченные полномочия и безопасная передача части прав субагентам. Вместо ключей API и долгоживущих токенов MCP движется к стандартным механизмам идентификации программных процессов, федерации идентичности и обмена токенами, чтобы встроить агентов в существующие корпоративные системы управления доступом. Одновременно MCP развивается от синхронных вызовов к событийной модели. Задачи предназначены для операций, которые могут длиться минуты или часы, а триггеры, события, подписки, уведомления о ходе выполнения и обратные вызовы позволят серверу самому сообщать агенту о завершении работы или изменениях вместо постоянных проверок. Развивается и работа с большими результатами: вместо передачи огромного JSON в контекст модель сможет получать ссылки на документы, файлы и другие ресурсы, читать их частями, использовать кэширование и отслеживать версии. При этом разработчики не хотят раздувать ядро MCP. Новые корпоративные возможности предполагается развивать через расширения с едиными правилами объявления возможностей, совместимости и версионирования. Удачные расширения впоследствии смогут становиться частью стандарта. В итоге идентификация и делегирование прав, задачи, триггеры и события, потоковые и ссылочные результаты и расширяемость выводят MCP далеко за пределы обычного интерфейса вызова инструментов искусственного интеллекта: он превращается в базовый инфраструктурный слой для распределённых агентных систем. https://blog.modelcontextprotocol.io/posts/mcp-roadmap/

The Exploration Company приобрела у LEAP 71 пятилетнюю лицензию на систему Noyron RP для разработки ракетных двигателей. Эта ИИ система не просто управляет CAD и не генерирует форму по текстовому описанию. В систему заложены физика, инженерные правила, ограничения производства и результаты реальных испытаний. Инженер задаёт требования к будущему двигателю, а Noyron рассчитывает конструкцию и создаёт геометрию, которую затем можно проверить в CAE, изготовить и испытать. То есть автоматизируется уже не столько работа в CAD, сколько значительная часть самого проектирования. The Exploration Company собирается применять Noyron при создании собственных двигателей, включая перспективный Storm. Главная цель — намного быстрее проходить цикл от идеи до испытаний: задать требования, получить конструкцию, изготовить её, испытать, вернуть результаты в модель и создать следующий вариант. Вместо множества ручных итераций инженер получает систему, способную быстро исследовать большое число возможных конструкций, оставляя CAE и физические испытания средствами проверки результата. https://www.exploration.space/blog/the-exploration-company-licenses-leap-71s-noyron-rp-for-the-design-of-next-generation-rocket-engines

Plamo, про который мы писали здесь https://t.me/BOM_Voyage/307 Ориентировано больше на строения, BOM, как Revit. Запустили бету, можно пробовать (кнопка "try it free) https://illoca.com/plamo

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

Исследователи MIT разработали GIFT — подход, который помогает мультимодальным моделям точнее превращать 2D-эскизы и текстовые описания в CAD-модели. Результатом становится не просто 3D-геометрия, а исполняемая CAD-программа с последовательностью операций построения, которую можно редактировать, параметризовать и использовать дальше в инженерном процессе. Основная проблема таких систем в том, что современные модели уже неплохо пишут код, но гораздо хуже восстанавливают по изображению правильную геометрию и конструктивную логику модели. GIFT решает эту проблему через обучение модели на собственных результатах. Она несколько раз выполняет одну задачу, а система выбирает случаи, где часть попыток успешна, а часть содержит ошибки. Правильные и автоматически исправленные решения превращаются в новые обучающие примеры. Таким образом, ресурсы расходуются не на общее расширение CAD-датасета, а на конкретные операции и типы геометрии, с которыми модель пока работает нестабильно. В экспериментах GIFT повысил точность генерации CAD и потребовал примерно пятую часть вычислительных затрат по сравнению с несколькими альтернативными подходами. Пока основная цель — геометрическая корректность, но следующий шаг предполагает добавление инженерных критериев: ограничений, эксплуатационных характеристик и технологичности. В перспективе это путь к AI-to-CAD системам, которые смогут самостоятельно улучшать навыки моделирования и учиться создавать не просто похожую геометрию, а инженерно корректные модели. https://meche.mit.edu/news-media/better-way-turn-2d-designs-3d-models-rapid-prototyping

Опубликовали https://huggingface.co/datasets/markov-ai/cad-1000-hours Компаса нет, хехе

В честь пятницы забавное из мира геймдева

Сименс хвастается что они осилили реализовать RAG и выкатили чатбота :) https://blogs.sw.siemens.com/insights-hub/2025/01/30/production-copilot-ai-assistant-for-production/ P.S. многие ещё и этого не смогли

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

Мы запускаем крупнейший открытый набор данных о работе с CAD-системами. Он охватывает Siemens NX, SolidWorks, AutoCAD и другие системы и включает описания заданий, входные файлы, записи экрана, синхронизированные действия мыши и клавиатуры, а также выходные файлы. Более 50 000 часов данных.

https://x.com/DevvMandal/status/2090476514488000584 https://www.markovstudios.com Роботам будет на чём учиться. Однако основной bottleneck здесь, вероятно, не только в отсутствии подобных данных. Современные языковые и мультимодальные модели по-прежнему гораздо лучше работают с дискретными символическими представлениями — текстом и кодом, — чем с точным пространственным представлением объектов. Говорить, что они буквально «мыслят языком», было бы упрощением, но архитектурно и обучением они действительно сильно смещены в эту сторону. Даже современные vision-language модели заметно уступают человеку в пространственных задачах: понимании взаимного положения объектов, перспективы, вращений, геометрии и особенно полноценной 3D-сцены. Отсюда и привлекательность представления моделей через код, дерево построения или другие структурированные описания. Для модели это гораздо более удобное пространство: операции явно названы, зависимости дискретны, результат можно проверять и исправлять по шагам. Когда же существенная часть информации существует только в геометрии или на экране CAD, модель должна сначала восстановить из визуального представления достаточно точную внутреннюю картину сцены, и именно здесь часто возникают ошибки. Поэтому проблема не столько в «токенизации картинки» как таковой, сколько в недостаточно развитом пространственном представлении и рассуждении поверх него. Если этот разрыв удастся существенно сократить на уровне самих моделей — дать им устойчивое внутреннее представление 2D/3D-геометрии, пространства и действий над ним, — CAD действительно станет одной из областей, где ИИ превзошёл человека в рутинных операциях. Пока же индустрия в значительной степени компенсирует слабость ядра обвязкой: собирает огромные наборы траекторий работы, добавляет структурированные CAD-представления, инструменты, обратную связь, верификацию результатов и агентные циклы. То есть сейчас совершенствуется прежде всего среда вокруг модели; следующий качественный скачок должен произойти уже в способности самой модели понимать пространство.

^^ Достаточно нишевое решение, но тем не менее. В следующий четверг они проводят вебинар Inside sphereneNXT: The Complete Toolset Покажут как применять для проектирования дрона и теплообменника.

SphereneNXT — облачная платформа для проектирования внутренней структуры деталей, прежде всего рассчитанная на аддитивное производство. Её идея хорошо выражается формулой «CAD for the Inside»: привычная CAD-система определяет внешнюю форму детали, а sphereneNXT занимается тем, как материал должен быть устроен внутри. Вместо сплошного объёма или обычной периодической решётки можно создавать сложные пористые структуры, менять их плотность и толщину в разных местах, формировать внутренние каналы и подстраивать геометрию под механические или тепловые требования. Пользователь импортирует исходную модель, задаёт область и необходимые свойства, после чего платформа вычисляет внутреннюю архитектуру и подготавливает результат для дальнейшего анализа или производства. Главная технология Spherene называется ADMS — Adaptive Density Minimal Surface. В отличие от обычных lattice-структур, собранных из одинаковых повторяющихся ячеек, ADMS формирует непрерывную непериодическую поверхность, которая может плавно меняться внутри детали. Благодаря этому можно, например, сделать одну область более жёсткой и плотной, другую — лёгкой и пористой, причем без резких переходов между ними. Такая поверхность одновременно разделяет внутренний объём на два независимых переплетающихся пространства, что открывает интересные возможности для теплообменников, охлаждения и движения жидкостей. Подобную геометрию трудно строить традиционными средствами B-Rep CAD: количество элементов быстро растёт, а операции пересечения и обрезки становятся тяжёлыми. Spherene вместо этого генерирует структуру алгоритмически сразу внутри нужного объёма. SphereneNXT поэтому интересен не просто как очередной генератор решёток, а как попытка выделить внутреннюю архитектуру детали в самостоятельный этап проектирования. Если классический CAD отвечает на вопрос, какой должна быть форма изделия, то здесь добавляется второй вопрос — как распределить материал внутри этой формы, чтобы получить нужные свойства. По смыслу это близко к возможностям nTop и других систем implicit modeling, но Spherene гораздо сильнее сфокусирован именно на внутренней структуре и собственной технологии ADMS. Для аддитивного производства такой подход выглядит естественным развитием CAD: 3D-печать позволяет проектировать уже не только поверхность изделия, но фактически сам материал на уровне его пространственной структуры. https://spherene.io

17 августа протокол и открытый стандарт Agent2Agent (A2A) перешёл под управление Agentic AI Foundation (AAIF) как отдельный hosted project: https://aaif.io/blog/a2a-joins-aaif Так что A2A теперь находится в одной специализированной нейтральной структуре с MCP и agentgateway, то есть начинает складываться общий открытый стек для agentic-инфраструктуры. AAIF указывает, что A2A уже поддерживают более 150 организаций и что протокол используется в production-сценариях, включая supply chain и financial services. Для концепции сетевой операционной среды для организаций, людей и ИИ-агентов в общем, и для перспектив ИИ в инженерной среде в частности, это достаточно заметный шаг. Формируется всё более ясное разделение слоёв: MCP — доступ агента к инструментам и данным; A2A — обнаружение других агентов, делегирование задач и взаимодействие между агентами разных организаций и технологических стеков; agentgateway — единая точка управления MCP-, A2A-, LLM- и API-трафиком с политиками доступа. Всё это теперь развивается под одной нейтральной организационной крышей. Кстати, в описании A2A прямо говорится об агентах, «owned by different organizations», то есть взаимосдействие с помощью протокола изначально рассматривается не только в контексте одной организации.

У Теренса Тао вышла новая статья-эссе, полностью посвященная проблеме переосмысления математики в век AI https://arxiv.org/pdf/2608.16753 Если кратко, ученый предлагает вообще перестать спорить о том, насколько мощным станет ИИ в математике, и подумать о том, что на самом деле является целью математического исследования, если решение задач перестает быть узким местом. На самом деле, решение задачи – это не только решение задачи. При ближайшем рассмотрении процесс разворачивается в пять этапов: генерация доказательства → верификация → внятное изложение → принятие сообществом → канонизация (встраивание в учебники и стандартный аппарат области). Так вот, ИИ берет на себя только первые два пункта. На людях же остается все остальное, а именно: понимание, объяснение, публичные обсуждения, связь найденных решений с существующей теорией и превращение их в материал, которым действительно можно пользоваться на благо науки. Это все можно обобщить как «коллективное усвоение знаний», и оно совсем не поддается автоматизации. Так что тезис Тао таков: математики не лишатся работы, даже когда ИИ полностью обесценит поиск решений. Просто их работа сместится к тому, что раньше считалось менее престижным, но всегда было сутью науки – пониманию и изложению.

Вебинар Luminary на котором расскажут про технологический стек Physics AI — искусственного интеллекта, который работает не только с текстами и данными, но и с физическими моделями реальных объектов и процессов, глубокой интеграции вычислительной инфраструктуры, симуляций, данных, машинного обучения и прикладных инструментов. Они используют результаты CFD, FEA, тепловых и других расчётов для построения быстрых моделей, способных оценивать множество вариантов конструкции и помогать выбирать наиболее перспективные решения ещё до запуска дорогостоящих высокоточных симуляций или физических испытаний. Проиллюстрируют как Physics AI меняет сам цикл разработки. Вместо последовательной схемы «создать вариант — рассчитать — проанализировать — изменить» появляется более быстрый контур, в котором ИИ помогает исследовать пространство решений, сравнивать компромиссы и определять, где действительно нужен точный расчёт. При этом классические симуляции и испытания не заменяются нейросетями, а становятся источником проверенных данных и способом валидации результатов. Иными словами покажут ценность Physics AI, которая заключается не столько в ускорении отдельного расчёта, сколько в сокращении всего пути от идеи до обоснованного технического решения. Понедельник, 31 августа, 20:00 - 20:45 по Минску https://events.luminary.ai/the-physics-ai-stack-required-for-faster-engineering-decisions-in-the-ai-era

CEO Figure AI объявил, что роботов Figure 02 утилизируют, потому что в штаб-квартире заканчивается место, и спросил у подписчиков, как лучше проводить модель на пенсию. На что в комменты пришел Арнольд Шварцнеггер и ответил ему: «Вы должны их расплавить»