IEC 61508 – Funktionale Sicherheit generisch & pragmatisch ?

Die IEC 61508 ist quasi die geschriebene generische Grundlage vieler Safety-Normen oder Standards. Es handelt sich um eine „nicht harmonisierte“ branchenübergreifende Richtlinie für sicherheitsgerichtete Systeme, was Sie daher besonders macht. Funktionale Sicherheit nach IEC 61508 pragmatisch zu erklären ist fast unmöglich. Beginnen wir mit dem Titel:

IEC 61508: Funktionale Sicherheit sicherheitsbezogener elektrischer/elektronischer/programmierbarer elektronischer Systeme

Die Teile 1 bis 4 sind normativ, Teile 5 bis 7 sind informativ zu betrachten. Insgesamt sind mehr als 500 Seiten teils stark untereinander in referenzierenden Bezug, welches die Verständlichkeit stark erschwert. Von einem schnellen durchlesen, studieren und anwenden ist abzuraten. Wenn diese Norm zum Einsatz kommt, handelt es sich meist um eine Entwicklung eines sicherheitsgerichteten Systems ohne harmonisierende Normgrundlage im Kontext einer Zertifizierung durch einen „certified body“ unter dem Dach der Maschinenrichtlinie. Was dies genau bedeutet und welche rechtlichen Risiken bei Nichtanwendung bestehen könnten, habe ich teilweise in den Safety Basics erläutert.

Der normative Kern

Die Normativen Teile der IEC 61508 beschreiben in Teil 1 u.a. das Sicherheitsmanagement, den Sicherheitslebenszyklus, die Dokumentation und die Validierungs- und Verifikationsaktivitäten (V&V), in Teil 2 die Systemebene mit der Hardware sowie in Teil 3 die Software:

• IEC 61508 Teil 1: Allgemeine Anforderungen
• IEC 61508 Teil 2: Anforderungen an sicherheitsbezogene elektrische/elektronische/programmierbar elektronische Systeme
• IEC 61508 Teil 3: Anforderungen an Software
• IEC 61508 Teil 4: Begriffe und Abkürzungen

Teil 6 ist eine Anwendungsrichtlinie und diese beschreibt, wie Teil 2 und Teil 3 anzuwenden sind. Teil 5 zeigt Beispiele zur Ermittlung des Sicherheitsintegritätslevels gemäß Teil 1 und Teil 7 gibt in drei Anhängen einen Überblick über die gängigen Maßnahmen und Verfahren zur Beherrschung zufälliger Hardwarefehler (Anhang A), zur Vermeidung systematischer Ausfälle (Anhang B) sowie zum Erreichen der Sicherheitsintegrität der Software (Anhang C).

Das Prozessmodell

Prozesstechnisch bildet die IEC 61508 eine Art „Framework“ in Kontext eines produktspezifischen Lebenszyklusmodells nach V-Modell-Manier. Einfacher ausgedrückt, von der Idee bis zur Entsorgung des Produktes ist eine vollständige Betrachtung erforderlich. Bereits mit der funktionalen Beschreibung beginnt der Sicherheitslebenszyklus. Damit beginnt auch das V-Modell-Vorgehen, welches das Prinzip „erst denken und planen, dann strukturiert, koordiniert und dokumentiert handeln“ erzwingt. Eine agile Entwicklung ist daher nur in Teilphasen brauchbar, wie es in der Softwareentwicklung (s. Teil 3) von mir etwas ausführlicher beschrieben ist.

Funktionale Sicherheit – IEC 61508 – pragmatisch einsteigen

Empfehlenswert ist der pragmatische Einstieg in die IEC 61508, wenn ein SIL bereits vorhanden ist, wie folgt:

• IEC 61508 Teil 2 Anhang A und B für Vorschläge zu Maßnahmen zur Beherrschung von zufälligen Hardwarefehlern und systematischen Fehlern in den verschiedenen Entwicklungsphasen
• IEC 61508 Teil 3 Anhang A und B für Maßnahmen für die Entwicklung sicherheitskritischer Software
• IEC 61508 Teil 7 Beschreibung zur Umsetzung dieser Maßnahmen und Verfahren

