Cei en Ita Con Agg

N O R M A I T A L I A N A C E I
Norma Italiana
CEI EN 62061
La seguente Norma è identica a: EN 62061:2005-04.
Data Pubblicazione Edizione
2005-09 Prima
Classificazione Fascicolo
44-16 7829
Titolo
Sicurezza del macchinario - Sicurezza funzionale dei sistemi di

comando e controllo elettrici, elettronici ed elettronici
programmabili correlati alla sicurezza
Copia concessa a FONDITAL SPA in data 12/05/2010 da CEI-Comitato Elettrotecnico Italiano
Title
Safety of machinery - Functional safety of safety-related electrical,

electronic and programmable electronic control systems
TECNICHE DI CONTROLLO E DI MISURA DEI

PROCESSI
CEI COMITATO ELETTROTECNICO ITALIANO

AEIT FEDERAZIONE ITALIANA DI ELETTROTECNICA, ELETTRONICA, AUTOMAZIONE, INFORMATICA E TELECOMUNICAZIONI
CNR CONSIGLIO NAZIONALE DELLE RICERCHE
SOMMARIO
La presente Norma specifica prescrizioni e propone raccomandazioni per la
progettazione, l'integrazione e la validazione di sistemi di controllo elettrici, elettronici ed
elettronici programmabili relativi alla sicurezza (SRECS) per macchinari ed è destinata
all'utilizzo da parte di progettisti di macchinari, costruttori e integratori di sistemi di
controllo e delle altre parti coinvolte nelle specifiche, nella progettazione e nella
validazione di uno SRECS.
La Norma si applica ai sistemi di controllo utilizzati individualmente o in associazione
per eseguire funzioni di controllo relative alla sicurezza su macchinari non mobili e non
portatili mentre sono in funzione, compresi i gruppi di macchinari che operano insieme
in modo coordinato.
La Norma:
- si riferisce esclusivamente alle prescrizioni per la sicurezza funzionale, destinate a
ridurre il rischio di lesioni o di danni alla salute di persone nelle immediate vicinanze del
macchinario o direttamente coinvolte nell'uso della macchina;
- è limitata ai rischi direttamente derivanti dai pericoli della macchina stessa o di un
gruppo di macchinari che operano insieme in modo coordinato;
- non specifica prescrizioni per le prestazioni di elementi di controllo non elettrici;
- non tratta i rischi elettrici derivanti dalla stessa apparecchiatura di controllo.
DESCRITTORI / DESCRIPTORS
Equipaggiamento elettrico - Electrical equipment; Macchine - Machines; Comando,
controllo e funzionamento - Control and operation; Sicurezza funzionale - Functional
safety; Sistemi di comando e controllo elettrici, elettronici e programmabili - Electrical,
electronic and programmable electronic systems
COLLEGAMENTI/RELAZIONI TRA DOCUMENTI

Nazionali
Europei (IDT) EN 62061:2005-04;
Internazionali (IDT) IEC 62061:2005-01; IEC 62061/Ec1:2005-07;
Legislativi
Legenda (IDT) - La Norma in oggetto è identica alle Norme indicate dopo il riferimento (IDT)
INFORMAZIONI EDITORIALI
Norma Italiana CEI EN 62061 Pubblicazioni Norma Tecnica Carattere Doc.
Stato Edizione In vigore Data Validità 2005-11-1 Ambito Validità Internazionale
In data
In data
Varianti Nessuna
Ed. Prec. Fasc. Nessuna
Comitato Tecnico CT 44-Equipaggiamento elettrico delle macchine industriali

Approvata da Presidente del CEI In data 2005-9-12
CENELEC 2004-12-1
Sottoposta a inchiesta pubblica come Documento originale Chiusura in data 2004-9-17
Gruppo Abb. 9 Sezioni Abb. B

ICS
CDU
© CEI - Milano 2005. Riproduzione vietata

Tutti i diritti sono riservati. Nessuna parte del presente Documento può essere riprodotta o diffusa con un mezzo qualsiasi senza
il consenso scritto del CEI. Le Norme CEI sono revisionate, quando necessario, con la pubblicazione sia di nuove edizioni sia di
varianti. È importante pertanto che gli utenti delle stesse si accertino di essere in possesso dell’ultima edizione o variante.
EN 62061
Sicurezza del macchinario - Sicurezza funzionale dei sistemi di comando e

controllo elettrici, elettronici ed elettronici programmabili correlati alla
sicurezza
Safety of machinery - Functional safety of safety-related electrical, electronic and

programmable electronic control systems
Sécurité des machines - Sécurité fonctionnelle des systèmes de commande

électriques, électroniques et électroniques programmables relatifs à la sécurité
Sicherheit von Maschinen - Funktionale Sicherheit sicherheitsbezogener

elektrischer, elektronischer und programmierbarer elektronischer
Steuerungssysteme
3
I Comitati Nazionali membri del CENELEC sono tenuti, in accordo col regolamento interno del CEN/CENELEC,
ad adottare questa Norma Europea, senza alcuna modifica, come Norma Nazionale. Gli elenchi aggiornati e i
relativi riferimenti di tali Norme Nazionali possono essere ottenuti rivolgendosi al Segretariato Centrale del
CENELEC o agli uffici di qualsiasi Comitato Nazionale membro. La presente Norma Europea esiste in tre
versioni ufficiali (inglese, francese, tedesco).Una traduzione effettuata da un altro Paese membro, sotto la sua
responsabilità, nella sua lingua nazionale e notificata al CENELEC, ha la medesima validità. I membri del
CENELEC sono i Comitati Elettrotecnici Nazionali dei seguenti Paesi: Austria, Belgio, Cipro, Danimarca,
Estonia, Finlandia, Francia, Germania, Grecia, Irlanda, Islanda, Italia, Lettonia, Lituania, Lussemburgo, Malta,
Norvegia, Olanda, Polonia, Portogallo, Regno Unito, Repubblica Ceca, Slovacchia, Slovenia, Spagna, Svezia,
Svizzera e Ungheria.
I diritti di riproduzione di questa Norma Europea sono riservati esclusivamente ai membri nazionali del CENELEC.
CENELEC members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the
conditions for giving this European Standard the status of a National Standard without any alteration. Up-to-
date lists and bibliographical references concerning such National Standards may be obtained on application to
the Central Secretariat or to any CENELEC member. This European Standard exists in three official versions
(English, French, German). A version in any other language and notified to the CENELEC Central Secretariat
has the same status as the official versions. CENELEC members are the national electrotechnical committees
of: Austria, Belgium, Cipre, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary,
Iceland, Ireland, Italy, Latvia, Lithuanian, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Slovakia,
Slovenia, Spain, Sweden, Switzerland and United Kingdom.
© CENELEC Copyright reserved to all CENELEC members.
CENELEC
Comitato Europeo di Normalizzazione Elettrotecnica Secrétariat Central Comité Européen deNormalisation Electrotechique
European Committee for Electrotechnical Standardization Rue de Strassart 35, B – 1050 Bruxelles EuropäiKomitee für Elektrotechnische Normung

PREFAZIONE
Il testo del documento 44/460/FDIS, futura prima edizione della IEC 62061, preparato dall’IEC TC 44,
Safety of machinery - Electrotechnical aspects, è stato sottoposto al voto parallelo IEC-CENELEC ed
è stato approvato dal CENELEC come EN 62061 in data 01-12-2004.
Sono state fissate le date seguenti:
– data ultima entro la quale la EN deve essere

recepita a livello nazionale mediante pubblicazione
di una Norma nazionale identica o mediante adozione (dop) 01-11-2005
– data ultima entro la quale le Norme nazionali contrastanti

con la EN devono essere ritirate (dow) 01-12-2007
Questa Norma Europea è stata preparata su mandato accordato al CENELEC dalla Commissione
Europea e dall’Associazione Europea per il Libero Commercio (EFTA) e contempla i requisiti
essenziali della Direttiva 98/37/CE. Si veda l’Allegato ZZ.
INTERVALLO DI VERIFICA PERIODICA (PROOF TEST) E CICLO DI VITA
La seguente importante informazione deve essere notata in relazione ai requisiti di questa norma:
Dove la probabilità di guasti per ora (PFHD) è altamente dipendente dalla verifica periodica (cioè la
prova intesa a rivelare i guasti non rivelati dalla funzione diagnostica) allora l’intervallo della prova
periodica è necessario che sia mostrato come realistico e praticabile nel contesto dell’uso previsto
relativo alla sicurezza del sistema elettrico di controllo (SRECS) (per esempio un intervallo di verifica
periodica inferiore a 10 anni può essere irragionevolmente corto per molte applicazioni del
macchinario).
Il CEN/TC114/WG6 ha utilizzato un intervallo per la verifica periodica (tempo di missione) di 20 anni a

supporto della stima del tempo medio al guasto pericoloso (MTTFD) per la realizzazione
dell’architettura riportata nell’Allegato B del prEN ISO 13849-1. Pertanto, si suggerisce che nell’attività
di progettazione di uno SRECS si usi un intervallo della verifica periodica di 20 anni.
É riconosciuto che alcuni sottosistemi e/o elementi di sottosistema (per esempio componenti
elettromeccanici con altri cicli di utilizzo) richiederanno la sostituzione all’interno dell’intervallo della
verifica periodica.
La verifica periodica coinvolge i controlli dettagliati e completi che possono, in pratica, essere effettuati
solo quando lo SRECS e/o i relativi sottosistemi sono stati progettati per facilitare la verifica periodica
(per esempio porte di verifica dedicate) e forniti delle informazioni necessarie (per esempio istruzioni
per la verifica periodica).
Per accertare la validità dell’intervallo della verifica periodica specificato dal progettista è importante
che tutte le altre prove indicate necessarie (per esempio prove funzionali) siano inoltre effettuate sullo
SRECS con successo.
Gli Allegati ZA e ZZ sono stati aggiunti dal CENELEC.
__________
AVVISO DI ADOZIONE
Il testo della Pubblicazione IEC 62061:2005 è stato approvato dal CENELEC come Norma Europea
senza alcuna modifica.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina v
INDICE
INTRODUZIONE ...................................................................................................................2
1 Campo di applicazione....................................................................................................8
2 Riferimenti normativi.....................................................................................................10
3 Termini, definizioni e abbreviazioni ...............................................................................12
3.1 Elenco delle definizioni secondo l’ordine del testo inglese ....................................12
3.2 Termini e definizioni ............................................................................................14
3.3 Abbreviazioni.......................................................................................................30
4 Gestione della sicurezza funzionale ..............................................................................30
4.1 Scopo..................................................................................................................30
4.2 Prescrizioni .........................................................................................................32
5 Prescrizioni per la specifica di Funzioni di Controllo Relative alla Sicurezza (SRCF)....................34
5.1 Finalità ................................................................................................................34
5.2 Specifiche delle prescrizioni per le SRCF .............................................................34
6 Progettazione e integrazione del sistema elettrico di controllo relativo alla
sicurezza (SRECS) .......................................................................................................38
6.1 Scopo..................................................................................................................38
6.2 Prescrizioni generali ............................................................................................38
6.3 Prescrizioni per il comportamento (dello SRECS) al rilevamento di un’avaria
nello SRECS .......................................................................................................40
6.4 Prescrizioni per l’integrità sistematica della sicurezza degli SRECS ......................42
6.5 Scelta del sistema elettrico di controllo relativo alla sicurezza ..............................46
6.6 Progettazione e sviluppo di un sistema elettrico di controllo relativo alla
sicurezza (SRECS) ..............................................................................................46
6.7 Realizzazione dei sottosistemi...................................................................................56
6.8 Realizzazione delle funzioni diagnostiche ....................................................................84
6.9 Realizzazione hardware dello SRECS ........................................................................86
6.10 Specifica delle prescrizioni di sicurezza del software ......................................................86
6.11 Progettazione e sviluppo del software .........................................................................88
6.12 Integrazione e collaudo del sistema elettrico di controllo relativo alla
sicurezza........................................................................................................... 100
6.13 Installazione dello SRECS ................................................................................. 104
7 Informazioni sull’uso dello SRECS .............................................................................. 104
7.1 Scopo................................................................................................................ 104
7.2 Documentazione per l’installazione, l’uso e la manutenzione .............................. 104
8 Validazione del sistema elettrico di controllo relativo alla sicurezza ............................. 106
8.1 Finalità .............................................................................................................. 106
8.2 Prescrizioni generali .......................................................................................... 106
8.3 Validazione dell’integrità della sicurezza sistematica dello SRECS ..................... 108
9 Modifiche ................................................................................................................... 110
6.1 Finalità .............................................................................................................. 110
9.2 Procedura di modifica ........................................................................................ 110
9.3 Procedure di gestione della configurazione ........................................................ 110
10 Documentazione......................................................................................................... 114
Allegato A (informativo) Assegnazione del SIL................................................................. 118
Allegato B (informativo) Esempio di progettazione di sistemi elettrici di controllo relativi
alla sicurezza (SRECS) utilizzando concetti e prescrizioni degli Articoli 5 e 6 ............... 132
NORMA TECNICA
CEI EN 62061:2005-09-09
Pagina vii
Allegato C (informativo) Guida alla progettazione e allo sviluppo del software
incorporato ................................................................................................................. 146
Allegato D (informativo) Modalità di guasto dei componenti elettrici/elettronici................... 162
Allegato E (informativo) Fenomeno elettromagnetico (EM) e aumento dei livelli di
immunità per gli SRECS destinati all’uso in un ambiente industriale conforme alla
IEC 61000-6-2 ............................................................................................................ 172
Allegato F (informativo) Metodologia per la stima della suscettibilità ai guasti per
cause comuni (CCF) ................................................................................................... 176
Allegato ZA (normativo) Riferimenti normativi alle Pubblicazioni Internazionali con le
corrispondenti Pubblicazioni Europee.......................................................................... 180
Allegato ZZ (informativo) Copertura dei requisiti essenziali delle Direttive Comunitarie..... 182
NORMA TECNICA
CEI EN 62061:2005-09-09
Pagina ix
IEC 62061
(Prima edizione – 2005)
Sicurezza del macchinario - Sicurezza funzionale dei sistemi di comando

e controllo elettrici, elettronici
ed elettronici programmabili correlati alla sicurezza
Sostituire, nella solo versione italiana, nell’Allegato B, nella Figura B.5, la dicitura
“Interruzione alimentazione motore FB4 SIL CL1” con la seguente: “Interruzione
alimentazione motore FB4 SIL CL2”.
ERRATA CORRIGE 2
3.2 Termini e definizioni
Eliminare la Nota alla definizione 3.2.41: guasto in sicurezza.
Sostituire la Tabella 5 con la seguente:
Tabella 5 – Vincoli dell’architettura sui sottosistemi:

massimo SIL che può essere richiesto per una SRCF che utilizza tale sottosistema
Frazione di guasto in Tolleranza all’avaria dell’hardware (vedere Nota 1)

sicurezza
0 1 2
Non permesso
< 60 % (per eccezioni vedere la SIL1 SIL2
Nota 3)
60 % – < 90 % SIL1 SIL2 SIL3
90 % – < 99 % SIL2 SIL3 SIL3 (vedere Nota 2)
t 99 % SIL3 SIL3 (vedere Nota 2) SIL3 (vedere Nota 2)

NOTA 1 Una tolleranza N all’avaria dell’hardware indica che N+1 avarie possono causare una perdita della
funzione di controllo relativa alla sicurezza.
NOTA 2 Un SILCL 4 non è considerato nella presente Norma. Per il SIL 4 vedere la IEC 61508-1.
NOTA 3 Vedere 6.7.6.4 o, per i sottosistemi nei quali sono state applicate le esclusioni di avaria alle avarie
suscettibili di condurre a un guasto pericoloso, vedere 6.7.7.
Articolo 6, aggiungere il nuovo paragrafo 6.7.6.4 seguente:
6.7.6.4 I sottosistemi elettromeccanici con una frazione di guasto in sicurezza inferiore al

60 % e una tolleranza di avaria hardware pari a zero che utilizzano componenti ben collaudati
(vedere Nota) in conformità alla ISO 13849-1:2006 Categoria 1 PLC, devono essere
considerati in grado di raggiungere un SILCL pari a SIL1.
NOTA Un componente ben collaudato per un’applicazione relativa alla sicurezza è un componente che è stato:
a) usato su larga scala in passato in applicazioni simili con risultati efficaci, oppure
b) costruito e verificato utilizzando principi che ne dimostrano l’idoneità e l’affidabilità per applicazioni
relative alla sicurezza.
Rinumerare il paragrafo 6.7.6.4 in:
6.7.6.5 Quando un sottosistema è progettato in conformità alla ISO 13849-1:1999 e validato

in conformità alla ISO 13849-2:2003, la seguente relazione può essere applicata nel contesto
dei soli vincoli dell’architettura, in conformità alla Tab. 6. Si ritiene che un sottosistema con
una categoria specifica conforme alla ISO 13849-1:1999 abbia la tolleranza all’avaria
dell’hardware associata e la frazione di guasto in sicurezza indicate nella Tab. 6.
NOTA Per realizzare un SIL prescritto è inoltre necessario rispettare le prescrizioni in base alla probabilità di
guasti pericolosi e all’integrità sistematica della sicurezza.
NORMA TECNICA
CEI EN 62061/EC:2008-09
Pagina 2 di 11
Sostituire la Tabella 6 con la seguente:
Tabella 6 – Vincoli dell’architettura: SILCL in rapporto alle categorie
Categoria Tolleranza all’avaria SFF Massimo limite di SIL

dell’hardware richiesto dai vincoli
dell’architettura
Si ritiene che i sottosistemi con la categoria
dichiarata abbiano le caratteristiche indicate nel
seguito
1 0 < 60 % Vedere Nota 1
2 0 60 % – 90 % SIL 1 (vedere Nota 2)
3 1 < 60 % SIL 1
1 60 % – 90 % SIL 2
4 >1 60 % – 90 % SIL 3 (vedere Nota 3)
1 > 90 % SIL 3 (vedere Nota 4)
NOTA 1 I sottosistemi con una SFF <60% ma progettati in conformità alla Categoria 1 della ISO 13849-1:1999 e
validati in conformità alla ISO 13849-2:2003 sono considerati in grado di raggiungere un SILCL pari a
SIL1.
NOTA 2 Il caso per la Categoria 2 dove SFF è > 90 % si ritiene non realizzato dalle prescrizioni di progettazione
della ISO 13849-1:1999.
NOTA 3 La copertura diagnostica è ritenuta inferiore a 90 % per i sottosistemi della Categoria 4 nei quali si
considera una tolleranza maggiore di quella all’avaria singola dell’hardware (cioè avarie accumulate).
NOTA 4 La Categoria 4 prescrive una SFF superiore a 90 % ma inferiore a 99 % quando si considera la
tolleranza all’avaria singola dell’hardware.
NOTA 5 La Categoria B in conformità alla ISO 13849-1:1999 non è considerata sufficiente al raggiungimento di
SIL 1.
Cambiare la Nota al paragrafo 6.7.7.3 come segue:

NOTA È ammessa l’esclusione di avarie in conformità a 3.3 e D.5 della ISO 13849-2:2003.
Cambiare il paragrafo 6.7.8.1.6 e la Tabella 7 come segue:
6.7.8.1.6 Quando un sottosistema a bassa complessità è progettato secondo la

ISO 13849-1:1999, validato secondo la ISO 13849-2:2003 e rispetta inoltre le prescrizioni dei
vincoli dell’architettura (vedere 6.7.6) e dell’integrità della sicurezza del sistema (vedere
6.7.9), i valori di soglia della probabilità di guasto pericoloso (PFH D ) indicati nella Tab. 7
possono essere utilizzati per stimare l’integrità della sicurezza dell’hardware (vedere 6.6.3.2).
Tabella 7 – Probabilità di un guasto pericoloso
Tolleranza all’avaria Valori di soglia (orari) PFHD che

DC
dell’hardware possono essere richiesti per il
Categoria sottosistema
Si ritiene che i sottosistemi della categoria indicata abbiano le PFHD (MTTF sottosistema ,
caratteristiche sotto riportate.
T prova , DC) (Vedere Nota 1)
1 0 0% Da fornire a cura del fornitore o

utilizzare dati generici (vedere
Allegato D)
2 0 60 % – 90 % 10 –6
3 1 60 % – 90 % 2 x 10 –7
4 >1 60 % – 90 % 3 x 10 –8
1 > 90 % 3 x 10 –8
NOTA 1 Il valore di soglia PFH D è una funzione del MTTF del sottosistema (derivato dal costruttore del
sottosistema o dai manuali dei dati dei componenti relativi), del tempo del ciclo di prova/verifica, come
indicato nella specifica delle prescrizioni di sicurezza (tale informazione è richiesta inoltre per la
validazione del sottosistema in conformità a 3.5 della ISO 13849-2:2003), e della copertura diagnostica,
come indicato nella presente Tabella (questi valori si basano sulle prescrizioni delle categorie descritte
nella ISO 13849-1:1999).
NOTA 2 La Categoria B secondo la ISO 13849-1:1999 non può essere considerata sufficiente a raggiungere SIL 1.
NORMA TECNICA
CEI EN 62061/EC:2008-09
Pagina 4 di 11
Cambiare la Nota 2 del paragrafo 6.7.8.2.1 come segue:
NOTA 2 Per le equazioni da (A) a (D) indicate in 6.7.8.2 si presumono tassi di guasto ( O ) degli elementi del
sottosistema costanti e sufficientemente bassi (1>> O x T) (questo significa che il tempo medio di un guasto
pericoloso deve essere molto maggiore dell’intervallo della verifica periodica (proof test) o del ciclo di vita del
sottosistema). Pertanto, può essere utilizzata la seguente equazione fondamentale:
O = 1/MTTF, dove MTTF è espresso in ore.
Per i dispositivi elettromeccanici, il tasso di guasto si determina utilizzando il valore B 10 e il numero di cicli di
funzionamento C (espresso come numero di cicli di funzionamento orari) dell’applicazione come specificato
(vedere 5.2.3).
O = 0,1 x C/B 10 .
Allegato A: Assegnazione del SIL
Cambiare il terzo capoverso in A.2.4.1 come segue:
Dovrebbe inoltre essere possibile prevederne la durata, per esempio se superiore a 10 min.
Quando la durata è inferiore a 10 min., il valore può essere diminuito a quello della riga
inferiore della Tabella A.2. Questo non si applica alla frequenza di esposizione d 1 h, che
non dovrebbe mai essere diminuita.
Cambiare la Tabella A.2 come segue:
Tabella A.2 – Classificazione della frequenza e durata dell’esposizione (Fr)
Frequenza e durata dell’esposizione (Fr)
Frequenza, Fr
Frequenza dell’esposizione
(vedere A.2.4.1)
d 1 per h 5
Da < 1 per h a 1 per giorno 5

Da < 1 per giorno a 1 per 2 settimane 4
Da < 1 per 2 settimane a 1 per anno 3
< 1 per anno 2
Cambiare la Tabella A.6 come segue:
Tabella A.6 – Matrice di assegnazione del SIL
Gravità (Se) Classe (Cl)

4 5-7 8-10 11-13 14-15
4 SIL 2 SIL 2 SIL 2 SIL 3 SIL 3
3 (OM) SIL 1 SIL 2 SIL 3
2 (OM) SIL 1 SIL 2
1 (OM) SIL 1
Cambiare la Figura A.3 come segue:
NORMA TECNICA
CEI EN 62061/EC:2008-09
Pagina 6 di 11
Documento Numero:
Valutazione del rischio e misure di sicurezza Parte di:
Prodotto: Valutazione del rischio prima delle misure

Emesso da: Valutazione intermedia del rischio
Data: Area nera = Misure di sicurezza prescritte Valutazione del rischio a posteriori
Area grigia = Misure di sicurezza raccomandate
Conseguenze Severità Classe Cl Frequenza, Probabilità evento Evitabilità
Se 4 5-7 8 - 10 11 - 13 14 - 15 Fr pericoloso, Pr Av
Morte, perdita di un occhio o di un braccio 4 SIL 2 SIL 2 SIL 2 SIL 3 SIL 3 1 per h 5 Molto alta 5
Permanente: perdita di dita 3 OM SIL 1 SIL 2 SIL 3 <1 per h - 1 per giorno 5 Probabile 4
Reversibile: intervento medico 2 OM SIL 1 SIL 2 <1 per giorno - 1 per 14giorni 4 Possibile 3 Impossibile 5
Reversibile: pronto soccorso 1 OM SIL 1 <1 per 2sett. - 1 per anno 3 Scarsa 2 Possibile 3
<1 per anno 2 Trascurabile 1 Probabile 1
N. Per. Pericolo Se Fr Pr Av Cl Misura di sicurezza Sicuro

Sev. N.
Pagina 8 di 11
Commenti

NORMA TECNICA - CEI EN 62061/EC:2008-09
Figura A.3 – Esempio proforma per il processo di assegnazione del SIL
Allegato F: Metodologia per la stima della suscettibilità
ai guasti per cause comuni (CCF)
Cambiare la Tabella F.2 come segue:
Tabella F.2 – Stima del fattore CCF ()
Punteggio totale Fattore di guasto per cause comuni ()

35 10 % (0,1)
36 – 65 5 % (0,05)
66 – 85 2 % (0,02)
86 – 100 1 % (0,01)
NORMA TECNICA
CEI EN 62061/EC:2008-09
Pagina 10 di 11
La presente Norma è stata compilata dal Comitato Elettrotecnico Italiano e
beneficia del riconoscimento di cui alla legge 1° Marzo 1968, n. 186.
Editore CEI, Comitato Elettrotecnico Italiano, Milano – Stampa in proprio
Autorizzazione del Tribunale di Milano N. 4093 del 24 Luglio 1956
Responsabile: Ing. R. Bacci
Comitato Tecnico Elaboratore

CT 44-Equipaggiamento elettrico delle macchine industriali
Altre Norme di possibile interesse sull’argomento
CEI EN 60204-1 (CEI 44-5)

Sicurezza del macchinario - Equipaggiamento elettrico delle macchine - Parte 1: Regole generali
CEI EN 60204-31 (CEI 44-7)

Sicurezza del macchinario - Equipaggiamento elettrico delle macchine - Parte 31: Prescrizioni particolari per macchine
per cucire, unità e sistemi
CEI EN 61310-1 (CEI 44-8)

Sicurezza del macchinario - Indicazione, marcatura e manovra - Parte 1: Prescrizioni per segnali visivi, acustici e tattili
CEI EN 61310-2 (CEI 44-9)

Sicurezza del macchinario - Indicazione, marcatura e manovra - Parte 2: Prescrizioni per la marcatura
CEI EN 61496-1 (CEI 44-10)

Sicurezza del macchinario - Apparecchi elettrosensibili di protezione - Parte 1: Prescrizioni generali e prove
CEI EN 60204-32 (CEI 44-11)

Sicurezza del macchinario - Equipaggiamento elettrico delle macchine - Parte 32: Prescrizioni per le macchine di
sollevamento
CEI EN 61310-3 (CEI 44-12)

Sicurezza del macchinario - Indicazione, marcatura e manovra - Parte 3: Prescrizioni per il posizionamento e il senso di
manovra degli attuatori
CEI EN 60204-11 (CEI 44-15)

Sicurezza del macchinario - Equipaggiamento elettrico delle macchine - Parte 11: Prescrizioni per l'equipaggiamento
AT con tensioni superiori a 1000 V AC o 1500 V DC, ma non superiori a 36 kV
CEI CLC/TS 62046 (CEI 44-17)

Sicurezza del macchinario - Applicazione di sistemi di protezione per rilevare la presenza di persone
CEI CLC/TS 61496-2 (CEI 44-18)

Sicurezza del macchinario - Apparecchi elettrosensibili di protezione - Parte 2: Prescrizioni particolari per
l'equipaggiamento che utilizza dispositivi di protezione fotoelettrici attivi (AOPD)
€ 0,00
NORMA TECNICA Sede del Punto Vendita e di Consultazione
CEI EN 62061/EC:2008-09 20134 Milano Via Saccardo,9
Totale Pagine 14 Tel. 02/21006.1 Fax 02/21006.222
http://www.ceiweb.it e-mail cei@ceiweb.it

INTRODUZIONE
In conseguenza dell’automazione, della domanda di una produzione più elevata e di una

riduzione degli sforzi fisici dell’operatore, i Sistemi di Controllo (1) Elettrici Relativi alla
Sicurezza (noti come SRECS) delle macchine hanno assunto un ruolo crescente nella
sicurezza complessiva delle macchine. Inoltre, gli stessi SRECS utilizzano sempre di più
tecnologie elettroniche complesse.
In passato, in assenza di norme, si era riluttanti ad accettare gli SRECS nelle macchine per le
funzioni legate alla sicurezza in caso di pericoli elevati, a causa dell’incertezza relativa alle
prestazioni di tale tecnologia.
La presente Norma Internazionale è destinata all’utilizzo da parte dei progettisti di macchinari,

costruttori, e integratori di sistemi di controllo e delle altre parti coinvolte nelle specifiche,
nella progettazione e nella validazione di uno SRECS. Essa definisce un approccio e fornisce
prescrizioni per il raggiungimento delle prestazioni necessarie.
La presente Norma è specifica per il settore delle macchine nell’ambito della IEC 61508. Essa
è destinata ad agevolare la specifica delle prestazioni di sistemi elettrici di controllo relativi
alla sicurezza in rapporto ai rischi rilevanti (vedere 3.8 della ISO 12100-1) delle macchine.
La presente Norma offre un quadro specifico per il settore macchine relativo alla sicurezza
funzionale dello SRECS di macchine. Essa tratta esclusivamente gli aspetti del ciclo di vita
utile della sicurezza relativi all’assegnazione di prescrizioni di sicurezza fino alla validazione
della stessa. Vengono fornite prescrizioni per le istruzioni d’uso in condizioni di sicurezza
degli SRECS di macchine che possono anche essere relative a fasi successive del ciclo di
vita utile di uno SRECS.
Vi sono molte situazioni, nelle macchine, in cui gli SRECS sono utilizzati tra le misure di
sicurezza fornite per ridurre i rischi. Un caso tipico è l’utilizzo di una protezione interbloccata
che, quando è aperta per consentire l’accesso alla zona pericolosa, segnala al sistema
elettrico di controllo di arrestare il funzionamento pericoloso della macchina. Anche
nell’automazione, il sistema elettrico di controllo, utilizzato per ottenere un funzionamento
corretto del processo della macchina, spesso contribuisce alla sicurezza, riducendo i rischi
connessi ai pericoli direttamente derivanti da guasti al sistema di controllo. La presente
Norma fornisce una metodologia e le prescrizioni per:
x assegnare il livello di integrità della sicurezza richiesto per ogni funzione di controllo ad
essa relativa da realizzare mediante SRECS;
x consentire la progettazione di SRECS idonei alla(e) funzione(i) di controllo assegnata(e)
relativa(e) alla sicurezza;
x integrare i sottosistemi relativi alla sicurezza progettati in conformità con la ISO 13849;
x validare gli SRECS.
La presente Norma è destinata a essere utilizzata nell’ambito della riduzione sistematica dei
rischi descritta nella ISO 12100-1, e associata alla valutazione dei rischi secondo i principi
contenuti nella ISO 14121 (EN 1050). Un esempio di metodologia suggerita per l’assegnazione
del livello di integrità della sicurezza (SIL) è contenuto nell’Allegato informativo A.
Sono fornite misure per coordinare la prestazione degli SRECS con la riduzione prevista dei
rischi, tenendo conto delle probabilità e delle conseguenze di avarie casuali o sistematiche
all’interno del sistema elettrico di controllo.
La Fig. 1 indica le relazioni tra la presente Norma e altre norme relative.
La Tab. 1 fornisce raccomandazioni sull’applicazione suggerita della presente Norma e della

revisione della ISO 13849-1.
———————
(1) N.d.R: Il termine inglese “control”, tradotto nella presente Norma prevalentemente come “controllo”, è tuttavia
da intendere in base al contesto come “comando”, “controllo” o “comando e controllo”.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 2 di 183
Progettazione e valutazione del rischio del macchinario
ISO 12100, Sicurezza del Macchinario – Concetti fondamentali,
principi generali di progettazione
ISO 14121, Sicurezza del Macchinario – Principi per la valutazione
dei rischi
Progettazione di sistemi di controllo elettrici, elettronici ed elettronici

programmabili relativi alla sicurezza (SRECS) per macchinari
Metodologia che utilizza:
Funzioni di controllo relative alla sicurezza
Approccio in base al sistema
- Indice quantitativo di sicurezza:
- Indice di sicurezza:
livello di integrità della sicurezza (SIL)
categoria/livello di prestazione
- Metodologia di assegnazione del SIL
- Assegnazione della categoria in base
per SRECS dei macchinari a grafici qualitativi del rischio
- Orientato all’architettura - Orientato all’architettura

- Prescrizioni per la prevenzione
il controllo di guasti sistematici
Obiettivo di progettazione
per gli SRECS
Norme relative
Aspetti relativi alla sicurezza elettrica

del macchinario Progettazione di sottosistemi
IEC 60204-1, Sicurezza del macchinario - a bassa complessità in base
Equipaggiamento elettrico delle macchine - alle categorie
Parte 1: Regole generali ISO 13849-1 e 2 Sicurezza del
macchinario – Parti dei sistemi di
comando legate alla sicurezza
(SRPCS)
– Parte 1: Principi generali per la
progettazione e Parte 2: Validazione
Progettazione di sottosistemi
complessi in base ai SIL
SRPCS non elettrici
IEC 61508, Sicurezza funzionale dei (meccanici,
sistemi elettrici, elettronici ed elettronici pneumatici, ecc.)
programmabili per applicazioni relative
alla sicurezza
SRPCS elettrici
IEC 62061
Sicurezza del macchinario -
Sicurezza funzionale dei
sistemi di comando e controllo
elettrici, elettronici
Legenda:
ed elettronici programmabili Aspetti relativi alla sicurezza elettrica
correlati alla sicurezza Aspetti relativi alla sicurezza funzionale
Figura 1 – Relazioni tra la IEC 62061 e altre norme relative
Informazioni sull’applicazione raccomandata della IEC 62061 e della ISO 13849-1

(in revisione)
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 4 di 183
La IEC 62061 e la ISO 13849-1 (in revisione) specificano le prescrizioni per la progettazione
e la realizzazione di sistemi di controllo relativi alla sicurezza di macchinari. Si ritiene che
l’uso di una qualsiasi di tali Norme, in conformità al loro campo di applicazione, rispetti le
relative prescrizioni essenziali di sicurezza. La Tab. 1 riassume i campi di applicazione della
IEC 62061 e della ISO 13849-1(in revisione).
NOTA La ISO 13849-1 è attualmente in preparazione da parte del ISO TC 199 e del CEN TC 114.
Tabella 1 – Applicazione suggerita della IEC 62061 e della ISO 13849-1 (in revisione)
Tecnologia che realizza la(e) funzione(i)

