Choose another country to see content specific to your location

//Select Country

Errori più frequenti sulla sicurezza funzionale

Aggiungere valore con il nostro portafoglio di servizi

EVITARE ERRORI NEI PROGETTI DI SICUREZZA FUTURI

TÜV SÜD ha più di 20 anni di esperienza nei test e nella certificazione di sistemi e componenti relativi alla sicurezza funzionale. Durante questo lungo periodo i nostri tecnici hanno avuto modo di osservare numerosi problemi ricorrenti derivanti da malintesi su alcuni concetti legati alla sicurezza funzionale. Qui di seguito, alcuni degli errori più interessanti di cui tutti dovrebbero essere consapevoli.

  1. PFH/PFD: necessario ma non sufficiente per un SIL (Safety Integrity LEVEL)

  2. Spesso i produttori si limitano a calcolare un valore PFD/PFH per il loro sistema o sottosistema e rivendicano successivamente un SIL per esso. Il PFH/PFD esprime la probabilità di un guasto pericoloso di un sistema (o sottosistema) di sicurezza per ora (PFH) o su richiesta (PFD). Entrambi i valori si riferiscono a guasti hardware casuali e di solito sono calcolati tramite analisi FMEDA. Il raggiungimento di uno specifico SIL (Safety Integrity Level) richiede non solo di controllare i guasti casuali dell'hardware ma anche di evitare e verificare i guasti sistematici nell'hardware e nel software. Quest'ultimo è espresso come Capacità Sistematica (SC, valori da 1 a 4, corrispondenti ai quattro valori SIL) e riflette i metodi e le tecniche utilizzate durante lo sviluppo del sistema di sicurezza. Pertanto, un SIL è sempre costituito da entrambi: PFD/PFH ed una determinazione della robustezza del suo processo di sviluppo, cioè l'SC.

  1. SIL non significa affidabilità del sistema di controllo

A volte i system integrator e i produttori di impianti richiedono ai loro fornitori sistemi di controllo per il normale funzionamento con un SIL, pensando che questo garantisca una certa affidabilità del sistema di controllo e/o dell'utilità. Ma lo scopo di una funzione di sicurezza (eseguita da un sistema di sicurezza) è di mettere un'apparecchiatura sotto controllo (EUC - Equipment Under Control) in uno stato di sicurezza per non aumentare la disponibilità.

Lo stato di sicurezza di un EUC è il risultato dell'analisi dei pericoli e dei rischi e dipende dalle sue diverse modalità operative. In questo contesto, si osservano spesso malintesi sulle strategie e sui concetti relativi agli scenari di sicurezza, ad esempio lo spegnimento dell'EUC in caso di guasto, e gli scenari operativi di guasto, ad esempio mantenere l'EUC il più possibile in funzione.

