DEXPI 1.3 Schema Explained. Process Industry Data Exchange in Practice.

DEXPI is the closest the process industry has to a vendor-neutral exchange format for P&ID data. Version 1.3 has been around long enough that most major P&ID tools support it, and operators with digital twin programs increasingly require DEXPI export as a contractual obligation.

The problem DEXPI is solving

A P&ID drawn in one CAD package and exported as a DXF or PDF loses most of its data on the way out. The graphics survive. The intelligence behind the graphics, the equipment classes, the connectivity, the attributes, the instrument ranges, does not. Anyone receiving the DXF has to re-derive that information by reading the drawing, often by hand.

DEXPI is a structured XML representation that carries the intelligence as data. Equipment items are classes with attributes. Instruments have ranges and signal types. Lines have specs and traced connectivity. The graphical layout is preserved as well, but it is secondary to the data layer.

Schema structure at a glance

A DEXPI 1.3 file is XML organized around a few top-level concepts.

• PlantModel. The root. Contains everything about one P&ID or one connected set of P&IDs.
• Equipment. Pumps, vessels, exchangers, columns, tanks, every named equipment item.
• Piping. Pipe runs, fittings, and the lines that connect equipment.
• Instrumentation. Field instruments, control loops, and signal lines.
• Drawing. The graphical layout. Coordinates, symbol placements, line routes, labels.
• MetaData. Drawing identification, revision, source tool, export date.

The classes are drawn from a controlled vocabulary that is tied to the ISO 15926-4 reference data library. So a centrifugal pump in DEXPI is a CentrifugalPump, not a free-text label, and the class is the same across every conforming exporter.

Equipment representation

An equipment item in DEXPI carries.

• A class, matched to the reference data library
• A tag identifier
• A set of typed attributes
• Connection points, nozzles with positional and functional information
• Optional graphical representation with coordinates

A vessel might look like.

<Equipment ID="V-101" ComponentClass="VerticalVessel">
  <GenericAttributes Set="DexpiAttributes">
    <GenericAttribute Name="DesignPressure" Value="350" Units="kPa"/>
    <GenericAttribute Name="DesignTemperature" Value="180" Units="degC"/>
    <GenericAttribute Name="MaterialOfConstruction" Value="CS"/>
  </GenericAttributes>
  <Nozzle ID="V-101-N1" ...>
    <ConnectionPoints>...</ConnectionPoints>
  </Nozzle>
</Equipment>

The attribute set is open. Vendors and projects can add custom attributes alongside the DEXPI-standard ones, but the standard ones are the portable layer.

Piping and connectivity

DEXPI represents pipe runs as PipingNetworkSegment elements that connect named connection points. Each segment carries.

• Line specification, material grade, schedule, insulation
• Operating and design conditions
• Flow direction
• Connectivity to upstream and downstream items

The connectivity is what makes DEXPI useful for downstream tooling. A target system can walk the pipe network from feed to product without re-parsing the drawing geometry.

Fittings, reducers, and inline equipment are first-class citizens of the piping network. A reducer is a Reducer element that sits in a PipingNetworkSegment and connects two pipe portions of different sizes.

Instrumentation

The instrumentation section carries.

• Process instruments, transmitters, gauges, switches
• Process control functions, controllers, alarms, interlocks
• Signal lines connecting instruments to control functions and to actuated equipment

Every instrument carries.

• Tag identifier
• Class, matching ISA 5.1 functional decomposition where applicable
• Range and units
• Signal type, 4-20 mA, HART, Foundation Fieldbus, discrete, software
• Connection to the measured variable's location in the process

Control loops are explicit. A flow control loop with FT-101, FIC-101, and FV-101 appears as three instrument elements plus a ProcessSignalGeneratingFunction and ProcessSignalReceivingFunction that wire them together.

The graphics layer

DEXPI carries the drawing layout in a separate but linked structure. Every equipment item has an optional Presentation element that locates it in drawing coordinates with a chosen symbol. Pipe segments have route geometry. Labels have positions. The graphics are preserved well enough that a conforming consumer can render an approximation of the original drawing.

