ПИ плюс ИИ плюс Матмодели

[suslad 1]

Итак, пришла пора раздвинуть границы <noindex>вот этой темы</noindex> поскольку складывается впечатление что некоторые авторы кроме ИИ собственно ничего и не выпускают. А ведь есть еще и ПИ, не говоря про ДИ, ДПИ, ПР.

Итак, начнем по порядку.

Допустим, есть матмодель некоторой детали, имеющей литеру "А" -- т.е. находится в производстве, КД на нее в архиве, в общем все замечательно. Но враги не дремлют и надо выпускать ПИ -- т.е. изменение которое потребует, к примеру, доработки оснастки (как самый простой случай). Конструктор "идёт в PDM/PLM" (не суть важно), находит нашу матмодель, берет ее на изменение, вносит в нее все что необходимо, сдает обратно в PDM/PLM, запускает процедуру согласования ПИ. Будем счиать что все требуемые подписи собраны и данное ПИ взято в подготовку производства -- инструментальное производство начало отработку данного ПИ. Здесь стоит отметить, что по времени такая "отработка" может выполняться и несколько месяцев (ну а если совсем повезет -- то и несколько лет).

И вот по прошествии некоторого времени, например месяца 3, конструктор изделия решается (ну враги то все равно не дремлют) выпустить еще одно ПИ на эту деталь. И вот тут возникает дилемма: а какую из матмоделей брать за основу для внесения изменений? Если руководствоваться ГОСТом 2.503 -- "надо брать" ту что с литерой "А"; но мы же "не маленькие" и прекрасно понимаем что ГОСТы писались под бумажный документооборот и ПИ предполагало внесение перечня изменений в бланк ПИ, которые, при погашении, успешно переносились в подлинник. С матмоделями так не пройдет. Матмодель изначально содержит всю требуемую информацию по детали и, как правило, а если точнее то по требованию все того же ГОСТа, производится замена чертежа а в графе "Содержание изменения" вносится запись типа "ХХХ.УУУ.ZZZ заменить". Конечно, практически всегда добавляется "Примечание", в котором конструктор старается подробно описать что же он все-таки поменял и чем же новый чертеж (мы подразумеваем и матмодель) отличается от старого (видимо поэтому технологи не очень любят игру "найди 10 отличий").

Но все же вернемся к нашей дилемме. Допустим мы выберем иной вариант, т.е. возьмем матмодель, которая соответствует уже выпущенному ПИ. Вроде бы все хорошо и последовательно. Однако и здесь появляются проблемы -- существует вероятность что второе ПИ будет выполнено раньше чем первое. Значит, при погашении второго ПИ мы должны будем удалить изменения содержащиеся в первом ПИ. Если посмотреть еще дальше -- при погашении первого ПИ после того как погашено второе ПИ придется решать еще больше проблем -- объединять изменения первого и второго.

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

Кроме этого, все еще больше усугубляется использованием матмоделей с таблицами исполнений (или конфигурациями в терминологии SoldWorks).

PS Ну и на последок. Вес вышеописанное в большей степени относится к крупносерийному и массовому производству. Для единичного это не так критично.

Собственно, если кто-то уже проходил это -- милости просим на обсуждение.

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

Также интересна информация по нормативным документам, буржуйским, по которым они работают.

[Странник 6]

В самом деле этот топик сильнее перекликается вот с этим

<noindex>http://fsapr2000.ru/index.php?showtopic=15069</noindex>

По опыту работы конструктором могу сказать следующее: в альбомах часто подкалывается по 2...3...4 и даже более ПИ, но в каждом из них есть чёткое указание о внедрении и заделе, посему катострофы не бывает.

Конечно, чем выше класс команды проектировщиков тем этих самых ПИ меньше, но жизнь есть жизнь.

В хорошо знакомой мне SWR-PDM для подобного рода ситуаций существует двойной механизм сохранения вариантов:

-итерации

-версии

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

Правда до указаний о внедрении и заделе SWR-PDM пока не доросло, но думаю этого можно и потребовать.

[brigval 687]

suslad

