OCPP 错误码
OCPP 1.6 为 StatusNotification 的 errorCode 字段定义了 16 个取值。其中十五个描述故障,一个表示一切正常。
OCPP 错误码出现在 StatusNotification 的 errorCode 字段中。它是一个封闭枚举——充电桩不得自行发明取值——正是这一点才让全网范围的故障统计成为可能。
这个集合刻意做得很小,这也是它最大的局限。十六个码无法描述充电桩出问题的所有方式,因此厂商把真正的细节放进旁边的自由文本字段 vendorErrorCode。两个都要读。标准码告诉你类别,厂商码告诉你实际发生了什么。
| 错误码 | 含义 | 常见成因 | 通常处理方式 |
|---|---|---|---|
NoError | 无故障。随正常状态变化一起上报。 | 正常运行。随普通状态变更一并发送。 | 无需处理 |
ConnectorLockFailure | 接口上锁或解锁失败。 | 机械锁扣卡住、插座内有异物,或锁止执行器失效。 | 现场处理 |
EVCommunicationError | 与车辆的通信失败。多半是 Control Pilot 的问题。 | Control Pilot 信号通信失败。多半是车辆或线缆的问题,而非充电桩。 | 重试,仍失败则现场处理 |
GroundFailure | 漏电保护器动作。 | 漏电保护装置跳闸。按安全类故障处理。 | 现场处理 |
HighTemperature | 内部温度过高。 | 环境温度过高、散热口被遮挡,或长时间大电流输出。 | 通常会自行恢复 |
InternalError | 某个内部硬件或软件组件出现故障。 | 某个硬件或软件组件失效。细节要看厂商错误码。 | 先远程重启,仍失败则现场处理 |
LocalListConflict | 更新过程中本地授权名单版本冲突。 | SendLocalList 更新与充电桩持有的版本冲突。 | 远程修复 |
OverCurrentFailure | 过流保护动作。 | 过流保护跳闸,通常是车辆或线缆故障。 | 通常会自行恢复 |
OverVoltage | 供电电压高于允许范围。 | 供电电压高于允许范围。属于电网侧问题。 | 联系供电方 |
PowerMeterFailure | 电能表故障。 | 电能表停止响应。此后的计费数据都不可信。 | 现场处理 |
PowerSwitchFailure | 功率开关或接触器故障。 | 接触器未能正常分闸或合闸。 | 现场处理 |
ReaderFailure | RFID 读卡器故障。 | RFID 读卡器故障。充电桩可能仍可通过远程启动使用。 | 现场处理 |
ResetFailure | 请求的重启失败。 | 一次请求的重启未能完成。 | 先远程重启,仍失败则现场处理 |
UnderVoltage | 供电电压低于允许范围。 | 供电电压低于允许范围。属于电网侧问题。 | 联系供电方 |
WeakSignal | 无线通信信号过弱。 | 蜂窝或 Wi-Fi 信号太弱,无法稳定维持连接。 | 现场处理 |
OtherError | 其余各码都描述不了的故障。 | 其他错误码都无法描述的故障。查看 vendorErrorCode。 | 取决于厂商 |
NoError 并不等于「没有消息」
NoError 会被持续发送,因为每一次普通的状态变更都带有 errorCode,而正常的状态转换用的正是这个取值。如果监控链路统计「带错误码的 StatusNotification」却不过滤 NoError,得出的故障率基本会是 100%。
影响整站的故障应上报在连接器 0 上
共用硬件的故障——电表、通信模块、主接触器——属于 connectorId: 0,它指的是充电桩本身。某个具体插座的故障则属于那个连接器。凡是把所有故障都报在连接器 1 上的充电桩,都会让人无法区分「一个插座坏了」和「整站坏了」。
错误码不会自己清除
协议中没有「故障已解除」这样的消息。故障要靠之后一条携带 NoError 的 StatusNotification 来清除;如果充电桩始终不发,你的仪表板就会永远显示这个故障。重连之后对齐状态时,用 TriggerMessage 请求 StatusNotification,就是询问当前真实状态的方式。
OCPP 2.0.1 没有错误码
这张表是 OCPP 1.6 的表,2.0.1 没有对应物。2.0.1 的 StatusNotification 根本没有 errorCode 字段——故障改为通过 NotifyEvent 上报,针对设备模型中的某个组件与变量触发,并带有 0 到 9 的严重级别。
结果是表达力更强,却远没那么方便:不再有十六个固定取值可供 switch,因为一个站点会上报什么,取决于它自己的设备模型。任何要从 1.6 迁移到 2.0.1 的故障处理逻辑,都必须重建,而不是简单映射。
厂商错误码
vendorErrorCode 是自由文本,与 vendorId 搭配以说明它属于谁的命名空间。它没有标准化,OCPP 中也没有文档,却往往是唯一能指明真实故障的东西。从第一天起就把它收集起来——事后给整个车队的历史数据补上这一项是做不到的。