doi.org/10.35321/term27-08

Terminologie als basis voor het bouwen van engineering-featuremodellen

RICARDO EITO BRUN

Universidad Carlos III de Madrid

SAMENVATTING

Voor satellietoperaties is het gecombineerde gebruik van verschillende hulpmiddelen nodig om technische werkzaamheden te ondersteunen en het ruimtevaartuig te besturen. Deze communicatie wordt beheerd door het bewakings- en controlesysteem (MCS), dat telemetriegegevens van het ruimtevaartuig ontvangt en telecommando’s uitgeeft om de stand en de vliegroute van de satelliet te handhaven. Deze complexe systemen worden ontwikkeld als open platforms die kunnen worden uitgebreid en aangepast ter ondersteuning van missiespecifieke eisen en doelstellingen. In het algemeen kan worden gesteld dat deze softwaretoepassingen geschikte kandidaten zijn voor de gestructureerde en geplande implementatie van variabiliteitsmechanismen, en dat hun functionaliteit zich goed leent voor een analyse van de haalbaarheid van toepassing van featuregebaseerde modelleringstechnieken. Dit artikel beschrijft het gebruik van terminologieanalyse om een featuremodel op te stellen dat de eisenanalyse voor dit type softwaregebaseerde systemen ondersteunt.

TREFWOORDEN: technische terminologie, featuregebaseerde modellen, lucht- en ruimtevaarttechniek, terminologie-extractie

SAMENVATTING

Voor satellietoperaties zijn verschillende hulpmiddelen nodig om soepel technisch werk te waarborgen en het ruimtevaartuig te besturen. Deze communicatie wordt beheerd door het bewakings- en controlesysteem (SKS), dat telemetriegegevens van het ruimtevaartuig ontvangt en telecommando’s geeft om de stand en de baantrajectorie van de satelliet te handhaven. Deze complexe systemen zijn opgezet als open platforms die kunnen worden uitgebreid en aangepast aan de eisen en doelstellingen van een specifieke missie. We kunnen stellen dat deze toepassingen doorgaans kunnen worden gebruikt om variabiliteitsmechanismen op een gestructureerde en geplande manier te implementeren, en dat hun functionaliteit het mogelijk maakt de toepasbaarheid van featuremodelleringstechnieken te analyseren. Dit artikel beschrijft het gebruik van terminologieanalyse om een featuremodel op te stellen dat de eisenanalyse voor dit type softwaresystemen ondersteunt.

TREFWOORDEN: technische terminologie, featuremodellen, luchtvaarttechniek, termherkenning

186

Ricardo Eito Brun

Terminology as the Basis for Building Engineering Feature-based Models

1. INLEIDING

De NASA-woordenlijst definieert satellieten als: “een vrij vliegend object dat om de aarde, een andere planeet of de zon draait.” Satellieten zijn een type ruimtevaartuig dat in een regelmatige, duidelijk afgebakende baan rond het zwaartepunt van een ander hemellichaam beweegt (Garner 1996: 4). Sinds de lancering van de eerste kunstmatige satellieten – Sputnik 1 op 4 oktober^th 1957 en Explorer 1 op 31 januari^st 1958 – zijn talrijke satellietmissies met uiteenlopende doelen gelanceerd: astronomisch onderzoek, het leveren van communicatie- en navigatiediensten, aardobservatie, verkenning en wetenschappelijke missies. Satellieten zijn complexe lucht- en ruimtevaartsystemen die bestaan uit elementen op de grond en in de ruimte: het ruimtevaartuig moet worden bestuurd door een besturingselement op aarde en ermee in contact blijven. Tegenwoordig zijn wetenschappelijke vooruitgang en diensten voor gebruikers afhankelijk van satellieten en satellietconstellaties. Relevante voorbeelden zijn de Hubble Space Telescope (HST), navigatiesystemen zoals GPS (Global Positioning System), GLONASS en het Europese Galileo, UARS (Upper Atmosphere Research Satellite) en GOES (Geostationary Operational Environment Satellite). Het totale aantal satellieten dat sinds 1957 is gelanceerd – volgens de catalogus van het US SSN² – ligt dicht bij 18.200; de 2017 Index of Objects Launched into Outer Space van UNOOSA meldt dat momenteel 4.635 satellieten om de planeet draaien, een toename van 357 satellieten (8,95%) ten opzichte van het voorgaande jaar³. Het doel van dit artikel is aan te tonen dat terminologiebeheer en -extractie nodig zijn ter ondersteuning van de ontwikkeling van feature-based modellen om de concepten te ordenen die de functies beschrijven van softwaretoepassingen voor satellietmonitoring en -besturing.

