Software in sicherheitsrelevanten systemen
Download
1 / 150

Software in sicherheitsrelevanten Systemen - PowerPoint PPT Presentation


  • 56 Views
  • Uploaded on

Software in sicherheitsrelevanten Systemen. Ralf Pinger Sommersemester 2009. Stundenzahl: 2V + 1Ü Vorlesung: Do. 08:00 - 09:30 Uhr in IZ 161 Do, 07.05.08 Do, 14.05.09 Do, 28.05.09 Blockveranstaltung Exkursionswoche 02. - 05.06.2009 Do, 11.06.09 Do, 25.06.09 Do, 02.07.09

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


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
Software in sicherheitsrelevanten systemen

Software in sicherheitsrelevanten Systemen

Ralf Pinger

Sommersemester 2009

SW in sicherheitsrelevanten Systemen


Organisatorisches

Stundenzahl: 2V + 1Ü

Vorlesung:Do. 08:00 - 09:30 Uhr in IZ 161

Do, 07.05.08

Do, 14.05.09

Do, 28.05.09

Blockveranstaltung Exkursionswoche 02. - 05.06.2009

Do, 11.06.09

Do, 25.06.09

Do, 02.07.09

Do, 09.07.09

Block:

VL + UE vom 02.06. – 05.06.

(Ex-Woche):

Di 02.06.: 8:00 - 16:00

Mi 03.06.: 8:00 - 16:00

Do 04.06.: 8:00 - 16:00

Fr 05.06.: 8:00 - 11:30

Inhalt: praktischer Umgang mit SCADE

Schulung erfolgt durch Esterel

Sprechstunde: nach Vereinbarung

Prüfung: nach Vereinbarung

Kontakt: [email protected]

Organisatorisches

SW in sicherheitsrelevanten Systemen


Inhalt
Inhalt

  • Motivation

  • RAMS/Normen

  • SCADE/modellbasierte Entwicklung

  • Qualifizierung von Entwicklungswerkzeugen

SW in sicherheitsrelevanten Systemen


1 motivation
1. Motivation

  • Zusammenstoß zweier S-Bahnen im Bahnhof Flughafen Hannover-Langenhagen, 29.06.00

SW in sicherheitsrelevanten Systemen


Signal
Signal

  • übermittelt Erlaubnis zur Einfahrt

  • übermittelt erlaubte Geschwindigkeit

SW in sicherheitsrelevanten Systemen


Weiche
Weiche

SW in sicherheitsrelevanten Systemen


Pzb indusi
PZB – Indusi

  • Punktförmige Zugbeeinflussung - PZB (induktive Zugsicherung)

  • Vermeidung von Gefährdungen und Unfällen durch Zwangsbremsung

  • Übertragung der Signalstellung an der Strecke auf das Fahrzeug

  • punktförmig, da nur an bestimmten Punkten eine Beeinflussung stattfinden kann

  • PZB lediglich Unterstützung des Fahrers

SW in sicherheitsrelevanten Systemen


Funktionen der pzb indusi
Funktionen der PZB/Indusi

  • Die Wachsamkeitsprüfung überwacht, dass der Triebfahrzeugführer (Tf) beim Passieren eines Halt ankündenden Signals die Aufnahme des Signalbegriffs durch eine Tastenbedienung bestätigt.

  • Die Bremswegüberwachung überwacht den Bremsvorgang vor einem Halt zeigenden Signal. Dies erfolgt fahrzeugseitig durch diskrete Prüfpunkte (bei Altsystemen) oder kontinuierliche Überwachungskurven.

  • Die Fahrsperre löst beim Passieren eines Halt zeigenden Signals eine Zwangsbremsung aus.

SW in sicherheitsrelevanten Systemen


Bertragungsprinzip indusi
Übertragungsprinzip Indusi

SW in sicherheitsrelevanten Systemen


Sicherungsstufen pzb indusi
Sicherungsstufen PZB/Indusi

  • 500-Hz-Magnete 250 bis 150 m vor Hauptsignalen, die besondere Gefahrenpunkte decken.-> falls zu schnell dann Zwangsbremsung (ZB)

  • 1000-Hz-Magnet am Vorsignal bzw. Überwachungssignal eines Bahnübergangs-> Wachsamkeitstaste innerhalb 4 s, sonst ZB-> falls zu schnell dann ZB

  • 2000-Hz-Magnet am Hauptsignal-> immer ZB

SW in sicherheitsrelevanten Systemen


Franz sische alternative zur indusi
Französische Alternative zur Indusi

  • Krokodil (1920er Jahre)

  • Signalbegriff wird als positive oder negative Spannung dargestellt (+/- 20 V)

SW in sicherheitsrelevanten Systemen


Alternativen zur indusi
Alternativen zur Indusi

  • Eurobalisen

  • komplexere Datenübertragung möglich (mehrere Bytes)

SW in sicherheitsrelevanten Systemen


Live-Demo Zugsicherung(am Beispiel der belgischen Bahn)

SW in sicherheitsrelevanten Systemen


Randbedingungen
Randbedingungen

  • 5711 stand ab 09:53 Uhr abfahrbereit vor Ausfahrsignal, geplante Abfahrt 10:10 Uhr

  • 5712 hat 7 Minuten Verspätung, erwartete Ankunftszeit 10:11 Uhr

  • 5712 erhält Erlaubnis zur Einfahrt in Bahnhof

  • 5711 steht vor Halt zeigendem Signal!

SW in sicherheitsrelevanten Systemen


Ausgangssituation
Ausgangssituation

SW in sicherheitsrelevanten Systemen


Was ist passiert
Was ist passiert?

  • 5711 startet um 10:10 Uhr

  • Ausfahrsignal für 5711 stand auf Halt

  • Indusi erzeugt Zwangsbremsung für 5711

  • Tf von 5711 drückt Freitaste und fährt wieder los!

  • 5711 fährt die Einfahrweiche auf

  • 5712 war zu diesem Zeitpunkt schon an seinem Einfahrsignal vorbei -> keine ZB mehr möglich!

  • Noch im Tunnel stoßen 5711 und 5712 frontal zusammen!

SW in sicherheitsrelevanten Systemen


Unfallfolgen
Unfallfolgen

  • 16 Personen verletzt

  • 3.600.000 DM Sachschaden

  • Wiederinbetriebnahme der Strecke erst am 30.06.00, 04:00 Uhr, einen Tag später

SW in sicherheitsrelevanten Systemen


Fazit
Fazit

  • keine kausale Beteiligung technischer Komponenten/Einrichtungen

  • 5711 erhielt Zwangsbremsung

  • Ursache:unerlaubte Weiterfahrt von 5711

  • Auszug aus Regelwerk:

    „Ist ein Zug an einem Halt zeigenden Hauptsignal (...) unzulässig vorbeigefahren, ist nach dem Anhalten der Fahrdienstleiter sofort zu verständigen. Dies gilt auch bei einer Zwangsbremsung durch PZB an einem Hauptsignal (...), das eine Fahrtstellung (...) zeigt.“

    Menschliches Versagen als Ursache

SW in sicherheitsrelevanten Systemen


Fazit 2
Fazit 2

  • System hat die Fehlhandlung des Triebfahrzeugführers erkannt und hat eingegriffen

  • nach erfolgter technischer Reaktion übernimmt der Mensch wieder die Verantwortung!

  • offenbar hat der Mensch die Zwangsbremsung nicht dem Hauptsignal zugeordnet!

