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.
