Software in sicherheitsrelevanten Systemen Ralf Pinger / Stefan Gerken Sommersemester 2013

Kapitel 4 - konstruktive Grundprinzipien der Sicherheit Inhaltsübersicht Mehrkanaligkeit Diversität Voting Sicherer Zustand Fallback-Mechanismen, Redundanz Umsetzung Zusammenfassung 27.03.2017 Ralf Pinger / Stefan Gerken

4.1 Mehrkanaligkeit – Prinzip Grundprinzip: Jede Funktion wird mehrfach realisiert und ausgeführt Die Ausführungen sind paarweise rückwirkungsfrei Folgerung: Fehler werden erkannt Fehler werden offenbart Fehler werden beherrscht Beherrschung heißt: „Gefährliche Auswirkungen von Fehlern werden vermieden“ Probleme: Grad der Offenbarung Reaktionszeit Sicherer Zustand muss existieren, sonst wird auch die Verfügbarkeit sicherheitsrelevant 27.03.2017 Ralf Pinger / Stefan Gerken

4.1 Mehrkanaligkeit – Unterscheidung unabhängige Wirkmechanismen: Physikalisch Logisch Algorithmen Vorgehen unabhängige Ausführungspfade: Ausfälle wirken nur in einem Kanal Unabhängige Hardware heißt in der EN50129 „physikalische Unabhängigkeit“ Unabhängige Wirkmechanismen heißen in der EN50129 in Verbindung mit physikalischer Unabhängigkeit „funktionale Unabhängigkeit“ 27.03.2017 Ralf Pinger / Stefan Gerken

4.2 Diversität – Grundpinzip Prinzip Eine Aufgabe wird auf unterschiedliche Art und Weise mehrfach realisiert Spezialfall der Mehrkanaligkeit Beispiele Geschwindigkeitsermittlung über Tacho und Radar Prozess: SW-Entwicklung und SW-Test Coded Mono Processor 27.03.2017 Ralf Pinger / Stefan Gerken

4.2 Diversität – Probleme Probleme Wissenschaftliche Untersuchungen Bei festem Budget für Entwicklung einer Funktion bleibt für jede Variante ein entsprechend kleinerer Bruchteil (für alle Phasen der Entwicklung) Gleiche Ausbildung erzeugt gleiche Weltbilder und damit ähnliche Fehler; damit ist die Annahme der Unabhängigkeit systematischer Fehler nicht gegeben Fehlerhafte Voraussetzungen werden auch hier nicht offenbart Wissenschaftliche Untersuchungen Nancy Leveson et al. In IEEE Transactions on Software Engineering: 1986: „An Experimental Evaluation of the Assumption of Independence in Multiversion Programming“ 1990: „The Use of SelfChecks and Voting in Software Error Detection: An Empirical Study“ 1991: An Empirical Comparison of Software Fault Tolerance and Fault Elimination“ 27.03.2017 Ralf Pinger / Stefan Gerken

4.3 Voting Voting: Annahme: Folgerung: Mehrkanaligkeit erzeugt immer mehrere Ergebnisse Es muss das richtige Ergebnis auf den gesteuerten Prozess wirken Annahme: Ein Fehler wirkt sich nur in einem Kanal aus Folgerung: Ein abweichender Kanal muss abgeschaltet werden 27.03.2017 Ralf Pinger / Stefan Gerken

4.3 Voting Problem: Lösung: Hat die Hardware physische (zufällige) Fehler? Welcher Kanal ist defekt? Lösung: Man nimmt mehrere Kanäle Man versucht, einen Mehrheitsentscheid zu erwirken Wenn das nicht möglich ist, nimmt man einen sicheren Zustand ein Es gibt nicht für jede Systemfunktion einen sicheren Zustand. In diesem Fall muss man den am wenigsten unsicheren Zustand wählen und die Gefahr möglichst schleunigst beherrschen. 27.03.2017 Ralf Pinger / Stefan Gerken

Ein Zustand, von dem keine Gefährdung mehr ausgeht 4.4 Sicherer Zustand Ein Zustand, von dem keine Gefährdung mehr ausgeht Bei der Bahn im Regelfall der energielose Zustand (Stillstand) Im Flugzeug ein Zustand, der ein sicheres Landen erlaubt  Auch der energielose Zustand ist nicht immer sicher Auch bei der Bahn gibt es am Ablaufberg Bremsen an der Schiene, die keinen sicheren Zustand haben, da entweder ein Waggon auf der Strecke stehen bleibt oder mit viel Schwung und Energie auf bereits stehende Waggons knallt und dabei Schaden entstehen kann. Da jeder Waggon hier auch unterschiedliches Gewicht und Rollvermögen hat, gibt es keine vereinheitlichte Bremsverzögerung, die zu einer sicheren Verteilung der Waggons im Ablaufberg führen würde. 27.03.2017 Ralf Pinger / Stefan Gerken

