1
N-Version Programmierung N-Version Programmierung
von Rafael Bielen
2
Inhalt Inhalt
Einleitung
Motivation
Funktionsprinzip
Herausforderungen
Abwandlungen
wichtige historische Ansätze
Probleme
Fazit
3
weiterer Ansatz um Softwarefehlertoleranter und robuster zuentwickeln
Programmierfehler mildern
Kernidee:
mehrfach dasselbe Programmimplementieren
Hoffnung: Auftreten gleicher Fehler senken
Einleitung 1/2 Einleitung 1/2
4
Implementierungen unabhängigvoneinander
alle Implementierungen
nach gleichen
Spezifikationen
ein Algorithmus wählt
das vermutlich richtige Ergebnis
Einleitung 2/2 Einleitung 2/2
5
Wieso Programmierfehlern vorbeugen?
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
20.000 Bugs
Motivation Motivation
6
Software ist kein „ganzes Stück“ mehr
besteht aus verschiedenenSoftwaremodulen
Funktionsprinzip Funktionsprinzip
7
Herausforderungen 1/4 Herausforderungen 1/4
Spezifikationen:
Eingabespezifikation, ein Fehler
N fehlerhafte Softwaremodule
Cross-Check Punkte gut definieren
Designfehler ausschließen
Freiraum für verschiedeneImplementierungen lassen
8
unabhängige Entwicklung:
Ziel: Auftreten von gemeinsamen Fehlern inden unterschiedlichen Softwareversionenvermindern.
verschiedene Programmiersprachenbenutzen
Verwendung von unterschiedlichenInstrumenten und Compilern
unterschiedliche Teams
Herausforderungen 2/4 Herausforderungen 2/4
9
Herausforderungen 3/4 Herausforderungen 3/4
Entscheidungs-Algorithmus:
effizient
selber sicher von Fehlern
Wie erkennt man das richtige Ergebnis?
oftmals einziger Weg Mehrfachbeschluss
10
Herausforderungen 4/4 Herausforderungen 4/4
Wartung eines laufenden Systems:
Welches Modul verursacht einen Fehler?
Wartung aufwendiger als bei „normaler“Software
höhere Wartungskosten
11
verschiedene Abwandlungen
Darstellung von verschiedenenKonfigurationen der Abwandlungen als3er Tupel möglich.
Zeit | Plattformen | Software
N-Version Programmierung Abwandlungen N-Version Programmierung Abwandlungen
12
Nutzung einer einzigen Plattform zurAusfü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örteHardware) Reparatur von außen nötig
Single-Channel 1/2 Single-Channel 1/2
13
neue Softwareinstanz-MethodeBeispiel:
Starten einer neuen Softwareinstanz
2 x Zeit | 1 x Plattform| 2 x Software
Daten auf denen gearbeitet wird
stabile und fehlerfreie gespeicherte Kopie
Single-Channel 2/2 Single-Channel 2/2
14
Multi-Channel 1/3 Multi-Channel 1/3
alles nur einmal berechnen
mehrere Softwareversionen, jede auf einereigenen 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 Multi-Channel 2/3
1. Konsistenz:
Plattformen müssen alle die gleiche Eingabebekommen sowie im gleichen Startzustandsein.
2. Zuverlässiger Entscheidungs-Algorithmus:
Kontrolle aller Ergebnisse der Berechnungenunnötig Akzeptanzbereich
16
Multi-Channel 3/3 Multi-Channel 3/3
Entscheidungs-Algorithmus wird oft fürjeden Bereich neu geschrieben.
hilft nicht gegen Designfehler
Lösung: Erstelle von Software undHardware individuelle Versionen.
17
Welche Fehler können behoben werden? 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 historischeAnsätze Wichtige historischeAnsätze
Dr. Dionysius Lardner (1834): Fehler vorbeugendurch gleiche Berechnungen aufunterschiedlichen 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 „Recovery Block“ von Brian Randell 1/2
Ziel:
Softwarefehler, auch welche die durchHardwarefehler verursacht werden, imlaufenden Betrieb zu erkennen.
Ursprungsversion der Software erstellen
Berechnungen der Version im laufendenZustand mit der Berechnung derUrsprungsversion verglichen Akzeptanztest
20
„Recovery Block“ von Brian Randell 2/2 „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“ Methodemöglich:
unterschiedliche Plattformen um Design- undHardwarefehler auszuschließen
21
NVP von UCLA NVP von UCLA
Erstellung von individuell gestaltetenSoftwaremodulen
Softwaremodule erfüllen alle die gleichenSpezifikationen
vermutlich richtiges Ergebnis mit Hilfe einesAlgorithmus auswählen
1 x Zeit | N x Hardware | N x Software
22
Experimentale Resultate der UCLA 1/4 Experimentale Resultate der UCLA 1/4
UCLA negativ aufgefallen
„Klassische“ Computersysteme sind nichtgut dafür geeignet, N-Version Softwareauszuführen und zu überwachen.
Eigener Computer Prototyp designt undimplementiert (DEDIX = Design DiversityExperiment).
23
Experimentale Resultate der UCLA 2/4 Experimentale Resultate der UCLA 2/4
Betriebssystem,Unix Abwandlung,genannt LOCUS
DEDIX nutzt eine verteilteRechenarchitektur, die auf 20 VAX 11/750Computern basiert (3.125 MHz proMaschine)
24
Experimentale Resultate der UCLA 3/4 Experimentale Resultate der UCLA 3/4
Studie:
Spezifikation in je 3 Sprachen für dasgleiche Problem/Aufgabe
OBJ (Declarative "ultra high-level" Sprache)
PDL (Seitenbeschreibungssprache)
Englisch als 3te Kontrollsprache
25
30 Programmierer beschäftigt, die 19Programme 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
Experimentale Resultate der UCLA 4/4 Experimentale Resultate der UCLA 4/4
26
Probleme 1/5 Probleme 1/5
Tests:
6 unterschiedliche Versionen, alleuntereinander testen, 21 Tests nötig
Aufwand fast um N-Mal höher als bei„normaler“ Software
Tests werden komplexer Wechselwirkung
Entscheidungs-Algorithmus muss getestetwerden
Kosten steigen damit
27
Unterschiedliche Plattformen undBetriebssysteme:
Für jedes Betriebssystem meistens eigeneTestkonfigurationen und unterschiedlicheHilfsprogramme notwendig
Probleme Ergebnisse untereinandervergleichen
unterschiedliche Zeichensätze oderkomplett andere Byte-Reihenfolge
Probleme 2/5 Probleme 2/5
28
Probleme 3/5 Probleme 3/5
29
Probleme 4/5 Probleme 4/5
Kosten:
Es gibt keine konkreten Statistiken, diebesagen wie viel teurer die Entwicklung von N-Software Versionen ist.
Zahlen schwanken von 25%-134%
Die Idee, N-Versionen einer Software lassendie Kosten um N-Mal multiplizieren, ist falsch!
viele Gemeinsamkeiten in der Entwicklung
30
Probleme 5/5 Probleme 5/5
Unabhängige Versionen:
Problemlösung lässt oft wenig Spielraum Implementierungen oft ähnlich
Keine Studien die Beweisen, dass gleicheFehler gemindert werden.
31
Fazit 1/2 Fazit 1/2
Positiv:
interessanter Ansatz
praktisch Einsetzung z.B. NASA SpaceShuttle
intuitiv verschiedene Softwareversionenmüssen nicht die gleichen Fehler enthalten
Fazit 2/2 Fazit 2/2
•Negativ:
•nicht gut entwickelt/erforscht
•Kosten/Aufwand?
•Werden gleiche Fehler wirklich minimiert?!
•Entscheidungs-Algorithmus nicht trivial
33
Fragen? Fragen?
Fragen?
34
Literaturverzeichnis Literaturverzeichnis
Algirdas Avizienis.The N-Version Approach to Fault-Tolerant Software.Software Engineering, IEEE Transactions on , vol.SE-11, no.12, pp.1491- 1501, Dec. 1985
Israel Koren and C. Mani Krishna. Fault-Tolerant Systems. MorganKaufmann Publishers Inc., San Francisco, CA, USA, 2007
Proseminar Software Desaster ARIANE 5 Absturz des Flugs 501Mathias Riedl
4.12.2002, Vorlesung Universtität Zürich, Martin Glinz SoftwareEngineering I
The Evolution of the Recovery Block ConceptBRIAN RANDELL and JIEXU University of Newcastle upon Tyne
35