doi.org/10.35321/term27-08

Terminologia ca bază pentru construirea modelelor inginerești bazate pe caracteristici

RICARDO EITO BRUN

Universidad Carlos III de Madrid

REZUMAT

Operațiunile satelitare necesită utilizarea combinată a diferitelor instrumente pentru a sprijini activitățile inginerești și pentru a controla nava spațială. Această comunicare este gestionată de Sistemul de monitorizare și control (MCS), care primește date de telemetrie de la nava spațială și transmite telecomenzi pentru a menține orientarea și traiectoria de zbor ale satelitului. Aceste sisteme complexe sunt dezvoltate ca platforme deschise, care pot fi extinse și personalizate pentru a sprijini cerințele și obiectivele specifice misiunii. În general, se poate afirma că aceste aplicații software sunt potrivite pentru implementarea mecanismelor de variabilitate într-un mod structurat și planificat și că funcționalitatea lor este adecvată analizei fezabilității aplicării tehnicilor de modelare bazate pe caracteristici. Această lucrare descrie utilizarea analizei terminologice pentru construirea unui model de caracteristici care să sprijine analiza cerințelor pentru acest tip de sisteme bazate pe software.

CUVINTE-CHEIE: terminologie tehnică, modele bazate pe caracteristici, inginerie aerospațială, extragerea terminologiei

REZUMAT

Operațiunile satelitare necesită diverse instrumente pentru a asigura desfășurarea fără probleme a activităților inginerești și pentru a controla nava spațială. Această comunicare este gestionată de Sistemul de monitorizare și control (SKS), care primește date de telemetrie de la nava spațială și transmite telecomenzi pentru a menține orientarea satelitului și traiectoria sa orbitală. Aceste sisteme complexe sunt concepute ca platforme deschise, care pot fi extinse și adaptate în funcție de cerințele și obiectivele specifice fiecărei misiuni. Se poate afirma, în general, că aceste aplicații pot fi utilizate pentru implementarea structurată și planificată a mecanismelor de variabilitate, iar funcționalitatea lor permite analizarea posibilităților de aplicare a metodologiilor de modelare a caracteristicilor. Acest articol descrie utilizarea analizei terminologice pentru crearea unui model de caracteristici care să sprijine analiza cerințelor pentru acest tip de sisteme software.

CUVINTE-CHEIE: terminologie tehnică, modele de caracteristici, inginerie aerospațială, identificarea termenilor

186

Ricardo Eito Brun

Terminology as the Basis for Building Engineering Feature-based Models

1. INTRODUCERE

Glosarul NASA definește sateliții astfel: „un obiect care zboară liber și orbitează în jurul Pământului, al unei alte planete sau al Soarelui.” Sateliții sunt un tip de vehicul spațial care se deplasează pe o orbită regulată, clar definită, în jurul centrului de greutate al unui alt corp ceresc (Garner 1996: 4). De la lansarea primilor sateliți artificiali – Sputnik 1 la 4 octombrie^th 1957 și Explorer 1 la 31 ianuarie^st 1958 – au fost lansate numeroase misiuni satelitare cu scopuri diverse: explorare astronomică, furnizarea de servicii de comunicații și navigație, observarea Pământului, recunoaștere și misiuni științifice. Sateliții sunt sisteme aerospațiale complexe, alcătuite din elemente terestre și spațiale: vehiculul spațial trebuie operat de un element de control aflat pe Pământ și trebuie să mențină contactul cu acesta. În prezent, progresul științific și serviciile oferite utilizatorilor depind de sateliți și constelații de sateliți. Exemple relevante sunt Telescopul Spațial Hubble (HST), sistemele de navigație precum GPS (Global Positioning System), GLONASS și sistemul european Galileo, UARS (Upper Atmosphere Research Satellite) sau GOES (Geostationary Operational Environment Satellite). Numărul total de sateliți lansați începând din 1957 – conform catalogului US SSN² – este de aproape 18 200; Indexul obiectelor lansate în spațiul cosmic din 2017 al UNOOSA raportează că în prezent orbitează planeta 4 635 de sateliți, cu o creștere de 357 de sateliți (8,95%) față de anul precedent³. Scopul acestui articol este de a demonstra necesitatea aplicării managementului și extragerii terminologiei pentru a sprijini dezvoltarea unor modele bazate pe caracteristici, care să organizeze conceptele ce descriu funcțiile aplicațiilor software utilizate pentru monitorizarea și controlul sateliților.

