slide1
Download
Skip this Video
Download Presentation
Software in sicherheitsrelevanten Systemen

Loading in 2 Seconds...

play fullscreen
1 / 80

Software in sicherheitsrelevanten Systemen - PowerPoint PPT Presentation


  • 82 Views
  • Uploaded on

Software in sicherheitsrelevanten Systemen. Ralf Pinger / Stefan Gerken Sommersemester 2014. Kapitel 6 - Software für sicherheitsrelevante Systeme. Inhaltsübersicht CENELEC EN 50128 – eine Gebrauchsanleitung Anforderungen SW-Entwicklungsmethoden SW-Test Qualität

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Software in sicherheitsrelevanten Systemen' - gilon


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1
Software in sicherheitsrelevanten Systemen

Ralf Pinger / Stefan Gerken

Sommersemester 2014

kapitel 6 software f r sicherheitsrelevante systeme
Kapitel 6 - Software für sicherheitsrelevante Systeme
  • Inhaltsübersicht
  • CENELEC
  • EN 50128 – eine Gebrauchsanleitung
  • Anforderungen
  • SW-Entwicklungsmethoden
  • SW-Test
  • Qualität
  • Qualitätssicherung von Entwicklungswerkzeugen

Ralf Pinger / Stefan Gerken

6 1 cenelec
6.1 CENELEC
  • CENELEC ist das Europäische Normungskomitee für Elektrotechnik (Comité Européen de Normalisation Électrotechnique).
  • In der CENELEC sind die nationalen Normungskomitees von vielen europäischen Staaten vertreten (z.B. DKE - Deutsche Kommission Elektrotechnik, Elektronik, Informationstechnik im DIN und VDE).
  • In diesen Staaten werden nationale Normen durch CENELEC-Normen sukzessive ersetzt.
  • Die CENELEC hat unter anderem Normen zur funktionalen Sicherheit im Bahnbereich veröffentlicht

Ralf Pinger / Stefan Gerken

6 1 cenelec struktur der bahnnormen
6.1 CENELEC – Struktur der Bahnnormen

Ralf Pinger / Stefan Gerken

6 1 cenelec lebenszyklus nach en 50126
6.1 CENELEC – Lebenszyklus nach EN 50126

Für jede Phase werden definiert

  • Ziele
  • Input (Dokumente)
  • Anforderungen
  • Output (Dokumente)
  • Verifikationsaufgaben

Der Lebenszyklus umfaßt wesentlich mehr als nur die Entwicklung und beinhaltet Aufgaben für Hersteller und Betreiber!

Bild: EN 50126

Ralf Pinger / Stefan Gerken

6 1 cenelec obligatorische anforderungen
6.1 CENELEC- Obligatorische Anforderungen

CENELEC EN 50126 ist seit 1.4.2000 in allen CENELEC-

Mitgliedsländern als nationale Norm in Kraft gesetzt.

  • Klar definierte Verantwortlichkeit für RAMS-Aufgaben
  • Kompetenznachweise
  • Ausarbeitung und Durchführung eines RAM Programms
  • Ausarbeitung und Durchführung eines Sicherheitsplans
  • Implementierung eines EN 50126 und ISO 900x konformen Geschäftsprozesses
  • Effektives Konfigurationsmanagement für RAMS-Aufgaben

Ralf Pinger / Stefan Gerken

6 2 en 50128 eine gebrauchsanleitung
6.2 EN 50128 – eine Gebrauchsanleitung
  • Normen sind keine Gesetze und haben nur Empfehlungscharakter
  • Haben einen definierten Sprachgebrauch (hier DIN)

Ralf Pinger / Stefan Gerken

6 2 en 50128 anwendungsbereich
6.2 EN 50128 – Anwendungsbereich
  • Verfahren und technische Anforderungen für die Entwicklung von programmierbaren elektronischen Systemen
  • gesamter Bereich der Sicherheitsanwendungen
  • gilt für jegliche sicherheitsrelevante Software, die in Eisenbahnsteuerungs- und -überwachungssystemen verwendet wird, einschließlich:
    • Anwendungsprogrammierung;
    • Betriebssysteme;
    • unterstützende Werkzeuge;
    • Firmware.
  • Anwendungsprogrammierung schließt Programmierung in Hochsprache, Maschinensprache und speziellen Anwendungssprachen ein (z. B.: ladderlogic bei speicherprogrammierbaren Steuerungen).
  • gilt auch für Änderungen und Erweiterungen an bestehender Software

Ralf Pinger / Stefan Gerken

6 2 en 50128 aufbau der norm
6.2 EN 50128 – Aufbau der Norm
  • Normativer Textteil
  • Normative Anhänge A, B
  • Informativer Anhang C, D

Anhang A

Auswahl von

Methoden und Techniken

Normativer Text

Kapitel

Referenzen (D.nn)

Anhang D

Anhang B

Anhang C

Schlüsselrollen und Verantwortlichkeiten

Zusammenfassung der Dokumentenkontrolle

Informationen zu

Methoden / Techniken

Ralf Pinger / Stefan Gerken

