Sicurezza di prodotto o di processo?

Se passi davanti a un negozio IKEA, può capitare di trovare questo strano dispositivo:

 

È una scatola di plexiglas trasparente, contenente una poltrona IKEA, uno strano braccio robotico con due grandi pistoni che spingono la sedia e un contatore. È una specie di esperimento di simulazione di una persona di 80 kg. seduto e in piedi, ripetuto per migliaia e migliaia di volte.

Probabilmente hai guardato il bancone, hai visto un numero come 999.999-1.000.000- … e hai fatto un po’ di matematica mentale…

“Probabilmente io e la mia famiglia potremmo sederci e alzarci in media 10 volte al giorno, 3.650 totali all’anno … quindi questo la sedia durerà almeno 300 anni “

E con la giusta fiducia nella sua robustezza, hai deciso di comprarla.

Ora pensiamo a un software critico per la sicurezza: ti potrebbe essere richiesto di certificare secondo il severo standard DO-178C, fino al livello A. Bene, guardando questa o altre normative di sicurezza correlate, potresti trovare che associato al livello A, hai una probabilità di errore 10E-9 ore di volo. Ok, ancora matematica… significa:

1 miliardo di ore senza problemi, o meglio 11.574 anni

Undicimila anni! Sembra abbastanza buono, non è vero? Tranne il fatto che… per il software, in realtà non funziona così. Cosa significa veramente DAL-A? Letteralmente, significa Design Assurance Level: garanzia del DESIGN.

Ma la vera probabilità di un guasto del software è molto più alta … alcuni esperti dicono che la probabilità è 1 ovvero il 100%! Potresti essere abbastanza sicuro che il tuo software fallirà! Pensa al tuo sistema operativo desktop o mobile … puoi immaginare un’app per il tuo smartphone o computer che resista migliaia di anni senza crash o bug?

E pensi che il software avionico possa essere reso così solido per millenni? Possa davvero essere rilasciato fin dall’inizio totalmente senza bug?

NON E’ COSI’

ed ora ti spiego perché.

Una sedia IKEA è un dispositivo semplice; ha solo due stati principali: vuoto o con qualcuno seduto. In questo modo, puoi facilmente simularlo e testarlo, sottolineando, fino al punto in cui si rompe, dopo forse milioni di cicli. Quindi calcoli l’uso quotidiano di una sedia di questo tipo in una famiglia, e hai la durata media di questa sedia, o meglio una distribuzione di difetti simile a Gauss, e puoi calcolare l’MTBF (Mean Time Between Failures).

 

Puoi calcolare anche come si rompe: dove sono i giunti critici, le modalità di guasto e fare un’analisi di sicurezza completa. Puoi stare certo che IKEA l’ha fatto per te.

Con una resistenza elettronica, puoi fare lo stesso. È un dispositivo semplice: dai un po ‘di tensione e corrente, e hai una caduta di tensione. È possibile testarlo estensivamente, fornire tutte le tensioni possibili in un intervallo e verificare i risultati previsti, costruire la relazione proporzionale simile a Ohm tra corrente e tensione. È possibile testare anche la sovratensione, controllare come si rompe e analizzare le modalità di guasto: si rompe come un circuito aperto? O corto circuito?

Puoi farlo milioni di volte e in un tempo relativamente breve hai un’analisi completa della sicurezza del tuo dispositivo semplice, completo di MTBF, distribuzione degli errori, FMEA (Failure Mode and Effects Analysis) e così via. Puoi fare lo stesso con tutti i dispositivi semplici: condensatori, induttori e porte AND / OR / NAND digitali. Puoi testarli in modo esauriente e fare un’analisi completa della sicurezza.

E anche se colleghi insieme un numero relativamente piccolo di dispositivi semplici, potrebbe essere possibile testare in modo esaustivo tutte le possibili combinazioni e permutazioni di Input, Output e stati, quindi combinarli insieme riconducendo il tutto a un altro dispositivo “semplice”. Finché il numero di IO è gestibile dalle attuali tecnologie di calcolo e test, si potrebbe pensare di trovare tutti i possibili errori e quindi dichiarare di aver prodotto un’analisi di sicurezza completa.

