It's 2 a.m. at a compressor station outside Midland. A developer on call is watching a dashboard tick oxygen concentration down toward the pass/fail threshold the commissioning engineer set. The nitrogen skid is running. Four field techs are watching the outlet. And every value on that screen (set-points, alarm thresholds, timestamps, operator acknowledgments) has to survive an audit that could happen five years from now.
The software running the purge isn't a nice-to-have. It's the artifact regulators, insurers, and the operator's own engineering team will judge the job by.
If you're building that software, the interesting work isn't the UI. It's the decisions baked into the data model, the control logic, and the reporting layer.
Here are the ones that matter most.
Decide Whether You're Writing a Control System or a Reporting System
The first fork is architectural, and getting it wrong will haunt you. A control system actuates valves, ramps nitrogen flow, and trips alarms in real time. A reporting system consumes telemetry from a SCADA layer someone else owns and turns it into signed, timestamped evidence. They share sensors and screens, but the guarantees they have to make are different.
Pick one primary role and design the other as a subordinate. Trying to be equally good at both is how you ship software that's mediocre at each.
Choose the Acceptance Logic Before You Design the UI
Pass/fail logic sounds trivial until you write it. A single-sweep purge on a short header is one comparison. A branched system with dead legs and multiple sample points is a state machine, and if your software conflates them, operators will disable your alarms and log values by hand.
The thresholds themselves are set by the service the pipe will hold, not by the software vendor.
Your job is to make the threshold configurable per segment, timestamp every change, and require a second signature to alter it mid-purge. Hard-coding a number to ship faster is a decision you'll regret the first time an auditor asks who changed it.
Decide What Counts as Evidence, and Store It That Way
Commissioning software produces two categories of output: the record of what the pipeline did, and the record of what the people supervising it did. Both are discoverable. Regulators treat purging of combustibles as tied to the same operational-status rules that govern the rest of a pipeline's life, and the PHMSA advisory makes clear that the paperwork around commissioning is not optional garnish.
At a minimum, your data model needs to preserve a few distinct classes of record:
- Process telemetry. Time-series readings from every O2 analyzer, flow meter, and pressure transducer, at the raw sample rate, with the sensor tag and calibration record attached.
- Configuration state. The thresholds, segment definitions, and alarm limits in force at each moment, plus a full history of who changed what and when.
- Human actions. Operator acknowledgments, signatures, overrides, and shift handovers, timestamped and tied to the identity of the person who took them.
Decide How Your Software Fails Safe
A commissioning job tends to be treated as dangerous until widely used otherwise. Your software should treat itself the same way. What happens when the O2 analyzer drops off the network for 30 seconds? What does the operator see if two sample points disagree? What does the report say when a sensor was replaced mid-job?
The unglamorous answer is that you write down the failure modes before you write the features. A crew running a nitrogen displacement on a live construction site can't wait for a hotfix, and the field engineer isn't going to read your changelog. Default to holding the last known good state, alerting loudly, and refusing to declare acceptance on incomplete data. Silent degradation is the failure mode that ends up in a deposition.
Decide Who the Report Is Actually For
The final PDF at the end of the job usually gets designed last, which is backwards. The report is the product. Everything else is plumbing that generates it.
It has three audiences, and they want different things. The commissioning engineer wants trend charts and event timelines they can defend to their own management. The operator's compliance team wants a document that maps cleanly onto their internal procedures and the applicable regulations. An outside auditor, if it ever comes to that, wants to reconstruct the job from the raw data your software preserved.
Build the report so all three can find what they need without asking you for a custom export. If your reporting layer can't do that, you haven't finished the software. You've finished the demo.
