How Power Fail Works

Published Date: 02 Nov 2017

An outage management systems can be an out-of-the-box solution customized for utilities but the difficulty with that is that there is no one-size-fits-all so once you start having to customize a product, the costs go up exponentially. In most cases, for smaller LDC’s whose budget constraints don’t necessarily allow for these increased costs, the look towards finding a solution of using what they already have available to them. With Multispeak, this has become a reality because this protocol will tie together all of the internal systems so that they communicate with each other. The linking together of systems via Multispeak is the easy part. The more difficult part is how to set the priorities on how the various systems get updated if changes are made, and how to prioritize the vast quantities of information available. For the purpose of this paper, we will only focus on the outage management segment of the whole picture.

How Power Fail Works

The AMI system provides outage information in the form of outage flags in event messages and as data quality indicators in the regular supervisory messages.

The event messages can be transmitted on a priority channel away from regular supervisory messages to allow a greater success rate of the message being received at the TBG.

LDC team can more quickly analyze the extent of the outages and send their teams to the source each outage. When a meter loses power for less than a configured number of seconds, it is considered a "click" or momentary outage rather than an outage.

Threshold needs to be defined and meters will need to be configured accordingly.

Utility can track trends to determine, for example, if tree trimming is required.

Clicks will be maintained in the ODS, but should not be automatically transferred to the GIS. However, the ODS needs to be able to export a running total of click counts to the GIS (a 365 day report will be run monthly with 30 day, 60 day and 90 days slices).

Outage Process for Utilities

Introduction

The AMI system provides outage information from the AMI meters in the form of Power Fail flags.  Using the Power Fail flags, utilities can streamline their outage management processes by having a more accurate picture of which consumers have lost power. In this way the outage team can more quickly analyze the extent of the outages and send resources to the source of each outage.

The utility has created a data management strategy.  With the introduction of the volume of data provided by AMI networks, and the possibilities presented by integration of this network with other utility systems, such as CIS, GIS, ODS, MDM, OMS, SCADA, etc., the creation and maintenance of a utility-wide data management strategy becomes increasingly important.  The data management strategy must define the system of record (SOR), or the source of each component of data which might be used by multiple systems.  Some things to consider in the creation of this data management strategy:

GIS systems should be the source, or system of record, for location information.  The programming of GPS coordinates into the AMI meters should not lead the utility to store the location information for the meters in the AMI system.  The meter does not have a GPS locator, but rather the coordinates are programmed into the meter upon installation.  When meters move, their coordinates are no longer accurate (unless re-programmed), and often the accuracy of the coordinates at the time of programming can be suspect.  A utility that may not have ideal data on the location data for meters or even premises, may decide to use the GPS location information within the meter as a starting point for their location information store.  The data can be exported from AMI and imported into GIS where the data is maintained and improved over time.

With GIS being the source of location information, typically the GIS will be the system of record for the Connectivity Model: the relationship between meters and transformers, and transformers and feeders.  As with the location of meters, in the early stages of the data management strategy, the CIS may be considered as the source for the connectivity model; however, ODS systems should be considered the business intelligence system for utilities that have not already purchased software for this purpose.  Optimization of the investment in the ODS can include adding business logic to assist in further optimizing other utility-owned systems.  If the Connectivity Model can be provided by the GIS to the ODS, the business logic in the ODS can be used to streamline outage management through upstream tracing.  This "intelligence" is normally found in GIS systems, or this might be implemented through an OMS.  If the utility owns an OMS, some of the GIS processes cited within this document would simply be replaced by referencing the OMS system.

To a large degree, the utility has optimized their AMI network.  While this document does make reference to thresholds, which by their very nature imply configurability, the effectiveness of this process is clearly improved through receipt of higher percentages of events.

Service Order integration is in place between the ODS and the CIS (or alternate source of service order and work order systems).  To fully optimize the workflow between systems, service order integration using a real time interface should be implemented.  Where the workflow is not in real time, changes to this process around timing will need to be considered.

Processes:

1. Outage Notification

A critical step in the Outage Management Project is to start using MultiSpeak from the AMI CMEP so that the utility can receive Power Fail flags in real time.  CMEP stands for the California Metering Exchange Protocol and is used for transmitting utility metering, billing and administrative information between multiple service providers (MSP’s) such as SENSUS, and utilities The MultiSpeak specification is an industry-wide standard for enterprise application interoperability.  (This standard helps vendors and utilities develop interfaces so that software products from different suppliers can interoperate without requiring the development of extensive custom interfaces.)

