Modellierung und Analyse eingebetteter und verteilter Systeme



Ähnliche Dokumente
Mean Time Between Failures (MTBF)

Strukturelle Redundanz

Sicherheit & Zuverlässigkeit

Präsentation DIN-EN 81-1/A1: 2005 DIN-EN 81-2/A1: 2005 (PESSRAL) 15. Juni 2008 VI. Schwelmer Liftsymposium

Ein einfaches Modell zur Fehlerfortpflanzung

Projektmanagement. Vorlesung von Thomas Patzelt 9. Vorlesung

Modellierung verteilter Systeme Grundlagen der Programm und Systementwicklung

SAFEYTEAMS-Newsletter Nr. 5

Life Cycle elektrischer Komponenten

Fassade. Objektbasiertes Strukturmuster. C. Restorff & M. Rohlfing

Qualitätsmanagement im Projekt

zu konzipieren und umzusetzen. Gerne unterstützen wir Sie auch persönlich sprechen Sie uns an.

SDD System Design Document

Anbindung LMS an Siemens S7. Information

Diplomarbeit. Konzeption und Implementierung einer automatisierten Testumgebung. Thomas Wehrspann. 10. Dezember 2008

Zuverlässigkeit und Lebensdauer

Theoretische Grundlagen der Informatik WS 09/10

Senden von strukturierten Berichten über das SFTP Häufig gestellte Fragen

Some Software Engineering Principles

Grundbegriffe der Informatik

1 Informationelle Systeme begriffliche Abgrenzung

Das System für Ihr Mitarbeitergespräche

Systeme 1. Kapitel 6. Nebenläufigkeit und wechselseitiger Ausschluss

Ihre Interessentendatensätze bei inobroker. 1. Interessentendatensätze

Würfelt man dabei je genau 10 - mal eine 1, 2, 3, 4, 5 und 6, so beträgt die Anzahl. der verschiedenen Reihenfolgen, in denen man dies tun kann, 60!.

Testplan. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw,

Statistik I für Betriebswirte Vorlesung 5

Easy-Monitoring Universelle Sensor Kommunikations und Monitoring Plattform

Neuerungen PRIMUS 2014

Fachdidaktik der Informatik Jörg Depner, Kathrin Gaißer

FAQ 04/2015. Auswirkung der ISO auf 3SE53/3SF13 Positionsschalter.

I N F O R M A T I O N V I R T U A L I S I E R U N G. Wir schützen Ihre Unternehmenswerte

Internet Explorer Version 6

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

Tipps und Tricks zu Netop Vision und Vision Pro

DAS VGB REFERENCE DESIGNATION SYSTEM FOR POWER PLANTS RDS-PP

RT Request Tracker. Benutzerhandbuch V2.0. Inhalte

Modellbasierte Software- Entwicklung eingebetteter Systeme

Softwaretests in Visual Studio 2010 Ultimate Vergleich mit Java-Testwerkzeugen. Alexander Schunk Marcel Teuber Henry Trobisch

Fragebogen ISONORM 9241/110-S

Übungen zur Softwaretechnik

TISIS - Industrie 4.0. Ereignis, Ort, Datum

tegos Support 1 Kontakt tegos Support Ticketing System Support Knowledge Database Fehlerklassen Fehlermanagement...

SEP 114. Design by Contract

i x k k=1 i u i x i v i 1 0, ,08 2 0, ,18 3 0, ,36 4 0, ,60 5 1, ,00 2,22 G = n 2 n i=1

6.2 Petri-Netze. kommunizierenden Prozessen in der Realität oder in Rechnern Verhalten von Hardware-Komponenten Geschäftsabläufe Spielpläne

Virtueller Seminarordner Anleitung für die Dozentinnen und Dozenten

Grundlagen der Informatik

Benutzerhandbuch. Leitfaden zur Benutzung der Anwendung für sicheren Dateitransfer.

Ust.-VA ab Release 1.0.0

Lehrpläne NRW Sek.stufe 2. Lernen im Kontext

Referent: Mathias Notheis Kontakt:

Leitfaden zur Nutzung von binder CryptShare

AGROPLUS Buchhaltung. Daten-Server und Sicherheitskopie. Version vom b

Erweiterung AE WWS Lite Win: AES Security Verschlüsselung

VdS Schadenverhütung GmbH. Bereich Security

1 Mathematische Grundlagen

Seite 1 von 14. Cookie-Einstellungen verschiedener Browser

Lineargleichungssysteme: Additions-/ Subtraktionsverfahren

SWT II Projekt. Chat - Anwendung. Pflichtenheft 2000 SWT

Proseminar: Website-Managment-System. NetObjects Fusion. von Christoph Feller

Orderarten im Wertpapierhandel

4. Jeder Knoten hat höchstens zwei Kinder, ein linkes und ein rechtes.

How-to: Webserver NAT. Securepoint Security System Version 2007nx

In diesem Tutorial lernen Sie, wie Sie einen Termin erfassen und verschiedene Einstellungen zu einem Termin vornehmen können.

Man liest sich: POP3/IMAP

H 4135A: Relais im Klemmengehäuse

Softwaretechnologie -Wintersemester 2013/ Dr. Günter Kniesel

Probeklausur. Lenz Belzner. January 26, Lenz Belzner Probeklausur January 26, / 16

How to do? Projekte - Zeiterfassung

4. Die Grundsätze der Dialoggestaltung aus DIN EN ISO

50. Mathematik-Olympiade 2. Stufe (Regionalrunde) Klasse Lösung 10 Punkte

ARAkoll 2013 Dokumentation. Datum:

ProSafe-RS sicherheitsgerichtete Technik

Installationsanleitung. Hardlock Internal PCI Hardlock Server Internal PCI

Installation der SAS Foundation Software auf Windows

4. AUSSAGENLOGIK: SYNTAX. Der Unterschied zwischen Objektsprache und Metasprache lässt sich folgendermaßen charakterisieren:

Erläuterungen zur Untervergabe von Instandhaltungsfunktionen

10 größten SLA Irrtümer. Seminar: 8663 Service-Level-Agreement. Qualified for the Job

Informationsblatt Induktionsbeweis

SQL Server 2008 Standard und Workgroup Edition

Dokumentation. Prüfungen sind zu dokumentieren: elektronische Systeme Prüfplaketten Prüfbücher. DIN VDE Abschn. 6

Primzahlen und RSA-Verschlüsselung

