Solutions · Automobil
Ein Connected-Vehicle-Programm ausliefern.
Ein verteiltes Komponenten-OS für Connected-Vehicle-OEM-Programme — 10k bis 300k Einheiten. Liefert den 16-Protokoll-Fahrzeug-Stack über obdstacks-v2, A/B-OTA, GNSS mit ESF-Dead-Reckoning und den CRA-bereiten Compliance-Pack ab Tag eins. Das Engineering-Team schreibt die Fahrzeug-Anwendung und Cloud-Policy — nicht das OS.
Was ab Tag eins ausgeliefert wird.
16 Fahrzeugprotokolle aus einer Runtime. Fehlercode-(DTC-)Lesen und -Löschen. J2534-2-Passthrough für bestehendes Dealer-Tooling. Over-the-Air-(OTA-)Updates mit automatischem Rollback. GNSS mit schnellem First-Fix und inertialem Dead-Reckoning. Ein CI-bereiter ECU-Simulator, damit Diagnose-Regression ohne Bench-Hardware läuft.
Was das Engineering-Team schreibt.
Die Fahrzeug-Anwendung und die Cloud-Policy. Protokoll-Stacks, OTA-Pipeline, Modem-Steuerung und GNSS-Multiplexing sind bereits ausgeliefert. Parameter-ID-Änderungen sind Datendatei-Edits — kein Firmware-Rebuild.
Relevanteste Fähigkeiten
Was out of the box ausgeliefert wird.
— 01
16 Fahrzeugprotokolle aus einer Runtime
CAN, CAN-FD, ISO-TP, DoIP, J1939, J1587/J1708, J1850 VPW/PWM, TP 2.0, GMLAN, CANopen, Modbus und K-Line teilen sich eine einheitliche Protokoll-API. 22 Produktions-Stacks werden bei jedem CI-Push validiert ausgeliefert.
— 02
Fehlercode-Lesen und Dealer-Tool-Passthrough
Diagnostic-Trouble-Code-(DTC-)Lesen und -Löschen über den unterstützten Stack — OBD-II (On-Board Diagnostics) Service 03, UDS-Fehlertabellen (Unified Diagnostic Services), J1939-SPN-Fehlercodes. J2534-2-Passthrough erlaubt bestehenden Dealer-Scan-Tools den Zugriff auf den Fahrzeugbus über dasselbe Gateway, das auch die kontinuierliche Telematik abwickelt.
— 03
Over-the-Air-Updates mit automatischem Rollback
Delta-Updates mit signierten Paketen und automatischem Rollback. Dual-Slot-(A/B-)Root-Dateisystem; bootet der neue Slot nicht, fällt der Bootloader automatisch zurück. Cohort- und Canary-Over-the-Air-(OTA-)Update-Steuerung über den Munic-Cloud-Companion. Keine Bediener-Aktion bei Fehlschlag.
Protokoll-Abdeckung
16 Protokolle aus einer Runtime.
Alle Protokolle teilen sich eine service obdstacks-v2 -Runtime.
Stack-Definitionen sind Datendateien — Protokolländerungen erfordern keinen Firmware-Rebuild.
Ein Streaming-Service erlaubt jedem Container oder Cloud-Subscriber, rohe CAN-Frames neben dem
J2534-Passthrough auf derselben Schnittstelle zu empfangen.
| Protokoll | Transport | Hinweise |
|---|---|---|
| CAN Classical / CAN-FD | ISO 11898 | Roh-Frame-Streaming; J2534-Passthrough |
| ISO-TP / DoIP | CAN / Ethernet | UDS-Sessions (Unified Diagnostic Services) |
| J1939 | CAN | PGN/SPN-Adressierung, FMS |
| J1587 / J1708 | SAE J1708 seriell | Legacy Heavy-Duty |
| J1850 VPW / PWM | SAE J1850 | Legacy OBD-II |
| TP 2.0 / GMLAN | CAN | VAG- / GM-Varianten |
| CANopen | CAN | Industrielle Knotenprofile |
| Modbus | RS-485 / TCP | Hilfssubsysteme |
| K-Line | ISO 9141-2 | Legacy OBD-II |
Bringen Sie Ihre Fahrzeugarchitektur-Skizze mit.
Plattform-Metriken
Zentrale Kennzahlen.
Cloud-Egress
Fahrzeugdaten in die Cloud.
Telemetrie, Fehlercode-Ereignisse und OTA-Status erreichen die Flotten-Cloud über einen einzigen gesicherten Kanal — denselben Kanal, den jeder Micro Service nutzt. Kein Pro-micro service-Cloud-Connector; die Cloud-Policy ist eine Datendatei-Konfiguration, kein Anwendungscode.
Canary- und Cohort-Over-the-Air-Update-Steuerung läuft im Munic-Cloud-Companion. Das Fahrzeug meldet Boot-Slot-Gesundheit und Service-Bereitschaft automatisch; kein Bediener-Polling erforderlich.
Referenzarchitektur
Ein Fahrzeugprogramm auf MOS4.
Anker-Proof
Produktions-Deployments.
Ein führender Performance-Fahrzeug-OEM liefert seine Flotte auf MOS4 aus.
Multi-Plattform-Deployment. Telemetrie nach MD21; Remote-Diagnose in die Engineering-Pipeline.
Ein EV-Hersteller liefert Spezialplattformen auf MOS4 aus.
Sub-Plattform-Varianten aus demselben Image. Pro-Produkt-Siliziumklasse; gemeinsames OTA; eine Flottenkonsole.
Wer kauft MOS4 fürs Auto
Käufer-Archetypen jenseits der OEMs.
Connected-Car-Telematik ist längst kein OEM-only-Markt mehr. MOS4 wird von angrenzenden Käufern eingesetzt, die dieselbe Plattform brauchen, ohne sie neu zu bauen.
Connected-Car-Versicherung
Pay-as-you-drive (PAYD), Pay-how-you-drive (PHYD) und Schaden-Telematik.
Versicherer und InsurTech-Carrier setzen MOS4 in OEM- oder Aftermarket-Boxen ein, um Fahrverhalten zu bewerten, Crash-Signaturen zu erkennen und pro Kilometer abzurechnen. Die Plattform liefert signierte Kilometer- und Ereignis-Payloads, eine manipulationssichere Uhr und einen OTA-Pfad, der einen versicherten Fahrer überdauert. Beispiele für Käufer-Archetypen: Usage-Based-Kfz-Versicherer, PHYD-fokussierte InsurTech, Spezialisten für Schadensrekonstruktion, Flottenversicherer.
Telco + Car-Data-Verticals
Connected-Car-Services im Bundle mit dem Mobilfunkvertrag.
Carrier und MVNOs vertreiben MOS4-Boxen zusammen mit einem SIM- oder eSIM-Tarif — Fahrer-Alerts, Familiensicherheit, Diebstahlortung, Kilometer- und Fahrhistorie, WiFi-Access-Point im Fahrzeug. Dual APN, eUICC-Consumer-Profile und On-Device-LTE/5G lassen denselben SKU ohne Board-Respin über Märkte hinweg laufen. Beispiele für Käufer-Archetypen: Tier-1-Mobilfunkbetreiber, regionale MVNOs, Fixed-Mobile-Bundler.
Sensor-micro services
IMU und lokaler URL-Server — bereits integriert.
Zwei Micro Services, die Fahrzeugprogramme konstant benötigen, sind in der Plattform enthalten.
mos-imu · Inertial-Messeinheit-Service
Streamt Beschleunigungssensor- und Gyroskopdaten an andere Services. Wird vom inertialen GNSS-Dead-Reckoning und von Edge-KI-Pipelines verwendet, die Bewegungskontext neben Kamera-Frames benötigen. Keine Polling-Schleife im Anwendungscode.
mos-url-server · Lokaler HTTP-Server
Eingebetteter HTTP-Server für lokale Web-UIs und Diagnose-Dashboards. Exponiert Fahrzeugstatus, Fehlercode-(DTC-)Zusammenfassungen und OTA-Status über HTTP auf localhost — erreichbar von einem verbundenen Service-Tool oder einem In-Dash-Browser ohne Cloud-Roundtrip. Die Konfiguration ist eine Datendatei, kein Anwendungscode.
FAQ
Häufig gestellte Fragen
-
Welche Fahrzeugprotokolle deckt MOS4 ab?
16 Protokolle — CAN, CAN-FD, ISO-TP, DoIP, K-Line, J1939, J1587/J1708, J1850 VPW/PWM, TP 2.0, GMLAN, CANopen und Modbus — teilen sich eine einheitliche Protokoll-API. Stack-Definitionen sind Datendateien; das Hinzufügen oder Ändern einer Parameter-ID erfordert keinen Firmware-Rebuild.
-
Wie funktioniert das Fehlercode-Lesen?
Diagnostic-Trouble-Code-(DTC-)Lesen und -Löschen ist über den unterstützten Stack verfügbar: OBD-II (On-Board Diagnostics) Service 03, UDS-Fehlertabellen (Unified Diagnostic Services) und J1939-SPN-Fehlercodes. Dies ist dieselbe Schnittstelle, die Fahrzeug-Tier-Produkte nutzen.
-
Was ist J2534-2-Passthrough?
J2534-2 ist ein SAE-Standard, der bestehenden OEM-Diagnose-Anwendungen — Scan-Tools, ECU-Programmierer — den Zugriff auf den Fahrzeugbus über dasselbe Gateway erlaubt, das auch die kontinuierliche Telematik abwickelt, ohne dedizierten Hardware-Dongle.
-
Wie funktioniert das Rollback eines Over-the-Air-Updates?
Dual-Slot-(A/B-)Root-Dateisystem mit automatischem Rollback. Bootet der neue Slot nicht, fällt der Bootloader automatisch zurück. Retry- und Reboot-Limits werden über Power-Cycles hinweg persistiert.
-
Ist MOS4 ASIL-zertifiziert?
Heute nicht ASIL-zertifiziert. MOS4 ist an den ISO-26262-Prozess ausgerichtet, wo das Kundenprogramm es erfordert.
-
Wie laufen Diagnose-Regressionstests ohne Bench-Hardware?
Ein gebündelter ECU-Simulator deckt UDS, OBD-II, ISO-TP, DoIP und J1939 über virtuelles CAN ab. Mehr als 20 reale Fahrzeug-Fixture-Profile und deklarative Test-Szenarien laufen in CI ohne Bench-ECU und ohne Pro-Sitz-Tool-Lizenz.
-
Welche Silizium-Tiers sind verfügbar?
MOS4 läuft auf modem-Klasse bis KI-Klasse Silizium. SKUs und Datenblätter siehe munic.io.
Bringen Sie das Fahrzeugprogramm mit.
Ein Discovery-Gespräch mit Engineering. Bringen Sie die Fahrzeugarchitektur-Skizze und die bereits feststehenden Constraints mit.