model -based systems engineering: a roadmap for …€“ modeling systems throughout the...

Model-Based Systems Engineering:

Model-Based Systems Engineering Center

1MBSE Center2008-2011 Copyright © Georgia Tech. All Rights Reserved.

Model-Based Systems Engineering: A Roadmap for Academic Research

Chris ParedisAssociate DirectorModel-Based Systems Engineering CenterGeorgia [email protected]

www.pslm.gatech.edu/courseswww.omg.org/ocsmp

Acknowledgments

� Collaborators– Fried Augenbroe– Leon McGinnis– Russell Peak– Yan Wang

– Ben Lee– Brian Taylor– Edward Huang– George Thiers– Kevin Davies


– Yan Wang

� Grad Students / Postdocs– Aditya Shah– Alek Kerzhner– Axel Reichwein

– Kevin Davies– Kysang Kwon– Ola Batarseh– Roxanne Moore– Sebastian Herzig– Stephanie Thompson– Wladimir Schamai

Context: MBSE and Decision Making

Alternatives Outcomes

IdeasKnowledge/Beliefs Preferences

Decision Theory

Selection Criterion: E[u]


� Goal of MBSE: Improve Efficiency & Rationality– Efficient = Perform the SE process with fewer resources– Rational = Be consistent with designer’s beliefs and preferences

(Figure Adapted from G. Hazelrigg)

Maximize E[u]

Most PreferredSystem Alternative

Decision Theory

Target for the MBSE Roadmap

� Improve Efficiency– Reduce the cost and effort

needed to identify, locate, access, and use information

Improve Rationality

Rationality target


� Improve Rationality– Make better decisions with

the currently available information

How can we help system engineers to design more efficiently and rationally?

Efficiency

current

Obstacles on the MBSE Roadmap

� Obstacles for Efficiency:– Creating models (manually) is

expensive– Performing analyses is

time-consuming and cumbersome (due to lack of

Rationality target


interoperability)– Rehashing the same

information: e.g., writing design review reports

– Maintaining dependencies between different model views of the same system is error-prone and time-consuming

Efficiency

current

Obstacle =Opportunity for Research

Obstacles on the MBSE Roadmap

� Obstacles for Rationality:– Consistency: Are models in

sync with each other? With data? Conform to language?

– Bounded rationality: too much information and knowledge for

Rationality target


a human to take into account and process

– Poor design methods: methods must be consistent with decision theory

– Distributed decision making: different people = different beliefs and preferences � irrationality

Efficiency

current

Obstacle =Opportunity for Research

Proposed Path to Target

� Focus on efficiency first– Establish benefits of

MBSE early on– Low-hanging fruit

� Address rationality

Rationality target


� Address rationality gradually– Start with consistency– Requires significant

change in mindset for SE practitioners

– Requires further development of theory of Rational Design

Efficiency

current

How can we help system engineers to design more rationally and efficiently?

Presentation Overview

� Context: MBSE and decision making

How can MBSE help us make better decisions?

� Common theme in research: Model Transformations


� More efficient decision making with MBSE– Modeling of system alternatives — descriptive– Predictive modeling of consequence — analytical

� More rational decision making with MBSE– How to formulate design decisions?

MBSE Process = Model Transformations

InitialModel

FinalModel

� � � Transformations � � �


time

Model Model

Model Libraries

Model Transformationpre-image(pattern)matches?

then generatepost-image

Model Transformation

Source Metamodel

Source Model

Target Metamodel

Target Model

conforms to conforms to

Transformation Specification

Transformation Enginereads writes

refers to refers to

executes

(Czarnecki, K., & Hellen, S., 2006)


� Transformation Specification isalso a Model� automated generation of transformation engine code

� Origins– Model Driven Architecture/

Engineering� Tools

– MOFLON, QVTo, ATL, GME/GReAT, VIATRA2, Kermeta,…

� Example Usages:– Automation of repeated

modeling patterns– Tool interoperation– Document generation– Consistency checking– Dependency propagation

(Czarnecki, K., & Hellen, S., 2006)

Modeling System Alternatives — Some Issues

