Systems Engineering During the Formulation Phase

1
Systems Engineering During the Formulation Phase
January 24, 2005
References SMAD text. Chapters 1-4 JPL
Project Manager Roles/Responsibilities Training
2
System Engineering

• Responsibility Direct, coordinate, and monitor
  the system design and product development
  activities to ensure that the Projects intended
  technical content is delivered.
• Understand and communicate the big picture
• Balance risk across science objectives, technical
  implementation, cost and schedule

3
Project Life Cycle
APPROVAL
NASAPhases
IMPLEMENTATION
FORMULATION
JPL Life CyclePhases
Pre-Phase AAdvanced Studies
Phase AMission Systems Definition
Phase BPreliminary Design
Phase CDesign Build
Phase DATLO
Phase EOperations
Major Project Reviews
Project PDR
Project CDR
Assembly, Test Launch Operation Readiness
Review ARR
Critical Events Readiness Review CERR
Concept Review
Operations Mission Readiness Reviews ORR
MRR
Post Launch Assmnt Review PLAR
STEP 1 TMC
STEP 2 TMC
PMSR
Major NASA Enterprise Reviews
Confirmation Review CR
Mission Briefing
Concept/ Proposal Review
Initial Confirmation Review ICR
Major Events
Contract
Commitment, Select for STEP 2
Launch
Down Select for STEP 1
Notes
4
Major Systems Engineering Responsibilities During
Project Formulation

• Requirements development and flowdown
• Architecture options
• Identifies key trade studies
• Defines functions within and boundaries between
  systems
• Perform trade studies for crosscutting issues
• Risk Management
• Margins

5
System Engineers Objective Achieving Balanced
Risk
Margins
Threats
Risk
Power-30
Mass-30
CPU-MS gt2
S/W Loc/ Language
Funding profile
Linked funding
Structure-MS gt2
Battery-40
RDM gt2
Instrument Xface Complex.
Schedule (i.e. Launch Date)
Mission Complexity
Schedule 1 mo./yr.
Testbeds 2
Dollars-25
Data return and quality
Success criteria
Pointing Accuracy
1,000 Operating Hours
Elec. Parts Derating
Delta -V-30
New Technologies
Number of instruments
Partner Cont. Capability
Deployables- MS gt2
JPL Workforce Availability
Thermal 25?
Program Requirements
Physical Environments
Inheritance H/W-S/W
Launch Vehicle Performance
Dynamics MS gt 6 db ENV.
Memory 200
Review Process
Systems Engineering
Fault Tree Analysis Safety Mission Assurance
Failure Mode Effect Analysis Configuration
Management
6
Requirements Development Is Key

• Requirements flowdown from the mission objective
  into a hierarchy that defines the Projects
  technical scope
• What must be done (Functions)
• How well it must be done (Performance)
• Requirements bound scope
• A hierarchy of traceable requirements ensures
  that the Project develops only what is required,
  i.e., no frivolous activities
• A hierarchy of negotiated requirements ensures a
  balanced system design
• Requirements are the basis for the Projects
  verification and validation efforts
• Poorly written, unverifiable requirements are
  trouble

7
Requirements Hierarchy and Flowdown
8

• Numbered ARES Science Objectives are described
  in Section D.1.2
• ARES Instrumentation MS mass spectrometer,
  MAG magnetometer CC context camera, PS
  point spectrometer, ADS air data system

Figure D.2-1 ARES Science, Measurements, and
Platform Selection Flow Directly from MEPAG and
COMPLEX
9
ARES Example Airplane Design Derived Directly
From Science Objectives

• AFS flight altitude driven by science objectives
  1, 2, 4 and 5
• AFS baseline science range requirement driven by
  science objectives 2, 4, 5 and 6
• Derived AFS propulsion and configuration
  requirements

10
ARES Example Payload Requirements Are
Accommodated by Airplane
11
Architecture Options

• Systems engineering personnel are responsible
  for major trades and architecture decision across
  the Project system
• Trades are performed in such a manner so as to
  keep the project system design in balance
• Ensure that all systems share comparable levels
  of risk
• Ensure that all systems are designed to the same
  standards and levels of expectation for
  performance

12
Design Decisions

• Make architecture decisions early
• On a fixed schedule, it is important to keep the
  design process moving
• Enabled by early definition of requirements and
  performance of rapid system analyses
• Design decisions must balance science objectives,
  technical risk, cost and schedule constraints

13
Probability of Mission Success

