OS Linux industrial · linaje de plataforma a 4M+ unidades

El OS nativo de IA para vehículos, máquinas y dispositivos conectados. Probado en campo. Totalmente programable.

MOS4 entrega telemática full-stack, visión por IA edge, diagnóstico remoto y un runtime programable — sobre un único OS Linux que escala desde hardware clase módem a clase IA. La línea de plataforma Munic que lo sostiene está en producción desde 2012 y hoy se despliega en 4M+ unidades en campo. MOS4 es el OS de próxima generación sobre ese linaje.

rss 28.4 mb
arranque 1.6 s
1 núcleo · 5% overhead
sbom: cyclonedx
cra: listo
28.4 MB memoria en estado estable (RSS) perfil de referencia clase módem — Resident Set Size en reposo
1.6 s tiempo de arranque listo perfil de referencia clase módem — tiempo hasta el primer micro service supervisado listo
<5% CPU / 10 MB presupuesto de contenedor sobrecarga del runtime por micro service — perfil de referencia del SDK
180 capacidades de plataforma superficies de servicio declaradas en el OS
hasta ~100 TOPS silicio clase IA hasta ~100 TOPS en el nivel clase IA

Las métricas etiquetadas como "perfil de referencia clase módem" se miden en un dispositivo representativo de producción clase módem. RSS en estado estable (Resident Set Size) en reposo; el tiempo de arranque listo es el tiempo desde la transferencia del kernel hasta que el primer micro service supervisado responde a una llamada de servicio. El presupuesto de contenedor es la sobrecarga del runtime por micro service según el perfil de referencia del SDK.

Niveles de silicio

MOS4 se ejecuta en tres niveles de hardware — clase módem (unidades conectadas de bajo consumo), clase compute (pasarelas edge de mayor rendimiento) y clase IA (inferencia NPU en dispositivo, hasta ~100 TOPS) — todo en un único build del OS, sin rama por nivel.

Niveles de hardware →

Seis capacidades · un OS

Lo que viene en la caja.

OS Linux industrial · telemática full-stack · IA edge lista · diagnóstico remoto integrado · totalmente programable en cualquier lenguaje · sobre un linaje de plataforma probado en campo en 4M+ unidades. Elija la capacidad que quiera verificar a continuación.

OS industrial — seguro por diseño 01 / 06

Un OS Linux industrial. Seguro por construcción. Safe por supervisión.

Arranque firmado, OTA A/B firmado con rollback automático, key store respaldado por TEE, SBOM CycloneDX y gate de CVE en cada commit. Watchdogs y contratos de recursos por servicio. CRA-ready.

Una sola imagen del OS curada para los tres niveles de hardware — alternativa de grado producción frente a Yocto, AGL, Linux crudo o ROS2 amateur. La seguridad y el safety funcional no son extras: la cadena Secure Boot ancla la raíz de confianza; el OTA con atestación y reversión elimina la clase de fallo «imagen rota en campo»; el bloqueo de CVE y el gating de licencias se ejecutan en cada commit, en cada micro service. En safety — límites cgroup supervisados, orden de arranque determinista, detección de anomalías sobre OpenTelemetry. El mapeo artículo por artículo del CRA viene en el pack de cumplimiento.

Seguridad + safety →
Telemática 02 / 06

Telemática de vehículo conectado full-stack.

Motor de comunicaciones autónomo. APN dual. eUICC Consumer + eUICC M2M. WiFi AP. 2G → 5G + LPWA.

UDS, J1939, ISOBUS, OBD-II, Modbus, CAN-FD — veintidós stacks en producción. ELD-ready. La capa celular intercambia en caliente las librerías de proveedor del módem en tiempo de ejecución — soportar un módem nuevo es un cambio de configuración, no una recompilación. Vea el frontend de telemática en producción sobre MOS4: ekkofleet.com.

Ver Multi Stacks →
IA edge 03 / 06

IA edge lista — declárela en TOML.

Cámara, GPU y NPU comparten memoria. Sin copias de píxeles por CPU. Hasta ~100 TOPS.

Declare el pipeline en TOML; entregue un modelo ONNX o TFLite. Munic reentrena, cuantiza, valida y despliega por OTA el modelo unificado. Carga DMS + ADAS completa (5 modelos) más codificación H.265 en un dispositivo de clase 10 TOPS.

Ver AI Funnel →
Diagnóstico remoto 04 / 06

La mayoría de plataformas leen el vehículo. MOS4 lo lee y le responde.

Un bot del lado de la nube pilota el bus en vivo. Leer · Resetear · Reconfigurar · Reflashear.

Mismo motor que la telemática autónoma — modo de operación distinto. Túnel TLS firmado, autorización por acción, reflash con atestación y reversión. Para el subconjunto de fallas de campo que no necesitan una llave inglesa, un desplazamiento se convierte en un paquete.

