How offline NDT field capture has to behave when the plant has no signal

What offline has to mean before a technician trusts it

Adoption in the field is binary. A technician either opens the app inside a tank and starts working, or reaches for a clipboard. One failed attempt and the app is finished: paper comes back, and the software degrades into a re-keying station where someone in the office types up the day's scribbles. That is a worse outcome than never buying it, because you now pay for the licence and the transcription. The requirement is therefore not that the app works offline sometimes — it is that it behaves identically whether or not there is a signal.

Concretely, that means all of the following work with the radio off: opening a job created last week, creating a new job, entering readings, attaching photos, marking an indication on a sketch or weld map, looking up the applicable procedure and acceptance criteria, seeing the previous thickness recorded at that CML, capturing a signature, and producing the PDF. If any one of them requires a round trip, the technician hits a wall mid-examination, which is the moment trust is lost.

The reliable tell during a demonstration is what happens to controls that normally fetch from a server. A client dropdown, the next report number, an acceptance criteria table, a technician list. If any of those loads on demand, the form stalls with no signal. All reference data has to be pre-synced with the work pack before the crew leaves, which means someone must be able to define what a work pack contains.

Where signal actually disappears in a plant

Coverage maps are drawn for people standing outside. NDT is performed inside. A welded steel tank interior behaves close to a Faraday cage; so do vessel and column internals, boiler houses, cooling tower basins, culverts and trenches, and below-deck spaces on a vessel. Signal also drops under dense pipe racks and grating, in concrete-walled radiography vaults, and in the middle of large tank farms where the nearest mast is a kilometre away and the steel is between you and it.

Plenty of no-signal situations are administrative rather than physical. Radiography exclusion zones impose controlled entry and, on some sites, radio restrictions. Many client facilities prohibit personal devices, prohibit cameras without a permit, and refuse to let contractor hardware join plant networks. During a turnaround, several thousand contractors share one guest SSID that was sized for a normal week, so the network exists and is functionally unusable — the worst case for any app that assumes a live connection.

Remote and offshore work adds latency rather than absence. VSAT links are contended and high-latency, and a design that makes one request per field is unusable at 600 ms round trip even though the connection is technically up. This is why offline-first and low-chattiness are the same engineering decision, not two separate features.

Local-first storage: the device holds the record of first entry

The architecture that works writes to a local database first and reads from it always. On a native app that is usually SQLite; in a browser-based or progressive web app it is IndexedDB. The server holds a replica that catches up. This inverts the default cloud pattern, where the server is authoritative and the device holds a cache, and the inversion is the whole point: if the server is authoritative, no server means no work.

This also improves the compliance position rather than weakening it. ISO/IEC 17020:2012 clause 7.3 requires primary records to be made as soon as practicable. A reading typed into the app at the point of examination is a primary record. The same reading written on a glove, transcribed to a notebook, then typed into a spreadsheet that evening is a transcription of a transcription, and every step is an opportunity for a transposed digit that nobody can later detect.

Storage durability deserves specific attention because it is where browser-based products quietly fail. Browser storage is evictable under device storage pressure unless the app explicitly requests persistence, and Safari's tracking prevention clears script-writable storage — IndexedDB, localStorage and service worker registrations included — for first-party sites the user has not interacted with in seven days of browser use. Home-screen web applications are exempt from that cap. A product making a week-long offline claim must therefore be a native app or an installed home-screen app, and you should confirm which.

Sync conflicts: resolve by record and field, never by file

Two technicians working the same job is normal, not an edge case. If sync operates on documents, reconnecting forces a choice between whole files: one person's afternoon wins and the other's is discarded or shunted into a conflict copy nobody reads. If sync operates on records, each reading, indication, photo and signature carries its own identity and version, and two people adding readings at different CMLs never conflict at all. Most apparent conflicts vanish purely by making the unit of sync smaller.

A genuine conflict is the same field of the same record given two different values. There are three honest resolutions. Last-write-wins is simple and silently destroys an examination result, which makes it acceptable for a cosmetic field like a job note and unacceptable for a measured value. First-write-wins rejects the second edit and tells the technician. Surfacing both values to a reviewer, with technician, device and capture time attached, is slowest and correct for anything that goes on a report. A product that cannot tell you which of these it uses has not thought about it.

Retry safety is the quiet requirement underneath all of it. Mobile sync retries constantly, and without a client-generated identifier the second attempt after a timeout creates a duplicate report. The device must mint the record identifier — a UUID — while still offline, and the server must treat a repeat of the same identifier as the same record rather than a new one. That same mechanism is what allows a report number to be reserved on the device before anyone knows the server is reachable.

Timestamp integrity: capture time, device time and server time

A handset clock is a user setting. Any record whose only timestamp came from the device is disputable, and in a disagreement about when an examination was performed that is precisely the record you need to defend. The answer is to record more than one clock. Store the device's local time with its UTC offset, store a monotonic elapsed-time reading that keeps counting forward regardless of what the user does to the clock, and store the server's receipt time when the record finally arrives.

Those three values together make manipulation visible. If the monotonic difference between two consecutive records is twenty minutes while the wall-clock difference is six hours, the clock was changed between them, and the system can flag the record rather than silently accepting it. GNSS gives an additional independent reference: a satellite fix carries time and needs no cellular network at all, so a position-stamped reading taken in a tank farm with no signal still has externally sourced time.