The graphics layer is intentionally lossy compared to the source CAD file. DEXPI is not trying to be a full graphical exchange format. It is trying to preserve enough layout for a consumer to display the data meaningfully.

Attributes and the reference data library

Every attribute on every item is named and typed. The unit is part of the attribute, so values are unambiguous. A design pressure of 350 with units kPa cannot be misread as 350 psi.

The attribute names come from the DEXPI specification, which in turn aligns with ISO 15926-4. Custom project attributes can be added under a separate namespace, but the standard attributes are what consumers can reliably parse.

Versioning

DEXPI 1.3 is the version most current implementations target. 1.2 and earlier are still in service on older projects. The schema is forward-compatible in the sense that a 1.2 consumer reading a 1.3 file can usually parse the elements it knows and ignore new ones, but full fidelity requires matching versions.

When teams pick DEXPI

A few project contexts where DEXPI is the right answer.

• Digital twin handover. The operator is building or maintaining a digital twin and wants the P&ID data in a vendor-neutral format. DEXPI is now the default for this on greenfield projects in the EU and increasingly in the Middle East.
• Multi-vendor engineering. Two EPCs working different parts of the same plant on different P&ID tools need to exchange data. DEXPI is a more reliable handoff than DXF or vendor-native files.
• Long-term archival. The plant operator wants documents that will still be readable in 20 years regardless of what CAD tooling exists then. XML on a published schema is more durable than a vendor file format.
• Asset information management. The operator's AIM system ingests DEXPI to populate the equipment register and the instrument index without manual data entry.

A few contexts where DEXPI is the wrong answer.

• Day-to-day editing. The native CAD file is faster to edit and the round-trip through DEXPI loses non-standard attributes.
• Fully graphical handover. If the consumer just wants a viewable drawing, a PDF is simpler.
• Brownfield with no source CAD. If the only source is a scanned legacy drawing, DEXPI export from the scan is non-trivial.

Where DEXPI exports break

A few patterns that cause grief.

• Custom equipment classes. A piece of project-specific kit that does not have a DEXPI class often ends up exported as a generic Equipment element. The downstream consumer cannot infer what it is from the class alone.
• Inconsistent attribute units. Different authoring tools sometimes export the same attribute with different unit strings. The consumer has to normalize.
• Incomplete connectivity. If the source drawing has loose ends, the DEXPI export carries the loose ends. The consumer cannot trace through them.
• Graphical fidelity loss. Custom symbols, hand-drawn annotations, and embedded photos do not survive the export.

A pre-handover validation pass against the receiving system's parser is the cheapest way to catch these.

How tag-extraction tooling produces DEXPI output

A document-extraction system that produces DEXPI has to do more than read tags. It has to.

• Classify equipment into the DEXPI controlled vocabulary
• Trace pipe and signal connectivity, not just identify objects
• Capture instrument ranges and signal types
• Handle off-page connectors as cross-drawing references
• Preserve enough layout for a viewable presentation

Tagsight produces DEXPI 1.3 export as one of its eight export formats. The output carries equipment classes, traced connectivity, and layout, consumable by Aveva, Hexagon, and Bentley P&ID tools, and by ISO 15926-aligned asset information systems.

If your customer or your operator is building a digital twin, DEXPI export will eventually appear in your scope of work whether you planned for it or not. Designing the project document set to be DEXPI-ready from the start is less work than retrofitting it at handover. The minimum is consistent equipment classification, traced connectivity, and unit-tagged attributes. Get those right and DEXPI export becomes a derived document rather than a redo. The P&ID digitization guide covers the drawing-preparation and extraction steps that generate the structured source data DEXPI export depends on.

Further reading

• DEXPI Specification, current version 1.3
• ISO 15926-4 Industrial automation systems and integration
• ISO 15926-2 Data model for the process industries
• DEXPI Working Group publications and conformance test suite