Using a Timed Petri Net (TPN) to Model a Bank ATM

Transcription

1 Using a Timed Petri Net (TPN) to Model a Bank ATM Tony Spiteri Staines MBCS, University of Malta, Department of Computer Information Systems toni_staines@yahoo.com Abstract This paper explains how a working Petri Net model developed for a soft Real Time system. A Bank ATM connects to an ATM controller, which in turn connects to a card authorization system. This model is developed using Timed Petri Nets and there is the addition of other complex mechanisms that give more realistic behavior and a finer level of detailed events. More complex constructs like: timers, reset points, transaction timeouts, redundancy mechanisms and others are included. First we discuss how the model was built using a bottom up approach. Each of the main components of the system are identified and built using Petri Nets. These are tested in isolation and then the complete system is assembled. This is similar to a bottom up approach. Once that the main model is built it is implemented on a simulation tool and used to derive performance results for the system. The final model is live and exhibits repetitive, consistent behavior. Results data have been included in tabular form and depicted graphically. These data show how it is possible to derive results for software and hardware performance using Petri Nets. This is quite exclusive because most software development methods like the UML and even formal techniques do not give us performance analysis and neither proper features for redundancy. To conclude it is possible to say that if good Petri Net simulation tools are available it is possible to use Petri Nets to describe soft Real Time systems in fine detail and analyze them. At present this cannot be easily achieved by many other techniques when the system involved has stringent synchronization requirements and timing constraints. The work presented here can be further developed. 1. Introduction A bank ATM or Teller can be considered to be a complex piece of computerized machinery composed of several classes of objects: Cash Dispenser, Card Verifier, Display Unit, Communication component, Printer, Keypad, servicing unit etc. Each of theses components needs to synchronize correctly with another component to get information and produce correct results. Even a simple transaction like a cash withdrawal in reality is composed of several steps. There could be possibly over 50 steps that are not visible. Some steps like communication and authorization are done remotely from the ATM. Various diagrams can be used to model this system like the Activity Diagram, Sequence Diagram, Communication Diagram or State Diagram of the UML 2 [1,4,8]. Other Object Oriented Modeling Techniques [1,2,3,14] use similar concepts to the UML. The problem with these is that it is difficult to model the detail required using just one of these diagrams. To properly understand the system being explored the notion of synchronization of events and objects is of fundamental importance. For Real Time behavior complex mechanisms, redundancy and time must be considered. It is not possible to use traditional methodologies to perform a simulation run and obtain experimental results. There is also a problem with Diagram consistency if too many diagrams are used. The bank ATM can be considered to be a soft Real- Time system which requires some form of performance analysis. Even though there are numerous methods that can be used for analysis, often it is better to keep to one method rather than end up with a collection of methods. There are formal techniques like: Real Time Logics, Duration Calculus, Process Algebras and Formal languages [7]. These have very specific uses and are not well understood. Usually there is no visual depiction of the system. Many of these techniques are oriented to formally verifying a system rather than model its proper behavior. It is possible to have a formally correct system exhibiting unwanted behavior if this is incorrectly modeled. For a bank ATM there are many possible events and states. This makes these techniques rather awkward to use. Understanding this system is highly dependant on dynamic modeling.

