doi.org/10.35321/term27-08

A terminológia mint a mérnöki jellemzőalapú modellek építésének alapja

RICARDO EITO BRUN

Universidad Carlos III de Madrid

ÖSSZEFOGLALÓ

A műholdak üzemeltetéséhez különböző eszközök együttes alkalmazására van szükség a mérnöki tevékenységek támogatása és az űreszköz irányítása érdekében. Ezt a kommunikációt a Felügyeleti és Irányítási Rendszer (MCS) kezeli, amely telemetriai adatokat fogad az űreszközről, és távvezérlő parancsokat ad ki a műhold helyzetének és repülési pályájának fenntartásához. Ezeket az összetett rendszereket nyílt platformokként fejlesztik, amelyek a küldetésspecifikus követelmények és célok támogatása érdekében bővíthetők és testre szabhatók. Általánosságban elmondható, hogy ezek a szoftveralkalmazások alkalmasak arra, hogy strukturált, tervezett módon variabilitási mechanizmusokat valósítsanak meg bennük, funkcionalitásuk pedig megfelelő alapot nyújt a jellemzőalapú modellezési technikák alkalmazhatóságának elemzéséhez. Ez a tanulmány a terminológiai elemzés alkalmazását mutatja be egy jellemzőmodell létrehozására, amely támogatja az ilyen típusú szoftveres rendszerek követelményelemzését.

KULCSSZAVAK: műszaki terminológia, jellemzőalapú modellek, repülőgépipari mérnöki tudományok, terminuskivonás

ABSZTRAKTUM

A műholdak üzemeltetéséhez különféle eszközökre van szükség a zökkenőmentes mérnöki munka biztosításához és az űreszköz irányításához. Ezt a kapcsolatot a Felügyeleti és Irányítási Rendszer (SKS) kezeli, amely telemetriai adatokat fogad az űreszközről, és távvezérlő parancsokat ad ki a műhold helyzetének és repülési pályájának fenntartása érdekében. Ezeket az összetett rendszereket nyílt platformokként hozták létre, amelyek az adott küldetés követelményeihez és céljaihoz igazodva bővíthetők és testre szabhatók. Általánosságban elmondható, hogy ezek az alkalmazások alkalmasak a variabilitási mechanizmusok strukturált és tervezett bevezetésére, funkcionalitásuk pedig lehetővé teszi a jellemzőmodellezési módszerek alkalmazhatóságának elemzését. A cikk bemutatja, hogyan használható a terminológiai elemzés olyan jellemzőmodell létrehozására, amely támogatja az ilyen típusú szoftverrendszerek követelményelemzését.

KULCSSZAVAK: műszaki terminológia, jellemzőmodellek, repülőgépipari mérnöki tudományok, terminusfelismerés

186

Ricardo Eito Brun

Terminology as the Basis for Building Engineering Feature-based Models

1. BEVEZETÉS

A NASA szójegyzéke a műholdakat a következőképpen határozza meg: „szabadon repülő objektum, amely a Föld, egy másik bolygó vagy a Nap körül kering.” A műhold olyan űreszköz, amely szabályos, egyértelműen meghatározott pályán kering egy másik égitest tömegközéppontja körül (Garner 1996: 4). Az első mesterséges műholdak – a Sputnik 1 1957. október 4-i és az Explorer 1 1958. január 31-i felbocsátása óta^thst – számos, különböző célú műholdküldetést indítottak: csillagászati kutatást, kommunikációs és navigációs szolgáltatásokat, Föld-megfigyelést, felderítést és tudományos küldetéseket. A műholdak összetett űrtechnikai rendszerek, amelyek földi és űrbeli elemekből állnak: az űreszközt egy földi irányítóegységnek kell üzemeltetnie, és folyamatos kapcsolatban kell maradnia vele. Napjainkban a tudományos fejlődés és a felhasználóknak nyújtott szolgáltatások a műholdaktól és a műhold-konstellációktól függenek. Jelentős példák a Hubble űrteleszkóp (HST), az olyan navigációs rendszerek, mint a GPS (Global Positioning System), a GLONASS és az európai Galileo, az UARS (Upper Atmosphere Research Satellite), valamint a GOES (Geostationary Operational Environment Satellite). Az 1957 óta felbocsátott műholdak száma az amerikai SSN² katalógusa szerint megközelíti a 18 200-at; az UNOOSA 2017 Index of Objects Launched into Outer Space jelentése szerint jelenleg 4635 műhold kering a bolygó körül, ami az előző évhez képest 357 műholddal (8,95%-kal) több³. A cikk célja annak bemutatása, hogy a terminológiamenedzsment és a terminuskinyerés alkalmazásával miként támogatható a műholdak felügyeletére és irányítására használt szoftveralkalmazások funkcióit leíró fogalmak rendszerezését szolgáló, jellemzőalapú modellek kidolgozása.

