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
Abstract—Application 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 flow (load flow) 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 flow computation has been implemented in C++ on windows environment. The performance of the developed program has been tested with IEEE benchmark systems. Index Terms—Design patterns, FACTS devices, object-oriented development, power flow analysis, power system computation.
I. INTRODUCTION
P
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 efficient 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. Specific applications, such as load flow, 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 flexibility. Neyer et al. [5] proposed an object-oriented design of power system components for load flow analysis. The local processing mechanism of object-oriented methodology was well utilized in [5] for obtaining flexible 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:
[email protected];
[email protected]). Digital Object Identifier 10.1109/TPWRS.2006.873050
to only Newton–Raphson power flow analysis. The object-oriented decomposition proposed in the present paper can be used also for Gauss–Seidal and fast decoupled load flow 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 flow, unbalanced load flow, 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 flow analysis program to include the behavior of FACTS devices. Fuerte-Esquivel et al. [7] proposed an object-oriented load flow 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 flow analysis. Application of design patterns in power flow 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) finding the appropriate objects, 2) designing the classes at the right granularity, 3) defining 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 flexible 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 identifies 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
There are large numbers of design patterns suitably applied for reusable object-oriented design, which are classified 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 flow computation. The remainder of this section will focus on the brief description of these patterns. Class diagrams are drawn using unified 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
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 modifications. 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 flexible 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” defines the skeleton of an algorithm in an operation, and it allows the subclasses to redefine certain steps of an algorithm without changing the algorithm’s structure. As shown in Fig. 3, the abstract class defines 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 specific 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.
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 flow 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.
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 find the appropriate conceptual objects for power flow analysis; 4) enhancing the code reusability in the power flow analysis program using “template method” design pattern. IV. SELECTION OF DESIGN PATTERNS FOR POWER FLOW ANALYSIS This section describes certain issues involved in power flow 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;
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 flow 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 classification. 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 defined 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 flag in the class PVBus, which toggles from “0” to “1,” when the bus type changes [19]. Application of inheritance and the use of flags will be cumbersome when two or more voltage controlling devices are connected at the same bus. Moreover, Coad’s 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 flag in the class Bus to indicate the type
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 Gauss–Seidal, Newton–Raphson, and fast decoupled are available for solving the power flow problem. All those techniques share several common procedures. “Template method” design pattern, which defines a skeleton of an algorithm in an operation, redefining some steps in the subclasses, is used to develop power flow analysis programs employing different solution techniques. This enhances the code reusability.
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
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 flow models of the FACTS devices proposed by Fuerte-Esquivel et al. [21]–[23] are used in this paper for implementing Newton–Raphson power flow 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
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 flow and optimal power flow 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 flow 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
Fig. 6.
615
Class diagram illustrating application of literator pattern.
in power flow analysis. Newton–Raphson power flow has been considered in this paper for discussion. Decorators contribute appropriate elements to the power mismatch vector and Jacobian matrix in Newton–Raphson power flow, 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 modifications in the class Bus. Thus, the developed code becomes extendible. 2) When power flow 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, flags are defined 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 difficult 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 firing 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 Newton–Raphson power flow 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 firing 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 Newton–Raphson power flow 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.
Fig. 9.
Computational classes in power analysis.
The remaining elements of (2) can be similarly expressed. C. Application of Template Method Pattern Several algorithms, such as Gauss–Seidal, Newton–Raphson, and fast decoupled exist for solving the power flow problem. All those algorithms share several common steps. “Template method” design pattern, which defines a skeleton of an algorithm in an operation, redefining some steps in the subclasses, is used to develop different power flow 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 loadflow algorithms. “solveLoadFlow ()” method is redefined 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 flow 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
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 defined 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 flow 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 verified 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 flow analysis has been carried out on various test cases given in [24], and the results have been verified. The results of power flow analysis on IEEE 14-bus system, for two particular case studies, are illustrated in this section.
Case 1: SVC at Bus 14: In the first 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 five iterations to a mismatch tolerance [maximum absolute . The SVC final firing angle value of mismatches in (4)] of is 143.75 degrees, and the final 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 (6–11): In the second case study, a thyristor controlled series compensator is connected along the line (6–11) to increase the real power flow through line (6–11) 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 final firing angle is match tolerance of is 0.2056 p.u. 157.96 degrees, and the final reactance Table II shows the real and reactive line flows of 14-bus system for both the base case and the case with TCSC along the line (6–11). The results obtained with SVC have been verified 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 verified with the results obtained by reducing the reactance of the line (6–11) by 0.2056 p.u. in the base case. This confirms the implementation correctness of the developed power flow 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 (6–11)
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 flow 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. 1045–1051, 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. 647–652, 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. 157–165, 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. 1002–1007, May 1997. [5] A. F. Neyer, F. F. Wu, and K. Imhof, “Object-oriented programming for flexible software: Example of a load flow,” IEEE Trans. Power Syst., vol. 5, no. 3, pp. 689–696, Aug. 1990. [6] E. Z. Zhou, “Object-oriented programming, C++ and power system simulation,” IEEE Trans. Power Syst., vol. 11, no. 1, pp. 206–215, Feb. 1996. [7] C. R. Fuerte-Esquivel, E. Acha, S. G. Tan, and J. J. Rico, “Efficient 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. 464–472, 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. 249–255, Feb. 1999.
[9] M. Foley and A. Bose, “Object-oriented on-line network analysis,” IEEE Trans. Power Syst., vol. 10, no. 1, pp. 125–132, 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. 1500–1508, Nov. 1992. [11] A. Losi and M. Russo, “Object-oriented load flow for radial and weakly meshed distribution networks,” IEEE Trans. Power Syst., vol. 18, no. 4, pp. 1265–1274, 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. 948–956, May 2004. [13] M. P. Selvan and K. S. Swarup, “Distribution system load flow using object-oriented methodology,” in Proc. IEEE Int. Conf. Power System Technology, 2004, pp. 1168–1173. [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. 532–537, May 1999. [15] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns—Elements 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 Developer’s 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. 122–130, Apr. 1992. [19] S. A. Soman, S. A. Khaparde, and S. Pandit, Computational Methods for Large Sparse Power Systems Analysis—An Object-Oriented Approach. Norwell, MA: Kluwers, 2002. [20] P. Coad and M. Mayfield, 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 flow solution of practical power networks,” IEEE Trans. Power Syst., vol. 15, no. 1, pp. 58–64, Feb. 2000. [22] , “A comprehensive Newton-Raphson UPFC model for the quadratic power flow solution of practical power networks,” IEEE Trans. Power Syst., vol. 15, no. 1, pp. 102–109, Feb. 2000. [23] H. Ambriz-Perez, E. Acha, and C. R. Fuerte-Esquivel, “Advanced SVC models for Newton-Raphson load flow and Newton optimal power flow studies,” IEEE Trans. Power Syst., vol. 15, no. 1, pp. 129–136, 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 (S’02) 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 (S’87–M’92–SM’02) 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 1992–1999. His areas of research are AI, knowledge-based systems, computational intelligence, soft computing, and object modeling and design of electric power systems.
