BOM Voyage

^^ Protolabs и Xometry решают похожую задачу: превращают заказ изготовления деталей в цифровой сервис. Инженер загружает CAD-модель, указывает материал, допуски, покрытие, количество и срок, после чего система быстро выдаёт цену, DFM-проверки и возможность сразу разместить заказ. Обе компании покрывают CNC, 3D-печать, литьё под давлением, листовой металл и другие процессы, поэтому для заказчика они выглядят как единая «точка входа» в большое количество производственных технологий. Protolabs исторически ближе к автоматизированной фабрике. Компания начала с быстрого изготовления пресс-форм и постепенно построила собственные производственные мощности, глубоко автоматизировав путь от CAD до изготовления. Это позволяет очень быстро выпускать прототипы и небольшие серии с относительно стандартизированными требованиями. Позже Protolabs добавила Protolabs Network — сеть внешних производственных партнёров для заказов, которые требуют большей мощности, более широкого набора процессов, сложных допусков или крупных серий. Таким образом, сейчас у Protolabs гибридная модель: собственные высокоавтоматизированные заводы плюс внешняя сеть. Xometry изначально построена скорее как marketplace производственных мощностей. Она сама выступает единым поставщиком для клиента, но физическое изготовление в основном распределяется между тысячами проверенных производителей. Центральный продукт Xometry — программная платформа, которая анализирует загруженную геометрию, автоматически оценивает стоимость и срок, даёт DFM-feedback, а затем подбирает подходящего производителя из сети. Компания прямо называет Instant Quoting Engine AI-powered и использует data science для расчёта цены и lead time. Сейчас сеть насчитывает несколько тысяч активных производственных партнёров и позволяет масштабировать заказ от единичных деталей до крупных серий. Упрощённо различие можно представить так: Protolabs — «мы построили автоматизированный завод и добавили к нему сеть подрядчиков», Xometry — «мы построили программный рынок, который превращает существующие заводы в одну виртуальную фабрику». Поэтому Protolabs сильнее контролирует сам технологический процесс на собственных мощностях, а Xometry сильнее в маршрутизации заказов, динамическом ценообразовании и использовании распределённой производственной ёмкости. На этом фоне Hadrian идёт ещё дальше по вертикальной интеграции. Xometry в основном оптимизирует связь «заказчик <=> производитель», Protolabs автоматизирует изготовление внутри стандартизированной цифровой фабрики, а Hadrian пытается программно автоматизировать практически весь завод: технологическую подготовку, оборудование, операторов, scheduling, inspection и качество. Поэтому условную эволюцию можно представить как Xometry — marketplace manufacturing, Protolabs — digital manufacturing, Hadrian — software-defined factory.

^^ ИИ у Hadrian используется прежде всего внутри Opus — программной платформы, которая связывает инженерную документацию, подготовку производства, оборудование, контроль качества и управление фабрикой. ИИ помогает интерпретировать CAD-данные, чертежи, спецификации и в том числе старую неструктурированную документацию, извлекая из них производственные требования. Далее система автоматизирует значительную часть работы, которую на традиционном предприятии выполняют технологи и производственные инженеры: определение последовательности операций, выбор оборудования и инструментов, подготовку производства и организацию контроля. Цель — сократить количество ручных решений между получением документации заказчика и запуском детали в производство. Кроме того, — в управление самой фабрикой. ИИ и алгоритмы оптимизации используются для планирования заданий, распределения их между станками и производственными ячейками, повышения загрузки оборудования и уменьшения простоев. Opus получает данные непосредственно из производственного процесса и объединяет их с информацией о заказах и требованиях. Благодаря этому Hadrian пытается превратить завод из набора отдельных CNC-станков, CAM, MES, QMS и действий операторов в единую программно управляемую систему. ИИ также участвует в контроле качества и обратной связи. Результаты измерений сопоставляются с требованиями к детали, отклонения связываются с конкретными этапами изготовления, а накопленные производственные данные могут использоваться для улучшения следующих циклов. Поэтому ИИ у Hadrian — не столько генерация CAD-моделей, сколько автоматизация роли технолога, специалиста по качеству и производственного диспетчера. Общая идея выглядит как CAD/чертёж → извлечение требований → технологический процесс → CNC → измерение и инспекция → анализ результатов → корректировка производства.

