IOP Status Report CIMug Meeting Margaret Goodrich, SISCO Inc Charlotte, NC November 11, 2009

1. IOP Status Report CIMug Meeting Margaret Goodrich, SISCO IncCharlotte, NCNovember 11, 2009

2. General Topics • Dynamics Project IOP • CDPSM IOP • Part 9 IOP

3. Dynamics Project IOP • Project Introduction • Test Participants • Test Contents • Use of Profiles • Test Witnesses and Logistics

4. Dynamics Project Introduction • EPRI Sponsored Project • Terry Saxton and Margaret Goodrich are Co-Directors of the Project • Project participants include Vendors and Utilities • Goal is to define and validate extensions to CIM for Dynamic Model Exchange and Dynamic Studies. • The Dynamics and Static model Profiles must contain sufficient information to allow Dynamic Study Analysis to be performed.

5. Dynamics Project Introduction • Project includes: • Definition of new UML modeling methods • Definition of the CIM Extensions for Standard Dynamic Models • Definition of User Defined Dynamic Models • Planning and Execution of an IOP test to Validate the extensions

6. Dynamics IOP Test Participants (Products) • DigSilent (PowerFactory) • GE Energy (PSLF) • RTE/Tractebel (Eurostag) • Siemens PTI (PSS/E)

7. Dynamics IOP Test Contents • Full Model Exchange of Static Model (import and export) • Power Flow Solutions • Interoperation of full test models between two or more vendors • Exchange of Solution Files • Exchange of Dynamic Profiles • Dynamics Studies

8. Dynamics IOP Test Contents – Model Exchange

9. Dynamics IOP Test Contents – Solution Exchange

10. Dynamics IOP – Use of Profiles • IOP will use 4 Profiles • Equipment • Topology • State Variables • Dynamics for both Standard and User Defined Models • Equipment, Topology and State Variables Profiles will be the same as was used in the UCTE IOP last March.

11. Dynamics IOP – UCTE Profiles

12. Dynamics IOP – Test Witnesses and Logistics • Test Witnesses • David Bogen, Oncor • Pamela McClean, AESO • Chavdar Ivanov, ENTSO-E • Margaret Goodrich, SISCO • Logistics • Location – EPRI Offices, Dallas, TX • Dates – Nov. 16 through Nov. 19

13. Part 13 CDPSM IOP • Participants • Profiles Used • Tests Contents • Test Witnesses • Logistics

14. CDPSM IOP Test Participants EDF GE EPRI (OpenDSS) by Tom McDermott Current Group (by Rod Frowd) SISCO

15. CDPSM IOP Profiles Three Profiles – All Full Model Single Profile Documents CDPSM for Balanced Network Model CDPSM for Unbalanced Network Model GIS Connectivity Network Model

16. CDPSM IOP Test Contents Tests Include: Full Model Exchange between two DMS systems Full Model Exchange from a GIS System to a DMS Interoperation of full test models between two or more vendors Incremental Model Exchange between two DMS systems Incremental Model Exchange between a GIS and a DMS Power Flow Solution for Balanced and Unbalanced Network Models.

17. CDPSM IOP Test Contents Data Exchange Test Cases – GIS Focus 61968-13 – CDPSM exchange, GIS focus in 2009

18. CDPSM IOP Test Contents Data Exchange Test Cases – DMS Model Exchange Focus Exchange of CDPSM* (similar to today’s CPSM inter-op tests) *Common Distribution Power System Model (CDPSM) – IEC 61968-13 standard

19. CDPSM IOP Test Witnesses & Logistics Test Witnesses David Bogen, Oncor Margaret Goodrich, SISCO Logistics Location – Oncor, Dallas, TX Dates – Nov. 30 through Dec. 3rd

20. Part 9 IOP • Introduction • Testing Infrastructure Overview • Test Participants • Test Contents • Test Issues • Controls and Events • Metering Systems • Asynchronous Replies • Enumerations • Test Witness GUI Slides • Test Schedule

21. Introduction Test is Sponsored by EPRI Scott Neumann and Margaret Goodrich are Co-Directors First IOP for WG14 First Messaging Test First Test using ESB First Test Remotely

22. 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 Slide Courtesy of UISOL

23. Test Participants Ecologic EDF Elster GE Grid Net Itron L&G Telvent

24. Test Contents - Messages MeterReading EndDeviceEvents EndDeviceControls EndDeviceAssets CustomerMeterDataSet MeterReadSchedule

25. Test Contents

26. Controls and Events Slide Courtesy of UISOL

27. 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 Slide Courtesy of UISOL

28. Metering Systems Slide Courtesy of UISOL

29. Metering Systems 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’ Slide Courtesy of UISOL

30. Asynchronous Replies Slide Courtesy of UISOL

31. 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 Slide Courtesy of UISOL

32. More on Asynchronous Replies 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 Slide Courtesy of UISOL

33. Reading Types 61968-9 Annex C Needed for MeterReadings message Populated as the value for the ‘ref’ attribute in ReadingType structure Population of the ReadingTypes list in the MeterReadings structure is optional Slide Courtesy of UISOL

34. Quality Codes 61968-9 Annex D Used to populate ‘quality’ element in ReadingQualities structure Readings are assumed to be valid unless reading quality is specified Slide Courtesy of UISOL

35. Event Types 61968-9 Annex E Used to populate ‘category’ of EndDeviceEvent structure Important not to confuse event codes with reply codes Slide Courtesy of UISOL

36. Control Types 61968-9 Annex F Used to populate ‘type’ in EndDeviceControl structure Slide Courtesy of UISOL

37. Test Witness GUI Slides 37 Slide Courtesy of UISOL

38. Test Witness GUI Slides 38 Slide Courtesy of UISOL

39. Test Witness GUI Slides Slide Courtesy of UISOL

40. Test Schedule All Connectivity testing between Vendor and ESB by November Dry Run Test – Dec. 15-16, 2009 Actual Test – Jan 5-6, 2010

41. ?????? Questions