La certificazione del software

Il software pervade ormai tutti gli aspetti della nostra vita. Da applicazioni che possiamo definire blande a quelle cosidette di tipo safety-critical, per questo motivo sono state approntate metodologie robuste per qualificarlo.

Ultimamente si parla molto di certificabilità, come se la tecnologia creasse un mondo più rischioso. Infatti, la maggior parte degli incidenti più seri dell’ultimo secolo è avvenuta negli ultimi 30 anni. Solo per fare un esempio, è possibile ricordare la tragedia di Bhopal (India) con 15000 morti e 200000 feriti. Nel panorama del software safety-critical sono nate negli anni diverse agenzie che si propongono di certificare il software e, nel frattempo, diverse normative di riferimento.  Il numero e la natura dei livelli variano, ma l’approccio generale è lo stesso: per i sistemi  più critici, sono raccomandate tecniche di verifica supplementari.

Ogni settore ha una propria normativa: da applicazioni industriali a quelle mediche, per questa ragione esistono sotto-standard e guide dedicate. Per esempio è possibile citare la DO-178B (Airborne civil avionics), la IEC-880 (Nuclear power plants), la IEC 601-4 (Medical systems) e la GAMP (Pharmaceutical). Inoltre, possiamo anche imbatterci in DS 00-55 (UK Defense Standard 00-.55), nella EN 50128 (European rai), nella ITSEC (European security), o la NRC (US nuclear), MISRA (UK automative), nella FDA (US medical) e per finire nellíente americano NASA (US space).

Safety  Certification Standards

In un mondo così complesso, i due standard più stringenti sono identificati come RTCA DO-178B e IEC 16508. Lo standard DO-178B è stato preparato dalle industrie avioniche per stabilire le considerazioni software cui deve attenersi chi sviluppa software per equipaggiamenti avionici. Il documento, Software Considerations in Airborne Systems and Equipment Certification, copre gli aspetti di verifica, validazione, documentazione, configurazione e di quality assurance di ogni software utilizzato in un sistema microprogrammato. Il documento vuole fornire una linea guida per tutte quelle attività che coinvolgono il software: dalla scelta dei tools, alle indicazioni sul suo sviluppo o riuso. Per il DO-178B ogni linea di codice, o gruppi di linee, è direttamente tracciabile verso un requisito e deve disporre di una procedura di test. Per rispondere alle diverse esigenze, il DO-178B prevede cinque livelli di criticità (da A a D). Ogni livello prevede, poi, un diverso processo di certificazione. In campo aeronautico  i sistemi vengono divisi in due grandi famiglie: safety critical e mission critical. Si parla di sistemi safety critical quando le conseguenze di una anomalia riguardano la vita umana, mentre con Mission critical quando le conseguenze hanno impatti sulla missione, cioè riguardano solo il fallimento  dell’obiettivo per cui il sistema è stato costruito (un concetto più vicino allíaffidabilità). La normatva DO-178B ha cinque livelli di certificazione con differenti impatti sulla safety: Livello  A. Una failure software causa, o può contribuire, ad un errore catastrofico. Per esempio causa o contribuisce ad una failure di un aereo (Catastrophic). Livello B. Una failure software potrebbe causare, o potrebbe contribuire, ad una condizione di hazardous o severe failure (Hazardous). Livello C. Una failure software potrebbe causare, o potrebbe contribuire, ad una condizione di major failure (Major). Livello D. Una failure software potrebbe causare, o potrebbe contribuire, ad una condizione di minor failure (Minor). Livello  E. Una eventuale failure non ha nessuno effetto sulla missione di un aereo (No Effect). Il livello al quale deve essere certificato un particolare sistema è deciso a seguito di un processo congiunto: si analizzano le possibili anomalie con il contributo dei costruttori dell'equipaggiamento.  Il processo di certificazione si termina con la decisione ufficiale dell'autorità certificatore. La certificazione a determinato livello copre automaticamente  il requisito dei suoi sotto-livelli; ma, evidentemente, non è vero il contrario.
Per controllare ogni passo del processo di certificazione, dalla sua domanda alla gestione dell’iter, secondo il processo DO-178, il FAA ha istituito la figura del DER, Designated Engineering Representative. I DER sono, in sostanza, dei tecnici del settore con provata esperienza nell'industria avionica; designati dal FAA per sovrintendere al processo di certificazione. Un DER ha la piena autorità per approvare le fasi del processo di certificazione; in questo caso, assume il ruolo di rappresentante FAA. Esistono, in ogni caso, dei limiti; infatti, un DER non può certificare tutto il processo di certificazione, così come un DER non può approvare aspetti di certificazione coinvolgenti i moduli software senza una particolare supervisione di un rappresentante FAA. Un DER di solito è utilizzato per attività di certificazioni preliminari. In questo modo si conduce l'azienda all'esame finale senza grossi problemi. Poichè l’attività di un DER è quella di testimoniare che il ciclo di sviluppo software adottato è conforme al processo DO-178, è buona norma cercare di formare, nella propria struttura aziendale, persone che siano in grado di vigilare e condurre il programma secondo il ciclo certificativo. Questa è una scelta consigliata per una serie di buone ragioni. Una persona interna ha maggiore spazio di manovra e conoscenze tecniche, per discutere le eventuali scelte progettuali che incidono sul normale flusso del processo DO-178. Può anche dare un contributo sostanziale ai razionali proposti per giustificare le eventuali deviazioni rispetto al processo. Un’altra ragione è di quality assurance. Infatti, se la documentazione, o il suo processo, non è corretta o conforme al processo DO-178, diventa più facile modificare la documentazione o mutare il flusso di sviluppo. Modificare la documentazione al termine del processo o, peggio ancora, scoprire di modificare il ciclo di sviluppo alla sua conclusione ha un costo economico abbastanza elevato.

