Transcript Timed-Rebeca Schedulability and Deadlock

Performance Analysis of Distributed
and Asynchronous Systems using
Probabilistic Timed Actors
Ali Jafari
Ehsan Khamespanah
Marjan Sirjani
Holger Hermanns
Reykjavik University, Iceland
University of Tehran, Iran
Saarland University, Germany
September 2014
Outline
Characteristics of systems
 Joining model checking and performance
evaluation
 Actor model
 Rebeca language
 PTRebeca language

◦ Syntax
◦ Semantics

Case study
2
Questions

System nowadays?

What kind of analysis?

Why actors? Why Rebeca?
3
Distributed Systems are
Everywhere
Aircraft control systems
 Multiplayer online games
 Distributed information processing
systems such as banking systems
 Embedded systems and pervasive
computing are widely used
 Distributed systems in stock exchange
market and other financial systems

4
Systems nowadays
Concurrent
 Event-based
 Based on message passing
 They are distributed over the network

Systems are becoming more and more
complex
 Timing and probability aspects are
becoming more and more important.

5
Complicated systems !
Concurrency
 Probabilistic behaviors
 Real-time aspects
 Asynchronous communication

6
Questions

System nowadays?

What kind of analysis?

Why actors? Why Rebeca?
7
Questions to answer

Are our systems functionally correct?
◦ Formal verification
 Model checking
 Theorem proving

Are they performing well enough?
◦ Mathematical analysis
◦ Numerical evaluation
◦ Discrete-event simulation
8
Combining model checking and
performance evaluation

A single model for both types
of analysis

Stochastic model checking
◦ Includes quantitative aspects like
timing and random phenomena

Recently proposed approach:
Performance Evaluation and Model Checking Join Forces
Baier, Haverkort, Hermanns, Katoen
Communications of the ACM, 2010
9
Questions

System nowadays?

What kind of analysis?

Why actors? Why Rebeca?
10
Actors
◦ A reference model for concurrent
computation
◦ Consisting of concurrent, distributed active
objects
Proposed by Hewitt as an agent-based
language (MIT, 1971)
Developed by Agha as a concurrent objectbased language (UIUC, since 1984)
Formalized by Talcott (with Agha, Mason and
Smith): Towards a Theory of Actor
Computation (SRI, 1992)
11
Applications of Actors

Transaction processing systems
◦ Payment systems (serving POS device, ATM
request)
◦ Stock market agents
Twitter’s message queuing
 Image processing in MS Visual Studio
library
 Vendatta game engine

12
Rebeca: The Modeling Language

Reactive object language
(Sirjani-Movaghar, Sharif U. of Technology, 2001)

Imperative Actor-based language
◦ Concurrent reactive objects (OO)
◦ Java like syntax
◦ Simple core
13
Rebeca Example
Example of a ticket service system
 A Customer wants to buy a ticket

14
Ticket Service model
reactiveclass TicketService {
reactiveclass Customer {
knownrebecs {
Agent a;
}
Actor type and
statevars {
its message
int issueDelay;
servers
}
msgsrv initial() {}
msgsrv requestTicket() {
a.ticketIssued(1);
}
knownrebecs {
Agent a;
}
msgsrv initial() {
Asynchronous
self.try();
message sending
}
msgsrv try() {
a.giveTicket();
}
msgsrv ticketReady(byte id) {
self.try();
}
}
reactiveclass Agent {
knownrebecs {
TicketService ts;
Customer c;
}
msgsrv giveTicket() {
ts.requestTicket();
}
msgsrv ticketIssued(byte id) {
c.ticketReady(id);
}
}
}
main {
Agent a(ts, c):();
TicketService ts(a):();
Customer c(a):();
}
Instances of
three different
actors
15
Analysis Facilities

Model checking toolset was developed.
◦ Automatic deadlock and queue size analysis
◦ CTL and LTL model checking

Also some reduction techniques.
◦ Atomic execution are used to reduce the size
of the state space
◦ Partial order and symmetry reductions
16
Probabilistic Timed Rebeca

An extension of Timed Rebeca for
modeling probabilistic real-time systems.
◦ Probabilistic assignment (behavior)
◦ Non-deterministic assignment (behavior)
◦ Timing behavior (deterministic, nondeterministic, probabilistic)
17
Probabilistic Timed Rebeca Example
Example of a ticket service system
 A Customer wants to buy a ticket

