All utilities have to inspect their facilities because of regulatory compliance and general maintenance stewardship. If the utility is large enough, usually it breaks its service territory into a grid network. Many times, it will be split up into grids that corresponds to its overhead and underground map boundaries. The result can be 2 separate and different grids. These grids might be aggregated to a higher/simpler level and given an identifier such as Location Group. This Location Group would encompass both overhead and underground maps and is what many utilities use as a basis for planning operations.
All electric utilities have an inspection department. If large enough, it may have separate inspection crews for Overhead and Underground. For this scenario, the focus will be on Overhead Detailed Inspections (ODI). Utilities usually have to perform a thorough inspection of their assets every set number of year. Because of the sheer amount of assets, most utilities break up the required inspection to a percentage of their territory so that each asset is inspection once every X years. That does not mean the assets sit neglected for X years until its turn comes again. Some utilities are required to perform an Annual Grid Patrol (AGP). For AGP, every Location Group in the territory has to be driven and all assets undergo a drive by visual inspection every year. Those Location Groups that have an ODI that year, already get credit for AGP.
Traditionally, planning ODI dates is a tabular process. It is usually done in Microsoft Excel. Since the inspection supervisor is looking at Location Groups as cells in Excel, what sometimes happens is inefficient scheduling. Crews could potentially be sent back and forth in the service territory. Worse yet, crews could be assigned to inspect the same grid, another words, double dipping. Now to add on to that process, these supervisors would need to try and match AGP efforts to the same timeframe. These scenarios are a huge resource drain. Especially if the inspection crews are contractors, those added cost do add up. This is a perfect opportunity for GIS.
Location Groups are spatial, so use a spatial tool to manage them. Application are going to the web. Desktop software licenses are expensive and everyone wants to be able to access application from any machine or device. This is where ESRI’s ArcGIS Web AppBuilder comes in. Web AppBuilder allows for quickly deploying web application using a configuration experience. No coding necessary. ArcGIS Web AppBuilder is part of the offering from ArcGIS Online. Web AppBuilder comes with many widgets available to use. The Batch Attribute Editor widget will be used to facilitate the ODI/AGP workflow.
The first step is to get the Location Groups into a GIS format if it is not already. There are many ways to do so which is out of the scope of this article. In this scenario, there are 2 feature classes, ODI and AGP. The feature class will be the basis of 4 layers. The layers are “ODI Year”, “ODI Month”, “AGP” and “AGP Tied to ODI”. The map document should look something like this.
Next is to publish ODI and AGP data to ArcGIS Online. Make sure to enable editing on the data so updates to the Location Groups can be made. Once the data has been published, go into ArcGIS Online and create a map with the data. Next, under “My Content”, create a new app, and choose “Using the Web AppBuilder”. To complete the configuration, select the ODI/AGP map. In the widgets tab, select the Batch Attribute Editor widget. For this workflow, define the parameters of the widget according:
Use “Select by Area” so that a graphic can be drawn on the map to select the Location Groups that intersect it.
This next tab determines what layers to update. Select all the layers except “AGP Tied to ODI”. Since AGP gets credit for areas where ODI is done, the system will take care of the relation and update. This will be a view only layer.
The final tab determines which fields to update. This only shows the fields in common between all the layers selected in tab 2. Since ODI and AGP have identical data structure, only choose to update “ODI_AGP_LINK”, “Inspection Year” and, “Inspection Month”. The widget is now configured and ready to use for ODI planning. When application is run, it should see something similar to the following.
The widget can be used to update ODI year in cases where inspections need to be brought forward or delayed to later years. It can be used to update ODI month to different months of the year. This is important for utilities that deal with high fire or frost and want to schedule work around those times of the year. As the case with ODI Month, this widget can assign AGP. Once again, AGP happens every year, so the pertinent field to update is “Inspection Month”. AGP has a relation to ODI, so keep it checked if updates are being done to ODI.
In this scenario above, the inspection crew in this district has capacity to take on more inspections. So the supervisor brings forward 3 grids from 2016 into 2015 and assigned them for December. Since the supervisor is working on ODI, AGP has to be linked to it to get credit.
After making the update, 2015 now has 3 additional grids added to the scheduled work.
When the supervisor switches over to the ODI monthly layer, the 3 new grids appears with all three being assigned to December.
Lastly, switching over to the AGP layers, the supervisor sees that the three grids are rendered in black which according to the layer list, means that the AGP grids are tied to ODI. The crew will get AGP credit for these grids.
This shows the powerful capabilities of web GIS using ArcGIS Web AppBuilder. By simply configuring an out of the box widget to the need of the utility, an existing workflow can be approved upon. Implementing ODI process in GIS, supervisors can now plan and assign work visually to ensure resources are not wasted and possibly reduce operation costs.