� SysML is well-suited for modeling a single alternativebut…that is often not sufficient:– Modeling product families– Modeling systems throughout the development process– Modeling variants


– Modeling variants » space of alternatives to be considered for design

optimization

� Integration between many viewpoints, many in languages/tools other than SysML

� Maintaining consistency in the specification

Generative Grammar for

Design Synthesis

� Graph Transformation


� Graph Transformation rules to generate systems

� Generate random system alternatives by applying rules in randomized order

Decision Tree of Generation ProcessDecision Tree Decision Tree[Activity] act [ ]

Add Cylinder [failure]

{probability = ".7" }

[success]

Add Cylinder

Add Directional

[success]

[failure]


[success]


Add Directional Valve


[success]



[success]

{probability = ".3" } [success]

Add Pump

Add Tank

Add Directional Valve


[success] [failure]


[success]

{probability = ".3" } [success]

[failure]{probability = ".3" }

[success]

Design Grammar Example


Apply ModelTransformations

((AlekAlek KerzhnerKerzhner, , MSMS Thesis)Thesis)

Analysis Modeling — Some Issues

� Expanding the expressivity of parametrics:– SysML4Modelica for Differential Algebraic Equations– ModelCenter for networks of black-box analysis models

� Model reuse through composition– Composition knowledge in transformations


– Composition knowledge in transformations– Model context: assumptions, applicability

� Declarative, equation-based modeling– More efficient solving through symbolic manipulation

� Abstraction levels– Best value: cost of creating/using model vs. benefit

� Predictive modeling– probability of future event

� Competing Requirements(Force, Total Time, Cost, Mass)

� Multiple Analyses (Fluid Power, Cost, Mass)

� Multiple use-phases

Example: Hydraulic Log SplitterLog Loading &Splitting Area

DirectionalControl Valve

Hydraulic Cylinder& Ram

Engine &Pump


� Multiple use-phases(Forward, Reverse)

� Many components to select from

(credit: Dave Thompson)

Engine DirectionalControl Valve Cylinder

Tank

LoadPump

Hydraulic Connection

Mechanical TranslationalConnection

Mechanical RotationalConnection

LogSplitterReqRequirements[Package] req [ ]

Id = "1.3.2"Text = "The system shall be capable of fulfilling the

«requirement»ForwardPhase

Id = "1.3"Text = "The system shall be capable of fulfilling the Hydraulic System Requirements."

«requirement»HydraulicSystem

Id = "1"Text = " "

«requirement»TotalSystem

Id = "1.3.3"Text = "The system shall be capable of fulfilling the

«requirement»ReversePhase

«deriveReqt»

Problem Definition: Requirements Decomposition

Hierarchy of

Requirements

Hydraulic

Reverse Phase

ForwardPhase


values+forceF : N{unit = Newton}+systemPressure : Pa{unit = Pascal}+forwardTime : s{unit = Second}+displacementF : m{unit = Meter}

«test»ForwardPhaseTestCase

(ProblemDefinition.Requirements.Test Cases){aspect = Behavior , GAMS}

values+forceR : N{unit = Newton}+systemPressure : Pa{unit = Pascal}+reverseTime : s{unit = Second}+displacementR : m{unit = Meter}

«test»ReversePhaseTestCase

(ProblemDefinition.Requirements.Test Cases){aspect = Behavior , GAMS}

values+totalCost : Real

«test»CostTestCase

(ProblemDefinition.Requirements.Test Cases)

{aspect = Cost , GAMS}

values+measuredMass : kg{unit = Kilogram}

«test»MassTestCase

(ProblemDefinition.Requirements.Test Cases)

{aspect = Mass , GAMS}

values+cycleTime : s{unit = Second}

«test»CycleTimeTestCase

(ProblemDefinition.Requirements.Test Cases){cycleTime=forwardTime+reverseTime}

{aspect = Behavior , GAMS}

«requirement»

Id = "1.3.2.2"Text = "The system pressure shall be less than 3e7 Pa."

«testable»

condition = ltlhs = systemPressurevalue = "30000000"

«testable»PrF

«requirement»

Id = "1.2"Text = "The cost of the system shall be less than $1,000."

