SG Systems - Service Definition Team Chair: Gerald Gray, Guiding Principle Consulting Co-Chair: Shawn Hu, Xtensible Solutions

You Are Here You are here

Introduction Why Service Definitions? – Best Practice CIM implementation – “The CIM is neat but…” IEC CIM alignment The service definition process (high level view) Future Plans

SDO – User Group Relationship Iterative process Analogy – early browser development OpenSG OpenAMIENT example First pass – IEC CIM draft XSD as informative Now – XSD as normative SDO User Community Thou shalt... Yes and... Feedback

IEC CIM Alignment Consistent –some features of the spec, and in accordance, but also some additional features Compliant – some of spec not implemented, but what is implemented is in accordance Conformant – All features of spec implemented, but some additional features that are not conformant Fully Conformant – full correspondence between the spec and implementation.. - Implementation Irrelevant. Consistent. Compliant. Conformant. Fully Conformant Adapted from TOGAF 9 - Specification

OpenSG - Where We Fit Use Case Team SRS Team Service Definition Team Interoperability Team Security Team Open AMI- ENT OpenADEOpenADROpenHAN

The Process Use Cases Business Processes Integration Requirements Services WSDLs XSDs System Requirements Specification For more info:

The Process Logical model input & development Identification of integration requirements Pattern naming Information objects Artifact generation (XSD, WSDL) Posting Issue generation and resolution

Logical Model Development Standardized actors from AMI-ENT SRS Document business process in use cases and activity diagrams

Identify Integration Requirements Where an object crosses a system boundary

Harmonize Integration Requirements Compare integration requirements and look for commonality: – Common actors – Common consumers – Common providers – Common information objects Eliminate duplicates, refine integration requirements

Patterns – Using CIM Verbs Pattern naming allows for both ESB and non- ESB (point-to-point) architectural assumptions Verbs and Information objects are based IEC Verb examples: – Create, Created – Send, Reply Information Object examples: – EndDeviceAsset – MeterSystemEvent – MeterReading e.g. CreatedMeterReading

Sequence Diagrams Show the services and integration with actors

Crafting Message Payloads Based on requirements identified in the Systems Requirements Specification

Notification Subscribe to the Listserv – Send listserv – Issues with artifacts should be noted on the OpenSG Help Desk site – Implementation Projects: Service Definition Team Wiki – cts/Home.aspx cts/Home.aspx

Plans - Feedback OpenAMI-ENT work was shared with IEC WG14 ( Use Cases, Requirements, Artifacts ) Continuing service definition work… OpenAMIENT ballot Oct ‘09Jan ‘10 IEC WG14Re-factor artifacts OpenADE 1.0 artifacts REST/SOAP ballot May ‘10Jul ‘10 OpenADR 1.0 Artifacts ballot Nov ‘10

Thank you!