PAUT Open File Formats: Test Data Portability Before Buying

Define the portability decision before comparing instruments

A PAUT buyer may want several different things from an open file format: access to stored arrays, a functioning engineering viewer, independent analysis, integration with an asset system, or long term preservation. These are separate purchasing requirements. Write the first intended use as an action performed by a named role. For example, a data engineer must extract approved location and thickness fields into the owner's database, while a qualified reviewer continues to examine the source in the manufacturer's application. That requirement is narrower and easier to test than a promise of complete independence from the supplier.

Give the proposed use a boundary. Identify the instrument family, acquisition software version, receiving application, supported inspection configuration and expected output. Include what will remain outside the exercise, such as independent reconstruction or acceptance evaluation. An equipment buyer should not silently transform a database integration project into development of a new inspection analysis system. If a later business requirement needs more functionality, it deserves its own technical review, resources and evidence.

Assign a technical owner and a data owner to the decision. The technical owner decides whether displayed quantities retain the required meaning. The data owner checks structure, permissions, reproducibility and storage. Purchasing records commercial dependencies. One person can hold multiple roles in a small business, but the written acceptance questions should remain distinct. A successful demonstration by a programmer is not, by itself, evidence that an inspection conclusion can be reproduced.

Understand what .nde and HDF5 actually establish

Evident describes its .nde format as using HDF5 with associated descriptive information and documents a historical transition from .odat with MXU 5.11. The HDF Group describes HDF5 as a portable container for heterogeneous datasets. These sources establish useful architectural facts. They do not establish that every third party inspection application supports every .nde file, or that a general HDF5 viewer understands ultrasonic semantics. Review the manufacturer FAQ and HDF5 overview when defining the test.

Treat opening, understanding and using as three different observations. Opening means the software can access the container without an error. Understanding means the relevant values, units, dimensions and relationships have documented meanings. Using means the intended business task can be completed correctly within the agreed constraints. A screen showing many datasets establishes only the first observation. Ask the supplier to demonstrate the other two with a representative file and keep the resulting evidence with the quotation.

Do not call the format universally adopted or describe the historical release as a new development. The FAQ includes statements tied to the software available at that release. Present day compatibility must come from the actual software versions being purchased and tested. Record those versions beside the evidence rather than assuming an older article is a complete current compatibility matrix. If a vendor promises a future reader, record it as a dependency that remains unresolved.

Request a specimen package that represents your purchase

Ask for a sanitized demonstration package generated by the proposed configuration, with permission to use it for the evaluation. A generic sample downloaded from an unrelated instrument can help a developer learn the structure, but it cannot settle whether your planned configuration exports the required information. Include the source file, the relevant setup description, a reference display or approved report excerpt, and a short statement of the features the sample is intended to demonstrate. Use authorized sample data rather than confidential customer files.

Select a small set of cases that exercise your actual integration risks. A straightforward file can establish basic access. A second file might represent multiple acquisition groups, a different location convention or an intentionally absent result. The responsible technical specialist should choose meaningful cases without introducing unapproved inspection conditions. The procurement exercise is about software compatibility; it does not prescribe scanning settings or validate a method for production use.

Record a unique sample identifier and a stable copy of each supplied file. Keep the source unchanged and perform evaluation on working copies. The acceptance sheet should identify which file supports each result so that a later software revision does not quietly replace the evidence. When the supplier supplies a new sample to resolve an issue, retain the relationship to the earlier case and explain why the replacement was necessary.

Record schema versions and distinguish fields from assumptions

A schema describes an expected structure, but a reader still needs to know which schema applies. Evident's public repository includes a versioned NDE schema, which provides a concrete example of documented structure. Cite the relevant schema version as an example, not as a claim that this version governs every available instrument. Ask how the supplied file identifies its own version and what the receiving software does when it encounters an unsupported one.

Build a field map for the particular output you need. Each row should contain the business field, source location or documented reference, meaning, units, permitted absence, transformation and reviewer. The mapping is an original project artifact, not a universal .nde parsing recipe. Avoid guessing a value from a similarly named field. If the supplier cannot explain which field represents the required quantity for the chosen acquisition, leave the mapping unresolved instead of inventing a plausible interpretation.

Separate source values from calculated values in the output. A value copied from a documented field and a value derived by your software have different review needs. For a calculation, record the approved method, required inputs, rounding policy and validation evidence. Do not place a calculated output in a column labeled raw measurement without explanation. The distinction will matter when another reviewer compares the export with a display that applies its own presentation or processing choices.

Test dimensions, units and missing data explicitly

A common integration mistake is to produce reasonable looking numbers with the wrong context. Ask the reviewer to select known reference locations in the demonstration file and compare them with the receiving output. Confirm the meaning and ordering of each axis used by the integration, the association with the correct acquisition group, and the units shown to the user. Do not infer axis orientation from how an array happens to appear in a development tool.

Include missing, invalid or unavailable values in the exercise where the supplied sample supports them. An empty field, a stored indicator and a numerical zero may have different meanings. The receiving application must follow the documented meaning instead of replacing all three with a convenient default. Agree how an unresolved value appears in the business system and who investigates it. A tidy spreadsheet that silently converts unknown results into valid readings is a failed integration.