Outage notification from the AMI provider happens in multiple formats:

Real-time event data available via the MultiSpeak interface.  Real-time information is considered most valuable in the optimization of outage and restoration processes.  However, the second method of outage recording may be considered.

CMEP file delivery with data quality indicators.  The CMEP file is delivered daily (5:00 a.m.) with consumption information.  Consumption information does contain data quality indicators that can reference outage information.  Typically these data quality indicators are used to validate of consumption information rather than optimize of outage processes due to the timing implications of a batch file process. However, it may be of interest to have the ODS compare real-time information to CMEP data quality indicators.  Testing has revealed that the information can differ.  If the two streams of data are used together there may be the possibility of enhancing VEE algorithms.

1.1. Meter Loses Power

The process assumes power is lost at one or more meters.  Outage duration can vary, and outage size can vary from single homes (i.e. nested outages) to mass outages involving many homes, transformers (Tx) and feeders.  This process documents logic to accommodate all scenarios.

1.2. Outage Exceeds Power Fail Threshold?

When a meter loses power for less than a configured number of seconds, it is considered a "click" or momentary outage rather than an outage.  This threshold needs to be defined, and the meters will need to be configured accordingly. In this way, the utility can track trends to determine, for example, if tree trimming is required.   Clicks will be maintained in the ODS, but should not be automatically transferred to the GIS. 

1.3. Outage Notification from Meter

The transmission and receipt of transmission are referenced individually to remind the reader that with RF systems, 100% of all transmissions are not received.  All processes utilizing RF transmission must consider that messages may not be received. 

1.4. RNI Receives Power Fail Notification

As messages are received over the air into the TGB, they flow through to the RNI. 

1.5. Parse Message - Into Database and Exposed to MultiSpeak

When received by the RNI, they are parsed and the data is simultaneously exposed to MultiSpeak and stored in the database.

1.6. Listens for MultiSpeak Power Fail Events

When events are exposed to the MultiSpeak interface, it becomes possible for downstream systems to "listen" or "subscribe" to message types.  In this case the ODS would subscribe to outage notification events/messages.

1.7. Rule - Verify if Outage is due to LDC work

Ensure that this is only Power Fail flag - not a Tamper Alert followed by Power Fail.  The ODS should also query the CIS data to confirm if there is an open service order for this meter location which would indicate that this is an expected Tamper Alert and Power Fail. 

1.8. Outage Mapping Using GIS?

The ODS can provide a mapping solution. The OMS and/or GIS solutions can also provide views to illustrate the meters which have lost power.  Depending on the size of the outage, the view may change from a meter level view to a Tx level view.  This visualization can assist Operations and CSRs in providing better responses to customer inquiries regarding outage calls.

If a single meter is in a rural area, where this is only one or limited number of meters off the same transformer, there may not be other meters to ping.  Therefore, create a visual point so that transformers to switch relationships can be built and then other meters can be pinged.   

1.9. Analyze Connectivity Model

A key factor is that the ODS requires the connectivity model (meter-to-transformer relationship).  When outages are reported, they will flow in real time to the ODS.  As it is unlikely that all meter transmissions, particularly in larger outages, will be successfully received by the RNI, the ODS needs logic to take the meter outage messages and associate these meters with transformers.  The utility can then conclude which transformers have lost power.   A threshold of meter messages needs to be defined to make the determination that a transformer has lost power.  For example, the utility will not conclude that a transformer has lost power if only one out of ten meter messages are received for a given transformer, but can reasonably conclude than a transformer has lost power if eight of ten meters under the same transformer have lost power.

The GIS is assumed to be the System of Record (SOR) for the connectivity model.  Therefore a Sync process must be defined between the GIS and the ODS.  It is therefore imperative that all meters are connected to a transformer in the GIS.

 

1.10. Ping Meters

Meters can be sent a ping (i.e. On Demand Read) via the two-way engine to determine power status.  Ping messages will return instantaneous readings.  If single meter is in rural area, where this is only one or limited number of meters off the same transformer, there may not be other meters to ping.  Create the switch as a virtual point so that you can then ping the meters off of other transformers on the same switch? 

