doi.org/10.35321/term27-08

La terminologia come base per la costruzione di modelli ingegneristici basati sulle feature

RICARDO EITO BRUN

Universidad Carlos III de Madrid

RIASSUNTO

Le operazioni satellitari richiedono l’uso combinato di diversi strumenti per supportare le attività ingegneristiche e controllare il veicolo spaziale. Questa comunicazione è gestita dal Sistema di monitoraggio e controllo (MCS), che riceve i dati telemetrici dal veicolo spaziale e invia telecomandi per mantenere l’assetto e la traiettoria di volo del satellite. Questi sistemi complessi sono sviluppati come piattaforme aperte, estensibili e personalizzabili per soddisfare i requisiti e gli obiettivi specifici della missione. In generale, si può affermare che queste applicazioni software sono adatte all’implementazione strutturata e pianificata di meccanismi di variabilità e che le loro funzionalità sono adatte ad analizzare la fattibilità dell’applicazione di tecniche di modellazione basate sulle feature. Questo articolo descrive l’uso dell’analisi terminologica per costruire un modello delle feature a supporto dell’analisi dei requisiti per questo tipo di sistemi software.

PAROLE CHIAVE: terminologia tecnica, modelli basati sulle feature, ingegneria aerospaziale, estrazione terminologica

ANNOTAZIONE

Le operazioni satellitari richiedono diversi strumenti per garantire il regolare svolgimento delle attività ingegneristiche e controllare il veicolo spaziale. Questa comunicazione è gestita dal Sistema di monitoraggio e controllo (SKS), che riceve i dati telemetrici dal veicolo spaziale e invia telecomandi per mantenere l’assetto e la traiettoria orbitale del satellite. Questi sistemi complessi sono progettati come piattaforme aperte, estensibili e adattabili ai requisiti e agli obiettivi specifici della missione. Si può affermare che, in generale, queste applicazioni possono essere utilizzate per implementare meccanismi di variabilità in modo strutturato e pianificato, e che le loro funzionalità consentono di analizzare le possibilità di applicazione delle metodologie di modellazione delle feature. Questo articolo descrive l’impiego dell’analisi terminologica per creare un modello delle feature che supporti l’analisi dei requisiti per questo tipo di sistemi software.

PAROLE CHIAVE: terminologia tecnica, modelli delle feature, ingegneria aerospaziale, riconoscimento dei termini

186

Ricardo Eito Brun

Terminology as the Basis for Building Engineering Feature-based Models

1. INTRODUZIONE

Il glossario della NASA definisce i satelliti come: “un oggetto a volo libero che orbita attorno alla Terra, a un altro pianeta o al Sole.” I satelliti sono un tipo di veicolo spaziale che percorre un’orbita regolare e chiaramente definita attorno al centro di gravità di un altro corpo celeste (Garner 1996: 4). Dal lancio dei primi satelliti artificiali – Sputnik 1 il 4 ottobre^th 1957 ed Explorer 1 il 31 gennaio^st 1958, sono state lanciate numerose missioni satellitari con finalità diverse: esplorazione astronomica, fornitura di servizi di comunicazione e navigazione, osservazione della Terra, ricognizione e missioni scientifiche. I satelliti sono complessi sistemi aerospaziali costituiti da elementi terrestri e spaziali: il veicolo spaziale deve essere gestito da un elemento di controllo sulla Terra e mantenersi in contatto con esso. Oggi il progresso scientifico e i servizi per gli utenti dipendono dai satelliti e dalle costellazioni satellitari. Tra gli esempi pertinenti figurano il Telescopio spaziale Hubble (HST), sistemi di navigazione come il GPS (Global Positioning System), GLONASS e il Galileo europeo, UARS (Upper Atmosphere Research Satellite) o GOES (Geostationary Operational Environment Satellite). Il numero complessivo di satelliti lanciati dal 1957 – secondo il catalogo SSN degli Stati Uniti² – è vicino a 18200; l’Indice degli oggetti lanciati nello spazio extra-atmosferico del 2017 dell’UNOOSA segnala 4635 satelliti attualmente in orbita attorno al pianeta, con un incremento di 357 satelliti (8.95%) rispetto all’anno precedente³. Lo scopo di questo articolo è dimostrare la necessità di applicare la gestione e l’estrazione della terminologia per sostenere lo sviluppo di modelli basati sulle funzionalità e organizzare i concetti che descrivono le funzioni delle applicazioni software utilizzate per il monitoraggio e il controllo dei satelliti.