2 There are cognitive problems when trying to design and comprehend complex structures and processes. A person s natural thought process must naturally focus on the interaction between the system s structure and events not on keeping models consistent. This can be achieved through the use of Petri Nets. Some of the most common classes of Petri Nets are Timed Petri Nets, Stochastic Petri Nets, Generalized Stochastic Petri Nets and colored Petri Nets [12]. Timed Petri Nets have been used successfully to model network ATM switching [14]. Special firing times and timing issues have been used in these cases. Transitions can have deterministic or exponential firing times [10]. High level Petri Nets have been used to describe intelligent network switching [6]. A Petri Net can perform some form of choice using defined conditions. Timed Petri Nets, Stochastic Petri Nets and Generalized Stochastic Petri Nets are special classes that can be used for the design of real time systems and embedded systems [5,9,15]. Petri Nets can be used in a three-view model: path-view, map-view and resourceview [17]. This is useful for performance engineering of concurrent software. These models like TCPN (Timing Constraint Petri Nets) can be used for schedulability analysis of real time system specifications [16]. Most of the work done with Petri Nets does not usually take a complete system into consideration from a highly detailed point of view. Also it is not usual for these models to cater for redundancy. This paper shows how many other details and mechanisms can be included in the Petri Nets being used. These mechanisms were built using the Petri Net theory. These mechanisms or constructs cannot be easily replicated using other methods. 2. Related work For this work 3 main classes of objects or components have been identified. Refer to Fig. 1. These are i) the Bank ATM machine, ii) an ATM Controller and iii) credit card authorization server. The ATM connects to the ATM Controller which in turn connects to a credit card authorization server. The following briefly describes sequentially the work carried out: i) Events and possible states were identified for the 3 main components. E.g. for the ATM possible events are: Customer Arrives, Insert Card, Insert Pin, Validate Pin and others. Along with these events possible states were identified and built into lists. For a full list refer to the appendix section 5.1. ii) These events and states were used to construct three Timed Petri Nets [18], one for the ATM Machine, the ATM Controller and the Card Authorization System. iii) Many additional mechanisms were added to the basic Petri Nets to make their behavior more realistic. iv) The Petri Nets for each of the components were tested in isolation for different types of errors. v) All the three Petri Nets were connected to produce the complete system. To connect the Petri Nets, the places designated as communication channels were used. This approach simplifies connecting different components. vi) The full system Petri Net was tested and simulated to derive results used for performance analysis. The final model resulted in Timed Petri Net. This was used to obtain performance results. Two types of transitions were used: i) time transitions ii) immediate transitions. ATM MACHINE ATM CONTROLLER CARD AUTHORIZATION SYSTEM Figure 1. The main components for a bank atm 2.1. Adding mechanisms to the petri net to model real behavior Various mechanisms have been added. These are rather difficult to imitate with other methods. The mechanisms have allowed us to achieve proper Real Time behaviour given the complexities involved. At many major events some form of redundancy has been included. E.g. If the credit card authorization server fails then the ATM Controller can feature a timeout. This will enable the ATM to take some required action. Also if the ATM Controller fails the ATM has an inbuilt timeout mechanism that will enable it to do the processing itself. This type of architecture will guarantee that processing is still carried out even in the worst case scenario. Most of these details cannot be

3 captured with normal object oriented modeling techniques where it is not possible to show the current state of the system Timing details. Timed transitions were used as required in the model. Two types of time were used: constant time and a range time (having an Earliest Firing Time and Latest Firing Time EFT,LFT) Communication channels. Communication channels are places that possibly can have a restriction on the number of tokens they store. These were used to couple together the complete system. These communication channels can serve as message buffers Buffers. Buffers were used to connect different parts together. Buffers consist of simple places with a restricted capacity Simple two-way timeout design. Refer to Fig. 2. The idea is to have a mechanism that simultaneously enables two timed transitions T 11, T 12 because when t8 fires tokens are placed in places P 9 and P 11 simultaneously. T 11 gets a firing time from the interval 5 20 whilst T 12 is fixed at 20. If T 11 < T 12 then a token is placed in P 12 and T 12 is disabled. If T 12 < T 11 then a token is removed from p11 and placed in the machine reset place or a reset point that implies that the transaction timed out and another token is placed in P 14. T 9 is disabled but T 11 remains enabled and will fire after its time expires placing a token in P 12. T 13 is then enabled and the mechanism is reset. This mechanism was used because it was found that once a timed transition from some distribution is enabled it is possible to stop it but then the time counter would not reset. E.g. if transition T 11 is stopped at time 6 then it will retain this value for the next firing. On the other hand if a deterministic transition is stopped its time resets back to the original value. E.g. if transition T 4 is stopped at time 6 it will automatically remain fixed at 20. This can vary depending on what type of Petri Net simulation software is used. The idea behind this is similar to that of having a random switch. This implies that the time is obtained at random allowing us to create different scenarios for evaluation. Figure 2. Simple two-way timeout design Choice points. Using the idea in Fig. 3 it is possible to add a choice point to the Petri Net. In Fig.3 there is probability the either T 1,T 2 or T 3 fires. This can be used to simulate 3 different choices or outcomes. Thus we use conflict or choice to simulate random conditions Machine reset points. The idea was to have places and transitions that can be used to return the components back to the original state. After processing the machine must return to the initial state and start again. Figure 3. A choice point Other details can be added to these buffers to allow the building of more complex mechanisms.