Sateliții sunt clasificați în funcție de scop și de tipul orbitei. Scopul se referă la serviciile pe care satelitul este destinat să le furnizeze. În ceea ce privește orbita, se face distincție între orbita terestră joasă (LEO), orbita terestră medie (MEO) și orbita geostaționară (GEO). Sateliții LEO – utilizați pentru știință și observarea Pământului – urmează o orbită eliptică; deoarece vizibilitatea lor de la stațiile terestre este limitată, datele sunt stocate la bord și transmise către sol

¹ A se vedea https://www.grc.nasa.gov/www/k-12/TRC/laefs/laefs_s.html#satellite [accesat la 2020-08-01].

² Rețeaua US Space Surveillance Network este responsabilă de detectarea, urmărirea, catalogarea și identificarea obiectelor artificiale care orbitează Pământul. Catalogul este disponibil la: https://www.space-track.org/#/ssr [accesat la 2020-08-01].

³ Oficiul Națiunilor Unite pentru Afaceri Spațiale. A se vedea https://www.pixalytics.com/sats-orbiting-earth-2017/

Terminologija | 2020 | 27

187

stații atunci când satelitul devine vizibil. Sateliții GEO sunt utilizați în scopuri de telecomunicații și meteorologice; sateliții de telecomunicații recepționează semnale de radiofrecvență (RF) de la Pământ, le amplifică, le deplasează frecvența și le retransmit către Pământ. Aceștia orbitează la 36 000 km deasupra Ecuatorului (în același plan), iar rotația lor este sincronă cu rotația Pământului, rămânând permanent deasupra aceluiași punct de pe Ecuator)⁴. La fel ca sateliții, misiunile științifice în spațiul îndepărtat au nevoie, de asemenea, de monitorizare și control similare pentru transmiterea telecomenzilor și recepția telemetriei.

Misiunile satelitare necesită personal dedicat pentru monitorizarea continuă, în timp real, a stării și poziției satelitului. Controlul misiunii cuprinde ansamblul sarcinilor executate după lansare de inginerii de operare cu ajutorul aplicațiilor software și implică schimbul de date între segmentele terestru și spațial pentru monitorizarea și controlul stării subsistemelor de la bordul satelitului. În misiunile științifice, este necesară și recepționarea informațiilor de la încărcătura utilă a satelitului și transmiterea acestora către utilizatorii finali (comunitatea științifică). Funcțiile tipice îndeplinite în timpul controlului misiunii includ recepția și analiza telemetriei, transmiterea telecomenzilor și urmărirea. Telemetria reprezintă datele transmise de satelit către Pământ, care informează asupra stării și condițiilor satelitului și ale subsistemelor sale. Telecomenzile sunt ordinele transmise de la sol către vehiculul spațial pentru configurarea și operarea acestuia. (Uhlig, Sellmaier, and Schmidhuber 2015: 232). Urmărirea și menținerea poziției pe orbită, cunoscute și sub denumirea de măsurarea distanței, constau în monitorizarea și determinarea traiectoriei de zbor și a poziției, folosind tehnici și semnale RF.

Din perspectiva ingineriei software, controlul sateliților necesită diferite aplicații și instrumente pentru dinamica zborului, planificarea misiunii, telemetrie și transmiterea telecomenzilor, controlul și rutarea rețelei, precum și interfețe între acestea. Această complexitate a determinat agențiile spațiale să ofere soluții diferite. Unul dintre cele mai importante repere în dezvoltarea software-ului MCS a fost decizia departamentului ESA Ground Systems Engineering de a dezvolta și licenția industriei europene un set de aplicații software distribuite sub denumirea MICONYS^®

