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

Ткаченко Иван Сергеевич; Ivan S. Tkachenko; Сафронов Сергей Львович; Sergey L. Safronov; Коровин Максим Дмитриевич; Maxim D. Korovin; Иванушкин Максим Александрович; Maxim A. Ivanushkin; Крестина Анастасия Владимировна; Anastasiya V. Krestina

doi:10.18287/2223-9537-2023-13-1-75-89

An information system to support preliminary design of small spacecraft

Authors: Tkachenko I.S.¹, Safronov S.L.¹, Korovin M.D.¹, Ivanushkin M.A.¹, Krestina A.V.¹
Affiliations:
1. Samara University (Samara National Research University named after academician S.P. Korolev)
Issue: Vol 13, No 1 (2023)
Pages: 75-89
Section: APPLIED ONTOLOGY OF DESIGNING
URL: https://journals.ssau.ru/ontology/article/view/26979
DOI: https://doi.org/10.18287/2223-9537-2023-13-1-75-89
ID: 26979

Cite item

Full Text

Abstract
Full Text
About the authors
References
Supplementary files
Statistics

Abstract

With the development of information technology, the role of support systems for the technical products design process has increased significantly. The capabilities of knowledge management systems make it possible to ensure the commonality of terminology, object definitions and relations between them. In addition, the use of formal semantics is necessary to support the reuse of knowledge. The article discusses ways to improve the efficiency of the small spacecraft design process and a creation of tools for the knowledge exchange about the functional characteristics of typical subsystems of such vehicles. The creation of an information system to support the preliminary design of small spacecraft, which contains information linked to the relationship between the functions and components of subsystems and their characteristics, is considered. The created system facilitates the synthesis of various product configurations. When developing the information system, modern approaches in the field of structural and functional classifications of small spacecraft systems and approaches existing in the field of taxonomy to create database structures were used. The information system database contains a set of characteristics for a wide range of small spacecraft equipment. As an example of the use of an information system to support the design of small spacecraft, the process of choosing the characteristics of a power supply system for a promising small spacecraft designed to provide communication between mobile ground terminals is considered..

Keywords

information system, small spacecraft, space platform, database, onboard system, design, user interface

Full Text

Введение

Исследования Земли из космоса с применением космических аппаратов (КА) проводятся уже более 60 лет, предоставляя людям всё большее количество необходимой и полезной информации. Без актуальной и качественной информации о состоянии объектов и явлений, связанных с поверхностью Земли и атмосферой, становится невозможным ведение эффективной деятельности в области метеорологии, экологии, экономики и других областях.

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

Разработка новых способов и развитие технологий проектирования и конструирования на базе подходов системной инженерии позволит не только решить актуальную проблему создания лёгких, эффективных и надёжных МКА, но и способствует снижению стоимости серийных изделий. За последние десятилетия было проведено много исследований в области повышения эффективности системной инженерии [2]. Системы управления знаниями позволят упростить представление природы и структуры инженерных систем и их компонентов, помочь различным заинтересованным сторонам лучше понять проблемы, характерные для сложных технических систем и их социотехнического окружения [3].

1. Контекст задачи проектирования

С формальной точки зрения контекст представляет собой определённую систему отсчёта, пространство имён. В более широком значении контекст — среда, в которой существует объект [4]. В большинстве моделей систем в области инженерного проектирования контекст оценивается редко или просто определяется как нечто, окружающее результаты проектной деятельности и придающее им смысл [5]. В настоящее время компании развиваются в условиях жёсткой конкуренции и постоянно меняющейся среды, и организациям приходится непрерывно адаптировать свои структуры, процессы и продукты для достижения успеха. Следовательно, сложность моделей, необходимых для представления систем, растёт, понятие контекста становится решающим.

Известны стандарты и обзоры, посвящённые различным аспектам системной инженерии: задачи и инструменты на основе моделей для сервис-ориентированной системной инженерии [6, 7]; подходы к архитектуре типа «система из систем» [8] и представлению знаний [9, 10], атрибутам качества [11], системной интеграции [12] и разработке требований [13, 14].

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

