Научная статья на тему 'Разработка модели данных PDM-системы Enovia smarteam для управления спецификациями при создании радиоэлектронной аппаратуры'

Разработка модели данных PDM-системы Enovia smarteam для управления спецификациями при создании радиоэлектронной аппаратуры Текст научной статьи по специальности «Компьютерные и информационные науки»

CC BY
661
134
i Надоели баннеры? Вы всегда можете отключить рекламу.

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Вичугова А. А., Дмитриева Е. А., Цапко Г. П.

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

i Надоели баннеры? Вы всегда можете отключить рекламу.

Похожие темы научных работ по компьютерным и информационным наукам , автор научной работы — Вичугова А. А., Дмитриева Е. А., Цапко Г. П.

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.
i Надоели баннеры? Вы всегда можете отключить рекламу.

Текст научной работы на тему «Разработка модели данных PDM-системы Enovia smarteam для управления спецификациями при создании радиоэлектронной аппаратуры»

№ 5(29) 2010

А. А. Вичугова, £ А. Дмитриева, Г. П. Цапко

Разработка модели данных РОМ-системы Е№У1А ЗМАИТЕАМ для управления спецификациями при создании радиоэлектронной аппаратуры

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

ления инженернымиданными применительно

В работах [1, 2] обоснована актуальность и особая стратегическая важность инновационных проектов для отечественной высокотехнологичной промышленности. Это имеет непосредственное отношение к сфере оборонного и космического комплексов. К изделиям точного приборостроения предъявляются повышенные требования точности и надежности. Однако непрерывное увеличение функциональной интеграции при проектировании радиоэлектронной аппаратуры (РЭА) для космических аппаратов (КА) приводит к возрастанию трудоемкости процесса разработки и объема проектной документации. В результате осложняется согласованное взаимодействие специалистов, участвующих в создании изделий. Кроме того, современные условия жесткой конкуренции требуют сокращения времени выпуска и реализации готовой продукции, что достигается за счет оптимизации процесса проектирования.

Для повышения эффективности деятельности по созданию РЭА для КА необходимо обеспечить структурированное хранение проектной информации и оперативный обмен данными между всеми участниками целого комплекса процессов. Актуальность данного тезиса практически подтверждена результатами анализа деятельности отделения проектирования и испытаний РЭА ОАО

к рассматриваемой предметной области.

«Информационные спутниковые системы» им. академика М. Ф. Решетнева, который был выполнен в 2009 г. командой с участием авторов настоящей статьи.

Непрерывное управление инженерной информацией

Разработка РЭА и выпуск инженерной документации представляют собой взаимосвязанную последовательность этапов, определенных техническими регламентами и Государственными стандартами. Результатом выполнения каждого этапа является набор документации, состав которой определяют стандарты ЕСКД и ЕСТД. В таблице 1 приведены эти этапы и типы инженерно-технической информации при создании РЭА для КА.

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

Разработка моделиданныхРОМ-системы ЕЫОМА вМАвТЕАМдля управления спецификациями при создании радиоэлектронной аппаратуры

№ 5(29) 2010

Таблица 1

Этапы создания РЭА для КА

№ Этап Процесс Исполнитель Вход Результат

1 Разработка ТЗ Системный отдел Характеристики и назначение КА Функциональные требования к РЭА

Схемотехническое проектирование Схемотехнический отдел Функциональ- Электрические схемы (ЭС)

ные требования к РЭА Программы и методики испытаний (ПМ)

Конструкторское про- Конструкторский ЭС Конструкторская документация (КД)

ектирование отдел Ведомость покупных изделий (ВПИ)

2 Проектирование Лабораторно-отработочные испытания (ЛОИ) Схемотехнический отдел ПМ КД

Конструкторский отдел КД

Конструкторско-доводочные испытания (КДИ) Конструкторский отдел КД КД

Разработка технологии Технический отдел КД Технологическая документация (ТД)

производства Маршрутная карта (МК)

3 Приобретение комплектующих электрорадиоизделий (ЭРИ) для сборки прибора Отдел снабжения ВПИ ЭРИ для сборки прибора

МК

4 Сборка прибора Сборочные цеха ЭРИ для сборки прибора Прибор

Приемочные испытания (ПрИ) Схемотехнический отдел Прибор Прибор

Сдача прибора в эксплуатацию Конструкторский

5 Наземно-экспериментальная отработка (НЭО) отдел Прибор

Представитель заказчика Прибор Комплектдокумен- тации: ЭС, ПМ, КД, ТД

№ 5(29) 2010

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

