> 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/cmz-constantly-monitoring-zone.md).

# CMZ – Constantly Monitoring Zone

**Goal:** Protect critical signals\
**Content:**

* Sequence / HW zone / Plant
* Shutdown behavior
* No manual movement on fault

### 1. Why is CMZ needed?

Interlocks (`i`) monitor conditions **dependent on state**.\
However, many safety- and integrity-relevant signals are **always relevant** – regardless of which state a sequence is in.

Typical examples:

* Doors, protective devices
* Power and supply states
* Basic process releases
* physically impossible states

If such signals are only checked depending on state, the result is:

* unclear reactions
* incomplete monitoring
* hard-to-explain fault patterns

**CMZ exists to explicitly and deterministically monitor permanently valid conditions.**

***

### 2. What is a CMZ?

A **CMZ (Constantly Monitoring Zone)** is a **zone**, whose state **is permanently monitored – regardless of the current state of a sequence**.

A CMZ is:

* state-independent
* continuously active
* deterministic

A CMZ is **not**:

* an interlock (`i`)
* a safety relay
* an emergency stop
* a hardware safety module

> **CMZ is a logical monitoring function in the model.**

***

### 3. Basic principle of the CMZ

The basic principle is strict:

* A CMZ does not know "doesn't matter right now"
* It only knows **valid** or **invalid**
* Its evaluation is **always active**

It follows:

> **If a CMZ is violated, the system must not move.**

CMZ monitors **system integrity**, not sequence logic.

***

### 4. CMZ levels (hierarchy)

CMZs exist on three levels:

#### 4.1 CMZ at sequence level

* concerns **only a single sequence**
* typical use cases:
  * process-critical releases
  * permanent conditions for a process

Fault effect:

* Automatic release of this sequence is withdrawn
* other sequences remain unaffected

***

#### 4.2 CMZ at hardware-zone level

* concerns **all sequences** within the hardware zone
* typical use cases:
  * Door contacts of a module
  * Power supply of a unit

Fault effect:

* Automatic release of the entire hardware zone is withdrawn
* all contained sequences stop

***

#### 4.3 CMZ at plant level (Total CMZ)

* concerns **the entire plant**
* typical use cases:
  * main power
  * overarching safety conditions

Fault effect:

* complete plant stop
* all hardware zones and sequences are locked

> **Higher CMZ levels always override lower ones.**

***

### 5. Behavior on CMZ deviation

In the event of a CMZ deviation, the following always applies:

* immediate withdrawal of automatic release
* stop of all affected sequences
* **no manual movement possible**
* clear diagnosis

There are:

* no transitional states
* no "continue to the end"
* no special handling in manual operation

> **CMZ fault means: The system must not move.**

***

### 6. Difference CMZ vs. Interlock (`i`)

| Feature               | Interlock (`i`)  | CMZ            |
| --------------------- | ---------------- | -------------- |
| State-dependent       | yes              | no             |
| Permanently active    | no               | yes            |
| Effect in manual mode | restricted       | full           |
| Purpose               | Protect sequence | Protect system |

**Mnemonic:**

> `i` protects the sequence,\
> **CMZ protects integrity, people and machine.**

***

### 7. CMZ and manual operation

CMZ applies **unrestricted also in manual operation**.

This means:

* no manual movement on CMZ fault
* no bypass by changing operating modes
* no "service exception"

> **Manual operation is not a safety mode.**

***

### 8. CMZ and diagnostics

A CMZ deviation generates:

* a clear diagnosis
* with clear assignment:
  * Sequence
  * Hardware zone
  * or Plant

Properties of the diagnosis:

* no aggregated messages
* no ambiguity
* direct traceability to the cause

The diagnosis is created **automatically from the model**.

***

### 9. CMZ in the plant's safety concept

CMZ:

* replaces **no** hardware safety functions
* complements functional safety
* increases traceability and arguability

CMZ is:

* part of the logical safety architecture
* basis for formal proofs
* crucial for auditable systems

> **CMZ complements hardware safety through formal model monitoring.**

***

### 10. Typical mistakes in dealing with CMZ

Common mistakes are:

* Using CMZ as a substitute for interlocks
* defining too many CMZs
* choosing the wrong CMZ level
* not modeling safety-relevant signals as CMZ
* misunderstanding CMZ as a convenience feature

Rule of thumb:

> **Everything that must always be correct belongs in a CMZ.**

***

### 11. Why CMZ is crucial for Selmo

CMZ enables:

* complete, permanent monitoring
* clear hierarchical reactions
* deterministic system behavior
* standardizable argumentation
* responsible automation

Or put differently:

> **CMZ turns sequence control into a responsible system.**

***

### 12. Summary

A CMZ is:

* a permanently monitored zone
* independent of the process
* strictly effective hierarchically
* basis for safe and explainable machines

> **Without CMZ there is no complete system integrity.**


---

# 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/cmz-constantly-monitoring-zone.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.