«testable»

condition = ltlhs = totalCostvalue = "1000"

«testable»Cost

«requirement»

Id = "1.3.1"Text = "The cycle time of the system shall be less than 20 seconds."

«testable»

condition = ltlhs = cycleTimevalue = "20"

«testable»CycleTime

«requirement»

Id = "1.3.3.3"Text = "The system shall provide displacement less than -0.25 m."

«testable»

condition = ltlhs = displacementRvalue = "-0.25"

«testable»DisplacementR

«requirement»

Id = "1.3.2.3"Text = "The system shall provide displacement greater than 0.25 m."

«testable»

condition = gtlhs = displacementFvalue = "0.25"

«testable»DisplacementF

«requirement»


«testable»


«testable»PrR

«requirement»

Id = "1.3.2.1"Text = "The force shall be greater than 10,000 N."

«testable»

condition = gtlhs = forceFvalue = "10000"

«testable»ForceF

«requirement»

Id = "1.1"Text = "Total mass shall be less than 300 kg "

«testable»

condition = ltlhs = measuredMassvalue = "300"

«testable»Mass «requirement»


«testable»

condition = gtlhs = forceRvalue = "1000"

«testable»ForceR

Forward Phase requirements."

Reverse Phase requirements."

«verify»«verify»

«verify»

«deriveReqt»

«verify»

«verify» «verify»«verify»

«deriveReqt» «deriveReqt»

«verify»

«deriveReqt»

«verify»


19

Mass Cost

Phase Phase

Force Force PressurePressureCycle Time

Displace-ment

Displace-ment

Test Cases verify requirements through algebraic mathematical models

Problem Definition: «testable» Requirements

Text = "The system shall be capable of fulfilling the Reverse Phase requirements."


«deriveReqt»

Id = "1.3.3"Text = "The system shall be capable of fulfilling the Reverse Phase requirements."

«requirement»ReversePhase

Stereotyped Requirement


«requirement»

Id = "1.3.3.3"Text = "The system shall provide displacement less than -0.25 m."

«testable»

condition = ltlhs = displacementRvalue = "-0.25"

«testable»DisplacementR

«requirement»


«testable»


«testable»PrR

«requirement»


«testable»

condition = gtlhs = forceRvalue = "1000"

«testable»ForceR


AdditionalProperties

Note: Stereotype = user-defined language extension

Problem Formulation: System Alternative

Internal Block Diagram


� Physical components are reused� Portions of the system model repeat� Patterns for instantiating these portions

Reusable Components � Reusable Models


� Component models � Domain specific model libraries� Application of pattern = Model transformations

Electric Motors

Model Libraries and CorrespondencesComponents[Model] pkg Data[ ]

Component Library

Components

FluidPower

Valve Volumes EnginesPumps

Mechanical

Actuator

Interfaces

GamsModelLibrary GamsModelLibrary[Package] pkg [ ]

GamsModelLibrary

Components Connectors

FluidPowerMassCost

Sizing

Selection


Correspondence[Model] pkg Data[ ]

Correspondence Library

Component Library GamsModelLibrary

«block»Cylinder

(Component Library)

«gamsModel»CylinderFP

(GamsModelLibrary)

«participant»+descriptionEnd : Cylinder«participant»+analysisEnd : CylinderFP

«structure2Analysis»Cylinder2CylinderFP

{analysisAspect = GAMS , Behavior}

«structure2Analysis»Cylinder2CylinderFP

-description

1

-analysis

1

«import»«import»

Components[Package] Pumpbdd [ ]

«gamsModel»PumpFP

(GamsModelLibrary.FluidPower.Components){flange.w =l= size.maxOpSpeed*2*Pi/60,

flow =e= size.displacement * flange.w/(2*Pi),pr =e= portP.p - portT.p,

portP.p =l= size.maxOpPr,0 =e= portP.q + portT.q,

Composable Analysis Models

Equations

(Equations expressedin GAMS language —


parts«ownedGamsModel»-size : PumpSizing

values«gamsModel»-pr{flowFlag = nonflow, type = free}«gamsModel»-flow{flowFlag = nonflow, type = free}«gamsModel»-power{flowFlag = nonflow, type = free}

«gamsModel»flange : RotConnectorFP{causality = inout}«gamsModel»portP : FluidConnectorFP{causality = inout}«gamsModel»portT : FluidConnectorFP{causality = inout}

0 =e= portP.q + portT.q,power =e= flange.w*flange.tau,

portP.q + flow =e= 0,flow =g= 1e-9,

flange.tau + size.displacement *pr /(2*Pi) =e= 0,}

Values

Ports

in GAMS language —General AlgebraicModeling System)

