> 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/6-operation-of-the-machine-user-view/mxic-manual-cross-interlock.md).

# MXIC – Manual Cross Interlock

## 6.4 MXIC – Manual Cross Interlock

MXIC stands for **Manual Cross Interlock**.\
It is the Selmo standard feature that **secures manual actions in manual mode**.

MXIC is **not a control element** and **not a button**.\
It is a **rule-based protection logic**that decides whether a manual movement **is allowed** or **must be prevented**.

***

### Why MXIC exists

In manual operation the operator can selectively influence zones to create states or eliminate deviations.

Without additional protective logic a risk arises:

* Movements could be executed even though prerequisites are missing
* technical interlocks would be implicitly expected
* safety and logic would be mixed

MXIC exists to prevent exactly that.

> **MXIC ensures**\
> **that manual movements are only allowed**\
> **when they fit the current model state.**

***

### Basic principle of MXIC

MXIC acts:

* exclusively at **Manual operation**
* the interface between **operator action** and **Zone**
* independent of the automatic sequence

For every manual action MXIC checks:

* which zone is being addressed
* which state is currently active
* whether an authorization is defined for this combination

The result is unambiguous:

* **allowed** → movement is executed
* **not allowed** → movement is prevented

***

### How MXIC is defined

MXIC is **defined model-based**, not programmed.

The definition is made:

* as the intersection of **button** and **Zone**
* with clearly formulated conditions
* analogous to the mindset of the system layer

In doing so it is specified:

* which button affects which zone
* under which conditions this is allowed
* when a movement must be prevented

> **MXIC is a formal rule –**\
> **not an exception in the code.**

***

### MXIC in the context of state

MXIC always considers:

* the current state of the sequence
* the significance of the zone in this state
* overarching monitors (e.g. CMZ)

This means:

* no movement outside the model context
* no implicit authorizations
* no bypass of the logic

> **Even in manual operation the state remains the reference.**

***

### Diagnosis instead of movement

If a manual movement **is not permissible** is:

* the movement will be **not executed**
* there is **no partial movement**
* instead a **clear diagnosis** is displayed

points to the affected zone

* explaining why the movement was prevented
* describes the contradictory state
* makes the missing condition visible

> **MXIC replaces dangerous movements**\
> **with explainable information.**

***

### Distinction from other mechanisms

To clarify:

* MXIC ≠ Interlock (`i`)\
  → `i` protects the sequence, MXIC protects manual actions
* MXIC ≠ CMZ\
  → CMZ acts permanently, MXIC only in manual mode
* MXIC ≠ safety hardware\
  → MXIC complements but does not replace a safe shutdown

MXIC is:

* a logical protective function
* part of the model
* completely deterministic

***

### Typical misconceptions about MXIC

Common misunderstandings are:

* ❌ “MXIC is just a key lock”
* ❌ “MXIC is optional”
* ❌ “MXIC replaces safety logic”
* ❌ “In manual mode MXIC can be bypassed”

All of these assumptions are false.

> **MXIC is an integral part**\
> **of a safe manual operation.**

***

### Summary

MXIC:

* protects against unauthorized manual movements
* checks every manual action based on the model
* prevents movement instead of correcting it
* produces diagnosis instead of risk

> **MXIC ensures that**\
> **the human in manual operation**\
> **remains within the model.**


---

# 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/6-operation-of-the-machine-user-view/mxic-manual-cross-interlock.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.