doi.org/10.35321/term27-08

Terminologie jako základ pro tvorbu inženýrských modelů založených na vlastnostech

RICARDO EITO BRUN

Universidad Carlos III de Madrid

ABSTRAKT

Provoz družic vyžaduje kombinované použití různých nástrojů na podporu inženýrských činností a řízení kosmické lodi. Tuto komunikaci spravuje systém monitorování a řízení (MCS), který přijímá telemetrická data z kosmické lodi a vydává telepříkazy, aby udržoval orientaci družice a její letovou dráhu. Tyto komplexní systémy jsou vyvíjeny jako otevřené platformy, které lze rozšiřovat a upravovat tak, aby podporovaly požadavky a cíle konkrétní mise. Obecně lze říci, že tyto softwarové aplikace jsou vhodnými kandidáty pro strukturovanou a plánovanou implementaci mechanismů variability a že jejich funkčnost je vhodná k analýze proveditelnosti použití technik modelování založeného na vlastnostech. Tento článek popisuje použití terminologické analýzy při tvorbě modelu vlastností, který podporuje analýzu požadavků pro tento typ softwarových systémů.

KLÍČOVÁ SLOVA: technická terminologie, modely založené na vlastnostech, letecké inženýrství, extrakce terminologie

ANOTACE

Provoz družic vyžaduje různé nástroje k zajištění plynulého inženýrského provozu a řízení kosmické lodi. Toto spojení řídí systém monitorování a řízení (SKS), který přijímá telemetrická data z kosmické lodi a vydává telepříkazy, aby udržoval polohu družice a její oběžnou dráhu. Tyto komplexní systémy jsou vytvořeny jako otevřené platformy, které lze rozšiřovat a přizpůsobovat požadavkům a cílům konkrétní mise. Lze tvrdit, že tyto aplikace jsou obecně vhodné k tomu, aby se v nich strukturovaným a plánovaným způsobem implementovaly mechanismy variability, a jejich funkčnost umožňuje analyzovat možnosti použití metodik modelování vlastností. Tento článek popisuje využití terminologické analýzy při tvorbě modelu vlastností, který podporuje analýzu požadavků pro tento typ softwarových systémů.

KLÍČOVÁ SLOVA: technická terminologie, modely vlastností, letecké inženýrství, rozpoznávání termínů

186

Ricardo Eito Brun

Terminology as the Basis for Building Engineering Feature-based Models

1. ÚVOD

Glosář NASA definuje satelity jako: „volně létající objekt, který obíhá kolem Země, jiné planety nebo Slunce.“ Satelity jsou typem kosmických lodí, které se pohybují po pravidelné, jasně vymezené oběžné dráze kolem těžiště jiného nebeského tělesa (Garner 1996: 4). Od vypuštění prvních umělých satelitů – Sputniku 1 dne 4. října^th 1957 a Exploreru 1 dne 31. ledna^st 1958 – bylo vypuštěno velké množství satelitů pro různé účely: astronomický výzkum, poskytování komunikačních a navigačních služeb, pozorování Země, průzkum a vědecké mise. Satelity jsou komplexní letecké a kosmické systémy složené z pozemních a kosmických prvků: kosmickou loď musí řídit pozemní řídicí prvek a musí s ním zůstat v kontaktu. Vědecký pokrok a služby pro uživatele dnes závisí na satelitech a satelitních konstelacích. Mezi významné příklady patří Hubbleův kosmický dalekohled (HST), navigační systémy jako GPS (Global Positioning System), GLONASS a evropský Galileo, UARS (Upper Atmosphere Research Satellite) nebo GOES (Geostationary Operational Environment Satellite). Celkový počet satelitů vypuštěných od roku 1957 – podle katalogu US SSN² – se blíží 18 200; publikace UNOOSA 2017 Index of Objects Launched into Outer Space uvádí 4 635 satelitů, které v současnosti obíhají planetu, což představuje nárůst o 357 satelitů (8,95%) oproti předchozímu roku³. Cílem tohoto článku je ukázat potřebu využívat terminologický management a extrakci terminologie k podpoře vývoje modelů založených na vlastnostech, které uspořádávají pojmy popisující funkce softwarových aplikací používaných k monitorování a řízení satelitů.

