Plataforma · MEP
40 reglas. 40 entradas YAML. Cero archivos Rust.
MEP ejecuta políticas Trigger → Condition → Action en el dispositivo. Diseñe en un editor visual, exporte como YAML, recargue en caliente sin reflash. Automatización del dispositivo sin un desarrollador Rust en el proceso.
Políticas de máquina de estados para el responsable de producto. Primitivas T·C·A para el ingeniero. Un archivo YAML, dos lecturas.
Modelo de política
Trigger → Condition → Action. Nada más.
Cada regla tiene exactamente tres partes. No existe un modelo de ejecución más allá de este constructo.
Trigger
Qué inicia la regla
- ·
on_change— cambio en clave DB - ·
on_event— evento nombrado desde cualquier micro service - ·
on_schedule— delay, periódico o cron (solo UTC)
Condition
Filtro opcional
Expresión evaluada contra el estado de DB y el payload del evento. Se verifica el tipo antes del despliegue — los errores aparecen en CI, no en el dispositivo.
Action
Qué se ejecuta
- ·
set— escribir una clave DB - ·
emit— publicar un evento - ·
call_interface— llamar a cualquier micro service de MOS4 - ·
schedule— disparar otra regla
YAML es el artefacto de despliegue
Sin Rust. Sin reconstrucción de firmware. Sin reflash.
Una regla de automatización de dispositivo vive en un archivo .yaml. Cambiarla es editar YAML y enviar la política actualizada — mediante OTA o una llamada de servicio directa. La recarga en caliente agota las reglas en vuelo e intercambia atómicamente el grafo de política.
La política declara dependencias
Cada archivo de política lleva una lista requires: con rangos semver. El motor
valida la restricción en el momento de cargar la política — no en tiempo de ejecución en la
primera llamada. Las dependencias opcionales degradan de forma elegante.
Ejecución paralela con detección de conflictos
Múltiples reglas que coinciden en el mismo ciclo se ejecutan en paralelo mediante un pool de trabajadores acotado. Cuando dos reglas escriben la misma clave DB, MEP lo detecta y descarta la escritura de menor prioridad — sin corrupción de datos silenciosa.
Auditoría de flota
Consulte cualquier dispositivo para obtener nombres de políticas cargadas, versiones y recuentos de reglas — auditable sin acceso SSH.
Superficie de autoría
Un editor basado en nodos que exporta YAML.
requires:
a partir de los nodos usados en el grafo.
MEP es uno de los cuatro motores de autoría visual de la capa no-code de MOS4, junto al editor de grafo de señales, el constructor de pipeline AI y la vista de configuración multi-stack.
Dos vistas, un archivo
Máquina de estados para el responsable de producto. T·C·A para el ingeniero.
La misma política de geocerca se lee como una máquina de tres estados en el diseñador y como tres reglas YAML T·C·A en la vista de ingeniería. El archivo YAML es la máquina de estados — no hay un runtime separado.
Vista de producto — diagrama de estados
Tres estados: fuera del polígono, aproximándose al límite, dentro. El responsable de producto lee el diagrama; el dispositivo ejecuta la política.
Máquina de estados de geocerca — tres estados (fuera, aproximándose, dentro) con transiciones en eventos de entrada, cercanía y salida. El mismo diagrama se genera a partir del YAML siguiente.
stateDiagram-v2 [*] --> outside outside --> approaching: near approaching --> inside: enter approaching --> outside: exit inside --> approaching: near inside --> outside: exit
Vista de ingeniero — tres reglas T·C·A
La misma política como tres reglas YAML. Cada transición es una triple Trigger / Condition / Action. El conjunto de reglas compuestas es la máquina de estados anterior.
rules:
- name: enter_geofence
on_event: geofence.near
when: state == "approaching"
do:
- set: { state: "inside" }
- emit: geofence.entered
- name: leave_geofence
on_event: geofence.exit
do:
- set: { state: "outside" }
- emit: geofence.left
- name: approach_geofence
on_change: distance_m
when: distance_m < 50 and state == "outside"
do:
- set: { state: "approaching" }El diseñador visual renderiza el diagrama de estados a partir del YAML; el YAML permanece como artefacto de despliegue. Agregar un estado es agregar una regla — el diagrama se actualiza automáticamente.
Validación previa al despliegue
Errores en CI, no en el dispositivo.
| Verificación | Qué detecta | Cuándo se ejecuta |
|---|---|---|
| Claves DB indefinidas | Errores tipográficos en claves y declaraciones faltantes | CI / pre-despliegue |
| Declaraciones requires: faltantes | Dependencias de micro service faltantes | CI / pre-despliegue |
| Grafos de reglas cíclicos | Bucles de disparo infinitos | CI / pre-despliegue |
| Condiciones inalcanzables | Ramas de regla muertas | CI / pre-despliegue |
| Errores de tipo en expresiones | Incompatibilidades de tipo en condiciones/acciones | CI / pre-despliegue |
Un ejecutor de escenarios autónomo reproduce archivos YAML fuera del objetivo en pipelines de CI. Un doble de prueba del motor de políticas permite la prueba completa de evaluación de políticas sin una pila MOS4 en hardware.
Reglas de ejemplo
Lo que los integradores despliegan.
Entrada y salida de geocerca
Disparar un evento en la nube y un zumbador cuando un vehículo cruza un polígono — escrito una vez, desplegado en toda la flota.
Detección de frenada brusca
Escuchar una señal de desaceleración derivada de MSP; si una ventana de 1,5 segundos coincide, elevar un evento con un pre-roll de 5 segundos.
Ralentí con motor apagado
Verificación periódica de RPM y estado de encendido; ante una violación de N minutos, atenuar el panel y abrir un ticket de mantenimiento.
Cobertura de despliegue
MEP se incluye en los seis escenarios de despliegue.
Las políticas de máquina de estados y control de LED se encuentran entre las capacidades de mayor cobertura en la matriz de características de MOS4 — disponibles desde factores de forma de dongle ligero hasta plataformas gateway de clase compute.
IOT Hub
Las políticas de trigger-action enrutan eventos de sensores a endpoints en la nube y controlan salidas del dispositivo — sin código de pegamento por regla.
Agricultura
El procesamiento de eventos basado en reglas coordina el estado de la maquinaria de campo: zonas de geocerca, conexión/desconexión de implementos y ventanas de programación.
Dashcam
Las políticas de eventos bruscos disparan el marcado de clips y la carga en la nube; los patrones de LED confirman el estado de grabación al conductor.
Dongle OBD
Las reglas de trigger-action ligeras reaccionan a señales OBD — detección de ralentí, presencia de DTC, secuencias de apagado — dentro de un footprint limitado.
C4Max
Las políticas de composición multi-stack orquestan el enrutamiento de datos entre dominios vehiculares; MEP impulsa secuencias controladas por eventos entre capas de señal.
Ekko Drive
Las políticas de comportamiento del conductor evalúan señales derivadas de MSP y emiten eventos puntuados; las reglas cron agregan datos de sesión para informes en la nube.
Las políticas MEP se componen con la capa multi-stack para secuencias de enrutamiento de datos controladas por eventos. Ver Multi Stacks para la composición de estrategia entre stacks.
Catálogo de nodos
58 tipos de nodo en tres categorías.
10 triggers · 17 conditions · 31 actions — derivados en tiempo de compilación del esquema del motor. Cada nodo está disponible en el diseñador visual y en YAML escrito manualmente.
Triggers (10)
-
on init -
on event -
on db changed -
on schedule -
on periodic -
on cron -
on rule -
on message -
any -
stt listen
Conditions (17)
-
comparison -
and -
or -
not -
has changed -
time since changed -
time since triggered -
is type -
matches -
in range -
contains -
is null -
time since applied -
time since condition true -
value -
rag confidence gate -
confidence gate
Actions (31)
-
set -
write db -
emit event -
call interface -
if else -
for each -
schedule -
unschedule -
trace -
set led -
sequence -
set output -
set buzzer -
read input -
read analog -
get ignition -
send message -
go to idle -
shutdown -
reboot -
register operation -
complete operation -
tts announce -
tts announce stream -
llm reason -
llm reason stream -
rag lookup -
tool call with confirm -
input sanitize -
observer log -
llm cloud fallback
Construya con acciones call_interface para alcanzar MSP, motores de inferencia y drivers
personalizados desde cualquier regla de política. Consulte el SDK
para crear micro services que MEP pueda llamar.
Preguntas frecuentes
Preguntas habituales
-
¿Necesito un desarrollador Rust para cambiar una regla después del despliegue?
No. Cambiar una regla es editar YAML y enviar la política actualizada — mediante OTA o una llamada de servicio directa. Sin toolchain Rust, sin reconstrucción de firmware, sin reflash. La recarga en caliente agota las reglas en vuelo e intercambia atómicamente el grafo de política.
-
¿Cuál es exactamente el modelo de política?
Cada regla tiene exactamente tres partes: un trigger (on_change, on_event u on_schedule — delay/periódico/cron en UTC); una condición opcional (expresión contra el estado de DB y el payload del evento); y una o más acciones (establecer una clave DB, emitir un evento, call_interface, o programar otra regla). No existe un modelo de ejecución más allá de este constructo.
-
¿MEP es una máquina de estados finitos?
Las reglas MEP expresan comportamiento de tipo máquina de estados mediante primitivas T·C·A. El YAML de política es la máquina de estados — no hay un runtime de máquina de estados separado. T·C·A es la primitiva de regla; el conjunto de reglas compuestas es la máquina de estados. Ambas lecturas se incluyen — el diseñador visual renderiza el diagrama de estados para los responsables de producto; el YAML permanece como artefacto de ingeniería.
-
¿Qué zona horaria usa la programación cron?
Solo UTC. La programación con zona horaria no está soportada actualmente.
-
¿Puede una política llamar a otro micro service de MOS4?
Sí. La acción call_interface alcanza cualquier micro service de MOS4 — MSP, motores de inferencia y drivers personalizados. El proxy de interfaz valida la restricción semver en el momento de cargar la política, almacena en caché la conexión y aplica un timeout configurable (por defecto 3 000 ms por llamada). Sin código de pegamento por integración. Consulte el SDK para crear micro services personalizados.
-
¿Puedo probar reglas sin hardware?
Sí. Una herramienta de lint semántico valida el YAML antes de que llegue a un dispositivo — detectando claves DB indefinidas, declaraciones requires: faltantes, grafos de reglas cíclicos, condiciones inalcanzables y errores de tipo en expresiones. Un ejecutor de escenarios autónomo reproduce archivos YAML fuera del objetivo en pipelines de CI. Un doble de prueba del motor de políticas permite probar la evaluación de políticas en integración sin una pila MOS4 completa.
Traiga el libro de reglas.
Muéstrenos la política que desea en el dispositivo; ingeniería le ayudará a redactar las reglas.