1.11. Transformer Outage?

Outages are of two types: single (nested) outages or outages to multiple customers.  When multiple customers are affected, the process is the same; it just becomes a question of scale.

1.12. Assume Tx out; Report

Based on utility determined business logic, the ODS can use algorithms to make educated assumptions about the power status of Transformers and/or Feeders based on the understanding of the connectivity model (synchronized from the appropriate System of Record). 

This output can also be to send an email alert to staff that ## of transformers with ## of customers are out.  It should include listing of transformers or a list of individual meters (if not transformer related). 

1.13. Outage Events Exported from ODS

Interface requirement - Report (or file) to be exported from the ODS to the GIS. 

1.14. Update Mapping Solution of Expected Tx Outages

Interface requirement - GIS will need to receive the ODS export and display results in mapping solution. 

1.15. User Analysis and Upstream Tracing

Interface requirement - The GIS will contain logic, and therefore be able to better determine the originating location of outages based on the connectivity model.

1.16. If Single Outage, Assign Service Orders

A single outage might result in a ping to other meters under the same Tx. If confirmation is received that the outage is small, this might result in some output.

Don't always have to dispatch a Line truck - could dispatch a Service truck for investigation.  Person in Ops should verify situation first before assigning Service Order.

This output could take the form of one of the following:

Report

Text message

Service order

Work order

Twitter message

1.17. Create Service Order for Nested Outage(s)

Single outages may require a service order for investigation/restoration.  If service orders are not the output, the process is easily modified to accommodate the desired result.

1.18. MultiSpeak Request to Meters for Power Status

Once the threshold of meter messages is reached, the ODS can initiate a ping process to other meters associated with the same transformer to help determine whether it is the transformer that has lost power. 

1.19. Outage Events Exported from ODS

Interface requirement - Report (or file) to be exported from the ODS to the GIS. 

1.20. Mapping Solution Updated

The format of the source, and whether the view would change based on thresholds/outage extent, will need to be determined.

1.21. Log and Close Event

ODS to automatically log that outage was ignored due to utility work at premise and close event. 

1.22. "Click" Recorded; No Outage

Momentary outages are recorded by the ODS for reporting purposes, but should not trigger outage processes.

1.23. RNI receives Click count event

1.24. Parse Message - Into Database and Exposed to MultiSpeak

As messages are received over the air into the TGB, they flow through to the RNI.  When received by the RNI, they are parsed and the data is simultaneously exposed to MultiSpeak and stored in the database.

1.25. ODS Listens for MultiSpeak Click Events

Momentary outages are recorded by the ODS for reporting purposes, but should not trigger outage processes.

1.26. Maintain Click Count; Report

A report might be created that is analyzed on a monthly, quarterly, or annual basis for such functions as tree trimming.  The ODS needs to be able to export a running total of click counts to the GIS (a 365 day report will be run monthly with 30 day, 60 day and 90 days slices).  It needs to be determined how this export takes place (i.e., define the interface or import format).  One option is to have ODS send an email that can be read by GIS as an event.

1.27. Has reached Click count threshold?

Utility parameter:  If more than 4 momentary outages (clicks) in one month, provide alert to utility staff to investigate.  This should be a parameter that can be configured for each LDC.

1.28. Events Export from ODS

1.29. Import Events

For those transformers that have lost power, this data will be provided to the GIS.  Therefore, an interface will need to be developed between the ODS and the GIS. 

1.30. User Analysis of Events

LDC Operations will need to analyze and determine required action for exceeding the Click Count threshold. 

1.31. Alert to LDC staff

Service orders created for service investigations or work order development for tree-trimming programs.

2. Upstream Tracing

Upstream Tracing occurs based on the connectivity model within GIS and the same connectivity model that has been synchronized with ODS.  ODS determines the transformers that have lost power, and the GIS uses this list to determine the location of the outage.

2.1. GIS Algorithm Determines Source of Outage

The GIS, based on mapping and intelligence, performs upstream tracing to determine where the outages are located. Research will be performed to find the best way to implement the existing GIS functionality for automating tracing functions.  

