IEEE TRANSACTIONS ON POWER SYSTEMS, VOL. 21, NO.

2, MAY 2006

611

Development of Power Flow Software Using Design Patterns

M. P. Selvan, Student Member, IEEE, and K. S. Swarup, Senior Member, IEEE
AbstractApplication of object-oriented design patterns for the development of power system computation software is presented. Important patterns such as Iterator, Decorator, and Template Method are utilized to develop a comprehensive power ow (load ow) analysis program, including FACTS devices such as SVC, TCSC, STATCOM, and UPFC. Analysis-independent object models of power system components are obtained by untying the attributes required for computation from the attributes representing the physical characteristics of an object. The proposed object-oriented design of power ow computation has been implemented in C++ on windows environment. The performance of the developed program has been tested with IEEE benchmark systems. Index TermsDesign patterns, FACTS devices, object-oriented development, power ow analysis, power system computation.

I. INTRODUCTION OWER system computation forms an integral part in power system planning, design, operation, and control. Power system researchers have been exploiting the advantages of object-oriented methodology (OOM) to address the issues involved in the development of power system analysis software used in the Energy Management System (EMS) since the early 1990s. The object-oriented approach was applied for the development of efcient sparse matrix computation tools in [1] and [2]. Few papers in the literature [3], [4] concentrate on obtaining a common object model for the power system that supports various analysis modules. Specic applications, such as load ow, online network analysis, dynamic simulation, etc., are dealt with in [5][9]. Object-oriented modeling of the distribution system is given in [10][13]. Zhu and Jossman [14] attempted the use of design patterns, an advanced technique of OOM, for modeling the objects of power system. Object composition and proxy design patterns have been effectively used in [14] to achieve modeling exibility. Neyer et al. [5] proposed an object-oriented design of power system components for load ow analysis. The local processing mechanism of object-oriented methodology was well utilized in [5] for obtaining exible software. PQNode, PVNode, and SlackNode are derived from the class Node, which is a conceptual object. Computation of the elements of power mismatch vector and Jacobian matrix are made local at the Node and Branch objects. However, the decomposition proposed in [5] is limited
Manuscript received August 18, 2005; revised December 5, 2005. Paper no. TPWRS-00522-2005. The authors are with the Department of Electrical Engineering, Indian Institute of Technology, Madras, Chennai 600036, India (e-mail: selvanmp@yahoo.com; swarup@ee.iitm.ac.in). Digital Object Identier 10.1109/TPWRS.2006.873050

to only NewtonRaphson power ow analysis. The object-oriented decomposition proposed in the present paper can be used also for GaussSeidal and fast decoupled load ow studies. Another hierarchical decomposition of the power system was proposed in [6]. In order to develop a new analysis module, such as fast-decoupled load ow, unbalanced load ow, short circuit analysis, etc., using this hierarchy, new classes of all the power system components have to be derived. Even though the new classes reuse the attributes of the base classes, the size of the inheritance hierarchy evolves as the number of different analysis increases. In this paper, analysis-independent object models of power system components are obtained by separating the attributes required for computation from the attributes representing the physical characteristics. Installation of FACTS devices in the existing network is becoming popular in order to control various parameters of the system. Hence, it is expected to upgrade the existing power ow analysis program to include the behavior of FACTS devices. Fuerte-Esquivel et al. [7] proposed an object-oriented load ow analysis of the systems with FACTS-controlled branches. In [7], LoadFlow and FaultAnalysis classes are inherited from class PowerSystemModel in order to have direct access to the attributes of the physical objects. Though it facilitates fast computation, this model does not comply with the rule of inheritance. Since LoadFlow and FaultAnalysis classes do not satisfy the is a or is kind of relationship with the PowerSystemModel, use of inheritance is not an appropriate choice. Instead, they can be modeled as methods of class PowerSystemModel. In this paper, LoadFlow has been modeled as a separate class, and the analysis is carried out by passing the object of class PowerSystem into the object of class LoadFlow. Similarly, class UPFC is derived from class LoadFlow in [7]. UPFC is a physical device, and LoadFlow is an algorithm class, where the is a or is kind of relationship does not hold well. These shortcomings are overcome in the object-oriented design proposed in this paper. This paper is organized as follows. Section II briefs the concepts of object-oriented design patterns employed in this paper. Section III provides the main objectives of the proposed methodology. Section IV discusses the selection of design patterns for designing the conceptual objects of power ow analysis. Application of design patterns in power ow analysis software is described in Section V. Numerical results are presented in Section VI, and Section VII provides important conclusions. II. CONCEPTS OF OBJECT-ORIENTED DESIGN PATTERNS In the object-oriented paradigm, the problem domain is viewed as a collection of objects interacting with each other to