Hadrian, американская компания, занимающаяся строительством заводов и производством продукции для оборонной промышленности, привлекла $1,37 млрд в раунде Series D при оценке в почти $8 млрд. Идея компании — не просто продавать станки или ПО для завода, а строить и эксплуатировать производственные мощности как программно управляемую систему. Заказчик передаёт конструкторскую документацию и требования, а Hadrian берёт на себя изготовление деталей, контроль качества и, всё чаще, сборку более крупных изделий. Иными словами это Factory-as-a-Service, фабрика-как-сервис. Ключевой технологический компонент называется Opus. Hadrian описывает его как «операционную систему для автоматизации фабрики»: ПО интерпретирует в том числе старую конструкторскую документацию, автоматизирует подготовку производства, обработку и инспекцию изделий и старается максимально повысить загрузку оборудования. То есть это довольно близко к концепции software-defined manufacturing: CAD/чертёж → технологический процесс → станок → измерение → контроль качества образуют единую автоматизированную цепочку. Компания утверждает, что благодаря этому новых операторов можно обучать работе на производстве примерно за 30 дней. У Hadrian сейчас фактически три уровня продукта. Первый — обычное контрактное производство precision components, от прототипов до серийных деталей. Второй — Manufacturing-as-a-Service: Hadrian выделяет заказчику специализированные производственные или инспекционные ячейки, причём они могут находиться как на предприятии Hadrian, так и непосредственно у заказчика. Третий и наиболее интересный — Factories-as-a-Service: Hadrian проектирует, оснащает и эксплуатирует целый завод или производственную линию под конкретное изделие, сборку или программу. Hadrian фактически пытается автоматизировать тот слой, который в традиционном производстве размазан между технологами, CAM, MES, QMS, планированием, операторами станков и метрологией. Это попытка построить непрерывный цифровой pipeline: CAD/чертёж → распознавание требований → планирование производства → CAM/станок → измерение → inspection → данные качества → корректировка процесса. Концептуально близко к сочетанию Protolabs/Xometry, MES, CAM-автоматизации и роботизированной фабрики — только с существенно более глубоким вертикальным контролем над самим производством. Их основной продукт (сервис) фактически не software, а производственная способность. Их Opus нужен для того, чтобы эту способность можно было быстро клонировать. Hadrian утверждает, что новую фабрику на своей платформе можно вводить в строй менее чем за шесть месяцев. Если этот подход действительно масштабируется, это похоже на попытку применить к физическому производству модель облачных дата-центров: стандартизированная архитектура фабрики, общий software stack и возможность быстро добавлять новые «инстансы» производственной мощности. https://www.hadrian.co

Не могу не похвастаться тем, какие у меня агенты молодцы. Сегодня утром обнаружил что задачи начали публиковать статистику в деньгах - сколько стоила бы реализация выполненных задач, если бы токены были API, а не по персональной квоте по подписке. В целом, а так же в разрезе по этапам - планирование, кодинг, ревью и т.п. Оказалось ночью research агенты сами придумали такую фичу, проголосавали за реализацию, сделали и накатили обновление. До этого оценка производилась только в токенах. Кроме того прикрутили бюджетирование и автоподбор моделей для задачи исходя не только из её сложности, но и из бюджета, если он на задачу установлен. Каждую ночь оркестр агентов у меня не только делает задачи, если они есть в очереди, но и анализирует кодовую базу и документацию, ищет и исправляет ошибки, неточности. Но кроме того агенты ищут и идеи для дальнейшего развития, в том числе смотрят на другие подобные решения в интернете — можно ли что-то заимствовать, оценивают идеи консенсусом, несколько разных LLM, могут сразу сделать, либо оставить мне на рассмотрение. До запуска SkyNet остаётся примерно год.

