ESPACIO AÉREO / CONOCIMIENTO Y DISEÑO
Supervisión y respuesta ante fallos | Prepararse para el momento en que se pierde la imagen
Pérdidas de enlace, posiciones obsoletas, desviaciones del plan. El apoyo al vuelo tiene que diseñarse no solo para la pantalla sana, sino para los momentos en que la información desaparece.
Lea esta página en orden
Conserve dos marcas de tiempo y tres estados
Separe la hora en que se hizo una observación de la hora en que el servidor la recibió. Junto a "normal" y "anómalo", mantenga un tercer estado: "desconocido". Una aeronave que se ha detenido en su última posición conocida y una pantalla que simplemente ha dejado de actualizarse no son lo mismo. Esta es una propuesta de diseño para un sistema de apoyo al vuelo de uso general.
| Estado | Cómo tratarlo |
|---|---|
| Datos frescos disponibles | Seguir supervisando dentro de las condiciones aplicables |
| Anomalía detectada | Indicar qué, qué aeronave, cuándo se detectó y quién es responsable |
| Datos obsoletos o desconocidos | No dibujarla como posición actual; mostrar la última observación |
Diseñe las alertas en torno a la acción de quién cambian
Más avisos no significan automáticamente más seguridad. Entregue el sujeto, el motivo y la siguiente acción a alguien que realmente pueda responder. Incorpore el acuse de recibo, el escalado de las alertas sin respuesta y los fundamentos para cerrarlas. Cualquier mensaje relacionado con la seguridad debe indicar primero la condición concreta, sin redacciones que difuminen su significado.
| Ejemplo de evento | Ejemplo de respuesta en pantalla | Qué registrar |
|---|---|---|
| Las actualizaciones de observación se detienen | Última hora de recepción; estado actual desconocido | Inicio, recuperación, acuse de recibo del responsable |
| Posible desviación del plan | Mostrar la aeronave y la diferencia | Criterios de decisión, versión del plan, valores observados |
| Caída de un servicio externo | Alcance afectado y lugares alternativos donde comprobar | Conexiones fallidas, reintentos |
| El responsable no responde | Escalar según el orden de contacto acordado | Destinatarios, acuse de recibo, resultado |
Los procedimientos de emergencia dependen de la aeronave y de la operación
Qué hacer ante una pérdida de enlace depende de las especificaciones de la aeronave, el lugar, las condiciones de vuelo, el manual de operaciones y más. Un sitio de uso general no debería diseñarse para emitir órdenes generales de "ascender", "regresar" o "aterrizar". La aplicación muestra el plan confirmado y cómo contactar con la persona responsable, y traza una línea clara de responsabilidad entre ella misma y las funciones de seguridad propias de la aeronave.
Escenarios para recorrer sobre el papel
- Cuando llega una observación con una marca de tiempo anterior a la última, ¿sobrescribe datos más recientes?
- Cuando la misma alerta se entrega repetidamente, ¿parece una anomalía distinta?
- ¿Puede alguien sin autoridad cerrar una alerta?
- Cuando un enlace se recupera y entra de golpe una acumulación de datos antiguos, ¿se mezclan con la posición actual?
- Cuando cambia la persona de turno, ¿se traspasan las anomalías sin resolver y sus fundamentos?
Empiece la verificación con la reproducción de registros y la simulación. Las pruebas con aeronaves reales necesitan su propio plan de seguridad y un equipo adecuado, así que hágalo por etapas.
CRITERIOS DE FINALIZACIÓN
Cuando lo construya, compruebe estos puntos.
- Un estado desconocido nunca se muestra con el color de "normal".
- Acusar recibo de una alerta y resolver el problema se registran por separado.
- Las observaciones antiguas nunca se reproducen como nuevas.
Puntos de control de diseño para usar en revisiones de especificaciones y pruebas funcionales.
Cómo leer esta página
Esta página es una propuesta de diseño original. La implementación y los ejemplos numéricos no son prueba de resultados reales ni de certificación. Verifíquelos frente a las condiciones del trabajo al que los aplique.
Lea cómo se elaboró esto y nuestra política editorial