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

[suslad 1]

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

Я, конечно, очень рад за Таип 2.17, но:

1. Это реализовано во всех известных мне PDM-ах (я бы сказал это условие №1).

2. Это никак не связано с темой топика.

[brigval 690]

рад за Таип

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

Это реализовано во всех известных мне PDM-ах

Автомтизация выпуска ИИ и внесение изменений по ЕСКД одно из самых слабых мест PDM. Да и не работает основная масса конструкторов в PDM-ах. А работу уже надо делать "тут и сейчас".

Это никак не связано с темой топика

Во-первых, на тему переименования файлов первым заговорили Вы.

Во-вторых, правильно сделали, потому что это действительно актуальный вопрос, в том числе и при выпуске ИИ и ПИ.

Вероятно, эта тема подтолкунула меня к поиску своего решения.

Но если Вы считаете, что я ответил не по Вашей Теме, тогда уж извините.

[Route 2]

Автомтизация выпуска ИИ и внесение изменений по ЕСКД одно из самых слабых мест PDM.

А можно по подробнее об "одном из самых слабых мест PDM"? Что значит в данном контексте "внесение изменений по ЕСКД"?

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

Изменено 15 марта 2009 пользователем Route

[brigval 690]

А можно по подробнее об "одном из самых слабых мест PDM"? Что значит в данном контексте "внесение изменений по ЕСКД"?

Это значит, что есть правила внесения измений, описанные в стандартах ЕСКД. А проектируемые системы PDM игнорируют эти правила.

[Route 2]

Это значит, что есть правила внесения измений, описанные в стандартах ЕСКД. А проектируемые системы PDM игнорируют эти правила.

Можно попросить Вас о большей конкретике? Каким образом правила внесения измений, описанные в стандартах ЕСКД игнорируются PDM-системами? Приведите ряд примеров ЕСКД-правил, а также пример игнорирования данных правил PDM-системами? Ведь для меня, как для конструктора, это очень важно!

Изменено 16 марта 2009 пользователем Route

[brigval 690]

Ведь для меня, как для конструктора, это очень важно!

Если Вы конструктор, то знаете требования ЕСКД к выпуску ИИ.

Суда по Вашим словам в соседней ветке, Вы довольно хорошо знаете возможности PDM:

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

А теперь Ваш вопрос:

Каким образом правила внесения измений, описанные в стандартах ЕСКД игнорируются PDM-системами?

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

Назовите мне коммерческую PDM, поддерживающую работу по ЕСКД с групповыми документами и поддерживающую работу с ИИ, ПИ, ДПИ, ДИ и ПР.

И я тоже буду знать о такой.

[Route 2]

Если Вы конструктор, то знаете требования ЕСКД к выпуску ИИ.

Суда по Вашим словам в соседней ветке, Вы довольно хорошо знаете возможности PDM:

А теперь Ваш вопрос:

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

Назовите мне коммерческую PDM, поддерживающую работу по ЕСКД с групповыми документами и поддерживающую работу с ИИ, ПИ, ДПИ, ДИ и ПР.

И я тоже буду знать о такой.

Вы наверное меня не поняли я прошу именно Вас ответить на вопросы: Каким образом правила внесения измений, описанные в стандартах ЕСКД игнорируются PDM-системами? Приведите ряд примеров ЕСКД-правил, а также пример игнорирования данных правил PDM-системами?

Ваше мнение для меня действительно важно!

Рекламировать конкретные PDMсистемы не буду.

На Ваш вопрос отвечаю: Все коммерческие PDM-системы где есть такие понятия как "Бизнес-процесс", "состояния элементов или их стадии" могут поддерживать ИИ, ПИ, ДПИ, ДИ и пр.

[brigval 690]

Рекламировать конкретные PDMсистемы не буду

Здесь можете рекламировать. Здесь целые форумы под них выделены.

Вот здесь, например, ни слова об ИИ и т.п.

<noindex>http://www.solidworks.ru/products/swr-pdm/...m_capabilities/</noindex>

[Route 2]

Здесь можете рекламировать. Здесь целые форумы под них выделены.

Вот здесь, например, ни слова об ИИ и т.п.

<noindex>http://www.solidworks.ru/products/swr-pdm/...m_capabilities/</noindex>

Вот прям по Вашей ссылке:

"Управление версиями.

