È uscita la nuova edizione della norma IEC 61508: 2010

1. A partire da quando dobbiamo applicarla?

2. Come dobbiamo applicarla?
3. E soprattutto, perché dobbiamo applicarla??

1
É uscita l’edizione 2010 della norma IEC 61508.
Da quando deve essere applicata?

2
Le norme emesse dalla IEC (International Electrotechnical Commission), al contrario di
altre
lt (ad
( d esempio
i l’l’edizione
di i CENELEC d della
ll stessa,
t che
h hha un periodo
i d di
sovrapposizione con l’edizione precedente che scade a fine maggio 2013), non hanno
periodo transitorio, ovvero entrano in vigore subito.

Il riferimento della IEC 61508 nella IEC 61511 è “non datato”, quindi deve essere
applicata l’ultima edizione.

Lo stesso vale anche per la EN 61800

61800-5-2,
5 2 si veda il punto 2 Normative References
References, che
dice:
References to various parts of IEC 61508 are undated, unless where specific clauses are
indicated.
(ovviamente, per quello che riguarda l’edizione CENELEC, e quindi anche per la
conformità alla Direttiva Macchine, vale come data di scadenza il 31 Maggio 2013).

I riferimenti all’interno
all interno della EN 62061 sono invece datati, per cui la nuova edizione della
norma sarà applicabile sono a seguito di modifica della IEC/EN 62061.

3
La IEC 61511 fa riferimento alla IEC 61508 per quello che rigaurda “costruttori e fornitori
di di
dispositivi”
iti i” che
h ddebbano
bb essere iintegrati
t ti iin S
Safety
f t IInstrumented
t t dSSystems
t per l’i
l’industria
d ti
di processo (chimico, oil&gas, farmaceutico, etc.).

Essendo il riferimento alla IEC 61508 “non datato”, deve essere applicata l’ultima
edizione.

4
5
6
7
8
La norma introduce definizioni dettagliate per tutta una serie di termini
utilizzati nella stessa (sia termini nuovi, che termini in precedenza utilizzati
ma non definiti, il che creava problemi di differenza di interpretazione).

9
Vengono introdotti i concetti di Tool di supporto SW funzionanti on-line oppure off-line.
I requisiti relativi sono nella parte 3 della norma.
In generale vale quanto segue:
7.4.4.1 A software on-line support tool shall be considered to be a software
element of the safety-related system
7.4.4.2 Software off-line support tools shall be selected as a coherent part of the software
development activities.

I requisiti per i tool off-line sono stati estesi, per i motivi spiegati più sotto:
The requirements for the selection and validation of tools to support the development,
verification and testing of safety related software have been greatly extended in d2.0, to
reflect the importance of this topic and the wide variety of support tools which are now
available. Tools are classified as T1, T2, or T3 depending on their purpose in the software
safety lifecycle and the possible effects of incorrect outputs from the tool (note that these
tool classes are defined in IEC 61508-4 rather than in Part 3). For example, a software
design tool which provides automatic source code generation is more critical than a
simple text editor, and a compilation system more critical than a source code generator.
For tools with higher criticality (T2 and T3), a specification of the tool is required so that its
behaviour and the implications of using it can be fully understood.

10
La norma introduce tutta una serie di requisiti per gli ASIC, in precedenza non trattati.

Gli ASIC vengono trattati all’interno della parte 2 della norma, e per loro viene definito:
• uno specifico modello di sviluppo a V (con similitudini rispetto allo sviluppo SW)
• tecniche e misure per controllare ed evitare guasti sistematici

•Full custom ASIC: ASIC where design and production is similar to a standard integrated
circuit with the functionalityy defined by
y the p
product developer.
p
•Core based ASIC: ASIC based on a pre-layout, designed or generated macro cores,
supported by additional logic.
•Cell based ASIC: ASIC based on logic primitives (like AND, OR, Flip-Flop, Latch) taken
from a cell library.
•Gate array: pre-manufactured silicon masters with a fixed number of cells that provide a
common starting point for different components.
•Field programmable gate array (FPGA): standard integrated circuit, using one-time
programmable or reprogrammable elements to define the connection between functional
blocks and to configure the functionality of the individual blocks.
•Programmable logic device (PLD): standard integrated circuit, with low to medium
complexity, using one-time programmable or electrical erasable elements (fuses) to
define combinatorial logic – typically based on AND or OR product terms – and
configurable storage elements.
•Complex programmable logic device (CPLD): multiple PLD-like blocks on a single chip,
connected byy a p
programmable
g interconnection matrix ((crossbar).
)

11
Per conformarsi alla IEC 61511, la norma parla di “altre misure per la riduzione del
rischio”,
i hi ” assimilabili
i il bili aglili ““altri
lt i lilivelli
lli di protezione”
t i ”ddella
ll IEC 61511.
61511

Importante è l’introduzione della definizione di “Elemento”, che può essere inteso come
“blocco funzionale in grado di svolgere una (o più) ben definita funzione d sicurezza”
denominata “element safety function”, rispetto all’”overall safety function”

Elementi sono ad esempio:

• Sensori
S i / trasduttori
t d tt i di processo
• Moduli I/O
• CPU di Logic Solver
• Solenoid Valve
• Attuatore
• Valvola di chiusura

Rispetto alla precedente edizione, due sono i punti importanti:

1. Viene chiarito che la Funzione di Sicurezza è da definirsi anche a livello di elemento
funzionale, non solo al sistema completo
2. Tutta una serie di requisiti, ad esempio Systematic Capability, HFT e SFF, sono
applicabili a partire dagli elementi

12
Come noto, la norma tratta in maniera differente i guasti casuali (con determinazione
numerica
i di valori
l i di ffailure
il rate,
t e rispondenza
i d a requisiti
i iti di PFDAVG e PFH) e quelli
lli
sistematici (con determinazione di un parametro sotto definito, e rispondenza a requisiti
di tecniche e misure da applicare per un certo SIL).

Viene introdotto il concetto di “systematic capability” di un elemento.

Tale valore deve anche essere esplicitamente dichiarato per i “compliant items” all’interno
del Safety Manual.

Viene meglio specificato il SW Safety Integrity Level, con riferimento alla Systematic
Capability.

13
Viene chiarito che le Specifiche dei Requisiti di Sicurezza sono per il Sistema (e
i l d
includono requisiti
i iti di iintegrità
t ità e di ffunzionalità).
i lità)

