Interfacing to outage management systems

Interfacing to outage management systems

Robert Sarfi
Convergent Group
6399 S. Fiddler's Green Circle Suite 600
Englewood, CO 80111

Introduction
With the advent of deregulation in the electric power industry, utilities find themselves preparing for a competitive environment. The advent of deregulation and ever-demanding consumers necessitates faster response times to perform outage restoration and reporting of outage statistics to calculate system reliability indices. OMS or Distribution Management Systems (DMS) have reached a third generation of maturity. First-generation systems provided little more than trouble-call sorting. Second-generation systems associated calls with a protective device. The third generation systems are scaleable and offer advanced functionality such as switch order generation, distribution load flow and crew management.

When faced with implementing an OMS, a utility is often faced with the dilemma of determining which interfaces are necessary to support their business processes. If an electronic source of data is unavailable, the utility will find that the cost of data conversion will probably represent the most significant project cost. Once source of data for the OMS has been resolved, the interfaces to be considered within the scope of the OMS project must be identified. Faced with cost constraints, the utility is faced with the prioritization of the interfaces to be developed. In order to formulate an interface development strategy, it is important for the utility to understand the relative benefits of all the interface types. It goes without saying that the goal should ultimately be to create a paperless environment with one-touch data entry. A reasonable compromise of functionality and cost must be derived. The external systems interfaced to an OMS include:

GIS Model
CIS Model
CIS
IVR
Work Management Systems (WMS)
Mobile Workforce Management (MWM)
Power Monitoring Unit (PMU)
Web-based reporting system

The objective of this presentation is to identify which interfaces are necessary in an OMS implementation and those that should be prioritized based on operational requirements. This presentation is divided into six sections. Section two presents a high-level system overview. Section three presents the mandatory interfaces. Section four describes interfaces that require prioritization. Section five presents implementation risks. Section six offers concluding remarks.

System overview
When considering the interfaces to an OMS system, at the present time most interfaces are executed in a traditional point-to-point fashion. Figure 1 identifies the types of interfaces typically associated with an OMS implementation. It is important to note that Figure 1 is a generic diagram and is independent of the technical specifics of the implementation.

Figure 1: OMS Interfaces

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.

Of increasing relevance to the deregulated environment where a goal is customer retention is the provision for restoration callbacks and status callbacks. The status and restoration callback is typically implemented through the IVR. The status callback provides a customer with any updates in the change in status of the outage. The restoration callback provides both the utility and the customer with verification that the outage has been restored.

A common interface that is often spoken of but rarely implemented is an interface between the OMS and an alphanumeric paging system. The thought is that the major account representatives will be proactively supplied with information about major client outages in real time. In this manner, the account representative can provide the necessary status information to the customer so that they can counsel the customer about mitigating the potential damage associated with the outage.

Reporting Systems Interface
The advent of commercial reporting packages as well as Internet/Intranet reporting mechanisms has facilitated the dissipation of outage information. It is recommended that unreviewed information should not be distributed beyond the enterprise and that current outage and historical statistics be reported for a limited internal distribution. In order to avoid performance issues on the actual OMS production server, it is recommended that a separate report server be implemented and that a batch interface move historical and current data to the reporting server as frequent as five-minute intervals. The batch mode interface should encompass at a minimum the following:

IEEE reliability indices
Current and historical outages by political or geographical boundaries
Current and historical outages by utility defined districts

Interfaces to be prioritized
The prioritization of the remaining interfaces is greatly determined by the presence of external systems. If the additional systems are in place, the cost of the interface is typically easily justified by the benefits brought about by its implementation. The most sophisticated interface addressed is typically the interface to MWM or WMS. It becomes difficult as embedded OMS functionality of crew management is brokered to another system. Within the systems to be prioritized, a utility must identify its own deployment decisions based on operational requirements.