ForwardPhaseTestCaseAnalysis ForwardPhaseTestCaseAnalysis[Class] ibd [ ]

«OwnedGamsModel»cylinderAnalysis : CylinderFP

portA portB

flangeA flangeB

AnalyticalSystemsModel

Composition of Analysis Models


«OwnedGamsModel»directionalValveAnalysis : ValveFP

portTportP

portA portB

«OwnedGamsModel»pumpAnalysis : PumpFP

portP

portT

flange

«OwnedGamsModel»engineAnalysis : EngineFP

flange

«OwnedGamsModel»tankAnalysis : TankFP

portTportP

«GamsPhysicalConnection»



«GamsPhysicalConnection» «GamsPhysicalConnection»


DescriptiveModels

CorrespondenceModels

AnalyticalModels

DescriptiveSystemsModel

ModelTransformation



portA portB

flangeA flangeB





portTportP

portA portB


portP

portT

flange


flange


portTportP






DescriptiveModels


AnalyticalModels


ModelTransformation



portA portB

flangeA flangeB



* To use the same cylinder model twice, a copy with unique names must be created.* There is no concept of objects, or model hierarchies, or reuse of the same model.

* Cylinder Model 1



portTportP

portA portB


portP

portT

flange


flange


portTportP






DescriptiveModels


AnalyticalModels


ModelTransformation

* Cylinder Model 1set cylinderCatalog1 / SAE-64508, SAE-64008, HMWparameterboreDiameterData1 / SAE-64508 0.1143, SAE0.1016 /;variable cylinder_f1, cylinder_bore1, cylinder_rod1, cylinder_portA_p1, cylinder_portB_p1;equationcylinder_f_eq1;cylinder_f_eq1.. cylinder_f1 =e= Pi*0.25*( (sqr(cylinder_bore1)*cylinder_portA_p1)

(sqr(cylinder_bore1)-sqr(cylinder_rod1)) );* Cylinder Model 2set cylinderCatalog1 / SAE-64508, SAE-64008, HMWparameterboreDiameterData1 / SAE-64508 0.1143, SAE0.1016 /;variable cylinder_f1, cylinder_bore1, cylinder_rod1, cylinder_portA_p1, cylinder_portB_p1;equationcylinder_f_eq1;cylinder_f_eq1.. cylinder_f1 =e= Pi*0.25*( (sqr(cylinder_bore1)*cylinder_portA_p1)

(sqr(cylinder_bore1)-sqr(cylinder_rod1)) );

Resulting Optimization Problem in GAMS

System Requirements Available Components

Fforward ≥ 50,000 N

ttotal ≤ 20 s

Ctotal ≤ $1000

mtotal ≤ 150 kg

Engine – 45 options

Pump – 64 options

Cylinder – 158 options

Valve – 34 options

Total Combinations – 15.5 million


� Mixed Integer Nonlinear Programming (MINLP)– Discrete component selection– Algebraic equations

expressing all requirements and objectives

� Declarative equations– Symbolic manipulation– Interval computation– Constraint propagation– Reduction� More efficient solution

Total Combinations – 15.5 million

Some Results

Scenario

Component Sizing

(Selection Id from Catalog)Variable Values

CPU

Execution

Time (s)Cylinder

Id Pump Id

Engine

IdValve Id

Forward

Force

(N)

Total

Mass

(kg)

Total

Cost

($)

Total

Time

(s)

z

Maximize Force

(N)HMW-5032 SKP1NN_012 DP340E NT-2020 139,833 94.9 993.5 20 0.40 2.82


