This document describes a timed automata model to evaluate the performance of an online transaction processing system for a bank. The model represents a bank with multiple branches and tellers, and models customer transactions as well as the database system that processes the transactions. The model is composed of five timed automata that synchronize to represent customer arrivals, transaction locking/unlocking, buffer processing, and clocks. The model is simulated and verified using UPPAAL to analyze transaction throughput under different customer arrival scenarios.

1. Application of the timed automata abstraction to the
performance evaluation of the architecture of a bank on-
line transaction processing system.
Maria Kourkouli1 and George Hassapis2
1,2
Dept. of Electrical and Computer Engineering,Aristotle University of
Thessaloniki
54124 Thessaloniki, Greece
1
mkour@auth.gr,2chasapis@eng.auth.gr
Abstract. Timed automata is an abstraction that can provide a way of
expressing timing delays when the behavior of a real time system is modeled.
Then, for the verification of specifications and properties of the system model
checking techniques can be used. In this work an attempt is made to model an
on-line transaction processing system with timed automata. We describe a bank
that has multiple branches with multiple tellers at each branch. The transactions
represent the deposit or the withdrawal that a customer makes. Basically, it is
the database management system of the bank information system that is
modeled and its time response to various different scenarios of customer arrival
rates at each teller machine is assessed as well as the transactions throughput
that can be served at specific timing windows. Scenarios are based on
dynamically increasing and decreasing of the on-going transactions per branch
at a specified period of time. The operation of the considered information
system generates different types of concurrent processes which are modeled by
forming a multitude of timed automata communicating and synchronized
between each other with channel variables. The system is modeled and verified
using the real time model checker UPPAAL that provides the possibility to
check our model for atomicity, consistency and durability. The results of this
analysis and the experience in developing, simulating and verifying this model
are presented and thoroughly discussed.
M. Kourkouli, G. Hassapis, "Application of the timed automata abstraction to the performance
evaluation of the architecture of a bank on-line transaction processing system",
Proceedings of the 2nd South-East European Workshop on Formal Methods (SEEFM05),
Ohrid, 18-19 Nov 2005, pp. 142-153. 142

2. 1. Introduction
Usually as real-time systems are defined the computer systems that are used to
process correctly and within desired or specified timing limits large amounts of data.
As the investment for developing such systems is quite high and the satisfaction of
safety and security requirements is quite demanding there is a need of evaluating their
basic design before proceeding to the development and the engineering of these
systems for compliance with desired specifications and requirements. One way of
evaluating the basic design of a real-time system before committing ourselves in the
expensive process of constructing it is to model the basic design, simulate the model
operation and verify the satisfaction of specified performance and safety
requirements. Among the possible modelling techniques such as finite state machines,
process algebras, Petri-nets, temporal logic [1] symbolic model checking by the use of
timed automata [2] seems to be a good first effort approach in modelling real-time
systems because it provides a formal mechanism for manipulating the timing delay
and the handling of the timing conditions. Based on the work of Alur and Dill [3]
several real-time applications have been studied as the railroad crossing [4], the
formal model of Ada Ravenscar tasking [5], the formal verification of a Power
Controller [6] and the Lip synchronization Protocol [7]. Other applications are
described in [8] and [9] proving the adequacy of the timed automata abstraction in the
modeling and verification of real-time systems. To add one more application in the
list and make stronger the argument of the appropriateness of the timed automata
abstraction in the modeling and verification of real-time systems we present in this
work the use of timed automata on the modelling, simulation and verification of an
on-line transaction processing system. Specifically, we model the design of the
database system of a banking organization with multiple branches and multiple tellers
at each branch. We assess the throughput and the time response of the database to
different scenarios of the customer arrival at the various tellers and their service from
the tellers. Our system is simulated and verified with the use of the real-time model
checker UPPAAL [10].
The structure of this paper is as follows: Section 2 contains some background
information for timed automata useful to understand the description of our model.
Then, in section 3 the transaction processing system of the bank is described. In
section 4 the proposed timed automata model is presented and in section 5 it is
demonstrated the way this model is used for simulating the running of the transaction
processing system, assessing its throughput and response figures and verifying the
satisfaction of processing requirements. This is done by the use of the UPPAAL
model checker. The results of this analysis and the experience in simulating and
verifying this model are presented in section 6. The conclusions are discussed in
section 7.
143

