Interlocks explained: the rules that stop a machine before it hurts itself

In one minute

• An interlock is a rule that watches a machine and takes a protective action on its own, without waiting for a person.
• The protective action is the safe action: the thing that is least likely to cause harm, such as stopping a pump.
• An alarm asks a person to look. A shutdown acts by itself. A plant needs both, for different situations.
• A plant wants these rules written in plain words so an engineer can read them, check them, and sign them.
• quorum lets you write the rule as readings, claims, and actions, then checks it against every possible situation before it runs.

Who this is for

This guide is for plant engineers, technicians, and anyone who maintains machines that must protect themselves. You do not need to be a programmer. If you have ever set an alarm limit, wired a trip, or read a cause-and-effect chart, you already know most of the ideas here. This guide explains the rest in plain words.

What an interlock is

An interlock is a rule that sits between a machine and harm. It watches the machine through its instruments. When the readings add up to danger, it acts. It does not ask first. That is the whole point: some things happen too fast for a person to catch.

A few everyday examples:

• A microwave oven will not run with the door open.
• A pump stops when its bearing gets too hot.
• A tank stops filling when the level gets too high.

Engineers also call this a safety function. The two words mean the same thing here. An interlock is a safety function with a clear job: stop a bad thing from happening to a machine or the people near it.

The safe action

Every interlock needs to know one thing above all: what is the safe thing to do. This is the safe action. It is the action that is least likely to cause harm when the machine is in trouble.

The safe action is not always "stop". For most machines it is. A pump that might be tearing itself apart should stop. A tank that might overflow should stop filling. But a flying drone has no safe way to simply switch off, so its safe action is something else.

The safe action has to be stated on purpose, not assumed. An interlock that guesses its own safe action is one bad guess away from making things worse. In quorum you write the safe action down, by hand, for each rulebook.

Alarms and shutdowns are not the same

Two kinds of protective action get mixed up often, and the difference matters.

An alarm asks a person to look. It raises a light, sounds a horn, or sends a message. The machine keeps running. A person decides what to do. Alarms are right when there is time to think and a person can add judgement.

A shutdown acts by itself. It stops the machine, closes a valve, or cuts power. No person is in the loop. Shutdowns are right when there is no time, or when the risk is too high to leave to a judgement call.

A good plant uses both. The hard part is choosing which situation gets which. Shut down too often and you create nuisance trips that cost money and teach people to ignore the system. Shut down too rarely and the one time it mattered, nothing stopped. The rule has to say, situation by situation, which response is correct.

Why plants want a rule a person can read

Many protective systems are hidden inside code or ladder logic that only a specialist can read. When something trips, nobody can easily say why. When a sensor dies, nobody notices until the day it was needed.

A rule a person can read fixes both problems. An engineer can check it before it runs. A technician can see why it tripped after it runs. An auditor can tie each rule to the document it came from. The rule stops being a black box and becomes a paper you can argue with.

This is the idea behind quorum. The rules live in a plain-words file called a casebook. The file ends in .cb. An engineer writes it, reads it, and signs it.

How quorum writes a rule

A quorum rule has three kinds of parts. You read them in order: what the instruments report, the conclusions those readings support, and the actions to take.

First, what the instruments report. These are the readings. Each one is a single fact the machine can see.

observe vib_high          "broadband vibration above alarm threshold"
observe bearing_temp_high "bearing temperature elevated"
observe suction_low       "suction pressure low, NPSH margin eroded"

Second, the conclusions. A claim is a hypothesis about what is wrong, and it names the readings it needs. The word needs means all of them must be present.

claim cavitation   "impeller cavitation"   needs vib_high suction_low
claim bearing_wear "bearing degradation"    needs vib_high bearing_temp_high

Third, the actions. Each action can be marked idle (the do-nothing action for a healthy machine) or safe (the protective fallback). The prefer line ranks them, so the rule knows which action wins when more than one could apply.

action continue idle
action maintain when any cavitation bearing_wear impeller_defect misalignment
action shutdown safe when bearing_wear
prefer shutdown over maintain over continue

These lines are excerpts from the pump rulebook that ships with quorum (casebook/pump/pump.cb). Read top to bottom, the rule says: watch these readings, draw these conclusions, and take the highest-ranked action that fits. A healthy, quiet machine lands on continue, the idle action. A machine with a hot, worn bearing lands on shutdown, the safe action.

The rule is checked before it runs

Writing the rule is half the job. The other half is proving it has no gaps. A rule with a gap is a rule that, in some situation nobody tested, gives two answers at once, no answer at all, or the wrong answer.

quorum's compiler is called cbc. It reads the rulebook and tries every combination of readings. Not a sample. All of them. The pump rulebook has 14 readings, which is 16,384 combinations, and cbc solves every one. (The 16,384 figure is from the quorum README.) If any situation selects two actions, or no action, the compiler refuses the rulebook and names the situation that breaks it. You fix the rule, not guess at it.

Only a rulebook that passes every situation becomes an image small enough to run on a low-cost chip. The README states this image is under 3 KB of flash.

The five outcomes

When the rule runs, it does not just say "stop" or "go". It gives one of five outcomes. quorum keeps them separate on purpose, because sending an engineer to the wrong problem is itself a safety defect. These are the five outcomes from the quorum README.

The important split is between Indeterminate and Faulted. Indeterminate means the plant is in a genuinely ambiguous state and a person should weigh in. Faulted means the checker itself did not finish, which is a different problem with a different fix. A system that lumps both into one vague "unknown" would hide that difference.

What quorum does not do

quorum is honest about its limits, and so is this guide.

• It is not certified for safety-critical use. The README says plainly that it has not been assessed against IEC 61508 or any other standard, and no plant runs it yet. Use it beside your existing protections, not instead of them.
• It checks the rules, not the plant. The every-situation check proves the rulebook is sound. It cannot prove that each reading comes from the right instrument, or that each threshold is set where the document says. Only a person working through a loop check on the real machine can prove that.
• It is not machine learning and does not predict the future. It applies rules a person wrote and approved to what the instruments report right now.

If you want to see the next step, read how quorum notices a dead sensor and how it handles 2-out-of-3 voting. The source is on GitHub at the quorum repository.