1 2 3 4 5 6 7 8 91011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556576061

Abstract--Visualization technique is widely used in power

system real-time monitoring and decision making. But existing visualization tools lack the ability of data aggregation and the flexibility for user customization. The Operation Cockpit, originated from Management Cockpit, is proposed as a new solution for power system visualization. The basic concepts about Operation Cockpit are introduced. A preliminary framework to implement an Operation Cockpit is presented, including data format, architecture and module design of the system.

Index Terms-- Power System Visualization, Smart Grid, Operation Cockpit

I. INTRODUCTION ignificant improvement of visualization techniques has been achieved and widely used in power system over

last decade [1]-[3]. More advanced visualization solutions are needed in the development of smart grid, as the operation of power system become more challengeable. For example, several index systems have been [4]-[6], and more in the future will be, introduced to the Smart Gird projects. Visualization of such index systems is a new challenge for the design and development of the Energy Management System in the control center.

Due to the lack of effective and comprehensive visualization solution in Energy Management System (EMS), individual visualization modules have to be developed to meet different needs. This situation has caused several problems in the development of EMS. Firstly, because of the high cost of implementing visualization module for every individual application, the visualization level of the system is limited. For example, tabular display, which is neither intuitive nor effective, is still widely used as the only way of presenting various kinds of data. Secondly, as existing visualization tools are developed separately, analysis results from different application software are always stored and processed in private data formats, making it difficult and expensive to perform data aggregation. The lack of data aggregation prevents the operators from getting a comprehensive understanding of the system. Lastly, as the rendering schema is bound with specific areas or problems, existing visualization tools seldom provide the possibility to

This work was supported in part by the Project supported by National Science Foundation of China (50823001) and National High Technology Research Program of China (2011AA05A118).

Wenchuan Wu* is the corresponding author (e-mail: wuwench@tsinghua.edu.cn). Zhemin Zhou, Boming Zhang and Hongbin Sun are all with the Department of Electrical Engineering, State Key Laboratory of Power Systems, Tsinghua University, Beijing 100084, China. Xuzhu Dong is with Electric Power Research Institute, China Southern Power Grid, Guangzhou, China.

customize the form of data presentation. A more general, flexible and user oriented visualization

solution is required to meet the growing demands on Smart Grid projects. One effective way to implement such a solution, using Operation Cockpit as the core concept, is proposed in this paper. A brief description of the basic ideas about Operation Cockpit is given first. Then a preliminary investigation about the framework of an Operation Cockpit, including data format, architecture and module design, is presented.

II. CONCEPTS AND SYSTEM DESIGN

A. Operation Cockpit The cockpit idea originated from aerospace (Fig. 1).

There’re lots of information about the fight and the plane, required by different participants (pilot, passengers, etc.). The cockpit provides the pilot with only relevant, controlling related information, expressed in an intuitive way. This idea was introduced to management information system by the SAP AG Corporation in 1990s, creating the concept of Management Cockpit. The key part of a Management Cockpit is called Wall Display System, typically made up of six screens on the wall. A group of dynamically created Key Performance Indicators (KPIs) are displayed on the Wall Display System in different kinds of graphs, offering an efficient monitoring of the whole operation situation of the company.

Inspired by the concept of Management Cockpit, this paper uses the term Operation Cockpit to describe the new visualization system that is used to monitor and assess the power system operating status. While multi-screen display system has already been used in the control center, the Operation Cockpit provides the possibility for large scale data aggregation and flexibility for user customization and interaction.

Fig. 1. Cockpit in aerospace

B. Data Format To ease the difficulty of system level data aggregation, a

common data format needs to be predefined. This format should satisfy the following demands:

A Preliminary Investigation on Smart Grid Operation Cockpit

Zhemin Zhou, Wenchuan Wu*, Member, IEEE, Xuzhu Dong, Boming Zhang, Fellow, IEEE, and Hongbin Sun, Member, IEEE

S

IEEE PES ISGT ASIA 2012 1569526635

1

1 2 3 4 5 6 7 8 91011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556576061

1) Simple and intuitive, so that other developers could understand and use it without any difficulty;

2) Highly extensible. New data of various types could be added dynamically;

3) Platform independent and language independent. It is required in enterprise software platform.

