This paper reviews the various architectures of GIS, OMS, MWM, DPS, and WMS vendors. It discusses the tradeoffs between how different architectures could be and have been integrated and discuss the merits of our approaches taken to date. The levels of integration and benefits derived at each level of integration are highlighted.
Topics include: the business objects (semantic data model) needed to develop an integrated solution; overviews of the product architectures, including message/event, polling and user demand-based; the type of data that should be owned by each system; the tradeoffs of different data distribution architectures; how GIS is architecturally better suited to analyze history logs of operations and outages and the advantages ArcGIS8 GeoDatabase technology provides in our approach of integrating of GIS, MWM, WMS, OMS and DPS systems.
Operational and business discussions include: why using the GIS as a graphical data entry tool for WMS is beneficial; the benefits of the different levels of DPS and GIS integration; the benefits of doing interruption and reliability analysis and reporting from a GIS and the technology and business dependencies of EDRP integration approaches and the business benefits that can be incrementally achieved from our methodology, as well as highlighting the pitfalls of alternate approaches.
This paper focuses on integrating the engineering, planning, scheduling and operational tools used to run the day-to-day activities of utilities with customer service systems and financial back office systems (ERP). The paper illustrates that commercially available solutions can be integrated to support this problem domain. A key to successful integration is building an Energy Network Object Model™ (ENOM) that supports both the vertical applications and the integration requirements. Many of the new features of ArcGIS 8.1 can be used to implement a robust object model that includes the underlying behavior required to support the integrations as part of the object model.
DPS - Distribution Planning System. This system performs the detailed engineering analysis and modeling required to plan the growth of the utility system and to make decisions during winter and summer peaks.
EIS - Executive Information System. This system takes advantage of the operational data and provides management summaries of current status and historical analysis of work types.
ERP - Enterprise Resource Planning. This system supports a suite of financial modules that typically include, but are not limited to, accounts payable, accounts receivable, general ledger, payroll, human resources, budgeting, material management and inventory.
GIS - Geographic Information System. This system performs the day-to-day maintenance on the utilities energy network models and related landbases.
GWD - Graphical Work Design. This system allows users to set job points and spans and design using compatible units while designing construction jobs that will enhance the utilities’ facilities.
MWM - Mobile Workforce Management. This system performs the automated dispatching of service orders to field crews and manages the field lifecycle of enroute, arrival, service call and closing.
OMS - Outage Management System. This system is used by operations to aid in the troubleshooting of trouble calls. It manages the abnormal states of the energy network models.
WMS - Work Management System. This system is used to manage utility work orders through initiation, design, estimating, scheduling, perform, and closing phases.
EDRP - Energy Delivery Resource Planning. This solutions takes all of the above core technologies and integrates them with the existing customer information, trouble call, accounting, payroll, human resources, budgeting, and SCADA systems typically found at utility companies.
The following diagram shows a high-level suite of systems to be addressed.
The following diagram shows the complete EDRP solution along with the other major systems that are typically part of the integrated enterprise solution.
Our integration approach tends to accelerate the deployment of the EDRP technologies. The core MWM, WMS and GIS technologies can be deployed in any order, or even in parallel. Typically, the data conversion or migration of the existing facilities is the longest duration task; hence, we will have incremental deployments of WMS and MWM before data exist for deploying GIS. Once both GIS and WMS have been configured, then Work Design can be configured using those two data dictionaries/catalogs to configure the relationships of GIS facility objects to WMS compatible and macro units. Designing both the ENOM and the work management compatible units to be at the same level of abstraction is a key design dependency that enables the successful integration of these systems.
The core MWM system to support automated dispatching and manage the field workforce can be deployed in parallel with any of the other technologies. Because of its business benefits and the fact that it efficiently supports the day-to-day dispatching operations, the MWM system should be deployed ahead of the OMS. From an operational perspective, MWM probably can be configured to support up to 80 to 90 percent of daily dispatching job types. Most of the OMS systems have some dispatching functionality, but we feel it is not the appropriate tool for handling dispatching and field management demands of the operational business needs of a utility. This is more of an educational dependency than a technology dependency.
The OMS configuration and deployment must follow the GIS, WMS and work design deployments. This is because the network model is maintained by the business process – Design, Estimate, Scheduling and Job Posting – that the other three technologies are needed to support. Attempting to deploy an OMS without a business process established to keep the energy network model current will not be a successful deployment. By following this sequence of technologies, the OMS configuration effort will have a tremendous head start by reusing most of the ENOM. Typically, the OMS requires just a subset of all the facility objects that are managed and maintained by the GIS object model. Again, a major key to ensuring that the OMS model is easily generated and updated takes into consideration some of the operational requirements when designing the GIS ENOM.
The need for the GIS ENOM to drive the DPS creates a natural dependency between these two technologies. The reuse of the ENOM to configure the DPS model ensures the clean integration between these two technologies. With the advancing architectures of many DPSs to support analysis services, our preferred integration approach is to use the visualization power of the GIS to render the analysis results. The inherent versioning of the GIS also goes a long way in supporting the business need of maintaining 5- and 10-year case studies or planning sessions.
There is a definite set of technology-related dependencies when attempting to deploy an integrated EDRP suite. Besides the inherent different set of business processes each technology is meant to support, the underlying ENOM relationships dictate that the GIS deployment should drive the other systems that need either a set of facilities or related landbase features. These include DPS, OMS, work design and preventative maintenance systems.
The specific benefits associated with each technology are numerous. Business benefits consulting is a valuable service offering. The relative ordering of the business merits of the technologies are WMS, MWM, work design, DPS, OMS and GIS. The spectrum is large with many tangible hard business benefits for WMS, MWM, work design and DPS to the softer customer service and other intangibles typically associated with OMS. From a business perspective, GIS by itself is not a business system, nor does it support a single business function. By managing the ENOM, it is a key supporting system for OMS, DPS and work design. For companies using paper maps, there are some firm tangible business benefits. However, it becomes harder to justify managing the enterprisewide energy network model if one does not look at the complete business picture of the other operational systems that rely on the energy network model being maintained and up to date.
Each of the integration efforts can be treated as separate point-to-point integrations. We prefer to take advantage of the leading Enterprise Application Integration (EAI) technologies and do as much of the integration in the context of an integration broker, its set of adapters and the functionality that its Messaging Orientated Middleware (MOM) transport layer provides. Typically, a hybrid approach is employed, using EAI for most of the synchronous integration requirements and for most of the high transaction rate asynchronous integration with low to medium data volume requirements and traditional FTP/bulk copy utilities for large volumes of data that have lower currency requirements. The following diagram illustrates the hybrid approach of using both EAI and point-to-point technologies where appropriate. Most of the integration with the existing systems – call center, ERP suite and CIS – take advantage of the integration broker architecture. Most of the GIS interfaces are at the COM level or still point-to-point. ArcGIS 8 supports the COM level and its new GeoDatabase object hierarchy functionality adds considerable maintainability and development productivity for the point-to-point interfaces, (this is discussed in more detail in the ArcGIS Architecture section). Other point-to-point integrations still include replicating a subset of the CIS customer database and the customer consumption history and the ICCP-based messaging integration between SCADA systems and the OMS.
The following series of diagrams illustrates the difficult problems of semantically integrating the various systems. To aid in addressing these problems, both ENOM and GWD were developed to support the gaps in functionality between the GIS, OMS and WMS technologies. Main GWD function is to address the need for designers to use job points and Compatible Units (CUs) while laying out the job sketch and developing the detailed set of facilities, their attributes and their network connectivity. The assumption here is that most WMS have good catalogs for users to collect and define their compatible units and macro units. GWD maintains the mappings between the facility/feature types and their WMS-based compatible and macro units. GWD also supports the tracking of individual facilities to all related work orders over time. Most of the WMS vendors will not maintain this level of tracking. They track to the job step and CU levels but not to the facility occurrences associated at the job step.
As noted in the introduction, the ENOM plays a key role in supporting the integration of the various operational systems with the GIS. ArcGIS8 enables standard object behavior via a custom feature class functionality. From an integration point of view, all of the interface logic can now be part of the GeoDatabase instead of in separate point-to-point applications. The ENOM has objects for devices, conductors and mains, which all have static attribution and dynamic behavior modeled. Developing the interfaces for DPS, OMS, and work design are now coupled to the COM interface definitions of our custom feature classes, and we can take advantage of using good class hierarchy definitions to inherit most of the required interface behavior. For example, when the OMS interface walks the circuit, it can ask the object what it is connected to, what attributes are worthy of exporting to the OMS, what type of OMS device it belongs to, etc. The interface applications that once had to know the connectivity models for both systems and the mapping logic and the attribute mappings, now employ a simple report writer that walks the circuit and dumps the information in the format specified by the OMS. As OMS loaders mature, the dump file format for this information can just as easily be in XML as the native OMS formats. This type of information can also be stored in the GeoDatabase to reduce formatting time, so that when designers are editing their circuits and posting as-built job prints, the XML version of the circuit is saved at the same time. The same type of power and productivity can be achieved with DPS integration by developing the customer feature classes to have standard COM interfaces supply all required engineering attribution and consumption information on specific device type to the analysis engine. The native versioning of an ArcGIS GeoDatabase plays a key role in supporting the integration with DPS. Based on the progress of DPS vendors decoupling their analysis engines from display services, multiple what if scenarios based on the different versions of a network can be run. By saving the modeling result sets to their own layers and using standard overlay processing, one can use the full visualization power of ArcGIS to identify the potential problem areas and determine which scenarios would best fix the problem.
Many of the new architectural features of ArcGIS8 can be exploited by system integrators to speed up the development and deployment of utility engineering and operational systems that rely heavily on the energy network models managed by ArcGIS. By looking at the complete integration needs and at the various software architectures of the systems involved, a hybrid application integration approach between using traditional point-to-point technologies and EAI technologies provides a pragmatic system architecture for deploying these integrated solutions. The new functionalities of true object-oriented custom feature classes and version management of feature datasets are two of the key advances that efficiently support a hybrid approach to systems integration.
Tom Helmer
SchlumbergerSema
6399 South Fiddler's Green Circle, Suite 600
Greenwood Village, CO 80111
(303) 486-1134 telephone
(303) 741-8401 fax
tom.helmer@convergentgroup.com