Software & Systems

Проектирование приборов, в частности радиоэлектронной аппаратуры (РЭА), – это совокупность технологически сложных процессов, которые характеризуются высоким уровнем приме- нения современных информационных систем и технологий, а также взаимодействием большого количества различных специалистов (схемотехники, конструкторы, топологи и др.).

Главным результатом проектирования является конструкторская документация, необходимая для производства новой продукции. Кроме того, в настоящее время состав комплекта конструкторской документации дополняется его электронной моделью, которая используется для получения чертежей и должна содержать полный набор конструкторских и физических параметров, необходимых для выполнения расчетов и математического моделирования. Однако проектирование включает в себя не только разработку массогабаритных свойств изделия посредством его электронной модели, но и определение других характеристик, необходимых для производства и эксплуатации изделия, например электромагнитных параметров и пр. Для моделирования, расчетов и анализа применяются САПР. Разрабатываемый в САПР виртуальный образец продукции называется информационной моделью изделия (ИМИ). Согласно ГОСТ 2.053-2006, ИМИ является источником данных для формирования конструкторской документации, необходимой для производства продукции. Фактически ИМИ представляет собой файл формата САПР для описания каких-либо свойств изделия. Например, твердотельная ИМИ, созданная в САПР SolidWorks, используется на этапе механического проектирования изделия; ИМИ для описания электрических свойств изделия может представлять собой набор файлов проекта, разработанного в САПР Altium Designer, и т.д. Кроме того, ИМИ отражает состав изделия с точки зрения иерархической совокупности его составных частей, которую принято называть электронной структурой изделия (ЭСИ).

Таким образом, ИМИ является первичным документом для получения ЭСИ и различных конструкторских документов. Например, специфи- кация, один из самых важных конструкторских документов, необходимых для производства изделия, формируется на основе ЭСИ и данных из информационных моделей, разработанных в различных САПР. Изменение ИМИ влечет изменение конструкторской документации. Поскольку функции интерактивного проектирования и инженерных расчетов реализуются в ИМИ, основным назначением конструкторской документации становится статическое представление информации об изделии по ГОСТ 2.102-68.

Обобщая понятия создаваемых в процессе проектирования сущностей (изделие, ИМИ, ЭСИ, конструкторская документация), примем единый термин для их обозначения. Рекомендуется использовать понятие «объект проектирования» [1]. Таким образом, далее под этим термином подразумеваются проектируемое изделие, его информационные модели и конструкторские документы, необходимые для его производства.

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

Информационные системы и технологии для поддержки процессов проектирования изделий

Для структурированного хранения информации об изделии применяются информационные технологии поддержки жизненного цикла продукции, которые принято называть PLM (Product LifeCycle Management). Центральное место в PLM-технологиях занимает информационная система управления данными (СУД) о продукции. Кроме структурированного хранения информации об изделии, для реализации полноценного управления данными СУД должна поддерживать интеграцию с другими программными средствами, использующимися для поддержки жизненного цикла изделия, в частности САПР.

Существует множество готовых программных продуктов от крупнейших российских и мировых компаний-разработчиков ПО (ENOVIA, Smar­Team, Вертикаль, Lotsia PLM, Oracle PLM, Wind­chill, SAP PLM, TeamCenter, T-FLEX DOCs, ЛОЦ­МАН:PLM, 1C: PDM 2.0). Однако несмотря на множество решений для различных отраслей промышленности, остается актуальной задача настройки правил хранения и управления информацией в СУД к специфике предметной области, включая особенности предприятия. В частности, изделия космического приборостроения разрабатываются в нескольких вариантах – для каждой стадии испытаний наземно-экспериментальной отработки, например, лабораторно-отработочных, конструкторско-доводочных и т.д. Аналитический обзор существующих СУД не выявил готовых программных решений для специфики отрасли космического приборостроения, которая включает проектную организацию деятельности, сложную структуру взаимосвязей объектов проектирования и взаимозависимую динамику изменения их жизненного цикла. Поэтому адаптация СУД к решению этих задач имеет высокую практическую значимость.

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

