1、Lessons Learned Entry: 1807Lesson Info:a71 Lesson Number: 1807a71 Lesson Date: 2007-12-11a71 Submitting Organization: JPLa71 Submitted by: David Oberhettingera71 POC Name: Glenn Tsuyuki, Robert F. Shotwella71 POC Email: Glenn.T.Tsuyukijpl.nasa.gova71 POC Phone: 818-354-2955 (Glenn Tsuyuki)Subject: I
2、nheritance Review of the Mars Phoenix Flight System Abstract: Despite the unusually large percentage of the Phoenix design and hardware that was inherited from previous Mars spaceflight projects, the format used for Phoenix project system and subsystem Inheritance Reviews (IRs) proved adequate to mi
3、tigate the risk within technical and programmatic constraints. A mission assurance checklist provided acceptance criteria to validate the flight worthiness of each subsystem. Consider using the Phoenix Inheritance Review format as a model for future missions that feature substantial inheritance. Pla
4、n carefully for the collection, analysis, and eventual archiving of records documenting the system and subsystem pedigree.Description of Driving Event: Reuse of NASA hardware, software, or designs that have been inherited from previous projects and proven in testing or spaceflight may help NASA to c
5、ontrol programmatic and technical risk. However, a formal Inheritance Review (Reference (1) is necessary to verify that the inherited product is acceptable, reliable, and compatible with current spacecraft requirements. Best scheduled at the earliest feasible time prior to the equivalent level Preli
6、minary Design Review (PDR), the Inheritance Review (IR) assesses the potential risk associated with product use and the need for modification or additional testing. JPL hopes that Mars Phoenix, the first in NASAs Scout series of highly innovative and relatively low-cost missions, will be the first l
7、ander to physically examine water on Mars. Launched in August 2007, the spacecraft features extensive inheritance (blue-shaded components in Figure 1) from the JPL Mars Surveyor 2001 Lander (MSP01) project that was cancelled in May 2000, which itself was based upon the Mars 98 Polar Lander (MPL). As
8、 70% of the MSP01 lander hardware had already been built, the hardware was moved by the system contractor to cleanroom storage. Available documentation was also stored, although the MSP01 design was largely drawn from the faster-better-cheaper era that limited the extent of engineering documentation
9、. Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-Figure 1 is a color diagram that depicts that extent of Phoenix flight system and payload heritage within the Phoenix subsystems Telecom, Power, GN Telecomm; Propulsion; Structures; Mechanisms; Guidan
10、ce, Navigation, and Control; Flight Software; Simulation Software; Command and Data Handling; Harness; Thermal; ATLO (Integration Support Equipment; and Mission Operations. In planning the subsystem IRs, JPL sought to exceed the minimum level of design penetration needed to prepare for the March 200
11、5 PDR by: 1. Soliciting the participation of the spacecraft system contractor in evaluating the system compatibility of the inherited or commercial off-the-shelf (COTS) product functionality with project Level 1 and Level 2 requirements. 2. Conducting a mission assurance review and system engineerin
12、g review in concert with the subsystem IRs.3. Utilizing a mission assurance checklist that provided acceptance criteria to validate the flight worthiness of each subsystem. The checklist was derived from the form (Hardware Review & Certification Record) that JPL uses to assess the risk to flight har
13、dware posed by mechanical or electrical integration with the system (Reference (3).4. Providing the project with a recommended course of action (e.g., modification or additional testing) in cases where a subsystem did not meet the checklists acceptance criteria. The Phoenix project found the IR form
14、at to be very useful in addressing mission assurance and system engineering needs. For example: 1. Cognizant engineers were very forthright and candid about their hardwares pedigree, and the detailed checklist forced them to actively seek out and review MSP01 and MPL documentation.2. Break-away spli
15、nter sessions at the spacecraft system contractor facilities to review archived MSP01 documents such as Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-drawings, build records, test data and material reviews (MRBs) were very useful in assessing the p
16、edigree of the Phoenix hardware.Although the Phoenix IR plan was well conceived, preparation for the reviews presented difficulties. Collecting all of the MSP01 and Mars 98 documentation (i.e., parts lists, waivers, anomaly reports, MRBs, GIDEP, reliability analyses) and analyzing material storage l
17、ife proved time-consuming. Planning for the IR schedule was inconsistent with the system contractors Phase B workforce ramp-up, and the contractor had to prepare for the reviews at a time when they were focused on expediting long lead-time procurements. Closing action items (e.g., assessment of waiv
18、ers, anomaly reports, environmental qualification, etc.) in time for subsystem Critical Design Review imposed a substantial workload on the Phoenix system contractor cognizant engineers. Certain action items identified by IR, like design changes or additional testing, may necessitate expensive late
19、modifications to the system contract. References: (1) “Subsystem Inheritance Review,“ NASA Preferred Practice for Design & Test No. PD-ED-1262, NEN # 0789, http:/www.nasa.gov/offices/oce/llis/0789.html. (2) “Phoenix Flight System Inheritance Review Lessons Learned,“ Glenn Tsuyuki, March 4, 2005. (3)
20、 “Delivery Review- Hardware Review Certification Record,“ Jet Propulsion Laboratory procedure, JPL Document DocID 67515, December 15, 2005.Lesson(s) Learned: 1. The format used for system and subsystem Inheritance Reviews (IRs) by the high-inheritance Phoenix project proved adequate to mitigate the
21、risk within technical and programmatic constraints.2. Schedule and resource constraints may prevent the benefits of IRs from being fully realized unless the IR process is carefully planned.3. Had the Phoenix project not had under contract the same system contractor as was used for the prior legacy p
22、rojects, JPLs ability to characterize the flight system pedigree years following contract closeout would have been severely curtailed. Even when the engineering analyses delivered by the contractor are accompanied by full supporting documentation, JPL retention and archiving of these schematics, par
23、ts lists, etc. after the flight project is disbanded is not a trivial expense and may not be given a high priority.Recommendation(s): 1. Consider using the Phoenix IR format as a model for future missions that feature substantial inheritance. Prepare and implement the IR plan in concert with mission
24、 assurance program activities. 2. Plan carefully for the collection and analysis of records documenting the system and subsystem pedigree. Provide ample lead time for obtaining missing drawings, parts/materials lists, or test data, and for resolving issues relating to environmental qualification, co
25、mmercial parts, materials storage life, and discrepant analyses. Assign JPL staff to monitor contractor progress in supplying the documentation.3. When specifying deliverable engineering documentation in system contracts, assume that drawings, build records, test data, MRBs, etc., will be needed lat
26、er to assess the pedigree of inherited hardware, software, and system and subsystem designs. Assure that the flight project or the institution makes arrangements to archive project engineering (and supporting) data after the project is disbanded.Evidence of Recurrence Control Effectiveness: JPL has
27、referenced this lesson learned as additional rationale and guidance supporting Paragraph 6.6 (“Engineering Practices: Inheritance“) in the Jet Propulsion Laboratory standard “Flight Project Practices, Rev. 6,“ JPL DocID 58032, March 6, 2006.Documents Related to Lesson: N/AProvided by IHSNot for Resa
28、leNo reproduction or networking permitted without license from IHS-,-,-Mission Directorate(s): a71 Sciencea71 Exploration SystemsAdditional Key Phrase(s): a71 Program Management.a71 Program Management.Acquisition / procurement strategy and planninga71 Program Management.Configuration and data manage
29、menta71 Program Management.Contractor relationshipsa71 Program Management.Program level review processesa71 Missions and Systems Requirements Definition.a71 Missions and Systems Requirements Definition.Configuration control and data managementa71 Missions and Systems Requirements Definition.Planetar
30、y entry and landing conceptsa71 Missions and Systems Requirements Definition.Review boardsa71 Systems Engineering and Analysis.a71 Systems Engineering and Analysis.Planning of requirements verification processesa71 Engineering Design (Phase C/D).a71 Engineering Design (Phase C/D).Lander Systemsa71 E
31、ngineering Design (Phase C/D).Roboticsa71 Engineering Design (Phase C/D).Software Engineeringa71 Engineering Design (Phase C/D).Spacecraft and Spacecraft Instrumentsa71 Integration and Testinga71 Safety and Mission Assurance.a71 Safety and Mission Assurance.Reliabilitya71 Safety and Mission Assuranc
32、e.Review systems and boardsa71 Additional Categories.a71 Additional Categories.Flight Equipmenta71 Additional Categories.Hardwarea71 Additional Categories.Packaging, Handling, Storagea71 Additional Categories.Payloadsa71 Additional Categories.Risk Management/Assessmenta71 Additional Categories.Softwarea71 Additional Categories.SpacecraftAdditional Info: a71 Project: Mars Phoenix ScoutApproval Info: a71 Approval Date: 2008-04-01a71 Approval Name: mbella71 Approval Organization: HQProvided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-
