Smart Grid Integration Framework

The Smart Grid Integration Framework integrates with AMI in order to allow Responder to process meter events. AMI receives messages from the meters, then passes the messages to the Smart Grid Integration Framework using a CIM-based interface. The Smart Grid Integration Framework uses services, web services and pipeline rules to filter and process messages. The Smart Grid Integration Framework diagram shows the entire framework and how it interacts with Responder. Individual portions of this framework are discussed in more detail below. Because of its size, the entire Smart Grid Integration Framework diagram is on a separate page:

Smart Grid Integration Framework Diagram

The meters in the field send messages to AMI. AMI communicates those messages in a CIM format to the Event Receiver (Miner.Smartgrid.EventService web service). The Event Receiver filters out any garbled or invalid messages and sends all valid messages to the Event Queue (MSMQ) where they are stored before processing by the Event Processor windows service.

As part of the Event Processor, the Event Dispatcher pulls messages from the Event Queue for processing. The Event Dispatcher then passes the messages (events) to the Event Processor pipelines to filter out or process specific types of messages. The Event Dispatcher uses the pipelines to ultimately persist events to a state data store.

The Event Processor uses multiple pipelines to more efficiently process AMI events. The following filters and rules make up each pipeline:

RemoteConnectDisconnect: This rule filters out all events that are meter disconnects or reconnects for billing reasons (e.g., a customer's power is disconnected after they fail to pay their bill). The event is flagged and an update is made to the customer's connection status in the Responder customer table.
QueryDatastoreFilter: This filter removes any duplicate events and any that are out of order (it keeps the most recent event and removes the earlier ones). The filter sends a message to the Event log for each event it filters out. It also filters out any momentary events. The length of a momentary is defined by the MomentaryFilterTimespan setting. This can be set using the Configuration Manager.
PersistEventFilter: This pipeline rule does not filter any messages. It writes the remaining messages (those that weren't filtered out earlier) to the state data store (Oracle).

Once messages arrive in the state data store the Smart Grid Integration Framework uses database triggers to map the meter events to GIS features in the geodatabase, which may be used to display AMI events. Database triggers maintain accurate data in the AMI Events feature class from the AMI_Snapshot and MapTable tables to ensure that ArcMap reflects the current status of the meter.

Next, the PostEventProcessor queries the state data store (Oracle) for new events. The PostEventProcessor's PostEventDispatcher component queries the state data store at set intervals and pulls all unrestored power down and unrestored partial power events that have waited the pre-determined (via configuration) amount of time. A second query pulls power down and partial power events that were restored by Responder but not by AMI after these events have been held a pre-determined (via configuration) amount of time.

The latter query is used to handle nested outages or incorrect Responder restorations. This query could introduce a never-ending loop if Responder restores incidents that never get restored by AMI because of delayed or dropped messages. For those cases, a reprocessing count for restored events can be set (via configuration) and is used to limit the number of times a reprocessed restoration event can be flagged as "stewed." Ultimately, the queried events are sent through the PostEventProcessor pipeline.

SubmitPartialPowerEventPipe: Submits any partial power events to Responder. If an event results in an incident that is downstream of another incident, it is rolled to the upstream incident.
StewedEvent: The StewedEvent Pipe updates the duration of AMI events in the state data store to "stewed" so that they can be queried by Prediction Services for processing. "Stewed" indicates that the event has been held in the state data store for the appropriate amount of time.

In order to optimize performance, Responder uses the Enhanced Prediction Engine to process AMI events. Enhanced Prediction holds events for a configurable amount of time (sometimes called "stew" time). In the Prediction Services configuration file, the value determines how long an event is held before processing.