Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

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

Ähnliche Präsentationen


Präsentation zum Thema: "Software in sicherheitsrelevanten Systemen Ralf Pinger / Stefan Gerken Sommersemester 2013."—  Präsentation transkript:

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

2 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page 2 Kapitel 1 - Was sind Sicherheit und Verfügbarkeit? Inhaltsübersicht 1.Motivation 2.Definitionen 3.systematische und zufällige Fehler

3 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Motivation – Der 1. Vorfall Zusammenstoß zweier S-Bahnen im Bahnhof Flughafen Hannover-Langenhagen,

4 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Motivation – Die Bahn Das Signal dient zur Informations- übermittlung an den Zug und über- mittelt z.B. Erlaubnis zur Einfahrt erlaubte Geschwindigkeit …

5 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Motivation – Die Bahn Die Weiche

6 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Motivation – Die Bahn 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

7 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Motivation – Die Bahn Funktionen der 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.

8 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Motivation – Die Bahn Beispielstrecke

9 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Motivation – Die Bahn Wirkprinzip der PZB/Indusi

10 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Motivation – Die Bahn Die Nachrichten der PZB/Indusi lauten: 500-Hz-Magnete Ist 250 bis 150 m vor Hauptsignalen, die besondere Gefahrenpunkte decken. falls zu schnell, erfolgt Zwangsbremsung 1000-Hz-Magnet Ist am Vorsignal bzw. Überwachungssignal eines Bahnübergangs Wachsamkeitstaste innerhalb 4 s betätigen, sonst Zwangsbremsung falls zu schnell, erfolgt Zwangsbremsung 2000-Hz-Magnet Ist am Hauptsignal Zwangsbremsung falls Halt-Signal

11 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Motivation – Die Bahn Französische Alternative zur Indusi Krokodil (1920er Jahre) Signalbegriff wird als positive oder negative Spannung dargestellt (Spannung ca. +/- 20 V)

12 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Motivation – Die Bahn Europäische Alternative zur Indusi Eurobalisen Übertragung von Datenpaketen möglich (mehrere Bytes) Übertragung von Fahrprofilen möglich Verbesserte Ortung möglich

13 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Motivation – Die Bahn Punktförmige Zugsicherung Live-Demo TBL1+ (TBL1+ ist ein Zugsicherungssystem der belgischen Bahn)

14 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Motivation – Fortsetzung des 1. Vorfalls Was geschah S-Bahn 5711 stand ab 09:53 Uhr abfahrbereit vor Ausfahrsignal, geplante Abfahrt 10:10 Uhr S-Bahn 5712 hat 7 Minuten Verspätung, erwartete Ankunftszeit 10:11 Uhr S-Bahn 5712 erhält Erlaubnis zur Einfahrt in Bahnhof S-Bahn 5711 steht vor Halt zeigendem Signal!

15 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Motivation – Fortsetzung des 1. Vorfalls Ausgangssituation beim Zusammenstoß zweier S-Bahnen im Bahnhof Flughafen Hannover-Langenhagen,

16 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Motivation – Fortsetzung des 1. Vorfalls Was ist passiert? S-Bahn 5711 startet um 10:10 Uhr Ausfahrsignal für S-Bahn 5711 stand auf Halt Indusi erzeugt Zwangsbremsung für S-Bahn 5711 Triebfahrzeugführer von S-Bahn 5711 drückt Freitaste und fährt wieder los! S-Bahn 5711 fährt die Einfahrweiche auf S-Bahn 5712 war zu diesem Zeitpunkt schon an seinem Einfahrsignal vorbei -> keine ZB mehr möglich! Noch im Tunnel stoßen S-Bahnen 5711 und 5712 frontal zusammen

17 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Motivation – Fortsetzung des 1. Vorfalls Unfallfolgen: 16 Personen verletzt DM Sachschaden Wiederinbetriebnahme der Strecke erst am , 04:00 Uhr, einen ganzen Tag später

18 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Motivation – Fortsetzung des 1. Vorfalls Fazit: keine kausale Beteiligung technischer Komponenten/Einrichtungen S-Bahn 5711 erhielt Zwangsbremsung Ursache: unerlaubte Weiterfahrt von S-Bahn 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

19 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Motivation – Fortsetzung des 1. Vorfalls Weiteres Fazit: Das Sicherungssystem hat die Fehlhandlung des Triebfahrzeugführers erkannt Das Sicherungssystem hat eingegriffen nach erfolgter technischer Reaktion übernimmt der Mensch wieder die Verantwortung offenbar hat der Mensch die Zwangsbremsung nicht dem Hauptsignal zugeordnet