ISO 13849-1 (in revisione) IEC 62061
di controllo relativa(e) alla sicurezza
A Non elettrica, es. idraulica X Non contemplata
B Elettromeccanica, es. relè, o elettronica Limitata ad architetture designate Tutte le architetture e fino a SIL 3
non complessa (vedere Nota 1) e fino a PL=e
C Elettronica complessa, es. Limitata ad architetture designate Tutte le architetture e fino a SIL 3
programmabile (vedere Nota 1) e fino a PL=d
D A in combinazione con B Limitata ad architetture designate X vedere Nota 3
(vedere Nota 1) e fino a PL=e
E C in combinazione con B Limitata ad architetture designate Tutte le architetture e fino a SIL 3
(vedere Nota 1) e fino a PL=d
F C in combinazione con A, o C in X vedere Nota 2 X vedere Nota 3
combinazione con A e B
“X“ indica che questa voce è trattata nella Norma indicata nell’intestazione di colonna.
NOTA 1 Le architetture designate sono definite nell’Allegato B della EN ISO 13849-1(rev.) per fornire un approccio
semplificato alla quantificazione dei livelli di prestazione.
NOTA 2 Per l’elettronica complessa: Utilizzare architetture designate in conformità alla EN ISO 13849-1(rev.) fino a
PL=d o qualsiasi architettura conforme alla IEC 62061.

NOTA 3 Per la tecnologia non elettrica, utilizzare come sottosistemi parti conformi alla EN ISO 13849-1(rev.).
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 6 di 183
SICUREZZA DEL MACCHINARIO –
SICUREZZA FUNZIONALE DEI SISTEMI DI COMANDO E CONTROLLO
ELETTRICI, ELETTRONICI ED ELETTRONICI PROGRAMMABILI
CORRELATI ALLA SICUREZZA
1 Campo di applicazione
La presente Norma Internazionale specifica prescrizioni e fornisce raccomandazioni per la

progettazione, l’integrazione e la validazione di sistemi di controllo elettrici, elettronici ed
elettronici programmabili relativi alla sicurezza (SRECS) per macchine (vedere Note 1 e 2).
Essa si applica ai sistemi di controllo utilizzati individualmente o in associazione per eseguire
funzioni di controllo relative alla sicurezza su macchine non mobili e non portatili mentre sono
in funzione, compresi i gruppi di macchine che operano insieme in modo coordinato.
NOTA 1 Nella presente Norma il termine “sistemi elettrici di controllo” è utilizzato per indicare “sistemi di controllo
Elettrici, Elettronici ed Elettronici Programmabili (E/E/PE)”, e “SRECS” è utilizzato per indicare “sistemi di
controllo elettrici, elettronici ed elettronici programmabili relativi alla sicurezza”.
NOTA 2 Nella presente Norma, si assume che la progettazione di sottosistemi elettronici programmabili complessi
o di elementi di sottosistemi sia conforme alle prescrizioni relative della IEC 61508. La presente Norma
offre una metodologia per l’utilizzo, piuttosto che per lo sviluppo, di tali sottosistemi ed elementi di
sottosistemi quali parti di uno SRECS.
La presente Norma è una norma applicativa e non è destinata a limitare o ostacolare il

progresso tecnologico. Essa non tratta tutte le prescrizioni (es., protezioni, interblocchi o
controlli non elettrici) necessarie o richieste da altre norme o regolamenti per proteggere le
persone da pericoli. Ogni tipo di macchina ha prescrizioni uniche che devono essere
rispettate per offrire una sicurezza adeguata.
La presente Norma:
– si riferisce esclusivamente alle prescrizioni per la sicurezza funzionale, destinate a ridurre

il rischio di lesioni o di danni alla salute di persone nelle immediate vicinanze della
macchina o direttamente coinvolte nell’uso della macchina;
– è limitata ai rischi direttamente derivanti dai pericoli della macchina stessa o di un gruppo
di macchine che operano insieme in modo coordinato;
NOTA 3 Le prescrizioni per ridurre i rischi derivanti da altri pericoli sono fornite nelle relative norme di settore.
Per esempio, quando uno o più macchine fanno parte di un’attività di processo, le prescrizioni
funzionali di sicurezza del sistema elettrico di controllo della macchina dovrebbero, inoltre, rispettare
altre prescrizioni (es. la IEC 61511) per quanto attiene alla sicurezza del processo.
– non specifica prescrizioni per le prestazioni di elementi di controllo non elettrici (es.,
idraulici, pneumatici) di macchine;
NOTA 4 Anche se le prescrizioni della presente Norma sono specifiche per i sistemi elettrici di controllo, il
quadro e la metodologia specificati possono essere applicabili a parti di sistemi di controllo relative
alla sicurezza che utilizzano altre tecnologie.
– non tratta i rischi elettrici derivanti dalla stessa apparecchiatura di controllo (es., shock
elettrico; vedere IEC 60204-1).
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 8 di 183
Gli scopi degli Articoli specifici della IEC 62061 sono indicati nella Tab. 2.
Tabella 2 – Panoramica e obiettivi della IEC 62061
Articolo Scopo
4: Specificare la gestione e le attività tecniche necessarie al raggiungimento della sicurezza
Gestione della funzionale prescritta degli SRECS.
sicurezza
funzionale
5: Indicare le procedure per specificare le prescrizioni delle funzioni di controllo relative alla
Prescrizioni sicurezza. Tali prescrizioni sono espresse sotto forma di specifiche di prescrizioni funzionali e di
per la specifica specifiche di prescrizioni per l’integrità della sicurezza.
di funzioni di
controllo
relative alla
sicurezza
6: Specificare i criteri di selezione e/o i metodi di progettazione e di realizzazione degli SRECS per
Progettazione rispettare le prescrizioni di sicurezza funzionale. Questo comprende:
e integrazione
del sistema di scelta dell’architettura del sistema,
controllo
elettrico scelta dell’hardware e del software relativi alla sicurezza,
relativo alla
sicurezza progettazione dell’hardware e del software,
verifica che l’hardware e il software progettati rispettino le prescrizioni di sicurezza funzionale.
7: Specificare le prescrizioni relative alle informazioni per l’uso dello SRECS, da fornire con la
Informazioni macchina. Questo comprende:
per l’uso del
macchinario fornitura del manuale e delle procedure d’uso,
fornitura del manuale e delle procedure di manutenzione.
8: Specificare le prescrizioni per il processo di validazione da applicare allo SRECS. Questo

Validazione del comprende l’ispezione e il collaudo dello SRECS per accertarsi che rispetti le prescrizioni indicate
sistema di nelle specifiche delle prescrizioni di sicurezza.
controllo
elettrico
relativo alla
sicurezza
9: Specificare le prescrizioni per la procedura di modifica da applicare alla modifica dello SRECS.
Modifica del Questo comprende:
sistema di
controllo adeguata pianificazione e verifica delle modifiche a qualsiasi SRECS prima di operare il
elettrico cambiamento;
relativo alla
sicurezza rispetto della specifica delle prescrizioni di sicurezza dello SRECS dopo l’effettuazione di
qualsiasi cambiamento.
2 Riferimenti normativi
I sottoelencati documenti ai quali viene fatto riferimento sono indispensabili per l’applicazione
del presente documento. Per quanto riguarda i riferimenti datati, si applica esclusivamente
l’edizione citata (1) . Per quanto riguarda i riferimenti non datati, si applica l’ultima edizione del
documento normativo cui viene fatto riferimento (compresi gli emendamenti).
———————
(1) N.d.R. Per l’elenco delle Pubblicazioni, si rimanda all’Allegato ZA.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 10 di 183
3 Termini, definizioni e abbreviazioni
3.1 Elenco delle definizioni secondo l’ordine del testo inglese

Termine Numero della
definizione
software applicativo 3.2.46
vincolo dell’architettura 3.2.36
architettura 3.2.35
guasto per cause comuni 3.2.43
componente complesso 3.2.8
funzione di controllo 3.2.14
guasto pericoloso 3.2.40
richiesta (d’intervento) 3.2.25
copertura diagnostica 3.2.38
sistema elettrico di controllo 3.2.3
software incorporato 3.2.47
guasto 3.2.39
avaria 3.2.30
tolleranza all’avaria 3.2.31
linguaggio a variabilità completa (FVL) 3.2.48

blocco funzionale 3.2.32
elemento del blocco funzionale 3.2.33
sicurezza funzionale 3.2.9
integrità della sicurezza dell’hardware 3.2.20
pericolo (derivante dal macchinario) 3.2.10
situazione pericolosa 3.2.11
modalità di richiesta (d’intervento) frequente o continua 3.2.27
linguaggio a variabilità limitata (LVL) 3.2.49
componente a bassa complessità 3.2.7
modalità di richiesta (d’intervento) con bassa frequenza 3.2.26
sistema di controllo della macchina 3.2.2
macchinario (macchina) 3.2.1
tempo medio al guasto (MTTF) 3.2.34
probabilità di guasto pericoloso all’ora (PFH D ) 3.2.28
prova di tenuta 3.2.37

misura protettiva 3.2.12
guasto casuale all’hardware 3.2.44
rischio 3.2.13
guasto in sicurezza 3.2.41
frazione di guasto in sicurezza 3.2.42
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 12 di 183
funzione di sicurezza 3.2.15
integrità della sicurezza 3.2.19
livello di integrità della sicurezza (SIL) 3.2.23
funzione di controllo relativa alla sicurezza (SRCF) 3.2.16
sistema elettrico di controllo relativo alla sicurezza (SRECS) 3.2.4
software relativo alla sicurezza 3.2.50
limite di SIL richiesto 3.2.24
integrità della sicurezza del software 3.2.21
funzione diagnostica dello SRECS 3.2.17
funzione di reazione all’avaria dello SRECS 3.2.18
sottosistema 3.2.5
elemento del sottosistema 3.2.6
guasto sistematico 3.2.45
integrità sistematica della sicurezza 3.2.22
valore di guasto da assumere 3.2.29
validazione 3.2.52
verifica 3.2.51
3.2 Termini e definizioni

Per gli scopi della presente Norma, si applicano i seguenti termini e definizioni.
3.2.1
Macchinario
Insieme di parti o componenti di cui almeno uno mobile, collegati tra loro, con appropriati
attuatori, circuiti di comando (*) e di potenza della macchina ecc., uniti fra loro per una
applicazione ben determinata, in particolare per la trasformazione, il trattamento, la
movimentazione o l’imballaggio di un materiale.
Il termine “macchinario” e macchina” comprendono anche un insieme di macchine che, per

raggiungere uno stesso risulatato, sono disposte e comandate in modo da avere un
funzionamento solidale.
[ISO 12100-1:2003, 3.1]
3.2.2
Sistema di controllo della macchina
Sistema che reagisce a un ingresso, per esempio, dal processo, da altri elementi della
macchina, da un operatore, da apparecchiature esterne di controllo, e genera una o più uscite
facendo in modo che la macchina si comporti nel modo previsto.
3.2.3
Sistema elettrico di controllo
Tutte le parti elettriche, elettroniche ed elettroniche programmabili del sistema di controllo
della macchina utilizzate per fornire, per esempio, funzioni di controllo operativo,
monitoraggio, interblocco, comunicazioni, protezione e relative alla sicurezza.
NOTA Le funzioni di controllo relative alla sicurezza possono essere svolte da un sistema elettrico di controllo
integrato a, o indipendente da, parti del sistema di controllo di una macchina che svolgono funzioni non
relative alla sicurezza.
———————
(*) N.d.R: Vedere (1) N.d.R a pag. 2.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 14 di 183
3.2.4
Sistema Elettrico di Controllo Relativo alla Sicurezza
SRECS
Sistema elettrico di controllo di una macchina il cui guasto può produrre un immediato
aumento del rischio.
NOTA Uno SRECS comprende tutte le parti di un circuito elettrico di controllo, il cui guasto può portare a una
riduzione o a una perdita della sicurezza funzionale, e questo può comprendere circuiti elettrici di potenza
o di controllo.
3.2.5
Sottosistema
Entità del progetto di architettura al livello più elevato dello SRECS, nella quale un guasto a
qualsiasi sottosistema comporta un guasto di una funzione di controllo relativa alla sicurezza.
NOTA 1 Un sottosistema completo può essere costituito da una serie di elementi identificabili e separati del
sottosistema che, se uniti insieme, realizzano i blocchi di funzione assegnati al sottosistema.
NOTA 2 Tale definizione è una limitazione della definizione generale della IEC 61508-4: Gruppo di elementi che
interagiscono in base a un progetto, in cui un elemento di un sistema può essere costituito da un altro
sistema, chiamato sottosistema, che può comprendere hardware, software e interazioni umane.
NOTA 3 Questa definizione differisce dal linguaggio comune, dove il termine “sottosistema” può indicare qualsiasi
suddivisione di un’entità, il termine “sottosistema” è utilizzato nella presente Norma all’interno di una
gerarchia terminologica chiaramente definita: un “sottosistema” è il primo livello di suddivisione di un
sistema. Le parti risultanti da un’ulteriore suddivisione di un sottosistema sono chiamate “elementi del
sottosistema”.
3.2.6
Elemento del sottosistema
Parte di un sottosistema che comprende un unico componente o un qualsiasi gruppo di
componenti.
3.2.7
Componente a bassa complessità
Componente nel quale
– le modalità di guasto sono ben definite; e

– il comportamento in condizioni di avaria può essere definito completamente.
[IEC 61508-4, 3.4.4 modificata]
NOTA 1 Il comportamento del componente a bassa complessità in condizioni di avaria può essere determinato con
metodi analitici e/o di prova.
NOTA 2 Un sottosistema, o l’elemento di un sottosistema, comprendente uno o più interruttori di fine corsa
eventualmente funzionanti per mezzo dell’interposizione di relè elettromeccanici, uno o più contattori per
diseccitare un motore elettrico, costituisce un esempio di componente a bassa complessità.
3.2.8
Componente complesso
Componente nel quale
– le modalità di guasto non sono ben definite; oppure
– il comportamento in condizioni di avaria non può essere definito completamente.
3.2.9
Sicurezza funzionale
Parte della sicurezza della macchina e del suo sistema di controllo che dipende dal
funzionamento corretto dello SRECS, di altri sistemi con tecnologia relativa alla sicurezza e
da impianti esterni per la riduzione del rischio.

NOTA 1 La presente Norma considera esclusivamente la sicurezza funzionale che dipende dal funzionamento
corretto dello SRECS nelle applicazioni dei macchinari.
NOTA 2 La Guida 51 dell’ISO/IEC definisce la sicurezza come l’assenza di rischi inaccettabili.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 16 di 183
3.2.10
Pericolo (derivante dal macchinario)
Fonte potenziale di lesione fisica o di danno per la salute.
[ISO 12100-1: 2003, 3.6 modificata]

NOTA Il termine pericolo può essere qualificato per definire l’origine o la natura del danno previsto (es., pericolo
di scossa elettrica, pericolo di schiacciamento, pericolo di taglio, pericolo tossico, pericolo di incendio).
3.2.11
Situazione pericolosa
Circostanza nella quale una persona è esposta a uno o più pericoli.
[ISO 12100-1:2003, 3.9 modificata]
3.2.12
Misura protettiva
Misura destinata a ottenere una riduzione del rischio.
[ISO 12100-1:2003, 3.18 modificata]
3.2.13
Rischio
Combinazione della probabilità del verificarsi di un danno e della gravità dello stesso.
[ISO 12100-1:2003, 3.11]
3.2.14
Funzione di controllo
Funzione che valuta le informazioni o i segnali in ingresso, e produce informazioni o attività in
uscita.
3.2.15
Funzione di sicurezza
Funzione di una macchina il cui guasto può provocare un immediato aumento del o dei rischi.
[ISO 12100-1:2003, 3.28]

NOTA Tale definizione è diversa da quelle della IEC 61508-4 e della ISO 13849-1.
3.2.16
Funzione di Controllo Relativa alla Sicurezza
SRCF
Funzione di controllo, realizzata da uno SRECS con un livello di integrità specificato,
destinata a mantenere la condizione di sicurezza della macchina, o a evitare un immediato
aumento del o dei rischi.
3.2.17
Funzione diagnostica dello SRECS
Funzione destinata a rilevare avarie nello SRECS e a produrre informazioni o attività
specifiche in uscita alla rilevazione di un’avaria.
NOTA Questa funzione è destinata a rilevare avarie suscettibili di portare al guasto pericoloso di una SRCF e ad
avviare una funzione specifica di reazione alle avarie.
3.2.18
Funzione di reazione alle avarie dello SRECS
Funzione attivata quando la funzione diagnostica dello SRECS rileva un’avaria in uno
SRECS.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 18 di 183
3.2.19
Integrità della sicurezza
Probabilità che uno SRECS o il suo sottosistema esegua in modo soddisfacente le funzioni
prescritte relative alla sicurezza, in tutte le condizioni dichiarate.

NOTA 1 Più elevato è il livello di integrità della sicurezza dell’elemento, minore è la probabilità che esso non
svolga la funzione di controllo prescritta relativa alla sicurezza.
NOTA 2 L’integrità della sicurezza comprende l’integrità della sicurezza dell’hardware (vedere 3.2.20) e l’integrità
sistematica della sicurezza (vedere 3.2.22).
3.2.20
Integrità della sicurezza dell’hardware
Parte dell’integrità della sicurezza di uno SRECS o dei suoi sottosistemi comprendente le
prescrizioni per la probabilità di guasti casuali pericolosi all’hardware e vincoli all’architettura.
3.2.21
Integrità della sicurezza del software
Parte dell’integrità della sicurezza del sistema di uno SRECS o dei suoi sottosistemi relativa
alla capacità del software, in un sistema elettronico programmabile, di svolgere le sue
funzioni di controllo relative alla sicurezza in tutte le condizioni dichiarate, in un intervallo di
tempo dichiarato.

NOTA L’integrità della sicurezza del software non può generalmente essere quantificata con precisione.
3.2.22
Integrità sistematica della sicurezza
Parte dell’integrità della sicurezza di uno SRECS o dei suoi sottosistemi relativa alla sua
resistenza a guasti sistematici (vedere 3.2.45) in modalità pericolosa.

NOTA 1 L’integrità sistematica della sicurezza non può generalmente essere quantificata con precisione.
NOTA 2 Le prescrizioni per l’integrità sistematica della sicurezza si applicano sia agli aspetti hardware che
software di uno SRECS o dei suoi sottosistemi.
3.2.23
Livello di Integrità della Sicurezza
SIL
Livello discreto (uno di tre possibili) per specificare le relative prescrizioni di integrità della
sicurezza delle funzioni di controllo da assegnare allo SRECS, dove il livello tre di integrità
della sicurezza è il livello più elevato di integrità della sicurezza e il livello uno il più basso.

NOTA Il SIL 4 non è considerato nella presente Norma, poiché non è relativo alle prescrizioni per la riduzione
del rischio normalmente associate al macchinario. Per le prescrizioni applicabili al SIL 4, vedere la
IEC 61508-1 e la IEC 61508-2.
3.2.24
Limite di SIL richiesto (per un sottosistema)
SILCL
SIL massimo che può essere richiesto per un sottosistema SRECS in rapporto ai vincoli
dell’architettura e all’integrità sistematica della sicurezza.
3.2.25
Richiesta (d’intervento)
Evento che provoca l’esecuzione della SRCF da parte di uno SRECS.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 20 di 183
3.2.26
Modalità di richiesta (d’intervento) con bassa frequenza
Modalità di funzionamento in cui la frequenza delle richieste a uno SRECS non è superiore a
una all’anno, né superiore al doppio della frequenza della verifica periodica.
NOTA Le apparecchiature progettate esclusivamente in conformità alle prescrizioni per la modalità di
funzionamento a richiesta (d’intervento) con bassa frequenza descritta nella IEC 61508-1 e nella
IEC 61508-2 possono essere inadatte all’uso come parti di uno SRECS nella presente Norma. La modalità
di funzionamento a richiesta (d’intervento) con bassa frequenza non è considerata rilevante per le
applicazioni SRECS ai macchinari.
3.2.27
Modalità di richiesta (d’intervento) frequente o continua
Modalità di funzionamento in cui la frequenza delle richieste a uno SRECS è superiore a una
all’anno, o superiore al doppio della frequenza della verifica periodica.

NOTA 1 La modalità di funzionamento a richiesta (d’intervento) con bassa frequenza non è considerata rilevante
per le applicazioni SRECS ai macchinari. Pertanto, nella presente Norma gli SRECS sono considerati
funzionanti esclusivamente in modalità a richiesta d’intervento frequente o continua.
NOTA 2 La modalità di richiesta (d’intervento) indica che una funzione di controllo relativa alla sicurezza è
eseguita solamente su richiesta, per portare la macchina in uno stato specifico. Lo SRECS non influenza
la macchina fino a quando non vi è una richiesta alla funzione di controllo relativa alla sicurezza.
NOTA 3 La modalità continua indica che una funzione di controllo relativa alla sicurezza è eseguita
continuamente, cioè lo SRECS controlla continuamente la macchina e un guasto (pericoloso) della sua
funzione può condurre a un rischio.
3.2.28
Probabilità di Guasti Pericolosi all’Ora
PFH D
Probabilità media di un guasto pericoloso in 1 h.

NOTA La PFH D non dovrebbe essere confusa con la probabilità di guasto su richiesta (d’intervento) (PFD).
3.2.29
Valore di guasto da assumere
PFH D destinata a essere raggiunta per rispettare una o più prescrizioni specifiche di integrità
della sicurezza.
NOTA Il valore di guasto da raggiungere è specificato in termini di probabilità di un guasto pericoloso all’ora.
3.2.30
Avaria
Condizione anomala suscettibile di provocare una riduzione o una perdita della capacità di
uno SRECS, di un sottosistema, o di un elemento di quest’ultimo di eseguire una funzione
richiesta.
3.2.31
Tolleranza all’avaria
Capacità di uno SRECS, di un sottosistema, o di un elemento di quest’ultimo di continuare a
eseguire una funzione richiesta in presenza di avarie o guasti.
3.2.32
Blocco funzionale
Elemento più piccolo di una SRCF il cui guasto può provocare un guasto della SRCF.
NOTA 1 Nella presente Norma, una SRCF (F) può essere considerata come un AND logico dei blocchi funzionali
(FB), cioè F = FB 1 AND FB 2 AND FB n .
NOTA 2 Questa definizione di un blocco funzionale è diversa da quella utilizzata nella IEC 61131-3 e in altre
norme.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 22 di 183
3.2.33
Elemento di blocco funzionale
Parte di un blocco funzionale.
3.2.34
Tempo Medio al Guasto
MTTF
Aspettativa del tempo medio al guasto.
[IEV 191-12-07, modificata]

NOTA MTTF è normalmente espresso come valore medio dell’aspettativa del tempo al guasto.
3.2.35
Architettura
Configurazione specifica di elementi hardware e software in uno SRECS
3.2.36
Vincolo dell’architettura
Gruppo di prescrizioni architettoniche che limitano il SIL che può essere richiesto per un
sottosistema.
NOTA Le prescrizioni per i vincoli dell’architettura sono indicate in 6.7.6.
3.2.37
Verifica periodica (Proof test)
Prova in grado di rilevare avarie e decadimenti di uno SRECS e dei suoi sottosistemi in modo
che, se necessario, lo SRECS e i suoi sottosistemi possano essere riportati in condizioni

“come nuove”, o quanto più praticamente vicino a tali condizioni.

NOTA Una verifica periodica è destinata a confermare che lo SRECS è in condizioni di assicurare l’integrità
della sicurezza specificata.
3.2.38
Copertura diagnostica
Riduzione della probabilità di guasti pericolosi all’hardware derivanti dal funzionamento degli
esami diagnostici automatici.

NOTA La copertura diagnostica (DC) può essere calcolata con l’equazione seguente:
DC = Ȉ ODD / ODtotal
dove O DD è il tasso di guasti pericolosi all’hardware rilevati, e O Dtotal è il tasso totale di guasti pericolosi
all’hardware.
3.2.39
Guasto
Interruzione della capacità di uno SRECS, di un sottosistema o di un elemento di quest’ultimo
di svolgere una funzione richiesta.
[IEC 61508-4, 3.6.4 modificata e ISO 12100-1:2003, 3.32]

NOTA I guasti possono essere casuali (nell’hardware) o di sistema (nell’hardware o nel software).
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 24 di 183
3.2.40
Guasto pericoloso
Guasto di uno SRECS, di un sottosistema o di un elemento di quest’ultimo, potenzialmente in
grado di provocare un rischio o uno stato non funzionale.

NOTA 1 L’eventualità che tale potenzialità si realizzi può dipendere dall’architettura del canale del sistema; per
esempio, nei sistemi con più canali per migliorare la sicurezza, un guasto hardware pericoloso ha minori
probabilità di portare a uno stato pericoloso globale o a un’incapacità funzionale.
NOTA 2 In un sottosistema a più canali, la probabilità di un guasto pericoloso al sottosistema può essere inferiore
al tasso di guasto pericoloso di un canale che costituisce il sottosistema. La probabilità di un guasto
pericoloso di uno SRECS non può essere inferiore a quella di qualsiasi sottosistema che costituisce lo
SRECS. (Questo deriva dalla definizione particolare di “sottosistema” della presente Norma.)
NOTA 3 Un guasto pericoloso porta, generalmente, a un guasto effettivo o potenziale nell’espletare la SRCF.
3.2.41
Guasto in sicurezza
Guasto di uno SRECS, di un suo sottosistema o di un elemento di quest’ultimo, che non
possiede la potenzialità di provocare un rischio.

NOTA Un guasto in sicurezza non comporta un guasto effettivo o potenziale nell’esecuzione della SRCF.
3.2.42
Frazione di guasto in sicurezza
SFF
Frazione del tasso di guasto globale di un sottosistema che non comporta un guasto
pericoloso.
NOTA La frazione di guasto in sicurezza (SFF) può essere calcolata utilizzando l’equazione seguente:
(6 O S + 6 O DD ) / (6 O S + 6 O D )
dove
OS è il tasso di guasto in sicurezza,
6 O S + 6 O D è il tasso di guasto globale,
O DD è il tasso di guasto pericoloso rilevato dalle funzioni diagnostiche, e
OD è il tasso di guasto pericoloso.

La copertura diagnostica (se presente) di ogni sottosistema nello SRECS è considerata nel calcolo della
probabilità dei guasti casuali all’hardware. La frazione del guasto in sicurezza è presa in considerazione
durante la determinazione dei vincoli dell’architettura sull’integrità della sicurezza dell’hardware (vedere 6.7.7).
3.2.43
Guasto per cause comuni
CCF
Guasto risultante da uno o più eventi che provocano guasti coincidenti a due o più canali
separati di un sottosistema a più canali (architettura ridondante), e che comporta il guasto di
una SRCF.

NOTA Questa definizione è diversa da quella contenuta nella ISO 12100-1 e nella IEV 191-04-23.
3.2.44
Guasto casuale all’hardware
Guasto che si verifica in un momento casuale risultante da uno o più tra i possibili
meccanismi di degrado dell’hardware.
[IEC 61508-4, 3.6.5]
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 26 di 183
3.2.45
Guasto sistematico
Guasto correlato in modo deterministico a una certa causa, il quale può essere eliminato
soltanto mediante una modifica della progettazione o del processo produttivo, delle procedure
operative, della documentazione o di altri fattori relativi.
[IEC 61508-4, 3.6.6]

NOTA 1 La manutenzione correttiva senza modifiche non elimina generalmente la causa del guasto.
NOTA 2 Un guasto sistematico può essere indotto simulando la causa del guasto.
NOTA 3 Esempi di cause di guasti sistematici comprendono errori umani nella:
specifica delle prescrizioni di sicurezza;
progettazione, produzione, installazione e/o esercizio dell’hardware;
progettazione e/o realizzazione del software.
3.2.46
Software applicativo
Software specifico per l’applicazione, realizzato dal progettista dello SRECS, generalmente
contenente sequenze logiche, limiti ed espressioni che controllano i dati in ingresso, i dati in
uscita, i calcoli, e le decisioni necessarie per rispettare le prescrizioni funzionali dello SRECS.
3.2.47
Software incorporato
Software fornito dal costruttore, facente parte dello SRECS, e normalmente non accessibile
per modifiche.
NOTA Il microprogramma e il software del sistema sono esempi di software incorporato.
3.2.48
Linguaggio a variabilità completa
FVL
Tipo di linguaggio che offre la capacità di realizzare una vasta gamma di funzioni e di
applicazioni.
[IEC 61511-1, 3.2.81.1.3 modificata]

NOTA 1 Un esempio tipico di sistemi che utilizzano FVL sono i calcolatori generici.
NOTA 2 Il FVL è generalmente presente nel software incorporato, e raramente utilizzato nel software applicativo.
NOTA 3 Tra gli esempi di FVL vi sono: Ada, C, Pascal, Liste di Istruzioni, linguaggi assembler, C++, Java, SQL.
3.2.49
Linguaggio a variabilità limitata
LVL
Tipo di linguaggio che offre la capacità di unire funzioni di libreria predefinite specifiche per
l’applicazione, allo scopo di realizzare le specifiche delle prescrizioni di sicurezza.
[IEC 61511-1, 3.2.81.1.2 modificata]

NOTA 1 Un LVL offre una stretta corrispondenza funzionale con le funzioni necessarie a svolgere l’applicazione.
NOTA 2 Esempi tipici di LVL sono indicati nella IEC 61131-3. Essi comprendono diagrammi a scala, diagrammi a
blocchi funzionali e diagrammi sequenziali funzionali. Le liste di istruzioni e i linguaggi testuali strutturati
non sono considerati LVL.
NOTA 3 Esempio tipico di sistemi che utilizzano LVL: Controllori Logici Programmabili (PLC) configurati per il
controllo di macchine.
3.2.50
Software relativo alla sicurezza
Software utilizzato per realizzare funzioni di controllo relative alla sicurezza in un sistema
relativo alla sicurezza.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 28 di 183
3.2.51
Verifica
Conferma mediante esame (es., prove, analisi) che lo SRECS, i suoi sottosistemi o gli
elementi di questi ultimi rispettano le prescrizioni definite dalla relativa specifica.
[IEC 61508-4, 3.8.1 modificata e IEC 61511-1, 3.2.92 modificata]

NOTA I risultati della verifica dovrebbero offrire prove obiettive documentate.
ESEMPIO: Le attività di verifica comprendono:

riesami dei dati in uscita (documenti di tutte le fasi) per accertare la conformità con gli obiettivi e le
prescrizioni della fase, tenendo conto dei dati in ingresso specifici per tale fase;
riesami della progettazione;
prove eseguite sui prodotti progettati per garantire che le prestazioni siano conformi alla specifica;
prove di integrazione condotte all’unione di varie parti del sistema in modalità passo-passo e
mediante l’esecuzione di prove ambientali per accertarsi che tutte le parti funzionino insieme nel
modo specificato.
3.2.52
Validazione
Conferma mediante esame (es., prove, analisi) che lo SRECS rispetta le prescrizioni di
sicurezza funzionale dell’applicazione specifica.
3.3 Abbreviazioni
Nella presente Norma sono utilizzate le seguenti abbreviazioni.

CCF Guasto(i) per cause comuni

DC Copertura diagnostica
EMC Compatibilità elettromagnetica
FB Blocco della funzione
FVL Linguaggio a variabilità completa
I/O Ingresso/Uscita (Input/Output)
LVL Linguaggio a variabilità limitata
PFHD Probabilità di guasto pericoloso all’ora
MTTF Tempo medio al guasto
MTTR Tempo medio al ripristino
P TE Probabilità di errore pericoloso di trasmissione
SFF Frazione di guasto in sicurezza
SIL Livello di integrità della sicurezza
SILCL Limite del livello di integrità della sicurezza (SIL) richiesto (per sottosistemi)
S-R Relativo alla sicurezza
SRECS Sistema elettrico di controllo relativo alla sicurezza
SRCF Funzione di controllo relativa alla sicurezza
SRS Specifica delle prescrizioni di sicurezza
SYS Sistema
4 Gestione della sicurezza funzionale
4.1 Scopo
Il presente Articolo specifica le attività gestionali e tecniche necessarie al raggiungimento

della sicurezza funzionale richiesta dello SRECS.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 30 di 183
4.2 Prescrizioni
4.2.1 Per ogni progetto di SRECS deve essere redatto, documentato e per quanto
necessario aggiornato, un piano per la sicurezza funzionale. Il piano deve comprendere
procedure per il controllo delle attività specificate negli Articoli da 5 a 9.
NOTA 1 Il contenuto del piano per la sicurezza funzionale dovrebbe dipendere dalle circostanze specifiche, tra le
quali:
– dimensioni del progetto;
– grado di complessità;
– grado di innovazione del progetto e della tecnologia;
– grado di normalizzazione delle caratteristiche progettuali;
– conseguenze possibili in caso di guasto.
In particolare il piano deve:
a) identificare le attività relative specificate negli Articoli da 5 a 9;

b) descrivere la politica e la strategia per rispettare le prescrizioni di sicurezza funzionale
specificate;
c) descrivere la strategia per raggiungere la sicurezza funzionale nello sviluppo,
nell’integrazione, nella verifica e nella validazione del software applicativo;
d) individuare persone, reparti o altre unità e risorse responsabili dell’esecuzione e della
revisione di ognuna delle attività specificate negli Articoli da 5 a 9;
e) individuare o stabilire le procedure e le risorse per registrare e mantenere le informazioni
relative alla sicurezza funzionale di uno SRECS.
NOTA 2 È opportuno considerare quanto segue:
i risultati dell’identificazione del pericolo e della valutazione dei rischi;

l’apparecchiatura utilizzata per le funzioni relative alla sicurezza, nonché le sue prescrizioni di
sicurezza;
l’organizzazione responsabile del mantenimento della sicurezza funzionale;
le procedure necessarie al raggiungimento e al mantenimento della sicurezza funzionale
(comprese le modifiche agli SRECS).
f) descrivere la strategia per la gestione della configurazione (vedere 9.3) considerando i
relativi aspetti organizzativi, quali le persone autorizzate e le strutture interne
all’organizzazione;
g) fissare un piano di verifica comprendente:
dettagli del periodo di verifica;
dettagli delle persone, reparti o unità incaricate della verifica;
selezione delle strategie e delle tecniche di verifica;
scelta e utilizzo delle apparecchiature di prova;
scelta delle attività di verifica;
criteri di accettazione; e
mezzi da utilizzare per la valutazione dei risultati della verifica;
h) istituire un piano di validazione comprendente:
dettagli del periodo di validazione;
individuazione delle modalità relative di funzionamento della macchina (es.,
funzionamento normale, impostazione);
prescrizioni rispetto alle quali deve essere validato lo SRECS;
strategia tecnica di validazione, per esempio, metodi analitici o prove statistiche;
criteri di accettazione; e
azioni da intraprendere in caso di mancato rispetto dei criteri di accettazione.
NOTA 3 Il piano di validazione dovrebbe indicare se lo SRECS e i suoi sottosistemi devono essere soggetti a
prove individuali, prove di tipo e/o prove su campioni.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 32 di 183
4.2.2 Il piano per la sicurezza funzionale deve essere realizzato in modo da garantire un
controllo tempestivo e una risoluzione soddisfacente degli aspetti relativi a uno SRECS,
derivanti da:
– attività specificate negli Articoli da 5 a 9;

