Integrazione dell'avionica

L'integrazione del sistema avionico è il processo che si occupa di realizzare e testare il progetto per assicurarsi che i vari sottosistemi possano funzionare una volta interconnessi tra loro; inoltre, si valuta anche l'impatto del sistema con il mondo esterno, ovvero il velivolo su cui è installato e il sistema organizzativo che lo impiega. L'obiettivo è quindi di massimizzare l'efficacia del sistema completo, portandola possibilmente a essere maggiore della somma dei suoi componenti.

A grandi linee possiamo suddividere l'integrazione in 5 fasi:

1. conclusione delle attività di ottimizzazione;
2. rianalisi dei requisiti;
3. definizione e realizzazione dell'architettura del sistema e prove di validazione sui rig;
4. installazione e validazione sul velivolo;
5. prove di volo;

Le fasi qui sopra citate verranno meglio descritte nelle prossime sezioni.

Fasi preliminari all'integrazione

Come già detto nelle scorse lezioni l'ottimizzazione è il passo precedente all'ottimizzazione. Giunti a questo punto, è stato scritto il progetto preliminare dell'architettura del sistema avionico, corredato da tutti i documenti di requisiti tecnici ed economici, che sono ora contrattualmente vincolanti. Inoltre sono già state prese le decisioni di make or buy per i componenti principali e vengono avviate le gare di appalto per i fornitori, anch'esse corredate con precise specifiche tecniche.

Analisi dei requisiti

I requisiti, ormai ben definiti e fissi, vengono rianalizzati allo scopo di strutturarli e preparare il processo di integrazione. Un concetto fondamentale in questa fase è la cosiddetta tracciabilità dei requisiti: i requisiti vengono ordinati (quale deve essere fatto prima, quale dopo, ecc.) ma rimangono tracciabili, perché ogni funzione (HW o SW) introdotta deve riferirsi a un particolare requisito, in modo da essere certi di aver implementato tutti i requisiti richiesti e viceversa di non averne implementato nessuno non richiesto.

Progettazione dell'architettura

La progettazione dell'architettura HW e SW è definita come:

«L'organizzazione della struttura di un sistema, che identifichi i suoi componenti, le loro interfacce e l'esecuzione (nel senso di interazione n.d.r.) tra di loro»

L'architettura - che comprende le informazioni morfologiche, elettriche ed informatiche - deve essere definita e documentata secondo gli standard aziendali ed è divisa su più livelli. I livelli possono essere schematizzati in prima approssimazione secondo la seguente suddivisione:

• sistema avionico generale complessivo;
• sottosistema funzionale (autopilota, navigazione, display, ecc.);
• livello LRU, la singola "black box" del sistema.

ad ognuno di questi livelli devono essere definiti quindi: i componenti che li compongono, le interfacce con cui comunicano e come devono interagire con gli altri componenti. Le architetture avioniche hanno quindi l'obiettivo di rispondere a tutti i requisiti funzionali (detti anche operativi) e per ogni funzione di fornire un livello di criticità appropriato (ad esempio realizzando le opportune ridondanze). Possiamo suddividere l'integrazione delle architetture in due parti:

• integrazione funzionale: rappresenta come le varie funzioni del sistema devono interagire per ottenere il requisito operativo;
• integrazione hardware: come le risorse hardware devono essere condivise (potenza di calcolo, display, ecc.)

Solitamente i sottosistemi avionici dove il livello di integrazione è più alto (quindi quelli che necessitano di maggior effort) sono:

• i displays, per condivide le informazioni provenienti da unità diverse;
• i comandi di volo
• la navigazione
• le comunicazioni
• la gestione del velivolo
• gli apparati di missione

Realizzazione dell'architettura

In questa fase, dai documenti sopra prodotti si deve realizzare l'architettura. Per fare questo bisogna produrre altri documenti che consentano o la costruzione fisica dell'hardware oppure le specifiche di acquisto se l'hardware viene comprato da un fornitore. Analogalmente, per il software viene fornita adeguata documentazione per la codifica nel linguaggio scelto, oppure le specifiche di acquisto per il software comprato dal fornitore. In particolare, con i fornitori devono essere concordate le interfacce che i loro componenti devono avere (attraverso documenti chiamati ICD, Interface Control Document), ad esempio come il componente dovrà utilizzare il data bus.

Sviluppo del software