NOTA: per una corretta progettazione degli “elementi”, in assenza di “system safety
requirements specification”, si raccomanda di partire dalle safety requirements
specification dell’elemento stesso (senò a volte è impossibile partire …).

Viene introdotto il concetto di “design requirements”, che include i requisiti di

progettazione per realizzare la funzione di sicurezza così come specificata
specificata.

14
Rispetto alla definizione precedente:
3.5.16 mode of operation
•way in which a safety-related system is intended to be used, with respect to the
frequency of demands made upon it, which may be either
– low demand mode: where the frequency of demands for operation made on a
safetyrelated system is no greater than one per year and no greater than twice the
proof-test frequency;
– high demand or continuous mode: where the frequency of demands for
operation made on a safety
safety-related
related system is greater than one per year or greater
than twice the proofcheck frequency
NOTE 1 – High demand or continuous mode covers those safety-related systems
which implement continuous control to maintain functional safety.
NOTE 2 – The target failure measures for safety-related systems operating in low
demand mode and high demand or continuous mode are defined in 3.5.13.

1. È stato eliminato il riferimento al confronto con la frequenza di proof test, che a

parere di chi scrive non era corretto
2. È stata modificata la definizione di “Continuous Mode” (anche se nell’industria di
processo sistemi di sicurezza siffatti sono molto rari)

15
È stata modificata in maniera sostanziale la definizione di guasto (fallimento) pericoloso
e, soprattutto,
tt tt di guasto
t sicuro.
i

Sono stati introdotti inoltre i concetti di “no part failure” e “no effect failure”: tutto questo ha
effetto sulla valutazione FMEDA e della SFF.

Guasto pericoloso:
1. Si chiarisce che il guasto deve essere relativo ad elementi che svolgono un ruolo
nell’implementare
ll’i l t una funzione
f i di sicurezza
i
2. Si chiarisce che il guasto è pericoloso se è tale da “compromettere la funzione di
sicurezza”, non perché è pericoloso in sé (ad esempio guasto di un isolamento
elettrico, oppure una perdita di fluido di processo verso l’esterno)
3. Purtroppo la seconda parte della definizione “decreases the probability …” può
ingenerare problematiche di interpretazione (un guasto di deriva può “diminuire la
probabilità …”: deve essere valutato caso per caso)

16
La modifica alla definizione di guasto “Safe” è ancora più corposa e significativa.

Guasto sicuro:
1. Si chiarisce che il guasto deve essere relativo ad elementi che svolgono un ruolo
nell’implementare una funzione di sicurezza
2. Il guasto è sicuro se “porta in sicurezza” oppure “aumenta la probabilità che il
sistema vada in sicurezza”, non più quando “non porta in situazione di pericolo”
3. Anche in questo caso la seconda parte della definizione “increases the probability …”
può
ò iingenerare problematiche
bl ti h di iinterpretazione,
t t i ed
deve essere valutato
l t t caso per
caso

La norma quindi “favorisce” ancora di più sistemi nei quali i guasti sono :
a. rilevati, oppure
b. vanno in direzione della sicurezza (e questo può creare anche un assurdo, favorendo
dispositivi che si guastano di più)

NOTA: per alcune tipologie di “elementi” risulta difficile avere guasti safe.
Esempio: Valvole di Shut-Down: non ho mai visto valvole di shut-down che si chiudono
da sole … un guasto safe può essere un guasto di alimentazione, ma non è un guasto
della valvola in sè

