Comparativa

MOS4 vs Zephyr

El eje de la comparación es la clase de silicio, no el conteo de funciones. Zephyr es un kernel en tiempo real clase MCU. MOS4 es un runtime de aplicación para Linux embebido. Donde termina Zephyr, empieza MOS4.

Dos barras horizontales apiladas: barra inferior MCU/Zephyr, barra superior Linux/MOS4 — un pulso ámbar cruza la frontera

Clase de silicio

Dominios distintos, silicio distinto.

Zephyr proporciona la capa RTOS para MCU con tareas, IPC, drivers y un scheduler en tiempo real. MOS4 proporciona la capa de runtime de aplicación sobre el kernel Linux en un SoC clase Linux. Los dos pueden coexistir como coprocesador y core de aplicación, conectados vía IPC SubscribeCanFrames.

flowchart TB
  subgraph MOS4["MOS4 — runtime de aplicación (SoC clase Linux)"]
    M1[Supervisor de componentes · EventBus · OTA]
    M2[obdstacks-v2 · GNSS · módem · inferencia IA]
    M3[Observabilidad · mos-update · contenedores]
  end
  subgraph Linux["Kernel Linux + userland"]
  end
  subgraph Zephyr["Zephyr — RTOS para MCU"]
    Z1[Tareas · IPC · drivers · scheduler tiempo real]
  end
  MOS4 --> Linux
  Zephyr -."IPC coprocesador (SubscribeCanFrames)".-> MOS4

Modelo de coexistencia: Zephyr sobre el coprocesador MCU gestiona el trabajo determinista en tiempo real (servicio de interrupción CAN sub-milisegundo); MOS4 sobre el core Linux de aplicación recibe tramas decodificadas vía el servicio de streaming SubscribeCanFrames por el enlace interprocesador y gestiona los servicios, OTA de flota y observabilidad.

Cara a cara

Comparación de capacidades.

Clase de silicio Zephyr Clase MCU: núcleos de microcontrolador de 32 bits, RISC-V y otros objetivos bare-metal. Latencia ISR sub-milisegundo. MOS4 Procesador de aplicación clase Linux (clase módem a clase IA). Suelo mínimo de trabajo: procesador de aplicación monocore a 800 MHz o superior, 256 MB de RAM.
Sistema operativo Zephyr Kernel RTOS: scheduler en tiempo real, threading cooperativo y apropiativo, latencia de interrupción determinista. MOS4 Runtime de aplicación clase Linux sobre la frontera kernel/userspace. No es un kernel; depende del kernel Linux proporcionado por la imagen.
Lenguajes Zephyr C, C++, Rust limitado vía los bindings Rust de Zephyr. MOS4 Micro servicios Rust nativos. Los contenedores OCI alojan Python, Rust, Go, C, C++ y nodos ROS2.
Supervisor de aplicación Zephyr Scheduler de tareas del kernel. Sin supervisor de micro services a nivel de aplicación. MOS4 MOS4: arranque ordenado por dependencias, on_start/on_stop/hot-swap, watchdog por componente, EventBus entre procesos.
Protocolos vehiculares Zephyr BSPs por placa. API de driver CAN disponible. Las pilas de protocolo a nivel de aplicación requieren bibliotecas de terceros o implementación a medida. MOS4 obdstacks-v2: 16 protocolos (CAN, CAN-FD, DoIP, UDS, J1939, ISOBUS y más) en un único runtime vía archivos JSON declarativos de pila.
OTA de flota Zephyr MCUmgr o SUIT para actualizaciones de firmware MCU. Sin servicio OTA de flota. MOS4 mos-update: paquetes delta firmados con Ed25519, particiones A/B, rollback automático vía bootcount, OTA por cohorte y canario vía el complemento cloud de Munic.
Observabilidad Zephyr Subsistema de logging. Sin pila de observabilidad a nivel de flota. MOS4 Métricas Prometheus por componente, exportación OTLP de OpenTelemetry, batching estructurado de errores con mos-sentry. Pila Grafana/OTLP operada por el cliente.
Procesamiento de señal Zephyr Filtrado a nivel ISR en C. Implementación por proyecto. MOS4 MSP: motor de grafos de dataflow configurado en YAML, 226 grafos cubriendo 21 dominios vehiculares. Validación off-device con la CLI msp-run y entradas CSV. Sin recompilación Rust para nueva cobertura de dominio.

Fuente — Zephyr desde zephyrproject.org ; MOS4 desde /es/architecture.

Nota: las cifras de huella en RAM y flash no se comparan más arriba. Zephyr y MOS4 corren en clases de silicio distintas con primitivas de OS distintas. Comparar huellas sería el eje equivocado.

FAQ

Las preguntas que más oímos.

  • ¿Puedo ejecutar Zephyr junto a MOS4?

    Sí — muchos despliegues usan Zephyr en un coprocesador (una MCU que gestiona interrupciones CAN deterministas en tiempo real) y MOS4 en el core de aplicación. Zephyr asume la tarea a nivel de kernel; MOS4 gestiona los servicios, OTA e integración de flota por encima de la frontera kernel/userspace de Linux.

  • ¿Requiere MOS4 Linux?

    Sí. MOS4 es un runtime de aplicación clase Linux. El objetivo mínimo es un procesador de aplicación clase módem ejecutando un kernel Linux. Para programas solo MCU, Zephyr o FreeRTOS son la elección correcta.

  • ¿Cómo difiere el nivel de silicio?

    Zephyr apunta a piezas clase MCU (núcleos de microcontrolador de 32 bits, RISC-V y equivalentes). MOS4 arranca en procesadores de aplicación clase módem capaces de Linux y escala hasta hardware clase IA. Son clases de hardware distintas con primitivas de OS distintas — huellas no comparables.

  • ¿Dónde termina Zephyr y empieza MOS4?

    En la frontera kernel/userspace de un SoC clase Linux. Zephyr no proporciona supervisor de micro services, OTA de flota, pila de observabilidad ni pilas de protocolo vehicular a nivel de aplicación — esas son primitivas de MOS4.

  • ¿Cuáles son las cifras de MOS4 en silicio clase módem?

    28,4 MB de RSS en estado estacionario, 1,6 s hasta primera aplicación lista, 200 ms de arranque en frío de componente en el perfil de referencia clase módem. Son cifras absolutas para esa clase de hardware — no una comparación con Zephyr, que corre en una clase de OS distinta.

  • ¿Cuándo sigue siendo Zephyr la elección correcta?

    Para núcleos de microcontrolador de 32 bits, MCUs RISC-V o cualquier objetivo bare-metal o RTOS. Siempre que la latencia ISR determinista sub-milisegundo sea la restricción principal y un kernel Linux no esté disponible ni sea necesario, Zephyr es la respuesta correcta.

Decida primero la clase de silicio.

Una llamada de 30 minutos con ingeniería. Dimensionaremos el SoC juntos — clase MCU, clase módem Linux, clase compute o clase IA.

¿Construyendo sobre MOS4?

Una respuesta del equipo de ingeniería, ~24 h. Sin presentación, sin NDA.

Hablar con ingeniería