Хотя методы системной инженерии и своды лучших практик формализованы и широко представлены в различных монографиях и стандартах, на сегодняшний момент всё ещё не преодолены два существенных вызова: трудности с разработкой систем в рамках бюджета и в срок [15] и значительные потери ресурсов, связанные с исправлением ошибок [16-18].

В [15] выделены причины отсутствия успеха в преодолении этих вызовов, среди которых: ограниченность описаний лучших практик в форме метамоделей, отсутствие общепринятой и согласованной терминологии, неэффективное сотрудничество из-за непонимания и неправильной интерпретации.

В частности, отмечается необходимость гармонизации в интерпретации многочисленных стандартов и различных моделей [19]. Онтологии используются для обеспечения семантической совместимости как между людьми, так и между людьми и компьютерами. В[20] отмечается, что «системная наука и инженерия нуждаются в чётко определённой фундаментальной, универсальной, общей, необходимой и достаточной онтологии, которая бы лежала в основе понятий и терминов, которые она использует, чтобы они были точными и однозначными». В [21] подчёркивается ключевая роль единой информационной среды в контексте проектирования сложных технических систем.

Целью создания информационной системы (ИС) поддержки предварительного проектирования МКА является формирование единого информационного пространства, которое содержит сведения о работе МКА, его бортовых систем (БС) и об эффективности их совместного функционирования.

Настоящая работа посвящена обеспечению общего пользовательского контекста процессов предварительного проектирования МКА при помощи традиционных ИС на основе таксономических моделей ПрО.

2. Модель ПрО

МКА разрабатываются в соответствии с техническими заданиями, в которых определены их тактико-технические характеристики. Эти характеристики определяются по результатам проектирования системы, состоящей из наземного и космического компонентов.

Одним из направлений в проектировании, обеспечивающих эффективное решение задач создания МКА в короткие сроки, является использование платформенных принципов. Переход к построению МКА на базе крупных компонентов позволяет создавать семейство МКА, отличающихся по составу целевой аппаратуры, но имеющих общую платформу, включающую в себя набор обеспечивающих систем.

Платформа является базовой частью создаваемого на её основе МКА и представляет собой несущую конструкцию, снабжённую служебными системами и устройствами для функционирования целевой аппаратуры различного назначения, но с близкими эксплуатационными требованиями. Платформа должна состоять из базового и целевого состава обеспечивающих БС. Базовый состав одинаков для всего семейства МКА, целевой формируется на этапе адаптации платформы под конкретную задачу. Создание МКА на базе универсальных платформ широко применяется отечественными и зарубежными проектными организациями. Перечень основных технических требований, которые должны быть учтены при составлении задания на проектирование МКА, включает [22]: назначение; живучесть и стойкость к внешним воздействиям; надёжность; удобство технического обслуживания; транспортабельность; безопасность; технологичность; конструктивные требования; технико-экономические характеристики и др.

На рисунке 1 представлена таксономическая схема подсистем МКА, использованная при создании ИС. На схеме элементы без рамок представляют собой группы конкретных компонентов, информация о которых содержится в базе данных (БД) разработанной ИС. Блоки в рамках представляют абстрактные системы, необходимые для наглядности схемы.

Обеспечивающими системами являются системы, общие для МКА различного назначения: система , система электропитания, система обеспечения теплового режима, двигательная установка, ряд механических систем и элементов, таких как средства отделения от ракеты-носителя, антенные устройства, механизмы фиксации и раскрытия подвижных устройств, экранно-вакуумная теплоизоляция (ЭВТИ) и т.д. Солнечная батарея и её конструкция, аккумуляторная батарея, высокоскоростная радиолиния, исполнительные органы системы управления движением и др. элементы выбираются в зависимости от характеристик и требований целевой аппаратуры [1].

