sg systems - service definition team chair: gerald gray, guiding principle consulting...

Post on 05-Jan-2016

217 Views

Category:

Documents

1 Downloads

Preview:

Click to see full reader

TRANSCRIPT

SG Systems - Service Definition Team

Chair: Gerald Gray, Guiding Principle Consultinggerald.gray@guiding-principle.comCo-Chair: Shawn Hu, Xtensible Solutionsshu@xtensible.com

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

OpenADE OpenADR OpenHAN

The Process

Use Cases

Business Processes

Integration Requirements

Services

•WSDLs

•XSDs

System Requirements Specification

For more info: http://osgug.ucaiug.org/sgsystems/SDTeam/Implementation%20Projects/Home.aspx

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 61968

• Verb examples: – Create, Created– Send, Reply

• Information Object examples:– EndDeviceAsset– MeterSystemEvent– MeterReading

<IEC Verb><Information Object> 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

– http://listserv.enernex.com/cgi/wa.exe

• Send listserv e-mail– OPENSG-SGSYS-SD@SMARTGRIDLISTSERV.ORG

• Issues with artifacts should be noted on the OpenSG Help Desk site– http://osgug.ucaiug.org/HelpDesk/default.aspx

• Implementation Projects: Service Definition Team Wiki– http://osgug.ucaiug.org/sgsystems/SDTeam/Implementation

%20Projects/Home.aspx

Plans - Feedback• OpenAMI-ENT work was shared with IEC WG14

(Use Cases, Requirements, Artifacts)• Continuing service definition work…

OpenAMIENT ballot

Oct ‘09 Jan ‘10

IEC WG14 Re-factor artifacts

OpenADE 1.0 artifactsREST/SOAP ballot

May ‘10 Jul ‘10

OpenADR 1.0 Artifacts ballot

Nov ‘10

Thank you!

top related