LCN Wafer Inspection

Appearance

Below is the structured deep dive for Safety Interlocks & Fail-Safe Behavior, aligned with your roadmap’s safety/interlock topic and the broader machine-control principle that safety must be designed, not assumed.

Safety Interlocks & Fail-Safe Behavior ​

Software Architecture Perspective for Industrial Machine Systems ​

Big Picture ​

In industrial machine software, safety is not just a hardware topic and not just a UI topic.

Safety is a system behavior.

A wafer inspection machine, robot cell, automation line, or motion platform may contain:

  • moving axes
  • robot arms
  • clamps
  • vacuum grippers
  • lasers or strong illumination
  • high voltage
  • heaters
  • pneumatic or pressurized systems
  • fragile products such as wafers, panels, or precision parts

The software does not directly make the machine safe by itself.

Instead, good software must:

  • understand safety-visible states
  • respect interlocks
  • block unsafe commands
  • avoid stale or optimistic assumptions
  • coordinate recovery
  • never bypass independent safety layers

A strong industrial software architect understands this rule:

Application software may request machine actions, but it must never assume it has the final authority to make unsafe physical behavior safe.

Part 1 — Why Safety Interlocks Matter ​

In enterprise software, a bad validation bug might create incorrect data.

In industrial software, a bad validation bug can move hardware at the wrong time.

That is the mental shift.

A command like this may look simple in code:

csharp
await stage.MoveToAsync(position);

But physically, that command may mean:

  • energize a motor
  • release a brake
  • move a heavy stage
  • pass near a mechanical limit
  • move under an optical head
  • interact with a wafer or fixture
  • affect an operator working nearby

So the real question is not:

“Can the method be called?”

The real question is:

“Is it currently safe, permitted, meaningful, and recoverable to execute this action?”

Examples:

ConditionExpected Software Behavior
Guard door openInhibit motion
Light curtain interruptedBlock robot movement
Vacuum not confirmedDo not release wafer
Safety PLC reports unsafe stateDo not start workflow
Motion drive safety inhibit activeTreat motion command as not executable
Door signal staleTreat as unsafe, not safe
Unknown robot positionDo not allow automatic sequence continuation

Interlocks are not “optional validations.”

They are part of machine behavior.

A business validation says:

“This order quantity must be greater than zero.”

A safety interlock says:

“This physical action must not happen unless the machine is in a safe and permitted condition.”

That difference matters architecturally.

Part 2 — Interlocks, Permissives, Inhibits, and Fail-Safe ​

These terms are related, but they are not identical.

Interlock ​

An interlock is a condition that prevents or stops an action when allowing it could be unsafe or damaging.

Example:

Guard door open → motion interlock active → stage movement is not allowed.

The interlock is usually connected to physical safety or machine protection.

Permissive ​

A permissive is a condition that must be true before an action is allowed.

Example:

Before ReleaseWafer, the system requires:

  • wafer present
  • vacuum confirmed
  • robot in correct position
  • target station ready
  • no safety inhibit active

Each of these is a permissive.

Inhibit ​

An inhibit is an active block.

Example:

Motion inhibit active because safety door is open.

The command may be valid in theory, but it is blocked right now.

Fail-safe ​

Fail-safe means that when information, power, communication, or control is lost, the system moves toward the safest reasonable defined state.

Important:

Fail-safe does not always mean “stop everything instantly.”

It means:

Choose the safest predefined response for that condition.

Examples:

ConditionFail-Safe Response
Lost safety PLC communicationInhibit new motion commands
Unknown door stateTreat door as unsafe
Vacuum signal missingDo not release wafer
Drive status staleStop workflow at safe boundary
Safety state invalidRequire operator/service recovery
Output ownership uncertainDe-energize or block output where appropriate

Concept Diagram ​

text
+----------------------+
| Physical / Logical   |
| Condition            |
|                      |
| Door closed?         |
| Vacuum confirmed?    |
| Light curtain clear? |
| Drive ready?         |
+----------+-----------+
           |
           v
+----------------------+
| Safety Interpretation|
|                      |
| Permissive satisfied |
| OR                   |
| Inhibit active       |
+----------+-----------+
           |
           v
