PDM для электронщиков

[inord 0]

Уважаемый vian, а Вы в Мегратеке эту тему обсуждали? К соседям по этажу заглядывали?

[brigval 690]

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

Иногда на форумах ищут ГОСТ для работы в AutoCAD, ГОСТ для работы в P-CAD.

Уважаемый vian, Ваш вопрос, извините, из этой же категории. Если Вы работаете по ЕСКД, то должны знать, что комплект конструкторской документации неделим.

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

Если Вам нужна система, обслуживающая чистые кристаллы, то, видимо об и надо было указать в вопросе. Если нет, то Странник-а нельзя не поддержать: даже самая простая микросхема требует "механических" чержей. А это уже не чистая электроника с точки зрания КД. И система документооборота должна быть не для-электонщиков. О чем я в этом посте и расстарался написать.

Вероятно, Ваше руководство поставило перед Вами некорректную задачу: поиск PDM для электронщиков.

Уважаемый vian, а Вы в Мегратеке эту тему обсуждали?

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

Уважаемый vian, если Вы работаете в Менторе, могу предложить рассмортеть вопрос о доработке программы <noindex>Генератор перчней</noindex>, заточенной под P-CAD, для вывода перечня элементов, спецификации, ведомости покупных изделий и КРР из Ментора. Все максимально по ЕСКД. Нормоконтроль доволен.

[VladS 0]

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

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

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

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

По крайней мере, решится вопрос с поддержкой ЕСКД.

Что же касается специфических систем управления проектами и данными для ECAD, то те из них, что мне приходилось видеть, имели неплохой функционал в части управления библиотеками элементов, связями между данными ECAD, но не очень хорошо управляли файлами (в части разграничения доступа, удобного поиска и т.п.) и не имели практически никаких средств workflow. Более того, сами разработчики этих систем часто рекомендуют встраивать их в комплексные PLM-решения (В частности, фирма Mentor Graphics пишет про свой модуль DMS следующее: "As an engineering solution DMS plugs into enterprise systems").

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

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

То есть, по теме и по сути сказать нечего.

[Далее удалено по просьбе Доброго модератора ART]

Изменено 1 июня 2009 пользователем VladS

[brigval 690]

Но чтобы работа с ними была удобной для всех сотрудников (как разрабатывающих электронику, так и механическую часть).

Категорически поддерживаю! Особенно, если и разработчиков ПО не забудем.

[VladS 0]

Категорически поддерживаю! Особенно, если и разработчиков ПО не забудем.

Разумеется не забудем, там ведь свои заморочки.

Хотя если речь идет о соответствии ИСО 12207, то это не самое страшное (под этот стандарт можно почти любую систему "подвести", настолько он неконкретный).

Изменено 28 мая 2009 пользователем VladS

[inord 0]

Уважаемый brigval,

я порекомендовал vian пообщаться с официальными партнерами Mentor Graphics ( и их соседями по этажу), а Вы как-то сразу отсоветовали и порекомендовали обратиться к Вам за свой разработкой, конкуренция-конкуренцией, но надо быть более сдержанным

[spacekon 0]

С 2004 или даже 2003 года Search практически не приблизился к уровню PDM системы для проектно-конструкторских работ, прежде всего это касаемо упоминавшихся выше версионности и методики погружения моделей в систему. По поводу же пользовательского интерфейса этой системы волками воют и сами айтишники. Особо стоит отметить также иерархическую структуру Imbase и общий уровень надёжности интермеховской продукции, в том числе при установке и обновлении версий системы.

Держите меня четверо... Ну что Вы лепите! В общем Странник еще тот Sеarch-а ненавистник.

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

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

Add-Inn к ECAD в Seach-e конечно же нету, как и возможности хранения общей библиотеки проектирования SolidWorks.

Add-in к ECAD, в частности к Expedition PCB маршрут DxD, кончно же есть, что позволяет и проекты хранить и структуру изделия получать с соответсвующими документами (ПЭ, СП, ВП).

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

В общем можно констатировать, что Search вполне конкуретно способная система. Что хуже или лучше: Search или Lotsia, по моему одного порядка - трудности при внедрении будут и там и там. Единственно, что не знаю как у Lotsia интеграция с Ментором, а так по моему системы очень близки (как мерседес и бмв ). Изменено 30 мая 2009 пользователем spacekon

[Странник 6]

Держите меня четверо... ;-) Ну что Вы лепите! В общем Странник еще тот Sеarch-а ненавистник. :-)

...

А вот вы извольте ка подкрепить свои заявления скринами, для начала по части версионности.

Задачка такова, модель имеет:

-3 версии (надо же силы расставлять и считать);

-10...15 итераций в каждой из версий (ибо требования меняются, а выкинуть жалко)

-7 конфигураций в каждой итерации, из них 4 нужны для сборки, но не для спецификации.

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

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

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

Add-in к ECAD, в частности к Expedition PCB маршрут DxD, кончно же есть, что позволяет и проекты хранить и структуру изделия получать с соответсвующими документами (ПЭ, СП, ВП).

