Top Misunderstandings about Functional Safety

Missverständnisse über funktionale Sicherheit

Qualität und Sicherheit für Ihre Produkte

Qualität und Sicherheit für Ihre Produkte

VERMEIDEN SIE FEHLER IN ZUKÜNFTIGEN SICHERHEITSPROJEKTEN

TÜV SÜD verfügt über mehr als 20 Jahre Erfahrung in der Prüfung und Zertifizierung von Systemen und Komponenten im Zusammenhang mit der funktionalen Sicherheit. Während dieser Zeit haben unsere Mitarbeiter wiederkehrende Probleme beobachtet, die sich aus Missverständnissen einiger funktionaler Sicherheitskonzepte ergeben. Die folgende Liste zeigt einige der interessantesten Fehler, die jeder kennen sollte.

 

  • 1. PFH / PFD: notwendig, aber nicht ausreichend für ein SIL

    Oft berechnen Hersteller nur einen PFD / PFH-Wert für ihr System oder Subsystem und fordern anschliessend einen SIL dafür an. Die PFH / PFD geben die Wahrscheinlichkeit eines gefährlichen Ausfalls eines sicherheitsrelevanten Systems (oder Teilsystems) pro Stunde (PFH) oder bei Bedarf (PFD) an. Beide Werte adressieren zufällige Hardwarefehler und werden normalerweise unter Verwendung von FMEDAs berechnet. Das Erreichen eines bestimmten Sicherheitsintegritätsniveaus (Safety Integrity Level, SIL) erfordert nicht nur die Kontrolle zufälliger Hardwarefehler, sondern auch die Vermeidung und Kontrolle systematischer Hardware- und Softwareausfälle. Letzteres wird als systematische Fähigkeit (SC, Werte von 1 bis 4, entsprechend den vier SIL-Werten) ausgedrückt und spiegelt Methoden und Techniken wider, die während der Entwicklung des sicherheitsrelevanten Systems verwendet wurden. Daher besteht ein SIL immer aus beiden: PFD / PFH und einer Bestimmung der Robustheit seines Entwicklungsprozesses, d.h. des SC.

  • 2. SIL bedeutet nicht Zuverlässigkeit des Steuerungssystems

    Manchmal verlangen Systemintegratoren und Anlagenhersteller von ihren Lieferanten, dass sie Steuerungssysteme für den normalen Betrieb mit einem SIL liefern, da sie der Ansicht sind, dass dies eine gewisse Zuverlässigkeit des Steuerungssystems und / oder des Versorgungsunternehmens gewährleistet. Ziel einer Sicherheitsfunktion (die von einem sicherheitsrelevanten System ausgeführt wird) ist es jedoch, ein EUC (Equipment Under Control) in einen sicheren Zustand zu versetzen, um die Verfügbarkeit nicht zu erhöhen.

    Ein sicherer Zustand eines EUC ist ein Ergebnis der Gefahren- und Risikoanalyse und hängt von seinen verschiedenen Betriebsmodi ab. In diesem Zusammenhang beobachten wir häufig Missverständnisse über Strategien und Konzepte in Bezug auf ausfallsichere Szenarien, z. B. das Herunterfahren des EUC im Falle eines Ausfalls, und ausfallende Betriebsszenarien, d.h. Halten Sie die EUC so weit wie möglich in Betrieb.

    Zufällige Hardwarefehler (und Zuverlässigkeit) werden basierend auf den Ausfallraten berechnet. In Bezug auf die funktionale Sicherheit werden die Ausfallraten in sichere und gefährliche Ausfälle unterteilt. Bei der Berechnung der PFD / PFH-Werte werden nur gefährliche Fehler berücksichtigt (die verhindern, dass die Sicherheitsfunktion wie beabsichtigt ausgeführt wird). Ein SIL ist daher nur ein Grad an Zuverlässigkeit, den die Sicherheitsfunktion wie beabsichtigt erfüllt, wenn es erforderlich ist, die EUC in einen sicheren Zustand zu versetzen.

  • 3. Watchdogs und Mikrocontroller

    Watchdogs des Mikrocontrollers (µC) setzen den Controller häufig nur zurück, steuern jedoch keine Outputs direkt und unabhängig. Im Falle eines Fehlers innerhalb des µC ist ein deterministisches Verhalten des Outputs erforderlich. Es reicht nicht aus, einen internen Watchdog zu verwenden, da nicht garantiert werden kann, dass die Ausgabe in den gewünschten Zustand versetzt wird: der interne Watchdog ist Teil des defekten Mikrocontrollers, daher kann nicht garantiert werden, dass er ordnungsgemäss funktioniert.

  • 4. Bewährte Software

    Wir beobachten immer noch Ansätze, um systematische Fähigkeiten für vorhandene SW auf der Grundlage von Betriebserfahrungen zu beanspruchen (Route 2S in IEC 61508). Seit IEC TS 61508-3-1 müssen alle einzelnen Fehler der SW während des Beobachtungszeitraums erkannt und gemeldet werden sowie alle Kombinationen von Eingabedaten, Ausführungssequenzen und Timing-Beziehungen. Dieser Ansatz ist aus praktischer Sicht in der Regel nicht möglich.

  • 5. Interferenzfreiheit

    Wir beobachten normalerweise Systemkonstruktionen, bei denen nicht sicherheitsrelevante Teile/Komponenten/Konstruktionselemente mit Sicherheitsteilen gemischt werden. Dies ist ein Standardansatz zur Reduzierung der Komplexität und der Systemkosten. Der Nachweis der Interferenzfreiheit ist jedoch erforderlich, wenn Entwurfstechniken für gemischte Sicherheitsintegritätsstufen verwendet werden. Die Analyse muss auf detaillierter Hardware- oder Softwareebene (je nach System) durchgeführt werden, wobei mögliche Fehlermodi der nicht sicherheitsrelevanten Teile und die damit verbundenen Auswirkungen auf die sicherheitstechnischen Teile (d.h. Überspannung, falsche Daten, Kurzschluss in nicht sicherheitstechnischen Teilen usw.) zu berücksichtigen sind.

  • 6. Gerätetest-Spezifikation

    Bei der Entwicklung sicherheitskritischer Software ist der Einsatz automatisierter Werkzeuge heutzutage hinsichtlich Effizienz und Sicherheit auf dem neuesten Stand der Technik. Mehrmals haben wir jedoch eine falsche Verwendung solcher Tools gesehen. Die Gerätetest-Spezifikation muss zunächst auf der Grundlage der Software-Gerät-/Modul-Spezifikation und nicht nur durch White-Box-Analyse des Quellcodes geschrieben werden. Ziel ist es, das gewünschte Funktionsverhalten der Softwareeinheit zu testen. Die Erfüllung des Nachweises der erforderlichen Testabdeckung auf Codeebene, für die eine White-Box-Analyse erforderlich sein kann, muss ebenfalls erbracht werden, ist jedoch nicht das einzige Ziel des Komponententests.

  • 7. Smart Sensors ohne SIL-Qualifikation

    In modernen komplexen sicherheitsrelevanten Systemen gewinnt der Einsatz von Smart Sensoren immer mehr an Bedeutung. Die Funktionen der Sensoren müssen mit der erforderlichen Integrität versehen sein, oder die Interferenzfreiheit für die gesamte Sicherheitsfunktion muss gerechtfertigt sein. Einige Systemdesigns basieren fälschlicherweise auf der Annahme, dass die Fehlermodi der komplexen Smart Sensoren (d.h. mit Logikverarbeitungseinheit, Kommunikationsprotokoll usw.) von einer externen Sicherheitseinheit innerhalb der erforderlichen Diagnoseabdeckung und Fehlererkennung/Reaktionszeit diagnostiziert und gemindert werden können.

  • 8. Schutz/Überwachung der Stromversorgung

    Wir sehen wiederkehrende Probleme im Zusammenhang mit dem fehlenden Schutz/der fehlenden Überwachung der Stromversorgung. Die Sicherheitsnormen legen nicht fest, wie Überspannungs-/Unterspannungsmassnahmen im Detail umgesetzt werden sollen, aber je nach erforderlichem SIL-Wert müssen geeignete Schutzmechanismen vorhanden sein. Die Verwendung eines nicht redundanten Überspannungsschutzmechanismus für Architekturen, die HFT> 1 erfordern, ist beispielsweise ein typisches wiederkehrendes Problem. Die Überwachung der Versorgungsspannung (einschliesslich der erforderlichen Reaktion wie Abschalten und sicherer Zustand) sollte von einer separaten Komponente durchgeführt werden, die einen grösseren Spannungsbereich bietet und daher nicht durch den Über-/Unterspannungszustand beeinflusst wurde. Selbst eine kurze Überspannung kann Teile des Mikrocontrollers dauerhaft beschädigt haben, ohne dass dies offensichtlich ist. Ein Zurücksetzen des Mikrocontrollers nach Überspannung ist daher keine geeignete Massnahme; nach einer Unterspannungsbedingung kann ein Reset in Ordnung sein, solange die Unterspannung nicht anhält.

  • 9. Übertemperatur

    Die Übertemperaturerfassung und die jeweilige Reaktion (in den sicheren Zustand wechseln, abschalten, ...) können nicht von einer Komponente (z. B. einem Mikrocontroller) durchgeführt werden, die im Falle eines Übertemperaturzustands direkt ausserhalb der angegebenen Bereiche betrieben wird. Ein einfaches Zurücksetzen ist auch hier nicht hilfreich, es muss davon ausgegangen werden, dass der Übertemperaturzustand anhält oder bereits beim Einschalten vorliegt. Niedrige Temperaturen werden manchmal von Sicherheitsstandards (d. H. EN50129) nicht berücksichtigt, aber die Anwendungsbedingungen (Benutzerhandbuch) sollten sicherstellen, dass das Gerät nur innerhalb bestimmter Temperaturbereiche (für alle Komponenten) betrieben wird.

  • 10. SIL ist nicht dasselbe wie SIL

    Die Abkürzung SIL (Safety Integrity Level) wird von mehreren Standards verwendet. In jeder Norm bezieht es sich jedoch auf unterschiedliche prozessuale, architektonische und technische Anforderungen. Einige der Standards verwenden unterschiedliche Abkürzungen wie ASIL (Automotive SIL). Einige andere verwenden dieselbe Abkürzung (SIL), mit der Gefahr von Verwirrung und Missverständnissen.

    Beispielsweise entspricht die von der SIRF (Sicherheitsrichtlinie Fahrzeug; EBA) verwendete SAS-Stufe (Sicherheitsanforderungsstufe; engl.: "Safety Integrity Level") nicht der SIL-Stufe (Safety Integrity Level), wie sie von EN 50128 / EN 50129 verwendet wird. SIRF (SAS) verwendet nur einen Teil der in Anhang E der EN 50129 aufgeführten Massnahmen, abzüglich organisatorischer und prozessualer Massnahmen und ohne definierte Grenze für die Gefährdungsrate. SIL im Kontext von IEC 61508 unterscheidet sich von SIL im Kontext von EN50129. Manchmal wird mehr Komplexität hinzugefügt, indem SIL als Software-Integritätsstufe anstelle der Sicherheitsintegritätsstufe definiert wird (siehe z. B. EN 50657).

  • 11. Erhöhung des SIL durch Redundanz

    Es ist nicht möglich, das SIL-Niveau eines Systems zu erhöhen, das Systeme ohne Sicherheitsnachweis kombiniert oder homogene Redundanz verwendet. Zum Beispiel ist es nicht möglich, den SIL auf SIL4 zu erhöhen, indem einfach mehrere SIL2-Systeme/Kanäle kombiniert werden (z.B. SIL3 auf Systemebene durch mehrere SIL2-Steuerungssysteme erreichen). Ein Grund ist, dass beispielsweise SIL2-Softwareprozesse systematische Softwarefehler nicht auf die gleiche Weise (Integrität) verhindern, wie sie für SIL4-Softwareprozesse erforderlich sind. Die Norm IEC 61508 ermöglicht es, die systematische Fähigkeit um 1 zu erhöhen, wenn zwei unabhängige Systeme in einer Zweikanalstruktur verwendet werden. Bei homogener Redundanz ist dies nicht möglich. Andere Normen (d.h. EN 50129) bieten diese Möglichkeit nicht.

     

  • 12. Gemeinsame Ursache bei der Fehlerbaumanalyse (FTA)

    Gemeinsame Ursachen werden in der Fehlerbaumanalyse (FTA) oft vergessen. Fehler, die mehrere Teile eines Systems gleichzeitig betreffen können (z. B. Stromausfall), müssen als grundlegende Ereignisse in allen relevanten Zweigen des Fehlerbaums enthalten sein. Alternative: Implementieren Sie Gemeinsame Ursachen mithilfe eines „Beta-Faktors“ im FTA-Tool.

  • 13. Definition von SIL

    Die Definition von SIL (Safety Integrity Level) gilt für Funktionen, deren Ursprung in einer Art Risikoanalyse/-klassifizierung liegt. Für ein System/eine Komponente ist es üblich, Sätze wie „eine SIL 2-Steuerung“, „ein SIL3-Bremssystem“ usw. zu hören. Richtigerweise bezieht sich der Begriff SIL nur auf bestimmte (Sicherheits-) Funktionen. Welche Funktionen sicher sind, ist das Ziel der Risikoanalyse. Eine korrektere Definition ist, dass ein „System in der Lage ist, Sicherheitsfunktionen bis zu SILx zu implementieren“. Dies bedeutet, dass die prozessualen, architektonischen und technischen Anforderungen der Normen vom System erfüllt werden.

  • 14. Systemumfang

    Die Grenzen des zu analysierenden Systems unter Sicherheitsgesichtspunkten und die Schnittstellen zu anderen Systemteilen sind zu Beginn eines Projekts häufig nicht klar definiert. Es ist z.B. nicht klar, welche Komponenten Teil des Systems sind, welche Sensoren/Aktuatorvarianten berücksichtigt werden sollen usw. Das Starten einer Sicherheitsanalyse ohne Definition des Bereichs ist einfach nicht möglich, ohne dass bei jeder Änderung des Bereichs mehrere Iterationen vermieden werden.

  • 15. SIL enthält DIAGNOSE

    Es gibt keine separate SIL-Ebene eines Fehlererkennungs- und Überwachungsblocks (Diagnose), der zu einer Sicherheitsfunktion gehört, die einem bestimmten SIL zugeordnet ist. Einige Standards erlauben es, das erforderliche Integritätsniveau um 1 zu reduzieren, aber aus Sicht der funktionalen Sicherheit ist die Diagnose Teil der Sicherheitsfunktionen. Integritätsanforderungen gelten auch für die Diagnose. Eine weitere Zersetzungsanalyse kann es ermöglichen, das Integritätsniveau zu verringern, schliesst jedoch normalerweise keine Sicherheitsanforderungen aus.

  • 16. Systemselbsttest beim Start

    Einige Integritäts- / Diagnosemassnahmen werden bei jedem Start des Systems durchgeführt (z.B. RAM-Test, Flash-CRC-Prüfung, Ausgabetests usw.). Diese Tests sind sehr wichtig, da sie z.B. zur Argumentation über diagnostische Massnahmen oder zur Fehlererkennungszeit (Testintervall) in der Sicherheitsanalyse verwendet werden. Manchmal kann sich jedoch die Betriebsbedingung ändern (neues Projekt, neue Anforderungen usw.). Systeme, die regelmässig ausgeschaltet wurden, bleiben länger eingeschaltet. Beispielsweise werden moderne Schienensysteme heutzutage häufig kontinuierlich eingeschaltet, ohne jeden Morgen neu zu starten. In solchen Fällen werden die beabsichtigten diagnostischen Massnahmen nicht wirksam. Falls dies für die Sicherheitsanalyse erforderlich ist, muss ein regelmässiger Neustart daher ausdrücklich im Sicherheitshandbuch, in der Bedienerdokumentation usw. angegeben werden.

Wie können wir Ihnen weiterhelfen?

Weltweit