40 Regeln. 40 YAML-Einträge. Null Rust-Dateien.

Richtlinien-Modell

Trigger → Condition → Action. Nicht mehr.

Jede Regel hat genau drei Teile. Es gibt kein Ausführungsmodell jenseits dieses Konstrukts.

Authoring-Oberfläche

Ein knotenbasierter Editor, der YAML exportiert.

MEP ist einer von vier visuellen Authoring-Engines in MOS4s No-Code-Schicht, neben dem Signal-Graph-Editor, dem KI-Pipeline-Builder und der Multi-Stack-Konfigurations-Ansicht.

Zwei Ansichten, eine Datei

Zustandsmaschine für den Produktverantwortlichen. T·C·A für den Ingenieur.

Dieselbe Geofence-Richtlinie liest sich als Drei-Zustands-Maschine im Designer und als drei T·C·A-YAML-Regeln in der Engineering-Ansicht. Die YAML-Datei ist die Zustandsmaschine — es gibt keine separate Laufzeit.

stateDiagram-v2
  [*] --> außerhalb
  außerhalb --> annähernd: nah
  annähernd --> innerhalb: Eintritt
  annähernd --> außerhalb: Austritt
  innerhalb --> annähernd: nah
  innerhalb --> außerhalb: Austritt

rules:
  - name: enter_geofence
    on_event: geofence.near
    when: state == "approaching"
    do:
      - set: { state: "inside" }
      - emit: geofence.entered

  - name: leave_geofence
    on_event: geofence.exit
    do:
      - set: { state: "outside" }
      - emit: geofence.left

  - name: approach_geofence
    on_change: distance_m
    when: distance_m < 50 and state == "outside"
    do:
      - set: { state: "approaching" }

Der visuelle Designer rendert das Zustands-Diagramm aus dem YAML; das YAML bleibt das Deployment-Artefakt. Einen Zustand hinzufügen bedeutet eine Regel hinzufügen — das Diagramm aktualisiert sich automatisch.

Beispiel-Regeln

Was Integratoren ausliefern.

Deployment-Abdeckung

MEP wird in allen sechs Deployment-Szenarien geliefert.

Zustandsmaschinen- und LED-Steuerungs-Richtlinien gehören zu den Fähigkeiten mit der höchsten Abdeckung in der MOS4-Feature-Matrix — verfügbar von leichten Dongle-Formfaktoren bis zu compute-class-Gateway-Plattformen.

MEP-Richtlinien kombinieren mit der Multi-Stack-Schicht für ereignisgesteuerte Daten-Routing-Sequenzen. Siehe Multi Stacks für Cross-Stack-Strategie-Komposition.

Knoten-Katalog

58 Knoten-Typen über drei Kategorien.

10 Triggers · 17 Conditions · 31 Actions — zur Build-Zeit aus dem Engine-Schema abgeleitet. Jeder Knoten ist im visuellen Designer und in handverfasstem YAML verfügbar.

Mit call_interface-Aktionen MSP, Inferenz-Engines und benutzerdefinierte Treiber aus jeder Richtlinien-Regel erreichen. Siehe das SDK für das Authoring von micro services, die MEP aufrufen kann.

FAQ

Häufig gestellte Fragen

• Brauche ich einen Rust-Entwickler, um nach dem Deployment eine Regel zu ändern?

  Nein. Eine Regel zu ändern bedeutet YAML zu bearbeiten und die aktualisierte Richtlinie zu pushen — via OTA oder einen direkten Service-Aufruf. Kein Rust-Toolchain, kein Firmware-Rebuild, kein Reflash. Hot-Reload entwässert laufende Regeln und tauscht den Richtlinien-Graphen atomar aus.

• Was ist das genaue Richtlinien-Modell?

  Jede Regel hat genau drei Teile: einen Trigger (on_change, on_event oder on_schedule — Delay/Periodic/Cron in UTC); eine optionale Bedingung (Ausdruck gegen DB-Zustand und Ereignis-Payload); und eine oder mehrere Aktionen (DB-Schlüssel setzen, Ereignis ausgeben, call_interface oder eine andere Regel planen). Es gibt kein Ausführungsmodell jenseits dieses Konstrukts.

• Ist MEP eine endliche Zustandsmaschine?

  MEP-Regeln drücken zustandsmaschinen-artiges Verhalten durch T·C·A-Primitive aus. Das Richtlinien-YAML ist die Zustandsmaschine — es gibt keine separate Zustandsmaschinen-Laufzeit. T·C·A ist das Regel-Primitiv; das zusammengesetzte Regelwerk ist die Zustandsmaschine. Beide Lesarten werden geliefert — der visuelle Designer rendert das Zustands-Diagramm für Produktverantwortliche; das YAML bleibt das Engineering-Artefakt.

• Welche Zeitzone verwendet die Cron-Planung?

  Nur UTC. Zeitzonenbewusste Planung wird derzeit nicht unterstützt.

• Kann eine Richtlinie einen anderen MOS4-micro service aufrufen?

  Ja. Die call_interface-Aktion erreicht jeden MOS4-micro service — MSP, Inferenz-Engines und benutzerdefinierte Treiber. Der Schnittstellen-Proxy validiert die Semver-Einschränkung bei der Richtlinien-Ladezeit, speichert die Verbindung und wendet ein konfigurierbares Timeout an (Standard 3 000 ms pro Aufruf). Kein Pro-Integration-Verbindungscode. Siehe das SDK für das Authoring benutzerdefinierter micro services.

• Kann ich Regeln ohne Hardware testen?

  Ja. Ein semantisches Lint-Tool validiert YAML, bevor es ein Gerät erreicht — fängt undefinierte DB-Schlüssel, fehlende requires:-Deklarationen, zyklische Regelgraphen, unerreichbare Bedingungen und Ausdrucks-Typfehler ab. Ein eigenständiger Szenario-Runner spielt YAML-Dateien Off-Target in CI-Pipelines ab. Ein Richtlinien-Engine-Test-Double erlaubt das Testen der Richtlinien-Auswertung in der Integration ohne einen vollständigen MOS4-Stack.