> 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/4-structure-of-the-machine-static/zone.md). # Zone **Goal:** Connection to real technology\ **Content:** * Zone types (Input, Output, In-Out, Mem) * Signal assignment * HMI texts * Diagnosability ### 1. Why are there zones? In classic control projects, signals are used directly in the code.\ Their meaning arises implicitly through logic, comments or experience. This leads to typical problems: * Signals are contextless * Meaning changes depending on where in the code * Diagnosis is fuzzy or manual * Safety and sequence aspects get mixed **The zone exists to give signals meaning, responsibility and context.** *** ### 2. What is a zone? A **Zone** is the **formal representation of a technical fact** within a sequence. A zone: * encapsulates one or more signals * gives them **functional meaning** * is in the context **of a specific sequence** defined * is uniquely diagnosable > **Everything used in a sequence must be a zone.** A zone is **not**: * just an input * just an output * just a memory bit It is **meaning + behavior + diagnosis**. *** ### 3. Classification in the Selmo overall model The zone is the link between logic and real technology: * **Sequence** – describes *what* is supposed to happen * **Zone** – describes *with what* it happens * **Signal** – is the physical implementation Zones do not exist **globally**, but always: * within a sequence * with a clear functional role *** ### 4. Zone types Selmo distinguishes four basic zone types: #### Input zone * represents pure feedback * e.g. sensors, push buttons, status signals * no active influence *** #### Output zone * represents pure actions * e.g. valves, lamps, motor enables * no feedback in the model *** #### In-Out zone * combines action and feedback * e.g. cylinders, axes, grippers * typical source for sequence monitoring *** #### Mem zone * pure logical memory * no physical counterpart * stores state or sequence information > The zone type defines **structure**, not behavior. *** ### 5. Zone and signal assignment A zone is linked to real signals: * Inputs * Outputs * or both The following applies: * a zone can contain multiple signals * a zone is **not a PLC address** * Signals can be exchanged without changing the model **The zone is stable – the technology is replaceable.** *** ### 6. Zone in the system layer (bit-control context) The behavior of a zone is **not in the code**, but in the **system layer** determined. For each state of the sequence it is defined: * whether the zone is relevant * what behavior is expected * which deviations are allowed This is done via bit-control operands (`0`, `S`, `i`). > **Zone + state + operand = behavioral contract** The full meaning of the operands is described in the chapter **Bit-Control** . *** ### 7. Behavior of a zone in operation A zone is at any time: * assessable * monitorable * diagnosable Depending on the set operand: * `S` → expected behavior / guidance * `i` → mandatory condition / protection * `0` → no meaning in the current state A zone does not know a "debug state" or a special mode. *** ### 8. Zone in manual operation In manual operation the zone immediately shows its state: * **blue** → zone meets the expectation of the current state * **red** → zone deviates from the expected behavior The operator recognizes: * which zone is relevant * why a state is not fulfilled * where targeted intervention is necessary > The operator works **not on actuators**,\ > but on the **fulfillment of zone conditions**. *** ### 9. Safety functions at zone level Zones are carriers of safety and monitoring functions: * **Interlock (`i`)**\ state-dependent sequence monitoring * **CMZ (Constantly Monitoring Zone)**\ state-independent, permanent monitoring * **Pair-Check**\ monitoring contradictory signal states * further plausibility checks (e.g. processing-check) > Safety is a **property of the zone**, not of the code. *** ### 10. Zone and diagnosis Each zone has: * a clear HMI text * an unambiguous meaning * a definable diagnostic reason Diagnosis is created automatically: * from the current state * from the expected behavior * from the actual signal feedback There is **no diagnosis without a zone cause**. *** ### 11. Distinction from other elements To clarify: * A **Zone** is **not a sequence**\ → it does not describe a sequence * A **Zone** is **not a signal**\ → it gives signals meaning * A **Zone** is **not a hardware zone**\ → it does not encapsulate operating modes * A **Zone** is **not a safety control**\ → it models monitoring, but does not replace hardware safety *** ### 12. Typical modeling errors with zones Common errors are: * Signals without a zone * collective zones without clear meaning * technical instead of functional zones * safety logic outside the zone * same zone for different tasks A good rule of thumb: > **If a zone cannot be explained, it is incorrectly modeled.** *** ### 13. Summary A zone is: * the smallest meaning-bearing unit in Selmo * the connection between logic and technology * fully monitorable and diagnosable * basis for safe operation and clear operation > **Without zones there is no explainable machine.** --- # 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/4-structure-of-the-machine-static/zone.md?ask=&goal= ``` `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.