Michael.hazen

Managing CPAS Architecture and Requirements Volatility

NASA Project Management Challenge 2010 Michael Hazen Jacobs Technology

Used with permission

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.

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.

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.

5

CPAS Architecture at Project Inception

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.

7

Generation 1 CPAS Requirements and Architecture

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

8

Systems Engineering “Engine” (Ref. 1)

9

$

$ $ $System dependencieswithin asingleorganization

Systems with interdependenciesAcross multiple organizations

System Dependencies (Ref. 2)

10

Interdependency Context Diagram (Ref. 2)

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.

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 .

13

CPAS PTRS Requirements TraceabilityCxP 70000 Constellation Architecture Requirements Document

CxP 72000 Orion System Requirements Document

CEV T-31000 LM Spacecraft Specification

CEV T-31100 LM Crew Module Requirements Specification

CEV T-31209 LM Landing and Recovery Systems Requirements

Subsystem Specification

JSC Design And Procedural Standards JPR

8080.5A

LM-ORN-0080 Interim Requirements Specification for CPAS

CEV T-035208 LM Landing and Recovery Systems Interface

Requirements Document

JSC-64355 CPAS PTRS Assumptions Document

JSC-63497 CPAS Project Technical Requirements

Specification

DraftInterim Release

Legend.

.

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

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.

16

Beyond Stakeholder Expectations Definition

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.

17

EXAMPLE Design Guidance & Direction Document Entry

Main 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 the performance and functional requirements.Discussion: The Aerodynamic Decelerator System specification, the PTRS, and the assumptions document do not specify the deployment altitude of the main parachutes. Without an assumed deployment height on nominal and high altitude aborts, it is impossible to determine if CPAS meets its functional and performance requirements. LM GN&C indicated during the CPAS summit that 8,000 ft would likely be the main chute deployment altitude.Disposition: Use through PDR.Modified: 06/15/09Approval: Tim Fisher CPAS SE&I IPT Chair

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.

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.

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.

21

Alternate Parachute Architecture

21

Drogues deploy thru FBC

Drogues separate FBC from CM

FBC deploys mains and confluence fitting

CM descending under mains

Assess candidate architecture using an “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

Drogue Mortar & Mains Installation Inside the Forward Bay Cover

24

Exercise architecture first approach process

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.

25

IDAT (Integrated Design and Architecture 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)

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

Alternate Architecture Issues

606G 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

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

29

Straight to Mains Sequence

Touchdown, Main Chute Cutaway, CMUS Airbag Inflation

Main Line Stretch

Blunt End ForwardLAS Jettison

Segmented FBCJettison

Straight to Main Deploy(using chosen

ParachuteArchitecture)

29

• A blunt-end-forward LAS jettison approach was chosen for the Generation 2 CPAS architecture

• Used for Pad aborts and low altitude aborts

Parachute Architecture Selection

Parachute 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

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

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)

Role of Testing in Managing Requirements and Architecture Volatility

33

34

Test and Verification influences on requirements & 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

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

Example architecture and requirements 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

Example architecture and requirements 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

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?

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

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

References

1. NPR 7123.1A, NASA Systems Engineering Processes and Requirements. March 2007

2. Department of Defense System of Systems Challenges, JSC Systems Engineering Seminar Presentation. Dr. Judith Dahlman. August 2007

3. Architecture First Approach, DACS (Department of Defense Data & Analysis Center for Software) https://www.goldpractices.com/practices/afa/index.php

41

Questions?

Contact Information Michael HazenJacobs EngineeringJSC Engineering and Science [email protected]

42