SW in sicherheitsrelevanten Systemen


Gr nde f r zwangsbremsung
Gründe für Zwangsbremsung

  • Indusi am Halt-Signal (Indusi)

  • Sicherheitsfahrschalter (Sifa) – Totmannknopf

  • Zurückrollen des Zuges

  • Störung im Fahrzeuggerät

  • Zwangsbremsung unbekannter Ursache

SW in sicherheitsrelevanten Systemen


Menschliches versagen
menschliches Versagen?

  • Ist das menschliche Versagen vorprogrammiert?

  • 22 aktenkundige Fälle zwischen 1994 und 2000: Tf fährt nach Zwangsbremsung durch Indusi unerlaubt weiter!

  • Forderung nach optischer Signalisierung bei „ZB durch Indusi“

    Systeme müssen von Menschen beherrscht werden können!

SW in sicherheitsrelevanten Systemen



Zweites beispiel genthin 1939
zweites Beispiel – Genthin 1939

  • 22.12.1939: D10 Berlin – Köln fährt in Brandenburg Reichsbahn mit 12 Minuten Verspätung ab (viele Reisende, lange Zeit für Aus- und Einsteigen)

  • D10 muss bei Kade halten, da sich im Abschnitt davor (Genthin) noch der Militärzug 176 befindet

  • D10 hat damit 27 Minuten Verspätung

SW in sicherheitsrelevanten Systemen


Ungl ck von genthin
Unglück von Genthin

  • D 180 Berlin Neunkirchen (Saar) folgt D10

  • D 180 lief auf und wurde mehrfach „gestutzt“ (Vorsignal auf Halt, Hauptsignal dann aber auf Fahrt)

  • Lokführer von D 180 „übersieht“ im Nebel Halt zeigendes Vorsignal und Hauptsignal bei Belicke

  • Fahrdienstleiter gibt Haltsignale und benachrichtigt Schrankenbude 89 und Stellwerkswärter in Genthin Ost

SW in sicherheitsrelevanten Systemen


Fahrt nach genthin
Fahrt nach Genthin

  • D 180 sieht nun nur noch „Fahrt“-Signale – die von D 10!

  • Wärter in Schrankenbude 89 schwenkt Kreiselsignal („Halt“), Knallkapseln konnte er nicht mehr auslegen

  • Lokführer sieht den Wärter nicht, da dieser zu tief steht

  • Wärter in Genthin Ost könnte D 180 noch stoppen – er hat höhere Position

SW in sicherheitsrelevanten Systemen


In genthin ost
In Genthin Ost

  • Stellwerkswärter reagiert überstürzt auf Meldung vom Blockwärter Belicke

  • Gibt Schutzhaltesignal mit elektrischer Signallampe (kreisförmig schwingend)

  • Er vergisst die Signale auf Halt zu stellen

  • D 10 sieht die Warnlampe, die für D 180 bestimmt war

  • D 10 leitet Schnellbremsung ein

  • D 180 hat „Fahrt-frei“ nach Genthin (von D10)

SW in sicherheitsrelevanten Systemen


Unfall folgen
Unfall Folgen

  • D 180 fährt mit 100 km/h auf den im Bahnhof stehenden D 10 auf

  • 186 Menschen sterben

  • 106 Menschen verletzt

    Größte Eisenbahnkatastrophe in Deutschland

  • weiterer Unfall in derselben Nacht mit 101 Toten, 28 Verletzten)

SW in sicherheitsrelevanten Systemen


Ursachen
Ursachen

  • menschliches Versagen des Lokführers von D 180 (Halt-Signal übersehen)

  • menschliches Versagen des Stellwerkwärter Genthin Ost – Verwechselung von D 10 mit D 180, keine Signal-Halt-Stellung

    Kette von menschlichen Fehlleistungen führte zum Unfall

SW in sicherheitsrelevanten Systemen


Ursachen 2
Ursachen 2

  • Indusi bereits in den 20er Jahren erprobt

  • 1939 war die Indusi schon weit verbreitet

  • Strecke war mit Indusi-Spulen ausgestattet

  • Einrichtung an der Lok von D 180 fehlte, da zur Reparatur!

  • Aufgrund von Lokmangel (Kriegszeiten) wurde die Lok trotzdem eingesetzt!

    menschliches Versagen?

  • Zwangsbremsung hätte Zugunglück verhindert!

  • Lokführer bekam 3 Jahre Gefängnis!

SW in sicherheitsrelevanten Systemen


Einfluss von software auf unf lle
Einfluss von Software auf Unfälle

  • reine Software-Fehler können ebenfalls Ursachen für Katastrophen sein

  • Beispielsweise Fehlfunktion im Fahrzeuggerät -> keine Bremsung

  • Funktioniert die Software beim automatischen Fahren?

  • Kann man überlappende Fahrstraßen im Stellwerk einstellen?

SW in sicherheitsrelevanten Systemen


Beispiele für SW-Fehlverhalten

Kincardine in Ontario, Kanada, Schwerer Reaktorunfall 1990

ausgelöst durch einen Softwarefehler:

Beim Austausch eines abgebrannten Brennelementes geriet die computer-gesteuerte Umlademaschine in einen unkontrollierten Zustand. Als sie sich 40 cm über dem Schachtdeckel befand, wurden durch einen falschen Befehl im Code des Computers, der die Umlademaschine kontrollierte, zugleich alle 4 Bremsen des Hebezuges gelöst und das schwere Gerät fiel auf die Schachtabdeckung. Die Folge war der Austritt von 12.000 I hoch-radioaktivem schweren Wasser aus dem Leck, das in den Brennstoff-behälter geschlagen worden war.

SW in sicherheitsrelevanten Systemen


Beispiele f r sw fehlverhalten
Beispiele für SW-Fehlverhalten

Thule, Grönland, 1960

In der US-Frühwarnstation wird

höchste Alarmstufe ausgelöst.

Durch einen Computerfehler wurde der Mondaufgang als "Nuklearangriff" gewertet.

Ähnliche Fehler waren in der Folgezeit des Öfteren die Ursache für die Menschheit bedrohende Fehlalarme (in einem Fall wurden Wildgänse als einfliegende Formationen von Atomsprengköpfen missdeutet).

SW in sicherheitsrelevanten Systemen


Beispiele f r sw fehlverhalten1
Beispiele für SW-Fehlverhalten

Die Objektiv-Linsen der Weltraum-sonde "Hubble" wichen nach einem computergesteuerten Schliff um einige zehntel Millimeter von der optimalen Krümmung ab. Der Fehler lag in der Programmierung der Schleifmaschine. Das Teleskop war daher nach dem Start in den Weltraum nur sehr einge-schränkt zu gebrauchen, lieferte zum großen Teil unscharfe Bilder. Ihm musste in einer Rettungsaktion, die Unsummen verschlang, im Weltraum eine 'Brille' verpasst werden, um die optimale scharfe Leistung wiederzugewinnen. Nur so konnte der Erfolg des gesamten Systems noch gerettet werden.

SW in sicherheitsrelevanten Systemen


Software f r sicherheitsrelevante systeme
Software für sicherheitsrelevante Systeme

  • Wie entwickelt man Software, die in sicherheitsrelevanten Systemen ausgeführt wird?

  • Nicht Inhalt dieser VL:

    • Entwicklung der Hardware

    • Entwurf sicherheitsrelevanter Betriebskonzepte