Ver Remote Diagnostic →
Programable 05 / 06

Totalmente programable — en cualquier lenguaje.

Configuración. Motores no-code. SDK completo en Python, Rust, C, C++, Go.

Tres superficies de programación, elegidas por capacidad. Configuración (TOML) para product managers. Motores no-code (procesado de señal, políticas de máquinas de estado, comunicaciones vehiculares, IA edge) para ingenieros embebidos. SDK completo donde importa. El único host industrializado de clase ROS2 que se ejecuta sobre hardware clase módem — los nodos ROS2 viajan a bordo mediante el patrón sidecar. Mezcle superficies en la misma flota.

Ver el SDK →
Linaje probado en campo 06 / 06

Sobre un linaje de plataforma probado en 4M+ unidades.

MOS4 es el OS de próxima generación en la línea de plataforma Munic. El linaje sostiene despliegues desde 2012 hasta hoy — vehículos de pasajeros, flotas, operaciones aeroportuarias, agricultura, automatización industrial.

La línea de plataforma Munic se despliega en 4M+ unidades en una aseguradora norteamericana de seguros para coches conectados (desde 2012), un programa MVNO de telemática (desde 2020), una asociación europea de automovilistas de 21 M miembros (desde 2022), varios programas de flota OEM europeos bajo NDA y OEMs especializados en vehículos de alto rendimiento, handling aeroportuario, off-highway y automatización industrial. MOS4 hereda los protocolos, los socios y la arquitectura probada en campo — y añade el modelo de micro services supervisados, OTA A/B y un pack de cumplimiento de grado CRA. Frontend de telemática de última generación encima: ekkofleet.com.

Ver la evidencia →
De serie, juntos

Un único cliente MQTT dirige los cuatro motores no-code — MSP, MEP, Multi Stacks y AI Funnel — desde un solo proceso. Sin toolchain de Rust, sin SDK por motor, sin pegamento personalizado.

Ver los ejemplos MQTT de los cuatro motores →

El pipeline

Cuatro motores · una plataforma.

Cada producto MOS4 ejecuta el mismo pipeline de cuatro motores: decodificación de bus e IoT, procesado de señal, política de máquinas de estado e IA edge declarativa — y luego bifurca al runtime en dispositivo y a la nube de Munic en el mismo ciclo OTA.

Pipeline de cuatro motores. Las entradas de bus vehicular e IoT industrial (CAN, CAN-FD, J1939, Modbus) alimentan Multi Stacks; las entradas de sensores (cámara, IMU, GNSS) alimentan los grafos de señal MSP. Las señales decodificadas de Multi Stacks también alimentan MSP. Las salidas de MSP alimentan MEP, el motor de política de máquinas de estado (primitivas T·C·A por debajo). Las salidas de MEP alimentan AI Funnel, el motor de IA edge declarativa. AI Funnel bifurca a dos destinos en el mismo ciclo OTA: un runtime NPU/GPU/CPU en dispositivo, y la nube de Munic para reentrenamiento y entrega OTA.

flowchart LR
  Bus[CAN · CAN-FD · J1939 · Modbus] --> MS[Multi Stacks]
  Sensors[Cámara · IMU · GNSS] --> MSP[Grafos MSP]
  MS --> MSP
  MSP --> MEP[MEP — política de máquinas de estado]
  MEP --> AI[AI Funnel]
  AI --> RT[Runtime NPU / GPU / CPU en dispositivo]
  AI --> Cloud[Nube de Munic — OTA + reentrenamiento]
  class AI ai-node
  class RT ai-node
Bus + sensores → Multi Stacks → MSP → MEP → AI Funnel. Cuatro motores, dos destinos: runtime en dispositivo y nube de Munic comparten el mismo ciclo OTA.

Antes / después — mismo OS, salto generacional.

métrica Generación anterior MOS4 (referencia clase módem)
tiempo de arranque listo ~90 s 1.6 s
memoria en estado estable (RSS) ~60 MB 28.4 MB
micro service mínimo — Rust escrito por el usuario n/a < 30 líneas

AI Funnel

Declare su IA. Munic la despliega.

Los clientes entregan un grafo TOML más un modelo ONNX/TFLite y un dataset COCO. Cámara, GPU y NPU comparten memoria directamente — la CPU nunca copia datos de píxeles. Ejecute varios modelos concurrentes con codificación H.265 en un dispositivo de clase 10 TOPS.

IA · capa de inteligencia
— STEP 01

El cliente aporta

Un grafo TOML, modelos ONNX/TFLite, un dataset COCO y un contenedor opcional de lógica de negocio.

— STEP 02

La nube de Munic hace

Reentrenar, cuantizar, validar, hacer benchmarks, empaquetar y desplegar por OTA el modelo unificado de triaje.

