Перейти к публикации

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


Рекомендованные сообщения

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

Это один путь.

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

Раньше версию отмечали номером извещения т.е. "колесо изм. 3". И это даже в планах производства прописывалось. Для ремкомплектов могли запускать и "колесо изм.2"....

Теперь вместо "изм.3" введено "вер.3" или 1.3 кому как удобно (в ГОСТЕ формат версии не прописан как мне помнится).

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


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

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

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

Любое правило, если его исполнять фанатично, может привести к абсурду. Человек не бог и не в состоянии предусмотреть все нюансы и последствия, изобретая правила, CADы, PDMы. Тем более, если изобретает не комплекс всего этого, а уже использует изобретенное кем-то.

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

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

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

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

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

Привычка математика, - перед решением сформулировать проблему максимально коротко:)

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

В общем, да.

ИИ допускается подписать не всеми участниками процесса, использующими изменённую деталь.

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

Так как документы физически меняются.

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

Раньше версию отмечали номером извещения т.е. "колесо изм. 3". И это даже в планах производства прописывалось. Для ремкомплектов могли запускать и "колесо изм.2"....

Теперь вместо "изм.3" введено "вер.3" или 1.3 кому как удобно (в ГОСТЕ формат версии не прописан как мне помнится).

нннуууу... а разве в системе электронного документа оборота деталь характеризуют не "деталь+версия" ?
Ссылка на сообщение
Поделиться на других сайтах

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

за колесо-то отвечают! но и за автомобиль целиком-то тоже кто-то отвечает! Получается, что разрешение "подписывать не всеми, использующими изменённую сборку", - ещё та палка о двух концах!

Вот почему я и начал спрашивать, как это уже реализовано в бумажном документообороте. Такое "соображение на троих", вообще, ГОСТами приветствуется?

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

Вот почему я и начал спрашивать, как это уже реализовано в бумажном документообороте. Такое "соображение на троих", вообще, ГОСТами приветствуется?

Собственно по ЕСКД всё и делается.

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

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

Собственно в этом и сидит самое радикальное, можно даже сказать философское, отличие.

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

за колесо-то отвечают! но и за автомобиль целиком-то тоже кто-то отвечает! Получается, что разрешение "подписывать не всеми, использующими изменённую сборку", - ещё та палка о двух концах!

Приведу пример из отрасли электроники: изделия собирают из электронных компонентов. Свойства этих компонентов вообще-то зависят от партии, в которой эти компоненты были произведены. Но ведь КД на изделие-то при этом (от партии к партии) не меняют! (даже при электронной КД). Просто свойства от серии к серии меняются в определенных границах, определенных ТУ (или стандартом).

Этот пример просто наиболее мне знаком, но и в других отраслях все точно также.

Нужно просто определить (проименовать, стандартизировать) допустимые диапазоны изменений. И в моделях изделий применять элементы со стандартизированными названиями этих диапазонов.

Понятно, что в механике более явно количество переходит в качество. Но основная мысль - в отделении базовой документации от конкретной (по которой производят конкретные элементы) остается верной. Разве не так?

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

Но основная мысль - в отделении базовой документации от конкретной (по которой производят конкретные элементы) остается верной. Разве не так?

Так.

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

В промышленности я уже писал - "изм.1", "изм.2"....., а по новым стандартам "вер.1", "вер.2".....

Еще раз повторю, что гайка №003 без изм. с изм.1, с изм.2.... это все равно гайка №003 и извещения на сборки, в которые она входит не выпускают (во-всяком случае раньше не выпускали - а я и сейчас не выпускаю). И не надо придумывать лишнее на пустом месте. Главное гайка с изм. 3 будет всегда гайкой и других гаек в серии не будет, а только в ремонте выпущенных изделий.

Вроде с 1973 года все ясно, по крайней мере мне.

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

Нужно просто определить (проименовать, стандартизировать) допустимые диапазоны изменений. И в моделях изделий применять элементы со стандартизированными названиями этих диапазонов.

ЕМНИП, именно об этом и говорилось в самом начале ветки.

АБВГ.00.00.000 это вообще то до 9900000 деталей и 10000 сборочных единиц. Положительно, не пренебрегайте 4 уровнями вложений.