17
Viene introdotto il concetto di “soft-error”: valgono le seguenti note:
NOTE 1 When a soft error has occurred and the data is rewritten, the circuit will be
restored to its original state.
NOTE 2 Soft errors can occur in memory, digital logic, analogue circuits, and on
transmission lines, etc and are dominant in semiconductor memory, including registers
and latches. Data may be obtained, for example, from manufactures.
NOTE 3 Soft errors are transient and should not be confused with software programming
errors.
NOTE Soft
Soft-errors
errors are listed in Table A
A.1,
1 IEC 61508
61508-2
2 as faults to be detected during
operation or to be analysed in the derivation of the safe failure fraction. Causes of
soft errors are: (1) Alpha particles from package decay, (2) Neutrons, (3) external EMI
noise, (4) Internal cross-talk.
Esempi di tecniche per diagnosticare soft-errors: RAM tests, such as walk-path, galpat,
etc. are not effective, whereas monitoring techniques using Parity and ECC with recurring
read of the memory cells or techniques using redundancy (and comparison or voting)
can be.

Oltre a “Dangerous” e “Safe” Failures, vengono ora introdotti i concetti di “no part” e “no
effect” failures.
Da notare che “no part” è riferito ad “componente”, mentre “no effect” a “elemento”.

ESEMPIO

18
La definizione della SFF è cambiata: a denominatore non c’è più λtot, ma
λS + λD

“no part” e “no effect” failures sono quindi esclusi dl calcolo della
SFF.

19
Vengono definiti (curiosamente, prima non lo erano), il PFDAVG e il PFH.

Il particolare, il PFDAVG è la “mean unavailability“ di un sistema di sicurezza (il tutto per

essere poi congruente con le formule ricavate dalla teoria).

NOTA BENE: in Low Demand Mode è sempre al PFDAVG che si fa riferimento quando ci
si confronta con i limiti dei vari gradi di SIL.

Viene specificato che al PFDAVG contribuiscono:

• i guasti undetected dall’ultimo “proof test”
• i guasti cosiddetti “on demand”, ovvero quelli che si rilevano solo durante la richiesta

I primi sono caratterizzati da una frequenza di guasto oraria, mentre i secondi sono
caratterizzati da una “probabilità di guasto “per demand”.

NOTA: la definizione non è comunque esatta, perché sono rilevanti anche i guasti DD
non ancora rilevati dall’ultimo test diagnostico (che potrà essere frequente finché si vuole,
ma che non sarà mai continuo, ed anzi spesso, quando invasivo, è ad intervalli discreti).

20
Nell’edizione 2000 della norma si parlava solo di MTTR (peraltro non definito),
N ll’ di i
Nell’edizione 2010 sii parla
l di MTTR e MRT
MRT.
MTTR include:
the time to detect the failure (a); and,
the time spent before starting the repair (b); and,
the effective time to repair (c); and,
the time before the component is put back into operation (d)
MRT include invece:
(b), (c) and (d) of the times for MTTR

Il tempo a) non era esplicitamente considerato nella edizione 2000: la definizione di

