1 / 21

Software in sicherheitsrelevanten Systemen

Software in sicherheitsrelevanten Systemen. Ralf Pinger / Stefan Gerken Sommersemester 2013. 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

emmet
Download Presentation

Software in sicherheitsrelevanten Systemen

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  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

More Related