Как показывает практика, основные трудности внедрения PDM обусловлены тем, что на отечественных предприятиях почти всегда используется сразу несколько зачастую очень разнородных CAD-систем. И связано это не только с тем, что внедрение CAD-систем, как правило, происходит значительно раньше внедрения PDM-системы, но и с экономической целесообразностью. Действительно, технолог, выполняющий эскизы для технологических процессов, вряд ли нуждается в мощной 3D-системе, а вот разработчику крупных сборочных единиц или деталей со сложной геометрией без нее никак не обойтись. Сегодня практически все подобные CAD-системы имеют функционал, позволяющий работать со встроенными или внешними базами данных, вести состав изделия, выпускать чертежи и конструкторские спецификации, но каждая делает это по-своему. Именно по этой причине переход к единой PDM-системе весьма затруднителен, а если учесть большой объем накопленных конструкторских данных из разнородных CAD-систем, которые также необходимо использовать и поддерживать, то мечта о внедрении единой PDM может и вовсе показаться несбыточной. Тем более что функции современной PDM-системы далеко не ограничиваются управлением конструкторскими данными. В ее задачи, как правило, входит и обработка данных, полученных с использованием CAM-систем, и управление технологической подготовкой производства, и ведение технологического состава для учета особенностей технологии сборки изделия, и управление проектами и работами, а зачастую еще и получение огромного количества ведомостей и документов, основанных на конструкторско-технологической информации и позволяющих организовать производство. Например, отделу снабжения требуются ведомости для приобретения необходимых покупных изделий, производственно-техническому отделу — материалы, позволяющие сформировать производственный состав и в зависимости от объема и сроков заказа запланировать производство. И все это взаимодействие должно происходить в единой информационной среде — PDM-системе, агрегирующей в себе необходимую информацию в режиме реального времени. Поэтому процесс встраивания нескольких CAD-систем в единую информационную среду PDM-системы может оказаться очень сложно реализуемой задачей.
Таким образом, основной проблемой, которую предстояло решить команде разработчиков TechnologiCS, стала унификация функциональности интеграции таким образом, чтобы конструктор мог решать задачи ведения состава изделия и хранения документов в единой базе данных независимо от того, в какой CAD-системе он работает. Такая задача решалась в TechnologiCS-PDM и ранее (CADmaster,
С учетом многолетнего опыта системной интеграции, первоначально для решения поставленной задачи разработчиками TechnologiCS был выработан список необходимых условий:
Рассмотрим более подробно приведенные выше условия на примере реализованного механизма интеграции CAD-систем (Autodesk Inventor и SOLIDWORKS) с PDM-системой TechnologiCS.
От версии к версии как CAD-, так и PDM-системы наращивают свой инструментарий, в том числе расширяется функционал API (набор готовых классов, процедур, функций, структур и констант, предоставляемых приложением). Очень важно, чтобы после выхода новой версии программного обеспечения ранее реализованные возможности API оставались актуальными и работоспособными. В противном случае после каждого обновления ПО придется повторно прорабатывать процедуру интеграции. Кроме того, без поддержки CAD-системой интерфейсной надстройки попросту невозможно реализовать полноценную интеграцию (рис. 1 и 2).
Наличие API-функций по созданию, обмену и синхронизации свойств и атрибутивной информации файлов CAD-системы является одним из основополагающих требований по интеграции с PDM-системой. В CAD-системе должен быть реализован понятный и прозрачный функционал API, который позволит читать/изменять значения базовых свойств файла CAD-системы и создавать дополнительные свойства.
Кроме того, следует отметить, что ключевым требованием является однократный ввод пользователем такой информации, как обозначение/наименование изделия, вид документа и его суффикс. В дальнейшем эта информация должна автоматически обрабатываться PDM-системой и при создании электронного документа, и при формировании состава изделия.
Таким образом, в механизме обмена атрибутивной информацией PDM-системы должны быть доступны настройки соотношения свойств файла CAD-системы и атрибутивной информации соответствующего документа в PDM-системе (рис. 3). В противном случае процесс обмена и синхронизации будет затруднен.
Как известно, файл 3D-модели хранит в себе список входящих в него файлов (компонентов 3D-модели), которые требуются для его корректного открытия и последующей работы в CAD-системе. Рассмотрим структуру связей входящих файлов на примере файла 3D-модели сборочной единицы (рис. 4).
В зависимости от принятой на предприятии модели ведения проектной документации, в PDM-системе могут быть реализованы разные способы хранения данных 3D-модели. Рассмотрим один из самых востребованных. Как видно из рис. 5, здесь каждый файл является документом PDM-системы, что предоставляет следующие преимущества:
Таким образом, API CAD-системы должно предоставлять информацию о структуре 3D-модели, чтобы в процессе загрузки данных в PDM-систему автоматизированно устанавливались соответствующие связи между документами. В дальнейшем эта информация позволит автоматизированно выгружать необходимые документы из PDM-системы для корректного открытия файла 3D-модели.
Также следует отметить, что наличие вариативности (исполнений) в 3D-модели может существенно изменять ее структуру вложенных файлов. Вся информация также должна быть доступна через API CAD-системы.
Для проработки нескольких вариантов конструкции изделия, а также внесения изменений в конструкторскую документацию в PDM-системе должен существовать функционал ведения версий электронных документов. И тут важной задачей для PDM-системы является умение загружать/выгружать и корректно обрабатывать новые версии файлов компонентов 3D-модели в контексте работы со всей 3D-моделью в целом.
Как было сказано ранее, полученные через API CAD-системы данные о структуре модели, количестве компонентов, их вариативности и прочих свойствах могут быть использованы для автоматизированного формирования состава изделия в PDM-системе (рис. 6).
В итоге все это позволит конструктору оперативно получить электронную спецификацию в PDM-системе, агрегировать ее с соответствующими электронными документами и, в конечном счете, получить конструкторский состав изделия — так называемую итоговую спецификацию (рис. 7).
Данная информация будет доступна всем последующим участникам процесса подготовки и запуска изделия в производство.
В итоге нашими специалистами был разработан универсальный инструмент, позволяющий интегрировать разные CAD-системы в рамках единой PDM, имеющий единый интерфейс и обеспечивающий единые принципы обмена данными между системами. Что это дает? Прежде всего — возможность, работая в разных CAD-системах, формировать документы и управлять ими, а также унифицированно вести состав изделия, оставаясь в рамках единой базы данных. Все эти факторы позволяют существенно повысить уровень качества конструкторской подготовки, сократить общий цикл подготовки производства и достичь положительного экономического эффекта.