20 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Motivation – Fortsetzung des 1. Vorfalls Mögliche 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

21 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Motivation – Systemkomplexität Ist menschliches Versagen als Unfallursache 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 und nicht umgekehrt!

22 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Motivation – Systemkomplexität

23 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Motivation – Der Vorfall in Genthin 1939 Betriebliche Randbedingungen : 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

24 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Motivation – Der Vorfall in Genthin 1939 Der Ablauf 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 D 180 sieht nun nur noch Fahrt-Signale – die von D 10!

25 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Motivation – Der Vorfall in Genthin 1939 Der Ablauf 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

26 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Motivation – Der Vorfall in Genthin 1939 Das Verhängnis 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)

27 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Motivation – Der Vorfall in Genthin 1939 Die Unfallfolgen 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 Zufall oder nicht? weiterer Unfall in derselben Nacht mit 101 Toten, 28 Verletzten

28 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Motivation – Der Vorfall in Genthin 1939 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

29 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Motivation – Der Vorfall in Genthin 1939 Hätte Genthin verhindert werden können? 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! Urteil: Lokführer wurde zu 3 Jahren Gefängnis verurteilt!

30 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Motivation 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?

31 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Motivation – Die Vorlesung Wie entwickelt man Software, die in sicherheitsrelevanten Systemen ausgeführt wird? Nicht Inhalt dieser Vorlesung: Entwicklung sicherer Hardware Entwurf sicherheitsrelevanter Betriebskonzepte Ergonomie sicherheitsrelevanter HMI

32 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Definitionen RAMSS

33 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Definitionen Zusammenhänge RAMSS und Gefährdung

34 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Definitionen Die Domäne als Biotop Jede Domäne hat eigene Begriffe, die sich in Details unterscheiden Jede Domäne hat eigene Vorgehensweisen, die sich im Detail unterscheiden Jede Domäne hat das Ziel der funktionalen Sicherheit Die Verfahren und Vorgehensweisen ähneln sich, so dass das Verständnis von RAMSS übertragbar ist, die Methoden aber im Detail anders gewichtet und angewendet werden. Damit ist aber nicht zwangsläufig eine andere Wirksamkeit verbunden Hier also Definitionen der Bahntechnik (CENELEC)

35 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Definitionen – Sicherheit Sicherheit (EN 50126) Das Nichtvorhandensein eines unzulässigen Schadensrisikos (kurz: Freiheit von nicht akzeptablen Risiken) 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.

36 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Definitionen – Gefährdung, Gefahr Gefährdung Keine explizite Definition in der Norm Sprachlich: Eine gefährliche Situation Gefahr (EN 50126) Eine physikalische Situation, die potentiell einen Schaden für den Menschen beinhaltet.

37 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Definitionen – Risiko Risiko (EN 50126) Die Wahrscheinlichkeit des Auftretens einer Gefahr, die einen Schaden verursacht, sowie der Schweregrad eines Schadens Vereinfacht: Risiko = Schadensausmaß * Schadenshäufigkeit

38 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Definitionen – Zuverlässigkeit Zuverlässigkeit (EN 50126) Die Wahrscheinlichkeit dafür, dass eine Einheit ihre geforderte Funktion unter gegebenen Bedingungen für eine gegebene Zeitspanne (t1, t2) erfüllen kann. [IEC 60050(191)] Mögliche Anforderung: Mean Time Between Failure (MTBF) Mean Time To Failure (MTTF) Mean Up Time (MUT) Mean Distance Between Failure (MDBF)

39 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Definitionen – Zuverlässigkeit

40 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Definitionen – Verfügbarkeit Verfügbarkeit (EN 50126) Die Fähigkeit eines Produkts, in einem Zustand zu sein, in dem es unter vorgegebenen Bedingungen zu einem vorgegebenen Zeitpunkt oder während einer vorgegebenen Zeitspanne eine geforderte Funktion erfüllen kann unter der Voraussetzung, dass die geforderten äußeren Hilfsmittel bereitstehen. Mögliche Anforderung: A = MUT/(MUT + MDT); 0 A 1 mit MUT = Mean Up Time MDT = Mean Down Time

