software in sicherheitsrelevanten systemen
DESCRIPTION
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 - PowerPoint PPT PresentationTRANSCRIPT
Software in sicherheitsrelevanten Systemen
Ralf Pinger / Stefan Gerken
Sommersemester 2013
Software in sicherheitsrelevanten SystemenSommersemester 2013
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
20.04.23 Ralf Pinger / Stefan GerkenPage 2
Kapitel 2 - SW und Systeme
Inhaltsübersicht
1. Abgrenzungen2. Vollständigkeit und Korrektheit3. Toleranzen bei SW und HW und Auswirkungen auf die Entwicklung4. Fehlerpropagation5. Fehler und Ausfälle6. Quantifizierung
1. zufällige Fehler2. systematische Fehler3. Qualität
Software in sicherheitsrelevanten SystemenSommersemester 2013
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
20.04.23 Ralf Pinger / Stefan GerkenPage 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
Software in sicherheitsrelevanten SystemenSommersemester 2013
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
20.04.23 Ralf Pinger / Stefan GerkenPage 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
Software in sicherheitsrelevanten SystemenSommersemester 2013
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
20.04.23 Ralf Pinger / Stefan GerkenPage 5
2.3 Toleranzen
Bild: nach Sergio Montenegro
"normaler" Funktionsbereich eines Systems ist ein schmales Band
Fehlerbereich ist der Rest
Undefinierter Bereich
Zeit
Varia
ble
Geplanter Bereich Tolerierter BereichVerlauf
Software in sicherheitsrelevanten SystemenSommersemester 2013
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
20.04.23 Ralf Pinger / Stefan GerkenPage 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
Software in sicherheitsrelevanten SystemenSommersemester 2013
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
Ablauf: Störung oder Fehler liegen vor Störung wird wirksam Störung pflanzt sich fort Störung führt zu einem Unfall
20.04.23 Ralf Pinger / Stefan GerkenPage 8
2.4 Fehlerpropagation – Störungen und Unfälle
Bild: nach Sergio Montenegro
Software in sicherheitsrelevanten SystemenSommersemester 2013
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
20.04.23 Ralf Pinger / Stefan GerkenPage 9
2.4 Fehlerpropagation – Hierarchisch
Bild: nach Sergio Montenegro
Fehler pflanzen sich in der funktionalen Programmhierarchie fort, da einzelne Module sich undefiniert verhalten
Software in sicherheitsrelevanten SystemenSommersemester 2013
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
20.04.23 Ralf Pinger / Stefan GerkenPage 10
2.4 Fehlerpropagation – Datenfluss
Bild: nach Sergio Montenegro
Fehler pflanzen sich zeitlich im Datenfluss fort, da einzelne Module sich undefiniert verhalten und reaktive Systeme im Regelfall nicht gedächtnislos sind.
Software in sicherheitsrelevanten SystemenSommersemester 2013
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
20.04.23 Ralf Pinger / Stefan GerkenPage 11
2.4 Fehlerpropagation – Fehlerauswirkungen
Bild: nach Sergio Montenegro
Betrieb
Rückfallebene
Normaler Betrieb
ReparaturFehler Fehlerbereich
Sicherer Zustand
System ausgefallen
Unfall
UnerwarteterFehler
Fehlertoleranz
Fail Safe
KeineMaßnahme
zu erwarten
Glück
Absolut nichtzu erwarten
Software in sicherheitsrelevanten SystemenSommersemester 2013
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
20.04.23 Ralf Pinger / Stefan GerkenPage 12
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!
Software in sicherheitsrelevanten SystemenSommersemester 2013
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
20.04.23 Ralf Pinger / Stefan GerkenPage 13
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
Software in sicherheitsrelevanten SystemenSommersemester 2013
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
20.04.23 Ralf Pinger / Stefan GerkenPage 14
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
Software in sicherheitsrelevanten SystemenSommersemester 2013
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
20.04.23 Ralf Pinger / Stefan GerkenPage 15
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?
Software in sicherheitsrelevanten SystemenSommersemester 2013
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
20.04.23 Ralf Pinger / Stefan GerkenPage 16
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
Software in sicherheitsrelevanten SystemenSommersemester 2013
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
20.04.23 Ralf Pinger / Stefan GerkenPage 17
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
Software in sicherheitsrelevanten SystemenSommersemester 2013
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
20.04.23 Ralf Pinger / Stefan GerkenPage 18
2.6.3 Quantifizierung – Qualitätsmodelle
Qualitätsmodell nach Balzert
Software in sicherheitsrelevanten SystemenSommersemester 2013
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
20.04.23 Ralf Pinger / Stefan GerkenPage 19
2.6.3 Quantifizierung – Qualitätsmodelle
Qualitätsmodell nach ISO/IEC 9126-1
Software in sicherheitsrelevanten SystemenSommersemester 2013
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
20.04.23 Ralf Pinger / Stefan GerkenPage 20
2.6.3 Quantifizierung – Qualitätsmodelle
Qualitätsmodell GQM nach Basili, Rombach
Software in sicherheitsrelevanten SystemenSommersemester 2013
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
20.04.23 Ralf Pinger / Stefan GerkenPage 21
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
Software in sicherheitsrelevanten SystemenSommersemester 2013
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
20.04.23 Ralf Pinger / Stefan GerkenPage 22
2.6.3 Quantifizierung – Qualität
Bild: Axel Zechner
Qualitätsanforderungen
QualitätsmodellArchitekturmodell
Designmodell