1. Utilization of CIM at Progress Energy with the Smart Grid DSDR Project Top-down approach to Integration Software Development Jon Drew November 12, 2009

2. PGN introduction to CIM and DSDR Overview Applying CIM to project DSDR The top-down integration development process for DSDR POC and Lessons Learned 2 Agenda

3. ●A few attempts at discovery were pursued between 2005 and 2008 ▪Most obvious finding - a lot of confusion as to what the CIM was really supposed to do ●Attended 2007 CIM Users Group ▪Report back to mgmt CIM would be useful in standardizing integrations Not any complete solutions available CIM not mature in Distribution space Still lots of changes in CIM technical space (Rational Rose to EA, etc.) Suggested a training workshop with industry leaders in CIM to educate technical and leadership ●Further action was delayed until…. 3 PGN Introduction to CIM

4. 4 DSDR - How does it work?? Lower Regulatory Limit Upper Regulatory Limit Flattened profile allows greater Voltage Reduction Existing Flattened Profile Lower Voltage to Reduce MWs Coordinate voltage and var control to defer investment in additional generation by providing peak load reduction.

5. DSDR Architecture – Existing DAS Interfaces and Data Flow

6. DSDR Architecture – Final DAS Interfaces and Data Flow (complete)

7. 7 DSDR Interface Potentials DCC Grid Operators Distribution Engineers Energy Control Center Primary Users Primary Business Applications (Business Data & Processes) Primary Interfaces DMS (includes historical data) DMS (includes historical data) DSCADA (includes historical data) DSCADA (includes historical data) Feeder & Substation Devices 1. Data Collection 2. User Views 3. Execution commands 4.Normal Operations 5.Loss Optimization Mode 6.DSDR Mode 7.Study mode (Engineers) Vendor Data Replication Application Interface Framework EMS (TSCADA) CIS AMI/ AMR/ MDM Historical Data Mgt Work Mgt/ Mobile Asset Mgt OMS GIS Note: Red indicates significant DSDR related impacts Passport/ Aspen VMS FMS

8. ●Conducted 2 training workshops with CIM consulting companies ▪Focused on technical aspects of CIM adoption ●Post workshops – decision to pursue targeted implementation of CIM based technology as part of DSDR integration efforts ●Contracted consultant for 6 week engagement to clearly define implementation plans and perform some initial work with the tools and concepts ▪Checkpoint after the 6 weeks – decided to engage consultant for longer term and perform the targeted implementation ▪Created detailed Work Breakdown Structure for the implementation phase Applying CIM to project DSDR

9. ●Project Management ▪WBS ●Governance ▪Processes and procedures ▪Integrate with Existing company standards and guides ▪Implement using the top-down approach to software development ●Infrastructure ▪ESB tool ▪Registry Repository ●SkillSets ▪New tools – Enterprise Architect, XMLSpy, utilities ▪New concepts – UML modeling, web services concepts ●Proof 0f Concept (Pilot) Implementation Components

10. ●Most difficult issue for Project Management is integrating this effort with the requirements of the rest of the project. An extremely aggressive overall project schedule shifts priorities, the integration project has to be flexible and adapt to changing conditions ●The WBS helps to keep focus on building the processes and procedures – tasks with predecessors and dependencies help to make sure things don’t “fall through the cracks” ●Top-Down implementation approach is new concept at PGN creates new challenges to the normal PGN project management style – much more emphasis on getting requirements completed before starting coding Project Management

11. ●Design and build the Development Processes ▪Leveraged existing IT Standards and Guidelines for SDLC ●Very heavy emphasis on Requirements Development and Documentation ▪Result of PGN consultant study on IT practices ●Create a repeatable and sustainable top-down integration development process ●Finding - Business Process Development is not a quick and easy task Governance - FOCUS on Processes and Procedures