Generell ist es für Pragmatiker des Maschinenbausektors oder dem Automobilsektor empfehlenswert über sogenannte Sektornormen wie die ISO 13849 – Funktionale Sicherheit für Maschinen oder die ISO 26262 – Funktionale Sicherheit für Straßenfahrzeuge in das Thema einzusteigen. Sektorspezifische Eigenheiten wie z.B. die verteilte Entwicklung im Automobilzulieferbereich werden umfangreicher berücksichtigt als in der generischen Grundsicherheitsnorm IEC 61508. Für den fundierten Einstieg empfehle ich den Gesamtsicherheitslebenszyklus nach IEC 61508 Teil 1.

Oft wird fälschlicherweise von Pragmatismus bei Anwendung der Normen zur Funktionalen Sicherheit gesprochen, mit dem Wunsch bei minimalen Ressourceneinsatz eine Konformität zur Norm und damit Zertifizierungserfolg zu erlangen.

Notwendige und wirtschaftliche Risikominderung ist Pragmatismus

Die Sicherheitsgrundnorm beschreibt in Teil 4, Abschnitt 3.5.18 den Begriff der notwendigen Risikominderung, als die Minderung des Risikos, die erreicht werden muss, um das tolerierbare Risiko für eine bestimmte Situation zu erreichen. Dieses tolerierbare Risiko wird ermittelt durch Faktoren wie Schadensschwere, Häufigkeit und Dauer der Einwirkung innerhalb der Gefahren- und Risikoanalyse (G&R). Insofern besteht also keine Option zu dieser Art von Pragmatismus, sondern es besteht vielmehr ein risikobasiertes Mindestmaß, welches die Entwicklungsaufwände vorgibt. Oft werden Fehler bereits in der G&R durch Unwissenheit im Umgang mit Gefahren, Risiken und deren Bewertung gemacht. Dies fälschlicherweise oft zu konservativ und damit unötigerweise kostenintensiv. Funktionale Sicherheit nach 61508 pragmatisch zu erreichen ist daher nicht notwendig.

Das Management der Funktionalen Sicherheit

In IEC 61508 Teil 1 Abschnitt 6 wird gefordert, dass Verantwortlichkeiten festgelegt werden müssen für den Sicherheitslebenszyklus (SLC) des Systems bzw. dessen Teilphasen und Abschnitte für die Ebene des Gesamtsystems, der Software und Hardware, sofern erforderlich. Eine genaue Tätigkeitsbeschreibung und Zuweisung an die verantwortlichen Personen ist eine Grundvorrausetzung für bewusstes und effektives Handeln zum Erhalt und Ereichen der funktionalen Sicherheit.

Verantwortung kann nur durch Identifikation mit den erforderlichen Aufgaben und Anforderungen wahrgenommen werden. Dies bedingt Autorität.

Ein System braucht einen Verantwortlichen für die Lebensphasen und einen Koordinator für die Ausführung der sicherheitsbezogenen Tätigkeiten in den Phasen. Sofern eine verteilte Entwicklung stattfindet, sind auch hier Verantwortliche zu benennen und eine klare Abgrenzung der Phasen und Arbeitsprodukte vorzunehmen. Am Projektende muss durch eine Person oder ein kleiner Personenkreis aufgezeigt werden können, wie die Anforderungen und Ziele der IEC 61508 erreicht wurden.

Eine Koordination der Beurteilung zur Funktionalen Sicherheit durch externe Berater und Gutachter, dessen Ergebnisse zur Integration in die Dokumente sowie die phasenspezifische Unterscheidung zwischen Autor und Tester/Prüfer oder Validierer ist durch das FuSi-Management sicherzustellen.

Anforderungen an das Management

Folgende Anforderungen werden an das Management der Funktionalen Sicherheit gestellt:

• Festlegung von Strategien und Vorgehensweisen zum systematischen Erreichen der funktionalen Sicherheit, sowie deren Ausführungsqualität (Prozessreifegradmodelle wie z.B. SPICE)
• Identifizierung und Mitteilung der Verantwortlichkeiten in den Phasen und Ebenen (Gesamtsystem, HW, SW) der Sicherheitslebenzyklen inbesondere im Hinblick auf Personen zur Beurteilung und Verifikation der Funktionalen Sicherheit und Sicherheitsüberwachungsorgane
• Sicherstellung und Aufbau von Kompetenz und Qualifikation der beteiligten verantwortlichen und ausführenden Personen der Phasen und Ebenen entsprechend im Sicherheitslebenszyklus (Personalentwicklungsplan)
• Verfahren zur Kommunikation und Informationsaustausch zwischen Parteien (Dokumentenmanagement und Bereitstellung über ein Managementsystem) wie zum Beispiel Zulieferer
• Sicherstellung von Mindeststandards beim Zulieferer / Dienstleister
• Tracking und Änderungsmanagement von sicherheitsrelevanten Empfehlungen (Impactanalyse) aus:
  • der Gefahren- und Risikoanalyse
  • Verifikationstätigkeiten
  • Validierungstätigkeiten
  • Beurteilung der funktionalen Sicherheit
  • Konfigurationsmanagement
  • Zwischenfällen
