On the development of tools for system design
Alessandro Pinto
United Technologies Research Center Inc.
Berkeley, CA 94705
PintoA@utrc.utc.com
UTC AND UTRC
Pratt & Whitney
Sikorsky
Berkeley,
California
UTC Power
Cork,
Carrier
Ireland
Shanghai,
China
East Hartford,
Connecticut
Hamilton
Sundstrand
A. Pinto, UTRC
UTC Fire
& Security
Otis
2
VISIBLE CONSEQUENCES
Cost/schedule overruns calls for new design methods
A. Pinto, UTRC
(Source: Paul Eremenko)
3
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
How does it come about?
• 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
QUIZ
i
vin = R ¢ i
vin
vin
1/R
i
R
Is this the right model of an ideal resistive load?
Is this the right model of load?
R
C
Is this a better model of load?
L
Is this a better model of load?
6
CONTRACTS
Assumptions, guarantees and their operations
U
OµX
X
V=U[X
U is the set of uncontrollable variables (i.e. from the environment)
X is the set of controllable variables
V=U[X
For 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
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 = X 1 [ X2
U = (U1 [ U2) n X
G = 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 = V 2
A = A1 [ A2
G = G1 Å G2
Refinement: Given C1 and C2 such that V1 = V2, C1 ¹ C2 iff A1 ¶ A2 and G1 µ G2.
8
CONTRACT BASED DESIGN
High level view
C1 (V1, A1, G1)
C2
Component
C1 Æ C2 = C3
(conjunction)
C4
C7
C3 || C4 || C5 = C6
(composition)
C5
C8
C7 || C8 ¹ C4
(refinement)
9
CONTRACT-BASED DESIGN
Contracts in a design process
• Some useful inference rules
M 1 j= C1 ^ M 2 j= C2
M 1 jjM 2 j= C1 jjC2
(M j= C1 ) ^ (C1 ¹ C2 )
M j= C2
• Operationally, the effective use of contracts depends on the
complexity of ||, Æ, ¹
10
THE GENERATOR/RESISTOR EXAMPLE
V
A
G
Gen({iin, RG, vnom} [ {vout}, {iin * vnom · Pmax}, {vout = vnom – RG * iin })
Load({vL,RL, vin} [ {iout}, { |vin - vL| · 0.1*vL}, {iout = vin / RL})
This models are not instantiated. We can instantiate and connect them
RG
vnom
RL
iin
vL
iin
iout
g1 : Gen
l1 : Load
vout
vin
vout
({iin, vout} [ {RG, vnom, vL,RL}, {vnom2 /(RG + RL) · Pmax},
A. Pinto, UTRC
{|vnom RL / (RG + RL) – vL| · 0.1 *vL}
{vout = vnom – RG * iin})
{iin = vout / RL}
11
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
The UTRC contract specification language
A. Pinto, UTRC
14
DEMO
A. Pinto, UTRC
15
THE ABSTRACTION HIERARCHY
Time scale and scope
Generator ramps up after a random time
> 300
source load
Uniform RandNumber between -1000 and 1000
Compare
To Constant1
ramped_up
out
Chart
Scope
Uniform Random
Number between -1000 and 1000
> 995
S
Q
Compare
To Constant
R
!Q
NOT
L
S-R
Flip-Flop
Generator is switched ON and no failures
AND
1
Generator_out
Switch
1
Generator_switch
Logical
Operator
0
Constant
Output is 0 in case of failure
connection
Reference architecture
Standard design flow
Time scale (f)
16
MOVING TO DYNAMICAL SYSTEMS
Quasi-static vs. dynamic
Taxi
Climb
Cruise
F(X) = 0
Taxi
Climb
Cruise
F(X,dX/dt) = 0
• Mission points (or system states)
• Mission points and transitions
• Steady state (ignore d/dt)
• Dynamics
• Design for each mission point
• Check for transients
• Use worst case
A. Pinto, UTRC
17
MODEL DEFINITION
Discrete Time Stochastic Hybrid Systems
• A DTSHS is a tuple H(Q; d; I ni t; T; L ; R)
• Discrete modes Q = f q1 ; : : : ; ql g
• Hybrid state space S = [
q2 Q f qg £
Rd(q) ; (S = [
q2 Q f qg £
Xd(q) )
• Stochastic dynamics T = f Tq g; X q;k + 1 = Tq(X q;k ; »q;k )
• Probabilistic jumps L = f L q : Rd(q) ! Di st(Q)g
• where L q (X q;k )(q0) is the probability of switching from q to q’
• Stochastic resets R = f
q0
Rq g;
X q00;k
=
q0
Rq (X q;k ; ´ q;k )
18
MODELING FEATURES
Inputs, Outputs and Hierarchy
• 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
EXAMPLE
The noisy bouncing ball
q0
y
vk + 1
=
vk ¡ ± ¢g + »k
yk + 1
=
yk + ± ¢vk
v
Switch
½
k
L q0 (vk ; yk )(q0 )
=
1 vk · 0 ^ yk · 0
0 other wi se
Reset
vk0
=
¡ ´ k ¢vk
yk0
=
yk
20
DEMO
• Modeling, simulation, analysis and verification
21
QUANTITATIVE ANALYSIS
Propagation of uncertainty subject to dynamics
Deterministic map
x k + 1 = T(x k )
Z
¹ k+ 1
Z
¹ k + 1 (x)dx =
A
Z
¹ k (x)dx;
Z
T¡
1 (A )
[P ]¹ (x)dx =
¹ (x)dx;
T¡
A
8 A ½ Rn
¹
1 (A )
Similarly, we can define
PF operators for
switching functions and
resets
Stochastic map
Z
2
Z
[P ]¹ (x)dx = E» 4
A
T
8 A ½ Rn
Perron-Frobenious operator
x k + 1 = T(x k ; »k )
k
A
3
¹ (x):ÂA (T(x; »))dx 5 ;
8 A ½ Rn
Rn
22
QUANTITATIVE ANALYSIS
Propagation of uncertainty subject to dynamics
Sub-probability measure for each mode
¹ ki (A) = ¡ k (qi ; A);
k
X
¹ ki (A)
¹ (A) =
PF operator within a mode
i
¡
2
6
6
6
6
4
k+ 1
= P¡
i = 1; 2; :::m:
PF operator for reset
k
P1 M 1;1 L 1;1
P2 M 1;2 L 1;2
::::::::
::::::::
Pm M 1;m L 1;m
PF operator for switching
P1 M 2;1 L 2;1
P2 M 2;2 L 2;2
::::::::
::::::::
Pm M 2;m L 2;m
::::
P1 M m ;1 L m ;1
:::::::: P2 M m ;2 L m ;2
::::::::
::::::::
::::::::
::::::::
:::::::: Pm M m ;m L m ;m
3
7
7
7
7
5
23
IMPLEMENTATION
Linear Hybrid Space
h
´
h
´
(i )
(i )
(i )
(i )
I nv(qi ) = x 1;l ; x 1;u £ : : : £ x n ;l ; x n ;u
(i )
(i )
ld
=
(i )
x d;u ¡ x d;l
Hybrid discrete state space
h
´
(i )
(i )
(i )
(i )
= x d;l + (j ¡ 1)l d ; x d;l + j l d
(i )
I d;j
(i )
gd
S^ =
D ( qi )
[m
f qi g £
(i )
[1; g1 ] £
n (mi ) =
[1; gn(i ) ]
::: £
^! S
^L
map : S
S^L = [
mode(s) = mode(s0) = q
D ( q)
0
(i )
gd
d= 1
i= 1
Linear encoding of the
discrete space
Y
X
B (s )j 1 = B (s)j D ( q) +
d= 1
0
q2 Q f qg £
D ( q)
@
Y
d 0= d+ 1
[1; n(im) ]
1
(i )
gd A (B (s)j d ¡ 1)
24
COMPLEXITY
Qualitative analysis
• 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
EXAMPLE
Thermal Management System
Tou t
Fuel tank
ECS/EPS/Engine
HL
m ou
_t
Initial Mass
Initial Temp.
Pump
Heat load
Tf
Splitter
m_f
M
m_i n
Fuel
consumption
Heat sink
Ti n
M_ = m_i n ¡ mout
_ = m_f
HS
Flow
• Mass rate
• Temperature
mout
_ cf (Tf ¡ Tout ) = H L = H E C S + H E + (1 ¡ ef f ) ¤ w
m_i n cf (Ti n ¡ Tf ) = H S
m_i n cf Ti n ¡ mout
_ cf Tout = M_cf T + M cp T_
26
EXAMPLE
Mission and parameters
Take off
Thrust:
38100 lb
Heat load: 26.63 kW
Speed:
240 km/hr
Ascend
Thrust:
38100 lb
Heat load: 27 kW
Climb angle: 30
Fly
Thrust:
19000 lb
Heat load: 20 kW
Total 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
Taxi
Thrust:
9525 lb
Heat load: 18.44 kW
Total time: [600,900] sec
27
EXAMPLE
Modeling mission modes
ascending
flying
h = 0; v = 0;
f = f t ; w = wt
±= 0
h ¸ ht g =± = 0
take-off
taxiing
v ¸ vt of f =± = 0
± ¸ t~l =± = 0
±_= 1
± ¸ ±~t =± = 0
eom
landing
decelerating
descending
h · hl d =± = 0
z · 0=± = 0
v · vl d =± = 0
28
FUEL LEVEL AND TEMPERATURE
Probability distributions
• Maximum number of states in the queue: 3M
• Total time: 30 min on Intel Core2 Duo P9400@2.4GHz
29
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
High level view
C1 (V1, A1, G1)
C2
Component
C1 Æ C2 = C3
(conjunction)
C4
C7
C3 || C4 || C5 = C6
(composition)
C5
C8
C7 || C8 ¹ C4
(refinement)
31
EXAMPLE
Refining the heat exchanger model
HL
Oil
Hex
Pump
HL
m
_o =
² f =o co (To;i n ¡ Tf ;i n )
m
_¤
To + º
Oil Tank
M o; To
HL
Controller
m
_o; To;out
Fuel tank
m
_o; To;i n
Oil flow/temperature
Boost pump
Fuel/Oil Hex
Engine/
Splitter
mou
_ t cf (Tf ¡ Tout ) = H L
Fuel
consumption
Air/Fuel HE
Guarantee
32
Air flow/temperature
RESULTS
A
m_f
Tf
Dist i
Di st i + 1
G
Coarse model
HL
Difference
metric
computation
HL 2 [20,25] kW
mf 2 [1,2] kg/s
Tf 2 [280,300] K
Refined model
33
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
x_2 = f 2 (x 2 ; u2 ; uc;2 )
x_1 = f 1 (x 1 ; u1 ; uc;1 )
¸1
OP
¸3
FAIL
C1
C2
C3
OP
FAIL
½1
Connections
¸2
OP
FAIL
35
EXAMPLE
Physical architecture
Control inputs
m ou
_t f
TMS
Fuel tank
HL
Initial Mass
Initial Temp.
Heat load
Pump
Splitter
m_f
m_i n
Ti n
Heat sink
HS
open/clos
e
Tou t
Tf
Observed variables
36
EXAMPLE
Adding the control architecture
TMS
m ou
_t
Tf
f
Tou t
m ou
_t
Mdot
controller
f
F
controller
37
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
Stochastic optimization problem
Control-parameters
Uncertain parameters
Sample average of cost-function
Number of samples
Sample average approximation problem
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.
39
OPTIMAL DISTRIBUTED CONTROL
TMS state
dynamics
Controller
dynamics
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,” 40
Mathematical Programming, vol. 106, pp. 25–57, 2006.
OPTIMAL DISTRIBUTED CONTROL
Optimization results
TMS states
Fuel-tank temperature
Fuel-combustor temperature
Controls
41
Fuel flow-rate
Heat-sink opening
OPTIMAL DISTRIBUTED CONTROL
Vulnerability vs. Cost
System is vulnerable if fuel temperatures go out of prescribed bounds.
TMS
m ou
_t
Tf
f
Tou t
TMS
m ou
_t
Tf
f
m ou
_t
Mdot
F
Mdot
F
42
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