Однако и здесь появляются проблемы -- существует вероятность что второе ПИ будет выполнено раньше чем первое

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

Кроме того, я думаю, что вариант гашения ПИ и переоформления в ИИ, по видимому, при компьютерном проектировании никогда не должен иметь место. Так же как и не должна иметь место замена листов документа (а уж текста, тем более), а должен всегда меняться документ на документ.

ЕСКД разрешает выпускать ИИ, в котором могут содержаться все данные аннулируемого ПИ, а также и другие, и в котором будет указание об аннулировании ПИ. Если документ (ПИ) выпущен и согласован, нет смысла (да и не удобно в электронном документообороте) ЕГО править в дальнейшем. Самое главное, что ЕСКД это не противоречит. И здесь может быть достигнут компромис между ЕСКД и техническими средствами (компьютерным проектированием).

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

[brigval 687]

Я не вижу больших проблем работы с математическими моделями (файлами 3D-моделей, чертежей, текстовых документов и схем) при разработке ПИ. Если добавлять в имя файла, скажем, в квадратных скобках, перечень всех ПИ, то путанницы никогда никакой не будет. То есть, никогда не будет двух одинаковых файлов. И каждый файл будет нести в себе новую информацию, оговоренную в примечании к документу в ПИ. Которое всегда можно посмотреть в БД. Причем, можно сделать так, чтоб в чертеж (при его разработке) автоматом вносилась запись о том, что он действует с ПИ перечисленными в имени файла, для котрого делается чертеж. Да и для остальных документов (схем и текстовых) это тоже можно сделать.

[DGroot 8]

Ну и на последок. Вес вышеописанное в большей степени относится к крупносерийному и массовому производству. Для единичного это не так критично.

Собственно, если кто-то уже проходил это -- милости просим на обсуждение.

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

Также интересна информация по нормативным документам, буржуйским, по которым они работают.

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

Больше всего чего можно опасаться от внедрения буржуйской системы - это перестройки самой организации ведения всего годами сложившегося процесса. Но пока видимо наши спецы просто даже не знают надо это делать или нет, а если надо то по какому месту ломать и перестраивать. Опыта "0".

По моим представления работа в PLM(PDM) системах в отличии от CAD во многом зависит от психологии (от ментальности) тех кто с ней работает. А наша ментальность во многом определяется нашими ГОСТ и любовью к непосредственному общению с клиентом. Компания SolidWorks Russia разрабатывают PLM(PDM) основанную на наших ГОСТ

и это несмотря на то что (по моим сведениям) существует американский вариант системы PDM компании SolidWorks.

Изменено 12 июля 2008 пользователем DGroot

[brigval 687]

А наша ментальность во многом определяется нашими ГОСТ и любовью к непосредственному общению с клиентом

Не только. Наша "ментальность" часто определяется требованиями ПЗ. А ПЗ сейчас работает по ЕСКД. Пока не получит иных указаний.

[ak762 307]

А ведь есть еще и ПИ, не говоря про ДИ, ДПИ, ПР

А ПЗ сейчас работает по ЕСКД

К автору топика и остальным любителям сокращений:

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

если таким чайникам как я про ИИ еще можно догадаться то остальные...?

я например знаю устойчивое сокращение ХЗ

[DGroot 8]

Не только. Наша "ментальность" часто определяется требованиями ПЗ. А ПЗ сейчас работает по ЕСКД. Пока не получит иных указаний.

Извените - отклоняясь от заявленной темы.

Не в бровь, а в глаз. Как раз с ПЗ и самая сложность. К сожалению, наш Заказчик (ПЗ) (и другие согласующие лица) настолько сильно привык к тому, что к нему все приходят на поклон и просят подписи под документом, что никакой Windchill со своими сообщениями типа "Вам пришло задание на согласование документа" ему не указ. Вот пока ему не позвонят и не попросят, и в ноги не упадут, сам он даже с места не сдвинется, чтобы посмотреть документы и пригласить специалиста, если это потребуется (при чем здесь ЕСКД??).

При всем при том, у меня нет аргументов, считать, что ЕСКД содержит какие-то противоречия в части работы PLM(PDM).