4.5 Fallback-Mechanismen, Redundanz Rückfallebenen sind erforderlich, wenn es keinen sicheren Zustand gibt ein Stillstand des Betriebs zu teuer ist eine Bergung des ausgefallenen Gerätes nicht oder nur schwer möglich ist  Rückfallebenen ermöglichen daher, für eine gewisse Zeit weiterhin Betrieb zu machen ohne die Sicherheit übermäßig zu verschlechtern 27.03.2017 Ralf Pinger / Stefan Gerken

4.5 Fallback-Mechanismen, Redundanz Redundanz: zusätzlicher Kanal, der im Regelbetrieb nicht benötigt wird. Verwendung nur im Fehlerfall Arten von Redundanz: Hot Standby: redundanter Kanal läuft immer mit, Umschaltung kann direkt erfolgen. Cold Standby: redundanter Kanal läuft nicht mit, Hochfahren des Systems nach Umschaltung notwendig 27.03.2017 Ralf Pinger / Stefan Gerken

In der Literatur gibt es unterschiedliche Bezeichnungen 4.6 Umsetzung In der Literatur gibt es unterschiedliche Bezeichnungen Definition: N-out-of-M oder N-von-M (z. B. 2oo2 oder 2v2) N der M Kanäle müssen funktionstüchtig sein und dasselbe Ergebnis errechnen Das Ergebnis der N gleichen Kanäle wird zur Weiterverarbeitung verwendet CENELEC und IEC 61508 haben unterschiedliche Definitionen zum Teil auch nur in Beispielen. Im Folgenden wollen wir diese Definition verwenden und verwenden NvM und NooM gleichbedeutend. 27.03.2017 Ralf Pinger / Stefan Gerken

4.6 Umsetzung – 1oo2, Redundanz Zwei Kanäle arbeiten parallel, durch eine externe Entscheidung kann zwischen dem ersten oder dem zweiten Kanal für die gültigen Ausgaben gewählt werden. Diese Architektur eignet sich nicht für die Erkennung von Hardwarefehlern, sie erhöht lediglich die Zuverlässigkeit und Verfügbarkeit des gesamten Systems, da trotz Ausfall des ersten Kanals mit dem zweiten Kanal weiterhin Betrieb gemacht werden kann (Rückfallebene). 27.03.2017 Ralf Pinger / Stefan Gerken

4.6 Umsetzung – Eigenschaften von 1oo2 Erhöhung der Zuverlässigkeit und Verfügbarkeit des Gesamtsystems Doppelte Hardwarekosten Common Cause: Gemeinsame Stromversorgung, etc. ? Hardwarefehler können innerhalb dieses Systems nicht erkannt werden. Dies obliegt dem Benutzer oder einem weiteren Teilsystem außerhalb dieser Darstellung. Common Cause, gemeinsame genutzt Ressource können zu einem gemeinsamen Fehler führen. Wird beispielsweise dieselbe Stromversorgung für beide Kanäle verwendet, so führt der Ausfall der Stromversorgung zum Ausfall beider Kanäle. Die Umschaltung bringt in diesem Falle also nicht. 27.03.2017 Ralf Pinger / Stefan Gerken

4.6 Umsetzung – 2oo2, Sicherheit Zwei Kanäle arbeiten parallel (hot), ein Voter entscheidet ob beide Kanäle dasselbe Ergebnis liefern. Nur in diesem Falle wird die Ausgabe weitergeleitet. Wird eine Abweichung erkannt, muss das gesamte System in den sicheren Zustand übergehen. 27.03.2017 Ralf Pinger / Stefan Gerken

4.6 Umsetzung – Voter Comp: Vergleicher Muxer: Multiplexer, der die Ausgabe ggf unterbrechen kann, und somit die Einleitung des sicheren Zustands hervorrufen kann. 27.03.2017 Ralf Pinger / Stefan Gerken