I satelliti sono classificati in base alla finalità e al tipo di orbita. La finalità si riferisce ai servizi che il satellite è destinato a fornire. Per quanto riguarda l’orbita, si distingue tra orbita terrestre bassa (LEO), orbita terrestre media (MEO) e orbita geostazionaria (GEO). I satelliti LEO – utilizzati per la scienza e l’osservazione della Terra – seguono un’orbita ellittica; poiché la loro visibilità dalle stazioni terrestri è limitata, i dati vengono memorizzati a bordo e inviati a terra

¹ Vedere https://www.grc.nasa.gov/www/k-12/TRC/laefs/laefs_s.html#satellite [consultato il 2020-08-01].

² La Rete di sorveglianza spaziale degli Stati Uniti è responsabile del rilevamento, del tracciamento, della catalogazione e dell’identificazione degli oggetti artificiali in orbita attorno alla Terra. Il catalogo è disponibile all’indirizzo: https://www.space-track.org/#/ssr [consultato il 2020-08-01].

³ Ufficio delle Nazioni Unite per gli affari dello spazio extra-atmosferico. Vedere https://www.pixalytics.com/sats-orbiting-earth-2017/

Terminologija | 2020 | 27

187

le stazioni quando il veicolo spaziale diventa visibile. I satelliti GEO sono utilizzati per le telecomunicazioni e per finalità meteorologiche; i satelliti per telecomunicazioni ricevono segnali a radiofrequenza (RF) dalla Terra, li amplificano, ne spostano la frequenza e li ritrasmettono verso la Terra. Orbitano a 36000 km sopra l’Equatore (sullo stesso piano) e la loro rotazione è sincrona con quella della Terra, rimanendo sempre sopra lo stesso punto dell’Equatore)⁴. Analogamente ai satelliti, anche le missioni scientifiche nello spazio profondo necessitano di attività analoghe di monitoraggio e controllo per l’invio di telecomandi e la ricezione di telemetria.

Le missioni satellitari richiedono personale dedicato che svolga il monitoraggio in tempo reale e continuo dello stato e della posizione del satellite. Il controllo della missione comprende l’insieme delle attività eseguite dopo il lancio dagli ingegneri operativi con l’ausilio di applicazioni software e comporta lo scambio di dati tra il segmento di terra e quello spaziale per monitorare e controllare lo stato dei sottosistemi di bordo del satellite. Nelle missioni scientifiche è inoltre necessario ricevere le informazioni dal carico utile del satellite e trasmetterle agli utenti finali (la comunità scientifica). Le funzioni tipiche svolte durante il controllo della missione comprendono la ricezione e l’analisi della telemetria, l’invio di telecomandi e il tracciamento. La telemetria consiste nei dati trasmessi dal satellite alla Terra che ne indicano lo stato e le condizioni, insieme a quelli dei suoi sottosistemi. I telecomandi sono gli ordini trasmessi da terra al veicolo spaziale per configurarlo e gestirlo. (Uhlig, Sellmaier, and Schmidhuber 2015: 232). Il tracciamento e il mantenimento della posizione orbitale, noto anche come misura della distanza, consistono nel monitoraggio e nella determinazione della traiettoria di volo e della posizione mediante tecniche e segnali RF.

