— Plattform / Architektur
Der MOS4-Stack.
MOS4 ist ein verteiltes micro service OS über Linux: 8 Architektur-Schichten, 52 Produktions-micro services, 89 Proto-Schnittstellen, 10-Sekunden-Hot-Swap. Proto-definierte Schnittstellen, Registry-erzwungene Startreihenfolge und Hot-Swap sind Framework-Eigenschaften — keine Anwendungsverantwortlichkeiten.
Komponentenmodell
Eine Deklaration, vollständige Service-Oberfläche.
Jeder micro service deklariert proto-definierte provided_interfaces und required_interfaces. Der Code-Generierungsschritt schreibt die vollständige Service-Oberfläche: Server-Trait, Proxy, direkter Client, Fake-Test-Double, Metriken-Modul und Compliance-Test-Suite — aus einer einzigen Deklaration. Der Autor schreibt Lifecycle-Hooks und Business-Logik — nichts weiter.
Ein Code-Generierungsschritt
build_api::generate_component_code(dir, out_dir) in build.rs treibt: Proto-Parsing → Server-Trait → Proxy → direkter Client → Fake → Metriken-Modul →
Compliance-Test-Suite. Ein minimaler micro service umfasst unter 30 Zeilen nutzerseitiges Rust.
Registry-erzwungene Reihenfolge
start_level 0–10 ist die numerische Registry-Priorität — verschieden vom L0–L7-Architektur-Mentalmodell.
Die Registry erstellt einen Abhängigkeitsgraphen und erzwingt ihn beim Start; kein micro service
kann eine erforderliche Schnittstelle aufrufen, bevor ihr Anbieter sich registriert hat.
Hot-Swap auf Framework-Ebene
Wenn ein neuer Prozess sich mit einer vorhandenen component.id registriert, fordert
die Registry einen State-Dump von der alten Instanz an, stoppt sie, injiziert den serialisierten
Zustand in die neue und startet den Ersatz. Vom Ende des Kompilierens bis zum ersten erfolgreichen
Serviceaufruf auf einem echten Gerät: 10 Sekunden.
Den vollständigen micro service-Katalog durchsuchen — 52 Services, 89 Proto-Dateien.
Beaufsichtigte Laufzeit
Drei Überwachungsschichten, kein Boilerplate.
Das Framework überwacht jeden micro service mit Task-Checkpoints, Prozess-Health-Pings und Hardware-Watchdog-Integration. Korrekturmaßnahmen — Neustart, Reboot oder Hardware-Reset — eskalieren automatisch ohne per-Service-Konfiguration.
Watchdog
Micro services deklarieren benannte Task-Checkpoints mit Timeouts im #[component]-Makro. Das Framework überwacht drei Überwachungsschichten: Task-Checkpoints,
Prozess-Health-Pings zwischen Master- und Slave-Prozessen sowie den Linux-/dev/watchdog-Hardware-Eskalierungspfad. Fehlgeschlagener Checkpoint → Degraded → Neustart → Reboot →
Hardware-Reset.
Sentry
Zentralisiertes Issue-Tracking über alle micro services. Während des Registry-Startup-Grace-Fensters werden Cascade-Class-Fehler gegattet — ein Sentry-Cascade-Gate verhindert, dass Startup-Rauschen das Issue-Log kontaminiert. Operatoren können die Startup-Grace-Periode anpassen oder das Gate vollständig deaktivieren.
Beobachtbarkeit
Das Framework gibt pro-RPC-Histogramme, Fehlerzähler, Service-Uptime und
Lifecycle-Event-Traces für jeden registrierten Serviceaufruf aus — automatisch über ObservabilityRegistry. W3C-Trace-Context-Propagation ist inklusive; kein
per-Service-Instrumentierungsvertrag erforderlich.
Dashboards, OTA, Remote-Steuerung, Lifecycle — vollständige Beobachtbarkeitsoberfläche unter /de/platform/operations.
Registry + Transport
Transport per Endpoint-URL gewählt.
Die Master-Registry verantwortet Service Discovery und Startreihenfolge. Der Transport-Modus — Memory, Unix-Socket, Shared Memory, TCP, QUIC, WebSocket — wird per URI-Schema zur Bundle-Konfigurationszeit gewählt. Der Direkt-Modus umgeht die Serialisierung für In-Process-Aufrufer. Service-Code ist transportblind.
| Umgebung | Transport | Kodierung |
|---|---|---|
| Service-zu-Service auf demselben Chip | iceoryx2 SHM + dmabuf | zero-copy |
| Kamera- / Vision-Plane | SCM_RIGHTS fd-Übergabe | dmabuf-Handle |
| ROS2-Bridge | iceoryx2 DDS | protobuf / DDS |
| Cross-Host / TCP | TCP / Unix-Sockets / QUIC | zstd / LZ4 / gzip |
| WebSocket-Clients | WebSocket | zstd / gzip |
TCP, Unix-Sockets, Shared Memory, QUIC, WebSocket, Named Pipes und Ring-Buffer implementieren alle dieselbe Transport-Schnittstelle. Keine bedingte Kompilierung im Service-Code. On-Wire-Komprimierung (zstd, LZ4, Snappy, gzip) wird pro Verbindung ausgehandelt. Circuit Breaker und Retry sind in die Registry integriert.
Zwei Transport-Modi. Modus 1: micro service-zu-micro service-Datenaustausch auf demselben Chip verwendet Shared Memory mit Frame-Handles für Zero-Copy-Frame-Übergabe. Modus 2: ROS2-Bridge — rclcpp- und rclpy-Knoten veröffentlichen DDS-Topics; der Frame-Transport übersetzt sie in den MOS4-Bus und liefert typisierte Events an MOS4-micro services.
flowchart LR
subgraph S1["Micro service zu Micro service auf demselben Chip"]
A[Micro service A] -->|Shared Memory + Frame-Handle| B[Micro service B]
end
subgraph S2["ROS2-Bridge über den Frame-Transport"]
R[rclcpp / rclpy-Knoten] -->|DDS-Topic| F[Frame-Transport]
F -->|MOS4-Bus| C[MOS4-micro service]
end Die 4 Engines, eine Laufzeit
Eine Plattform bedient alle vier No-Code-Engines und N Container.
Supervisor, Registry, EventBus und der In-Process-MQTT-Broker sind gemeinsame Infrastruktur. MSP, MEP, Multi Stacks und AI Funnel verwenden alle dieselben Primitive — und so tut es auch jeder Kunden-Container in jeder der fünf unterstützten Sprachen.
Gemeinsame Plattform
- · Supervisor — Start, Stop, Neustart, Hot-Swap
- · Registry — typisierte Schnittstellen, SemVer, Abhängigkeitsgraph
- · EventBus — benannte Event-Verteilung
- · In-Process-MQTT-Broker — jeder Sprach-Container erreicht jeden Service
Engines und Container, Seite an Seite
- · MSP — kontinuierliche Signalverarbeitungsgraphen
- · MEP — Zustandsmaschinen-Policies (T·C·A darunter)
- · Multi Stacks — Fahrzeug- und Industrial-IoT-Kommunikation
- · AI Funnel — deklarative Edge-KI
- · N Container — Python · Rust · C · C++ · Go (ROS2-Sidecar)
Jede No-Code-Engine ist ausführlich dokumentiert unter /de/platform/no-code.
Glossar
Öffentlicher Name zu Engineering-Begriff.
| Begriff | Was es ist |
|---|---|
| Micro service | Die Laufzeiteinheit von MOS4. Rust-Crate, #[component]-Makro, Proto-Schnittstellen. |
| MCM | MOS Container Manager — schlanke Container-Engine mit erzwungener Ressourcenisolierung. |
| MD21 | Munics Telemetrie-Uplink-Protokoll (ASN.1 UPER), bandbreitenoptimiert. |
| MSP | MOS Signal Processing — YAML-Graph-Engine für fahrzeugdomänen-spezifischen Datenfluss. |
| MEP | MOS Event Processor — Zustandsmaschinen-Policy-Engine. Jede Regel ist ein Trigger-/Condition-/Action-Primitiv; das zusammengesetzte Regelwerk ist die Zustandsmaschine. Hot-reloadfähig. |
| iceoryx2 | Zero-Copy-IPC. Zwei Modi: SHM + dmabuf für denselben Chip, vollständiges DDS für die ROS2-Bridge. |
Stack-Diagramm-Labels (L0–L7) sind ein mentales Modell für die Schichtgruppierung. Die
Registry-Priorität verwendet ein numerisches start_level 0–10 — unterschiedliche Skala,
unterschiedlicher Zweck.
Cloud-Egress
Micro service zum GraphQL-Mesh — Ende zu Ende.
Micro service im Container
Anwendungscode oder ein Plattform-micro service veröffentlicht typisierte Events.
MQTT-Bridge
Jeder Standard-MQTT-Client — keine SDK-Übernahme erforderlich.
Communication Gateway
MD21-Uplink: ASN.1-UPER-Kodierung, bandbreitenoptimiert.
cloud-connect
Munic-Cloud-Relay — führt Multiplexing, Piggybacking, Komprimierung aus.
GraphQL-Mesh
Kunden-Einstiegspunkt. Öffentliche Referenz: gateway.munic.io
GraphQL-Mesh ist der Kunden-Einstiegspunkt — Cloud-seitig, nicht geräteseitig. Der öffentliche Referenz-Endpunkt ist das Entwicklerdokumentationsportal.
Entwickler-Unlock
RPC-Bridge — jeden micro service aus der Cloud aufrufen.
Die RPC-Bridge exponiert jeden registrierten MOS4-Service über den applications.rpc-Kanal. Akzeptiert JSON mit itfname, call und payload. Kein Protokoll- oder Wiring-Code über die Komponentenschnittstelle und den Cloud-seitigen Service hinaus.
Debuggen und Entblocken
Jeden micro service — einschließlich Container — aus der Cloud aufrufen, um den Zustand zu inspizieren, eine einmalige Aktion auszulösen oder eine seltene Situation auf einem Remote-Gerät zu entblocken.
KI-gesteuerte Hybrid-Flows
Ein KI-Agent oder eine Cloud-Automatisierungsschicht kann das Gerät über API steuern —
Sensoren abfragen, Aktuatoren auslösen, eine neue Policy laden — mit ListServices() , das den Live-Service-Katalog zur Laufzeit zurückgibt.
RoutingService ist Teil des Modem-Stacks, kein separater micro service. Die SDK-Entwicklersicht desselben RPC-Primitivs ist unter /de/platform/sdk zu finden.
MOS4 mit anderen Embedded-OS- und Plattformansätzen vergleichen unter Vergleichsübersicht.