Bene, abbiamo capito una cosa fondamentale:

sedie, resistori e condensatori IKEA hanno qualcosa in comune

sono dispositivi semplici e per loro possiamo realizzare ciò che chiamiamo Product Assurance. Possiamo garantire che questo prodotto abbia un livello preciso e misurabile di qualità e sicurezza. La scienza ci consente di dire con sufficiente certezza che la probabilità che si rompa in media nelle prime 1.000-10.000-10.000 ore di lavoro è così piccola che potrebbe essere impercettibile.

Ok, e allora che mi dici del software?

È possibile avere… Product Assurance per il software?

Purtroppo NO!

Sì, puoi prendere in considerazione pochissime dichiarazioni IF-THEN o WHILE-LOOP come se fossero elementi di un semplice dispositivo, con un numero finito di possibili risultati … ma non appena il numero di possibili percorsi nel tuo codice, o meglio la complessità ciclomatica, diventa poco più che banale … il numero di casi di test necessario per testare in modo esaustivo il tuo codice diventa facilmente ingestibile con le tecnologie attuali e future.

Supponiamo di non avere solo variabili BOOLEAN con valori FALSE / TRUE o 0/1: con numeri interi, potrebbe essere necessario 256 o 65.536 o 4 miliardi di vettori di test diversi per un solo ingresso. Non appena hai 2-3 o più variabili di input, il prodotto cartesiano e così la dimensione del vettore di test diventa troppo grande per essere gestibile. E se hai variabili FLOAT o DOUBLE, il numero di testate teoriche diventa più o meno infinito. Puoi raggiungere numeri impossibili se vuoi avere una prova completa e completa anche con poche righe di codice, dimentichiamoci se hai migliaia o anche milioni di LOC. Quindi, per il software, non si può avere alcuna confidenza sulla probabilità di errori, fino al punto che fissiamo convenzionalmente quella probabilità a 1: fallirà.

E ora la vera domanda:

Che cosa sono allora gli standard di sicurezza come DO-178C per l’aviazione, ISO 26262 per il settore automobilistico, IEC 61508 per l’industria, 501K per il settore medico?

E non stanno forse consentendo…

migliore SICUREZZA?

 

Sì, certo: ma stanno dando una garanzia di un prodotto migliore per il nostro software?

Beh no.

Quindi potrei misurare la sicurezza e la probabilità di errore del mio software?

In nessun modo…

Posso migliorare la qualità del mio software utilizzando questi standard di sicurezza?

CERTO!

Ma solo indirettamente: potresti migliorare il design, ma non direttamente la qualità del prodotto finale, o almeno non in modo quantitativo e misurabile. Questi standard non stanno realmente parlando della qualità del tuo PRODOTTO, ma piuttosto della qualità del tuo PROCESSO. Esatto: ti danno Process Assurance, o garanzia del processo.

I 71 obiettivi dello standard DO-178C non stanno davvero discutendo su come controllare o migliorare direttamente le metriche del software. Non hanno un impatto diretto e misurabile sulla qualità del tuo codice. Non ti costringono a utilizzare metodologie Agile, Spiral o Waterfall.

All’Authority non interessa direttamente il tuo linguaggio di programmazione: in teoria, sei libero di usare quello che vuoi. Non parlano di processi, thread, RTOS. Non parlano di problemi in tempo reale, concorrenza, fame, deadlock. Non parlano di modelli di codifica suggeriti come Publisher / Subscriber, Singletons o Letter / Envelop. Non ti suggeriscono nemmeno esplicitamente di utilizzare uno specifico standard MISRA o JSF o qualsiasi altro stile di codifica particolare!

In altre parole:

gli standard safety-critical non si preoccupano direttamente del modo in cui programmate e quali sono i miglioramenti delle metriche che dovreste aspettarvi applicando lo standard di sicurezza.

E quindi, che cosa è realmente importante? I 71 obiettivi sono principalmente legati al tuo processo e al modo in cui svolgi alcune attività fondamentali:, che sono state poi riprese in maniera ridotta ed adatta a tutti nel METODO DELLO SVILUPPO EFFICIENTE del software:

• PIANI: la pianificazione è un’attività preliminare fondamentale che devi completare e far approvare dall’autorità certificativa prima di iniziare qualsiasi altra cosa
• REVIEW: ciò che è veramente importante per gli standard di sicurezza non è solo il modo iniziale di scrivere requisiti, codice o qualsiasi altra cosa. È l’attività di revisionarlo, in particolare la peer-review. Un altro ingegnere, con un livello di esperienza simile, deve revisionare tutto ciò che fai e viceversa. Questa è la chiave per migliorare la qualità dell’output di qualsiasi attività
• STANDARD: tutto ciò che fai, i requisiti, la codifica, la programmazione devono essere soggetti a uno standard. Non è obbligatorio un particolare standard di settore, quindi puoi scegliere il tuo
• CHECKLIST: al fine di ridurre la soggettività del processo di revisione, l’introduzione di una lista di controllo formale da compilare per ciascun deliverable è obbligatoria al fine di avere un processo ripetibile
• TEST: ovviamente il test è importante, molto importante: la maggior parte del tempo (e del budget!) Nel tuo ciclo di vita viene speso per i test. Unit Test di piccole funzioni, integrazione di più funzionalità, System Test… Whitebox/Blackbox… su host, simulatore e target. Per cui è necessario prendere in considerazione un enorme investimento di tempo e di risorse, molto più di ogni altra attività
• QUALITY ASSURANCE: il responsabile dell’assicurazione di qualità è il direttore dell’orchestra. Si assicura che i piani, gli standard, le liste di controllo siano seguiti a fondo e che i 71 obiettivi siano tutti raggiunti.

Quindi … una domanda a cui verrà data una risposta completa in un altro articolo:

è possibile avere Product Assurance anche per il software?

La risposta è un no parziale … non solo con DO-178B / C e non con le tradizionali tecniche di programmazione e test.

Non c’è modo di garantire in modo formale o statistico che il tuo software di livello B sia 1x10E-2 più sicuro di un livello DAL-C e peggio di un software di livello DAL-A di garanzia del design.

Non esiste un tasso di fallimento diretto o misurabile che puoi usare per dimostrare qualcosa in modo formale.

L’unica cosa di cui puoi essere sicuro, è che il processo di progettazione di un livello B è davvero migliore di un livello-C, e peggiore di un livello-A. Questo è ciò che abbiamo chiamato: DESIGN o PROCESS ASSURANCE.

Il software avionico sviluppato secondo DO-178 è ancora sicuro?

Direi di sì, perché circa il 99,99% dell’attuale software aeronautico avionico è stato sviluppato secondo gli attuali standard di sicurezza DO-178B e nessun incidente nel servizio passeggeri è stato attribuito solo a errori software. Ma la sicurezza è indiretta: con un processo migliore, probabilmente avrai un software migliore, ma non potresti misurare direttamente in termini di probabilità di incidenti, ma solo indirettamente come conformità allo standard DO-178B / C.

Quindi quando e come sarà adatto avere Product Assurance per il software?

Questo sarà sempre più possibile grazie ai metodi formali. Un’Analisi Formale eseguita su una quantità relativamente piccola di codice (ora poche centinaia di linee, ma si sta migliorando sempre di più) e su un insieme limitato di proprietà potrebbe darti la sicurezza, la solidità o la probabilità del 100% dell’assenza di alcune categorie di errori.

E il supplemento DO-333 “Formal Methods” rilasciato insieme a DO-178C è ora disponibile per supportare la certificazione usando questo modo alternativo di dimostrare in modo matematico e formale la correttezza del tuo software. Questo è qualcosa di nuovo e rivoluzionario, anche se è stato già utilizzato in molti progetti di avionica da alcune importanti compagnie aerospaziali.

Ma questo è un argomento per un altro articolo…

 

Se vuoi ricevere questi articoli via email o comunque vuoi essere aggiornato quando ne scrivo uno nuovo, scrivimi a: blog@softwaresicuro.it

 

Autore: Massimo Bombino