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: necessary but not sufficient for a SIL

    Often manufacturers just calculate a PFD/PFH value for their system or subsystem and claim afterwards a SIL for it. The PFH/PFD express the probability of a dangerous failure of a safety related system (or sub-system) per hour (PFH) or on demand (PFD). Both values address random hardware faults and usually are calculated with use of FMEDAs. Fulfilling a specific Safety Integrity Level (SIL) requires not only the control of random failures of hardware but also the avoidance and control of systematic failures in hardware and software. The latter is expressed as Systematic Capability (SC, values from 1 to 4, corresponding to the four SIL values) and reflects methods and techniques used during development of the safety related system. Therefore, a SIL always consists of both: PFD/PFH and a determination of the robustness of its development process i.e. the SC.

  • 2. SIL does not mean reliability of the control system

    Sometimes system integrators and plant manufacturers require their suppliers to deliver control systems for normal operation with a SIL, thinking that this will ensure a certain reliability of the control system and/or utility. But the aim of a safety function (which is performed by a safety related system) is to put an Equipment Under Control (EUC) into a safe state not to increase availability.

    A safe state of a EUC is a result of the hazard and risk analysis and depends on its different operational modes. In this context, we frequently observe misunderstandings about strategies and concepts regarding fail safe scenarios, for example shutting down the EUC in case of a failure, and fail operational scenarios, i.e. e.g. keep the EUC as much as possible in operation.

    Random hardware failures (and reliability) are calculated based on failure rates. In terms of functional safety failure rates are split into safe and dangerous failures. Only dangerous failures (preventing the safety function to perform as intended) are considered in the calculation of the PFD/PFH values. A SIL therefore is only a degree of reliability that the safety function will perform as intended when it is required to put the EUC in a safe state.

  • 3. Watchdogs and microcontroller

    Watchdogs of microcontroller (µC) often just reset the controller but do not control any outputs in a direct independent way. In case of a fault inside the µC a deterministic behaviour of the output is required. It is not enough to use an internal watchdog, because it is not guaranteed that the output will go into the desired state: the internal watchdog is part of the defect microcontroller, therefore it cannot be guaranteed that it works correctly.

  • 4. Proven in use software

    We still observe approaches to claim systematic capability for existing SW based on operational experience (Route 2S in IEC 61508). Since IEC TS 61508-3-1 all individual failures of the SW need to be detected and reported during the observation period and also all combinations of input data, sequences of execution and timing relations must be documented. This approach is usually not possible from a practical point of view.

  • 5. Freedom of interference

    We usually observe system designs where non-safety parts/components/design elements are mixed with safety ones. This is a standard approach to reduce complexity and system costs. However, evidence for freedom of interference is required when mixed safety integrity level design techniques are used. The analysis shall be performed at detailed hardware or software level (depending on the system), considering any possible failure modes of the non-safety parts and the related impact on the safety one (i.e. overvoltage, wrong data, short circuit in not safety parts, etc.).

  • 6. Unit test specification

    In the development of safety critical software, the usage of automated tools is nowadays state of the art in terms of efficiency and safety. Several times we have seen however some wrong usage of such tools. The unit test specification shall be written firstly based on the software unit/module specification and not only by white-box analysis of the source code. The goal is to test the desired functional behaviour of the software unit. The fulfilment of the evidence of the required test coverage at code level, for which white-box analysis can be required, shall be provided as well, but is not the only goal of unit test.

  • 7. Smart sensors without SIL qualification

    In modern complex safety relevant systems, the usage of smart sensors is getting more and more importance. The functions of the sensors shall be provided with the required integrity or the freedom of interference to the overall safety function shall be justified. Some system designs are wrongly based on the assumption that the failure modes of the complex smart sensors (i.e. with logic processing unit, communication protocol, etc.) can be diagnosed and mitigated by some external safety unit within the required diagnostic coverage and failure detection/reaction time.

  • 8. Protection/supervision of power supply

    We see recurrent issues related to missing protection/supervision of power supply. The safety standards do not specify how overvoltage/undervoltage measures shall be implemented in detail, but suitable mechanisms for protection shall be in place depending on the required SIL level. Usage of not redundant overvoltage protection mechanism for architecture requiring HFT>1 is for example a typical recurring issue. Supply voltage monitoring (including the required reaction like switch-off and safe state) should be done by a separate component which is capable of a wider voltage range, and has thus not been affected by the over/undervoltage condition. Even short overvoltage might have permanently damaged parts of the microcontroller, without being obvious. Thus, a reset of the microcontroller after overvoltage is not a suitable measure; after undervoltage condition a reset can be ok, as long as the undervoltage is not persisting.

  • 9. Overtemperature

    The overtemperature detection and the respective reaction (enter safe state, switch-off,…) cannot be done by a component (e.g. microcontroller) which is right operated outside the specified ranges in case of overtemperature condition. A simple reset is also not helpful here, it has to be assumed that the overtemperature condition is persisting, or is already present during switch-on. Low temperature is sometimes not considered by safety standards (i.e. EN50129), but the application conditions (user manual) should make sure that the device is only driven within specified temperature ranges (for all components).

  • 10. SIL is not the same as SIL

    The abbreviation SIL (Safety Integrity Level) is used by several standards. In each standard, it relates however to different process, architectural and technical requirements. Some of the standards use different abbreviations like ASIL (Automotive SIL). Some others use the same abbreviation (SIL), with the risk of confusion and misunderstandings.

    For example the SAS level (german:“Sicherheitsanforderungsstufe” for Safey Integrity Level) as it is used by SIRF (Sicherheitsrichtlinie Fahrzeug; EBA) is not the same as SIL level (“Safety Integrity Level”) as used by EN 50128 /EN 50129. SIRF (SAS) only uses part of the measures listed in appendix E of EN 50129, less organizational and process measures, and no defined limit for the hazard rate. SIL in the context of IEC 61508 is different than SIL in the context of EN50129. Sometime more complexity is added by defining SIL as Software Integrity Level instead of Safety Integrity Level (see e.g. EN 50657).

  • 11. Increasing SIL by redundancy

    It is not possible to raise the SIL level of a system combining systems having no safety evidence or using homogeneous redundancy. For example, it is not possible to increase the SIL to SIL4 by simply combining several SIL2 systems/channels (e.g. reach SIL3 on system level by several SIL2 Control Systems). One reason is that for example SIL2 software processes do not prevent systematic software faults in the same way (integrity) as required for SIL4 ones. The IEC 61508 standard allows to increase the systematic capability by 1 if two independent systems are used in a dual channel structure. In case of homogeneous redundancy this is not possible. Other standards (i.e. EN 50129) do not provide this possibility.

  • 12. Common cause in Fault Tree Analysis (FTA)

    Common cause is often forgotten in Fault Tree Analysis (FTA). Failures which can affect several parts of a system at the same time (e.g. loss of power supply) must be included as basic events in all relevant branches of the Fault Tree. Alternative: implement Common cause by using a “Beta Factor” in FTA tool.

  • 13. Definition of SIL

    The definition of SIL (safety integrity level) applies to functions that have been in origin derived by some kind of risk analysis/classification. For a system/component it is common to hear sentence like “a SIL 2 controller”, “a SIL3 brake system”, etc. Correctly speaking the term SIL is only related to specific (safety) functions. Which functions are safety ones is the goal of the risk analysis. A more correct definition is that a “system is capable to implement safety functions up to SILx”. This means that the process, architectural and technical requirements of the standards are fulfilled by the system.

  • 14. System scope

    The borders of the system to be analyzed from a safety point of view, and the interfaces to other system parts, are often not clearly defined at the beginning of a project. It is e.g. not clear which components are part of the system, which sensors/actuator variants shall be considered, etc. Starting a safety analysis without defining the scope is simply not possible, without avoiding several iterations each time the scope is changed.

  • 15. SIL includes DIAGNOSTIC

    There is not something like separate SIL level of a Failure Detection and Monitoring blocks (Diagnostic) belonging to a safety function classified to certain SIL. Some standards allow to reduce the required integrity level by 1, but from a functional safety point of view the diagnostic is part of the safety functions. Integrity requirements apply to diagnostic as well. Further decomposition analysis can allow to reduce the integrity level, but usually not to exclude any safety requirements.

  • 16. System self-test during start-up

    Some integrity/diagnostic measures are performed at each startup of the system (e.g. RAM test, Flash CRC check, output tests, etc.). These tests are very important, as they are e.g. used for argumentation on diagnostic measures, or for fault detection time (test interval) in the safety analysis. However, sometime the operation condition can change (new project, new requirements, etc.). Systems which were regularly powered-down, stay powered-up for longer time. For example, modern rail systems are nowadays often continuously powered-on, without re-start every morning. In such cases the intended diagnostic measures will not become effective. If needed by the safety analysis, regular re-start shall be therefore explicitly specified in the safety manual, operator documentation, etc.

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