cim university: track 1 afternoon session cim user’s group...

CIM University: Track 1 Afternoon SessionCIM User’s Group

June 13, 2017

• Margaret Goodrich• Principal Consultant, Project Consultants, LLC• Email: margaret@j-mgoodrich.com• Phone: 903-477-7176

• Pat Brown• Principal Technical Leader, EPRI• Email: pbrown@epri.com• Phone: 913-449-0736

• Gowri Rajappan• Director, Technology & Cybersecurity, Doble Eng• Email: grajappan@doble.com

• Phone: 617 926 4900 x2214

• Stephan Amsbary• Sr. Technical Leader, EPRI• Email: samsbary@epri.com• Phone: 828.559.1110

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

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.

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 ]

Meter Maintenanceand

Asset Management

MeterData

Management

CustomerInformation

andBilling

[ 20 ]

[ 15 ]

{ 14 }

[ 19 ]

[ 17 ]

{ 16 }

{ 11 }

Interface and protocol details of the Service Point are outside the scope of

IEC 61968-9

[ 21 ]

Planningand

Scheduling

[ 7 ][ 6 ]

[ 13 ]

[ 12 ]

{ 23 }

[ 22 ]

61968-3

61968-8

61968-5

[ 7 ][ 6 ]

[ 18 ]

[ 13 ]

{ 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

Pointof

61968-10

[ 12 ]

{ 14 }

LoadManagement

System

Load Analysis

Load Control

[ 10 ]

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 & assetchanges

Proposed normalchanges

Recommended normalchanges

Build SwitchingPlan

Substation

Device out &fault data

Metersdown

Device out &fault dataDevice Out

Device out

Energize

Switching Plan to energize

Fault location isolation stepsRestoration steps

AMI/MDM

OMS DMS

GIS Planning

Predict tooutage device Current

StateCurrent

NormalState

Normal State

Meter servicerequest

Meter serviceorder

Meter info &complete

status

Isolation Steps

FLISR = Fault Location, Isolation,

and Restoration

Scope:

A - Outage ManagementB - Network Model Synchronization

C - Maintenance

IEC61968 Scope

Workorder

Current State

Network Operations Scope (IEC 61968-Part 3)

Enterprise

Applications

Control Center Applications

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

defined by

relevant

standards or

vendors. May

use a wide

variety of

communication

technologies

[Part 8 –

Customer

Support]

AMI/MDM

[Part 9 – Meter

Reading &

Control]

[Part 5 –

Operational

Planning

Part 6 –

Maintenance &

Construction]

[Part 6 –

Maintenance &

Construction]

Part 3

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).

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.

Network Operations (Outage Management) Reference Model

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)

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.

IEC 61968-4: Vision

Aligns with ISO 55000 Asset Management Concepts

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.

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.

IEC 61968-4: Asset Model

IEC 61968-4: Measurements Model

IEC 61968-4: Analytics Model

IEC 61968-4: Asset Messages

IEC 61968-4: Measurements Messages

IEC 61968-4: Analytics Messages

• Information on CIMug SharePoint sitehttp://cimug.ucaiug.org/Focus_Comms/AssetHealth/

– UCAI UserID needed

Asset Health Focus Community

• Contact – Gowri Rajappan, grajappan@doble.com– Pat Brown, pbrown@epri.com

Enterprise DER IntegrationDeveloping 61968-5, MultiSpeak Support (2012-2014)

Sensors, Switches, Capacitors, Regulators

MDMS OMS

SOLAR BATTERY PEV

• Creation and management of

groups and sharing of group

definitions

• Monitoring of group status

• Dispatch of real and reactive

• Forecasting of group

capabilities

• Compliance Test – NREL

(2014)

Enterprise Integration

Report 3002001249 Enterprise Integration Functions for Distributed Energy Resources

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

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)

Status Monitoring PUSH

individual OpenFMB signals()

individual 61850 signals()

reply()

individual DNP3 control signals()

createDERGroupDispatches()

determine how to meet request()

DERMS enterprise…

DMS DERMS

…to DERMS “anywhere”

GIS OMS

DMS DERMS

Sensors, capacitors, switches

SCADA, Field Networks

DERMSSmart Inverter

DERMS Internal Architecture example

technology 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

Voltage

Regulation

Field NetworkEnterprise Network

Status

Monitoring

Maintenance

Forecast

Dispatch

OpenFMB Comms

IEC 61850 Comms

DNP3 Comms

IEEE 2030.5 Comms

Test case - 61868-5 Compliance /Interoperability Compliance Testing

Test Script for DERMS to GIS

Test Script for DERMS to DMS

Report 3002004681

Functions Test Plan for

Distributed Energy

Resources, Phase 1

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

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.

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

Customer Support

Customer Service

[ 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 ]

Records & Asset

Management (AM)

General Inventory

Management (GINV)

Equipment hierarchy

[ 13 ]

Work Mgt Planning

Materials

Management

Composition

[ 16 ]

61968 Part 6

[ 14 ]

{ 15 }

Scheduling & Dispatch

[ 13 ]

[ 10 ]

Maintenance & Construction

Maintenance and Inspection

(MC-MAI)

Preventive Maintenance

Conditional Maintenance

Meter Reading &

Control

(MR&C)

[ 17 ]

[ 18 ]

{ 19 }

[ 20 ]

