Prof. Dr. Holger Schlingloff

Präsentation zum Thema: "Prof. Dr. Holger Schlingloff"—  Präsentation transkript:

1 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

2 Ü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 , Fr MBEES (Vorlesung entfällt)

3 2.1: Softwarequalität: Definitionen
Qualität = Übereinstimmung mit den Anforderungen DIN : „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 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

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

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!

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 / / 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 Ü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: Lesen!

17 Grundannahme „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