Dal punto di vista dell’ingegneria del software, il controllo dei satelliti richiede diverse applicazioni e strumenti per la dinamica di volo, la pianificazione della missione, la telemetria e l’invio di telecomandi, il controllo e l’instradamento della rete, nonché interfacce tra di essi. Questa complessità ha portato le agenzie spaziali a fornire soluzioni diverse. Una delle tappe più significative nello sviluppo del software MCS è stata la decisione del dipartimento Ground Systems Engineering dell’ESA di sviluppare e concedere in licenza all’industria europea una serie di applicazioni software distribuite con il nome MICONYS^®

⁴ I satelliti GEO sono distribuiti in un’area limitata dello spazio. Le posizioni orbitali sono assegnate dall’Unione internazionale delle telecomunicazioni (ITU) per evitare collisioni, un rischio legato al problema dei detriti spaziali, che oggi riceve maggiore attenzione.

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

(Sistema di controllo della missione). MICONYS e il suo componente SCOS-2000® sono probabilmente gli esempi più noti della politica dell’ESA in materia di sviluppo software, innovazione e trasferimento tecnologico (Kaufeler, Jones and Karl 2001). SCOS-2000 supporta l’invio di telecomandi, la ricezione della telemetria, la visualizzazione e l’archiviazione. SCOS-2000 è il risultato dell’esperienza acquisita dall’ESA nello sviluppo e nell’esercizio di sistemi analoghi precedenti: MSSS, SCOS-1 e SCOS-2. Oggi l’ESA sta sviluppando il nuovo sistema MCS, destinato a sostituire SCOS-2000 in futuro. Il suo nome è European Ground Systems – Common Core (EGS-CC). Come SCOS, il progetto ha lo scopo di sviluppare un’infrastruttura comune a supporto del monitoraggio e del controllo delle missioni spaziali nelle fasi pre- e post-lancio, utilizzando tecnologie moderne e architetture orientate ai servizi (Peccioli et al. 2012). Lo sviluppo di EGS-CC non è responsabilità esclusiva dell’ESA: le agenzie spaziali nazionali europee (CNES, UK Space Agency e DLR) e le aziende industriali (AIRBUS Defence and Space, Thales Alenia Space e OHB Systems) partecipano al progetto.

Oltre ai progetti dell’ESA, esistono altre iniziative volte a sviluppare un sistema software MCS generico. La NASA ha portato a termine progetti analoghi, per la maggior parte sviluppati internamente. Il Goddard Space Flight Centre ha sviluppato due sistemi, ITOS e ASIST, per la gestione di missioni come 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) o LRO (Lunar Reconnaissance Orbiter) (Pfarr et al. 2007).

In tutti questi casi, ci troviamo di fronte a un sistema complesso che deve implementare diverse funzioni, attivabili o meno a seconda delle caratteristiche del satellite e della missione. Per questo motivo, questi sistemi software-intensive sono adatti allo sviluppo mediante tecniche di product-line e di modellazione basata sulle funzionalità, che si fondano su un’organizzazione chiara e ben strutturata dei concetti per comprendere il dominio e le capacità richieste al sistema.

2. MODELLAZIONE BASATA SULLE FUNZIONALITÀ

COME ORGANIZZAZIONE DEI CONCETTI

La modellazione basata sulle funzionalità è una delle tecniche applicate nell’ingegneria delle software product-line, una disciplina volta a realizzare programmi software riutilizzabili, divenuta popolare alla fine degli anni Novanta. SPLE si propone di

Terminologija | 2020 | 27

189

