Il settore aeronautico in continuo movimento

• 
• Tweet
• Pin It
• Condividi per email

La promessa di una maggiore efficienza grazie a sistemi di avionica modulare integrata (IMA) che riducono spazio, peso e potenza (SWaP) si sta finalmente concretizzando. Progetti di notevole rilevanza e visibilità come il Boeing 787 Dreamliner e l’Airbus A380 sfruttano questa strategia più efficiente per integrare i sistemi dei fornitori di aeromobili in piattaforme di calcolo condivise.

L’obiettivo dell’avionica modulare integrata consiste nell’abbinare una serie di sistemi federati tradizionali indipendenti con piattaforme comuni integrate. Tale riduzione/compressione del sistema aumenta l’efficienza e riduce le schede processori, il supporto hardware e il cablaggio, offrendo l’ulteriore vantaggio di tagliare i costi per i materiali (BOM), nonché il numero delle unità sostituibili (LRU). Questo si traduce in una semplificazione nella gestione dei pezzi di ricambio e in una riduzione della necessità di formazione.

Il sistema IMA più avanzato, il Common Core System (CCS) fornito da GE Aviation per il Boeing 787, attualmente conta su più di 70 applicazioni distinte che vengono eseguite a livelli di sicurezza diversi. Tale architettura ha consentito a Boeing di eliminare oltre 100 LRU discrete nel suo aeromobile di ultima generazione, ottenendo pertanto risparmi in termini di SWaP e di costi associati ad aggiornamenti software, espansioni, revisioni e riparazioni nel corso del ciclo di vita del prodotto.

La sfida dell’IMA consiste nel mantenere una funzione di sostituzione e riparazione paragonabile a quella dei sistemi federati, assicurando nel contempo un solido meccanismo per la separazione delle applicazioni con diversi livelli di criticità per la sicurezza. In ragione dei costi estremamente elevati della sperimentazione e della certificazione del software, una piattaforma IMA sostenibile deve consentire un percorso efficiente ed efficace dal punto del rapporto costi/benefici per rispondere ai requisiti della certificazione di sicurezza RTCA DO-178B e DO-254, risultato che può essere ottenuto soltanto con una certificazione del software incrementale.

Cambiamenti fondamentali
Nel modello federato dell’avionica, hardware e software dei sottosistemi vengono forniti in un unico pacchetto da un solo appaltatore principale, il quale è responsabile del 100% della progettazione, dell’introduzione e del collaudo del dispositivo; pertanto, tale fornitore di sistemi federati ha il controllo assoluto sullo sviluppo dell’intero sottosistema. Questo modello vincolava il costruttore dell’aeromobile a una specifica catena di fornitura e uno specifico fornitore di sottosistemi, il che limitava le possibilità di risparmio sui costi, soprattutto in caso di aggiornamento delle funzionalità o introduzione di nuove tecnologie. Le nuove funzionalità venivano spesso risolte introducendo una nuova unità sostituibile (LRU), che poteva essere fornita dallo stesso costruttore od ottenuta appaltandone la fornitura, soluzioni che comportavano entrambe costi notevoli.

Il modello di fornitura federato prevedeva che il fornitore di LRU per ogni sistema si facesse carico del 100% della responsabilità della certificazione DO-178B e DO-254 dell’unità. Di solito, una LRU era destinata a supportare una sola funzione dell’aeromobile, come il sistema di gestione del volo, e sebbene potesse eseguire varie applicazioni per supportare tale funzione, veniva certificata per un unico livello di sicurezza DO-178B e/o DO-254. Il fornitore di LRU sottoponeva poi l’intero sistema alla procedura di certificazione, fornendone la documentazione al costruttore dell’aeromobile per inserirla nel fascicolo di sicurezza dell’apparecchio.

La certificazione incrementale non era praticabile: tutte le volte che era necessario modificare una riga del codice del software, secondo le istruzioni per la certificazione DO-178B e/o DO-254, occorreva anche riqualificare interamente tutta la LRU. Ciò valeva anche se la piattaforma di calcolo della LRU utilizzava una strategia di partizionamento delle applicazioni, generalmente in ragione dell’accoppiamento dei dati e/o del controllo tra le applicazioni e il sistema operativo. Per qualunque modifica apportata al pacchetto di supporto della scheda (BSP), al sistema operativo in tempo reale (RTOS)/al controllo sequenziale o all’applicazione era necessario sottoporre nuovamente alla procedura di collaudo l’intero stack del software della LRU.

