Введение

Меня зовут Чугунов Сергей. Я больше 10 лет занимаюсь конструированием медицинских рентгенодиагностических комплексов и являюсь главным конструктором нескольких серийно поставляемых систем. Одна из моих зон ответственности — внедрение лучших практик работы с системой автоматизированного проектирования или сокращенно CAD. После общения с коллегами из других компаний у меня сложилось впечатление, что многие испытывают проблемы с хранением и поддержкой актуальности документации. Системный же подход к работе с CAD вообще развит у единиц небольших и средних фирм-разработчиков.

Электронный макет

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

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

Зачем нужен Product Data Management (PDM)

Для хранения и управления этим множеством документов существует PDM – Product Data Manager. Его основной функцией является хранение и обеспечение жизненного цикла документации.

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

1. Создание и редактирование спецификаций, формирование на основе спецификации дерева состава изделия.

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

3. Хранение справочников допустимых к применению материалов, стандартных и покупных изделий, справочников обозначений.

4. Создание технологической структуры изделия на базе конструкторской структуры изделия.

5. Формирование заказов на производство или закупку.

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

Как организовано хранение документов в PDM

В используемой нами PDM системе есть две сущности — объект и документ. Объектом является любая единица, которая может быть включена в дерево состава изделия – сборка, деталь или покупное изделия. Документ же является файлом стороннего ПО, который хранится в PDM и может быть связан с несколькими объектами. Например, по одному чертежу может быть изготовлено несколько различных деталей, отличающихся размерами – в системе конструкторской документации такие детали называются исполнениями. В PDM этот чертёж хранится как один документ, но каждому исполнению соответствует свой объект. Также бывают объекты, для которых в PDM отсутствуют документы – например крепежные элементы, изготавливаемые по стандартам, или покупное изделие.

К документам относятся: спецификации, 3D модели, чертежи, схемы и т.п. Для контроля доступа все документы распределены по архивам.

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

В PDM есть возможность хранить ассоциированные с документом файлы, а поскольку не у всех сотрудников может быть установлена необходимая для просмотра CAD система, у нас принято с каждым документом, имеющим бумажный эквивалент (спецификация, чертёж, схема), хранить его распечатку в pdf.

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

Организация взаимодействия CAD и PDM

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

Для их хранения этих данный в PDM выбрана следующая логика: есть три типа документов – электронная модель сборочной единицы, сборочный чертеж и электронная модель детали. Для чертежа детали отдельного документа в PDM нет, было принято решение хранить чертёж детали в ассоциированных с документом детали файлах. Это связано с тем, что согласно единой системе конструкторской документации ЕСКД в спецификацию вносится объект детали, и внести в неё отдельный документ чертежа детали невозможно, таким образом и при прочих системах хранения будет либо нарушена логика регламентирующих стандартов, либо будет потерян доступ к чертежу детали из электронной структуры изделия.

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

Что касается документов, имеющих несколько исполнений, то это реализовано следующим образом: в CAD системе есть конфигурации модели. Для каждой конфигурации есть свой набор метаданных. Туда записывается флаг, который определяет следующие состояния:

1.       На основе этой конфигурации необходимо создать объект в PDM.

2.       Для этой конфигурации уже есть объект в PDM.

3.       PDM должна проигнорировать эту конфигурацию.

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

Ранее я уже упоминал, что существует ряд объектов, для которых в PDM отсутствуют ассоциированные с ними документы. Если для этих объектов требуются 3D-модели, как в случае крепежа или покупных изделий, модель помещается на общем сетевом диске с доступом для сотрудников только для чтения, в метаданных этой модели прописывается флаг, что для неё уже существует объект в PDM. Разработчик вставляет эту модель в свою сборку строго с сетевого диска, не копируя на локальных компьютер.

Также существуют такие объекты, которые меняют свою форму в зависимости от сборки, куда их устанавливают. Это в основном касается кабелей и упругих деталей типа пружин, уплотнителей и т.п. Для таких деталей и сборок в PDM создаётся модель в номинальном положении, а в модели вышестоящей сборки создаётся её виртуальны клон, ассоциированный с помощью флага с данным документом. Виртуальная модель в CAD системе – модель, для которой отсутствует отдельный документ, она сохранена только в файле вышестоящей сборки. Таким образом мы с одной стороны добиваемся корректного отображения таких деталей в наших сборочных единицах, с другой стороны, обеспечиваем взаимосвязь дерева состава 3D модели с деревом состава в PDM.

В результате мы добиваемся того, чтобы дерево состава 3D-модели полностью соответствовало дереву состава в PDM по разделам сборочные единицы, детали, стандартные, прочие изделия и материалы. Для PDM у нас написан ряд плагинов, которые сортируют дерево 3D модели по дереву состава спецификации, сравнивают составы модели и спецификации, автоматически проставляют на чертеже в CAD-системе позиции по созданной в PDM спецификации.

Организация совместной работы над документацией

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

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

Заключение

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