+-----------------------------+
| Command Decision            |
|                             |
| Allow command               |
| Reject command              |
| Stop / hold workflow        |
| Escalate fault              |
+-----------------------------+

The key idea:

Raw signals should not be scattered throughout the codebase. They should be interpreted into explicit safety/permissive/inhibit meaning.

Part 3 — Software vs Safety System Responsibility ​

This is one of the most important architecture boundaries.

Normal application software should not be the only thing preventing dangerous motion.

Safety-critical enforcement may belong to:

  • safety PLC
  • safety relay
  • drive safety functions
  • hardwired safety circuit
  • motion controller safety configuration
  • hardware-level enable chain

Application software usually has a different responsibility.

It should:

  • observe safety state
  • respect safety inhibits
  • prevent unsafe command requests
  • avoid misleading the operator
  • record safety-related context
  • coordinate recovery
  • never bypass the safety layer

Boundary Diagram ​

text
+--------------------------------------------------+
| HMI / Workflow Application                       |
|                                                  |
| - Operator commands                              |
| - Auto sequence                                  |
| - Manual/service commands                        |
| - Recovery flow                                  |
+-------------------------+------------------------+
                          |
                          | command requests
                          v
+--------------------------------------------------+
| Machine Control Layer                            |
|                                                  |
| - Command gating                                 |
| - State machine                                  |
| - Workflow coordination                          |
| - Interlock-aware decisions                      |
+-------------------------+------------------------+
                          |
                          | device commands
                          v
+--------------------------------------------------+
| Device Layer                                      |
|                                                  |
| - Motion controller adapter                      |
| - Robot adapter                                  |
| - IO module adapter                              |
| - Vacuum / light / camera adapter                |
+-------------------------+------------------------+
                          |
                          | electrical / protocol control
                          v
+--------------------------------------------------+
| Hardware                                          |
|                                                  |
| - Motors                                         |
| - Drives                                         |
| - Valves                                         |
| - Sensors                                        |
| - Actuators                                      |
+--------------------------------------------------+

                 independent safety path

+--------------------------------------------------+
| Safety PLC / Safety Relay / Safety Circuit       |
|                                                  |
| - Guard door                                     |
| - Light curtain                                  |
| - E-stop chain                                   |
| - Motion enable                                  |
| - Safe torque off / drive inhibit                |
+-------------------------+------------------------+
                          |
                          | independently inhibits
                          v
+--------------------------------------------------+
| Dangerous Hardware Action                        |
+--------------------------------------------------+

The application may say:

“Move axis X.”

But the safety system may say:

“No. Motion enable is inhibited.”

The application must be designed to handle that correctly.

It should not assume:

“I sent the command, therefore the command succeeded.”

That assumption causes many real production bugs.

Part 4 — Command Gating with Interlocks ​

Good industrial software usually has a central command gate.

The command gate decides whether a command is allowed before it reaches the device layer.

Before executing a command, the system checks:

  • current machine state
  • operating mode
  • user role, where relevant
  • interlock state
  • permissives
  • inhibits
  • device readiness
  • resource ownership
  • workflow ownership
  • command preconditions
  • freshness of safety-visible state

UI Disablement Is Not Enough ​

Bad design:

text
Button disabled = safety handled

This is weak.

Why?

Because commands may come from:

  • UI button
  • workflow engine
  • service screen
  • remote command
  • script
  • recovery logic
  • retry logic
  • background automation
  • test tool

If only the UI disables the button, another path may still execute the unsafe command.

Better design:

text
Every command path goes through backend command gating.

Command Gating Flow ​

text
+------------------+
| Command Intent   |
|                  |
| MoveStage        |
| OpenClamp        |
| ReleaseWafer     |
| StartInspection  |
+--------+---------+
         |
         v
+------------------+
| Basic Validation |
|                  |
| Valid parameter? |
| Valid target?    |
| Valid mode?      |
+--------+---------+
         |
         v
+----------------------+
| Interlock Check      |
|                      |
| Safety state fresh?  |
| Door closed?         |
| Light curtain clear? |
| Motion allowed?      |
| Vacuum confirmed?    |
+--------+-------------+
         |
         v
