P&ID Digitization Data: Symbols, Lines and Instrument Tags

Why P&IDs need their own training data

P&IDs are schematic graphs, not dimensioned drawings, so models trained on mechanical CAD or general layout data transfer poorly. A P&ID encodes process topology: which pump feeds which vessel, which control loop measures which line, and which valve isolates which branch. The geometry is incidental; the connections are the payload.

That makes the task closer to graph extraction than to OCR. The Digitize-PID pipeline, for example, detects pipes, symbols and text separately, then associates them and checks the result against domain rules [1]. Later work treats the whole sheet as a graph and extracts symbols and their connections jointly with a transformer, noting that modular pipelines often fall back on Hough transforms for line detection [2]. Your dataset spec has to support whichever architecture you run, which in practice means labeling both the primitives and the edges.

If your models also consume dimensioned engineering drawings or PCB layouts, keep those in a separate request; the owner page for CAD and PCB design datasets covers that data, and the broader document AI datasets by task hub maps adjacent label layers.

What public P&ID datasets cover, and where they stop

Public P&ID data is enough to prototype but rarely enough to ship. Dataset-P&ID, released with Digitize-PID, contains 500 synthetic sheets with added noise and complex symbols; the authors evaluated real-world performance on 12 real, anonymized sheets [1]. PID2Graph adds a small real-world benchmark with graph labels, which is valuable for evaluation but not training scale [2].

The gaps that matter in production:

• Legend drift. Real sheets mix ISA-style instrument bubbles with company-specific equipment symbols, vendor packages and revision-era conventions. Synthetic sets draw from one fixed symbol library.
• Scan artifacts. Brownfield archives are scanned A1 or ANSI D sheets with fold lines, stamps, redlines, hatching and skewed title blocks.
• Off-page connectors. Real process lines leave the sheet and continue on another drawing number; a single-sheet dataset cannot teach cross-sheet stitching.
• License clarity. Community mirrors re-package the same data in YOLO or bounding-box formats, and license terms on mirrors are often missing or wrong, a pattern the Data Provenance Initiative measured across dataset hosts [7]. Check the original release terms before any commercial training use.

For a wider view of which document sets permit commercial use, see public document AI datasets and commercial-use terms.

Symbol conventions: ISA-5.1 plus the owner's legend

Symbol classes should follow ISA-5.1 for instrumentation and the drawing owner's legend sheets for everything else. As of October 2026, ANSI/ISA 5.1-2024 is the current edition of the standard that sets uniform means of depicting and identifying instruments [3]. It defines a designation system with symbols and an identification code, and it groups instrument graphics by function (discrete instrument, shared display or control, computer function, PLC) and by location (field-mounted, primary location, auxiliary location) [4].

Equipment symbols such as pumps, exchangers, vessels, compressors and specialty valves are far less standardized. Many owners use their own legend sheets, and older drawings may cite an earlier ISA revision. Ask suppliers to deliver the legend sheets with each drawing set and to map every local symbol to your canonical class list, with an explicit "unmapped" class rather than a forced guess.

A practical class taxonomy usually has three tiers: instrument function (the bubble shape and location line), equipment family (pump, vessel, heat exchanger), and valve or fitting type (gate, globe, ball, check, control valve with actuator type). Keep a separate attribute for the fail-position or actuator annotation so the class list does not explode.

Line types and connectivity labels

Line labels need both geometry and semantics, because line tracing errors propagate into every downstream graph. Each line segment should carry a polyline, a line-type class and the IDs of the nodes it connects.

Line types to label separately: major process lines, minor process lines, pneumatic signal, electric signal, capillary, software or data link, and hydraulic, plus any owner-specific types in the legend. Flow arrows, line numbers (often encoding size, service, line sequence and piping spec), insulation codes and spec breaks should be labeled as attributes of the line, not as free-floating text.

The hardest cases are crossings versus junctions, line jumps, dashed signal lines that cross process lines, and lines that terminate at off-page connectors. Ask for an explicit label on every crossing, because a model that cannot distinguish a crossing from a tee will produce a wrong graph that still looks plausible.

Instrument tag extraction and text labels

Tag text should be transcribed verbatim and also parsed into structured fields. An ISA-style tag combines function letters with a loop number (for example a flow transmitter in loop 101), but ISA notes that functional tagging by primary variable is a basic tenet that real practice often departs from [4]. Your labels must record what is on the drawing, not what the standard says should be there.

Label text at three levels: the full tag string with its bounding box, the parsed function letters and loop number, and the association to the symbol it belongs to. Do the same for line numbers, equipment numbers, set points and notes. Rotated and vertical text, text overlapping lines, and tags split across two lines inside a bubble are common failure modes for OCR engines; the OCR ground truth data guide covers transcription conventions in more depth.