6 2 en 50128 beispiel 1 normativer textteil
6.2 EN 50128 – Beispiel 1: Normativer Textteil
  • 7.2 Software-Anforderungen
  • 7.2.1 Ziele
  • 7.2.1.1 Beschreibung eines vollständigen Satzes von Anforderungen an die Software, der alle System- und Sicherheitsanforderungenerfüllt, und einen umfassenden Satz von Dokumenten für jede spätere Phase bereitstellt.
  • 7.2.1.2 Beschreibung der Gesamtsoftware-Testspezifikation.
  • 7.2.2 Eingangsdokumente
  • System-Anforderungsspezifikation …
  • 7.2.3 Ausgangsdokumente
  • Software-Anforderungsspezifikation...
  • 7.2.4 Anforderungen
  • 7.2.4.1 Eine Software-Anforderungsspezifikation muss unter der Verantwortung des Anforderungsmanagers auf der Grundlage der Eingangsdokumente nach 7.2.2 erstellt werden. Die Anforderungen in 7.2.4.2 bis 7.2.4.15 beziehen sich auf die Software-Anforderungsspezifikation.
  • 7.2.4.2 Die Software-Anforderungsspezifikation muss die geforderten Eigenschaften der zu entwickelnden Software darstellen. Diese Eigenschaften, die alle in der Normenreihe ISO/IEC 9126 (mit Ausnahme der Sicherheit) definiert sind, müssen einschließen:…
  • 7.2.4.3 Der Software-Sicherheits-Integritätslevel muss nach der Definition in Abschnitt 4 abgeleitet und in der Software-Anforderungsspezifikation festgehalten werden.

Ralf Pinger / Stefan Gerken

6 2 en 50128 sil
6.2 EN 50128 – SIL
  • SILheißt Sicherheitsanforderungsstufe
  • 5 SIL-Stufen
    • 0 = nichtsichere Anwendungen
    • 1 = niedrigste Anforderungsstufe
    • 4 = höchste Anforderungsstufe
  • 2 Klassen für sichere Anwendungen
    • (1,2) und (3,4)
  • Maßnahmen sind notwendig bei unter-schiedlichen SSAS innerhalb eines Systems

Ralf Pinger / Stefan Gerken

6 2 en 50128 beispiel 1 aus anhang a
6.2 EN 50128 – Beispiel 1 aus Anhang A

Ralf Pinger / Stefan Gerken

6 2 en 50128 beispiel 1 aus anhang d
6.2 EN 50128 – Beispiel 1 aus Anhang D
  • D.13 Entscheidungstabellen (Wahrheitstabellen) (en: Decision Tables (Truth Tables))
  • Ziel

Erstellen einer klaren und zusammenhängenden Spezifikation und Analyse komplexer logischer Kombinationen und Beziehungen.

Beschreibung

Diese verwandten Verfahren benutzen zweidimensionale Tabellen zur Kurzdarstellung logischer Beziehungen zwischen boolschen Programmvariablen.

Durch die Kürze und die tabellarische Form eignen sich beide Verfahren zur Analyse komplexer logischer Kombinationen, ausgedrückt in codierter Form.

Beide Verfahren können ausführt werden, falls sie als Spezifikation benutzt werden.

Ralf Pinger / Stefan Gerken

6 2 en 50128 beispiel 2 aus anhang a
6.2 EN 50128 – Beispiel 2 aus Anhang A

Quelle: EN 50128

Ralf Pinger / Stefan Gerken

6 2 en 50128 beispiel 2 aus anhang a fortsetzung
6.2 EN 50128 – Beispiel 2 aus Anhang A (Fortsetzung)

Quelle: EN 50128

Ralf Pinger / Stefan Gerken

6 2 en 50128 beispiel 2 aus anhang d
6.2 EN 50128 – Beispiel 2 aus Anhang D

Quelle: EN 50128

Ralf Pinger / Stefan Gerken

6 2 en 50128 beispiel 2 aus anhang d fortsetzung
6.2 EN 50128 – Beispiel 2 aus Anhang D (Fortsetzung)
  • Fortsetzung D.54

Quelle: EN 50128

Ralf Pinger / Stefan Gerken

6 2 en 50128
6.2 EN 50128

Quelle: EN 50128

Ralf Pinger / Stefan Gerken

6 2 en 50128 prozess
6.2 EN 50128 – Prozess

Ver

Val

Phase

Ergebnisse

Quelle: EN 50128

Ralf Pinger / Stefan Gerken

6 2 en 50128 verifikation und validierung
6.2 EN 50128 – Verifikation und Validierung

Verifikation: Untersuchungsprozess mit anschließender, auf Nachweisen beruhender Beurteilung, dass die Ergebnisse (Prozess, Dokumentation, Software oder Anwendung) einer bestimmten Entwicklungsphase die Anforderungen dieser Phase hinsichtlich Vollständigkeit, Richtigkeit und Konsistenz erfüllt

DIN EN 50128, März 2012

Wird richtig entwickelt

Ist das Richtige

entwickelt worden?

Validierung: Analyseprozess gefolgt von einer auf Nachweisen beruhenden Beurteilung, ob ein Objekt (z. B. Prozess, Dokumentation, Software oder Anwendung) den Bedarf des Nutzers erfüllt, insbesondere bezüglich Sicherheit und Qualität, sowie mit einem Schwerpunkt auf die betriebliche Eignung für den Verwendungszweck in der vorgesehenen Betriebsumgebung

DIN EN 50128, März 2012

Ralf Pinger / Stefan Gerken

6 2 en 50128 dokumente ergebnisse
6.2 EN 50128 – Dokumente / Ergebnisse
  • Definitionen / Anforderungen zu den Phasen des Lebenszyklus‘ (Textteil)
  • Vorgaben von Maßnahmen und Tools (Anhang A)
  • Vorgaben zu Kompetenzprofilen (Anhang B)
  • Vorgaben zu Reviews (Verifikation)
  • Verfolgbarkeit der Anforderungen

Ralf Pinger / Stefan Gerken

6 2 en 50128 rollen und unabh ngigkeiten
6.2 EN 50128 – Rollen und Unabhängigkeiten

Anerkannter Fachbetrieb:

Der Gutachter kann auch der entwickelnden Firma unterstellt sein, wenn eine ausreichende Unabhängigkeit zur entwickelnden Abteilung gewährleistet ist

Voraussetzung:

Anerkennung durch Zulassungsbehörde wie z.B. EBA