Таким образом, сквозной обмен данными внутри всего предприятия подчеркивает важность создания единого информационного пространства (ЕИП) — комплексной программно-аппаратной телекоммуникационной среды [3], объединяющей все информационные ресурсы компании. ЕИП реализуется посредством специальных программных средств управления данными о продукции — PDM (от англ. Product Data Management). PDM-системы являются не только электронным архивом проектных данных, но и обеспечивают возможность параллельной командной разработки, управления потоками работ, распределения прав доступа к информации и другие функции автоматизированного управления данными. Поэтому внедрение PDM-систем в сферу точного приборостроения весьма актуально. Следует учесть, что создание РЭА имеет следующие отличительные особенности:

1) штучное производство сложных высокотехнологичных приборов;

2) итеративный выпуск новых версий документации на каждой стадии длительного этапа проектирования;

3) ограниченный перечень комплектующих для сборки прибора;

4) совместная удаленная работа со спецификациями (согласно ЕСКД спецификация — документ, определяющий состав сборочной единицы, комплекса, комплекта. ВПИ составляется на основе спецификации).

Разработка модели данных для работы со спецификациями в PDM-системе ENOVIA SmarTeam

Указанная отраслевая специфика задач создания РЭА для КА была реализова-

на в PDM-системе ENOVIA SmarTeam. На кафедре автоматики и компьютерных систем Томского политехнического университета развернута сетевая лицензионная версия данного программного средства. SmarTeam — продукт американской корпорации IBM и французской софтверной компании Dassault Systems, успешно используется на многих зарубежных и отечественных наукоемких предприятиях машиностроительной промышленности. SmarTeam предлагает две технологии работы с инженерными спецификациями: редактор ВОМ (от англ. BUI Of Material — Перечень материалов) и утилиту Briefcase (от англ. Briefcase — Портфель). Оба решения основаны на иерархической структуре изделия, которое состоит из взаимосвязанных сборок. Элементами сборки являются объекты модели данных (МД), хранимой в реляционной базе данных. Именно МД определяет возможности управления информацией, в том числе работу со спецификациями.

Согласно объектно-ориентированной методологии SmarTeam модель данных — это абстрактная структура отношений между классами.

Класс представляет собой типовой набор объектов, которые имеют общие свойства — атрибуты. Функциональность класса задается его методами. Классы верхнего уровня иерархии являются абстрактными и называются суперклассами. Класс может иметь подклассы, наследующие атрибуты и методы родительского класса. Следует отметить специфику классовой иерархии модели данных Smarteam: деление на внутренние подклассы нерационально, поскольку родительский класс становится абстрактным и исчезает возможность работы с его объектами.

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

А. А. Вичугова. £ А. Дмитриева, Г. П. Цапко

Разработка моделиданныхРОМ-системы ЕЫОМА вМАвТЕАМдля управления спецификациями при создании радиоэлектронной аппаратуры

№ 5(29) 2010

Таблица 2

Основные механизмы модели данных ЭтагТеат для работы со спецификациями, автоматизации документопотоков и бизнес-процессов

Механизм Функциональность

Сборка (Product) Работа со сборками, механизм необходим для управления спецификациями

Элементы и Документы (Parts and Documents) В зависимости от типа объекта (Элемент или Документ) определяются возможные операции работы с ним, механизм необходим для управления спецификациями

Поддержка нескольких состояний объекта (Multi-States Mechanism) В зависимости от типа объекта (Элемент или Документ) определяются возможные состояния его жизненного цикла (ЖЦ), механизм необходим для управления спецификациями

AutoCAD, Autodesk Mechanical Desktop, CATIA, Inventor, Microstation, Pro/Engineer, SolidWorks, SolidEdge Интеграция с различными CAD-системами

Microsoft Excel, Word Интеграция со средствами MS Office

SmartGateway Двунаправленный обмен данными между SMARTEAM-и ERP-системами

Авторизация на уровне проектов (Project Based Authorizations) Разделение пользователей по ролям

Бизнес-процесс (Work Flow) Автоматизация документопотоков и бизнес-процессов

ции документопотоков и бизнес-процессов (табл. 2).

Методология Зтаїїеат предусматривает четкое разделение следующих понятий:

• Элемент — физическая сущность, компонент сборки изделия;

• Документ — информационная единица, определяющая Элемент.

Связь спецификации устанавливает жесткое динамическое соединение между экземплярами классов «Элемент» и «Документ», которые позволяют отследить историю изменений состояний объекта, называемых стадиями его ЖЦ. Правила ЖЦ определяют бизнес-логику выполняемых процессов, изменяя состояние объекта в результате исполнения операций. Стадии ЖЦ можно изменять или создавать согласно организационно-технологическим регламентам отрасли или предприятия. В таблице 3 приведены стадии ЖЦ Элемента в соответствии с последовательностью этапов процесса разработки РЭА.

В таблице 4 представлены стадии ЖЦ объектов класса «Документ», настроенные согласно внутренним стандартам документооборота ОАО «ИСС» при разработке РЭА.

