This document proposes extending the Promela modeling language and SPIN verification tool to support probabilistic model checking. It discusses adding probability annotations to the non-deterministic "if" clause in Promela's grammar. This would allow specifying the probability of a transition between states in a probabilistic model, either as a constant or variable. The document also describes how SPIN's simulation engine could be modified to select the next state based on the specified transition probabilities rather than randomly, enabling probabilistic model checking of Promela models. The goal is to enhance Promela and SPIN for probabilistic verification without creating a new language or tool.

1. Towards a Probabilistic Extension to
Non-Deterministic Transitions in Model-Based
Checking
Sergey Staroletov
Polzunov Altai State Technical University,
Lenin avenue 46, Barnaul, 656038, Russia
Email: serg soft@mail.ru
June 10, 2019
1 / 27

2. The Goal
The work is considered a problem of modeling probabilistic transitions
in Promela language (SPIN verification tool) and a technique of
enhancing its grammar for the purpose of probabilistic verification. The
extension is based on non-deterministic choice operator in Promela.
Motivation:
Study Probabilistic Model Checking
Study grammar of Promela Modeling language
Study internals of SPIN verifier
Propose a Probability-Driven Programming technique
2 / 27

3. Testing and Formal Verification
Software engineering world has already developed a sufficient
amount of testing technologies and they are applicable well when
creating typical desktop applications or web sites with their
business logic.
For systems that need to work in the critical industries such as
embedded control systems, aircraft management entities,
operating system components, the testing process does not
guarantee sufficient output quality of the product and the
appearance of an error can lead to costly consequences.
It is because the testing is not able to prove the absence of errors
over all possible states and can only show their lack at a particular
test.
3 / 27

4. Model Checking
Formal verification is a way to mathematically prove the model
program with respect to the requirements (assumptions of correct
model behavior). In the Model Checking approach, these requirements
are usually expressed in a timed logic, such as LTL or CTL. The
models for verification are usually written in a special modeling
language, which simplifies ordinary imperative or functional
programming language with some reduction of types, available
memory, standard library but adds some kind of modeling of process
interoperations and non-deterministic transitions. 4 / 27

5. Towards the Probabilistic Model Checking
The Probabilistic Model Checking Problem is stated as follows:
Given a property φ, the Problem consists of checking whether a
stochastic system satisfies φ with a probability greater than or equal to
a certain threshold θ. Herein we consider to LTL properties φ.
5 / 27

6. Towards the Probabilistic Model Checking: An
Example
Refer to the Roundabout Maneuver [Platzer] – is a behavior of two
aircraft to make Collision Avoidance, and it is a subject to cooperation
in air traffic control. The avoidance of collision is achieved by an
agreement on some common angular velocity ωxy and common centre
cxy around which both can fly by the circle safely without coming close
to each other not more than Rsafe. There is the following precondition
to the entry procedure of the Maneuver and the safe property to verify:
isSafe ::= (x1 − y1)2
+ (x2 − y2)2
R2
safe (1)
where x = (x1, x2) is a first planar position, y = (y1, y2) is a second
planar position.
6 / 27

7. Probabilistic Model Based Checking vs Model Based
Checking
Model checking approach can be applied to this problem by specifying
an LTL property:
[ ] (isSafe == 1) (2)
where ”[]” is the ”Globaly” LTL operator and 1 is an alias for true.
Statement (2) in natural language means ”during the execution in all
the states of the program model, the rule (1) will be preserved as true”.
When we move to the Probabilistic Model Checking, we can specify a
PLTL property as
[ ] θ>90% (isSafe == 1) (3)
and here we like to verify that the system satisfies the safe property
with probability of 90% or higher (that means the system will be safe in
90% cases for some reasons when it start working from an initial state
and finish in a final state; or: in 10% cases or less two aircraft can be
closer than Rsafe).
7 / 27

