REG NASA-LLIS-1743--2006 Lessons Learned Mitigating the Risk of Single String Spacecraft Architecture.pdf

1、Lessons Learned Entry: 1743Lesson Info:a71 Lesson Number: 1743a71 Lesson Date: 2006-04-7a71 Submitting Organization: JPLa71 Submitted by: David Oberhettingera71 POC Name: Jeffrey Nunesa71 POC Email: jeffery.nunesjpl.nasa.gova71 POC Phone: 818-354-8367Subject: Mitigating the Risk of Single String Spa

2、cecraft Architecture Abstract: Mars Exploration Rover met and exceeded mission requirements despite a largely single string spacecraft architecture. Balance the risk of a single string flight system with effective risk management, ample fault tolerance, flight system flexibility, access to experienc

3、ed designers, ample stress testing, use of proven designs, and a rigorous approach to fault protection.Description of Driving Event: The Mars Exploration Rover (MER) project was extremely successful despite the largely single string flight system, which included such single string elements as the fl

4、ight computer and the panoramic camera (Pancam). The lack of backups for many mission-critical system functions was largely due to spacecraft mass limitations. Constrained project resources were also responsible for other design tradeoffs (Reference 1) that increased the risk to mission success. The

5、 following 7 design features or program provisions (Reference 2) mitigated the risks posed by MERs design constraints: 1. Effective Risk Management. The MER risk management approach involved the identification of risks and failure modes at project inception and their continuous modeling throughout d

6、evelopment. For example: a72 MER probabilistic risk assessment (PRA) included development of high level fault trees for the entry, descent, and landing (EDL) event that were completed for the Project Mission, System Design, and Cost Review (PMSDCR). Subsequent Provided by IHSNot for ResaleNo reprodu

7、ction or networking permitted without license from IHS-,-,-preparation and refinement of event trees and lower level fault trees were performed, not to pass reviews, but rather to understand system vulnerabilities and threats to EDL success. Significant failure modes were checked against contingency

8、 plans and reported at mission readiness reviews. The Mars Polar Lander (MPL) 1999 mission failure encouraged MER project management to impose a healthy skepticism towards success. The project continuously demanded proof that the system would work, rather than assuming that risks were acceptable unl

9、ess shown to the contrary. 2. Ample Fault Tolerance. The MER design featured extensive fault tolerance to allow full or degraded operation in the presence of a fault. Examples of this approach include: a72 The MER design did not include a backup flight computer, but multiple EPROMs provided redundan

10、t copies of the boot code and of the flight software. a72 The MER flight system design was tolerant to nearly all transient errors (e.g., power-on-resets) during EDL or on the Martian surface. a72 The Heat Rejection System, which provided active cooling during the Cruise phase, featured a single coo

11、lant filter that could become clogged. However, a check valve permitted the coolant to bypass the filter if the coolant pressure reached a threshold value. a72 The Pancam cameras were effectively single string as both needed to be operational to permit stereoscopic imaging, and both the failure mode

12、s, effects and criticality analysis (FMECA) and the PRA identified failure of a camera as a major risk to rover mobility. JPL planned for a degraded operational mode that could acquire an image from a single working camera, shift the rover several centimeters, take a second picture with the camera,

13、and use ground software to combine the two images into a stereo image. a72 A software commanding error could power a warm-up heater during the Mars daytime when it was not normally powered, and cause overheating. Hence, thermostats were added for fault mitigation. 3. Flight System Flexibility. MER f

14、eatured a very flexible design that, though it resulted in a very complex vehicle, permitted flaws to be corrected after launch: a72 The MER PRA identified EDL as the most risky mission phase. Arguably, this held true for the Genesis and Stardust missions, which hard wired the EDL sequences such tha

15、t they could not be changed after launch. In contrast, MER retained an ability to update critical EDL parameters during the latter stages of encounter and EDL. (See Reference (3).) This included both a flight system capability to uplink software updates during entry, and the operational plan, proces

16、s, and tools for ground personnel to prepare the updates. a72 Rover egress from the lander required the removal of various launch locks by firing pyrotechnic cable cutters and pin pullers in a predetermined sequential order. The firing of the pyro to permit deployment of the rover robotic arm had be

17、en timed to mitigate the risk that the arm might encounter higher than expected dynamic forces during egress. After launch, extensive analysis of the sequence revealed a yet greater risk that another, earlier, pyro firing to cut the final rover-lander cable could enable a sneak circuit that could be