Quelle: EN 50128

Ralf Pinger / Stefan Gerken

6 2 en 50128 aufgaben und rollen
6.2 EN 50128 – Aufgaben und Rollen

Quelle: EN 50128

Ralf Pinger / Stefan Gerken

6 2 en 50128 zusammenfassung
6.2 EN 50128 – Zusammenfassung
  • Vorgaben für den Entwicklungsprozess
  • Festlegung von Maßnahmen und Tools
  • Anforderungen an Dokumente
  • Unabhängige Stellen

Ralf Pinger / Stefan Gerken

6 3 anforderungen inhalts bersicht
6.3 Anforderungen – Inhaltsübersicht
  • Inhaltsübersicht
  • Anforderungsmanagement
  • Ermittlung von Anforderungen
  • Rapid Prototyping
  • Verfolgung von Anforderungen
  • Identifikation von Anforderungen
  • Umsetzung von Anforderungen
  • Nachweis von Anforderungen

Ralf Pinger / Stefan Gerken

6 3 anforderungen ziele der en 50128
6.3 Anforderungen – Ziele der EN 50128
  • Beschreibung eines vollständigen Satzes von Anforderungen an die Software, der alle System- und Sicherheitsanforderungen erfüllt, und einen umfassenden Satz von Dokumenten für jede spätere Phase bereitstellt.
  • In dem durch den Software-Sicherheits-Integritätslevel festgelegten Umfang muss die Software-Anforderungsspezifikation so formuliert und strukturiert werden, dass sie vollständig, klar, genau, eindeutig, verifizierbar, testbar, wartbar und umsetzbar ist und auf alle Eingangsdokumente rückverfolgbar.
  • Beschreibung der Gesamtsoftware-Testspezifikation.

Ralf Pinger / Stefan Gerken

6 3 1 anforderungsmanagement motivation
6.3.1 Anforderungsmanagement – Motivation
  • fehlende oder falsche Anforderungen
  • haben Auswirkungen auf das gesamte Produkt
  • werden üblicherweise erst bei Inbetriebnahme oder später erkannt
  • gefährden die erfolgreiche Abnahme des Produkts
  • können Auswirkungen auf die gesamte Architektur haben
  •  Änderungen sind entsprechend kostspielig
  • Anforderungsmanagement
  • ist eine Managementaufgabe
  • zielt auf Effizienz
  • zielt auf Fehlerarmut
  • ordnet das Chaos

Ralf Pinger / Stefan Gerken

6 3 2 ermittlung von anforderungen
6.3.2 Ermittlung von Anforderungen
  • Ziel der Anforderungsermittlung:
  • Erkennen der Anforderungen des Kunden
  • Das bedeutet:
  • Definition der Systemgrenzen
  • Definition der Schnittstellen
  • Definition der zu erbringenden Systemfunktionen
  • Definition der Umgebungsbedingungen
  • Definition der zu unterstützenden Kundenprozesse
  • Definition der gesetzlichen Rahmenbedingungen
  • Definition der wirtschaftlichen Rahmenbedingungen

Ralf Pinger / Stefan Gerken

6 3 2 ermittlung von anforderungen1
6.3.2 Ermittlung von Anforderungen
  • Häufige Probleme
  • Mensch
    • Sprache (Domäne vs. SW-Experte)
    • Divergierende Meinungen von Stakeholdern
    • Motivation zur Unterstützung
  • Organisationen
    • Produktstrategie
    • Verfügbarkeit von Stakeholdern
  • Fachlicher Inhalt
    • Kritikalität des Systems
    • Systemumfang
    • Unterschiedliche Detaillierung von Anforderungen
    • Nicht funktionale Anforderungen
    • Methoden
  • Und vieles mehr

Ralf Pinger / Stefan Gerken

6 3 2 ermittlung von anforderungen2
6.3.2 Ermittlung von Anforderungen
  • Bewertung der Anforderungen:
  • Korrektheit
  • Vollständigkeit
  • Machbarkeit
  • Bewertung, ob Kundenanforderung
  • Wichtigkeit
  • Kosten

Ralf Pinger / Stefan Gerken

6 3 3 rapid prototyping
6.3.3 Rapid Prototyping
  • Rapid Prototyping
  • kommt eigentlich aus dem Maschinenbau
  • beschreibt den schnellen Musterbau
  • ist als Software Engineering Methode adaptiert worden
  • wird in Verbindung mit agilen Vorgehensweisen eingesetzt
  • kann auch zur Anforderungsermittlung eingesetzt werden

Ralf Pinger / Stefan Gerken

6 3 3 rapid prototyping1
6.3.3 Rapid Prototyping
  • Vorteile
  • ausführbares Anforderungsmodell macht das System „erlebbar“
  • Ausführbares Testmodell als Diskussionsgrundlage mit dem Kunden dienen
  • Anforderungsmodell kann als Testmodell verwendet werden
  • Nachteile
  • Anforderungsmodell orientiert sich an einer Spezifikation oder Kundengesprächen
  • Anforderungsmodell ist nicht architekturgetrieben
  • Anforderungsmodell erzeugt den Eindruck doppelter Entwicklung

Ralf Pinger / Stefan Gerken

6 3 3 analyse design modell
Analyse-Modell:

schneller Prototyp

keine vollständige Durchdringung der Anforderungen notwendig

Anforderungsfehler werden frühzeitig offenbart

Schnelle Anpassbarkeit an Kundenänderungen (agil)

Ausprägungen:

Wegwerfprototyp

Refaktorisierung bis zum Produkt

Design-Modell:

Verständlichkeit/Wartbarkeit

Einfache Lösungen entstehen in der Regel nicht im ersten Ansatz!

Hohe Durchdringung der Anforderungen notwendig

Architektur muss weitgehend bekannt sein