Satellieten worden ingedeeld naar doel en type baan. Het doel verwijst naar de diensten die de satelliet geacht wordt te leveren. Wat de baan betreft, wordt onderscheid gemaakt tussen Low Earth Orbit (LEO), Medium Earth Orbit (MEO) en Geostationary Orbit (GEO). LEO-satellieten – die worden gebruikt voor wetenschap en aardobservatie – volgen een elliptische baan; omdat ze vanaf grondstations slechts beperkt zichtbaar zijn, worden gegevens aan boord opgeslagen en naar de grond verzonden

¹ Zie https://www.grc.nasa.gov/www/k-12/TRC/laefs/laefs_s.html#satellite [geraadpleegd op 2020-08-01].

² Het US Space Surveillance Network is verantwoordelijk voor de detectie, tracking, catalogisering en identificatie van kunstmatige objecten die om de aarde draaien. De catalogus is beschikbaar op: https://www.space-track.org/#/ssr [geraadpleegd op 2020-08-01].

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

Terminologija | 2020 | 27

187

grondstations wanneer het ruimtevaartuig zichtbaar wordt. GEO-satellieten worden gebruikt voor telecommunicatie en meteorologische doeleinden; telecommunicatiesatellieten ontvangen radiofrequentiesignalen (RF) van de aarde, versterken deze, verschuiven hun frequentie en zenden ze terug naar de aarde. Ze draaien 36.000 km boven de evenaar (in hetzelfde vlak), en hun omlooptijd is synchroon met de rotatie van de aarde, zodat ze voortdurend boven hetzelfde punt op de evenaar blijven)⁴. Net als satellieten hebben ook wetenschappelijke missies in de diepe ruimte vergelijkbare monitoring en besturing nodig voor telecommandering en telemetrie-ontvangst.

Satellietmissies vereisen gespecialiseerd personeel om de status en positie van de satelliet in realtime en continu te monitoren. Missiecontrole omvat de taken die na de lancering door operationele ingenieurs worden uitgevoerd met behulp van softwaretoepassingen, en houdt de uitwisseling in van gegevens tussen de grond- en ruimtecomponenten voor het monitoren en besturen van de status van de subsystemen aan boord van de satelliet. Bij wetenschappelijke missies is het ook nodig informatie van de satellietlading te ontvangen en aan de eindgebruikers (de wetenschappelijke gemeenschap) te leveren. Typische functies die tijdens missiecontrole worden uitgevoerd, zijn de ontvangst en analyse van telemetrie, telecommandering en tracking. Telemetrie bestaat uit gegevens die van de satelliet naar de aarde worden verzonden en die informatie geven over de status en toestand van de satelliet en zijn subsystemen. Telecommando's zijn opdrachten die vanaf de grond naar het ruimtevaartuig worden verzonden om het te configureren en te bedienen. (Uhlig, Sellmaier, and Schmidhuber 2015: 232). Tracking en stationkeeping, ook bekend als ranging, omvatten het monitoren en bepalen van de vliegroute en positie met behulp van RF-technieken en signalen.

Vanuit het perspectief van software-engineering vereist satellietbesturing verschillende toepassingen en hulpmiddelen voor vluchtdynamica, missieplanning, telemetrie en telecommandering, netwerkbesturing en routering, evenals interfaces daartussen. Deze complexiteit heeft ertoe geleid dat ruimtevaartorganisaties verschillende oplossingen hebben aangeboden. Een van de belangrijkste mijlpalen in de ontwikkeling van MCS-software was het besluit van de afdeling Ground Systems Engineering van ESA om een reeks softwaretoepassingen te ontwikkelen en in licentie te geven aan de Europese industrie, verspreid onder de naam MICONYS^®

