A Systems Engineering Approach to Designing
Complex Systems
Dr. Michael Winter, Mr. Randy Skelding, & Dr. Ravi Rajamani
Pratt & Whitney, United Technologies Corporation
This document contains no technical data.
United Technologies
Business units
aerospace
systems
commercial
power
solutions
commercial
building
systems
2
PRATT & WHITNEY
Leading industry change
Commercial
Engines and
Global Services
P&W
Rocketdyne
Power
Systems
P&W Canada
Military
Engines
System Engineering Process Driven by Product Needs
Propulsion System Complexity Driving Need for More Robust Systems Engineering
Process and Tools
Variant-common F135
Turbomachinery
Integrated
Integrated TEC
TEC
&
& Augmentor
Augmentor
Lift Fan, Clutch,
& Driveshaft
3-Bearing
3-Bearing
Swivel
Swivel Duct
Duct
Roll
Roll Control
Control
Ducts
Ducts and
and Nozzles
Nozzles
LO
LO Axi-symmetric
Axi-symmetric
Nozzle
Nozzle
Controls & externals,
engine gearbox
Pratt
Pratt&&Whitney
Whitney
Rolls-Roy
Rolls-Royce
ce
Hamilt
Hamilton
onSSundstrand
undstrand
System of Systems
4
Modern Gas Turbine Optimization is an Exercise in
Managing Complexity
~ 80,000 PARTS
~5000 PART NUMBERS
~ 200 MAJOR PART NUMBERS
REQUIRING 3D FEA/CFD ANALYSIS
~ 5000-10,000 PARAMETRIC CAD
VARIABLES DEFINE MAJOR
PART NUMBERS
~ 200 MAN-YEAR ANALYTICAL
DESIGN EFFORT
~ 200 MAN-YEARS
DRAFTING / ME
EFFORT
5
Requirements Management
Output
Company
Program
Job
Ticket
System
SRD
Module
CRD
Part
PRD
Requirements Flow to 3 Levels
Job Ticket or Contract => Requirements
Job Ticket measures compliance to requirements
Program
Job Ticket
System Parameter
Product / Service Solution
Performance
System
Weight
Efficiency
Reliability
Roles
“Activities”
Deliverables
System = Part I
Operability
Augmentor
Module
Fan = Part II
Observability
Cost
Maintenance Cost
Durability
Part
Fan Blade = Part III
System Analysis & Optimization
Execution
THERMALS
Optimization
Simulation
CAD/CAM
Y1
Computational Systems Engineering
DRAFTING
MFG
A
C
E
B
D
Complex Designs are Inherently Iterative & Bounded
CAD
MODEL
PHYSICS
MODEL
DESIGN SPACE
WORK
INSTRUCTIONS
- NON LINEAR
- MULTI MODAL
- DISCONTINUOUS
- NOISEY
- HIGHLY CONSTRAINED
DESIGN
STANDARD
WORK
CRITERIA
VALIDATED
ANALYSIS
DECISION
Manual Iteration 100s-1000s of Times
PREFERRED
CONFIGURATIONS
9
Sophisticated Simulation Based Design Systems
10
…and Complex Designs are Iterated Across
Disciplines & Organizations…
FEED FORWARD
IPT
PROCESS
CYCLE
FEEDBACK
1D AERO
COOLING
FLOWS
3D
STAR AERO
PROSTAR 3.00
23-SEP-97
VIEW
1.000
1.000
1.000
ANGLE
0.000
DISTANCE
6.549
CENTER
10.138
-0.554
0.776
EHIDDEN PLOT
HEAT X
DESIGN
PLATFORM
NECK
ATTACHMENT
DISK & SEALS
X
Y
Z
11
. . . And Iterations Can Take Place Across the Globe
• OUTSOURCING
• INTER-DIVISIONAL
• PARTNERSHIPS
• CUSTOMERS
12
Gains are Being Made by Shifting from “Human” to
“Computer” Based MDO
“HUMAN” BASED
“COMPUTER” BASED
Program
IPMT
Program Standard Work Flow
0
Business Plan
Concept &
Venture
Definition
I
Integrated
Business
& Project Plan
Product/ Industrial
Plan Execution & FETT
II
III
Validate, Certify,
Deliver
IV
EIS, Operational
Service
& Support
WORKFLOW, RULES,
And DESIGN ITERATIONS
AUTOMATED WITHIN
And ACROSS SYSTEMS
& DISCIPLINES
V
System
CIPT
CIPT
CIPT
Select
Concept
Program
Launch
After
FETT
Release to
Production
0
Concept
Optim ization
I
Prelim inary
Design
2
Product Design
Procurement &
Initial Validation (FETT)
3
Validation/
Certification
4
Airplane
Validation
Service &
Support
5
IPT
Concept
Optim ization
I
Prelim inary
Design
2
Product Design
Procurement &
Initial Validation (FETT)
3
Validation/
Certification
4
Airplane
Validation
Service &
Support
5
I
Prelim inary
Design
I2
Product Design
Procurement &
Initial Validation (FETT)
3
Validation/
Certification
Airplane
Validation
Service &
Support
Concept
Initiation
3
4
IPT
1 1 1 1 1
2 2 2 2 2
3 3 3 3 3
4 4 4 4 4
IPT
1 1 1 1 1
2 2 2 2 2
3 3 3 3 3
4 4 4 4 4
IPT
NON-ANALYTICAL
2
IPT
NON-ANALYTICAL
1
IPT
NON-ANALYTICAL
LEVELS OF FIDELITY
Module
Concept
Initiation
Part
1 1 1 1
Concept
Initiation
Concept
Optim ization
2 2 2 2
2.5
4
5
Engineering Standard Work Flow
3 3 3 3
4 4 4 4
-- LABOR INTENSIVE --
SYSTEM
SUB-SYSTEM A
SUB-SYSTEM B
MANUAL WORK FLOW per PROCESS
MAPS
AUTOMATE WORKFLOW
MANUAL CAD/CAE MODEL BUILDING
AUTOMATE MODEL BUILDING & EXECUTION
MANUAL EXPLORATION TO FIND
OPTIMAL DESIGNS
AUTOMATE DESIGN EXPLORATION
13
Large Scale Computer Based MDO is Already
Practical
3D Aero-Vibratory Shape Optimization Of A Cooled Turbine Airfoil
(Single Row RANS CFD, Cooled UG Parametric Model, 3D ANSYS Vibes)
AIRFOIL
SHAPE
3D AERO
CFD
PARAMETRIC
CAD
MESH
OPTIMIZER
VIBRATORY
ANALYSIS
CAMP BELL DI AGRAM
STRESS
MODE 1
EFFICI ENCY
MODE 3
MODE 4
Aero Xsections
0.5
0.4
Area
MODE 2
0.3
Initial
0.2
Iteration 515
0.1
0
AreaS1 AreaS2 AreaS3 AreaS4 AreaS5
14
Large Scale Computer Based MDO is Already
Becoming Practical
3D Shape Optimization Based On Hybrid Genetic Algorithm & Rule System
(3D RANS Multi Row CFD, Population Size 80, Total Runs 2400, Run Time 48 hrs on 40CPUs)
DELTA TURBINE EFFICIENCY
LOSS CONTOURS
150 VARIABLES
15 CONSTRAINTS
0.6
0.4
LOSS CONTOURS
Discovered “bowed” rotor
To control tip leakage
Vortex
0.2
0.0
0
10
20
GENERATION
30
15
Will Enable New Design Paradigms
CUSTOMER NEEDS
UNDERSTAND THE FUTURE
CREATE TECHNOLOGY
ENGINEERS
COMPUTER BASED DESIGN
RUN 24/7 365 DAYS
A YEAR
CONTINUOUS
DETAILED DESIGN
IMPROVE MODELS
RE-FORMULATE PROBLEM
SOLVE ALL POSSIBLE
APPLICATIONS @
TECHNOLOGY
READINESS LEVEL
UPGRADE COMPUTER
BASED DESIGN “MACHINE”
CUSTOMER REQ. EXCEED TECHNOLOGY
LESS TIME
FEWER PEOPLE
16
Verification - Convergence to Requirements
Value (e.g.. Weight)
Technical Performance Measurement Tracking Chart
Tolerance Band
Planned Profile)
(±x s)
Actual Profile
NTE (Not to Exceed)
Goal
Milestones
Time
Convergence to Requirements
Dry engine weight (lbs)
5450
5400
5424
Commitment 5400 lb
5350
5338
-29 lb
5318
5300
5286
5289
Average
Compliance
EIS
Projected
5250
Compliance
1
Compliance
2
Status
Entry Into Service >100 lbs Below Commitment
18
Generic 2 Spool Gas Turbine Engine Diagram
ITT
N1
N2
PB
Source: Wikipedia
commons
EGT
Putting Rigor into System Requirements with Requirements
Modeling
The classical “paper” based method for
Systems Requirements
Picture Source: Dr Peter Hoffman – IBM / Rational
The classical “paper” based method for
Systems Requirements
Picture Source: Dr Peter Hoffman – IBM / Rational
Requirements
Requirements are explicit contracts between the system
element that consumes a product feature and the
system element that provides it.
• There are two major types of requirements.
– Product Requirements “the system shall”
– Statement of Work (SOW) Requirements “the
contractor shall”
• Product Requirements specify something the product
must do or a quality the product must have.
– “The engine shall generate up to 20000 pounds of
thrust during engine operation.”
Focus on Product Requirements
Product Requirements
• Product Requirements further classified as:
• Functional Requirements specify a task or
activity the system must perform & its duty cycle.
• Performance Requirements specify a constraint
on how the system should perform a functional
task.
Performance Requirements linked to Functional Requirements
Modeling Overview
• Models are abstractions that allow us to focus on a
solution to a particular problem.
Abstractions are essential to managing complexity.
• Abstractions can be layered
• accurately represent essential content
• high fidelity and still remain simple.
– The key to managing layers is to control the complexity of
both the layer and its interfaces to other layers.
– Push the details as low as possible but keep the essential
meaning at all levels.
Keep each layer simple & push the details down
Models have different purposes
• Functional Modeling
– Logical relationships between activities and sequences in
time
• Parametric Modeling
– Extends Functional Modeling to include equations or
models of constraints on physical and functional elements.
Data/Results may be collected by repeated computer runs
in time-domain or thru a separate Monte Carlo analysis.
• Dynamic Modeling
– Focus is on mathematical representations of physical
behavior of system or subsystem components. This may
or may not be time domain.
• Business / Economic Modeling
– Focus is on cost and schedule
Connect the network of models together
Functional Modeling – Activity Diagrams / Tasks and
Control Flow
Activity Diagram
Start, Stop, Operate Engine
Functional Modeling
• Requirements Modeling elucidate functional product
requirements and their inter-relationships
• It is designed to catch situations like the following
• Page 257 states “The valve shall be on” when yyy.
• Page 5205 states “The valve shall be off” when zzz
• But the yyy and zzz conditions overlap, so the valve has to
be both on and off at the same time.
• State space of the system based on an analysis of
the system requirements.
ON or OFF but not both
Modeling – Overview - Parametric Modeling
Distiller - SYSML Parametric Model
28
Modeling – Overview - Dynamic Modeling
Rocket Engine – SIMULINK model
29
Modeling – Form of model should match
purpose
–
–
–
–
–
SYSML is ideal for functional modeling
UML is ideal for Software Architecture and Design
MATLAB / SIMULINK is ideal for Control System work.
NPSS is ideal for Aerodynamic simulations.
Mathmatica is ideal for symbolic calculations and
mathematics.
– Minitab is ideal for statistical calculations.
– Microsoft Excel is also a modeling tool!
Pick the model to match the problem
What is SYSML?
UML not
required
by
SysML
UML reused by
SysML
INCOSE slide – from tutorial
by “The Aerospace
Corporation”
UML
• SysML:
•
•
Reuses a subset of
UML 2.0
Uses UML 2.0 profile
mechanisms to specify
extensions for SysML
UML4SysML
SysML
SysML
extensions
to UML
(Have no counterpart in UML
or place UML constructs)
SysML tailored for Systems Engineering
31
Example Drawings for a Functional Modeling
using SYSML
• Use Case Diagram – captures system or subsystem scope
• Activity Diagram – captures tasks and control flow
• Internal Block Diagram – captures system structure and
interfaces
• Sequence Diagram – captures details of interactions
between system and external actors.
• State Diagram – details states and modes of system.
To be shown in demo
The Harmony Mini Cycle – as we use it
Draw / Modify Use Case Diagram
Generate/Modify Internal Block Diagram
Draw High Level Activity Diagrams
Add parameters, attributes,
and messaging
Annotate and finalize
message sequences
Create Ports, Interfaces, and Links
Draw Detailed Activity Diagrams
Draw State Charts
Generate Sequences
Animate and Execute
To be shown in demo
Family of use cases – highest level system
description
Use Case Diagram – Gas Turbine Engine – family of use cases
What does the engine need to do?
Lets zoom in so we can read the diagram
Pick a
particular use
case – Operate
Engine
Engine Startup and Shutdown – Problem
Overview
• To start a gas turbine engine:
– Turbine Rotation established by Air Starter Subsystem –
driving generator for power and pressure for pumps
– Fuel flow is enabled.
– Proper Fuel / Air mix is established in combustion
chamber.
– Electrical spark from Ignition - Subsystem starts
combustion.
– Conditions monitored for automatic restart if necessary.
– Controlled ramp increases fuel flow per schedule to
achieve stable idle
• Cockpit switch semantics rationalized with standard signals
& start sequence
Generic 2 Spool Gas Turbine Engine Diagram
ITT
N1
N2
PB
Source: Wikipedia
commons
EGT
Use Case Diagram for “How to Start a Jet
Engine”
Hit a button and…
Internal Block Diagram – formal system
interfaces
FADEC
Control
System
Engineer draw connections
Functional Modeling – Activity Diagrams /
Tasks and Control Flow
Level 1 Activity Diagram
Start, Stop, Operate Engine
Level 2 Activity Diagram – Start_Engine
Draw flow chart
Sequence Diagram – sequence and content of
interactions
Wizard reads flow chart and assists in developing sequence
State Diagram – states, modes, detailed logic
End-result is executable code*
Formal Methods can be applied
* Simulation or control logic
So… Where are the Requirements?
• Model first from concept-of-operations
information.
– the model becomes the requirements!
• The model then guides the writing of the
requirements document.
• Key model elements – activities, dialogs, states,
will trace to explicit requirements paragraphs.
Next Step - Verification
• After creating an executable model, and writing requirements
based on the model, the next step is to create formal test
sequences
• One way to do this is to create another “actor”, and connect
this actor to the external actors of the model. The test
sequencer drives particular tests by setting states
• Animated sequence diagrams capture the results of the test
• Book keep your work, linking requirement to test
Systems Engineering
Requirements models start with pictures
Parametric
Structural
Functional
48
SysML models are visual
Details of “Control_Is_Active”
Details of Engine Startup