На рисунке 1 показана взаимосвязь объектов проектирования. Например, Проект_2 из существующего множества проектов сопровождается набором документов, объединенных в дерево документов. В рамках Проекта_2 осуществляется разработка Изделия_1, которое состоит из множества Элементов, образующих структуру изделия. Информация об Изделии_1 фиксируется в связанном с ним Документе_n.

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

Концептуальное проектирование модели данных СУД

Для управления жизненным циклом объектов проектирования в модели данных СУД необходимо предусмотреть следующие классы объектов: «Проекты», «Изделия», «ЭСИ», «Документы». При этом между данными классами существуют определенные отношения:

-      в рамках одного проекта может выполняться разработка одного или более изделий;

-      для одного изделия может существовать множество вариантов его электронной структуры;

-      к одному проекту может относиться множество документов;

-      ЭСИ и ее составные части описываются одним (или более) документом;

-      к одному изделию может относиться один (или более) документ.

Рассматривая специфику прикладной области, следует детализировать состав ЭСИ. В ГОСТ 2.101-68 устанавливаются следующие виды изделий: детали, сборочные единицы, комплексы и комплекты. Между ними существуют отношения:

-      в состав сборочной единицы могут входить детали, комплекты и другие сборочные единицы;

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

-      в комплекс могут входить детали, сборочные единицы, комплекты, а также другие комплексы.

Кроме того, согласно выделению разделов спецификации по ГОСТ 2.106-96, изделия и их составные части также принято делить на стандартные, прочие и материалы, непосредственно входящие в специфицируемое изделие, иногда их называют «изделия из материалов».

Стандартные изделия используются по межгосударственным, государственным и отраслевым стандартам, а также стандартам предприятий; прочие – по техническим условиям, а импортные – по сопроводительной технической документации зарубежных изготовителей (поставщиков).

В рамках данной классификации электрорадиоизделия (ЭРИ), которые являются основой РЭА, относятся к прочим изделиям. Учитывая компонентный состав ЭСИ, следует согласно принципу подстановки [4] объявить данный класс базовым (суперклассом). Его подклассами будут составные части изделия по ГОСТ 2.106-96, ГОСТ 2.108-68, ГОСТ 2.112-70: «Стандартное изделие», «Комплект», «Деталь», «Сборочная единица», «Прочее изделие», «Изделие из материала». При этом между данными подклассами суперкласса «ЭСИ» существуют следующие отношения:

-      к одному экземпляру класса «Комплект» может относиться множество экземпляров классов «Деталь», «Сборочная единица», «Стандартное изделие», «Комплект»;

-      к одному экземпляру класса «Сборочная единица» может относиться множество экземпляров классов «Деталь», «Сборочная единица», «Прочее изделие», «Изделие из материала», «Стандартное изделие».

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

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

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

Таким образом, применительно к исследуемой специфике космического приборостроения на этапе концептуального проектирования СУД класс «ИМИ» следует объявить абстрактным, потомками которого будут два базовых класса: MCAD (Mechanical Computer Aided Design), используемый для хранения сущностей механического проектирования, которыми являются файлы, экспортированные в СУД из соответствующих САПР; ECAD (Electrical Computer Aided Design), используемый для хранения сущностей электрического проектирования, которыми являются файлы, экспортированные в СУД из соответствующих САПР.

В свою очередь, классы MCAD и ECAD име- ют потомков, при этом между данными классами существуют следующие отношения: MCAD_As- sembly, используемый для хранения сборки, с которой ассоциируется множество экземпляров классов сборки MCAD_Assembly и деталей MCAD_Part; ECAD_Project, используемый для хранения проекта, с которым ассоциируется множество экземпляров класса входящих в него файлов электрических схем, печатных плат, программного кода ECAD_File.

