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). Загальна кількість супутників, запущених із 1957 року, за каталогом US SSN² становить близько 18 200; у 2017 Index of Objects Launched into Outer Space UNOOSA зазначено, що наразі навколо планети обертаються 4635 супутників, що на 357 супутників (8,95%) більше, ніж попереднього року³. Мета цієї статті — продемонструвати потребу в застосуванні управління термінологією та її вилучення для підтримки розроблення моделей на основі ознак, що впорядковують поняття, які описують функції програмних застосунків для моніторингу й керування супутниками.

Супутники класифікують за призначенням і типом орбіти. Призначення стосується послуг, які супутник має надавати. Щодо орбіти розрізняють низьку навколоземну орбіту (LEO), середню навколоземну орбіту (MEO) та геостаціонарну орбіту (GEO). Супутники LEO, що використовуються для науки та спостереження за Землею, рухаються еліптичною орбітою; оскільки їхня видимість із наземних станцій обмежена, дані зберігаються на борту й передаються на Землю

¹ Див. https://www.grc.nasa.gov/www/k-12/TRC/laefs/laefs_s.html#satellite [переглянуто 2020-08-01].

² Мережа космічного спостереження США відповідає за виявлення, відстеження, каталогізацію та ідентифікацію штучних об’єктів на орбіті навколо Землі. Каталог доступний за адресою: https://www.space-track.org/#/ssr [переглянуто 2020-08-01].

³ Управління ООН з питань космічного простору. Див. https://www.pixalytics.com/sats-orbiting-earth-2017/

Terminologija | 2020 | 27

187

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

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

З погляду програмної інженерії, керування супутником потребує різних застосунків та інструментів для динаміки польоту, планування місії, телеметрії й передавання телекоманд, керування мережею та маршрутизації, а також інтерфейсів між ними. Ця складність зумовила розроблення космічними агентствами різних рішень. Однією з найважливіших віх у розробленні програмного забезпечення MCS стало рішення підрозділу ESA інженерії наземних систем розробити й ліцензувати європейській промисловості набір програмних застосунків, поширюваних під назвою MICONYS^®

⁴ Супутники GEO розміщені в обмеженій області космічного простору. Орбітальні позиції для уникнення зіткнень розподіляє Міжнародний союз електрозв’язку (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 (Wilkinson Microwave Anisotropy Probe), IMAGE (Imager for Magnetopause-to-Aurora Global Exploration), EO-1 (Earth Observing 1), ST-5 (Space Technology 5), SDO (Solar Dynamics Observatory) або LRO (Lunar Reconnaissance Orbiter) (Pfarr et al. 2007).

У всіх цих випадках ідеться про складну систему, яка має реалізовувати різні функції, що можуть активуватися або ні залежно від характеристик супутника й місії. Тому ці програмно-інтенсивні системи є вдалими кандидатами для розроблення із застосуванням лінійок програмних продуктів і методів моделювання на основі функцій, що спираються на чітку й добре впорядковану організацію понять для розуміння предметної області та необхідних можливостей системи.

2. МОДЕЛЮВАННЯ НА ОСНОВІ ФУНКЦІЙ

ЯК ОРГАНІЗАЦІЯ ПОНЯТЬ

Моделювання на основі функцій — один із методів, застосовуваних у розробленні лінійок програмних продуктів, дисципліні створення багаторазово використовуваних програмних продуктів, що набула популярності наприкінці дев’яностих років. SPLE має на меті

Terminologija | 2020 | 27

189

створювати багаторазово використовувані компоненти й артефакти, які згодом можна поєднувати для створення продуктів, що відповідають потребам конкретного замовника й контексту. Досвід застосування SPLE широко описано в професійній та академічній літературі. Capilla (2013) навів кілька прикладів успішного застосування SPLE: експлуатаційні програми Boeing’s, критично важливі для виконання місій, для авіоніки й функцій кабіни пілотів; програмне забезпечення Bosch’s для керування двигунами в бензинових системах; програмне забезпечення Hewlett Packard’s для принтерів; обладнання Toshiba’s для виробництва й передавання електроенергії; а також програмне забезпечення 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

процедури, користувацька документація тощо. Аналіз предметної області можна розглядати як різновид інженерії вимог для всієї лінійки продуктів, що передбачає виявлення очікуваної варіативності. Основним артефактом, створеним у результаті аналізу предметної області, є модель ознак, яка визначатиме й описуватиме продукти в межах лінійки.

Моделювання ознак — це техніка діаграмного подання, запроваджена в 1990-х роках у межах методології 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 Текстове, цифрове або статусне калібрування: зіставляє текстові рядки з діапазонами необроблених значень параметрів. Текстові значення можна отримати з дискретних значень або їх діапазону. Простий приклад — статус ON / OFF бортових блоків, який можна отримати з однобітового параметра, де 0 означає OFF, а 1 — ON.

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