单位时间报警数存在处理上限
别名: 报警处理能力 · alarm rate
概念解释
报警处理能力是有限的：每一条报警从出现到被消化，都要经过定向、理解、判断优先级、决定动作、执行动作和记录这几步，合起来构成这条报警占用操作员的“服务时间”。当单位时间内到达的报警数量——到达率——超过操作员能够完成服务的总条数——服务率，尚未处理的报警就会在队列里持续累积。这个上限就是常说的报警率（alarm rate）容量，它由任务和组织共同决定，脱离具体工艺、具体人员配置去谈一个普遍适用的数字没有意义。
机制
到达率一旦逼近服务率，排队延迟不是按比例增长，而是非线性放大：把利用率理解成到达率与服务率之比，利用率越接近于一，期望等待时间的增长速度就越快，越靠近容量上限，等待时间对到达率的微小变化就越敏感。这解释了一个反直觉的现象——日均报警数量看起来完全正常，某个尖峰时段却会突然彻底失控：决定队列是否发散的是峰值利用率，而不是被均值抹平之后的日均数字。
服务时间本身也不是常数。报警文本含糊、需要跳转多层画面才能确认根因、或与其他任务并发执行时，单条报警的服务时间会被拉长，相当于把服务率往下压，于是同样的到达率更容易越过容量上限。确认（acknowledge）动作很快完成，并不代表服务已经完成——按一下确认键只是把这条报警从待处理列表里移走，诊断和控制动作可能还没有开始，这一点常常被“平均确认时间”这类指标掩盖。
怎么研究
评估报警容量最常用的方法是人在环控制室仿真研究：用全范围或部分范围培训模拟器，系统性改变报警到达率或到达节奏（持续稳定还是短时成簇），让操作员执行常规监视与响应任务，记录其行为数据与主观负荷。之所以依赖仿真而不是现场实验，是因为真实工厂不允许为了做实验人为制造报警积压。
常见自变量包括到达率、到达是否成簇、并发任务数量、报警措辞的含糊程度；常见因变量包括首次确认时间、首个有效控制动作时间、待处理队列长度随时间变化的曲线，以及主观工作负荷量表得分。这类研究的用途是标定“多大的报警率会让积压持续增长而不是收敛”，从而为具体工厂设定报警率目标提供依据，而不是照搬一个行业通用数字。
一个方法论上的注意点：仿真场景通常是脚本化、有限时长的事件序列，真实值班却是连续、不知道何时结束的过程，短时段实验容易低估长时间值班里积压效应的累积；同时，真实报警里大量到达在时间上高度相关——同一个根因会在短时间内触发多个仪表报警——这种相关到达比相互独立的到达更容易压垮队列，但在设计工整的实验里反而容易被自变量的分组方式无意间控制掉，需要专门设计成簇到达的条件才能复现。
边界
容量会随团队规模、熟练度、自动化程度、报警类型和事故所处阶段变化，用长期平均每小时报警数来衡量负荷会掩盖短时爆发，也说明不了哪些报警在争夺同一个责任人的注意力。EEMUA 191 给出的一个常被引用的稳态基准是：长期平均报警率控制在十分钟一条左右（约合每小时六条以内）通常被认为可控，明显高于这个量级就会被归入负荷过重的区间——但这个基准针对的是稳态运行，事故发生时的短时到达率完全可以合法地远超它，不能拿稳态基准去评判短时爆发期间的表现。
这一叶讨论的是排队本身的容量问题：报警是否被及时接住。至于报警内容该按什么顺序处理、哪些报警会在积压中被忽略，属于另外的问题。
怎么落地
从报警与操作日志里计算到达间隔、首次评估时间、首个有效动作时间与积压长度，按角色和运行阶段分层统计——同一个到达率，对单人值守和多人分工的班组意味着完全不同的容量。
用真实历史的峰值时段而不是设计假设去回放，检验队列能否在峰值过后的一段时间内收敛到零，而不是长期维持在某个非零水平：非零收敛点意味着系统性容量不足，需要削减报警数量或增加人力、自动化，调整确认流程解决不了这个问题。
验证办法：从日志里提取每条报警从触发到首个有效控制动作之间的时间，按到达率区间分箱，画出到达率与平均等待时间的关系曲线。曲线开始陡峭上翘的那个到达率，就是这套人机系统的实际容量上限，用它替代任何未经验证的行业通用数字。