4 Independent timers. Independent Timers are timers that were used to model some specific activity. I.e. When a transaction is being performed a timer is started. It is possible to assign a random time to this timer from a uniformly distributed range. E.g. in Fig. 4., T 19 and T 18 and P 25, P 24 form part of such a timer. model needed to be analyzed in detail. Refer to Fig. 5. The functioning of the model was successful Counters. Counters were added to the Petri Nets by just using normal places with no restricted capacity. These were useful to see if the Petri Nets were functioning correctly and also for performance analysis Testing the components of the atm system Fig. 4 shows how the ATM Controller was tested using dummy connections, places and transitions. This process was also repeated for the ATM and Card Authorization Server. These 2 other individual components have not been displayed. A similar method of testing was used for each. The three components the ATM, ATM Controller and the Card Authorization Server were all tested individually. A sort of coupled token generator was connected to the Petri Net of each individual components in isolation to validate its behavior. This was done before connecting all the three Petri Nets together as in Fig. 5. The approach can be classified as bottom up. Fig. 4 also shows how the ATM Controller component is constructed and tested in isolation before constructing the complete system. Places and transitions have been included both at the end and the start of the ATM Controller. This has been done intentionally for testing purposes. There is also redundancy built into this component using a timer The complete system After each component worked successfully as planned the complete system was assembled. Assembly was simply done by using connection channels. Basically places and transitions were used instead of the dummy places and transitions used for testing. Counters (places) were added to this to be able to get performance results from the Petri Net being used. The full model was also checked and simulated for possible errors. Simulation was used to derive performance results. Inside the model there are many redundancy mechanisms. This implies that if one component fails, e.g. the ATM controller fails the ATM will still operate. This implies that the final Figure 4. Atm controller with dummy places and transitions for testing 3. Results What has been mainly achieved here is that fine Real Time details have been developed and integrated into the Petri Nets. Fault tolerant and recovery mechanisms that function correctly have been created. These mechanisms are important for complex systems being a hybrid of hardware and software parts. Timing and performance analysis can be obtained from the models. These could help in the identification and solution of possible system bottlenecks at an early stage. The final model with the counter places comes close to a generalized stochastic Petri Net which is a special class of a Timed Petri Net. This is determined by its behavior. Two major types of transitions were needed. Timed and immediate transitions. Some transitions have zero delay time. Other transitions have time that is randomly obtained from a distribution whilst other transitions have a constant time..

5 Figure 5. Complete system timed petri net consisting of an atm, atm controller and card authorization

6 There is also an element of non-determinism because of conflicting transitions or transitions enabled simultaneously. The model was executed and tested on the HPSIM Tool [19].The redundancy mechanisms used e.g. the timers, random switches, reset points etc guarantee that the numbers of customers served remains relatively constant with time. The model is also deadlock free, exhibits repetitive behavior, consistent, conservative, structurally bounded and live [18]. The model developed guarantees that it will return to the original state. This can be formally proven using Petri Net theory and other suitable tools. Run No Table 1. Processing results for 10 runs of the complete system part 1 CUSTOMERS IN TOTAL TRANSACTIONS TOTAL ATM TIMEOUTS TIMER 1 TOTAL ATM TIMEOUTS TIMER Run No Table 2. Processing results for 10 runs of the complete system part 2 TOTAL CARDS TAKEN INVALID PIN TIMEOUTS INSERTING PIN TIMEOUTS TRANSACTION SELECTION TOTAL ATM CONTROLLER TIMEOUTS The data in Table 1,2 consists of a summary of 10 simulation runs of one hour each for the model in Fig. 5. Detailed performance analysis was carried out on the model. The results given here are just a small summary of what results are possible. Results in Table 1. and Table 2. confirm that the model is behaving consistently and random data is being generated. The values obtained are also quite close to a real scenario e.g. in 1 hour about 50 customers use the system. This is quite realistic. The final results appear in Fig. 6. It is evident that the random switches and structures used are all fully functional. There is the random generation of invalid pins and transaction timeouts in the model. By changing the time values of the transitions it is possible to achieve totally different results as desired. QUANTITY RUN NUMBER CUSTOMERS IN TOTAL TRANSACTIONS TOTAL ATM TIMEOUTS TIMER 1 TOTAL ATM TIMEOUTS TIMER 2 TOTAL CARDS TAKEN INVALID PIN TIMEOUTS TRANSACTION SELECTION TIMEOUTS INSERTING PIN TOTAL ATM CONTROLLER TIMEOUTS Figure 6. Performance results for the full model It is possible to use a broken connection or a malfunctioning component to simulate different system behavior. If the ATM controller is down the approach used here guarantees that the ATM will still respond to a customer. This is achieved by the timers included in the ATM transitions: T 33 and T 34. If the performance of each component is taken in isolation it is possible to determine design flaws in the system and modify it as needed. 4. Conclusion From the results obtained it is shown that added complex mechanisms have been successfully added to normal Timed Petri Nets. These have enabled us to achieve proper behavior and redundancy which would be important for complex systems. It is noticeable that even though the system modeled here initially looks simple there are many intricacies that are often overlooked. It is possible to refine the Petri Nets developed using reduction methods to simplify the model [18]. These reduction methods enable the Petri Net developed to be simplified in detail. It is possible to add higher order constructs like inhibitor arcs. The problem is that many simulation tools do not support higher level constructs. This is why many of these constructs were not used here. Reachability Analysis can be used to analyze the final Petri Net. Petri Nets can be used for performance analysis. These types of diagrams could be used for detailed analysis and design of complex information systems with synchronous and asynchronous message passing. Strict and precise timing constraints can be modeled in Petri Nets. These diagrams help to identify possible system