Con il più recente approccio IMA, le applicazioni sono separate dalla piattaforma di calcolo di base e comunicano attraverso l’API ARINC 653 standard. Inoltre le applicazioni sono controllate attraverso un controllo di sequenza spaziale e temporale da RTOS ARINC 653. Questa separazione potenzialmente permette al costruttore dell’aeromobile di acquisire la piattaforma di calcolo di base e le applicazioni da fonti distinte, scegliendo il miglior fornitore per ogni funzione. Questa architettura IMA assicura una maggiore competitività e flessibilità al costruttore, ma moltiplica le sfide poste dall’ingegnerizzazione del software e dall’integrazione dei sistemi, tra cui l’introduzione di unità aviotrasportate nel caso in cui i concorrenti condividano il medesimo silicio per i dispositivi di calcolo.

Le piattaforme di calcolo IMA condivise hanno richiesto un radicale mutamento del modo in cui si sviluppano i sistemi per gli aeromobili con la definizione di nuovi ruoli specifici per l’integratore di sistemi, il fornitore di piattaforme e i fornitori di applicazioni, ruoli che sono definiti interamente nel quadro dello standard DO-297 denominato “Orientamenti per lo sviluppo dell’avionica modulare integrata (IMA) e considerazioni in materia di certificazione”. Nell’ambito di tale modello, l’aggiunta di ulteriori funzionalità nel sistema comporta l’aggiunta o la modifica di un’applicazione software esistente. La sfida diventa quindi la progettazione, il collaudo e l’integrazione di tale componente software nel sistema finale senza incidere sul livello di sicurezza di altre applicazioni o della piattaforma stessa.

Ogni ruolo implica responsabilità ben precise per la certificazione della componente corrispondente. Il fornitore di piattaforme gestisce la consegna e la certificazione della piattaforma di base (hardware e software), i fornitori delle applicazioni sono responsabili unicamente delle proprie applicazioni e l’integratore di sistemi è responsabile del consolidamento di tutti gli elementi di sicurezza provenienti dalle diverse fonti distinte per mettere a disposizione del cliente un fascicolo di sicurezza completo.

Di conseguenza, l’approccio IMA, ovvero l’abbinamento di applicazioni software critiche per la sicurezza distinte in un’unica piattaforma hardware, ha comportato l’introduzione di una definizione contrattuale più vincolante tra queste componenti distinte, sia a livello aziendale sia in termini di sistemi. Se da una parte i maggiori vincoli e la separazione tra le componenti pongono all’integratore di sistemi la sfida di distribuire le risorse tra tutti i fornitori di applicazioni, dall’altra offrono comunque una piattaforma che può permettere a ciascuna di queste applicazioni di essere certificata con sicurezza a un livello diverso. Le piattaforme IMA assicurano inoltre la possibilità di procedere alla certificazione incrementale, che non impone di eseguire nuovamente le prove sull’intera piattaforma, bensì soltanto sull’ambito dell’eventuale modifica apportata all’applicazione.

Certificazione incrementale
La solidità dell’architettura dell’ARINC 653 è, secondo le indicazioni dello standard DO-178B, l’elemento fondamentale per l’efficienza della certificazione incrementale. Senza tale separazione collaudata, i sistemi ARINC 653 sono automaticamente convertiti in piattaforme federate molto complesse e ogni modifica apportata alla piattaforma integrata costringe a eseguire nuovamente le prove sull’intera piattaforma, provocando un aumento esponenzia
le dei test del sistema, rendendo la piattaforma integrata non commercialmente sostenibile.

La solidità, secondo la definizione contenuta nelle indicazioni dello standard DO-178B, è una dimostrazione molto specifica del fatto che in tutte le condizioni di malfunzionamento dell’applicazione, un singolo malfunzionamento in una partizione non incide sulle altre partizioni. Questa dimostrazione può risultare impegnativa e nel caso delle prove di certificazione VxWorks 653 di Wind River comporta una corposa documentazione di oltre 330 pagine prevedendo test e analisi per il fornitore del RTOS ARINC 653 (nella fattispecie Wind River), nonché prove specifiche da svolgere sull’hardware installato nell’aeromobile.

La certificazione incrementale funziona soltanto se le componenti hardware e software sono realmente isolate, consentendo una comprovata indipendenza e solidità dell’intero sistema. Tale separazione significa che il software deve essere sviluppato senza fare affidamento su un hardware specifico o altre applicazioni nella fase di costruzione, utilizzando invece soltanto le risorse informatiche messe a disposizione dalla piattaforma di base attraverso le interfacce di programmazione delle applicazioni (API) ARINC 653, risorse che non soltanto includerebbero le stesse API ARINC 653, ma fornirebbero accesso alle risorse hardware come CPU, memoria e I/O.
La prima sfida posta dalla solidità consiste nel consentire l’accesso a tali risorse usando le API ARINC 653 in maniera che le applicazioni possano accedervi e soddisfare i requisiti prestazionali di progetto.

