How to write an interlock a programmer cannot misread

Interlocks are where an unclear FDS costs the most. A vague sentence about a pump or a valve gets built the way the programmer reads it, and the process engineer finds out how that differs from their own reading during commissioning. Four small habits remove most of the risk.

Name the condition and the action separately. "Pump protected against dry running" describes an intention. "Stop pump P101 when suction level LSL101 is low for more than five seconds" names the device, the signal, the delay and the result. If the sentence can be turned into a test, it is finished.

Say whether it trips or holds. A trip stops the equipment and keeps it stopped until someone acts. A hold stops it only while the condition is true and lets it run again when the condition clears. These behave very differently and a single word in the FDS is the only thing that separates them. Write "trip" or "inhibit" and say which you mean.

State how it resets. Does the interlock clear itself once the condition is gone or does an operator have to acknowledge it first? Where does the reset happen and does it need the device back in a safe state? A good reset line names the permission needed and the place the operator presses it.

Separate permissives from interlocks. A permissive must be true before something can start. An interlock acts while it is running. Mixing them in one list leads to a pump that cannot start for a reason nobody can find or one that keeps running when it should have stopped. Give each its own list for every device.

Here is the same requirement written badly and then well. Before: "The tank must not overflow." After: "Close inlet valve XV201 and stop pump P101 when tank level LSHH201 is high high. Both actions latch. The operator resets from the tank faceplate once level is below LSH201." The second version names two actions and two devices. It also says what latches and where the operator resets it.

A good test of any interlock line is to hand it to someone who has never seen the plant and ask them to write the test steps. If they have to ask a question the line is not finished yet. This is also the cheapest review an FDS can get. It takes minutes and it catches the questions that would otherwise arrive mid-project.

A structured record helps here because every interlock has the same fields: a cause tag and condition, one or more effect tags, an effect action and a reset mode. A blank field is easy to see. In a long Word document the same gap can sit unnoticed until someone reads it as if they had to build from it.

FDSIQ holds every interlock as a record with a condition, an action and a reset. You can see how it works on How It Works.

An engineer reviews and tests everything FDSIQ and ScaffIQ generate before it goes anywhere near a running system.