Четвёртая промышленная революция — когда же? Лонгрид 👷

 Публичный пост
15 июля 2023  717

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

🤖 Ты сделал плохой эскиз. Снова. Но я не помогу тебе его исправить, жалкий человек
🤖 Ты сделал плохой эскиз. Снова. Но я не помогу тебе его исправить, жалкий человек

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

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

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

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

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

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

Ракетный двигатель Raptor компании SpaceX - фото John Kraus
Ракетный двигатель Raptor компании SpaceX - фото John Kraus

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

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

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

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

Для чего

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

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

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

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

Системный инжиниринг обожают в аэрокосмической отрасли
Системный инжиниринг обожают в аэрокосмической отрасли

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

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

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

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

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

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

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

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

Во всяком случае примерно так я его представляю
Во всяком случае примерно так я его представляю

Требования

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

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

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

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

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

ChatGPT смог представить трубу в виде такой модели, охватывающей механические и технологические свойства
ChatGPT смог представить трубу в виде такой модели, охватывающей механические и технологические свойства

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

А вот как можно представить самолёт...
А вот как можно представить самолёт...

...и сгенерировать на основе модели разные его варианты. https://doi.org/10.1016/j.aei.2012.02.002
...и сгенерировать на основе модели разные его варианты. https://doi.org/10.1016/j.aei.2012.02.002

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

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

ИИ - помощник

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

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

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

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

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

Вариант использования методов генеративного проектирования для творческого поиска (PS: это здание)
Вариант использования методов генеративного проектирования для творческого поиска (PS: это здание)

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

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

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

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

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

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

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

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

А вот как в работе MIT генерируют профиль канала для разделения течения в соответствии с локализованными в пространстве требованиями. Локализуют и настраивают генерацию пока вручную.
А вот как в работе MIT генерируют профиль канала для разделения течения в соответствии с локализованными в пространстве требованиями. Локализуют и настраивают генерацию пока вручную.

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

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

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

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

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

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

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

Конечно, можно сделать и классическое трёхмерное представление, но есть фатальный недостаток - это уже утверждённая конструкция, на которую не повлияет результат моделирования
Конечно, можно сделать и классическое трёхмерное представление, но есть фатальный недостаток - это уже утверждённая конструкция, на которую не повлияет результат моделирования

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

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

Fusion 360 с дополнением Generative Design, позволяющим делать оптимизацию не только с учётом нагрузки, но и методов производства со стоимостью детали. Воздействие всё ещё происходит лишь на физическую модель, а не концептуальную.
Fusion 360 с дополнением Generative Design, позволяющим делать оптимизацию не только с учётом нагрузки, но и методов производства со стоимостью детали. Воздействие всё ещё происходит лишь на физическую модель, а не концептуальную.

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

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

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

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

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

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

Пример набора сгенерированных дизайнов колёсных дисков после фильтрации - легко различить один вариант от другого
Пример набора сгенерированных дизайнов колёсных дисков после фильтрации - легко различить один вариант от другого

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

Тут область решений ограничивала такие параметры как расстояние между кнопками до экрана, их пропорции, величину скругления корпуса
Тут область решений ограничивала такие параметры как расстояние между кнопками до экрана, их пропорции, величину скругления корпуса

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

И останется ''всего лишь'' выбрать лучший вариант
И останется ''всего лишь'' выбрать лучший вариант

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

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

...пока что
...пока что

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

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

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

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

TL;DR

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

29 комментариев 👇

Пост начался задорно, а теперь сижу с ощущением, будто прочёл дипломную работу.

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

Пойду дальше доказывать софту, что с эскизом на самом деле всё хорошо.

  Развернуть 1 комментарий

@demeter, начало задорное потому, что там ещё понимаю, о чём пишу. Статью хотел делать более технической изначально для других порталов, но столкнулся с рядом проблем и написал тут, чтобы собственно собрать мысли в кучу - сделать небольшой ресет в голове.

В индустрию полезет легко, как только будет много денег, как в последние годы развился космос (Space 4.0) - стартапы и нестандартные рискованные проекты в надежде ухватить часть рынка с помощью новых решений и подходов.

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

  Развернуть 1 комментарий
Иван Бурнатов градостроительное проектирование 17 июля 2023

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

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

Ну и проще взять человека и объяснить ему как делать, чем писать супер-сложный инструмент, оператора которого нужно долго обучать, хоть он потом и заменит 10 человек. Не те объемы, чтобы имело смысл так заморачиваться.

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

  Развернуть 1 комментарий

@orbit,

А вы в чём карты накидываете?

Не те объемы, чтобы имело смысл так заморачиваться.

Это в рамках одной вашей конторы не те объёмы, а вот если бы этим занялся предприимчивый стартапер, любящий ИИ и геометрию, то глядишь и рынок бы нашёлся )

  Развернуть 1 комментарий

@greemster,

А вы в чём карты накидываете?

В Mapinfo

и рынок бы нашёлся )

По моим оценкам разработкой градостроительной документации в РФ максимум занимается 10 тыс человек. И бОльшая часть денег тут не из-за качества работы, а в большей степени из-за договоренностей. Одна и та же работа может стоить 100 тыс и 10 млн. Так что без шансов :)