И россияне — Dmitrii Zhemchuzhnikov (Москва) и Marina Barannikov (Париж). CADENA - ещё одна AI-реконструкции параметрического CAD по геометрии (mesh). На входе система получает например результат 3D-сканирования детали, а на выходе строит параметрический CAD. Формируемая последовательность CAD операций записывается как программа на Python/CadQuery: фактически задача формулируется как mesh → CAD code. Главная идея CADENA — отказаться от генерации всего дерева построения за один проход. Предыдущие модели пытались сразу предсказать полную последовательность операций и поэтому сильно зависели от типичных последовательностей, встречавшихся в обучающих данных. CADENA работает примерно так, как инженер вручную восстанавливает деталь: добавляет одну операцию, исполняет получившуюся CAD-программу, получает промежуточную геометрию, сравнивает её с исходной деталью и только затем выбирает следующую операцию. Если очередной шаг не улучшает соответствие, он отбрасывается. Получается замкнутый цикл «предположение → построение → геометрическая проверка → следующий шаг». Это существенно интереснее обычного text-to-CAD или mesh-to-CAD с autoregressive-декодированием. Модель получает обратную связь не только через токены программы, но и через фактически построенную геометрию. Поэтому ей необязательно заранее угадать правильную полную историю построения. Особенно заметно преимущество на сложных и нетипичных деталях — именно там статистическое воспроизведение знакомых CAD-последовательностей начинает плохо работать. Наиболее важен именно характер результата. Это не reverse engineering в традиционном смысле «подогнать NURBS/B-Rep поверхности под облако точек». CADENA пытается восстановить инженерную логику построения детали. Например, результат концептуально может выглядеть как: создать эскиз → extrusion → добавить цилиндрический boss → сделать отверстие → fillet → pattern. Такую модель затем можно параметрически менять, а не просто использовать как геометрическую копию исходной поверхности. Одновременно выпущен CADENA-Bench — 3396 реальных механических деталей, классифицированных по обычным инженерным семействам: валы, зубчатые колёса, корпуса, крепёж и т. п. Это важно, поскольку многие существующие CAD-ML benchmarks состоят из данных, распределение которых довольно далеко от реального набора промышленных деталей. На CADENA-Bench система выигрывает в пяти из шести категорий и по среднему результату. На BenchCAD авторы сообщают восстановление 91% целевого объёма против 71% у frontier-моделей общего назначения и 75% у специализированных решений. Код, веса модели и benchmark опубликованы открыто. GitHub: https://github.com/zhemdi/cadena Научная работа: https://arxiv.org/abs/2608.00799

Пока что без сборки, но думаю выложат

Наконец-то 100% китайское, живут и работают тоже в Китае. Правда до этого автор жила, училась и работала в США, но сейчас уже в Китае. https://github.com/Pan-Chera/Multi-Agent-CAD Multi-Agent-CAD, или MAC, — экспериментальная система text-to-CAD. Пользователь описывает деталь обычным текстом, а программа строит исполняемый Python-скрипт на build123d и получает из него 3D-модель в форматах STEP и STL. Дополнительно сохраняются исходный код модели, результаты измерений, диагностика неудачных операций и, при запуске через веб-интерфейс, GLB для просмотра в браузере. Основная идея проекта — создать полноценный гибридный CAD-конвейер. LLM отвечает за формализацию требований, геометрический план и сложные исправления; повторяемая часть выполняется детерминированным переводчиком; build123d/OCP строит точную модель; два QA-движка проверяют STEP и STL; Aider замыкает цикл. Главная архитектурная ценность — компактные структурированные границы между этапами и сохранение всех промежуточных артефактов. Заявлены результаты внутреннего бенчмарка на 10 деталях и 141 проверяемом признаке: 99,3 % пройденных признаков, примерно в 116 раз меньше токенов и в 13 раз меньшая стоимость по сравнению с использованным авторами single-agent baseline. Эти числа являются опубликованными авторами результатами, а не результатом локального воспроизведения при данном разборе. LLM можно использовать любую - хоть китайскую DeepSeek, хоть западные модели. src: https://x.com/xyz2maureen/status/2085346460032496025

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

А так же Coding for Engineer — открытая онлайн-книга Лина Кайзера, создателя PicoGK. Формально она обучает C#, но фактически её цель шире: научить инженера превращать предметные знания в программные модели. PicoGK появляется не сразу — сначала разбираются структура программы, классы, наследование, интерфейсы и архитектура модели и только затем начинается построение геометрии. Автор сознательно ставит классы, интерфейсы и декомпозицию раньше условных операторов. Идея состоит в том, что инженеру недостаточно научиться писать отдельные вычисления. Он должен научиться представлять изделие как систему объектов, правил и зависимостей. Содержание книги сейчас включает 26 глав — от нулевой до 25-й. Первые главы дают основы C#: — устройство вычислений и представление данных; — запуск и компиляция программы; классы, конструкторы и пространства имён; — наследование, полиморфизм и абстрактные классы; — интерфейсы; — типы-значения и ссылочные типы; свойства, nullable-типы и сокращённый синтаксис. После этого вводится инженерная декомпозиция. В главе о проектировании самолёта предлагается сначала разложить сложное изделие на программные сущности, их параметры и отношения, не пытаясь немедленно рисовать окончательную форму. Затем начинается непосредственная работа с PicoGK: воксели, решётки и булевы операции. В курсе есть центральный учебный проект — генератор технологического приспособления. На нём показывается, как последовательно перейти от простого скрипта к более организованной системе: выделить классы, абстрагировать вывод прогресса, создавать отверстия, выполнять воксельные операции и отделять инженерную логику от инфраструктурного кода. Это не просто упражнение по геометрии, а пример эволюции прототипа в поддерживаемую программу. В последних опубликованных главах строится профиль крыла NACA, рассматриваются полярные, цилиндрические и сферические координаты, а затем вводится строгая предметная типизация. Например, угол предлагается представлять не обычным float, а отдельным типом, который явно различает градусы и радианы. Это напрямую связано с надёжностью инженерного ПО: многие ошибки возникают не из-за неправильной формулы, а из-за смешения физически разных величин, представленных одинаковыми числами. https://picogk.org/coding-for-engineers/TOC.html

