Industrial Linux OS · platform lineage at 4M+ units
The AI-native OS for connected vehicles, machines, and devices. Field-proven. Fully programmable.
MOS4 ships full-stack telematics, edge-AI vision, remote diagnostic, and a programmable runtime — on one Linux OS that scales modem-class to AI-class hardware. The Munic platform line behind it has been production-deployed since 2012 and now ships across 4M+ units in the field. MOS4 is the next-generation OS on that lineage.
Metrics tagged "modem-class reference profile" measured on a representative modem-class production device. Steady-state RSS (Resident Set Size) at idle; boot-ready time is time from kernel handoff to first supervised micro service responding to a service call. Container budget is the runtime overhead per micro service per the SDK reference profile.
MOS4 runs across three hardware tiers — modem-class (low-power connected units), compute-class (higher-throughput edge gateways), and AI-class (on-device NPU inference, up to ~100 TOPS) — all on one OS build, no per-tier branch.
Hardware tiers →Six capabilities · one OS
What ships in the box.
Industrial Linux OS · full-stack telematics · edge-AI ready · remote diagnostic built in · fully programmable in any language · on a platform lineage field-proven across 4M+ units. Pick the capability to verify next.
An industrial Linux OS. Secure by build. Safe by supervision.
Signed boot, signed A/B OTA with auto-rollback, TEE-backed key store, CycloneDX SBOM and CVE gate on every commit. Per-service watchdogs and resource contracts. CRA-ready.
One curated OS image across three hardware tiers — production-grade alternative to Yocto, AGL, raw Linux, or hobby ROS2. Security and functional safety are not bolt-ons: Secure Boot chain anchors the root of trust; attest-and-revert OTA removes the field-broken-image class; CVE blocking and licence gating run on every commit across every micro service. On the safety side — supervised cgroup limits, deterministic startup order, anomaly detection over OpenTelemetry. CRA Article-by-Article mapping ships in the compliance pack.
Full-stack connected-vehicle telematics.
Autonomous communications engine. Dual APN. eUICC Consumer + eUICC M2M. WiFi AP. 2G → 5G + LPWA.
UDS, J1939, ISOBUS, OBD-II, Modbus, CAN-FD — twenty-two production stacks. ELD-ready. The cellular layer hot-swaps modem vendor libraries at runtime — supporting a new modem is a configuration change, not a rebuild. See the production telematics frontend on top of MOS4: ekkofleet.com.
Edge-AI ready — declare it in TOML.
Camera, GPU, and NPU share memory. No CPU pixel copies. Up to ~100 TOPS.
Declare the pipeline in TOML; ship an ONNX or TFLite model. Munic retrains, quantises, validates, and OTAs the unified model. Full DMS + ADAS workload (5 models) plus H.265 encode on a 10-TOPS-class device.
Most platforms read the vehicle. MOS4 reads it and talks back.
A cloud-side bot drives the bus live. Read · Reset · Reconfigure · Reflash.
Same engine as autonomous telematics — different mode of operation. Signed TLS tunnel, per-action authorisation, attest-and-revert reflash. For the subset of field failures that do not need a wrench, a truck roll becomes a packet.
Fully programmable — any language.
Configuration. No-code engines. Full SDK in Python, Rust, C, C++, Go.
Three programming surfaces, chosen per feature. Configuration (TOML) for product managers. No-code engines (signal processing, state-machine policies, vehicle comms, edge AI) for embedded engineers. Full SDK where it matters. The only industrialised ROS2-class host that ships on modem-class hardware — ROS2 nodes ride along via the sidecar pattern. Mix surfaces in the same fleet.
On a platform lineage field-proven across 4M+ units.
MOS4 is the next-generation OS on the Munic platform line. The lineage carries deployments from 2012 to today — passenger cars, fleets, airport ops, agriculture, industrial automation.
The Munic platform line ships on 4M+ units across a North-American connected-car insurance carrier (since 2012), an MVNO telematics programme (since 2020), a 21M-member European motorist association (since 2022), multiple European OEM fleet programmes under NDA, and specialty OEMs in performance vehicles, airport ground handling, off-highway, and industrial automation. MOS4 inherits the protocols, the partners, and the field-tested architecture — and adds the supervised micro services model, A/B OTA, and CRA-grade compliance pack. State-of-the-art telematics frontend on top: ekkofleet.com.
Products on MOS4
Five product categories. One OS.
The OS underneath the box you ship. Five product categories — the names buyers search for. The vertical pages below map each product to its industry context.
Autonomous Vehicle
Tractor · airport tug · mower · haul truck. On private premises.
Explore →AI Camera
OEM cam · dashcam · multi-cam fleet.
Explore →Connected Vehicle
Telemetry-first. MD21 uplink. Fleet-ready.
Explore →Voice Kiosk
On-device LLM. Refuse-preferred. Audit-logged.
Explore →Remote-Care fleet
When the box stalls, you send a packet — not a truck.
Explore →Three programming tiers
Match the team you have.
MOS4 is structured around three programming surfaces. Pick the tier per product, per feature, per engineer — and mix them in the same fleet.
Config
Toggle features, set thresholds, ship variants in declarative TOML, validated at build time.
Read more →No-code
MSP signal graphs. MEP state-machine policies. Multi Stacks vehicle and IoT comms. AI Funnel declarative edge AI.
Read more →Full code
Drop in existing application code — inside the lightweight container engine with enforced resource isolation.
A single MQTT client drives all four no-code engines — MSP, MEP, Multi Stacks, and AI Funnel — from one process. No Rust toolchain, no per-engine SDK, no custom glue.
See the four-engine MQTT examples →The pipeline
Four engines · one platform.
Every MOS4 product runs the same four-engine pipeline: bus and IoT decode, signal processing, state-machine policy, and declarative edge AI — then branches to the on-device runtime and the Munic cloud in the same OTA cycle.
Four-engine pipeline. Vehicle bus and industrial-IoT inputs (CAN, CAN-FD, J1939, Modbus) feed Multi Stacks; sensor inputs (camera, IMU, GNSS) feed MSP signal-processing graphs. Multi Stacks decoded signals also feed MSP. MSP outputs feed MEP, the state-machine policy engine (T·C·A primitives under the hood). MEP outputs feed AI Funnel, the declarative edge-AI engine. AI Funnel branches to two destinations in the same OTA cycle: an on-device NPU/GPU/CPU runtime, and the Munic cloud for retraining and OTA delivery.
flowchart LR Bus[CAN · CAN-FD · J1939 · Modbus] --> MS[Multi Stacks] Sensors[Camera · IMU · GNSS] --> MSP[MSP graphs] MS --> MSP MSP --> MEP[MEP — state-machine policy] MEP --> AI[AI Funnel] AI --> RT[On-device NPU / GPU / CPU runtime] AI --> Cloud[Munic cloud — OTA + retrain] class AI ai-node class RT ai-node
Before / after — same OS, generation jump.
| metric | Previous generation | MOS4 (modem-class reference) |
|---|---|---|
| boot-ready time | ~90 s | 1.6 s |
| steady-state memory (RSS) | ~60 MB | 28.4 MB |
| minimal micro service — user-written Rust | n/a | < 30 lines |
AI Funnel
Declare your AI. Munic deploys it.
Customers ship a TOML graph plus an ONNX/TFLite model and a COCO dataset. Camera, GPU, and NPU share memory directly — the CPU never copies pixel data. Run multiple concurrent models with H.265 encode on a 10-TOPS-class device.
Customer provides
A TOML graph, ONNX/TFLite models, a COCO dataset, and an optional business-logic container.
Munic cloud does
Retrain, quantise, validate, benchmark, package, and OTA the unified triage model.
On-device runtime
GPU crop and resize, NPU inference, shared memory end-to-end. No pixel bytes traverse the CPU.
Remote Diagnostic
A truck roll becomes a packet.
The cloud opens a signed session, drives the bus, completes the action, closes. For the subset of field failures that do not need a workshop. Same UDS / J1939 / ISOBUS / Modbus / J2534-passthru engine as autonomous telematics — different mode of operation.
OEM · warranty
ECU reset over the air
Reset a stalled ECU (Electronic Control Unit) from the cloud. Driver continues. No tow truck, no dealer visit.
EV maker
Live-monitor certification
Read live cell telemetry through a charge / discharge cycle. Certificate from the same audit log.
Roadside service
Drive-or-tow triage
Read ECU state. Decide whether the vehicle can reach the next garage or needs a tow.
Fleet inspector
Inspector mutualisation
Errand operators connect on-vehicle; one technician inspects many vehicles from an office.
Out of the box
What you do not have to build.
The expensive twelve months of any embedded programme — cellular, GNSS, vehicle bus, vision, OTA, fleet telemetry — already shipped, supervised, and CRA-grade. Each tile links the components in that category.
Cloud egress
GraphQL mesh as the customer entry point.
The end-to-end cloud path: micro service in container → MQTT bridge → communication gateway → cloud-connect → cloud micro service → GraphQL mesh → customer application.
Cloud egress topology — micro service to GraphQL mesh
flowchart LR
A[Micro service in container] --> B[MQTT bridge]
B --> C[Communication gateway]
C --> D[cloud-connect]
D --> E[cloud micro service]
E --> F[GraphQL mesh]
F --> G[Customer app] Public GraphQL gateway reference: gateway.munic.io/services/graphql_gateway/docs/
Container runtime
Hot-swap. No reboot.
Drop in your node. Replace a micro service without rebooting the device. Process-isolated containers with enforced resource limits. First-class SDKs in Python, Rust, C, C++, Go. Any language that speaks MQTT rides along.
Process-isolated containers
Resource limits as a contract, not best-effort. crun production runtime over cgroups v2.
Bring your own node
Existing Python · Rust · C · C++ · Go nodes drop in unmodified. No code changes to ride the typed bus.
Any MQTT-speaking language
Above the SDK layer, any client publishes and subscribes — language-neutral.
ROS2 runtime alternative
A first-class ROS2 sidecar gateway bridges DDS graphs into MOS4. Existing ROS2 nodes ride along — the only industrialised ROS2-class host on modem-class hardware.
SDLC · CI · compliance
Typed service contracts. SBOM on every release.
Every micro service publishes its contract. Every release ships a CycloneDX SBOM, a CVE scan, signed binaries, and an OpenTelemetry surface. CRA-ready — Article-by-Article mapping in the compliance pack.
The day-2 layer is in the box.
Observability, safety, OTA, remote control, lifecycle. Five capabilities, one platform, every device.
Solutions
One OS, six buyer profiles.
Pick the vertical closest to your product. Each page covers the capabilities most relevant to that buyer — and names the products you can ship on MOS4 for it.
Automotive
EV makers, performance OEMs, specialty platforms.
Products: Connected Vehicle · AI Dashcam
Explore →Machinery
Off-highway, ISOBUS, agriculture.
Products: Off-highway machine ECU · Operator-vision AI Cam
Explore →Autonomous Vehicles
Tractor, airport tug, mower, haul truck. Private premises only.
Products: Autonomous Tractor · Tug · Mower · Haul Truck box
Explore →Trucks & LCV
Telematics, OBD heavy duty, fleet.
Products: Fleet Dashcam · Telematics box
Explore →IoT Gateway
Industrial automation, autonomous arms and mowers.
Products: Industrial Gateway · Sensor Hub
Explore →AI Cameras
OEM cam, dashcam, multi-camera fleet network.
Products: AI Cam · Dashcam · Multi-cam Fleet
Explore →CRA-ready. Day one. Every release.
Article-by-article CRA mapping, SBOM, security pipeline, PSIRT process.
Build on MOS4.
Start with the service catalog — declare the capabilities you need, sized by silicon tier. Engineering is one click away when you need a fit conversation.