Solutions · Automotive
Ship a connected-vehicle programme.
A distributed component OS for connected-vehicle OEM programmes — 10k to 300k units. Ships the 16-protocol vehicle stack via obdstacks-v2, A/B OTA, GNSS with ESF dead reckoning, and the CRA-ready compliance pack on day one. The engineering team writes the vehicle application and cloud policy — not the OS.
What ships on day one.
16 vehicle protocols from one runtime. Fault-code (DTC) reading and clearing. J2534-2 passthrough for existing dealer tooling. Over-the-air (OTA) updates with automatic rollback. GNSS with fast first-fix and inertial dead reckoning. A CI-ready ECU simulator so diagnostic regression runs without bench hardware.
What the engineering team writes.
The vehicle application and cloud policy. Protocol stacks, OTA pipeline, modem control, and GNSS multiplexing are already shipped. Parameter-ID changes are data-file edits — no firmware rebuild.
Capabilities most relevant
What ships out of the box.
— 01
16 vehicle protocols from one runtime
CAN, CAN-FD, ISO-TP, DoIP, J1939, J1587/J1708, J1850 VPW/PWM, TP 2.0, GMLAN, CANopen, Modbus, and K-Line share one unified protocol API. 22 production stacks ship validated on every CI push.
— 02
Fault-code reading and dealer-tool passthrough
Diagnostic trouble code (DTC) reading and clearing across the supported stack — OBD-II (On-Board Diagnostics) service 03, UDS (Unified Diagnostic Services) fault tables, J1939 SPN fault codes. J2534-2 passthrough lets existing dealer scan tools reach the vehicle bus through the same gateway handling continuous telematics.
— 03
Over-the-air updates with automatic rollback
Delta updates with signed packages and automatic rollback. Dual-slot (A/B) root filesystem; if the new slot fails to boot, the bootloader falls back automatically. Cohort and canary over-the-air (OTA) update management via the Munic cloud companion. No operator action on failure.
— 04
Secure short-range vehicle access over Bluetooth
The device acts as a Bluetooth Low Energy (BLE) peripheral — a phone or key fob locks, unlocks, and checks vehicle status with commands authenticated by signed tokens. A command wakes the device from low power, so access works even when the device is asleep and no network is in reach.
Protocol coverage
16 protocols from one runtime.
All protocols share one service obdstacks-v2 runtime. Stack definitions
are data files — protocol changes require no firmware rebuild. A streaming service lets any container
or cloud subscriber receive raw CAN frames alongside J2534 passthrough on the same interface.
| Protocol | Transport | Notes |
|---|---|---|
| CAN Classical / CAN-FD | ISO 11898 | Raw frame streaming; J2534 passthrough |
| ISO-TP / DoIP | CAN / Ethernet | UDS (Unified Diagnostic Services) sessions |
| J1939 | CAN | PGN/SPN addressing, FMS |
| J1587 / J1708 | SAE J1708 serial | Legacy heavy-duty |
| J1850 VPW / PWM | SAE J1850 | Legacy OBD-II |
| TP 2.0 / GMLAN | CAN | VAG / GM variants |
| CANopen | CAN | Industrial node profiles |
| Modbus | RS-485 / TCP | Auxiliary subsystems |
| K-Line | ISO 9141-2 | Legacy OBD-II |
Bring your vehicle architecture sketch.
Platform metrics
Key numbers.
Cloud egress
Vehicle data to cloud.
Telemetry, fault-code events, and OTA status travel to the fleet cloud over a single secured channel — the same channel every micro service uses. No per-micro service cloud connector; the cloud policy is a data-file configuration, not application code.
Canary and cohort over-the-air update management sits in the Munic cloud companion. The vehicle reports boot-slot health and service readiness automatically; no operator polling required.
Reference architecture
A vehicle programme on MOS4.
Anchor proof
Production deployments.
A leading performance-vehicle OEM ships its fleet on MOS4.
Multi-platform deployment. Telemetry into MD21; remote diagnostics into the engineering pipeline.
An EV maker ships specialty platforms on MOS4.
Sub-platform variants from the same image. Per-product silicon class; shared OTA; single fleet console.
Who buys MOS4 for cars
Buyer archetypes beyond OEMs.
Connected-car telematics is no longer an OEM-only market. MOS4 is shipped by adjacent buyers who need the same platform without rebuilding it.
Connected-car insurance
Pay-as-you-drive (PAYD), pay-how-you-drive (PHYD), and claims telematics.
Insurers and InsurTech carriers ship MOS4 in OEM-line or aftermarket boxes to score driving behaviour, detect crash signatures, and price per kilometre. The platform delivers signed mileage and event payloads, a tamper-evident clock, and an OTA path that survives an insured driver. Examples of buyer archetypes: usage-based motor insurers, PHYD-focused InsurTech, claims-reconstruction specialists, fleet-insurance carriers.
Telco + car-data verticals
Connected-car services bundled with the cellular subscription.
Carriers and MVNOs distribute MOS4-powered boxes alongside a SIM or eSIM plan — driver alerts, family safety, theft recovery, mileage and trip history, in-car WiFi access point. Dual APN, eUICC Consumer profiles, and on-device LTE/5G let the same SKU travel across markets without a board re-spin. Examples of buyer archetypes: Tier-1 mobile carriers, regional MVNOs, fixed-mobile bundlers.
Sensor micro services
IMU and local URL server — built in.
Two micro services that vehicle programmes consistently need ship in the platform.
mos-imu · Inertial measurement unit service
Streams accelerometer and gyroscope data to other services. Used by GNSS inertial dead-reckoning and by edge-AI pipelines that require motion context alongside camera frames. No polling loop in application code.
mos-url-server · Local HTTP server
Embedded HTTP server for local web UIs and diagnostic dashboards. Exposes vehicle state, fault-code (DTC) summaries, and OTA status over HTTP on localhost — reachable by a connected service tool or an in-dash browser without a cloud round-trip. Configuration is a data-file, not application code.
FAQ
Frequently asked questions
-
What vehicle protocols does MOS4 cover?
16 protocols — CAN, CAN-FD, ISO-TP, DoIP, K-Line, J1939, J1587/J1708, J1850 VPW/PWM, TP 2.0, GMLAN, CANopen, and Modbus — share one unified protocol API. Stack definitions are data files; adding or changing a parameter ID requires no firmware rebuild.
-
How does fault-code reading work?
Diagnostic trouble code (DTC) reading and clearing is available across the supported stack: OBD-II (On-Board Diagnostics) service 03, UDS (Unified Diagnostic Services) fault tables, and J1939 SPN fault codes. This is the same interface used by vehicle-tier products.
-
What is J2534-2 passthrough?
J2534-2 is a SAE standard that lets existing OEM diagnostic applications — scan tools, ECU programmers — reach the vehicle bus through the same gateway handling continuous telematics, without a dedicated hardware dongle.
-
How does over-the-air update rollback work?
Dual-slot (A/B) root filesystem with automatic rollback. If the new slot fails to boot, the bootloader falls back automatically. Retry and reboot limits are persisted across power cycles.
-
Is MOS4 ASIL-certified?
Not ASIL-certified today. MOS4 is aligned to ISO 26262 process where the customer programme requires it.
-
How do I run diagnostic regression without bench hardware?
A bundled ECU simulator covers UDS, OBD-II, ISO-TP, DoIP, and J1939 over virtual CAN. 20+ real-vehicle fixture profiles and declarative test scenarios run in CI without a bench ECU or per-seat tool licence.
-
What silicon tiers are available?
MOS4 runs on modem-class through AI-class silicon. See munic.io for hardware SKUs and datasheets.
Bring the vehicle programme.
A discovery call with engineering. Bring the vehicle architecture sketch and the constraints already locked in.