SW in sicherheitsrelevanten Systemen


Definition system
Definition System

Ein Beispiel:

  • system:

    set of sub-systems or elements which interact according to a design

  • sub-system:

    portion of a system which fulfils a specialisedfunction.

  • function:

    A mode of action or activity by which a product fulfils its purpose.

  • element:

    a part of a product that has been determined to be a basic unit or building block. An element may be simple or complex.

  • Problem: Die Definition von Begriffen wie System oder Funktion ist willkürlich,

    ... und wahrscheinlich wird niemals eine universelle Definition gelingen.

SW in sicherheitsrelevanten Systemen


Definition system1
Definition System

Aber:

Die Hauptaufgabe ist die Entwicklung hinreichend gefährdungsfreier Produkte. Die Sicherheit sollte nicht davon abhängen, ob eine Funktion von einem „System” oder „Element” erbracht wird.

  • Der Benutzer muss das zu betrachtende „System” klar und eindeutig definieren.

SW in sicherheitsrelevanten Systemen


Definition system2
Definition System

Ein (Sub-)System zeichnet sich dadurch aus,

  • dass es sich von der Umgebung abgrenzen lässt (also Systemgrenze und Schnittstellen bekannt sind), und

  • dass es eine wohldefinierte (beabsichtigte) Funktion erbringen soll

SW in sicherheitsrelevanten Systemen


Definition system3
Definition System

SW in sicherheitsrelevanten Systemen


Definition system4
Definition System

  • Checkliste:

    • Ist die Systemgrenze klar definiert?

    • Sind an der Systemgrenze die Schnittstellen definiert?

    • Sind die Ein- und Ausgaben auf diesen Schnittstellen definiert?

    • Ist die Aufgabe, die das System erfüllen soll, klar definiert?

    • Sind die Einsatzszenarien bekannt und dokumentiert?

    • Ist die Systemstruktur bzw. Systemarchitektur dargestellt?

    • Sind die einzelnen Architekturelemente definiert?

    • Ist ihr Zusammenwirken eindeutig definiert?

SW in sicherheitsrelevanten Systemen


Scade schulung
SCADE-Schulung

  • Zeit: 02.06.- 05.06.2009,9:00 Uhr – 17:00 Uhr

  • Ort: Siemens AG, Ackerstraße 22

  • Raum: Gebäude 37, Raum 37235

    bitte melden beim Eingang Ost, der Raum ist im Erdgeschoss rechts den Gang hinunter und dann auf der linken Seite

SW in sicherheitsrelevanten Systemen


Lageplan siemens ag
Lageplan Siemens AG

SW in sicherheitsrelevanten Systemen


Definition ramss
Definition RAMSS

SW in sicherheitsrelevanten Systemen


Zusammenhang zwischen ram s und s
Zusammenhang zwischen RAM, S und S

SW in sicherheitsrelevanten Systemen


Definitionen von sicherheit
Definitionen von Sicherheit

Sicherheit nach Mü8004: “Die Fähigkeit einer Sicherungsanlage, bei

  • bestimmungsgemäßem Einsatz,

  • ordnungsgemäßer Instandhaltung und

  • vorschriftsmäßiger Handhabung

    während einer vorgegebenen Brauchbarkeitsdauer

    Gefährdungen durch Funktionsversagen

    in dem Umfang, der nach dem Stand der Technik erforderlich ist,

    auch dann zu verhindern, wenn Bauelementeausfälle und Störungen in der zu Beanspruchungsbeginn als fehlerfrei angesehenen Sicherungsanlage eintreten.”

     D. h. eine Anlage ist (im Sinne der Mü8004) sicher oder nicht.

    Sicherheit nach CENELEC: Freiheit von nicht akzeptierten Risiken.

SW in sicherheitsrelevanten Systemen


Military standard
MILITARY-STANDARD

  • MIL-STD-882

  • System Safety: The application of engineering and management principles, criteria, and techniques to optimize all aspects of safety within the constraints of operational effectiveness, time, and cost throughout all phases of the system life cycle.

  • Software System Safety Handbook (MIL-STD)

  • Purpose: Provide management and engineering guidelines to achieve a reasonablelevel of assurance that software will execute within the system context with an acceptable level of safety risk.

SW in sicherheitsrelevanten Systemen


Sicherheit probleme
Sicherheit: Probleme

  • Wie sicher sind die Komponenten bzw. Anlagen?

  • Wie sicher müssen die Komponenten bzw. Anlagen sein?

  • Wie kann die Sicherheit glaubhaft gemacht werden?

  • Warum ist die eingesetzte SW/HW frei von systematischen Fehlern?

SW in sicherheitsrelevanten Systemen


Was bedeutet ramss f r eisenbahnsignaltechnik
Was bedeutet RAMSS für Eisenbahnsignaltechnik?

  • Zwingend notwendige Produkteigenschaften, ohne Nachweis sind die Produkte nicht marktfähig

  • Funktionsversagen kann katastrophale Folgen haben (Unfälle)

  • Mangelnde Verfügbarkeit wird pönalisiert

  • Das behauptete Sicherheitsniveau ist weder durch Gebrauch noch Test positiv nachweisbar

  • Security wird bisher als Problem unterschätzt

SW in sicherheitsrelevanten Systemen


Klassifikation von fehlern
Klassifikation von Fehlern

  • Zufällige Fehler

    • Hardwarefehler als Folge von Alterung

    • Verschleiß

    • ausgefallene Transistoren

  • Systematische Fehler

    • mangelhafter Entwurf

    • Programmierfehler

    • mangelhafte Auslegung der Hardware

  • Unterscheidung

    • systematische Fehler treten nach Beseitigung nicht mehr auf

    • zufällige Fehler können sich jederzeit wiederholen

      Übergang kann fließend sein: Unterdimensionierter Kühlkörper eines Transistors

SW in sicherheitsrelevanten Systemen


Klassifikation von fehlern 2
Klassifikation von Fehlern 2

  • Hardware: zufällige und systematische Fehler

  • Software:nur systematische Fehler möglich!

  • In dieser VL:Entwicklung von Software, die für die Ausführung auf einer Hardware gedacht ist, die sich für die Ausführung von Sicherheits-Funktionen eignet.

  • geeignete Hardware: Erkennen von zufälligen Fehlern!Anschließend: Sicheren Zustand einnehmen

SW in sicherheitsrelevanten Systemen


Rechnerarchitektur 1oo1d
Rechnerarchitektur 1oo1D

SW in sicherheitsrelevanten Systemen


Eigenschaften von 1oo1d
Eigenschaften von 1oo1D

  • Diagnosekomponente ist eine Selbstprüfung

  • Falls ein Fehler erkannt wird, erfolgt die Ausführung einer Sicherheitsfunktion (z. B. Abschalten, eingeschränkte Funktion, etc)

  • Fehlerhafte Ausgaben werden nicht sofort unwirksam (Diagnose muss erst arbeiten!)

  • Gemeinsame HW für Haupt- und Prüfprogramm: Was passiert wenn beide gleichermaßen versagen? Common Cause (gleiche Ursache für denselben Fehler)

  • Überprüfung kann auch auf evtl. vorhanden Ausgabebaugruppen verlagert werden

  • Geringe Kosten der HW

