compositional semantics and analysis of hierarchical block...

Compositional Semantics and Analysis of HierarchicalBlock Diagrams

Iulia Dragomir1

joint work with Viorel Preoteasa1 and Stavros Tripakis1,2

1Aalto University, Finland2UC Berkeley, USA

Hierarchical block diagrams

1

Constant Scope

Inport Outport

DelaySum

g

f

e c a 1

Outport1

Inportz1

UnitDelayAdd

Consist of:

atomic components

composed components (orsubsystems)

communication links(instantaneous)

Simulink is a HBD language forembedded control system design.

Goal: compositional semantics and analysis of HBDs

Iulia Dragomir (Aalto Univ.) Compositional Semantics and Analysis of Hierarchical Block Diagrams December 8, 2016 2 / 34

Compositional semantics and analysis of HBDs

Compositional semantics:

How to translate HBDs into a formal compositional reasoning framework

Compositional analysis:

Compositional verificationCompatibility checking


Refinement Calculus of Reactive Systems (RCRS):a compositional reasoning framework

Introduced in [Tripakis et al., TOPLAS 2011], and [Preoteasa et al.,EMSOFT 2014]

Formal model:

monotonic predicate transformers3 composition operators: serial (◦), parallel (‖) and feedback (feedback)refinement operator

Allows for:

modeling open, non-deterministic, and non-input-receptive systemsmodeling safety and liveness propertiescomponent substitutability, reusabilitycompositional and incremental design


A non-trivial problem: translating HBDs into RCRSTranslation

A

a

b

c

d B

c a

Input diagram


A non-trivial problem: translating HBDs into RCRSTranslation 1

A

a

b

c

d B

c a

Input diagram

Ab B

Iddd

ac

RCRS term: feedbacka(PA ◦ (PB ‖ Id))



A

a

b

c

d B

c a

Input diagram

A dB

Idb b

ac

RCRS term: feedbackc((PB ‖ Id) ◦ PA)



A

a

b

c

d B

c a

Input diagram

Ab

c

d

B

a

RCRS term: feedbacka,c(PA ‖ PB)


A non-trivial problem: translating HBDs into RCRSQuestions

A

a

b

c

d B

c a

Input diagram

Ab B

Iddd

ac

feedbacka(PA ◦ (PB ‖ Id))

A dB

Idb b

ac

feedbackc((PB ‖ Id) ◦ PA)

Ab

c

d

B

a

feedbacka,c(PA ‖ PB)

What are the advantages/drawbacks of these expressions?→ How efficiently can these terms be analyzed?

Are these expressions semantically equivalent?


Another non-trivial problem: expansion and simplificationof RCRS terms

“DelaySum” block diagram:

g

f

e c a 1

Outport1

Inportz1

UnitDelayAdd

translation

DelaySum = feedback((Add ‖ Id) ◦ UnitDelay ◦ (Split ‖ Id))

expansion and simplification

DelaySum = [e, s s, s+ e]


Contributions

1 Implementation of RCRS in the Isabelle theorem prover

2 Translation of HBDs into RCRS

3 Expansion and simplification of RCRS terms in Isabelle

4 Case study: realistic Simulink model from Toyota


Outline

1 Context and motivation

2 The RCRS framework

3 Translation of HBDs to RCRS

4 Expansion and simplification

5 Implementation and evaluation

6 Conclusions


Monotonic predicate transformers

Classic mechanism to represent programs

Weakest precondition semantics [Dijkstra et al.]

Atomic Simulink components can be represented by monotonic predicatetransformers (MPTs)

Example:

Div = {x, y : y 6= 0} ◦ [x, y xy ] Div

x

yz


Composition operators

Serial composition

Ax

Bzy

Parallel composition

Ax y

Bz t

Feedback composition

Sx y


Outline



3 Translation of HBDs to RCRSTranslating atomic componentsTranslating HBDs



6 Conclusions


Translating (standard) atomic components

An atomic component becomes an atomic monotonic predicate transformer.

Examples:

a Div componentDiv = {x, y : y 6= 0} ◦ [x, y x

y] Div

x

yz

an Add componentAdd = [x, y x+ y]

Add

x

yz


Translating stateful atomic components

Stateful atomic components define current- and next-state variables

Example:

a UnitDelay componentUnitDelay = [x, s s, x]

UnitDelayx y

s, s′

Simulink representation

UnitDelay

s

x

s′

y

Atomic MPT representation


Translating continuous-time atomic components

Continuous-time atomic components are discretized and parameterized by dt

Example:

an Integrator componentIntegrator(dt) = [x, s s, s+ x · dt] x yIntegrator

s, s′, dt

Simulink representation

Integratordt

x

s

y

s′

