critical real time software verification - inria
TRANSCRIPT
![Page 1: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/1.jpg)
Critical Real Time Software Verification
A. Ressouche*
(*) Inria Sophia Antipolis-Méditerranée
08/01/2014 Critical Software
![Page 2: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/2.jpg)
Outline
1. Critical software design
2. Critical software validation techniques
3. Model checking
1. Model specification
2. Synchronous languages
3. Scade
4. Model Checking Technique
1. Property definition
2. Validation technique
08/01/2014 Critical Software
![Page 3: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/3.jpg)
08/01/2014 Critical Software
Critical Software
Roughly speaking a critical system is a system whose failure could have serious consequences
Nuclear technology
Transportation
Automotive
Train
Avionics
…………
![Page 4: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/4.jpg)
08/01/2014 Critical Software
Critical Software (2)
In addition , other consequences are relevant to determine the critical aspect of a software:
Financial aspect
Loosing of equipment, bug correction
Equipment callback (automotive)
Bad advertising
Intel famous bug
![Page 5: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/5.jpg)
08/01/2014 Critical Software
Software Classification
Example of the aeronautics norm DO178B: A Catastrophic (human life
loss)
B Dangerous (serious injuries, loss of goods)
C Major (failure or loss of the system)
D Minor (without consequence on the system)
E Without effect
Depending of the level of risk of the system, different kinds of verification are required
![Page 6: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/6.jpg)
08/01/2014 Critical Software
Software Classification (avionics)
Minor acceptable situation
Major
Dangerous Unacceptable situation
catastrophic 10-3 / hour 10-6 / hour
10-9/hour 10-12/hour
probabilities probable rare very rare very improbable
![Page 7: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/7.jpg)
08/01/2014 Critical Software
How Develop critical software ?
Classical Development V Cycle
investigation Qualification in laboratory in operation
specification
design
development tests
integration
validation
tests white box
tests black box
tests of integrated system
![Page 8: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/8.jpg)
08/01/2014 Critical Software
How Develop Critical Software ?
Cost of critical software development: Specification : 10%
Design: 10%
Development: 25%
Integration tests: 5%
Validation: 50%
Fact:
Earlier an error is detected, more expensive its correction is.
![Page 9: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/9.jpg)
08/01/2014 Critical Software
Cost of Error Correction
error detection time
cost of error
correction
Put the effort on the upstream phase
development based on models
![Page 10: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/10.jpg)
08/01/2014 Critical Software
How Develop Critical Software ?
Goals of critical software specification:
Define application needs
specific domain engineers
Allowing application development
Coherency
Completeness
Allowing application functional validation
Express properties to be validated
Formal models usage
![Page 11: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/11.jpg)
08/01/2014 Critical Software
Critical software specification
First Goal: must yield a formal description of the application needs:
Standard to allowing communication between computer science engineers and non computer science ones
General enough to allow different kinds of application:
Synchronous (and/or)
Asynchronous (and/or)
Algorithmic
![Page 12: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/12.jpg)
08/01/2014 Critical Software
Critical software specification
Second Goal: allowing errors detection carried out upstream:
Validation of the specification:
Coherency
Completeness
Proofs
Test
Quick prototype development
Specification simulation
![Page 13: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/13.jpg)
08/01/2014 Critical Software
Example of non completeness
From Ariane 5:
helium tank low
hydrogen tank low
action action
Simultaneous events ?
unspecified action
![Page 14: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/14.jpg)
08/01/2014 Critical Software
Critical Software Specification (3)
Third goal: make easier the transition from specification to design (refinement)
Reuse of specification simulation tests
Formalization of design
Code generation
Sequential/distributed
Toward a target language
Embedded/qualified code
![Page 15: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/15.jpg)
08/01/2014 Critical Software
Relying on Formal Methods
test reuse test coverage
test generation MODEL
proofs
code
automatic code generation
functional validation
abstract interpretation
simulation
no more integration tests
![Page 16: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/16.jpg)
08/01/2014 Critical Software
Critical Software Validation
What is a correct software?
No execution errors, time constraints respected, compliance of results.
Solutions:
At model level :
Simulation
Formal proofs
At implementation level:
Test
Abstract interpretation
![Page 17: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/17.jpg)
08/01/2014 Critical Software
Validation Methods
Testing
Run the program on set of inputs and check the results
Static Analysis
Examine the source code to increase confidence that it works as intended
Formal Verification
Argue formally that the application always works as intended
![Page 18: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/18.jpg)
08/01/2014 Critical Software
Testing
Dynamic verification process applied at implementation level.
Feed the system (or one if its components) with a set of input data values:
Input data set not too large to avoid huge time testing procedure.
Maximal coverage of different cases required.
![Page 19: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/19.jpg)
08/01/2014 Critical Software
Testing (2)
Program Testing
Concrete semantics
Test coverage errors
all program executions
executions tested ok
undetected failure
“Testing only highlights bugs but not ensure their absence “ (E. Dijkstra)
![Page 20: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/20.jpg)
08/01/2014 Critical Software
Static Analysis
The aim of static analysis is to search for errors without running the program.
Abstract interpretation = replace data of the program by an abstraction in order to be able to compute program properties.
Abstraction must ensure :
A(P) “correct” P correct
But A(P) “incorrect” ?
![Page 21: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/21.jpg)
08/01/2014 Critical Software
Static Analysis: example
abstraction: integer by intervals
1: x:= 1;
2: while (x < 1000) {
3: x := x+1;
4: }
x1 = [1,1]
x2 = x1 U x3 ∩ [-∞, 999]
x3 = x2 [1,1]
x4 = x1 U x3 ∩ [1000, ∞]
Abstract interpretation theory values are fix
point equation solutions.
![Page 22: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/22.jpg)
08/01/2014 Critical Software
Formal verification
What about functional validation ?
Does the program compute the expected outputs?
Respect of time constraints (temporal properties)
Intuitive partition of temporal properties:
Safety properties: something bad never happens
Liveness properties: something good eventually happens
![Page 23: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/23.jpg)
08/01/2014 Critical Software
Safety and Liveness Properties
Example: the beacon counter in a train:
Count the difference between beacons and seconds
Decide when the train is ontime, late, early ontime : difference = 0
late : difference > 3 and it was ontime before or difference > 1 and it was already late before
early : difference < -3 and it was ontime before or difference < -1 and it was ontime before
![Page 24: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/24.jpg)
08/01/2014 Critical Software
Safety and Liveness Properties
Some properties:
1. It is impossible to be late and early;
2. It is impossible to directly pass from late to early;
3. It is impossible to remain late only one instant;
4. If the train stops, it will eventually get late
Properties 1, 2, 3 : safety
Property 4 : liveness
It refers to unbound future
![Page 25: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/25.jpg)
08/01/2014 Critical Software
Safety and Liveness Properties Checking
Use of model checking techniques
Model checking goal: prove safety and liveness properties of a system in analyzing a model of the system.
Model checking techniques require:
model of the system
express properties
algorithm to check properties on the model ( decidability)
![Page 26: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/26.jpg)
08/01/2014 Critical Software
Model Checking Techniques
Model = automata which is the set of program behaviors
Properties expression = temporal logic:
LTL : liveness properties
CTL: safety properties
Algorithm =
LTL : algorithm exponential wrt the formula size and linear wrt automata size.
CTL: algorithm linear wrt formula size and wrt automata size
![Page 27: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/27.jpg)
Model Checking Model Specification
• Model = automata which is the set of program behaviors
27 08/01/2014 27
![Page 28: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/28.jpg)
Model Specification
• Model = automata which is the set of program behaviors
• An automata is composed of: 1. A finite set of states (Q)
2. A finite alphabet of actions (A)
3. An initial state (qinit € Q)
4. A transition relation (R in Q x Q) 5. A labeling function λ : Q x Q → A
28
Notation: a transition is denoted q1 q2 a
![Page 29: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/29.jpg)
Model Specification
• Model = automata which is the set of program behaviors
Example: Traffic Light
trigger: tick, reset
action:green,orange,red
reset
tick/green
tick/orange
tick/red
tick/green reset
reset
![Page 30: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/30.jpg)
08/01/2014 Critical Software
Model Specification
![Page 31: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/31.jpg)
Model Specification
How design automata as system behaviors ?
Use synchronous languages to specify critical systems.
Synchronous programs = automata
![Page 32: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/32.jpg)
Model Specification with Synchronous
Languages
1. Synchronous languages have a simple formal model (a finite automaton) making formal reasoning tractable.
2. Synchronous languages support concurrency and offer an implicit or explicit means to express parallelism.
3. Synchronous languages are devoted to design reactive real-time systems.
![Page 33: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/33.jpg)
Determinism & Reactivity
• Synchronous languages are deterministic and reactive
• Determinism:
• The same input sequence always yields the same output sequence
• Reactivity:
• The program must react(*) to any stimulus
• Implies absence of deadlock • (*) Does not necessary generate outputs, the reaction may change internal state only.
![Page 34: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/34.jpg)
Synchronous Reactive Systems (1)
Environment
Read
08/01/2014 34
![Page 35: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/35.jpg)
Synchronous Reactive Systems (2)
Environment
Computations
08/01/2014 35
![Page 36: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/36.jpg)
Synchronous Reactive Systems (3)
Environment
Write
Atomic execution: read, compute, write
08/01/2014 36
![Page 37: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/37.jpg)
Synchronous Hypothesis
• Synchronous languages work on a logical time.
• The time is
– Discrete
– Total ordering of instants.
• A reaction executes in one instant.
• Actions that compose the reaction may be partially ordered.
Use N as time base
![Page 38: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/38.jpg)
Synchronous Hypothesis
• Communications between actors are also supposed to be instantaneous.
• All parts of a synchronous model receive exactly the same information (instantaneous broadcast).
• Outcome: Outputs are simultaneous with Inputs (they are said to be synchronous)
• Thanks to these strong hypotheses, program execution is fully deterministic.
![Page 39: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/39.jpg)
Reactive ?
• Different ways to “react” to the environment:
– Event driven system:
• Receive events
• Answer by sending events
– Data flow system:
• Receive data continuously
• Answer by treating data continuously also
Some systems have components of
both kinds
![Page 40: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/40.jpg)
Event Driven Reactive System
landing
open gear door
gear door opened gear down
push down gear block gear
Langing gear management
![Page 41: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/41.jpg)
Data Flow Reactive System (Example)
sensors
navigation
guidance
piloting
operators
Periodic
pro
cess
us
• get measures
• where am I ?
• where go I ?
• command computation
• command to operators
Control/Command vehicle
![Page 42: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/42.jpg)
Imperative and Declarative languages
Different ways to express synchronous programs:
1. Imperative languages rely on implicitly or explicitly finite state machines, well suited to design event driven reactive system
2. Declarative languages rely on operator networks computing data flows, well suited to design data flow reactive system
08/01/2014 42
![Page 43: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/43.jpg)
Event Driven = FSM
Event driven applications can be designed: 1. As simple finite sate machines (=
automata) 2. As the synchronous product of finite
state machines
![Page 44: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/44.jpg)
08/01/2014 Critical Software
Data Flow = Operator Networks
LUSTRE programs can be interpreted as networks of operators.
Data « flow » to operators where they are consumed. Then, the operators generate new data. (Data Flow description).
op1
op2
op3
Operator
Token
(data)
![Page 45: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/45.jpg)
08/01/2014 Critical Software
An example of Data Flow
![Page 46: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/46.jpg)
08/01/2014 Critical Software
Data Flow
![Page 47: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/47.jpg)
08/01/2014 Critical Software
Data Flow
![Page 48: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/48.jpg)
08/01/2014 Critical Software
Data Flow
![Page 49: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/49.jpg)
08/01/2014 Critical Software
Data Flow
![Page 50: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/50.jpg)
08/01/2014 Critical Software
Data Flow
![Page 51: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/51.jpg)
08/01/2014 Critical Software
Functional Point of View
DIT FFT
P P’
Q Q’ *'
*'
k
N
k
N
P
Q
W
W
P Q
P Q
![Page 52: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/52.jpg)
08/01/2014 Critical Software
Flows, Clocks
A flow is a pair made of
A possibly infinite sequence of values of a given type
A clock representing a sequence of instants
X:T (x1, x2, … , xn, … )
![Page 53: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/53.jpg)
Data Flow Synchronous Languages
1. Data flow programs compute output flows from input flows using: 1. Variables (= flows) 2. Equation: x = E means xk = Ek
3. Assertion: Boolean expression that should be always true.
2. Data flow programs define new data flow operators.
k
![Page 54: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/54.jpg)
08/01/2014 Critical Software
Substitution principle: if X = E then E can be substituted for X
anywhere in the program and conversely
Definition principle:
A variable is fully defined by its declaration
and the equation in which it appears as a
left-hand side term
Data Flow Synchronous Languages
![Page 55: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/55.jpg)
Data Flow Synchronous Languages
operator Average (X,Y:int) returns (M:int) M = (X + Y)/2 X = (X1,X2,….,Xn,…….) Y = (Y1,Y2,…..,Yn,……..) M = ((X1+Y1)/2, X2+Y2)/2,……,(Xn+Yn)/2,….)
Average
X:int
Y:int
M:int
![Page 56: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/56.jpg)
08/01/2014 Critical Software
Constants 0, 1, …, true, false, …, 1.52, ...
Expressions
+
Imported
types and
operators
int
bool
real
![Page 57: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/57.jpg)
08/01/2014 Critical Software
« Combinational » Operators
Data operators
Arithmetical: +, -, *, /, div, mod
Logical: and, or, not, xor, =>
Conditional: if … then … else ...
Casts: int, real
YopXYopXkYopX kkk )(,
« Point-wise » operators
![Page 58: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/58.jpg)
08/01/2014 Critical Software
« Combinational » Operator IF
if operator
operator Max (a,b : real) returns (m: real) let m = if (a >= b) then a else b; tel
functional «if then else »; it is not a statement
![Page 59: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/59.jpg)
08/01/2014 Critical Software
« Combinational » Operator IF
if operator
operator Max (a,b : real) returns (m: real) let m = if (a >= b) then a else b; tel
let if (a >= b) then m = a ; else m = b; tel
![Page 60: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/60.jpg)
08/01/2014 Critical Software
Memorizing
Take the past into account!
1 2 1 1( , , , , ) : ( ) nil, , , ,n nX x x x pre X x x
pre (previous):
-> (initialize): sometimes call “followed by”
1 2 1 2
1 2
( , , , , ) , ( , , , , ) :
( ) ( , , , , )
n n
n
X x x x Y y y y
X Y x y y
Undefined value denoting uninitialized memory: nil
![Page 61: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/61.jpg)
08/01/2014 Critical Software
« Sequential » Examples
n = 0 pre(n) +1
+ 1
0
pre
n
![Page 62: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/62.jpg)
08/01/2014 Critical Software
Sequential » Examples
operator MinMax (X:int) returns (min,max:int);
min = X -> if (X < pre min) then X else pre min;
max = X -> if (X > pre max) then X else pre max;
![Page 63: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/63.jpg)
Sequential examples
operator CT (init:int) returns (c:int): c = init → pre(c) + 2 operator DoubleCall (even:bool) returns (n:int)
n= if (even) then CT(0) else CT(1) DoubleCall (ff,ff,tt,tt,ff,ff,tt,tt,ff) = ?
08/01/2014 63
![Page 64: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/64.jpg)
Sequential examples
operator CT (init:int) returns (c:int): c = init → pre(c) + 2 CT(0) = (0,2,4,6,8,10,12,14,16,18,….) CT(1) = (1,3,5,7,9,11,13,15,17,19,….) operator DoubleCall (even:bool) returns (n:int)
n= if (even) then CT(0) else CT(1) DoubleCall (ff,ff,tt,tt,ff,ff,tt,tt,ff) = ? (1,3,4,6,9,11,12,14,17)
08/01/2014 64
![Page 65: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/65.jpg)
08/01/2014 Critical Software
Recursive definitions
Temporal recursion
Usual. Use pre and ->
e.g.: nat = 1 -> pre nat + 1
Instantaneous recursion
e.g.: X = 1.0 / (2.0 – X)
Forbidden in Lustre, even if a solution exists!
Be carefull with cross-recursion.
![Page 66: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/66.jpg)
08/01/2014 Critical Software
Clocks
Basic clock
Discrete time induced by the input sequence
Derived clocks (slower)
when (filter operator): E when C is the sub-sequence of E obtained by keeping only the values of indexes ek for which
ck=true
![Page 67: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/67.jpg)
08/01/2014 Critical Software
Examples of clocks
Basic cycles
C1
Cycles of C1
C2
Cycles of C2
1
true
1
false
2
false
3
true
2
true
1
4
true
3
false
5
false
6
true
4
true
2
7
false
8
true
5
true
3
![Page 68: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/68.jpg)
08/01/2014 Critical Software
Example of sampling
nat,odd:int
halfBaseClock:bool
nat = 0 -> pre nat +1;
halfBaseClock =
true -> not pre halfBaseClock;
odd = nat when halfBaseClock; nat is a flow on the basic clock; odd is a flow on halfBaseClock
Exercice: write even
![Page 69: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/69.jpg)
Modulo Counter
operator MCounter (incr:bool; modulo : int) returns (cpt:int); var count : int; count = 0 -> if incr pre (cpt) + 1 else pre (cpt); cpt = count mod modulo;
![Page 70: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/70.jpg)
Modulo Counter Clock
operator MCounterClock (incr:bool; modulo : int) returns(cpt:int; modulo_clock: bool); var count : int; count = 0 -> if incr pre (cpt) + 1 else pre (cpt); cpt = count mod modulo;
modulo_clock = count != cpt;
![Page 71: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/71.jpg)
Modulo Counter Clock
var count : int; count = 0 -> if incr pre (cpt) + 1 else pre (cpt); cpt = count mod modulo; modulo_clock = count != cpt;
MCounterClock(true,3): count: 0 1 2 3 1 2 3…… cpt = 0 1 2 0 1 2 0…….. modulo_clock = ff ff ff tt ff ff tt ….
![Page 72: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/72.jpg)
Timer
operator Timer returns (hour, minute, second:int); var hour_clock, minute_clock, day_clock : bool;
(second, minute_clock) = MCounterClock(true, 60); (minute, hour_clock) = MCounterClock(minute_clock,60); (hour, dummy_clock) = MCounterClock(hour_clock, 24);
![Page 73: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/73.jpg)
Data Flow Programs Compilation
Data flow programs are compiled into automata
![Page 74: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/74.jpg)
Data Flow Program Compilation
operator WD (set, reset, deadline:bool) returns (alarm:bool); var is_set:bool; alarm = is_set and deadline; is_set = false -> if set then true else if reset then false else pre(is_set); assert not(set and reset);
![Page 75: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/75.jpg)
Data Flow Program Compilation
First, the program is translated into pseudo code: if _init then // first instant (or reaction) is_set := false; alarm := false; _init := false; else // following reactions if set then is_set := true else if reset then is_set := false; endif endif alarm := is_set and deadline; endif
![Page 76: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/76.jpg)
Data Flow Program Compilation
3 states: S0: _init = true and pre_is_set = nil S1: _init = false and pre_is_set = false S2: _init = false and pre_is_set = true
For WD, we consider 2 state variables: _init (true, false, false, ….) and pre_is_set
Choose state variables : _init and variables which have pre.
08/01/2014 76
![Page 77: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/77.jpg)
Data Flow Program Compilation
S1:
_init := false pre_is_set= false
S0: alarm := false;
initial
08/01/2014 77
if _init then // first instant (or reaction) is_set := false; alarm := false _ init := false; else // following reactions if set then is_set := true else if reset then is_set := false; endif endif alarm := is_set and deadline; endif
![Page 78: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/78.jpg)
Data Flow Program Compilation
S1: if set then alarm:= deadline; go to S2; else alarm := false; go to S1;
S2:
_init = false; pre(is_set) := true;
S0: alarm := false;
initial
¬set
set
08/01/2014 78
if _init then // first instant (or reaction) is_set := false; alarm := false; _init := false; else // following reactions if set then is_set := true else if reset then is_set := false; endif endif alarm := is_set and deadline; endif
![Page 79: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/79.jpg)
Data Flow Program Compilation
S1: if set then alarm:= deadline;
go to S2; else
alarm := false; go to S1;
S2:
_init = false; pre_is_set := true;
S0: alarm := false;
initial
¬set
set
08/01/2014 79
![Page 80: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/80.jpg)
Lustre Program Compilation
S1: if set then alarm:= deadline;
go to S2; else
alarm := false; go to S1;
S2: if set then alarm := deadline; go to S2; else if reset then alarm := false; go to S1; else alarm := deadline; go to S2;
S0: alarm := false;
initial
¬set ¬reset
reset
set
08/01/2014 80
if _init then // first instant (or reaction) is_set := false; alarm := false; _init := false; else // following reactions if set then is_set := true else if reset then is_set := false; endif endif alarm := is_set and deadline; endif
![Page 81: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/81.jpg)
Lustre Program Compilation
S1: if set then alarm:= deadline;
go to S2; else
alarm := false; go to S1;
S2: if set then alarm := deadline;
go to S2; else
if reset then alarm := false;
go to S1; else
alarm := deadline; go to S2;
S0: alarm := false;
initial
¬set ¬reset
reset
set
08/01/2014 81
![Page 82: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/82.jpg)
08/01/2014 Critical Software
Model Checking of Data Flow programs with Observers
Express safety properties as observers.
An observer is a program which observes the program and outputs ok when the property holds and failure when its fails
program
observer
inputs outputs
ok failure
![Page 83: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/83.jpg)
08/01/2014 Critical Software
Properties Validation
Taking into account the environment
without any assumption on the environment, proving properties is difficult
but the environment is indeterminist
Human presence no predictable
Fault occurrence
…
Solution: use assertion to make hypothesis on the environment and make it determinist
![Page 84: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/84.jpg)
08/01/2014 Critical Software
Properties Validation (2)
Express safety properties as observers.
Express constraints about the environment as assertions.
program
observer
inputs outputs
ok failure
assertions assume
![Page 85: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/85.jpg)
08/01/2014 Critical Software
Properties Validation (3)
if assume remains true, then ok also remains true (or failure false).
program
observer
inputs outputs
ok failure
assertions assume
![Page 86: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/86.jpg)
08/01/2014 Critical Software
Safety and Liveness Properties
Example: the beacon counter in a train:
Count the difference between beacons and seconds
Decide when the train is ontime, late, early operator train (sec, bea : bool) returns (ontime, early, late: bool) diff = (0 ->pre diff) + (if bea then 1 else 0) + (if sec then -1 else 0); early = (true -> pre ontime) and (diff > 3) or (false -> pre early) and (diff > 1); late = (true -> pre ontime) and (diff < -3) or (false -> pre late) and (diff < -1); ontime = not (early or late);
![Page 87: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/87.jpg)
08/01/2014 Critical Software
Train Safety Properties
It is impossible to be late and early;
ok = not (late and early)
It is impossible to directly pass from late to early;
ok = true -> (not early and pre late);
It is impossible to remain late only one instant;
Plate = false -> pre late; PPlate = false -> pre Plate; ok = not (not late and Plate and not PPlate);
![Page 88: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/88.jpg)
08/01/2014 Critical Software
Train Assumptions
property = assumption + observer: “ if the train keeps the right speed, it remains on time”
observer = ok = ontime
assumption:
naïve: assume = (bea = sec);
more precise : bea and sec alternate:
SF = Switch (sec and not bea, bea and not sec); BF = Switch (bea and not sec, sec and not bea); assume = (SF => not sec) and (BF => not bea);
![Page 89: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/89.jpg)
SCADE: Safety-Critical Application Development Environment
Scade has been developped to address safety-critical embedded application design
The Scade suite KCG code generator has been qualified as a development tool according to DO-178B norm at level A.
08/01/2014 Critical Software
![Page 90: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/90.jpg)
SCADE
Scade has been used to develop, validate and generate code for:
avionics:
Airbus A 341: flight controls
Airbus A 380: Flight controls, cockpit display, fuel control, braking, etc,..
Eurocopter EC-225 : Automatic pilot
Dassault Aviaation F7X: Flight Controls, landing gear, braking
Boeing 787: Landing gear, nose wheel steering, braking
08/01/2014 Critical Software
![Page 91: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/91.jpg)
System Design
Both data flows and state machines
Simulation
Graphical simulation, automatic GUI integration
Verification
Apply observer technique
Code Generation
certified C code
SCADE
Critical Software 08/01/2014
![Page 92: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/92.jpg)
Modulo Counter
operator MCounter (incr:bool; modulo : int) returns (cpt:int); var count : int; count = 0 -> if incr pre (cpt) + 1 else pre (cpt); cpt = count mod modulo;
![Page 93: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/93.jpg)
Modulo Counter
count = 0 -> if incr pre (cpt) + 1 else pre (cpt); cpt = count mod modulo;
![Page 94: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/94.jpg)
Modulo Counter Clock
operator MCounterClock (incr:bool; modulo : int) returns(cpt:int; modulo_clock: bool); var count : int; count = 0 -> if incr pre (cpt) + 1 else pre (cpt); cpt = count mod modulo;
modulo_clock = count <> cpt;
![Page 95: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/95.jpg)
Modulo Counter Clock
![Page 96: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/96.jpg)
Timer
operator Timer returns (hour, minute, second:int); var hour_clock, minute_clock, day_clock : bool; (second, minute_clock) = MCounterClock(true, 60); (minute, hour_clock) = MCounterClock(minute_clock,60); (hour, dummy_clock) = MCounterClock(hour_clock, 24);
![Page 97: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/97.jpg)
Timer
![Page 98: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/98.jpg)
SCADE: state machines
Input and output: same interface
States:
Possible hierarchy
Start in the initial state
Content = application behavior
Transitions:
From a state to another one
Triggered by a Boolean condition
08/01/2014 98
![Page 99: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/99.jpg)
SCADE: state machines
state
transition
trigger
When ON, ison = true
When off, ison = false
08/01/2014 99
![Page 100: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/100.jpg)
08/01/2014 Critical Software
SCADE: model checking
Observers in Scade
P: aircraft autopilot and security system
P aircraft_altitude landing_order
aircraft_altitude
200
landing_order not
alarm
alarm
and
implies
![Page 101: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/101.jpg)
SCADE: model checking
Observer technique
posture model
posture model specification in scade
08/01/2014 101
![Page 102: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/102.jpg)
SCADE: model checking
Observer technique
posture observer
posture verification
failure
lying: true; sitting:true;standing:true
08/01/2014 102
![Page 103: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/103.jpg)
SCADE: model checking
Observer technique
posture observer
posture verification
valid
assume (lying # sitting # standing)
08/01/2014 103
![Page 104: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/104.jpg)
SCADE: code generation
KCG generates certifiable code (DO-178 compliance)
Clean code, rigid structure (easy integration)
Interfacing potential with user-defined code (c/c++)
08/01/2014 104
![Page 105: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/105.jpg)
SCADE: code generation structures
InC_<operator_name>
structure C
one member for each input
OutC_<operator_name>
Structure C
one member for each output and each state
Other members for output/state computations
08/01/2014 105
![Page 106: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/106.jpg)
SCADE: code generation structures
Reaction function
for a transition (or a reaction) computes the output and the new state
void <operator_name> (Inc_<operator_name> * inC, outC_<operator_name>* outc)
Reset function
To reset the reaction and the structures
void <operator_name>_reset (outC_<operator_name>* outc
08/01/2014 106
![Page 107: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/107.jpg)
SCADE: code generation files
Generated files
<operator_name>.h : type and function declarations for code integration
<operator_name>.c : implementation of reaction and reset functions
kcg_types.(h,c) to define types in C
kcg_conts.(h,c) to define contants
08/01/2014 107
![Page 108: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/108.jpg)
08/01/2014 Critical Software
CHECKING TEMPORAL PROPERTIES
![Page 109: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/109.jpg)
08/01/2014 Critical Software
Properties Checking
Liveness Property :
automata B()
L(B()) = décidable
|= M : L(M B(~)) =
Scade allows only to verify safety properties, thus we will study such properties verification techniques.
![Page 110: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/110.jpg)
08/01/2014 Critical Software
Safety Properties
CTL formula characterization:
Atomic formulas
Usual logic operators: not, and, or ()
Specific temporal operators:
EX , EF , EG
AX , AF , AG
EU(1 ,2), AU(1 ,2)
![Page 111: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/111.jpg)
08/01/2014 Critical Software
Safety Properties Verification (1)
Mathematical framework: S : finite state, (P (S), ) is a complete lattice
with S as greater element and as least one.
f : P (S) P (S) :
f is monotonic iff x,y P (S), x y f(x) f(y)
f is -continue iff for each decreasing sequence f( xi) = f(xi)
f is -continue iff for each increasing sequence f( xi) = f(xi)
![Page 112: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/112.jpg)
08/01/2014 Critical Software
Safety Properties Verification (2)
Mathematical framework:
if S is finite then monotonic -continue et -continue.
x is a fix point iff of f iff f(x) = x
x is a least fix point (lfp) iff y such that f(y) = y, x y
x is a greatest fix point (gfp) iff y such that f(y) = y, y x
![Page 113: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/113.jpg)
08/01/2014 Critical Software
Safety Properties Verification (3)
Theorem:
f monotonic f has a lfp (resp glp)
lfp(f) = fn()
gfp(f) = fn(S)
Fixpoints are limits of approximations
![Page 114: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/114.jpg)
08/01/2014 Critical Software
Safety Properties Verification (4)
We call Sat() the set of states where is true.
M |= iff sinit Sat().
Algorithm: Sat() = { s | |= s}
Sat(not ) = S\Sat()
Sat(1 or 2) = Sat(1) U Sat(2)
Sat (EX ) = {s | t Sat() , s → t} (Pre Sat())
Sat (EG ) = gfp ((x) = Sat() Pre(x))
Sat (E(1 U 2)) = lfp ((x) = Sat(2) U (Sat(1) Pre(x))
![Page 115: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/115.jpg)
08/01/2014 Critical Software
Example
s0 s1
s2
s3 s4
atomic formulas: a, b, c a b
a,b,c
c b,c
EG (a or b) gfp ((x) = Sat() Pre(x))
({s0, s1, s2, s3, s4}) = Sat (a or b) Pre({s0, s1, s2, s3, s4})
({s0, s1, s2, s3, s4}) = {s0, s1, s2, s4} {s0, s1, s2, s3, s4}
({s0, s1, s2, s3, s4}) = {s0, s1, s2, s4}
![Page 116: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/116.jpg)
08/01/2014 Critical Software
Example
s0 s1
s2
s3 s4
atomic formulas: a, b, c a b
a,b,c
c b,c
EG (a or b) ({s0, s1, s2, s3, s4}) = {s0, s1, s2, s4}
({s0, s1, s2, s4}) = Sat (a or b) Pre({s0, s1, s2,, s4})
({s0, s1, s2, s4}) = {s0, s1, s2, s4}
S0 |= EG( a or b)
![Page 117: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/117.jpg)
08/01/2014 Critical Software
Model checking implementation
Problem: the size of automata
Solution: symbolic model checking
Usage of BDD (Binary Decision Diagram) to encode both automata and formula.
Each Boolean function has a unique representation
Shannon decomposition: f(x0,x1,…,xn) = f(1, x1,…., xn) v f(0, x1,…,xn)
![Page 118: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/118.jpg)
08/01/2014 Critical Software
Model Checking Implementation
When applying recursively Shannon decomposition on all variables, we obtain a tree where leaves are either 1 or 0.
BDD are:
A concise representation of the Shannon tree
no useless node (if x then g else g g)
Share common sub graphs
![Page 119: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/119.jpg)
08/01/2014 Critical Software
Model Checking Implementation (2)
(x1 x0) v (( x1 v y1) (x0 y0))
x0
x1
y1
1
x1
y0 y0
0 1
0
![Page 120: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/120.jpg)
Model Checking Implementation (2)
(x1 y1) v (x0 y0 x1)
0 0 0 0 0 1 0 1 0 0 0 0 0 1 1
x0
x1
y0
y1 y1
y0
y1 y1
x1
y0
y1 y1
y0
y1 y1
0 1
1
08/01/2014 120
![Page 121: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/121.jpg)
Model Checking Implementation (2)
(x1 y1) v (x0 y0 x1)
x0
0 0 0 0 0 1 0 1 0 0 0 0 0 1 1
0
1
1
x1
y0
y1 y1
y0
y1 y1
x1
y0
y1 y1
y0
y1 y1
08/01/2014 121
![Page 122: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/122.jpg)
Model Checking Implementation (2)
(x1 y1) v (x0 y0 x1)
x0 0 1
x1
y0
y1 y1
0 1 0 1
x1
y0
y1 y1
0
0 1 1 1
0
08/01/2014 122
![Page 123: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/123.jpg)
Model Checking Implementation (2)
(x1 y1) v (x0 y0 x1)
x0 0 1
x1
y1
0 1
x1
y0
y1 y1
0 1 1 1
0 0
08/01/2014 123
![Page 124: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/124.jpg)
Model Checking Implementation (2)
x0 0 1
x1
y1
0 1
x1
y0
y1
1 1
0 0
(x1 y1) v (x0 y0 x1)
08/01/2014 124
![Page 125: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/125.jpg)
Model Checking Implementation (2)
x0 0 1
x1
y1
0 1
x1
y0
1
0 0
(x1 y1) v (x0 y0 x1)
08/01/2014 125
![Page 126: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/126.jpg)
Model Checking Implementation (2)
x0 0 1
x1
y1
0 1
x1
y0
(x1 y1) v (x0 y0 x1)
08/01/2014 126
![Page 127: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/127.jpg)
08/01/2014 Critical Software
Model Checking Implementation(3)
Implicit representation of the of states set and of the transition relation of automata with BDD.
BDD allows canonical representation
test of emptiness immediate (bdd =0)
complementarity immediate (1 = 0)
union and intersection not immediate
Pre immediate
![Page 128: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/128.jpg)
08/01/2014 Critical Software
Model Checking Implementation (4)
But BDD efficiency depends on the number of variables
Other method: SAT-Solver
Sat-solvers answer the question: given a propositional formula, is there exist a valuation of the formula variables such that this formula holds
first algorithm (DPLL) exponential (1960)
![Page 129: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/129.jpg)
08/01/2014 Critical Software
Model Checking Implementation (4)
SAT-Solver algorithm:
formula CNF formula set of clauses
heuristics to choose variables
deduction engine:
propagation
specific reduction rule application (unit clause)
Others reduction rules
conflict analysis + learning
![Page 130: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/130.jpg)
08/01/2014 Critical Software
Model Checking Implementation (5)
SAT-Solver usage:
encoding of the paths of length k by propositional formulas
the existence of a path of length k (for a given k) where a temporal property is true can be reduce to the satisfaction of a propositional formula
theorem: given a temporal property and M a model, then M |= n such that M |= n ( n < |S| . 2 ||)
![Page 131: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/131.jpg)
08/01/2014 Critical Software
Bounded Model Checking
SAT-Solver are used in complement of implicit (BDD based) methods.
M |=
verify ¬ on all paths of length k (k bounded)
useful to quickly extract counter examples
![Page 132: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/132.jpg)
Bounded Model Checking
08/01/2014 Critical Software
Given a property p Is there a state reachable in k cycles, which satisfies ¬p ?
p p p p ¬p
s0 s1 s2 Sk-1 sk
……..
![Page 133: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/133.jpg)
Bounded Model Checking
08/01/2014 Critical Software
The reachable states in k steps are captured by: I(s0) T(s0,s1) ……….. T(sk-1, sk) The property p fails in one of the k steps
V V V ¬p(s0) V ¬p(s1) V ¬p(s2) …… V ¬p(sk-1) V ¬p(sk)
The safety property p is valid up to step k iff Ω(k) is unsatisfiable:
Ω(k) = I(s0) T(si, si+1) ¬p(si)
v V
i=0
k-1
v V i=0
k
![Page 134: Critical Real Time Software Verification - Inria](https://reader034.vdocuments.site/reader034/viewer/2022042519/6261cd69df3a4d129d22fa04/html5/thumbnails/134.jpg)
Bounded Model Checking
08/01/2014 Critical Software
K=0
BMC(M,ρ,k)
k≥ CT
SAT
UnSAT K++
M |= ρ
M |=ρ
CT is the completeness threshold