> 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/bit-control.md). # Bit control ### 1. Why is Bit-Control needed? In classical control programs behavior arises implicitly: * Conditions are distributed across the code * Expectations of signals are not fully described * Monitoring is performed at points or event-driven * Diagnosis is created afterwards This leaves a central question unanswered: **What is allowed, required, or irrelevant – in exactly this state of the machine?** Bit-Control exists to answer this question **explicitly, completely and formally** to answer. *** ### 2. What is Bit-Control? **Bit-Control** describes the **expected and permitted behavior of each zone in every state of a sequence**. It is: * not program code * not a safety function * not a query * not an event But: > **A formal behavior contract between state and zone.** *** ### 3. Basic principle of Bit-Control The principle is simple and strict: * A sequence is in exactly **a state** * Each zone has in this state **a defined meaning** * This meaning is **explicitly defined** Therefore: > **No state without evaluation.**\ > **No zone without meaning.** The result is: * complete state description * permanent monitoring * deterministic behavior *** ### 4. The Bit-Control matrix Bit-Control is formally represented as **cross table** represented: * **Columns** → States of the sequence * **Rows** → Zones * **Cells** → Operands (`0`, `S`, `i`) This matrix is: * **the model**, not the implementation * complete * unambiguously * machine- and human-readable > The Bit-Control matrix describes the entire logical behavior of a sequence. *** ### 5. The operands #### 5.1 `0` – Don’t Care **Meaning:** * The zone is in this state **not relevant** * Nothing is expected * Nothing is checked * No reaction occurs **Purpose:** * clear decoupling * focused models * avoidance of unnecessary dependencies *** #### 5.2 `S` – Sequence Check **Meaning:** * In this state **a behavior is expected** * The system: * if necessary sets an output * waits for a defined feedback * As soon as the expectation is met: * the state is considered fulfilled * the transition can take place **Purpose:** * Process control * operator guidance * deterministic progression > `S` describes **Progress**, not safety. *** #### 5.3 `i` – Interlock **Meaning:** * The condition **must be met** * In case of deviation: * immediate loss of automatic enable * stop of the sequence * automatic diagnosis **Purpose:** * protection of the process * prevention of inadmissible state combinations > `i` protects the **logical process**, not the machine as a whole. *** ### 6. Bit-Control and behavior in operation Bit-Control acts: * continuously * dependent on state * independent of the operating mode Differences: * `S` → leads and waits * `i` → monitors and protects * `0` → consciously ignores > Bit-Control evaluates **always the current model state**, not events. *** ### 7. Bit-Control in automatic operation In automatic operation applies: * Automatic enable is a prerequisite * Bit-Control monitors permanently * When fulfilled `S`: * state is completed * transition occurs automatically * In case of deviation of a `i`: * immediate abort * withdrawal of automatic enable * diagnosis is generated automatically It is **no additional error logic necessary**. *** ### 8. Bit-Control in manual operation Also in manual operation applies: * States remain valid * Bit control remains active * Monitoring remains effective The difference: * The operator influences zones manually * The goal is the **fulfillment of the current state conditions** A `i` continues to act as protection: * no inadmissible movement * no bypass of the logic > Manual operation is **not an exception**, but the same logic with a different source of influence. *** ### 9. Distinction from other monitoring To clarify: * Bit-Control ≠ **CMZ**\ → CMZ acts independently of state * Bit-Control ≠ **MXIC**\ → MXIC governs manual actions * Bit-Control ≠ **Safety hardware**\ → Bit-Control does not replace an emergency stop chain Bit-Control protects the **process in the model**, not physical safety alone. *** ### 10. Typical mistakes with Bit-Control Common mistakes are: * `i` use it excessively * `S` abuse it as a safety replacement * zones without clear meaning * states not evaluated completely * implicit assumptions instead of explicit operands A good rule of thumb: > **If you have to explain why something is the way it is, an operand is missing.** *** ### 11. Why Bit-Control is the core of Selmo Bit-Control enables: * complete behavior description * automatic, correct diagnosis * clear state logic * standardizable argumentation * formal foundation for AI support Or put differently: > **Bit-Control makes machine behavior explainable.** *** ### 12. Summary Bit-Control is: * the formal behavior core of Selmo * explicit, complete and deterministic * independent of implementation and UI * Foundation for process, diagnosis and safety > **Without Bit-Control there is no verifiable machine 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/4-structure-of-the-machine-static/bit-control.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.