doi.org/10.35321/term27-08

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

RICARDO EITO BRUN

Universidad Carlos III de Madrid

АННОТАЦИЯ

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

КЛЮЧЕВЫЕ СЛОВА: техническая терминология, модели на основе признаков, аэрокосмическая инженерия, извлечение терминологии

АННОТАЦИЯ

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

КЛЮЧЕВЫЕ СЛОВА: техническая терминология, модели признаков, авиационная инженерия, распознавание терминов

186

Ricardo Eito Brun

Terminology as the Basis for Building Engineering Feature-based Models

1. ВВЕДЕНИЕ

В глоссарии NASA спутники определяются как: «свободно летящий объект, обращающийся вокруг Земли, другой планеты или Солнца.» Спутники — это разновидность космических аппаратов, движущихся по регулярной, четко определенной орбите вокруг центра тяжести другого небесного тела (Garner 1996: 4). С момента запуска первых искусственных спутников — Sputnik 1 4 октября^th 1957 года и Explorer 1 31 января^st 1958 года — было запущено множество спутниковых миссий различного назначения: астрономические исследования, предоставление услуг связи и навигации, наблюдение за Землей, разведка и научные миссии. Спутники — сложные аэрокосмические системы, состоящие из наземных и космических элементов: космическим аппаратом должен управлять наземный управляющий элемент, и он должен поддерживать с ним связь. Сегодня научный прогресс и предоставление услуг пользователям зависят от спутников и спутниковых группировок. К важным примерам относятся Hubble Space Telescope (HST), навигационные системы, такие как GPS (Global Positioning System), GLONASS и европейская Galileo, UARS (Upper Atmosphere Research Satellite) или GOES (Geostationary Operational Environment Satellite). Согласно каталогу US SSN², с 1957 года было запущено в общей сложности почти 18 200 спутников; 2017 Index of Objects Launched into Outer Space UNOOSA сообщает, что в настоящее время вокруг планеты обращаются 4635 спутников, что на 357 спутников (8,95%) больше, чем в предыдущем году³. Цель данной статьи — показать необходимость применения управления терминологией и извлечения терминов для разработки моделей на основе признаков, позволяющих систематизировать понятия, описывающие функции программных приложений, используемых для мониторинга и управления спутниками.

Спутники классифицируют по назначению и типу орбиты. Назначение определяется услугами, которые должен предоставлять спутник. По типу орбиты различают Low Earth Orbit (LEO), Medium Earth Orbit (MEO) и Geostationary Orbit (GEO). Спутники на низкой околоземной орбите (LEO), используемые для научных исследований и наблюдения за Землей, движутся по эллиптической орбите; поскольку их видимость с наземных станций ограничена, данные хранятся на борту и передаются на Землю

¹ См. https://www.grc.nasa.gov/www/k-12/TRC/laefs/laefs_s.html#satellite [дата обращения: 2020-08-01].

² US Space Surveillance Network отвечает за обнаружение, отслеживание, каталогизацию и идентификацию искусственных объектов, обращающихся вокруг Земли. Каталог доступен по адресу: https://www.space-track.org/#/ssr [дата обращения: 2020-08-01].

³ United Nations Office for Outer Space Affairs. См. https://www.pixalytics.com/sats-orbiting-earth-2017/

Terminologija | 2020 | 27

187

наземные станции, когда аппарат становится видимым. Спутники GEO используются для телекоммуникационных и метеорологических целей; телекоммуникационные спутники принимают радиочастотные (RF) сигналы с Земли, усиливают их, изменяют их частоту и передают обратно на Землю. Они обращаются на высоте 36 000 км над экватором (в одной плоскости), причем их вращение синхронно с вращением Земли, благодаря чему они постоянно находятся над одной и той же точкой экватора)⁴. Подобно спутникам, научные миссии в дальний космос также нуждаются в аналогичных средствах мониторинга и управления для передачи телекоманд и приема телеметрии.