Interfaces to Crew and Work-Related Systems
At the present time, a weakness of OMS is the crew management functionality. A way to strengthen the crew management functionality associated with the OMS is to provide a tight integration to a MWM for short duration work or emergency response work and to a WMS for long duration work or referral to a construction crew. Development of this group of interfaces is complicated because it requires customization to the commercially available OMS in order to handoff work to the external system and receives crew update information from the external system. A common crew database that keeps track of not only crew availability and skills but also equipment, can be interfaced as well to provide the OMS operator a more representative portrait of the available tools to assist in the restoration effort. Interfaces to vehicle location systems are not widely implemented. This is possibly due to the political ramifications associated with implementing a global positioning system in vehicles. Interfaces to Operations and Engineering Analysis Two interfaces that are often viewed as essential but rarely implemented include the uni- or bidirectional SCADA interface and the interface to engineering analysis. The implementation of a uni-directional SCADA interface is a relatively risk free undertaking and can bring benefits to the OMS operators. Analog and digital status can be polled on a predetermined interval. Due to safety and reliability concerns, bidirectional interfaces are rarely implemented. Some incentive exists for an interface to be developed between the OMS and an engineering analysis application to permit the engineer to perform an analysis on the current status of the system. While the implementation of the interface from OMS to the engineering analysis system is not challenging from a technical perspective, it is not typically justified from a business perspective.

A utility can leverage PMUs or suitably equipped automated meters to provide the OMS operator with intelligence beyond the information of the D-SCADA system. While utilities are often reluctant to implement PMUs, if they are in place at a utility they can be employed to assist the OMS operator in determining which protective device is associated with an outage and to verify that the crews have completed the restoration of an outage. The interface is typically implemented as a uni-directional interface from the PMU server and the OMS.

Implementation risks

The major technical risks associated with the implementation of the OMS-related interfaces are itemized:

Performance
Lack of hardware/software upgrade path
Integration strategy
Poor data

Current OMS offerings are considered to be pseudo-real-time systems. Status is not updated in real time but rather on a sufficiently frequent basis to manage the distribution network during outage conditions. Development of the interfaces should include an architecture and implementation that will meet the utility's performance requirements. A common means of setting performance requirements for both the OMS and interfaces include a measure of the maximum number of customers that might call in an hour during a catastrophic incident.

Often the OMS vendor will take advantage of new hardware and software trends when considering upgrades for their systems. The interfaces should be designed so that they do not require much effort during hardware or software upgrades. Designs should be avoided in which there is a proprietary interface, either on the OMS side or the side of the other external system.

Another important consideration in developing an OMS interface is that a solution is selected and implemented that can support additional functionality without replacing or redesigning the interface. While external systems may not support a particular desirable functionality, such as an IVR not being able to perform status callbacks, the design should be suited for future growth and inclusion of functionality.

At the present time, most OMS systems are implemented with a point-to-point integration strategy. When considering integrating OMS into an enterprise system deployment strategy there is increasing consideration of using a middleware-based integration strategy. The cost of a middleware solution should be closely examined as it may prove to be unnecessary overhead. In the case of a small- to midsized utility (less than 1 million customers) or a larger utility with centralized operations, a middleware-based solution is typically not justified. In addition, few OMS systems available at the present time have an architecture that is well suited to implementation within a framework that includes a middleware messaging backbone.

While data does not directly represent a risk associated with OMS interface implementation, it is of paramount importance to the overall implementation and must be discussed. OMS will offer a utility a means of validating their data on an around-the-clock basis 365 days per year. Data will affect the usability of the system as well as the perceived success of the implementation. Considerable effort must be made to ensure that the data of the deployed OMS is of a suitably high quality and represents accurately the current network status.

Concluding remarks
A review of the system interfaces associated with OMS has been presented. When considering the interfaces to external systems, it is important to identify interfaces that are mandatory for a successful implementation and those that can be prioritized. The interfaced systems that are mandatory include the batch interfaces between GIS and CIS, the bi-directional interfaces to the call-taking mechanisms, and to the reporting system. The interfaces to be prioritized include the interfaces to MWM, WMS, Engineering and operations systems, and to PMU and IVR's. If budgetary constraints do not permit implementing all the interfaces described, it is recommended to prioritize development and deployment based on this presentation.