1 an experimental evaluation of the assumption of independence in multi-version programming john c....
TRANSCRIPT
1
An Experimental Evaluation of
the Assumption of Independence
in Multi-Version Programming
John C. Knight (University of Virginia)
Nancy G. Leveson (University of California, Irvine)
2
Inhalt
1 Wichtige Begriffe2 Motivation3 Einführung4 Das Experiment
4.1 Programmierer-Hintergrund4.2 Resultate des Experiments4.3 Unabhängigkeitsmodell4.4 Analyse der Programm-Defekte4.5 Diskussion des Experiments4.6 Fazit
5 Folgen6 Personen
3
1 Wichtige Begriffe
(Achtung: nicht einheitlich)
Defekt / fault: Teil des Systems verhält sich nicht so wie es sollte, bedingt durch Hardware- oder Software-Fehler
Fehlschlagen / failure: Gesamtsystem verhält sich nicht so wie es sollte, bedingt durch Defekt
Fehler (-zustand) / error: Versagen der Hardware oder Software
4
Fehlertoleranz / fault tolerance: Systemeigenschaft, die bedeutet:Defekt wird so abgefangen, daß das
gewünschte Systemverhalten gesichert bleibt: Defekt führt nicht zu Fehlschlag
5
N-Versionen-Programmierung (NVP) wurde lange Zeit als „die“ Methode angesehen, umfehlertolerante Software zu schreiben:
• Mehrere verschiedene Implementierungen einer Spezifikation werden parallel ausgeführt
• Die Ergebnisse werden gesammelt und von einer Entscheidungseinheit / Voter verglichen
• bei einer angenommenen Mehrheit gleicher Ergebnisse wird das mehrheitliche Ergebnis als korrekt angesehen
2 Motivation
6
• Fehlertoleranz ist immens wichtig bei sicherheitskritischen Applikationen, bei denen Menschen zu Schaden kommen können
• Die unbedingte Korrektheit des Mehrheitsergebnis beruht allerdings auf einer zentralen Annahme:
Alle Fehlschläge passieren unabhängigvoneinander
wenn ein Programm Fehlschläge zeigt, ist es nicht wahrscheinlich, dass dies auch die anderen Versionen tun
7
• Falls Fehlschläge doch miteinander in Beziehung stehen, wird es wahrscheinlicher, dass mehrere Versionen zugleich fehlschlagen
d.h. das Mehrheitsergebnis könnte falsch sein !
8
• Bis 1985 galt die Unabhängigkeits-Annahme allgemein als wahr
• Wurde nie statistisch überprüft
• Wegen der Relevanz von sicherheitskritischen Systemen, die NVP benutzen, haben Knight/Leveson 1985 ein Experiment zur Überprüfung gestartet
Zeigte, dass die Annahme falsch ist
9
NVP Anforderungen
• separate, unabhängig voneinander erstellte „N“ Versionen
• Jede Version muss dieselbe Funktionalität besitzen
daher braucht man ein gemeinsames Anforderungs-Dokument
3 Einführung
10
NVP Anforderungen (2)
• Koordination, da die Versionen Daten an den Voter übermitteln
• Alle Design-Entscheidungen müssen unabhängig voneinander getroffen werden
sonst keine Vermeidung von gemeinsamen Design-Fehlern!
11
Nutzen von NVP
• Soll die Verlässlichkeit von Software erheblich erhöhen
• Analyse der NVP-Methode bzgl. Verlässlichkeit basiert auf der Annahme
• dass alle N Versionen unabhängig voneinander fehlschlagen
• dass also Defekte in den N Versionen zufällig vorkommen und nicht zueinander in Beziehung stehen
12
Nutzen von NVP (2)
Folgerungen aus der Annahme: • Wahrscheinlichkeit, dass zwei oder mehr
Versionen auf der gleichen Eingabe fehlschlagen, ist sehr gering
• W-keit des Fehlschlagens eines NVP-Systems ist proportional zur mit N potentierten W-keit des Fehlschlagens der unabhängigen Versionen
13
Nutzen von NVP (3)
Verlässlichkeit des Systems könnte größer sein als die Verlässlichkeit der individuellen Komponenten
man könnte sich das aufwändige Testen und Validieren von Software sparen,
indem einfach ein System aus genügend vielen Komponenten zusammengestellt wird
14
Nutzen von NVP (4)
Ein um 1985 weit verbreiteter Gedanke war:
man könne das Testen sicherheitskritischer Real-Zeit-Systeme vereinfachen
• indem zwei Software-Versionen produziert werden (nur zwei, weil teuer)
• und umfangreichen Tests unterzogen werden,
• ohne dass das Ergebnis von Hand auf Korrektheit überprüft werden muss !!!
15
Nutzen von NVP (5)
Denn solange beide Ergebnisse übereinstimmen, wird das gemeinsame Ergebnis als korrekt angenommen
16
4 Das Experiment
Fand statt mit Informatik-Studenten (graduate oder senior) an den Universitäten
• University of Virginia (UVA) und• University of California at Irvine (UCI)
Studenten sollten Programme zu einer ganz bestimmten Spezifikation schreiben
27 Programme (9 UVA und 18 UCI), die theoretisch für die gleiche Eingabe alle die gleiche Ausgabe liefern sollten
17
Alle 27 Programme wurden einer Million zufällig erzeugter Tests unterzogen
Experiment sollte möglichst realistisch sein, daher wurde eine Applikation programmiert, die ein Kandidat für eingebaute Fehlertoleranz ist:
Anti-Raketen-System
• einfach aber realistisch• das zu lösende Problem stammt
ursprünglich aus einem Luft- und Raumfahrtunternehmen
18
Anforderungen an das Programm
• Daten lesen, die Radarwerte darstellen
• Mittels einer Menge von Bedingungen entscheiden, ob die Radarwerte von einem bedrohlichen Objekt kommen oder nicht
• Wenn die Entscheidung für „bedrohlich“ ausfällt, soll ein Signal erzeugt werden, das den Abfangjäger aktiviert
Problem ist der Fachwelt als „launch interceptor problem“ bekannt
19
Die Spezifikation
• Dies Problem war schon in anderen Experimenten benutzt worden
• Insbesondere ein NVP-Experiment mit N=3 am Research Triangle Institute (RTI)
• Die Spezifikation konnte wiederverwendet und dabei um einige Fehler reduziert werden
Die Spezifikation war also sorgfältig auf Fehler untersucht worden
20
Sicherstellen von Unabhängigkeit
• die Spezifikation wurde den Studenten gegeben
• keine bestimmte Softwareentwicklungs-Methode war vorgegeben
• Bedeutung von unabhängiger Entwicklung wurde betont, Studenten hatten Anweisungen nicht untereinander zu diskutieren
• Fragen der Studenten zur Spezifikation wurden individuell per Mail beantwortet
21
• Studenten durften beliebige Referenzen benutzen
denn die Entwicklung von Algorithmen für die Applikation erforderte geometrisches Wissen
und wahrscheinlich wären auch für kommerzielle Entwicklung Referenzen zu Geometrie benutzt worden
22
Eingabedaten
• Jede(r) Student(in) bekam 15 Sätze mit Eingabedaten
• plus die zu erwartenden Ausgaben zu Debug-Zwecken
23
Akzeptanz-Test
• Satz aus 200 zufallsgenerierten Testfällen, die jedes Programm durchlaufen musste
• Für jedes der 27 Programme ein eigener Satz
• man wollte verhindern, dass zuviele gemeinsame Defekte beim Akteptanz-Test herausgefiltert wurden
• Warum Akzeptanz-Test?Software aus realer Produktion würde auch ausführlichen Test unterzogen werden, um eine hohe Verlässlichkeit sicherzustellen
24
Test-Treiber für den Akzeptanz-Test
• Generierte zufällige Radarwerte und Zufallswerte für alle Parameter im gestellten Problem
• Es gab eine „Gold-Version“ („gold version“)
• Programm, das ursprünglich in FORTRAN für das RTI-Experiment geschrieben worden war
• nun neu geschrieben in Pascal• im RTI-Experiment war die Gold-Version
durch mehrere Millionen Testfälle gelaufen
25
• Alle 27 Programme wurden gegen die Gold-Version getestet
so konnte man mehr Testfälle ausführen, weil die Ausgaben nicht manuell
überprüft werden mussten
• Insgesamt wurden die 27 Programme plus die Gold-Version 1 000 000 Tests unterzogen
• Auf verschiedenen Maschinen an verschiedenen Orten (Mai bis September 1984)
26
Gold-Version wirklich verlässlich?
• Was, wenn der unwahrscheinliche Fall eintritt, und alle 28 Versionen inkl. Gold-Version die gleichen Fehlschläge zeigen:
• Das hätte keinen Effekt auf den Ausgang des Experiments
• unentdeckte gemeinsame Defekte würden nur das Fazit des Experiments bestärken
27
4.1 Programmierer-Hintergrund
• 14 Programmierer arbeiteten an ihrem Bachelor
• 8 Programmierer arbeiteten an ihrem Master (und hatte mindestens einen Bachelor)
• 4 arbeiteten an ihrem Doktor (und hatten mindestens einen Master)
• 1 Programmierer konnte nicht in die Analyse mit einbezogen werden
28
• Von denjenigen mit Bachelor waren
• 4 aus Mathematik• 3 aus Informatik
• je 1 aus Astronomie, Biologie, Umwelt-Wissenschaften, Management-Wissenschaften, Physik
29
• Arbeitserfahrung der Programmierer in der Softwareentwicklung reichte von 0 bis über 10 Jahre
• Die meisten hatten nur ein paar Monate gearbeitet
• Bei Selbst-Einstufung ihrer Pascal-Fähigkeiten kam folgendes heraus:
expert thorough fair limited
4 18 4 -
30
• Programmierer sollten die Verlässlichkeit ihrer Programme schätzen
Schätzungen lagen alle zwischen 0.75 und 1.0
• die meisten Programme stellten sich als verlässlicher heraus die Programmierer geschätzt hatten
31
4.2 Resultate des Experiments
• Für jeden Testfall berechnete jedes Programm
• 15x15 Boolean Arrays• einen 15-elementigen Boolean-Vector• eine einzelne Aktivierungs-Entscheidung• für insgesamt 241 Resultate
• Die Aktivierungs-Entscheidung war die einzige echte Ausgabe
• Rest waren erforderliche Zwischenergebnisse
32
Qualität der Programme
• war ungewöhnlich hoch
• von den 27 Versionen hatten 6 gar kein Fehlerverhalten
• die anderen 21 bestanden mindestens 99% der Tests
• 23 der 27 waren erfolgreich bei mehr als 99.9% der Tests
33
Gemeinsame Defekte
• erstaunlicherweise gab es Testfälle, bei denen 8 der 27 Versionen fehlschlugen!
• Entgegen erster Vermutung waren die 8 Versionen nicht an derselben Universität entwickelt worden
• Alle entdeckten gemeinsamen Defekte wurden in Versionen von stets beiden Universitäten gefunden
34
4.3 Unabhängigkeitsmodell
Es wurde ein Wahrscheinlichkeitsmodell für Unabhängigkeit von Fehlschlägen entwickelt
und bewiesen, dass dieses Modell für das Experiment nicht gültig ist.
35
Hypothese:Für ein beliebiges gegebenes Programm wird angenommen, dass die Wahrscheinlichkeit eines Fehlschlags für jeden Testfall dieselbe ist.
• Um diese Hypothese auf ihren Wahrheitsgehalt zu testen, wurde aus der statistischen Definition für unabhängige Ereignisse [ pr(A|B) = pr(A) und pr(B|A) = pr(B) ]ein Modell entwickelt
• Für die Parameter im Modell wurden Werte aus dem Experiment eingesetzt
36
• Die Wahrscheinlichkeitsverteilung des Modells konnte durch die standardisierte Normalverteilung gut approximiert werden
• In der standardisierten Normalverteilung liegt der 99%-Punkt bei x = 2.33
• Die Statistik des Modells mit eingesetzten Parametern hatte allerdings den Wert 100.51 größer als 2.33
Also wurde die Hypothese mit einer Sicherheit von 99% verworfen.
37
• Daraus schlossen Knight & Leveson, dass das Wahrscheinlichkeitsmodell nicht für das Experiment gültig ist.
• Da das Modell aus der Annahme von unabhängigen Fehlschlägen entwickelt worden war, wurde auch die Unabhängigkeitsannahme verworfen.
38
Warum wurden die Fehlschläge und nicht die Defekte berücksichtigt?
• Aus Operationssicht ist es egal, warum ein Programm fehlschlägt
• es zählt nur, dass ein Programm fehlschlägt
• Darum wurden die Defekte im Programmquelltext für die Überprüfung der Hypothese außenvorgelassen
39
4.4 Analyse der Programm-Defekte
Knight & Leveson definierten:
Defekt / faultein Programmstück in einer bestimmten Version, das diese Version fehlschlagen lässt, wenn das Programmstück auf einem Testfall ausgeführt wird
40
• insgesamt 45 Defekte entdeckt
• viele waren individuell, aber mehrere traten in mehr als einer Programmversion auf
• erstere Defekte werden nicht-korrelierend, letztere korrelierend genannt
• Details der Defekte sind komplex, daher hier nur ein erhellendes Beispiel (folgende Folie):
41
• Man musste eine Annahme machen über den Winkel, den drei Punkte bilden
• Dabei waren drei Fälle zu unterscheiden
• Einer der Fälle war subtiler und wurde von mehr als einem Programmierer übersehen
Keine Fehler der Spezifikation, sondern ein Mangel an geometrischem Verständnis –typisches menschliches Problem!
42
4.5 Diskussion des Experiments
Problem bei Durchführung von Experimenten anUniversitäten: realistische Programmier-
erfahrung der Teilnehmer
Aber: • viele Studenten hatten schon professionell
gearbeitet und waren zurück an die Universität gekommen
• Der erfahrenste Real-Zeit-Programmierer im Experiment machte auch viele Fehler
43
Weiterer möglicher Einwand wäre:
• Experiment spiegelt keine realistische Softwareentwicklung aus der Industrie wieder,
• 1 Mio Testfälle sind nicht viel Operations-Zeit für eine solche Applikation.
1 Mio Testfälle entsprechen allerdings 1 Mio ungewöhnlicher Zwischenfälle auf dem Radarschirm. Dazu kommen noch viel mehr Testfälle für gewöhnliche Radarwerte
1 Mio Testfälle korrespondieren laut Knight&Leveson mit 20 Jahren Operationszeit
44
4.6 Fazit
Für das spezifische Problem, das im Experiment programmiert wurde, hält die für die NVP-Analyse fundamentale Annahme, dass eine Unabhängigkeit von Fehlschlägen gegeben sei, nicht.
Mit einer Sicherheit von 99% hält ein Wahrscheinlichkeitsmodell für Unabhängigkeit nicht für das durchgeführte Experiment.
45
• Knight & Leveson betonen, dass diese Aussage von der Applikation abhängt
• NVP ist weiterhin eine sinnvolle Methode,
• aber die Verlässlichkeit eines NVP-Systems ist möglicherweise geringer als in der Theorie behauptet
halten weitere Beschäftigung mit möglichen gemeinsamen Defekten in NVP-Systemen für sinnvoll, da dies sicherheitskritische Systeme betrifft!
46
5 Folgen
• Knight&Leveson-Experiment schlug große Wellen
• In den folgenden Jahren wurden Kni&Lev mit Kritik von NVP-Befürwortern überhäuft
• hauptsächlich von Prof. Algirdas Avizienis von der University of California, Los Angeles (UCLA) und Mitgliedern seiner Arbeitsgruppe
47
• Wegen der andauernden Vorwürfe veröffentlichten Knight&Leveson 1990 (!)ein weiteres Paper als Antwort auf die Kritik
Auszüge aus der Kritik von Avizienis:
„These efforts serve to illustrate the pitfalls of premature preoccupation with numerical results.“
K&L weisen die Kritik zurück und stellen die rethorische Frage, wieso Prof. Avizienis dann den Einsatz von NVP in sicherheitskritischen Applikationen nicht auch zu früh findet
48
„The use of the term ‘experiment‘ is misleading, since it implies repeatability of the experimental procedure that is taken for granted in science.“
K&L weisen die Kritik zurück, da ihr Experiment komplett wiederholbar ist und auch von anderen Forschern wiederholt wurde (und sogar bestätigt worden ist).
• In ihrem Paper von 1990 gehen sie der Reihe nach auf alle Kritikpunkte ein und argumentieren schlüssig dagegen
49
• Das Knight&Leveson-Experiment gilt heute als
eins der mustergültigen Experimente in der
Informatik
50
Prof. Avizienis, UCLA
• Fellow of IEEE
• AIAA Information Systems Award
(1997)
• NASA Exceptional Service Medal
(1980)
• Annual IEEE Computer Society
Technical Achievement Award
(1985)
• IFIP Silver Core Award (1986)Forschungsschwerpunkte sind u.a. Fehlertoleranz,
Fehlertoleranz in verteilten Systemen und Design-Methodiken
für fehlertolerante Systeme.
51
Nancy Leveson
• Professorin am MIT für Aeronautics
and Astronautics and Engineering
• studierte am UCLA bis zum Ph.D.
• Fellow of the ACM
• ACM Allen Newell Award for research
contributions to computer science
(1999)
• elected to the National Academy of
Engineering (NAE)
AIAA Information Systems Award for "developing the field of
software safety and for promoting responsible software and system
engineering practices where life and property are at stake.“ (1995)
52
John C. Knight
• Professor an der University of Virgina
in Computer Science (seit 1992)
• war 1985/1986 Associate Professor
an der University of Virginia
• Editor in Chief, IEEE Transactions on
Software Engieneering, Jan 2002 -
present
Forschungsschwerpunkt heute u.a. Software Dependability
53
Quellen
[1] J.C. Knight and N.G. Leveson, „An Experimental Evaluation of the Assumption of Independence in Multi-Version Programming“, IEEE Transactions on Software Engineering, Vol. SE-12, No. 1 (January 1986), pp. 96-109.
[2] J.C. Knight and N.G. Leveson, „A Reply to the Criticisms of the Knight&Leveson Experiment, Software Engineering Notes, Vol. 15, No. 1 (January 1990), pp. 24-35.
[3] Prof. Algadir Avizienis Homepage http://www.cs.ucla.edu/csd/people/faculty_pages/avizienis.html
54
Quellen
[4] Prof. John Knight Homepage http://www.cs.virginia.edu/~jck/
[5] Prof. Nancy Leveson Homepage http://sunnyday.mit.edu/[6] Verteilte Systeme Vorlesung Prof. H.-P. Löhr
http://www.inf.fu-berlin.de/lehre/SS03/alpIV/vorlesung.html