The Enterprise GIS has long been at the heart of planning and operations for Utilities. With the increased demand for intelligent, connected systems geospatial data has become the common language used to communicate between systems because location is the one piece of information that every system must agree on. This article shows design considerations that developers and IT professionals can use to design and build three of the most important interfaces for the utility network: The Work Management System (WMS), Asset Management System (AMS), and Customer Information System (CIS) . If you haven’t already, you should read my earlier article Getting Started with Utility Network Integrations to get up to speed on the technologies and workflows I reference in this article.
You can use the following links to quickly navigate to the corresponding section in this article.
Utility companies make use of Work Management, Construction Design, and Staking tools to model proposed changes to the network using tools that run outside of the GIS. Vendors who are Esri partners typically supply interfaces that import design packages from their software into the GIS. If you are integrating with a smaller solution or have developed your own in-house tools for managing designs, you may need to build your own interface.
When importing designs, or performing edits that make changes to the network, you must use workflows and APIs that maintain the validity of the network. Because of this, you must apply any proposed changes to the GIS that come from a construction design or staking tool to a named version. Once again this makes the ArcGIS API for Python or ArcGIS Pro SDK the recommended API for the problem because of their ability to create and manage versions, their ability to scale with larger datasets, and their ability to validate the network topologyt.
The largest design challenge for the work management interface related to design decisions that allow the interface to gracefully handle any problems that occur during the import. If jobs are small and consistent you can achieve this with a headless script using the ArcGIS API for Python that imports completed work. For complicated design scenarios that require user interaction you will want to use the ArcGIS Pro SDK to develop an Add-In. This will provides users a graphical user interface to interactively import, manipulate, and validate the design features.
Asset Management System
Utility companies make use of an Asset Management System (AMS) to track the lifecycle of a piece of equipment from the moment of purchase through its retirement. The GIS tracks the attributes of an asset when it is in the field, so for this stage of its lifecycle the GIS and AMS must communicate changes to the asset with each other. An AMS interface implements logic for sharing changes between the systems to ensure they remain aligned. They use a set of business rules to limit the changes to specific types of assets, fields, and types of edits.
From an interface design perspective this means we need to do a full system compare between the GIS and AMS. Every time the interface runs you can expect it to change hundreds if not thousands of features. Comparing and editing the two systems will take more time for larger systems, but you should design your interface to take anywhere from several minutes to an hour to complete. An important part of this design is to perform the comparison and edits in a named version because this will isolate it from other changes occurring at the same time. Again, the APIs best suited for this interface are the ArcGIS API for Python and the ArcGIS Pro SDK, because of their ability to work in versions and scale with larger sets of data.
Versioned Editing Workflow
One final design consideration for this interface is whether your edits will change the underlying topology. You can figure out this by asking yourself if your interface could create / delete network features or alter attributes that control the state of the network (device position, lifecycle status, etc.). If you answered yes to any of these items, then your interface will need to follow the best practices outlined for editing utility network data:
- You must perform your edits in a version
- You must validate any dirty areas created by your process
- You must update any networks that edited by your edits
- You should only reconcile/post your version if it does not introduce any network errors
- If your version introduces errors a user must review and correct the errors
Customer Information System
The Customer Information System (CIS) at a utility tracks the who, what, and where of the customer. Who is the customer, what kind of service(s) do they have with the utility, and where is the service? A Customer Service Representative (CSR) manages the information in the CIS through their interactions with customers or by capturing data from forms they receive from field crews. If the CSR never receives forms or the CSR can’t read the forms received from the field, then the information in the CIS quickly gets out of date with the field. Because the GIS is the system of record for what equipment is in the field, the solution most utilities have for this problem is to integrate the CIS with their GIS. What follows is a high-level design for how a small to mid-sized utility may design and implement an interface like this with the GIS.
Before we talk APIs and workflow, I first want to talk about the data structures we will be synchronizing across the CIS interface. These structures will vary widely between different products so the solution I’m describing will be using a simpler model; however, this approach should scale to more complicated solutions with a few adjustments. The GIS and CIS often have conflicting or confusing terminology, so let’s define some terms up front:
- Service Location – The location in the GIS that serves one or more customers. Some utilities may use this to model individual meters, others may use it to act as a placeholder for a premise or service point.
- Service Point – A unique, immutable way of naming the service provided by a utility. A Service Point record is related to customer, meter, and premise information. Because the service point is unique and persistent, you can replace any of those related items without affecting the service provided at that location. Each Service Point has a unique identifier that integrates with other systems like GIS, Advanced Metering Infrastructure (AMI), and Meter Data Management (MDM).
- Meter – The physical device responsible for measuring the service provided by the utility. A special type of meter called a net meter can also measure the service provided by the customer to the utility in the event a customer generates more power than they consume.
Note: The Utility Network has several options for modelling customer connection details. For a detailed discussion on this I recommend you read the Meters section of my Electric Standards: Devices story map.
The following diagram shows how these objects are related.
- Service Location – Primary Key: Global ID. No customer information stored on this feature.
- Utility Service – Foreign Keys: DeviceGuid, ServicePointID. Can store characteristics of the service point (or associated items), but should be done with caution.
- Service Point (GIS) – Primary Key, ServicePointID
- Service Point (CIS) – Primary Key ServicePointID
If you do not store any information about the customer on your Utility Service or Service Location features, you can use a simple ArcPy script to read the customer information data into memory (xml, csv, web service, sql), then update the Service Point table in the GIS. If you are loading a few hundred thousand records, you can just delete the rows out of the table and insert the new ones. For a larger dataset you will need to use a more selective approach that inserts, updates, and deletes individual service point records.
If you keep information about the customer on versioned tables, you will use one of the APIs that allows you to perform versioned edits (ArcGIS API for Python or ArcGIS Pro SDK). This is important because you will want to perform these edits in a version and take care to only update values that have changed. Once your interface applies edits to the version it will then reconcile and post the version.
The two earlier approaches rely on a batch process to synchronize the two systems. However, it is also possible to use these same methods to perform real-time updates to the GIS. If you take this approach, you should still build a batch process to audit or reconcile the two systems on a periodic basis. No matter how well designed such a real-time interface is there will always be messages that slip through the cracks.
Your interfaces will perform and capture some quality assurance information in log files for administrators each time they run. In addition to this you should run a separate process to produce a quality assurance report for end users. This quality assurance report will flag inconsistencies, missing data, or other business rule violations for mappers or customer service representatives to resolve.