DO-178
# 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 dei software in ambito aerospaziale. 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 e hanno assunto un ruolo importante nello sviluppo di nuove metodologie di sviluppo e testing del software critico.

Almeno fino all'incidente dei voli ET302 e Lion Air 610, le quali indagini al 2020 ancora procedono, secondo l'NTSB queste norme hanno garantito che nessun incidente mortale può essere direttamente attribuito a un errore di progettazione del software.

## Storia

La prima versione di questo standard, datata 1981 e chiamata DO-178 senza alcuna lettera a suffisso, era più una raccolta di buone prassi rispetto a norme vere e proprie. Successivamente, il comitato RTCA Special Committee 152 pubblica nel 1985 un documento molto più approfondito e tecnico rispetto alla precedente versione. Questo nuovo standard, chiamato DO-178A, introduce 3 livelli di criticità del software, poi tradotti nei 5 livelli chiamati Design Assurance Levels delle versioni successive. 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. In questa versione si è dato particolare enfasi alla specifica dei requisiti e al processo di analisi di essi, al fine di soddisfare i requisiti dello sviluppo di software critico. Infine, nel 2011, a distanza di quasi 20 anni, la nuova norma DO-178C viene rilasciata e applicata. Questa versione, oltre a chiarimenti e modifiche minori di terminologia, introduce i riferimenti normativi necessari per l'uso di:

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

### Versioni

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

## Design Assurance Levels

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. Essi sono:

| 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 | $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 | $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 | $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 | $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: il programmatore che sviluppa il codice deve essere una persona diversa da chi compie le verifiche. 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.

## Il processo di sviluppo

Le attività che regolano il processo di sviluppo sono categorizzate in:

* 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 al 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:

* Pianificazione (Planning)
* Analisi degli standard e requisiti (Standards and Requirements)
* Sviluppo - Design e programmazione (Development - Design and Coding)
* Verifica e testing (Verification and Testing)
* Controllo della qualità (Quality Assurance)
* Certificazione (Certification)

Vista la criticità dei software prodotti, 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, implementazione del codice occupa in media appena il 20% del tempo totale richiesto per lo sviluppo del codice avionico. Invece, le parti più dominante risultano essere la verifica (35%) e la parte di analisi dei requisiti (25%).