SW in sicherheitsrelevanten Systemen


Rechnerarchitektur 1oo2
Rechnerarchitektur 1oo2

SW in sicherheitsrelevanten Systemen


Eigenschaften von 1oo2
Eigenschaften von 1oo2

  • Verdoppelung der HW

  • zufälliger Fehler einer HW-Komponente kann erkannt werden

  • fehlerhafte Ausgaben werden unterdrückt

  • Sicherheitsfunktion muss bei Abweichung ausgeführt werden

  • Kanäle müssen synchron gehalten werden

  • Reduktion von common cause Fehlern

SW in sicherheitsrelevanten Systemen


Rechnerarchitektur 2oo2
Rechnerarchitektur 2oo2

SW in sicherheitsrelevanten Systemen


Eigenschaften von 2oo2
Eigenschaften von 2oo2

  • ähnlich 1oo2

  • fehlerhafte Ausgaben werden unterdrückt

  • Sicherheitsfunktion wird erst beim Erkennen eines Fehlers in beiden Vergleichern ausgeführt! Weiterlaufen mit einem Kanal theoretisch möglich

  • Es kann nicht erkannt werden, welcher Kanal den Fehler hat!

  • Warnung notwendig, da nicht klar ob mit fehlerhaften Daten gearbeitet wird

  • Kanäle müssen synchron gehalten werden

  • Reduktion von common cause Fehlern

SW in sicherheitsrelevanten Systemen


Rechnerarchitektur 1oo2d
Rechnerarchitektur 1oo2D

SW in sicherheitsrelevanten Systemen


Eigenschaften von 1oo2d
Eigenschaften von 1oo2D

  • Verdoppelung von 1oo1D

  • Erkennen des fehlerhaften Kanals unter Einschränkungen von 1oo1D

  • fehlerhafte Ausgaben werden unterdrückt

  • fehlerhaften Kanal abschalten, weiterarbeiten nach erstem Fehler möglich

  • Kanäle müssen synchron gehalten werden

SW in sicherheitsrelevanten Systemen


Rechnerarchitektur 2oo3
Rechnerarchitektur 2oo3

SW in sicherheitsrelevanten Systemen


Eigenschaften von 2oo3
Eigenschaften von 2oo3

  • Verdreifachung der HW

  • Fehlerhafter Kanal kann erkannt werden

  • Weiterarbeiten nach erstem Fehler möglich

  • Synchronisation noch schwieriger

SW in sicherheitsrelevanten Systemen


Rechnerarchitektur xooy
Rechnerarchitektur XooY

  • genannten Prinzipien sind nur Beispiele und können beliebig erweitert bzw. verändert werden

  • Notwendigkeit der einzusetzenden Architektur sollte aus einer Risiko-Analyse abgeleitet werden

  • Vollständige Zweikanaligkeit verringert common cause Ausfälle

  • Hohes Maß an Ausfalloffenbarung durch Zwei- bzw. Mehrkanaligkeit möglich

  • Durch HW-Vergleicher extrem schnelle Ausfalloffenbarung möglich

  • Durch Symmetrie und HW-Synchronisation sieht der Programmierer in der Regel nur einen Kanal

  • Unabhängiges Abschalten durch Vergleicher möglich

  • Natürlich können auch die Übertragungsmedien mehrkanalig ausgelegt werden!

SW in sicherheitsrelevanten Systemen


Allgemeines zu mehrkanaligkeit
Allgemeines zu Mehrkanaligkeit

  • Probleme:

    • Enge Synchronisation und dichte Nachbarschaft der Kanäle machen das System empfindlich für common cause Einflüsse:

    • Einflüsse über die Peripherie

    • Einflüsse über die Stromversorgung

    • Elektromagnetische Felder

    • Temperatur (von außen, aber auch durch Nachbarkanal)

  • Gegenmaßnahmen

    • „Sichere“ Trennung der Peripherie vom Rechnerkern

    • Hoch überwachte Stromversorgung

    • Hochwirksame Schirmung

SW in sicherheitsrelevanten Systemen


Definition software
Definition Software

Intellektuelle Schöpfung, die Programme, Verfahren, Regeln und alle dazugehörige Dokumentation umfasst, die zum Betrieb eines Systems gehören.

Anmerkung: Software ist unabhängig vom verwendeten Transportmedium

englische Übersetzung

intellectual creation comprising the programs, procedures, rules and any associated documentation pertaining to the operation of a system.

NOTE: Software is independent of the media used for transport

  • Quelle: EN 50128

SW in sicherheitsrelevanten Systemen


Fehler in software
Fehler in Software

  • Software hat keine zufälligen Fehler, nur systematische Fehler!

  • Gibt es nichttriviale fehlerfreie Software?

  • RAMS-Eigenschaften von Software sind nicht quantifizierbar!

    -> im Gegensatz zu Hardware

SW in sicherheitsrelevanten Systemen


Fishbone analysis zur identifikation von gr nden f r softwarefehler
Fishbone Analysis zur Identifikation von Gründen für Softwarefehler

Quelle: A Software Fault Prevention Approach in Coding and Root Cause Analysis

Weider D. Yu

SW in sicherheitsrelevanten Systemen


Cenelec nach 50129
CENELEC nach 50129

Da es nicht möglich ist, die Sicherheit gegen systematische Fehler mit quantitativen Methoden zu bestimmen, werden Sicherheitsanforderungsstufen verwendet, innerhalb derer Methoden, Werkzeuge und Techniken gruppiert werden, die – wenn sie richtig angewendet werden – ein angemessenes Maß an Vertrauen in die Realisierung eines Systems liefern, das die vorgegebene Sicherheitsanforderungsstufe erfüllt.

SW in sicherheitsrelevanten Systemen


Sicherheitsanforderungsstufen f r software ssas
Sicherheitsanforderungsstufen für Software (SSAS)

  • SSAS = SIL der Systemfunktionen

  • 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 unterschiedlichen SSAS innerhalb eines Systems

SW in sicherheitsrelevanten Systemen


Software und sicherheit
Software und Sicherheit

SW-Anforderungen

SW Architektur und Design

SW Implementierung und Test

SW-Abnahme / Zulassung

SW in sicherheitsrelevanten Systemen


Eingliederung der en50128
Eingliederung der EN50128

CENELEC-Normen

EN 50126

EN 50159

Eisenbahnsystem

Eisenbahnsignalsystem

EN 50129

Teilsystem Software

EN 50128

SW in sicherheitsrelevanten Systemen


Anwendungsbereich
Anwendungsbereich

  • Verfahren und technische Anforderungen für die Entwicklung

  • gesamter Bereich der Sicherheitsanwendungen

  • gilt für jegliche Software, die bei der Entwicklung und Realisierung von 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.: ladder logic bei speicherprogrammierbaren Steuerungen).

  • gilt nicht rückwirkend (Ausnahme Wartung bei umfangreichen Änderungen)

SW in sicherheitsrelevanten Systemen


Aufbau der norm
Aufbau der Norm

  • Normativer Textteil

  • Normativer Anhang A

  • Informativer Anhang B

Normativer Text

Kapitel

Anhang A

Referenzen (B.nn)

Auswahllisten zu

Methoden, Maßnahmen

und Tools

Anhang B

Informationen zu

Methoden und Tools

SW in sicherheitsrelevanten Systemen


Beispiel 1 normativer textteil
Beispiel 1: Normativer Textteil