⁴ Sateliții GEO sunt distribuiți într-o zonă limitată a spațiului. Sloturile orbitale sunt alocate de Uniunea Internațională a Telecomunicațiilor (ITU) pentru a evita coliziunile, un risc asociat problemei deșeurilor spațiale, care primește astăzi o atenție tot mai mare.

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

(Sistem de control al misiunii). MICONYS și componenta sa SCOS-2000® sunt probabil cele mai cunoscute exemple ale politicii ESA privind dezvoltarea software-ului, inovarea și transferul de tehnologie (Kaufeler, Jones and Karl 2001). SCOS-2000 permite transmiterea telecomenzilor, recepționarea telemetriei, afișarea și arhivarea datelor. SCOS-2000 a rezultat din experiența acumulată de ESA în dezvoltarea și operarea unor sisteme similare anterioare: MSSS, SCOS-1 și SCOS-2. În prezent, ESA dezvoltă noul sistem MCS, destinat să înlocuiască SCOS-2000 în viitor. Numele său este European Ground Systems – Common Core (EGS-CC). La fel ca SCOS, proiectul urmărește dezvoltarea unei infrastructuri comune care să sprijine monitorizarea și controlul misiunilor spațiale în fazele de dinaintea lansării și de după lansare, folosind tehnologii moderne și arhitecturi orientate pe servicii (Peccioli et al. 2012). Dezvoltarea EGS-CC nu ține doar de responsabilitatea ESA: agențiile spațiale naționale europene (CNES, UK Space Agency și DLR) și companiile industriale (AIRBUS Defence and Space, Thales Alenia Space și OHB Systems) fac parte din proiect.

Pe lângă proiectele ESA, există și alte inițiative care urmăresc dezvoltarea unui sistem software MCS generic. NASA a finalizat proiecte similare, majoritatea dezvoltate în cadrul instituției. Goddard Space Flight Centre a dezvoltat două sisteme, ITOS și ASIST, pentru gestionarea unor misiuni precum 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) sau LRO (Lunar Reconnaissance Orbiter) (Pfarr et al. 2007).

În toate aceste cazuri, avem de-a face cu un sistem complex, care trebuie să implementeze funcții diferite, ce pot fi activate sau nu în funcție de caracteristicile satelitului și ale misiunii. Prin urmare, aceste sisteme cu o componentă software intensivă sunt candidate potrivite pentru dezvoltarea prin utilizarea liniilor de produse și a tehnicilor de modelare bazată pe caracteristici, care se bazează pe o organizare clară și bine structurată a conceptelor, pentru a înțelege domeniul și capabilitățile necesare ale sistemului.

2. MODELAREA BAZATĂ PE CARACTERISTICI

CA ORGANIZARE A CONCEPTELOR

Modelarea bazată pe caracteristici este una dintre tehnicile aplicate în ingineria liniilor de produse software, o disciplină pentru construirea de programe software reutilizabile, care a devenit populară la sfârșitul anilor nouăzeci. SPLE urmărește să

Terminologija | 2020 | 27

189

construiască componente și artefacte reutilizabile, care pot fi ulterior combinate pentru a crea produse adaptate nevoilor unui anumit client și unui anumit context. Experiențele din domeniul SPLE sunt documentate pe larg în literatura profesională și academică. Capilla (2013) a inclus mai multe studii de caz în care SPLE a fost aplicată cu succes: programele de zbor operaționale și esențiale pentru misiune ale Boeing’s pentru funcțiile avionice și de cockpit, software-ul de control al motoarelor pentru sistemele pe benzină al Bosch’s, software-ul pentru imprimante al Hewlett Packard’s, echipamentele de producere și transmitere a energiei ale Toshiba’s și software-ul de control al grupurilor motopropulsoare al General Motors’. Beneficiile liniilor de produse software (SPL), conform Apel et al. (2013: 9), includ adaptarea produselor software la nevoile specifice ale clienților, reducerea costurilor – deoarece un set de active reutilizabile poate fi combinat în moduri diferite pentru a genera produse noi –, îmbunătățirea calității și reducerea timpului de lansare pe piață.