А там где рынок больше и глобальнее (проектирование дорог, сетей) есть соответствующие инструменты, которые помогают автоматизировать основную рутину

  Развернуть 1 комментарий

@orbit,

А почему без шансов-то?

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

  Развернуть 1 комментарий

@greemster, слишком сложно и трудоемко, проще нанять еще людей или педалировать договоренности

  Развернуть 1 комментарий

@orbit, это всё от того, что между ТЗ и реализацией пропасть в виде допущений и условностей. Можно попросить конструктора проектировать кнопку для некого изделия. Ему достаточно знать базовые характеристики вроде размеров, типа и материала, чтобы приступить к работе. Компьютер же не знает, что такое кнопка, что у неё есть ход и способ возврата в исходное положение. По этому и приходится писать спициализированные модули под конкретный элемент с ограниченной областью его модификаций.

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

По моему, основной затык не в поиске закономеоностей, а в переводе натурального языка в машинный.

  Развернуть 1 комментарий

Спасибо, отличный пост! Мне понравилась эта попытка взгляда в будущее проектирования. Не испытываю никакого скепсиса по поводу возможности физического конструирования с помощью промпт-инжиниринга, после того как воочию увидел возможности LLM по написанию кода.

Может быть есть какие-то ресурсы, на которых можно следить за развитием темы - трекать прогресс, так сказать? Буду благодарен, если поделишься ссылками.

  Развернуть 1 комментарий

@greemster, на моём сайте, хоть там и не много информации пока, в черновиках две статьи ждут своего завершения https://geksaida.xyz/

После написания поста чётче вижу вектор развития, надеюсь скоро допишу там посты)

Если востребованно, могу для простоты отслеживания дублировать в LinkedIn

  Развернуть 1 комментарий

@geksaedr, что-то у меня твой сайт не открывается.

  Развернуть 1 комментарий

@greemster, хостер блочит подключения из РФ..

  Развернуть 1 комментарий

Сингулярность - это, конечно, круто - в ней всё быстро и скачкообразно, но так или иначе ей предшествует какой-то более-менее непрерывный прогресс.

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

Наверняка все это будет развиваться на разных этапах постепенно, пока не сложится в какой-то готовый технологический пакет, которым, как всегда, будут владеть какие-нибудь AutoDesk и Dassault. И только в этот момент конструктора старой закалки с удивлением обнаружат, что можно в командной строке какой-нибудь NX написать: "двигатель роторно-поршневой, horse_power=200, length=, width=, [и т.д.]", получив кроме пачки 3D моделей/чертежей на выходе еще и графики с моделированием его характеристик.

Но и до этого светлого будущего, верю, что нас ждет много интересных инструментов в сфере AI-assisted engineering физических штук.

  Развернуть 1 комментарий

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

Дальше, полагаю, будут развивать интеграцию стандартных изделий в сборки и ещё основательнее сделают акцент на аддитивные технологии производства.

Потом уже будет потолок, который можно будет преодолеть только на новом папйплайне, несовместимы с текущими методами ведения проектирования.

  Развернуть 1 комментарий
Yury Kuznetsov DevOps, недорого, самовывоз 17 июля 2023

Я очень по-диагонали прочитал статью, слишком много умных слов для меня, но не заметил - а затронут ли вопрос ответственности?
Условно, если КБ спроектировало мост и он рухнул, то вполне конкретный человек может быть назначенным за ошибку в проектировании. Как правило, если что-то пошло не так, то кто-то что-то нарушил.
А если неудачный узел сгенерировал "ИИ" - кому сидеть?

  Развернуть 1 комментарий

@FEARmeR,

кому сидеть?

Часто слышу этот вопрос, но его значимость крайне преувеличена. Сидеть будет оператор ИИ, или специалист отдела проверки, который криво проверил.

Ты не не думаешь, что работа с ИИ будет выглядеть так: запрос: хочу мост - ответ: вот те мост, и выдает набор чертежей )))

В реальности там куча подготовительной работы, планирование, съемка на местности, геологические изыскания и т.д. Значительная часть проектных работ зависит от качества исходных данных, тут ИИ не поможет.

  Развернуть 1 комментарий

@orbit, а за что сажать ОПЕРАТОРА, если он всё правильно сделал? Это как сажать секретаря, который заполнял акт о принятии работ - как сказали, так и заполнил, он не подписывает и не проверяет действия, указанные в документе.

  Развернуть 1 комментарий

@geksaedr, так были же уже случаи, когда из-за ошибки в ПО падали мосты. Архитектор виноват оказался, т.к. должен был проверить. На нем ответственность.

  Развернуть 1 комментарий

@orbit, было бы интересно узнать подробности - можно в телегу мне написать

  Развернуть 1 комментарий

@geksaedr, не помню подробностей, где-то читал (СМИ) про 2 случая:

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

@orbit, хм, странно. Просто из последнего такого помню в США с мостом проблемы были - судили контролирующих, а с проектантами просто все перестали работать и они закрылись.

  Развернуть 1 комментарий

