Title: Dependable Systems

Q: Was bedeutet Dependability?
A: Original: Dependability is the ability to deliver service that can justifiably be trusted.
Alternate: Dependability of a system is the ability to avoid service failures that are more frequent and more severe than is acceptable.

Q: Fault, Error, Failure
A: The (hypothesized) cause of an error is called a fault.
A service failure means that at least some external state of the provider service deviates from the correct state. This deviation is called the error (i.e., a deviation from the current state from the correct state).
A (service) failure is an event that occurs when the delivered service deviates from correct service. Thus, a failure is a transition from correct service to incorrect service.

Q: Attributes of Dependability
A: Reliability (Funktionsfähigkeit): Verlässlichkeit bezogen auf Kontinuität des Service. R(t) ist die Wahrscheinlichkeit, dass das System über eine Periode t hinweg ununterbrochen zur Verfügung steht.
Availability (Verfügbarkeit): Verlässlichkeit bezogen auf die Verfügbarkeit zu einem bestimmten Zeitpunkt: A oder V ist der Prozentsatz der Zeit, zu dem das System gemäß den Spezifikationen funktioniert.
Maintainability: Ability to undergo modifications and repairs.
Safety (Sicherheit): Verlässlichkeit bezogen auf das Vermeiden katastrophaler Auswirkungen
Integrity: absence of improper system alterations

Q: Reliability vs. Availability (+ Examples)
A: Reliability is the probability that the system will conform to its functional specification throughout a period of duration t.
Availability is the percentage of time for which the system will conform to its specification (also considering repair actions).
→ Availability is a function of reliability and maintainability.
Examples:
High Availability: Factory
High Reliability: Satelitte

Q: Reliability vs. Safety
A: Reliability is the probability that the system will conform to its functional specification throughout a period of duration t.
Safety is the probability that the system will not exhibit specific undesired behaviors throughout a period of duration t.
In general, not all deviations from the functional specification imply specific undesired behaviors.

Q: Reliability vs. Safety Examples
A: Railway signalling: red signal is a safe system state, safe system state is unreliable
Fly-by-wire airplane control: after take off there is no safe (non-functional) system state

Q: Failure Mode Classification
A: Domain: content, early timing failure, late timing failure, ...
Detectability: signaled failures, unsignaled failures
Consistency: consistent failure, inconsistent failure
Consequences: minor failure, ..., catastrophic failure

Q: Examples for fault/failure chain
A: Program error (software):
− a dormant fault in the written software (instruction or data)
− upon activation the fault becomes active and produces an error (system state)
− if the erroneous data affects the delivered service, a failure occurs
Electromagnetic interference (hardware):
− leads to faulty input value (either digital or analog)
− by reading the input the fault becomes active and produces an error
− if the erroneous input value is processed and becomes visible at the interface a failure occurs

Q: Wie hoch ist die Availability in einem System, das nicht gewartet wird
A: Ist ein System ab dem ersten Ausfall nie wieder einsatzfähig (= Reparatur dauert unendlich lange), beträgt die Availability Null:

Q: Was ist eine gute Spezifikation?
A: - exakt
- konsistent
- vollständig
- verbindlich (authoritative)

Q: Assumption Coverage
A: Jedes Modell/Design basiert auf einer Menge von Annahmen über das Verhalten der Komponenten in der Umgebung. Die Assumption Coverage ist die Wahrscheinlichkeit, dass die Annahmen dem Szenario der realen Welt entsprechen.
Die berechnete Reliability eines Systems muss immer noch mit der Assumption Coverage multipliziert werden. Dadurch kann die Reliability oft empfindlich reduziert werden. Ein System mit perfekter Reliability ist immer nur so gut wie die Assumption Coverage, die der Berechnung der Reliability zugrunde liegt.

Wie sieht die Reliability bei konstanter Fehlerrate aus?

Describe Simple block diagrams

Q: Pros and Cons of Simple block diagrams
A: Pros:
• can be used to model arbitrary combinations of series and parallel connected components
• easy mathematics for constant failure rates
Cons:
• assumption of independent failures
• maintenance cannot be modeled
• restricted to series/parallel connection
• only for active redundancy and fail-silence

Compare probabilistic modeling techniques