Ну пусть у нас из 8000 компонентов оригинальны 3000. На каждый оригинальный компонент приходится по 10 изменений за 20 лет ЖЦИ, в среднем. Каждая правка тянет за собой 4 уровня. Очень грубо 3000*10*4*7/(20*360*5)=23,33 изменения в день. А ведь это всё ИИ, между прочим. То есть весь отдел общих видов только и делает что непрестанно бегает по предприятию - собирает подписи, все 20 лет.

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

Например: облегчили какую ни будь деталь грамм на 50, хотя бы материал изменили, а допуска на блок установлены плюс минус 200 грамм, реально же вообще грамм на 70 всего и бегают. Центровка при этом вообще практически не дёрнется, прочие же параметры совсем ни при делах. ИИ таким образом ограничется собственно той самой деталью.

В CAD всё равно обновится вся цепочка, но может кто слыхал таки о способах не потерять при этом утверждающие галочки Workflow?

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

Собственно по ЕСКД всё и делается.

А как там это сформулировано? (в какую сторону копнуть? :))

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

Собственно в этом и сидит самое радикальное, можно даже сказать философское, отличие.

Если уж углубились в философию...

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

В промышленности я уже писал - "изм.1", "изм.2"....., а по новым стандартам "вер.1", "вер.2".....

Еще раз повторю, что гайка №003 без изм. с изм.1, с изм.2.... это все равно гайка №003 и извещения на сборки, в которые она входит не выпускают (во-всяком случае раньше не выпускали - а я и сейчас не выпускаю). И не надо придумывать лишнее на пустом месте. Главное гайка с изм. 3 будет всегда гайкой и других гаек в серии не будет, а только в ремонте выпущенных изделий.

Вроде с 1973 года все ясно, по крайней мере мне.

хм, получается, что если сделать (или она уже есть?) настройку в PDM, при включении которой документ, у которого изменилась версия входящей детали, сборки (ДСЕ, т.е), не считается изменённым, - то проблема, означенная Странником исчезнет?

PS а если всё-таки гайка с изм.5, супертяжёлая и влияет на сборки, в которые входит? Куда, при бумажном документообороте ставят отметину, что изменения подписывает и автор моста?

Изменено пользователем AnTe
Ссылка на сообщение
Поделиться на других сайтах

....

PS а если всё-таки гайка с изм.5, супертяжёлая и влияет на сборки, в которые входит? Куда, при бумажном документообороте ставят отметину, что изменения подписывает и автор моста?

Распишется за "вед.констр", или "провер.", чаще всего - это виза на полях.

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

Распишется за "вед.констр", или "провер.", чаще всего - это виза на полях.

Наверное, я не совсем ясно задал вопрос :(

Хоть и не знаю ГОСТов, по которым регулируется бумажный документооборот, в плане ИИ, всё-таки попробую самостоятельно дать отчасти ответ на собственный вопрос:

Итак, изменили гайку. Изменение № 5, или, что эквивалентно, выпустили версию гайки № 5.

При бумажном документообороте, насколько я понял, ИИ в обязаловку подписывает только разработчик колеса. Ну, ещё пара человек (нач предпр. или кто там ещё). Разработчики моста, автомобиля - не обязаны его подписывать, только по желанию :) разработчика колеса.

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

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

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

Собственно говоря, если в PDM не считать изменённым документ, в котором изменилась всего лишь версия входящей в него ДСЕ, - проблема "ротора" не существует? Особенно, если утверждать "существенные" изменения, по способу "1"

Изменено пользователем AnTe
Ссылка на сообщение
Поделиться на других сайтах

А если замена гайки таки влияет на мост?

Значит ИИ на ЭТУ сборку "Колесо" подписывать НЕЛЬЗЯ. Нужно создавать новую сборку "Колесо" и предлагать ЕЕ для включения в сборку "Мост".

И уже на уровне Мост-Колесо принимать решение по тому же алгоритму, что и на уровне Колесо-Гайка.

Обоснование - колесо может использоваться в нескольких РАЗНЫХ мостах, и для одних из них влияние замены гайки в колесе может быть в пределах допустимых, а для других - НЕТ.

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

....

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

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

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

.....

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

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

И ещё, проблему с "ротором" легко не похороните, ибо в сборках бывает полным-полно контекстов, о чём выше по топику уже говорилось.

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

Значит ИИ на ЭТУ сборку "Колесо" подписывать НЕЛЬЗЯ. Нужно создавать новую сборку "Колесо" и предлагать ЕЕ для включения в сборку "Мост".