Для выполнения спутниковых миссий необходим специализированный персонал, обеспечивающий непрерывный мониторинг состояния и положения спутника в реальном времени. Управление миссией включает совокупность задач, выполняемых инженерами по эксплуатации после запуска с помощью программных приложений, и предполагает обмен данными между наземным и космическим сегментами для мониторинга состояния бортовых подсистем спутника и управления ими. В научных миссиях также необходимо принимать данные от полезной нагрузки спутника и передавать их конечным пользователям (научному сообществу). К типичным функциям, выполняемым в ходе управления миссией, относятся прием и анализ телеметрии, передача телекоманд и отслеживание. Телеметрия — это данные, передаваемые со спутника на Землю и сообщающие о состоянии и условиях работы спутника и его подсистем. Телекоманды — это команды, передаваемые с Земли на космический аппарат для его настройки и управления им (Uhlig, Sellmaier, and Schmidhuber 2015: 232). Отслеживание и удержание на орбите, также известное как ranging, заключается в мониторинге и определении траектории полета и положения с использованием радиочастотных методов и сигналов.

С точки зрения программной инженерии управление спутником требует различных приложений и инструментов для динамики полета, планирования миссии, телеметрии и передачи телекоманд, управления сетью и маршрутизации, а также интерфейсов между ними. Эта сложность привела к разработке различных решений космическими агентствами. Одним из наиболее значимых этапов в развитии программного обеспечения MCS стало решение отдела ESA Ground Systems Engineering разработать и лицензировать для европейской промышленности набор программных приложений, распространяемых под названием MICONYS^®

⁴ Спутники GEO размещаются на ограниченном участке космического пространства. Орбитальные позиции распределяются International Telecommunication Union (ITU) во избежание столкновений — риска, связанного с проблемой космического мусора, которой сегодня уделяется все больше внимания.

188 Ricardo Eito Brun │ Terminology as the Basis for Building Engineering Feature-based Models

(система управления полётами). MICONYS и его компонент SCOS-2000® — вероятно, наиболее известные примеры реализации политики ESA в области разработки программного обеспечения, инноваций и передачи технологий (Kaufeler, Jones and Karl 2001). SCOS-2000 поддерживает передачу телекоманд, приём телеметрии, отображение и архивирование данных. SCOS-2000 стал результатом опыта, накопленного ESA при разработке и эксплуатации предыдущих аналогичных систем: MSSS, SCOS-1 и SCOS-2. В настоящее время ESA разрабатывает новую систему MCS, призванную в будущем заменить SCOS-2000. Она называется Европейские наземные системы — общее ядро (EGS-CC). Подобно SCOS, проект направлен на разработку общей инфраструктуры для поддержки мониторинга и управления космическими миссиями на этапах до и после запуска с использованием современных технологий и сервисно-ориентированных архитектур (Peccioli et al. 2012). За разработку EGS-CC отвечает не только ESA: в проекте участвуют национальные космические агентства европейских стран (CNES, UK Space Agency и DLR), а также промышленные компании (AIRBUS Defence and Space, Thales Alenia Space и OHB Systems).

Помимо проектов ESA, существуют и другие инициативы, нацеленные на разработку универсальной программной системы MCS. NASA завершило аналогичные проекты, большинство из которых разрабатывалось собственными силами. Центр космических полётов имени Годдарда разработал две системы — ITOS и ASIST — для управления такими миссиями, как WMAP (зонд для исследования микроволновой анизотропии имени Уилкинсона), IMAGE (глобальный исследователь магнитопаузы и полярных сияний), EO-1 (спутник дистанционного зондирования Земли 1), ST-5 (космическая технология 5), SDO (обсерватория солнечной динамики) или LRO (орбитальный аппарат для исследования Луны) (Pfarr et al. 2007).

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

2. МОДЕЛИРОВАНИЕ НА ОСНОВЕ ПРИЗНАКОВ

КАК СТРУКТУРА ПОНЯТИЙ

Моделирование на основе признаков — один из методов, применяемых в инженерии семейств программных продуктов, дисциплине разработки повторно используемых программных продуктов, получившей распространение в конце девяностых годов. SPLE предполагает

Terminologija | 2020 | 27

189