Caracteristicile și modelarea bazată pe caracteristici sunt concepte relevante în dezvoltarea SPL. ISO/IEC/IEEE 24765:2010, Systems and software engineering — Vocabulary, oferă o definiție generală a features, preluată din IEEE Std 829:2008 IEEE Standard for Software and System Test Documentation: „O caracteristică distinctivă a unui element de sistem. NOTĂ: include atât atribute funcționale, cât și nefuncționale, precum performanța și reutilizabilitatea.” Kang and Lee (2013, 28) definesc caracteristicile drept „concepte abstracte care sprijină eficient comunicarea între diverșii factori interesați ai unei linii de produse și, prin urmare, este firesc și intuitiv ca oamenii să exprime comunalitatea și variabilitatea liniilor de produse în termeni de caracteristici.”

Caracteristicile îndeplinesc diverse scopuri în procesul de concepere și dezvoltare a produsului. Ele sunt mijloace de comunicare a caracteristicilor produsului și de sprijinire a identificării cerințelor; totodată, sunt conceptele care ghidează deciziile de proiectare și implementare.

Dezvoltarea unei linii de produse cuprinde două cicluri de viață complementare:

• Ingineria domeniului și

• Ingineria aplicațiilor.

Standardul IEEE 1517-2010 definește ingineria domeniului astfel: „Ciclu de viață care constă dintr-un set de procese pentru specificarea și gestionarea comunalității și variabilității unei linii de produse. Ingineria domeniului analizează domeniul unei linii de produse și dezvoltă un set de artefacte reutilizabile. Aceste artefacte includ cerințe software, elemente de proiectare, cazuri de testare și

190

Ricardo Eito Brun

Terminology as the Basis for Building Engineering Feature-based Models

proceduri, documentație pentru utilizatori etc. Analiza domeniului poate fi considerată un fel de inginerie a cerințelor pentru întreaga linie de produse, inclusiv identificarea variabilității anticipate. Principalul artefact generat de analiza domeniului este modelul de caracteristici, care va specifica și descrie produsele din cadrul liniei.

Modelarea caracteristicilor este o tehnică de reprezentare diagramatică, introdusă în anii nouăzeci odată cu metodologia FODA (Analiza domeniului orientată pe caracteristici). FODA a furnizat primitive pentru reprezentarea relațiilor structurale (compoziție, generalizare și specializare), a caracterului opțional, a alternativelor și a dependențelor reciproce. Ulterior, metodologia a fost revizuită de diferiți autori (Kang și Lee 2013: 30–31). Diagramele caracteristicilor sunt reprezentarea vizuală a modelelor de caracteristici, în care caracteristicile sunt reprezentate prin casete într-un arbore ierarhic. Fiecare nod are atașată o etichetă cu numele caracteristicii. Dispunerea ierarhică a caracteristicilor creează relații părinte-copil. Dacă este selectată o caracteristică copil, trebuie selectată și caracteristica sa părinte. Diagramele pot distinge între caracteristicile obligatorii și cele opționale și pot identifica combinațiile valide de caracteristici.

În particular, diagramele caracteristicilor pot reprezenta:

Caracteristici abstracte, folosite pentru a organiza caracteristicile în arbore, dar care nu sunt asociate cu artefacte de implementare. Acestea sunt reprezentate prin casete gri.

Caracteristici concrete, care corespund artefactelor de implementare și sunt reprezentate prin casete albe.

Caracteristici obligatorii, care au un punct plin deasupra marginii superioare a casetei.

