Industrielles Linux-OS · Plattformlinie mit 4M+ Einheiten

Das KI-native OS für vernetzte Fahrzeuge, Maschinen und Geräte. Feldbewährt. Vollständig programmierbar.

MOS4 liefert vollständige Telematik, Edge-AI-Vision, Remote Diagnostic und eine programmierbare Laufzeit — auf einem Linux-OS, das von modem-Klasse- bis KI-Klasse-Hardware skaliert. Die zugrunde liegende Munic-Plattformlinie ist seit 2012 in Produktion und läuft heute auf 4M+ Einheiten im Feld. MOS4 ist das OS der nächsten Generation auf dieser Linie.

rss 28.4 mb
boot 1.6 s
1 Kern · 5% Overhead
sbom: cyclonedx
cra: bereit
28,4 MB Speicher im Dauerbetrieb (RSS) modem-Klasse-Referenzprofil — Resident Set Size im Leerlauf
1,6 s Boot-Bereit-Zeit modem-Klasse-Referenzprofil — Zeit bis zum ersten beaufsichtigten Micro Service
<5% CPU / 10 MB Container-Budget Laufzeit-Overhead pro Micro Service — SDK-Referenzprofil
180 Plattform-Features deklarierte Service-Oberflächen im gesamten OS
bis ~100 TOPS KI-Klasse-Silizium bis ~100 TOPS auf der KI-Klasse-Stufe

Metriken mit dem Tag „modem-Klasse-Referenzprofil" wurden auf einem repräsentativen modem-Klasse-Produktionsgerät gemessen. Steady-State-RSS (Resident Set Size) im Leerlauf; Boot-Bereit-Zeit ist die Zeit vom Kernel-Handoff bis zum ersten beaufsichtigten Micro Service, der auf einen Service-Aufruf antwortet. Container-Budget ist der Laufzeit-Overhead pro Micro Service gemäß SDK-Referenzprofil.

Siliziumstufen

MOS4 läuft über drei Hardware-Stufen — modem-Klasse (stromsparende vernetzte Einheiten), compute-Klasse (Edge-Gateways mit höherem Durchsatz) und KI-Klasse (On-device-NPU-Inferenz, bis ~100 TOPS) — alle auf einem OS-Build, ohne Branch pro Stufe.

Hardware-Stufen →

Sechs Fähigkeiten · ein OS

Was im Lieferumfang enthalten ist.

Industrielles Linux-OS · vollständige Telematik · Edge-AI-bereit · Remote Diagnostic integriert · vollständig programmierbar in jeder Sprache · auf einer feldbewährten Plattformlinie mit 4M+ Einheiten. Wählen Sie die als Nächstes zu prüfende Fähigkeit.

Industrial OS — sicher by design 01 / 06

Ein industrielles Linux-OS. Sicher beim Build. Sicher unter Aufsicht.

Signierter Boot, signiertes A/B-OTA mit Auto-Rollback, TEE-gestützter Key-Store, CycloneDX-SBOM und CVE-Gate bei jedem Commit. Watchdogs und Ressourcenkontrakte pro Service. CRA-bereit.

Ein kuratiertes OS-Image über drei Hardware-Stufen — produktionsreife Alternative zu Yocto, AGL, Roh-Linux oder Hobby-ROS2. Sicherheit und funktionale Sicherheit sind keine Aufsätze: die Secure-Boot-Kette verankert die Vertrauenswurzel; Attest-und-Revert-OTA eliminiert die Klasse defekter Feldimages; CVE-Blocking und Lizenz-Gating laufen bei jedem Commit über jeden Micro Service. Auf der Safety-Seite — beaufsichtigte cgroup-Limits, deterministische Startreihenfolge, Anomalie-Erkennung über OpenTelemetry. CRA-Article-by-Article-Mapping liegt im Compliance-Pack.

Security + Safety →
Telematik 02 / 06

Vollständige Telematik für vernetzte Fahrzeuge.

Autonome Kommunikationsengine. Dual APN. eUICC Consumer + eUICC M2M. WiFi AP. 2G → 5G + LPWA.

