Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement

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

2. Übersicht 1. Eingebettete Systeme 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)

3. 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. 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

5. 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

6. 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

7. Safety ist nicht alles • Safety vs. Security • 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

8. 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)

9. Verläßlichkeit

10. 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

11. 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

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

13. 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

14. 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)

15. 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)

16. Struktur IEC61508 • 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!

17. 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)

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