I guasti hardware casuali (e l'affidabilità) sono quantificati tramite i ratei di guastoIn termini di sicurezza funzionale i tassi di guasto sono suddivisi in guasti sicuri e pericolosi. Solo quelli pericolosi (che impediscono alla funzione di sicurezza di performare come previsto) sono considerati nel calcolo dei valori PFD/PFH. Un SIL rappresenta quindi solo un grado di affidabilità che la funzione di sicurezza performerà come previsto quando è richiesto di mettere il EUC in uno stato di sicurezza.

Watchdog e microcontroller

watchdog del microcontroller (µC) spesso si limitano a resettare il controller ma non verificano alcuna uscita in modo diretto e indipendente. In caso di guasto all'interno del µC è necessario un comportamento deterministico degli output. Non è sufficiente utilizzare un watchdog interno, perché non è garantito che l'uscita vada nello stato desiderato: il watchdog interno fa parte del microcontrollore difettoso, quindi non si può garantire che funzioni correttamente.

Software provato IN USO

Utilizziamo tuttora approcci per sostenerela capacità sistematica per il SW esistente sulla base dell'esperienza operativa (Route 2S in IEC 61508).A partire dalla IEC TS 61508-3-1 tutti i singoli guasti del SW devono essere rilevati e segnalati durante il periodo di osservazione e anche tutte le combinazioni di dati in ingresso, le sequenze di esecuzione e le relazioni temporali devono essere documentate. Questo approccio non è solitamente possibile da un punto di vista pratico.

Libertà di interferenza

Di solito osserviamo i progetti di sistema in cui parti/componenti/elementi di progettazione non sicuri smescolano con quelli isicurezza. Questo è un approccio standard per ridurre la complessità e i costi del sistema. Tuttavia, quando si utilizzano tecniche di progettazione a livello di integrità di sicurezza mista, è necessario dimostrare l’assenza di interferenze. L'analisi deve essere eseguita dettagliatamente a livello di hardware o software (a seconda del sistema), considerando le possibili modalità di guasto delle parti non di sicurezza e il relativo impatto su quella di sicurezza (ad es. sovratensione, dati errati, corto circuito in parti non di sicurezza, ecc.).

Specifiche di prova dell'unità

Nello sviluppo di software critici per la sicurezza, l'utilizzo di strumenti automatizzati rappresenta oggi il metodo più comune in termini di efficienza e sicurezza. Tuttavia, abbiamo assistito diverse volte ad un uso improprio di tali strumenti. La specifica del test dell’unità deve essere scritta in primo luogo sulla base della specifica dell'unità/modulo software e non solo attraverso l'analisi del codice sorgente in white-box. L'obiettivo è di testare il comportamento funzionale desiderato dell'unità software. Deve essere fornita anche la prova della copertura di test richiesta a livello di codice, per la quale può essere richiesta l'analisi della white-box, ma non è l'unico obiettivo del test dell’unità.

Sensori intelligenti senza qualifica SIL

Nei moderni sistemi complessi rilevanti per la sicurezza, l'uso di sensori intelligenti sta diventando sempre più importante. Le funzioni dei sensori devono essere fornite con la necessaria integrità o l’assenza di interferenze con la funzione di sicurezza complessiva deve essere giustificata.Alcuni progetti di sistemi si basano erroneamente sul presupposto che le modalità di guasto dei sensori intelligenti complessi (cioè con unità di elaborazione logica, protocollo di comunicazione, ecc.) possano essere diagnosticate e mitigate da alcune unità di sicurezza esterne entro la copertura diagnostica richiesta e il tempo di rilevamento/reazione del guasto.

Protezione/sorveglianza dell'alimentazione

Vediamo problemi ricorrenti relativi alla mancanza di protezione/sorveglianza dell'alimentazione elettrica. Le norme di sicurezza non specificano in dettaglio come devono essere attuate le misure di sovratensione/sottotensione, ma devono essere predisposti adeguati meccanismi di protezione a seconda del livello SIL richiesto. L'uso di meccanismi di protezione da sovratensione non ridondanti per architetture che richiedono HFT>1 è ad esempio un tipico problema ricorrente. Il monitoraggio della tensione di alimentazione (inclusa la reazione richiesta come lo spegnimento e lo stato di sicurezza) dovrebbe essere effettuato da un componente separato che sia in grado di un più ampio range di tensione, e che quindi non sia stato influenzato dalla condizione di sovratensione o sottotensioneAnche una breve sovratensione di scarsa durata potrebbe aver danneggiato in modo permanente parti del microcontrollore, anche senza che ci sia evidenzaPertanto, un reset del microcontrollore dopo la sovratensione non è una misura adeguata; dopo la condizione di sottotensione un reset può andare bene, fintanto che la sottotensione non persiste.

Sovratemperatura

Il rilevamento della sovratemperatura e la relativa reazione (entrata in stato di sicurezza, spegnimento, ...) non possono essere effettuati da un componente (es. microcontrollore) che, in caso di sovratemperatura, viene fatto funzionare correttamente al di fuori dei campi specificati. Anche in questo caso un semplice reset non è utile, si deve presumere che la condizione di sovratemperatura sia persistente o sia già presente durante l'accensione. La bassa temperatura a volte non è considerata dalle norme di sicurezza (es. EN50129), ma le condizioni di applicazione (manuale d'uso) devono assicurarsi che il dispositivo venga azionato solo entro i campi di temperatura specificati (per tutti i componenti).

SIL varia a seconda degli standard

L'abbreviazione SIL (Safety Integrity Level) è utilizzata da diversi standard. Ognuno di essi, tuttavia, si riferisce a diversi requisiti di processo, architettonici e tecnici. Alcuni standard utilizzano abbreviazioni diverse come ASIL (Automotive SIL). Alcuni altri usano la stessa abbreviazione (SIL), con il rischio di confusione e malintesi.

