N-Version Programmierung von Rafael Bielen 1 Inhalt

N-Version Programmierung von Rafael Bielen 1

Inhalt Einleitung Motivation Funktionsprinzip Herausforderungen Abwandlungen wichtige historische Ansätze Probleme Fazit 2

Einleitung 1/2 weiterer Ansatz um Software fehlertoleranter und robuster zu entwickeln Programmierfehler mildern Kernidee: mehrfach dasselbe Programm implementieren Hoffnung: Auftreten gleicher Fehler senken 3

Einleitung 2/2 Implementierungen unabhängig voneinander alle Implementierungen nach gleichen Spezifikationen ein Algorithmus wählt das vermutlich richtige Ergebnis 4

Motivation Wieso Programmierfehlern vorbeugen? Sichere Software spart Kosten! Ariane 5 Satelliten, 1, 7 Milliarden DM Schaden Programmierfehler: 64 Bit – 16 Bit Umwandlung Studie aus dem Jahr 1986: pro 1 Million Zeilen Code 20. 000 Bugs 5

Funktionsprinzip Software ist kein „ganzes Stück“ mehr besteht aus verschiedenen Softwaremodulen 6

Herausforderungen 1/4 Spezifikationen: Eingabespezifikation, ein Fehler N fehlerhafte Softwaremodule Cross-Check Punkte gut definieren Designfehler ausschließen Freiraum für verschiedene Implementierungen lassen 7

Herausforderungen 2/4 unabhängige Entwicklung: Ziel: Auftreten von gemeinsamen Fehlern in den unterschiedlichen Softwareversionen vermindern. verschiedene Programmiersprachen benutzen Verwendung von unterschiedlichen Instrumenten und Compilern unterschiedliche Teams 8

Herausforderungen 3/4 Entscheidungs-Algorithmus: effizient selber sicher von Fehlern Wie erkennt man das richtige Ergebnis? oftmals einziger Weg Mehrfachbeschluss 9

Herausforderungen 4/4 Wartung eines laufenden Systems: Welches Modul verursacht einen Fehler? Wartung aufwendiger als bei „normaler“ Software höhere Wartungskosten 10

N-Version Programmierung Abwandlungen verschiedene Abwandlungen Darstellung von verschiedenen Konfigurationen der Abwandlungen als 3 er Tupel möglich. Zeit | Plattformen | Software 11

Single-Channel 1/2 Nutzung einer einzigen Plattform zur Ausführung N x Zeit | 1 x Plattform | N x Software Rollback-Methode Beispiel: 2 x Zeit | 1 x Plattform | 1 x Software Rollback zum letzten fehlerfreien Zustand mehrfacher Rollback bei einem Fehler auch möglich nicht geeignet für permanente Fehler (zerstörte Hardware) Reparatur von außen nötig 12

Single-Channel 2/2 neue Softwareinstanz-Methode Beispiel: Starten einer neuen Softwareinstanz 2 x Zeit | 1 x Plattform| 2 x Software Daten auf denen gearbeitet wird stabile und fehlerfreie gespeicherte Kopie 13

Multi-Channel 1/3 alles nur einmal berechnen mehrere Softwareversionen, jede auf einer eigenen Plattform 1 x Zeit | N x Plattformen | N x Software NASA's Space Shuttle mit N = 4 2. Punkt wichtig für Realisierung 14

Multi-Channel 2/3 1. Konsistenz: Plattformen müssen alle die gleiche Eingabe bekommen sowie im gleichen Startzustand sein. 2. Zuverlässiger Entscheidungs. Algorithmus: Kontrolle aller Ergebnisse der Berechnungen unnötig Akzeptanzbereich 15

Multi-Channel 3/3 Entscheidungs-Algorithmus wird oft für jeden Bereich neu geschrieben. hilft nicht gegen Designfehler Lösung: Erstelle von Software und Hardware individuelle Versionen. 16

Welche Fehler können behoben werden? Fehlerbehebung möglich bei: Programmierfehlern Programmfehlern Hardwarefehlern Kein Erfolg bei: mangelhafter Spezifikation fehlerbehaftetem Input Fehler in der Bedienung 17

Wichtige historische Ansätze Dr. Dionysius Lardner (1834): Fehler vorbeugen durch gleiche Berechnungen auf unterschiedlichen Plattformen N-Version Programmierung: auch genannt Multi. Version Programmierung, Beginn 1970 zwei wichtige Ansätze von: Brian Randell UCLA (Universität von Kalifornia, Los Angels) 18

