Come viene testato il software nei sistemi critici vita o morte?

Un aereo, al contrario, ad esempio, di un sito Web, è un sistema in cui qualsiasi guasto in alcuni sistemi è completamente inaccettabile, poiché errori nel monitoraggio del volo possono causare malfunzionamenti al pilota automatico e fare immersioni. Ovviamente, ciò non accade dal momento che i geniali ingegneri di Boeing e Airbus hanno controlli nell'autopilota per assicurarsi che non si decida improvvisamente che un'immersione sia una manovra perfettamente accettabile e sicura. O forse il computer si arresta in modo anomalo e i piloti del nuovo velivolo fly-by-wire non possono più far volare l'aereo. Naturalmente, ci sono varie procedure di sicurezza e ridondanze integrate in questi sistemi per prevenire un incidente (sia del software che dell'aeromobile).

Tuttavia, d'altra parte, è abbastanza ovvio che il software non è perfetto: sia il software open source che quello chiuso si bloccano regolarmente e solo il programma "Hello World" più semplice non fallisce. Come possono gli ingegneri che progettano i sistemi software nell'industria aeronautica, medica e in altri settori della vita o della morte riuscire a testare il loro software in modo che non fallisca (e se fallisce, almeno fallisce con grazia)?

_{Spero disperatamente che non andrai tutti: "Oh, lavoro per Boeing / Airbus / (qualche altra compagnia) e non lo è! Divertiti al tuo prossimo volo / visita in ospedale."}

Ho lavorato molto nei controlli industriali. Non deve essere in un settore glorioso come quello aerospaziale. Quasi tutte le macchine industriali dispongono di energia potenziale sufficiente per causare lesioni gravi o mortali. Sono stato in giro quando le persone sono rimaste ferite. Se passi la maggior parte del tempo a una scrivania in un ufficio, probabilmente rimarrai sorpreso da quanto possano essere pericolosi (e sicuramente lo sono stati fino a poco tempo fa) la maggior parte dei lavori di fabbrica. Ora abbiamo metodi migliori per la protezione delle macchine. Ecco come funziona in pratica (anche se varia da giurisdizione a giurisdizione):

Esistono standard OSHA negli Stati Uniti e linee guida simili (di solito più rigorose) nell'UE. Questi generalmente iniziano richiedendo di fare un'analisi del rischio. Ciò significa che fai un elenco di tutti i pericoli e poi li categorizzi, tenendo conto di cose come la frequenza con cui una persona sarebbe esposta al rischio, quanto è facile evitare il rischio (dipende dalla velocità, ecc.) E cosa è la gravità del risultato (taglio, amputazione, morte, ecc.).

Molte analisi hanno a che fare con la protezione dei pericoli. Se si mette una grande gabbia attorno alla macchina e la si serra saldamente, la macchina viene considerata sicura se i componenti della macchina non possono violare la protezione. Se hai bisogno di uno strumento per entrare, questo è considerato un compito di manutenzione e gli addetti alla manutenzione dovrebbero essere addestrati su come lavorare in sicurezza su una macchina. In realtà, tuttavia, la maggior parte delle macchine necessita di una regolare interazione con gli operatori, quindi dobbiamo mettere le porte di accesso nella protezione, o le barriere fotoelettriche, ecc. Quelle porte e le barriere fotoelettriche devono essere monitorate e la potenza dei pericoli a cui l'operatore si sta esponendo deve essere spento in modo "affidabile dal controllo".

Sulla base di tale analisi, il rischio è suddiviso in varie categorie. Una scala di classificazione comune è dalla Categoria 1 alla Categoria 4 (basata sulla norma EN 954-1). Sulla base di tali categorie, l'utente è legalmente tenuto a fornire un certo livello di protezione e sicurezza della macchina.

La categoria 4, ad esempio, richiede che:

Un singolo errore in ciascuna di queste parti non provoca la perdita della funzione di sicurezza.

Il singolo errore viene rilevato con o prima della successiva richiesta alla funzione di sicurezza oppure, se ciò non è possibile, un accumulo di guasti potrebbe non causare la perdita della funzione di sicurezza.

In pratica ciò può essere difficile da raggiungere, ma è reso più semplice dalla disponibilità di componenti standard certificati per la Categoria 4. Ad esempio, un componente comune in questi sistemi è un relè di sicurezza. Questi sono più che semplici relè meccanici:

• Sono progettati per monitorare doppi canali di ingresso ridondanti, quindi se si dispone di un sensore che rileva una condizione di guasto (come una porta di protezione aperta), in genere ha due contatti con circuiti ridondanti. Il relè controlla entrambi i canali e, se uno dei due si apre, interrompe l'alimentazione degli attuatori, ma se entrambi non si disattivano contemporaneamente, entra in una condizione di guasto e la macchina non può essere riavviata fino alla riparazione .
• Il relè utilizza anche impulsi elettrici su quelle linee e utilizza tali segnali per monitorare i fili incrociati o in corto, in modo da poter rilevare un guasto del cablaggio.
• Sul lato di uscita, utilizza una serie di doppi circuiti per pilotare le bobine di uscita, quindi se uno si guasta nella condizione "on", l'altro dovrebbe impedire che l'uscita venga eccitata. Inoltre, vengono monitorati e, se viene rilevato un errore, ne impedisce il funzionamento. Le bobine stesse sono in realtà relè a doppia forza che significano relè fisici ridondanti sull'uscita, oltre a garantire che i contatti su ogni singolo relè siano fisicamente collegati tra loro in modo che un contatto su, diciamo 4, non possa essere bloccato da solo. Anche questi sono monitorati.
• Include anche un ingresso per monitorare un contatto ausiliario normalmente chiuso dal carico che si sta controllando. Se disattiva l'uscita, deve vedere il contatto normalmente chiuso impegnarsi, il che significa che convalida di aver spento il contattore del motore, o qualunque cosa fosse, prima che gli fosse permesso di tornare alla condizione di accensione.

Come puoi vedere, si tratta di dispositivi complicati. I costi tipici sono compresi tra $ 200 e $ 600 per ciascun relè di sicurezza. Ovviamente c'è un software in questi dispositivi. Per ottenere la certificazione del tuo relè di sicurezza, in genere devi seguire un design come questo:

• Due processori ridondanti, in genere provenienti da fornitori diversi, basati su progetti diversi.
• Il codice in esecuzione su ciascun processore deve essere sviluppato da due team che lavorano in condizioni isolate. Ciò impedisce che un singolo bug software sia un singolo punto di errore.
• L'uscita di entrambi i processori deve concordare altrimenti i guasti del relè di sicurezza.

Dopo aver progettato il sistema di sicurezza per la tua macchina, utilizzando componenti con classificazione di sicurezza, devi sottoporre a revisione il progetto e timbrarlo da un ingegnere professionista. Quindi costruisci la macchina. Quindi il P.Eng. esaminerà la costruzione della macchina assicurandosi che sia stata costruita secondo il progetto. Lo documenteranno e eseguiranno alcuni test per assicurarsi che funzioni come previsto. Questa si chiama revisione pre-avvio (PSR) e non viene eseguita in tutte le giurisdizioni. Dopo che il PSR è passato, è possibile far eseguire alla macchina un operatore.

Negli ultimi anni ci sono state alcune rivoluzioni nei sistemi di sicurezza. Per un po 'nessuno si è fidato della trasmissione di dati di sicurezza su una rete, quindi i cosiddetti "sistemi di I / O distribuiti" come DeviceNET ed EtherCAT non sono stati ammessi nella parte di sicurezza del sistema. Tuttavia, i protocolli recenti ora consentono ai dispositivi di sicurezza di funzionare su queste reti industriali. I protocolli utilizzano messaggi con data e ora e doppia elaborazione ridondante su entrambe le estremità della connessione.

I relè di sicurezza stanno lentamente prendendo la strada dell'uccello dodo, sostituito da più complicati PLC di sicurezza, che sono come un modo per costruire la logica di sicurezza in un linguaggio di diagramma a blocchi funzionali. Ancora una volta, questi PLC di sicurezza utilizzano tutto ridondante. Quando il programma viene approvato, prima che la macchina venga messa in servizio, il P.Eng. timbrerà il programma e il programma / PLC verrà bloccato con una password. Prende anche un hash del programma e quell'hash è registrato nella documentazione (questo è ciò che il P.Eng. Sta davvero timbrando).

Ora, una volta progettato il tuo sistema di sicurezza, la logica che scrivi per controllare la macchina stessa può essere molto comoda. I programmatori spesso si rompono le macchine causando danni per migliaia di dollari, ma almeno nessuno rimarrà ferito.

C'è un serio passo in avanti verso la verifica formale piuttosto che i test funzionali casuali.

Agenzie governative come la NASA e alcune organizzazioni di difesa stanno spendendo sempre di più per queste tecnologie.

Sono ancora una PITA per il programmatore medio, ma spesso sono più efficaci nel testare i sistemi critici.

C'è anche la tendenza a provare più tecniche dal mondo accademico, per cose come la convalida del codice multithread.

Dipende dal software. Ad esempio, negli aerei di solito esiste un'elaborazione a doppia ridondanza per i sistemi critici; in casi estremi possono essere utilizzati 2 diversi design hardware e due pezzi di s / w sviluppati in modo indipendente, uno da eseguire su ciascuno. Si calcolano e si confrontano reciprocamente. Questo non è infallibile ed è estremamente costoso.