0885-8950/$20.00 2006 IEEE

612

IEEE TRANSACTIONS ON POWER SYSTEMS, VOL. 21, NO. 2, MAY 2006

achieve a meaningful behavior. The basic principle of OOM is to represent each component of the problem domain by an element called object. A class represents a collection of similar objects and is effectively a template, from which the objects are instantiated. Objects have data or attributes (knows something) and behaviors or methods (does something). Knowing something and doing something are responsibilities of an object. Classes and objects provide a computable representation of the physical system that is convenient for engineers, who naturally think of systems as collection of objects. The process of designing the object-oriented model of a physical system involves 1) nding the appropriate objects, 2) designing the classes at the right granularity, 3) dening class interfaces and inheritance hierarchies and 4) establishing key relationships between the objects. An object-oriented design is reusable, when it is appropriate for the problem at hand, and also general enough to address future problems and requirements. Obtaining a reusable and exible design is a challenging task, and it is an iterative process. In order to expedite the design process, object-oriented designers consult a library of solutions to common system development problems that are proposed by experienced object-oriented designers. Each set of problem and solution in the library is called a design pattern. In general, design patterns are standard solutions to common design problems in object-oriented software design. Design patterns were introduced in 1995 by Gamma et al. [15]. Each pattern identies the key aspects of common design structure, makes an abstraction of it, and names it. These abstracted key aspects are used for creating reusable object-oriented design. Four essential elements of each pattern are Pattern name Solution and Problem Consequences

Fig. 1.

Class diagram of iterator pattern.

access the elements of the aggregate by calling the methods of the iterator object. If a new class of aggregate is introduced in the system, then the corresponding iterator class should also be implemented. The existing aggregate classes do not require any modications. The elements of new aggregate objects can be accessed similar to the existing aggregate objects. B. Decorator Design Pattern A Decorator design pattern is categorized as an object structural pattern. Decorator attaches additional responsibilities dynamically to an object and provides a exible alternative to subclassing for extending functionality. UML representation of the decorator design pattern is shown in Fig. 2. Different decorator objects can attach different responsibilities to a component. Added responsibility may be a new state or a new behavior. Decorator object contains the component object. Whenever the operation of decorator object is invoked, it in turn invokes the operation of the component, as shown in Fig. 2, and also provides its additional responsibility. C. Template Method Design Pattern A Template method design pattern is categorized as a class behavioral pattern. Template method denes the skeleton of an algorithm in an operation, and it allows the subclasses to redene certain steps of an algorithm without changing the algorithms structure. As shown in Fig. 3, the abstract class denes primitive operations and implements a template method. The template method calls primitive operations, which are the skeleton of an algorithm. Concrete class implements the primitive operations to carry out the specic steps of the algorithm. III. PROPOSED METHODOLOGY The following objectives are emphasized in the proposed object-oriented decomposition of the power system. 1) Chosen objects should be analysis independent and should realize the physical nature of the system. 2) The relationship between the physical objects should be replicated in the software objects in order to make the software model more understandable.