MTTR e MRT consente quindi di correggere un errore nelle formule della Parte 6 della
norma per il calcolo di PFDAVG (nella slide il calcolo del PFDAVG nel caso di sistema
1oo1(D) con diagnostica ad intervalli definiti, ad esempio Partal Stroking Test.
Le formule per le altre architetture vanno corrette di conseguenza.

MTTR e MRT sono importanti anche nella considerazione o meno della diagnostica, in
funzione del Modo Operativo (Low Demand o High Demand) (si veda nel seguito).

21
Per il Proof Test valgono le seguenti note:
NOTE 1 In this standard the term “proof test” is used but it is recognised that a
synonymous term is “periodical test”.
NOTE 2 The effectiveness of the proof test will be dependent upon how close to the “as
new” condition the system is restored. For the proof test to be fully effective, it will be
necessary to detect 100 % of all dangerous failures both on failure coverage and repair
effectiveness. In practice detecting 100 % of the hidden dangerous failures is not easily
achieved for other than low-complexity E/E/PE safety-related systems. …
NOTE 3 A p proof test needs some time to be achieved. During g this time the E/E/PE safety
y
related system may be inhibited partially or completely. The proof test duration can be
neglected only if the part of the E/E/PE safety related system under test remains available
in case of a demand for operation or if the EUC is shut down during the test.
NOTE 4 During a proof test, the E/E/PE safety related system may be partly or
completely unavailable to respond to a demand for operation. The MTTR can be
neglected for SIL calculations only if the EUC is shut down during repair or if other risk
measures are put in place with equivalent effectiveness.

Sono cambiate tante definizioni, ma non quella relativa a “detected” (a parte la nota).
Quindi, anche guasti rilevati da Proof Test, normale funzionamento o intervento
dell’operatore sono da considerare “detected”, posto che vengano poste in atto
misure efficaci per la sicurezza quando rilevati (ovvero, comportamento del sistema alla
rilevazione di un guasto: Fail Safe o “riparazione controllata del guasto entro un periodo
definito”, a seconda della presenza o meno di ridondanze e del modo operativo di
funzionamento)

22
La edizione 2010 della norma richiede, come requisito obbligatorio per “compliant items”
(d
(dove “it
“item”” è d
da iintendersi
t d i sinonimo
i i di ““element”).
l t”)
Il Safety Manual deve contenere informazioni che riguardano sia HW che SW (nel seguito
un indice).

Viene anche definito l’approccio “proven in use” che, come vedremo in seguito, risulta
però svantaggioso per il fabbricante.

23
24
In realtà, nessuna modifica sostanziale: viene focalizzata l’attenzione su:
“E/E/PE Systems”.

25
Lo sviluppo di ASICs deve seguire un ciclo di vita simile a quello della Parte 3 per il SW.
Per lo sviluppo di ASICs:
• deve essere messa a punto documentazione per ciascuna fase
• devono essere seguite tecniche e misure per raggiungere la “Systematic Capability”
desiderata per l’ASIC

A detailed V-model of the ASIC development lifecycle for the design of ASICs (see IEC
61508-4, 3.2.15) is shown in Figure 3.

NOTE 2 There are significant similarities between the ASIC and the software design
processes. IEC 61508-3 recommends the V-model for designing safety-related software.
The V-model requires a clearly structured design process and a modular software
structure for avoiding and controlling systematic faults. The ASIC Development lifecycle
for the design of ASICs in Figure 3 follows this model. At first the requirements for the
ASIC specification are derived from the system requirements. ASIC architecture, ASIC
design and module design follow. The results of each step on the left-hand side of the V
become the input to the next step, and are also fed back to the preceding step for iteration
where appropriate, until the final code is created. This code is verified against the
corresponding design through post-layout simulation, module testing, module integration
testing and verification of the complete ASIC. The results of any step may necessitate a
revision to any of the preceding steps. Finally, the ASIC is validated after its integration
into the E/E/PE safety-related system.

26
Al di là di modifiche “cosmetiche”, le seguenti sono quelle principali:
1. I requisiti di progettazione sono applicabili anche per ASICs
2. Vengono definiti i requisiti per “on-chip redundancy” con criteri per ottenere
sufficiente indipendenza tra i canali, e metodi per valutare il fattore β di guasti di
causa comune (si veda nel seguito)

27
Nell’edizione 2010 della norma IEC 61508, i due approcci (“progettazione secondo
norma”” e “proven
“ in
i use”)
”) sono nettamente
tt t distinti
di ti ti ma, come vedremo,
d a sfavore
f d
dell
metodo semplicemente “proven in use” (il tutto in parte bilanciato dalla “sottile” modifica
alle definizioni di “elementi” di “Tipo A” e “Tipo B”).

28
NOTE 1 The systematic capability of an element determines the potential for systematic
f lt off that
faults th t element
l t to
t lead
l d to
t a failure
f il off the
th safety
f t function.
f ti The
Th conceptt off systematic
t ti
capability of an element is applicable to both hardware and software elements.
NOTE 2 Subclause 7.6.2.7 of IEC 61508-1 recognises the value of independence and
diversity at the level of a safety function and the E/E/PE safety related systems to which it
could be allocated. These concepts can also be applied at the detailed design level where
an assembly of elements implementing a safety function can potentially achieve a better
systematic performance than the individual elements.

La procedura illustrata è un po’ cervellotica, ma in sintesi vuol dire questo:

a. Caso di elementi in serie: la massima “Systematic Capability” raggiungibile è data
dall’elemento con la SC più bassa
b. Caso di elementi in parallelo: es.: 1oo2(D), in cui ciascun canale ha SC=2: la norma
consente che la combinazione di due canali in parallelo con SC possa portare come
risultato a SC+1 (ovvero, nell’esempio, a SC=3), posto che sia dimostrabile una
adeguata diversità e indipendenza tra i canali, secondo la definizione riportata nella
parte 1 della norma:
… such that the likelihood of simultaneous failures between two or more of these different
systems or measures is sufficiently low in relation to the required safety integrity

29
Nuovamente, le strade “progettazione secondo norma” e “proven in use” divergono in
maniera
i netta.
tt
Seguendo la strada 2H, si seguono le solite due tabelle relative a HFT e SFF, che
forniscono il massimo SIL raggiungibile (per un elemento) in funzione di requisiti di
architettura e requisiti di SFF, mentre nel caso di elementi “proven in use” i requisiti di
HFT sono svantaggiosi, per una asserita congruenza con la IEC 61511.

30
La modifica alle definizioni è questa:
• perché un “elemento” possa essere classificato di Tipo A, non è più necessario che la
sua “affidabilità” sia supportata da “esperienza di campo”.

