BOM Voyage

^^ Продавайте чиновникам «Национальная платформа инженерной кооперации», «Единая среда цифровой инженерной кооперации», «Национальное пространство инженерных данных» или, более бюрократически, «Государственная информационная система межорганизационного инженерного взаимодействия». Сокращать до нечитаемой абревиатуры я не могу, но там обязательно придумают. Потенциальная задача таких организаций — обеспечение доверенного взаимодействия между независимыми контурами предприятий. Идентификация предприятий, пользователей и ИИ-агентов; проверка их полномочий; единые глобальные идентификаторы публикуемых объектов; каталог доступных интерфейсов и типов данных; передача уведомлений об изменениях; публикация и получение согласованных представлений изделий, требований, спецификаций и доказательств; фиксация версий и принятых baseline; обмен запросами, предложениями и обязательствами между предприятиями; проверяемая электронная подпись и происхождение данных; управление политиками доступа и условиями использования; отраслевые схемы и правила преобразования между разными PLM, ERP, MES и другими системами. Национальный "центр доверия" и "слой координации": он знает, кто с кем взаимодействует, кто за что отвечает, какой версии можно доверять и какие обязательства существуют, но внутренние BOM, CAD, расчёты, себестоимость и производственные планы остаются внутри предприятий. На Западе, скорее всего, возникнет не один «национальный сервис инженерной координации», а экосистема совместимых пространств данных. Собственно это уже сейчас видно в Европе: Catena-X строит автомобильное пространство данных, где предприятия сохраняют свои системы и данные, получают устойчивую идентичность, публикуют стандартизованные представления цифровых двойников и обмениваются ими через совместимые connectors. Над отдельными отраслевыми пространствами формируется общий слой доверия — Gaia-X развивает федеративную идентификацию, проверяемые credentials, политики и возможность связывать между собой разные data spaces, а International Data Spaces определяет протоколы каталогов, переговоров об условиях доступа и передачи данных. То есть государственный или общеевропейский уровень скорее будет отвечать не за хранение CAD/BOM, а за вопрос «кто ты, каким требованиям соответствуешь, что тебе разрешено получить и на каких условиях». Поверх этого отрасли будут определять собственную семантику. Catena-X уже стандартизует модели цифровых двойников, BOM, качества, сертификатов и других объектов; Manufacturing-X развивает тот же общий подход для промышленности шире автопрома. Это очень похоже на упомянутую выше модель: нет единой PLM-схемы, но существует набор согласованных профилей, через которые Teamcenter, Windchill, 3DEXPERIENCE, SAP, собственные системы предприятий и будущие AI-native платформы могут понимать друг друга. В США модель, вероятно, будет менее «инфраструктурно-федеративной» и более ориентированной на открытые стандарты, отраслевые экосистемы и требования крупных заказчиков. Так NIST уже много лет развивает Digital Thread именно через стандартизованный обмен между проектированием, производством и качеством и подчёркивает необходимость открытых стандартов вместо одной общей системы. В оборонке DoD говорит об authoritative sources of system data and models, причём исследования для DoD уже приходят к тому, что такая среда фактически должна представлять собой распределённую федерацию данных и моделей. Кстати ставлю на то, что DoD основным конструктором стандарта, эталона, как это уже неоднократно происходило в США в поворотные для индустрии моменты. Следующий шаг, который пока только начинает проявляться, — добавить поверх data spaces не просто передачу данных, а координацию действий. Сегодня инфраструктура в основном умеет сказать: «организация A предлагает dataset X организации B на таких условиях». Для мира агентов потребуется: «агент A, действуя от имени компании X и имея такой мандат, предлагает изменение; агент B может его проверить; компания Y принимает конкретную версию; поставщик принимает обязательство; результат подтверждён такими доказательствами». Gaia-X уже двигается в сторону автоматизированного trust layer и межэкосистемной проверки полномочий, но полноценной общей модели подобных инженерных обязательств пока нет.

