Formal Verification of Probabilistic Systems in ASMETA

Universit`a degli Studi di Milano
Department of Computer Science
Master degree in Computer Security
Formal Veriﬁcation of
Probabilistic Systems in ASMETA
Candidate:
Riccardo Melioli – 901664
Supervisor:
Prof. Elvinia Riccobene
Co-supervisor:
Dr. Paolo Arcaini
Academic year 2017–2018

Acknowledgements
I would like to thank my Supervisor Professor Elvinia Riccobene for proposing
this thesis, for the continuous availability and the help that she gave me during the
whole internship and the writing of this thesis.
I would like to thank my Co-supervisor the Doctor Paolo Arcaini, with whom I
worked closely during my stay in Japan.
I would like to thank Professor Ichiro Hasuo for hosting me at the ERATO
MMSD project of the NII in Japan.
Finally I would like to thank my family for the support they gave me.
R. M.
iii

Contents
Introduzione 1
Introduction 4
I Background 7
1 Abstract State Machines and ASMETA 9
1.1 Abstract State Machines (ASMs) . . . . . . . . . . . . . . . . . . . . 9
1.1.1 States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1.2 Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.1.2.1 Transition rules . . . . . . . . . . . . . . . . . . . . 11
1.1.3 ASM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.1.4 Multi-agent ASMs . . . . . . . . . . . . . . . . . . . . . . . . 14
1.1.5 Functions classification . . . . . . . . . . . . . . . . . . . . . . 14
1.2 ASMETA: a framework for ASMs . . . . . . . . . . . . . . . . . . . . 15
2 PRISM: Probabilistic Model Checker 19
2.1 Probabilistic Models . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1.1 Discrete-Time Markov Chains (DTMC) . . . . . . . . . . . . 20
2.1.2 Markov-decision process (MDP) . . . . . . . . . . . . . . . . 21
2.2 Probabilistic Computation Tree Logic (PCTL) . . . . . . . . . . . . 22
2.3 PRISM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3.1 Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3.2 Properties specification . . . . . . . . . . . . . . . . . . . . . 27
II Extending ASMETA with the probabilistic model checking 31
3 AsmetaF: a flattener for the ASMETA framework 33
3.1 Flattener rule removers and terms simplifier . . . . . . . . . . . . . . 35
3.2 Validation of the approach . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3 Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4 AsmetaPRISM: Probabilistic Model Checking in ASMETA 45
4.1 AsmetaPRISM in the ASMETA framework . . . . . . . . . . . . . . 45
4.2 Mapping ASMETA models to PRISM models . . . . . . . . . . . . . 46
4.2.1 Domains and Locations . . . . . . . . . . . . . . . . . . . . . 47
v

vi CONTENTS
4.2.2 Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.3 Handling non-deterministic ASMETA model . . . . . . . . . . . . . . 52
4.3.1 Internal non-determinism: Choose Rule . . . . . . . . . . . . 52
4.3.2 Modeling the environment . . . . . . . . . . . . . . . . . . . . 54
4.3.3 Selecting the PRISM model kind . . . . . . . . . . . . . . . . 57
4.4 Temporal Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.4.1 Syntax adjustment for CTL properties . . . . . . . . . . . . . 59
4.4.2 Adding PCTL properties . . . . . . . . . . . . . . . . . . . . 60
4.5 Validation of the approach . . . . . . . . . . . . . . . . . . . . . . . . 61
4.6 Tool Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
III Case Studies 63
5 Veriﬁcation of probabilistic systems using AsmetaPRISM 65
5.1 PIN cracking schemes . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.1.1 Problem presentation . . . . . . . . . . . . . . . . . . . . . . 65
5.1.2 Applying AsmetaF and AsmetaPRISM . . . . . . . . . . . . 68
5.1.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.2 Probabilistic Fair Exchange . . . . . . . . . . . . . . . . . . . . . . . 69
5.2.1 Problem presentation . . . . . . . . . . . . . . . . . . . . . . 69
5.2.2 Applying AsmetaF and AsmetaPRISM . . . . . . . . . . . . 70
5.2.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Conclusion and future development 73
A ASMETA and PRISM models 77
Bibliography 85

List of Figures
1 Processo dai requisiti di sistema alla verifica di proprietà probabilistiche 3
2 Process from system modeling to probabilistic properties verification 6
1.1 Classification of ASM functions . . . . . . . . . . . . . . . . . . . . . 14
1.2 The ASMETA toolset . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1 ASMETA toolset - validation and verification . . . . . . . . . . . . . 46
4.2 Rule relations in the normal form . . . . . . . . . . . . . . . . . . . . 46
4.3 Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.4 Non-deterministic environment . . . . . . . . . . . . . . . . . . . . . 56
4.5 Probabilistic environment with uniform distribution . . . . . . . . . 57
4.6 Probabilistic environment with custom distribution . . . . . . . . . . 58
4.7 Example for temporal properties verification . . . . . . . . . . . . . . 59
5.1 ATM Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.2 A fragment of a tree produced by AnaBlock . . . . . . . . . . . . . . 68
5.3 Chart of table 5.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.4 Probability of the protocol termination, for different N values . . . . 73
vii

Introduzione
I sistemi informatici sono in costante crescita nella vita di tutti i giorni, in
particolare in scenari safety-critical (come quello automobilistico, avionico, medico,
ecc.) nei quali l’affidabilità e la correttezza sono requisiti principali che vanno
garantiti.
La complessità dei sistemi informatici è in crescente aumento, e recentemente,
nello scenario dei moderni sistemi, sono emersi i Cyber-Physical System (CPS), ossia
sistemi in cui la componente software interagisce in modo continuo con il sistema
fisico in cui il software opera. Rispetto alla dinamica di sistemi classici, la compo-
nente fisica di un CPS introduce nuovi fattori da considerare nel comportamento
del sistema, in particolare comportamenti probabilistici. Nei CPS, infatti, questi
comportamenti si presentano quando vi sono aspetti non prevedibili, dovuti ad
esempio a comportamenti stocastici di componenti fisici e comportamenti randomici
dovuti all’interazione umana o ad aspetti di sicurezza.
Nell’ ambito dei cosiddetti sistemi safety-critical “classici”, ossia sistemi che non
espongono comportamenti stocastici o probabilistici, i metodi formali sono stati
utilizzati come approccio rigoroso per lo sviluppo e per l’analisi. I metodi formali
forniscono notazioni precise e non ambigue che permettono di modellare i requisiti
del sistema, e sono supportati da tecniche di verifica per provare proprietà qualitative.
Queste proprietà (ad esempio, safety, liveness, etc.) sono relative ai comportamenti
funzionali del sistema e possono essere verificate mediante l’utilizzo di model checker
classici, come ad esempio NuSMV.
Per analizzare tutti gli aspetti caratteristici dei CPS, le proprietà qualitative non
sono abbastanza, dal momento che non sono in grado di formalizzare comportamenti
probabilistici del sistema. Per riuscire in ciò, è necessario poter esprimere proprietà
quantitative (connesse alla probabilità ed al tempo), che sono relative principalmente
ai comportamenti probabilistici. La verifica di tali proprietà è supportata dai model
checker probabilistici (come ad esempio PRISM).
Per modellare e verificare i CPS, in letteratura sono stati proposti diversi metodi;
sebbene alcuni di questi siano stati applicati con successo in molti ambiti, essi presen-
tano alcuni svantaggi, tra cui la difficoltà di utilizzo, l’uso di notazioni matematiche
complesse, etc.
Per ovviare a questi svantaggi, in questo lavoro di tesi, la proposta è di modellare
i sistemi CPS mediante il metodo formale delle Abstract State Machines (ASMs),
che è un metodo dell’ingegneria dei sistemi che consente di applicare le principali
tecniche di design ed analisi tipicamente utilizzate durante il ciclo di vita del software.
Durante il processo di sviluppo di un sistema, le ASMs guidano in modo rigoroso
l’utente dall’analisi dei requisiti fino alla scrittura del codice.
1

2 INTRODUZIONE
I vantaggi di usare le ASMs come metodo di modellazione sono diversi. In
particolare: esse permettono di operare a diversi livelli di astrazione; permettono
di gestire la complessità di sistemi di tutte le dimensioni; supportano il concetto
di computazione distribuita; sebbene abbiano una precisa definizione matematica,
le ASM non richiedono particolari competenze matematiche per essere utilizzare;
i modelli sono eseguibili, quindi le ASM sono adatte per validare un sistema ad
alto livello di astrazione; esiste un insieme di tool (ASMETA) per la modellazione,
validazione e verifica. Tale metodo, però, non fornisce alcun supporto per la model-
lazione e verifica di comportamenti probabilistici e scopo di questo lavoro di tesi è
fornire questo supporto.
Per supportare la verifica di proprietà quantitative su modelli ASM, si è deciso di
potenziare ASMETA, essendo questo tra i principali tool per il metodo formale delle
ASM. ASMETA è un framework che consiste in un insieme di strumenti sviluppati
sotto Eclipse per la scrittura, la verifica sintattica, la simulazione e la verifica di
proprietà (qualitative) mediante model checking classico, di modelli ASM scritti
nel linguaggio AsmetaL. All’interno di ASMETA la prova di proprietà è effettuata
tramite model checking, e tale automatismo di è voluto garantire anche per la verifica
di proprietà quantitative.
In generale, il model checking è una tecnica di verifica automatica di proprietà:
dato il modello di un sistema (hardware o software) scritto in un formalismo op-
portuno (strutture di Kripke, catene di markov, ...), un model checker permette
di verificare che il modello soddisfi determinate proprietà espresse in una logica
temporale (Computation tree logic (CTL), Linear temporal logic (LTL), Probabilistic
Computation tree logic (PCTL)).
Per estendere le ASMs con il concetto di probabilità, si è cercata una corrispon-
denza con le catene di Markov, formalismo che permette la modellazione di sistemi
aventi comportamenti probabilistici. Uno dei principali tool che si basano sulle catene
di Markov è PRISM, un model checker probabilistico che permette la modellazione
e l’analisi formale di sistemi che espongono un comportamento non-deterministico o
probabilistico; in particolare PRISM permette la verifica di proprietà quantitative.
Lo scopo del lavoro di tesi è stato quello di cercare di sfruttare le potenzialità del
model checker probabilistico PRISM per effettuare verifiche di proprietà quantitative
con la logica temporale PCTL su modelli AsmetaL.
Nella fase di progettazione di questa mappatura abbiamo riscontrato che lo
sviluppo di certe procedure sarebbe stato simile a quello inerente altri progetti di
mappatura sviluppati in passato per ASMETA. Per questa ragione, si è pensato di
suddividere il problema di mappare modelli ASM in modelli PRISM in due parti:
definire una forma normale di un modello ASM, ed utilizzare questa forma normale
per mappare una ASM in un modello PRISM.
Per risolvere i due problemi descritti sopra, abbiamo sviluppato due tool, AsmetaF
e AsmetaPRISM, che permettono rispettivamente di tradurre un modello ASM nella
sua "forma normale", e di tradurre un modello nella forma normale ad un modello
PRISM. Il progettista può limitarsi a descrivere il sistema con il modello ASMETA,
specificando con un meccanismo particolare le proprietà PCTL che vuole verificare;
in un secondo momento, tramite il tool AsmetaF, il modello originale è portato in
forma normale e poi tramite AsmetaPRISM in PRISM. Attraverso l’esecuzione del
modello PRISM ottenuto si ottiene la verifica di proprietà specificate.

L’unica conoscenza che il progettista deve acquisire per poter fare model checking
probabilistico su modelli ASMETA è la semantica degli operatori PTCL; la sintassi
PRISM può essere ignorata.
La seguente immagine illustra le fasi del processo di mappatura dai requisiti di
sistema fino alla verifica di proprietà probabilistiche.
Figure 1: Processo dai requisiti di sistema alla verifica di proprietà probabilistiche
Parte della presente tesi è stata sviluppata presso il National Institute of Informat-
ics di Tokyo, Giappone, nel contesto del progetto ERATO MMSD (Metamathematics
for Systems Design) che prevede l’applicazione dei metodi formali alla modellazione
e verifica di CPS. La collaborazione è stata fondamentale per gli aspetti riguardanti
lo sviluppo di AsmetaPRISM, in particolare, lo studio e progettazione della cor-
rispondenza dei modelli teorici (ASMs e Markov Decision Process (MDP)).
La tesi è composta da tre parti: nella prima parte si forniscono le conoscenze degli
ambienti i tools sviluppati interagiscono; nella seconda parte verranno mostrati i tools
svilupparti; nell’ultima parte vi sarà l’applicazione dei tools a due casi di studio. I
capitoli della tesi sono: Nel capitolo 1 sono descritti i concetti teorici delle ASMs e nel
capitolo 2 quelli di PRISM, per fornire l’adeguato background teorico che permetta
al lettore di comprendere in pieno gli aspetti trattati nei capitoli seguenti riguardanti
l’utilizzo ed il potenziamento di tali concetti. Nel capitolo 3 si definisce la forma
normale di un modello ASM, viene descritto il processo per trasformare una ASM
nella sua forma normale equivalente, vengono discussi i vantaggi che essa favorisce e
viene presentato il tool AsmetaF che è stato sviluppato per ottenerla. Nel capitolo
4 sono descritti l’architettura ed il funzionamento del tool principale sviluppato
come parte di questa tesi, ossia AsmetaPRISM. Partendo dalla forma normale di
un modello ottenuta tramite AsmetaF, AsmetaPRISM mappa un modello scritto in
AsmetaL in un modello PRISM, per poi sfruttare le capacità di verifica probabilistica
del model checker probabilistico. Nel capitolo 5 presentiamo l’applicazione dei tool
sviluppati a diversi casi di studio di diversa complessità, mostrando il modello
AsmetaL, la forma normale ottenuta e infine la traduzione in PRISM; e per ogni
modello analizzato sono provate proprietà quantitative. Nell’appendice sono raccolti
i codici degli esempi presenti nel capitolo 5.
Il contributo presentato nel cap 3 è stato pubblicato nel seguente articolo: P.
Arcaini, R. Melioli, E. Riccobene AsmetaF: a flattener for the ASMETA framework
in 4th Workshop on Formal Integrated Development Environment (F-IDE 2018),
Oxford, UK, July 14, 2018.
3

4 INTRODUCTION
Introduction
Information Technology (IT) systems are constantly growing in everyday life,
particularly in safety-critical scenarios (such as the automotive, avionics, medical,
etc.) in which reliability and correctness are the main requirements that must be
guaranteed.
The complexity of the information systems is increasing, and recently, in the
scenario of modern systems, the Cyber-Physical System (CPS) emerged as systems
in which the software component interacts continuously with the physical system in
which the software operates. Compared to the dynamics of classical systems, the
physical component of a CPS introduces new aspects to consider in the behavior of
a system, in particular probabilistic behaviors.
In CPS, these behaviors occur when there are unpredictable aspects, for example
due to stochastic behaviors of physical components and random behavior due to
human interaction or to security aspects.
Formal methods are classically used as a rigorous method for safety-critical
systems, providing formal notations suitable for modeling system requirements
and verification techniques to check qualitative properties. These properties (for
example, safety, liveness, etc.) are related to the functional behavior of the system
and can be verified by using classic model checkers, such as NuSMV. To cover all
the characteristic aspects of the CPS, the qualitative properties are not enough,
because they are not able to formalize probabilistic aspects. To succeed in this,
there is the necessity to use the quantitative properties, which are mainly related to
probabilistic behaviors. Verification of these properties is supported by probabilistic
model checkers (such as PRISM).
To model and verify the CPS, different methods have been proposed; although
some of these have been applied successfully in many areas, they have some dis-
advantages, including: difficulty in use, complex mathematical notations, etc. To
solve these disadvantages, in this thesis we propose to model CPS systems using the
formal method of the Abstract State Machines (ASMs). It is a system engineering
method that allows the implementation of the main design and analysis techniques
typically used in software life cycle. During the development of a system, the ASMs
drive the user from the analysis of the requirements up to the code implementation.
The advantages of using ASMs as a modeling method are the following: they allow
to operate at different levels of abstraction; they manage the complexity of systems
of all sizes; they support the concept of distributed computing; although they are
a strong mathematical basis, they do not require particular mathematical skills to
be used; ASM models are executable, therefore suitable for high level validation of
systems; there exists a toolset for model validation and verification (ASMETA). This

5
method, however, does not provide any support for the modeling and verification
of probabilistic behaviors and the purpose of this thesis work is to provide such
support.
As a tool for modeling the ASMs we use ASMETA, which is one of the main tools
supporting this formal method. In particular, it is a framework consisting of tools
developed under Eclipse for editing, syntax checking, simulation and verification of
qualitative properties through classic model checking, of ASM models written in
the AsmetaL language. Within ASMETA, the properties verification is provided by
model checking, and this proof automation we intend to guarantee for quantitative
verification too.
In general, model checking is a technique of automatic verification of properties:
given the model of a system (hardware or software) written in a suitable formalism
(Kripke structures, Markov chains, etc.), a model checker makes it possible to verify
that the model satisfies certain properties expressed in a temporal logic (Computation
tree logic (CTL), Linear temporal logic (LTL), Probabilistic Computation tree logic
(PCTL)).
To extend the ASMs with the concept of probability, we have studied the relation
between the ASM computational model with that of the Markov chains, a formalism
that allows modeling of systems presenting probabilistic behaviors. One of the main
tools that are based on the Markov chains is PRISM, a probabilistic model checker
that allows modeling and formal analysis of systems exposing non-deterministic or
probabilistic behavior; in particular PRISM allows the verification of quantitative
properties.
The aim of the thesis work was to try to exploit the potentialities of the PRISM
probabilistic model checker to perform quantitative properties checks with the PCTL
temporal logic on ASMETA models.
In the design phase of this mapping from ASMs to PRISM, we found that the
development of certain processes would have been similar to projects developed in
the past by the developers of ASMETA; so, for this reason, we thought of splitting
the problem of mapping ASM models into PRISM models into two steps: defining a
normal form of an ASM model, and using this normal form to map an ASM into a
PRISM model.
To solve the two problems described above, we have developed two tools, AsmetaF
and AsmetaPRISM, which allow respectively to translate an ASM model into its
"normal form", and to translate a model in normal form to a PRISM model.
The user can easily develop an ASM model in ASMETA, specifying with the
PCTL those properties (s)he wants to verify; then, through the AsmetaF tool, the
original model is brought in its normal form and then, by means of the AsmetaPRISM,
encoded in PRISM. Through the execution of the obtained PRISM model we obtain
the verification of the specified properties. The only knowledge that the user must
acquire in order to make probabilistic model checking on ASMETA models is the
semantics of the PTCL operators; the PRISM syntax can be ignored.
The following image illustrates the phases of the mapping process from the
system requirements to the verification of probabilistic properties.

6 INTRODUCTION
Figure 2: Process from system modeling to probabilistic properties verification
Part of this thesis was developed at the National Institute of Informatics in
Tokyo, Japan, in the context of the ERATO MMSD (Metamathematics for Systems
Design) project, which studies the application of formal methods to the modeling and
verification of CPS. The collaboration was fundamental for the aspects concerning
the development of AsmetaPRISM, in particular, the study and design of the
correspondence of the theoretical models (ASMs and Markov Chains).
The thesis is composed of three parts: in the first part we provide the knowledge
of the environments with the tools developed interact; in the second part the tools
developed are shown; in the last part there are the application of the tools to two case
studies. The chapters of the thesis are: Chapter 1 describes the theoretical concepts
of ASMs and Chapter 2 those of PRISM, to provide the appropriate theoretical
background and allow the reader to understand the contribution presented in the
following chapters. Chapter 3 defines the normal form of an ASM model, describes
the process for transforming an ASM into its equivalent normal form, discusses
the advantages of the normal form, and presents the AsmetaF tool developed for
this purpose. Chapter 4 describes the architecture and operation of the main tool
developed as part of this thesis, i.e., AsmetaPRISM. Starting from the normal form
of a model obtained through AsmetaF, AsmetaPRISM maps a model written in
AsmetaL in a PRISM model, to then exploit the probabilistic verification capabilities
of the probabilistic model checker to prove properties. In Chapter 5 we present the
application of the tools developed to different case studies of different complexity;
we show the AsmetaL model, its normal form, and finally the translation in PRISM;
for each model analyzed quantitative properties are verified. The appendix contains
the codes of the examples in Chapter 5.
Part of the content presented in Chapter 3 has been published in the following
paper: P. Arcaini, R. Melioli, E. Riccobene AsmetaF: a flattener for the ASMETA
framework in 4th Workshop on Formal Integrated Development Environment (F-IDE
2018), Oxford, UK, July 14, 2018.

Chapter 1
Abstract State Machines and
ASMETA
1.1 Abstract State Machines (ASMs)
Abstract State Machines (ASMs) [BS03], previously named as Evolving Alge-
bras [Gur95]), are a system engineering method that drives the development of
systems (both software and hardware) from the requirements capture to the code
implementation.
ASMs have been successfully applied in different contexts:
• definition of industrial standards for programming and modeling languages;
• design and re-engineering of industrial control systems;
• modeling e-commerce and web services;
• design and analysis of protocols;
• architectural design;
• verification of compilation schema and compiler back-ends;
• ...
ASMs are transition systems based on the concept of state representing the
instantaneous configuration of the system under development, and transition rules
describing the change of state. ASMs extend the concept of uncontrolled FSM state
and provide a more powerful and expressive way to model transitions than FSMs.
1.1.1 States
ASM states are multi-sorted first-order structures, i.e., domains of objects with
functions and predicates defined on them. An ASM state S is represented by a set
of couples (location, value). ASM locations, namely pairs (function-name, list-of-
parameter-values), represent the abstract ASM concept of basic object containers
(memory units). Location updates represent the basic units of state change and they
are given as assignments, each of the form loc :“ v, where loc is a location and v its
new value.
We formally denote the following definitions:
Definition 1.1 (Signature). A signature (or vocabulary) is a finite set of function
names, each having an arity n P N0 that specifies the number of arguments of the
9

10 CHAPTER 1. ABSTRACT STATE MACHINES AND ASMETA
function.
Also if it is not specified, every signature contains the static constants undef,
true, false.
Definition 1.2 (Location). The pair pf, pv1, . . . , vnqq composed by a function name
f of arity n ě 0, which is fixed by the signature, and an argument pv1, . . . , vnq (empty
if n “ 0), which is formed by a list of dynamic parameter values vi of whatever type,
is called location.
Locations can be viewed as an abstraction of memory units, in which the memory
addressing and object referencing mechanisms are not specified [BS03].
Definition 1.3 (State). An ASM state A of a signature Σ is given by a non-empty
set X (called the superuniverse of A) and interpretations for the function names in
Σ.
An interpretation for an n-ary function f, with n ą 0, is a function fA : Xn Ñ X.
An interpretation ca for a 0-ary function c is an element of X.
ASM functions can be partial, since they can be not totally defined. However,
they can be seen as total functions, saying that the interpretation of a not specified
location fpv1, . . . , vnq is interpreted as the interpretation of the constant undef (i.e.,
fApv1, . . . , vnq “ undef A
).
The superuniverse X is usually divided in smaller universes (or domains). A
domain D can be described by a characteristic function g that indicates the elements
of the superuniverse that constitute the domain, i.e., @x P X rx P D Ø gpxq “ trues.
1.1.2 Transitions
ASM transition rules express how function interpretations are modified from
one state to the next one, and therefore describe the system configuration changes.
The basic form of a transition rule is the guarded update: “if Condition then
Updates”, where Updates is a set of function updates (or update rules) of the form
fpt1, . . . , tnq :“ t which are simultaneously executed when Condition is true; f is an
arbitrary n-ary function and t1, . . . , tn, t are first-order terms.
We give the following definitions
Definition 1.4 (Update). Location-value pairs ploc, vq (i.e., pf, pv1, . . . , vnq, vq) are
called updates and represent the basic units of state change.
Definition 1.5 (Update set). The update set is the set of all the applicable updates
in a state.
The condition imposed by transition rules identifies the applicable updates. An
update set is applicable to the machine only if it is consistent.
Definition 1.6 (Consistent Update Set). An update set US is consistent if it holds:
pppf, pa1, . . . , anqq, bq P US ^ ppf, pa1, . . . , anqq, cq P USq Ñ b “ c
If the update set is consistent, it is not possible that a location is updated to
two different values at the same time.

1.1. ABSTRACT STATE MACHINES (ASMS) 11
Definition 1.7 (Run). A run (or computation) of an ASM is a finite or infinite
sequence s0, s1, . . . , sn, . . . of states of the machine, where s0 is an initial state and
each si`1 is obtained from si by simultaneously applying all of the transition rules
which are enabled in si.
If in a state the computed update set is not consistent, it is not applied and the
run terminates.
1.1.2.1 Transition rules
In its simplest form, a transition rule has the form of guarded update
if cond then updates
where cond is a first-order formula without free variables, and updates a set of
function updates of the form fpt1, . . . , tnq :“ t which are simultaneously executed
when cond is true. f is an arbitrary n-ary function and t1, . . . , tn, t are first-order
terms. To apply this rule in a state si, i ě 0, all terms t1, . . . , tn, t are evaluated
at si to their values, say v1, . . . , vn, v, then the value of location pf, pv1, . . . , vnqq is
updated to v, which represents the value of the location in the next state si`1.
Actually, ASMs provide a rich set of transition rules and by their high expres-
siveness we can easily and concisely describe complex guarded updates.
We here briefly describe the transition rules available in the ASMs.
Skip rule It does not produce any effect.
skip
Update rule It updates the location fpv1, . . . , vnq to the value v, being v1, . . . , vn
and v the evaluation of terms t1, . . . , tn and t in the current state.
fpt1, . . . , tnq :“ t
Block rule It executes rules R1 and R2 simultaneously in parallel.
R1 par R2
Since R1 and/or R2 could be block rules as well, we introduce a more general
notation that describes the parallel execution of n rules, with n ě 2.
par
R1
. . .
Rn
endpar

Conditional rule It executes rule Rthen if the boolean condition cond is true,
Relse otherwise1.
if cond then
Rthen
else
Relse
endif
Forall rule It executes in parallel the rule R with all the values of x for which
the boolean condition cond is true. The read-only variable x can occur both in the
boolean condition and in the rule R.
forall x in D with cond do
R
Choose rule It non-deterministically chooses a value for x for which the boolean
condition cond is true and executes the rule R with the chosen value. If no value for
x exists that satisfies the condition, nothing is done2. The read-only variable x can
occur both in the boolean condition and in the rule R.
choose x in D with cond do
R
Extend rule It takes a new element e from the reserve (i.e., a subset of the
superuniverse X, containing fresh elements), it removes e from the reserve and adds
it to the domain D. Then it executes rule R, where the new value e could be read.
extend D with e
R
Let rule It associates to x the value of t and executes R. The read-only variable
x can occur in the rule R.
let x “ t in R
Call rule It calls the rule R using as parameters t1, . . . , tn.
Rpt1, . . . , tnq
1
In concrete syntaxes, as AsmetaL (see Section 1.2) or the CoreASM syntax [FG11], the else
branch is usually optional.
2
Usually, in concrete syntaxes, the choose rule can also specify a rule Rifnone that must be
executed if no value for x satisfies the condition. The modified syntax is
choose x in D with cond do
R
rifnone Rifnones

1.1. ABSTRACT STATE MACHINES (ASMS) 13
Turbo ASMs transition rules The transition rules described previously consti-
tute the so called basic ASMs. A richer set of ASMs are the turbo ASMs that can
contain transition rules for sequential composition, iteration, and the definition of
parametric sub-machines. The sequential rule (R1 seq R2), for example, permits
to decompose a step in micro steps that must be executed in sequence. We do not
describe all the turbo rules here, since they are not used in the rest of the text.
1.1.3 ASM
Having the notion of signature, state, and transition rule, we can now formally
define what is an Abstract State Machine, by first introducing the notion of rule
declaration.
Definition 1.8 (Rule declaration). Given a transition rule R, containing occurrences
of the free variables x1, . . . , xn, a rule declaration for a rule name r of arity n is
rpx1, . . . , xnq “ R
Given a rule call rpt1, . . . , tnq, each occurrence of variable xi in the body of R is
substituted with ti.
Definition 1.9 (Abstract State Machine). An Abstract State Machine is constituted
by:
1. a signature Σ, together with a classification for all the functions;
2. a set of initial states S0;
3. a set of rule declarations RD;
4. a main rule of arity 0 that acts as the starting point of the ASM and that
invokes, directly or indirectly, the rules in RD.
Model refinements An useful and incremental approach to use the ASM for
capturing the system specifications is to start creating a ground model, and step by
step, add system details to the model, until it reaches, the wanted granularity. In
detail a ground models are abstract yet complete, that is they contain all the essential
elements of the system under development (the interaction with the environment,
the architectural system structure, etc.), but they do not model behaviors that are
not necessary for the overall understanding of the system.
The elements of the system not inserted in the ground model, in other words they
are left abstract at this point, and if necessary, they are been specified in successive
refinements. Given that the ground model is based on mathematical concept, it can
be validated and verified, obviously, the correctness and accuracy of their results
respect the system, depends on the level of details expressed by the model. For
example, since they are executable, they can be simulated to discover if they reflect
the user expectations about the system.
Starting from the ground model, more detailed models can be obtained, in a
interactive way, through the refinement method. Each refinement step consists in the
implementation of some system requirements in a more detailed way. A refinement

shared
out
monitored
controlled
static
dynamic
function
basic
derived
Figure 1.1: Classification of ASM functions
is considered as correct if an ASM M and the refined ASM M˚ have equivalence of
their runs. It provides a theoretical support for the verification of the refinement
correctness.
1.1.4 Multi-agent ASMs
ASMs can be specified as multi-agents models, in which different agents can
interact with each other, executing their moves. In a multi-agent ASM, each agent
specifies its own program, i.e., some basic/turbo rules that describe its behavior.
Multi-agent ASMs can be:
• synchronous: all agents execute their programs in parallel, synchronized
using an implicit global system clock [BS03]. A synchronous multi-agent ASM
permits to decompose a complex single-agent ASM, identifying the part of
the machine (signature and behaviors (i.e., transition rules)) that is due to a
particular agent of the system under development.
• asynchronous: the moves of the agents can be scheduled in any desired order.
A run of a multi-agent asynchronous ASM is a partially ordered set pM, ăq
that guarantees three conditions:
1. finite history: each move m P M has finitely many predecessors;
2. sequentiality of agents: the set of moves of every agent is linearly ordered
by ă;
3. coherence: given an initial finite segment X of pM, ăq, it exists a state
σpXq that is the result of applying any maximal element m P M to state
σpX ´ tmuq.
1.1.5 Functions classification
ASMs functions are classified, as shown in Fig. 1.1, depending on the way in
which they can be read and updated.
A first distinction is made between basic and derived functions. Basic functions
are those that form the basic signature, whereas derived functions are those coming
with a specification or computation mechanism given in terms of other basic functions.

1.2. ASMETA: A FRAMEWORK FOR ASMS 15
Basic functions are further divided into static, which never change during any
run of the machine, and dynamic, that may be changed by the environment or by
machine updates.
0-ary static functions are also called constants; 0-ary dynamic functions, in-
stead, are also called variables, since they can be viewed as the variables used in
programming languages.
Dynamic functions are divided into:
• monitored: they are updated by the environment (or by another agent in case
of a multi-agent machine), and can be only read by the machine (i.e., they can
not appear in the left-hand side of an update rule); they identify the part of
the dynamic state that is controlled by the environment;
• controlled: they can be read and updated by the machine (i.e., updated by
transition rules), and they can not be updated by the environment (or other
agents); they identify the part of the dynamic state that is directly controlled
by the machine;
• shared: they can be read and updated both by the machine and the environment;
they represent a combination of monitored and controlled functions; since they
can be updated by multiple agents, usually a protocol is required to assure
that the updates are consistent;
• out: they can be updated but not read by the machine (i.e., they can only
appear in the left-hand side of an update rule), and read but not updated by
the environment and other agents.
1.2 ASMETA: a framework for ASMs
The use of formal methods in system development processes is not common.
This is because: they use mathematical notations, sometimes they need specific
knowledge, and there are not many tools that try to solve these problems. In other
words, there are few tools that allow you to use formal methods for the following
processes:
• modeling
• simulation
• validation
• verification
• tests generation
• ...
These activities are often individually covered by some tools, and this is why
users have difficulties to use them; what the user would like to have is to switch
tools to get the best of them, for example reusing information already entered about
their models. Indeed, one of the main disadvantage of the different tools usage is
their own notations and internal representation of models, these aspects make the
integration of tools and the reuse of information hard to accomplish.
The goal of the ASMETA (ASM mETAmodeling) toolset [Asmb; GRS08b] is to
fill this gap, because it provides tools for developing, exchanging, analyzing ASM
models, and it is also a framework for developing new ASM tools and for integrating
existing ones.

Core concepts The initial developers of ASMETA started collecting all material
available on the ASM theory and tool support. As official documentation about the
ASM theory, they took [BS03], but they also considered to include constructs (i.e.,
particular forms of domains, special terms, derived rule schemes) from other existing
notations (like XASM, ASM-WB, AsmGofer, and AsmL) for encoding ASM models.
Indeed, they defined general rules on how to derive a context-free EBNF grammar
from a metamodel, and also provided guidance on how to automatically assemble a
script file and give it as input to the JavaCC parser generator to generate a parser
for the EBNF grammar of the textual notation. This parser is more than a grammar
checker: it is able to process models conforming to their metamodel, to check for
their well-formedness with respect to the OCL constraints of the metamodel, and to
create instances of the metamodel through the use of the Java APIs.
Applying the technique explained in [GRS06a], they obtained AsmetaL [GRS08a],
a platform-independent textual notation, to write ASM models. Table 1.1 shows the
template of an ASM model (taken from [GRS08a]); the complete documentation
about the language can be found in [GRS06b; Asma].
Moreover, they also, obtained AsmetaLc, a text-to-model compiler, to parse
AsmetaL models and check for their consistency w.r.t. the AsmM OCL constraints.
The AsmetaL and its compiler AsmetaLc can be considered in between generated
and based tools, since they were partially derived from the metamodel (however we
consider them based tools).
Tools developed In the last few years our research group3 creates different tools
for covering all possible aspects mentioned before (1.2).
ASMs have been provided with a set of tools, the ASMs mETAmodeling (AS-
META) toolset [Asmb] (see Fig. 1.2), useful for the practical use of ASMs in the
systems development life-cycle. Concrete syntaxes have been defined, useful to
create, store, access, validate, exchange and manipulate ASM models. Moreover, a
general framework has been built, suitable for developing new ASM tools and for
the integration of existing ones [GRS08b].
Modelling
Editor AsmetaL - AsmEE
Visualizer AsmetaVis
Refinement prover
AsmRefProver
ASM 0 ASM 1
ASM
final
Validation and verification
Atany
level
Code Generator
Asm2C++ C++ Code
Abstract unit tests generator
Model-Based Testing
ATGT
Validation Property Verification
Model Checking
AsmetaSMV
Model Review
AsmetaMA
Simulation
AsmetaS
Scenarios
AsmetaV
C++ Unit test
Animator
AsmetaA
Figure 1.2: The ASMETA toolset
In ASMETA framework, three different categories of tools, are identifiable:
• Modeling: the tools in this category are for:
3
Formal Methods and Software Engineering Laboratory (FM&SE Lab) – http://fmse.di.unimi.
it/

1.2. ASMETA: A FRAMEWORK FOR ASMS 17
AsmM elements Concrete syntax
ASM (asm|module) name
Header [import] m1 [pid11 . . . id1h1 q]
[import] mk [pidk1 . . . idkhk
q]
[export pid1 . . . ideq | export *]
signature:
[dom_decl1 . . . dom_decln]
[fun_decl1 . . . dom_declm]
where:
- pidi1 . . . idihi q are names for domains, functions and rules imported from module mi
(if omitted, all exported elements of mi are imported)
- pid1 . . . ideq are names for exported domains, functions and rules (* to export all)
- dom_decli and fun_decli are declarations of domains and functions
Body deﬁnitions:
[domain D1 “ DTerm1 . . . domain Dp “ DTermp]
[function f1 [pp11 in D11 . . . p1h1 in D1h1 q ] “ FTerm1
. . .
function fq [ppq1 in Dq1 . . . pqhq in Dqhq q ] “ FTermq ]
[rule_decl1 . . . rule_declr]
[invariant_decl1 . . . invariant_decls]
where:
- DTermi and FTermi are terms deﬁning domains Di and functions fi
- pij are variables ranging in the domain Dij and specifying the formal parameters of the function fi
- rule_decli and invariant_decli are declarations of rules and axioms
Main rule [main rule_decl ]
Initial state [default] init sn:
[domain D1 “ DTerm1 . . . Du “ DTermu]
[function f1 [pp11 in D11 . . . p1h1 in D1h1 q ] “ FTerm1
. . .
function fv [ppv1 in Dv1 . . . pvhv in Dvhv q ] “ FTermv ]
[agent A1: rule1 . . . agent Az: rulez ]
where:
- sn is the name of the initial state
- DTermi and FTermi are terms specifying the initial value of domains Di and functions fi
- pij are variables ranging in the domain Dij and specifying the formal parameters of the function fi
- Ai and rulei are the agents and their associated programs
Table 1.1: Template of AsmetaL programs
– model development

– model refinement
– verify the refinement correctness (AsmRefProver)
• Validation and Verification: the tools in this category are for:
– Validation by model simulation
– Model checking (AsmetaSMV)
• Dealing with the implementation: the tools in this category are for:
– Automated generation of code
– Linking an existing code with the respective model
– Test generation from the model (by SPIN)

Chapter 2
PRISM: Probabilistic Model
Checker
Probabilistic model checking is a technique for formally verifying quantitative
properties of systems that exhibit stochastic behavior. There are several domains in
which it is possible to find a stochastic behavior, for example:
• communications with lossy compression;
• distributed protocols, where it is used randomization;
• systems with unreliable components, that they could present a margin of error.
Probabilistic model checking is based on the construction and analysis of a prob-
abilistic model, which is introduced in the section 2.1. The technique has been
applied to a variety of different types of models, typically variants of Markov chains
(MCs) and Markov decision processes (MDP), see in Tab. 2. In this thesis, only
discrete-time MC (DTMC) and MDP are considered, since the concept of continuous
time in Markov chains, is not supported in ASMs and ASMETA.
Time Non-determinism Probabilistic Models
Discrete no Discrete-time Markov chains (DTMCs)
yes probabilistic automata (PAs)
Markov decision processes (MDPs)
Continuous no continuous-time Markov chains (CTMCs)
yes probabilistic timed automata (PTAs)
priced probabilistic timed automata (PPTAs)
Table 2.1: Supported models by Prism
2.1 Probabilistic Models
A stochastic process or random process is a collection of random variables
valuated in S (set of states), which can be written as Xptq : t P T, so it is a category
Xptq of aleatory variables, indexed on the parameter t P I and defined into the same
space of samples, where
• t is time
• I is an interval of time
19

20 CHAPTER 2. PRISM: PROBABILISTIC MODEL CHECKER
• the space of samples identifies a set of possible values (or states) of Xptq
Definition 2.1 (Markov Process). When a stochastic process describes a sequence
of possible events in which the probability of each event in a state depends only on
the previous state, therefore on the previous event, it’s called Markov process.
And formally:
PpXt0q “ xk|Xpt0q “ x1, Xpt1q “ vx1...Xpk´1q “ xk´1q “
PrXptkq “ xk|Xptk´1q “ xk´1s
where:
• k P N
• t0...tk P I with t0 ă t1 ă ... ă tk
• x0...xk P a space of samples
Markov process with a discrete space of samples is called Markov chain, and regarding
its behavior to the time, it is spitted in two categories:
• DTMC: Discrete Time Markov Chain, this kind it is explained and used in
this thesis;
• CTMC: Continuous Time Markov Chain.
2.1.1 Discrete-Time Markov Chains (DTMC)
Discrete-time Markov chains can be thought as a labeled state-transition system
in which for every transition is labeled with a value indicating the probability of its
associated event can occur, therefore the probability of making a transition from
one state to another.
Definition 2.2 (Discrete-Time Markov Chains (DTMC)). DTMC is defined as a
tuple pS, ¯s,P,Lq where:
• S is a finite set of states;
• ¯s P S is the initial state;
• P: S ˆ S Ñ r0, 1s is the transition probability matrix;
• L: S Ñ 2AP is the labeling function.
An element of the transition probability matrix describes the probability of
making a transition from state s to state s’, and it is written as follow P(s,s’).
Definition 2.3 ((ω)). An execution of the system which is being modeled is repre-
sented by a path through the DTMC, and it is denoted by ω, and it is a non-empty
sequence of state, where for every state the probability of making a transition is
greater than 0.
Definition 2.4 (finite or infinite path). A path can be either finite or infinite, a
finite path is simply present when there is the last state in that path, instead if it is
not present it is a infinite path.
For understanding the probabilistic behavior of the system, it is necessary
describing the probability of the paths in a DTMC. As said before, an execution

2.1. PROBABILISTIC MODELS 21
of the system corresponds to a path, and its probability is determinable with a
standard method [JKK66], for each state s P S, is defined a value of probability,
Probs on the path Paths, and the probability measure is induced on the transition
probability matrix P.
• If ωfin has an only state s0, then Ppωfinq “ 1
• If ωfin “ s0s1...sn, then Ppωfinq “ Pps0, s1q ¨ Pps1, s2q...Ppss´1, snq
Using the method mentioned before is possible to quantify the probability of a
DTMC, by identifying the set of paths which satisfy this specification and, assuming
that it is measurable, using the associated measure Probs .
Probabilistic model checking allows to reason about path-based properties, and
they can be used to specify constraints on the probability of the occurrence of events.
Properties are defined using temporal logic, for DTMC specifications can be written
in PCTL (Probabilistic Computation Tree Logic), a probabilistic extension of the
temporal logic CTL (2.2).
2.1.2 Markov-decision process (MDP)
Markov decision processes (MDPs) is second type of model considered in this
thesis, and it can be thought as a generalization of the DTMC.
An MDP can model non-deterministic and probabilistic behavior. This makes
possible our goal of mapping from an ASM to MDP model, because ASMa can
contain non-determinism.
Non-determinism Indeed it is the kind of model we chose for the mapping
(Chapter 4).
Non-determinism is useful for:
• systems that work in parallel;
• systems in which the exact value of probability is not know.
Definition 2.5 (Markov-decision process (MDP)). A Markov-decision process
(MDP) is a tuple M = (S, ¯s, Act, Steps, AP , L) where:
• S, ¯s P S , AP and L : S Ñ 2AP are as for DTMCs;
• Act is a set of action labels;
• Steps : S Âct Ñ Dist(S) is the (partial) transition probability function, with
Dist(S) denoting the set of all discrete probability distributions over S.
In each state s of an MDP, the successor state is decided in two steps:
• non-deterministically selecting an available action P Act (in other words one
for which Steps(s, a) is defined);
• randomly choosing the successor according to the probability distribution
Steps(s, a).
To reason formally about the behavior of MDPs, it is used the notion of adversaries
according to [MK], which resolve all of the non-deterministic choices in a model.
An example of non-determinism used to model the concurrency among the
components is as follows. The notion of adversary represents a possible planning of
components during the life of the system. With a particular adversary, the behavior
of an MDP is completely probabilistic and, as for the DTMCs, we can define a
probability space on the possible paths through the model. We can therefore reason

on the best or worst behavior of the system, trying for all possible opponents: for
example, we can calculate the minimum or maximum probability that some event
will occur.
To formally specify properties is used the logic PCTL as in the DTMC model,
with same syntax, but with an implicit quantification over adversaries. Th? e P“?
operator used for DTMCs is replaced with two variants Pmin“? and Pmax“?.
Example properties include:
• Pě1rFends - “under all possible adversaries, the algorithm always terminates
with probability 1”;
• Pmax“?rFlosts - “the maximum probability, across all possible schedulers, of
the protocol losing a message”.
2.2 Probabilistic Computation Tree Logic (PCTL)
PCTL (Probabilistic Computational Tree Logic) [HJ94] is a probabilistic exten-
sion of the temporal logic CTL. The syntax of PCTL is as follows:
Φ ::= true | a | Φ | Φ ^ Φ | Φ _ Φ | Φ’prφs
φ ::= X Φ | ΦUďkΦ | ΦUΦ
where a is an atomic proposition, ’P tă, ď, ě, ąu,p P r0, 1s and k P N. PCTL
formula are interpreted over the states of a DTMC [[Par02]].
A state s P S satisfies a PCTL formula Φ, denoted s|ù Φ, if it is true for s. The
key operator in PCTL is P’ p [ ϕ ] which means that the probability of a path
formula ϕ being true in a state satisfies the bound ’ p. As path formulae (specified
separately on the second line, it is allowed X Φ (“Φ is satisfied in the next step”) Φ1
Uďk Φ2 (“Φ2 is satisfied within k steps and Φ1 is true until that point”) and Φ1 U
Φ2 (“Φ2 is eventually satisfied and Φ1 is true until then”). A simple example is:
Pď0.15[ failAUfailB]
which states that “the probability that component B fails before component A is at
most 0.15”. Here, failA and failB are atomic propositions, used to label states of
a DTMC in which a property of interest (for example “component A has failed”)
is true. In practice, it is common to take a more quantitative approach, instead
writing formula of the following kind:
P“?[ failAUfailB]
which asks simply “what is the probability that component B fails before component
A?”.
Several other useful operators can be derived from the basic PCTL syntax given
above. This includes, for example, F Φ ” true U Φ (“eventually Φ becomes true”),
G Φ ” F Φ (“Φ is always true”) and time-bounded variants of these.
Examples of properties using these operators, in particular the operators needed by
this thesis are given in the section 2.3.2.

2.3. PRISM 23
2.3 PRISM
PRISM is a probabilistic model checker, a tool for formal modeling and analysis
of systems that exhibit random or probabilistic behavior. It has been used to
analyse systems from many different application domains, including communication
and multimedia protocols, randomised distributed algorithms, security protocols,
biological systems and many others.
PRISM can build and analyse several types of probabilistic models:
• discrete-time Markov chains (DTMCs)
• continuous-time Markov chains (CTMCs)
• Markov decision processes (MDPs)
• probabilistic automata (PAs)
• probabilistic timed automata (PTAs)
plus extensions of these models with costs and rewards.
2.3.1 Language
PRISM language is a simple, state-based language. It provides support for
automated analysis of a wide range of quantitative properties, for examples "what is
the probability of a failure causing the system to shut down within 4 hours?", "what is
the worst-case probability of the protocol terminating in error, over all possible initial
configurations?", "what is the expected size of the message queue after 30 minutes?",
or "what is the worst-case expected time taken for the algorithm to terminate?".
The property specification language incorporates the temporal logics:
• Computation Tree Logic (CTL)
• Linear Temporal Logic (LTL)
• Probabilistic CTL (PCTL)
• Probabilistic CTL * (PCTL*)
In this thesis we use only the CTL, LTL and PCTL, because the first two are used in
ASMETA, and they are useful for a direct translation to PRISM. The PCTL is used
to define quantitative properties by P operator as we see in a following paragraph
(2.3.2), for obtaining minimum and maximum probability, that they come from
non-deterministic rules in ASMETA, and even to specify probabilistic properties on
the model when ASMETA will be extended with probabilities on its rules.
PRISM incorporates state-of-the art symbolic data structures and algorithms,
based on:
• BDDs (Binary Decision Diagrams)
• MTBDDs (Multi-Terminal Binary Decision Diagrams)
It also includes a discrete-event simulation engine, providing support for approximate
or statistical model checking, and implementations of various different analysis
techniques, such as quantitative abstraction refinement and symmetry reduction.
PRISM is free and open source, released under the GNU General Public License
(GPL). In the next paragraphs are explained the language features [[Pri]] necessary
for this thesis.
Model type As mentioned above, the PRISM language can be used to describe
several types of probabilistic models: DTMCs, CTMCs, MDPs and PTAs. To

indicate which type is being described, a PRISM model should include one of the
keywords dtmc, ctmc, mdp or pta. This is typically at the very start of the file, but
can actually occur anywhere in the file (except inside modules and other declarations).
If no such model type declaration is included, the model is by default assumed to
be an MDP. The models used in this thesis are only Discrete-time Markov Chain
(DTMC) and Markov-decision process (MDP).
Modules and Variables A module is specified as:
module name . . . endmodule
¥
The definition of a module contains two parts:
• variables: describe the possible states that the module can be in;
• commands: describe its behaviour, in other words the way in which the state
changes over time.
Currently, PRISM supports just a few simple types of variables: they can either be
(finite ranges of) integers or Booleans.
In the example above, each module has one integer variable with range [0..2]. A
variable declaration looks like:
x : [ 0 . . 2 ] i n i t 0;
¥
Notice that the initial value of the variable is also specified. A Boolean variable is
declared as follows:
b : bool i n i t f a l s e ;
¥
It is also possible to omit the initial value of a variable, in which case it is assumed
to be the lowest value in the range (or false for a Boolean). For a few kinds of
model analysis (typically those based on simulation, such as approximate model
checking or fast adaptive simulation, it is also permissible to use integer variables
with unbounded ranges, denoted as:
x : i n t ;
y : i n t i n i t 3;
¥
Where the state space of the model remains finite, despite the presence of such
unbounded variables, you can use the explicit engine to build and analyze the model.
Commands The behavior of each module is described by commands, comprising
a guard and one or more updates. An example of command is:
[ ] x=0 ´> 0 . 8 : ( x ’=0) + 0 . 2 : ( x ’=1) ;
¥
The guard x=0 indicates that this describes the behavior of the module when
the variable x has value 0. The updates (x’=0) and (x’=1) and their associated
probabilities state that the value of x will remain at 0 with probability 0.8 and
change to 1 with probability 0.2. Note that the inclusion of updates in parentheses,
for example (x’=1), is essential.
[ ] x=1 & y!=2 ´> ( x ’=2) ;
¥

2.3. PRISM 25
The guards can contain constraints on any variable, not just the ones in that module,
so the behavior of one module can depend on the state of another. Updates, however,
can only specify values for variables belonging to the module. In general a module
can read the variables of any other module, but only write to its own.
Parallel composition The probabilistic model (DTMC, MDP) is deﬁned in
PRISM, as the parallel composition of all the modules of the PRISM model. In each
model state, there is a set of commands (which belong to any of the modules) that
are enabled. The choice between which command to perform depends on the type
of model.
For an MDP, the choice is non-deterministic. There are two commands enabled,
one from each module:
module M1
. . .
[ ] x=0 ´> 0 . 8 : ( x ’=0) + 0 . 2 : ( x ’=1) ;
endmodule
module M2
. . .
[ ] y=0 ´> 0 . 8 : ( y ’=0) + 0 . 2 : ( y ’=1) ;
endmodule
¥
In state (0,0) of the MDP, there would be a non-deterministic choice between these
two probability distributions:
• 0.8:(0,0) + 0.2:(1,0) (module M1 moves)
• 0.8:(0,0) + 0.2:(0,1) (module M2 moves)
For a DTMC, the choice is probabilistic: each enabled command is selected with
equal probability. If the previous example was a DTMC, then in state (0,0) of the
model the following probability distribution would result:
• 0.8:(0,0) + 0.1:(1,0) + 0.1:(0,1)
Local non-determinism Probabilistic models that support non-determinism (e.g.
MDPs), can also contain local non-determinism, that allows to the modules to make
non-deterministic choices. In the previous example, we can make the probabilistic
choice in the ﬁrst state of module M1 non-deterministic by replacing the command:
[ ] x=0 ´> 0 . 8 : ( x ’=0) + 0 . 2 : ( x ’=1) ;
¥
with the commands:
[ ] x=0 ´> ( x ’=0) ;
[ ] x=0 ´> ( x ’=1) ;
¥
Assuming we do the same for module M2, in state (0,0) of the MDP there will be a
non-deterministic choice between the three (trivial) probability distributions listed
below. (There are three, not four, distributions because two possibilities result in
identical behavior: staying with probability 1 in the state state.)
• 1.0:(0,0)
• 1.0:(1,0)
• 1.0:(0,1)
More generally, local non-determinism can also arise when the guards of two com-
mands overlap only partially, rather than completely as in the example above.

Constants PRISM supports the use of constants, and they can be integers, doubles
or Booleans and can be defined using literal values or as constant expressions
(including in terms of each other) using the const keyword. For example:
const i n t r a d i u s = 12;
const double p i = 3.141592;
const double area = p i ∗ r a d i u s ∗ r a d i u s ;
const bool yes = true ;
¥
Constants can be used anywhere that a constant value would be expected, such as
the lower or upper range of a variable, the probability or rate associated with an
update, or anywhere in a guard or update.
Expressions Expressions can contain literal values(1, true,...), identifiers(variables,
...) and operators from the following list:
• - (unary minus)
• *, / (multiplication, division)
• +, - (addition, subtraction)
• <, <=, >=, > (relational operators)
• =, != (equality operators)
• ! (negation)
• & (conjunction)
• | (disjunction)
• <=> (if-and-only-if)
• => (implication)
• ? (condition evaluation: condition ? a : b means "if condition is true then a
else b")
All of these operators except ? are left associative, so they are evaluated from left
to right.
Built-in Functions Expressions can make use of several built-in functions:
• min(...) and max(...), which select the minimum and maximum value, respec-
tively, of two or more numbers;
• floor(x) and ceil(x), which round x down and up, respectively, to the nearest
integer;
• pow(x,y) which computes x to the power of y;
• mod(i,n) for integer modulo operations;
• log(x,b), which computes the logarithm of x to base b.
Synchronization In the style of many process algebras, it is allowed to commands
to be labeled with actions. These are placed inside the square brackets which mark
the start of the command, for example:
[ s e r v e ] q>0 ´> lambda : ( q’=q´1) ;
¥
These actions can be used to force two or more modules to make transitions simulta-
neously (synchronize). A common technique, is to make one action passive, with
rate 1 and one action active, which actually defines the rate for the synchronized
transition. By default, all modules are combined using the standard CSP parallel
composition (modules synchronize over all their common actions).

2.3. PRISM 27
Multiple Initial States The initial state for the model is defined by the initial
value for all variables. It is possible, however, to specify that a model has multiple
initial states. This is done using the init...endinit construct, which can be placed
anywhere in the file except within a module definition, and removing any initial
values from variable declarations. Between the init and endinit keywords, there
should be a predicate over all the variables of the model. Any state which satisfies
this predicate is an initial state.
2.3.2 Properties specification
The P Operator This operator is one of the principal operators in the PRISM
property specification language, and it is used to obtain the probability whether a
property it could be satisfied by the analyzed model, more in general, when an event
occurs. This operator is applicable to every kind of models supported by PRISM.
An example of the syntax of the operator P is
Pboundrevents
This property is true if, the algorithm eventually reaches the event successfully with
probability bound.
An example of bound is, if it can be greater than 0.70, and the syntax to describe
this is:
P ą 0.70revents
and it means that the algorithm eventually reaches the event successfully with
probability 0.70.
Non-determinism For probabilistic models such as DTMCs and CTMCs, proba-
bility measures over paths are well defined, for non-deterministic models a probability
measure can only be defined only if all non-determinism has been removed.
For probabilistic/non-deterministic model such as MDPs or PTAs, is necessary
specify something more, for example, the actual meaning of the property P bound
[ pathprop ] in these cases is: "the probability that pathprop is satisfied by the
paths from state s meets the bound bound for all possible resolutions of non-
determinism". This means that, properties using the P operator then effectively
reason about the minimum or maximum probability, over all possible resolutions of
non-determinism, that a certain type of behavior is observed. This depends on the
bound attached to the P operator: a lower bound (> or >=) relates to minimum
probabilities and an upper bound (< or <=) to maximum probabilities.
Quantitative properties Quantitative approach to probabilistic model checking
is very often useful, for example, to compute the actual probability that some
behavior of a model is observed, rather than just verifying whether or not the
probability is above or below a given bound.
PRISM allows the P operator to take the following form:
P=? [ pathprop ]
¥

These properties return a numerical rather than a Boolean value.
For nondeterministic models (MDPs or PTAs), either minimum or maximum proba-
bility values can be computed. Therefore, in this case, we have two possible types of
property:
Pmin=? [ pathprop ]
Pmax=? [ pathprop ]
¥
which return the minimum and maximum probabilities, respectively. It is also
possible to specify to which state the probability returned by a quantitative property
refers.
Path properties PRISM supports a wide range of path properties that can be
used with the P operator. A path property is a formula that evaluates to either true
or false for a single path in a model.
In the next paragraphs are explained some of the simpler properties.
"Next" path properties The property X prop is true for a path if prop is
true in its second state. An example of this type of property, used inside a P operator,
is:
P<0.01 [ X y=1 ]
¥
which is true in a state if "the probability of the expression y=1 being true in the
next state is less than 0.01".
"Until" path properties The property prop1 U prop2 is true for a path if
prop2 is true in some state of the path and prop1 is true in all preceding states. A
simple example of this would be:
P>0.5 [ z<2 U z=2 ]
¥
which is true in a state if "the probability that z is eventually equal to 2, and that z
remains less than 2 up until that point, is greater than 0.5".
"Eventually" path properties The property F prop is true for a path if
prop eventually becomes true at some point along the path. The F operator is in
fact a special case of the U operator (you will often see F prop written as true U
prop). A simple example is:
P<0.1 [ F z>2 ]
¥
which is true in a state if "the probability that z is eventually greater than 2is less
than 0.1".
"Globally" path properties Whereas the F operator is used for "reachability"
properties, G represents "invariance". The property G prop is true of a path if prop
remains true at all states along the path. Thus, for example:
P>=0.99 [ G z<10 ]
¥
states that, with probability at least 0.99, z never exceeds 10.

2.3. PRISM 29
"Weak until" and "release" path properties Like F and G, the operators
W and R are derivable from other temporal operators. Weak until (a W b), which
is equivalent to (a U b) | G a, requires that a remains true until b becomes true,
but does not require that b ever does becomes true (in other words a remains true
forever). For example, a weak form of the until example used above is:
P>0.5 [ z<2 U z=2 ]
¥
which states that, with probability greater than 0.5, either z is always less than 2, or
it is less than 2 until the point where z is 2. Release (a R b), which is equivalent to
!(!a U !b), informally means that b is true until a becomes true, or b is true forever.
"Bounded" variants of path properties All of the temporal operators given
above, with the exception of X, have "bounded" variants, where an additional time
bound is imposed on the property being satisfied. The most common case is to use
an upper time bound, in other words, the form "<=t" or "<t", where t is a PRISM
expression evaluating to a constant, non-negative value. For example, a bounded
until property prop1 U<=t prop2, is satisfied along a path if prop2 becomes true
within t steps and prop1 is true in all states before that point. A typical example of
this would be:
P>=0.98 [ y<4 U<=7 y=4 ]
¥
which is true in a state if "the probability of y first exceeding 3 within 7 time units
is greater than or equal to 0.98". Similarly:
P>=0.98 [ F<=7 y=4 ]
¥
is true in a state if "the probability of y being equal to 4 within 7 time units is
greater than or equal to 0.98" and:
P>=0.98 [ G<=7 y=4 ]
¥
is true if the probability of y staying equal to 4 for 7 time units is at least 0.98.
Transient probabilities We can also use the bounded F operator to refer to
a single time instant, for example:
P=? [ F [ 1 0 , 1 0 ] y=6 ]
¥
or, equivalently:
P=? [ F [ 1 0 , 1 0 ] y=6 ]
¥
both of which give the probability of y being 6 at time instant 10.

Part II
Extending ASMETA with the
probabilistic model checking
31

Chapter 3
AsmetaF: a flattener for the
ASMETA framework
The ASMs have shown to be a suitable high-level specification method for
complex, even industrial, systems; the ASMETA framework, supporting several
validation and verification activities on ASM models, is an example of a formal
integrated development environment, as said in 1.1. Although ASMs allow modeling
complex systems in a rather concise way, and this is advantageous for specification
purposes, such concise notation is in general a problem for verification activities as
model checking and theorem proving that rely on tools accepting simpler notations.
To resolve this point we design and develop an ASMETA tool for doing a particular
kind of refactoring, namely a rules flattening, and terms and rules simplifying of
the code; it transforms general ASM models into a flattened ones only composed
by update, parallel, and conditional rules. Flattened models usage makes easier
the syntax mapping process to other verification tools language, in section 5 some
experiments on representative case studies of the ASMETA repository are shown to
explain advantages and disadvantage of applying this tool.
Performing a flattening phase in order to simplify the model is a rather common
activity, others related work are:
• [Dev+15], the authors make an overview of flattening transformations for state
machines.
• [Win97] is in the context of the ASMs, and the authors proposed some ad-hoc
transformations for mapping ASMs to SMV models;
• [YSFG12] the authors identified a number of refactoring patterns to restructure
ASM models with the goal of improving their intelligibility and maintainability.
Motivation
Syntax Expressiveness ASMs use a plain mathematical notation to model
a system configuration (i.e., a state) in terms of a mathematical algebra, and use a
set of powerful rule constructors to specify system behavior (i.e., state transitions).
ASMs provide, therefore, a powerful language that permits to describe complex
systems in a rather concise way. Although it is an advantage when modeling, this
notation conciseness can be a problem for tools integration: target languages have
33

34CHAPTER 3. ASMETAF: A FLATTENER FOR THE ASMETA FRAMEWORK
their own syntax and semantics, and translating an ASM to a target model by
maintaining the intended computational model is not a trivial work; moreover, ASM
specifications must often be translated to less expressive languages, and implementing
these transformation tools is rather complicated, as the semantics of the complex
rule constructors of the ASM language must be taken into account and guaranteed.
Past Experiences In the past, different mappings have been developed to:
• SPIN [GRR03];
• NuSMV [AGR10];
• SMT solvers [AGR18; AGR16];
• C++ code [Bon+17].
All these target notations, although can in principle represent the same class of
systems as ASMs, have syntaxes that are very different from the ASM notation, with
less expressive constructs; therefore, the integration of these tools into ASMETA
usually supports only specific classes of ASMs. Some constructs of the ASM formalism
are indeed difficult to translate in the target notation, and, although possible, we did
not implement such translations because too much complex (e.g., the mappings to
model checkers NuSMV and SPIN do not support variable arguments in functions).
On the other hand, we observe that tools integrated into ASMETA usually perform
similar pre-processing of supported ASM constructs (e.g., translation of unbounded
parallelism of the forall rule is usually implemented by an unfolding), and that this
pre-processing could be extracted from the integrated tools and made separately
available for all the integrations.
This necessity is again confirmed by AsmetaPrism, as we see in the Chapter 4
in which instead of trying to directly map any ASM in PRISM (that provides an
extremely limited language), it would have been better to go through a simpler, but
still equivalent, ASM that uses a limited set of ASM constructs. Such simpler ASM
would have been as the result of the pre-processing phase of other integrated tools.
Normal form In order to simplify the porting of ASMs towards other modeling
languages, to reuse tools for model validation and verification, and to foster tool
integration into the ASMETA framework, in flattener (AsmetaF) we have the
following concept, given an ASM model M, it produces an equivalent model Mf
that only contains update, conditional and parallel rules; we consider the Mf model
to be in a normal form. The idea is that translating the normal form to the target
languages of verification frameworks (e.g., NuSMV, SMT-LIB) or code is much easier
than considering ASMs containing any possible construct.
Application AsmetaF is currently used in AsmetaPrism and AsmetaSMV,
this latter one is used to map into nuSMV model checker, for exploiting its properties
verification; this has allowed us to support a wider set of specifications, namely those
having variable function arguments. In the future, we plan to integrate it in all the
exiting verification tools of the ASMETA framework and to use it as pre-processing
step in future integrated tools requiring flattening.
This Chapter is organized as follows. Sect. 3.1 introduces the flattener transfor-
mations, Sect. 3.2 discusses how we validated the approach, and Sect. 3.3 describes

3.1. FLATTENER RULE REMOVERS AND TERMS SIMPLIFIER 35
signature:
rule r(v1 in D1, . . .,vn in Dn) =
R[v1,...,vn]
. . .
r[t1,...,tn] //macro call rule
¥
//Macro rule r is removed
R[v1 ÞÑ t1, . . ., vn ÞÑ tn]
¥
definitions:
rule rAgentKind = R[self]
. . .
//a is an AgentKind agent
program(a)
. . .
agent AgentKind: rAgentKind[]
¥
//Macro rule rAgentKind is removed
R[self ÞÑ a]
//Program declaration for AgentKind is
removed
¥
Code 1: Macro Call rule Remover
some preliminary experiments.
3.1 Flattener rule removers and terms simplifier
In order to improve tools integration in ASMETA and to overcome some limits
due to the high level and concise mathematical notation of the ASMs with respect
to less expressive (in terms of conciseness) formalisms of the integrated tools, we
developed a flattener. Given an ASM M written in general form i.e., containing any
kind of rule and any level of nesting, the flattener produces an ASM Mf in normal
form (if all the flattener transformation rules are applied). An ASM is in normal
form if, in the main rule, it only contains a parallel rule composed of a set of update
rules and conditional rules (without else branch); each conditional rule must contain
either an update rule or a parallel of update rules.
The flattener applies a series of transformations described in the following.
MCR: Macro Call rule Remover A macro rule is a named rule r with some
formal parameters v1, . . . , vn, and a rule body R defined in terms of the parameters.
A macro call rule is an invocation of rule r with actual parameters t1, . . . , tn. The
flattener transformation MCR replaces each occurrence of a call rule r with the macro
rule body R; occurrences of formal parameters in the rule are replaced by the actual
parameters used in the macro call rule.
In multi-agent ASMs, given a specific set AgentKind of Agent, a macro rule
rAgentKind specifies the program of all agents in AgentKind, and, by the keyword
program, it is possible to invoke the program of an agent a in AgentKind; in rule
rAgentKind, the keyword self is used to reference the current agent executing the
rule. MCR flattens also program invocations; an invocation programpaq is replaced
with the rule R (body of the agent rule), where each occurrence of self is replaced
with a.
At the end, all the macro rules declared in the ASM model are removed.
FR: Forall rule Remover In a forall rule, the rule R is executed in parallel with all
the values of variables v1, . . . , vn satisfying the guard. The flattener transformation
FR, for each combination d “ pd1, . . . , dnq of values of the domains D1, . . . , Dn of

forall v1 in D1, . . ., vn in Dn
with guard[v1, . . ., vn] do
R[v1, . . ., vn]
¥
par
if guard[v1 ÞÑ d1
1, . . ., vn ÞÑ d1
n] then
R[v1 ÞÑ d1
1, . . ., vn ÞÑ d1
n]
endif
...
if guard[v1 ÞÑ dm
1 , . . ., vn ÞÑ dm
n ] then
R[v1 ÞÑ dm
1 , . . ., vn ÞÑ dm
n ]
endif
endpar
¥
Code 2: Forall rule Remover
choose v in D with guard[v] do
R[v]
ifnone Rnone
¥
function fchoose =
chooseone({v in D | guard[v] ) : v})
if isDef(fchoose) then
R[v ÞÑ fchoose]
else
Rnone
endif
¥
Code 3: Choose rule Remover
the variables, builds a conditional rule (without else branch)1. The guard of the
conditional rule is that of the forall rule, instantiated over values d (i.e., variables
v1, . . . , vn are replaced by values d1, . . . , dn); in a similar way, the rule in the then
branch is the rule R of the forall body instantiated over d.
ChR: Choose rule Remover In a choose rule, the rule R is executed once with
a value of v, nondeterministically chosen, that satisfies guard. If such value does
not exist, the choose rule does nothing. The flattener transformation ChR embeds
the non-deterministic choice in a derived function fchoose that randomly selects one
of the values of the choose domain; the rule is replaced by a conditional rule that
checks whether fchoose is defined (i.e., it is possible to select a value from the domain)
and, if so, calls the body R of the choose rule instantiated over fchoose. In a choose
rule, it is also possible to specify a rule Rnone that must be executed when no choice
can be performed; in the flattened version, this rule is reported in the else branch.
AR: Arguments Remover In ASMs, function locations are identified at runtime
by interpreting the terms used as function arguments. Such feature is usually
particularly difficult to handle in target notations; NuSMV, for example, allows
to specify arrays (that could be used to model functions), but does not allow to
dynamically accessing them. Therefore, the flattener transformation AR removes
terms used as function arguments and replaces them by suitable let rules; let rules
can then be flattened by the flattener transformation LR.
LR: Let rule Remover A let rule associates logical variables v1, . . . , vn to terms
t1, . . . , tn; the rule body R is defined in terms of the variables. The flattener
1
Note that in AsmetaL the domains of a forall rule are required to be finite and so the number
of generated conditional rules will be finite.

3.1. FLATTENER RULE REMOVERS AND TERMS SIMPLIFIER 37
f(t1, . . ., tn)
¥
let (v1 = t1, . . ., vn = tn) in
f(v1, . . ., vn)
endlet
¥
Code 4: Arguments Remover
let (v1=t1, . . ., vn=tn) in
R[v1, . . ., vn]
endlet
¥
par
if t1 = d1
1 and . . . and tn = d1
n then
R[v1 ÞÑ d1
1, . . ., vn ÞÑ d1
n]
endif
. . .
if t1 = dm
1 and . . . and tn = dm
n then
R[v1 ÞÑ dm
1 , . . ., vn ÞÑ dm
n ]
endif
endpar
¥
Code 5: Let rule Remover
signature:
switch(t)
case t1: R1
. . .
case tn: Rn
endswitch
¥
par
if t = t1 then R1 endif
. . .
if t = tn then Rn endif
endpar
¥
definitions:
switch(t)
case t1: R1
. . .
case tn: Rn
otherwise Ro
endswitch
¥
par
if t = t1 then R1 endif
. . .
if t = tn then Rn endif
if t != t1 and . . . and t != tn then Ro endif
endpar
¥
Code 6: Case rule Remover
transformation LR removes the rule by considering all the possible values assumed
by the terms; for each combination d “ pd1, . . . , dnq of values of the terms domains,
a conditional rule is created: the guard checks whether the terms assume the values
in d, and the then rule is the rule body R of the let rule, instantiated over d.
In the code 5, we have D1, . . ., Dn are the domains of t1, . . . , tn and (d1
1,. . .,d1
n),
. . . , (dm
1 , . . ., dm
n ) P D1 ˆ . . . ˆ Dn with m “
śn
j“1 |Dj|
CaR: Case rule Remover In a case rule, a term t is compared with some terms
t1, . . . , tn; each term ti is associated with a rule Ri that is executed if t evaluates as
ti. An optional otherwise branch can specify a rule Ro to execute when t is different
from all the compared terms. The flattener transformation CaR introduces a parallel
of conditional rules, one for each branch; a conditional rule checks whether the term
t is equal to ti and executes the corresponding rule Ri in the then branch. An
additional conditional rule is added if the otherwise branch is present.
NR: Nesting Remover A nested conditional rule is replaced by parallel conditional
rules, by unfolding the rules and aptly combining their guards.

if guard1 then
par
R1
if guard2 then Rt
else Re endif
endpar
endif
¥
Code 7: Nesting Remover: Original ASM
par
if guard1 then R1 endif
if guard1 and guard2 then Rt endif
if guard1 and not(guard2) then Re endif
endpar
¥
Code 8: Nesting Remover: Flattened ASM
Code 9: Case rule Remover
asm PetriNet_flat
signature:
abstract domain Place
abstract domain Transition
domain TokenDomain setof Integer
controlled tokens : Place ´> TokenDomain
static incidenceMatrix: Prod(Place, Transition) ´> TokenDomain
...
derived chooseVar0: Transition
definitions:
domain TokenDomain = {0 .. 5}
function incidenceMatrix($p in Place, $t in Transition) =
outArcWeight($t, $p) ´ inArcWeight($p, $t)
...
function chooseVar0 = chooseone({$t in Transition| isEnabled($t) : $t})
main rule r_Main =
main rule r_Main =
par
if and(isDef(chooseVar0),eq(chooseVar0,t2)) then
tokens(p1) := plus(tokens(p1),incidenceMatrix(p1,t2))
endif
if and(isDef(chooseVar0),eq(chooseVar0,t1)) then
tokens(p1) := plus(tokens(p1),incidenceMatrix(p1,t1))
endif
...
default init s0: ...
¥
Code 10: Excerpt of the flattened model of an ASM model
Simplifier Applying the previous flattener transformations could produce some
terms only containing constants; such terms can be evaluated statically at parsing
time. Therefore, in order to avoid unnecessary rules in the flattened models, after
the application of a flattener transformation, we apply two simplifiers:
• TS visits all the terms and, if possible, evaluates them or simplifies them; for
example, a function term andpa, trueq is simplified to a, 3 ă 4 is simplified to
true, 2 ` 1 is simplified to 3, and so on; TS can simplify logical, mathematical,
and relational terms;
• RS visits all the rules and, if possible, removes or simplifies them; for example
a conditional rule with guard equal to true is replaced with its then rule.
Code 10 reports an excerpt of the model obtained by the flattening process.

