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].

Storia

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]:

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 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
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
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
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
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].

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 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%).

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

Strategi Solo vs Squad di Free Fire: Cara Menang Mudah!