realizzare componenti e artefatti riutilizzabili che possano essere successivamente combinati per creare prodotti adeguati alle esigenze di uno specifico cliente e contesto. Le esperienze nell’ambito della SPLE sono ampiamente documentate nella letteratura professionale e accademica. Capilla (2013) ha presentato diversi casi di studio in cui la SPLE è stata applicata con successo: i programmi avionici Boeing’s operativi e critici per la missione, destinati alle funzioni di avionica e cockpit, il software Bosch’s di controllo motore per i sistemi a benzina, il software Hewlett Packard’s per stampanti, le apparecchiature Toshiba’s per la generazione e la trasmissione di energia e il software General Motors’ di controllo dei gruppi propulsori. Secondo Apel et al. (2013: 9), i vantaggi delle software product-line (SPL) comprendono l’adattamento dei prodotti software alle esigenze specifiche dei clienti, la riduzione dei costi — poiché un insieme di risorse riutilizzabili può essere combinato in modi diversi per generare nuovi prodotti —, il miglioramento della qualità e la riduzione del time-to-market.

Le funzionalità e la modellazione basata sulle funzionalità sono concetti rilevanti nello sviluppo delle SPL. La norma ISO/IEC/IEEE 24765:2010, Systems and software engineering — Vocabulary, offre una definizione generale di features, ripresa da IEEE Std 829:2008 IEEE Standard for Software and System Test Documentation: “Una caratteristica distintiva di un elemento del sistema. NOTA: include attributi sia funzionali sia non funzionali, quali le prestazioni e la riutilizzabilità.” Kang e Lee (2013, 28) definiscono le funzionalità come “concetti astratti che supportano efficacemente la comunicazione tra i diversi stakeholder di una product-line e che, pertanto, costituiscono un modo naturale e intuitivo per esprimere la comunanza e la variabilità delle product-line in termini di funzionalità.”

Le funzionalità svolgono ruoli diversi nel processo di ideazione e sviluppo del prodotto. Sono strumenti per comunicare le caratteristiche del prodotto e supportare l’identificazione dei requisiti; sono inoltre i concetti che guidano le decisioni di progettazione e implementazione.

Lo sviluppo di una product-line comprende due cicli di vita complementari:

• Ingegneria di dominio, e

• Ingegneria delle applicazioni.

La norma IEEE 1517-2010 definisce l’ingegneria di dominio come: “Ciclo di vita costituito da un insieme di processi per specificare e gestire la comunanza e la variabilità di una product-line. L’ingegneria di dominio analizza il dominio di una product-line e sviluppa un insieme di artefatti riutilizzabili. Questi artefatti comprendono requisiti software, elementi di progettazione, casi di test e

190

Ricardo Eito Brun

Terminology as the Basis for Building Engineering Feature-based Models

procedure, documentazione utente, ecc. L’analisi del dominio può essere considerata una sorta di ingegneria dei requisiti per l’intera linea di prodotti, compresa l’identificazione della variabilità prevista. Il principale artefatto generato dall’analisi del dominio è il modello delle funzionalità, che specificherà e descriverà i prodotti della linea.

La modellazione delle funzionalità è una tecnica diagrammatica introdotta negli anni Novanta con la metodologia FODA (Feature-Oriented Domain Analysis). FODA ha fornito primitive per rappresentare relazioni strutturali (composizione, generalizzazione e specializzazione), opzionalità, alternative e dipendenze reciproche. In seguito è stata riesaminata da diversi autori (Kang e Lee 2013: 30–31). I diagrammi delle funzionalità sono la rappresentazione visiva dei modelli delle funzionalità, nei quali le funzionalità sono rappresentate da riquadri disposti in un albero gerarchico. A ciascun nodo è associata un’etichetta con il nome della funzionalità. La disposizione gerarchica delle funzionalità crea relazioni genitore-figlio. Se viene selezionata una funzionalità figlia, deve essere selezionato anche il suo genitore. I diagrammi possono distinguere tra funzionalità obbligatorie e facoltative e identificare le combinazioni di funzionalità valide.

In particolare, i diagrammi delle funzionalità possono rappresentare:

Funzionalità astratte, utilizzate per organizzare le funzionalità nell’albero, ma non associate ad artefatti di implementazione. Sono rappresentate con riquadri grigi.

