Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.


  • Login to see the comments

  • Be the first to like this


  1. 1. Managing CPAS Architecture and Requirements Volatility NASA Project Management Challenge 2010 Michael Hazen Jacobs TechnologyUsed with permission
  2. 2. Introduction Complex systems frequently see requirements and architecture volatility. These kinds of volatility can be aggravated when multiple contractors and government agencies are working to interdependent but loosely coupled schedules. Recent experience on CPAS is used to illustrate some high value / low cost systems engineering approaches to help identify areas of volatility and to address these kinds of issues in a direct manner. 2
  3. 3. Background The Crew Exploration Vehicle (CEV) will land using parachutes much like Apollo did in the 1960s era. NASA decided to provide the parachute portion of the landing system, referred to as CPAS (CEV Parachute Assembly System) as GFE (Government Furnished Equipment) based on NASA Johnson Space Center (JSC) experience with the X-38 and other parachute programs. 3
  4. 4. Background (continued) JSC chose Jacobs Technology from ESCG (Engineering and Science Contract Group) to manage the overall program development. After a detailed selection program, Jacobs chose Irvin Aerospace (now Airborne Systems) to provide the parachutes and mortars for CPAS. 4
  5. 5. CPASArchitectureat ProjectInception 5
  6. 6. Can we just re-use the Apollo design? Some believe that the CPAS design should just be an Apollo carbon copy. Some things have changed since the 1960s technology used by Apollo:  Use of modern materials (Kevlar, Vectran and Spectra) that did not exist in the Apollo era  Drogue parachutes updated to Variable Porosity Conical ribbon.  Main parachute design updated from ringsail technology of the 1960s to the Irvin Quarter – Spherical technology. Numerous CPAS requirements were significantly more demanding than those levied on Apollo. 6
  7. 7. Generation 1 CPAS Requirements andArchitecture Requirements that significantly exceeded those levied on Apollo:  Deployment envelope (max altitude of 72,000 feet vs. 40,000 ft.)  Unprecedented vibration levels  Reliability requirement twice that of Apollo The requirements management paradigm has also changed since the days of Apollo 7
  8. 8. Systems Engineering “Engine” (Ref. 1) 8
  9. 9. System Dependencies (Ref. 2) $System $ $dependencieswithin asingleorganization $ Systems with interdependencies Across multiple organizations 9
  10. 10. Interdependency Context Diagram (Ref. 2) 10
  11. 11. CPAS Mandate Operational parachutes are required to support early program Pad Abort tests. Pad Abort 1 is scheduled for early 2010. More parachutes required to support Ascent Abort tests and early Orbital tests. This mandate for CPAS was challenging with the still draft and evolving parent requirements for Orion. 11
  12. 12. Early Requirements Volatility As the prime contractor prepared for a System Requirements Review, CPAS closely monitored the proposed content of the SRD (System Requirements Document) As the Orion requirements were proposed, lower level requirements were articulated. The following slide illustrates the state of CPAS parent requirements at the CPAS SRR . 12
  13. 13. CPAS PTRS Requirements Traceability CxP 70000 Constellation Architecture Requirements Document CxP 72000 Orion System Requirements Document Legend Draft . CEV T-31000 LM Spacecraft Specification Interim . Release CEV T-31100 LM Crew Module Requirements Specification CEV T-035208 LM Landing and CEV T-31209 LM Landing and Recovery Systems InterfaceRecovery Systems Requirements Requirements Document Subsystem Specification LM-ORN-0080 Interim Requirements Specification for CPAS JSC Design JSC-64355 JSC-63497 CPAS ProjectAnd Procedural CPAS PTRS Technical RequirementsStandards JPR Assumptions Specification 8080.5A Document 13
  14. 14. Meeting the Mandate ! Team Collaboration between CPAS and Lockheed Martin was a big enabler to stop the requirements “tail chasing” by coming up with an explicit set of key requirements that would allow CPAS to proceed with Gen 1 design This set of requirements (without TBDs) was labeled as an “Interim Requirements Memo”, also dubbed “The Prouty Memo”, named after its primary author from Lockheed Martin, Chris Prouty. The memo also included key interface requirements 14
  15. 15. Stakeholder Expectations Clear?A separate assumptions document was developed to: Identify areas of disagreement with interim parent requirements Add needed details where existing requirements were incomplete Articulate perceived interface requirements on the vehicle side of the interface Serve as a stakeholder expectations baseline, formally approved by the program. 15
  16. 16. Beyond Stakeholder ExpectationsDefinition Requirements and architecture volatility can happen within a project too. A clearly defined Architecture and Requirements baseline to capture derived requirements and architecture decisions is essential A Design Guidance & Direction Document was developed to communicate key technical decisions and ground rules within the project and to ensure stakeholders were kept fully informed. 16
  17. 17. EXAMPLE Design Guidance & Direction Document EntryMain Chute Deployment AltitudeDesign Item: 09-009aOwner: CPAS SE&I IPTDate: 05/07/2009Issue: Main Chute Deployment AltitudeGuidance: CPAS will use 8,000 ft MSL to determine if it meets theperformance and functional requirements.Discussion: The Aerodynamic Decelerator System specification, thePTRS, and the assumptions document do not specify the deploymentaltitude of the main parachutes. Without an assumed deploymentheight on nominal and high altitude aborts, it is impossible to determineif CPAS meets its functional and performance requirements. LM GN&Cindicated during the CPAS summit that 8,000 ft would likely be the mainchute deployment altitude.Disposition: Use through PDR.Modified: 06/15/09Approval: Tim Fisher CPAS SE&I IPT Chair 17
  18. 18. Getting Program Buy-In Getting CEV program concurrence at each step of the requirements and architecture volatility management process is a key enabler. The GFE Equipment and Materials Control Panel (GEMCP) was empowered to provide directives to CPAS to formalize CPAS Generation 1 requirements. This concurrence allowed parachute development to proceed without undue risk and with direct involvement of key stakeholders. 18
  19. 19. Architecture Changes due to Stability Concerns Significant oscillations of the crew module under drogues could result in a “flipped” crew module which would amount to a backwards (or apex forward) parachute deployment. Confirmed by early drop tests Confirmed by extensive simulations using evolving Orion aerodynamics data base. 19
  20. 20. Step Back to Look at the “Big Picture”  A proposal was brought forward for a significantly different parachute architecture to address these stability concerns. 20
  21. 21. Alternate Parachute ArchitectureDrogues deploy thru FBC Drogues separate FBC from CM FBC deploys mains and confluence fitting CM descending under mains 21 21
  22. 22. Assess candidate architecture usingan “architecture first” approach (Ref. 3)  Elicit Architectural Requirements  Document the architecture  Analyze the architecture  Stakeholders / scenarios  Independent reviewers  Prove Architecture will meet stated requirements  Realize the architecture  Maintain the architecture 22
  23. 23. Drogue Mortar & Mains InstallationInside the Forward Bay Cover
  24. 24. Exercise architecture first approachprocess CPAS now owns FBC separation and recontact avoidance. Mains just too heavy for effective deployment using forward bay cover – so move to forward bay cover deployed pilot chutes which in turn will deploy mains. Benefits of moving to alternate architecture starting to degrade. IDAT team commissioned to sort out the real “big picture” including not only CPAS, but the entire vehicle. 24
  25. 25. IDAT (Integrated Design andArchitecture Team) membership Crew Module Office / CPAS/ Airborne (Irvin) / Lockheed Martin Non-advocate technical experts  Consultants (includes Apollo era experts)  NESC (NASA Engineering Safety Center)  JPL (Jet Propulsion Laboratory) 25
  26. 26. Alternate Architecture Challenges Integrated system challenges were identified in baseline design (606G) of Orion Entry, Descent, and Landing (EDL) architecture  First openly discussed at May 2009 “CPAS Summit”  Issues were symptomatic of a highly coupled architecture 26
  27. 27. Alternate Architecture Issues606G Baseline Issues Main chute volume FBC near-field re-contact Drogue load mass threats (chute inflation, mortar kick-loads) Drogue harness extraction thru TPS Aux chute packaging and deployment Reliability – probability of loss of crew 27
  28. 28. IDAT Recommendations  Forward Bay Volume  Backshell Outer Mold Line change from 32.5 to 30 degrees  Steel risers for both mains and drogues to enable “any attitude” parachute deployment  Forward Bay Cover – 6 Segments  Launch Abort System (LAS) Abort Conops - Straight to Mains 28
  29. 29. Straight to Mains Sequence Blunt End Forward LAS Jettison• A blunt-end- Segmented FBC Jettisonforward LASjettison approachwas chosen forthe Generation 2 Straight to Main Deploy (using chosen ParachuteCPAS architecture Architecture)• Used for Pad Main Line Stretchaborts and lowaltitude aborts Touchdown, Main Chute Cutaway, 29 CMUS Airbag Inflation 29
  30. 30. Parachute Architecture SelectionParachute Architectures Considered Modified Apollo (three point drogue harness) 3 Drogues 3 mains concept where each drogue would extract one of the main chutes at the right time Ultimately selected “classic Apollo” 30
  31. 31. Classic Apollo Drogues  2 each attached to flower pot gusset  Each cut away with single dual-initiated cutter Main parachutes  3 each attached to flower pot gusset  Each deployed by use of individual mortar deployed pilot parachutes 31 31
  32. 32. Classic Apollo? Isn’t that where we were when we started this journey for CPAS?  Yes and No – we did not start with an integrated design solution and architecture. Smooth sailing now?  No – we still have some unprecedented requirements that will likely result in additional requirements and architecture volatility  Using test planning to explicitly address key risks (not only identify the risks but take concrete action to abate) 32
  33. 33. Role of Testing in ManagingRequirements and Architecture Volatility 33
  34. 34. Test and Verification influences onrequirements & architecture volatility Engineering development unit tests are key in validating requirements and candidate architectures  Extensive Monte Carlo simulations are anchored by test data.  Assessment of which tests are architecture specific helps to zero in on testability aspects of candidate architectures Early validation of performance requirements revealed several problems and risks 34
  35. 35. Risk Assessment Extensive brainstorming sessions were conducted with grey beards from the Apollo era and parachute experts from both industry and the government This enabled identification of requirements and architecture attributes which posed the greatest risk. 35
  36. 36. Example architecture andrequirements risk areas identified Architecture  High Risk: Drogue Harness Deploy, Pilot off-angle deployment  Medium Risk: Drogue confluence, Pilot deployment and inflation  Low Risk: Two drogue chute / two aux chute performance 36
  37. 37. Example architecture andrequirements risk areas identified Requirements  High Risk: Drogue High Altitude, two mains  Medium Risk: high body rate deployment, riser abrasion, skipped reefing stages  Low Risk: Main riser twist, one drogue and two mains 37
  38. 38. Requirements related enablers Master Verification Plan –ask specifically “how can that requirement be verified?” NESC proposed statistical “design of experiments” test approach associated requirements impact NESC proposed component level verification assessment – are end item specs needed? 38
  39. 39. Looking Ahead A stakeholder-wide Entry Descent and Landing Focus Integration Team (EDL FIT) has been established to ensure future design decisions reflect truly integrated solutions 39
  40. 40. Closing Comments Requirements & architecture volatility is part of the job The techniques described in this presentation helped CPAS to ensure the right system (right requirements and architecture) is built BEFORE anyone’s life depends on the successful operation of CPAS Part of Systems Engineering’s role is acting as the project’s “technical conscience” as requirements and architecture volatility issues are addressed 40
  41. 41. References1. NPR 7123.1A, NASA Systems Engineering Processes and Requirements. March 20072. Department of Defense System of Systems Challenges, JSC Systems Engineering Seminar Presentation. Dr. Judith Dahlman. August 20073. Architecture First Approach, DACS (Department of Defense Data & Analysis Center for Software) afa/index.php 41
  42. 42. Questions?Contact InformationMichael HazenJacobs EngineeringJSC Engineering and Science 42