18、 triggered by any subsequent pyro events. (see Reference Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-(4). So a decision was made to reorder the deployment sequence to release the rover arm before the final rover-lander cable cut to prevent activa

19、ting any sneak circuits set up by the rover-lander cable cutter. 4. Experienced Personnel. The lead engineers in each area had an unusually high level of experience, and were in many cases drawn from other current flight projects. These individuals were well acquainted with the MER mission failure s

20、pace, and recent JPL mission failures had negated any complacency about mission risks. The JPL line/project matrix organization facilitates such project access to key personnel. With JPLs reputation at stake, the MER project made sure that each critical failure mode was fully understood and the risk

21、 mitigated before the risk item was retired. (See Reference (5).) 5. Ample Stress Testing. Significant resources were devoted to testing flight system robustness. MER utilized multiple flight system testbeds that were very flight-like. Compared to a project like Stardust that had only pieces of cert

22、ain subsystems, the MER testbeds were hardware-rich and were not as dependent on simulators. (See Reference (6).) Long after launch, the project continued to perform system-level stress testing to identify system performance margins. Just prior to EDL, for example, a decision was made to enable all

23、pyros. This posed a risk of premature pyro firing, but the additional test data indicated a higher risk that the safeties might inhibit a pyro during the firing sequence. 6. Mars Program Synergy. Despite the short MER development schedule, the MER project was able to take advantage of the avionics c

24、oncept and rover designs developed for the 1999 version of the Mars Sample Return project architecture. 7. In-House Project. Because the MER flight system was largely an in-house development, the designers and testers understood how the subsystems worked. Although some items like the radar altimeter

25、 and solar arrays were procured, JPLs lesser dependence on major subsystems provided by other organizations or countries permitted the same rigorous approach to fault protection to be employed at all hardware levels. References: 1. Rob Manning, “MER Project: Stealing Success from the Jaws of Failure

26、, Video Presentation AVC-2005-200,“ September 23, 2005. 2. David Oberhettinger, “Mitigation of Risks Associated with MER Single String Architecture,“ OCE DJO 05-001, November 28, 2005. 3. “Provide In-flight Capability to Modify Mission Plans During All Operations, NEN No.1480,“ NASA Engineering Netw

27、ork (NEN), June 21, 2004. 4. “Plasma Arcs from Pyro Firing May Cause Prolonged NSI Shorts,“ NEN No.1412, NASA Engineering Network (NEN), April 19, 2004. 5. “If You Dont Understand an Environment, Provide Well-Margined Capabilities to Encompass the Worst Case,“ NEN No. 1712, NASA Engineering Network

28、(NEN), December 16, 2005. 6. “The Risk Reduction From Two-fers (Multiple Sister Spacecraft) May Outweigh the Incremental Cost,“ NEN No.1485, NASA Engineering Network (NEN), May 17, 2004. Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-Lesson(s) Learn

29、ed: A system architecture that is highly dependent on single string subsystems can succeed by focusing project resources on intensive analysis of known failure modes and on ample testing.Recommendation(s): Balance the risks of single string spacecraft architectures with effective risk management, am

30、ple fault tolerance, flight system flexibility, access to experienced designers, ample stress testing, use of proven designs, and a rigorous approach to fault protection.Evidence of Recurrence Control Effectiveness: JPL opened Preventive Action Notice (PAN) No. 1474 on July 18, 2006 to initiate and

31、document appropriate Laboratory-wide action on the above recommendations.Documents Related to Lesson: N/AMission Directorate(s): a71 Space Operationsa71 Sciencea71 Exploration Systemsa71 Aeronautics ResearchAdditional Key Phrase(s): a71 Program Management.a71 Program Management.Acquisition / procure

32、ment strategy and planninga71 Program Management.Contractor relationshipsa71 Program Management.Program planning, development, and managementa71 Program Management.Risk managementa71 Missions and Systems Requirements Definition.a71 Missions and Systems Requirements Definition.Level 0/1 Requirementsa

33、71 Missions and Systems Requirements Definition.Planetary entry and landing conceptsa71 Missions and Systems Requirements Definition.Requirements critical to costing and cost credibilitya71 Systems Engineering and Analysis.a71 Systems Engineering and Analysis.Mission and systems trade studiesProvide

34、d by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-a71 Systems Engineering and Analysis.Mission definition and planninga71 Engineering Design (Phase C/D).a71 Engineering Design (Phase C/D).Lander Systemsa71 Engineering Design (Phase C/D).Roboticsa71 Engineerin

35、g Design (Phase C/D).Spacecraft and Spacecraft Instrumentsa71 Safety and Mission Assurance.a71 Safety and Mission Assurance.Early requirements and standards definitiona71 Safety and Mission Assurance.Reliabilitya71 Additional Categories.a71 Additional Categories.Environmenta71 Additional Categories.

36、Flight Equipmenta71 Additional Categories.Flight Operationsa71 Additional Categories.Hardwarea71 Additional Categories.Payloadsa71 Additional Categories.Risk Management/Assessmenta71 Additional Categories.Softwarea71 Additional Categories.Spacecrafta71 Additional Categories.Test FacilityAdditional Info: a71 Project: MERApproval Info: a71 Approval Date: 2006-12-06a71 Approval Name: ghendersona71 Approval Organization: HQProvided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-