3.2. VALIDATION OF THE APPROACH 39
Application order of flattener transformations All the flattener transforma-
tions are applied in the order in which they have been presented.
1. MCR
2. FR
3. ChR
4. AR
5. LR
6. CaR
7. Simplifier
The order guarantees that no construct that should be flattened is not. Indeed,
a transformation could introduce some constructs that are further flattened by
another one; namely, LR must be executed after AR because AR introduces let rules
that are then flattened by LR; in a similar way, NR must be applied after all the
other transformations because it must remove the nesting they introduce. However,
the chosen order is not the only possible; indeed, although there are couples of
transformations that must be executed in a given order, the order of other couples
could be exchanged. We will discuss about the best order in the experiments (see
RQ1 in Sect. 3.3).
Tool implementation The flattener has been implemented in the tool AsmetaF.
The tool has been designed in a modularized way such that the user can decide
which flattener transformations to apply; in some cases, it may be not necessary to
flatten all the ASM constructs, as some of them could be natively supported by the
target language. For example, a programming language as C supports nesting, and
so it is not necessary to remove it. The tool is meant to be used as pre-processing
step of other tools. However, we provide a standalone version for demonstration
purposes.2
3.2 Validation of the approach
The proposed flattener transformations preserve the ASM semantics; however, it
could be that their implementation in AsmetaF is not correct. In order to guarantee
the correctness of AsmetaF, we should prove semantic equivalence between original
and flattened models, but this is in general difficult to achieve. Therefore, we perform
two kinds of validation:
• syntactic validation, we simply check whether the produced flattened ASM
is syntactically correct, i.e., it can be parsed correctly by the ASMETA parser.
• semantic validation, we try to check that the semantics of the model is
preserved; we do this by model checking and scenario-based validation.
By means of the AsmetaSMV tool, we check that the temporal properties specified
in the original model are evaluated in the same way in the two models (either both
models prove the property or falsify it). The tool AsmetaV, instead, allows to write
scenarios (similar to test cases) that drive the model simulation and check that
the ASM state (values of controlled locations) is as expected; we run the scenarios
2
A jar file of the tool can be downloaded from https://goo.gl/vShfbJ

