Why It Breaks Down
Electronic permit-to-work systems, work order management platforms, and digital TAR command tools are substantial investments — in software licensing, implementation, training, and change management. They are adopted because paper-based permitting and manual work order tracking are genuinely less safe and less efficient. The payoff assumes the field workers can actually use the digital tools in the field. At most Gulf Coast process facilities, that assumption breaks down in the process unit — precisely where the permits get issued, accepted, and closed.
ePTW Tablets Work in the Trailer and Nowhere Else
Electronic permit-to-work platforms require a network connection to issue, accept, modify, and close permits — whether that connection goes to a cloud-hosted ePTW service or to an on-premise ePTW server in the plant network. In the site office or the TAR command trailer, carrier LTE or the plant's Wi-Fi provides that connection adequately. Fifty feet into the process unit — between pipe racks, under elevated structures, in the areas where hot work permits are actually being executed — the connection drops. Workers have two options: walk back to the trailer to complete each permit transaction, or resume the paper workflow that the ePTW system was supposed to replace. Most choose paper.
The TAR Manager's Dashboard Is Hours Behind Reality
Work order management during a TAR gives the turnaround manager real-time visibility into job progress, crew status, and schedule adherence — when field workers are updating their work orders in real time. When the work order system loses connectivity in the process area, field workers batch their updates at end-of-shift or at scheduled break periods when they can reach the site office. The TAR manager's dashboard reflects the state of work as of the last batch update, not the current state of work. Scheduling decisions and resource reallocation are made on information that is four to eight hours old.
Permit Cycle Time Extends When the Digital Workflow Goes Offline
A hot work permit requires issuance by the area authority, acceptance by the crew lead, a firewatch confirmation, and ultimately closure when the work is complete. On paper, each step requires a physical handoff. On a functioning ePTW system, each step is a tablet transaction that takes seconds. When the ePTW system loses connectivity in the process area, the digital workflow reverts to a partial paper workflow — some steps digital, some manual — which is slower and more error-prone than either a fully paper or fully digital process. Permit cycle time extends, hot work windows are delayed while workers physically locate the area authority, and work that should be progressing is waiting on permit administration.
The ePTW Investment Looks Worse Than Paper
A hybrid paper-digital permit workflow — digital in the trailer, paper in the field — is not safer than a fully paper workflow. It is less safe, because permit status exists in two systems simultaneously, closure confirmation may not match between the paper record the field crew has and the ePTW system status, and the area authority managing permits has incomplete visibility into what is open in the field. The ePTW system that was sold as a safety improvement is producing a worse safety outcome than the paper process it partially replaced, because the network layer that would make it work in the field was never part of the implementation plan.
Contractor Qualification Verification Requires Connectivity at the Gate
Contractor qualification verification — confirming that a contractor is current in their ISNetworld or Avetta profile, has completed the facility safety orientation, and holds the certifications required for their scope — increasingly happens digitally at the site access gate. Without reliable connectivity at the gate, verification becomes manual: printed qualification lists, phone calls to the contractor coordinator, or wave-through on the assumption that paperwork will be confirmed later. The safety credential verification that was supposed to be an automated gate function becomes a manual exception process during every shift change of a large TAR.
The Software Vendor's Answer Is "Check Your Network"
When a process facility's IT team asks their ePTW software vendor why the system doesn't work in the process unit during a TAR, the answer is consistently the same: the software is working correctly; the network connectivity is the problem. The software vendor sells permits software. They do not sell industrial wireless networks, and the connectivity gap between the site office and the process unit is outside their scope. The result is a well-functioning software platform that underdelivers on its core safety and efficiency value proposition because the network problem it depends on was never solved.
What Actually Works
The private 5G network deployed for turnaround connectivity is also the network layer that makes ePTW and TAR command systems work in the process area — not as an add-on, but as a core function of the connectivity deployment. Here is how the network supports each element of the digital permitting workflow.
Private 5G Coverage in the Process Area — Where the Permits Get Used
The sector antenna elevated on the mast delivers private 5G coverage into the process unit work zone — above the pipe racks and between the equipment clusters that block carrier LTE at ground level. A permit tablet in the hands of a field supervisor in the process unit has network connectivity to the ePTW system for the duration of the TAR. Permit issuance, acceptance, modification, and closure happen in the field, on the tablet, without a trip to the site office. The digital permit workflow works the way the software vendor demonstrated it, because the network conditions now match the demo.
Cloud ePTW: Satellite Backhaul as the WAN Path From the Field
For cloud-hosted ePTW platforms, the network path is: permit tablet → private 5G → satellite backhaul → cloud ePTW server. The satellite backhaul provides a reliable, dedicated internet path that does not share bandwidth with contractor devices, visitor phones, or the carrier LTE that is saturated by 400 contractors in a confined area. Cloud ePTW transactions from the process area route through a dedicated internet path, not through whatever carrier LTE remains available in the process unit. Permit transactions that previously timed out due to connectivity loss complete reliably.
On-Premise ePTW: Defined Integration Point to Plant IT
For on-premise ePTW installations — where the ePTW server is on the plant's internal network — the private 5G network connects to the plant IT network through a specific, access-controlled integration point reviewed during pre-deployment scoping (as described in the OT discovery and segmentation post). Permit tablets on the TAR network reach the ePTW server on the plant network through that defined conduit. The integration is deliberate and documented — not a general bridge between the TAR network and plant IT, but a specific path to the ePTW server with defined access controls. OT systems remain isolated behind their own VLAN boundary.
Work Order Management — Real-Time Field Updates
Work order management tablets and contractor CMMS clients on the private 5G network provide real-time field updates to the TAR management system. Job completions, safety observations, inspection results, and scope change requests are submitted from the field as they happen — not batched at end-of-shift from the site office. The TAR manager's dashboard reflects current field status. Schedule decisions are made on current data. Resource reallocation happens when it can still affect the shift, not after the shift has ended.
Contractor Qualification Verification at the Gate
A Wi-Fi access point or private 5G coverage at the site access gate — configured as part of the TAR network deployment — gives the gate supervisor connectivity for contractor qualification verification. ISNetworld or Avetta credential checks, safety orientation confirmation, and access badging all work at the gate with dedicated connectivity that is not competing with the contractor crowd for bandwidth. The automated gate function that the qualification system was designed to provide actually works the way it was designed to work.
Dedicated VLAN for ePTW and TAR Command Traffic
ePTW transactions, work order updates, and TAR command traffic run on a dedicated VLAN with prioritized bandwidth — isolated from general worker data traffic, PTT communications, and any other load on the private network. Permit transactions are not competing with a contractor streaming a video on the same network segment. The ePTW system gets the bandwidth it needs when it needs it, regardless of what else is happening on the private network.
The Unit on Your Site
The Clover IQ Mobile Connectivity Unit for turnaround deployments is configured to support ePTW and TAR command systems as a primary use case — not as an afterthought. Here is what that configuration looks like in practice.
Pre-Deployment ePTW Integration Planning
ePTW system type and architecture
The pre-deployment scoping call establishes whether the ePTW platform is cloud-hosted or on-premise, its network connectivity requirements (port and protocol specifications, authentication method, bandwidth per transaction), and whether it has offline/sync capability that affects how connectivity interruptions are handled. For on-premise installations, the integration point to the plant IT network is scoped with the plant IT team during pre-deployment planning — not configured on-site the morning the TAR starts.
Device provisioning for permit tablets
Permit tablets — whether operator-owned, plant-supplied, or leased through the engagement — are provisioned to the private 5G network during pre-deployment. VLAN assignment for ePTW traffic, ePTW application credentials, and any VPN configurations required by the ePTW platform are configured before the unit deploys. The first shift of the TAR starts with permit tablets that are already connected and tested — not configured on-site while contractors are waiting for permits.
Gate connectivity for qualification verification
The deployment plan identifies the site access gate position and whether Wi-Fi coverage from the mast reaches it or requires a dedicated access point at the gate location. Gate connectivity for qualification verification systems is confirmed during pre-deployment planning — including whether the gate system connects to a cloud platform or a plant-hosted qualification database.
How This Changes the TAR Permit Workflow
Before the private network
Permit transaction: supervisor in process area identifies hot work completion → walks 200 meters to site office → logs into ePTW on trailer-based laptop → closes permit → walks 200 meters back to process area. Total transaction time: 20–30 minutes. Per-shift for a 50-permit TAR: 4–8 supervisor hours consumed by permit administration logistics.
With the private network
Permit transaction: supervisor in process area closes permit on tablet → transaction completes in the field → supervisor continues work. Total transaction time: 2–3 minutes. Per-shift for the same 50-permit TAR: 30 minutes of supervisor time on permit administration. The remaining 3.5–7.5 supervisor hours per shift return to productive TAR management.
What It's Worth
The ROI of field-functional ePTW and TAR command systems has two components: productivity recovered from eliminating the trailer-to-field-to-trailer permit administration cycle, and the safety and schedule value of real-time TAR visibility. The figures below are illustrative. Validate against your specific TAR size, permit volume, and supervisor cost.
Permit Administration Productivity
Illustrative scenario — 400-person TAR, 200 daily permit transactions
200 permit transactions per day. Average field-to-office-to-field round trip per non-functional ePTW transaction: 20 minutes. Supervisor blended cost: $100/hr. 200 transactions × 20 min = 4,000 person-minutes = 66 person-hours per day in permit administration logistics. At $100/hr: $6,600 per day. Over a 21-day TAR: $138,600 in supervisor time spent walking to and from the site office to use a digital system that doesn't work in the field. With a functioning private network: permit transactions complete in the field in 2–3 minutes each. The same 200 transactions cost 7–10 person-hours per day — a 6–9x reduction in permit administration overhead.
TAR Schedule Visibility and Decision Quality
Illustrative scenario — real-time vs. end-of-shift work order updates
A 400-person TAR with 80 active work orders. End-of-shift batch updates mean the TAR manager's schedule visibility is 8 hours behind field reality. A critical path job that completed at noon is not reflected in the schedule until the 8pm shift update — 8 hours during which the dependent job could have been started and wasn't. On a $5M turnaround where every day of schedule delay costs $200K–$500K in extended shutdown cost, a single critical path job delayed by 8 hours of information lag represents $33K–$83K in avoidable schedule extension cost. Real-time field updates via a functioning work order system eliminate the information lag entirely.
ePTW Investment Recovery
Illustrative scenario — the ePTW investment that isn't delivering field ROI
A Gulf Coast refinery spent $200,000–$500,000 implementing an ePTW platform: software licensing, implementation consulting, IT infrastructure, training, and change management. The platform works in the site office. In the field during a TAR, workers use paper. The safety improvement and efficiency gain that justified the investment have not materialized because the network that makes the platform work in the field was not part of the implementation budget. Adding a private 5G network for the TAR window — billed as an operating expense against the TAR cost, not as a capital project — recovers the field ROI of the ePTW investment that was already made.
Permits Live From Day One
- Pre-deployment scoping (2–4 weeks before TAR): ePTW system architecture confirmed, integration point or cloud path scoped, permit tablet devices provisioned.
- T−3 days: Unit deployed, private network live within 1 hour, ePTW connectivity tested end-to-end from a process area position.
- TAR Day 1, first shift: Permit tablets functioning in the process area. Field supervisors issuing and closing permits from the work zone.
Questions from the Field
Does the private network support cloud-based ePTW systems or only on-premise installations?
Both architectures are supported. Cloud-hosted ePTW platforms connect from the permit tablet over the private 5G network to the satellite WAN backhaul — the same internet path the TAR management team uses for cloud applications, now available in the process area. On-premise ePTW installations connect through a defined integration point between the TAR private network and the plant IT network, reviewed and approved during pre-deployment scoping. The integration approach depends on your ePTW platform's architecture — confirming that during pre-deployment planning is why the scoping call asks specifically about ePTW system type and network requirements.
What happens to permit data if the private network has a brief interruption?
For ePTW platforms with offline/sync capability — the ability to queue transactions locally and sync when connectivity is restored — a brief network interruption results in queued transactions that complete on reconnection, with no data loss and no workflow interruption beyond the interruption window. For platforms without offline capability, a connectivity interruption means transactions cannot be submitted until connectivity is restored — the same as the current situation where connectivity is absent in the process area. The private network reduces the frequency and duration of connectivity interruptions to near zero; it does not make them impossible. Confirming your ePTW platform's offline behavior is part of the pre-deployment scoping discussion.
Can the network integrate with specific TAR management or work order platforms?
The private network provides the connectivity layer; the TAR management platform communicates over standard network protocols that the private network supports. There is no platform-specific integration in the network itself — the network carries IP traffic to and from the TAR management system the same way it carries permit traffic and PTT. For on-premise platforms that require LAN connectivity to a specific server on the plant network, the integration point is scoped the same way as an on-premise ePTW installation. Specific platform names and their network requirements should be included in the pre-deployment scoping brief.
Does adding ePTW connectivity to the TAR network require changes to the ePTW system configuration?
For cloud-hosted platforms: typically no ePTW system configuration changes are required — the platform sees a new network path to the internet, which it handles the same way it handles any other connection. For on-premise platforms: the plant IT team may need to configure firewall rules allowing the private network's defined integration point to reach the ePTW server. Those requirements are identified during pre-deployment scoping and confirmed with the plant IT team before the TAR starts — not discovered on the day the TAR begins.
What about isolated confined space entries — does the private network reach into confined spaces?
Coverage inside confined spaces — vessels, tanks, below-grade structures — depends on the geometry of the space and the position of the sector antenna relative to the opening. CBRS Band 48 signal does not penetrate steel vessel walls; coverage inside a vessel requires either a repeater antenna positioned at the vessel manway or an alternative connectivity approach for in-vessel permit transactions. Coverage in below-grade confined spaces (pits, trenches) that have an open top is generally achievable from the elevated sector antenna. Coverage in enclosed confined spaces requires a site-specific assessment during pre-deployment planning. This is a known limitation and should be flagged during scoping for any TAR with significant confined space work scope.
Straight Talk
The TAR manager who ran the last turnaround on a hybrid paper-digital permit workflow is not looking for another software pitch. They know the ePTW system works. They know the digital work order management platform works. They have watched both of them work correctly in the site office and fail in the field, and they have sat through the post-TAR debrief where both the software vendor and the IT team explained that the problem was the other party's responsibility.
The network gap between the site office and the process unit is the specific, solvable problem that Clover IQ addresses. Not with a different software platform, not with a process change that asks field workers to adapt their workflow to a connectivity constraint, but with a private 5G network that covers the process area where the work happens. The ePTW system that the plant already owns, configured the way it already is, works in the field when the network layer it was always supposed to run on is actually present.
We Don't Sell Permit Software
Clover IQ does not sell, implement, or support ePTW platforms, work order management systems, or contractor qualification software. We provide the private 5G network that makes those systems function in the environments where they were deployed to work. If the ePTW platform has a functionality gap that exists regardless of connectivity — a workflow issue, a user adoption problem, a configuration that doesn't match how the TAR actually runs — that is between the operator and the software vendor. What we fix is the connectivity gap that prevents an otherwise functioning system from working in the field.
The Confined Space Limitation Is Real — Scope It Early
The FAQ answer about confined spaces above is an honest statement of a real limitation. CBRS signal does not penetrate steel vessel walls. For TARs with significant confined space work scope — vessel entries, column work, exchanger bundle pulls — the coverage question for in-vessel permit transactions needs to be answered during pre-deployment scoping, not discovered during the TAR. In many cases, vessel entry permit transactions can be completed at the vessel manway (which is in coverage) rather than inside the vessel. In cases where that workflow doesn't fit, a repeater or alternative approach is identified before the TAR begins.
Scoping the ePTW Integration Is Part of the Engagement
Every Clover IQ turnaround deployment that includes ePTW or TAR command connectivity goes through an ePTW integration scoping step — confirming the platform architecture, the network requirements, the integration point for on-premise installations, and the device provisioning plan. This step is not optional and is not an add-on service. The private network that doesn't integrate with the ePTW system is not delivering the value the engagement was scoped to provide. Getting the integration right before the TAR starts is the standard, not a premium.
Talk to us before your next TAR planning cycle. Bring the ePTW system architecture documentation and the work order management platform your team uses. The scoping call that covers connectivity also covers digital permitting integration — because the two are the same deployment.
