Странник

Изменения в подсборках.

126 posts in this topic

Важно что бы у софта крыша не ехала при этом.

Софт - это "автомобиль", а ГОСТы - это "знаки дорожного движения". Автомобиль САМ по дороге не едет. Едет крыша.

Share this post


Link to post
Share on other sites


ID: 42   Posted (edited)

..............Ни дать, ни взять – стратегическая ловушка.

Вопрос: какой есть опыт борьбы с этим «весёлым» эффектом?

А Вы думаете при бумажном документообороте было как-то иначе???

Внедрение PDM должно лишь:

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

- обеспечить ускорение процессов согласования (меньше бегать ногами по кабинетам).

и еще кое-что другое.

Edited by DGroot

Share this post


Link to post
Share on other sites

А Вы думаете при бумажном документообороте было как-то иначе???

Да не думаю, а прошёл всё это на личном опыте, при чём не единожды.

На теперешнем инженерном софте такие фокусы, в коих лично принимал не единожды участие, не пройдут.

Share this post


Link to post
Share on other sites

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

Другой разговор, проверяет ли нормоконтроль степень ответственности, автора извещения.

Share this post


Link to post
Share on other sites

А визы разработчика следующего верхнего уровня вхождений ужели не достаточно?

Share this post


Link to post
Share on other sites

Пока бюро А готовит свои изменения (см. выше), в бюро Б возникла потребность проводить изменения в узле АБВ.3445.100.050. То, что описывалось ранее имеет место быть и здесь. Т.е. конструктор бюро Б меняет АБВ.3445.100.050, обновляет АБВ.3445.100.000... пока всё штатно, но только до тех пор пока эти изменения не встретятся в одном изделии АБВ.3445.000.000.

Так вот, если использовать одну единственную версию, то в случае возникновения коллизий в АБВ.3445.000.000 причин не найдешь! А если, несколько версий, то получается:

а) ГЛАВНАЯ версия изделия АБВ.3445.000.000

б) версия изделия АБВ.3445.000.000 с изменением от бюро А

в) версия изделия АБВ.3445.000.000 с изменением от бюро Б

и гл. конструктор может сделать для себя

г) версия изделия АБВ.3445.000.000 с обеими изменениями

чтобы проанализировать как повлияют эти изменения друг на друга (если будут приняты).

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

ИТОГО: на стадии конструкторской разработки (конструкторской подготовки изменения) не обойтись без многоверсионности.

Прошу извинений за чайниковский вопрос, но каким образом эта ситуация решается в "бумажных" технологиях?

Share this post


Link to post
Share on other sites

Во-первых не рекомендую использовать такое обозначение:

АБВ.3445.000.000

без указания на стандарт, по которому оно сформировано.

Во-вторых, у АБВ.3445.000.000 есть автор и если этот автор я то никакое бюро А, Б, В, Г ..... изменения не внесут без моего "горячего" участия. Так что в электронной и бумажной технологиях я положу главному конструктору всего 1 вариант, который я подпишу и буду отвечать за него.

Ну а если автор кто-то другой, то это уже его проблемы.

Share this post


Link to post
Share on other sites

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

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

:wallbash: :wallbash: :wallbash:

Share this post


Link to post
Share on other sites

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

А это потому, что КД утверждать не приходится, по видиму.

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

Share this post


Link to post
Share on other sites

ID: 50   Posted (edited)

А это потому, что КД утверждать не приходится, по видиму.

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

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

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

а так же что значат понятия контрольной суммы и непринципиального изменения.

ну, с этим вроде понятнее..

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

Очевидно, что с внесением, хотя косметической правки, в какую ни будь деталь АБВГД.04.01.013 по законам CAD должны будут перестроиться и все сборки, в которые эта деталь входит, включая и АБВГД.00.00.000. Каждый из этих документов нужно будет снова сохранить в PDM, с изменение контрольной суммы и появлением новой итерации. То есть потребуется ещё раз пройти круг согласований, по каждому изменившемуся документу.

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

С точки зрения WORKFLOW это будет не слабый «ротор» ибо количество таких процедур на каждом более высоком уровне сборочных единиц будет расти едва не в геометрической прогрессии. Ни дать, ни взять – стратегическая ловушка.

