Study of Applying CORBA-Based Distributed Object Technology to Next Generation of Power Dispatching Automation System

Huang Haifeng, Yang Zhihong and Zhang Shenming platforms , databases, communication protocols, and application program interfaces are not same. Since a unified standard is absent, all vendors describe the power system model with their private data structures, interfaces and communication protocols. These bring the communication difficulty and form the isolated island phenomena. So realizing the information share is the developing emphasis of the power dispatching automation [ 1],[4],[5]. Standard IEC 61970 is to build Common Information Model (CIM) to describe the power system object and to construct Component Interface Specification (CIS) to realize the interoperability of the system.
11. ADVANTAGE OF CORBA-BASED DISTRIBUTEDOBJECT
TECHNOLOGY

Abstract-The distributed object technology and its application in the next generation of a power dispatching automation system are introduced. Standard IEC 61970 is to found Common Information Model (CIM) for the power system objects and to form Component Interface specifications (CIS) for logical information exchanges among all applications. Standard IEC 61970 is the theoretical base of data models and distributed object technology is the technology guarantee of implementing this system. Each application, each service or each sub-system can be described as one or more components. All components are interconnected by an integration framework, which is composed of Object Request Broker (ORB) bus, namely the core of Common Object Request Broker Architecture (CORBA). In this paper, the background of developing a next generation of a power dispatching automation system complying with Standard IEC 61970 is reviewed. On tbe basis of a lot of testing data about CORBA performance, the feasibility of adopting CORBA-based distributed object technology is discussed. Constructing integration framework of the system and encapsulating the existing applications or programs are two. main methods about CORBA applications. Lastly, the whole system structure and its design scheme of the dispatching automation system are presented and analyzed.
Inder Terms-Energy Management System; CORBA; Power System; CIM; CIS; Component

I. INTRODUCTION

HE aim of setting up a power dispatching automation system is to ensure the security and stability of the power network operation. In order to transmit the power energy with high quality, and reduce the energy loss, multi-subsystems need to be operated in the same time, such as: Energy Management System (EMS), Tele-Meter Reading (TMR), and Distribution Management System (DMS). And each sub-system includes several applications, for example, SCADA, AGC, NA and DTS belong to EMS subsystem. Because in the control center, each sub-system or application may be developed by different vendors, and its software
Huang Haifeng works in Nanjing Automation Research Institute (NARI), Nanjing, P.R. China. (e-mail: huanghf200O@yeah,net). Yang Zhihong works in Nanjing Automation Research Institute (NARI), Nanjing, P.R. China (e-mail: young@nari-china.com) B a n g Shenming works in Nanjing Automation Research Institute (NARI), Nanjing, P.R. China (e-mail: zsm7005@nari-china.com).

Standard IEC 61970 is the theoretical base of data models in the next power dispatching automation system and distributed object technology is the technology guarantee of implementing this system. TCP/IP protocol is used in a local network communication normally. Although it has high efficient, this method depends on the network types, realizing language, application manner and system platform deeply. On the contrary, in the distributed object technology, TCP/IP protocol is shielded. The communication process is taken charge by ORBs. The development process centralizes on the mutual exchange data among component applications. After adopting ORBS, as long as the standard interface is followed, the connection of a server and a client object can be established by ORBs. The functions of ORB are as following: Receiving a service request sent by a client, and fulfilling the mapping of request in the server; Setting a route scheme and searching for a service object; Submitting client parameters; Returning to a client with a computing result of a service object. Fig. 1 is the progress of a client s ervice request. A client object sends a request to the implement of a service object. In fact, a client is an entity of sending a function request to a service object, and a service object includes data resource and realizing codes of this function. The function of an object request broker is to locate the service request, and to receive the service request of a client and to return an executing result to the client. After sending a request, a client object can get

0-7803-7459-2/02/$17.00 2002 IEEE 0

-621 -

the computing result of a service object by a polling or other manners.

I
OR
Fig 1 Client Service Request Progress

1 1 CORBA APPLICATION METHODS AND PROBLEMS IN THE 1.