A műholdakat rendeltetésük és pályatípusuk szerint osztályozzák. Rendeltetésük azokra a szolgáltatásokra utal, amelyek nyújtására a műholdat szánták. A pályát tekintve megkülönböztetünk alacsony Föld körüli pályát (LEO), közepes Föld körüli pályát (MEO) és geostacionárius pályát (GEO). A tudományos célokra és Föld-megfigyelésre használt LEO-műholdak elliptikus pályán keringenek; mivel a földi állomásokról csak korlátozottan láthatók, az adatokat a fedélzeten tárolják, majd továbbítják a földre

¹ Lásd: https://www.grc.nasa.gov/www/k-12/TRC/laefs/laefs_s.html#satellite [megtekintve: 2020-08-01].

² Az US Space Surveillance Network feladata a Föld körül keringő mesterséges objektumok észlelése, követése, nyilvántartásba vétele és azonosítása. A katalógus a következő címen érhető el: https://www.space-track.org/#/ssr [megtekintve: 2020-08-01].

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

Terminologija | 2020 | 27

187

azokon az állomásokon, amikor az űreszköz láthatóvá válik. A GEO-műholdakat távközlési és meteorológiai célokra használják; a távközlési műholdak rádiófrekvenciás (RF) jeleket fogadnak a Földről, felerősítik és frekvenciájukat átalakítják, majd visszasugározzák a Földre. Az Egyenlítő fölött 36 000 km magasan keringenek (ugyanabban a síkban), és forgásuk szinkronban van a Föld forgásával, így folyamatosan az Egyenlítő ugyanazon pontja fölött maradnak)⁴. A műholdakhoz hasonlóan a mélyűri tudományos küldetések esetében is szükség van a teleparancsok küldését és a telemetria vételét szolgáló felügyeletre és irányításra.

A műholdküldetésekhez külön személyzet szükséges a műhold állapotának és helyzetének valós idejű, folyamatos felügyeletéhez. A küldetésirányítás a felbocsátás után az üzemeltető mérnökök által, szoftveralkalmazások segítségével végrehajtott feladatok összessége; a földi és az űrszegmens közötti adatcserét foglalja magában a műhold fedélzeti alrendszerei állapotának felügyelete és irányítása érdekében. Tudományos küldetések esetén a műhold hasznos terhétől érkező információkat is fogadni kell, majd el kell juttatni a végfelhasználókhoz (a tudományos közösséghez). A küldetésirányítás során végrehajtott tipikus funkciók közé tartozik a telemetria vétele és elemzése, a teleparancsok küldése és a követés. A telemetria a műholdról a Földre továbbított adat, amely tájékoztat a műhold és alrendszerei állapotáról és működési körülményeiről. A teleparancsok a földről az űreszköznek küldött utasítások annak konfigurálására és működtetésére. (Uhlig, Sellmaier, and Schmidhuber 2015: 232). A követés és az állomástartás, más néven távolságmérés, a repülési pálya és a helyzet RF-technikák és -jelek segítségével történő megfigyeléséből és meghatározásából áll.

Szoftverfejlesztési szempontból a műholdirányításhoz különféle alkalmazásokra és eszközökre van szükség a repülésdinamika, a küldetéstervezés, a telemetria és a teleparancsok kezelése, a hálózatirányítás és az útválasztás területén, valamint az ezek közötti interfészekhez. Ez az összetettség arra késztette az űrügynökségeket, hogy különféle megoldásokat kínáljanak. Az MCS-szoftver fejlesztésének egyik legjelentősebb mérföldköve az ESA Ground Systems Engineering részlegének döntése volt, hogy a MICONYS^® néven forgalmazott szoftveralkalmazás-csomagot fejleszt és licencel az európai ipar számára.

