Integrating Utility Operations Integrating Utility Operations and Business Management and Business Management

(ERP)(ERP)

Copyright 2000, Systems Integration Specialists Company, Inc. All Rights Reserved

How to Exchange How to Exchange Information withInformation with

Topics to be CoveredTopics to be Covered

• Why Integrate?

• Why ERP?

• The Integration Issues

• Resolution– OAG– XML Messages– CCAPI

Why Integrate (Use Case)Why Integrate (Use Case)

The Customer

Utilities Provide:Utilities Provide:

Power

Tertiary Services

Restoration and Repair Services

ContractedContractedServicesServices

Requires

Contracted Service FailureContracted Service Failure

Customer Service(CIS)

UpsetCustomer

Planning

Financial

Materials

Call Request

Work

Order

Service

Restoration

Happier Customer Work Completion

ERPERP

Other ReasonsOther Reasons

Utilities Have:Utilities Have:• Normal Business Concerns (e.g.

Accounting, warehousing, ERP, etc...).

• Government, public, and business ramifications for failure to deliver.

• Government Regulations for audibility beyond pharmaceuticals.– Environment, service delivery, power quality,

etc...

Utilities Have (cont.)Utilities Have (cont.)

• Wide Geographic delivery areas– Infrastructure is distributed– Equipment installed and maintained for 30 years or

more.

• Uncertain business models– Deregulation– High Merger Rate

• High throughput requirements greater than financial applications.

Different Information SchemasDifferent Information Schemas

MFG

Serial NumberTest ResultsCertificationDate of ProductionRating

DIST

Utility

Order for RestockingCauses Relay to Ship

Price ChargedDate of MFG Ship

MFGSerial NumberDate Rxd’dCost

Order to DIST

Date of DIST ShipPrice Charged

MFGDISTSerial NumberPriceDate of Delivery

Inherited

Different Information Even in Different Information Even in UtilityUtility

WH SE

MFGDISTSerial NumberPriceDate of DeliveryTest ResultsCertificationDate of ProductionRating

ConfigurationMFGSerial NumberRatingInit. Test ResultsDate in ServiceLocationReference

CC

TelemetryDate in ServiceLocationReferenceRatingCC Reference

Warehouse SubstationEngineering

Control Center

Different Information Even in Different Information Even in UtilityUtility

WH SE

MFGDISTSerial NumberPriceDate of DeliveryTest ResultsCertificationDate of ProductionRating

ConfigurationMFGSerial NumberRatingInit. Test ResultsDate in ServiceLocationReference

Maint.

MFGSerial NumberRatingProblem { Location Problem Desc. Date of Maint. Resolution

}[ ]Current LocationTest Results [ ]Config[ ]

Where did ERP come From?Where did ERP come From?

First there was paper!First there was paper!

HumanResourcesProduction

OrderEntry

Then Came:Then Came:

HumanResources

OrderEntry

Production Planning

MRP

Then came ERPThen came ERP

Human ResourcesWorkflowFinancial AccountingMaterials ManagementSales and DistributionFixed Asset ManagementOthers.....

IndustrySolutions

Internally?Internally?

MetaData

Database* MetaData* Instance* Data

Rules

InterfacesSimilar to EMS’s

Information Exchange by:Information Exchange by:

• Manual Entry

• Proprietary Interfaces– No two vendor’s interfaces the same

• EDI– Batch mode typically

• Others

Wrappering of Proprietary Wrappering of Proprietary InterfaceInterface

• Oracle

• TSI Software

• IBM

• Etc...

No Common Messages or Interfaces - $$$

Enter Open Access Group Enter Open Access Group (OAG)(OAG)

• Consortium of ERP Vendors

• Charter to define information Exchange between business applications

• Architecture has been defined

• XML messages defined for exchange

• American Software, Inc.• AT&T Wireless• Bluestone• CANDLE Corp.• Compaq• Component Software• Computer Associates• CrossWorlds Software• DATEV eG• Extricity Software• Ford Motor • Fortress Technologies• GloTech Solutions• Great Plains• HK Systems• I2• IBM Adv. Mfg. Solutions Unit• Indus International• Integrated Systems & Services• J.D. Edwards• Lockheed Martin• Lucent Technologies• Microsoft

• NEC Corporation• Netfish• ObTech• OnDisplay• Oracle Corporation• PCS• PeopleSoft, Inc.• PricewaterhouseCoopers• PSDI, Inc. • QAD, Inc.• Requisite• Robocom Systems Intl.• SAGA Software• SAP AG• Teklogix• Trilogy• TSI• USData• Vitria• Wonderware• webMethods• XML Solutions

OAG MembershipOAG Membership

OAG InformationOAG Information

• http://www.openapplications.org/

– OAMAS - Interface Specification/Architecture

– XML - Schema and Messages• 122 Messages currently defined (BODs)

• 26 Other Messages under Consideration

Sample MessagesSample Messages

• Sync Customer• Sync Supplier• Process PO• Update Delivery • Load invoice• Post Journal • Sync Salesorder• Sync Item• Sync Inventory• Add Requisition• Load Payable

Example DTDExample DTD

XML Support being XML Support being AnnouncedAnnounced

• SAP

• Peoplesoft

• IBM

• Oracle

OAG Does Not SpecifyOAG Does Not Specify

How to Exchange XML!

Parallel Activities Yield Similar Parallel Activities Yield Similar ResultsResults

• EPRI CCAPI Project– Message based information exchange supported

– XML Messages being defined

– Power System Metadata Defined• EPRI/IEC Common Information Model

– OAG Architecture being supported

No Nirvana Yet!No Nirvana Yet!

CIM/ERP MetaData Mismatch

Public/Private Data Issues

Political Issues

Standardized Interface Needed