создание повторно используемых компонентов и артефактов, которые впоследствии можно комбинировать для создания продуктов, соответствующих потребностям конкретного заказчика и контекста. Опыт применения SPLE широко описан в профессиональной и академической литературе. Capilla (2013) приводит несколько примеров успешного применения SPLE: эксплуатационные критически важные для миссии программы Boeing для авиационных систем и функций кабины экипажа, программное обеспечение Bosch для управления двигателями бензиновых автомобилей, программное обеспечение Hewlett Packard для принтеров, оборудование Toshiba для выработки и передачи электроэнергии, а также управляющее программное обеспечение General Motors для силовых агрегатов. Согласно Apel et al. (2013: 9), преимущества семейств программных продуктов (SPL) включают адаптацию программных продуктов к конкретным потребностям клиентов, снижение затрат — поскольку набор повторно используемых ресурсов можно комбинировать различными способами для создания новых продуктов, — повышение качества и сокращение времени вывода на рынок.

Признаки и моделирование на основе признаков являются важными понятиями при разработке SPL. Стандарт ISO/IEC/IEEE 24765:2010, Systems and software engineering — Vocabulary, предлагает общее определение признака, взятое из IEEE Std 829:2008 IEEE Standard for Software and System Test Documentation: «Отличительная характеристика элемента системы. ПРИМЕЧАНИЕ. Включает как функциональные, так и нефункциональные атрибуты, такие как производительность и повторное использование». Kang and Lee (2013, 28) определяют признаки как «абстрактные понятия, эффективно поддерживающие взаимодействие между различными заинтересованными сторонами семейства продуктов; поэтому естественно и интуитивно понятно выражать общность и вариативность семейств продуктов через признаки».

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

Разработка семейства продуктов включает два взаимодополняющих жизненных цикла:

• Инженерия предметной области и

• Инженерия приложений.

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

190

Ricardo Eito Brun

Terminology as the Basis for Building Engineering Feature-based Models

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

Моделирование признаков — это метод диаграммного представления, появившийся в девяностых годах вместе с методологией FODA (анализ предметной области, ориентированный на признаки). FODA предложила примитивы для представления структурных отношений (композиции, обобщения и специализации), необязательности, альтернативности и взаимных зависимостей. Позднее методология была пересмотрена разными авторами (Kang and Lee 2013: 30–31). Диаграммы признаков — это визуальное представление моделей признаков, в которых признаки изображаются в виде прямоугольников, расположенных в иерархическом дереве. Каждый узел снабжён меткой с названием признака. Иерархическое расположение признаков формирует отношения родитель—потомок. Если выбран дочерний признак, необходимо также выбрать его родительский признак. Диаграммы позволяют различать обязательные и необязательные признаки, а также определять допустимые сочетания признаков.

В частности, диаграммы признаков позволяют представлять:

Абстрактные признаки, используемые для организации признаков в дереве, но не связанные с артефактами реализации. Они изображаются серыми прямоугольниками.

Конкретные признаки, соответствующие артефактам реализации и изображаемые белыми прямоугольниками.

Обязательные признаки, обозначаемые закрашенной точкой над верхней границей прямоугольника.

Необязательные признаки, обозначаемые незакрашенной точкой над верхней границей прямоугольника.

Необходимость выбрать только один из дочерних признаков конкретного родительского признака (исключающее ИЛИ, XOR или один из многих). Она обозначается незакрашенной дугой у нижней границы прямоугольника родительского признака.

Возможность выбрать более одного дочернего признака конкретного родительского признака (ИЛИ или несколько из многих). Она обозначается закрашенной дугой у нижней границы прямоугольника родительского признака.

Зависимости между признаками, обозначаемые стрелками с текстовыми пояснениями.

Terminologija | 2020 | 27

191

На приведённой ниже диаграмме показан типичный вариант диаграммы признаков с использованием описанных выше условных обозначений:

Рис. 1. Пример построения диаграммы признаков (источник: Gargantini 2015)

Модель признаков должна содержать сведения, дополняющие диаграмму. Apel et al. (2013: 27) указывают на возможность добавления следующих данных:

«Описание признака и соответствующего ему набора требований.

Связь с другими признаками, особенно иерархия, порядок и группировка.

Внешние зависимости, например необходимые аппаратные ресурсы.

Заинтересованные стороны.

Оценочная или измеренная стоимость реализации признака.

