— Por qué MOS4
Una plataforma, cinco decisiones que puede reenviar.
MOS4 es un OS Linux embebido distribuido basado en micro services para vehículos, máquinas e IoT conectados — elegido por programas que necesitan un SBOM CRA-listo, secure boot con runtime supervisado, soporte de silicio AI-class, un OS en todos los niveles de silicio y un SDK de seis lenguajes. La página a continuación divide las respuestas en las cinco áreas de decisión — cumplimiento, seguro-y-safe, economía, narrativa, ingeniería — para que cada sección se reenvíe al colega responsable.
Lo que un expediente de evaluación de proveedor necesita del proveedor del OS.
El Reglamento Europeo de Ciberresiliencia se aplica desde 2027. MOS4 se entrega con un SBOM CycloneDX, un PSIRT público y un mapeo CRA artículo por artículo, para que los equipos jurídico y de seguridad puedan incluir el dossier de conformidad en una evaluación de proveedor.
SBOM CycloneDX en cada versión
Lista de materiales legible por máquina — descargable desde el portal del cliente para incluirla en los expedientes de evidencia de compras. cargo cyclonedx se ejecuta en cada commit en los 52 micro services.
PSIRT + divulgación coordinada
Dirección pública security@munic.io, reconocimiento en 5 días laborables, CVEs seguidos por versión. Objetivos de parche interno: 7 / 30 / 90 días por gravedad; SLAs contractuales por programa.
Mapeo CRA artículo por artículo
Anexo I §1, §2, Art. 13, Art. 14 — cada requisito mapeado al artefacto MOS4 que lo satisface. El equipo responsable del pack de cumplimiento solo documenta la capa aplicativa.
OTA firmado + gestión de cohortes
Paquetes delta firmados con Ed25519, particiones A/B, retroceso automático por bootcount. OTA por cohorte y canary mediante la nube complementaria de Munic.
Higiene OSS + LTS
El OSS upstream es auditado para detectar licencias contaminantes (LGPLv3 y equivalentes eliminados antes de la integración). cargo audit + cargo deny + semgrep se ejecutan en cada commit para detectar CVEs en dependencias OSS. Un compromiso de soporte a largo plazo proporciona a los programas una base estable durante ciclos de producción plurianuales.
Seguridad y safety pertenecen al OS.
El papeleo de compliance (#01) es derivado de la postura de ingeniería. Seguridad y safety funcional son propiedades de plataforma en MOS4: impuestas en CI en build-time, por el supervisor en el arranque y por el contrato de recursos en runtime. Los mismos controles corren en cada commit, cada release, cada micro service.
Secure Boot + key store anclado en TEE
Raíz de confianza anclada en hardware. Cadena de arranque firmada en silicio compatible. Claves almacenadas en un Trusted Execution Environment — nunca expuestas a la capa de aplicación.
OTA A/B firmado con rollback automático
Particiones A/B con imágenes criptográficamente firmadas. Fallo → attest-and-revert, eliminando la clase de fallo «imagen rota en campo». Anti-rollback impuesto.
Runtime supervisado con contratos de recursos
Cada micro service corre en un contenedor con límites cgroup CPU/memoria/IO impuestos al arranque. Watchdog con reinicio automático ante heartbeats perdidos. Un servicio descontrolado no puede asfixiar al dispositivo.
Arranque determinista, contratos tipados
El orden de arranque deriva de un grafo de dependencias declarado; el registry rechaza grafos mal ordenados en build-time. Contratos protobuf tipados atrapan la deriva en compilación — sin clase de race condition, sin rotura silenciosa en campo.
Observabilidad a escala de flota
Trazas, métricas y logs estructurados de cada servicio en una superficie OpenTelemetry unificada. Contadores de reinicio, códigos de salida, latencia y advisories CVE aparecen en el dashboard antes de propagarse.
Un OS en toda la escala de silicio.
MOS4 funciona desde SoCs modem-class hasta silicio AI-class sobre un único OS. Munic realiza el porte; el programa elige el nivel de silicio por producto. No se requiere equipo BSP interno. Rutas de migración documentadas desde RTOS, Linux genérico, Android Automotive y ROS2 sobre Linux completo.
Escala de niveles de silicio. El mismo OS MOS4 abarca tres clases de silicio. Modem-class — menos del 5% de overhead, 28.4 MB de RSS en estado estable, arranque first-app-ready en 1.6 s. Compute-class — captura multicámara, aislamiento de contenedores. AI-class — hasta aproximadamente 100 TOPS NPU en silicio AI-class, compatible binariamente en el nivel AI-class. Munic porta el OS en la familia; el OEM elige el nivel por producto.
flowchart LR M[modem-class<br/>RSS 28.4 MB · arranque 1.6 s<br/>menos del 5% overhead] C[compute-class<br/>multicámara · contenedores] A[AI-class<br/>hasta ~100 TOPS NPU<br/>familia QCS] M --> C --> A M -. un OS .-> C C -. un OS .-> A class A ai-node
28.4 MB RSS · arranque 1.6 s · <5% overhead
Referencia de silicio modem-class. RSS en estado estable y arranque first-app-ready en un dispositivo de producción modem-class representativo. La misma imagen de OS escala a silicio AI-class sin una rama separada.
Sin licencia de toolchain por ingeniero
Multi Stacks + Diagnóstico remoto sustituye el utillaje de taller por asiento por un modelo por dispositivo, a escala de flota.
Matriz de migración incluida
Rutas documentadas desde RTOS monolítico, Linux genérico, Android Automotive y ROS2 sobre Linux completo — el generador de bundle Cargo de mos-distro y los perfiles por objetivo cubren los destinos embebidos más comunes.
Variantes de hardware, el código permanece igual
La gama de silicio va desde una referencia modem-class sin NPU ni GPU hasta silicio AI-class (~100 TOPS). El mismo conjunto binario se ejecuta en toda la familia — sin costes de portado, reentrenamiento ni revalidación al moverse por la escala de silicio. Escala de costes de producción por volumen: consulte munic.io para SKUs y niveles.
Entregar capacidades, no afirmaciones de marketing.
El pipeline de IA en dispositivo está completamente disponible. Cámara, GPU y NPU comparten memoria directamente — la CPU nunca copia datos de píxeles. Ejecute una carga DMS + ADAS completa (5 modelos) más codificación H.265 en un dispositivo de 10 TOPS. Configurado en TOML; desplegado mediante el mismo canal OTA que el código.
Pipeline cámara-a-NPU con memoria compartida
Cámara, GPU y NPU comparten memoria directamente — la CPU nunca copia datos de píxeles. La CPU planifica pero nunca toca píxeles. Configurado en TOML; desplegado por OTA.
Vision: multicámara, recorte y redimensión GPU, anonimización GDPR en tiempo real
Cinco entradas de cámara (MIPI-CSI, GMSL2, USB UVC, RTSP/ONVIF, WebRTC). La anonimización GDPR en tiempo real (desenfoque de rostros y matrículas) está controlada por un interruptor de política en el arranque antes de que cualquier frame abandone el pipeline.
Despliegues de referencia detrás de cada afirmación
Vehículos de alto rendimiento, operaciones aeroportuarias en tierra, agricultura, maquinaria off-highway. Los clientes están bajo NDA, pero los sectores, capacidades y estándares no.
Pila AI completa de un solo proveedor — un SLA desde la cámara hasta el LLM y el registro de auditoría
La AI de visión y la AI de lenguaje se ejecutan en el mismo dispositivo bajo un único SLA de plataforma. Inferencia cámara-a-NPU, LLM on-device con RAG refuse-preferred, y un manifiesto de auditoría por respuesta — todo de un proveedor, un canal OTA, un contrato de soporte.
AI offline-first — RAG, LLM y voz se ejecutan on-device por defecto; la nube es opt-in
La plataforma de lenguaje se ejecuta completamente on-device por defecto. El acceso a la nube requiere configuración explícita en tres puertas independientes. Sin dependencia de conectividad para la inferencia principal.
Python, Rust, C, C++, Go — todos sobre la misma plataforma.
La reformación es uno de los mayores costes ocultos de un programa embebido. MOS4 conserva los lenguajes que el equipo ya ejecuta. MQTT, Prometheus, TOML y esquemas tipados son ciudadanos de primera clase. Los nodos ROS2 (rclcpp/rclpy) se ejecutan sin modificaciones dentro de un contenedor MCM mediante el patrón sidecar.
Cinco lenguajes, un motor de contenedores OCI
Python, Rust, C, C++ y nodos Go funcionan codo a codo bajo aplicación de recursos cgroups v2 (runtime de producción crun). Los nodos ROS2 se integran mediante el patrón sidecar. Los nodos existentes se incorporan; los nuevos adoptan interfaces protobuf tipadas. Requisitos de calificación AGV/robótica: contacte con ingeniería.
Motores no-code para lógica de autoría por expertos de dominio
MSP: 226 grafos de procesado de señal en 21 dominios de vehículo, configurados en YAML, sin recompilación de Rust por dominio. MEP: motor de política de máquinas de estado (T·C·A bajo el capó), recarga en caliente, pool de workers paralelos. Multi Stacks: comunicación vehicular e IoT industrial, 16 familias de protocolo declarativamente. AI Funnel: IA edge declarativa — grafo TOML dentro, OTA fuera.
SDLC adaptado a un programa industrial
cargo test, integración e2e de distro, cargo bench, cargo grcov (cobertura), cargo audit + geiger + deny (seguridad), semgrep (análisis estático), cargo cyclonedx (SBOM) — en cada commit, mediante la plantilla compartida ci-gamma.
Observable por diseño
Métricas Prometheus, exportación OpenTelemetry OTLP, propagación W3C Trace Context, logs estructurados — automáticos para cada llamada de servicio registrada mediante ctx.observer(). Las mismas convenciones que el equipo cloud ya opera.
Compare MOS4 con alternativas
Matriz de adecuación
Sector × capacidad.
Encuentre su sector, recorra su columna, autocalifíquese. Cada celda resume la capacidad para ese sector.
| Capability | Automoción | Maquinaria | Camiones y VCL | Gateway IoT | Vídeo e IA de flota |
|---|---|---|---|---|---|
| Multi Stacks · Diagnóstico remoto | CAN, CAN-FD, DoIP | ISOBUS, J1939 | HD-OBD, J1708, J1587 | Modbus, RS485 | — |
| AI Funnel · IA edge declarativa | Modelos específicos del OEM | Detección de cultivo / activo | Puntuación del conductor | Triaje de anomalías | Reentrenamiento multicámara |
| Vision · ROI shader · ADAS+DMS | DMS, caja negra | Alertas al operador | Dashcam + DMS | — | Anonimización GDPR en directo |
| CRA · SBOM · pipeline de seguridad | core | core | core | core | core |
| Nivel de hardware | compute · AI-class | compute-class | compute-class | modem · compute | AI-class |
| Lenguajes: Python · Rust · C · C++ · Go | los cinco | C / C++ / Rust | C / C++ / Rust | Python / Rust | Python / C++ |
FAQ
Preguntas frecuentes
-
¿Para quién está escrita la página Por qué MOS4?
La página está organizada por área de decisión — cumplimiento, seguro-y-safe, economía, narrativa, ingeniería — para que cada sección se reenvíe al colega responsable.
-
¿Cómo aborda MOS4 el Reglamento Europeo de Ciberresiliencia (CRA)?
El CRA se aplica a partir de 2027. MOS4 se entrega con un SBOM CycloneDX, un PSIRT público en security@munic.io y un mapeo CRA artículo por artículo que cubre el Anexo I §1, §2, Art. 13 y Art. 14.
-
¿Sobre qué niveles de silicio funciona MOS4?
Un solo OS abarca silicio modem-class, compute-class y AI-class. La referencia modem-class es 28.4 MB de RSS en estado estable y arranque first-app-ready en 1.6 s, con menos del 5% de overhead. Munic realiza el porte; el programa elige el nivel por dispositivo.
-
¿Qué lenguajes de programación se ejecutan en MOS4?
Python, Rust, C, C++ y nodos Go conviven bajo aislamiento de contenedores garantizado. Los nodos ROS2 se integran mediante el patrón sidecar. Los nodos existentes se incorporan; los nuevos adoptan interfaces tipadas.
-
¿Cómo gestiona MOS4 la IA edge?
Cámara, GPU y NPU comparten memoria directamente — la CPU nunca copia datos de píxeles. Ejecute una carga DMS + ADAS completa (5 modelos) más codificación H.265 en un dispositivo de 10 TOPS con capacidad de CPU disponible para el código de aplicación. Consulte /es/platform/ai-vision para más detalles.
-
¿A qué tamaños de programa se dirige MOS4?
MOS4 se dirige a programas de pequeño y mediano volumen — 10 000 a 300 000 unidades — en automoción, maquinaria, camiones y VCL, gateway IoT, y vídeo e IA de flota.
-
¿Cómo funciona la OTA por cohorte y canary?
Particiones A/B, paquetes delta firmados y retroceso automático. La gestión de cohortes y canary se entrega del lado servidor mediante la nube complementaria de Munic.
¿Es nuevo en la jerga de MOS4? El glosario cubre contenedor MCM, dma-buf, ci-gamma, J1939 y más.
Reenvíe esta superficie de decisión al colega responsable.
Una llamada, un artefacto, cada interfaz y cada contrato sobre la mesa.