Planes de vuelo, comprobaciones del día y registros de vuelo | Cerrar la operación

Para un vuelo específico (uno que requiere permiso o aprobación), debe confirmar las obligaciones relativas a la notificación previa del plan de vuelo y a los registros de vuelo. La guía más reciente del MLIT (Ministerio de Tierra, Infraestructura, Transporte y Turismo de Japón) es la referencia. Los registros propios de una aplicación no satisfacen automáticamente el formato legal, así que contraste los campos que exporta.

El plan dice «así pretendemos volar»; el registro dice «esto es lo que ocurrió realmente». Si sobrescribe el plan con el registro, pierde por qué el vuelo se retrasó y qué se cambió. Conserve ambos y observe la diferencia.

Una fila de casillas de verificación por sí sola es débil. Cuando alguien selecciona «anomalía detectada», el diseño debe conducirlo a una explicación y a un punto de contacto. Los umbrales de go/no-go para el tiempo y la aeronave provienen del manual del modelo, del manual de operaciones y de la evaluación de riesgos in situ. No fije aquí un número único para todos.

draft → planned → preflight_review → ready
ready → in_progress → landed → closed
preflight_review → on_hold
in_progress → contingency → landed
landed → follow_up_required → closed

Estos son estados de ejemplo para una aplicación de registro. El diseño no envía órdenes a la aeronave real a partir de esta secuencia. Si el enlace se corta, no fije el último estado recibido como «el estado actual»; infórmelo como desconocido, con una marca de tiempo.

Asuma que la conexión será débil sobre el terreno y considere permitir que las entradas no enviadas se conserven temporalmente en el dispositivo. Muestre si cada entrada se ha compartido y reutilice el mismo ID de evento al reenviar para que nada se registre dos veces. Si otra persona ha actualizado el registro entretanto, no sobrescriba en silencio; muestre primero la diferencia.