Методология RGD
Методология Relational Generative Design (RGD) пока еще не имеет устоявшегося терминологического аналога в русском языке. Ее можно определить как «Параллельное разделенное по стадиям проектирование с использованием и накоплением знаний». RGD — одно из решений, составляющих основу современного автоматизированного проектирования, которые реализованы в системе CATIA V5. Перечислим основные принципы методологии RGD.
Процесс проектирования разделяется на стадии. Каждой стадии соответствуют специализации пользователей по ролям, по представлениям данных, по видам моделей, по правам доступа. переходе к следующей стадии модели наследуют только те данные, которые необходимы для работы на этой стадии. Ограничение по ролям обеспечивает для каждого пользователя ролевой группы видимость только тех данных предыдущих стадий, которые специально определены как необходимые на текущей стадии. Сохраняется ассоциативная ссылочность на данные предыдущих стадий проектирования.
Таким образом, обеспечивается возможность отслеживания любых изменений, выполненных на предыдущих стадиях, конфиденциальность информации и возможность работы с максимально облегченным представлением моделей на каждой стадии. При этом гарантируется целостность проекта в целом — все причинно следственные связи отслеживаются по ссылкам. Общая схема методологии RGD приведена на рис. 1.
Разделение на стадии зависит от специфики конкретной прикладной области или от специфики предприятия. В случае рассматриваемого пилотного проекта была выбрана следующая схема разделения (рис. 2):
стадия инженерного моделирования (Engineering Design, ED); стадия геометрического моделирования (Shape Definition, SD); стадия определения детали как компонента сборки (Part Definition, PD); стадия определения системно - агрегатной (функциональной) сборки (Functional DMU Definition); Стадия определения технологической сборки (Manufacturing DMU Definition).
На каждой стадии имеются свои особенности организации работы конструктора. Опишем теперь общие принципы, присущие всем стадиям.
Наброски системного решения
Современные проекты обычно характеризуются жесткими ограничениями по времени, кооперативностью, удаленностью и «непохожестью» участников. Для выполнения таких проектов требуется PLM-решение, позволяющее управлять хранением и доступом к информации; управлять составом и структурами изделия; поддерживать логические связи и ассоциативности; обеспечивать многофункциональную среду проектирования, предполагающую быстрый, легкий и надежный обмен проектными данными. Кроме того, в таком решении должен быть обеспечен открытый интерфейс к ERP-системе, а также в другие PDM.
Модели сложных изделий с длительным жизненным циклом должны содержать описание всех стадий и состояний этого цикла, а также предусматривать несколько различных способов визуализации. Носитель информации о компоненте содержит множество различных типов элементов данных, а проекты имеют как минимум два различных вида конфигураций: конфигурация состава (или «Комплектация») и конфигурация состояния. Проектные данные должны управляться не только параметрами, но и DTs (управляющие таблицы), Rules (правила), Checks (проверки) и т.д. Проектные данные имеют «поведенческие» элементы описания (Behavior features), требуя контроля средствами PDM и характеризуясь высокой вариантностью («как задумано», «как спроектировано», «как изготовлено», «как существует при эксплуатации»).
Возможностей SMARTEAM оказалось достаточно для реализации такого системного решения:
имеется двухсторонний обмен между CATIA и SMARTEAM; поддерживаются межмодельные связи (как логические, так и иерархические); имеется конфигурируемая модель данных; предусмотрены возможности настройки; реализованы средства импорта/экспорта.
Эти специфические функции позволили нашей компании выполнить пилотный проект для крупной российской авиационной корпорации.
Настройка SMARTEAM для реализации RGD
Для выполнения настройки использовались три стандартных средства SMARTEAM: конструктор информационной модели SMARTEAM Data Model Designer; моделер средств интеграции с различными системами Integration Tools Setup (моделер средств интеграции с различными системами, в нашем случае, с системой CATIA); Users Maintenance (управление полномочиями пользователей). При настройке не было написано ни одной строчки программного кода. С помощью Data Model Designer были определены новые классы моделей для моделей CATIA. Для каждой стадии проектирования были созданы специальные классы с необходимыми наборами атрибутов и других свойств. С помощью Integration Tools Setup реализована возможность двунаправленного отображения параметров CATIA и атрибутов метаданных SMARTEAM. Средствами Users Maintenance были настроены необходимые права доступа для различных групп пользователей в соответствии с их ролевыми функциями на различных этапах проектирования.
Врезки:
Рис. 1. Общая схема методологии RGD Рис. 2. Модель реализованного решения
Сценарии для сборок
 | |
|
Рис. 4. Сценарий определения системно-агрегатной сборки |
Сценарий определения системно-агрегатной (функциональной) сборки приведен на рис. 4.
Обратим внимание на два способа формирования сборок. Левая ветвь иллюстрирует формирование сборок средствами CATIA. Этот способ является предпочтительным тогда, когда большая часть сборочных элементов выполнена в этой системе. Правая ветвь иллюстрирует альтернативный вариант, в котором сборки создаются средствами компонента SMARTEAM-BOM. Такой подход может оказаться эффективным при необходимости включения в сборку элементов, созданных альтернативными средствами и не имеющими представления в CATIA.
Сценарии проектирования моделей
Рассмотрим сценарий проектирования на примере стадии инженерного моделирования.
 | |
|
Рис. 3. Сценарий инженерного моделирования |
Далее осуществляется поиск других ранее выполненных моделей (прототипов), данные которых требуются для разрабатываемой модели. Если такие модели найдены, то из них проводится импортирование ссылок. После этого, производится доведение модели до уровня поставленных требований. Результаты работы публикуются, становясь доступными для импорта в другие модели (например, для использования на следующих стадиях проектирования). Таким способом обеспечивается сохранение конфиденциальности разработки, и «облегчаются» модели, наследующие полученные результаты. Это важно для последующего формирования больших сборок: они формируются из максимально «облегченных» моделей, которые, вместе с тем, обладают ассоциативностью со всеми порождающими моделями.
Затем выполняется проверка корректности модели в соответствии с заранее определенными критериями. Если результаты проверки положительны, то производится утверждение модели и запись ее в базу данных SMARTEAM. Следует заметить, что на самом деле автоматическая проверка на соответствие правилам происходит постоянно в процессе работы в реальном времени, а не только по завершении работы.
Система SMARTEAM
Представляется, что пока еще не существует систем, которые в полной мере реализуют концепцию cPDm. Границы между CPD, CPC, VPDM, а также «классическим» PDM размыты по своей природе: не существует абсолютных критериев определения принадлежности системы к какому-то специфическому классу. Многие производители относят свою систему к нужному им классу только потому, что в ней в каком-то зачаточном, а иногда и просто в декларативном виде, включены соответствующие функции. Если использовать подобные «мягкие» критерии, то почти все современные PDM-системы можно позиционировать как cPDm. Реально же можно утверждать, что современные системы действительно имеют некоторый тренд в сторону cPDm.
Система SMARTEAM по своей функциональности может быть отнесена к классу CPC-ориентированных систем с развитой функциональностью, а также как CPD-система начального уровня. В случае использования SMARTEAM в качестве основной PDM системы предприятия, часть CPD-функциональности (например, поддержка цифровой модели) обеспечивается с помощью систем CATIA, ENOVIA DMU Navigator и встроенных средств интеграции. Рассматриваемое в статье системное решение (реализация методологии) во многом является решением именно класса CPD. Особенностью SMARTEAM является возможность плавного наращивания функциональности, изменения информационной модели и модели бизнес-процессов в процессе эксплуатации.