Aras немного рассуждает про децентрализацию PLM в будущем (и конечно же хвалит себя, но заслужено) https://www.designnews.com/design-software/the-decentralized-future-of-innovation-the-evolving-role-of-plm Краткий пересказ + собственные мысли на этот счёт Распространение ИИ-агентов будет резко усиливать уже начавшуюся децентрализацию разработки. Информация об изделии и сегодня разбросана между CAD, CAE, системами требований и разработки ПО, PLM, MES, QMS, ERP, поставщиками и отдельными предприятиями. Пока основными участниками остаются люди, эту раздробленность ещё удаётся компенсировать совещаниями, согласованиями, интеграциями и ручной передачей контекста. Но агентная работа меняет масштаб проблемы. Множество специализированных агентов смогут одновременно анализировать требования, менять модели, проверять технологичность, искать риски, работать с поставщиками и инициировать изменения в разных системах. В результате распределённой становится уже не только сама информация, но и процесс принятия решений: разные части общей работы будут выполняться в разных системах, организациях и агентных средах. Существующие PLM-подходы к такой нагрузке подготовлены лишь частично. Центральный репозиторий или единое облако предполагают, что работу удастся собрать вокруг одной платформы. Multi-Site и репликация распространяют копии объектов между контурами. Пакетный обмен передаёт заранее подготовленные срезы данных. Коннекторы связывают системы попарно, а сквозные workflow пытаются провести один процесс через несколько подразделений или организаций. Все эти механизмы создавались для сравнительно небольшого числа заранее известных систем и относительно медленного обмена, которым в основном управляют люди. Когда одновременно начнут работать сотни агентов, такие схемы могут стать серьёзным ограничением: репликация будет разносить множество лишних изменений, количество интеграций станет быстро расти, общий workflow начнёт слишком тесно связывать независимые организации, а постоянное приведение разных систем к единой модели данных будет тормозить автоматизацию именно там, где агенты способны действовать очень быстро. Поэтому будущей среде нужен другой фундамент. Каждое предприятие должно сохранять собственный контур, свои внутренние данные и свою авторитетную модель, а наружу публиковать только ту часть информации, которая действительно нужна партнёрам. Чужой объект лучше не просто копировать к себе, а хранить его устойчивую идентичность, знать, какая организация отвечает за его состояние, какую версию мы приняли и какой снимок использовался в конкретной конфигурации изделия. Новая версия у поставщика не должна автоматически становиться новой версией у заказчика: она сначала должна быть замечена, проверена, оценена по последствиям и только затем принята. Изменения между организациями логичнее передавать как события, предложения и обязательства, а не как попытку синхронизировать между собой целые базы. Меняться должна и сама логика владения. В сложной кооперации недостаточно одного поля «владелец объекта». Одна сторона может разрабатывать изделие, другая — разрешать его применение, третья — подтверждать соответствие требованиям, четвёртая — использовать его в своей конфигурации. Поэтому системе нужны отдельные полномочия на изменение, публикацию, утверждение, сертификацию и использование данных. По той же причине между компаниями лучше не протягивать единый workflow. Одна организация должна сообщать другой, что ей нужно получить, к какому сроку и по каким критериям будет принят результат, а партнёр уже сам решает, каким внутренним процессом, людьми и агентами это выполнить. PLM в такой картине не исчезает, а меняет свою роль. Вместо места, куда пытаются собрать все данные и процессы, он становится доверенным слоем контекста и координации: связывает требования, конфигурации, решения, изменения, доказательства и обязательства независимо от того, в какой системе или организации они возникли. Для полноценной агентной работы к этому нужно добавить машиночитаемые полномочия агентов, понятные границы их действий, происхождение значимых решений, явно зафиксированные версии и базовые конфигурации, а также версионируемые способы перевода между разными моделями данных. Тогда агенты смогут действительно ускорять работу, не требуя сначала загнать всю промышленную кооперацию в одну систему. Без такого перехода получится обратный эффект: интеллект станет распределённым и очень быстрым, а инфраструктура, которая должна согласовывать его действия, останется построенной на медленных и централизованных принципах прошлого поколения.

Плюс упомянутая в начале локализация, секретность, защита интеллектуальной собственности. Для промышленного применения важно не только качество модели, но и то, куда отправляется геометрия, может ли поставщик использовать данные для обучения, где хранится журнал действий и можно ли отменить изменения. Предлагаемая архитектура Cosmon предполагает выполнение агента внутри инфраструктуры предприятия, журналирование операций и возможность их проверки и отката. Таким образом, конечная цель описывается как управляемая агентная автоматизация инженерного процесса: ИИ получает возможность выполнять длинные последовательности действий между CAD, CAE и PLM, но контроль критических решений и окончательное утверждение сохраняются за человеком. Сайт компании: https://cosmon.com Блог: https://cosmon.com/blogs Ютуб: https://www.youtube.com/@cosmon-ai

