Petri Nets Modeling & Analysis for Corporate Energy Invoice and Automation Management Software

Petri Nets Modeling & Analysis for Corporate Energy Invoice and Automation Management Software Jamshaid Iqbal Janjua Al-Khawarizmi Institute of Computer Science University of Engineering & Technology, Lahore, Pakistan jamshaid.janjua@kics.edu.pk Dr. Zubair A. Khan Dean, Department of Electrical Engineering University of Engineering & Technology Lahore, Pakistan deanee@uet.edu.pk Dr. Farooq Ahmed Dean, Faculty of Information Technology University of Central Punjab Lahore, Pakistan dr.farooq@ucp.edu.pk Abstract Reliability and Conformance with the requirement specifications are the basic points of interest for the verification and validation of developed software in software engineering. Formal methods are a well researched area in verification and validation of software production. We discuss the mathematical approach by using Petri Nets (PN), to model the dynamic behavior of high level complex software, developed for corporate energy management in the open source development environment. Further, we discussed analysis of PN features like reachibility, deadlock, liveness and reversibility upon the modeled PN of developed software to prove the reliability & conformance of the developed software with software requirements. Keywords- Software Verification, Software Validation, Formal Methods, Petri Nets, Dynamic Behaviour Modeling, Open Source Environment, Energy Sector, PPA. S OFTWARE systems have become the part of every circle of human life. Dependable systems are crucial for efficient working in the modern world. The software running the logical sequences of the algorithms to perform certain tasks, are the underline heart beat of these systems [1]. It deals with our financial management [2], regulates power generation [3], pedals various systems and process security-critical information. Invoices are the integral part of financial software which is used where services or products are provided [4][5]. The complexity of the invoices is pertinent in accordance with the problem domain. The flexibility and complexity of the software systems makes the requirements conformance a challenging task for the developers. This requires a solid modeling and analysis for its operational responsibilities. As a result, the skillful development of reliable software is of every growing importance that is in accordance with the requirements and specifications. G I. INTRODUCTION OVERNMENT of Pakistan announced a latest policy for the future electric power production projects in 2002. This policy is endorsed by National Electric Power Regulatory Authority (NEPRA). To make this policy effective, a new standard Power Purchase Agreement (PPA) has been developed by National Transmission & Dispatch Company (NTDC). This resulted in definition of a demand for an Efficient Data Collection, and Invoice Processing Automation System which implements the rules and regulations of the PPA in its best form. The new PPA of 2002 revolves around the basic concept of financial transactions based on the Complex Availability dependant billing. The main interacting bodies are Independent Power Producers (IPPs) and NTDC as Power Purchaser (PP) which operates through NTDC sub companies, Central Power Purchasing Agency (CPPA) & National Power Control Center (NPCC) also called as System Operator (SO). CPPA deals with the financial transactions regarding the sale and purchase of power between power generation and power distribution companies. The NPCC is responsible for secure, safe and reliable operations on the national power grid through proper control and dispatch instruction to IPPs and other power production facilities. In order to implement demand identified for an automated enterprise grade data collection and invoicing software, we developed a software system named Invoice Processing & Automation System (IPAS) [6]. This system assists WAPDA and IPPs to operate in a time efficient manner as compared to the existing manual or semi automated