In pratica, la distinzione è ora tra “elementi” “semplici”, che includono solo componenti
meccanici/idraulici/pneumatici e/o elettrici/elettronici non programmabili (Tipo A) e
“complessi”, ovvero che includono almeno un componente elettronico programmabile .

NOTA: per componentiti non elettronici

NOTA l tt i i programmabili,bili pur essendo
d svantaggiosa
t i
l’opzione meramente “proven in use”, la classificazione in Tipo A, più vantaggiosa per
quello che riguarda i requisiti di architettura, è ora praticamente automatica.

31
La nuova edizione della norma specifica quando la diagnostica è da considerare efficace
o meno.
Il primo alinea di cui sopra è valido per HFT=0, per applicazioni High Demand Mode o
continuous Mode.
Il secondo alinea è valido sempre in HFT=0, e per applicazioni High Demand Mode (si
fissa un valore massimo per il Test Interval Diagnostico, rispetto alla frequenza stimata
dell’evento pericoloso).

32
In questo punto s fissa una relazione tra TID/2, MRT e MTTR, ovvero TID/2+MRT<MTTR
di hi t
dichiarato
valido per:
a. HFT>0, per applicazioni High Demand Mode o Continuous Mode
b. applicazioni Low Demand Mode

33
La procedura per la strada 1H (determinazione del massimo SIL dichiarabile secondo
requisiti
i iti di architettura
hit tt e SFF) è lla seguente:
t
1. Determinare i sottosistemi componenti il sistema di sicurezza
2. Determinare il SFF per tutti gli elementi dei sottosistemi
3. Per ciascun elemento, determinare il massimo SIL raggiungibile, utilizzando le tabelle
per elementi di Tipo A e Tipo B
4. Determinare il massimo SIL raggiungibile dal sistema, dalle combinazioni serie e
parallelo dei singoli elementi:
a. C bi
Combinazioni
i i serie:
i a pesare di più
iù è “th
“the weakest
k t link
li k iin th
the chain”
h i ”
b. Combinazioni parallelo: in questo caso vale il discorso fatto per “Systematic
Capability” di canali in parallelo (vedi slide relativa), e il punto 2 qui sopra,
ove dice: In the case of redundant element configurations, the SFF may be
calculated by taking into consideration the additional diagnostics that may be
available (e.g. by comparison of redundant elements). Ovvero, in caso di
configurazioni ridondanti, la SFF può essere significativamente più elevata
che nel canale singolo
5. Ovviamente, deve poi essere verificata la congruenza con la tabella del SIL
raggiungibile in funzione dei valori di PFDAVG e PFH

⇒ Esempi di combinazioni serie e parallelo

(Nota: la figura 6 sulla Parte 2 della norma è sbagliata)

34
La norma, seguendo un po’ pedissequamente la IEC 61511, sfavorisce “elementi”
“proven
proven in use
use”.
Infatti, anche se un elemento è di tipo A, per ottenere SIL 3 occorre almeno una
ridondanza, mentre nelle tabelle HFT/SFF per elementi di Tipo A, è possibile ottenere SIL
anche senza ridondanza.

7.4.4.3.3 If Route 2H is selected, then the reliability data used when quantifying the effect
of random hardware failures (see 7.4.5) shall be:
a) based on field feedback for elements in use in a similar application and
environment; and,
and
b) based on data collected in accordance with international standards (e.g., IEC
60300-3-2 or ISO 14224); and,
c) evaluated according to:
i) the amount of field feedback; and,
ii) the exercise of expert judgement; and where needed,
iii) the undertaking of specific tests;
in order to estimate the average g and the uncertainty y level ((e.g.,
g , the 90 %
confidence interval or the probability distribution (see Note 2)) of each reliability
parameter (e.g., failure rate) used in the calculations.

NOTE 1 End-users are encouraged to organize relevant component reliability data

collections as described in published standards.
If route 2H is selected, then the reliability data uncertainties shall be taken into account
when calculating the target failure measure (i.e. PFDavg or PFH) and the system shall be
improved until there is a confidence greater than 90 % that the target failure measure is
achieved.
hi d

35
Come visto nella slide precedente, la dimostrazione meramente “Proven in use” di un elemento è
sfavorevole in termini di architettura.
Altri requisiti per l’applicabilità del metodo “proven in use” sono i seguenti:

7.4.10.2 The documentary evidence required by 7.4.10.1 shall demonstrate that:

c) the previous conditions of use (see Note 1) of the specific element are the same as, or
sufficiently close to, those that will be experienced by the subsystem element in the E/E/PE
safety-related system;
NOTE 1 The conditions of use (operational profile) include all the factors that may influence the
likelihood of trigger systematic faults in the hardware and software of the subsystem element. For
example environment, modes of use, functions performed, configuration, interfaces to other
systems, operating system, translator, human factors. Rigorous conditions for similarity of
operational profile may be found in IEC 61784-3.
d) the
th ddangerous ffailure
il rate
t h
has nott b
been exceeded
d d iin previous
i use.
NOTE 2 See IEC 61508-7, Annex D, for guidelines on the use of a probabilistic approach to
determining software safety integrity for pre-developed software based on operational experience
NOTE 3 The collection of evidence for proven in use elements requires an effective system for
reporting failures.
7.4.10.4 A proven in use safety justification shall be documented, using the information available
from 7.4.10.2, that the element supports the required safety function with the required systematic
safety integrity. This shall include:
a) the suitability analysis and testing of the element for the intended application;
b)) the demonstration of equivalence
q between the intended operation
p and the pprevious
operation experience, including the impact analysis on the differences;
c) the statistical evidence.
7.4.10.6 There shall be satisfactory evidence that, the existing element’s functions that are not
covered by the proven in use demonstration, cannot adversely affect the safety integrity of the
element functions that are used.
NOTE This requirement can be achieved by ensuring that the functions are physically or electrically
disabled or that software to implement these functions is excluded from the operational
configuration, or by other forms of arguments and evidence.