⁴ GEO-satellieten zijn verspreid over een beperkt gebied in de ruimte. Om botsingen te voorkomen, worden baanslots toegewezen door de International Telecommunication Union (ITU); het risico op botsingen houdt verband met het ruimteafvalprobleem, dat tegenwoordig steeds meer aandacht krijgt.

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

(Mission Control System). MICONYS en zijn component SCOS-2000® zijn waarschijnlijk de bekendste voorbeelden van dit beleid van ESA voor softwareontwikkeling en innovatie en technologieoverdracht (Kaufeler, Jones and Karl 2001). SCOS-2000 ondersteunt het verzenden van telecommando’s, de ontvangst van telemetrie, weergave en archivering. SCOS-2000 was het resultaat van de ervaring die ESA had opgedaan met de ontwikkeling en exploitatie van eerdere vergelijkbare systemen: MSSS, SCOS-1 en SCOS-2. Momenteel ontwikkelt ESA het nieuwe MCS-systeem, dat SCOS-2000 in de toekomst moet vervangen. De naam ervan is European Ground Systems – Common Core (EGS-CC). Net als SCOS heeft het project tot doel een gemeenschappelijke infrastructuur te ontwikkelen ter ondersteuning van de bewaking en besturing van ruimtemissies in de fasen vóór en na de lancering, met gebruik van moderne technologieën en servicegerichte architecturen (Peccioli et al. 2012). De ontwikkeling van EGS-CC valt niet alleen onder de verantwoordelijkheid van ESA: Europese nationale ruimtevaartagentschappen (CNES, UK Space Agency en DLR) en industriële ondernemingen (AIRBUS Defence and Space, Thales Alenia Space en OHB Systems) maken deel uit van het project.

Naast ESA-projecten zijn er andere initiatieven die gericht zijn op de ontwikkeling van een generiek MCS-softwaresysteem. NASA heeft soortgelijke projecten voltooid, waarvan de meeste interne ontwikkelingen waren. Het Goddard Space Flight Centre ontwikkelde twee systemen, ITOS en ASIST, voor het beheer van missies zoals 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) of LRO (Lunar Reconnaissance Orbiter) (Pfarr et al. 2007).

In al deze gevallen gaat het om een complex systeem dat verschillende functies moet implementeren, die al dan niet geactiveerd kunnen worden afhankelijk van de kenmerken van de satelliet en de missie. Daarom zijn deze software-intensieve systemen geschikte kandidaten voor ontwikkeling met behulp van productlijnen en featuregebaseerde modelleertechnieken, die steunen op een heldere en goed georganiseerde ordening van concepten om het domein en de benodigde systeemmogelijkheden te begrijpen.

2. FEATUREGEBASEERDE MODELLERING

ALS ORDENING VAN CONCEPTEN

Featuregebaseerde modellering is een van de technieken die worden toegepast in softwareproductlijnengineering, een discipline voor het bouwen van herbruikbare softwareprogramma’s die eind jaren negentig populair werd. SPLE beoogt

Terminologija | 2020 | 27

189

herbruikbare componenten en artefacten te bouwen die later kunnen worden gecombineerd om producten te maken die aansluiten bij de behoeften van een specifieke klant en context. Ervaringen met SPLE zijn uitvoerig gedocumenteerd in de professionele en academische literatuur. Capilla (2013) beschreef verschillende casestudy’s waarin SPLE met succes werd toegepast: de operationele, missiekritieke vluchtprogramma’s van Boeing’s voor avionica- en cockpitfuncties, de motorbesturingssoftware van Bosch’s voor benzinesystemen, de printersoftware van Hewlett Packard’s, de apparatuur voor energieopwekking en -transmissie van Toshiba’s en de besturingssoftware voor aandrijflijnen van General Motors’. Volgens Apel et al. (2013: 9) omvatten de voordelen van softwareproductlijnen (SPL) het afstemmen van softwareproducten op de specifieke behoeften van klanten, lagere kosten – doordat een verzameling herbruikbare middelen op verschillende manieren kan worden gecombineerd om nieuwe producten voort te brengen –, hogere kwaliteit en een kortere time-to-market.

