Architetture modulari e integrate per sistemi avionici

AVIONICA & AEROSPAZIO –

Le soluzioni Ima, rappresentano una delle più interessanti prospettive per la realizzazione di nuovi paradigmi caratterizzati da elevate prestazioni, maggiore affidabilità, riduzioni di costi e consumi, facilità di riutilizzo.


La significativa e continua crescita del traffico aereo negli ultimi anni ha determinato una forte concorrenza tra le diverse società per accaparrarsi le più redditizie quote di mercato. Come sempre accade, questo ha favorito l'innovazione nel settore, sostenendo, unitamente ai progressi tecnologici dell'industria dei semiconduttori, un'interessante evoluzione dei sistemi avionici. Negli anni si è osservata la transizione dai sistemi di controllo analogico ai più complessi computer di bordo basati su architetture PowerPc, l'esplosione della capacità di memorizzazione dei dati e lo sviluppo di sistemi di trasmissione affidabili a più elevato data rate (fino a 100 Mbps). Oggi, il concetto di Ima (Integrated Modular Avionics) sta lentamente sostituendo le tradizionali architetture distribuite.

Uno degli esempi più evidenti di tale architettura distribuita è ancora oggi la Stazione Spaziale Internazionale (ISS), assemblata da un insieme di unità autoconsistenti (Orbital Replaceable Units) connesse mediante bus Mil-STD-1553. Più o meno allo stesso modo, l'avionica della maggior parte dei più classici velivoli utilizzati dall'aviazione civile - quali il Boeing 767 - adotta soluzioni 'federate' basate su un insieme di Lru (Line-Replaceable Unit) indipendenti tra loro, con ben definite funzionalità e connesse tipicamente mediante bus Arinc-429. Il vantaggio principale di tali soluzioni è evidentemente l'elevata affidabilità dell'architettura che consente facilmente il confinamento dei fault, visto il netto partizionamento delle funzionalità fin dai moduli hardware; in seguito a un malfunzionamento, infatti, si perde la sola funzionalità corrispondente al modulo soggetto a fault, e questo, d'altra parte, può, più o meno facilmente, essere escluso dal sistema per evitare la propagazione degli errori. Negli anni, tuttavia, queste soluzioni si sono dimostrate piuttosto pesanti da mantenere e soprattutto soggette a lunghi tempi di sviluppo. La modifica di una sezione del software applicativo su un modulo poteva in alcuni casi richiedere variazioni anche al resto del sistema; architetture e applicativi finivano per essere difficilmente standardizzabili e quindi riutilizzabili.

Nella seconda metà degli anni '90 si è così provato a percorrere una strada diversa puntando alla realizzazione di architetture integrate; l'Aims (Aircraft Information Management System) del Boeing 777 ne è una delle più interessanti realizzazioni. In questo caso l'avionica di bordo si basa su complessi calcolatori connessi in rete mediante link punto-punto (Arinc-429 e Arinc-629 sono stati i bus più utilizzati) e che aggregano funzioni in precedenza implementate da varie Lru. Riduzione della massa e della dissipazione di potenza dell'elettronica, semplificazione dello sviluppo dei software applicativi sono i vantaggi principali di tali soluzioni. Fault management e confinamento dei fault diventano tuttavia più complessi da gestire; dislocazione dei moduli all'interno del velivolo e installazioni dei cablaggi pongono non pochi problemi. L'implementazione di adeguati livelli di ridondanza, infine, finisce in alcuni casi per annullare i benefici nella riduzione delle risorse occupate.
Sotto molti punti di vista, la soluzione a molti di questi problemi sembra essere oggi rappresentata dalle architetture Ima che combinano efficienza e flessibilità, prestazioni e affidabilità. I sistemi Ima, infatti, ereditano l'idea di una soluzione integrata propria delle architetture 'federate' ma sostituiscono le connessioni punto-punto con un bus di comunicazione dati che costituisce una sorta di 'back-plane virtuale' così da rendere i dati accessibili dovunque ed a qualunque modulo; adottano l'idea di modularità dei sistemi distribuiti ma la spostano sul livello applicativo piuttosto che sull'architettura hardware. Una rete connette le diverse Lru che diventano in questo caso unità periferiche più o meno standard, che integrano in un singolo modulo un numero maggiore di funzionalità e che sono configurabili dal punto di vista software in funzione della particolare applicazione. Esiste un path di connessione tra due qualunque Lru, con il livello di rete e quello applicativo che definiscono in tempo reale i Link Virtuali. In presenza di errore il sistema si può riconfigurare per escludere le unità soggette a malfunzionamento ridistribuendo i processi eseguiti da questi sulle altre, eventualmente sopportando un degrado delle prestazioni ma senza una perdita netta delle funzionalità. Diversi sono i vantaggi delle soluzioni Ima tra cui la portabilità delle applicazioni tra diverse piattaforme, la “trasparenza tecnologica” che significa una sostanziale indipendenza del software di alto livello dall'hardware ovvero la standardizzazione di interfacce e protocolli di base, la scalabilità dell'architettura e la flessibilità del sistema nella sua riconfigurazione. Ne derivano una significativa riduzione di costi di sviluppo, di qualifica e di certificazione grazie anche al riutilizzo delle parti e ad un maggiore impiego di componenti Cots (Commercial Off-The-Shelf). Da un punto di vista hardware, l'adozione di una architettura integrata consente inoltre una riduzione delle risorse. Secondo la Boeing lo sviluppo di una soluzione Ima a bordo dei Dreamliner 787 ha consentito una riduzione di massa dell'intera avionica di oltre 700 chilogrammi; secondo Airbus ha semplificato l'intera elettronica di bordo dell'A380 riducendo fino anche della metà il numero di processori utilizzati in precedenti velivoli analoghi. Dal punto di vista del software, infine, la definizioni di Api standard per l'accesso alla risorse hardware semplifica lo sviluppi degli applicativi e migliora l'affidabilità di sistema, demandando le funzionalità di accesso al basso livello al solo sistema operativo.