Q: Describe the relationship between probability and severity (safety)
A: Das primäre Ziel von Safety ist eine umgekehrt proportionale Beziehung zwischen Wahrscheinlichkeit und Schwere eines Fehlers herzustellen: Wahrscheinliche Fehler sollen keine schwerwiegenden Konsequenzen haben, während Fehler mit katastrophalen Auswirkungen sehr unwahrscheinlich gemacht werden sollen.
Klassen der Severity:
- No Safety Effect
- Minor
- Major
- Hazardous (starke Reduktion der Sicherheit, zu Schaden kommen einer relativ kleinen Gruppe von Personen)
- Catastrophic (Absturz des Flugzeugs)
Klassen der Probability:
- Probable: ein oder mehrere Vorkommen im Leben eines Flugzeugs, p > 10⁻⁵ pro Flugstunde
- Improbable: Fehler tritt wahrscheinlich nicht im Leben eines Flugzeugs auf, könnte aber bei einigen wenigen Flugzeugen eines Typs auftreten, 10⁻⁹ < p < 10⁻⁵
- Extremely Improbable: Fehler tritt wahrscheinlich kein einziges mal in irgendeinem Flugzeug des selben Typs auf, p < 10⁻⁹

Q: Describe the Hierarchische Klassifikation of Failure Modes
A: - Byzantinische, Arbitrary (beliebige) Failures: keine Einschränkung des Verhaltens, z.B. kann das Fehlverhalten von zwei unterschiedlichen (korrekt arbeitenden) Komponenten unterschiedlich wahrgenommen werden.
- Authentification detectable byzantine Failures: wie Byzantinisch, jedoch können Nachrichten von anderen Systemen nicht gefälscht werden (nur sinnvoll bei verteilten Systemen)
- Performance Failures: Resultate sind korrekt bezogen auf den Wert, jedoch treffen sie zu früh oder zu spät ein (early oder late failures)
- Omission Failures: Resultate kommen entweder rechtzeitig oder nie an (Spezialfall von PerformanceFailures)
- Crash Failures: Bei Auftreten eines Fehlers sendet die Komponente in der Folge keine Resultate mehr. (Spezialfall von OmissionFailures)
- FailStop Failures: Spezialfall von CrashFailures, der von anderen Systemen erkannt werden kann. Außerdem kann der letzte gültige Zustand von einem stabilen Datenspeicher gelesen werden.

Describe the Arrhenius Equation

Q: What is Accelerated Stress Testing?
A: Wird verwendet um die Infant Mortality Failures schon vor der Auslieferung zu erkennen, und um die zu erwartende Fehlerrate mit relativ kurzen Testperioden abschätzen zu können.
Möglichkeiten des künstlichen Beschleunigens von FehlerauftrittsIntervallen:
- Erhöhung der Temperatur
- Verringerung der Temperatur
- schnelles Abwechseln von hohen und niedrigen Temperaturen
- Erhöhung der Spannung
- Erhöhung der Temperatur und der Spannung
- Erhöhung der Temperatur, Spannung und Feuchtigkeit
- Beschießen mit Alpha Partikeln
Für Software nicht anwendbar, da nicht bekannt ist, wie man „Stress“ für Software charakterisieren und simulieren kann.

Q: Preliminary hazard analysis
A: Stellt die erste Phase in jeder Safety Analyse dar. System Hazards, kritische Zustände und Failure- Modes werden definiert, kritische Elemente identifiziert und Konsequenzen und Wahrscheinlichkeiten der hazardous Events bestimmt und festgelegt. Die gewonnenen Erkenntnisse sind Thema genauerer Analyse in darauf folgenden Phasen.

Q: Hazards and Operability Study (HAZOP)
A: Systematisches Suchen nach Abweichungen, die zu Hazards führen könnten. Dazu wird für jeden Teil des Systems eine Spezifikation der „Intention“ erstellt, danach kann das System nach Abweichungen durchsucht werden. Es werden Guide Words anhand einer CheckListe abgearbeitet, um verschiedene Typen von Abweichungen zu spezifizieren: NO, NOT, MORE, LESS, AS WELL AS, PART OF, REVERSE, OTHER THAN
Die Analyse wird von einem Team bestehend aus unterschiedlichen Spezialisten durchgeführt.
Diese Methode ist gut um die Kommunikation zwischen beteiligten Personen zu erhöhen und um Ausgangspunkte für detaillierte Studien zu schaffen, jedoch ist sie nicht gut Standardisiert.

Q: Action Error Analysis
A: Beschäftigt sich mit den potentiellen Fehlern, die Menschen bei der Verwendung, Wartung, Kontrolle und Überwachung machen können.
- Die einzelnen Schritte in Bedienungsabläufen werden aufgelistet,
- für jeden Schritt eine Liste möglicher Fehler erstellt,
- die Konsequenzen der Fehler beurteilt
- sowie deren Ursache (gewisse Aktionen nicht durchgeführt, in Falscher Reihenfolge durchgeführt, etc..) bestimmt.
Darauf aufbauend kann analysiert werden, wie man Kontrolle über diese Ursachen bekommen kann.
AEA beschäftigt sich nicht mit den Gründen für Bedienungsfehler.
AEA ist besonders für Software im Bereich des User Interface Design wichtig.

