> For the complete documentation index, see [llms.txt](https://infosys.selmotech.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://infosys.selmotech.com/selmo-solution/selmo-solution-en/selmo-documentation/7-safety-and-monitoring/interlock-i.md).

# Interlock (I)

## Interlock (`I`) – state-dependent monitoring

The **Interlock (`I`)** is the mechanism for **state-dependent monitoring of the sequence**.\
It protects the logical consistency of a sequence and prevents a process from entering an **invalid state** from occurring.

The interlock is therefore **not a general safety concept**,\
but a **process safeguarding within the model**.

***

### Purpose of the interlock

The interlock answers the question:

> **May this state be active under the current conditions?**

It ensures that:

* mandatory prerequisites are met
* invalid combinations of states do not occur
* the process remains logically consistent

Interlocks are necessary because:

* not all conditions are relevant in every state
* monitoring must be targeted and context-dependent
* safety and process should not be mixed

***

### Interlock in the system layer

Interlocks are in the **system layer** via the operands **`i`** .

This means:

* each zone can be marked as an interlock in a state
* the meaning is **dependent on state**
* the evaluation is continuous

In the bit-control cross table, the following applies:

* I → condition **must be met**
* Deviation is **not tolerable**

> **An interlock is a mandatory statement**\
> **about the validity of a state.**

***

### Behavior on interlock deviation

If an I-condition is violated, the system reacts deterministically:

* the **automatic enable is revoked immediately**
* the affected **sequence stops**
* the current state remains
* a **clear diagnosis** is generated

There are:

* no continuation
* no transition
* no temporal tolerance

> **An interlock knows no gray area.**

***

### Interlock in automatic operation

In automatic operation an interlock means:

* the process must not continue
* the state is no longer logically valid
* the system stops immediately

The interlock thus protects:

* the logical sequence of the process
* the consistency of the state machine
* the traceability of the behavior

***

### Interlock in manual operation

Even in manual operation the interlock remains active.

This means:

* States cannot be "forced"
* invalid combinations of states are excluded
* the operator works under the same rules

Important:

> **Interlocks are not an automatic concept,**\
> **but part of the model.**

***

### Distinction from CMZ

For clear classification:

* **Interlock (I)**
  * acts **dependent on state**
  * protects the **process**
  * may under certain circumstances allow manual movement
* **CMZ**
  * acts **state-independent**
  * protects **system integrity**
  * Plausibility checks:

> **Interlock protects the process.**\
> **CMZ protects people, machine and plant.**

***

### Distinction from MXIC

Equally important:

* **Interlock (I)**
  * acts in the process context
  * evaluates state validity
* **MXIC**
  * acts only in manual operation
  * evaluates manual operator actions

Both complement each other,\
taking on **different roles**.

***

### Typical mistakes in dealing with interlocks

Common mistakes are:

* Using interlocks as a substitute for CMZ
* too many interlocks without clear justification
* Using interlocks for permanent conditions
* Misunderstanding interlocks as a comfort feature

Rule of thumb:

> **Everything that must always apply belongs in a CMZ –**\
> **not in an interlock.**

***

### Summary

The interlock (I):

* is a state-dependent monitor
* protects the logical consistency of the process
* acts in automatic and manual operation
* generates immediate, unambiguous reactions
* is an integral part of the system layer

> **Interlocks ensure that**\
> **a process only takes place where**\
> **it is logically allowed.**


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://infosys.selmotech.com/selmo-solution/selmo-solution-en/selmo-documentation/7-safety-and-monitoring/interlock-i.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.