invoicing processes for IPPs. The system supports the transparency that refers to the vision of a glass tube though which the stakeholders can see the whole status of power production to the distribution facade. Another important feature of system automation is to focus on the paperless paradigm for sale and purchase of power. Invoice Processing & Automation System (IPAS) This system can be classified as corporate energy management system. It makes available a platform to energy regulatory bodies to have cleanest and crystal clear conduct of agreed terms and conditions with IPPs in PPA and proficient management of WAPDA s own energy resources. IPP s in accordance with PPA, are required to declare their available production capacity in advance, 12 months, 3 months, 14 days and 24 hours for medium & short term complex availability commitment. Followed by these obligations the IPPs are incessantly providing the changes in available capacity due to much unexpected environmental aspects and unforeseen conditions until the energy is generated and delivered in the particular operating hour. The NPCC watch this available capacity declaration from IPPs, while giving the Dispatch Instruction to an IPP for competent load balancing on the National Power Grid. Keeping in view this both side obligations, the IPP delivers the net electrical output energy at ambient conditions (temperature, pressure, humidity, etc.) under particular complex full or limited loading conditions with dissimilar fuel based energy production units. The complex maintenance also have an impact on the available capacity declaration of IPP, which are covered in certain complex outages allowances for scheduled and non scheduled outages for an agreement year. These factors have an effect on the calculations of the monetary instruments for IPPs, primarily such as Capacity Payments for administrative and operational costs, Energy Payments for fuel utilization for energy production and Liquidated Damages intended for the result of IPPs not satisfying the both side complex availability commitment or not operating up to the required performance levels as per the PPA. We have developed this system in full with all these preliminary outputs and supporting information. The outputs of the developed software are persevered in the central repository classified as technical and financial data disjointedly. The developed software system is engineered and finished using the open source technologies & tools environment (JSF, J2EE, MySql, etc.). We have processed several technical and financial information from different fuel based IPPs for more than twelve months and efficiently produced the results as per PPA indicating the issues and point of differences of the manual system well thought-out as human error or manual handing difficulty of the PPA due to its half hourly based calculations [6]. Petri Nets (PN) are mathematical as well as graphical tool for dynamic modeling and performance evaluation of information processing systems, which are characterized as being concurrent, asynchronous, distributed, parallel or stochastic [7]. Its powerful features not only assists in understanding of the dynamic behavior of the system but can also determine the different performance constraints that helps in providing orientation for system architecture and the options of parameters for the modeled system [15]. As a graphical tool, PN can be used as a visual communication aid similar to flow charts, block diagram, networks etc [8]. As a mathematical tool, linear programming, linear algebraic and graph theoretic techniques are applicable for verification of the modeled system. PN can be used for both theoreticians and practitioners. The paper proposes the PN oriented method for the evaluation of software dependability and conformance through the analysis of the PN model of a developed system. This method can assist in order to verify and validate the developed system effectively as per the requirements, rules and regulations of PPA in this case, which further reduces the complication of describing and analyzing the software reliability. The paper is organized as follows. In Section II, we briefly discuss the basic concepts and definitions of the Petri Nets used in modeling of the developed corporate energy invoice and automation management software. In Section III, we discuss the proposed Petri Nets model for the said software. Our approach for application of Petri Nets features analysis to prove the reliability and conformance of the software is summarized in Section IV. Finally, the paper is concluded in Section V, followed by details of the modeled Petri Net in Section VI. M II. BASIC CONCEPTS & DEFINATIONS AIN power of Petri nets is their assistance for analysis of specified properties in the understudy software like reachibility, liveness, reversibility, safeness and boundedness, etc. Determining whether software shows a specific functional behavior or not, is a cardinal issue in verification and validation of the complex software & even in the modeling of the software. This contributes effectively in an early finding of whether or not a system modeled with Petri nets shows all desirable properties, as specified in the requirements & functional specifications.