Caracteristici opționale, care au un punct gol deasupra marginii superioare a casetei.

Necesitatea de a selecta doar una dintre caracteristicile copil ale unui anumit părinte (OR exclusiv, XOR sau una din multe). Aceasta este reprezentată printr-un arc gol la marginea inferioară a casetei caracteristicii părinte.

Posibilitatea de a selecta mai multe caracteristici copil ale unui anumit părinte (OR sau unele din multe). Aceasta este reprezentată printr-un arc plin la marginea inferioară a casetei caracteristicii părinte.

Dependențe între caracteristici, reprezentate prin săgeți cu adnotări textuale.

Terminologija | 2020 | 27

191

Diagrama de mai jos prezintă o diagramă tipică de caracteristici, folosind convențiile descrise mai sus:

Fig. 1. Exemplu de reprezentare a caracteristicilor prin diagramă (Sursa: Gargantini 2015)

Un model de caracteristici ar trebui să includă informații suplimentare față de diagramă. Apel et al. (2013: 27) indică posibilitatea de a adăuga următoarele date:

„Descrierea unei caracteristici și a setului de cerințe corespunzător acesteia.

Relația cu alte caracteristici, în special ierarhia, ordinea și gruparea.

Dependențe externe, cum ar fi resursele hardware necesare.

Părțile interesate.

Costul estimat sau măsurat al realizării unei caracteristici.

Etc.”

Dezvoltarea unui model de caracteristici care să reprezinte caracteristicile funcționale ale aplicațiilor software pentru controlul sateliților trebuie să pornească de la o înțelegere clară și de la modelarea conceptelor care alcătuiesc domeniul. În acest scop, activitățile legate de terminologie și terminografie, precum și identificarea termenilor, a conceptelor și a relațiilor dintre acestea, oferă baza pentru construirea modelului vizat.

192

Ricardo Eito Brun

Terminology as the Basis for Building Engineering Feature-based Models

3. METODOLOGIA DE LUCRU

Modelul de caracteristici propus a fost completat urmând acești pași:

Identificarea și revizuirea literaturii de specialitate și academice publicate în acest domeniu. Aceasta presupune căutarea de informații despre abordarea urmată în proiectele aerospațiale conduse de entități precum ESA (European Space Agency) sau NASA (National Aeronautics and Space Administration).

Elaborarea unui glosar pe baza literaturii analizate, prin aplicarea tehnicilor de management terminologic pentru a înregistra informații despre termeni, relațiile dintre aceștia, definițiile identificate în documente și contextul în care sunt utilizați termenii.

Crearea unui model bazat pe caracteristici, care reprezintă funcțiile oferite de aplicațiile software de monitorizare și control al sateliților, folosind glosarul ca bază.

Datele de intrare utilizate pentru identificarea termenilor au inclus un subset de documente tehnice care descriu produsul selectat: manuale de operare, documente de prezentare și materiale de instruire. Modelul de caracteristici este un arbore ierarhic de caracteristici marcate ca obligatorii sau opționale, cu dependențe între acestea. În cazul aplicației software analizate, pe lângă identificarea caracteristicilor opționale și obligatorii, au fost identificate cerințe suplimentare de variabilitate pentru linia de produse. În special, unele dintre funcțiile susținute de software-ul analizat necesită suprascrierea sau personalizarea codului existent. Identificarea acestor cazuri de variabilitate s-a realizat cu sprijinul experților care își desfășoară activitatea în dezvoltarea și personalizarea acestui tip de aplicații software. Pentru a colecta aceste informații, au fost realizate interviuri individuale.

Instrumentul selectat pentru crearea modelului de caracteristici și a diagramelor este FeatureIDE⁵. Acesta este un instrument cu sursă deschisă, bazat pe Java și Eclipse, dezvoltat de personalul de la Otto-von-Guericke-Universität Magdeburg. Cu FeatureIDE, se poate crea un model de caracteristici folosind un editor grafic, se pot marca caracteristicile ca obligatorii, opționale sau abstracte și se poate construi arborele ierarhic. După construirea modelului de caracteristici, se pot crea diferite configurations: selecții de caracteristici care vor fi utilizate pentru a genera aplicația software țintă