Ausprägungen:

(Neu-) Entwicklung

Refaktorisiert aus Analyse-Modell

6.3.3 Analyse-/Design-Modell

Ralf Pinger / Stefan Gerken

6 3 4 verfolgung von anforderungen
6.3.4 Verfolgung von Anforderungen
  • Ziele sind Identifikation von:
  • Verfeinerungen
  • Realisierungen
  • Wechselwirkungen
  • Nachweisen
  • Nebenwirkungen der Identifikation:
  • Änderungsauswirkungsanalyse
  • Regressionstests
  • Fehleranalyse
  • Kostenabschätzung für Änderungen

Ralf Pinger / Stefan Gerken

6 3 5 identifikation von anforderungen
6.3.5 Identifikation von Anforderungen
  • Anforderung bedarf
  • einer eindeutigen Bezeichnung (z. B. Text, Nummer, Identifikator)
  • eines vereinbarten Zwecks, z. B.
    • define
    • refine
    • implement
    • test
    • safety
    • RAM
    • motive
    • annotation
    • version
  • um die Verfolgbarkeit und Nachvollziehbarkeit zu gewährleisten

Ralf Pinger / Stefan Gerken

6 3 6 umsetzung von anforderungen
6.3.6 Umsetzung von Anforderungen
  • Arten der Umsetzung
  • Artefakte
    • Modellierung
    • Programmierung
    • Dokumente
  • Verfeinerung der Anforderungen durch neue Anforderungen
  • Umsetzen nicht-funktionaler Anforderungen durch Prozesse

Ralf Pinger / Stefan Gerken

6 3 7 nachweis von anforderungen
6.3.7 Nachweis von Anforderungen
  • Zielgruppen:
  • Kunde
  • Gutachter
  • Zulassungsbehörde
  • Methoden:
  • Analyse
    • Sicherheitsnachweise
    • RAM-Nachweise
    • Qualitätsnachweise
  • Test
    • Testberichte

Ralf Pinger / Stefan Gerken

6 4 sw entwicklungsmethoden inhalts bersicht
6.4 SW-Entwicklungsmethoden – Inhaltsübersicht
  • Inhaltsübersicht
  • Konventionelle Entwicklungsmethoden
  • Halb-formale Entwicklungsmethoden
  • Formale Entwicklungsmethoden
  • Modellbasiertes Software-Engineering

Ralf Pinger / Stefan Gerken

6 4 sw entwicklungsmethoden ziele der en 50128
6.4 SW-Entwicklungsmethoden – Ziele der EN 50128
  • SW-Architektur & SW-Entwurf und Design
  • Entwickeln einer Software-Architektur
  • Überprüfen der Anforderungen an die System-Architektur
  • Feststellen und Bewerten, der Wechselwirkungen zwischen Hardware und Software
  • Auswahl eines Entwurfsverfahrens
  • Entwurf und Implementierung von Software
  • Software, die analysierbar, testbar, verifizierbar und wartbar ist
  • Auswahl eines für die geforderte Software-Sicherheitsanforderungsstufe angemessenen Satzes von Werkzeugen
  • Durchführung der Softwareintegration

Ralf Pinger / Stefan Gerken

6 4 1 konventionelle entwicklungsmethoden beispiele
6.4.1 Konventionelle Entwicklungsmethoden – Beispiele
  • Konventionelle Entwicklungsmethoden
  • VHIDT – Vom Hirn in die Tastatur
  • Strukturierte Verfahren (laut EN 50128)
    • JSD - Jackson System Development
    • MASCOT - Modular Approach to Software Construction, Operation and Test
    • SADT - Structured Analysis and Design Technique
    • SDL
    • SSADM
    • Yourdon - Real-time Yourdon
  • Modulares Vorgehen
  • Entwurfs- und Codierstandards
  • Streng typisierte Programmiersprache
  • Strukturierte Programmierung
  • Objektorientierte Programmierung

Ralf Pinger / Stefan Gerken

6 4 2 modellierung beispiele
6.4.2 Modellierung – Beispiele
  • Methoden der Modellierung aus der EN 50128
  • Datenmodellierung
  • Datenflussdiagramme
  • Kontrollflussdiagramme
  • Endliche Zustandsmaschinen/Zustandsübergangsdiagramme
  • Zeit-Petri-Netze
  • Entscheidungs-/Wahrheitstabellen
  • Formale Methoden
  • Leistungsmodellierung
  • Strukturdiagramme
  • Ablaufdiagramme

Ralf Pinger / Stefan Gerken

6 4 3 formale entwicklungsmethoden beispiele
6.4.3 Formale Entwicklungsmethoden – Beispiele
  • Formale Entwicklungsmethoden aus der EN 50128
  • CSP - Communicating Sequential Processes
  • CCS - Calculus of Communicating Systems
  • HOL - Higher Order Logic
  • LOTOS - Language for Temporal Ordering Specification
  • OBJ – ist eine algebraische Spezifikationssprache
  • Temporal Logic
  • VDM - Vienna Development Method
  • Z
  • B
  • Model Checking

Ralf Pinger / Stefan Gerken

6 4 4 modellbasiertes software engineering urspr nge
6.4.4 Modellbasiertes Software-Engineering – Ursprünge
  • Erste Ansätze in den 80er Jahren mit den CASE-Tools
  • Modellierungselemente waren: SA/SD
  • Es gab viele Erfolge mit CASE-Tools
    • Qualitätsverbesserung
    • Bessere Beherrschung der Komplexität
    • Mehr Abstraktion  mehr Plattformunabhängigkeit
  • Die CASE-Tools hatten aber auch noch einige Unzulänglichkeiten
    • Roundtrip-Engineering nicht möglich
    • Formale Verifikation noch nicht ausgereift
    • Tool-Entwicklung war nicht fortschrittlich genug
    • Modellelemente waren für viele Probleme nicht ausreichend

