È 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 lt ( d i l’ di i CENELEC d ll t h h i d dialtre (ad esempio l’edizione CENELEC della stessa, che ha un periodo 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 5 2 si veda il punto 2 Normative References cheLo stesso vale anche per la EN 61800-5-2, si veda il punto 2 Normative 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 della EN 62061 sono invece datati, per cui la nuova edizione dellaI riferimenti 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 iti i” h d bb i t ti i S f t I t t d S t l’i d t idi dispositivi” che debbano essere integrati in Safety Instrumented Systems per l’industria 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 system7.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 functionality defined by the product developer.y y p 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 by a programmable interconnection matrix (crossbar).y p g ( )

11

Per conformarsi alla IEC 61511, la norma parla di “altre misure per la riduzione del i hi ” i il bili li “ lt i li lli di t i ” d ll IEC 61511rischio”, assimilabili agli “altri livelli di protezione” della IEC 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:S i / t d tt i di• Sensori / trasduttori 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 completo2. 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 i di l i di f il t i d i iti di PFD PFH) llinumerica di valori di failure rate, e rispondenza a requisiti di PFDAVG e PFH) e quelli

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 i iti di i t ità di f i lità)includono requisiti di integrità e di funzionalità).

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 specificataprogettazione per realizzare la funzione di sicurezza così come 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 related system is greater than one per year or greateroperation made on a safety-related system is greater than one per year or greater than twice the proofcheck frequencyNOTE 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 a1. È 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 tt tt di t ie, soprattutto, di guasto sicuro.

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

ll’i l t f i di inell’implementare una funzione di sicurezza2. 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 sicurezza2. 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 …”

ò i bl ti h di i t t i d l t tpuò ingenerare problematiche di interpretazione, e deve essere valutato caso per caso

La norma quindi “favorisce” ancora di più sistemi nei quali i guasti sono :a. rilevati, oppureb. 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 errors are listed in Table A 1 IEC 61508 2 as faults to be detected duringNOTE Soft-errors are listed in Table A.1, IEC 61508-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 2010 i l di MTTR MRTNell’edizione 2010 si parla di MTTR e 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 proof test needs some time to be achieved. During this time the E/E/PE safety p g yrelated 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 “it ” è d i t d i i i di “ l t”)(dove “item” è da intendersi sinonimo di “element”).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 ASICs2. 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 ” “ i ”) tt t di ti ti d f d lnorma” e “proven in use”) sono nettamente distinti ma, come vedremo, a sfavore del

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 f th t l t t l d t f il f th f t f ti Th t f t tifaults of that element to lead to a failure of the safety function. The concept of systematic 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ù bassab. 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: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 i ttmaniera netta.

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 ti l tt i i bili d t iNOTA: per componenti non elettronici programmabili, pur essendo svantaggiosa 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 tdichiaratovalido per:a. HFT>0, per applicazioni High Demand Mode o Continuous Modeb. applicazioni Low Demand Mode

33

La procedura per la strada 1H (determinazione del massimo SIL dichiarabile secondo i iti di hit tt SFF) è l trequisiti di architettura e SFF) è la seguente:

1. Determinare i sottosistemi componenti il sistema di sicurezza2. Determinare il SFF per tutti gli elementi dei sottosistemi3. Per ciascun elemento, determinare il massimo SIL raggiungibile, utilizzando le tabelle

per elementi di Tipo A e Tipo B4. Determinare il massimo SIL raggiungibile dal sistema, dalle combinazioni serie e

parallelo dei singoli elementi:C bi i i i di iù è “th k t li k i th h i ”a. Combinazioni serie: a pesare di più è “the weakest link in the chain”

