1. Victor Khomenko Newcastle University
A Usable Reachability Analyser
Victor Khomenko
Newcastle University

2. Reachability analysis
Problem statement: check if there is a reachable state s satisfying a given predicate R(s)
Usually R specifies some undesirable situation, e.g. a deadlock, violation of mutual exclusion, violation of an assertion
If the system is a safe Petri net then R is a Boolean expression over the elementary predicates corresponding to the places, e.g.:
p1 p2 + p1 p3 + p2 p3

3. How to specify properties?
Manual specification is tedious and error-prone
Automatic generation of formulae can be done only for a fixed set of standard properties; hence custom properties cannot be checked, even if they are just minor variations of standard properties
Users are often forced to implement generators for their custom properties (simple in theory, hard work in practice)

4. Example: Dining PhilosophersT1 P3 P5 P2 T2 P1 T5 P6 T4 P4 P7 P8 P9
P11
P10
P13
P14
P12 T9 T7
T10 T6 T8 T3
T11
P15
T12
P16
p1 (p2 + p7)(p3 + p8)(p4 + p5) p6 p9 (p7 + p10)(p8 + p9)(p12 + p13) p14
p1 p9
(p15 + p16)

5. How to specify properties?
In this case can reduce to standard deadlock checking:
In general, such reductions may be difficult or not possible
It is a bad idea to make
the user to modify the
model or invent tricks
P15
P16

6. Proposed solution
Language Reach for specifying reachability properties:
custom properties can be easily and concisely specified
the model does not have to be modified in any way, in particular the model does not have to be translated into an input language of some model checker
almost any reachability analyser can be used as the back-end

7. Example: deadlock property
Mathematical definition:
Reach specification:
forall t in TRANSITIONS {
exists p in pre t { ~$p } }
or simply
forall t in TRANSITIONS { }
taking care of proper termination:
forall t in TRANSITIONS { } & (~$P"p15" | ~$P"p16")

8. Reachability analysis flow

9. Case studies: asynchronous circuits
Asynchronous circuits are circuits without clocks
Very attractive: the traditional
synchronous (clocked) designs
lack flexibility to cope with
contemporary microelectronics
challenges
Notoriously difficult to design correctly
Often specified using Signal Transition Graphs (STGs) – a class of labelled Petri nets

10. Example: VME Bus Controller
Device
VME Bus
Controller
lds
ldtack d
Data Transceiver
Bus
dsr
dtack
lds- d-
ldtack-
ldtack+
dsr-
dtack+ d+
dtack-
dsr+
lds+

11. Case studies: Consistency
In each possible execution, the transitions representing the rising and falling edges of each signal must be correctly alternated between, always starting from the same edge (either rising or falling)
exists s in SIGNALS {
let Ts = tran s {
$s & exists t in Ts s.t. is_plus t } |
~$s & exists t in Ts s.t. is_minus t } }

12. Case studies: Output persistency
A local signal (output or internal) should not be disabled by any other transition x+ a+ x+ a+ x+ a+
OP violation ok ok y+ x+ b+ a+ x+ a+
OP violation ok ok

13. Case studies: Output persistency
exists t1 in TRANSITIONS s.t. sig(t1) in LOCAL {
@t1 &
exists t2 in TRANSITIONS s.t. sig(t2)!=sig(t1) &
|pre(t1)*(pre(t2)\post(t2))|!=0 {
@t2 &
forall t3 in tran(sig(t1))\{t1} s.t.
|pre(t3)*(pre(t2)\post(t2))|=0 {
exists p in pre(t3)\post(t2) { ~$p } }
Intuitively, we are looking for a marking where t1 is disabled by t2, and after t2 fires, no transition with the same signal as t1 is enabled

14. Case studies: CSC
dtack-
dsr+
00100
ldtack-
00000
10000
lds-
01100
01000
11000
lds+
ldtack+ d+
dtack+
dsr- d-
01110
01010
11010
01111
11111
11011
10010
M’’ M’
States with the same encoding should enable the same local signals

15. Case studies: CSC
Generalised reachability property: check if there are reachable states s1,…,sk satisfying a given predicate R(s1,…,sk)
forall s in SIGNALS { $s <-> $$s }
&
exists s in LOCAL { }

16. Case studies: arbiters
g1+
r1+
rn+
r1-
g1-
gn+
rn-
gn- …
Traditional protocol
Arbiter r1 … rn g1 gn
g1+
r1+
rn+
r1-
g1-
gn+
rn-
gn- …
Early protocol

17. Case studies: deadlock in arbiters
The rising request transitions are not weakly fair, i.e. any state (except the initial one) enabling only such transitions is a deadlock
The initial state has to be treated in a special way
A minor variation of a standard property that renders standard deadlock checkers almost useless
let requests = {T"ra+", T"rb+", T"rc+"} {
forall t in TRANSITIONS\requests { } }
&
exists p in PLACES { $p ^ is_init p }
let requests = TT "r[a-z]\\++\\(/[0-9]\\+\\)\\?" {

18. Case studies: mutual exclusion
Mutual exclusion of signals rather than places
let a = $S"ga", b = $S"gb", c = $S"gc" {
a & b | b & c | a & c }
Alternatively:
threshold[2]($S"ga", $S"gb", $S"gc")
With a regular expression:
let grants = SS "g[a-z]\\+" {
threshold[2] g in grants { $g }

19. Case studies: mutual exclusion
Traditional mutual exclusion does not hold for the early protocol
threshold[2]($S"ra" & $S"ga",
$S"rb" & $S"gb", $S"rc"&$S"gc")
With a regular expression:
let req = SS "r[a-z]\\+" {
threshold[2] r in req {
$r & $S("g" + (name r)[1..]) }

20. Conclusion
A solution to the problem of generating formulae expressing custom reachability properties has been proposed
The usefulness of this method is demonstrated on several case studies
The developed MPSAT tool is currently being used as the reachability analysis engine within the DesiJ and Workcraft tools

21. Future work
Extension to other formalisms is straightforward (general Petri nets, coloured Petri nets, products of automata, digital circuits, etc.)
Extension to other property classes is straightforward (e.g. add LTL or CTL modalities)
Share common subterms during expansion
Add more powerful constructs, such as recursive definitions and rewriting rules