Simulación en tiempo acelerado: probar decisiones antes de tomarlas

Hay decisiones que no se pueden probar con un test A/B.

No puedes cerrar una pista treinta minutos a ver qué pasa. No puedes agregar cinco vuelos por hora para averiguar si las calles de rodaje lo absorben. No puedes ensayar un procedimiento de pushback un martes y revertirlo el miércoles. El experimento mismo es el daño.

La simulación en tiempo acelerado es la forma de correr esos experimentos de todas maneras.

La simulación en tiempo acelerado es una técnica de modelado que reproduce horas o días de una operación real en segundos, sin una persona dentro del ciclo, de modo que el mismo escenario puede correrse cientos de veces y compararse contra alternativas. Es el motor detrás de la mayoría de los gemelos digitales de sistemas físicos: aeropuertos, puertos, plantas, hospitales.

Qué significa tiempo acelerado

Un simulador en tiempo real corre a la velocidad de la vida. Una hora de operación toma una hora. Eso hacen los simuladores de vuelo, porque un piloto tiene que vivir la experiencia a velocidad humana.

La simulación en tiempo acelerado descarta esa restricción. No hay una persona dentro del ciclo, así que no necesita respetar el reloj. Un día completo de operación aeroportuaria puede modelarse en segundos.

Esa sola propiedad es lo que la hace útil, y por una razón que no es evidente: permite correr el mismo día cientos de veces.

Por qué una sola corrida no dice nada

Los sistemas que vale la pena simular están llenos de aleatoriedad. Las aeronaves llegan unos minutos antes o después. El turnaround se alarga cuando una pasarela se traba. Los tiempos de rodaje cambian con el tráfico. Ninguno de estos es un número fijo, son distribuciones.

Así que una sola corrida te da un día posible. Puede ser un día inusualmente tranquilo o inusualmente malo, y nada en el resultado te dice cuál de los dos.

Córrela trescientas veces y obtienes la forma del resultado. No "el atraso será de nueve minutos", sino "el atraso normalmente va de seis a once minutos, y aproximadamente un día de cada veinte supera los veinte". Esa distribución es la respuesta real, porque es contra lo que planificas capacidad y personal.

Es el mismo razonamiento detrás de los métodos Monte Carlo en cualquier otro contexto. Una muestra es una anécdota. La distribución es el hallazgo. La misma trampa aparece en la evaluación de modelos, sobre lo que escribí en una sola división de prueba no basta para comparar modelos.

Qué lleva adentro un modelo de tiempo acelerado

Una simulación útil de una operación física tiene cuatro partes.

La infraestructura. Una versión digital del lugar. Pistas, calles de rodaje, posiciones, sectores del espacio aéreo, y sobre todo las reglas que los conectan: qué calle alimenta qué pista, cuánta separación se requiere, qué posiciones aceptan qué aeronaves.

Los actores. Aeronaves, controladores, equipos de tierra. Cada uno sigue los mismos procedimientos que sigue su contraparte real.

Tiempo y aleatoriedad. El modelo avanza evento por evento, segundo a segundo. Los tiempos de llegada, las duraciones de turnaround, los tiempos de rodaje y los atrasos se extraen de distribuciones de probabilidad en lugar de valores fijos. Esto es lo que hace que corridas repetidas produzcan días distintos.

Los escenarios. Un baseline que representa el hoy, y luego las variantes que realmente quieres comparar contra él.

Esa última parte es donde está el valor. Un modelo que solo reproduce el presente es una forma cara de describir algo que ya tienes. El punto es la comparación.

Cómo se hace un estudio en la práctica

Va en una sola dirección, y cada paso depende del anterior:

Recolectar. Historia operativa, itinerarios, procedimientos, layout de infraestructura. Es la mayor parte del trabajo y la que menos se discute.

Modelar, repetidamente. Construir la versión digital y correrla muchas veces, para que la aleatoriedad tenga espacio de expresarse.

Evaluar. Comparar escenarios contra el baseline con métricas que importan operativamente: throughput, tiempos de rodaje, largo de filas, propagación de atrasos. La simulación te dice cómo se comporta un sistema; la optimización matemática te dice qué hacer al respecto, como un modelo entero mixto de cancelación de vuelos que construí, que elige qué vuelos cancelar cuando la falta de aviones ya es inevitable. Son complementos.

Entender el sistema. Este es el entregable real, y es fácil pasarlo por alto. El número que produce el modelo importa menos que saber por qué el sistema se comporta así, porque ese entendimiento se transfiere a situaciones que nunca simulaste.

Las preguntas que responde

Todas tienen la misma forma: qué pasa si.

Qué pasa si agregamos cinco vuelos por hora. Qué pasa si una pista cierra treinta minutos en el peor momento posible. Qué pasa si cambiamos los procedimientos de rodaje. Qué pasa si el clima se deteriora durante el banco más cargado del día.

Un dashboard no puede responder ninguna de estas, porque un dashboard reporta lo que pasó. Estas preguntas son sobre cosas que todavía no ocurren y que, en la mayoría de los casos, nunca deben ocurrir sin haberlas planificado.

Un patrón aparece constantemente y conviene conocerlo de antemano: la disrupción rara vez es la parte cara. Cierra una pista treinta minutos y los treinta minutos no son el problema. El problema es la fila que se acumula mientras está cerrada, que después hay que desahogar tras la reapertura, a un ritmo para el que el sistema nunca fue diseñado. La recuperación toma considerablemente más que la interrupción. Un modelo te muestra esa curva. La intuición la subestima de forma sistemática.

Cuándo vale la pena construir un gemelo digital

Lo necesitas cuando el sistema es complejo, el costo de fallar es alto y experimentar en la realidad es riesgoso o caro. Las tres cosas, no una.

No lo necesitas cuando el sistema es simple, cuando fallar es barato, o cuando un dashboard ya te dice lo que necesitas. Construir un gemelo digital de algo que ya entiendes es una forma cara de confirmar lo que sabes.

La prueba honesta es si hay una decisión genuinamente esperando la respuesta. Si nadie va a actuar distinto según el resultado, el modelo es una demostración, no una herramienta.

El argumento de fondo

El valor no está en que la simulación prediga el futuro con precisión. No lo hará. Todo modelo está equivocado en algo, y los útiles están equivocados de maneras que puedes caracterizar.

El valor está en que convierte una decisión de una discusión sobre opiniones en una discusión sobre evidencia. Cuando alguien con jerarquía dice que el aeropuerto puede absorber más tráfico y otra persona dice que no, ese desacuerdo no tiene mecanismo de resolución. Ambos razonan desde su experiencia, y ambas experiencias son reales.

Un modelo no lo resuelve por tener la razón. Lo resuelve haciendo explícitos los supuestos, para que el desacuerdo se mueva hacia algo verificable.

En sistemas complejos, la confianza sin simulación es un riesgo. No porque la gente se equivoque, sino porque nadie puede sostener tantas filas interactuando al mismo tiempo en la cabeza, y tener confianza igual es exactamente como se termina comprometiendo capital en el cuello de botella equivocado.