Validazione del software di sicurezza

Dipartimento di Tecnica e Gestione dei Sistemi

Industriali

Corso di Laurea Triennale in Ingegneria Meccatronica

Tesi di Laurea Triennale

Validazione del software di sicurezza

Safety software validation

Relatore: Candidato:

Prof. Diego Dainese Riccardo Palmarin

2050054

Anno Accademico: 2023 - 2024

Indice

Indice 1

Sommario 3

Introduzione 4

1 Software che svolgono funzioni di sicurezza 5

1.1 SRASW e SRESW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2 V-Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.2.1 Verifica e Validazione . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Contesto Normativo 8

2.1 Direttiva Macchine e Nuovo Regolamento Macchine . . . . . . . . . . . . . 8

2.2 UNI EN ISO 13849:2023 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.1 UNI EN ISO 13849-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.2 UNI EN ISO 13849-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3 EN IEC 61508:2010 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3.1 EN 61508-1: Requisiti Generali . . . . . . . . . . . . . . . . . . . . . 14

2.3.2 EN 61508-2: Requisiti per sistemi E/E/PE . . . . . . . . . . . . . . . 14

2.3.3 EN 61508-3: Requisiti del software . . . . . . . . . . . . . . . . . . . 15

2.4 EN IEC 62061:2021 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.4.1 Specifiche di una funzione di sicurezza . . . . . . . . . . . . . . . . 17

2.4.2 Classificazione dei software . . . . . . . . . . . . . . . . . . . . . . . 18

2.4.3 Validazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Metodo di validazione del software e il software SOFTEMA 22

3.1 Metodo di validazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.1.1 Ipotesi e fasi principali del metodo . . . . . . . . . . . . . . . . . . . 23

3.1.2 A - Fase preliminare . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1.3 B - Piano di validazione . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.1.4 C - Analisi e verifiche . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.1.5 D - Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2 SOFTEMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2.1 Il metodo a matrice IFA . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2.2 Introduzione a SOFTEMA . . . . . . . . . . . . . . . . . . . . . . . . 27

1

4 Validazione di un software legato alla sicurezza con SOFTEMA 31

4.1 Impostazione del progetto in SOFTEMA . . . . . . . . . . . . . . . . . . . . 31

4.2 A - Fase preliminare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.2.1 Funzioni di sicurezza . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.2.2 Informazioni aggiuntive . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.2.3 Aggiornamento tabelle SOFTEMA . . . . . . . . . . . . . . . . . . . 36

4.3 B - Piano di validazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.3.1 Normale funzionamento . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.3.2 Funzionamento in caso di guasto . . . . . . . . . . . . . . . . . . . . 43

4.3.3 Verifiche normate . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.4 C - Analisi e Verifiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.4.1 Normale funzionamento . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.4.2 Funzionamento in caso di guasto . . . . . . . . . . . . . . . . . . . . 51

4.4.3 Verifiche normate . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.4.4 Aggiornamento tabelle SOFTEMA . . . . . . . . . . . . . . . . . . . 55

4.5 D - Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.5.1 Normale funzionamento . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.5.2 Funzionamento in caso di guasto . . . . . . . . . . . . . . . . . . . . 65

4.5.3 Aggiornamento tabelle SOFTEMA . . . . . . . . . . . . . . . . . . . 69

5 Risultati 73

6 Conclusioni 74

Bibliografia 75

Appendice A 78

Ringraziamenti 81

Elenco delle figure 82

Elenco delle tabelle 84

2

Sommario

La presente tesi ha lo scopo di analizzare e studiare il processo di validazione di un

software che svolge funzioni di sicurezza, con l’obbiettivo di sviluppare una linea guida

che accompagni i tecnici nel processo di validazione.

L’entrata in vigore del nuovo Regolamento UE 2023/1230 ha introdotto la necessità

di certificare i software che svolgono funzioni di sicurezza, rappresentando una delle

principali novità rispetto alla Direttiva Macchine 2006/42/CE. Pertanto, le aziende e i

professionisti dovranno orientarsi tra diverse normative per validare i propri software di

sicurezza.

In questa tesi verrà approfondito il tema dei software legati alla sicurezza e le nor-

me armonizzate da seguire per ottenere la conformità alle Direttive in vigore. Inoltre, si

illustrerà la validazione di un software di sicurezza tramite lo strumento SOFTEMA.

La tesi è composta da sette Capitoli:

• Nel capitolo 1 vengono illustrati le principali tipologie di software relativi alla sicu-

rezza, oltre ai concetti chiave per trattare la validazione dei software.

• Nel capitolo 2 viene trattato il contesto normativo a partire dalla Direttiva Macchine

2006/42/CE e dal nuovo Regolamento UE/2023/1230. Si analizzano nello specifico

le principali norme armonizzate in modo da formulare i requisiti e gli aspetti principa-

li che un software legato alla sicurezza deve rispettare. Nello specifico si analizzano

le norme EN IEC 62061:2022, UNI EN ISO 13849 e EN IEC 61508:2010.

• Nel capitolo 3 viene presentata la metodologia elaborata per la validazione del soft-

ware, oltre alla creazione di una check-list per accompagnare l’intero processo.

Inoltre, viene presentato il software SOFTEMA in tutte le sue funzionalità utili per la

validazione dei software legati alla sicurezza.

• Nel capitolo 4 viene presentato un caso studio rilevante per l’applicazione della

metodologia elaborata. Si userà lo strumento SOFTEMA per condurre il processo

di validazione;

• Nel capitolo 5 vengono discussi i risultati ottenuti dal caso studio, elaborando even-

tuali accorgimenti o note integrative.

• Nel capitolo 6 vengono sintetizzate le principali scoperte e le principali raccoman-

dazioni pratiche. 3

Introduzione

Ai fini della trattazione, si applicano i termini e le definizioni seguenti:

– SRP/CS: parte di un sistema di comando legata alla sicurezza;

– Funzione di sicurezza: funzione di una macchina il cui guasto può determinare un

immediato aumento del rischio;

– SRP: parte legata alla sicurezza;

– PL: livello di prestazione. E’ il livello discreto utilizzato per specificare la capacità

delle parti dei sistemi di comando legate alla sicurezza di eseguire una funzione di

sicurezza in condizioni prevedibili;

– PLr : livello di prestazione richiesto. E’ il livello di prestazione applicato al fine di

conseguire la riduzione del rischio richiesta per ciascuna funzione di sicurezza;

– Misura di protezione: misura atta a conseguire una riduzione del rischio;

– SIL: livello di integrità della sicurezza. E’ il livello discreto per specificare i requi-

siti di integrità della sicurezza delle funzioni di sicurezza da assegnare ai sistemi

Elettrici/Elettronici/Programmabili legati alla sicurezza;

– LVL: linguaggio a variabilità limitata. E’ il tipo di linguaggio che offre la possibilità

di combinare le funzioni di libreria predefinite, specifiche per l’applicazione, per

implementare le specifiche dei requisiti di sicurezza;

– FVL: linguaggio a variabilità completa. E’ il tipo di linguaggio che offre la possibilità

di implementare una vasta gamma di funzioni e applicazioni.

– FB: blocco di funzioni;

– FMEA: analisi delle modalità e degli effetti dei guasti;

– MMTFd: tempo medio al guasto pericoloso. E’ una previsione del tempo medio al

guasto pericoloso;

– PFHd: probabilità media di guasto pericoloso per ora;

4

Capitolo 1

Software che svolgono funzioni di sicurezza

1

Ogni sistema di controllo di una macchina o di una quasi-macchina è dotato di parti re-

lative alla sicurezza che hanno lo scopo di eliminare, o diminuire, un rischio specifico. Le

parti legate alla sicurezza dei sistemi di controllo asservono ad una determinata funzione

di sicurezza.

I sistemi di controllo sono caratterizzati dalla sinergia tra componenti fisici (hardware)

e componenti digitali (software). Pertanto, i software legati alla sicurezza costituiscono

una parte integrante dei sistemi di controllo che svolgono funzioni di sicurezza. Si evince

che i guasti del software che gestisce le funzioni di sicurezza possono provocare un

aumento del rischio non accettabile.

1.1 SRASW e SRESW

Le principali norme che trattano gli aspetti relativi a software che svolgono funzioni di

sicurezza distinguono due principali categorie di software:

a) SRASW: il Safety-Related Application Software è il software specifico dell’applica-

zione implementato dal costruttore della macchina e generalmente contenente se-

quenze logiche, limiti ed espressioni che controllano gli appropriati ingressi, uscite,

calcoli e decisioni necessari per soddisfare i requisiti della parte del sistema di co-

mando correlata alla sicurezza. Il software è generalmente scritto in un linguaggio

a variabilità limitata (LVL).