Ralf Pinger / Stefan Gerken

6 4 4 modellbasiertes software engineering erl uterung
6.4.4 Modellbasiertes Software-Engineering – Erläuterung
  • Modellbasierte Entwicklung definiert:
  • n Hierarchieebenen
  • auf jeder Ebene eine (formale, domänenspezifische) abstrakte Sprache
  • Transformationen zwischen den Hierarchieebenen
  • möglichst weitgehende Automatisierung der Transformationen

Ralf Pinger / Stefan Gerken

6 4 4 modellbasiertes software engineering
6.4.4 Modellbasiertes Software-Engineering
  • 29 .text
  • 30 0027 90 .p2align 2,,3
  • 31 .globl main
  • 32 .type main,@function
  • 33 main:
  • 34 0028 55 pushl %ebp
  • 35 0029 89E5 movl %esp, %ebp
  • 36 002b 83EC08 subl $8, %esp
  • 37 002e 83E4F0 andl $-16, %esp
  • 38 0031 83EC0C subl $12, %esp
  • 39 0034 680E0000 pushl $.LC1 39 00
  • 40 0039 C7050000 movl $3, a 40 00000300
  • 41 0043 E8FCFFFF call puts 41 FF
  • 42 0048 C7042404 movl $4, (%esp)

Ralf Pinger / Stefan Gerken

6 4 4 modellbasiertes software engineering1
6.4.4 Modellbasiertes Software-Engineering
  • void Step(void) {
  • input.AktuelleZeit.timeX = GetTickCount() - starttime;tbl_display.hour = timeinfo->tm_hour;tbl_display.min = timeinfo->tm_min;
  • if ((stepcount > 1000) && (output.StarteDailyTest)) {
  • input.DailyTestResult.vorhanden = kcg_true; input.DailyTestResult.Result = DT_ok_TBL1p_Types;
  • }
  • writeSSS(&input);
  • do{ stepcount = stepcount + 1; TBL1p_MainMixer(&input, &output); output2display();} while(!output.HabeFertig);
  • }

Ralf Pinger / Stefan Gerken

6 4 4 modellbasiertes software engineering motivation
6.4.4 Modellbasiertes Software-Engineering – Motivation
  • Logisch funktionale Inhalte auf hoher Abstraktionsebene
  • Unabhängig von konkreter Hardwareplattform  lange Produktlebenszyklen
  • Effizienzsteigerung in der Entwicklung
  • Frühzeitige Fehleroffenbarung
  • stärkere Verknüpfung von Implementierung und Dokumentation
  • Qualitätssteigerung
  • Einsatz von Analysewerkzeugen (z. B. Model Checker)  Nachweis von Eigenschaften
  • Unterstützung der Zertifizierung von Systemen

Ralf Pinger / Stefan Gerken

6 4 4 modellbasiertes software engineering abgrenzung
6.4.4 Modellbasiertes Software-Engineering – Abgrenzung
  • Eigenschaften der modellbasierten Entwicklung (1)
  • Verwendung von Modellen zur Softwareentwicklung um die Abstraktion zu erhöhen
  • Verwendung von Generatoren/Transformatoren bei der Softwareentwicklung
  • Auch teilweise Automatisierung möglich (je nach fachlicher Anforderung zwischen 20% und 100%)
  • Die erste Abstraktionsebene wird vollständig manuell erzeugt
  • Ziel ist die Steigerung der Softwarequalität bzw. -effizienz
  • Schlagwort „Automation durch Formalisierung“ in frühen Entwicklungsphasen
  • Definitionen MDA, MDSD, MDSE nicht einheitlich und weichen je nach Literaturquelle voneinander ab

Ralf Pinger / Stefan Gerken

6 4 4 modellbasiertes software engineering abgrenzung1
6.4.4 Modellbasiertes Software-Engineering – Abgrenzung
  • Eigenschaften der modellbasierten Entwicklung (2)
  • Die Modelltransformation erzeugt Modelle zur manuellen Weiterbearbeitung
  • MDA erfordert anwendungsspezifische Frameworks
  • MDA erfordert plattformspezifische Generatoren
  • MDA kann - abhängig von der Vollständigkeit der Codegenerierung – auch änderungsunfreundlich sein
  • MDA sagt nichts über den Abstraktionsgrad der Ebenen aus
  • Ebenen können aufeinander aufbauen.
  • Logische Fortsetzung des Abstraktionsgedankens bei der Entwicklung – manuelle Drahtverbindung, Maschinencode, Assembler, Programmiersprache, Modellierungssprache

Ralf Pinger / Stefan Gerken

6 4 4 modellbasiertes software engineering4
6.4.4 Modellbasiertes Software-Engineering
  • Ausdehnung der Abstraktionsidee auf gesamten Prozess
  • Entwicklung:
    • UML entwickelt sich zur industriellen Standardsprache
    • SCADE für sicherheitsrelevante Systeme geeignet
    • kommerzielle Werkzeuge im industriellen Einsatz bewährt
  • Testen/Analyse:
    • UML entwickelt sich zur industriellen Standardsprache
    • kaum geeignete, kommerzielle Werkzeuge am Markt
    • sehr großes Potenzial vor allem in der Sicherungstechnik

Ralf Pinger / Stefan Gerken

6 5 sw test inhalts bersicht
6.5 SW-Test – Inhaltsübersicht
  • Inhaltsübersicht
  • Konventionelle Testmethoden
  • (halb-)automatisierte Testmethoden
  • modellbasierte Testmethoden
  • analytische Methoden
  • Testende-Kriterien

Ralf Pinger / Stefan Gerken

6 5 testmethoden motivation
6.5 Testmethoden – Motivation