— STEP 03

Runtime en dispositivo

Recorte y redimensión por GPU, inferencia por NPU, memoria compartida de extremo a extremo. Ningún byte de píxel atraviesa la CPU.

Diagrama fan-in: tres flujos de entrada convergen en un diamante de decisión ámbar — el modelo de triaje IA en dispositivo

Remote Diagnostic

Un desplazamiento se convierte en un paquete.

La nube abre una sesión firmada, pilota el bus, completa la acción y cierra. Para el subconjunto de fallas de campo que no requieren un taller. Mismo motor UDS / J1939 / ISOBUS / Modbus / J2534-passthru que la telemática autónoma — modo de operación distinto.

OEM · garantía

Reset de ECU por aire

Resetear una ECU (Electronic Control Unit) bloqueada desde la nube. El conductor continúa. Sin grúa, sin visita al concesionario.

Fabricante de VE

Certificación con monitor en vivo

Leer telemetría de celdas en vivo a lo largo de un ciclo de carga / descarga. Certificado emitido desde el mismo registro de auditoría.

Asistencia en carretera

Triaje rodar-o-grúa

Leer el estado de la ECU. Decidir si el vehículo puede alcanzar el próximo taller o necesita grúa.

Inspector de flota

Mutualización de inspectores

Operadores de campo se conectan al vehículo; un solo técnico inspecciona muchos vehículos desde una oficina.

Egreso a la nube

GraphQL mesh como punto de entrada del cliente.

El camino completo a la nube: micro service en contenedor → MQTT bridge → pasarela de comunicaciones → cloud-connect → micro service en la nube → GraphQL mesh → aplicación del cliente.

Silueta de servidor cloud cian a la izquierda conectada por flujos de datos brillantes a tres vehículos a la derecha (sedán, camión, excavadora) — topología de telemática sobre fondo blueprint oscuro

Topología de egreso a la nube — de micro service a GraphQL mesh

flowchart LR
    A[Micro servicio en contenedor] --> B[MQTT bridge]
    B --> C[Pasarela de comunicaciones]
    C --> D[cloud-connect]
    D --> E[Micro servicio en la nube]
    E --> F[GraphQL mesh]
    F --> G[App del cliente]

Referencia pública de la pasarela GraphQL: gateway.munic.io/services/graphql_gateway/docs/

Runtime de contenedor

Hot-swap. Sin reinicio.

Lleve su nodo. Reemplace un micro service sin reiniciar el dispositivo. Contenedores aislados en proceso con límites de recursos garantizados. SDKs de primera clase en Python, Rust, C, C++, Go. Cualquier lenguaje que hable MQTT viaja a bordo.

Contenedores aislados en proceso

Límites de recursos como contrato, no mejor esfuerzo. Runtime crun de producción sobre cgroups v2.

Lleve su nodo

Los nodos existentes en Python · Rust · C · C++ · Go se incorporan sin cambios. Ningún cambio de código para circular por el bus tipado.

Cualquier lenguaje que hable MQTT

Por encima de la capa SDK, cualquier cliente publica y se suscribe — neutral en lenguaje.

Alternativa runtime ROS2

Una pasarela sidecar ROS2 de primera clase puentea los grafos DDS hacia MOS4. Los nodos ROS2 existentes viajan a bordo — el único host industrializado de clase ROS2 sobre hardware clase módem.

SDLC · CI · cumplimiento

Contratos de servicio tipados. SBOM en cada versión.

Cada micro service publica su contrato. Cada versión incluye un SBOM CycloneDX, un escaneo de CVE, binarios firmados y una superficie OpenTelemetry. CRA-ready — mapeo artículo por artículo en el pack de cumplimiento.

SBOM CycloneDX software bill of materials, en cada versión
Versiones firmadas binarios firmados, registro de auditoría por versión
Gate de CVE escaneo de dependencias, en cada commit
Análisis estático patrones de código seguro aplicados
OpenTelemetry superficie de observabilidad, en cada micro service
CRA artículo por artículo EU Cyber Resilience Act, mapeado
Operaciones

La capa day-2 está incluida.

Observabilidad, safety, OTA, control remoto, ciclo de vida. Cinco capacidades, una plataforma, todos los dispositivos.

Explorar la capa de operaciones →
CRA-ready

CRA-ready. Desde el primer día. En cada versión.

Mapeo CRA artículo por artículo, SBOM, pipeline de seguridad, proceso PSIRT.

Leer cumplimiento →

Construir sobre MOS4.

Empiece por el catálogo de servicios — declare las capacidades que necesita, dimensionadas por nivel de silicio. Ingeniería está a un clic cuando necesite una conversación de encaje.

¿Construyendo sobre MOS4?

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

Hablar con ingeniería