Ad esempio, il livello SAS (tedesco: "Sicherheitsanforderungsstufe" per Safety Integrity Level) utilizzato dalla SIRF (SicherheitsrichtlinieFahrzeug; EBA) non è lo stesso livello SIL ("SafetyIntegrity Level") utilizzato dalla EN 50128 /EN 50129. La SIRF (SAS) utilizza solo una parte delle misure elencate nell'appendice E della norma EN 50129, meno le misure organizzative e di processo, e nessun limite definito per il tasso di pericolo. SIL nel contesto della IEC 61508 è diverso da SIL nel contesto della EN 50129. A volte si aggiunge una maggiore complessità definendo il SIL come Livello di integrità del Software invece del Livello di integrità della Sicurezza (vedere ad es. EN 50657).

Aumentare il SIL attraverso la RIDONDANZA

Non è possibile innalzare il livello SIL di un sistema che combina sistemi che non hanno prove di sicurezza o che utilizzano una ridondanza omogenea. Ad esempio, non è possibile aumentare il SIL a SIL4 semplicemente combinando diversi sistemi/canali SIL2 (ad es. raggiungere SIL3 a livello di sistema con diversi sistemi di controllo SIL2). Una ragione è che, ad esempio, i processi software SIL2 non impediscono i guasti sistematici del software nello stesso modo (integrità) richiesto per quelli SIL4. La norma IEC 61508 permette di aumentare la capacità sistematica di 1 se si utilizzano due sistemi indipendenti in una struttura a doppio canale. In caso di ridondanza omogenea ciò non è possibile. Altre norme (es. EN 50129) non prevedono questa possibilità. 

Causa comune nella Fault Tree Analysis (FTA)

La causa comune è spesso dimenticata nella Fault Tree Analysis (FTA). I guasti che possono interessare contemporaneamente più parti di un sistema (es. perdita di alimentazione) devono essere inclusi come eventi di base in tutti i rami rilevanti dell'albero dei guasti. Alternativa: implementare la causa comune usando un "Beta Factor" nello strumento FTA.

 

Definizione di SIL

La definizione di SIL (Safety IntegrityLevel) si applica alle funzioni che hanno avuto origine da un qualche tipo di analisi/classificazione del rischio. Per un sistema/componente è comune sentire frasi come "un controllore SIL 2", "un sistema frenante SIL3", ecc. Correttamente parlando il termine SIL è riferito solo a specifiche funzioni (di sicurezza). Individuare le funzioni di sicurezza è l'obiettivo dell'analisi dei rischi. Una definizione più corretta è che un "sistema è in grado di implementare funzioni di sicurezza fino a SILx". Ciò significa che il sistema soddisfa i requisiti di processo, architettonici e tecnici delle norme.

 

Ambito di applicazione del sistema

I confini del sistema da analizzare dal punto di vista della sicurezza e le interfacce con altre parti del sistema spesso non sono chiaramente definiti all'inizio di un progetto. Ad esempio, non è chiaro quali componenti fanno parte del sistema, quali sono le varianti di sensori/attuatori da considerare, ecc. Non è possibile avviare un'analisi di sicurezza senza definire lo scopo, senza evitare diverse iterazioni ogni volta che lo scopo viene modificato.

 

SIL include DIAGNOSTICA

Non c'è qualcosa come ulivello SIL separato di un blocco di rilevamento e monitoraggio dei guasti (Diagnostica) appartenente ad una funzione di sicurezza classificata ad un determinato SIL. Alcuni standard consentono di ridurre il livello di integrità richiesto di 1, ma dal punto di vista della sicurezza funzionale la diagnostica fa parte delle funzioni di sicurezza. I requisiti di integrità si applicano anche alla diagnostica. Ulteriori analisi di decomposizione possono consentire di ridurre il livello di integrità, ma di solito non escludono alcun requisito di sicurezza.

 

Autotest del sistema durante l'avvio

