Empfehlung einer Strategie

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:


64Bit – 16Bit 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
3er 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 EntscheidungsAlgorithmus:

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 MultiVersion 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
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
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 3te 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?

Fragen?
33
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. 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 ConceptBRIAN RANDELL and JIE
XU University of Newcastle upon Tyne
34
35