In conclusion, we have successfully demonstrated the feasibility of MTBDD-based proba- bilistic model checking on a broad range of case studies, including examples of real-world randomised protocols. We have been able to perform analysis of extremely large, struc- tured models, some of which are clearly out of the reach of explicit approaches.
This illustrates that established symbolic model checking techniques can be extended to the probabilistic case. In keeping with results from this field, we confirm that the most important heuristic for symbolic approaches is to maximise the exploitation of structure and regularity which derives from high-level model descriptions.
We also draw similar conclusions to other work on structured methods for probabilistic model analysis such as Kronecker-based techniques; namely that, while compact model storage can increase by approximately an order of magnitude the size of model which can be handled, the need to store one or more explicit solution vectors of size proportional to the model being analysed is often the limiting factor. This suggests that an important focus for future work should be the development of techniques and methodologies for abstraction, which concentrate on reducing the size of model which must be analysed, rather than on finding compact storage for large models.
The PRISM Model Checker
This appendix gives a brief overview of PRISM (Probabilistic Symbolic Model Checker), the tool which has been developed to implement the techniques described in this thesis. PRISM supports model checking of PCTL over discrete-time Markov chains (DTMCs) and Markov decision processes (MDPs) and of CSL over continuous-time Markov chains (CTMCs). The algorithms used are those described in Section 3.3.
The tool takes two inputs: a model description and a properties specification. The former is written in the PRISM language, the syntax and semantics of which are given in Appendix B. PRISM parses this description, constructs a model of the appropriate type, either a DTMC, an MDP or a CTMC, and then determines the set of reachable states of this model. The properties specification consists of a number of temporal logic formulas in either PCTL or CSL, depending on the model type. These are parsed and then model checked. The architecture of the PRISM tool is summarised in Figure A.1.
The basic underlying data structures of PRISM are BDDs and MTBDDs. These are used for the construction and storage of all models, as described in Chapter 4 and Ap- pendix C, for reachability, and for the precomputation phases of model checking. For the numerical computation aspect of model checking, PRISM provides three distinct engines. The first is a pure MTBDD implementation, as described in Chapter 5 and Appendix D; the second is explicit, based on sparse matrices; and the third uses the hybrid approach described in Chapter 6.
There are two versions of PRISM available, one based on a graphical user interface and one on a command line interface. Screenshots of each are shown in Figures A.2 and A.3, respectively. Binary and source-code versions of the tool can be obtained from the PRISM web site at www.cs.bham.ac.uk/˜dxp/prism. The site also includes tool documentation, a number of relevant papers and a large amount of information about more than twenty case studies which have been developed with PRISM.
CTMC formulasPCTL formulas DTMC Results (states, probabilities) specification Properties Model Model parser MDP description parser PRISM kernel PCTL
model checker model checkerCSL
Properties engine Hybrid engine Sparse matrix engine CSL MTBDD PRISM
Figure A.2: Screenshot of the PRISM graphical user interface
The PRISM Language
In Section 3.4, we gave an informal presentation of the PRISM language and some simple examples of models described in it. This appendix provides a formal definition. Sec- tion B.1 defines the syntax of the language and Sections B.2, B.3 and B.4 give its se- mantics when describing DTMCs, CTMCs and MDPs, respectively. In these sections, we consider the restricted scenario where neither global variables nor synchronisation be- tween modules are permitted. In Sections B.5 and B.6, we show how the basic syntax and semantics can be modified to handle these extensions. Finally, in Section B.7, we consider the issue of reachability.
B.1
Syntax
In this section, we give the syntax of a model described in the PRISM language. A model is defined as a set of m modules M1, . . . , Mm. Each module Mi is a pair (Vari, Ci)
where Vari is a set of integer-valued, local variables with finite range and Ci is a set of
commands. The variable sets Vari define the local state space of each module which in
turn define the global state space of the whole model. We denote by Var the set of all
local variables in the model, i.e. Var = Sm
i=1Vari. Furthermore, we suppose that each
variable v ∈ Var has an initial value v.
The behaviour of module Mi is defined by the set of commands Ci. Each command
c ∈ Ci takes the form (g, (λ1, u1), . . . , (λnc, unc)), comprising a guard g and a set of pairs
(λj, uj) where λj ∈ IR>0 and uj is an update for each 1 ≤ j ≤ nc. A guard g is a predicate
over the set of all local variables Var . Each update uj of a command in Ci corresponds to
a possible transition of module Mi. This is described in terms of the effect the transition
would have on the variables in Vari. If Vari contains ni local variables v1, . . . , vni, then an
update takes the form (v10 = expr1) ∧ · · · ∧ (v0ni = exprni) where each exprj is an expression
in terms of the variables in Var . We use v0 to denote the new value of a variable v. Note
that, in practice, an update may leave the values of some variables in Vari unchanged.
We allow this information to be omitted from the description of the update.
The constants λj in a command are used to assign probabilities or rates to each of its
updates. These values will determine the probability or rate attached to transitions in the model which correspond to these updates. For a description of a DTMC or an MDP, we require that λj ∈ (0, 1] for 1 ≤ j ≤ nc and that
Pnc
i=1λj = 1. In the case of a CTMC,
each λj can take any value in IR>0.
Example
To illustrate the above ideas more clearly, we relate them to a simple example:
dtmc module M1 v : [1..6] init 1; [] (v = 1) → 1 : (v0 = 2); [] (v > 1) ∧ (v < 6) → 0.5 : (v0= v − 1) + 0.5 : (v0= v + 1); [] (v = 6) → 1 : (v0 = 5); endmodule
This model defines a DTMC and consists of a single module M1. The description of the
module is split into two parts, giving its local variables and commands, respectively. From the first line, we see that M1 has a single local variable v with range {1, . . . , 6} and initial
value 1. Hence Var = Var1 = {v} and v = 1.
The other three lines describe the module’s set of commands C1. In our notation, each
command (g, (λ1, u1), . . . , (λnc, unc)) is written “ [] g → λ1 : u1 + · · · + λnc : unc; ”. For
example, the second command of the three has the guard “ (v > 1) ∧ (v < 6) ” and two updates, “ (v0 = v − 1) ” and “ (v0 = v + 1) ”, each assigned probability 0.5.