Herausforderung des Testens:

  • Der Testling besitzt einen großen internen Zustandsraum (vielleicht 21000 interne Zustände)
  • Testfälle sind separat zu erstellen
  • 215 manuell erstellte Testfälle sind schon sehr viel, aber bestimmt nicht erschöpfend
  •  nur ein kleiner Teil des Verhaltens wird getestet
  • Zum Vergleich:
  • Anzahl Elektronen im sichtbaren Universum

Eddington numberN_edd = 136×2256 = 1.57×1079

Ralf Pinger / Stefan Gerken

6 5 1 konventionelle testmethoden
6.5.1 Konventionelle Testmethoden
  • Excel-basiert, Ringbuch-Ordner oder einfach die Waldabholz-Methode
  • Testfälle sind in einer Tabelle aufgelistet
  • Eingabewerte, Ausführungsbeschreibung, Erwartungswert
  • Testausführung erfolgt manuell
    • Einstellen der Eingabewerte/Sequenzen
    • Ausführen des Tests
    • Beobachtung der Reaktionen und Vergleich mit Sollwert
  • Dokumentation des Tests in der Liste
  • Probleme:
  • Regressionstest nur sehr aufwändig möglich
  • Bei Software-Änderungen wird nur ein sehr kleiner Teil des Tests wiederholt

Unentdeckte Seiteneffekte möglich!

Ralf Pinger / Stefan Gerken

6 5 2 halb automatisierte testmethoden
6.5.2 (halb-)automatisierte Testmethoden
  • Ausprogrammierte Testfälle:
  • Testfälle werden ausprogrammiert
  • Erwartungswerte werden ebenfalls hinterlegt und am Ende der Ausführung verglichen
  • Test endet mit: „OK“ oder „FAILED“
  • Testausführung wird regressionsfähig
    • Nach SW-Änderung können (alle) Testfälle wiederholt werden
    • Ungewollte Seiteneffekte können entdeckt werden
  • Unterstützt durch Unit-Test-Module: JUnit, etc.
  • Probleme:
    • Testfälle „folgen sehr eng den Programmstrukturen“
    • Änderung an SW zieht oft große Änderungen an den Testfällen nach sich

Ralf Pinger / Stefan Gerken

6 5 3 modellbasierte testmethoden
6.5.3 Modellbasierte Testmethoden
  • Modellbasiertes Testen
    • ist weitgehend noch Gegenstand der Forschung
    • hat kaum geeignete, kommerzielle Werkzeuge am Markt
    • hat sehr großes Potenzial vor allem in der Sicherungstechnik
    • Testen umfasst 40 % des Gesamtaufwand eines Projekts
  • Zwei unterschiedliche Ausprägungen
    • Einsatz von Standard-Sprachen
    • Einsatz domänenspezifischer Sprachen ist möglich
  • Sehr hohes Potenzial zur Effizienzsteigerung
    • Generierung sehr vieler Testfälle ist möglich: Aber: Testorakel nicht vergessen

Ralf Pinger / Stefan Gerken

6 5 3 modellbasierte testmethoden1
6.5.3 Modellbasierte Testmethoden

Modellbasiertes Testen mit Standardsprachen

  • Verwenden einer bekannten Sprache zur Testfallmodellierung
    • Teilsprache der UML
      • Use-Case-Diagramm
      • Aktivitäts-Diagramm
      • Sequenz-Diagramm
      • Zustands-Diagramm
    • Auch andere Sprachen sind denkbar, z. B. Markov-Ketten
    • Generieren der Testfälle aus diesen Beschreibungen
    • Anpassen an die Testumgebung notwendig
    • Werkzeuge sind bestenfalls Baukästen

Ralf Pinger / Stefan Gerken

6 5 3 modellbasierte testmethoden2
6.5.3 Modellbasierte Testmethoden

Modellbasiertes Testen mit domänenspezifischen Sprachen

  • Entwickeln einer domänenspezifischen Sprache
  • Modellieren mit Meta-Modellierungswerkzeugen
    • EMF (Eclipse Modeling Framework)
    • Metaedit (kommerzielles Werkzeug)
    • Topcased (Open-source-Werkzeug)
  • In der Regel graphische Sprachen
  • Entwickeln eines Generators zur Testfallerzeugung
  • Leichter Zugang für Domänen-Experten

Ralf Pinger / Stefan Gerken

ein fahrprofil
Ein Fahrprofil

6.5.3 Modellbasierte Testmethoden

Ralf Pinger / Stefan Gerken

6 5 3 modellbasierte testmethoden3
6.5.3 Modellbasierte Testmethoden
  • Editor für Fahrprofile
  • Meta-Sprache in Metaedit
  • Editor-Generierung
  • Code-Generierung in XML-Format

Ralf Pinger / Stefan Gerken

6 5 3 modellbasierte testmethoden4
6.5.3 Modellbasierte Testmethoden
  • Metaedit bis zur Zwischensprache
  • Unterschiedliche Back-Ends für verschiedene Zielplattformen
  • Identische Testfälle für
    • Simulation am PC
    • Integrationstestumgebung
    • Zielplattform

Ralf Pinger / Stefan Gerken

6 5 3 modellbasierte testmethoden5
6.5.3 Modellbasierte Testmethoden

Strategie

  • Generierung aus abstrakten Beschreibungen:
    • Viele Testfälle aus einer abstrakten Beschreibung
    • Basis meist Aktivitätsdiagramme oder Zustandsmaschinen
    • Grundprinzip: Fallunterscheidungen “ausrollen“
    • Testorakel muss separat erzeugt werden
  • Generierung aus festgelegten Eingabesequenzen:
    • In der Regel ein Testfall pro abstrakter Beschreibung
    • Basis meist Sequenz-Diagramme, Use-Case-Diagramme
    • Grundprinzip: Ein “Durchlauf“ durch das System
    • Erzeugung vieler Testfälle durch Mischen
    • Testorakel kann mit beschrieben werden

