Towards an Operational Semantics of the Simulation Engine of - PowerPoint PPT Presentation

Towards an Operational Semantics of the Simulation Engine of Simulink Alexandre Chapoutot joint work with Olivier Bouissou (CEA LIST, LMeASI) ENSTA Paristech SYNCHRON 2011 December 1st

Motivation 2 / 22

Simulink and its industrial uses Context Simulink is a de facto standard in the industry to design embedded safety critical applications. e.g. it is used to design almost all the drive-by-wire systems. Components of a drive-by-wire systems A physical mechanism we want to control, e.g. a suspension. A software which implement the controller. ⇒ we have to deal with hybrid systems . Current validation method The main method to validate the design of embedded systems is based on simulation activity . 3 / 22

Classical design and validation methodology Mathematical model Identification m ¨ x + c ˙ x + kx = u Computer description Controller definition road road relative_position 1 Road_profile damping_force relative_position Theoretical and k 1 Quarter_car road Gain experimental studies 1 1 1/m ddot_zb s dot_zb s zb 2 Integrator Integrator1 damping_force c(t) Gain1 relative_position Controller Remarks Mathematical models are an approximated descriptions of physical systems . The computer descriptions are studied with numerical tools. 4 / 22

Classical design and validation methodology MIL: Model in the loop Definition of a mathematical model of the plant and the controller . Expected output Test vectors Test process Sensor model Controller: model Plant Model Actuator model Simulation platform Aim of the testing activity Does the controller fulfil the specification? The set of tests will be used as “an oracle” in the next steps. 4 / 22

Classical design and validation methodology SIL: Software in the loop Implementation of the controller in a target language. Expected output Test vectors Test process Sensor model Controller: source code Plant Model Actuator model Simulation platform Aim of the testing activity Do the hand-written or generated code still fulfil the specification? 4 / 22

Classical design and validation methodology PIL: Processor in the loop Compilation of the controller and execute it on a virtual processor. Expected output Test vectors Test process Sensor model Controller: object code Plant Model Actuator model Virtual targeted CPU Simulation platform Aim of the testing activity Does the low-level implementation still fulfil the specification? 4 / 22

Considering Simulink as a language Simulink: a graphical language It allows to describe, as block-diagrams, a mixing of: Ordinary differential equations (ODE). Finite difference equations: single-rate or multi-rate period. Conditional executed equations: enabled or triggered . Simulink: several parametrized semantics the definition of a numerical solver used to solve ODEs; the detection of events: zero-crossing . So, it is a numerical approximation of the mathematical behavior . What we should keep in mind! The designer only refers to the Simulink’s semantics (i.e. graphical output) to validate the development steps! 5 / 22

Formal verification of Simulink Fact: simulations will never be complete and cannot bring strong guarantee on the designed software. Main question: How can we help designer to be more confident in its designed systems with formal methods? Formal verification of Simulink: Our Goal To compute invariant properties on the software taking into account a model of the plant . Our approach: abstract interpretation-based static analysis. Formal verification of Simulink: Constraint Formal verification methods should be adaptable for the design process in order to be more easily adopted by the end-user. Formal verification of Simulink: Challenge Understand the simulation engine of Simulink. 6 / 22

Simulink Language 7 / 22

