Title: Towards a formal analysis approach based on the use of Colored Petri Nets, Timed Colored Petri Nets and the CPN Tools
1Towards a formal analysis approach based on the
use of Colored Petri Nets, Timed Colored Petri
Nets and the CPN Tools
Panagiotis Katsaros katsaros_at_csd.auth.gr -
http//delab.csd.auth.gr/katsaros/ Department of
Informatics Aristotle University of
Thessaloniki G R E E C E
2Few words for CP-nets
- Colored Petri Nets is a Petri Net (PT-net) based
modeling language that as all other PT-net
languages - provides an explicit representation of both
states (markings) and events (transitions) - provides an easy to understand and intuitively
appealing graphical representation - has a well-defined formal semantics that builds
upon true concurrency, instead of interleaving - use of appropriate tools to generate interactive
simulations of the modeled systems and to apply a
wide range of formal analysis alternatives
3Few words for CP-nets
- CP-nets compared to simple PT-nets
- provide a more compact and much more convenient
modeling language, in a similar way as high-level
programming languages are much more adequate for
practical programming than assembly code - have been developed over the last 28 years
(research team lead by Prof. K. Jensen in Aarhus
Un., Denmark) and today constitute a mature
modeling language supported by an advanced
toolset (CPN Tools with about 3500 worldwide
installations used in academic industrial
problems)
4Few words for CP-nets
- CP-nets compared to simple PT-nets
- provide a compact description of control and
synchronization, integrated with a description of
data manipulation - provide support for building large system models,
by relating smaller CP-nets to each other in a
well-defined way (hierarchical CP-nets) - provide a CP-net variant called Timed CP-nets to
analyze systems with time-dependent behavior,
like for example systems with timing constraints - in CPN Tools, models are saved in an XML
representation (possible to automatically
generate CP-nets)
5Few words for CP-nets
( declarations ) colset E with e colset INT
int colset BOOL bool colset STRING
string colset daytime with day night colset
sListlist STRING var anIntINT var
messagessList var aDayTimedaytime
A very simple CP-net
6Our approach
- use an automaton-driven model building approach
for individual CP-net components - build the CP-net model hierarchy
- generate the state space graph and perform the
standard state space analysis (standard report) - check the systems safety and liveness properties
(terminal self loops, deadlocks, livelocks,
fairness properties etc) - model check other correctness properties by
querying the state space graph or by applying a
Computation Tree Temporal Logic (CTL) formula
over the generated graph - possible to be extended in building CP-nets for
component-based software and for systems with
timing constraints (Timed CP-nets) and then in
model checking the required correctness properties
7Case study electronic payment transactions
- we model check the NetBill electronic payments
system with respect to a range of transaction
atomicity guarantees that the system should
provide in all circumstances - we build the state machines for each one of the
three transaction parties, namely the Consumer
(C), the Merchant (M) and the Trusted Third Party
(TTP) - we assume that the TTP fulfills a range of trust
assumptions and we model check the transaction
guarantees of interest in all cases of
participants system failures (fail-stop
failures), message losses and fraudulent behavior
- Katsaros, P. A roadmap to electronic payment
transaction guarantees and a Colored Petri Net
model checking approach, Technical Report,
Department of Informatics, Aristotle University
of Thessaloniki, Greece, 2006 (50 pages -
available in http//delab.csd.auth.
gr/katsaros/publications.htm)
8The top-level CP-net
( declarations ) colset validORnValid with v
i colset accBalance with gValue
lessMoney colset State with IDLE WAIT
W_FAILED ABORTED COMMITTED C_FAILED
COMPLETED DISPUTED_TR LISTEN
NO_RECORD L_FAILED STARTED_TR ST_FAILED
N_FAILED colset NetBillMSg union
gRequestvalidORnValid eGoodsvalidORnValid
pORequestvalidORnValid trResultSTRING
dKeyvalidORnValid queryE colset NetBillMQ
list NetBillMSg var p,q,r,s NetBillMQvar
mes,mes2 NetBillMSg var gReqvalidORnValidvar
pOrdervalidORnValid var enGoods
validORnValid var balance accBalance var
timer,timer2 BOOL var key validORnValid var
st State
9Consumers state machine and CP-net
- irrespective of the occurred site failures a
consumer either aborts or completes a purchase
transaction and the received goods are either the
ordered ones or are not as expected for the
ordered ones
10Consumers state machine and CP-net
11Merchants state machine and CP-net
-
- we abstract from candidate recovery mechanisms
(which would result in loss of generality) by
adopting the assumption that merchants site does
not provide recovery with respect to the ongoing
purchase transaction
12Merchants state machine and CP-net
13TTPs state machine and CP-net
-
- trust assumptions imply that irrespective of the
occurred site failures or message losses the TTP
either aborts or completes the purchase
transaction and delivers the transaction result
as expected
14TTPs state machine and CP-net
15Standard state space analysis
Statistics ---------------------------------------
--------------------------------- State Space
Nodes 6439 Arcs 18915 Secs
30 Status Full Scc Graph Nodes
2678 Arcs 11257 Secs 2 Boundedness
Properties ---------------------------------------
--------------------------------- Best Integers
Bounds Upper Lower Consumer'decrKey 1
1 0 TTP'TTP 1 1
1 Consumer'encrGoods 1 1 0
TTP'amount 1 1 0
Consumer'goodsReq 1 1 1
TTP'decrKey 1 1 0
Consumer'pOrderReq 1 1 0
TopLevel'ConToMer 1 1 1
Merchant'Merchant 1 1 1
TopLevel'ConToTTP 1 1 1
Merchant'decrKey 1 1 0
TopLevel'Consumer 1 1 1
Merchant'pOrderReq 1 1 0
TopLevel'MerToCon 1 1 1
16Standard state space analysis
Home Properties ----------------------------------
-------------------------------------- Home
Markings None Liveness Properties ------------
--------------------------------------------------
---------- Dead Markings 72
963,665,592,5905,5890,... Dead Transitions
Instances None Live Transitions Instances
None Fairness Properties ----------------------
--------------------------------------------------
Consumer'C1 1 No Fairness Consumer'C10 1 No Fairness Consumer'C11 1 Fair Consumer'C12 1 Fair Consumer'C13 1 Fair Consumer'C14 1 Just Consumer'C15 1 Just Consumer'C16 1 Just Consumer'C17 1 No Fairness Consumer'C18 1 Fair Consumer'C19 1 Fair Consumer'C2 1 No Fairness Consumer'C3 1 No Fairness Merchant'M13 1 No Fairness Merchant'M2 1 No Fairness Merchant'M3 1 No Fairness TTP'TTP1 1 No Fairness TTP'TTP10 1 No Fairness
17Model checking systems safety liveness
properties
- CPN Tools provides appropriate functions for
querying the generated state space graph - to find the dead markings (valid termination
states or deadlocks)
18Model checking systems safety liveness
properties
- to verify the absence of self-loop terminal
nodes
19Model checking systems safety liveness
properties
- to verify the absence of unexpected dead markings
(deadlocks)
20Model checking systems safety liveness
properties
- to verify the absence of livelocks (reachable
cycles with no exit) - if the state space and its Scc graph are
isomorphic and also there are no self-loops, then
the protocol model is free of livelocks - if the state space contains self-loops or if
there is at least one strongly connected
component that consists of more than one node,
then we need to show that all terminal components
are trivial that is, they consist of a single
node and no arcs.
21Model validation
- model validation is performed by model checking
the systems model assumptions (e.g. trust
assumptions for the shown payment system) - for system properties that imply certain temporal
dependencies for the occurrence of certain events
we use the ASK-CTL library to express them as
Computation Tree Temporal Logic formulae
22Computation Tree Temporal Logic Formulae
- money atomicity there is no possibility of
creation or destruction of money, while
electronic cash is being transferred - we model check that there is no reachable path,
where for every state neither M nor C has the
money and there is also no reachable path, where
for every state both M and C have the money
23Computation Tree Temporal Logic Formulae
- Other transaction guarantees verified as CTL
formulae - goods atomicity or fairness includes money
atomicity and also ensures that there is no
possibility of paying without having received
goods or vice versa - certified delivery includes money atomicity and
goods atomicity and also allows C and M to prove
the details of the transaction (not proved before
in related work) - protection of participants interests
- Cs protection guarantee if M is entitled to a
payment, then C actually receives the goods, or C
can claim them in an offline dispute handling - Ms protection guarantee . . .
- (not proved before in related work)
24Additional model checking tasks
- to generate a property violation scenario
(counterexample), if any - in the NetBill payment system we generated a
replay attack scenario (double spending) by the
use of appropriate state space querying functions
(countermeasures had already been proposed by the
systems inventors) - model checking concurrent payment transactions
and intruder attack scenarios - main problem inappropriate model structure is
easy to result in a computationally expensive
state space - solution alternatives
- - to generate the state space only partially,
according to specific search criteria - - to apply clever state space reduction
techniques
25CP-net analysis alternatives
- place invariant or transition invariant analysis
- place invariant analysis aims to formulate some
equations which we postulate to be satisfied
independently of the steps that occur - transition invariants are similar to place
invariants, but they are use to determine
transition occurrence sequences that have no
total effect, i.e. they have the same start and
end markings - make possible to prove general system properties
without fixing system parameters - it is possible to check invariants without
considering the set of all reachable markings (no
need to generate the state space) - formulating appropriate equations for a system
property is not a easy task in all cases - very limited tool support
26Timed CP-nets
- Each token, in addition to its data value carries
a time stamp. The time stamp tells us when the
token is ready to be used by a transition. - We specify how the different activities and
states consume time. It is possible to specify
al kinds of delays (constant, interval, or
probability distribution). - The nodes in the generated state space graph
contain a time value and a timed marking.
27Timed CP-nets
- Possible analyses
- - to prove properties like for example for
each instance of a - given transition firing (activity start)
exists an instance of the - corresponding transition firing (activity
end) such that the - deadline of execution is less than a fixed
time value - - to calculate the maximal time used for the
execution of - certain activities (worst execution time
analysis) - - simulation based performance evaluation
28Conclusion
- CP-nets seem to be a modeling language for many
different types of analysis - need to invest on a systematic (and possibly
automated) model building approach which should
possibly employ specialized state space reduction
techniques - Future research prospects
- possibilities to exploit Timed CP-net model
analysis for the schedulability analysis of
systems with timing constraints - possibilities to exploit existing know-how in
order to systematically generate CP-nets for
component-based software - to investigate the effectiveness of existing or
new state space reduction techniques in different
component software cases