Previously we published an article on OMS integration using MultiSpeak. Since then we have added two additional projects to our portfolio that used two additional MultiSpeak messages.

ODEventNotification

Using this message, we are able to accept “customer calls” to ingest into the OMS. This is accomplished using the ODEventNotificationRequest object as input. The details are pretty simple, as all we needed were the customer account number, the outage reason code, and any additional customer comments.

The origination of this message actually came from a web-based customer portal provided by another vendor. Additionally, we identify the message origin by a configured value in the web service. This allows the operators to know where the call came from, if needed.

The customer decided to use special cause and trouble codes that were stored in the OMS configuration for this project. Because of this, the web service used a mapping in the website configuration that allowed the values to be updated at any time without code changes.

Snippet of an example message:

SCADAStatusChangedNotification

This message allows a SCADA system to notify the OMS of a device’s status. The key item in the SCADAStatusChangedNotificationRequest is the objectID of the device. In the OMS used, Schneider Electric’s Responder™, the required pieces of information from the GIS are both the feature class id and the object id of the device.

Fortunately, this information was stored in the SCADA system thanks to the OMS export that occurs.  In the case of an abnormal status, the integration point notifies the OMS to create an incident for the device.

When the status of the device is normal, and there is an incident defined in the OMS, the OMS is notified that the incident should be cleared.

Snippet of an example message:

In this example, the objectID is a composed of both the feature class id (45) and the object id (100). The interface code splits this out and passes it to the OMS in the respective fields. For the status of “Open” we first check to see if the device already has an incident assigned to it. If it is not, we submit a “device incident” to the OMS.

For the status of “Closed” we first check to see if the device already has an incident attached to it. If it does, then the the status of the incident is set to “Restored”. This is a pretty simplistic example of how to implement this call for this customer. Other SCADA and/or OMS systems may behave differently.

Need More Info?

Feel free to contact us for more information about these solutions, or if you are going to the Esri GeoConX 2016 conference in Phoenix, check out the presentations with CoServ and Connexus about how they used MultiSpeak with their Responder™ OMS.