Integrated Power Analytics Visualizations

Using SVG and Modern Web Technologies

Josh Pearce

Josh Pearce is a software engineer at the Power Analytics Corporation and developer of Paladin DesignView.


Abstract


Building power analytics visualization and analysis user interfaces within standard power systems monitoring packages is challenging and inefficient. We needed a single web-based system that could be integrated into monitoring packages from multiple venders while preserving the same workflow for our engineers.

DesignView is a technology developed by the Power Analytics Corporation to provide advanced visualization capabilities for their power systems analysis platforms, Paladin Live and Paladin Smart Grid. Paladin Live uses a model of the power system to predict vulnerabilities or energy inefficiencies and allows operators to run "what-if" scenarios. The unique challenges of real time power analysis combined with real time data require a very high performance, secure and flexible visualization environment well suited for SVG. The variation in user groups exposed to the analytics also impacts the implementation and how DesignView is integrated into a larger data acquisition and historical logging systems.

DesignView is the user interface component of a larger power analytics suite of applications. As shown in Figure 1, the suite consists of:

  1. Paladin DesignBase -- Contains the power system model and simulation engine.
  2. Paladin Live -- Real-Time power network management.
  3. Paladin SmartGrid -- Real-Time power grid optimization.
Paladin Overview

Figure 1. Paladin Overview


Table of Contents

Requirements
Architecture, Overview
Detailed Architectural Outline
Client Architecture
Server Architecture
SVG Documents
SVG Widgets
WYSIWYG Editor
Moving and Resizing
Editing Widget Properties
JavaScript Object Model
Challenges
Conclusion
Bibliography

Requirements

The application needed to enable non-software developers to create and edit drawings quickly. The system architecture also had to be flexible and extensible to meet the changing needs of the company. To solve this, we created an in-browser, drag-and-drop WYSIWYG designer and runtime engine using modern web technologies.

It was clear when we started this project in 2010, that the timing was right to build an SVG-based web application. We found the combination of recent web browsers, fast JavaScript engines, and Scalable Vector Graphics provided a powerful development and runtime environment. SVG, when contrasted with alternatives such as Flash, Flex or Silverlight, provided a more elegant development strategy and allowed DesignView to run on a broader set of platforms.

Architecture, Overview

Other web-based visualization products in the power industry use ActiveX components, Flash or Silverlight. When they have targeted SVG, it's been through the EOL'd Adobe SVG Viewer. We built an application where SVG elements are treated as first class DOM citizens. This has been the most important design decision in the project. It allows us to use standard web development methods, leverage powerful JavaScript libraries, and target mobile devices because our application does not require a plugin to run.

Figure 2 is a feature diagram describing the system components and the technology used to implement them.

DesignView Architecture

Figure 2. DesignView Architecture

Detailed Architectural Outline

Client (Web Browser)

  • SVG Document

    • SVG Widgets (Instruments and Layout objects)

      • Graphical Elements

      • Metadata

  • JavaScript Object Model

    • Wrapper Classes for Widgets

      • Convenience Functions for Editing Attributes and Data

      • Caching of Expensive DOM Queries

  • Communication Model

    • Common JSON Envelope for Asynchronous Communication

      • Status

      • Payload

      • Method Invocation

Server (ASP.NET MVC)

  • Persistence

    • Castle's ActiveRecord

    • Sqlite

  • Data Gateway Communication

    • WCF (Windows Communication Foundation)

  • Security

    • Custom User/Role/Permission Scheme

  • Business Logic

    • SVG Screen Parsing

    • Simulation Requests

SVG Documents

We follow the live-editing paradigm. What this means, is that a screen consists of a single SVG XML document. During design time, the screen designer is making changes to this document and when they are done, it's saved as an XML blob. To glean information about a screen, the system will inspect the saved SVG XML and even make small changes, but for the most part, the SVG document, as it was edited in the browser, is unchanged when displayed at runtime. And, each widget, once placed in the screen, maintains no connection or reference to the original widget definition.

An alternative to the live editing approach would be to follow a "def-ref" model. Under this paradigm, no matter what happens during design time, a saved screen, rather than being an XML blob, consists of only the configuration properties that were edited for each widget, e.g. their colors, position on the screen, rotation, and the data points to which they were bound. These configuration properties along with the ID and version of the widget constitute a reference to the widget definition. It's only at runtime, that the SVG for the display screen is built by combining the reference data into the widget definitions.

The "live-edit" method offers more flexibility than "def-ref". For example, if a power user of the system decides to make a change to the way a widget works, he does not need to create a new widget definition, but only has to alter a portion of the SVG document. The downside of the "live-edit" method is that when we need to change the behavior or widgets that are already in screens, we have to either delete and replace them, or write a script to update them in place. Once we have a robust library of mature widgets we'll look at implementing a more formal "def-ref" model for the screens.