Funzionalità concrete, corrispondenti ad artefatti di implementazione e rappresentate con riquadri bianchi.

Funzionalità obbligatorie, contrassegnate da un punto pieno sopra il bordo superiore del riquadro.

Funzionalità facoltative, contrassegnate da un punto vuoto sopra il bordo superiore del riquadro.

La necessità di selezionare una sola delle funzionalità figlie di un determinato genitore (OR esclusivo, XOR o una su molte). È rappresentata da un arco vuoto sul bordo inferiore del riquadro della funzionalità genitore.

La possibilità di selezionare più di una funzionalità figlia di un determinato genitore (OR oppure alcune su molte). È rappresentata da un arco pieno sul bordo inferiore del riquadro della funzionalità genitore.

Dipendenze tra funzionalità, rappresentate da frecce con annotazioni testuali.

Terminologija | 2020 | 27

191

Il diagramma seguente mostra un diagramma delle funzionalità tipico, con le convenzioni descritte sopra:

Fig. 1. Esempio di diagramma delle funzionalità (Fonte: Gargantini 2015)

Un modello delle funzionalità dovrebbe includere informazioni aggiuntive rispetto al diagramma. Apel et al. (2013: 27) indicano la possibilità di aggiungere i seguenti dati:

«Descrizione di una funzionalità e del relativo insieme di requisiti.

Relazione con le altre funzionalità, in particolare gerarchia, ordine e raggruppamento.

Dipendenze esterne, come le risorse hardware necessarie.

Stakeholder interessati.

Costo stimato o misurato della realizzazione di una funzionalità.

Ecc.

Lo sviluppo di un modello delle funzionalità per rappresentare le caratteristiche funzionali delle applicazioni software per il controllo satellitare deve partire da una chiara comprensione e modellizzazione dei concetti che costituiscono il dominio. A tal fine, le attività relative alla terminologia e alla terminografia, all’identificazione dei termini, dei concetti e delle loro relazioni forniscono la base per costruire il modello desiderato.

192

Ricardo Eito Brun

Terminology as the Basis for Building Engineering Feature-based Models

3. METODOLOGIA DI LAVORO

Il modello delle funzionalità proposto è stato completato seguendo i passaggi seguenti:

Identificazione e revisione della letteratura professionale e accademica pubblicata in questo ambito. Ciò comporta la ricerca di informazioni sull’approccio seguito nei progetti aerospaziali condotti da enti come ESA (European Space Agency) o NASA (National Aeronautics and Space Administration).

Elaborazione di un glossario basato sulla letteratura analizzata, applicando tecniche di gestione terminologica per registrare informazioni sui termini, sulle relazioni tra essi, sulle definizioni individuate nei documenti e sul contesto in cui vengono utilizzati.

Creazione di un modello basato sulle funzionalità che rappresenti le funzioni offerte dalle applicazioni software di monitoraggio e controllo dei satelliti, utilizzando il glossario come base.

Gli input utilizzati per identificare i termini includevano un sottoinsieme di documenti tecnici che descrivono il prodotto selezionato: manuali operativi, white paper e materiali didattici. Il modello delle funzionalità è un albero gerarchico di funzionalità contrassegnate come obbligatorie o facoltative, con dipendenze tra di esse. Nel caso dell’applicazione software oggetto di analisi, oltre all’identificazione delle funzionalità facoltative e obbligatorie, sono stati individuati ulteriori requisiti di variabilità della linea di prodotti. In particolare, alcune delle funzioni supportate dal software analizzato richiedono la sovrascrittura o la personalizzazione del codice esistente. L’identificazione di questi casi di variabilità è stata effettuata con il supporto di esperti che svolgono la propria attività nello sviluppo e nella personalizzazione di questo tipo di applicazioni software. Sono state condotte interviste personali per raccogliere queste informazioni.

