— Why MOS4
One platform, six decisions you can forward.
MOS4 is a distributed embedded Linux OS for connected vehicles, machines, and IoT — chosen for programmes that need EU Cyber Resilience Act (CRA) compliance, secure boot and supervised runtime, AI-class silicon support, one OS across silicon tiers, and a six-language SDK. The page below splits the answers across the six decision areas — compliance, secure-and-safe, economics, narrative, engineering, uptime — so each section forwards to the colleague who owns it.
What a vendor-evaluation pack needs from the OS vendor.
The EU Cyber Resilience Act applies from 2027. MOS4 ships with a CycloneDX SBOM, a public PSIRT, and an article-by-article CRA mapping so legal and security teams can include the compliance pack in a vendor-evaluation packet.
CycloneDX SBOM on every release
Machine-readable bill of materials — downloadable from the customer portal for inclusion in procurement evidence packs. Generated automatically on every commit across 52 micro services.
PSIRT + coordinated disclosure
Public security@munic.io address, acknowledgement within 5 business days, tracked CVEs per release. Internal patch targets: 7 / 30 / 90 days by severity; contractual SLAs per programme.
Article-by-article CRA mapping
Annex I §1, §2, Art. 13, Art. 14 — each requirement mapped to the MOS4 artefact that satisfies it. The team that owns the compliance pack only documents the application layer.
Signed OTA + cohort management
Ed25519-signed delta packages, A/B partitions, automatic rollback via bootcount. Cohort and canary OTA via the Munic cloud companion.
OSS hygiene + LTS
Upstream open-source software is audited for contaminating licences (LGPLv3 and equivalents cleaned before integration). Vulnerability scanning and static analysis run on every commit to catch CVEs in open-source dependencies. A long-term-support commitment gives programmes a stable base over multi-year production runs.
Security and safety belong to the OS.
Compliance paperwork (#01) is downstream of the engineering posture. Security and functional safety are platform properties at MOS4: enforced in CI at build time, by the supervisor at start time, and by the resource contract at run time. The same controls run on every commit, every release, every micro service.
Secure Boot + TEE-anchored key store
Hardware-anchored root of trust. Signed boot chain on supported silicon. Keys stored in a Trusted Execution Environment — never exposed to the application layer.
Signed A/B OTA with automatic rollback
A/B partitions with cryptographically signed images. Failed update attest-and-reverts, eliminating the field-broken-image failure class. Anti-rollback enforced.
Supervised runtime with resource contracts
Each micro service runs in a container with cgroup CPU/memory/IO limits enforced at start time. Watchdog with automatic restart on missed heartbeats. A misbehaving service cannot starve the device.
Deterministic startup, typed contracts
Startup order derives from a declared dependency graph; the registry refuses a misordered graph at build time. Typed protobuf contracts catch interface drift at compile time — no race-condition class, no silent field break.
Observability for fleet-scale anomaly detection
Traces, metrics, and structured logs from every service on a unified OpenTelemetry surface. Restart counts, exit codes, latency, and CVE advisories surface in your dashboard before they spread.
One OS across the silicon ladder.
MOS4 runs from modem-class chips up to AI-class silicon on a single OS. Munic ports the OS; the programme picks the silicon tier per product. No in-house board-support team required. Documented migration paths from RTOS, hobby Linux, Android Automotive, and ROS2 on full Linux.
Silicon-tier ladder. The same MOS4 OS spans three classes of silicon. Modem-class — under 5% overhead, 28.4 MB steady-state RSS, 1.6 s first-app-ready boot. Compute-class — multi-camera capture, container isolation. AI-class — up to approximately 100 TOPS NPU on AI-class silicon, binary-compatible across the AI-class tier. Munic ports the OS across the family; the OEM picks the tier per product.
flowchart LR M[modem-class<br/>RSS 28.4 MB · boot 1.6 s<br/>under 5% overhead] C[compute-class<br/>multi-camera · containers] A[AI-class<br/>up to ~100 TOPS NPU] M --> C --> A M -. one OS .-> C C -. one OS .-> A class A ai-node
28.4 MB RSS · 1.6 s boot · <5% overhead
Modem-class silicon baseline. Steady-state RSS and first-app-ready boot on a representative modem-class production device. The same OS image scales to AI-class silicon without a separate branch.
No per-engineer toolchain licence
Multi Stacks + Remote Diagnostics replaces per-engineer workshop tooling with a per-device model, fleet-wide.
Migration matrix included
Documented paths from monolith RTOS, hobby Linux, Android Automotive, and ROS2 on full Linux — build tooling and per-target profiles cover the most common embedded targets.
Hardware flavors, code stays the same
The silicon range spans from a no-NPU, no-GPU modem-class baseline up to AI-class silicon (~100 TOPS). The same binary set runs across the family — no porting, no retraining, no revalidation cost moving up or down the silicon ladder. Production-cost ladder by volume: see munic.io for SKUs and tiers.
Shipping capabilities, not marketing claims.
The on-device AI pipeline is fully available. Camera, GPU, and NPU share memory directly — the CPU never copies pixel data. Run a full driver-monitoring (DMS) + advanced driver-assistance (ADAS) workload (5 models) plus H.265 encode on a 10-TOPS-class device. Configured in TOML; deployed via the same OTA channel as code.
Shared-memory camera-to-NPU pipeline
Camera, GPU, and NPU share memory directly — the CPU never copies pixel data. CPU schedules but never touches pixels. Configured in TOML; deployed via OTA.
Vision: multi-camera, GPU crop and resize, GDPR live anonymisation
Five camera inputs (MIPI-CSI, GMSL2, USB UVC, RTSP/ONVIF, WebRTC). GDPR live anonymisation (face and plate blur) is controlled by a boot-time policy toggle before any frame leaves the pipeline.
Reference deployments behind every claim
Performance vehicles, airport ground ops, agriculture, off-highway machinery. Customers are under NDA but the verticals, capabilities, and standards are not.
Single-vendor full AI stack — one SLA from camera to LLM to audit log
Vision AI and language AI run on the same device under one platform SLA. Camera-to-NPU inference, on-device LLM with retrieval-augmented generation (RAG) set to prefer on-device answers, and a per-answer audit manifest — all from one vendor, one OTA channel, one support contract.
Offline-first AI — RAG, LLM and voice run on-device by default; cloud is opt-in
The language platform runs entirely on-device by default. Cloud access requires explicit configuration at three independent gates. No connectivity dependency for core inference.
Python, Rust, C, C++, Go — all on the same platform.
Re-training is one of the larger hidden costs in an embedded programme. MOS4 keeps the languages the team already runs. MQTT, Prometheus, TOML, and typed schemas are first-class. ROS2 nodes run unmodified inside a managed container via the sidecar pattern.
Five languages, one container engine
Python, Rust, C, C++, and Go nodes run side-by-side under enforced resource limits. ROS2 nodes ride along via the sidecar pattern. Existing nodes drop in; new ones adopt typed interfaces. Automated guided vehicle (AGV) and robotics qualification requirements: talk to engineering.
No-code engines for domain-expert–authored logic
Signal Processing (MSP): 226 signal graphs across 21 vehicle domains, YAML-configured, no recompile per domain. Policy Engine (MEP): trigger–condition–action rules, hot-reloaded, parallel execution. Multi Stacks: vehicle and industrial-IoT communication across 16 protocol families, declared in configuration. AI Funnel: declarative edge AI — configure in TOML, deploy via OTA.
SDLC that fits an industrial programme
Unit tests, end-to-end integration, benchmarks, code-coverage measurement, dependency vulnerability scanning, static analysis, and SBOM generation — every commit, across every micro service.
Observable by design
Prometheus metrics, OpenTelemetry Protocol (OTLP) export, W3C Trace Context propagation, and structured logs — automatic for every registered service call. Same observability conventions the cloud team already operates.
Compare MOS4 against alternatives
Remote diagnostic, hot reconfiguration, signed remediation — in every device.
Uptime is not won on AI demos. It is won in the moments when something goes wrong. MOS4 ships the surface that converts a truck-roll into a packet: signed remote diagnostic, hot reconfiguration without OTA, A/B remediation with auto-rollback, and an MSP fault-detection layer that flags the failure before it stops the machine.
Diagnose remotely — no truck-roll for an actuator read-out
Full UDS, J1939, ISOBUS fault tree from the cloud. Live signal read-out via Multi Stacks. Live log retrieval by time range and keyword, streamed and compressed. No SSH, no SCP, no device-side tooling.
Reconfigure remotely — push a new graph, a new policy, a new map
Signal-processing graph swap, policy update, geofence remap, Multi Stacks scenario refresh — hot-reloaded without a full OTA. Around 10 seconds from edit to first successful service call. A/B file rotation persists the config across reboots; rollback to the prior config is one signed call.
Remediate remotely — signed A/B OTA, remote reboot, remote re-flash
Ed25519-signed delta packages, A/B partitions, automatic rollback if a new image fails to boot. Remote process restart and remote chip reboot via the watchdog supervisor. Remote re-flash with cryptographic attestation. Safety interlocks cannot be overridden from the remediation surface.
Predictive layer — catch the failure before it stops the machine
MSP signal graph runs telemetry through a fault-detection model on the device. Cloud aggregates fleet-wide signatures; AI Funnel retrains and OTAs the updated detection model. No firmware release, no fleet-wide flash window — every device gets the improved detector.
Signed-action gate + per-action audit log
Every remote action passes through a signed-action gate. Multi-party authorisation available for sensitive actions. Per-action audit log covering actor, action, target, timestamp, and result. Six-month rolling retention, suitable as evidence for CRA-aligned review.
Fit matrix
Vertical × capability.
Find your vertical, scan your column, self-qualify. Each cell summarises the capability for that vertical.
| Capability | Automotive | Machinery | Trucks & LCV | IoT Gateway | Video & Fleet AI |
|---|---|---|---|---|---|
| Multi Stacks · Remote Diagnostics | CAN, CAN-FD, DoIP | ISOBUS, J1939 | HD-OBD, J1708, J1587 | Modbus, RS485 | — |
| AI Funnel · declarative edge AI | OEM-specific models | Crop / asset detect | Driver scoring | Anomaly triage | Multi-camera retrain |
| Vision · region-of-interest crop · ADAS+DMS | DMS, blackbox | Operator alerts | Dashcam + DMS | — | GDPR live anon |
| CRA · SBOM · security pipeline | core | core | core | core | core |
| Hardware tier | compute · AI-class | compute-class | compute-class | modem · compute | AI-class |
| Languages: Python · Rust · C · C++ · Go | all five | C / C++ / Rust | C / C++ / Rust | Python / Rust | Python / C++ |
FAQ
Frequently asked questions
-
Who is the Why MOS4 page written for?
The page is organised by decision area — compliance, economics, narrative, engineering, uptime — so each section forwards to the colleague who owns it.
-
How does MOS4 address the EU Cyber Resilience Act?
The CRA applies from 2027. MOS4 ships a CycloneDX SBOM, a public PSIRT at security@munic.io, and an article-by-article CRA mapping covering Annex I §1, §2, Art. 13, and Art. 14.
-
What silicon classes does MOS4 run on?
One OS spans modem-class, compute-class, and AI-class silicon. The modem-class baseline is 28.4 MB steady-state RSS and 1.6 s first-app-ready boot, under 5% overhead. Munic ports the OS; the programme picks the tier per product.
-
Which programming languages run on MOS4?
Python, Rust, C, C++, and Go nodes run side-by-side under enforced container isolation. ROS2 nodes ride along via the sidecar pattern. Existing nodes drop in; new ones adopt typed interfaces.
-
How does MOS4 handle edge AI?
Camera, GPU, and NPU share memory directly — the CPU never copies pixel data. Run a full DMS + ADAS workload (5 models) plus H.265 encode on a 10-TOPS-class device with CPU headroom free for application code. See /platform/ai-vision for detail.
-
What programme sizes does MOS4 fit?
MOS4 targets small and mid-volume programmes — 10k–300k units — across automotive, machinery, trucks and LCV, IoT gateway, and video and fleet AI verticals.
-
How does cohort and canary OTA work?
A/B partitions, signed delta packages, and automatic rollback. Cohort and canary management ships server-side via the Munic cloud companion.
New to MOS4 terminology? The glossary covers managed containers, dma-buf, J1939, and more.
Forward this decision surface to the colleague who owns it.
One call, one artefact, every interface and contract on the table.