Если всё делать по правилам, то это и сейчас неслабый «ротор». Или электронный документооборот добавляет в этот ротор свои "вихри"? Edited by AnTe

Share this post


Link to post
Share on other sites

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

"Мягкая" это когда на непринципиальных изменениях подпись останется невредимой.

Например: по многочисленным просьбам завода некий радиус скругления в детали АБВГ.07.04.005 сменили с 0,3 на 0,5*. С точки зрения покрытия, термообработки, материала-заменителя, маркировок, прочности, даже массы в штампе чертежа изменение совершенно непринципиальное, но технологам оно надо, а конструктора не возражают. На бумаге по всем инстанциям пройдёт извещение с переправкой R0,3 на R0,5*, но даже "разраб.", "провер.", "т.контр.", "гл.мет.", "н.контр.", "утв." да и всякие на полях визирующие обновлять своих подписей не будут. Тем более на уровне сборок, особенно общих. Сделали указание о внедрении и задели и производство счастливо.

Теперь смотрим тож самое изменение при электронной технологии...

Модель параметризована полностью, радиус правим с 0,3 на 0,5 очень легко, чертёж обновляется тоже, но тут же появляется новая итерация этой детали и чертежа на неё, а вместе с ними сборок первого, второго и последующих уровней вхождения, вплоть до АБВГ.00.00.000, вместе с ними и чертежи, и всё это надо будет заново утверждать. Потом передавать в производство и заново же гнать ТД...

Вот это и называется "ротор".

Share this post


Link to post
Share on other sites

"Мягкая" это когда на непринципиальных изменениях подпись останется невредимой.

Например: по многочисленным просьбам завода некий радиус скругления в детали АБВГ.07.04.005 сменили с 0,3 на 0,5*. С точки зрения покрытия, термообработки, материала-заменителя, маркировок, прочности, даже массы в штампе чертежа изменение совершенно непринципиальное, но технологам оно надо, а конструктора не возражают. На бумаге по всем инстанциям пройдёт извещение с переправкой R0,3 на R0,5*, но даже "разраб.", "провер.", "т.контр.", "гл.мет.", "н.контр.", "утв." да и всякие на полях визирующие обновлять своих подписей не будут. Тем более на уровне сборок, особенно общих. Сделали указание о внедрении и задели и производство счастливо.

т.о. если при электронном документообороте ввести понятие вроде "изменение, не касающееся..", и отметить тех, кто "не возражает", (за подписями тех, кто за это изменение ответственен?), то проблема решится?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Так, правильно я сформулировал? Честно говоря, запарился я уже по выдуманным АБВГ.0000.... строить деревья, и разбираться, что же имелось в виду. :sad::wallbash:

Share this post


Link to post
Share on other sites

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

т.е. эти "непринципиальные" изменения, на самом деле, подписываются и при бумажном документообороте? Хоть и подписи ставятся только на извещении?

Share this post


Link to post
Share on other sites

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

например, ТОЛЬКО разработчик ИИ?

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

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

Олег, поясните, пожалуйста, если не сложно, в двух словах, как в данном случае будет проходить процесс согласования изменения-выпуска_новой_версии?