⁴ A GEO-műholdak az űr egy korlátozott területén helyezkednek el. Az ütközések elkerülése érdekében a pályapozíciókat a International Telecommunication Union (ITU) osztja ki; az ütközésveszély az űrszemét problémájához kapcsolódik, amely napjainkban egyre nagyobb figyelmet kap.

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

(Misszióirányítási rendszer). A MICONYS és annak SCOS-2000® komponense valószínűleg az ESA szoftverfejlesztési, innovációs és technológiatranszfer-politikájának legismertebb példái (Kaufeler, Jones and Karl 2001). A SCOS-2000 támogatja a teleparancsok kiadását, a telemetria vételét, megjelenítését és archiválását. A SCOS-2000 az ESA korábbi hasonló rendszereinek fejlesztése és üzemeltetése során szerzett tapasztalatok eredményeként jött létre: ilyen volt az MSSS, a SCOS-1 és a SCOS-2. Az ESA jelenleg az új MCS-rendszert fejleszti, amely a jövőben a SCOS-2000 leváltására szolgál. Neve: European Ground Systems – Common Core (EGS-CC). A SCOS-hoz hasonlóan a projekt célja egy közös infrastruktúra fejlesztése, amely modern technológiák és szolgáltatásorientált architektúrák alkalmazásával támogatja az űrmissziók indítás előtti és utáni szakaszainak felügyeletét és irányítását (Peccioli et al. 2012). Az EGS-CC fejlesztése nem kizárólag az ESA felelőssége: a projektben európai nemzeti űrügynökségek (CNES, UK Space Agency és DLR), valamint ipari vállalatok (AIRBUS Defence and Space, Thales Alenia Space és OHB Systems) is részt vesznek.

Az ESA projektjei mellett más kezdeményezések is irányulnak általános célú MCS-szoftverrendszer fejlesztésére. A NASA több hasonló projektet valósított meg, ezek többsége házon belüli fejlesztés volt. A Goddard Space Flight Centre két rendszert fejlesztett ki, az ITOS-t és az ASIST-et, olyan missziók kezelésére, mint a WMAP (Wilkinson Microwave Anisotropy Probe), az IMAGE (Imager for Magnetopause-to-Aurora Global Exploration), az EO-1 (Earth Observing 1), az ST-5 (Space Technology 5), az SDO (Solar Dynamics Observatory) vagy az LRO (Lunar Reconnaissance Orbiter) (Pfarr et al. 2007).

Mindezekben az esetekben összetett rendszerekről van szó, amelyeknek különböző funkciókat kell megvalósítaniuk; ezek a műhold és a misszió jellemzőitől függően aktiválhatók vagy kikapcsolva maradhatnak. Emiatt ezek a szoftverintenzív rendszerek alkalmasak termékcsalád- és jellemzőalapú modellezési technikákkal történő fejlesztésre, amelyek a fogalmak világos és jól szervezett rendszerezésére támaszkodnak a szakterület és a rendszer szükséges képességeinek megértése érdekében.

2. JELLEMZŐALAPÚ MODELLEZÉS

A FOGALMAK RENDSZEREZÉSEKÉNT

A jellemzőalapú modellezés a szoftver-termékcsaládok mérnöki fejlesztésében alkalmazott technikák egyike. Ez a kilencvenes évek végén népszerűvé vált tudományterület újrafelhasználható szoftverprogramok létrehozásával foglalkozik. Az SPLE célja, hogy

Terminologija | 2020 | 27

189

újrafelhasználható komponenseket és artefaktumokat hozzon létre, amelyeket később egyesítve az adott ügyfél és környezet igényeinek megfelelő termékek állíthatók elő. Az SPLE-vel kapcsolatos tapasztalatokat a szakmai és tudományos szakirodalom széles körben dokumentálja. Capilla (2013) több olyan esettanulmányt ismertetett, amelyekben az SPLE-t sikeresen alkalmazták: Boeing’s üzemi, missziókritikus repülési programjai az avionikai és pilótafülke-funkciókhoz; Bosch’s benzinüzemű rendszerek motorvezérlő szoftvere; Hewlett Packard’s nyomtatószoftvere; Toshiba’s energiatermelő és -átviteli berendezései; valamint General Motors’ hajtáslánc-vezérlő szoftvere. Az Apel et al. (2013: 9) szerint a szoftver-termékcsaládok (SPL) előnyei közé tartozik a szoftvertermékek ügyfelek egyedi igényeihez igazítása, a költségek csökkenése – mivel újrafelhasználható eszközök készlete különféle módokon egyesíthető új termékek létrehozására –, a minőség javulása és a piacra jutási idő rövidülése.

