REG NASA-LLIS-1806--2007 Lessons Learned Capture of Apollo Lunar Module Reliability Lessons Learned Program Engineering Management.pdf

1、Lessons Learned Entry: 1806Lesson Info:a71 Lesson Number: 1806a71 Lesson Date: 2007-09-25a71 Submitting Organization: HQa71 Submitted by: David Oberhettingera71 POC Name: Dr. Bette Siegela71 POC Email: bette.siegelnasa.gova71 POC Phone: 202-358-2245Subject: Capture of Apollo Lunar Module Reliability

2、 Lessons Learned: Program/Engineering Management Abstract: A July 2007 workshop attended by Constellation Program personnel traced the success of the Apollo Lunar Module designers to the NASA and contractor culture, Grummans flat organization structure, an ability to hire the “best and brightest“ en

3、gineers, placement of the Reliability function within System Engineering, definition of a “reference mission“ common to all design elements, and strong configuration control. However, little formal training was provided, and limited best practice or lesson learned information was available.Descripti

4、on of Driving Event: As part of the Constellation Programs review of human spaceflight lessons learned, NASA hosted a July 20, 2007 panel discussion with a group of retired engineers who were members of Grumman Corporations Apollo Lunar Module Reliability and Maintainability Team. One of the lessons

5、 learned that was discussed focused on the Apollo program/engineering management approach to reliability (Reference (1): The Apollo engineering culture proved key to meeting objectives in a program environment in which technical performance was primary, schedule was secondary, and cost was a distant

6、 third. Throughout the program life cycle, the Grumman and NASA cultures encouraged (1) an environment of open communications that fostered attention to detail; (2) a focus on the mission rather than on the organization; (3) ability to challenge technical assumptions; (4) assignment of Provided by I

7、HSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-managers to work as technical contributors; (5) worker buy-in or ownership of the design, schedule, and flights; (6) a high level of dedication by NASA and contractor personnel; (7) astronauts who were visible to th

8、e design team; and (8) a contract type (e.g., Cost-Plus-Fixed-Fee) that matched the program priorities. Anyone could challenge a design at any time, and Grumman challenged NASA expertise as often as the customer confronted the contractor. Astronauts were “always there“ at Grumman, and that their liv

9、es were visibly at stake exerted pressure on engineers to “do things right the first time“ wherever possible. Business arrangements influenced the program results: had the Grumman Cost-Plus-Fixed-Fee contract instead been issued for a fixed price, then technical objectives could not have dominated o

10、ver cost. To complement this culture, Grummans Apollo program organization was very flat, with a minimal number of layers. The site organizations were structured to mirror the NASA headquarters organizational structure such that all Grumman personnel knew the identity of their NASA counterparts. Str

11、ong technical expertise was provided at all levels of the organization. Program management personnel had strong technical backgrounds, and the purchasing personnel who were initially responsible for subcontract management were soon replaced with technical personnel. The national priority and public

12、interest focused on the Apollo program meant that NASA and its contractors could attract the countrys best engineers and scientists. Unlike NASA, the reliability function was placed within the Grumman systems engineering organization instead of the mission assurance organization. This relationship e

13、nabled the Systems Reliability Group at Grumman to be deeply involved in system design and in the review of design tradeoffs. Grumman recognized that it was the reliability part of system engineering that would determine the early system configuration. Although subsystem engineering (e.g., propulsio

14、n, crew environmental control) reported vertically, the systems engineering organization (e.g., thermal, dynamics) was structured horizontally to assure technical penetration of design interfaces. When subsystem managers reported a failure mode, it was easy for Systems Engineering to task system int

15、egration engineers to modify interface hardware, and then advise the Crew Systems Group to modify the Caution & Warning System, Simulator Operations (crew training), and Mission Rules as necessary. Reliability was a concern at all levels of the engineering and program organizations. Organizational i

16、nterfaces with Grumman subcontractors and suppliers permitted reliability products, such as Failure Mode and Effects Analyses (FMEAs) used to find single point failures, to cover all hardware tiers. Nevertheless, problems occurred on certain assemblies (e.g., batteries) where FMEAs were not passed d

17、own to subcontractors. Also, there may have been more duplication of engineering analysis between NASA and Grumman (and other system contractors) than was necessary. Given that ground support equipment (GSE) was a large part of the program, the organizational separation between the engineering of GS

18、E and flight hardware may not have been optimal. This constrained the close examination of GSE failure modes (e.g., over-voltage conditions) that could harm flight equipment. Apollo Lunar Module design engineering focused on the early resolution of (1) reliability problems Provided by IHSNot for Res

19、aleNo reproduction or networking permitted without license from IHS-,-,-related to interfaces and (2) other critical design issues such as micrometeoroid protection and the Landing Gear Subsystem. This was facilitated by lunar mission planning performed by Grummans Apollo Mission Planning Task Force

20、 (AMPTF), which designed the baseline vehicle and established ground rules and constraints (e.g., daylight launch, daylight landing near the lunar equator, water landing on Earth) to serve as a baseline for the mission design. Establishment of the AMPTF assured that all design elements were traceabl

21、e to a common “reference mission,“ and that design organizations did not make inconsistent design assumptions (e.g., regarding the capacity of the propellant tanks). Functional diagrams were used for reliability analysis, as well as for educating new project staff on the detailed lander design. The

22、design engineering process featured strong configuration control, with Grumman project management represented on the Apollo Lunar Module change control board. This change control board was given significant authority: the NASA and contractor program managers met, decided on a course of action, and i

23、ssued a joint program directive. The initial Apollo core competencies and technical skills in reliability engineering were not that high by todays standards, as experience was limited to the Mercury and Gemini programs. Most training was performed on the job, although this proved adequate. Training

24、materials were not widely available: instead, functional diagrams were used for training as they were developed. Although reliability engineering was an established field, little information on best practices or lessons learned was available. References: 1. Gerry Sandler (Ret.), “Presentation on Apo

25、llo/Lunar Module Reliability,“Apollo Lunar Module Reliability and Maintainability Team, Apollo Lunar Lander Team Lessons Learned Workshop, July 20, 2007.2. Greg J. Marien, “Engineering Design Challenges of the Lunar Lander,“ AIAA 2004-5889, Space 2004 Conference and Exhibit, San Diego, California, S

26、ep. 28-30, 2004, htttp:/pdf.aiaa.org/getfile.cfm?urlX=5%3A7I%276D%26X%5BRS%22SPWUWT%5B%5EP%2B%3B%3A7%2A%2C%2C%0A&urla=%25%2AB%2C%27%21%404%20%0A&urlb=%21%2A%20%20%20%0A&urlc=%21%2A0%20%20%0A&urle=%27%2ABP%23%220%22AU%40%20%20%0ALesson(s) Learned: The Constellation lunar lander program faces challeng

27、es similar to those faced by the Apollo program 45 years ago in terms of establishing an engineering culture and organization appropriate to the mission, obtaining the necessary design expertise, retiring technical risks, and capturing best practices and lessons learned.Recommendation(s): 1. Take st

28、eps early in the program to assure that (1) the desired engineering culture is attained Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-and (2) the participating engineering organizations baseline compatible and consistent engineering requirements an

29、d tradeoffs. 2. Infuse a high level of technical expertise throughout the organization. 3. Provide a flat organizational structure for design engineering to assure that system and reliability issues are visible throughout the organization. Interface reliability systems (e.g., Grummans FMEAs) with su

30、bcontractor and supplier reliability systems. 4. Prioritize skills development, including an emphasis on application of lessons learned and best practices. 5. Plan engineering processes to assure the appropriate level of redundancy, without undesirable duplication of effort, between the engineering

31、work performed by NASA and system contractors.Evidence of Recurrence Control Effectiveness: JPL has referenced this lesson learned as additional rationale and guidance supporting Paragraph 5.4 (“Project Organization, Roles and Responsibilities, Internal Communications, and Decision-Making“), Paragra

32、ph 5.5 (“Work Breakdown Structure“), Paragraph 5.12 (“Project Staffing and Destaffing“), Paragraph 5.22.1 (“Lessons Learned“), Paragraph 6.15 (“Configuration Management“), Paragraph 7.2 (“Reliability Engineering“), and Paragraph 7.6.8 (“Safety and Mission Assurance Practices: Problem Reporting“) in

33、the Jet Propulsion Laboratory standard “Flight Project Practices, Rev. 6,“JPL DocID 58032, March 6, 2006. In addition, JPL has referenced it supporting Paragraph 2.8 (“Mapping to Additional Rationale“), Paragraph 3.0 (“Mission Design“), and Paragraph 4.1.3.1 (“Flight System Design: Design Robustness

34、- Single Failure Tolerance“) in the JPL standard “Design, Verification/Validation and Operations Principles for Flight Systems (Design Principles),“ JPL Document D-17868, Rev. 3, December 11, 2006.Documents Related to Lesson: 1. NASA-STD-8729.1, “Planning, Developing and Managing an Effective Reliab

35、ility & Maintainability Program”2. MIL-STD-1543, “Reliability Program Requirements for Space and Launch Vehicles”3. MIL-STD-2070, “Procedures for Performing a Failure Mode, Effects & Criticality Analysis for Aeronautical Equipment”4. SP 6105, “NASA System Engineering Handbook”5. IEEE 1220, “Standard

36、 for Application and Management of the Systems Engineering Process”6. ISO15288, “Systems Engineering System Life Cycle Processes”Mission Directorate(s): a71 Exploration SystemsProvided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-Additional Key Phrase(s):

37、a71 Program Management.Acquisition / procurement strategy and planninga71 Program Management.Center distribution of programs and management activitiesa71 Program Management.Communications between different offices and contractor personnela71 Program Management.Configuration and data managementa71 Pr

38、ogram Management.Contractor relationshipsa71 Program Management.Cross Agency coordinationa71 Program Management.Risk managementa71 Program Management.Role of civil service technical staff versus contractor staffa71 Missions and Systems Requirements Definition.Configuration control and data managemen

39、ta71 Missions and Systems Requirements Definition.Crew operations and support conceptsa71 Missions and Systems Requirements Definition.Mission concepts and life-cycle planninga71 Missions and Systems Requirements Definition.Planetary entry and landing conceptsa71 Missions and Systems Requirements De

40、finition.Vehicle conceptsa71 Systems Engineering and Analysis.Engineering design and project processes and standardsa71 Systems Engineering and Analysis.Level II/III requirements definitiona71 Systems Engineering and Analysis.Long term sustainability and maintenance planninga71 Systems Engineering a

41、nd Analysis.Mission and systems trade studiesa71 Systems Engineering and Analysis.Mission definition and planninga71 Systems Engineering and Analysis.Planning of requirements verification processesa71 Engineering Design (Phase C/D).Lander Systemsa71 Engineering Design (Phase C/D).Simulators and Trai

42、ning Systemsa71 Engineering Design (Phase C/D).Spacecraft and Spacecraft Instrumentsa71 Integration and Testinga71 Mission Operations and Ground Support Systems.Lunar Operationsa71 Mission Operations and Ground Support Systems.Mission control Planninga71 Mission Operations and Ground Support Systems

43、.Training and simulation systemsa71 Safety and Mission Assurance.Configuration Change Controla71 Safety and Mission Assurance.Early requirements and standards definitiona71 Safety and Mission Assurance.Product Assurancea71 Safety and Mission Assurance.Reliabilitya71 Additional Categories.Configurati

44、on Managementa71 Additional Categories.Flight Equipmenta71 Additional Categories.Flight Operationsa71 Additional Categories.Ground Equipmenta71 Additional Categories.Ground Operationsa71 Additional Categories.Hardwarea71 Additional Categories.Independent Verification and Validationa71 Additional Cat

45、egories.Launch Vehiclea71 Additional Categories.Mishap Reportinga71 Additional Categories.Payloadsa71 Additional Categories.Risk Management/AssessmentProvided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-a71 Additional Categories.Safety & Mission AssuranceAdditional Info: a71 Project: ApolloApproval Info: a71 Approval Date: 2008-05-09a71 Approval Name: mbella71 Approval Organization: HQProvided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-