On the development of tools for system design

Alessandro PintoUnited Technologies Research Center Inc.

Berkeley, CA 94705PintoA@utrc.utc.com

UTC PowerUTC Power

OtisOtisUTC FireUTC Fire& Security& Security

HamiltonHamiltonSundstrandSundstrand

SikorskySikorsky CarrierCarrier

Pratt & WhitneyPratt & Whitney

UTC and UTRC

2

East Hartford,East Hartford,ConnecticutConnecticut

Shanghai,Shanghai,ChinaChina

Berkeley,Berkeley,CaliforniaCalifornia

Cork,Cork,IrelandIreland

A. Pinto, UTRC

Visible consequences

3

Cost/schedule overruns calls for new design methods

(Source: Paul Eremenko)A. Pinto, UTRC

UTRC Efforts

•Complex System Design and Analysis (CODA)

•Methods and tools to reduce schedule by 5X

•In this talk: Contract-Based Specification

•Verification and Validation of Dynamic and Distributed Systems (V2D2)

•Tools for design/verification of dynamical systems with uncertainty

•In this talk: A very brief summary (full report available on my website)

A. Pinto, UTRC 4

The language issue

•Need for a virtual environment

•Models, not code (multiple tools, automation)

•However, models may be very detailed (legacy)

•Modeling requirements

•Integration, independent implementability

•Multiple (related) views

•Multiple (related) levels of abstraction

A. Pinto, UTRC 5

How does it come about?

quiz

6

Rvin

i

Is this the right model of an ideal resistive load?

vin = R ¢ i1/R

ivin

Is this the right model of load?

R

L

C Is this a better model of load?

Is this a better model of load?

Contracts

8

Assumptions, guarantees and their operations

U

X