Ad ogni avvio del sistema vengono eseguite alcune misure di integrità/diagnostica (ad es. test della RAM, controllo del Flash CRC, test delle uscite, ecc.) Questi test sono molto importanti, in quanto vengono utilizzati ad es. per argomentare le misure diagnostiche o per il tempo di rilevamento dei guasti (intervallo di prova) nell'analisi della sicurezza. Tuttavia, a volte le condizioni di funzionamento possono cambiare (nuovo progetto, nuovi requisiti, ecc.). I sistemi che sono stati regolarmente spenti, rimangono accesi più a lungo. Ad esempio, i moderni sistemi ferroviari sono oggi spesso continuamente accesi, senza riaccendersi ogni mattina. In questi casi le misure diagnostiche previste non diventano efficaci. Se l'analisi di sicurezza lo richiede, il regolare riavvio deve quindi essere esplicitamente specificato nel manuale di sicurezza, nella documentazione per l'operatore, ecc.

  • 1. PFH/PFD: necessario ma non sufficiente per un SIL (Safety Integrity Level)

    Spesso i produttori si limitano a calcolare un valore PFD/PFH per il loro sistema o sottosistema e rivendicano successivamente un SIL per esso. Il PFH/PFD esprime la probabilità di un guasto pericoloso di un sistema (o sottosistema) di sicurezza per ogni ora (PFH) o su richiesta (PFD). Entrambi i valori affrontano i guasti hardware casuali e di solito sono calcolati con l'uso di FMEDA. Il raggiungimento di uno specifico SIL (Safety Integrity Level) richiede non solo di controllare i guasti casuali dell'hardware ma anche di evitare e verificare i guasti sistematici nell'hardware e nel software. Quest'ultimo è espresso come Capacità Sistematica (SC, valori da 1 a 4, corrispondenti ai quattro valori SIL) e riflette i metodi e le tecniche utilizzate durante lo sviluppo del sistema di sicurezza. Pertanto, un SIL è sempre costituito da entrambi: PFD/PFH ed una determinazione della robustezza del suo processo di sviluppo, cioè l'SC.

  • 2. SIL non significa affidabilità del sistema di controllo

    A volte i system integrator e i produttori di impianti richiedono ai loro fornitori sistemi di controllo per il normale funzionamento con un SIL, pensando che questo garantisca una certa affidabilità del sistema di controllo e/o dell'utilità. Ma lo scopo di una funzione di sicurezza (eseguita da un sistema di sicurezza) è di mettere un'apparecchiatura sotto controllo (EUC - Equipment Under Control) in sicurezza per non aumentare la disponibilità.

    Lo stato di sicurezza di un EUC è il risultato dell'analisi dei pericoli e dei rischi e dipende dalle sue diverse modalità operative. In questo contesto, si osservano spesso malintesi sulle strategie e sui concetti relativi agli scenari di sicurezza, ad esempio lo spegnimento dell'EUC in caso di guasto, e gli scenari operativi di guasto, ad esempio mantenere l'EUC il più possibile in funzione.

    I guasti hardware casuali (e l'affidabilità) sono calcolati in base a quanto si guastano. In termini di sicurezza funzionale i tassi di guasto sono suddivisi in guasti sicuri e pericolosi. Solo quelli pericolosi (che impediscono alla funzione di sicurezza di performare come previsto) sono considerati nel calcolo dei valori PFD/PFH. Un SIL rappresenta quindi solo un grado di affidabilità che la funzione di sicurezza performerà come previsto quando è richiesto di mettere il EUC in uno stato di sicurezza.

  • 3. Watchdog e microcontroller

    I watchdog del microcontroller (µC) spesso si limitano a resettare il controller ma non verificano alcuna uscita in modo diretto e indipendente. In caso di guasto all'interno del µC è necessario un comportamento deterministico degli output. Non è sufficiente utilizzare un watchdog interno, perché non è garantito che l'uscita vada nello stato desiderato: il watchdog interno fa parte del microcontrollore difettoso, quindi non si può garantire che funzioni correttamente.

  • 4. Software collaudato in uso

    Osserviamo tuttora gli approcci per rivendicare la capacità sistematica per il SW esistente sulla base dell'esperienza operativa (Route 2S in IEC 61508). A partire dalla IEC TS 61508-3-1 tutti i singoli guasti del SW devono essere rilevati e segnalati durante il periodo di osservazione e anche tutte le combinazioni di dati in ingresso, le sequenze di esecuzione e le relazioni temporali devono essere documentate. Questo approccio non è solitamente possibile da un punto di vista pratico.

  • 5. Libertà di interferenza

    Di solito osserviamo i progetti di sistema in cui parti/componenti/elementi di progettazione non sicuri si mescolano con quelli in sicurezza. Questo è un approccio standard per ridurre la complessità e i costi del sistema. Tuttavia, quando si utilizzano tecniche di progettazione a livello di integrità di sicurezza mista, è necessario dimostrare la libertà di interferenza. L'analisi deve essere eseguita dettagliatamente a livello di hardware o software (a seconda del sistema), considerando le possibili modalità di guasto delle parti non di sicurezza e il relativo impatto su quella di sicurezza (ad es. sovratensione, dati errati, corto circuito in parti non di sicurezza, ecc.).

  • 6. Specifiche di prova dell'unità

    Nello sviluppo di software critici per la sicurezza, l'utilizzo di strumenti automatizzati rappresenta oggi il metodo più comune in termini di efficienza e sicurezza. Tuttavia, abbiamo assistito diverse volte ad un uso improprio di tali strumenti. La specifica del test del pezzo deve essere scritta in primo luogo sulla base della specifica dell'unità/modulo software e non solo attraverso l'analisi del codice sorgente in white-box. L'obiettivo è di testare il comportamento funzionale desiderato dell'unità software. Deve essere fornita anche la prova della copertura di test richiesta a livello di codice, per la quale può essere richiesta l'analisi della white-box, ma non è l'unico obiettivo del test unitario.

  • 7. Sensori intelligenti senza qualifica SIL

    Nei moderni sistemi complessi rilevanti per la sicurezza, l'uso di sensori intelligenti sta diventando sempre più importante. Le funzioni dei sensori devono essere fornite con la necessaria integrità o la libertà di interferenza con la funzione di sicurezza complessiva deve essere giustificata. Alcuni progetti di sistemi si basano erroneamente sul presupposto che le modalità di guasto dei sensori intelligenti complessi (cioè con unità di elaborazione logica, protocollo di comunicazione, ecc.) possano essere diagnosticate e mitigate da alcune unità di sicurezza esterne entro la copertura diagnostica richiesta e il tempo di rilevamento/reazione del guasto.

  • 8. Protezione/sorveglianza dell'alimentazione

    Vediamo problemi ricorrenti relativi alla mancanza di protezione/sorveglianza dell'alimentazione elettrica. Le norme di sicurezza non specificano in dettaglio come devono essere attuate le misure di sovratensione/sottotensione, ma devono essere predisposti adeguati meccanismi di protezione a seconda del livello SIL richiesto. L'uso di meccanismi di protezione da sovratensione non ridondanti per architetture che richiedono HFT>1 è ad esempio un tipico problema ricorrente. Il monitoraggio della tensione di alimentazione (inclusa la reazione richiesta come lo spegnimento e lo stato di sicurezza) dovrebbe essere effettuato da un componente separato che sia in grado di un più ampio range di tensione, e che quindi non sia stato influenzato dalla condizione di sovratensione o sottotensione. Anche una breve sovratensione di scarsa durata potrebbe aver danneggiato in modo permanente parti del microcontrollore, anche senza che ci sia evidenza. Pertanto, un reset del microcontrollore dopo la sovratensione non è una misura adeguata; dopo la condizione di sottotensione un reset può andare bene, fintanto che la sottotensione non persiste.

  • 9. Sovratemperatura

    Il rilevamento della sovratemperatura e la relativa reazione (entrata in stato di sicurezza, spegnimento, ...) non possono essere effettuati da un componente (es. microcontrollore) che, in caso di sovratemperatura, viene fatto funzionare correttamente al di fuori dei campi specificati. Anche in questo caso un semplice reset non è utile, si deve presumere che la condizione di sovratemperatura sia persistente o sia già presente durante l'accensione. La bassa temperatura a volte non è considerata dalle norme di sicurezza (es. EN50129), ma le condizioni di applicazione (manuale d'uso) devono assicurarsi che il dispositivo venga azionato solo entro i campi di temperatura specificati (per tutti i componenti).

  • 10. SIL varia a seconda degli standard

    L'abbreviazione SIL (Safety Integrity Level) è utilizzata da diversi standard. Ognuno di essi, tuttavia, si riferisce a diversi requisiti di processo, architettonici e tecnici. Alcuni standard utilizzano abbreviazioni diverse come ASIL (Automotive SIL). Alcuni altri usano la stessa abbreviazione (SIL), con il rischio di confusione e malintesi.

    Ad esempio il livello SAS (tedesco: "Sicherheitsanforderungsstufe" per Safey Integrity Level) utilizzato dalla SIRF (Sicherheitsrichtlinie Fahrzeug; EBA) non è lo stesso livello SIL ("Safety Integrity Level") utilizzato dalla EN 50128 /EN 50129. La SIRF (SAS) utilizza solo una parte delle misure elencate nell'appendice E della norma EN 50129, meno le misure organizzative e di processo, e nessun limite definito per il tasso di pericolo. SIL nel contesto della IEC 61508 è diverso da SIL nel contesto della EN 50129. A volte si aggiunge una maggiore complessità definendo il SIL come Livello di integrità del software invece del Livello di integrità della sicurezza (vedere ad es. EN 50657).

  • 11. Aumento del SIL per ridondanza

    Non è possibile innalzare il livello SIL di un sistema che combina sistemi che non hanno prove di sicurezza o che utilizzano una ridondanza omogenea. Ad esempio, non è possibile aumentare il SIL a SIL4 semplicemente combinando diversi sistemi/canali SIL2 (ad es. raggiungere SIL3 a livello di sistema con diversi sistemi di controllo SIL2). Una ragione è che, ad esempio, i processi software SIL2 non impediscono i guasti sistematici del software nello stesso modo (integrità) richiesto per quelli SIL4. La norma IEC 61508 permette di aumentare la capacità sistematica di 1 se si utilizzano due sistemi indipendenti in una struttura a doppio canale. In caso di ridondanza omogenea ciò non è possibile. Altre norme (es. EN 50129) non prevedono questa possibilità. 

  • 12. Causa comune nella Fault Tree Analysis (FTA)

    La causa comune è spesso dimenticata nell'a Fault Tree Analysis (FTA). I guasti che possono interessare contemporaneamente più parti di un sistema (es. perdita di alimentazione) devono essere inclusi come eventi di base in tutti i rami rilevanti dell'albero dei guasti. Alternativa: implementare la causa comune usando un "Beta Factor" nello strumento FTA.

  • 13. Definizione di SIL

    La definizione di SIL (Safety Integrity Level) si applica alle funzioni che hanno avuto origine da un qualche tipo di analisi/classificazione del rischio. Per un sistema/componente è comune sentire frasi come "un controllore SIL 2", "un sistema frenante SIL3", ecc. Correttamente parlando il termine SIL è riferito solo a specifiche funzioni (di sicurezza). Individuare le funzioni di sicurezza è l'obiettivo dell'analisi dei rischi. Una definizione più corretta è che un "sistema è in grado di implementare funzioni di sicurezza fino a SILx". Ciò significa che il sistema soddisfa i requisiti di processo, architettonici e tecnici delle norme.

  • 14. Ambito di applicazione del sistema

    I confini del sistema da analizzare dal punto di vista della sicurezza e le interfacce con altre parti del sistema spesso non sono chiaramente definiti all'inizio di un progetto. Ad esempio, non è chiaro quali componenti fanno parte del sistema, quali sono le varianti di sensori/attuatori da considerare, ecc. Non è possibile avviare un'analisi di sicurezza senza definire l'ambito, senza evitare diverse iterazioni ogni volta che l'ambito viene modificato.

  • 15. SIL include DIAGNOSTICA

    Non c'è qualcosa come il livello SIL separato di un blocco di rilevamento e monitoraggio dei guasti (Diagnostica) appartenente ad una funzione di sicurezza classificata a certi SIL. Alcuni standard consentono di ridurre il livello di integrità richiesto di 1, ma dal punto di vista della sicurezza funzionale la diagnostica fa parte delle funzioni di sicurezza. I requisiti di integrità si applicano anche alla diagnostica. Ulteriori analisi di decomposizione possono consentire di ridurre il livello di integrità, ma di solito non escludono alcun requisito di sicurezza.

  • 16. Autotest del sistema durante l'avvio

    Ad ogni avvio del sistema vengono eseguite alcune misure di integrità/diagnostica (ad es. test della RAM, controllo del Flash CRC, test delle uscite, ecc.) Questi test sono molto importanti, in quanto vengono utilizzati ad es. per argomentare le misure diagnostiche o per il tempo di rilevamento dei guasti (intervallo di prova) nell'analisi della sicurezza. Tuttavia, a volte le condizioni di funzionamento possono cambiare (nuovo progetto, nuovi requisiti, ecc.). I sistemi che sono stati regolarmente spenti, rimangono accesi più a lungo. Ad esempio, i moderni sistemi ferroviari sono oggi spesso continuamente accesi, senza riaccendersi ogni mattina. In questi casi le misure diagnostiche previste non diventano efficaci. Se l'analisi di sicurezza lo richiede, il regolare riavvio deve quindi essere esplicitamente specificato nel manuale di sicurezza, nella documentazione per l'operatore, ecc.

esplora

Catalogo corsi TUV Italia Akademie
Brochure

Catalogo Corsi Interattivo

Oltre 250 corsi di formazione in aula, online e in modalità e-learning

Scopri i nostri corsi

innovazione digitale nel futuro
Blog
Bytest: hi-tech a raggi X
Blog

Bytest: Hi-Tech a raggi X

LEGGI L'ARTICOLO

tutte le risorse

Come possiamo aiutarti?

Select Your Location

Global

Americas

Asia

Europe

Middle East and Africa