Features en featuregebaseerde modellering zijn relevante concepten bij de ontwikkeling van SPL. ISO/IEC/IEEE 24765:2010, Systems and software engineering — Vocabulary, geeft een algemene definitie van features, overgenomen uit IEEE Std 829:2008 IEEE Standard for Software and System Test Documentation: “Een onderscheidend kenmerk van een systeemitem. OPMERKING: omvat zowel functionele als niet-functionele attributen, zoals prestaties en herbruikbaarheid.” Kang and Lee (2013, 28) definiëren features als “abstracte concepten die de communicatie tussen uiteenlopende belanghebbenden van een productlijn doeltreffend ondersteunen en die daarom een natuurlijke en intuïtieve manier vormen om de gemeenschappelijkheid en variabiliteit van productlijnen in termen van features uit te drukken.”

Features dienen verschillende doelen tijdens het productideatie- en ontwikkelingsproces. Ze zijn middelen om productkenmerken te communiceren en de identificatie van vereisten te ondersteunen; daarnaast zijn het concepten die ontwerp- en implementatiebeslissingen sturen.

De ontwikkeling van een productlijn omvat twee complementaire levenscycli:

• Domeinengineering, en

• Applicatie-engineering.

De IEEE 1517-2010-norm definieert domeinengineering als: “Levenscyclus bestaande uit een reeks processen voor het specificeren en beheren van de gemeenschappelijkheid en variabiliteit van een productlijn. Domeinengineering analyseert het domein van een productlijn en ontwikkelt een verzameling herbruikbare artefacten. Deze artefacten omvatten softwarevereisten, ontwerpelementen, testgevallen en

190

Ricardo Eito Brun

Terminology as the Basis for Building Engineering Feature-based Models

procedures, gebruikersdocumentatie enz. Domeinanalyse kan worden beschouwd als een vorm van requirements engineering voor de gehele productlijn, met inbegrip van de identificatie van verwachte variabiliteit. Het belangrijkste artefact dat door domeinanalyse wordt opgeleverd, is het featuremodel, dat de producten binnen de productlijn specificeert en beschrijft.

Featuremodellering is een diagramtechniek die in de jaren negentig werd geïntroduceerd met de FODA-methodologie (Feature-Oriented Domain Analysis). FODA bood basisbouwstenen voor het weergeven van structurele relaties (compositie, generalisatie en specialisatie), optionaliteit, alternatieven en onderlinge afhankelijkheden. Later werd de methode herzien door verschillende auteurs (Kang and Lee 2013: 30–31). Featurediagrammen zijn de visuele weergave van featuremodellen, waarin features als vakken in een hiërarchische boom worden weergegeven. Aan elke knoop is een label gekoppeld met de naam van de feature. De hiërarchische ordening van de features creëert relaties tussen ouders en kinderen. Als een childfeature wordt geselecteerd, moet ook de parentfeature worden geselecteerd. Diagrammen kunnen onderscheid maken tussen verplichte en optionele features, en aangeven welke combinaties van features geldig zijn.

In het bijzonder kunnen featurediagrammen het volgende weergeven:

Abstracte features, die worden gebruikt om de features in de boom te ordenen, maar niet aan implementatieartefacten zijn gekoppeld. Ze worden weergegeven met grijze vakken.

Concrete features, die overeenkomen met implementatieartefacten en worden weergegeven met witte vakken.

Verplichte features, met een ingevulde stip boven op de bovenrand van hun vak.

Optionele features, met een niet-ingevulde stip boven op de bovenrand van hun vak.