Lo strumento selezionato per creare il modello delle funzionalità e i diagrammi è FeatureIDE⁵. Si tratta di uno strumento open source basato su Java ed Eclipse, sviluppato dal personale della Otto-von-Guericke-Universität Magdeburg. Con FeatureIDE è possibile creare un modello delle funzionalità utilizzando un editor grafico, contrassegnare le funzionalità come obbligatorie, facoltative o astratte e costruire l’albero gerarchico. Una volta creato il modello delle funzionalità, è possibile creare diverse configurazioni: selezioni di funzionalità che saranno utilizzate per generare l’applicazione software di destinazione

⁵ Vedi https://FeatureIDE.github.io/. Ultima verifica: 01-03-2018.

Terminologija | 2020 | 27

193

Il codice sorgente della funzione. Purtroppo, lo strumento non offre funzionalità per gestire termini o unità terminologiche, rendendo necessario l’uso di strumenti complementari.

Fig. 2. FeatureIDE (creato dall’autore)

4. PRESENTAZIONE DEI RISULTATI E DISCUSSIONE

Questa sezione riassume una parte del modello delle funzionalità per le applicazioni software dei sistemi di controllo missione (MCS). L’analisi dei concetti estratti dai documenti ha portato a organizzare le funzionalità del sistema nelle seguenti aree:

Gestione del desktop e delle sessioni, che fornisce le funzioni per accedere, avviare una sessione e lanciare le diverse applicazioni. Nel caso della gestione di più satelliti, l’utente può passare da uno spazio di lavoro all’altro dei satelliti.

Catena di telemetria, che comprende l’elaborazione della telemetria, il gestore degli allarmi e la visualizzazione della telemetria.

194

Ricardo Eito Brun

Terminology as the Basis for Building Engineering Feature-based Models

Catena dei telecomandi, che comprende l’invio dei telecomandi, la coda manuale, la coda pianificata e la cronologia dei telecomandi.

Bridge TT&C/TCR, che fornisce visibilità e controllo sull’interfaccia con la stazione di terra per i flussi di dati di telemetria, comando, ranging (TCR) e puntamento dell’antenna.

Registro degli eventi, che registra gli eventi identificati durante le operazioni del sistema e consente agli operatori di consultare e cercare l’intera cronologia degli eventi.

Gestione della memoria di bordo, che offre strumenti per gestire (scaricare, modificare e caricare) l’immagine della memoria del veicolo spaziale.

L’analisi della documentazione e dei termini ha portato alla creazione di modelli delle funzionalità per queste funzioni del sistema. Il caso particolare della gestione della telemetria è riassunto a titolo di esempio. Si può osservare come alle funzionalità identificate siano associate definizioni basate sulla letteratura esistente e sulla documentazione tecnica:

Il termine catena di telemetria si riferisce ai diversi processi coinvolti nell’elaborazione della telemetria: ricezione dal TT&C, formazione dei pacchetti, archiviazione e distribuzione alle applicazioni utilizzatrici:

Formazione dei pacchetti di telemetria. L’MCS acquisisce i pacchetti sorgente di telemetria conformi allo standard per i pacchetti di telemetria, aggiunge metadati (ad es. la qualità del flusso di telemetria) e li converte in uno o più pacchetti interni di telemetria dell’MCS. I criteri per generare pacchetti dai dati in ingresso possono variare in base al satellite, alla missione e ai protocolli BBE.

Controllo della qualità dei pacchetti. L’MCS verifica continuamente la qualità della telemetria mediante controlli eseguiti dal TT&C o dall’MCS stesso. A ogni pacchetto interno vengono aggiunti metadati sulla qualità della telemetria. In base all’esito di tali controlli, il pacchetto può essere classificato come idoneo all’elaborazione (GOOD) o non idoneo all’elaborazione (BAD). Durante il processo devono essere rilevate anche le perdite di telemetria.

Un controllo tipico della qualità è il controllo della sequenza dei frame, che valuta se i frame sono ricevuti in sequenza oppure no.

Terminologija | 2020 | 27

