Catia

Управление требованиями

28.12.2020 10:22:36 |

Автор: admin

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

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

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

Что такое требования и в чем суть проблемы?

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

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

Иерархия требований

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

Для организации процессов разработки сложных изделий Независимая Ассоциация системных инженеров рекомендует использование метода RFLP (Requirements Functional Logical Physical). В таком методе, опираясь на управление требованиями, в первую очередь определяют функциональный состав изделия, т.е. какие функции должно выполнять разрабатываемое изделие.

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

Имитационное моделирование

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

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

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

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

Для чего нужны инструменты работы с требованиями?

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

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

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

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

Платформа 3DEXPERIENCE и другие средства

Платформа 3DEXPERIENCE позволяет совместно работать с требованиями и включает в себя инструменты их формализации, привязки требований к элементам состава изделия, состава проекта разработки и испытательных работ. Всё это дает возможность не просто вести учёт требований, а с целью принятия осознанных решений анализировать требования по затратам и результатам от их реализации.
Решение CATIA Magic позволяет выявить и проанализировать потребности заинтересованных сторон, участвующих в производстве, вводе в эксплуатацию, в самой эксплуатации изделия, и выводе из нее. Все это обеспечивает полноту и правильное представление требований с самого начала жизненного цикла изделия, а именно недостаточная полнота и представление требований, как мы уже знаем, являются источником 2/3 ошибок в проектировании изделия.
Решение Stimulus ещё на ранних стадиях разработки еще на уровне определения требований моделирует поведение системы и анализирует взаимозависимость и реализуемость требований. Однако для такого моделирования необходимо должным образом сформулировать требования.

Самый современный подход к разработке сложных изделий это основанный на моделировании моделей системный инжиниринг (MBSE, Model-based System Engineering). Требования один из трех китов, на которых базируется MBSЕ, без реализации которого невозможен системный инжиниринг.

Платформа 3DEXPERIENCE обеспечивает прозрачность требований в связке с методиками определения соответствия, прозрачность хода испытаний и их результатов. Система построена на рекомендуемом в системном инжиниринге подходе RFLP, что дает возможность на ранних стадиях провести имитационное моделирование и расчёты, выполнить анализ систем и внести необходимые изменения ещё в цифровой среде. А цифровые изменения, как известно, на порядок-другой дешевле натурных.
Функционал платформы 3DEXPERIENCE выходит далеко за рамки учёта требований, а именно:

Составление спецификаций требований с ранжированием;
Составление программы испытаний;
Планирование и управление ходом работ по программе испытаний;
Управление результатами испытаний с корреляцией результатов виртуальных и натурных испытаний;
Наглядное отслеживание хода выполнения программы испытаний и результатов определения соответствия требованиям.

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

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

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

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

Подписывайтесь на новости Dassault Systmes и всегда будьте в курсе инноваций и современных технологий.

Dassault Systmes официальная страница

Facebook
Vkontakte
Linkedin
3DS Blog WordPress
3DS Blog on Render
3DS Blog on Habr

Подробнее..

Категории: Инженерные системы , Управление проектами , Анализ и проектирование систем , Проектирование и рефакторинг , Cad/cam , Cad , Блог компании dassaultsystèmes , Dassault systemes , Управление требованиями , 3dexpirience , Catia , 3d проектирование , Mbse , Инженерные решения , Cad/cam/cae/plm , Инженерные расчеты

Цифровизация управления проектами

07.12.2020 18:15:24 |

Автор: admin

Задачей проекта цифровизации при сооружении дожимной компрессорной станции Еты-Пуровского газового месторождения стало создание 3D-модели в ПО CATIA по исходной рабочей документации, настройка программного обеспечения 3DEXPERIENCE для обновления модели в ходе управления изменениями, проверка качества поступающих обновлений со стороны генерального проектировщика и настройка цифровых протоколов и документооборота.

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

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

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

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

Дорога ложка к обеду

Генеральным подрядчиком по сооружению стала компания ООО КСМП. Поставщиком цифровой платформы 3DEXPERIENCE была выбрана компания ООО ЛМП Проджект Груп, официальный партнер Dassault Systemes в РФ и СНГ.
Данный проект цифровизации начался, когда стройка уже шла полным ходом: объект был частично готов, поэтому цифровизация оказалась неполной. ООО ЛМП Проджект Груп пришлось буквально догонять реальные процессы строительства объекта. Тем не менее, общая тенденция в компании перевод бумажных документов в электронный формат дала, например, возможность руководству в любой момент просматривать нужные документы, даже со своего смартфона.

В апреле, мае и июне 2020 г. также прорабатывались вопросы с электронными поручениями. Как показала практика, это оказалось вполне реальным и уже внедряется на ряде объектов компании. Портал управления проектами на основе 3DEXPERIENCE обеспечивает работу в единой унифицированной среде. С помощью цифровой платформы руководство теперь может контролировать ключевые процессы.

В ПО CATIA была разработана 3D-модель строящегося объекта, и ей реально пользовались, но действительности она очень нужна еще в самом начале строительства, на нулевом этапе. Такая модель, в частности, позволяет увидеть, как будет выглядеть объект после завершения строительства, отмечают специалисты заказчика.

На практике оказалось, что когда была закончена 3D-модель объекта, который предназначен для транспортировки газа одного из месторождений, его строительство уже было на этапе 60% готовности, поэтому данная модель использовалась в основном для проверки, контроля и тестирования. Сейчас такие модели разрабатываются в обязательном порядке для всех газоперекачивающих станций, рассказывает представитель заказчика. Каждая подобная модель действительно необходима и полезна, но она должна быть своевременной. Следует начинать ею пользоваться в нужный момент, на самом начальном этапе.

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

Управление изменениями

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

Управление несоответствиями

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

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

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

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

