A web-based spatial viewer for operations resource management

A web-based spatial viewer for operations resource management

Brett Doehr
Product Manager CES International 3140
Harbor Lane North, #202 Plymouth, MN 55447

Hannu Huhdanpää
Development Manager CES International
3140 Harbor Lane North, #202 Plymouth, MN 55447

Abstract
Utilities are placing increasing emphasis on making their outage management systems (OMS) available via the web to make these systems more scalable, more flexible, and more accessible to remote users. This allows a utility to better support decentralized operations during storms and other high-activity periods. This paper presents an approach to view and interact with a spatially enabled OMS model using a web-based viewer. PL/SQL scripts are used to spatially enable the utility’s OMS model in a relational database management system. The model consists of database tables for all the durable objects, such as electrical devices, and for dynamic operations-related objects, such as outages and crew locations. A concept of a layer is introduced which is a database view definition over any of these spatially enabled entities, and users of the viewer select which layers to view. Bringing the required objects into view consists of fetching the data from Enterprise JavaBeans™ (EJB) objects, which execute standard SQL queries against the layer view definitions and cache the data for efficient serving of future requests. Tunneling fetches via the HTTPS protocol provides additional security. Feedback from utilities using this functionality will be presented. Other ideas for future enhancements will also be discussed.

Introduction
Many power utilities are consolidating operation centers to streamline routine operations, yet at the same time finding benefits in becoming decentralized in times of high activity or when events are focused in a remote area. These distributed, remote users can benefit from a graphical viewer that displays a variety of spatial information in an efficient, scalable manner. Such a viewer enables a user to see layered information including electrical networks, landbase data, outage and crew indicators, note and tag markers, and text labels such as device names and streets. This information, especially in conjunction with other web-based tools, allows more efficient management of crews and outages.

Architecting a web-based viewer
The architecture used for the viewer makes use of several components that are installed as Windows services, as shown in the below diagram. Either Apache’s HTTP Server or Microsoft’s Internet Information Server (IIS) can be used for the web server. We use Tomcat for the Java Servlet / JavaServer Pages (JSP) container, since it is the official reference implementation and is available as Open Source. For the Enterprise JavaBeans container, we opted for Recursion Software’s Voyager server. And for the ORB used with our CORBA Gateway, we support the choice of Borland’s VisiBroker or MICO, an Open Source offering. For the client (end-user) PC, we use Microsoft’s Internet Explorer or Netscape’s Navigator for the web browser, along with the Java Plug-in that will be auto-downloaded if not previously installed. Other than the Java Plug-in, running the web-based viewer is essentially “zero-install” for the client PCs.

Figure 1 - Web Gateway Architecture
Each component has an essential role to play in making the web-based viewer viable. Certainly a web server is required for supporting any web browser-based applet. Tomcat enabled the use of a JSP-based secure login, as described in the section on security. The Voyager EJB container allows processing of standard viewer commands and more importantly the caching of the results, as described in the next section. The CORBA gateway interfaces the Java software to the Isis messaging software that communicates with the core Outage Management System services. Even though the viewer accesses much of its data using a JDBC connection to a database, some data is transmitted via Isis messaging. The CORBA Name Service is required to manage the name-object mappings used by the CORBA gateway.

Spatially Enabling a Database
When initially implementing the web-based viewer, Oracle’s Spatial Data Option (SDO) was used to spatially enable our outage management system (OMS) database. However, we subsequently developed an internal option for several reasons. The first was a cost consideration since the added price of 3rd-party products is a factor, especially for small utilities such as co-ops. However, replacing it would not have been feasible if it weren’t that we needed only a small fraction of the Oracle SDO capabilities. Additionally, it turned out that our internal solution using geo-spatial partitions proved more efficient for our use. Oracle’s SDO queries for objects are based on geographical indices, which are more efficient in terms of only returning the area that is needed. However, since we used caching of the query results, as explained in a later section, it proved more effective to return the larger map partition that contains the desired object. If a nearby object were then sought, it would likely be located on the already-cached partition, obviating the need for a query back to the database.

Our spatial data option uses a set of PL/SQL scripts to add columns to one of the OMS database tables, as well as creating a new table. For our DIAGRAM_OBJECTS table, which contains all of the objects in the utility’s data model, we added a SHAPE column containing an aggregation of the point coordinates of the object, a SHAPE_TYPE column to indicate how to draw the object, and a NUM_POINTS column to indicate the number of anchor points. Typically this is done after an initial model build to calculate values for all existing rows in the table. The scripts also add a trigger such that when new rows are added or existing rows are changed or deleted during an incremental model build, the appropriate values for these new columns are calculated for each new row.

