DICONDE, ISO 15926 and what actually moves NDT data into a digital twin

DICONDE is DICOM's grammar applied to industrial examination

The design decision that shaped everything else was to harmonise with an existing standard rather than invent one. DICOM had already solved a structurally identical problem in medical imaging: many vendors, many modalities, images that had to be readable decades later on equipment that did not exist when they were acquired, and metadata that had to travel inseparably from the pixels. ASTM Committee E07 adapted that information model to non-destructive evaluation, and E2339 is the result.

What this inheritance buys is more than file compatibility. It brings a proven information model in which an examination is described as a structured set of information objects — the image or signal data, the equipment that produced it, the technique parameters in force, and the identifiers that bind them together. It also brings a network service model for storing and retrieving those objects between systems, rather than only a file layout. Archive software written against that model does not need modality-specific handling for every new instrument.

What it does not bring is any concept of a plant. DICOM's identity anchor is a patient, and the medical workflow supplies that identity from a hospital information system before imaging begins. Industrial NDE has no equivalent universal anchor arriving automatically. The nearest analogue is the asset owner's tag register, and nothing in the acquisition chain forces a technician's instrument to know it. That single structural difference explains most of the integration difficulty described further down this page.

The modality practices and what inheritance means in practice

E2339 is the base practice, and the modality-specific standards extend it rather than replace it. E2663 covers ultrasonic test methods, defining information modules for UT parameters and results that sit on top of the base practice and the underlying DICOM structures. E2738 covers computed radiography, E2699 digital radiography, E2934 eddy current, E2767 X-ray computed tomography, and E3440 thermography. Each supplies information object definitions, modules and dictionary entries appropriate to how that modality actually produces data.

The practical consequence for a specification writer is that a conformance claim naming only E2339 is incomplete for any specific inspection. A supplier stating DICONDE conformance for phased array ultrasonic work should be able to name E2663 alongside the base practice, and a supplier delivering computed tomography volumes should name E2767. Asking which designations apply is a fast and non-adversarial way to establish whether the claim has substance behind it.

There is also a guide, E3169, which orients readers to the family as a whole rather than imposing requirements, and an evaluation practice, E3147, which addresses interoperability between systems rather than conformance of one system. E3147 is the standard most frequently missing from procurement documents and the one that most directly predicts whether an integration will work. It exists because the industry discovered that mutual conformance does not guarantee mutual comprehension.

What a DICONDE file actually carries

A conforming file holds the examination data itself — the radiograph, the ultrasonic A-scan or volumetric dataset, the eddy current signal, the thermographic sequence — together with the parameters that produced it. For ultrasonic work that includes the acquisition configuration in the terms the modality uses. For radiography it includes the exposure and detector parameters. This is the standard's core value: the technique record travels with the data and cannot be separated from it by a file copy, a system migration or an archive restore.

It also carries structural identifiers inherited from the DICOM model — hierarchical identity for a study, series and instance, plus equipment and component-level fields. These are genuinely useful for organising an archive and for retrieving related examinations together. Where they cause trouble is when integrators assume they map cleanly onto plant asset structures, which they do not without explicit configuration decided in advance and applied consistently by every acquiring party.

The result is a strong archival and interpretive layer. Ten years after acquisition, a conforming file still tells a competent analyst exactly how the data was produced, which is precisely what a proprietary vendor binary from a discontinued product line does not. For fitness-for-service work, litigation, and jurisdictional review, that property alone justifies specifying DICONDE where the modality supports it well.

What DICONDE deliberately does not carry

It does not carry the owner's asset tag. There is no field whose defined meaning is "this examination belongs to vessel V-2104 in the owner's equipment register", enforced in a way that a receiving system can rely on. Integrators overload component identification fields to hold tags, which works within one organisation that agreed a convention and fails the moment a second contractor with a different convention delivers data into the same archive.

It does not carry position on a three-dimensional model. The standard describes an examination, not a location in a plant coordinate system. Where a scan sat on a vessel wall, which weld a shot covered, how a corrosion map registers against as-built geometry — none of that is in scope. Any digital twin that shows an examination in the right place is holding that relationship somewhere outside the DICONDE file, and how well it holds it determines whether the twin is trustworthy.

It does not carry inspection history or derived integrity results. Corrosion rate, remaining life, minimum required thickness, next inspection date and the comparison against prior campaigns are integrity management outputs, computed from a series of examinations rather than contained in any one. Expecting a file format to supply them is a category error that appears surprisingly often in requirements documents, usually phrased as a request for DICONDE support to deliver corrosion trending.

Where asset context lives instead: ISO 15926 and CFIHOS

The layer DICONDE leaves empty is occupied by plant information standards. ISO 15926 provides an upper-level ontology and reference data library for process plant lifecycle information, giving a common semantic basis for what equipment classes exist, which properties describe them, and how systems can exchange that meaning without agreeing on a single database schema. It is the vocabulary layer for the plant itself rather than for any examination of it.

CFIHOS — the Capital Facilities Information Handover Specification, which originated under USPI and moved to IOGP governance as Joint Industry Project 36 — narrows that ontology into something a project can actually contract for. It specifies which structured asset data and documents must be delivered at handover, how equipment attributes should be named, and which reference data describes equipment classes. Major operators including Shell, bp, Equinor and TotalEnergies participate in its governance, which is why it appears in handover specifications across the sector.

Neither standard says anything about how an examination result attaches to the asset it describes. That join — a persistent identifier shared between the inspection record and the asset register, plus a location reference within the asset — is left to the implementing organisation. It is unglamorous, it appears in no vendor datasheet, and it is the single most important design decision in a digital twin integration. Get it wrong and every conforming file in your archive is still orphaned.