There are large numbers of design patterns suitably applied for reusable object-oriented design, which are classied into three broad categories, such as creational patterns, structural patterns, and behavioral patterns. Object-oriented design patterns were introduced to the power system domain in [14] and employed in [12] for physical object modeling of power system components. The present paper has employed design patterns for modeling computational objects in order to gain design extensibility and code reusability. This paper explores iterator, decorator, and template method design patterns for power ow computation. The remainder of this section will focus on the brief description of these patterns. Class diagrams are drawn using unied modeling language (UML) notations [16], [17]. A. Iterator Design Pattern An Iterator pattern is categorized as an object behavioral pattern. It provides a way to access the elements of an aggregate object sequentially without exposing the internal representation of the aggregate object. As shown in Fig. 1, the object of class ConcreteAggregate creates its own iterator (object of class ConcreteIterator) when the method CreateIterator() is invoked. A client can call the aggregate object to create the iterator object. Once the iterator object is created, the client can

SELVAN AND SWARUP: DEVELOPMENT OF POWER FLOW SOFTWARE

613

2) handling different types of buses in the input bus data; 3) need for dynamically changing the bus type during the iterative process due to operating limit violations; 4) reusing the common steps of various power ow algorithms. A. Easy Access of Different Data Structures The power system is modeled using object-oriented methodology prior to developing computational tools. The real-world components, such as bus, branch, generator, load, etc., are modeled as software objects, which are stored in different types of data structures by different clients. Hence, it is mandatory for an analysis tool to have a unique method for traversing different data structures. Iterator pattern was used to solve this problem.
Fig. 2. Class diagram of decorator pattern.

B. Eliminating the Type Information From Class Bus The following are the notation used in this paper to represent different types of buses: PQ Load bus. PVG Generator bus. PVT Voltage controlled bus with tap transformer. PVB Voltage controlled bus with SVC. PVST Voltage controlled bus with STATCOM. In the conventional power ow program, the information about the type of bus is embedded in the input data format. This format of input bus data is not suitable for any other analysis modules, which do not require this type of classication. Moreover, PV and PQ buses do not really exist, and they are formulated only for analysis purposes. Since the bus exists in the real world and its model should be independent of the studies being carried out, it is preferred not to include any type information in the class Bus. The guidelines for the design of objects, proposed by Pollinger et al. [18], also recommend not to include any type parameter in the class attributes. C. Dynamically Changing the Bus Type Generally, the PQ, PVG, PVT, PVB, and PVST buses are dened as subclasses of class Bus. While performing computation, a PVG bus may be converted into a PQ bus due to violations in the reactive power generation limits. Similarly, other types of PV buses may also be converted into a PQ bus due to operating limit violations. In the literature, this situation is handled by including a ag in the class PVBus, which toggles from 0 to 1, when the bus type changes [19]. Application of inheritance and the use of ags will be cumbersome when two or more voltage controlling devices are connected at the same bus. Moreover, Coads rule [20] states that inheritance should be used when a subclass expresses is a special kind of and not is a role played by a super class and an instance of a subclass never needs to become an object of another class. In our study, PVG, PVT, PVB, PVST, and PQ buses are not special kinds of Bus; instead, they are different roles played by Bus. Hence, it is decided not to make PVGBus, PVTBus, PVBBus, PVSTBus, and PQBus as subclasses of class Bus and not to include any ag in the class Bus to indicate the type

Fig. 3. Class diagram of template method pattern.

3) Conceptual objects, which are mostly designed for computational purposes, should be different from the physical objects and may vary according to the analysis. 4) Code reusability reduces the software development time. The objectives mentioned above are attained by 1) untying the attributes required for computation from the attributes representing the physical characteristics of an object; 2) exploiting the inheritance, association, and aggregation relationships of object-oriented methodology; 3) using iterator and decorator design patterns to nd the appropriate conceptual objects for power ow analysis; 4) enhancing the code reusability in the power ow analysis program using template method design pattern. IV. SELECTION OF DESIGN PATTERNS FOR POWER FLOW ANALYSIS This section describes certain issues involved in power ow analysis, which is a vital tool for power system studies, and the selection of appropriate design patterns to address them. The following issues are considered in this paper: 1) requirement of a unique method to access different data structures;