„Recovery Block“ von Brian Randell 1/2 Ziel: Softwarefehler, auch welche die durch Hardwarefehler verursacht werden, im laufenden Betrieb zu erkennen. Ursprungsversion der Software erstellen Berechnungen der Version im laufenden Zustand mit der Berechnung der Ursprungsversion verglichen Akzeptanztest 19

„Recovery Block“ von Brian Randell 2/2 Nichtbestehen des Akzeptanztests ältere Version der Software einspielen, die den Test bestanden hat N x Zeit | 1 x Hardware | N x Software Variierung der „Recovery Block“ Methode möglich: unterschiedliche Plattformen um Design- und Hardwarefehler auszuschließen 20

NVP von UCLA Erstellung von individuell gestalteten Softwaremodule erfüllen alle die gleichen Spezifikationen vermutlich richtiges Ergebnis mit Hilfe eines Algorithmus auswählen 1 x Zeit | N x Hardware | N x Software 21

Experimentale Resultate der UCLA 1/4 UCLA negativ aufgefallen „Klassische“ Computersysteme sind nicht gut dafür geeignet, N-Version Software auszuführen und zu überwachen. Eigener Computer Prototyp designt und implementiert (DEDIX = Design Diversity Experiment). 22

Experimentale Resultate der UCLA 2/4 Betriebssystem, Unix Abwandlung, genannt LOCUS DEDIX nutzt eine verteilte Rechenarchitektur, die auf 20 VAX 11/750 Computern basiert (3. 125 MHz pro Maschine) 23

Experimentale Resultate der UCLA 3/4 Studie: Spezifikation in je 3 Sprachen für das gleiche Problem/Aufgabe OBJ (Declarative "ultra high-level" Sprache) PDL (Seitenbeschreibungssprache) Englisch als 3 te Kontrollsprache 24

Experimentale Resultate der UCLA 4/4 30 Programmierer beschäftigt, die 19 Programme erstellten 8 Programme aus der OBJ Spezifikation 5 aus der PDL Spezifikation 6 aus der Kontrollsprache Eng. Spezifikation = 10 Seiten OBJ Spezifikation = 7 Seiten PDL Spezifikation = 74 Seiten 25

Probleme 1/5 Tests: 6 unterschiedliche Versionen, alle untereinander testen, 21 Tests nötig Aufwand fast um N-Mal höher als bei „normaler“ Software Tests werden komplexer Wechselwirkung Entscheidungs-Algorithmus muss getestet werden Kosten steigen damit 26

Probleme 2/5 Unterschiedliche Plattformen und Betriebssysteme: Für jedes Betriebssystem meistens eigene Testkonfigurationen und unterschiedliche Hilfsprogramme notwendig Probleme Ergebnisse untereinander vergleichen unterschiedliche Zeichensätze oder komplett andere Byte-Reihenfolge 27

Probleme 3/5 28

Probleme 4/5 Kosten: Es gibt keine konkreten Statistiken, die besagen wie viel teurer die Entwicklung von NSoftware Versionen ist. Zahlen schwanken von 25%-134% Die Idee, N-Versionen einer Software lassen die Kosten um N-Mal multiplizieren, ist falsch! viele Gemeinsamkeiten in der Entwicklung 29

Probleme 5/5 Unabhängige Versionen: Problemlösung lässt oft wenig Spielraum Implementierungen oft ähnlich Keine Studien die Beweisen, dass gleiche Fehler gemindert werden. 30

Fazit 1/2 Positiv: interessanter Ansatz praktisch Einsetzung z. B. NASA Space Shuttle intuitiv verschiedene Softwareversionen müssen nicht die gleichen Fehler enthalten 31

Fazit 2/2 • Negativ: • nicht gut entwickelt/erforscht • Kosten/Aufwand? • Werden gleiche Fehler wirklich minimiert? ! • Entscheidungs-Algorithmus nicht trivial

Fragen? 33

Literaturverzeichnis Algirdas Avizienis. The N-Version Approach to Fault-Tolerant Software Engineering, IEEE Transactions on , vol. SE-11, no. 12, pp. 1491 - 1501, Dec. 1985 Israel Koren and C. Mani Krishna. Fault-Tolerant Systems. Morgan Kaufmann Publishers Inc. , San Francisco, CA, USA, 2007 Proseminar Software Desaster ARIANE 5 Absturz des Flugs 501 Mathias Riedl 4. 12. 2002, Vorlesung Universtität Zürich, Martin Glinz Software Engineering I The Evolution of the Recovery Block Concept. BRIAN RANDELL and JIE XU University of Newcastle upon Tyne 34

35