Поскольку фактически ИМИ и конструкторская документация являются документами, целесообразно объявить класс «Документы» абстрактным суперклассом, потомками которого будут суперклассы «конструкторская документация» и «ИМИ». В свою очередь, ГОСТ 2.102-68 регламентирует состав основного и полного комплектов конструкторской документации, которые включают множество отдельных текстовых, табличных и графических документов. Однако в связи с большим количеством документов в составе конструкторской документации на этапе концептуального проектирования БД СУД целесообразно не детализировать потомков данного базового класса. Поскольку первоисточником данных для конструкторских документов является совокупность файлов САПР, импортированных в СУД, следует отметить, что один экземпляр класса «конструкторская документация» может ассоциироваться с множеством экземпляров класса «ИМИ».

Кроме того, следует учитывать, что в реальности каждый элемент изделия выполняется из одного или целого набора материалов. В свою очередь, каждый материал может описываться одним или несколькими документами. Следовательно, целесообразно выделить суперкласс «Материалы» и связать его с суперклассами «ЭСИ» и «Документы», используя следующие отношения ассоциации:

-      каждый экземпляр суперкласса «ЭСИ» может быть связан с множеством экземпляров суперкласса «Материалы»;

-      каждый экземпляр суперкласса «Материалы» может быть связан с множеством экземпляров суперкласса «Документы».

Суперкласс «Материалы» может быть детализирован на подклассы, однако в связи с большим количеством типов материалов на этапе концептуального проектирования БД СУД целесообразно не детализировать потомков данного базового класса.

Описанные взаимосвязи объектов проектирования и их компонентный состав можно формализовать с помощью языков графического моделирования. Одним из наиболее часто используемых в сфере программной инженерии языков моделирования является UML, который предоставляет широкие возможности для разработки алгоритмического базиса ПО и БД [5]. На рисунке 2 показана диаграмма классов модели данных СУД, составленная на основе вышеописанных взаимосвязей объектов проектирования и их компонентного состава.

Поскольку диаграмма классов с концептуальной точки зрения описывает модель предметной области [5], в ней присутствуют только те классы, которые описывают объекты проектирования (конструкторская документация, ИМИ, ЭСИ, Изделия) и связанные с ними сущности (Проект, Материал). Данная диаграмма описывает иерархию, состав и взаимосвязь объектов проектирования космического приборостроения. Кроме того, статическая структурная диаграмма позволяет формализовать отношения кратности между классами. Это используется на дальнейших этапах проектирования БД СУД, в частности, при определении отношений между сущностями в случае наиболее часто применяемой реляционной модели данных [3].

Предложенная структура хранения проектных данных была реализована в СУД Enovia Smar­Team, БД которой основана на объектно-реляци­онной модели. Для практического применения разработанной структуры взаимосвязи объектов проектирования рассмотрим пример выполнения проекта по разработке изделия «Блок электронный устройства поворота батареи солнечной». Данное изделие является составной частью космического аппарата (КА), поэтому его разработка фактически является одной из задач в составе комплекса работ по проектированию КА. В разработанной модели данных СУД Enovia SmarTeam экземпляр класса «Проект» является ключевым объектом, который обеспечивает семантическую связь между разнотипными сущностями (изделием, элементами его электронной структуры, документами) с помощью ссылок. Таким образом, проект представляет собой портфель данных о предмете разработки, а экземпляр класса «Проект» – контейнер для структурированного хранения информации о временных, стоимостных и качественных ограничениях (параметрах) работ. Под качественными характеристиками проекта по разработке изделия следует понимать соответствие разрабатываемого объекта требованиям технического задания.

Таким образом, целевым результатом проекта по разработке изделия является непосредственно само изделие. Поэтому с экземпляром класса «Проект», который хранит сведения общего характера о разрабатываемом изделии, связан экземпляр класса «Изделие», предназначенный для структурированного хранения обобщенной технической информации о проектируемом изделии, такой как, например, наименование, массогабаритные характеристики, функциональное назначение и т.д. Все эти данные являются значением атрибутов класса «Изделие». Поскольку специфика космического приборостроения предполагает одновременное существование нескольких вариантов изделия (на каждую стадию испытаний, например, лабораторно-отработочных, конструкторско-дово­дочных и т.д.), для отслеживания степени за- вершения проектирования на этих стадиях в разработанной модели данных СУД Enovia SmarTeam для класса «Изделие» введен соответствующий атрибут.

