Концептуальное Проектирование 2

[DmitryV 0]

Очень жаль, предыдущая тема была закрвта. ( Концептуальное Проектирование. Дизайн)

Но ведь тема действительно важная. Опыта ведь нет ни у кого.

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

Нет ведь ни литиратуры ни других пособий. Динозавры повымерли, а молодым похоже на все наплевать.

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

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

[Ruslan 266]

предыдущая тема была закрвта

Предыдущая тема была закрыта по причине превращения во флейм.

И эту тему, к сожалению, ждет таже участь.

Для начала нужно определится, что обсуждать, на базе какого изделия.

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

[DmitryV 0]

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

Предыдущая тема была закрыта по причине превращения во флейм.

И эту тему, к сожалению, ждет таже участь.

Может постараться тогда в рамках Pro/E.

[GOLF_stream 292]

В принцыпе, свою позицию по обсуждению подобных тем я уже высказал. Но могу повторить ещё раз:

Концепция - она всегда прежде всего в голове конструктора (главного, генерального, гениального). И именно там - в своей голове он её прорабатывает. Какими средствами её воплощать и доносить до других, контролируя их работу, - это другой вопрос. Это можно делать на бумажке, можно писать служебные записки, можно что-то строить в компьютере, заносить в него какие-то числа. Это уже называется не Концепция, а МЕТОДОЛОГИЯ проектирования.

Так вот, Методология ИНДИВИДУАЛЬНА ДЛЯ КАЖДОЙ ЗАДАЧИ. Мало того, она индивидуальна для КАЖДОГО ИЗДЕЛИЯ, если эти изделия не однотипны.

Для простого изделия, типа корпуса телефона, это одно - я вкратце её описАл. Для самолёта - это СОВСЕМ другое. Мало того. Говорить о Методологии проектирования самолёта в рамках данного форума БЕССМЫСЛЕННО. Во-первых, как я уже говорил, для каждого самолёта это будет индивидуально. Во-вторых, кроме общих слов ты ничего не узнаешь, ибо конкретики на этом сайте быть не может - чтобы была конкретика, надо ТЩАТЕЛЬНО РАЗОБРАТЬСЯ в каждом конкретном проекте. Думаю, что никто здесь этим заниматься не будет. Вернее, этим может кто-нибудь заняться, но за большие деньги, потому что на выработку методики нужно потратить ОЧЕНЬ много времени и обладать достаточными знаниями и навыками.

И акцентирую внимание ещё раз:

Говорить о Методологии проектирования самолёта в рамках данного форума БЕССМЫСЛЕННО. Во-первых, как я уже говорил, для каждого самолёта это будет индивидуально. Во-вторых, кроме общих слов ты ничего не узнаешь, ибо конкретики на этом сайте быть не может - чтобы была, конкретика надо ТЩАТЕЛЬНО РАЗОБРАТЬСЯ в каждом конкретном проекте. Думаю, что никто здесь этим заниматься не будет. Вернее, этим может кто-нибудь заняться, но за большие деньги, потому что на выработку методики нужно потратить ОЧЕНЬ много времени и обладать достаточными знаниями и навыками.

И ещё раз:

чтобы была конкретика, надо ТЩАТЕЛЬНО РАЗОБРАТЬСЯ в каждом конкретном проекте.

Что касается общих рассуждений, то я вижу два пути развития темы:

1 она перейдёт во флейм, как и предыдущая. Это уже было, это не интересно.

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

[shurshik 14]

Держать всё в голове это конечно хорошо, если она одна и не дырявая

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

[DmitryV 0]

На мой взгляд, все гораздо прозрачнее. Дело не в больших сборках.

Пока что все рассуждения напоминают обсуждения у нас на предприятии проектного способа управления. Пначалу только и разговоров было, что каждый проект индивидуален и все делается поразному. Потои выяснилось, что все проекты в рамках одного предприятия делаются по одним и тем же правилам и планам. Более того существует стандарт на проектирование радиоаппаратуры, в котором прописана вся последовательность. Другими словами на любои предприятии радиаппаратура должна проектироваться единообразно. Но еще раз повторяю стандарт о котором я говорю описывает принципы ведения проекта и все. Выпуск РКД в нем записан одной строкой. Т.е. как хочешь так и делай. У нас на разработку издели обычно выделяется 1-2 конструктора, каждый из которых варится в собственном соку. Совершенно не учитывается работа расчетчиков (ни тепловиков ни прочнистов). Точнее сказать учитывается по остаточному принципу. Если конструктору вдруг в голову ударит, что надо что-то посчитать, он может и передаст свою работу на рачет. Я уж не говорю об оптимизации самой конструкции. Хорошо если это наземка...

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