A jellemzők és a jellemzőalapú modellezés fontos fogalmak az SPL fejlesztésében. Az ISO/IEC/IEEE 24765:2010, Systems and software engineering — Vocabulary szabvány az features (jellemzők) általános meghatározását adja meg, amely az IEEE Std 829:2008 IEEE Standard for Software and System Test Documentation szabványból származik: „Egy rendszerelem megkülönböztető tulajdonsága. MEGJEGYZÉS: Funkcionális és nem funkcionális attribútumokat egyaránt magában foglal, például a teljesítményt és az újrafelhasználhatóságot.” Kang and Lee (2013, 28) a jellemzőket így határozza meg: „olyan elvont fogalmak, amelyek hatékonyan támogatják a kommunikációt egy termékcsalád különböző érdekelt felei között, ezért természetes és intuitív módja annak, hogy az emberek a termékcsaládok közös és változó tulajdonságait jellemzők formájában fejezzék ki.”

A jellemzők különböző célokat szolgálnak a termékötlet kialakításának és fejlesztésének folyamatában. Eszközt jelentenek a termékjellemzők közlésére és a követelmények azonosításának támogatására; emellett azok a fogalmak is, amelyek a tervezési és megvalósítási döntéseket irányítják.

A termékcsalád fejlesztése két egymást kiegészítő életciklusból áll:

• Szakterületi mérnöki tevékenység, valamint

• Alkalmazásmérnöki tevékenység.

Az IEEE 1517-2010 szabvány a szakterületi mérnöki tevékenységet a következőképpen határozza meg: „Életciklus, amely a termékcsalád közös és változó jellemzőinek meghatározására és kezelésére szolgáló folyamatok összességéből áll. A szakterületi mérnöki tevékenység elemzi a termékcsalád szakterületét, és újrafelhasználható artefaktumok készletét dolgozza ki. Ezek az artefaktumok szoftverkövetelményeket, tervezési elemeket, teszteseteket és

190

Ricardo Eito Brun

Terminology as the Basis for Building Engineering Feature-based Models

eljárások, felhasználói dokumentáció stb. A tartományelemzés a teljes termékvonalra kiterjedő követelménymérnöki tevékenység egyik formájának tekinthető, amely magában foglalja az előre látható változékonyság azonosítását is. A tartományelemzés fő eredménye a jellemzőmodell, amely meghatározza és leírja a termékvonal termékeit.

A jellemzőmodellezés egy diagramkészítési technika, amelyet a kilencvenes években vezettek be az FODA (Feature-Oriented Domain Analysis) módszertannal. Az FODA primitíveket biztosított a strukturális kapcsolatok (összetétel, általánosítás és specializáció), az opcionális jelleg, az alternatívák és a kölcsönös függőségek ábrázolásához. Később különböző szerzők felülvizsgálták (Kang és Lee 2013: 30–31). A jellemződiagramok a jellemzőmodellek vizuális megjelenítései, amelyeken a jellemzőket hierarchikus fában elhelyezett dobozok ábrázolják. Minden csomóponthoz tartozik egy címke a jellemző nevével. A jellemzők hierarchikus elrendezése szülő-gyermek kapcsolatokat hoz létre. Ha egy gyermekjellemzőt kiválasztunk, a szülőjét is ki kell választani. A diagramok különbséget tehetnek a kötelező és az opcionális jellemzők között, és azonosíthatják az érvényes jellemzőkombinációkat.

A jellemződiagramok különösen a következőket ábrázolhatják:

Absztrakt jellemzők, amelyek a fában lévő jellemzők rendszerezésére szolgálnak, de nem kapcsolódnak megvalósítási artefaktumokhoz. Ezeket szürke dobozok jelölik.

Konkrét jellemzők, amelyek megvalósítási artefaktumoknak felelnek meg, és fehér dobozok jelölik őket.

Kötelező jellemzők, amelyeket a dobozuk felső szegélye fölött elhelyezett kitöltött pont jelöl.