◦ There are time constraints for issuing ticket
Agent
Request maybe
lost
Customer
Ticket Service
Issuing a ticket takes
3 or 4 units of time
Ticket Service Model
msgsrv ticketIssued(byte id) {
c.ticketIssued(id);
}
reactiveclass TicketService {
knownrebecs {
Agent a;
Probabilistic
}
statevars {
assignment for
int issueDelay; Issuing ticket time
}
msgsrv requestTicket() {
int issueDelay =?(0.3:3,0.7:4);
delay(issueDelay);
a.ticketIssued(1);
}
}
reactiveclass Agent {
}
reactiveclass Customer {
knownrebecs {
Agent a;
}
msgsrv initial() {
self.try();
}
msgsrv try() {
a.requestTicket();
}
msgsrv ticketIssued(byte id) {
\\ customer happy
int a = ? (30,35);
self.try() after(a);
}
Probabilistic
assignment for
missing a request
knownrebecs {
TicketService ts;
Customer c;
}
msgsrv requestTicket() {
boolean lost = ?(0.05:true,0.95:false);
if(!lost)
ts.requestTicket() deadline(5);
}
}
main {
Non-deterministic
periodic task
Agent a(ts, c):();
TicketService ts(a):();
Customer c(a):();
}
19
Timed Markov Decision Process

