Utility Integration Bus Architecture (and Implementation) the KCPL CIM / UIB Project EMS Users Group...

Utility Integration Bus Architecture

(and Implementation)

the KCPL CIM / UIB Project

EMS Users GroupJune, 1999Pat Brown, KCPLJohn Kishpaugh, KCPL

1997 EMS Users Group presentation

– the KCPL integration problem

– the progress of electric utility standards– the promise of distributed object

technology

“A fascinating intersection of industry readiness and technology readiness”

KCPL CIM / UIB Project

high quality becoming commonly used?

our standards are...our standards are...

allows software and data to be spread across platforms

that 5-letter “C” word... CORBA(Common Object Request Broker Architecture)that 5-letter “C” word... CORBA(Common Object Request Broker Architecture)

Electric Utility Software StandardsElectric Utility Software Standards a fascinating intersection...Electric Utility Software StandardsElectric Utility Software Standards a fascinating intersection...



– designing solutions with electric utility standards

– and distributed object technology

“Why we’re using an integration bus”


the KCPL Business Solution: the KCPL Technical Problem

CIMDatabase

Desktop Access

DFMSDistribution

Facilities Management

System

EMSEnergy

Management System

Power PoolICCP

Maintenance Management

System

Real-Time Data

HistorianSubstation

Automation

the KCPL Technical Solution

CIMDatabase

Desktop Access

DFMSDistribution

Facilities Management

System

EMSEnergy

Management System

Power Pool

ICCP

Maintenance Management

System

Real-Time Data

Historian

Substation Automation

Utility Integration Bus



– the key architectural concepts of the Utility Integration Bus, an electric utility standard integration framework using distributed object technology

“What is the Utility Integration Bus?”


An integration of 4 control center applications, that supports:– data sharing

• real-time• electrical system model• one-line display data

– remote requests• supervisory control

KCPL CIM / UIB Project Overview

EMSEnergy

ManagementSystem

Trans& Power

Operators

real-time “point” dataelectrical system model info

supy control requests

RTUs

CIM / UIB Project Applications Integrated

EMSEnergy

ManagementSystem

DFMSDistribution

FacilitiesManagement

System

DistributionOperators

CADS

real-time “point” data

display infoelectrical system model info


Trans& Power

OperatorsRTUs


EMSEnergy

ManagementSystem

KCPL-wideDesktopAccess

TOMTransmissionOperations

Modeldatabase

DFMSDistribution


System


CADS




Trans& Power

OperatorsRTUs


EMSEnergy

ManagementSystem


Power Pool

ICCPInter-Control Center

CommunicationsProtocolpackage


Modeldatabase

DFMSDistribution


System


CADS




Trans& Power

OperatorsRTUs


EMSEnergy

ManagementSystem

Utility Integration Bus (UIB)


Power Pool

KCPL CIM/UIB Project Overview

DFMS/UIB Interface




Modeldatabase

DFMSDistribution


System


CADS

TOM/UIB Interface

ICCP/UIB Interface

EMS/UIB Interface

Trans& Power

OperatorsRTUs

1996 - selling the project 1997 - designing the bus

KCPL CIM/UIB Project Timeline

1998 - implementing the simple bus 1999 - deploying the first simple bus 2000 - sending out the SISCO fleet??

Observations: EVERYTHING takes longer than you expect being standards-based is worth the pain

Review of integration strategies Key UIB design concepts

CIM/UIB Project UIB Philosophies

Possible Integration Strategies

•Point-to-point interfaces1 interface per source/destination pair

•Central Database1 interface between each application and the database

cleaner, but leads to the database “kitchen sink” problemno support of application-to-application interaction

solves short term problem, but each subsequent application addition becomes more difficult

The Integration Framework Strategy

•Integration Bus1 interface between each application and the integration framework

Observation: integration frameworks make integration easier,

not easy

applications are autonomousinterface to bus is standardshared data is modeled and is extensible

The integration problem– stand-alone applications– sharing info about / making requests related to

business objects

CIM/UIB Project UIB Key Concept #1

Application A Application B Application C

businessobjects

CIM/UIB Project UIB Key Concept #2 Data sharing

– is done by announcements of changes related to business objects called events

– which are passed over the bus from a supplier application to one or more consumer applications

Application A(supplier)

Application B(consumer)

Application C(consumer)

x

X

x x


Application A(server)

Application B(client)

Application C

x

X

x

Inter-application communication– is accomplished via business object-related

request / replies– requests are passed over the bus from one client

application to one server application

?




Application C

x

X

x

Inter-application communication– replies return information or acknowledgement to

the client

?


Application A(supplier)

Application B Application C

x

X

Applications are blissfully unaware of the identity of other applications– suppliers issue events to the bus

Application A Application B Application C(consumer)

x

Applications are blissfully unaware of the identity of other applications– consumers receive events from the bus


Application A Application B(client)

Application C

x

X?

Applications are blissfully unaware of the identity of other applications– clients make requests of the bus




Application C

x

X

x

?

Applications are blissfully unaware of the identity of other applications– except, perhaps, when servers reply


Applications are blissfully unaware of the identity of other applications– therefore, adding an application requires no

change to any existing application

Application A Application B Application C Application D

x

x


Application ASUPPORT

Application B Application C

Applications have roles– they can be event announcers and request

servers in their support role

x

x

X



Application BINTEREST

Application CINTEREST

Applications have roles– they can be event consumers and/or request

clients in their interest role

x

x xx

x

X X?



Application BSUPPORT/INTEREST

Application CINTEREST

Applications have roles– they can be both!

x

x xx

x

XX

?Y Y?

Y

Y

Y


Application A Application B Application C

Most applications have an internal model– and the job of the interface is to translate business

object information from the application’s internal model to the bus model (or vice versa)

interface interfaceinterface


When applications interact in any UIB deployment– the message package and the interaction

mechanics are the same– only the contents of the event or request package

change


UIB Deployment 1UIB Deployment 1

Application CApplication BApplication A

UIB Deployment 2UIB Deployment 2

Application ZApplication YApplication X


Information Exchange Model

Business objects– are modeled in an OO way– are described in classes that have attributes,

events and methods and relationships– have a model, the Information Exchange Model,

that is “understood” by the participating applications– whose reference can be a standard…like the CIM!

Class Foo

attribute1

method1

event1event2

Class FooToo

attribute1

event1event2event3


Adding to the interaction– requires modifications only to the business object

model and to involved / interested application interfaces

– does not affect existing applications that have no interest

Application A

interface

Application B

interface

Application C

interface

Information Exchange Model

Class Foo

Class FooToo

interfaceinterface


EMSEnergy

ManagementSystem

Utility Integration Bus (UIB)

Trans OpsModel


Power Pool


DFMS/UIB Interface




Modeldatabase

DFMSDistribution


System


CADS

TOM/UIB Interface

ICCP/UIB Interface

EMS/UIB Interface

Trans& Power

OperatorsRTUs

Utility Integration Bus Architecture (and Implementation) the KCPL CIM / UIB Project EMS Users Group...

Documents

Transcript of Utility Integration Bus Architecture (and Implementation) the KCPL CIM / UIB Project EMS Users Group...