Atomic MPT representation


Outline



3 Translation of HBDs to RCRSTranslating atomic componentsTranslating HBDs



6 Conclusions


Composite monotonic predicate transformers

g

f

e c a 1

Outport1

Inportz1

UnitDelayAdd

Simulink diagram

?translation


Composite MPT


Translation strategies

3 translation strategies:

feedback-parallel

incremental

feedbackless

g

f

e c a 1

Outport1

Inportz1

UnitDelayAdd

Simulink diagram

Add UnitDelay Split

f

e

c ag

c a

s'

f

s

Atomic MPTs representation


Feedback-parallel translation

Key idea: compose all components in parallel and then connect outputs toinputs by applying feedback operations

g

f

e c a 1

Outport1

Inportz1

UnitDelayAdd

feedback-parallel

Add

UnitDelay

Split

f

e

c

a g

c

as'

f

ǁ

ǁ

s

DelaySum = feedbackf,c,a(Add ‖ UnitDelay ‖ Split)


Incremental translation

Key idea:

sort components topologically according to dependencies in the diagramcompose components 1-by-1for each pair of components determine which composition operator(s) to use

g

f

e c a 1

Outport1

Inportz1

UnitDelayAdd

incremental

Add UnitDelay Split

f

e

c ag

s'

f

s

Aux = (Add ‖ Id) ◦ UnitDelay

DelaySum = feedbackf (Aux ◦ (Split ‖ Id))


Feedbackless translation

Key idea: eliminate feedback by replacing it with direct operations oncurrent- and next-state variables (like for stateful atomic components)

g

f

e c a 1

Outport1

Inportz1

UnitDelayAdd

Add UnitDelay Split

f

e

c ag

c a

s'

f

s

feedbackless

Adde

g

s'

sId

s

s

Add Idud1

Idsplt1

fe

c

a g

s'

sIdud2 Idsplt2

aIdud2

s

s

DelaySum = [s, e s, s, e] ◦ (Id ‖ Add)


Outline






6 Conclusions


From composite MPTs to atomic MPTs

g

f

e c a 1

Outport1

Inportz1

UnitDelayAdd

Simulink diagram

translation


Composite MPT

expansion and simplification ?

DelaySum = [e, s s, s+ e]

Simplified (atomic) MPT


Obtaining simplified MPTs

Expand definitions of MPTs, ◦, ‖ and feedback→ an MPT of the form {p} ◦ [f ] is obtained→ but formulas p and f can grow very large ...

Simplify p and f using rewriting rules

1600 lines of Isabelle code


Compatibility checking

Simplify the CPT to an MPT {p} ◦ [f ]

Verify that p is not false

A satisfiability problem


Outline






6 Conclusions


Toolset

Powertrain Control Benchmark Model

Toyota Technial Center

2014

This is a model of a hybrid automaton with polynomial dynamics, and an implementation of the 3rd model that appears in

"Powertrain Control Verification Benchmark", 2014 Hybrid Systems: Computation and Control,

X. Jin, J. V. Deshmukh, J.Kapinski, K. Ueda, and K. Butts

Fuel Control System Model This model uses only the ODEs to implement the dynamics.

3

controller_mode

1

A/F

1s

pe

1s

p

1s

lambda

1s

i

~=

~= ~=

Starup Mode

Power Mode Guard

0.0

ODE4 Open

f(u)

ODE4 Closed

f(u)

ODE3

f(u)

ODE2

f(u)

ODE1

OR

f(u)

InputPoly

f(u)

Fuel Cmd Open Pwr

f(u)

Fuel Cmd Open

f(u)

Fuel Cmd Closed

FaultInjection

1: Failure

0: Normal

theta [0 90]

pi/30

(rpm) to (rad/s)

2

engine speed (rpm)

[900,1100]

1

throttle input (deg)

[0, 81.2]

AND

NOT

1.1s+1

Throttle del ay1

8.8

Base opening angle

In Out

Startup Mode Latch

In Out

Sensor Failure Detection Latch

boolean

boolean

2

airbyfuel_ref

~= double

14.7

12.5

Simulinkdiagram

Translator(simulink2isabelle)

Options(translation strategy, etc.)

Formal model of the diagram

Formal Analyzer(built on top of

Isabelle theoremprover)

incompatiblity detection

auto generated top-level contract

substitutability checking

Python code generation

internal variable elimination

RCRS theory and component library

Publicly available at: rcrs.cs.aalto.fi


rcrs.cs.aalto.fi

Case study: Automotive Fuel Control System by Toyota

Publicly available benchmark: http://cps-vo.org/group/ARCH/benchmarks

Simulink model:

3-level hierarchy104 blocks: 97 atomic blocks and 7 subsystems101 links of which 7 feedbacks

