Software Prozess für Satelliten

Transkript

1 Software Prozess für Satelliten Informationstechnik für Luft- und Raumfahrt Informationstechnik für Luftund Raumfahrt

2 Damit haben wir zu tun: Space: Aero: Aero: Atom: Indust: Auto: ECSS DO-178B & DO-254 CENELEC EN & EN BS IEC :2000 & ISO26262 IEC > SIL MISRA (Motor Industry Software Reliability Association) Vorentscheidungen & Randbedingungen Alles ist geregelt Normen (ECSS-40, 80) Requirements Komponentenbaum Funktionsbaum Technology Readiness Phasen Reviews Phasen & Reviews & Technology Readiness & Komp & Funk Sicherheit durch Disziplin -> Regeln -> Prozesse? 2

3 Schritte Definition des Entwicklungsprozesses 1. Technische Spezifikation: Anforderungen/ Requirements (mit Traceability) 1.1 Software Requirements (meistens gesamte Funktionalität) (mit Traceability) 2. Grober Entwurf (+ Doku mit Traceability) 3. Feiner Entwurf (+Doku mit Traceability) 4. Programmieren (+Doku mit Traceability) 5. Test- & Verifikations-Plan (+Doku mit Traceability) 6. Testen (+ Doku mit Traceability) 3

4 Schritte Definition des Entwicklungsprozesses Traceability: Verfolgen den ganzen weg 1. Technische Spezifikation: Anforderungen/ Requirements (mit Traceability) 1.1 Software Requirements (meistens gesamte Funktionalität) (mit Traceability) 2. Grober Entwurf (+ Doku mit Traceability) 3. Feiner Entwurf (+Doku mit Traceability) 4. Programmieren (+Doku mit Traceability) 5. Test- & Verifikations-Plan (+Doku mit Traceability) 6. Testen (+ Doku mit Traceability) Vorsicht: Der größte Aufwand (in jeder Phase) ist Dokumentation!!! Was entscheidet der Übergang von Phase N zu N+1? Dokumentation! Im Weltraum verdient man das Geld mit Papier (Doku), und nicht mit Entwicklung. Eine Zeile Code eine Seite Dokumentation (req, Des, Test-Spec, Testreports...) Das produzierte Papier ist ca. 3x bis 10x so schwer wie der Satellit. 1,2 Mbytes Boot Image -> 2,2 GBytes Dokumentation 4

5 Parallel-Arbeit -> Abhängigkeiten Ground, Funk Orbit SW, HW, atc, guindance Elektrik, Power Struktur Themral payload...

6 Entscheidungen Vorsicht: Jede Entscheidung hat auch woanders Konsequenzen Ground, Funk Orbit SW, HW, atc, guindance Elektrik, Power Struktur Themral payload... sw zu langsman -> schnell hw -> power -> Struktur -> thermal -> solarp... Änderungen in einen Komponente Änderungen in anderen System Ingenieur soll gesamte Überblick haben und Änderungen abgrenzen / bremsen KO: Sys. Ingenieur akzeptiert immer mit neue tolle Ideen... schlimmer seine eigenen Tötet das Projekt! -> Richtiger Balance und ab eine Grenze: keine Änderungen mehr! 6

7 wichtige Bedingungen für Projekterfolg Klare Stabile Ziele & Arch. Stabile Teams Klare Prioritäten Klare Interfaces Wenige Änderungen Retro-Analysen 7 Erlaube Änderungen Entwicklungszeit

8 Design- Entscheidungen SSB Orbit Structure Payload Launcher Energy Pre-Selection Thermal Electronic TET Bus AOCS Z.B. Vorhandenes Data Management BIRD Bus TM / TC 8

9 Design- Entscheidungen Design dependencies graph SSB Launcher Orbit Structure Energy Thermal AOCS Electronic TM / TC 9 Data Management Mission Independet

10 Komponentenbaum Mission: Payload-Name/SSB Mission <PY>/SSB Segments Space Segment Launch RY Systems Satellite Bus (SSB) RY-OS EGSE OS SubBus Building Systems blocks Bus Payload Interfaces RY Structure RY-OS Data Management RY RY-OS Energy GSOC Payload Internals...Provider Data Interface Structure Int. OS Thermal RY-OS Electronics RY-OS GSOC Communications OS AOCS TCC / TM Payload (<PY>) Provider Ground Segment RY Thermal Int. Energy Int. Mission Control GSOC Payload Data Handling Provider

11 Struktur Komponenten 11

12 Elektronische Komponenten 12

13 Software Komponenten Booter Operating System (Basic Support Package) IO Drivers Applications Commander Housekeeping Telemetry (DownlinkManager) Mass Memory Manager Surveillance Thermal Control Charge Control Time Control Payload Interface (NVS-Interface) Redundancy Manager Watchdog RelayControl On-board Navigation System Attitude Control Guidance (Bahnregelung & Bahnmanövern) 13

14 Hardwaremacher: Komponenten Baum Softwaremachen: Funktionsbaum VOR-AB (Siehe Req) Functional Tree

