Introduzione allo standard DO-254

Nei sistemi safety critical, in particolare in ambito avionico, tutte le fasi di pianificazione, definizione e progettazione di un sistema embedded sono delineate e condotte al fine di ottenere la certificazione del prodotto secondo determinati standard.

Quando si parla di applicazioni o sistemi safety-critical ci si riferisce a sistemi embedded che possono causare danni o perdite di vite umane nel momento in cui in essi si verificano errori o failure. In tale categoria rientrano i sistemi embedded aerotrasportati utilizzati negli aerei militari, come il Flight Control Computer o il Mission Computer,  i  quali sono sviluppati seguendo precise linee guida tali per cui il progetto è sviluppato secondo il livello di safety prestabilito a partire dalla fase di definizione e stesure delle specifiche fino alla progettazione finale. Se dal punto di vista dello sviluppo software il riferimento assoluto è l’RTCA DO-178B, per quanto attiene alla progettazione dell’hardware il riferimento è l’ RTCA DO-254. Tale standard fornisce esclusivamente linee guida, vale a dire concetti ad alto livello e considerazioni ai fini della certificazione e non in che modo esse devono essere rispettate e realizzate. Dal 2005 la FAA (Federal Aviation Administration) e l’EASA (European Aviation Safety Agency) hanno impresso una significativa spinta verso l’adozione di quello che in europa è conosciuto come standard ED-80. 

Sebbene l’intendimento iniziale fosse quello di applicarlo a tutta la progettazione hardware, a causa dei notevoli costi che le aziende avrebbero dovuto affrontare per essere compliant con la DO-254, si è deciso di limitare l’applicazione ad hardware programmabile: FPGA,ASIC e PLD. Si è fatto riferimento al 2005, quindi è evidente come molti apparati nati prima di quella data possano essere certificati attraverso un processo di reverse engineering che sostanzialmente si può ritenere accettabile in situazioni simili. Non lo è per apparati di nuova generazione dove un’applicazione del suddetto processo può determinare non solo problemi di certificazione ma anche un processo di progettazione del sistema poco solido. Si è fatto cenno all’aumento dei costi poiché possono lievitare in modo considerevole fino ad arrivare a toccare aumenti pari al 300% strettamente legati al livello di sicurezza che si intende perseguire. In modo analogo possiamo formulare la considerazione sui costi per quanto riguarda la certificazione del software, in questo caso lo standard di riferimento è l’ RTCA DO-178B e i costi possono raggiungere i 100$ per linea di codice sviluppata. Se pensiamo ad un sistema embedded strutturato da hardware e software risulta evidente quanto le attività di certificazione incidano sui costi, sebbene un uso competente dei relativi standard può aiutare a contenere gli investimenti. Qui di seguito riportiamo gli aspetti essenziali dello standard il cui scopo è chiaramente quello si assicurare la sicurezza in volo dell’hardware.

Figura 1: una errata valutazione delle specifiche di safety può portare a conseguenze molto gravi.

Figura 1: una errata valutazione delle specifiche di safety può portare a conseguenze molto gravi.

DO-254: LA SCELTA DEL LIVELLO DI SAFETY

La prima fase da intraprendere è quella della definizione del livello di criticità del sistema e di conseguenza occorre stabilire gli effetti che una condizione di “failure” può determinare; in questa fase si segue il cosiddetto processo di valutazione della sicurezza del sistema (System Safety Assessment Process) nel quale si indicano 5 livelli di criticità:

  • A: Catastophic: può seriamente minare la sicurezza del volo e l’atterraggio del velivolo e il cui verificarsi determina vittime tra i passeggeri e l’equipaggio.
  • B: Hazardous: può ridurre in modo significativo la sicurezza e la capacità di volo dell’aereo con possibilità di vittime.
  • C: Major: riduzione dei margini di sicurezza di volo.
  • D: Minor: guasti che non riducono in modo significativo la sicurezza determinando al più un volo poco confortevole per i passeggeri e per l’equipaggio.
  • E: No Effect: guasto o failure che non impatta sulle funzionalità dell’aereoplano.

Come si vede dalla figura 2 il documento comune a tutti i livelli e che è fondamentale per la certificazione è il Document Design Assurance Approach, quello che più avanti vedremo essere il PHAC.

Figura 2: processo per la scelta della corretta criticità.

Figura 2: processo per la scelta della corretta criticità.