И т. д.»

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

192

Ricardo Eito Brun

Terminology as the Basis for Building Engineering Feature-based Models

3. МЕТОДОЛОГИЯ РАБОТЫ

Предложенная модель признаков была разработана в соответствии со следующими этапами:

Выявление и анализ профессиональной и академической литературы, опубликованной в этой области. Это включает поиск информации о подходах, применяемых в аэрокосмических проектах, реализуемых такими организациями, как ESA (European Space Agency) или NASA (National Aeronautics and Space Administration).

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

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

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

Для создания модели признаков и диаграмм был выбран инструмент FeatureIDE⁵. Это инструмент с открытым исходным кодом, основанный на Java и Eclipse и разработанный сотрудниками Otto-von-Guericke-Universität Magdeburg. С помощью FeatureIDE можно создать модель признаков в графическом редакторе, отметить признаки как обязательные, необязательные или абстрактные и построить иерархическое дерево. После построения модели признаков можно создавать различные конфигурации — наборы выбранных признаков, используемые для генерации целевого программного приложения

⁵ См. https://FeatureIDE.github.io/. Последняя проверка: 01-03-2018.

Terminologija | 2020 | 27

193

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

Рис. 2. FeatureIDE (создано автором)

4. ПРЕДСТАВЛЕНИЕ РЕЗУЛЬТАТОВ И ОБСУЖДЕНИЕ

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

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

Цепочка телеметрии, включающая обработку телеметрии, диспетчер аварийных сигналов и отображение телеметрии.

194

Ricardo Eito Brun

Terminology as the Basis for Building Engineering Feature-based Models

Цепочка телекоманд, включающая передачу телекоманд на борт, ручную очередь, очередь запланированных команд и историю телекоманд.

Мост TT&C/TCR, обеспечивающий отображение состояния и управление интерфейсом с наземной станцией для потоков телеметрии, команд, дальнометрии (TCR) и данных наведения антенны.

Журнал событий, в котором регистрируются события, выявленные в ходе работы системы, и который позволяет операторам просматривать и искать полную историю событий.

Управление бортовой памятью, предоставляющее средства для управления образом памяти космического аппарата (загрузки, редактирования и передачи на борт).

Анализ документации и терминов привёл к созданию моделей функций для указанных функций системы. В качестве примера кратко рассмотрен частный случай управления телеметрией. Можно видеть, что для выявленных функций приводятся определения, основанные на существующей литературе и технической документации:

Термин цепочка телеметрии обозначает различные процессы, связанные с обработкой телеметрии: приём от TT&C, пакетирование, архивирование и передачу приложениям-потребителям:

Пакетирование телеметрии. MCS принимает исходные пакеты телеметрии, соответствующие стандарту пакетов телеметрии, добавляет метаданные (например, качество потока телеметрии) и преобразует их в один или несколько внутренних пакетов телеметрии MCS. Критерии формирования пакетов из входящих данных могут меняться в зависимости от спутника, миссии и протоколов BBE.

Проверка качества пакетов. MCS непрерывно проверяет качество телеметрии с помощью проверок, выполняемых либо TT&C, либо самой MCS. Метаданные о качестве телеметрии добавляются к каждому внутреннему пакету. В зависимости от результатов этих проверок пакет может быть классифицирован как пригодный для обработки (GOOD) или непригодный для обработки (BAD). Потери телеметрии также должны выявляться в ходе этого процесса.

Типичной проверкой качества является проверка последовательности кадров, которая определяет, принимаются ли кадры в правильной последовательности.

Terminologija | 2020 | 27

195

События генерируются, если эти проверки не пройдены. Оператор может выбрать, как поступать при обнаружении кадров телеметрии BAD (обрабатывать или отбрасывать их).

• Проверки качества времени. Эти проверки устанавливают, не слишком ли сильно расходится время, сообщаемое TT&C для каждого потока телеметрии, с местным временем MCS. Разница между текущим временем MCS и меткой времени в кадре телеметрии (устанавливаемой наземной станцией при приёме кадра) должна укладываться в настраиваемое временное окно. Если эти проверки не пройдены, генерируются сообщения о событиях. Для проверок качества времени необходимо ставить временные метки на пакеты телеметрии.