Because the efficiency of the network communication using CORBA is lower than that using TCP/IP directly. At one time, it is doubtful whether CORBA can meet the real-time performance demand of the power system. The main problems show in two aspects: 0 Possibility of CORBA adopted in the power dispatching automation system; 0 Methods of CORBA applied in the power dispatching automation system. To the first problem, the answer is affirmative. Firstly, Standard IEC 61970 is the start and standpoint of the next generation of the system. CIM interface definition will become the formal standard. And the interface of each application must accord with component interface specifications, namely, each component shall encapsulate its relative application program codes, and offer a standard, public method to be visited by the other vendors. This can meet the demand of an open system interconnection. CORBA is the most suitable tool for constructing a component model. Secondly, CORBA is able to provide the simple, extensive and standardized integrated method and a system structure to solve the integration and development in a distributed heterogeneous environment. So CORBA ought to be adopted in the power system. To the second problem, there are two manners about CORBA application. 0 On the basis of meeting the real-time performance, CORBA can be used in constructing a system platform; 0 CORBA can be used to encapsulate the existing applications or services to form components The existing CORBA application status in the non-real-time system shows that CORBA can reduce the complexity of the distributed system. But CORBA applied in the control center should meet the real-time performance demand, especially for a real-time task, such as: alert, telemetry message transmit. So, CORBA performance test should be taken under a real-time condition.
IV. CORBA PERFORMANCE TEST

are synchronous invocation, oneway operation and deferred synchronous invocation. Because a deferred synchronous invocation manner is usually used in Dynamic Invocation Interface (DII), it is seldom used. [3] Besides in some scenarios, a more decoupled communication model between objects is required. For example, in the power dispatching automation system, if a measurement value exceeds the measurement limit value, and a alert message is sent by the monitoring program, and then the relative equipment can adjust operating status. If the monitoring program communicates with all relative members to inform the alert event information, this close-couple communication manner is very complex and influence on the systems scalable capability and the quantity variety of alert relative users. A decouple relation applied in alert event and alert object can simplify the communication process. [2] The Event service decouples the communication between objects. The Event service defines two roles for objects: the supplier role and the consumer role. Suppliers produce event data, and consumers process event data. Event data are communicated between suppliers and consumers by issuing standard CORBA requests. The Event service allows object log on and exit with a dynamic manner. Because the Event service offers a method for decoupled communication, the performance of the push model in suppliers and consumers is tested.

A. Testing Environment The test is operated in a lOOM local area network. There are one workstation (ULTRA 60 workstation, 667MHz CPU, 512M memory) and one server (SUN Enterprise 250,450MHz CPU, 128M memory). To avoid the disturbance and enhance the accuracy of the testing result, the following testing message format is adopted as shown in fig.2. Each item message has 540 bytes, and each group need send 30-item messages. In every test time, 10-group messages are sent. The actual testing time is the sum of sending 300-item messages, i.e. there are about 300-time invocations between a client and a server object.

B. Peflormance Analysis
First item Second item

......

thirtieth item

first group

......
tenth group

......
bytes bytes
*****.

......

Fig.2 Message Format in each testing time

On the basis of normal CORBA communication methods and combined with application features of a power system, CORBA communication performance is tested We know that the normal CORBA communication manners

Testing results is shown in fig.3. 50-time tests are carried out. Each testing cost time is shown in the Y-coordinate of fig.3. Fig.3a shows testing result in a synchronous invocation manner. In a synchronous invocation, before sending a next message; the client ,must wait for a current answer from a server, after a server disposes this invocation. So the cost time

- 622 -

is longer than that in an oneway operation manner. But the availability is very high. Fig.3b shows oneway operation testing result. Because of no answer from a server, the speed is very high. But compared with a synchronous invocation, the availability is relatively low. In an Event service, there are two basic models for . communicating event data between suppliers and consumers: the push model and the pull model. In the push model, a supplier pushes event data to a consumer. Compared with the push model, the way of acquiring data in a pull model is decided by the action sponsors. For example, obtaining data time is determined by the pull consumers. Because the pull action is active, only a push model is tested. Before messages sending by a supplier arrive at consumers, the messages must be transmitted in an event channel. The speed of the Event Service is low. But this is an asynchronous method. Fig.3~ is the testing performance of the push Event service.

1.6
h

a 1.4
C

gi ' i
E ss

9: 1.2
1.0

0.8

10

20

30

'

40

50

number of sending times (c)

Fig 3 Testing performance of CORBA common communication

0.21

'

10

'

'

20

