Responder Architecture

Responder is an outage management system (OMS) that allows utilities to track incoming calls from customers and create outage incidents in ArcMap. Below is an example of how Responder may work and how the various servers and databases are involved. Responder is highly customizable, so your architecture may be different.

Responder requires the following:

• Responder database

• Geodatabase

• Responder Services (Data Services, Prediction Services, Archive Services)

• Web server

• Client machine

These components can be housed on the same computer or on separate computers. For this example, we'll have them stored on separate computers to more easily demonstrate how they interact.

The Responder Data Services is the component that binds everything together. Data Services communicates with all of the other components. Prediction Services manages prediction and roll-up in Responder Explorer. Both of these are hosted on the Responder server.

The configuration might look like this:

This sample process flow begins with a call from a customer reporting a power outage or some other power problem (e.g., flickering lights).

• A utility operator uses a client machine to connect to the web browser (on the web server) and log the customer's call.

• The web server conveys the information to the Responder server.

• The Responder server uses the information to create an incident in the Responder database (potentially on another server).

• Responder's prediction engine analyzes the existing incidents, and uses data in the geodatabase to perform traces and predict the common device that may be causing the outage. Responder does not edit the geodatabase. The geodatabase is used to perform traces and identify the locations of the features on the map.

• All subsequent modifications to an existing incident are made by the client in the Responder Explorer. The changes are submitted from Responder Explorer to the Responder server. The Responder server then stores the changes in the Responder database.