• Minimierung der Auftrittswahrscheinlichkeit nach Sicherheitsvorfällen/Zwischenfällen durch Analyse und Handlungsempfehlung
• Festlegung der Häufigkeit, dem Unabhängigkeitsgrad des Auditors sowie die Dokumentation und Sicherstellung möglicher Folgetätigkeiten für wiederkehrende Audits
• Planung und Ausführung von Modifikationsverfahren (Zustimmung und Ermächtigung) der sicherheitsbezogenen Systeme
• Festlegen von Verfahren zur Bewahrung von Informationen im Hinblick auf Gefährdungen, Sicherheitsvorfälle, Sicherheitsfunktionen und sicherheitsbezogenen Systemen (z.B. Ereignisspeicher)
• Training und Informationen für Notfalldienste (Vgl. ISO 26262 mit der elektronischen Fahrzeugkarte, welche die Position der Energiespeicher (Batterie) im Fahrzeug aufzeigt)
• Festlegen des Konfigurationsmanagements im Hinblick auf:
  • die Vermeidung des Betriebs sicherheitsrelevanter Systeme mit nicht zugelassen Komponenten
  • die eindeutige Identifikation aller Bestandteile eines Systems oder Objektes (Bsp. HW-Revision mit SW-Version oder Release)
  • Zeitpunkte festlegen innerhalb der Phasen, in der eine formale Konfigurationskontrolle stattfinden muss

Wer ist der richtige Kandidat für den FuSi-Manager ?

In der Regel ist ein interner FuSi-Manager mit diesen Aufgaben betraut. Dieser sollte durchsetzungsfähig und jederzeit handlungsfähig sein. Falls in Phasen des Sicherheitslebenszyklus unterschiedliche Personen diese Verantwortung abschnittsweise und/oder unterschiedlichen Ebenen tragen, so müssen diese Personen alle Management- und technischen Tätigkeiten (s. Auflistung oben) zum Erreichen, Nachweis und zur Erhaltung der Funktionalen Sicherheit planen/festlegen. Schließlich ist im Kern die Konsistenz aller Maßnahmen zum Erreichen und Erhalt der Funktionalen Sicherheit und damit die Konformität sicherzustellen.

Wenn ein FuSi-Manager im Projekt unplanmäßig ausscheidet, ist dies ein schlechtes Zeichen für die Sicherheitskultur

Insbesondere muss das FuSi-Management sicherstellen, dass die Beurteilung zur Funktionalen Sicherheit nach Teil 1, Abschnitt 8 durch Personen erfolgt mit folgenden Eigenschaften:

• Unabhängigkeit
• konkreten Aufgabenbereich
• Beständigkeit (Proaktiver Wechsel mit Übergabe und ausreichend Einarbeitungszeit)
• Durchsetzungsfähigkeit

Die erforderliche Unabhängigkeit

Der Grad der minimalen Unabhängigkeit ist abhängig von:

• der Schwere der Auswirkungen bei Ausfall aller Maßnahmen zur Gesamtsicherheit im Hinblick auf Personen mit Beurteilungstätigkeiten in den Planungsphasen, insbesondere in der Konzeptphase
• dem erforderlichen Sicherheitsintegritätslevel der Sicherheitsfunktion für Personen, mit Beurteilungstätigkeiten in der Spezifikation und Realisierung des sicherheitsbezogenen E/E/PE-Systems
• Komplexität, Erfahrung und Neuigkeit im Hinblick auf die verwendete Technologie

Dabei sind die Stufen der minimalen Unabhängigkeit durch folgende Subjekte festgelegt:

• Person (nicht eigebunden in Tätigkeiten der Entwicklungsphase einer Ebene (Konzeption/Planung, System, Hardware, Software), welche Gegenstand der Beurteilung oder Validierung ist)
• Abteilung (getrennte Abteilung ohne Verbindung zur anderen Abteilung)
• Organisation (Trennung in Management und Mittel (finanziell und ressourcentechnisch))

