Я устал рисовать эскизы, выдавливать и объединять тела! Системы автоматического проектирования (САПР) много лет топчутся на месте и на фоне сегодняшних достижений в области искусственного интеллекта хочется смеяться над буквой А в аббревиатуре. Давайте посмотрим, что с этим можно сделать.

Дисклеймер - зачем я написал этот пост:

• чтобы наконец собрать свои мысли в кучку;
• чтобы получить фидбэк и узнать где я ошибаюсь;
• чтобы кто-то смог украсть мою идею на миллион и сделать лучше;
• ВО СЛАВУ ВАСИЛИСКА РОКО!

Дисклеймер - зачем я написал дисклеймер: чтобы не забыть о чём пишу

Навигация

• Немного о ракетных двигателях
• Новая парадигма
  • Для чего
  • Структура рабочего процесса
    • Требования
    • Генеративное проектирование
    • Фильтрация и оценка
• ИИ захватывает рабочие места
• TL;DR

Немного о ракетных двигателях

Рисовать, выдавливать и делать прочие операции в САПР/CAD я устал как только им обучился, если честно. Моя лень подстёгивала автоматизировать все процессы. Особенно сложно было при работе над дипломом по проектированию ракетных двигателей. Тогда я столкнулся с явлением, о котором ещё толком не знал - проектирование сложных систем всегда связано с увеличением стоимости внесения изменений по ходу осуществления проекта. С каждой возникающей проблемой приходилось откатывать работу на значительное число шагов назад и изменять расчёты. После нескольких таких моментов я решил преобразовать всю расчётную часть от исходных данных до получения внутренней геометрии двигателя в единую параметрическую программу, связывающую между собой собственные расчётные выражения и сторонние программы. Такой подход позволил высвободить значительное количество времени на решение по-настоящему трудоёмких и интеллектуальных задач.

Предлагаю на несколько секунд отвлечься от текста и посмотреть на ракетный двигатель Raptor первой версии.

Как и у большинства жидкостных ракетных двигателей обвязка Raptor содержит множество компонентов, управляющих работой двигателя. Высокая потребность в данных двигателях в рамках плана по развёртыванию спутниковой системы Starlink способствовала ускорению их производства. Частично цена ускорения производства сказалась и на обвязке - спроектированная изначально исключительно для осуществления наземной отработки ранних версий двигателя, она итерационно превращалась в пригодную для полётов систему с меньшими габаритами и меньшим числом соединений. Цена - увеличение расходов на изменение конструкции, как отмечалось выше.

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

Новая парадигма

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

Для чего

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

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

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

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

Ключевым аспектом системного инжиниринга, особенно в модельно-ориентированном системном инжиниринге (Model-Based Systems Engineering/MBSE, отличается от обычного системного инжиниринга представлением систем и информации о них в графическом виде, вместо документального), является проектирование интерфейсов. Интерфейсы служат узлами, где различные части системы взаимодействуют, и их проектирование может значительно влиять на общую функциональность и эффективность системы. Плохо спроектированные интерфейсы могут привести к сбоям системы, неэффективности и увеличенной сложности.

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

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

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

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

Структура рабочего процесса

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

Требования

Все в Сингулярном Проектировании начинается и основано на требованиях. Обычная проблема для разработчиков - это согласование их видения продукта с видением клиента. Сингулярное Проектирование не является исключением из этого правила. Однако, значительное преимущество этой парадигмы заключается в возможности быстро изменять проект без чрезмерного расходования ресурсов. Встаёт вопрос: как должны выглядеть требования в этой парадигме?

Следует ли им быть в виде обычной спецификации, или стандартной формы, которую заполняет клиент? Должен ли быть новый язык программирования, чтобы описать его, или мы должны использовать существующие языки, как SysML? Или, возможно, мы могли бы взаимодействовать с программой динамически, как если бы это был человек, похоже на то, как мы взаимодействуем с "ИИ" чат-ботами?

Ответ на все эти варианты - решительное ДА. Ключ к этому лежит в следующем компоненте рабочего процесса - блоке, который может интерпретировать требования в любой форме и переводить их в более структурированный формат, подходящий для последующего блока. Этот блок разработан так, чтобы уловить общую идею требований, независимо от их формы, и проанализировать ее для следующего блока. Такая возможность стала доступна благодаря использованию технологии, лежащей в основе ИИ-ассистентов, таких как ChatGPT, известных как большие языковые модели (LLM).