ps не могу найти, как удалить предыдущих два своих сообщения. глупости какие-то понаписал:), а грохнуть их не могу:(

Share this post


Link to post
Share on other sites

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

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

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

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

И куда же они денутся?

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

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

Нужны какие то специальные решения на уровне функционала PDM систем, ИМХО.

Share this post


Link to post
Share on other sites

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

Все свалили в кучу - уже здесь на форуме запутались.

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

А теперь смотрим внимательно:

Разработчик детали выпустил ИИ, которое сам же и подписал. Всё.

Разработчик НОВОЙ гайки просто выпустил чертеж новой гайки и поставил ее на учет. Его работа закончена.

Далее разработчик "крохотной" сборки выпускает извещение "старую гайку удалить - новую гайку поставить" "внедрить с 26 комплекта" "версия 1.07 или "исполнение -05".

И вот тут 2 пути:

- первый - версия - все изменения организационные - поменяли версию и все - до ИИ были версии 1.06 после ИИ версии 1.07. (т.е. продолжаем выпускать тоже изделие, просто с другой версией). - все это отражается в извещении и, соответственно, в PDM.

- второй - исполнение - всё до самого верха должно получить исполнение - изделие имело 4 исполнения - после ИИ 5 исполнений - в извещении это все и прописываем и имеем еще одно изделие с еще одним набором сборок. (теперь можем выпускать и "старое" изделие и "новое")

Вроде все просто.

Да, забыл дописать: "извещения все - даже самые "незначительные" подписывает Гл.констр., Гл.технолог, Нач.ПДО, и кто еще Вам нужен" Это кроме автора и проверявшего.

Share this post


Link to post
Share on other sites

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

Хорошо они поступают или плохо - это обсудим позже.

Share this post


Link to post
Share on other sites

Кстати, придумайте хотя бы 3 причины по которой в ГСС уничтожают параметризацию моделей перед установкой их в ЭЦМ изделия

А что такое ГСС?

Share this post


Link to post
Share on other sites

А что такое ГСС?

Гражданские Самолёты Сухого.

Предприятие как бы считается лидером по автоматизации в России.

Рисуют они в катьке, а PLM у них юниграфиковская.

Share this post


Link to post
Share on other sites

Понятно.

Это меня, конечно, волнует, но не тревожит.

Share this post


Link to post
Share on other sites

Это меня, конечно, волнует, но не тревожит.

У нас без параметрического ЭЦМ изделия не обойтись, а цикл отработки предвидится лет на 5...7.

В общем проблема острейшая, просматривается.

Share this post


Link to post
Share on other sites

Да, забыл дописать: "извещения все - даже самые "незначительные" подписывает Гл.констр., Гл.технолог, Нач.ПДО, и кто еще Вам нужен" Это кроме автора и проверявшего.

то есть, это при бумажном документообороте?! т.о. при электронном кол-во подписей принципиально не изменяется?!

А в чём состоит проблема, означенная в первом посте треда, Странником?

Share this post


Link to post
Share on other sites

то есть, это при бумажном документообороте?! т.о. при электронном кол-во подписей принципиально не изменяется?!

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

Share this post


Link to post
Share on other sites

А в чём состоит проблема, означенная в первом посте треда, Странником?

Проектирование частного должно вестись как часть целого, то есть неизбежно появляется модель общего вида - ЭЦМ, полная модель, до шайбочки, до проводка. Без PDM сие вообще невозможно.

С другой стороны элементы нижнего уровня по тем или иным причинам изменяются, в среднем где то один или два в год, а элементов этих тысячи. ЕМНИП, как то прикидывалось количество изменений в день и получалось, что "живой" (то есть полностью параметризованный и поддерживаемый в актуальном состоянии ЭЦМ изделия) будет получать в среднем порядка 4 или даже более обновлений в день. Ситуация достаточно критична сама по себе уже потому, что проектно-конструкторские организации обыкновенно работают в одну смену, но это пол беды. Страшнее то, что всем нужны не просто модели, но согласованная и утверждённая КД, а расставленные в результате работы Workflow галочки за "т.контр.", "гл.мет" и т.д. по определению теряют актуальность при появлении каждой новой итерации модели (следовательно и построеных с неё чертежей, ассоциативно).

Очевидно, что с внесением, хотя косметической правки, в какую ни будь деталь АБВГД.04.01.013 по законам CAD должны будут перестроиться и все сборки, в которые эта деталь входит, включая и АБВГД.00.00.000. Каждый из этих документов нужно будет снова сохранить в PDM, с изменение контрольной суммы и появлением новой итерации. То есть потребуется ещё раз пройти круг согласований, по каждому изменившемуся документу.

Смотрите, как пример, что тянет за собою изменение одного компонента самого ниженго уровня:

АБВГ.04.01.013 - АБВГ.04.01.020 - АБВГ.04.010.100 - АБВГ.04.01.000 - АБВГ.04.00.000 - АБВГ.00.00.000.

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

:wallbash::throw:

Share this post


Link to post
Share on other sites

ID: 67   Posted (edited)

Проектирование частного должно вестись как часть целого, то есть неизбежно появляется модель общего вида - ЭЦМ, полная модель, до шайбочки, до проводка. Без PDM сие вообще невозможно.

Почему же? А что такое КД, как не полная модель, пусть и "бумажная", до шайбочки, до проводка? Или в чём здесь принципиальная разница?

Страшнее то, что всем нужны не просто модели, но согласованная и утверждённая КД, а расставленные в результате работы Workflow галочки за "т.контр.", "гл.мет" и т.д. по определению теряют актуальность при появлении каждой новой итерации модели (следовательно и построеных с неё чертежей, ассоциативно).

А без внедрения PDM разве было по-другому?

Смотрите, как пример, что тянет за собою изменение одного компонента самого ниженго уровня:

АБВГ.04.01.013 - АБВГ.04.01.020 - АБВГ.04.010.100 - АБВГ.04.01.000 - АБВГ.04.00.000 - АБВГ.00.00.000.

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

Я понял, что при использовании PDM придётся заново утвердить все сборки, начиная от колеса, моста, и заканчивая нулевой сборкой. Так как изменится сигнатура каждой сборки.

А при бумажном документообороте? Разработчик колеса выпустил ИИ, которое затем подписывают те же участники, которые будут тыкать на кнопы в PDM системе?

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

Вот он и выигрыш - быть нажимателем кнопки проще, чем подписывателем листочка?

при чём без всякой возможности вникать в технику дела. При этом даже не важно влияет изменение той самой АБВГ.04.01.013 на функционирование хотя бы АБВГ.04.01.020, просто появилась новая итерация и вперёд по "заячьему кругу".

:wallbash::throw:

Может, можно сформулировать вопрос так: каким образом "вникают в технику дела" при бумажной документации? Какими правилами, ГОСТами это регулируется? Кто и как определяет, "влияет" ли замена гайки на сборку выше, нулевую сборку? И, в конце концов, почему это невозможно с PDM?

:sad:

Edited by AnTe

Share this post


Link to post
Share on other sites

Возвращаясь к оригинальной теме: все описанные проблемы были объяснены и решены в Toyota, и это было описано в книге Toyota Way (принцип Toyota Lean Manufacturing). Я лично смог участвовать в подобной имплементации. Софт: SMARTEAM, CATIA. Порядка 600+ инжинеров. Делают самолеты.

1) Итак, они решили сделать в основе всего т.н. стандартные части (Standard Parts). Чем ниже по иерархии находится часть (и чем чаще она используется), тем меньше вероятность ее изменения. Т.е. те кто сверху по иерархии, должны брать то что дают.

