CC BY
139
УДК 002.53; 002.53:004.65; 002.53:004.62/.63
ОСОБЕННОСТИ ИНТЕГРАЦИИ ИНФОРМАЦИОННЫХ СИСТЕМ АВТОМАТИЗИРОВАННОГО ПРОЕКТИРОВАНИЯ И СИСТЕМ УПРАВЛЕНИЯ ДАННЫМИ
А.А. Вичугова, В.Н. Вичугов, Г.П. Цапко
Томский политехнический университет E-mail: [email protected]
Рассмотрены требования к программной интеграции информационных систем с точки зрения технологий непрерывной поддержки жизненного цикла изделия. Приведен пример сопряжения системы автоматизированного проектирования электронных приборов Altium Designer с системой управления данными Enovia SmarTeam. Описаны некоторые особенности технической реализации взаимодействия указанных программных средств. Предложен способ интеграции информационных систем на основе API- и COM-технологий, а также унифицированных форматов представления данных.
Ключевые слова:
Информационные системы, жизненный цикл, модель данных, технологии программной интеграции.
Введение
В настоящее время все больше товаров оснащены средствами вычислительной техники и радиоэлектроники. Это объясняет увеличение спроса на продукцию приборостроительных предприятий. Единица промышленной продукции называется изделием. В приборостроительной отрасли промышленности изделие представляет собой взаимосвязанную совокупность множества составных частей [1]. Принимая во внимание тенденцию к расширению функциональности и интеллектуализации товаров, можно сделать вывод, что одной из главных задач сегодня является размещение радиоэлектронных средств (РЭС) в условиях габаритно-весовых ограничений. Совокупность РЭС, объединенных в сборочные единицы и устройства, предназначенные для преобразования и обработки электромагнитных сигналов, необходимых для выполнения прибора, принято называть радиоэлектронной аппаратурой (РЭА).
Функциональная сложность РЭА объясняет итеративность процессов ее проектирования и производства. При этом характерной особенностью данной деятельности является большое количество ее участников и высокий уровень использования информационных технологий (ИТ): систем автоматизированного проектирования (САПР) и систем управления данными (СУД). При этом следует отметить, что проектирование РЭА включает, как минимум, два взаимосвязанных аспекта: электрическое проектирование, которое обеспечивает выполнение определенных функций в условиях воздействия различных факторов, а также механическое
Вичугова Анна Александровна, аспирант, ассистент кафедры автоматики и компьютерных систем Института Кибернетики ТПУ.
E-mail: [email protected] Область научных интересов: бизнес-моделирование, структурный анализ, базы данных, информационные системы электронного документооборота, информационно-
управляющие системы. Вичугов Владимир Николаевич, канд. техн. наук, доцент кафедры автоматики и компьютерных систем Института кибернетики ТПУ.
E-mail: [email protected] Область научных интересов: программирование, базы данных, автоматизированные системы управления.
Цапко Геннадий Павлович, д-р техн. наук, профессор, заведующий кафедрой автоматики и компьютерных систем Института кибернетики ТПУ. E-mail: [email protected] Область научных интересов: системный анализ, информационные технологии управления жизненным циклом продукции.
проектирование, цель которого состоит в размещении определенных РЭС в соответствии с требованиями к массогабаритным характеристикам прибора.
В соответствии с положениями концепции технологий непрерывной поддержки жизненного цикла (ЖЦ) изделия, СУД выполняет роль связующего звена между различными САПР. Для обеспечения целостности информации, ее структурированного хранения и автоматизированной обработки, необходима интеграция САПР и СУД. При этом основной задачей является непротиворечивость представления информационных сущностей, которые создаются и используются в различных ИС. Таким образом, проблема разработки методов программного сопряжения САПР и СУД для проектирования РЭА имеет высокий уровень актуальности и практической значимости.
Информационные сущности при проектировании РЭА
С точки зрения проектирования РЭА, разработка изделия включает в себя описание в различных САПР электронной структуры, электронной и информационной моделей изделия. В связи с важностью этих понятий следует рассмотреть их определение с точки зрения регламентирующих документов - стандартов единой системы конструкторской документации.
Электронная структура изделия (ЭСИ) - это конструкторский документ, содержащий состав сборочной единицы, комплекса или комплекта и иерархические отношения (связи) между его составными частями и другие данные в зависимости от его назначения [2].
Согласно [3] информационная модель изделия (ИМИ) - совокупность данных и отношений между ними, описывающая различные свойства реального изделия, интересующие разработчика модели и потенциального или реального пользователя. В свою очередь, электронная модель изделия (ЭМИ) по [3, 4] - это электронный конструкторский документ, содержащий электронную геометрическую модель детали или сборочной единицы, соответствующие электронные геометрические модели составных частей, свойства, характеристики и другие данные, необходимые для сборки (изготовления) и контроля. Таким образом, ЭМИ является частным случаем ИМИ. Именно ИМИ отражает данные о проектируемой сущности с той или иной точки зрения, например, ИМИ электрического или конструкторского проектирования, теплового моделирования и т. д.
Подводя итог описанию информационных сущностей, создающихся в процессе проектирования РЭА, можно сделать вывод, что ЭСИ и ИМИ являются первичными документами для получения различных конструкторских документов (КД), входящих в основной и полный комплекты КД согласно [4]. Например, спецификация, один из самых важных конструкторских документов, необходимый для производства изделия, формируется на основе данных информационных моделей, разработанных в различных САПР: при электрическом и при механическом проектировании. Изменение этих ИМИ и ЭСИ влечет изменение остальной КД. Этот факт должен являться базисом для разработки правил интеграции ИС с точки зрения технологий непрерывной поддержки ЖЦ изделия.
Требования к интеграции САПР и СУД
В соответствии со спецификой проектирования РЭА, можно выделить следующие основные требования к интеграции ИС:
• СУД является централизованным хранилищем всех характеристик изделия, проектируемых в различных САПР;
• исключение дублирования данных;
• автоматическая синхронизация данных в различных ИС;
• автоматическое формирование КД;
• накопление данных и опыта, возможность использования информации из предшествующих проектов разработки изделий.
Обобщая вышеуказанные требования к интеграции САПР и СУД, можно сделать вывод, что они сводятся к анализу правил хранения и обработки данных в ИС. Согласно ГОСТ 34.32196, они описываются схемой данных. Основным отличие СУД от систем электронного документооборота является их направленность на проектную специфику деятельности [5]. Разработка изделия выполняется в рамках проекта, который является хранилищем всех связанных с изделием информационных сущностей (ЭСИ, ИМИ, КД). В современных СУД предусмотрено логическое разделение информационных сущностей и представление их в виде структурированной совокупности однотипных объектов, например, дерево проектов, дерево элементов, дерево документов, дерево материалов и т. д. При этом все информационные сущности, относящиеся к одному изделию, связаны между собой (рис. 1).
Проекты
Документы
Проект_1
Проект_2
Гг
I.
Проект_п
Ґ "Ч Ґ >
Изделия Документу
Документ_1
Документ_2
Изделие_1
___ Структура
изделия_к
V
г- ^ г \
Изделие_2 Элемент_^1
V-
Изделие_п
Элемент к 2
Элемент_к_п
у
Рис. 1. Схематичное представление иерархии и взаимосвязи информационных сущностей в СУД в виде структурированных деревьев
С точки зрения объектно-ориентированного подхода, семантическая типизация информационных сущностей в схеме данных СУД означает выделение объектов с одинаковым поведением в классы с одним набором характеристик-атрибутов. Таким образом, схема данных является объектной моделью, которая описывает структуру объектов, составляющих систему, их атрибуты, операции, взаимосвязи с другими объектами. Такое представление информационных сущностей с точки зрения объектно-ориентированного подхода должно являться базисом для интеграции ИС. Это означает, что разработанная в САПР сущность (ИМИ, ЭСИ) должна быть без потерь экспортирована в систему управления данными, что обеспечивается наличием в СУД соответствующих контейнеров (классов с необходимым набором атрибутов). На рис. 2 показана упрощенная схема передачи информационных сущностей из САПР в СУД для реализации программного сопряжения ИС.
Рис. 2. Схема передачи информационных сущностей из САПР в СУД
Рассматривая информационные сущности, разработанные в САПР, с точки зрения объектной модели данных СУД, следует отметить, что импортируемая из ИМИ и формируемая на ее основе КД обладают поведением документа. В свою очередь, ЭСИ должна быть интегрирована в дерево элементов. Таким образом, при экспорте данных из САПР в СУД необходимо генерировать объекты соответствующих классов в рамках одного проекта и одного изделия. Кроме того, поскольку СУД является многопользовательской ИС, необходимо предусмотреть авторизацию входа в СУД при импорте данных из САПР. На рис. 3 показан обобщенный алгоритм действий, который необходимо выполнить в СУД при загрузке данных из САПР.
Рис. 3. Алгоритм действий, выполняемых в СУД при загрузке данных из САПР
Технические средства программной интеграции САПР и СУД
Кроме концептуальной стороны вопроса о сопряжении ИС, следует также определить технические средства для решения данной задачи. Можно выделить несколько наиболее популярных на сегодня методов интеграции приложений:
• обмен файлами, в которые помещаются общие данные;
• общая база данных (БД), в которой сохраняется общая информация;
• удаленный вызов процедур для выполнения действий или обмена данными;
• система обмена сообщениями, которые используются для обмена данными и выполнения действий;
• веб-сервисы, в том числе ESB и SOAP.
Выбор определенного метода из данного списка зависит от специфики связываемых ИС, например, в случае веб-приложений наиболее эффективным будет последний вариант. Однако если сопрягаемые ИС функционируют как настольные приложения, что часто распространено среди САПР и СУД, данный метод не подойдет. Обмен файлами и общая БД также не уместны из-за различных схем данных сопрягаемых ИС. Таким образом, следует рассмотреть интеграцию САПР и СУД с помощью удаленного вызова процедур и асинхронного обмена сообщениями. Принимая во внимание вышеприведенный алгоритм интеграции САПР и СУД, можно сделать вывод, что его действия, по сути, представляют собой вызов интерфейсных функций СУД. Это может быть реализовано с помощью современных технологий создания программного обеспечения (ПО) на основе взаимодействующих компонент, каждая из которых может использоваться во многих ИС одновременно. Принципы этого подхода к программированию закреплены в виде технологического стандарта компании Microsoft, называемого COM (от англ. Component Object Model).
Стандарт COM поддерживает положения ООП (инкапсуляцию и полиморфизм), но основным его понятием является COM-компонент. Программы, построенные на стандарте COM, фактически не являются автономными программами, а представляют собой набор взаимодействующих между собой COM-компонентов. Каждый компонент имеет уникальный идентификатор и может одновременно использоваться многими программами. Компонент взаимодействует с другими программами через COM-интерфейсы - наборы абстрактных функций и свойств.
Windows API (от англ. Application Programming Interface) предоставляет базовые функции, позволяющие использовать COM-компоненты. Библиотеки MFC (от англ. Microsoft Foundation Classes - библиотека на языке C++, разработанная Microsoft и призванная облегчить разработку приложений с графическим интерфейсом для Microsoft Windows) и, особенно, ATL (от англ. Active Template Library - набор шаблонных классов языка C++, разработанных компанией Microsoft для упрощения написания COM-компонентов) и WTL (от англ. Windows Template Library - свободно распространяемая библиотека шаблонов C++, предназначенная для облегчения разработки приложений с графическим интерфейсом для Microsoft Windows) предоставляют гораздо более гибкие и удобные средства для работы с COM. Главное достоинство COM - независимость от языка программирования и исполняющей среды.
Таким образом, интерфейсные функции СУД из вышеприведенного алгоритма интеграции СУД и САПР могут быть реализованы посредством COM-компонент, которые, в связи с их многократным использованием, логично объединить в динамически подключаемую библиотеку (DLL, англ. dynamic-link library). Однако данные действия являются вспомогательными в решении проблемы интеграции САПР и СУД и не обеспечивают ее главную задачу - экспорт данных ИМИ и ЭСИ. Для этого необходимо передать в COM-объект информацию из САПР в виде массива данных унифицированного формата. В настоящее время универсальными форматами данных принято считать языки разметки, например, XML. Но для использования преимуществ объектноориентированного подхода COM рационально выбрать формат разметки, поддерживающий эту методологию. Одним из таких форматов является JSON (JavaScript Object Notation). Он основан на подмножестве языка программирования JavaScript, определенного в стандарте ECMA-262, третья редакция. Несмотря на происхождение от JavaScript, формат считается языконезависимым и может использоваться практически с любым языком программирования. Для многих языков существуют функции для создания и обработки данных в формате JSON.
JSON представляет собой правила для описания универсальных структур данных, называемых в разных языках программирования по-разному (например, объект, запись, структура, словарь, хэш, именованный список или ассоциативный массив, массив, вектор, список или последовательность и т. д.) с помощью простого синтаксиса разметки: (), {}, [], “”, / и т. д., подобно XML. Таким образом, JSON подходит для описания сложных структур в силу удобочитаемости и лаконичности, а также меньшим размером файла по сравнению с XML.
Разработанная авторами статьи технология интеграции САПР и СУД графически представлена на рис. 4.
Рис. 4. Обобщенная схема технологии интеграции САПР и СУД
Пример программной интеграции СУД Enovia SmarTeam и САПР Altium Designer
В качестве примера вышеизложенных аспектов интеграции САПР и СУД, необходимой при проектировании РЭА в соответствии с концепцией технологий непрерывной информационной поддержки ЖЦ изделий, командой разработчиков с участием авторов статьи был реализовано программное сопряжение САПР Altium Designer и СУД Enovia SmarTeam. Работа выполнялась в рамках ОКР «Разработка комплекса программных и технических средств проектирования, изготовления и испытаний унифицированного ряда электронных модулей на основе технологии «система-на-кристалле» для систем управления и электропитания космических аппаратов (КА) связи, навигации и дистанционного зондирования Земли с длительным сроком активного существования» по договору с ОАО «Информационные спутниковые системы» (г. Железногорск, Красноярский край).
Интеграция САПР Altium Designer и СУД Enovia SmarTeam предназначена для выполнения следующих функций:
• получение из проекта САПР Altium Designer данных о файлах, подключенных к проекту, списка схем, списка электрорадиоизделий (ЭРИ) на схемах и создание в СУД Enovia SmarTeam соответствующих объектов классов «Проект Altium» и «Файл Altium» с целью помещения в них данных ИМИ для выбранной пользователем сборочной единицы;
• формирование КД вида «Перечень элементов» в формате PDF в СУД Enovia SmarTeam для выбранной пользователем сборочной единицы;
• формирование ЭСИ в СУД Enovia SmarTeam - объектов класса «Прочие изделия» для выбранной пользователем сборочной единицы.
Учитывая поддержку Windows API в интегрируемых ИС, рационально использовать преимущества данного средства разработки. Для предоставления объектно-ориентированных API или сервисов другим приложениям, используется объектная модель компонентов COM. Таким образом, задача интеграции САПР Altium Designer и СУД Enovia SmarTeam сводится к формированию COM-объекта из САПР и его обработка в Enovia SmarTeam. При этом информация из САПР поступает в COM-объект в виде массива данных унифицированного формата JSON. Следует отметить, что, помимо ИМИ и ЭСИ, данный файл также включает сведения о разработчике, контролере и другую информацию, необходимую для формирования КД.
Перед тем как приступить непосредственно к описанию механизма разработанной интеграции ИС, следует пояснить особенности представления данных об изделии в сопрягаемой САПР. В основе Altium Designer лежит программная платформа DesignExplorer, объединяющая различные модули для реализации всех функций сквозного автоматизированного проектирования: редактор схем, печатных плат, автотрассировщик, программу моделирования схем РЭС,
CAM-средства и др. Функциональность каждого компонента Altium Designer по отношению к другим может быть расширена через его собственный API (например, Shematic API), а также общий WorkSpace API. Это осуществляется с помощью выполнения скриптов, написанных на различных скриптовых языках (DelphiScript, EnableBasic, VisualBasic Script, JavaScript). В разработанной программной системе интеграции САПР Altium Designer и СУД Enovia SmarTeam для получения полного перечня ЭРИ (со схемы и с печатной платы), а также их характеристик, был реализован скрипт на языке Visual Basic Script.
Начальной точкой каждого конструктивного решения в Altium Designer является проект - набор документов с однозначной трактовкой данных. Например, схема и плата в проектных данных представляют собой набор файлов для изготовления единственной печатной платы, в то время как схема и текст HDL в проектных данных для программируемой логической интегральной схемы представляют собой набор файлов, необходимых для ее программирования. Комплект документов, которые создают проект, формируется совместно с файлом проекта. Файл проекта содержит все установки, включая связи с каждым документом в проекте и все проектно-зависимые опции. Каждый документ в проекте записывается как отдельный файл, который связан с проектом через относительные ссылки к файлам на одном и том же логическом устройстве или абсолютные ссылки на файлы на различных логических устройствах. Выходные данные, генерируемые из проекта, также ссылаются на проектный файл.
Таким образом, в проекте Altium Designer содержатся файлы двух типов: логические (схемы, печатные платы, файл проекта) и сгенерированные (файлы отчетов). Для экспорта данных из САПР в СУД необходимо перенести весь проект Altium Designer, поэтому необходимо использовать WorkSpace API.
На основе вышеизложенных положений разработана программная модульная система интеграции САПР Altium Designer и СУД Enovia SmarTeam, которая представляет собой COM-компонент, взаимодействующий с внешними программными системами посредством COM-интерфейсов. Большая часть механизма интеграции указанных ИС реализована средствами языка программирования C# и функционирует в общеязыковой среде выполнения CLR. Структура программной системы интеграции и схема взаимодействия с сопрягаемыми ИС показана на рис. 5.
Рис. 5. Структура программной системы интеграции и схема взаимодействия с сопрягаемыми ИС
Разработанная программная система интеграции состоит из следующих частей:
• Модуль getSchemeComponentForm обеспечивает чтение данных об изделии из проекта Altium Designer, сохранение этих данных в файл в формате JSON и передачу управления модулю AltiumToEnoviaSmarTeam.
• Модуль AlitumToEnoviaSmarTeam обеспечивает проведение аутентификации пользователя, выбор пользователем проекта Enovia SmarTeam, выбор пользователем сборочной единицы, а также создание в Enovia SmarTeam объектов классов «Проект Altium» и «Файл Altium» в соответствии с данными, полученными из проекта Altium Designer.
• Модуль AltiumSupport запускается по запросу пользователя из СУД Enovia SmarTeam и обеспечивает формирование КД вида «Перечень элементов» в формате PDF и структуры выбранной сборочной единицы на основе данных ИМИ, хранящихся в СУД Enovia SmarTeam.
• Модуль CommonUtils используется другими модулями программной системы интеграции, поскольку содержит общие функции для работы с СУД Enovia SmarTeam и с форматом JSON.
Описанный пример интеграции САПР и СУД является лишь частью работы по организации единого информационного пространства для процессов проектирования и производства РЭА. В рамках этой задачи еще необходимо решить вопросы сопряжения САПР механического и электрического проектирования, а также обмена информацией СУД с другими ИС, использующимися для непрерывной поддержки на протяжении ЖЦ изделия.
Выводы
Итак, описанная в статье задача интеграции информационных систем, используемых для проектирования РЭА, включает детальную проработку следующих компонентов:
• концептуальные понятия информационных сущностей и их взаимосвязь;
• специфические правила хранения и обработки информации в САПР и СУД, согласно схеме данных этих видов ИС;
• требования к сопряжению ИС с точки зрения предметной области;
• технические средства реализации.
Формализованное представление описанных в статье приемов в виде взаимосвязанных методик, моделей и алгоритмов полезно при выполнении работ по организации единого информационного пространства приборостроительных предприятий.
СПИСОК ЛИТЕРАТУРЫ
1. Виды изделий. ГОСТ 2.101-68. Взамен ГОСТ 5290-60; введ. 01.01.1971. - 3 с.
2. Электронная структура изделия. Общие положения. ГОСТ 2.053-2006. введ. 01.09.2006. - 11 с.
3. Электронная модель изделия. Общие положения. ГОСТ 2.052-2006. введ. 01.09.2006. - 14 с.
4. Виды и комплектность конструкторских документов. ГОСТ 2.102-68. введ. 01.01.1971. - 11 с.
5. Вичугова А.А., Вичугов В.Н., Дмитриева Е.А. Жизненный цикл документа в информацион-
ных системах управления данными // Вестник науки Сибири. Серия: Информационные технологии и системы управления. - 2011. - № 1. - C. 328-334. URL:
http://sjs.tpu.ru/journal/issue/view/2/showToc/sect/4 (дата обращения: 15.12.2011).
Поступила 19.12.2011 г.