Процесс должен быть максимально автоматизирован, подтверждает руководитель строительства КСМП Антон Постолов. У нас это делается через платформу 3DEXPERIENCE. Она позволяет в режиме реального времени получать представление о бизнесе и бизнес-экосистеме, объединяет людей, идеи и данные в единой цифровой среде совместной работы. Ключевые участники проекта отмечают простоту использования 3DEXPERIENCE, гибкость при получении информации, доступность данных в любой момент времени, возможность формирования корпоративной базы знаний и многое другое.

Если есть решение руководства о строительстве такого объекта как газоперекачивающая станция, то даётся задание эксплуатирующим обществам на расчет ее требуемой эффективности и мощности. На выходе делается технико-экономическое сравнение. Эти данные определяют концепт проекта. Например, определяется экономическая эффективность применения перекачивающих агрегатов с электродвигателем. Параллельно начинаются изыскательские работы: берутся пробы грунта и пр. Затем начинается процесс проектирования, готовится рабочая документация и начинается стройка. Каждый бизнеспроцесс тесно переплетен с BIM-моделью, размещенной в 3DEXPERIENCE, где доступны дополнительные инструменты цифрового управления проектами, инженерной документацией.

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

Разработка техкарт на основе 3D-модели в 3DEXPERIENCE

Кто пользуется 3D-моделью такого производственного объекта? Это примерно 15% руководящего состава, также она нужна непосредственно исполнительным производствам, производственным компаниям, мастерам, прорабам, инженерам ПТО, которые осуществляют технический надзор за выполнением строительно-монтажных работ. 3D-модель позволяет легко выявлять различные коллизии, она используется также теми, кто оформляет документы, составляет исполнительные схемы.

Именно 3D-модель определяет все параметры трубопроводов, линии контуров, она же становится основой для подготовки инструкций и проведения испытаний.

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

Если еще два-три года назад 3D-модели применялись достаточно редко. Сейчас же практически каждая станция проектируется на основе 3D-модели. Поэтому 3D-модель необходима в нужное время и на нужном этапе строительства.

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

Результаты и планы

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

Цифровая платформа позволяет получать сводную итеративную аналитику по проектам и регулярную аналитику использования ресурсов.

Управление проектами это вопрос номер один. Развитие и внедрение средств управления проектами одна из целевых задач, которые ставит руководство компании-заказчика. В ее ближайших планах расширенное использование имеющихся инструментов 3DExperience: работа с отклонениями в проекте, прогнозирование нестыковок, рисков, управление качеством BIM-моделей, управление проектированием на основе BIM-моделей и многое другое.

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

Хотите узнать больше? Напишите нам

Подробнее..

Категории: Управление проектами , Работа с 3d-графикой , Cad/cam , 3d , Блог компании dassaultsystèmes , Dassault systemes , 3dexpirience , Catia , Catia v5 , 3d моделирование , 3d проектирование , Цифровая платформа

CATIA из истории одного проекта

24.08.2020 10:10:39 |

Автор: admin

Насколько легко использовать возможности современных систем автоматизированного проектирования для автомобильной отрасли, включая инструменты моделирования поверхностей и функции работы с цифровыми макетами программного решения CATIA V5? Какой это дает эффект, какие возникают проблемы? Лучше всего показать это на конкретном примере.
В данном случае речь пойдет об одном из проектов компании Ладуга.

Ладуга это российская автомобильная инжиниринговая компания, разрабатывающая электронные и механические компоненты и системы для транспортных средств. Она работает с отечественными и зарубежными автомобильными компаниями Daimler, General Motors, Audi, Opel, АВТОВАЗ, КАМАЗ, РОСТЕЛЬМАШ, УАЗ и рядом других.

Конечно, CATIA это не единственный применяемый в компании программный пакет. Ее инженеры работают с CAD пакетами (NX), CAE пакетами (PRADIS, LS-Dyna, Ansa, Ansys, Ansys CFX, Fluent, Ansa, Salome, Code-Aster, OpenFoam). Однако CATIA играет ключевую роль в проектах по разработке дизайна, собственно проектированию и оптимизации в соответствии со стандартами и требованиями к автомобилю.
Например, как спроектировать детали интерьера легкового автомобиля, его внешние поверхности крылья, бампер, то есть экстерьер автомобиля? Без серьезной САПР не обойтись. С деталями двигателя или элементами трансмиссии тоже все непросто.

Сложная задача

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

Инструментарий проектировщика

Программное обеспечение CATIA V5 позволяет разрабатывать трехмерные модели изделий, ассоциативные чертежи деталей и сборочных единиц, поддерживает работу с большими сборками, ассоциативные связи между 3D-моделью и ее проекциями на чертежах, включает в себя инструменты моделирования поверхностей и работы с цифровым макетом (DMU).

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

Разделение труда

Проект впускного коллектора (модуля впуска) для двигателя легкового автомобиля один из самых крупных и длительных в данной компании. Он реализовывался с июля 2013 года по сентябрь 2015 года. Проектирование и подготовку конструкторской документации выполнили специалисты компании Ладуга, а непосредственно изготовлением изделия и поставкой на конвейер занимается ее индустриальный партнер. Над проектом работали конструкторы и команда расчетчиков Ладуги.

К конструкции изделия предъявляется множество требований. Модуль должен быстро и просто устанавливаться на конвейере, нужен удобный доступ к свечам зажигания и возможность легко замерить уровень масла. Для оценки выполнения этих требований применялся кинематический анализ модели. Непосредственно проектирование изделия выполнялось в пакете CATIA V5. В нем же готовилась конструкторская документация.

