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 Hassapis

2

1,2Dept. of Electrical and Computer Engineering,Aristotle University of

Thessaloniki

54124 Thessaloniki, Greece 1mkour@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

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

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:

– (l, u) d

(l, u + d) if d’ : 0 d’ d u + d’ I(l), and

– (l, u) a

(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

C\r [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

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

BRANCH

TELLER

HISTORY

ACCOUNT

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.

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

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

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

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

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

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

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

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