Device Events

Publishing Events

SGG can be configured to publish device events for use in Oracle DataRaker or other external systems. This functionality is supported through a combination of OSB components and BPEL composites.

Enabling Device Event Publishing

<publishServices>
  <service>[publisherBusinessService]</service>
</publishServices>

The following components provided with the SGG-D3-EVENT-CM OSB project are used in publishing device events data to Oracle DataRaker:

• The DataRakerBusinessService business service is used to send data to a pre-configured JMS queue (defined as an Endpoint URI), from which the data will be published. This is the business service that should be specified in the EnvironmentSettings.xq file.

• The DataRakerServiceAccount service account is used to define and maintain the user name and password needed to access the JMS queue defined in the DataRakerBusinessService business service.

Configuring Device Event Publishing Output

The SGGDRIntegration BPEL composite handles publishing the data to Oracle DataRaker or other systems. Device event data is published in the “native” device event data format (the format of the device event seeder business object). This format includes normalized device event codes. See the Oracle Utilities Smart Grid Gateway Adapter Development Kit Administrative User Guide for more details about this format.

The following parameters can be used to configure details of how the data is provided to Oracle DataRaker, including the directory where files are posted for Oracle DataRaker to consume, number of records per file, polling frequency, etc. These parameters are defined during installation. See the Oracle Utilities Smart Grid Gateway Installation Guide for more details about defining values for these parameters.

Filtering Events

<filterEvents>true</filterEvents>

When filtering is enabled, only device events whose <externalEventName> matches one of the values defined in the Landis+Gyr Device Event Mapping extendable lookup (D3-DeviceEventMappingLookup) are passed into the system for processing.

Subscribing to Real-Time Device Events

The Landis+Gyr Command Center provides the ability to "subscribe" to device events from within their online interface. This is done by creating a subscriber in Command Center with an associated callback URL as well as a list of events types that subscriber is interested to receive. When an event that is subscribed to occurs it is sent to the callback URL in real time.

Within L+G Events are configured with one of three "alarm" settings. These settings determine how often the events will be sent to subscribers:

1. Alarm: immediately delivered from the meter

2. Advisory: sent based upon a delivery schedule

3. Log Only: sent only upon request (not applicable for our implementation real time event processing)

Command Center will communicate the events using a CIM format that describes the message as a noun/verb combination. The details of the event itself will be contained within a "payload" element of the standard structure. The payload will be formatted using the EndDeviceEvent message structure. This message identifies device events using a CIM 4-part category number. These numbers are four period separated numbers that will describe the type of device and the event. For example: 3.33.1.257 is for "Tamper attempt suspected".

• Segment 1: End Device event domain code (e.g. 3. meter/10. collector/11. router/12. HAN device)

• Segment 2: End Device Event Domain Part Codes (e.g. 1. Access/2. Battery)

• Segment 3: End Device Event Type Codes (e.g. 1. Alarm/2. Alarm Mgt)

• Segment 4: End Device Event Index (e.g. 1. Abort/2. Access Attempt)

Refer to the Landis+Gyr documentation for details about the CIM Category Numbers. CIM Category Numbers must be mapped to standard device event names using the Landis+Gyr Device Event Mapping extendable lookup.

SGG receives these messages through a BPEL composite that saves the incoming request as a file to be picked up by OSB.

The AMIEventSubscriber composite is responsible for receiving the event messages based on subscriptions defined in the L+G Command Center. The callback URL configured for the subscription in the Command Center should point to this BPEL composite.

The following OSB projects parse individual device events from the message and perform the validation and mapping of the information to the Device Event Seeder Format.

1. SGG-D3-CIM-EVENT-BASE contains components responsible for "actual" processing of incoming data. It can be upgraded in future without affecting the customization and environment settings that done in SGG-D3-CIM-EVENT-CM project.

2. SGG-D3-CIM-EVENT-CM allows the customization and simplifies the future upgrades.

The runtime configuration settings for the SGG-D3-CIM-EVENT-CM project are stored in the EnvironmentSettings.xq XQuery file. You can use this file to adjust device event data processing. For example, if you want to load raw data you would specify “true” for the content of the populateRaw element.

The following table describes the elements included in the EnvironmentSettings.xq file:

Processing statistics are gathered for any real time events that are received (even if there is just one event in the message) in the same manner as device events received via the flat-file interface.

Prioritized Device Event Processing

The SGG adapter prioritizes processing of device events created from smart meter commands and/or completion events by setting the Execution Method flag in these types of device events to “Real Time” (D1RT). In addition, device events received with the Execution Method flag set to “Real Time” will be processed in real time rather than via batch processing. See Device Event Prioritization in the Oracle Utilities Meter Data Management / Smart Grid Gateway Business User Guide for more information.

Configuring Payload Processing Notifications

By default, Payload Statistics, Payload Error Notification, and Payload Summary notification activities are sent to the Notification Queue within Oracle Service Bus. Smart Grid Gateway adapters can be configured to restrict sending these activities by defining optional JCA transport dynamic properties in the appropriate OSB project. The following optional JCA transport dynamic properties can used to control if these notification activities are sent:

• SGG_​SEND_​STATISTICS: Controls sending Payload Statistic activities (true: send, false: do not send)
• SGG_​SEND_​ERROR: Controls sending Payload Error Notification activities (true: send, false: do not send)
• SGG_​SEND_​SUMMARY: Controls sending Payload Summary activities (true: send, false: do not send)

When these properties are set to false, the corresponding payload notification will not be sent to the JMS Queue. Note these properties are not populated by default, and default to true if omitted.

To create these properties:

1. Navigate to the SGG-D3-CIM-EVENT-CM project in the Oracle Service Bus Console.

2. Expand the Proxy Services folder.

3. Select the InboundProxyService proxy service (not the Pipeline or WSDL).

4. Click Create to create a new session.

5. Select Transport Details.

6. Click the plus sign in the Dyanmic EndPoint Properties section. An empty row will appear.

7. Enter the property you wish to define in the Property column.

8. Enter "false" in the value colulmn.

9. Repeat steps 6-8 for each property you wish to define.

10. Click Activate to save and activate your changes.