Realisierung sicherheitsbezogener Systeme – Technisches Sicherheitskonzept

Nach IEC 61508 Teil 2 beginnt der Enwurf mit der Verfeinerung der Anforderungen an das sicherheitsbezogene E/E/PE-System, welches die Sicherheitsfunktion ausführt. Ziel ist ein Technisches Sicherheitskonzept zu entwerfen, systematisch geeignete Technologien auszuwählen und dazu passende Verfahren und Maßnahmen zur Vermeidung und Beherrschung von Fehlern und Ausfällen auszuwählen und in einer Architektur zu beschreiben. Weiterhin werden Installations-, Inbetriebnahme- und Validierungsanforderungen festgelegt. Es empfiehlt sich bei hoher Systemkomplexität auf die modellbasierte Systementwicklung und deren Werkzeuge mit eigeschränkten Sprach- und Kodiersatz zu setzen ganz im Sinne der Vermeidung systematischer Fehler.

Der Sicherheitslebenszyklus muss zum einen den Anforderungen zur Vermeidung systematischer Fehler gerecht werden und dabei die Tätigkeiten des FSM unterstützen wie z.B. Verifikation, Validierung, Konfigurationsmanagement und Änderungsmanagement. Zum anderen müssen verwendete Technologien berücksichtigt werden. Eine Entwicklung mit FPGA-Technologie kann ein anderes Vorgehensmodell induzieren als mit DSP- oder µC-Technologie. Dazu ist die Entwicklungslandschaft und Art maßgeblich. Der Sicherheitslebenszyklus und die Entwicklungsumgebung müssen kompatibel mit den Zielen der Norm ausgewählt oder entwickelt werden. Oft geben die Hersteller der Kerntechnologien (z.B. Infineon, Atmel, TI, Altera/Intel PSG, Xilinx) sogegannte „Qualification-Kits“ für sicherheitsbezogenen Serien von µC, FPGAs oder andere Hardware mit heraus, welche das Vorgehensmodell und die Entwicklungswerkzeuge vorgeben.

Wasserfall und V-Modell sind möglich. Wichtig ist die effektive Iterationsfähigkeit durch alle Stationen der folgenden chonologisch aufgezählten Kernphasen:

Dazu sind Modifikationsroutinen, Verifikationstätigkeiten und die abschließende Beurteilung der FuSi in den Sicherheitslebenszyklus zu integrieren. Jede Phase ist zu beschreiben mit Ziel, Anwendungsbereich, den notwendigen Eingangsinformationen und den dokumentierten Ergebnissen der Phase. Weiterhin ist der Bezug zu den Anforderungen der Norm notwendig, um deren Ziele strukturiert umzusetzen.

Oft wird die FuSi als V-Modell dargestellt und als unvereinbar mit agilen Vorgehensweisen wie Scrum interpretiert. Teilweise sind in bestimmten Phasen „Sprints“ tatsächlich möglich. Die Aufwände lassen sich dadurch nicht reduzieren und machen die Maßnahmen zur Vermeidung systematischer Fehler nicht gerade effektiver.

Ein Technisches Sicherheitskonzept beginnt mit der Anforderungsspezifikation an den Entwurf

Ausgehend von den Top-Level-Anforderungen an das sicherheitsbezogene E/E/PE-System werden Anforderungen an den Entwurf durch Zerlegung der Sicherheitsfunktion in Teilfunktionen und Zuordnung zu Teilsystemen oder Elementen hergeleitet. Dabei werden oft Blockdiagrammsequenzen wie Sensor(en), Logik(en) und Aktor(en) vollständig beschrieben. Es ist die Vor- und Rückverfolgbarkeit (Traceability) zwischen den Top-Level-Systemanforderungen und den Entwurfsanforderungen zu gewährleisten. Weiterhin sind neben der Sicherheitsfunktion – zerlegt in Teilfunktionen – auch Anforderungen zur Sicherheitsintegrität an Elemente im Hinblick auf Entwurf und Architekturmerkmale zu entwickeln. Nicht alle Anforderungen müssen Teil der Sicherheitsanforderungsspezifikation sein. Wenn Wechselwirkungsfreiheit gewährleistet ist, dann sind auch Nicht-Sicherheitsanforderungen innerhalb sicherheitsrelevanter Elemente abbildbar.

Je Sicherheitsfunktion sind Anforderungen an:

• alle beteiligten Elemente wie Teilsysteme/Hardware/Software zu stellen
• die Integration der Elemente
• Performance wie Rechenleistung, Reaktionszeit, Speicherkapazität, Kommunikationsraten usw…
• Sensoren, Steuerungen und Regelungen wie Genauigkeiten, Dynamik, Robustheit und Stabilität
• Schnittstellen (Userinterface, Inter- & Intra-System-Kommunikation, Energie, Mechanik, Umwelt (EUC), usw…)
• das Ausfallverhalten und Ausfallreaktion (z.B. Fail-Safe oder Fail-Silent)
• Wechselwirkungen zwischen HW und SW (z.B. Interrupt, POST usw…) sowie Wechselwirkungsfreiheit (z.B. Partition) sofern bereits bekannt
• die Spezifikation von Grenzwerten (Zeitbeschränkungen, Temperaturbeschränkungen, Schock…)
• Einschränkungen im Hinblick auf CCF (z.B. getrennt abgesicherte Schaltkreise)
• die Initialisierung und Neustart der Sicherheitsfunktion bzw. des Systems

Für die Sicherheitsintegrität und den zu erfüllenden Ausfallgrenzwert sind weiterhin folgende Anforderungen zu spezifizieren:

• Hardwarearchitekturvorgaben im Hinblick auf Fehlertoleranzmerkmale und/oder den Anteil sicherer Ausfälle (SFF) oder Zuverlässigkeitsdaten der Bauteile
• Testintervalle und anwendungspezifische Wiederholungstestintervalle
• Handlungen und Maßnahmen nach Detektion/Diagnose eines gefahrbringenden Ausfalles
• Wiederholungsprüfung, die Betriebsmittel dafür, die Funktionen der Prüfung und Einschränkungen
• Extrem-Umgebungsbedingungen [Temperatur, Feuchte, elektrisch, mechanisch] für alle Lebenszyklusphasen [Herstellung, Lagerung, Prüfung, Transport, Installation, Inbetriebnahme, Betrieb und Instandhaltung]
• Elektromagnetische Störfestigkeit (IEC 61000-1-2 / 5-7) und sonstige Einflüsse dieser Art
• Leistungsvermögen der Betriebsmittel
• Kontrollmaßnahmen zur erforderlichen Qualität

Verfahren und Maßnahmen zur Vermeidung von Fehlern

Die Phase der Spezifikation an den Entwurf des sicherheitsbezogenen E/E/PE-Systems ist erfahrungsgemäß eine Fehlerquelle und wird i.d.R. mit einer ausgewählte Gruppe von Verfahren und Maßnahmen behandelt. Diese sind im Anhang B des 2. Teils in Tabelle B.1 mit Richtliniencharakter enthalten für jeden Sicherheitsintegritätslevel  (SIL 1 bis 4) mit unterschiedlicher Wirksamkeit entweder verbindlich oder mit Empfehlungsgraden von „besonders Empfohlen“ bis hin zur „ausdrücklichen Ablehnung“.

Verbindlich für alle SIL sind:

• ein Projektmanagement
• eine Dokumentation

Quasi verbindlich durch „besonders empfehlenswert“ ist:

• die Trennung von Sicherheitsfunktion und anderen Funktionen
• Strukturierte Spezifikation
• Inspektion / Prüfung der Spezifikation

Verifikation der Anforderungsspezifikation an den Entwurf

Durch Verifikation muss die Angemessenheit der Anforderungsspezifikation im Hinblick auf die Sicherheit, Funktionalität und planungsspezifische Sicherheit festgestellt werden. Dabei ist im Wesentlichen auf Widersprüche zu prüfen im Hinblick auf die Sicherheitsanforderungen sowie dem Entwurf des E/E/PE-Systems, der Testbarkeit sowie des Zusammenhangs der System- und Anwenderdokumentation.

Validierungsplanung

Entwurf und Validierung gehen Hand in Hand und erfolgen zeitgleich. Ziel ist durch Festlegen technischer Verfahren, einen Nachweis erbringen zu können, dass das sicherheitsbezogene E/E/PE-System die spezifizierten Anforderungen an die Sicherheit und an den Entwurf erfüllt. Dabei sind nach IEC 61508 Teil 2 folgende Punkte bei der Planung zu berücksichtigen:

• alle Anforderungen an die Sicherheit und Entwurf
• Validierungsverfahren zum Nachweis der korrekten Implementierung der Sicherheitsfunktion mit pass/fail-Kriterien der Testfälle
• Validierungsverfahren zum Nachweis der erreichten Sicherheitsintegrität mit pass/fail-Kriterien der Testfälle
• Testumgebung, Testwerkzeuge und Betriebsmittel ggf. mit Kalibrierdaten/Zertifikat
• Testbewertungsverfahren
• Testverfahren sowie Bewertungskriterien im Hinblick auf die Validierung der elektromagnetischen Störfestigkeitsgrenzwerte
• Vorgehen zur Behandlung von Ausfällen während der Validierung

Insbesondere wird das Testinterface und dessen Leistungsfähigkeit bzw. die Leistungsfähigkeit der Testumgebung bereits während der Anforderungsspezifikation spezifiziert. Oft ist z.B. eine Fehlerinjektion kaum möglich oder nur mit enormen Aufwand.

Entwurf und Entwicklung – ein Technisches Sicherheitskonzept entsteht

Hauptgegenstand jeder sicherheitsrelevanten Entwicklung ist ein Technisches Sicherheitskonzept. Dessen Entwicklung erfolgt in dieser Phase nach den bereits in der Vorphase spezifizierten Anforderungen an den Entwurf des E/E/PE-Systems. Dabei ist ganzheitlich die Hardwarearchitektur, Softwarearchitektur Embedded-Software, Anwendungssoftware, Datensätze, Sensoren, Aktoren und programmierbare Elektronik passend für die folgenden Anforderungen zu entwerfen / auszuwählen:

• Konformität der Hardwaresicherheitsintegrität (Architekturbeschränkungen und Quantifizierungsrandbedingungen wie Ausfallraten, Diagnosedeckungsgrade, Anteile sicherer Fehler usw…) durch einer der folgenden Pfade:
  • 1H mit Hardwarefehlertoleranz (HFT) und dem Anteil sicherer Ausfälle SFF (FMEDA erforderlich), welche mit Ausfallraten mit einem Konfidenzniveau von mind. 70% ermittelt werden können oder
  • 2H mit Hardwarefehlertoleranz (HFT), Zuverlässigkeitsdaten aus dem Feld mit 90% Konfidenzniveau und einer konservativen SIL-orientierten HFT-Vorgabe.
• ggf. On-Chip-Redundanz mit besonderen Architekturanforderungen bei Mehrkanal-Strukturen mit kritischen CCF-Faktoren (s. IEC 61508 Teil 2 Anhang E)
• Konformität der systematischen Sicherheitsintegrität der Software / systematischen Eignung durch einen der folgenden Pfade (S1, S2, S3):
  • Erfüllung der Anforderungen an die Vermeidung und Beherrschung von systematischen Fehlern nach IEC 61508 Teil 3
  • Betriebsbewährtheit für Betriebsmittel
  • Wiederverwendung eines existierenden Software-Elements, welches:
    • Betriebsbewährt ist nach IEC 61508 Teil 2 Abschnitt 7.4.10 oder
    • Konformität zur IEC 61508 Teil 3 dafür nachgewiesen ist oder
    • eine Beurteilung nach den Maßstäben der IEC 61508 Teil 3 Abschnitt 7.4.2.13 für nicht konform entwickelte Elemente durchgeführt wird mit positiven Ergebniss
    • und zusätzlich ein Sicherheitshandbuch für dieses Software-Element vorliegt
• Systemfehlerreaktion
• Datenkommunikationsprozess
• Wechselwirkungsfreiheit / Unabhängigkeit zwischen Softwareelementen mit Sicherheitsbezug und nicht sicherheitsrelevanten Funktionen oder unterschiedlichen Sicherheitsfunktionen mit unterschiedlicher Sicherheitsintegrität

Ein Technisches Sicherheitskonzept mit Wechselwirkungsfreiheit bedingt Unabhängigkeit

Die Unabhängigkeit in den Dimensionen Zeit, Wert und Raum ist vorwiegend durch gemeinsam genutzte Ressourcen schwer zu erreichen. Die erforderliche Analyse zu diesen abhängigen Ausfällen (z.B. FMECA) ist umfangreich und bildet die Grundlage zur Auswahl der Methode wie z.B. Partitionierung. Ein Technisches Sicherheitskonzept beinhaltet dieses Kapselungsmerkmal i.d.R. als Funktion mit dem höchsten SIL. Beispielsweise sind ein Core-Exception-Interrupt oder ein Fehler im Round-Robin-Logiksystem einer gemeinsam genutzen Ressource wie z.B. einer ADC-Peripherie schwer zu behandeln. Der sichere Zustand der Maschine und systemische Abhängigkeiten der Sicherheitsfunktionen in bestimmten Betriebarten spielen dabei eine entscheidende Rolle. Ein Technisches Sicherheitskonzept mit temporären und/oder verteilten Redundanzen kann erforderlich werden. Dies erzeugt unnötige Komplexität. Die Realisierung dieser Merkmale erfolgt meist im Kontext rechenintensiver Sicherheitsfunktionen wie z.B. Fahrerassistenzsystemem in vernetzten Multi-Core-System-Umgebungen und diese erfordern komplexe Fehlermodelle und erzeugen somit enorme Analysekosten. Daher ist eine Bewertung der Angemessenheit im Entwurf der Sicherheitsfunkionen, deren Anforderungen an die Sicherheitsintegrität des sicherheitsbezogenen E/E/PE-Systems und der Betriebsmittel sowie der Interaktion mit dem Menschen erforderlich.

Ein Argumentieren mit Merkmalen der Unabhängigkeit ist oft die besser Wahl als der Weg über Analysen mit ungewissen Ausgang zum Projektende.

Der Teufel im Entwurf steckt häufig im Detail der ausgewählten Technologie. Ein gutes Technisches Sicherheitskonzept ist dahingehend technologiespezifisch. Die Komplexität im Entwurf und in der Entwicklung ist durch Modularisierung und ganzheitliche Lösungen auf angemessenen Niveau zu halten. Komplexe Technologien erfordern oft ein komplexes Technisches Sicherheitskonzept, welches beherrschbar umzusetzen ist und keine systematischen Fehler fördert. Im Entwurf lässt sich mit „Architekturpattern“ ein gutes Mittelmaß erreichen. Die Verifikationsaktivitäten können mehr als propotional zur Komplexität ausufern. Daher ist die Granularität und Zuordnung der Teilfunktionen auf Subsysteme und mehrere Elemente in der Vorphase entscheidend. Dies bildet die Grundlage zum modularen Entwurf.

Komplexe Hardware-Software-Wechselwirkungen sind während des Entwurfs zu analysieren und zu bewerten und dazu ggf. Maßnahmen zu entwerfen z.B. gegen unbeabsichtigte Funktionalitäten. Oft werden überdimensionierte Elemente ausgewählt, welche der Sicherheitsintegrität nicht gerade förderlich sind (z.B. CPLD statt Safety-zertifizierter µC oder einfache Elektronik mit Testeinrichtung).

FPGA-Strukturen sind z.B. vorteilhaft bei geforderter Diversität zur Vermeidung und Beherrschung von systematischen Fehlern in mehrkanaligen rechenintensiven Strukturen in Kombination mit anderen programmierbaren Logiksystem wie ein µC oder ein SoC für den Anwendungsfall. Der deterministische Nachweis zur Einhaltung der Fehlertoleranzzeit in FPGAs ist ungleich komplexer als in CPLD-Technologie. Weiterhin ist das Ausfallverhalten aufgrund der unterschiedlichen Speichertechnologien zu berücksichtigen. CPLDs verwenden nicht flüchtigen EEPROM, während FPGAs vorwiegend SRAM verwendet, welches nach Verlust der Energie neu geladen werden muss.

Technisches Sicherheitskonzept im Entwurf – Designanalyse

Der Entwurf ausgehend von der zerlegten Sicherheitsfunktion auf die Elemente des Systems mit Auswahl der Technologien erfordert nach dem Erstentwurf eine Designanalyse im Hinblick auf die Ausfälle der Elemente. Die Fähigkeit zur Fehlertoleranz und Fehlervermeidung ist technologieabhängig. Das System muss im Ganzen in der Lage sein, die erforderliche Intergität zu gewährleisten und bei Verlust dieser Integrität das System in den sicheren Zustand bringen. Ein Technisches Sicherheitskonzept berücksichtigt dies.

Wenn Sie Zweifel haben an der Eignung Ihrer Technologie für Sicherheitsanwendungen, lassen Sie eine Technologiebetrachtung durchführen, um Risiken im Projektverlauf zu vermeiden.