• Демультиплексирование телеметрии, при котором из пакетов извлекаются отсчёты параметров телеметрии⁶. Оно включает извлечение параметров, декодирование битов, калибровку, проверку выхода за пределы диапазона, проверку достоверности и датирование параметров.

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

○ Декодирование битов извлекает исходное значение из значения, закодированного в пакете телеметрии. В типичном случае исходное значение совпадает с закодированным в пакете, однако в некоторых случаях необходимы битовые (например, обращение порядка битов или дополнительный код) либо побайтовые преобразования.

○ Расчётные, или синтетические, параметры. Они не поступают со спутника, а вычисляются алгоритмически на Земле с использованием полученных параметров телеметрии в качестве операндов. Их рассчитывают по формулам, записанным на скриптовых языках. Расчёт выполняется до калибровки, проверки достоверности и датирования параметров.

Особый тип расчётных параметров — жёстко заданные расчётные параметры (HCDP), записываемые на языках программирования низкого уровня.

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

196 Ricardo Eito Brun | Terminology as the Basis for Building Engineering Feature-based Models

например, на C++, Fortran или C. Их модификация требует повторной компиляции исходного кода.

o Датирование параметров телеметрии присваивает выборкам параметров дату, используя время пакета, в котором они содержатся, и добавляя смещение, указанное в спутниковой MIB.

o Контроль выхода за допустимый диапазон (OOR) анализирует, находится ли необработанное значение параметра телеметрии за пределами заданного диапазона калибровки. Параметры телеметрии, выходящие за допустимый диапазон, объявляются недействительными с категорией OOR. OOR используется для оценки достоверности параметра телеметрии и определения того, является ли его значение полезным или бессмысленным.

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

• Калибровка параметров телеметрии преобразует их необработанные значения в форму, понятную человеку (инженерные или калиброванные значения с единицами, соответствующими физической величине). Калибровка может выполняться различными методами:

o Числовая или линейная дискретная калибровка: используется линейная интерполяция по калибровочной кривой, состоящей из пар (X, Y), где X обозначает необработанное значение, а Y — инженерное значение.

o Текстовая, цифровая или статусная калибровка: связывает текстовые строки с диапазонами необработанных значений параметров. Текстовые значения могут быть получены из дискретных значений или их диапазона. Простой пример — состояние бортовых устройств ВКЛ. / ВЫКЛ., которое можно получить из однобитового параметра, где 0 означает ВЫКЛ., а 1 — ВКЛ.

o Полиномиальная калибровка: для преобразования необработанных значений в инженерные используется полином не выше пятой степени.

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

Terminologija | 2020 | 27

197

Рис. 3. Обработка TM — признаки Рис. 1: FeatureIDE (создано автором)

5. ВЫВОДЫ

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

198

Ricardo Eito Brun

Terminology as the Basis for Building Engineering Feature-based Models

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

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

Параметры конфигурации, специфичные для миссии и обычно управляемые с помощью открытых файлов конфигурации.

Выбор необязательных признаков в зависимости от типа миссии: например, позиционно-зависимые телекоманды, характерные для спутников LEO, предназначенных для наблюдения Земли.

Настройка служб, специфичных для миссии и расширяющих базовые службы и функции, определенные в стандартах телеметрии и телекоманд, таких как PUS.

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

REFERENCES

Apel et al. 2013: Feature-Oriented Software Product Lines: Concepts and Implementation, Berlin: Springer.

Capilla Rafael 2013: Variability Scope. – System and Software Variability Management: Concepts, Tools, and Experiences, Berlin: Springer, 43–56.

CCSDS 520.0-G-3 (Mission operations services concept), December, 2010.

Clements, Paul C. and Northrop Linda M. 2002: Software Product Lines: Practices and Patterns, Boston: Addison-Wesley Professional.

Gargantini Angelo 2015: Generating Tests for Detecting Faults in Feature Models. – 2015 IEEE 8th International Conference on Software Testing, Verification and Validation, ICST 2015 – Proceedings.

Terminologija | 2020 | 27

199

Garner John T. 1996: Satellite Control: a Comprehensive Approach, Chichester: John Wiley and sons, xv.