Inoltre per i livelli A, B e C è necessario produrre il documento dove si evidenziano gli aspetti dei criteri di sicurezza del sistema. Risulta di fondamentale importanza scegliere correttamente il livello di safety sebbene possa risultare non immediata ad un primo approccio. Vi è già memoria di casi nei quali apparati non classificati correttamente (con un livello di safety inferiore ad A) abbiano portato a condizioni di failure di livello A, tali quindi da determinare situazioni critiche e che in alcuni casi hanno fatto precipitare il velivolo interessato. Negli ultimi tempi si è iniziato a parlare della necessità di classificare tutti gli apparati come livello A per evitare situazioni nelle quali un guasto di apparecchiature di livello C o anche inferiore possa determinare incendi o rotture tali da determinare situazioni di rischio elevato. La DO-254 indica inoltre processi maggiormente rigorosi in base alla complessità dell’hardware, unitamente quindi alla classificazione nei livelli di cui si è parlato in precedenza. Da qui nasce la distinzione che sfocia nelle seguenti due categorie:

  • Semplice: si può ritenere sufficiente un un certo numero di test per determinare in modo completo e preciso la corretta funzionalità in tutte le condizioni operative.
  • Complesso: hardware complesso come lo è la maggior parte degli FPGA.

DESCRIZIONE DELLA SPECIFICA: L’HARDWARE DESIGN LIFECYCLE

La specifica DO-254 descrive il cosiddetto “Hardware Design Lifecycle” nel quale vengono indicate tutte le fasi da seguire per arrivare alla certificazione del prodotto. I punti essenziali che lo costituiscono, in riferimento anche a quanto riportato in figura 3, possono essere riassunti nei seguenti punti chiave:

  • Il processo di pianificazione deve essere completato prima che ogni altra fase di sviluppo del progetto sia portata avanti.
  • Deve essere redatto il planning process che risulta essere il principale documento di pianificazione, il PHAC (Plan for Hadware Aspects of Certification).
  • I processi di supporto servono per monitorare che il progetto e lo stesso PHAC sia corretto.
  • I criteri di transizione devono gestire e determinare il salto da una fase ad un altra del progetto.
Figura 3: strutturazione dell’hardware design lifecycle.

Figura 3: strutturazione dell’hardware design lifecycle.

Si ha quindi il punto di partenza costituito dal processo di pianificazione che è caratterizzato dalla produzione del documento PHAC al cui interno confluiscono tutti gli altri documenti di design, validation, configuration management e process assurance, unitamente al processo di design; tutto questo è coadiuvato dai processi di supporto di cui parleremo più avanti. Il planning process è un documento fondamentale per la certificazione poiché esso definisce sia in che modo le specifiche hardware tracciano la funzionalità del sistema sia il processo che dimostra il livello di safety definito. Riassumendo, gli obiettivi del PHAC sono dunque di definire l’intero ciclo di vita della progettazione hardware, definire tutti i piani con la completa indicazione degli ambienti di sviluppo e i tools utilizzati e infine definire la documentazione di quale livello di safety si vuole perseguire.

FASE PROGETTUALE: IL DESIGN PROCESS

La parte più corposa della DO-254 si trova nella fase di progettazione, la quale è costituita da una serie di processi di cui qui di seguito si riporta l’elenco e la descrizione.

Requirements capture: tutte le specifiche di progetto vengono inserite in documenti o inseriti all’interno di un tool apposito come il noto DOORS. I requisiti possono essere di alto livello e anche derivati, ossia delle specifiche addizionali catturati per deduzione. Lo standard fornisce le linee guida per l’attività di cattura dei requisiti:

  • tutti i requisiti di sistema implementati in hardware devono essere documentati;
  • i requisiti di sicurezza legati all’hardware devono essere documentati, requisiti per esempio che definiscono il funzionamento del sistema a seguito di danni o failure;
  • identificazione delle tecnologie e degli standard utilizzati in fase progettuale; # definizione di tutti i requisiti derivati; # tolleranze ammesse nel progetto;
  • monitoraggio sui requisiti e aggiunte o cambiamenti in virtù del monitoraggio operato.

Conceptual design: indica l’architettura del progetto supportato da modelli concettuali più o meno definitivi, ma di alto livello, in modo che il team che si occupa di review possa stabilire se l’implementazione descritta sia idonea a coprire tutti requisiti. L’utilizzo di una descrizione di alto livello può far uso di diagrammi di flusso, macchine a stati e grafici. I punti chiave di questa fase sono i seguenti:

  • creazione della descrizione ad alto livello dell’hardware;
  • identificazione dei principali componenti e indicazione di quando devono o non devono essere utilizzati;

Detailed design: facendo uso dei primi due processi, si esegue tutto il flusso progettuale dell’FPGA a partire dalle considerazioni di design dell’RTL; anche per questa fase la DO-254 fornisce una indicazione di quelli che devono essere i punti chiave:

  • scrittura del codice HDL;
  • implementazione delle tecniche di progettazione dell’architettura;
  • assegnazione dell’impatto sulla sicurezza di ogni funzionalità non utilizzata.

