Una scheda NI per leggere la 'scatola nera' del Tornado

Author(s):
F. Lanzillota - GALILEO AVIONICA

Industry:
Aerospace/Avionics

Products:
Data Acquisition, LabVIEW, LabWindows/CVI

The Challenge:
Interfacciare un apparato tecnologicamente obsoleto, ma ancora in uso, con un PC commerciale. Questo obiettivo doveva essere raggiunto in modo rapido ed economico.

The Solution:
E' stata individuata la scheda di acquisizione digitale NI PCI-6534 che è risultata sufficientemente flessibile per l'applicazione. E' inoltre stato utilizzato un software 'template' abbinato alla scheda stessa; tale software, con i dovuti adattamenti, è diventato il driver di acquisizione dei dati.

Breve riassunto
Il rifacimento di un sistema di acquisizione ed elaborazione dati per una delicata applicazione militare si presentava in termini spinosi; la natura del problema lasciava presagire tempi e costi di sviluppo notevoli, incompatibili con il requisito commerciale. La ricerca dei mezzi e dei modi adeguati per affrontare al meglio il problema ha portato alla individuazione di una scheda National Instruments e a diversi esempi di programmi per controllare da PC la scheda stessa. L'elevata flessibilità della scheda, unita alla possibilità di modificare il software di esempio per adeguarlo alla specifica esigenza, ha ridotto notevolmente il problema tecnico originario. Da una situazione complessa si è passati ad una situazione relativamente lineare.

Articolo
Il Tornado è stato il primo velivolo militare italiano a disporre, fin dal suo apparire sullo scenario europeo, di un sistema d'acquisizione di parametri di volo e di memorizzazione degli stessi su un supporto orientato al crash recorder; tale supporto è costituito dalla cosiddetta scatola nera o, per usare la sigla ufficiale, dall'ADR (Accident Data Recorder).
Si parla di tecnologia datata anni 70-80 e concepita secondo il criterio del 'tanto più semplice, tanto più affidabile', almeno per quel che riguarda le apparecchiature di bordo.
Da un punto di vista contemporaneo, l'ADR appare come un'unità piuttosto rudimentale: a parte l'involucro corazzato e l'apparato di trascinamento, il cuore del sistema è costituito da un anello di nastro magnetico, in cui i dati più recenti sovrascrivono quelli più antichi, mantenendo la registrazione delle due ultime ore di volo. Non esiste né un inizio né una fine in quest'anello perpetuo che, sia in scrittura sia in lettura, gira sempre in un verso e non consente alcun riferimento assoluto. Le informazioni sono costituite da un flusso seriale di bit individuali, in cui non esiste il concetto di byte, di word né di altra aggregazione formale fra i bit stessi. Il protocollo che regola lo scambio dei comandi e dei dati è lineare ma del tutto fuori standard.
In questa sede, trattandosi tra l’altro d'argomenti che riguardano apparati militari, non è necessario né opportuno scendere troppo in dettagli tecnici. Si può solo dire che la relativa semplicità dell'hardware preposto alla registrazione si risolve in complicazioni notevoli quando i dati devono essere riletti e ricostruiti nella loro sequenza temporale.
Le stazioni di terra originariamente in dotazione all'Aeronautica Militare, anch'esse risalenti alla protostoria informatica degli anni 80, necessitavano di un monumentale hardware ad hoc e di un software minimale (molto specializzato e realizzato in linguaggio Assembler) per gestire minuziosamente l'acquisizione fisica dei dati registrati sulla ADR e poter ricostruire correttamente, dopo una serie di manipolazioni, le informazioni secondo le esigenze degli investigatori. A quei tempi il peso relativo tra hardware e software era nettamente a vantaggio del primo.
Con il passare del tempo le vecchie stazioni, dopo anni di onorato servizio, sono ormai tutte diventate inesorabilmente e definitivamente inefficienti; una lunga serie di riparazioni acrobatiche e di cannibalizzazioni si è ormai esaurita per impossibilità a procedere. In un contesto così delicato si possono intuire i rischi per l’Ente militare nel malaugurato, ma sempre possibile, caso di incidente.
Per questi motivi, nell'ambito di un programma di ammodernamento complessivo del Tornado, la Forza Armata ha commissionato alla Galileo Avionica nuove stazioni di terra per sostituire le vecchie. Gli apparati di bordo, inclusa l'ADR, sono invece rimasti immutati e tali resteranno per chissà quanti anni ancora.
Il target da perseguire era:

-contenere i costi al di sotto di un tetto prefissato
-ottenere un prodotto affidabile in tempi limitati
-garantire la mantenibilità del prodotto per almeno i prossimi dieci anni
-aggiungere alle prestazioni base delle vecchie stazioni ulteriori funzioni ad  esempio  animazioni 2D/3D, trattamento della traccia audio, ecc.
-tentare di riciclare, per motivi di economia, moduli software scritti in Visual Basic per un progetto analogo

Il problema a carico del malcapitato sistemista della Galileo Avionica sembrava essere una specie di quadratura del cerchio: interfacciare un mondo arcaico (lontano almeno cinque generazioni, tecnologicamente parlando) con un mondo moderno. Il tutto naturalmente tenendo conto dei vincoli di budget e di tempi di realizzazione.
Delle apparecchiature ad hoc citate sopra era stata persa ogni memoria, anche da parte delle stesse Ditte costruttrici, e non era pensabile, né dal punto di vista economico né da quello temporale, imbarcarsi in un'opera di riprogettazione di apparati equivalenti.
Sullo sviluppo del software arieggiava la tetra prospettiva di dover produrre dal nulla un driver dedicato per gestire in dettaglio l’interfaccia fra PC e ADR, con tutti i conseguenti problemi di documentazione, di testing, di controllo qualità, ecc. Come sarebbe stato apprezzato un volgare protocollo standard!
Comunque, l'ipotesi di partenza, quasi obbligatoria, è stata quella di utilizzare apparati commerciali: Personal Computer e schede general purpose di acquisizione digitale.

Un rapido sondaggio fra le esperienze esistenti in Galileo Avionica ha portato a sfogliare il catalogo della National Instruments. In tale catalogo figurano diverse schede Data Acquisition che in prima istanza sembravano sufficientemente flessibili e forse in grado di adattarsi allo specifico problema.
E’ stata contattata la National Instruments per un incontro interlocutorio di tipo tecnico-commerciale.
La risposta da parte del funzionario commerciale della NI è stata eccellente: dopo aver prospettato alcune soluzioni, ciascuna con le proprie caratteristiche di costo/prestazioni, è stato addirittura offerto il supporto tecnico per effettuare alcune prove pratiche e verificare l'adeguatezza delle schede ‘papabili’.
Detto fatto, è stato improvvisato un prototipo hardware presso il laboratorio della Galileo Avionica utilizzando le schede messe a disposizione per le prove, mentre l’ottimo ingegnere della NI adattava rapidamente uno tanti template software in linguaggio LabView disponibili per la gestione di ciascuna delle schede.
Con sole poche ore di lavoro integrato è stato possibile appurare la concretezza delle ipotesi di partenza: con un comune PC commerciale si è riusciti a controllare una ADR e ad acquisirne il contenuto informativo senza perdite né errori.
Certo, questo è stato solo l’inizio di tutta una serie di lavori successivi però, quello che sembrava lo scoglio principale del sistema si è rivelato un problema risolvibile in modo relativamente lineare e rapido. Questo grazie ad una scheda oculatamente selezionata, ad un template software facilmente personalizzabile e, non ultimo, al prezioso supporto dell’ingegnere della NI.
I fatti sopra riportati risalgono a pochi mesi fa. Ora le nuove stazioni stanno per essere consegnate al Cliente finale, abbastanza in linea con i tempi e i costi preventivati.

Per marcare i punti salienti di questa esperienza con la National Instruments, si precisano alcuni dettagli:
• la scheda di acquisizione utilizzata è la NI PCI-6534
• il sistema operativo è Microsoft Windows XP su piattaforma Workstation HP xv4300
• il template LabView utilizzato per le prove iniziali è stato personalizzato fino a soddisfare tutti i requisiti necessari per il controllo della ADR; il template stesso, convertito in DLL e integrato nell’ambito di un programma principale scritto in Visual Basic, assolve completamente alla funzione di driver della scheda NI 6534, risultando tuttavia trasparente (come interfaccia utente LabView) all’Operatore esterno
• il programma per le animazioni 2D/3D dei voli recuperati dalla ADR è stato realizzato con il linguaggio LabWindows CVI

Le immagini allegate derivano da schermate catturate dal programma di animazione 3D, sviluppato in ambiente NI LabWindows, durante la riproduzione di alcune fasi di una missione reale di volo.

Author Information:
For more information on this Case Study, contact:
F. Lanzillota
GALILEO AVIONICA
Tel: 06 91196455
felice.lanzillotta@galileoavionica.it

Browse All Case Studies »