Пожалуй это наиболее близкий к ИИ-нативному решению подход из тех что я видел. Плюс решение агноистичное к PLM/CAD системам и допускает локальное развёртывание, на базе локальных моделей. Cosmon развивает Nexus — агентную платформу для разработки физических изделий, которая работает не вместо CAD, CAE и PLM, а поверх уже существующего стека. В этом и состоит наиболее интересная часть подхода: ИИ получает не отдельную команду для конкретной программы, а высокоуровневую задачу, сам разбивает её на этапы, вызывает нужные инструменты, анализирует результат и продолжает работу до достижения цели или до момента, когда требуется решение человека. По сути, Nexus превращает SolidWorks, NX, Ansys, COMSOL и другие системы в инструменты единого агентного процесса. Пожалуй, это один из наиболее близких к AI-native подходов, которые сегодня видны в этом домене: автоматизируется не интерфейс отдельного приложения, а сам процесс разработки, проходящий через несколько специализированных систем. Архитектурно Nexus представляет собой локальное приложение с коннекторами к установленным рабочим инструментам. Модели и расчётные файлы могут оставаться внутри корпоративного контура, а агент взаимодействует с CAD и CAE через их API. При этом последовательности действий можно оформлять в повторно используемые workflows и skills, сочетая детерминированные корпоративные правила с адаптивным поведением агента. Для программной автоматизации Cosmon также развивает SDK, через который можно задавать цели уровня «проведи расчёт для всех деталей этого набора», не реализуя отдельно интеграцию с API каждой CAD или CAE-системы. В перспективе такой слой может координировать не только геометрию и расчёты, но и требования, изменения, конфигурации и данные PLM. В качестве примера они сравнивают своего агента со встроенными в SolidWorks: https://cosmon.com/blogs/solidworks-ai-tools Небольшое изменение геометрии может нарушить подавленное сопряжение, родительско-дочернюю зависимость эскизов или сделать предыдущий расчёт недействительным. Модель в CAD может оказаться одной ревизии, а запись или BOM в PLM — другой. Деталь отдельно может пройти проверку технологичности, но после сборки возникнет недопустимая размерная цепь. Если ИИ видит только состояние текущего окна SolidWorks, то значительная часть контекста остаётся за его пределами. Изменение модели становится событием, которое агент способен провести дальше: обновить связанный чертёж, повторить нужные проверки, подготовить или перезапустить расчёты, сравнить результат с требованиями и проверить соответствие данных в PLM. Здесь ключевой объект автоматизации — уже не файл и не команда, а связанный процесс изменения изделия. Встроенный помощник SOLIDWORKS видит прежде всего контекст SOLIDWORKS, тогда как реальный процесс может проходить через SOLIDWORKS, Ansys или COMSOL и PLM. Изменение геометрии способно успешно пройти локальную проверку, но вызвать проблему размерной цепи на уровне сборки или сделать устаревшим расчёт и запись в PLM. Поэтому следующий этап развития ИИ в CAD здесь связывается не столько с более умной генерацией геометрии, сколько с оркестрацией всей цепочки CAD → чертёж → DFM → CAE → PLM. При этом Cosmon не предлагает полностью передавать агенту принятие конструкторских решений. Формальные проверки, повторяющиеся операции, подготовка данных и координация инструментов могут автоматизироваться глубоко, но выбор между массой, стоимостью, технологичностью, прочностью или допусками остаётся за специалистом. Поэтому Nexus интересен не столько как «ИИ для SolidWorks», сколько как попытка изменить саму границу между человеком и инженерным ПО: человек всё меньше управляет последовательностью программ и команд и всё больше формулирует намерение, ограничения и критерии результата, тогда как агент берёт на себя исполнение и согласование технического процесса.

Выложили запись презентации новой версии Synera. Первая 1/3 на моей памяти сумбурна, но дальше огонь. Смотреть стоит.

Ну и раз уж мы про роботов https://github.com/Introduction-to-Autonomous-Robots/Introduction-to-Autonomous-Robots

Four professors at the University of Colorado Boulder spent years building it from lecture notes. MIT Press published it.

И отдельно компилируемый формат публикации книги интересное, по лучшему стандарту

https://robot-2-two.vercel.app Конфигуратор гуманоидного робота на основе моделей от опенсорсного робота Asimov 1 (кстати жду с нетерпением) Их модельки на GitHub: https://github.com/menloresearch/asimov-1/