Standard per architetture Ima   
I primi esempi di architettura Ima si possono rintracciare nell'avionica militare con il progetto della quarta generazione di jet da combattimento come i Lockheed Martin F-22 ed F-35 o il Rafale di Dassault Aviation sviluppati negli anni '90. È solo sul finire del secolo però che questi concetti si presentano appieno nell'ambito dell'aviazione civile con la realizzazione degli Airbus A380 o del Boeing 787. Più o meno in quello stesso periodo ci sono stati dei tentativi di standardizzazione ma a tutt'oggi solo alcuni aspetti delle architetture Ima risultano standard.
In effetti, il programma Asaac (Allied Standards Avionics Architecture Council), condotto da un consorzio di industrie e dipartimenti statali di Regno Unito, Francia e Germania aveva tentato di definire una serie di standard che coprissero i principali aspetti dell'architettura, dai livelli software, alle interfacce di comunicazione e di rete, ai moduli fondamentali caratterizzati da precise funzionalità (data processing, signal processing, graphics processing, mass memory, network support e power conversion), alla meccanica di questi. Gli standard sono successivamente confluiti nelle specifiche Nato Stanag 4626 per la definizione di una architettura aperta per applicazioni avioniche. Tuttavia nel luglio del 2007 le associazione che fanno capo all'Asaac hanno deciso di ritirare l'appoggio ed il supporto a tutti gli standard emessi tranne che alla specifica “Def Stan 0074: Proposed Standards for Software” che definisce gli aspetti software dell'architettura ritenendo questo l'unico punto davvero di comune interesse nel quale avesse senso continuare a investire. Lo standard, come mostrato nella Fig. 2, definisce un'architettura a tre livelli che comprende gli strati applicativo (AL), di sistema operativo (OSL) e di supporto per i moduli (MSL). La configurazione di sistema è definita mediante Rtbp (Run-Time Blueprint) che descrivono l'allocazione di thread, processi, schedule e canali virtuali; non è definito un linguaggio specifico di configurazione così come non è prevista un'interfaccia specifica per l'inizializzazione dei servizi del sistema operativo, se si esclude uno “start thread” che è una sorta di processo general-purpose chiamato come parte della gestione dei processi multi-threaded. È invece definita un'interfaccia standard di accesso alle blueprint mediante il Smbp (System Management to Blueprint Interface). È prevista una netta separazione tra le funzionalità di gestione standard (come healt monitoring e fault management) demandate al Gsm (Generic System Management) e quelle proprie di missione (Application Manager). Il Smli (System Management Logical Interface) definisce un canale virtuale di comunicazione tra AM e Gsm; il Gsm Logical Interface (GLI), invece, descrive la comunicazione tra due istanze del Gsm. Il sistema operativo (OS) è la sezione del livello OSL che gestisce il funzionamento in tempo reale del sistema e delle risorse associate mediante una interfaccia astratta definita dal Module Support to OS Interface (MOS). I dettagli di accesso all'hardware dipendenti dalla particolare piattaforma sono quindi specificati nel Module Support Layer (MSL). Il Smos (System Management to OS Interface) descrive i servizi forniti del sistema operativo al Gsm; l'Apos (Application to OS Interface), invece, fornisce l'interfaccia verso il livello applicativo sulla base di metodi astratti e standardizzati al fine di favorire il riuso dei software applicativi. I servizi forniti al livello applicativo sono classificati in nove categorie in base alle diverse arre di interesse: comunicazione, gestione dei file, conversione di potenza, System Manager Logical Interface, gestione dei thread, gestione del tempo, sincronizzazione, gestione degli errori e file handling. Soltanto i servizi di base di comunicazione (spedizione e ricezione di messaggi e dati nelle modalità blocking e non-blocking), tuttavia, sono mandatori.

