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[modifica | modifica wikitesto]

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[modifica | modifica wikitesto]

Design Assurance Levels[modifica | modifica wikitesto]

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
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: 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[modifica | modifica wikitesto]

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[modifica | modifica wikitesto]

  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[modifica | modifica wikitesto]

Estratto da "https://it.wikipedia.org/w/index.php?title=DO-178&oldid=136228258"