Ralf Pinger / Stefan Gerken

6 5 3 modellbasierte testmethoden6
6.5.3 Modellbasierte Testmethoden
  • Modellbasierte Entwicklung ist auf dem Weg zum Industriestandard
  • Modellbasierte Entwicklungswerkzeuge sind auch für sicherheitsrelevanteSysteme einsetzbar
  • Modellbasiertes Testen bietet erhebliches Einsparpotenzial
  • Werkzeugunterstützung für domänenspezifische Sprachen
  • Einfache Sprache für Domänenexperten
    • Leicht zu Erlernen
    • Nur der Sprachumfang der auch benötigt wird
  • Generierung kann durch Software-Experten leicht ausgeführt werden
  • Anpassung an Testumgebungen, Simulation ...

Ralf Pinger / Stefan Gerken

6 5 4 analytische methoden
6.5.4 Analytische Methoden

Analyse

  • Testorakel: Ist mein Testfall durchgefallen?
  • Formale Verifikation: Erfüllt mein System die Anforderungen?
  • Timing-Analyse: Werden die Zeitanforderungen erfüllt?
  • Testende-Kriterien: Abdeckungsmessungen
  • Statische Analyse: Laufzeitfehler, Speicherverbrauch
  • Simulation: Wie verhält sich das System im Einsatz?
  • Güte des Designs: Ist die Architektur verständlich?

Ralf Pinger / Stefan Gerken

6 5 5 testende kriterien
6.5.5 Testende-Kriterien
  • Testende-Kriterien
  • Code-Abdeckung
    • Anweisungsüberdeckung – EN 50128
    • Pfadüberdeckung
    • Modified Condition/Decision Coverage (MC/DC) – DO 178C
  • Funktionsüberdeckung
  • Requirementsüberdeckung
  • Schnittstellenüberdeckung

Ralf Pinger / Stefan Gerken

6 6 1 prozesse
6.6.1 Prozesse
  • Prozesse bilden die Grundlage für
  • Zertifizierbarkeit
    • Können geforderte Eigenschaften nachgewiesen werden?
    • Ist nach dem Stand der Technik entwickelt worden?
  • Qualität
    • Wurde an alles gedacht?
    • Gibt es genügend Maßnahmen zur Fehlerreduktion?
  • Wartbarkeit
    • Wo muss was geändert werden?
  • Vorhersagbarkeit eines Projekts
    • Wann wird was geliefert?
    • Wie viel kostet es?
  • Gerichtsfeste Nachweise

Ralf Pinger / Stefan Gerken

6 6 2 fehlerkultur
6.6.2 Fehlerkultur
  • Offener Umgang mit Fehlern:
  • Fehler in Projekten sind ganz normal
  • Der Gesamtprozess mit den unterschiedlichen Rollen soll gemachte Fehler erkennen und beseitigen
  • Erkannte Fehler dürfen/müssen offen kommuniziert werden
  • Das Erkennen von Fehlern ist die Grundlage für die künftige Vermeidung!

Ralf Pinger / Stefan Gerken

6 7 qualit tssicherung von entwicklungswerkzeugen
6.7 Qualitätssicherung von Entwicklungswerkzeugen
  • EN 50128 verlangt:
  • CENELEC-Norm gilt auch für „unterstützende Werkzeuge“
  • „angemessener Satz an Werkzeugen“ soll eingesetzt werden.
  • Automatische Testwerkzeuge und integrierte Entwicklungswerkzeuge werden empfohlen.
  • Werkzeuge und Hilfsmittel sollten zum frühest möglichen Termin verfügbar sein.
  • Software-Werkzeuge müssen für den Zweck geeignet sein.
  • In der Praxis:
  • Werkzeuge mit Validierung, Begutachtung und Zulassung!
  • Werkzeuge ohne Nachweis der Qualifizierung
  • Und alles was dazwischen ist

Ralf Pinger / Stefan Gerken

6 7 qualit tssicherung von entwicklungswerkzeugen1
6.7 Qualitätssicherung von Entwicklungswerkzeugen
  • Neue Version der EN 50128 klassifiziert Werkzeuge
  • T1: Kein direkter oder indirekter Einfluss auf Code: Editoren, Requirements Management Tools
  • T2: Verifikations- und Testwerkzeuge: Fehler im Tool erzeugen keine Fehler im Produkt, aber er bleibt evtl. unentdeckt
  • T3: Output hat direkten oder indirekten Einfluss auf das sicherheitsrelevante System
  • ISO 61508 klassifiziert Werkzeuge nach:
    • Einfluss des Tools auf das Ergebnis (ähnliche T1, T2, T3)
    • Fehleraufdeckung durch nachgelagerte Prozessschritte

Ralf Pinger / Stefan Gerken

6 7 qualit tssicherung von entwicklungswerkzeugen2
6.7 Qualitätssicherung von Entwicklungswerkzeugen
  • Einsatz von Werkzeugen
  • bei Automatisierung manueller Tätigkeiten
  • Aber
  • das Werkzeug besitzt deterministisches Fehlerverhalten
  • der Mensch besitzt stochastisches Fehlerverhalten

Nachgelagerte Qualitätssicherung zum Fehlerfinden

    • keine Qualifizierung von Werkzeugen notwendig!
    • gleicher Prozess wie bei manueller Erstellung der Ergebnisse

Einsparen von Qualitätssicherungsschritten:

 Qualifizierung von Werkzeugen notwendig!

Ralf Pinger / Stefan Gerken