CAM Agent — система автоматизации CAM-программирования при подготовке обработки на станках с ЧПУ. Агент получает геометрию детали, материал, заготовку, доступное оборудование, инструмент и технологические требования, после чего определяет последовательность обработки, выбирает операции, инструмент и режимы резания и строит траектории непосредственно в CAM-системе. Результатом остаётся обычная редактируемая CAM-модель: специалист может проверить и изменить созданные операции или продолжить работу вручную. Система работает с точной B-rep-геометрией и должна учитывать GD&T — базы, допуски и требования к поверхностям, связывая геометрию детали с технологическими ограничениями производства. В работе учитывается не только геометрическая возможность провести инструмент по заданной траектории, но и физика процесса: силы резания, вибрации, износ инструмента и деформация детали. Для многоосевой обработки дополнительно проверяется кинематика станка, включая столкновения и недостижимые положения. ИИ здесь выполняет прежде всего роль агента, управляющего специализированными средствами расчёта: «геометрия и требования → план обработки → выбор операций, инструмента и режимов → расчёт траекторий → физическая и кинематическая проверка → операции CAM». Это принципиально отличается от попыток генерировать G-code непосредственно языковой моделью: геометрия, траектории и физические ограничения остаются в детерминированном вычислительном контуре, а агент планирует работу и управляет им. Сейчас заявлена работа с Siemens NX и Mastercam, готовится интеграция с Creo; похожий подход начинает использовать Cimatron. Работают над переносом накопленного производственного опыта в поведение агента. Система может учитывать конкретные станки, инструмент, ограничения предприятия и ранее принятые CAM-программистами решения, чтобы похожие детали обрабатывались по уже проверенным технологическим правилам. Поэтому CAM Agent можно рассматривать не только как генератор траекторий, но и как средство формализации и повторного использования знаний, которые обычно остаются у отдельных специалистов. В результате получается не замена CAM-системы языковой моделью, а автоматизированный технолог-программист ЧПУ, способный провести деталь через значительную часть подготовки обработки, используя точную геометрию, физические модели и возможности существующей CAM-среды, при этом оставляя человеку проверку и окончательное решение. https://limitless-labs.ai/cam-agent

nTop выложили кучу видео со своего саммита, там конечно много бла-бла-бла, но с не последними людьми и обсуждается всякое, включая гиперзвук (хотя вот его я кажется уже выкладывал) https://www.ntop.com/ntop-summit-2026/

nTop постепенно перестаёт позиционировать себя просто как специализированный инструмент для implicit modeling и аддитивного производства. В nTop 6 компания хочет превратить своё ядро в контейнеризованную headless-инфраструктуру геометрии и физики, которую можно запускать программно и встраивать в автоматизированные pipelines, ИИ-системы и агентов. Это важное изменение: геометрический движок становится не обязательно интерактивным CAD-приложением для человека, а вычислительным сервисом, которым может управлять программа.

Не удивлюсь если в какой-то момент такое использование станет основным. AI-native на максималках. Смело, возможно даже слишком. Хотя посмотрим.

Одно плохо: если каждый CAD-вендор создаст собственный язык или API для программного описания фич, интеграторам придётся поддерживать отдельный backend для каждого такого языка, как это уже происходит с CAD-коннекторами. Для независимых PLM и text-toCAD-систем это будет ещё один слой vendor-specific интеграции. Хотя бы API создания выносок с номерами позиций унифицировали, ёлки-палки. Одна надежда на MCP.

The Tset tech modules' series: Machining

^^ А всплыло оно в связи стем, что они делают новое - оценку расходов на ИИ в supply chain, это становится одним из факторов цены. И обещают показать в новом выпуске их отчёта по индустрии. Заодно вероятно можно будет настоящим образом оценить реальные темпы втягивание ИИ в индустрии.