ЫЫыыы! Так вот, в чём дело! В терминологии: ИИ на сборки не выпускаются, для сборок выпускают новую версию! Значит, обозначив элементы ЭСИ, как ДСЕ (деталь == сборке), я ошибся. Тогда вопрос Олегу:

Еще раз повторю, что гайка №003 без изм. с изм.1, с изм.2.... это все равно гайка №003 и извещения на сборки, в которые она входит не выпускают (во-всяком случае раньше не выпускали - а я и сейчас не выпускаю)

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

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

Кому от этого легче? Спутник на орбите загнулся, нашли виновника - гражданина-неопытного-конструктора, и "не простили его", вычтя у него из зарплаты стоимость аппарата? :bleh: А так же из зарплат десятка последующих поколений :)

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

Ну конечно пойдёт. Кому охота на сотню-другую миллионов зелени встрять:) Если догадается, что нужно идти.

Если серьёзно, - то я считал, что система документооборота должна была его ОБЯЗАТЬ пойти, при любом изменении, пусть даже он считает, что оно незначительное. А это означает, что его изменение подпишет разработчик колеса, замену колеса подпишет разработчик моста, и т.д. И при бумажном, и при электронном документообороте? т.о. "выпустить молчком кардинальное ИИ" ему просто не позволит система-"ротор". Или эту проблему можно решить по-другому?

И ещё, проблему с "ротором" легко не похороните, ибо в сборках бывает полным-полно контекстов, о чём выше по топику уже говорилось.

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

ГОСТ 2.503-90

Пункт 1.2:

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

Комментарий к 1.2:

При нарушении взаимозаменяемости изменяемого изделия, с изделями изготовленными ранее, изменения в документы последних не вносят, а выпускают новые документы с новыми обозначениями или единичные конструкторские документы преобразуют в групповые по ГОСТ 2.113.

Пункт 1.3:

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

Пункт 1.4:

Если изменяемый документ на изделие входит в состав документов других изделий, то должна быть обеспечена возможность внесения изменений в документы всех изделий, указанных в карточках учета документов по ГОСТ 2.501 или в карточке учета применяемости документов по ГОСТ 3.1201. Если хотя бы для одного изделия изменение окажется неприемлимым, то на изменяемое изделие должен быть выпущен новый документ с новым обозначением.

PS Так, для информации...

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

ЫЫыыы! Так вот, в чём дело! В терминологии: ИИ на сборки не выпускаются, для сборок выпускают новую версию!

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

Версии и извещения об изменениях - это практически одно и то же (определение версии - по ГОСТ 2.051) Практически - потому что при проектировании извещение об изменении под номером 1 появляется при первом внесении изменений в подлинник, то есть при порождении версии с номером 2 (версии с номером 0 не бывает).

А я говорил о другом: если нет уверенности, что замена гайки в колесе не влияет на мост, то нужно выпускать ДРУГУЮ сборку "Колесо" (даже не новое исполнение, а с новым порядковым децимальным номером). И уже эту новую сборку "Колесо" предлагать для включения в сборку "Мост".

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

ГОСТ 2.503-90

Пункт 1.2:

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

Комментарий к 1.2:

При нарушении взаимозаменяемости изменяемого изделия, с изделями изготовленными ранее, изменения в документы последних не вносят, а выпускают новые документы с новыми обозначениями или единичные конструкторские документы преобразуют в групповые по ГОСТ 2.113.

Пункт 1.3:

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

Пункт 1.4:

Если изменяемый документ на изделие входит в состав документов других изделий, то должна быть обеспечена возможность внесения изменений в документы всех изделий, указанных в карточках учета документов по ГОСТ 2.501 или в карточке учета применяемости документов по ГОСТ 3.1201. Если хотя бы для одного изделия изменение окажется неприемлимым, то на изменяемое изделие должен быть выпущен новый документ с новым обозначением.

PS Так, для информации...

Вот-вот, именно так.

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

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

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

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

При изменении детали , входящей в сборку , новая ревизия сборки не создается.

Так что ловушки стратегической никакой нет.

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

При изменении детали , входящей в сборку , новая ревизия сборки не создается.

Так что ловушки стратегической никакой нет.

:clap_1:

Надо полагать сейчас будет сказано много нового..

dynas, давайте подробности, начиная с того, какую PDM используюте, где брали не неё дистриб и все прочие подробности, лучше со скринами или даже с видеороликом. :wink:

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

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




×
×
  • Создать...