При выборе параметров для описания каждого из типов подсистем МКА в качестве основы использовался приведённый выше перечень требований из [22]. Информация для БД собиралась из каталогов продукции предприятий, выпускающих оборудование для изделий космической техники [23-27].

Рисунок 1 – Таксономическая схема подсистем МКА

Figure 1 – Taxonomic diagram of MCA subsystems

3. Информационная система

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

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

В большинстве случаев пользователи не взаимодействуют напрямую с БД и пользуются дополнительным слоем абстракции над БД в виде пользовательского приложения. Такой подход позволяет упростить взаимодействие пользователей с БД, например, за счёт того, что при запросах через клиентский интерфейс от пользователя как правило не требуются навыки применения языка запросов (например, SQL) или знания информации о схеме БД. Приложение может представлять пользователю информацию в наглядной форме.

Использование клиент-серверной архитектуры позволяет пользователям ИС взаимодействовать с БД (Postgres) без необходимости установки СУБД на локальный компьютер. Кроме того, отделение клиентской части от приложения и БД позволит в будущем реализовать интерфейсы, адаптированные под мобильные устройства.

Клиентский интерфейс приложения представлен на рисунке 2. Условия для поиска интересующих пользователя объектов задаются взаимодействием пользователя с графическими компонентами экрана. Из описания конкретного изделия существует возможность перейти на сайт его производителя.

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

Блок для задания параметров поиска включает в себя: фильтры поиска в БД; поле поиска по запросу; кнопки для запуска процесса поиска в БД и для очистки заданных фильтров поиска.

Рисунок 2 – Клиентский интерфейс ИС поддержки проектирования МКА

Figure 2 – Client interface of the MCA design support IS

4. База данных

БД обеспечивающих БС и полезных нагрузок МКА различного целевого назначения разработана как часть веб-приложения. Клиентская часть выполнена на JavaScript и HTML5¹, работает в веб-браузере и взаимодействует с БД через Django Backend²

Семантическая структура ПрО описана в разделе 2. В дополнение к схеме ПрО, приведённой на рисунке 1 в БД добавлены описания , обеспечивающих работу подсистем в составе МКА. Под аппаратными интерфейсами подразумеваются способы физического соединения элементов МКА, например, шины и разъёмы. Соответствие интерфейсов используется в качестве одного из критериев . В случае если отобранные системы не совместимы, пользователь будет об этом уведомлен.

Фрагмент ER³-диаграммы разработанной БД ИС поддержки проектирования приведён на рисунке 3.

В таблицах, описывающих аппаратуру и компоненты КА, используются суррогатные первичные ключи. В промежуточных таблицах, отражающих связи вида «многие ко многим», используются составные первичные ключи.

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

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

было отмечено, что СУБД выполняет поиск по таблицам вне зависимости от использования фильтров по индексированным и неиндексированным полям.

5. Работа с системой

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

Одним из подходов к предварительному проектированию МКА является метод проектирования с использованием заимствованных элементов.

Рисунок 3 – Фрагмент ER-диаграммы БД подсистем МКА

Figure 3 – Fragment of the ER-diagram of the database of MCA subsystems

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

В общем случае задача проектирования может формулироваться в терминах нелинейного программирования [30, 31]. Необходимо найти вектор проектных переменных X^*, при котором выполняется условие:

$f (X^{*}) \leq f (X) \forall X \in Ω$

$Ω = \{X : g_{j} (X) \leq 0, j = 1,2,..., m\}$ ,

где $f (X)$ – целевая функция, $X = \{x_{1}, x_{2},..., x_{n}\}$ – вектор проектных параметров, $Ω$ – область допустимых значений, определяемая комплексом ограничений – $g_{j} (X) \leq 0$ .

Для определения основных характеристик СЭП в качестве проектных параметров принимаются: масса аккумуляторной батареи (m_АБ), масса солнечных батарей (m_СБ), масса контроллера заряда-разряда (m_К).