8. Probabilistic languages and models to verify
In the work [David] the SMC (Statistical model checking) approach has
been introduced, and the tool Uppaal has been extended to check
system properties using an extended automaton model. The tool offers
probabilistic simulation and verification by specifying in the user
interface probability distributions that drive the timed behaviors, and
the engine offers computing an estimate of probabilities and
comparison between estimated probabilities without actually
computing them.
In the book [Pfeffer] the author decided to implement classes in Scala
language to allow developers to make complex probabilistic and
statistical programs.
In the paper [Probmela] the authors decided to implement from scratch
a language similar to Promela with some probabilistic additions to
satisfy the probabilistic model checking goals. They used SOS-rules in
the Plotkin style to describe the language formally. For example, this
language offers to write code with PIF (probability IF clause):
PIF [p1] ⇒ P1...[pn] ⇒ Pn FIP (4)
8 / 27

9. SPIN and Promela
SPIN [spinroot.com] is a verifier for models written in the special
Promela input language with respect to given LTL requirements
consisted of model key variables. Some language features:
it is an actor-based (process-oriented) language;
a C-style syntax in some cases;
code in the language looks having the functional style, but the
language does not offer to define functions, it uses inline
declarations quite similar to the macros in C;
allows non-deterministic transitions;
primarily designed to describe protocols interoperations.
9 / 27

10. SPIN and Promela example
int var = 2;
int count = 0;
l t l formula { [ ] ( var >= 0)}
active proctype main ( ) {
do
: : count != 3 −>
{
i f
: : true−> var = var + 1;
: : true−> var = var − 1;
f i
count = count + 1;
}
: : else −>
break
od
}
10 / 27

11. SPIN internal automaton for the example program
11 / 27

12. SPIN internal automaton for the example formula
12 / 27

13. Towards the extensibility of a modeling language
In the current work, we are going to follow this approach, but without
creating a ”yet another” language and a new tool, because now
Promela language and SPIN tool are well-designed and
community-approved, and new language creation instead of extension
of an existing one should be well justified. Of course, it is possible to
declare some inductive rules for a theorem prover for making the
evidence of particular problems like it is done in [Shishkin], but
extending a modeling language to some conventional structures and
rules can involve additional engineers to the formal proof process of
software.
13 / 27

14. Towards the extensibility of a modeling language: IF
clause
The Promela language contains conditions in the form
i f
: : boolean expression1 −> actions1
: : boolean expression2 −> actions2
: : boolean expressionN −> actionsN
f i
It is considered that in order to perform a certain action, it is necessary
that the corresponding logical expression was true.
14 / 27

15. Towards the extensibility of a modeling language:
non-detetministic IF clause
The Promela language contains conditions in the form
Refer to the code snippet in Promela, modeling the Leader Selection
algorithm (Dolev, Klawe & Rodeh):
i f /∗ non−d e t e r m i n i s t i c choice ∗/
: : I n i [ 0 ] == 0 && N >= 1 −> I n i [ 0 ] = I
: : I n i [ 1 ] == 0 && N >= 2 −> I n i [ 1 ] = I
: : I n i [ 2 ] == 0 && N >= 3 −> I n i [ 2 ] = I
: : I n i [ 3 ] == 0 && N >= 4 −> I n i [ 3 ] = I
: : I n i [ 4 ] == 0 && N >= 5 −> I n i [ 4 ] = I
: : I n i [ 5 ] == 0 && N >= 6 −> I n i [ 5 ] = I
f i
with N equal to, for example, 3 and the zero value of Ini, it has four
variants of non-deterministic steps in the Promela model to continue at
this point.
15 / 27

16. Towards the extensibility of a modeling language:
Naive probabilies
For example in this case the probabilities of both actions are identical
(50 and 50 percents):
i f
: : boolean expression1 −> actions1
: : boolean expression2 −> actions2
f i
If we want to increase the likelihood of action1, the following code
i f
: : boolean expression1 −> actions1
: : boolean expression1 −> actions1
: : boolean expression2 −> actions2
f i
does not change the logic of the transition, it changes the likelihood of
the first step in the model.
16 / 27

17. Towards the extensibility of a modeling language: what
do we want
We propose first to extend the Promela grammar with an annotation of
probabilistic transition:
i f
: : [ prob = value %] condition −> actions
. . .
f i
where the ”prob value” (probability value) is an integer of [0..100].
17 / 27

18. Towards the extensibility of a modeling language:
extension to the grammar
SPIN is shipped in the open source code, now available in Github
repository. Promela language parser is implemented using Yacc tools.
A fragment of the grammar is introducing the changes described here
(modified source from spin.y):
options : option
| option options
;
option : SEP
prob
sequence OS
;
prob :/* empty */
| ’[’ PROB ASGN const_expr ’%’ ’]’
;
18 / 27