36
Non ci sono modifiche sostanziali sulla valutazione guasti casuali, anche perché la norma
di d
dice davvero poco …

Rispetto alla norma edizione 2000 possono essere fatte le seguenti osservazioni:
• c’è un maggior rigore teorico nella trattazione dei tassi di guasto
• come in altri punti della norma, si fa riferimento ad “element” come “mattoncino
elementare”
• si continua a fare riferimento a “recognised industry source”, anziché a Failure Rate
Database
D t b come iin altre
lt norme ((ad d esempioi EN ISO 13849-1
13849 1 e EN 61800
61800-5-2):
5 2) sii ritiene
iti
comunque che una FME(D)A debba essere fatta a partire da valori di letteratura di
Failure Rates (di database), o valori specifici se disponibili, eventualmente integrati con
dati di laboratori e dati di campo (analisi Bayesiana)
• “application specific data” sono preferiti
• un riferimento utile per la valutazione del confidence level è la ISO 14224:2006
Petroleum, petrochemical and natural gas industries — Collection and exchange of
reliability and maintenance data for equipment, da utilizzare anche per la raccolta dati dal
campo

37
Elementi di Tipo A che seguono la strada 1H: per ottenere SIL 3 può
ragionevolmente non essere necessaria la ridondanza.

38
Elementi di Tipo B che seguono la strada 1H: per ottenere SIL 3 può
ragionevolmente essere necessaria la ridondanza.

39
Strada “Proven in use”: svantaggiosa in termini di architettura.

40
La tabella di cui sopra è valida per il sistema completo, anzi, per la
“Funzione Strumentata di Sicurezza”.

41
Sono state mantenute le tabelle per controllare i guasti, con riferimento a:
a. Tecniche e misure per controllare guasti causati dalla progettazione
b. Tecniche e misure per controllare guasti causati da stress e influenze ambientali
c. Tecniche e misure per controllare guasti durante il funzionamento

Ove “to control” sta per “contenere”, “tenere sotto controllo”

Stesso discorso vale per le tabelle da B B.1

1aB
B.5,
5 per evitare guasti sistematici,
sistematici con
riferimento alle varie fasi del ciclo di vita.

In entrambi i casi vi sono piccole modifiche, che tengono conto anche delle modiifche a
“importanza” ed “efficacia”

42
Per la valutazione dell’integrità sistematica, è stato introdotto il requisito di obbligatorietà
(M d t ) per alcune
(Mandatory) l d
delle
ll ttecniche/misure.
i h / i

Di conseguenza, “Mandatory” è stato eliminato tra i livelli di efficacia (oltretutto la sua

definizione aveva poco senso).

È stato mantenuto il requisito di obbligatorietà di utilizzo di almeno una delle tecniche in

grigio (e in nero) nelle tabelle.

43
44
45
46
47
48
49
Oltre all’applicazione del ciclo di sviluppo a V, gli ASICs devono essere progettati e
realizzati
li ti seguendo
d ttecniche
i h / misure
i d
descritte
itt in
i massimo
i dettaglio
d tt li nell’Allegato
ll’All t F
(informativo).

NOTA: Il punto b) di cui sopra include:

• application of the individual tool (including different versions with equivalent features)
over a substantial period of time in projects of similar or greater complexity;
• application of common or widely used tools to ensure that information about possible
bugs and restrictions is known for the given tool and/or the given version,
version which should be
considered during use. Version control and monitoring should be carried out by the
manufacturers to track existing faults
• internal consistency and plausibility checks to avoid faults in the different databases
created by different tools.

50
51
Il Safety Manual è quindi requisito obbligatorio per “elementi” che si voglia dichiarare
conformi
f i alla
ll norma, e può
ò essere richiesto
i hi t aii costruttori
t tt i ddaglili iintegratori
t t i di sistema.
i t

Il Safety Manual non è sufficiente, ma deve essere supportato da sufficienti evidenze,