В качестве критерия оптимальности в настоящей работе используется минимум массы СЭП, обеспечивающей функционирование МПН. Таким образом, целевая функция: $М_{С Э П} = m_{А Б} + m_{С Б} + m_{К} \to \min$ .

Условия функционирования МПН определяются из режимов работы, приведённых в таблице 1.

Таблица 1 – Исходные данные по электропотреблению МПН

Режимы работы МПН	Длительность на рабочем витке, мин	Электропотребление, Вт		Допустимое время работы в сутки, мин
Режимы работы МПН	Длительность на рабочем витке, мин	при работе	среднесуточное	Допустимое время работы в сутки, мин
1 Режим включения (РВ)	3	450	3,75	12
2 Режим ретрансляции (РР)	13	2090	75,5	52
3 Режим выключения (РВЫК)	3	450	3,75	12
4 Дежурный режим (ДР)	77,7	100	94,7	1364

Согласно исходным данным, в сутки предполагается до четырёх рабочих сеансов с максимальной длительностью сеанса ретрансляции до 13 минут при пролёте региона интереса: два сеанса на двух последовательных восходящих витках и через ~ 12 часов на двух последовательных нисходящих витках. График электропотребления МПН для типовых суток полёта МКА приведён на рисунке 4.

Рисунок 4 – График электропотребления МПН

Figure 4 – MPN power consumption graph

График электропотребления бортовой аппаратуры МКА и уровня освещённости солнечных панелей приведён на рисунке 5.

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

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

Схема рабочего процесса использования системы представлена на рисунке 6. При работе с ИС пользователь задаёт значения или диапазоны значений интересующих его параметров, используя интерфейс приложения (1). Приложение формирует запрос к БД (2) и представляет полученную информацию пользователю (3).

Рисунок 5 – График электропотребления бортовой аппаратуры МКА и уровня освещённости

Figure 5 – Graph of power consumption of the on-board equipment of the small spacecraft and the level of illumination

Таблица 2 – Исходные данные для определения параметров СЭП

Характеристика	Значение
Среднесуточное электропотребление бортовой аппаратуры, Вт	418,7
1 МПН	177,7
2 БС контроля и управления	55
3 Система управления движением	55
4 Система электропитания	20
5 Система обеспечения теплового режима	96
Резерв	15
Среднее напряжение бортовой сети, В	27
Среднесуточный уровень освещённости панелей БС (cosα)	0,51
Удельная мощность ФЭП (арсенид-галлиевые), Вт/м²	255
Удельная мощность ФЭП (кремний), Вт/м²	150
Среднее значение КПД аккумуляторной батареи	0,9
Среднее значение КПД разрядного/зарядного устройства	0,95
Коэффициент деградации ФЭП	1,2

Дальнейший расчёт параметров СЭП проводится с учётом данных, приведённых в таблице 2. Пример результатов расчёта требуемых для обеспечения работы МПН параметров СЭП приведён в нижней таблице на рисунке 6. Полученные значения параметров СЭП позволяют определить границы областей, в которых может находиться искомое проектное решение для МКА.

Заключение

В работе описана ИС поддержки проектирования и представлена структура БД обеспечивающих БС и полезных нагрузок МКА. ИС может быть использована для повышения эффективности проектирования МКА на базе платформ.

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

Рисунок 6 – Схема работы ИС поддержки проектирования МКА

Figure 6 – Scheme of operation of the MCA design support IS

¹ HTML5 (англ. HyperText Markup Language, version 5) — язык для структурирования и представления содержимого всемирной паутины (англ. World Wide Web). HTML5 предназначен для поддержки мультимедиа-технологий с одновременным сохранением обратной совместимости, удобочитаемости кода для человека и простоты анализа для парсеров.

² Django — свободный полнофункциональный фреймворк для создания веб-приложений, написанный на Python.

³ ER от англ. Entity-Relationship model, модель «сущность — связь». В программной инженерии ER-модель часто выступает абстрактной моделью ПрО, определяющей структуру данных или информации, которая может быть реализована в БД, обычно реляционной.