Once the outage locations are defined, this information is provided to the Operations Department to resolve the problems.  The utility will need to define the format of this transformer outage list, as well as decide which fields should appear on the report (for example, the report could be defined to list transformers and street names but not customer names).  This report will also be used by the Customer Service Department to streamline call centre activities related to outages.

Based on the outage information gathered, the utility can decide to use their IVR system to dial out to homes to acknowledge that an outage has taken place.  This information will also be posted on Twitter.  The utility needs to develop logic for IVR technology, for example, to determine which customers to call in the event of an outage.  The format of the IVR feed will also need to be defined.

 

3. Field Work Requirements

Service order integration is assumed for this process; however this project is separate with different possible levels of integration.  Again, real-time integration between systems will allow the greatest extent of integration.

3.1. Work Order Created as Req’d 

LDC should identify what system (or manual process) where work orders are created. 

We have referenced work order and service order systems in this process.  It may be unique to the utility which system is used for what level of work.  This would be made specific during business process modifications.

For nested outages, service orders should be created for investigation (since the outage is evidently not a transformer issue).  Therefore, an interface is required between the CIS and the ODS so that the ODS can create service orders for transfer to the CIS. Text messaging is another option for sending service order data to crews in the field.

Other things that we need to incorporate into this document

Define interface and costs for transferring information between the ODS and GIS (Batch or Real Time).

GIS → ODS (connectivity model, asset attributes)

ODS/RNI → GIS (events)

Determine if there is a way to automate some GIS functions for up stream tracing.

Define logic for IVR technology that determines which customers to call.

Define two way Interface with IVR feed

IVR → ODS to trigger outage rules.

ODS → IVR to trigger calls to customers or provide message of known outage from calls.

Define format and fields for transformer outage report.

Develop interface between the CIS and ODS for service orders for outages.

Determine if text messaging will be used to send service order data to crews in the field.

Automated Reporting of Key Performance Indicators

SAIDI (System Average Interruption Duration Index)

SAIFI (System Average Interruption Frequency Index)

CAIDI (Customer Average Interruption Duration Index)

CAIFI (Customer Average Interruption Frequency Index)

Model outlines meter-to-transformer relationships.

When outages are reported, they will flow in real time to the ODS.

Unlikely that all meter transmissions, particularly in larger outages, will be successfully received by the RNI, logic required to associate meters to transformers.

Utility can then conclude which transformers have lost power.

A threshold of meter messages needs to be defined to make the determination that a transformer has lost power.

For those transformers that have lost power, this data can be provided to the GIS.

The GIS, based on mapping and intelligence, performs upstream tracing to determine where the outages are located.

Once outage locations are defined, information is provided to the Operations Department to resolve the problems.

Utility will need to define the format of this transformer outage list as well as decide which fields should appear on the report.

Report will also be used by Customer Service to streamline call centre activities related to outages.

Utility can use their IVR system as another data source to to dial out to homes to acknowledge that an outage has taken place.

Utility can use their IVR system to dial out to homes to acknowledge that an outage has taken place.

Information can also be posted on Twitter.

Require development of logic for IVR technology, for example, to determine which customers to call in the event of an outage.

The format of the IVR feed will also need to be define

Service Order interface will allow filtering on outage causes by utility staff (i.e. meter change, disconnect for non payment)

For nested outages, service orders should be created for investigation (investagation may need to generate work orders if the outage is a transformer issue).

An interface is required between the CIS and the ODS so that the ODS can create service orders for transfer to the CIS.

Text messaging is another option for sending outage information to crews in the field.

Implement MultiSpeak from Sensus to transmit restoration flags from the AMI.

Define connectivity model in the ODS.

Define logic in ODS to determine which premises have not been restored.

Develop interface between ODS and GIS for outage information.

Define threshold for number of pings to meters required for creation of service order.

Develop interface between the CIS and ODS for service orders for restorations.

Determine if text messaging will be used to send service order data to crews in the field.

Confirm restoration flag logic is correct in the Sensus meters.

Utility can determine whether power is returned to all customers immediately, even before the crew leaves the field.

Logic is required in the ODS to determine which homes have not been restored and then ‘ping’ these meters though the MultiSpeak interface.

‘Pings’ add message traffic to the AMI system.

Once a defined threshold is reached, a service order should be created for investigation and restoration.

Service orders can be created for nested outages.

Text messaging is another option for sending service order data to crews in the field.