На всякий случай напомню, что Leap 71 - это бюро проектирующее и изготавливающее вот такие "сумашедшие", но при этом отлично работающие изделия - гиперзвуковые теплообменники, клиновидные ракетные двигатели и т.п. Композитная металлическая печать - изделия печатаются не одним сплавом, а несколькими сразу, используя преймущества разных сплавов в разных местах изделия. https://leap71.com

PicoGK — компактное открытое геометрическое ядро от LEAP 71 для программного построения инженерной геометрии на C#. Название расшифровывается как Pico Geometry Kernel — «малое геометрическое ядро». Проект намеренно предоставляет небольшой набор примитивов, из которых кодом собираются значительно более сложные формы: теплообменники, электродвигатели, решётчатые конструкции, корпуса, ракетные двигатели и бионические объекты. Главное отличие PicoGK от обычного CAD — не столько интерфейс, сколько представление геометрии. Традиционное параметрическое CAD-ядро обычно работает с аналитическими поверхностями, кривыми, гранями и топологией B-Rep. PicoGK в значительной степени опирается на воксельное и неявное представление формы. Внутри используется OpenVDB — библиотека для разреженных объёмных данных. Благодаря этому булевы операции, объединение множества тел, плавные переходы, сложные внутренние каналы и решётки выполняются устойчивее, чем во многих B-Rep-сценариях, где появляются микрограни, разрывы и проблемы с допусками. Архитектура состоит из двух частей. Верхний слой PicoGK написан на C# и предоставляет удобный объектный API. Низкоуровневый PicoGKRuntime написан на C++ и выполняет тяжёлые геометрические операции. Между ними находится небольшой C-интерфейс. Авторы рассматривают его как потенциальный общий контракт: теоретически вместо открытого runtime можно подключить другое, в том числе коммерческое, геометрическое ядро. Типичный процесс выглядит примерно так: — Инженер создаёт обычный консольный проект .NET. — Подключает NuGet-пакет PicoGK. — Запускает приложение через Library.Go. — Кодом создаёт решётки, объёмные поля, воксельные тела или полигональные сетки. — Выполняет объединение, вычитание и пересечение тел. — Просматривает результат во встроенном 3D-просмотрщике. — Экспортирует геометрию для дальнейшего расчёта или аддитивного производства. PicoGK не заменяет SolidWorks, CATIA или Siemens NX. Здесь нет привычного дерева построения, сборок, чертежей и полноценной работы с B-Rep. Его задача — алгоритмическое создание геометрии, поэтому он ближе к nTop, OpenSCAD и CadQuery, чем к традиционным CAD. При этом PicoGK выходит за рамки обычного скриптового моделирования. Программа описывает не последовательность геометрических операций, а саму модель изделия: физические зависимости, материалы, производственные ограничения, расчёты и оптимизацию. Например, по тяге, давлению и типу топлива она может автоматически построить камеру сгорания, сопло и охлаждающие каналы, а при изменении требований перестроить всю конструкцию. Такой подход LEAP 71 называет Computational Engineering — переносом инженерных знаний в исполняемые алгоритмы. У подхода есть и ограничения. Воксельная модель дискретна, поэтому точность определяется размером вокселя, а её повышение требует больше памяти и вычислений. Для высокоточных сопряжений и традиционного производства B-Rep нередко остаётся предпочтительнее. Кроме того, основную сложность здесь составляет уже не построение геометрии, а разработка самой программной модели изделия. https://picogk.org

