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

Introduction The purpose of this presentation is to describe messaging patterns to be potentially used for interoperability tests for IEC 61968-9 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

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

Controls and Events

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 61968-9) 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

Metering System

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’

Asynchronous Replies

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

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

Another Possible Approach

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

More Information UISOL web site: http://uisol.com E-mail: sneumann@uisol.com EPRI Technical Report: ESB Implementation Profile Using IEC 61968