1. 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.
2
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. 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
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. 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
7
9. System Dependencies (Ref. 2)
$
System
$ $
dependencies
within a
single
organization
$
Systems with interdependencies
Across multiple organizations
9
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. 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
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. 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. 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.
16
17. EXAMPLE Design Guidance & Direction Document Entry
Main Chute Deployment Altitude
Design Item: 09-009a
Owner: CPAS SE&I IPT
Date: 05/07/2009
Issue: Main Chute Deployment Altitude
Guidance: 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/09
Approval: Tim Fisher CPAS SE&I IPT Chair
17
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. 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. 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
22. 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
23. 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.
24
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. 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
28
29. Straight to Mains Sequence
Blunt End Forward
LAS Jettison
• A blunt-end- Segmented FBC
Jettison
forward LAS
jettison approach
was chosen for
the Generation 2
Straight to Main Deploy
(using chosen
Parachute
CPAS architecture Architecture)
• Used for Pad Main Line Stretch
aborts and low
altitude aborts
Touchdown,
Main Chute Cutaway, 29
CMUS Airbag Inflation
29
30. 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
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)
32
33. 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
34
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. 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
37. 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?
38
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. 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. 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