Множество подобных проектов компании Ладуга, выполняются в CATIA V5. Они длятся от месяца и дольше, в зависимости от стадии автомобильного проекта. Другие проекты, например, связанные с электроникой, могут выполняться с помощью других программных пакетов, что связано с требованиями заказчиков. Сам процесс проектирования выполняется совместно конструкторами, технологами и расчётчиками. Расчеты в Ладуге выполняются в отдельных CAE пакетах, в том числе разработанных самой компанией.

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

От прототипа к изделию

Конечно, модуль впуска это прежде всего аэродинамика. Его задача максимально наполнить воздухом цилиндры двигателя. В течение двух месяцев конструктора и расчетчики перебрали множество решений.
Рассматривали варианты банки модуля с дополнительными сквозными колодцами для управления потоками воздуха, внутренними рёбрами, различной формой каналов (раннеров). Всё это обсчитывалось на проверку требований по аэродинамике и акустике. Основными критериями по аэродинамике были максимальное наполнение цилиндров и равномерное распределение воздуха по цилиндрам. А оценка уровня шума особенно важна, поскольку пластиковый корпус модуля мягкий по сравнению с традиционным алюминиевым модулем.
По результатам проектирования изготавливается опытный образец изделия. Модуль впуска работает в подкапотном пространстве в сложных условиях. Стандартная 3D печать в 2013 году, увы, давала на выходе слишком хрупкие детали, которые не могли выдержать ни высоких температур, ни больших нагрузок. Поэтому основной технологией прототипирования тут выступало литье в силиконовые формы.

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

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

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

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

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

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

В сжатые сроки

А что со сроками?

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

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

Моделирование в 3D и подготовка документации

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

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

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

Данную задачу значительно упрощает поддержка ассоциативности в CATIA. Когда происходит обновление 3D-модели, то чертежи автоматически обновляются с минимальными ручными правками.

Провал на испытаниях и работа над ошибками

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

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

Недостаточная прочность материала прототипа (это не основной материал на этой стадии проекта) и различные исследовательские режимы испытаний привели к разрушению конструкции.

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

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

Новые планы

Сейчас автопроизводитель создает двигатель второго поколения, на который должен устанавливаться новый модуль впуска. Компания Ладуга проектирует этот новый продукт также используя ПО CATIA.

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

Сложности перехода

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

В данное время у нас даже нет возможности изучать весь новый функционал, внедрять его в проекты. Еще одна серьезная задача интеграция 6-й версии пакета с системой PLM. Это обеспечит грамотное управление изменениями, версиями, составами и так далее. Обсуждается также вопрос проектирования электрических кабелей в перспективных проектах. Для этого в CATIA есть отдельный модуль для проектирования кабелей, позволяющий делать 3D-трассировку жгутов и проводов. Она интегрируется с пакетами ECAD и значительно упрощает разработку электронной архитектуры. Такие задачи сейчас возникают при проектировании автомобилей и электромобилей. Даже в простом автомобиле километры жгутов. Тем более это актуально для электромобилей.

При внедрении CATIA V6 наряду с тем, что мы используем много разного другого программного обеспечения, возникает вопрос экспорта и импорта данных. Это требует применения плагинов, дополнительных конвертеров. Бесшовной интеграции не получается. Но, в конечном счете, и этот вопрос будет решен, уверен Валерий Овчинников.

Даже ведущие конструкторы используют функционал CATIA не более чем на 20% в силу того, что за последние годы разработано множество функций, утверждает он. Как освоить тот или иной функционал, насколько он будет нам полезен это вопрос методологический, и мы этому ещё только учимся. Требуется разработать методологию проектирования с использованием нового функционала.

Наш постоянный партнёр и надёжный поставщик услуг технической поддержки программного обеспечения Dassault Systemes компания СиЭс Групп. Её сотрудники оперативно решают вопросы, касающиеся работы программы CATIA и платформы 3DExperience. Валерий Александрович Овчинников.

Подробнее..

Категории: Визуализация данных , Анализ и проектирование систем , Управление продуктом , Cad/cam , Cad , Проектирование систем , Блог компании dassaultsystèmes , Dassault systemes , Сапр , Сапр системы , 3dexpirience , Catia , Catia v5 , 3d моделирование , 3d проектирование , Цифровые технологии

Электрические батареи, цифровизация и инструменты проектирования

21.09.2020 18:14:10 |

Автор: admin

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

Электрические батареи разного типа и формата уже давно стали неотъемлемой частью жизни современных людей. Считается, что первая батарея была создана около 2000 лет назад. Она состояла из глиняной банки, заполненной уксусом, железного стержня и медного цилиндра. С тех пор в технологии изготовления этих источников энергии многое изменилось. Современные батареи развиваются и совершнствуются более двух столетий. Батарею, подобие которой используется в наше время, в 1798 году создал Алессандро Вольта. Помимо собственных знаний Вольта использовал результаты опытов Луиджи Гальвани.

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

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

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

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

Инструмент для инженера

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

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

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

Электрофикация всей страны

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

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

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

Если же говорить про космос, то тут и без внешних факторов всё очевидно: все применяемые источники электроэнергии, по сути батареи: солнечные, химические (литий-йонные, литий-кадмиевые, водородные и т.д.), а также радиоизотопные (РИТЭГ). Единственная альтернатива им ядерный реактор.

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

В конце сентября концерн BASF начинает серийное производство новых батарей без лития. Пока такие технологии дороги, но запрет на классические дизели и даже на двигатели внутреннего сгорания подстегнет развитие электротранспорта. Например, в Швеции новые автомобили с дизельными или бензиновыми двигателями не будут продаваться после 2030 года, Норвегия планирует ввести запрет на продажу автомобилей с ДВС с 2025 года, а Дания, как и Швеция с 2030 года. Среди государств, принявших аналогичные нормы, есть и такие крупные экономики, как Великобритания и Франция. Последние склоняются к запрету ДВС к 2040 году.

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

Одно из наиболее перспективных направлений водородные топливные элементы.