Implementation: in seguito al processo descritto nel punto 3 viene prodotto il dispositivo; gli aspetti fondamentali del processo di implementazione sono:

  • approvvigionamento delle componenti interessate;
  • costruzione del dispositivo;
  • programmazione del dispositivo;
  • assemblaggio;
  • ispezione e test.

Production transition: in questo processo sono analizzati tutti i dati essenziali per poter riprodurre l’hardware nel rispetto delle seguenti linee guida:

  • preparazione dei dati di fabbricazione a partire dai dati di progetto;
  • controllo dei dati di fabbricazione;
  • definizione di ogni specifica di fabbricazione in relazione alla sicurezza;
  • test di accettazione nei quali si è sicuri che il prodotto fabbricato sia compliant con le specifiche.

I PROCESSI DI SUPPORTO

Si è fin qui analizzata la parte nella quale si mettono a punto i piani e la fase di progettazione, costituita da una serie di sotto processi che ne definiscono gli aspetti principali. A queste due macro fasi lo standard ritiene obbligatori l’uso dei processi di supporto di cui si riporta la strutturazione:

1- Requirements validation, fase in cui un gruppo di ingegneri controlla tutte le specifiche per accertare che esse siano valide; si pone l’attenzione ai requisiti derivati sebbene non tutti debbano esserlo; in particolar modo sono validati tutti i requisiti derivati che hanno un impatto sulla sicurezza. La validazione è condotta attraverso una serie di test ed analisi supportati in fase finale da documenti che ne evidenzino i risultati ed eventualmente la differenza tra i dati attesi e quelli avuti in fase di test.

2- Verification process, processo in cui si verifica che l’implementazione hardware rispetti le specifiche; tale fase è condotta in riferimento alle seguenti linee guida:

  • identificazione dei requisiti che necessitano di essere verificati;
  • verifica di ciascuno di essi attraverso simulazioni, tests, analisi e reviews;
  • verifica della copertura delle analisi, ossia ogni requisito deve essere coperto da un test;
  • documentazione dei risultati.

3- Configuration management process: è un processo utilizzato per “fotografare” il sistema software e i dati in un certo istante temporale, di fatto serve per poter gestire tutti i dati, per tenere traccia delle modifiche e dei problem report che vengono di volta in volta aperti attraverso l’utilizzo di un tool apposito come PVCS.

4-  Process assurance: un responsabile della qualità controlla tutte le attività in modo da verificare che esse sia state dichiarate nei piani.

5- Certification liaison: attività nella quale vi è l’incontro tra chi produce il progetto e chi è responsabile della certificazione e nella quale vengono discussi e approvati i piani.

LA QUALITÀ DEI DATI

La grande mole di documenti costituita da dati, specifiche, requisiti e procedure di test necessita di essere caratterizzata da una certa qualità, consistenza e coerenza. A questo riguardo vi è una precisa indicazione sul fatto che essi debbano essere:

  • non ambigui, una sola possibilità di interpretazione;
  • completi, tutti i requisiti devono essere presenti;
  • verificabili, in modo che i dati e tutti i requisiti possano essere verificati;
  • consistenti, in modo che non si determino conflitti tra di essi;
  • modificabili, in modo che sia possibile modificare un dato senza determinare la variazione della struttura o della architettura;
  • tracciabili, in modo che l’origine del dato possa essere recuperata o ricostruita.

Infine ma non ultimi ci sono due altri supporting process menzionati dalla DO-254:

  • Tool assessment, fase che assicura che tutti i tools utilizzati in questi processi siano accurati ed appropriati e qualificati.
  • Requirements traceability, in cui si accerta che il design e i relativi test coprano tutti i requisiti e viceversa.

Un aspetto essenziale di tutto il progetto, e quindi delle attività che conducono alla certificazione, è rappresentato dai tools EDA i quali sono essenziali per la progettazione hardware. Risulta evidente che ciascun aspetto della DO-254 che si intende implementare e automatizzare con un tool deve essere qualificato utilizzando il processo indicato dallo stesso standard.

CONCLUSIONI

Si è cercato di affrontare gli aspetti essenziali e piuttosto complicati relativi alla certificazione di apparati safety-critical, certamente non in modo esauriente vista la complessità e le competenze in gioco. Di questo articolo si colgano gli aspetti qualitativi di quello che di fatto è l’aspetto fondamentale della progettazione di un sistema embedded.

 

 

Scrivi un commento

EOS-Academy