⁵ Consultați https://FeatureIDE.github.io/. Ultima verificare: 01-03-2018.

Terminologija | 2020 | 27

193

codul sursă al aplicației. Din păcate, instrumentul nu oferă funcționalități pentru gestionarea termenilor sau a unităților terminologice, ceea ce face necesară utilizarea unor instrumente complementare.

Fig. 2. FeatureIDE (creat de autor)

4. PREZENTAREA REZULTATELOR ȘI DISCUȚII

Această secțiune rezumă o parte a modelului de caracteristici pentru aplicațiile software ale Sistemelor de Control al Misiunii (MCS). Analiza conceptelor extrase din documente a condus la organizarea funcționalităților sistemului în următoarele domenii:

Gestionarea desktopului și a sesiunii, care oferă funcțiile necesare pentru autentificare, începerea unei sesiuni și lansarea diferitelor aplicații. În cazul gestionării mai multor sateliți, utilizatorul va putea comuta între spațiile de lucru ale acestora.

Lanțul de telemetrie, care include procesarea telemetriei, gestionarea alarmelor și afișarea telemetriei.

194

Ricardo Eito Brun

Terminology as the Basis for Building Engineering Feature-based Models

Lanțul de telecomenzi, care include uplinkul telecomenzilor, stiva manuală, stiva programată și istoricul telecomenzilor.

Puntea TT&C/TCR, care oferă vizibilitate și control asupra interfeței cu stația terestră pentru fluxurile de date de telemetrie, comandă, măsurare a distanței (TCR) și de orientare a antenei.

Jurnalul de evenimente, care înregistrează evenimentele identificate în timpul operațiunilor sistemului și le permite operatorilor să parcurgă și să caute în întregul istoric al evenimentelor.

Gestionarea memoriei de la bord, care oferă funcționalități pentru gestionarea (descărcarea, editarea și transmiterea către satelit) a imaginii memoriei navei spațiale.

Analiza documentației și a termenilor a condus la crearea unor modele de caracteristici pentru aceste funcții ale sistemului. Cazul particular al gestionării telemetriei este rezumat ca exemplu. Se poate observa că pentru caracteristicile identificate sunt furnizate definiții bazate pe literatura de specialitate și documentația tehnică existente:

Termenul lanț de telemetrie se referă la diferitele procese implicate în prelucrarea telemetriei: recepția de la TT&C, împachetarea în pachete, arhivarea și distribuirea către aplicațiile consumatoare:

Împachetarea telemetriei. MCS preia pachetele sursă de telemetrie, conforme cu standardul pentru pachetele de telemetrie, adaugă metadate (de exemplu, calitatea fluxului de telemetrie) și le convertește în unul sau mai multe pachete interne de telemetrie MCS. Criteriile de generare a pachetelor din datele de intrare pot varia în funcție de satelit, misiune și protocoalele BBE.

Verificarea calității pachetelor. MCS verifică în permanență calitatea telemetriei, efectuând verificări fie prin intermediul TT&C, fie chiar de către MCS. Metadatele privind calitatea telemetriei sunt adăugate fiecărui pachet intern. În funcție de rezultatul acestor verificări, pachetul poate fi clasificat drept adecvat pentru prelucrare (GOOD) sau neadecvat pentru prelucrare (BAD). În timpul procesului trebuie identificate și pierderile de telemetrie.

O verificare tipică a calității este verificarea secvenței cadrelor, care evaluează dacă cadrele sunt recepționate sau nu în ordine.

Terminologija | 2020 | 27

195

Se generează evenimente în cazul în care aceste verificări nu sunt satisfăcute. Operatorul poate selecta comportamentul care trebuie aplicat atunci când sunt identificate cadre de telemetrie BAD (să fie procesate sau eliminate).