Satelity se klasifikují podle účelu a typu oběžné dráhy. Účel se vztahuje ke službám, které má satelit poskytovat. Pokud jde o oběžnou dráhu, rozlišujeme mezi nízkou oběžnou dráhou Země (LEO), střední oběžnou dráhou Země (MEO) a geostacionární oběžnou dráhou (GEO). Satelity na LEO – používané pro vědecký výzkum a pozorování Země – se pohybují po eliptické dráze; protože jejich viditelnost z pozemních stanic je omezená, data se ukládají na palubě a odesílají na Zemi

¹ Viz https://www.grc.nasa.gov/www/k-12/TRC/laefs/laefs_s.html#satellite [přístup 2020-08-01].

² US Space Surveillance Network odpovídá za detekci, sledování, katalogizaci a identifikaci umělých objektů obíhajících kolem Země. Katalog je dostupný na adrese: https://www.space-track.org/#/ssr [přístup 2020-08-01].

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

Terminologija | 2020 | 27

187

stanicemi, když se družice stane viditelnou. Satelity GEO se používají pro telekomunikační a meteorologické účely; telekomunikační satelity přijímají radiofrekvenční (RF) signály ze Země, zesilují je, mění jejich frekvenci a vysílají je zpět na Zemi. Obíhají ve výšce 36 000 km nad rovníkem (ve stejné rovině) a jejich rotace je synchronní s rotací Země, takže se po celou dobu nacházejí nad stejným místem na rovníku)⁴. Podobně jako satelity vyžadují také vědecké mise do hlubokého vesmíru obdobné monitorování a řízení pro vysílání telepříkazů a příjem telemetrie.

Satelitní mise vyžadují specializovaný personál, který nepřetržitě a v reálném čase monitoruje stav a polohu satelitu. Řízení mise je soubor úkolů, které po vypuštění vykonávají provozní inženýři za pomoci softwarových aplikací a které zahrnují výměnu dat mezi pozemním a kosmickým segmentem za účelem monitorování a řízení stavu palubních subsystémů satelitu. U vědeckých misí je také nutné přijímat informace z užitečného zatížení satelitu a předávat je koncovým uživatelům (vědecké komunitě). Mezi typické funkce vykonávané během řízení mise patří příjem a analýza telemetrie, vysílání telepříkazů a sledování. Telemetrie jsou data přenášená ze satelitu na Zemi, která informují o stavu a podmínkách satelitu a jeho subsystémů. Telepříkazy jsou příkazy vysílané ze Země do kosmické lodi za účelem její konfigurace a provozu. (Uhlig, Sellmaier, and Schmidhuber 2015: 232). Sledování a udržování na stanici, označované také jako měření vzdálenosti, spočívá v monitorování a určování letové dráhy a polohy pomocí RF technik a signálů.

Z pohledu softwarového inženýrství vyžaduje řízení satelitu různé aplikace a nástroje pro letovou dynamiku, plánování mise, telemetrii a vysílání telepříkazů, řízení sítě a směrování, jakož i rozhraní mezi nimi. Tato složitost vedla kosmické agentury k poskytování různých řešení. Jedním z nejvýznamnějších milníků ve vývoji softwaru MCS bylo rozhodnutí oddělení ESA Ground Systems Engineering vyvinout a licencovat evropskému průmyslu sadu softwarových aplikací distribuovaných pod názvem MICONYS^®

⁴ Satelity GEO jsou rozmístěny v omezené oblasti vesmíru. Orbitální pozice přiděluje International Telecommunication Union (ITU), aby se předešlo srážkám, což je riziko související s kosmickým odpadem, jemuž se dnes věnuje stále větší pozornost.

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