2) Производственники (Manufacturing) участвуют в дизайне с самого начала, и они имеют возможность влиять на все до того, как был сделан Release. После того как был сделан Release, вероятность изменения крайне мала, я бы сказал, что такая ситуация (изменения after Release) негативно отразится на тех кто привел к подобной ситуации.

3) Во всем этом процессе очень большую роль играет разграничение полномочий. Люди, занимающиеся "старшими" асс, не имеют возмойность менять низлежащие, в особенности Standard Parts.

В общем, по результату имплементации, компания съекономила $250М за 2 года, а всего планируют сохранить 1 миллиард за 5-7 лет.

Счастье возможно!

Share this post


Link to post
Share on other sites

А что такое КД, как не полная модель, пусть и "бумажная", до шайбочки, до проводка? Или в чём здесь принципиальная разница?

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

То есть ЭЦМ эта по сути таж самая конструкторская прорисовка, только на качественно более высоком уровне. Больше того, есть методики позволяющие буквально "лепить" изделие прямо в CAD, то есть формировать его облик, привязывать покупные и стандартные компоненты, оптимизировать, находить альтернативу, в общем делать всё то, что называется словом ПРОЕКТИРОВАНИЕ.

С этой же точнейшей прорисовки делаются и чертежи, и электронная стуктура изделия, и ещё много чего.

Это надеюсь понятно?

А при бумажном документообороте? Разработчик колеса выпустил ИИ, которое затем подписывают те же участники, которые будут тыкать на кнопы в PDM системе?

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

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

Вот он и выигрыш - быть нажимателем кнопки проще, чем подписывателем листочка?

Проще то проще, только не в сотни раз, а количество потребных согласований возрастёт в тысячи раз.

То есть не автоматизация в итоге получается, но диверсия.