Q: Fault Tree Analysis
A: Graphische Repräsentation von Kombinationen, die zu Hazards führen können. Dabei wird vom Hazard als Wurzel des Baums ausgegangen, die Verzweigungen finden an ODER- oder UND- Symbolen statt. Die einzelnen Knoten sind Events.
Kann als quantitative Methode verwendet werden.
Einschränkungen:
- Es wird angenommen, dass Fehler binär sind, also eine Komponente entweder komplett oder garnicht ausfällt.
- Bäume werden schnell sehr groß und unverständlich,
- sind nicht mathematisch eindeutig.

Q: Event Tree Analysis
A: Etwaige Konsequenzen von Fehlerursachen und Faults werden als Events modelliert. Ausgehend von grundlegenden Events werden die möglichen Konsequenzen des Events bis hin zu möglichen Fehlern abgeleitet. Umgekehrte Vorgehensweise wie bei FTA: es wird mit den Events begonnen. Kann als quantitative Methode verwendet werden.
Einschränkungen: Detaillierte Analysen können wegen des Großen Umfangs nicht erstellt werden, parallele Sequenzen, unvollständige, zu frühe oder zu späte Aktionen werden als Fehlerursache nicht in Betracht gezogen.

Q: Failure Modes and Effect Analysis
A: Der Designer muss systematisch die Fragen „Wie kann eine Komponente ausfallen?“ und „Was passiert in diesem Fall?“ beantworten. Dazu wird das System in Komponenten zerlegt (→ Block Diagram), für die die FailureModes, die Ursache und die Bedeutung von Fehlern identifiziert werden. Es wird ermittelt, wie Failures erkannt werden können und wenn notwendig Empfehlungen zu geeigneten Kontrollmaßnahmen gegeben.
Die Analyse wird durch standardisierte Tabellen unterstützt.
Einschränkungen: Kombinationen von technischen und menschlichen Fehlern werden oft nicht bedacht und es ist schwierig gleichzeitige Fehler zu Analysieren.

Q: Cause-consequence analysis
A: Kombination aus FTA und ETA: Startpunkte der Analyse sind kritische Events, ETA wird Verwendet um die Konsequenzen, FTA um die Ursachen zu ermitteln. Diese Methode ist sehr flexibel und gut dokumentiert, hat jedoch viele Nachteile der FTA (Baum wird schnell zu groß und unübersichtlich, bestimmte Kombinationen werden nicht bedacht, etc.)

Compare Safety Analysis Methods

Q: Was kann mit Markov Modellen modelliert werden was mit Blockdiagrammen nicht möglich ist?
A: Markov erlaubt Repairs, Assumption Coverage

Q: maintenance (warum besser als fault-tolerance)?
A: Maintenance macht ein System zwar komplexer, aber in wesentlich geringerem Ausmaß als FaultTolerance. Dadurch sinkt auch die Wahrscheinlichkeit von DesignFaults. ErrorDetection wird benötigt, jedoch kein FaultTreatment auf Systemebene
Allerdings ist Maintenance als Mittel zu Dependability nur möglich, falls SystemDownTimes erlaubt sind (d.h. es handelt sich um ein FailStop- oder FailSafe- System wie z.B. Zugsignale, nicht jedoch um ein FailOperational- System wie z.B. Flugzeug).
Außerdem kann nur begrenzte Reliability erzielt werden. Preventive Maintenance ist nur dann sinnvoll möglich, wenn die auswechselbaren Komponenten konstante oder steigende FailureRates haben und die InfantMortality gut kontrolliert werden kann.

Q: Was ist Replika Determinismus?
A: Definition:
Korrekte Replikate erzeugen korrespondierende ServiceOutputs und/oder ServiceStates unter der Annahme, dass alle Server der Gruppe im gleichen Zustand starten und korrespondierende Service- Requests innerhalb eines gegebenen Zeitintervalls ausführen. Diese Art von Replika- Determinismus wird Replica Control genannt.
Es ist notwendig, dass replizierte Komponenten eines systematisch Faulttoleranten Systems (Fault Tolerance wird unabhängig von Applikationspezifischem Wissen implementiert, also durch Replikation) im fehlerfreien Fall korrespondierende Werte zu korrespondierenden Zeitpunkten liefern, das Verhalten der Komponenten also konsistent ist. Dies ist notwendig, um zwischen fehlerhaftem und korrektem Verhalten unterscheiden zu können.
Mögliche Ursachen für Replika- Nichtdeterminismus:
- unterschiedliches Runden analoger Eingangsgrößen
- unterschiedliche Wahrnehmung der Reihenfolge von Ereignissen durch nicht perfekt synchronisierte lokale Uhren
- unterschiedliche Wahrnehmung der Reihenfolge von Ereignissen durch unterschiedliche Message Transmission Delays
- Inkonsistente Information über die Gruppenmitgliedschaft von Replikationen
- nichtdeterministische Programmkonstrukte (Zufallsgenerator, Konstrukte zur Kommunikation, Synchronisation, etc.)
- Entscheidungen, die auf lokalen Informationen beruhen (z.B. CPULoad, lokale Zeit)
- Unterschiedliche TimeoutEntscheidungen durch ClockDrifts
- Dynamische Scheduling- Entscheidungen
- Unterschiedliche Rundung von Real- Zahlen auf unterschiedlichen Implementierungen
Kann Replika- Nichtdeterminismus nicht verhindert werden, müssen Agreement Protokolle verwendet werden. (Auch diese können das Problem jedoch nicht vollständig lösen)