Водородные топливные элементы

Одним из инженерных трендов в области новых источников питания для силовых установок различных автономных систем являются водородные топливные элементы. Первый водородный топливный элемент сконструирован английским ученым Уильямом Гроувом в 30-х годах XIX века. Была продемонстрирована возможность производства энергии в водородно-кислородном топливном элементе с использованием кислотного электролита. NASA использовало обновленный топливные элементы на космических аппаратах Аполлон в качестве главного источника энергии.

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

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

В РФ данная технология хорошо известна, есть передовые разработки. Они применяются в летающих беспилотниках, создан поезд на водороде: группа Трансмашхолдинг вместе с Росатомом планируют выпускать в России поезда на водородном топливе, а РЖД рассматривают остров Сахалин как пилотный полигон для их запуска.

За рубежом BMW и Toyota разработали водородную трансмиссию для экологичных автомобилей. Трансмиссия на водородных топливных элементах ляжет в основу автомобиля Hydrogen Next от BMW. Компания Mercedes-Benz представила свой первый серийный автомобиль на водородных топливных элементах GLC F-Cell.

У водородных топливных элементов высокий КПД 60%. И по этому параметру водородная энергетика является наиболее привлекательным источником энергии. Данная технология в сравнении с электрическими батареями дает также ряд других преимуществ, таких как увеличенное время автономности изделия, более высокая энергоотдача.

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

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

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

В помощь разработчикам

У компании Dassault Systemes имеется специальный инструмент для разработки систем на водородных топливных элементах библиотека Hydrogen Library в пакете имитационного математического моделирования поведения систем DYMOLA. Библиотека написана на языке Modelica, содержит ключевые компоненты систем на водородных топливных элементах PEM для интеграции в различные энергетические системы и силовые установки.

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

Dassault Systemes участвует во многих проектах как методологический консультант и поставщик ПО для моделирования, анализа, сравнения и интеграции данных.

Стандарт FMI

На помощь инженерам и разработчикам также приходит FMI (Functional Mock-up Interface) стандартизованный интерфейс, используемый в компьютерной симуляции при создании сложных кибер-физических систем. FMI открытый стандарт, разработанный для переноса моделей динамических систем между разными мультивендорными средами моделирования, а также для проведения совместных вычислительных экспериментов. Он позволяет решить одну из наиболее болезненных проблем в области системного проектирования обеспечить возможность переноса моделей между инструментами. На сегодняшний день стандарт FMI поддерживается о многих системах моделирования.

На сегодня стандарт FMI интерфейс для переноса и совместного использования моделей в различных средах моделирования стандарт, который становится всё более популярным.

Экспорт моделей в формате Functional Mock-up Unit (FMU) имеет разные приложения. Прежде всего, FMU может использоваться в разных средах и языках программирования. FMU также защищает интеллектуальную собственность, компилируя код модели в двоичный файл, что может быть полезно при обмене моделями с клиентами и коллегами.

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

Если в конце 20-го века в инженерном сообществе стандартом при разработке твердотельного макета изделия был формат STEP, STL или любой другой формат, то следующей вехой в развитии инструментов обмена инженерными данным становится формат FMI. Он описывает не только геометрические зависимости будущего изделия, твердотельную модель, но и его поведение, то есть как функционирует изделие в том или ином режиме работы.

Еще в 2008 году по техническому заданию Daimler AG компания Dassault Systemes создала европейский консорциум под названием MODELISAR, который после ряда технологических исследований и определил спецификацию будущей технологии и стандарта FMI. Его задачей было определить характеристики FMI, провести технологические исследования, доказывающие концепции FMI через разработанные сценарии использования.

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

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

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

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

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

Dassault активно работает над внедрением FMI. Математическое моделирование, как таковое, и формат FMI, в частности, стали неотъемлемой частью современного процесса проектирования.

В продолжение нашей статьи предлагаем вам посмотреть 3 видеоподкаста Dassault Systemes, раскрывающие темы Электрические батареи, Водородные топливные элементы и Functional Mock-up Interface FMI

Подписывайтесь на новости Dassault Systmes и всегда будьте в курсе инноваций и современных технологий.

Dassault Systmes официальная страница

Facebook
Vkontakte
Linkedin
3DS Blog WordPress
3DS Blog on Render
3DS Blog on Habr

Подробнее..

Категории: Научно-популярное , Математическое моделирование , Энергия и элементы питания , Цифровизация , Блог компании dassaultsystèmes , Dassault systemes , Catia , Catia v5 , Элементы питания , Электрические системы , Dymola , Mbse , Системная инженерия

Войны лоббистов и развитие BIM. Часть 3 Отцы BIM технологий. Кто стоит за успехом Autodesk и openBIM?

29.12.2020 10:06:55 |

Автор: admin

В этой статье мы осветим работу всех основных отцов BIM технологий, которые в 80-е и 90-е разрабатывали инструменты для автоматизированного проектирования. Разберём также, кто стоит за успехом организации buildingSMART и таких корпораций, как Nemetschek Group и Autodesk и почему старые программисты Autodesk не любили разработчиков Revit, а компания Nemetschek отказывалась от разработки IFC формата.

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

Как университет Мюнхена создал IFC формат.

К первой части этой темы - мне часто задавали вопрос, почему программное обеспечение, производимое в Европе, является более открытым и совместимым, чем ПО из других стран мира. Почему именно Европа является хорошим примером в разностороннем применении BIM ПО (openBIM)?Эта открытость связана с активным использованием формата IFC и openBIM программ. Чтобы понять, откуда появилась такая диверсификация или, точнее, раздробленность в подходах к BIM проектированию, посмотрим на историю возникновения openBIM движения.

Общеизвестно: всё, что связано с BIM, openBIM, IFC, Revit, - всё это придумала дальновидная и прогрессивная компания Autodesk.