614

IEEE TRANSACTIONS ON POWER SYSTEMS, VOL. 21, NO. 2, MAY 2006

Fig. 4. Proposed class diagram of power system components.

changes. The decorator design pattern, which can be dynamically attached to and removed from the object, is proposed in this paper to model the different roles played by Bus. D. Reusing the Common Steps Several techniques, such as GaussSeidal, NewtonRaphson, and fast decoupled are available for solving the power ow problem. All those techniques share several common procedures. Template method design pattern, which denes a skeleton of an algorithm in an operation, redening some steps in the subclasses, is used to develop power ow analysis programs employing different solution techniques. This enhances the code reusability. V. APPLICATION OF DESIGN PATTERNS IN POWER FLOW ANALYSIS The proposed decomposition of the power system into objects is shown in Fig. 4. PowerSystem is an aggregation of PSComponents. Load, Generator, and NetworkComponent are different kinds of PSComponent. CSLoad, CILoad, and CZLoad, representing constant complex power, constant current, and constant impedance loads, respectively, are subclasses of class Load. Class Generator is specialized as TurboGenerator and SynCondensor. Bus and Branch are inherited from NetworkComponent. Class Branch is further specialized as SeriesBranch and ShuntBranch. FACTSDevice is also a NetworkComponent. Subclasses of FACTSDevice, class TCSC, and class SVC, shown in Fig. 4 with thick line boxes, also share the attributes of SeriesBranch and ShuntBranch, respectively, using the multiple inheritance technique. Class STATCOM and class UPFC are inherited from FACTSDevice. The power ow models of the FACTS devices proposed by Fuerte-Esquivel et al. [21][23] are used in this paper for implementing NewtonRaphson power ow analysis. Fig. 5 shows the association between power system component objects. Each object of classes Load, Generator, ShuntBranch, and STATCOM are associated with an object of class

Fig. 5.

Association relationship between the classes shown in Fig. 4.

Bus (1). Each object of classes SeriesBranch and UPFC are associated with two bus objects (2). This is indicated in Fig. 5 by the numerals 1 and 2. A. Application of Iterator Pattern In this paper, the decomposed power system objects are stored in linked list data structure. Using iterator design pattern, a ListIterator is created to traverse the linked list. The class diagram of class List and its iterator class ListIterator is shown in Fig. 6. Multiple traversals of an aggregate object can be simultaneously done by different iterators. Fig. 6 can be related with Fig. 1. In Fig. 6, power ow and optimal power ow modules are Clients, as shown in Fig. 1. Tree and List are data structures to store the objects, which can be related to the class ConcreteAggregate in Fig. 1. In this paper, the power system objects (bus, transmission line, shunt capacitor, etc.) are stored in different lists. TreeIterator and ListIterator are ConcreteIterator classes, whose objects are used to traverse the objects of ConcreteAggregate classes, such as Tree and List. Each iterator object has an association with the aggregate object. For instance, as shown in Fig. 6, the TreeIterator object has an association with one Tree object, and the ListIterator object has an association with one List object. B. Application of Decorator Pattern Application of decorator design pattern in the power ow analysis program is shown in Fig. 7. These decorators perform the computations, which are unique for a particular type of bus

SELVAN AND SWARUP: DEVELOPMENT OF POWER FLOW SOFTWARE

615

Fig. 6.

Class diagram illustrating application of literator pattern.