Rule
Model Update Parallel Conditional Forall Choose Case Let MacroCall All
CoffeeVendingMachine 2 1 3 0 1 0 0 2 9
DijkstraTermination 9 6 8 1 3 0 0 9 36
ferrymanSimulator_raff1 5 1 3 0 0 0 0 2 11
GameOfLife 2 0 3 1 0 0 0 1 7
GilbreathCardTrick 15 5 7 2 3 1 0 9 42
HemodialysisRef3 146 78 228 1 0 0 0 192 645
LandingGearSystem_3L 38 15 9 0 0 5 0 4 71
OneWayTrafficLight 5 9 8 0 0 0 0 16 38
PetriNet 1 0 0 1 1 0 0 1 4
philosophers1 6 3 4 0 1 0 0 3 17
Roulette 4 2 3 0 1 0 0 4 14
SluiceGateMotorCtl 9 7 8 0 0 0 0 4 28
StereoacuityRaff5 20 6 11 0 0 0 0 15 52
AVG 20.15 10.23 22.69 0.46 0.77 0.46 0 20.15 74.92
Table 3.1: Benchmarks size
written for the original model also on the flattened model and we expect that it
passes them.
Future work We plan to devise a more systematic way to perform validation.
For example, we could automatically produce scenarios achieving rule coverage of
the original model and of the target model: the target model should pass all the
scenarios generated for the original one (to check that the flattener preserves the
behavior), and the original model should pass all the scenarios generated for the
target one (to check that the flattener does not introduce additional behaviors).
3.3 Experiments
We applied all the transformations to 13 representative models of the ASMETA
repository3 as, for example, a Landing Gear System [AGR17], a hemodialysis
device [Arc+18], a device for measuring amblyopia, and a termination detection
algorithm by Dijkstra (from Dagstuhl Seminar 133724). Note that some of the
case study models were obtained by refinement and we took the last refined model.
Table 3.1 reports, for all the models, the number of their rules. The table also
reports, for each kind of rule, the average number among the models. We observe
that the update, the conditional, and the macro call rules are the most used ones.
Which are the most applied flattener transformations? We are here inter-
ested in finding which are the transformations that are applied more often. Table 3.2
reports how many times each transformation is applied to each model. Since MCR is
used at the beginning, it is applied exactly the same number of times as the number
of macro call rules (see Table 3.1); note that, although MCR could be applied at any
stage during the flattening process, it makes sense to use it at the beginning since it
3
All the original and the flattened models, together with the scenarios used for validation, are
available at http://fmse.di.unimi.it/sw/FIDE2018AsmetaF.zip
4
https://www.dagstuhl.de/de/programm/kalender/semhp/?semnr=13372

