Digital Field As-Builting with ArcGIS: Pressure Tests
Part 3 of 4
By Tom DeWitte and Tom Coolidge
Digitally transforming the gas and pipeline industry construction packet initially has been focused on digitally transforming the redlined paper maps into digital data. Most of the initial Tracking and Traceability solutions on the market have been almost exclusively focused on this part of the construction packet. What about the rest of the construction packet?
A pipe construction packet contains more than marked-up paper maps. It contains pressure test results, exposed pipe inspections, checklists, daily reports, and more. What about digitally transforming those documents?
In this blog article we will discuss how to configure and automate the data capture of the pressure test. Pressure test documentation has historically been a critical piece of information that too often is relegated to the bottom of the document pile, filed at the back of the cabinet, boxed, warehoused, and eventually misplaced never to be found again. If you are responsible for managing or determining a pressure zone’s maximum allowable operating pressure (MAOP), then this frustrating reality most likely results in a palm slap to your forehead.
A key benefit of digitally transforming the documentation of pressure tests is that this information is immediately tied to the tested assets. As a related record to the asset, it is a simple click to retrieve this information. No more searching through warehoused boxes of documents to find this critical information.
What is a Pressure Test?
Pressure testing is an industry standard practice. The purpose is to identify issues which would result in system failure and the release of gas prior to natural gas flowing through these new assets. Simply put, it is to insure the newly installed components are part of a safe and reliable pipe system.
The physical action of performing a pressure test is not complicated. You insert an inert substance, such as air or water, into the newly installed portion of the pipe system. The new subsystem is then pressurized to the desired test pressure. Once pressurized, the subsystem is then monitored for a specified duration to verify the pipes, valves, and fittings are holding pressure and not leaking. The final step is to document the test to persist this important information for future analysis and engineering of the pipe system.
Historical Issues
Documenting a pressure test has two primary components. The results of the test itself, and the identification of which pipe system components were tested. Historically this was all done on paper. It was time consuming. Field crews had to sketch the portion tested and identify the components which were included in the tested subsystem. Not only was this prone to error and data omission issues, it was redundant data documentation. Field crews were being asked to redraw the new pipe system for the pressure test after separately drawing those components for the redline as-built documentation.
Early attempts to convert the paper documentation into digital documentation often focused on eliminating the redundant sketch creation. For example, one legacy solution asked the field user to manually click on each unique asset which participated in the pressure test. This eliminated the redundant creation of the sketch, but at a cost of significant loss of productivity. Imagine how long it would take you on your phone, tablet, or laptop to manually select every fitting, valve, and pipe segment for the pressure tested subsystem. This could easily include over 100 unique items. This legacy digital approach, in addition to taking more time to complete, was still prone to data omission issues.
Easier, Faster, and More Accurate
This industry problem of how to efficiently and accurately document pressure tests is a great example where a spatially aware mobile software application can uniquely solve this problem. There is a solution that provides the field user with an easier process for documenting pressure tests in a manner which is faster and more accurate. So, what exactly is the secret sauce that a geospatial mobile solution can provide?
The answer is polygons.
Our Secret Sauce
A geospatially aware mobile application, such as ArcGIS Field Maps, understands which of the newly installed pipe segments, valves, and fittings are contained within a polygon’s extent. This geospatial understanding eliminates the need for a field user to manually select the pipe system components.
Using a polygon to represent the pressure test extent simplifies the documentation of the pressure test down to two steps.
Step 1: Draw a polygon around the components of the pipe system which were tested.
Step 2: Document the results of the test itself.
The two key configurations to ArcGIS Field Maps to enable this automation is the polygon layer and an attribute rule.
The Pressure Test Polygon
The pressure test polygon feature is the persisted record of the pressure test. It is enabled with attachments to allow photos of the pressure test wheel to be stored as part of the pressure test record. The specific information a utility wishes to capture about the pressure test, duration, pipe test medium, who performed the test, etc., is the schema of the polygon. This polygon pressure test record fully captures where, when, who, how, and what was tested.
Documenting Pressure Test Results
For most utilities, defining the schema is a onetime process of converting the questions on the paper pressure test form into a digital smart form. The schema can include picklists, default values, and date pickers to eliminate typos and speed-up the data entry process.
Persisting Link Between Asset and Test
A key part of the automation of the pressure test is to tag all newly installed assets which were tested. This is where an attribute rule is implemented. The attribute rule will compare the extent of the polygon against the pipe system components which were documented as the initial part of the digital field as-builting workflow.
Here is the attribute rule arcade script to automate the assigning of the pressure test id for the staging line featureclass.
//Rule Name: StagingPressureTest_PressureTestID_StagingLine
//Description: Push StagingPressureTest attributes to StagingLines
//Type: Calculation
//Subtype: All
//Field: pipetestpressure
//Editable: checked (true)
//Trigger: Insert, Update
//Error Code: 7
//Error Message: Couldn't push StagingPressureTest attributes to StagingLines
//Evaluate from application evaluation: checked (true)
// Get pressure test id from the polygon feature
var retVal = $feature['pipetestpressure'];
var pressureTestId = $feature['PressureTestID'];
var feature_set = FeatureSetByName($datastore, 'StagingLine', ['OBJECTID'], false);
// Find line features that intersect the polygon
var intersected_features = Intersects($feature, feature_set);
//If need to exclude certain types of features tweak the next line and change the "for" loop to use: filtered_features
//var filtered_features = Filter(intersected_Features, 'assetgroup not in (10, 12)')
//add features to the update dictionary
var updates = [];
var i = 0;
for (var feat in intersected_features) {
updates[i++] = {'objectid': feat.objectid,
'attributes': {
'PRESSURETESTID': $feature.pressureTestID
}
}
}
//return the dictionary
return {
'result': retVal,
'edit': [{
'className': 'StagingLine',
'updates': updates
}]
}
This attribute rule is automatically initiated as soon as the field user submits the pressure test polygon.
Geospatially Aware Mobile Applications
This configuration of ArcGIS Field Maps shows how the needs of documenting pipe construction information, such as a pressure test can be uniquely addressed. Geospatially aware mobile applications provide the secret sauce for automating the documentation with the ease of use and productivity field users are looking for.
It is also important to note that automating the tagging of the pressure tested assets with the pressure test unique ID improves data quality. This mobile application writing of the pressure test ID onto each of the assets, means that this critical data will no longer be lost to the stack of boxes in the warehouse.
If you are interested in deploying this configuration of ArcGIS Field Maps, we have posted all the scripts, data model templates, and instructions for this pressure test configuration and the entire digital field as-builting solution. You can download this configuration from the Esri Community site for free. Here is the link.This blog article is the third in a series of four blogs articles explaining how to deploy ArcGIS Field Maps for Digital Field As-builting. If you missed our previous blog articles on digital field as-builting, here are the links to those articles.
Part 1: Digital Field As-Builting with ArcGIS
Part 2: Digital Field as-Builting with ArcGIS: No barcode No Problem
Next blog article will continue leveraging the productivity enhancer geospatial awareness. Blog #4 will divulge the secret sauce of configuration and automation for managing the construction project, and how to automatically link all construction project digital documentation together.
PLEASE NOTE: The postings on this site are our own and don’t necessarily represent Esri’s position, strategies, or opinions.