Lessons Learned: STRV 1c/d Mission

1. Lessons Learned: STRV 1c/d Mission Keith Avery ATK Mission Research 5001 Indian School Rd. NE Albuquerque, NM 87110 Keith.Avery@ATK.com

2. Introduction • My Role in the Program • Electronic TestBed (ETB) • Multiple Roles • Single Point of Failure What can be Learned?

3. Background • Mission • QinetiQ (then the UK Defence Evaluation and Research Agency – DERA) designed and built the Space Technology Research Vehicles (STRV-1c and –1d) during the latter part of the 1990s. These were 100kg micro-satellites that carried between them 25 different experiments and payloads from a wide variety of international sponsoring organizations. • They followed on from the highly successful STRV-1a and –1b programme that culminated in their launch in 1994 into Geostationary Transfer Orbit (GTO) as auxiliary passengers on an Ariane-4 launcher. Designed for only one year of operations, both vehicles continued for 4 years in the harsh environment of GTO before the programme partners decided to shut them down. Among their notable achievements was the first demonstration of a tactical cryo-cooler in space and a comprehensive mapping of the electron and proton fluxes in the Van Allen Radiation Belts. • STRV-1c and –1d were launched as auxiliary passengers on an Ariane-5 in November 2000, again into GTO. After two weeks of successfully commissioning all subsystems and experiments on both spacecraft, and immediately prior to announcing the start of routine operations, telemetry from both spacecraft indicated a serious problem.

4. Orbital Period ~ 10.5 hours • Apogee 36,000 km 7.5 o Inclination p+ e-- Equator Background • Orbit Parameters

5. Background – Spacecraft • Spacecraft Design

6. QinetiQ, its suppliers and its sponsors Brought together 25 different experiments from academic, government and industry sponsors based around the world All were successfully integrated into 2 spacecraft that were launched together. Payloads were all fully commissioned on orbit. This was a huge management and technical undertaking, requiring a delicate balance of all the disparate technical and political requirements. STRV-1c and –1d were the first spacecraft to fly as auxiliary passengers on an Ariane-5 New launch vehicle with a new auxiliary platform Introduced difficult and changing launch requirements Difficult design issues with the structural qualification process were overcome. Robustness of the system was demonstrated The onboard data handling, attitude control and thermal control all performed flawlessly, as did the ground segment and S-band station at QinetiQ. Great success in terms of the cost In 2000 economic conditions, the entire programme cost less than 15M$ and took less than 4 years of design and development time to launch. Cause of the failure identified Not typically the case Things Go Right – The Program Despite the mission loss the programme was a success in many other respects:

7. Problem same for both vehicles S/C rendered incapable of receiving commands Receivers without power Systematic issue not random failures Obvious candidates discounted quickly Spacecraft designed to be fully dual-redundant Subsequent on-ground investigations using flight spare equipment replicated anomaly after two weeks in vacuum chamber Tiny relay inside the communications equipment burned out Could not cause the inability to communicate through either receiver by itself Power system architecture meant both receivers powered down as result of excessive current drawn by failed component Failed component found to be driven with a continuous rather than pulsed signal Does not cause the device to fail when used in air Absence of convective heating in space causes the device to fail after approximately 2 weeks of operations Failure not detected during the months of in-air testing Failure not detected during thermal vacuum tests Total duration of these tests was insufficient to cause the onset of the failure Options for recovery System reset of the spacecraft triggered by Single event upset (SEU) in the main computer SEU probability was extremely low Software crash (and automatic reset) Software crash was not observed for the 6 months Power bus outage Drift of the solar aspect angle (and loss of power from the solar arrays) Residual torques on spacecraft did not significantly change SAA over the course of 6 months Power design had sufficient margin to prevent an outage from occurring Things Go Wrong – On Orbit

8. The spacecraft were formally declared lost after 6 months of observations and attempts to re-establish communications. Throughout this time, telemetry continued to indicate that all onboard systems were healthy, with the one catastrophic exception. Things Go Wrong – The Result

9. Combination of events led to the mission loss Component knowledge Architecture design decisions System engineering Project management Program unable to uncover problem during development despite usual sequence of independent reviews and many layers of testing Multiple event nature of problem and depth hidden Lessons learned here not necessarily new or Earth-shattering Thoroughly consider the system failure modes! Failure Modes Analysis conducted! Did not detect the architectural weakness that was inherent in the system from this particular failure Beware the complacency that might exist if systems are a “rebuild” from a previous programme! Subtle component changes lead to a system whose characteristics are subtly different Beware the technical expert who has worked with a device or system for many years and “understands” it’s characteristics! Important difference between knowledge and experience blurred All claims backed up with documented facts from a sound source Share your fortunes openly and in good time with your sponsors! No time or money would have saved this program once the opportunities to find the problem had passed Relationship between customer and supplier crucial in understanding risks involved and in successfully exposing many other development issues during course of program Learning Experience – Lessons

10. Background – Electronics Testbed (ETB) • ETB History • MAPLE Series • STRV2 • STRV1d

11. ETB Development Plan • Architecture – ETB

12. ETB Development Plan • Architecture – DHS

13. ETB Development Plan • Slot Concept

14. ETB Development Plan Software ConOps • Time Slice

15. ETB Development Plan • Software ConOps • Time Slice

16. Types of Experiments “Smart” Experiments Full Communication Analog Sample State Based Experiments Use ‘Poll’ to advance counter Analog Only Experiment No communication COTS1 – Analog Circuits COTS2 – Digital Circuits COTS3 – Digital Circuits PHA – Pulse Height Analyzer LPE – Low Power Experiment (AIC) TRAM – Transmit Receive Antenna Module CCD – Charge Coupled Device QWIP – Quantum Well Infrared Photodector Dose – TID Dose Monitor/Shielding None Used ETB Development Plan

17. Things Go Wrong – ETB Development • During Development • BIC (Basic Interface Controller) • Co-Design • ASIC Into MCM • Radiation Shield • Tantalum Structure • Redesign Implemented

18. Things Go Wrong – ETB Integration • During Integration • First attempt at MFS • Service Connections (Don’t do it this way) • Connector Dyslexia

19. Things Go Wrong – ETB Test • During Integration • A Broken Experiment • Never Recovered

20. Things Go Right – ETB Modular System • During Integration • Recovery (modularity of system)

21. A Good Mistake • Miscommunication • Flight Spare Used • Missions Problems • Flight Unit Available for Another Mission Flight Flight Spare

22. Conclusions • Failure Modes – Cover All the Bases • Complacency – Sometimes Experience Can Be Bad • Communication – Key to Good Design and Success • Experience – Build On It • Modularity – Too Much Can Be Bad • Modularity – Turns bad into good • Luck Beats Skill