in power ow analysis. NewtonRaphson power ow has been considered in this paper for discussion. Decorators contribute appropriate elements to the power mismatch vector and Jacobian matrix in NewtonRaphson power ow, when they are attached to the bus object. This makes the process of Jacobian matrix formulation easy and extendible during the introduction of new components. Several advantages have been observed while using decorator design pattern, which are as follows. 1) A generalized abstraction of class Bus, which is common for different studies, was obtained by eliminating the type information from the data members of class Bus. Moreover, if a new equipment, which controls the bus voltage, is to be included, then it is required only to derive a new decorator and does not require any modications in the class Bus. Thus, the developed code becomes extendible. 2) When power ow analysis of a large power system with a number of devices for controlling the parameters of the system is carried out, the structure of power mismatch vector and the structure of Jacobian matrix may change in each iteration due to limit violations. In conventional programming, ags are dened for each bus in order to check their type in each iteration so that the dimensions of mismatch vector and Jacobian matrix could be determined at the beginning of each iteration. Due to the introduction of different techniques to control the bus voltage magnitude, the types of buses involved in the analysis evolve. Handling different types of buses is a difcult task in conventional methodology. The method, using a decorator design pattern, proposed in this paper can dynamically change the bus type during the iterative process. The decorators are stored in a list, which can be easily accessed using iterator design pattern. The total size of the individual decorator list can also be obtained using the iterator. This information was used to decide the dimensions of power mismatch vector and Jacobian matrix in the beginning of each iteration. 3) The technique of using decorator design pattern will be more appropriate, when the voltage magnitude of a particular bus is controlled by more than one control mechanism [24]. For instance, assume that a generator, static var compensator, and tap changing transformer control the voltage magnitude of a bus. The bus will be considered as a PVG bus until the reactive power of the generator reaches any of its limits. Then the bus voltage is controlled by SVC. When the ring angle reaches its limit, the voltage magnitude will be controlled by the tap changing transformer.

Fig. 7. Application of decorator design pattern.

If the tap limit violation takes place, then it will be converted to PQBus. Handling this situation in conventional programming leads to multiple type checks and logical loops while computing mismatch vector and Jacobian matrix elements in NewtonRaphson power ow analysis. This can be easily accomplished using the decorator pattern. Initially, the bus will be decorated by PVGDecorator and then by PVBDecorator following the reactive power limit violation. If the ring angle limit violation occurs, then it will be decorated by PVTDecorator. Following the tap limit violation, the bus will be decorated by PQDecorator. During this process, the elements of power mismatch vector and the Jacobian matrix will be contributed by the corresponding decorator. This gives more cohesiveness and less coupling to the class Bus. The structure of mismatch vector and Jacobin matrix of NewtonRaphson power ow are given in (1) and (2)

(1) where for all Bus PQ Decorators; for all Bus PVG Decorators; for all Bus PVT Decorators; for all Line PST Decorators; for all Bus PVB Decorators; for all Line TCSC Decorators; for all Bus PVST Decorators; for all Line UPFC Decorators. See (2) at bottom of the next page. In (1), each element corresponds to the rows contributed by different types of decorais a submatrix contributed by tors. In (2), each element

616

IEEE TRANSACTIONS ON POWER SYSTEMS, VOL. 21, NO. 2, MAY 2006

different types of decorators. The element of submatrix inwith redicates the differentiation of functions of decorator indispect to the variables of decorator . For example, cates the differentiation of functions ( and ) of Busof BusPQDecorator with respect to the variables PVTDecorator, as given in (3) where and represents PQ and PVT buses, respectively. For each total number of PVTbuses
Fig. 8. Class diagram illustrating the use of template method pattern.

