Plataforma · Multi Stacks
Comunicación vehicular e IoT industrial, declarada como archivos de datos.
CAN, J1939, UDS, Modbus, ISOBUS — el mismo motor, un DSL, un runtime. Los stacks se ejecutan de forma concurrente en las mismas interfaces físicas con ciclos de vida independientes. Los cambios de protocolo son ediciones de JSON, no publicaciones de firmware.
Parte de la capa de motor no-code — configure el comportamiento del stack desde JSON, sin necesidad de recompilar. Orientado al desarrollador: DSL JSON completo mediante el SDK de MOS4.
El modelo declarativo
Cuatro elementos — un motor.
Cada despliegue de Multi Stacks, bus vehicular o IoT industrial, se declara como cuatro partes móviles. La estrategia periódica está disponible de fábrica; las secuencias avanzadas emergen al componer con MSP y MEP.
1 · Protocolo
El transporte y la trama — CAN, CAN-FD, J1939, ISO-TP, DoIP, UDS, K-Line, ISOBUS, Modbus RTU/TCP, CANopen. La selección es un campo JSON; no se necesita recompilación para agregar un transporte.
2 · Pregunta + Respuesta
Qué comando, PID, PGN o registro enviar y cómo decodificar la respuesta. Las expresiones de decodificación son en línea — bytes de entrada, señal nombrada de salida.
3 · Broadcast
Manejo de mensajes de solo lectura y no solicitados — escucha pasiva, decodificación de estilo evento sin una solicitud. El mismo JSON declara la decodificación para frames no solicitados.
4 · Estrategia
Qué secuencias ejecutar y cuándo. Periódica de fábrica. Controlada por señal mediante MSP, controlada por eventos mediante MEP — el resto de MOS4 suministra la estrategia avanzada sin salir del modelo declarativo.
Cobertura de protocolos
16 familias de protocolos en una API unificada.
| Protocolo | Transporte | Segmento típico |
|---|---|---|
| CAN Classical | CAN | Vehículos de pasajeros, VCL, maquinaria fuera de carretera |
| CAN-FD | CAN | Vehículos de pasajeros modernos, VE |
| ISO-TP | CAN segmentado | Capa de diagnóstico UDS |
| DoIP | Ethernet | Diagnóstico de ECU modernas |
| UDS | ISO-TP / DoIP | Servicios de diagnóstico unificado |
| OBD-II | ISO-TP / K-Line | Emisiones vehículos ligeros (ISO 15031) |
| OBFCM | OBD-II / UDS | Informe de consumo de combustible/energía UE (2021/392) |
| J1939 | CAN | Camiones de gran tonelaje, autobuses |
| J1587/J1708 | RS-485 | Gran tonelaje heredado |
| J1850 VPW/PWM | Monohilo | Pasajeros heredado (GM, Chrysler) |
| K-Line | ISO 9141-2 | Vehículos de pasajeros más antiguos |
| CANopen | CAN | Maquinaria industrial y fuera de carretera |
| ISOBUS | CAN (ISO 11783) | Implementos agrícolas (solo lectura) |
| Modbus RTU/TCP | RS-485 / Ethernet | Sensores industriales, grupos electrógenos, PLC |
| GMLAN | CAN | Vehículos de pasajeros GM heredado |
| TP 2.0 | CAN | Vehículos de pasajeros del grupo VAG |
Modbus ASCII es experimental — no se declara para uso en producción. ISOBUS es adquisición de solo lectura; la autoría de pantallas VT no está soportada.
Trae tu bus y mezcla de protocolos — adaptamos Multi Stacks.
Ejemplo práctico · vehículo (J1939)
Escenario dashcam de camión — carga del motor mediante J1939.
Un dashcam de flota de gran tonelaje necesita carga del motor y velocidad en carretera a 10 Hz, junto con lecturas de códigos de diagnóstico de averías bajo demanda. Todo esto es un único stack JSON.
Stack JSON mínimo para J1939
{
"ecu_id": "EngineECU",
"address": "0x00",
"commands": [
{
"name": "engine_load_pct",
"pgn": "0xF003",
"spn": 92,
"period_ms": 100,
"decode": "A * 100 / 255"
},
{
"name": "road_speed_kph",
"pgn": "0xFEF1",
"spn": 84,
"period_ms": 100,
"decode": "(A * 256 + B) / 256"
}
],
"dtc": { "service": "uds", "read": "0x19", "clear": "0x14" }
} Agregar un PGN, cambiar un período o conectar un nuevo servicio DTC es una edición de JSON y un commit. Sin recompilación, sin flasheo de firmware.
Ejemplo práctico · IoT industrial (Modbus)
Consulta de un PLC mediante Modbus RTU.
Los mismos cuatro elementos, diferente protocolo. Un controlador de grupo electrógeno de fábrica expone registros de entrada; un stack Modbus los consulta a 1 Hz, los decodifica como señales nombradas y emite un evento cuando se supera un umbral.
Stack JSON mínimo para Modbus
{
"device_id": "Genset-01",
"transport": "modbus_rtu",
"slave_id": 7,
"commands": [
{
"name": "coolant_temp_c",
"function": "read_input_registers",
"address": 30001,
"count": 1,
"period_ms": 1000,
"decode": "A / 10"
},
{
"name": "fuel_level_pct",
"function": "read_input_registers",
"address": 30002,
"count": 1,
"period_ms": 1000,
"decode": "A"
}
],
"broadcast": { "on_threshold": "fuel_level_pct < 10", "emit": "low_fuel" }
} Modbus RTU y Modbus TCP/MBAP comparten el mismo DSL. Cambiar de uno a otro es un único campo JSON.
Composición de estrategia
Multi Stacks impulsado por MSP o por MEP.
El elemento Estrategia es intencionalmente simple — periódico, con disparadores de broadcast opcionales. Las secuencias avanzadas emergen cuando MSP (controlado por señal) o MEP (controlado por eventos) es la estrategia.
MSP impulsa Multi Stacks (controlado por señal)
Un grafo MSP observa una señal decodificada — por ejemplo, la velocidad en carretera superando 80 kph — y dispara una solicitud de Multi Stacks (p. ej., lectura UDS de una instantánea de consumo de combustible). La respuesta fluye de vuelta a través del mismo stack.
Un grafo MSP monitorea un umbral de señal y dispara una solicitud UDS de Multi Stacks; la respuesta de Multi Stacks fluye de vuelta a MSP.
flowchart LR Sig[Grafo MSP<br/>umbral de señal] -->|disparar| MS[Multi Stacks<br/>enviar solicitud UDS] MS -->|respuesta| Sig
MEP impulsa Multi Stacks (controlado por eventos)
Una regla MEP se activa ante un evento nombrado (motor encendido, cruce de geocerca, descarga OTA completa) y ejecuta una secuencia de acciones de Multi Stacks — por ejemplo, borrar DTC después de una visita de servicio, o leer una instantánea de ECU de una sola vez.
Un evento de EventBus dispara una regla MEP, cuya acción ejecuta una secuencia de Multi Stacks.
flowchart LR Evt[EventBus<br/>evento nombrado] -->|disparar| MEP[Regla MEP] MEP -->|acción| MS[Multi Stacks<br/>ejecutar secuencia]
Modo multi-stack
N stacks · un conjunto de interfaces físicas.
Cada stack se ejecuta con un ciclo de vida independiente y una ruta de exportación en las mismas interfaces físicas. Múltiples stacks que comparten un bus no requieren un planificador — la API de protocolo unificada arbitra el acceso y aplica el aislamiento.
Tres stacks independientes comparten una API de protocolo unificada. El Stack A es un stack JSON OBD-II que lee PIDs de pasajero. El Stack B es un stack JSON J1939 que lee PGN de camión. El Stack C es un stack JSON Modbus que lee sensores RS-485. Los tres alimentan la API de protocolo unificada, que arbitra el acceso y aplica ciclos de vida independientes. El gestor distribuye a tres interfaces físicas — CAN0, CAN1 y RS-485 — sin conflictos de propiedad del bus. Cada stack exporta de forma independiente: el Stack A al tópico MQTT A, el Stack B al tópico MQTT B, el Stack C al motor de políticas.
flowchart TD S1[Stack A — JSON OBD-II<br/>PIDs de pasajero] S2[Stack B — JSON J1939<br/>PGN de camión] S3[Stack C — JSON Modbus<br/>sensores RS-485] V[API de protocolo unificado<br/>arbitraje · ciclos de vida] S1 --> V S2 --> V S3 --> V V --> Iface1[CAN0] V --> Iface2[CAN1] V --> Iface3[RS-485] S1 -->|exportar| MQ1[Tópico MQTT A] S2 -->|exportar| MQ2[Tópico MQTT B] S3 -->|exportar| MEP[Motor de políticas]
| Método | Cadencia | Descripción |
|---|---|---|
| SubscribeData | configurable | Valores de señal decodificados y nombrados para consumo de MSP y MEP |
| SubscribeBusLoad | ~1 Hz | Métricas de utilización CAN por interfaz física |
| SubscribeCanFrames | frecuencia de frame | Captura de frames brutos — flujo combinado de todos los stacks activos |
La captura de frames brutos fluye en tiempo real para consumo por MSP, el puente MQTT y el servicio de base de datos de MOS4.
Capacidades
Lo que se incluye de fábrica.
22 stacks por defecto validados en CI, manejo de DTC de grado producción, passthrough J2534-2 y resiliencia de circuit-breaker incorporada — todo disponible sin escribir un planificador ni gestionar el arbitraje de bus manualmente.
22 stacks por defecto validados en CI
OBD-II, UDS, J1939, ISOBUS, OBFCM, Modbus, CANopen y otros están incluidos y validados en cada push de CI mediante pruebas autónomas de Python/pytest. Agregue su propio stack como un archivo JSON junto a ellos.
Lectura + borrado de DTC
Los códigos de diagnóstico de averías se leen y borran en el stack compatible mediante el servicio OBD-II 03/04 o los servicios de información de diagnóstico UDS. Declarado en el JSON del stack — no se requiere código personalizado.
Passthrough J2534-2
Una API PassThru JSON/Protobuf con soporte de API extendida J2534-2 permite que las herramientas de diagnóstico y los flasheadores de ECU existentes alcancen el vehículo a través del mismo gateway — sin necesidad de un dongle J2534 dedicado.
Resiliencia de circuit-breaker
Tras fallos de comunicación repetidos con una ECU específica, ese stack retrocede automáticamente e informa su estado de salud al controlador en la nube. Otros stacks en el mismo gateway continúan ejecutándose normalmente — sin tormenta de reintentos, sin fallo en cascada.
Identificación + push de stack OE
El stack correcto para cada vehículo, automáticamente.
Antes de que comience cualquier consulta, el runtime identifica el vehículo y selecciona el stack OE apropiado para cargar. El stack OE enviado estandariza los datos — nombre, formato, unidades y frecuencia — en DTC OE, telemetría del panel y otras superficies de datos OE.
Identificación por VIN
El VIN se lee del vehículo durante la conexión. El runtime lo mapea a la definición de stack OE correspondiente y la carga antes de que comience el primer ciclo de consulta. Sin configuración manual a nivel de vehículo.
Lógica de identificación
Cuando el VIN solo es insuficiente, la lógica de identificación personalizada — declarada en la configuración del stack — maneja casos límite: variantes de vehículos, retrofits o configuraciones de flota mixta. El resultado es siempre una selección de stack.
Configuración por vehículo
La identificación también puede estar impulsada por una configuración por vehículo enviada desde la nube. Esto admite flotas donde la resolución basada en VIN no está disponible o es anulada por asignación del operador.
Este proceso de identificación es autónomo — el dispositivo resuelve el stack correcto localmente a partir del resultado de identificación, sin necesidad de un round-trip a la nube para el funcionamiento rutinario. La nube envía la definición del stack OE una vez; el dispositivo la aplica en cada conexión.
Los clientes pueden extender el catálogo de stacks con sus propios stacks — comprados, de propiedad intelectual propia o de ingeniería inversa — usando su propia lógica de identificación. Los stacks personalizados tienen alcance solo a su flota; coexisten junto a los stacks OE por defecto sin conflictos.
Para diagnóstico remoto impulsado desde la nube — donde un humano o una IA es el maestro en lugar del dispositivo — consulte a nuestro equipo de ingeniería sobre la superficie de diagnóstico remoto.
Dónde encaja
Un pilar de la capa de operaciones.
El diagnóstico remoto es uno de los cinco pilares de la capa de operaciones — junto con observabilidad, seguridad, OTA y ciclo de vida. Lea el conjunto completo en /es/platform/operations.
Simulación de ECU
Pruebas sin hardware en vcan.
mos-mes simula una o más ECU en CAN virtual o DoIP y responde a UDS, OBD-II e ISO-TP
con estrategias de señal configurables: constante, rampa, seno, aleatoria o tabla de búsqueda. Los
pipelines de CI ejecutan suites de regresión UDS/OBD-II completas sin banco físico.
La CLI autónoma ejecuta load-stack, validate-stack y un REPL interactivo
sin dependencia del runtime de MOS4. Ideal para integrar la validación de stacks en su propio pipeline
de CI.
Soporte de lenguajes
Seis lenguajes para extensiones de stack.
Los clientes pueden extender el comportamiento del stack — lógica de identificación personalizada, transformaciones de señales y manejadores de acciones — usando cualquiera de seis lenguajes. Lua 5.4 es la opción de scripting con menor barrera de entrada: no se requiere cadena de herramientas Rust.
Rust
Autoría nativa de micro services. Seguridad de tipos completa, integración EventBus de copia cero.
Python
Scripting y cargas de trabajo de ciencia de datos. Validación de stacks en CI basada en Pytest sin hardware.
C / C++
Bases de código embebido existentes y SDK de proveedores. El aislamiento por contenedor aplica el mismo presupuesto de recursos.
Go
Micro servicios orientados a red y adaptadores de gateway. Entrega estándar de contenedor OCI.
JavaScript / TypeScript
Micro servicios de UI, dashboards web y scripting de acciones MEP.
Lua 5.4
Opción de scripting con menor barrera. Extienda el comportamiento del stack sin cadena de herramientas Rust. Manejadores de acciones recargables en caliente a través del servicio de configuración.
Preguntas frecuentes
Preguntas habituales
-
¿Multi Stacks es lo mismo que OBDStacks?
Sí. OBDStacks es el nombre heredado; Multi Stacks es el nombre canónico desde el 2026-05-05. El mismo motor, el mismo DSL JSON, el mismo catálogo default-stacks/.
-
¿Cuántos protocolos admite el runtime de forma simultánea?
Hasta 16 familias de protocolos comparten una API de protocolo unificada. Múltiples stacks se ejecutan de forma concurrente con ciclos de vida independientes y rutas de exportación en las mismas interfaces físicas.
-
¿Qué es un stack declarativo?
Un stack es un archivo de datos JSON que especifica ECUs, Commands, Actions, Exports, Conditions y Expressions. Actualizar un PID, cambiar un período de muestreo o ajustar una política de respuesta es una edición de JSON y un commit — no una publicación de firmware.
-
¿Funciona Modbus ASCII en producción?
Modbus ASCII es una característica experimental — no dependa de ella para despliegues en producción. Modbus RTU (RS-485) y Modbus TCP/MBAP son ambos listos para producción.
-
¿Puedo probar un stack sin hardware ECU real?
Sí. mos-mes simula una o más ECU en una interfaz CAN virtual y responde a UDS, OBD-II e ISO-TP con estrategias de señal configurables. Los pipelines de CI ejecutan suites de regresión completas en vcan sin banco físico.
-
¿Qué cubre el soporte de DTC?
Lectura y borrado de DTC en el stack compatible — mediante el servicio OBD-II 03/04 o los servicios de información de diagnóstico UDS.
-
¿Cómo se compone Multi Stacks con MSP y MEP?
Una "Strategy" de Multi Stacks es periódica de forma predeterminada. Para secuencias controladas por señal, un grafo MSP publica un disparador y Multi Stacks envía la solicitud correspondiente. Para secuencias controladas por eventos, una regla MEP se activa ante un evento nombrado y ejecuta una acción de Multi Stacks. Ambas composiciones permanecen declarativas.
Traiga su matriz de protocolos.
Liste las familias de activos que despliega; le emparejamos con los stacks correctos y mostramos la configuración de ciclo de vida concurrente en un dispositivo de desarrollo.