Software-Entwicklung sicherheitskritischer Systeme. Das SEHB im Safety Management System der DFS Dr. Jörg Brachmann

Transkript

1 Software-Entwicklung sicherheitskritischer Systeme Das SEHB im Safety Management System der DFS Dr. Jörg Brachmann

2 Agenda Die DFS Deutsche Flugsicherung GmbH Entwicklung sicherheitskritischer Software in der DFS Software in der Flugsicherung Normen und Standards Phasenmodell der SW-Entwicklung DFS Safety Management System (SMS) SW-Entwicklung auf gefordertem SWAL Vererbung der Safety-Relevanz Fazit und Ausblick 2

3 Die DFS Deutsche Flugsicherung GmbH

4 Die DFS Deutsche Flugsicherung GmbH 4

5 Software in der Flugsicherung Air Traffic Control Systems Remote Tower Control Tower Simulatoren Unmanned Aircraft Systems (UAS) Drohnen Operational Support Systeme 5

6 Software in der Flugsicherung Air Traffic Control Systems: Flugplan-Verwaltung Wo und wann will ein Flugzeug fliegen? RADAR-Verwaltung Wo sind die Flugzeuge? Höhe Rufzeichen Geschwindigkeit über Grund -> Luftlage-Darstellung: Flugplan + RADAR Flugzeugtyp Zielflughafen Flugsicherungs-Software ist sicherheitsrelevant Noch kritischer ist Software nur noch, wenn sie fliegt das SW-Entwicklungsvorgehen ist eingebettet in das Safety Management System der DFS 6

7 Normen und Standards ESARR-Reihe BAF Sicherheits -bewertungen Safety Management System 7

8 Normen und Standards ESARR 6 VO (EG) Nr. 482/2008 Reihe der ESARR-Normen fordert Aufbau eines Safety Management Systems ANS recommendations / ED-153 Prüfnorm / Compliance Matrix Etablierung eines SW-Entwicklungsvorgehens (Phasen + Phasenübergänge) ISO SW-Entwicklungsvorgehen angelehnt an ISO 12207:1995 DFS Systemhaus Software Entwicklungshandbuch (SEHB) Definition des Phasenmodells, der Artefakte, der Prüfungen 8

9 Vorgabenbeispiel aus ED-153 9

10 Phasenmodell der Software-Entwicklung I Phasen Prüfungen + Tests Aktivitäten 10

11 Object Hierarchy Phasenmodell der Software-Entwicklung II TM-SC V-model Development Test (Sub-) (Sub-) Subsystem Subsystem Unit Unit Component Segment Segment System System (CSU) (CSU) Customer Customer (CSC) (CSC) (CSCI) (CSCI) System Requirements Definition System Design Development phases SSS SSDD Software Specification Code-Review Metrics ICD SRS Software Design Software Implementation Coding Docs SDD ICD Code Unit Test Component Integration Test Subsystem Test [PQT] [Fix Verify] Development Environment System Test [Build Verify] Customer Acceptance Test [SAT/FAT] Fix / Patch PQT Build System Build System Build Software Status Tests 11