И, в конце концов, почему это невозможно с PDM?

А кто сказал, что невозможно?

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

1) Итак, они решили сделать в основе всего т.н. стандартные части (Standard Parts). Чем ниже по иерархии находится часть (и чем чаще она используется), тем меньше вероятность ее изменения. Т.е. те кто сверху по иерархии, должны брать то что дают.

А обводы самолёта тоже брать какие дают?

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

Всяких же болтов-гаечек и прочих компонентиков с литерой не ниже О1 и у нас хватает.

2) Производственники (Manufacturing) участвуют в дизайне с самого начала, и они имеют возможность влиять на все до того, как был сделан Release.

Опять же, Америку тут не открыли, называется это "т.контр.", только необходимости внесения изменений он не исключит хотя бы потому, что ТЗ на изделие выдаёт заказчик, а не подрядчик.

После того как был сделан Release, вероятность изменения крайне мала, я бы сказал, что такая ситуация (изменения after Release) негативно отразится на тех кто привел к подобной ситуации.

А приводит к такой ситуации банальна конкуренция: взяла фирма А и вывела на рынок новую модель, вот и приходится фирме Б модернизировать свою продукцию.

Кого и как будете наказывать?

А нижеследующее заявление уже вообще ни в какие ворота не лезет.

3) Во всем этом процессе очень большую роль играет разграничение полномочий. Люди, занимающиеся "старшими" асс, не имеют возмойность менять низлежащие, в особенности Standard Parts.

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

В прочем, повторим ещё раз аксиомы:

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

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

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

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

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

P.S. а вообще этот топик нужно читать только целиком.

Share this post


Link to post
Share on other sites

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

Ну, начинается беседа о патриотизме...

А обводы самолёта тоже брать какие дают?

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

Всяких же болтов-гаечек и прочих компонентиков с литерой не ниже О1 и у нас хватает.

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

Опять же, Америку тут не открыли, называется это "т.контр.", только необходимости внесения изменений он не исключит хотя бы потому, что ТЗ на изделие выдаёт заказчик, а не подрядчик.

А приводит к такой ситуации банальна конкуренция: взяла фирма А и вывела на рынок новую модель, вот и приходится фирме Б модернизировать свою продукцию.

Кого и как будете наказывать?

Я здесь говорю о достаточно конкретном сегменте рынка, не смею судить о ваших конкретних проблемах. Однако, если речь идет о подрядчиках (suppliers), то они не могут просто так кого-либо заставить использовать новую модель, они обязаны поставлять старую сколько потребуются. Проблема еще и в том, что на каждое изменение post-Release понадобится сертификация FAA, а этого точно никто не хочет.

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

Осел с золотом на самом деле - страшный противник. Я уже несколько лет наблюдаю как Американские и Европейские фирмы год за годом улучшают свою производительность: полностью 3D Design, никаких Drawings, workflow + ограничение на возможность изменений, автоматизированная сертификация. Потом приезжаю в Россию, и наблюдаю людей мечушихся по КБ/заводу с бумажками, потерянние изменения (или неизвестно кем внесенные) и т.д.

Share this post


Link to post
Share on other sites

если у вас через 10000 жизней появится возмойность конкурировать с этой конретной фирмой, считайте что вам повезло.

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

естественно, все новое начинается сверху.

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

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

Однако, если речь идет о подрядчиках (suppliers), то они не могут просто так кого-либо заставить использовать новую модель, они обязаны поставлять старую сколько потребуются. Проблема еще и в том, что на каждое изменение post-Release понадобится сертификация FAA, а этого точно никто не хочет.

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

Государство А запустило в серию новый тип бомбовоза, тем самым сделав ЗРК страны Р неэффективными. Посему некое КБ в стране Р в скором времени выпускает ИИ, что бы там директор завода УХ по этому поводу бы не думал. Вследствии прохождения названного ИИ некоего КБ новый бомбовоз страны А становится неэффективным и уже фирма YHOHO вынуждена выпускать ИИ, что бы по этому поводу не думал владелец соответствующего авиазавода JAMF. Таковая игра будет продолжаться до тех пор, пока одна из противостоящих систем не исчерпает инновационую способность. Инициаторами же всей этой чехарды являются соответственно главкомы ВВС страны А и ПВО страны Р, они и оплачивают все издержки.