The scripts create various database views by joining data in other database tables of our schema with the spatially enabled data in the DIAGRAM_OBJECTS table. For example, to see outage information in the spatial viewer, a SPATIAL_OUTAGES view is created by joining the OUTAGES and DIAGRAM_OBJECTS tables. The same is done for all dynamic data such as notes, tags, crews, and so forth. Similarly, for data such as roads that can be fetched without requiring any joins, database views are defined to pull in objects with the proper object types from the DIAGRAM_OBJECTS table. This way, all the viewable data in the system is partitioned into named layers. All the viewing happens by bringing in specific layers for requested partitions. The scripts also create a SPATIAL_LAYERS table that includes information such as which layers of information are displayed by default, which contain selectable objects, the zoom range within which they are displayed, the color to be used, the draw order, and other parameters. With the SPATIAL_LAYERS table, the large amount of data in the DIAGRAM_OBJECTS table can be partitioned into logical layers, the visibility of which can then be individually determined.

Background data such as water bodies and subdivisions, also referred to as landbase, is handled differently due to its very large data volume. Rather than being stored in the DIAGRAM_OBJECTS table, it resides in background map files that are based on the DXF format. To see the background within the spatial viewer, these DXF files are pulled from the OMS onto the Web Gateway server and parsed with a Java DXF parser. This parsed data is cached by partition on the Web Gateway server, just like the data from the DIAGRAM_OBJECTS table. This data can then be fetched by the client viewer and displayed along with the data from the DIAGRAM_OBJECTS, if the user wants to see the background as well. Since this background data comes from a DXF file instead of a database table or view, it is not further divisible into layers. If the user displays the background data layer, all the background will be visible.

Achieving Scalability Through Caching and Efficient Updates
The use of an EJB container such as Voyager gave us the ability to cache information such that a large number of users could be supported. If dozens of users were each directly querying the database for map partitions, the performance impact on the database could be prohibitive. However, map partitions are cached in a viewer EJB, so that only the first request for a given partition requires a database access. Subsequent requests for the map partition, either by the same user as they navigate away and back to the area, or by another user, will only need to go as far as Voyager’s EJB container.

Another way in which scalability is achieved is through the use of a Publisher used with the CORBA gateway that allows the viewer to subscribe to messages that provide updates to the cached information. A set of associations is maintained between message types and layers such that when a message is received that a certain type of update has occurred, only the associated layers for the affected partition(s) are uncached.

Viewer Functionality

Figure 2 - Web-based Viewer
The viewer is interactive and supports several functions in addition to data display. A set of “pan bars” around the border of the viewer display area allow panning up, down, left, right, or along any diagonal. The text boxes on the lower right indicate the current object selection in the viewer (left text box) and a selection in an associated tool (right text box). Web-based tools integrated with the viewer include a work agenda of outages and nonoutage events, crew management tools, and customer and call information. The toolbar, which is shown along the right side of the viewer but may be repositioned to any border of the window or left floating in its own window, offers several functions. The top two buttons toggle the viewer selection mode between the Control Tool and the Trace Tool. When in Control Tool mode and a device is selected, a popup window opens that supports the opening and closing of devices, adding notes or “Do Not Operate” tags to devices, moving outage predictions upstream / downstream, and bringing up device attributes. Examples of a Tag icon (white T inside a filled box) and a Note icon can be seen on a device in the lower center of the viewer. Outage type indicators (RO, PSO) can be seen on several devices, and rings indicate devices in an abnormal state (e.g., open when normally closed). A crew truck icon can also be seen near a device to the right of center. Each type of icon resides in a separate layer and thus supports efficient updates as described in the previous section.

When in Trace Tool mode and a device is selected, the viewer opens a popup window allowing the user to select the type of trace to be performed: To Source, To Switch, To Transformer, or to All Connected devices. The “file cabinet” button brings up a search popup dialog, where for example a device name (or partial name) can be entered. If a partial name is entered, all matching device names will be displayed for selection. The “H/D” button allows turning on or off the display of graphical layers such as electrical components, landbase data, text, etc. The next two buttons are Back and Forward arrow buttons that function similar to such buttons on a web browser. Whenever the displayed view area is changed as a result of panning, zooming, or focusing on another device location, the previous view is cached up to a configurable number (typically 12). The Back button can then be used to “un-zoom”, “un-pan”, or otherwise undo a view change, just like navigating through web pages. Next down on the toolbar is a “refresh” button that does an on-demand update of the displayed viewer information. Use of this button is needed to see updates associated with electrical network changes.

