Compare
MOS4 vs Zephyr
The comparison axis is silicon class, not feature count. Zephyr is an MCU-class real-time kernel. MOS4 is an embedded-Linux application runtime. Where Zephyr ends, MOS4 begins.
Silicon class
Different domains, different silicon.
Zephyr provides the MCU RTOS layer with tasks, IPC, drivers, and a real-time scheduler. MOS4 provides the application runtime layer above the Linux kernel on a Linux-class SoC. The two can coexist as co-processor and application core, connected via SubscribeCanFrames IPC.
flowchart TB
subgraph MOS4["MOS4 — application runtime (Linux-class SoC)"]
M1[Component supervisor · EventBus · OTA]
M2[obdstacks-v2 · GNSS · modem · AI inference]
M3[Observability · mos-update · containers]
end
subgraph Linux["Linux kernel + userland"]
end
subgraph Zephyr["Zephyr — MCU RTOS"]
Z1[Tasks · IPC · drivers · real-time scheduler]
end
MOS4 --> Linux
Zephyr -."co-processor IPC (SubscribeCanFrames)".-> MOS4
Coexistence model: Zephyr on the MCU co-processor handles deterministic real-time work
(sub-millisecond CAN interrupt service); MOS4 on the Linux application core receives decoded
frames via SubscribeCanFrames streaming service over the inter-processor link and handles
services, fleet OTA, and observability.
Side-by-side
Capability comparison.
Source — Zephyr from zephyrproject.org ; MOS4 from /architecture.
Note: RAM and flash footprint figures are not compared above. Zephyr and MOS4 run on different silicon classes with different OS primitives. Comparing footprints would be the wrong axis.
FAQ
The questions we hear most.
-
Can I run Zephyr alongside MOS4?
Yes — many deployments use Zephyr on a co-processor (an MCU handling deterministic real-time CAN interrupts) and MOS4 on the application core. Zephyr handles kernel-level duty; MOS4 handles services, OTA, and fleet integration above the Linux kernel/userspace boundary.
-
Does MOS4 require Linux?
Yes. MOS4 is a Linux-class application runtime. The minimum target is a modem-class application processor running a Linux kernel. For MCU-only programmes, Zephyr or FreeRTOS is the correct choice.
-
How does the silicon tier differ?
Zephyr targets MCU-class parts (32-bit microcontroller cores, RISC-V, and equivalents). MOS4 starts at modem-class Linux-capable application processors and scales to AI-class hardware. These are different hardware classes with different OS primitives — not comparable footprints.
-
Where does Zephyr end and MOS4 begin?
At the kernel/userspace boundary on a Linux-class SoC. Zephyr does not provide a micro service supervisor, fleet OTA, observability stack, or vehicle protocol stacks at application level — those are MOS4 primitives.
-
What are the MOS4 figures on modem-class silicon?
28.4 MB steady-state RSS, 1.6 s first-app-ready, 200 ms component cold-start on the modem-class reference profile. These are absolute figures for that hardware class — not a comparison to Zephyr, which runs on a different OS class entirely.
-
When is Zephyr still the right choice?
For 32-bit microcontroller cores, RISC-V MCUs, or any bare-metal or RTOS target. Whenever deterministic sub-millisecond ISR latency is the primary constraint and a Linux kernel is not available or needed, Zephyr is the correct answer.
Decide the silicon class first.
A 30-minute call with engineering. We will size the SoC together — MCU class, modem-class Linux, compute, or AI.