Alternativo al Def Stan 0074 è la specifica Arinc 653 - “Avionic Application Software Interface” emessa da Arinc. Lo standard consiste attualmente di tre parti che definiscono i Required Services, gli Extended Services e le Conformity Test Specification. Definisce un'interfaccia Apex (Application Executive) unica tra le applicazioni e il sistema operativo e un meccanismo di chiamata dei servizi forniti da questo. L'applicazione utente è divisa in partizioni che sono allocate in differenti aree di memoria eseguite in finestre temporali predefinite dalla configurazione di sistema. Lo standard adotta, ovvero, un partizionamento fisico e temporale dell'applicazione per assicurare operatività in tempo reale e tolleranza ai fault. In questo schema, il sistema operativo assicura che applicazioni eseguite su una partizione non monopolizzino le risorse del sistema; ogni partizione utilizza un diverso contesto di memoria virtuale al fine di preservare l'integrità di dati ed ogni applicazione dispone di un proprio heap per l'allocazione della memoria dinamica e di uno stack privato per i processi in esecuzione. Chiaramente questo impone che il processore disponga di Mmu (Memory Management Unit). All'interno di questo schema, le interfacce Apex definiscono quindi i servizi per la gestione dell'applicazione, i metodi di comunicazione tra le diverse applicazioni, la gestione degli errori e l'interfaccia con i dispositivi hardware. La configurazioni di sistema è definita mediante apposite tabelle, oggetti di tipo statico accessibili dal solo sistema operativo che specificano porte, canali, processi e loro modalità d'uso.

La Figura mostra un esempio di implementazione di Rtos compatibile con le specifiche Arinc 653. Un primo livello indicato come Module OS - o più semplicemente boars support package - gestisce l'interfaccia con la piattaforma hardware fornendo per ogni partizione la gestione delle risorse, lo scheduling delle partizioni e l'healt monitoring. Il livello superiore denominato Partition OS gestisce invece lo scheduling dei processi secondo uno schema pre-emptive a priorità e la ripartizione delle risorse all'interno di ogni partizione; implementa inoltre le interfacce Apex verso le applicazioni. La comunicazione con il Module OS può avvenire, ad esempio, mediante messaggistica di tipo privato.

Esempi di architetture Ima
La Figura mostra a titolo di esempio una implementazione piuttosto generica e modulare di architetture Ima che tende a separare, mediante impiego di piattaforme dedicate, le funzioni critiche dal punto di vista del controllo del volo da quelle propriamente inerenti la pianificazione della missione. Il Mission Computer, ad esempio, ha il compito di gestire l'acquisizione ed elaborare i dati di missione. Adottando uno schema compatibile con la specifica Arinc 653, si può assumere che il computer esegua una serie di applicazioni pianificate dinamicamente sotto il controllo del sistema operativo, in grado di accedere ai dati di volo ma non di modificarli. La partizione di più alto livello è dedicata appunto ai task di acquisizione dei dati dalla rete di sensori, di elaborazione e di memorizzazione di questi nel Flight Data Recorder (implementato ad esempio come un array di memorie flash). Il sistema è in grado di selezionare i parametri da inviare a terra, gestire le risorse di comunicazione a disposizione determinando ad esempio priorità dei link impiegati, fornire l'interfaccia primaria di accesso ai servizi di connessione della rete di bordo, arbitrare i comandi ricevuti. L'MC può inoltre ospitare - eventualmente in una partizione separata - applicazioni di machine-vision per scopi di Vsm (Vehicle System Management), tra cui la riconfigurazione di sistemi critici in seguito a failover. L'Fcc (Flight Critical Computer) controlla la dinamica di volo in base ai parametri e alle indicazioni del MC, non senza però verificare la consistenza e opportunità di questi. L'Asn (Ancillary Sensor Network), invece, è la rete di sensori intelligenti del velivolo; caratteristiche fondamentali sono la tolleranza a singoli fault e l'espandibilità della rete, eventualmente mediante un semplice meccanismo plug&play che richieda operazioni di riconfigurazione minimali. MC, Fcc e Asn, oltre a restanti moduli di bordo tra cui i sistemi di telemetria/telecomandi per le comunicazioni radio e gli apparati di controllo della strumentazione della cabina di pilotaggio, come mostrato in figura, sono connessi mediante rete, in grado di sostenere un protocollo di comunicazione deterministico al fine di assicurare il funzionamento in tempo-reale della piattaforma. Afdx è oggi la soluzione principalmente adottata.

