The words permissive and interlock get used almost interchangeably in the field, but they describe two genuinely different kinds of protection, and the difference is about timing. A permissive answers the question of whether you are allowed to start, checked at the moment of starting. An interlock answers the question of whether you are still allowed to run, checked continuously the whole time the equipment operates. Blurring the line between them is not just sloppy language; it can let a machine start when it should have stayed blocked, or keep running when it should have tripped.
Process interlock vs permissive in one line: A permissive is a condition that must be true to allow an action to begin, and it is checked at the point of starting to grant or withhold permission. An interlock is a condition that continuously trips or blocks equipment while it is running, checked on every scan so that if the condition is violated at any time the equipment is stopped or prevented from operating. The permissive gates the start; the interlock guards the run.
A permissive is fundamentally a gate on an action. Before a start command is allowed to take effect, the logic checks a set of conditions, and only if they are all satisfied does the start proceed. A permissive answers may I start right now. Crucially, a pure permissive is evaluated at the moment of the attempt; once the equipment is running, the permissive has done its job and is not necessarily what keeps the equipment safe from that point on. It is the bouncer at the door, checking your ticket on the way in.
An interlock is a continuous guard on operation. It is evaluated on every scan for as long as the equipment runs, and the instant its condition is violated it acts, either tripping running equipment to a safe state or blocking an output from energizing. An interlock answers may I keep running, over and over, forever. It does not care that conditions were fine at startup; if a protected limit is crossed an hour later, the interlock trips then. It is the guard who stays in the room the whole time, not just at the entrance.
The reason the distinction matters is that the two failures are different. If you only have a permissive, the equipment is checked at startup and then left unguarded, so a condition that goes bad during operation is not caught. If you only have an interlock, the equipment may be allowed to attempt a start into a state that was never suitable, relying on the interlock to catch it after the fact rather than preventing the start cleanly. Good design uses both, deliberately, and knows which conditions belong to which.
Take a gas compressor. Before it can start, you want minimum suction pressure available, because starting with no gas to compress is pointless and can be damaging. That is a permissive: suction pressure adequate is a condition to start, checked at the moment the start is attempted. If suction is too low, the start is simply not permitted, and the operator sees that the permissive is not met. Once the machine is running normally, the low-suction permissive has served its purpose as a start gate.
Now consider high discharge pressure. You never want the compressor to keep running against a dangerously high discharge, whether that happens one second after start or three hours in. That is an interlock: high discharge pressure is a condition to trip, checked continuously the whole time the machine runs, and if it is exceeded at any moment the compressor is shut down. It is not a start check; it is a run guard. The same machine thus has permissives that decide whether it may start and interlocks that decide whether it may continue.
The danger comes from putting a condition in the wrong category. If a genuine run-protection condition, such as high discharge pressure or loss of lube oil, is implemented only as a start permissive, the machine is protected at startup and then wide open once running, because a permissive that is only evaluated at the start does not trip a running unit when the condition later goes bad. Conversely, treating a start-only condition as a continuous interlock can cause nuisance trips. Deciding, for each condition, whether it gates the start or guards the run is the core of getting the protection scheme right.
In remote and unmanned operations, the permissive-versus-interlock distinction shapes what an operator can safely do from a SCADA screen. A remote start command should be gated by the full set of start permissives at the controller, so that a click on a dashboard cannot start equipment into an unsuitable state just because the link happened to be up. The permissive logic lives on the local controller and is proven before the start proceeds, and the operator sees which permissives are and are not met rather than blindly commanding a start.
The interlocks, meanwhile, must run continuously on the local controller entirely independent of the communications link, because a run-protection condition cannot wait for a remote operator to notice a bad reading and react. If a discharge pressure interlock is violated on a remote pad, the controller trips the compressor immediately, and the SCADA system's role is to report that a trip occurred and why, not to be the thing that decides to trip. Protection that depends on a healthy network to act is not protection at all for a site that is often out of contact.
This division also clarifies what the cloud layer is good for. A dashboard is excellent at showing an operator the live status of every permissive and interlock, at logging the history of what blocked a start or caused a trip, and at surfacing trends that hint an interlock is about to act. It should not, however, be the enforcement point. The rule that keeps remote operations safe is that permissives gate the start locally and interlocks guard the run locally, with the remote system observing and informing rather than being trusted to enforce.
Yes, and often they should. Lube oil pressure, for instance, can be a permissive that must be present before a machine starts and also an interlock that trips the machine if pressure is lost while running. The same physical condition serves two roles: gating the start and guarding the run. Implementing only one of the two leaves a gap.
A permissive contributes to safe operation by preventing a start into an unsuitable state, but a pure permissive is generally not the continuous protection that a safety-rated interlock provides. Because a permissive is checked mainly at the start, run-time protection has to come from an interlock that acts on every scan. Whether a permissive is treated as a safety function depends on the specific risk assessment for that equipment.
The equipment is protected only at the moment it starts and is left unguarded afterward. If a condition like high pressure or lost lubrication goes bad during operation, a start-only permissive does not trip the running machine, so the protection silently fails. Genuine run-protection conditions must be implemented as continuous interlocks that are evaluated every scan, not as one-time start checks.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.