12 Phasenmodell der Software-Entwicklung III Planungsphase Auftraggeber Erheben der Kundenanforderungen Akzeptanzkriterien Anforderungs- Beschreibung Planungsphase CCB-Beschluss => Auftragsvergabe PdM/AM Anfrage Real.Auftrag Anforderungsprozess Abnahme-Definition Anforderungs- Beschreibung Kundenanforderungen SSS sortieren, klären System- Spezifikation System techn. strukturieren/anpassen Angebot System- Architektur Aufwand schätzen, Terminplan erstellen SSDD Testprozedur Auftraggeberprozesse operationelle Evaluierung / Validierung Akzeptanztests BAT,MIT,LDT System- Integration gemeinsame Prozesse Auftraggeber und Lieferant Abnahmetest FAT/SAT Bereitstellung zum System Verifikation Abnahme-Test Software-/Hardware Integration techn.freigabe betriebl. Freigabe Produktivbetrieb Abnahme-/ Systemtest Integrationsphase Spezifikationsphase SSS+SSDD Software spezifizieren Software- Spezifikation SRS Software integrieren Integrationstest (=BVT / FAT Dry Run) PQT CRn+x PQT CRn CR-Tests + Regressiontest + Performancetest Level Software Specification Entwurfsphase CDR SRS Software aufteilen in SW-Komponenten Software- Architektur SDD SDD Software im Detail beschreiben Software- Feinentwurf SDD SRS Testentwurf erstellen Testkomponenten / logische Testfälle DAT / CR-LCD Level Software Architectural Design Level Detailed Design Implementierungsphase SRS+SDD Software codieren Code-Review Metrics Measurement SRS + DAT / CR-LCD PQT-Prozedur Testprozeduren + Testdaten erstellen DAT / CR-LCD Unit-Tests erstellen Code Repository, Development Environment Unit Test Level Code Produktmanagement, Konfigurationsmanagement, Qualitätsmanagement Abkürzungen: PQT = Preliminary Qualification Test (Test der Änderungen durch Lieferant) (CR = change request) BVT = Build Verification Test (interner Test des Gesamtsystems durch Lieferant) FAT = Factory Acceptance Test (Abnahmetest des AG ggü. Lieferant auf Testanlage) SAT = Site Acceptance Test (Akzeptanztest des AG auf seiner operationellen Anlage) LDT = Life Data Test (Test des AG im operationellen Umfeld mit Daten aus dem Produktivsystem) MIT = Master Integrationstest (Test des AG im operationellen Umfeld mit allen Partnersystemen) BAT = Betrieblicher Abnahmetest (Test der Geschäftsabläufe durch AG im operationellen Umfeld) 12

13 DFS Safety Management System (SMS) Sicherheitsbewertungen Wahrscheinlichkeitsnetz Flugsicherungsinduzierte Unfälle < alle Jahre Software Assurance Level SWAL SWAL 2 ~ fliegende Systeme SWAL 3 ~ (Boden-)Systeme für operative Flugsicherung SWAL 4 ~ Offline-Systeme Sicherheitsanforderungen z.b. redundante Ausführung einer Systemkomponente 13

14 Software Entwicklungsvorgehen nach SWAL An das geforderte SWAL angepasstes SW-Entwicklungs-Vorgehen Auswirkungen auf Tiefe der Traceabilitity Review und Approval von Artefakten Kriterien für Phasenübergänge Testabdeckung Fehlerbewertung und -behebung Nachweise gegenüber Aufsichtsbehörde für Flugsicherung (BAF) 14

15 Vererbung der Safety-Relevanz Vererbung der Safety-Relevanz durch Traceability Safety System Software Test Fehler Safety Anforderungen aus Sicherheitsbewertungen Durch Traceability auf System-Anforderungen werden diese safety-relevant Durch Traceability von System auf Software-Anforderungen erben die Software Anforderungen die Safety-Relevanz Getestete Anforderungen werden dadurch ebenfalls safety-relevant und gesondert reportet Fehler aus dem fehlgeschlagenen Test einer safety-relevanten Anforderung werden als produktionsverhindernd behandelt 15

16 Fazit und Ausblick Die DFS Deutsche Flugsicherung erzeugt mit einem W-Modell-artigen SW-Entwicklungsvorgehen, das in ein Safety Management System eingebettet ist, erfolgreich sicherheitsrelevante Flugsicherungs-Software. Aufgrund der regulativen Anforderungen des Umfeldes müssen bestimmte Nachweise erbracht werden. In Zukunft sollen agile Vorgehen und Techniken in dieses Vorgehen integriert werden. Dies natürlich unter Beibehaltung des hohen Sicherheits-Niveaus, das von der Aufgabe Flugsicherung gefordert wird. 16

17 Vielen Dank für die Aufmerksamkeit!