On the development of tools for system design

1. On the development of tools for system design Alessandro Pinto United Technologies Research Center Inc. Berkeley, CA 94705 PintoA@utrc.utc.com

2. UTC and UTRC Pratt & Whitney Cork,Ireland Berkeley,California UTC Power Sikorsky Shanghai,China Carrier East Hartford,Connecticut We are hiring!!! Hamilton Sundstrand Otis UTC Fire& Security A. Pinto, UTRC

3. Visible consequences Cost/schedule overruns calls for new design methods (Source: Paul Eremenko) A. Pinto, UTRC

4. 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

5. 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 How does it come about? A. Pinto, UTRC

6. quiz i 1/R vin i vin = R ¢ i vin 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?

7. Contracts Assumptions, guarantees and their operations 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) U O µ X X V = U [ X A contractis 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 = X1[ 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 = V2 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) C1Æ C2 = C3 C2 C3 || C4 || C5 = C6 (conjunction) (composition) Component C4 C5 C7 || C8¹ C4 C7 C8 (refinement)

9. Contract-based design Some useful inference rules • Operationally, the effective use of contracts depends on the complexity of ||, Æ, ¹ Contracts in a design process

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 vL iin iout iin g1 : Gen l1 : Load vout vin vout ({iin, vout} [ {RG, vnom, vL,RL}, {vnom2 /(RG + RL) · Pmax}, {vout = vnom – RG * iin}) {|vnom RL / (RG + RL) – vL| · 0.1 *vL} {iin = vout / RL} A. Pinto, UTRC

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 load source Scope connection Reference architecture Standard design flow Time scale (f)

16. Moving to dynamical systems Quasi-static vs. dynamic Mission points and transitions Dynamics Check for transients • Mission points (or system states) • Steady state (ignore d/dt) • Design for each mission point • Use worst case Taxi Climb Cruise Taxi Climb Cruise F(X) = 0 F(X,dX/dt) = 0 A. Pinto, UTRC

17. 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 Discrete Time Stochastic Hybrid Systems

18. 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 Inputs, Outputs and Hierarchy

19. Example The noisy bouncing ball Switch Reset

20. DEMO • Modeling, simulation, analysis and verification

21. Quantitative Analysis Propagation of uncertainty subject to dynamics Deterministic map Perron-Frobenious operator Similarly, we can define PF operators for switching functions and resets Stochastic map

22. Quantitative Analysis Propagation of uncertainty subject to dynamics Sub-probability measure for each mode PF operator within a mode PF operator for reset PF operator for switching

23. Implementation Linear Hybrid Space Hybrid discrete state space Linear encoding of the discrete space

24. 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 Qualitative analysis

25. Example Thermal Management System ECS/EPS/Engine Fuel tank Initial Mass Initial Temp. Heat load Pump Splitter Fuel consumption Heat sink • Flow • Mass rate • Temperature

26. EXAMPLE Mission and parameters Ascend Thrust: 38100 lb Heat load: 27 kW Climb angle: 30 Take off Thrust: 38100 lb Heat load: 26.63 kW Speed: 240 km/hr • 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 Fly Thrust: 19000 lb Heat load: 20 kW Total time: [3600,4500] sec Taxi Thrust: 9525 lb Heat load: 18.44 kW Total time: [600,900] sec

27. Example Modeling mission modes taxiing take-off ascending flying decelerating landing eom descending

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) C1Æ C2 = C3 C2 C3 || C4 || C5 = C6 (conjunction) (composition) Component C4 C5 C7 || C8¹ C4 C7 C8 (refinement)

31. Example Refining the heat exchanger model Oil Hex Pump Controller Fuel tank Oil Tank Oil flow/temperature Guarantee Boost pump Fuel/Oil Hex Fuel consumption Engine/Splitter Air/Fuel HE Air flow/temperature

32. results A G Coarse model HL2 [20,25] kW mf2 [1,2] kg/s Tf2 [280,300] K Difference metric computation 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 C1 C2 C3 Connections OP FAIL OP FAIL OP FAIL

35. Example Physical architecture Control inputs f TMS Heat load Fuel tank Initial Mass Initial Temp. Pump Splitter Heat sink open/close Observed variables

36. Example Adding the control architecture TMS f Mdot controller F controller f

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,” Mathematical Programming, vol. 106, pp. 25–57, 2006.

40. Optimal DISTRIBUTED CONTROL Optimization results TMS states Fuel-tank temperature Fuel-combustor temperature Controls Fuel flow-rate Heat-sink opening

41. Optimal DISTRIBUTED CONTROL Vulnerability vs. Cost System is vulnerable if fuel temperatures go out of prescribed bounds. TMS TMS f f Mdot Mdot F F Architecture –> {1, 0, 0, 1} Architecture –> {1, 0, 1, 0}

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