DO-178

I documenti DO-178 (Software Considerations in Airborne Systems and Equipment Certification) sono una famiglia di linee guida, considerate lo standard de facto per lo sviluppo e la certificazione di software in ambito aerospaziale^[1][2][3][4]. Sono sviluppate da RTCA in collaborazione con EUROCAE. Queste norme sono il punto di riferimento per la certificazione degli aeromobili da parte di FAA e EASA^[5][6] e hanno assunto un ruolo importante nello sviluppo di nuove metodologie di sviluppo e testing del software critico^[7].

Almeno fino agli incidenti dei voli ET302 e Lion Air 610, accaduti nel 2019 e le cui indagini al 2020 ancora procedono, secondo l'NTSB, a seguito dell'introduzione di queste normative, nessun incidente mortale occorso a veicoli aerospaziali poteva essere direttamente attribuito ad errori nella realizzazione dei software^[8][9].

La prima versione di questo standard, datata 1981 e chiamata DO-178, senza alcuna lettera a suffisso, era una raccolta di buone prassi e non una vera e propria normativa^[10]. Successivamente, il comitato RTCA Special Committee 152 pubblica nel 1985 un documento molto più approfondito e tecnico rispetto alla precedente versione^[10]. Questo nuovo standard, chiamato DO-178A, introduce 3 livelli di criticità in termini di sicurezza del software, che nelle versioni successive diventarono 5 e vennero battezzati Design Assurance Levels (DAL)^[11]. Nel 1992 viene rilasciata la versione DO-178B, che risulta essere anche la prima ufficialmente approvata un anno dopo da FAA per quanto concerne lo sviluppo software^[12]. In questa versione si è dato particolare enfasi alla specifica dei requisiti e al processo di analisi di essi, al fine di regolamentare lo sviluppo di software critico^[10]. Nel 2011, a distanza di quasi 20 anni, è stata rilasciata l'ultima versione, la DO-178C, attualmente applicata. Questa versione, oltre a chiarimenti e modifiche minori di terminologia, introduce i riferimenti normativi necessari per l'uso di^[13]:

• Model-based software
• Programmazione orientata agli oggetti
• Metodi formali di sviluppo del software

• DO-178 (1981)
• DO-178A (1985)
• DO-178B (1992)
• DO-178C (2011)

Dalla versione DO-178B, cinque Design Assurance Level (DAL), anche chiamati, per compatibilità con altri standard, Item Development Assurance Level (IDAL) o Software Level, sono stati definiti per classificare ogni software secondo l'impatto che un suo malfunzionamento può avere sull'aeromobile e sulla sua operatività. Essi sono^{[14][15][16][17]}:

Livello	Nome	Descrizione	Obiettivi (DO-178B)	Obiettivi (DO-178C)	Tasso di guasto (per ora di volo)
A	Catastrofico (Catastrophic)	Guasti che possono causare un disastro aereo e potenzialmente la morte di tutte le persone a bordo.	66	71	${\displaystyle 10^{-9}}$
B	Rischioso (Hazardous)	Guasti che possono causare una riduzione significativa delle performance del velivolo o della sua sicurezza. Possono potenzialmente causare la morte e il ferimento grave di alcune persone a bordo.	65	69	${\displaystyle 10^{-7}}$
C	Maggiore (Major)	Guasti che possono causare una riduzione delle performance del velivolo, della sua sicurezza o un aumento del carico di lavoro e stress dei piloti. Non è prevista la morte di alcuna persona, ma solo potenziali feriti.	57	62	${\displaystyle 10^{-5}}$
D	Minore (Minor)	Guasti che hanno un qualche impatto, seppur minore, sul volo e sul carico di lavoro dei piloti. Non è prevista la morte o il ferimento di persone, ma solo un eventuale disagio (ritardo del volo, assenza di ricircolo dell'aria, ecc.).	28	26	${\displaystyle 10^{-3}}$
E	Senza effetto (No Effect)	Guasti che non hanno alcun effetto sui piloti o sui passeggeri.	0	0	N.A.

Gli obiettivi si riferiscono a determinate procedure da effettuare per scrivere il software e verificarne la bontà. Alcuni di questi obiettivi richiedono l'indipendenza tra i due processi: chi sviluppa il prodotto non può essere la stessa persona che lo verifica^[17]. Questo metodo non deve essere confuso con il pair programming: in quest'ultimo caso i programmatori lavorano contemporaneamente e in modo collaborativo, mentre nel caso aeronautico le interazioni tra chi sviluppa e chi esegue il testing non sono consentite. In taluni casi, i due processi sono assegnati a unità organizzative o aziende diverse^[18].

Le attività che regolano il processo di sviluppo sono categorizzate in^[19]:

• Pianificazione, che definisce e coordina tutte le attività del progetto
• Sviluppo, in cui si scrive il vero e proprio software
• Integrazione, che assicura la correttezza e rispondenza ai requisiti del software prodotto

Sia la versione B che la versione C della norma prevedono un processo di sviluppo del software articolato in sei fasi principali^[11][20]:

1. Pianificazione (Planning)
2. Analisi degli standard e requisiti (Standards and Requirements)
3. Sviluppo - Design e programmazione (Development - Design and Coding)
4. Verifica e testing (Verification and Testing)
5. Controllo della qualità (Quality Assurance)
6. Certificazione (Certification)

Vista la criticità dei software usati in ambito aerospaziale, la fase di sviluppo del codice vero e proprio non è una parte dominante sul tempo, e conseguentemente sui costi di sviluppo. Secondo una ricerca dell'università di Vienna^[21], l'implementazione del codice occupa in media appena il 20% del tempo totale richiesto per la realizzazione del software avionico, mentre le parti più dominanti risultano essere la verifica (35%) e la parte di analisi dei requisiti (25%).

• Avionica
• Sistema critico

Portale Aviazione

Portale Ingegneria

Portale Scienza e tecnica