Q: Was ist Konsistenz?
A: Konsistenz im Allgemeinen bezeichnet die Abwesenheit von Widersprüchen.
Ein Zustand in einem verteilten System wird Konsistent genannt, wenn er
während der Ausführung des Systems existieren könnte.

Q: Was ist Konsistenz bei Replica?
A: Konsistenz ist der Zustand, in dem sich alle korrekten Prozessoren einer Gruppe auf einen Wert geeinigt haben und alle Entscheidungen endgültig sind. (Vorlesungsfolien, part6)
Ein Zustand in einem verteilten System ist konsistent, wenn er ohne das Auftreten von Fehlern existieren könnte.

Q: Was ist / sind Recovery Lines?
A: Eine Menge von RecoveryPoints bildet eine Recovery Line (= ein konsistenter Zustand), wenn er folgende Bedingungen erfüllt:
- Die Menge enthält genau einen RecoveryPoint für jeden Prozess.
- Keine Nachricht wird von Prozess P vor dessen RecoveryPoint empfangen, wenn sie nicht auch vor dessen RecoveryPoint gesendet wurde. (No Orphan Message)
- Keine Nachricht wird von Prozess P vor dessen RecoveryPoint gesendet, wenn sie nicht auch vor dessen RecoveryPoint empfangen wurde. (No lost Message)

Q: Erkläre Sie Consensus Protocols?
A: Wird bei Strictly Distributed Replica Control (alle Replikate sind Gleichwertig) benötigt, um Konsistenz unter den Replikaten zu erzeugen.
Ein Konsens- Protokoll muss folgende Eigenschaften aufweisen:
- Konsistenz: Jeder Knoten muss zur gleichen Entscheidung kommen
- Nicht- Trivialität: Der Wert, auf den sich die Knoten einigen, muss der Eingabewert eines Knoten der Gruppe oder eine Funktion der einzelnen EingabeWerte sein
- Terminierung: Jeder Knoten trifft seine Entscheidung in endlicher Zeit.

Q: Erklären Sie die Gründe für Nicht-Determinismus.
A: Mögliche Ursachen für Replika- Nichtdeterminismus:
- unterschiedliches Runden analoger Eingangsgrößen
- unterschiedliche Wahrnehmung der Reihenfolge von Ereignissen durch nicht perfekt synchronisierte lokale Uhren
- unterschiedliche Wahrnehmung der Reihenfolge von Ereignissen durch unterschiedliche Message Transmission Delays
- Inkonsistente Information über die Gruppenmitgliedschaft von Replikationen
- nichtdeterministische Programmkonstrukte (Zufallsgenerator, Konstrukte zur Kommunikation, Synchronisation, etc.)
- Entscheidungen, die auf lokalen Informationen beruhen (z.B. CPULoad, lokale Zeit)
- Unterschiedliche TimeoutEntscheidungen durch ClockDrifts
- Dynamische Scheduling- Entscheidungen
- Unterschiedliche Rundung von Real- Zahlen auf unterschiedlichen Implementierungen
Kann Replika-Nichtdeterminismus nicht verhindert werden, müssen Agreement Protokolle verwendet werden. (Auch diese können das Problem jedoch nicht vollständig lösen)

Q: Erklären Sie Logical und Real Time Clocks
A: Logical clocks
represent information about causal dependency
- events are time stamped using counters: C(a)
- properties:
– a→b ⇒ C(a)<C(b) monotonicity, consistency
– a→b ⇔ C(a)<C(b) strong consistency
Lamport’s logical clocks
- Logical clocks of processes pi represent the local views of global time
- Ci represents the local clock of pi
- • clock update rules
1. pi increments Ci for each local event
2. each message transports the value of the senders clock Cmsg
3. when pi receives a message with timestamp Cmsg: Ci = max(Ci, Cmsg) and then increments
- consistency is given
- also total ordering of timestamps
- NO strong consistency

Q: Was ist ein FIT? Einheit erklären + Mathematische Definition
A: FIT = Failures in Time
1 FIT = 1 Failure in 10^9 Stunden