12. ●Leverage the existing corporate ESB provider ●Implement multi-security zone architecture ●Integrate our efforts into a parallel effort to implement a corporate Registry Repository ●Integrate our efforts into the corporate standards for software development and web service governance ●Interoperability between different development environments (.NET C# and ESB java platforms) Infrastructure

13. ●Enterprise Architect ▪New tool – lots of discovery ▪Build usage standards that would work for enterprise ●XMLSpy ▪Already used in company but DSDR team had learning curve ●ESB provider development – new to DSDR personnel ●Registry Repository ●Microsoft Utilities ▪PGN is C# shop. How to take XML schemas and WSDL and produce consistent web services and web clients (providers and consumers) Skill Set development

14. ●Take one integration and go through the whole process ●Define deliverables before starting work on POC ●Deliverables/Measures of Success: ▪Validation of the data modelling processes and service life cycle ▪Identify defects in the process descriptions and plan to mitigate ▪Delivery of the initial DDSB infrastructure ▪High-level performance benchmark of the infrastructure Proof of Concept

15. ●Software development process ▪Our effort focused on 3 of the 5 stages of software development (or 6, depending on the consultant) Top-down integration development process

16. Business Requirements Analysis Use Case / Business Analysis Review and Update Interface Inventory Integration Requirements Specification Document (IRSD) Activity Diagrams Enterprise Architect

17. Requirements Development Business Requirements Analysis DEMO in EA

18. ●Artifacts l IRSD - document l Use Cases – stored in EA l Activity Diagrams – stored in EA l Services and Operations Inventory - spreadsheet l Impact Analysis and Change Package for change management - document Business Requirements Analysis

19. Enterprise Architect w/Xtensible Add-ins Technical Requirements and Design PGN Vocabulary IEC CIM Other models (Multispeak, etc) PGN Semantic Model Integration Message Context

20. Technical Design Development Technical Requirements and Design DEMO in EA Note the different Skill Sets needed Architect Modeler

21. ●Artifacts l IRSD – document l Sequence Diagrams – stored in EA l Data Mappings - spreadsheets l Inventories - spreadsheets Technical Requirements and Design

22. Registry Repository Enterprise Architect w/Xtensible Add-ins Message Content and Structure Message Context Message XSD Generate the message schema Message Header XSD Fault XSD Message Header and Fault XSDs are corporate standards and used by all messages

23. ●Original Design Messaging Artifacts WSDL Message XSD Msg Header XSD Fault XSD XMLSpy

24. Registry Repository Modified PGN Design WSDL Message XSD Msg Header XSD Fault XSD

25. Registry Repository Final Modified PGN Design PGN web Application (Web Service) Message XSD Msg Header XSD Fault XSD WSDL

26. Final Modified PGN Design

27. Registry Repository Web Service and Web Client Development Microsoft Development Environment Message XSD Msg Header XSD Fault XSD WSDL PGN Visual Studio Automation Web Service Code Framework Web Client Code Framework

28. Registry Repository Service Bus Provider and Consumer Development Service Bus Development Environment Message XSD Msg Header XSD Fault XSD WSDL Provider Workflows Consumer Workflows

29. Software Development Process

30. ●Purpose ●Provide a workflow for determination and documentation of User requirements for integrations (interfaces and reporting). ●Provide links to associated forms that are required during this work. ●Provide links to inventory and tracking sheets required by the DSDR project. ●This process fulfils the requirements of the PGN SDLC standards for managing and documenting User Requirements. ●Scope ●This process is applicable only for inter-application integration efforts and integrated reporting efforts. ●This process should be used for all inter-application interface development, including SOA (ESB) based, Point to Point, ETL, and Replication. ●This process should be used for reporting requests where data is moved from the raw data historian or transaction system. DSDR Integration Development Process

31. ●Documents ●Integration Requirements Specification Document (IRSD) ●Interface Inventory ●Service and Operations Inventory ●Mapping Spreadsheets ●Enterprise Semantic Model ●XML Schema (XSD) and Web Service Definition Language (WSDL) files ●References ●Services Naming Standard ●WSI-I ●Internal PGN Software Development Guides and Standards DSDR Integration Development Process

32. ●Select an existing P2P interface that will be migrated to SOA architecture during the project ●Do an end to end test of the user requirements, modeling, xsd and wsdl generation, application adapter architecture, and service bus infrastructure ●Test and refine the governance processes around this methodology so they can be leveraged by other projects DSDR SOA Proof of Concept

33. Application Infrastructure

34. POC Infrastructure

35. Fault Analysis Activity Diagram

36. Sequence Diagram Example

37. ESB DSCADA Fire wall OMS Web Service wM Integration Server wM Broker wM Integration Server wM Broker Gather Fault Data Fault Analysis MRID Web Service DDSB POC Message Flow and Orchestration -.NET Services

38. ●Defined and validated the integration development process using Top-Down design approach for data exchange between applications in a service bus oriented architecture ●Xtensible’s MD3i methodology validated for inter- application messaging development ●EA tool validated as preferred tool for modeling and artifact management ●Established Service and Operation naming standards ●Created base header and fault return document schemas (XSD) Results

39. ●Developed interoperable WSDL format that supports both ESB (Java) and.NET ●Created and tested process for leveraging PE’s.NET WCF Development Template in building web services and application adapters ●Successfully exchanged messages between applications utilizing the service bus across multiple security zones ●Gathered ESB performance statistics for message delivery between zones ●Registry Repository implemented and tested Results

40. ●Accuracy in data modeling was crucial for efficient top- down development. Expertise in UML modeling is required ●CIM is an abstract information model and can’t be used by itself. It needs to be extended by internal Progress Energy semantics ●XSD and WSDL templates were needed to facilitate interoperability between platforms (ESB (java) and.NET) ●The referential nature of XSD’s within WSDL’s mandates the development of XSD’s to be accurate and final before being released for consumption ●Microsoft Visual Studio Automation is critical for repeatable production of web services and clients Lessons Learned – Top-Down Design

41. ●Allow time for familiarization of new tools (EA, md3i, XMLSpy, ESB, Reg Repository) and their idiosyncrasies ●Enterprise Architect is an excellent modeling tool but doesn’t provide safe-guards for user mistakes. Backups using a source code repository is essential as well backing up the model database (SQL Server) ●Because DSDR was the first implementation of the Registry Repository tool, we required extra time to adjust the mix of governance requirements against iterative development needs Lessons Learned – Tool Set

42. ●There can be performance implications from implementing too high a level of security ●There is not a clearly defined matrix of security implementations that fit all the different types of message requirements for DSDR ●Each development environment has idiosyncrasies for security implementation. Not consistent from platform to platform Lessons Learned – Security

43. ●Determining expected load and throughput for each interface is essential in selecting the most efficient messaging pattern to use Lessons Learned - Performance

44. ●Vocabulary ●Master Resource Identifier (MRID) ●More automation around developer tools ●More testing for performance ●Asynchronous message pattern standards On-going Efforts

45. Questions?