19. Towards the extensibility of a modeling language:
additional extension to the grammar
Further, we propose to extend this idea, putting the probability of not
only as a constant number but the value of a variable. In this case, the
probability may dynamically be recalculated during program execution
on Promela. So, the following Promela grammar addition is presented:
prob :/* empty */
| ’[’ PROB ASGN const_expr ’%’ ’]’
| ’[’ PROB ASGN expr ’]’
;
where expr – is a grammar rule for the Promela expression.
19 / 27

20. Towards the extensibility of a modeling language: how
to wrap the SPIN simulation engine
In the current SPIN implementation, a next running node in a
non-deterministic transition is selected using seed-based random
generator, see run.c:
/∗ CACM 31(10) , Oct 1988 ∗/
Seed = 16807∗(Seed%127773) − 2836
∗(Seed/127773);
i f (Seed <= 0) Seed += 2147483647;
return Seed ;
So the patch do the following: calculate current likehood of code node
execution and move from the random to probabilities.
20 / 27

21. Towards the extensibility of a modeling language:
advantages
Thus we will be able, for example, simulate and verify various training
and recognition algorithms. A new probability value will be received
from a different process, changed in code based on a given
probabilistic transition or other different cases. So, with simple
grammar additions and some changing to semantic of SPIN code, we
can speak of ”Probability driven programming” in Promela.
21 / 27

22. Towards the extensibility of a modeling language:
channels
To continue this idea, we can propose some ”syntactic sugar” for
probabilistic actions with Promela channels. To simulate some
networking protocols it is required to specify a loss/reliability value for a
channel, that means: with a given probability a channel lose/guarantee
some messages and protocols should correctly handle this.
22 / 27

23. Towards the extensibility of a modeling language: our
toy simulation language
mtype = {s1 , s2 , s3 };
int count = 0;
/∗ now define a normal chan ∗/
chan a = [ 1 ] of { short };
/∗ now define a chan with 30% loss value ∗/
chan [ loss = 30%] b = [ 1 ] of { short };
/∗ now define a chan with 70% r e l y
value ( or 30% loss ) ∗/
chan [ r e l y = 70%] c = [ 1 ] of { short };
int pp = 70;
23 / 27

24. Towards the extensibility of a modeling language: our
toy simulation language
active proctype main ( ) {
mtype state = s1 ;
count = pp − 10;
/∗ send to a normal chan ∗/
a ! 1
/∗ send to a 30% loss chan ∗/
b ! count ;
/∗ send to a chan with re−defined 10%
loss ∗/
c ! [ loss = 10%] 3;
/∗ send to a chan with 70% r e l i a b i l i t y ∗/
c ! 2;
/∗ send to a chan with re−defined 99%
r e l i a b i l i t y ∗/
c ! [ r e l y = 99%] 4;
/∗ send to a chan with re−defined loss 24 / 27

25. Towards the extensibility of a modeling language: our
toy simulation language
b ! [ loss = count ] 1;
i f
: : true −> state = s2 ;
/∗ 10% prob t r a n s i t i o n ∗/
: : [ prob = 10%] true −> state = s3 ;
/∗ dynamic prob t r a n s i t i o n ∗/
: : [ prob = pp ] true −> state = s3 ;
/∗ f o r the others prob w i l l be ∗/
calculated as 100% − a l l
specified probs ∗/
: : true −> state = s2 ;
: : true −> state = s3 ;
f i
printf ( ” state = %d ” , state ) ;
}
25 / 27

26. Status and Results
Currently, we implemented the extension to the grammar with a
goal to extend the semantics and understanding of the SPIN
internal logic.
The advanced program simulation in Promela as well as
verification code generation are in progress.
Adding probabilities to the transitions and channels with losses
will allow SPIN users to model some complex interactions and
probabilistic algorithms. We are making some additions on
internal nodes (at the parsing time), and some – on dynamic
values calculation after SPIN processes are scheduled.
This approach also allows verification engineers to extend the
class of verifiable systems with the SPIN verifier.
26 / 27

27. Learn more about Model Checking
27 / 27