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[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 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[8][9].

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[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à del software, poi tradotti nei 5 livelli chiamati Design Assurance Levels delle versioni successive[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 soddisfare i requisiti dello sviluppo di software critico[10]. 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[13]:

Versioni

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[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 10 − 9 {\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 10 − 7 {\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 10 − 5 {\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 10 − 3 {\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: il programmatore che sviluppa il codice deve essere una persona diversa da chi compie le verifiche[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].

Il processo di sviluppo

Il diagramma concettuale del processo di sviluppo software della norma DO-178B

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 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[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 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[21], 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%).

Note

  1. ^ DO-1 78C compliance: turn an overhead expense into a competitive advantage, IBM, 2014.
  2. ^ Vance Hilderman, DO-178 Introduction Whitepaper, su afuzion.com. URL consultato il febbraio 2020.
  3. ^ Jaiden David Kennedy, Massood Towhidnejad, Innovation and certification in aviation software, in 2017 Integrated Communications, Navigation and Surveillance Conference (ICNS), IEEE, 2017, DOI:10.1109/ICNSURV.2017.8011916.
  4. ^ Leanna Rierson, Developing Safety-Critical Software: A Practical Guide for Aviation Software and DO-178C Compliance, CRC Press, 2017, ISBN 978-1-4398-1369-0.
  5. ^ Software Approval Guidelines (PDF), FAA, 2018.
  6. ^ Frédéric Faubladier, David Rambaud, Safety Implications of the use of systemon-chip (SoC) on commercial of-the-shelf (COTS) devices in airborne critical applications (PDF), EASA, 2008.
  7. ^ The Impact of RTCA DO-178C on Software Development (PDF), Cognizant, 2012. URL consultato il 19 febbraio 2020 (archiviato dall'url originale il 30 agosto 2017).
  8. ^ Sott Beecher, History of Aerospace Software and Standards, su slideplayer.com, 2017. URL consultato il febbraio 2020.
  9. ^ E. Kesseler, Measuring a safety-critical embedded software development process (PDF), National Aerospace Laboratory NLR.
  10. ^ a b c DO-178B and DO-178C, su t-vec.com, t-vec, 2007. URL consultato l'8 marzo 2020.
  11. ^ a b Johnny Cardoso Marques, Modification to Legacy Software Developed per DO-178A Level 1 to DO178B Level A: How to Organize Software Life Cycle Data for Software Approval in Aircraft Certification, 2011.
  12. ^ Advisor Circulary - RTCA, Inc., Document RTCA/DO-I 78B (PDF), su airweb.faa.gov, FAA, 1993. URL consultato l'8 marzo 2020 (archiviato dall'url originale il 18 febbraio 2017).
  13. ^ Small but subsequent changes in DO-178C explain modern technologies and methodologies in clear, concise terminology, su psware.com, Performance Software, 2017. URL consultato l'8 marzo 2020.
  14. ^ What is safety-certifiable avionics hardware that meets Design Assurance Levels (DAL)?, su militaryaerospace.com, 2016. URL consultato l'8 marzo 2020.
  15. ^ RTCA DO-178B Process Visual Summary, su scribd.com. URL consultato l'8 marzo 2020.
  16. ^ Yanyun WANG, Developing Safety Critical Embedded Software under DO-178C[collegamento interrotto], The University of Cincinnati, 2015.
  17. ^ a b Christoph Torens, Florian Michael Adolf, Lukas Goormann, Certification and Software Verification Considerations for Autonomous Unmanned Aircraft, in Journal of Aerospace Computing, Information and Communication, 2014, DOI:10.2514/1.I010163.
  18. ^ Ben Sampson, Getting to grips with software testing, su aerospacetestinginternational.com, Aerospace Testing International. URL consultato l'8 marzo 2020.
  19. ^ Geir K. Hanssen, Gosse WedzingaMartijn Stuip, An Assessment of Avionics Software Development Practice: Justifications for an Agile Development Process, in Lecture Notes in Business Information Processing, Springer, 2017, DOI:10.1007/978-3-319-57633-6_14.
  20. ^ DO-1 78C compliance: turn an overhead expense into a competitive advantage, su ibm.com, IBM. URL consultato il 10 marzo 2020.
  21. ^ Roland Wolfig, Parameters for Efficient Software Certification (PDF), su itk.ntnu.no. URL consultato il 10 marzo 2020 (archiviato dall'url originale il 21 dicembre 2016).

Voci correlate

  Portale Aviazione
  Portale Ingegneria
  Portale Scienza e tecnica