'

.
a

30

'

'

40

'

'

50

Although the efficiency of CORBA is lower than that of other communications software that is constructed on TCP/IP protocol directly. But this technology improves system opening and reliability greatly. Known from the CORBh performance test, if the component granularities are not very small, the system CORBA platform can meet the communication demand among components of the power dispatching automation system, such as alert service, report form service, and SCADA, PAS, DTS application. But to high real-time communication tasks, for instance, the communication among front machines and SCADA data servers should consider to make on TCP/IP protocol.

number of sending times

v. APPLICATION OF CORBA IN POWER DISPATCHING

To sum up, the structure of the power dispatching

0.001

"

10

20

'

"

30

40

'

'

50

number of sending times b

7
Database Management System

Fig. 4 Structure ofNext Power Dispatching Automation System

automation system is shown as fig.4. CORBA technology can be used in shallow parts of fig.4. In the bottom part, CORBA is used to integrate a heterogeneous system, and the main task is to sustain internal several communications protocols and to solve high performance communication in a heterogeneous environment. In this part, CORBA need have a real-time

- 623 -

performance. The database management system part answers for exchanging data models and data formats in the real-time database with orient-object, relational and hierarchy characteristics. In the upper part, middleware service system based CORBA is used to encapsulate applications and services to form diverse components with different granularity, and these consist of common object service, common facility and a series of function agents. Function agents are object-oriented function entities formed by encapsulating application system programs, and their sizes of granularities are decided by the actual applications.

Zhang S henming was born in Nantong, Jiangsu Province, P.R. China, on May 1, 1970.He received his B.S. degree and M.E. degree from Southeast University, Nanjing, in 1992, 96 respectively, all in Electric Engineering. Presently, he is working/with NARI in the area of Dispatcher Training Simulator (DTS), Energy Management System (EMS) and the support platform of power system automation.

VI. CONCLUSION In the paper, the background of the next generation of a power dispatching automation system based on standard IEC 61970 is reviewed. Because the computers become more and more popular, the construction and integration of computer systems are more important. The distributed object technology, whose mainstream technology is CORBA, has the nature ability to reduce the complexity and difficulty i n the system developing process. Each application, each service or each sub-system can be described as one or more components. All components a re interconnected by an integration framework, which is composed of ORB bus, namely the core of CORBA, and communicated with each other by the ORBS. On the basis of a lot of testing data about COMA communication efficiency and performance, the feasibility of adopting COMA-based distributed object technology in the next system is discussed. Constructing integration framework of the system and encapsulating the existing applications o r programs are two main methods about CORBA applications. Lastly, the whole system structure is presented and analyzed. We think that, with our endeavors, the next generation of the power dispatching automation system will be realized in the near future.

VII. REFERENCES
B a n g Shenming, Huang Haifeng, Architecture of Power Dispatching Automation System Based on IEC 61970 Standard, Automation o f Electric Power System .vo1.26,pp. 45-47, May. 2002 . Event Service Specification. Object Management Group. 2001.march. versionl.1. The Common Object Request Broker: Architecture and Specification. Object Management Group. December2001. Revision 2.6. J.P.Britton, An open, Object-Based Model as the Basis of an Architecture for Distribution Control Centers, IEEE Transactions on Power Systems, Vol.7. No.4.pp.1500-1508. Nov.. 1992. K.Kawata, M.Fujimura, MSugata, T.Aiura, New Generation of Advanced Control System for Large Electric Power Network, IEEE PES Winter Meeting, Singapore, Jan. 2000.

VIII. BIOGRAPHIES
Huang Haifeng was born in Suzhou, Jiangsu Province, P.R. China, in November 1969. He received his M.S. and Ph.D. degree in Southeast University, Nanjing in 1998 and 2001 respectively, all in Electronic Technology. Presently, he is working in Nanjing Automation Research Institute (NAN) in the area of Energy Management System (EMS) and the CORBA application in the power system automation support platform.

Yang Zhihong was born in Nanjing, Jiangsu Province, P.R. China, 1968. He received his B.S. degree and M.S. degree from Nanjing University, Southeast University, Nanjing, in 1990, 1998 respectively, all in Computer Science and Technology. Presently, he is working wt NARI in the area of Energy ih Management System (EMS) and the power system automation support platform.

- 624 -