— Warum MOS4
Eine Plattform, fünf Entscheidungen zum Weiterleiten.
MOS4 ist ein verteiltes komponentenbasiertes Embedded-Linux-OS für vernetzte Fahrzeuge, Maschinen und IoT — gewählt für Programme, die ein CRA-bereites SBOM, secure boot mit beaufsichtigter Laufzeit, AI-class-Silizium-Unterstützung, ein OS über alle Siliziumstufen und ein Sechs-Sprachen-SDK benötigen. Die Seite unten gliedert die Antworten in fünf Entscheidungsflächen — Compliance, Sicher-und-Safe, Ökonomie, Narrativ, Engineering — sodass jeder Abschnitt an den Kollegen weiterleitbar ist, der ihn verantwortet.
Was eine Lieferantenbewertungsmappe vom OS-Anbieter braucht.
Der EU Cyber Resilience Act gilt ab 2027. MOS4 liefert eine CycloneDX-SBOM, ein öffentliches PSIRT und ein Artikel-für-Artikel-CRA-Mapping mit, sodass Rechts- und Sicherheitsteams das Compliance-Paket in eine Lieferantenbewertungsmappe aufnehmen können.
CycloneDX-SBOM bei jedem Release
Maschinenlesbare Stückliste — herunterladbar aus dem Kundenportal zur Aufnahme in Beschaffungs-Nachweispakete. cargo cyclonedx läuft bei jedem Commit über 52 micro services.
PSIRT + koordinierte Offenlegung
Öffentliche Adresse security@munic.io, Bestätigung innerhalb von 5 Werktagen, getrackte CVEs pro Release. Interne Patch-Ziele: 7 / 30 / 90 Tage nach Schweregrad; vertragliche SLAs pro Programm.
Artikel-für-Artikel-CRA-Mapping
Annex I §1, §2, Art. 13, Art. 14 — jede Anforderung ist auf das MOS4-Artefakt gemappt, das sie erfüllt. Das Team, das den Compliance-Pack verantwortet, dokumentiert nur die Anwendungsschicht.
Signiertes OTA + Cohort-Management
Ed25519-signierte Delta-Pakete, A/B-Partitionen, automatisches Rollback via Bootcount. Cohort- und Canary-OTA über den Munic-Cloud-Companion.
OSS-Hygiene + LTS
Upstream-OSS wird auf kontaminierende Lizenzen geprüft (LGPLv3 und Äquivalente werden vor der Integration bereinigt). cargo audit + cargo deny + semgrep laufen bei jedem Commit, um CVEs in OSS-Abhängigkeiten zu erkennen. Eine Langzeit-Support-Verpflichtung gibt Programmen eine stabile Basis über mehrjährige Produktionsläufe.
Security und Safety gehören dem OS.
Compliance-Papierkram (#01) ist nachgelagert zur Engineering-Haltung. Security und funktionale Sicherheit sind bei MOS4 Plattform-Eigenschaften: in der CI zur Build-Zeit, durch den Supervisor zum Startzeitpunkt und durch den Ressourcenkontrakt zur Laufzeit erzwungen. Dieselben Kontrollen laufen bei jedem Commit, jedem Release, jedem micro service.
Secure Boot + TEE-Key-Store
Hardware-verankerte Vertrauenswurzel. Signierte Boot-Kette auf unterstütztem Silizium. Schlüssel in einem Trusted Execution Environment — niemals der Applikationsschicht ausgesetzt.
Signiertes A/B-OTA mit automatischem Rollback
A/B-Partitionen mit kryptographisch signierten Images. Fehlgeschlagenes Update attest-and-revertet — die Field-Broken-Image-Fehlerklasse entfällt. Anti-Rollback erzwungen.
Beaufsichtigte Laufzeit mit Ressourcenkontrakten
Jeder micro service läuft in einem Container mit cgroup-CPU/Speicher/IO-Limits zum Startzeitpunkt erzwungen. Watchdog mit automatischem Neustart bei verpassten Heartbeats. Ein fehlverhaltener Service kann das Gerät nicht aushungern.
Deterministischer Start, typisierte Kontrakte
Startreihenfolge leitet sich aus einem deklarierten Abhängigkeitsgraph ab; die Registry verweigert einen fehlerhaft geordneten Graph zur Build-Zeit. Typisierte Protobuf-Kontrakte fangen Schnittstellen-Drift zur Compile-Zeit ab — keine Race-Condition-Klasse, kein stiller Field-Break.
Observability für flottenweite Anomalie-Erkennung
Traces, Metriken und strukturierte Logs jedes Services auf einer einheitlichen OpenTelemetry-Fläche. Restart-Zähler, Exit-Codes, Latenz und CVE-Advisories erscheinen in Ihrem Dashboard, bevor sie sich ausbreiten.
Ein OS über die gesamte Silizium-Leiter.
MOS4 läuft von modem-class-SoCs bis zu AI-class-Silizium auf einem einzigen OS. Munic portiert das OS; das Programm wählt die Siliziumstufe pro Produkt. Kein internes BSP-Team erforderlich. Dokumentierte Migrationspfade von RTOS, Hobby-Linux, Android Automotive und ROS2 auf vollständigem Linux.
Siliziumstufen-Leiter. Dasselbe MOS4-OS umspannt drei Siliziumklassen. modem-class — unter 5% Overhead, 28,4 MB RSS im Dauerbetrieb, 1,6 s erste-App-bereit-Boot. compute-class — Multi-Kamera-Erfassung, Container-Isolierung. AI-class — bis ~100 TOPS NPU auf AI-class-Silizium, binärkompatibel über die AI-class-Stufe. Munic portiert das OS über die Familie; der OEM wählt die Stufe pro Produkt.
flowchart LR M[modem-class<br/>RSS 28,4 MB · Boot 1,6 s<br/>unter 5% Overhead] C[compute-class<br/>Multi-Kamera · Container] A[AI-class<br/>bis ~100 TOPS NPU<br/>GPU↔NPU Shared Memory] M --> C --> A M -. ein OS .-> C C -. ein OS .-> A class A ai-node
28,4 MB RSS · 1,6 s Boot · <5% Overhead
modem-class-Silizium-Baseline. RSS im Dauerbetrieb und erste-App-bereit-Boot auf einem repräsentativen modem-class-Produktionsgerät. Dasselbe OS-Image skaliert auf AI-class-Silizium ohne separaten Branch.
Keine Toolchain-Lizenz pro Engineer
Multi Stacks + Remote-Diagnose ersetzt seitenbasierte Werkzeuge durch ein per-Device-Modell, flottenweit.
Migrationsmatrix inklusive
Dokumentierte Pfade von monolithischem RTOS, Hobby-Linux, Android Automotive und ROS2 auf vollständigem Linux — der mos-distro Cargo-Bundle-Generator und per-Target-Profile decken die häufigsten Embedded-Targets ab.
Hardware-Varianten, Code bleibt gleich
Die Siliziumspanne reicht von einer No-NPU-/No-GPU-modem-class-Baseline bis zu AI-class-Silizium (~100 TOPS). Derselbe Binärsatz läuft über die gesamte Familie — kein Portierungsaufwand, kein Retraining, keine Neuvalidierungskosten beim Auf- oder Absteigen der Silizium-Leiter. Produktionskostenleiter nach Volumen: siehe munic.io für SKUs und Stufen.
Fähigkeiten ausliefern, keine Marketing-Versprechen.
Die On-device-KI-Pipeline ist vollständig verfügbar. Kamera, GPU und NPU teilen den Speicher direkt — die CPU kopiert keine Pixeldaten. Führen Sie einen vollständigen DMS+ADAS-Workload (5 Modelle) plus H.265-Encoding auf einem 10-TOPS-Gerät aus. In TOML konfiguriert; über denselben OTA-Kanal wie Code deployt.
Shared-Memory-Kamera-zu-NPU-Pipeline
Kamera, GPU und NPU teilen den Speicher direkt — die CPU kopiert keine Pixeldaten. Die CPU plant, aber berührt keine Pixel. In TOML konfiguriert; via OTA deployt.
Vision: Multi-Kamera, GPU-Crop und -Resize, DSGVO-Live-Anonymisierung
Fünf Kameraeingaben (MIPI-CSI, GMSL2, USB UVC, RTSP/ONVIF, WebRTC). DSGVO-Live-Anonymisierung (Gesichts- und Kennzeichenunschärfe) wird durch einen Boot-Time-Policy-Toggle gesteuert, bevor ein Frame die Pipeline verlässt.
Referenz-Deployments hinter jeder Aussage
Performance-Fahrzeuge, Flughafen-Bodenbetrieb, Landwirtschaft, Off-Highway-Maschinen. Kunden stehen unter NDA, die Branchen, Fähigkeiten und Standards aber nicht.
Vollständiger KI-Stack von einem Anbieter — ein SLA von der Kamera bis zum LLM bis zum Audit-Log
Vision-KI und Sprach-KI laufen auf demselben Gerät unter einem einzigen Plattform-SLA. Kamera-zu-NPU-Inferenz, On-device-LLM mit refuse-preferred RAG und ein Prüfmanifest pro Antwort — alles von einem Anbieter, einem OTA-Kanal, einem Support-Vertrag.
Offline-first KI — RAG, LLM und Sprache laufen standardmäßig on-device; Cloud ist opt-in
Die Sprachplattform läuft standardmäßig vollständig on-device. Cloud-Zugang erfordert explizite Konfiguration an drei unabhängigen Gateways. Keine Konnektivitätsabhängigkeit für die Kerninferenz.
Python, Rust, C, C++, Go — alle auf derselben Plattform.
Umschulung gehört zu den größten versteckten Kosten in einem Embedded-Programm. MOS4 behält die Sprachen, die das Engineering-Team bereits einsetzt. MQTT, Prometheus, TOML und typisierte Schemata sind erstklassig. ROS2-Knoten (rclcpp/rclpy) laufen unverändert in einem MCM-Container über das Sidecar-Muster.
Fünf Sprachen, eine OCI-Container-Engine
Python, Rust, C, C++ und Go-Knoten laufen Seite an Seite unter cgroups-v2-Ressourcenerzwingung (crun-Produktions-Laufzeit). ROS2-Knoten laufen über das Sidecar-Muster mit. Bestehende Knoten lassen sich übernehmen; neue verwenden typisierte Protobuf-Schnittstellen. AGV/Robotik-Qualifikationsanforderungen: Mit dem Engineering-Team sprechen.
No-Code-Engines für Domänenexperten-Logik
MSP: 226 Signalverarbeitungsgraphen über 21 Fahrzeugdomänen, YAML-konfiguriert, kein Rust-Neukompilieren pro Domäne. MEP: Zustandsmaschinen-Policy-Engine (T·C·A darunter), Hot-Reload, paralleler Regelarbeitspool. Multi Stacks: Fahrzeug- und Industrial-IoT-Kommunikation, 16 Protokollfamilien deklarativ. AI Funnel: deklarative Edge-KI — TOML-Graph rein, OTA raus.
SDLC für ein industrielles Programm
cargo test, distro-E2E-Integration, cargo bench, cargo grcov (Coverage), cargo audit + geiger + deny (Sicherheit), semgrep (statische Analyse), cargo cyclonedx (SBOM) — jeder Commit, über ci-gamma-Shared-Template.
Observable by design
Prometheus-Metriken, OpenTelemetry-OTLP-Export, W3C-Trace-Context-Propagation, strukturierte Logs — automatisch für jeden registrierten Serviceaufruf über ctx.observer(). Dieselben Konventionen, die das Cloud-Team bereits betreibt.
MOS4 mit Alternativen vergleichen
Eignungsmatrix
Branche × Fähigkeit.
Finden Sie Ihre Branche, scannen Sie Ihre Spalte, qualifizieren Sie sich selbst. Jede Zelle fasst die Fähigkeit für diese Branche zusammen.
| Capability | Automobil | Maschinen | LKW & leichte Nutzfahrzeuge | IoT-Gateway | Video & Flotten-KI |
|---|---|---|---|---|---|
| Multi Stacks · Remote-Diagnose | CAN, CAN-FD, DoIP | ISOBUS, J1939 | HD-OBD, J1708, J1587 | Modbus, RS485 | — |
| AI Funnel · deklarative Edge-KI | OEM-spezifische Modelle | Ernte- / Asset-Erkennung | Fahrer-Scoring | Anomalie-Triage | Multi-Kamera-Retraining |
| Vision · ROI-Shader · ADAS+DMS | DMS, Blackbox | Bediener-Alarme | Dashcam + DMS | — | DSGVO Live-Anonymisierung |
| CRA · SBOM · Sicherheitspipeline | core | core | core | core | core |
| Hardware-Stufe | compute · AI-class | compute-class | compute-class | modem · compute | AI-class |
| Sprachen: Python · Rust · C · C++ · Go | alle fünf | C / C++ / Rust | C / C++ / Rust | Python / Rust | Python / C++ |
FAQ
Häufig gestellte Fragen
-
Für wen ist die Seite „Warum MOS4" geschrieben?
Die Seite ist nach Entscheidungsflächen gegliedert — Compliance, Ökonomie, Narrativ, Engineering, Verfügbarkeit — sodass jeder Abschnitt an den Kollegen weiterleitbar ist, der ihn verantwortet.
-
Wie adressiert MOS4 den EU Cyber Resilience Act?
Der CRA gilt ab 2027. MOS4 liefert eine CycloneDX-SBOM, ein öffentliches PSIRT unter security@munic.io und ein Artikel-für-Artikel-CRA-Mapping, das Annex I §1, §2, Art. 13 und Art. 14 abdeckt.
-
Auf welchen Siliziumklassen läuft MOS4?
Ein OS umspannt modem-class, compute-class und AI-class-Silizium. Die modem-class-Baseline liegt bei 28,4 MB RSS im Dauerbetrieb und 1,6 s erste-App-bereit-Boot, unter 5% Overhead. Munic portiert das OS; das Programm wählt die Stufe pro Produkt.
-
Welche Programmiersprachen laufen auf MOS4?
Python, Rust, C, C++ und Go-Knoten laufen Seite an Seite unter erzwungener Container-Isolierung. ROS2-Knoten laufen über das Sidecar-Muster mit. Bestehende Knoten lassen sich übernehmen; neue verwenden typisierte Protobuf-Schnittstellen.
-
Wie behandelt MOS4 Edge-KI?
Kamera, GPU und NPU teilen den Speicher direkt — die CPU kopiert keine Pixeldaten. Führen Sie einen vollständigen DMS+ADAS-Workload (5 Modelle) plus H.265-Encoding auf einem 10-TOPS-Gerät mit freiem CPU-Spielraum für Anwendungscode aus. Siehe /platform/ai-vision für Details.
-
Für welche Programmgrößen eignet sich MOS4?
MOS4 zielt auf kleine und mittelvolumige Programme — 10k bis 300k Einheiten — in den Branchen Automobil, Maschinen, LKW und leichte Nutzfahrzeuge, IoT-Gateway sowie Video und Flotten-KI.
-
Wie funktioniert Cohort- und Canary-OTA?
A/B-Partitionen, signierte Delta-Pakete und automatisches Rollback. Cohort- und Canary-Management wird serverseitig über den Munic-Cloud-Companion bereitgestellt.
Neu in der MOS4-Terminologie? Das Glossar erläutert MCM-Container, dma-buf, ci-gamma, J1939 und mehr.
Leiten Sie diese Entscheidungsfläche an den Kollegen weiter, der sie verantwortet.
Ein Gespräch, ein Artefakt, jede Schnittstelle und jeder Vertrag offen auf dem Tisch.