6 7 qualit tssicherung von entwicklungswerkzeugen3
6.7 Qualitätssicherung von Entwicklungswerkzeugen
  • Beispiel: Compiler oder Generator
  • Generator mittels Validierungssuite überprüfen
  • Vorwärts- und Rückwärtsübersetzung mit Vergleich des Ausgangsmaterials
  • Zwei Mal diversitäre Vorwärtsübersetzung mit Ergebnisvergleich
  • Applikationstest mit Abdeckungsmessung auf Ebene des Bytecodes oder Assemblers
  • Generierung der Testfälle aus dem Modell mit Abdeckungsmessung
  • Generierung der Testfälle aus einem Testmodell mit anschließender Abdeckungsmessung
  • Formal beweisbare Übersetzung

Ralf Pinger / Stefan Gerken

6 7 qualit tssicherung von entwicklungswerkzeugen4
6.7 Qualitätssicherung von Entwicklungswerkzeugen
  • Validierungssuite
  • ausführliche Sammlung von Testfällen
  • Bei Unvollständigkeit der Sammlung bleiben ungetestete Situationen übrig.
  • Testendekriterien bleiben genauso entscheidend wie bei den Tests des sicherheitsrelevanten Systems
  • Validierungssuite muss nicht besser sein als ein Test eines sicherheitsrelevanten Systems
  • gängige Praxis bei der Validierung von Compilern

Ralf Pinger / Stefan Gerken

6 7 qualit tssicherung von entwicklungswerkzeugen5
6.7 Qualitätssicherung von Entwicklungswerkzeugen
  • Zwei Mal diversitäre Vorwärtsüber-
  • setzung mit Ergebnisvergleich
  • Setzen G1 und G2 auf denselben Spezifikationen auf?
  • Können G1 und G2 wirklich unabhängig sein?
  • diversitäre Auslegung des Vergleichers?
  • In der Luftfahrt wird diversitäre Vorwärtsentwicklung im first und second level eingesetzt
  • doppelter Transformationsaufwand (Kosten)
  • Validierung der Ergebnisse bei jeder Übersetzung -> keine fehlenden Testfälle

Ralf Pinger / Stefan Gerken

6 7 qualit tssicherung von entwicklungswerkzeugen6
6.7 Qualitätssicherung von Entwicklungswerkzeugen
  • Vorwärts- und Rückwärtsübersetzung
  • mit Vergleich des Ausgangsmaterials
  • Diversität durch unterschiedliche Aufgaben besser gegeben
  • Vergleich diversitär?
  • Falls Transformation nicht eineindeutig ist, kann M‘ nicht wiederhergestellt werden.
  • Evtl. zusätzliche Hilfen notwendig, damit M‘ aus dem Code herstellbar ist.
  • Vergleicher kann mit Intelligenz ausgestattet werden (Äquivalenzvergleich)
  • Validierung mit jeder Übersetzung.
  • Fehler in V mit anschließender Fehlerverschleierung in R relativ unwahrscheinlich -> sehr gute Fehleroffenbarung

Ralf Pinger / Stefan Gerken

6 7 qualit tssicherung von entwicklungswerkzeugen7
6.7 Qualitätssicherung von Entwicklungswerkzeugen
  • Generierung der Testfälle aus dem
  • Modell mit Abdeckungsmessung
  • Generierte Testfälle nur für die Korrektheit des Generators (Gen)
  • Abdeckungsmessung soll die Güte der erzeugten Testfälle dokumentieren und nachweisen (optional).
  • Validierung mit jeder Übersetzung und Testausführung -> keine offenen Testfälle
  • Keine Funktionstests des Modells, die müssen noch gesondert formuliert und durchgeführt werden.

Ralf Pinger / Stefan Gerken

6 7 qualit tssicherung von entwicklungswerkzeugen8
6.7 Qualitätssicherung von Entwicklungswerkzeugen
  • Applikationstest mit Abdeckungs-
  • messung auf Ebene des Bytecodes
  • oder Assemblers
  • Generierte Code wird mit Testfällen aus der Validierung abgedeckt
  • keine offene Funktionalität im Code vorhanden, da Testabdeckung gemacht
  • Test der Generierung wird mit den ohnehin notwendigen Funktionstests kombiniert -> Einsparung intensiver Generator-Tests
  • Abdeckungsmessungen können sehr aufwändig sein, bei sehr viel generiertem Code
  • Abdeckungsmessungen können manuelle Argumentation für nicht abgedeckte Testfälle haben -> aufwändig

Ralf Pinger / Stefan Gerken

6 7 qualit tssicherung von entwicklungswerkzeugen9
6.7 Qualitätssicherung von Entwicklungswerkzeugen
  • Generierung der Testfälle aus einem
  • Testmodell mit anschließender
  • Abdeckungsmessung
  • ähnlich voriges Beispiel, allerdings werden die Testfälle aus einem separaten Testmodell erzeugt.
  • impliziter Funktionstest des Systems
  • korrekte Generierung wird über die korrekte Testausführung nachgewiesen
  • doppelter Modellierungsaufwand (Modell + Testmodell)
  • Abdeckungsmessung weist Güte der generierten Testfälle nach
  • Abgleich zwischen Modell und Testmodell kann anhand der Abdeckungsmessungen schwierig sein

Ralf Pinger / Stefan Gerken

6 7 qualit tssicherung von entwicklungswerkzeugen10
6.7 Qualitätssicherung von Entwicklungswerkzeugen
  • Formal beweisbare Übersetzung
  • Korrektheit der Übersetzung anhand eines formalen Nachweises auf der Ebenen der Sprachdefinitionen
  • Formale Semantik der Sprachen notwendig
  • Evtl. aufwändige Nachweise notwendig
  • bisher noch keine industrielle Anwendung in der Breite möglich (Forschungsgegenstand)

Ralf Pinger / Stefan Gerken

ad