Integrating Utility Operations and Business Management _ERP_

Integrating Utility Operations and Business Management (ERP)Copyright 2000, Systems Integration Specialists Company, Inc. All Rights ReservedHow to Exchange Information withTopics to be Covered•Why Integrate?•Why ERP?•The Integration Issues•Resolution–OAG–XML Messages–CCAPIWhy Integrate (Use Case)The CustomerUtilities Provide:PowerTertiary ServicesRestoration and Repair ServicesContractedServicesRequiresContracted Service FailureCustomer Service(CIS)UpsetCustomerPlanningFinancialMaterialsCallRequestWorkOrderServiceRestorationHappier CustomerWork CompletionERPOther ReasonsUtilities 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 SchemasMFGSerial NumberTest ResultsCertificationDate of ProductionRatingDISTUtilityOrder for RestockingCauses Relay to ShipPrice ChargedDate of MFG ShipMFGSerial NumberDate Rxd’dCostOrder to DISTDate of DIST ShipPrice ChargedMFGDISTSerial NumberPriceDate of DeliveryInheritedDifferent Information Even in UtilityWHSEMFGDISTSerial NumberPriceDate of DeliveryTest ResultsCertificationDate of ProductionRatingConfigurationMFGSerial NumberRatingInit. Test ResultsDate in ServiceLocationReferenceCCTelemetryDate in ServiceLocationReferenceRatingCC ReferenceWarehouseSubstationEngineeringControl CenterDifferent Information Even in UtilityWHSEMFGDISTSerial NumberPriceDate of DeliveryTest ResultsCertificationDate of ProductionRatingConfigurationMFGSerial NumberRatingInit. Test ResultsDate in ServiceLocationReferenceMaint.MFGSerial NumberRatingProblem {LocationProblem Desc.Date of Maint.Resolution}[ ]Current LocationTest Results [ ]Config[ ]Where did ERP come From?First there was paper!HumanResourcesProductionOrderEntryThen Came:HumanResourcesOrderEntryProduction PlanningMRPThen came ERPHuman ResourcesWorkflowFinancial AccountingMaterials ManagementSales and DistributionFixed Asset ManagementOthers.....IndustrySolutionsInternally?MetaDataDatabase* MetaData* Instance* DataRulesInterfacesSimilar to EMS’sInformation Exchange by:•Manual Entry•Proprietary Interfaces–No two vendor’s interfaces the same•EDI–Batch mode typically•OthersWrappering 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 SolutionsOAG MembershipOAG Information•http://www.openapplications.org/–OAMAS -Interface Specification/Architecture–XML -Schema and Messages•122 Messages currently defined (BODs)•26 Other Messages under ConsiderationSample Messages•Sync Customer•Sync Supplier•Process PO•Update Delivery •Load invoice•Post Journal •Sync Salesorder•Sync Item•Sync Inventory•Add Requisition•Load PayableExample DTDXML Support being Announced•SAP•Peoplesoft•IBM•OracleOAG Does Not SpecifyHow 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 supportedNo Nirvana Yet!CIM/ERP MetaData MismatchPublic/Private Data IssuesPolitical IssuesStandardized Interface NeededServiceTransformation* Publish/Subscribe*Request/ResponseMetaData/DataTransformationAdapters/Wrappers still Needed!Message Bus must support:•Publish/Subscribe•Request/Response•Publish Request/Directed Response•Alarming/Transactions/Events•Standardized APIWhy 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.PublishingAppPublishingAppPublish/Subscribe ModelPublishingAppMessage BusABCDDESubscribingAppABSubscribingAppACSubscribingAppADSubscribingAppABCEHow 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 servicesPossible ArchitectureCORBA or DCOMUtility ApplicationsUtility Specific Services and SpecificationsAPPLICATIONUTILITY COMMON SERVICESOFF THE SHELF MIDDLEWAREArchitectural features•Can be run over different middleware implementations •Allows for direct access to middleware•Provides an environment for integration of utility applicationsRequirements of Middleware •Persistent Message Queuing•Life cycle Services•Transaction Services•Security Services•Other standard distributed objects servicesWhy 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 applicationsOwnerBilling AddressRate StructureUsageMeterIDLastCalibrationAn Object Instance (e.g. SISCOMeter)Typical Middleware SolutionFromIndependentSourcesAggregate orProxy ObjectInstanceCORBA or DCOMUtilities really need: Decomposed ObjectsCORBA or DCOMAttributes directlyavailable frommultiple sources.This requirement has several design impacts!Example: Information in Legacy ApplicationsAMR/ERPDBCISMaintenanceSISCOMeterMessaging TechnologyXML Messaging AllowsIIOPNotif.CORBAJMSEJBDCOMCOMLegacyC, C++Integration of Various Technologies without Object GatewaysMessages need to be exchangedThrough 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 architectureApplicationProprietaryOTSConnectorSupplied by SISCO or othersSupplied by Neon, Tibco, TSI, Oberon, Oracle, etc.GIDGIDEMS/DMSConnectorXML MessagesTransportSupplied 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 GroupGID 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 neutralCCAPI and IEC leadership have agreed.Messaging TechnologyGID and Messaging AllowsDCOMSQLLegacyCORBAEJBGIDIIOPNotif.JMSCOMC, C++WrapMetadata and DataBOD’s and BeyondEPRI Common Information Model(CIM)Standardizes the Data ModelsCommon 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 dataMeasurement 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 Standardization•Status and Control:–IEC is Harmonizing between UCA, ICCP/TASE.2, and CIM•Quality Codes–Recommend IEC 61850-7-3 definitions.•Time Base: GMTNow Possible to Integrate!•Adoption of OAG Architecture•Adoption of B2B and OAG XML Messages•Development and Standardization of Utility specific XML messages.•Standardization at IECMessages and Data are the key!•Scaleable beyond current Distributed Object technologies.•Technology Neutrality•Minimizes API requirements.For Further InformationHerbert FalkSystems Integration Specialists Company6605 19½ Mile RoadSterling Heights, MI 48314Ph: 586-254-0020, Fx: 586-254-0053URL: http://www.sisconet.comEmail: herb@sisconet.comElectronic Copy of Presentation: http://www.sisconet.com/uib.htm