Do-178b Software Verification

Esistono tre livelli di testing strutturale:

SC (Statement Coverage). Si vuole affermare che l’attività di test deve verificare ogni asserzione (statement) del codice. Questíattività a volte è chiamata anche code coverage. In questo lavoro i test sono selezionati in base alla loro capacità di coprire gli statement del codice (nodi del grafo di flusso).

DC (Decision Coverage). Ogni punto di ingresso e di uscita del programma e ogni punto decisionale deve essere valutato. In sostanza,con questa attività si vuole che ogni asserzione booleana venga valutata “Vero o Falso”. In questo lavoro i test sono selezionati in base alla loro capacità di coprire i risultati di ciascuna decisione (True/False) nel codice; una decisione risulta coperta se entrambi i  risultati booleani sono stati esercitati dai casi di test selezionati.

MCDC  (Modified Condition Decision Coverage). Con questa attività si vuole dire che ogni punto di entrata e uscita nel programma è stato invocato almeno una volta, che ogni decisione nel programma ha preso almeno una volta tutte le possibili conseguenze, e che ogni condizione in una decisione è stata mostrata per colpire indipendentemente la conseguenza di quella decisione. In questa attività sono utilizzati altri criteri, che considerano non solo i valori di verità delle condizioni di base, ma anche le decisioni finali (MCDC: Modified Condition Decision Coverage).

Utilizzare un tool commerciale facilita il processo di certificazione; un mezzo automatico fornisce le condizioni oggettive per dimostrare che la verifica del codice è stata condotta in maniera automatica e affidabile.  Il processo DO-178B definisce gli specifici obiettivi di verifica che devono essere soddisfatti, e questi includono:

➤ Verifica dei processi di sviluppo del software.

➤ Review sul ciclo di sviluppo del software

➤ Verifica funzionale del software.

➤ Structural Coverage Analysis.

La Structural Coverage Analysis è generalmente percepita come l’attività più ostica. Inoltre, la certificazione di un sistema operativo, che è parte integrate del sistema, il gestore delle interruzioni, il gestore della memoria e la gestione dei processi, può rendere  il collaudo strutturale più complesso. Questi aspetti di basso livello creano una sfida significativa al processo di verifica.

Conclusione

Come abbiamo visto, la certificazione del software è un’attività abbastanza complessa e richiede conoscenze tecniche molto mirate. Certificare un prodotto software è un lavoro appassionante, perchè si affrontano diverse tematiche: dal ciclo di vita al testing del prodotto, dalla codifica del software alla sua documentazione. Seguire questi aspetti vuol dire conoscere il progetto nella sua interezza.

 

 

Scrivi un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *