Integrating Utility Operations

normaldeerΔιαχείριση

20 Νοε 2013 (πριν από 3 χρόνια και 9 μήνες)

79 εμφανίσεις

Integrating Utility Operations
and Business Management
(ERP)



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

How to Exchange
Information with

Topics to be Covered


Why Integrate?


Why ERP?


The Integration Issues


Resolution


OAG


XML Messages


CCAPI


Why Integrate (Use Case)

The Customer

Utilities Provide:

Power

Tertiary Services

Restoration and

Repair Services

Contracted

Services

Requires

Contracted Service Failure

Customer Service

(CIS)

Upset

Customer

Planning

Financial

Materials

Call

Request

Work


Order

Service



Restoration

Happier

Customer

Work Completion

ERP

Other Reasons

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


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 Schemas

MFG

Serial Number

Test Results

Certification

Date of Production

Rating

DIST

Utility

Order for Restocking

Causes Relay to Ship

Price Charged

Date of MFG Ship

MFG

Serial Number

Date Rxd’d

Cost

Order to DIST

Date of DIST Ship

Price Charged

MFG

DIST

Serial Number

Price

Date of Delivery

Inherited

Different Information Even in
Utility

WH

SE

MFG

DIST

Serial Number

Price

Date of Delivery

Test Results

Certification

Date of Production

Rating

Configuration

MFG

Serial Number

Rating

Init. Test Results

Date in Service

Location

Reference

CC

Telemetry

Date in Service

Location

Reference

Rating

CC Reference

Warehouse

Substation

Engineering

Control Center

Different Information Even in
Utility

WH

SE

MFG

DIST

Serial Number

Price

Date of Delivery

Test Results

Certification

Date of Production

Rating

Configuration

MFG

Serial Number

Rating

Init. Test Results

Date in Service

Location

Reference

Maint.

MFG

Serial Number

Rating

Problem {


Location


Problem Desc.


Date of Maint.


Resolution


}[ ]

Current Location

Test Results [ ]

Config[ ]

Where did ERP come From?

First there was paper!

Human

Resources

Production

Order

Entry

Then Came:

Human

Resources

Order

Entry

Production

Planning

MRP

Then came ERP

Human Resources

Workflow

Financial Accounting

Materials Management

Sales and Distribution

Fixed Asset Management

Others.....

Industry

Solutions

Internally?

MetaData

Database

* MetaData

* Instance

* Data

Rules

Interfaces

Similar to EMS’s

Information Exchange by:


Manual Entry



Proprietary Interfaces


No two vendor’s interfaces the same



EDI


Batch mode typically



Others

Wrappering of Proprietary
Interface


Oracle



TSI Software



IBM



Etc...

No Common Messages or Interfaces
-

$$$

Enter Open Access Group
(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 Membership

OAG Information


http://www.openapplications.org/



OAMAS
-

Interface Specification/Architecture



XML
-

Schema and Messages


122 Messages currently defined (BODs)


26 Other Messages under Consideration

Sample Messages


Sync Customer


Sync Supplier


Process PO


Update Delivery


Load invoice


Post Journal


Sync Salesorder


Sync Item


Sync Inventory


Add Requisition


Load Payable


Example DTD

XML Support being
Announced


SAP



Peoplesoft



IBM



Oracle

OAG Does Not Specify

How to Exchange XML!

Parallel Activities Yield Similar
Results


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!

CIM/ERP MetaData Mismatch

Public/Private Data Issues

Political Issues

Standardized Interface Needed

Service

Transformation

* Publish/Subscribe

*Request/Response

MetaData/

Data

Transformation

Adapters/Wrappers still
Needed!

Message Bus must support:


Publish/Subscribe



Request/Response



Publish Request/Directed Response



Alarming/Transactions/Events



Standardized API

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.


Publishing

App

Publishing

App

Publish/Subscribe Model

Publishing

App

Message Bus

A

B

C

D

D

E

Subscribing

App

A

B

Subscribing

App

A

C

Subscribing

App

A

D

Subscribing

App

A

B

C

E

How to Construct a Message
Bus?

A Message Bus is:


A set of middleware requirements



A set of middleware use specifications



A set of utility specific services



Possible Architecture

CORBA or DCOM

Utility
Applications

Utility Specific
Services and
Specifications

APPLICATION

UTILITY COMMON SERVICES

OFF THE SHELF MIDDLEWARE

Architectural 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


Persistent Message Queuing


Life cycle Services


Transaction Services


Security Services


Other standard distributed objects services

Why not just use Middleware?

Answer: Utilities need more!

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

Usage

MeterID

Last

Calibration

An Object Instance (e.g. SISCOMeter)

Typical Middleware Solution

From

Independent

Sources

Aggregate or

Proxy Object

Instance

CORBA or DCOM

Utilities really need:
Decomposed Objects

CORBA or DCOM

Attributes directly

available from

multiple sources.

This requirement has several design impacts!

Example: Information in Legacy Applications

AMR/ERP

DB

CIS

Maintenance

SISCOMeter

Messaging Technology

XML Messaging Allows

IIOP

Notif.

CORBA

JMS

EJB

DCOM

COM

Legacy

C, C++

Integration of Various Technologies without Object Gateways

Messages need to be exchanged

Through Standard Interface!

The Generic Interface
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 architecture

Application

Proprietary

OTS

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

DCOM

SQL

Legacy

CORBA

EJB

GID

IIOP

Notif.

JMS

COM

C, C++

Wrap

Metadata and Data

BOD’s and Beyond

EPRI Common

Information Model

(CIM)

Standardizes the Data Models



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


IEC indicates a
preference for SI units.


One Conversion per
application



HMI units display a
local issue.

$185M of Problems

if not addressed!

Data Definition
Standardization


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!


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!


Scaleable beyond current Distributed Object
technologies.



Technology Neutrality



Minimizes API requirements.

For Further Information

Herbert Falk

Systems Integration Specialists Company

6605 19½ Mile Road

Sterling Heights, MI 48314

Ph: 586
-
254
-
0020, Fx: 586
-
254
-
0053

URL: http://www.sisconet.com

Email: herb@sisconet.com

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