O µ X U is the set of uncontrollable variables (i.e. from the environment)X is the set of controllable variablesV = U [ XFor a variable v 2 V, let Dv be its domain (DV = £ v 2 V Dv)

A contract is a tuple C(V,A,G) where A µ DU is an assumption and G µ DU £ DX is a guarantee

V = U [ X

Satisfaction: A component model M(V, B µ DU £ DX) satisfies a contract C iff B Å A µ G

Composition: Given C1 and C2 such that X1 Å X2 = ;, C = C1 || C2 is such that:X = X1 [ X2

U = (U1 [ U2) n XG = G1 "V Å G2 "V (satisfies both contracts)A = A1 "V Å A2 "V [ : G (assumes both assumptions)Conjunction: Given C1 and C2 such that V1 = V2, C = C1 Æ C2 is such that:V = V1 = V2

A = A1 [ A2

G = G1 Å G2

Refinement: Given C1 and C2 such that V1 = V2, C1 ¹ C2 iff A1 ¶ A2 and G1 µ G2.

Contract based design

9

High level view

C1 (V1, A1, G1) C2 C1 Æ C2 = C3

Component C4 C5

(conjunction)C3 || C4 || C5 = C6

(composition)

C7 C8C7 || C8 ¹ C4

(refinement)

Contract-based design

•Some useful inference rules

•Operationally, the effective use of contracts depends on the complexity of ||, Æ, ¹

10

Contracts in a design process

M1 j= C1 ^M2 j= C2

M1jjM2 j= C1jjC2

(M j= C1) ^(C1 ¹ C2)M j= C2

The Generator/resistor example

A. Pinto, UTRC 11

Gen({iin, RG, vnom} [ {vout}, {iin * vnom · Pmax}, {vout = vnom – RG * iin })

V A G

Load({vL,RL, vin} [ {iout}, { |vin - vL| · 0.1*vL}, {iout = vin / RL})

This models are not instantiated. We can instantiate and connect them

g1 : Gen l1 : Load

RG vnom RL vL

iin

vout

iout

vin

iin

vout

({iin, vout} [ {RG, vnom, vL,RL}, {vnom2 /(RG + R

L) · Pmax}, {vout = vnom – RG * iin})

{iin = vout / RL}{|vnom RL / (RG + RL) – vL| · 0.1 *vL}

Quiz

•Can we instantiate more than one load?

•Can we instantiate an unconnected component?

•Is this a desirable?

•We need an algebra that defines how the world behaves

•We need rules that define valid architectures

•Are these two the same?

A. Pinto, UTRC 12

Our contributions

•Definition of the TinyCSL language

•First order logic extended with background theories

•Ability to model platforms, i.e. sets of products obeying rules

•Meta-model and associated tools

•Does and architecture belong to a platform?

•Limitations

•Steady state (quasi-static regime)

•Verification can be done for arithmetic expressions only

A. Pinto, UTRC 13

TinyCSL

A. Pinto, UTRC 14

The UTRC contract specification language

Demo

A. Pinto, UTRC 15

The abstraction hierarchy

16

Time scale and scope

Scope

Time scale (f)

Reference architectureStandard design flow

source load

connection

Generator is switched ON and no failures

Output is 0 in case of failure

Generator ramps up after a random time

1

Generator_out

Uniform RandomNumber between -1000 and 1000

Uniform RandNumber between -1000 and 1000

Switch

S

R

Q

!Q

S-RFlip-Flop

AND

LogicalOperator

NOT

L

0

Constant

> 300

CompareTo Constant1

> 995

CompareTo Constant

ramped_up out

Chart

1

Generator_switch

Moving to dynamical systems

•Mission points (or system states)

•Steady state (ignore d/dt)

•Design for each mission point

•Use worst case

A. Pinto, UTRC 17

Quasi-static vs. dynamic

•Mission points and transitions

•Dynamics

•Check for transients

Taxi Climb Cruise

F(X) = 0

Taxi Climb Cruise

F(X,dX/dt) = 0

Model definition

•A DTSHS is a tuple

•Discrete modes

•Hybrid state space

•Stochastic dynamics

•Probabilistic jumps

•where is the probability of switching from q to q’

•Stochastic resets

18

Discrete Time Stochastic Hybrid Systems

H(Q;d;I nit;T;L ;R)

Q = fq1; : : : ;qlg

S = [ q2Q fqg£ Rd(q); (S = [ q2Q fqg£ Xd(q))

T = fTqg; X q;k+1 = Tq(X q;k;»q;k)

L = fLq : Rd(q) ! Dist(Q)g

Lq(X q;k)(q0)

R = fRq0

q g; X 0q0;k = Rq0

q (X q;k;´q;k)

Modeling features

•I-O DTSHS

•Composition operator (results in an I-O DTSHS)

•Requirement: after composition, the system must be closed (empty inputs and output sets)

•Hierarchy

• A system can be composition of sub-systems

• A mode can be composition of modes

• A transition can be composition of transitions

19

Inputs, Outputs and Hierarchy

Example

The noisy bouncing ball

20

Lq0 (vk;yk)(q0) =½

1 vk · 0^yk · 00 otherwise

Switch

Reset

vk+1 = vk ¡ ±¢g+ »k

yk+1 = yk + ±¢vk

v0k = ¡ ´k ¢vk

y0k = yk

q0

y

v

k

DEMO

•Modeling, simulation, analysis and verification

21

Quantitative Analysis

22

Propagation of uncertainty subject to dynamics

Similarly, we can define PF operators for switching functions and resets

xk+1 = T(xk)

¹ k

¹ k+1Z

A¹ k+1(x)dx =

Z

T ¡ 1(A )¹ k(x)dx; 8 A ½Rn

T

A

xk+1 = T(xk;»k)

Z

A

[P ]¹ (x)dx = E»

2

4Z

Rn

¹ (x):ÂA (T(x;»))dx

3

5 ; 8 A ½Rn

Z

A[P ]¹ (x)dx =

Z

T ¡ 1(A )¹ (x)dx; 8 A ½Rn

Perron-Frobenious operator

Deterministic map

Stochastic map

Quantitative Analysis

23

Propagation of uncertainty subject to dynamics

¹ ki (A) = ¡ k(qi ;A); i = 1;2;:::m:

¹ k(A) =X

i

¹ ki (A)

¡ k+1 = P ¡ k

2

66664

P1M1;1L1;1 P1M2;1L2;1 :::: P1Mm;1Lm;1

P2M1;2L1;2 P2M2;2L2;2 :::::::: P2Mm;2Lm;2

:::::::: :::::::: :::::::: :::::::::::::::: :::::::: :::::::: ::::::::

PmM1;mL1;m PmM2;mL2;m :::::::: PmMm;mLm;m

3

77775

Sub-probability measure for each mode

PF operator within a mode

PF operator for switching

PF operator for reset

Implementation

24

Linear Hybrid Space

I nv(qi ) =hx(i )

1;l ;x(i )1;u

´£ :: : £

hx(i )

n;l ;x(i )n;u

´

l(i )d =x(i )

d;u ¡ x(i )d;l

g(i )d

I (i )d;j =

hx(i )

d;l + (j ¡ 1)l(i )d ;x(i )d;l + j l(i )d

´

S =m[

i=1

f qi g£ [1;g(i )1 ]£ ::: £ [1;g(i )

n ] n(i )m =

D (qi )Y

d=1

g(i )d

SL = [ q2Q f qg£ [1;n(i )m ]map: S ! SL

mode(s) = mode(s0) = q

B(s0)j1 = B(s)jD (q) +D (q)X

d=1

0

@D (q)Y

d0=d+1

g(i )d

1

A (B(s)jd ¡ 1)

Hybrid discrete state space

Linear encoding of the discrete space

Complexity

•Size

•Step size for the discretization of the continuous state space: number of states of the discrete state space

•Time

•Computation of the PF operator (numerical computation of integrals),

• Depends on the step size and desired accuracy

• on the dynamics of the system

• on the statistics of the processes involved

25

Qualitative analysis

Example

26

Thermal Management System

Fuel tank

Fuel consumption

Flow• Mass rate• Temperature

Heat load

Pump

Heat sink

Splitter

ECS/EPS/Engine

Initial MassInitial Temp.

_mout

_min

_mf

HL

HS

Tout

Tin

Tf

_M = _min ¡ _mout = _mf

M

_moutcf (Tf ¡ Tout) = HL = HE C S + HE + (1¡ ef f ) ¤w

_mincf (Tin ¡ Tf ) = HS

_mincf Tin ¡ _moutcf Tout = _M cf T + M cp _T

EXAMPLE

27

Mission and parameters

Take offThrust: 38100 lbHeat load: 26.63 kWSpeed: 240 km/hr

TaxiThrust: 9525 lbHeat load: 18.44 kWTotal time: [600,900] sec

AscendThrust: 38100 lbHeat load: 27 kWClimb angle: 30

FlyThrust: 19000 lbHeat load: 20 kWTotal time: [3600,4500] sec

• Dry weight: 10400 kg• Initial fuel mass: 9000 kg• Fuel consumption: 0.7 kg/kgt/hr• Fuel specific heat: 0.2 kJ/(kg K)• Drag coefficient: 0.48• Wing area: 28 m2

Example

28

Modeling mission modes

take-off

ascending flying

descendinglanding

taxiing

deceleratingeom

±¸ ~±t=±= 0

v ¸ vtof f =±= 0h ¸ htg=±= 0

±¸ ~tl=±= 0

h · hld=±= 0

v · vld=±= 0z · 0=±= 0

h = 0; v = 0;

f = f t; w = wt

±= 0

_±= 1

Fuel level and temperature

29

Probability distributions

•Maximum number of states in the queue: 3M

•Total time: 30 min on Intel Core2 Duo P9400@2.4GHz

Limitations in practice

•Limited to 10 million reachable states (single machine)

• 6-7 continuous variables (modes not relevant)

3-4 components

•Can be improved: The PF operator is linear easy parallelization of the algorithm

•However, speedup is linear against exponential blow up

30

Contract based design

31

High level view

C1 (V1, A1, G1) C2 C1 Æ C2 = C3

Component C4 C5

(conjunction)C3 || C4 || C5 = C6

(composition)

C7 C8C7 || C8 ¹ C4

(refinement)

Example

32

Refining the heat exchanger model

Fuel tank

Boost pump

Engine/Splitter

Oil flow/temperature

Fuel consumption

Air flow/temperature

Fuel/Oil Hex

Air/Fuel HE

HL Oil Hex Pump

Oil Tank

Controller

_mo; To;out

_mo; To;in

Mo;To

To + º

_m¤

HL

_moutcf (Tf ¡ Tout) = HL

Guarantee

_mo =HL

²f =oco (To;in ¡ Tf ;in)

results

33

Coarse model

Refined model

DistiDisti+1

_mf

Tf

HLDifference

metric computation

HL 2 [20,25] kWmf 2 [1,2] kg/sTf 2 [280,300] K

A G

A synthesis approach

•Analysis: To check whether a system satisfies a property

•Synthesis: given a partial system, define the remaining components such that the composition satisfies a property (and some objectives a minimized)

•The composition does not need to be verified. The guarantee is in the synthesis algorithm

34

Hardware/Damage abstraction

35

_x1 = f 1(x1;u1;uc;1) _x2 = f 2(x2;u2;uc;2)

C1 C2 C3

Connections

OP FAIL

¸1

½1

OP FAIL

¸2

OP FAIL

¸3

Example

36

Physical architecture

Fuel tank

Heat load

Heat sink

Splitter

Initial MassInitial Temp.

_mout

_min

_mf

HL

HS

Tout

Tin

Pump

open/close

TMS

Tf

f Control inputs

Observed variables

Example

37

Adding the control architecture

ToutTf_mout f

TMS

Mdot controller

F controller

_mout

f

Optimal DISTRIBUTED CONTROL

•Optimal control of hybrid systems (in general) - difficult.

•Optimal control of hybrid systems with time-triggered transitions – possible.

•Hybrid systems with random transition times – leads to a stochastic optimization problem.

•Use sample average approximation method to perform stochastic optimization

38

Optimal DISTRIBUTED CONTROL

•Sample Average Approximation method

39

Stochastic optimization problem

Control-parameters Uncertain parameters

Sample average of cost-function

Sample average approximation problem

Number of samples

A. J. Kleywegt, A. Shapiro, and T. Homem-De-Mello, “The sample average approximation method for stochastic discrete optimization,”SIAM J. Optim., vol. 12, no. 2, pp. 479–502, 2001.

Optimal DISTRIBUTED CONTROL

40

TMS state dynamics

Controllerdynamics

Cost-function = Deviation from set-points + controller effort

Optimize control parameters for expected value of cost-function:1. Generate constraints for states from dynamics.2. Compute sample average of cost-function.3. Compute gradient of cost-function and Jacobian of constraints equations.4. Use IPOPT to perform optimization.

A. Wachter and L. T. Biegler, “On the implementation of an interior point filter line-search algorithm for large-scale nonlinear programming,”Mathematical Programming, vol. 106, pp. 25–57, 2006.

Optimal DISTRIBUTED CONTROL

41

Optimization results

Fuel-tank temperature Fuel-combustor temperature

Fuel flow-rate Heat-sink opening

TMS states

Controls

42

Optimal DISTRIBUTED CONTROLVulnerability vs. Cost

System is vulnerable if fuel temperatures go out of prescribed bounds.

ToutTf_mout f TMS

Mdot F

Tf_mout f TMS

Mdot F

_mout

Summary

•Motivation: complexity (pick your def.) is the driver for virtual engineering

•Languages and tools

•Contract-based design seems to be a good candidate

•TinyCSL and verification tools

•Dealing with dynamics and uncertainty

•Methods do not scale

•Synthesis seems to be the solution

A. Pinto, UTRC 43

Thanks!

Questions?

A. Pinto, UTRC 44