Сейчас в ЕСКД есть понятие электронной подписи, как в прочем и Удостоверяющего листа (УЛ), есть понятие документа в электронном виде. Есть федеральный закон об электронной подписи (ЭЦП). Что еще надо. Все, чего нет в ЕСКД, можно расписать в стандартах предприятия (СТП) и согласовав с заказчиком формально этим руководствоваться. Мы у себя так и сделали - разработали СТП об использовании ЭЦП и согласовали его с ПЗ. Заключили с ПЗ (т.к. он сторонняя организация) соглашение об использовании корпоративной сети в целях электронного документооборота. Тот же ГОСТ 2.051-2006 через абзац оговаривается – то-то и то-то по согласованию с заказчиком. Т.е. формально все преодолимо при обоюдной заинтересованности в процессе. Хуже, когда эта заинтересованность не подкрепляется нашими убедительными знаниями системы как таковой. А понятия заинтересованность и ЕСКД - это понятия из разных областей.

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

P.S. Сейчас мы вводим жесткий регламент о времени нахождения документов на каждой инстанции согласования. Контрь за его исполнением возлагается на администраторов системы. Им поручается подготавливать отчеты для руководства, в том числе для руководства ПЗ.

Изменено 12 июля 2008 пользователем DGroot

[brigval 687]

К автору топика и остальным любителям сокращений:

Я думаю, что здесь нет любителей сокращений. Многие термины из этой темы Вы легко найдете в ГОСТ 2.503. В том числе и расшифровку аббревиатуры.

[brigval 687]

(при чем здесь ЕСКД??).

Ну хотя бы при том, что именно ЕСКД обязывает согласовывать КД с ПЗ. :)

По поводу того, что мне легче, взгляните здесь <noindex>http://fsapr2000.ru/index.php?showtopic=14487&hl</noindex>

За эту тему, я получил штраф в 10 %. :)

Почти все, о чем Вы пишете мне понятно и я со многим согласен.

Но от темы темы не хочется отклоняться.

[volodja 77]

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

Кроме этого, все еще больше усугубляется использованием матмоделей с таблицами исполнений (или конфигурациями в терминологии SoldWorks).

PS Ну и на последок. Вес вышеописанное в большей степени относится к крупносерийному и массовому производству. Для единичного это не так критично.

Собственно, если кто-то уже проходил это -- милости просим на обсуждение.

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

Также интересна информация по нормативным документам, буржуйским, по которым они работают.

По поводу буржуйского крупносерийного производства:

Модель имеет индекс, для работы в производство берут последний, актуальный. Если конструктор вносит изменения или улучшает конструкцию, то он обязан:

- немедленно отослать по электронной почте уведомления об изменении всем участникам проекта, типа стоп всем

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

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

Но самая важная проблема, не как обозначить итд, а в кооперации звеньев, то есть человеческий фактор. Это напрочь отсутствует в России и недостаточно развито в Западной Европе и США. Без взаимодействия отделов, с привычным перетягиванием одеяла на себя, любая система обречена на провал. Японцы, научившись взаимодействовать друг с другом, медленно, но верно выходят на первые места; к примеру. в автостроении это уже ясно видно.

[suslad 1]

В хорошо знакомой мне SWR-PDM для подобного рода ситуаций существует двойной механизм сохранения вариантов:

-итерации

-версии

Это есть и у меня в INTRALINKе, но это абсолютно не решает вышеописанную проблему.

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

Такой подход и мне видится наиболее оптимальным. Однако пока над нами довлеют ГОСТы, позволяющие выпустить, как вы далее заметили, до 4-х ПИ одновременно (странно, я считал что до 3-х, ну да ладно), мы им не можем противоречить. Или, если быть откровенным, конструктор считает такой подход заламыванием ему рук. Более того, если по ПИ уже "грызут металл" то его сложно, я бы сказал невозможно, аннулировать.