The overall behavior of software can be described in terms of global states of software and their transformations [9]. In order to simulate the dynamic behavior of a system, a marking in PN is modified according to the enabling and firing rules of transitions which actually simulates the software code path execution pattern. Starting with initial marking, transition firings yield new markings that in turn give rise to further transition occurrences. Some basic definitions of Petri Nets and their properties are discussed related to the modeled software. The associated terminology & information are mostly taken from [7] & [10]. Definition 1: (Petri net)[10]. A Petri net PN is 5 tuple: set of finite places P, set of finite transitions T, input function I and output function O and initial marking M o : PN = (P,T,I,O,M o ). The input function I is mapping from transition tj to a collection of places I(tj), known as input places of tj. The output function O maps a transition tj to a collection of places O (tj) i.e. I: T P, and O: T P. The directed arcs from places to transitions are shown by mapping I: T P and the directed arcs from transitions to places are shown by mapping O: T P such that P T = Ø and P T = Ø. M: T P defines a marking function in PN, where as initial marking is denoted by M o. PN structure without M o is defined as 4 tuple N where N = (P, T, I, O). PN with a known initial marking is represented by (N, M o ). Suppose I(tj) shows the set of input places of a transition tj, where tj T & pi P, then input function is a mapping from T P if pi is an input place of a transition tj and pi I(tj). Further, O (tj) shows the set of output places of a transition tj, where tj T & pi P, then output function is also a mapping from T P, if pi is an output place of a transition tj and pi O (tj). Definition 2: (Reachibility) [7]. A marking M n is considered to be reachable from a marking M 0 if there exists a sequence of firings σ that transforms the markings from M 0 to M n. If M n is reachable from M 0 by σ, then we write M 0 [σ > M n. The set of all reachable markings from M 0 is denoted by R(M 0 ) which is a distinct set of markings of PN such that, if M k R(M 0 ) and firing of transition tj T : M k [tj > M k, then also M k R(M 0 ). Definition 3: (Deadlock)[11]. A transition tj is considered to be a dead transition at marking M k R(M 0 ) if there does not exist any reachable marking that enables a transition tj. A marking M k R(M 0 ) is considered to be in a deadlock. A PN is said to be deadlock-free if and only if there is no deadlock. Definition 4: (Liveness)[7]. A transition tj T is said to be live if for all M k R(M 0 ) there is marking reachable M k from M k such that M k enables tj and PN (N, M 0 ) is live if all tj T: tj is live. Definition 5: (Reversibility)[12]. Any marking M k of PN is considered reversible only if for each marking M k which is reachable from M k there exist a transition firing sequence σ that regenerates the marking M k from M k. A PN is considered reversible only if M 0 is reversible. S III. PROPOSED MODEL OFTWARE is designed initially with different diagrams. These diagrams assist in understanding of the basic architecture at different levels of the software [13]. The developed system IPAS, which is under study here is complex technical and financial data treatment software. It has twelve developed modules which processes the information at different levels to achieve the useful desirable functions as the end result of the software. These modules can be classified in four groups such as technical input, financial input, data filtration and output groups. The developed modules can be classified as: 1) Technical Input Group a) Chronological Data Management (CDM) b) Plant Availability Management (PAM) c) Data Collection Management (DCM) d) Metering Data Management (MDM) e) Technical Limits Management (TLM) f) Force-majeure Events Management (FEM) 2) Financial Input Group a) Tariff Indexation Management (TIM) b) Banked Energy Management (BEM) 3) Data Filtration Group a) Complex Outages Management(COM) 4) Output Group a) Capacity Invoice Management (CPM) b) Energy Invoice Management (EPM) c) Liquidated Damages Management (LDM) The overall major high level module interaction can be depicted by the module interaction diagram as shown in Figure 1 and the high level detail of the input parameters is shown in Table 1. The major information exchange between the modules is shown. The data flow is identified from the input information to the ultimate processed output. As the software is designed and developed on hourly calculations as per the basic requirement of the PPA, so the ultimate objective is to generate the Capacity Payment, Energy Payment and Liquidated Damages Payment, firstly for any hour than for a day and finally for a month.

