From a P&ID to Control Logic: How an Experienced Team Programs a Process from the Drawing

A P&ID carries most of the control design already. An engineer who can read the drawing and understands the process behind it can derive the equipment modules, the operating sequences, the interlocks, the control loops and the alarm strategy from the P&ID plus a short, structured conversation about how the plant should run. Metromotion Controls is a control systems integrator based in Mount Waverley that programs process plant across Melbourne, Victoria and Australia for dairy, beverage and food sites. This article walks through how that reading is done and where the limits of it sit.

Working this way speeds scoping, reduces the spec overhead at the front of a project, and lets the control work start from the document the mechanical and process designers already produced. It does not skip documentation or shortcut safety; both are covered below.

What a P&ID shows, and what it does not

A piping and instrumentation diagram shows the process equipment, the piping that connects it, and every instrument and control device, together with their relationships: which vessels, pumps, heat exchangers and valves exist, how product and utilities flow between them, where each instrument sits, and how instruments group into control loops.

It deliberately leaves some things out. It is not to scale, it does not show physical layout or pipe routing, and it does not carry setpoints or operating values. The drawing tells the engineer that a level loop exists on a balance tank; it does not give the target level or the high alarm band. That gap is what the conversation with the process owner fills.

How an engineer reads ISA-5.1 symbology

The symbols and tags on a P&ID are not arbitrary. They follow ISA-5.1, Instrumentation Symbols and Identification, the standard that defines instrument symbols and tag identification for process drawings. Reading it fluently is the baseline skill, because every loop the engineer has to program is described in a few characters.

Tag letters and loop numbers

Under ISA-5.1 a tag has two parts: a letter group and a number. The first letter identifies the measured or initiating variable. The succeeding letters identify the function the device performs. The number is the loop number that ties the parts of one loop together.

LT-201 and LIC-201 are the field device and the controller of the same level loop. The engineer reads that pair and knows the loop will need a final control element on the same loop number, usually a valve or a variable-speed pump. The loop number is the thread that links measurement, controller and actuator across the drawing.

Bubbles, valves and equipment symbols

Instruments are drawn as bubbles, the circles carrying the tag. A circle with no line through it is a field-mounted instrument, a single horizontal line through the centre places it in the control room, and a circle inside a square marks a function in a shared display and control system such as a DCS or SCADA. Valves carry symbols that distinguish a gate valve from a butterfly, a globe or a diaphragm, and a control valve from a hand valve. The actuator symbol on top of a valve tells the engineer whether it is pneumatic, motorised or solenoid driven, and the fail position, fail open or fail closed, is what the logic has to assume when air or power is lost.

Equipment symbols show the vessels, pumps, heat exchangers and skids. The shape of a pump symbol distinguishes a centrifugal pump from a positive displacement one, and that distinction changes the control approach, as the next section shows.

Lines and interlock references

Line types separate process piping from instrument signals, and instrument signal lines themselves are distinguished by type, pneumatic, electric, software or data link. Interlock references, often a diamond or a labelled note linking one device to another, point to the conditions that tie equipment together: a pump that must not run on low suction level, a valve that must not open against a closed downstream valve. These references are where the interlock and permissive logic begins.

From symbology to a working control narrative

Reading the symbology is the start; turning it into correct logic needs the process understanding behind the drawing. A few examples of that reading in practice:

• A centrifugal pump needs a flooded suction, so the logic should prove the suction is primed before the pump starts, and a flush sequence is usually needed at product change or before cleaning. None of that is written on the P&ID; it is read from the pump type and the process.
• A fast-acting valve on a long liquid line is a water hammer risk. Closing quickly against moving liquid produces a pressure surge that damages pipework and instruments, so the engineer writes the close as a ramped or staged action, the closure-time reasoning covered in our guide to pump control and water hammer.
• A level loop and a flow loop on the same vessel can fight each other if both try to control the same stream. The engineer reads both loops off the drawing and decides which is the master and which follows, rather than tuning two controllers that oppose each other.
• Each loop has its own dynamics. A temperature loop on a steam-heated exchanger responds differently from one driven by hot water, and a gas pressure loop behaves differently from a tank level loop. The engineer reads the medium and the actuator off the drawing and tunes accordingly, the loop-by-loop reasoning in our guide to PID loop tuning.

This is the layer that a symbol-only reading misses. The drawing says what is there. Process understanding says how it has to behave.

A worked example: a tank fill, heat and transfer skid

The following is an illustrative, generic example, not a real Metromotion Controls project. It shows the path from drawing to logic on a deliberately simple skid.

Picture a small skid: a feed tank, a transfer pump, a plate heat exchanger heated by hot water, and a transfer line to a downstream vessel. On the P&ID the engineer reads:

• LT-101 and LIC-101 on the feed tank: a level loop with an indicating controller.
• A centrifugal transfer pump, P-101, with a low-level switch LSL-101 on the tank.
• TT-201 and TIC-201 on the heat exchanger product outlet, with a control valve TV-201 on the hot water supply.
• FT-301 on the transfer line, and a downstream valve XV-301 with position feedback.

The control narrative the drawing implies

From those tags and the process, the control narrative reads roughly like this. The skid fills the feed tank to a working level under LIC-101. When a transfer is requested, the pump P-101 starts, but only once the tank level is above the low-level switch LSL-101, so the pump is not started dry. Product is drawn through the heat exchanger, where TIC-201 modulates the hot water valve TV-201 to hold the product outlet temperature. Flow is confirmed on FT-301 before the heat step is considered active. Product transfers to the downstream vessel through XV-301, which must be proven open before flow is established.

The sequence, interlocks and loops that fall out of it

The narrative resolves into three layers the engineer can program directly.

Equipment modules. The tank with its level loop, the pump, the heat exchanger with its temperature loop, and the transfer valve are each a module with its own states and its own interlocks. Building them as modules, rather than one long sequence, is what makes the skid reusable and testable.

Operating sequence. Fill, then on transfer request prove level and downstream valve, start pump, prove flow, enable temperature control, transfer until the batch or level target is met, then stop pump, close valves, and return to idle. Each step has an entry condition and a completion condition read from the instruments.

Interlocks and permissives. The pump does not start below LSL-101 and trips if level falls during the transfer. The heat step does not enable until FT-301 proves flow, so the exchanger is not heated with no product moving through it. XV-301 must show open before the pump pushes against it. The hot water valve fails to a safe position on loss of air. Each of these is read off the drawing, or implied by the process and confirmed in conversation.

Control loops. LIC-101 is a level loop, tuned for the tank dynamics. TIC-201 is a temperature loop on a hot-water-heated exchanger, tuned for its lag. Both are named on the drawing; the tuning comes from the process, not the symbols.

Alarm strategy. Level high and low on the tank, temperature deviation on the exchanger outlet, flow loss during transfer, and valve position mismatch on XV-301. The alarms come straight from the loops and interlocks already identified, prioritised so the operator sees the actionable ones first.

That entire structure was derived from the P&ID and a short conversation, before any line of code was written and without a separate functional specification arriving first.

What still has to be confirmed in the conversation

The drawing and the engineer's reading get the structure right. They do not settle the numbers and the operating intent. These are confirmed with the process owner, and they are where a derived design goes wrong if the conversation is skipped:

• Setpoints and ranges. The target tank level, the product outlet temperature and its acceptable band, the transfer flow rate. The drawing shows the loops exist; it does not carry the values.
• Product grades and changeover. Whether the skid runs more than one product, how they differ, and what has to happen between them. Two products that must never share a line without a flush is a process rule, not a symbol.
• CIP and cleaning. Where the cleaning connections are, what recipe each circuit runs, and how cleaning interacts with production state, the detail covered in CIP automation for hygienic processing.
• Operating modes. Manual, automatic, maintenance and cleaning modes, and what is permitted in each.
• Safety functions. Any hazard that needs a safety instrumented function is identified and assessed on its own terms, following the relevant functional safety and SIL process, not derived informally from the drawing.

Confirming these is a short, structured discussion, not a long document exercise. The engineer arrives with the structure already derived and asks targeted questions against it, which is faster for the plant than reviewing a specification written from scratch.

Why this speeds scoping without skipping the documentation

Working from the drawing changes the order of a project, not the deliverables. Instead of waiting for a functional specification to be written, reviewed and signed before control work begins, the engineer derives the control narrative from the P&ID, confirms the open points in conversation, and starts building. The control philosophy, the sequence descriptions, the interlock register and the test plan are produced as the work is built, so the plant is still documented at handover.

The saving is specific: it removes the front-loaded specification phase and the duplication where a specification describes what the P&ID already shows. It does not remove the documentation, and it does not change how safety functions are handled. For an Australian food, beverage or agricultural processing site that wants control work moving without a long paper phase first, this reading is what makes it possible, and it underpins our broader industrial automation work.

References

Source for the symbology and tag identification described above:

• ISA-5.1, Instrumentation Symbols and Identification, International Society of Automation.