需指出位置、原因与建议动作
别名: 报警消息结构 · diagnostic alarm
概念解释
有效的报警呈现要在信息层面回答三个问题：异常发生在过程的哪个位置、触发它的依据是什么、现在应该先做什么。这里的"原因"必须是可以被核实的触发条件或者带着不确定性标注的根因候选，而不能把单一传感器测到的一个症状，包装成一句听起来已经确定的因果结论呈现给操作员。这条讨论的是消息该包含哪三类内容，声光呈现方式该怎么和优先级对应、确认之后状态该怎么变化，分别是同组另外两叶的内容。
机制
位置信息的作用是支持操作员从抽象的报警列表条目映射回具体的过程对象；触发依据的作用是让操作员能够验证这条报警是不是真的、而不是被动接受；建议动作的作用是把纯粹的信息转化成可以马上执行的控制行为。这三类信息各自解决不同的认知问题，任何一类缺失都会单独产生一种延迟：缺位置会让操作员花时间搜索对象，缺依据会让操作员靠猜测填补因果关系，缺建议动作会让报警停留在"知道了但不知道干什么"这个层面，无法推进到实际处置。
边界
移动设备、纯软件服务或者跨系统级联故障，往往没有单一确定的物理位置可以指认；复杂事故也经常在同一时刻存在好几个尚未排除的假设，而不是唯一答案。遇到这两种情况，呈现方式应该切换成展示受影响的范围、每个假设目前的证据强度，以及用来鉴别哪个假设成立的具体步骤，并且允许这个判断随新证据进来而更新，不能强行凑出一个看起来唯一确定的位置或原因。
怎么落地
把资产标识、空间或拓扑上的入口、偏差内容和发生时间、根因的置信程度、以及第一步安全动作在同一条消息里并列展示，建议动作还必须标明它适用的运行模式和需要什么授权角色，避免正确的动作被错误的人在错误的工况下照搬执行。验证时特意设计传感器给出误导性读数、或者存在多个可能原因的测试场景，观察操作员是不是会去核验证据链条，还是直接盲从消息里给出的建议动作。