Backflip AI представила этой ночью (что поделаешь, в США был день) второе поколение своей модели для восстановления CAD из полигональной геометрии. Вместо обычного преобразования STL или 3D-скана в B-Rep система пытается восстановить замысел построения детали: эскизы, выдавливания, вращения, отверстия, фаски, массивы и дерево операций. В результате получается редактируемая параметрическая модель, а не просто твердотельная копия исходной сетки. Поддерживаются STL, OBJ, PLY, GLB и другие форматы с экспортом в STEP или напрямую в Autodesk Fusion. Новая версия получила два режима работы: Fast для типовых деталей и Thinking для более сложной геометрии. По данным компании, восстановление модели занимает 1–5 минут вместо часов или дней ручного обратного проектирования. Одновременно появился мультимодальный поиск деталей по тексту и фотографии, а также заявлено использование технологии одним из крупных автопроизводителей. Сегодня система ориентирована прежде всего на детали, изготовленные токарной обработкой и трёхосевым фрезерованием; поддержка листового металла, литья и других технологий находится в разработке. Backflip интересна тем, что строит не очередной ИИ для генерации 3D-мешей, а фундаментальную параметрическую модель, понимающую логику CAD-проектирования. Если качество восстановления параметрических моделей окажется достаточно высоким, это может существенно сократить стоимость и время обратного проектирования, оцифровки архивных деталей и переноса изделий между CAD-системами. https://www.backflip.ai

Czinger Vehicles наоптимизировали и даже продают богатым.

Autodesk поглотила MaintainX — CMMS/EAM для управления техническим обслуживанием оборудования ориентированую на мобильную работу: сотрудники получают задания, выполняют пошаговые инструкции, проводят инспекции и сразу фиксируют результаты. Для каждого объекта хранится история ремонтов, инструкции, чек-листы, сведения о запасных частях и другие эксплуатационные данные. Платформа интегрируется с ERP, IoT и корпоративными системами. ИИ в ней помогает искать информацию в документации, формировать отчёты, анализировать историю ремонтов, выявлять аномалии и предлагать рекомендации по обслуживанию. Купили за 3,6 млрд долларов, рассматривая её как основу ИИ-платформы для управления жизненным циклом объектов. https://www.getmaintainx.com

Кстати напомнило Dirac BuildOS которая принимает CAD-сборку и автоматически: — выделяет логические узлы и подсборки; — предлагает порядок сборки; группирует повторяющиеся операции; — создаёт пошаговые 3D-анимации; — генерирует текст операций; формирует основу MBOM и BOP; — синхронизирует визуализацию после изменения структуры процесса. Заявляют, что автоматизируют примерно 80% подготовки инструкции. Оставшиеся сведения — моменты затяжки, смазка, герметики, оснастка, контрольные операции и производственные приёмы — добавляет технолог. https://www.diracinc.com/

Инструкции IKEA печально известны тем, что с ними бывает непросто разобраться. Поэтому я за три часа превратил их в интерактивное 3D-руководство по сборке и занял второе место на дизайн-хакатоне HQ Make-a-thon.

https://x.com/leakedleek/status/2084331062344511707

На всякий случай проговорю, что я не считаю публикуемые Text-to-CAD чем-то готовым к использованию, "очень интересно, продолжайте развиваться" - где-то на этом уровне, не более того. Пока что местами результаты хорошие, однако недостаточно уверенные. Когда-нибудь мы увидим не создание с нуля, а внесение точечных изменений по инструкциям в сложных изделиях, создание с нуля - это самый простой из сценариев. Но что уже реально можно пробовать и даже полноценно использовать - дополнительный слой контроля. Не как замену человеку, но дополнительно. Особенно уверено это работает в BIM, например Revit, в модели крупного здания с тысячами, а то и миллионами объектов ИИ хорошо находит недочеты которые пропускают люди, что экономит в подобных проектах и время, и деньги, и нервы проектантов. Как-нибудь выложу демонстрацию подобных сценариев. Плюс отдельные рутинные шаги в принятии решений в потоках работ (workflow), не слишком ответственные, но отдельно замечу что рискованность решений ИИ определяет достаточно точно, решение о том может ли он сам принять решение или ждать человека - вполне работающий уже сейчас сценарий. А более уверенный CAD, который можно будет использовать в рутинных задачах, - это горизонт примерно год-два, пока что просто смотрим что рождается, ещё не может ходить, но растёт на глазах.

Опубликовано с комментарием "А что, если затем мы добавим к агенту ещё и инструменты для ручного редактирования CAD?" Ещё один Text-to-CAD стартап https://arche.co Их агент пишет параметрический CAD-код на Python, который становится "исходным кодом" изделия. — создание CAD-моделей по текстовым инструкциям; — параметрическое моделирование, где Python является источником истины; — интерактивные правки через диалог с агентом; — встроенный конечно-элементный анализ и CFD, выполняемые прямо во время проектирования; — автоматический подбор стандартных компонентов из каталогов поставщиков; — проверка технологичности изготовления (DFM) для 3D-печати и листового металла; — публикация готовой конструкции как неизменяемой версии, пригодной для заказа.