Beispielhaft sei eine „Safe Torque Off“ Sicherheitsfunktion genannt. I.d.R. werden Leistungshalbleiter in einer Leistungsstufe (z.B. 3 Phasen B6 MOSFET oder IGBT Brückenkonfiguration) durch einen µC oder DSP angesteuert. Die Leistungsstufe wandelt Energie (Gleichstrom aus dem DC-Zwischenkreis) in ein Satz drehfelderzeugender Energiesignale auf 3 Phasen für einen elektromagnetischen Wandler (E-Motor) einer bestimmten Technologie (Synchron, Asynchron oder Permanent Magnet Synchronmotor oder Reluktanz). Dabei kann z.B. ein Phasenschluss, Kurzschluss oder ein Fehler in der Ansteuerungselektronik in der Leistungsstufe ein potenziell gefährliches Drehmoment erzeugen, welcher durch die Sicherheitsfunktion behandelt werden soll. Wenn nun die normale Umrichterfunktion Ansteuerungssignale an diese Leistungsstufe sendet, um ein Drehmoment zu erzeugen, die Sicherheitsfunktion jedoch aktiv dies verhindern muss, so darf z.B. die Sicherheitsfunktion bei einen Core-Exception-Interrupt durch ein Ereignis nicht deaktiviert werden.

Daher ist es erforderlich die Leistungsstufe durch eine anderes Element wie z.B. ein Hardwareabschaltpfad im sicheren Zustand zu halten. Dieser Abschaltmechanismus muss auch mit der erforderlichen EMV-Störfestigkeit aufweisen. Ein Isolationsfehler in dem elektromagnetischen Wandler mit der Folge eines Fehlmoments durch magnetische Asymmetrie kann zu einen EMV-Störfeld im Erdungssystem führen und auf den DC-Zwischenkreis rückwirken. Daher ist Kapselung, Isolation, räumlichen Trennung, Trennung von Energieversorgung, Teilung und Überwachung von Teilfunktionen oder Unterlastung/Überdimensionierung auch abhängig von der Technologie, der Entwicklung und der Erfahrung sowie den Analysetätigkeiten (Produkt- und Design-FMEA oder FTA).

Der Entwurf des sicherheitsbezogenen E/E/PE-Systems ist nur mit ausreichend Technologiekenntnis zu beginnen und iterativ mit den Zielen zur Sicherheitsintegrität zu überarbeiten.

Das Konzept der systematischen Eignung für Elemente

Jede Technologie, jedes Element, welches der Technologie zugrunde liegt, kann unterschiedlich systematisch geeignet sein für die zu entwickelnde Sicherheitsfunktion. Eine Software-Lib kann eine Funktion ggf. schlechter im Sinne der Sicherheitsintegrität erfüllen als ein Hardwareelement. Die Kombination mehrerer Elemente mit Unabhängigkeit und/oder technologischer bzw. funktionaler Diversität kann eine bessere systematischen Eignung bilden als jedes Einzelelement. Ein Technisches Sicherheitskonzept enthält eine Kombination von Elementen, auch als Synthese bezeichnet.

Die IEC 61508 gibt in Teil 2 Abschnitt 7.4.3 den Elementen im Sinne ihrer systematischen Eignung die Bezeichnung SC 1 bis 3. Wobei dem Element eine Einfachfehlersicherheit im systematischen Sinne in Bezug auf die Sicherheitsfunktion zugesprochen werden müsste. Wenn es nun zu einer Kombination zweier unabhängiger technologisch diversitärer Elemente z.B. mit SC 2 kommen kann, so bildet diese Kombination die nächst höhere Stufe der systematischen Eignung. In diesem Fall SC 2 für Element A + SC 2 Für Element B ergibt ein SC 3 für die Element-Kombination A+B. Die Elementkombination kann jedoch nicht Grundlage weiterer Kombinationen werden. Es gilt nur SC N +1.

Die Unabhängigkeit muss in einer Analyse gemeinsamer Uraschen nachgewiesen werden in Hinblick auf die Umwelt der unabhängigen Elemente sowie in Entwurf, Realisierung, Betrieb und Instandhaltung. Neben der funktionalen und technologischen Diversität müssen gemeinsame Dienste (z.B. Speicher, ADC, Energieversorgung, gemeinsame Ansteuerungslogik) und Verfahren (z.B. Compiler, Testeinrichtung, Testumgebung) vermieden werden. Zwangsläufig kommt es häufig zu mindestens einen Berührpunkt im Ausführungsverhalten, welcher jedoch nicht gefahrbringend sein darf.

Softwarelemente sind z.B. unabhängig, wenn diese in Raum und Zeit sowie bei Verletzung der Unabhängigkeit diesen Umstand auch Beherrschen können. Wenn eine Funktion in Software den Zugriff auf eine gemeinsame Ressource versperrt und dies erkannt wird aber nicht gehandelt werden kann, da die andere Funktion weitere Ressourcen sperrt, so ist die Beherrschung dieser Art von Integritätsverletzung nicht ausreichend. Eine Integritätsverletzung ist nicht immer gleich ein gefahrbringeder Ausfall, sondern ein potenziell gefährlicher Zustand, welcher zu einen gefahrbringenden Ausfall führen wird.

Zukünftige Technologien werden vermehrt Funktionen in Software ausführen. Dies wird dazu führen, dass die Gestalter neuer Technologien den Umgang mit dem Thema „systematische Sicherheitsintegrität“ als Teil der Unternehmung, der Unternehmenskultur und als kritischen Erfolgsfaktor behandeln müssen!

Hardwaresicherheitsintegrität – architekturbestimmenden Faktoren (HFT, SFF, Bauteilgüte)

Die Hardware bildet den Kern des sicherheitsbezogenen Systems. Ohne funktionierende Hardware kann die Software nicht funktionieren. Die Sicherheitsintegrität der Hardware ist abhängig von Ihrer Güte (Ausfallwahrscheinlichkeit) sowie der Architektur mit Merkmalen wie Fehlertoleranz und Fehlerbeherrschung im Technischen Sicherheitskonzept. Dabei ist es Ziel, eine Hardwareachitektur zu entwerfen, welche die spezifizierten Anforderungen zur Integrität erfüllt und dabei den erforderlichen Ausfallgrenzwert der Sicherheitsfunktion nicht überschreitet.

Ein Technisches Sicherheitskonzept berücksichtigt die erforderliche Hardwareintegrität!

Die Hardware wird beschränkt angesehen in ihrer Sicherheitsintegrität. Zum einen ist die Ausfallrate der Bauteile beschränkend zum anderen ist die Komplexität bestimmter Elementtypen in Fehlermodellen nicht zu 100% analytisch erfassbar. Daher bildet das Zuverlässigkeitsmodell eine Abschätzung zur Robustheit der Hardware gegenüber Fehlern und Ausfall. In Kombination mit der Vorhersage zur Ausfallwahrscheinlichkeit bildet die Hardwarefehlertoleranz (HFT) den bestimmenden Faktor zur Struktur der Hardwarearchitektur im Hinblick auf die Kanäle und Testeinrichtungen (Diagnosefunktionen). In anwendungsspezifischen FuSi-Normen wie der ISO 13849 Teil 1 findet sich daher das Konzept der vorgesehenden Architekturen, dort auch bezeichnet als Kategorien.

Die IEC 61508 zeigt in Teil 2 Abschnitt 7.4.4  zwei mögliche Pfade im Hinblick auf Architekturbeschränkungen durch die Hardware-Sicherheitsintegrität. Bei der Wahl des Pfades ist der Sektor und die Anwendung maßgeblich (sichere Zustand, Redundanzmöglichkeiten und Reparaturzeitdauer oder Intervall (MTTR) im Verhältnis zur Wiederholungsprüfung, Determinismus). Grob lässt sich sagen, dass es entweder den Pfad für betriebsbewährte und deterministisch bestimmte Architekturen gibt oder den probalilistischen Weg. Beide Wege setzen auf die Hardwarefehlertoleranz jedoch mit unterschiedlicher Beziehung zur Quantifizierung. Letzter genannter Pfad (s. IEC 61508 Teil 2 Abschnitt 7.4.4 „1H“) ist i.d.R. die typische Entwicklung neuer Technologien geeignet und wird im Folgenden weiter im Detail vorgestellt. Ein Technisches Sicherheitskonzept folgt einem der beiden Pfade. Der alternative Pfad 2H ist in der folgenden Tabelle vereinfacht dargestellt.

