Рассмотрена архитектура базы данных расширяемого автоматизированного программного комплекса для проведения механического анализа бортовой радиоаппаратуры космических аппаратов. Описаны нестандартные приемы организации и расширения спектра хранимых данных. Описан состав и назначение служебных и рабочих таблиц реляционной базы данных, а также структура файлового архива дополнительных материалов. Выделены особенности структурирования базы данных, обусловленные технологией проектирования и производства бортовой радиоаппаратуры космических аппаратов. Созданная база данных опробована в составе прототипа интегрированной системы, получены удовлетворительные результаты.
Database of the integrated system for the mechanical analyses of the spacecraft on-board electronic equipment.pdf Для автоматизации проведения механического анализа бортовой радиоаппара-туры космических аппаратов создается аппаратно-программный комплекс, интег-рирующий различные системы проектирования и инженерного анализа. Комплексимеет модульную архитектуру, где функционал подготовки расчетной модели,непосредственного расчета и обработки результатов разнесен по отдельным про-граммным библиотекам (DLL-модулям). Неотъемлемой частью данного комплек-са является база данных (БД), обеспечивающая хранение исходных сведений дляпроведения расчетов (в том числе геометрические модели), данные самих расче-тов и результаты их обработки. БД программного комплекса сочетает в себе ре-ляционную базу данных табличного типа и файловую библиотеку дополнитель-ных материалов. Доступ к БД организован через набор программных интерфей-сов, реализованных в виде специального субмодуля.Содержимое файловой библиотеки можно разделить на три категории: архивмоделей (геометрические модели и шаблоны конечно-элементных моделей), ар-хив вариантов расчета (подготовленные «программы» для исполнения встроен-ным или внешним CAE-решателем и полученные результаты расчетов), времен-ные файлы (файлы, не имеющие практической ценности за рамками текущей сес-сии работы с программным комплексом).При проектировании реляционной БД было применено несколько нестандарт-ных решений. Одно из них - создание ряда служебных таблиц. Эти таблицы ис-пользуются для унификации встраивания элементов редактирования БД в графи-ческую оболочку комплекса, а также для описания нестандартных межтабличныхсвязей и типов данных.Служебные таблицы БД представлены в следующем составе: TABLES - описание (список) таблиц БД; FIELDS - описание полей каждой таблицы; ENUMS - описание предустановленных наборов значений (сопоставленныепары имени и значения); TYPES - описание типов элементов, на которые организованы перекрестныессылки в рабочих и служебных таблицах; SETTINGS - описание настроек суб-модулей программного комплекса.Несмотря на то, что большинство современных систем управления базамиданных (СУБД) предоставляют возможности получения списка таблиц и ихструктуры, наличие (создание) в произвольной базе таблиц TABLES и FIELDSпозволяет получить ряд дополнительных возможностей представления и обработ-ки данных. Кроме того, унификация алгоритмов работы с БД обеспечивает пер-спективу дальнейшего развития комплекса в части интеграции с базами различ-ной структуры и назначения, а также базовую совместимость последующих вер-сий комплекса.Некоторые рабочие параметры комплекса удобно представлять в виде вариан-та из предустановленного набора значений или так называемого перечисления (например, «Да» - «Нет» или «Линейная нагрузка» - «Вибрационная нагрузка» -«Ударная нагрузка»). Для хранения подобных наборов значений предназначенатаблица ENUMS. При дальнейшем развитии функционала становится возможнымдобавлять новые варианты значений в уже имеющиеся наборы, сохраняя совмес-тимость расчетных данных и настроек от предыдущих версий комплекса.Большинство рабочих (неслужебных) таблиц БД организовано так, что для за-писей предусмотрено внутреннее структурирование (группировка). То есть неко-торые из табличных записей являются служебными и не содержат иной полезнойинформации, кроме индекса и имени подгруппы(заголовки подгрупп). Все записив такой таблице содержат ссылку на определенную «родительскую» подгруппу втой же таблице. Подобная организация структурирования данных лишь в незна-чительной степени увеличивает пространство, требуемое для хранения таблицы(за счет отказа от полезного использования большинства полей в записи подгруп-пы). Однако, при этом отпадает необходимость в ведении дополнительной табли-цы описания подгрупп и реализации соответствующих процедур поддержки цело-стности данных. Кроме того, значительно облегчается и сам процесс структури-рования записей, поскольку он ограничивается работой только с одной (текущей)таблицей. Структурирование данных необходимо исключительно для удобстваработы пользователя. Оно находит применение, в частности, при выборе нужногоматериала или электрорадиоизделия из соответствующей таблицы. Названия под-групп в этом случае могут быть заданы самим пользователем, исходя из удобнойему классификации материалов и радиоэлементов.Еще одним нестандартным решением для реляционной БД является введениетаблицы компоновочного типа. Таблица компоновочного типа служит, в частно-сти, для описания компоновки конструктивных элементов изделия, где для эле-ментов различных типов (электрорадиоизделия, платы, несущие рамки, крепленияи пр.) необходимо задать иерархическую структуру взаимного расположения иподчиненности. Необходимость введения таблицы подобного рода обусловленатехнологией проектирования радиоэлектронной аппаратуры, в которой докумен-тация на разработку печатной платы, её монтирование в блоке и монтированиеблока в приборе, как правило, ведется в различных системах координат. То естьэлектрорадиоизделия располагаются относительно платы, плата - относительноблока, блок - относительно «нулевой» точки прибора.Иерархия элементов в таблице компоновочного типа обеспечивается поддерж-кой группировки элементов, как в структурированных таблицах. То есть таблицакомпоновочного типа является развитием структурированной таблицы. Здесь рольподгрупп могут играть как служебные, так и рабочие записи, а ссылка на типовойэлемент конструкции организуется не одним полем (индекс элемента в стороннейтаблице), а двумя (индекс элемента и индекс типа элемента). Естественно, при та-кой организации ссылок решение задачи поддержки целостности данных целикомперекладывается с СУБД на суб-модуль комплекса по работе с БД.Состав и наполнение рабочих таблиц БД во многом определяется технологиейпроизводства бортовой радиоаппаратуры космических аппаратов, а также мето-дами моделирования механических нагрузок [1,2]. В проектируемом комплексеиспользуются следующие таблицы: CCS - описание компоновочной схемы; CHASSIS - описание вспомогательных элементов конструкции; FRAMES - описание несущих рамок; PCBS - описание монтажных плат; PIES - описание слоистых структур; ERIS - описание электрорадиоизделий; FORMS - описание вспомогательных стандартных форм (плоских и про-странственных);Для обеспечения проведения механического анализа состав БД дополнен сле-дующими таблицами: FEMMODELS - описание шаблонов конечно-элементных моделей; MATERIALS - описание материалов и критериев их разрушения; CONFIGURATIONS - описание расчетных конфигураций; VARIANTS - варианты значений табличных полей для каждой конфигурации.Таблица CHASSIS предназначена для описания элементов конструкции, кото-рые выполнены из однородного материала. Это могут быть, например, крепежныеэлементы, рамы, кронштейны, панели корпуса прибора. Кроме того, в даннуютаблицу можно заносить макро-сборки и блоки, данные о детализации которыхотсутствуют. Таким образом, можно проводить оценочные расчеты изделия дажене имея детальной информации обо всех его блоках.Технология изготовления унифицированных электронных модулей бортовойрадиоаппаратуры космических аппаратов предполагает создание печатных платзаданной формы в виде многослойной структуры из металлизированного стекло-текстолита, клея и диэлектрических пленок с последующим закреплением на теп-лоотводящей металлической пластине несущей рамки. И плата, и рамка имеютстандартный прототип формы, в которой могут быть сделаны индивидуальныевырезы. Для хранения всего комплекса информации о платах и несущих рамкахпредназначены таблицы PCBS, FRAMES, PIES и FORMS.Описание радиоэлементов в таблице ERIS имеет ряд существенных особенно-стей. При проектировании бортовой радиоаппаратуры космических аппаратов со-блюдаются определенные правила, по которым, например, радиодетали опреде-ленного типа помещаются только на плату, а другие - только на корпус блока. Тоесть для удобства ручной компоновки изделия полезно предусмотреть иерархиюсовместимых типов элементов. Наконец, для облегчения пользовательской клас-сификации удобно иметь возможность не только структурировать, но и типизиро-вать записи таблицы ERIS (например, различать резисторы, конденсаторы и т.д.).Для реализации этой возможности в таблице TYPES кроме индекса и описаниятипа элемента (включая иерархию совместимости) также хранится индекс табли-цы, в которой расположены элементы данного типа. Таким образом, ссылка натип конструктивного элемента присутствует как в компоновочной таблице CCS,так и в простой структурированной таблице ERIS. Кроме того, на этапе заданияконечно-элементной модели для электрорадиоизделия важно указать материалыкорпуса и выводов, способ крепления и критерии разрушения.Центральное место в БД комплекса занимает таблица CCS. Она является от-правной точкой для формирования расчетного задания для выделенного прибора,блока или группы элементов. Несмотря на то, что информация о компоновке из-делия уже имеется в БД ОАО «ИСС» в стандартном табличном виде, эти сведенияимпортируются в БД комплекса и преобразуются в необходимую иерархическуюструктуру «дерева» компоновки.При проектировании прототипа автоматизированного комплекса возникла не-обходимость расширения типового набора форматов данных, хранимых в БД. Так,возникла необходимость на базе целочисленного формата различать обычноечисло, набор битовых флагов или код цветности, а на базе строкового формата -обычный текст, IP-адрес, пароль доступа, путь к файлу или структуру данных вкодировке Base-64. При этом ставилась цель максимально снизить зависимостьоболочки комплекса от структуры подключаемой БД и унифицировать соответст-вующие алгоритмы обработки данных. В результате необходимые характеристи-ки (типы и признаки) табличных полей были описаны в таблице FIELDS иSETTINGS, а в оболочку программного комплекса встроены необходимые эле-менты отображения и редактирования данных.Рис. 1. Прототип графической оболочки расчетного комплекса со встроеннымисуб-модулями доступа к БД, импорта, отображения пространственных моделейСозданная база данных была опробована в составе прототипа расчетного ком-плекса (рис. 1). Предварительное тестирование показало удовлетворительную ра-ботоспособность полного спектра средств доступа и редактирования БД, а такжеуспешное взаимодействие с субмодулями импорта данных из БД ОАО «ИСС» иотображения пространственных моделей.
Бовсуновский Александр Борисович | Национальный исследовательский Томский государственный университет | научный сотрудник НИИ прикладной математики и механики | Alexander.Bovsunovsky@niipmm.tsu.ru |
Ящук Алексей Александрович | Национальный исследовательский Томский государственный университет | кандидат физико-математических наук, старший научный сотрудник НИИ прикладной математики и механики | rainbow@niipmm.tsu.ru |
Хвалько Александр Александрович | ОАО «Информационные спутниковые системы» имени академика М. Ф. Решетнева | инженер-конструктор | hvalko@iss-reshetnev.ru |
Stephen A. McKeown. Mechanical analyses of electronic packaging systems. N.Y.: Marcel Dekker Inc, 1999. P. 13−21.
Автоматизированное моделирование конструкций радиоэлектронных средств (РЭС) при комплексных воздействиях // Информационные технологии в проектировании, производстве и образовании: сб. трудов Российской научно-технической конференции, посвящ. 50-летию КГТУ и 10-летию кафедры «Прикладная математика и САПР», Ковров, июнь, 2002. Ковров: Изд-во Ковров. гос. технол. акад., 2002. С. 124−126.