• Verificări ale calității timpului. Aceste verificări stabilesc dacă ora raportată de TT&C pentru fiecare flux de telemetrie și orele locale ale MCS sunt suficient de apropiate. Diferența dintre ora curentă a MCS și marca temporală din cadrul de telemetrie (stabilită de stația terestră la recepționarea cadrului) se încadrează într-o fereastră de timp configurabilă. Dacă aceste verificări eșuează, sunt generate mesaje de eveniment. Verificările calității timpului necesită marcarea temporală a pachetelor de telemetrie.

• Decomutarea telemetriei, care extrage eșantioanele parametrilor de telemetrie din pachete⁶. Aceasta implică extragerea parametrilor, decodarea biților, calibrarea, verificarea depășirii intervalului, verificarea validității și atribuirea datei parametrilor.

○ Extragerea parametrilor de telemetrie localizează și extrage valorile brute ale parametrilor de telemetrie din pachete. Valorile brute sunt, de obicei, numere întregi cu semn sau fără semn ori numere în virgulă mobilă. Acest proces este simplu pentru telemetria fixă, deoarece toate informațiile necesare despre localizarea parametrului sunt disponibile în MIB-ul satelitului, dar este mai complex în cazul telemetriei programabile.

○ Decodarea biților obține valoarea brută din valoarea codificată în pachetul de telemetrie. Într-o situație tipică, valoarea brută corespunde celei codificate în pachet, însă există cazuri în care sunt necesare transformări la nivel de bit (precum inversarea biților sau complementul față de doi) ori la nivel de octet.

○ Parametri derivați sau sintetici. Aceștia nu sunt achiziționați de la nava spațială, ci derivați algoritmic la sol, folosind ca operanzi parametrii de telemetrie achiziționați. Sunt calculați cu formule scrise în limbaje de scripting. Calculul lor are loc înaintea calibrării, a verificărilor de validitate și a atribuirii datei parametrilor.

Un tip special de parametri derivați îl constituie parametrii derivați codificați direct (HCDP), scriși în limbaje de programare de nivel scăzut.

⁶ Parametrii pot fi sincroni (transmiși în telemetrie imediat ce sunt eșantionați la bord) sau asincroni (netransmiși în telemetrie imediat ce sunt eșantionați la bord, ci stocați în memoria de la bord și transmiși ulterior). De regulă, parametrii sunt eșantionați și codificați o dată sau de mai multe ori pentru fiecare format, cu excepția parametrilor subcomutați, care nu sunt eșantionați și codificați în toate formatele, și a parametrilor supracomutați, care sunt eșantionați și codificați de mai multe ori.

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

precum C++, Fortran sau C. Modificarea acestora necesită recompilarea codului sursă.

o Datarea parametrilor de telemetrie atribuie o dată eșantioanelor parametrilor, folosind ora pachetului care le conține și adăugând un decalaj conform specificațiilor din MIB-ul satelitului.

o Controlul depășirii intervalului (OOR) analizează dacă valoarea brută a unui parametru de telemetrie se află în afara intervalului de calibrare definit. Parametrii de telemetrie care depășesc intervalul sunt declarați invalizi, cu categoria OOR. OOR este utilizat pentru a evalua validitatea parametrului de telemetrie și pentru a indica dacă valoarea sa este utilă sau lipsită de sens.

În plus, parametrii care depășesc intervalul trebuie afișați și confirmați de operatori. Alte condiții pentru declararea unui parametru ca invalid includ expirarea parametrului sau, în cazul parametrilor derivați, calcularea acestora folosind parametri invalizi. În orice situație, metadatele privind invaliditatea parametrului de telemetrie trebuie să detalieze motivul acestei stări.

• Calibrarea parametrilor de telemetrie transformă valorile lor brute într-o formă ușor de înțeles de către oameni (valori inginerești sau calibrate, cu unitățile corespunzătoare mărimii fizice). Calibrarea se poate realiza prin diferite metode:

o Calibrare numerică sau discretă liniară: se utilizează interpolarea liniară pe o curbă de calibrare alcătuită din perechi (X, Y), unde X reprezintă valoarea brută, iar Y valoarea inginerească.

o Calibrare textuală, digitală sau de stare: asociază șiruri de text intervalelor valorilor brute ale parametrilor. Valorile textuale pot fi obținute din valori discrete sau dintr-un interval al acestora. Un exemplu simplu este starea ON / OFF a unităților de bord, care poate fi obținută dintr-un parametru de un bit, unde 0 înseamnă OFF, iar 1 înseamnă ON.

o Calibrare polinomială: utilizează un polinom de grad cel mult cinci pentru a transforma valorile brute în valori inginerești.

Fără a intra în detalii suplimentare despre caracteristicile extrase (este descris doar un subset, pentru a arăta că identificarea lor necesită o analiză terminologică riguroasă), diagrama următoare prezintă principalele caracteristici identificate pentru această zonă funcțională:

Terminologija | 2020 | 27

197

Fig. 3. Procesarea TM – Caracteristici Fig. 1: FeatureIDE (creat de autor)

5. CONCLUZII

Această lucrare descrie dezvoltarea unui model de caracteristici pentru aplicații software de control al sateliților, folosind ca intrări documente tehnice (manuale de operare, documente de prezentare și materiale de instruire) care descriu funcționalitățile tipului de sistem studiat. Primul pas constă în

198

Ricardo Eito Brun

Terminology as the Basis for Building Engineering Feature-based Models

identificarea și extragerea termenilor prin examinarea documentelor și identificarea definițiilor acestora în funcție de contextul în care sunt utilizați. Colecția de termeni este apoi analizată pentru a identifica caracteristici, care au fost organizate în modelul și diagrama de caracteristici pe baza criteriilor funcționale, în cadrul a douăsprezece categorii principale: gestionarea sesiunilor, gestionarea conexiunilor cu stațiile terestre, procesarea telemetriei, afișarea datelor de telemetrie, procesarea telecomenzilor, arhiva misiunii etc.

Pentru fiecare domeniu funcțional, descrierea conceptelor principale și a caracteristicilor care trebuie să fie susținute de un sistem software a fost sintetizată și reprezentată în diagrame de caracteristici create cu instrumentul FeatureIDE. Definițiile și contextul de utilizare au constituit, de asemenea, baza pentru stabilirea relațiilor dintre caracteristici și identificarea oportunităților de variabilitate. Au fost identificate trei motive principale pentru variabilitate:

Parametri de configurare specifici misiunii, gestionați de obicei cu ajutorul fișierelor publice de configurare.

Selectarea caracteristicilor opționale, în funcție de tipul misiunii: de exemplu, telecomenzile bazate pe poziție, caracteristice sateliților LEO pentru observarea Pământului.

Personalizarea serviciilor specifice misiunii, care extind serviciile și funcțiile de bază definite în standardele de telemetrie și telecomandă, precum PUS.

Lucrarea demonstrează necesitatea aplicării tehnicilor legate de terminologie pentru a colecta, analiza și documenta semnificația termenilor și pentru a extrage relații care pot fi utilizate ulterior în diferite scopuri. În cazul modelelor de inginerie bazată pe caracteristici, termenii constituie baza pentru descrierea fără ambiguități a funcțiilor software-ului și ale sistemelor și pentru identificarea caracteristicilor sistemelor complexe. Utilizarea consecventă a termenilor este, de asemenea, necesară pentru a asigura că diferiții actori implicați în sarcinile inginerești ulterioare (proiectare, implementare, testare etc.) împărtășesc o înțelegere comună a caracteristicilor sistemului, evitând erorile cauzate de definirea insuficientă a domeniului pe care sistemul este destinat să îl susțină.

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