同时突显过多异常会造成新的注意力过载
别名: 显著性竞争 · attentional overload
概念解释
同时突显过多异常会带来显著性竞争（salience competition）：多个闪烁、变色和声音同时争夺同一份注意资源，结果是每个线索相对其他线索的优先级都被稀释，操作员很难再从画面上直接看出哪个异常最值得先处理，也难以判断这些异常是不是同一个原因造成的。
机制
工业过程里的异常经常是级联的——一个上游设备或工艺参数的故障会顺着物理和逻辑连接触发一串下游状态变化。如果每一个变化都在画面上以同等强度呈现，操作员面对的就是一堆孤立的视觉瞬变，还要在自己的工作记忆里把它们重新聚类成"这些都是同一件事的不同表现"。人在时间压力下能同时追踪的独立信息块数量有限，级联异常一旦超过这个数量，操作员要么漏看其中一部分，要么把精力耗在聚类本身而不是判断根因和采取行动上。按因果关系、物理区域或触发时间窗口把相关异常合并展示，本质上是把很多个信息块降维成少数几个"事件"，减轻的是工作记忆里的聚类负担，不是减少信息总量。
分组能不能真的降低负担，取决于用来分组的因果关系是不是可靠、实时地知道。如果分组依据的是预先配置的报警关联表或规则引擎，而实际工况偏离了配置时的假设（比如某条本该级联的支路提前被隔离，或者维护状态改变了正常的依赖关系），系统仍会按旧的因果假设分组——这时呈现的"一个事件"可能包含了本不该合并的信息，或者遗漏了确实相关但没被规则覆盖的报警。分组因此不是无成本的：它把"操作员自己判断哪些异常相关"的认知负担，转移成了"信任系统预先设定的关联规则"的风险，一旦规则错，操作员可能比看原始列表时更晚发现问题，因为聚合后的界面看起来"已经解释清楚了"，反而降低了进一步核查的动机。
这套分组机制要解决的是画面上同时出现多个异常时怎么呈现的问题，跟单位时间内报警总量有没有超出处理能力是两个不同层面的问题——后者取决于到达节奏本身，就算只有两三个异常同时出现，只要它们之间的因果关系没有被可靠地识别出来，显著性竞争一样会发生。
怎么研究
在级联故障仿真里操纵同时突显的异常数量和分组方式（不分组、按因果分组、按区域分组），测操作员识别首要原因所需时间、第一个正确动作出现的时间、来回核对原始列表的次数，以及主观负荷评分。一个关键的设计要求是必须在级联场景之外单独插入一个和主故障无关的独立异常，用来检验分组呈现是不是让操作员在处理级联故障时漏看了这个不相关但同样需要处理的问题——这是分组类界面最容易在现场被发现的失效模式，只测级联场景本身的表现测不出来。
边界
分组算法依赖已知的因果或位号关联，遇到彼此独立但恰好同时发生的多重故障、或者因控制系统本身故障产生的大范围虚假跳变时会失效。后一类通常归为噪声大户报警（bad actor alarm，指长期反复触发、贡献了不成比例报警量的点），与因反复短时跳变但每次都不构成有效信息的滋扰报警（nuisance alarm）是两种需要在源头治理、而不是靠显示层分组解决的问题——分组会把它们强行并入某个不相关的簇，或者因为找不到已知因果关系而完全不分组，两种结果都可能误导操作员。多重独立故障同时发生时，聚合展示天然更容易让某一路被另一路盖过去。到底同时呈现多少个独立信息才算过载，会随任务复杂度、画面尺寸和操作团队人数变化，不存在一个可以脱离具体系统直接套用的数量上限。
怎么落地
对可靠识别出同源的报警建立事件簇，簇的默认呈现只给出根因候选、影响范围和簇内最高紧迫等级，同时保留展开查看全部成员的入口，不能因为分组就丢掉可追溯性。分组规则要能被运维人员定期核对和更新，而不是上线后长期不变——工艺改造、设备退役都会让旧的因果关系失效。验证办法：跑历史级联故障的报警日志回放，比较聚合前后的呈现事件数；再专门设计"级联故障叠加一个无关独立故障"的场景，检查操作员是否仍能在合理时间内发现并处理这个被淹没风险最高的独立问题。