NDT Reporting Software for Phased Array UT: Storing and Sharing Scan Data
Phased array generates gigabytes of encoded scan data per weld, not a single number. Here's how reporting workflows actually need to store, link, and share it.
A phased array report is not a UT report with a picture attached
Conventional single-probe UT produces a result that fits comfortably on a paper form: a reflector, a depth, an amplitude, a distance from a reference point, evaluated against an acceptance table. Phased array ultrasonic testing (PAUT) produces something categorically different — an encoded, position-correlated data set covering the entire weld volume, typically saved as a proprietary file from whatever instrument acquired it (Olympus OmniScan .opd files, Zetec .uip or .zeta files, GE Krautkramer formats, and others), often running from tens of megabytes to several gigabytes per weld once you're scanning long seam welds or a full vessel course with an encoder. Treating that file the way an inspection company has always treated a UT report — print the summary sheet, attach a screenshot, file the folder — throws away the majority of the information the scan actually captured.
The practical problem this creates shows up months or years later, almost always at the worst possible time: a fitness-for-service evaluation is triggered on a vessel, or a client disputes an indication call from an inspection performed two turnarounds ago, and someone needs the original raw data — not the summary report, the actual A-scan and C-scan data behind a specific reportable indication — and it's sitting on a laptop that left the company with the technician who ran the scan, or on a USB drive nobody can find. A reporting system built for phased array work has to solve storage and retrieval as a first-class problem, not an afterthought bolted onto a form generator built for spot-check UT.
What actually needs to be captured, beyond the summary table
A complete phased array record for a single weld or component realistically includes several distinct data types, and a reporting workflow needs a place for each of them:
- Raw encoded data — the full data set as acquired, before any post-processing, gated, or filtered. This is what a Level III or a third-party reviewer needs if an indication call is ever challenged.
- C-scan and B-scan images — the plan-view and cross-sectional representations used for visual interpretation, typically exported as annotated images showing indication location relative to weld centerline and cap.
- TFM (total focusing method) or S-scan sector images, where used, for indications requiring higher-resolution characterization than a standard linear scan provides.
- Calibration and verification records tied to the specific probe/wedge/instrument combination used for that scan — reference block ID, DAC/TCG curve, sensitivity settings, and the date and result of the calibration check, per ASME Section V Article 4.
- Scan plan and procedure reference — the specific written procedure number and revision the scan was performed to, since acceptance criteria differ meaningfully between, say, ASME B31.3 Appendix criteria and AWS D1.1 Annex criteria for the same nominal indication size.
- Indication log — a structured list of reportable indications with position (weld ID, clock position or distance from a reference), amplitude, length, and disposition, cross-referenced to where in the raw data that indication lives.
Why file size breaks generic reporting tools
Most reporting platforms — and nearly every Word-template or generic form-app workflow — were designed around the assumption that a report is a document with a few photos attached, maybe 10-20 MB all in. Encoded phased array data blows past that assumption fast. A single long-seam scan on a large-diameter vessel course, captured with an encoder at fine index resolution, can produce a raw file well into the gigabyte range once you're not throwing away the unprocessed data. Multiply that across a turnaround where forty or fifty welds get scanned, and you're looking at hundreds of gigabytes of scan data that needs to be associated with the right report, retrievable years later, without the whole system choking.
This is where the difference between a form-filling tool and actual reporting infrastructure becomes visible. A system built for this needs to treat the encoded file as a linked asset tied to a specific weld ID and report — stored efficiently, with the report itself referencing the file rather than trying to embed it — so opening a report to check an indication doesn't require downloading a multi-gigabyte file every time, but the raw data is still one click away when someone actually needs to re-open it in analysis software.
Traceability: linking a specific indication to a specific frame of data
The part that separates an audit-defensible phased array record from a shortcut is whether a specific reportable indication in the summary table can be traced back to the exact position in the raw data set that produced it. When a fitness-for-service engineer or a third-party auditor asks "show me the data behind indication 7 on weld JT-114," the answer needs to be a specific cursor position in a specific file, not "let me see if I can find that in the export." Reporting workflows that log indications with a reference to file name, scan pass, and encoder position at the point of report generation — rather than reconstructing that link manually after the fact — save hours during any future review and remove a real source of error when a technician has to remember, months later, which scan pass a particular call came from.
Sharing scan data with clients without losing control of it
Clients increasingly want more than the summary report — especially owner-operators with their own Level III staff who want to independently review borderline indications, or EPC quality teams verifying fabrication welds before a vessel ships. That creates a real tension: the raw data needs to be shareable, but not in a way that lets it circulate uncontrolled, get separated from its calibration context, or get opened in a viewer that doesn't correctly render the original gates and DAC curve.
Practical approaches that hold up:
- Share read-only access to the specific scan file tied to a specific report through a reporting platform with access logging, rather than emailing raw files as attachments that then live forever in someone's downloads folder with no version control.
- Bundle the calibration record with the scan export by default, since a raw data file without its calibration and gain settings is close to meaningless for independent review.
- Keep proprietary viewer compatibility in mind — if a client's Level III uses a different OEM's analysis software, confirm the export format (or a converted format) actually opens correctly before promising deliverables in a proposal.
Retention periods matter more for phased array than people assume
Retention requirements for NDT records are usually framed around the report itself — API 510 and API 653 both drive multi-year retention expectations for pressure vessel and tank inspection records, and fabrication contracts frequently specify record retention tied to the design life of the equipment. What often gets missed is that the raw scan data carries the same retention obligation as the report, not a lighter one — because the report's conclusions are only defensible as long as the underlying data that supports them is still retrievable. An inspection company that retains the PDF summary for the contractually required period but lets the raw encoded files get purged from a technician's laptop after eighteen months has technically kept "the report" while quietly losing the ability to defend it.
Storage cost is a real conversation, not a hypothetical one
Gigabyte-scale files accumulating across years of inspection work add up to a genuine infrastructure cost, and it's worth having that conversation honestly rather than discovering it during a storage crisis. Tiered storage — keeping recently acquired data readily accessible and moving older, rarely accessed raw files to lower-cost archival storage while keeping the summary report and indication log instantly searchable — is a reasonable approach that most owner-operators will understand, as long as retrieval time for archived data is defined and reasonable (same-day, not "we'll get back to you").
Naming and tagging discipline determines whether the data is ever found again
None of the storage and linkage infrastructure matters if the underlying files aren't named and tagged consistently at the point of acquisition. A common failure pattern on growing phased array programs: Technician A names files by weld number, Technician B names them by scan sequence number assigned by the instrument software, and Technician C renames files after the fact based on whatever made sense to them that afternoon. Six months later, retrieving "the scan for weld JT-114 on the March turnaround" means someone manually opening a dozen candidate files to find the right one, because there was never an enforced naming convention tying the file to the job, the asset, and the weld ID at the moment it was saved.
The fix is procedural as much as technical: a written naming and tagging convention that's part of the phased array procedure itself, not a suggestion — job number, asset ID, weld ID, and scan pass encoded into the file name or, better, captured as structured metadata at upload rather than relying on the file name alone. Reporting software that requires this metadata before a scan file can be attached to a report enforces the discipline automatically, rather than depending on every technician remembering to do it correctly under field conditions and schedule pressure.
Raw data retention versus processed-only: a real trade-off, not a default
Some inspection companies, particularly once storage costs become visible, consider retaining only the processed summary images and indication log rather than the full raw encoded data set, on the logic that the summary captures everything anyone will ever need. This is a defensible position for some contracts and a real liability for others, and the difference is whether the client or the governing code expects the ability to independently re-analyze the original data. A fabrication shop doing routine production welds under a standard acceptance table may genuinely never need the raw data again once the summary is accepted. A pressure vessel fabricator supplying equipment into a fitness-for-service-sensitive industry, or an aerospace supplier under NADCAP oversight, is in a different position — the raw data is exactly what a future engineering evaluation or audit will ask for, and processed-only retention leaves the company unable to produce it. The safest default, absent a specific contractual reason to do otherwise, is retaining raw data for the same period the report itself is retained, and making the storage cost conversation explicit with clients and management rather than quietly trimming it to save space.
Review time: why a phased array report takes longer to check, not just longer to acquire
It's worth being honest with clients and with internal QA staff that a phased array report takes meaningfully longer to review properly than a conventional single-probe UT report covering the same weld, and reporting workflows and job scheduling should reflect that rather than treating "UT report" as a single time estimate regardless of method. A Level II or Level III reviewing a PAUT report isn't just checking a table of numbers against an acceptance criteria column — they're often reviewing C-scan images and, for flagged indications, cross-checking against the raw data itself, which is a materially different and slower review process. Reporting software that lets a reviewer navigate directly from an indication log entry to the relevant frame of image data, rather than requiring them to reopen the entire raw file and manually scrub to the right position, is the difference between a thorough phased array review taking twenty minutes and taking two hours per weld.
What to build into a phased array reporting workflow from day one
Inspection companies scaling up phased array capability — often because a client is moving away from radiography for weld inspection due to RT's radiation-safety logistics, especially on live plants where RT requires area clearance that PAUT doesn't — should treat scan data handling as part of the procedure qualification conversation, not an IT afterthought discovered after the first dispute. That means defining, before the first job: which raw data gets retained (all of it, not just flagged indications), how it's linked to the report and to the specific procedure revision used, who has access to re-open it, and how long it's kept. Getting this structure right from the first project prevents the alternative — a growing pile of orphaned scan files with no consistent naming, no link back to a report, and no way to answer a question about a five-year-old weld when a client calls asking for it. Level III oversight of the procedure, paired with reporting software actually designed to carry encoded data alongside the summary report rather than around it, is what keeps phased array work defensible long after the crew has moved to the next job.
Backing up field-acquired data before it ever reaches the office
A surprising amount of phased array data loss happens not through any software failure but through simple field logistics — a laptop or instrument gets damaged, lost, or has its storage overwritten before the day's scans are backed up anywhere else. Building an automatic or at-minimum end-of-shift backup step into the field workflow, syncing acquired data to a central system before the crew leaves site whenever connectivity allows, closes off the single most common and most avoidable way phased array data actually gets lost — not a sophisticated failure, just a full day of scanning that existed in exactly one place and stopped existing when that one place failed.
Atlantis NDT Products & Services
Atlantis NDT pairs field expertise with software: NDT inspection management software — Atlantis ERP, a digital twin platform for asset integrity, and NDT reporting software. Build your team with NDT training & certification (ASNT SNT-TC-1A) and ASNT certification pathways, or bring in ASNT Level III consulting. Affordable, accessible, fully customizable — book a free consultation.
When report turnaround is the bottleneck
Most inspection companies lose more hours to report formatting than to inspection. NDT reporting software compares the options for issuing the same dataset in several client formats without re-keying, the NDT inspection software buyer’s guide separates the four product categories that all get called “NDT software”, and the free evaluation checklist sets out the tests that actually separate marketing from capability.
Atlantis NDT Products & Services
Atlantis NDT pairs field expertise with software: NDT inspection management software — Atlantis ERP (certification tracking, work orders, method-specific reporting on every business app you need), a digital twin platform for asset integrity (3D corrosion mapping and inspection-data overlay), and NDT reporting software. Build your team with NDT training & certification (ASNT SNT-TC-1A) and ASNT certification pathways, or bring in ASNT Level III consulting for written practices, procedures and audits — plus independent inspection data review on API 510/570/653-governed assets. Capture as-built reality with 3D laser scanning services. Affordable, accessible, fully customizable — book a free consultation.