Durch Begründung kann die HFT im Pfad 2H um eine Stufe reduziert werden wie es z.B. in der IEC 61511 der Fall ist für betriebsbewährte Elemente oder durch andere Fehlertoleranzmaßnahmen wie z.B. ein virtueller Sensor. Weiterhin sind Felddaten zur Ermittlung von Ausfallraten nach annerkannten Normen zu sammeln, auszuwerten und deren Konfidenzintervall abzuschätzen bis eine Konfidenz größer 90 % vorliegt zum erreichten Ausfallgrenzwert (PFH). Weiterhin ist der Einsatz von Typ B Elementen nur mit mehr als 60% DC möglich.

Der Element-Typ bestimmt die Hardwarearchitektur!

Die IEC 61508 unterscheidet Elemente in Typ A und Typ B, welche für die Sicherheitsfunktion bedeutsam sind. Ein Typ A Element ist vollständig in seinem Ausfallverhalten und Verhalten unter Fehlbedingungen definiert und mit verlässlichen Ausfallraten beschrieben. Ein Typ B Element ist unvollständig beschrieben in seinem Ausfallverhalten und weist Ausfallraten mit geringen Konfidenzniveau auf.

Beispiele für Typ A Elemente (einfache Betriebsmittel) sind:

• elektronische Leistungshalbleiter (MOSFET/IGBT)
• Relais, Ventil etc…

Beispiele für Typ B Elemente (komplexe Betriebsmittel) sind:

• HF-Frontend ohne Hersteller-FMEA
• SOC, FPGA, µC

Sind die Elementtypen identifiziert, so erfolgt eine Abschätzung der Anteile sicherer Ausfälle für jedes Element. Weiterhin ist die Anordnung dieser Elemente unterschiedlichen oder gleichen Typs zur Erfüllung der Sicherheitsintegrität architekturbestimmend. Bei einer Reihenanordnung bestimmt das schwächste Element die erreichbare Sicherheitsintegrität (Vgl. Kette mit schwächsten Kettenglied). Bei der Parallelanordnung mit Unabhängigkeit kann sogar ein SIL X + N erreicht werden, wobei X das SIL eines Elements mit dem höchsten SIL ist und N die HFT ist (HFT=N=1, wenn 2 Elemente parallel angeordnet sind , HFT=N=2 wenn 3 Elemente parallel sind usw…). Die Sicherheitsintegrität der Hardware ist jedoch auf Systemebene durch die sytematische Eignung eines Elements (SC) begrenzt auf SC N +1. Diese Methoden zur Kombination von Elementen in Teilsystemen, welche wiederum die Gesamtheit des sicherheitsbezogenen E/E/PE-Systems bilden, sind Kern der Entwurfphase und bilden die Grundlage zur Realisierung der erforderlichen Hardware-Sicherheitsintegrität in Wechselwirkung mit der systematischen Eignung. Ein Technisches Sicherheitskonzept baut auf dieser Grundlage auf.

Anteil sicherer Ausfälle bestimmen (SFF)

Ein Zuverlässigkeitsmodell zur quantitativen Analyse muss entwickelt werden. Dazu ist eine Methode zur Modellierung auszuwählen. Meisst wird eine FMEDA durchgeführt. Input sind mindestens eine Blockarchitektur mit allen Schnittstellen, die Schaltpläne der Blöcke, Ausfallraten aus einer Bauteil-Ausfallratendatenbank und mögliche detaillierte Fehlermodelle zu spezifischen Bauteilausfallraten. Weitere Bauteil und Betriebsdaten wie Temperatur, Zyklen, Spannung, Strom, Technologie (z.B. CMOS, TLL), Lebensdauer/Betriebsdauer, Auslegung (über/unterdimensioniert) müssen vorliegen. Output dieser Analysen sind sicherheitstechnische Kennzahlen der Architektur zur Sicherheitsintegrität wie der Anteil sicherer Ausfälle (SFF = Safe Failure Fraction) oder die Eigendiagnosefähigkeit der betrachteten Elemente (Diagnosedeckungsgrad, DC = Diagnostic Coverage) sowie die Teilwerte zur Ausfallwahrscheinlichkeit der Sicherheitsfunktion (PFH/PFDavg). Im Entwurf ist eine grobe Schätzung mit einfachen Methoden bzw. Verfahren sinnvoll. Da im weiteren Verlauf ein passendes Zuverlässigkeitsmodell mit passender Methode entwickelt wird, ist es i.d.R. frühzeit notwendig, ein passendes Verfahren für die Komplexität der Technologie und des Systemverhaltens auszuwählen. Nachfolgend sind grob die Methoden bzw. Verfahren in Ihrer Genauigkeit und der Komplexität aufgetragen:

Wenn der vorgegebene Sicherheitsintegritätslevel (SIL) und die Grundfunktion in einem einkanaligen System mit einer Schätzung des Anteils sichere Ausfälle (SFF) im ersten Entwurf vorliegt, kann geprüft werden, ob die Hardwarefehlertoleranz (HFT) der Architektur ausreichend ist. Die folgende Tabelle zeigt den Zusammenhang von SFF und HFT als Funktion über den SIL für die Element-Typen A und B. Es ist anhand der Tabelle deutlich, dass für eine Sicherheitsfunktion mit SIL 3, welche wesentlich auf einen Digital-Logik-Element wie ein µC (Typ B) ausgeführt wird, nur mit hohem Anteil sicherer Ausfällen (SFF >99%) in einer einkanaligen Architektur (HFT = 0) realisiert werden könnte. Dies ist grenzwertig praktikabel, da der µC einen Großteil seiner Rechenleistung an Diagnosefunktionen vergeben müsste. Daher ist ab SIL 3 eine HFT von mindestens 1 realistisch. Aus der wirtschaftlichen Perspektive sind entweder hohe Entwicklungskosten für die Diagnosefunktionen bzw. für eine vor-zertifizierte Sicherheitslogik oder hohe Produktionskosten durch Redundanz zu berücksichtigen.

Hierbei zeigt sich auch, dass die Kosten erst nach dem Entwurf der Anforderungen an die Architektur kalkulierbar sind. Die Tabelle zeigt auch das typische Spannungsfeld, welches von der Zuverlässigkeit (Reliability), der Funktionalen Sicherheit (Safety) und der Verfügbarkeit (Availability) aufgespannt wird. Entscheidend für die Einschränkungen der Architektur durch das Merkmal der HFT ist auch die Charakteristik der Sicherheitsfunktion und der sichere Systemzustand (Fail-Safe / Fail-Operational). Ein Technisches Sicherheitskonzept berücksichtigt dies.

Der folgende Prozees zeigt das Vorgehen nach Pfad 1H:

Technisches Sicherheitskonzept und die Quantifizierung zufälliger Hardwarefehler

Nachdem die Architektur entworfen wurde und die Schaltpläne vorliegen, sind die zufälligen HW-Fehler/-Ausfälle und sicherheitsrelevanten Datenkommunikationsprozesse für jede Sicherheitsfunktion separat zu quantifizieren. Dabei muss der durch ein Verfahren zur Zuverlässigkeitsvorhersage abgeschätzter Ausfallgrenzwert (PFH/PFDavg) je Sicherheitsfunktion unter dem geforderten Zielwert liegen. Dieses Vorgehen beinhaltet die Ermittlung der bereits im Entwurf abgeschätzten SFF (s. Kapitel „Anteil sicherer Ausfälle bestimmen (SFF) ).

Dazu ist je Sicherheitsfunktion der Bezug zu Teilsystemen und Elementen in der Architektur (Technisches Sicherheitskonzept) zu berücksichtigen. Die geschätzten Ausfallraten für zufällige permanente Ausfälle (Hard-Errors) sind hinsichtlich der Modi mit gefahrbringender Wirkung (open, short, drift), der Diagnosefähigkeit, sowie der Quellen-Genauigkeit und Quellen-Toleranz zu beschreiben. Weiterhin sind sporadische Fehler und deren Ausfallraten (Soft-Errors) zu berücksichtigen. Der auf dieser Seite vorwiegend beschriebene Pfad 1H zur Hardwaresicherheitsintegrität fordert mind. ein 70% Konfidenzniveau der Ausfallraten.