– attività di verifica; e
– attività di validazione.
5 Prescrizioni per la specifica di Funzioni di Controllo Relative alla Sicurezza (SRCF)
5.1 Finalità
Il presente Articolo definisce le procedure per specificare le prescrizioni delle SRCF da

realizzare mediante gli SRECS.
5.2 Specifiche delle prescrizioni per le SRCF
5.2.1 Generalità
5.2.1.1 Qualsiasi necessità per le funzioni di sicurezza deve essere determinata partendo
dalla strategia di riduzione del rischio delineata nella ISO 12100-1, nella ISO 12100-2 e nella
ISO 14121.
5.2.1.2 Ove si sia scelto di realizzare (in tutto o in parte) funzioni di sicurezza mediante
SRECS, devono allora essere specificate le SRCF associate (vedere 3.2.16).
5.2.1.3 Le specifiche di ogni SRCF devono comprendere:
– specifica dei requisiti funzionali (vedere 5.2.3);

– specifica delle prescrizioni per l’integrità della sicurezza (vedere 5.2.4);
e devono essere documentate nella specifica delle prescrizioni di sicurezza (SRS).

NOTA 1 Quando apparecchiature non elettriche contribuiscono alla realizzazione di una funzione di sicurezza in
associazione con mezzi elettrici, il(i) valore(i) di guasto da assumere applicabile(i) alle apparecchiature
non elettriche non è(sono) considerato(i) nella presente Norma. I mezzi elettrici comprendono ogni e
qualunque dispositivo o sistema funzionante in base a principi elettrici, compresi:
– dispositivi elettromeccanici;
– dispositivi elettronici non programmabili;
– dispositivi elettronici programmabili.
NOTA 2 La SRS deve essere sottoposta al controllo della versione all’interno delle procedure di gestione della configurazione
(vedere 9.3).
5.2.1.4 La specifica delle prescrizioni di sicurezza deve essere verificata per garantirne la
coerenza e la completezza per l’uso previsto.
NOTA Questo può, per esempio, essere ottenuto mediante ispezione, analisi, lista di riscontro. Vedere anche B.2.6 della
IEC 61508-7.
5.2.2 Informazioni da rendere disponibili
Le informazioni seguenti devono essere utilizzate per produrre la specifica delle prescrizioni
funzionali e la specifica delle prescrizioni per l’integrità della sicurezza di ogni SRCF:
– risultati della valutazione del rischio per la macchina, comprese tutte le funzioni di
sicurezza ritenute necessarie al processo di riduzione del rischio per ogni specifico
pericolo;
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 34 di 183
– caratteristiche di funzionamento della macchina, tra cui:
x modalità di funzionamento,
x tempo di ciclo,
x prestazione del tempo di risposta,
x condizioni ambientali,
x interazione di persone con la macchina (es., riparazione, regolazione, pulizia);
– tutte le informazioni relative alle SRCF suscettibili di influenzare la progettazione degli
SRECS, tra cui per esempio:
x descrizione del comportamento della macchina da realizzare o da impedire mediante
la SRCF;
x tutte le interfacce tra le SRCF, e tra esse e qualsiasi altra funzione (interna o esterna
alla macchina);
x funzioni di reazione alle avarie prescritte per la SRCF.
NOTA Alcune informazioni potrebbero non essere disponibili o sufficientemente definite prima dell’inizio del
processo di progettazione iterativo degli SRECS, pertanto le prescrizioni per le specifiche di sicurezza
degli SRECS possono dover essere aggiornate durante il processo di progettazione.
5.2.3 Specifica delle prescrizioni funzionali per le SRCF
5.2.3.1 La specifica delle prescrizioni funzionali per le SRCF deve descrivere i dettagli di
ogni SRCF da eseguire, tra cui, per quanto applicabile:
– la(e) condizione(i) (es., modalità di funzionamento) della macchina nella(e) quale(i) la

SRCF deve essere attiva o disabilitata;
– la priorità delle funzioni che possono essere attive contemporaneamente e causare azioni
conflittuali;
– la frequenza di funzionamento di ogni SRCF;
– il tempo di risposta prescritto di ogni SRCF;
– l’interfaccia(e) delle SRCF con altre funzioni della macchina;
– i tempi di risposta prescritti (dispositivi di ingresso e di uscita);
– la descrizione di ogni SRCF;
– la descrizione della(e) funzione(i) di reazione alle avarie e qualsiasi vincolo, per esempio,
al riavvio o alla prosecuzione del funzionamento della macchina quando la reazione
iniziale all’avaria è l’arresto della macchina;
– la descrizione dell’ambiente di funzionamento (es., temperatura, umidità, polvere,
sostanze chimiche, vibrazioni e urti meccanici);
– le prove e le apparecchiature associate (es., apparecchi di prova, porte di accesso per le
prove);
– la frequenza dei cicli di funzionamento, il fattore di utilizzazione dei cicli di lavoro e/o la
categoria di utilizzo per i dispositivi elettromeccanici destinati all’uso nella SRCF.
5.2.3.2 Oltre alle prescrizioni della IEC 61000-6-2, quando uno SRECS è destinato all’uso in
un ambiente industriale, nell’Allegato E vengono forniti i livelli di immunità elettromagnetica
(EM). Gli SRECS destinati all’uso in un altro ambiente EM (es., residenziale) dovrebbero
avere livelli di immunità basati su quelli specificati in norme EMC diverse (es., per un
ambiente residenziale, la IEC 61000-6-1).
NOTA 1 Quando si specificano i livelli di immunità EM è necessario considerare se i livelli utilizzati nelle varie
norme EMC comprendono i casi suscettibili di verificarsi in un’applicazione SRECS compresi quelli con
scarsa probabilità di accadere.
NOTA 2 Il criterio di prestazione dell’immunità EM per la sicurezza funzionale di uno SRECS è indicato in 6.4.3.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 36 di 183
5.2.4 Specifica per le prescrizioni dell’integrità della sicurezza delle SRCF
5.2.4.1 Le prescrizioni dell’integrità della sicurezza per ogni SRCF devono essere derivate
dalla valutazione dei rischi per garantire il raggiungimento della necessaria riduzione del
rischio. La prescrizione dell’integrità della sicurezza nella presente Norma è espressa come
valore di guasto da assumere per la probabilità di guasto pericoloso orario di ogni SRCF.
5.2.4.2 Le prescrizioni dell’integrità della sicurezza per ogni SRCF devono essere specificate
in termini di un SIL in conformità alla Tab. 3, e documentate. Un esempio di metodologia è
indicato nell’Allegato A.
Tabella 3 – Livelli di integrità della sicurezza: valore di guasto da assumere per le SRCF
Livello di integrità della sicurezza Probabilità di un guasto pericoloso per ora (PFHD)
3 t 10 –8 a 10 –7
2 t 10 –7 a 10 –6
1 t 10 –6 a 10 –5
NOTA Quando l’integrità della sicurezza prescritta di una SRCF è inferiore a SIL 1, dovrebbero essere rispettate
almeno le prescrizioni della categoria B della ISO 13849-1.
5.2.4.3 Quando una norma di prodotto specifica un SIL per una SRCF, questa deve avere la
precedenza sull’Allegato A.
6 Progettazione e integrazione del sistema elettrico di controllo relativo alla

sicurezza (SRECS)
6.1 Scopo
Il presente Articolo specifica le prescrizioni per la scelta o la progettazione di uno SRECS per
rispettare le prescrizioni di integrità della sicurezza e funzionali indicate nella specifica delle
prescrizioni di sicurezza (vedere 5.2).
6.2 Prescrizioni generali
6.2.1 Lo SRECS deve essere scelto o progettato per rispettare la specifica delle prescrizioni
di sicurezza (vedere 5.2) e, dove pertinente, la specifica delle prescrizioni per la sicurezza del
software (vedere 6.10) considerando le prescrizioni appropriate della presente Norma.
6.2.2 La scelta o la progettazione dello SRECS (compresa l’architettura globale

dell’hardware e del software, i sensori, gli attuatori, l’elettronica programmabile, il software
incorporato, il software applicativo, ecc.) deve essere conforme a 6.5 o 6.6. Qualunque sia il
metodo utilizzato, lo SRECS deve rispettare le prescrizioni seguenti:
a) prescrizioni per l’integrità della sicurezza dell’hardware compresi:

i vincoli dell’architettura sull’integrità della sicurezza dell’hardware (vedere 6.6.3.3); e
le prescrizioni relative alla probabilità di guasti casuali pericolosi all’hardware
(vedere 6.6.3.2);
b) prescrizioni per l’integrità sistematica della sicurezza (vedere 6.4) comprese:
le prescrizioni per la prevenzione dei guasti, e
le prescrizioni per il controllo dei guasti sistematici;
c) prescrizioni per il comportamento dello SRECS al rilevamento di un’avaria (vedere 6.3);
d) prescrizioni per la progettazione e lo sviluppo del software relativo alla sicurezza (vedere
6.10 e 6.11).
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 38 di 183
6.2.3 La progettazione dello SRECS deve considerare le capacità e i limiti dell’uomo
(compreso l’uso improprio ragionevolmente prevedibile), ed essere adatta alle azioni
assegnate agli operatori, al personale di manutenzione e alle altre persone suscettibili di
interagire con lo SRECS. La progettazione di tutte le interfacce operatore deve seguire regole
di buona pratica relative al fattore umano (vedere la serie IEC 61310) e accogliere i probabili
livelli di formazione o consapevolezza degli operatori, in particolare per i sottosistemi prodotti
su vasta scala, l’operatore dei quali può essere il pubblico.
NOTA L’obiettivo della progettazione dovrebbe essere la prevenzione o l’eliminazione, grazie alla progettazione,
degli errori ragionevolmente prevedibili commessi dagli operatori o dal personale di manutenzione. Ove ciò
non fosse possibile, dovrebbero essere applicati anche altri mezzi (es., azione manuale con conferma
secondaria prima del completamento), per ridurre al minimo la possibilità di errori dell’operatore, e per
accertare che gli errori prevedibili non conducano a un aumento dei rischi.
6.2.4 Durante la progettazione e l’integrazione devono essere prese in considerazione la

manutenibilità e la collaudabilità per facilitare la realizzazione di tali caratteristiche nello SRECS.
6.2.5 La progettazione dello SRECS, comprese le funzioni di diagnostica e di reazione ai

guasti, deve essere documentata. Tale documentazione deve:
essere precisa, completa e concisa;

essere idonea allo scopo previsto;
essere accessibile e aggiornabile;
disporre di un controllo di versione.
6.2.6 L’esito delle attività svolte durante la progettazione, lo sviluppo e la realizzazione dello
SRECS deve essere verificato nelle fasi appropriate.
6.3 Prescrizioni per il comportamento (dello SRECS) al rilevamento di un’avaria

nello SRECS
6.3.1 Il rilevamento di un’avaria pericolosa in qualsiasi sottosistema con una tolleranza

all’avaria dell’hardware superiore a zero deve risultare nell’esecuzione della funzione di
reazione all’avaria specificata.
La specifica può consentire l’isolamento della parte in avaria del sottosistema per mantenere
il funzionamento in sicurezza della macchina durate la riparazione della stessa. In questo
caso, se la parte in avaria non è riparata entro il periodo massimo considerato nel calcolo
della probabilità di un guasto casuale hardware (vedere 6.7.8), deve essere eseguita una
seconda reazione all’avaria per mantenere la condizione di sicurezza.
Quando lo SRECS è progettato per una riparazione in linea, l’isolamento di una parte guasta
deve essere applicabile esclusivamente ove non aumenti la probabilità di un guasto casuale
pericoloso all’hardware dello SRECS oltre a quella specificata nella SRS.
Dopo il verificarsi di avarie tali da ridurre a zero la tolleranza all’avaria dell’hardware, si

applicano le prescrizioni di 6.3.2.
NOTA Il tempo medio di ripristino (vedere IEV 191-13-08), considerato nel modello di affidabilità, deve tenere conto
dell’intervallo delle prove diagnostiche, del tempo di riparazione, e di altri ritardi prima del ripristino.
6.3.2 Quando una o più funzioni diagnostiche sono necessarie per raggiungere la probabilità
prescritta di guasti casuali pericolosi all’hardware, e il sottosistema ha una tolleranza
all’avaria dell’hardware pari a zero, il rilevamento dell’avaria e la reazione specificata ad essa
devono essere eseguiti prima del verificarsi della situazione pericolosa affrontata dalla SRCF.
ECCEZIONE a 6.3.2: In caso di un sottosistema che realizzi una SRCF specifica nella
quale la tolleranza all’avaria dell’hardware è zero e il rapporto tra la frequenza di prova
diagnostica e la frequenza di richiesta (di intervento) è superiore a 100, l’intervallo delle
prove diagnostiche di tale sottosistema deve essere in grado di consentirgli di rispettare le
prescrizioni per la probabilità di un guasto casuale pericoloso all’hardware.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 40 di 183
6.3.3 Quando l’esecuzione di una funzione di reazione all’avaria facente parte di una SRCF
specificata a SIL 3 ha portato all’arresto della macchina, non deve essere possibile un
successivo funzionamento normale della macchina tramite lo SRECS (es., abilitazione al
riavvio della macchina) fino a quando l’avaria non sia stata riparata o rettificata. Per le SRCF
con un’integrità della sicurezza specificata inferiore a SIL 3, il comportamento della macchina
dopo l’esecuzione di una funzione di reazione all’avaria (es., riavvio del funzionamento
normale) deve dipendere dalla specifica delle relative funzioni di reazione all’avaria (vedere
5.2.3).
6.4 Prescrizioni per l’integrità sistematica della sicurezza degli SRECS
NOTA Tali prescrizioni si applicano al “livello di sistema” dove i sottosistemi sono interconnessi per costituire uno
SRECS. Per le prescrizioni relative alla realizzazione dei sottosistemi, vedere 6.7.8.
6.4.1 Prescrizioni per la prevenzione di guasti sistematici all’hardware
6.4.1.1 Devono essere applicate le seguenti misure:
a) progettazione e realizzazione dello SRECS in conformità al piano funzionale della

sicurezza (vedere 4.2);
b) idonea scelta, combinazione, disposizione, assemblaggio e installazione dei sottosistemi,
compresi i cablaggi, i cavi e tutte le interconnessioni;
c) uso dello SRECS nel campo delle specifiche del costruttore;
d) uso delle note applicative del costruttore, per esempio, schede di catalogo, istruzioni di
installazione e regole di buona pratica ingegneristica (vedere anche D.1 della ISO 13849-2);
e) uso di sottosistemi con caratteristiche di funzionamento compatibili (vedere anche D.1
della ISO 13849-2);

f) protezione dello SRECS in conformità alla IEC 60204-1;
g) prevenzione della perdita dei collegamenti funzionali a terra in conformità alla IEC 60204-1;
h) divieto dell’uso di modalità non documentate di funzionamento dei componenti (es.,
registri “riservati” di apparecchiature programmabili); e
i) considerazione di prevedibili usi impropri, cambiamenti ambientali o modifiche.
6.4.1.2 Inoltre, deve essere applicata almeno una delle seguenti tecniche e/o misure
considerando la complessità dello SRECS e del(i) SIL per le funzioni da realizzare mediante
lo SRECS:
a) riesame della progettazione hardware dello SRECS (es., mediante ispezione o

spiegazione esauriente): per stabilire mediante riesame e/o analisi qualsiasi discrepanza
tra la specifica e la realizzazione;
NOTA 1 La realizzazione e l’uso del prodotto devono essere documentati allo scopo di rilevare discrepanze
tra la specifica e la realizzazione, oltre a qualsiasi elemento di dubbio o di potenziale debolezza
relativo a quest’ultima, in modo da poterli risolvere, considerando che durante una procedura di
ispezione l’autore è passivo e l’ispettore è attivo, mentre durante una procedura di spiegazione
esauriente l’autore è attivo e l’ispettore è passivo.
b) strumenti di consulenza, quali pacchetti CAD, in grado di eseguire simulazioni o analisi

e/o di eseguire sistematicamente le procedure di progettazione utilizzando elementi pre-
progettati disponibili e collaudati;
NOTA 2 L’integrità di tali strumenti può essere dimostrata mediante prove specifiche, o mediante dati storici
di utilizzo prolungato soddisfacente, oppure mediante verifica indipendente dei dati di uscita per lo
SRECS specifico in fase di progettazione, vedere 6.11.3.4.
c) simulazione: esecuzione di un’assimilazione sistematica e completa di un progetto di

SRECS in termini di prestazioni funzionali, nonché di corretto dimensionamento e
interazione dei suoi sottosistemi.
ESEMPIO La funzione dello SRECS può essere simulata al calcolatore mediante un modello
comportamentale software (vedere 6.11.3.4), nel quale è simulato il comportamento di ognuno dei
singoli sottosistemi o dei suoi elementi, e la risposta del circuito al quale è connesso viene
esaminata osservando i dati marginali di ogni sottosistema o suo elemento.
.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 42 di 183
6.4.2 Prescrizioni per il controllo dei guasti sistematici
Devono essere applicate le seguenti misure:
a) uso della disalimentazione: lo SRECS deve essere progettato in modo da raggiungere o

mantenere condizioni di sicurezza della macchina in caso di perdita dell’alimentazione
elettrica;
b) misure per il controllo dell’effetto di guasti temporanei ai sottosistemi: gli SRECS devono
essere progettati in modo che, per esempio:
le variazioni di tensione (es., interruzioni, buchi) su un singolo sottosistema o parte di
esso non portino a un pericolo (es., un’interruzione di tensione che interessa il circuito
di un motore non deve provocare un avvio imprevisto al ripristino dell’alimentazione), e
NOTA 1 Vedere anche le prescrizioni relative della IEC 60204-1. In particolare:
le sovratensioni o le sottotensioni dovrebbero essere rilevate a uno stadio sufficientemente
precoce da poter commutare tutte le uscite in condizioni di sicurezza mediante la procedura di
disalimentazione o di migrazione a una seconda unità di alimentazione, e/o
ove necessario, le sovratensioni o le sottotensioni dovrebbero essere rilevate a uno stadio
sufficientemente precoce da poter salvare lo stato interno su una memoria non volatile, in modo
che tutte le uscite possano essere impostate a una condizione di sicurezza dalla procedura di
disalimentazione, o commutate a una condizione di sicurezza dalla procedura di
disalimentazione o dalla migrazione a una seconda unità di alimentazione.
gli effetti delle interferenze elettromagnetiche dell’ambiente fisico o di uno o più
sottosistemi non portino a un pericolo;
c) misure per controllare gli effetti degli errori e altri effetti derivanti da qualsiasi processo di
comunicazione dati, compresi gli errori di trasmissione, le ripetizioni, le cancellazioni, le
inserzioni, i risequenziamenti, le corruzioni, i ritardi e i mascheramenti;
NOTA 2 Ulteriori informazioni sono reperibili nella IEC 60870-5-1, nella EN 50159-1, nella EN 50159-2 e nella
IEC 61508-2.
NOTA 3 Il termine “mascheramento” indica che il contenuto reale di un messaggio non è correttamente
identificato. Per esempio, quando un messaggio da un componente non relativo alla sicurezza è
identificato erroneamente come proveniente da un componente relativo alla sicurezza.
d) quando si verifica un’avaria pericolosa a un’interfaccia, la funzione di reazione all’avaria

deve essere svolta prima del verificarsi del pericolo dovuto a tale avaria. Quando si
verifica un’avaria che riduce a zero la tolleranza all’avaria dell’hardware, tale reazione
all’avaria deve verificarsi prima che venga superato il MTTR stimato (vedere 6.7.4.4.2 g).
Le prescrizioni del punto d) si applicano alle interfacce che costituiscono ingressi e uscite di
sottosistemi e a tutte le altre parti di questi ultimi, che comprendono o richiedono cablaggi
durante l’integrazione (per esempio, dispositivi di commutazione del segnale di uscita di una
barriera optoelettronica, uscita del sensore di una posizione di protezione).
NOTA 4 Questo non prescrive che un sottosistema o un suo elemento debba autonomamente rilevare un guasto alle
proprie uscite. La funzione di reazione all’avaria può anche essere avviata da qualsiasi sottosistema
successivo dopo l’esecuzione di un collaudo diagnostico.
6.4.3 Immunità elettromagnetica (EM)
Oltre alle prescrizioni della IEC 61000-6-2 e ai fenomeni EM indicati nell’Allegato E, uno
SRECS deve soddisfare il seguente criterio prestazionale per la sicurezza funzionale:
– non devono essere introdotte condizioni di rischio o pericoli; e

– non deve verificarsi nessuna perdita della(e) SRCF; oppure
– la(e) SRCF realizzata(e) dallo SRECS può(possono) essere colpita(e) temporaneamente o
in permanenza, purché venga mantenuto o raggiunto uno stato di sicurezza della
macchina prima del verificarsi di un pericolo. Quando fenomeni EM possono portare alla
distruzione di componenti, deve essere assicurato (es., mediante analisi) che la sicurezza
funzionale non sia colpita, anche da uno o più valori inferiori dei fenomeni EM in grado di
causare una distruzione parziale.
NOTA È opportuno considerare inoltre il comportamento dello SRECS in risposta a fenomeni EM a qualsiasi
valore fino a quelli indicati nell’Allegato E.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 44 di 183
6.5 Scelta del sistema elettrico di controllo relativo alla sicurezza
Quando un fornitore offre uno SRECS per una funzione particolare a cui viene fatto
riferimento nella specifica delle prescrizioni di sicurezza, può essere scelto uno SRECS pre-
progettato anziché uno con progettazione personalizzata, purché rispetti le indicazioni della
specifica delle prescrizioni di sicurezza, nonché di 6.3, 6.4 e 6.6.1.
NOTA La scelta di uno SRECS pre-progettato è un’alternativa alla progettazione e allo sviluppo di uno SRECS
specifico in conformità a 6.6.
6.6 Progettazione e sviluppo di un sistema elettrico di controllo relativo alla

sicurezza (SRECS)
6.6.1 Prescrizioni generali
6.6.1.1 Lo SRECS deve essere progettato e sviluppato in conformità alle specifiche delle
prescrizioni di sicurezza per gli SRECS (vedere 5.2).
6.6.1.2 Deve essere seguito e documentato un processo di progettazione chiaramente

strutturato (vedere 6.6.2).
6.6.1.3 Dove l’uso della diagnostica è necessario per raggiungere l’integrità della sicurezza
richiesta quando un’avaria è rilevata, lo SRECS deve eseguire la specifica funzione di
reazione all’avaria (vedere 5.2 e 6.3).
6.6.1.4 Quando uno SRECS o parte di esso (cioè un suo sottosistema) deve realizzare
funzioni SRCF e altre funzioni, tutto il suo hardware e software devono essere considerati
relativi alla sicurezza, salvo che si possa dimostrare che la realizzazione delle SRCF e delle
altre funzioni siano sufficientemente indipendenti l’una dall’altra (cioè che il funzionamento
normale o il guasto di qualsiasi altra funzione non influenzi le SRCF).
NOTA L’indipendenza sufficiente della realizzazione può essere definita mostrando che la probabilità di un guasto
dipendente a parti relative alla sicurezza e parti non relative alla sicurezza è equivalente a quella del livello
di integrità della sicurezza dello SRECS.
6.6.1.5 Se uno SRECS, o i suoi sottosistemi, realizza funzioni di controllo relative alla
sicurezza di diversi livelli di integrità della sicurezza, si deve considerare che il suo hardware
e il suo software abbiano bisogno del più elevato livello di integrità della sicurezza, a meno
che non sia possibile dimostrare che la realizzazione delle funzioni di controllo relative alla
sicurezza dei vari livelli di integrità della sicurezza è sufficientemente indipendente.
NOTA L’indipendenza sufficiente della realizzazione può essere definita mostrando che la probabilità di un guasto
dipendente tra le parti che realizzano SRCF di diversi livelli di integrità è equivalente a quella del livello di
integrità della sicurezza raggiunto dallo SRECS.
6.6.1.6 Le interconnessioni (cioè cavi, cablaggi) diverse dalle comunicazioni di dati digitali
devono essere considerate parte di uno dei sottosistemi al quale sono connesse (vedere
anche il punto d) di 6.4.2).
6.6.1.7 Ove vengano utilizzate comunicazioni di dati digitali all’interno della realizzazione di
SRECS, esse devono soddisfare le prescrizioni relative della IEC 61508-2 in conformità al(i)
valore(i) da raggiungere del SIL della(e) SRCF.
6.6.1.8 Le informazioni per l’uso dello SRECS devono specificare le tecniche e le misure
necessarie al mantenimento del livello di integrità della sicurezza durante la vita progettuale dello
SRECS.
6.6.2 Processo di progettazione e sviluppo
La progettazione e lo sviluppo devono seguire un processo chiaramente definito che consideri

tutti gli aspetti del processo indicati nella Fig. 2.
NOTA L’approccio della presente Norma è l’applicazione di un processo di progettazione strutturato per lo
SRECS, iniziando dalle prescrizioni indicate nelle Specifiche per le Prescrizioni di Sicurezza. La Fig. 3
indica lo schema di flusso del processo di progettazione e la terminologia applicabile ai diversi livelli.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 46 di 183
6.6.2.1 Progettazione dell’architettura del sistema
6.6.2.1.1 Ogni SRCF deve essere scomposta in una struttura di blocchi funzionali, come è
indicato nella specifica delle prescrizioni di sicurezza dello SRECS, per esempio quella
indicata in Fig. 3. Tale struttura deve essere documentata e comprendere:
– la descrizione della struttura;

– le prescrizioni (funzionali, di integrità) della sicurezza per ogni blocco funzionale;
– la definizione degli ingressi e delle uscite di ogni blocco funzionale.
NOTA 1 Il processo di scomposizione dovrebbe portare a una struttura di blocchi funzionali che descrive
completamente le prescrizioni funzionali e di integrità della SRCF. Tale processo dovrebbe essere
applicato fino al livello che consente l’assegnazione delle prescrizioni di integrità e funzionali determinate
per ogni blocco funzionale ai sottosistemi, ove sia possibile tale assegnazione delle prescrizioni funzionali
complete di un blocco funzionale a un sottosistema. Tuttavia, è possibile assegnare più di un blocco
funzionale a un unico sottosistema, ma non è possibile assegnare un blocco funzionale a più sottosistemi
quando si preveda che essi abbiano prescrizioni di integrità e funzionali separate. Quando si intendono
assegnare a elementi ridondanti del sottosistema le prescrizioni funzionali di un blocco funzionale, riferirsi
a 6.7.4.
NOTA 2 Gli ingressi e le uscite di ogni blocco funzionale sono le informazioni trasmesse, per esempio, velocità,
posizione, modalità di funzionamento, ecc..
NOTA 3 I blocchi funzionali sono una rappresentazione delle funzioni della SRCF (vedere 3.2.16) e non
comprendono le funzioni diagnostiche dello SRECS (vedere 3.2.17). Per gli scopi della presente Norma,
le funzioni diagnostiche sono considerate funzioni separate suscettibili di avere una struttura diversa
rispetto alla SRCF (vedere 6.8).
6.6.2.1.2 Deve essere creato un concetto iniziale di architettura dello SRECS in conformità
alla struttura dei blocchi funzionali.
NOTA Dovrebbe esservi una collaborazione continua tra lo sviluppatore dell’architettura di controllo relativa alla
sicurezza, l’ente responsabile della configurazione dei dispositivi, e lo sviluppatore del software. Man mano
che si precisano le prescrizioni di sicurezza e la possibile architettura del software, è possibile un impatto
sull’architettura hardware dello SRECS e, per questo motivo, una stretta collaborazione tra il progettista
dell’architettura dello SRECS, il o i fornitori del sottosistema, lo sviluppatore del software e, se necessario,
il progettista o l’utilizzatore della macchina può aiutare a ridurre la possibilità di guasti al sistema.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 48 di 183
1. Identificazione dello SRECS proposto per ogni
SRCF dalla SRS (vedere 5.2)
2. Scomposizione della SRCF in blocchi funzionali

(6.6.2.1.1) per ogni funzione e creazione di un
concetto iniziale per una o più architetture dello
SRECS (6.6.2.1.2)
3. Dettaglio delle prescrizioni di sicurezza per ogni

blocco funzionale (6.6.2.1.6)
4. Assegnazione dei blocchi funzionali ai

sottosistemi dello SRECS (6.6.2.1.3 e 6.6.2.1.7)
5. Verifica
6A. Selezione del 6B. Progettazione e

dispositivo per il sviluppo del
sottosistema (6.7.3) sottosistema (6.7.4)
6.7
7. Progettazione delle funzioni diagnostiche

come prescritto (6.8)
8. Determinazione del SIL raggiunto Se una qualsiasi

dall’architettura considerata per ogni funzione di prescrizione non è stata
raggiunta, tornare alla
controllo S-R (6.6.3)
relativa fase
9. Documentazione dell’architettura dello

SRECS (6.6.2.1.5)
10. Realizzazione dello SRECS progettato (6.9)
Figura 2 – Schema di flusso del processo di progettazione e di sviluppo dello SRECS
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 50 di 183
6.6.2.1.3 Ogni blocco funzionle deve essere assegnato a un sottosistema all’interno
dell’architettura dello SRECS. A un sottosistema possono essere assegnati più blocchi funzionali.
6.6.2.1.4 Ogni sottosistema e i blocchi funzionali ad esso assegnati devono essere

chiaramente identificati.
6.6.2.1.5 L’architettura deve essere documentata e descrivere i sottosistemi e le loro

relazioni.
Funzione difunction
Safety sicurezza
B B
Vista virtuale: Funzione

Safetydifunction
sicurezza
A A
descrizione funzionale
(F = Fb1 ‘AND’ Fb2 ‘AND’ Fb3)
Blocco funzionale
Function block BB11 Blocco funzionale
Function block B B
2 2 Blocco funzionale
Function block BB
23
Blocco funzionale
Function block AA 11 Blocco
Function
funzionale
block AA22 Function
Blocco block AA33
funzionale
assegnazione
Subsystem 1 1
Sottosistema Subsystem 2 2
Sottosistema Subsystem 3 3
Sottosistema
Vista reale:
disegno architettonico
SRECS
Figura 3 – Assegnazione delle prescrizioni di sicurezza dei blocchi funzionali ai

sottosistemi (vedere 6.6.2.1.1)
6.6.2.1.6 Le prescrizioni di sicurezza per ogni blocco funzionale devono essere quelle
indicate nella specifica delle prescrizioni di sicurezza della SRCF corrispondente in termini di:
– prescrizioni funzionali (es., informazioni in ingresso, funzionamento interno (logico) e

uscita del blocco funzionale);
– prescrizioni dell’integrità della sicurezza.
6.6.2.1.7 Le prescrizioni di sicurezza di un sottosistema devono essere quelle del blocco o

dei blocchi funzionali a esso assegnate. Se a un sottosistema è assegnato più di un blocco
funzionale, si applica la prescrizione di integrità più elevata (vedere 6.6.3). Tali prescrizioni
devono essere documentate come specifiche delle prescrizioni di sicurezza di un
sottosistema.
6.6.3 Prescrizioni per la stima dell’integrità della sicurezza raggiunta da uno SRECS
6.6.3.1 Generalità
Il SIL che può essere raggiunto dallo SRECS deve essere considerato separatamente per
ogni SRCF che lo SRECS deve eseguire.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 52 di 183
Il SIL che può essere raggiunto dallo SRECS deve essere determinato dalla probabilità di un
guasto pericoloso casuale dell’hardware, dai vincoli all’architettura e dall’integrità sistematica
della sicurezza dei sottosistemi che comprendono lo SRECS. Il SIL raggiunto è inferiore o
pari al valore più basso dei SILCL di ognuno dei sottosistemi per l’integrità sistematica della
sicurezza e i vincoli all’architettura.
6.6.3.2 Integrità della sicurezza dell’hardware
6.6.3.2.1 La probabilità di un guasto pericoloso di ogni SRCF dovuta a guasti pericolosi

casuali dell’hardware deve essere pari o inferiore al valore di guasto da assumere indicato
nella specifica delle prescrizioni di sicurezza.
NOTA I valori da assumere associati ai SIL sono indicati nella Tab. 3.
6.6.3.2.2 La probabilità di un guasto pericoloso di ogni SRCF dovuta a guasti casuali

pericolosi dell’hardware deve essere stimata tenendo conto:
a) dell’architettura degli SRECS in relazione a ogni SRCF considerata;

NOTA Questo comporta la decisione sulle modalità di guasto dei sottosistemi in una configurazione in serie
(cioè ogni guasto provoca un guasto nell’esecuzione della SRCF relativa) e in parallelo (ridondante)
(cioè sono necessari guasti coincidenti per un guasto alla SRCF relativa).
b) del tasso stimato di guasti di ogni sottosistema nell’esecuzione del blocco o dei blocchi
funzionali assegnati in qualsiasi modalità suscettibile di causare un guasto pericoloso
dello SRECS.
6.6.3.2.3 La stima della probabilità di un guasto pericoloso deve essere basata sulla
probabilità di un guasto pericoloso casuale dell’hardware di ogni sottosistema relativo,
derivato utilizzando le informazioni prescritte in 6.7.2.2, compreso, quando è il caso, 6.7.2.2
(k), per i processi di comunicazione di dati digitali tra i sottosistemi. La probabilità di guasti
pericolosi casuali dell’hardware dello SRECS è la somma delle probabilità di guasti casuali
pericolosi dell’hardware di tutti i sottosistemi legati all’esecuzione della SRCF, e deve
comprendere, ove è il caso, la probabilità di errori pericolosi di trasmissione per i processi di
comunicazione di dati digitali:
PFHD = PFHD1 + ...+ PFHDn + PTE
NOTA 1 Tale approccio si basa sulla definizione di un blocco funzionale in base alla quale un guasto in qualsiasi
blocco funzionale risulta in un guasto della SRCF (vedere 3.2.16).
NOTA 2 Le interconnessioni diverse dalle comunicazioni di dati digitali sono considerate parte dei sottosistemi.
6.6.3.3 Vincoli all’architettura
Il SIL ottenuto dagli SRECS secondo i vincoli all’architettura è inferiore o pari al SILCL più
basso di qualsiasi sottosistema (vedere 6.7.6) interessato all’esecuzione della SRCF.
NOTA Per esempio uno SRECS comprende due sottosistemi collegati in serie (sottosistema 1 e sottosistema 2) dove la
SFF e la tolleranza all’avaria di ogni sottosistema sono considerate come indicato nella Tab. 4. La PFHD
–8
stimata per lo SRECS è 8 × 10 , che corrisponde a SIL 3. Tuttavia, secondo la Tab. 5, il vincolo all’architettura
del sottosistema 2 limita il SIL raggiungibile dallo SRECS a SIL 2.
Tabella 4 – Caratteristiche dei sottosistemi 1 e 2 utilizzati nel presente esempio

