on the development of tools for system design
DESCRIPTION
On the development of tools for system design. Alessandro Pinto United Technologies Research Center Inc. Berkeley, CA 94705 [email protected]. UTC and UTRC. Pratt & Whitney. Cork, Ireland. Berkeley, California. UTC Power. Sikorsky. Shanghai, China. Carrier. - PowerPoint PPT PresentationTRANSCRIPT
On the development of tools for system design
Alessandro PintoUnited Technologies Research Center Inc.
Berkeley, CA [email protected]
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 [email protected]
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