Utilization of CIM at Progress Energy with the Smart Grid

DSDR Project

Top-down approach to Integration Software Development

Jon DrewNovember 12, 2009

• 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

● 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

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.

DSDR Architecture – Existing DAS Interfaces and Data Flow

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

● 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

● 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

● 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

Business Requirements Analysis

Business Analysis

Use Case /BusinessAnalysis

Review andUpdate

InterfaceInventory

Integration Requirements Specification Document (IRSD)

Activity Diagrams

Enterprise Architect

Requirements Development

Business Requirements Analysis

Business Analysis

DEMO in EA

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

management - document

Business Requirements Analysis

Business Analysis

Enterprise Architect w/Xtensible Add-ins

Technical Requirements and Design

Design

PGN Vocabulary

IEC CIM

Other models (Multispeak, etc)

PGN Semantic

Model

IntegrationMessageContext

Technical Design Development

Technical Requirements and Design

DEMO in EA

• Note the different Skill Sets needed• Architect• Modeler

Design

● Artifacts IRSD – document Sequence Diagrams – stored in EA Data Mappings - spreadsheets Inventories - spreadsheets

Technical Requirements and Design

Business Analysis

Registry RepositoryEnterprise Architect w/Xtensible Add-ins

Message Content and Structure

MessageContext

Implementation

MessageXSD

Generate the message schema

MessageHeader

XSD

FaultXSD

Message Header and Fault XSDs are corporate standards and used by all messages

● Original Design

Messaging Artifacts

WSDL

Implementation

MessageXSD

Msg HeaderXSD

FaultXSD XMLSpy

Registry Repository

Modified PGN Design

WSDL

Implementation

MessageXSD

Msg HeaderXSD

FaultXSD

Registry Repository

Final Modified PGN Design

PGN web Application

(Web Service)

Implementation

MessageXSD

Msg HeaderXSD

FaultXSD

WSDL

Final Modified PGN Design

Implementation

Registry Repository

Web Service and Web Client Development

MicrosoftDevelopmentEnvironment

Implementation

MessageXSD

Msg HeaderXSD

FaultXSD

WSDL

PGN Visual Studio

Automation

Web ServiceCode Framework

Web ClientCode Framework

Registry Repository

Service Bus Provider and Consumer Development

Service BusDevelopmentEnvironment

Implementation

MessageXSD

Msg HeaderXSD

FaultXSD

WSDL

ProviderWorkflows

ConsumerWorkflows

Software Development Process

● 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

● 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

Application Infrastructure

POC Infrastructure

Fault Analysis Activity Diagram

Sequence Diagram Example

ESB

DSCADA

Fire

wal

l OMSWeb

Service

wM Integration

Server

wMBroker

wM Integration

Server

wMBroker

Gather Fault Data

Fault Analysis

MRIDWeb

Service

DDSB

POC Message Flow and Orchestration

- .NET Services

● 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

● 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

● 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

● 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

● 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

● Determining expected load and throughput for each interface is essential in selecting the most efficient messaging pattern to use

Lessons Learned - Performance

● Vocabulary

● Master Resource Identifier (MRID)

● More automation around developer tools

● More testing for performance

● Asynchronous message pattern standards

On-going Efforts

Questions?