The remaining elements of (2) can be similarly expressed. C. Application of Template Method Pattern Several algorithms, such as GaussSeidal, NewtonRaphson, and fast decoupled exist for solving the power ow problem. All those algorithms share several common steps. Template method design pattern, which denes a skeleton of an algorithm in an operation, redening some steps in the subclasses, is used to develop different power ow analysis algorithms. Application of template method pattern is shown in Fig. 8. The method performAnalysis() of class LoadFlow is the template method, which invokes the following methods in sequence: readSlackBusNo (); createPVPQBuses (); setFlatStart (); solveLoadFlow (); checkLimitViolations (); printLFResults (). The above steps, except the technique used in the solveLoadFlow () method, are common for many of the loadow algorithms. solveLoadFlow () method is redened in each subclass of class LoadFlow. Thus, template method design pattern has been used as a fundamental technique for code reuse. The relationships between the computational classes implemented for power ow analysis are shown in Fig. 9. Class LoadFlow has a reference to the power system object. LoadFlow creates LineDecorator and BusDecorator objects according to the attributes of the power system object and does

Fig. 9.

Computational classes in power analysis.

the analysis using the method solveLoadFlow (). For instance, solveLoadFlow () method of class NRLoadFlow forms the Jacobian matrix and the power mismatch vector by passing messages to different decorators. Jacobian matrix is dened as an object of class SPMatrix (SParseMatrix), which is an aggregation of objects of class SPVector (SParseVector). Each sparse vector object represents a column of the sparse matrix, which is implemented using dynamic doubly linked list data structure. This allows the elements to be easily traversed in both the directions and avoids symbolic factorization during LU decomposition. Power mismatch vector is an object of class Complete Vector (CVector ). Jacobian matrix and power mismatch vector are passed into the object of class Linear System Solver (LSS) to solve the following: (4)

(2)

SELVAN AND SWARUP: DEVELOPMENT OF POWER FLOW SOFTWARE

617

where power mismatch vector given by (1); Jacobian matrix given by (2); vector of change in state variables given by (5)

TABLE I BUS VOLTAGE MAGNITUDE AND ANGLE OF IEEE 14-BUS SYSTEM (FOR CASE 1: SVC AT BUS-14)

(5) where for all Bus PQ Decorators; for all Bus PVG Decorators; for all Bus PVT Decorators; for all Line PST Decorators; for all Bus PVB Decorators; for all Line TCSC Decorators; for all Bus PVST Decorators; for all Line UPFC Decorators. In the proposed method, the corresponding decorator objects are created and attached to bus and line objects, according to the type of controlling devices connected to bus and line. The created bus and line decorator objects are stored in a list that can be accessed using iterator pattern. In each iteration, the size of the individual decorator list is obtained using the associated list iterator object. The dimensions of the Jacobian matrix and mismatch vector can be determined from the knowledge of the number of rows contributed by each decorator and using the size of the individual decorator list. A limit violation leading to change of bus type (e.g., from PVG bus to PQ bus) causes a decorator (PVG) to be detached from the bus object and a new decorator (PQ) to be attached with the bus object. This alters the size of two decorator lists. The size of the individual decorator list could be found using the iterator object; as a result, the Jacobian matrix and power mismatch vector can be re-dimensioned. Whenever a bus type changes, new ordering needs to be carried out to exploit the sparsity techniques. VI. NUMERICAL RESULTS Power ow analysis has been performed initially on the standard IEEE (IEEE 14-bus-IEEE 300-bus) benchmark systems, using the developed program based on the discussed design patterns. The results have been veried with [25] and found to be in exact agreement. Subsequently, the objects of FACTS devices, such as SVC, TCSC, STATCOM, and UPFC, are included, and the power ow analysis has been carried out on various test cases given in [24], and the results have been veried. The results of power ow analysis on IEEE 14-bus system, for two particular case studies, are illustrated in this section.

