Utilization of CIM at Progress Energy with the Smart Grid

Download Report

Transcript Utilization of CIM at Progress Energy with the Smart Grid

Utilization of CIM at Progress
Energy with the Smart Grid
DSDR Project
Top-down approach to Integration
Software Development
Jon Drew
November 12, 2009
Agenda
• 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
PGN Introduction to CIM
● 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
DSDR - How does it work??
Coordinate voltage and var control to defer investment in additional generation by
providing peak load reduction
.
Upper
Regulatory
Limit
Flattened profile allows greater Voltage Reduction
Lower
Regulatory
Limit
Existing
Flattened Profile
4
Lower Voltage to Reduce
MWs
DSDR Architecture – Existing DAS Interfaces and
Data Flow
DSDR Architecture – Final DAS Interfaces and
Data Flow (complete)
Applying CIM to project DSDR
● 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
Implementation Components
● 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)
Top-down integration development process
● Software development process
▪ Our effort focused on 3 of the 5 stages of software development
(or 6, depending on the consultant)
Business Requirements Analysis
Integration Requirements Specification Document (IRSD)
Use Case /
Business
Analysis
Review and
Update
Interface
Inventory
Enterprise Architect
Business Analysis
Activity
Diagrams
Business Requirements Analysis
Requirements Development
DEMO in EA
Business Analysis
Business Requirements Analysis
● 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 Analysis
Technical Requirements and Design
IEC CIM
PGN Vocabulary
PGN
Semantic
Model
Integration
Message
Context
Other models
(Multispeak, etc)
Enterprise Architect w/Xtensible Add-ins
Design
Technical Requirements and Design
Technical Design Development
DEMO in EA
•Note the different Skill Sets needed
•Architect
•Modeler
Design
Technical Requirements and Design
● Artifacts

IRSD – document

Sequence Diagrams – stored in EA

Data Mappings - spreadsheets

Inventories - spreadsheets
Business Analysis
Message Content and Structure
Generate the
message schema
Message
Header
XSD
Fault
XSD
Message Header and Fault XSDs
are corporate standards and used
by all messages
Message
Context
Enterprise Architect
w/Xtensible Add-ins
Message
XSD
Registry Repository
Implementation
Messaging Artifacts
● Original Design
Message
XSD
Msg Header
XSD
Fault
XSD
WSDL
XMLSpy
Implementation
Modified PGN Design
Message
XSD
Msg Header
XSD
WSDL
Fault
XSD
Registry Repository
Implementation
Final Modified PGN Design
PGN web
Application
(Web Service)
Message
XSD
Msg Header
XSD
Fault
XSD
Registry Repository
Implementation
WSDL
Final Modified PGN Design
Implementation
Web Service and Web Client Development
PGN Visual
Studio
Automation
Microsoft
Development
Environment
Web Service
Code Framework
Web Client
Code Framework
Message
XSD
Msg Header
XSD
Fault
XSD
Registry Repository
Implementation
WSDL
Service Bus Provider and Consumer Development
Provider
Workflows
Service Bus
Development
Environment
Consumer
Workflows
Message
XSD
Msg Header
XSD
Fault
XSD
Registry Repository
Implementation
WSDL
Software Development Process
DSDR Integration 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 SOA Proof of Concept
● 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
Application Infrastructure
POC Infrastructure
Fault Analysis Activity Diagram
Sequence Diagram Example
POC Message Flow and Orchestration
ESB
DSCADA
wM
Integration
Server
Gather
Fault
Data
wM
Broker
Fire wall
DDSB
wM
Broker
wM
Integration
Server
OMS
Web
Service
MRID
Web
Service
Fault
Analysis
- .NET Services
Results
● 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 interapplication 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
Lessons Learned – Top-Down Design
● Accuracy in data modeling was crucial for efficient topdown 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 – Tool Set
● 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 – Security
● 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 - Performance
● Determining expected load and throughput for each
interface is essential in selecting the most efficient
messaging pattern to use
On-going Efforts
● Vocabulary
● Master Resource Identifier (MRID)
● More automation around developer tools
● More testing for performance
● Asynchronous message pattern standards
Questions?