3.3. EXPERIMENTS 41
Flattener transformation
Model MCR FR ChR AR LR CaR NR
CoffeeVendingMachine 2 0 1 1 1 0 2
DijkstraTermination 9 1 18 12 42 0 5
ferrymanSimulator_raff1 2 0 0 3 9 0 2
GameOfLife 1 1 0 0 0 0 2
GilbreathCardTrick 9 4 3 50 50 1 4
HemodialysisRef3 192 1 0 0 0 0 8
LandingGearSystem_3L 4 0 0 0 0 6 4
OneWayTrafficLight 16 0 0 12 20 0 1
PetriNet 1 1 1 4 4 0 1
philosophers1 3 0 1 10 5414 0 2
Roulette 4 0 1 1 1 0 3
SluiceGateMotorCtl 4 0 0 4 4 0 1
StereoacuityRaff5 15 0 0 0 0 0 6
AVG 20.15 0.62 1.92 7.46 426.54 0.54 3.15
Table 3.2: Applied flattener transformations
is applied so many times (it is the second most used transformation). Applying it
after some other transformations (e.g., FR) would probably increase even more the
number of times it is used.
The most used transformation is LR; although the original models do not contain
any let rule, these are introduced by AR. Note that in some models (e.g., philosophers1)
the number of applications of LR is much higher than that of AR, because the let
rules are nested: during the flattening, the inner let rule is visited as many times as
the number of conditional rules created by outer let rule.
The value reported for NR is the difference between the maximum nestings of the
starting model and of the flattened one (i.e., it indicates how many nesting levels
have been removed). We observe that, on average, 3.15 levels of nesting are removed,
meaning that the developers tend to write quite nested models.
Which is the effect of flattening? We are now interested in evaluating the
effect of applying the flattener to the models. Table 3.3 reports the size of the
flattened models in terms of number of update, parallel, and conditional rules. The
table also reports the total number of rules and their percentage change w.r.t. the
original model (∆). We can observe that usually the flattened model has many
more rules. The model that has the greatest increment in the number of rules is
philosophers1; indeed, the model has several dynamic function arguments that, when
flattened by AR and LR, produce several rules (see Table 3.2).
However, there are also some models for which the number of rules is similar or
also decreases; by inspecting these models we can observe that they are already quite
flatten: for example, the original model of HemodyalisisRef3 already contains almost
only update, parallel, and conditional rules (see Table 3.1), and the application of
the flattener has the effect of reducing the conditional rules by merging some of