A simple example: mathematical models A semi-active suspension of a quarter-car model Sensor m = 250 kg Mass ( m ) k = 20000 N/m z b − z r z b c max = 16000 N/m/s Controller k c ( t ) c min = 0 z r Mathematical model of the mechanical system z b = − 1 � � ¨ k ( z b − z r ) + c ( t ) . m Mathematical model of the controller � − c max ( z b − z r ) if ( z b − z r )(˙ z b − ˙ z r ) < 0 c ( t ) = z r ) ≥ 0 . c min if ( z b − z r )(˙ z b − ˙ 8 / 22

A simple example: Simulink implementation – 1 Mathematical model of the mechanical system z b = − 1 � � ¨ k ( z b − z r ) + c ( t ) . m 1 relative_position k 1 road Gain 1 1 1/m ddot_zb s dot_zb s zb 2 Integrator Integrator1 c(t) Gain1 Integrator block Associated to a first order dynamic system: � x ( t ) = input ( t ) ˙ output ( t ) = x ( t ) with x ( 0 ) = x 0 9 / 22

A simple example: Simulink implementation – 2 Mathematical model of the controller � − c max ( z b − z r ) if ( z b − z r )(˙ z b − ˙ z r ) < 0 c ( t ) = z r ) ≥ 0 . if ( z b − z r )(˙ z b − ˙ c min Implementation: (˙ z b − ˙ z r ) is given by differentiating the sensor output. 0 1 c_min relative_position 1 >= 0 � K � damping_force Product1 Product Subtract Gain Switch 1 z � c Unit Delay c_max Discrete differentiation at rate 1 / 40 sec. Closed-loop system Connect the output of the plant to the input of the controller. Connect the output of the controller to the input of the plant. 9 / 22

A simple example: simulation results Simulation settings Duration of the simulation: 5 seconds. Variable step-size solver: ode23 . Zero-crossing detection activated (non adaptive version). Road profile Relative position 5 · 10 − 2 0 . 1 0 5 · 10 − 2 − 5 · 10 − 2 0 − 0 . 1 0 2 4 0 2 4 Remarks The on-off controller make the suspension stable. 10 / 22

A simple example: simulation results Damping coefficient c ( t ) Time vs. simulation loop iteration · 10 4 0 4 − 0 . 5 2 − 1 − 1 . 5 0 0 2 4 0 100 200 Remark: numerical precision The damping force oscillated because of tiny variations of the suspension. Consequence: finite precision may induce unexpected behaviors. Remark: time The time evolution is not homogeneous: Consequence: blocks depending on time may produce more or less output following the time evolution e.g. sine block. 10 / 22

Operational Semantics 11 / 22

Simulink as an equation-based programming language Input/Output relation Each block defines the time invariant relation between its input and its output. Library Blocks Representation Equations 1 ℓ 1 Input ℓ 1 = in1 In1 Sources ℓ 1 c Constant Constant ℓ 1 = c ℓ 1 ℓ 3 ℓ 2 Arithmetic Add ℓ 3 = ℓ 1 + ℓ 2 Add ℓ 1 ℓ 2 ℓ 4 ℓ 3 Signal routing Switch ℓ 4 = if ( p r ( ℓ 2 ) , ℓ 1 , ℓ 3 ) Switch ℓ 1 ℓ 2 1/s Continuous-time Integrator { ℓ 2 = x ; ˙ x = ℓ 1 ; x ( 0 ) = init } Integrator 1 ℓ 1 ℓ 2 z { ℓ 2 = d ; ¯ Discrete-time Unit Delay d = S ℓ 1 ; d ( 0 ) = init } Unit Delay ¯ d = S ℓ stands for at each t = kS , d = ℓ else it keeps its previous value. 12 / 22

Simulink as an equation-based programming language Input/Output relation Each block defines the time invariant relation between its input and its output. A core language of equations ⊳ e 2 | if � � e ::= r | ℓ | x | d | e 1 ⋄ e 2 | e 1 ⊲ e 1 , e 2 , e 3 (1) x := e | ¯ eq ::= ℓ := S e | ℓ := e | ˙ d := S e (2) p ::= eq | eq ; p (3) with r ∈ R , constant values; ℓ ∈ V , variables associated to a block output ; x ∈ V , variables associated to continuous-time states ; d ∈ V , variables associated to discrete-time states ; ⋄ ∈ { + , − , × , ÷} , arithmetic operations; ⊳ ∈ { <, ≤ , >, ≥ , = , <> } , relational operations; ⊲ S is the set of all the sampling times. 12 / 22

Simulink as an equation-based programming language 1 12 3 1 relative_position k 1 13 14 road 15 2 Gain 1 1 1/m s dot_zb s ddot_zb 2 zb Integrator Integrator1 c(t) Gain1 x 0 x 1 8 0 1 In red: evaluation relative_position c_min 10 11 7 5 6 order of blocks 1 >= 0 � K � 4 damping_force Product1 Product Subtract Gain 9 Switch 1 z � c Unit Delay d c_max For each block in the evaluation order, a simple translation gives: ℓ 1 = input ℓ 5 = ℓ 3 − ℓ 4 ℓ 11 = ℓ 3 × ℓ 10 x 1 = ℓ 15 ˙ ℓ 6 = 1 / 40 × ℓ 5 ℓ 12 = 20000 × ℓ 3 ℓ 2 = x 1 ℓ 7 = ℓ 3 × ℓ 6 ℓ 13 = − ℓ 12 − ℓ 11 ℓ 3 = ℓ 2 − ℓ 1 ℓ 8 = 0 ℓ 14 = 1 / 250 × ℓ 13 ¯ ℓ 9 = − 16000 x 0 = ℓ 14 ˙ d = S ℓ 3 ℓ 10 = if ℓ 7 ≥ 0 then ℓ 8 else ℓ 9 ℓ 15 = x 0 ℓ 4 = d 12 / 22

Simulink as an equation-based programming language Kinds of equations A Simulink model is made of four kinds of functions: the output function; the update function of discrete-time states; the update function of continuous-time states; ℓ 11 = ℓ 3 × ℓ 10 ℓ 1 = input ℓ 5 = ℓ 3 − ℓ 4 ℓ 12 = 20000 × ℓ 3 x 1 = ℓ 15 ˙ ℓ 6 = 1 / 40 × ℓ 5 ℓ 13 = − ℓ 12 − ℓ 11 ℓ 2 = x 1 ℓ 7 = ℓ 3 × ℓ 6 1 ℓ 3 = ℓ 2 − ℓ 1 ℓ 8 = 0 ℓ 14 = 250 × ℓ 13 ¯ d = S ℓ 3 ℓ 9 = − 16000 x 0 = ℓ 14 ˙ ℓ 4 = d ℓ 10 = if ℓ 7 ≥ 0 then ℓ 8 else ℓ 9 ℓ 15 = x 0 Remark These functions allow a state-space representation of a model. 12 / 22