Terminology as the Basis for Building Engineering Feature-based Models

doi.org/10.35321/term27-08 Terminologia jako podstawa budowania modeli inżynierskich opartych na cechach RICARDO EITO BRUN Universidad Carlos III de Madrid STRESZCZENIE Operacje satelitarne wymagają łącznego wykorzystania różnych narzędzi wspierających działania inżynierskie i sterowanie statkiem kosmicznym. Komunikacją tą zarządza System Monitorowania i Sterowania (MCS), który odbiera dane telemetryczne ze statku kosmicznego i wysyła telekomendy, aby utrzymać orientację satelity oraz jego trajektorię lotu. Te złożone systemy są rozwijane jako otwarte platformy, które można rozbudowywać i dostosowywać do wymagań i celów konkretnej misji. Ogólnie rzecz biorąc, można stwierdzić, że aplikacje te dobrze nadają się do wdrażania w uporządkowany i zaplanowany sposób mechanizmów zmienności, a ich funkcjonalność stanowi dobry przedmiot analizy wykonalności zastosowania technik modelowania opartego na cechach. W artykule opisano wykorzystanie analizy terminologicznej do zbudowania modelu cech wspierającego analizę wymagań dla tego rodzaju systemów opartych na oprogramowaniu. SŁOWA KLUCZOWE: terminologia techniczna, modele oparte na cechach, inżynieria lotnicza i kosmiczna, ekstrakcja terminologii ADNOTACJA Operacje satelitarne wymagają różnorodnych narzędzi, które zapewniają sprawną pracę inżynierską i umożliwiają sterowanie statkiem kosmicznym. Komunikacją tą zarządza System Monitorowania i Sterowania (SKS), który odbiera dane telemetryczne ze statku kosmicznego i wysyła telekomendy, aby utrzymać orientację satelity oraz jego trajektorię lotu. Te złożone systemy są tworzone jako otwarte platformy, które można rozbudowywać i dostosowywać do wymagań i celów konkretnej misji. Można stwierdzić, że aplikacje te z reguły nadają się do uporządkowanego i zaplanowanego wdrażania mechanizmów zmienności, a ich funkcjonalność pozwala analizować możliwości zastosowania metod modelowania opartego na cechach. W artykule opisano wykorzystanie analizy terminologicznej do stworzenia modelu cech wspierającego analizę wymagań dla tego typu systemów programowych. SŁOWA KLUCZOWE: terminologia techniczna, modele cech, inżynieria lotnicza i kosmiczna, rozpoznawanie terminów 186 Ricardo Eito Brun Terminology as the Basis for Building Engineering Feature-based Models 1. WPROWADZENIE Słownik NASA definiuje satelity jako: „swobodnie poruszający się obiekt, który krąży wokół Ziemi, innej planety lub Słońca.” Satelity są rodzajem statków kosmicznych poruszających się po regularnej, jasno określonej orbicie wokół środka ciężkości innego ciała niebieskiego (Garner 1996: 4). Od czasu wystrzelenia pierwszych sztucznych satelitów – Sputnik 1 4 październikath 1957 r. oraz Explorer 1 31 styczniast 1958 r. – wystrzelono wiele misji satelitarnych o różnych celach: eksploracji astronomicznej, świadczenia usług komunikacyjnych i nawigacyjnych, obserwacji Ziemi, rozpoznania oraz badań naukowych. Satelity to złożone systemy lotniczo-kosmiczne składające się z elementów naziemnych i kosmicznych: statkiem kosmicznym musi sterować element kontrolny na Ziemi, z którym musi on pozostawać w łączności. Obecnie postęp naukowy i usługi dla użytkowników zależą od satelitów i ich konstelacji. Istotne przykłady obejmują Kosmiczny Teleskop Hubble’a (HST), systemy nawigacyjne, takie jak GPS (Global Positioning System), GLONASS i europejski Galileo, UARS (Upper Atmosphere Research Satellite) czy GOES (Geostationary Operational Environment Satellite). Łączna liczba satelitów wystrzelonych od 1957 r. – według katalogu US SSN2 – wynosi niemal 18 200; Indeks obiektów wystrzelonych w przestrzeń kosmiczną z 2017 r. UNOOSA podaje, że obecnie wokół planety orbituje 4635 satelitów, co oznacza wzrost o 357 satelitów (8,95%) w porównaniu z poprzednim rokiem3. Celem niniejszego artykułu jest wykazanie potrzeby stosowania zarządzania terminologią i jej ekstrakcji w celu wspierania opracowywania modeli opartych na cechach, które porządkują pojęcia opisujące funkcje aplikacji programowych wykorzystywanych do monitorowania i kontroli satelitów. Satelity klasyfikuje się według przeznaczenia i rodzaju orbity. Przeznaczenie odnosi się do usług, które satelita ma świadczyć. Jeśli chodzi o orbitę, rozróżnia się niską orbitę okołoziemską (LEO), średnią orbitę okołoziemską (MEO) oraz orbitę geostacjonarną (GEO). Satelity LEO – wykorzystywane do badań naukowych i obserwacji Ziemi – poruszają się po orbicie eliptycznej; ponieważ ich widoczność ze stacji naziemnych jest ograniczona, dane są przechowywane na pokładzie i przesyłane na Ziemię 1 Zob. https://www.grc.nasa.gov/www/k-12/TRC/laefs/laefs_s.html#satellite [dostęp: 2020-08-01]. 2 US Space Surveillance Network odpowiada za wykrywanie, śledzenie, katalogowanie i identyfikację sztucznych obiektów orbitujących wokół Ziemi. Katalog jest dostępny pod adresem: https://www.space-track.org/#/ssr [dostęp: 2020-08-01]. 3 Biuro Narodów Zjednoczonych ds. Przestrzeni Kosmicznej. Zob. https://www.pixalytics.com/sats-orbiting-earth-2017/ Terminologija | 2020 | 27 187 stacji, gdy statek kosmiczny staje się widoczny. Satelity GEO są wykorzystywane do telekomunikacji i celów meteorologicznych; satelity telekomunikacyjne odbierają sygnały o częstotliwości radiowej (RF) z Ziemi, wzmacniają je, zmieniają ich częstotliwość, a następnie przesyłają z powrotem na Ziemię. Krążą 36 000 km nad równikiem (w tej samej płaszczyźnie), a ich obrót jest zsynchronizowany z obrotem Ziemi, dzięki czemu przez cały czas pozostają nad tym samym punktem na równiku)4. Podobnie jak satelity, naukowe misje w przestrzeni kosmicznej również wymagają monitorowania i kontroli na potrzeby wysyłania telekomend oraz odbioru telemetrii. Misje satelitarne wymagają zaangażowania wyspecjalizowanego personelu do prowadzenia ciągłego monitorowania w czasie rzeczywistym stanu i położenia satelity. Kontrola misji obejmuje zestaw zadań wykonywanych po wystrzeleniu przez inżynierów operacyjnych przy użyciu aplikacji programowych i wiąże się z wymianą danych między segmentem naziemnym a kosmicznym w celu monitorowania i kontrolowania stanu podsystemów pokładowych satelity. W misjach naukowych konieczne jest również odbieranie informacji z ładunku użytecznego satelity i przekazywanie ich użytkownikom końcowym (społeczności naukowej). Typowe funkcje realizowane podczas kontroli misji obejmują odbiór i analizę telemetrii, wysyłanie telekomend oraz śledzenie. Telemetria to dane przesyłane z satelity na Ziemię, informujące o stanie i warunkach pracy satelity oraz jego podsystemów. Telekomendy to polecenia przesyłane z Ziemi do statku kosmicznego w celu jego konfiguracji i obsługi. (Uhlig, Sellmaier, and Schmidhuber 2015: 232). Śledzenie i utrzymywanie pozycji na orbicie, znane również jako pomiar odległości, polega na monitorowaniu i określaniu toru lotu oraz położenia z wykorzystaniem technik i sygnałów RF. Z perspektywy inżynierii oprogramowania kontrola satelitów wymaga różnych aplikacji i narzędzi do dynamiki lotu, planowania misji, telemetrii i wysyłania telekomend, kontroli sieci i routingu, a także interfejsów między nimi. Ta złożoność skłoniła agencje kosmiczne do opracowania różnych rozwiązań. Jednym z najważniejszych kamieni milowych w rozwoju oprogramowania MCS była decyzja departamentu ESA Ground Systems Engineering o opracowaniu i licencjonowaniu dla europejskiego przemysłu zestawu aplikacji programowych dystrybuowanych pod nazwą MICONYS® 4 Satelity GEO rozmieszczone są na ograniczonym obszarze przestrzeni kosmicznej. Pozycje orbitalne przydziela Międzynarodowy Związek Telekomunikacyjny (ITU), aby uniknąć kolizji — ryzyka związanego z problemem śmieci kosmicznych, któremu poświęca się obecnie coraz większą uwagę. 188 Ricardo Eito Brun │ Terminology as the Basis for Building Engineering Feature-based Models (System Kontroli Misji). MICONYS i jego komponent SCOS-2000® są prawdopodobnie najbardziej znanymi przykładami realizacji polityki ESA w zakresie rozwoju oprogramowania, innowacji oraz transferu technologii (Kaufeler, Jones and Karl 2001). SCOS-2000 obsługuje wysyłanie telekomend, odbiór telemetrii, wyświetlanie i archiwizację. SCOS-2000 powstał w oparciu o doświadczenia zdobyte przez ESA podczas opracowywania i eksploatacji wcześniejszych podobnych systemów: MSSS, SCOS-1 i SCOS-2. Obecnie ESA opracowuje nowy system MCS, który ma w przyszłości zastąpić SCOS-2000. Nosi on nazwę Europejski System Naziemny – Wspólny Rdzeń (EGS-CC). Podobnie jak SCOS, projekt ma na celu opracowanie wspólnej infrastruktury wspierającej monitorowanie i kontrolę misji kosmicznych w fazach przed startem i po starcie, z wykorzystaniem nowoczesnych technologii i architektur zorientowanych na usługi (Peccioli et al. 2012). Za rozwój EGS-CC odpowiada nie tylko ESA: w projekcie uczestniczą europejskie krajowe agencje kosmiczne (CNES, UK Space Agency i DLR) oraz przedsiębiorstwa przemysłowe (AIRBUS Defence and Space, Thales Alenia Space oraz OHB Systems). Oprócz projektów ESA istnieją inne inicjatywy mające na celu opracowanie uniwersalnego systemu oprogramowania MCS. NASA zrealizowała podobne projekty, z których większość opracowano we własnym zakresie. Goddard Space Flight Centre opracowało dwa systemy, ITOS i ASIST, do zarządzania misjami takimi jak 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) lub LRO (Lunar Reconnaissance Orbiter) (Pfarr et al. 2007). We wszystkich tych przypadkach mamy do czynienia ze złożonym systemem, który musi realizować różne funkcje, możliwe do włączenia lub wyłączenia w zależności od charakterystyki satelity i misji. Z tego względu te systemy, w których oprogramowanie odgrywa kluczową rolę, są dobrymi kandydatami do opracowywania z wykorzystaniem podejścia linii produktów oraz technik modelowania opartego na cechach, które opierają się na jasnym i dobrze uporządkowanym układzie pojęć, pozwalającym zrozumieć dziedzinę i wymagane możliwości systemu. 2. MODELOWANIE OPARTE NA CECHACH JAKO UPORZĄDKOWANIE POJĘĆ Modelowanie oparte na cechach jest jedną z technik stosowanych w inżynierii linii produktów oprogramowania — dziedzinie zajmującej się tworzeniem wielokrotnego użytku programów, która zyskała popularność pod koniec lat dziewięćdziesiątych. SPLE ma na celu Terminologija | 2020 | 27 189 tworzenie wielokrotnego użytku komponentów i artefaktów, które można następnie łączyć, aby budować produkty dostosowane do potrzeb konkretnego klienta i kontekstu. Doświadczenia związane z SPLE są szeroko opisywane w literaturze branżowej i naukowej. Capilla (2013) przedstawił kilka studiów przypadków, w których z powodzeniem zastosowano SPLE: programy operacyjne i krytyczne dla misji firmy Boeing dla systemów awionicznych i funkcji kokpitu, oprogramowanie sterujące silnikiem w systemach benzynowych firmy Bosch, oprogramowanie do drukarek firmy Hewlett Packard, urządzenia do wytwarzania i przesyłu energii firmy Toshiba oraz oprogramowanie sterujące układami napędowymi firmy General Motors. Korzyści płynące z linii produktów oprogramowania (SPL), według Apel et al. (2013: 9), obejmują dostosowanie produktów programowych do konkretnych potrzeb klientów, obniżenie kosztów — ponieważ zestaw wielokrotnego użytku zasobów można łączyć na różne sposoby, aby tworzyć nowe produkty — poprawę jakości oraz skrócenie czasu wprowadzenia produktu na rynek. Cechy i modelowanie oparte na cechach są istotnymi pojęciami w rozwoju SPL. Norma ISO/IEC/IEEE 24765:2010, Systems and software engineering — Vocabulary, podaje ogólną definicję cech, zaczerpniętą z normy IEEE Std 829:2008 IEEE Standard for Software and System Test Documentation: „Cecha wyróżniająca element systemu. UWAGA: obejmuje zarówno atrybuty funkcjonalne, jak i niefunkcjonalne, takie jak wydajność i możliwość ponownego wykorzystania.” Kang and Lee (2013, 28) definiują cechy jako „abstrakcyjne pojęcia skutecznie wspierające komunikację między różnymi interesariuszami linii produktów, dlatego naturalne i intuicyjne jest wyrażanie wspólności i zmienności linii produktów za pomocą cech.” Cechy pełnią różne funkcje w procesie tworzenia koncepcji produktu i jego rozwoju. Służą do komunikowania charakterystyki produktu i wspierają identyfikację wymagań; są również pojęciami, które wyznaczają kierunek decyzji dotyczących projektowania i implementacji. Rozwój linii produktów obejmuje dwa uzupełniające się cykle życia: • Inżynieria dziedzinowa oraz • Inżynieria aplikacji. Norma IEEE 1517-2010 definiuje inżynierię dziedzinową jako: „Cykl życia obejmujący zestaw procesów służących do określania i zarządzania wspólnością oraz zmiennością linii produktów. Inżynieria dziedzinowa analizuje dziedzinę linii produktów i opracowuje zestaw artefaktów wielokrotnego użytku. Artefakty te obejmują wymagania dotyczące oprogramowania, elementy projektu, przypadki testowe oraz 190 Ricardo Eito Brun Terminology as the Basis for Building Engineering Feature-based Models procedury, dokumentacja użytkownika itp. Analizę dziedziny można postrzegać jako rodzaj inżynierii wymagań dla całej linii produktów, obejmującej identyfikację przewidywanej zmienności. Głównym artefaktem powstającym w wyniku analizy dziedziny jest model cech, który będzie określać i opisywać produkty należące do linii. Modelowanie cech to technika diagramowa wprowadzona w latach dziewięćdziesiątych wraz z metodologią FODA (analiza dziedziny zorientowana na cechy). FODA dostarczyła prymitywów do przedstawiania relacji strukturalnych (kompozycji, uogólnienia i specjalizacji), opcjonalności, alternatywności oraz wzajemnych zależności. Później została poddana przeglądowi przez różnych autorów (Kang i Lee 2013: 30–31). Diagramy cech są wizualną reprezentacją modeli cech, w których cechy przedstawia się jako pola w hierarchicznym drzewie. Każdy węzeł ma dołączoną etykietę z nazwą cechy. Hierarchiczne rozmieszczenie cech tworzy relacje rodzic–dziecko. Jeśli zostanie wybrana cecha potomna, należy również wybrać jej cechę nadrzędną. Diagramy mogą rozróżniać cechy obowiązkowe i opcjonalne oraz wskazywać poprawne kombinacje cech. W szczególności diagramy cech mogą przedstawiać: Cechy abstrakcyjne, używane do porządkowania cech w drzewie, ale niepowiązane z artefaktami implementacyjnymi. Przedstawia się je za pomocą szarych pól. Cechy konkretne, które odpowiadają artefaktom implementacyjnym i są przedstawiane za pomocą białych pól. Cechy obowiązkowe, oznaczone wypełnionym punktem nad górną krawędzią pola. Cechy opcjonalne, oznaczone niewypełnionym punktem nad górną krawędzią pola. Konieczność wybrania tylko jednej z cech potomnych określonej cechy nadrzędnej (wyłączne LUB, XOR lub jedna z wielu). Przedstawia się ją za pomocą pustego łuku przy dolnej krawędzi pola cechy nadrzędnej. Możliwość wybrania więcej niż jednej cechy potomnej określonej cechy nadrzędnej (LUB lub niektóre z wielu). Przedstawia się ją za pomocą wypełnionego łuku przy dolnej krawędzi pola cechy nadrzędnej. Zależności między cechami, przedstawione za pomocą strzałek z adnotacjami tekstowymi. Terminologija | 2020 | 27 191 Poniższy diagram przedstawia typowy diagram cech z konwencjami opisanymi powyżej: Rys. 1. Przykład diagramu cech (Źródło: Gargantini 2015) Model cech powinien zawierać dodatkowe informacje oprócz tych przedstawionych na diagramie. Apel et al. (2013: 27) wskazują możliwość dodania następujących danych: „Opis cechy i odpowiadającego jej zbioru wymagań. Powiązania z innymi cechami, zwłaszcza hierarchia, kolejność i grupowanie. Zależności zewnętrzne, takie jak wymagane zasoby sprzętowe. Zainteresowane strony. Szacowany lub zmierzony koszt realizacji cechy. Itp.” Opracowanie modelu cech reprezentującego charakterystyki funkcjonalne aplikacji programowych do sterowania satelitami należy rozpocząć od jasnego zrozumienia i modelowania pojęć składających się na daną dziedzinę. W tym celu działania związane z terminologią i terminografią, identyfikacją terminów, pojęć oraz relacji między nimi stanowią podstawę do zbudowania modelu docelowego. 192 Ricardo Eito Brun Terminology as the Basis for Building Engineering Feature-based Models 3. METODYKA PRACY Proponowany model cech opracowano, postępując zgodnie z następującymi etapami: Identyfikacja i przegląd literatury fachowej i akademickiej opublikowanej w tym obszarze. Obejmuje to wyszukiwanie informacji o podejściu stosowanym w projektach lotniczo-kosmicznych prowadzonych przez podmioty takie jak ESA (European Space Agency) lub NASA (National Aeronautics and Space Administration). Opracowanie glosariusza na podstawie analizowanej literatury, z zastosowaniem technik zarządzania terminologią w celu rejestrowania informacji o terminach, relacjach między nimi, definicjach zidentyfikowanych w dokumentach oraz kontekście, w którym terminy są używane. Utworzenie modelu opartego na cechach, który przedstawia funkcje oferowane przez aplikacje do monitorowania i sterowania satelitami, wykorzystując glosariusz jako podstawę. Dane wejściowe wykorzystane do identyfikacji terminów obejmowały podzbiór dokumentów technicznych opisujących wybrany produkt: instrukcje obsługi, dokumenty typu white paper oraz materiały szkoleniowe. Model cech jest hierarchicznym drzewem cech oznaczonych jako obowiązkowe lub opcjonalne, z określonymi między nimi zależnościami. W przypadku analizowanej aplikacji, poza identyfikacją cech opcjonalnych i obowiązkowych, określono dodatkowe wymagania dotyczące zmienności linii produktów programowych. W szczególności niektóre funkcje obsługiwane przez analizowane oprogramowanie wymagają nadpisania lub dostosowania istniejącego kodu. Przypadki zmienności zidentyfikowano przy wsparciu ekspertów zajmujących się opracowywaniem i dostosowywaniem tego typu aplikacji. Informacje te zebrano podczas wywiadów indywidualnych. Narzędziem wybranym do utworzenia modelu cech i diagramów jest FeatureIDE5. Jest to narzędzie open source oparte na Javie i Eclipse, opracowane przez pracowników Otto-von-Guericke-Universität Magdeburg. Za pomocą FeatureIDE można utworzyć model cech w edytorze graficznym, oznaczyć cechy jako obowiązkowe, opcjonalne lub abstrakcyjne oraz zbudować hierarchiczne drzewo. Po utworzeniu modelu cech można utworzyć różne konfiguracje: wybory cech, które zostaną wykorzystane do wygenerowania docelowej aplikacji programowej 5 Zob. https://FeatureIDE.github.io/. Ostatnie sprawdzenie: 01-03-2018. Terminologija | 2020 | 27 193 kod źródłowy. Niestety narzędzie nie udostępnia funkcji zarządzania terminami ani jednostkami terminologicznymi, co sprawia, że konieczne jest korzystanie z narzędzi uzupełniających. Rys. 2. FeatureIDE (opracowany przez autora) 4. PREZENTACJA WYNIKÓW I DYSKUSJA W tej sekcji podsumowano część modelu cech dotyczącą aplikacji programowych systemów kontroli misji (MCS). Analiza pojęć wyodrębnionych z dokumentów doprowadziła do podziału funkcjonalności systemu na następujące obszary: Zarządzanie pulpitem i sesjami, które udostępnia funkcje logowania, rozpoczynania sesji i uruchamiania różnych aplikacji. W przypadku zarządzania wieloma satelitami użytkownik może przełączać się między obszarami roboczymi poszczególnych satelitów. Łańcuch telemetrii, obejmujący przetwarzanie telemetrii, menedżera alarmów i wyświetlanie telemetrii. 194 Ricardo Eito Brun Terminology as the Basis for Building Engineering Feature-based Models Łańcuch telekomend, obejmujący łącze uplink telekomend, stos ręczny, stos zaplanowany i historię telekomend. Most TT&C/TCR, który zapewnia podgląd interfejsu ze stacją naziemną i umożliwia sterowanie przepływami danych telemetrycznych, komend, pomiarów odległości (TCR) oraz wskazywania anteny. Dziennik zdarzeń, który rejestruje zdarzenia wykryte podczas działania systemu i umożliwia operatorom przeglądanie oraz wyszukiwanie pełnej historii zdarzeń. Zarządzanie pamięcią pokładową, które udostępnia funkcje zarządzania obrazem pamięci statku kosmicznego (pobieranie, edycję i wysyłanie łączem uplink). Analiza dokumentacji i terminów doprowadziła do utworzenia modeli cech dla tych funkcji systemu. Jako przykład podsumowano szczególny przypadek zarządzania telemetrią. Można zauważyć, że dla zidentyfikowanych cech podano definicje oparte na istniejącej literaturze i dokumentacji technicznej: Termin łańcuch telemetrii odnosi się do różnych procesów związanych z przetwarzaniem telemetrii: odbioru z systemu TT&C, pakietyzacji, archiwizacji i dystrybucji do aplikacji odbiorczych: Pakietyzacja telemetrii. MCS pobiera źródłowe pakiety telemetryczne zgodne ze standardem pakietów telemetrycznych, dodaje metadane (np. jakość strumienia telemetrycznego) i przekształca je w jeden lub więcej wewnętrznych pakietów telemetrycznych MCS. Kryteria generowania pakietów z danych wejściowych mogą się różnić w zależności od satelity, misji i protokołów BBE. Kontrola jakości pakietów. MCS stale kontroluje jakość telemetrii, wykonując kontrole realizowane przez TT&C lub sam system MCS. Metadane dotyczące jakości telemetrii są dołączane do każdego pakietu wewnętrznego. W zależności od wyniku tych kontroli pakiet może zostać sklasyfikowany jako nadający się do przetwarzania (GOOD) albo nienadający się do przetwarzania (BAD). W trakcie tego procesu należy również wykrywać utratę pakietów telemetrycznych. Typową kontrolą jakości jest kontrola kolejności ramek, która ocenia, czy ramki są odbierane w odpowiedniej kolejności. Terminologija | 2020 | 27 195 Zdarzenia są generowane, gdy te kontrole nie zostaną spełnione. Operator może wybrać sposób postępowania w przypadku wykrycia ramek telemetrycznych BAD (przetworzyć je lub odrzucić). • Kontrole jakości czasu. Kontrole te sprawdzają, czy czas podawany przez TT&C dla każdego strumienia telemetrycznego oraz lokalny czas MCS nie różnią się zbytnio. Różnica między bieżącym czasem MCS a znacznikiem czasu w ramce telemetrycznej (ustawianym przez stację naziemną po odebraniu ramki) mieści się w konfigurowalnym przedziale czasu. W przypadku niepowodzenia tych kontroli generowane są komunikaty o zdarzeniach. Kontrole jakości czasu wymagają opatrywania pakietów telemetrycznych znacznikami czasu. • Dekapsulacja telemetryczna, która wydobywa próbki parametrów telemetrycznych z pakietów6. Obejmuje ona ekstrakcję parametrów, dekodowanie bitów, kalibrację, sprawdzanie zakresu, sprawdzanie poprawności oraz datowanie parametrów. ○ Ekstrakcja parametrów telemetrycznych lokalizuje i wydobywa z pakietów surowe wartości parametrów telemetrycznych. Surowe wartości są zwykle liczbami całkowitymi ze znakiem lub bez znaku albo liczbami zmiennoprzecinkowymi. W przypadku telemetrii stałej proces ten jest trywialny, ponieważ wszystkie wymagane informacje o lokalizacji parametru są dostępne w MIB satelity, natomiast w przypadku telemetrii programowalnej jest bardziej złożony. ○ Dekodowanie bitów pozwala uzyskać surową wartość z wartości zakodowanej w pakiecie telemetrycznym. W typowej sytuacji surowa wartość odpowiada wartości zakodowanej w pakiecie, jednak w niektórych przypadkach konieczne są transformacje bitowe (takie jak odwrócenie bitów lub kodowanie uzupełnień do dwóch) albo transformacje bajtowe. ○ Parametry pochodne lub syntetyczne. Nie są one pozyskiwane ze statku kosmicznego, lecz obliczane algorytmicznie na Ziemi, z wykorzystaniem pozyskanych parametrów telemetrycznych jako operandów. Oblicza się je za pomocą formuł zapisanych w językach skryptowych. Są obliczane przed kalibracją, kontrolą poprawności i datowaniem parametrów. Szczególnym rodzajem parametru pochodnego są zakodowane na stałe parametry pochodne (HCDP), zapisywane w językach programowania niskiego poziomu 6 Parametry mogą być synchroniczne (przesyłane w dół w telemetrii zaraz po próbkowaniu na pokładzie) lub asynchroniczne (nieprzesyłane w dół w telemetrii zaraz po próbkowaniu na pokładzie, lecz przechowywane w pamięci pokładowej i przesyłane później). Parametry są zwykle próbkowane i kodowane raz lub kilka razy w każdym formacie; wyjątek stanowią parametry subkomutowane, które nie są próbkowane ani kodowane we wszystkich formatach, oraz parametry superkomutowane, które są próbkowane i kodowane wielokrotnie. 196 Ricardo Eito Brun | Terminology as the Basis for Building Engineering Feature-based Models takich jak C++, Fortran czy C. Ich modyfikacja wymaga ponownej kompilacji kodu źródłowego. o Datowanie parametru telemetrycznego przypisuje próbkom parametru datę, wykorzystując czas pakietu, który je zawiera, i dodając przesunięcie określone w MIB satelity. o Kontrola wartości poza zakresem (OOR) sprawdza, czy surowa wartość parametru telemetrycznego wykracza poza zdefiniowany zakres kalibracji. Parametry telemetryczne poza zakresem uznaje się za nieprawidłowe i oznacza kategorią OOR. OOR służy do oceny prawidłowości parametru telemetrycznego oraz do określenia, czy jego wartość jest użyteczna, czy pozbawiona znaczenia. Ponadto parametry o wartościach poza zakresem muszą być wyświetlane i potwierdzane przez operatorów. Inne warunki uznania parametru za nieprawidłowy obejmują jego wygaśnięcie lub — w przypadku parametrów pochodnych — obliczenie go z użyciem nieprawidłowych parametrów. Niezależnie od przypadku metadane o nieprawidłowości parametru telemetrycznego powinny szczegółowo określać przyczynę tego stanu. • Kalibracja parametrów telemetrycznych przekształca ich surowe wartości w postać czytelną dla człowieka (wartości inżynierskie lub skalibrowane wraz z jednostkami odpowiadającymi wielkości fizycznej). Kalibrację można przeprowadzać różnymi metodami: o Kalibracja numeryczna lub liniowa dyskretna: wykorzystuje się interpolację liniową na podstawie krzywej kalibracyjnej złożonej z par (X, Y), gdzie X oznacza wartość surową, a Y — wartość inżynierską. o Kalibracja tekstowa, cyfrowa lub stanowa: przypisuje ciągi tekstowe do zakresów surowych wartości parametrów. Wartości tekstowe można uzyskać dla wartości dyskretnych lub ich zakresu. Prostym przykładem jest stan ON / OFF jednostek pokładowych, który można uzyskać z parametru jednobitowego, gdzie 0 oznacza OFF, a 1 — ON. o Kalibracja wielomianowa: wykorzystuje wielomian stopnia nie wyższego niż piąty do przekształcania wartości surowych w wartości inżynierskie. Nie omawiając szczegółowo wyodrębnionych cech (przedstawiono jedynie ich podzbiór, aby pokazać, że ich identyfikacja wymaga rzetelnej analizy terminologicznej), na kolejnym diagramie przedstawiono główne cechy zidentyfikowane dla tego obszaru funkcjonalnego: Terminologija | 2020 | 27 197 Rys. 3. Przetwarzanie TM – cechy Rys. 1: FeatureIDE (opracowanie autora) 5. WNIOSKI W artykule opisano opracowanie modelu cech dla aplikacji programowych do sterowania satelitami, wykorzystując jako dane wejściowe dokumenty techniczne (instrukcje obsługi, dokumenty informacyjne i materiały szkoleniowe) opisujące funkcjonalności badanego rodzaju systemu. Pierwszym krokiem jest 198 Ricardo Eito Brun Terminology as the Basis for Building Engineering Feature-based Models identyfikacja i ekstrakcja terminów poprzez analizę dokumentów oraz określenie ich definicji na podstawie kontekstu, w którym są stosowane. Zbiór tych terminów poddaje się dalszej analizie w celu identyfikacji cech, które następnie uporządkowano w modelu cech i na diagramie według kryteriów funkcjonalnych, w ramach dwunastu głównych kategorii: zarządzanie sesjami, zarządzanie połączeniem ze stacją naziemną, przetwarzanie telemetrii, wyświetlanie danych telemetrycznych, przetwarzanie telekomend, archiwum misji itd. Dla każdego obszaru funkcjonalnego podsumowano opis głównych pojęć i cech, które musi obsługiwać system programowy, a następnie przedstawiono je na diagramach cech utworzonych za pomocą narzędzia FeatureIDE. Definicje i kontekst użycia stanowiły również podstawę do określenia relacji między cechami oraz zidentyfikowania możliwości wprowadzania zmienności. Zidentyfikowano trzy główne przyczyny zmienności: Parametry konfiguracyjne specyficzne dla misji, zwykle zarządzane za pomocą publicznie dostępnych plików konfiguracyjnych. Wybór cech opcjonalnych, zależny od rodzaju misji: np. telekomendy oparte na pozycji, charakterystyczne dla satelitów LEO służących do obserwacji Ziemi. Dostosowywanie usług specyficznych dla misji, które rozszerzają podstawowe usługi i funkcje określone w standardach telemetrii i telekomend, takich jak PUS. Praca pokazuje, że należy stosować techniki terminologiczne do gromadzenia, analizowania i dokumentowania znaczeń terminów oraz wydobywania relacji, które można później wykorzystać do różnych celów. W przypadku modeli inżynierii opartej na cechach terminy stanowią podstawę jednoznacznego opisu funkcji oprogramowania i systemów oraz identyfikowania właściwości systemów złożonych. Spójność użycia terminów jest również niezbędna, aby różni uczestnicy kolejnych zadań inżynierskich (projektowania, implementacji, testowania itp.) mieli wspólne rozumienie cech systemu, co pozwala unikać błędów wynikających z niewłaściwego zdefiniowania obszaru dziedzinowego, który system ma obsługiwać. 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