15 TRL: Technology Readiness Level TRL 1: Beobachtung und Beschreibung des Funktionsprinzips (bis zum Flug: 8-15 Jahre) TRL 2: Beschreibung der Anwendung einer Technologie TRL 3: Nachweis der Funktionstüchtigkeit einer Technologie (bis zum Flug: 5-13 Jahre) TRL 4: Versuchsaufbau im Labor TRL 5: Versuchsaufbau in Einsatzumgebung TRL 6: Prototyp in Einsatzumgebung (z.b: Strahlungstest) TRL 7: Prototyp im Einsatz (bis zum Flug: 1-5 Jahre) (Geflogen) TRL 8: Qualifiziertes System mit Nachweis der Funktionstüchtigkeit im Einsatzbereich (Geflogen) TRL 9: Qualifiziertes System mit Nachweis des erfolgreichen Einsatzes (nx Geflogen!) Zeit bei Normalen Hoch Qualität Standard ECSS vorgehen

16 TRL: Technology Readiness Level TRL 1: Erste Idee: Ich habe Atom Oszillationen beobachtet, sehr stabil! TRL 2: Eine Anwendung: Wozu ist es gut? Eine Uhr? TRL 3: Mathematisch und nach den betanken Physik bewiesen TRL 4: Oszillator mit Zähler, so groß wie mein Zimmer, So viel Strom wie ein Haus TRL 5: Wie oben, in Vakuum und Thermal-Zyklen TRL 6: Wie oben aber klein und sparsam + Strahlungstest TRL 7: Als Payload erprobt. Es war mindestens 1 Woche an TRL 8: + Das ganze Qualifikationsprozedur, Längere Zeit in Betrieb in Orbit TRL 9: Es ist Operational bereits in mehreren Satelliten

17 TRL 9. Actual system 'flight proven' through successful mission operations 8. Actual system completed and 'flight qualified' through test and demonstration 7. System prototype demonstration in an operational environment 6. System/subsystem model or prototype demonstration in a relevant environment 5. Component and/or breadboard validation in relevant environment 4. Component and/or breadboard validation in laboratory environment 3. Analytical and experimental critical function and/or characteristic proof of concept 2. Technology concept and/or application formulated 1. Basic principles observed and reported

18 Papier und Entwicklung -1. Qualität = Menge an Paperwork (Papier, gemessen in kg und Tonnen) Z.B. Beim Columbus-Segment: Die Dokumentation war 3x schwerer als das Modul selbst. TET: 1,2 Mbyte Boot Image, 2,2 Gbyte Dokumentation A400, A380 würden mit Ihrer Dokumentation an Board nicht aufheben können -2. Mehr Dokumentation -> Höhere Qualität? Reale Qualität (Dependable) Sinvoll: Req, Tracebility, Interface Control Doc. Menge an Dokumentation (Zeit und Personal gleichbleibend)

19 Phasen: Wünsche aber FALSCH! ECSS Intuitiv R = Review R R R Was prüft er? Dokumente! R R R Intuitiv Aber nicht ECSS!!! wo ist Programmieren? wo ist Test?!?

20 Phasen : Realität ECSS Intuitiv R = Review Ist nicht so! aber so fühlt man sich! Angegeben A -> B -> C -> D... Commisioning Realität 90 %: A -> von rest 50% A -> B -> A -> B -> B1 -> B2 -> A -> B -> C -> C1... wo ist Programmieren? wo ist Test?!?

21 ECSS-40 TRL Anforderungen TRL/Phase A B C D E Was ist das Problem damit? (nichts neues!)

22 Tracebility ECSS-40 Standards Für SW SW Entwicklungsprozess in ECSS reinpressen! Validation: implementieren wir was wir sollen? Verification: implementieren wir es richtig: 22

23 Phase 0 TRL: 1-2 Vorbereitungsphase oder Mission Analysis Abschluss: Mission Definition Review (MDR) Phase A TRL: 2-3 Konzeption oder Feasibility. Abschluss: Preliminary Requirement Review (PRR) Phase B TRL: 4-5 Definitionsphase oder Preliminary Definition phase. Zwischenbericht (teilt Phase in B1 und B2): System Requirements Review (SRR) Abschluss: Preliminary Design Review (PDR) Phase C TRL C/D: 6-8 Entwurfsphase oder Detailed Definition Start: meist mit SRR Abschluss: Critical Design Review (CDR), meist fließender Übergang zu Phase D Phase D (TRL 8.. 9) Entwicklung oder Production Abschluss: Qualification Review (QR)

24 Phase E1 TRL: Qualifizierung oder Flight Qualification / Acceptance review (AR) Zwischenbericht: Flight Readiness Review (FRR) Zwischenbericht: Launch Readiness Review (LRR) Abschluss: Flight Qualification Review (FQR) Phase E2 Einsatz oder Utilization Zwischenbericht: Operational Readiness Review (ORR) (Commissioning) Abschluss: End of Life Review (EOLR) Phase F Entsorgung oder Disposal

25 ECSS-40 Dok & Reviews SRR: System Req Review PDR: Preliminary Desgin Rev. DDR: Detailed Design CDR: Chritical Design Review QR: Qaulity Revie AR: Acceptance Review ORR: Operational Readynes Review

26 ECSS-40 Phasen 26