1

I will state that what I’m showing today is just a brief snapshot of what the new system is capable of.  It can do a lot and to cover everything would take a couple of hours.  

2

3

We’ve been using GIS in our control center since 2002 and it has become indispensable to daily operations. It shows the location of our facilities, which participate in a geometric network.

Our control center is manned 24/7 365 to handle all situations that arise with the LES power grid. This includes transferring load around the system and handling outage calls from our hotline.

The hotline data was managed via a home-grown program, which resembles an excel spreadsheet. This data does not directly interact with the GIS system. We were able to take the hotline data, though, and geo-code it against the map. This allows us to “manually” predict outages based on where the geocode dots appear.This manual prediction was effective, but it took time to digest the call data and what we were seeing on the map. During major storms, the GIS editors supported the control center by taking over the “triaging” of the outages.

With all the outage and restoration events being tracked manually, assembling the statistics afterwards was quite a chore. Figures had to be checked and double checked before being manually entered into an Access database. For a major storm, the reporting could take a week or two to complete.

Basically, we had a lot of moving parts and systems in play when it comes to outage management.

4

So why did we decide to change things?  They were working, even if they were inefficient.

To put it down to one factor: Smart Grid.

If smart meters were introduced into the LES system, the old practices would not be able to leverage the data provided by Smart Meters in outage events.  To prepare for that possibility, we needed a new outage management system that met five general requirements:

Improve efficiencyTake advantage of technology, new and existingProvide information fasterProvide a web presenceAnd, as mentioned before, support Smart Meters

5

Building on those general requirements, we tailored the business case

Any new system had to provide real time, planned, and historical outage reports

It had to run in our existing ArcGIS environment and take advantage of the investment we’ve already made there

It had to integrate with our SCADA, IVR, and CIS systems.  If you’re not familiar with those acronyms, SCADA stands for Supervisory Control and Data Acquisition and we use it to monitor and operate the most critical parts of our electric grid.  IVR stands for Interactive Voice Responder, which is really just our outage hotline.  CIS is our Customer Information System.

The new system had to provide a methods of company‐wide notification of outages.

It had to provide us real time status of the power grid, geographically and tabularly.

And, as mentioned before, it has to provide the ability to integrate with smart meters

6

We ended up choosing Schneider Electric’s Responder Outage Management System.  If you didn’t know Schneider Electric provided GIS software, it’s because they recently bought one of the largest players in Esri‐based utility GIS software: Telvent.

LES has been a Telvent customer for around 15 years.  We use a wide array of their products, including the ArcFM Solution.  

They were an obvious choice because our GIS system is built around the enhancements they provide an Esri system.  We knew we could leverage our existing data without a conversion project.

Responder provided us with what we were looking for: multiple ways OOTB to engage our data.  It provided more then just outage management; it gave us a way to manage the system in daily operations.  While you might wonder why we would push the scope to include daily ops, daily ops will drastically change how you manage an outage.  You need to understand what the daily ops have done to the grid to know how to tackle an outage.

Responder also was able to accept out outage hotline data, customer information, and outage alerts from our SCADA system with custom built integrators.  Since Telvent has been dealing with Smart Meters for years, Responder will be able to integrate that data if we choose to pursue the technology. 

7

For Responder, we needed to expand our server environment.

Before, we had Oracle database, the SDE server (or ArcServer Basic), and our Arc Web Server (or ArcServer Standard)

Responder required a message router server to handle all the communication traffic and a business server to handle processing all the business logic.  Responder is interesting in the fact that the client PCs do very little work.  All information is fed back to the application server, where Responder completes the processing and then saves the data to the Oracle database directly.  If a client crashes, they haven’t lost anything because the application server is responsible for all data management.  When one client makes an update, all the other clients will simultaneously receive the same update.

The reason you see two of everything up there is because we make everything redundant for high availability.

8

Responder is broken down into four applications:

Responder in ArcMap

Responder Explorer

Responder Archive Explorer

And Responder Web Portal

9

Responder in ArcMap appears as a toolbar within ArcMap itself.  We add layers to our existing map displays to display different aspects of the Responder data tables.  We can display via tables, xy event layers, and table views.  Since it is basically ArcMap, we can apply whatever symbology, labeling, and definition queries we choose.  

When we receive a phone call that a customer is out of power, that information is fed into the Responder server while also being displayed on the map.  Responder will use our geometric network to figure out how this customer is being fed.  The basic rule that Responder follows is that two devices without power that have the same “parent” device will in turn cause the parent device to predict as being out.  In ArcMap, we will see a visual representation of the customers who have called in, what device Responder is predicting is the cause of the outage, and all the other devices that would also be out based on said cause.  I’ll show an example of that in a second.

Since everything is based on the geometric network, we can choose to trace on two options: the normal state of the system (or how the GIS editors drew in and connected the features) or the actual state of the system (or how the Control Center has used Responder to change how the features are connected).  

10

Here you see an example of the predicted outage.  In the left picture, you see we have received one outage call at 9555 Hollow Tree Dr.  In the second picture, it’s a little hard to see, but a second phone call was received from 9543 Hollow Tree Place.  Responder reviewed those two metering points and found that Transformer 94581 was the parent device for both those meters.  Responder then represented the transformer as being without power and the fact that five customers are without power if said transformer is without power.  

Control doesn’t have to accept this as gospel, though.  If they discovered the problem is not the transformer, they have the option to move the source of the problem.  This is just a way to quickly provide a starting point to the dispatcher for investigation.