Компонентный состав разных версий изделия для каждой стадии испытаний реализуется с использованием объектов класса «ЭСИ». В разработанной модели данных СУД Enovia SmarTeam на верхнем уровне абстракции компонентный состав изделия аккумулируется объектом класса «Сборочная единица».

На рисунке 3 показаны иерархическая структура дерева проектов и взаимосвязь объектов различных классов в СУД Enovia SmarTeam, модель данных которой основана на типизации объектов согласно разработанной UML-диаграмме классов (рис. 2). Разработка изделия выполняется в рамках проекта, являющегося хранилищем всех связанных с изделием информационных сущностей: ИМИ, конструкторской документации и элементов ЭСИ. К экземпляру класса «Проект» присоединен экземпляр класса «Изделие»; к нему, в свою очередь, относятся несколько экземпляров класса «Сборочная единица» (ЭСИ), среди дочерних элементов которых показаны экземпляры классов «Прочие изделия» и «Детали».

Элементы ЭСИ подробно описаны в связанных с ними экземплярах классов «Документы», в файлах ИМИ и конструкторской документации, содержание и состояние которых определяют состояние объектов класса «ЭСИ».

Таким образом, в модели данных СУД Enovia SmarTeam, основанной на разработанной UML-диаграмме классов, не только осуществляется структурированное хранение информации об изделиях, формализованной в виде документов (ИМИ и конструкторской документации), но и визуализируется электронная структура изделия, которая используется в том числе для автоматической генерации некоторых конструкторских документов. Кроме того, большое внимание уделено поддержке версионности: объекты (ИМИ, конструкторская документация, изделие и элементы его электронной структуры) могут иметь различные версии, отражающие степень разработки или испытаний.

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

Разработанные модели позволяют формализовать взаимозависимости объектов проектирования и фактически являются алгоритмической основой для разработки программного обеспечения управления информацией о продукции, в частности, для разработки модели данных СУД в рамках PLM-решения.

Созданная UML-диаграмма классов моде- ли данных СУД нашла практическое применение при настройке СУД Enovia SmarTeam к задачам ОАО «Информационные спутниковые системы» имени академика М.Ф. Решетнева (г. Железногорск, Красноярский край). Однако общие положения относительно иерархии классов и связей объектов проектирования, описанные в работе, могут быть использованы при настройке и внедрении практически любой СУД в процессы проектирования и производства изделий различных отраслей промышленности.

Литература

1.     Боргест Н.М. Онтология проектирования: теоретические основы. Понятия и принципы: учеб. пособие. Самара: Изд-во СГАУ, 2010. Ч. 1. 88 с.

2.     Дейт К.Дж. Введение в системы баз данных = Introduction to Database Systems М.: Вильямс, 2006. 8-е изд. 1328 с.

3.     Кузнецов С.Д. Основы баз данных. М.: ИНТУИТ; БИНОМ. Лаборатория знаний, 2007. 2-е изд. 484 с.

4.     Liskov B., Program development in Java: Abstraction, specification and object-oriented design, 2001.

5.     Фаулер М., Скотт К. UML. Основы; [пер. с англ.]. СПб: Символ-Плюс, 2002. 192 с.

References

1.     Borgest N., Ontologiya proektirovaniya: teoreticheskie osnovy. Ponyatiya i printsipy: ucheb. posobie [Design ontology: theoretical foundations. Concepts and Principles: study guide], SSAU Publ., 2010.

2.     Date C.J., Introduction to Database Systems, 8th ed., Addison-Wesley, 2006.

3.     Kuznetsov S., Osnovy baz dannykh [Foundations of databases], 2nd ed., Moscow, INTUIT, BINOM, Laboratoriya Znaniy, 2007.

4.     Liskov B., Program development in Java: Abstraction, specification and object-oriented design, Addison-Wesley Professional, 1st ed., 2001.

5.     Fowler M., Scott K., UML Distilled: A Brief Guide to the Standard Object Modeling Language, 2nd ed., Addison-Wesley, 2000.