VOO / CONHECIMENTO & DESIGN
Planos de voo, verificações do dia e diários de voo | Encerrando a operação
Não pare no envio de um plano. Amarre o que você verificou, o que aconteceu e como terminou em uma única operação.
Leia esta página em ordem
Mantenha o plano e o registro real separados
Para um voo específico (um que exige permissão ou aprovação), é preciso confirmar as obrigações de notificação prévia do plano de voo e de diários de voo. A orientação mais recente do MLIT (Ministério da Terra, Infraestrutura, Transporte e Turismo do Japão) é a referência. Os registros próprios de um aplicativo não satisfazem automaticamente o formato legal, então confira os campos que ele exporta.
Fonte: MLIT | Notificação do plano de voo e diários de vooO plano diz "é assim que pretendemos voar"; o registro diz "foi isso que realmente aconteceu". Sobrescreva o plano com o registro e você perde por que o voo atrasou e o que foi alterado. Mantenha os dois e observe a diferença.
Passe a responsabilidade ao longo de três fases
| Fase | Exemplos de verificações e registros | Sinal de conclusão |
|---|---|---|
| Pré-voo | Estado da aeronave, tempo, arredores, equipe, procedimentos de emergência | O responsável confirma as condições deste voo |
| Em voo | Início e fim, posição, desvios, anomalias, comandos do operador | Fim do voo e recolhimento da aeronave confirmados |
| Pós-voo | Defeitos, manutenção, recuperação de mídia, relatórios obrigatórios | Pendências com um responsável e um prazo |
Uma fileira de caixas de seleção sozinha é fraca. Quando alguém seleciona "anomalia encontrada", o design precisa conduzi-lo a uma explicação e a um ponto de contato. Os limiares de go/no-go para tempo e aeronave vêm do manual do modelo, do manual de operações e da avaliação de risco no local. Não fixe aqui um número único para todos os casos.
Um exemplo de transições de estado
draft → planned → preflight_review → ready
ready → in_progress → landed → closed
preflight_review → on_hold
in_progress → contingency → landed
landed → follow_up_required → closedEstes são estados de exemplo para um aplicativo de registro. O design não envia comandos à aeronave real a partir desta sequência. Se o enlace cair, não fixe o último estado recebido como "o estado atual"; informe-o como desconhecido, com carimbo de data e hora.
Recuperando-se do modo offline
Presuma que a conexão será fraca em campo e considere permitir que entradas não enviadas fiquem retidas temporariamente no dispositivo. Mostre se cada entrada foi compartilhada e reutilize o mesmo ID de evento no reenvio para que nada seja registrado duas vezes. Se outra pessoa atualizou o registro nesse meio-tempo, não sobrescreva em silêncio; mostre a diferença primeiro.
DEFINIÇÃO DE PRONTO
Ao construir, verifique isto.
- Tanto a versão do plano anterior à mudança quanto o registro real do voo são mantidos.
- Entradas não enviadas, enviadas e com falha podem ser distinguidas.
- Um caso encerrado com anomalia mantém um responsável e um acompanhamento.
Itens de checklist de design para uso em revisões de especificação e testes funcionais.
Confira as fontes
As explicações de regras e definições remetem aos materiais abaixo. As telas, os dados e a definição de pronto são propostas de design nossas.
- MLIT | Notificação do plano de voo e diários de vooNotificação do plano e registros para voos específicos
Fontes verificadas em 30 de setembro de 2026. Confirme como as regras se aplicam ao seu caso com base nas informações oficiais mais recentes.