Осел с золотом на самом деле - страшный противник.

Страшный, но вся его сила лишь в человеческом пороке.

Десятки поколений людей вполне успешно побеждали сию страшилку, и ещё будут побеждать.

Американские и Европейские фирмы год за годом улучшают свою производительность: полностью 3D Design, никаких Drawings, workflow + ограничение на возможность изменений, автоматизированная сертификация. Потом приезжаю в Россию, и наблюдаю людей мечушихся по КБ/заводу с бумажками, потерянние изменения (или неизвестно кем внесенные) и т.д.

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

Чай не лаптем щи хлебают ни те, ни другие.

Share this post


Link to post
Share on other sites

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

Как говорят у нас на Западе, попытки оскорбить не было. Я не знаю чем занимается ваша фирма, но я вижу, что эти конкретние клиенты по всему миру имеют не слишком много конкурентов (при этом оккупируя большую часть своего сегмента) , а в России они конкурентов точно не имеют. Или опять осел с золотом виноват?

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

Не думаю, что грязная игра, просто суровая реальность - если уж так получилось, то сначала отработать, а потом наказывать. Кроме того, не вижу противоречия: все изменения вносятся и вылавливаются в CAD/CAM/PDM до того как был произведен Release, а потом уже поздно.

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

Государство А запустило в серию новый тип бомбовоза, тем самым сделав ЗРК страны Р неэффективными. Посему некое КБ в стране Р в скором времени выпускает ИИ, что бы там директор завода УХ по этому поводу бы не думал. Вследствии прохождения названного ИИ некоего КБ новый бомбовоз страны А становится неэффективным и уже фирма YHOHO вынуждена выпускать ИИ, что бы по этому поводу не думал владелец соответствующего авиазавода JAMF. Таковая игра будет продолжаться до тех пор, пока одна из противостоящих систем не исчерпает инновационую способность. Инициаторами же всей этой чехарды являются соответственно главкомы ВВС страны А и ПВО страны Р, они и оплачивают все издержки.

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

В качестве не-авиационного примера, у меня есть клиент, который делает некие электро-шкафы, стоящие потом на улице. Когда у их конкурента появляется новая модель, они вынуждены отвечать. Они меняют соответствующий модуль, следя при этом, чтоб минимизировать влияние на остальние блоки. Фактически, это продукт, где 90% деталей пришли из старого, используя PLM функцию Design Copy. И опасность "вихря в Workflow" снижается опять-таки, кардинально.

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

Чай не лаптем щи хлебают ни те, ни другие.

Опять-таки, я говорю о том что видел: американские, французские, шведские фирмы, полностью 3D Design, очень четкая система PLM. И то что видел в России - только в апреле имел честь.

Не уверен, что это имеет отношение к теме, по-поводу сравнения реальних образцов. У меня знакомые в свое время работали на американскую авиационную военку. Им каким-то образом достались советские двигатели и они их сравнивали со своими. Так вот, их поразило, что если по параметрам они были вполне сравнимы (что-то хуже, что-то лучше), но советские образцы отличались крайне низкой поддерживаемостью - их проще было выкинуть, чем чинить. Как они (американцы) мне объясняли, у них контракт заключается на 20-30 лет, заказчик пытается заставить фирму над поддерживаемостью, чтобы контролировать свои долговременные расходы. В этом смысле, философия PLM очень даже сюда вкладывается.

Share this post


Link to post
Share on other sites

...я вижу, что эти конкретние клиенты по всему миру имеют не слишком много конкурентов (при этом оккупируя большую часть своего сегмента) , а в России они конкурентов точно не имеют.

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

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

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

Кроме того, не вижу противоречия: все изменения вносятся и вылавливаются в CAD/CAM/PDM до того как был произведен Release, а потом уже поздно.

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

То есть если надо выпускать ИИ уже по построенному ЭЦМ, значит это ИИ будет выпущено и "ротор" закрутится.

Они меняют соответствующий модуль, следя при этом, чтоб минимизировать влияние на остальние блоки. Фактически, это продукт, где 90% деталей пришли из старого, используя PLM функцию Design Copy. И опасность "вихря в Workflow" снижается опять-таки, кардинально.