На основании выбранных механизмов автоматически генерируется набор классов (см. рис. 1 (а) на стр. 28), однако, полученную таким образом структуру необходимо адаптировать к специфике деятельности: добавить новые классы, изменить иерархию. Визуальное отображение уровня вложенности классов для пользователя определяется с помощью композиции класса. С учетом этих особенностей и отраслевых задач (см. табл. 1) была разработана структура классов для управления данными при создании РЭА (см. рис. 1 (б) на стр. 28).

Функциональность объектов класса обеспечивают его методы. В частности, для работы со спецификациями объект класса «Сборка» должен поддерживать метод

№ 5(29) 2010

Таблица 3

Стадии ЖЦ Элемента

Стадия Описание

Неактивный Элемент не находится в состоянии разработки или изготовления/производства

Временный Ожидание подтверждения элемента в ЕВР-системе

Разработка Этап разработки (по умолчанию новый элемент создается в этом состоянии)

Прототип Создание прототипа, конфигурация разработки

Готов к производству Выпуск элемента, планирование изготовления

Производство Этап изготовления/производства

Таблица 4

Стадии ЖЦ Документа и операции по их изменению

Операция Стадия Описание

Добавить Новый Объект создан пользователем и находится в рабочей директории, недоступен другим пользователям

Отправить на согласование На согласовании Файл объекта помещается в общее защищенное хранилище, становится доступным для просмотраавторизованным пользователям. Для внесения изменений объект следует взять на корректировку

Взять на корректировку На изменении Файл объекта перемещается в рабочую директорию пользователя для внесения изменений. Никакой другой пользователь не может в этот момент изменять файл, атолько просматривать файл родительской версии

Новая корректировка Создает новую версию исходного утвержденного объекта

Утвердить Утвержден Файл объекта помещается в защищенное хранилище утвержденных файлов и не подлежит изменениям, возможны только новые версии на его основе

Деактивировать Устаревший Файл объекта помещается в защищенное хранилище неактивных файлов, доступен для просмотра, но не для изменения

Таблица 5

Методы классов разработанной модели данных

Метод Класс, к которому подключен метод

Workflow Пользователи, Проекты, Сборки, Элементы, Процессы, Документы

Поведение Элемента Элементы

Поведение Документа Документы

Версия Элементы, Документы

Файловые операции Документы

Excel, HTML, Image, PDF, PowerPoint, Text, Word Документ

3D XML, CAD САО-документ

Поведение папки Папка

А. А. Вичугова. £ А. Дмитриева, Г. П. Цапко

Разработка моделиданныхРОМ-системы ЕЫОМА вМАвТЕАМдля управления спецификациями при создании радиоэлектронной аппаратуры

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

№ 5(29) 2010

Э jft Браудер кйДССД Е ^Ерфмонлгаачэ»

— £ ШШ

Пэвддог)«

О !£j ПнакТш Jd Прчйвр 21 Стлыр В ifi| Нда»

C4«r-t

йэ«т

Н SI

Прп«тчп»1*>

2d КднпиатаижНТР

ПрОДМВДСПЮ El jjjj Fb* H»f

Qknttirf Flw LjjFlMdiMl t’i Цпмд« -чжкРЕ - Ijjj JxfiWffil ^ ДйцИ»&

СДРЖнулс*# ibJ dtfi.4

б) модифицированная структура

Рис. 1. Классы структуры данных

Product Behavior. Методы Document Behavior для класса «Документ» и Part Behavior для класса «Элементы» позволяют изменять состояния ЖЦ этих объектов согласно установленным правилам (см. табл. 3, 4).

Метод Workflow становится доступным при наличии механизма Workflow в модели данных и служит для автоматизации доку-ментопотоков и бизнес-процессов.

В таблице 5 приведены методы классов созданной структуры.

Каждый класс описывается набором атрибутов, являющихся настраиваемыми полями таблиц спецификаций. Атрибуты клас-

tl Users

tJ РюіесЬ 0 Рі&ЬисИ 2J PVaducL Б Piit Irtffince

"J Gtfiiil Part lml«Ki .t! Flii'ii Pvacsia

ІІЗІ GwieialFiccfi*

H Si fbwNode

Fkw Ncde

a) Fbmhjl Д Meuest H«dcu

а)сгенерированные автоматически

PaLhjb*. С к ниша тгаї» !"ЗТ05ПИП<ТГ

- 4 Jeil 1

5

ЇАЯН

- /> ¿1 IIIBifiOIMtc

<1 1

вя№е№ч*Ое?ч|ґЧгіАі

ftafoJbe Няч Миє

Fiji F!teH»3Sr_«c

i:i<n>№v ОпропиЛ

К IHUrHUFiHMf гизн^и-ксялед*

1 ~ТЛг**лг-г|і I jrj'i j ТЗ

