La creazione di un software è in generale “difficile”: l’affidabilità dei software non va di pari passo con l’aumento di affidabilità dei componenti hardware. Quante volte si è obbligati a riavviare il PC per ripristinarne le funzionalità? Quante volte la mancanza di funzionalità deriva dalla incompatibilità di versioni? Quanti aggiornamenti vengono emessi ogni giorno per i sistemi operativi?

1. Errori nel software

Non esiste un software privo di errori: è però necessario che in base all’utilizzo che ne viene fatto — quindi al livello di prestazione richiesto (PLr) della funzione di sicurezza — il software rispetti determinati requisiti stabiliti dalla norma UNI EN ISO 13849-1:2008.

Un software per funzioni semplici contiene circa 25 errori ogni 1000 linee di codice; software scritto bene contiene circa 2,3 errori ogni 1000 linee di codice; il software utilizzato nello Space Shuttle contiene menodi un errore ogni 10000 linee di codice. Ciò significa che il software di un cellulare contiene circa 600 errori, il sistema operativo di un PC circa 50.000 errori ed il software dello Space Shuttle circa 300 errori.

Gli errori del software rimangono dormienti finché in certe condizioni si verificano con conseguente impatto sul risultato dell'elaborazione. Mentre i malfunzionamenti dei componenti hardware sono normalmente causati da guasti casuali dei componenti, gli errori presenti nel software sono sistematici. L'unico modo per scongiurare comportamenti potenzialmente pericolosi di software che svolgono funzioni di sicurezza è evitare, per quanto possibile, che si introducano errori durante la scrittura del software.

Errori possono essere introdotti in fase di redazione delle specifiche, di progettazione del software e di modifiche successive.

2. Definizioni

• Parte del sistema di comando correlata alla sicurezza – SRP/CS (Safety Relatedpart of Control System) parte di un sistema di comando che risponde a segnali di ingresso legati alla sicurezza e genera dei corrispondenti segnali di uscita legati alla sicurezza.

• Linguaggio a variabilità limitata – LVL (Limited Variability Language): tipo di linguaggio che ha la capacità di combinare funzioni predefinite contenute in una libreria specifica dell’applicazione per implementare una specifica di sicurezza (esempio PLC).

• Linguaggio a variabilità completa – FVL (Full Variability Language): tipo di linguaggio che consente di implementare una grande quantità di funzioni e applicazioni (esempi C, C++, assembler).

• Software applicativo – SRASW (Safety-related application software): software specifico dell’applicazione implementato dal costruttore della macchina e generalmente contenente sequenze logiche, limiti ed espressioni che controllano gli appropriati ingressi, uscite, calcoli e decisioni necessari per soddisfare i requisiti della SRP/CS.

• Software di sistema o software incorporato – SRESW (Safety-related embedded software): software facente parte della fornitura del fabbricante del sistema di controllo e che non è accessibile per la modifica all’utilizzatore della macchina; il software di sistema è normalmente scritto in linguaggio a variabilità completa.

3. Tipologia di software e di linguaggi

Il software incorporato è quella parte di software (firmware, software di sistema) che fa parte del sistema fornito dal produttore dell’hardware(computer, PLC, ecc.) e che non è accessibile per la modifica da parte dell'utente.

Il software applicativo è quella parte di software specifico per l'applicazione, realizzato dal fabbricante della macchina e che in genere contiene sequenze logiche, limiti ed espressioni che controllano in modo opportuno gli ingressi,le uscite, i calcoli e le decisioni da prendere per il corretto funzionamentodelle SRP/CS.

Il SRASW è normalmente scritto utilizzando un linguaggio a variabilità limitata(LVL), ad esempio linguaggi grafici (ladder diagram) forniti dal fabbricante dell'hardware (ad esempio del PLC).

Il SRESW viene fornito all’utilizzatore già validato dal produttore dell’hardware ed è normalmente scritto utilizzando un linguaggio a variabilità completa (FVL), ad esempio C.