Case 1: SVC at Bus 14: In the rst study, a static var compensator is connected at bus 14 to improve its voltage magnitude to 1.05 p.u., which is 1.0358 p.u. in the base case. The base and of the SVC MVA is 100 MVA. The chosen values of are 0.013 and 0.13 p.u., respectively. Convergence was obtained in ve iterations to a mismatch tolerance [maximum absolute . The SVC nal ring angle value of mismatches in (4)] of is 143.75 degrees, and the nal succeptance is 0.0627 p.u. Table I shows the bus voltage magnitude and angle of 14-bus system for both the base case and the case with SVC at bus 14. Case 2: TCSC at Line (611): In the second case study, a thyristor controlled series compensator is connected along the line (611) to increase the real power ow through line (611) to 0.1 p.u., which is 0.0734 p.u. in the base case. The chosen and of the TCSC are 0.013 and 0.13 p.u., revalues of spectively. Convergence was obtained in six iterations to a mis. The TCSC nal ring angle is match tolerance of is 0.2056 p.u. 157.96 degrees, and the nal reactance Table II shows the real and reactive line ows of 14-bus system for both the base case and the case with TCSC along the line (611). The results obtained with SVC have been veried with the results obtained by connecting a shunt capacitance of succeptance 0.0627 p.u. at bus-14 in the base case, using the program developed by the present authors and the Power World Simulator software version 10.0 [26]. Similarly, the results obtained with TCSC have been veried with the results obtained by reducing the reactance of the line (611) by 0.2056 p.u. in the base case. This conrms the implementation correctness of the developed power ow software based on the technique discussed in this paper. VII. CONCLUSION Application of object-oriented design patterns for developing improved power system analysis software has been described. Design patterns were found to be an effective technique, both for modeling power system components and obtaining

618

IEEE TRANSACTIONS ON POWER SYSTEMS, VOL. 21, NO. 2, MAY 2006

REAL

AND

