Plataforma · Motores no-code
Cuatro motores no-code. Cero archivos Rust.
MSP para grafos de procesamiento de señales continuo. MEP para políticas de máquina de estados (primitivas T·C·A bajo el capó). Multi Stacks para comunicación vehicular e IoT industrial. AI Funnel para IA de borde declarativa. Los cuatro son testables fuera del objetivo sin hardware en el bucle.
Comparación de motores
Cuatro motores · una plataforma.
| Dimensión | MSP | MEP | Multi Stacks | AI Funnel |
|---|---|---|---|---|
| Modelo | Grafo de flujo de datos tipado con nodos y aristas | Máquina de estados mediante reglas T·C·A | Protocolo / P+R / Broadcast / Estrategia | Grafo TOML + ONNX/TFLite + dataset |
| Ejecución | Continua, siempre activa | Controlada por eventos, reactiva | Periódica + compuesta (MSP/MEP) | Cámara → GPU → NPU en el dispositivo |
| Autoría | Grafo YAML + editor Streamlit en navegador | Política YAML + diseñador visual de políticas | JSON de stack + catálogo default-stacks/ | Grafo TOML + pipeline de reentrenamiento en nube |
| Validación fuera del objetivo | CLI msp-run con entradas CSV (macOS) | Ejecutor msp-standalone + mep-lint | Simulador de ECU sobre CAN virtual | Fakes de runtime AI + shader ROI GPU |
| Recarga en caliente | Llamada de servicio LoadGraph, sin reflash | Política intercambiada en vuelo, sin reinicio | Edición de JSON de stack + commit | Canal OTA — igual que el OTA de código |
| Catálogo | 226 grafos · 21 dominios vehiculares | 3 tipos de trigger · 5 tipos de acción | 16 familias de protocolos · 22 stacks por defecto | Modelo del cliente + dataset COCO |
MEP — políticas de máquina de estados (T·C·A bajo el capó)
Automatización de políticas sin código procedural.
El responsable de producto lee MEP como políticas de máquina de estados en el dispositivo. El ingeniero lee el mismo YAML como primitivas Trigger / Condition / Action. El nuevo YAML de política se valida e intercambia con agotamiento de reglas en vuelo — sin reinicio del proceso, sin reinicio del dispositivo.
Tres tipos de trigger
| Trigger | Ejemplo | Uso típico |
|---|---|---|
| Cambio en clave DB | vehicle.speed supera 90 km/h | Alertas de umbral, cambios de frecuencia de muestreo |
| Evento nombrado | sos.button.pressed | Reenvío de interrupciones de hardware, eventos de micro service |
| Cron / periódico / una sola vez | cada 15 min, UTC | Informes programados, heartbeats |
Acción call_interface
La acción action call_interface despacha a MSP, Multi Stacks, cualquier
driver personalizado o cualquier micro service a través de un proxy con verificación de tipo,
validación de versión semver y un timeout configurable (por defecto 3 000 ms). Las dependencias
de micro service se declaran con rangos semver y degradan de forma elegante en tiempo de ejecución.
Un diseñador visual de políticas genera YAML válido a partir de un grafo de nodos y
autodescubre las declaraciones requires para ingenieros que prefieren una superficie
de autoría visual. El mismo diseñador renderiza el diagrama de estados para revisión de producto.
MSP — Flujo de datos continuo
226 grafos. 21 dominios. Presupuesto de CPU de un solo dígito porcentual.
Editor en navegador con 124 kernels
Un canvas en navegador lista los 124 tipos de kernel, valida la estructura del grafo contra el esquema JSON en tiempo real y exporta el .msp.yml que el runtime lee directamente.
Inyección en runtime sobre MQTT
Envíe nuevos grafos a un dispositivo en ejecución sobre MQTT sin actualización de firmware. El catálogo de 21 dominios — accidente, batería EV, combustible, GNSS, flota, carretera y más — proporciona un punto de partida para telemetría vehicular sin autoría desde cero.
Multi Stacks — Comunicación vehicular + IoT industrial
Cuatro elementos por stack. 16 familias de protocolos.
Cada despliegue de Multi Stacks, bus vehicular o IoT Modbus, declara cuatro partes móviles: Protocolo, Pregunta + Respuesta, Broadcast, Estrategia. Los stacks son archivos de datos JSON; los cambios de protocolo son ediciones de JSON.
22 stacks por defecto incluidos con el SO
OBD-II, UDS, J1939, ISOBUS, OBFCM, Modbus RTU/TCP, CANopen — validados en cada push de CI mediante pruebas autónomas de Python/pytest. Los nuevos stacks viven en control de versiones, no en compilaciones de firmware.
Se compone con MSP y MEP
Estrategia periódica de fábrica. Secuencias controladas por señal mediante MSP (un grafo dispara una solicitud UDS); secuencias controladas por eventos mediante MEP (una regla se activa ante un evento nombrado y ejecuta una acción de stack). La estrategia avanzada permanece declarativa.
AI Funnel — IA de borde declarativa
TOML de entrada. OTA de salida. Sin toolchain en el dispositivo.
El cliente entrega un grafo TOML más un modelo ONNX/TFLite y un dataset COCO. La nube de Munic reentrena, cuantiza, valida, empaqueta y realiza OTA. El runtime en el dispositivo ejecuta cámara → GPU → NPU con cero copia de píxeles.
Mismo canal OTA que el código
Un reentrenamiento de modelo se distribuye a través del mismo canal OTA que una actualización de micro service — despliegue escalonado, fijación de versiones, rollback de flota, todo unificado entre código y modelos.
Cero lecturas de píxeles en CPU
La GPU recorta y reescala la región de interés; el runtime AI impulsa la NPU. Cámara, GPU y NPU comparten memoria directamente — el handle se mueve, los datos de píxeles permanecen en su lugar. El detalle del runtime es la prueba de que el modelo declarativo es real.
Validación fuera del objetivo
Pruebas a nivel de CI sin dispositivo — en los cuatro motores.
| Herramienta | Motor | Qué detecta |
|---|---|---|
| msp-run | MSP | Ejecución del grafo contra entrada CSV en macOS, sin necesidad de dispositivo |
| mep-standalone | MEP | Reproducción completa de política con archivos de escenario YAML |
| mep-lint | MEP | Errores de esquema, claves DB indefinidas, grafos de reglas cíclicos, errores de tipo en expresiones |
| Simulador de ECU | Multi Stacks | Simulación de ECU sobre CAN virtual — suites de regresión UDS, OBD-II, ISO-TP sin banco físico |
| Fake de runtime AI | AI Funnel | Stub de inferencia para CI; sin hardware NPU requerido |
Cada motor no-code tiene un ejecutor fuera del objetivo. Se requiere un formato YAML/JSON/TOML correcto y un contrato de datos — estas herramientas validan la superficie de configuración, no la integración de hardware.
Fuera de la caja, juntos
Un contenedor Python impulsa los cuatro motores.
Los cuatro motores no son silos. Un único contenedor Python, hablando con el broker MQTT en proceso, puede impulsar MSP, MEP, Multi Stacks y AI Funnel desde un proceso — sin toolchain Rust, sin SDK por motor, sin pegamento personalizado.
MSP · enviar un grafo
c.publish(
"mos/msp/LoadGraph",
json.dumps({"name": "harsh_brake", "yaml": yaml_str}),
)MEP · cargar una política
c.publish(
"mos/mep/LoadPolicy",
json.dumps({"name": "geofence", "yaml": policy_str}),
)Multi Stacks · cargar un stack
c.publish(
"mos/multi-stacks/LoadStack",
json.dumps({"name": "j1939_truck", "json": stack_json}),
)AI Funnel · suscribirse a detecciones
c.subscribe("mos/ai-runtime/detections")
c.on_message = lambda _c, _u, m: handle(m.payload)Mismo cliente MQTT, cuatro motores, sin límite de lenguaje. Cualquier runtime capaz de MQTT — C, C++, Go, Rust, JavaScript — puede hacer lo mismo.
Cuando no-code no es suficiente
Tres niveles de programación diseñados para coexistir.
Un producto MOS4 típico combina MSP para procesamiento de señales continuo, MEP para política de máquina de estados, Multi Stacks para comunicaciones vehiculares o Modbus, AI Funnel para IA de borde, un micro service Rust personalizado para el algoritmo genuinamente novedoso, y un contenedor Python o C++ para el clasificador del equipo de ciencia de datos.
Los cuatro motores no-code comparten un registro y runtime con cada micro service Rust y de contenedor en el dispositivo. Ver arquitectura de plataforma para ver cómo encajan los motores, y micro services para la capa de conexión a la nube e integración más allá del dispositivo.
Ver el SDK completo →Preguntas frecuentes
Preguntas habituales
-
¿Cómo encajan los cuatro motores entre sí?
MSP produce señales nombradas continuas a partir de entradas de sensores y buses. MEP reacciona a disparadores discretos (umbral de señal, evento, cron) con políticas de máquina de estados. Multi Stacks se comunica con buses vehiculares y dispositivos IoT industriales, impulsado periódicamente o compuesto con MSP/MEP. AI Funnel ejecuta IA de borde declarativa — un grafo TOML más un modelo y dataset; la nube de Munic reentrena y realiza OTA. Los cuatro motores comparten un SO, un canal OTA y una historia fuera del objetivo.
-
¿MEP es una máquina de estados o un motor T·C·A?
Ambas lecturas se incluyen. El responsable de producto lee MEP como políticas de máquina de estados en el dispositivo — el YAML de política es la máquina de estados. El ingeniero lee el mismo YAML como primitivas Trigger / Condition / Action. No hay un runtime de máquina de estados separado; el conjunto de reglas compuestas es la máquina de estados.
-
¿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. Mismo motor, mismo DSL JSON, mismo catálogo default-stacks/.
-
¿Necesito hardware para probar una política o un grafo?
No. El ejecutor autónomo MEP reproduce archivos de escenario YAML fuera del objetivo; la herramienta de lint MEP detecta errores estáticamente. El ejecutor MSP ejecuta cualquier .msp.yml con entradas CSV en macOS. El simulador de ECU incluido cubre Multi Stacks sobre CAN virtual. El fake de runtime AI provee stubs de inferencia para el CI de AI Funnel. Los cuatro motores tienen ejecutores fuera del objetivo a nivel de CI.
-
¿Alguno de esto requiere Rust?
No. Los cuatro motores se configuran con YAML, JSON y TOML. El runtime es Rust, pero la superficie de autoría son archivos de datos. Un contenedor Python puede impulsar cualquiera de los motores a través del broker MQTT en proceso — vea "Fuera de la caja, juntos" más abajo.
-
¿Cuándo aplica la ruta del SDK?
Cuando el algoritmo genuinamente no puede expresarse como un grafo, una política, un stack o un grafo AI TOML. Lógica de detección novedosa, inferencia de modelos propietarios, integración de hardware personalizado. Los cuatro motores no-code cubren la mayor parte de la superficie de comportamiento del dispositivo; los micro services Rust, los contenedores Python y los contenedores C++ cubren el resto.
Traiga un YAML, un JSON o un TOML.
Muéstrenos el comportamiento del dispositivo, el protocolo, la extracción de señales o la tarea de inferencia; le asignaremos el motor correcto en un dispositivo de desarrollo.