• For a generic Mars mission,
• Pms PlaunchPTMIPcruisePMOIPEDLPSciencePDataretur
  n
• A selectable concept is likely to have strong
  science, low mission risk, and satisfy the cost
  and schedule constraints
• Pms will drive architecture selections towards
  focused science, simplicity, redundancy,
  reliability, operational flexibility, large
  margins and minimal use of new technology

14
ARES Example Key Mission Architecture Trades
High-level architecture options to analyze in
determining Baseline Science Mission
15
Keep A Record of Your Major Trades Document
Performance Improvement and/or Risk Mitigation
16
Baseline Science Mission Performance Floor

• Baseline Science Mission BSM refers to that
  investigation that, if fully implemented, will
  accomplish the entire set of proposed scientific
  objectives.
• Performance Floor Minimum science return below
  which the investigation is not considered
  justified for the proposed cost. Failure to
  maintain a level of science return at or above
  the Performance Floor as determined by NASA may
  be cause for termination of the investigation.
• Descope Options The difference(s) between the
  Baseline Mission and the Performance Floor will
  be assessed to determine the investigation's
  resiliency

17
ARES Example Descope Options
18
Performance Floor Mission Reduces Complexity,
Increases Margins
19
Risk Management

• Risk Combination of the likelihood of occurrence
  and the severity of the consequences of an event
• Aspects of risk
• Likelihood
• Consequence
• Uncertainty in assessment
• Risk management An organized means of managing
  risk by assuring that uncommitted resources are
  sufficient to enable mission success

20
Risk Management
21
Risk Rating Matrix
22
ARES Example
23
(No Transcript)
24
Margins and Margin Management

• Projects maintain margins in order to provide
  resiliency during planning and implementation
• Projects define, track, and actively manage
  margins throughout the life cycle of the project
• Generally, projects compute and track margins for
  schedule, cost, mass, power, computer throughput,
  memory, telecom and any other parameter or
  resource that is critical to mission success

25
Definitions

• Current Best Estimate (CBE) Cognizant engineers
  best estimate of the system value
• Growth Maximum expected value based on technical
  maturity of the system
• Allocation Maximum allowable value of the system
  based on some physical limit
• Contingency Difference between Growth and CBE
• Generally under system managers control
• Margin Difference between Allocation and Growth
• Generally under project managers control

26
Contingency as a Function of Technical Maturity

• During formulation,
• New designs shall use a 30 or larger contingency
  depending on the nature, maturity, amount of new
  technology/ concepts, and complexity of the
  design
• Inherited designs shall use a 15 or larger
  contingency
• Inherited hardware shall use 10 or larger
  contingency
• Inherited hardware shall use 2 contingency if
  hardware is totally known to be without change,
  and is build-to-print. Any change to these
  conditions should be evaluated and a larger
  growth percentage applied.

27
Technical Margin Calculations
Contingency Max Expected Resource Value CBE
Resource Value Contingency
__________Contingency_________________ X 100
CBE Resource Value Margin Max Possible
Resource Value Max Expected Resource Value
Margin __________ Margin_________ X 100
Max Expected Resource Value
28
Budget Reserves
Definitions Budget Reserve Unencumbered
Budget Reserve/Estimated Cost to Go x 100 Total
Budget Estimated Cost to Go Unencumbered
Budget Reserve Notes 1. Cost to Go includes the
funded schedule margin, but excludes the launch
vehicle costs
29
Technical Margins
30
Schedule Margin
Definitions Total Schedule Planned Activities
Schedule Margin Schedule Margin No Planned
Activities, but Funded Schedule Schedule Margin
Rate Schedule Margin/(Planned Activity
Schedule Margin)
31
ARES Example

• Project will exercise descope options as
  necessary to maintain the above resource profile

32
Example for Last Years Competition EGReSS
33
Europa Science Objectives

• Characterize surface and near surface ice
  composition
• Confirm and redefine possible Europan subsurface
  ocean
• Provide geological visualization of samples and
  the landing site
• Investigate Europan surface mineral composition
• Characterize Europan life sustaining ability and
  the probability of life

34
Baseline Mission
35
Mission ImplementationArchitecture Trades
36
Descope Options

• Descope options will enhance mass, power, cost
  and schedule reserves
• Decisions must be made prior to PDR (End of Phase
  B)

37
Risk Mitigation
38
EGReSS Reserves

• Large reserves ensure a highly conservative
  program
• Program margins reduce mission system risk

39
EGRESS Spending (M FY16)
40
Cost and Reserve Breakdown
All Figures M FY16