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.

2

Business units

aerospacesystemsaerospacesystems

commercial powersolutions

commercial powersolutions

commercial buildingsystems

commercial buildingsystems

United Technologies

PRATT & WHITNEYLeading industry change

Military Engines

Commercial Engines and

Global Services

P&W CanadaP&W Rocketdyne

Power Systems

4

Integrated TEC& Augmentor

Integrated TEC& Augmentor

Variant-common F135Turbomachinery

LO Axi-symmetricNozzle

LO Axi-symmetricNozzle

Lift Fan, Clutch,& Driveshaft

Roll ControlDucts and Nozzles

Roll ControlDucts and Nozzles

3-BearingSwivel Duct3-Bearing

Swivel Duct

Controls & externals,engine gearbox

Pratt & WhitneyPratt & Whitney

Hamilton SundstrandHamilton Sundstrand Rolls-Royce Rolls-Royce

Propulsion System Complexity Driving Need for More Robust Systems Engineering Process and Tools

System of Systems

System Engineering Process Driven by Product Needs

5

~ 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

Modern Gas Turbine Optimization is an Exercise in Managing Complexity

Requirements Management

Company

Job Ticket

SRD CRD PRD

Program System Module Part

Out

put

Requirements Flow to 3 Levels

Job Ticket

System Parameter

Performance

Weight

Efficiency

Reliability

Operability

Augmentor

Observability

Cost

Maintenance Cost

Durability

Job Ticket measures compliance to requirements

System

Module

Part

Program

Fan Blade = Part III

Fan = Part II

System = Part I

Roles

“Activities”

Deliverables

Product / Service Solution

Job Ticket or Contract => Requirements

Optimization

Execution

A

B

C

D

ETHERMALS

DRAFTING

MFG

A

B

C

D

ETHERMALS

DRAFTING

MFG

Y1

Simulation

CAD/CAM

System Analysis & Optimization

Computational Systems Engineering

9

CADMODEL

PHYSICSMODEL

DECISIONDESIGN

DESIGN SPACE

- NON LINEAR - MULTI MODAL - DISCONTINUOUS - NOISEY - HIGHLY CONSTRAINED

Complex Designs are Inherently Iterative & Bounded

WORKINSTRUCTIONS

CRITERIA

VALIDATEDANALYSIS

PREFERREDCONFIGURATIONS

STANDARDWORK

Manual Iteration 100s-1000s of Times

10

Sophisticated Simulation Based Design Systems

11

…and Complex Designs are Iterated Across Disciplines & Organizations…

STAR

PROSTAR 3.00

23-SEP-97VIEW

1.000 1.000 1.000

ANGLE 0.000

DISTANCE 6.549

CENTER 10.138 -0.554 0.776

EHIDDEN PLOT

X

Y Z

CYCLE

1D AERO

COOLINGFLOWS

3D AERO

HEAT XDESIGN

PLATFORM

NECK

ATTACHMENT

DISK & SEALS

FEED FORWARD

FE

ED

BA

CK

IPTPROCESS

12

. . . And Iterations Can Take Place Across the Globe

• OUTSOURCING

• PARTNERSHIPS

• INTER-DIVISIONAL

• CUSTOMERS

13

Gains are Being Made by Shifting from “Human” to “Computer” Based MDO

AUTOMATE WORKFLOW

AUTOMATE MODEL BUILDING & EXECUTION

AUTOMATE DESIGN EXPLORATION

MANUAL WORK FLOW per PROCESS MAPS

MANUAL CAD/CAE MODEL BUILDING

MANUAL EXPLORATION TO FIND OPTIMAL DESIGNS

“COMPUTER” BASED

WORKFLOW, RULES,WORKFLOW, RULES,And DESIGN ITERATIONSAnd DESIGN ITERATIONSAUTOMATED WITHINAUTOMATED WITHINAnd ACROSS SYSTEMS And ACROSS SYSTEMS & DISCIPLINES & DISCIPLINES

SYSTEM SUB-SYSTEM A SUB-SYSTEM B

Business PlanConcept &

Venture Definition

IntegratedBusiness

& Project Plan

Product/ Industrial Plan Execution & FETT

Validate, Certify, Deliver

EIS, OperationalService

& Support0 I II III IV V

Program Program Standard Work Flow

Business PlanConcept &

Venture Definition

IntegratedBusiness

& Project Plan

Product/ Industrial Plan Execution & FETT

Validate, Certify, Deliver

EIS, OperationalService

& Support0 I II III IV V

Program Program Standard Work Flow

Engineering Standard Work Flow

System

ConceptInitiation

Product Design Procurement & Initial Validation (FETT)

PreliminaryDesign

Validation/Certification

ConceptOptimization

AirplaneValidation

Service &Support0 I 2 3 4 5

Module

ConceptInitiation

Product Design Procurement & Initial Validation (FETT)

PreliminaryDesign

Validation/Certification

ConceptOptimization

AirplaneValidation

Service &Support

Part

ConceptInitiation

Product Design Procurement & Initial Validation (FETT)

PreliminaryDesign

Validation/Certification

ConceptOptimization

AirplaneValidation

Service &Support3I2 4 5I

SelectConcept

ProgramLaunch

After FETT

Release toProduction

I 2 3 4 5

2.52.5

“HUMAN” BASED

IPMT

CIPT CIPTCIPT

IPTIPTIPTIPTIPTIPT

1

2

3

4

1

2

3

4

1

2

3

4

1

2

3

4

1

2

3

4

1

2

3

4

1

2

3

4

1

2

3

4

1

2

3

4

1

2

3

4

1

2

3