(vedere nota precedente)
Sottosistema Tolleranza all’avaria SFF Limite di SIL richiesto dai vincoli dell’architettura
dell’hardware (vedere Tab. 5)
1 1 95 % SIL 3
2 1 80 % SIL 2
6.6.3.4 Integrità della sicurezza sistematica
Il SIL ottenuto dagli SRECS è inferiore o pari al SILCL più basso di qualsiasi sottosistema
interessato all’esecuzione della SRCF.
NOTA Le misure descritte in 6.7.9 mostrano un SILCL fino a SIL 3 per l’integrità della sicurezza sistematica di un
sottosistema realizzato secondo 6.7.4.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 54 di 183
6.7 Realizzazione dei sottosistemi
6.7.1 Scopo
Lo scopo è la realizzazione di un sottosistema che soddisfi tutte le prescrizioni di sicurezza

dei blocchi funzionali assegnati (vedere Fig. 3). Si considerano due approcci:
– scelta di un dispositivo sufficiente a rispettare le prescrizioni di tale sottosistema, cioè

conforme alle specifiche delle prescrizioni di sicurezza di ognuno dei blocchi funzionali a
esso assegnati e alle prescrizioni della presente Norma, oppure
– progettazione e sviluppo di un sottosistema unendo elementi dei blocchi funzionali e
specificando la loro disposizione e interazione.
6.7.2 Prescrizioni generali per la realizzazione di un sottosistema
6.7.2.1 Il sottosistema deve essere realizzato mediante selezione (vedere 6.7.3) o

progettazione (vedere 6.7.4) in conformità alle proprie specifiche delle prescrizioni di
sicurezza (vedere 6.6.2.1.7), considerando tutte le prescrizioni di 6.2. Il o i sottosistemi che
contengono componenti complessi devono essere conformi alla IEC 61508-2 e alla
IEC 61508-3 a seconda dei casi per il SIL richiesto.
ECCEZIONE: Dove il progetto di un sottosistema comprende un componente complesso tra

gli elementi di un sottosistema, si applica 6.7.4.2.3.
6.7.2.2 Per ogni sottosistema devono essere disponibili le informazioni seguenti:
a) specifica funzionale di quelle funzioni e interfacce del sottosistema che possono essere
utilizzate dalla(e) SRCF;
b) tassi di guasto stimati (dovuti a guasti casuali dell’hardware) dichiarati in qualsiasi

modalità suscettibile di causare un guasto pericoloso dello SRECS;
NOTA 1 Per i sottosistemi elettromeccanici la probabilità di un guasto dovrebbe essere stimata tenendo conto
del numero di cicli di funzionamento dichiarati dal costruttore e del ciclo di servizio (vedere 5.2.3).
Tali informazioni dovrebbero essere basate su un valore B10 (cioè il tempo previsto perché si guasti
(1)
il 10 % del campione). Vedere anche la IEC 61810-2 .
c) limiti al sottosistema per

– l’ambiente e le condizioni di funzionamento da osservare per mantenere la validità
dei tassi di guasto stimati dovuti a guasti casuali dell’hardware; e
– la vita utile del sottosistema, che non dovrebbe essere superata per mantenere la
validità dei tassi stimati di guasto dovuti a guasti casuali dell’hardware;
d) qualsiasi prescrizione per manutenzione e/o prova;
e) copertura diagnostica e intervallo delle prove diagnostiche (quando richiesto, vedere
Nota 2);
NOTA 2 Il punto e) si riferisce alle funzioni diagnostiche esterne al sottosistema. Tali informazioni sono
prescritte solo quando viene richiesto un credito nel modello di affidabilità dello SRECS per l’azione
delle funzioni diagnostiche svolte nel sottosistema.
f) qualsiasi informazione supplementare (es., tempi di riparazione) necessaria a consentire

la derivazione di un tempo medio di ripristino (MTTR) dopo il rilevamento di un’avaria da
parte della diagnostica;
NOTA 3 I punti da b) a f) sono necessari per consentire la stima della probabilità di guasti all’ora della SRCF.
g) il SILCL dovuto ai vincoli all’architettura (vedere 6.7.6), oppure:

– tutte le informazioni necessarie a consentire la derivazione della frazione di guasto
in sicurezza (SFF) del sottosistema applicato nello SRECS; e
NOTA 4 Le informazioni prescritte sono le possibili modalità di guasto del sottosistema. Sulla base di
esse è possibile decidere se il guasto al sottosistema provoca un guasto in condizioni di
sicurezza o di pericolo allo SRECS.
NOTA 5 Per dettagli sulla stima della SFF vedere 6.7.7.
– la tolleranza all’avaria dell’hardware del sottosistema;

———————
(1) In corso di pubblicazione.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 56 di 183
h) qualsiasi limite all’applicazione del sottosistema da osservare per evitare guasti
sistematici;
i) il massimo livello di integrità della sicurezza che può essere richiesto per una SRCF che
utilizza il sottosistema sulla base delle:
– misure e tecniche utilizzate per evitare l’introduzione di avarie sistematiche durante
la progettazione e la realizzazione dell’hardware e del software del sottosistema;
– caratteristiche progettuali che rendono il sottosistema tollerante nei confronti delle
avarie sistematiche.
NOTA 6 I punti h) e i) sono necessari per la determinazione del massimo livello di integrità della
sicurezza richiesto per una SRCF, secondo i vincoli dell’architettura. Inoltre tali punti possono
essere utilizzati per fornire un collegamento (vedere Tabelle 4 e 5) alle prescrizioni di categoria
della ISO 13849-1, in termini di rilevazione di avarie e di tolleranza alle avarie dell’hardware.
j) qualsiasi informazione necessaria a identificare la configurazione hardware e software

del sottosistema allo scopo di consentire la gestione della configurazione di uno SRECS
in conformità a 6.11.3.2;
k) la probabilità di errori pericolosi di trasmissione per i processi di comunicazione di dati
digitali, ove applicabile.
6.7.3 Prescrizioni per la scelta di sottosistemi esistenti (pre-progettati)
6.7.3.1 Quando un fornitore offre un sottosistema per una specifica SRCF, alla quale viene
fatto riferimento nella specifica delle prescrizioni di sicurezza, tale sottosistema pre-
progettato può essere scelto invece di un progetto personalizzato, purché soddisfi le
specifiche delle prescrizioni di sicurezza per il sottosistema, nonché 6.4.3 e 6.7.3.2 o 6.7.3.3.
6.7.3.2 I sottosistemi comprendenti componenti complessi devono essere conformi alla

IEC 61508-2 e alla IEC 61508-3 a seconda dei casi per il SIL prescritto.
ECCEZIONE: Quando il progetto di un sottosistema comprende un componente complesso

come elemento del sottosistema, si applica 6.7.4.2.3.
6.7.3.3 I sottosistemi comprendenti componenti a bassa complessità devono essere

conformi esclusivamente a 6.7.4.4.1, 6.7.6.2, 6.7.6.3, 6.7.7, 6.7.8 e 6.8 della presente Norma.
6.7.4 Progettazione e sviluppo dei sottosistemi
6.7.4.1 Finalità
6.7.4.1.1 La prima finalità è la progettazione di un sottosistema che rispetti le prescrizioni di

sicurezza dei blocchi funzionali assegnati.
6.7.4.1.2 La seconda finalità è la creazione di un’architettura in termini di elementi di

sottosistema che operino insieme in combinazione per rispettare le prescrizioni funzionali e di
integrità della sicurezza di tutti i blocchi funzionali assegnati al sottosistema.
6.7.4.2 Prescrizioni generali
6.7.4.2.1 Il sottosistema deve essere progettato in conformità alle specifiche delle sue
prescrizioni di sicurezza.
6.7.4.2.2 Il sottosistema deve essere in grado di rispettare tutte le prescrizioni da a) a c)

seguenti:
a) le prescrizioni per l’integrità della sicurezza dell’hardware comprendenti:

– i vincoli all’architettura sull’integrità della sicurezza dell’hardware (vedere 6.7.6), e
– le prescrizioni per la probabilità di guasti casuali pericolosi all’hardware (vedere 6.7.8);
b) le prescrizioni per l’integrità della sicurezza sistematica comprendenti:
– le prescrizioni per la prevenzione di guasti (vedere 6.7.9.1), e le prescrizioni per il
controllo di avarie sistematiche (vedere 6.7.9.2), oppure
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 58 di 183
– la dimostrazione che l’apparecchiatura è “convalidata dall’esperianza d’uso”. In
questo caso il sottosistema deve rispettare le prescrizioni relative della IEC 61508-2
(vedere da 7.4.7.5 a 7.4.7.12 della IEC 61508-2,).
c) le prescrizioni per il comportamento del sottosistema al rilevamento di un’avaria
(reazione all’avaria) (vedere 6.3).
6.7.4.2.3 Quando il progetto di un sottosistema comprende un componente complesso (quale un

elemento del sottosistema) che soddisfa tutte le prescrizioni relative della IEC 61508-2 e della
IEC 61508-3 in relazione al SILCL, si può considerare come componente a bassa complessità nel
contesto del progetto di un sottosistema, poiché le sue modalità relative di guasto, il
comportamento al rilevamento di un’avaria, il tasso di guasto e altre informazioni relative alla
sicurezza sono note. Tale componente deve essere utilizzato esclusivamente in conformità alla
sua specifica e le informazioni relative all’uso devono essere fornite dal costruttore.
6.7.4.3 Processo di progettazione e sviluppo dei sottosistemi
La progettazione e lo sviluppo del sottosistema deve seguire un processo chiaramente

definito che deve considerare tutti gli aspetti trattati dal processo indicati nella Fig. 4.
Produzione di un’architettura del

sottosistema in conformità alla
struttura interna dei suoi
elementi (6.7.4.3.1.1.)
Dettaglio delle prescrizioni

(funzionali e di integrità) di
sicurezza per ogni elemento del
sottosistema (6.7.4.3.1.2)
Selezione del(i) dispositivo(i) Progettazione e sviluppo

per gli elementi identificati degli elementi del
del sottosistema (6.7.4.4) sottosistema
Assemblaggio degli elementi del

sottosistema e documentazione della
progettazione (6.7.9)
Determinazione della prestazione di sicurezza

raggiunta dal sottosistema (6.7.5)
Figura 4 – Schema di flusso per la progettazione e lo sviluppo del sottosistema (vedere

casella 6B della Fig. 2)
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 60 di 183
6.7.4.3.1 Progettazione dell’architettura del sottosistema
6.7.4.3.1.1 Durante la progettazione dell’architettura del sottosistema il processo di

scomposizione dovrebbe portare a una struttura di elementi di blocchi funzionali in grado di
rappresentare appieno le prescrizioni funzionali del blocco. Tale processo dovrebbe essere
applicato fino a un livello tale da consentire la determinazione delle prescrizioni funzionali per
ogni elemento del blocco funzionale da assegnare agli elementi del sottosistema (vedere
esempio in Fig. 5).
NOTA Lo schema di flusso del processo di progettazione è indicato nella Fig. 4.
Blocco funzionale
function block
Elemento
function 1 del
block blocco 1
element
Vista virtuale: funzionale
scomposizione
funzionale
Elemento 2 del blocco
(Fb = Fbe1 OR Fbe2) function block element 2
funzionale
Allocation
Assegnazione
Elemento
Subsystem 1 del 1
element
Vista reale: sottosistema
progettazione
architettonica Elemento 2 del
Subsystem element 2
sottosistema
Sottosistema
Subsystem
Vedere 6.7.4.3.1
Figura 5 – Scomposizione di un blocco funzionale in elementi ridondanti del blocco

funzionale e negli elementi del sottosistema a essi associato
6.7.4.3.1.2 L’architettura del sottosistema deve essere documentata in termini dei suoi
elementi e delle relazioni intercorrenti tra essi. Quando è necessario, questo deve
comprendere anche informazioni relative a elementi del blocco funzionale assegnati a
elementi del sottosistema.
6.7.4.4 Prescrizioni per la scelta e la progettazione di elementi per il sottosistema
6.7.4.4.1 Gli elementi per il sottosistema devono essere idonei all’uso previsto e conformi
alle relative norme internazionali ove esistenti.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 62 di 183
6.7.4.4.2 Per ogni elemento del sottosistema devono essere disponibili le informazioni
seguenti:
a) specifica funzionale dell’elemento del sottosistema;

b) specifica delle interfacce dell’elemento del sottosistema (es., caratteristiche elettriche);
c) ogni modalità di guasto, la sua probabilità di verificarsi e, ove rilevante (es., componenti
complessi utilizzati in conformità a 6.7.4.2.3), la copertura diagnostica e la probabilità di
guasto pericoloso;
NOTA Per sottosistemi elettromeccanici, la probabilità di guasto dovrebbe essere stimata tenendo conto
del numero di cicli di funzionamento dichiarati dal costruttore e del ciclo di lavoro dell’applicazione
(vedere 5.2.3). Tale informazione dovrebbe essere basata su un valore B10 (cioè il tempo previsto
(1)
perché si guasti il 10 % del campione). Vedere anche la IEC 61810-2 .
d) vincoli all’elemento del sottosistema per:

l’ambiente e le condizioni di funzionamento che dovrebbero essere osservate per
mantenere la validità delle informazioni fornite nel punto c); e
il ciclo di vita dell’elemento del sottosistema che non dovrebbe essere superato per
mantenere la validità delle informazioni fornite nel punto c);
e) qualsiasi prova di tenuta periodica e/o prescrizione di manutenzione;
f) caratteristiche che contribuiscono alla diagnostica (es., contatti con collegamento meccanico);
g) qualsiasi informazione supplementare (es., tempo di riparazione) necessaria a consentire la derivazione di
un tempo medio di ripristino (MTTR) dopo il rilevamento di un’avaria da parte della diagnostica;
h) qualsiasi limite all’applicazione dell’elemento del sottosistema che dovrebbe essere
osservato allo scopo di evitare guasti sistematici;
i) tolleranza all’avaria dell’hardware.
6.7.5 Determinazione delle prestazioni di sicurezza del sottosistema
Le prestazioni di sicurezza di un sottosistema sono caratterizzate dal SILCL determinato dai

suoi vincoli dell’architettura (6.7.6), dal suo SILCL dovuto all’integrità del sistema (6.7.9) e
dalla sua probabilità di guasto pericoloso casuale dell’hardware (6.7.8).
NOTA 1 Il SILCL di un sottosistema fissa un limite per il livello massimo di integrità della sicurezza che può essere
richiesto per una funzione di controllo relativa alla sicurezza che utilizza tale sottosistema.
NOTA 2 Sono necessarie informazioni su tutti e tre gli aspetti per determinare il SIL raggiunto dal sistema di
controllo relativo alla sicurezza che svolge la SRCF assegnata.
6.7.6 Vincoli dell’architettura sull’integrità della sicurezza dell’hardware dei

sottosistemi
6.7.6.1 Nel contesto dell’integrità della sicurezza dell’hardware, il livello di integrità della sicurezza più
elevato che può essere richiesto per una SRCF è limitato dalla tolleranza all’avaria dell’hardware e dalle
frazioni di guasto in sicurezza dei sottosistemi che svolgono tale SRCF. La Tab. 5 specifica il massimo
livello di integrità della sicurezza che può essere richiesto per una SRCF che utilizza un sottosistema,
tenendo conto della tolleranza all’avaria dell’hardware e della frazione di guasto in sicurezza del
sottosistema. I vincoli dell’architettura contenuti nella Tab. 5 devono essere applicati a ogni sottosistema.
Per quanto attiene a tali vincoli dell’architettura:
a) una tolleranza N all’avaria dell’hardware indica che N+1 avarie possono causare una
perdita della SRCF. Nella determinazione della tolleranza all’avaria dell’hardware non si
tengono in alcuna considerazione altre misure in grado di controllare gli effetti delle
avarie, quali la diagnostica; e
b) quando un’avaria porta direttamente al verificarsi di una o più avarie successive, esse
devono essere considerate un’avaria singola;
c) nella determinazione della tolleranza all’avaria dell’hardware, certe avarie possono essere
escluse, purché la probabilità che si verifichino sia molto bassa in rapporto alle prescrizioni
sull’integrità della sicurezza del sottosistema. Ognuna di tali esclusioni deve essere
giustificata e documentata (vedere anche 6.7.7).
———————
(1) In corso di pubblicazione.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 64 di 183
6.7.6.2 I vincoli dell’architettura della Tab. 5 si applicano a ogni sottosistema che realizza un
blocco funzionale di una SRCF.
6.7.6.3 Un sottosistema comprendente un solo elemento di sottosistema deve soddisfare le

prescrizioni della Tab. 5. In particolare, per un tale sottosistema con una tolleranza all’avaria
dell’hardware pari a zero (cioè N = 0) deve allora essere realizzata una SFF superiore a 99 %
dalla(e) funzione(i) diagnostica(che) di uno SRECS.
NOTA Tale prescrizione è necessaria per garantire l’applicazione di una forma adeguata dei vincoli
all’architettura a sottosistemi comprendenti un solo elemento di sottosistema, allo scopo di giustificare un
SILCL pari a SIL 3.
Tabella 5 – Vincoli dell’architettura sui sottosistemi: massimo SIL che può essere
richiesto per una SRCF che utilizza tale sottosistema
Frazione di guasto in Tolleranza all’avaria dell’hardware (vedere Nota 1)

sicurezza (SFF) 0 1 2
< 60 % Non permesso SIL1 SIL2
(vedere Nota 3)
60 % – < 90 % SIL1 SIL2 SIL3
90 % – < 99 % SIL2 SIL3 SIL3 (vedere Nota 2)
t 99 % SIL3 SIL3 (vedere Nota 2) SIL3 (vedere Nota 2)
NOTA 1 Una tolleranza N all’avaria dell’hardware indica che N+1 avarie possono causare una perdita della
funzione di controllo relativa alla sicurezza.
NOTA 2 Un SILCL 4 non è considerato nella presente Norma. Per il SIL 4 vedere la IEC 61508-1.
NOTA 3 Eccezione, vedere 6.7.7.
6.7.6.4 Quando un sottosistema è progettato in conformità alla ISO 13849-1:1999 e validato

in conformità alla ISO 13849-2:2003, la seguente relazione può essere applicata nel contesto
dei soli vincoli dell’architettura in conformità alla Tab. 6.
Si ritiene che un sottosistema con una categoria specifica conforme alla ISO 13849-1 abbia la
tolleranza all’avaria dell’hardware associata e la frazione di guasto in sicurezza indicata nella
Tab. 6.
NOTA Per realizzare un SIL prescritto è inoltre necessario rispettare le prescrizioni in base alla probabilità di
guasti pericolosi e all’integrità sistematica della sicurezza.
Tabella 6 – Vincoli dell’architettura: SILCL in rapporto alle categorie
Categoria Tolleranza all’avaria SFF Massimo limite di SIL

dell’hardware richiesto dai vincoli
dell’architettura
Si ritiene che i sottosistemi con la categoria
dichiarata abbiano le caratteristiche indicate nel
seguito
1 0 < 60 % Vedere Nota 1
2 0 60 % – 90 % SIL 1
3 1 < 60 % SIL 1
1 60 % – 90 % SIL 2
4 >1 60 % – 90 % SIL 3 (vedere Nota 3)
1 > 90 % SIL 3 (vedere Nota 4)
NOTA 1 I casi per le Categorie 1 e 2 dove la SFF è < 60 % sono considerati non rilevanti nell’ambito della ISO
13849-1, e i sottosistemi progettati in conformità alla ISO 13849-1 realizzano in pratica una SFF
superiore al 60 %.
NOTA 2 Il caso per la Categoria 2 dove la SFF è > 90 % si ritiene non realizzato dalle prescrizioni di
progettazione della ISO 13849-1.
NOTA 3 La copertura diagnostica è ritenuta inferiore a 90 % per i sottosistemi della Categoria 4 nei quali si
considera una tolleranza maggiore di quella all’avaria singola dell’hardware (cioè avarie accumulate).
NOTA 4 La Categoria 4 prescrive una SFF superiore a 90 % ma inferiore a 99 % quando si considera la
tolleranza all’avaria singola dell’hardware.
NOTA 5 La Categoria B in conformità alla ISO 13849-1 non è considerata sufficiente al raggiungimento di SIL 1.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 66 di 183
6.7.7 Stima della frazione di guasto in sicurezza (SFF)
6.7.7.1 La SFF deve essere stimata, ove necessario, per determinare il SILCL dovuto ai
vincoli all’architettura.
6.7.7.2 Per stimare la SFF, deve essere condotta un’analisi (es., analisi dell’albero dei guasti,
analisi delle modalità e degli effetti delle avarie) di ogni sottosistema per determinare tutte le
avarie relative e le corrispondenti modalità di guasto. La sicurezza o la pericolosità di un
guasto dipende dallo SRECS e dalle funzioni di controllo previste relative alla sicurezza,
compresa la funzione di reazione all’avaria. La probabilità di ogni modalità di guasto deve
essere determinata sulla base della probabilità dell’avaria, o delle avarie associate,
considerando l’uso previsto, e può essere derivata da fonti quali:
a) dati affidabili sul tasso di guasti raccolti da esperienze in campo del costruttore relativi
all’uso previsto;
b) dati sui guasti dei componenti provenienti da una fonte di settore riconosciuta (vedere
riferimenti nell’Allegato D) e relativi all’uso previsto;
c) dati sulle modalità di guasto contenuti nell’Allegato D;
d) dati sul tasso di guasto derivati dai risultati di prove e analisi.
ECCEZIONE: Per un sottosistema con una tolleranza all’avaria dell’hardware pari a zero e nel quale le
esclusioni delle avarie sono state applicate ad avarie suscettibili di portare a un guasto pericoloso, il
SILCL dovuto ai vincoli dell’architettura di tale sottosistema è vincolato a un massimo di SIL 2.
6.7.7.3 L’uso di esclusioni di avarie deve essere giustificato (es., mediante analisi) e documentato.
NOTA È ammessa l’esclusione di avarie in conformità a 3.3 e alla Tab. D.5 della ISO 13849-2.
6.7.8 Prescrizioni per la probabilità di guasti pericolosi casuali dell’hardware di

sottosistemi
6.7.8.1.1 La probabilità di guasti pericolosi casuali dell’hardware deve essere pari o inferiore
al valore di guasto da assumere indicato nella specifica delle prescrizioni di sicurezza del
sottosistema (vedere 6.6.2.1.7).
6.7.8.1.2 La probabilità di guasti pericolosi di ogni sottosistema dovuta a guasti casuali

dell’hardware nell’esecuzione dei blocchi funzionali assegnati deve essere stimata tenendo
conto di quanto segue:
a) l’architettura del sottosistema in relazione ai blocchi funzionali assegnati considerati;

NOTA 1 Questo comporta la decisione sull’eventuale presenza di una tolleranza all’avaria dell’hardware.
b) il tasso di guasto di ogni elemento di ogni sottosistema in qualsiasi modalità suscettibile di provocare
un guasto pericoloso del sottosistema rilevato però da prove diagnostiche (vedere 6.3);
c) il tasso di guasto di ogni elemento di ogni sottosistema in qualsiasi modalità suscettibile di provocare
un guasto pericoloso del sottosistema non rilevato da prove diagnostiche (vedere 6.3);
d) la suscettibilità del sottosistema a guasti per cause comuni in grado di causare un guasto
pericoloso al sottosistema (vedere Note 2 e 3);
NOTA 2 Quando per il rilevamento delle avarie si utilizza il confronto tra componenti ridondanti, può verificarsi
un guasto dei mezzi di rilevazione delle avarie se i componenti ridondanti sono in avaria
contemporaneamente nello stesso modo. Questo può essere dovuto a una causa comune,
considerata un guasto per cause comuni (CCF) espresso come fattore beta (ß).
Un approccio semplificato per la stima della suscettibilità a guasti per cause comuni è indicato in
6.7.8.3. Per ulteriori linee guida sulla quantificazione dell’effetto dei guasti per cause comuni relativi
all’hardware, si veda l’Allegato D della IEC 61508-6.
e) la copertura diagnostica delle prove diagnostiche (vedere 3.2.38) e l’intervallo delle prove
diagnostiche associate;
f) gli intervalli ai quali vengono condotte le prove di tenuta per rilevare avarie pericolose non rilevate da
prove diagnostiche e/o il tempo di missione dell’elemento o degli elementi del sottosistema che non
dovrebbe essere superato per mantenere la validità delle informazioni contenute nei punti b) e c);
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 68 di 183
g) i tempi di riparazione per le avarie rilevate quando il sottosistema è progettato per la riparazione in linea.
NOTA 3 Il tempo massimo di riparazione costituisce parte del tempo di ripristino (vedere IEV 191-10-05),
compreso il tempo necessario a rilevare un’avaria e ogni periodo di tempo durante il quale la
riparazione è impossibile (vedere l’Allegato B della IEC 61508-6 per un esempio di come il tempo medio
di ripristino può essere utilizzato per calcolare la probabilità di un guasto). Per situazioni nelle quali la
riparazione può essere condotta solo in un periodo specifico, a macchina spenta e in condizioni di
sicurezza, è particolarmente importante considerare completamente il periodo nel quale non può essere
eseguita alcuna riparazione, specialmente quando esso è particolarmente lungo.
NOTA 4 Un approccio semplificato per la stima della probabilità di guasti pericolosi casuali dell’hardware dei
sottosistemi è indicato in 6.7.8.2. Sono disponibili altri metodi e quello più appropriato dipende dalle
circostanze. Tra i metodi disponibili vi sono:
a) analisi dell’albero dei guasti (vedere B.6.6.5 della IEC 61508-7 e la IEC 61025);
b) modelli di Markov (vedere C.6.4 della IEC 61508-7 e la IEC 61165-13);
c) schemi a blocchi di affidabilità (vedere C.6.5 della IEC 61508-7).
NOTA 5 I guasti dovuti a cause comuni e a processi di comunicazione dati possono derivare da cause diverse
dai guasti effettivi dei componenti hardware (es., interferenze elettromagnetiche, errori nel software,
ecc.). Vedere 6.7.9.
6.7.8.1.3 Per i sottosistemi o i loro elementi nei quali la probabilità di guasto è fornita in
rapporto a un numero di cicli di funzionamento, tali valori devono essere convertiti in valori
temporali utilizzando il ciclo di lavoro specificato per le relative SRCF (vedere 5.2.3).
6.7.8.1.4 L’intervallo delle prove diagnostiche di qualsiasi sottosistema con una tolleranza
all’avaria dell’hardware superiore a zero deve essere tale da consentire al sottosistema di
rispettare la prescrizione per la probabilità di guasto casuale all’hardware (vedere 6.3.1).
NOTA L’intervallo delle prove diagnostiche dovrebbe consentire la rilevazione di un’avaria prima del verificarsi di
un’avaria successiva suscettibile di portare a un guasto pericoloso del sottosistema e di superare il valore
di guasto da raggiungere.
6.7.8.1.5 L’intervallo delle prove diagnostiche di qualsiasi sottosistema con una tolleranza
all’avaria dell’hardware pari a zero deve consentire il rispetto delle prescrizioni di 6.3.2.
6.7.8.1.6 Quando un sottosistema a bassa complessità è progettato secondo la ISO 13849-1,

validato secondo la ISO 13849-2 e rispetta inoltre le prescrizioni dei vincoli dell’architettura
(vedere 6.7.6) e dell’integrità della sicurezza del sistema (vedere 6.7.9), i valori di soglia della
probabilità di guasto pericoloso (PFH D ) indicati nella Tab. 7 possono essere utilizzati per
stimare l’integrità della sicurezza dell’hardware (vedere 6.6.3.2).
Tabella 7 – Probabilità di guasto pericoloso
Tolleranza all’avaria Valori di soglia (orari) PFHD che

DC
dell’hardware possono essere richiesti per il
Categoria sottosistema
Si ritiene che i sottosistemi della categoria indicata abbiano la PFHD (MTTF sottosistema ,
caratteristica sotto riportata.
T prova , DC) (Vedere Nota 1)
1 0 0% Da fornire a cura del fornitore o

utilizzare dati generici (vedere
Allegato D)
2 0 60 % – 90 % 10 –6
3 1 60 % – 90 % 2 x 10 –7
4 >1 60 % – 90 % 3 x 10 –8
1 > 90 % 3 x 10–8
NOTA 1 Il valore di soglia PFHD è una funzione del MTTF del sottosistema (derivato dal costruttore del sottosistema o dai
manuali dei dati dei componenti relativi), del tempo del ciclo di prova/verifica, come indicato nella specifica delle
prescrizioni di sicurezza (tale informazione è richiesta inoltre per la validazione del sottosistema in conformità con
3.5 della ISO 13849-2), e della copertura diagnostica, come indicato nella presente Tabella (questi valori si basano
sulle prescrizioni delle categorie descritte nella ISO 13849-1).
NOTA 2 La Categoria B secondo la ISO 13849-1 non può essere considerata sufficiente a raggiungere SIL 1.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 70 di 183
6.7.8.2 Approccio semplificato per la stima della probabilità di guasti pericolosi
casuali dell’hardware dei sottosistemi
6.7.8.2.1 Generalità
Il presente paragrafo descrive un approccio semplificato per la stima della probabilità di

guasti pericolosi casuali dell’hardware di alcune architetture fondamentali dei sottosistemi e
fornisce formule utilizzabili per i sottosistemi assemblati con elementi a bassa complessità o
complessi. Le formule sono di per sé una semplificazione della teoria dell’analisi
dell’affidabilità, e sono destinate a fornire stime orientate cautelativamente. La condizione
preliminare della validità di tutte le formule contenute in questo paragrafo è che 1 >> O x T 1 ,
dove T 1 è il valore inferiore tra l’intervallo della verifica periodica (proof test) e il ciclo di vita,
e il sottosistema sta operando in “modalità (d’intervento) frequente o continua” (vedere
3.2.27) Vedere anche 6.8.6.
NOTA 1 I risultati ottenuti rappresentano un limite alla probabilità di guasti pericolosi casuali all’hardware dei
sottosistemi e, ove ciò sia inaccettabile, si possono applicare tecniche di modellazione più precise
(vedere 6.7.8.1.1).
NOTA 2 Per le equazioni da (A) a (D) indicate in 6.7.8.2 si presumono tassi di guasto ( O ) costanti e
sufficientemente bassi (1>> O x T) degli elementi del sottosistema (questo significa che il tempo medio di
un guasto pericoloso deve essere molto maggiore dell’intervallo della verifica periodica (proot test) o del
ciclo di vita del sottosistema). Pertanto, può essere utilizzata la seguente equazione fondamentale:
O = 1/MTTF
Per i dispositivi elettromeccanici, il tasso di guasto si determina utilizzando il valore B 10 e il numero di
cicli di funzionamento C dell’applicazione come specificato (vedere 5.2.3).
O = 0,1 x C/ B 10
NOTA 3 I termini usati sono i seguenti:
O = O S + O D ; dove O S è il tasso di guasto in sicurezza e O D è il tasso di guasto pericoloso.
PFH D = O D x 1h; probabilità media di guasto pericoloso entro un’ora.

T 2 : intervallo della prova diagnostica.
T 1 : valore inferiore tra l’intervallo della verifica periodica (proof test) e il ciclo di vita.
6.7.8.2.2 Architettura base, sottosistema A: zero tolleranza all’avaria senza funzione

diagnostica
In tale architettura, qualsiasi guasto pericoloso di un elemento del sottosistema provoca un

guasto alla SRCF. Nell’architettura A, la probabilità di un guasto pericoloso del sottosistema è
la somma delle probabilità di un guasto pericoloso di tutti gli elementi del sottosistema:
O DssA = O De1 + ....+ O Den (A)
PFHDssA = O DssA x 1h
Sottosistema A
Elemento 1 del Elemento n del

sottosistema sottosistema
O De1 O Den
Figura 6 – Sottosistema A, rappresentazione logica

NOTA La Fig. 6 è una rappresentazione logica dell’architettura del sottosistema A e non dovrebbe essere
considerata come la sua realizzazione fisica.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 72 di 183
6.7.8.2.3 Architettura base, sottosistema B: singola tolleranza all’avaria senza funzione
diagnostica
Questa architettura è tale per cui un singolo guasto di qualsiasi elemento del sottosistema
non causa una perdita della SRCF. Pertanto, dovrebbe verificarsi un guasto pericoloso in più
di un elemento prima che si verifichi un guasto alla SRCF. Nell’architettura B, la probabilità di
un guasto pericoloso al sottosistema è:
O DssB =(1 – ȕ)2 x O De1 x O De2 x T 1 + ȕ x (O De1 + O De2 )/2 (B)
PFHDssB = O DssB x 1h
dove
T 1 è il valore inferiore tra l’intervallo della verifica periodica e il ciclo di vita
ȕ è la suscettibilità ai guasti per cause comuni.
Sottosistema B
Elemento 1 del
sottosistema
O De1
Guasto per cause

comuni
Elemento 2 del
sottosistema
O De2
Figura 7 – Sottosistema B, rappresentazione logica

NOTA La Fig. 7 è una rappresentazione logica dell’architettura del sottosistema B e non dovrebbe essere
considerata come la sua realizzazione fisica.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 74 di 183
6.7.8.2.4 Architettura base, sottosistema C: zero tolleranza all’avaria con funzione
diagnostica
Qualsiasi avaria pericolosa dell’elemento di un sottosistema porta a un guasto pericoloso

della SRCF. Quando si rileva un’avaria di un elemento del sottosistema, la o le funzioni
diagnostiche avviano una funzione di reazione all’avaria (vedere 6.3.2). Nell’architettura C, la
probabilità di un guasto pericoloso del sottosistema è:
O DssC = O De1 (1 – DC1) + ....+ O Den (1 – DCn) (C)
PFHDssC = O DssC x 1h
Sottosistema C
Elemento 1 del Elemento n del

sottosistema sottosistema
O De1 O Den
Funzione(i) diagnostica(che)
Figura 8 – Sottosistema C, rappresentazione logica
NOTA La Fig. 8 è una rappresentazione logica dell’architettura del sottosistema C e non dovrebbe essere
considerata come la sua realizzazione fisica. La funzione diagnostica indicata può essere eseguita:
– dal sottosistema che richiede la diagnostica, oppure
– da altri sottosistemi dello SRECS; oppure
– da sottosistemi non interessati all’esecuzione della funzione di controllo relativa alla sicurezza.
6.7.8.2.5 Architettura base, sottosistema D: singola tolleranza all’avaria con funzione(i)