UDS, J1939, ISOBUS, OBD-II, Modbus, CAN-FD — zweiundzwanzig Produktionsstacks. ELD-bereit. Die Mobilfunk-Schicht tauscht Modem-Vendor-Bibliotheken zur Laufzeit aus — die Unterstützung eines neuen Modems ist eine Konfigurationsänderung, kein Rebuild. Das produktive Telematik-Frontend auf MOS4: ekkofleet.com.

Multi Stacks ansehen →
Edge AI 03 / 06

Edge-AI-bereit — in TOML deklarieren.

Kamera, GPU und NPU teilen den Speicher. Keine CPU-Pixelkopien. Bis ~100 TOPS.

Deklarieren Sie die Pipeline in TOML; liefern Sie ein ONNX- oder TFLite-Modell. Munic trainiert neu, quantisiert, validiert und liefert das vereinheitlichte Modell per OTA aus. Vollständiger DMS- + ADAS-Workload (5 Modelle) plus H.265-Encoding auf einem 10-TOPS-Klasse-Gerät.

AI Funnel ansehen →
Remote Diagnostic 04 / 06

Die meisten Plattformen lesen das Fahrzeug. MOS4 liest es und spricht zurück.

Ein cloud-seitiger Bot steuert den Bus live. Lesen · Zurücksetzen · Rekonfigurieren · Reflashen.

Dieselbe Engine wie die autonome Telematik — anderer Betriebsmodus. Signierter TLS-Tunnel, Autorisierung pro Aktion, Attestieren-und-Rücksprung beim Reflashen. Für den Teil der Feldausfälle, die keinen Schraubenschlüssel brauchen, wird aus einer Servicefahrt ein Paket.

Remote Diagnostic ansehen →
Programmierbar 05 / 06

Vollständig programmierbar — in jeder Sprache.

Konfiguration. No-Code-Engines. Volles SDK in Python, Rust, C, C++, Go.

Drei Programmieroberflächen, pro Feature gewählt. Konfiguration (TOML) für Product Manager. No-Code-Engines (Signalverarbeitung, State-Machine-Policies, Fahrzeug-Kommunikation, Edge-KI) für Embedded-Engineers. Volles SDK, wo es darauf ankommt. Der einzige industrialisierte ROS2-Klasse-Host, der auf modem-Klasse-Hardware ausgeliefert wird — ROS2-Knoten laufen über das Sidecar-Muster mit. Oberflächen lassen sich in derselben Flotte mischen.

SDK ansehen →
Feldbewährte Plattformlinie 06 / 06

Auf einer Plattformlinie feldbewährt auf 4M+ Einheiten.

MOS4 ist das OS der nächsten Generation auf der Munic-Plattformlinie. Die Linie trägt Einsätze von 2012 bis heute — Personenwagen, Flotten, Flughafenbetrieb, Landwirtschaft, Industrieautomation.

Die Munic-Plattformlinie läuft auf 4M+ Einheiten bei einem nordamerikanischen Connected-Car-Versicherer (seit 2012), einem MVNO-Telematikprogramm (seit 2020), einem europäischen Automobilclub mit 21 M Mitgliedern (seit 2022), mehreren europäischen OEM-Flottenprogrammen unter NDA sowie Spezial-OEMs in Hochleistungsfahrzeugen, Flughafenbodenabfertigung, Off-Highway und Industrieautomation. MOS4 erbt Protokolle, Partner und die feldbewährte Architektur — und ergänzt das beaufsichtigte micro service-Modell, A/B-OTA und das CRA-grade Compliance-Pack. Modernes Telematik-Frontend darüber: ekkofleet.com.

Den Nachweis ansehen →
Out of the box, zusammen

Ein einziger MQTT-Client steuert alle vier No-Code-Engines — MSP, MEP, Multi Stacks und AI Funnel — aus einem Prozess. Kein Rust-Toolchain, kein SDK pro Engine, kein eigener Glue-Code.

Die vier MQTT-Beispiele ansehen →

Die Pipeline

Vier Engines · eine Plattform.

Jedes MOS4-Produkt führt dieselbe Vier-Engines-Pipeline aus: Bus- und IoT-Dekodierung, Signalverarbeitung, State-Machine-Policy und deklarative Edge-KI — dann Verzweigung zur On-device-Laufzeit und zur Munic-Cloud im selben OTA-Zyklus.

Vier-Engines-Pipeline. Fahrzeugbus- und Industrie-IoT-Eingaben (CAN, CAN-FD, J1939, Modbus) fließen in Multi Stacks; Sensoreingaben (Kamera, IMU, GNSS) fließen in MSP-Signalverarbeitungsgraphen. Dekodierte Multi-Stacks-Signale fließen ebenfalls in MSP. MSP-Ausgaben fließen in MEP, die State-Machine-Policy-Engine (T·C·A-Primitive darunter). MEP-Ausgaben fließen in AI Funnel, die deklarative Edge-KI-Engine. AI Funnel verzweigt zu zwei Zielen im selben OTA-Zyklus: einer On-device-NPU/GPU/CPU-Laufzeit und der Munic-Cloud für Retraining und OTA-Bereitstellung.

flowchart LR
  Bus[CAN · CAN-FD · J1939 · Modbus] --> MS[Multi Stacks]
  Sensors[Kamera · IMU · GNSS] --> MSP[MSP-Graphen]
  MS --> MSP
  MSP --> MEP[MEP — State-Machine-Policy]
  MEP --> AI[AI Funnel]
  AI --> RT[On-device NPU / GPU / CPU-Laufzeit]
  AI --> Cloud[Munic-Cloud — OTA + Retraining]
  class AI ai-node
  class RT ai-node
Bus + Sensoren → Multi Stacks → MSP → MEP → AI Funnel. Vier Engines, zwei Ziele: On-device-Laufzeit und Munic-Cloud teilen denselben OTA-Zyklus.

Vorher / nachher — dasselbe OS, Generationssprung.

Metrik Vorgängergeneration MOS4 (modem-Klasse-Referenz)
Boot-Bereit-Zeit ~90 s 1,6 s
Speicher im Dauerbetrieb (RSS) ~60 MB 28,4 MB
minimaler Micro Service — nutzerseitiges Rust n/a < 30 Zeilen

AI Funnel

Ihre KI deklarieren. Munic deployt sie.

Kunden liefern einen TOML-Graph plus ein ONNX/TFLite-Modell und einen COCO-Datensatz. Kamera, GPU und NPU teilen den Speicher direkt — die CPU kopiert keine Pixeldaten. Führen Sie mehrere gleichzeitige Modelle mit H.265-Encoding auf einem 10-TOPS-Klasse-Gerät aus.

KI · Intelligenzschicht
— STEP 01

Kunde liefert

Einen TOML-Graph, ONNX/TFLite-Modelle, einen COCO-Datensatz und optional einen Business-Logic-Container.

— STEP 02

Munic-Cloud erledigt

Neu trainieren, quantisieren, validieren, benchmarken, paketieren und per OTA das einheitliche Triage-Modell ausliefern.

— STEP 03

On-device-Laufzeit

GPU-Crop und -Resize, NPU-Inferenz, gemeinsamer Speicher durchgehend. Kein Pixel-Byte durchquert die CPU.

Fan-in-Diagramm: drei Eingabeströme laufen auf einem amber-Entscheidungsdiamanten zusammen — das On-device-KI-Triage-Modell

Remote Diagnostic

Aus einer Servicefahrt wird ein Paket.

Die Cloud eröffnet eine signierte Session, steuert den Bus, schließt die Aktion ab, beendet die Session. Für den Teil der Feldausfälle, die keine Werkstatt brauchen. Dieselbe UDS- / J1939- / ISOBUS- / Modbus- / J2534-Passthrough-Engine wie die autonome Telematik — anderer Betriebsmodus.

OEM · Garantie

ECU-Reset über Funk

Eine blockierte ECU (Electronic Control Unit) aus der Cloud zurücksetzen. Der Fahrer fährt weiter. Kein Abschleppwagen, kein Händlerbesuch.

EV-Hersteller

Live-Monitor-Zertifizierung

Live-Zelltelemetrie durch einen Lade- / Entladezyklus lesen. Zertifikat aus demselben Audit-Log.

Pannenservice

Weiterfahren-oder-Abschleppen-Triage

ECU-Zustand lesen. Entscheiden, ob das Fahrzeug die nächste Werkstatt erreichen kann oder abgeschleppt werden muss.

