Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer Institut für Rechnerarchitektur und Softwaretechnik 4.1.2006

Übersicht 1. Eingebettete Systeme 2. Software-Qualität Hinweise 1.1. Definitionen 1.2. Anforderungsanalyse 1.3. Modellierung 1.4. Architektur Hard- und Software-Aufbau Fehlertoleranz 1.5. Automotive Software Engineering 2. Software-Qualität 2.1 Definitionen und Standards 2.2 Funktionstest Überdeckungsmaße, Integrations- und Abnahmetest, Spezifikationsformalismen, Verifikation und Modellprüfung, Metriken, Reviews, Qualitätsstandards (CMM/I) Hinweise Mi. 11.1., Fr. 13.1. MBEES (Vorlesung entfällt) 4.1.2006

2.1: Softwarequalität: Definitionen Qualität = Übereinstimmung mit den Anforderungen DIN 55350-11 95: „die Beschaffenheit einer Einheit bezüglich ihrer Eignung, festgelegte und abgeleitete Erfordernisse (Qualitätsanforderungen) zu erfüllen“ Also z.B.: Funktionalität, Benutzbarkeit, Zuverlässigkeit, aber auch Preisgünstigkeit, ... Qualitätsanforderungen: die Gesamtheit der Einzelanforderungen an eine Einheit, die die Beschaffenheit dieser Einheit betreffen Qualitätsmaße: stellen den Grad der Ausprägung eines Qualitätsmerkmals (numerisch) dar z.B. MTBF für Zuverlässigkeit 4.1.2006

Hersteller- und Nutzersicht Eigenschaften einer Funktionseinheit, anhand derer die Qualität beschrieben und beurteilt wird Funktionalität, Zweckdienlichkeit, Robustheit, Zuverlässigkeit, Sicherheit, Effizienz, Benutzbarkeit, Verfügbarkeit, Geschwindigkeit, Änderbarkeit, Portierbarkeit, Prüfbarkeit, … kann aus Teilmerkmalen bestehen Hersteller- und Nutzersicht verschiedene Optimierungsfunktionen oft gegensätzliche Optimierungskriterien „die beste Qualität“ gibt es nicht 4.1.2006

Korrektheit, Sicherheit, Zuverlässigkeit… ANSI 72983: „Grad der Übereinstimmung zwischen Spezifikation und Programm“ vgl. Definition von Qualität! ungeeignete Definition (ein wenig schwanger…) Korrektheit bedeutet Abwesenheit von Fehlern Software ist korrekt, wenn sie genau das in der Spezifikation festgelegte funktionale Verhalten zeigt also nicht: Wartbarkeit, Effizienz, Funktionalität, … als Qualitätsmaß schlecht geeignet Üblicherweise sind mehrere verschiedene korrekte Implementierungen einer Spezifikation möglich 4.1.2006

Sicherheit „Sicher“ ist sicher ein vielstrapaziertes Wort… ISO 8402: Sicherheit = Zustand, in dem das Risiko eines Personen- oder Sachschadens auf einen annehmbaren Wert begrenzt ist was heißt „annehmbar“ ? Ein System heißt sicherheitskritisch, wenn es beim Ausfall großen Schaden verursachen kann „großer Schaden“: Der Ausfallverlust übersteigt die regulären Betriebsgewinne um ein Vielfaches „Sicherer Zustand“ ist nicht immer sicher… fail-safe, safe-stop, fail-silent, … „Sicherheit durch Erfahrung“ ist problematisch Erfahrung hat man erst wenn das Kind in den Brunnen gefallen ist Systeme müssen sicher sein ohne dass etwas schief geht 4.1.2006

Safety ist nicht alles Safety vs. Security Safety vs. Liveness Security = Informationssicherheit / Geschütztheit Security = Schutz vor böswilligen Schäden Safety = Schutz vor unbeabsichtigten Schäden Manchmal direkt gegensätzliche Ziele Kaufhauskunden verbrennen weil Türen verriegelt Safety vs. Liveness Formale Definitionen von Sicherheitseigenschaften safety = „nothing bad will ever happen“ Wenn die Eigenschaft verletzt ist, gibt es eine endliche Folge von Ereignissen die dies bewirkt liveness = „something good will eventually happen“ Jede endliche Folge von Ereignissen kann so erweitert werden, dass die Eigenschaft doch noch erfüllt ist 4.1.2006

