Странник

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

126 сообщений в этой теме

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах


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

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

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

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

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

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

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

Изменено пользователем DGroot

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Пока бюро А готовит свои изменения (см. выше), в бюро Б возникла потребность проводить изменения в узле АБВ.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 с обеими изменениями

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

АБВ.3445.000.000

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

:wallbash: :wallbash: :wallbash:

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ID: 50   Опубликовано: (изменено)

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

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

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

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

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

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Понятно.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Проектирование частного должно вестись как часть целого, то есть неизбежно появляется модель общего вида - ЭЦМ, полная модель, до шайбочки, до проводка. Без 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:

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ID: 67   Опубликовано: (изменено)

Проектирование частного должно вестись как часть целого, то есть неизбежно появляется модель общего вида - ЭЦМ, полная модель, до шайбочки, до проводка. Без 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:

Изменено пользователем AnTe

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Возвращаясь к оригинальной теме: все описанные проблемы были объяснены и решены в 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 лет.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Самая главная беда конструктора в бумажной технологии (даже при правильной организации работ) это необходимость постоянно заново прорисовывать сборку. Считай вручную делать обновление. Собственно тут сидит радикальное преимущество параметрических 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. а вообще этот топик нужно читать только целиком.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

...

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

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

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

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

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

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

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ID: 77   Опубликовано: (изменено)

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

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

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

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

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

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

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

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

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

Изменено пользователем AnTe

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Гость
Эта тема закрыта для публикации сообщений.

  • Сейчас на странице   0 пользователей

    Нет пользователей, просматривающих эту страницу



  • Реклама

  • Сообщения