Event Order Abstraction for Parametric RealTime System Verification

1
Event Order Abstraction for Parametric Real-Time
System Verification

• Shinya Umeno
• Nancy Lynchs Group
• CSAIL, MIT

2
Train-Gate Toy Example
Request

• The gate must be closed when the train passes the
  crossing.

• The train makes a close request to the gate
  module.

3
Train-Gate Toy Example
Request

• The gate must be closed when the train passes the
  crossing.

• The train makes a close request to the gate
  module.

Timing parameters
p,P Time that takes for the train to reach
the crossing.
r,R Time that a request is made.
d, ? Delay time from a request arrival to a
gate close.
4
A Bad Scenario of Train-Gate
Request
0. The system starts executing.
1. The train sends a request (Request event).
2. The train passes the crossing (Pass event)
before the gate becomes closed.
5
A Bad Scenario of Train-Gate
Request
0. The system starts executing.
1. The train sends a request (Request event).
2. The train passes the crossing (Pass event)
before the gate becomes closed.
- Request - Pass - Close
6
A Bad Scenario of Train-Gate
Request
0. The system starts executing.
1. The train sends a request (Request event).
2. The train passes the crossing (Pass event)
before the gate becomes closed.
- Request - Pass - Close
R
?
p
7
A Bad Scenario of Train-Gate
Request
0. The system starts executing.
1. The train sends a request (Request event).
2. The train passes the crossing (Pass event)
before the gate becomes closed.
- Request - Pass - Close
R
?
Required constraint R ? lt p
p
8
Event-Order-Critical Timed Systems
Correct ordering of events is needed for the
correctness of the system.
Event ordering is maintained by timing
constraints on the system behavior.
Example Fischer mutual exclusion
i
seti
testi
time
j
setj
checkj
testj
9
Event-Order-Critical Timed Systems
Correct ordering of events is needed for the
correctness of the system.
Event ordering is maintained by timing
constraints on the system behavior.
Example Fischer mutual exclusion
U
i
seti
testi
time
j
setj
checkj
testj
L
10
Event-Order-Critical Timed Systems
Correct ordering of events is needed for the
correctness of the system.
Event ordering is maintained by timing
constraints on the system behavior.
Example Fischer mutual exclusion
U
i
seti
testi
time
j
setj
checkj
testj
L
Required Constraint L gt U
11
Event-Order-Critical Timed Systems
Correct ordering of events is needed for the
correctness of the system.
Event ordering is maintained by timing
constraints on the system behavior.
Example Fischer mutual exclusion
U
i
seti
testi
time
j
setj
checkj
testj
The constraint is derived by analyzing just a
subsequence of an execution.
L
Required Constraint L gt U
12
Typical Verification Approach
Only a subset of all possible parameter
combinations satisfy the correctness.
Time-parametric verification
1. Treat timing parameters symbolically as
uninterpreted constants.
2. Find a sufficient set of parameter constraints.
3. Prove/check the model under the constraints.
13
Finding Parameter Constraints
1. Find out bad scenarios that occur when the
parameters are badly tuned.
2. Depict the bad scenario by using a process
communication diagram.
3. Manually derive timing constraints to exclude
the depicted bad scenario.
14
Finding Parameter Constraints
1. Find out bad scenarios that occur when the
parameters are badly tuned.
2. Depict the bad scenario by using a process
communication diagram.
3. Manually derive timing constraints to exclude
the depicted bad scenario.
If the user uses inductive reasoning approach
4. Come up with inductive properties, and
prove/check the properties.
Needs deep human insights and training.
15
Timing Parameter Synthesis
Parameter constraints are not given, but the user
tries to derive them systematically using a
mechanical support.
Fully automatic timing parameter synthesis for
parametric timed automata is undecidable (Alur
et al. 1993).
16
Automatic Parameter Synthesis
Some of the existing timed model-chekers (HyTech,
RED, Trex, and LPMC) allow automatic timing
constraint synthesis.
These model-checkers do not scale to a system
with a large number of parameters.
They do not allow unbounded number of repetitions
of events with timing constraints.
Essential for (modified) Train-Gate, Biphase Mark
Protocol, and certain versions of Fischer Mutex
(we will see why later).
17
Event Order Abstraction (Our Approach)
Verification task is split into two parts
1. Safety property verification of the system
given that bad event orders do not occur.
Represents a subsequence of an entire execution.
2. Automatic derivation of timing parameter
constraints that exclude bad event orders.
Model-checker
Inductive approach
EOA
Automation
Versatility
18
Overview of EOA
Identify bad event orders
Model-check the discretized model under an event
ordering assumption.
Counter-example
Successful
Automatically derive timing constraints
19
Related Work

