Date post: | 30-Mar-2015 |
Category: |
Documents |
Upload: | aliya-walpole |
View: | 223 times |
Download: | 4 times |
SG Systems - Service Definition Team
Chair: Gerald Gray, CIMple [email protected]: Shawn Hu, Xtensible [email protected]
Introduction• Why Service Definitions?
– Best Practice CIM implementation– “The CIM is neat but…”
• The service definition process (high level view)• IEC CIM alignment• Future Plans
You Are Here
You are here
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• Posting• Issue generation and resolution• Versioning
Logical Model Input• IEC 61989-9 and Multispeak
are the primary model inputs• AMI-ENT: use case
contributions from SCE, Consumers Energy
• Open AMI-ENT, OpenADE 1.0• On-going: OpenADR 1.0,
OpenHAN 2.0, etc
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
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
Notification• Subscribe to the Listserv
– http://listserv.enernex.com/cgi/wa.exe
• Send listserv e-mail– [email protected]
• 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• Current 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…
Thank you!