1. # 1 Application Integration Architecture A Framework For Standard Interface Development Gerald R. Gray, Consumers EnergyJune 23, 2008

2. # 2 High Level

3. # 3 Moderate Level

4. # 4 Deep Dive

5. # 5 Abstract to Detail Standards Bodies Business Case Conceptual Architecture Use Cases Integration Requirements Sequence Diagram Patterns Services WSDL

6. # 6 Leveraging the Overlap: UCAIug Groups – AMI & CIM CIMug UtilityAMI AMI Enterprise WG Standard Services

7. # 7 Key Collaboration Concept Standard building blocks are defined by CIMug (i.e., IEC working groups) and other relevant industry groups (e.g., Open Architecture Group (OAG), MultiSpeak, OGC) Common industry practices are defined by the user community; the AMI Enterprise WG - by specifying how standard building blocks are used for popular scenarios with the resulting artifacts: –Use cases specify required services –Service definitions (WSDLs) contain the building blocks Artifacts are placed on the Utility AMI SharePoint –Sponsors of work name their directories (could be utility names) –Any utility may reference a common industry practice directory in an RFP. –Popular directories become de facto industry standards

8. # 8 AMI-ENT Security – Zone Defense Home PC OMS 61968-3 Planning & Scheduling 61968-5 MDM Or MDUS 61968-9 Data Collection 61968-9 Control & Configuration 61968-9 Meter Maintenance 61968-9 WMS 61968-6 Network Operations 61968-3 Load Mgmt. 61968-9 CIS 61968-8 GIS 61968-4 Load Control 61968-9 MDM 61968-9 MDUS 61968-9 Open HAN 1.0 Third Parties – Retailers, etc Meter Data & Comm. C12.19 C12.22 Data Collection Systems Utility Systems MDM SystemWide Area Networks Meter- Specific Networks HAN AMI-SEC AMI-COMM ???

9. # 9 Scope

10. # 10 Moving To A Common Language

11. # 11 Requirements Traceability Business Benefits Business Processes Functional Requirements Integration Requirements Services Portfolio Interface Reference Model Application Portfolio Resulting from an activity in a Use Case Scenario Resulting from an flow in a Use Case Scenario Includes application services and common services.

12. # 12 Services Gap Analysis Steps Map system actors to IEC 61968 systems/IRM Identify integration requirements Create common services per integration requirements Model service sequence diagram that includes vendor and legacy services Create services mapping and gap analysis! Review CIM and MultiSpeak services/schemas Identify Application services/schemas Gap analysis Documents

13. # 13 Context – Conceptual Architecture

14. # 14 Use Case – B1.3

15. # 15 Integration Requirements

16. # 16 Operation Naming Patterns Operation Naming Patterns utilizing IEC 61968 verb (Reference #9): _ CREATE CREATED CHANGE CHANGED CANCEL CLOSE DELETE GET CLOSED CANCELED DELETED SHOW REPLY SUBSCRIBE UNSUBSCRIBE

17. # 17 Service Naming Patterns Service Naming Patterns: Send – to provide (send) information (message) for public (enterprise) consumption. Receive – to receive information (message) from an external source. Publish – to provide (send) information (message) for public (enterprise) consumption. Subscribe – to receive information (message) from an external source. Request – to request another party to perform a specific service Reply – to confirm the execution of a service on behalf of the provider, and return specific results. Retrieve – to request information Show – to provide information as the result of a request or unsolicited Execute – to run a service provided to the public

18. # 18 Sequence Diagram

19. # 19 Recommended Services

20. # 20 Services Services provided by MDUS (“Receive” service): –Service: ReceiveMeterSystemEvent.wsdl Operation: CreatedMeterSystemEvent_Receive Operation: ChangedMeterSystemEvent_Receive Operation: CanceledMeterSystemEvent_Receive Services provided by ESB (“Show” service): –Service: ShowMeterSystemEvent.wsdl Operation: CreatedMeterSystemEvent_Show Operation: ChangedMeterSystemEvent_Show Operation: CanceledMeterSystemEvent_Show Services provided by CIS (or any interested systems) (“Receive” service): –Service: ReceiveMeterSystemEvent.wsdl Operation: CreatedMeterSystemEvent_Receive Operation: ChangedMeterSystemEvent_Receive Operation: CanceledMeterSystemEvent_Receive

21. # 21 WSDL (Proof of Concept) <wsdl:definitions name="ReceiveMeterSystemEvent" targetNamespace="http://ce.corp.com/ei/2008/06/ReceiveMeterSystemEvent.wsdl" xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:wsi="http://ws-i.org/schemas/conformanceClaim/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" xmlns:tns="http://ce.corp.com/ei/2008/06/ReceiveMeterSystemEvent.wsdl" xmlns:typeOrig="http://ce.corp.com/ei/2008/06" xmlns:typeIn="http://ce.corp.com/ei/2008/06/MeterSystemEvent" xmlns:typeOut="http://ce.corp.com/ei/2008/06/OutputData.xsd"> A web service to receive MeterSystemEvent

22. # 22 Abstract to Detail Standards Bodies Business Case Conceptual Architecture Use Cases Integration Requirements Patterns Sequence Diagram Services WSDL

23. # 23 Benefits to each Utility As utilities pull in the same direction, de facto standards are created; economies of scale should yield: –Improved vendor response & support –Reduced product procurement costs –Reduced effort for requirements analysis and design –Reduced risk of overlooking requirements That are expensive to retrofit later –Reduced life-cycle costs

24. # 24 Next Steps Issues and/or improvements?