De noodzaak om slechts één van de childfeatures van een specifieke parent te selecteren (exclusieve OR, XOR of één-uit-veel). Dit wordt weergegeven met een lege boog aan de onderrand van het vak van de parentfeature.

De mogelijkheid om meer dan één childfeature van een specifieke parent te selecteren (OR of enkele-uit-veel). Dit wordt weergegeven met een gevulde boog aan de onderrand van het vak van de parentfeature.

Afhankelijkheden tussen features, weergegeven met pijlen voorzien van tekstuele annotaties.

Terminologija | 2020 | 27

191

Het onderstaande diagram toont een typisch featurediagram met de hierboven beschreven conventies:

Fig. 1. Voorbeeld van featurediagramnotatie (Bron: Gargantini 2015)

Een featuremodel moet naast het diagram aanvullende informatie bevatten. Apel et al. (2013: 27) wijzen op de mogelijkheid om de volgende gegevens toe te voegen:

“Beschrijving van een feature en de bijbehorende reeks vereisten.

Relatie met andere features, met name hiërarchie, volgorde en groepering.

Externe afhankelijkheden, zoals vereiste hardwarebronnen.

Belanghebbenden.

Geschatte of gemeten kosten voor de realisatie van een feature.

Enz.”

De ontwikkeling van een featuremodel om de functionele kenmerken van softwaretoepassingen voor satellietbesturing weer te geven, moet beginnen met een helder begrip en een modellering van de concepten die het domein vormen. Daartoe vormen activiteiten op het gebied van terminologie en terminografie, en de identificatie van termen, concepten en hun onderlinge relaties, de basis voor het opbouwen van het beoogde model.

192

Ricardo Eito Brun

Terminology as the Basis for Building Engineering Feature-based Models

3. WERKMETHODOLOGIE

Het voorgestelde featuremodel is volgens de volgende stappen voltooid:

Identificatie en beoordeling van professionele en academische literatuur die op dit gebied is gepubliceerd. Dit omvat het zoeken naar informatie over de aanpak die is gevolgd in ruimtevaartprojecten onder leiding van organisaties zoals ESA (European Space Agency) of NASA (National Aeronautics and Space Administration).

Ontwikkeling van een woordenlijst op basis van de geanalyseerde literatuur, waarbij technieken voor terminologiebeheer worden toegepast om informatie vast te leggen over termen, onderlinge relaties, definities die in de documenten zijn aangetroffen en de context waarin de termen worden gebruikt.

Creatie van een featuregebaseerd model dat de functies weergeeft die worden aangeboden door softwaretoepassingen voor satellietbewaking en -besturing, met de woordenlijst als basis.

De inputs die werden gebruikt om termen te identificeren, omvatten een deelverzameling van technische documenten waarin het geselecteerde product wordt beschreven: bedieningshandleidingen, whitepapers en trainingsmateriaal. Het featuremodel is een hiërarchische boomstructuur van features die als verplicht of optioneel zijn gemarkeerd, met onderlinge afhankelijkheden. In het geval van de geanalyseerde softwaretoepassing werden naast de identificatie van optionele en verplichte features aanvullende eisen voor variabiliteit van de productlijn geïdentificeerd. Met name vereisen sommige functies die door de onderzochte software worden ondersteund dat bestaande code wordt overschreven of aangepast. Deze variabiliteitsgevallen werden geïdentificeerd met hulp van deskundigen die werkzaam zijn in de ontwikkeling en aanpassing van dit type softwaretoepassing. Er werden persoonlijke interviews afgenomen om die informatie te verzamelen.

De geselecteerde tool voor het maken van het featuremodel en de diagrammen is FeatureIDE⁵. Dit is een opensourcetool op basis van Java en Eclipse, ontwikkeld door medewerkers van de Otto-von-Guericke-Universität Magdeburg. Met FeatureIDE is het mogelijk om met een grafische editor een featuremodel te maken, features als verplicht, optioneel of abstract te markeren en de hiërarchische boomstructuur op te bouwen. Zodra het featuremodel is opgebouwd, kunt u verschillende configurations maken: selecties van features die zullen worden gebruikt om de doelsoftwaretoepassing te genereren