• Yoneda, Kitai, and Myers, Automatic Derivation of
  Timing Constraints by Failure Analysis. 2002.

• Negulescu and Peeters. Verification of
  speed-dependences in single-rail handshake
  circuits. 1998.

• Frehse, Jha, and Krogh. A counterexample-guided
  approach to parameter synthesis for linear hybrid
  automata. 2008.

No treatment for repetitive events.
20
Organization of The Talk
Time-Interval Automata
- Train-Gate Example
Specifying Event Orders
Deriving Timing Constraints
Case Studies
- Train-Gate Example
- Biphase Mark Protocol
- IEEE 1394 Root Contention Protocol
- Fischer Mutual Exclusion
21
Time-Interval Automata
A time-interval automaton (A,b) is an I/O
automaton A with bound mapping b.
b (p, P) L , U
An action of A
A set of actions that follow p
A lower bound L and an upper bound U for the
duration between p and any action in P
22
Timed Execution
Timed execution of a TIA
s0 (a1,t1) s1 (a2,t2) s2 (a3,t3) s3
si i-th state
ai i-th action (event)
ti Time of occurrence of the i-th action
that satisfies upper and lower bound conditions
See the paper for the definitions.
Example (push(M1),2) M1 (push(M2),4) M1
M2 (pop(),6) M1
23
Modified Train-Gate Toy Example
Request
train_ requested
The gate module cannot immediately know a request
from the train. Instead, it checks the variable
train_requested in a busy loop.
The train repeatedly passes the crossing.
The gate becomes open again after closed.
24
Train-Gate Example (Code)
25
Train-Gate Example (Code)
26
Organization of The Talk
Time-Interval Automata
- Train-Gate Example
Specifying Event Orders
Deriving Timing Constraints
Case Studies
- Train-Gate Example
- Biphase Mark Protocol
- Fischer Mutual Exclusion
27
Overview of Our Approach
Identify bad event orders
Model-check the discretized model under an event
ordering assumption.
Counter-example
Successful
Automatically derive timing constraints
28
Event Order (Simple Case)
Bad event order examples
- Check(false) Request - Check(true) - Pass
Execution prefix
Pass Open -
Check(false) Request - Check(true) - Pass
Execution fragment
These event orders specify the order of
consecutive actions in an automaton execution.
The bottom symbol represents the event that the
automaton starts executing.
29
Event Order with Dont-Care Events
- Pass
Possibly unbounded number of Check(false) can
precede Pass
30
Event Order with Dont-Care Events
- Pass
Possibly unbounded number of Check(false) can
precede Pass
- (Check(false)) - Pass
31
Event Order with Dont-Care Events
- Pass
Possibly unbounded number of Check(false) can
precede Pass
- (Check(false)) - Pass
- Pass insert Check(false) to 0,1
32
Why Are Repetitions with Timing Constraints
Troublesome?
Require R lt p
- (Check(false)) - Pass
Timed execution
s0 (Check(false), ?) s1 (Check(false), 2?) s2
(Check(false), 3?) s3
33
Why Are Repetitions with Timing Constraints
Troublesome?
Require R lt p
- (Check(false)) - Pass
Timed execution
s0 (Check(false), ?) s1 (Check(false), 2?) s2
(Check(false), 3?) s3
All of sis are different! Reachable state (fixed
point) computation will not terminate.
34
Why Are Repetitions with Timing Constraints
Troublesome?
Require R lt p
- (Check(false)) - Pass
Timed execution
s0 (Check(false), ?) s1 (Check(false), 2?) s2
(Check(false), 3?) s3
All of sis are different! Reachable state (fixed
point) computation will not terminate.
Untimed execution
s0 Check(false) s1 Check(false) s2 Check(false)
s3
All of sis are same (Check(false) is just a
stuttering transition).
35
Overview of Our Approach
Identify bad event orders
Model-check the discretized model under an event
ordering assumption.
Counter-example
Successful
Automatically derive timing constraints
36
Identifying Bad Event Orders
The user first identifies a candidate set of bad
event orders (which may be empty).
He/she constructs monitors for the orders (for
model-checking) a monitor raise a flag if a bad
event order is detected in a system execution.
He/she then model-checks Untimed Model
not Monitor.raiseFlag
not SafetyPropertyViolated.
More in the paper.
37
Organization of The Talk
Time-Interval Automata
- Train-Gate Example
Specifying Event Orders
Deriving Timing Constraints
Case Studies
- Train-Gate Example
- Biphase Mark Protocol
- Fischer Mutual Exclusion
38
Overview of Our Approach
Identify bad event orders
Model-check the discretized model under an event
ordering assumption.
Counter-example
Successful
Automatically derive timing constraints
39
Steps for Deriving Timing Constraints
1. Enumerate upper and lower bounds between a
pair of events that are immediately derivable
from the time bound structure.
No transition structure required.
2. Combine individual upper bounds and lower
bounds.
3. Derive constraints using a matching pair of
combined upper bounds and combined lower bounds.
40
Enumerating Upper and Lower Bounds
41
Covering UB Set and Distributed LB Set
Event Order
E1 - E2 - E3 - E4 - E5 - E6 - E7
A covering UB set for 2,6
Union of intervals cover the entire 2,6.
A distributed LB set for 2,6
All intervals inside 2,6, and no overlap.
42
Covering UB Set and Distributed LB Set
Event Order
E1 - E2 - E3 - E4 - E5 - E6 - E7
A covering UB set for 2,6
Union of intervals cover the entire 2,6.
A distributed LB set for 2,6
All intervals inside 2,6, and no overlap.
43
Key Theorem
A time-interval automaton (A,b) exhibits no
execution that matches an event order E if
There is an event interval I in E such that
1. Upper bound set U covers I,
2. Lower bound set L is distributed in I, and
3. S u in U lt S l in L.
44
Timing Derivation Example
Check(false)
Request
Check(true)
Pass
R
(
R
,0,1)
R
(
R
,0,2)
D
D
(
,0,1)
D
D
(
,1,2)
D
Upper Bounds
D
(
,1,3)
T
(
T
,3,4)
P
(
P
,0,1)
P
(
P
,0,2)
P
(
P
,0,3)
P
(
P
,0,4)
d
d
(
,0,1)
r
(
r
,0,2)
d
d
(
,1,3)
Lower Bounds
d
d
(
,0,3)
p
(
p
,0,4)
45
Timing Derivation Example
Check(false)
Request
Check(true)
Pass
R
(
R
,0,1)
Derived Constraint
R
(
R
,0,2)
D
D
(
,0,1)
D
D
(
,1,2)
D
Upper Bounds
D
(
,1,3)
R T
T
(
T
,3,4)
P
(
P
,0,1)
lt
P
(
P
,0,2)
P
(
P
,0,3)
p
P
(
P
,0,4)
d
d
(
,0,1)
r
(
r
,0,2)
d
d
(
,1,3)
Lower Bounds
d
d
(
,0,3)
p
(
p
,0,4)
46
Form of Timing Constraints
A constraint from one event order forms a
disjunction of linear inequalities
Lj
j?J
The user typically needs to exclude multiple bad
event orders.
The final form of the constraint a conjunction
of disjunctions of linear inequalities --
similar to conjunctive normal form.
Lij
i?I
j?Ji
47
Implementation
METEORS Version 0.2 (implemented in Python)
(MEchanized Timing/Event-ORder Synthesizer)