Check the exported identifier as carefully as the numerical result. A correct value assigned to the wrong component or location can be more difficult to detect than an obvious file error. Compare a few deliberately selected records that have similar names, repeated positions or multiple acquisition segments. Document the expected relationship before running the test. This makes the exercise a check of a defined mapping rather than an informal search for numbers that look familiar.

Compare the intended output with an agreed reference

Create a comparison sheet with one row for each acceptance question. Record the expected observation, actual observation, source file, software version and reviewer decision. Examples include retaining the location identifier, displaying the expected unit label, distinguishing absent data, and producing a complete record count for the chosen subset. The technical reviewer defines appropriate numerical comparison criteria where needed; this guide supplies no universal tolerance for software agreement.

Investigate disagreements instead of adjusting outputs until the displays match. Differences may come from a mapping error, a documented conversion, presentation rounding, an unsupported feature or a genuine software problem. Record the explanation and its evidence. If the explanation changes the intended use, revise the acceptance requirement openly. A demonstration should expose limits before purchase, not turn those limits into undocumented assumptions hidden inside an extraction script.

Preserve unsuccessful cases. A case that remains unsupported can still inform a sound purchase if the buyer accepts a clear boundary and retains a suitable workflow for it. For example, an integration may support location indexing while all technical analysis remains in an approved application. That is a narrower capability than independent analysis, but it can still solve a useful business problem. The quotation and implementation plan should describe the narrower capability accurately.

Make failure behavior part of acceptance

Ask what happens when the receiving program sees a newer schema, a missing required field or an unavailable external dependency. A clear unsupported message is often more useful than partial output presented as complete. Require the integration to communicate its limits in terms the intended user can understand. The buyer should know whether a failed import leaves no records, partial records requiring review, or an explicitly marked exception queue.

Test failure handling with copies or supplier provided examples under an agreed evaluation plan. Do not corrupt retained inspection evidence to create a demonstration. A developer can prepare a controlled test fixture while the original remains untouched. Keep a record of what was changed and why. The technical owner should confirm that the resulting test establishes software behavior only and does not represent an actual inspection result.

Include a repeatability check on a clean receiving environment. A workflow that works only on the supplier's laptop may depend on an unlisted library, license, account or local configuration. Record those dependencies when they appear. The objective is not to eliminate every dependency; it is to identify the ones the buyer will need to maintain and to avoid discovering them after the instrument has entered service.

Price the ongoing reader responsibility

Open documentation can make custom integration possible without making development or maintenance free. Identify who will maintain the field map, monitor version changes, investigate unreadable files and rerun the acceptance cases. Estimate these responsibilities separately from the instrument price. A small inspection provider may reasonably prefer supported analysis software even when the file format is open, because the provider does not want to own a specialist reader.

Ask commercial questions about the complete workflow. Which application functions require a paid license, which viewer functions remain available, what support is included, and what happens when a subscription or support term ends? Confirm the answers for the quoted package rather than relying on a screenshot of an available download. An open container does not automatically provide the supplier's analysis interface, reporting tools, remote control functions or technical support.

Keep the evidence usable for future equipment decisions. Store the tested software versions, sample identifiers, mappings, unresolved limits and acceptance results together. When a firmware or analysis software change is proposed, this package provides a starting point for deciding what must be checked again. It does not authorize the update automatically. Link the review to the instrument's software change record.

Work through a hypothetical purchase decision

Consider a fictional U.S. inspection company evaluating two PAUT packages. Its customer requires a location index in an asset database and access to the original inspection files for qualified review. Package A demonstrates a documented extraction of identifiers and selected approved fields. Package B opens the source file in a general viewer but has not demonstrated the field mapping. The company should record those as different evidence states even if both brochures use the word open.

During the hypothetical test, Package A preserves location names but drops an absent result indicator. The team does not approve the integration merely because most rows match. It asks for the missing value behavior to be corrected or clearly limited, then repeats the affected case. The source analysis remains in the supported manufacturer application throughout. This example illustrates a procurement decision process; it claims no result for a real vendor or inspection.

The final decision note states the approved use, the tested versions, the remaining software dependency and the owner of future reviews. It might approve database indexing while declining to claim independent reanalysis. Attach the evidence to the purchase record and retain the acceptance sheet outside NDT Connect. The free equipment tracker can hold the instrument identity, status, due date and a concise reference in notes; it does not parse .nde files, validate schemas or store an integration audit trail.

Use the acceptance package when negotiating delivery

Make the compatibility result a deliverable in the purchase file. Identify the tested configuration, evidence location, unresolved items and person authorized to accept a change. If a different software edition is substituted before shipment, ask whether the existing results still apply. The purchase coordinator can compare the delivered identifiers with the agreed configuration without attempting to decide technical equivalence independently.

Avoid making an unsupported promise to your own customer while the integration is still being evaluated. State whether the proposed deliverable is a native file, a documented database extract, a supported analysis environment or a combination. Describe any limitation that affects the customer's intended use in the proposal itself. This allows the customer to decide whether the narrower deliverable is useful before relying on it for a future review.