> 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-of-the-logic/comparison-to-classical-control-development.md).

# Comparison to classical control development

***

### 🔄 Classical way: Open loop with many breaks

In a classic PLC project it typically goes like this:

1. **Requirements** are defined
2. An expert translates them manually into **PLC code**
3. The code is tested – does it match the requirement?
4. **Documentation** is created separately – usually afterwards
5. When changes occur:
   * Adjust code
   * Update documentation
   * Re-run tests
   * Review by a specialist required
6. Result: An **open loop**
   * high effort for review, traceability, maintenance
   * any deviation in operation requires manual intervention

***

### 🧠 Selmo & SDEA: Closed, automated loop

With Selmo it works differently – structured and end-to-end:

1. **Requirements are formulated as a process model (SDEA)** formulated
2. From this are generated automatically:
   * the **control** (logic, states, transitions)
   * the **Monitoring** (bit control, CMZ, interlock, MXIC)
   * the **Documentation** (signal directory, sequence, safety functions)
3. **Code and HMI are generated directly from the model**
4. **Changes in the requirement** → Update model → everything adapts
5. In operation:
   * the model checks the machine in real time
   * no undefined states
   * automated fault diagnosis & documentation

***

### 🎯 Conclusion: Difference in depth

| Aspect             | Classical                     | Selmo with SDEA                 |
| ------------------ | ----------------------------- | ------------------------------- |
| Requirements       | manually translated into code | directly modeled                |
| Code review        | by experts                    | automatically validated         |
| Documentation      | retrospective and costly      | automatically from model        |
| Changes            | error-prone, costly           | simple via model change         |
| Real-time behavior | hard to verify                | formally monitored by the model |
| States             | often open, implicit          | deterministic and visible       |
| CE evidence        | manually assembled            | structured, directly derivable  |

***

With Selmo and the SDEA model a **closed, audit-proof loop**, in which logic, behavior, safety, operation and documentation **are always synchronized** – and **any deviation is detected immediately** is.

📌 *Selmo replaces testing effort with model clarity – and makes automation traceable, scalable and safe.*

### 🆕 Chapter: Comparison to the classic PLC – methodology & behavior

#### What is Selmo (SDEA) compared to the classic PLC?

| Criterion              | Classic PLC                             | Selmo (SDEA model)                                         |
| ---------------------- | --------------------------------------- | ---------------------------------------------------------- |
| **Sequence logic**     | via code, jump markers, conditions      | via modeled states and transitions                         |
| **Control logic**      | distributed in the code                 | central in the model (logic layer)                         |
| **Signal behavior**    | programmed directly (e.g., set/reset)   | modeled via bit control (`0`, `S`, `i`)                    |
| **Safety behavior**    | manually programmed                     | modeled (interlock, CMZ, MXIC)                             |
| **Manual mode**        | via auxiliary logic and button handling | automatically released/locked by MXIC                      |
| **Operator diagnosis** | created manually                        | automatically from the model (texts, colors, zone display) |
| **Restart**            | programmed individually                 | model-driven with synchronization and reset                |
| **Documentation**      | manually or externally                  | automatically generated from the model                     |

#### Advantages of the Selmo approach

* **Clarity**: Model instead of code – everyone sees what is happening
* **safety**: Structured CMZ and MXIC logic
* **Maintainability**: every change documented traceably
* **Fault tolerance**: Diagnosis comes directly from the model
* **CE conformity**: Operating modes, reset logic, safety reactions representable

With Selmo a **consistent behavior** is created – from the sensor to the HMI display, documented and testable.


---

# 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-of-the-logic/comparison-to-classical-control-development.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.