⁵ See https://FeatureIDE.github.io/. Last checked: 01-03-2018.

Terminologija | 2020 | 27

193

broncode. Helaas biedt de tool geen mogelijkheden om termen of terminologie-eenheden te beheren, waardoor het gebruik van aanvullende tools noodzakelijk is.

Fig. 2. FeatureIDE (gemaakt door de auteur)

4. PRESENTATIE VAN DE RESULTATEN EN DISCUSSIE

In deze sectie wordt één onderdeel van het featuremodel voor softwaretoepassingen van Mission Control Systems (MCS) samengevat. De analyse van de uit de documenten geëxtraheerde concepten leidde tot een indeling van de systeemfunctionaliteiten in de volgende gebieden:

Desktop- en sessiebeheer, dat de functies biedt voor inloggen, een sessie starten en de verschillende toepassingen opstarten. Bij het beheer van meerdere satellieten kan de gebruiker tussen de werkruimten van de satellieten schakelen.

Telemetrieketen, die telemetrieverwerking, alarmbeheer en telemetrieweergave omvat.

194

Ricardo Eito Brun

Terminology as the Basis for Building Engineering Feature-based Models

Telecommandoketen, die uplink van telecommando’s, handmatige stack, geplande stack en telecommandogeschiedenis omvat.

TT&C/TCR-brug, die inzicht en controle biedt over de interface met het grondstation voor gegevensstromen van telemetrie, commando’s, afstandsmeting (TCR) en antennerichting.

Gebeurtenissenlogboek, waarin tijdens de systeemoperaties vastgestelde gebeurtenissen worden geregistreerd en operators de volledige gebeurtenisgeschiedenis kunnen doorbladeren en doorzoeken.

Beheer van het geheugen aan boord, dat voorzieningen biedt voor het beheren (downloaden, bewerken en uplinken) van het geheugenbeeld van het ruimtevaartuig.

De analyse van de documentatie en termen leidde tot het opstellen van featuremodellen voor deze systeemfuncties. Het specifieke geval van telemetriebeheer wordt als voorbeeld samengevat. We zien hoe voor de geïdentificeerde features definities worden gegeven die zijn gebaseerd op bestaande literatuur en technische documentatie:

De term telemetrieketen verwijst naar de verschillende processen die betrokken zijn bij de verwerking van telemetrie: ontvangst via TT&C, pakketvorming, archivering en distributie naar gebruikertoepassingen:

Telemetriepakketvorming. MCS neemt de telemetriebronpakketten volgens de telemetriepakketstandaard, voegt metadata toe (bijv. de kwaliteit van de telemetriestroom) en zet deze om in een of meer interne MCS-telemetriepakketten. De criteria voor het genereren van pakketten uit de binnenkomende gegevens kunnen variëren afhankelijk van de satelliet, de missie en de BBE-protocollen.

Controle van de pakketkwaliteit. MCS controleert voortdurend de telemetriekwaliteit met behulp van controles die door TT&C of door MCS zelf worden uitgevoerd. Aan elk intern pakket worden metadata over de telemetriekwaliteit toegevoegd. Afhankelijk van de resultaten van deze controles kan het pakket worden geclassificeerd als geschikt voor verwerking (GOOD) of ongeschikt voor verwerking (BAD). Ook verloren telemetriepakketten moeten tijdens dit proces worden geïdentificeerd.

Een typische kwaliteitscontrole is de framevolgordecontrole, waarmee wordt vastgesteld of de frames al dan niet in de juiste volgorde worden ontvangen.

Terminologija | 2020 | 27

195

Er worden gebeurtenissen gegenereerd als niet aan deze controles wordt voldaan. De operator kan selecteren welk gedrag wordt toegepast wanneer BAD-telemetrieframes worden geïdentificeerd (verwerken of verwerpen).