Срины и ссылку в студию!

P.S. крови не жажду, но меру таки знать надо.

[brigval 690]

Уважаемый brigval,

я порекомендовал vian пообщаться с официальными партнерами Mentor Graphics ( и их соседями по этажу), а Вы как-то сразу отсоветовали и порекомендовали обратиться к Вам за свой разработкой, конкуренция-конкуренцией, но надо быть более сдержанным

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

В функции компании Megratec входит маркетинг, продажа, техническая и административная поддержка и сопровождение программных продуктов Mentor Graphics. С этой целью создано два технических центра, специализирующихся, соотвественно, в области средств проектирования систем и печатных плат и в области проектирования интегральных схем.

Нет ни слова об электронном документообороте.

Кроме того, в силу некоторых причин, мне пришлось побывать в этой компании около месяца назад. Там мне была показана программа на макросах для получения ПЭ3, о которой я и сообщил выше.

Это первое.

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

Как Вы думаете, для чего вводится АПИ в программы? Давно известно, всякие примочки к большому программному продукту, позволяют распространять его более успешно. И если появится программа, позволяющая выводить из Ментора перечень, спецификацю, ВП, КРР по ЕСКД, то это пойдет бизнесу Мегратека только на пользу, а не наоборот.

Отсюда вывод. Уважаемый inord, прежде чем советовать людям потратить их время без пользы, а еще, прежде чем сделать мне замечание на форуме, необходимо взвесить все ЗА и ПРОТИВ. А потом уже писать.

Поскольку я с Вами не знаком, то в моем этом посте нет ничего личного. В нем я постарался объяснить свою позицию по поводу ранее сказаного. Только и всего.

Если Вам лично что-то не понравилось в этом моем сообщении, пишите в личку, как рекомендует Добрый модератор ART. Обсудим.

[spacekon 0]

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

Если я правильно посчитал, то это около 300 вариантов - плодовитый конструктор однако... 15 раз требования (я так понимаю ТЗ) менять это тоже сильно... Если не секрет у Вас что за отрасль?

Что касается сути вопроса: навыпускать столько вариантов на один номер теоретически наверное можно либо в виде версий, либо в виде исполнений, но в реале делать, по моему, такое не нужно - кто через год разбереться в этих десятках вариантах одного и того же... Тем более, что в конечном варианте у Вас будет ОДНО утвержденное ТЗ.

Относительно SW: при занесении в серч можно управлять как эта сборка/деталь будет занесена в архив.

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

Так нам и нужны реальные процессы, разве нет? ;-) Штатными средствами как раз процесс и будет попадать к одному и томуже проверяющему. :-) Можно настроить чтоб к разным ходил без применения скриптов. Скрипты весчь нужная и полезная (и достаточно простая в реализации) если нужно сделать что-то уникальное под конкретные задачи или автоматизировать рутинные операции.

Срины и ссылку в студию!

Цитата из документации:

Интеграция c системой Mentor Graphics (MG) - с проектами, выполненными в системе DX Designer.

Для схем выполняется сканирование и строится состав.

При наличии параметра проектной связи "Поз. обозначение" в него будут записываться значения атрибута Refdes элементов схемы.

Для схем MG можно генерировать перечни элементов (Команда в меню "Сервис").

Изменено 30 мая 2009 пользователем spacekon

[Странник 6]

Если я правильно посчитал, то это около 300 вариантов - плодовитый конструктор однако... 15 раз требования (я так понимаю ТЗ) менять это тоже сильно... Если не секрет у Вас что за отрасль?

Что касается сути вопроса: навыпускать столько вариантов на один номер теоретически наверное можно либо в виде версий, либо в виде исполнений, но в реале делать, по моему, такое не нужно - кто через год разбереться в этих десятках вариантах одного и того же... Тем более, что в конечном варианте у Вас будет ОДНО утвержденное ТЗ.

Приведённый мною пример по сути своей банален и даже упрощён. Реально бывает и 6...7 вариантов компоновки, каждый из которых пошагово просматривается на предмет годности по всему набору критериев. А количество конфигураций зачастую определяется потребным для компоновки числом промежуточных положений составных частей изделия. Думаете с проста был затеян разговор по этой ссылке?

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

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

Относительно SW: при занесении в серч можно управлять как эта сборка/деталь будет занесена в архив.

Можно флаги расставить, только это ещё дорабатывать будет надо под реальные потребности.

Так нам и нужны реальные процессы, разве нет? ;-) Штатными средствами как раз процесс и будет попадать к одному и томуже проверяющему. :-) Можно настроить чтоб к разным ходил без применения скриптов. Скрипты весчь нужная и полезная (и достаточно простая в реализации) если нужно сделать что-то уникальное под конкретные задачи или автоматизировать рутинные операции.

Нет, я могу это утверждать, ибо всё прошёл на собственном опыте.

