A First-MOVE in satellite development at the TUM

Transcription

1 A First-MOVE in satellite development at the TUM Manuel Czech 7th IAA Symposium on Small Satellites for Earth Observation Berlin, The Munich Orbital Verification Experiment

2 MOVE Summary MOVE is a program started at the Institute of Astronautics (LRT) of the Technische Universität München (TUM) in 2006 The objective of the MOVE program is to build pico-satellites with students for educational purposes. The experience gained shall help the development of small satellite missions at the institute in the future First-MOVE is the first mission of the MOVE program. First-MOVE shall verify the MOVE satellite platform and gain data for future optimization. In addition, new technologies such as deployable solar panels will be tested The industry is involved as an experimenter for new solar cells, which shall be verified The future emphasis on development within the MOVE program shall be mainly on payloads, in particular of a scientific nature. The Munich Orbital Verification Experiment 2

3 Mission First MOVE (scientific technological elements) The mission shall verify several techniques for increasing the performance of CubeSats. Limiting factors are: - Solar cell area - Radiator surfaces Increase of surfaces by deployable solar panels with highly efficient solar cells The MOVE platform and the solar cells shall be verified A camera for small pictures of the Earth for public outreach will be installed on the first MOVE satellite. High-performance On- Board Computer Additional Solar Cell Area Efficient Solar Cells Thermally adjustable surfaces Camera Antennas (deployed with the panel) The Munich Orbital Verification Experiment 3

4 Project Status All Prototype Models are manufactured and verified All acquired systems are ready or will be delivered shortly Manufacturing of the Structure and Mechanisms is almost finished Manufacturing of the Electronic systems in progress (PCBs) Operating software is ready Software Implementation on the platform and verification in progress Hardware qualification and acceptance testing in summer 2009 Launch estimated for Q4 of 2009 The Munich Orbital Verification Experiment 4

5 Technologies for Robustness The Munich Orbital Verification Experiment

6 Main Design Objective No matter what, MOVE shall create and deliver data! It is not strictly necessary that MOVE works perfectly or highly efficiently, but it shall live long enough to gain experience in satellite design and operation The more the lessons learned through First-MOVE, the better can the second one be optimized towards efficiency and scientific outreach Highest Design Goal Robustness rather than Efficiency The Munich Orbital Verification Experiment 6

7 Robustness: Central Reset Strategies Reset Strategy for Computers on Ground: In case of a problem, push the Reset Button Problem with satellites: The reset button is far away! Resets shall be commandable in case of a complete software crash Hard Coded Command Interpreter Resets might be necessary quickly (Latch-up), so that they have to be triggered autonomously Latch-up Protection In case of top level problems (no command possibility), a top system level reset shall be performed periodically System level Watchdog Timer The Munich Orbital Verification Experiment 7

8 Reset Strategies: Hard Command Reset Unit Idea: A limited set of commands (resets) shall be executable even in the event of a complete software crash As long as the transceiver works, the satellite is reachable and can be reset on different levels A Hard Command Reset Unit has been developed at LRT - Prototype Card of the size of 30x90mm, to be optimized to 25x80mm and integrated on a daughter board of the MOVE OBDH. - Variable Coding via jumpers on the board. - Length of the commands 80bit coincidental activation by noise unlikely Comprehensive analysis of failures and impacts has been performed, including sabotage EM/Prototype 30x90mm The Munich Orbital Verification Experiment 8

9 Reset Strategies: Latchup Protection and Master Watchdog Latchup Protection Background: High Risk of Latchups with COTS components Microcontrollers and memories are affected in particular Three protected power buses MC Memory Transceiver In case of a Latchup, the complete satellite power is reset WDT Background: In case of a high level system failure or a problem with the HCU, a reset is performed automatically and periodically The Munich Orbital Verification Experiment 9

10 Robustness: Temperature Zones and Electrical Control with Experiment Cells The satellite is divided in three temperature zones 1. Outer skin consisting from Solar Panels and Cells 2. Intermediate zone: Aluminum Structure and PCBS 3. Temperature stabilized core with batteries All areas are separated by thermal washers and MLI (temperature barriers) The experimental solar cells are not connected to the MPPTs of the power subsystem, as their electrical load has to be variable for characterization The experiment cells load resistors are designed as Kapton heaters, which are located on the batteries in the thermally stabilized core. Variation of the loads enables control of conduction of energy through the barriers The Munich Orbital Verification Experiment 10

11 Robustness: Electrical Control with Experiment Cells Control Loop1 (sunlight) If the temperature drops below a certain value which is close to the upper temperature limit of the battery, energy is transferred from the experiment cells through the barrier to the heaters on the battery While First-MOVE is in sunlight, the battery temperature is kept close to the upper limit It therefore carries as much energy as possible into the shadow phase the lower limit of the temperature is attained later Control Loop 2 (eclipse) In eclipse, the battery will be regulated by the power from the battery close to the low temperature limit The Munich Orbital Verification Experiment 11

12 Robustness: Software Error Corrections No radiation hard memory available for the OBDH software Maintenance of OBDH software by a memory combination MRAM Flash +No SEL or SEB + Big Size - SEUs - SEU, SEL, SEB - Small Sizes MRAM Failure Occurrence Severity (stand-alone) SEL, SEB low high - Severity (combined with Flash) Flash Failure SEL, SEB Occurrence Low (Lup protection) Severity (stand-alone) high - Severity(with Flash and comparator) SEUs high high Very low SEUs high high Very low The Munich Orbital Verification Experiment 12

13 Robustness: Verification of Critical Systems Failures during start-up of a CubeSat might be hazardous First-MOVE s deployables and kill switches are mission critical Deployables and kill switches have been tested and successfully verified in October 2008 with the VERTICAL mission (Rexus-4) See also presentation today 13:30 (student conference) The Munich Orbital Verification Experiment 13

14 Conclusion While designing a first CubeSat, there are many uncertainties which cannot be solved with the resources available in a University environment It is not possible to design a perfect CubeSat in one step It is expected that failures and problems will appear on First-MOVE System Critical failures shall be avoided by a robust design You can only learn from the mission if you get data The data about occurring failures is of special interest Comprehensive data has to be collected and submitted to understand what is going on in a CubeSat The Munich Orbital Verification Experiment 14

15 Future Prospects First-MOVE OBDH, incl. two Safety boards and Camera Safety measures are most likely over pessimistic Optimization through application of lessons learned leading to an optimized MOVE platform MOVE-on optimized OBDH with one Safety daughter board MOVE-on platform with larger payload envelope The Munich Orbital Verification Experiment 15

16 Conclusion and Vision The First- is the hardest, but once it is done,????? 2011?? we can -on 2009 and we will even -further The Munich Orbital Verification Experiment 16

17 Thank you very much! The Munich Orbital Verification Experiment 17