Interfacing to outage management systems
Mandatory interfaces
A review of Figure 1 identifies the following interfaces as mandatory:
-
Model Build (Items 1 and 2)
-
Call Taking (Items 3, 4, and 5)
-
Reporting System (Item 12)
These interfaces should be considered the minimum that a utility can implement to support an OMS
implementation that satisfies its operational requirement. If constrained by budgetary restrictions,
these interfaces should be the first to be implemented. Once these interfaces are in place, the utility
can start realizing the benefits associated with an OMS implementation, leading to further
justification for adding the complementary interfaces described in subsequent sections.
Model Build Interfaces
In order to maximize OMS performance, it is necessary to maintain a current network model and
subset of the GIS records as well as CIS records. While certain systems may include provisions for
only a complete model update (which may be performed on a feeder-by-feeder basis), it is
recommended that the mode and customer updates be performed on an incremental basis. Only
changes to the as-built model are applied to the OMS.
The incremental update process must provide provisions for maintaining the current status of the
system when performing the updates so that temporary status is maintained. The incremental update
process should include business rules for identifying data anomalies that may result in errors in the
outage analysis. It is most desirable that this batch mode interface includes a user-friendly interface
that allows a control room operator to schedule the updates and abort the updates if necessitated by an
operational condition. Most commercial OMS include an incremental model-build process to serve as
the interface identified in Figure 1 Item 3. This interface is always customized to suit the GIS data
model. Utilities may also choose to expand upon this functionality to meet their specific needs.
Usually the model-build and customer-update processes are treated as distinct activities. The
frequency of running either of these processes should be determined based on current operational
requirements. Caution should be paid to ensure that the update is run at a sufficiently high frequency
to ensure the OMS model represents closely what is found by the crews in the field. The GIS model is
updated on a more frequent basis than the subset of the customer information.
Call Taking Interfaces
One of the most important aspects of an OMS implementation is the ability to reliably provide a
means of recording customer outage-related calls as well as the ability for the utility to provide timely
outage status information to the customer in real time. No matter which interfaces are selected for
entering calls and providing status, the following questions should be asked and answers provided for:
-
Is the customer part of a known outage?
-If the customer is part of a known outage, provide what is the estimated time of
restoration, and possibly crew status and high-level outage cause.-
Is the customer aware of any hazard conditions? (For example wire down and arcing.)
The simplest means of entering call information is to develop a simple entry screen for a call taker to
perform queries and inserts on the OMS database. This method of entering calls and providing status
should only be considered in small utilities where CIS-related constraints preclude a more
sophisticated call-entering mechanism.
Typically the CIS, IVR, and outsourced call overflow include functionality to automatically identify
the caller's phone number to immediately query the outage database for the presence of a known
outage condition. It is important to note that the OMS on its own provides only limited benefits to the
utility. It must be used in conjunction with an efficient means of call entry. The automated means of
call entry, such as an IVR, offers a tremendous increase in call throughput.