8 Software-Anforderungsspezifikation

8.1 Ziele

8.1.1 Beschreiben eines Dokumentes, das einen vollständigen Satz von Anforderungen an die Software definiert, der alle Systemanforderungen in dem durch die Software-Sicherheitsanforderungsstufe festgelegten Umfang erfüllt. Es soll ein derart umfassendes Dokument für jeden Software-Ingenieur sein, daß es für ihn nicht erforderlich ist, zum Thema Anforderungen in irgendeinem anderen Dokument nachzusehen.

8.1.2 Beschreibung der Software-Anforderungstestspezifikation.

8.2 Eingangsdokumente

1) System-Anforderungsspezifikation ...

8.3 Ausgangsdokumente

1) Software-Anforderungsspezifikation

2) Software-Anforderungstestspezifikation

8.4 Anforderungen

8.4.1 Die Software-Anforderungsspezifikation muß die erforderlichen Eigenschaften der zu entwickelnden Software zum Ausdruck bringen und nicht die Verfahren, sie zu entwickeln. Diese Eigenschaften, die alle (außer der Sicherheit) in ISO/IEC 9126 definiert sind, müssen einschließen:

...

SW in sicherheitsrelevanten Systemen


Beispiel 1 aus anhang a
Beispiel 1 aus Anhang A

SW in sicherheitsrelevanten Systemen


Beispiel 1 aus anhang b
Beispiel 1 aus Anhang B

  • B.14 Entscheidungstabellen (Wahrheitstabellen) (en: Decision Tables (Truth Tables)) (zu Abschnitt 14 und D.7)

  • 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 booleschen 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.

SW in sicherheitsrelevanten Systemen


Beispiel 2 aus anhang a
Beispiel 2 aus Anhang A

SW in sicherheitsrelevanten Systemen


Beispiel 2 aus anhang a fortsetzung
Beispiel 2 aus Anhang A (Fortsetzung)

SW in sicherheitsrelevanten Systemen


Beispiel 2 aus anhang a fortsetzung1
Beispiel 2 aus Anhang A (Fortsetzung)

SW in sicherheitsrelevanten Systemen


Beispiel 2 aus anhang a fortsetzung2
Beispiel 2 aus Anhang A (Fortsetzung)

SW in sicherheitsrelevanten Systemen


Proze
Prozeß

Phase

Ergebnisse

Ver

Val

SW in sicherheitsrelevanten Systemen


Proze1

Software Architektur & Entwurfsphase

Software-Architekturspezifikation

Software-Entwurfsspezifikation

Software-Entwurfstestspezifikation

_______________________________________________

Software-Architektur und -Entwurfsverifikationsbericht

Software-Integrationsphase

____________________________

Software-Integrationstestbericht

Software-Validierung

_________________________

Software-Validationsbericht

Software-Begutachtungsphase

_______________________________

Software-Gutachten

Software/Hardware-Integrationsphase

______________________________________

Software/Hardware-Integrationstestbericht

Software-Modulentwufsphase

Software-Modulentwufsspezifikation

Software-Modultestspezifikation

_______________________________

Software-Modulverifikationsbericht

Prozeß

Software-Planungsphase

Software-Entwicklungsplan

Software-Qualitätssicherungsplan

Software-Konfigurationsmgm.-Plan

Software-Verifikationsplan

Software-Integrationsplan

Software/Hardware-Integrationsplan

Software-Validationsplan

Software-Wartungsplan

Software-Anforderungsspezifikationphase

Software-Anforderungsspezifikation

Software-Anforderungstestspezifikation

Software-Anforderungsverifikationsbericht

System-Anforderungsspezifikation

System-Sicherheitsanforderungsspezifikation

System-Architekturbeschreibung

System-Sicherheitsplan

Software-Modultestphase

______________________

Software-Modultestbericht

Software-Wartungsphase

___________________________________

Software-Wartungsaufzeichnungen

Software-Wartungsprotokoll

Phase

Ergebnisse

Ver

Val

SW in sicherheitsrelevanten Systemen


Proze2
Prozeß

Ver

Val

Phase

Ergebnisse

SW in sicherheitsrelevanten Systemen


Dokumente ergebnisse
Dokumente / Ergebnisse

  • Definitionen / Anforderungen zu den Phasen des Lebenszyklus‘ (Textteil)

  • Vorgaben von Maßnahmen und Tools (Anhang A)

  • Vorgaben zu Reviews (Verifikation)

  • Verfolgbarkeit der Anforderungen

SW in sicherheitsrelevanten Systemen


Rollen und unabh ngigkeiten
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

SW in sicherheitsrelevanten Systemen


Aufgaben und rollen
Aufgaben und Rollen

SW in sicherheitsrelevanten Systemen


Verifikation und validation

Verifikation: Analyse und Testen um festzustellen, ob das Ausgangsprodukt jeder Phase des Lebenszyklus die Anforderungen aus der vorhergehenden Phase erfüllt.

Draft EN50128, Feb. 1998

Validation: Analyse und Testen zur Demonstration, daß das Produkt in allen Belangen seine spezifizierten Anforderungen erfüllt.

Draft EN50128, Feb. 1998

Verifikation und Validation

Wird richtig entwickelt

Ist das Richtige

entwickelt worden?

SW in sicherheitsrelevanten Systemen


Anwendungsspezifisch konfigurierbare systeme
Anwendungsspezifisch konfigurierbare Systeme

SW in sicherheitsrelevanten Systemen


Anwendungsspezifisch konfigurierbare systeme1
Anwendungsspezifisch konfigurierbare Systeme

SW in sicherheitsrelevanten Systemen


Begutachtung
Begutachtung

  • Vorgaben der Maßnahmen zur Begutachtung (Anhang A)

  • Entwicklungsbegleitende Begutachtung

    • Zustimmung zum SW-Validierungsplan

    • Zustimmung zu den Maßnahmen (Anhang A) der Entwicklung

    • Zusätzliche Verifikations-/Validationsschritte

Analyseprozeß zur Feststellung, ob die Entwurfsinstanz und der Validierer ein

Produkt zustande gebracht haben, das die spezifizierten Anforderungen erfüllt und um zu beurteilen, ob das Produkt für seinen gedachten Anwendungszweck geeignet ist.

To evaluate that the lifecycle processes and products resulting are such that the software is of the defined software safety integrity level and is fit for its intended use.

SW in sicherheitsrelevanten Systemen


Begutachtung im entwicklungsproze
Begutachtung im Entwicklungsprozeß

Begutachten

Begutachten

Begutachten

Zustimmung

Begutachten ab SIL 3

Begutachten ab SIL 3

Begutachten ab SIL 3

Begutachten ab SIL 3

Begutachten ab SIL 3

Begutachten

Verifikation

Validierung

Begutachten

SW in sicherheitsrelevanten Systemen


Zusammenfassung en 50128
Zusammenfassung EN 50128

  • Vorgaben für den Entwicklungsprozeß

  • Festlegung von Maßnahmen und Tools

  • Anforderungen an Dokumente

  • Unabhängige Stellen

SW in sicherheitsrelevanten Systemen


Modellbasierte entwicklung
Modellbasierte Entwicklung

SW in sicherheitsrelevanten Systemen