Rule
Model Update Parallel Conditional All ∆ %
CoffeeVendingMachine 6 2 5 13 44%
DijkstraTermination 276 13 252 541 1403%
ferrymanSimulator_raff1 145 1 145 291 2545%
GameOfLife 32 1 32 65 829%
GilbreathCardTrick 900 2 898 1800 4186%
HemodialysisRef3 214 54 154 422 -35%
LandingGearSystem_3L 46 19 18 83 17%
OneWayTrafficLight 72 9 56 137 261%
PetriNet 8 1 8 17 325%
philosophers1 118800 1 118800 237601 1397553%
Roulette 5404 2703 2702 10809 77107%
SluiceGateMotorCtl 20 9 8 37 32%
StereoacuityRaff5 30 7 16 53 2%
AVG 9688.69 217.08 9468.77 19374.54 25759%
Table 3.3: Size of the flattened models
them through NR (see Table 3.2).
We can interpret ∆ as an index of the conciseness of the model: the higher
∆ is, the more concise the original model is. Indeed, a very concise model (as
philosophers1) specifies, by using few powerful rules, a complex behavior; when
flattened, this results in a big number of rules.
Does the simplification have any effect? We here check if the simplification
of terms and rules (embedded in all the flattener transformations) has some effect.
Table 3.4 reports, for each model, the number of simplifications performed by the two
simplifiers. We observe that, for more than half of the models, the simplifications
are actually applied. For example, in the flattening of OneWayTrafficLight and
philosophers1, several terms are simplified; this is due to the fact that both models
contain several guards of conditional rules that depend on functions with dynamic
arguments. When these arguments are flattened by AR and LR, some resulting
guards can be simplified by TS either to true or to false; as a consequence of the
simplifications of guards, some conditional rules can be simplified by RS, either by
removing them (if the guard is false) or by replacing them with the then branch (if
the guard is true).
Which is the computational effort required by the flattener? We are here
interested in knowing which is the computational effort required by the tool. We
performed 100 executions of the flattener over all the models on a macOS machine,
3.1 GHz Intel Core i5, and 16GB. Table 3.5 reports, for each model, the average
time (in seconds) taken by the flattener, and the average time among models. We
observe that for almost all models the execution time is less than 1.5 secs. We can
notice that the model for which it takes longer (59.93 secs for philosophers1) is a

