CIM University: Track 1 Afternoon SessionCIM User’s Group
June 13, 2017
• Margaret Goodrich• Principal Consultant, Project Consultants, LLC• Email: [email protected]• Phone: 903-477-7176
• Pat Brown• Principal Technical Leader, EPRI• Email: [email protected]• Phone: 913-449-0736
• Gowri Rajappan• Director, Technology & Cybersecurity, Doble Eng• Email: [email protected]
• Phone: 617 926 4900 x2214
• Stephan Amsbary• Sr. Technical Leader, EPRI• Email: [email protected]• Phone: 828.559.1110
1
2
Introduction
• Information Model & Reference Model
• CIM Based Integration for Outages, Assets, Work Management, Customer Support and Metering
• Network Operations (IEC 61968-Part 3)
• Assets (IEC 61968-Part 4)
• DER (IEC 61968-Part 5)
• Maintenance and Construction (IEC 61968-Part 6)
• Customer Support Interfaces (IEC 61968-Part 8)
• Meter Reading and Control (IEC 61968-Part 9)
• Interface Specification Documentation and CIM Based Integration – a Deep Dive
• Enterprise Architecture Best Practices (Methodology)
• Standards Development Process
© Copyright 2016 Project Consultants, LLC
3
Information Model for all Distribution Series Standards
• UML Classes, Attributes and Associations for all Parts in the 61968 standard series are contained in IEC 61968-Part 11 and IEC 61970-301
• The classes and attributes may come from one or more of the packages contained in these documents.
© Copyright 2016 Project Consultants, LLC
WG14 Messaging Reference Model
Key Outside the scope of 61968
61968 Part 9
Defined by other 61968 Parts
ServicePoint
Metering System
Data Collection
Control and Reconfiguration
[ 18 ]
[ 3 ]
Meter Maintenanceand
Asset Management
[ 2 ]
MeterData
Management
CustomerInformation
andBilling
[ 9 ]
[ 20 ]
[ 15 ]
{ 8 }
{ 14 }
[ 19 ]
[ 17 ]
{ 16 }
{ 11 }
Interface and protocol details of the Service Point are outside the scope of
IEC 61968-9
[ 5 ]
[ 21 ]
[ 1 ]
Planningand
Scheduling
[ 7 ]
[ 7 ][ 6 ]
[ 4 ]
[ 13 ]
[ 12 ]
{ 23 }
[ 22 ]
61968-3
61968-8
61968-5
[ 7 ][ 6 ]
[ 18 ]
[ 13 ]
{ 12 }
{ 12 }
[ 1 ] Account information[ 2 ] Configuration, installation etc.[ 3 ] Controls and signals[ 4 ] Customer data set[ 5 ] Data obtained by special read[ 6 ] Demand response signals[ 7 ] Disconnect/reconnect, demand reset{ 8 } Install, remove, repair, disconnect, reconnect[ 9 ] Load curves, Measurement history, etc.[ 10 ] Load scenarios{ 11 } Meter health and tamper detection{ 12 } Meter history
[ 13 ] Meter readings{ 14 } Meter service request[ 15 ] On request read[ 16 ] Outage and restoration verification[ 17 ] Power reliability and quality events[ 18 ] Readings, events and status[ 19 ] Special read[ 20 ] Tariffs, parameters[ 21 ] Transaction information[ 22 ] Transaction records{ 23 } Tokens
NetworkOperations
WorkManagement
61968-6
Outage Management
61968-3
[ 3 ]
Pointof
Sale
61968-10
[ 12 ]
{ 14 }
LoadManagement
System
Load Analysis
Load Control
[ 10 ]
© Copyright 2016 Project Consultants, LLC4
End-to-End Use Cases and Messages
Use Cases:
1. Initialize network2. Non-telemetered fuse trips3. Telemetered breaker trips4. Tap for new subdivision5. Maintenance on transformer6. Meter replacement
Normal State
Normal State
Normal & assetchanges
Proposed normalchanges
Recommended normalchanges
Build SwitchingPlan
Substation
IED
IED
IED
Device out &fault data
Device out &fault data
Metersdown
Device out &fault dataDevice Out
Device out
Energize
Switching Plan to energize
Fault location isolation stepsRestoration steps
AMI/MDM
SCADA
OMS DMS
GIS Planning
Predict tooutage device Current
StateCurrent
State
NormalState
Normal State
CIS
WMS
MWF
Meter servicerequest
Meter serviceorder
Meter info &complete
status
WMS
MWF
Isolation Steps
FLISR = Fault Location, Isolation,
and Restoration
Scope:
A - Outage ManagementB - Network Model Synchronization
C - Maintenance
IEC61968 Scope
Workorder
Current State
© Copyright 2016 Project Consultants, LLC5
Network Operations Scope (IEC 61968-Part 3)
Enterprise
Applications
Control Center Applications
RTU
IED
Enterprise
Integration
Infrastructure
(e.g. ESB, SOA,
)
Standard or
Proprietary
Communication
Infrastructures
Messages
defined by IEC
61968-3 and
based upon IEC
CIM, conveyed
using a variety of
integration
technologies
Network
Operations
Messages
Messages
defined by
relevant
standards or
vendors. May
use a wide
variety of
communication
technologies
OMS
SCADA
CIS
[Part 8 –
Customer
Support]
AMI/MDM
[Part 9 – Meter
Reading &
Control]
WMS
[Part 5 –
Operational
Planning
Part 6 –
Maintenance &
Construction]
MWM
[Part 6 –
Maintenance &
Construction]
DMS
Part 3
IEC
61
96
8-3
Me
ssa
ge
s*
Advanced DMS
* Note, that depending on the system configuration,
these can also be proprietary interfaces (E.g. a
system that covers DMS and SCADA in one product).
© Copyright 2016 Project Consultants, LLC6
7
Network Operations Scope (Outages)
• An outage can be detected by:• AMI• Customer Call• Field Crew• SCADA
• An outage must be communicated between networkoperations systems, including trouble location, devices inabnormal state, and customers affected.
• Other Network Operations Outage is the Fault Location,Isolation, and Supply Restoration (FLISR).
• Fault location refers to the observations, signals, and analysisnecessary to identify the true cause of the outage.
• Isolation is the process of switching and cutting that allows thefault location to be safely isolated for repairs.
• The process of restoring power to healthy islands of networkaround the isolated area is referred to as supply restoration.
• Other areas will be added as Use Cases are defined.
© Copyright 2016 Project Consultants, LLC
Network Operations (Outage Management) Reference Model
© Copyright 2016 Project Consultants, LLC8
Work Flows - Outage Notification from an AMI
sd Outage Notification from Meters
«Fault Mgmt»
Part 3 - Network
Operation::NO-FLT
«Outage Analysis»
Part 3 - Network
Operation::NO-OA
«Trouble Call M...
Part 8 - Customer
Support::CS-TCM
«AMI»
Part 9 - Meter
Reading and
Control::MR-AMIField Crew
Created(EndDeviceEvent)
Confirm Outage()
Outage Confirmed()
Created(Outage)
Created(Outage)
© Copyright 2016 Project Consultants, LLC9
10
IEC 61968-4 CIM for Asset Management
• Close collaboration between IEC TC57 WGs and the utility CIM user community – an Asset Health Focus Community set up for this purpose
• 61968 – Part 4 Edition 2 Draft completed and CD to be submitted to IEC.– Three main areas of work: Assets, Measurements and Analytics.– Many new concepts and models.– 18 messages, of which 15 are new and 3 are major revisions from Ed 1.
• 61968-4 Edition 3 Scope Development in progress.– Asset work.– Asset investment planning.– Asset management activities other than health-related (compliance,
configuration management, etc.).– Real-time analytics (DER, operational impact, etc.)– Weather considerations.
© Copyright 2017 Doble Engineering Co.
11
IEC 61968-4: Vision
© Copyright 2017 Doble Engineering Co.
Aligns with ISO 55000 Asset Management Concepts
12
IEC 61968-4: Use Case #1 – Analytical Evaluation of Asset Health and Risk
• Business case: Decide renewal priorities on network and optimise maintenance programs.
• The analytical evaluation is used to strategically plan, on the basis of factors such as asset ageing rate, what assets need to be renewed or replaced, and when.
• The analytical evaluation is also used to determine the maintenance schedule of assets on the basis of their condition.
© Copyright 2017 Doble Engineering Co.
13
IEC 61968-4: Use Case #2 – Replace a Failing or Failed Asset
• Business case: Decide to carry out urgent maintenance operations.
• The replacement could be the same product model as the original asset or a different model with equivalent capability.
• The replacement work is coordinated with grid operations for safety while the work is in progress and quick restoration of function when the work is completed.
© Copyright 2017 Doble Engineering Co.
14
IEC 61968-4: Asset Model
© Copyright 2017 Doble Engineering Co.
15
IEC 61968-4: Asset Model
© Copyright 2017 Doble Engineering Co.
16
IEC 61968-4: Asset Model
© Copyright 2017 Doble Engineering Co.
17
IEC 61968-4: Measurements Model
© Copyright 2017 Doble Engineering Co.
18
IEC 61968-4: Analytics Model
© Copyright 2017 Doble Engineering Co.
19
IEC 61968-4: Asset Messages
© Copyright 2017 Doble Engineering Co.
20
IEC 61968-4: Measurements Messages
© Copyright 2017 Doble Engineering Co.
21
IEC 61968-4: Analytics Messages
© Copyright 2017 Doble Engineering Co.
22
• Information on CIMug SharePoint sitehttp://cimug.ucaiug.org/Focus_Comms/AssetHealth/
– UCAI UserID needed
Asset Health Focus Community
• Contact – Gowri Rajappan, [email protected]– Pat Brown, [email protected]
© Copyright 2016 EPRI, Inc.
23
Enterprise DER IntegrationDeveloping 61968-5, MultiSpeak Support (2012-2014)
DMS
GIS
Sensors, Switches, Capacitors, Regulators
MDMS OMS
DERMS
SOLAR BATTERY PEV
• Creation and management of
groups and sharing of group
definitions
• Monitoring of group status
• Dispatch of real and reactive
power
• Forecasting of group
capabilities
• Compliance Test – NREL
(2014)
Enterprise Integration
Report 3002001249 Enterprise Integration Functions for Distributed Energy Resources
24
IEC 61968-5 DER Use Case prioritization
Functional/Technical Implementation
• 2012 – 2014 Phase I• DER group creation and maintenance• DER group Status and Monitoring• DER group dispatch (Power: active, reactive, apparent)• DER group forecast
• 2015 – 2016 Phase II• Additional Functional Requirements
• 2017 Phase III Technical Implementation• DER group connect/disconnect• DER group voltage regulation• DER group capability discovery
25
Example Integrationssd Create Group - generic
:Group Forming Entity :Group Acknowledging
Entityopt DERMS created group
create(DERGroups)
reply(DERGroups)
create(DERGroups)
sd DER Dispatch
DMS DERMS DER (1..n)
ref
Status Monitoring PUSH
individual OpenFMB signals()
individual 61850 signals()
reply()
individual DNP3 control signals()
createDERGroupDispatches()
determine how to meet request()
26
DERMS enterprise…
DMS DERMS
DER
DER
DER
DER
27
…to DERMS “anywhere”
Enterprise Integration
GIS OMS
DMS DERMS
Sensors, capacitors, switches
SCADA, Field Networks
DERMS
DERMSSmart Inverter
DERMS
28
DERMS Internal Architecture example
technology DERMS
DERMS
Ubuntu 14.04DBMS
2. DER Comms
1. Enterprise
Comms (61968-5)
3. Security
4. Group
Maintenance
6. Forecast
5. Status
Monitoring
7 Dispatch
Active Power Reactive
Power
Voltage
Regulation
Field NetworkEnterprise Network
Status
Monitoring
Group
Maintenance
Forecast
Dispatch
DER 1
DER 2
DER n
OpenFMB Comms
IEC 61850 Comms
DNP3 Comms
IEEE 2030.5 Comms
29
Test case - 61868-5 Compliance /Interoperability Compliance Testing
Test Script for DERMS to GIS
Test Script for DERMS to DMS
Report 3002004681
Enterprise Integration
Functions Test Plan for
Distributed Energy
Resources, Phase 1
30
Testing Artifacts / Resources
• Common Functions For DER Group Management, Third Edition, 3002008215
• Functional requirements, 30 functions• https://www.epri.com/#/pages/product/000000003002008215/
• Program on Technology Innovation: Test Script for International Electrotechnical Commission, 61968-5:CDMessages
• Resource file: WSDLS, XSDs• https://www.epri.com/#/pages/product/000000003002009276/
• 2017 - 3002009983• Adding 3 use cases• “Breaking change” to dispatch / forecast• Weekly calls to cover the details
31
Maintenance and Construction (Work Management) Scope (IEC 61968-Part 6)
• Specifies the information content for messagesused to support business functions related toMaintenance and Construction.
• Typical uses of Part 6 messages include:• Planned Maintenance (Work Request)
• Meter Change Out (Service Order)
• Device Maintenance (Maintenance Order)
• Message types defined in other Parts of IEC61968may also be relevant to these use cases.
© Copyright 2016 Project Consultants, LLC
32
Maintenance and Construction (Work Management) Reference Model
Operational
Planning &
Optimization
Network Operation
Simulation
(OP-SIM)
Network Operations
Fault Management
(NO-FLT)
Maintenance &
Construction - Field
Recording
(MC-FRD)
Mobile Workforce
[ 10 ]
[ 12 ]
Network Monitoring
NO-NMON
[ 1 ]
Customer Support
(CS)
Customer Service
CSRV
[ 11 ] Available / Used Materials
[ 12 ] Bill Of Materials / Material Status
[ 13 ] Crew Composition
[ 14 ] Actual Labor Cost
[ 15 ] Failure Event
[ 16 ] New/Updated or get Asset
[ 17 ] Special Read Request / Response
[ 18 ] Install, Remove, Repair, Connect and Disconnect
[ 19 ] Meter History
[ 20 ] Map
[ 21 ] Outage Notification from Field Crew
[ 22 ] Outage Confirmation Request
[ 1 ] SCADA Measurements, failures, conditions
[ 2 ] Switching Plan
[ 3 ] Request for Service
[ 4 ] Materials Reservation
[ 5 ] Request for Planned Maintenance/Inspection Work
[ 6 ] Request for Unplanned Work
[ 7 ] Follow-up Work
[ 8 ] Switching Order
[ 9] Work Request from Network Operations
[10 ] Work Order
[ 11 ]
[ 7 ]
[ 3 ]
Records & Asset
Management (AM)
General Inventory
Management (GINV)
Equipment hierarchy
[ 13 ]
[ 6 ]
Work Mgt Planning
[ 5 ]
Materials
Management
Crew
Composition
[ 4 ]
[ 16 ]
[ 2 ]
61968 Part 6
Defined by other 61968 Parts
Key
[ 14 ]
[ 8 ]
{ 15 }
Scheduling & Dispatch
[ 13 ]
[ 10 ]
Maintenance & Construction
Maintenance and Inspection
(MC-MAI)
Preventive Maintenance
Conditional Maintenance
[ 9 ]
Meter Reading &
Control
(MR&C)
[ 17 ]
[ 18 ]
{ 19 }
[ 20 ]
[ 12 ]
[ 12 ]
[ 16 ]
[ 10 ]
[ 21 ]
[ 22 ]
© Copyright 2016 Project Consultants, LLC
33
Planned Maintenance Work Flow
• Triggered by maintenance and inspection, or by periodic schedule for work.
• Example activity is tree trimming or major maintenance on a power transformer.
• Uses Work Request message
© Copyright 2016 Project Consultants, LLC
Planned Maintenance Work Flow sd Carry out planned maintenance with temporary equipment
Part 6 - Maintenance
and
Construction::MC-MAI
«Work Sched & Di...
Part 6 - Maintenance
and
Construction::MC-SCHD
«Subst. & Network ...
Part 4 - Records and
Asset
Management::AM-EINV
«Geographic Inv.»
Part 4 - Records and
Asset
Management::AM-GINV
«Field Recording»
Part 6 - Maintenance
and
Construction::MC-FRD
«Network Ctrl»
Part 3 - Network
Operation::NO-CTL
Create(WorkRequest)
Create(OutageBooking)
Created(BookedOutage)
Create(MaintenanceOrder)
Get(Map)
Reply(Map)
Get(Asset)
Reply(Asset)
Create(MaintenaceOrder)
Execute(WorkOrder)
Changed(MaintenanceOrder)
Close(MaintenanceOrder)
Closed(WorkRequest)
© Copyright 2016 Project Consultants, LLC34
35
Meter Change Out Work Flow
• May include one or more Meter Service Work items
• Each item may refer to a max of two meters to provide a means to replace a meter.
• Meter readings can be obtained as a part of the work.
• A Meter Service Request occurs due to:
• Change out a Meter due to a Problem (Alarm, Complaint or other event)
• Change out a Meter for Recalibration
© Copyright 2016 Project Consultants, LLC
36
Meter Change Out Work Flow
• When a Meter Change-Out is performed the following steps must occur:
• Send a MeterServiceRequest to the WMS• Send a Meter Technician to:
• Take the final Meter Reading• Remove the old Meter• Install the new Meter• Take the new Meter Reading
• The following messages are sent/received to Configure the Meter:
• EndDeviceConfig• CustomerMeterDataSet• MeterConfig• MeterReadSchedule
© Copyright 2016 Project Consultants, LLC
Change-Out Meter Work Flow
© Copyright 2016 Project Consultants, LLC37
38
Customer Support Interface Scope (IEC 61968-Part 8)
• Specifies the information content for messages used tosupport business functions related to Customer Serviceand Trouble Call Management.
• Typical uses of these messages include:• Trouble Ticket
• Incident Information
• Service Request
• Customer Agreement
• Message types defined in other Parts of IEC61968 mayalso be relevant to these use cases.
© Copyright 2016 Project Consultants, LLC
39
Customer Support Interface Reference Model
Part 8 Customer Support (CS)
Customer service (CSRV)
Trouble Call Management (TCM)
(3) Trouble Call Management
(NO)
(6) Maintenance and construction
(MC)Other Systems
61968 Parts 3-9
(1)(2)(3)(5)
1. Trouble Ticket2. Incident Information3. Service Request4. Work Request5. Customer Agreement6. Service Request
(4)
(6)
© Copyright 2016 Project Consultants, LLC
Trouble Ticket Work Flow sd Trouble Ticket
CS-TCM
(from Approved Actors)
NO-FLT
(from Approved Actors)
Call taker takes all
the relevent info
from the customer
and enters the
calls in the call
tracking
application()
Created(TroubleTicket)
Obtain connectivity topology ()
Reply(TroubleTicket)
© Copyright 2016 Project Consultants, LLC40
Incident Information Work Flow sd Incident Information
NO-FLT
(from Approved Actors)
CS-CSRV
(from Approved Actors)
Update(IncidentInformation)
Update associated trouble ticket()
© Copyright 2016 Project Consultants, LLC41
42
Meter Reading and Control Scope (IEC 61968-Part 9)
• To Define the exchange of information between a Metering System and other systems within the Utility enterprise
• Specifies the information content of a set of message types that can be used to support many of the business functions related to Meter Reading and Control.
• Typical uses of the message types include:• Meter Event Messages
• Meter Control Messages
• Meter Reading Messages
© Copyright 2016 Project Consultants, LLC
Meter Reading and Control Scope
Enterprise
Applications
Head End
SystemsPAN
PAN
Device
PAN
Device
PAN
PAN
Device
PAN
Device
Meter
Meter or
Gateway
Meter or
Gateway
PAN
Device
Utility
Enterprise Integration
Infrastructure
(e.g. ESB, SOA, …)
Standard or Proprietary
Communication
Infrastructures
Messages defined by IEC
61968-9 and based upon
IEC CIM, conveyed using a
variety of integration
technologies
IEC 61968-9 Messages
Messages defined by
relevant standards or
vendors. May use a wide
variety of communication
technologies
Messages defined
by PAN/HAN
specifications
Mappings, translations
and/orforwardiing as
needed Mapping, translations
and/or forwarding as
needed
Customer
Customer
Customer
Area of Direct Impact
using IEC 61968-9
Area Causally/Indirectly
Impacted by or impacting
IEC 61968-9
© Copyright 2016 Project Consultants, LLC43
Meter Reading and Control Reference Model
Key
Service
Point
Metering System
Data Collection
Control and
Reconfiguration
Readings, events
and status
Controls and signals
Meter
Data
Management
Scheduled
Read
Interface and protocol details of the
Service Point are outside the scope of
IEC 61968-9
Outside the scope of 61968
61968 Part 9
Defined by other 61968 Parts
Scheduled
Read
Tokens
Network
Operations
61968-3
Scheduled
Read
Customer
Information
and
Billing
61968-8
Exchange
Portal
Scheduled
ReadPeak
Price
(1)
Peak
Price (1)Load
Reduction
Peak
Price (1)
Load
Reduction
Peak
Price
(2)
Meter
Administration
© Copyright 2016 Project Consultants, LLC44
45
Meter Reading and Control Reference Model
• The Reference Model provides examples of the logical components and data flows related to this standard.
• The Meter is treated as an “end device”
• An End Device:
• Has a unique identity
• Is managed as a physical asset
• May issue events
• May receive control requests
• May collect and report measured values
• May participate in utility business processes
• The Reference Model describes the flows between the components.
© Copyright 2016 Project Consultants, LLC
46
Meter Reading and Control Messages
• There are currently 63 Metering Messages
• End Device Event Messages (includes PAN Messages)
• End Device Control Messages (includes PAN Messages)
• Meter Reading Messages
© Copyright 2016 Project Consultants, LLC
47
EndDeviceEvent Messages
• EndDeviceEvent Messages Convey events related to:
• Sustained and Momentary Outage Detection
• Low and High Voltage Threshold Detection
• Meter Health
• Tamper Detection
• Revenue Event
© Copyright 2016 Project Consultants, LLC
EndDeviceEvent Work Flow for Outage Detection Event
© Copyright 2016 Project Consultants, LLC48
49
End Device Control Messages
• The EndDeviceControl message issues control commands related to:
• Load Control
• Demand Reset
• Connect/Disconnect
• Real-Time Pricing
© Copyright 2016 Project Consultants, LLC
EndDeviceControls Work Flow – Remote Disconnect
© Copyright 2016 Project Consultants, LLC50
51
MeterReadings Message
• The request for meter reading should specify:• A meter or group of meters
• A type of reading to collect
• A frequency
• A Duration of interest
• The scheduled frequency may consist of regular or irregular periods.
© Copyright 2016 Project Consultants, LLC
MeterReadings Work Flow - Billing Inquiry
© Copyright 2016 Project Consultants, LLC52
End Device Types –(EndDeviceEventType) Enumerations
• EndDeviceEventType enumerations defines the event using four parts:EndDeviceEventType := <EndDeviceType>.<EndDeviceDomain>.<EndDeviceSubdomain>.<EndDeviceEventorAction>Where:
<EndDeviceType> = a numeric value from the EndDeviceType enumeration. Example: 3 is Electric Meter, 5 is a Gateway, 12 is a PAN Device, etc.<EndDeviceDomain> = a numeric value from the EndDeviceDomain enumeration. Example: 26 is Power, 15 is Load Control, etc.<EndDeviceSubdomain> = a numeric value from the EndDeviceSubdomain enumeration. Example: 0 is N/A, 28 is Power Quality, etc.<EndDeviceEventorAction> = a numeric value from the EndDeviceEventorAction enumeration. Example: 85 is Failed, 81 is Opted-Out, etc.
© Copyright 2016 Project Consultants, LLC53
Message Organization – Event Type Enumerations
EndDeviceEventType Description
3.26.0.85 Power off alarm
3.26.0.216 Power on
3.26.38.150 Low voltage
3.26.38.93 High voltage
3.26.38.37 Voltage Imbalance Cleared
3.12.1.38 Unauthorized Access attempt
3.12.0.257 Tamper detection
3.8.0.215 Demand reset occurred
3.31.0.68 Disconnected
3.31.0.42 Connected
© Copyright 2016 Project Consultants, LLC54
EndDeviceEvent XML Message ExampleMeter Power Off Event (Last Gasp): Electric, Power, N/A, Failed<ns1:EndDeviceEvents
xmlns:ns1="http://iec.ch/TC57/2011/EndDeviceEvents#">
<ns1:EndDeviceEvent>
<ns1:createdDateTime>2009-11-04T18:52:50.001-
05:00</ns1:createdDateTime>
<ns1:EndDeviceEventType ref=“3.26.0.85”/>
<ns1:description>Power off alarm</ns1:description>
<ns1:Assets>
<ns1:mRID>3dc53ee5-777e-50b4-8699-
a1c224f45f3d</ns1:mRID>
<ns1:Names>
<ns1:name>Meter23253</ns1:name>
</ns1:Names>
</ns1:Assets>
</ns1:EndDeviceEvent>
</ns1:EndDeviceEvents>© Copyright 2016 Project Consultants, LLC
55
56
CIM Based Integration –Interface Specification Doc (Example)• Define Integration Systems and Points
• Define the Actors• Define the Interface Diagram
• Define Information Exchanges for each Integrated System using Sequence Diagrams
• Functions to be performed• Data to be exchanged (the Payloads)
• Define Context Diagrams for each System’s Integration Points
• Generate Spreadsheet with Message Content and CIM Mapping• Define each message payload in a spreadsheet• Map each message payload to the CIM• Extend the CIM as needed using CIM UML tools• Generate the Message Payload (Profiles) in XSD using a tool
• Identify Testing Matrix for Each Interface• Identify the specific areas to be tested• Identify the behaviors to be tested
• Document Test Cases© Copyright 2016 Project Consultants, LLC
Table of ActorsActor Nickname Description Notes
MS (Metering System) AMI
The Metering Infrastructure responsible for automated energy monitoring and control, configuration of advanced meters, distribution automation, Meter Readings, Meter Events and Alarms
Meter Data Management System
MDMS
The Meter Data Management system is responsible for collecting the reads from the AMI Head-End, performing VEE services and presenting the billing determinants to CIS.
Customer Information System
CIS The Customer Information System acts as the system of record for Customer, Account, premise and rate information.
© Copyright 2016 Project Consultants, LLC57
Sample Interface Diagram
© Copyright 2016 Project Consultants, LLC58
Sample Sequence Diagram -Connect/Disconnect
© Copyright 2016 Project Consultants, LLC
59
Sample Context Diagram -Connect/Disconnect
© Copyright 2016 Project Consultants, LLC60
Message Definition and Mapping Spreadsheet
Column Name Data Type Source Comments CIM Mapping CIM Comments
ORDER_ID NUMBER po_order Region unique OutageRecord.Names.name
Use the name structure - This and the next line appear in the schema once but have multiple instances in the actual message payload.
ORDER_LABEL VARCHAR2(24) po_order Company unique OutageRecord.Names.name Use the name structure
ORDER_TYPE VARCHAR2(32)
po_orderpo_ui_order_type
internal vs. external? -isTrouble, nsTouble, switching, etc. Extension
Will be a String that may become an enumeration
LOCATION VARCHAR2(80) po_orderi.e. Address or closest intersection, etc. Location.StreetAddress
CKT_NUMBER VARCHAR2(24)
po_order_info.feeder_numbers()
derived from breaks for incidents, may be multiple ACLineSegment.Names.name
For the ACLineSegment - may have multiple feeders affected. This and the next line appear in the schema once but have multiple instances in the actual message payload.
CKT_NAME VARCHAR2(66)
custom_get_circuit_names() may be multiple ACLineSegment.Names.name
For the ACLineSegment - may have multiple feeders affected
OUTEXTENT VARCHAR2(50)
aep_custom.outage_classification() - Breaker, Recloser, Fuse, etc.
Extension - Is this the same as the device field below?
Will be a String that may become an enumeration
CUSTOUT NUMBERNumber of Customers that are out OutageReport.customerCount Integer
MAXCUSTOUT NUMBER(10)
Max number of customers that have been out in the past for this order.
Extension - put attribute in OutageReport Integer
COMMENTS VARCHAR2(500)Dispatcher and Crew free form comments
Extension - put attribute in OutageRecord
String - entered realtime as work on outage progresses
© Copyright 2016 Project Consultants, LLC61
Testing Matrix
Device Pair
GWAC Layers
Res
po
nse
to
Fai
lure
Bas
icC
on
nec
tivi
ty
Net
wo
rkIn
tero
per
abili
ty
Syn
tact
icIn
tero
per
abili
ty
Sem
anti
cU
nd
erst
and
ing
AMI Head-End
CIS YES YES YES YES YES
AMI Head-End
MDMS YES YES YES YES YES
AMI Network
AMI Head-End
NO NO NO NO NO
Legend:YES – Testable LayersNO– Proprietary / Inaccessible LayerN/A – Not Applicable
© Copyright 2016 Project Consultants, LLC62
63
CIM Based Integration using a Message Based Implementation Process
• Introduction & Scope
• Integration Choices and Patterns• Web Service/Client-Server/JMS
• Using an ESB or not
• Messaging• Common Message Envelope
• Verbs
• Nouns (aka Payload)
• The Naming Problem• The Problem Definition
• The CIM Solution© Copyright 2016 Project Consultants, LLC
64
Introduction
• The purpose of this section is to describe enterprise integration as defined in the IEC 61968-100, Ed. 1 standard
• This standard is reflective of best practices and integration experiences, and has effectively been in use since 2006
• Approach published several years ago as an EPRI report
• IEC 61968-100 became an IEC standard in 2013
© Copyright 2016 Project Consultants, LLC
65
Scope of IEC 61968-100
• IEC 61968-100 focuses on message-based integration using transport technologies such as JMS and web services
ESB
Integration
Layer
Web Service
Client
Web Service
Service
WS - Direct Interaction w/o Integration Layer
Application
using JMS
Application
using JMS
JMS JMS
WS WS
JMS – Direct integration using a JMS server
Client or Server
using another
integration
technology
C/SClient or Server
using another
integration
technology
C/S
© Copyright 2016 Project Consultants, LLC
66
Integration Patterns• There are many possible integration patterns, but
there are several that provide basic building blocks
• These basic patterns include:– Synchronous request/reply
– Point to point
– Publish/subscribe
– Asynchronous request/reply
• Request/reply patterns can be used to support queries as well as transactions
© Copyright 2016 Project Consultants, LLC
67
Basic ESB Integration Patterns
Publish/Subscribe
Synchronous Request/Reply
Asynchronous Request/Reply
Point-to-Point (One Way)
© Copyright 2016 Project Consultants, LLC
68
Two Integration Implementation Options using Request/Reply
• Basic examples using web services and JMS
• Web services can either have generic interfaces or be strongly typed
• JMS can use topics or queues
Web Service Client
Service
WS Interface
ReplyRequest
WS Interface
ESB or standalone JMS
JMS Client
JMS Service
JMS Interface
JMS
Topic or
Queue
Request
Request
Reply
JMS Interface
Reply
Topic or
Queue
Reply
© Copyright 2016 Project Consultants, LLC
Messaging
© Copyright 2016 Project Consultants, LLC69
• In all cases messages are defined in XML Schemas:• Are used to define the structure of the message envelopes
• Are used to define the structure of the message payloads
• Message envelopes are used to convey 61968 messages
• Key contents are: verb, noun, payload
• Verb identifies if the message is a query request, transaction or an event that may be the consequence of a transaction
• Noun identifies the contents of the payload
• From a common message envelope structure there are three stereotypes that are used:
• RequestMessage
• ResponseMessage
• EventMessage
Message Envelopes
© Copyright 2016 Project Consultants, LLC70
Message Envelope Structure
•Header: Required for all messages (except for fault response messages), using a common structure for all service interfaces•Request: optional, defining parameters needed to qualify request messages•Reply: Required only for response messages to indicate success, failure and error details•Payload: Sometimes required, used to convey message information as a consequence of the ‘verb’ and ‘noun’ in the message Header
© Copyright 2016 Project Consultants, LLC71
Message Payload
• The structure of a payload is typically defined as a Profile from a UML model
• A payload may or may not be required in a message
• A message payload is required for a Create, Update Request or in a Reply for a successful Get Request
• An example of this message is the Power Off (last gasp from a meter).
© Copyright 2016 Project Consultants, LLC72
73
Verb Usage
Request Verb Reply Verb Event Verb Usage
get reply (none) query
create reply created transaction
change reply changed transaction
cancel reply canceled transaction
close reply closed transaction
delete reply deleted transaction
execute reply executed transaction
© Copyright 2016 Project Consultants, LLC
74
Noun Example – Identifies Payload (EndDeviceEvents)
© Copyright 2016 Project Consultants, LLC
75
Example with Verbs and Nouns
© Copyright 2016 Project Consultants, LLC
Example Message (Meter Event – Last Gasp)<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body><ns0:RequestMessage xmlns:ns0="http://www.iec.ch/TC57/2008/schema/message">
<Header xmlns:jms1="http://www.tibco.com/namespaces/tnt/plugins/jms" xmlns:ns0="http://www.docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns1="http://www.docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns="http://www.iec.ch/TC57/2008/schema/message">
<Verb>created</Verb><Noun>EndDeviceEvents</Noun><Revision>1.4</Revision><Timestamp>2010-01-05T18:00:00Z</Timestamp><Source>CIS</Source><AsyncReplyFlag>true</AsyncReplyFlag><ReplyAddress>queue:INTEROP.ECOLOGIC.REPLY</ReplyAddress><MessageID>234782443</MessageID><CorrelationID>IOP Reconnect_4_216</CorrelationID>
</Header><Payload xmlns:jms1="http://www.tibco.com/namespaces/tnt/plugins/jms"
xmlns:ns0="http://www.docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns1="http://www.docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns="http://www.iec.ch/TC57/2008/schema/message">
<tns:EndDeviceEvents xmlns:tns="http://iec.ch/TC57/2009/EndDeviceEvents#"><tns:EndDeviceEvent>
<tns:createdDateTime>2009-11-04T18:52:50.001-05:00</tns:createdDateTime>
<tns:EndDeviceEventType ref=“3.26.0.85</tns:type><tns:description>Power off alarm</tns:description><tns:Assets>
<tns:mRID>3dc53ee5-777e-50b4-8699-a1c224f45f3d</tns:mRID><tns:Names><tns:name>Meter23253</tns:name></tns:Names>
</tns:Assets></tns:EndDeviceAsset>
</tns:EndDeviceEvent></tns:EndDeviceEvents></Payload>
</ns0:RequestMessage></SOAP-ENV:Body>
</SOAP-ENV:Envelope>© Copyright 2016 Project Consultants, LLC
76
77
The Naming Problem• Object naming is an important aspect of integration that is often
overlooked especially where all systems do not use common names, naming conventions or Master Identification Numbers (i.e., mRIDs)
• Issues: • The same object may be known in different system by different names
• Messages need to use an identified that is known by source and targets
• Some systems may need to be aware of multiple identifiers for a single object (e.g. local ID and external ID)
• Sources and targets MUST agree upon names to be used, or rely upon the use of bilateral mapping tables for object names
• A naming service could be used for allocating and managing names
• The performance implications of name lookups needs to be carefully considered
• Name class introduced in CIM v15 to help address these issues, providing a more realistic and useful model of object naming
• In theory, an mRID is just another type of name!
© Copyright 2016 Project Consultants, LLC
78
CIM Name Class
• Identified Objects can have many Names
• Each Name.name instance can be associated with a different NameType
• NameTypes can be associated with a NameTypeAuthority that can be responsible for allocating Name.name values within a NameType
• IdentifiedObject.name preserved for legacy reasons
© Copyright 2016 Project Consultants, LLC
79
Name Mapping Example
• Source sends a message related to object ‘ABC’
• Within message Name.name value is set to ‘ABC’
• Name.NameType.name can be used to specifically identify the type of name
• Target receives the message
• Given that the Name.name value is unknown, a table lookup is required to know that object named ‘ABC’ as provided by the external system is equivalent to locally named object ‘1’
• This is a bilateral agreement required for integration where all systems do not share a globally unique ID
External ID Local ID
ABC 1
XYZ 2
RTY 345
INB 67433
MJG 222
ECV 555
GGG 225
Note: This is one example, there are many options
© Copyright 2016 Project Consultants, LLC
80
CIM Based Integration – The Keys to Success
• Benefits and Challenges
• Success Factors
• Information Requirements
• Using and Extending the Standards
• What skill sets are required
• Where to Start
• Training
© Copyright 2016 Project Consultants, LLC
81
Enterprise Integration with CIM
• The benefits• Common semantic model for all areas of utility operations
• Fully-specified, standardized XML messaging for data in flight
• Vendor independence, increasing vendor uptake
• The challenges• Legacy applications don’t speak CIM
• Information Technology / Operational Technology culture clash
• “Big Data”
• All of the usual organizational impacts of integration re-engineering, plus…
• Retraining!
© Copyright 2016 Project Consultants, LLC
82
The Keys to Success
• Information Requirements• Map your enterprise onto the CIM metamodel of an electric utility
• Find the language for IT to communicate with OT
• Understand security requirements
• Enterprise Integration Environment• Choose the right toolchain(s)
• Service Bus
• Adapter framework
• Information modelling tools
• Incremental Adoption• Identify highest-value interfaces to begin with
• Manage your training strategy
© Copyright 2016 Project Consultants, LLC
83
Information Requirements
• Integration is more than mapping data, bit by bit
• Integration mediates business process steps
• Business process + data = information
• Business process can be captured:• in terms of actors and use cases
• in terms of information lifecycle and activity diagrams
• Capture information requirements for your integration points:
• and you have modeled a lot of your enterprise
• and you have a bridge between data-centric (OT) and process-centric (IT) worldviews
© Copyright 2016 Project Consultants, LLC
84
Using & Extending the Standards
• Information requirements also discover any gaps in the standards
• Have a robust methodology for extension• Direct involvement with IEC Working Groups from the
beginning (identify extensions and submissions)
• Engage a competent consultant in the CIM Integration field (example is the CIM for Environment work we will present in a few minutes)
• Implementation does not need to wait for extensions to be accepted into the standards
© Copyright 2016 Project Consultants, LLC
85
What are the new skills?
• Information Modelling• UML
• XML / XSD / XSLT/RDFS
• Tools• Information Modelling
• e.g. Sparx Systems Enterprise Architect
• CIM Profiling
• e.g. CIMTool or something like it
• Adapter Framework
• JMS / JPA / JCA
© Copyright 2016 Project Consultants, LLC
86
Where to start?
• Don’t Boil the ocean – derive a roadmap to integration multiple systems one step at a time.
• How is the Roadmap derived?• “Highest-value” interfaces: what kind of value?
• Cost/benefit
• Organizational impact• Training, retraining, cross-training, collaboration
• New capabilities• Consumer engagement
• Regulatory mandates
• Enable retirement of legacy systems© Copyright 2016 Project Consultants, LLC
87
Building Out the Integration Environment
• CIM doesn’t care what you use
• The key is ownership • …of the information (including business process!)
• …of the technology
• Invest in growing the knowledge base around the standards
• Avoid having to grow the knowledge base around the legacy apps
© Copyright 2016 Project Consultants, LLC
88
Training – Training -- Training• Always hands-on in the context of the selected
toolchain(s)
• Information modeling concepts and the standards themselves
• Information requirements• Business process
• Security
• Deltas to the standards• Your differentiators
• Adaptation tactics
• Tailored Personnel Training (all groups/departments) – IT, OT, Business Units, Management
© Copyright 2016 Project Consultants, LLC
89
The rest is program scope and planning• Standards adoption is transformative
• Even more so organizationally than technologically
• Investment is front-loaded• Pipeline projects for cumulative value and
quickest benefits• Milestones• Success criteria• Plan the investment stream• This is a multi-year effort
© Copyright 2016 Project Consultants, LLC
Enterprise Architecture (EA) Best PracticesProtecting yourself …. From yourself
Start with the stakeholder’s perspective, not a vendor’s or developer’s perspective. EA is all about ensuring you know why this is important
• Choose a methodology
• Use the appropriate tool
• Use a Service-oriented approach
• Keep your architecture at a consistentlevel of abstraction
• Quality attribute (nonfunctional)requirements are constraints acquired by a service
• Start with a more abstract diagram and decompose it in another diagram. Keep it small, if it doesn’t fit on one page … parse it into to “digestable” parts
Why Enterprise Architecture (EA)Protecting yourself …. From yourself
ArchitecturalProcess
Input Output
First in first out/Priority of the day
Logical – but … ?
OR
Yes, it’s a
Kitchen/
Bathroom
TOGAF Architecture capabilities - PhasesRather then trying to “eat an elephant all at once”,
architecture identifies goals and decomposes them into
services that ultimately relate to the physical entities
This breaks-down into:• Preliminary, what do you have• Vision, what goals you trying to achieve• Requirements, what needs do the goals, and
regulations impose• Business Services, what abstracted services
are needed to support a requirement• Information (or Application) Services, what
sort of applications and interfaces are needed to support the business service
• Technical Service (or Physical), what kind of thing is actually performing the service
• Implementation Service, who is performing the work
G.Implementation
Types of ArchitectureCIM Use Cases
NIST Conceptual
Logical (TOGAF) ArchiMate* for Remote Access UC example
Why must we doing this?
Who & how is this going to be accomplished?
What type of applications are needed?
What type of ICT is needed?
What physical equipment is involved?
* ArchiMate is an Open Group modelling tool
Vendor offering mapped to UC Logical architecture
GAP
GAP
Logical Vendor Offering Alignment to Use Case (sample UC UML mapping not created)
UML Sequence Diagram
Vendor supported Sequence
97
Physical Application Mapping to Data Architecture
• CIM!
• But not just CIM – linking CIM to architecture
application Phase C
MR-MS OMS
End Device Event
ActivityRecord
Metering::EndDev iceEv ent
+ issuerID: String
+ issuerTrackingID: String
+ userID: String
Outage Analysis
«trace»
© Copyright 2016 EPRI, Inc.
98
62325 Part ??
CIM for Environmental Data
98
99
CIM for Environmental Data
• Use of environmental data is pervasive in utilities• Load forecasting• Pre-storm resource deployment • Restoration• Root cause analysis (lightning strikes)• Litigation
• Current utility picture• Many sources (some external, some internal)
• Procurement silos (multiple providers on department-by-department basis)
• Multiple formats • Manual correlation, communication and data entry within the
utility
99
100
CIM for Environmental Data
• Internal to the utility
• Envisions a Environmental Data Service
100
101
Data Domains
Space
Hydrospheric
Geospheric
Atmospheric
• High Level Data Organization
Data Model Overview
101
CIM for Environmental Data
102
102class Env ir onmenta lOv er v iew
IdentifiedObject
Common::Loca t ion
Env ir onmenta lAler tEnv ir onmenta lDa taP r ov ider
IdentifiedObject
Common::Or ganisa t ion
IdentifiedObject
Common::Act iv ity Recor d
Obser v a t ion For ecast
IdentifiedObject
Env ir onmenta l Informat ion
Env ir onmenta lPhenomenon
IdentifiedObject
Assets::Asset
IdentifiedObject
Common::Or ganisa t ionRole
Env ir onmenta lEv ent
IdentifiedObject
Mar ketCommon::
Env ir onmenta lMonitor ingSta t ion
IdentifiedObject
Meter ing::UsagePoint
Env ir onmenta lDa taAuthor ity Env ir onmenta lLoca t ionK ind
Analog
Env ir onmenta lAna log
StringMeasurement
Env ir onmenta lSt r ingMeasur ement
Discrete
Env ir onmenta lDiscr ete
+Assets 0..*
+ActivityRecords 0..*
+EnvironmentalMonitoringStation
0..*
+Location 0..1
+EnvironmentalPhenomenon
0..*
+EnvironmentalLocationKind
0..*
+EnvironmentalPhenomenon 0..*
+EnvironmentalInformation 0..1
+EnvironmentalLocationKind 0..*
+Location 0..1
+EnvironmentalAnalog
0..*
+EnvironmentalInformation
0..1
+EnvironmentalAnalog
0..*
+EnvironmentalMonitoringStation
0..1
+EnvironmentalStringMeasurement0..*
+EnvironmentalInformation
0..1
+EnvironmentalAlert
0..*+EnvironmentalDataProvider
0..1
+Assets
0..* +Location
0..1
+EnvironmentalDiscrete
0..*
+EnvironmentalInformation
0..1
+EnvironmentalMonitoringStation0..1
+UsagePoint0..*
+EnvironmentalInformation
0..*
+EnvironmentalDataProvider
0..1
+Roles 0..*
+Organisation 0..1
+EnvironmentalAlert 0..*
+EnvironmentalLocationKind 1..*
+EnvironmentalEvent 0..*
+EnvironmentalInformation
0..*
103
CIM for Environmental Data
• Quick History• Project started by Southern California Edison• Initial work coordinated by EPRI• Have had significant participation from utility IT,
meteorology staff, vendors, weather data providers
• Status• Significant work on profiles, especially Observation &
Forecast• In latest merged CIM UML• UML included in next 62325-301
103
Top Related