Fachanforderungen für die Abiturprüfung im Fach Elektrotechnik

SQL Server 2005 Standard Edition SQL Server 2005 Enterprise Edition SQL Server 2005 Workgroup Edition

Kommunikations-Management

Funktionale Sicherheit Testing unter

Verwendung des Terminalservers der MUG

Klausur zur Vorlesung Stochastische Modelle in Produktion und Logistik im SS 09

Aufgabe 1 Berechne den Gesamtwiderstand dieses einfachen Netzwerkes. Lösung Innerhalb dieser Schaltung sind alle Widerstände in Reihe geschaltet.

Software Engineering Interaktionsdiagramme

Betriebssysteme K_Kap11C: Diskquota, Raid

Durchführung der Datenübernahme nach Reisekosten 2011

lldeckblatt Einsatzszenarien von SIMATIC Security-Produkten im PCS 7-Umfeld SIMATIC PCS 7 FAQ Mai 2013 Service & Support Answers for industry.

Objektorientierte Programmierung

Dokumentation zum Spielserver der Software Challenge

Inhalt. 1 Einleitung AUTOMATISCHE DATENSICHERUNG AUF EINEN CLOUDSPEICHER

Programmierparadigmen. Programmierparadigmen. Imperatives vs. objektorientiertes Programmieren. Programmierparadigmen. Agenda für heute, 4.

Ein Blick voraus. des Autors von C++: Bjarne Stroustrup Conrad Kobsch

Transkript:

Modellierung und Analyse eingebetteter und verteilter Systeme Thread Zuverlässigkeit Teil 1 Begriffe und Kenngrößen Fehler und Ausfälle Zuverlässigkeitsblockdiagramm Struktur-Funktionsmodell Fehlermodell und Ausbreitung Redundanz Fehlertoleranzverfahren Qualitätssicherung, Analyse und Bewertung Formale Ansätze A X1 Y1 B X2 Y2 Server Down Hardware F OS Fault C Heiko Krumm, RvS, Informatik IV, TU Dortmund 1

F: Funktionaler Thread Inhalte Begriffe und Kenngrößen Fehler und Ausfälle Zuverlässigkeitsblockdiagramm Strukturfunktionsmodell Fehlermodell und Ausbreitung Redundanz Fehlertoleranzverfahren Fehlerdiagnose Fehlerbehandlung Qualitätssicherung, Analyse und Bewertung FMEA HAZOP Fault Trees Formale Ansätze Literatur K. Echtle: Fehlertoleranzverfahren, Springer Verlag, 1990. D. P. Siewiorek, R. S. Swarz: The theory and practice of reliable system design; Digital Press, 1982. Blockley, David: Engineering Safety, Mcgraw Hill, 1992. Leveson, Nancy: Safeware: System Safety and Computers, Addison Wesley, 1995. W. Fredrich: Lehrblattsammlung Zuverlässigkeit und Qualitätssicherung, Uni Rostock, Fakultät Informatik und Elektrotechnik, 2003. Heiko Krumm, RvS, Informatik IV, TU Dortmund 2

RAMSS Eigenschaften Reliability, Availability, Maintainability, Safety, and Security Reliability Zuverlässigkeit: Funktionsfähigkeit in Betriebszeit Availability Verfügbarkeit: Funktionsfähigkeit bei Anforderung Maintainability Instandhaltbarkeit: Dauer für Reparaturen Safety Funktionssicherheit: Gefährdungsfreiheit Security Datensicherheit: Schutz gegen unberechtigten Zugriff Normen DIN VDE 31000, DIN 19250, DIN 19251 MIL - Standards VDI/VDE 2180, VDI/VDE 3541, VDI/VDE 3542 IEC 880, IEC 61508 Heiko Krumm, RvS, Informatik IV, TU Dortmund 3

Funktionssicherheitsgrad Safety Integrity Level (SIL) Wahrscheinlichkeit, dass ein sicherheitsrelevantes System die Sicherheitsanforderungen erfüllt hinsichtlich systematischer Fehler hinsichtlich zufallsbedingter Fehler Tolerable Hazard Rate (THR) Anzahl zu erwartender sicherheitsrelevanter Störungen pro Betriebsstunde und Systemfunktion Sicherheitsanforderungsstufen (SIL-Werte) nach IEC 61508 SIL 4: THR < 10-8 SIL 3: 10-8 < THR < 10-7 SIL 2: 10-7 < THR < 10-6 SIL 1: 10-6 < THR < 10-5 Heiko Krumm, RvS, Informatik IV, TU Dortmund 4

Zuverlässige Systeme: Verfahren A] Produkte ohne besondere Funktionssicherheitsanforderungen (z.b. Komfortfunktionen) Qualitätssicherung, Standards: Fehlervermeidung, Perfektionierung EN 29000 EN 29004 (ISO 9000 ISO 9004) EN 29000 EN 29004 (ISO 9000 ISO 9004) B] Produkte mit besonderen Funktionssicherheitsanforderungen (z.b. Medizingeräte, Verkehrssteuerung, Chemieanlagensteuerung) Zertifizierung (gesetzliche Grundlagen) Produktgestaltung, Bauplan Komponenten und Materialien Produktionsverfahren Analyse Prüfung, Test Bewertung Erfahrungen auswerten, Statistiken, Bauteildatenbanken Heiko Krumm, RvS, Informatik IV, TU Dortmund 5

Zuverlässige Systeme Gestaltung: Fehlertoleranz Fehlererkennung Fehlerausgrenzung Fehlerbehebung Fehlerkompensierung Fehlerdiagnose Fehlerbehandlung Redundanz - Zeit - statisch / dynamisch / hybrid - Struktur (e.g. hot / cold standby) - Funktion - ungenutzt, fremdgenutzt, gegenseitig - Information Heiko Krumm, RvS, Informatik IV, TU Dortmund 6

Z1: Begriffe Komponente Ausfall Fehler Reparatur t Zuverlässigkeit Reliability Fähigkeit einer Komponente ihre Funktion über eine bestimmte Betriebszeit in korrekter Weise zu erfüllen Ausfall Failure Ereignis / Zustandsübergang von funktionsfähig nach fehlerhaft Fehler Fault Zustand des Nichterfüllens einer Anforderung Funktionssicherheit Safety Zuverlässigkeit hinsichtlich sicherheitsrelevanter Funktionen: - sicherheitsrelevante Ausfälle und Fehler Heiko Krumm, RvS, Informatik IV, TU Dortmund 7