• Searches over covering UB sets and distributed LB
  sets.

• Derives constraints from all matching pair of a
  covering UB set and a distributed LB set.

• Simplifies constraints using simple linear
  arithmetic logics.

More in a tech report version.

• Manages constraints for multiple event orders and
  does overall simplifications.

48
Organization of The Talk
Time-Interval Automata
- Train-Gate Example
Specifying Event Orders
Deriving Timing Constraints
Case Studies
- Train-Gate Example
- Biphase Mark Protocol
- Fischer Mutual Exclusion
49
Train-Gate Example Bad Event Orders
We identified 10 bad event orders (each untimed
model-checking took less than one second).
Three groups.
50
Train-Gate Example Derived Constraints
Correctness is guaranteed when all of the
following three conditions are satisfied
1. p gt R T D
Originally From A6
2. r t c gt P or d t c gt P
Originally From B1
Originally From C1
3. r gt C
51
Summary of Other Three Case Studies
Biphase Mark Protocol
Derived three constraints equivalent to other
case studies with different approaches.
IEEE 1394 Root Contention Protocol
One bad scenarios created 32 bad event orders due
to interleaving processes.
Fischer Mutual Exclusion Protocol
Untimed model-checking successfully completed in
40 seconds with 5 processes.
52
Summary of Contributions
We

• Proposed a new approach, event order abstraction,
  for machine-assisted timing parameter synthesis.

• Presented a scheme that automatically derives
  timing constraints needed to exclude bad event
  orders.

• Demonstrated applicability of the approach by
  four case studies.

53
Future Work

• Larger case studies

Timed distributed algorithms.

• Enhancing automation in

• Event order monitor construction

• Bad event order identification.

• Extending the event order language to treat
  partial orders.

54
Questions?