Quando si tratta di cose come i test dei sistemi aeronautici, ci sono una serie di test effettuati: i test sui sistemi relativi al volo richiedono mesi e se si apportano modifiche, è necessario eseguire un'intera serie di test. Questo di solito viene fatto in un simulatore, che potrebbe effettivamente essere pieno di parti di velivoli reali (ad esempio cabina di pilotaggio) con un motore simulato o simile. Come puoi immaginare, anche questo è terribilmente costoso da costruire. Le modifiche vengono valutate rispetto a un programma di test formale e quindi eseguite su un aereo reale nei voli di prova. Lungo il modo in cui vengono eseguiti test come "disturbi funzionali", è qui che l'oggetto modificato può fare le sue cose normali e tutto viene controllato / testato per vedere che non vi sono effetti deleteri. Questo costa anche un sacco di soldi e può richiedere settimane.

Conosco un esempio in cui era richiesta una modifica molto semplice a un sistema di volo - così semplice che rimarrai sbalordito da quanto minore. Tuttavia, il nuovo test avrebbe richiesto> 3 mesi e sarebbe costato qualcosa come $ 1 milione.

Quando si entra in medicina, ci sono tutta una serie di ostacoli normativi da saltare non solo relativi ai test ma ai processi di sviluppo e alla documentazione.

Tutti questi campi sono un grande passo avanti rispetto a un luogo che ricava un po 'di codice PHP per un sito web. È lento, scrupoloso, difficile, noioso, noioso, meticoloso e molto costoso. Prendi i tuoi normali costi di sviluppo / test e moltiplica per circa 100 e ti stai avvicinando al segno.

Per il software NASA Space Shuttle leggere Hanno scritto la roba giusta . Per la FDA (US Food and Drug Administration) leggi questo

Dal momento che hai già ricevuto risposte fantastiche e istruttive, ecco la mia opinione.

È semplice: il primo test viene sempre eseguito sui programmatori stessi. Tende a mantenere basso il numero di bug e garantisce che solo i programmatori di qualità siano tenuti sul libro paga.

Il software critico per la vita non è testato secondo uno standard diverso da quello "sembra funzionare" , poiché viene eseguito ovunque .

Tutto l'investimento è destinato a ciò che sembrava funzionare prima o ai progetti per consentire ai non programmatori di produrre software migliore .

ps Non ci sono commenti sul primo -1, ma sarei felice di prendere -1per ogni riferimento che contrasta la mia affermazione.

Posso prendere un +1 per ogni riferimento che trovo a software critico non ben progettato o testato? Simson Garfinkel documenta dieci casi in un articolo su WIRED.

Non c'è una risposta per tutti i casi. Spetta al singolo produttore decidere come progettare e testare il proprio software. Ma l'intero processo di sviluppo del software deve essere conforme alle specifiche formali.

Ad esempio, durante la creazione di software per dispositivi medici è necessario seguire lo standard IEC 62304 per il software per dispositivi medici. (Sfortunatamente posso solo collegarmi a Wikipedia in quanto non è gratuito). Praticamente tutti i paesi del mondo richiedono che questo standard sia stato seguito.

La severità di questi requisiti dipende dal rischio di danno. Ad esempio, un dispositivo di supporto vitale avrebbe il maggior rischio di danno (morte certa se il sistema fallisce), mentre un sistema che funziona con la diagnostica delle malattie ha un rischio inferiore (possibile morte se una malattia terminale non è stata diagnosticata correttamente se il sistema fallisce).

Ma ciò che dice sostanzialmente è che deve esserci una tracciabilità dai requisiti al software. È necessario eseguire le verifiche dell'unità software. Ciò non specifica quale sia la verifica. Può essere un test unitario, può essere una revisione del codice. Per i dispositivi a rischio più elevato è necessario rivedere manualmente le interfacce tra le unità software (per quanto ho capito e ricordo). E ovviamente molte altre regole. Oh, e devi scrivere molta documentazione per documentare il tuo lavoro.

Lo standard non proibisce lo sviluppo agile, anche se durante la lettura sembra che sia stato scritto pensando allo sviluppo a cascata.

Non conosco altre aree di sviluppo software, come aviazione, treni, automobili, ecc. Ma presumo che esistano altre linee guida formali simili.

Vengono utilizzate molte tecniche, incluso ma non limitato a:

• progettazione formale e / o validazione
• rigorosi standard di codifica evitando programmazioni elaborate come l'allocazione dinamica della memoria
• ingegneri di qualità molto esigenti
• manys tecniche di analisi statica come revisione del codice, alberi di guasto, FMECA, ...

Ma la tecnica numero uno è:

• COLLAUDO