Lo sviluppo del software deve seguire alcune norme che prescrivono il processo, ovvero la metodologia, con cui il software è realizzato; infatti la norma non dice come il software deve essere scritto (perché non sarebbe in grado di assicurarne la sicurezza), ma con quale processo esso viene generato, in modo da garantire i requisiti di sicurezza e controllabilità. Il controllo del processo di sviluppo software è essenziale, perché i test funzionali non possono garantire la completa assenza di errori software.

Le due principali norme applicabili per il settore civile e militare sono:

• RTCA DO178B: Software Considerations in Airborne Systems and Equipment Certification
• MIL-STD-498: Software Development Process

Lo scopo di queste norme è specificare quali processi devono essere eseguiti nella scrittura del software (es. sw requirements analysis, sw design, unit testing, integration testing, system testing, ...) e quali documenti devono essere prodotti (es. system design specification, sw test description, sw test report, ...).

Oltre a prescrizioni direttamente sul software come detto precedentemente, anche il project planning è soggetto a regolamentazione, dalla fase di pianificazione, analisi del rischio, sicurezza, rapporto con i subfornitori, ecc.

L'obiettivo è quindi quello di ottenere un software tracciabile, testato, manutenibile e sicuro. Il livello di testing che deve essere raggiunto dipende dal livello di criticità della funzione svolta da una certa unità di software, ed è solitamente specificato nelle norme.

Verifica e validazione

Quando i primi prototipi hardware e software sono realizzati, inizia la fase di testing a terra di tutti gli apparati, basandosi su i cosiddetti Rigs ovvero l'insieme di componenti avionici che comporranno l'aeromobile, disposti e connessi come se fossero montati a bordo. I rig possono poi essere ridotti a specifiche funzioni (in questi casi parleremo di Subsystem rigs). Ovviamente, non tutti i sensori a terra possono fornire dati reali o possono essere facilmente stimolati, perciò si fa uso di emulatori che simulano i dati.

Parallelamente a questa fase il software continua ad evolvere in rispondenza dei test effettuati sui rig. Possiamo suddividere i test di questa fase in:

• prove funzionali: si verifica che ogni sistema funzioni in modo corretto;
• prove di sviluppo: si verifica che ogni requisito sia rispettato;
• prove iniziali di qualificazione: prove eseguite dall'azienda atte a portare i sistemi a una configurazione che permettano le prove in volo;
• prove di dimostrazione alle autorità: prove per la verifica insieme alle autorità della compliace ai requisiti di aeronavigabilità.

Inoltre, in parallelo a queste attività viene installato per la prima volta il sistema avionico sul velivolo ed effettuati altri test (ATP: acceptance test procedure) per portarsi alle prove di volo. Ogni sistema autorizzato alla prove di volo riceve la cosiddetta red label.

Dopo le prove di volo il software ormai giunto al suo stato finale, tutti i test funzionali vengono ripetuti nel processo di Validazione e Verifica (V&V), in modo da permettere di dichiarare un apparato adatto al volo, e fargli ricevere la cosiddetta black label.

Acquisto di hardware/software esterno

L'acquisto esterno di hardware e/o software implica un notevole vantaggio: tutta la parte di certificazione e di test del singolo sottosistema è delegato al fornitore dell'apparecchiatura, anche se non possono ovviamente essere esclusi i test di funzionamento una volta connesso con il resto del sistema. Gli apparati comprati che rispondono al TSO (Technical Standard Order) sono già approvati dall'ente aeronautico, in quanto è l'azienda fornitrice stessa che certifica l'aeronavigabilità del prodotto.

Il principale svantaggio risiede nel dover rivelare all'esterno dati e know-how dell'impresa. Spesso infatti, il velivolista compra l'hardware e il software di base all'esterno, e costruisce all'interno il proprio software applicativo, in modo da garantire una buona riservatezza sulle funzionalità del proprio prodotto, sia per problemi di concorrenza, che problemi militari. Solitamente in questa categoria rientrano l'AFCS, il fly-by-wire, l'HUMS e il software di missione.

Altre volte invece, soprattutto per commesse militari, il software di missione è installato a bordo del velivolo da parte di aziende dette system integrator dopo che il velivolista ha costruito il velivolo stesso, per garantire così maggiore riservatezza.

DDP

Alla conclusione del progetto, ogni responsabile di ogni settore del sistema avionico e il responsabile del progetto complessivo forniscono la Declaration of Design and Performance (DDP), nella quale dichiarano la rispondenza del sistema avionico a tutti i requisiti. Il responsabile dell'intera Design Organization firma quindi in ottemperanza a EASA part 21, la Dichiarazione di Rispondenza (Declaration of Compliance). Questi documenti permettono di ottenere dalle autorità civili (militari) la certificazione (qualificazione).

