Architetture modulari e integrate per sistemi avionici

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.