b) SRESW: il Safety-Related Embedded Software è il software facente parte della

fornitura del fabbricante del sistema di controllo e che non è accessibile per la

modifica al costruttore della macchina. Il software è scritto generalmente in un

linguaggio a variabilità completa (FVL).

Gli obiettivi principali dello sviluppo del software correlato alla sicurezza sono 2:

1. evitare i guasti;

2. generare un software leggibile, comprensibile e che possa essere sottoposto a

prove e a manutenzione.

1 In riferimento alle definizioni riportate nella Direttiva Macchine 2006/42/CE e nel Regolamento UE

2023/1230. 5

1.2 V-Model

Come si approfondirà nei capitoli 2 e 3, il processo di sviluppo più efficace per soddisfare

gli obbiettivi principali è basato sul V-Model.

Il modello a V distingue tutte le fasi del ciclo di vita del software, incluse le attività di

gestione e documentazione, atte a raggiungere la prestazione di sicurezza richiesta.

Lo sviluppo secondo il V-Model include già le attività di validazione e verifica, neces-

sarie per documentare ogni fase del ciclo di vita del software. Lo sviluppo richiede la

formulazione della specifica dei requisiti di sicurezza della funzione di sicurezza come

dato in ingresso da cui partire. In figura 1.1 è illustrato il V-Model completo.

Figura 1.1: V-Model Completo

Si osserva che, al completamento di ogni fase, è prevista un’attività di revisione o

di test, prima di spostarsi alla fase successiva. Seguendo le fasi proposte dal V-Model,

si sviluppa un software già testato e validato. Inoltre, come illustrato nel capitolo 2, il

modello a V è il metodo riconosciuto dalle principali norme armonizzate; oltre ad essere

il metodo utilizzato da SOFTEMA.

Figura 1.2: V-Model semplificato

Per i software di complessità ridotta, il processo di sviluppo illustrato dal modello a V

2

completo può essere ridotto e semplificato, in modo da ottimizzare l’attività di sviluppo .

In figura 1.2 è riportato il modello a V semplificato riconosciuto dalle principali normative

di riferimento.

2 Le ipotesi sulle quali si basa la semplificazione verranno trattate al paragrafo 3.1.

6

1.2.1 Verifica e Validazione

Uno dei concetti più fraintesi della progettazione di software legati alla sicurezza è la

differenza tra l’attività di verifica e l’attività di validazione. Le normative di riferimento

sanciscono una differenza sostanziale tra le due attività.

• La verifica ha come obbiettivo il controllo di qualità delle attività svolte durante

una fase dello sviluppo. E’ un’attività prevalentemente analitica, che può essere

accompagnata da test per completarla.

• La validazione ha come obbiettivo il controllo di qualità del sistema rispetto alla

specifica dei requisiti di sicurezza iniziali. E’ un’attività basata principalmente su

prove, ma che, all’occorrenza, può essere accompagnata da analisi e simulazioni.

Per facilitare ulteriormente la distinzione tra le due attività, si può far riferimento a due

domande: è data dalla verifica.

1. ”Stiamo realizzando correttamente il sistema?” La risposta

2. ”Stiamo realizzando il sistema corretto?” La risposta è data dalla validazione.

7

Capitolo 2

Contesto Normativo

2.1 Direttiva Macchine e Nuovo Regolamento Macchine

Il contesto normativo attuale è disciplinato dalla Direttiva Macchine 2006/42/CE, che verrà

sostituita dal Regolamento UE 2023/1230 a partire dal 20 Gennaio 2027.

Il nuovo Regolamento Macchine prevede esplicitamente che i software atti allo svol-

gimento di funzioni di sicurezza siano marcati CE. Tuttavia, per ottenere la conformità

alla Direttiva Macchine, devono essere seguite le stesse norme armonizzate del nuo-

vo Regolamento Macchine. Pertanto, la trattazione sarà basata sul Regolamento UE

2023/1230.

Le principali norme applicabili nell’ambito dei software che svolgono funzioni di sicu-

rezza sono la UNI EN ISO 13849:2023, la EN IEC 61508:2010 e la EN IEC 62061:2022.

Il Regolamento [29] sancisce una nuova definizione di componenti di sicurezza: [28]:

[...] Inoltre, la definizione di componenti di sicurezza dovrebbe riguardare non

soltanto i dispositivi fisici ma anche quelli digitali. [...], il software che svolge

una funzione di sicurezza ed è immesso in maniera indipendente sul mercato

