Hand an experienced process engineer an unfamiliar P&ID and watch what they do. They do not read it left to right. They check the title block for the unit and the revision, glance at the legend, find the major equipment, then follow lines: out of a vessel nozzle, through a control valve station, past a crossing, off the sheet to the drawing the off-page connector names. A few minutes later they can tell you what the sheet does.
That skill is reading a drawing as a network that obeys a grammar. Software has to do the same before a P&ID is useful as data. Here is what that grammar looks like, why text recognition plus symbol detection falls short, and how a typed graph holds what an engineer sees.
Start with the legend
Every P&ID set is written in a symbol language, and its legend sheets say which one. Usually several are in play.
ISA 5.1, Instrumentation Symbols and Identification, governs how instruments and control functions are drawn and tagged. The balloon shape says what carries a function: a plain circle for a discrete instrument, a circle in a square for a function shared on a control system display, a hexagon for a computer function, a diamond in a square for a PLC. Horizontal lines through the balloon say where the device sits and whether an operator can normally reach it. Signal lines have their own vocabulary, with dashed lines for electric signals, double hatch marks for pneumatic ones and small circles for a software or data link.
ISO 10628, common on plants designed to European practice, covers diagrams for the chemical and petrochemical industry, from block diagrams and process flow diagrams to P&IDs. Its graphical symbols build on ISO 14617, a multi-part series of graphical symbols for diagrams covering valves, pumps, compressors, heat exchangers, actuators and more.
Owner legends sit on top of both, adapting a standard, adding symbols and fixing local conventions. On many legends a valve drawn with a filled body is normally closed. On others the same fact is written as NC beside the valve.
A single unit's drawings often span decades of conventions, and vendor packages such as a compressor skid arrive drawn to the vendor's rules. An engineer reads the legend first and adjusts. Software has to do the same: a model with one universal picture of a gate valve will misread a set whose legend disagrees, and do it confidently. That is why our detection covers proprietary symbol libraries alongside ISA 5.1 and ISO 14617.
The grammar inside a tag
Tags on a P&ID are compressed records, and most of their segments are keys into another document. A line number identifies one engineered line, usually from one piece of equipment or header to another, in a format set per project. An instrument tag under ISA 5.1 combines identification letters with a loop number. Two illustrative tags, 6"-P-1204-A1A-H and FIC-101, break down like this:
| Segment | Example | What it carries | Where it resolves |
|---|---|---|---|
| Line: nominal size | 6" | Nominal pipe size | Line list |
| Line: service code | P | Fluid or service, here process (CW, IA or LPS on other lines) | Legend sheet |
| Line: sequence number | 1204 | Unique line identifier, often with an area or unit prefix | Line list |
| Line: piping class | A1A | Pressure-temperature rating, materials, corrosion allowance, wall thickness, permitted valves and fittings | Piping material specification |
| Line: insulation code | H | Insulation or tracing requirement, here heat conservation | Insulation specification |
| Instrument: first letter | F | Measured or initiating variable, here flow | ISA 5.1 identification letters |
| Instrument: succeeding letters | IC | Functions: indicate (I) and control (C) | ISA 5.1 identification letters |
| Instrument: loop number | 101 | Ties the device to every other device in its loop | Instrument index and loop diagrams |
A handful of rules do much of the work:
- Modifiers change meaning. A letter after the first can modify the variable rather than name a function. PD is pressure differential, so PDI is a differential pressure indicator. In PSV, the S marks a safety function.
- Function modifiers set levels. H, L, HH and LL mark alarm and trip points, so LAHH is a level alarm, high-high.
- The loop number binds devices. FE-101, FT-101, FIC-101 and FV-101 are the primary element, transmitter, controller and control valve of one flow loop. Read separately, they are four labels.
- Local conventions vary. P-101A/B is a pump with an installed spare almost anywhere, but C is a column at one site and a compressor at the next, and a relief valve is PSV on one legend and PRV on another.
The grammar is also the best defense against misreads. A loop number is numeric, so an O in that position is a zero. A piping class has to exist in the piping material specification, and a service code has to appear on the legend. A reader that knows the grammar can reject strings that cannot be right. A reader that only knows characters cannot.
Connectivity is the hard part
Symbols and tags tell you what is on a sheet. Lines tell you how it works, and they are where most of the difficulty lives. Following one means a run of small decisions an engineer makes without noticing:
- Crossing or junction. Most legends break one line where two cross without connecting, and some older sets draw a hop. A tee, sometimes marked with a dot, is a real junction. On a faded scan a gap can close up and a speck of noise can pass for a dot.
- Direction of flow. Flow arrows are sparse, so direction is also inferred from the equipment at each end and from in-line items such as check valves.
- Where a label applies. A line number may be written once per sheet. Every unlabeled segment takes its identity by tracing back to a labeled one, through whatever valves and reducers sit between.
- Where the line changes. A spec break marks a change of piping class, a reducer a change of size. Depending on the project's rules, either can start a new line number.
- Process or signal. A tracer that follows a dashed signal line into a process line has invented a pipe.
Then the line leaves the sheet. An off-page connector names the continuation drawing, and usually the line number and the equipment at the other end. Tracing across it is a join between two documents: find the named sheet, find the partner connector, confirm the line number agrees, and keep going. A process line can cross several sheets, and a utility header such as instrument air can touch dozens.
This is also where drawing sets contradict themselves: a connector pointing to a sheet renumbered two revisions ago, a line that changes number between sheets, a partner connector nobody drew. An engineer who spots one writes it down. Software should route it to a person rather than resolve it silently.
Why OCR plus object detection is not enough
The obvious way to digitize a P&ID is to run optical character recognition for the text and an object detector for the symbols. The result is a table of strings and a table of boxes, and the gaps between those tables and a P&ID are specific:
- Text has no owner. OCR returns strings and coordinates, not the balloon, valve or line a string belongs to. On a dense sheet the nearest symbol is often the wrong one, and line numbers run rotated along the pipe or sit at the end of a leader.
- Tags are split by design. In an ISA balloon the identification letters sit in the top half and the loop number in the bottom half, so FIC-101 never appears on the drawing as one string.
- Characters are ambiguous without grammar. A character reader has no basis for deciding that the O in P-1O1A is a zero.
- Boxes have no topology. A detector can find every valve on a sheet without knowing which line each one sits on, which nozzle a line ties into, or whether two lines cross or join.
- Sheets are not islands. Connectivity through off-page connectors belongs to the document set, not to any one image.
- Annotations carry engineering meaning. CSO beside a block valve under a relief device, FC beside a control valve, a hold cloud, a note that a line must slope to a drain. Few of them are symbols in the detection sense.
General-purpose vision-language models move the boundary without removing it. They describe a crop of a drawing well, but they cannot reliably keep the connectivity of a large set consistent, cite the exact region behind each answer, or report uncertainty in a form that routes work to an engineer.
OCR gives you a table of strings. Detection gives you a table of boxes. A P&ID is a network, and neither table contains it.
A typed graph of the plant
What an engineer builds in their head while reading is a network with types. We build the same network explicitly. Its first-class objects are:
- Equipment, with tag, type and nozzles.
- Lines, with the attributes parsed from the line number and the ordered run of segments and in-line items: valves with their type and normal position, reducers, spec breaks, in-line instruments.
- Instruments, with identification letters, loop number, balloon type and location, and the process connection that ties each one to a line or vessel.
- Loops, grouping instruments that share a loop number, with the signal connections between them.
- Sheets and revisions, so every object knows where it is drawn, and in which version.
Typed edges connect them: a segment ties into a nozzle, an instrument connects to the line it measures, a controller signals a valve, a connector continues a line onto another sheet. Every node and edge carries provenance: the sheet, revision and drawing region it was read from, its confidence score, and its verification status, including who verified it and when.
Questions that used to mean an afternoon with a highlighter become traversals. With the illustrative tags from above:
- every valve, instrument and branch on 6"-P-1204-A1A-H between V-301 and the suction of P-101A/B, on every sheet it touches
- every device in loop 101, where each is mounted, and which way FV-101 fails
- every relief device protecting V-301, and every block valve in its inlet and outlet path, with the car-sealed or locked position shown
Each answer resolves to the sheet and region it came from, so an engineer can check it against the drawing directly.
Revision deltas fall out of the graph
P&IDs on an operating unit are revised every time the unit changes. The usual way to find what changed is a visual overlay of one revision on the next, which is loud where it does not matter and quiet where it does. A redrafted title block lights up. A piping class changed from A1A to B1A is a one-letter edit, easy to miss in the noise. Revision clouds help, but drafters cloud what they meant to change, and clouds are not always complete.
When both revisions are graphs, the delta compares objects instead of pixels. Matching uses identity where identity exists: tags, line numbers, loop numbers. Many manual valves carry no tag on a P&ID, so those are matched by their place in the topology, the line they sit on and their neighbors along it. The result is a structured list:
- Added and removed objects, such as a new PSV on V-301 or a bypass taken out.
- Changed attributes, such as a piping class going from A1A to B1A, or a control valve that now fails open instead of closed.
- Changed connectivity, such as a line moved to a different nozzle, or a transmitter relocated from upstream to downstream of a control valve.
- Clouds without changes, and changes without clouds, flagged for the reviewer.
Each item points to its region on both revisions. A reviewer checks the list against those regions and signs off on the change set, which is where a management of change review should begin. More on that in Management of change starts with a diff.
Reading at the scale of a plant
None of this is news to a process engineer. Read the legend, parse the tags, follow the lines, note what disagrees. What changes is scale. An engineer reads one sheet at a time and carries the connections in memory. A typed graph carries them for every sheet and revision at once, with a record of who verified each piece, so the next take-off, MOC review or PHA revalidation starts from the network instead of the paper.
For how verification works, see Why we verify every tag. For the broader case, see why the physical world runs on drawings.