TABLE II REACTIVE LINE FLOW OF IEEE 14-BUS SYSTEM (FOR CASE 2: TCSC AT LINE (611)

extendible object-oriented design for power system computation. This paper has demonstrated the suitability of design pattern technique for modeling the conceptual objects of power ow analysis. The technique of using decorator pattern for handling various types of buses has been described, and the advantages have been discussed. Reusability of code has been demonstrated through template method pattern. Several other suitable design patterns could be studied and applied in the future for power system computation. REFERENCES
[1] B. Hakavik and A. T. Holen, Power system modeling and sparse matrix operations using object-oriented programming, IEEE Trans. Power Syst., vol. 9, no. 2, pp. 10451051, May 1994. [2] S. Pandit, S. A. Soman, and S. A. Khaparde, Design of generic direct sparse linear system solver in C++ for power system analysis, IEEE Trans. Power Syst., vol. 16, no. 4, pp. 647652, Nov. 2001. [3] T. S. Dillon and E. Chang, Solution of power system problems through the use of the object-oriented paradigm, Int. J. Elect. Power Energy Syst., vol. 16, no. 3, pp. 157165, 1994. [4] J. Zhu and D. L. Lubkeman, Object-oriented development of software systems for power system simulations, IEEE Trans. Power Syst., vol. 12, no. 2, pp. 10021007, May 1997. [5] A. F. Neyer, F. F. Wu, and K. Imhof, Object-oriented programming for exible software: Example of a load ow, IEEE Trans. Power Syst., vol. 5, no. 3, pp. 689696, Aug. 1990. [6] E. Z. Zhou, Object-oriented programming, C++ and power system simulation, IEEE Trans. Power Syst., vol. 11, no. 1, pp. 206215, Feb. 1996. [7] C. R. Fuerte-Esquivel, E. Acha, S. G. Tan, and J. J. Rico, Efcient object oriented power systems software for the analysis of large scale networks containing FACTS-controlled branches, IEEE Trans. Power Syst., vol. 13, no. 2, pp. 464472, May 1998. [8] A. Manzoni, A. S. e. Silva, and I. C. Decker, Power systems dynamics simulation using object-oriented programming, IEEE Trans. Power Syst., vol. 14, no. 1, pp. 249255, Feb. 1999.

[9] M. Foley and A. Bose, Object-oriented on-line network analysis, IEEE Trans. Power Syst., vol. 10, no. 1, pp. 125132, Feb. 1995. [10] J. Britton, An open, object-based model as the basis of an architecture for distribution control centers, IEEE Trans. Power Syst., vol. 7, no. 4, pp. 15001508, Nov. 1992. [11] A. Losi and M. Russo, Object-oriented load ow for radial and weakly meshed distribution networks, IEEE Trans. Power Syst., vol. 18, no. 4, pp. 12651274, Nov. 2003. [12] F. Li and R. P. Broadwater, Software framework concepts for power distribution system analysis, IEEE Trans. Power Syst., vol. 19, no. 2, pp. 948956, May 2004. [13] M. P. Selvan and K. S. Swarup, Distribution system load ow using object-oriented methodology, in Proc. IEEE Int. Conf. Power System Technology, 2004, pp. 11681173. [14] J. Zhu and P. Jossman, Application of design patterns for object-oriented modeling of power systems, IEEE Trans. Power Syst., vol. 14, no. 2, pp. 532537, May 1999. [15] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design PatternsElements of Reusable Object-Oriented Software. Delhi, India: Pearson Education Indian Branch, 1995. [16] G. Booch, Object-Oriented Analysis and Design With Applications, 2nd ed. Reading, MA: Addison-Wesley, 1994. [17] S. W. Ambler, The Object Primer, the Application Developers Guide to Object-Orientation and the UML, 2nd ed. New York: Cambridge Univ. Press, 2001. [18] S. J. Pollinger, C. C. Liu, and M. J. Damborg, Design guidelines for object-oriented software with an EMS man-machine interface application, Int. J. Elect. Power Energy Syst., vol. 14, no. 2, pp. 122130, Apr. 1992. [19] S. A. Soman, S. A. Khaparde, and S. Pandit, Computational Methods for Large Sparse Power Systems AnalysisAn Object-Oriented Approach. Norwell, MA: Kluwers, 2002. [20] P. Coad and M. Mayeld, Java Design. Englewood Cliffs, NJ: Prentice-Hall, 1997. [21] C. R. Fuerte-Esquivel, E. Acha, and H. Ambriz-Perez, A thyristor controlled series compensator model for the power ow solution of practical power networks, IEEE Trans. Power Syst., vol. 15, no. 1, pp. 5864, Feb. 2000. [22] , A comprehensive Newton-Raphson UPFC model for the quadratic power ow solution of practical power networks, IEEE Trans. Power Syst., vol. 15, no. 1, pp. 102109, Feb. 2000. [23] H. Ambriz-Perez, E. Acha, and C. R. Fuerte-Esquivel, Advanced SVC models for Newton-Raphson load ow and Newton optimal power ow studies, IEEE Trans. Power Syst., vol. 15, no. 1, pp. 129136, Feb. 2000. [24] E. Acha, C. R. Fuerte-Esquivel, H. Ambriz-Perez, and C. Angeles-Camacho, FACTS Modeling and Simulation in Power Networks. Chichester, U.K.: Wiley, 2004. [25] University of Washington. Power System Test Case Archive. [Online]Available: http://www.ee.washington.edu/research/pstca/. [26] Power World Simulator Version 10.0 Reference Manual.

M. P. Selvan (S02) is working toward the Ph.D. degree in the Department of Electrical Engineering, Indian Institute of Technology, Madras, India. His areas of interest are computer methods in power systems, object-oriented analysis, and design for power systems computation tools.

K. S. Swarup (S87M92SM02) is with the Department of Electrical Engineering, Indian Institute of Technology, Madras, India. Prior to joining the department as a Visiting Faculty Member, he held positions at the Mitsubishi Electric Corporation, Osaka, Japan, and Kitami Institute of Technology, Hokkaido, Japan, as a Visiting Research Scientist and Visiting Professor, respectively, during 19921999. His areas of research are AI, knowledge-based systems, computational intelligence, soft computing, and object modeling and design of electric power systems.