(Mission Control System). MICONYS a jeho komponenta SCOS-2000® jsou pravděpodobně nejznámějšími příklady politiky ESA v oblasti vývoje softwaru, inovací a transferu technologií (Kaufeler, Jones and Karl 2001). SCOS-2000 podporuje vysílání telecommandů, příjem telemetrie, zobrazování a archivaci. SCOS-2000 vznikl na základě zkušeností, které ESA získala při vývoji a provozu předchozích podobných systémů: MSSS, SCOS-1 a SCOS-2. ESA dnes vyvíjí nový systém MCS, který má v budoucnu SCOS-2000 nahradit. Jmenuje se European Ground Systems – Common Core (EGS-CC). Podobně jako SCOS má projekt za cíl vyvinout společnou infrastrukturu podporující monitorování a řízení vesmírných misí v předstartovní i po startovní fázi s využitím moderních technologií a architektur orientovaných na služby (Peccioli et al. 2012). Za vývoj EGS-CC neodpovídá pouze ESA: součástí projektu jsou evropské národní kosmické agentury (CNES, UK Space Agency a DLR) a průmyslové společnosti (AIRBUS Defence and Space, Thales Alenia Space a OHB Systems).

Kromě projektů ESA existují i další iniciativy zaměřené na vývoj generického softwarového systému MCS. NASA dokončila podobné projekty, z nichž většina byla vyvinuta interně. Goddard Space Flight Centre vyvinulo dva systémy, ITOS a ASIST, pro řízení misí, jako jsou 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) nebo LRO (Lunar Reconnaissance Orbiter) (Pfarr et al. 2007).

Ve všech těchto případech se jedná o komplexní systém, který musí implementovat různé funkce, jež lze aktivovat, nebo neaktivovat podle charakteristik družice a mise. Tyto softwarově náročné systémy jsou proto vhodnými kandidáty pro vývoj pomocí produktových řad a technik modelování založeného na vlastnostech, které se opírají o jasnou a dobře uspořádanou organizaci pojmů potřebnou k pochopení domény a požadovaných schopností systému.

2. MODELOVÁNÍ ZALOŽENÉ NA VLASTNOSTECH

JAKO ORGANIZACE POJMŮ

Modelování založené na vlastnostech je jednou z technik používaných v inženýrství softwarových produktových řad, disciplíně zaměřené na tvorbu opakovaně použitelných softwarových programů, která se stala populární koncem devadesátých let. SPLE má za cíl

Terminologija | 2020 | 27

189

vytvářet opakovaně použitelné komponenty a artefakty, které lze později kombinovat a vytvářet tak produkty přizpůsobené potřebám konkrétního zákazníka a kontextu. Zkušenosti s SPLE jsou rozsáhle dokumentovány v odborné i akademické literatuře. Capilla (2013) uvedl několik případových studií, v nichž bylo SPLE úspěšně použito: provozní programy společnosti Boeing’s pro avioniku a funkce kokpitu, u nichž je kritická spolehlivost, software společnosti Bosch’s pro řízení motorů benzinových systémů, software tiskáren společnosti Hewlett Packard’s, zařízení společnosti Toshiba’s pro výrobu a přenos energie a řídicí software pohonných ústrojí společnosti General Motors’. Mezi přínosy softwarových produktových řad (SPL) podle Apel et al. (2013: 9) patří přizpůsobování softwarových produktů konkrétním potřebám zákazníků, nižší náklady – protože ze souboru opakovaně použitelných prostředků lze různými způsoby vytvářet nové produkty –, vyšší kvalita a kratší doba uvedení na trh.

Vlastnosti a modelování založené na vlastnostech jsou důležitými pojmy při vývoji SPL. Norma ISO/IEC/IEEE 24765:2010, Systems and software engineering — Vocabulary, nabízí obecnou definici vlastností převzatou z normy IEEE Std 829:2008 IEEE Standard for Software and System Test Documentation: „Rozlišovací charakteristika položky systému. POZNÁMKA: zahrnuje funkční i nefunkční atributy, například výkonnost a opakovanou použitelnost.“ Kang and Lee (2013, 28) definují vlastnosti jako „abstraktní pojmy, které účinně podporují komunikaci mezi různými zainteresovanými stranami produktové řady; je proto přirozené a intuitivní, že lidé vyjadřují společné rysy a variabilitu produktových řad prostřednictvím vlastností.“

Vlastnosti slouží v procesu koncipování a vývoje produktu různým účelům. Jsou prostředkem ke komunikaci charakteristik produktu a podporují identifikaci požadavků; zároveň jde o pojmy, které řídí rozhodování při návrhu a implementaci.

Vývoj produktové řady zahrnuje dva vzájemně se doplňující životní cykly:

• Doménové inženýrství a

• Aplikační inženýrství.