+-----------------------------+
| Decision                    |
|                             |
| Allow                       |
| Reject with reason          |
| Hold workflow               |
| Escalate fault              |
+-----------------------------+

A command should produce a clear decision:

csharp
public enum CommandDecisionKind
{
    Allowed,
    Rejected,
    Inhibited,
    Faulted
}

public sealed record CommandDecision(
    CommandDecisionKind Kind,
    string ReasonCode,
    string Message);

Example reasons:

text
MotionInhibited_GuardDoorOpen
MotionInhibited_SafetyStateUnknown
WaferReleaseRejected_VacuumNotConfirmed
WorkflowStartRejected_SafetyPlcDisconnected
RobotMoveRejected_LightCurtainInterrupted

Consistent rejection reasons are important because they help:

  • UI display
  • workflow recovery
  • logging
  • diagnostics
  • field support
  • automated testing

Part 5 — Fail-Safe Behavior Under Uncertainty ​

A very important rule:

Unknown is not safe.

If the system does not know the safety state, it must not assume the safe case.

Examples:

SituationBad BehaviorGood Behavior
Lost safety PLC connectionContinue using last known safe stateTreat safety state as unknown/unsafe
Door status staleAllow motion because last value was closedInhibit motion
Vacuum sensor timeoutAssume vacuum is still presentBlock wafer release
Drive status not updatingContinue workflowHold or fault workflow
IO module disconnectedUse cached inputsMark safety-visible state invalid

Fail-Safe Does Not Always Mean Instant Stop ​

This is subtle.

Some conditions require immediate hardware-level stop. Others require controlled software behavior.

Examples:

ConditionPossible Response
Guard door opened during motionSafety layer may remove motion enable; app records and transitions to inhibited/faulted
Vacuum not confirmed before releaseReject release command
Lost PLC comms while idleInhibit start commands
Sensor stale during workflowStop at safe workflow boundary
Unknown axis position after restartRequire homing/revalidation
Safety state changed during auto runpause/fault workflow depending on severity

Fail-safe design means each unsafe or uncertain condition has a defined response.

Not this:

text
Something weird happened. Let the exception bubble up.

But this:

text
Safety state became unknown.
New motion commands are inhibited.
Current workflow transitions to SafetyHold.
Operator recovery requires safety state revalidation.
Diagnostic event is recorded.

Part 6 — Interlock State Modeling ​

A weak system has booleans everywhere:

csharp
if (doorClosed && !estop && vacuumOk)
{
    Move();
}

A stronger system has an explicit model.

Example:

csharp
public enum SafetyConditionState
{
    Satisfied,
    Inhibited,
    UnsafeActive,
    Unknown,
    Stale,
    Recovering,
    Faulted
}

A machine-level safety view might look like:

csharp
public sealed record SafetySnapshot(
    SafetyConditionState OverallState,
    IReadOnlyList<InterlockStatus> Interlocks,
    DateTimeOffset Timestamp,
    bool IsFresh);

public sealed record InterlockStatus(
    string Code,
    string Name,
    SafetyConditionState State,
    string? ActiveReason,
    DateTimeOffset LastUpdated);

Practical States ​

StateMeaning
Safe / permissive satisfiedRequired condition is confirmed and fresh
InhibitedCommand/action is actively blocked
Unsafe condition activePhysical or logical unsafe condition exists
Unknown / staleState cannot be trusted
RecoveringSystem is moving from unsafe/unknown toward validated state
FaultedRecovery requires explicit action or service intervention

Unknown Is Different from Safe ​

This is a common beginner mistake.

Bad:

text
DoorClosed = false means unsafe.
DoorClosed = true means safe.
No value means probably safe.

Good:

text
DoorClosed confirmed fresh = permissive satisfied.
DoorOpen confirmed fresh = unsafe active.
No fresh value = unknown = unsafe for command gating.

Acknowledged Is Different from Resolved ​

Another common mistake:

text
Operator clicked Acknowledge.
Therefore fault is gone.

No.

Acknowledged means:

The operator has seen the condition.

Resolved means:

The physical condition is no longer active and the system has revalidated it.