195

Vengono generati eventi quando questi controlli non vengono superati. L’operatore può selezionare il comportamento da applicare quando vengono identificati frame di telemetria BAD (elaborarli o scartarli).

• Controlli di qualità temporale. Questi controlli verificano che l’ora riportata dal TT&C per ciascun flusso di telemetria e gli orari locali dell’MCS non differiscano eccessivamente. La differenza tra l’ora corrente dell’MCS e il riferimento temporale nel frame di telemetria (impostato dalla stazione di terra al momento della ricezione del frame) rientra in una finestra temporale configurabile. Se questi controlli non vengono superati, vengono generati messaggi di evento. I controlli di qualità temporale richiedono l’apposizione di timestamp ai pacchetti di telemetria.

• Decommutazione della telemetria, che estrae dai pacchetti i campioni dei parametri di telemetria⁶. Comprende l’estrazione dei parametri, la decodifica dei bit, la calibrazione, il controllo dei valori fuori intervallo, il controllo di validità e l’attribuzione della data ai parametri.

○ Estrazione dei parametri di telemetria individua ed estrae dai pacchetti i valori grezzi dei parametri di telemetria. I valori grezzi sono generalmente interi con segno o senza segno, oppure numeri in virgola mobile. Questo processo è semplice per la telemetria fissa, poiché tutte le informazioni necessarie sulla posizione del parametro sono disponibili nella MIB del satellite, ma è più complesso nel caso della telemetria programmabile.

○ Decodifica dei bit ricava il valore grezzo dal valore codificato nel pacchetto di telemetria. In una situazione tipica, il valore grezzo corrisponde a quello codificato nel pacchetto, ma in alcuni casi è necessaria una trasformazione basata sui bit (come l’inversione dei bit o il complemento a due) o sui byte.

○ Parametri derivati o sintetici. Non sono acquisiti dal veicolo spaziale, ma derivati algoritmicamente a terra usando come operandi parametri di telemetria acquisiti. Sono calcolati mediante formule scritte in linguaggi di scripting. Il calcolo avviene prima della calibrazione, dei controlli di validità e dell’attribuzione della data ai parametri.

Un tipo speciale di parametro derivato è costituito dai parametri derivati codificati direttamente nel codice (HCDP), scritti in linguaggi di programmazione di basso livello.

⁶ I parametri possono essere sincroni (inviati a terra tramite telemetria non appena vengono campionati a bordo) oppure asincroni (non inviati a terra tramite telemetria non appena vengono campionati a bordo, ma memorizzati nella memoria di bordo e trasmessi successivamente). I parametri vengono generalmente campionati e codificati una o più volte per formato, fatta eccezione per i parametri sottocommutati, che non vengono campionati e codificati in tutti i formati, e per i parametri sovracommutati, che vengono campionati e codificati più volte.

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

come C++, Fortran o C. La loro modifica richiede la ricompilazione del codice sorgente.

o Datazione dei parametri di telemetria assegna una data ai campioni dei parametri, utilizzando l’ora del pacchetto che li contiene e aggiungendo un offset come specificato nel MIB del satellite.

o Controllo dei valori fuori intervallo (OOR) analizza se il valore grezzo di un parametro di telemetria è al di fuori dell’intervallo di calibrazione definito. I parametri di telemetria fuori intervallo sono dichiarati non validi con la categoria OOR. OOR viene utilizzato per valutare la validità del parametro di telemetria e per indicare se il suo valore è utile o privo di significato.

Inoltre, i parametri fuori intervallo devono essere visualizzati e confermati dagli operatori. Altre condizioni per dichiarare non valido un parametro includono: il parametro è scaduto oppure, nel caso di parametri derivati, è stato calcolato utilizzando parametri non validi. In ogni caso, i metadati relativi all’invalidità del parametro di telemetria devono specificare il motivo di tale stato.