[aav1 0]

"Очень жаль, предыдущая тема была закрыта. ( Концептуальное Проектирование. Дизайн)

Но ведь тема действительно важная. "

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

"Контролировать работу каждого конструктора необходимо еще в самом начале. И скорее всего не на бумажке-промакашке. В ТЗ ведь все написано (если конечно все) но прочитать можно по-разному."

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

Поэтому мне кажется логично переименовать тему (вспомним Кунфуцзи с его "исправлением имён") и всё встанет на свои места.

И далее хочется сказать что проблему контроля лучше решать административными методами ( подбор кадров, стимулирование, взаимопроверки и пр. пр. пр.) а не при помощи CAD систем.

[DmitryV 0]

проблему контроля лучше решать административными методами ( подбор кадров, стимулирование, взаимопроверки и пр. пр. пр.) а не при помощи CAD систем.

Административными методами контролировать бесполезно. Должна работать система. Не административная естественно.

А тему можно и переименовать сути это не меняет, посколькуконтроль нужен именно с самого начала, с идеи или концепции.

[GOLF_stream 292]

читайте классиков: "Разруха - она прежде всего в головах."

ЛЮБАЯ компьютерная система оперирует только байтами, содержащимися в файлах, которые доступны этой системе. Содержимое голов никакой системе недоступно. Поэтому никакая система не может контролировать то, чего хочется - раздолбайство, пофигизм, некомпетентность и банальный идиотизм.

Вспомните Чернобыль - там была предусмотрена "система защиты от дурака". И она сработала в критической ситуации. Но там не было предусмотрено "системы защиты от идиота", который просто-напросто повернул рубильник.

И ещё про "умные системы". Подобные системы существуют. И даже кое-где работают. Но у них есть один существенный "недостаток" - они изначально подразумевают, что с ними будут работать грамотные, умные и ОБУЧЕННЫЕ люди. Объединение этих трёх качеств в одном человеке очень редко в наших постсоветских условиях.

Поэтому наиболее эффективными методами котроля в наших условиях по-прежнему остаются административно-дисциплинарные.

[DmitryV 0]

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

Во флейме вроде замечен не был.

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

Почти все темы обсуждаются между чаем и бутербродом.

ЛЮБАЯ компьютерная система оперирует только байтами, содержащимися в файлах, которые доступны этой системе. Содержимое голов никакой системе недоступно. Поэтому никакая система не может контролировать то, чего хочется - раздолбайство, пофигизм, некомпетентность и банальный идиотизм.

Я говорю не о компьютерной системе., а о системе взаимоотношений. О правилах, гласных или негласных. В конце концов, если под административными методами понимать набор СТП, то о них.

И ещё про "умные системы". Подобные системы существуют. И даже кое-где работают. Но у них есть один существенный "недостаток" - они изначально подразумевают, что с ними будут работать грамотные, умные и ОБУЧЕННЫЕ люди. Объединение этих трёх качеств в одном человеке очень редко в наших постсоветских условиях.

Я почему-то еще расчитываю на то, что здесь все еще можно пообщаться с грамотными, умными и ОБУЧЕННЫМИ людьми пускай и не в одном лице.

[SAS_17 10]

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

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

[Norsk 0]

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

Может постараться тогда в рамках Pro/E.

Интересно а кто-нибудь видел в глаза книги

по сабжу (наши или зарубежные) где бы на НЕСКОЛЬКИХ (пусть даже учебных)

примерах разных конечных изделий рассматривался бы одинаковый подход проектирования,

прослеживались бы одинаковые принципы в этом?

[aav1 0]

Во флейме вроде замечен не был

Уважаемый DmitryV прошу меня извинить если я не совсем точно высказался.

(как видно из предыдущего флейма)

-имелась ввиду только ссылка на тему, но никак не на личности. Конечно Вас никто не упрекает во флейме. Ещё раз извините.

[sloter 546]

Доброе время суток!

Разрешите вклиниться в обсуждение. В прошлую тему не успел - она закрылась. А тема действительно интересует многих и не только работающих в ПроЕ. Проще было бы её искать в корне "Обсуждение CAD/CAM систем". По поводу терминологии. Может конечно формально это не так, но при рассмотрении универсальных CAD систем действительно не стоит рассматривать "Концептульное проектирование" в предметной плосткости. Разные типы изделий имеют свои исторические методики проектирования. В этом я полностью согласен с GOLF_stream. Здесь же речь может идти о методах и технологиях проектирования "сверху-вниз" в САПР и механизмах обеспечения ассоциативной связи исходных данных и первичной эскизной информации с реальной сборкой изделия. А так же возможность гибко влиять на реальную сборку с помощью "Эскизной проработки". Хотел бы поделиться своими соображениями на этот счёт и попробовать обобщить и классифицировать методы, применяемые в разных CAD. Далеко не претендую на истину во всех соображениях и с удовольствием выслушаю конструктивные коментарии и поправки, так как нужно это прежде всего мне.

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

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

