— Plataforma / Arquitectura
El stack MOS4.
MOS4 es un OS de micro services distribuido sobre Linux: 8 capas arquitectónicas, 52 micro services en producción, 89 interfaces proto, hot-swap en 10 segundos. Interfaces definidas en proto, orden garantizado por el registro y hot-swap son propiedades del framework — no responsabilidades de la aplicación.
Modelo de componente
Una declaración, superficie de servicio completa.
Cada micro service declara provided_interfaces y required_interfaces definidos en proto. El paso de generación de código escribe la superficie de servicio completa: trait de servidor, proxy, cliente directo, doble de prueba fake, módulo de métricas y suite de pruebas de conformidad — desde una única declaración. El autor escribe hooks de ciclo de vida y lógica de negocio — nada más.
Un paso de generación de código
build_api::generate_component_code(dir, out_dir) en build.rs genera: análisis proto → trait de servidor → proxy → cliente directo → fake → módulo de métricas
→ suite de pruebas de conformidad. Un micro service mínimo tiene menos de 30 líneas de Rust
escrito por el usuario.
Orden garantizado por el registro
start_level 0–10 es la prioridad numérica del registro — distinta del modelo mental
de arquitectura L0–L7. El registro construye un grafo de dependencias y lo aplica en el arranque;
ningún micro service puede llamar a una interfaz requerida antes de que su proveedor se haya
registrado.
Hot-swap a nivel de framework
Cuando un nuevo proceso se registra con un component.id existente, el registro
solicita un volcado de estado a la instancia antigua, la detiene, inyecta el estado serializado
en la nueva y arranca el reemplazo. Desde el fin de la compilación hasta la primera llamada
de servicio exitosa en un dispositivo real: 10 segundos.
Explore el catálogo completo de micro services — 52 servicios, 89 archivos proto.
Runtime supervisado
Tres capas de supervisión, sin código adicional.
El framework monitoriza cada micro service con checkpoints de tarea, pings de salud de proceso e integración con watchdog hardware. La acción correctiva — reinicio, rearranque o reset de hardware — escala automáticamente sin configuración por servicio.
Watchdog
Los micro services declaran checkpoints de tarea con nombre y tiempos de espera en la
macro #[component]. El framework monitoriza tres capas de supervisión:
checkpoints de tarea, pings de salud de proceso entre procesos maestro y esclavo, y la
ruta de escalado hardware de Linux /dev/watchdog. Checkpoint perdido →
Degradado → reinicio → rearranque → reset de hardware.
Sentry
Seguimiento centralizado de incidencias en todos los micro services. Durante la ventana de gracia de arranque del registro, los errores de clase cascada se retienen — una puerta Sentry en cascada impide que el ruido de arranque contamine el registro de incidencias. Los operadores pueden ajustar el periodo de gracia de arranque o deshabilitar la puerta completamente.
Observabilidad
El framework emite histogramas por RPC, contadores de error, tiempo de actividad del
servicio y trazas de eventos de ciclo de vida para cada llamada de servicio registrada —
automáticamente mediante ObservabilityRegistry. La propagación W3C Trace
Context está incluida; no se requiere contrato de instrumentación por servicio.
Paneles, OTA, control remoto, ciclo de vida — superficie completa de observabilidad en /es/platform/operations.
Registro + transporte
Transporte seleccionado por URL de endpoint.
El registro maestro controla el descubrimiento de servicios y el orden de arranque. El modo de transporte — memoria, socket Unix, memoria compartida, TCP, QUIC, WebSocket — se selecciona por esquema URI en la configuración del bundle. El modo directo omite la serialización para llamadores en el mismo proceso. El código del servicio es ciego al transporte.
| Entorno | Transporte | Codificación |
|---|---|---|
| Servicio a servicio en el mismo chip | iceoryx2 SHM + dmabuf | sin copia |
| Plano de cámara / visión | paso de fd SCM_RIGHTS | handle dmabuf |
| Puente ROS2 | iceoryx2 DDS | protobuf / DDS |
| Entre hosts / TCP | TCP / sockets Unix / QUIC | zstd / LZ4 / gzip |
| Clientes WebSocket | WebSocket | zstd / gzip |
TCP, sockets Unix, memoria compartida, QUIC, WebSocket, tuberías con nombre y buffers de anillo implementan todos la misma interfaz de transporte. Sin compilación condicional en el código del servicio. La compresión en línea (zstd, LZ4, Snappy, gzip) se negocia por conexión. El circuit breaker y el reintento están integrados en el registro.
Dos modos de transporte. Modo 1: el intercambio de datos de servicio a servicio en el mismo chip usa memoria compartida con handles de frame para transferencia de frames sin copia. Modo 2: puente ROS2 — los nodos rclcpp y rclpy publican temas DDS; el transporte de frames los traduce al bus MOS4, entregando eventos tipados a los micro services MOS4.
flowchart LR
subgraph S1["Servicio a servicio en el mismo chip"]
A[Micro service A] -->|memoria compartida + handle de frame| B[Micro service B]
end
subgraph S2["Puente ROS2 mediante el transporte de frames"]
R[nodo rclcpp / rclpy] -->|tema DDS| F[Transporte de frames]
F -->|bus MOS4| C[Micro service MOS4]
end Los 4 motores, un runtime
Una plataforma sirve los cuatro motores no-code y N contenedores.
El supervisor, el registro, el EventBus y el broker MQTT en proceso son infraestructura compartida. MSP, MEP, Multi Stacks y AI Funnel consumen las mismas primitivas — y también lo hace cada contenedor del cliente, en cualquiera de los cinco lenguajes disponibles.
Plataforma compartida
- · Supervisor — arrancar, detener, reiniciar, hot-swap
- · Registro — interfaces tipadas, semver, grafo de dependencias
- · EventBus — distribución de eventos con nombre
- · Broker MQTT en proceso — cualquier contenedor de lenguaje accede a cualquier servicio
Motores y contenedores, en paralelo
- · MSP — grafos continuos de procesado de señal
- · MEP — políticas de máquinas de estado (T·C·A bajo el capó)
- · Multi Stacks — comunicaciones vehiculares e IoT industrial
- · AI Funnel — IA edge declarativa
- · N contenedores — Python · Rust · C · C++ · Go (sidecar ROS2)
Cada motor no-code está documentado en detalle en /es/platform/no-code.
Glosario
Nombre público a término de ingeniería.
| Término | Qué es |
|---|---|
| Micro service | Unidad de runtime de MOS4. Crate de Rust, macro #[component], interfaces proto. |
| MCM | MOS Container Manager — motor de contenedores ligero con aislamiento de recursos garantizado. |
| MD21 | Protocolo de telemetría ascendente de Munic (ASN.1 UPER), optimizado en ancho de banda. |
| MSP | MOS Signal Processing — motor de grafos YAML para flujo de datos de dominio vehicular. |
| MEP | MOS Event Processor — motor de política de máquinas de estado. Cada regla es una primitiva Trigger / Condition / Action; el conjunto de reglas compuesto es la máquina de estado. Recargable en caliente. |
| iceoryx2 | IPC sin copia. Dos modos: SHM + dmabuf en el mismo chip, DDS completo para el puente ROS2. |
Las etiquetas del diagrama de stack (L0–L7) son un modelo mental para la agrupación de capas.
La prioridad del registro usa un start_level numérico 0–10 — escala diferente, propósito
diferente.
Egreso a la nube
De micro service a GraphQL mesh — de extremo a extremo.
Micro service en contenedor
El código de aplicación o un micro service de plataforma publica eventos tipados.
MQTT bridge
Cualquier cliente MQTT estándar — sin adopción de SDK necesaria.
Pasarela de comunicaciones
Enlace ascendente MD21: codificación ASN.1 UPER, optimizado en ancho de banda.
cloud-connect
Relay de la nube de Munic — ejecuta multiplexación, piggybacking y compresión.
GraphQL mesh
Punto de entrada del cliente. Referencia pública: gateway.munic.io
GraphQL mesh es el punto de entrada del cliente — del lado de la nube, no del dispositivo. El endpoint de referencia público es el portal de documentación para desarrolladores.
Desbloqueo del desarrollador
Puente RPC — llame a cualquier micro service desde la nube.
El puente RPC expone cualquier servicio MOS4 registrado sobre el canal applications.rpc. Acepta JSON con itfname, call y payload. Sin código de protocolo ni de cableado más allá de la interfaz del componente y el servicio del lado de la nube.
Depurar y desbloquear
Llame a cualquier micro service — incluidos contenedores — desde la nube para inspeccionar el estado, activar una acción puntual o desbloquear una situación poco frecuente en un dispositivo remoto.
Flujos híbridos dirigidos por IA
Un agente de IA o una capa de automatización en la nube puede dirigir el dispositivo
mediante API — consultar sensores, activar actuadores, cargar una nueva política — con ListServices() devolviendo el catálogo de servicios en vivo en tiempo de ejecución.
RoutingService es parte del stack del módem, no un micro service separado. La vista del mismo primitivo RPC para el desarrollador de SDK vive en /es/platform/sdk.
Compare MOS4 con otros OS embebidos y enfoques de plataforma en visión general de comparativas.