These are not the same.

State Diagram ​

text
                  +----------------+
                  |     Safe       |
                  | Permissives OK |
                  +-------+--------+
                          |
                          | interlock becomes active
                          v
+-----------+     +----------------+     +----------------+
| Unknown / | --> |   Inhibited    | --> | Unsafe Active  |
|  Stale    |     | Command Blocked|     | Condition True |
+-----+-----+     +--------+-------+     +--------+-------+
      ^                    |                      |
      |                    | condition clears     |
      |                    v                      |
      |           +----------------+              |
      |           |   Recovering   | <------------+
      |           | Revalidation   |
      |           +--------+-------+
      |                    |
      | revalidation fails | revalidation passes
      |                    v
      |           +----------------+
      +---------- |    Faulted     |
                  | Needs Action   |
                  +----------------+

Explanation:

  • Safe means permissives are confirmed.
  • Inhibited means the system blocks commands.
  • Unsafe Active means a real unsafe condition is present.
  • Unknown/Stale means the system cannot trust the state.
  • Recovering means physical conditions may have improved, but the system has not revalidated yet.
  • Faulted means automatic continuation is not allowed.

Part 7 — Real-World Failure Scenarios ​

1. UI Allows Motion Because Interlock State Was Stale ​

What it looks like ​

The UI shows:

text
Door Closed
Motion Ready

The operator clicks Move Stage.

But the door status stopped updating 10 seconds ago.

The app uses the old value and sends the motion command.

Why it happens ​

The system models safety state as a simple boolean:

csharp
bool IsDoorClosed;

There is no timestamp, freshness check, or safety snapshot validity.

How experienced engineers prevent it ​

They model:

  • value
  • timestamp
  • freshness
  • source health
  • confidence/validity

Example:

csharp
public sealed record SafetySignal<T>(
    T? Value,
    DateTimeOffset LastUpdated,
    bool IsFresh,
    bool IsValid);

The command gate checks:

text
Door closed AND signal fresh AND safety PLC healthy

not just:

text
DoorClosed == true

2. Safety Signal Flickers and Causes Nuisance Stops ​

What it looks like ​

A door switch or light curtain signal flickers briefly.

The machine repeatedly stops, alarms, recovers, then stops again.

Operators lose trust and start asking for bypasses.

Why it happens ​

Possible causes:

  • noisy input
  • loose wiring
  • poor sensor alignment
  • edge-triggered software logic
  • no debounce/filtering at the correct layer
  • poor separation between warning, inhibit, and fault

How experienced engineers handle it ​

They do not simply ignore the signal.

They:

  • check whether filtering belongs in safety PLC, controller, or app
  • distinguish transient warning from confirmed inhibit
  • log signal transitions with timestamps
  • expose diagnostics for flicker patterns
  • avoid unsafe software-side bypasses

The important architectural point:

Do not “fix” nuisance stops by weakening safety semantics in application code.

3. Software Clears Fault but Physical Interlock Is Still Active ​

What it looks like ​

Operator presses Reset Fault.

The alarm disappears.

Then the machine immediately faults again.

Or worse, the UI says ready while the physical condition is still unsafe.

Why it happens ​

The app treats fault acknowledgment as fault resolution.

How experienced engineers prevent it ​

They separate:

text
Acknowledge
Reset
Revalidate
Resume

Example recovery flow:

text
Operator acknowledges fault
        ↓
System checks physical interlock state
        ↓
If condition still active: remain inhibited
        ↓
If condition cleared: enter recovering
        ↓
Revalidate machine state
        ↓
Allow resume only if safe

4. Manual/Service Mode Bypasses Checks Incorrectly ​

What it looks like ​

Auto mode blocks motion correctly.

But service mode has a manual jog button that directly calls the motion device adapter.

csharp
await axis.JogAsync(direction);

It bypasses the command gateway.

Why it happens ​

Engineers think:

“Service mode is for engineers, so it can skip normal checks.”

This is dangerous.

Service mode may allow different actions, but it should not bypass safety architecture.

How experienced engineers prevent it ​

They route service commands through the same safety-aware command gateway.

text
Service Tool
    ↓
Command Gateway
    ↓
