Plataforma
La capa de operaciones.
Cinco capacidades que una flota necesita después de que se envía el primer dispositivo — y lo que se necesita para mantener esa flota viva en el campo. Integradas en la plataforma; no son un complemento, no son un add-on del proveedor, no son el problema del cliente.
Pilar 1
Observabilidad
Métricas, trazas e instantáneas en vivo por micro service — compatibles con Prometheus y OpenTelemetry de fábrica.
Métricas automáticas por micro service
Temporización RPC, contadores de solicitudes y errores, throughput, eventos de ciclo de vida, estado, tiempo de actividad — sin código de instrumentación requerido.
Push de métricas personalizadas + puntuación de salud
Cualquier micro service envía métricas personalizadas y una puntuación de salud 0,0–1,0 mediante la API del observador en proceso.
Instantánea periódica del lado de la nube
Un micro service de informes dedicado envía registros por componente y por proceso (CPU, memoria, descriptores de archivo, hilos, tiempo de actividad, cadena de salud), más un vaciado forzado en reposo, parada y parada de emergencia.
Scrape Prometheus de contenedores
El endpoint de métricas de cada contenedor en ejecución alimenta el pipeline de supervisión a través del motor de contenedores ligero.
Propagación de W3C Trace Context
Trazado distribuido a través de micro services y procesos — sin cambio en el código de aplicación requerido.
Pull remoto de sincronización forzada
La nube o las herramientas extraen una instantánea inmediata bajo demanda, con limitación de tasa.
Por qué importa. Un dispositivo de flota con cien micro services independientes emite un conjunto de métricas compatible con Prometheus en minutos desde el arranque; el equipo de la nube usa los dashboards que ya posee.
Cómo el registro y el observador encajan en la arquitectura de plataforma →
Pilar 2
Seguridad
Cuatro niveles de supervisión y una cadena de escalada determinista. Una tarea colgada, un proceso colgado o un kernel colgado no puede perder el dispositivo.
Flujo de supervisión del watchdog. Una tarea de micro service alimenta su checkpoint HealthMonitor en proceso; los pings de proceso fluyen al micro service de política de watchdog junto con el HealthMonitor; la política emite advertencia, reinicio o parada de emergencia al registro, y alimenta el watchdog de hardware Linux; en caso de bloqueo, el hardware fuerza un reinicio del sistema.
graph TD
A[Tarea de micro service] -->|alimentar checkpoint| B[HealthMonitor en proceso]
C[Pings de proceso] --> D[Micro service de política de watchdog]
B --> D
D -->|advertir / reiniciar / parada de emergencia| E[Registro]
D -->|alimentar| F[Linux /dev/watchdog]
F -->|reset de hardware en bloqueo| G[Reinicio del sistema] Nivel 1 — HealthMonitor en proceso
Cada micro service declara checkpoints nombrados y los alimenta desde su bucle de tarea.
Nivel 2 — Pings de proceso
Los procesos master y slave intercambian pings de salud; el estado degradado aflora a la política.
Nivel 3 — Micro service de política de watchdog
Bucle autónomo de 30 segundos, contador de violaciones por componente, escalera de acción determinista: advertir → reiniciar → parada de emergencia.
Nivel 4 — Watchdog de hardware Linux
Temporizador alimentado a intervalos fijos; si la pila de software se cuelga, el hardware fuerza un reset.
Hook del ciclo de vida de parada de emergencia
Cada micro service obtiene una ventana de limpieza breve antes del reinicio. Los hooks se llaman desde el registro, no desde la aplicación.
Agregación de incidencias
Las incidencias idénticas se colapsan en lotes clasificados como periódicos-o-ráfaga antes de la carga — es imposible inundar la nube con duplicados.
Árbitro de energía
Cualquier micro service puede mantener un token para diferir una transición de energía hasta que sea seguro; el motor espera hasta un timeout configurable para que se liberen los tokens.
Por qué importa. La cadena de escalada es auditable, testable en el banco y se ejecuta sin intervención del operador. Un corte de servicio en una flota a escala cuesta más que la plataforma en sí.
Pilar 3
Actualizaciones over-the-air
Particiones A/B, paquetes delta firmados, rollback automático. Rust puro, sin daemon externo, funciona en hardware de clase módem.
Slots A/B de rootfs + contador de arranques
Un arranque fallido revierte al slot anterior sin acción del operador.
Paquetes delta
Fragmentación definida por contenido, deduplicación en múltiples árboles fuente, compresión zstd dimensionada para targets de clase módem.
Cadena criptográfica
Manifiesto firmado verificado antes de cualquier escritura en flash; cifrado de payload opcional; verificaciones de integridad por archivo y de imagen completa.
Contadores de reintentos y reinicios persistentes
Límite de reintento por archivo, límite de reintento por actualización, límite de reinicios por actualización — sobreviven ciclos de energía, previenen bucles de reinicio infinitos en actualizaciones inestables.
Dos entradas de transporte
Canal de comando en la nube y llamada directa al micro service.
Dos binarios de una librería
Un generador del lado del host y un aplicador en el dispositivo; los cambios de formato se propagan atómicamente.
Por qué importa. Enviar firmware es la parte fácil; revertirlo sin un desplazamiento de técnico es la difícil.
Recorre un rollout OTA con nosotros, de extremo a extremo.
Pilar 4
Control remoto
Un único canal se dirige a cada micro service del dispositivo. Señales en vivo, logs en vivo, sesiones de diagnóstico en vivo.
Interfaces de micro service invocables desde la nube
Cualquier interfaz de micro service registrada es invocable desde la nube o desde herramientas, passthrough JSON o protobuf, consulta del catálogo en tiempo de ejecución, errores JSON-RPC 2.0, estadísticas de latencia por llamada opcionales.
Recuperación remota de logs
Filtro de rango de marca de tiempo TAI64 más patrón grep/sed, chunks comprimidos en streaming. Sin SSH, sin SCP, sin herramientas del lado del dispositivo.
Instantánea de observabilidad bajo demanda
Extraiga una instantánea inmediata antes de emitir un comando o actualización; con limitación de tasa.
Superficie de protocolo vehicular mediante Multi Stacks
Lectura en vivo de cualquier señal CAN, CAN-FD, DoIP, ISOBUS, J1939, J1708, J1850, J1587, HD-OBD, Modbus, RS-485 como un tópico de micro service.
Por qué importa. El flujo de trabajo de postventa es práctico porque cada dispositivo de la flota expone la misma superficie de control remoto.
Pilar 5
Ciclo de vida
Cada cambio de estado es deliberado. Los reinicios se explican, los reposos son anulables, las actualizaciones de runtime se implementan en toda la flota sin cambios en el código del cliente.
Registros de razón de arranque + razón de activación
Expuestos a cada micro service (HardReset, SoftReset, WatchdogReset, Ignition, Alarm, RTC, CAN). Las herramientas de campo y la superficie en la nube los leen para determinar la causa raíz de cada reinicio.
Override-next-idle
El registro puede sustituir el próximo reposo natural por un reinicio o apagado controlado — sin reinicios inesperados en el campo.
Guardia de tiempo de actividad máximo
Modelo de reinicio de dos umbrales que apunta a la fragmentación del asignador en dispositivos de larga ejecución; el límite suave reinicia en el próximo reposo, el límite duro fuerza el reinicio, la guardia de bucle rompe los ciclos de reinicio-reposo.
Capas del sistema
Capas de runtime compartidas fijadas por el operador. Una actualización de runtime de toda la flota es un único bump de digest en la configuración del operador; los contenedores de aplicación del cliente no se reconstruyen ni reenvían.
Configuración de eventos de activación
Máscara de activación configurable (encendido, alarma, RTC) para que el dispositivo entre en reposo por energía y se active ante las señales correctas en plataformas que lo admiten.
Por qué importa. Las operaciones de flota raramente tratan sobre fallos catastróficos; se trata de respuestas coherentes a "¿por qué reinició este dispositivo anoche?" y "¿cómo implemento un parche de seguridad de runtime a diez mil contenedores de clientes sin tocar el código del cliente?".
Capacidad transversal
Remote Care — la vista de disponibilidad de la flota
Los cinco pilares anteriores muestran cómo se estructura la capa de operaciones por área de interés. La misma superficie, vista de extremo a extremo como remediación, es la página Remote Care — pensada para el equipo de operaciones de flota que razona en inmovilizaciones evitadas, no en pilares.
Cuando el dispositivo falla, no envía un camión. Envía un paquete.
Remote Care es la vista transversal de la capa de operaciones — tres niveles de remediación (diagnosticar, reconfigurar, remediar), una capa predictiva en el dispositivo y un registro de auditoría en cada acción. Capacidad integrada del SO; no es un SaaS separado.
Catálogo
Las siete tarjetas del catálogo detrás de la capa
Cada afirmación anterior se asigna a un micro service. Entre en el catálogo para interfaces, especificación fuente y puntos de integración.
Arquitectura de plataforma — cómo registro + ciclo de vida se conectan →
Seguridad
Watchdog
Micro service de política de supervisión de cuatro niveles. Bucle autónomo de 30 segundos; escalada determinista; integración de watchdog de hardware.
Observabilidad
Observer
Reportador periódico de instantáneas en la nube. Registros por componente y por proceso; vaciado forzado en transiciones del ciclo de vida; RPC de sincronización forzada.
Seguridad
Sentry
Agregación de incidencias en todos los micro services. Compuerta en cascada en el arranque; clasificación periódico-o-ráfaga; deduplicación antes de la carga.
Control remoto
Logs
Recuperación remota de logs. Rango de marca de tiempo TAI64 + filtro grep/sed; chunks comprimidos en streaming; sin SSH, sin SCP.
OTA
Update
OTA de partición A/B. Paquetes delta firmados; fragmentación definida por contenido; cadena criptográfica; contadores de reintentos y rollback.
Ciclo de vida
Containers
Motor de contenedores ligero. Sustitución de capas del sistema; scrape Prometheus por contenedor; aislamiento de recursos cgroups v2.
Seguridad + Ciclo de vida
Power
Árbitro de energía; guardia de tiempo de actividad máximo; configuración de eventos de activación; override-next-idle; registros de razón de arranque y activación.
Preguntas
Las cinco preguntas que hacen los integradores
Lo que aparece en cada llamada técnica de descubrimiento.
-
¿Es esto un rebranding de cumplimiento, observabilidad y OTA?
No. El cumplimiento, la observabilidad y el OTA conservan sus propias páginas y conceptos. La capa de operaciones es el paraguas — lo que la plataforma le da a una flota en el día dos — y enlaza a cada una de esas páginas donde vive la profundidad.
-
¿Tengo que usar todos los pilares?
No. Cada pilar es independiente. Un equipo puede lanzar solo con la supervisión de seguridad y la cadena OTA el día uno, y activar el control remoto y la instantánea de observabilidad cuando el backend en la nube esté listo.
-
¿Esto me vincula a los servicios cloud alojados por Munic?
No. La instantánea de observabilidad es compatible con Prometheus y OpenTelemetry; la cadena OTA se ejecuta contra cualquier endpoint HTTP, HTTPS o SFTP; la superficie de control remoto habla un esquema JSON documentado. Los backends en la nube son intercambiables.
-
¿En qué se diferencia esto de ejecutar Prometheus + Grafana + un servicio OTA personalizado en contenedores?
No es una pila diferente. Son los mismos protocolos, preempaquetados, con la integración del lado del dispositivo ya en su lugar: integración de watchdog de hardware, flujo de partición A/B, verificación de paquetes firmados, instantáneas sincronizadas con el ciclo de vida, escalada determinista. Lo que se entrega es el proceso de puesta en marcha.
-
¿Cómo mantienen la página actualizada a medida que evoluciona la plataforma?
Cada afirmación en esta página enlaza a su documentación del micro service fuente; el CI falla en citas fuente obsoletas o faltantes. El catálogo de micro services es la fuente canónica de verdad; esta página es un índice navegable sobre él.
Opere su flota en MOS4.
Una llamada de descubrimiento de 30 minutos con ingeniería — revise su línea de costes del día 2 y vea qué pilares la reducen más.