Sofern das sicherheitsrelevante System in Feld ist, so muss das FuSi-Management durch Analyseverfahren die Leistungsfähigkeit im Betrieb und bei Instandhaltung sicherstellen. Dabei ist die Erkennung von systematischen und widerkehrenden Fehlern durch Auswertung von Betriebsdaten und Parametern notwendig. Insbesondere sind auch die Annahmen zum Betriebsprofil der Fehlerraten mit den Realbetriebsbedingungen zu überwachen.

Kompetenz, personelle Eignung und Erfahrung bilden die Grundpfeiler – Beteiligte müssen wissen, was sie tun und wie sie handeln können, ohne das Wege in der Funktionale Sicherheit nach 61508 als pragmatisch wahrgenommen werden. Oft wird von unseriösen Beratern dieser trügerische pragmatische Weg verkauft.

Die Dokumentation als Grundlage zur Beurteilung der Funktionalen Sicherheit

Frei nach dem Motto erst planen dann handeln, setzt die Funktionale Sicherheit auf die Grundpfeiler eines typischen Qualitätsmanagementprozesses z.B. nach QM 9001. Die Phasen Plan, Do, Check, Act (PDCA) sind auch hier notwendig. Die Dokumentation beinhaltet die wirkungsvolle Planung der drei Sicherheitslebenszyklusphasen (Gesamtsystem, Hardware, Software), welche das Ziel der Vermeidung systematischer Fehler unterstützt. Dokumentierte Verifikations- und Validierungsaktivitäten (V&V) bilden die Grundlagen zur Beurteilung der funktionalen Sicherheit. Die Dokumente stellen dabei grundlegenden Artefakte dar, welche in einer zielgerichteten Argumentation notwendig sind. Sie sind der Nachweis und zeigen die Wirkung der Maßnahmen gegen zufällige Hardwarefehler sowie der Maßnahmen zur Vermeidung systematischer Fehler.

Der Umfang der Dokumentation ist abhängig von der Informationsmenge, welche notwendig ist, um Faktoren wie z.B. Komplexität verständlich und vollständig abzubilden

Funktionale Sicherheit nach IEC 61508 pragmatisch ausgeführt bedeutet oft zu spät dokumentiert, nachträglich dokumentiert oder dokumentiert aber nicht wie dokumentiert umgesetzt. Dieses Vorgehen macht eine positive Beurteilung der Maßnahmen zur Vermeidung systematischer Fehler unmöglich, wenn es sich nicht um ein umfangreiches Pre&Re-Compliance-Programm handelt. Der systematische Fehler ist dann möglicherweise im Produkt enthalten und wartet auf sein „Erwachen“.

Ein kommentierter Code einer SW-Unit ist ohne dokumentierte Architektur oder Spezifikation wertlos.

Es reicht eine genaue, auf ein Mindestmaß an Informationen reduzierte, leicht verständliche, dem Zweck erfüllende Dokumentation. Die Dokumentenpflege und Dokumentenlenkung muss leicht möglich sein.

Erforderliche Merkmale der Dokumentation

Folgende Merkmale sollten nicht fehlen:

• Titel / Bezeichnung des Dokuments
• Anwendungsbereich / Zweck
• Bezug zur Norm
• Register / Inhaltsverzeichnis
• Revision / Versionsnummer
• Dokumentenlenkungsinformationen

Ziel ist es, Konsistenz der Informationen zu erhalten. Eine Dokumentversion für eine Anforderungsspezifikation muss z.B. eindeutig mit einer SW-Architekturabbildung in SysML, der passenden Software-Unit-Spezifikation und dem Testbericht zuordbar sein. Dokumente, welche automatisch erstellt werden, müssen nachvollziehbar und kontrollierbar sein.

Die Verifikation jeder Phase des Sicherheitslebenszyklus

Die Verifikation ist neben der Validierung eine wichtige Tätigkeit des FSM in Zusammenarbeit mit dem Entwicklungsteam. Ziel ist die Sicherstellung aller Ziele und Anforderungen der IEC 61508 in jeder Phase auf allen drei Ebenen (System, Hardware und Software) im Gesamtlebenszyklus. Dabei kommt vorwiegend die protokollierte Review-Methode zum Einsatz. Im Allgemeinen bestimmen Komplexität, Projektgröße, Projekt-Tool-Landschaft und Tool-Brüche, Qualitätskultur sowie Erfahrung in der verwendeten Technologie und die erforderliche Sicherheitsintegrität maßgeblich die Aufwände der Verifikation. Oft werden die Verifikations- und Validierungstätigkeiten gebündelt zu den sogenannten V&V-Aktivitäten im FSM. Schauen Sie mal in Teil 3 – der Softwareentwicklung nach dem Umfang der Verifikationsaktivitäten, Sie werden beeindruckt sein.

