Надеюсь, тот страшный сон с электропроводкой в А-380 больше не является по ночам руководителю программы PLM.
P.S. Ещё вот смотрю скриншоты и удивляюсь: вроде и Дассо - изначально авиационная компания, и страшные слова вроде 3DEXPERIENCE везде мелькают, а вот ввести в программе авиационную ориентацию системы координат всё никак не возможно. Столько неудобств при проектировании из-за такого пустяка возникало, а вот подиж-ты, проблема.

(=> Gook'у)

Что касается "страшного сна" - если помните, он произошёл из-за того, что:
1. "Немцы" и "Франзузы" использовали различные версии одного и того же САПРа.
2. А полноценной PLM, даже PDM - не было, все "нестыковки" по электрике выползали непосредственно в САПР

Тогда "разбор полётов" однозначно показал, что не стоит идти по пути установки у всех участников проекта одной и той же версии одного и того же САПР, ибо на практике авиастроения никогда такого положения на достаточно продолжительный срок по всем участникам добиться не удастся. А раз так, раз "зоопарка" САПР всё равно не избежать, то "гасить" разночтения при интеграции различных агрегатов-узлов-сборок в единое изделие надо "над" САПРовским зоосадом - в PLM. А вот тут уже AIRBUS потратил полгода (если память не изменяет, это было в 2009) и объявило тендер на поставку такой "оркестрирующей" (прям так и называлось, не по-русски, конечно, но именно "оркестровка") среды разработки авиалайнеров нового поколения. И вот там уже как раз 350XWB и доделывали-доводили до ума. Всё равно, в каких САПРах делели шпангоуты, в каких - жгуты, а в каких - стороннюю авионику - всё сводилось на уровне DMU уже в PLM, не в САПРе. Жаль, что наши "умники" из ОАК'а до сих пор упрямо твердят: "все участники одного и того же проекта должны работать в одной и той же версии сами-знаете-какого САПР, чтобы всё срослось. А то будет, как с электрикой на 380-м у французов". То есть, давайте у нас научимся правильно наступать на грабли и по максимуму надвигать кепку на лоб при этом. И не видят в упор, что "французы" просто убрали грабли вообще. И 350 "сделали" быстрее, чем мы тут с ОАКом - многострадальный наш SSJ.

В статье, посвящённой инструментам проектирования XWB, в качестве иллюстрации применяемых функционалов 3DEXPERIENC'а одна из картинок - видимо, из "другой оперы", хотя и Dassault Systemes'шной. http://www.aero-mag.com/_img/p ... - это DMU на шасси, но не А-350XWB, там не такая механика, не такой состав.
На самом деле эта DMU - от другого детища Эрбаса - военно-транспортного А-400М.
http://cdn-www.airliners.net/a ... - картинка "живого" А-400М. Вот там как раз шасси такое. У А-350XWB - шасси и не трёхстоечное, и "прячется" не в такой выступающий пилон.

Оптегрист, так там и носовая часть показана от А-380.

Оптегрист, про всю эту бодягу с нестыковками в А-380 я прекрасно помню. А насчет проектирования RRJ, то тут Вы как раз не правы. Он то как раз и проектировался в двух разных системах - весь планер в NX (Unigraphics), а все остальное в CATIA (системы и пр.). Насколько это было возможно, это всё соединили как и положено в единой PLM-системе (хотя и тут немного намудрили: помимо Team-Center еще использовался и SmartTeam). Но по факту, я Вам скажу, это огромная ...опа. Скажем, летающие в воздухе отдельно от планера заклепки, наверное многие инженеры помнят. Хотя это вовсе не ошибки конкретных NX, CATIA или Team-Center. Но крови и нервов это мультиСАПРие выело немало.

Первый раз слышу, что в ГСС стоял Юниграфикс. Сколько там бывал - на всех компах все проектировали только в Катиа.

ReD_mobile_BARON, к тому времени, когда Вы там стали бывать, планер уже был спректирован (КБ "Сухого"). Большинство работ по правке планера в NX (UG) выполнялись в филиалах (Комсомольск, Новосибирск), поскольку все права переданы были им. В Москве - глобальные переработки, идеи и вся работа по системам.

Скорее всего,всё-таки не совсем так, как пишет Gook. Сколько себя помню, на всех \"сборищах\" по САПР, а потом - по PDM-PLM, всегда говорилось, что планер делался в CATIA, потом, при переходе к РП, подоспела Погояново-Коммстроминская идея, что всё надо делать только в UGS+TeamCenter. Ну, вот, разве только электрика осталась развиваться в CATIA. Ну, и что там к электрике приросло.
Я никакого отношения (тогда) к ГСС не имел, не CATIAщик, но вот, к примеру, беру с полки первое попавшееся Руководство по эксплуатации (ещё на RRJ !!!) и смотрю первый же попавшийся раздел по работе с монтажём встраиваемого оборудования. В нашем случае - какие-то там перегородки-стелажики в районе 10 и в районе 51 шпангоутов. Кто в теме - картинка 3D модели этих конструкций спэдээфлена из CATIA, а то, что картинки - CGM-овские гарантирует то, что они взяты из DMU на секцию.
http://www.4shared.com/downloa ... - в районе 51-го шпангоута
http://www.4shared.com/downloa ... - а это - для 10-го шпангоута.
Авторы этой главы Руководства вообще даже утверждают, что сборка, из которой \"выбирались\" эти картинки, была сделана в CATIA V5 R16, потом пересобиралась в R18, но такие \"тонкости\" уже на картинке не углядеть.

И вот ещё что вспомнилось: Галина Львова в 2011 году дала интервью в CIO, тоже подтверждение, что всё-таки SSJ был спроектирован в CATIA (изначально):
Михаил Зырянов
\\\"Подъем на крыло\\\"

О роли ИТ-команды ГСС в создании нового авиалайнера рассказывает Галина Львова, директор по информатизации компании «Гражданские самолеты Сухого»

Проект создания нового гражданского самолета изначально замысливался как новаторский с точки зрения организации работ. ГСС должна была стать компанией полного цикла — от маркетинга до производства, продаж и сопровождения в эксплуатации. Новаторским проект был и по составу проектной и производственной кооперации. В частности, было решено, что каркас самолета будут разрабатывать российские конструкторы, а все системы самолета, в том числе бортовые, и прочее оборудование — западные. К тому времени в «ОКБ Сухого» и в Комсомольском-на-Амуре авиационном производственном объединении им. Ю. А. Гагарина (КнААПО) был уже накоплен опыт проектирования и производства изделий с использованием PLM-технологий, поэтому было решено самолет RRJ 95 (позднее он стал называться SSJ 100) проектировать в электронном виде. Для этого требовались развитая ИТ-инфраструктура, организация взаимодействия внутри проекта (в том числе с внешними поставщиками) с использованием ИТ. Кроме того, декларировалось, что компания будет открытой (это было необходимо для успешного выхода на зарубежные, в первую очередь западные, рынки). И эту открытость, в том числе в плане ИТ, необходимо было реализовать и продемонстрировать. Все это стало причиной того, что ИТ-департамент в ГСС появился одним из первых. Когда я пришла в ГСС, в ее ИТ-дирекции работало 15 ИТ-специалистов, сейчас — около 70.
В качестве САПР еще до моего прихода в проект была выбрана система 3D-моделирования CATIA компании Dassault Systèmes.
..
Я подключилась к проекту в ноябре 2004 года. К тому времени уже был создан компоновочный макет. По указанию генерального директора холдинга «Сухой» Михаила Погосяна я была направлена в ГСС, чтобы оценить состояние работ по созданию электронного макета изделия. При этом я продолжала работать в «ОКБ Сухого». С точки зрения ИТ осень 2004 года стала переломным моментом в проекте. До этого электронный компоновочный макет разрабатывался без использования PDM-системы. В ЗАО «ГСС» и холдинге «Сухой» долго обсуждался вопрос, какую PDM-систему выбрать, и в конце 2004 года приняли решение взять Teamcenter Engineering компании Siemens PLM Software.
...
Позднее, когда выяснилось, какие системы используют наши партнеры, пришлось развернуть и NX, ... Единое информационное пространство разработки обеспечивается средствами Teamcenter. Первоисточником информации об изделии у нас является 3D-модель. Если необходимо, на ее основе делаются упрощенные чертежи.
= = = = = = = = =

Что же касается "отдельнолетающих" в пространстве заклёпок - то всё просто: примеры классические, я на лекциях всегда привожу примеры, к какой белиберде приводит развёртывание совместных параллельных проектных работ без предварительного развёртывания единой среды PDM ли, PLM ли. Вот если без среды, то конструкторы замучаются выдерживать многочисленные требования и у=словия работы в едином проектном пространстве, когда каждый из них "виртуозит" в своём и ещё поднастроенном только "под себя". Малейшее несогласование - и либо надо всё переделывать , ещё раз точно блюдя все правила и временные соглашения, либо успокоиться и иметь в виду сепаратно летящие "заклёпки".
Вот, к примеру, на том же RRJ, когда делали всё с PDMом, то летящие заклёпки (как тут)
http://www.4shared.com/downloa ...
просто оказывались показанными без визуализированной допю обстановки. Если Обстановку добавляли, то проверялось: соблюли ли все правила совмнестной работы. Если да, то
http://www.4shared.com/downloa ...
заклёпки становились на своё место.
http://www.4shared.com/downloa ...
Следить за этими правилами - ясен пень, должна система PLM, человеку это претит.

Оптегрист, я всё же не буду пытаться убедить Вас в своей версии, ведь "на всех \"сборищах\" по САПР, а потом - по PDM-PLM" всегда знают больше, чем сами работники. Замечу лишь что "какие-то там перегородки-стелажики в районе 10 и в районе 51 шпангоутов" как раз таки входят в группу "системы", а не в планер самолета. Да и, кстати, что мешает отрендерить в том числе и части планера для руководства в той же CATIA (если в Москве почти все работают в ней), мне непонятно.

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

Именно про это я и говорю: не надо работать в сборке в САПР, если число элементов больше 200-300, а количество одновременно работающих конструкторов в сборке - больше трёх. Пусть даже они будут в однотипных САПР одной и той же версии. Для согласованности (в т.ч. и отслеживании корректности приведения к единой системе координат проекта) нужна система "над" САПРами. В народе их называют PDM, а для всех этапов разработки (когда не тошлько САПРы, а и другое ПО привлекается, расчёты там всякие, информационный обмен, работа с поставщиками...) - PLM. Это - азы. А нормальную PDM (ну, со SmarTeam'ом - это я оценил, thanXs) как Вы помните, на проекте привлекли уже после того, как три года им геометрия и силовой набор и членение уже в САПРе(САПРах, если хотите) лежали. Со всеми вытекающими. Вернее, свободнолетающими. Всё пыжились в DMU нормально всё провязать. Народ со всяких там форумов и конференций, который чуть-чуть в проектировании авиатехники понимает, криком хихикал: ну не вяжется проект по авиатехнике только в САПРе, не 80-е годы ХХ века. Кто их слушал? Ясно же, что Михаил Асланович лучше знает, как надо управлять инженерными данными разработки пассажирских самолётов. Кстати, вот картинка у меня над рабочим местом висит лет уж пять-шесть. На всякий случай -
http://www.4shared.com/downloa ...
систем тут мало, всё больше шпангоуты. Я - не САПРовщик, но поинтересовался у тогдашних ГССовцев (их сейчас в ГСС нет), в чём выгоняли, в чьей DMU. Сказали - в CATIA'йной. Врут, поди... :-)

Sorry, забыл как всегда :


http://www.remmag.ru/admin/upl ...

"ЗАО “ГСС” применяет множество модулей решения Dassault Systemes для аэрокосмической отрасли, например для проектирования деталей и узлов, для параметризации по функциям, с целью автоматического перестроения моделей, для резервирования пространства под электропроводку и трубопроводы, для
обеспечения возможности применения уже существующих наработок. "

Оптегрист, и снова не то.
Во-первых, в этом проекте немного по-другому организована совместная работа. Грубо говоря, эта совместная работа средствами Team Centr-а как раз таки воспрещается. В любой момент времени право на изменение детали или сборки существует только у одного человека, со всеми вытекающими отсюда нюансами и ограничениями.
Во-вторых, редактировать детали и сборки можно только в той САПР, в которой они создавались. А вот просто открывать для просмотра, рендеринга для плакатов и руководств можно хоть в Юниграфиксе, хоть в Кате (но, конечно, только через Team Centr).
Все косяки, о которых я говорил возникают, когда открываешь (хоть для редактирования, хоть для просмотра) совместно сборки, созданные в разных САПР - силовой каркас и системы. Происходило это не всегда, но довольно часто. Что-то постепенно исправлялось, что-то нет. Но намучились с этим двоеСАПРием выше крыши.

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

Gook, Вы же абсолютно правы : "в этом проекте немного по-другому организована совместная работа. Грубо говоря, эта совместная работа средствами Team Centr-а как раз таки воспрещается. В любой момент времени право на изменение детали или сборки существует только у одного человека, со всеми вытекающими отсюда нюансами и ограничениями." То есть, вчистую никакой TeamCenter не будет за нас решать наши задачи по проекту. НО важно не это, а то, что в принципе в PLM системах (даже в TeamCentre) есть "зародыши", фрагменты,элементы, заготовки для решения любых задач ведения коллективной проектной работы.Для нашего случая: во всех системах PLM, которые так или иначе пытаются применять в авиастроении, уже прописаны процессы внесения изменений (Engineering Change Management) на процессном (шаблоны Workflow c типовыми ролями), так и на объектном (ECR... ECO...) уровнях. Только применяй. Ну, надо только "прикрутить" практику отечественного производства. То есть, доработать объектный ряд и расширить его: как в терминах Engineering Change Reuest -> Engineering Change Order описать все наши ПР, ДПИ, ПИ, ИИ, бюллетени... И в части уточнения Workflow - доработать шаблоны в соответствии с практикой конструкторско-технологической проработки изменений и постановки на производство. Тут вот надо бы не просто понакупать ПО, а вначале проработать архитектуру решения и получить доступ к API для доработки софта по месту. Вот тогда любая "немного по-другому" организованная работа на любом проекте будет доступна для автоматизации в смысле PLM. Как жаль, что наши "идеологи" Коммстромины так и не допёрли до такой простой мысли (до которой дорасли даже китайцы на AVIC'е), что PLM - это не пакет, а решение. Очень гибкое, когда с ним хотят работать по-честному. И просто жопа, если думают, что разработчики PLM "знают" как делать самолёты (вариантЖ автомобили. или турбины. и т.д.)

Gook, Вы почти правы и далее: "редактировать детали и сборки можно только в той САПР, в которой они создавались. А вот просто открывать для просмотра, рендеринга для плакатов и руководств можно хоть в Юниграфиксе, хоть в Кате (но, конечно, только через Team Centr)." -!!! Ура!!! Как надо бы вляпать этот тезис ОАКовским идиотам, которые идут дальше и утверждают, что раз самые большие сборки делаются в САПР такой-то, то и все детали, агрегаты и узлы в этом проекте надо также делать в той же единой САПР. И не колышет их, убогих, что давным-давно никто ни на Арбюзе, ни на Боинге (даже ни на Эмбраере с Бомбардьёй вкупе) не требует, чтобы Tier I поставщики (тот же Либбхер или Талес или Хамильтон-Санстранд, Райтеон) или Снекмы-Роллс-Ройсы-ПраттЭндУитни всякие выстаивались чётко под базовую САПР ОЕМа. Решают там несколько по-другому. Предоставлением доступа в проект через проектную среду (ну, PLMоподобное что-то, как правило, "заточенное" под особенности ОЕМа) ОЕМа и на время проекта. Тот же NeamCenter? как Вы пишете. И я - тоже про это. Работает каждый вв том, в чём ему "сподручнее", а "сшивать" всё в единое информационное пространство - уже через такую вот среду. (Единственная поправка Вашего второго тезиса) рендеринг или там фотореализм какой - давно уже не требует САПРов, в любой PLM есть высокоуровневая 3D-визуализация средствами самой PLM, без САПР. И не надо там САПРовских мощностей, достаточно просто иметь cjr'ы вместо CATPart/CATProduct'ов, jt вместо prt... Сразу объём сборок сократится на два-три порядка (мегабайт вместо гигабайтов), можно использовать WEB-просмотровщик с любого места вместо только САПРовского, вставлять аннотации, открывать сеансы он-лайн конференций c 3D-контентом и т.д. И кроме прочего - разнотипные модели, из разных САПР, можно "замесить" в такой технологии для просмотра в простеньком визуалайзере в PLM. Так работают, и работают давно, все уважающие себя "Эрбуинги". Так что мы с Вами тут не спорим никак. Просто для использования всего этого "изюма" PLM нужно сначала чуть-чуть головой подумать, не ОАКом, и потом тщательно и внимательно "затачивать" PLMу под себя, под своё уникальное пространство процессов с уникальным составом соисполнителей и ПО у соисполнителей по каждому проекту.

И конечно же вот такой тезис - просто бальзам на растерзанную душу: " Вам нигде не напишут, и ни на одной САПРовской конференции не расскажут чего стоят такие нюансы для простых инженеров." - Ну, не совсем так, да, на конференции или уж точно - в пресс-релизе - не скажут. Ну, разве в кулуарах, а в пресс-релизах и кулуаров-то нет. А вот практика внедрения, сервисная поддержка, предпроектная проработка архитектуры PLM-решения - вот это то место, где надо и надо обязательно попытаться предусмотреть все те "нюансы", об которые спотыкается любое внедрение таких сверхсложных систем корпоративного уровня, как PLM. Всего всё равно не предусмотришь, но "спасение ЗДЬ-внедряющего - дело рук самого PLM-внедряющего". А вот о том, как всё-таки выстроить взаимодействие по внедрению PLM между поставщиком PLM и пользователем-заказчиком - вот об этом уже давно, года три как, говорят на (по крайней мере - в России, в Москве, в СПб) PLM конференциях и форумах. Давно уже никто не хвастает фичами и фанкшенами, а козыряют выполненными проектами. Не секрет, что давно уже и у SIEMENS'а, и у PTC'а и даже у Dassault'а на "русских" PLM-форумах на отраслевых секциях выступают не вендоры, а наоборот, именно заказчики. Да, без особых подробностей, но именно с описанием того, как удалось (если кому удалось) эти самые фанкшенз-энд-фичерз "заточить" под свой ландшафт процессов разработки, как удалось (если удалось) припрячь сюда же сторонних соисполнителей и т.д. Так что и конференции - тоже иногда приносят пользу. Опять же : отследить тренд там или моду какую. С коллегами по несчастью минералочки попить. :-)

О споре, в чём моделировали RRJ/SSJ. Планер, действительно проектировали в Unigraphics NX с участием Комсомольска, Новосибирска и Таганрога, где тогда работали только в UG. И вели планер в Москве спецы, пришедшие из ОКБ Сухого, где тоже знали только UG. Работал в этом деле в 2006-2007 г.г.

arkair, осторожно, тебя сейчас рекламными буклетами закидают. :)

Творчество компьютером не заменишь. САПР, кстати, преподавался 25 лет назад. От систем автоматизированного проектирования ожидались чудеса. Что компьютеры/программы будут сами проектировать самолеты, дома, автомобили итд. Взять например Камри или Крузак. Базовые модели были созданы пол века назад. Да, появилось электронное зажигание, навигаторы, электрические зеркала и сиденья. Но по существу, это та же Камри или Крузак что и 50 лет назад. Не оправдали себя эти САПР.

(-- > VNVinogradskiy )
Именно: ожидалось, что автоматически методики ведения крупных проектов от Боинга или Эрбаса будут перенесены на родную почву, если только мы тут понапокупаем тех же САПРов и таких же компьютеров. А оказалось, что ведение проекта - это, как Вы выразились - "творчество", а САПРы-компьютеры всякие - это только инструмент. Замена молотка отбойным молотком не решает проблемы эффективного забивания гвоздей.
И ещё. САПР - никогда не считались единой информационной средой для организации проектирования-анализа-планирования-изготовления-сопровождения, для этого САПРа мало. Нужен PDM, а если шире - PLM. Ну, с подхватом в ERP всяких и проч.
А на палочку-выручалочку в виде САПР, а ещё хуже - одного конкретного САПР, даже у нас в Удмуртятии давно никто не верит. XXI век на дворе. С Новым Годом!

;) Лет двадцать пять назад, когда компьютеры вызывали благоговейный трепет и был слоган "Всемирная библиотека" на одной дискете, считалось, что еще пару лет, и компьютеры сами начнут писАть рассказы на уровне Толстого. Даже короткой заметки не видел в итоге, написанной искусственным разумом. Вторая идея была телеведущих сделать электронными. Ну итд. Самолетом, разработанным с использованием цифровых технологий (с большой долей использования, скажем так) и САПР является B2-Spirit. Изделие конечно уникальное. Сколько он стОит в итоге, все знают.

Оптегрист
1. "Немцы" и "Франзузы" использовали различные версии одного и того же САПРа.
-------
При разработке А380 Airbus GE использовал CATIA V4, a Airbus UK и Airbus France работали в CADDS5 в основном в explicit-mode http://www.ptc.com/product/cadds-5 с использованием для спецификации старинной GILDA с интерфейсом на черно-зеленных мониторах и OPTEGRA. А380F все еще был CADDS5 но уже с использованием Windchill. Детали сделанные в CADDS5 в parametric mode были очень «тяжелые», что иногда их делали в CATIA V4 и переводили в CADDS5 как эксплиситные модели.

Хотел бы добавить, что сила заблуждения в настоящее время просто фантастическая - финансы решают все: главное выделить 10 миллиардов зелени ну, и как частное, поставить САПР. Если бы было так просто, новейшие типы самолетов были и у Китая и у Индии и у Вьетнама. Даже последний, 10 миллиардов найдет и САПР поставит, не говоря уж о Китае. Было бы все так просто.