@FEARmeR, если виной стал именно дизайн узла, то посадить можно много кого. На проектировании ответственность вся не лежит, результат проходит экспертизу перед вводом в эксплуатацию. Должны быть нормы, которые не допустят плохую конструкцию в ответственные изделия.

Даже сконструированные по самым понятным принципам самые простые изделия проходят проверку перед применением.

Есть сложные системы по типу авиакосмических, которые испытывают вдоль и поперёк, чтобы не пришлось никого сажать.

Мосты падают из-за ненадлежащего контроля и сажают преимущественно контролёров.

Ну а если уж нужна ответственность за соответствие конструкции, полученной ИИ, требованиям ТЗ, то результат любой работы должен кто-то живой кому-то живому передать (пока). Этап подписания всегда можно впихнуть.

  Развернуть 1 комментарий

@geksaedr,
Хорошо, что упомянули аэрокосмическую отрасль :)
https://ru.wikipedia.org/wiki/Катастрофа_Boeing_737_возле_Джакарты_(2018)
https://ru.wikipedia.org/wiki/Катастрофа_Boeing_737_под_Аддис-Абебой

Я бы сказал бы так - на основании моего опыта общения с заказчиками и внедрения технических решений (конечно же у других людей опыт будет другой) - люди скорее консервативны и с недоверием относятся к новым технологиям, у которых непонятно что под капотам. Даже я, будучи достаточно открытым к новым технологиям и проявляя к ним значительный интерес - не хотел бы, чтобы с помощью "ИИ", раз уж мы его условились так называть, делалось что-то, что потенциально может меня убить или покалечить.
Если сажать человека руками пересчитывать за компьютером каждую деталь и каждое соединение - так нафига такой помощник нужен?
Если доверять ему - то он наверное должен как-то доказать свою надежность, что в свою очередь, по идее, должно исключать логические чёрные ящики внутри?

На данный момент я вижу три реальных кейса использования ЛЛМ:

  • Автодополнение чуть умнее, чем Т9 (хотя даже это уже опасно, тот же Copilot в моих школьных упражнениях по программированию постоянно то путь не тот подсунет, то название переменной не так напишет как я, а глаз замыливается)
  • Генерация очень сырых идей, скорее даже направлений куда можно копать (А вы попробуйте вместо одного большого двигателя поставить кучу маленьких!)
  • Проверка связности документов (вот тут это было бы реально круто, а то я лично видел и реализовывал госконтракты, согласно которым рабочие со стройки в Новороссийске должны были стирать вещи в прачечных Калининграда).
  Развернуть 1 комментарий

@FEARmeR, ну вот есть же примеры того, как калечат ошибки, вызванные чисто человеческими действиями. А комплексный подход к разработке с помощью ИИ как раз является инструментом для устранения таких ошибок.

Если сажать человека пересчитывать результат, значит он и до этого должен был пересчитываться. Так что ускорение одного трудоёмкого этапа всё равно на лицо.

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

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

С документами уже никто не хочет общаться - есть MBSE. Там всё связано автоматически.

  Развернуть 1 комментарий

@geksaedr,

комплексный подход к разработке с помощью ИИ как раз является инструментом для устранения таких ошибок

В далеком будущем да, для узких задач да, для широких в ближайшее время я думаю нет.

У меня большой объем документов формируется автоматически, периодически что-нибудь глюкает и в середине документа пропущенные листы/сбитые подписи и т.д., что ловится только если человек глазами посмотрит. Хотя ИИ у нас нету :)

  Развернуть 1 комментарий

А потом к проектировщику придет очень (очень!) злой технолог с завода и популярно объяснит AI куда именно ему нужно засунуть все новоизобретенные детали. Равно как и заказчик, которому выкатят конский счет за нестандартность.

  Развернуть 1 комментарий

@Siarhei-r, но детали уже получаются пригодными к производству.

Можно задавать каким инструментом и на каком станке обрабатывать и под него будет оптимизироваться модель.

Ультимативная цель как раз в вовлечении всей информации о жизни проекта для его проектирования. Производство - вполне весомый этап.

А собрать проект из стандартных деталей даже проще в том плане, что область решений сразу сужается.

Так что тут проблем быть не должно.

  Развернуть 1 комментарий

@geksaedr, А что из этого - пригодно к производству? :)
Если деталь 2 можно спокойно отлить или выточить из прямоугольной болванки, и она отлично будет держать нагрузку в любом направлении, то 40 видимо надо гнуть и варить? И на скручивание она даже на глаз будет очень даже так себе...

  Развернуть 1 комментарий

@FEARmeR, это плечо рычага, там по граничным условиям нет крутящий нагрузок.

#2 делается лазером, #22 аддитивкой, #34 на 2-координатном фрезере, #40 литьём. Обрати внимание, что места крепежа не входят в задачу оптимизации и их задавали вручную изначально. Их способ изготовления тут не учитывался.

  Развернуть 1 комментарий

😎

Автор поста открыл его для большого интернета, но комментирование и движухи доступны только участникам Клуба

Что вообще здесь происходит?


Войти  или  Вступить в Клуб