Zuverlässigkeit / Verläßlichkeit Zuverlässigkeit (Reliability) ist ein Maß für die Fähigkeit des Systems, funktionstüchtig zu bleiben; Wahrscheinlichkeit, dass das System während einer bestimmten Zeitdauer t nicht versagt DIN 40041: Zuverlässigkeit ist die Beschaffenheit bezüglich der Eignung, während oder nach vorgegebenen Zeitspannen bei vorgegebenen Arbeitsbedingungen die Zuverlässigkeits-anforderungen zu erfüllen Verläßlichkeit (Dependability) = Grad der Vertrauenswürdigkeit in die vom System erbrachte Leistung (subjektive Wertung) 4.1.2006

Verläßlichkeit 4.1.2006

Dependability Verlässlichkeit Mean Time to Failure (MTTF) Mittlere Laufzeit vor Ausfall Reliability Zuverlässigkeit Availability Verfügbarkeit Mean Time To Repair (MTTR) Safety Sicherheit Risikobehandlung: erkennen, eliminieren, reduzieren, Folgen minimieren Maintainability Wartbarkeit 4.1.2006

Verfügbarkeit Maß für die durchschnittliche Erbringung der Funktionalität Kenngrößen MTTF = Mean Time to Failure MTTR = Mean Time To Repair Availability = MTTF / (MTTF + MTTR) Verfügbarkeit und Sicherheit sind oft gegensätzliche Ziele! Ein Auto, das niemals fährt, ist sicher: es geht keine Gefahr von ihm aus, es ist aber nicht brauchbar Ein Auto, das immer fahren kann, auch wenn es auseinanderfällt, hat die höchste Verfügbarkeit, ist aber nicht sicher 4.1.2006

Pause! http://www.b-cent.com/modules/gallery/albums/siteimages/safety_first_cartoon.jpg 4.1.2006

Sicherheitsstandards und -normen beschreiben Vorgehensweisen, um die Sicherheit von Produkten zu erhöhen spezialisiert auf Branchen Beispiele: IEC 61508, Functional safety of electrical/electronic/programmable electronic safety-related systems CENELEC EN 50126 / 50128 / 50129, Railway Applications - the specification and demonstration of Reliability, Availability, Maintainability and Safety; Software for railway control and protection systems; Safety related electronic systems for signalling. DO 178-B, Software Considerations in Airborne Systems and Equipment Certification 4.1.2006

Beispiel IEC61508 Entwurf 1995/1998, Endfassung August 2002 Zielsetzung: Standard zur Beurteilung sicherheitsbezogener Systeme durch allgemeine Anforderungen zur funktionalen Sicherheit funktionale Sicherheit: der Teil der Sicherheit, der davon abhängt ob ein System oder Gerät auf Eingaben richtig reagiert Beispiele: Nothaltsystem, Förderbandkontrolle, x-by-wire, Motordrehzahlbegrenzer, Strahlungsdosierung, … Statt einer Betrachtung einzelner Komponenten (Sensor, Aktuator, Prozessor) Ausrichtung auf sicherheitsgerichtete Funktion Abdeckung aller relevanter Phasen im Lebenszyklus (Konzept, Design, Implementierung, Betrieb) 4.1.2006

Ursachen gefährlicher Ausfälle incorrect specifications of the system, hardware or software omissions in the safety requirements specification (e.g. failure to develop all relevant safety functions during different modes of operation) random failures of hardware systematic failures of hardware and software common cause failures human error environmental influences (e.g. electromagnetic, temperature, mechanical phenomena) supply system voltage disturbances (e.g. loss of supply, reduced voltages, re-connection of supply) 4.1.2006

Struktur IEC61508 Überblick: http://www.iec.ch/zone/fsafety/ Part 1: General requirements documentation, conformance to the standard, management and assessment, as well as the technical requirements for achieving safety throughout the system life cycle Part 2: Requirements for E/E/PE safety-related systems (hardware) Part 3: Software requirements Part 4: Definitions and abbreviations Part 5: Examples of methods for the determination of safety integrity levels Part 6: Guidelines on the application Part 7: Overview of techniques and measures Überblick: http://www.iec.ch/zone/fsafety/ Lesen! 4.1.2006

Grundannahme http://www.csr.ncl.ac.uk/FELIX_Web/4B.IEC%2061508%20Intro.pdf „Equipment under Control“ (EUC) stellt immanente Gefährdung der Umgebung dar korrekte Steuerung allein garantiert keine Sicherheit Steuerung und Sicherung müssen getrennt betrachtet werden (z.B. separate Kabel) 4.1.2006

Risikobegriffe Risikominderung durch verschiedene Technologien möglich; von IEC61508 wird nur E/E/PE betrachtet 4.1.2006