La seconda sfida consiste nel costruire, configurare e introdurre l’applicazione in un sistema IMA in maniera che le applicazioni possano prontamente spostarsi da una piattaforma all’altra ed essere modificate senza alterare o interessare la piattaforma di base o altre applicazioni. Questo è l’ambito in cui il fornitore di piattaforme ha il compito di mappare gli I/O e altre risorse di calcolo del sistema a disposizione dell’API ARINC 653, nonché consentire ad altre API un’agevole migrazione verso altre risorse software (per esempio, applicazioni POSIX o VxWorks).

L’integratore di sistemi deve dunque integrare tali applicazioni nella piattaforma di base accertandosi che l’intero sistema risponda sempre ai requisiti prestazionali, attività che potrebbe comportare una complessa negoziazione tra i vari fornitori distinti per assegnare le risorse in maniera efficiente. Le decisioni prese in tale ambito possono anche incidere sulla configurazione generale della piattaforma di calcolo condivisa e imporre al fornitore di piattaforme di mettere a disposizione una maggiore risorsa a livello di CPU o distribuire le applicazioni in maniera diversa nel sistema finale.

Disporre di una semplice API ARINC 653 per le applicazioni oltre a un RTOS o disporre di un sistema operativo ARINC 653 che assicuri unicamente un partizionamento spaziale e temporale a livello di applicazioni non è sufficiente: è necessario che venga supportato un ambiente in cui non solo le componenti del sistema siano nettamente separate, ma il ciclo di sviluppo del software sia separato anch’esso, consentendo pienamente la certificazione incrementale. Questa è la quarta sfida, che richiede un ambiente progettato in maniera più sofisticata in cui le applicazioni possano essere sviluppate e testate senza fare affidamento sulla presenza di altre applicazioni o hardware specifico. Spesso esistono legami o accoppiamenti impliciti, invisibili o per altri versi ignoti tra applicazioni, BSP e driver che vanificato la reale indipendenza dei sistemi e delle applicazioni; un rigido partizionamento impone che non vi siano accoppiamenti di dati né controllo tra partizioni.

L’accoppiamento del controllo si configura come vulnerabilità all’accesso esterno (per esempio, superamento delle finestre assegnate), mentre l’accoppiamento dei dati comprende dati condivisi, nonché stack e registri del processore. Qualunque accoppiamento del controllo o dei dati tra componenti della piattaforma IMA elimina la possibilità di un rigido partizionamento DO-178B e, dunque, della certificazione incrementale.

Nonostante tutte le sfide, un esempio eloquente dei vantaggi derivanti dall’adozione di un approccio IMA è l’evoluzione del Boeing 777 al 787. Mentre il Boeing 777 utilizzava l’IMA per i sistemi di gestione del volo, l’attuale sviluppo IMA per il Boeing 787 esegue circa 70 applicazioni su un’unica piattaforma hardware avionica, abbinando sistemi di navigazione, distribuzione dell’energia elettrica e sistemi di gestione dei rifiuti, architettura che ha consentito a Boeing di eliminare LRU discrete, ottenendo in tal modo un risparmio in termini di SWaP e costi sostenuti durante il ciclo di vita per la manutenzione, la revisione e la riparazione.

I benefici a lungo termine derivanti da un approccio IMA per la progettazione dei sistemi di un aeromobile ora sono evidenti. La riduzione dello SWaP grazie all’eliminazione di serie di unità processore distinte comporta un impatto positivo notevole e un’elevata redditività dell’aeromobile nel corso della sua vita, oltre a migliorare la capacità di ingegnerizzazione dei sistemi software nella catena di fornitura globale.

Questo ha richiesto un cambiamento radicale del modo in cui tali sistemi sono definiti, progettati, installati e collaudati, e dunque anni per realizzarlo con la massima efficienza mantenendo gli elevati livelli di sicurezza indispensabili nel settore dell’avionica. Ogni generazione di prodotti aumenta il livello di integrazione, supportando la conseguente maggiore complessità e il maggior numero di prove richieste per la certificazione. Il software dell’attuale generazione di aeromobili è probabilmente il software testato con maggior rigore al mondo.

Tali cambiamenti, intervenuti non soltanto a livello tecnologico, ma anche negli standard, nelle strategie di certificazione e nel modello aziendale,procedono a ritmi diversi. Nondimeno, i progressi realizzati nell’avionica modulare integrata hanno consentito notevoli miglioramenti dell’efficienza se basati su una netta separazione e una certificazione incrementale, come dimostrano gli aeromobili dell’ultima generazione in cui tali standard e prassi IMA globali si concretizzano.

Wind River
 

Chip Downing, Director, Aerospace & Defense, Wind River

• 
• Tweet
• Pin It
• Condividi per email