In this article12 sections
DEXPI is the closest the process industry has to a vendor-neutral exchange format for P&ID data. Version 1.3 is the current release, and several major P&ID tools already offer DEXPI export.
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. Instrumentation functions record what they measure or act on, and where. Lines carry their 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 written against the Proteus schema, version 4.1.1. Its main elements.
- PlantModel. The root. One plant model, usually one P&ID sheet or a connected set of sheets.
- PlantInformation. The header. Schema version, originating system, export date and time, units and discipline.
- MetaData. The title block as data. Drawing number and name, revision, sheet number, plant area, and who drew, checked and approved it.
- Equipment. Pumps, vessels, exchangers, columns, tanks, every named equipment item, with its nozzles.
- PipingNetworkSystem. One per line, holding the segments, valves and fittings that make up the pipe runs.
- ProcessInstrumentationFunction. One per instrument bubble, with its measuring and actuating functions and the signal lines that belong to it.
- Drawing and ShapeCatalogue. The sheet itself and the library of symbols the file draws with.
The classes come from a closed list in the specification, and every class carries a URI into reference data. Dozens of those definitions come from the POSC Caesar library that implements ISO 15926-4. 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 tank, in the shape the DEXPI reference files use and trimmed to its data, looks like this.
<Equipment ID="Tank-1" ComponentClass="Tank"
ComponentClassURI="http://data.posccaesar.org/rdl/RDS445139"
ComponentName="VESSEL_WITH_DISHED_HEADS_SHAPE">
<GenericAttributes Set="DexpiAttributes" Number="2">
<GenericAttribute Name="TagNameAssignmentClass" Format="string" Value="V-101"/>
<GenericAttribute Name="NominalCapacity(Volume)" Format="double" Value="26" Units="MetreCubed"/>
</GenericAttributes>
<Nozzle ID="Nozzle-1" ComponentClass="Nozzle"
ComponentClassURI="http://data.posccaesar.org/rdl/RDS415214">
<ConnectionPoints NumPoints="3">...</ConnectionPoints>
<GenericAttributes Set="DexpiAttributes" Number="1">
<GenericAttribute Name="SubTagNameAssignmentClass" Format="string" Value="N1"/>
</GenericAttributes>
</Nozzle>
</Equipment>
Each attribute also carries its own URI, left out here. Attributes the specification defines go in the DexpiAttributes set. Anything a project adds goes in a separate set, such as DexpiCustomAttributes, on the same object, so a receiving tool can tell the portable layer from the project's own.
Piping and connectivity
DEXPI groups each line into a PipingNetworkSystem, which carries the line number, fluid code, nominal diameter and piping class. The system holds one or more PipingNetworkSegment elements, the runs that make up the line. Each segment carries.
- Piping class, nominal diameter, fluid code and insulation
- Heat tracing and operating temperature where the project records them
- Flow direction
Connectionelements naming the item and node each run comes from and goes to
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.
Valves, fittings and reducers are PipingComponent items inside the segment, joined by those connections. A reducer is a PipingComponent of class PipeReducer, sitting in the segment between the two pipe sizes it joins. A line that leaves the sheet ends at a PipeOffPageConnector.
Instrumentation
DEXPI models instrumentation as functions rather than devices. Each instrument bubble on the sheet is a ProcessInstrumentationFunction, and every one carries.
- Its number, and its letters split into the measured variable and the functions, such as
FandIC - Where it sits, in the field, in a central control room or on a panel
- Safety and quality relevance where the project records them
- Links to what it measures or acts on, the pipe, nozzle or valve
Control loops are explicit. A flow loop drawn as FT-101, FIC-101 and FV-101 is written as.
- A
ProcessInstrumentationFunctionfor each instrument bubble - A
ProcessSignalGeneratingFunctionfor the measurement, located in the pipe or nozzle it senses - An
ActuatingFunctionwhose actuating system refers to the control valve in the piping - A measuring line and a signal line between them, each an
InformationFlow - An
InstrumentationLoopFunctionthat every function in the loop is part of
DEXPI 1.3 gives an instrument function no measuring range and no I/O signal type such as 4-20 mA or HART. Signal lines are typed only by what carries them, electrical, pneumatic, hydraulic, capillary or conducted radiation. Ranges and I/O types belong in the instrument index and the I/O list, or in custom attributes agreed with the receiving system.
The graphics layer
DEXPI carries the drawing layout alongside the data. A plant item can carry a Position, its location and orientation in drawing coordinates, and a ComponentName that names its symbol in the file's ShapeCatalogue. Presentation holds the layer, colour, line type and weight. Pipe segments carry their route as CenterLine geometry, and labels carry their own text and position. 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, with a Format such as string or double. A physical quantity carries its unit as Units plus a units URI, so values are unambiguous. An upper design pressure of 10 with Units="Bar" cannot be misread as 10 psi.
The attribute names come from the DEXPI specification, and each one carries its own URI into the DEXPI reference data. Custom project attributes go in their own attribute set on the same object, but the standard attributes are what consumers can reliably parse.
Versioning
DEXPI 1.3 is the current release, written against Proteus schema 4.1.1. Files from 1.2 and earlier are still in circulation on older projects. The versions differ in their schema, so agree the version with the receiving system rather than assuming a newer file loads into an older reader.
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.
- 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 seed the equipment register and the instrument index instead of keying them in from drawings.
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 with no DEXPI class goes in as
CustomEquipment, or a custom class such asCustomVessel, with a free-text type name. 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.
Where Tagsight fits
Tagsight exports reviewed P&ID data as DEXPI as one of its export formats, so the receiving tool starts from what the engineers confirmed against the drawings.
If your customer or your operator is building a digital twin, DEXPI export can 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.