Но всё-таки история openBIM начинается не с Autodesk, a с международных проектов, которыми занималось немецкое проектное бюро Obermeyer GmbH. Проектное бюро под руководством Leonard Obermeyer успешно работало над реализацией как крупных проектов на территории Германии, так и международных проектов в Европе. Поскольку Obermeyer зависел от международных проектов, глава бюро - Leonard Obermeyer - активно сотрудничал с руководителями американских корпораций, таких как: Patrick MacLeamy (CEO of HOK) и John Walker (Autodesk, Inc.).

Мюнхенский коллега Leonard Obermeyer, Georg Nemetschek, в это же время был категорически против сотрудничества немецких компаний с Autodesk и другими иностранными фирмами, так как такие партнерства открывали рынок Германии для создателей CAD программ из других стран. Georg Nemetschek разрабатывал узкоспециализированные программы (в основном для расчета статики), которые он продавал с 1977 г. Он считал, что местные производители ПО ещё не готовы бороться за рынок CAD планирования в Европе с такими стартапами начала 90-х, как Autodesk, Graphisoft и PTC.

В конце 80-х проектное бюро Obermeyer при проектировании нового мюнхенского аэропорта начало активно работать с международными архитектурными бюро и поставщиками строительных элементов и конструкций (таких, как Honeywell и HOK). Перед бюро Obermeyer возникла задача: как в больших международных проектах (например, строительство аэропорта в Мюнхене) передавать информацию о проекте и модели на производство в разные регионы мира, где в каждой стране свои правила, свои единицы измерения и свои нормы.

На счастье строителей, как раз к этому времени, задачу по стандартизации геометрических элементов уже решила более богатая военная промышленность стран НАТО, которые в конце 1970-х годов пришли к необходимости стандартизации в области обмена данными при производстве военной техники. В связи с этим, в кругах специалистов и учёных, занимающихся в основном машинной графикой и геометрическим моделированием, возникла соответствующая инициатива, которая была поддержана фирмами США и Западной Европы, занятыми разработками сложной военной техники для стран НАТО. И уже в 1985 году министерство обороны США объявило о планах создания глобальной автоматизированной системы электронного описания всех этапов проектирования, производства и эксплуатации продукции военного назначения.

Кратко уже к середине 80-х военные начали обмениваться данными с производителями в нейтральном стандарте и производить сложные конструкции через общий формат данных - STEP.

Но после окончания холодный войны, к концу 80-х, интерес к производству военной техники и разработке формата STEP резко падает. Наработки военных, добытые во времена холодной войны, начинают просачиваться в гражданский сектор. ISO стандарты из военной отрасли по формату STEP доходят до технического университета Мюнхена, где Richard Junge и его команда студентов, в числе которых был Thomas Liebich, видя успехи проектировщиков военной техники, пробует создать похожий формат передачи данных для строительной отрасли. Не изобретая новое колесо, Richard Junge берёт за основу военный формат STEP, чтобы не создавать новое геометрическое ядро и разработать формат, который станет независимым от производителей САПР.

Цитата Richard Junge в 2000 году:

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

Obermeyer (к этому времени ему 60 лет) патронирует свой бывший факультет и, находясь в тесном контакте с командой Richard Junge, обращается к своему знакомому Patrick MacLeamy (CEO of HOK) с идеей создать мировой формат для обмена строительными данными.

Patrick MacLeamy, видя перспективы и масштабы проекта, переносит всю тему с сертификацией и созданием (картельной) организации для написания правил и использования нового формата в Соединённые Штаты. Дальнейшая разработка формата IFC передается фирме Autodesk, которая, перенимая мюнхенские наработки, дополнительно пытается перестроить формат под своим нужды. Через несколько лет, в 1994 году, Autodesk регистрирует всю разработку формата IFC на своё имя. Patrick MacLeamy, вытеснив немецкий корни из всей истории, создаёт вместе с Autodesk картель (International Alliance for Interoperability - IAI) из американских консалтинговых и телекоммуникационных фирм, которые пишут стандарты и правила использования этого нового формата IFC в соответствии со своими требованиями.

Организация IAI официально регистрируется в торговой палате Чикаго в 1994 году. Инициативу по дальнейшему развитию формата и написанию стандартов американцы полностью берут в свои руки. А в 2005 году организации с непонятной аббревиатурой IAI дают более хайповое и понятное название - buildingSMART. С этого момента buildingSMART ставит целью устанавливать свои правила игры в строительном проектировании на всей планете Земля.

А Patrick MacLeamy, создатель buildingSMART, становится знаменитым, утверждая, что первым разработал концепцию кривой Маклими в 2004 г. Однако позже становится известно, что основа этих идей и подобных кривых впервые появилась в статье, написанной профессором Бойдом Полсоном в 1976 г. примерно за 28 лет до разработанной MacLeamy Кривой.

Отец БИМ - создатель SONATA или RADAR CH?

Если формат для (open) BIM моделирования был один - STEP/IFC, то в отношении первой настоящей программы для BIM (3D) моделирования всё намного сложнее. Это RUCAPS, Sonata, Reflex и RADAR CH. Но какая программа стала первой по-настоящему применяться для BIM моделирования?

Программа RUCAPS стала первой программой, которая в комплексе с единой рабочей станцией использовалась для реального проектирования зданий. Разработанная английскими инженерами Dr John Davison и John Watts, которые работали над проектом для Университета Эр-Рияда, RUCAPS стала одним из прообразов и ориентиров для многих последующих программ в BIM моделировании. В RUCAPS впервые была заложена концепция строительства по фазам, что очень помогло при возведении третьего терминала аэропорта Хитроу в Лондоне. Эти и ещё более ранние наработки, возможно, позже легли в основу программ, ставших настоящими прообразами уже современных программ - Sonata и Radar CH. Но что же появилось раньше: Sonata от Jonathan Ingram или Radar CH от Bojr Gbor и Ulrich Zimmer? Кого можно считать отцом BIM?