Weiterhin sind insbesondere die Betriebsbedingungen (z.B. Temperatur, Kontaktströme, Zyklen …) zu berücksichtigen. Die Anfälligkeit zu Fehlern gemeinsamer Ursache (CCF) in Teilsystemen ist durch begründete Annahmen zu behandeln und durch eine Methode wie z.B. dem Beta-Faktor-Model im Ausfallgrenzwert zu berücksichtigen. Hier kann auch z.B. eine Bestätigung notwendig werden, dass eine erhöhte Anforderungsrate der SF durch einen CCF für das sicherheitsrelevante System bereits im Sicherheitskonzept bei der Festlegung des SIL und des Ausfallgrenzwertes im Sinne der Gesamtsicherheit berücksichtigt wurde. Der Diagnosedeckungsgrad (DC), der Diagnosetestintervall und Ausfallrate der Diagnosefunktion im Hinblick auf unerkannte Diagnosefehler durch zufällige Hardwarefehler der Diagnose-Testeinrichtung sind bei der Ermittlung des DCs zu berücksichtigen.

Folgende Methoden/Verfahren werden z.B. in der IEC 61508 Teil 2 vorgeschlagen:

• Fehlerbaum (FTA)
• Ursache-Wirkungsanalyse
• Zuverlässigkeitsblockdiagramm (RBD)
• Markov
• Petri-Netze
• Vereinfachter konservativer Ansatz mittels Formeln nach IEC 61508 Teil 6 Anhang B

Für das Zuverlässigkeitsmodell muss die mittlere Lebensdauer (MTTR) und die mittlere Reperaturzeit (MRT) bekannt sein. In Beispieltabellen zur Schätzung nach Teil 6 Anhang B wird für MTTR = 8 h angenommen. Die Wiederholungsprüfung T1 muss mindestens um eine 10er Potenz höher liegen als die MRT.

In IEC 61508 Teil 6 Anhang B befinden sich Beispiele zu möglichen Verfahren. Erst wenn die Quantifizierung aufzeigt, dass der erforderliche Ausfallgrenzwert jeder einzelnen Sicherheitsfunktion eingehalten wird, ist die Implementierung und die Auswahl der Verfahren zur Vermeidung und Beherrschung systematischer Fehler und die Vervollständigung der Anforderungen an das Systemfehlerverhalten sinnvoll.

Kommunikation in sicherheitsrelevanten PE-Systemen

Wenn das sicherheitsrelevante E/E/PE-System Kommunikationsprozesse verwendet und diese an der Sicherheitsfunktion beteiligt sind oder diese maßgeblich beeinflussen, so muss die Restfehlerrate abgeschätzt werden und muss in der Ausfallwahrscheinlichkeit (PFH/PFDavg) berücksichtigt werden. In IEC 61508 Teil 2 Abschnitt 7.4.11 werden Prinzipien und Anforderungen an Kommunikationskanäle und die Übertragung sicherheitsrelevanter Daten zwischen Sicherheitssubsystemen vorgegeben. Ein Technisches Sicherheitskonzept beschreibt das Kommunikationsverhalten vollständig. Dabei wird i.d.R. das Black Channel Prinzip bevorzugt verwendet. Es ermöglicht die Verwendung beliebiger Kommunikationstechnologien ohne den Zwang zur Normkonformität im Hinblick auf die unteren Ebenen nach ISO/OSI-Modell. Nur ein Safety Communication Layer (SCL) muss nach IEC 61508 entwickelt bzw. als zertifiziertes und damit systematisch geeignetes SW-Modul (z.B. ein safety com-stack) erworben und implementiert werden. White Channels sind vorwiegend in zeitsensitiven Anwendungen (time sensitive networks) vertreten. Die folgende Grafik verdeutlicht die beiden Haupttypen (Black- und White-Channel):

Die durch IEC61508 vorgegebenen Kommunikationsstandards sind:

• IEC61784-3 Industrie / Feldbus (kabelgebunden Anwendungen)
• IEC62280 (EN 50159) Bahntechnik / Kommunikationsnetze, auch Funkverbindungen

Der SCL muss folgende potenzielle Bedrohungen für sicherheitsrelevante Nachrichten und deren Übertragung nach IEC 62280 beherrschen:

• Übertragungsfehler
• Verlust
• Wiederholung
• falsche Abfolge
• Einfügung
• Verfälschung
• Verzögerung
• Masquerade (fehlerhafte Identifizierung der Nachrichtenquelle)

Diese potenziellen Bedrohungen sind nach IEC 62280 durch folgende Absicherungsmechanismen im SCL zu beherrschen/behandeln:

• Sequenznummer (sequence number)
• Zeitstempel (timestamp)
• Zeitablauf (timeout)
• Quell/Ziel-Identifikationsmerkmal (Source/Destination ID)
• Identifikationsprozedur (Ident. Function)
• Feedback-Nachricht (Feedback-Message)
• Code-Sicherung (CRC-Safety-Polynom)
• Kryptografische Techniken

Die IEC62280 bzw. EN50159 listet im Anhang B.2 die Beziehung „Threat and Network-Category“ als Guide zur Auswahl der Absicherungsmaßnahmen auf. Ein Funknetzwerk ist z.B. ein offenes Netzwerk, welches der Kategorie 3 nach EN 50159 entspricht. Hier ist insbesondere mit der Möglichkeit des unbefugten Zugriffs (unauthorized Access) zu rechnen. Daher werden alle oben gelisteten Absicherungsmaßnahmen strengstens empfohlen.

Die Kommunikationstechnologien, mögliche Topologien und insbesondere das Kanalzugriffsverfahren sind bestimmende Faktoren und sind frühzeitig im Technischen Sicherheitskonzept zu behandeln. Hierzu zählen inbsesondere die Fehlertoleranzzeit, Redundanzaspekte und Wechselwirkungsfreiheit. Bei offenen Kommunikationsnetzen ist in der IT-Bedrohungsanalyse nach IEC 62443 die Notwendigkeit und die Wirksamkeit der Absicherungsmaßnahmen gegen Missbrauch und Fremdeingriff begründet. Der im Black-Channel-Prinzip vorhandene Vorteil der Unabhängigkeit zu den unteren Schichten des ISO/OSI-Modells der verwendeten Kommunikationstechnologien bildet jedoch den Nachteil, dass der SCL in den oberen Schichten viel Rechner-Ressourcen verbraucht. Weiterhin ist frühzeitig zu bedenken, dass offene Kommunikationsnetze in Fail-Operational-Anwendungen ungeeignet sind. In Fail-Safe-Anwendungen ist durch Kommunikationsfehler jeglicher Art die Verfügbarkeit der bestimmungsgemäßen Funktion stark abhängig von der Kanalqualität welche wiederum von der Umwelt abhängig ist. Wirtschaftliche Aspekte sollten bei diesem Aspekt im Konzeptentwurf nicht fehlen.

Kommunikation im Hinblick auf Funktionale Sicherheit (engl. Safety) sollte innerhalb der IEC 61508 behandelt werden, während die IT-Sicherheit (engl. Security) nur mittels Berührpunkten mit der Funktionalen Sicherheit in Berührung kommen sollte.

Bei der Abschätzung der Restfehlerrate ist die zu erwartende Bitfehlerrrate (BER) nach den Kommunikations-Sicherungsmechanismen entscheidend. Die Wirksamkeit von z.B. CRC-Polynomen im Hinblick auf die erreichbare Hammingdistanz ist vom Anwendungsfall abhängig. Eine grobe Schätzung der Restfehlerwahrscheinlichkeit kabelgebundener und gekapselter Bussysteme ist leicht möglich mit den Prüfgrundsatz GS-ET 26 von der BGETEM für Anwendungen im Bereich der ISO13849-1.

Maßnahmen zur Vermeidung systematischer Fehler im Entwurf

Es sind eine Reihe von Maßnahmen auszuwählen, welche in ihrer Kombination geeignet sind, das Entstehen von Fehlern während des Entwurfs, der Entwicklung bzw. vor- und während der Installation der Hardware und Software des  sicherheitsbezogenen E/E/PE-Systems zu verhindern. Die Gesamtheit aller Maßnahmen im Hinblick auf die Vermeidung systematischer Fehler in den verschiedenen Lebensphasen findet sich im Anhang B der IEC 61508 Teil 2. Diese Maßnahmen sind zu unterscheiden von denen im Anhang A des gleichen Teils der IEC 61508, welche im Wesentlichen Merkmale des sicherheitsbezogenen E/E/PE-Systems sind, wie z.B. Fehlertoleranzmechanismen oder Vermeidung der falschen Kombination von modularen Elementen. Ein Technisches Sicherheitskonzept berücksichtigt dies.

Die Maßnahmen sind teils historisch durch Unfallanalyse zusammengetragen und stellen damit empirisches Wissen dar. Bekannte Katastrophen wie die Ariane 5, Tschernobyl, Deepwater Horizon sind durch systematische Fehler bzw. eine Verkettung von Umständen entstanden, welche durch Anwendung von Maßnahmen mit passender Wirksamkeit verhindert oder zumindest in ihren Auswirkungen beschränkt wären. Viele dieser Maßnahmen entsprechen denen eines zertifizierten QM-Systems.