La documentazione

La documentazione è tutto quell'insieme di documenti (in parte citati nella sezione precedente) che accompagnano lo sviluppo del sistema avionico con lo scopo di ottenere la certificazione o la qualificazione del prodotto. Per ottenere la certificazione/qualificazione la documentazione deve includere:

• EWS: v. sezione dedicata
• SDD: v. sezione dedicata
• Analisi della sicurezza: failure mode e effects analysis (FMECA)
• Reliability, Availability Plan
• Maintainability, Testability Plan
• Disegno delle installazioni
• Compliance checklists

EWS

Come già citato, la gestione del progetto deve anch'essa rispondere di precise norme che ne regolano il processo, per questo tutte le attività del progetto devono essere indicate in un piano di sviluppo, in inglese EWS (Engineering Work Statement). Esso definisce secondo diagrammi a blocchi e diagrammi di Gantt con quale ordine e quali tempistiche il processo di sviluppo dovrà aver luogo, quali risorse umane e materiali sono necessarie e le milestone da raggiungere. Le milestone devono corrispondere a eventi tangibili, cioè a metriche di progetto (EVMS), un insieme di indicatori rivolto a tenere sotto controllo e prevedere l'andamento delle principali variabili critiche del progetto.

SRD e SRR

Il System Requirement Document (SRD) contiene tutti i requisiti proveniente dalla fase di ottimizzazione, convertiti in requisiti tecnici. Questa è una fase cruciale, i requisiti ad alto livello risultato dell'ottimizzazione devono essere riscritti in modo da diventare requisiti che permettano lo sviluppo delle architettura hardware e software. Punto fondamentale di questo documento, come già detto, è la tracciabilità dei requisiti attraverso un numero identificativo che ne permetta l'associazione strutturata requisito-funzioni, per assicurare che tutti i requisiti siano stati implementati e viceversa che nessuna funzione sia superflua, cioè non prevista da nessun requisito.

A questo punto un processo di risk management deve tenere sotto controllo i requisiti, sia in termine di severità che in termini di probabilità che essi non vengano eseguiti nel tempo prefissato. Difatti, i requisiti sono strutturati in senso gerarchico e la mancanza di uno di essi può portare ad effetti a cascata.

Il SRD è costituito a diversi livelli di sviluppo:

1. sistema velivolo completo
2. sistema avionico
3. sottosistema avionico
4. apparato (LRU, apparati in possesso di TSO, ecc.)

Il System Requirement Review (SRR) è il processo di revisione al termine della scrittura del SRD. Al termine di questa revisione, il documento SRD è approvato e "sigillato" e può essere modificato solo attraverso processi controllati. Il progetto esecutivo può finalmente prendere il via sulla base di questo documento.

Una particolare attenzione durante il processo di review è data al software: esso deve rispettare i requisiti e soprattutto deve essere sufficientemente specificato per permetterne lo sviluppo.

SDD

Il System Design Document è un documento scritto durante la produzione del sistema avionico, per la parte hardware e/o per la parte software. Basato a partire dall'SRD, mantiene la tracciabilità dei requisiti e indica l'architettura di sviluppo del sistema. Comprende anche le specifiche dell'input e output di ogni singolo sottosistema e ne descrive tutte le funzioni.

Anche l'SDD contiene una parte di project management, descrivendo i work element necessari per le fasi successive di sviluppo o di acquisto, la loro integrazione e le attività di test e certificazione richieste.

I documenti prodotti in questa fase che concorrono alla qualificazione e alla certificazione sono:

• Qualification plan: definisce gli aspetti generali e la programmazione temporale dell'attività di qualificazione
• Qualification test plan: fornisce informazioni su come sono pianificati i test e come devono essere effettuati.
• Qualification test report: fornisce informazioni sui risultati dei test

Design review

Una design review è una riunione con lo scopo di revisionare l'andamento del progetto, vericando e approvando le attività svolte e l'autorizzazione a proseguire con le attività successive. Questa fase di revisione è quindi un'analisi critica del progetto in un determinato instante di tempo in cui si svolge, composta da tutti gli attori interessati nel progetto, da chi si occupa dello sviluppo, dai rappresentanti dei fornitori e gli enti esterni.