Opcionális jellemzők, amelyeket a dobozuk felső szegélye fölött elhelyezett üres pont jelöl.

Annak szükségessége, hogy egy adott szülő gyermekjellemzői közül csak egyet válasszunk ki (kizáró VAGY, XOR vagy egy-a-sok-közül). Ezt a szülőjellemző dobozának alsó szegélyén elhelyezett üres ív jelöli.

Annak lehetősége, hogy egy adott szülő több gyermekjellemzőjét is kiválasszuk (VAGY vagy néhány-a-sok-közül). Ezt a szülőjellemző dobozának alsó szegélyén elhelyezett kitöltött ív jelöli.

A jellemzők közötti függőségeket szöveges megjegyzésekkel ellátott nyilak jelölik.

Terminologija | 2020 | 27

191

Az alábbi ábra a fent ismertetett konvenciók szerinti tipikus jellemződiagramot mutatja:

1. ábra. Példa a jellemződiagram ábrázolására (Forrás: Gargantini 2015)

A jellemzőmodellnek az ábrán kívül további információkat is tartalmaznia kell. Apel et al. (2013: 27) szerint az alábbi adatok adhatók hozzá:

„A jellemző leírása és a hozzá tartozó követelmények összessége.

Kapcsolat más jellemzőkkel, különösen a hierarchia, a sorrend és a csoportosítás.

Külső függőségek, például a szükséges hardvererőforrások.

Érdekelt érintettek.

Egy jellemző megvalósításának becsült vagy mért költsége.

Stb.”

A műholdvezérlő szoftveralkalmazások funkcionális jellemzőit reprezentáló jellemzőmodell kidolgozását a domént alkotó fogalmak világos megértésével és modellezésével kell kezdeni. E célból a terminológiai és terminográfiai tevékenységek, valamint a terminusok, fogalmak és kapcsolataik azonosítása képezi a célmodell felépítésének alapját.

192

Ricardo Eito Brun

Terminology as the Basis for Building Engineering Feature-based Models

3. MUNKAMÓDSZERTAN

A javasolt jellemzőmodellt az alábbi lépések követésével dolgoztuk ki:

Az ezen a területen megjelent szakmai és tudományos szakirodalom azonosítása és áttekintése. Ez magában foglalja az olyan szervezetek által vezetett űrkutatási projektekben alkalmazott megközelítésre vonatkozó információk keresését, mint az ESA (European Space Agency) vagy a NASA (National Aeronautics and Space Administration).

Az elemzett szakirodalom alapján szójegyzék összeállítása terminológiamenedzsment-technikák alkalmazásával, a kifejezésekre, a köztük lévő kapcsolatokra, a dokumentumokban azonosított definíciókra, valamint a kifejezések használati kontextusára vonatkozó információk rögzítése érdekében.

A szójegyzéket alapul vevő, a műholdak felügyeletét és vezérlését végző szoftveralkalmazások által kínált funkciókat reprezentáló jellemzőalapú modell létrehozása.

A kifejezések azonosításához felhasznált bemenetek között szerepelt a kiválasztott terméket ismertető műszaki dokumentumok egy része: üzemeltetési kézikönyvek, ismertető dokumentumok és oktatási anyagok. A jellemzőmodell a jellemzők hierarchikus fája, amelyben a jellemzők kötelezőként vagy választhatóként vannak megjelölve, és függőségek állnak fenn közöttük. Az elemzett szoftveralkalmazás esetében a választható és kötelező jellemzők azonosítása mellett további, termékcsalád-változékonysági követelményeket is azonosítottunk. A vizsgált szoftver által támogatott funkciók közül néhányhoz különösen a meglévő kód felülírására vagy testreszabására van szükség. E változékonysági eseteket olyan szakértők segítségével azonosítottuk, akik ilyen típusú szoftveralkalmazások fejlesztésével és testreszabásával foglalkoznak. Az információk összegyűjtésére személyes interjúkat készítettünk.

A jellemzőmodell és a diagramok létrehozására kiválasztott eszköz a FeatureIDE⁵. Ez egy Java- és Eclipse-alapú, nyílt forráskódú eszköz, amelyet a Otto-von-Guericke-Universität Magdeburg munkatársai fejlesztettek ki. A FeatureIDE segítségével grafikus szerkesztőben hozható létre jellemzőmodell, a jellemzők kötelezőként, választhatóként vagy absztraktként jelölhetők meg, és felépíthető a hierarchikus fa. A jellemzőmodell elkészülte után különböző konfigurációk hozhatók létre: ezek a cél-szoftveralkalmazás előállításához felhasználandó jellemzők kiválasztásai.

