Software in sicherheitsrelevanten Systemen

1. Software in sicherheitsrelevanten Systemen Ralf Pinger / Stefan Gerken Sommersemester 2014

2. Kapitel 2 - SW und Systeme • Inhaltsübersicht • Abgrenzungen • Vollständigkeit und Korrektheit • Toleranzen bei SW und HW und Auswirkungen auf die Entwicklung • Fehlerpropagation • Fehler und Ausfälle • Quantifizierung • zufällige Fehler • systematische Fehler • Qualität Ralf Pinger / Stefan Gerken

3. 2.1 Abgrenzungen – Definition • Definition Software • Intellektuelle Schöpfung, die Programme, Verfahren, Regeln und alle dazugehörige Dokumentation umfasst, die zum Betrieb eines Systems gehören. • englische Übersetzung • intellectual creation comprising the programs, procedures, rules and any associated documentation pertaining to the operation of a system. • Quelle: EN 50128 Ralf Pinger / Stefan Gerken

4. 2.2 Vollständigkeit und Korrektheit • Vollständigkeit • Wurden alle Eingangswerte und ihre Parameter definiert? • Führen alle Verhaltensweisen der realen Welt zu gefährdungsfreien Reaktionen des implementierten Systems? • Korrektheit • Tut das System genau das, was definiert wurde? • Führen alle implementierten Reaktionen des Systems zu einem gefährdungsfreien Verhalten der realen Welt? • Folgerung: Korrektheit ist theoretisch nachweisbar, Vollständigkeit maximal plausibel Ralf Pinger / Stefan Gerken

5. 2.3 Toleranzen • "normaler" Funktionsbereich eines Systems ist ein schmales Band • Fehlerbereich ist der Rest Bild: nach Sergio Montenegro Ralf Pinger / Stefan Gerken

6. 2.3 Toleranzen – HW und SW • Auswirkungen bei • Hardware • Sind analoger Natur (sie „zerbricht“ nicht unmittelbar) • Führen im Allgemeinen nicht sofort zu einem Ausfall des Teils • Führen nicht zwangsläufig zu einem Bruch • Software • Ist digital (Werte sind sofort unplausibel, Wertebereiche laufen über, …) • Führen im Normalfall sofort zu einem undefinierten Zustand • Regenerieren sich im Normalfall nicht Ralf Pinger / Stefan Gerken

7. 2.4 Fehlerpropagation – Störungen und Unfälle • Ablauf: • Störung oder Fehler liegen vor • Störung wird wirksam • Störung pflanzt sich fort • Störung führt zu einem Unfall Bild: nach Sergio Montenegro Ralf Pinger / Stefan Gerken

8. 2.4 Fehlerpropagation – Hierarchisch • Fehler pflanzen sich in der funktionalen Programmhierarchie fort, da einzelne Module sich undefiniert verhalten Bild: nach Sergio Montenegro Ralf Pinger / Stefan Gerken

9. 2.4 Fehlerpropagation – Datenfluss • Fehler pflanzen sich zeitlich im Datenfluss fort, da einzelne Module sich undefiniert verhalten und reaktive Systeme im Regelfall nicht gedächtnislos sind. Bild: nach Sergio Montenegro Ralf Pinger / Stefan Gerken

10. 2.4 Fehlerpropagation – Fehlerauswirkungen Bild: nach Sergio Montenegro Ralf Pinger / Stefan Gerken

11. 2.5 Fehler und Ausfälle • Fehler ist die Abweichung von einem erwarteten Sollwert • Fehler kann unterschiedliche Ursachen haben • Menschliche (z. B. Fehlbedienungen) • Systematische (z. B. Programmierfehler, falsche Anforderungen) • Zufällige Ursachen (z. B. Übertragungsfehler) • Physikalische (z. B. Messfehler) • Ausfall ist das Versagen einer technischen Funktion • Ausfall bezieht sich auf physikalische Objekte • Ausfall ist in der Regel stochastisch • Nur ein unerwarteter Ausfall kann zu einem Fehler führen • Ausfall und Fehler hängen zusammen, sind aber nicht identisch! Ralf Pinger / Stefan Gerken