Input ID Input Name Input ID Input Name CDM: 1 PPA information with COD TIM:5 WPIadjust PAM: 1 Declaration Complete Versions with Intimation/Ack times TIM: 6 Fuel Cost PAM: 2 Dispatch Complete Versions with Intimation/Ack times TIM:7 LIBOR MDM : 1 DNEO from all Meters TIM:8 KIBOR MDM: 2 Ambient Temp from Weather Station TIM:9 Supplementary Tariff DCM : 1 DNEO for an Hour TIM:10 CPP DCM: 2 Ambient Temp for an Hour TIM:11 EPP TLM: 1 Complex Event Type OUT: 1 Final Declaration for an Hour FEM: 1 FM Event Start Date OUT: 2 Final Dispatch for an hour FEM: 2 FM Event End Date OUT: 3 DNEO for Hour FEM:3 FM Event Type OUT: 4 Ambient Temp for an hour TIM :1 Reference Parameters LDM:2 Declaration based LDs TIM :2 Reference Prices LDM:1 Shortfall based LDs TIM :3 Fxadjust BEM :1 Banked Energy Deposit TIM : 4 CPIadjust BEM:2 Banked Energy Withdrawal Table 1. Modules Input Information Each part of basic module input parameter is injected in the system either by data entry or any equivalent form. A state is possible if and only if the state composition requirements are fulfilled such as if all the set of input parameters are available for a specific state only then the state is said to be possible. To show whether a state is possible or not a token representation is used in Petri nets. Absence of a token means that the state is not active in PN or it is not yet reached by other places in the dynamic system environment. The initial marking in this case may be defined as the availability of all the input parameters required for the data input places. The module interaction diagram in Figure 1 can further be used to convert the software into equivalent PN model into the form of parallel process net (PPN) [10] with some exceptions. The states of the software become the places whereas the major functions become the transitions in PN. Input set related with every module can be decomposed in the set of places such that P M1 = {p1, p2,..., pn} becomes a finite set of places. By taking union of the input sets of all modules we can generate set of all places in PN such as P = { P M1 P M2 P M3... P MN } and P > 0. Similarly, all the major module functions are taken as finite set of transitions such that T = {t1, t2,..., tn} for the PN. TIM: 1,2,3,4,5,6,7,8 BE: 1,2 FEM BEM FME: 1,2,3 TIM TIM: 11 CDM: 1 EPM Energy Invoice CDM TLM PAM TLM: 1 COM CPM PAM: 1,2 OUT: 1,2,3,4 MDM: 1,2 TIM: 9,10 DFS MFS OUT: 1,2,3,4 DFS MFS Capacity Invoice Figure 1. Module Interaction Diagram DCM: 1,2 MDM DCM LDM LDM:1,2 When the enabled transition is fired it changes the token placement according to the transition firing rule. The sequence generated from firing of transitions produces the sequence of marking. Once a transition tj is fired, it consumes tokens from the I(tj) and add tokens to O (tj). The change in the state of the software can be simulated by the new positions of markings of tokens in the PN. Further this can be extended to fire next enabled transitions in the PN until the final outputs of the software are achieved. The modeled petri net PN for IPAS is shown in Figure 2. As recalled from above, the markings represent the states of the software execution and transition tj can only be enabled if its set of input places I(tj) P have tokens. This consumes tokens from I(tj) and introduce new tokens in O(tj). This is also called the enabling rule for transitions. This activity results in a new state of the software referred as M k th marking.

