CC BY
63
УДК 002.53; 002.53:004.65; 002.53:004.62/.63
СПОСОБ ПОСТРОЕНИЯ ИНТЕГРИРОВАННОЙ ИНФОРМАЦИОННОЙ СРЕДЫ НА БАЗЕ СИСТЕМ
УПРАВЛЕНИЯ ДАННЫМИ И СИСТЕМ АВТОМАТИЗИРОВАННОГО ПРОЕКТИРОВАНИЯ
А.А. Вичугова
Томский политехнический университет E-mail: anya@aics.ru
Рассмотрены аспекты построения единого информационного пространства для разработки высокотехнологичной продукции, реализованного в виде программного взаимодействия системы управления данными и систем автоматизированного проектирования. Предложены требования к интеграции систем указанных категорий, структура хранения типовых справочных данных, алгоритмы обмена информацией между интегрируемыми информационными системами с учетом состояний жизненного цикла объектов проектирования.
Ключевые слова:
Информационные системы управления данными, системы автоматизированного проектирования, технологии интеграции программного обеспечения.
Введение
Проектирование высокотехнологичной продукции с длительным сроком активного существования (глубоководные и космические аппараты, искусственные человеческие органы и т. д.) представляет собой целый комплекс процессов со сложной структурой взаимосвязей и временной длительностью. Отличительной особенностью данной деятельности является проведение натурных испытаний на этапе проектирования, что вызывает необходимость создания реального образца изделия для каждой стадии испытаний. Готовность изделия к производству определяется состоянием конструкторской документации (КД) на данное изделие. Под качеством КД понимается отсутствие ошибок в описании характеристик изделия согласно принятым нормативно-техническим стандартам. Первоисточником данных для КД является совокупность элементов электронной структуры изделия (ЭСИ), под которой понимают структурированную совокупность составных частей (компонентов) изделия.
В свою очередь, ЭСИ формируется на основе файлов информационных моделей изделия (ИМИ), разработанных в различных системах автоматизированного проектирования (САПР). Проектирование изделия считается завершенным в случае окончательно сформированной ЭСИ и утвержденной КД. Сложность проектируемых изделий обусловливает итеративность процессов разработки, что ведет к наличию нескольких вариантов ИМИ, называемых версиями. Это, в свою очередь, вызывает необходимость к версионности электронной структуры изделия и конструкторской документации.
Итак, проектирование высокотехнологичной продукции сопровождается большим количеством разнотипных взаимозависимых данных в виде ИМИ, КД и ЭСИ. Необходимость работы с большим количеством этой информации усложняет процесс проектирования и увеличивает его длительность за счет временных затрат на поиск необходимых данных и изменение их в ручном режиме. Учитывая требования современной экономической ситуации к сокращению сроков представления готовых изделий на рынок с условием сохранения их качества, становится особенно актуальной задача уменьшения длительности проектирования путем оптимизации процессов, не добавляющих ценности итоговому продукту (итеративный выпуск и проверка документации, поиск данных и т. д.).
Вичугова Анна Александровна, ассистент кафедры автоматики и компьютерных систем Института кибернетики ТПУ.
E-mail: anya@aics.ru. Область научных интересов: бизнес -моделирование, структурный анализ, базы данных, информационные системы электронного документооборота, информационно-управляющие системы..
Для обозначения создаваемых при проектировании сущностей (Изделие, ИМИ, КД, ЭСИ) в статье используется термин «объекты проектирования», а термин «управление жизненным циклом объектов проектирования» - для обозначения следующей совокупности действий: структурированное хранение большого объема данных и автоматизированное изменение разнотипных объектов проектирования от исходного состояния к целевому с учетом их взаимозависимости, включая мониторинг работ участников процессов проектирования и обработки информации. В настоящее время для решения этих задач применяются технологии информационной поддержки жизненного цикла изделий, реализованные в системах управления данными (СУД) и САПР. Объединение СУД и САПР в единый программно-аппаратный комплекс принято называть интегрированной информационной средой (ИИС).
С точки зрения технологий информационной поддержки жизненного цикла изделий, ИИС реализуется посредством программной интеграции систем, обеспечивающих автоматизацию и поддержку различных этапов жизненного цикла продукции. Центральное место в организации ИИС играет СУД. Кроме структурированного хранения информации об изделии, для реализации полноценного управления данными СУД должна поддерживать интеграцию с другими программными средствами в рамках ИИС.
Идея организации ИИС широко исследуется с начала XXI в. российскими и зарубежными учеными и широко описана в работах О. Шиловицкого, Д. Брауна, Е.И. Яблочникова , В.И. Молочникова и др. [1].
Особое внимание уделяется командному сквозному проектированию, которое означает многопользовательскую работу и оперативный обмен электронными данными при использовании нескольких САПР в разработке изделий. Сегодня существует множество стандартов обмена электронными данными, которые позволяют организовать операции импорта и экспорта информации между различными программными средствами, например STEP, IGES, Parametrics, Mandate, Parts Library. Однако с точки зрения технологий информационной поддержки жизненного цикла изделий интеграция между САПР и СУД не сводится к простому обмену файлами, поскольку следует учитывать версионность объектов, а также необходимость объединения информации из различных САПР, в которых выполняется разработка частей проектируемого изделия, при условии агрегации всех характеристик одного элемента ЭСИ в СУД и отсутствия дублирования данных (рис. 1).
Рис. 1. Представление данных из множества систем автоматизированного проектирования в системе управления данными
Таким образом, возникает задача разработки способа построения ИИС на базе интегра-ций САПР и СУД с целью управления жизненным циклом разнотипных взаимозависимых объектов проектирования. Разрабатываемый способ должен носить общий характер и быть адаптируемым к особенностям предметных областей внедрения и специфике конкретных предприятий. В рамках разработки способа построения интегрированной информационной среды на базе САПР и СУД необходимо решить следующие задачи:
• выявление требований к интеграции систем автоматизированного проектирования и управления данными об изделии;
• определение структуры хранения и вариантов использования справочных данных, которые создаются и применяются при проектировании;
• разработка алгоритмов взаимодействия систем автоматизированного проектирования и управления данными об изделии;
• анализ существующих методов и технологий программной интеграции информационных систем с целью выбора оптимального решения для реализации ранее разработанных алгоритмов взаимодействия.
Разработка требований к интеграции САПР и СУД в рамках ИИС
На основании ранее описанного взаимовлияния разнотипных объектов проектирования друг на друга можно выделить следующие категории требований, предъявляемых к интеграции САПР и СУД в рамках ИИС:
1. Требования к целостности, полноте и аутентичности информации:
• централизованное хранение в СУД всех характеристик изделия, проектируемых в различных программных средствах;
• однозначное непротиворечивое представление в СУД объекта, описанного с различных точек зрения в разных САПР;
• исключение дублирования данных;
• автоматическая синхронизация данных в различных информационных системах.
2. Требования к автоматизации процесса проектирования:
• автоматическое формирование ЭСИ в СУД;
• автоматическое формирование полного комплекта КД в СУД.
3. Требования к безопасности:
• аутентификация и авторизация пользователей;
• распределение прав пользователей на доступ к информации согласно их ролям в процессе проектирования;
• организация хранилищ данных на распределенных серверах;
• резервирование хранилищ данных.
4. Требования к управлению версиями данных:
• возможность существования нескольких версий объекта;
• любое изменение опубликованного в СУД объекта должно отображаться в его новой версии, генерируемой автоматически;
• накопление данных и опыта, возможность использования информации из предшествующих проектов для текущих разработок.
Рассматривая вышеуказанные требования к ИИС с точки зрения программного сопряжения САПР и СУД можно выделить следующие функциональные возможности, обеспечиваемые за счет интеграции этих систем:
• возможность просмотра в интерфейсе СУД содержимого файлов ИМИ, разработанных в различных САПР;
• возможность открытия для редактирования файлов информационных моделей изделия из интерфейса СУД, с учетом версии и стадии жизненного цикла документа;
• экспорт файлов информационных моделей изделия САПР в СУД с выбором проекта, изделия, элемента ЭСИ, а также с учетом версии и стадии жизненного цикла документа;
• автоматическая генерация ЭСИ на основе данных из множества ИМИ-файлов, импортированных в СУД из различных САПР;
• автоматическая генерация комплекта конструкторской документации на изделие, с учетом версии и стадии жизненного цикла документа, по заданному шаблону на основе его электронной структуры и данных из множества информационных моделей, импортированных в СУД из различных САПР;
• непротиворечивость и полнота представления в СУД информации об объекте, который описан в различных САПР.
Перечисленные задачи сводятся к определению правил хранения и обработки информации, включая как вновь созданные в процессе проектирования данные (ИМИ, КД, ЭСИ), так и сведения об уже существующих и успешно применяемых решениях. Также следует принять во внимание, что высокотехнологичные изделия, например, в отрасли машиностроения, космической промышленности и т. д., состоят из множества типовых компонентов, применение которых четко регламентировано государственными и отраслевыми стандартами. Информация об этом может быть названа типовыми (справочными) данными, которые, согласно положению о центральной роли СУД в ИИС, должны храниться в СУД с возможностью дальнейшего использования.
Структура хранения типовых справочных данных
В соответствии с классификацией составных частей изделия по [1], многие его элементы являются типовыми, т. е. описываются с помощью унифицированных характеристик, 3D-моделей и условных графических обозначений. Поэтому целесообразно организовать хранение типовых элементов изделия в СУД в виде справочных данных, на которые будут ссылаться сущности из ЭСИ.
Типовой объект характеризуется меньшим набором атрибутов, чем реальная сущность, например, атрибут расположения объекта относительно других элементов изделия (х-, у-координаты) присущ только реальному элементу изделия и потому отсутствует в наборе атрибутов связанного типового объекта. Кроме того, справочные данные описывают лишь диапазоны значений атрибутов элементов, а не конкретные значения. Например, атрибут «Ширина выводов» у типовой микросхемы может варьироваться от 0,33 до 0,51 мм, однако в каждом конкретном случае этот атрибут принимает единственное дискретное значение. Аналогичные ситуации возникают и в случае механических изделий, например болтов и т. д.
Применяя терминологию объектно-ориентированного программирования к исследуемым объектам проектирования, каждому типу объекта поставим в соответствие класс, экземпляры которого являются контейнерами информации о конкретном объекте. Таким образом, экземпляры класса «ЭСИ» должны ссылаться на типовые объекты, которые содержат справочные данные о рассматриваемой сущности. Каждый элемент реального изделия связан с соответствующим ему типовым элементом отношением кратности «один к одному», поскольку реальная сущность, к примеру транзистор или болт, не может быть основан на нескольких типовых элементах одного класса одновременно. Таким образом, каждый реальный элемент ЭСИ, который используется при проектировании изделия, описывается значениями атрибутов экземпляра класса «ЭСИ» и справочной информацией о типовом элементе рассматриваемого класса.
В настоящее время большинство предприятий, осуществляющих проектирование и производство высокотехнологичных изделий, функционируют по проектной модели деятельности. Разработка новой продукции выполняется в рамках проекта, что определяет исходную точку структуризации объектов в СУД. Набор однотипных сущностей принято отображать в виде взаимосвязанных иерархических деревьев, например дерево проектов, дерево изделий, дерево документов и т. д. Поскольку в основе любого элемента изделия может лежать типовой объект, классификация справочных данных аналогична реальным. Поэтому целесообразно создать специальный проект «Справочники», с которым будут связаны нормативно-справочные документы (например, государственные и отраслевые стандарты), а также элементы ЭСИ.
Значения атрибутов объекта класса «ЭСИ» (например, «Ширина выводов») характеризуют только некоторые количественные и качественные параметры данной сущности. Полное описание элемента изделия содержится в его информационных моделях, которые представляют собой файлы САПР. Таким образом, с типовыми (справочными) объектами ЭСИ должны быть связаны описывающие их информационные модели.
На рис. 2 приведена схема предлагаемой структуры хранения справочных данных в СУД на примере отрасли космического приборостроения.
Документы
Проекты
/
Справочники
Стандарт предприятия (СТП) ...
Документы
Справочни электрорадиоизделий (ЭРИ)
Документы
Транзисторы
Элементы ЭСИ
-С
/
/
/
Биполярные транзисторы
/
Перечень разрешенных к ^применению ЭРИ
Рис. 2. Схема хранения справочных данных в СУД
Условно-графическое изображение
Результаты инженерного анализа
Схема на рис. 2 показывает, что в рамках дерева проектов создан специальный проект «Справочники», с которым связано отдельное дерево документов. В дереве проектов организована иерархическая структура типов справочных данных, например электрорадиоизделий. Множество элементов, которые относятся к рассматриваемому типу, представлены в отдельном дереве ЭСИ. Документация на каждый элемент изделия, включая его информационные модели, содержится в отдельном, связанном с ним, дереве документов.
В свою очередь, файлы, импортированные из САПР в СУД, хранятся в экземплярах класса «ИМИ» и могут быть использованы в качестве основы для разработки новых объектов, т. е. вновь экспортированы в САПР, доработаны и сохранены в СУД под новым именем. При этом необходимо сохранить связь между всеми этими объектами. Это условие должно быть учтено при разработке алгоритма экспорта информационных моделей изделия из САПР в СУД.
Использование типовых объектов класса «ЭСИ», описывающих элементы изделия, позволит сократить объем информации, хранящейся в СУД, и избежать дублирования данных. Поэтому необходимо определить процедуру наполнения системы управления данными справочной информацией. В связи с большим объемом подобных данных их создание в СУД должно выполняться автоматически при импорте информационных моделей изделия из САПР. Для обеспечения непротиворечивости и полноты представления информации об объекте, описанного в различных информационных системах, разработанная в САПР сущность должна быть без потерь экспортирована в СУД. Это обеспечивается наличием в СУД соответствующих контейнеров (классов с необходимым набором атрибутов).
Анализируя требования к однозначности и полноте представления в СУД информации об объекте, описанного в различных САПР, можно отметить следующее:
• экземпляры класса «ЭСИ» в СУД являются хранилищами информации о составной части изделия (детали, сборочной единицы, комплекта, комплекса и т. д. по [1]);
• различные характеристики составной части изделия описываются с помощью экземпляров классов суперкласса «ИМИ», файлы которых разработаны в различных САПР и импортированы в СУД.
Учитывая данные замечания, требования к непротиворечивости и полноте представления в СУД информации об объекте, описанного в различных САПР, а также положения объектно-ориентированного подхода, можно сделать вывод, что класс «ЭСИ» является контейнером для информации из файлов информационных моделей изделия, импортированных в СУД из различных САПР. Поэтому определение набора атрибутов класса «ЭСИ» является отдельной задачей, решение которой влияет на организацию интеграции систем автоматизированного проектирования и управления данными об изделии в рамках ИИС.
Чтобы избежать ситуации с дублированием или потерей данных, необходимо знать контрольное значение атрибута, которое будет одинаково для одного элемента электронной структуры изделия, описанного в нескольких его информационных моделях, разработанных в раз-
ГОСТ Р
3Р-модель
КТ321А
ОСТ Р
личных САПР. Это позволит реализовать однозначное представление элемента изделия в СУД. С целью выделения данного атрибута из набора характеристик класса обозначим его термином «ключевой атрибут». Например, для электрорадиоизделий таким атрибутом может являться составное выражение: «Обозначение корпуса элемента и его расположение в ячейке схемы». Значение ключевого атрибута должно проверяться при автоматическом формировании электронной структуры изделия в СУД на основе его информационных моделей, разработанных в разных САПР. Таким образом, далее целесообразно определить алгоритм экспорта информационных моделей изделия из САПР в СУД, с учетом обозначенных выше особенностей структуры хранения и использования справочных данных.
Разработка алгоритмов
Файлы информационных моделей изделия и формируемая на их основе конструкторская документация являются экземплярами класса «Документ». В свою очередь, элемент изделия, описываемый с помощью информационной модели изделия, должен быть интегрирован в дерево элементов его электронной структуры. При этом следует также учитывать, является ли объект, импортируемый в СУД, типовым. В этом случае его следует считать справочным данным, и требуется настроить ссылку на уже существующую в СУД сущность. Таким образом, при экспорте данных из САПР необходимо генерировать в СУД объекты соответствующих классов в рамках одного проекта и одного изделия. Кроме того, поскольку СУД является многопользовательской программной средой, необходимо предусмотреть процедуры аутентификации и авторизации при импорте данных из САПР.
Учитывая вышесказанное, целесообразно определить процедуру экспорта информационных моделей изделия из САПР в СУД в виде следующей логической последовательности действий:
1. Аутентификация и авторизация пользователя СУД, включая выбор базы данных СУД и определение набора операций, доступных пользователю в рамках выбранной базы данных.
2. Поскольку разработка изделия выполняется в рамках конкретного проекта, необходимо выбрать один экземпляр класса «Проект» из существующих в выбранной базе данных СУД. При этом пользователь должен иметь право работать с выбранным проектом.
3. Далее аналогичным образом, следует произвести выбор изделия и его составной части (сборочной единицы), т. к. в рамках одного проекта может выполняться разработка нескольких изделий и сборочных единиц.
4. Поскольку экспортируемые из САПР файлы информационных моделей изделия в СУД являются экземплярами класса «Документ», должно происходить автоматическое создание этих объектов в дереве документов, включая связь с проектируемым изделием и его составной частью. При этом следует учитывать комплексный характер САПР-файлов, например, сборка из конечного множества деталей. В таком случае в СУД должна сохраниться иерархичная совокупность всех составных частей объекта.
5. После того как экспорт файлов информационных моделей изделия из САПР в СУД завершен, становится возможным формирование его электронной структуры.
Первоисточником данных для формирования электронной структуры изделия является содержимое множества файлов его информационных моделей, в которых описаны количественные и качественные характеристики элементов. Таким образом, для создания элементов изделия в структурированном порядке необходимо, прежде всего, определить, какие сущности содержатся в файлах ИМИ. Это возможно сделать, если данные о внутреннем содержимом информационной модели изделия представлены в открытом структурированном формате, например XML, JSON, STEP. В этом файле должны быть описаны элементы ЭСИ и их характеристики, которые моделируются в САПР. Наиболее простой и доступный способ формирования этих данных состоит в использовании функций сохранения результатов в САПР, например «Сохранить как» или «Экспортировать в ...». Затем необходимо присоединить эти данные к пакету файлов ИМИ, которые должны быть переданы в СУД.
Чтобы определить алгоритм формирования ЭСИ, рассмотрим следующую логическую последовательность функций:
1. Начальным шагом формирования электронной структуры изделия или его сборочной единицы в СУД является ее выделение и вызов пользователем соответствующей команды.
2. Первоисточником данных для электронной структуры изделия является множество его информационных моделей. Таким образом, следует выполнить поиск документа ИМИ, связанного с изделием (сборочной единицей), электронную структуру которого необходимо построить.
3. Далее следует проанализировать информацию об элементе ЭСИ из файла, в котором описано содержимое информационной модели (файл формата JSON, XML, STEP и т. д.). Значение ключевого атрибута найденного объекта определяет, к какому классу «ЭСИ» он относятся.
4. При наличии объекта с равным значением ключевого атрибута в дереве элементов электронной структуры изделия (сборочной единицы), структура которого формируется, следует дополнить информацию об объекте (которая представлена в виде атрибутов) данными, описанными в рассматриваемом файле информационной модели.
5. Иначе, при отсутствии объекта с равным значением ключевого атрибута, создать новый объект необходимого класса и заполнить его значениями атрибутов на основе информации из файла, который описывает рассматриваемую информационную модель изделия.
6. Найти в структуре проекта «Справочники» объект, который соответствует вновь созданному (найденному) элементу ЭСИ.
7. При отсутствии типового объекта в структуре проекта «Справочники» его следует создать, задав соответствующий класс и значения атрибутов.
8. Связать типовой (в структуре проекта «Справочники») и реальный объекты ЭСИ.
9. Повторение шагов 3-8 выполняется до тех пор, пока не обработаны все элементы электронной структуры изделия, перечисленные в рассматриваемом файле с описанием его информационной модели.
10. Повторение шагов 2-9 выполняется до тех пор, пока не обработаны все документы ИМИ, связанные с изделием, электронную структуру которого необходимо сформировать. Сформированное по завершению данного цикла структурированное множество объектов представляет собой ЭСИ в стадии жизненного цикла «Новая версия».
Предложенный алгоритм формирования ЭСИ в СУД связан с другим, ранее рассмотренным компонентом предложенного способа построения ИИС на базе СУД и ее интеграций с САПР - структурой хранения типовых справочных данных в СУД. Таким образом, предложенный способ построения ИИС включает следующие взаимосвязанные составляющие:
• требования к взаимодействию систем автоматизированного проектирования и управления данными об изделии;
• структура хранения и варианты использования типовых справочных данных;
• алгоритм экспорта ИМИ из САПР в СУД;
• алгоритм формирования ЭСИ в СУД.
Показанная на рис. 3 схема взаимосвязи компонентов предложенного способа построения ИИС наглядно иллюстрирует развитие выявленных требований к взаимодействию систем автоматизированного проектирования и управления данными об изделии в виде формальных алгоритмов и моделей. Например, авторизация пользователей, относящаяся к категории «требования к безопасности», является неотъемлемой функций алгоритма экспорта ИМИ из САПР в СУД.
^САПР^
алгоритм экспорта ИМИ из САПР в СУД )
авторизация пользователя
/структура хранения \ —I типовых справочных ) V данных У
^ V ^
алгоритм -►(формирования ЭСИ 'Ц-в СУД у
автоматическое формирование ЭСИ в СУД
однозначное представление элемента ЭСИ, на основе множества ИМИ из разных САПР
автоматическое формирование новых версий объектов
требования к безопасности требования требования требования
к автоматизации процесса к целостности, полноте к управлению версиями
проектирования и аутентичности данных данных
автоматическое формирование КД в СУД
Рис. 3. Концептуальная схема взаимосвязи компонентов предложенного построения ИИС на базе СУД и ее интеграций с САПР
Аналогичным образом требования к автоматизации процесса проектирования, такие как автоматическое формирование ЭСИ и КД в СУД, находят свое отражения в алгоритмах формирования электронной структуры изделия в СУД и экспорта его информационных моделей из САПР. Выполняемое при этом автоматическое формирование новых версий объектов относится к категории требований к управлению версиями данных. При формировании ЭСИ в СУД реализуется требование к целостности, полноте и аутентичности данных, выражающееся в необходимости однозначного представления элемента ЭСИ, на основе множества информационных моделей из разных САПР. Это влияет на структуру хранения типовых справочных данных в СУД, которая, в свою очередь, учитывается при формировании электронной структуры изделия.
Итак, все ранее рассмотренные компоненты представленного способа построения ИИС на базе систем автоматизированного проектирования и управления данными об изделии взаимосвязаны между собой в рамках единой концептуальной основы. Однако для практической реализации разработанных моделей и алгоритмов следует выполнить анализ существующих методов и технологий интеграции приложений, а затем, в зависимости от конкретной прикладной специфики, выбрать наиболее подходящий вариант.
Поиск технологий программной интеграции систем
На основе анализа разработанных алгоритмов экспорта информационных моделей изделия из САПР в СУД и формирования его электронной структуры можно сделать вывод, что взаимодействие САПР и СУД фактически представляет собой удаленный вызов процедур одного приложения в контексте другого. Под термином «удаленный вызов процедур» понимают класс технологий, которые позволяют компьютерным программам вызывать функции или процедуры в другом адресном пространстве. Наибольшая эффективность использования метода удалённого вызова процедур достигается в тех приложениях, в которых существует интерактивная связь между удалёнными компонентами с небольшим временем ответов и относительно малым количеством передаваемых данных [2]. Поэтому данный метод целесообразно использовать для интеграции разных информационных систем.
Распределённые системы доступа к объектам и системы удалённого вызова процедур называют системами обмена сообщениями. Сообщение реализуется путём посылки пакетов информации получателю. Передаваемой информацией могут являться сигналы, данные, а также удаленные вызовы процедур. Обмен сообщениями позволяет вызывающему приложению
отправить информацию и вернуться к выполнению текущей задачи, переложив всю ответственность за доставку данных на систему обмена сообщениями [3].
В настоящее время выделяют следующие наиболее распространенные технологии реализации метода удаленного вызова процедур в рамках систем обмена сообщениями [4]:
• компонентная объектная модель (Component Object Model - COM), разработанная корпорацией Microsoft;
• общая архитектура брокеров объектных запросов (Common Object Request Broker Architecture - CORBA);
• веб-сервисы, например ESB (Enterprise Service Bus, сервисная шина предприятия) и SOA (Service Oriented Architecture, сервис-ориентированная архитектура).
Выбор конкретной архитектуры зависит от специфики интегрируемых систем, например, в случае веб-платформенных приложений наиболее эффективным будет применение протоколов SOA, JAVA и т. д. Однако если сопрягаемые системы функционируют как настольные приложения (что часто распространено среди САПР и СУД), их интеграцию наиболее уместно выполнить на основе взаимодействующих компонентов, каждый из которых может использоваться во многих системах одновременно. Это позволяют реализовать компонентно-объектные технологии CORBA и COM. Несмотря на сходные базовые принципы, они имеют множество различий в деталях реализации. Выбор конкретной технологии интеграции САПР и СУД методом удаленного вызова процедур зависит от множества факторов, таких как программно-аппаратные платформы сопрягаемых систем, особенности информационной инфраструктуры предприятия внедрения и т. д. Поэтому данный вопрос следует детально рассмотреть в рамках отдельного исследования.
Выводы
Рассмотренный способ построения интегрированной информационной среды на базе системы управления данными и ее интеграций с системами автоматизированного проектирования позволяет реализовать автоматизированное управление жизненным циклом разнотипных взаимозависимых объектов, представленных множеством версий, с учетом специфических особенностей проектирования высокотехнологичной продукции, таких как итеративность процессов разработки и необходимость единого комплексного представления данных из множества источников. Предложенный способ представлен набором требований к взаимодействию программных средств и оригинальными алгоритмами их реализации, включая автоматическое заполнение справочных каталогов при построении электронной структуры изделия.
СПИСОК ЛИТЕРАТУРЫ
1. Яблочников Е.И., Молочник В.И., Миронов А.А. ИПИ-технологии в приборостроении. -СПб.: СПбГУИТМО, 2008. - 128 с.
2. ГОСТ 2.101-68. Единая система конструкторской документации. Виды изделий. - М.: Стандартинформ, 2007. - 3 с.
3. Боркус В. Методы и инструменты интеграции корпоративных приложений. - М.: RC Group, 2005. - 215 c.
4. Хоп Г., Вульф Б. Шаблоны интеграции корпоративных приложений. - М.: Вильяме, 2007. -672 с.
Поступила 30.04.2013 г.