b. Combinazioni parallelo: in questo caso vale il discorso fatto per “SystematicCapability” 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 diconfigurazioni ridondanti, la SFF può essere significativamente più elevatache 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 in use”proven in 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; andenvironment; 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 and the uncertainty level (e.g., the 90 % g y ( g , %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

hi dachieved.

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) th d f il t h t b d d i id) the dangerous failure rate has not been exceeded in previous 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 experienceNOTE 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 between the intended operation and the previous ) q p poperation 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 ddice 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 D t b i lt ( d i EN ISO 13849 1 EN 61800 5 2) i itiDatabase come in altre norme (ad esempio EN ISO 13849-1 e EN 61800-5-2): si ritiene 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 progettazioneb. Tecniche e misure per controllare guasti causati da stress e influenze ambientalic. 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 1 a B 5 per evitare guasti sistematici conStesso discorso vale per le tabelle da B.1 a B.5, per evitare guasti 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 ) l d ll t i h / i(Mandatory) per alcune delle tecniche/misure.

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 li ti d t i h / i d itt i i d tt li ll’All t Frealizzati seguendo tecniche / misure descritte in massimo dettaglio nell’Allegato 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 which should bebugs and restrictions is known for the given tool and/or the given 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 f i ll ò i hi t i t tt i d li i t t i di i tconformi alla norma, e può essere richiesto ai costruttori dagli integratori di sistema.

Il Safety Manual non è sufficiente, ma deve essere supportato da sufficienti evidenze, come ad es.:a. Certificati di Parte Terzab. Reports (ad esempio Safety Analysis Reports stesi secondo OLF 070, o similari)

52

Contenuto del Safety Manual – HWa. 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 – HWDa 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 – HWk. Per ciascun modo di guasto dell’elemento, diagnosticato da diagnostica interna,

l’output fornito dalla diagnostica stessal. 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) raggiungibilen. HFT

Cl ifi i Ti A Ti Bo. Classificazione come Tipo A o Tipo B

55

Contenuto del Safety Manual – HWp. La Systematic Capabilityq. 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 out of range or untimely values;k) 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 di i 2000 i ti h i i i i l il d l(la norma edizione 2000 ipotizzava che si iniziasse sempre lo sviluppo seguendo la 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 SWevitare guasti SW

64

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

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’inizio2. Documentare che tutte le fasi del ciclo a V sono comunque state soddisfatte nella

sostanza3. Documentare test e verifiche sulle varie fasi4. 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 d t i th i t it f th ft b d i th lik lih d f i t d iin order to increase the integrity of the software by reducing the likelihood of introducing 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, design, implementation, documentation, modification) should be considered.g , p , , )

68

69

70

Come nell’edizione 2000, viene fatto riferimento a tabelle di tecniche e misure per la i d ll S t ti C bilit (All t A t b ll li All t B t b ll dirispondenza alla Systematic Capability (Allegato A: tabelle generali; Allegato B: tabelle 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 tablesAnnex C is supplementary to Annexes A and B tables.

71

72

73

74

4) Infine, questa tabella fornisce indicazioni (con uno score indicativo) dell’efficacia delle i t i h if i t ll i tà li tvarie tecniche con riferimento alle proprietà analizzate.

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 i iti l SW li ti )requisiti solo per SW applicativo):

a. Livello di competenza necessario per l’integratoreb. 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 installazioned. Motivazioni di releasee. Anomalie non risolte, in sospesof. Compatibilità con versioni precedenti

78

Contenuti del Safety Manual per quello che riguarda il SW:g. Compatibilità con altri sistemih. Configurazione SWi. Controllo e richiesta modifiche

79

Contenuti del Safety Manual per quello che riguarda il SW:k. Stato sicuro di progettol. Limitazioni di interfacciam. Dettagli su misure di sicurezza da intraprenderen. Metodi di configurazione degli elementi

80

81

82

83

Come si vedrà in seguito, si focalizza l’attenzione sulla responsabilità e competenza delle i lt ll ti d ll Si F i lpersone coinvolte nella gestione della Sicurezza Funzionale.

84

85

Viene data maggiore enfasi al livello di competenza necessario e ad eventuali qualifiche, ti l if i t ll Si F i lcon particolare riferimento alla Sicurezza Funzionale

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 b i f d t i i th l l f i d d F ll k d X1 X2 ith X1a basis for determining the level of independence. For cells marked X1 or X2, either 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– greater degree of novelty of 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