3. 2. Background Information
A timed automaton is a finite state machine extended with clock variables [10]. In
each automaton a real-valued clock is added and in each transition there are guards as
enabling conditions.
Definition (Timed Automata) A timed automaton is a tuple (L, l0, C, A, E, I) where
L is a non-empty finite set of locations, l0 L is the initial location, C is the set of
clocks, B( C ) is the set of conjunctions over simple conditions of the form x#c or x-y
# c, where x, y C, c N and # { , , , , }, A is a set of actions, co-actions
and the internal -action, E L x A x B ( C ) x 2C x L is a set of edges between
locations with an action, a guard and a set of clocks to be reset, and I : L B(C)
assigns invariants to locations.
Definition (Semantics of TA) Let (L, lo,C, A, E, I) be a timed automaton. The
semantics are defined as a labeled transition system (S, s0, ), where S L × RC is
the set of states, s0 = (l0, u0) is the initial state, and S×{ 0 A}×S is the
transition relation such that:
d
– (l, u) (l, u + d) if d’ : 0 d’ d u + d’ I(l), and
a
– (l, u) (l’, u’) if there exists e = (l, a, g, r, l’) Es.t. u g,
u’ = [r 0]u, and u’ I(l),
where for d R 0, u + d maps each clock x in C to the value u(x) + d, and [r 0]u
denotes the clock valuation which maps each clock in r to 0 and agrees with u over
Cr [11].
The edges of the automata have three types of optional labels:
A guard, expressing a condition on the values of clocks and integer
variables that must be satisfied in order for the edge to be taken. For
example in figure 1 the edge between A0 and A1 can only be taken
when the value of the clock x is greater than or equals 2.
A synchronization action that is performed when the edge is taken. In
figure 1 the two processes communicate via the channel a. When the
action a! in process A which consists from A0 and A1 is performed, ,
then it is synchronized with process B, that consists from B0 and B1, on
the complementary action a?
A number of clock resets and assignments to integer variables. In figure
1 the clock x is reset to 0 when the transition between A0 and A1 is
taken and the same time the integer variable i is increased by four.
144

4. Fig. 1. A timed automaton
The model of a timed automaton often consists of a collection of timed automata,
called network of timed automata, and have a common set of clocks and actions. The
variables model the logical clocks in the system. The clocks are initialized with zero
when the system is started, and then increase synchronously at the same rate. Clock
constraints are used in the same way as the guards on edges are used to restrict the
behavior of the automaton. A transition represented by an edge can be taken when the
clock values satisfy the guard labeled on the edge. Clocks can be reset to zero when a
transition is taken [11].
Timed automata are useful in the design phase when decision about the system
structure and behavior must be taken. They provide a graphical and a mathematical
system view and we are enabling to analyze the system.
3. On-line Transaction Processing System
In this work an attempt is made to model the on-line transaction processing system of
a banking organization with timed automata. In Figure 2 the organization of the bank
is depicted. It consists of multiple branches with multiple tellers at each branch.
Fig. 2. The bank organization
145

5. The transactions that are performed represent the work done when a customer makes
a deposit or a withdrawal. Transactions are handled by a database system, which
considers them as concurrent processes. For each transaction there is a set of records,
each one of which can be in a locked or unlocked state. The way the concurrent
processes are processed by the database system is pictorially presented in Figure 3.
BRANCH
TELLER ACCOUNT
HISTORY
Fig. 3. The architecture of the database system
As a small percentage of the database is locked each time we use a hash table to
represent the database and a list with only those records that are locked is made. The
components of the database are four separate and individual tables, namely the tables
Account, Branch, Teller and History. The relationship between them is represented in
figure 3. The history file should be large enough to hold all history data from
transactions performed in order to allow system reconstruction after a crash. For the
consistency of the system the record must be locked in the account, in the branch and
in the teller. Multiple transactions cannot access the same record simultaneously. The
system first locks access to the records and it logs these data on transactions on a
buffer [12]. When the log information is written the changes generated by each
transaction are committed and the corresponding records are unlocked. They are
carried out by special database processes, which write to disk the modified pages
and after that, remove these pages from the buffer.
4. The UPPAAL tool
A simulation model is a model which is formulated by using arithmetic and algebraic
relations along with non-mathematical logical processes. It consists of five major
components: state variables, variables, functional relations, inputs and outputs.
UPPAAL [10] is a tool for modeling, simulating and verifying real-time systems. The
tool is appropriate for systems that can be modeled as a collection of non-
146

