Ultima modifica: 30/03/2026
Sommario
Questo articolo è parte di una serie di articoli sulla sicurezza funzionale dei macchinari. Abbiamo recentemente introdotto uno dei due standard utilizzati per la progettazione di sistemi di controllo di sicurezza ad alta richiesta: la ISO 13849-1. Presentiamo ora gli aspetti chiave della IEC 62061. Nella precedente edizione di TUTTOMISURE abbiamo presentato le Architetture A e B; ora descriveremo in dettaglio l’Architettura C: l’equivalente della Categoria 2 della ISO 13849-1, ovvero un singolo canale con diagnostica.
Basic Subsystem Architecture C: 1oo1D
In questa Architettura, a singolo canale con diagnostica, qualsiasi guasto pericoloso non rilevato di un elemento del sottosistema comporta un guasto pericoloso della funzione di sicurezza. Quando viene rilevato un guasto di un elemento del sottosistema, la funzione diagnostica avvia una fault reaction. Questa architettura corrisponde a una Hardware Fault Tolerance (HFT) pari a 0.
Questa Architettura corrisponde alla Categoria 2 della norma ISO 13849-1; nella figura 2 è riportata una rappresentazione più precisa.
Si noti che la TE (Test Equipment) di Categoria 2 nella norma ISO 13849-1 è definita come Fault Diagnostic Function nella norma IEC 62061. Analogamente, l’equivalente dell’OTE è la Fault Reaction Function. La combinazione TE + OTE è definita come Fault Handling Function nella norma IEC 62061.
Condizioni per la Corretta implementazione della Basic Subsystem Architecture C
Per l’Architettura C, il calcolo del PFH presuppone una gestione dei guasti ottimale nel tempo. La Time optimal fault handling di un elemento del sottosistema può essere presupposta se è soddisfatta una delle seguenti condizioni:
- Il diagnostic rate è almeno un fattore 100 superiore al demand rate della funzione di sicurezza e il tempo necessario per la fault reaction è sufficientemente breve da portare il sistema in uno stato sicuro, prima che si verifichi un evento pericoloso; oppure
- La fault handling viene eseguita immediatamente su qualsiasi potenziale richiesta della funzione di sicurezza e il tempo necessario per rilevare un errore rilevabile e per portare il sistema in uno stato sicuro è inferiore al tempo di sicurezza del processo; oppure
- La fault handling viene eseguita in modo continuo e il tempo necessario per rilevare un errore rilevabile e per portare il sistema in uno stato sicuro è inferiore al tempo di sicurezza del processo; oppure
- La gestione degli errori viene eseguita periodicamente e la somma dell’intervallo di prova, del tempo necessario per rilevare un errore rilevabile e del tempo necessario per portare il sistema in uno stato sicuro è inferiore al tempo di sicurezza del processo.
Nella tabella 1 sono riassunte tutte le possibili condizioni relative ad una corretta implementazione di un’architettura 1oo1D.
- Situazione 1 e 3. Se non è possibile raggiungere uno stato sicuro, indipendentemente dal fatto che esista o meno una optimal testing frequency, non possiamo affermare di avere un’architettura 1oo1D. Pertanto, ritorniamo a un’architettura 1oo1, in cui è necessario utilizzare well-tried components.
La differenza con la norma ISO 13849-1, nel caso della Situazione 3, è dovuta al collegamento tra la norma IEC 62061 e la norma IEC 61508.
[IEC 61508-2] 7.4.8 Requirements for system behaviour on detection of a fault
7.4.8.3 The detection of a dangerous fault (by diagnostic tests, proof tests or by any other means) in any subsystem having a hardware fault tolerance of 0 shall, in the case of a subsystem that is implementing any safety function(s) operating in the high demand or the continuous mode, result in a specified action to achieve or maintain a safe state (see Note).
NOTE: The specified action required to achieve or maintain a safe state will be specified in the E/E/PE system safety requirements (see IEC 61508-1, 7.10). It may consist, for example, of the safe shut-down of the EUC, or that part of the EUC that relies, for functional safety, on the faulty subsystem.
- Situazione 2. Non è presente alcun optimal testing; tuttavia, in caso di rilevamento di un guasto, possiamo riportare il sistema in uno stato sicuro. Possiamo affermare di avere Basic Subsystem Architecture 1oo1D e raggiungere SIL 2, se sussistono tutte le altre condizioni. Non è necessario utilizzare well-tried components.
- Situazione 4. Disponiamo di optimal testing e, in caso di rilevamento di un guasto, possiamo riportare il sistema in uno stato sicuro. Possiamo affermare di avere Basic Subsystem Architecture 1oo1D e raggiungere SIL 2, se sussistono tutte le altre condizioni. Non è necessario utilizzare well-tried components.
Si tratta di un’architettura “delicata”, simile alla Categoria 2. Il problema è il guasto della Diagnostic Function, chiamata Fault handling Function, mentre il canale funzionale è ancora attivo. La Fault Handling function include sia la Fault Diagnostics guasti che la funzione di Fault Reaction.
Basic Subsystem Architecture C con Fault Handling realizzato dal SCS
Questa è la situazione più semplice, poiché le Diagnostic e Fault Reaction Functions (equivalenti a TE e OTE nella norma ISO 13849-1) fanno già parte della funzione di sicurezza. La Fault Handling Function è completamente svolta da un sottosistema separato del SCS, che è anch’esso coinvolto nell’esecuzione della funzione di sicurezza, contribuendo così al suo PFH.
In altri termini, in questo caso possiamo ignorare l’affidabilità del canale di monitoraggio poiché questa viene già presa in considerazione durante il calcolo dell’affidabilità del canale funzionale.
Questo potrebbe essere il caso in cui un Safety-related Control System monitora se un contattore del motore si è aperto e, in caso di guasto, disattiva un altro contattore, che fa parte di un’altra funzione di sicurezza.
Se consideriamo un sottosistema C, composto da n elementi numerati da 1 a n, il PFH è dato dalla seguente formula:
Come si può vedere, l’affidabilità della Fault Handling Function (o monitoring function) non è presente nella formula. Si tratta della stessa formula utilizzata nella prima edizione dello standard.
Basic Subsystem Architecture C con mixed Fault Handling
In tutti questi casi, l’affidabilità del canale di monitoraggio, o meglio, della funzione di gestione dei guasti, è al di fuori della funzione di sicurezza. Per calcolare il PFH di questa architettura, è necessario introdurre un nuovo tasso di guasto: il tasso di guasto della Fault Handling Function, o λD-FH.
Per arrivare alle diverse formule PFH è stato utilizzato un modello di Markov.
Ci sono 3 possibili situazioni:
- Il sottosistema C ha una External Fault Diagnostics (TE), ma l’elemento che esegue la Fault Reaction (sarebbe l’OTE nella categoria 2 della norma ISO 13849-1) è interno al sottosistema.
In questo caso il tasso di guasto della fault handling function include solo la Fault Reaction function.
Ciò significa λD-FH= λD-FR
Il tasso di guasto della Fault Reaction function non viene preso in considerazione poiché è già preso in considerazione durante il calcolo dell’affidabilità del canale funzionale.
2. Il sottosistema C è dotato di External Fault Reaction (OTE), mentre la Fault Diagnostic (TE) viene eseguita internamente al sottosistema.
In questo caso, il tasso di guasto della gestione dei guasti include solo la funzione Fault Diagnostic.
Ciò significa che λD-FH= λD-FD
Il tasso di guasto della Fault Reaction non viene considerato poiché è già preso in considerazione durante il calcolo dell’affidabilità del canale funzionale.
3. Il sottosistema C è dotato sia di Fault Diagnostics che Fault Reaction interne al sottosistema.
In questo caso, il tasso di guasto della gestione dei guasti include sia la funzione diagnostica che quella di reazione ai guasti.
Ciò significa λD-FH = λD-FD + λD-FR
PFH in caso di quattro condizioni soddisfatte
In tutti e tre i casi precedentemente descritti, esiste una semplice equazione che può essere utilizzata per calcolare il valore PFH, a condizione che siano soddisfatte tutte le seguenti condizioni:
- β ≤ 2 %;
- DC ≤ 99 %;
- 1/λDe ≤ 1.000 years;
- 1/ λD-FH ha almeno il valore minimo Tabella 2 {7.2.4.1};
dove λD-FH è il tasso di guasto del singolo elemento che realizza la Fault Handling Function all’interno del sottosistema.
L’equazione è la seguente:
Se il canale funzionale ha più di un elemento, il DC correlato viene calcolato utilizzando la seguente formula.
PFH in Caso una delle Quattro Condizioni non sia Soddisfatta
Nel caso in cui una delle quattro condizioni sopra indicate non sia soddisfatta, la formula semplificata non può essere utilizzata, poiché potrebbe fornire un valore di PFH inferiore e quindi fornire un’affidabilità maggiore rispetto alla realtà.
Se il canale funzionale è composto da un solo elemento e la Fault Handling Function, all’interno del sottosistema, è realizzata da un altro singolo elemento, è possibile utilizzare la seguente equazione:
Dove:
- T1 è il minore tra Proof Test interval of the perfect Proof Test e useful lifetime;
- 𝜆De è il tasso di guasto pericoloso del singolo elemento del canale funzionale;
- 𝜆D-FH è il tasso di guasto del singolo elemento che realizza la/le Fault Handling Function(s) all’interno del sottosistema;
- DC è la copertura diagnostica per il singolo elemento e del canale funzionale;
- β è la suscettibilità ai common cause failures del canale funzionale e del canale che realizza la/le Fault Handling Function(s) all’interno del sottosistema.
La stessa equazione può essere utilizzata anche nel caso in cui siano soddisfatte tutte e quattro le condizioni di cui sopra, è la formula generale per l’Architettura C, è sempre valida.
Si può notare che, nel caso in cui il tasso di guasto pericoloso delle Fault Handling Functions all’interno del sottosistema possa essere assunto pari a zero (𝜆D-FH = 0), l’equazione diventa la stessa di quella in § 7.2.6.1. Il motivo è ovvio: si presume che il canale di monitoraggio abbia un’affidabilità molto elevata.
Si tenga presente che la formula generale può essere utilizzata anche se l’affidabilità della Fault Handling Function è peggiore di quella richiesta dalla Tabella 2.
Implicazioni dei Vincoli di Architettura nella Basic Subsystem Architecture C
I sottosistemi di Architettura C hanno un HFT = 0. Ciò significa che, in base all’SFF, è possibile raggiungere un SIL massimo pari a 3. Tuttavia, è importante verificare che sia soddisfatta una delle seguenti condizioni:
- la somma dell’intervallo del test diagnostico e del tempo impiegato per eseguire la Fault Reaction al guasto specificata per raggiungere o mantenere uno stato sicuro deve essere inferiore al tempo di sicurezza del processo (ad esempio, vedere ISO 13855);
- Oppure, il rapporto tra la frequenza dei test diagnostici e la frequenza della domanda deve essere uguale o superiore a 100. Quest’ultima condizione allinea l’Architettura 1oo1D alla Categoria 2.
Pertanto, un sottosistema a singolo canale monitorato (1oo1D), in cui nessuna delle due condizioni è soddisfatta, deve essere considerato Basic Subsystem Architecture A (1oo1); fare riferimento alla Tabella 7.8.
La tabella 3 può essere applicata. Normalmente SFF < 99%, poiché SFF ≥ 99% è possibile solo quando c’è un monitoraggio continuo del corretto funzionamento dell’elemento: in genere, possibile solo con tecnologia elettronica.
Esempio di una Basic Subsystem Architecture C
Consideriamo il sottosistema di uscita come mostrato in Figura 7. KP ha B10 = 106 con il 73% come percentuale di guasti pericolosi. “U<” ha un B10 = 4·105. Il Mission Time sia del contattore che della bobina di minima tensione è di 20 anni.
KP dovrebbe aprirsi due volte al minuto mentre “U< “ dovrebbe aprirsi una volta al mese.
Concentriamoci ora sul calcolo della probabilità di guasti casuali.
- Il primo passo è calcolare il 𝜆D del contattore KP. Supponendo che la macchina funzioni 240 giorni all’anno e otto ore al giorno.
2. Il secondo passaggio consiste nel calcolare T1 e β.
T1=min (Useful Life; Proof Test);
Useful Life= min (Mission Time; T10D);
Mission Time = 20 years;
Useful Life = min (20 years; 5,9 years) à Useful Life = 5,9 years;
Proof Test > 20 years
T1 = min (5,9 years ; > 20 years) àT1 = 5,9 years = 52 560 hours;
Sulla base dei criteri CCF elencati nell’Allegato E della norma, possiamo supporre un β = 0,02.
3. Il terzo passaggio è la determinazione della Diagnostic Coverage. Trattandosi di un singolo canale con un elemento di test che monitora direttamente lo stato del KP, ipotizziamo DC = SFF = 90%.
4. Ora, dobbiamo verificare che il valore 𝜆D-FH del canale di test non sia inferiore a quello specificato nella Tabella 2. In questo caso, il canale funzionale e il canale di test hanno in comune il PLC di sicurezza, in altri termini, ci troviamo nella situazione della figura 4: External Fault Diagnostic. La Fault Reaction (bobina di minima tensione) è considerata parte del sottosistema di output, mentre la Fault Handling non lo è, poiché la sua affidabilità è già considerata nel calcolo dell’affidabilità del canale funzionale, che include la logica di sicurezza. Per questo motivo, solo il tasso di guasto della bobina di minima tensione è importante per il 𝜆D-FH.
“U<” viene utilizzato solo quando viene rilevato un guasto, una volta al mese:
Poiché affermiamo una DC del 90%, in base alla tabella 2, il valore minimo di 1/𝜆D-FH è 1200.
In questo caso 1/𝜆DU< è molto più alto di quanto richiesto nella tabella 2: la condizione è soddisfatta;
5. L’ultimo passaggio è calcolare il PFH
Tutte le seguenti condizioni sono soddisfatte:
- β ≤ 2 %;
- DC ≤ 99 %;
- 1/ 𝜆𝐷𝑒 =1/ 𝜆𝐷KP = 1/1,92 x 10-6 8760 = 59,5 < 1.000 years;
- 1/ 𝜆D-FH =1/ 𝜆DFR =1/ 𝜆DU< = 333 333 > 1200 years;
Pertanto, è possibile utilizzare l’equazione semplificata.
Con un SFF = 90% e un HFT = 0, il livello SIL è limitato dai vincoli architettonici a SIL 2.
Il Sottosistema di Sicurezza raggiunge SIL 2 e ha un PFH = 1,92 10-7.