What matters on the finished report is that the examination date comes from the capture, never from the upload. A crew that syncs on Monday morning must not produce reports dated Monday for work performed on Saturday, and the record must retain both facts — when it was taken, when it was received, and that the two differ. That is a stronger evidentiary position than paper, which carries whatever date the technician wrote.

Signing and issuing the PDF on site

Clients frequently want a document before the crew leaves the gate. That requires the PDF to be composed on the device: template, fonts, logo, sketches and photographs all embedded locally with no server-side render step. This is the most common place a supposedly offline app fails, because capture was built offline and rendering was left on the server. The technician can enter everything and hand over nothing.

Signature type matters more than most buyers realise. A captured signature image is a picture of a scribble; it proves very little and can be copied between documents. A cryptographic signature applied on the device binds the document content to a key, so any later alteration is detectable. Signing itself needs no network, because it uses the private key held on the device. The trusted timestamp does need one: RFC 3161 timestamps come from a Time-Stamp Authority over the network.

The practical resolution is a two-stage signature. The device produces a signed PDF on site under the PAdES baseline profiles defined in ETSI EN 319 142-1, and the technician issues that copy immediately. At sync, the system embeds the certificate chain and revocation data and adds a document timestamp, reaching PAdES-LT or LTA. Further archive timestamps can be added over the years without invalidating the original signature, which is what keeps a record verifiable long after the signing certificate has expired. Where the report is derived from instrument output, the path from raw file to issued document is covered at /omniscan-data-to-inspection-report.

Weak signal is worse than no signal

Most apps detect connectivity as a boolean and get it wrong at exactly the wrong moment. With one bar, the operating system reports a working network, the app issues a request, and that request hangs for the full timeout rather than failing fast. The interface shows a spinner, the technician assumes the tap did not register and taps again, and now two records are in flight. Performance on a marginal connection is routinely worse than performance with the radio switched off.

The design that survives treats the network as unreliable at all times rather than as a state to be checked. Every write goes to the local database first and returns immediately. Sync runs in the background and never blocks the form. Timeouts are short and fall back instantly to the queue. Sync state is shown as a count of pending records with a manual sync control, not as an indeterminate spinner, so the technician always knows how much work is still only on the device.

Battery is the other casualty of marginal coverage: a radio hunting continuously for an unusable network drains a device far faster than one that has given up. A deliberate field mode that suspends sync attempts until the technician is back at the gate is a legitimate and underrated feature, particularly on a twelve-hour shift where nobody can charge anything.

Devices, hazardous areas and what site IT will allow

Area classification decides the hardware before software preferences do. Zone 1 and 21 under ATEX and IECEx, and Class I Division 1 under the North American scheme, require intrinsically safe devices from specialist manufacturers such as Aegex, ecom or Bartec, or a standard device inside a certified enclosure. Zone 2 and 22, and Class I Division 2, are the more common classification for the areas technicians actually work in, and are served by mainstream rugged tablets from Getac, Durabook and Juniper Systems among others. Always take the classification from the site's own hazard assessment rather than from a product page.

Client IT policy is the second gate and is often the harder one. Many facilities prohibit personal devices airside, require a permit for any camera, and will not permit contractor hardware onto plant networks under any circumstances. An app that never needs the client's network sidesteps that negotiation completely — the crew works offline all day and syncs over the company's own cellular connection or back at the office. That is a commercial advantage during mobilisation, not only a technical one.

Because the device now holds the primary record before sync, device management becomes part of the quality system. The local database must be encrypted at rest, the device must enforce a screen lock, and remote wipe must exist. Sync frequency is a risk control as much as a convenience: a device that has synced at lunchtime exposes half a shift if it is dropped from scaffolding, and a device that syncs weekly exposes a week.

How to test an offline claim in twenty minutes

Run this before you sign anything, on a real device, with the vendor watching. Switch to airplane mode before opening the app, then cold start it. Create a job, enter twenty thickness readings, attach three photographs, mark an indication on a sketch, capture a signature, generate the PDF and open it. Force-quit the app entirely. Reopen it, still offline. Everything must be exactly where you left it, and the PDF must still open. Most products fail somewhere in the second half of that list.

Then run the harder half. On a second device, also offline, edit the same job — change one of the same readings and add readings at different CMLs. Reconnect both devices and check four things: no duplicate report number was issued, no reading disappeared, the genuine conflict was surfaced to a reviewer rather than silently resolved, and every examination timestamp still shows capture time rather than sync time. Finally, set one device's clock back three hours before syncing and see whether the system notices.

Turn those steps into written acceptance criteria and put them in your requirements document rather than leaving them as demo-day questions — the buyer-side checklist at /erp/ndt-software-rfp-requirements-checklist is structured for exactly that. If you are still deciding whether the underlying record model needs to change at all, the comparison at /ndt-reporting-software-vs-excel covers what a spreadsheet can and cannot hold. Atlantis builds NDT reporting and field capture to be affordable, accessible and fully customisable; ask us to run the twenty-minute test on your own job types at /contact or info@atlantisndt.com.

Request a consultation