Отслеживание изменений документов и изделий выполнено по двухуровневой схеме версия-итерация. Версии используются для проработки альтеранитвных вариантов и фиксации изменений, а итерации обеспечивают возможность возврата к предыдущим состояниям (Undo) и коллективную работу над моделями."

Это есть во всех комерческих PDM-системах, даже в SWR.

Изменено 16 марта 2009 пользователем Route

[DGroot 8]

Здесь можете рекламировать. Здесь целые форумы под них выделены.

Вот здесь, например, ни слова об ИИ и т.п.

<noindex>http://www.solidworks.ru/products/swr-pdm/...m_capabilities/</noindex>

К сожалению приведенный Вами brigva пример не самый удачный. Я просто близко знаком с авторами SWR-PDM в С.Петербурге. И для них ГОСТ - все равно что библия. (Да простят меня за невольную рекламу).

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

Вот и приходится "подкручивать", "подвинчивать" - т.е. дорабатывать Windchill до соответствия ЕСКД.

Так вот в такого рода системах извещения об изменении скорее процесс чем документ.

Т.е. чтобы наилучшим образом (при внедрении любой пришлой) разобраться хорошо бы ознакомиться с нормативной базой от которой отталкивались ее авторы. Затем решить, что нужно изменить в системе организации проектирования, чтобы наилучшим образом соответствовать требованиям пришлого продукта с одной стороны (иначе неравен час потеряешь все те преимущества, на которые рассчитывал и понесешь не меренные убытки) , и что (если ну ОЧЕНЬ ХОЧЕТСЯ и кажется что НУЖНО и ВОМОЖНО) попытаться перенастроить в самой PDM.

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

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

[brigval 690]

Вот прям по Вашей ссылке:

"Управление версиями.

Отслеживание изменений документов и изделий выполнено по двухуровневой схеме версия-итерация. Версии используются для проработки альтеранитвных вариантов и фиксации изменений, а итерации обеспечивают возможность возврата к предыдущим состояниям (Undo) и коллективную работу над моделями."

Это есть во всех комерческих PDM-системах, даже в SWR.

И что в Вашей цитате сказано про выпуск Извещений об изменении по ЕСКД? Вы сами-то прочтите еще раз, что цитируете.

DGroot

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

Внесение изменений - это процесс. И сделан он должен быть по ЕСКД, коль это требование Заказчика.

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

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

Я знаю случаи, когда отечественные интеграторы, получив деньги и окунувшись в мир особенностей предприятия, просто теряли к нему интерес, со всеми вытекающими отсюда последствиями. А у западных разработчиков PDM, думаю, и своих проблем полно. Запад - не панацея.

И для них ГОСТ - все равно что библия

Этого, к сожалению, не достаточно.

Еще нужны специалисты, которые понимают ЕСКД и могут помочь направить программеров по нужному пути и еще нужны базовые предприятия, позволяющие использовать свой исходный нехилый материал для разработки и всестороннего тестирования отечественой PDM. А не просто "заказчик сказал, а мы сделали, что он просил, сам и виноват - не мог сформулировать правильно".

[Route 2]

И что в Вашей цитате сказано про выпуск Извещений об изменении по ЕСКД? Вы сами-то прочтите еще раз, что цитируете.

DGroot

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

Внесение изменений - это процесс. И сделан он должен быть по ЕСКД, коль это требование Заказчика.

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

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

Я знаю случаи, когда отечественные интеграторы, получив деньги и окунувшись в мир особенностей предприятия, просто теряли к нему интерес, со всеми вытекающими отсюда последствиями. А у западных разработчиков PDM, думаю, и своих проблем полно. Запад - не панацея.

Этого, к сожалению, не достаточно.

Еще нужны специалисты, которые понимают ЕСКД и могут помочь направить программеров по нужному пути и еще нужны базовые предприятия, позволяющие использовать свой исходный нехилый материал для разработки и всестороннего тестирования отечественой PDM. А не просто "заказчик сказал, а мы сделали, что он просил, сам и виноват - не мог сформулировать правильно".

Если контекст "Отслеживание изменений документов и изделий выполнено по двухуровневой схеме версия-итерация" Вам ни чего не говорит, тогда понятно почему Вы уже наверное третий раз не можете ответить на мои вопросы: Каким образом правила внесения измений, описанные в стандартах ЕСКД игнорируются PDM-системами? Приведите ряд примеров ЕСКД-правил, а также пример игнорирования данных правил PDM-системами?