Jones, M.; Srensren E. M. and Wolff T. 1993: “A review of mission planning systems”. – IPL SpaceOps 1992: Proceedings of the Second International Symposium on Ground Data Systems for Space Mission Operations (SEE N94-23832 06-66), 219–224. Available at: https://ntrs.nasa.gov/search.jsp?R=19940019393

Kang Kyo-Chul and Lee H. 2013: Variability Modelling. – System and Software Variability Management: Concepts, Tools, and Experiences, eds. R. Capilla, J. Bosch and K. C. Kang, Berlin: Springer, 25–42.

Kaufeler J.-F., Jones M., Karl H.-U. 2001: Promoting ESA Software as a European Product: The SCOS-2000 Example. – ESA Bulletin 108, 72–77.

Pecchioli Mauro et al. 2012: Objectives and Concepts of the European Ground Systems Common Core (EGS-CC). – SESP 2012: Simulation and EGSE facilities for Space Programs, ESTEC Noordwijk, 25–27 September. Available at: http://www.egsc.esa.int/downloads/20120925_SESP_2012_egsc_objectives_and_concepts.pdf.

Pfarr Barbara et al. 2007: Proven and Robust Ground Support Systems – GSFC Success and Lessons Learned. (2008). – IEEE Aerospace Conference, paper # 1219, version 6. Available at: https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20080045437.pdf

Uhlig Thomas; Sellmaier Florian and Schmidhuber Michael 2015: Spacecraft Operations, Wien: Springer.

TERMINOLOGIJA KAIP INŽINERINIŲ POŽYMIŲ MODELIŲ KŪRIMO PAGRINDAS

S a n t r a u k a

Paly dovai yra erdvėlaiviai, kurie skrieja aplink kito dangaus kūno gravitacijos centrą pastovia, aiškiai apibrėžta orbita (Garner 1996: 4). Nuo pirmųjų dirbtinių palydovų paleidimo – „Sputnik 1“ 1957 m. spalio 4 d. ir „Explorer 1“ 1958 m. sausio 31 d. – buvo paleista daug palydovų misijų, kuriomis siekta skirtingų tikslų: astronominiai tyrimai, komunikacinių ir navigacinių paslaugų teikimas, Žemės stebėjimas, žvalgyba ir mokslinės misijos. Palydovai turi būti valdomi Žemėje esančiu valdymo elementu ir palaikyti su juo ryšį. Šį ryšį valdo Stebėjimo ir kontrolės sistema (SKS), kuri gauna telemetrinius duomenis iš erdvėlaivio ir duoda telekomandas, kad palaikytų palydovo padėtį ir skriejimo trajektoriją. Galime teigti, kad šios taikomosios programos gali būti naudojamos norint struktūruotai ir planuotai įdiegti variantškumo mechanizmus, o jų funkcionalumas leidžia analizuoti požymių modeliavimo metodikų pritaikymo galimybes.

Požymiai yra naudojami norint perduoti produkto charakteristikas ir palaikyti reikalavimų nustatymą. Jie taip pat naudojami priimant projektavimo ir įgyvendinimo sprendimus. Straipsnyje aprašomas požymių modelio sukūrimas remiantis šios srities profesinės ir akademinės literatūros apžvalga, žodynėlio, nurodančio ryšius tarp terminų, sudarymu ir požymių modelio, apimančio taikomųjų palydovų stebėjimo ir kontrolės programų funkcijas, sukūrimu. Įvesties duomenys, skirti identifikuoti terminus, apėmė techninių dokumentų, aprašančių pasirinktą produktą, pogrupį: valdymo vadovus, baltaisias knygas ir mokomąją medžiagą. Požymius nurodančios sąvokos ir terminai yra išdėstyti hierarchinės struktūros principu, o tarpusavio sąsajoms naudojamas FeatureIDE įrankis.

Gauta 2020-09-07

Ricardo Eito Brun Universidad Carlos III de Madrid Calle Madrid, 126, 28903 Getafe, Madrid, Spain E-mail [email protected]

200

Ricardo Eito Brun | Terminology as the Basis for Building Engineering Feature-based Models