Machine Design #38: Interlocks and Permissives — Not Every PLC Condition Is “Safety”
Machine programs often collect hundreds of conditions that can prevent motion. Some protect people, some protect the process, and some only help diagnose a fault. Calling every condition an “interlock” or “safety” does not make the machine safer. It hides ownership, required reliability, correct reaction, and the evidence needed for validation.
A guard-locking function and a “part present” bit may both block Cycle Start, but they do not belong to the same engineering class. One can be part of a validated safety function; the other can be a process permissive. A low-lubrication warning may require maintenance attention without stopping the current safe cycle at all.
The design task is to classify each condition, assign it to the right system, define its reaction and reset behavior, and validate it according to its consequence.
This article presents a conceptual framework. It does not replace risk assessment, safety-requirement specifications, applicable type-C standards, performance-level calculations, or validation by a competent machine-safety engineer.
1. “Interlock” is not a generic name for every bit that prevents operation
In everyday project language, teams often call any blocking condition an interlock: door open, pressure low, recipe missing, downstream station busy, maintenance counter due, or camera result invalid. The shared effect—“machine cannot start”—does not mean the conditions have the same purpose.
If classification remains vague, ordinary PLC logic may accidentally carry a safety claim, safety PLC code may become overloaded with quality logic, alarms may give the wrong instructions, and technicians may bypass a condition without understanding its consequence.
Name the class before naming the tag.
2. What is a safety interlock?
A safety interlock contributes to a safety function intended to reduce risk to people. Examples include preventing hazardous motion while an interlocked guard is open, or maintaining guard locking until a hazardous run-down has ended.
The complete function includes the initiating device, input subsystem, safety logic, output subsystem, power-control elements, feedback where required, and the mechanical hazard it controls. It needs a specified safe state, required performance, fault response, reset behavior, and validation.
A device marketed as a “safety switch” does not create a complete safety function by itself. The architecture and integration determine the achieved performance.
3. What is a process permissive?
A process permissive is a condition required to begin or continue the intended operation, production quality, or equipment coordination. Examples include adequate utility pressure, valid recipe, workpiece seated, downstream ready, tool life available, and correct model identification.
Failure of a permissive commonly inhibits start, pauses a sequence in a controlled state, or routes the machine to recovery. Its implementation may be standard PLC logic unless the risk assessment assigns a safety role.
Process permissives should have clear reason codes. The operator needs to know which condition is missing, where it is located, and what legitimate action restores it.
4. What is a diagnostic condition?
A diagnostic condition identifies deterioration, inconsistency, or a likely fault. It may warn that cycle time is increasing, a sensor margin is shrinking, a filter is approaching its limit, a brake test is due, or two signals are implausible.
Diagnostics can trigger warnings, maintenance work, controlled stops, or immediate faults depending on consequence. They should not be treated as harmless merely because they are “only diagnostics.” Equally, adding a diagnostic bit to standard logic does not automatically increase the integrity of a safety function.
5. Build a logical ownership map
For every condition, document:
| Question | Design decision |
|---|
| What claim does it support? | Personnel safety, process operation, quality, equipment protection, or diagnosis |
| Who owns the logic? | Safety controller, process PLC, device controller, or supervisory system |
| What is the reaction? | Safe stop, controlled stop, start inhibit, hold, warning, or maintenance request |
| How is it cleared? | Automatic after state recovery, acknowledge, manual reset, inspection, or authorized maintenance |
| What evidence is required? | Safety validation, functional test, challenge test, trend, or inspection record |
Ownership should be visible in the electrical design, software structure, HMI text, test plan, and change process. A tag prefix alone is not sufficient documentation.
6. Guard closed and guard locked are different states
Guard closed
The guard has reached the closed position. This may be sufficient when stopping time is short and opening immediately removes access, depending on the risk assessment.
Guard locked
The guard is closed and mechanically prevented from opening until release conditions are satisfied. Guard locking may be required when hazardous motion or energy persists after a stop command.
One sensor indicating “closed” does not prove “locked.” Conversely, a lock command does not prove that the locking element engaged. Define the required evidence and test misalignment, broken actuator, lock failure, and manipulated conditions.
7. An interlocking device does not create a complete safety function alone
The interlocking device detects or controls guard state, but the safety function also depends on logic, contactors or drive safety functions, wiring, diagnostics, stopping behavior, and the machine mechanics.
Specify the hazard, safe state, stop category or safe-motion behavior, reset and restart rules, and required performance. Validate the complete chain under normal and fault conditions. Do not copy a wiring diagram from a component catalog and assume the machine function is validated.
8. Prevent unexpected start-up
Opening a guard or activating a safety device should initiate the designed safety response. Closing the guard or clearing the device should not, by itself, restart hazardous motion unless a specific application has been assessed and designed for that behavior.
Consider restoration of power, pressure, network communication, remote commands, retained PLC states, and automatic device sequences. After interruption, the machine should establish a known state and wait for the required reset and separate intentional start command.
9. Define reset ownership
A reset acknowledges that conditions for restoring the safety function have been checked. Its location, visibility, authorization, and affected zone matter.
Do not let a process “Reset All” silently reset safety functions across zones. Avoid a remote reset from a position where the hazardous area cannot be assessed. In multi-zone systems, document which reset applies to which device and whether another zone remains inhibited.
Reset must not create hazardous motion. It restores eligibility for operation; it is not a start command.
10. Process permissives need reason codes
An aggregated bit such as AutoReady = false is useful to sequence logic but poor for troubleshooting. Preserve the individual reasons: pressure below minimum, part not seated, recipe invalid, downstream not ready, axis outside recovery window, or tool life exceeded.
The HMI should present the first relevant reason, current value, expected value, location, and allowed action. Avoid instructions such as “bypass sensor” or “force bit.” If several conditions are missing, let maintenance inspect the full list without hiding the first-out event.
11. Do not collapse every condition into one giant ready bit
A single composite ready signal makes code short but removes context and often creates circular dependencies. Separate readiness by subsystem and phase: safety ready, utilities ready, motion ready, tooling ready, workpiece ready, downstream ready, and recipe ready.
Define who produces and consumes each state. Preserve raw evidence and diagnostic reason while exposing a stable interface to the higher-level sequence.
12. Permissive before start, interlock during operation
Some conditions are checked before cycle start but need a different reaction if lost during motion. Pressure above a threshold may be a start permissive; loss during clamping may require a controlled fault response. Downstream ready may be required before transfer; loss during handoff needs a defined handshake recovery.
For every condition, specify:
- Requirement before start.
- Monitoring while running.
- Reaction if lost.
- Whether restart is automatic, operator-commanded, or maintenance-controlled.
- Evidence required before resuming.
Do not assume that reusing the same Boolean automatically defines correct state-dependent behavior.
13. Stale bits and network state
A remote Ready bit may remain true after communication stops if the receiving PLC does not monitor freshness. A cached HMI value can look valid while the device has rebooted. A handshake bit can be left from the previous cycle.
Use communication health, heartbeat or sequence counters, timeouts derived from system behavior, startup initialization, and explicit invalid states. After reconnection, reconcile both sides instead of resuming from retained bits.
14. Plausibility
Check whether combinations can physically coexist. A guard cannot be both open and safely locked under normal geometry. A cylinder cannot be at both ends. A station should not report CycleComplete without having accepted the current request and part identity.
Plausibility diagnostics detect wiring shorts, swapped connectors, damaged targets, stale data, and incomplete state models. Decide which inconsistency requires a safety response, process stop, or maintenance warning based on the associated claim.
15. Timing
Signals must arrive and disappear within physically credible windows. Guard locking needs time to engage; a drive needs time to reach safe speed or standstill; pressure needs time to build; a handshake needs bounded communication latency.
Set timing from measurement, component data, mechanics, scan and network behavior, plus validated margin. Arbitrary delays create nuisance trips or conceal faults. Record actual timing where trend data can reveal deterioration.
16. Defeat and bypass control
Maintenance bypasses, mute functions, setup overrides, and defeated sensors require explicit design. Define who may enable them, in which mode, for how long, with which alternative protective measures, and how the state is indicated and logged.
Prefer engineered mode selection and limited functions over PLC forces. A bypass should expire or require deliberate renewal, affect only the minimum scope, and prevent normal automatic production where appropriate. Removing a jumper after commissioning is not a lifecycle control strategy.
17. Mode control
Automatic, manual, setup, teaching, recovery, and maintenance modes have different allowed motions and protective measures. Mode selection should be unambiguous and, where required, access-controlled.
Changing mode must not silently clear faults or enable motion. Define speed, force, travel, hold-to-run, enabling-device, guard, and reset requirements for each mode. HMI labels should describe capability and restriction, not merely Mode 1 and Mode 2.
18. Alarm architecture
Safety active
State which safety device and zone are active, what action is prohibited, and what legitimate inspection or reset is required. Do not suggest bypass.
Process inhibit
Show the unmet condition, actual and required values, location, and recovery action. Distinguish “not ready to start” from a fault that interrupted operation.
Diagnostic warning
Describe deterioration, remaining margin, recommended maintenance, and escalation threshold. A warning should become actionable work rather than permanent background noise.
Keep first-out information and a context snapshot so secondary alarms do not hide the initiating event.
19. Validate by class
Safety validation
Validate the complete safety function against its specification, including foreseeable faults, reset and restart behavior, stopping performance, and achieved architecture.
Process validation
Challenge valid and invalid operating conditions, boundary values, sequence phases, recipe changes, utility loss, and recovery behavior.
Diagnostic validation
Inject sensor, wiring, communication, timing, and plausibility faults. Confirm the correct message, reaction, logging, and maintenance guidance.
Passing a normal production cycle does not prove any of these three classes adequately.
20. Change management
Changing one condition can change safety, sequence, HMI, test evidence, and recovery. Record the requirement, owner, affected modes and zones, previous and new behavior, risk impact, software and drawing revisions, and revalidation scope.
Do not rename a process permissive as “safety” to make it sound important, or downgrade a safety condition to simplify production. Classification follows the claim and risk, not project pressure.
21. Design process
Step 1 — Risk assessment
Identify hazards and required safety functions before designing ordinary sequence logic.
Step 2 — Process state model
Define valid states, transitions, interrupted states, and recovery paths.
Step 3 — Classify conditions
Assign safety, process, quality, equipment-protection, or diagnostic purpose.
Step 4 — Assign ownership
Choose the responsible controller, subsystem, zone, and engineering discipline.
Step 5 — Define reaction and reset
Specify start behavior, run-time loss response, reset authority, and restart conditions.
Step 6 — Design diagnostics
Preserve reason codes, transitions, timing, plausibility, and communication freshness.
Step 7 — Plan validation
Select evidence and fault-injection tests appropriate to each class.
Step 8 — Manage the lifecycle
Control bypass, parameters, changes, periodic tests, and replacement.
22. Review checklist
Classification
- [ ] Every blocking condition has a documented claim and class.
- [ ] Safety, process, and diagnostic conditions are not mixed by name alone.
- [ ] Controller and subsystem ownership are explicit.
Safety
- [ ] Required safety functions have specifications and validation plans.
- [ ] Guard closed and guard locked are distinguished where necessary.
- [ ] Reset and energy restoration cannot cause unexpected start-up.
Process
- [ ] Start permissives and run-time loss reactions are defined separately.
- [ ] Reason codes remain available behind composite ready states.
- [ ] Handshakes include freshness and recovery after communication loss.
Diagnostics
- [ ] Transitions, timing, and implausible combinations are monitored.
- [ ] Alarms identify location, expected state, and legitimate action.
- [ ] First-out and context are retained.
Reset and restart
- [ ] Reset authority and affected zone are clear.
- [ ] Reset does not initiate motion.
- [ ] Restart requires the defined intentional command and verified state.
Validation
- [ ] Safety, process, and diagnostic tests match their claims.
- [ ] Bypass and mode behavior are tested and traceable.
- [ ] Changes trigger the required revalidation.
Conclusion
The fact that a condition prevents a machine from running does not make it a safety interlock. Safety interlocks reduce risk to people through a specified and validated safety function. Process permissives protect operation and quality. Diagnostics provide evidence for finding degradation and faults.
Classify the claim, assign ownership, define reactions for both start and run, preserve reason codes, control resets and bypasses, and validate each class with appropriate evidence.
Clear classification is not paperwork. It makes the machine easier to validate, troubleshoot, recover, maintain, and change without silently weakening protection.
Public references
View all MINATA technical articles