CADmaster

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

Таким образом, основной проблемой, которую предстояло решить команде разработчиков TechnologiCS, стала унификация функциональности интеграции таким образом, чтобы конструктор мог решать задачи ведения состава изделия и хранения документов в единой базе данных независимо от того, в какой CAD-системе он работает. Такая задача решалась в TechnologiCS-PDM и ранее (CADmaster, № 3/2011, c. 34−38), но опыт предыдущих внедрений показал, что сейчас мало кого интересует система, позволяющая лишь хранить разнородные файлы в виде электронных документов, обеспечивая распределенный доступ, управление правами и процессами согласования, утверждения и введения в действие. С другой стороны, как правило, глубокой интеграции достигают разработчики, имеющие собственные CAD и PDM. И это неудивительно: зная внутреннее устройство своей CAD-системы, а также имея возможность дорабатывать ее функциональность, вполне возможно добиться хороших результатов. А каким образом заставить разнородные CAD-системы работать со своей PDM как с «родной»?

С учетом многолетнего опыта системной интеграции, первоначально для решения поставленной задачи разработчиками TechnologiCS был выработан список необходимых условий:

• открытый и поддерживаемый разработчиками API CAD/PDM-системы;
• поддержка CAD-системой интерфейсной надстройки стороннего разработчика ПО;
• наличие API-функций CAD-системы по созданию, обмену и синхронизации свойств и атрибутивной информации файлов CAD-системы;
• наличие API-функций CAD-системы по управлению и передаче данных структуры 3D-модели (включая вариативность 3D-модели);
• наличие функций PDM-системы по структурированной загрузке/выгрузке, отслеживанию и управлению данными CAD-системы (нескольких CAD-систем);
• наличие функций PDM-системы по ведению версионности как всей 3D-модели изделия, так и компонентов в ее составе;
• наличие функций PDM-системы по автоматизированному формированию состава изделия на основе структуры 3D-модели с возможностью «ручной» корректировки и отслеживания изменений;
• наличие функций PDM-системы по ведению конструкторского, технологического/производственного состава изделия и его автоматизированной передаче в смежные информационные системы.

Рассмотрим более подробно приведенные выше условия на примере реализованного механизма интеграции CAD-систем (Autodesk Inventor и SOLIDWORKS) с PDM-системой TechnologiCS.

Требования к API и интерфейсной части интегрируемой системы

От версии к версии как CAD-, так и PDM-системы наращивают свой инструментарий, в том числе расширяется функционал API (набор готовых классов, процедур, функций, структур и констант, предоставляемых приложением). Очень важно, чтобы после выхода новой версии программного обеспечения ранее реализованные возможности API оставались актуальными и работоспособными. В противном случае после каждого обновления ПО придется повторно прорабатывать процедуру интеграции. Кроме того, без поддержки CAD-системой интерфейсной надстройки попросту невозможно реализовать полноценную интеграцию (рис. 1 и 2).

Рис. 1. Пример реализации интерфейсной надстройки TechnologiCS в Autodesk Inventor

Рис. 2. Пример реализации интерфейсной надстройки TechnologiCS в SOLIDWORKS

Требования к работе с атрибутивной информацией файлов CAD-системы

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

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

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

Рис. 3. Пример реализации интерфейса обмена атрибутами в TechnologiCS

Особенности хранения информации о структуре 3D-модели в PDM-системе

Как известно, файл 3D-модели хранит в себе список входящих в него файлов (компонентов 3D-модели), которые требуются для его корректного открытия и последующей работы в CAD-системе. Рассмотрим структуру связей входящих файлов на примере файла 3D-модели сборочной единицы (рис. 4).

Рис. 4. Пример структуры файлов 3D-модели

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

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

Рис. 5. Способ хранения данных 3D-модели в PDM-системе

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

Также следует отметить, что наличие вариативности (исполнений) в 3D-модели может существенно изменять ее структуру вложенных файлов. Вся информация также должна быть доступна через API CAD-системы.

Версионность и управление данными на уровне PDM-системы

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

Формирование состава изделия в PDM-системе на основе данных 3D-модели

Как было сказано ранее, полученные через API CAD-системы данные о структуре модели, количестве компонентов, их вариативности и прочих свойствах могут быть использованы для автоматизированного формирования состава изделия в PDM-системе (рис. 6).

Рис. 6. Формирование состава изделия на основе данных 3D-модели в редакторе спецификаций TechnologiCS

В итоге все это позволит конструктору оперативно получить электронную спецификацию в PDM-системе, агрегировать ее с соответствующими электронными документами и, в конечном счете, получить конструкторский состав изделия — так называемую итоговую спецификацию (рис. 7).

Рис. 7. Конструкторский состав изделия в TechnologiCS

Данная информация будет доступна всем последующим участникам процесса подготовки и запуска изделия в производство.

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

Скачать статью в формате PDF — 1.81 Мбайт