1. Interoperability Test Message Patterns for IEC 61968-9
Scott Neumann
September 14, 2009

2. Introduction
The purpose of this presentation is to describe messaging patterns to be potentially used for interoperability tests for IEC
This is intended to supplement the EPRI technical report
Important to note that messaging between metering systems and end devices is outside the scope of this InterOp
This document is currently a draft, where comments from metering vendors as a consequence of the 9/1/2009 call are pending

3. Testing Infrastructure Overview
UISOL test bus is based upon EPRI TR and IEC
Participant products remotely connect to bus using internet as clients, servers and/or listeners
Test witnesses monitor tests using web browser

4. Controls and Events

5. Controls and Events
Client process issues request to MS as ‘create EndDeviceControls’, where each EndDeviceControl has a unique mRID (using a GUID)
MS replies to client synchronous, as ‘reply EndDeviceControls’
Event published ‘created EndDeviceControls’ to notify potentially interested clients that a control has been requested or scheduled
MS processes control request issuing messages to end devices as needed (the messaging and processing sequences here are outside the scope of )
Consequences of controls may be reported to metering system from end devices
Events published ‘created EndDeviceEvents’ to notify potentially interested clients, where if possible, the mRID for each EndDeviceEvent should use the mRID from the corresponding EndDeviceControl

6. Metering System

7. Metering System Meter readings are collected by metering system
Metering system publishes messages using ‘created MeterReadings’ to potentially interested clients
Some of the information collected from meters may be events, or may cause events to be inferenced and reported using ‘created EndDeviceEvents’

8. Asynchronous Replies

9. Asynchronous Replies
Client (e.g. MDM) may request meter readings from metering system using ‘get MeterReadings’
Metering system replies to client synchronously using ‘reply MeterReadings’ with whatever data is available that is relevant to the request if it chooses
Meters may later return the desired data to metering system
Metering system replies asynchronously to client using ‘reply MeterReadings’ to specified reply topic/queue and correlation ID used on initial request
Metering system may also publish data using ‘created MeterReadings’ to any potentially interested client

10. More on Asynchronous Replies
Both client and server must support
Client responsibilities:
CorrelationID in header must be used to allow client to correlate multiple replies to an initial request
AsyncReplyFlag in header should be set to true
ReplyAddress should identify topic/queue to be used for asynchronous replies
Server responsibilities:
Server (e.g. metering system) must be will to dedicate a thread or process to process the request asynchronously
Server must send replies to the designated destination with the appropriate correlationID as initially supplied by the client
All but last reply should use ‘PARTIAL’ for the ReplyCode
Last reply should use ‘OK’ for the ReplyCode
Need to decide if asynchronous replies will be fully supported for the InterOp tests

11. Another Possible Approach

12. Details
Asynchronous relies are handled through get/reply pairs that are tied together via the correlation ID
Client polls for subsequent payloads
Provides an approach that is better supported using web services
Is easier to test, as bus does not need to track state

13. More Information UISOL web site: http://uisol.com
EPRI Technical Report: ESB Implementation Profile Using IEC 61968