PowertrainControlBenchmarkModelToyotaTechnialCenter

2014

Thisisamodelofahybridautomatonwithpolynomialdynamics,andanimplementationofthe3rdmodelthatappearsin"PowertrainControlVerificationBenchmark",2014HybridSystems:ComputationandControl,X.Jin,J.V.Deshmukh,J.Kapinski,K.Ueda,andK.Butts

FuelControlSystemModel ThismodelusesonlytheODEstoimplementthedynamics.

3

controller_mode

1

A/F

1s

pe

1s

p

1s

lambda

1s

i

~=

~= ~=

StarupMode

PowerModeGuard

0.0

ODE4Open

f(u)

ODE4Closed

f(u)

ODE3

f(u)

ODE2

f(u)

ODE1

OR

f(u)

InputPoly

f(u)

FuelCmdOpenPwr

f(u)

FuelCmdOpen

f(u)

FuelCmdClosed

FaultInjection1:Failure0:Normal

theta[090]

pi/30

(rpm)to(rad/s)

2

enginespeed(rpm)[900,1100]

1

throttleinput(deg)[0,81.2]

AND

NOT

1.1s+1

Throttledelay1

8.8

Baseopeningangle

In Out

StartupModeLatch

In Out

SensorFailureDetectionLatch

boolean

boolean

2

airbyfuel_ref

~= double

14.7

12.5


http://cps-vo.org/group/ARCH/benchmarks

Evaluation results I

Negligible translation time (< 1sec) for all 3 strategies

Expansion/simplification time:

feedback-parallel strategy: 10min to 50min (depending on translation options)incremental strategy: 2min to 40min (depending on translation options)feedbackless strategy: < 1min


Evaluation results II

Length of the final, top-level, simplified MPT: 122k characters


Semantical equivalence of the translation strategies

For all studied examples, the simplified MPTs are semantically equivalent

Generally: the simplified MPTs obtained with all translations strategies aresemantically equivalent

Results proved in Isabelle


Compatibility checking

The FCS Simulink model is proven compatible ∀dt > 0

i.e., the model’s simplified assert condition is satisfiable ∀dt > 0

→ proved in Isabelle

All Isabelle proofs available at rcrs.cs.aalto.fi


rcrs.cs.aalto.fi

Validation by simulation

From Isabelle we can automatically generate simulation code (in Python)

Simulation plots obtained from the FCS model using Simulink vs. our toolare nearly identical

|error| ≤ 6.1487 · 10−5

0 5 10 15 20 25 30 35 40 45 50

-0.01

0

0.01

0 5 10 15 20 25 30 35 40 45 50-0.01

0

0.01

Simulink simulation Simulation of the simplified MPT


Outline






6 Conclusions


Conclusion

Powertrain Control Benchmark Model

Toyota Technial Center

2014

This is a model of a hybrid automaton with polynomial dynamics, and an implementation of the 3rd model that appears in

"Powertrain Control Verification Benchmark", 2014 Hybrid Systems: Computation and Control,

X. Jin, J. V. Deshmukh, J.Kapinski, K. Ueda, and K. Butts

Fuel Control System Model This model uses only the ODEs to implement the dynamics.

3

controller_mode

1

A/F

1s

pe

1s

p

1s

lambda

1s

i

~=

~= ~=

Starup Mode

Power Mode Guard

0.0

ODE4 Open

f(u)

ODE4 Closed

f(u)

ODE3

f(u)

ODE2

f(u)

ODE1

OR

f(u)

InputPoly

f(u)

Fuel Cmd Open Pwr

f(u)

Fuel Cmd Open

f(u)

Fuel Cmd Closed

FaultInjection

1: Failure

0: Normal

theta [0 90]

pi/30

(rpm) to (rad/s)

2

engine speed (rpm)

[900,1100]

1

throttle input (deg)

[0, 81.2]

AND

NOT

1.1s+1

Throttle del ay1

8.8

Base opening angle

In Out

Startup Mode Latch

In Out

Sensor Failure Detection Latch

boolean

boolean

2

airbyfuel_ref

~= double

14.7

12.5

Simulinkdiagram

Translator(simulink2isabelle)

Options(translation strategy, etc.)

Formal model of the diagram

Formal Analyzer(built on top of

Isabelle theoremprover)

incompatiblity detection

auto generated top-level contract

substitutability checking

Python code generation

internal variable elimination

RCRS theory and component library

Compositional semantics of HBDs

3 translation strategies of HBDs to RCRS

Implementation of the RCRS framework in Isabelle

Evaluation on real-life automotive case study

Thank you!Questions?


compositional semantics and analysis of hierarchical block...

Documents