(N)HMW-5032 SKP1NN_012 DP340E NT-2020 139,833 94.9 993.5 20 0.40 2.82

Minimize Total

Time (s)HMW-3010 SKP1NN_012 DP390E

NT_Prince-

2036 50,000 51.87 843.97 4.896 0.25 3.54

Minimize Total

Cost ($)HMW-4010 SKP1NN_012 DP240 NT-2020 53,698 51.3 657.4 9.69 0.26 2.45

Minimize Total

Mass (kg)PMC-5414 SNP2NN_4_0 DP160V

MSCDirect-

01825629 52,013 32.25 708.6 9.15 0.25 78.13

Minimize

Multiobjective zHMW-5010 SKP1NN_012 DP390 NT-2020 147,437 71.53 866.3 13.79 -0.39 5.65

z = 0.25*((totalMass/300) + (totalTime/20) + (totalCost/1000) - (forwardForce/50000))

SysML

Future: Architecture Exploration Framework

Problem Definition

Generate Architecture

ComponentsSysML

SysML Model exchanged in XMIMagicDraw SysML Editor

GAMS SolverTransformation Engine

Topology Analysis

Variable FidelityModel Selection


SysML

SysML

GenerateAlgebraic Design

Problem

SysMLAlgebraic Models

GenerateDynamic Design

Problem

SysMLDynamic Models

Problem Formulation Problem Solution

Analysis

Dynamic Analysis

Uncertainty Quantification

Mixed-IntegNonlin Solver

Algebraic Analysis

OptimizationSolver

Monte Carlo + KrigingDesign Explorer Modelica

GAMS






� More efficient decision making with MBSE– Modeling of system alternatives � descriptive– Predictive modeling of consequence � analytical


Making Decisions: Focus on Outcomes

� Design decisions should be made based on desired outcomes —What do we want to achieve?


� An objective is a direction in which one strives to do better

� An attribute is a quantity by which the attainment of an objective can be measured

[Alice came to a fork in the road.] 'Would you tell me, please, which

way I ought to go from here?''That depends a good deal on

where you want to get to,'said the Cat.

'I don't much care where—'said Alice.

'Then it doesn't matter which way you go,' said the Cat.

What When We Have Multiple Objectives?

� Means Objectives versus Fundamental Objectives


We MUST expressour preferences as

ONE objective

Only One Objective: Value

� Voice of the Customer:“I want a car that goes from 0-60 mph in 3 seconds,

gets 200 mpg and costs nothing.”

� Is it really in your best interest to build this car?


� Is it really in your best interest to build this car?

� Maximize profit– Voice of customer � demand � profit

Value-Driven Design

Value-Centric or Value-Driven Design

� How to express Value?– Maximize

probability of successof a weapons system

– Maximize the

� Related research:– Paul Collopy– Harry Cook– Paul Eremenko– George Hazelrigg


benefit to societyfor a non-for-profit

– Maximizing themarket sharefor a start-up

– Maximizing thescientific valuefor a spacecraft

– George Hazelrigg– Ralph Keeney– Jeremy Michalek– Joe Saleh– …

Engine SizeMarket

Perception

Weather

Manufacturing Defects

Driver Behavior

Safety

Reliability

Example:Value-Centric Design of Hydraulic Hybrid Vehicle


Customer Demand

Utility

Pump/Motor Size

Transmission Ratios

Accumulator Size

Hydraulic OilPrice

Top Speed

Fuel Economy

Noise

Production Cost

Acceleration

Terrain

How About Requirements?

� Requirements as expressions of preferences– Requirements express only what is NOT acceptable

� Derived Requirements– Budgets for mass, cost, etc. provide no incentive to do


– Budgets for mass, cost, etc. provide no incentive to do better than budget� on average the budget constraint is violated

cost

pdfbudget

average

cost

pdfrequirement

average

CombineMultiple

Subsystems

Summary


� Goal: Improve Efficiency and Rationality� Key Enabler: Model Transformations


� We must improve our SE methods… otherwise,we are sure to get somewhere,

but it may not be where we wanted to go

Questions?

model -based systems engineering: a roadmap for …€“ modeling systems throughout the...

Documents