Sebbene da un punto di vista concettuale l'idea di architetture Ima sia ben definita, come osservato in precedenza non esiste ancora uno standard comunemente accettato per la realizzazione hardware. Pertanto nella realtà, sono state proposte nel tempo diverse soluzioni.
In ambito militare, ad esempio, una delle prime è stata l'avionica del Rafale, l'aereo da combattimento francese progettato e realizzato da Dassault Aviation che ha ricevuto nel 2008 la qualifica F3 dal dipartimento francese, che, tra l'altro, consente l'impiego a bordo di armamenti nucleari. Il velivolo è dotato di una complessa rete di sensori e strumentazione, tra cui:
•    Rbe2, un'antenna radar a scansione elettronica in grado di generare in tempo reale mappe tridimensionali del suolo, rilevare e tracciare bersagli multipli in area e in mare;
•    Osf, un sensore optronico in grado di operare sia nel visibile che nell'infrarosso;
•    Spectra, un complesso sistema multi-spettrale di combattimento elettronico;
•    Damocles, un pod per armamenti laserguidati
•    un sistema di comunicazione sicuro ad elevato data-rate utilizzabile per lo scambio dati nelle operazioni combinate in volo.

Cuore dell'aereo è l'Mdpu (Modular Data Processing Unit) che realizza applicazioni di analisi e sintesi dei dati, così da consentire al pilota di prendere la decisione tecnico-tattica più appropriata in base allo scenario operativo ed alla situazione del velivolo. Sulla base delle informazioni primarie dei sensori, l'Mdpu ricostruisce possibili tracce; sovrapponendo i dati, quindi, raffina l'analisi rimuovendo limitazioni intrinseche delle singole apparecchiature nella loro risposta in frequenza. Infine cancella tracce ridondanti semplificando le immagini riportate sul display del pilota. La Mdpu si basa su 18 Lrus, quasi interamente realizzate con componenti Cots ed ognuna dotata di una capacità di processamento ed elaborazione dati 50 volte maggiore di quella dei computer XRI presenti sulla precedente versione del Mirage 2000-5.

In ambito civile, invece, due dei più interessanti esempi di architettura Ima sono il Boeing 787 e l'Airbus A380, già citati in precedenza. Entrambi adottano l'idea di risorse condivise che rappresenta la base di ogni soluzione Ima ma la implementano da due diversi punti di vista.
Elemento chiave dell'architettura dei Boeing 787, ad esempio, è il Ccs (Common Core System), un computer centrale che da solo integra le funzionalità di oltre 100 Lru di precedenti architetture, tra cui l'avionica in generale, il controllo ambientale, dei sistemi elettrici, meccanici, idraulici e di potenza ausiliari, la gestione degli apparati di propulsione e del carburante. Progettato da GE Aviation, il Ccs consiste di una rete di moduli connessi mediante bus Afdx; supporta l'interfacciamento verso i Rdc (Remote Data Concentrator), moduli di acquisizione dati con interfacce analogiche e digitali. Una rete Ethernet in fibra ottica denominata Common Data Network, quindi, consente la comunicazione con il Ccs. Completa l'architettura un Ciss (Configurable Integrated Surveillance System) sviluppato da Rockwell Collins che implementa, ad esempio, il sistema di visualizzazione della cabina di pilotaggio. Il Ccs esegue VxWorks 653, il sistema operativo compatibile con le specifica Arinc 653 sviluppato da WindRiver. L'applicazione - sviluppata da Honeywell - oltre al software di controllo di volo include package accessori per, ad esempio, soluzioni fly-by-wire.