Flotteninspektor

Inspektor-Mutualisierung

Errand-Operatoren schließen am Fahrzeug an; ein Techniker prüft viele Fahrzeuge aus einem Büro.

Cloud-Egress

GraphQL-Mesh als Kunden-Einstiegspunkt.

Der Ende-zu-Ende-Cloud-Pfad: micro service im Container → MQTT-Bridge → Communication Gateway → cloud-connect → Cloud-micro service → GraphQL-Mesh → Kundenanwendung.

Cyan-Cloud-Server-Silhouette links, durch leuchtende Datenflüsse mit drei Fahrzeugen rechts (Limousine, LKW, Bagger) verbunden — Telematik-Topologie auf dunklem Blueprint-Hintergrund

Cloud-Egress-Topologie — Micro Service zum GraphQL-Mesh

flowchart LR
    A[Micro Service im Container] --> B[MQTT-Bridge]
    B --> C[Communication Gateway]
    C --> D[cloud-connect]
    D --> E[Cloud-micro service]
    E --> F[GraphQL-Mesh]
    F --> G[Kundenapp]

Öffentliche GraphQL-Gateway-Referenz: gateway.munic.io/services/graphql_gateway/docs/

Container-Laufzeit

Hot-Swap. Kein Neustart.

Eigenen Knoten einlegen. Einen Micro Service austauschen, ohne das Gerät neuzustarten. Prozess-isolierte Container mit erzwungenen Ressourcenlimits. First-Class-SDKs in Python, Rust, C, C++, Go. Jede Sprache, die MQTT spricht, fährt mit.

Prozess-isolierte Container

Ressourcenlimits als Vertrag, nicht Best-Effort. crun-Produktions-Runtime über cgroups v2.

Eigenen Knoten einbringen

Bestehende Python-, Rust-, C-, C++-, Go-Knoten lassen sich unverändert übernehmen. Keine Code-Änderungen, um auf dem typisierten Bus zu fahren.

Jede MQTT-fähige Sprache

Oberhalb der SDK-Schicht publiziert und abonniert jeder Client — sprachneutral.

ROS2-Laufzeit-Alternative

Ein erstklassiges ROS2-Sidecar-Gateway brückt DDS-Graphen in MOS4. Bestehende ROS2-Knoten fahren mit — der einzige industrialisierte ROS2-Klasse-Host auf modem-Klasse-Hardware.

SDLC · CI · Compliance

Typisierte Service-Verträge. SBOM bei jedem Release.

Jeder Micro Service publiziert seinen Vertrag. Jedes Release liefert ein CycloneDX-SBOM, einen CVE-Scan, signierte Binärdateien und eine OpenTelemetry-Oberfläche. CRA-bereit — Article-by-Article-Mapping im Compliance-Pack.

CycloneDX-SBOM Software Bill of Materials, jedes Release
Signierte Releases Binärdateien signiert, Audit-Log pro Release
CVE-Gate Abhängigkeits-Scan, jeder Commit
Statische Analyse Secure-Code-Muster erzwungen
OpenTelemetry Observability-Oberfläche, jeder Micro Service
CRA Article-by-Article EU Cyber Resilience Act, gemappt
Operations

Die Day-2-Schicht ist im Lieferumfang enthalten.

Beobachtbarkeit, Sicherheit, OTA, Remote-Steuerung, Lifecycle. Fünf Fähigkeiten, eine Plattform, jedes Gerät.

Operations-Schicht erkunden →
CRA-bereit

CRA-bereit. Ab Tag eins. Bei jedem Release.

Artikel-für-Artikel CRA-Mapping, SBOM, Sicherheitspipeline, PSIRT-Prozess.

Compliance lesen →

Auf MOS4 aufbauen.

Starten Sie mit dem Service-Katalog — deklarieren Sie die benötigten Fähigkeiten, dimensioniert nach Siliziumstufe. Engineering ist einen Klick entfernt, sobald ein Fit-Gespräch nötig wird.

Bauen Sie auf MOS4?

Eine Antwort vom Engineering-Team, ~24 h. Kein Deck, kein NDA.

Mit Engineering sprechen