Analisi, progettazione e testing dei safety critical system

Dall’analisi al testing dei safety critical system

La dipendenza dei “safety critical system” dal software può risultare controproducente , in quanto il software contribuisce ad aumentare la sicurezza del sistema, ma può anche, portare il sistema in uno stato instabile e pericoloso.

Pertanto la progettazione di sistemi sicuri segue il “software engineering for safety” che cerca di ridurre il rischio di incidenti. Tale approccio è articolato in:

1. analisi dei fattori di rischi;
2. analisi e specifica dei requisiti di sicurezza;
3. progettazione rivolta alla sicurezza;
4. testing.

Analisi dei fattori di rischio

L’ individuazione dei rischi ed una loro successiva analisi risultano indispensabili per la sicurezza del sistema; tali operazioni di analisi vengono effettuate in base al livello di criticità ed alla probabilità di occorrenza del rischio.

Il primo passo è l’individuazione dei rischi che possono essere eliminati da particolari scelte progettuali, detti infatti “rischi eliminabili”. Successivamente si individuano, tramite tecniche particolari quali il “criticality analysis” ed il “fault tree analysis”, i componenti software che contribuiscono all’esistenza od alla prevenzione di ogni rischio.

La gestione dei rischi può variare da sistema a sistema; può, infatti, essere richiesto di prevenire il verificarsi di situazioni pericolose (es.tramite la mutua esclusione o i timeout), oppure semplicemente di individuare una situazione pericolosa, o di portare il sistema da uno stato pericoloso ad uno sicuro.

Analisi e specifica dei requisiti di sicurezza

L’individuazione formale dei requisiti migliora la qualità del prodotto finale in quanto facilita e rende più accurata la progettazione, l’implementazione e lo sviluppo dei casi di test; l’analisi formale, inoltre, consente di determinare mediante meccanismi automatici se sono preservate le proprietà di sicurezza e se una combinazione di eventi può portare il sistema in uno stato instabile.

Per garantire la sicurezza del sistema, inoltre, devono essere annullate eventuali discordanze che possono insistere tra i requisiti di sicurezza del sistema ed i requisiti del software. In quest’ottica, quindi, una corretta individuazione dei requisiti di sicurezza diventa fondamentale al fine di sviluppare sistemi software sicuri; dato che un minimo errore in fase di analisi dei requisiti può causare degli inconvenienti, essi non solo devono essere identificati e specificati, ma devono anche essere sottoposti a verifiche accurate.

Progettazione rivolta alla sicurezza

Un sistema software progettato per la sicurezza può gestire i pericoli in diversi modi: può impedirli, oppure individuarli e controllarli. La progettazione rivolta alla prevenzione dei rischi (impedire i pericoli) prevede meccanismi come “hardware lockouts”, “lockins”, “interlocks”, “watchdog timers”, l’isolamento dei moduli “safety critcal” e che il comportamento del sistema sia quello atteso.

L’individuazione ed il controllo dei pericoli, invece, prevede meccanismi come la progettazione a sicurezza intrinseca, test automatici, gestione delle eccezioni, controlli su errori degli utenti e riconfigurazione.

Inoltre, la progettazione di sistemi sicuri introduce tre problematiche principali:

1. Design tradeoff: la progettazione dei safety system deve garantire non solo lo sviluppo dei requisiti di sicurezza, ma anche che le proprietà del sistema siano
2. Vulnerabilità ai semplici errori progettuali: si tende a pensare che i problemi di progettazione rivolta alla sicurezza siano tutti di alta complessità; ciò in realtà non è vero, dato che sono numerosi gli incidenti causati da errori semplici, talvolta noti, spesso facilmente prevenibili in fase di progettazione o semplici da individuare in fase di Non è vero, tuttavia, che da piccoli errori derivino piccole conseguenze; gli effetti degli errori in un software non sono mai prevedibili a priori.
3. Uso di tecniche progettuali note: nella progettazione dei safety system è sempre opportuno seguire le tecniche progettuali note; in tal modo si evita di incappare in errori che siano già stati commessi in precedenza e poi corretti mediante l’uso di tecniche formali di progettazione.

In definitiva,per ridurre il richio di mishap possiamo utilizzare vari approcci tra i quali:

• migliorare l’affidabilità e la qualità dei componenti;
• utilizzare dispositivi interni per la sicurezza;
• utilizzare dispositivi esterni per la sicurezza.

Testing

Il testing verifica che i requisiti di sicurezza del software siano soddisfatti dal sistema e che l’analisi dei rischi sia corretta.

I requisiti di sicurezza spesso descrivono condizioni invarianti che devono verificarsi in tutte le circostanze; il testing in questi casi verifica che il sistema sia tollerante al verificarsi di eventuali errori del software (“fault-tolerance”); il testing, inoltre, può anche dimostrare che il software risponda appropriatamente a situazioni anomale. A tal proposito i casi di test devono marcare le condizioni di inizio e di fine (startup e shutdown) e le condizioni anomale (individuazione e correzione degli errori), poiché da una gestione impropria di questi stati vulnerabili possono derivare dei mishap.

Il testing di un sistema sicuro viene notevolmente complicato da problematiche legate al:

1. Dominio: un sistema può risultare pericoloso a causa di errati presupposti sul dominio nel quale il sistema stesso opera; ciò può accadere per esempio nello sviluppo di software per mezzi spaziali in cui è facile effettuare valutazionierrate sull’ambiente. Le incertezze riguardanti il dominio di applicazione complicano l’individuazione del punto esatto in cui il sistema muta; esso può, infatti, mutare in uno stato non sicuro, complicando le eventuali correzioni in grado di riportarlo in uno stato sicuro. Una giusta modellazione del dominio di tali sistemi risulta quindi essenziale per una corretta determinazione dei casi di test.
2. Utente: allo stesso modo assunzioni errate sull’utente o sull’operatore contribuiscono a rendere un sistema non sicuro; un utente può, ad esempio, utilizzare il sistema in modo non corretto, compromettendone quindi lasicurezza. Pertanto i fattori umani sono da non sottovalutare, ed è solo nel corso del testing che tali discordanze vengono alla luce.