| GISdevelopment.net ---> GITA 1999 ---> Enterprise Resource Planning |
Interfacing AM/FM/GIS with enterprise and Operations Systems
Bud Porter
AM/FM Solutions Manager, ESRI, Inc.
5216 Old Mountain Lane
Powder Springs, GA 30127
Bud Porter
AM/FM Solutions Manager, ESRI, Inc.
5216 Old Mountain Lane
Powder Springs, GA 30127
The Problem – Many Systems, No Connection
Energy utilities have historically implemented specialized engineering or operational support systems as departmental or even project solutions. Samples of systems implemented in this manner included Outage Management, Mobile Dispatch and Network Analysis systems. Stated another way, these were typically implemented as islands of automation with little connectivity to corporate mainframe systems.
In the 1990s, with the onset of deregulation and its resulting competition, utilities were faced with the problem of cutting operational costs and streamlining work processes. Modern information systems technology dictates a normalized approach, not only in data storage, but also in the applications themselves. That is, systems must not duplicate functions as well as data. In today’s competitive environment, utility companies cannot afford to have disparate systems that address only one or a few applications and that do not share data, nor communicate with other systems throughout the enterprise.
During this same recent timeframe, major AM/FM/GIS vendors have moved their solutions into the mainstream IT environment by making them easier to use and more compliant with emerging data storage and application development standards. They have also expanded their use throughout the enterprise by making the technology embeddable in other systems by using object-oriented, drag and drop techniques.
Also in the 1990s, a separate classification of software emerged that began replacing legacy mainframe applications in large corporate environments, including utility companies. This software is called Enterprise Resource Planning (ERP). None of these systems individually, however can handle all the corporate and departmental requirements of utilities. Therefore, it has become apparent that a utility must interface these disparate systems to eliminate redundant data and common functions. Until recently, the only way to accomplish this was to develop a custom interface between every system. This was very time consuming and expensive.
The Solution – Interfacing Standards
As an alternative to custom-developed interfaces, interfacing standards needed to be defined so that different systems could communicate with one another. In addition, data flows required between such systems would have to be packaged in such a way that vendors could pass information without restructuring or even revealing their proprietary data structures. Object-oriented programming techniques were the most obvious way to handle this interfacing dilemma. More specifically, Microsoft’s COM/DCOM architecture could be employed to facilitate communications.
One of the leading Enterprise Resource Planning (ERP) vendors, SAP, has developed their own interfacing methodology and has used it for some time to facilitate communications between its R/3 system and a wide variety of complimentary systems. This methodology is called the Business Application Programming Interface (BAPI). The figure below illustrates the structure of a BAPI and the business objects that it contains.
Figure 1 The Structure of SAP’s Business Object
SAP Business Components are comprised of a set of related SAP Business Objects that represent all of the functionality and behavior of the business entity. An SAP Business Object (Figure 1) consists of a business object kernel which contains the core business logic. The second layer contains constraints and business rules (responsible for integrity). The third layer contains the methods, input event control and output events. The final layer is the access layer (COM/DCOM, Java, and CORBA). DCOM enables COM software components to communicate directly over a network and is designed for use across multiple network transports. DCOM will work with Java applets and ActiveX components through its use of COM.
The Plan – Bringing Vendors Together
In an effort to avoid the time and expense of continually developing custom interfaces to other systems, ESRI, a leading GIS vendor, began a utility industry initiative it calls OpenFM. The goal of OpenFM is to bring together the leading vendors of three complimentary technologies with SAP and ESRI to build standard interfaces between their systems. The complimentary technologies include Outage Management, Mobile Data Dispatch and Network Analysis. The GIS component is ESRI’S AM/FM application called Arc Facilities Manager.
Each interface between complimentary technologies and GIS, as well as with SAP’s R/3 are being defined in generic terms. The interfaces are being built as ready-made, drop-in options that will require little or no customization by the implementing utility. The vendors have used use-case scenarios to define business objects that will be at the core of each interface. In addition, each interface design supports future integration for all vendors, and as a result will be an open standard. Once completed these interface designs will be published, so that other vendors not included in the original group can build interfaces to their own system using the OpenFM standards.
The Details – Building BAPIs
Using the Business Objects and BAPIs defined and developed in OpenFM by ESRI, SAP and key industry partners, an overall integrated solution is well within reach. The use of BAPIs will ensure that when two applications systems communicate with each other, the business-related information, such as the order details, customer number or facility ID, all use the same semantics. BAPIs can be seen as building on COM/DCOM or CORBA to offer interface technology for integrating SAP and non-SAP applications.
AM/FM/GIS
ESRI will interface with each of the complimentary technolo ies, as well as SAP, through its .$ AM/FM application called Arc Facilities Manager (ArcFM ). ArcFM is an ARC/INFO@ software-based application designed for editing, maintenance, modeling, and data management of utility information. ArcFM’s standard templates for utilities include a data model and business rules stored in a technology-independent data architecture. These standard templates and their respective data models will be used to develop the GIS BAPIs. The following diagram illustrates the location of BAPIs with respect to each of the technology components of OpenFM.
Figure 2 Block Diagram of Components of OpenFM and BAPI Interfaces
The Participants – Complimentary Technology Vendors
Each complimentary technology partner is contributing to the design of the business objects and BAPIs to complete the interface structure. The deliverables from the OpenFM Initiative include the following key components:
Network Analysis Systems Technology
Mobile Data Dispatch Technology
Outage Management Systems Technology
In addition to these vendors, PriceWaterhouseCoopers has provided a consultant at the OpenFM meetings to assist in BAPI and object model development. Their participation and extensive R/3 utility industry implementation experience has been a significant help to the other OpenFM participants.
Current Status – Building a Prototype
By the end of 1998 (and as of the writing of this paper), twenty-seven individual use-case scenarios had been identified and documented by the OpenFM participants. These describe the various situations within utility companies that require the systems to interface with each other. In addition, data flows between the systems were also identified and documented.
It was determined that a prototype be built that involved all systems and technologies. Therefore, three master use-cases were identified which combined situations from many of the individual use-cases. The result was that through these master use-cases, a high percentage of interface situations and data flows could be handled by creating their respective business objects and BAPI ‘s. One of these master use-cases was identified as the one to be used to build the interface prototype.
This master use-case involves: The reporting of an electrical outage by a customer; the instance being recorded by the Customer Care System; it being logged into and analyzed by the Outage Management System; a repair order dispatched through the use of the Mobile Data Dispatch System; the recording of field modifications in the AM/FM/GIS; and then running a resulting circuit analysis in the Network Analysis system. The following diagram represents the flows of this master use-case scenario.
The object definitions for all the interface elements for this master use-case have been defined and documented. By the end of January 1999, the participating vendors will code the first prototype OpenFM interfaces. PriceWaterhouseCoopers has agreed for the participants to use one of their lU3 Development Labs for this purpose. It is planned that by February, a complete, working prototype wilI be built and be demonstrable by the vendors.
Once this first prototype is complete, the participants will continue to build object definitions for all the other use-cases and will build the BAPIs for those as well. As OpenFM completes the definitions for these interfaces, they will be published so that other vendors can use them to build their own interfaces. If this process proves successful, with users and vendors adopting the OpenFM specifications, the same approach for integrating disparate systems will be expanded to other technologies and into other vertical markets.
Energy utilities have historically implemented specialized engineering or operational support systems as departmental or even project solutions. Samples of systems implemented in this manner included Outage Management, Mobile Dispatch and Network Analysis systems. Stated another way, these were typically implemented as islands of automation with little connectivity to corporate mainframe systems.
In the 1990s, with the onset of deregulation and its resulting competition, utilities were faced with the problem of cutting operational costs and streamlining work processes. Modern information systems technology dictates a normalized approach, not only in data storage, but also in the applications themselves. That is, systems must not duplicate functions as well as data. In today’s competitive environment, utility companies cannot afford to have disparate systems that address only one or a few applications and that do not share data, nor communicate with other systems throughout the enterprise.
During this same recent timeframe, major AM/FM/GIS vendors have moved their solutions into the mainstream IT environment by making them easier to use and more compliant with emerging data storage and application development standards. They have also expanded their use throughout the enterprise by making the technology embeddable in other systems by using object-oriented, drag and drop techniques.
Also in the 1990s, a separate classification of software emerged that began replacing legacy mainframe applications in large corporate environments, including utility companies. This software is called Enterprise Resource Planning (ERP). None of these systems individually, however can handle all the corporate and departmental requirements of utilities. Therefore, it has become apparent that a utility must interface these disparate systems to eliminate redundant data and common functions. Until recently, the only way to accomplish this was to develop a custom interface between every system. This was very time consuming and expensive.
The Solution – Interfacing Standards
As an alternative to custom-developed interfaces, interfacing standards needed to be defined so that different systems could communicate with one another. In addition, data flows required between such systems would have to be packaged in such a way that vendors could pass information without restructuring or even revealing their proprietary data structures. Object-oriented programming techniques were the most obvious way to handle this interfacing dilemma. More specifically, Microsoft’s COM/DCOM architecture could be employed to facilitate communications.
One of the leading Enterprise Resource Planning (ERP) vendors, SAP, has developed their own interfacing methodology and has used it for some time to facilitate communications between its R/3 system and a wide variety of complimentary systems. This methodology is called the Business Application Programming Interface (BAPI). The figure below illustrates the structure of a BAPI and the business objects that it contains.
Figure 1 The Structure of SAP’s Business Object
SAP Business Components are comprised of a set of related SAP Business Objects that represent all of the functionality and behavior of the business entity. An SAP Business Object (Figure 1) consists of a business object kernel which contains the core business logic. The second layer contains constraints and business rules (responsible for integrity). The third layer contains the methods, input event control and output events. The final layer is the access layer (COM/DCOM, Java, and CORBA). DCOM enables COM software components to communicate directly over a network and is designed for use across multiple network transports. DCOM will work with Java applets and ActiveX components through its use of COM.
The Plan – Bringing Vendors Together
In an effort to avoid the time and expense of continually developing custom interfaces to other systems, ESRI, a leading GIS vendor, began a utility industry initiative it calls OpenFM. The goal of OpenFM is to bring together the leading vendors of three complimentary technologies with SAP and ESRI to build standard interfaces between their systems. The complimentary technologies include Outage Management, Mobile Data Dispatch and Network Analysis. The GIS component is ESRI’S AM/FM application called Arc Facilities Manager.
Each interface between complimentary technologies and GIS, as well as with SAP’s R/3 are being defined in generic terms. The interfaces are being built as ready-made, drop-in options that will require little or no customization by the implementing utility. The vendors have used use-case scenarios to define business objects that will be at the core of each interface. In addition, each interface design supports future integration for all vendors, and as a result will be an open standard. Once completed these interface designs will be published, so that other vendors not included in the original group can build interfaces to their own system using the OpenFM standards.
The Details – Building BAPIs
Using the Business Objects and BAPIs defined and developed in OpenFM by ESRI, SAP and key industry partners, an overall integrated solution is well within reach. The use of BAPIs will ensure that when two applications systems communicate with each other, the business-related information, such as the order details, customer number or facility ID, all use the same semantics. BAPIs can be seen as building on COM/DCOM or CORBA to offer interface technology for integrating SAP and non-SAP applications.
AM/FM/GIS
ESRI will interface with each of the complimentary technolo ies, as well as SAP, through its .$ AM/FM application called Arc Facilities Manager (ArcFM ). ArcFM is an ARC/INFO@ software-based application designed for editing, maintenance, modeling, and data management of utility information. ArcFM’s standard templates for utilities include a data model and business rules stored in a technology-independent data architecture. These standard templates and their respective data models will be used to develop the GIS BAPIs. The following diagram illustrates the location of BAPIs with respect to each of the technology components of OpenFM.
Figure 2 Block Diagram of Components of OpenFM and BAPI Interfaces
The Participants – Complimentary Technology Vendors
Each complimentary technology partner is contributing to the design of the business objects and BAPIs to complete the interface structure. The deliverables from the OpenFM Initiative include the following key components:
- The document which defines the business objects and BAPIs to be used for support and for development of future business objects and BAPIs
- The collection of business objects for AM/FM/GIS, Network Analysis, MDD, and OMS developed with the selected tool(s)
- The Client Business Component BAPIs for support of the selected business objects
- The R/3 BAPIs for support of the selected business objects
Network Analysis Systems Technology
| ABB Power T&D Company, Inc. | CADPAD |
| Stoner Associates | SynerGEE and DPA |
| Miner and Miner | DistOps |
Mobile Data Dispatch Technology
| Utility Partners | Mobile UP |
| ABB Power T&D Company, Inc. | MCMS |
| M3i Systems, Inc. | PragmaCAD |
Outage Management Systems Technology
| ABB Power T&D Company, Inc. | CADOPS |
| Configured Energy Systems, Inc. | TroubleMan |
| M3i Systems, Inc. | PragmaLine |
| Miner and Miner | Responder |
In addition to these vendors, PriceWaterhouseCoopers has provided a consultant at the OpenFM meetings to assist in BAPI and object model development. Their participation and extensive R/3 utility industry implementation experience has been a significant help to the other OpenFM participants.
Current Status – Building a Prototype
By the end of 1998 (and as of the writing of this paper), twenty-seven individual use-case scenarios had been identified and documented by the OpenFM participants. These describe the various situations within utility companies that require the systems to interface with each other. In addition, data flows between the systems were also identified and documented.
It was determined that a prototype be built that involved all systems and technologies. Therefore, three master use-cases were identified which combined situations from many of the individual use-cases. The result was that through these master use-cases, a high percentage of interface situations and data flows could be handled by creating their respective business objects and BAPI ‘s. One of these master use-cases was identified as the one to be used to build the interface prototype.
This master use-case involves: The reporting of an electrical outage by a customer; the instance being recorded by the Customer Care System; it being logged into and analyzed by the Outage Management System; a repair order dispatched through the use of the Mobile Data Dispatch System; the recording of field modifications in the AM/FM/GIS; and then running a resulting circuit analysis in the Network Analysis system. The following diagram represents the flows of this master use-case scenario.
The object definitions for all the interface elements for this master use-case have been defined and documented. By the end of January 1999, the participating vendors will code the first prototype OpenFM interfaces. PriceWaterhouseCoopers has agreed for the participants to use one of their lU3 Development Labs for this purpose. It is planned that by February, a complete, working prototype wilI be built and be demonstrable by the vendors.
Once this first prototype is complete, the participants will continue to build object definitions for all the other use-cases and will build the BAPIs for those as well. As OpenFM completes the definitions for these interfaces, they will be published so that other vendors can use them to build their own interfaces. If this process proves successful, with users and vendors adopting the OpenFM specifications, the same approach for integrating disparate systems will be expanded to other technologies and into other vertical markets.