Группа НОРМОКОНТРОЛЬ состоит пусть из 8 сотрудников и 2 начальников, нужно что бы документ на втором предъявлении попал к тому же контролёру, что проверял его и в первый раз. Как это сделать?

Вариант 1 - направить докУмент изначально к начальнику, что бы тот назначил ответственного (экранная форма + пользовательская переменная).

Вариант 2 - создавать роли (чего Search не умеет).

Вариант 3 - написать 1 строчку на скрипте.

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

Если мы всё замкнём на начальника, то это тоже не хорошо... во всяком случае с его точки зрения.

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

Цитата из документации:

Интеграция c системой Mentor Graphics (MG) - с проектами, выполненными в системе DX Designer.

Для схем выполняется сканирование и строится состав.

При наличии параметра проектной связи "Поз. обозначение" в него будут записываться значения атрибута Refdes элементов схемы.

Для схем MG можно генерировать перечни элементов (Команда в меню "Сервис").

А ведь я не с проста попросил скринчик и ссылку, не сочтите за труд, пройдите по этой ссылке, а так же по этой и вот этой.

[Елена 116]

Если идет замена документа, то документ идет по тому же маршруту (в маршруте уже исполнители), если кто-то отсутствует, руководитель имеет право заменить исполнителя. Поэтому проблем попадания к тому же исполнителю нет. Это все, конечно, если маршрутизация организована правильно.

[ART 511]

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

Спасибо!

Добрый модератор ART

[Странник 6]

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

[vian 2]

Вернемся к баранам :)

Иногда на форумах ищут ГОСТ для работы в AutoCAD, ГОСТ для работы в P-CAD.

Уважаемый vian, Ваш вопрос, извините, из этой же категории. Если Вы работаете по ЕСКД, то должны знать, что комплект конструкторской документации неделим.

...

Вероятно, Ваше руководство поставило перед Вами некорректную задачу: поиск PDM для электронщиков.

...

Нет, это я просто специально так назвал топик, чтобы были понятны акценты. Я все понимаю про неделимость КД и т.п. Просто сам я - электронщик, и больше всего меня волнует моя часть работы.

Что же касается специфических систем управления проектами и данными для ECAD, то те из них, что мне приходилось видеть, имели неплохой функционал в части управления библиотеками элементов, связями между данными ECAD, но не очень хорошо управляли файлами (в части разграничения доступа, удобного поиска и т.п.) и не имели практически никаких средств workflow. Более того, сами разработчики этих систем часто рекомендуют встраивать их в комплексные PLM-решения (В частности, фирма Mentor Graphics пишет про свой модуль DMS следующее: "As an engineering solution DMS plugs into enterprise systems").

Про DMS согласен, в-общем-то.

Наверное, поэтому, да и вообще по совокупности, решено делать свою разработку. :)

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

Думаю, что положить в основу.

Пока есть два кандидата: XML и ISO 10303-210.

Про XML все понятно, а вот про STEP не очень. По результатам недолгих поисков понял, что это один многих стандартов, входящих в очень обширную группу 10303, говорят, даже, самую обширную в ISO.

Текст найти не удалось, может, кто-нибудь поделится?

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

Особенно много ссылок на стандарты этой группы, посвященные механическим САПР, а вот с электроникой (210) как-то все не очень, ссылочки какие-то староватые и т.п.

Вот и вопрос, стоит ли с ним связываться, или сразу делать на XML? Очень не хочется изобретать велосипед.

[DGroot 8]

Вот и вопрос, стоит ли с ним связываться, или сразу делать на XML? Очень не хочется изобретать велосипед.

Ну если средств больших нет не проще ли воспользоваться

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

[vian 2]

Ну если средств больших нет не проще ли воспользоваться

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

Спасибо, но - нет. У нас уже достаточно много сделано для автоматизации проектирования, и это никак не связано с указанными программами.

Сейчас пока стоит первая задача - отслеживание состава изделия. Потом будем добавлять функции.

Хочется узнать побольше про ISO 10303-210. Сам текст неплохо бы почитать, ну и программки какие-нибудь пощупать. После этого, думаю, можно будет сделать вывод о возможности его использования.

Вообще, на основе чего в PDM-ах делают деревья состава изделий?

[brigval 690]

Вообще, на основе чего в PDM-ах делают деревья состава изделий?

На сколько я в курсе, в основном - ручная набивка дерева.

Точно скажу про БрагинДок. Дерево состава КД и дерево состава изделия формируются на основе спецификаций. Без участия пользователя.

[vian 2]

На сколько я в курсе, в основном - ручная набивка дерева.

Точно скажу про БрагинДок. Дерево состава КД и дерево состава изделия формируются на основе спецификаций. Без участия пользователя.

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

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

[brigval 690]

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

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

Конечно, на основе того, чем Вы лучше владеете. Я знаю пример, когда один форумчанин принципиально хранил БД в текстовом файле. И у него все работало.

Главными вопросами являются

1 источник информации для дерева

2 способ наполнения этого источника

3 способ считывания из этого источника.

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

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