IEEE TRANSACTIONS ON SMART GRID, VOL. 2, NO. 4, DECEMBER 2011
573
Study on Data Management of Fundamental Model in Control Center for Smart Grid Operation Jinsong Liu, Xiaolu Li, Member, IEEE, Dong Liu, Member, IEEE, Hesen Liu, and Peng Mao
Abstract—The control center in smart grids requires the collaboration among different specialized groups to ensure the safety, reliability, greenness and efficiency of power system. However, each specialized group is interested in different aspects of the network model. In order to improve the teamwork and timeliness, the fundamental models should be managed in a unified way. This paper summarizes the requirements for data management of fundamental models, presents a concept of three-mode models, and designs the architecture of generic model access services. With the generic model access services, the differences of real-world model databases will be shielded, and the future virtual model can be managed as versions. The upper applications can obtain the fundamental model information through the data broker component and business model data through the business data organizing component.
consistency across databases should be taken into account [1]. The managed data types consist not only model data (including static parameters and measurement data), but also configuration data, logging, operational status of components, security data, and rule information [2]. Because all the operational analysis and control in intelligent dispatching are based on electric network model, the requirements specific to model data management to satisfy various analysis applications are stated in this paper.
Index Terms—Data management, generic model access services, intelligent control center, three-mode models.
The specialized groups such as dispatching, operation mode planning, relay protection, automation, and communication are often established in a control center, and these groups will collaborate to ensure the power system operating safely, reliably and economically. The persons in these groups are segmented as dispatcher, security check engineer, planner, communication engineer, relay protection engineer, and automation maintenance engineer, where the following relates directly to the power grid operation. 1) The dispatcher is the commander of power grid operation and fault handling. He is responsible for the real-time monitoring and control of network, keeping the real-time balance of power production and regulating the power flow on lines and voltages on buses to prevent limit violation. 2) The security check engineer prepares yearly, monthly, weekly and daily operation modes and other special operation modes required. He is responsible for verifying the security, presenting stability measures, and stability analysis or fault analysis. 3) The planner issues the schedules of generation and power supplies, including the power exchange of tie-line in an interconnected grid. 4) The relay protection engineer is responsible for the setting of relay protection and verifying the protection settings when operation mode changes. These persons have different responsibilities, and are interested in different aspects of the network model. For example, for the real-time monitoring and control and network loss analysis, the current network model is expected; for the protection setting, the network model to be put into operation is expected; for the security verification of operation modes, the stability calculation model including detailed generator, excitation system, and governor is expected. If each group makes the management of the fundamental model individually according to their own demands, this will result in lack of unified management of network model, graphics, parameters, and operational data. The
I. INTRODUCTION
T
HE MAIN TASK of control center in smart grids is to realize intelligent warning in advance by means of monitoring and controlling the transmission network in real-time and analyzing its security through the corporation among several specialized groups, to optimize the transmission operation by means of collecting, integrating, analyzing, and mining the operational information to support decision making; and to ensure the security, reliability, flexibility, coordination, economics, greenness, and efficiency of electric power network. All these tasks are based on accurate and adequate data, and hence data management is a critical task for realizing intelligent dispatching. Data management includes the collecting, analyzing, storing and providing data to users and applications. The issues of data identification, validation, accuracy, updating, time-tagging, and Manuscript received August 12, 2010; revised December 25, 2010, May 01, 2011; accepted June 18, 2011. Date of publication August 12, 2011; date of current version November 23, 2011. Paper no. TSG-00109-2010. J. Liu is with the School of Electronic, Information and Electrical Engineering, Shanghai Jiao Tong University, Shanghai 200240, China, and also with East China Electric Power Test & Research Institute, Shanghai 200437, China (e-mail:
[email protected]). X. Li is with Dongfang Electronics, Yantai 264000, China (e-mail:
[email protected]). D. Liu is with the School of Electronic, Information and Electrical Engineering, Shanghai Jiao Tong University, Shanghai 200240, China (e-mail:
[email protected]). H. Liu is with Yunnan Power Grid Corporation, Kunming 650011, China (e-mail:
[email protected]). P. Mao is with Jiangxi Electric Power Company Extra-high Voltage Sub-company, Nanchang 330072, China (e-mail:
[email protected]). Color versions of one or more of the figures in this paper are available online at http://ieeexplore.ieee.org. Digital Object Identifier 10.1109/TSG.2011.2160571
II. REQUIREMENTS FOR FUNDAMENTAL MODEL DATA MANAGEMENT
1949-3053/$26.00 © 2011 IEEE
574
model inconsistency will occur due to multisite maintenance and restrict the functionalities of application systems. The unified management and maintenance of fundamental models is required necessarily when the control center evolving into an intelligent dispatching center. The requirements for fundamental data management are as follows. 1) To satisfy the requirements of different specialized groups on different time scales, i.e., it can provide current, future, or historical model subsets for different specialized analysis to meet the requirements of analysis, setting of relay protection, planning, or real-time monitoring and control. Different applications can fetch on-demand model subsets flexibly. 2) To save the fundamental model in multiple forms (e.g., memory database, relational database, and files), and a unified means is needed to access the model from the various storage. 3) To accommodate multiple data sources, including legacy system, substation configuration files, and other application systems. Semantic integration is an efficient way to collect data from a variety of data sources [4]. Within the power industry, IEC TC57 CIM is a generally accepted semantic. 4) To have panoramic view of whole system model. The intelligent control center needs wide area situation awareness. However, the modeling of power system is scattered by far, and there are multiple control centers to model the network limited to what they controlled. In order to realize the wide area situation awareness, the scattered models should be merged into a panoramic view, including the merging of multiregional models with the unified model boundary definition between higher and lower control centers as well as the model sharing between substation and control center. 5) To be stored in distributed databases but managed in a unified way. As described in [5], it can be expected that the ubiquitous availability of synchronized measurements will promise the new and improved applications to operate the power system more reliably and efficiently. These applications may be distributed in substations, and thus the model and data will be distributed too. The supporting infrastructure will manage the distributed databases and retrieve the right model from the right place for the right applications. III. MANAGEMENT OF THREE-MODE FUNDAMENTAL MODELS A. Conceptual View of Three-Mode Management Different specialties in the control center have different requirements for fundamental network models. For example, the current network model is provided to the EMS for real-time monitoring and control and to the TMR for network loss analysis, the approved model for the relay protection software, the models with detailed parameters for stability analysis for the planning programs. The network model should satisfy the future, current, and historical requirements for each specialized group. Therefore, the management of current, future, and historical models is essential for intelligent control center, i.e., the
IEEE TRANSACTIONS ON SMART GRID, VOL. 2, NO. 4, DECEMBER 2011
Fig. 1. Management of three-mode models.
three-mode models management. This basic functionality will provide on-demand model subsets for analysts of different specialties, and promotes closer collaboration among specialized groups by means of sharing fundamental models. The management of three-mode models can be distributed, i.e., the current-mode model, future-mode models and historical-mode models can be stored in different database entities, and the model at one instant may be distributed too (e.g., some substation model and data may be kept at substation side [5]). The analysts can check out the needed models by time. No matter the final form of storage for three-mode models, the model should be accessed and organized according to the specialized requirements with the generic model access services from the viewpoints of specialized applications. Basing on the unified fundamental models, the combination among specialized groups will be closer, and the timeliness of teamwork can be improved greatly. Take the planning of operation mode as example: the planner will calculate the typical operational modes and checking modes of the next year, and make annual summary of operational modes at the end of the year. Once an accident occurs, the fault analysis will be made after the accident. The planner’s routine work also includes verifying the security of day-ahead or temporary operation modes. With the unified management of three-mode models, the generic model access services will provide the study model required by the planner. Thus, the burden of preparing analysis data is reduced, and then the on-demand analysis of network will be accelerated. Therefore, the collaboration between planners and dispatchers can be enforced. B. Storage of Three-Mode Fundamental Models 1) Management of Current-Mode Model: The requirements for this kind of management are to model current network in time and adequately for analysis in real-time mode or study context. The EMS will store the current-mode model in a relational database for persistent storage. For the analysis such as network topology, power flow, state estimator, contingency analysis, and so on, the model will be extracted from the relational database and loaded to the memory databases in real-time or study mode context. 2) Management of Historical-Mode Model: The historical model is a model at one historical time, or it is a current model at that historical time. It is assumed that there is no edit operation
LIU et al.: STUDY ON DATA MANAGEMENT OF FUNDAMENTAL MODEL IN CONTROL CENTER FOR SMART GRID OPERATION
575
Fig. 2. Usage of three-mode models by planners.
on the historical model, i.e., it cannot be added, deleted, or modified. More likely, the user will checkout model at a specified time. Thus, the requirements for this kind of data management are to fetch the network model at specified time to load into the memory database in study mode context for study mode analysis. The traditional EMS system will archive the historical measurements in a relational database. However, the intelligent operation requires highly granular and massive historical data; therefore, the historical measurement can be archived in a time-series database such as OSISoft PI or eDNA. 3) Management of Future-Mode Model: The future-mode models include day-ahead model, month-ahead model, and year-ahead model, where the day-ahead or month-ahead model may have detailed description about the equipment to be approved (i.e., the modeled network is the actual model of tomorrow or next month); however, some equipment in year-ahead models may be a conceptual model instead of actual approval devices because the planning application only needs the typical parameters instead of accurate parameters of the equipment. The present EMS systems have good real-time and historical database environment, but few of them takes into account the future model management. The hour-ahead or day-ahead study capabilities of EMS systems are based on the current model. In study context, the operating conditions may be adjusted through opening/closing switches or changing the power production/ consumption, but the devices would not be deleted, added, or moved. So some utilities resolve the problem by another planning application system which may be created from scratch. The unified management of current, historical, and future model will facilitate deriving the future models from historical or current models. Thus, the model maintenance will be reduced through the unified model management.
tails about the model, e.g., the relay protection engineers need model subset for relay setting calculation, the dispatchers need model subset for real-time operations, and the planners need the subset for security and stability calculation in current, future or historical contexts. The generic model access services should provide the on-demand model subsets for upper applications according to the application categories. 2) Extracting of Business Analysis Model: The fundamental information is modeled compliant to IEC 61970 [7]. The data shall be described in a standard way, but it may be too trivial for some management applications. For example, the information about a power transformer can be described by instantiating the classes such as PowerTransformer, TransformerWinding, HeatExhanger, and TapChanger, and the telemetry information related to the transformer such as current, active power, reactive power, oil temperature, environment temperature, and tap position will be modeled as Measurement. A business application may intend to transfer all the measurements about one transformer in one message. For the data at business analysis level, it can be processed as messages compliant to IEC 61968 [12], i.e., to define different message types according to the specific business application requirements, where the interested objects will be packed and combined as shown in Fig. 3. Fig. 3 shows a message type organized by the data extracted from originally CIM class information, for example, one attribute of the first CIM class and two attributes of the second and third CIM classes are included in the message type. The upper analysis application can use the predefined message type directly without reprocessing the scattered instances of CIM classes.
IV. GENERIC ACCESS TO FUNDAMENTAL MODELS
V. IMPLEMENTATION
No matter how and where the underlying model data is stored, the upper application should access the model in a generic way. 1) Extracting of Specialized Model: As described in Section II, different professionals are interested in different de-
Fig. 3. Definition of business message type.
A. Implementation of Three-Mode Models Storage The storage of three-mode models should satisfy the requirements for saving business models and persistency. The com-
576
IEEE TRANSACTIONS ON SMART GRID, VOL. 2, NO. 4, DECEMBER 2011
TABLE I EXAMPLE OF DEVICE TABLE
TABLE II EXAMPLE OF TERMINAL TABLE
monly used data storage may be relational database, memory database, or file storage, where the relational database is suitable for saving the data which has no high requirements for real-time property but needs reliable persistent insurance, the memory database is suitable for saving the data which has high requirements for real-time property and supporting the immediate data access to improve the data access efficiency, and the file storage is used to satisfy simple storage requirements or to realize the proprietary or customized storage. A red and black mechanism is presented in [6] to manage the dynamic changing process of distribution network and graphs, where a red for future model and black for realistic model. The application types are used to distinguish that a device belongs to a future model or a realistic model, and the node zone for the connectivity nodes of future model is different from that of the realistic model. However, only the realistic model and one future model at certain instant can be managed by means of red and black mechanism, and the continuously changing process cannot be expressed by the application types. An approach combining relational databases with version management based on files is put forward in this paper to store continuously changing process of the fundamental model from the past to the present and into the future. 1) Storage of Real-World Models: The real-world models describe the reality of current, historical, or future electric network. The current real-world model is about the real-time electric network that is monitored by the dispatchers, the historical real-world model is about the network that ever existed in the history, and the future real-world model is about the network that will appear in the future and will become a current real-world model at one future instant. These models can be stored in one relational database. An example how to store the information about the devices and topology is descibed in Tables I and II. Every device will have commission date and retirement date. If its retirement date is earlier than current time, then the device is part of a historical real-world model. If the commission date is later than current time, then the device belongs to a future real-world model. Similarly, every substation has commission date and retirement date
too to determine whether the substation appears in a historical or future real-world model. For the continuous change of network topology, it can be handled with terminal table as shown in Table II. Each topology change will have a corresponding record in this table. For example, the topological relationship of Device 12003 (i.e., a device whose ID is 12003) with other devices will change due to its commission, movement or retirement. The first record about one terminal (whose ID is 53001) of Device 12003 in terminal table must be active when the device is put into operation, and the last record about the terminal subjects to the deletion of topology when the device retires from the network. Hence, the ActiveTime of the first record about Terminal 53001 in terminal table is the commission date of Device 12003, and the InActiveTime of last record about Terminal 53001 is the retirement date of Device 12003. The Generic Model Access Services can fetch the real-world model at specific time from the relational database using the Generic Database Access Interfaces. A historical, current or future model will be determined according to the required time. 2) Storage of Virtual Models: The future models can be divided into two categories: one is the models before operation, and another is the models only for study analysis. The models before operation will become the current model at the future instant, so they are future real-world models and can be used for debugging of telemetry and telecontrol. However, the future models that are only for study analysis have no strict requirements for the naming of substations and power devices. A new substation and its power devices in this kind of model can be cloned from the base model or modeled according to a typical scheme of a substation. This model will be deleted from the future-mode repository when it is no longer in use. This kind of models can be regarded as virtual models. The virtual future model will be modified based on the current-mode or historical-mode models, and the modification cannot influence the usage of the original model. Therefore, each virtual future model has the version information about its corresponding base model; that is, the future-mode model is modified from which model version, e.g., current model or historical model at certain time. The maintained future-mode models can be managed in versions. The virtual future model maintenance tool will assign a unique identification to each future-mode model. Thus, the Generic Model Access Services can checkout one virtual future model from the future-mode model repository with Checkout Versions Interfaces. 3) Other Requirements for Model Storage: Redundancy, fail-over, and backup are very important to the availability of three-mode model repository. Because the real-world models are stored in a relational database, full use should be made of the functionalities provided by the commercial software, such as array, cluster, etc. The future virtual models are in XML format, and their backup and fail-over will be based on files. As for the memory database, regular backup of the memory image files can improve the availability. As described in Section III, the storage formats of three-mode models include relational database, time-series database, file and memory database. The relationships among the four formats are described in Fig. 4.
LIU et al.: STUDY ON DATA MANAGEMENT OF FUNDAMENTAL MODEL IN CONTROL CENTER FOR SMART GRID OPERATION
Fig. 4. Implementation of three-mode model storage. TABLE III APPLICATION CATEGORIES AND REQUIRED MODEL SUBSETS
B. Definition of Application Categories The three-mode model repository will store the node-breaker models, and the Generic Model Access Services determine which model subset will be provided according to the application category. The model subset may be node-breaker model or bus-branch model. How to transform the node-breaker model in the three-mode model repository into the required model subset will be described in Section V-D. C. Extracting of Business Data The fundamental model data may be further processed for some business application. Thus, the generic model access service will organize the business data flexibly according to the message type, which can be explained by the business system. D. Implementation of Generic Model Access Services According to the above requirements, the architecture of generic model access services is put forward in this paper. There are the following components in this architecture:
577
Fig. 5. Architecture of generic model access services.
1) Generic Database Access Interfaces. This component will mask the differences of various relational databases, and make generic access to these databases. The three-mode real-world models can be stored in a commercial relational database, such as ORACLE, SYBASE, SQLSERVER, MYSQL, etc. There are multiple technologies to connect heterogeneous databases now, e.g., ODBC, OLEDB, ADO, JDBC, but these technologies are constrained either by operating systems or by java language. The Generic Model Access Services will need an access interface that can connect to manifold commercial relational databases, cross various platforms, and be implemented in C/C++. The Generic Database Access Interfaces will act as a semantic broker for relational databases. Regardless of the actual relational database is used for model storage, a client application using the Generic Database Access Interfaces will see a data model as shown in Fig. 6. Each commercial relational database will provide proprietary access interfaces for applications. These interfaces form the bases for efficient data access. The Generic Database Access Interfaces will encapsulate these underlying database access interfaces, and provide a concise and generic set of database operations, i.e., creating connection environment, connecting database, disconnecting database, executing SQL command, inserting records, updating records, deleting records, querying database, etc. When the data required by the upper applications is stored in a relational database, the Generic Database Access Interfaces will create an environment for database connection, and return the table and record information about the database as shown in Fig. 6 through the unified operations. 2) Checkout Versions Interfaces. This component checks out the future virtual model version with specific version number from the model version management repository. 3) Memory Database Access Interfaces. This component loads the historical, current, or future mode model to the memory database in certain context, and obtains models from the memory database.
578
4) Data Broker Component. This component shields the access differences between future-mode model base, current-mode model base, historical-mode model base, and memory base. The upper applications will access the models they need with generic interfaces. The Data Broker Component provides the data access services compliant to IEC 61970, i.e., GDA, HSDA, TSDA, and GES, to the upper applications [8]–[11]. The sequence for an application to access the fundamental models as a client of Generic Model Access Services is shown in Fig. 7. a) The application sets its application category using the operation setApplicationType() provided by the Client Connection Service of Data Broker Component, enabling the server to identify which model subset is needed for the application. b) The client application specifies the needed model version using the operation setModelVersion() provided by the Client Connection Service of Data Broker Component. c) The client application accesses the model of specific version using the operations provided by GDA Service of Data Broker Component, such as get_resource_ids() and get_extent_values(). d) If the model required by the client application is currentmode model, then the GDA service of the Data Broker Component will access the model from relational database using the operation dbfselectsqlresults() provided by the Generic Database Access Interfaces according to current time. The query results will be organized in CIM and return to the client application. The Generic Model Access Services determines which model subset will be provided according to the application category. There is a tendency to encapsulate some common applications into services, such as topology processing, then other applications (e.g., state estimation, contingency analysis, power flow, etc.) can make topology analysis through this common topology processing service. Therefore, the topology processing service can be provided by the Data Broker Component, or be provided by a third-party vendor and integrated into the system. For example, the contingency analysis may set a contingency, and the influenced node-breaker model in the three-mode model repository will be transferred to the common topology processing service. Finally, a bus-branch model subset corresponding to the specific contingency will be returned to the contingency analysis. 5) Business Data Organizing Component. This component will access the fundamental model information through Data Broker Component, organize the data according to the message type required by the business applications, and then return the results to the application. An example of one application accessing business data is shown in Fig. 8. The accessing steps are as follows. a) The client application sets the required business data type using the operation setBusinessMessageType() provided by the Client Connection Service of Data Broker Component.
IEEE TRANSACTIONS ON SMART GRID, VOL. 2, NO. 4, DECEMBER 2011
Fig. 6. Unified database model.
Fig. 7. Data access sequence through Data Broker Component.
Fig. 8. Sequence of organizing business data.
b) The Client Connection Service of Data Broker Component will relay the requirement for setting the business data type to Business Data Organizing Component. c) The client application queries the business data through the operation getBusinessMessage() provided by Business Data Organizing Component. d) According to the business data type set by the client application, the Business Data Organizing Component gets the required data from the model storage through the operations (e.g., get_values()) provided by the GDA Service of Data Broker Component, organizes the data, and then returns the results to the client application. E. Example of Using Generic Model Access Services The process to get the model required by an application through the Generic Model Access Services is illustrated in this part. Assume that the application system has the network structure as shown in Fig. 9, where the storage of virtual model is deployed on node 2, the storage of real-world model is deployed on node 3, and the applications are deployed on node 1 and node n. Notice that the memory databases are distributed, i.e., there may be memory databases on each application node. Except the memory databases in real-time context must be
LIU et al.: STUDY ON DATA MANAGEMENT OF FUNDAMENTAL MODEL IN CONTROL CENTER FOR SMART GRID OPERATION
Fig. 9. Example of using Generic Model Access Services by an application.
consistent among the application nodes, the memory databases in study context on one application node can be different from another node, which are loaded according to the local application requirements. If the App 1 on node 1 needs a virtual model at certain future time, then the Generic Model Access Services will retrieve this model version through the Checkout Versions Interfaces, and load this virtual model into MDB2 through the Memory Database Access Interfaces. The retrieved model will be transferred to the App 1 by the Data Broker Component in binary format. If another application also needs this study model, the Generic Model Access Services will get the model directly through Memory Database Access Interfaces from MDB2. Similarly, if the App 2 on node 1 needs the current model for study-mode analysis, the Generic Model Access Services will retrieve the current model from real-world model database through Generic Database Access Interfaces, and load the model to MDBn through the Memory Database Access Interfaces. All the applications that need the current model for analysis in study context will obtain the current model from MDBn ultimately. VI. CONCLUSION The unified management for fundamental model data is necessary for the operation of smart grid, not only involving the unified storage of historical-mode model, current-mode model and future-mode model, but also providing the on-demand model subset through Generic Model Access Services. The Generic Model Access Services have the following functionalities: 1) to shield the differences of various relational databases where current, historical and future real-world model is stored with the Generic Database Access Interfaces; 2) to fetch the model of required version from model version management repository with the Checkout Versions Interfaces; 3) to access the model residing in memory with the Memory Base Access Interfaces; 4) to provide the unified fundamental model access interfaces to the upper applications with the Data Broker Component; 5) to acquire the business model data organized in the specified message type with the Business Data Organizing Component.
579
REFERENCES [1] EPRI. Palo Alto, CA, “Report to NIST on the Smart Grid Interoperability Standards Roadmap,” 2009. [2] EPRI, Palo Alto, CA, “Transmission fast simulation and modeling (T-FSM)—Architectural requirements,” Final Rep., TP-1011667, 2005. [3] X. Wang, S. V. Ausdall, and J. Zhou, “Managing the life cycle of business semantics,” [Online]. Available: http://xtensible.net/services/services-white-paper [4] S. Biffl, W. D. Sunindyo, and T. Moser, “Semantic integration of heterogeneous data sources for monitoring frequent-release software projects,” in Proc. 2010 Int. Conf. Complex, Intell., Softw. Intensive Syst.. [5] A. Bose, “Smart transmission grid applications and their supporting infrastructure,” IEEE Trans. Smart Grid, vol. 1, no. 1, pp. 11–19, 2010. [6] H. Shen et al., “Management mechanism for dynamic model change in distribution network automation management systems,” Autom. Elect. Power Syst., vol. 31, no. 6, pp. 52–56, 2007. [7] Energy Management System Application Program Interface (EMS-API)—Part 301: Common Information Model (CIM)—Base, IEC 61970-301. [8] Energy Management System Application Program Interface (EMSAPI)—Part 403: Component Interface Specification (CIS)—Generic Data Access, IEC 61970-403. [9] Energy Management System Application Program Interface (EMS-API)—Part 404: High Speed Data Access (HSDA), IEC 61970-404. [10] Energy Management System Application Program Interface (EMS-API)—Part 407: Time Series Data Access (TSDA), IEC 61970-407. [11] Energy Management System Application Program Interface (EMS-API)—Part 405: Generic Eventing and Subscription (GES), IEC 61970-405. [12] Application Integration at Electric Utilities—System Interfaces for Distribution Management—Part 1: Interface Architecture and General Requirements, IEC 61968-1. Jinsong Liu received the B.S., M.S. and the Ph.D. degrees from Wuhan University, China, in 1992, 1995, and 1999, respectively. He was with Dongfang Electronics as a R&D manager for nine years, and then worked as a Postdoc with Shanghai Jiao Tong University from 2007 to 2010. Currently he is with East China Electric Power Test & Research Institute, Shanghai. His research interests include energy management system and distribution automation system. Xiaolu Li (M’99) received the B.S. and M.S. degrees from Wuhan University, China, in 1992 and 1995, respectively, and the Ph.D. degree from Huazhong University of Science and Technology, China, in 1999. Currently she is a Deputy Chief Engineer with Dongfang Electronics, Yantai, China. Her research interests include utility application integration and energy management system. Dong Liu (M’02) received the B.S. and M.S. degrees from Sichuan University, China, in 1989 and 1994, respectively, and the Ph.D. degree from Southeast University, China, in 1997. Currently he is a Professor with the School of Electronic, Information and Electrical Engineering, Shanghai Jiao Tong University, China. His research interests include energy management system, distribution automation system, and smart grids. Hesen Liu received the B.S. degree from North China Electric Power University, China in 2001. He is now taking the responsibility of online control and real-time analysis of the Yunnan power system with Yunnan Power Grid Corporation, Kunming, China. Peng Mao received the B.S. degree from Shandong University of Technology, China, in 1995, and the M.S. and Ph.D. degrees from Tianjin University, China, in 1998 and 2000, respectively. He is with Jiangxi Electric Power Company Extra-high Voltage Sub-company, Nanchang, China, and his research interests include power system fault analysis and relay protection.
