Systems Engineering During the Formulation Phase

1
Systems Engineering During the Formulation Phase
January 29, 2007
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
System Engineering
4
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 2 TMC
PMSR
STEP 1 TMC
MCR
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
5
Major Systems Engineering Responsibilities During
Project Formulation

• Objective Achieve Project Balance
• Approach
• Architecture options
• Identifies key trade studies
• Defines functions within and boundaries between
  systems
• Perform trade studies for crosscutting issues
• Requirements development and flowdown
• Science objectives to measurement requirements to
  instrument, platform and mission requirements
• Risk Management
• Margins

6
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
7
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

8
Requirements Hierarchy and Flowdown
9

• 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
10
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

11
ARES Example Payload Requirements Are
Accommodated by Airplane
12
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
• All systems share comparable levels of risk
• All systems designed to the same standards and
  levels of performance

13
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

14
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

15
THOR Mission Architecture Trades
16
ARES Example Key Mission Architecture Trades
High-level architecture options to analyze in
determining Baseline Science Mission
17
Keep A Record of Your Major Trades Document
Performance Improvement and/or Risk Mitigation
18
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

19
ARES Example Descope Options
20
Performance Floor Mission Reduces Complexity,
Increases Margins
21
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

22
Risk Management
23
Risk Rating Matrix
24
ARES Example Risk List
25
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

26
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

27
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.

28
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
29
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
30
Technical Margins
31
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)
32
ARES Example

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