4.6 Umsetzung – Eigenschaften von 2oo2 Erkennung von Hardware-Fehlern durch Voter möglich Bei Abweichung: sicherer Zustand Doppelte Hardwarekosten Common Cause: Gemeinsame Stromversorgung, etc. ? Zuverlässigkeit und Verfügbarkeit geringer als bei einem Kanal, da beide Kanäle zwingend benötigt werden. Hardwarefehler können innerhalb dieses Systems nicht erkannt werden. Dies obliegt dem Benutzer oder einem weiteren Teilsystem außerhalb dieser Darstellung. Common Cause, gemeinsame genutzt Ressource können zu einem gemeinsamen Fehler führen. Wird beispielsweise dieselbe Stromversorgung für beide Kanäle verwendet, so führt der Ausfall der Stromversorgung zum Ausfall beider Kanäle. Die Umschaltung bringt in diesem Falle also nicht. 27.03.2017 Ralf Pinger / Stefan Gerken

4.6 Umsetzung – 1oo1D, Sicherheit Die Diagnosekomponente überprüft die Ausgaben des Kanals ständig auf Plausibilität. Falls die Ausgabe nicht schlüssig sind, wird die Ausgabe abgeschaltet und die Sicherheitsfunktion ausgeführt. Die Diagnosekomponente kann beispielsweise eine Referenzimplementierung sein oder auch nur ein Plausibilitätscheck, der die Ausgaben auf Konsistenz prüft. Im letzteren Fall muss dann sichergestellt werden, dass eine defekte Hardware keine als gültig angesehenen Daten mehr liefern kann. Darüber hinaus muss der Einfluss der defekten Hardware auf die Funktion der Diagnose ausgeschlossen werden können. Ansonsten könnte beispielsweise ein Hardwaredefekt eine falsche Ausgabe verursachen und derselbe Defekt führt dazu, dass die Diagnose diesen Fehler nicht als solchen erkennt. Kanal und Diagnose müssen also hinreichend unabhängig sein. Dieses Verfahren steht und fällt mit der Unabhängigkeit von Kanal und Diagnose. Eine Unabhängigkeit kann nur dann angenommen werden, wenn Kanal und Diagnose hinreichend unterschiedliche Aufgaben haben und die für die Berechnung der jeweiligen Funktionen eingesetzte Hardware ebenfalls hinreichend unabhängig sind. 27.03.2017 Ralf Pinger / Stefan Gerken

4.6 Umsetzung – Eigenschaften von 1oo1D 1D steht für 1 Kanal + Diagnose-Kanal, in diesem Sinne eigentlich auch 2 Diagnosekomponente führt eine Selbstprüfung durch Falls ein Fehler erkannt wird, erfolgt die Ausführung einer Sicherheitsfunktion (z. B. Abschalten, eingeschränkte Funktion) Fehlerhafte Ausgaben werden nicht sofort unwirksam (Diagnose muss erst arbeiten!) Gemeinsame Hardware für Haupt- und Prüfprogramm: Was passiert wenn beide gleichermaßen versagen (Common Cause) Überprüfung kann auch auf Ausgabebaugruppen verlagert werden Geringe Kosten für zusätzlich Hardware, falls D einfach aufgebaut werden kann Das Erkennen eines HW-Fehlers kann in dieser Varianten einige Zeit in Anspruch nehmen. Das Verfahren ist also nur dann einsetzbar, wenn für die Einnahme des sicheren Zustand genügend Zeit zur Verfügung steht. Der Vorteil dieser Variante ist die vergleichsweise günstige Ausführung, da nur eine Diagnoseeinheit hinzugefügt werden muss. 27.03.2017 Ralf Pinger / Stefan Gerken

4.6 Umsetzung – 2 mal 2oo2, Sicherheit und Redundanz Zwei Kanäle arbeiten parallel (hot), ein Voter entscheidet ob beide Kanäle dasselbe Ergebnis liefern. Nur in diesem Falle wird die Ausgabe weitergeleitet. Wird eine Abweichung erkannt, muss das gesamte System in den sicheren Zustand übergehen. 27.03.2017 Ralf Pinger / Stefan Gerken

4.6 Umsetzung – Eigenschaften von 2 x 2oo2 Redundanz als hot oder cold möglich Erhöhung der Zuverlässigkeit und Verfügbarkeit des Gesamtsystems Vierfache Hardwarekosten plus Umschaltungen Common Cause: Gemeinsame Stromversorgung, Sensorik, Aktorik etc. ? Diese Architektur wird teilweise bei Fahrzeuggeräte eingesetzt: Eine zweite komplette Rechnergarnitur wird im Fahrzeug eingebaut, in der Regel als cold standby System. Bei Funktionsversagen des ersten Rechners kann manuell umgeschaltet werden. 27.03.2017 Ralf Pinger / Stefan Gerken