come ad es.:
a. Certificati di Parte Terza
b. Reports (ad esempio Safety Analysis Reports stesi secondo OLF 070, o similari)

52
Contenuto del Safety Manual – HW
a. Identificazioni delle Funzioni di Sicurezza (a livello di elemento)
b. Identificazione delle configurazioni HW/SW (ad es. per Logic Solvers)
c. Limitazioni di utilizzo (condizioni ambientali (temperatura, umidità), vibrazioni,
elettromagnetiche, dichiarazione, Grado IP, possibilità di utilizzo in ambienti
classificati ATEX, etc.)
d. Lifetime garantito, per cui si garantiscono i valori di Failure Rates

53
Contenuto del Safety Manual – HW
Da e) a j):
• modi di guasto dell’elemento con relativi tassi di guasto e possibilità di diagnostica
interna, e relativo Test Interval Diagnostico
• modi di guasto della diagnostica interna con relativi tassi di guasto

Questo secondo punto secondo me è discutibile ed in ogni caso incluso nel computo del
DC, ma la norma lo chiede.

54
Contenuto del Safety Manual – HW
k. Per ciascun modo di guasto dell’elemento, diagnosticato da diagnostica interna,
l’output fornito dalla diagnostica stessa
l. Requisiti di Proof Test periodico (per il mantenimento nel tempo di PFDAVG) e
manutenzione periodica (per il mantenimento nel tempo dei tassi di guasto)
m. Per ciascun modo di guasto dell’elemento, diagnosticabile da diagnostica esterna,
informazioni sulla DC (Copertura Diagnostica) raggiungibile
n. HFT
o. Cl
Classificazione
ifi i come Tipo
Ti A o Tipo
Ti B

55
Contenuto del Safety Manual – HW
p. La Systematic Capability
q. Eventuali restrizioni per il raggiungimento della Systematic Capability

56
57
58
In realtà, nessuna modifica sostanziale: viene focalizzata l’attenzione su:
“E/E/PE Systems”.

59
Sono state meglio chiarite la seconda e la terza fase del ramo di risalita
del modello a V di sviluppo SW, fasi che non erano ben chiare
nell’edizione 2000.

60
Vengono aggiunti requisiti relativi all’indipendenza del SW.

Tali requisiti devono essere specificati nella specifica di sicurezza del SW, in aggiunta ai
requisiti per comunicazioni safety-related.

Anche per il SW, viene introdotto il concetto di “Systematic Capability” (che è l’unico di cui
si parla, non avendo il SW guasti casuali …).

61
Viene data maggior e importanza, in sede di definizione delle specifiche, a:
• coerenza e consistenza dei dati
• tempi di risposta (inclusi best case e worst case execution time)
• overflow e underflow di capacità di immagazzinamento dati

Vale anche quanto segue:

7.2.2.13 Operational parameters shall be protected against:
k) invalid
invalid, out of range or untimely values;
l) unauthorized changes;
m) corruption.

62
Viene meglio specificato il requisiti di automonitoraggio di flusso di controllo e flusso dati.

Per quello che riguarda la combinazione (serie e parallelo) di elementi SW con

Systematic Capability definita, vale quanto riportato nella IEC 61508-2.

63
Viene meglio precisato il comportamento da tenere in caso di elementi SW pre-esistenti
(l norma edizione
(la di i 2000 iipotizzava
ti che
h sii iiniziasse
i i sempre llo sviluppo
il seguendo
d lla
norma).

La strada suggerita è, anche in questo caso, come nel caso HW, la 1S,che consiste in
sintesi in quanto segue:
• Verificare che durante lo sviluppo sia stato seguito il ciclo di sviluppo a V della norma
• verificare che siano state applicate adeguate tecniche e misure per controllare ed
evitare guasti SW

64
In caso il SW pre-esistente non sia stato sviluppato secondo la norma, si può seguire la
strada
t d 3S3S.

In sintesi, si tratta di riprodurre e verificare “ex-post” la conformità alla norma:

1. Documentando le Specifiche di Sicurezza SW come se si partisse dall’inizio
2. Documentare che tutte le fasi del ciclo a V sono comunque state soddisfatte nella
sostanza
3. Documentare test e verifiche sulle varie fasi
4. Predisporre Safety Manual per il SW

65
66
67
NOTE 2 Appropriate off-line tools to support the development of software should be used
i order
in d tto iincrease th
the integrity
i t it off the
th software
ft by
b reducing
d i theth likelihood
lik lih d off iintroducing
t d i
or not detecting faults during the development.
Examples of tools relevant to the phases of the software development lifecycle include:
a) transformation or translation tools that convert a software or design representation (e.g.
text or a diagram) from one abstraction level to another level: design refinement tools,
compilers, assemblers, linkers, binders, loaders and code generation tools;
b) verification and validation tools such as static code analysers, test coverage monitors,
theorem proving assistants, and simulators;
c) diagnostic tools used to maintain and monitor the software under operating conditions;
d) infrastructure tools such as development support systems;
e) configuration control tools such as version control tools;
f) application data tools that produce or maintain data which are required to define
parameters and to instantiate system functions. Such data includes function parameters,
instrument ranges, alarm and trip levels, output states to be adopted at failure,
geographical layout.
NOTE 3 Off-line support tools should be selected to be integrated. In this context, tools
are integrated if they work co-operatively such that the outputs from one tool have
suitable content and format for automatic input to a subsequent tool, thus minimising the
possibility of introducing human error in the reworking of intermediate results.
NOTE 4 Off-line support tools should be selected to be compatible with the needs of the
application, of the safety related system, and of the integrated toolset.
NOTE 5 The availability of suitable tools to supply the services that are necessary over
the whole lifetime of the E/E/PE safety-related system (e.g. tools to support specification,
g , implementation,
design, p , documentation,, modification)) should be considered.