Norma IEEE 1517-2010 definuje doménové inženýrství takto: „Životní cyklus sestávající ze souboru procesů pro specifikaci a řízení společných rysů a variability produktové řady. Doménové inženýrství analyzuje doménu produktové řady a vytváří soubor opakovaně použitelných artefaktů. Mezi tyto artefakty patří softwarové požadavky, návrhové prvky, testovací případy a

190

Ricardo Eito Brun

Terminology as the Basis for Building Engineering Feature-based Models

postupy, uživatelská dokumentace atd. Analýzu domény lze chápat jako určitou formu inženýrství požadavků pro celou produktovou řadu, včetně identifikace předpokládané variability. Hlavním artefaktem vytvořeným při analýze domény je model funkcí, který specifikuje a popisuje produkty v rámci řady.

Modelování funkcí je diagramovací technika, která byla představena v devadesátých letech v rámci metodiky FODA (analýza domény orientovaná na funkce). Metodika FODA poskytla základní prvky pro znázornění strukturálních vztahů (kompozice, generalizace a specializace), volitelnosti, alternativ a vzájemných závislostí. Později ji přezkoumali různí autoři (Kang a Lee 2013: 30–31). Diagramy funkcí jsou vizuálním znázorněním modelů funkcí, v nichž jsou funkce znázorněny jako rámečky v hierarchickém stromu. Každý uzel má připojený štítek s názvem funkce. Hierarchické uspořádání funkcí vytváří vztahy rodič-potomek. Pokud je vybrána podřízená funkce, musí být vybrána také její nadřazená funkce. Diagramy mohou rozlišovat mezi povinnými a volitelnými funkcemi a určovat platné kombinace funkcí.

Konkrétně mohou diagramy funkcí znázorňovat:

Abstraktní funkce, které slouží k uspořádání funkcí ve stromu, ale nejsou vázány na implementační artefakty. Znázorňují se šedými rámečky.

Konkrétní funkce, které odpovídají implementačním artefaktům a znázorňují se bílými rámečky.

Povinné funkce, které mají na horním okraji rámečku plnou odrážku.

Volitelné funkce, které mají na horním okraji rámečku prázdnou odrážku.

Nutnost vybrat pouze jednu z podřízených funkcí konkrétní nadřazené funkce (výlučné NEBO, XOR neboli jedna z mnoha). Znázorňuje se prázdným obloukem na dolním okraji rámečku nadřazené funkce.

Možnost vybrat více než jednu podřízenou funkci konkrétní nadřazené funkce (NEBO neboli některé z mnoha). Znázorňuje se plným obloukem na dolním okraji rámečku nadřazené funkce.

Závislosti mezi funkcemi, znázorněné šipkami s textovými popisky.

Terminologija | 2020 | 27

191

Níže uvedený diagram znázorňuje typický diagram vlastností s konvencemi popsanými výše:

Obr. 1. Příklad diagramu vlastností (zdroj: Gargantini 2015)

Model vlastností by měl kromě diagramu obsahovat i další informace. Apel et al. (2013: 27) uvádějí možnost doplnit následující údaje:

„Popis vlastnosti a souboru požadavků, které se k ní vztahují.

Vztahy k ostatním vlastnostem, zejména hierarchie, pořadí a seskupení.

Externí závislosti, například požadované hardwarové prostředky.

Zainteresované strany.

Odhadované nebo změřené náklady na realizaci vlastnosti.

A tak dále.“

Vývoj modelu vlastností, který má reprezentovat funkční charakteristiky softwarových aplikací pro řízení satelitů, musí vycházet z jasného porozumění konceptům tvořícím danou oblast a z jejich modelování. Za tímto účelem tvoří základ pro vytvoření cílového modelu činnosti související s terminologií a terminografií, identifikací termínů a konceptů a jejich vztahů.

192

Ricardo Eito Brun

Terminology as the Basis for Building Engineering Feature-based Models

3. METODIKA PRÁCE

Navržený feature model byl dokončen podle následujících kroků:

Identifikace a přezkoumání odborné a akademické literatury publikované v této oblasti. To zahrnuje vyhledávání informací o přístupu uplatňovaném v leteckých a kosmických projektech vedených subjekty, jako jsou ESA (European Space Agency) nebo NASA (National Aeronautics and Space Administration).