Во многих источниках на просторах интернета фигурирует, что ArchiCAD (первая версия называлась RADAR CH) в 1984 году стала первым программным обеспечением BIM, доступным на персональном компьютере. Сторонние специалисты отмечали, что в 80-х советские инженеры были впереди своих западных коллег в темах, которые касались машинной графики и геометрического моделирования. Поскольку экспорт в коммунистические страны был ограничен, программисты из Советского Союза привыкли работать на очень маленьких и простых компьютерах. Это означало, что у них был опыт создания относительно сложного программного обеспечения, которое могло работать на относительно простом оборудовании.

Dr Jonathan Ingram, в свою очередь, утверждает, что первым BIM программным обеспечением является написанная им программа Sonata, опубликованная в 1985 году. В подтверждение своих слов он ссылается (в личной переписке со мной, к сожалению, не могу проверить их подлинность) на открытые письма от создателя ArchiCAD, в которых Gabor Bojar признается, что на создание RADAR CH также повлияла Sonatа.

Цитата Gabor Bojar:

Кроме того, мы согласны с тем, что с технической точки зрения Sonata была в 1986 году был более продвинутой, чем ArchiCAD того времени. Однако мы по-прежнему считаем, что первый выпуск ArchiCAD в 1984 году (названный RadarCH на Apple Lisa) с его возможностями трехмерного моделирования зданий, параметрическими и интеллектуальными трехмерными объектами, можно рассматривать как новаторского предшественника BIM. При этом мы (Graphisoft - авт.) согласны с тем, что в 1986 году Sonata превзошла уже сформировавшееся определение BIM, уточненное лишь примерно через полтора десятилетия спустя. Что касается влияния Sonata на развитие ArchiCAD, то это, естественно, повлияло на нас, не нарушая никаких IP Sonata или T2. Конкуренты всегда учатся и влияют друг на друга, это стандартная и честная деловая практика до тех пор, пока конкуренты воздерживаются от посягательства друг на друга

На просторах интернета также можно найти изображение (справа) от Graphisoft (RadarCH), которое считается доказательством первой визуализации в 1984 году.

В общем, в этой истории больше вопросов, чем ответов. К первой визуализации Radar CH есть вопрос, так как компьютеры Mac с поддержкой цвета появились только в 1987 году. Но почему Steve Jobs сделал ставку на венгерско-советский стартап, находящийся за железным занавесом и не стал договариваться с близкими стартапами, которые разрабатывали ПО в силиконовой долине (скорее всего, Gabor Bojar нелегально смог импортировать несколько Mac компьютеров в Венгрию и переписал свой софт с медленных советских компьютеров на быстрый Mac). А на вопрос, откуда Gabor Bojar получил доступ к наработкам Sonata, Jonathan Ingram предпочёл не отвечать в письменной форме.

Словом, запутанная история, в которой только Интерпол, ЦРУ и КГБ может помочь нам разобраться: кто, когда и у кого взял идеи. Или всё-таки эти две программы имели общую теоретическую основу.

Предположу, что обе - ПО Radar CH и Sonata - начали с общей теоретической базы (RUCAPS или его подобие). Но при этом венгерская Radar CH была только трехмерной системой, с ограниченными параметрическими компонентами, в то время как у Sonata уже появились некоторые преимущества в создании рабочих чертежей, например, планов высот. В итоге, после публикации обеих систем, эти программы, возможно, позже черпали вдохновение друг у друга. Как сказал Gabor Bojar: "Конкуренты всегда учатся и влияют друг на друга, это стандартная и честная деловая практика".

B это же самое время на другом, более успешном, материке начинается новая эра CAD и MCAD ПО, которую открыла компания PTC (Nasdaq: PMTC) cо своим инновационным продуктом Pro/ENGINEER.

Создание Pro/ENGINEER и появление Solidworks и Revit

В 1974 году русский математик Самуил Гайзберг, профессор математики Ленинградского университета (сегодня Санкт-Петербург), эмигрирует сначала в Израиль, а затем в США (жена Гайзберга, работавшая над военными проектами в Ленинграде, эмигрировала в США несколькими годами позже).

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

Таким образом, в мае 1985 года Samuel P. Гайзберг основавывет Parametric Technology Corporation (PTC Inc.). И уже в 1988 году компания представляет свой первый коммерческий продукт на основе Unix под названием Pro/ENGINEER, сразу привлекая John Deere в качестве своего первого заказчика. Так Pro/ENGINEER стал первым программным обеспечением CAD для параметрического моделирования твердых тел.

Цитата Гейзенберга:

Цель состоит в том, чтобы создать систему, которая была бы достаточно гибкой, чтобы побудить инженера легко рассматривать различные конструкции. А затраты на внесение изменений в проект должны быть как можно ближе к нулю. Кроме того, традиционные CAD / CAM программное обеспечение того времени нереально ограничивало внесение недорогих изменений только в самый начальный этап процесса проектирования

Что отличало PTC от других производителей ПО, так это общая полнота всего цикла планирования. Pro/ENGINEER первой разработала !концепцию единой модели данных для всего проекта!. Эта концепция была позже успешно реализована в Revit Леонидом Райцем, бывшим выпускником того же Ленинградского университета (и скорее всего, бывшим учеником Гайзберга) и бывшим работником PTC..

Pro / ENGINEER произвела революцию на рынке MCAD (программное обеспечение для автоматизированного проектирования механических устройств). Параметрическое моделирование на основе элементов, взятое за основу в Pro/ENGINEER, будет доминировать в отрасли на протяжении четверти века, и все ведущие системы MCAD (CATIA, NX, SolidWorks, Inventor и Solid Edge) станут идейными преемниками Pro/Engineer.