Urspr nge der modellbasierten entwicklung
Ursprünge der modellbasierten Entwicklung

  • 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

  • SW in sicherheitsrelevanten Systemen


    Was ist modellbasierte entwicklung
    Was ist modellbasierte Entwicklung?

    • Modellbasierte Entwicklung definiert:

    • n Hierarchieebenen

    • auf jeder Ebene eine (formale, domänenspezifische) abstrakte Sprache

    • Transformationen zwischen den Hierarchieebenen

    • möglichst weitgehende Automatisierung der Transformationen

    SW in sicherheitsrelevanten Systemen


    Motivation f r modellbasierte entwicklung
    Motivation für modellbasierte Entwicklung

    • 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 Analysewerkzeuge (z.B. Model Checker)  Nachweis von Sicherheitseigenschaften

    • Unterstützung der Zertifizierung von Systemen

    SW in sicherheitsrelevanten Systemen


    Begriff mda und abgrenzung 1
    Begriff „MDA“ und Abgrenzung (1)

    Eigenschaften der modellbasierten Entwicklung (MDA - model driven architecture) sind:

    • Verwendung von Modellen zur Softwareentwicklung zur Abstraktion

    • Verwendung von Generatoren/Transformatoren zur Softwareentwicklung

    • Auch teilweise Automatisierung möglich (je nach fachlicher Anforderung zwischen 20% und 100%)

    • Die erst Abstraktionsebene wird vollständig manuell erzeugt

    • Ziel ist die Steigerung der Softwarequalität

    • Schlagwort „Automation durch Formalisierung“ in frühen Entwicklungsphasen

    • Definitionen MDA, MDSD, MDSE nicht einheitlich und weichen je nach Literaturquelle voneinander ab

    SW in sicherheitsrelevanten Systemen


    Begriff mda und abgrenzung 2
    Begriff „MDA“ und Abgrenzung (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 von Plattformen aus

    • Plattformen können aufeinander aufbauen.

    • Logische Fortsetzung des Abstraktionsgedankens bei der Entwicklung – manuelle Drahtverbindung, Maschinencode, Assembler, Programmiersprache, Modellierungssprache

    SW in sicherheitsrelevanten Systemen


    Mda und omg
    MDA und OMG

    • Ein Gesamtmodell wird in mehrere Schichten unterteilt:

      • Computation Independent Model► (CIM) für die umgangssprachliche Beschreibung

      • Platform Independent Model► (PIM) für die Geschäftsprozesse

      • Platform Specific Model► (PSM) für die Architektur und Services

      • Codemodell► für die Zielplattform

    SW in sicherheitsrelevanten Systemen



    Modelltransformation
    Modelltransformation

    SW in sicherheitsrelevanten Systemen


    Pim und psm bestimmen sich ber kontext
    PIM und PSM bestimmen sich über Kontext

    SW in sicherheitsrelevanten Systemen


    Ausf hrbare modelle
    Ausführbare Modelle

    Modelle, die durch die Verwendung eines Code-Generators direkt ausgeführt bzw. interpretiert werden können.

    • Voraussetzung:

    – Sprache zur Beschreibung von Algorithmen

    – Strukturen für die Ausführung (Simulationsumgebung)

    • Ziel: vollständig ausführbare PIMs

    – Komplette Entwicklung auf Modellebene

    – Ausführung des Modells zum Testen

    – weitgehende Generierung des Codes

    • Sehr gute Komponenten-Architektur – MDA erfordert immer noch „DENKARBEIT“

    SW in sicherheitsrelevanten Systemen


    Mda und uml
    MDA und UML

    • Ein MDA-Modell ist eine abstrakte Repräsentation von Struktur, Funktion oder Verhalten eines Systems

    • Ein MDA-Modell wird in der Regel in UML beschrieben

    • UML-Diagramme sind nicht per se MDA-Modelle

    • Die Semantik der MDA-Modelle wird durch die Verwendung einer entsprechenden Modellierungssprache formal definiert

    • Es werden UML-Profile und entsprechende Transformationsregeln zwischen MDA-Modell und plattformspezifischem Modell eindeutig definiert

    SW in sicherheitsrelevanten Systemen


    Mof meta object facility
    MOF – Meta Object Facility

    • OMG standard

    • stellt Framework für das Management von Metadaten zur Verfügung

    • Unterstützt die Entwicklung modell- /metadatenbasierter Entwicklung

    • diverse UML-Profile verwenden MOF

    • XMI verwendet ebenfalls MOF

    SW in sicherheitsrelevanten Systemen


    4 mof ebenen
    4 MOF-Ebenen

    • M0-Ebene  - Konkret (Ausgeprägte Daten)

    • M1-Ebene  - Modelle (z. B. logische Daten-, Prozess- oder UML- bzw. Objekt-Modelle, die die Daten der M0-Ebene definieren)

    • M2-Ebene  - Sprachebene (Definieren, wie die Sprache über den Modellen von M1 aufgebaut und strukturiert sind)

    • M3-Ebene  - Meta-Sprache (Abstrakte Ebene, die zur Definition der M2-Ebene herangezogen wird)

    SW in sicherheitsrelevanten Systemen



    M3-Ebene:

    SW in sicherheitsrelevanten Systemen


    Wie viele ebenen definiert mof
    Wie viele Ebenen definiert MOF?

    • 4 Ebenen sind nur ein Beispiel

    • Grundlagen sind Klasse und Instanz

    • MOF definiert die Möglichkeit von einer Instanz zu ihrem Metaobjekt zu navigieren

    • Somit kann mit Hilfe von MOF jede beliebige Anzahl von Ebenen definiert werden

    • Mindestens zwei Ebenen

    SW in sicherheitsrelevanten Systemen


    Automatendefinition in 3 ebenen
    Automatendefinition in 3 Ebenen

    • M2:

      {} Mengenlehre aus Mathematik

      -> Funktionen

      x Kartesischen Produkt

    • M1:

      A = (Z, E, A, F)

      Z = {z1, … , zn)

      E = {e1, …, en)

      A = {a1, …, an)

      F: ZxE -> ZxA

    • M0:

      A = ({1,2,3}, {tr}, {a, b, c}, ((1,tr) -> (2,a), (2,tr) -> (3,b), (3,tr) -> (1,c)))

    SW in sicherheitsrelevanten Systemen


    Automatendefinition in 3 ebenen1
    Automatendefinition in 3 Ebenen

    M1:

    M2:

    M0:

    SW in sicherheitsrelevanten Systemen


    Programmiersprachen in 4 ebenen m3
    Programmiersprachen in 4 Ebenen M3

    • M3 - Definition der BNF (Backus-Naur-Form)

      Definition =Endezeichen  ;Logisches Oder |Option [ ... ]Optionale Wiederholung { ... }Gruppierung ( ... )

      Terminal- und Nichtterminalsymbole

      usw.

    SW in sicherheitsrelevanten Systemen


    Programmiersprachen in 4 ebenen m2
    Programmiersprachen in 4 Ebenen M2

    • M2: Syntax der Programmiersprache in BNF

      Programm = 'PROGRAM' Bezeichner 'BEGIN' { Zuweisung [";"] } 'END' "." ; Bezeichner = Buchstabe { ( Buchstabe | Ziffer ) } ; Zahl = [ "-" ] Ziffer { Ziffer } ; String = '"' { AlleZeichen − '"'} '"' ; Zuweisung = Bezeichner ":=" ( Zahl | Bezeichner | String ) ;

    SW in sicherheitsrelevanten Systemen


    Programmiersprachen in 4 ebenen m1
    Programmiersprachen in 4 Ebenen M1

    • M1: Programm

      PROGRAM DEMO1 BEGIN

      A0:=3; B:=45; H:=-100023; C:=A; D123:=B34A; ESEL:=GIRAFFE; TEXTZEILE:="Hallo, Welt!"; END.

    SW in sicherheitsrelevanten Systemen


    Programmiersprachen in 4 ebenen m0
    Programmiersprachen in 4 Ebenen M0

    • M0: Programmausführung mit Instanzen/Daten

    SW in sicherheitsrelevanten Systemen


    Meta programmierung meta modellierung
    Meta-ProgrammierungMeta-Modellierung

    • Definition von Domänen-Spezifischen Sprachen (DSL)

    • Modelltransformation

    • Sprachumfang wird auf das Nötigste beschränkt

    • Schneller zu lernen als manche UML-ProfileDefinition MARTE-Profile über 600 Seiten!

    • Guter Programmierzugang für Nicht-InformatikerWichtig für interdisziplinäre Entwicklung

    • Sprache nicht zu einfach wählen, Abstraktionskonzepte nicht vergessen!

    • Qualitätssicherung der Modelltransformationen

    SW in sicherheitsrelevanten Systemen


    Werkzeuge zur meta programmierung modellierung
    Werkzeuge zur Meta-Programmierung/-Modellierung

    • TOPCASED (Toolkit in Open Source for Critical Applications & Systems Development)

    • EMF (Eclipse Modeling Framework)

    • MetaEdit

    SW in sicherheitsrelevanten Systemen


    Scade
    SCADE

    SW in sicherheitsrelevanten Systemen


    Grundlagen der scade modellierung
    Grundlagen der SCADE-Modellierung

    • SCADE-Modellierung beschreibt:

    • SW-Regelkreisen und Signalverarbeitung (Differenzengleichungen)

    • Endliche Zustandsmaschinen (Hierarchie, Parallelismus)

    • Synchron getaktetes Modell

    SW in sicherheitsrelevanten Systemen


    Grundlagen synchroner programmierung
    Grundlagen synchroner Programmierung

    Gut geeignet für Regelungen und Endliche Automaten

    Eingaben lesen

    Reaktion berechnen

    Ausgaben schreiben

    Synchron = 0-Delay innerhalb eines Taktes für

    Kontrollfluss

    Signalfluss

    Vorteile:

    I/O und Berechnungen sind sauber getrennt

    einfaches Semantik, die auf Datenflüssen (Streams) beruht

    SW in sicherheitsrelevanten Systemen


    Synchrone hypothese
    Synchrone Hypothese

    Wenn der Raum klein genug ist,

    können Sängerin und Publikum die

    Schallgeschwindigkeit vernachlässigen.

    Spezifizieren mit 0-Delay

    Implementieren mit vohersagbarem Delay

    SW in sicherheitsrelevanten Systemen


    Synchrones zeitmodell

    i1

    i2

    i3

    i4

    i5

    i6

    i7

    o1

    o2

    o3

    o4

    o5

    o6

    o7

    i1

    i2

    i3

    i4

    i5

    i6

    i7

    o1

    o2

    o3

    o4

    o5

    o6

    o7

    Synchrones Zeitmodell

    • Zeit wird zu einer logischen Größe

    Logische Zeit

    Implementationszeit

    WCET = garantiert keine Überlappung

    WCET: Worst Case Execution Time

    SW in sicherheitsrelevanten Systemen


    Berblick ber die scade syntax
    Überblick über die SCADE-Syntax

    • Daten

      • Starke Typisierung (bool, int, real, array, structure)

      • Nur statische Datentypen

    • Datenfluss Beschreibung

      • Boole’sche Logik (not, and, or, etc.)

      • Arithmetik (+, -, *, /, mod, etc.)

      • Auswahl (if … then … else …; switch case)

      • Keine Schleifen – aber Map / Fold über Felder

      • Temporale Operatoren: Zugriff auf vorherige Datenflusswerte (fby=“followed by”)

    • Safe state machines

      • Synchrone Automaten

      • Hierarchie

      • Parallelismus

    SW in sicherheitsrelevanten Systemen


    Scade syntax datentypen
    Scade Syntax - Datentypen

    • Grundtypen:

      bool, int, real, char

    • Nutzerdefinierte Typen

      Aufzählungstypen

      type COLORS = enum {RED, GREEN, BLUE};

      Strukturen

      type Sensor = {valid: bool; value: real;};

      Arrays

      type RealArray = real^5;

      type ElevatorButtons = int^(FLOORS);

    • Typen der Zielsprache

      type imported CanMessage;

    SW in sicherheitsrelevanten Systemen


    Scade semantik
    SCADE Semantik

    • Ein Datenfluss ist eine unendliche Folge von Datenwerten

    SW in sicherheitsrelevanten Systemen


    Gleichungen
    Gleichungen

    • Syntaktische Gleichungen definieren Datenflüsse:

    • fib, aux: nat;

    • fib = fby(aux, 1, 0)

    • aux = fby(aux + fib, 1, 1);

    SW in sicherheitsrelevanten Systemen


    Ein einfacher z hler
    Ein einfacher Zähler

    node Counter (Reset: bool) returns (Count: int)

    Count = if Reset then 0 else 1 + fby(Count,1,0)

    SW in sicherheitsrelevanten Systemen


    Zustandsmaschinen
    Zustandsmaschinen

    • Count: intlast = 0;

    SW in sicherheitsrelevanten Systemen


    Der last operator
    Der last Operator

    Wenn Up aktiv ist

    Count = last 'Count + 1;

    Wenn Down aktiv ist

    Count = last 'Count – 1;

    last 'Count ist immer der letzte Wertvon Count im gesamten Skope dieses Datenflusses

    Wenn STAND_BY aktiv ist, behält Count seinen vorherigen Wert

    Die Initialisierung von Count geschieht aufgrund der Deklaration

    Count: int last = 0;

    SW in sicherheitsrelevanten Systemen


    Parameter polymorphismus

    node toggle_sample (a, b: 'T) returns (c: 'T)

    var

    flag: bool

    let

    flag = fby(not flag, 1, true);

    c = if flag then a else b

    tel

    polymorphic

    Parameter Polymorphismus

    node toggle_sample (a, b: int) returns (c: int)

    var

    flag: bool

    let

    flag = fby(not flag, 1, true);

    c = if flag then a else b

    tel

    monomorphic

    SW in sicherheitsrelevanten Systemen


    Array map operator beispiel elementweise summe
    Array Map Operator (Beispiel: Elementweise Summe)

    node SumScalar (a,b: int) returns (c: int)

    let

    c = a + b;

    tel

    node SumArray(t,u: int^3) returns (v: int^3)

    let

    v = (map SumScalar <<3>>) (t,u);

    tel

    SumArray([1,2,3],[2,4,0])  [3,6,3]);

    SW in sicherheitsrelevanten Systemen


    Array fold operator beispiel akkumulierte summe
    Array Fold Operator(Beispiel: akkumulierte Summe)

    node AccumulatedSum(t: int^5) returns (v: int)

    let

    v = (fold SumScalar <<5>>) (t);

    tel

    AccumulatedSum([1,2,3,4,5])  15;

    SW in sicherheitsrelevanten Systemen


    Qualit tssicherung von entwicklungswerkzeugen
    Qualitätssicherung von Entwicklungswerkzeugen

    SW in sicherheitsrelevanten Systemen


    Was sagt die cenelec norm
    Was sagt die CENELEC-Norm?

    • 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

    • 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

    • Werkzeuge werden in Zukunft normativ stärker betrachtet

    SW in sicherheitsrelevanten Systemen


    Qualifizierung von werkzeugen
    Qualifizierung von Werkzeugen?

    • Automatisierung manueller Tätigkeiten

    • Werkzeug besitzt deterministisches Fehlerverhalten

    • Mensch besitzt stochastisches Fehlerverhalten

    • Nachgelagerte Qualitätssicherung zum Fehlerfinden -> keine Qualifizierung von Werkzeugen notwendig!

    • Einsparen von Qualitätssicherungsschritten: -> Qualifizierung von Werkzeugen notwendig!

    • Es gibt auch Werkzeuge, die weit über die Möglichkeiten manueller Tätigkeiten hinaus gehen:

      • Compiler,

      • Model Checker,

      • färbende einrückende Editoren,

      • Debugger, etc.

    SW in sicherheitsrelevanten Systemen


    Qualifizierung am beispiel v generatoren compilern
    Qualifizierung am Beispiel v. Generatoren/Compilern

    • Generator durch Validierungssuite

    • Vorwärts- Rückwärts mit Vergleich

    • 2 mal diversitär Vorwärts mit Vergleich

    • Test der Applikation mit Abdeckungsmessung auf Bytecode/Assembler-Ebene

    • Generierung der Testfälle aus dem Modell mit Abdeckungsmessung

    • Generierung der Testfälle aus einem Testmodell anschließende Abdeckungsmessung

    • Formal beweisbare Übersetzung

    SW in sicherheitsrelevanten Systemen


    Validierungssuite
    Validierungssuite

    • Validierungssuite: Sammlung von Testfällen (ausführlich)

    • 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

    SW in sicherheitsrelevanten Systemen


    Zweimal diversit r vorw rts mit vergleich
    zweimal diversitär Vorwärts mit Vergleich

    • 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

    SW in sicherheitsrelevanten Systemen


    Vorw rts r ckw rts mit vergleich
    Vorwärts- Rückwärts mit Vergleich

    • 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

    SW in sicherheitsrelevanten Systemen


    Testf lle aus modell mit abdeckungsmessung
    Testfälle aus 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.

    SW in sicherheitsrelevanten Systemen


    Abdeckungsmessung auf generiertem code
    Abdeckungsmessung auf generiertem Code

    • 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

    SW in sicherheitsrelevanten Systemen


    Testmodell mit abdeckungsmessung
    Testmodell mit 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

    SW in sicherheitsrelevanten Systemen


    Formal beweisbare bersetzung
    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)

    SW in sicherheitsrelevanten Systemen


    Qualifizierung in der praxis
    Qualifizierung in der Praxis

    • Werkzeuge mit Validierung, Begutachtung und Zulassung!

    • Werkzeuge ohne Nachweis der Qualifizierung

    • Und alles was dazwischen ist

    • In der Überarbeitung der CENELEC werden Werkzeuge differenzierter betrachtet:

      • 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

    • Werkzeuge werden in Zukunft normativ stärker betrachtet

    SW in sicherheitsrelevanten Systemen


    Formale verifikation in scade
    Formale Verifikation in SCADE

    SW in sicherheitsrelevanten Systemen


    Model checking von scade modellen
    Model Checking von SCADE-Modellen

    Durchführung:

    Verknüpfung mit synchronem Observer

    Anwendung liefert Testscenario bzw. Nachweis

    Grundlage Stalmarcks Algorithmus (Prover Technologies

    Übersetzung SCADE  Aussagenlogik + (Presburger) Arithmetik

    Model Checking und Zertifizierung

    SW in sicherheitsrelevanten Systemen


    Synchrone observer
    Synchrone Observer

    Idee von Model Checking

    Eigenschaften werden als Observer in SCADE formuliert:

    Design Verifier prüft, ob die einzige Ausgabe des Observers immer true ist.

     Beispiel: SW-Komponente eines Achszählers

    SW in sicherheitsrelevanten Systemen


    Formulierung von eigenschaften
    Formulierung von Eigenschaften

    • Aussagenlogik: logische Operatoren and, or, implies, …

    • Temporale Operatoren von SCADE: fby, pre und daraus abgeleitete

    • Lineare Arithmetik (auch Presburger Arithmetik):

      Integer: Multiplikation mit höchstens einer Variable

      Real: Multiplikation und Division mit höchstens einer Variable

    Mathematische Funktionen (sin, cos, sqrt) und Potenzen gehen

    nicht!

    SW in sicherheitsrelevanten Systemen


    Einige abgeleitete temporale operatoren
    Einige abgeleitete temporale Operatoren

    AlwaysAfterFirstCond: gleicht Input1 sobald Cond einmal true wird;

    vorher immer true

    SW in sicherheitsrelevanten Systemen


    Einige abgeleitete temporale operatoren1
    Einige abgeleitete temporale Operatoren

    AtLeastNTick: wird immer dann true, wenn Input1 n-mal hintereinander true war; false sonst

    SW in sicherheitsrelevanten Systemen


    Algorithmische grundlagen des model checkers
    Algorithmische Grundlagen des Model Checkers

    • Hersteller: Prover Technologies

    • Lösungsalgorithmen für das SAT-Problem; z.B. Davis-Putnam-Logemann-Loveland-(= DPLL-)Algorithmus

    • Entscheidungsalgorithmen für Datengleichungen

    • Constraint solver

    • Stålmarks Algorithmus:

      Eingabe: Aussagenlogische Formel

      Ausgabe

      Entweder: Beweis im Dilemma-Beweissystem dass die Formel Tautologie ist;

      Oder: Belegung der Variablen, die die Formel false macht

    SW in sicherheitsrelevanten Systemen


    Bersetzung scade in aussagenlogik
    Übersetzung SCADE in Aussagenlogik

    • Automaten durch Datenflussbeschreibung ersetzen

    • Alle fby(…, n,…) durch fby(…,1, …) ersetzen

    • Hilfvariablen einführen, so dass nur noch fby(xi, 1, …) vorkommt  Jetzt gibt es nur noch, Logik, Arithmetik, fby(xi, 1, …)

    • SCADE-Knoten node anObserver (x1, …, xn) returns (Prop: bool) wird übersetzt zu Boole’scher Funktionen f(i, x1, ..., xn, pre(x1), …, pre(xn))

    • Induktionsbeweis mit Stålmarks Algorithmus: Beweise

      • f(true, x1, ..., xn, pre(x1), …, pre(xn))

      • f(false, x1, …, xn, pre(x1), ..., pre(xn))  f(false, y1, …, yn, x1, …, xn)

    SW in sicherheitsrelevanten Systemen


    Beispiel
    Beispiel

    • node risingedge(x: bool) returns (y: bool);

    • y = x and fby(not(x), 1, false);

    • (Hilfvariable einführen)

    • z = not(x);

    • y = x and fby(z, 1, false);

    • (Übersetzung in Boole‘sche Funktion – Gleichen werden zu logishen Äquivalenzen)

    SW in sicherheitsrelevanten Systemen


    ad