3.1. Introduzione
Il software di sicurezza di una SRP/CS costituisce, per la tipologia dei requisiti previsti e le misure contro i guasti sistematici, uno degli aspetti qualitativi del PL. La EN ISO 13849-1 tratta l’argomento indicando:
il ciclo di vita del software (il cosiddetto “V-model”);
i requisiti per il software di sistema (Embedded software “SRESW”);
i requisiti per il software applicativo (Application software “SRASW”);
i requisiti per la parametrizzazione tramite software.
A causa della trattazione molto concisa e particolarmente specialistica, questa parte della norma risulta non sufficientemente completa e non facilmente applicabile da parte dell’utente. Comunque, non era intenzione del normatore approfondire l’argomento in maniera dettagliata, in quanto una trattazione approfondita era già contenuta nella IEC 61508, tuttavia il richiamo ha lo scopo di calare i requisiti base anche all’interno della struttura della EN ISO 13849-1. Ciò è stato ritenuto necessario perché la IEC 61508 tratta il software in maniera specifica nella parte 3 e in maniera diffusa nelle altre parti, per cui, senza il richiamo, sarebbero stati necessari una lettura e uno studio globale della IEC 61508 per avere una visione completa ed esaustiva dell’argomento.
I requisiti per il software contenuti nella EN ISO 13849-1 dipendono strettamente dal PL richiesto.
3.2. Il ciclo di vita del software
Lo scopo principale da perseguire durante la stesura del software è quello di realizzare un prodotto che sia leggibile, comprensibile, testabile e manutenibile. Il V-model semplificato (figura 11), concepito per questo obiettivo, presenta sette fasi. I risultati di uscita di ciascuna fase sono utilizzati come ingressi dalle fasi successive. Il ramo a sinistra rappresenta le fasi di progettazione, mentre il ramo a destra rappresenta le fasi di prova (test).
Fig. 11: V-model (semplificato) del ciclo di vita del software Specifiche del
software di sicurezza Validazione Validazione
Progettazione del sistema
Progettazione dei moduli
Prove dei moduli
Prove per l’integrazione
Codifica Specifiche
delle funzioni di sicurezza
Software validato
Legenda:
Risultati Verifiche
Ogni fase deve terminare con un documento formale approvato dalla struttura che ha realizzato il progetto.
Nella tabella 18 sono indicati alcuni documenti da produrre durante l’applicazione del V-model.
I rami tratteggiati rappresentano verifiche eseguite dalla fase che emette la freccia sulla fase che la riceve (ad esempio durante la fase delle prove dei moduli si esegue contestualmente una verifica di quanto è stato fatto durante la fase di progettazione dei moduli stessi e durante la fase delle prove per l’integrazione si esegue contestualmente una verifica di quanto è stato fatto durante la fase di progettazione del sistema, inoltre durante ogni fase di progettazione si esegue una verifica sul soddisfacimento delle specifiche del modulo precedente).
La freccia spessa è una speciale verifica volta ad accertare che il software realizzato (attraverso le fasi colorate in celeste) verifichi le specifiche del software di sicurezza (derivate dalle specifiche delle funzioni di sicurezza).
Il software necessario all’esecuzione di ciascuna funzione di sicurezza è scomposto in parti (costituite da un programma che esegue blocchi funzionali) che servono al funzionamento dei singoli moduli.
TAB.18–LISTA NON ESAUSTIVA DI DOCUMENTI RELATIVI AL V-MODEL
Documenti Specifiche delle funzioni di sicurezza;
Schema della macchina o dell’insieme;
Progetto del sistema di controllo (funzioni, modi operativi);
Specifiche del software di sicurezza, Schema circuitale (hardware – Figura 12);
Lista dei segnali di Input e Output;
Indicazioni guida per il codice;
Architettura del programma di sicurezza;
Architettura del programma non di sicurezza,
Architettura dei moduli del programma (funzioni, segnali, indirizzi), Schema del programma;
Codice;
Protocollo di verifica;
Protocollo di revisione del codice;
Protocollo di validazione del software.
Fig. 12: Esempio di schema circuitale
3.3. Regole di programmazione
Un software per applicazioni di sicurezza deve seguire regole che lo rendano univocamente identificabile e tracciabile, in modo da evitare errori e malfunzionamenti.
Ai fini dell’identificazione e della tracciabilità devono essere definiti:
l’autore;
la versione;
la data;
l’ultimo accesso effettuato per modifiche.
Le regole per la stesura del software si differenziano a livello di:
struttura del programma;
scelta delle variabili;
blocchi funzionali.
3.3.1. Struttura del programma
Il software deve essere sequenziale, coerente e comprensibile.
A tale scopo sono di seguito indicate alcune regole da seguire:
i blocchi di funzione devono essere di dimensioni ridotte;
il programma deve essere suddiviso in sezioni o parti in modo da separare gli ingressi, l’elaborazione/processo dei dati, le uscite;
ogni blocco deve essere descritto e commentato;
la programmazione deve essere “strutturata”;
le aree di memoria utilizzate devono essere specificate e descritte;
le variabili devono essere identificate nel tipo e univoche.
3.3.2. Le variabili del programma
Le variabili devono essere gestite in modo da non compromettere la funzionalità del programma.
Alcuni criteri di utilizzazione sono i seguenti:
far apparire solo una volta nel programma l’ON e l’OFF di un segnale di uscita (output);
usare simboli espliciti per individuare le variabili;
gestire da una sola posizione nel programma l’aggiornamento delle variabili.
Altri criteri di questo tipo che rendono univoche e definite le scelte, evitando rimandi e loop, consentono di dare al programma linearità, sequenzialità, chiarezza e leggibilità e al tempo stesso di evitare errori e malfunzionamenti.
3.3.3. I blocchi funzionali
Sul mercato sono disponibili blocchi funzionali validati e certificati dal fabbricante per diverse esigenze [ad esempio STO (safe torque off), SS1 (safe stop 1), SS2 (safe stop 2), SLS (safe limited speed)].
Utilizzare blocchi funzionali certificati da un fabbricante è certamente utile, occorre però accertarsi che le condizioni operative corrispondano a quelle indicate dal fabbricante.
In particolare, alcune regole di cui si suggerisce l’applicazione sono:
utilizzare blocchi di dimensioni ridotte in termini di ingresso e uscita, ad esempio al massimo 8 ingressi booleani, 2 numerici e una sola uscita;
limitare a 10 le variabili numeriche e a 20 quelle booleane;
le variabili numeriche e booleane devono essere inizializzate prima di essere usate per la prima volta;
le variabili globali non devono essere modificate dai blocchi funzionali;
evitare incongruenze nei blocchi in cui sono contenute le definizioni delle variabili;
identificare i guasti nei blocchi, definire con commenti quelli rilevati e lo stato del blocco (il ripristino o l’azzeramento del blocco devono essere commentati).
3.4. Il software di sistema (SRESW - safety-related embedded software)
Il software di sistema (SRESW) è quella parte del software di un sistema elettronico programmabile relativo al funzionamento del dispositivo elettronico stesso e ai servizi da esso forniti. Costituisce parte integrante del sistema fornito dal fabbricante e l’utilizzatore non vi ha alcun accesso.
La EN ISO 13849-1 distingue le misure da applicare al software di sistema in misure di base comuni (tabella 19.a), da applicare fino a PLr = “d”, e in misure addizionali per PLr = “c” e PLr = “d”
(tabella 19.b).
Per PLr = “e” occorre applicare la norma IEC 61508 parte 3a, paragrafo 7 a meno che non si applichi per il software dei due canali (categoria 3 e 4) il criterio della diversità nella definizione delle specifiche, nella progettazione e nella codifica, nel qual caso sono sufficienti le misure addizionali di cui sopra (fig. 13). Ciò perché l’applicazione del criterio della diversità fa presumere una riduzione della probabilità di guasti sistematici, che consente, in fase di verifica o validazione, di applicare solo una revisione della struttura del software invece del controllo di ogni linea del codice.
TAB.19.a:MISURE DI BASE PER IL SRESW
Misure di base (per PLr = “a”, PLr = “b”, PLr = “c”, PLr = ”d”) Ciclo di vita del software (V-model), con verifiche e validazione;
Documentazione: specifiche e progetto;
Progetto e codifica modulare e strutturata;
Controllo dei guasti sistematici;
Verifica di corretta implementazione, se il software è usato per il controllo dei guasti hardware;
Prove funzionali, ad es.”black box testing”;
Dopo eventuali modifiche, rielaborazione delle fasi del V-model applicabili.
TAB.19.b:MISURE ADDIZIONALI PER IL SRESW Misure di addizionali (per PLr = “c”, PLr = ”d”)
Sistema di gestione del progetto e della qualità confrontabile con IEC 61508 o ISO 9001;
Documentazione di tutte le attività rilevanti durante il ciclo del software;
Gestione della configurazione per identificare tutte le caratteristiche e i documenti della versione;
Specifica strutturata con requisiti di sicurezza e progetto;
Impiego di linguaggi e tool idonei di cui si abbia competenza nell’uso;
Programmazione modulare e strutturata, separazione dal software non di sicurezza, dimensioni limitate dei moduli con interfacce completamente definite, uso di progettazione e codifica standard;
Verifica del codice (tramite “walk-through” o revisione con analisi del flusso);
Prove funzionali estese, ad es. “grey box testing”, prove di prestazione o simulazioni;
Dopo eventuali modifiche, analisi dell’impatto e rielaborazione delle fasi del V-model applicabili.
L’Amendment del 2016 della norma EN ISO 13849-1 tratta il caso di componenti per i quali non siano rispettati i requisiti richiesti per il SRESW, quali per esempio PLC, inverter, sensori non espressamente destinati ad applicazioni di sicurezza.
Per tali componenti è consentito l’uso se (figura 14):
la SRP/CS ha un PLr = “a” o un PLr = “b” e la sua struttura è in Categoria B, 2 o 3
la SRP/CS ha un PLr = “c” o un PLr = “d” e può usare più componenti per i due canali nelle Categorie 2 o 3. I componenti dei due canali devono utilizzare tecnologie diverse.
Fig. 13: Misure per SRESW in PL = “e”
Fig. 14: Impiego di componenti non di sicurezza
3.5. Il software applicativo (SRASW - Safety-Related Application Software)
Il software applicativo SRAWS è quella parte del software di un sistema elettronico programmabile che riguarda le funzioni che assolvono un compito specifico relativo alla sicurezza della macchina.
Il software applicativo può essere scritto con linguaggi LVL (low variability languages) oppure FVL (full variability languages). I linguaggi LVL sono tipicamente utilizzati dai PLC e offrono la possibilità di utilizzare librerie di funzioni predefinite per realizzare le specifiche dei requisiti di sicurezza.
Alcuni esempi di LVL (ad es. function block diagram, ladder logic) sono definiti nella norma IEC 61131-3.
I linguaggi FVL permettono di realizzare una vasta tipologia di funzioni e applicazioni, [tipici esempi sono: l’Assembler (basso livello) ma anche il C ed il C++ (medio livello)]. Nel settore delle macchine i linguaggi FVL si trovano nel software di sistema e più raramente nel software applicativo.
Nel caso si utilizzi un linguaggio FVL per il software applicativo allora si applicano gli stessi requisiti indicati per il software di sistema (vedi paragrafo precedente) con la possibilità di soddisfare PL da “a” fino a “e”.
La EN ISO 13849-1 distingue le misure da applicare al software applicativo in misure di base comuni (tabella 20.a), da applicare fino a PLr = “e”, e in misure addizionali per PLr = “c”, PLr = “d” e PLr = “e” (tabella 20.b).
Le misure addizionali sono in parte richieste in parte raccomandate e dovrebbero essere applicate con efficacia crescente al crescere del PL richiesto.
Non è chiaro come tale efficacia crescente vada gestita, sarebbe ragionevole che ciò sia indicato nella norma stessa quando propone o raccomanda per un certo PL una misura piuttosto che un’altra.
TAB.20.a:MISURE DI BASE PER IL SRASW
Misure di base (per PLr = “a”, PLr = “b”, PLr = “c”, PLr = ”d”, PLr = “e”) Ciclo di vita del software con verifiche e validazione;
Documentazione: specifiche e progetto;
Progetto e codifica modulare e strutturata;
Prove funzionali;
Dopo eventuali modifiche, rielaborazione delle fasi del V-model applicabili.
TAB.20.b:MISURE ADDIZIONALI PER IL SRASW
Misure di addizionali (per PLr = “c”, PLr = ”d”, PLr = “e”)
Revisione delle specifiche del software di sicurezza, da rendere disponibili a chiunque fa parte del gruppo di lavoro incaricato del ciclo di vita del software. Le specifiche devono contenere:
a) le funzioni di sicurezza col PLr e i modi operativi associati;
b) i criteri di prestazione, ad es. i tempi di reazione;
c) l’architettura hardware con i segnali d’interfaccia;
d) la rilevazione e il controllo dei guasti.
Scelta di tool idonei:
a) devono rilevare situazioni che possono causare guasti sistematici, effettuando verifiche anche durante la compilazione e non solo durante il funzionamento della macchina;
b) devono sostenere le strutture del linguaggio e le linee guida della codifica o almeno guidare o supervisionare l’utente;
c) se il PLr = “e” è raggiunto con un unico componente e il suo tool, allora il tool deve essere conforme alla norma tecnica pertinente; se sono usati due diversi componenti con tool diversi, allora è sufficiente la competenza nell’uso
Scelta di librerie idonee:
a) Se ragionevolmente possibile scegliere blocchi di funzione (FB) validati, ad es. librerie di software di sicurezza provenienti dal fornitore del tool (altamente raccomandate per PLr = “e”) o librerie per applicazioni specifiche conformi alla ISO 13849-1.
Scelta di linguaggi idonei:
a) Si raccomanda caldamente di usare un sottoinsieme del linguaggio LVL (function block diagram, ladder logic) idoneo per la programmazione modulare
La progettazione del software dovrebbe consistere di:
a) metodi semi-formali per controllo dati e flusso, es. diagramma di stato o flow chart del programma;
b) programmazione modulare e strutturata (con librerie di blocchi di funzione validati);
c) blocchi di funzione di dimensioni ridotte;
d) esecuzione del codice, in ogni blocco funzionale, con un solo punto di ingresso e uno solo d’uscita;
e) architettura del programma a tre livelli: ingresso dei dati, elaborazione, uscita;
f) assegnazione dell’uscita di sicurezza in una sola posizione nel programma;
g) utilizzo di tecniche per rilevare i guasti e per portare il sistema in uno stato sicuro durante l’ingresso dei dati, l’elaborazione, l’uscita (programmazione difensiva).
Quando il software SRAWS si trova combinato col software NON SRASW in un componente:
a) software SRAWS e NON SRAWS devono essere codificati in blocchi funzionali diversi con collegamenti dati ben definiti;
b) dati relativi alla sicurezza non devono essere combinati con quelli non di sicurezza.
Codifica del software:
a) Il codice deve essere leggibile, comprensibile, testabile (ad es. usare variabili simboliche);
b) devono essere usate linee guida accettate e giustificate per la codifica;
c) dovrebbero essere usate le verifiche per l’integrità dei dati e i test di plausibilità disponibili nell’application layer (programmazione difensiva);
d) il codice dovrebbe essere testato con simulazioni;
e) per i PLr =”d” o PLr = “e” dovrebbero essere condotte verifiche con il controllo e l’analisi del flusso di dati.
TAB.20.b:MISURE ADDIZIONALI PER IL SRASW(PROSECUZIONE) Misure di addizionali (per PLr = “c”, PLr = ”d”, PLr = “e”) Testing:
a) condurre “black box testing” della funzionalità e delle prestazioni (ad es. “timing performance”);
b) per i PLr =”d” o PLr = “e” sono raccomandati dei test di esecuzione con valori limite dei parametri;
c) raccomandata di pianificare i test includendo i criteri per la completezza e i tool da utilizzare;
d) l’effettuazione di test di I/O garantisce che il SRASW usi correttamente i segnali relativi alla sicurezza.
Documentazione:
a) tutte le attività di vita e le modifiche del software devono essere documentate;
b) la documentazione deve essere completa, disponibile, leggibile e comprensibile;
c) la documentazione del codice deve contenere l’intestazione dei moduli con le informazioni legali, la descrizione del funzionamento del modulo e le informazioni di I/O, la versione del programma e delle librerie usate, commenti e spiegazioni in quantità sufficiente.
Verifiche (ad es. revisioni, ispezioni):
a) sono necessarie solo per il software scritto appositamente per una data applicazione e non per le librerie certificate.
Gestione della configurazione:
a) devono essere definite procedure opportune per l’identificazione e l’archiviazione della documentazione per ogni versione del software SRASW.
Modifiche:
a) dopo eventuali modifiche effettuare analisi dell’impatto sul soddisfacimento delle specifiche e rielaborazione delle fasi del V-model applicabili;
b) controllo dei diritti di accesso;
c) documentazione storica delle modifiche.
Le misure addizionali possono essere messe in atto con efficienza crescente con il PLr (efficienza bassa se il PLr = “c”, efficienza media se il PLr = “d”, efficienza alta se il PLr = “e”).
3.6. La parametrizzazione tramite software
La parametrizzazione serve a configurare e gestire le funzioni e i parametri caratteristici dei diversi dispositivi, come sensori e attuatori, nonché a variare la risposta della SRP/CS a seconda di valori preimpostati.
La parametrizzazione tramite software rientra tra gli aspetti di sicurezza della SRP/CS, e come tale deve essere inclusa nella specifica dei requisiti di sicurezza del software.
Tale parametrizzazione può essere effettuata impiegando tool software dedicati messi a disposizione dal fornitore della SRP/CS che soddisfano i requisiti della EN ISO 13849-1 (in particolare hanno un nome, una versione e prevengono modifiche non autorizzate ad es. tramite password).
Per fare in modo che sia mantenuta l’integrità dei dati utilizzati per la parametrizzazione, devono essere applicate le misure della tabella 21.
TAB.21:MISURE PER L’INTEGRITÀ DEI DATI PARAMETRIZZATI TRAMITE SOFTWARE
Misure per l’integrità dei dati parametrizzati tramite software Controllo degli intervalli di ingresso validi;
Controllo della corruzione dei dati prima della trasmissione;
Controllo degli effetti degli errori dovuti al processo di trasmissione dei parametri;
Controllo degli effetti della trasmissione incompleta dei parametri;
Controllo degli effetti dei guasti hardware e degli errori software del tool usato per la parametrizzazione.
È possibile utilizzare una procedura alternativa per stabilire i valori dei parametri di sicurezza. Tale procedura prevede la conferma dei parametri in ingresso alla SRP/CS per mezzo di:
ritrasmissione dei parametri modificati al tool di parametrizzazione, oppure
altri mezzi opportuni per confermare l’integrità dei parametri;
conferma a posteriori, da parte di una persona addestrata, per mezzo di un tool di parametrizzazione.
L’ultima possibilità è utile quando la parametrizzazione è stata effettuata con dispositivi non specificamente dedicati allo scopo (e quindi non dotati di tool di controllo), ma ad es. con normali personal computer, e quindi un controllo, dopo l’inserimento dei parametri e prima delle operazioni della macchina, per verificare che tutto sia in ordine, è utile per la sicurezza.
I moduli software usati per la codifica/decodifica all’interno del processo di trasmissione/ritrasmissione e i moduli software usati per la visualizzazione dei parametri di sicurezza devono, come minimo, usare la diversità (nei blocchi funzionali), per evitare errori sistematici.
La documentazione della parametrizzazione tramite software deve indicare i dati usati (ad es. i valori predefiniti dei parametri), le informazioni necessarie per identificare i valori dei parametri che la SRP/CS sta usando, la persona che ha effettuato la parametrizzazione, la data di tale parametrizzazione e le altre informazioni importanti.
Le attività di verifica riportate in tabella 22 devono essere applicate alla parametrizzazione tramite software.
TAB.22:VERIFICHE DA APPLICARE ALLA PARAMETRIZZAZIONE TRAMITE SOFTWARE
Verifiche da applicare alla parametrizzazione tramite software
Verifica della corretta impostazione dei parametri di sicurezza (valori minimo, massimo e valore tipico);
Verifica del fatto che è attuato il controllo della plausibilità dei parametri di sicurezza, ad es.
utilizzando valori non validi;
Verifica del fatto che le modifiche non autorizzate dei parametri sono prevenute;
Verifica del fatto che i dati e i segnali di sicurezza sono generati e usati in modo tale che eventuali guasti non possano portare alla perdita della funzione di sicurezza (ciò è utile quando la parametrizzazione è stata effettuata con dispositivi non specificamente dedicati allo scopo).