Оптимизация и расчёты бывает не только инженерными, и местами она может быть даже интереснее простой инженерной. Просто как пример подобного сервиса для интеграции в процессы оптимизации себестоимости, причём не только внутренней. Tset — платформа для расчёта себестоимости промышленных изделий на этапе разработки. Вместо цены поставщика или исторических данных ERP она строит расчёт снизу вверх: учитывает материалы, оборудование, производственные операции, время цикла, труд, энергию, отходы и накладные расходы. Поддерживаются сотни процессов — от литья, штамповки и мехобработки до электроники и сборки, с учётом стоимости производства в разных странах. Tset рассчитывает should-cost — обоснованную стоимость детали или сборки. Например, цену поставщика в €18 можно разложить на сырьё, литьё, мехобработку, труд, оборудование и накладные расходы и получить расчётную стоимость €15. Такая модель становится аргументом для закупщика при переговорах с поставщиком или позволяет разработчику понять, какие особенности конструкции делают изделие дорогим. Расчёт можно начинать с ранней BOM или 3D-модели, сравнивая материалы, геометрию, технологии и страны производства. По той же модели рассчитывается углеродный след, поэтому варианты сравниваются одновременно по стоимости и CO₂. В последнее время Tset активно добавляет ИИ, но не заменяет им точную расчётную модель. ИИ классифицирует детали, находит функционально похожие компоненты с другими названиями и номерами, выявляет аномалии и помогает подобрать технологический маршрут по аналогам. Это особенно полезно для больших массивов CAD, PLM и ERP, где одинаковые по сути детали могут существовать под разными обозначениями, у разных поставщиков и в разных проектах. Другой сценарий — ИИ как естественный интерфейс к Cost Intelligence. Можно спросить, какие компоненты сильнее всего увеличили стоимость сборки, где ухудшилась маржа или какие детали необычно дороги относительно аналогов. ИИ находит и анализирует данные, а стоимость вычисляет детерминированный движок. После соглашения о приобретении Tset компанией A2MAC1 в 2026 году это направление должно усилиться: расчётный движок объединят с большой базой реальных изделий и benchmark-данных A2MAC1, используя ИИ для поиска аналогов, массовых расчётов, построения cost-моделей и выявления аномалий. Сервис развивается из системы расчёта себестоимости в платформу Cost Intelligence: PLM знает, из чего состоит изделие, ERP — сколько оно стоило фактически, ИИ помогает разобраться в данных и аналогах, а Tset определяет, сколько конкретная конструкция должна стоить и почему. Естественное продолжение интеграции подобного - интеграция в итеративные процессы многомерные оптимизации изделия, когда цена становится одним из оптимизируемых параметров. Самый так сказать жизненный сценарий. Плюс развилки Build-or-Buy, изготавливать самим или заказывать у внешних производителей.

Давно вебинаров не было. Inside Plamo: How Agentic 3D Modeling Actually Works https://luma.com/scwaebry 26 августа, 19:00 - 20:00 по Минску На помню что Plamo — AI-native система 3D-моделирования, где пользователь задаёт текст, эскиз или изображение, а ИИ превращает их в редактируемую параметрическую модель. Это своего рода «vibe coding» для CAD: вместо ручного выполнения множества операций человек описывает результат и итеративно уточняет форму и размеры. В отличие от обычных text-to-3D генераторов, Plamo ориентирован на рабочую CAD-геометрию, включая BREP, пригодную для дальнейшего редактирования профессиональными инструментами. По сути, это агентный интерфейс к проектированию: человек формулирует замысел, ИИ выполняет построение модели-наброска, работа с которым продолжается в профессиональном CAD. https://illoca.com/plamo Их рекламное видео было ранее здесь: https://t.me/BOM_Voyage/184

^^ Так вот, к чему это — завтра они вебинар проводят https://us06web.zoom.us/webinar/register/WN_mX3OIfZtTBKNMIdt-pv4Ig#/registration

Многоразовая ракетная система SpaceX или репликатор из Star Trek — люди давно представляют технологии, позволяющие создавать всё более сложные физические системы. Однако на практике одним из ограничений остаётся системная инженерия, которую трудно масштабировать на большие команды людей и ИИ-агентов. Вебинар посвящён тому, как сочетание ИИ, SysML v2 и Git может сделать системную разработку более гибкой и итеративной, сохраняя работу между разными инструментами, организациями и контурами безопасности. На примере платформы SysGit покажут применение подходов Git к разработке системных моделей: управление версиями и изменениями, требованиями, MBSE и архитектурой, автоматизацию системной инженерии и симуляцию. Также будут продемонстрированы интеграция ИИ с SysML v2 через MCP-сервер и REST API. Основная презентация займёт около 30 минут, после чего предусмотрена сессия вопросов и ответов.

Интересующимся управлениями требованиями. Хотя мне кажется что их подход ограничивает систему и переусложняет её, можно проще. Но посмотрим, может я чего-то не понимаю. В конце концов их реально SpaceX использует.