SVG Widgets

We implemented an extensible widget interface in DesignView. Widgets exist as small XML files on the server and are loaded via AJAX during development. Figure 4 illustrates the structure of a widget.

SVG Widget Structure

Figure 4. SVG Widget Structure

The following components are required for every SVG Widget:

  1. Wrapper Group - The outermost element of a widget is a single group tag with the following attributes:

    1. id - for example, "dialGauge", which then serves as the id prefix for each instance of the widget in a screen.

    2. class - The class attribute with the following classes defined.

      1. HMI Object Class - Every widget has this.

      2. Identifier Class - This is the same as the ID.

      3. Layout/Instrument - Declares whether this widget is simply for layout purposes or is data bound.

      4. hmiNoScale - Optional attribute that restricts an item from being scaled.

    3. transform - The transform attribute of the group is used for the X and Y positions of the widget on the screen and for the scaling. (Scaling is restricted by the existence of the hmiNoScale class)

  2. Metadata - Includes the following elements.

    1. Name/Type/Version

    2. Data Binding Addresses - Multiple addresses with purpose differentiating attributes.

    3. Configuration Parameters - Different types of configuration types to choose from. Each parameter has a default value which is editable by the user at design-time. Values are read by the widget's event handlers. Here are the different types of parameters:

      1. Static Display Text - Configuration parameter to let user modify static text in the visual SVG.

        <edsa:configparam key="text-disp-text" label="Default Text" type="8" query="text" iscss="false"  />
        
      2. Color Chooser - Configuration parameter for a simgle color

        <edsa:configparam key="sw-color-on" label="Digital State 1 " type="2" color="red" />
        
      3. Five Color Range - Stores Range and corresponding color data for analog value displays.

        <edsa:configparam type="14" label="Color Ranges" key="color-range"
           minval="-3" loloval="-2" loval="-1" hival="5" hihival="10" maxval="100" lolocolor="white"
           locolor="white" normcolor="white" hicolor="white" hihicolor="white" />
        
      4. Format - Sprintf styled formatting for values.

        <edsa:configparam val="%.2f" type="5" label="Format String" key="format" />
        
      5. Font Family

        <edsa:configparam iscss="true" query="text" type="6" label="Font Family" key="text-disp-fontfamily" />
        
      6. Font Size

        <edsa:configparam iscss="true" query="text" type="7" label="Font Size" key="text-disp-fontsize" />
        
      7. Bold

        <edsa:configparam iscss="false" query="text" type="9" label="Bold" key="text-disp-bold" />
        
      8. Checkbox - true/false value.

        <edsa:configparam key="units" label="Show Units" val="false" type="11" />
        
      9. Italic

        <edsa:configparam query="text" type="16" label="Italic" key="text-disp-italic" />
        
      10. String - An arbitrary string value; can be parsed to numeric.

        <edsa:configparam val="5" type="1" label="Major Ticks" key="range-major-ticks" />
        
    4. Data Value Update Event Handler - Function body is defined here is a CDATA block. The function is wrapped with a function definition and certain values and helpers it needs.

      function(hmiObj, tags) {
         var tag = tags['default'];
         var $g = hmiObj.getGroup();
         var animCfg = hmiObj.getConfig();
         ... function body inserted here ...
      }
      
    5. On Click Event Handler - Function body is defined here is a CDATA block. The function is wrapped with a function definition and certain values and helpers it needs.

      function(hmiObj, tagNames) {
         return function(evt) {
            var $g = hmiObj.getGroup();
            var animCfg = hmiObj.getConfig();
            var tag = Edsa.Public.epagTagCacheGet(tagNames['default']);
            ... function body inserted here ...
         };
      }
      
    6. Advanced Config Function - Many configurable aspects of widgets are simple and straight forward. They are tied closely with the configurable parameter types. But, other configurable options are advanced and cannot not be handles by the parent system, such as redrawing the arc and tick for the Dial Gauge. For those configurations, the widget must define it's own configuration method, which is called after the user edits the configuration parameters.

      Function body is defined here is a CDATA block. The function is wrapped with a function definition and certain values and helpers it needs.

      function() {
         var hmiObj = this; 
         var $g = this.getGroup(); 
         var animCfg = this.getConfig();
         ... function body inserted here ...
      }
      
    7. SVG Graphics - The actual visible part of the widget. For example, below is the visible SVG portion of the generator widget. One thing to note is that rotation is not performed on every widget, but only those which declare a "rotWrapper".

      <rect class="background" fill-opacity="0" fill="black" stroke-width="1" stroke="none" x="-3" y="-3" width="46" height="46" />
      <circle r="18" cy="20" cx="20" stroke-width="3" stroke="#000000" fill="Violet" />
      <g class="rotWrapper" transform="rotate(30, 20, 20)">
          <path stroke-linecap="round" d="M20,20 l10,0" stroke-width="4" stroke="#000000" fill="#FFFFFF" />
          <path fill="#FFFFFF" stroke="#000000" stroke-width="4" d="M20,20 l-5,-8.66" stroke-linecap="round" />
          <path fill="#FFFFFF" stroke="#000000" stroke-width="4" d="M20,20 l-5,8.66" stroke-linecap="round" />
      </g>                
      

