Interoperability Test Message Patterns for IEC 61968-9 Scott Neumann November 24, 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 async reply pattern 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 url/topic/queue to be used for asynchronous replies, using following form: TOPIC: topic:<topic name> QUEUE: queue:<queue name> Web Service : URL that begins with ‘http:’ 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
AsyncReply WS Interface WSDL operation allows a WS-based client to send an asynchronous reply to the ESB The operation is called ‘AsyncReply’ and uses a ‘ResponseMessage’ for BOTH input and output ESB then determines if the target is a web service or a JMS topic based upon the replyAddress element (i.e. if the replyAddress begins with ‘http’ it is forwarded to a web service, otherwise JMS, using a queue: or topic: prefix) Async replies can also be submitted to the ESB using the JMS ‘TESTING.ASYNCREPLIES’ topic, where the ESB will log and then forward to JMS or WS destination A web service client that wants to receive asynchronous replies must also expose a listener for the AsyncReply operation A JMS client that wants to receive asynchronous replies just needs to identify a desired reply topic and then listen on that topic
Another Possible Approach
More Information UISOL web site: http://uisol.com E-mail: sneumann@uisol.com EPRI Technical Report: ESB Implementation Profile Using IEC 61968