Z1: Systemzustände aus K. Echtle: Fehlertoleranzverfahren, Springer Verlag, 1990. Heiko Krumm, RvS, Informatik IV, TU Dortmund 8

Z1: Systemzustände L i : Lebensdauer B i : Fehlerbehandlungsdauer D i : Sicherheitsdauer aus K. Echtle: Fehlertoleranzverfahren, Springer Verlag, 1990. Heiko Krumm, RvS, Informatik IV, TU Dortmund 9

Z1: Zuverlässigkeitskenngrößen Fehlerwahrscheinlichkeit F L (t) Dichte f L (t) Wahrscheinlichkeit, dass ein zu Beginn fehlerfreies System im Zeitintervall [0,t] fehlerhaft wird Überlebenswahrscheinlichkeit R(t) Wahrscheinlichkeit, dass ein fehlerfreies System im Zeitintervall [0,t] ununterbrochen fehlerfrei ist Mittlere Lebensdauer E(L) Erwartungswert der Zeitdauer bis zum ersten Fehler Ausfallrate λ(t) Anzahl der in einer Zeiteinheit ausfallenden Komponenten λ(t) = f L (t) / R(t) Heiko Krumm, RvS, Informatik IV, TU Dortmund 10

Z1: Beispiel Mensch Heiko Krumm, RvS, Informatik IV, TU Dortmund aus W. Fredrich: Zuverlässigkeit und Qualitätssicherung, Uni Rostock, 2003 11

Z1: Beispiel Mensch Heiko Krumm, RvS, Informatik IV, TU Dortmund aus W. Fredrich: Zuverlässigkeit und Qualitätssicherung, Uni Rostock, 2003 12

Z1: Beispiel Mensch Heiko Krumm, RvS, Informatik IV, TU Dortmund aus W. Fredrich: Zuverlässigkeit und Qualitätssicherung, Uni Rostock, 2003 13

Z1: Beispiel Mensch Heiko Krumm, RvS, Informatik IV, TU Dortmund aus W. Fredrich: Zuverlässigkeit und Qualitätssicherung, Uni Rostock, 2003 14

Z1: Zuverlässigkeitskenngrößen Ausfallrate λ(t) Anzahl der in einer Zeiteinheit ausfallenden Komponenten λ(t) = f L (t) / R(t) Badewannen-Kurve λ(t) Frühausfälle Zufallsausfälle Spätausfälle Betriebszeit t Heiko Krumm, RvS, Informatik IV, TU Dortmund 15

Z1: Zuverlässigkeitskenngrößen Verfügbarkeit V Wahrscheinlichkeit, ein System zu einem beliebigen Zeitpunkt fehlerfrei anzutreffen Mean Time Between Failures MTBF Reziproker Wert der Ausfallrate, mittlere Zeit zwischen zwei Fehlern, mittlere ausfallfreie Betriebszeit MTBF = 1/z gesamt Mean Time To Repair MTTR mittlere Zeit zur Reparatur nach Fehler E(L), E(B) Erwartungswerte für die Nutzzeitdauer L und die Defektzeitdauer B Mittlere Verfügbarkeit V Wahrscheinlichkeit, dass das System funktionsfähig ist V = MTBF / (MTBF + MTTR) Heiko Krumm, RvS, Informatik IV, TU Dortmund 16

Z1: Zuverlässigkeitskenngrößen Gefährdungswahrscheinlichkeit F D (t) Wahrscheinlichkeit, dass ein System im Zeitintervall [0, t] in einen Gefahrenzustand gerät Sicherheitswahrscheinlichkeit S(t) Wahrscheinlichkeit, das sich ein System im Zeitintervall [0, t] ununterbrochen in sicheren Zuständen befindet Mittlere Sicherheitsdauer E(D) Erwartungswert der Zeitdauer, bis ein unsicherer Zustand auftritt Heiko Krumm, RvS, Informatik IV, TU Dortmund 17

Z1: Zuverlässigkeit von Bauteilen Beanspruchungen erhöhen die Ausfallrate - Temperatur und Temperaturwechsel bei allen elektrotechnischen Bauteilen - Spannung bei Kondensatoren - Verlustleistung bei Halbleiterbauelementen, Widerständen, Transformatoren - Strom bei Kontaktstellen, Leitungen, Dioden - Beschleunigung bei Röhren, Leitungsverbindungen - Atmosphäre bei Kontaktstellen - Elektrische Feldstärke bei Halbleiter Bauelementen (insb. MOS Bauelemente) Weitere Einflüsse - geschützter Transport (richtige Verpackung) - richtige und zeitbegrenzte Lagerung - konstruktive Ausführung - Materialeinsatz (Materialkombinationen) - Klima, Feuchte, Korrosion - mechanische und dynamische Beanspruchung - elektrische Belastung Heiko Krumm, RvS, Informatik IV, TU Dortmund aus W. Fredrich: Zuverlässigkeit und Qualitätssicherung, Uni Rostock, 2003 18