Qualora uno SRASW sia scritto utilizzando un linguaggio a variabilità completa si dovrebbero applicare i requisiti della norma UNI EN ISO 13849-1:2008 relativi al SRESW. Per SRESW che controlla funzioni che devono raggiungere un PLr “e” devono essere rispettati i requisiti del punto 7 della norma IEC 61508-3:1998 appropriati per il SIL 3.

Se viene applicata la diversità nella redazione delle specifiche, nella progettazione e nella codifica del software per i due canali di un circuito in categoria 3 o 4, il PLr e può essere raggiunto applicando al software le misure richieste per il PLr c o d.

4. Prescrizioni per la sicurezza del software Tutte le attività del ciclo di vita del software (sia applicativo che di sistema) avente funzioni di sicurezza devono innanzitutto considerare l’eliminazione delle avarie introdotte durante il ciclo di vita del software (incluse revisioni e correzioni).

Modello a V.png

4.1. Specifiche del software

Le specifiche del software avente funzioni di sicurezza devono descrivere le funzioni di sicurezza che devono essere controllate ed indicarne il PLr. Le specifiche dovrebbero essere redatte in modo da poter fungere successivamente da check list per la validazione del software.

Le specifiche dovrebbero essere controllate da persone non coinvolte nella loro redazione per accertarsi che siano conformi con quanto richiesto dalle specifiche di più alto livello e che contengano tutte le indicazioni sulle modalità di realizzazione del software. Le specifiche dovrebbero essere succinte, comprensibili e fare riferimento ai punti essenziali che il software deve soddisfare.

Le specifiche del software possono costituire i vincoli contrattuali per la realizzazione del software, svolta esternamente o all'interno dell'organizzazione.

4.2. Codifica del software

Il codice deve essere leggibile, in modo da facilitare le attività di verifica e di successiva modifica (inserimento di commenti all’interno delle righe di codice, preparazione di linee guida, legende con il significato delle variabili utilizzate, ecc.).

La programmazione dovrebbe essere difensiva, ad esempio controllando che i valori assunti dalle variabili siano negli intervalli previsti.

Il codice deve essere analizzato staticamente, cioè senza eseguirlo; per PLr bassi è sufficiente una verifica del codice, mentre per PLr d ed e, il flusso dei dati e dell'esecuzione del programma dovrebbe essere esaminata, possibilmente con l'ausilio di strumenti quali simulatori software.

L'analisi del software dovrebbe accertarsi che non vi siano funzioni aventi un PLr più basso che possono avere la precedenza rispetto a funzioni con PLr maggiore (ad esempio funzioni non di sicurezza che controllano i medesimi elementi comandati da funzioni di sicurezza).

4.3. Verifica e validazione

La verifica è un'attività tesa ad accertarsi che i risultati di una fase soddisfino le specifiche applicabili. I risultati delle attività di verifica devono essere documentati. I controlli da effettuare possono comprendere i seguenti:

• Il codice è coerente con i diagrammi di progettazione iniziali?
• Ci sono funzioni non di sicurezza che “scavalcano” delle funzioni di sicurezza?
• Quali moduli o quali parti del software producono delle variabili legate a funzioni di sicurezza?
• Quali valori queste possono assumere? È possibile verificare la loro coerenza con il funzionamento della macchina?
• Ci sono delle parti del software che, in determinate condizioni, non vengono eseguite?

La validazione è una forma di verifica dell'intero software il cui scopo è controllare che siano state rispettate le specifiche iniziali. La verifica dell'integrazione dell'intero sistema può coincidere con lavalidazione. La check list per la verifica del software può, per esempio, comprendere i seguenti elementi:

• La configurazione hardware del PLC è completa?
• I parametri relativi alla parte fail-safe della CPU sono configurati correttamente?
• I parametri relativi agli I/O fail-safe sono configurati correttamente?
• Gli identificativi delle connessioni fail-safe sono univoci?
• I dati provenienti dalla parte standard (non fail-safe) del programma sono staticontrollati per verificarne la validità?
• I blocchi funzionali sono ben commentati?
• Le variabili sono ben commentate?