7 bottlenecks at the analysis stage. This depends if they are simulated. Other work can be done to formally verify these models and also improve upon them. These types of models could be useful for fault identification even when the system is functional. They could be used for fine tuning the actual system. There are also drawbacks with Petri Nets. If the system is complex it is possible to have too many states to control. Reduction methods would solve this problem. A Petri Net solution might not always be the best approach. From experience it is suggested that other diagrams like State Diagrams or Sequence Diagrams be used along with Petri Nets. 5. Appendix 5.1. Places used P 1 Customer Arrives; P 2 Customer Being Served; P 3 Customer Ready; P 4 Customer In; P 5 Customer Out; P 6 ATM Machine Ready; P 7 Card Inserted; P 8 Ready For Main Reset; P 9 Card Processed P 10 Input 1 Timer; P 11 Input 2 Timer; P 12 Control; P 13 Output 2 Timeout; P 14 Output 1 Normal; P 15 Pin Inserted; P 16 Waiting For Pin Check; P 17 Selection Possible; P 18 Max Pin Retires Allowed ;P19 Input 1 Timer ; P20 Input 2 Timer; P 21 Control; P 22 Output1 Timeout; P 23 Transaction Selection Ready; P 24 Output 2 Normal ;P 25 Selection Processed Ok; P 26 Processing Ended P 27 Output Channel; P 29 Input Channel; P 30 Message Received; P 33 Message Sent Waiting For A Reply; P 37 Reply Processed A; P 38 Reply Processed B; P 39 Customer Processing Ended; P 40 Reset Place; P 41 Timer 1 Firing Enabled; P 42 Timer 2 Firing Enabled; P 43 Control Message Timer; P 44 Additional Transactions Performed Counter; P 45 Maximum Transactions Allowed In 1 Session Counter; P 46 Transition Counter Control; P 47 Pin Selection Place; P 48 No Of Invalid Pin Tries Counter; P 49 Invalid Pin Retries Count Exceeded; P 50 Control; P 51 Timeout Occurred; P 31 Message Received; P 32 Ready For Processing; P 34 Ready To Send Reply; P 28 Message Read In; P 84 Message In Progress; P 35 Message Checked; P 36 Message To Send; P 55 Waiting For Reply; P 54 Message Received; P 53 Message Processed; P52 Message Checked; P34 Ready To Send Reply; P 58 Control; P59Timeout; P 57 Input Channel; P 56,P 66,P 72 Output Channel; P66 Is An Output Buffer Channel That Can Hold Only 4 Tokens; P 72 Can Hold 1 Token; P 62 Reply Message Generated; P 60 Message Received; P 61 Ready For Processing; P 63 Message Read; P 65 Reply Data Generated; P 68 Message Received; P 69 Processes Ready; P 74 Message Received; P 70 Message Read In; P 71 Update Message Sent; P 64 Message Sent To Buffer; P 76 Processes Ready; P 78, P 79, P 80 Ready To Update For Card Transaction Bank Account Interface; P 81, P 82,P 83 Card,Transaction, Bank Account Interface Updated; P 75 Update Signal Sent; P 77 Waiting For Main Update To Complete; P 67, P 73 Buffer Control Places; 5.2. Transitions used T 1 Customer Arrives; T 2 Customer Leave; T 3 Reset Customer; T 4 Insert Card; T 5 Reset Machine; T 6 Process Card; T 7 Request Pin; T 8 Constant Timeout; T 9 Reset Transition; T 10 Time Transition Range [Min,Max];T 11 Start Pin Validation; T 12 Start Pin Validation; T13 Validate Pin Constant Time; T 14 Start Transaction Selection; T 15 Constant Timeout; T 16 Reset Transition; T 17 Time Transition Range [Min,Max]; T 18 Record Transaction; T 19 Process Selection; T20 End Processing; T 22 Send; T 25 Receive; T 28 Forward Normal Reply; T 29 Process Reply; T 30 End Customer Processing; T 31 Give Card Back; T 32 Dual Timer Reset; T 33 Timer 1 Constant Timed Transition; T 34 Timer 2 Constant Timed Transition; T 35 Reset Timer; T 36 Reset- Transaction Counter; T 37 Process Another Transaction; T 38 Process Valid Pin; T 39 Process Invalid Pin; T 40 Pin Counter Reset; T 41 Invalid Pins Process; T 42 Take Card; T 23 Receive; T 24 Send; T 21 Read In; T 43 Prepare String; T 26 Check Or Verify; T 44 Check Message; T 27 Prepare String; T 45 Process Message In; T 46 Send; T 47 Receive; T 48 Timer 1; T49 Reset; 6. Acknowledgements I would like to thank Henryk Anschuetz for using his tool. 7. References [1] S. S. Alhir, Understanding the Unified Modeling Language (UML) Methods& Tools, Martinig & Associates, Apr [2] M. Awad, J. Kuusela, and J. Ziegler, Object-Oriented Technology for Real-Time Systems, Englewood Cliffs, N.J.: Prentice Hall, [3] G. Booch, Object-Oriented Design with Applications, 2d ed. Reading, Mass.: Addison-Wesley, 1991.