68
69
70
Come nell’edizione 2000, viene fatto riferimento a tabelle di tecniche e misure per la
rispondenza
i d alla
ll SSystematic
t ti Capability
C bilit (All
(Allegato
t AA: ttabelle
b ll generali;
li All
Allegato
t BB: ttabelle
b ll di
dettaglio).
Come anche nella parte 2, sono state introdotte alcune modifiche alle tabelle.

La modifica sostanziale riguarda però il riferimento all’Allegato C, per fornire indicazioni

maggiormente dettagliate su come rispondere ai requisiti.
In questo modo la norma vuole diminuire la soggettività della conformità del SW alla
Systematic Capability”
“Systematic Capability .

Scopo dell’Annex C (informativo) è:

– to give guidance on selecting specific techniques from Annexes A and B to achieve
software systematic capability;
– to outline a rationale for justifying the use of techniques that are not explicitly listed in
Annexes A and B.
Annex C is supplementary to Annexes A and B tables
tables.

71
72
73
74
4) Infine, questa tabella fornisce indicazioni (con uno score indicativo) dell’efficacia delle
varie
i ttecniche
i h con riferimento
if i t alle
ll proprietà
i tà analizzate.
li t

Lo stesso viene applicato per tutte le fasi del SW Safety LifeCycle.

75
76
Contenuti del Safety Manual per quello che riguarda il SW (nota: ove applicabili, alcuni
requisiti
i iti solo
l per SW applicativo):
li ti )
a. Livello di competenza necessario per l’integratore
b. Livello di “confidenza” sull’elemento SW:
• Certificazioni
• Norme applicate nello sviluppo
• Alte informazioni necessarie per l’integratore

77
Contenuti del Safety Manual per quello che riguarda il SW:
c. Istruzioni di installazione
d. Motivazioni di release
e. Anomalie non risolte, in sospeso
f. Compatibilità con versioni precedenti

78
Contenuti del Safety Manual per quello che riguarda il SW:
g. Compatibilità con altri sistemi
h. Configurazione SW
i. Controllo e richiesta modifiche

79
Contenuti del Safety Manual per quello che riguarda il SW:
k. Stato sicuro di progetto
l. Limitazioni di interfaccia
m. Dettagli su misure di sicurezza da intraprendere
n. Metodi di configurazione degli elementi

80
81
82
83
Come si vedrà in seguito, si focalizza l’attenzione sulla responsabilità e competenza delle
persone coinvolte
i lt nella
ll gestione
ti d
della
ll Si
Sicurezza FFunzionale.
i l

84
85
Viene data maggiore enfasi al livello di competenza necessario e ad eventuali qualifiche,
con particolare
ti l riferimento
if i t alla
ll Si
Sicurezza FFunzionale
i l

86
87
La fase 11 va a conglobare due fasi in precedenza esistenti.
Viene evidenziata la fase 9: E/E/PE System Safety Requirements Specification.

88
8.2.16 In the context of Tables 4 and 5, only cells marked X, X1, X2 or Y shall be used as
a basis
b i ffor ddetermining
t i i ththe llevell off iindependence.
d d F
For cells
ll marked
k d X1 or X2
X2, either
ith X1 or
X2 is applicable (not both), depending on a number of factors specific to the application.
The rationale for choosing X1 or X2 should be detailed. Factors that will make X2 more
appropriate than X1 are:
– lack of previous experience with a similar design;
– greater degree of complexity;
– greater degree of novelty of design;
– greater degree of novelty of technology
technology.

89
8.2.17 In the context of Table 4, the consequence values for the specified level of
independence are:
– Consequence A: minor injury (for example temporary loss of function);
– Consequence B: serious permanent injury to one or more persons, death to one
person;
– Consequence C: death to several people;
– Consequence D: very many people killed.
The consequences specified in Table 4 are those that would arise in the event of failure of
all the risk reduction measures including the E/E/PE safety-related systems.

90
91
92
93
94
95
96
97
98