Graph ground truth from intelligent P&ID source files

Where drawings were authored in an intelligent P&ID tool, the native project data can supply a connectivity graph that is more complete than manual tracing. These tools store equipment, lines and instruments as objects with relationships, which can be exported to a neutral exchange format or a database extract and aligned to the rendered sheet.

This alignment is not free. Exported objects may not match what is printed (hidden items, revision mismatches, symbols drawn as graphics rather than objects), and coordinates need a transform into page pixel space. Ask suppliers which revision the export reflects, whether it matches the issued-for-construction or as-built sheet you receive, and how unmatched objects are flagged. Treat manual tracing as the fallback for scanned brownfield sheets that have no source model.

A practitioner write-up of a P&ID digitization pipeline describes the same staged structure of symbol, text and line detection feeding graph assembly [5], which is why buyers usually want labels for each stage rather than only an end-state graph.

Annotation record and file layout

A record should bind one sheet image to its symbols, lines, text and edges with stable IDs, so you can train stage models and graph models from the same source. COCO-style JSON (info, licenses, categories, images and annotations sections) works for boxes and polygons and is supported by tools such as CVAT [6]; carry graph edges and tag parses in a sidecar file keyed by the same IDs.

Illustrative example: invented to show structure; it does not describe an available dataset.

{
  "sheet_id": "PID-0420-R3",
  "drawing_number_masked": "SITE-A/UNIT-2/PID-0420",
  "revision": "R3",
  "status": "as-built",
  "source": "scan_300dpi",
  "legend_ref": "LEG-001-R1",
  "symbols": [
    {"id": "s1", "class": "instrument.field.discrete", "bbox": [1820, 940, 64, 64], "tag_id": "t1"},
    {"id": "s2", "class": "valve.control.globe.pneumatic", "bbox": [2010, 1130, 48, 72], "fail_position": "FC"},
    {"id": "s3", "class": "equipment.pump.centrifugal", "bbox": [1400, 1500, 120, 110], "equipment_no": "P-201A"}
  ],
  "lines": [
    {"id": "l1", "type": "process.major", "polyline": [[1520,1550],[2010,1550],[2010,1200]], "line_number": "4\"-PW-1023-A1", "flow_dir": "forward"},
    {"id": "l2", "type": "signal.electric", "polyline": [[1852,1004],[2034,1130]], "crossings": ["l1"]}
  ],
  "text": [
    {"id": "t1", "raw": "FT 101", "bbox": [1828, 958, 48, 28], "function_letters": "FT", "loop": "101"}
  ],
  "edges": [
    {"from": "s3", "to": "s2", "via": "l1"},
    {"from": "s1", "to": "s2", "via": "l2", "kind": "signal"}
  ],
  "off_page": [{"line_id": "l1", "connector_text": "TO PID-0421", "target_sheet": "PID-0421-R2"}]
}

Before you accept a delivery, sample sheets and re-trace them independently; the method in auditing annotation quality before acceptance applies directly, with edge-level precision and recall as the key metric.

Buyer checklist for a P&ID data request

A strong request names the drawing population, the label layers and the masking rules up front. Use this checklist when you scope a supplier or an annotation vendor.

Illustrative example: invented to show structure; it does not describe an available dataset.

Rights, security and masking for facility drawings

Facility drawings can reveal how critical infrastructure is built, so site identifiers should be masked by agreement before release. Typical masking targets are site and unit names, plant coordinates, owner and contractor logos in title blocks, and drawing numbers that reveal project codes. Agree in writing which fields are masked, replaced with consistent pseudonyms (so cross-sheet references still resolve), or kept.

Rights are often split. An EPC may have authored the drawings under contract for an owner, and the owner may restrict reuse; title-block approvals and personal names of engineers are also present on most sheets. Ask who holds the right to license the drawings for model training, and treat engineer names and signatures as personal data to remove. Engineering consultancies weighing their own position can see buyers by industry: engineering consultancies.

How SourceX approaches P&ID requests

SourceX sources operational datasets, including engineering records and documents, from US companies on request; it does not hold P&ID data in stock, and a request does not guarantee a match. Buyers describe the data they need, and SourceX looks for US businesses that hold it; every release is approved by the supplying company. Each dataset is rights-reviewed for ownership and consents, personal details are removed or replaced before delivery with the method recorded and a sample checked, and delivery runs through private, access-controlled workflows only after an executed agreement. You can start by describing your drawing population and label layers on the SourceX buyer intake.

Sourcing licensed P&ID datasets

If you need real P&IDs with symbol, line, tag and graph labels for digitization models, write down the drawing population, standards and masking rules from the checklist above. SourceX manages the process from finding a supplier through assessment of data and licensing permissions to a license that defines records, uses, term and delivery; nothing is contracted until a supplier agrees. Describe the P&ID data you need.