• Calibrazione dei parametri di telemetria trasforma i loro valori grezzi in una forma leggibile dall’uomo (valori ingegneristici o calibrati, con le unità corrispondenti alla grandezza fisica). La calibrazione può essere effettuata con metodi diversi:

o Calibrazione numerica o lineare discreta: si utilizza l’interpolazione lineare a partire da una curva di calibrazione composta da coppie (X, Y), dove X rappresenta il valore grezzo e Y il valore ingegneristico.

o Calibrazione testuale, digitale o di stato: associa stringhe di testo agli intervalli dei valori grezzi dei parametri. I valori testuali possono essere ottenuti da valori discreti o da un loro intervallo. Un semplice esempio è lo stato ON / OFF delle unità di bordo, che potrebbe essere ricavato da un parametro a un bit, in cui 0 significa OFF e 1 significa ON.

o Calibrazione polinomiale: utilizza un polinomio fino al quinto grado per convertire i valori grezzi in valori ingegneristici.

Senza entrare nei dettagli delle funzionalità estratte (ne viene descritto solo un sottoinsieme per mostrare come la loro identificazione richieda un’accurata analisi terminologica), il diagramma seguente presenta le principali funzionalità identificate per quest’area funzionale:

Terminologija | 2020 | 27

197

Fig. 3. Elaborazione TM – Funzionalità Fig 1: FeatureIDE (creato dall’autore)

5. CONCLUSIONI

Questo articolo descrive lo sviluppo di un modello delle funzionalità per applicazioni software di controllo satellitare, utilizzando come input documenti tecnici (manuali operativi, white paper e materiali formativi) che descrivono le funzionalità del tipo di sistema oggetto di studio. Il primo passo consiste nell’

198

Ricardo Eito Brun

Terminology as the Basis for Building Engineering Feature-based Models

identificazione ed estrazione dei termini attraverso l’esame dei documenti, individuando le relative definizioni tramite il contesto in cui vengono applicati. Questa raccolta di termini viene ulteriormente analizzata per identificare le funzionalità, che sono state disposte nel modello e nel diagramma delle funzionalità secondo criteri funzionali, all’interno di dodici categorie principali: gestione delle sessioni, gestione della connessione con la stazione di terra, elaborazione della telemetria, visualizzazione dei dati di telemetria, elaborazione dei telecommandi, archivio di missione, ecc.

Per ciascuna area funzionale, la descrizione dei concetti principali e delle caratteristiche che un sistema software deve supportare è stata sintetizzata e rappresentata in diagrammi delle funzionalità creati con lo strumento FeatureIDE. Le definizioni e il contesto d’uso sono stati anche la base per stabilire le relazioni tra le funzionalità e individuare le opportunità di variabilità. Sono state identificate tre ragioni principali di variabilità:

Parametri di configurazione specifici della missione, generalmente gestiti tramite file di configurazione pubblici.

Selezione di funzionalità opzionali, a seconda del tipo di missione: ad es., telecommandi basati sulla posizione, caratteristici dei satelliti LEO per l’osservazione della Terra.

Personalizzazione dei servizi specifici della missione, che estendono i servizi e le funzioni di base definiti negli standard di telemetria e telecommandi, come il PUS.

Il lavoro dimostra la necessità di applicare tecniche terminologiche per raccogliere, analizzare e documentare il significato dei termini e per estrarre relazioni che possano essere successivamente utilizzate per scopi diversi. Nei modelli di ingegneria basati sulle funzionalità, i termini costituiscono la base per descrivere senza ambiguità le funzioni del software e dei sistemi e per identificare le caratteristiche dei sistemi complessi. È inoltre necessario usare i termini in modo coerente per garantire che i diversi agenti coinvolti nelle successive attività di ingegneria (progettazione, implementazione, collaudo, ecc.) condividano una comprensione comune delle funzionalità del sistema, evitando errori causati da una definizione inadeguata del dominio che il sistema è destinato a supportare.

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