Vytvoření glosáře na základě analyzované literatury s využitím technik správy terminologie k zaznamenání informací o termínech, vztazích mezi nimi, definicích zjištěných v dokumentech a kontextu, v němž se termíny používají.

Vytvoření feature-based modelu, který na základě glosáře znázorňuje funkce nabízené softwarovými aplikacemi pro monitorování a řízení družic.

Mezi vstupy použité k identifikaci termínů patřila podmnožina technických dokumentů popisujících vybraný produkt: provozní příručky, technické zprávy a školicí materiály. Feature model je hierarchický strom prvků označených jako povinné nebo volitelné, mezi nimiž existují závislosti. V případě analyzované softwarové aplikace byly kromě identifikace volitelných a povinných prvků určeny také další požadavky na variabilitu produktové řady. Některé funkce podporované analyzovaným softwarem vyžadují přepsání nebo úpravu stávajícího kódu. Tyto případy variability byly identifikovány s podporou odborníků, kteří se zabývají vývojem a přizpůsobováním tohoto typu softwarových aplikací. Informace byly shromážděny prostřednictvím osobních rozhovorů.

Nástrojem vybraným k vytvoření feature modelu a diagramů je FeatureIDE⁵. Jde o nástroj s otevřeným zdrojovým kódem založený na Javě a Eclipse, který vyvinuli pracovníci univerzity Otto-von-Guericke-Universität Magdeburg. Pomocí nástroje FeatureIDE lze pomocí grafického editoru vytvořit feature model, označit prvky jako povinné, volitelné nebo abstraktní a sestavit hierarchický strom. Po vytvoření feature modelu lze vytvářet různé konfigurace: výběry prvků, které budou použity k vygenerování cílové softwarové aplikace.

⁵ Viz https://FeatureIDE.github.io/. Naposledy zkontrolováno: 01-03-2018.

Terminologija | 2020 | 27

193

zdrojový kód. Nástroj bohužel neposkytuje možnosti správy termínů ani terminologických jednotek, a proto je nutné používat doplňkové nástroje.

Obr. 2. FeatureIDE (vytvořil autor)

4. PREZENTACE VÝSLEDKŮ A DISKUSE

Tato část shrnuje jednu část modelu vlastností softwarových aplikací systémů řízení misí (MCS). Analýza pojmů získaných z dokumentů vedla k uspořádání funkcionalit systému do těchto oblastí:

Správa plochy a relací, která poskytuje funkce pro přihlášení, zahájení relace a spuštění různých aplikací. Při správě více satelitů může uživatel přepínat mezi pracovními plochami jednotlivých satelitů.

Telemetrický řetězec, který zahrnuje zpracování telemetrie, správce alarmů a zobrazení telemetrie.

194

Ricardo Eito Brun

Terminology as the Basis for Building Engineering Feature-based Models

Řetězec telepříkazů, který zahrnuje uplink telepříkazů, manuální zásobník, plánovaný zásobník a historii telepříkazů.

Most TT&C/TCR, který zajišťuje přehled a ovládání rozhraní pozemní stanice pro datové toky telemetrie, příkazů, měření vzdálenosti (TCR) a směrování antény.

Protokol událostí zaznamenává události zjištěné během provozu systému a umožňuje operátorům procházet a vyhledávat celou historii událostí.

Správa palubní paměti poskytuje nástroje ke správě (stahování, úpravě a odesílání uplinkem) obrazu paměti kosmické lodi.

Analýza dokumentace a termínů vedla k vytvoření modelů vlastností pro tyto funkce systému. Jako příklad je shrnut konkrétní případ správy telemetrie. Je vidět, jak jsou pro zjištěné vlastnosti uvedeny definice vycházející z existující literatury a technické dokumentace:

Termín telemetrický řetězec označuje různé procesy související se zpracováním telemetrie: příjem z TT&C, paketizaci, archivaci a distribuci do spotřebitelských aplikací:

Paketizace telemetrie. MCS přijímá zdrojové telemetrické pakety podle standardu telemetrických paketů, přidává metadata (např. kvalitu telemetrického toku) a převádí je na jeden či více interních telemetrických paketů MCS. Kritéria pro vytváření paketů z příchozích dat se mohou lišit v závislosti na satelitu, misi a protokolech BBE.