ServiceTransformation

* Publish/Subscribe*Request/Response

MetaData/Data

Transformation

Adapters/Wrappers still Adapters/Wrappers still Needed!Needed!

Message Bus must support:Message Bus must support:• Publish/Subscribe

• Request/Response

• Publish Request/Directed Response

• Alarming/Transactions/Events

• Standardized API

Why Publish/Subscribe?Why Publish/Subscribe?

• Decouples applications from the data sources.• Sources of data do not need to be configured with the

destination of data.

• Allows for the creation of redundancy and fault tolerance.

• Reduces overhead of communications.

PublishingPublishingAppApp

PublishingPublishingAppApp

Publish/Subscribe ModelPublish/Subscribe Model

PublishingPublishingAppApp

Message BusMessage Bus

AA BB CC DD DD EE

SubscribingSubscribingAppApp

AA BB

SubscribingSubscribingAppApp

AA CC

SubscribingSubscribingAppApp

AA DD

SubscribingSubscribingAppApp

AA BB CC EE

How to Construct a Message How to Construct a Message Bus?Bus?

A Message Bus is:A Message Bus is:

• A set of middleware requirements

• A set of middleware use specifications

• A set of utility specific services

Possible ArchitecturePossible Architecture

CORBA or DCOM

Utility Applications

Utility Specific Services and

Specifications

APPLICATION

UTILITY COMMON SERVICES

OFF THE SHELF MIDDLEWARE

Architectural featuresArchitectural features

• Can be run over different middleware implementations

• Allows for direct access to middleware

• Provides an environment for integration of utility applications

Requirements of Middleware Requirements of Middleware

• Persistent Message Queuing

• Life cycle Services

• Transaction Services

• Security Services

• Other standard distributed objects services

Why not just use Middleware?Why not just use Middleware?

Answer: Utilities need more!

Utility Objects are:Utility Objects are:

• Many different types

• Are long lived (ie monitored continually instead of short live transactions)

• Attributes are distributed in existing legacy applications

Owner Billing Address

Rate Structure

UsageMeterID

LastCalibration

An Object Instance (e.g. SISCOMeter)An Object Instance (e.g. SISCOMeter)

Typical Middleware SolutionTypical Middleware Solution

FromIndependent

Sources

Aggregate orProxy Object

Instance

CORBA or DCOM

Utilities really need: Utilities really need: Decomposed ObjectsDecomposed Objects

CORBA or DCOM

Attributes directlyavailable frommultiple sources.

This requirement has several design impacts!

Example: Information in Legacy ApplicationsExample: Information in Legacy Applications

AMR/ERP

DBCIS

MaintenanceSISCOMeter

Messaging Technology

XML Messaging AllowsXML Messaging Allows

IIOP

Notif.

CORBA

JMS

EJB DCOM

COM

Legacy

C, C++

Integration of Various Technologies without Object Gateways

Messages need to be exchangedMessages need to be exchanged

Through Standard Interface!

The Generic Interface The Generic Interface Definition (GID)Definition (GID)

• A standardized API to used to wrap applications and middleware.

• GID gives customers and application developers a greater independence from proprietary or specific broker/messaging implementations.

• Lowers cost of wrapper deployment.

Open messaging and adapter architectureOpen messaging and adapter architecture

Application

ProprietaryOTS

Connector

Supplied by SISCO or others

Supplied by Neon, Tibco, TSI, Oberon, Oracle, etc.

GID GID

EMS/DMS

Connector

XML Messages

Transport

Supplied by SAP, Peoplesoft, Siemens, Telegyr, Alstom,

Oracle, etc….

The GID - An open approachThe GID - An open approach

• SISCO, partners, CCAPI, and IEC are actively working on defining the GID

• Goal is to make the GID an IEC standard

• GID complements the work being done in the Open Applications Group

GID based on OAG ConceptsGID based on OAG Concepts• OAG work is technology neutral

– allows mappings to CORBA, JMS, and COM

• Architecture separates content from interface:– Business Object Documents

• Nouns, Verbs, Business Data Area

– Interface is content neutral

CCAPI and IEC leadership have agreed.

Messaging Technology

GID and Messaging AllowsGID and Messaging AllowsDCOM SQLLegacyCORBA EJB

GID

IIOP

Notif.

JMS COM C, C++ Wrap

Metadata and DataMetadata and Data

BOD’s and Beyond

EPRI Common EPRI Common Information ModelInformation Model

(CIM)(CIM)Standardizes the Data Models

Common ModelCommon Model

• Provides a base for application integration and higher level applications

• Future standards work will leverage the CIM

• Tools available to centrally manage the meaning and location of data

Measurement Units?Measurement Units?

• IEC indicates a preference for SI units.– One Conversion per

application

– HMI units display a local issue.

$185M of Problemsif not addressed!

Data Definition Data Definition StandardizationStandardization

• Status and Control:– IEC is Harmonizing between UCA,

ICCP/TASE.2, and CIM

• Quality Codes– Recommend IEC 61850-7-3 definitions.

• Time Base: GMT

Now Possible to Integrate!Now Possible to Integrate!

• Adoption of OAG Architecture

• Adoption of B2B and OAG XML Messages

• Development and Standardization of Utility specific XML messages.

• Standardization at IEC

Messages and Data are the key!Messages and Data are the key!

• Scaleable beyond current Distributed Object technologies.

• Technology Neutrality

• Minimizes API requirements.

For Further InformationFor Further Information

Herbert FalkSystems Integration Specialists Company6605 19½ Mile RoadSterling Heights, MI 48314Ph: 586-254-0020, Fx: 586-254-0053URL: http://www.sisconet.comEmail: herb@sisconet.com

Electronic Copy of Presentation: http://www.sisconet.com/uib.htm