The magnifying glass button brings up a zoom tool that supports step zooms in or out with a settable zoom magnitude. As alluded to in the SPATIALLY ENABLING A DATABASE section, some layers of information will not be displayed at certain zoom levels, typically when zoomed out to a high level. The “target” button will center the viewer on a selected device. The device selection can be done within the viewer, or outside the viewer from another tool in the same product. A typical example might be to select in an event list a new outage with a large number of customers out, which “registers” the associated outage device as selected. The name of the device will be displayed in the rightmost text box on bottom of the viewer, and then the “target” button can be used to focus the viewer on that device location. A user could then look in the viewer to see if any crews are dispatched nearby and assign them to the new outage location.

The final toolbar button is a “stop” icon, which will hide the viewer window until it is selected again from the associated environment manager. SECURITY One key concern with any software package, especially one that is intended for remote users, is secure access. This includes minimizing access to any components of the software until the user is authenticated, and making certain that the authentication process itself is secure. The approach taken was to begin with a JavaServer Pages (JSP) login interface so that no software, including Java applet jar files, would be exposed until after the authentication process was completed. Since the applet makes use of Extensible Markup Language (XML) and standard Java properties files, in addition to the compiled class files, some of the information in the jar files is readable and therefore it is desirable that they not be downloaded as part of the initial login process.

As show in Figure 1 - Web Gateway Architecture, the Tomcat Java Servlet/JSP container is used during the login process. The connection to Tomcat supports HTTPS, meaning it uses Secure Socket Layer (SSL) in conjunction with standard HTTP to provide an initial secure connection. To further protect the transmittal of the login credentials from the client PC to the Web Gateway PC, the password undergoes a one-way hash using MD5, the same general technology used with SSL. Since the Web Gateway PC is typically located on a local subnet with the Oracle database server, no further security may be required. However, if desired the transmittal between the Web Gateway and database can be further secured using Oracle Advanced Security option. This option encrypts the password retrieval from the database, and also supports checksum authentication to ensure that the password was not tampered with during transit.

Feedback and Future Directions
The initial response from the pilot use of this functionality has been positive. The ability for a utility to enable service depots and other remote sites to graphically view their area of responsibility and see relative grouping of outages, device conditions, and crew locations is of great benefit. Naturally as users are exposed to the product, they generate recommendations for enhancements. These help shape the future direction of the viewer along with the other integrated web-based products. Some of the viewer-related items are mentioned below.

Currently changes to the “condition” layers such as outages, crews, tags, and notes are automatically updated in the viewer, since the data involved is comparatively small. However, when larger-scale changes occur such as changes in the state of the electrical network, the user must do an explicit refresh of the viewer. This is done for performance reasons, and options are being investigated on how to indicate to the user that updated information is available.

Also, additional color-coding of viewer information based upon database values is being examined. Currently color-coding of phases, device state, and energization state is done. Under consideration is adding color-coding for loops, parallels, and other topology. The viewer supports searching based upon device and partition information. Since individual customer issues drive much of the utility’s activity, the ability to search based upon customer criteria such as account number, name, address, etc. is being considered. Another area of future development is support for disconnected operations, for example when a repair crew receives a set of planned work activities and goes into the field. To be able to work in a disconnected mode, the viewer map data needs to be cached locally on the client side, in addition to the server side caching, so that it can be navigated to even when the server is not accessible. The infrastructure components for doing this are already in place, since JDBC is being used to fetch the data from the database server and we also already have developed a JDBC driver against a flat file. To read maps from a local disk or CD, the map data must be serialized into files using Java serialization and then read them using the flat file JDBC driver. The applet doing this would have to be digitally signed for security reasons. Also, the background data is already being read from files as described above, so for disconnected more those files would simply have to be persisted on the client side. Furthermore, once this technology for disconnected operations is in place, various personal computing devices, such as PalmOS, PocketPC, and smart cellular telephones become feasible substrates for this technology.

Glossary

CORBA	Common Object Request Broker Architecture
DXF	Drawing Exchange Files
EJB	Enterprise JavaBeans
HTTP	Hyper Text Transfer Protocol
IIS	Internet Information Server – Microsoft’s web server offering
Isis	The causally and totally ordered communications support (CATOCS) – based messaging bus used by CES International
JDBC	Java Database Connectivity
JSP	JavaServer Pages
MD5	Message Digest 5, a one-way hash algorithm
MICO	Open Source CORBA ORB option
ORB	Object Request Broker
PDO	Predicted Service Outage
PL/SQL	Procedural Language / Standard Query Language
RO	Real Outage
SSL	Secure Socket Layer
Tomcat	Jakarta project’s Open Source Java Servlet/JavaServer Pages container
VisiBroker	Borland’s commercial CORBA ORB option
XML	Extensible Markup Language