Die Entwurfsmethode der gewählte Technologie sollte folgende Merkmale unterstützen:

• Komplexitätsreduzierung durch Transparenz und Modularität in der Architektur
• Klare, eindeutige und genaue Beschreibung der Funktion(en), Schnittstellen, die Reihenfolge und damit die Entstehung von Informationen
• Prozesse, Sequenzen und Gleichzeitigkeit sowie erforderliche Synchronisierungsmerkmale
• Eindeutige und verständliche Dokumentation sowie Verteilung von Informationen
• Verifikation sowie Validierung (V&V)

Hier ist z.B. SysML ganz nützlich.

Im Hinblick auf die zu erwartende Instandhaltung sind Anforderungen zu formalisieren, um die Sicherheitsintegrität aufrecht erhalten zu können in den Lebenszyklusphasen nach der Entwicklung. Hierzu zählt folglich auch die Unterscheidung von internen Tätigkeiten und Feldaktivitäten. Dies zeigt sich z.B. im Umgang mit Parametern. Interne, dem Entwicklungszyklus zugeordnete Parameter sollten unveränderlich sein, um die Zertifizierung nicht zu gefährden. Nur eine Einflussanalyse kann die Tragweite einer möglichen Änderung dieser entwicklungsinternen Parameter erfassen und ist durch das FSM zu koordinieren. Im Feld sollten Parameter für anwendungsspezifische Bereiche nach Checklisten und/oder Anweisungen nach Möglichkeit in eigensicheren Prozeduren änderbar sein. Weiterhin sind automatische Testwerkzeuge und integrierte Entwicklungsumgebungen (IDEs) bevorzugt anzuwenden. Die Planung der Integrationstests während des Entwurfs erzwingt die Auseinandersetzung mit der Werkzeuglandschaft (Tool-Chain) und der Anforderungsspezifikation und ist damit der Vermeidung von Fehlern dienlich.

Der Integrationstestplan sollte folgendes enthalten:

• Testart
• Testverfahren
• Testumgebung und Testwerkzeuge
• Testkonfiguration und Testprogramme
• Pass-/Fail-Kriterien

Maßnahmen zur Vermeidung von systematischen Fehlern im Entwurf und während der Entwicklung für SIL 2 nach IEC 61508 Teil 2, Tabelle B.2 sind z.B.:

• Beachtung von Richtlinien und Normen (verbindlich)
• Projektmanagement (Projektsteuerung mit niedriger Wirksamkeit, verbindlich)
• Dokumentation (verbindlich)
• Strukturierter Entwurf (empfohlen)
• Modularisierung (empfohlen)
• Checklisten oder IDE (mind. eine Verifikationsmethode für diese Phase des Sicherheitslebenszykluses)

Maßnahmen zur Beherrschung systematischer Fehler im Entwurf

Es sind folgende Fehlertoleranzmerkmale in sicherheitsbezogenen E/E/PE-System umzusetzen, welche zur Beherrschung systematischer Fehler im Entwurf beitragen für:

• verbleibende Hardware-Entwurfsfehler (hier z.B. für SIL 2: Programmablaufkontrolle und Testinterface mit Boundary-Scan-Möglichkeit)
• Umgebungseinflüsse (hier z.B. für SIL 2:
  • Störungen der Spannungsversorgung (Über- / Unter-Spannung und falsche Frequenz)
  • Trennung von Leitungen für Energie- und Informationen
  • erhöhte Störfestigkeit (EMV)
  • Signaldiagnose (Kurzschluss, Stuck-at) oder eine Erwartungshaltung (z.B. Ruhestromprinzip)
  • Maßnahmen gegen physikalische Einwirkungen wie Temperatur, Staub, Schwingung, Feuchtigkeit, Wasser usw…
  • Überwachung des Programmablaufs und der Temperatur
  • geeignete robuste und diagnosefähige Software)
• Fehler und Auswirkungen von Datenkommunikationsprozessen (Neben Inter- und Intra-Kommunikation z.B. auch eine unvollständig in den Speicher geschriebenen Konfiguration bei der Wartung/Instandhaltung)
• Fehlbedienung durch Irrtümer des Bedieners (z.B. Dead-Lock mit Reset im Sequenzübergang und/oder Abschaltung der Energiezufuhr ohne Speicherung des Fehlers im persistenten Speicher oder auch einfach eine fehlerhafte oder widersprüchliche Anzeige im Bedienfeld)
• Entwurfsfehler in der Software

Die Wartbarkeit und Instandhaltung ist zu berücksichtigen bei der Auswahl und Umsetzung dieser Maßnahmen. Weiterhin sind Bildungs- und Kenntnissstand des Bedien- und Wartungspersonals sowie Ergonomie zu berücksichtigen. Mögliche vorhersehbare Fehlbedienungen sollten im Entwurf bereits verhindert (Stichwort „Eigensicher“) oder durch Bestätigungsmechanismen begrenzt möglich sein. Faktoren der Ergonomie sind zu berücksichtigen. Oft stehen selten genutzte Betriebsarten und schwere Unfälle im Zusammenhang.

Technisches Sicherheitskonzept – Festlegen der Systemfehlerreaktion

Die Systemfehlereaktion richtet sich nach der Gesamtsicherheitsfunktion. Steht das sicherheitsbezogenen E/E/PE-System in Wechselwirkung mit den anderen risikomindernden Maßnahmen, so müsste dies bereits in der Spezifikation an das sicherheitsbezogene E/E/PE-System erfolgt sein. Führt allein das im Entwurf befindliche sicherheitsbezogenen E/E/PE-System die Sicherheitsfunktion aus, so sind folgende Aspekte bei der Umsetzung des Systemfehlverhaltens im technischen Sicherheitskonzept zu berücksichtigen:

• Erkannte gefahrbringende Fehler in Teilsystemen in mehrkanaligen Strukturen (HFT>0) sollten entweder:
  • zum Übergang und der Erhaltung des sicheren Zustandes führen (z.B. Fail-Safe in 1oo2 Architekturen)
  • oder zur Fehlerisolation im Teilsystem führen mit Überwachung der in der Berechnung zur Ausfallwahrscheinlichkeit zugrundeliegende mitteler Reperaturdauer (MRT) und nach Ablauf zur weiteren Systemreaktion führen wie z.B. Abschaltung des EUC (Fail-Operational-Fail in 2oo2D oder 2oo3 (TMR)-Architekturen).
• Erkannte gefahrbringende Fehler in Teilsystemen in einkanaligen Strukturen (HFT=0) im Low-Demand-Mode sollten entweder:
  • zum Übergang und der Erhaltung des sicheren Zustandes führen (z.B. Fail-Safe in 1oo1 Architekturen)
  • oder zur Reparatur führen mit Überwachung der in der Berechnung zur Ausfallwahrscheinlichkeit zugrundeliegende mitteler Reperaturdauer (MRT) und dem Einsatz von gleichwertigen Ersatzmaßnahmen zur Erhaltung der Sicherheit des EUC, welche dem SIL entsprechen müssen.
• Erkannte gefahrbringende Fehler in Teilsystemen in einkanaligen Strukturen (HFT=0) im High-Demand-Mode sollten immer:
  • zum Übergang und der Erhaltung des sicheren Zustandes führen (z.B. Fail-Safe in 1oo1 Architekturen durch Abschaltung des EUC)

Implementierung der Elemente und Teilsysteme des sicherheitsbezogenen E/E/PE-Systems

Die Umsetzung der in der Spezifikation und Architektur festgelegten Struktur (Technisches Sicherheitskonzept) und den geplanten Prozessabläufen sollte folgende Aspekte berücksichtigen:

• Identifikation aller Elemente und Teilsysteme und deren Beschreibung
• Information über die Elemente:
  • funktionale Spezifikation des Elements
  • Anweisungen, um anwendungsspezifische systematische Ausfälle zu verhindern
  • Konformitätspfad (S1, S2, oder S3) zur systematischen Eignung
  • Konfigurationsdaten (HW und SW) für das Konfigurationsmanagement nach IEC 61508 Teil 1
  • Nachweis zur Verifikation im Hinblick auf die Übereinstimmung des Elements mit der systematischen Eignung und der Spezifikation