8 [4] G. Booch, The Unified Modeling Language User Guide, Reading, Mass.: Addison-Wesley, [5] G. Bucci, E. Vicario, Compositional Validation of Time- Critical Systems using Communicating Time Petri Nets, IEEE Transactions on Software Engineering, Vol 21 No 12, Dec 1995, pp [6] C. Capellmann, H. Dibold and U. Herzog, Using High- Level Petri Nets in the field of Intelligent Networks, Lecture Notes In Computer Science 1605, Applications of Petri Nets to Communication Networks, Springer-Verlag, [17] C.M. Woodside, A Three-View Model for Performance Engineering of Concurrent Software, IEEE Transactions on Software Engineering, Vol 21 No 9, Sep 1995, pp [18] M. Zhou, K. Venkatesh, Modeling, Simulation And Control Of Flexible Manufacturing Systems A Petri Net Approach, World Scientific, 1999, isbn x. [19] HPSIM Petri Net simulation tool, Copyright (C) Henryk Anschuetz was used to build the Petri Net in Figure 5. [7] J. Carlson, Languages and Methods for Specifying Real- Time Systems, MRTC report, Mälardalen Real-Time Research Centre, Mälardalen University, Aug [8] K. Duddy, UML2 Must Enable a Family of Languages, Communications of the ACM, Vol. 45 No.11, Nov 2002, pp [9] Z. Gu and K.G. Shin, Analysis of Event-Driven Real- Time Systems with Time Petri Nets, IFIP World Computer Congress 2000, Stream 7 on Distributed, Parallel& Embedded systems, University of Michigan, [10] B.R. Haverkort, Performance Evaluation of Polling- Based Communication Systems using SPNs, Lecture Notes In Computer Science 1605, Applications of Petri Nets to Communication Networks, [11] J.W. Janneck, R. Esser, Higher-order Petri Net modeling Techniques and Applications, Conferences in Research and Practice in IT Series, Vol 12, Adelaide Australia, 2002, pp [12] Lecture Notes from the 21 st International Conference On Application And Theory Of Petri Nets, Aarhus, Denmark, Jun [13] J. Martin, M. Odell, Object-Oriented Methods: A Foundation, Prentice Hall, [14] M. Reid, W.M. Zuberek, Timed Petri Net Models of ATM LANs, Lecture Notes In Computer Science 1605, Applications of Petri Nets to Communication Networks, Springer-Verlag, [15] C. Rust, F. Stappert, and R. Bernhardi-Grisson, Petri Net Based Design of Reconfigurable Embedded Real-Time Systems, Distributed and parallel et. Publishers, Univ. of Paderborn, Germany, [16] J.P. Tsai, Y. Dong BI, S.J. Yang, Debugging for Timing-Constraint Violations, IEEE Software Engineering, Vol 13-2, Mar 1996, pp