Safety / Interlock Service
    ↓
Machine Controller
    ↓
Device Adapter

Service mode may have different permissives, but they should still be explicit.

5. Interlock Checked in One Command Path but Not Another ​

What it looks like ​

The normal Start Workflow button checks safety.

But a retry path, script path, or recovery path does not.

The machine behaves safely most of the time, then fails during unusual recovery.

Why it happens ​

Safety checks are scattered.

csharp
if (safetyOk)
{
    await MoveStage();
}

appears in many places.

Eventually one path forgets it.

How experienced engineers prevent it ​

They centralize command gating.

The device layer should not be casually reachable from workflow/UI code.

Bad:

text
UI → Device
Workflow → Device
Service Tool → Device
Recovery → Device

Good:

text
UI / Workflow / Service / Recovery
              ↓
        Command Gateway
              ↓
      Safety-aware Controller
              ↓
          Device Layer

6. Safety PLC Inhibits Motion but App Thinks Command Succeeded ​

What it looks like ​

The app sends a move command.

The motion controller accepts the command message, but the drive is safety-inhibited.

The app says:

text
Move completed

But the axis never moved.

Why it happens ​

The software confuses:

text
Command accepted

with:

text
Physical action completed

How experienced engineers prevent it ​

They model command execution stages:

text
Requested
Accepted
Started
InProgress
Completed
Rejected
Inhibited
Faulted
TimedOut

A motion command is not successful just because an API call returned successfully.

The software must verify actual execution and final state.

7. Unknown Safety State Treated as Safe ​

What it looks like ​

After restart, the app has no current safety snapshot.

But default values make the system appear safe.

Example:

csharp
public bool IsDoorOpen { get; set; } // default false

Default false accidentally means:

text
door not open

So motion becomes allowed before real IO is read.

Why it happens ​

Poor default modeling.

How experienced engineers prevent it ​

They avoid unsafe default booleans.

Better:

csharp
public enum DoorState
{
    Unknown,
    Open,
    Closed,
    Faulted
}

Initial state:

text
Unknown

Command gate behavior:

text
Unknown → inhibit

8. Operator Repeatedly Resets Without Resolving Root Cause ​

What it looks like ​

Machine stops.

Operator resets.

Machine stops again.

Operator resets again.

Eventually production calls engineering.

Why it happens ​

The system allows reset loops without requiring condition resolution or diagnostic escalation.

How experienced engineers prevent it ​

They design recovery logic that asks:

  • Did the physical condition clear?
  • Did the signal stabilize?
  • Has the state been revalidated?
  • Is repeated reset happening?
  • Should this escalate to service intervention?

A strong system records:

text
10:32:10 Door interlock active
10:32:12 Operator acknowledged
10:32:15 Reset requested
10:32:15 Reset rejected: Door still open
10:32:20 Door closed
10:32:22 Revalidation started
10:32:25 Revalidation passed
10:32:26 Resume allowed

This is much easier to support than:

text
Fault reset failed.

Part 8 — Software Design Implications ​

Safety-related constraints should be first-class architecture concepts.

They should not be hidden in random if statements.

Bad Approach ​

text
UI button disabled sometimes
Random boolean checks
Device adapter callable from everywhere
Service mode bypasses checks
Missing signal treated as safe
Fault reset clears software state only
No safety-state freshness check
No consistent rejection reason
No audit trail

This creates a fragile machine.

Good Approach ​

text
Central command gateway
Explicit safety/interlock model
Unknown-as-unsafe policy
Backend command enforcement
Independent hardware safety boundaries
Freshness/timestamp checks
Consistent rejection reasons
Traceable command decisions
Recovery flow revalidates physical state
Service mode uses controlled permissions, not bypasses

Component Diagram ​