diagnostica(che)
L’architettura evita che un guasto singolo di qualsiasi elemento del sottosistema provochi una
perdita della SRCF, dove
T 2 è l’intervallo della prova diagnostica;

T 1 è il valore inferiore tra l’intervallo della verifica periodica e il ciclo di vita;
ȕ è la suscettibilità a guasti per cause comuni; O D = O DD + O DU ; dove O DD è il tasso
di guasti pericolosi rilevabili, e O DU è il tasso di guasti pericolosi non rilevabili.
O DD = O D x DC
O DU = O D x (1 – DC)
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 76 di 183
Per gli elementi di sottosistemi di diversa progettazione:
O De1 è il tasso di guasti pericolosi dell’elemento 1 del sottosistema;
DC 1 è la copertura diagnostica dell’elemento 1 del sottosistema;
O De2 è il tasso di guasti pericolosi dell’elemento 2 del sottosistema;

DC 2 è la copertura diagnostica dell’elemento 2 del sottosistema .
O DssD = (1 – ȕ)2 {[ O De1 x O De2 x (DC 1 + DC 2)] x T2/2 + [O De1 x O De2 x (2 – DC 1 – DC 2) ] x T1/2 } (D.1)
+ ȕ x (O De1 + O De2 )/2
PFHDssD = O DssD x 1h
Per gli elementi di sottosistemi di uguale progettazione:

O De è il tasso di guasti pericolosi dell’elemento 1 o 2 del sottosistema;
DC è la copertura diagnostica dell’elemento 1 o 2 del sottosistema.
O DssD = (1 – ȕ)2 {[ O De 2 x 2 x DC ] x T2/2 + [ O De 2 x (1 – DC) ] x T1} + ȕ x O De (D.2)
PFHDssD = O DssD x 1h
Sottosistema D
Elemento del
sottosistema
ODFe1
Guasto per
cause comuni
Funzione(i)
diagnostica(che)
Elemento del
sottosistema
ODfe2
Figura 9 – Sottosistema D, rappresentazione logica

NOTA 1 La Fig. 9 è una rappresentazione logica dell’architettura del sottosistema D e non dovrebbe essere
considerata come la sua realizzazione fisica. La(e) funzione(i) diagnostica(che) indicata(e) può(possono)
essere eseguita(e):
dal sottosistema che richiede la diagnostica, oppure
da altri sottosistemi dello SRECS; oppure
da sottosistemi non interessati all’esecuzione della funzione di controllo relativa alla sicurezza.
NOTA 2 Si considera che la reazione all’avaria di tale sottosistema sia l’interruzione dell’operazione relativa come prescritto in 6.3.1.
Quando nella progettazione è incorporata la riparazione in linea, dove la reazione all’avaria è la notifica della stessa ma non
l’interruzione dell’operazione relativa, dovrebbe essere determinata una nuova PFHD per il sottosistema dopo il verificarsi di una
prima avaria per l’architettura rimanente.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 78 di 183
6.7.8.3 Approccio semplificato alla stima del contributo del guasto per cause comuni (CCF)
6.7.8.3.1 È necessaria la conoscenza della suscettibilità di un sottosistema al CCF per

contribuire alla stima della probabilità di un guasto pericoloso casuale all’hardware del
sottosistema (vedere 6.7.8.1).
6.7.8.3.2 Quando si utilizza un’architettura ridondante per realizzare la probabilità prescritta di un guasto
casuale pericoloso all’hardware di un sottosistema, e uno o più CCF possono rimuovere gli effetti di tale
ridondanza, la probabilità di un guasto pericoloso casuale all’hardware basata sulla probabilità del
verificarsi della causa comune deve essere aggiunta alla probabilità di un guasto pericoloso casuale
all’hardware di un sottosistema basato sull’uso della ridondanza.
6.7.8.3.3 La probabilità del verificarsi del CCF dipende, di solito, da una combinazione di
tecnologia, architettura, applicazione e ambiente. L’uso dell’Allegato F è efficace per evitare
molti tipi di CCF.
6.7.8.3.4 L’Allegato F contiene una classifica e una metodologia associata utilizzabile per
stimare l’efficacia delle misure applicate alla progettazione di un sottosistema per limitarne la
suscettibilità al CCF.
6.7.9 Prescrizioni per l’integrità sistematica della sicurezza nei sottosistemi
Il SILCL dovuto all’integrità sistematica della sicurezza in un sottosistema arriva a SIL 3

quando sono rispettate le prescrizioni di 6.7.9.1 e 6.7.9.2.
NOTA Tali prescrizioni sono applicabili al “livello di sottosistema” dove gli elementi di quest’ultimo sono
interconnessi per realizzare un sottosistema. Per altre prescrizioni relative alla realizzazione di uno
SRECS, vedere 6.4.
6.7.9.1 Prescrizioni per evitare i guasti sistematici
6.7.9.1.1 Devono essere applicate le seguenti misure:
a) adeguata selezione, combinazione, disposizione, assemblaggio e installazione dei

componenti, tra i quali cablaggi, cavi e interconnessioni; applicazione delle note
applicative del costruttore e utilizzo di buona pratica ingegneristica;
b) uso del sottosistema e dei suoi elementi nel rispetto delle specifiche del costruttore e
delle istruzioni di installazione;
c) compatibilità: uso di componenti con caratteristiche di funzionamento compatibili;
d) tenuta a condizioni ambientali specificate: progettazione del sottosistema in modo che sia in grado di
funzionare in tutti gli ambienti previsti e in ogni prevedibile condizione avversa, per esempio,
temperatura, umidità, vibrazioni e interferenze elettromagnetiche (EMI) (vedere D.1 della ISO 13849-2);
e) uso di componenti conformi a una norma idonea e dotati di modalità di guasto ben
definite: per ridurre il rischio di guasti non rilevati dall’uso di componenti con
caratteristiche specifiche;
f) uso di materiali idonei e di lavorazioni adeguate: scelta dei materiali, metodi costruttivi e
trattamenti relativi, per esempio, alle sollecitazioni, alla durata, all’elasticità, all’attrito,
all’usura, alla corrosione, alla temperatura, alla conduttività e alla resistenza dielettrica;
g) dimensionamento e forma corretta: considerare gli effetti, per esempio, delle sollecitazioni,
trazione, fatica, temperatura, rugosità superficiale, tolleranze di costruzione.
6.7.9.1.2 Inoltre, devono essere applicate una o più delle misure seguenti tenendo conto
della complessità del sottosistema:
a) riesame della progettazione hardware (es., mediante ispezione o spiegazione esauriente): per stabilire
mediante riesame e/o analisi qualsiasi discrepanza tra la specifica e la realizzazione;
NOTA 1 La realizzazione e l’uso del prodotto devono essere documentate allo scopo di rilevare discrepanze
tra la specifica e la realizzazione, oltre a qualsiasi elemento di dubbio o di potenziale debolezza
relativo alla realizzazione, in modo da poterlo risolvere; si considera che durante una procedura di
ispezione l’autore è passivo e l’ispettore è attivo, mentre durante una procedura di spiegazione
esauriente l’autore è attivo e l’ispettore è passivo.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 80 di 183
b) strumenti CAD in grado di eseguire simulazioni o analisi: eseguire sistematicamente le
procedure di progettazione e includere gli elementi costruttivi automatici idonei disponibili
e collaudati;
NOTA 2 L’integrità di tali strumenti può essere dimostrata mediante prove specifiche, o mediante dati storici
di utilizzo prolungato soddisfacente, oppure mediante verifica indipendente delle uscite per il
sottosistema specifico in fase di progettazione, vedere 6.11.3.4.
c) simulazione: esecuzione di una simulazione sistematica di un progetto di sottosistema in

termini di prestazioni funzionali, nonché di corretto dimensionamento dei componenti.
NOTA 3 La funzione del sottosistema può essere simulata al calcolatore mediante un modello comportamentale software (vedere
6.11.3.4), nel quale è simulato il comportamento di ognuno dei singoli componenti del circuito, e la risposta del
sottosistema al quale è connesso viene esaminata osservando i dati marginali di ogni componente.
6.7.9.2 Prescrizioni per il controllo dei guasti sistematici
6.7.9.2.1 Devono essere applicate le seguenti misure:
a) misure per controllare gli effetti di rotture dell’isolamento, variazioni e interruzioni di

tensione, sovratensioni e sottotensioni: il comportamento dei sottosistemi in risposta a
rottura dell’isolamento, variazioni e interruzioni di tensione, sovratensioni e sottotensioni,
deve essere predefinito in modo che il sottosistema possa raggiungere o mantenere le
condizioni di sicurezza dello SRECS;
NOTA 1 Vedere anche le prescrizioni relative della IEC 60204-1. In particolare:
le sovratensioni dovrebbero essere rilevate in una fase sufficientemente precoce da consentire
l’interruzione di tutte le uscite in condizioni di sicurezza mediante la procedura di
disalimentazione o una commutazione a una seconda sorgente di potenza; e/o
la tensione del circuito di controllo dovrebbe essere monitorata e dovrebbe essere avviata una
disalimentazione o una commutazione a una seconda unità di potenza se non è nel campo
specificato; e/o
le sovratensioni o le sottotensioni dovrebbero essere rilevate in fase sufficientemente precoce in

modo che lo stato interno possa essere salvato su una memoria non volatile (se necessario)
consentendo l’impostazione di tutte le uscite in una condizione di sicurezza dalla procedura di
disalimentazione o da una commutazione a una seconda sorgente di potenza.
b) misure per controllare o evitare gli effetti dell’ambiente fisico (per esempio, temperatura,
umidità, acqua, vibrazioni, polveri, sostanze corrosive, interferenze elettromagnetiche e i
loro effetti): il comportamento del sottosistema in risposta agli effetti dell’ambiente fisico
deve essere predeterminato in modo che lo SRECS possa raggiungere o mantenere una
condizione di sicurezza della macchina. Vedere anche IEC 60204-1;
c) misure per controllare o evitare gli effetti di aumenti o diminuzioni di temperatura: se possono verificarsi
variazioni di temperatura, il sottosistema dovrebbe essere progettato in modo da rilevare, per esempio,
la sovratemperatura prima di iniziare a funzionare all’esterno delle specifiche.
NOTA 2 Ulteriori informazioni sono disponibili in A.10 della IEC 61508-7.
6.7.9.2.2 Inoltre, al controllo dei guasti sistematici, devono essere applicate le seguenti
misure, a seconda dei casi:
– rilevamento guasti mediante monitoraggio in linea;

– prove mediante confronto di hardware ridondante;
– hardware diversificati;
– funzionamento in modalità positiva (es., viene spinto un interruttore di fine corsa
all’apertura di una protezione);
– modalità di guasto orientata;
– sovradimensionamento in base a un coefficiente idoneo quando il costruttore può
dimostrare che questo può aumentare l’affidabilità.
NOTA 1 Quando il sovradimensionamento è idoneo, dovrebbe essere utilizzato un fattore di almeno 1,5.
NOTA 2 Ulteriori informazioni sono disponibili in D.3 della ISO 13849-2.
6.7.10 Assemblaggio del sottosistema
Gli elementi del sottosistema devono essere combinati per costituire il sottosistema in
conformità a 6.7.4.3.1.2 e alla progettazione dettagliata documentata.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 82 di 183
6.8 Realisation of diagnostic functions
6.8.1 Each subsystem shall be provided with associated diagnostic functions that are
necessary to fulfil the requirements for architectural constraints (6.7.6) and the probability of
dangerous random hardware failures (6.7.8).
6.8.2 The diagnostic functions are considered as separate functions that may have a
different structure than the SRCF and may be performed by
– the same subsystem which requires diagnostics; or

– other subsystems of the SRECS; or
– subsystems of the SRECS not performing the SRCF.
NOTE See also Note 3 of 6.6.2.1.
6.8.3 Diagnostic functions shall satisfy the following that are applicable to their associated
SRCFs:
– requirements for the avoidance of systematic failures (see 6.7.9.1); and

– requirements for the control of systematic failures (see 6.7.9.2).
6.8.4 The probability of failure of the SRECS diagnostic function(s) shall be taken into
account when estimating the probability of dangerous failure of the SRCF.
NOTE 1 See also Note 3 of 6.6.2.1.
NOTE 2 Timing constraints applicable to the testing of the subsystem performing a diagnostic function may differ
from those applicable to SRCFs and, in general, the test interval should meet requirements applicable to
a subsystem with a hardware fault tolerance of 1.
NOTE 3 Failure of a diagnostic function(s) should be detected and an appropriate reaction should be taken to
ensure that the contribution of the diagnostic function to the safety integrity of the SRCF is maintained.
The failure of a diagnostic function(s) may be detected by on-line testing, cross-checking by redundant
hardware, etc.
6.8.5 A clear description of the SRECS diagnostic function(s), their failure detection/reaction, and an
analysis of their contribution towards the safety integrity of the associated SRCFs shall be provided.
6.8.6 To apply the simplified approach for the estimation of probability of dangerous random
hardware failures of subsystems (6.7.8.2), the following shall apply:
where a SRECS diagnostic function(s) is necessary to achieve the required

probability of dangerous random hardware failure and the subsystem has a
hardware fault tolerance of zero, then the fault detection and specified fault
reaction shall be performed before the hazard due to this fault can occur; and
SRECS diagnostic function(s) shall as a minimum be implemented so that the
probability of random hardware failure and the systematic safety integrity are the
same as those specified for the corresponding SRCF(s); or
NOTE 1 Architectural constraints on hardware safety integrity need not apply to the realisation of
diagnostic function(s).
where the probability of dangerous random hardware failure is of an order of

magnitude greater than that specified for the SRCF, then a test shall be performed
to determine whether diagnostic function(s) or diagnosing device(s) remain
operational. It is assumed that such a test of the diagnostic function(s) or
diagnosing device(s) be carried out at a minimum of 10 times during the interval
between proof tests applied to the subsystem.
NOTE 2 A test of the diagnostic function(s) should as far as practicable cover 100 % of those parts
implementing the diagnostic function(s).
NOTE 3 Where a diagnostic function is implemented by the logic solver of the SRECS it can be
unnecessary to perform a separate test of the diagnostic function as its failure can be
revealed as a failure of the SRCF.
NOTE 4 A test can be performed by either external means (e.g. test equipment) or internal dynamic
checks (e.g., embedded within the logic solver) of the SRECS.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 83 di 183
6.9 Realizzazione hardware dello SRECS
Lo SRECS deve essere realizzato in conformità al progetto documentato dello SRECS.
6.9.1 Interconnessione dello SRECS
6.9.1.1 Lo SRECS deve essere interconnesso in modo da soddisfare le parti appropriate

della specifica delle prescrizioni di sicurezza dello SRECS e le prescrizioni relative ai
conduttori, alle pratiche di cablaggio e collegamento della IEC 60204-1.
6.9.1.2 Le misure per evitare e controllare i guasti dei conduttori e dei cavi interconnessi
devono essere realizzate in conformità a 6.4.1 e 6.4.2.
6.10 Specifica delle prescrizioni di sicurezza del software
6.10.1 Generalità
Quando deve essere utilizzato un software in qualsiasi parte di uno SRECS che realizza una
o più funzioni di controllo relative alla sicurezza, deve essere sviluppata e documentata una
specifica delle prescrizioni di sicurezza del software.
6.10.2 Prescrizioni
6.10.2.1 Per ogni sottosistema deve essere sviluppata una specifica delle prescrizioni di
sicurezza del software sulla base della specifica e dell’architettura dello SRECS.
6.10.2.2 La specifica delle prescrizioni di sicurezza del software di ogni sottosistema deve
essere derivata: (1) dalle prescrizioni di sicurezza specificate della SRCF, (2) dalle
prescrizioni derivanti dall’architettura dello SRECS e (3) da qualsiasi prescrizione del piano di
sicurezza funzionale (vedere 4.2). Tali informazioni devono essere rese disponibili allo
sviluppatore del software applicativo.
6.10.2.3 La specifica delle prescrizioni di sicurezza del software applicativo deve essere
sufficientemente dettagliata da consentire alla progettazione e alla realizzazione dello SRECS
di raggiungere l’integrità della sicurezza prescritta e consentire la verifica.
6.10.2.4 Lo sviluppatore del software applicativo deve riesaminare le informazioni della

specifica per accertarsi che le prescrizioni siano adeguatamente specificate. In particolare, lo
sviluppatore del software deve uniformarsi alla presente Norma comprendendo quanto segue:
SRCF;
configurazione o architettura del sistema;
prestazioni di capacità e di tempo di risposta;
apparecchiature e interfacce operatore;
tutte le modalità relative di funzionamento della macchina indicate nella specifica delle
prescrizioni di sicurezza;
prove diagnostiche dei dispositivi esterni (es., sensori ed elementi finali).
6.10.2.5 Le prescrizioni specificate per la sicurezza del software devono essere espresse e
strutturate in modo da essere:
chiare, verificabili, collaudabili, mantenibili e funzionali, commisurate con il livello di

integrità della sicurezza;
rintracciabili fino alla specifica delle prescrizioni di sicurezza dello SRECS;
esenti da terminologia e descrizioni ambigue.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 86 di 183
6.10.2.6 La specifica delle prescrizioni per la sicurezza del software deve esprimere le
proprietà prescritte di ogni sottosistema, fornendo informazioni che consentano la scelta di
apparecchiature adeguate. Devono essere specificate le prescrizioni per le SRCF seguenti
basate sul software:
– logica (cioè funzionalità) di tutti i blocchi funzionali assegnati a ogni sottosistema;

– interfacce di ingresso e di uscita assegnate a ogni blocco funzionale;
– formato e campi dei valori dei dati di ingresso e di uscita e loro relazione con i blocchi
funzionali;
– dati idonei a descrivere qualsiasi limite di ogni blocco funzionale, per esempio, massimo
tempo di risposta, valori limite per i controlli di plausibilità;
– funzioni diagnostiche di altri dispositivi nello SRECS (es., sensori ed elementi finali) da
realizzare da parte del sottosistema;
– funzioni che consentono alla macchina di raggiungere o mantenere una condizione di sicurezza;
– funzioni relative al rilevamento, alla notifica e alla gestione delle avarie;
– funzioni relative ai collaudi periodici in linea e fuori linea delle SRCF;
– funzioni che impediscono la modifica non autorizzata degli SRECS;
– interfacce con funzioni non SRCF; e
– prestazioni di capacità e di tempo di risposta.
NOTA Le interfacce comprendono mezzi di programmazione in linea e fuori linea.
6.10.2.7 Quando è il caso, nella documentazione devono essere utilizzati metodi

semiformali, quali schemi logici, blocchi funzionali o schemi di sequenza.
NOTA Linee guida sulla documentazione del software sono contenute nella IEC 61506, nella ISO/IEC 15910 e
nella ISO/IEC 9254.
6.11 Progettazione e sviluppo del software
6.11.1 Progettazione e sviluppo del software incorporato
Il software incorporato inserito nei sottosistemi deve essere conforme alla IEC 61508-3 a
seconda dei casi per il SIL richiesto.
NOTA 1 Vedere anche 6.7.3.2.
NOTA 2 L’Allegato C è fornito per aiutare nella progettazione e nello sviluppo del software incorporato utilizzato
per realizzare SRCF in uno SRECS.
6.11.2 Parametrizzazione basata sul software
6.11.2.1 La parametrizzazione di parametri relativi alla sicurezza basata sul software deve
essere considerata un aspetto della progettazione degli SRECS relativo alla sicurezza,
descritto nella specifica delle prescrizioni per la sicurezza del software (vedere 6.10). La
parametrizzazione deve essere effettuata utilizzando uno strumento dedicato fornito dal
fornitore dello SRECS o dei sottosistemi relativi. Tale strumento deve avere un’identificazione
propria (nome, versione, ecc.). Lo strumento di parametrizzazione deve impedire le modifiche
non autorizzate, per esempio, utilizzando una password.
6.11.2.2 Deve essere mantenuta l’integrità di tutti i dati utilizzati per la parametrizzazione.
Questo deve essere ottenuto con l’applicazione di misure atte a:
– controllare il campo degli ingressi validi;

– controllare la corruzione dei dati prima della trasmissione;
– controllare gli effetti degli errori del processo di trasmissione dei parametri;
– controllare gli effetti della trasmissione incompleta dei parametri; e
– controllare gli effetti di avarie e guasti hardware e software dello strumento utilizzato per
la parametrizzazione.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 88 di 183
6.11.2.3 Lo strumento utilizzato per la parametrizzazione deve rispettare le prescrizioni
seguenti:
– tutte le prescrizioni relative di un sottosistema conformemente alla presente Norma per

garantire una parametrizzazione corretta; oppure
– deve essere utilizzata una procedura speciale per l’impostazione dei parametri relativi alla sicurezza. Tale
procedura deve comprendere la conferma dei parametri inseriti nello SRECS mediante:
y la ritrasmissione dei parametri modificati allo strumento di parametrizzazione; oppure
y altri mezzi per confermare l’integrità dei parametri;
e la successiva conferma (es., da parte di un operatore adeguatamente specializzato e il
controllo automatico mediante uno strumento di parametrizzazione);
NOTA Questo è particolarmente importante quando la parametrizzazione viene svolta utilizzando un
dispositivo non specificatamente destinato a tale scopo (es., personal computer o equivalente).
– i moduli software utilizzati per la codifica/decodifica nel processo di trasmissione/

ritrasmissione e i moduli software utilizzati per la visualizzazione all’utente dei parametri
relativi alla sicurezza devono, come minimo, usare funzioni diversificate per evitare guasti
di sistema.
6.11.2.4 La documentazione della parametrizzazione basata sul software deve indicare i dati
utilizzati (es., gruppi di parametri predefiniti) e le informazioni necessarie all’identificazione
dei parametri associati allo SRECS, delle persone che svolgono la parametrizzazione, nonché
altre informazioni relative, quali la data di parametrizzazione.
6.11.2.5 Le seguenti attività di verifica si applicano alla parametrizzazione basata sul software:
– verifica dell’impostazione corretta di ogni parametro relativo alla sicurezza (minimo,

massimo e valori rappresentativi);

– verifica della plausibilità dei parametri relativi alla sicurezza, per esempio, mediante
rilevamento di valori non validi, ecc.;
– verifica del divieto di modifica non autorizzata di parametri relativi alla sicurezza;
– verifica che i dati/segnali per la parametrizzazione siano generati ed elaborati in modo
che i guasti non possano portare a una perdita di SRCF.
NOTA Questo è particolarmente importante quando la parametrizzazione viene svolta utilizzando un
dispositivo non specificatamente destinato a tale scopo (es., personal computer o equivalente).
6.11.3 Progettazione e sviluppo del software applicativo
NOTA Il presente paragrafo si basa sulla IEC 61508-3.
6.11.3.1.1 Le prescrizioni della IEC 61508-3 si applicano ai linguaggi a variabilità completa

(FVL). Le seguenti prescrizioni si applicano al software applicativo basato su linguaggi a
variabilità limitata (LVL).
6.11.3.1.2 Deve essere verificato l’esito delle attività svolte durante lo sviluppo del software
applicativo nelle fasi appropriate.
6.11.3.1.3 Il metodo di progettazione e il linguaggio applicativo scelto per soddisfare il SIL

richiesto della SRCF deve possedere caratteristiche relative all’applicazione in grado di favorire:
a) astrazione, modularità e altre caratteristiche che controllano la complessità; ove possibile,

il software deve essere basato su funzioni logiche dimostrate che possono comprendere
funzioni di libreria utente e regole definite per il collegamento di funzioni logiche;
b) espressioni di
funzionalità, idealmente come descrizioni logiche o funzioni algoritmiche;
flusso di informazioni tra elementi modulari;
sequenziamento e prescrizioni temporali;
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 90 di 183
vincoli temporali;
strutture dei dati e loro proprietà, compresi i tipi di dati e la validità dei campi di dati;
c) comprensione da parte degli sviluppatori e di altri che devono capire il progetto, dal punto
di vista sia di una comprensione funzionale dell’applicazione sia della conoscenza dei
vincoli della tecnologia SRECS;
d) verifica e validazione, comprese le prove strutturali (scatola bianca) del software applicativo, le prove
funzionali (scatola nera) del programma applicativo integrato e le prove di interfaccia (scatola grigia)
delle interazioni con lo SRECS e la configurazione specifica dell’hardware per l’applicazione;
e) modifica in condizioni di sicurezza.
6.11.3.1.4 La prova deve essere il metodo di verifica principale utilizzato per il software
applicativo. La pianificazione delle prove deve richiamare quanto segue:
– la politica per la verifica dell’integrazione del software e dell’hardware;

– casi e risultati di prova;
– tipi di prove da eseguire;
– apparecchiature di prova, compresi strumenti, software di supporto e descrizione della
configurazione;
– criteri di prova in base ai quali deve essere giudicato il completamento delle stesse;
– ubicazione fisica (es., fabbrica o sito);
– dipendenza da funzionalità esterne;
– numero di casi di prova necessari; e
– completezza rispetto alle funzioni o alle prescrizioni relative.
6.11.3.1.5 Quando il software applicativo deve realizzare funzioni di controllo sia relative
alla sicurezza sia non relative alla sicurezza, tutto il software applicativo deve essere
considerato relativo alla sicurezza, a meno che non possa essere dimostrata nel progetto
un’autonomia adeguata tra le funzioni.
6.11.3.1.6 Il progetto deve comprendere verifiche dell’integrità dei dati e controlli di logicità al livello
applicativo (es., controlli nei collegamenti di comunicazione, controlli dei delimitatori sugli ingressi dei
sensori e sui parametri dei dati).
6.11.3.1.7 Il progetto software applicativo deve comprendere l’automonitoraggio del flusso di

controllo e del flusso dati, a meno che tali funzioni non siano incluse nel software incorporato.
Al rilevamento di un guasto, devono essere compiute azioni adeguate per raggiungere o
mantenere una conduzione di sicurezza.
6.11.3.1.8 Quando librerie software precedentemente sviluppate devono essere utilizzate come
parte del progetto, deve essere giustificata la loro idoneità a rispettare le specifiche delle
prescrizioni per la sicurezza del software. L’idoneità deve basarsi su riscontri soddisfacenti di
funzionamento in applicativi analoghi che abbiano dimostrato di avere analoghe funzionalità, oppure
essere soggetta alle stesse procedure di verifica e di validazione previste per qualsiasi software
relativo alla sicurezza di nuova concezione. Devono essere valutati i vincoli dell’ambiente software
precedente (per esempio dipendenze dal sistema operativo e dal compilatore).
6.11.3.1.9 Qualsiasi modifica o cambiamento al software applicativo deve essere soggetto a

un’analisi di impatto che identifichi tutti i moduli software interessati e le necessarie attività di
riverifica o ricontrollo, per confermare la continua conformità alla specifica per le prescrizioni
per la sicurezza del software.
6.11.3.2 Gestione della configurazione del software
6.11.3.2.1 Il piano per la sicurezza funzionale deve definire la strategia per lo sviluppo,
l’integrazione, la verifica e la validazione del software.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 92 di 183
6.11.3.2.2 La gestione della configurazione del software deve:
– garantire lo svolgimento di tutte le operazioni necessarie per dimostrare il raggiungimento

dell’integrità della sicurezza del software richiesta;
– mantenere con precisione e con identificazione univoca tutti i documenti relativi alle voci
di configurazione necessari al mantenimento dell’integrità dello SRECS. Le voci di
configurazione devono comprendere almeno quanto segue:
x analisi e prescrizioni di sicurezza;
x specifiche del software e documenti del progetto;
x moduli del codice sorgente del software;
x piani di prove e risultati;
x moduli e pacchetti software preesistenti da incorporare nello SRECS;
x tutti gli strumenti e gli ambienti di sviluppo utilizzati per creare, provare o svolgere
qualunque azione sul software applicativo;
– applicare procedure di modifica-controllo per:
x impedire modifiche non autorizzate;
x documentare le richieste di modifica;
x analizzare l’impatto delle modifiche proposte e approvare o rifiutare le richieste;
x documentare i dettagli e l’autorizzazione per tutte le modifiche approvate;
x documentare la configurazione software nei punti appropriati dello sviluppo del
software;
– documentare le informazioni seguenti per consentire una verifica successiva: stato della
versione, giustificazione e approvazione di tutte le modifiche e dettagli delle stesse;

– documentare formalmente l’uscita del software applicativo. Copie principali del software e
di tutta la documentazione associata devono essere conservate per consentire la
manutenzione e la modifica del software pubblicato durante tutta la sua vita utile.
6.11.3.3 Prescrizioni per l’architettura del software
NOTA 1 L’architettura del software definisce i componenti e i sottosistemi principali del software di sistema e
applicativo, le loro interconnessioni e le modalità di raggiungimento degli attributi richiesti. Tra gli esempi di
moduli di software applicativo vi sono le funzioni applicative replicate nella macchina, gli ingressi/uscite della
macchina, i componenti di esclusione e di disabilitazione, i controlli della validità dei dati e del campo, ecc..
NOTA 2 L’architettura del software è inoltre influenzata dall’architettura sottostante del sottosistema offerta dal
fornitore.
6.11.3.3.1 Il progetto dell’architettura del software deve essere basato sulla specifica di
sicurezza per lo SRECS richiesta entro i vincoli dell’architettura del sistema dello SRECS e
del progetto del sottosistema.
6.11.3.3.2 Il progetto dell’architettura del software deve:
a) offrire una descrizione globale della struttura interna e del funzionamento dello SRECS e
dei suoi componenti (vedere nota);
b) comprendere la specifica di tutte le componenti software identificate e la descrizione del
collegamento e delle interazioni tra componenti (software e hardware) identificate;
c) comprendere la progettazione interna e l’architettura di tutte le componenti identificate
diverse dalle scatole nere;
d) identificare i moduli software inclusi nello SRECS ma non utilizzati in alcuna modalità di
funzionamento relativa alla sicurezza.
NOTA È particolarmente importante che la documentazione dell’architettura sia aggiornata e completa rispetto
agli SRECS.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 94 di 183
6.11.3.3.3 Deve essere descritto e giustificato un insieme di tecniche e misure necessarie
durante il progetto del software applicativo per soddisfare la specifica. Tali tecniche e misure
devono mirare ad accertare la prevedibilità del comportamento degli SRECS ed essere
coerenti con qualsiasi vincolo identificato nella documentazione degli SRECS.
6.11.3.3.4 Devono essere descritte e giustificate le misure utilizzate per mantenere

l’integrità di tutti i dati. Tali dati possono comprendere dati di ingresso-uscita macchina, dati
di comunicazione, di operazione di interfaccia, di manutenzione e del database interno.
6.11.3.4 Prescrizioni per gli strumenti di supporto, il manuale utente e i linguaggi applicativi
6.11.3.4.1 Deve essere scelto un idoneo inisieme di strumenti, tra cui la gestione della
configurazione, la simulazione e l’organizzazione delle prove. Deve essere considerata la
disponibilità di strumenti idonei (non necessariamente quelli utilizzati durante lo sviluppo
iniziale del sistema) per fornire i servizi relativi per l’intero ciclo di vita utile dello SRECS.
Deve essere spiegata e documentata l’idoneità degli strumenti.
NOTA La scelta di strumenti di sviluppo dipende dalla natura delle attività di sviluppo del software, dal software
incorporato e dalla sua architettura. Possono essere necessari strumenti di verifica e di validazione, quali
analizzatori di codici e simulatori.
6.11.3.4.2 Ove necessario, deve essere definito un sottoinsieme del linguaggio di

programmazione dell’applicazione.
6.11.3.4.3 Il software applicativo deve essere progettato considerando i vincoli e le

debolezze note, comprese nei manuali utente dello SRECS e dei sottosistemi.
6.11.3.4.4 Il linguaggio dell’applicazione selezionato deve:

– essere elaborato utilizzando un traduttore/compilatore che deve essere valutato per

definirne l’idoneità allo scopo;
– essere completamente e inequivocabilmente definito, o limitato a caratteristiche
inequivocabilmente definite;
– corrispondere alle caratteristiche dell’applicazione;
NOTA Per esempio, una caratteristica dell’applicazione si riferisce a qualsiasi vincolo di prestazione.
– contenere caratteristiche che facilitino il rilevamento di errori di programmazione; e

– supportare caratteristiche adatte al metodo di progettazione;
oppure, le deficienze del linguaggio utilizzato devono essere documentate nella descrizione del
progetto dell’architettura del software, e l’idoneità del linguaggio allo scopo deve essere spiegata
comprendendo le ulteriori misure necessarie ad affrontare gli svantaggi del linguaggio identificati.
6.11.3.4.5 Le procedure per l’uso del linguaggio applicativo devono specificare buone
pratiche di configurazione, condannare caratteristiche generiche e non sicure del software
(per esempio, caratteristiche non definite del linguaggio, progetti non strutturati, ecc.),
identificare controlli che possano essere utilizzati per rilevare errori di configurazione, e
specificare procedure per la documentazione del programma applicativo. Come minimo, nella
documentazione del programma applicativo, devono essere contenute le informazioni
seguenti:
a) organizzazione legale (per esempio azienda, autore(i), ecc);

b) descrizione;
c) tracciabilità alle prescrizioni funzionali dell’applicazione;
d) tracciabilità alla funzione di libreria normalizzata;
e) ingressi e uscite; e
f) gestione della configurazione.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 96 di 183
6.11.3.5 Prescrizioni per la progettazione del software applicativo
6.11.3.5.1 Prima dell’inizio della progettazione dettagliata del software applicativo devono
essere disponibili le seguenti informazioni:
– specifica delle prescrizioni per la sicurezza del software;

– descrizione della progettazione dell’architettura del software, compresa l’identificazione della
logica applicativa e la funzionalità di tolleranza alle avarie, un elenco dei dati di uscita, moduli
generici del software e strumenti di supporto da utilizzare, nonché le procedure per la
configurazione del software applicativo con i materiali disponibili per offrire la funzionalità
applicativa per la I/O definita; e
– piano di validazione della sicurezza del software.
6.11.3.5.2 Il software applicativo deve essere prodotto in modo strutturato per ottenere:
– modularità della funzionalità applicativa e dei dati di controllo I/O;

– collaudabilità della funzionalità (comprese le caratteristiche di tolleranza all’avaria) e della
struttura interna;
– capacità di modifica in condizioni di sicurezza attraverso un’adeguata tracciabilità e
spiegazione delle funzioni applicative e dei vincoli associati.
6.11.3.5.3 L’affinamento della progettazione per ogni componente/sottosistema principale

nella descrizione del progetto dell’architettura del software applicativo (vedere 6.11.3.5.1),
deve basarsi su:
– funzioni utilizzate in modo ricorrente in tutto il progetto;

