Software in sicherheitsrelevanten Systemen

Präsentation zum Thema: "Software in sicherheitsrelevanten Systemen"—  Präsentation transkript:

1 Software in sicherheitsrelevanten Systemen
Ralf Pinger / Stefan Gerken Sommersemester 2013

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

3 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 Ralf Pinger / Stefan Gerken

4 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“ Ralf Pinger / Stefan Gerken

5 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 Ralf Pinger / Stefan Gerken

6 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“ Ralf Pinger / Stefan Gerken

7 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 Ralf Pinger / Stefan Gerken

8 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. Ralf Pinger / Stefan Gerken

9 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. Ralf Pinger / Stefan Gerken

10 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 Ralf Pinger / Stefan Gerken

11 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 Ralf Pinger / Stefan Gerken

12 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 haben unterschiedliche Definitionen zum Teil auch nur in Beispielen. Im Folgenden wollen wir diese Definition verwenden und verwenden NvM und NooM gleichbedeutend. Ralf Pinger / Stefan Gerken

13 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). Ralf Pinger / Stefan Gerken

14 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. Ralf Pinger / Stefan Gerken

15 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. Ralf Pinger / Stefan Gerken

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

17 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. Ralf Pinger / Stefan Gerken

18 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. Ralf Pinger / Stefan Gerken

19 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. Ralf Pinger / Stefan Gerken

20 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. Ralf Pinger / Stefan Gerken

21 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. Ralf Pinger / Stefan Gerken

22 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. Ralf Pinger / Stefan Gerken

23 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. Ralf Pinger / Stefan Gerken

24 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. Ralf Pinger / Stefan Gerken

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

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

27 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! Ralf Pinger / Stefan Gerken

28 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 Ralf Pinger / Stefan Gerken

29 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 Ralf Pinger / Stefan Gerken