Diverso è invece l'approccio dell'Airbus A380 che non utilizza un processore centralizzato ma piuttosto impiega 8 diversi moduli di elaborazione dati in rete mediante connessione Afdx. Sette di questi moduli - denominati Cpiom (Core processing I/O Module) - sono unità general purpose di I/O con intelligenza locale; l'ottavo, denominato IOM (I/O Module), è invece progettato specificatamente per la particolare applicazione. Fino a 30 Lru compongono la rete di acquisizione dati. Al fine di supportare il riuso di parti e componenti, i moduli condividono tipicamente il progetto delle schede comuni, tra cui quelle di potenza e di memoria. In questo modo è stata stimata una riduzione dei costi fino anche al 20%. Per favorire inoltre l'espandibilità dell'architettura, è resa disponibile direttamente da Rockwell System un'unità di connessione alla rete Afdx che può essere integrata da terze parti nei propri sistemi. L'avionica dell'A380 tende così verso una soluzione piuttosto aperta; fino a 22 applicazioni sviluppate da oltre 11 fornitori diversi sono eseguite dai computer di bordo.

WxWorks 653: RTOS per architetture Ima
WxWorks 653 è la versione del sistema operativo WxWorks di WindRiver compatibile con le raccomdazioni Arinc 653 Supplemento 1 e 2 Parte I. Distribuito unitamente a Wind River Workbench - suite di progetto basata su Eclipse sviluppata per supportare la realizzazione, il test e la certificazione di applicazioni compatibili con le specifiche Rtca DO-178B Livello A - WvWorks 653 fornisce una infrastruttura per il partizionamento temporale e spaziale della applicazioni e il contenimento dei fault. Basato su una architettura con macchina virtuale a due livelli che assicura basso jitter nella esecuzione dei programmi, supporta fino a 255 partizioni e 2000 processi per partizione. Il sistema è già stato impiegato su alcuni dei più innovativi velivoli tra cui gli Airbus MTT e A400, i Boeing 787-Dreamliner o gli aerei da combattimento P-8A.
www.windriver.com/products/platforms/safety_critical_arinc_653/index.html

Arinc
Arinc (Aeronautical Radio, Incorporated) è un'associazione fondata nel 1929 in qualità di unico detentore, oltre al governo federale, di licenza per le comunicazioni radio nel settore aeronautico. L'associazione si prese successivamente carico della responsabilità di tutte le stazioni di terra e delle procedure di approvazione e qualifica di apparecchiature e sistemi rispetto alle regolamentazioni FRC. Nel 1950 è stata tra i primi nello sviluppo dei metodi e delle teorie sull'analisi di affidabilità. Nel 1978 ha introdotto l'Acars (Aircraft Communications Addressing and Reporting System), un sistema di comunicazione non vocale correntemente usato per lo scambio dati tra stazioni di terra e velivoli commerciali. La sussidiaria Arinc Engineering Services si occupa delle attività nel settore aerospaziale e della difesa.
Nell'ambito delle attività di coordinamento nel settore, Arinc cura la stesura e l'aggiornamento di numerosi standard in ambito avionico. Di seguito le principali categorie in cui sono stati emessi documenti di interesse:
- serie 400 - principi e raccomandazioni per la progettazione di sistemi compatibili con le specifiche delle serie 500 e 700
- serie 500 - apparecchiature analogiche in ambito avionico
- serie 600 - principi e raccomandazioni per la progettazione di sistema compatibili con le specifiche della serie 700
- serie 700 - sistemi digitali e protocolli datalink in ambito avionico
- serie 800 - tecnologie di supporto per sistemi di reti a bordo di aeromobili
- serie 900 - in fase di definizione

www.arinc.org

Il programma Asaac
Asaac (Allied Standards Avionics Architecture Council) è un programma congiunto di Regno Unito, Francia e Germania per la definizione di uno standard comune per architetture Ima in ambito avionico. Nel 2005, l'attività del consorzio è culminata nella definizione di una serie di specifiche per architettura, reti di comunicazioni, packaging, funzionalità e software, secondo lo schema seguente:
- Def Stan 00 74 - Software
- Def Stan 00 75 - Communication/Network
- Def Stan 00 76 - Functional Modules
- Def Stan 00 77 - Packaging
- Def Stan 00 78 - Architecture

Le specifiche sono state successivamente sottoposte a rappresentanti del Ministero della Difesa inglese (DSTAN, TES, DSTL) e industrie del settore (Bae Systems, General Dynamics, Westlands, Selex) al fine di verificarne merito e interesse per successivo supporto. Nel 2007 il MoD ha terminato l'attività di rivisitazione concludendo che il solo standard di interesse e per il quale è opportuno continuare tale attività di supporto per la standardizzazione è il Def Stan 0074.
http://assconline.co.uk/asaac.asp

Pubblica i tuoi commenti