监控与故障应对 | 为失去画面的那一刻做准备

把观测发生的时间与服务器接收到的时间分开。在“正常”和“异常”之外，保留第三种状态：“未知”。停在最后已知位置的机体，和只是停止更新的显示，不是一回事。这是一份面向通用飞行支持系统的设计提案。

警告更多，并不自动意味着更安全。把对象、原因和下一步行动传达给真正能够响应的人。内置确认机制、对无人应答告警的升级机制，以及解除告警的依据。任何与安全相关的消息都应先说明具体状况，不使用模糊其含义的措辞。

失联时该怎么做，取决于机体规格、场地、飞行条件、运行手册等。通用网站不应被设计成一刀切地发出“爬升”“返航”或“降落”指令。应用显示已确认的计划和联系负责人的方式，并在自身与机体自带的安全功能之间划清责任界线。

• 当一条观测到达时，其时间戳早于上一条，它会覆盖更新的数据吗？
• 当同一条告警被重复送达时，它看起来像是另一个异常吗？
• 没有权限的人能解除告警吗？
• 当链路恢复、积压的旧数据涌入时，它会与当前位置混在一起吗？
• 值班人员交接时，未解决的异常及其依据会被移交吗？

验证先从日志回放和仿真开始。使用真实机体进行测试需要专门的安全计划和合适的团队，因此要分阶段进行。