Великое дело модульная конструкция, но не спасёт и она от "ротора".

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

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

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

А вот с этим спорить не буду.

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

...

Это надеюсь понятно?

Ну, с этим проблем и не возникало :)

Вот он, ключевой момент беседы, о котором я не знал (выделено мною):

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

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

Однако, он входит в противоречие с вышесказанным другими (выделено, опять же, мною):

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

В контексте нашего разговора, я понял эту выделенную фразу, примерно как "извещение подписывают все те, кто подписывает эл.модель"

А на деле получается, что далеко не "все"!

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

Что при электронном документообороте невозможно.

Странник, а можно чуть поподробнее, как эта процедура "уговора" вышестоящего проходит в реальности, оформляется документально, при бумажном документообороте? Кто контролирует процесс?

Share this post


Link to post
Share on other sites

Странник, а можно чуть поподробнее, как эта процедура "уговора" вышестоящего проходит в реальности, оформляется документально, при бумажном документообороте? Кто контролирует процесс?

Сядут за стол 3 разгильдяя:

"разраб." - разработчик "колеса",

"вед.констр" - разработчик "моста"

"гл.констр." - начальник отдела

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

"Нач.предпр." подпишет не глядя, если какой сдвиг - то позвонит секретарше, а та приведёт соответствующего начальника отдела. Всё просто.

А что бы ВСЯ цепочка вхождений автографы ставила - это просто немыслимо, да и невозможно.

Share this post


Link to post
Share on other sites

ID: 77   Posted (edited)

Сядут за стол 3 разгильдяя:

"разраб." - разработчик "колеса",

"вед.констр" - разработчик "моста"

"гл.констр." - начальник отдела

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

Ну, с этим понятно. Процесс разработки, так сказать ;)

"Нач.предпр." подпишет не глядя

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

А PDM такого провернуть не даёт? Полагаю, тут два варианта: либо 1. подпись нулевой сборки "подписывает" все нижестоящие, подпись "нач.предпр." равносильна подписи авторов, либо 2. "нач.предпр" не ставит подписи на нулевой, но ставит какую-то галочку на колесе, после чего колесо перестаёт считаться изменённым для остальных сборок, что и фиксируется соответствующим документом.

Edited by AnTe

Share this post


Link to post
Share on other sites

"Нач.предпр. подпишет" т.о., если я правильно понимаю, утвердится нулевая сборка?.

Неа, "нач.предпр.", как правильно говорил VOleg, подписывает все извещения.

Здесь начинается область бизнесс-процессов, но мы в неё углубляться не будем.

И именно это даёт разрешение нижестоящие сборки не переутверждать.

Этот подписывает всегда позже всех, разве что в ВП МО может кто пойдёт после..

А PDM такого провернуть не даёт? Полагаю, тут два варианта: либо 1. подпись нулевой сборки "подписывает" все нижестоящие, подпись "нач.предпр." равносильна подписи авторов, либо 2. "нач.предпр" не ставит подписи на нулевой, но ставит какую-то галочку на колесе, после чего колесо перестаёт считаться изменённым для остальных сборок, что и фиксируется соответствующим документом.

"Нач.предпр." просто не в силах уследить за всем, ну представьте что у вас хотя бы 50 тем (новых изделий), в ЭЦМ каждой из которых будет порядка 10000 компонентов... или хотя бы 3...4 самолёта в разработке.

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

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

Share this post


Link to post
Share on other sites

Спасибо! Кажется, начинает доходить... Надеюсь, не заманал ещё..

Надеюсь, что, быть может, попытка в очередной раз сформулировать проблему, поможет её решению?

Как я понимаю, проблема состоит в том, что нельзя провести изменение, не регистрируя его как изменение?

То есть, в случае с ИИ - дело понятное. ИИ на каком-то этапе перестают подписывать, и точка.

В случае, когда вместо изделие+ИИ есть новая версия изделия - это сделать не представляется возможным, т.к. в каждом случае изменения возникает НОВЫЙ документ...

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

да.... надо подумать....

правильно я сформулировал? :)

Share this post


Link to post
Share on other sites

правильно я сформулировал? :)