В 1995 году Jon Hirschtick создаёт новый стартап - SolidWorks и переманивает большое количество разработчиков PTC вместе с вице-президентом и директором по развитию PTC - Michael Payne. PTC подаёт в суд на Solidworks за переманивание сотрудников, но обеим компаниям удалось уладить дело до того, как был нанесен слишком большой ущерб. Solidworks сразу становится главным конкурентом Pro/Engineer и уже в 1997 году французская компания Dassault, наиболее известная своим программным обеспечением CATIA CAD, приобретает SolidWorks за 310 миллионов долларов.

Выручка PTC с её основным продуктом Pro/Engineer резко выросла: со 163 миллионов долларов в 1993 году до 809 миллионов долларов в 1997 финансовом году. В этом же 1997 году выручка всей корпорации Autodesk была в два раза меньше, чем у PTC и составляла 497 миллионов долларов.В то время как AutoCAD мог похвастаться функционалом ограниченного 2D-моделирования, PTC стала программой настоящего 3D проектирования для всей машиностроительной промышленности. К середине 90-х клиентами компании были BMW, Fiat, Ferrari, Toyota, Hyundai, PSA и Volkswagen, Caterpillar, John Deere и остальные крупные игроки мировой промышленности.

К середине 90-х на рынке конструкторского планирования Pro/Engineer становится глобальным лидером. Теперь, чтобы перехватить инициативу в менее прибыльной строительной отрасли, в 1996 г. PTC покупает за 32 миллиона долларов программу Sonata у разработчиков Jonathan Ingram и Gerard Gartside. К этому времени Sonata уже переродилась в Reflex и реально была применена только на нескольких проектах в Англии. Но PTC полагала, что Reflex может стать основой новой линейки продуктов для комплексного проектирования зданий.

PTC дорого заплатила за относительно незрелое программное обеспечение Reflex и сильно недооценила усилия, которые потребовались бы для создания конкурентоспособной архитектурной программы для проектирования зданий. В итоге PTC не смогла выпустить достойный продукт для строительной отрасли и продала технологии Reflex техасской компании The Beck Group.

Успех команды SOLIDWORKS, которая построила продукт на разработках PTC и продала свой продукт за 311 миллионов Dassault Systems, видимо, повлиял еще на двоих работников PTC. Обладая знаниями о работе с Pro/ENGINEER и Reflex, два лучших разработчика компании PTC - Леонид Райц и, годом позже, Ирвин Юнгрейс - отделяются от PTC и в 1996 г. основывают собственную компанию по разработке программного обеспечения под названием Charles River Software (в Кембридже, Массачусетс, где уже были офисы PTC и Solidworks). Леонид Райц видел перспективы связки Pro/ENGINEER и Reflex, а также, видимо, был не согласен с продажей продукта техасской компании. Поэтому он ставит задачу создать версию программного обеспечения, которая могла бы обрабатывать более сложные проекты, чем ArchiCAD, но при этом использовать идеи общей модели и параметрического проектирования, которые он получил при работе над Pro/ENGINEER и Reflex. Код для новой программы командой Леонида Райца был написан с нуля, чтобы не нарушать патенты PTC и Reflex. Но сколько времени было у стартапа Revit до того, как инвесторы захотели вернуть свои деньги в 2001 году? Проблема с моделью ежемесячной подписки у Revit заключалась в том, что деньги поступали медленно и к концу каждого отчетного квартала компания подходила с кассовым разрывом.

Если взять 60 сотрудников Revit, которые зарабатывали в среднем 100 000 долларов США в год, и если при этом Revit получал 100 долларов в месяц за подписку, то получается, что компании нужно было 5 000 подписок, чтобы окупать вложения инвесторов каждый месяц. Сколько времени потребуется Revit, чтобы увеличить количество подписок до 5 000 и просто окупать текущие расходы?

Именно этот вопрос, скорее всего, заставил Leonid Reiz продать компанию за 133 миллионов долларов Autodesk.

Как развивались BIM стартапы. Слияния, поглощения и отношение к истории.

В 2002 году Leonid Raiz продает свой стартап Revit компании Autodesk. Продажи лицензий Revit дают взрывной рост корпорации Autodesk, и уже через 3 года после покупки, в 2005 году, Autodesk продаёт по 60 000 лицензий Revit в год, а начиная с 2019 года, Autodesk делает на продукте Revit - миллиардную выручку каждый год. Таким образом, небольшой корпорации Autodesk, выросшей на дрожжах инвестиций в Силиконовой Долине, с её единственным успешным продуктом 2D AutoCAD, разработчики RUCAPS - SONATA - Pro/ENGINEER подарили возможность стать мировым лидером в 3D проектировании.

Те, кто первым принимается за великие дела, обычно терпят неудачу, но они оставляют завоеванные плацдармы тем, кто следует за ними.

Samuel Butler

Как же развивались остальные BIM стартапы из 90-х?

ArchiCAD, который изначально задумывался как CAD программа для проектирования трубопроводов, стал успешным венгерским стартапом на европейском рынке. После опубликования формата IFC - Graphisoft обнаруживает, что программа ArchiCAD идеально подходит для работы с этим форматом и начинает активно внедрять применение IFC формата в свои продукты, что позволяет программе ArchiCAD выйти на мировой рынок ПО и к началу 2000-х годов стать лидером в строительном проектировании. Возможно, формат IFC хорошо подходил к Radar CH, так как некоторые смыслы созданного STEP пересекались конкретно с RUCAPS, или с другой подобной программой, которую взял за основу Gabor Bojar для своего Radar CH.