• Tijdkwaliteitscontroles. Deze controles verifiëren of de door de TT&C voor elke telemetriestroom gerapporteerde tijd en de lokale MCS-tijden niet te ver uiteenlopen. Het verschil tussen de huidige MCS-tijd en de tijdstempel in het telemetrieframe (ingesteld door het grondstation bij ontvangst van het frame) valt binnen een configureerbaar tijdvenster. Als deze controles mislukken, worden gebeurtenisberichten gegenereerd. Voor tijdkwaliteitscontroles moeten de telemetriepakketten van een tijdstempel worden voorzien.

• Telemetriedemultiplexing, waarbij telemetrieparametersamples uit de pakketten worden gehaald⁶. Dit omvat parameterextractie, bitdecodering, kalibratie, controle op waarden buiten het bereik, geldigheidscontrole en datering van parameters.

○ Extractie van telemetrieparameters lokaliseert en haalt de ruwe waarden van telemetrieparameters uit de pakketten. Ruwe waarden zijn doorgaans gehele getallen met of zonder teken, of drijvendekommagetallen. Dit proces is eenvoudig bij vaste telemetrie, omdat alle benodigde informatie over de locatie van de parameter beschikbaar is in de satelliet-MIB, maar is complexer bij programmeerbare telemetrie.

○ Bitdecodering haalt de ruwe waarde uit de in het telemetriepakket gecodeerde waarde. In een typische situatie komt de ruwe waarde overeen met de in het pakket gecodeerde waarde, maar soms is een transformatie op bitniveau (zoals bitomkering of two’s complement) of op byteniveau nodig.

○ Afgeleide of synthetische parameters. Deze worden niet van het ruimtevaartuig verkregen, maar op de grond algoritmisch afgeleid met behulp van verkregen telemetrieparameters als operanden. Ze worden berekend met formules die in scripttalen zijn geschreven. Ze worden berekend vóór kalibratie, geldigheidscontroles en datering van parameters.

Een speciaal type afgeleide parameter is hardgecodeerde afgeleide parameters (HCDP), geschreven in programmeertalen op laag niveau

⁶ De parameters kunnen synchroon zijn (via telemetrie omlaag gestuurd zodra ze aan boord zijn bemonsterd) of asynchroon (niet via telemetrie omlaag gestuurd zodra ze aan boord zijn bemonsterd, maar opgeslagen in het geheugen aan boord en later omlaag gestuurd). Parameters worden doorgaans één of meerdere keren per formaat bemonsterd en gecodeerd, met uitzondering van subgecommuteerde parameters, die niet in alle formaten worden bemonsterd en gecodeerd, en supergecommuteerde parameters, die meerdere keren worden bemonsterd en gecodeerd.

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

zoals C++, Fortran of C. Voor de wijziging ervan moet de broncode opnieuw worden gecompileerd.

o Datering van telemetrieparameters kent datums toe aan de parameterwaarden, op basis van het tijdstip van het pakket waarin ze zijn opgenomen en met toevoeging van een offset zoals gespecificeerd in de satelliet-MIB.

o Bewaking van waarden buiten het bereik (OOR) analyseert of de ruwe waarde van een telemetrieparameter buiten het gedefinieerde kalibratiebereik valt. Telemetrieparameters buiten het bereik worden met de categorie OOR als ongeldig aangemerkt. OOR wordt gebruikt om de geldigheid van de telemetrieparameter te beoordelen en aan te geven of de waarde ervan bruikbaar of betekenisloos is.

Daarnaast moeten parameters buiten het bereik aan de operators worden weergegeven en door hen worden bevestigd. Andere omstandigheden waarin een parameter ongeldig wordt verklaard, zijn onder meer dat de parameter is verlopen of dat deze – in het geval van afgeleide parameters – is berekend met behulp van ongeldige parameters. In alle gevallen moeten de metagegevens over de ongeldigheid van de telemetrieparameter de reden voor deze status vermelden.

• Kalibratie van telemetrieparameters zet hun ruwe waarden om in een voor mensen leesbare vorm (technische of gekalibreerde waarden met de eenheden die bij de fysieke grootheid horen). Kalibratie kan op verschillende manieren worden uitgevoerd:

o Numerieke of lineaire discrete kalibratie: er wordt lineaire interpolatie toegepast op basis van een kalibratiecurve die bestaat uit (X, Y)-paren, waarbij X staat voor de ruwe waarde en Y voor de technische waarde.

o Tekstuele, digitale of statuskalibratie: hierbij worden tekstreeksen gekoppeld aan bereiken van ruwe parameterwaarden. Tekstuele waarden kunnen worden verkregen uit discrete waarden of uit een bereik daarvan. Een eenvoudig voorbeeld is de AAN-/UIT-status van de boordeenheden, die kan worden verkregen uit een parameter van één bit, waarbij 0 UIT betekent en 1 AAN.

o Polynomiale kalibratie: hierbij wordt een polynoom van maximaal de vijfde graad gebruikt om ruwe waarden om te zetten in technische waarden.

Zonder nader in te gaan op de geëxtraheerde kenmerken (er wordt slechts een deel beschreven om te laten zien dat de identificatie ervan gedegen terminologisch werk vereist), toont het volgende diagram de belangrijkste kenmerken die voor dit functionele gebied zijn geïdentificeerd:

Terminologija | 2020 | 27

197

Fig. 3. TM-verwerking – kenmerken Fig 1: FeatureIDE (gemaakt door de auteur)

5. CONCLUSIES

Dit artikel beschrijft de ontwikkeling van een featuremodel voor softwaretoepassingen voor satellietbesturing, waarbij technische documenten (bedieningshandleidingen, whitepapers en trainingsmateriaal) als uitgangspunt zijn gebruikt. Deze documenten beschrijven de functionaliteiten van het type systeem dat wordt onderzocht. De eerste stap is de

198

Ricardo Eito Brun

Terminology as the Basis for Building Engineering Feature-based Models

identificatie en extractie van termen door de documenten te inspecteren en definities ervan vast te stellen aan de hand van de context waarin ze worden gebruikt. Deze verzameling termen wordt vervolgens verder geanalyseerd om kenmerken te identificeren, die op basis van functionele criteria in het featuremodel en diagram zijn ingedeeld in twaalf hoofdcategorieën: sessiebeheer, beheer van grondstationverbindingen, telemetrieverwerking, weergave van telemetriegegevens, verwerking van telecommando’s, missiearchief, enz.

Voor elk functioneel gebied werden de belangrijkste concepten en de kenmerken die door een softwaresysteem moeten worden ondersteund, samengevat en weergegeven in featurediagrammen die met de FeatureIDE-tool zijn gemaakt. De definities en de gebruikscontext vormden ook de basis voor het vaststellen van de relaties tussen de kenmerken en voor het identificeren van mogelijkheden voor variabiliteit. Er werden drie hoofdredenen voor variabiliteit vastgesteld:

Missiespecifieke configuratieparameters die doorgaans worden beheerd met openbare configuratiebestanden.

Selectie van optionele kenmerken, afhankelijk van het type missie: bijvoorbeeld positiegebaseerde telecommando’s, die kenmerkend zijn voor LEO-satellieten voor aardobservatie.

Aanpassing van missiespecifieke diensten die de basisdiensten en -functies uitbreiden die zijn gedefinieerd in telemetrie- en telecommandostandaarden zoals PUS.

Dit werk toont aan dat terminologische technieken moeten worden toegepast om de betekenis van termen te verzamelen, te analyseren en te documenteren, en om relaties te extraheren die later voor verschillende doeleinden kunnen worden gebruikt. Bij feature-based engineeringmodellen vormen termen de basis om de functies van software en systemen ondubbelzinnig te beschrijven en de kenmerken van complexe systemen te identificeren. Consistent gebruik van termen is ook noodzakelijk om ervoor te zorgen dat de verschillende actoren die betrokken zijn bij latere engineeringtaken (ontwerp, implementatie, testen enz.) een gemeenschappelijk begrip hebben van de systeemkenmerken, en fouten te voorkomen die worden veroorzaakt door een gebrekkige definitie van het domein waarvoor het systeem bedoeld is.

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