– mappatura delle informazioni di ingresso/uscita dei moduli del software applicativo;
– realizzazione delle funzioni applicative partendo dalle funzioni generiche del software e
dalla mappatura di I/O.
6.11.3.5.4 Deve essere specificata la progettazione di ogni modulo del software applicativo
e delle relative prove strutturali da applicare.
6.11.3.5.5 Devono essere specificate idonee prove del software e di integrazione dello
SRECS per accertarsi che il programma applicativo soddisfi le prescrizioni specificate per la
sicurezza del software applicativo. Deve essere considerato quanto segue:
– divisione del software applicativo in gruppi gestibili di integrazione;

– casi di prova;
– tipi di prove da eseguire;
– ambiente di prova, strumenti, configurazioni e programmi;
– criteri di prova in base ai quali viene valutato il completamento delle stesse; e
– procedure per azioni correttive in caso di mancato superamento delle prove.
6.11.3.6 Prescrizioni per lo sviluppo del codice applicativo
6.11.3.6.1 Il software applicativo deve:
– essere leggibile, comprensibile e collaudabile;

– rispettare i principi progettuali relativi;
– rispettare le relative prescrizioni specificate durante la pianificazione della sicurezza.
6.11.3.6.2 Il software applicativo deve essere riesaminato per garantire la conformità al

progetto specificato, alle regole di codifica e alle prescrizioni della pianificazione della
sicurezza.
NOTA Il riesame del software applicativo comprende tecniche quali: ispezioni o spiegazioni esaurienti, analisi del
codice o prove matematiche. Tali tecniche dovrebbero essere utilizzate associate a collaudi e/o simulazioni
per assicurare che il software applicativo rispetti le specifiche associate.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 98 di 183
6.11.3.7 Prescrizioni per il collaudo dei moduli applicativi
NOTA Il collaudo del rispetto corretto delle specifiche di prova da parte del software applicativo è un’attività di
verifica. Si tratta della combinazione dell’esame del codice e del collaudo strutturale per assicurare che il
software applicativo rispetti le specifiche associate, cioè sia verificato.
6.11.3.7.1 La configurazione di ogni punto di ingresso e di uscita deve essere verificata

mediante riesame, collaudo o simulazione per confermare che i dati I/O siano mappati alla
logica applicativa corretta.
6.11.3.7.2 Ogni modulo software deve essere verificato attraverso un processo di riesame,
collaudo e simulazione per determinare la corretta esecuzione della funzione prevista e la
mancata esecuzione delle funzioni non previste.
6.11.3.7.3 Le prove devono essere idonee al modulo collaudato e devono:
– assicurare l’esercizio di ogni ramo di ogni modulo del software applicativo;

– assicurare l’esercizio dei dati limite;
– assicurare la corretta realizzazione delle sequenze, comprese le relative condizioni di
sincronizzazione.
6.11.3.7.4 I risultati delle prove del modulo del software applicativo devono essere documentati.
6.11.3.7.5 Quando il software è già stato valutato, o quando è disponibile una mole notevole
di esperienze positive di funzionamento, l’estensione delle prove può essere ridotta.
6.11.3.8 Prescrizioni per la prova dell’integrazione del software applicativo

NOTA Il collaudo dell’integrazione corretta del software è un’attività di verifica.
6.11.3.8.1 I collaudi del software applicativo devono verificare che tutti i suoi moduli e i
componenti/sottosistemi interagiscano correttamente tra loro e con il software incorporato
sottostante per eseguire la funzione prevista, e non eseguano funzioni impreviste suscettibili
di compromettere qualsiasi funzione di sicurezza.
6.11.3.8.2 Il risultato delle prove di integrazione del software applicativo deve essere
documentato e dichiarare:
– i risultati delle prove; e

– l’eventuale raggiungimento degli obiettivi dei criteri di prova.
6.11.3.8.3 In caso di guasto, i motivi dello stesso e le azioni correttive intraprese devono
essere incluse nella documentazione dei risultati di prova.
6.11.3.8.4 Durante l’integrazione del software applicativo, qualsiasi modifica o variazione al

software deve essere sottoposta a un’analisi dell’impatto della sicurezza, che determini:
– tutti i moduli del software interessati; e

– tutte le attività di riverifica e riprogettazione necessarie.
6.12 Integrazione e collaudo del sistema elettrico di controllo relativo alla sicurezza
NOTA L’integrazione dello SRECS si svolge generalmente prima dell’installazione ma, in alcuni casi,
l’integrazione dello SRECS non può aver luogo se non dopo l’installazione (per esempio, quando lo
sviluppo del software applicativo non è finalizzato fino a dopo l’installazione).
6.12.1 Prescrizioni generali
6.12.1.1 Lo SRECS deve essere integrato in base al progetto specifico. Lo SRECS deve
essere collaudato in base alle prove specifiche di integrazione nell’ambito dell’integrazione di tutti
i sottosistemi e dei loro elementi. Tali prove devono verificare che tutti i moduli interagiscano
correttamente per eseguire la funzione prevista e non eseguano funzioni impreviste.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 100 di 183
6.12.1.2 L’integrazione del software applicativo relativo alla sicurezza dello SRECS deve
comprendere prove specificate in fase di progettazione e sviluppo per garantire la compatibilità del
software applicativo con l’hardware e con la piattaforma del software incorporato in modo da
rispettare le prescrizioni prestazionali, funzionali e di sicurezza.
NOTA 1 Questo non implica il collaudo di tutte le combinazioni di ingresso. La prova di tutte le classi di
equivalenza (vedere B.5 e C.5.7 della IEC 61508-7) può essere sufficiente. L’analisi statica, l’analisi
dinamica o l’analisi dei guasti possono ridurre il numero dei casi di prova a un livello accettabile. L’uso di
una progettazione strutturata o di metodi semiformali può facilitare il collaudo e la verifica.
NOTA 2 L’uso di una progettazione strutturata o di metodi semiformali può consentire una riduzione della
profondità e del numero dei casi di prova.
NOTA 3 Possono anche essere utilizzati riscontri statistici per consentire una riduzione della profondità e del
numero dei casi di prova.
6.12.1.3 Deve essere prodotta una documentazione idonea dei collaudi di integrazione dello SRECS
che indichi i risultati delle prove e l’eventuale raggiungimento degli obiettivi e dei criteri specificati durante la
fase progettuale e di sviluppo. In caso di guasto, il motivo deve essere documentato, devono essere
intraprese azioni correttive ed eseguito un nuovo collaudo.
6.12.1.4 Durante l’integrazione e il collaudo qualsiasi modifica o variazione allo SRECS

deve essere sottoposta a un’analisi di impatto che identifichi tutti i componenti interessati e le
verifiche supplementari.
6.12.1.5 Durante le prove di integrazione degli SRECS, deve essere documentato quanto segue:
a) la versione della specifica di prova utilizzata;

b) i criteri di accettazione delle prove di integrazione;
c) la versione dello SRECS in prova;
d) gli strumenti e l’apparecchiatura utilizzati, nonché i dati di taratura;

e) i risultati di ogni prova;
f) qualsiasi discrepanza tra i risultati previsti ed effettivi;
g) le analisi condotte e le decisioni intraprese sulla prosecuzione delle prove o sull’emissione di
una richiesta di variazione in caso di discrepanze.
6.12.2 Prove per la determinazione dell’integrità sistematica della sicurezza durante

l’integrazione dello SRECS
6.12.2.1 Devono essere condotte prove per rivelare avarie ed evitare guasti durante
l’integrazione del software applicativo e dell’hardware. Durante le prove devono essere svolti
riesami per vedere se le caratteristiche specificate dello SRECS sono state raggiunte.
6.12.2.2 Devono essere eseguite le seguenti prove:
a) prove funzionali, dove i dati che caratterizzano adeguatamente l’operazione sono applicati
allo SRECS. Gli esiti devono essere osservati, e la loro risposta confrontata con quella fornita
dalla specifica. Devono essere documentate le deviazioni dalla specifica e le indicazioni di
una specifica incompleta; e
b) prove dinamiche per verificare il comportamento dinamico in condizioni funzionali realistiche, e per
rivelare il mancato rispetto della specifica funzionale dello SRECS, nonché per valutare l’utilità e la
robustezza dello SRECS.
NOTA Le funzioni di un sistema o di un programma sono eseguite in un ambiente specifico, con dati di prova specifici
derivati sistematicamente dalla SRS dello SRECS secondo criteri consolidati. Questo evidenzia il comportamento
dello SRECS e consente un confronto con la specifica. Lo scopo è la determinazione dell’eventuale corretta
esecuzione di tutte le funzioni richieste dalla specifica da parte dello SRECS e/o dei suoi sottosistemi. La tecnica di
formare classi di equivalenza è un esempio dei criteri per i dati di prova delle scatole nere. Lo spazio dei dati in
ingresso viene suddiviso in campi specifici di valori di ingresso (classi di equivalenza), con l’aiuto della specifica. I
casi di prova si costituiscono successivamente partendo da:
– dati dei campi ammissibili;
– dati dei campi inammissibili;
– dati dei limiti del campo;
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 102 di 183
– valori estremi; e
– combinazioni delle classi precedenti.
Altri criteri possono essere efficaci nella scelta dei casi di prova durante le varie attività di prova (prove modulari,
prove di integrazione e prove di sistema).
6.13 Installazione dello SRECS
6.13.1 Scopo
Gli scopi delle prescrizioni del presente paragrafo si riferiscono all’installazione di uno
SRECS per assicurare che sia idoneo all’uso previsto e pronto alla validazione.
6.13.2 Prescrizioni
6.13.2.1 Uno SRECS deve essere installato in conformità al piano della sicurezza funzionale
per la validazione finale del sistema (vedere punto h) di 4.2.1).
6.13.2.2 Devono essere prodotte registrazioni appropriate dell’installazione dello SRECS

indicanti qualsiasi risultato di prova. In caso di mancato superamento devono essere registrati
i motivi.
7 Informazioni sull’uso dello SRECS
7.1 Scopo
Devono essere fornite informazioni sullo SRECS per consentire all’utilizzatore lo sviluppo di
procedure per garantire il mantenimento della sicurezza funzionale prescritta dello SRECS
durante l’uso e la manutenzione della macchina.
7.2 Documentazione per l’installazione, l’uso e la manutenzione
NOTA 1 Vedere anche l’Articolo 6 della ISO 12100-2 che fornisce informazioni generali da considerare durante la
stesura dei documenti di accompagnamento.
NOTA 2 Una o più voci della documentazione descritta nel presente paragrafo può essere stata sviluppata per
rispettare altri aspetti della presente Norma.
La documentazione deve fornire informazioni per l’installazione, l’uso e la manutenzione dello

SRECS. Queste devono comprendere:
a) descrizione esauriente dell’apparecchiatura, dell’installazione e del montaggio;

b) dichiarazione dell’uso previsto dello SRECS e di qualsiasi misura eventualmente
necessaria a impedirne l’uso improprio ragionevolmente prevedibile;
c) informazioni sull’ambiente fisico (es., illuminazione, vibrazioni, livelli di rumore,
contaminazioni atmosferiche), ove appropriato;
d) schema(i) a blocchi globale(i), ove appropriato;
e) schema(i) dei circuiti;
f) intervallo della prova di tenuta o ciclo di vita;
g) descrizione (compresi gli schemi di interconnessione) dell’interazione (eventuale) tra le
funzioni dello SRECS e le funzioni del sistema elettrico di controllo della macchina;
h) descrizione delle misure necessarie a garantire la separazione delle funzioni dello SRECS
e delle funzioni del sistema elettrico di controllo della macchina;
i) descrizione delle salvaguardie e dei mezzi forniti per mantenere la sicurezza ove sia
necessario sospendere la SRCF (es., programmazione manuale, verifica del programma);
j) informazioni sulla programmazione, ove rilevanti;
k) descrizione delle prescrizioni di manutenzione applicabili allo SRECS tra cui:
1) un diario per la registrazione dello storico della manutenzione della macchina;
2) le azioni di routine che devono essere svolte per mantenere la sicurezza funzionale dello SRECS,
tra cui la sostituzione di routine di componenti con ciclo di vita predefinito;
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 104 di 183
3) procedure di manutenzione da seguire in caso di avarie o guasti allo SRECS, tra cui:
procedure per la diagnosi e la riparazione di avarie;
procedure di conferma del funzionamento corretto in seguito a riparazioni;
prescrizioni di registrazione della manutenzione;
4) strumenti necessari per la manutenzione e la rimessa in servizio, nonché procedure
per la manutenzione degli strumenti delle apparecchiature;
5) specifica per le prove periodiche, la manutenzione preventiva e correttiva.
NOTA 3 Le prove periodiche sono le prove funzionali necessarie a confermare il funzionamento corretto e
rilevare guasti.
NOTA 4 La manutenzione preventiva è costituita dalle misure intraprese per mantenere la prestazione
prescritta dello SRECS.
NOTA 5 La manutenzione correttiva comprende le misure intraprese dopo il verificarsi di specifiche avarie,
per riportare lo SRECS alle condizioni di progetto.
8 Validazione del sistema elettrico di controllo relativo alla sicurezza

NOTA La validazione dello SRECS può costituire parte delle attività di validazione applicate alla progettazione
globale della macchina.
8.1 Finalità
Il presente Articolo specifica le prescrizioni per il processo di validazione da applicare allo

SRECS. Questo comprende l’ispezione e il collaudo degli SRECS per accertare che
raggiunga le prescrizioni indicate nella specifica per la sicurezza.
8.2 Prescrizioni generali

8.2.1 La validazione dello SRECS deve essere condotta in conformità a un piano preparato
(vedere 4.2).
NOTA 1 In alcuni casi, la validazione di sicurezza non può essere completata fino a dopo l’installazione (per
esempio, quando lo sviluppo del software applicativo non è finalizzato fino a dopo l’installazione).
NOTA 2 La validazione di uno SRECS programmabile comprende la validazione sia dell’hardware che del
software. Le prescrizioni per la validazione del software sono contenute in 6.11.3.
8.2.2 Ogni SRCF indicata nella specifica delle prescrizioni dello SRECS (vedere 5.2) e tutte
le procedure di funzionamento e di manutenzione dello SRECS devono essere validate
mediante collaudi e/o analisi.
8.2.3 Deve essere prodotta una documentazione adeguata della validazione della sicurezza
dello SRECS, che deve dichiarare per ogni SRCF:
a) la versione del piano di validazione di sicurezza dello SRECS utilizzato e la versione dello
SRECS provato;
b) la SRCF in prova (o in analisi), nonché il riferimento specifico alla prescrizione specificata
durante la pianificazione della validazione di sicurezza dello SRECS;
c) strumenti e apparecchiature utilizzate e dati di taratura;
d) risultati di ogni prova;
e) discrepanze tra risultati previsti ed effettivi.
8.2.4 Quando si verificano discrepanze, devono essere eseguite, ove necessario, e

documentate azioni correttive e nuovi collaudi.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 106 di 183
8.3 Validazione dell’integrità della sicurezza sistematica dello SRECS
8.3.1 Deve essere applicato quanto segue:
a) devono essere condotte prove funzionali per rivelare guasti durante le fasi di specifica, di
progettazione e di integrazione e per evitare guasti durante la validazione del software e
dell’hardware dello SRECS. Questo deve comprendere la verifica (mediante ispezioni o
prove) per valutare se lo SRECS è protetto da influenze ambientali avverse, e deve
essere basato sulla specifica delle prescrizioni di sicurezza;
b) prove di immunità all’interferenza per garantire che lo SRECS sia in grado di rispettare
5.2.3. Le prove di immunità all’interferenza elettromagnetica non devono necessariamente
svolgersi su sottosistemi dello SRECS o elementi di un sottosistema dove un’analisi può
dimostrare un’immunità adeguata dello SRECS per l’applicazione prevista;
NOTA 2 Ove praticabile lo SRECS dovrebbe essere caricato con un applicativo tipico, e tutte le linee
periferiche (tutte le connessioni, digitali, analogiche e le interfacce seriali, nonché le connessioni al
bus e all’alimentazione, ecc.) devono essere soggette a segnali normalizzati di rumore. Per ottenere
una dichiarazione quantitativa è buona norma avvicinarsi a qualsiasi limite con cautela.
c) le prove di inserzione di avaria (prove di guasto) devono essere effettuate ove la frazione
di guasti in sicurezza sia 90 %. Tali prove devono introdurre o simulare avarie
all’hardware dello SRECS e la risposta deve essere documentata.
8.3.2 Inoltre, devono essere applicati uno o più dei gruppi seguenti di tecniche analitiche
considerando la complessità dello SRECS e il SIL assegnato:
a) analisi statica e di guasto;

NOTA 1 Tale combinazione di tecniche analitiche è considerata idonea solo per SRECS che realizzano
SRCF con un SIL assegnato non superiore a SIL 2.
NOTA 2 Ulteriori informazioni sono disponibili in B.6.4 e B.6.6 della IEC 61508-7.
b) analisi statica, dinamica e di guasto;

NOTA 3 Tale combinazione di tecniche analitiche non è raccomandata per SRECS che realizzano SRCF con
un SIL assegnato inferiore a SIL 2.
NOTA 4 Ulteriori informazioni sono disponibili in B.6.4, B.6.5 e B.6.6 della IEC 61508-7.
c) simulazione e analisi dei guasti.

NOTA 5 Tale combinazione di tecniche analitiche è considerata idonea solo per SRECS che realizzano
SRCF con un SIL assegnato non superiore a SIL 2.
NOTA 6 Ulteriori informazioni sono disponibili in B.3.6 e B.6.6 della IEC 61508-7.
8.3.3 Inoltre, devono essere applicati uno o più dei seguenti gruppi di tecniche di prova
considerando la complessità dello SRECS e il SIL assegnato:
a) prove su scatole nere: una o più prove del comportamento dinamico in condizioni
funzionali reali per rivelare il mancato rispetto delle specifiche funzionali dello SRECS e
per valutare l’utilità e la robustezza dello stesso;
b) prove di inserzione di avaria (prove di guasto): devono essere condotte ove la frazione di
guasti in sicurezza sia < 90 %. Tali prove devono introdurre o simulare avarie all’hardware
dello SRECS, e i risultati devono essere documentati;
c) prove “del caso peggiore”: devono essere eseguite per valutare i casi estremi (cioè
peggiori) specificati dall’applicazione delle tecniche analitiche (vedere 8.3.2);
NOTA 2 La capacità operativa dello SRECS e del dimensionamento dei suoi componenti è provata nelle
condizioni del caso peggiore. Le condizioni ambientali sono modificate fino a raggiungere i massimi valori
marginali ammissibili. Le risposte più essenziali dello SRECS sono verificate e confrontate con la specifica
delle prescrizioni per la sicurezza.
d) esperienza in campo: uso di esperienza in campo di applicazioni diverse, come misura per
evitare avarie durante la validazione dello SRECS.
NOTA 3 Vedere anche 6.12.2.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 108 di 183
9 Modifiche
6.1 Finalità
Il presente Articolo specifica le procedure di modifica applicabili durante la modifica di

SRECS in fase di progettazione, integrazione e validazione (es., durante l’installazione e la
messa in servizio dello SRECS).
9.2 Procedura di modifica
9.2.1 La richiesta della modifica di uno SRECS può derivare, per esempio:
– da variazioni nella specifica delle prescrizioni di sicurezza;

– da condizioni effettive d’uso;
– da esperienza di incidenti/infortuni;
– da variazioni nel materiale lavorato;
– da modifiche della macchina o delle sue modalità operative.
NOTA Gli interventi (es., regolazioni, impostazioni, riparazioni) allo SRECS, svolti in conformità alle informazioni
d’uso o al manuale di istruzioni dello SRECS, non sono considerati una modifica nel contesto del presente
Articolo.
9.2.2 I motivi per la richiesta di una modifica dello SRECS devono essere documentati.
9.2.3 L’effetto della modifica richiesta deve essere analizzato per stabilirne l’effetto sulla
sicurezza funzionale dello SRECS.
9.2.4 L’analisi di impatto della modifica e l’effetto sulla sicurezza funzionale dello SRECS
devono essere documentati.
9.2.5 Tutte le modifiche accettate con effetto sullo SRECS devono avviare un ritorno alla
fase di progettazione appropriata dell’hardware e/o del software (es., specifica, progettazione, integrazione,
installazione, messa in servizio e validazione). Tutte le fasi successive devono quindi essere svolte in
conformità alle procedure specificate per le fasi specifiche della presente Norma. Tutti i documenti relativi
devono essere revisionati, emendati e riemessi in conseguenza.
9.2.6 Sulla base di tali documenti revisionati deve essere preparato e documentato un piano
d’azione completo prima dello svolgimento di qualsiasi modifica.
9.3 Procedure di gestione della configurazione
9.3.1 Le procedure di gestione della configurazione devono essere realizzate in conformità

al piano della sicurezza funzionale (vedere 4.2.1) considerando quanto segue:
a) piano di ogni processo di modifica;

b) documentazione del processo decisionale e di ogni decisione relativa allo SRECS;
c) documentazione cronologica (es., diario) delle procedure di richiesta di variazione, compresi:
x rischi individuati suscettibili di essere interessati;
x descrizione della richiesta di modifica (hardware e/o software);
x motivi per la richiesta di modifica (vedere anche 9.2.1);
x decisione raggiunta (e autorizzazione per ogni decisione);
x analisi dell’impatto;
x riverifica (di ogni fase) e rivalidazione;
x tutti i documenti interessati dalle attività di richiesta di modifica;
x tutte le attività svolte durante il processo di modifica e le persone/enti responsabili per
le stesse;
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 110 di 183
d) documentazione delle seguenti informazioni per consentire una successiva ispezione:
x stato della configurazione;
x stato della versione;
x giustificazione e approvazione di tutte le modifiche;
x dettagli della modifica.
9.3.2 Le procedure per un adeguato processo di controllo delle modifiche dovrebbero

considerare le prescrizioni di
a) procedure per la definizione di un’unica linea di base di ogni versione dello SRECS;
b) definizione di tutte le voci di configurazione di una linea di base, comprendenti almeno:
1) analisi e specifica delle prescrizioni di sicurezza;
2) documenti progettuali relativi;
3) moduli hardware e/o software;
4) piani e risultati delle prove;
5) rapporti di verifica e di validazione;
6) componenti di software preesistenti da incorporare nello SRECS;
7) strumenti e ambienti di sviluppo utilizzati per la creazione e le prove;
8) manutenzione precisa con identificazione univoca di tutte le voci di configurazione
necessarie al mantenimento dell’integrità dello SRECS;
9) cambiamento delle procedure di controllo allo scopo di:
x evitare modifiche non autorizzate,

x documentare le richieste di variazione,
x analizzare l’impatto di una richiesta di variazione proposta e approvare o rifiutare
tale richiesta,
x documentare i dettagli e l’autorizzazione di tutte le modifiche approvate,
x fissare una linea di base di configurazione in punti appropriati dello sviluppo
dell’hardware o del software, e documentare le prove di integrazione (parziali) che
giustificano la linea di base,
x garantire la composizione e la costruzione di tutte le linee di base hardware o
software (compresa la ricostruzione di linee di base precedenti);
10) analisi degli effetti allo scopo di valutare l’impatto di ogni richiesta di variazione. Tale
analisi dovrebbe anche comprendere un’adeguata analisi dei rischi e tener conto di
tutte le attività di modifica di uno SRECS;
11) ritorno alla fase di progettazione appropriata dell’hardware e/o del software (es.,
specifica, progettazione, integrazione, installazione, messa in servizio e validazione)
dello SRECS per tutte le modifiche accettate con impatto su di esso. Tutte le fasi
successive dovranno quindi essere svolte in conformità alla presente Norma;
12) svolgimento di tutte le operazioni necessarie a dimostrare il raggiungimento
dell’integrità della sicurezza richiesta;
13) autorizzazione a condurre le attività di richiesta di modifica prescritte in funzione dei
risultati dell’analisi di impatto.
9.3.3 La documentazione del processo di controllo delle modifiche deve contenere almeno:
a) un piano di ogni processo di modifica;

b) una documentazione di ognuna delle prescrizioni e delle procedure organizzative
summenzionate;
c) una documentazione del processo decisionale e di ogni decisione presa relativa allo SRECS;
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 112 di 183
d) una documentazione cronologica (diario) delle procedure di richiesta di variazione,
compresi:
x rischi individuati suscettibili di essere interessati;
x descrizione della richiesta di modifica (hardware e/o software);
x motivi per la richiesta di modifica (vedere anche 9.2.1);
x decisione raggiunta (e autorizzazione per ogni decisione);
x analisi dell’impatto;
x riverifica (di ogni fase) e rivalidazione;
x tutti i documenti interessati dalle attività di richiesta di modifica;
x tutte le attività svolte durante il processo di modifica e le persone/enti responsabili per
le stesse;
e) documentazione delle seguenti informazioni per consentire una successiva ispezione:
x stato della configurazione;
x stato della versione;
x giustificazione e approvazione di tutte le modifiche;
x dettagli della modifica.
10 Documentazione
10.1 La documentazione deve essere:

– precisa e concisa;
– di facile comprensione dalle persone destinate a utilizzarla;
– idonea allo scopo a cui è destinata;
– accessibile e mantenibile.
10.2 Il progettista dello SRECS dovrebbe distinguere la documentazione relativa all’utilizzatore da

quella relativa alla progettazione e costruzione dello stesso.
10.3 I documenti devono avere titoli o nomi che indichino il campo di applicazione del
contenuto.
10.4 I documenti devono avere un indice di revisione (numeri di versione) per consentire
l’identificazione delle varie versioni del documento.
NOTA Vedere anche la IEC 82045-1: 2001 per ulteriori informazioni sui metodi utilizzabili per la gestione della
documentazione.
10.5 La Tab. 8 riassume le informazioni e la documentazione che deve essere resa

disponibile a seconda dei casi.
Tabella 8 – Informazioni e documentazione di uno SRECS
Informazione richiesta Paragrafo

Piano di sicurezza funzionale 4.2.1
Specifica delle prescrizioni per le SRCF 5.2
Specifica delle prescrizioni di sicurezza funzionali per le SRCF 5.2.3
Specifica delle prescrizioni di integrità della sicurezza per le SRCF 5.2.4
Progettazione dello SRECS 6.2.5
Processo di progettazione strutturata 6.6.1.2
Documentazione di progettazione dello SRECS 6.6.1.8
Struttura dei blocchi funzionali 6.6.2.1.1
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 114 di 183
Informazione richiesta Paragrafo
Architettura dello SRECS 6.6.2.1.5
Specifica delle prescrizioni di sicurezza del sottosistema 6.6.2.1.7
Realizzazione del sottosistema 6.7.2.2
Architettura del sottosistema (elementi e loro interrelazioni) 6.7.4.3.1.2
Esclusione delle avarie dichiarata alla stima della tolleranza 6.7.6.1c)/6.7.7.
all’avaria/SFF 3
Assemblaggio del sottosistema 6.7.10
Specifica delle prescrizioni di sicurezza del software 6.10.1
Parametrizzazione basata sul software 6.11.2.4
Punti per la gestione della configurazione del software 6.11.3.2.2
Idoneità degli strumenti di sviluppo del software 6.11.3.4.1
Documentazione del programma applicativo 6.11.3.4.5
Risultati delle prove del modulo del software applicativo 6.11.3.7.4
Risultati delle prove di integrazione del software applicativo 6.11.3.8.2
Documentazione delle prove di integrazione dello SRECS 6.12.1.3
Documentazione dell’installazione dello SRECS 6.13.2.2
Documentazione per l’installazione, l’uso e la manutenzione 7.2
Documentazione delle prove di validazione dello SRECS 8.2.4
Documentazione della gestione della configurazione dello SRECS 9.3.1
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 116 di 183
Allegato A
(informativo)
Assegnazione del SIL
A.1 Generalità
Il presente Allegato informativo offre un esempio di approccio qualitativo per la stima dei
rischi e l’assegnazione del SIL applicabile alle SRCF per la macchina. Esempi di altre
tecniche utilizzabili per l’assegnazione del SIL sono contenuti nella IEC 61508-5, e verranno
delineati in una futura Specifica Tecnica proposta dal TC 44 della IEC.
NOTA 1 La metodologia descritta nel presente Allegato utilizza una stima qualitativa dei rischi, ed è destinata ad
essere applicata generalmente per l’assegnazione di SIL alle SRCF delle macchine. I parametri di
rischio (vedere Fig. A.2) utilizzati nell’applicazione di tale metodologia a macchine particolari e ai loro
rischi specifici dovrebbero essere soggetti ad accordo con le parti interessate per accertare che lo
SRECS possa fornire una riduzione adeguata del rischio.
NOTA 2 In un gran numero di norme specifiche per le macchine (norme di tipo “C” del CEN) la stima del rischio è
stata svolta per scegliere una categoria in conformità alla ISO 13849-1:1999, per le parti relative alla
sicurezza di sistemi di controllo di macchine. Si noti che, per semplicità, vengono comunemente
utilizzate le seguenti relazioni: richiesta Categoria 1 per SIL richiesto 1, richiesta Categoria 2 per SIL
richiesto 1, richiesta Categoria 3 per SIL richiesto 2, richiesta Categoria 4 per SIL richiesto 3. Sono allo
studio Metodi più esaurienti di mappatura tra le Categorie richieste della ISO 13849-1:1999 e i SIL
richiesti utilizzati nella presente Norma Internazionale.
Per ogni rischio specifico, le prescrizioni di integrità della sicurezza dovrebbero essere
determinate separatamente per le funzioni di controllo relative alla sicurezza da eseguire
dallo SRECS (vedere 5.2.4.2).
La Fig. A.1 è un esempio di modalità pratica di svolgere una valutazione dei rischi per un
pericolo particolare che porta alla stima della prescrizione di un SIL per una funzione SRECS.
Tale metodologia dovrebbe essere seguita per ogni rischio che deve essere ridotto da una
funzione di controllo relativa alla sicurezza, da realizzarsi da parte di uno SRECS. La Fig. A.1
dovrebbe essere utilizzata in associazione con le informazioni del presente Allegato.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 118 di 183
Valutazione
del rischio
Riduzione No
Nessuna stima
del rischio
del SIL
mediante
SRCF?
Si
Campo di applicazione
del presente Allegato
Stima del
rischio per
l’assegnazione del
SIL
Variazione dei
fattori causata
Si
dalla SRCF?
No
Assegnazione
del SIL alla

SRCF
Figura A.1 – Schema di flusso del processo di assegnazione di un SIL
La stima del rischio è un processo iterativo, che significa che il processo deve essere ripetuto
più volte.
La Fig. A.1 indica una freccia di retroazione alla stima dei rischi. Essa è necessaria poiché la
prescrizione di una misura protettiva specifica per realizzare una SRCF può avere un impatto
sui parametri di rischio (es., l’uso di una barriera optoelettronica può portare a una maggiore
frequenza di accesso). Un guasto alla barriera optoelettronica può quindi esporre l’operatore
a un rischio superiore a quello originariamente considerato. Questo richiede una ripetizione
del processo seguendo lo stesso metodo ma con il(i) parametro(i) di rischio modificato(i).
Alla fine del processo indicato in Fig. A.1, il SIL stimato è il SIL prescritto per la funzione di
controllo relativa alla sicurezza.
A.2 Stima del rischio e assegnazione del SIL
A.2.1 Individuazione/indicazione del pericolo
Indicare i pericoli, compresi quelli derivanti da un ragionevole e prevedibile uso improprio, di

cui si devono ridurre i rischi realizzando una SRCF. Elencarli nella colonna pericoli della
Tab. A.5.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 120 di 183
A.2.2 Stima del rischio
La stima del rischio dovrebbe essere condotta per ogni pericolo, determinando i parametri di
rischio che, come indicato in Fig. A.2, dovrebbero essere derivati da quanto segue:
– gravità del danno Se; e

– probabilità di occorrenza di tale danno, che è una funzione della:
x frequenza e durata dell’esposizione di persone al pericolo, Fr;
x probabilità di occorrenza di un evento pericoloso Pr; e
x possibilità di evitare o limitare il danno, Av.
A.2.3 Frequenza e durata A.2.4.1

dell’esposizione A.2.4
Rischio Gravità del Fr
relativo al Probabilità di
danno Probabilità di occorrenza A.2.4.2
occorrenza di
pericolo = possibile
e
di un evento pericoloso
individuato Pr tale danno
Se
Probabilità di evitare o A.2.4.3
limitare il danno Av
Figura A.2 – Parametri utilizzati per la stima del rischio
Le stime inserite nella Tab. A.5 dovrebbero generalmente basarsi sulle considerazioni del
caso peggiore per la SRCF. Tuttavia, in una situazione nella quale, per esempio, è possibile
una lesione irreversibile ma con una probabilità notevolmente inferiore di una reversibile, ogni
livello di gravità dovrebbe essere inserito in una riga separata della Tabella. Può trattarsi del
caso di una SRCF diversa realizzata per ogni riga. Se viene realizzata una SRCF
comprendente entrambe le righe, dovrebbe essere utilizzata la prescrizione per il SIL più
elevato.
A.2.3 Gravità (Se)
La gravità delle lesioni o dei danni alla salute può essere stimata considerando lesioni
reversibili, lesioni irreversibili e decessi. Scegliere un valore appropriato di gravità dalla
Tab. A.1 sulla base delle conseguenze di una lesione, dove:
4 indica una lesione fatale o significativa irreversibile, tale da rendere molto difficile
continuare lo stesso lavoro dopo la guarigione, ammesso che sia possibile;
3 indica una lesione importante o irreversibile tale da rendere possibile continuare lo stesso
lavoro dopo la guarigione. Può inoltre includere una lesione importante grave ma
reversibile, quale la rottura di un arto;
2 indica una lesione reversibile, comprese gravi lacerazioni, ferite da taglio e gravi
escoriazioni che richiedono l’intervento di un medico;
1 indica una lesione minore, compresi graffi e lacerazioni minori che richiedono le cure di un
pronto soccorso.
Scegliere la riga adeguata per le conseguenze (Se) della Tab. A.1. Inserire il numero relativo
nella colonna Se della Tab. A.5.
Tabella A.1 – Classificazione della gravità (Se)
Conseguenze Gravità (Se)

Irreversibile: morte, perdita di un occhio o di un braccio 4
Irreversibile: rottura di uno o più arti, perdita di uno o più dita 3
Reversibile: richiede l’intervento di un medico 2
Reversibile: richiede le cure di un pronto soccorso 1
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 122 di 183
A.2.4 Probabilità del verificarsi di un danno
Ognuno dei tre parametri della probabilità del verificarsi di un danno (cioè: Fr, Pr e Av)
dovrebbe essere stimato indipendentemente dagli altri. Deve essere utilizzata un’ipotesi del
caso peggiore per ogni parametro per accertarsi che alle SRCF non sia erroneamente
assegnato un SIL inferiore a quello necessario. In genere, l’uso di un modulo di analisi basato
sui compiti è fortemente raccomandato per garantire che venga data adeguata considerazione
alla stima della probabilità che si verifichi un danno.
A.2.4.1 Frequenza e durata dell’esposizione
Considerare gli aspetti seguenti per determinare il livello dell’esposizione:
x necessità di accesso alla zona pericolosa sulla base di tutte le modalità d’uso, per
esempio, funzionamento normale, manutenzione, e
x natura dell’accesso, per esempio, alimentazione manuale di materiali, impostazioni.
Dovrebbe quindi essere possibile stimare l’intervallo medio tra le esposizioni e, di

