Präsentation herunterladen
Die Präsentation wird geladen. Bitte warten
Veröffentlicht von:Sophia Adler Geändert vor über 9 Jahren
1
© EADS Sichere SW - Juli 2007 Qualitätssicherung bei der Entwicklung sicherheitskritischer SW © EADS Stefan Kauer EADS Deutschland GmbH Defence & Security
2
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 –…–…
3
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"
4
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) ……
5
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 …
6
Page 6 © EADS Sichere SW - Juli 2007 Avioniksystem interner Bus Gerät boards
7
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 -…
8
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 / …)
9
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
10
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
11
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 –…–…
12
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
13
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
14
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
15
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! –…–…
16
Page 16 © EADS Sichere SW - Juli 2007 Danke für Ihre Aufmerksamkeit
Ähnliche Präsentationen
© 2024 SlidePlayer.org Inc.
All rights reserved.