Il software di un veicolo spaziale richiede più sforzi per testare che per progettare e codificare in primo luogo.

I velivoli sono sottoposti a numerosi anni di prove di volo in cui l'aereo viene portato in situazioni estreme. Questo verifica non solo la struttura fisica ma anche il software.

C'è un articolo "Software perfetto" di Jack Ganssle su EETimes datato 01/03/2009 12:00 AM EST. A pochi punti da lì:

• "Teoricamente, il software è l'unico componente che può essere perfetto e questo dovrebbe essere sempre il nostro punto di partenza." - Lo dice Jesse Poore. Seguendo la sua pagina web scoprirai come realizzare un software perfetto senza costi molto maggiori rispetto al normale software.
• Esistono fornitori industriali di sistemi operativi altamente affidabili. L'articolo menzionava Mircrium e Green Hills. Seguendo la pagina Web di Micrium, ci sono un elenco di standard per le certificazioni. Questi devono essere i processi e le regole che l'industria segue. Questo si basa sulla validazione formale, ma molto deviato dalla teoria.

È interessante notare che, per quanto riguarda il software commerciale, i dati raccolti da Capers Jones suggeriscono che "il software in generale ha un'efficienza di rimozione dei difetti (la percentuale di bug rimossi prima della spedizione) dell'87%. Il firmware ottiene un 94% enormemente migliore". Per me, nessuno di questi è quasi perfetto. L'articolo menzionato in precedenza da un risponditore indica che il team della NASA Space Shuttle ha raggiunto una percentuale di rimozione dei bug del 99%, ma il costo è di 35 milioni all'anno per circa 400k righe di codice.

Un articolo più interessante "Software per sistemi affidabili" dello stesso autore dell'11 / 1/2009 sembra essere più pertinente. Può essere riassunto in questo modo:

• Per quanto riguarda il processo di sviluppo, l'industria ha seguito DO-178B o IEC61508. Sottolinea i test con la massima copertura. Ma poche prove possono essere trovate sull'efficacia di questo.
• Un'autorità di certificazione, il Comitato sui sistemi software affidabili, ha pubblicato un libro intitolato "Software per sistemi affidabili - prove sufficienti". È un buon riferimento.
• Il libro, in sostanza, chiede tre cose: [1] Rendi esplicite regole per i test di affidabilità. [2] Test contro le regole, ma anche assicurarsi che i test siano comprensibili da parte dei normali clienti o regolatori con un tempo inferiore rispetto a quello impiegato dagli sviluppatori. [3] Assicurati che siano gli esperti in ingegneria del software e il dominio dei problemi a fare lo sviluppo e il test.
• Il fornitore di software deve impegnarsi in una garanzia o altri rimedi per eventuali guasti del software.
• Utilizzare un linguaggio sicuro, in particolare non C. SPARK è suggerito.
• Il design per l'approccio contrattuale è uno dei punti di forza di SPARK. La progettazione per contratto è un'importante tecnologia per incorporare i test in ogni chiamata di funzione / metodo ed eseguirla sempre in fase di esecuzione. Più che un semplice assert () ai vecchi tempi, il contratto può anche includere test contro l'intenzione strutturale e assicurarsi che nessuna violazione possa essere introdotta in un secondo momento nel ciclo di manutenzione quando gli sviluppatori originali sono passati ad altri progetti. Ci sono prove che la progettazione per il contratto ha prodotto prodotti software molto affidabili. SPARK e i suoi strumenti possono essere utilizzati per aiutare a generare casi di test di certificazione per semplificare il processo di certificazione.

Secondo la mia memoria, HP ha praticato la progettazione per contratto quasi un decennio fa. Con un piccolo team, 500k righe di codice, solo 2 bug segnalati dopo la consegna. Molto impressionante.

A mio avviso, un software affidabile o perfetto può essere raggiunto solo se il costo non è proibitivamente elevato. Framework o automazioni sono un must.

Di solito hanno un interblocco hardware che viene utilizzato come fail-safe.

Ad esempio, i progetti di caselle di testo standard malvagi per i robot killer sono sempre dotati di un kill switch: P

Ogni settore ha una propria serie di agenzie di regolamentazione che hanno requisiti di test e documentazione per hardware e software relativi alla sicurezza. Considera questo PDF di Underwriters Laboratory (UL) che introduce lo standard UL 1998: http://www.ul.com/global/documents/offerings/industries/hightech/software/UL_softwareconformityassessment.pdf

Ci sono riferimenti in quel documento a molti altri correlati da UL, CSA e IEC.

In genere, il software relativo alla sicurezza avrà circuiti hardware ridondanti o dovrà avere altre funzioni di controllo ridondanti per garantire un funzionamento sicuro e modalità di guasto sicure.