12. 2.6 Quantifizierung • Zweck: • ist nichts anderes als die Angabe von irgendetwas als Zahlenwert • zum Zweck der Vergleichbarkeit • erzeugt das Gefühl einer objektiven Bewertung • Problem: • Vergleichbarkeit • Objektivität Ralf Pinger / Stefan Gerken

13. 2.6.1 Quantifizierung – zufällige Fehler • Voraussetzung: Stochastisches Fehlermodell • Softwarefehler besitzen (hoffentlich) deterministisches Fehlermodell •  Ausfall • Stochastisches Modell über die Zeit → Ausfallrate ≡ Ausfälle des Elements pro Stunde • Stochastisches Modell über die Nutzungsfälle → Ausfallwahrscheinlichkeit ≡ Ausfälle pro Nutzung des Elements •  Betrifft sowohl Verfügbarkeit als auch Sicherheit Ralf Pinger / Stefan Gerken

14. 2.6.2 Quantifizierung – systematische Fehler • Mögliche Quantifizierung: • Z. B. Gefundene Fehler pro LOC • Prognose von systematischen Fehlern • Systematische Fehler treten bei gleichen Eingangsbedingungen reproduzierbar immer wieder auf • Zufälligkeit der Eingangsbedingungen sind nicht notwendigerweise gegeben • Warum einen Fehler nicht beheben, wenn er bekannt ist? • Woher weiß man, wie die Restfehler verteilt sein werden? Ralf Pinger / Stefan Gerken

15. 2.6.2 Quantifizierung – korrekt, robust und vollständig • Korrektheit ist ein Synonym für Fehlerfreiheit, das heißt: • Korrektheit ist digital • Korrektheit einer Realisierung ist bezogen auf deren Spezifikation • Eine fehlende Spezifikation impliziert Korrektheit • Vollständigkeit ist • verallgemeinert, wenn alles für eine Problemlösung erforderte realisiert wurde (Normalbetrieb und Fehlerfälle) • bezogen auf Software die Umsetzung aller Anforderungen der Spezifikation • bezogen auf ein Problem die Spezifikation aller Aspekte eines Problems • Robustheit ist • unter unerwarteten Situationen sinnvoll zu reagieren • nicht digital • nicht proportional zur Korrektheit Ralf Pinger / Stefan Gerken

16. 2.6.3 Quantifizierung – Qualität • Qualität - Lat.: qualitas – Beschaffenheit • Die Gesamtheit von Merkmalen (und Merkmalswerten) einer Einheit bezüglich ihrer Eignung, festgelegte und vorausgesetzte Erfordernisse zu erfüllen. [Deutsche Gesellschaft für Qualität] • Qualitätsmodelle • Softwarequalität selbst ist in der Praxis nicht direkt anwendbar. • weitere Detaillierung und Konkretisierung durch Qualitätsmodelle • Ableitung von Unterbegriffen Ralf Pinger / Stefan Gerken

17. 2.6.3 Quantifizierung – Qualitätsmodelle • Qualitätsmodell nach Balzert Ralf Pinger / Stefan Gerken

18. 2.6.3 Quantifizierung – Qualitätsmodelle • Qualitätsmodell nach ISO/IEC 9126-1 Ralf Pinger / Stefan Gerken

19. 2.6.3 Quantifizierung – Qualitätsmodelle • Qualitätsmodell GQM nach Basili, Rombach Ralf Pinger / Stefan Gerken

20. 2.6.3 Quantifizierung – Metriken • Beispiele: • McCabes zyklomatische Zahl • Eindeutig definiert • Reproduzierbar • Nur auf Kontrollflussgraphen anwendbar • Lines of Code (LOC) • Unklarheit bezüglich Leerzeilen und Kommentarzeilen • Function Points • Basiert auf individuellen Einschätzungen • Prinzipbedingt nur sehr eingeschränkt reproduzierbar Ralf Pinger / Stefan Gerken

21. Qualitätsanforderungen Qualitätsmodell Architekturmodell Designmodell 2.6.3 Quantifizierung – Qualität Bild: Axel Zechner Ralf Pinger / Stefan Gerken