conseguenza, la frequenza media di accesso.
Dovrebbe inoltre essere possibile prevedere la durata, per esempio, se maggiore di 10 min.
Quando la durata è inferiore a 10 min, il valore può essere ridotto al livello successivo. Questo
non si applica a frequenze di esposizione <= 1 h, che non dovrebbero mai essere ridotte.
NOTA La durata è relativa alla prestazione di attività svolte sotto la protezione della SRCF. Le prescrizioni della
IEC 60204-1 e della ISO 14118 relative all’isolamento energetico e alla dissipazione di energia,
dovrebbero essere applicate agli interventi più rilevanti.
Tale fattore non prende in considerazione il guasto della SRCF.
Scegliere la riga appropriata della frequenza e della durata dell’esposizione (Fr) della
Tab. A.2. Inserire il numero corrispondente nella colonna Fr della Tab. A.5.
Tabella A.2 – Classificazione della frequenza e durata dell’esposizione (Fr)
Frequenza e durata dell’esposizione (Fr)
Durata
Frequenza dell’esposizione
> 10 min
1h 5
Da > 1 h a 1 giorno 5
Da > 1 giorno a 2 settimane 4
Da > 2 settimane a 1 anno 3
> 1 anno 2
A.2.4.2 Probabilità del verificarsi di un evento pericoloso
La probabilità del verificarsi di un evento pericoloso dovrebbe essere stimata indipendentemente dagli altri
parametri relativi, Fr e Av. Dovrebbe essere utilizzata un’ipotesi del caso peggiore per ogni parametro per
accertarsi che alle SRCF non sia erroneamente assegnato un SIL inferiore a quello necessario. Per evitare
questa circostanza, l’uso di un modulo di analisi basato sui compiti è fortemente raccomandato per
garantire che venga data adeguata considerazione alla stima della probabilità che si verifichi un danno.
Questo parametro può essere stimato considerando:
a) Prevedibilità del comportamento delle parti costitutive della macchina relative al pericolo
in diverse modalità d’uso (es., funzionamento normale, manutenzione, ricerca guasti).
Questo richiede un’attenta considerazione del sistema di controllo, soprattutto per quanto
riguarda il rischio di avvio inatteso. Non prendere in considerazione l’effetto protettivo di
qualsiasi SRECS. Questo è necessario per stimare l’entità del rischio a cui si viene esposti in
caso di guasto allo SRECS. In generale, bisogna considerare se la macchina o il materiale in
lavorazione tende ad agire in modo inaspettato.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 124 di 183
Il comportamento della macchina varia da molto prevedibile a imprevedibile, ma eventi
inattesi non possono essere esclusi.
NOTA 1 La prevedibilità è spesso legata alla complessità della funzione della macchina.
b) Le caratteristiche specificate o prevedibili del comportamento umano relative all’interazione con le parti
componenti della macchina relative al pericolo. Questo può essere caratterizzato da:
– sollecitazioni (es., dovute a vincoli temporali, compiti di lavoro, percezione della
limitazione del danno), e/o
– scarsa conoscenza delle informazioni relative al pericolo. Questo è influenzato da
fattori quali capacità, formazione, esperienza e complessità della macchina/processo.
Tali attributi non sono generalmente direttamente influenzati dal progettista dello SRECS,
ma un’analisi dei compiti può rivelare attività nelle quali la consapevolezza totale di tutti
gli aspetti, compresi gli esiti imprevisti, non può essere ragionevolmente presunta.
Dovrebbe essere scelta una probabilità “molto alta” del verificarsi di un evento pericoloso
per rispecchiare i vincoli normali alla produzione e le considerazioni del caso peggiore.
Sono richiesti motivi positivi (es., applicazioni ben definite e conoscenza di un elevato
livello di competenza degli utilizzatori) per utilizzare qualsiasi valore inferiore.
NOTA 2 Le informazioni d’uso dovrebbero indicare qualsiasi capacità, competenza, ecc., richiesta o presunta.
Scegliere la riga appropriata alla probabilità del verificarsi di un evento pericoloso (Pr) dalla
Tab. A.3. Inserire il numero corrispondente nella colonna Pr della Tab. A.5.
Tabella A.3 – Classificazione della probabilità (Pr)
Probabilità dell’evento pericoloso Probabilità (Pr)

Molto alta 5
Probabile 4
Possibile 3
Scarsa 2
Trascurabile 1
A.2.4.3 Probabilità di evitare o limitare il danno (Av)
Questo parametro può essere stimato tenendo conto degli aspetti dei progetti della macchina
e dell’applicazione prevista che possono contribuire a limitare o evitare il danno derivante da
un pericolo. Tali aspetti comprendono, per esempio:
– insorgenza improvvisa, ad alta o bassa velocità, dell’evento pericoloso;

– possibilità spaziale di sottrarsi al pericolo;
– natura del componente o del sistema, per esempio un coltello è generalmente affilato, un
tubo in una latteria è generalmente caldo, l’elettricità è generalmente pericolosa per sua
natura, ma invisibile; e
– possibilità di riconoscere un pericolo, per esempio un rischio elettrico: una sbarra di rame
non cambia aspetto se è in tensione o no; per accorgersene è necessario uno strumento
per stabilire se un’apparecchiatura elettrica è energizzata o no; le condizioni ambientali,
per esempio, elevati livelli di rumore, possono impedire a una persona di sentire
l’avviamento di una macchina.
Scegliere la riga appropriata alla probabilità di evitare o limitare il danno (Av) dalla Tab. A.4.
Inserire il numero corrispondente nella colonna Av della Tab. A.5.
Tabella A.4 – Classificazione della probabilità di evitare o limitare il danno (Av)
Probabilità di evitare o limitare il danno (Av)

Impossibile 5
Scarsa 3
Probabile 1
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 126 di 183
A.2.5 Classe della probabilità del danno (Cl)
Per ogni pericolo e, se applicabile, per ogni grado di gravità sommare i punteggi delle colonne
Fr, Pr e Av e inserire la somma nella colonna Cl della Tab. A.5.
Tabella A.5 – Parametri utilizzati per determinare la classe della probabilità del danno
(Cl)
N° di Pericolo Se Fr Pr Av Cl
serie
1
2
3
4
A.2.6 Assegnazione del SIL
Utilizzando la Tab. A.6, il punto di intersezione tra la riga della gravità (Se) e la relativa
colonna (Cl) indica se è necessaria un’azione. La zona nera indica il SIL assegnato come
obiettivo per la SRCF. Le zone di colore più chiaro dovrebbero essere utilizzate come
raccomandazione per l’uso di altre misure (OM).
Tabella A.6 – Matrice di assegnazione del SIL
Gravità (Se) Classe (Cl)

3-4 5-7 8-10 11-13 14-15
4 SIL 2 SIL 2 SIL 2 SIL 3 SIL 3

3 (OM) SIL 1 SIL 2 SIL 3
2 (OM) SIL 1 SIL 2
1 (OM) SIL 1
ESEMPIO: Per un pericolo specifico con una Se assegnata di 3, una Fr di 4, una Pr di 5 e

una Av di 5:
Cl = Fr + Pr + Av = 4 + 5 + 5 = 14
Utilizzando la Tab. A.6, questo porterebbe l’assegnazione di un SIL 3 alla SRCF destinata a
mitigare questo pericolo specifico.
La Fig. A.3 mostra un esempio di documentazione che può essere utilizzata per registrare i
risultati di un esercizio di assegnazione del SIL utilizzando il presente Allegato informativo.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 128 di 183
Documento numero:
Valutazione del rischio e misure di sicurezza Parte di:
Prodotto: Valutazione del rischio prima delle misure

Emesso da: Valutazione intermedia del rischio
Data: Aerea nera = Misure di sicurezza richieste Valutazione del rischio a posteriori
Area grigia = Misure di sicurezza raccomandate
Conseguenze Gravità Classe CI Frequenza e Probabilità del- Evitabilità
Se 3-4 5-7 8 - 10 11 - 13 14 - 15 durata Fr l'evento pericoloso Pr Av
Morte, perdita di un occhio o di un braccio 4 SIL 2 SIL 2 SIL 2 SIL 3 SIL 3 <=1 h 5 Molto alta 5
Permanente: perdita di dita 3 OM SIL 1 SIL 2 SIL 3 Da > 1 h a <= giorno 5 Probabile 4
Da >1 giorno a <= 2
Reversibile: intervento medico 2 OM SIL 1 SIL 2 settimane 4 Possibile 3 Impossibile 5
Da > 2 settimane a
Reversibile: pronto soccorso 1 Scarsa 2 Possibile 3
OM SIL 1 <= 1 anno 3
> 1 anno 2 Trascurabile 1 Probabile 1
Serie Pericolo Pericolo Se Fr Pr Av Cl Misura di sicurezza Sicuro

No. No.
Commenti

Pagina 130 di 183
CEI EN 60893-3-2:2004
NORMA TECNICA
Figura A.3 – Esempio proforma per il processo di assegnazione del SIL
Allegato B
(informativo)
Esempio di progettazione di sistemi elettrici di controllo relativi alla

sicurezza (SRECS) utilizzando concetti e prescrizioni degli Articoli 5 e 6
B.1 Generalità
L’approccio strutturato alla progettazione di uno SRECS utilizzato dalla presente Norma,
definisce una metodologia in base alla quale le prescrizioni funzionali e per l’integrità della
sicurezza delle funzioni di controllo relative alla sicurezza sono suddivise in una serie di
sottofunzioni. Questo processo è utilizzato per realizzare, nel settore dei macchinari, un
quadro tecnico per la sicurezza funzionale, e la Fig. B.1 descrive la terminologia utilizzata a
ognuno di tali livelli, che è importante quando si integra il progetto di uno SRECS
nell’installazione di una macchina.
Tale metodologia progettuale può essere utilizzata mediante processi di verifica e di

validazione per dimostrare che uno SRECS rispetta le specifiche per le prescrizioni di
sicurezza descritte nell’Articolo 5.
L’esempio seguente del progetto di uno SRECS è destinato a chiarire i principi della
scomposizione funzionale e la realizzazione di una funzione di controllo relativa alla sicurezza
specificata in conformità alla prescrizioni dell’Articolo 6. Di conseguenza questo esempio è
semplificato, e non tiene conto delle misure supplementari che possono essere necessarie
nella pratica, per esempio, dispositivi ad azione mantenuta.
Sottosistema (vedere 3.2.5)

SRECS (vedere 3.2.4)
INGRESSO
RISOLUZIONE USCITA
LOGICA
Elementi del sottosistema (vedere 3.2.6)
Figura B.1 – Terminologia utilizzata nella scomposizione funzionale
In genere, i termini indicati in Fig.a B.1 sono destinati a delineare il processo di progettazione
in due fasi fondamentali, cioè:
– progettazione dello SRECS che può essere svolta da un progettista di macchinari o da un

integratore di sistemi di controllo; e
– progettazione di sottosistemi (ed elementi dei sottosistemi) applicabile ai fornitori di apparecchiature
elettriche e di dispositivi di comando (es., contattori, interruttori interbloccati, controllori logici
programmabili) e ai progettisti di macchinari o agli integratori di sistemi di controllo.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 132 di 183
B.2 Esempio
Figura B.2 – Esempio di macchina
La metodologia utilizzata nella presente Norma si basa su un approccio strutturato dall’alto

verso il basso per la specifica delle funzioni di controllo relative alla sicurezza e la
progettazione dello SRECS che realizza tali funzioni.
Fase 1: Specifica delle prescrizioni di sicurezza della SRCF (Articolo 5)
Da una specifica delle prescrizioni di sicurezza di una SRCF si possono ricavare le

informazioni seguenti:
SRCF di esempio:
Specifica delle prescrizioni Se la porta di protezione è
per una SRCF aperta, la velocità di rotazione
dell’albero non deve essere
(funzione e integrità)
superiore a quella specificata.
Prescrizione di integrità della
sicurezza SIL 2
Figura B.3 – Specifica delle prescrizioni per una SRCF
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 134 di 183
Fase 2: Processo di progettazione e sviluppo di uno SRECS (vedere 6.6.2)
Fase 2.1: La funzione di controllo per la sicurezza indicata nella specifica delle prescrizioni di
sicurezza è suddivisa in una struttura di blocchi funzionali.
SRCF di esempio:
Specifica delle prescrizioni di Se la porta di protezione è aperta,
sicurezza per una SRCF la velocità di rotazione dell’albero
(funzione e integrità) non deve essere superiore a quella
specificata.
Prescrizione di integrità della
sicurezza.
SIL 2
Deve essere fornito un rilevamento

Proposta per un concetto di SRECS con le per la posizione della porta di
prescrizioni funzionali e di integrità protezione e per la velocità di
rotazione dell’albero. L’uscita del
(SIL 2) rilevamento deve essere elaborata
mediante la risoluzione logica, in
modo da avviare una disinserzione
del motore di azionamento, quando
la velocità dell’albero è troppo elevata
e la porta di protezione non è chiusa
all’avvio, l’alimentazione del motore è
Assegnare ai blocchi funzionali interrotta.
Figura B.4 – Scomposizione in una struttura di blocchi funzionali
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 136 di 183
Fase 2.2: La struttura dei blocchi funzionali offre un concetto iniziale per l’architettura di uno
SRECS. Le prescrizioni di sicurezza di ogni blocco funzionale derivano dalla specifica delle
prescrizioni di sicurezza della corrispondente funzione di controllo relativa alla sicurezza.
Gli elementi che realizzano ogni blocco funzionale devono raggiungere almeno la stessa
capacità di SIL assegnata alla SRCF. Questo è mostrato in Fig. B.5 come capacità SIL 2
(cioè: FB1 SILCL2, ecc.).
Funzioni e prescrizioni per l’integrità assegnate
I blocchi funzionali (FB)

Rilevamento rappresentano il livello
protezione più elevato di
FB1 SIL CL2 scomposizione di una
Risoluzione Interruzione funzione di controllo
logica alimentazione relativa alla sicurezza
FB3 SIL CL2 motore dove un guasto di un
FB4 SIL CL1 qualsiasi blocco
Rilevamento funzionale porta al
velocità guasto della funzione di
FB2 SILCL2 controllo relativa alla
RISOLUZIONE
LOGICA ATTUAZIONE sicurezza
INGRESSO
Assegnare le funzioni e le prescrizioni per l’integrità

Figura B.5 – Concetto iniziale dell’architettura di uno SRECS
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 138 di 183
Fase 3: Ogni blocco di funzione è assegnato a un sottosistema, all’interno dell’architettura
dello SRECS. Ogni sottosistema può essere costituito da elementi del sottosistema e, ove
necessario, da funzioni diagnostiche, per garantire che le avarie possano essere individuate e
possano essere intraprese le azioni appropriate (vedere 6.2).
L’architettura dovrebbe descrivere lo SRECS in termini di sottosistemi e loro interrelazioni.

Per questo esempio varie alternative possono essere utilizzate per la realizzazione dello
SRECS e per l’architettura dei suoi sottosistemi.
Esempio 1: In questo esempio (vedere Fig. B.6), le funzioni diagnostiche sono incorporate in
ogni sottosistema.

Sottosistemi (SS): Realizzano
Interruttore di blocchi funzionali e sono elementi al
interblocco SSE 1.1 livello più elevato del progetto di
architettura di uno SRECS, dove un
PLC guasto di qualsiasi sottosistema porta al
conforme guasto della funzione di controllo relativa
Interruttore di
alla sicurezza.
interblocco SSE 1.2 alla
IEC 61508 Elementi del Sottosistema (SSE):
Sono componenti che realizzano gli
Contattore elementi del blocco di funzione
SSE 4.1 assegnato al sottosistema.
Funzioni Diagnostiche (D): Sono
considerate come funzioni separate che
Contattore possono avere una struttura separata nei
SSE 4.2 confronti della funzione di controllo

Sensore di velocità
SSE 2.1 relativa alla sicurezza. Esse possono
essere realizzate:
x all’interno del sottosistema
Sensore di velocità x da un altro sottosistema nello
SSE 2.2 SRECS
x da un sottosistema esterno allo
SRECS
Figura B.6 – Architettura di uno SRECS con funzioni diagnostiche incorporate

all’interno di ogni sottosistema (da SS1 a SS4)
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 140 di 183
Esempio 2: In questo esempio (vedere Fig. B.7), le funzioni diagnostiche sono incorporate
all’interno di un controllore logico programmabile (PLC) in SS3 che soddisfa gli aspetti relativi
della IEC 61508.

Sottosistemi (SS): Realizzano
Interruttore di blocchi i funzionali e sono elementi al
interblocco SSE 1.1 livello più elevato del progetto di
architettura di uno SRECS, dove un
guasto di qualsiasi sottosistema porta al
Interruttore di guasto della funzione di controllo relativa
interblocco SSE 1.2 PLC alla sicurezza.
conforme Elementi del Sottosistema (SSE):
alla IEC 61508 Sono componenti che realizzano gli
Contattore elementi del blocco di funzione
SSE 4.1 assegnato al sottosistema.
Funzioni Diagnostiche (D): Sono
Contattore considerate come funzioni separate che
SSE 4.2 possono avere una struttura separata nei
Sensore di velocità confronti della funzione di controllo
SSE 2.1 relativa alla sicurezza. Esse possono
essere realizzate:
x all’interno del sottosistema
Sensore di velocità x da un altro sottosistema nello
SSE 2.2 SRECS
x da un sottosistema esterno allo
SRECS
Figura B.7 – Architettura dello SRECS con funzioni diagnostiche incorporate nel
sottosistema SS3
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 142 di 183
Fase 4: Stima del SIL raggiunto dallo SRECS (vedere 6.6.3)
Il SIL che può essere richiesto per lo SRECS deve essere inferiore o uguale ai SILCL di
qualsiasi sottosistema. La probabilità di un guasto pericoloso casuale all’hardware dello
SRECS (PFH DSRECS ) è la somma delle probabilità di guasti pericolosi all’ora di tutti i
sottosistemi (da PFH D1 a PFH Dn ) interessati alla prestazione della funzione di controllo
relativa alla sicurezza e deve comprendere, ove è il caso, la probabilità di errori pericolosi di
trasmissione (P TE ) per i processi di comunicazione di dati digitali nel modo seguente:
PFH DSRECS = PFH D1 + ...+ PFH Dn + P TE
Per questo esempio, il valore di guasto da raggiungere per la funzione di controllo relativa
alla sicurezza è SIL 2 e, dalla Tab. 3 (vedere 5.2.4.2), questo equivale a una probabilità di
guasti pericolosi all’ora (PFH D ) compresa tra 10 -7 e < 10 -6 . Pertanto, considerando che le
probabilità di un guasto pericoloso all’ora di ogni sottosistema siano quelle indicate nel
seguito, la somma delle probabilità di guasti pericolosi all’ora di tutti i sottosistemi può essere
stimata come indicato in Fig. B.8.
Pertanto, in questo esempio, il progetto di SRECS può dimostrare di soddisfare tutte le

prescrizioni per la realizzazione della funzione di controllo relativa alla sicurezza a SIL 2.
Sottosistema 1 Sottosistema 2 Sottosistema 3 Sottosistema 4

interruttori di sensori di PLC (conforme contattori
interblocco di velocità alla IEC 61508)

protezione
PFH D = 1×10 –7 PFH D = 2×10 –7 PFH D = 1×10 –7 PFH D = 2×10 –7
PFH DSRECS = (1 x 10 –7 ) + (2 x 10 –7 ) + (1 x 10 –7 ) + (2 x 10 –7 ) = 6 x 10 –7
Figura B.8 – Stima della PFH D di uno SRECS
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 144 di 183
Allegato C
(informativo)
Guida alla progettazione e allo sviluppo del software incorporato

NOTA Il presente Allegato informativo è fornito per indicare l’approccio di base necessario a soddisfare le
prescrizioni della IEC 61508-3. Esso non può di per sé garantire la conformità alla IEC 61508-3 senza
l’applicazione di ulteriori misure.
C.1 Generalità
Il presente Allegato è fornito per aiutare le persone nella progettazione e nello sviluppo del
software incorporato per la realizzazione di funzioni di controllo relative alla sicurezza in uno
SRECS.
L’obiettivo principale qui considerato è una guida generale alla prevenzione dei guasti al
software incorporato e di qualsiasi altro comportamento inatteso dello stesso suscettibile di
portare a guasti pericolosi nel sistema.
Per soddisfare questi obiettivi, sono considerati i punti seguenti:
– descrizione delle caratteristiche principali che dovrebbero essere possedute dagli

elementi di uno SRECS per garantirne la qualità e la sicurezza (linee guida per l’elemento
del software);
– definizione di tutte le attività tecniche relative e delle misure associate allo sviluppo del
software per le persone coinvolte nella sua progettazione. Esse possono essere utilizzate
per guidare il progettista durante la produzione di tale tipo di software (linee guida per il
processo di sviluppo del software);

– quadro di riferimento per la valutazione del software. Questo consente al progettista e/o
all’analista di decidere che gli elementi del software soddisfano le prescrizioni di
sicurezza dello SRECS o del sottosistema dello SRECS da analizzare (linee guida per la
verifica del software).
Il presente Allegato offre una serie di linee guida fondamentali coerenti con la IEC 61508-3,
adattate al software incorporato per i microprocessori.
C.2 Linee guida per l’elemento del software
Il presente Articolo illustra le linee guida che un elemento di software incorporato in uno
SRECS o in un sottosistema di uno SRECS dovrebbe rispettare per avere un funzionamento
sicuro e di qualità sufficientemente elevata. Per ottenere un tale elemento di software
dovrebbero essere stabilite una serie di attività, una certa organizzazione e una serie di
principi. Questo dovrebbe svolgersi nelle primissime fasi del processo di sviluppo.
C.2.1 Interfaccia con l’architettura del sistema
L’elenco dei vincoli imposti al software dall’architettura dell’hardware dovrebbe essere definito
e documentato. Le conseguenze di qualsiasi interazione hardware/software sulla sicurezza
della macchina o del sistema monitorato dovrebbero essere identificate e valutate dal
progettista, e considerate nella progettazione del software.
NOTA Tra i vincoli sono presenti: protocolli e formati, frequenze di ingresso/uscita, per fronte di salita o di
discesa, per livelli di dati di ingresso utilizzando logiche inverse, ecc. L’elenco di tali vincoli consente di
tenerne conto all’inizio dell’attività di sviluppo, e riduce il rischio di incompatibilità tra software e hardware
quando il primo è installato nell’hardware indicato.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 146 di 183
C.2.2 Specifiche del software
Le specifiche del software dovrebbero considerare i punti seguenti:
– funzioni di controllo relative alla sicurezza con una descrizione quantitativa dei criteri
prestazionali (precisione, esattezza) e dei vincoli temporali (tempo di risposta), con le
tolleranze o i margini, ove possibile;
– configurazione o architettura del sistema;
– istruzioni relative all’integrità della sicurezza dell’hardware (risolutori logici, sensori,
attuatori, ecc.);
– istruzioni relative all’integrità del software;
– vincoli relativi alla capacità di memoria e al tempo di risposta del sistema;
– interfacce operatore e apparecchiatura;
– istruzioni per l’automonitoraggio del software e per il monitoraggio dell’hardware eseguito
dal software;
– istruzioni che consentono la verifica di tutte le funzioni di controllo relative alla sicurezza
mentre i sistemi sono in funzione (es., prove in linea, tempo di cattura per segnali
momentanei, coincidenza con la velocità di scansione).
NOTA 1 Le istruzioni per il monitoraggio, sviluppate tenendo conto degli obiettivi di sicurezza e dei vincoli
operativi (durata del funzionamento continuo, ecc.) possono comprendere dispositivi, quali circuiti di
vigilanza, monitoraggio del carico dell’unità centrale (CPU), retroazione dell’output verso l’input per
l’automonitoraggio del software. Per il monitoraggio dell’hardware, della CPU e della memoria, ecc.,
dovrebbero essere comprese nelle specifiche delle istruzioni per la verifica della funzione di controllo
relativa alla sicurezza: per esempio, possibilità di una verifica periodica del funzionamento corretto dei
dispositivi di sicurezza.
Dovrebbero essere specificate le prescrizioni funzionali per ogni modalità funzionale.

Dovrebbe essere specificata la transizione da una modalità all’altra.
NOTA 2 Le modalità funzionali possono comprendere modalità nominali e una o più modalità degradate.
L’obiettivo è specificare il comportamento in tutte le situazioni per evitare comportamenti inattesi in
contesti non nominali.
C.2.3 Software preesistente
Il termine software “preesistente” si riferisce a moduli sorgente che non sono stati sviluppati
specificatamente per il sistema in oggetto e che sono integrati nel resto del software. Tra essi
vi sono elementi di software sviluppati dal progettista per progetti precedenti, o software
disponibili in commercio (es., moduli di calcolo, algoritmi per l’ordinamento dei dati).
Nel considerare questo tipo di software e, in particolare, nel caso di elementi di software
commerciale, il progettista non ha sempre accesso a tutti gli elementi necessari per soddisfare le
prescrizioni precedenti (es., prove condotte, disponibilità della documentazione di progetto).
Pertanto, può essere necessario uno specifico coordinamento con l’analista nelle prime fasi.
Il progettista dovrebbe indicare all’analista l’uso di software preesistente, e dimostrare che

tale software ha lo stesso livello degli altri elementi di software. Tale dimostrazione dovrebbe
essere svolta:
a) utilizzando sul software preesistente le stesse attività di verifica utilizzate sul resto del
software; e/o
b) attraverso l’esperienza pratica quando il software preesistente ha funzionato in un sistema
analogo in un ambiente eseguibile simile (es., può essere necessario valutare le conseguenze
di una variazione del compilatore, o di un diverso formato di architettura del software).
NOTA 1 Lo scopo dell’indicazione dell’uso di un software preesistente è avviare fin dalle prime fasi una
consultazione con l’analista sulle eventuali difficoltà che questo tipo di software può causare. L’integrazione
di moduli sorgenti preesistenti può essere causa di alcune anomalie o di comportamenti non sicuri, qualora
questi non fossero stati sviluppati con lo stesso rigore del resto del software.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 148 di 183
Il software preesistente dovrebbe essere individuato utilizzando gli stessi principi di gestione
della configurazione e di controllo delle versioni applicati al resto del software.
NOTA 2 La gestione della configurazione e del controllo delle versioni dovrebbe essere condotta su tutte le
componenti del software indipendentemente dall’origine.
C.2.4 Progettazione del software
La descrizione della progettazione del software dovrebbe comprendere una descrizione di:
– architettura del software che definisce la struttura decisa per soddisfare le specifiche;
– ingressi e uscite (es., sotto forma di un vocabolario dati interno ed esterno), per tutti i
moduli che costituiscono l’architettura del software;
– interruzioni;
– dati globali;
– ogni modulo di software (ingressi/uscite, algoritmo, particolarità di progettazione, ecc.)
– moduli o librerie dati utilizzati;
– software preesistente utilizzato.
Il software dovrebbe essere modulare e scritto in modo logico per facilitarne la verifica o la
manutenzione:
– ogni modulo o gruppo di moduli dovrebbe corrispondere, se possibile, a una funzione

nelle specifiche;
– le interfacce tra i moduli dovrebbero essere più semplici possibile.
NOTA Le caratteristiche generali di una corretta architettura del software possono essere riassunte nel modo
seguente: un modulo dovrebbe possedere un livello elevato di coesione funzionale e una semplice
interfaccia con l’ambiente.
Il software dovrebbe:
– limitare il numero o l’estensione delle variabili globali;

– controllare la disposizione delle matrici nella memoria (per evitare il rischio di
superamento di memoria).
C.2.5 Codifica
Il codice sorgente dovrebbe:
– essere leggibile, comprensibile e verificabile;

– soddisfare le specifiche progettuali del modulo del software;
– seguire le istruzioni del manuale di codifica.
C.3 Linee guida per il processo di sviluppo del software
C.3.1 Processo di sviluppo: ciclo di vita utile del software
L’obiettivo della guida seguente, applicabile al ciclo di vita utile del software, è ottenere una
descrizione formalizzata dell’organizzazione dello sviluppo del software e, in particolare, dei
diversi compiti tecnici che costituiscono tale sviluppo.
Il ciclo di vita utile dello sviluppo del software dovrebbe essere specificato e documentato (es.
in un piano di qualità del software). Il ciclo di vita utile dovrebbe comprendere tutte le attività
tecniche e le fasi necessarie e sufficienti allo sviluppo del software.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 150 di 183
Ogni fase del ciclo di vita utile dovrebbe essere suddivisa nei suoi compiti elementari e
comprendere una descrizione di:
– ingressi (documenti, norme, ecc.);
– uscite (documenti prodotti, rapporti analitici, ecc.);
– attività da svolgere;
– verifiche da eseguire (analisi, prove, ecc.).
C.3.2 Documentazione: gestione della documentazione
La documentazione dovrebbe essere conforme all’Articolo 10 della presente Norma.
C.3.3 Gestione della configurazione e delle modifiche del software
La gestione della configurazione e quindi della versione è una parte indispensabile di

qualsiasi sviluppo che può necessitare di approvazione. In effetti l’approvazione è valida
solamente quando può essere individuata una configurazione specifica. La gestione della
configurazione comprende le attività di individuazione, modifica, gestione, definizione di punti
di riferimento e archiviazione di elementi di software, compresi i dati associati (documenti,
registrazioni di prove, ecc.). Per tutto il ciclo di vita utile del progetto, gli obiettivi generali
sono la fornitura di:
– una configurazione del software definita e controllata, che garantisca l’archiviazione

fisica, e che possa essere utilizzata per riprodurre in modo coerente un codice eseguibile
(tenendo conto di future produzioni o modifiche del software);
– una base di riferimento per la gestione delle modifiche;
– un mezzo di controllo in modo da analizzare correttamente qualsiasi problema ed
effettuare le modifiche approvate correttamente.
Per quanto riguarda le modifiche, i motivi possono derivare, per esempio, da:
– sicurezza funzionale inferiore a quella specificata;

– esperienza di guasto sistematico;
– legislazione nuova o emendata in materia di sicurezza;
– modifica della macchina o del suo uso;
– modifica delle prescrizioni globali di sicurezza;
– analisi delle operazioni e mantenimento delle prestazioni, che indicano che la prestazione
è inferiore al valore da raggiungere.
C.3.4 Gestione della configurazione e dell’archiviazione
Dovrebbe essere definita e documentata una procedura per la gestione della configurazione e
delle modifiche. Tale procedura dovrebbe comprendere almeno quanto segue:
– articoli gestiti dalla configurazione, almeno: specifica del software, progettazione preliminare e dettagliata
del software, moduli del codice sorgente, piani, procedure e risultati delle prove di validazione;
– regole di identificazione (di un modulo sorgente, di una versione del software, ecc.);
– trattamento delle modifiche (registrazione delle richieste, ecc.).
Per ogni articolo di configurazione dovrebbe essere possibile identificare qualsiasi

cambiamento suscettibile di essersi verificato e le versioni di qualsiasi elemento associato.
NOTA 1 Lo scopo è riuscire a rintracciare lo sviluppo storico di ogni articolo: le modifiche eseguite, il motivo e la
data.
La gestione della configurazione del software dovrebbe consentire l’ottenimento di una

versione precisa e univoca dello stesso. La gestione della configurazione dovrebbe associare
tutti gli articoli (e le loro versioni) necessari alla dimostrazione della sicurezza funzionale.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 152 di 183
Tutti gli articoli nella configurazione del software dovrebbero essere trattati dalla procedura di
gestione della configurazione prima di essere esaminati o di essere richiesti da parte
dell’analista per la valutazione definitiva della versione del software.
NOTA 2 L’obiettivo, in questo caso, è garantire che la procedura di valutazione sia eseguita sul software con tutti
gli elementi in uno stato preciso. Ogni cambiamento successivo può richiedere una revisione del software,
in modo da renderlo identificabile da parte dell’analista.
Dovrebbero essere stabilite le procedure per l’archiviazione del software e dei dati associati
(metodi di immagazzinamento dei salvataggi e degli archivi).
NOTA 3 Tali salvataggi e archivi possono essere utilizzati per la manutenzione e la modifica del software durante
il suo ciclo di vita funzionale utile.
C.3.5 Gestione delle modifiche del software
Qualsiasi modifica del software che ha un impatto sulla sicurezza funzionale dello SRECS
dovrebbe essere soggetta alle regole fissate per la gestione delle modifiche e della
configurazione, in modo che il processo di sviluppo sia riavviato nel punto “più a monte”
necessario per tener conto della modifica senza diminuire la sicurezza funzionale.
NOTA In particolare, anche la documentazione dovrebbe essere aggiornata, e dovrebbero essere svolte tutte le
necessarie attività di verifica. Questo garantisce che il software mantenga le sue proprietà iniziali dopo
ogni modifica.
C.4 Strumenti di sviluppo
Gli strumenti utilizzati durante la procedura di sviluppo (compilatore, collegatore, prove, ecc.) dovrebbero
essere identificati (nome, riferimento, versione, ecc.) nella documentazione associata alla versione del
software (es. documentazione del controllo della versione).
NOTA Strumenti di versioni diverse non producono necessariamente gli stessi risultati. Pertanto, una precisa
individuazione degli strumenti dimostra direttamente la continuità del processo di generazione di una
versione eseguibile in caso di modifica della stessa.
C.5 Riproduzione, consegna
C.5.1 Produzione del codice eseguibile
Qualsiasi opzione o variazione nella generazione durante la produzione del software,