В общем и целом правильно, вот только

ИИ на каком-то этапе перестают подписывать, и точка.

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

В электронном же виде получается дополнительная "карусель", что собственно в топик и вынесена.

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.

  • Recently Browsing   0 members

    No registered users viewing this page.



  • Сообщения

    • qieb111
      Features
      P/N: P1022
      Nonin 9000N disposable neonate/adult(<3kg/>40kg) SpO2 sensor
      Latex free
      0.9m PVC cable
      CE/ISO 13485 FSC FDA
      Packages: non-sterilization, individual package with instruction

      Photos

      Compatibility
      Nonin

      Specifications
      Safety: IEC 60601-1-1 approved, conformity with MDD 93/42/EEC and EN9919:2005
      Patient sizes: Neonate/Adult
      Ambient temperature: 0 to 40℃ (32 to 104℉)
      Relative humidity: 15% to 95%
      Measurement technology: Tri-wavelength LEDs & photo detector
      LED wavelength: 660nm/880nm/905nm
      SpO2 accuracy: ±3 (70-100%); Unspecified (0-69%)
      Pulse rate range: 20-250bpm
      Pulse rate accuracy: ±3 (20-250bpm)

      Payment
      We accept payment via TT (Telegraphic Transfer) and L/C. For small orders of samples, it's acceptable by Western Union and PayPal.

      Shipment
      We offer as many shipping options as possible, including DHL,UPS, TNT, FedEx, EMS, etc.China Disposable SpO2 Sensor
      website:http://www.spo2cables.com/patient-monitor-accessories/disposable-spo2-sensor/
    • ДОБРЯК
      Чтобы выполнять роль зеркала нужно понимание того как решается контактная задача, а у тебя роль попугая или обезьянки, которая кривляется. ) В данной теме. Ты прежде чем давать советы как моделировать и решать контактные задачи сам пойми как программа автоматически меняет пятно контакта.  Начни с простой задачи контакт узел - узел. Потом разберись с контактом узел - конечный элемент. Потом пойми как учитывается сила трения в пятне контакта. Ведь с одной стороны узлы контактируют, а с другой могут скользить друг относительно друга. Почитай лучше хелп, чем тратить время на пустой треп и кривляния. ) И только после этого ты сможешь объяснить, что тебе автоматически нарешал черный ящик с названием Ансис или Абакус.  И сможешь объяснить правильно ли ты сделал математическую модель. А пока только кудах-тах-тах слышно с твоей стороны. Видимо хотел увеличить количество просмотров данной темы. )))  
    • Udav817
      С листовыми я уже заметил один подвох. Нельзя много раз прыгать туда-сюда с синхронки в обычную и обратно. Потом какие-то грани просто перестанут двигаться. И управляющие размеры на них не всегда работают. Видимо какой-то нюанс я не уловил ещё. Но в целом да, с листовыми удобно. Надо немного сдвинуть полку - ты не заморачиваешься с размерами в эскизе, просто грань двигаешь, а тело само добавится/убавится и развёртка перестроится.
    • emre007
        I want to process here angled but I could not do which command I should use  
    • EVGENY1325
      Добрый день господа.  Кто может поделится постом,станок SVL-850 стойка FANUC oi-md, так- же имеется дополнительная ось.
    • Ветерок
      Идея была несколько иной. Поставить их вдоль друг друга и давить одним концом навстречу, прилагая к обоим одинаковый момент. И смотреть в какую сторону от середины будет прогибаться.
    • pechkin624
      Вот про это даже не знал.Милл тогда помогите найти.
    • chatjokey
      Я не среднестатистический житель России. Могу ответить сразу. Не позволительная. Они работают по 12 часов. Впрочем как и я. Но если есть огромное желание, как у меня, то для них будет менее напряжно по бюджету сделать такой трип. Т. Е. У них среднестатистический житель может себе это позволить при желании. У нас нет. Япошек и китайцев туристов в Питере нынче полно. Туристический сезон открыт! 
    • Kelny
      Как вариант использовать штатный инструмент, некорректная работа которого в некоторых старых версиях и породила всякого рода макросы на тему:  
    • piden
      Ок, ок. Публика предупреждена на счет ну или вечер...