© EADS Sichere SW - Juli 2007 Qualitätssicherung bei der Entwicklung sicherheitskritischer SW © EADS Stefan Kauer EADS Deutschland GmbH Defence & Security

Page 2 © EADS Sichere SW - Juli 2007 Begriff  Fehlerhaftes Verhalten oder Ausfall der SW kann zu Verlust von Menschenleben oder Sachgütern von erheblichem Wert führen  Stufen der Kritikalität (Level A, B, C, D, E oder 1,2,3 je nach Standard, z.B. flight critical, mission critical, …)  Verschiedene Einstufungen je nach (militärischem oder zivilen) Standard  Kritikalität bestimmt –Welche Tätigkeiten –Wie durchzuführen –Wie zu dokumentieren –Tool Qualifikation –…–…

Page 3 © EADS Sichere SW - Juli 2007 Art der Geräte  Elektronische Komponenten für militärische Fluggeräte (Hubschrauber, Flugzeuge,...)  kundenspezifisch  geringe Stückzahlen (einige 100)  sicherheitskritisch  zertifiziert entsprechend Zertifizierungsprozess (bezieht sich auf‘s ganze Gerät: (mechanisch / elektrisch / SW /... )  special purpose - das Gerät kann nichts, was nicht benutzt wird, also nicht "universell", "alles-in-einem"

Page 4 © EADS Sichere SW - Juli 2007 Art der Geräte  sehr lange Betriebszeit (10-30 Jahre) –Wartung –Weiterentwicklung –Archivierung "alter" Tools /Rechner... –Single Source / Obszolesenz-Probleme / Management –…–…  embedded (Entwicklungssystem  Zielsystem!)  eingeschränkte HW aufgrund Zertifizierung und anderer Randbedingungen  oft keine user interaction (dafür Interface zu anderem HW- Modul / -gerät) ……

Page 5 © EADS Sichere SW - Juli 2007 Avioniksystem Main Computer Bus Controller Device 1Device n …. Avionic Bus …. Redundanz bei Geräten und Bus MC überwacht Geräte per BIT-Meldung MC überwachen sich gegenseitig …

Page 6 © EADS Sichere SW - Juli 2007 Avioniksystem interner Bus Gerät boards

Page 7 © EADS Sichere SW - Juli 2007 Avioniksystem HW -CPU (GPU, DSPs, MC) -Speicher (RAM, ROM, flash, spezial, ….) -FPGA, CPLD, ASIC, … -spezial HW -interner Bus -I/O -… board SW -Boot-ROM -FW -Treiber -OS -Application SW -…

Page 8 © EADS Sichere SW - Juli 2007 Vorgehen  Prozessorientierung –In house Standard, z.B. V-Modell (tailoring) –Von customer / purchaser, z.B. EFA-Standard –Übergreifend, z.B. DO178B  Requirement engineering  Problem / Änderungs-Management  Konfigurations-Management (Versionen / HW / SW / Konfig.- Stand / Umgebung / …)

Page 9 © EADS Sichere SW - Juli 2007  Dokumente – mit Reviews! –Planung –Requirement –Design (grob / fein) –Coding / Design Regeln (automatische / manuelle Prüfung -> CWT report) –Test –…–…  Compliance: Dokumentation muss mit Gerät übereinstimmen –„Fehler zugeben“ - concession –nicht erfüllbare Requirements nennen (wie kann das passieren?) Vorgehen

Page 10 © EADS Sichere SW - Juli 2007 Test / Integration  SW-Module –Entwickler-Tests –Unit Tests (White Box Tests) – nach Testplan, möglichst automatisiert -> Code Coverage 100% mit Code Inspection –Code Walk Through -> Einhaltung der Codier-Regeln  Integration der SW-Module auf board –„wilde“ Tests –Requirement based tests (black box tests) - nach Testplan, möglichst automatisiert (traceability) –Test für jeden gefixten Fehler durchführen  Integration der boards im Gerät –„wilde“ Tests –Requirement based tests (black box tests) - nach Testplan, möglichst automatisiert –Formale Abnahme (konfigurierte Testdaten u. -umgebung / Protokoll)  Integration der Geräte in Avioniksystem

Page 11 © EADS Sichere SW - Juli 2007 Fehler-Behandlung  Formale Erfassung / Verfolgung / …  Einfache Liste oft nicht ausreichend (zu komplex)  Zustandsdiagramm –verschiedene Zustandmengen –Rechte (wer darf was?) –Verfeinerungen –…–…

Page 12 © EADS Sichere SW - Juli 2007 Fehler-Verfolgung open occurance describe / assign new accept accepted reassign reject closed reopen fix fixed verify  verify not fixed

Page 13 © EADS Sichere SW - Juli 2007 Fehlerbehebung 1.Reproduzieren -SW / HW / Daten Version / Konfiguration; Umgebung („tritt nur in Afghanistan auf“) -wenn reproduzierbar: gut -wenn nicht: schwierig, nicht-deterministisch? 2.Analysieren -stufenweise Eingrenzung -Weglassen von potenziellen Einflussfaktoren -Abhängigkeit von Vorgeschichte ist schlecht -rückwärts Integration -Ziel: Auftreten des Fehlers mit möglichst einfacher Umgebung / Bedingungen / Eingaben -> Debuggen auf Ziel / Entw.-System 3.Fixen, Testfall entwickeln, testen, dokumentieren 4.Wieder auftretende Fehler (ärgerliche Sache) -statt Debugen auch Eingrenzen der SW mit Hilfe der Version- Tools (nächtl. build) -„ausprobieren“ bis Übergang gefunden, dann Quellcode-Differenz finden, …. -> wichtig ist, was zum Ziel führt

Page 14 © EADS Sichere SW - Juli 2007 Tools  Requirements-Engineering  Design / Codegen (?)  Versions- u. Konfigurationskontrolle  Compiler  Fehlerverfolgung  Coverage (Testabdeckung Unit Test)  Coding Standard Checker  Re-Engineering: Erzeugung Klassen / Paket / Modul- Diagramme  Generator für Schnittstellen-Beschreibung ……  Tool-Qualifikation

Page 15 © EADS Sichere SW - Juli 2007 Designmerkmale  HW –Selbsttest- / Diagnose-Funktionen (PBIT, IBIT, CBIT) –Verfügbarkeits-Überwachung –Watchdog –…–…  SW –deterministisch –keine dynamische Speicherverwaltung (OO  ) –darf nicht abstürzen -> ·robust gegen Fehleingaben über Interface ·falsche Parameter(Kombinationen), Kommando-Sequenzen, Timing, … ·Nicht (mehr) verfügbare HW-Resourcen (Speicher (Haupt, Hintergrund / Flash, Shared, Spezial z.B. Video), Bus, Zeit … –„doppelte Sicherheit“ bei Schnittstellen (Aufrufer / Sender und Ausführer / Empfänger prüfen Parameter) –Bei festgestelltem Fehlverhalten Wegschalten vom System; lieber nichts als etwas falsches machen, was womöglich nicht als solches erkannt wird! –…–…

Page 16 © EADS Sichere SW - Juli 2007 Danke für Ihre Aufmerksamkeit