N-Version Programmierung

Präsentation zum Thema: "N-Version Programmierung"—  Präsentation transkript:

1 N-Version Programmierung
von Rafael Bielen

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

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

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

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

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

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

8 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

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

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

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

12 Single-Channel 1/2 Rollback-Methode Beispiel:
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

13 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

14 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

15 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

16 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.

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

18 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)

19 „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

20 „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

21 NVP von UCLA Erstellung von individuell gestalteten Softwaremodulen
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

22 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).

23 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)

24 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 3te Kontrollsprache

25 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

26 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

27 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

28 Probleme 3/5

29 Probleme 4/5 Kosten: Es gibt keine konkreten Statistiken, die besagen wie viel teurer die Entwicklung von N-Software 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

30 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.

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

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

33 Fragen? Fragen?

34 Literaturverzeichnis
Algirdas Avizienis.The N-Version Approach to Fault-Tolerant Software. Software Engineering, IEEE Transactions on , vol.SE-11, no.12, pp , 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 , Vorlesung Universtität Zürich, Martin Glinz Software Engineering I The Evolution of the Recovery Block ConceptBRIAN RANDELL and JIE XU University of Newcastle upon Tyne

35