Plataforma · Conectividad
Del módem a la nube, tipado en todo el camino.
Todos los principales módems 2G–5G + LPWA, backend WiFi detectado en tiempo de ejecución, rol central BLE, servidor y cliente DHCP por interfaz, enlace multiprocotolo a la nube y un resolutor DNS SRV mínimo — cada capa tipada, observable y configurada por datos.
Métricas clave
Los números que dimensionan la pila.
Celular
Todos los principales módems — capacidad primero.
Todos los principales tipos de módem, 2G → 5G + LPWA
La pila de módem carga librerías de proveedor en tiempo de ejecución. La cobertura abarca 2G, 3G, 4G LTE, 5G, Cat-M1 (LTE-M) y NB-IoT — IPv4 e IPv6. Agregar un nuevo módulo celular es un intercambio de librería más una actualización de configuración — sin recompilación del micro service.
eUICC Consumer + eUICC M2M en carcasas selladas
Gestión de perfiles eUICC GSMA SGP.22 v2.2: descarga, habilitación, deshabilitación, eliminación y recuperación — sin un micro service de gestión eUICC separado. Compilado condicionalmente — no añade sobrecarga en las compilaciones con SIM física. El mismo binario se envía a ambas variantes de hardware.
Enrutamiento IP y NAT
El enrutamiento IP, NAT/MASQUERADE y el reenvío IP son gestionados por el micro service
de módem a través de RoutingService — no es un micro service separado.
Gestión térmica definida por software
Para módulos sin zonas térmicas a nivel de firmware, sondeo desde el host con acciones graduadas: registro → reducción de MTU → radio apagada → apagado.
WiFi
WiFi — backend dual, un binario.
El micro service WiFi lee el device tree en el arranque y selecciona el backend sin ninguna
bandera en tiempo de compilación. Los modos AP y STA se cambian en tiempo de ejecución
mediante SetMode .
| Backend | Modos | Bandas de frecuencia | ScanNetworks |
|---|---|---|---|
| AP+STA doble banda | AP + STA | 2,4 GHz + 5 GHz | Sí |
| AP+STA 2,4 GHz | AP + STA | 2,4 GHz | No soportado |
En plataformas donde WiFi y BT comparten un rail de alimentación de radio, el micro service Bluetooth se suscribe a los eventos de energía y suspende/reanuda el adaptador BT automáticamente. Los consumidores BLE no necesitan conocer la coexistencia con WiFi.
Auto-recuperación de 3 niveles
Escalada: L1 reinicio de software → L2 ciclo de radio rfkill → L3 reinicio completo del micro service. Cuando se agota L3, el micro service deja de alimentar el watchdog de MOS, lo que activa la recuperación del supervisor.
WifiService de 7 métodos
SetMode, GetStatus, GetConnectedStations, StreamEvents, GetConfig, UpdateConfig, ScanNetworks — todos tipados sobre el plano de transporte de MOS4.
Reconfiguración en tiempo de ejecución
UpdateConfig reconfigura un AP en ejecución sin parar/reiniciar. SetMode cambia AP↔STA en tiempo de ejecución. Configuración no-code mediante
política TOML. Ver motores no-code para la política de conectividad
impulsada por TOML.
Bluetooth
Bluetooth — rol central BLE, multichip.
Todas las principales familias Bluetooth
Familia del chip autodetectada desde el device tree en el arranque. Se admiten múltiples familias Bluetooth — variantes integradas de clase compute y coprocesadores de la familia Wi-Fi. BT clásico y BLE ambos disponibles.
Wake-on-BT (coprocesador de la familia Wi-Fi)
En chips coprocesadores de la familia Wi-Fi, la entrada en reposo cambia a un modo BLE interno. Una escritura BLE a la característica de activación dispara el pin de activación; el host recibe un evento de activación en el bus de eventos — sin sondeo.
DHCP
Servidor y cliente DHCP por interfaz.
Las instancias de servidor y cliente DHCP se ejecutan de forma independiente en cualquier número de interfaces de red simultáneamente — servidor del AP WiFi, cliente Ethernet de upstream e interfaz de diagnóstico en el mismo dispositivo al mismo tiempo.
Rol por interfaz
Asigne el rol de servidor o cliente de forma independiente por interfaz. La interfaz del AP WiFi ejecuta un servidor DHCP; la interfaz Ethernet de upstream ejecuta un cliente; la interfaz de diagnóstico sirve su propio pool de arrendamientos — todo simultáneamente.
8 métodos RPC
Superficie de API completa tipada: iniciar/detener servidor y cliente, actualizar configuración del servidor, consultar estado de arrendamiento y transmitir eventos — todo accesible sin comandos de shell ni reinicios de archivos de configuración.
Reconfiguración en tiempo de ejecución + persistencia de arrendamientos
UpdateServerConfig reconfigura un servidor DHCP en ejecución sin parar/reiniciar.
El estado de arrendamiento persiste entre reinicios del micro service a través del Database
Service.
Enlace a la nube
Enlace multiprocotolo a la nube.
El gateway de comunicación selecciona y enruta los datos de seguimiento a uno o más protocolos de nube simultáneamente. MDI21, MQTT TR50, MQTT Munic y MQTT genérico están todos disponibles — las políticas de enrutamiento por pista determinan qué protocolo lleva cada flujo de datos.
Protocolo binario MDI21
La codificación ASN.1 UPER minimiza el tamaño del payload en planes celulares limitados. Las marcas de tiempo relativas y los IDs de mensaje compactos comprimen las cabeceras por paquete. Las políticas de registro por campo (OnChange, Periodic, PeriodicOnChange, Manual) ajustan las compensaciones entre ancho de banda y batería. TCP/TLS persistente con reintento respaldado por PDM en la desconexión.
MQTT TR50
Entrega de esquema JSON TR50 de grado producción sobre MQTT a plataformas en la nube compatibles con TR50. Configurado junto con otros protocolos mediante la tabla de enrutamiento; el acuse de recibo se rastrea por protocolo para que un reintento apunte solo al protocolo que aún no ha confirmado.
MQTT Munic
Entrega de grado producción en el esquema de tópicos de Munic sobre MQTT hacia despliegues de la plataforma cloud de Munic. Comparte la misma infraestructura de enrutamiento por pista y reintento que todos los demás protocolos.
MQTT genérico
MQTT genérico de grado producción — cualquier cliente MQTT estándar alcanza los servicios MOS4 a través del broker MQTT en proceso, sin adopción del SDK. Los payloads JSON se transcodifican en la entrada; un catálogo de servicios retenido permite a los clientes descubrir los servicios disponibles en el momento de la conexión. Ver SDK para el patrón de integración del desarrollador.
Los protocolos se enrutan por ID de pista. Una pista puede distribuirse a múltiples protocolos simultáneamente; la retransmisión apunta solo a los protocolos que aún no han confirmado. Ver el catálogo completo para el micro service de gateway de comunicación.
DNS
Resolutor SRV mínimo.
Un resolutor DNS ligero gestiona los registros SRV (RFC 2782) con seguimiento A/AAAA. Lee /etc/resolv.conf en cada llamada — por lo que los cambios de nameserver debidos
a la renovación de DHCP o la activación del módem se detectan sin reinicio del proceso.
Durante la activación del módem, antes de que se configure un nameserver, el resolutor devuelve un error tipado para que los llamadores implementen una lógica de reintento correcta en lugar de fallar silenciosamente. La implementación es intencionalmente mínima — sin dependencia ICU/IDNA — lo que mantiene bajo el footprint del binario en hardware de clase módem.
Puente MQTT
Broker MQTT en proceso — cualquier cliente estándar alcanza MOS4.
Un broker MQTT se ejecuta en proceso — sin proceso externo. Transcodifica JSON al formato de llamada tipada en la entrada. Cualquier cliente Python, Go, C o C embebido puede llamar a cualquier servicio MOS4 sin adoptar el SDK de MOS4 ni los archivos .proto.
Broker embebido
Se ejecuta en proceso. Sin proceso de broker externo. Sin dependencia de infraestructura adicional.
Descubrimiento de servicios
Publica un catálogo de servicios retenido en la conexión. Los clientes enumeran los servicios disponibles sin configuración fuera de banda.
Todos los tipos de llamada de servicio
Enruta a llamadas unarias, llamadas de streaming de servidor y suscripciones al bus de eventos. Tipo de contenido dual: JSON y binario tipado en el mismo espacio de nombres de tópicos. Ver SDK para ejemplos de cliente.
Preguntas frecuentes
Preguntas habituales
-
¿Las herramientas MQTT existentes funcionan con los servicios MOS4?
Sí. MOS4 embebe un broker MQTT en proceso — sin proceso externo. Transcodifica los payloads JSON al formato tipado en la entrada y enruta a cualquier servicio MOS4 como una llamada unaria, una llamada de streaming de servidor o una suscripción al bus de eventos. Cualquier cliente MQTT estándar funciona sin adoptar el SDK de MOS4.
-
¿Qué estándares celulares son compatibles?
Todos los principales estándares celulares — 2G, 3G, 4G LTE, 5G, Cat-M1 (LTE-M) y NB-IoT — son compatibles mediante librerías de proveedor cargadas en tiempo de ejecución. Agregar un nuevo módulo celular requiere una librería de proveedor correspondiente y una actualización de configuración — sin recompilación del micro service.
-
¿Cómo funciona la selección del backend WiFi?
El micro service WiFi lee el device tree en el arranque y selecciona la ruta hostapd de doble banda o la ruta esp-control de 2,4 GHz sin ninguna bandera en tiempo de compilación. El mismo binario se ejecuta en ambas variantes de hardware.
-
¿Se admite eSIM en carcasas selladas?
Sí. La pila de módem implementa la gestión de perfiles eUICC (GSMA SGP.22 v2.2 Consumer; GSMA SGP.02 M2M) para descarga, habilitación, deshabilitación, eliminación y recuperación de perfiles eUICC. Compilado condicionalmente — no añade sobrecarga en las compilaciones con SIM física.
-
¿Cómo funciona la detección del chip BLE?
El micro service Bluetooth autodetecta la familia del chip desde el device tree en el arranque. Se admiten múltiples familias Bluetooth — chips integrados de clase compute y variantes de coprocesador de la familia Wi-Fi — sin recompilación.
-
¿Qué versión MQTT usa el broker en proceso?
La versión MQTT no se divulga públicamente. El broker presenta una superficie MQTT estándar — cualquier cliente MQTT estándar se conecta sin adopción del SDK.
Traiga su plan de conectividad de flota.
Ingeniería le guiará a través de la selección de módems, la coexistencia WiFi, la selección del protocolo de enlace a la nube y la integración del puente MQTT para su hardware objetivo.