Z1: Zuverlässigkeit von Bauteilen Relative Häufigkeit der Ausfallarten elektronischer Halbleiterbauelemente Bauelement Kurzschluss Unterbr. Drift Fehler Digitale bipolare IC`s 30% 30% 10% 30% Digitale MOS IC s 20% 10% 30% 40% Lineare IC s 30% 10% 10% 50%* Bipolare Transistoren 70% 20% 10% ------- Feldeffekt-Transistoren 80% 10% 10% ------- Mehrzweck-Dioden 70% 30% ------- ------- Zener-Dioden 60% 30% 10% ------- Hochfrequenz-Dioden 80% 20% ------- ------- Thyristoren 20% 20% 60% ------- Optoelektr.Bauelemente 10% 50% 40% ------- *: Überlast Heiko Krumm, RvS, Informatik IV, TU Dortmund aus W. Fredrich: Zuverlässigkeit und Qualitätssicherung, Uni Rostock, 2003 19

Z1: Zuverlässigkeit von Bauteilen Relative Häufigkeit der Ausfallarten passiver elektronischer Bauelemente Bauelement Kurzschluss Unterbr. Drift Fehler Festwiderstände ------- 90% 10% ------- Variable Widerstände ------- 60% 20% 20%** Folienkondensatoren 80% 10% 10% ------- Metallfolienkondensatoren 40% 60% ------- ------- Keramikkondensatoren 50% 40% 10% ------- Tantalkondensatoren 60% 20% 20% ------- Aluminiumelektrolytkond. 20% 10% 70% ------- Spulen 10% 30% -------- 60%*** Relais 15% 15% -------- 70% Schwingquarze -------- 80% 20% ------- **: Verschleiß, ***: Isolation Heiko Krumm, RvS, Informatik IV, TU Dortmund aus W. Fredrich: Zuverlässigkeit und Qualitätssicherung, Uni Rostock, 2003 20

Z1: Zuverlässigkeit von Bauteilen Ausfallrate von elektronischen Bauteilen in Abhängigkeit von der Temperatur und Belastung Heiko Krumm, RvS, Informatik IV, TU Dortmund aus W. Fredrich: Zuverlässigkeit und Qualitätssicherung, Uni Rostock, 2003 21

Z1: Zuverlässigkeit von Bauteilen Ausfallrate von elektronischen Bauteilen in Abhängigkeit von der Temperatur und Belastung Heiko Krumm, RvS, Informatik IV, TU Dortmund aus W. Fredrich: Zuverlässigkeit und Qualitätssicherung, Uni Rostock, 2003 22

Z1: Zuverlässigkeit von Bauteilen Ausfallrate von elektronischen Bauteilen in Abhängigkeit von der Temperatur und Belastung Heiko Krumm, RvS, Informatik IV, TU Dortmund aus W. Fredrich: Zuverlässigkeit und Qualitätssicherung, Uni Rostock, 2003 23

Z1: Zuverlässigkeit von Bauteilen Ausfallrate von elektronischen Bauteilen in Abhängigkeit von der Temperatur und Belastung Heiko Krumm, RvS, Informatik IV, TU Dortmund aus W. Fredrich: Zuverlässigkeit und Qualitätssicherung, Uni Rostock, 2003 24

Z2: Fehler und Ausfälle Fehler Fehlzustände Funktionsausfälle Anforderungsdefinition V-Modell Abnahmetest Fehlerursachen Entwurfsfehler Spezifikation Implementierung Dokumentation Herstellungsfehler Betriebsfehler Störungen Verschleiß Zufall Bedienung Wartung Absichtliche Eingriffe Grob- Entwurf Fein- Entwurf Modul- Spezifikation Programmierung, Implementierung Modultest Integrationstest Systemtest Heiko Krumm, RvS, Informatik IV, TU Dortmund 25

Z2: Fehler und Ausfälle Fehler Hardware Fehler Software Fehler Zeitverlauf Intermittierende Fehler Permanente Fehler Beispiel: Sporadische Computerfehler SEUs (Single Event Upsets) / Soft Errors Hauptursache: Höhenstrahlen Höhenstrahlpartikel bringen punktuell Energie in eine mikroelektronische Struktur so ein, dass sich ein dort vorhandener binärer Zustand verändert Einheit FIT (Failures In Time) 1 FIT: im Mittel 1 Fehler pro 10 9 Stunden Speicherfehler (Bit kippt) Einheit FIT pro Megabit typisch: 1.000 bis 5.000 FIT pro Megabit RAM-Speicher Heiko Krumm, RvS, Informatik IV, TU Dortmund 26

Z2: Fehler und Ausfälle Beispiele Fehlerhafte Ausgabe Fehlende Ausgabe, Stop Herstellungsfehler: Exemplarstreuung Herstellungsfehler: Compilerfehler Leitungsbruch Leitungsstörung Nachrichtenverlust Nachrichtenverfälschung Nachrichten-Fehlleitung Nachrichten-Duplizierung Entwurfsfehler, Spezifikationsfehler Programmierfehler Dokumentationsfehler Hardwareentwurfsfehler Chip-Fehlstelle Chip-Leitungsschluss Chip-Leitungsunterbrechunng Sabotage (kein Fehler im engeren Sinn) Äußere Einflüsse mechanisch elektrisch thermisch Strahlung magnetisch elektromagnetisch Plattencrash Verschleißfehler Alterung Gebläse-Ausfall, Überhitzung Wartungsfehler Kaputtreparatur (HW u. SW) Fehlbedienung Heiko Krumm, RvS, Informatik IV, TU Dortmund 27

Z2: Fehler und Ausfälle Fehlerorte Fehler und Ausfälle Ausfall: Ereignis, Zustandsübergang Fehler: Systemzustand Fehler ohne Ausfall? Ja: Latenter Fehler Latenzdauer = Zeit bis zum Ausfall Ausfall ohne Fehler? nicht möglich Orte Anwendungssoftware Middleware Betriebssystem Kommunikationssystem Hardware Peripherie Heiko Krumm, RvS, Informatik IV, TU Dortmund 28

Z3: Zuverlässigkeitsblockdiagramm Knoten: Komponente Kanten: Anordnung von Komponenten, parallel und in Serie, entsprechend Beitrag zur gewünschten Systemfunktion K1 K2 K1 K2 Parallelschaltung wenn beide Komponenten unabhängig ausfallen: p(ausfall ges ) = p(ausfall K1 ) * p(ausfall K2 ) Serienschaltung wenn beide Komponenten unabhängig ausfallen: p(funktion ges ) = p(funktion K1 ) * p(funktion K2 ) Heiko Krumm, RvS, Informatik IV, TU Dortmund 29

Z3: Zuverlässigkeitsblockdiagramm Komplexere Strukturen K1 K2 K3 Serien-Parallelschaltung K2 kommt zweimal vor! K1 K2 K3 K4 K5 K2 Mehrfach vorkommende Komponenten Heiko Krumm, RvS, Informatik IV, TU Dortmund 30

Z3: Zuverlässigkeitsblockdiagramm Komplexere Strukturen K1 K2 Redundanz 1-aus-2 K1 Kn k Kn Redundanz k-aus-n K1 K2 K3 2 K4 Redundanz 2-aus-3 mit Entscheider K4 Heiko Krumm, RvS, Informatik IV, TU Dortmund 31

Z4: Struktur Funktionsmodell nicht-formal: Adressat Mensch abstrakte System Sicht Verständnis der Systemzusammenhänge Struktur des Systems Funktionen des Systems und Zuordnung Abhängigkeiten Bereiche der Fehlerentstehung Bereiche der Fehlerausbreitung Wirkung der eingesetzten Fehlertoleranz-Verfahren Heiko Krumm, RvS, Informatik IV, TU Dortmund 32

Z4: Struktur Funktionsmodell: Graph Knoten: Komponenten K1 Kanten (gerichtet): Funktionen sowie Zuordnungen zu Erbringer und Nutzer K2 erbringt F1 für K1 und F2 für K3 K3 erbringt F3 für K1 F2 F1 K1 K2 K3 F3 Prinzip: Funktionsausfall geht immer auf Fehlzustand der erbringenden Komponente zurück Heiko Krumm, RvS, Informatik IV, TU Dortmund 33

Z4: Struktur Funktionsmodell Zusätzlich: Strukturierung in Subsysteme möglich A] Als Komponenten-Sammlungen Subsystem U System S B] Als zusammenfassende Abstraktion der inneren Komponenten Subsystem U System S Heiko Krumm, RvS, Informatik IV, TU Dortmund 34

Z4: Struktur Funktionsmodell B] Als zusammenfassende Abstraktion der inneren Komponenten f1 f2 f3 Subsystem U F1 F2 System S Innere Spezifikation eines Subsystems: Komponentenstruktur und interne Funktionszuordnungen Äußere Spezifikation eines Subsystems: an den Subsystemgrenzen von außen benötigten sowie die nach außen erbrachten Funktionen Heiko Krumm, RvS, Informatik IV, TU Dortmund 35

Z4: Struktur Funktionsmodell C] Weitere Strukturierungen Überlappende Subsysteme Komplexes ist komplex aber, Abstraktion und Übersicht sind nötig Heiko Krumm, RvS, Informatik IV, TU Dortmund 36

Z4: Struktur Funktionsmodell K1 erbringt Funktion F1 für K2 K1 ist Bestandteil von K2 K1 stellt K2 Betriebsmittel zur Verfügung K1 kann von K2 aufgerufen werden K1 bietet K2 einen Dienst an K1 F1 K2 Statische und dynamische Systemstrukturen Komponenten erzeugen und vernichten Komponenten (Dienste) suchen, binden und freigeben Unterschiedliche Komponenten--Arten Software-Prozess, Software-Modul, Software-Funktion, Services und Operationen Betriebssystem, Betriebssystem-Komponente Hardware, Hardware-Komponente, Prozessor-Zeitscheibe, permanenter Speicher Heiko Krumm, RvS, Informatik IV, TU Dortmund 37

Z4: Struktur Funktionsmodell Beispiel aus K. Echtle: Fehlertoleranzverfahren Hardware HW = {R1, KM, R2}, Software SW = {K1, K2, KS1, KS2} Anwendungssoftware AS = {K1, K2} Kommunikationssyst em KS = {KS1, KM, KS2} Erste Ablaufeinheit AE1 = {K1, KS1, R1} Zweite Ablaufeinheit AE2 = {K2, KS2, R2}. Heiko Krumm, RvS, Informatik IV, TU Dortmund 38

Z4: Struktur Funktionsmodell: Schichtenmodell Schicht Halbordnung zwischen den Schichten Subsystem Funktionszuordnungen innerhalb von Schichten sowie nur von niedrigeren an höhere Schichten Beispiel aus K. Echtle: Fehlertoleranzverfahren Heiko Krumm, RvS, Informatik IV, TU Dortmund 39

Beispiel aus K. Echtle: Fehlertoleranzverfahren Zwei- Rechner- System Heiko Krumm, RvS, Informatik IV, TU Dortmund 40

Beispiel aus K. Echtle: Fehlertoleranzverfahren Zwei- Rechner- System Heiko Krumm, RvS, Informatik IV, TU Dortmund 41

Z4: Struktur Funktionsmodell: Spezielle Komponentenarten Replikate Vervielfältigte Komponenten mit gleicher Funktion Replizierte Komponente Exemplar z.b. P 1, P 2, P 3 (hochgestellte Indizes) als die drei Prozessexemplare eines 2-von-3-Systems Replikate mit veränderter Implementierung diversitäre Exemplare oder Varianten e P1 P2 P3 f f f V f Komponentenmengen aus ungleichen Komponenten Module z.b. Modul aus Funktions-, Umkehrfunktionsund Vergleichskomponente zur Fehlerdiagnose e T P 1 f c f -1 P 2 f Heiko Krumm, RvS, Informatik IV, TU Dortmund 42

Z5: Fehlermodell und Ausbreitung: Fehlermodell Spezifikation der Fehlertoleranz-Fähigkeit eines Systems benötigt: Fehlervorgabe Menge der zu tolerierenden Fehler (bezogen auf ein formales Fehlermodell) Fehlermodell definiert die betrachteten Fehlermöglichkeiten eines Systems als Obermenge der Menge der zu tolerierenden Fehler muss die von einem Fehler betroffenen Komponenten nennen (Ort: strukturelle Fehlerbetrachtung) muss angeben, in welcher Weise deren Funktion beeinträchtigt wird (Art: funktionelle Fehlerbetrachtung) Komponentenbezogenes strukturelles Fehlermodell unterscheidet häufig für jede Komponente nur "fehlerfrei" von "fehlerhaft : Binäres Fehlermodell System S, Fehlermodell FS als Funktion FS: {K : K ist Komponente des Systems S} x Zeit {fehlerfrei, fehlerhaft} Heiko Krumm, RvS, Informatik IV, TU Dortmund 43

Z5: Fehlermodell und Ausbreitung: Fehlerbereiche Annahme, dass zu tolerierende Fehler nur in bestimmten Komponentenmengen auftreten. Fehlerbereich Komponentenmenge einer zugeordneten Fehlermenge Fehlerbereichs-Annahme Zuordnung der zu tolerierenden Fehler zu Fehlerbereichen ein Fehler f bleibt stets auf die von f zugeordnete Komponentenmenge beschränkt, z. B. weil Fehler in den einzelnen Fehlerbereichen unabhängig voneinander entstehen und sich nicht auf weitere Komponentenmengen ausbreiten Fehlerfall Aussage, in welchem der Fehlerbereiche aktuell Fehler aufgetreten sind Grundannahme Kein Fehlerbereich umfasst das gesamte System (Andernfalls könnten sich Fehler auf sämtliche Komponenten auswirken und man könnte sie nicht tolerieren). Heiko Krumm, RvS, Informatik IV, TU Dortmund 44

Z5: Fehlermodell und Ausbreitung: Fehlerbereiche Fehlerbereiche sind nicht unbedingt disjunkte vollständige Zerlegung Überschneidende Bereiche K, i, j: K FB i K FB j Perfektionskern FB 1 FB 2.. FB n S Perfektionskern = S \ (FB 1 FB 2.. FB n ) Einzelfehlerbereiche Größeres System mit höherer Anzahl von zu tolerierenden Fehlern Fehlerbereiche müssen alle Kombinationen von zulässigen "Fehlerstellen" beschreiben Viele Kombinationsmöglichkeiten Stattdessen disjunkte Zerlegung der Vereinigung aller Fehlerbereiche in Einzelfehlerbereiche Jede maximal große Komponentenmenge, bei der alle Komponenten zu genau den gleichen Fehlerbereichen gehören, ist Einzelfehlerbereich Heiko Krumm, RvS, Informatik IV, TU Dortmund 45

Z5: Fehlermodell und Ausbreitung: Einzelfehlerbereiche Beispiel: 3-Rechner-System Prozesse P1, P2, P3, P4 und P5, die Lokale Betriebssysteme BS1, BS2 und BS3 Rechnerhardware R1, R2 und R3 Bereichsgliederung einander zugeordnete Hardware und Software sind wegen der Ausbreitung von Hardwarefehlern auf die Software zusammengefasst auch ohne Hardwarefehler kann es Softwarefehler in P2, P3 und P4 geben Menge der zu tolerierenden Fehler, formuliert anhand der Fehlerbereiche: Fb = {Fb1, Fb2, Fb3, Fb4} = {{P1, P2, BS1, R1}, {P3, P4, BS2, R2}, {P5, BS3, R3}, {P2, P3, P4}} Daraus resultierende Einzelfehlerbereiche Eb = {Eb1, Eb2, Eb3, Eb4, Eb5} = {{P1, BS1, R1}, {BS2, R2}, {P5, BS3, R3}, {P2}, {P3, P4}}. Beispiel aus K. Echtle: Fehlertoleranzverfahren Heiko Krumm, RvS, Informatik IV, TU Dortmund 46

Z5: Fehlermodell und Ausbreitung: Einzelfehlerbereiche 3-Rechner-System dick umrandet: Fehlerbereiche - R: Hardware dünn umrandet: Einzelfehlerbereiche - BS: Betriebssystem - P: Anwendungsprozesse Beispiel aus K. Echtle: Fehlertoleranzverfahren Heiko Krumm, RvS, Informatik IV, TU Dortmund 47

Z5: Fehlermodell und Ausbreitung: k-fehlerannahme Zur Vereinfachung bei großer Zahl von Fehlerbereichen als Spezialfall der Fehlerbereichs-Annahme: k-fehler-annahme mit Zeitredundanz t R und Mindestanzahl n Disjunkte Zerlegung eines Systems S in Einzelfehlerbereiche Eb 1,..., Eb e (mit Eb 1 Eb e = S) k-fehler-annahme Forderung alle Fehler zu tolerieren, die sich auf bis zu k Einzelfehlerbereiche erstrecken Zeitredundanz t R Zu jedem Zeitpunkt dürfen höchstens k Einzelfehlerbereiche Fehler aufweisen oder in der durch t R begrenzten Vergangenheit fehlerhaft gewesen sein Mindestanzahl n Bei permanenten Fehlern können im Zuge der Fehlerbehandlung Komponentenmengen ausgegliedert werden. Die Fähigkeit, trotz zuvor aufgetretener und erfolgreich behandelter Fehler weitere zu tolerieren, wird solange gefordert, wie noch eine Mindestanzahl n an Einzelfehlerbereichen im System S vorhanden sind Heiko Krumm, RvS, Informatik IV, TU Dortmund 48

Z5: Fehlermodell und Ausbreitung: k-fehlerannahme Zur Vereinfachung bei großer Zahl von Fehlerbereichen als Spezialfall der Fehlerbereichs-Annahme: k-fehler-annahme mit Zeitredundanz t R und Mindestanzahl n Disjunkte Zerlegung eines Systems S in Einzelfehlerbereiche Eb 1,..., Eb e (mit Eb 1 Eb e = S) Die k-fehler-annahme läßt sich auf die Fehlerbereichs-Annahme zurückführen, indem jede Vereinigungsmenge beliebiger k Einzelfehlerbereiche als eigener Fehlerbereich definiert wird: Fb = {Eb i1 Eb ik : i 1,..., i k {1,..., e} } Kombinatorik: Aus e Einzelfehlerbereichen entstehen e k Fehlerbereiche Heiko Krumm, RvS, Informatik IV, TU Dortmund 49

Beispiel: 4-Rechner-System mit 2-Fehler- Annahme Einzelfehlerbereiche und Fehlerbereiche: Alle 6 Kombinationen von je 2 Einzelfehlerbereichen sind zu je einem Fehlerbereich zusammengefasst. Heiko Krumm, RvS, Informatik IV, TU Dortmund Beispiel aus K. Echtle: Fehlertoleranzverfahren 50

Z5: Fehlermodell und Ausbreitung: Fehlfunktionsannahme Eine zusätzlich zur Fehlerbereichs-Annahme getroffene Fehlfunktions- Annahme, dient der Detaillierung der Fehlervorgabe bestimmte Fehlermöglichkeiten sind u.u. allzu unwahrscheinlich Fehler, die nur mit allzu hohem Aufwand zu tolerieren wären, werden aus der Fehlervorgabe ausgenommen Beispiele Teilausfall (bestimmte Teilfunktionen fallen aus) Unterlassungsausfall (eine Operation wird insgesamt nicht ausgeführt) Anhalte-Ausfall (die Komponente stoppt) Haft-Ausfall (die Komponente gibt immer dasselbe aus) Inkonsistenz-Ausfall (durch Plausibilitätstest erkennbarer Ausfall) k-binärstellen-ausfall (maximal k-stellen sind verfälscht) Heiko Krumm, RvS, Informatik IV, TU Dortmund 51

Z5: Fehlermodell und Ausbreitung: Fehlerausbreitung K1 F1 K2 F2 K3 Fehler können sich über Funktionen ausbreiten Wenn z.b. K1 ausfällt ist, kann F1 fehlerhaft sein und K1 ausfallen, so dass F2 fehlerhaft wird und K3 ausfällt Fehler können weiterhin über sich zusätzliche Wege ausbreiten Leitungen sprechen über Ein Prozess greift aufgrund eines Programmierfehlers in den Adressraum eines anderen Prozesses Zwei Hardware-Module sind räumlich so eng benachbart, dass eine Überhitzung des einen Moduls auch zur Überhitzung des anderen führt Darstellung im Struktur-Funktionsmodell Pseudofunktionen» z.b. eng benachbart, Übersprechen, Adressraum-Übergriff, etc. Heiko Krumm, RvS, Informatik IV, TU Dortmund 52

Z5: Fehlermodell und Ausbreitung: Fehlerausbreitung Funktionen Pseudofunktionen Beispiel aus K. Echtle: Fehlertoleranzverfahren Heiko Krumm, RvS, Informatik IV, TU Dortmund 53

Beispiel eines Schichtenmodells mit Pseudofunktionen zur Darstellung der vertikalen Fehlerausbreitung oberer Teil Heiko Krumm, RvS, Informatik IV, TU Dortmund Beispiel aus K. Echtle: Fehlertoleranzverfahren 54

Beispiel eines Schichtenmodells mit Pseudofunktionen zur Darstellung der vertikalen Fehlerausbreitung, unterer Teil Heiko Krumm, RvS, Informatik IV, TU Dortmund Beispiel aus K. Echtle: Fehlertoleranzverfahren 55

Z5: Fehlermodell und Ausbreitung: Fehlerausbreitung Zeit Fehler breiten sich häufig nicht sofort aus Programmierfehler wirkt sich erst aus, wenn fehlerhaftes Programmstück ausgeführt wird Dateiverfälschung wirkt sich erst aus, wenn die Datei gelesen wird Fehlerlatenzdauer d(p,q) zwischen P und Q Zeitdauer, bis Fehler in K1 zu Fehler in K2 führt Fehlertypen ein permanenter Fehler in einem Programm K1 kann zu einem intermittierenden Fehler in einem Prozess K2 führen kurzfristige Überhitzung (ein intermittierender Fehler) kann zu einer permanenten Störung einer Hardwarekomponente führen Q P B U Prozess Q permanent fehlerhaft Prozedur P intermittierend fehlerhaft Baustein B permanent fehlerhaft Umgebung U intermittierend fehlerhaft Heiko Krumm, RvS, Informatik IV, TU Dortmund 56

Z5: Fehlermodell und Ausbreitung: Fehlereingrenzung Fehler können sich über viele Wege ausbreiten umfassende Fehlerbereiche Fehlertoleranz schwer realisierbar Fehlerbereich Fehlerbereich Fehlereingrenzung wenige Funktionszuordnungen im System Maßnahmen zur Isolation zwischen Komponenten Isolation» Hardware-Schutzmaßnahmen (Adressraum-Überwachung)» Fehlerkorrektur (z.b. ECC-Speicher, z.b. wiederholtes Lesen)» Plausibilitätskontrollen» Selbstdiagnose und Abschalten (Einnahme eines sicheren Fehlerzustands)» Einkapselung, Interaktionen nur über enge Schnittstellen Heiko Krumm, RvS, Informatik IV, TU Dortmund 57

Z5: Fehlermodell und Ausbreitung: Fehlereingrenzung Vertikale Eingrenzung in Hardware HW-Fehlerkorrektur verhindert Ausbreitung zu SW Zugriffskontrolle verhindert Fehlerausbreitung von SW auf HW Vertikale Fehlereingrenzung in Software Syntax- und Konsistenzprüfungen Modularität (Einkapselung) unteilbare Aktionen, Transaktionen Horizontale Fehlereingrenzung in der Hardware und in tieferen Schichten des Betriebssystems Modularität (Einkapselung) Horizontale Fehlereingrenzung bei Interaktionen in der Software Syntax- und Konsistenzprüfungen im verteilten System: Nachrichtenaustausch Nachrichtenfehler Heiko Krumm, RvS, Informatik IV, TU Dortmund 58

Z5: Fehlermodell und Ausbreitung: Fehlereingrenzung Nachrichtenfehler und horizontale Fehlereingrenzung Verfälschung des Nachrichteninhalts beim Transfer Blockprüfzeichen bzw. Signatur zur Fehlererkennung, negative Quittung und Wiederholung Nachrichtenverlust Timeout bei ausbleibender Quittung, Wiederholung Nachrichtenvervielfältigung Sequenzzahlen, Duplikaterkennung und Ignorieren Reihenfolgevertauschungen Sequenzzahlen und Sortieren Spontanes Absenden unerwarteter fehlerhafter Nachrichten Empfänger prüft Nachricht und Kontext, ignoriert oder weist zurück Verbindungsverlust Timeout-Anzahl-Überwachung, Wahl alternativer Wege Sender erzeugt Nachricht mit fehlerhaftem Inhalt aber gutem Blockprüfzeichen Kontextprüfung beim Empfänger (häufig nicht möglich) Verfälschung so, dass Blockprüfzeichen stimmt häufig nicht erkennbar und eingrenzbar Heiko Krumm, RvS, Informatik IV, TU Dortmund 59

Z6: Redundanz Überfluss Mittel, welche für die eigentliche Systemfunktion nicht erforderlich sind Basis der Fehlertoleranzmechanismen Art Zeit Struktur Funktion Information Aktivierung statisch, dynamisch, hybrid ungenutzt, fremdgenutzt, gegenseitig genutzt Art strukturell funktionell Diversität Redundanz statisch Aktivierung hybrid ungenutzt dynamisch Zeitredundanz Informationsredundanz Zusatzfunktion fremdgenutzt gegenseitig Heiko Krumm, RvS, Informatik IV, TU Dortmund 60

Z6: Redundanz Strukturelle Redundanz Erweiterung eines Systems um zusätzliche (gleich- oder andersartige), für den Nutzbetrieb entbehrliche Komponenten Mehrrechnersystem Datei-Replikate RAID-Plattenarrays Diagnosekomponente Heiko Krumm, RvS, Informatik IV, TU Dortmund 61

Z6: Redundanz Funktionelle Redundanz Erweiterung eines Systems um zusätzliche für den Nutzbetrieb entbehrliche Funktionen Zusatzfunktionen» Testfunktionen» Funktionen zur Verwaltung von Toleranzmechanismen» Parity-Erzeugung» Rekonfigurationsfunktion Diversität» n-versionsprogramme unabhängiger Entwurf gegensätzlicher Entwurf Heiko Krumm, RvS, Informatik IV, TU Dortmund 62

Z6: Redundanz Informationsredundanz zusätzliche Information neben der Nutzinformation fehlererkennende Codes fehlerkorrigierende Codes Nachrichtenwiederholungen Quersummen, Signaturen Doppelverzeigerung Heiko Krumm, RvS, Informatik IV, TU Dortmund 63

Z6: Redundanz Zeitredundanz bezeichnet über den Zeitbedarf des Normalbetriebs hinausgehende zusätzliche Zeit, die für Fehlertoleranzmechanismen zur Verfügung steht Zeit, um die wiederholte Nachricht zu verarbeiten Zeit, um die Rekonfiguration durchzuführen Zeit, um die Prüfsumme zu berechnen Heiko Krumm, RvS, Informatik IV, TU Dortmund 64

Z7: Fehlerdiagnose Liegt in einem Fehlerbereich ein Fehler vor? Fehlertest möglichst hohe Testgüte Testgüte Fehlererfassung C F = p(df 1 DF n ) / p(df 1 DF n NF 1 NF m ) DF i : richtig als Fehler diagnostizierte Fälle NF i : fälschlich als richtig diagnostizierte Fehler (false positive) Richtigerfassung C R = p(dr 1 DR n ) / p(dr 1 DR n NR 1 NR m ) DR i : richtig diagnostizierte fehlerfreie Fälle NR i : fälschlich als Fehler diagnostizierte fehlerfreie Fälle (false negative) Heiko Krumm, RvS, Informatik IV, TU Dortmund 65

Z7: Fehlerdiagnose Testzwecke Fehlererkennung Sind die Komponenten fehlerfrei? Fehlerlokalisierung Welche Komponenten sind fehlerfrei? Übrige sind u.u. fehlerhaft. Genauigkeit» Möglichkeiten zur Fehlererfassung» Anforderungen der gewünschten Ausgrenzungsmaßnahmen» Aufwand Lokalisierungsbereich Lb i» Komponentenmenge Lb i» Test sagt für einen (vergangenen) Zeitpunkt t aus, ob alle Komponenten aus Lb i fehlerfrei waren oder Fehler aus der Menge der zu tolerierenden Fehler aufgetreten sind ( x Lb i, t Zeit: FS (x, t) = fehlerhaft). Heiko Krumm, RvS, Informatik IV, TU Dortmund 66

Z7: Fehlerdiagnose Lokalisierungsbereich Lokalisierungsbereiche LB i müssen alle Fehlerbereiche FB i überdecken Behandlungsbereich Komponentenmenge Bb i, bei welcher ein Fehlerbehandlungs- Verfahren auf alle Komponenten x Bb i stets die gleiche Operation anwendet Behandlungsbereiche Bb i müssen alle Fehlerbereiche FB i überdecken Heiko Krumm, RvS, Informatik IV, TU Dortmund 67

Z7: Fehlerdiagnose Sinnvolle Einschränkungen Jeder Behandlungsbereich ist Teilmenge eines Fehlerbereichs Fehlerbehandlung auf nicht zu viele Komponenten anwenden Jeder Lokalisierungsbereich ist im Komplement des Perfektionskerns Teilmenge eines Behandlungsbereichs Entscheidung in welchem Behandlungsbereich Fehler bearbeitet wird Behandlungsbereiche sollen möglichst wenig Komponenten des Perfektionskerns enthalten Behandlung verursacht unnötigen Aufwand Jeder Behandlungsbereich soll in einem Einzelfehlerbereich enthalten sein Zielgerichtete Behandlung Jeder Lokalisierungsbereich umfasst einen Behandlungsbereich nicht genauer lokalisieren als behandelt werden kann Einfachster Fall Jedem Einzelfehlerbereich entspricht genau ein Lokalisierungs- und ein Behandlungsbereich Heiko Krumm, RvS, Informatik IV, TU Dortmund 68

Z7: Fehlerdiagnose Komponenten K i Fehlerbereiche Fb i Einzelfehlerbereiche Eb i Lokalisierungsbereiche Lb i Behandlungsbereichen Bb i Komponente K 4 im Perfektionskern Beispiel aus K. Echtle: Fehlertoleranzverfahren Der Behandlungsbereich Bb 4 wird durch zwei Lokalisierungsbereiche Lb 4 und Lb 5 gemeinsam abgedeckt (sie lokalisieren genauer als behandelt werden kann). Im Einzelfehlerbereich Eb 4 ruft der Lokalisierungsbereich Lb 3 bei Fehlermeldung eine Behandlung in Bb 3 und Bb 5 hervor, wobei Bb 5 auch eine Komponente des Perfektionskerns enthält Heiko Krumm, RvS, Informatik IV, TU Dortmund 69

Z7: Fehlerdiagnose Testmethoden Normalbetrieb: Fehlererkennung Häufig Folgefehler-Erkennung, z.b. Adressraumüberschreitung Zeitüberschreitung Zugriffsrechtverletzung Ausnahmebetrieb: Fehlerlokalisierung Testmodus mit speziellen Testdaten und dafür spezifiziertem Soll-Verhalten Testprogramm Konsistenzprüfung Probenachrichten Testarten Strukturtest Basis: strukturelles Fehlermodell Liegt die Soll-Struktur, bestehend aus fehlerfreien Komponenten und ihren Funktionszuordnungen vor? Funktionstest Basis: funktionelles Fehlermodell Wird die spezifizierte Soll-Funktion erbracht? Heiko Krumm, RvS, Informatik IV, TU Dortmund 70

Z7: Fehlerdiagnose Testmethoden Testarten Absoluttest / Akzeptanztest Soll-Ist-Vergleich, ob a priori gegebene Konsistenzbedingungen über dem internen Zustand eines Testobjekts und / oder die von ihm errechneten Ergebnisse erfüllt sind Testobjekt ist fehlerfrei / Testobjekt ist fehlerhaft Relativtest Ist-Ist-Vergleich mehrfach ausgeführter Berechnungen Mehrheitsentscheid Informationsredundanz als Testbasis z.b. CRC, Quersumme, Signatur Heiko Krumm, RvS, Informatik IV, TU Dortmund 71

Z7: Fehlerdiagnose Diagnosegraph Diagnosegraph Knoten: Testsubjekte und objekte Kanten (gerichtet von Subjekt auf Objekt): Tests Subsystem S1 T3 T1 T2 Subsystem S2 Selbsttests z.b. T1, Prozessorselbsttest Fremdtests z.b, T2, T3 Speichertest Verbindungstest Subsystem S3 Heiko Krumm, RvS, Informatik IV, TU Dortmund 72