SysGit — платформа для системного проектирования (MBSE), построенная вокруг идеи «Hardware as Code»: требования и архитектура изделия описываются как формальная модель и хранятся в Git почти как исходный код. Такой подход особенно оправдан при разработке сложных изделий в организациях с формализованными процессами, где множество подсистем, требований и команд должны согласованно развиваться годами. Это уровень выше CAD: модель описывает не геометрию деталей, а систему целиком — её подсистемы, функции, интерфейсы, параметры, требования и проверки. Например, требование к аварийному питанию связывается с аккумулятором, потребителями и тестом, подтверждающим его выполнение. Модель хранится в текстовых файлах SysML v2, поэтому к ней применим привычный процесс разработки ПО: commit фиксирует изменение, branch позволяет прорабатывать альтернативный вариант, pull request — проводить ревью, а diff и merge — сравнивать и объединять изменения. Из текста SysGit автоматически строит диаграммы, поэтому код и графика остаются двумя представлениями одной модели. Получается процесс "Requirements → System Model → Git → Review → Validation", где CI может автоматически проверять целостность модели и выполнение формальных правил. Такое представление удобно и для AI-агентов, которые могут анализировать зависимости, предлагать изменения и проверять результат. SysML v2 — новое поколение стандартного языка системного моделирования SysML. В отличие от ориентированного прежде всего на диаграммы SysML v1, он был фактически разработан заново и получил полноценное текстовое представление, формальную семантику и стандартный API. На нём можно описывать структуру и поведение системы, требования, интерфейсы, параметры и проверки вместе со связями между ними. Благодаря этому системная модель становится машиночитаемым артефактом, который можно версионировать, автоматически анализировать и передавать между инструментами. Именно на этом SysGit строит подход, превращающий системное проектирование в процесс, во многом похожий на современную разработку ПО.

Ansys SimAI — система, заменяющая тысячи повторных CFD- и FEA-расчётов быстрой моделью машинного обучения. Она обучается на уже рассчитанных конструкциях, используя геометрию, условия и результаты моделирования, а затем за секунды или минуты прогнозирует для новых форм давление, скорость потока, напряжения, температуры и другие величины вместо запуска полноценного CAE-солвера. В отличие от обычных суррогатных моделей, SimAI работает непосредственно с геометрией, без фиксированного набора CAD-параметров, и допускает значительные изменения формы и топологии. Система предсказывает не только интегральные показатели вроде аэродинамического сопротивления, но и физические поля на поверхности или в объёме. Для этого глубокое обучение и неявное нейронное представление описывают поле как функцию координат, не привязанную к исходной расчётной сетке. Сначала сотни или тысячи вариантов рассчитываются обычным CAE и образуют обучающий набор. Затем SimAI быстро проверяет тысячи новых конструкций: оптимизатор или ИИ-агент генерирует геометрию, модель оценивает её физику, плохие варианты отбрасываются, а лучшие развиваются дальше. Только финальные кандидаты отправляются на точный CAE-расчёт. Оценка уверенности позволяет выявлять конструкции, слишком отличающиеся от обучающих данных. SimAI не заменяет физические солверы: CAE остаётся источником обучающих данных и окончательной проверки, а машинное обучение ускоряет массовое исследование вариантов. Особенно это полезно для генеративного проектирования и многокритериальной оптимизации, формируя цикл «генерация конструкции → быстрое предсказание физики → оптимизация → точная CAE-проверка». https://ansyshelp.ansys.com/public/account/secured?returnurl=/Views/Secured/SimAI/v000/en/SimAI_ug/SimAI_ug/C_UG_SAI_overview.html

https://www.amazon.de/Building-Agents-Engineers-Practices-Development/dp/1569905622 От ведущих инженеров Synera

В отличие от автоматизации на основе правил, которая выполняет повторяющиеся задачи по заранее заданным инструкциям, ИИ-агенты действуют автономно и способны принимать решения в сложных и динамически меняющихся ситуациях. Эта книга показывает, как создавать ИИ-агентов для разработки продукции, прежде всего аппаратных изделий. Она предназначена для инженеров-разработчиков, конструкторов и руководителей инженерных подразделений. Рассматриваются основные принципы и архитектуры агентных систем, фреймворки и шаблоны проектирования агентов, а также их интеграция с CAx-, PLM- и ERP-системами. Отдельное внимание уделяется управлению такими системами, управлению изменениями, распределению ответственности и тому, как применение агентов может изменить организацию разработки продукции в будущем. Шаг за шагом показывается создание ИИ-агентов с помощью low-code-платформ, включая переход к многоагентным системам, где несколько агентов взаимодействуют для достижения общих или индивидуальных целей. Описываются критерии выбора пилотных проектов и основные этапы их внедрения. Практические примеры охватывают автомобильную промышленность, производство потребительских товаров и инженерные услуги, включая опыт NASA, Miele, IMS Gear и ARRK Engineering. Они показывают, как ИИ-агенты могут снижать затраты на разработку и сокращать время вывода продукции на рынок.