. T0 P0 { T26 P11 P10 P9 T25 P8 T8 P7 T7 P6 T6 P5 T5 P4 T4 P3 T3 T2 P2 P1 T1 P20 P19 P18 P17 P16 P15 P14 P13 P12 T28 T27 T12 T11 T10 T9 P27 P26 P25 P24 P23 P22 P21 T13 P29 P28 T14 T15 P32 P31 P30 T17 T19 P37 T16 P35 T20 P34 P33 T21 P40 P39 T23 P38 P36 T18 P43 T22 T24 (Tf) P42 P41 Figure 2. Modeled Petri Net (PN) for Developed Software The initial marking in the modeled PN is the M 0 results in the productions of the next markings depending upon the transition enabling rules. Any marking M k is followed by M k which contributes a sequence of firing sequence σ (sigma). This can be referred as the order of the firing transitions in the PN of the system, which in fact can be used to detect the flow of the code path coverage in the developed software. The final marking M f is the final state of the software execution, in this case the generation of Capacity Invoice, Energy Invoice and Liquidated Damages Invoice.

In order to make the PN, first requirement is to generate the set of places P and set of transitions T, we have a set of 45 places and 25 transitions. The detail of each is shown in the Table 3 and Table 4 in Section V of the paper. The initial state of the software PN is M 0 = (p 0 ), hence the initial token is in p 0 place, this enables the transition t 0 as the pre condition places such that all places in the set I (t 0 ) = {p 0 } have tokens and the output places belonging to set O (t 0 ) = {p1, p2, p3, p4, p5, p6, p7, p8, p9, p10, p11} donot have tokens. When t 0 is fired a new set of markings M 1 = (p1, p2, p3, p4, p5, p6, p7, p8, p9, p10, p11) is generated. This will enable other transitions in the PN. Table 2 shows the production of all the markings from the software modeled PN. The above mentioned fired transition t 0, contributes as a first transition in the firing sequence σ = t 0. Transition Modeled PN Generated Markings M k Modeled PN Generated Firing Sequence σ M 0 =(p 0 ) t 0 M 1 =( p 1,p 2,p 3,p 4,p 5,p 6,p 7,p 8,p 9,p 10,p 11 ) σ = t 0 t 1 M 2 =( p 2,p 3,p 4,p 5,p 6,p 7,p 8,p 9,p 10,p 11,p 21 ) σ = t 0 t 1 t 2 M 3 =( p 3,p 4,p 5,p 6,p 7,p 8,p 9,p 10,p 11,p 12,p 21 ) σ = t 0 t 1 t 2 t 3 M 4 =( p 4,p 5,p 6,p 7,p 8,p 9,p 10,p 11,p 12,p 13, p 21 ) σ = t 0 t 1 t 2 t 3 t 9 M 5 =( p 4,p 5,p 6,p 7,p 8,p 9,p 10,p 11, p 21,p 22 ) σ = t 0 t 1 t 2 t 3 t 9 t 4 M 6 =( p 5,p 6,p 7,p 8,p 9,p 10,p 11, p 14,p 21,p 22 ) σ = t 0 t 1 t 2 t 3 t 9 t 4 t 5 M 7 =( p 6,p 7,p 8,p 9,p 10,p 11,p 14,p 15,p 21,p 22 ) σ = t 0 t 1 t 2 t 3 t 9 t 4 t 5 t 10 M 8 =( p 6,p 7,p 8,p 9,p 10,p 11, p 21,p 22,p 23 ) σ = t 0 t 1 t 2 t 3 t 9 t 4 t 5 t 10 t 6 M 9 =( p 7,p 8,p 9,p 10,p 11,p 21,p 22,p 23,p 16 ) σ = t 0 t 1 t 2 t 3 t 9 t 4 t 5 t 10 t 6 t 11 M 10 =( p 7,p 8,p 9,p 10,p 11,p 21, p 22,p 23,p 24 ) σ = t 0 t 1 t 2 t 3 t 9 t 4 t 5 t 10 t 6 t 11 t 13 M 11 =( p 7,p 8,p 9,p 10,p 11,p 28,p 29 ) σ = t 0 t 1 t 2 t 3 t 9 t 4 t 5 t 10 t 6 t 11 t 13 t 7 M 12 =( p 8,p 9,p 10,p 11, p 17,p 28,p 29 ) σ = t 0 t 1 t 2 t 3 t 9 t 4 t 5 t 10 t 6 t 11 t 13 t 7 t 8 M 13 =( p 9,p 10,p 11, p 17,p 18,p 28,p 29 ) σ = t 0 t 1 t 2 t 3 t 9 t 4 t 5 t 10 t 6 t 11 t 13 t 7 t 8 t 14 M 14 =( p 9,p 10,p 11,p 17,p 18,p 29,p 30,p 31 ) σ = t 0 t 1 t 2 t 3 t 9 t 4 t 5 t 10 t 6 t 11 t 13 t 7 t 8 t 14 t 12 M 15 =( p 9,p 10,p 11, p 18,p 25, p 29,p 30,p 31 ) σ = t 0 t 1 t 2 t 3 t 9 t 4 t 5 t 10 t 6 t 11 t 13 t 7 t 8 t 14 t 12 t 25 M 16 =( p 10,p 11,p 19,p 18,p 25,p 29,p 30,p 31 ) σ = t 0 t 1 t 2 t 3 t 9 t 4 t 5 t 10 t 6 t 11 t 13 t 7 t 8 t 14 t 12 t 25 t 27 M 17 =( p 10,p 11,p 18,p 25,p 29,p 26,p 30,p 31 ) t 16 M 18 =( p 10,p 18,p 11,p 33,p 34,p 29 ) t 16 t 18 M 19 =( p 18,p 11,p 10,p 36,p 29 ) t 16 t 18 t 20 M 20 =( p 11,p 18,p 10,p 38,p 29 ) t 16 t 18 t 20 t 22 M 21 =( p 11,p 18, p 10,p 41,p 42,p 29 ) t 16 t 18 t 20 t 22 t 26 M 22 =( p 18,p 10,p 20,p 41,p 42,p 29 ) t 16 t 18 t 20 t 22 t 26 t 28 M 23 =( p 10,p 18,p 27,p 41,p 42,p 29 ) t 16 t 18 t 20 t 22 t 26 t 28 t 15 M 24 =( p 10,p 18,p 27,p 29,p 32,p 41,p 42 ) t 16 t 18 t 20 t 22 t 26 t 28 t 15 t 17 M 25 =( p 10,p 18,p 29,p 35,p 41,p 42 ) t 16 t 18 t 20 t 22 t 26 t 28 t 15 t 17 t 19 M 26 =( p 10,p 18,p 29,p 37,p 41,p 42 ) t 16 t 18 t 20 t 22 t 26 t 28 t 15 t 17 t 19 t 21 M 27 =( p 10,p 18,p 29,p 39,p 40,p 41,p 42 ) t 16 t 18 t 20 t 22 t 26 t 28 t 15 t 17 t 19 t 21 t 23 M 28 =( p 10,p 18,p 29,p 43,p 41,p 42 ) t 16 t 18 t 20 t 22 t 26 t 28 t 15 t 17 t 19 t 21 t 23

t f M 29 =(p 0 ) M Table 2. t 16 t 18 t 20 t 22 t 26 t 28 t 15 t 17 t 19 t 21 t 23 t f Modeled Petri Net (PN) Generated Markings & Firing Sequences IV. ANALYSIS ODELED petri net can now be verified in reference with the various properties as discussed in the definitions in a previous section. Firstly, reachibility property of PN is used to simulate achievable states of the software. Let, we want to verify whether or not a desirable marking M 16 = (p 10,p 11,p 19,p 18,p 25,p 29,p 30,p 31 ) is reachable from a current system marking M 3 = (p 3,p 4,p 5,p 6,p 7,p 8,p 9,p 10,p 11,p 12,p 21 ) while considering from the possible markings from the Table 2, such that M 3 is M k marking and M 16 is M k then by applying the firing sequence σ = t 3 t 9 t 4 t 5 t 10 t 6 t 11 t 13 t 7 t 8 t 14 t 12 t 25, we can reach from M k to M k and vice versa is true from firing sequence σ = t 25 t 27 t 16 t 18 t 20 t 22 t 26 t 28 t 15 t 17 t 19 t 21 t 23 t f t 0 t 1 t 2. Hence, M 3 [σ > M 16 is true and the reachibility property is proved resulting that we can reach any desirable state from any possible desired state in the software. Secondly, deadlock detection property is used to determine whether or not the modeled PN have any deadlock existence [14]. Considering the possible markings in the Table 2, we can observe from PN iterations that there does not exist any transition tj that remains disabled by any reachable marking of the system or every transition is fired and is not permanently disabled in the modeled PN. Hence, the deadlock is not detected in the modeled software. Thirdly, the deadlock freeness of the modeled PN can be proved due to the absence of the deadlock in the system. This means that every I (tj) and O (tj) work under transition firing rules for the PN. Hence, the modeled software is live in nature. Lastly, the reversibility property is used to simulate that the system is reverserable to a certain desirable state by a sequence of firing sequences σ which defines the sequence of firing transitions. This helps to understand the code path execution analysis of the modeled system. The possible markings in Table 2 shows that the overall modeled PN is starting with the initial marking M 0 = (p 0 ), can be reversed to its initial marking M 0 = (p 0 ) by executing the firing sequence t 16 t 18 t 20 t 22 t 26 t 28 t 15 t 17 t 19 t 21 t 23 t f. Hence, the modeled software is also reversible to its initial state. Therefore, above analysis converges to a point that the developed system that is modeled through PN is reachable, deadlock free and reversible in nature. This means that the software is in the light of its design and information exchange pattern is workable, stable, dependable and its architecture supports the dynamic code execution. Furthermore, it also identifies the firing sequences of the transitions with respect to major functional activity in the software and can assist in proving the conformance to the requirement specification for the developed software. D V. CONCLUSION YNAMIC behavior modeling & analysis is an important activity for the software verification and validation that leads to the overall software reliability and conformance to requirement specifications. The formal approaches are computational intensive but that can be easily utilized in evaluation of different developed software at high levels. In this paper, we discussed a corporate energy invoice and automation software modeling in a class of nets called Petri nets and then their feature analysis in order to simulate and determine whether or not the developed system is deadlock free, reachable and reversible, which assists in the identifying the developed software as workable, stable, dependable for performing functional activity that obey the rules in the requirement specifications. Table 3. VI. APPENDIX Places Table Modeled Petri Net (PN) Places Table Place Module Place Name p 0 Initial State (Master state) p 1 CDM PPA Information p 2 PAM All versions of Complex Availability Declaration are available for an IPP p 3 PAM All versions of Dispatch Instructions are available for an IPP p 4 MDM Ambient Temperature is available p 5 MDM All Meter Readings are available p 6 TLM Data available for TLM p 7 FME FME data is available to the system p 8 TIM TIM data is available to the system required for supplementary tariff p 9 TIM Unique indexations parameters of TIM p 10 TIM Attributes of TIM common to CPP&EPP p 11 TIM Unique indexations parameters of TIM to be used in EPP p 12 PAM Valid Complex Availability Declaration available to the system

p 13 PAM Valid Dispatch Instruction available to the system p 14 DCM Value of ambient temperature is available to the system after rounding off. p 15 DCM Commulative Dneo is available to the system. p 16 FME TLM event is available to the system. p 17 TIM FME data (Start date, End date & Type) is available. p 18 TIM TIM data is available to the System for the calculation of Supplementary Tariff p 19 CPM CPP is available p 20 EPM EPP is available p 21 CDM PPA Information available to the System p 22 PAM Final Declaration & Dispatch instruction is available. p 23 DCM Commulative Dneo and rounded value of ambient temperature is available. p 24 TLM Hourly TLM event is available. p 25 TIM Supplementary Tariff is prepared. p 26 CPM Indexed CPP is available to the system. p 27 EPM Indexed EPP is available to the system. p 28 PAM SO & FO Allowances p 29 PAM Combined Technical data on the basis of an hour p 30 LDM LDs generated p 31 CPM Qualifying Capacity p 32 EPM Qualifying Energy p 33 CPM LDs payment p 34 CPM Capacity Payment p 35 EPM Daily Fact Sheet for Energy p 36 CPM Daily Fact Sheet for Capacity p 37 EPM Monthly Fact Sheet for Energy p 38 CPM Monthly Fact Sheet for Capacity p 39 EPM Qualifying Energy p 40 BEM Data from Banked Energy p 41 CPM Final Invoice for Capacity p 42 LDM Final Bill for Liquidated Damages p 43 EPM Final Invoice for Energy Transition Table t 8 TIM Provision of TIM data(other than FME data) to the system for the preparation of Supplementary Tariff t 9 PAM Provides the latest valid Declaration/Dispatch pair for an IPP t 10 DCM Provision of Dneo & Ambient Temperature to the system t 11 TLM Provision of TLM event to the system for an hour t 12 TIM Preparation of Supplementary Tariff t 13 PAM Acquisition of Technical Data t 14 CPM Data acquisition for CPP t 15 EPM Data Processing for the calculation of EPI t 16 CPM Data Processing for the calculation of CPI t 17 EPM Preparation of DFS of Energy t 18 CPM Preparation of DFS of capacity t 19 EPM Preparation of Monthly Fact Sheet of Energy t 20 CPM Preparation of Monthly Fact Sheet of Capacity t 21 BEM Processing with data from Banked Energy t 22 CPM Preparation of CPI and LDBs t 23 EPM Preparation of Energy Invoice t 24 Loop back to the Initial state t 25 CPM Calculation of CPP t 26 EPM Calculation of EPP t 27 CPM Provision of indexed CPP t 28 EPM Provision of indexed EPP W VI. ACKNOWLEDGMENT E are grateful to Al-Khawarizmi Institute of Computer Science, University of Engineering & technology, Lahore, Pakistan, for providing us the platform to work on the Invoice Processing & Automation System (IPAS). We also acknowledge WAPDA, Pakistan for project funding that helped us to complete the initiative. Table 4. Modeled Petri Net (PN) Transitions Table VII. REFERENCES Transition Module Transaction Name t 0 Master Reset t 1 CDM Fetch PPA information from Chronological Data Management. t 2 PAM Provide valid Declaration instructions to the system t 3 PAM Provide valid Dispatch instructions to the system t 4 DCM Ambient Temperature Rounding off t 5 DCM Preparation of Commulative Dneo t 6 TLM Provision of TLM event to the system t 7 FME Provision of FME data to the system [1] Roberto Pietrantuono, Stefano Russo, Kishor S. Trivedi, "Software Reliability and Testing Time Allocation: An Architecture-Based Approach," IEEE Transactions on Software Engineering, vol. 36, no. 3, pp. 323-337, May/June, 2010. [2] Hunter P., Focusing on finance [financial software], Institution of Engineering and Technology, Stevenage, ROYAUME-UNI, 2010, vol. 5, no7, pp. 52-55, ISSN 1750-9645 [3] Di Paolo, I.F.; Cordeiro, T.D.; Sena, J.A.S.; Fonseca,

M.C.P.; Barra, W.; Barreiros, J.A.L.; Silva, O.F.;, "Creational Object-Oriented Design Pattern Applied to the Development of Software Tools for Electric Power Systems Dynamic Simulations," Latin America Transactions, IEEE, vol.8, no.3, pp.287-295, June 2010 [4] Eduardo B. Fernandez, Xiaohong Yuan, An Analysis Pattern for Invoice Processing, 16th Conference on Pattern Languages of Programs, August 28-30, 2009, Chicago. [5] WANG Quan-bin, Design and Implementation of Invoicing Management System of Storage Enterprises, Journal of Tonghua Normal University, April 2009. [6] Jamshaid I. Janjua & Dr. Zubair A. Khan, Real-time, Efficient E-Infrastructure Development Framework for Corporate Energy Sector, IEEE International Conference on Intelligence and Information Technology (ICIIT-2010), Lahore, Pakistan, 28th-30th October 2010, IEEE Catalog Number: CFP1071K-PRT, ISBN: 978-1-4244-8138-5. [7] Murata, T., Petri nets: Properties, Analysis and Application, In Proceedings of IEEE, Vol. 77, No. 4, pp. 541-580, 1989. [8] Reisig, W. Petri Net: An Introduction, Springer-Verlag, 1985. [9] A. Karatkevich, Dynamic Analysis of Petri Net-Based Discrete Systems, LNCIS 356, Springer-Verlag, Berlin Heidelberg, 2007. [10] Peterson, J. L., Petri Net theory and the Modeling of Systems, Prentice-Hall, 1981. [11] Z. Li, and M. C. Zhou, On siphon computation for deadlock control in a class of Petri nets, IEEE Trans. on Systems, Man, and Cybernetics-Part A: Systems and Humans, 38(2008): 667-679. [12]Reveliotis, S., A Necessary and Sufficient Condition for the Liveness and Reversibility of Process-Resource Nets With Acyclic, Quasi-live, Serializable, and Reversible Process Subnets, Automation Science and Engineering, IEEE Transactions, pp 462-468, Volume: III, Oct. 2006 [13] Li Xiaoli,Long Xiang,Bao Xiaolu,Li Hu, Formal definition and characteristic analysis of UML sequence diagram Journal of Beijing University of Aeronautics and Astronautics [J. Beijing Univ. Aeronaut. Astronaut.]. Vol. 36, no. 3, pp. 350-352, 362, Mar 2010. [14] F. Ahmad, H. Huang, X. L. Wang, Petri net modeling and deadlock analysis of parallel manufacturing processes with shared-resources, Journal of Systems and Software, vol. 83, pp. 675-688, 2010. [15] Sun, T.H., Cheng, C.W., Fu, L.C., A Petri net based approach to modeling and scheduling for an FMS and a case Study. IEEE transactions on Industrial Electronics 41 (6), 593 601, 1994.