Die Beurteilung der FuSi

Am Ende der Entwicklung ist eine Beurteilung durchzuführen (Audits und Gutachten) über die Angemessenheit der durch die konformen Objekte erreichten Funktionalen Sicherheit durch kompetentes Personal (ein Qualifikationsnachweis und ein Nachweis für die Unabhängigkeit ist erforderlich!). Dazu müssen ein oder mehrere Personen ernannt werden, welche Zugriff auf das Entwicklungspersonal und Verantwortliche der 3 Ebenen (Gesamtsystem, Hardare, Software) haben. I.d.R. werden entwicklungsbegleitende Assessments durchgeführt. Es kann jedoch auch nach mehreren Phasen ein Audit durchgeführt werden, jedoch mit erhöhten Risiken für das Projekt (z.B. Termineinhaltung und Ressourcen). Dabei sind die chronologisch dokumentierten Tätigkeiten und Ergebnisse zu betrachten und auf angemessende Konformität zu den Zielen der jeweiligen Phase zu prüfen. Die revisionssicheren Dokumente und Verifikationsprotokolle sowie Konformitätserklärungen dritter Parteien bilden zusammen mit mehreren Audits die Grundlage dieser Beurteilung.

Dabei werden auf den Anwendungsbereich bezogenen relevante Audits durchgeführt mit folgenden Merkmalen:

• Planung und Strategie der Beurteilung zur FuSi
• ggf. Prüfung des Fortschritts der Empfehlungen des vorherigen Audits
• Abfrage des Bearbeitungsstandes oder Phasenzustandes im Sicherheitslebenszyklus

Die Planung zur Beurteilung ist durch den Assessor in Kooperation mit dem FSM zu entwickeln und legt die folgenden zu betrachtenden Informationen fest, um eine wirksame Beurteilung zu ermöglichen:

• Anwendungsbereich (z.B. Teilkonformität, Modifikation oder Neuentwicklung)
• beteiligte Organisationen und erforderliche Ressourcen
• Personen zur Beurteilung der FuSi und deren Unabhängigkeitsgrad sowie deren Befähigung
• Ergebnisse der Beurteilung zur FuSi
• ggf. Kontextabgrenzung und Zusammenfassungsstrategie bei bestehenden Beurteilungen
• Sichtung von ausgewählten Dokumenten mit Nachweis (Dokumentenname und Revisionsstand) als Grundlage zur Beurteilungstätigkeit

Der Safety-Case – das Ziel einer FuSi-konformen Entwicklung

Die Beurteilung erfolgt als eine Art Gutachten. Dabei ist es notwendig, als beurteilende Person, die ausgeführten Tätigkeiten und die daraus resultierenden Feststellungen zu Folgerungen im Hinblick auf die Angemessenheit der erreichten Funktionalen Sicherheit argumentativ zu Verdichten. Eine zielgerichtete Argumentation kann z.B. mittels der Methode „GSN“ im Rahmen des SafetyCase-Dokuments erfolgen. Dazu dient die Gesamtheit der Dokumente als Artefakt-Grundlage der Nachweisführung.