• Informationen zu den Sicherheitskennzahlen der Elemente im Hinblick auf die Quantifizierung:
  • Aufsallarten an den Schnittstellen des Elements ohne interner oder externer Diagnose mit den jeweiligen Ausfallraten (DU = Dangerous Undetected)
  • Aufsallarten an den Schnittstellen des Elements mit interner oder externer Diagnose mit den jeweiligen Ausfallraten (DD = Dangerous Detected):
    • Diagnosedeckungsgrad (DC) je Diagnosefunktion
    • Testintervall je Diagnosefunktion
    • Ausfallrate je Diagnosefunktion im Hinblick auf zufällige Hardwareausfälle
  • Alle Annahmen zu den Betriebs- und Umgebungsbedingungen, welche die Berechnungen der Ausfallraten beeinflusst haben (Gültigkeitsbereich der Ausfallraten)
  • Lebens- und Gebrauchsdauer ( 8 bis 12 Jahre)
  • Anforderungen an Instandhaltung / Wartungsintervalle / Wiederholungsprüfungen (T1-Intervall)
  • Reparaturzeiten zur Abschätzung der mittleren Reparaturdauer (MRT)
  • Elementtyp (A oder B) und der Anteil sicherer Fehler (SFF)
  • Hardwarefehlertoleranz (HFT)

Die Ausfallraten für zufällige Hardwareausfälle eines Elements können festgelegt werden durch eine FME(D)A mit Daten aus einer Industriedatenbank (z.B. Siemens SN 29500) oder durch aus Erfahrung im Sinne von Betriebsbewährtheit. Wichtig ist, dass das Konfidenzniveau aller Ausfallraten größer-gleich 70% statistisch nachgewisen erreicht wurde.

Betriebsbewährte Elemente – das proven-in-use Szenario

Oft wird die Betriebsbewährtheit von Betriebsmitteln im Sinne einer pragmatischen Strategie über den Konformitätspfad S2 angestrebt. Die Aufwände und Randbedingungen werden oft unterschätzt. Ein Technisches Sicherheitskonzept kann nur betriebsbewährte Elemente mit folgenden Aspekten aufnehmen:

• klar begrenzte und festgelegte Funktionalität
• angemessener dokumentarischer Nachweis als Grundlage für die Ermittlung der Wahrscheinlichkeit aller gefahrbringender systematischer Fehler
• Aus einer dem breiten Anwendungsgebiet entstprechenden Konfiguration des Elements muss folgendes dokumentiert vorliegen:
  • Analyse der Betriebserfahrungen im Hinbklick auf das funktionale Verhalten, der Genauigkeit, der Reaktionszeit, der Fehlerreaktion, das Überlastverhalten, die Ergoinomie und Wartbarkeit
  • Eignungsnalyse im Hinblick auf die sicherheitstechnische Leistungsfähigkeit im geplanten Anwendungsfall
  • Tests
• Es ist aufzuzeigen, dass:
  • das Betriebsprofil (s. IEC 61784-3) vergleichbar ist mit dem des geplanten Anwendungsfalles
  • obere Grenze der Rate gefahrbringender Ausfälle nicht überschritten ist aus der Betriebserfahrung (zur Quantifizierung siehe auch IEC 61508 Teil 7 Anhang D)
• Wenn Unterschiede im Betriebsprofil bzw. den Verwendungsbedingungen vorliegen, so muss durch eine Einflussanalyse eine Strategie mit Tests und analytische Methoden entwickelt werden, um aufzuzeigen, dass die Wahrscheinlichkeit gefahrbringender systematischer Fehler unter dem geforderten Sicherheitsinteritätslevel der Sicherheitsfunktion(en) liegt, welche durch das Element ausgeführt werden.
• Die Dokumentation muss um eine Art Gutachten (Dokument) zur Betriebsbewährung ergänzt werden, welches aufzeigt, das dass Element die Sicherheitsfunktion oder Teile davon in der geforderten Sicherheitsintegrität ausführen kann. Dazu sind die Eignungsanalyse, Tests, Gleichwertigkeit bzw. Unterschiede und deren Ergebnisse in der Einflussanalyse sowie den statistischen Nachweis (Konfidenzniveau) zu berücksichtigen.

Bei der Beurteilung ist es notwendig, die Gesamtheit aller vorliegenden Informationen zu würdigen. Oft sind bei komplexen Elementen nicht genügend oder nur unvollständige Informationen vorhanden oder die erforderliche systematische Eignung kann nicht erfüllt werden oder die statistische Grundlage erreicht kein 70% Konfidenzniveau. Neue Technologien können naturgemäß nicht als Betriebsbewährt gelten. Sofern das Element auch „Nicht-Sicherheitsfunktionen“ enthält, ist es äußerst schwierig nachzuweisen, dass die sicherheitsbezogene Funktion davon Wechselwirkungsfrei ist. Modifikationen dieser betriebsbewährten Elemente unterliegen bei Einsatz in der zu entwickelnden Sicherheitsfunktionen dem Sicherheitslebenszyklus und damit gilt auch die IEC 61508 Teil 3 (Softwareentwicklung) sowie Teil 2, Abschnitt 7.8 (Modifikation).

Verifikation des Entwurfs und der Entwicklung

Durch Verifikation muss die Angemessenheit der Testfälle, Testarten und Testtiefe festgestellt werden noch vor der Integration. Weiterhin ist im Wesentlichen auf Vollständigkeit und Korrektheit zu achten im Sinne der Nachverfolgbarkeit (Traceability). Dabei müssen folgende Fragestellungen beantwortet werden:

• Sind alle Sicherheitsanforderungen im Entwurf umgesetzt worden ?
• Sind diese vollständig und korrekt bis ins Modul abgebildet ?
• Ist die Testbarkeit gegeben und sind die Tests passend ?
• Ist der Diagnosedeckungsgrad (DC) im Hinblick auf die Fehlererkennung angemessen ?

Integration des E/E/PE-Systems

Ganz nach V-Modell-Manier kommt nach der Konzeptphase, der Spezifikationsphase, nach dem Entwurf der Architektur und der Realisierung die Integrationsphase. IEC 61508 Teil 2 behandelt das System und die Hardwareentwicklung im Hinblick auf die Integrationsphase, während IEC 61508 Teil 3 in Abschnitt 7.5 die Softwareintegration behandelt. Folglich sind 3 Ebenen bei der Integration überlappend zu koordinieren, um eine nahtlose Integration zu ermöglichen. Ein geschulter interdisziplinärer Blick bzw. Überblick zwischen den 3 Ebenen ist notwendig, um systematische Fehler bei der Integration zu vermeiden.

Die Integration muss selbstverständlich nach Entwurfvorgaben erfolgen und nach dem Integrationstestplan getestet werden. Die Integrationstests haben das Ziel, die korrekte Interaktion aller Module und damit die korrekte System-Funktionalität nachzuweisen. Oft zeigen sich erst in Kombination mehrerer Module in den Integrationstests nicht vorhersehbare Funktionalitäten, welche bewertet werden müssen und zu einer Modifikation führen könnten. Der Testaufwand ist abhängig von den Entwurfsmethoden. Ein strukturierter Entwurf oder semiformale bzw. formale Methoden erleichtern den Testnachweis erheblich. Klassisch werden folgenden Testarten verwendet:

• Äquivalenzklassen
• statische Analysen
• dynamische Analysen

Die notwendigen Informationen der Integrationstestphase müssen vollständig erfasst werden. Dazu zählen u.a. Akzeptanzkriterien (pass/fail), alle Testergebnisse, Testwerkzeuge, Betriebsmittel mit Kalibrierdokument, die Version der Testspezifikation sowie des Testsubjekts (DUT). Dabei sind auftretende Testauffälligkeiten zu analysieren und im Änderungsmanagement zu behandeln. Weiterhin sind alle Modifikationen am Testsubjekt (DUT bzw. des sicherheitsbezogenen E/E/PE-Systems) in einer Einflussanalyse zu behandeln darunter auch die erneuten Verifikationstätigkeiten sowie die betroffenden Elemente.

Der Zeitraum nach der Entwicklung

Die Aufrechterhaltung der Sicherheitsintegrität bzw. der produktspezifischen Funktionalen Sicherheit in der Umgebung außerhalb der Entwicklungsabteilung ist zu planen und von einem Verantwortlichen auszuführen. Daher sind folgende Betriebs- und Instandhaltungsverfahren für das E/E-PE-System zu planen und in der Gesamtbetriebs- und Instandhaltungsverfahren des EUC zu integrieren:

• Wartungsaktivitäten mit dem Austausch lebensdauerbeschränkter Komponenten wie z.B. Batterien
• Beschreiben von Handlungen und Einschränkungen, um unsichere Zustände und Schadensereignisse zu verhindern
• die Art und Weise der Aufzeichnung von Ausfällen und Anforderungsraten im Feld
• die Art und Weise der Aufzeichnung von den Audits und Tests
• Instandhaltungsverfahren bei Fehlern oder Auffälligkeiten wie:
  • Fehlersuche, Diagnose
  • Reparatur
  • Revalidierung, auch bei nicht mehr verfügbaren Ersatzteilen
  • die Anforderungen an die Aufzeichnung von Instandhaltungsarbeiten
• Analyseverfahren im Hinblick auf Ausfälle und deren Aufzeichung
• Instandhaltungswerkzeuge und Revalidierungswerkzeuge sowie die Instandhaltung dieser Werkzeuge, um die Verfahren im Feldbetrieb zu gewährleisten.

Oft sind bei Instandhaltungsarbeiten auch Softwaremodifikationen notwendig, dessen Verfahren in IEC 61508 Teil 3 Abschitt 7.8 vorgesehen ist. Die Gesamtheit aller Feldverfahren unterliegt dem Audit zur Funktionalen Sicherheit und ist i.d.R. fortlaufend iterativ anzupassen. Hier spielt insbesondere die Wiederholungsprüfung (T1) eine entscheidende Rolle. Der Zeitpunkt und die Intervalle sind abhängig von den spezifischen Merkmalen des sicherheitsbezogenen E/E/PE-Systems und wurden hoffentlich wirtschaftlich bei der Berechnung der Ausfallwahrscheinlichkeit berücksichtigt. Die Festlegung der Instandhaltungstätigkeiten und deren Intervalle werden mittels Analyse wie FTA oder FMEA mit dem Fokus auf Minderung der Sicherheitsintegrität durch menschliches Versagen im Feldbetrieb unterstützt, um die Wirksamkeit aufzuzeigen. Die Architektur, der Ausfallgrenzwert, die angenommende Anforderungsrate sowie die Diagnosen beeinflussen die Häufigkeit der Wiederholungsprüfungen. Vorsorgliche Prüfungen ohne begründeten Ursprung sind obsolet.

Die V&V Aktivitäten (Verifikation und Validierung) der Systemebene

Bei der Validierung ist aufzuzeigen, dass das E/E/PE-System den erforderlichen Umständen und Anforderungen an die Sicherheitsfunktion und Integrität Rechnung trägt. Der Zeitpunkt der Validierung ist abhängig von der Gestaltung der Sicherheitsfunktion. Hängt ein wesentlicher Teil der Integrität am Anwendungsfall und ist z.B. sicherheitsbezogene anwendungsspezifische Software entwickelt, so ist die Validierung nach der Installation beim Kunden durchzuführen. Ist die Sicherheitsfunktion mit Annahmen außerhalb eines Anwendungskontextes entwickelt worden und unveränderlich, so ist eine Teil-Validierung vor der Installation sinnvoll.

In der IEC 61508 wird das Thema Validierung für programmierbare elektronische Systeme in 2 Normenteilen behandelt, mit unterschiedlichen Ebenen. In Teil 2 wird das System und die Elektronik(Hardware) validiert. In Teil 3 wird nur die Software und in Teil 1 wird die Gesamtsicherheit validiert. Der Validierungsplan ist ganzheitlich während des Entwurfs interativ zu entwickeln. Dabei müssen auch die Prüf- und Messeinrichtungen kalibriert werden auf eine Norm bzw. nach einen annerkannten Verfahren. Die Verifikation der korrekten Funktion aller Prüfmittel ist selbstverständlich notwendig.

Durch Tests oder Analysen müssen folgende Aspekte/Merkmale validiert werden:

• die korrekte Implementierung jeder Sicherheitsfunktion im Hinblick auf die Spezifikation
• der korrekte Entwurf gemäß Spezifikation
• die Betriebsverfahren
• die Instandhaltungsverfahren
• Wechselwirkungsfreiheit

Die Validierungstests je Sicherheitsfunktion sind mit folgenden Inhalten zusammenfassend zu dokumentieren:

• geltender Validierungsplan (Version und Dokumentenname)
• Bezug zwischen Sicherheitsfunktion mit dem Test bzw. der Analyse und den geplanten Anforderungen im Validierungsplan (aufzeigen, dass erst geplant und nach Plan sowie nach der Realisierung validiert wurde)
• Testmittel/Betriebsmittel mit Kalibrierungsdaten und Werkzeuge
• Testergebnisse und Abweichungen von den Erwartungen außerhalb der Toleranzen sowie deren Analysen und ggf. die zugehörige Änderungsanforderung im Sinne der Sicherheitslebenszyklusplanung

Die Validierungsergebnisse müssen in einem Bericht zusammengestellt und dem Integrator der Sicherheitsfunktion zugänglich sein, um die Validierung zur Gesamtsicherheit nach IEC 61508 Teil 1 zu ermöglichen. Ein gutes Technisches Sicherheitskonzept ist die Grundlage einer erfolgreichen Validierung.

Die Verifikation ist eine Aktivität, welche in den verschiedenen Phasen des Sicherheitslebenszyklus ausgeführt wird. Ziel der Verifikation ist es, Konsistenz und Korrektheit sicherzustellen zwischen den normativen Anforderungen und der Dokumentation innerhalb eines Phasenabschnitts zum Anfang der Phase. Die Verifikation des E/E/PE-Systems muss entwicklungsbegleitend geplant und phasenweise erfolgen. Insbesondere muss in jeder Entwurfs- und nachfolgenden Entwicklungsphase aufgezeigt werden können, dass die Anforderungen bezüglich der Funktion und der Sicherheitsintegrität erfüllt worden sind. Damit ist im Vergleich zur Validierung die Verifikation ein Mittel zum Zweck der Konsistenzsicherung.

Dabei sind in der Planung folgende Aspekte zu berücksichtigen:

• Strategien und Verfahren zur Verfikation sowie deren Kombination
• die Testeinrichtungen und deren Verwendung in den Verfahren
• die Dokumentation (z.B. Reviewprotokoll)
• die Bewertung der Verifikationsergebnisse hinsichtlich der Gründe bzw. Auffälligkeiten

Die Auffälligkeiten müssen konkret auf die Anforderungen des Sicherheitslebenszyklus, auf Anforderungen des Sicherheitsmanagements oder auf ungenügend umgesetzte andere Normen bezogen sein.

Folgende Verifikationen sind mindestens durchzuführen für:

• die Anforderungen an den Entwurf noch vor dem Entwurf und der Entwicklung
• den Entwurf und die Entwicklung noch vor der Integration
• die planmäßige Integration durch Verifizierung der Anforderungen nach IEC 61508 Teil 2 Abschnitt 7.5 (s. Kapitel Integration)

Im Folgenden ist nochmal der Zusammenhang im V-Modell im Hinblick auf die Maßnahmen zur Vermeidung systematischer Fehler und die Verifikation sowie die Validierung abgebildet.

Die Modifikation

Bei einer Modifikation des sicherheitsbezogenen Systems ist die Sicherheitsintegrität zu erhalten. Daher ist es notwendig, die Änderungen im Hinblick auf Verbesserungen, Korrekturen oder Systemanpassungen genau zu planen. Daher ist zu dokumentieren, was geändert wird und es ist eine Einflussanalyse durchzuführen, welche die Auswirkungen durch die Modifikation aufzeigt bezogen auf die 3 Ebenen (Gesamtsicherheit, Hardware, Software), auf die Bedienung, auf die Umwelt und ob potenzielle ungewollte Wechselwirkungen entstehen. Das Tracking der Modifikation mit Genehmigung, Status, Anpassung der Spezifikation, neue Testfälle, erneute Verifikationsaktivitäten und Revalidierung sollte im Änderungs- und Konfigurationsmanagement leicht verständlich dokumentiert sein. Dazu gehören auch Änderungen an Systemverfahren und ggf. die Dokumentation von Abweichungen zum Normalbetrieb. Alle Dokumente, welche betroffen sind, sind anzupassen.

Die Modifikation kann durch interne Erkenntnisse oder durch externe Feldbeobachtungen und Kundenrückmeldungen ausgelöst werden. Insbesondere ist dies Teil der Beobachtungspflicht nach dem ProdHaftG. Hier sind auch Anwender zu informieren, wenn sicherheitsrelevante Modifikationen notwendig wären.

Die Modifikation ist Teil des Sicherheitslebenszyklus. Die Sicherheitsintegrität ist nur erhaltbar, wenn mit dem gleichen Niveau zum Systemverständnis wie bei der Entwicklung mit vornehmlich automatisierten Werkzeugen mit Planung und Management das sicherheitsrelevante E/E/PE-System modifiziert wird.