A timed Markov decision process is
T = (S, s0 , Act,, L)
◦ A set of states S with an initial state s 0
◦ A set of actions Act,
◦ A timed probabilistic, non-deterministic transition
relation  S  Act  N  Dist(S)
such that, for each state, s  S there exists at least
one tuple (s, act, d , ) 
AP
◦ A labeling function L : S  2
20
Semantics of a simple PTRebeca model
Timed Markov Decision Process
reactiveclass RC1 (3) {
knownrebecs {
RC2 r2;
}
}
RC2() {
msgsrv m1( ) {
1delay(3);
}
self.m2();
}
RC1() {
msgsrv m2() {
self.m1();
int a=?(0.2:2,0.8:4);
}
}
delay (a);
msgsrvm2()
m1(){ {
msgsrv
delay(3);
1int a=?(0.2:2,0.8:4);
2-}
delay (a);
}
}
msgsrv m3() { }
}
main {
reactiveclass RC2 (4) {
RC1 r1(r2):();
knownrebecs {
RC1 r1;
RC2 r2(r1):();
}
TMDP of The Simple Model
msgsrv m1( ) {
1delay(3);
}
msgsrv m2() {
1int a=?(0.2:2,0.8:4);
2delay (a);
}
22
Transitions in TMDP
Taking a message from queue to be
executed
 Progress of Time
 Internal action 𝝉

◦
◦
◦
◦
Ordinary statement
Non-deterministic assignment
Probabilistic assignment
Delay statement
Performance analysis of PTRebeca
models



PTRebeca can be verified against properties
specified in PCTL.
The TMDP semantics of PTRebeca model is
equal to the discrete-time semantics of a PTA
with digital clocks.
Two classes of properties for PTAs with digital
clocks.
◦ Probabilistic reachability: minimum/maximum probability
of reaching a target, possibly within a time bound.
◦ Expected rechability: the minimum/maximum expected
reward accumulated until a target is reached.
24
Toolset for PTRebeca Models
RMC 2.4
Probabilistic
Timed Rebeca Model
Sate Space
to PRISM input
25
Sensor Network Example
Control
Systems
Rescue
Scientist
26
Parameters of Sensor Network
The toxic level is changed to the
dangerous level with a probability of 0.02
 Sensor does not send data with a
probability of 0.01
 Does the scientist stay alive?

◦ Sensor checks the laboratory by different
periods
◦ We want to find out the working period of
sensor for which the probability of scientist’s
death is minimum.
27
Reactive Class of ‘Laboratory’
reactiveclass Lab(10){
knownrebecs{
Sensor sensor0;
Scientist scientist;
}
statevars{
byte gasLevel, changingPeriod, scientistDeadline;
boolean meetDangerousLevel;
}
Lab(){ /*Some initializations*/}
msgsrv changeGasLevel(){
if (gasLevel == 2)
gasLevel = ?(0.98:2, 0.02:4); // 4 = dangerous 2 = safe
if (gasLevel > 2)
scientist.die() after (scientistDeadline /* = 10 */);
self.changeGasLevel() after (changingPeriod /* = 5*/);
}
msgsrv giveEnvGas(){/*…*/}
}
28
Reactive Class of ‘Sensor’
reactiveclass Sensor(7) {
knownrebecs {
Admin admin;
Lab lab;
}
statevars {
int checkingPeriod, netDelay;
}
Sensor(int myPeriod) { /* Some initializations*/ }
msgsrv checkGasLevel() { /*Ask environment for the toxic level*/}
msgsrv doReport(byte value) {
boolean working = ?(0.01:false,0.99:true);
if (working){
admin.report(value) after (netDelay /* = 1 */);
self.checkGasLevel() after (checkingPeriod);
}
}
}
29
Reactive Class of ‘Admin’
reactiveclass Admin(13) {
knownrebecs { /**/ }
statevars { /**/ }
Admin() {
/* Some initializations */
self.checkSensors();
}
msgsrv checkSensors() {
if (sensorValue0 = dangerousLevel ) {
scientist.abortPlan() after (netDelay);
self.checkScientistAck() after (sciAckDeadline /* = 5 */);
}
self.checkSensors() after (adminCheckDelay /* = 5 */);
}
msgsrv checkScientistAck() {
if (!scientistAck)
rescue.go() after (netDelay);
}
}
30
Analysis Results

The minimum probability for scientist’s
death (scientist deadline is 10 units of
time)
1
0.9
Probability
0.8
0.7
0.6
0.5
0.4
0.3
0.2
0.1
0
0
2
4
6
8
10
12
14
16
18
20
22
24
Period in which the Sensor checks the lab
Pmin
31
Analysis Results

The minimum and maximum probabilities
for scientist’s death
1
Probability
0.8
0.6
0.4
0.2
0
0
2
4
6
8 10 12 14 16 18 20 22
Period in which the Sensor checks the lab
Pmax
24
Pmin
32
Sensor Period = 4
s.checkGasLevel
s.checkGasLevel
e-›s.doReport
s-›a.report
e.changeGasLevel
e-›s.doReport
s.checkGasLevel
s-›a.report
s-›a.report
e.changeGasLevel
a.checkSensors
0
1
a.report
a.checkSensors
a-›sci.abortPlan
4
5
e.changeGasLevel
e-›sci.die
a.checkSensors
a.report
8
9
10
11
sci.abortPlan
a.report
33
Sensor Period = 6
s.checkGasLevel
e-›s.doReport
s-›a.report
e.changeGasLevel
a.checkSensors
0
1
a.report
s.checkGasLevel
e-›s.doReport
s-›a.report
e.changeGasLevel
e-›sci.die
a.checkSensors
5
6
e.changeGasLevel
a.checkSensors
a-›sci.abortPlan
7
10
11
sci.abortPlan
a.report
34
Sensor Period = 5
s.checkGasLevel
e-›s.doReport
s-›a.report
e.changeGasLevel
a.checkSensors
0
1
a.report
s.checkGasLevel
s.checkGasLevel
e-›s.doReport
e-›s.doReport
s-›a.report
s-›a.report
e.changeGasLevel
e-›sci.die
a.checkSensors
5
6
a.report
sci.die
e.changeGasLevel
a.checkSensors
10
11
15
a.report
35
Difficulties!
Interpretation of the results are some
times hard to do
 Tool sets are poor in reporting counter
examples
 Non-determinism between execution of
concurrent components and probabilistic
behavior of components are mixed
together

36
Modified Version of The Model

Scientist deadline is 12 units of time
1
0.9
Probability
0.8
0.7
0.6
0.5
0.4
0.3
0.2
0.1
0
0
2
4
6
8
10
12
14
16
18
20
22
24
26
28
Period in which the Sensor checks the lab
pmax
Pmin
37
Future work
Adding reward/cost to the PTRebeca language
 Modeling and verification of power
consumption using reward/cost
 Dynamic creation and dynamic topology
 More case studies

◦ Modeling with PTRebeca
◦ Model check with PRISM as a backend model
checker.
38
Thanks!
39
References

Luca Aceto, Matteo Cimini, Anna Ingólfsdóttir, Arni Hermann
Reynisson, Steinar Hugi Sigurdarson, Marjan Sirjani, Modelling
and Simulation of Asynchronous Real-Time Systems
using Timed Rebeca, FOCLASA 2011, 1-19.

Ehsan Khamespanah, Zeynab Sabahi Kaviani, Ramtin Khosravi, Marjan Sirjani
and Mohammad-Javad Izadi, Timed-Rebeca Schedulability and


Deadlock-Freedom Analysis Using Floating-Time
Transition System, AGERE! '12
Marta Kwiatkowska, Gethin Norman, Roberto Segala, Jeremy
Sproston, Automatic verification of real-time systems with
discrete probability distributions, Theor. Comput. Sci. 2002
Marta Kwiatkowska, Gethin Norman, Roberto Segala, Jeremy
Sproston, Model Checking Probabilistic Timed Automata
with One or Two Clocks, TACAS'07
40
References




M. Sirjani, A. Movaghar, and M.R. Mousavi, Compositional
Verification of an Actor-Based Model for Reactive Systems,
in Proceedings of Workshop on Automated Verification of Critical
Systems (AVoCS'01), Oxford University, April 2001.
M. Sirjani, M. M. Jaghoori, Ten Years of Analyzing Actors:
Rebeca Experience, LNCS 7000, pp. 20-56, 2011.
M. Sirjani, A. Movaghar, A. Shali, F.S. de Boer, Modeling and
Verification of Reactive Systems using Rebeca, Fundamenta
Informaticae,Volume 63, Number 4, ISSN 0169-2968, pp. 385-410,
2004.
Christel Baier, Boudewijn R. Haverkort, Holger Hermanns, JoostPieter Katoen, Performance Evaluation and Model Checking
Join Forces, Communications of the ACM, 2010
41
Timed Rebeca

An extension of Rebeca for real time
systems modeling
◦
◦
◦
◦
Computation time (delay)
Message delivery time (after)
Message expiration (deadline)
Periods of occurence of events (after)
Modelling and Simulation of Asynchronous Real-Time Systems using Timed Rebeca
Luca Aceto, Matteo Cimini, Anna Ingólfsdóttir, Arni Hermann Reynisson, Steinar
Hugi Sigurdarson, Marjan Sirjani
FOCLASA 2011, 1-19.
Timed Rebeca Example
Example of a ticket service system
 A Customer wants to buy a ticket

◦ There are time constraints for issuing ticket
Ticket Service model
msgsrv ticketIssued(byte id) {
c.ticketReady(id);
}
reactiveclass TicketService {
knownrebecs {
Agent a;
}
statevars {
int issueDelay; Time progress
}
because of
msgsrv initial(int myDelay) {
computation delay
issueDelay = myDelay;
}
msgsrv requestTicket() {
delay(issueDelay);
a.ticketIssued(1);
}
}
reactiveclass Customer {
Message sending,
knownrebecs {
Agent a;
network delay is
}
10
msgsrv initial() {
self.try();
}
msgsrv try() {
a.giveTicket() after(10);
}
msgsrv ticketIReady(byte id) {
\\ customer happy
self.try() after(30);
}
}
reactiveclass Agent {
Deadline for the
release
knownrebecs {
message
TicketService ts;
Customer c;
}
msgsrv requestTicket() {
ts.requestTicket() deadline(5);
}
}
main {
Agent a(ts, c):();
TicketService ts(a):(3);
Customer c(a):();
}
Communication
delay or periodic
tasks
44
Deadlock and schedulability check
We keep the relative distance between
values of all the timing values of each
state (relative timing distances are
preserved)
 Deadlines are set relatively so time shift
has no effect on deadline-miss
 For checking “deadline missed” and
“deadlock-freedom” relative time is
enough

45
Another Challenge (cont.)
We have to think about new reduction
techniques
 Maybe probabilistic FTTS
 Chance of reducing state space using
partial order reduction of untimed nonprobabilistic transitions

46
Future Work (2/2)
Non-determinism in the models results in
big state spaces
 We try to reduce non-deterministic
behavior of the models
 Effect of non-deterministic and
probabilistic behaviors are the same in the
size of state spaces
 We can not reduce degree of probabilistic
behavior of models

47
Comparing to others(1/4)

PRISM language
◦ well-established and powerful model checker with
a state-based input language.
◦ lacks high-level programming constructs, like loops,
and primary data structures, like arrays.
◦ Modeling and verification of systems with
asynchronous message passing makes complex
models.
48
Comparing to others(2/4)

ProbMela language
◦ The operational semantics of was defined in Markov
Decision Process.
◦ MDP model checker LiQuor is used for qualitative
and quantitative analysis of LTL properties.
◦ There is also a mapping from ProbMela to PRISM
language which makes probabilistic analysis possible.
49
Comparing to others(3/4)

PMaude language
◦ There is an actor extension of probabilistic rewriting
theories for Pmaude.
◦ It resolves non-determinism.
◦ A statistical technique is provided to analyze
quantitative aspects of systems using discrete-event
simulation
◦ It lacks probabilistic model checking.
50
Comparing to others(4/4)

PCreol language
◦ High level and object-oriented paradigm is used to
model systems.
 Probability distribution functions for probabilistic behavior.
 Implements stochastic continuous-time for modeling.
◦ It resolves all the non-determinism to make eventbased simulation and statistical analysis feasible.
◦ It lacks probabilistic model checking since VESTA
model checker supports statistical model checking.
51
Timed Rebeca Model of Ping-Pong
reactiveclass Ping(3) {
knownrebecs {Pong pong;}
Ping() {
self.ping();
}
msgsrv ping() {
pong.pong() after(1);
delay(2);
}
}
main {
Ping ping(pong):();
Pong pong(ping):();
}
reactiveclass Pong(3) {
knownrebecs {Ping ping;}
Pong() {
}
msgsrv pong() {
ping.ping() after (1) deadline(2);
delay(1);
}
}
Timed Transition System of PingPong
Without after and deadline
Ping.ping
With after and deadline
Start executing a
method
Ping.ping
Pong.pong
time+=1
τ:Pong.pong
time+=1
time +=1
delay
continue executing
a method
τ:Ping.ping
Ping.ping
Pong.pong
time +=1
τ:Ping.ping
Ping.ping
τ:Pong.pong
τ:Pong.pong
τ:Pong.pong
Ping.ping
τ:Ping.ping
Timed Automata of Timed Rebeca
Models

Three types of automata
◦ A timed automaton for modeling the behavior
of each rebec
◦ A timed automaton for each message bag
◦ A timed automaton for simulating the
behavior of after
Timed Automata for Ping and Pong
(Model without after and deadline)
s1
receive?
s2
message == ping
s3
sender=ping
receiver=pong
send!
s4
clock1=0
reactiveclass Ping(3) {
knownrebecs {Pong pong;}
Ping() {self.ping();}
msgsrv ping() {
pong.pong();
delay(2);
}
}
remove-executed-message
s6
clock1==2
s5
clock2=0
reactiveclass Pong(3) {
sender=pong
receiver=ping
knownrebecs {Ping ping;}
send!
message == pong
Ping() {}
p1 receive? p2
p3
p4
msgsrv ping() {
ping.ping();
delay(1);
}
remove-executed-message
p6 clock2==1 p5
}
Timed Automata for Message Buffers
Receiving
messages
send?
insertInBuffer()
messageBag[0] != NULL
Synchronized
with receive?
in the rebec
receive!
i:int[1,N]
messageBag[i] != NULL &&
deadline[i] < clock[i]
q1
discard(i)
Discard messages
which missed
their deadlines
Timed Automata for After
Send the messages
when time enough is
passed according to
the after parameter
Receive messages
and put them in a
buffer
messageBag[i] != NULL &&
time[i] == clock[i]
r1
takeFromBuffer()
send!
after?
insertInBuffer()
Region Transition System of Timed
Automata Model

Labels of states
◦
◦
◦
◦
◦
◦
s: Ping actor,
p: Pong actor,
q: Ping queue,
t: Pong queue
c1: local clock of Ping actor,
c2: local clock of Pong actor
c1<=2
sender=Pong
receiver=Ping
send!
q1
send?
t1
A simple
trace of the
p5 transition
p6 region
p4
s4
c2=0
c2==1
discard(i)
c2<=1
system discard(i)
c1=0
receive
send
s4, q1, p5, t1
c1=0, c2=0
p3
Region Transition System of Timed
receive! send?
receive!
Automata Model (without after and deadline)
s5 
s1, q1, p1, t1
c1=0, c2=0
message
== pong
c2=0
s2, q1, p1, t1
c1=0, c2=0
s5, q1, p3, t1
c1=0, c2=0
s4, q1, p4, t1
c1=0, c2=0
message
==ping
message
== pong
send
s3, q1, p1, t1
c1=0, c2=0
send
s4, q1, p1, t1
c1=0, c2=0
s5, q1, p2, t1
c1=0, c2=0
receive
s4, q1, p3, t1
c1=0, c2=0 message
== pong
s5, q1, p1, t1
c1=0, c2=0
s4, q1, p2, t1
c1=0, c2=0
receive
c1==2
p1 receive? p2
s3
c1=0
s6
message
== ping
Remove
executed
message
s2
sender=Ping
receiver=Pong
send!
receive?
Remove
executed
message
s1
Region Transition System of Timed
Automata Model (Model without after and deadline)
RTS of the Timed
Automata model
receive
message==ping
send
c1=0
receive
message==pong
send
c2=0
c1=0
receive
c1=0 message==pong
c1=0 send
c2=0
c1=0
0<c1<1, 0<c2<1
c1=1, c2=1
TTS of the Timed
Rebeca model
Ping.ping
Pong.pong
time +=1
FTTS of the
Timed
Rebeca model
τ:Pong.pong
time +=1
Ping.ping
τ:Ping.ping
Pong.pong
Ping.ping
Ping.ping
Timed Automata for Ping-Pong
(Model with after and deadline)
reactiveclass Ping(3) {
knownrebecs {Pong pong;}
receive?
s2
message == ping
s3
clock1=0
Ping() {self.ping();}
s1
sender=Ping
receiver=Pong
deadline=Infinity
afterClock1=0
afterTime1=1 s4
after!
msgsrv ping() {
pong.pong() after(1);
delay(2);
remove-executed-message
}
s6
clock1==2
s5
}
p3 sender=Pong
receiver=Ping p4
deadline=2
afterClock2=0
afterTime2=1
after!
p6
clock2==1
clock2=0
reactiveclass Pong(3) {
message == pong
p1 receive? p2
knownrebecs {Ping ping;}
Ping() {}
msgsrv ping() {
ping.ping() after (1) deadline(2);
remove-executed-message
delay(1);
}
}
p5
Future work
Adding reward/cost to the PTRebeca language
 Modeling and verification of power
consumption using reward/cost
 Dynamic creation and dynamic topology
 More case studies

◦ Modeling with PTRebeca
◦ Model check with PRISM as a backend model
checker.
62
Future work (2/3)
Probabilistic Floating Time Transition System

An extension of FTTS to support both probability
and non-determinism.
◦ Semantics
◦ Implementing a tool
◦ Deadlock freedom and schedulability
◦ Case studies
Second goal:
◦ Model checking event-based properties
 Model checking algorithm
 Property language
63
pRebeca

An extension of Rebeca for modeling
probabilistic systems using:
◦
◦
◦
◦

Probabilistic alternative behavior
Non-deterministic assignment
Probabilistic assignment (behavior)
Probabilistic message sending
Lacks modeling timing behaviors
64
Ticket Service model
reactiveclass TicketService {
knownrebecs {
Agent a;
}
msgsrv requestTicket() {
a.ticketIssued(1) probloss (0.1);
}
}
reactiveclass Agent {
reactiveclass Customer {
knownrebecs {
Probabilistic
Agent a;
sending message
}
statevars {
boolean requestRepeat;
}
msgsrv initial() {
self.try();
}
msgsrv try() {
a.requestTicket();
}
msgsrv ticketIssued(byte id) {
requestRepeat =?(0.95:true,0.05:false);
if (requestRepeat ) {
self.try();
}
}
Probabilistic
knownrebecs {
Probabilistic
TicketService ts;
Customer c;
alternative behavior
}
msgsrv requestTicket() {
pAlt{
prob(0.95) {
ts.requestTicket ();
}
prob(0.05){
}
}
assignment
main {
}
}
Agent a(ts, c):();
msgsrv ticketIssued(byte id) {
TicketService ts(a):();
c.ticketIssued(id);
Customer c(a):();
}
}
}
65
Model Checking of pRebeca
Semantics in Markov Decision Process
 Automated tool for generating MDP from
pRebeca models.
 PRISM as a backend model checker

Modeling and Verification of Probabilistic Actor Systems Using pRebeca
Mahsa Varshosaz, Ramtin Khosravi
ICEFM 2012
66
Applications
NoC: hardware group at UT – Siamak
Mohammadi
 Hadoop: Distributed Systems group at
UIUC – Indy Gupta
 TinyOS: OSL at UIUC – Gul Agha
 Wireless network distributed
connectivity : Algorithm group at RU –
Magnus Halldorsson

67
Probabilistic Reachability in PTA

Reachability
The system can reach a certain set of states with a given
probability.

Time bounded reachability
The system can reach a certain set of states within a certain time
deadline with a given probability.

Invariance
The system does not leave a certain set of states with a given
probability.

Bounded response
The system inevitably reaches a certain set of states within a
certain time deadline with a given probability.
68