3.3. EXPERIMENTS 43
Simpliiifier
Model TS RS
CoffeeVendingMachine 0 0
DijkstraTermination 0 0
ferrymanSimulator_raff1 1 1
GameOfLife 0 0
GilbreathCardTrick 12 0
HemodialysisRef3 0 0
LandingGearSystem_3L 0 0
OneWayTrafficLight 96 16
PetriNet 0 0
philosophers1 20102 1802
Roulette 37 37
SluiceGateMotorCtl 2 2
StereoacuityRaff5 0 1
Table 3.4: Applied simplifications
Model Time (sec)
CoffeeVendingMachine 0.01
DijkstraTermination 0.11
ferrymanSimulator_raff1 0.08
GameOfLife 0.02
GilbreathCardTrick 0.37
HemodialysisRef3 0.94
LandingGearSystem_3L 0.03
OneWayTrafficLight 0.04
PetriNet 0.01
philosophers1 59.93
Roulette 1.36
SluiceGateMotorCtl 0.01
StereoacuityRaff5 0.06
AVG 4.84
Table 3.5: Execution time of the flattener
very concise model that has been flattened a lot (see Tables 3.2 and 3.3).

Chapter 4
AsmetaPRISM: Probabilistic
Model Checking in ASMETA
As said in Chapter 2, PRISM is a probabilistic model checker that allows to
model probabilistic behaviors by labeling the model transitions with the probability
that they occur, and to verify probabilistic properties on the models. ASMETA,
at the moment, only supports classic model checking (by means of the NuSMV
model checker), and so it does not allow to model and verify probabilistic behaviors;
therefore, it can only verify qualitative properties, i.e., properties that can check
only whether an event can occur or not (they are either true or false). The goal of
AsmetaPRISM is to extend ASMETA with the probabilistic model checking features
of PRISM1, in particular regarding the verification of quantitative properties on
probabilistic models; for doing this, we have exploited AsmetaF, that let us to
overcome the issues about the differences between the syntaxes of these languages,
providing a flattened and simplified model with just three kinds of rules (conditional,
update and block rules) and without rules nesting. After that, starting from this
simple form of ASM, we have designed and developed a syntax translation, in which
the semantic of the original model is totally preserved.
In the following sections, the translation algorithm behind AsmetaPRISM is ex-
plained, with a particular focus on the aspects that come from the non-deterministic
rules of ASMETA, and then all the aspects that concern the verification of proba-
bilistic properties.
4.1 AsmetaPRISM in the ASMETA framework
In the ASMETA framework, there are three different categories of tools, as
seen in Chapter 1. AsmetaPRISM is in the category that concerns Validation and
Verification of code; indeed the goal of this project is to extend the ASMETA support
for verification, introducing the probabilistic verification, i.e., the verification of
quantitative properties in models that have probabilistic behaviors.
In the Figure 4.1, is shown the ASMETA toolset with the addition of As-
metaPRISM; indeed, the goal of this project is extending ASMETA with probabilis-
tic verification, i.e., the verification of quantitative properties in models that have
1
http://www.prismmodelchecker.org/
45