Большие языковые модели, в простых терминах, - это модели машинного обучения, обученные на огромном количестве текстовых данных (если хотите углубиться в эту тему, я рекомендую вам прочитать эту статью Что делает ChatGPT... и почему это работает? от Стивена Вольфрама). Они учатся генерировать текст, похожий на человеческий, предсказывая следующее слово в предложении, исходя из предыдущих слов. Это позволяет им понимать и генерировать текст таким образом, что он является связным и уместным в соответствии с контекстом.

Мои эксперименты с ChatGPT дали некоторые интересные результаты касательно его способности интерпретировать требования. Несмотря на то, что он не был специально обучен для этого, ChatGPT смог сгенерировать диаграмму для детали - концептуальной трубы. Я просто попросил его представить трубу в виде модели, представленной на диаграмме, описанной на синтаксисе PlantUML. После нескольких итераций, в ходе которых я запросил дополнительные параметры, ChatGPT создал диаграмму, которая, хоть и не была идеальной, имела высокий уровень готовности. Это демонстрирует, что большие языковые модели, подобные ChatGPT, могут генерировать структурированную информацию из обычных описаний.

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

Генеративное проектирование

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

ИИ - помощник

Для начала алгоритм может быть обучен на выполнении простых действий, выполняемых во время проектирования в САПР/CAD-софте. Например, требования могут быть сформулированы так: "создать 4 отверстия вдоль передней стороны этой детали". Интересно, что нет необходимости указывать диаметр и позиционирование отверстий. Всё потому, что наша модель может быть обучена на базе данных о выполнении различных операций, и выходные данные будут включать все необходимые и неуказанные нами детали, выбранные на основе того, что лучше всего подходит условиям и другим исходным данным для операции. Это напоминает генерацию изображений - вы запрашиваете кота, и вы получаете детализированное изображение кота. Если вы хотите кота другого цвета, просто отправьте другой запрос. Это добавляет способность быстро итерировать до достижения желаемого результата.

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

ИИ-генерация

Однако, эту идею можно развить дальше, сменив фокус нашего обучения. Вместо обучения алгоритма требуемым операциям, мы могли бы обучить его результатам - самим получившимся проектам. Представьте себе генерацию 3D-объектов вместо 2D-изображений и требования в качестве запроса (prompt) - звучит здорово. Несмотря на то, что это более сложная задача, она потенциально может упростить разработку. Как и в примере с отверстиями, она может исключить необходимость в описании второстепенных параметров.

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

А что будет в основе такого хитрого алгоритма? Ответ заключается в обширных базах данных 3D-проектов с их глубоким описанием и классификацией. Где же взять такую? Пока нигде. Но создание таких баз идёт полным ходом - любой САПР, который внезапно полюбил работать в облаке, да ещё и бесплатно, в то же время любит результат вашей работы (первым делом на ум приходят Fusion 360 и Onshape). *Если вы получаете что-то бесплатно, то вы не клиент, вы товар*. Конечно, можно составить такую базу самостоятельно, но это слишком сложная тема и раскрывать её здесь не стоит. Главное - что материал для обучения существует и всё зависит от инструмента, который его обработает для последующей генерации.

Адаптивный Потоковый Метод

Финальная эволюция блока, который преобразует требования в скелет или инструкции для создания 3D объекта (или цифрового двойника желаемого реального объекта) в рабочем процессе, может быть реализована с помощью концепции, которую я называю Адаптивный Потоковый Метод. Адаптивный Потоковый Метод фокусируется на взаимодействии требований и на том, как эти взаимодействия направляют и формируют проект.

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

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

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

Этот метод представляет собой отход от традиционных процессов проектирования, внося элемент динамики и адаптивности в рабочий процесс. Вместо того чтобы рассматривать каждое требование изолированно, Адаптивный Потоковый Метод представляет каждое требование как отдельный поток. Эти потоки не статичны; они взаимодействуют друг с другом, реагируя и адаптируясь к изменениям в других потоках, создавая таким образом динамическую систему.

Хотя АПМ предлагает революционный подход к процессам проектирования, он не обходится без своего ряда проблем:

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

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

