ESPAÇO AÉREO / CONHECIMENTO E DESIGN
Monitoramento e resposta a falhas | Preparar-se para o momento em que você perde a visão
Perdas de enlace, posições desatualizadas, desvios do plano. O apoio ao voo precisa ser projetado não só para a tela saudável, mas para os momentos em que a informação some.
Leia esta página na ordem
Mantenha dois carimbos de tempo e três estados
Separe o horário em que uma observação foi feita do horário em que o servidor a recebeu. Ao lado de "normal" e "anormal", mantenha um terceiro estado: "desconhecido". Uma aeronave que parou na última posição conhecida e uma exibição que simplesmente parou de atualizar não são a mesma coisa. Esta é uma proposta de design para um sistema de apoio ao voo de uso geral.
| Estado | Como tratar |
|---|---|
| Dados atualizados disponíveis | Continuar monitorando dentro das condições aplicáveis |
| Anomalia detectada | Informar o quê, qual aeronave, quando foi detectada e quem é o responsável |
| Dados desatualizados ou desconhecidos | Não desenhar como posição atual; mostrar a última observação |
Projete os alertas em torno de quem muda de ação por causa deles
Mais avisos não significam automaticamente mais segurança. Entregue o assunto, o motivo e a próxima ação a alguém que realmente possa responder. Inclua a confirmação de recebimento, o escalonamento de alertas sem resposta e os fundamentos para encerrá-los. Qualquer mensagem relacionada à segurança deve declarar primeiro a condição concreta, sem palavras que desfoquem seu significado.
| Exemplo de evento | Exemplo de resposta na tela | O que registrar |
|---|---|---|
| As atualizações de observação param | Horário da última recepção; estado atual desconhecido | Início, recuperação, confirmação do responsável |
| Possível desvio do plano | Mostrar a aeronave e a diferença | Critérios de decisão, versão do plano, valores observados |
| Interrupção de serviço externo | Escopo afetado e lugares alternativos para verificar | Conexões com falha, novas tentativas |
| O responsável não responde | Escalonar seguindo a ordem de contato acordada | Destinatários, confirmação, resultado |
Os procedimentos de emergência seguem a aeronave e a operação
O que fazer em uma perda de enlace depende das especificações da aeronave, do local, das condições de voo, do manual de operações e mais. Um site de uso geral não deve ser projetado para emitir comandos genéricos de "subir", "retornar" ou "pousar". O aplicativo mostra o plano confirmado e como contatar o responsável, e traça uma linha clara de responsabilidade entre si e os recursos de segurança da própria aeronave.
Cenários para percorrer no papel
- Quando uma observação chega com um carimbo de tempo anterior ao último, ela sobrescreve dados mais recentes?
- Quando o mesmo alerta é entregue repetidamente, ele parece uma anomalia separada?
- Alguém sem autoridade consegue encerrar um alerta?
- Quando um enlace se recupera e um acúmulo de dados antigos chega de uma vez, eles se misturam com a posição atual?
- Quando a pessoa de plantão muda, as anomalias não resolvidas e seus fundamentos são repassados?
Comece a verificação com reprodução de logs e simulação. Testar com aeronaves reais exige seu próprio plano de segurança e uma equipe adequada, então avance em etapas.
DEFINIÇÃO DE PRONTO
Ao construir, verifique estes pontos.
- Um estado desconhecido nunca é mostrado na cor de "normal".
- Confirmar um alerta e resolver o problema são registrados separadamente.
- Observações antigas nunca são reproduzidas como novas.
Pontos de verificação de design para uso em revisões de especificação e testes funcionais.
Como ler esta página
Esta página é uma proposta de design original. A implementação e os exemplos numéricos não são evidência de resultados reais nem de certificação. Verifique-os em relação às condições do trabalho em que você os aplica.
Leia como isto foi feito e nossa política editorial