Le design review sono un componente fondamentale per trovare e correggere gli errori di progetto il prima possibile durante il suo sviluppo, in modo da ridurre l'effetto negativo che la modifica può portare. Ovviamente, più la modifica avviene tardi nel progetto, più il costo e il tempo per correggerla aumentano, e possono addirittura avere effetti economicamente catastrofici.

Anche le design review vengono programmate a priori, solitamente nei documenti chiamati Development Plans. Le review minime solitamente richieste sono:

1. Preliminary Design Review (PDR): si verifica che il design preliminare soddisfi tutti i requisiti con un rischio accettabile nei limiti di costo e temporali. Inoltre si controlla che i requisiti rimangano tracciabili, che le scelte di progetto siano corrette, che le interfacce e i metodi di verifica siano stati descritti. Se necessario sono separate la review hardware da quella software.
2. Critical Design Review (CDR): verifica la maturità del progetto per passare alla fase di produzione e test; verifica quindi che il progetto sia rispondente al SDD e in linea con i requisiti e limiti del sistema superiore. Se necessario sono separate la review hardware da quella software.
3. Test Readiness Review (TRR): verifica che il sistema rispetti in ogni sua parte determinati requisiti per renderlo pronto al testing. Questo non comprende esclusivamente le caratteristiche funzionali, ma anche tutta la documentazione correlata.
4. altre review: altre design review possono essere stabilite a priori oppure convocate ad-hoc.
5. Certification Reviews: queste review in presenza dell'autorità, si occupano di mostrare come il progetto risponda alle norme di certificazione, in particolar modo che processo di sviluppo controllato.
6. verifiche di avanzamento: sono delle review che si svolgono tra gli azionisti dell'azienda o i committenti (tipicamente militari) per verificare lo stato di avanzamento del progetto, verificando il progetto negli obiettivi intermedi prefissati. Spesso vengono associati ai pagamenti intermedi.

L'integrazione con il velivolo

Questa fase consiste l'installazione a bordo del velivolo di tutta l'avionica, in parallelo al disegno di tutti gli schemi di installazione e documentazione correlata. Il progetto di installazione, tutt'altro che banale, deve tener conto di:

• visibilità ed accessibilità degli strumenti per il pilotaggio e per la missione
• dimensioni delle LRU
• raffreddamento delle avionics bay (si preferisce sempre un sistema non forzato e non condizionato, per non introdurre ulteriori fattori di rischio)
• interferenze elettromagnetiche condotte e irridiate tra apparati di bordo
• interference EMP e di origine esterna (es. fulmini)
  • mitigazione interferenze sopra descritte (shielding, grounding, bonding, filtering, circuit design, blanking)
• antenne (posizione, dimensione ground plane, disaccoppiamento, probabilità di rottura, resistenza aerodinamica, irradiazione, assenza di elementi strutturali disturbanti)
• vibrazioni: le LRU sono qualificate per una determinata soglia di vibrazioni che deve essere rispettata. A volta si pongono le unità avioniche su ammortizzatori per ridurre le vibrazioni.
• controllo del peso: il peso degli apparati avionici non è limitato alle LRU in sè, ma anche dai cablaggi e relative schermature, ai supporti strutturali e agli eventuali sistemi di ventilazione e raffreddamento.
• posizionamento degli apparati/cablaggi duplicati in zone diverse
• posizionamento dei cablaggi rispetto alla struttura del velivolo per evitare chaffing

Il problema dei limiti di peso è spesso oggetto di revisioni continue durante il progetto, per attivare tempestivamente le azioni correttive necessarie. Queste rigorose tecniche di controllo del peso, attuate tra ingegneri aeronautici e avionici, sono essenziali per evitare azioni correttive, che in questo caso risultano molto costose e difficili da attuare.

Prove di volo

Per approfondire questo argomento, consulta la pagina Materia:Sperimentazione in volo.

Le prove di volo sono il processo finale dell'integrazione. Esse vengono avviate dopo il rilascio dell'EFA (Experimental Flight Approval), cioè con la red label. Si occupano di testare in un ambiente reale e condizioni reali, l'avionica e il velivolo in generale. Il sistema ormai collaudato a terra e pronto per la prova in volo è assente da bug o comunque con un numero e severità di bug che permettono comunque la prova. Eventuali problemi trovati possono poi essere corretti sempre attraverso un rigido processo controllato. Caso tipico di queste modifiche è il tuning delle leggi di controllo (dell'autopilota ad esempio), non perfettamente testabili a terra.