text
+------------------+     +------------------+     +------------------+
| UI / HMI         |     | Workflow Engine  |     | Service Tool     |
|                  |     |                  |     |                  |
| Start button     |     | Auto sequence    |     | Manual jog       |
| Manual command   |     | Recovery logic   |     | Diagnostics      |
+--------+---------+     +--------+---------+     +--------+---------+
         |                        |                        |
         +------------------------+------------------------+
                                  |
                                  v
                     +--------------------------+
                     | Command Gateway          |
                     |                          |
                     | - validates command      |
                     | - checks mode            |
                     | - checks ownership       |
                     | - asks interlock service |
                     +------------+-------------+
                                  |
                                  v
                     +--------------------------+
                     | Safety / Interlock       |
                     | Service                  |
                     |                          |
                     | - safety snapshot        |
                     | - permissives            |
                     | - inhibits               |
                     | - freshness checks       |
                     | - rejection reasons      |
                     +------------+-------------+
                                  |
                                  v
                     +--------------------------+
                     | Machine Controller       |
                     |                          |
                     | - state machine          |
                     | - command execution      |
                     | - workflow coordination  |
                     +------------+-------------+
                                  |
                                  v
                     +--------------------------+
                     | Device Layer             |
                     |                          |
                     | - motion controller      |
                     | - robot                  |
                     | - IO module              |
                     | - vacuum                 |
                     +------------+-------------+
                                  ^
                                  |
                     +--------------------------+
                     | Safety State Sources     |
                     |                          |
                     | - safety PLC             |
                     | - IO                     |
                     | - drive status           |
                     | - sensors                |
                     +--------------------------+

Practical Architecture Rule ​

A good design makes unsafe shortcuts difficult.

A weak design relies on every developer remembering to check the right boolean.

Part 9 — Interview / Real-World Talking Points ​

How to Explain Interlocks Clearly ​

You can say:

An interlock is a machine condition that prevents or stops an action when the required safe conditions are not satisfied. In software architecture, I do not treat interlocks as UI validation. I model them explicitly and enforce them through backend command gating so every command path respects the same safety constraints.

Why Application Software Should Not Be the Only Safety Layer ​

You can say:

Normal application software is not reliable enough to be the only safety mechanism. It can crash, freeze, have stale state, or contain bugs. Safety-critical enforcement should usually live in independent safety hardware such as safety PLCs, relays, drive safety functions, or hardwired circuits. Application software still has an important role: observe safety state, respect inhibits, block unsafe command requests, guide recovery, and provide traceability.

Why Unknown/Stale Safety State Must Not Be Treated as Safe ​

You can say:

In machine software, unknown is not safe. If the app loses communication with the safety PLC, receives stale door status, or cannot confirm vacuum, it should inhibit relevant commands. A cached safe value is not enough. Safety-visible state needs freshness, validity, and source health.

Common Mistakes Software Engineers Make ​

Common mistakes include:

  • treating interlocks as normal form validation
  • disabling only the UI button
  • allowing service mode to bypass safety checks
  • using raw booleans without unknown/stale states
  • confusing command accepted with physical action completed
  • clearing software faults without checking physical conditions
  • scattering safety checks across code
  • treating missing sensor data as safe
  • not logging why a command was rejected
  • allowing recovery without revalidation

What Strong Engineers Understand ​

Strong engineers understand that:

Safety is not a feature added at the end. It is a constraint that shapes command flow, state modeling, recovery, diagnostics, and architecture boundaries.

They design systems where:

  • commands are gated centrally
  • permissives and inhibits are explicit
  • unknown state fails closed
  • safety hardware remains authoritative
  • software does not bypass safety boundaries
  • recovery requires physical revalidation
  • every rejected command has a clear reason
  • safety-related transitions are traceable

Final Mental Model ​

The best way to think about this topic:

text
Application software requests actions.
Command gating decides whether requests are allowed.
Safety/interlock state defines what is currently permitted.
Hardware safety layers independently prevent dangerous behavior.
Recovery logic revalidates before allowing continuation.
Unknown state is unsafe until proven otherwise.

For an industrial software architect, the goal is not merely to write code that works during the happy path.

The goal is to build software that behaves correctly when:

  • the door opens
  • the signal is stale
  • the safety PLC disconnects
  • the workflow is halfway complete
  • the operator presses reset repeatedly
  • the device rejects the command
  • the machine is physically not in the state the software expected

That is the real meaning of safety-aware machine software.

Docs-first project memory for AI-assisted implementation.

LCN Wafer Inspection Prototype