⁵ Lásd: https://FeatureIDE.github.io/. Utolsó ellenőrzés: 01-03-2018.

Terminologija | 2020 | 27

193

forráskódot. Sajnos az eszköz nem biztosít lehetőséget terminusok vagy terminológiai egységek kezelésére, ezért kiegészítő eszközök használata szükséges.

2. ábra. FeatureIDE (a szerző készítette)

4. AZ EREDMÉNYEK ÉS A MEGVITATÁSUK BEMUTATÁSA

Ez a szakasz a Mission Control Systems (MCS) szoftveralkalmazások egyik funkciómodell-részét foglalja össze. A dokumentumokból kinyert fogalmak elemzése a rendszerfunkciók alábbi területek szerinti csoportosításához vezetett:

Asztali környezet és munkamenet kezelése, amely biztosítja a bejelentkezéshez, a munkamenet indításához és a különböző alkalmazások elindításához szükséges funkciókat. Több műhold kezelése esetén a felhasználó válthat a műholdak munkaterületei között.

Telemetriai lánc, amely a következőket foglalja magában: telemetria-feldolgozás, riasztáskezelő és telemetria-megjelenítés.

194

Ricardo Eito Brun

Terminology as the Basis for Building Engineering Feature-based Models

Teleparancs-lánc, amely a következőket foglalja magában: teleparancs-feltöltés, kézi verem, ütemezett verem és teleparancs-előzmények.

TT&C/TCR híd, amely láthatóságot és vezérlést biztosít a földi állomással fennálló interfészen a telemetriai, parancs-, távolságmérési (TCR) és antennapozicionálási adatfolyamok tekintetében.

Eseménynapló, amely rögzíti a rendszerműködés során azonosított eseményeket, és lehetővé teszi az üzemeltetők számára a teljes eseménytörténet böngészését és keresését.

Fedélzeti memóriakezelés, amely lehetőséget biztosít az űreszköz memóriaképének kezelésére (letöltésére, szerkesztésére és feltöltésére).

A dokumentáció és a terminusok elemzése a rendszer e funkcióihoz kapcsolódó funkciómodellek létrehozásához vezetett. Példaként a telemetriakezelés konkrét esetét foglaljuk össze. Megfigyelhető, hogy az azonosított funkciókhoz a szakirodalmon és műszaki dokumentáción alapuló meghatározások tartoznak:

A telemetriai lánc kifejezés a telemetria feldolgozásában részt vevő különböző folyamatokra utal: vétel a TT&C rendszertől, csomagképzés, archiválás és továbbítás a felhasználó alkalmazásokhoz:

Telemetriai csomagképzés. Az MCS a telemetriai csomagokra vonatkozó szabvány szerinti forráscsomagokat fogadja, metaadatokkal (például a telemetriai adatfolyam minőségével) egészíti ki, majd egy vagy több belső MCS-telemetriacsomaggá alakítja azokat. A beérkező adatokból képzett csomagok kritériumai a műholdtól, a küldetéstől és a BBE-protokolloktól függően változhatnak.

Csomagminőség-ellenőrzés. Az MCS folyamatosan ellenőrzi a telemetria minőségét a TT&C vagy maga az MCS által végzett ellenőrzések segítségével. Minden belső csomaghoz telemetriaminőségi metaadatok kerülnek hozzáadásra. Az ellenőrzések eredményétől függően a csomag feldolgozásra alkalmasnak (GOOD) vagy feldolgozásra alkalmatlannak (BAD) minősíthető. A folyamat során az elveszett telemetriai adatokat is azonosítani kell.

Tipikus minőségellenőrzés a Keretek sorrendjének ellenőrzése, amely megállapítja, hogy a keretek sorrendben érkeznek-e.

Terminologija | 2020 | 27

195

Ellenőrzési események keletkeznek, ha ezek a vizsgálatok sikertelenek. Az operátor kiválaszthatja, milyen művelet történjen a BAD telemetriai keretek azonosításakor (feldolgozásuk vagy elvetésük).