4

1

2

3

4

1

2

3

4

1

2

3

4

1

2

3

4

1

2

3

4

1

2

3

4

1

2

3

4

1

2

3

4

1

2

3

4

1

2

3

4

1

2

3

4

1

2

3

4

1

2

3

4

1

2

3

4

1

2

3

4

1

2

3

4

1

2

3

4

LE

VE

LS

OF

FID

EL

ITY

NO

N-A

NA

LY

TIC

AL

NO

N-A

NA

LY

TIC

AL

NO

N-A

NA

LY

TIC

AL

-- LABOR INTENSIVE --

14

Large Scale Computer Based MDO is AlreadyPractical

Aero Xsections

0

0.1

0.2

0.3

0.4

0.5

AreaS1 AreaS2 AreaS3 AreaS4 AreaS5

Are

a

Initial

Iteration 515

Aero Xsections

0

0.1

0.2

0.3

0.4

0.5

AreaS1 AreaS2 AreaS3 AreaS4 AreaS5

Are

a

Initial

Iteration 515

AIRFOILSHAPE

OPTIMIZER

PARAMETRICCAD MESH

VIBRATORYANALYSIS

3D AEROCFD

EFFICIENCY

STRESS MODE 1

MODE 2 MODE 3 MODE 4

CAMPBELL DIAGRAM

3D Aero-Vibratory Shape Optimization Of A Cooled Turbine Airfoil(Single Row RANS CFD, Cooled UG Parametric Model, 3D ANSYS Vibes)

15

Large Scale Computer Based MDO is AlreadyBecoming Practical

GENERATION0 10 20 30

0.6

0.4

0.2

0.0

DE

LT

A T

UR

BIN

E E

FF

ICIE

NC

Y

150 VARIABLES 15 CONSTRAINTS

LOSS CONTOURS

LOSS CONTOURS

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)

Discovered “bowed” rotorTo control tip leakageVortex

16

LESS TIMELESS TIMEFEWER PEOPLEFEWER PEOPLE

Will Enable New Design Paradigms

COMPUTER BASED DESIGNCOMPUTER BASED DESIGNRUN 24/7 365 DAYS A YEAR

CONTINUOUS DETAILED DESIGN

SOLVE ALL POSSIBLEAPPLICATIONS @ TECHNOLOGY READINESS LEVEL

CUSTOMER NEEDS

UNDERSTAND THE FUTURE

CREATE TECHNOLOGY

IMPROVE MODELS

RE-FORMULATE PROBLEM

UPGRADE COMPUTER BASED DESIGN “MACHINE”

ENGINEERSENGINEERS

CUSTOMER REQ. EXCEED TECHNOLOGY

Va

lue

(e

.g..

Wei

ght

)

Goal

NTE (Not to Exceed)

Tolerance Band (±x s) Planned Profile)

Milestones

Actual Profile

Time

Goal

NTE (Not to Exceed)

Tolerance Band (±xs) Planned Profile)

Milestones

Actual Profile

Technical Performance Measurement Tracking Chart

Verification - Convergence to Requirements

18

5424

5338

5318

5286 5289

5250

5300

5350

5400

5450

Compliance1

Compliance2

Status AverageCompliance

EISProjected

Dry

en

gin

e w

eig

ht

(lbs) Commitment 5400 lb

-29 lb

Convergence to Requirements

Entry Into Service >100 lbs Below Commitment

Generic 2 Spool Gas Turbine Engine - Diagram

N2 EGTPB

ITT

N1

Source: Wikipedia commons

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 RequirementsFocus 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 RequirementsPerformance 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 downKeep 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 togetherConnect the network of models together

Functional Modeling – Activity Diagrams / Tasks and Control Flow

Activity DiagramActivity DiagramStart, Stop, Operate EngineStart, Stop, Operate Engine

Activity DiagramActivity DiagramStart, Stop, Operate EngineStart, 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 bothON or OFF but not both

28

Modeling – Overview - Parametric Modeling

Distiller - SYSML Parametric Model

29

Modeling – Overview - Dynamic Modeling

Rocket Engine – SIMULINK model

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 problemPick the model to match the problem

31

UML4SysML

UML

SysML

UML reused by SysML

• SysML:• Reuses a subset of

UML 2.0• Uses UML 2.0 profile

mechanisms to specify extensions for SysML

UML not required by SysML

SysML extensions to UML

(Have no counterpart in UML or place UML constructs)

What is SYSML?

INCOSE slide – from tutorial by “The Aerospace Corporation”

SysML tailored for Systems EngineeringSysML tailored for Systems Engineering

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

Draw Detailed Activity Diagrams

Generate Sequences

Add parameters, attributes, and messaging

Annotate and finalize message sequences

Draw State Charts

Animate and Execute

Create Ports, Interfaces, and Links

To be shown in demoTo 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?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

N2 EGTPB

ITT

N1

Source: Wikipedia commons

Use Case Diagram for “How to Start a Jet Engine”

Hit a button and…Hit a button and…

Internal Block Diagram – formal system interfaces

FADEC Control System

Engineer draw connectionsEngineer 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 chartDraw flow chart

Sequence Diagram – sequence and content of interactions

Wizard reads flow chart and assists in developing sequenceWizard reads flow chart and assists in developing sequence

State Diagram – states, modes, detailed logic

End-result is executable code* End-result is executable code* Formal Methods can be appliedFormal Methods can be applied

* Simulation or control logic* 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

48

SysML models are visualSysML models are visual

StructuralStructural

ParametricParametric

FunctionalFunctional

Details of “Control_Is_Active”

Details of Engine Startup