46CHAPTER 4. ASMETAPRISM: PROBABILISTIC MODEL CHECKING IN ASMETA
probabilistic behaviors.
Figure 4.1: ASMETA toolset - validation and verification
4.2 Mapping ASMETA models to PRISM models
As a starting point, we have a model flattened by AsmetaF; This model is
obtained by applying all the flatteners and is presented in a normal form as in Figure
4.2.
Figure 4.2: Rule relations in the normal form
The Figure 4.2 shows the relations between the rules in the normal form; the
arrows must be intended as the "contains" relation: for example, a Conditional Rule
can contain an Update Rule, a Block Rule of Update Rule, or a Skip Rule. In
this figure, there are two notes. The first note is for noticing that Block Rule for
Conditional Rule can contain Conditional Rules and Update Rules, and at least two
rules, for definition of Block Rule. The second note is for remarking that Block Rule
for Update Rule can contain only Update Rule; this distinction between these two
Block Rule is necessary to avoid rule nesting.
A PRISM model is basically composed of only variables and transitions, and
it is similar to the normal form provided by AsmetaF, that contains only updates,
conditional and block rules. Therefore, for the mapping process, we start from a
normal form provided by AsmetaF (an example of normal form is shown in code
11), and we obtain a semantic equivalent PRISM model. For doing this we need to
map: domains, functions, rules and all the other aspects necessary for keeping the
semantic of the ASMETA model.

Formal Verification of Probabilistic Systems in ASMETA

Formal Verification of Probabilistic Systems in ASMETA

Recommended

Recommended

More Related Content

What's hot

What's hot (15)

Similar to Formal Verification of Probabilistic Systems in ASMETA

Similar to Formal Verification of Probabilistic Systems in ASMETA (20)

Recently uploaded

Recently uploaded (20)

Formal Verification of Probabilistic Systems in ASMETA