• Időminőségi ellenőrzések. Ezek az ellenőrzések azt vizsgálják, hogy a TT&C által az egyes telemetriai adatfolyamokhoz jelentett idő és az MCS helyi ideje közötti eltérés nem túl nagy-e. Az aktuális MCS-idő és a telemetriai keret időbélyege (amelyet a földi állomás állít be a keret vételét követően) közötti különbség egy konfigurálható időablakon belül van. Ha ezek az ellenőrzések sikertelenek, eseményüzenetek keletkeznek. Az időminőségi ellenőrzésekhez szükséges a telemetriacsomagok időbélyegzése.

• Telemetriai dekommutáció, amely kinyeri a telemetriai paramétermintákat a csomagokból⁶. Ez magában foglalja a paraméterek kinyerését, a bitek dekódolását, a kalibrálást, a tartományon kívüli értékek ellenőrzését, az érvényesség ellenőrzését és a paraméterek időbélyegzését.

○ Telemetriai paraméterek kinyerése során a rendszer megkeresi és kinyeri a telemetriai paraméterek nyers értékeit a csomagokból. A nyers értékek rendszerint előjeles vagy előjel nélküli egész számok, illetve lebegőpontos számok. Ez a folyamat rögzített telemetria esetén egyszerű, mivel a paraméter helyére vonatkozó összes szükséges információ megtalálható a műhold MIB-jében, programozható telemetria esetén azonban összetettebb.

○ Bitek dekódolása során a telemetriai csomagban kódolt értékből állapítják meg a nyers értéket. Tipikus esetben a nyers érték megegyezik a csomagban kódolt értékkel, de előfordul, hogy bitalapú (például bitfordítás vagy kettes komplemens képzése) vagy bájtszintű átalakításra van szükség.

○ Származtatott vagy szintetikus paraméterek. Ezeket nem az űreszközről nyerik, hanem a földi állomáson, algoritmikus úton származtatják a begyűjtött telemetriai paramétereket operandusként használva. Szkriptnyelveken írt képletekkel számítják ki őket. A kalibrálás, az érvényesség ellenőrzése és a paraméterek időbélyegzése előtt kerül sor a kiszámításukra.

A származtatott paraméterek egyik különleges típusa a keményen kódolt származtatott paraméter (HCDP), amelyet alacsony szintű programozási nyelveken írnak.

⁶ A paraméterek lehetnek szinkronok (a fedélzeti mintavételezést követően azonnal letöltődnek a telemetriában) vagy aszinkronok (a fedélzeti mintavételezést követően nem töltődnek le azonnal a telemetriában, hanem a fedélzeti memóriában tárolják, majd később töltik le őket). A paraméterek mintavételezése és kódolása formátumonként rendszerint egyszer vagy többször történik, kivéve az alkommutált paramétereket, amelyek mintavételezése és kódolása nem minden formátumban történik meg, valamint a felülkommutált paramétereket, amelyek mintavételezése és kódolása többször történik.

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

mint például a C++, a Fortran vagy a C. Módosításukhoz újra kell fordítani a forráskódot.

o A telemetriai paraméter időbélyegzése dátumot rendel a paramétermintákhoz a mintákat tartalmazó csomag időpontjának felhasználásával, és hozzáadva a műhold MIB-jében meghatározott eltolást.

o A tartományon kívüliséget (OOR) ellenőrző funkció elemzi, hogy egy telemetriai paraméter nyers értéke kívül esik-e a meghatározott kalibrálási tartományon. A tartományon kívüli telemetriai paraméterek érvénytelennek minősülnek, OOR kategóriával. Az OOR a telemetriai paraméter érvényességének megítélésére szolgál, és jelzi, hogy az értéke használható vagy értelmetlen-e.

Ezenkívül a tartományon kívüli paramétereket meg kell jeleníteni, és az operátoroknak nyugtázniuk kell. A paraméter érvénytelennek nyilvánításának további esetei: a paraméter lejárt, vagy – származtatott paraméterek esetén – érvénytelen paraméterek felhasználásával számították ki. Az esettől függetlenül a telemetriai paraméter érvénytelenségére vonatkozó metaadatoknak részletezniük kell az állapot okát.

• A telemetriai paraméterek kalibrálása a nyers értékeket ember által olvasható formává alakítja (mérnöki vagy kalibrált értékekké, a fizikai mennyiségnek megfelelő mértékegységekkel). A kalibrálás különböző módszerekkel végezhető:

o Numerikus vagy lineáris diszkrét kalibrálás: egy (X, Y) párokból álló kalibrációs görbe alapján lineáris interpolációt alkalmaz, ahol X a nyers értéket, Y pedig a mérnöki értéket jelöli.

o Szöveges, digitális vagy állapotkalibrálás: szöveges karakterláncokat rendel a paraméter nyers értékének tartományaihoz. A szöveges értékek diszkrét értékekből vagy azok egy tartományából származtathatók. Egyszerű példa a fedélzeti egységek ON / OFF állapota, amely egy egybites paraméterből állapítható meg, ahol a 0 az OFF, az 1 pedig az ON értéket jelenti.

o Polinomiális kalibrálás: legfeljebb ötödfokú polinomot használ a nyers értékek mérnöki értékekké alakításához.

Az azonosított jellemzők részletesebb ismertetése nélkül (csupán néhányat mutatunk be, hogy szemléltessük: azonosításukhoz alapos terminológiai munkára van szükség), a következő ábra ezen funkcionális terület fő jellemzőit mutatja be:

Terminologija | 2020 | 27

197

3. ábra. TM-feldolgozás – jellemzők 1. ábra: FeatureIDE (a szerző készítette)

5. KÖVETKEZTETÉSEK

A tanulmány egy műhold-irányító szoftveralkalmazás jellemzőmodelljének kidolgozását ismerteti. Bemenetként olyan műszaki dokumentumokat (üzemeltetési kézikönyveket, szakmai tanulmányokat és oktatási anyagokat) használ, amelyek a vizsgált rendszertípus funkcióit írják le. Az első lépés a

198

Ricardo Eito Brun

Terminology as the Basis for Building Engineering Feature-based Models

a dokumentumok áttekintésével történő fogalomazonosítás és -kinyerés, valamint a fogalmak meghatározásának azonosítása abban a kontextusban, amelyben alkalmazzák őket. Ezt a fogalomgyűjteményt tovább elemzik a jellemzők azonosítása érdekében; ezeket funkcionális kritériumok szerint, tizenkét fő kategóriába rendezve jelenítették meg a jellemzőmodellben és az ábrán: munkamenet-kezelés, földi állomáskapcsolat-kezelés, telemetriafeldolgozás, telemetriaadatok megjelenítése, teleparancs-feldolgozás, küldetési archívum stb.

Az egyes funkcionális területeknél összefoglalták és jellemződiagramokban ábrázolták a fő fogalmak leírását, valamint azokat a jellemzőket, amelyeket egy szoftverrendszernek támogatnia kell; a diagramokat a FeatureIDE eszközzel hozták létre. A definíciók és a használati kontextus szolgáltak alapul a jellemzők közötti kapcsolatok megállapításához és a változatossági lehetőségek azonosításához is. A változatosság három fő okát azonosították:

A küldetésre jellemző konfigurációs paramétereket rendszerint nyilvános konfigurációs fájlokkal kezelik.

Opcionális jellemzők kiválasztása a küldetés típusától függően: például a Föld megfigyelésére szolgáló LEO-műholdakra jellemző, helyzetalapú teleparancsok.

A küldetésre jellemző szolgáltatások testreszabása, amelyek kiterjesztik a telemetriai és teleparancs-szabványokban, például a PUS-ban meghatározott alapszolgáltatásokat és -funkciókat.

A munka szemlélteti, hogy szükség van a terminológiai módszerek alkalmazására a fogalmak jelentésének összegyűjtése, elemzése és dokumentálása, valamint a később különböző célokra felhasználható kapcsolatok kinyerése érdekében. A jellemzőalapú mérnöki modellek esetében a fogalmak képezik az alapot a szoftverek és rendszerek funkcióinak egyértelmű leírásához, valamint az összetett rendszerek jellemzőinek azonosításához. A fogalmak következetes használata azért is szükséges, hogy a későbbi mérnöki feladatokban (tervezés, megvalósítás, tesztelés stb.) részt vevő különböző szereplők közös értelmezéssel rendelkezzenek a rendszer jellemzőiről, és elkerüljék azokat a hibákat, amelyeket a rendszer által támogatni kívánt szakterület nem megfelelő meghatározása okoz.

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