Terminology as the Basis for Building Engineering Feature-based Models

doi.org/10.35321/term27-08 Terminologie als Grundlage für den Aufbau ingenieurwissenschaftlicher merkmalsbasierter Modelle RICARDO EITO BRUN Universidad Carlos III de Madrid ZUSAMMENFASSUNG Der Satellitenbetrieb erfordert den kombinierten Einsatz verschiedener Werkzeuge zur Unterstützung technischer Tätigkeiten und zur Steuerung des Raumfahrzeugs. Diese Kommunikation wird vom Überwachungs- und Kontrollsystem (MCS) verwaltet, das Telemetriedaten vom Raumfahrzeug empfängt und Telekommandos ausgibt, um die Lage und Flugbahn des Satelliten aufrechtzuerhalten. Diese komplexen Systeme werden als offene Plattformen entwickelt, die erweitert und angepasst werden können, um missionsspezifische Anforderungen und Ziele zu unterstützen. Allgemein lässt sich sagen, dass sich diese Softwareanwendungen gut dazu eignen, Variabilitätsmechanismen strukturiert und planmäßig umzusetzen, und dass ihre Funktionalität ein geeigneter Gegenstand ist, um die Machbarkeit der Anwendung merkmalsbasierter Modellierungstechniken zu untersuchen. Dieser Beitrag beschreibt den Einsatz einer Terminologieanalyse zum Aufbau eines Merkmalsmodells, das die Anforderungsanalyse für diese Art softwarebasierter Systeme unterstützt. SCHLÜSSELWÖRTER: Fachterminologie, merkmalsbasierte Modelle, Luft- und Raumfahrttechnik, Terminologieextraktion ZUSAMMENFASSUNG Der Satellitenbetrieb erfordert verschiedene Werkzeuge, um reibungslose technische Arbeiten zu gewährleisten und das Raumfahrzeug zu steuern. Diese Kommunikation wird vom Überwachungs- und Kontrollsystem (SKS) gesteuert, das Telemetriedaten vom Raumfahrzeug empfängt und Telekommandos ausgibt, damit die Lage und Flugbahn des Satelliten aufrechterhalten werden. Diese komplexen Systeme sind als offene Plattformen konzipiert, die entsprechend den Anforderungen und Zielen einer bestimmten Mission erweitert und angepasst werden können. Allgemein lässt sich sagen, dass diese Anwendungen zur strukturierten und planmäßigen Einführung von Variabilitätsmechanismen eingesetzt werden können und ihre Funktionalität die Analyse der Möglichkeiten zur Anwendung merkmalsbasierter Modellierungsmethoden erlaubt. Dieser Beitrag beschreibt die Nutzung einer Terminologieanalyse zur Erstellung eines Merkmalsmodells, das die Anforderungsanalyse für diese Art von Softwaresystemen unterstützt. SCHLAGWÖRTER: Fachterminologie, Merkmalsmodelle, Luft- und Raumfahrttechnik, Terminerkennung 186 Ricardo Eito Brun Terminology as the Basis for Building Engineering Feature-based Models 1. EINLEITUNG Das NASA-Glossar definiert Satelliten als: „ein frei fliegendes Objekt, das die Erde, einen anderen Planeten oder die Sonne umkreist.“ Satelliten sind eine Art von Raumfahrzeugen, die sich auf einer regelmäßigen, klar definierten Umlaufbahn um den Schwerpunkt eines anderen Himmelskörpers bewegen (Garner 1996: 4). Seit dem Start der ersten künstlichen Satelliten – Sputnik 1 am 4. Oktoberth 1957 und Explorer 1 am 31. Januarst 1958 – wurden zahlreiche Satellitenmissionen zu unterschiedlichen Zwecken gestartet: astronomische Erforschung, Bereitstellung von Kommunikations- und Navigationsdiensten, Erdbeobachtung, Aufklärung und wissenschaftliche Missionen. Satelliten sind komplexe Luft- und Raumfahrtsysteme, die aus boden- und weltraumgestützten Komponenten bestehen: Das Raumfahrzeug muss von einer steuernden Komponente auf der Erde betrieben werden und mit ihr in Kontakt bleiben. Heute hängen wissenschaftlicher Fortschritt und Dienstleistungen für die Nutzer von Satelliten und Satellitenkonstellationen ab. Zu den einschlägigen Beispielen zählen das Hubble-Weltraumteleskop (HST), Navigationssysteme wie GPS (Global Positioning System), GLONASS und das europäische Galileo, UARS (Upper Atmosphere Research Satellite) oder GOES (Geostationary Operational Environment Satellite). Die Gesamtzahl der seit 1957 gestarteten Satelliten liegt laut dem Katalog des US-SSN2 bei knapp 18.200; der 2017 Index of Objects Launched into Outer Space von UNOOSA verzeichnet 4.635 Satelliten, die derzeit die Erde umkreisen, 357 Satelliten (8,95%) mehr als im Vorjahr3. Ziel dieses Artikels ist es, die Notwendigkeit des Einsatzes von Terminologiemanagement und Terminologieextraktion zur Unterstützung der Entwicklung merkmalsbasierter Modelle aufzuzeigen, mit denen die Konzepte zur Beschreibung der Funktionen von Softwareanwendungen für die Satellitenüberwachung und -steuerung geordnet werden. Satelliten werden nach ihrem Zweck und ihrer Umlaufbahn klassifiziert. Der Zweck bezieht sich auf die Dienste, die der Satellit bereitstellen soll. Hinsichtlich der Umlaufbahn wird zwischen niedriger Erdumlaufbahn (LEO), mittlerer Erdumlaufbahn (MEO) und geostationärer Umlaufbahn (GEO) unterschieden. LEO-Satelliten – die für Wissenschaft und Erdbeobachtung eingesetzt werden – folgen einer elliptischen Umlaufbahn; da ihre Sichtbarkeit von Bodenstationen aus begrenzt ist, werden Daten an Bord gespeichert und zur Erde gesendet 1 Siehe https://www.grc.nasa.gov/www/k-12/TRC/laefs/laefs_s.html#satellite [abgerufen am 2020-08-01]. 2 Das US Space Surveillance Network ist für die Erfassung, Verfolgung, Katalogisierung und Identifizierung künstlicher Objekte zuständig, die die Erde umkreisen. Der Katalog ist verfügbar unter: https://www.space-track.org/#/ssr [abgerufen am 2020-08-01]. 3 Büro der Vereinten Nationen für Weltraumfragen. Siehe https://www.pixalytics.com/sats-orbiting-earth-2017/ Terminologija | 2020 | 27 187 Bodenstationen, sobald das Raumfahrzeug sichtbar wird. GEO-Satelliten werden für Telekommunikations- und meteorologische Zwecke eingesetzt; Telekommunikationssatelliten empfangen Hochfrequenzsignale (RF) von der Erde, verstärken sie, verschieben ihre Frequenz und senden sie zur Erde zurück. Sie umkreisen die Erde 36.000 km über dem Äquator (in derselben Ebene), und ihre Rotation ist mit der Erdrotation synchronisiert, sodass sie sich ständig über demselben Punkt am Äquator befinden)4. Ähnlich wie Satelliten benötigen auch wissenschaftliche Weltraummissionen eine vergleichbare Überwachung und Steuerung für die Übertragung von Telecommands und den Empfang von Telemetrie. Satellitenmissionen erfordern speziell eingesetztes Personal, das den Status und die Position des Satelliten in Echtzeit und kontinuierlich überwacht. Die Missionskontrolle umfasst die nach dem Start von Betriebsingenieuren mithilfe von Softwareanwendungen ausgeführten Aufgaben und beinhaltet den Datenaustausch zwischen Boden- und Weltraumsegment zur Überwachung und Steuerung des Status der Bordsysteme des Satelliten. Bei wissenschaftlichen Missionen müssen außerdem die Informationen der Satellitennutzlast empfangen und an die Endnutzer (die wissenschaftliche Gemeinschaft) weitergeleitet werden. Zu den typischen Funktionen der Missionskontrolle gehören der Empfang und die Analyse von Telemetrie, die Übertragung von Telecommands und die Bahnverfolgung. Telemetrie sind Daten, die vom Satelliten zur Erde übertragen werden und über den Status und die Betriebsbedingungen des Satelliten und seiner Subsysteme informieren. Telecommands sind Befehle, die vom Boden zum Raumfahrzeug übertragen werden, um es zu konfigurieren und zu betreiben. (Uhlig, Sellmaier, and Schmidhuber 2015: 232). Bahnverfolgung und Bahnhaltung, auch als Entfernungsmessung bezeichnet, bestehen in der Überwachung und Bestimmung von Flugbahn und Position mithilfe von RF-Techniken und -Signalen. Aus Sicht der Softwaretechnik erfordert die Satellitensteuerung verschiedene Anwendungen und Werkzeuge für Flugdynamik, Missionsplanung, Telemetrie und Übertragung von Telecommands, Netzwerksteuerung und Routing sowie Schnittstellen zwischen ihnen. Diese Komplexität hat dazu geführt, dass Raumfahrtagenturen unterschiedliche Lösungen bereitstellen. Ein wichtiger Meilenstein bei der Entwicklung von MCS-Software war die Entscheidung der Abteilung Ground Systems Engineering der ESA, eine Reihe von Softwareanwendungen zu entwickeln und an die europäische Industrie zu lizenzieren, die unter dem Namen MICONYS® vertrieben wurden. 4 GEO-Satelliten verteilen sich auf einen begrenzten Bereich im Weltraum. Umlaufbahnpositionen werden von der Internationalen Fernmeldeunion (ITU) zugewiesen, um Kollisionen zu vermeiden – ein Risiko im Zusammenhang mit Weltraummüll, dem heute größere Aufmerksamkeit gewidmet wird. 188 Ricardo Eito Brun │ Terminology as the Basis for Building Engineering Feature-based Models (Missionskontrollsystem). MICONYS und seine Komponente SCOS-2000® sind wahrscheinlich die bekanntesten Beispiele für diese Politik der ESA in Bezug auf Softwareentwicklung, Innovation sowie Technologie- und Wissenstransfer (Kaufeler, Jones and Karl 2001). SCOS-2000 unterstützt die Übermittlung von Telecommands, den Empfang von Telemetrie, die Anzeige und die Archivierung. SCOS-2000 entstand aus den Erfahrungen, die die ESA bei der Entwicklung und dem Betrieb früherer ähnlicher Systeme gesammelt hatte: MSSS, SCOS-1 und SCOS-2. Heute entwickelt die ESA das neue MCS-System, das SCOS-2000 künftig ersetzen soll. Sein Name lautet European Ground Systems – Common Core (EGS-CC). Ähnlich wie SCOS verfolgt das Projekt das Ziel, eine gemeinsame Infrastruktur zur Unterstützung der Überwachung und Steuerung von Weltraummissionen in den Phasen vor und nach dem Start zu entwickeln, wobei moderne Technologien und serviceorientierte Architekturen zum Einsatz kommen (Peccioli et al. 2012). Die Entwicklung von EGS-CC liegt nicht allein in der Verantwortung der ESA: Europäische nationale Weltraumagenturen (CNES, UK Space Agency und DLR) sowie Industrieunternehmen (AIRBUS Defence and Space, Thales Alenia Space und OHB Systems) sind an dem Projekt beteiligt. Neben den ESA-Projekten gibt es weitere Initiativen zur Entwicklung eines generischen MCS-Softwaresystems. Die NASA hat ähnliche Projekte abgeschlossen, von denen die meisten interne Entwicklungen waren. Das Goddard Space Flight Centre entwickelte zwei Systeme, ITOS und ASIST, für die Verwaltung von Missionen wie 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) oder LRO (Lunar Reconnaissance Orbiter) (Pfarr et al. 2007). In all diesen Fällen haben wir es mit einem komplexen System zu tun, das verschiedene Funktionen implementieren muss, die abhängig von den Merkmalen des Satelliten und der Mission aktiviert werden können oder nicht. Daher eignen sich diese softwareintensiven Systeme gut für die Entwicklung mithilfe von Produktlinien- und merkmalsbasierten Modellierungstechniken, die auf einer klaren und gut organisierten Struktur von Konzepten beruhen, um die Domäne und die erforderlichen Systemfunktionen zu verstehen. 2. MERKMALSBASIERTE MODELLIERUNG ALS ORGANISATION VON KONZEPTEN Merkmalsbasierte Modellierung ist eine der Techniken der Software-Produktlinienentwicklung, einer Disziplin zur Entwicklung wiederverwendbarer Softwareprogramme, die Ende der 1990er-Jahre populär wurde. SPLE zielt darauf ab, Terminologija | 2020 | 27 189 wiederverwendbare Komponenten und Artefakte zu entwickeln, die später kombiniert werden können, um Produkte zu erstellen, die den Bedürfnissen eines bestimmten Kunden und Kontexts entsprechen. Erfahrungen mit SPLE sind in der Fach- und Wissenschaftsliteratur umfassend dokumentiert. Capilla (2013) führte mehrere Fallstudien an, in denen SPLE erfolgreich angewendet wurde: die operativen, missionskritischen Flugprogramme von Boeing’s für Avionik- und Cockpitfunktionen, die Motorsteuerungssoftware von Bosch’s für Benzinsysteme, die Druckersoftware von Hewlett Packard’s, die Stromerzeugungs- und Übertragungsausrüstung von Toshiba’s sowie die Steuerungssoftware für Antriebsstränge von General Motors’. Zu den Vorteilen von Software-Produktlinien (SPL) zählen laut Apel et al. (2013: 9) die Anpassung von Softwareprodukten an die spezifischen Bedürfnisse der Kunden, geringere Kosten – da sich eine Reihe wiederverwendbarer Ressourcen auf unterschiedliche Weise kombinieren lässt, um neue Produkte zu erzeugen –, eine höhere Qualität und eine kürzere Markteinführungszeit. Merkmale und merkmalsbasierte Modellierung sind wichtige Konzepte bei der Entwicklung von SPL. ISO/IEC/IEEE 24765:2010, Systems and software engineering — Vocabulary, bietet eine allgemeine Definition von Merkmalen, übernommen aus IEEE Std 829:2008 IEEE Standard for Software and System Test Documentation: „Ein unterscheidendes Merkmal eines Systemelements. HINWEIS: Dazu gehören sowohl funktionale als auch nichtfunktionale Attribute wie Leistung und Wiederverwendbarkeit.“ Kang und Lee (2013, 28) definieren Merkmale als „abstrakte Konzepte, die die Kommunikation zwischen verschiedenen Beteiligten einer Produktlinie wirksam unterstützen und es daher ermöglichen, Gemeinsamkeiten und Variabilität von Produktlinien auf natürliche und intuitive Weise anhand von Merkmalen auszudrücken.“ Merkmale erfüllen im Prozess der Produktkonzeption und -entwicklung verschiedene Zwecke. Sie dienen dazu, Produkteigenschaften zu kommunizieren und die Ermittlung von Anforderungen zu unterstützen; zugleich sind sie Konzepte, die Entwurfs- und Implementierungsentscheidungen leiten. Die Entwicklung einer Produktlinie umfasst zwei sich ergänzende Lebenszyklen: • Domänenentwicklung und • Anwendungsentwicklung. Der Standard IEEE 1517-2010 definiert Domänenentwicklung als: „Lebenszyklus, der aus einer Reihe von Prozessen zur Spezifizierung und Verwaltung der Gemeinsamkeiten und Variabilität einer Produktlinie besteht. Bei der Domänenentwicklung wird die Domäne einer Produktlinie analysiert und eine Reihe wiederverwendbarer Artefakte entwickelt. Zu diesen Artefakten gehören Softwareanforderungen, Entwurfselemente, Testfälle und 190 Ricardo Eito Brun Terminology as the Basis for Building Engineering Feature-based Models Verfahren, Benutzerdokumentation usw. Die Domänenanalyse kann als eine Art Anforderungstechnik für die gesamte Produktlinie betrachtet werden, einschließlich der Ermittlung der erwarteten Variabilität. Das wichtigste durch die Domänenanalyse erzeugte Artefakt ist das Feature-Modell, das die Produkte innerhalb der Produktlinie spezifiziert und beschreibt. Die Feature-Modellierung ist eine Diagrammtechnik, die in den neunziger Jahren mit der FODA-Methodik (Feature-Oriented Domain Analysis) eingeführt wurde. FODA stellte Grundelemente zur Darstellung struktureller Beziehungen (Komposition, Generalisierung und Spezialisierung), Optionalität, Alternativität und wechselseitiger Abhängigkeiten bereit. Später wurde sie von verschiedenen Autoren überarbeitet (Kang und Lee 2013: 30–31). Feature-Diagramme sind die visuelle Darstellung von Feature-Modellen, in denen Features als Kästen in einem hierarchischen Baum dargestellt werden. Jedem Knoten ist eine Beschriftung mit dem Namen des Features zugeordnet. Die hierarchische Anordnung der Features bildet Eltern-Kind-Beziehungen. Wird ein untergeordnetes Feature ausgewählt, muss auch sein übergeordnetes Feature ausgewählt werden. Diagramme können zwischen obligatorischen und optionalen Features unterscheiden und die gültigen Feature-Kombinationen kennzeichnen. Insbesondere können Feature-Diagramme Folgendes darstellen: Abstrakte Features, die zur Anordnung der Features im Baum dienen, jedoch keinen Implementierungsartefakten zugeordnet sind. Sie werden durch graue Kästen dargestellt. Konkrete Features, die Implementierungsartefakten entsprechen und durch weiße Kästen dargestellt werden. Obligatorische Features, die durch einen ausgefüllten Punkt oberhalb der oberen Kante ihres Kastens gekennzeichnet sind. Optionale Features, die durch einen nicht ausgefüllten Punkt oberhalb der oberen Kante ihres Kastens gekennzeichnet sind. Die Notwendigkeit, nur eines der untergeordneten Features eines bestimmten übergeordneten Features auszuwählen (exklusives ODER, XOR oder one-out-of-many). Dies wird durch einen leeren Bogen an der unteren Kante des Kastens des übergeordneten Features dargestellt. Die Möglichkeit, mehrere untergeordnete Features eines bestimmten übergeordneten Features auszuwählen (ODER oder some-out-of-many). Dies wird durch einen ausgefüllten Bogen an der unteren Kante des Kastens des übergeordneten Features dargestellt. Abhängigkeiten zwischen Features, dargestellt durch Pfeile mit textuellen Anmerkungen. Terminologija | 2020 | 27 191 Das nachstehende Diagramm zeigt ein typisches Feature-Diagramm mit den oben beschriebenen Konventionen: Abb. 1. Beispiel für die Darstellung eines Feature-Diagramms (Quelle: Gargantini 2015) Ein Feature-Modell sollte neben dem Diagramm weitere Informationen enthalten. Apel et al. (2013: 27) nennen die Möglichkeit, folgende Daten hinzuzufügen: „Beschreibung eines Features und der zugehörigen Anforderungen. Beziehung zu anderen Features, insbesondere Hierarchie, Reihenfolge und Gruppierung. Externe Abhängigkeiten, etwa erforderliche Hardwareressourcen. Interessierte Stakeholder. Geschätzte oder gemessene Kosten für die Umsetzung eines Features. Usw.“ Die Entwicklung eines Feature-Modells zur Darstellung der funktionalen Merkmale von Softwareanwendungen für die Satellitensteuerung muss von einem klaren Verständnis und einer Modellierung der Konzepte ausgehen, die den Fachbereich ausmachen. Zu diesem Zweck bilden Aktivitäten im Zusammenhang mit Terminologie und Terminografie sowie der Identifizierung von Termini, Konzepten und ihren Beziehungen die Grundlage für den Aufbau des Zielmodells. 192 Ricardo Eito Brun Terminology as the Basis for Building Engineering Feature-based Models 3. ARBEITSMETHODIK Das vorgeschlagene Feature-Modell wurde in den folgenden Schritten erstellt: Identifizierung und Prüfung der in diesem Bereich veröffentlichten Fach- und wissenschaftlichen Literatur. Dazu gehört die Suche nach Informationen über den in Luft- und Raumfahrtprojekten verfolgten Ansatz, die von Institutionen wie der ESA (European Space Agency) oder der NASA (National Aeronautics and Space Administration) geleitet werden. Erstellung eines auf der analysierten Literatur basierenden Glossars unter Anwendung von Terminologiemanagement-Techniken, um Informationen zu Begriffen, ihren Beziehungen untereinander, den in den Dokumenten ermittelten Definitionen und den Verwendungskontexten der Begriffe festzuhalten. Erstellung eines Feature-basierten Modells, das die von Softwareanwendungen zur Überwachung und Steuerung von Satelliten angebotenen Funktionen darstellt und das Glossar als Grundlage verwendet. Als Eingaben zur Identifizierung von Begriffen diente eine Auswahl technischer Dokumente, die das ausgewählte Produkt beschreiben: Betriebshandbücher, Whitepapers und Schulungsmaterialien. Das Feature-Modell ist ein hierarchischer Baum von Features, die als obligatorisch oder optional gekennzeichnet sind und untereinander Abhängigkeiten aufweisen. Im Fall der untersuchten Softwareanwendung wurden neben der Identifizierung optionaler und obligatorischer Features zusätzliche Anforderungen an die Variabilität der Produktlinie ermittelt. Insbesondere erfordern einige der von der untersuchten Software unterstützten Funktionen das Überschreiben oder Anpassen vorhandenen Codes. Die Ermittlung dieser Variabilitätsfälle erfolgte mit Unterstützung von Fachleuten, die in der Entwicklung und Anpassung dieser Art von Softwareanwendung tätig sind. Zur Erhebung dieser Informationen wurden persönliche Interviews geführt. Das zur Erstellung des Feature-Modells und der Diagramme ausgewählte Werkzeug ist FeatureIDE5. Es handelt sich um ein Open-Source-Werkzeug, das auf Java und Eclipse basiert und von Mitarbeitenden der Otto-von-Guericke-Universität Magdeburg entwickelt wurde. Mit FeatureIDE lässt sich mithilfe eines grafischen Editors ein Feature-Modell erstellen, in dem Features als obligatorisch, optional oder abstrakt gekennzeichnet und zu einem hierarchischen Baum angeordnet werden können. Sobald das Feature-Modell erstellt ist, lassen sich verschiedene Konfigurationen erstellen: Feature-Auswahlen, die zur Generierung der Zielsoftwareanwendung verwendet werden. 5 Siehe https://FeatureIDE.github.io/. Zuletzt geprüft: 01-03-2018. Terminologija | 2020 | 27 193 …ionsquellcode. Leider bietet das Tool keine Funktionen zur Verwaltung von Begriffen oder Terminologieeinheiten, sodass ergänzende Tools eingesetzt werden müssen. Abb. 2. FeatureIDE (vom Autor erstellt) 4. DARSTELLUNG DER ERGEBNISSE UND DISKUSSION Dieser Abschnitt fasst einen Teil des Feature-Modells für Softwareanwendungen von Missionskontrollsystemen (MCS) zusammen. Die Analyse der aus den Dokumenten extrahierten Konzepte führte zu einer Gliederung der Systemfunktionen in folgende Bereiche: Desktop- und Sitzungsverwaltung, die Funktionen zum Anmelden, Starten einer Sitzung und Starten der verschiedenen Anwendungen bereitstellt. Bei der Verwaltung mehrerer Satelliten kann der Benutzer zwischen den Arbeitsbereichen der Satelliten wechseln. Telemetrie-Verarbeitungskette, die Telemetrieverarbeitung, Alarmmanager und Telemetrieanzeige umfasst. 194 Ricardo Eito Brun Terminology as the Basis for Building Engineering Feature-based Models Telecommand-Verarbeitungskette, die Telecommand-Uplink, manuellen Stapel, geplanten Stapel und Telecommand-Verlauf umfasst. TT&C/TCR-Bridge, die Sichtbarkeit und Kontrolle über die Schnittstelle zur Bodenstation für Telemetrie-, Kommando-, Entfernungsmesstechnik-(TCR-) und Antennenausrichtungsdatenströme ermöglicht. Ereignisprotokoll, das während des Systembetriebs erkannte Ereignisse protokolliert und den Bedienern das Durchsuchen und Durchsehen des gesamten Ereignisverlaufs ermöglicht. Verwaltung des Bordspeichers, die Funktionen zur Verwaltung (Herunterladen, Bearbeiten und Hochladen) des Speicherabbilds des Raumfahrzeugs bereitstellt. Die Analyse der Dokumentation und der Begriffe führte zur Erstellung von Feature-Modellen für diese Systemfunktionen. Der besondere Fall der Telemetrieverwaltung wird beispielhaft zusammengefasst. Dabei wird deutlich, wie für die identifizierten Features Definitionen auf Grundlage bestehender Fachliteratur und technischer Dokumentation angegeben werden: Der Begriff Telemetrie-Verarbeitungskette bezeichnet die verschiedenen Prozesse der Telemetrieverarbeitung: Empfang über TT&C, Paketierung, Archivierung und Verteilung an Verbraucheranwendungen: Telemetriepaketierung. Das MCS übernimmt die Telemetrie-Quellpakete gemäß dem Telemetriepaketstandard, fügt Metadaten hinzu (z. B. die Qualität des Telemetriestroms) und wandelt sie in ein oder mehrere interne MCS-Telemetriepakete um. Die Kriterien für die Erzeugung von Paketen aus den eingehenden Daten können je nach Satellit, Mission und BBE-Protokollen variieren. Paketqualitätsprüfung. Das MCS prüft die Telemetriequalität kontinuierlich anhand von Prüfungen, die entweder vom TT&C oder vom MCS selbst durchgeführt werden. Jedem internen Paket werden Metadaten zur Telemetriequalität hinzugefügt. Je nach Ergebnis dieser Prüfungen kann das Paket als für die Verarbeitung geeignet (GOOD) oder ungeeignet (BAD) eingestuft werden. Auch Telemetrieausfälle müssen während des Prozesses erkannt werden. Eine typische Qualitätsprüfung ist die Rahmenfolgenprüfung, bei der festgestellt wird, ob die Rahmen in der richtigen Reihenfolge empfangen werden. Terminologija | 2020 | 27 195 Ereignisse werden ausgelöst, wenn diese Prüfungen nicht bestanden werden. Der Bediener kann das anzuwendende Verhalten auswählen, wenn fehlerhafte Telemetrie-Frames identifiziert werden (sie verarbeiten oder verwerfen). • Zeitqualitätsprüfungen. Diese Prüfungen verifizieren, ob die vom TT&C für jeden Telemetriestrom gemeldete Zeit und die lokalen Zeiten des MCS nicht zu weit auseinanderliegen. Die Differenz zwischen der aktuellen MCS-Zeit und dem Zeitstempel im Telemetrie-Frame (der von der Bodenstation beim Empfang des Frames gesetzt wird) liegt innerhalb eines konfigurierbaren Zeitfensters. Wenn diese Prüfungen fehlschlagen, werden Ereignismeldungen ausgelöst. Zeitqualitätsprüfungen erfordern die Zeitstempelung der Telemetriepakete. • Telemetrie-Dekommutierung, bei der Telemetrieparameter-Stichproben aus den Paketen extrahiert werden6. Dazu gehören die Parameterextraktion, die Bitdekodierung, die Kalibrierung, die Prüfung auf Werte außerhalb des zulässigen Bereichs, die Gültigkeitsprüfung und die Datierung der Parameter. ○ Telemetrieparameter-Extraktion lokalisiert und extrahiert die Rohwerte der Telemetrieparameter aus den Paketen. Rohwerte sind üblicherweise vorzeichenbehaftete oder vorzeichenlose Ganzzahlen oder Gleitkommazahlen. Bei fester Telemetrie ist dieser Prozess trivial, da alle erforderlichen Informationen zur Position des Parameters in der Satelliten-MIB verfügbar sind; bei programmierbarer Telemetrie ist er jedoch komplexer. ○ Bitdekodierung gewinnt den Rohwert aus dem im Telemetriepaket kodierten Wert. In einer typischen Situation stimmt der Rohwert mit dem im Paket kodierten Wert überein; es gibt jedoch Fälle, in denen eine bitbasierte (etwa Bitumkehrung oder Zweierkomplement) oder bytebasierte Transformation erforderlich ist. ○ Abgeleitete oder synthetische Parameter. Sie werden nicht von der Raumsonde erfasst, sondern am Boden algorithmisch abgeleitet, wobei erfasste Telemetrieparameter als Operanden dienen. Sie werden mithilfe von Formeln berechnet, die in Skriptsprachen geschrieben sind. Die Berechnung erfolgt vor der Kalibrierung, den Gültigkeitsprüfungen und der Datierung der Parameter. Eine besondere Art abgeleiteter Parameter sind hartcodierte abgeleitete Parameter (HCDP), die in Programmiersprachen niedriger Ebene geschrieben sind 6 Die Parameter können synchron (werden unmittelbar nach ihrer Abtastung an Bord per Telemetrie zur Erde übertragen) oder asynchron sein (werden nicht unmittelbar nach ihrer Abtastung an Bord per Telemetrie zur Erde übertragen, sondern zunächst im Speicher an Bord gespeichert und später zur Erde übertragen). Parameter werden üblicherweise pro Format einmal oder mehrmals abgetastet und kodiert, mit Ausnahme von unterkommutierten Parametern, die nicht in allen Formaten abgetastet und kodiert werden, und überkommutierten Parametern, die mehrfach abgetastet und kodiert werden. 196 Ricardo Eito Brun | Terminology as the Basis for Building Engineering Feature-based Models wie C++, Fortran oder C. Ihre Änderung erfordert eine Neukompilierung des Quellcodes. o Datierung von Telemetrieparametern versieht die Parameterabtastwerte mit einem Datum, indem die Zeit des Pakets verwendet wird, das sie enthält, und ein in der Satelliten-MIB angegebener Offset addiert wird. o Kontrolle auf Bereichsüberschreitung (OOR) prüft, ob der Rohwert eines Telemetrieparameters außerhalb des definierten Kalibrierungsbereichs liegt. Telemetrieparameter außerhalb des Bereichs werden mit der Kategorie OOR als ungültig gekennzeichnet. OOR dient dazu, die Gültigkeit des Telemetrieparameters zu beurteilen und erkennen zu lassen, ob sein Wert brauchbar oder bedeutungslos ist. Darüber hinaus müssen Parameter außerhalb des Bereichs angezeigt und von den Bedienern bestätigt werden. Zu den weiteren Bedingungen, unter denen ein Parameter für ungültig erklärt wird, gehören: Der Parameter ist abgelaufen oder – im Fall abgeleiteter Parameter – wurde anhand ungültiger Parameter berechnet. In jedem Fall müssen die Metadaten zur Ungültigkeit des Telemetrieparameters den Grund für diesen Status angeben. • Kalibrierung von Telemetrieparametern wandelt deren Rohwerte in eine menschenlesbare Form um (technische oder kalibrierte Werte mit den Einheiten, die der physikalischen Größe entsprechen). Die Kalibrierung kann mit verschiedenen Methoden erfolgen: o Numerische oder lineare diskrete Kalibrierung: Dabei wird eine lineare Interpolation anhand einer Kalibrierungskurve verwendet, die aus (X, Y)-Paaren besteht, wobei X für den Rohwert und Y für den technischen Wert steht. o Textuelle, digitale oder Statuskalibrierung: Dabei werden Textzeichenfolgen den Rohwertbereichen von Parametern zugeordnet. Textwerte können aus diskreten Werten oder einem Wertebereich abgeleitet werden. Ein einfaches Beispiel ist der ON-/OFF-Status der Bordgeräte, der anhand eines Ein-Bit-Parameters ermittelt werden kann, bei dem 0 OFF und 1 ON bedeutet. o Polynomielle Kalibrierung: Dabei wird ein Polynom bis zum fünften Grad verwendet, um Rohwerte in technische Werte umzuwandeln. Ohne näher auf die extrahierten Features einzugehen (es wird lediglich eine Teilmenge beschrieben, um zu zeigen, dass ihre Identifizierung fundierte Terminologiearbeit erfordert), stellt das folgende Diagramm die wichtigsten für diesen Funktionsbereich identifizierten Features dar: Terminologija | 2020 | 27 197 Abb. 3. TM-Verarbeitung – Merkmale Abb. 1: FeatureIDE (erstellt vom Autor) 5. SCHLUSSFOLGERUNGEN In diesem Beitrag wird die Entwicklung eines Merkmalsmodells für Satellitensteuerungssoftware beschrieben. Als Eingaben dienen technische Dokumente (Betriebshandbücher, Whitepaper und Schulungsmaterialien), die die Funktionen des untersuchten Systemtyps beschreiben. Der erste Schritt ist die 198 Ricardo Eito Brun Terminology as the Basis for Building Engineering Feature-based Models Identifizierung und Extraktion von Begriffen durch die Prüfung der Dokumente sowie die Ermittlung ihrer Definitionen anhand des jeweiligen Anwendungskontexts. Diese Begriffssammlung wird anschließend weiter analysiert, um Merkmale zu identifizieren, die nach funktionalen Kriterien in einem Merkmalsmodell und -diagramm angeordnet wurden. Dabei wurden zwölf Hauptkategorien unterschieden: Sitzungsverwaltung, Verwaltung der Bodenstationsverbindungen, Telemetrieverarbeitung, Anzeige von Telemetriedaten, Verarbeitung von Telekommandos, Missionsarchiv usw. Für jeden Funktionsbereich wurden die Beschreibung der Hauptkonzepte und die Merkmale, die ein Softwaresystem unterstützen muss, zusammengefasst und in mit dem Werkzeug FeatureIDE erstellten Merkmalsdiagrammen dargestellt. Die Definitionen und der Verwendungskontext bildeten außerdem die Grundlage für die Bestimmung der Beziehungen zwischen den Merkmalen und für die Identifizierung von Variabilitätsmöglichkeiten. Es wurden drei Hauptgründe für Variabilität ermittelt: Missionsspezifische Konfigurationsparameter, die gewöhnlich mithilfe öffentlich zugänglicher Konfigurationsdateien verwaltet werden. Auswahl optionaler Merkmale, abhängig vom Missionstyp: z. B. positionsbasierte Telekommandos, die für LEO-Satelliten zur Erdbeobachtung charakteristisch sind. Anpassung missionsspezifischer Dienste, die die in Telemetrie- und Telekommandostandards wie PUS definierten Basisdienste und -funktionen erweitern. Die Arbeit zeigt, dass terminologiebezogene Techniken eingesetzt werden müssen, um die Bedeutung von Begriffen zu sammeln, zu analysieren und zu dokumentieren sowie Beziehungen zu extrahieren, die später für unterschiedliche Zwecke genutzt werden können. Bei merkmalsbasierten Entwicklungsmodellen bilden Begriffe die Grundlage, um die Funktionen der Software und Systeme eindeutig zu beschreiben und die Merkmale komplexer Systeme zu identifizieren. Eine konsistente Verwendung der Begriffe ist zudem erforderlich, damit die verschiedenen an nachfolgenden Entwicklungsaufgaben (Entwurf, Implementierung, Test usw.) beteiligten Akteure ein gemeinsames Verständnis der Systemmerkmale haben und Fehler vermeiden, die durch eine unzureichende Definition des Anwendungsbereichs entstehen, den das System unterstützen soll. 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