Conformance is not interoperability, and E3147 exists because of it

Two systems can both conform to E2339 and still fail to exchange usable data. The mechanisms are well understood from DICOM's longer history. Optional modules that one system writes and the other ignores. Private data elements holding information the writer considers essential and the reader cannot interpret. Differing interpretations of how hierarchical identifiers should be populated. Partial implementations covering the modalities a vendor sells and no others. All of these are compatible with a truthful conformance claim.

ASTM E3147 addresses this by providing a practice for evaluating DICONDE interoperability between actual nondestructive testing and inspection systems, rather than assessing one system in isolation. The practical implication for a buyer is direct: a conformance statement in a datasheet is an input to your evaluation, not a conclusion from it. The question worth asking a vendor is not whether their system is DICONDE conformant but whether it has been interoperability-tested against the specific systems in your chain.

In procurement terms, the cheapest protection is a test rather than a clause. Take a real file from each instrument model your contractors actually use, send it through the proposed receiving system, and confirm that the parameters you care about survive the round trip and are retrievable afterwards. This takes a day. Discovering the same information after go-live takes a change order and a credibility loss.

What the instrument vendors actually export today

The honest position is that support varies by modality and by product line, and the safest assumption is that it varies within a brand as well. Radiographic and computed tomography workflows have the strongest DICONDE presence in the field, reflecting where the standard family started and where the medical analogy is closest. Waygate Technologies' Rhythm software suite stores images with DICONDE information and transfers files using the DICONDE protocol, which makes radiographic archives a comparatively solved problem.

Ultrasonic and eddy current instruments more commonly write native formats first. Evident's OmniScan X3 flaw detector produces .odat files and, on more recent onboard software, the newer .nde format, with WeldSight and OmniPC on the analysis side. Eddyfi Technologies' UltraVision family works in .uvdata and .beamdata alongside legacy .dat and .rdt files, and has extended its ability to open acquisition files from associated instrument lines. Zetec now sits within the Eddyfi group, which has consolidated some of this landscape.

The operational conclusion for anyone specifying a twin integration is to verify at the level of instrument model and firmware version rather than at brand level, and to write the verification into the mobilisation checklist. A contractor arriving with an older unit that cannot produce the specified export is a problem discovered on site, at the worst possible moment, and it is entirely preventable by asking the question during the bid.

The .nde open format and what it signals

Evident introduced .nde as an open file standard built on HDF5, the widely used hierarchical scientific data format, with a JSON-structured description layer. The stated design intent is that data files can be accessed without proprietary Evident software, opening the way for third-party developers and other NDT providers to read and potentially adopt the same format. On the OmniScan X3 line it sits alongside the legacy .odat format, with setup files unchanged.

Evident's published position is that .nde has advantages not available in DICONDE, without publishing a detailed technical comparison. Reading that fairly rather than defensively: HDF5 with a JSON schema layer is a modern, tooling-rich foundation that a software team can consume with standard libraries, whereas DICONDE requires a DICOM-family implementation. For an organisation building its own ingestion pipeline, that difference is significant in engineering effort.

The strategic signal matters more than the format choice. A major instrument vendor publishing an openly readable format is a direct response to owner pressure for data portability, and it means a receiving system should be built to handle multiple open formats rather than betting on one. A specification that names DICONDE per the relevant modality practice, .nde, or any documented open export with a published schema, and then tests each one against the real receiving system, is more robust than a specification naming a single winner.

The three joins where twin integration actually breaks

The first is instrument to identifier. A technician's instrument records a file name, a scan number and sometimes a free-text description. The twin needs the owner's asset tag and location identifier. Bridging that gap either happens at acquisition, by loading the register onto the instrument or into the field application, or it happens afterwards through manual matching, which is where transcription errors enter and where the same physical location acquires two identities across two campaigns.

The second is identifier to geometry. Having the correct location identifier does not tell the model where that location sits in space. Someone must have registered the identifier against a point, patch or component in the as-built geometry, and that registration must survive model updates when equipment is replaced or rescanned. Projects that treat this registration as a one-time setup task rather than a maintained dataset find their overlays drifting silently over successive campaigns.

The third is result to history. A single reading has almost no integrity value. Its value comes from comparison with the reading taken at the same point in the previous campaign, which requires that both campaigns agreed the point was the same. This is why identifier discipline matters more than file format elegance — a perfectly conformant file at a location nobody can match to last cycle's location contributes nothing to a corrosion rate. Our contractor-side guidance for closing all three joins at source is at /deliver-twin-ready-ndt-data.

What to write into a data specification

Name the standards precisely and pair them. For radiographic and computed tomography deliverables, require the base practice E2339 together with the applicable modality practice — E2699 or E2738 for radiography, E2767 for computed tomography. For ultrasonic and eddy current work, require either the relevant DICONDE modality practice, an open published format such as .nde, or a documented export with a schema you have reviewed. Never accept an undocumented vendor binary as an archival deliverable.

Then specify the layer the standards do not cover, because that is where the value is created. State the identifier scheme every result must carry and confirm it matches the register the client already maintains. State the location reference convention and the datum. State the required metadata: procedure and revision, equipment and calibration status, technician identity and certification level, date and campaign. State the submission route and the window. These lines are short and they determine whether the archive is usable.

Finally, require an interoperability demonstration rather than a conformance statement, referencing E3147 as the evaluation basis, and run it against the actual receiving system before mobilisation. If the twin platform, the archive and the instrument fleet have never been tested together, the specification is a statement of intent. Our buyer-side checklist at /erp/ndt-software-rfp-requirements-checklist covers the surrounding commercial questions, and /contact reaches our team if you want the technical clauses reviewed against your own instrument fleet.

Request a consultation