6. deterministic processes with finite control structure and real-valued clocks,
communicating through channels or shared variables [13].
UPPAAL consists of three main parts: a description language, a simulator and a
model-checker. An automaton contains location and transitions connecting the
locations. In UPPAAL, time is modeled using clock variables. The timing constraints
are attached to transitions or to the locations in the form of labels. A label can be a
guard that expresses the conditions under which the transition can be performed. A
transition can contain clocks, boolean variables, integer variables or synchronous
channels. A system in UPPAAL consists of a collection of automata. These automata
can communicate using the shared variables or the synchronous channels. The
synchronization of two channels is indicated by the use of an exclamation mark (!)
and a question mark(?). The ! at the end of the channel name indicates that the
channel is used for sending. The ? is used to indicate that the channel receives. The
label of a location consists of three parts: the name of the location, the option
invariant and the option Committed or Urgent. The invariant indicates the period that
the automaton can remain in the location.
5. The Timed Automata Model
In this work a model with three branches and different number of tellers is considered
where some customers are served while others may arrive. A five automata model
has been developed to describe the dynamic processing of transactions by the bank
database system. These five automata have been given the tag names OLTP, P0,
Clock, P2 and P3. The OLTP is the basic automaton, which is synchronized with the
others and is shown in figure 4.
Fig.4. OLTP
147

7. The customer is assumed to wait for being served no more than 20 time units, as the
guard a<=20 denotes. When a teller is free then the automaton is in the state
“Tr_Req” and initially all the records are unlocked. Then they are locked and the
automaton moves to the state “Tr_Locked”. The next transition is the “Disk_Service”
the activation of which is synchronized in the P0 automaton shown in Figure 8. This
last automaton models the behavior of a buffer and shows that the locked transactions
are first enter in a queue for input to a buffer (Input, buffer location) and eventually
through a wait location enter the buffer location where they can be read from
(Read_Data_From_buffer). The transaction arrives in buffer where it can stay more
than 35 time units, as the guard indicates. When the time exceeds a certain
limit(c.>=35) the request can be served (Req_served) activating in this way the “disk
service” synchronization channel and enabling the transition of the automaton of
Figure 4to the Tr-Unlocked location . After the activation of the “disk service”, the
records are unlocked in order to become ready for another use. When the transaction
processing is completed through the “Tr_processing” channel in the OLTP
automaton, the automaton P0 is synchronized, moves to the “Input” location and
waits the next request while another transaction is loaded from the node “Tr_Req”.
Fig. 5. P3
Fig. 6. Clock
148

8. Fig. 7. P2
Fig. 8. P0
The scenario of customer arrival rate at each branch is described by the automaton P3
in figure 5. The customer arrival rate is increased after 100 time units providing in
this way time for some earlier transactions to be completed. We use a clock variable c
to specify the resource consumption of the bank. In order to make sure that a number
of transactions can be completed within T time units we use the automaton, Clock,
described in figure 6. The Clock and the OLTP are synchronized by the channel
“begin”. When the model is in the “Input” location of P0, a “begin!” signal can be
issued, telling the Clock to start measuring the time. When the location “Finish” of the
149

9. OLTP is reached, no matter along which path, an “end!” signal is issued, telling the
Clock to stop measuring the time. The channel end is declared as urgent, so it will be
activated as soon as location “Finish” is reached without imposing any delay. If the time
exceeds the T time units then the location “Finish_out_of_time” is entered and an
“end?” signal is issued, telling the OLTP to move to the “Finish” location. During the
transition from “Tr_Req” to “Tr_Unlocked” the OLTP is synchronized with automaton
P2 through the channel “database” as shown in figure 7. In automaton P2 the database
management system of the bank information system is modeled. The locations
“Data_teller” and “Data_Branch” are declared as committed. Now the account, the
teller and the branch are locked and the deposit or the withdrawal is ready to be
accomplished. The channel “Record_lock” is used to synchronize the P2 with OLTP
and the location “Tr_Locked” is reached. Then, P2 and P0 are synchronized through the
channel “bufferpage”. When the transaction is finished the account, the teller and the
branch are unlocked and become ready to serve another request. Then, the location
“Tr_Completed” is reached and the completed transactions are counted.
6. Model Simulation
UPPAAL was used to simulate the presented in the previous section model. The
future behavior of a timed automaton depends on its present state and the value of all
its clocks and data variables. In this way, we have a model with an infinite number of
states. Figure 9 shows an instantiation of the simulation. If no transition is selected
from the “Enabled Transitions window” then the system shows all possible clock
valuations that can be reached along the path. If a transition is selected then only
those clock valuations from which the transition can be activated are shown.
Fig. 9. An instantiation of the model simulation
150

10. 7. Evaluation and Verification
Running the simulation for the next 1000 time units, we observe that 16 transactions
are completed in one branch, 9 transactions in the second branch and 10 in the third
branch. That is 35 transactions are completed in 1000 time units. In figure 10 a
graphical representation of the completed transactions at a branch and over a range of
different time periods is presented.
Fig. 10. Transactions completed over a 1000 t.u.
For an online transaction processing system apart from the throughput, the
measurement of the response time is equally important. This can be done by counting
the transactions, x, that are completed (Tr_completed location), in T time units and.
perform the calculation x/T. In order to count in each period how many transactions
are in the state “completed”, we need to run the simulator for T time units and
monitor the number of transactions that are at the various locations by the end of the
simulation time, i.e in the “Locked”, “Unlocked”, and “Tr_Completed..
Another use of the model simulation is the verification of the satisfaction of some properties
of the automata, such as whether a location is reachable. This may have the meaning that if
transactions never enter in this state, i.e. in the “Tr_Completed” location, then one can
conclude that the on-line transaction processing system does not function properly.
151