Die folgende Grafik veranschaulicht das Vorgehen. Es zeigt einige Phasen, die aus den Phasen entstehenden Dokumente (WP#) und die Argumentation (Trichter) aus diesen Dokumenten zur Beurteilung der Angemessenheit zur erreichten Funktionalen Sicherheit. Wobei jedes Dokument als Work-Product (WP) als Teil der Verifikationsaktivitäten in jeder Phase chronologisch ensteht und alle miteinander teils im referenziellen Bezug im Bewertungsdokument „Safety Case“ erwähnt/behandelt wird.

Dabei wird letzendlich eine Empfehlung ausgesprochen zur Annahme, bedingten Annahme oder Ablehnung zur Akzeptanz der erreichten Funktionalen Sicherheit gemäß den normativen Anforderungen und Zielen. Die Beurteilung muss dem FSM des sicherheitsbezogenen E/E/PE-Systems sowie dem Integrator vorgelegt werden. Letzendlich kann Funktionale Sicherheit nach IEC 61508 NICHT pragmatisch entwickelt und dann positiv beurteilt werden.

Inhalt des Gutachtens

Die aus der Beurteilung ergebende Erklärung zur Funktionalen Sicherheit (Safety Case) muss folgende Informationen enthalten:

• Bezeichnung / Name / Gerätefamilie mit Hardwareversion und Softwareversion zur eindeutigen Identifikation
• Verwendungsbedingungen / Annahmen zur Verwendungsumgebung
• Referenz auf die Dokumente (Beweisartefakte)
• Die für die Beurteilung zur systematischen Eignung verwendeten Methoden, Verfahren und Werkzeuge sowie die Rechtfertigung zur Wirksamkeit
• Die für die Beurteilung zur Hardware-Sicherheitsintegrität gewählten Verfahren, Methodenn, Werkzeuge, deren Rechtfertigung sowie die Qualität der Ausfallraten-Datenbank und das Fehlermodell
• Die Verkünpfung der Beurteilungsergebnisse zu den normativen Anforderungen und dem sicherheitsbezogenen Merkmalen des konformen Objektes in seinem Sicherheitshandbuch
• Die akzeptierten Abweichungen mit entsprechender Erklärung oder Verweis auf einen anderen Nachweis

Wichtige Punkte der Beurteilung sind in das Sicherheitshandbuch für konforme Objekte und/oder Software-Elemente aufzunehmen.

Mögliche Kritik an der IEC 61508

Oft wird die IEC 61508 als zu komplex und zu allgemein empfunden. Frei nach dem Motto „Freiheit erzeugt Unsicherheit“. Da sich die IEC 61508 an Normensetzer richtet, gehört diese Norm auch nur in diese Hände.

Künstliche Intelligenz (KI / AI) und Funktionale Sicherheit ?

Es zeigt sich öfters, dass nicht immer alle Fragestellungen der IEC 61508 in einem Anwendungsfall vollständig behandelt werden können. Die auf Prozess- und Automatisierungsindustrie gerichtete IEC 61508 hat weniger mit intelligenten Mensch-Maschine-Interaktionen Berührpunkte als die Entwicklungen mit künstlicher Intelligenz (KI / AI) derzeit fordern. Beispielsweise ist die Beta-Modell-Rechnung für Fehler gemeinsamer Ursache zu konservativ.

Beispielsweise findet sich in Tabelle A.2 des 3. Teils (Software) eine eindeutig ablehnende Haltung. Dort ist ein Verfahren zur Fehlerkorrektur mit „künstlicher Intelligenz“ (KI / AI) beschrieben, welches in Teil 7 Anhang C.3.9 genauer beschrieben ist. Dabei dient dieses Verfahren zur Vermeidung systematischer Fehler durch eine fehlerhafte Spezifikation im Softwarearchitekturentwurf. Leider ist dieses Verfahren für Anwendungen größer SIL 2 nicht empfohlen, da grundlegende Eigenschaften an die Fehlervermeidung in der Softwarearchitektur nicht erreicht werden können wie z.B. nachweisbarer und testbarer Entwurf, Einfachheit und Verständlichkeit oder voraussagbares Verhalten (s. hierzu auch Teil 3, Anhang C, Tabelle C.2). Maschinen sollen keine Funktionale Sicherheit entwickeln. D.h. wir müssen weiterhin die Technologien verstehen und beherrschen.

Kritik an Anspruch und Wirklichkeit

• Verwendung von wechselnden Begriffen für die gleiche Bedeutung (Schnitstellen zum EUC und „Anlagenschnittstellen“)
• Die normativ geforderte Auswahl einer Menge von Verfahren und Methoden, welche projekt- bzw- technologiespezifisch erfolgen muss, gibt allein keine Garantie, dass die systematische Sicherheitsintegrität erreicht wird. Es bleibt dem Urteil der Fachsachverständigen und dem FuSi-Bereich überlassen, dies durch Stellungnahme/Argumentation zu beweisen. Dies kann bei komplexen Technologien mit wenig Erfahrung unmöglich sein.
• Die Begriffe „Strenge“ und „Wirksamkeit“ bezogen auf erforderliche Eigenschaften der Methoden und Verfahren sind recht weich definiert, um den erforderliche Freiheitsgrad für neue Technologien zu erhalten. Jedoch ist für die Bewertung viel Erfahrung notwendig.