Gestión de incidentes para un gran evento de automovilismo

En un gran evento en un autódromo, una falla eléctrica o hidráulica exige una respuesta rápida y coordinada. Cuando el aviso circula por canales sueltos, como radio y teléfono, nadie tiene la visión de conjunto: el mismo incidente llega por varias personas, el equipo pierde tiempo para encontrar el lugar exacto y, al final, no quedan datos sobre los tiempos de atención.

El sistema reemplaza esos canales por un solo panel, que se actualiza al instante, en el que cada incidente se abre, se sigue y se cierra con historial completo.

Una aplicación web instalable (PWA), usada en el celular por el equipo de campo, y un panel para la central de operación. Con ella es posible:

• registrar un incidente en pocos toques, con nombre y hora completados automáticamente y el área sugerida a partir de los datos cargados con anticipación;
• elegir la categoría (eléctrica o hidráulica), el tipo de problema en una lista y la urgencia (alta, media o baja), y adjuntar hasta tres fotos;
• registrar incluso sin conexión, dejando el envío a cargo de la aplicación cuando vuelva la red;
• seguir todos los incidentes en un tablero en vivo con seis columnas, una por estado;
• asignar al equipo técnico, cambiar la urgencia y controlar los plazos de primera respuesta y de solución;
• recibir la sugerencia de agrupación cuando dos incidentes parecen ser el mismo;
• cerrar en dos etapas: el equipo resuelve e informa lo que se hizo, y el coordinador general valida;
• consultar informes por estado, urgencia, área y categoría.

Los avisos llegan por notificación en la aplicación y por correo electrónico. Una configuración ampliada agrega WhatsApp, SMS, una alerta reforzada que se repite hasta la confirmación dentro de la aplicación, mapa interactivo, video y un informe ejecutivo diario de siete secciones.

Sin red. Cuando no hay conexión, la aplicación guarda el incidente en el dispositivo, con el sello “esperando sincronización”, y lo envía automáticamente cuando vuelve la red, siempre que la aplicación esté abierta. Al recibirlo, la central devuelve al solicitante la confirmación “recibido por la central”, con el número del incidente. El prefijo del número indica la categoría (EL- o HI-), la numeración es única y secuencial, y la categoría no cambia después del registro.

Ubicación. Cada incidente se vincula a un área. La ubicación usa puntos fijos del plano del autódromo, cargados antes del evento, sin depender de GPS ni de señal de red.

Ciclo de vida. El incidente pasa por seis estados: sin atender, en clasificación, en curso, pendiente, resuelto y finalizado. Quien registra no cierra, y quien resuelve no valida. Un incidente resuelto solo se finaliza cuando el coordinador general lo valida, y puede reabrirlo con un motivo.

Plazos. Cada nivel de urgencia tiene un plazo de primera respuesta y de solución, iguales para las dos categorías. Cuando la central cambia la urgencia de un incidente, los plazos se recalculan a partir de la apertura, y el reloj no se reinicia.

Tiempo real. El panel se actualiza mediante Server-Sent Events. Todo cambio de estado pasa por un único punto de escritura, que comprueba el permiso según el contrato, guarda el evento y, en la misma transacción, emite por PostgreSQL el aviso que despierta a los demás módulos. Cada notificación se guarda antes del envío y, si la falla es temporal, se reenvía a intervalos cada vez mayores.

Seguridad. Cada usuario tiene acceso individual, con cambio de contraseña en el primer acceso y límite de intentos de inicio de sesión, y las contraseñas se protegen con argon2id. El nombre, el celular y el correo electrónico se usan solo en la operación del evento.

El sistema se dividió en módulos independientes, como registro, sincronización, panel, notificaciones e informes, construidos sobre un contrato compartido escrito en código. El contrato reúne las enumeraciones, la máquina de estados, las reglas de plazo, los esquemas de sincronización, los eventos y las notificaciones. El plan de cada módulo solo puede modificar su propia carpeta.

La especificación de la API y los tipos del frontend se generan a partir de ese contrato, y la integración continua rechaza el cambio que los deje desincronizados. Las operaciones que tardan más de dos segundos corren en segundo plano: la API responde con el código 202 (aceptado) y la aplicación muestra el aviso de procesamiento.

Para probar el sistema antes de la entrada en operación, un kit de ensayo simula la caída de la red, el reinicio del backend con notificaciones en curso y la restauración de un respaldo. Para producción, el sistema se empaqueta en tres contenedores: PostgreSQL 16, el backend FastAPI y un servidor Caddy, que sirve la aplicación con TLS automático.

El sistema distingue cinco roles:

• usuario general registrado, que registra y sigue los incidentes que abrió;
• coordinador de área, que registra y sigue los de sus áreas;
• equipo técnico, que recibe asignaciones y registra llegada, avance y solución;
• responsable técnico de la central, que hace la clasificación, la asignación y el cambio de urgencia;
• coordinador general, que valida el cierre y decide los duplicados.

El sistema se desarrolló a medida para un cliente, y no como producto de estantería. Está totalmente desarrollado y todavía no se ha entregado. La documentación incluye el manual del usuario, el manual del administrador y una guía para la entrada en operación. Los límites están documentados: en el iPhone, las notificaciones exigen la aplicación en la pantalla de inicio; las acciones del equipo técnico necesitan red; y un registro hecho por error no se cancela, sino que lo cierra la central.