2. Проектирование "сверху-вниз" ведётся группой исполнителей.

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

Для первой группы наиболее быстрым и удобным методом нисходящего проектирования, на мой взгляд, является следующий. Создаётся файл изделия, и в нём напрямую создаётся и увязывается сначала эскизная геометрия, параметризация, затем тела, с таким расчётом, что тела - это будущие детали. Вначале всё сохраняется в этом общем файле. По мере "устаканивания" каких либо частей проекта эти тела сохраняются в детали, детали группируются в узлы. Разузловывать на первоначальном этапе нет необходимости. Это ведь в "инновационных" изделиях на начальном этапе сделать очень сложно, иногда вообще не возможно. Полная "структурная свобода". Конечно, на каком то этапе проработки можно сохранить тела в детали и узлы и отдать на доработку другим исполнителям. Тогда этот метод уже переходит в группу 2, но это на более позднем этапе. Насколько я знаю, такой метод поддерживается в UG (но не уверен, так как реально с ним не работал) и в TF (почти уверен). Может ещё в каких - кто знает - дополните. Пародия на этот метод есть в SW, но там многотельная деталь, распускаемая в ассоциативную сборку. А это другой файл, куда детали приходят без своей истории, история остаётся в многотельной детали (в другом файле). Это вызывает необходимость их совместного использования и ряд других неудобств.

Другим методом в 1 группе можно было бы назвать создание деталей в сборке по месту в контексте других деталей, но такой метод вряд ли можно назвать "сверху-вниз" ибо он ведётся последовательно и со связями "родитель-потомок", что затрудняет или делает невозможным глобальное управление сборкой. Этим методом обладают все современные CAD.

Ещё один метод - это проектирование на контекстах "Компоновочного эскиза" сборки. Его же можно отнести и к 2 группе. Знаю точно, что SW, SE поддерживают его, да и наверное некоторые другие то же. Кто в курсе - дополните. Инвентор этот метод не поддерживает. На мой взгляд этот метод не обладает достаточной гибкостью. Всю вновь появляющуюся эскизную геометрию нужно в ручную не забывать заимствовать. Возрастает количество действий и дополнительный "человеческий фактор".

Для второй группы основными методами являются "Скелетон" и "Метод мастер-модели". Кстати сразу вопрос к знатокам. Чем они отличаются? Или это одно и то же? Хотя бы на примере ПроЕ. Как я это понимаю:

"Скелетон" - это когда создаётся "Скелетный Part" - деталь, где на низком уровне (эскизы, поверхности) создаётся структура изделия, параметризуется и увязывается. Затем этот "Скелетный Part" вставляется первым в файл изделия и с него в контексте сборки копируется геометрия во вновь создаваемые файлы реальных деталей и узлов. Ассоциативность сохраняется только при нахождении "Скелетный Part" в сборке. Он там должен остаться навсегда. При удалении его ассоциативность теряется. Такой способ поддерживает UG, ProE, CATIA, SE, может ещё какие.

"Метод мастер-модели" начальным этапом ни чем не отличается от "Скелетон", но копирование геометрии осуществляется не в контексте сборки, а независимой вставкой её непосредственно во вновь созданный файл детали (узла). То есть сборку для копирования геометрии в детали создавать необязательно, и "Скелетный Part" не обязан присутствовать в файле изделия. Такой способ поддерживает UG, ProE, CATIA, Инвентор, SE, SW, помойму в TF и даже Компас. Точно знаю, что в SE, SW есть ограничение в виде невозможности копировать таким образом эскизы, хотя в SW2008 вроде это устранено. Есть ли такое ограничение в TF и Компас не знаю. В Инвентор точно нет.

Ясно, что в методах 1 группы нет необходимости в механизме контроля стыковок и увязок деталей, так как всё делается одним исполнителем (ведущим) и он контролирует сам себя стандартными средствами CAD. При проектировании группой метод контроля представляется мне вобщем то таким же. Можно в любом случае вставить в сборку изделия исходный "Скелетный Part" и контролировать наполняющийся контент сборки по нему. А так же использовать стандартные средства контроля CAD такие как проверка пересечений, зазоров и т.д. Всё это делается "ведущим" который и имеет права доступа к главной сборке.

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

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

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