Simulación como portón: validación antes del mundo físico

Toda ingeniería madura de sistemas autónomos converge al mismo principio: el mundo físico es el peor lugar para descubrir que una capacidad no funciona. Es caro, es lento, es riesgoso — y, en el caso de sistemas que vuelan, navegan o actúan sobre infraestructura, un error descubierto en campo puede tener consecuencias irreversibles. Las industrias aeroespacial y de defensa aprendieron esto a lo largo de décadas; Zendrix aplica la misma disciplina — hardware-in-the-loop, validación en simulación de alta fidelidad, aceptación por números — al desarrollo de infraestructura de inteligencia para operaciones autónomas.

Este artículo describe qué significa ese portón de simulación en nuestra práctica de ingeniería, a nivel de método. No es un manifiesto contra las pruebas reales: es la descripción de por qué las pruebas reales solo tienen valor después de que la simulación hizo su trabajo.

Simulación de alta fidelidad no es dibujo animado

Existe un malentendido común: la simulación sería un mundo idealizado donde todo funciona y que, por lo tanto, probaría poco. La simulación útil es lo contrario. Modela exactamente aquello que hace difícil al mundo.

En los entornos de simulación de Zendrix, la dinámica de los vehículos se aproxima con parámetros medidos — incluidos inercia, saturación de actuadores y retrasos de respuesta. La comunicación se modela con pérdida de paquetes, latencia variable y envejecimiento de estado: el agente recibe información atrasada e incompleta, como la recibiría en campo. Los sensores producen lecturas ruidosas, con deriva y fallas parciales. La batería se agota. El enlace cae. El viento existe.

La fidelidad tiene un propósito epistémico preciso: si una capacidad sobrevive a un entorno simulado que contiene las dificultades correctas, la evidencia que produce se transfiere al mundo real con margen conocido. Si sobrevive solo a un entorno idealizado, la evidencia no vale nada — y es por eso que la calidad de una simulación se mide por la honestidad de sus imperfecciones, no por la suavidad de sus gráficos.

Determinismo: la misma pregunta, la misma respuesta

Un portón de validación exige reproducibilidad. Una prueba que pasa hoy y falla mañana sin causa identificada no valida nada — apenas consuela. Por eso los entornos de simulación de Zendrix son deterministas por construcción: dada la misma semilla aleatoria y el mismo escenario, la trayectoria completa del sistema es reproducible bit a bit, incluidos el ruido de los sensores y la pérdida de paquetes.

Determinismo no significa artificialidad. Significa que la aleatoriedad está controlada: el ruido existe, pero es reproducible. Eso permite una disciplina que las pruebas no deterministas imposibilitan — cuando aparece un comportamiento sospechoso, puede reejecutarse, aislarse y diagnosticarse; cuando se hace una corrección, puede verificarse contra exactamente el escenario que expuso el problema. Y permite variar la semilla de forma sistemática para garantizar que un resultado no es suerte de un único escenario: la robustez que depende de la semilla no es robustez.

Pisos medidos: la aceptación es número, no adjetivo

La tercera pieza del método es la más importante culturalmente: criterios de aceptación cuantitativos, definidos antes de la medición y nunca flexibilizados después.

Cada capacidad que atraviesa el portón lleva un piso: el valor mínimo medible que necesita alcanzar en el entorno simulado — precisión de navegación por debajo de una deriva máxima, tiempo de reacción a falla de comunicación dentro de un límite declarado, retención de capacidad coordinada por encima de un umbral bajo derribo parcial. Los pisos se fijan a partir de mediciones honestas de lo que el sistema realmente alcanza, y luego se congelan como requisito. Cuando un cambio de código tumba un piso, el portón se cierra: el cambio no pasa.

Esa disciplina tiene un corolario impopular que abrazamos: cuando un sistema no alcanza el piso, la respuesta correcta es mejorar el sistema — nunca rebajar el piso. Un criterio de aceptación que se ajusta al resultado deja de ser criterio y se vuelve decoración. La cultura de evidencia de Zendrix, descrita en publicaciones anteriores, se aplica aquí en su forma más concreta: lo que no se mide no se declara; y lo que se mide y no alcanza el piso no se publica.

Controles anti-teatro: el sistema no puede engañar al portón

Hay una sutileza que separa la validación real de la validación teatral: un portón solo vale si es imposible atravesarlo fingiendo. Los sistemas de aprendizaje automático son especialmente propensos a formas sofisticadas de fingimiento — correlacionar con la respuesta correcta sin ejecutar el razonamiento que la produce, memorizar escenarios en lugar de generalizar, explotar filtraciones de información del entorno de prueba.

Por eso los entornos de simulación de Zendrix incluyen controles negativos por diseño. Para cada prueba que exige que el sistema acierte, existe una prueba espejo que verifica si un impostor plausible fallaría: ¿un agente inerte logra atravesar el piso? ¿Un sistema que solo repite comportamiento estándar alcanza la métrica? ¿La información que solo debería estar disponible en campo se filtra al planificador en la simulación? Si un impostor pasa el portón, el portón es el problema — y corregir el portón viene antes de celebrar el paso.

Esos controles no son paranoia académica. Son la diferencia entre afirmar que un sistema autónomo fue validado y saber que lo fue. Para infraestructura de defensa, la segunda postura es la única admisible.

Hardware-in-the-loop: el ensayo general antes del vuelo

La etapa final del portón es la simulación hardware-in-the-loop: el software de operación real — el mismo código que algún día comandará hardware físico — se ejecuta contra un simulador fiel del vehículo, intercambiando los mismos mensajes, en los mismos formatos, con los mismos retrasos que intercambiaría con el equipo verdadero. La única diferencia es que nada despega.

El valor del HIL es que elimina una categoría entera de riesgo: la de que el software de validación y el software de operación sean sistemas distintos que coinciden en el laboratorio y divergen en el campo. En el portón de Zendrix, no existe un "modo de prueba" privilegiado. El sistema que atraviesa la simulación es el sistema que iría a campo — y el modo de operación real solo se activa por decisión explícita y registrada, nunca por accidente ni por defecto.

Qué protege el portón

El portón de simulación protege tres cosas a la vez. Protege la operación: nada inmaduro llega al campo. Protege a la institución: las decisiones de promoción son auditables, con números registrados y criterios congelados. Y protege la verdad interna de la ingeniería: un equipo que solo promueve capacidades con evidencia medida no acumula la deuda más peligrosa de todas — la creencia falsa en la propia capacidad.

Así construye Zendrix la base tecnológica para operaciones autónomas futuras, incluidos los sistemas no tripulados: con el mundo físico al final del proceso, nunca al comienzo. La simulación no sustituye la validación en campo — es lo que hace que la validación en campo sea segura, económica y lo bastante honesta para merecer ese nombre.