[ 12 ]

[ 16 ]

[ 10 ]

[ 21 ]

[ 22 ]

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

Planned Maintenance Work Flow sd Carry out planned maintenance with temporary equipment

Part 6 - Maintenance

Construction::MC-MAI

«Work Sched & Di...

Construction::MC-SCHD

«Subst. & Network ...

Part 4 - Records and

Management::AM-EINV

«Geographic Inv.»

Part 4 - Records and

Management::AM-GINV

«Field Recording»

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)

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

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

Change-Out Meter Work Flow

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.

Customer Support Interface Reference Model

Part 8 Customer Support (CS)

Customer service (CSRV)

Trouble Call Management (TCM)

(3) Trouble Call Management

(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

Trouble Ticket Work Flow sd Trouble Ticket

CS-TCM

(from Approved Actors)

NO-FLT

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)

Incident Information Work Flow sd Incident Information

NO-FLT

CS-CSRV

Update(IncidentInformation)

Update associated trouble ticket()

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

Meter Reading and Control Scope

Enterprise

Applications

Head End

SystemsPAN

Device

Meter or

Gateway

Meter or

Gateway

Device

Utility

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

Area of Direct Impact

using IEC 61968-9

Area Causally/Indirectly

Impacted by or impacting

IEC 61968-9

Meter Reading and Control Reference Model

Service

Metering System

Data Collection

Control and

Reconfiguration

Readings, events

and status

Controls and signals

Management

Scheduled

Interface and protocol details of the

Service Point are outside the scope of

IEC 61968-9

Outside the scope of 61968

61968 Part 9

Scheduled

Tokens

Network

Operations

61968-3

Scheduled

Customer

Information

Billing

61968-8

Exchange

Portal

Scheduled

ReadPeak

Price (1)Load

Reduction

Price (1)

Reduction

Administration

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.

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

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

EndDeviceEvent Work Flow for Outage Detection Event

End Device Control Messages

• The EndDeviceControl message issues control commands related to:

• Load Control

• Demand Reset

• Connect/Disconnect

• Real-Time Pricing

EndDeviceControls Work Flow – Remote Disconnect

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.

MeterReadings Work Flow - Billing Inquiry

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.

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

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>

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

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

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.

Sample Interface Diagram

Sample Sequence Diagram -Connect/Disconnect

Sample Context Diagram -Connect/Disconnect

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

Testing Matrix

Device Pair

GWAC Layers

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

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

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

Scope of IEC 61968-100

• IEC 61968-100 focuses on message-based integration using transport technologies such as JMS and web services

Integration

Web Service

Client

Web Service

Service

WS - Direct Interaction w/o Integration Layer

Application

using JMS

Application

using JMS

JMS JMS

JMS – Direct integration using a JMS server

Client or Server

using another

integration

technology

C/SClient or Server

using another

integration

technology

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

Basic ESB Integration Patterns

Publish/Subscribe

Synchronous Request/Reply

Asynchronous Request/Reply

Point-to-Point (One Way)

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

Topic or

Request

JMS Interface

Topic or

Messaging

• 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

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

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).

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

Noun Example – Identifies Payload (EndDeviceEvents)

Example with Verbs and Nouns

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">

<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>

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!

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

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

RTY 345

INB 67433

MJG 222

ECV 555

GGG 225

Note: This is one example, there are many options

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

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!

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

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

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

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

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

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

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

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

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 … ?

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

Logical Vendor Offering Alignment to Use Case (sample UC UML mapping not created)

UML Sequence Diagram

Vendor supported Sequence

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»

62325 Part ??

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

• Internal to the utility

• Envisions a Environmental Data Service

Data Domains

Hydrospheric

Geospheric

Atmospheric

• High Level Data Organization

Data Model Overview

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

+Location 0..1

+EnvironmentalPhenomenon

+EnvironmentalLocationKind

+EnvironmentalPhenomenon 0..*

+EnvironmentalInformation 0..1

+EnvironmentalLocationKind 0..*

+Location 0..1

+EnvironmentalAnalog

+EnvironmentalInformation

+EnvironmentalAnalog

+EnvironmentalMonitoringStation

+EnvironmentalStringMeasurement0..*

+EnvironmentalAlert

0..*+EnvironmentalDataProvider

+Assets

0..* +Location

+EnvironmentalDiscrete

+EnvironmentalMonitoringStation0..1

+UsagePoint0..*

+EnvironmentalDataProvider

+Roles 0..*

+Organisation 0..1

+EnvironmentalAlert 0..*

+EnvironmentalLocationKind 1..*

+EnvironmentalEvent 0..*

• 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

cim university: track 1 afternoon session cim user’s group...

Documents

comms pg 2011

n comms

comms presentation[1]

dario consolato frazzetta entso-e use of cim cim@entso-e &...

comms 2000

cim cgmes applications in research projects for...

crisis comms presentation

open-source middleware platform for the data...

cim for asset management and analytics - home -...

dull to dazzling compliance comms | creative internal comms...

comms brochure

comms cymru13

comms app (basic comms) - mozilla · comms app (basic...

comms expt4

using owl for cim profiling -...

11 comms info_bl_final

etsi isg cim · [json-ld] 20170608 introduction to isg cim...

jeppview : eddh (43 charts) - virtualairlines.eu · d d d...

cim customer comms

data comms