11. UPPAAL is able to check for reachability properties, especially if a combination of
locations and constraints on clock and data variables is reachable from an initial state
[14]. The properties that can be verified may have one of the following forms:
– E<> p: to be satisfied a path must exist where p eventually holds
– A [] p: to be satisfied p must be satisfied for all reachable states
– E [] p: to be satisfied a path must exist where p always holds
– A<> p: to be satisfied p must eventually hold for all paths
Using the above we can verify the following properties of our model:
1. Every transaction that arrives in state Input goes only to Tr_Req to start
the processing. In UPPAAL this is declared as: Bank.Input -->
Bank.Tr_Req
2. We can verify that a transaction is in location Tr_Req (waiting for
service) in branch Bank1 while another transaction which is in the node
Tr_Locked in branch Bank2, is served). In UPPAAL this requirement is
symbolized as: E<> Bank1.Tr_Req and Bank2.Tr_Locked
3. We can check that the time does not exceed the limit that we have
declared on Clock automaton with the expression: E [] c<1000
The results that UPPAAL returns are indicated in figure 11
Fig. 11. UPPAAL results
Also from the simulation runs one can assess the response time and the throughput per
branch by monitoring the time taken to move from one location to another until the
desired state is reached. For example the observed response times for completing 16
transactions in the first branch, 10 in the second and 9 in the third are respectively 0.016
time units for the first branch, 0.01 for the second and 0.009 time units for the third.
152

12. 8. Conclusions
The purpose of this study was to demonstrate how the formal method
of timed automata can be utilized in modeling, simulating and verifying
real-time computer systems, different in nature from the traditional
engineering systems. To this purpose the model of an on-line
transaction processing system of a bank has been developed and its use
in assessing performance features of the design, such as throughput and
transaction response time was demonstrated by simulating the model
operation on the UPAAL software tool. Also, it was demonstrated that
the model can be used in verifying the satisfaction of safety and
operational requirements of the system, such as system inability to
complete transaction processing.
References
[1] Branicky, V., Borkar, S., Mitter, S.K. (1994) A unified framework for hybrid
control, Proceedings of the. eerd Conferance. Decision and Control, Lake Buena
Vista 4228-4234
[2] Macmillan, K. (1993) Symbolic Model Checking, Kluwer Academic
[3] Alur and David L. Dill. A theory of timed automata. Journal of Theoretical
Computer Science, 126(2):183–235, 1994.
[4] P.R D’Argenio and Ed Brinksma. A calculus for timed automata. June 1996
[5] K.Lundqvist and L.Asplund. A formal Model of the Ada Ravenscar Tasking
Profile; Delay Until. 1999
[6] K.Havelund, K.G.Larsen and A.Skou. Formal Verification of a Power Controller
Using the Real – time Model Checker UPPAAl.
[7] H.Bowman, G.Faconti,J-P Katoen, D.Latella and M.Massink. Automatic
Verification of a Lip Synchronization Algorithm using UPPAAL
[8] T.A. Henzinger, X.Nicollin,J.Sifakis and S.Yovine. Symbolic model checking for
real-time systems.Information and Computation, 111:193-244,1994
[9] W.Yi, P.Pettersson and M.Daniels. Automatic verification of real-time
communicating systems by constraint- solving.In Hogrefe and Leu pages 223-238
[10] G.Behrmann, A.David, K.G.Larsen. A Tutorial on Uppaal, 2004
[11] J. Bengtsson and W.Yi. Timed Automata: Semantics, Algorithms and Tools
[12] K.Jensen. Coloured Petri Nets,Basic Concepts Analysis Methods and practical
Use, vol 3, pp 51-64
[13] T.Amnell, G. Behrmann, J.Bengtsson, P.R.D’Argenio, A.David, A.Fehnker,
T.Hune, B.Jeannet,Kim G.Larsen, M.O.Moller, P.Pettersson, C.Weise and W.Yi,.
UPPAAL- Now,Next and Future. Springer –Verlag Berlin Heidelberg, 2001
[14] K.G.Larsen, P.Petterson and W.Yi. UPPAAL in a Nutshell, Int. Journal on
Software Tools for technology Transfer, Springer-Verlag,vol 1,number 1-2,
pp134-152,Oct 1997
153