4.6 Umsetzung – 2 x 1oo1D, Sicherheit und Redundanz Zwei Kanäle arbeiten parallel (hot), ein Voter entscheidet ob beide Kanäle dasselbe Ergebnis liefern. Nur in diesem Falle wird die Ausgabe weitergeleitet. Wird eine Abweichung erkannt, muss das gesamte System in den sicheren Zustand übergehen. 27.03.2017 Ralf Pinger / Stefan Gerken

4.6 Umsetzung – Eigenschaften von 2 x 1oo1D Alternative Darstellung mit 1oo1D Hier als Hot-Standby-System mit Muxer realisiert. Dieser Muxer schaltet nur durch Sicherheit steckt in den einzelnen 1oo1D-Kanälen. Realisierungsvarianten hängen Architektur, Kosten, Nutzen, Einsatzzweck usw. ab Diese Architektur wird teilweise bei Fahrzeuggeräte eingesetzt: Eine zweite komplette Rechnergarnitur wird im Fahrzeug eingebaut, in der Regel als cold standby System. Bei Funktionsversagen des ersten Rechners kann manuell umgeschaltet werden. 27.03.2017 Ralf Pinger / Stefan Gerken

4.6 Umsetzung – 2oo3 Ein Voter ist ein Vergleicher der Ausgaben der jeweiligen Kanäle. Tritt eine Abweichung in einem Kanal auf, so wird aufgrund der Gleichheit der anderen Kanäle angenommen, dass dieser Kanal fehlerhaft ist. Fehlerhaft erkannte Kanäle werden abgeschaltet und der Betrieb kann zweikanalig weiterlaufen. Erst beim nächsten Fehler (Abweichung des Vergleichs im Voter) muss die Sicherheitsfunktion ausgeführt werden. Denn dann kann nicht mehr entschieden werden, welcher der beiden letzten Kanäle noch korrekt arbeitet. Verfügbarkeit hoch, da nach erstem Fehler weitergearbeitet werden kann. Unabhängigkeit gegenüber 1oo1D-Problematik hier weiter reduziert. 2oo3 ist Standard bei Stellwerken der höchsten Sicherheitsanforderungsstufe. 27.03.2017 Ralf Pinger / Stefan Gerken

4.6 Umsetzung – 2oo3-Voter Muxer kann die Ausgabe wieder „unterdrücken“ 27.03.2017 Ralf Pinger / Stefan Gerken

4.6 Umsetzung – Eigenschaften von 2oo3 Verdreifachung der HW Fehlerhafter Kanal kann erkannt werden Weiterarbeiten nach erstem Fehler möglich Synchronisation noch schwieriger 27.03.2017 Ralf Pinger / Stefan Gerken

4.7 Zusammenfassung - Umsetzungen genannten Prinzipien sind nur Beispiele und können beliebig erweitert bzw. verändert werden Notwendigkeit der einzusetzenden Architektur sollte aus einer Risiko-Analyse abgeleitet werden Vollständige Zweikanaligkeit verringert common cause Ausfälle Hohes Maß an Ausfalloffenbarung durch Zwei- bzw. Mehrkanaligkeit möglich Durch HW-Vergleicher extrem schnelle Ausfalloffenbarung möglich Unabhängiges Abschalten durch Vergleicher möglich Natürlich können auch die Übertragungsmedien mehrkanalig ausgelegt werden! 27.03.2017 Ralf Pinger / Stefan Gerken

4.7 Zusammenfassung - Allgemeines Probleme: Enge Synchronisation und dichte Nachbarschaft der Kanäle machen das System empfindlich für common cause Einflüsse: Einflüsse über die Peripherie Einflüsse über die Stromversorgung Elektromagnetische Felder Temperatur (von außen, aber auch durch Nachbarkanal) Gegenmaßnahmen „Sichere“ Trennung der Peripherie vom Rechnerkern Hoch überwachte Stromversorgung Hochwirksame Schirmung 27.03.2017 Ralf Pinger / Stefan Gerken

4.7 Zusammenfassung - Allgemeines Mehrkanaligkeit kann eingesetzt werden für: Redundanz: Weiterarbeiten nach Ausfall von Kanälen Sicherheit: Erkennung von physischen Fehlern der Hardware Sicherheit und Redundanz Architekturen müssen die Ziele sicherstellen in Bezug auf R: Zuverlässigkeit A: Verfügbarkeit M: Wartbarkeit S: Sicherheit 27.03.2017 Ralf Pinger / Stefan Gerken