Я не вижу больших проблем работы с математическими моделями (файлами 3D-моделей, чертежей, текстовых документов и схем) при разработке ПИ. Если добавлять в имя файла, скажем, в квадратных скобках, перечень всех ПИ, то путанницы никогда никакой не будет. То есть, никогда не будет двух одинаковых файлов. И каждый файл будет нести в себе новую информацию, оговоренную в примечании к документу в ПИ. Которое всегда можно посмотреть в БД. Причем, можно сделать так, чтоб в чертеж (при его разработке) автоматом вносилась запись о том, что он действует с ПИ перечисленными в имени файла, для котрого делается чертеж. Да и для остальных документов (схем и текстовых) это тоже можно сделать.

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

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

Насколько мне известно в основе Windchill лежит ISO 10303. А вот модуль проведения изменений (который Enterprise Change Management) на базе чего стоиться -- к сожалению, не в курсе.

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

А может не надо бояться? :)

[brigval 687]

Однако пока над нами довлеют ГОСТы, позволяющие выпустить, как вы далее заметили, до 4-х ПИ

Вы малость не поняли. Речь шла не о уже выпущенных ПИ, а о том случае, когда одно ПИ еще не выпущено, но уже готовится к выпуску и в этот момент появляется необходимость выпустить еще одно ПИ.

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

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

[suslad 1]

Вы малость не поняли. Речь шла не о уже выпущенных ПИ, а о том случае, когда одно ПИ еще не выпущено, но уже готовится к выпуску и в этот момент появляется необходимость выпустить еще одно ПИ.

В этом случае никто выпускать такое ПИ не будет. Доработают и тогда уже вперед.

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

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

[brigval 687]

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

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

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

Решен вопрос по существованию нескольких 3D-моделей для одной записи в спецификации (уже с использованием программы для выпуска спецификации).

Аналогично, я думаю, может быть решен вопрос и с именами 3D-моделей и 2D-чертежей для ПИ.

ПИ я уже давно не выпускал. Но видимо, на моем предприятии придут к их выпуску. Поэтому вопрос мне интересен.

[Странник 6]

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

Например: На контракт №1001, по особой прозьбе заказчика, разместить в салоне вместо 200 посадочных мест барную стойку, видеосалон, эстраду, а также отсек с двуспальной водяной кроватью и стенами односторонней прозрачности.

[suslad 1]

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

Интересно, а что происходит если в "центральной библиотеке" уже есть файл с таким именем?

Но решен вопрос как очень быстро найти нужный библиотечный файл, на который имеется ссылка в сборке. А это немаловажно.

Я так полагаю что пересохранять нужно для получения вашей программой ссылок. Это, конечно, вариант но не панацея. А почему вы отлавливаете только ссылки в сборке? Другие игнорируете? Как потом детали/сборки открывать будете?

Решен вопрос по существованию нескольких 3D-моделей для одной записи в спецификации (уже с использованием программы для выпуска спецификации).

Можно поподробнее? Интресен ваш метод.

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

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

Например: На контракт №1001, по особой прозьбе заказчика, разместить в салоне вместо 200 посадочных мест барную стойку, видеосалон, эстраду, а также отсек с двуспальной водяной кроватью и стенами односторонней прозрачности.

Это из другой оперы -- позаказное производство. На мой взгляд на сегодняшний день эта схема довольно успешно отработана всеми ведущими поставщиками PLM-систем.

[brigval 687]

suslad

Интересно, а что происходит если в "центральной библиотеке" уже есть файл с таким именем?

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

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

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

Можно поподробнее? Интресен ваш метод.

Этот метод описан в Руководстве пользователя к моей программе Таип, которая, в том числе, выпускает и спецификации по ЕСКД.

[Странник 6]

...

Это из другой оперы -- позаказное производство. На мой взгляд на сегодняшний день эта схема довольно успешно отработана всеми ведущими поставщиками PLM-систем.

Может быть и так, но что мешает это реализовать с помощью ПИ?

[brigval 687]

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

suslad

Маленький анонс по цитируемой актуальнейшей проблеме. В следующей версии Таип 2.17, которая появится дней через 5-10, предложен вариант решения проблемы перемещения/переименования файлов Autodesk Inventor. После открытия сборки, нажатие на кнопку автоматом восстановит все ссылки на все файлы, сколько бы раз они не были переименованы и перемещены...