41 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Definitionen – Instandhaltbarkeit Instandhaltbarkeit (EN 50126) Die Wahrscheinlichkeit, dass für eine Komponente unter gegebenen Einsatzbedingungen eine bestimmte Instandhaltungsmaßnahme innerhalb einer festgelegten Zeitspanne ausgeführt werden kann, wenn die Instandhaltung unter festgelegten Bedingungen erfolgt und festgelegte Verfahren und Hilfsmittel eingesetzt werden. [IEC 60050(191)] Mögliche Anforderung: Mean Down Time (MDT) Mean Time Between Maintenance (MTBM) Mean Distance Between Maintenance (MDBM) Mean Time To Repair (MTTR)

42 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Definitionen – System Safety Anderes Beispiel - MIL-STD-882C 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. Purpose of Software System Safety Handbook (MIL-STD) Provide management and engineering guidelines to achieve a reasonable level of assurance that software will execute within the system context with an acceptable level of safety risk.

43 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Definitionen – System EN50129: System ist: Eine Menge von Teilsystemen, die entsprechend einem Entwurf zusammenwirken. Teilsystem ist: Ein Teil eines Systems, der eine spezielle Funktion erfüllt Element ist: ein Teil eines Produktes, der als Grundeinheit oder Grundbaustein bestimmt wurde. Ein Element kann einfach oder komplex sein. MIL Std 882 C System: A composite, at any level of complexity, of personnel, procedures, materials, tools, equipment, facilities, and software. The elements of this composite entity are used together in the intended operational or support environment to perform a given task or achieve a specific purpose, support, or mission requirement. Subsystem: An element of a system that, in itself may constitute a system.

44 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Definitionen – System System ISO 9000 Systembegriff bezieht sich auf die Wechselwirkung von Prozessen Problem: Die Definition von Begriffen wie System oder Funktion ist willkürlich,... und wahrscheinlich wird niemals eine universelle Definition gelingen. ABER: Die Sicherheit darf nicht davon abhängen, ob eine Funktion von einem System oder Element erbracht wird oder gar nur von einer Definition.

45 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Definitionen System - Eigenschaften 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. Daraus folgt: Der Benutzer muss das zu betrachtende System klar und eindeutig definieren. 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

46 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Definitionen System - Eigenschaften

47 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Definitionen 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 beziehungsweise Systemarchitektur dargestellt? Sind die einzelnen Architekturelemente definiert? Ist ihr Zusammenwirken eindeutig definiert?

48 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page RAMSS für Systeme/Produkte Was bedeutet RAMSS für Eisenbahnsignaltechnik? Zwingend notwendige Produkteigenschaften, ohne deren Nachweis die Produkte nicht marktfähig sind 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

49 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Sicherheit von Systemen/Produkten Wann ist etwas sicher? 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 Fehlern? Auf welche Betrachtungseinheit bezieht sich die Sicherheit? Was ist überhaupt ein Fehler?

50 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Anforderungen und Sicherheitsanforderungen Sicherheitsanforderungen

51 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Systematische und physische (zufällige) Fehler Klassifikation von Fehlern Physische (zufällige) Fehler Hardwarefehler als Folge von Alterung Verschleiß ausgefallene Transistoren Ursache: Physik Systematische Fehler mangelhafter Entwurf Programmierfehler fehlerhafte Dimensionierung der Hardware Ursache: Mensch

52 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page systematische und physische Fehler Klassifikation von Fehlern Unterscheidung systematische Fehler treten nach Beseitigung nicht mehr auf physische Fehler können sich jederzeit wiederholen Übergang kann fließend sein: Unterdimensionierter Kühlkörper eines Transistors Aber: eigentlich ist das ein systematisches Problem Mögliche Ursache?

53 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page systematische und physische Fehler Folgerung: Hardware physische Fehler möglich systematische Fehler möglich Software physische Fehler nicht möglich systematische Fehler möglich

54 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page systematische und physische Fehler Für diese Vorlesung folgt daraus: 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. Vermeiden von systematischen Fehlern in der Software Für sicherheitsrelevante Hardware folgt daraus: Erkennen von physischen Fehlern Beherrschen von physischen Fehlern (falls vorhanden einen sicheren Zustand einnehmen) Vermeiden von systematischen Fehlern Wohldefiniertes Verhalten (und auch dokumentiert) Nicht Inhalt dieser Vorlesung


Herunterladen ppt "Software in sicherheitsrelevanten Systemen Ralf Pinger / Stefan Gerken Sommersemester 2013."

Ähnliche Präsentationen


Google-Anzeigen