Was Selmo bewusst nicht beschreibt

Diese Seite beschreibt bewusst die Grenzen von Selmo.

Nicht, um etwas auszuschließen, sondern um klar zu machen, wofür Selmo gedacht ist – und wofür nicht.

Ein klares Modell braucht klare Grenzen.

---

Selmo beschreibt kein SPS-Programm

Selmo ist:

• kein SPS-Framework

• keine Sammlung von Bausteinen

• Programmrichtlinie als Standard und Methode

• Modell für Verhalten

Selmo beschreibt:

• Maschinenverhalten

• nicht die konkrete Implementierung im Code

Der erzeugte oder abgeleitete SPS-Code:

• ist eine Umsetzung

• nicht die Wahrheit

• nicht der Referenzpunkt

Der Code folgt dem Modell – nicht umgekehrt.

---

Selmo beschreibt kein HMI-Design

Selmo definiert:

• was angezeigt werden muss

• warum es angezeigt wird

• wann etwas als Abweichung gilt

Selmo definiert nicht:

• Layouts

• Bildschirmaufteilung

• Farben im grafischen Sinn

• Bedien-Workflows

Das HMI ist:

• eine Ansicht auf das Modell

• kein eigenständiges Konzept

Selmo beschreibt Bedeutung – nicht Gestaltung.

---

Selmo beschreibt keine Hardware-Auslegung

Selmo beschreibt keine:

• Mechanik

• Elektrokonstruktion

• Pneumatik- oder Hydraulikschaltungen

• Sensorplatzierung

• Sicherheits-Hardware

Diese Entscheidungen gehören:

• zur Konstruktion

• zur Risikobeurteilung

• zur Maschinenarchitektur

Selmo setzt voraus, dass diese Grundlagen fachlich korrekt sind.

Selmo modelliert Verhalten, nicht Physik.

---

Selmo beschreibt keine Sicherheits-Hardware

Selmo ersetzt keine:

• Not-Halt-Kette

• sichere Abschaltung

• Sicherheits-SPS

• mechanischen Schutzmaßnahmen

Selmo ergänzt diese durch:

• explizite Zustandsmodelle

• formale Überwachung

• nachvollziehbare Reaktionen

Hardware-Sicherheit schützt physikalisch. Selmo-Sicherheit schützt logisch.

---

Selmo beschreibt keine Projektorganisation

Selmo ist:

• kein Projektmanagement-Modell

• keine Vorgehensmethode für Termine

• keine Organisationsstruktur

Selmo kann Projekte unterstützen, ersetzt aber keine:

• Rollenklärung

• Verantwortungszuweisung

• Prozessorganisation

Selmo strukturiert Maschinen – nicht Organisationen.

---

Selmo beschreibt keine Verantwortung ab

Selmo automatisiert:

• Logik

• Überwachung

• Diagnose

• Konsistenz

Selmo automatisiert nicht:

• Entscheidungen über Zulässigkeit

• Sicherheitsverantwortung

• normative Bewertung

• Haftung

Diese Verantwortung bleibt:

• beim Menschen

• beim Unternehmen

• beim Betreiber

Selmo macht Verantwortung sichtbar – es übernimmt sie nicht.

---

Warum diese Abgrenzung wichtig ist

Diese Klarheit verhindert:

• falsche Erwartungen

• Überladung des Modells

• Missbrauch als „Allzwecklösung“

• spätere Enttäuschung

Und sie ermöglicht:

• saubere Integration in bestehende Prozesse

• klare Rollenverteilung

• belastbare Argumentation

• langfristige Stabilität

---

Zusammenfassung

Selmo beschreibt bewusst:

• was eine Maschine tun darf

• wann sie es tun darf

• warum sie so reagiert

Selmo beschreibt bewusst nicht:

• wie alles umgesetzt wird

• wie alles gestaltet wird

• wie alles organisiert wird

Selmo ist kein Ersatz für Engineering. Selmo ist dessen formales Fundament.