11

On this slide, the picture on the left shows a larger outage involving numerous customers.  The black dots represent every metering point (or customer) that Responder says is without power.  The thick black line you see represents the electrical cable that is without power.  The green dot you see at the bottom of the picture shows the predicted probable cause of the power outage, in this case a fuse.

The picture on the right is showing a large portion of our service territory and where problems exist or where daily work is occurring in the system.  By just logging into ArcMap, we can instantly see where the abnormal sections of the system are.

12

Moving to the second application of Responder, I will now explain Responder Explorer.

The easiest way to describe Responder Explorer is to say it’s a highly functional version the attribute table.  It gives us a grid view of every incident in the system, color coded by the number of customers involved or the type of incident it is.  

Explorer is completely interactive with ArcMap.  While you can use Responder with just ArcMap or just Responder Explorer, they are meant to be used in conjunction with one another.  In the Explorer, you can create a new incident and then click on a feature in ArcMap to assign that feature to Responder.

The Explorer grid itself allows for multiple filtering, sorting, and customizations.  For example, if you don’t like where a column is displayed in the grid, you can drag and move it on the fly to where you want it.

Explorer will alert you when new incidents are created, it will allow you to assign and track which dispatcher and crews are working an incident, it will allow you to create switching order orders to complete daily operations, and it will allow you to complete steps to restore power.

Responder can also automatically send email or text alerts when large outages occur (right now, set at over 200 customers involved) or when outages occur to critical customers, such as hospitals.

13

The next few slides are just picture examples of a few of the parts of Explorer.

The top picture is a sliver of the grid itself.  You can see it shows us the status of an incident, whether we’ve confirmed the problem or not, and the address of the problem.

The bottom left picture is the alert the dispatcher receives when Responder creates a new incident.

The bottom right picture is Responder enforcing workflow on handling an outage.

14

This a more complete view of the grid.  It you click on the plus signs on each row, you can see more details of an outage.  Such as what features are assigned to an incident, if there are safety hazards associated with the incident.  You can’t see it in the picture, but we can also see a full list of the people affected by an incident.

15

This slide represents the switch order and restoration steps manager.  We can build switching orders for future work, which you can see in the left picture.  To build an order, we have a large list of pre‐built steps that only need a GIS feature assigned to  it.  Based on the GIS feature the dispatcher selects, Responder will automatically add the facility ID and address of the affected feature to the order. 

The slide on the right shows what a dispatcher typically records for restoring power.

16

With a click of a button, you can see what devices you will be affecting on the map.  The left picture shows the locations and full text of each step of a switching order.

The right picture shows a completed restoration order, where we had to perform a power backfeed to restore power.  The pink line shows abnormally backfed power cables.  This is another example of Responder providing us a quick visual of the “actual” state of the power grid.

17

Archive Explorer allows us to data mine closed incidents for reports and statistics.

We weren’t able to import our old outage data, so we don’t have a lot of data to mine at this point.

18

The Responder Web Portal is our internal dashboard to outage data.

We can view the data in geographic, analytical, or tabular views.

If a customer calls our call center directly, the customer service rep can enter their call directly into the Responder system.  They can also look up all the outages a customer has experienced.

19

A few shots of the web portal.

The left view is a heat map of our service territory, showing how many customers are affected in each quadrant.

The right view is an analytical view, where we can see the percentage of customers affected, crew status, and how many incidents we have responded to.

20

This is a shot of the tabular view of the data.  We can see the raw numbers of customers affected for the whole system or broke down into north/south or system quadrants.

21

This final tab shows historical customer data.

We can look up how many calls we’ve previously received from a customer via the outage hotline and how many incidents that customer has been involved with, including how long it took to restore their power and what the cause of the incident was.

Honestly, when you break down all the system is doing, it’s just a giant logging system of times stamps and affected equipment and customers.  It is not operating any equipment in the field nor is it perfect in it’s assessment of all situations.  As with any analysis of GIS data, you have to sit back and ask yourself “Does this make sense?”  It is all dependent on the data in the GIS system and Responder sometimes brings data errors to light.  

22

It took some time, but that does include contract negotiations and such.  And that NEVER goes quickly.

The bulk of the project took place between Sept of 2011 to June 2012.  We almost went live in the summer of 2012, but we discovered a small but crucial piece of functionality that was being released with the 10.1 version of the software.  So we waited until 10.1 was released.

We took advantage of the wait by training the dispatchers on the new system.  They know how to handle outages and daily ops, but now we were cramming all that into one computer system.  It took time to get them acclimated and it’s still a learning curve.  This is a massive change in how they operate.

Officially, we went live with new servers, ArcGIS 10.1 and Responder on April 8th.  As with any new system going live, we’ve had a couple bugs to work through, but things are stable.  The old outage management practices are still in place as we know we weren’t able to test/train on every possible scenario the system could experience.  The biggest benefit we’re already seeing is the fact that, as the dispatchers use Responder in their daily operations, all our reports and statistics are being automatically created and stored.  It doesn’t require data entry into another system.  It’s just there and ready to use.  

23

Right now, we’re watching how Control is using the system.  We know we didn’t get everything, so what are they seeing that we can tweak on?

We plan on enhancing a couple things with daily operations, but we are gathering data now to ensure we understand how/what needs to be added.

The most visible item on the list is to expand to an outage web page.  We’ve never had one before.  Our customers want to see where the outages are at and they want to see it on their phone.  Our hopes is to have one out this fall.

24

25