导语： 正常的机器人梯控流程很好写，真正考验工程设计的是异常路径。电梯途中停止怎么办？到目标层却不开门怎么办？机器人进入轿厢后电梯状态长时间不变化怎么办？如果所有异常最后都进入同一个TIMEOUT，系统上线后会很难定位问题。

一、先把“异常停靠”定义成任务状态异常

机器人梯控不应该试图替代电梯控制器诊断所有电梯故障。

它真正能够判断的是：

Expected_State ≠ Observed_State

例如任务状态为：

MOVING_TO_TARGET

系统预期：

Floor持续变化

或运行状态保持MOVING但实际连续观察到：

Elevator_State = STOPPED

且：

Current_Floor ≠ Target_Floor

并持续超过项目设定的确认窗口，就可以产生：

UNEXPECTED_STOP

这不是在判断电梯具体发生了什么机械故障，而是在判断“机器人乘梯任务已经偏离预期”。

二、不要只有一个Timeout

常见但不够好的写法是：

if task_time > timeout:
    alarm()

这样做的问题是所有异常最后都变成“超时”。

更适合工程排查的状态可以拆成：

WAIT_ELEVATOR_TIMEOUT

UNEXPECTED_STOP

TARGET_FLOOR_MISMATCH

DOOR_OPEN_TIMEOUT

DOOR_CLOSE_TIMEOUT

STATE_UNKNOWN

COMMUNICATION_LOST

例如机器人已经进入轿厢，目标楼层是Floor_8：

if state == MOVING_TO_TARGET:
    if elevator_stopped:
        if current_floor == target_floor:
            state = WAIT_DOOR_OPEN
        else:
            state = UNEXPECTED_STOP

进入WAIT_DOOR_OPEN以后：

if door_open_confirmed:
    state = READY_TO_EXIT
elif wait_time > door_timeout:
    state = DOOR_OPEN_TIMEOUT

这样日志里看到DOOR_OPEN_TIMEOUT，就知道问题发生在“已经到层但没有获得预期门状态”这一阶段，而不是只有一个没有上下文的ERROR。

三、异常确认需要去抖和持续时间

真实电梯运行过程中，短时间停止不一定代表异常。

因此不能写成：

STOPPED = True

立即报警。

更合理的做法是设置异常候选状态：

NORMAL

→ SUSPECTED_EXCEPTION

→ CONFIRMED_EXCEPTION

第一次发现状态不符合预期时进入SUSPECTED_EXCEPTION。如果随后状态恢复正常，则返回任务状态；只有异常持续满足确认条件，才进入CONFIRMED_EXCEPTION。

这种设计可以减少瞬态状态变化造成的误报警。

具体持续时间不能写成一个适用于所有电梯的固定数字，应根据电梯运行特性、楼层距离、数据采样周期和项目要求进行标定。

四、异常以后首先冻结机器人动作

安全相关系统一个很重要的原则是：

未知状态不能默认成正常状态。

如果电梯当前状态已经无法确认，就不应该继续释放：

ENTER_ELEVATOR

EXIT_ELEVATOR

NEXT_FLOOR_TASK

等动作。

可以进入：

TASK_HOLD

等待状态恢复、重新确认或人工介入。

如果通信丢失，同样不能简单把最后一次正常状态一直沿用。

例如：

10:20:01 Door = OPENED

随后状态数据中断。

系统不能在10:20:20仍然认为Door = OPENED。

状态应该具有有效期：

if now - last_update > state_ttl:
    elevator_state = UNKNOWN

UNKNOWN应该进入保守处理，而不是继续执行机器人动作。

五、困人和异常停靠必须分开

这是系统设计中特别容易犯的错误。

机器人梯控发现：

电梯非预期停止

并不能直接推出：

Passenger_Trapped = True

因为非预期停止可能有多种原因，而系统未必拥有判断轿厢内是否存在人员的可靠数据。

因此建议将事件命名为：

UNEXPECTED_ELEVATOR_STOP

而不是：

PASSENGER_TRAPPED

如果项目还接入了电梯原有安全系统、人员检测系统或物业告警平台，再由上层系统结合其他数据判断是否进入人员救援流程。

六、告警最好包含上下文

只发：

“电梯异常”

对运维帮助有限。

更有价值的事件应该携带：

Elevator_ID

Robot_ID

Task_ID

Current_Floor

Target_Floor

Elevator_State

Door_State

Task_State

Exception_Type

Timestamp

这样管理端看到异常以后，可以快速知道：

哪部电梯；

哪台机器人；

任务做到哪一步；

电梯停在哪层；

机器人原本准备去哪层。

七、告警以后怎么恢复

异常处理不能只有Alarm，还必须设计Recovery。

典型逻辑可以分成：

状态自行恢复 → 重新验证 → 继续任务；

当前电梯不可用 → 取消当前乘梯任务；

存在其他可用电梯 → 重新调度；

状态长期未知 → 保持任务暂停并请求人工介入。

最需要避免的是异常解除后直接从中断位置无条件继续。

例如机器人在WAIT_DOOR_OPEN阶段发生异常，恢复以后仍应重新确认：

Floor_OK

Elevator_Stopped

Door_Open_OK

再允许EXIT。

八、测试异常路径比测试正常路径更重要

测试用例至少应该覆盖：

途中非目标层停止；

目标层停止但不开门；

门状态长时间不变化；

运行状态与楼层状态矛盾；

状态数据中断；

状态短时抖动后恢复；

异常持续后恢复；

异常后切换其他电梯；

机器人处于轿厢内时发生异常；

多机器人等待同一电梯时发生异常。

尤其要测试：

异常发生以后机器人有没有继续移动。

因为安全状态机最重要的不是“报警弹出来了没有”，而是异常期间不应该执行的动作有没有真正被阻止。

FAQ：

问题1：电梯停止多久才算异常？

没有通用固定时间。应结合运行距离、正常运行时间分布、采样周期和项目要求设定。

问题2：检测到非预期停止能否直接判断困人？

不能。非预期停止与人员被困不是同一个事件，需要其他可靠信息进一步确认。

问题3：网络断开以后应该继续使用最后一次门状态吗？

不建议无限沿用。状态应设置有效期，过期后进入UNKNOWN并采取保守策略。

问题4：报警以后可以自动重新调度另一部电梯吗？

技术上可以设计这样的恢复策略，但前提是当前机器人位置、任务状态以及替代电梯条件能够重新确认。

总结： 机器人梯控异常告警的核心不是写更多报警规则，而是建立“任务预期—实际状态—异常确认—动作冻结—告警—恢复验证”的闭环。尤其在可能涉及人员安全的场景中，系统应该明确区分“检测到异常停靠”和“确认人员被困”，避免用有限的状态数据做超出能力范围的结论。