Nemetschek Group - тихий и уверенный игрок на европейском рынке CAD ПО со своими небольшими специализированными продуктами для проектирования. Он в своё время отказался от международного сотрудничества и от разработки формата IFC, но в 2006 году, от страха перед резкой экспансией Revit, покупает Graphisoft и становится главным соперником Revit. С покупкой Archicad Nemetschek Group наконец-то открывает для себя тему openBIM c ее мировой миссией и вместе с картельными схемами buildingSMART вступает в битву за рынок планирования в Европе.

Между тем такие корпорации, как Autodesk и Nemetschek, продолжают пиарить идеи из 80-х и 90-х как свои уникальные преимущества, при этом они умалчивают, что эти технологии достались им скорее через счастливое стечение обстоятельств, и скрывают свои корни и свою историю, чтобы лишний раз не напоминать о том, насколько все равны.

BuildingSMART не будут упоминать про немецкие корни в создании формата IFC и самой организации buildingSMART, поставив перед собой цель стать мировым интернетом в мире строительства и превращаясь в Советский Союз с членскими карточками, своей идеологией по использованию IFC и паспортами - сертификатами buildingSMART Certification.

Graphisoft и Gabor не любят вспоминать свои коммунистические корни, вспоминают лишь про свою успешную героическую борьбу с советским режимом и про установку первого в мире памятника Стиву Джобсу.

Autodesk не любит вспоминать про IFC и buildingSMART, после того как разработчики в 1996 году не смогли скрестить свои 2D продукты с форматом IFC (как и сегодня, ни один разработчик не может нормально подружить формат IFC c программами от Autodesk).

Также можно только представить, насколько тысячи программистов Autodesk в Силиконовой долине - создатели программы, которая не имела значимых изменений от года в года, - в начале 2000-х на дух не переносили десяток наглых выскочек с восточного побережья (с русским бэкграундом), которые с чистого листа за несколько лет написали улучшенную копию программы Pro/ENGINEER. А глава компании Autodesk в это время, Carol Ann Bartz, не ожидая от этого стартапа значимой прибыли, после покупки в 2002 году охарактеризовала Revit как небольшую экспериментальную базу пользователей (кстати о предсказательных возможностях глав компаний).

В заключение

Вопрос, кого можно реально считать отцом BIM, возможно, навсегда останется открытым.

У победы тысяча отцов, а поражение всегда сирота

Джон Кеннеди, 1946

Можно сказать, что реальный отец BIM - это идеи советских и английских математиков и программистов, которые смогли прорасти на плодородной денежной почве инвестиций в США.

А Samuel Geisberg помог своим бывшим сотрудникам PTC создать стартапы, которые, после продажи корпорациям, сегодня задают направление во всём мире CAD и MCAD планирования.

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

Но и Charles Eastman, и Samuel Geisberg, и Robert Aish, и Georg Nemetschek, и Jonathan Ingram, и Bojr Gbor и Leonid Raiz - я думаю, согласятся с тем, что они не придумывали ничего сверхнового. Они брали разработки своих более старших коллег и учителей и давали этим старым идеям новый смысл и новый дизайн.

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

Остаётся только надеяться, что в наше время интернет и профессиональные комьюнити заменят нам университеты и что такие новые ученики-самоучки всё чаще будут создавать Open Source продукты.

А Autodesk, PTC Inc. и Nemetschek Group хочется пожелать, чтобы вместо многомиллионных бонусов своим менеджерам, они перевели пару миллионов евро на благотворительные счета в технический университет Мюнхена, Санкт-Петербурга и Ливерпуля.

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

Войны лоббистов и развитие BIM. Часть 1: Как ленинградский математик помог Autodesk захватить мировой рынок CAD

В 17 веке каждый продвинутый голландский крестьянин хотел достать тюльпан, в 2017 продвинутый пользо...

habr.com

Войны лоббистов и развитие BIM. Часть 2: open BIM VS closed BIM. Revit vs ArchiCAD и Европа против остального мира

В первой части мы говорили о возникновения форматов STEP, IFC и создании организации buildingSMART. ...

habr.com

В статье собрано большое количество фактов, дат и связей. Если у вас есть какие-то дополнения к этой схеме, или если вы нашли несоответствие в указанных данных, - пожалуйста, напишите мне. Буду рад вашим комментариям, уточнениям и критике. Я буду рад добавить уточненные или новые данные к этой схеме. Спасибо большое за понимание.

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

Подробнее..

Категории: Open source , Дизайн , It-компании , Cad/cam , История it , Autodesk , Catia , Openbim , Archicad , Bim , Revit , Ifc , Steve jobs , Solidworks

	Русский
	English

Catia

Управление требованиями

Что такое требования и в чем суть проблемы?

Иерархия требований

Имитационное моделирование

Для чего нужны инструменты работы с требованиями?

Платформа 3DEXPERIENCE и другие средства

Цифровизация управления проектами

Дорога ложка к обеду

Управление изменениями

Управление несоответствиями

Разработка техкарт на основе 3D-модели в 3DEXPERIENCE

Результаты и планы

CATIA из истории одного проекта

Сложная задача

Инструментарий проектировщика

Разделение труда

От прототипа к изделию

В сжатые сроки

Моделирование в 3D и подготовка документации

Провал на испытаниях и работа над ошибками

Новые планы

Сложности перехода

Электрические батареи, цифровизация и инструменты проектирования

Инструмент для инженера

Электрофикация всей страны

Водородные топливные элементы

В помощь разработчикам

Стандарт FMI

Войны лоббистов и развитие BIM. Часть 3 Отцы BIM технологий. Кто стоит за успехом Autodesk и openBIM?

Как университет Мюнхена создал IFC формат.

Отец БИМ - создатель SONATA или RADAR CH?

Создание Pro/ENGINEER и появление Solidworks и Revit

Как развивались BIM стартапы. Слияния, поглощения и отношение к истории.

В заключение

Категории

Последние комментарии