dovrebbe essere considerato un componente di sicurezza.

Inoltre, sono stati aggiornati gli allegati 1 e 2, includendo i blocchi logici per assicu-

rare funzioni di sicurezza [25] nelle categorie di macchine e prodotti per cui deve essere

1

applicata una delle procedure dell’articolo 25 , e il software che garantisce funzioni di

sicurezza. nell’elenco indicativo di componenti di sicurezza [26].

Un’ulteriore novità del Regolamento Macchine è riportata nell’allegato 4 [27]. Nella

Documentazione Tecnica (ex Fascicolo Tecnico) dovrà essere riportato il codice sorgente

o la logica di programmazione del software relativo alla sicurezza al fine di dimostrare la

conformità del prodotto.

2.2 UNI EN ISO 13849:2023

Il software SOFTEMA è stato ideato per validare i software relativi alla sicurezza rispetto

alla norma armonizza UNI EN ISO 13849. La norma stabilisce le linee guida e i requisiti

1 L’articolo 25, paragrafo 3, sancisce le modalità di valutazione della conformità per i prodotti correlati alla

parte B dell’allegato I 8

di sicurezza per la progettazione delle parti legate alla sicurezza dei macchinari, focaliz-

zandosi prevalentemente sugli aspetti meccanici o hardware della progettazione, tuttavia

fa riferimento anche ad importanti aspetti relativi al software.

Nella parte 1 della norma [9] viene trattata la sola progettazione dei sistemi correlati

alla sicurezza, nella parte 2 della norma [3] si tratta nello specifico la validazione dei

sistemi che svolgono funzioni di sicurezza.

2.2.1 UNI EN ISO 13849-1

Durante la progettazione di una funzione di sicurezza viene definito il Livello di Perfor-

mance richiesto o PLr. Il PL è un indice di sicurezza discretizzato su cinque livelli, da a

fino ad e per sicurezza crescente. I requisiti di sicurezza da applicare dipendono dal PLr

della funzione di sicurezza.

2.2.1.1 Requisiti di sicurezza del software

I requisiti di sicurezza del software dipendono dalla categoria del software, nonché dal

PLr.

Nel caso dei SRESW per componenti con PLr da a fino a d si deve tracciare il ciclo di

vita del software con attività di verifica e validazione, si deve redigere della documentazio-

ne di specifica e progettazione, si deve attuare una progettazione modulare e codificata.

Si devono prendere delle misure per il controllo dei guasti sistematici e si devono eseguire

delle prove funzionali, ad esempio prove a scatola nera.

Il SRASW scritto in FVL deve soddisfare i requisiti del SRESW e può raggiungere un

PL da a ad e. Il SRASW scritto in LVL e conforme ai seguenti requisiti può raggiungere

un PL da a fino ad e. Per quanto riguarda i SRASW per componenti con PLr da a fino

a d si deve tracciare il ciclo di vita del software tramite attività di verifica e validazione

e occuparsi della redazione di documentazione di specifica e progettazione. Risulta ne-

cessario implementare una programmazione modulare e strutturata e si devono eseguire

delle prove funzionali più specifiche, ad esempio prove a scatola grigia.

Al software SRESW per componenti con PLr c oppure d devono essere applicate del-

le misure aggiuntive. Ad esempio, si deve usufruire di un sistema di gestione del progetto

conforme alla ISO 9001, si deve redigere la documentazione pertinente a ciascuna atti-

vità del ciclo di vita del software, si devono usare linguaggi di programmazione idonei e

strumenti computerizzati affidabili. Si deve separare il software non legato alla sicurezza

e i moduli devono avere dimensioni limitate e interfacce interamente definite. Devono es-

sere applicate norme di progettazione e di codifica. Si deve verificare la codifica mediante

walk-through/revisione e si devono attuare prove funzionali estese.

Il software SRASW per componenti con PLr da c fino ad e deve seguire delle misure

aggiuntive con efficienza crescente:

1. La specifica dei requisiti di sicurezza del software deve essere sottoposta a revi-

sione e deve essere a disposizione di ogni persona coinvolta nel ciclo di vita del

9

software. Deve contenere la descrizione delle funzioni di sicurezza con PLr e mo-

dalità di funzionamento, deve riportare i criteri di performance, l’architettura e la

struttura dell’hardware e deve rilevare e controllare i guasti esterni.

2. Si devono selezionare strumenti, librerie e linguaggi di programmazione. Gli stru-

menti devono ess