Kontrola kvality paketů. MCS průběžně kontroluje kvalitu telemetrie pomocí kontrol prováděných buď systémem TT&C, nebo samotným MCS. Ke každému internímu paketu se připojují metadata o kvalitě telemetrie. Podle výsledků těchto kontrol lze paket klasifikovat jako vhodný ke zpracování (GOOD), nebo jako nevhodný ke zpracování (BAD). Během tohoto procesu je třeba identifikovat také výpadky telemetrie.

Typickou kontrolou kvality je kontrola posloupnosti rámců, která posuzuje, zda jsou rámce přijímány v pořadí.

Terminologija | 2020 | 27

195

V případě, že tyto kontroly nejsou splněny, jsou generovány události. Operátor může zvolit, jak se má postupovat při identifikaci BAD telemetrických rámců (zpracovat je, nebo je zahodit).

• Kontroly kvality času. Tyto kontroly ověřují, zda se čas hlášený systémem TT&C pro každý telemetrický tok a místní čas systému MCS příliš neliší. Rozdíl mezi aktuálním časem systému MCS a časovou značkou v telemetrickém rámci (nastavenou pozemní stanicí při příjmu rámce) se musí vejít do konfigurovatelného časového okna. Pokud tyto kontroly selžou, generují se zprávy o událostech. Kontroly kvality času vyžadují časové označování telemetrických paketů.

• Telemetrická dekomutace, která z paketů extrahuje vzorky telemetrických parametrů⁶. Zahrnuje extrakci parametrů, dekódování bitů, kalibraci, kontrolu překročení rozsahu, kontrolu platnosti a datování parametrů.

○ Extrakce telemetrických parametrů vyhledává a extrahuje z paketů surové hodnoty telemetrických parametrů. Surové hodnoty jsou obvykle celá čísla se znaménkem nebo bez znaménka, případně čísla s plovoucí desetinnou čárkou. U pevné telemetrie je tento proces jednoduchý, protože všechny potřebné informace o umístění parametru jsou dostupné v satelitní databázi MIB; u programovatelné telemetrie je však složitější.

○ Dekódování bitů získá surovou hodnotu z hodnoty zakódované v telemetrickém paketu. V typickém případě surová hodnota odpovídá hodnotě zakódované v paketu, existují však případy, kdy je nutná bitová transformace (například obrácení pořadí bitů nebo doplněk do dvojkového čísla) či transformace na úrovni bajtů.

○ Odvozené neboli syntetické parametry. Nezískávají se z kosmické lodi, ale algoritmicky se odvozují na Zemi s využitím získaných telemetrických parametrů jako operandů. Vypočítávají se pomocí vzorců zapsaných ve skriptovacích jazycích. Vypočítávají se před kalibrací, kontrolami platnosti a datováním parametrů.

Zvláštním typem odvozeného parametru jsou natvrdo zakódované odvozené parametry (HCDP), zapisované v nízkoúrovňových programovacích jazycích.

⁶ Parametry mohou být synchronní (odesílané v telemetrii ihned po vzorkování na palubě) nebo asynchronní (neodesílané v telemetrii ihned po vzorkování na palubě, ale ukládané do palubní paměti a odesílané později). Parametry se obvykle vzorkují a kódují jednou nebo několikrát v každém formátu, s výjimkou subkomutovaných parametrů, které se nevzorkují a nekódují ve všech formátech, a superkomutovaných parametrů, které se vzorkují a kódují opakovaně.

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

jako C++, Fortran nebo C. Jejich úprava vyžaduje opětovnou kompilaci zdrojového kódu.

o Datování parametru telemetrie přiřazuje vzorkům parametru datum, přičemž používá čas paketu, který je obsahuje, a přičítá posun podle specifikace v satelitní MIB.

o Kontrola překročení rozsahu (OOR) analyzuje, zda se surová hodnota parametru telemetrie nachází mimo definovaný kalibrační rozsah. Parametry telemetrie překračující rozsah se označují jako neplatné kategorií OOR. OOR slouží k posouzení platnosti parametru telemetrie a k určení, zda je jeho hodnota užitečná, nebo bezvýznamná.

Kromě toho musí být parametry mimo rozsah zobrazeny operátorům a ti je musí potvrdit. Mezi další podmínky, za nichž se parametr označí jako neplatný, patří jeho expirace nebo – v případě odvozených parametrů – výpočet pomocí neplatných parametrů. Ve všech případech musí metadata o neplatnosti parametru telemetrie uvádět důvod tohoto stavu.

• Kalibrace parametrů telemetrie převádí jejich surové hodnoty do podoby čitelné pro člověka (technické nebo kalibrované hodnoty s jednotkami odpovídajícími fyzikální veličině). Kalibraci lze provádět různými metodami:

o Numerická nebo lineární diskrétní kalibrace: používá se lineární interpolace z kalibrační křivky sestavené z dvojic (X, Y), kde X označuje surovou hodnotu a Y technickou hodnotu.

o Textová, digitální nebo stavová kalibrace: přiřazuje textové řetězce rozsahům surových hodnot parametrů. Textové hodnoty lze získat z diskrétních hodnot nebo z jejich rozsahu. Jednoduchým příkladem je stav ZAPNUTO / VYPNUTO palubních jednotek, který lze odvodit z jednobitového parametru, kde 0 znamená VYPNUTO a 1 znamená ZAPNUTO.

o Polynomiální kalibrace: používá polynom až pátého stupně k převodu surových hodnot na technické hodnoty.

Aniž bychom zacházeli do dalších podrobností o extrahovaných vlastnostech (je popsána pouze jejich podmnožina, aby bylo patrné, že jejich identifikace vyžaduje důkladnou terminologickou analýzu), následující diagram znázorňuje hlavní vlastnosti identifikované pro tuto funkční oblast:

Terminologija | 2020 | 27

197

Obr. 3. Zpracování TM – vlastnosti Obr. 1: FeatureIDE (vytvořil autor)

5. ZÁVĚRY

Tento článek popisuje vývoj modelu vlastností pro softwarové aplikace pro řízení družic. Jako vstupní podklady byly použity technické dokumenty (provozní příručky, odborné zprávy a školicí materiály), které popisují funkce zkoumaného typu systému. Prvním krokem je

198

Ricardo Eito Brun

Terminology as the Basis for Building Engineering Feature-based Models

identifikace a extrakce termínů prostřednictvím zkoumání dokumentů a určení jejich definic podle kontextu, v němž se používají. Tato kolekce termínů se dále analyzuje s cílem identifikovat vlastnosti, které byly podle funkčních kritérií uspořádány do modelu vlastností a diagramu v rámci dvanácti hlavních kategorií: správa relací, správa připojení k pozemní stanici, zpracování telemetrie, zobrazení telemetrických dat, zpracování telepříkazů, archiv mise atd.

Pro každou funkční oblast byly shrnuty a znázorněny hlavní koncepty a charakteristiky, které musí softwarový systém podporovat, ve feature diagramech vytvořených pomocí nástroje FeatureIDE. Definice a kontext použití rovněž posloužily jako základ pro stanovení vztahů mezi vlastnostmi a identifikaci příležitostí k variabilitě. Byly identifikovány tři hlavní důvody variability:

Konfigurační parametry specifické pro misi, které se obvykle spravují pomocí veřejných konfiguračních souborů.

Výběr volitelných vlastností v závislosti na typu mise: např. telepříkazy založené na poloze, které jsou charakteristické pro družice na nízké oběžné dráze (LEO) určené k pozorování Země.

Přizpůsobení služeb specifických pro misi, které rozšiřují základní služby a funkce definované ve standardech telemetrie a telepříkazů, jako je PUS.

Tato práce dokládá potřebu používat terminologické techniky ke shromažďování, analýze a dokumentování významu termínů a k získávání vztahů, které lze později využít k různým účelům. V případě modelů inženýrství založeného na vlastnostech tvoří termíny základ pro jednoznačný popis funkcí softwaru a systémů a pro identifikaci charakteristik komplexních systémů. Důsledné používání termínů je rovněž nezbytné k zajištění toho, aby různí účastníci následných inženýrských činností (návrh, implementace, testování atd.) sdíleli společné porozumění vlastnostem systému a předcházeli chybám způsobeným nedostatečným vymezením oblasti působnosti systému.

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