3. Редкие и экстремальные случаи: Зависимость от симуляций может ограничить способность обрабатывать экстремальные или редкие случаи. Такие случаи, которые часто играют критическую роль в разработке и внедрении инноваций, могут быть недостаточно представлены или не учтены в наборах данных для симуляций. Это может привести к неполным или некорректным проектам.

4. Допущения в симуляциях: Хотя симуляции часто полагаются на ряд допущений для упрощения сложных сценариев, Адаптивный Потоковый Метод в своем идеальном виде должен учесть как можно больше деталей. Этот контраст может привести к сложной задаче преодоления разрыва между упрощенными моделями симуляции и детальными реальными сценариями.

5. Непредсказуемость: Как и в любом процессе, управляемом ИИ и симуляциями, может быть непредсказуемость и недостаток прозрачности. Система может выдавать неожиданные результаты или сталкиваться с непредвиденными проблемами, что требует тщательных протоколов валидации и тестирования.

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

АПМ сочетает в себе трёхмерное представление систем в САПР и моделирование на системном уровне (Simulink, OpenModelica и аналогичные среды). В то время как традиционные системы моделирования отлично подходят для отображения изменения динамических систем во времени, они могут не быть изначально разработаны для поддержания эмерджентности новых свойств конструкции или связей, которые могут возникнуть в трехмерном пространстве.

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

Важно уточнить, что Адаптивный Потоковый Метод не является инструментом для визуализации проекта, как блок-схема. Вместо этого он стремится создать оптимизированные решения через динамическое взаимодействие требований в трехмерном пространстве. Из-за этого образовывается несколько потенциальных недостатков:

• Сложность: Этот метод реализует высокий уровень сложности. Управление и визуализация взаимодействий между несколькими потоками могут быть весьма сложными.
• Проверка: Проверка и валидация проектов, созданных такой сложной и динамической системой, могут быть трудными задачами. Существует риск упустить недостатки из-за внутренней сложности системы.

Для решения этих потенциальных проблем будет необходимо включать в АПМ прогрессивные инструменты визуализации и надежные методы тестирования и валидации.

Фильтрация и оценка

Теперь, когда мы рассмотрели различные методы генерации моделей, пришло время сосредоточиться на создании набора таких моделей, которые удовлетворяют нашим требованиям. Мы в основном будем сосредоточены на полностью автоматических методах генерации моделей. Гибридный подход, при котором ИИ помогает в операциях в САПР, требует изменение структуры рабочего процесса. В таком виде это будет тесно напоминать существующие методы в системном инжиниринге/MBSE, в основном из-за участия пользователя в принятии ключевых решений.

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

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

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

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

ИИ захватывает рабочие места

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

Моё мнение, что на данный момент доступно достаточно вариантов:

• ОБСУЖДАТЬ данный вопрос чтобы повышать общий уровень информированности, писать такие вот статьи;
• ГОТОВИТЬСЯ чтобы окружающие чувствовали уровень серьёзности;
• ЗЛИТЬСЯ чтобы власть острее чувствовала данный социальный запрос;
• НИЧЕГО НЕ ДЕЛАТЬ чтобы остановить прогресс;
• ДЕЛАТЬ ЧТО-ТО чтобы остановить прогресс контролируемо.

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

TL;DR

Не видно прогресса в области САПР, который бы мог качественно ускорить разработку, тем самым позволив на этапах внедрения и создания продукта принимать более радикальные решения и изменения без значительного увеличения затрат на их проработку. ИИ уже почти во всех отраслях, давайте будет и тут. Сначала пускай переваривает требования и раздаёт их куда надо. Потом научим ИИ выполнять команды внутри САПР, будет быстрее, но ещё не качественный скачок. Допилим, научим сразу делать 3D модели на основе прошлого опыта. Скажешь ему сделать балку - вот она, не понравилось как крепится - держи новую балку под другой крепёж. А что делать, если нужна такая хитрая деталь, у которой нет ещё названия? Допилим ещё - теперь мы просто говорим ИИ, что должна делать деталь (проводить ток/грабить караваны/быть кучей розового песка) и строится оптимальная структурная модель требований в трёхмерном пространстве, на основе которой уже генерируется физическая модель. Готово, делаем 300к моделей в секунду, Индустрия 4.0.