dovrebbe essere registrata (es., nella scheda della versione), in modo che sia possibile
dichiarare come e quando il software è stato generato.
C.5.2 Installazione e sfruttamento del software
Tutti i guasti legati a funzioni di controllo relative alla sicurezza portate all’attenzione del
progettista del sistema dovrebbero essere registrate e analizzate.
NOTA Questo significa che il progettista è consapevole di qualsiasi guasto relativo alla sicurezza comunicatogli,
e che intraprende le azioni appropriate (es., avvertimento di altri utilizzatori, modifica del software, ecc.).
C.6 Verifica e validazione del software
Scopo delle attività di verifica è dimostrare che gli elementi del software che derivano da una
certa fase del ciclo di sviluppo sono conformi alle specifiche stabilite durante le fasi
precedenti e a qualsiasi norma o regolamento applicabile. Esse, inoltre, servono come mezzo
di identificazione e considerazione di qualsiasi errore introdotto durante lo sviluppo del
software.
La verifica del software non è semplicemente una serie di prove, anche se questa è l’attività
predominante per l’elemento relativamente piccolo del software considerato nel presente
Allegato. Tra le attività di verifica sono considerate anche altre attività, quali revisioni e
analisi, associate o meno a tali prove. In alcuni casi queste possono sostituire alcune prove
(es., quando una prova non può essere svolta poiché provocherebbe il deterioramento di un
componente hardware).
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 154 di 183
C.7 Linee guida generali per la verifica e la validazione
L’analista dovrebbe essere in grado di eseguire la valutazione della conformità del software
svolgendo tutte le ispezioni o perizie ritenute utili durante le varie fasi di sviluppo del
software.
Tutti gli aspetti tecnici dei processi del ciclo di vita utile del software sono soggetti alla valutazione
dell’analista. All’analista dovrebbe essere consentito l’esame di tutti i rapporti di verifica (prove,
analisi, ecc.) e di tutti i documenti tecnici utilizzati durante lo sviluppo del software.
NOTA 1 L’intervento dell’analista nella fase della specifica è preferibile a un intervento a posteriori, poiché
dovrebbe limitare l’impatto di ogni decisione presa. D’altro canto, gli aspetti finanziari e umani del
progetto non sono soggetti a valutazione.
NOTA 2 È interresse del richiedente fornire prove soddisfacenti di tutte le attività svolte durante lo sviluppo del
software.
NOTA 3 L’analista dovrebbe avere a propria disposizione tutti gli elementi necessari a formulare un’opinione.
La valutazione della conformità del software si esegue per una versione specifica e
referenziata. Qualsiasi modifica di un software precedentemente valutato che ha ricevuto
un’opinione definitiva dell’analista dovrebbe essere indicata a quest’ultimo in modo da poter
svolgere qualsiasi ulteriore attività di valutazione per aggiornare tale opinione.
NOTA 4 Qualsiasi modifica può alterare il comportamento del software, pertanto la valutazione svolta dall’analista
può applicarsi esclusivamente a una versione specifica dello stesso.
C.8 Riesame della verifica e della validazione

Le attività di analisi e di verifica della progettazione del software dovrebbero verificare la

conformità alle specifiche.
NOTA 1 Lo scopo è accertarsi che la specifica e la progettazione (dettagliata e preliminare) del software siano
coerenti.
Al termine della fase di validazione dovrebbe essere svolto un riesame esterno della
validazione (con l’analista).
NOTA 2 Esso può essere utilizzato per accertare se un elemento rispetta le specifiche.
Il risultato di ogni riesame dovrebbe essere documentato e archiviato. Dovrebbe comprendere

un elenco di tutte le azioni decise nel processo di riesame, e la conclusione dello stesso
(decisione se proseguire o meno con l’attività successiva). Le attività definite nella revisione
dovrebbero essere monitorate e trattate.
C.9 Prove del software
C.9.1 Validazione generale
Prima di redigere le prime schede di prova, è importate stabilire una strategia di prova
all’interno di un piano di prova. Tale strategia indica l’approccio adottato, gli obiettivi definiti in
termini di copertura della prova, gli ambienti e le specifiche tecniche utilizzate, i criteri di
superamento applicati, ecc.
Gli obiettivi delle prove dovrebbero essere adattati al tipo di software e ai fattori specifici. Tali
criteri determinano i tipi di prove da svolgere: prove funzionali, prove al limite, prove fuori dai
limiti, prove di prestazione, prove di carico, prove di guasti di apparecchiature esterne, prove
di configurazione, nonché la gamma di oggetti coperti dalle stesse (prove della modalità
funzionale, prove delle funzioni di controllo relative alla sicurezza, prova di ogni elemento
della specifica, ecc.).
La verifica di una nuova versione del software dovrebbe comprendere prove di non regressione.
NOTA Le prove di non regressione sono utilizzate per garantire che le modifiche apportate al software non
abbiano alterato il comportamento del software in modo inaspettato.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 156 di 183
C.9.2 Verifica della specifica del software: prove di validazione
Scopo di tali verifiche è la rilevazione di errori associati al software nell’ambiente del sistema indicato. Gli
errori rilevati da questo tipo di verifica comprendono: qualsiasi meccanismo errato di trattamento delle
interruzioni, rispetto insufficiente delle prescrizioni temporali, risposta erronea del software che funziona in
modalità transitoria (avviamento, flusso in ingresso, commutazione in modalità degradata, ecc.), conflitti di
accesso a varie risorse o problemi organizzativi nella memoria, incapacità di rilevamento delle avarie da parte
delle prove integrate, errori di interfaccia software/hardware, superamento di capacità dello stack. Le prove di
validazione sono il componente principale della verifica della specifica del software.
La copertura della prova dovrebbe essere esplicitata in una matrice di tracciabilità e accertare che:
– ogni elemento della specifica, compresi i meccanismi di sicurezza, sia coperto da una
prova di validazione; e
– il comportamento in tempo reale del software in qualsiasi modalità operativa possa essere
verificato.
Inoltre, la validazione dovrebbe essere svolta in condizioni rappresentative delle condizioni

operative dello SRECS o del suo sottosistema.
NOTA 1 Questo garantisce che il software reagisca come previsto durante il funzionamento. Si applica solo ai
casi in cui le condizioni di prova possano essere distruttive per l’hardware (es., avaria fisica di un
componente non simulabile). Per essere significativa la validazione dovrebbe svolgersi nelle condizioni
operative dello SRECS o del suo sottosistema (cioè, con le versioni definitive del software e
dell’hardware, e con il software installato nel sistema in oggetto). Qualsiasi altra combinazione potrebbe
diminuire l’efficienza delle prove e richiedere un’analisi della sua rappresentazione.
I risultati della validazione dovrebbero essere registrati in un rapporto che comprenda,

almeno, i punti seguenti:
– versioni del software e del sistema validate;

– descrizione delle prove di validazione eseguite (ingressi, uscite, procedure di prova);
– strumenti e apparecchiature utilizzate per la validazione o la valutazione dei risultati;
– risultati che indicano il successo o il mancato successo della validazione;
– valutazione della validazione: non conformità individuate, impatto sulla sicurezza, decisione di
accettare o meno la validazione.
Dovrebbe essere reso disponibile un rapporto di validazione per ogni versione del software consegnata, e
dovrebbe corrispondere alla versione definitiva di ogni elemento del software consegnato.
NOTA 2 Questo rapporto può essere utilizzato per dimostrare l’effettivo svolgimento delle prove e l’esattezza dei
risultati (o delle deviazioni contenute giustificabili). Inoltre può essere utilizzato per una successiva
riesecuzione delle prove, per una versione futura del software o per un altro progetto. Esso offre una
garanzia della validazione di ogni versione consegnata nella sua forma definitiva. D’altro canto, non
impone una validazione completa di ogni modifica di un codice esistente; un’analisi dell’impatto può, in
alcuni casi, giustificare una validazione parziale.
C.9.3 Verifica della progettazione del software: prove di integrazione del software
La presente verifica si concentra sull’assemblaggio corretto dei moduli software e sul rapporto
reciproco tra i componenti dello stesso. Può essere utilizzata per rivelare errori del tipo
seguente: errata inizializzazione di variabili e costanti, errori nel trasferimento dei parametri,
qualsiasi alterazione di dati, soprattutto dei dati globali, sequenze errate degli eventi e delle
operazioni.
Le prove dell’integrazione del software dovrebbero essere in grado di verificare:
– la sequenza corretta dell’esecuzione del software;

– lo scambio dei dati tra i moduli;
– il rispetto dei criteri di prestazione;
– la non alterazione dei dati globali.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 158 di 183
La copertura di prove dovrebbe essere fornita esplicitamente in una matrice di rintracciabilità,
a dimostrazione della corrispondenza tra le prove da eseguire e gli obiettivi definiti per le
stesse.
L’integrazione dei risultati delle prove dovrebbe essere registrata in un rapporto sulle prove di
integrazione del software che dovrebbe contenere almeno quanto segue:
– versione del software integrato;

– descrizione delle prove condotte (ingressi, uscite, procedure);
– risultati delle prove di integrazione e loro valutazione.
C.9.4 Verifica della progettazione di dettaglio: prove dei moduli
Le prove dei moduli si concentrano sui moduli software e sulla loro conformità alla
progettazione di dettaglio. Tale attività può essere indispensabile per elementi di software
grandi e complessi, ma è soltanto raccomandata per gli elementi di software relativamente
piccoli qui trattati. Questa fase della procedura di verifica consente il rilevamento dei seguenti
tipi di errore:
– incapacità di un algoritmo di rispettare le specifiche del software;

– operazioni di loop errate;
– decisioni logiche errate;
– incapacità di calcolare correttamente combinazioni valide di dati in ingresso;
– reazioni errate a dati di ingresso mancanti o alterati;
– violazione dei limiti della matrice;
– sequenze errate di calcolo;

– precisione inadeguata;
– precisione o prestazione di un algoritmo.
Ogni modulo software dovrebbe essere sottoposto a una serie di prove per verificare,
utilizzando i dati in ingresso, che il modulo adempia alle funzioni indicate nella fase di
progettazione dettagliata.
La copertura della prova dovrebbe essere fornita in una matrice di tracciabilità che dimostri la
corrispondenza tra i risultati e gli obiettivi delle prove definite.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 160 di 183
Allegato D
(informativo)
Modalità di guasto dei componenti elettrici/elettronici
L’ambiente operativo minimo per uno SRECS e i suoi sottosistemi dovrebbe essere quello
specificato nella IEC 60204-1. Tuttavia, nella pratica molti sottosistemi (es., AOPD) sono
conformi a una norma di prodotto che può avere un ambiente operativo specificato più
severo.
Le informazioni contenute nella Tab. D.1 sono esempi dei tassi di modalità di guasto di
componenti elettrici/elettronici derivati dalle fonti di riferimento indicate. Tali valori possono
essere diversi dalle informazioni fornite da altre fonti. Generalmente, i dati sulle modalità di
guasto utilizzati dovrebbero rispecchiare l’applicazione pratica dei componenti.
NOTA 1 La Tab. seguente non è un elenco esaustivo delle modalità di guasto dei componenti.
NOTA 2 I dati sulle modalità di guasto dovrebbero essere forniti dal costruttore del sottosistema.
Tabella D.1 – Esempi dei tassi delle modalità di guasto dei componenti elettrici/elettronici
Componente Modalità di guasto Tassi tipici delle

modalità di guasto
%
Interruttore con comando ad apertura Mancata apertura dei contatti 20
positiva, per esempio, pulsante, dispositivo
di arresto di emergenza, interruttori di
posizione azionati a camma, selettori
Mancata chiusura dei contatti 80

Interruttore elettromeccanico di posizione, Mancata apertura dei contatti 50
fine corsa, commutatore azionato
manualmente, ecc. (non con comando ad
apertura positiva)
Relè Tutti i contatti rimangono in posizione 25
eccitata quando la bobina è diseccitata
Tutti i contatti rimangono in posizione 25
diseccitata quando la bobina è eccitata
Mancata apertura dei contatti 10
Cortocircuito simultaneo tra tre contatti di 10
un contatto di commutazione
Chiusura simultanea di contatti 10
normalmente aperti e normalmente chiusi
Cortocircuito tra due coppie di contatti e/o 10
tra contatti e morsetto della bobina
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 162 di 183
modalità di guasto
%
Interruttore, interruttore differenziale, Tutti i contatti rimangono in posizione 25
dispositivo differenziale eccitata quando la bobina è diseccitata
Contattore Tutti i contatti rimangono in posizione 25
eccitata quando la bobina è diseccitata
Fusibile Mancata fusione (cortocircuito) 10
Circuito aperto 90
Interruttore di prossimità Resistenza permanentemente bassa 25
all’uscita
Resistenza permanentemente alta all’uscita 25
Interruzione dell’alimentazione 30
Mancato funzionamento dell’interruttore per 10
guasto meccanico
Cortocircuito simultaneo tra tre morsetti di 10
contatti di commutazione
Termostato Mancata chiusura dei contatti 30
Cortocircuito tra contatti adiacenti 10
Avaria al sensore 20
Cambiamento di rilevazione o di 20
caratteristica di uscita
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 164 di 183
modalità di guasto
%
Pressostato Mancata chiusura dei contatti 30
Cortocircuito tra contatti adiacenti 10
Avaria al sensore 20
Cambiamento di rilevazione o di 20
caratteristica di uscita
Elettrovalvola Mancata eccitazione 5
Mancata diseccitazione 15
Variazione dei tempi di commutazione 5
Perdita 65
Altre modalità di guasto (vedere Nota 4) 10
Trasformatore Circuito aperto del singolo avvolgimento 70
Cortocircuito tra avvolgimenti diversi 10
Cortocircuito in un avvolgimento 10
Variazione nel rapporto spire effettivo 10
Induttanze Circuito aperto 80
Cortocircuito 10
Variazione casuale di valore 10
Resistori Circuito aperto 80
Cortocircuito 10

Reti di resistori Circuito aperto 70
Cortocircuito 10
Cortocircuito tra connessioni qualsiasi 10
Potenziometri Circuito aperto della singola connessione 70
Cortocircuito tra tutte le connessioni 10
Cortocircuito tra due connessioni qualsiasi 10
Condensatori Circuito aperto 40
Cortocircuito 40
Variazione del valore di tan D 10
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 166 di 183
modalità di guasto
%
Semiconduttori discreti Circuito aperto di qualsiasi connessione 25
Cortocircuito tra tutte le connessioni 25
Variazione delle caratteristiche 25
Circuiti integrati non programmabili (non Circuito aperto di qualsiasi connessione 20
complessi, cioè meno di 1000 porte e/o
meno di 24 piedini, amplificatori
operazionali, registri a scorrimento e
moduli ibridi)
Avarie per “bloccaggio” 20
Oscillazione parassita delle uscite 20
Variazione dei valori (es., tensione di 20
ingresso/uscita di dispositivo analogico)
Accoppiatori ottici Circuito aperto della singola connessione 30
in ingresso
in uscita
in ingresso e in uscita
Presa a spina, connettore multipolare Cortocircuito tra due qualsiasi poli adiacenti 10
Cortocircuito tra un qualsiasi conduttore e 10

una parte conduttrice esposta
Circuito aperto di singoli poli del connettore 80
Morsetto componibile Cortocircuito tra morsetti adiacenti 10
Circuito aperto di singoli morsetti 90
NOTA 1 Questo dato è stato derivato da varie fonti industriali tra cui:
MIL-HDBK 217F (Notice 2) Reliability Prediction of Electronic Equipment (28-02-95), Parts Stress Analysis
MIL-HDBK 217F (Notice 2) Reliability Prediction of Electronic Equipment (28-02-95), Appendix A, Parts
Count Reliability Prediction
SN 29500 Part 7, Failure Rates of Components, Expected Values for Relays, April 1992
SN 29500 Part 11, Failure Rates of Components, Expected Values for Contactors, August 1990
I documenti della serie SN 29500 sono a disposizione del pubblico e possono essere ottenuti da:
Siemens AG, CT SR SI
Otto-Hahn-Ring 6
D-81739 Monaco
NOTA 2 Le modalità di guasto elettrico sono rilevate dalle Tabelle D.5 della ISO 13849-2. Modalità di guasto
meccanico (ove applicabili) sono tratte dagli Allegati A, B e C della ISO 13849-2.
NOTA 3 Per alcuni componenti elettrici/elettronici, per esempio, resistori e condensatori, progetti diversi possono
avere una diversa distribuzione della modalità di guasto rispetto a quella indicata in Tabella.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 168 di 183
NOTA 4 Altre modalità di guasto che si applicano a una elettrovalvola comprendono:
mancata commutazione (permanenza in posizione estrema o in posizione zero) o commutazione
incompleta (permanenza in una posizione intermedia casuale);
variazione spontanea della posizione iniziale di commutazione (senza un segnale di ingresso);
variazione nella portata della perdita nel corso di un lungo periodo;
scoppio dell’involucro della valvola o rottura dei componenti mobili, nonché rottura/frattura delle viti
di montaggio o dell’involucro;
avarie pneumatiche/idrauliche che causano un comportamento incontrollato delle servovalvole e delle
valvole proporzionali.
NOTA 5 Altre fonti di informazioni sui dati dei tassi di guasto e sui tassi delle modalità di guasto comprendono:
UTE C 80-810 RDF 2000: Reliability data handbook – A universal model for reliability prediction of
electronic components, PCBs and equipments
Failure mode/mechanism distributions FMD-91, RAC 1991
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 170 di 183
Allegato E
(informativo)
Fenomeno elettromagnetico (EM) e aumento dei livelli di immunità per gli

SRECS destinati all’uso in un ambiente industriale conforme alla
IEC 61000-6-2
Tabella E.1 – Fenomeno EM e aumento dei livelli di immunità per gli SRECS
Porta Fenomeno Norma base Valori aumentati per le prove

(vedere Nota 1) supplementari per le prestazioni
dello SRECS (vedere 6.4.3)
Involucro Scarica elettrostatica (ESD) IEC 61000-4-2 6 kV/8 kV scarica contatto/aria
(vedere Nota 2)
Campo elettromagnetico (EM) IEC 61000-4-3 20 V/m (80 MHz – 1 GHz)
6 V/m (1,4 GHz – 2 GHz)
3 V/m (2 GHz – 2,7 GHz)
(vedere Tab. E.2 e Nota 3)
Campo magnetico a frequenza IEC 61000-4-8 30 A/m (vedere Note 4 e 5)
nominale di rete
Potenza AC Buchi/brevi interruzioni di IEC 61000-4-11 0,5 periodi
tensione
30 % riduzione (vedere Nota 5)
Variazioni/ interruzioni di IEC 61000-4-11 250 periodi
tensione >95 % riduzione (vedere Nota 5)
Treno d’impulsi IEC 61000-4-4 4 kV
Impulso IEC 61000-4-5 2 kV linea-linea/4 kV linea-terra

(vedere Nota 6)
Radiofrequenze (RF) condotte IEC 61000-4-6 10 V alle frequenze date (vedere
Tab. E.3 e Nota 3)
Potenza DC Treno d’impulsi IEC 61000-4-4 4 kV
(vedere Nota 7)
Impulso IEC 61000-4-5 1 kV linea-linea/2 kV linea-terra
(vedere Nota 6)
RF condotte IEC 61000-4-6 10 V alle frequenze date (vedere
Tab. E.3 e Nota 3)
Linee di segnale I/O Treno d’impulsi IEC 61000-4-4 2 kV per linee > 3 m
/ controllo
Impulso IEC 61000-4-5 2 kV linea-terra (vedere Nota 8)
RF condotte IEC 61000-4-6 10 V alle frequenze date (vedere
Tab. E.3 e Nota 3)
Terra funzionale Treno d’impulsi IEC 61000-4-4 2 kV
NOTA 1 Una porta è un’interfaccia particolare dello SRECS e dei suoi sottosistemi con l’ambiente
elettromagnetico esterno.
NOTA 2 I livelli devono essere applicati in conformità alle condizioni ambientali descritte nella IEC 61000-4-2 su
parti che possono essere toccate da persone diverse dal personale che lavora secondo procedure
definite per il controllo delle ESD, ma non alle apparecchiature con accesso limitato al solo personale
adeguatamente addestrato.
NOTA 3 I valori aumentati devono essere applicati nelle gamme di frequenza generalmente utilizzate per i
trasmettitori radiomobili digitali, salvo quando sono utilizzate misure efficaci per evitare le interferenze
elettromagnetiche da tali apparecchiature. Le frequenze ISM devono essere considerate individualmente.
NOTA 4 Solo verso apparecchiature sensibili al magnetismo.
NOTA 5 Un valore aumentato non si applica ai fenomeni quando non è considerato necessario alla sicurezza
funzionale.
NOTA 6 Sono consentiti dispositivi esterni di protezione per ottenere l’immunità.
NOTA 7 I collegamenti DC tra parti dell’apparecchiatura/sistema non collegate a una rete di distribuzione in DC
sono considerati come porte I/O di segnale/controllo.
NOTA 8 Solo in caso di linee su lunghe distanze.
NOTA 9 Riferimento alla IEC 61326-3 (in preparazione).
NOTA 10 Quando le norme di prodotto (es. IEC 61496-1) specificano livelli di prova diversi per fenomeni EMC
specifici nel contesto della sicurezza funzionale, tali diversi livelli di prova si applicano ai sottosistemi
dello SRECS.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 172 di 183
Tabella E.2 – Frequenze selezionate per prove di campo RF
Sistema Frequenza
GSM 890 – 915 MHz
GSM 1 710 – 1 785 MHz
GSM 1 890 MHz
UMTS Allo studio
Ricetrasmittente Allo studio
ISM 433,05 – 434,79 MHz
ISM ??? 83,996 – 84,004 MHz
ISM ??? 167,992 – 168,008 MHz
ISM ??? 886,000 – 906,000 MHz
Tabella E.3 – Frequenze selezionate per prove RF condotte
Sistema Frequenza
ISM 6,765 – 6,795 MHz
ISM 13,553 – 13,567 MHz
ISM 26,957 – 27,283 MHz
ISM 40,66 – 40,70 MHz
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 174 di 183
Allegato F
(informativo)
Metodologia per la stima della suscettibilità

ai guasti per cause comuni (CCF)
F.1 Generalità
Il presente Allegato informativo offre un semplice approccio quantitativo alla stima dei CCF
applicabili alla progettazione del sottosistema.
F.2 Metodologia
Il progetto proposto per un sottosistema dovrebbe essere valutato per stabilire l’efficacia delle
misure utilizzate per proteggere dai CCF. Dovrebbero essere individuate le voci applicabili
della Tab. F.1, e dovrebbe essere stabilito un punteggio globale utilizzato per determinare il
fattore di guasto per cause comuni dalla Tab. F.2, come valore percentuale.
Tabella F.1 – Criteri per la stima del CCF
Voce Riferimento Punteggio

Separazione/segregazione
I cavi di segnale dello SRECS per i singoli canali percorrono vie separate dagli altri 1a 5
canali in tutte le posizioni, oppure sono sufficientemente schermati?
Quando vengono utilizzate informazioni di codifica/decodifica, sono sufficienti al 1b 10

rilevamento degli errori di trasmissione dei segnali?
I cavi di segnale dello SRECS e i cavi elettrici di potenza sono separati in tutte le 2 5
posizioni, oppure sono sufficientemente schermati?
Se elementi del sottosistema possono contribuire a un CCF, sono forniti come 3 5
dispositivi fisicamente separati in involucri autonomi?
Diversità/ridondanza
Il sottosistema usa tecnologie elettriche diverse, per esempio, una elettronica o 4 8
elettronica programmabile e l’altra con un relè elettromeccanico?
Il sottosistema usa elementi che utilizzano principi fisici diversi (es., sensori a una 5 10
porta di protezione che utilizzano tecniche meccaniche e magnetiche)?
Il sottosistema usa elementi con differenze temporali nelle operazioni funzionali e/o 6 10
nelle modalità di guasto?
Gli elementi del sottosistema hanno un intervallo diagnostico di prova 1 min? 7 10
Complessità/progetto/applicazione
È evitata l’interconnessione tra canali del sottosistema con l’eccezione di quella 8 2
utilizzata per scopi diagnostici?
Valutazione/analisi
Sono stati esaminati i risultati delle modalità di guasto e l’analisi degli effetti per 9 9
stabilire fonti di guasti per cause comuni, e sono state eliminate mediante la
progettazione le fonti di guasti per cause comuni predeterminate?
I guasti in campo sono analizzati con una retroazione alla progettazione? 10 9
Competenza/formazione
I progettisti del sottosistema comprendono le cause e le conseguenze dei guasti per 11 4
cause comuni?
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 176 di 183
Voce Riferimento Punteggio
Controllo ambientale
Gli elementi del sottosistema tendono a funzionare sempre nel campo delle 12 9
temperature, umidità, corrosione, polvere, vibrazione, ecc., nel quale sono stati
provati senza l’uso di controlli ambientali esterni?
Il sottosistema è immune alle influenze negative delle interferenze elettromagnetiche 13 9
fino ai limiti specificati nell’Allegato E compresi?
NOTA Un elemento alternativo (es., riferimenti 1a e 1b) è indicato nella Tab. F.1 quando si prevede che si possa
richiedere un contributo alla prevenzione dei CCF solo dall’elemento più rilevante.
Utilizzando la Tab. F.1 gli elementi considerati come aventi un impatto sul progetto del
sottosistema dovrebbero essere sommati per fornire un punteggio globale per il progetto da
realizzare. Quando può essere dimostrato che i mezzi equivalenti per evitare il CCF possono
essere ottenuti attraverso l’uso di specifiche misure progettuali (es., uso di dispositivi a
isolamento ottico anziché cavi schermati), può essere utilizzato il punteggio relativo poiché si
può considerare che il contributo alla prevenzione dei CCF sia lo stesso.
Tale punteggio totale può essere utilizzato per determinare un fattore di guasto per cause
comuni (ȕ) utilizzando la Tab. F.2.
Tabella F.2 – Stima del fattore CCF (ȕ)
Punteggio totale Fattore di guasto per cause comuni (ȕ)

< 35 10 % (0,1)
35 – 65 5 % (0,05)
65 – 85 2 % (0,02)
85 – 100 1 % (0,01)
Il valore di ȕ derivato dovrebbe essere utilizzato nella stima della probabilità dei guasti
pericolosi come richiesto in 6.7.8.1.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 178 di 183
Allegato ZA
(normativo)
Riferimenti normativi alle Pubblicazioni Internazionali

con le corrispondenti Pubblicazioni Europee
I documenti normativi sottoelencati sono indispensabili per l’applicazione del presente
documento. In caso di riferimenti datati, si applicano solo le edizioni citate. In caso di
riferimenti non datati, si applica l’ultima edizione della Pubblicazione indicata (modifiche
incluse).
NOTA Quando la Pubblicazione Internazionale è stata modificata da modifiche comuni CENELEC, indicate con
(mod), si applica la corrispondente EN/HD.
Pubblicazione Anno Titolo EN/HD Anno Norma CEI

(1)
IEC 60204-1 - Sicurezza del macchinario - EN 60204-1 1997(2) 44-5
Equipaggiamento elettrico delle + corr. 1998
macchine - Parte 1: Regole September
generali
(1)
IEC 61000-6- - Compatibilità elettromagnetica EN 61000-6-2 2001(2) 210-54
2, mod. (EMC) - Parte 6-2: Norme
generiche - Immunità per gli
ambienti industriali
IEC 61310 Serie Sicurezza del macchinario - EN 61310 Serie 44-9
Indicazione, marcatura e manovra
- Parte 2: Prescrizioni per la
marcatura
(1)
IEC 61508-2 - Sicurezza funzionale dei sistemi EN 61508-2 2001(2) 65-75
elettrici, elettronici ed elettronici
programmabili per applicazioni di
sicurezza - Parte 2: Requisiti per i
sistemi elettrici, elettronici ed
elettronici programmabili per
applicazioni di sicurezza
IEC 61508-3 -(1) Sicurezza funzionale dei sistemi EN 61508-3 2001(2) 65-76
elettrici, elettronici ed elettronici
programmabili per applicazioni di
sicurezza - Parte 3: Requisiti del
software
ISO 12100-1 2003 Safety of machinery EN ISO 12100-1 2003 -
Basic concepts, general principles
for design - Part 1: Basic
terminology, methodology
ISO 12100-2 2003 Basic concepts, general principles EN ISO 12100-2 2003 -
for design - Part 2: Technical
principles
ISO 13849-1 1999 Safety of machinery - Safety- - - -
related parts of control systems
Part 1: General principles for
design
ISO 13849-2 2003 Part 2: Validation EN ISO 13849-2 2003 -
(1)
ISO 14121 - Safety of machinery Principles of - - -
risk assessment
(1) Riferimenti non datati.
(2) Edizione valida al momento della pubblicazione.
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 180 di 183
Allegato ZZ
(informativo)
Copertura dei requisiti essenziali delle Direttive Comunitarie
La presente Norma Europea è stata preparata su mandato accordato al CENELEC dalla

Commissione Europea e dall’Associazione Europea per il Libero Scambio (EFTA) e,
all’interno del suo campo di applicazione, contempla i seguenti requisiti essenziali tra quelli
forniti nell’Allegato I della Direttiva Comunitaria 89/37/CE:
1.2.1;
1.2.7.
L’osservanza della presente Norma fornisce un dei mezzo di conformità ai requisiti essenziali
specificati dalla Direttiva interessata.
ATTENZIONE: Altri requisiti ed altre Direttive Comunitarie possono essere applicabili ai

prodotti compresi nel campo d’applicazione della presente Norma.
___________
NORMA TECNICA
CEI EN 62061:2005-09
Pagina 182 di 183
La presente Norma è stata compilata dal Comitato Elettrotecnico Italiano e
beneficia del riconoscimento di cui alla legge 1° Marzo 1968, n. 186.
Editore CEI, Comitato Elettrotecnico Italiano, Milano – Stampa in proprio
Autorizzazione del Tribunale di Milano N. 4093 del 24 Luglio 1956
Responsabile: Ing. A. Alberici
Comitato Tecnico Elaboratore

CT 44-Equipaggiamento elettrico delle macchine industriali
Altre Norme di possibile interesse sull’argomento
CEI EN 60204-1 (CEI 44-5)

Sicurezza del macchinario - Equipaggiamento elettrico delle macchine - Parte 1: Regole generali
CEI EN 61310-1 (CEI 44-8)

Sicurezza del macchinario - Indicazione, marcatura e manovra - Parte 1: Prescrizioni per segnali visivi, acustici e tattili
CEI EN 61310-2 (CEI 44-9)

Sicurezza del macchinario - Indicazione, marcatura e manovra - Parte 2: Prescrizioni per la marcatura
CEI EN 61508-1 (CEI 65-74)

Sicurezza funzionale dei sistemi elettrici, elettronici ed elettronici programmabili per applicazioni di sicurezza - Parte 1:
Requisiti generali
CEI EN 61508-2 (CEI 65-75)

Requisiti per i sistemi elettrici, elettronici ed elettronici programmabili per applicazioni di sicurezza
CEI EN 61508-3 (CEI 65-76)

Requisiti del software
€ 165,00
NORMA TECNICA Sede del Punto Vendita e di Consultazione
CEI EN 62061:2005-09 20134 Milano Via Saccardo,9
Totale Pagine 192 Tel. 02/21006.1 Fax 02/21006.222
http://www.ceiweb.it e-mail cei@ceiweb.it

Cei en Ita Con Agg

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Cei en Ita Con Agg

Caricato da

Copyright:

Formati disponibili

N O R M A I T A L I A N A C E I

Data Pubblicazione Edizione

Sicurezza del macchinario - Sicurezza funzionale dei sistemi di

Safety of machinery - Functional safety of safety-related electrical,

TECNICHE DI CONTROLLO E DI MISURA DEI

CEI COMITATO ELETTROTECNICO ITALIANO

COLLEGAMENTI/RELAZIONI TRA DOCUMENTI

Comitato Tecnico CT 44-Equipaggiamento elettrico delle macchine industriali

Gruppo Abb. 9 Sezioni Abb. B

© CEI - Milano 2005. Riproduzione vietata

Sicurezza del macchinario - Sicurezza funzionale dei sistemi di comando e

Safety of machinery - Functional safety of safety-related electrical, electronic and

Sécurité des machines - Sécurité fonctionnelle des systèmes de commande

Sicherheit von Maschinen - Funktionale Sicherheit sicherheitsbezogener

Copia concessa a FONDITAL SPA in data 12/05/2010 da CEI-Comitato Elettrotecnico Italiano

Sono state fissate le date seguenti:

– data ultima entro la quale la EN deve essere

– data ultima entro la quale le Norme nazionali contrastanti

INTERVALLO DI VERIFICA PERIODICA (PROOF TEST) E CICLO DI VITA

Il CEN/TC114/WG6 ha utilizzato un intervallo per la verifica periodica (tempo di missione) di 20 anni a

Gli Allegati ZA e ZZ sono stati aggiunti dal CENELEC.

Sicurezza del macchinario - Sicurezza funzionale dei sistemi di comando

3.2 Termini e definizioni

Eliminare la Nota alla definizione 3.2.41: guasto in sicurezza.

Sostituire la Tabella 5 con la seguente:

Tabella 5 – Vincoli dell’architettura sui sottosistemi:

Frazione di guasto in Tolleranza all’avaria dell’hardware (vedere Nota 1)

t 99 % SIL3 SIL3 (vedere Nota 2) SIL3 (vedere Nota 2)

Articolo 6, aggiungere il nuovo paragrafo 6.7.6.4 seguente:

6.7.6.4 I sottosistemi elettromeccanici con una frazione di guasto in sicurezza inferiore al

Rinumerare il paragrafo 6.7.6.4 in:

6.7.6.5 Quando un sottosistema è progettato in conformità alla ISO 13849-1:1999 e validato

Tabella 6 – Vincoli dell’architettura: SILCL in rapporto alle categorie

Categoria Tolleranza all’avaria SFF Massimo limite di SIL

Cambiare la Nota al paragrafo 6.7.7.3 come segue:

Cambiare il paragrafo 6.7.8.1.6 e la Tabella 7 come segue:

6.7.8.1.6 Quando un sottosistema a bassa complessità è progettato secondo la

Tabella 7 – Probabilità di un guasto pericoloso

Tolleranza all’avaria Valori di soglia (orari) PFHD che

1 0 0% Da fornire a cura del fornitore o

Allegato A: Assegnazione del SIL

Cambiare il terzo capoverso in A.2.4.1 come segue:

Cambiare la Tabella A.2 come segue:

Tabella A.2 – Classificazione della frequenza e durata dell’esposizione (Fr)

Frequenza e durata dell’esposizione (Fr)

Da < 1 per h a 1 per giorno 5

Cambiare la Tabella A.6 come segue:

Tabella A.6 – Matrice di assegnazione del SIL

Gravità (Se) Classe (Cl)

Cambiare la Figura A.3 come segue:

Prodotto: Valutazione del rischio prima delle misure

N. Per. Pericolo Se Fr Pr Av Cl Misura di sicurezza Sicuro

Copia concessa a FONDITAL SPA in data 12/05/2010 da CEI-Comitato Elettrotecnico Italiano

Tabella F.2 – Stima del fattore CCF ()

Punteggio totale Fattore di guasto per cause comuni ()

Comitato Tecnico Elaboratore

Altre Norme di possibile interesse sull’argomento

CEI EN 60204-1 (CEI 44-5)

CEI EN 60204-31 (CEI 44-7)

CEI EN 61310-1 (CEI 44-8)

CEI EN 61310-2 (CEI 44-9)

CEI EN 61496-1 (CEI 44-10)

CEI EN 60204-32 (CEI 44-11)