Considering these restrictions, the JavaScript Object Notation (JSON) is used in this paper. JSON is a text-based and human-readable data interchange format, described in RFC 4627 [7]. A JSON object is a collection of key-value pairs, in which the key is always a string and the type of values could be any basic type (number, string, etc.), another JSON object or array (including array of JSON objects). Its hierarchical structure provides the ability to describe complex structures.

JSON is a popular data format for web-based applications. Native JSON support is included in the ECMAScript standard (edition 5), and is supported by all modern web browsers. Although based on a subset of JavaScript language, JSON format can be parsed by other predominant programing languages (C/C++, Java, C#, Perl, Python, etc.). Compared with Extensible Markup Language (XML), which has been widely used in power system data exchange, JSON is a light-weight format. JSON has a much lower overhead and much easier to be created and parsed, making it a better choice for common data interchange.

C. MVC Architecture The classic Model–View–Controller (MVC) architecture,

originated from Smalltalk, is adopted to develop the operation cockpit. In brief, the Model is the structured data set and the View refers to its screen presentation. The Controller is responsible for the handling of user input. This architecture separates data storage from data presentation and can significantly increases flexibility and reusability.

In Operation Cockpit design, the original data is passed to the Model through an intermediate layer, which acts as both data collector and aggregator. Firstly measurement data from SCADA and analysis results from other applications are gathered. Then these data (corresponding to ‘value’ in JSON format) are marked with specific identifier (corresponding to ‘key’ in JSON format) and stored in database.

For example, some basic information of a bus after topology analysis can be expressed in JSON format:

{ “name”: “Bus1”, “ID”: 1, “type”: “bus” “voltage”: 110, “adjacency”: [

{ “name”: “Line2”, “type”: “line”, “ID”: 2 }, { “name”: “Line3”, “type”: “line”, “ID”:3 }

] } The View queries the database and performs the data

rendering on the returned data set. Since the Model only provides the structured data, the User Interface (UI) logic is totally leaved to Views and Controllers. The first benefit of the decoupling is that it permits independent development and maintenance of the back-end modules and front-end modules. The second benefit is that different Views could be directly applied on the same data set, offering the possibility for customization. For example, the voltage control application may query the voltage of buses and send the filtered data set to a bar chart view. The same data set could also be sent to a line chart view or pie chart view, without any modification. In this way, the architecture enables low-cost and highly flexible visualization development at system level.

D. Component-Oriented Design As many analysis modules would be integrated into the

Operation Cockpit to offer a sophisticated view of the whole system, a both extensible and effective system structure is required. While the MVC architecture has successfully constructed a double-layer system in vertical direction, a component-oriented design pattern is used to construct the system in horizontal direction. A message-based communication mechanism is developed for module communicating, with high efficiency and safety. This mechanism simplifies the interaction between modules and the loosely coupled modules make up a flat system. Some details of implementation will be discussed in section III.

E. Multiscreen Display As mentioned above, the key part of an Operation

Cockpit is called Wall Display System. Based on the proposed techniques, the Wall Display System can be established.

The Wall Display System is usually made of six screens arranged in a 3x2 grid (Fig. 2). Operating KPIs of power system, which are calculated by different analysis applications, stored with uniform JSON format in the database, rendered by different forms of Views, managed by different modules, are shown on the Wall Display System. Each screen describes one part of the system status and an overall report about the whole system is formed by the entire Wall Display System.

Fig. 2. Wall Display System Since the contents in each screen are always related, the

logic of a “smart” Wall Display System can be of high complexity. For example, when user changes the settings of the system on one screen, the contents of other screens

2

1 2 3 4 5 6 7 8 91011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556576061

should change accordingly. When user chooses a collection of electric devices, all the screens should highlight the information relative to the selected devices.

III. IMPLEMENTATION

A. Data Storage While the JSON format itself allows for dynamic

extension, the traditional Relational Database Management System (RDBMS) provide poor support for such extension. Every table in the RDBMS is bound with a predefined schema, so adding new attributes to several existing rows is impossible — the whole table must be updated. This leads to a significant high cost of schema design in earlier develop stage. The RDBMS is also inconvenience for hierarchical data storage. As the parsing procedure can be very complicated, JSON or XML formatted data is usually stored as simple text block in RDBMS.

To meet the demand of supporting dynamic and hierarchical JSON data, a NoSQL database called MongoDB is adopted here. MongoDB uses Binary JSON (BSON), a superset of JSON, as the primary storage format. BSON objects are simply gathered in a “collection” (correspond to table in RDBMS) for management issues and the “collection” is schema-free, which means any BSON objects can be used and modified at run-time. Applications can dynamically create, modify and remove attributes on a specified BSON object at run-time. This feather greatly simplified system design and development in Operation Cockpit.

B. Model/View Architecture Qt is a cross-platform application framework that is

widely used in enterprise software development. In the development of Operation Cockpit, Qt is used as the fundamental develop framework. The 4th version of Qt introduced a derivative implementation of the MVC architecture, called Model/View architecture. In Qt’s implementation, the Controller is merged into View, offering a simpler structure. When flexibility for user input handling is required, the Delegate, a simplified and light-weight version of the Controller, is used.

The core of Model/View architecture is the abstract structure of Model, which serves as the standard interface for data access from Views and Delegates. The structure is designed to be a hierarchical table. Items in the table are indexed by the row number and column number and every item can be the parent of another table of items. Data stored in an item is bound to different roles. For example, the Display Role indicates that the data is used to be shown on screen and is probably a string. Decoration Role, on the other hand, probably stores an icon that gives an illustration of the item. Since roles only give a hint about the stored data, it’s the View’s duty to decide how the data is rendered and organized on the screen.

Although compatibility with JSON format is not taken into account in the design of Qt’s Model structure, a model in Qt can be converted to a JSON object without any difficulty, and vice versa. The Role in Model corresponds to the key in JSON object, and hierarchical data support in these two structures is implemented in a similar way. However, this is not coincidental. The similarity implies that

this structure is a universal and powerful abstraction for dynamic data.

As JSON objects can be converted from/to the Model/View architecture, many graphic libraries that perform data rendering on JSON formatted data can be used, acting as Views. Since Qt only offers three basic built-in Views (list, tree and table), this significantly increase the diversity of expression. In other words, Views are extended at low cost. All the visualization tools, including 3rd party graphic libraries and Qt’s built-in Views, are called Visualization Toolkit.

C. Module Communication and Display Different modules in the system are often independently

developed and maintained. The communication mechanism in the system should allow for such independence, with a simple and effective interface. A message-based mechanism is applied to the Operation Cockpit system. The work-flow is illustrated in Fig. 3.

Fig. 3. Message-based communication When status of one module changes, or a service offered

by another module is required, it will emit a signal with type identifier and relevant data (called a message). The message is firstly sent to the framework. The framework will check the type of the message, react to that change if needed and then send this message to other modules. When other modules receive the message, they will also check the type and react accordingly.

While the work-flow is simple and natural, the efficiency and security issues must be resolved. For language like C++ that has no built-in Garbage Collection (GC), since the number of message receivers is unknown to the message sender, manual GC is impracticable. Passing a copy of the data to the receiver could solve the problem but will slow down the program and increase memory usage. This problem is more serious in multithread programing, as the receivers process the message asynchronously. The message-based communication mechanism uses smart pointers, which act as automatic resource calculators, to ensure safety with no sacrifice of efficiency.

In the Operation Cockpit system, each module is packed into a dock widget. Within the dock widget, the module can be integrated into the main window of the Operation Cockpit, and can also be shown separately in another screen. In this way, different modules and relative Views can be output to the Wall Display System conveniently. It also gives users the freedom to reorganize the Wall Display System.

D. System Integration The whole system design is illustrated in Fig. 4.

MongoDB serves as the common data source for the front-end system, with all data stored in JSON format. Modules in the front-end system query data from the database and send the filtered data set to the Visualization Toolkit. The Visualization Toolkit performs data rendering using

Module A

Module B

Framework Message (type, data)

Message (type, data)

3

1 2 3 4 5 6 7 8 91011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556576061

different kind of Views and output them to the Wall Display System. The background communication mechanism of Model/View architecture keeps synchronization of Models and Views. And the decoupling of Models and Views makes the visualization schema highly customizable.

Fig. 4. Operation Cockpit system

E. Example A simple example of the Operation Cockpit system is

shown in Fig. 5, based on a distribution network. The power flow calculation results are attached to the relative devices in a tree view. The tree view is module in the cockpit system and can be moved to and maximized in another screen. When user checks several devices in the tree, a bar chart or a pie chart can be used to show relative results.

Fig. 5. Results in bar chart and pie chart

IV. CONCLUSION A more general, flexible and user oriented visualization

solution is needed for the development Smart Grid. This paper gives a preliminary and fundamental investigation on the system design and implementation of the Operation Cockpit system. The Operation Cockpit system decreases the cost of data visualization at system level and increase the

customizability. A uniform data format is introduced for data aggregation, and a NoSQL database is used for persistent storage. MVC architecture and component-oriented technique are used in the proposed system. The modules in system are prepared for the output on Wall Display System, so that operators can get a comprehensive understanding of the power system.

V. REFERENCES [1] T. J. Overbye and J. D. Weber, "Visualization of power system data,"

in System Sciences, 2000. Proceedings of the 33rd Annual Hawaii International Conference on, 2000, p. 7 pp.

[2] T. J. Overbye, "Wide-area power system visualization with geographic data views," in Power and Energy Society General Meeting - Conversion and Delivery of Electrical Energy in the 21st Century, 2008 IEEE, 2008, pp. 1-3.

[3] J. Zhu, E. Zhuang, C. Ivanov, and Z. Yao, "A Data-Driven Approach to Interactive Visualization of Power Systems," Power Systems, IEEE Transactions on, vol. 26, pp. 2539-2546, 2011.

[4] Z. Jian, P. Tianjiao, W. Wei, L. Jingr, and W. Weining, "A Comprehensive Assessment Index System for Smart Grid Demonstration Projects," Power System Technology, pp. 5-9, 2011.

[5] T. Wei1, H. Guangyu, L. Feng, H. Wenying, D. Zhaoyun, and D. Yong, "A Preliminary Investigation on Smart Grid’s Low-carbon Index System," Automation of Electric Power Systems, pp. 1-5, 2010.

[6] W. Zhi-dong, L. Hui, L. Jun, and H. Feng, "Assessment Index System for Smart Grids, "Power System Technology, pp. 14-18, 2009.

[7] "Internet Engineering Task Force" [Online]. Available: http://www.ietf.org/rfc/rfc4627

VI. BIOGRAPHIES

Zhemin Zhou received his Bachelor degree from the Department of Electrical Engineering, Tsinghua University, Beijing, China, in 2010, where he is now pursuing the Master degree. His interests include the power system visualization. Wenchuan Wu (M’2006) was born in Jinhua, Zhejiang in China on Nov. 26, 1973. He graduated from the Department of Electrical Engineering, Tsinghua University, Beijing, China, in 1997 with MSc. He received his PhD degree from Tsinghua University in 2003 where he is now an associate professor. His special fields of interest include the EMS/DMS advanced applications, especially the online security and risk assessment Boming Zhang (Fellow,2009) received his Ph.D. degree from Tsinghua University, Beijing, China, in 1985, in electrical engineering. From 1985 he has progressed from a lecturer to an associate professor and finally to a professor in the Department of Electrical Engineering of Tsinghua University. His research interests include power system analysis and control, especially the EMS advanced applications in EPCC. He is a steering member of CIGRE China State Committee and Int. Workshop of EPCC. Hongbin Sun (M’2000) received his double B.S.degrees from Tsinghua University in 1992, the Ph.D from Dept. of E.E., Tsinghua University in 1997. He is now a full professor in Dept. of E.E., Tsinghua Univ, and assistant director of State Key Laboratory of Power Systems in China. From 2007.9 to 2008.9, he was a visiting professor with School of EECS at the Washington State University in Pullman. He is members of IEEE PES CAMS Cascading Failure Task Force and CIGRE C2.13 Task Force on Voltage/Var support in System Operations. His research interests include energy management system, voltage optimization and control, applications of information theory and intelligent technology in power systems. He has implemented system-wide automatic voltage control systems in more than 20 electrical power control centers in China. He won the first rank prize of Beijing science and technology progress in 2004, the first rank award of Chinese national high education achievements in 2005 and the second rank prize of Chinese national technology innovation in 2008 respectively. E-mail: shb@tsinghua.edu.cn

View

Model

MongoDB

EMS Analysis Applications

Data Collector/ Aggregator

Wall Display System

Module A Module B

Visualization Toolkit

4