А по поводу слов о западе, хочется сказать словами увиденными на одном из форумов, словами Жванецкого:

"Иначе, чем нужно

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

Ну и жили не так, как все, хотя и хуже.

А сейчас живем не просто не так, как все, а иначе, чем нужно.

Это отдает закоренелостью.

И чревато невозможностью пригласить педагога со стороны.

А разобраться может только тот, кто только здесь.

Но он же должен взглянуть на это все со стороны.

Это тоже должно быть не так, как у всех, хотя и так, как нужно.

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

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

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

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

Просьба ко всем оставшимся: если кто увидит выход или догадается, звоните по мобильному 760-32-31 круглосуточно. Я или жена всегда у телефона. Отсутствие определителя гарантирует анонимность."

Изменено 17 марта 2009 пользователем Route

[brigval 690]

Если контекст "Отслеживание изменений документов и изделий выполнено по двухуровневой схеме версия-итерация" Вам ни чего не говорит

Если в описании системы прямо не сказано о выпуске ИИ по ЕСКД, то в контексте уже можно не копаться: там этого нет.

Я ответил на Ваши вопросы и даже привел пример, а Вы начали спорить. Зачем тогда спрашивать? Только для того, чтоб процитировать известного Юмориста, не имеющего к технике никакого отношения? Вы могли бы это сделать и не задавая вопросы на техническом форуме : ))

[Route 2]

Если в описании системы прямо не сказано о выпуске ИИ по ЕСКД, то в контексте уже можно не копаться: там этого нет.

Я ответил на Ваши вопросы и даже привел пример, а Вы начали спорить. Зачем тогда спрашивать? Только для того, чтоб процитировать известного Юмориста, не имеющего к технике никакого отношения? Вы могли бы это сделать и не задавая вопросы на техническом форуме : ))

Что то я не пойму на каких основаниях у Вас такие суждениях о PDM-системах? Вы, простите, вообще какие нибудь системы PDM изучали? Ветка в форуме называется "Все вопросы о PDM"

Я начал спорить..., а форум то на что?

Вы своими размытыми понятиями "о выпуске ИИ по ЕСКД" ни кому ни чего не объяснили. Выпуск ИИ это действие, а форма действия может быть любая...в том числе и ГОСТовская описанная бизнес-процессами PDM. Я пока не вижу коллизий в вопросе выпуска ИИ и др. И в PDM по ГОСТ.

По поводу цитаты.... По моему цитата очень уж подходит к существующей действительности на предприятиях нашей необъятной страны.

[Елена 116]

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

[Route 2]

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

Но эти изменения будут записаны не техническим, сжатым, отбражающим суть изменений языком,

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

Да, в PDM конечно возможно формирование ИИ по регистрации изменений вносимых конструктором в изделие. А для возможности описания изменения ИИ техническим языком, нужно дать конструктору подготовленное ИИ и пусть пишет там что хочет. Вот с этого момента можно (если конечно надо) превратить ИИ в ПИ и т.п.

[Странник 6]

Да, в PDM конечно возможно формирование ИИ по регистрации изменений вносимых конструктором в изделие. А для возможности описания изменения ИИ техническим языком, нужно дать конструктору подготовленное ИИ и пусть пишет там что хочет. Вот с этого момента можно (если конечно надо) превратить ИИ в ПИ и т.п.

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

[Route 2]

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

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

[suslad 1]

Понятное дело. rolleyes.gif Да я про суть дела, про то что извещение то по сути то одно. А вот стадий много.

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

[Route 2]

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

Если коротко:

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

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

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

При проведении ИИ, один элемент PDM меняется на его ревизию. ИИ также , как того и требует ГОСТ, составляют на один или несколько элементов PDM. Одно ИИ составляют на несколько элементов PDM при условии одновременного проведения изменений по всем изменяемым элементам.

По ГОСТ:

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

В копии документов, находящихся в производстве, допускается вносить изменения на основании предварительного извещения (ПИ) (приложение 5).

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

Предложения об изменении (ПР) (приложение 7) рекомендуется оформлять на предприятии - держателе копий на формах ИИ и направлять их для дальнейшего оформления предприятию - держателю подлинников."

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

С любого извещения можно будет сформировать отчеты по ГОСТ.