ДльТвралзш* E'jnl їп : гріпп ТІК

!4i.T~2U 1 Dc? ^=»?cE Tftf

Рис. 2. Фрагмент спецификации в редакторе ВОМ

сов, дополнительно созданные для классов разработанной модели данных, представлены в табл. 6.

Концепция модели данных Эта^еат предполагает взаимосвязь объектов различных классов между собой, что достигается за счет установки связей между классами, например, связь спецификации между классами «Элемент» и «Документ». На рисунке 2 показан фрагмент спецификации в редакторе ВОМ, полученной автоматически согласно структуре разработанной модели данных.

Редактор ВОМ позволяет изменять структуру изделия и значения атрибутов в хранилище данных, поддерживать как основные операции редактирования (копировать, вставить, удалить), так и специфичные функ-

Таблица 6

Дополнительно созданные атрибуты классов разработанной модели данных

Атрибут Характеристики Принадлежность к классу

Наименование Обязательный кзаполнению символьный тип Проекты, Сборки, Элементы, Процессы, Документы

Стоимость Тип — число с двойной точностью Элементы

Наличие в перечне ЭРИ, разрешенных к использованию Логический тип

Альтернатива Тип — ссылка на класс, для выбора возможных вариантов замены данного компо-нентадругим объектом класса Элементы

№ 5(29) 2010

ции: изменение стадии ЖЦ, версии, значений атрибутов и т.д.

Благодаря технологии Briefcase BOM дает возможность извлекать спецификации, упаковывать их со всеми связанными документами в Портфель для передачи внешним и внутренним контрагентам. Портфель — это самораспаковывающийся документ в формате .stbom или .ехе, который может быть отправлен по электронной почте, просмотрен и изменен получателем независимо от наличия специального программного обеспечения. Активный Портфель содержит встроенный редактор, необходимый для работы с файлами. Возможны сравнение и объединение многочисленных спецификаций и их обратная синхронизация в системе Smarteam. Схема работы с инженерными спецификациями в Smarteam показана на рис. 3.

Для автоматизации и контроля исполнения деятельности по созданию РЭА нужно разработать Workflow-диаграммы для каждого процесса, определяющие исполнителя и вид операции над объектом. В частности, в бизнес-логику процесса комплектации ЭРИ для сборки РЭА следует заложить сверку ВПИ с перечнем ЭРИ, разрешенных к использованию, и обмен данными с потенциальными поставщиками (см. табл. 1). Эти действия будут выполняться с применением технологии BOM Briefcase «Активный Портфель», поскольку внешние контрагенты не являются пользователями ЕИП предприятия.

В заключение сформулируем основные результаты проведенного исследования.

Разработана модель данных PDM-системы ENOVIA SmarTeam для использования в процессах создания РЭА с учетом отраслевых и организационных особенностей.

Выявлены виды входной и выходной инженерно-технической документации на каждом этапе создания РЭА с точки зрения ЖЦ изделия.

Определена последовательность этапов создания модели данных в терминах PDM-системы ENOVIASmarTeam.

Рис. 3. Схема работы с инженерными спецификациями

Рассмотрены возможности работы с инженерными спецификациями.

Список литературы

1. Круглов М. Г. Инновационный проект: управление качеством и эффективностью. — М.: Изд-во «Дело» АХН, 2009. — 336 с.

2. Воробьева Л. Л. Проблемы и перспективы использования CALS-технологий в Республике Беларусь // Инновационные технологии и системы: мат-лы междунар. форума. — Минск: ГУ «БелИСА», 2006. — 156 с.

3. Судов Е. В., Левин А. И., Петров А. В., Чубаров-цева Е. В. Технологии интегрированной логистической поддержки изделий машиностроения. — М.: ООО Изд-во «Информбюро», 2006. — 232 с.

4. Русановский С. А., Шалумов А. С. Математическое и программное обеспечение человеко-машинных интерфейсов для моделирования бортовых приборов и систем II Избранные труды Российской школы по проблемам науки и технологий. Под ред. Н. П. Ершова. —■ М.: Изд-во РАН, 2007. — 168 с.

5. Алексеев В. П., Коблов Н. Н., Хрулев Г. М. Современные технологии автоматизации проектирования РЭА специального назначения. — Томск: Изд-во ИОА СО РАН, 2003. — 134 с.

6. Baresi L., Casati F., Castano S., Fugini М., Gre-fen P., Mirbel I., Pernici B., Pozzi G. WIDE Workflow design methodology // Intern, joint Conf. on Work Activities Coordination and Collaboration. — WACC 1999, San Francisco, California, USA, February, 1999. P. 19-28.

А. А. Вичугова. £ А. Дмитриева, Г. П. Цапко

i Надоели баннеры? Вы всегда можете отключить рекламу.