WYSIWYG Editor

Moving and Resizing

Building the basic framework for a WYSIWYG visualization designer using SVG in JavaScript is not too difficult in concept, it simply requires handling these methods: MouseDown, MouseMove, MouseUp, Click and KeyDown in order to allow moving and scaling elements.

DesignView Edit Mode

Figure 3. DesignView Edit Mode

In order to contain the development effort, we have put several restrictions in place to limit the ways in which the SVG widgets can be manipulated.

  1. Scaling - Only one widget can be scaled at a time. Also, if a widget needs to maintain thin borders, it can use rectangles and their width and height will be adjusted rather than scaling the parent group.

  2. Rotation - Widgets must opt-in to rotation, defining a group within themselves which has a rotation attribute.

  3. Grouping and Layers - Grouping and layers are not yet implemented.

We have a single SVG area that comprises an HMI screen. On that screen are widgets. Each widget must be wrapped in a single SVG group, with a special class. Selecting multiple objects is just a matter drawing a selecting rectangle when the mouse is down and moving, and then calculating the whether the widgets are contained in that rectangle or intersect it, depending on the selection type, when the mouse comes up. Each browser vender implements three methods to help you a figure an SVG elements location and containing rectangle: getBoundingClientRect, getScreenCTM, and getBBox. We found that getBoundingClientRect worked well in Firefox and IE9, and that getScreenCTM and getBBox work well in Chrome. The getBoundingClientRect method was broken in Chrome, but we filed a bug ticket and they fixed it.

Editing Widget Properties

Each widget's properties are available from a link in the context menu.

DesignView Properties Edit Mode

Figure 4. DesignView Properties Edit Mode

JavaScript-Object-Model

The main JavaScript application file has is about 10,000 lines long. We use Google's Closure Compiler with EVERY warning set to error to lint the code as part of our build precess. We haven't yet moved to Advanced Compilation mode because we've had trouble references third party scripts and hiding function that need to be globally available.

The Closure Comipler Suite comes with a great versoin of JSDoc. We annotate all of our code with JSDoc style comments and are able to create great HTML documentation.

Performance has been an ongoing challenge. By far the slowest enviornment for SVG DOM access was SVGWeb. We did extensive profiling to identify expensive DOM queries and memoized their results where possible.

Challenges

  1. Support for Internet Explorer versions 7 and 8. We used an open source library called svgweb to provide support for IE7 and IE8. Svgweb converts SVG to Flash in the browser, and fakes in the SVG DOM, making proxy calls into Flash. Svgweb saved the day and allowed us to support older version of IE, yet write the application as if it would only run on modern browsers. We decided early that we wanted to use jQuery for its power and because developers are familiar with it, but in order to make it work, not only with the SVG DOM, but especially with the svgweb DOM, we had to patch it significantly.

  2. Adjusting the properties of those widgets, such as: size, rotation, display text, font, color animation, value display ranges, static colors, position, and more.

  3. JavaScript performance was also an issue. Power systems model screen can contain thousands of widgets, which makes keeping track of them and operations like selection, copying and pasting, and moving very expensive. In addition, Svgweb added significant overhead to each operation. It was necessary to do a great deal of JavaScript profiling to identify slow or repetitive code block, not only in our code, but in svgweb and jQuery, and work around as required using caching, memorization, and efficient algorithms.

  4. Our designer only works most completely in Firefox and it's pretty good in Chrome/WebKit, but not as functional in in IE7 or IE8 using svgweb. IE9 is a future test/road map for us but thus far the native SVG support looks to be outstanding. HMI Widgets

Conclusion

SVG is in many ways the ideal technology for a real time visualization environment in the power world. The rapid changes in and expanding importance of power, energy and in particular the diverse needs of users are all well suited for SVG. In short, the right place at the right time.

Bibliography

[REF1] author-1-firstname author-1-surname. author-2-firstname author-2-surname. editor-1-firstname editor-1-surname. Title of the reference. Publisher name.