接手过几十个充电桩项目之后我越来越确信一件事真正让运维和研发头疼的不是功能开发而是现场一上报Faulted日志里却只有一个干巴巴的InternalError。OCPP 1.6 的故障码就是这么个东西看起来是枚举值背后却牵扯到硬件状态、协议状态机、平台业务判断甚至时钟同步。做充电桩接入或者做充电管理平台的兄弟多多少少都会被这块绊一跤。这篇内容就围绕 OCPP 1.6 里的故障码展开从协议字段到实际定位给你捋一遍。它适合刚接触 OCPP 的嵌入式工程师、平台后端开发也适合已经在做充电桩运维但总被现场日志搞得焦头烂额的朋友。我会尽量用项目里真实会踩坑的语气讲该贴代码贴代码该给速查表给速查表。1. OCPP 1.6 故障码到底是个什么码很多新人第一次接触 OCPP 1.6 时会以为“故障码”就是一个字段。真去翻代码才发现至少有三种东西都会被统称为故障码分别是ChargePointErrorCode、ChargePointStatus里的Faulted以及各条指令响应里的Accepted/Rejected/NotSupported。如果不先把这三层分清后面排查的时候很容易被绕晕。1.1 你会在哪些报文里看到“故障码”标准OCPP 1.6里最核心的故障码字段是StatusNotification请求里的errorCode它的类型叫ChargePointErrorCode。充电桩在状态发生变化时会主动向充电管理平台上报状态比如[ 2, d1c5b8f8-1234-4a2e-8c0d-7b9f6e0a1b2c, StatusNotification, { connectorId: 1, status: Faulted, errorCode: HighTemperature, info: NTC sensor value: 87.3C, timestamp: 2025-06-07T14:23:11Z, vendorId: CPLC, vendorErrorCode: E_TEMP_SENSOR_1 } ]这里的errorCode是标准层面的故障原因vendorId和vendorErrorCode是厂商自定义补充信息。很多平台只看标准字段忽略厂商字段结果现场故障原因被隐藏了。另外要注意StartTransaction和StopTransaction报文里没有标准errorCode字段但StopTransaction里有一个reason比如EmergencyStop、PowerLoss、Reboot、Remote等。它不算严格意义的故障码却是判断一次充电终止原因的关键线索。1.2 设备状态和错误码不是一回事StatusNotification里有两个字段经常被混为一谈status和errorCode。status是充电桩当前状态的枚举比如Available、Charging、SuspendedEVSE、FaultederrorCode才是说明“为什么会进入这个状态”的故障码。换句话说Faulted是“现在出问题了”的状态HighTemperature才是“什么问题”的描述。两者必须组合着看。一个充电桩可能上报Faulted NoError这在逻辑上很别扭但现场真的会遇到。平台如果只根据status Faulted就告警不管errorCode很容易把一次正常的设备维护误报成事故。2. 16个 ChargePointErrorCode 逐个拆解OCPP 1.6 标准里ChargePointErrorCode一共定义了 16 个枚举值从电源故障到通信故障都有。这一节咱们按类别拆开讲每个都说明典型触发场景和排查思路。2.1 电源与计量类故障码先看最容易理解的四类OverVoltage、UnderVoltage、OverCurrentFailure、PowerMeterFailure。OverVoltage和UnderVoltage指的是充电桩输入端或者输出端的电压超出合理范围。交流桩常见于电网波动直流桩则要同时看输入三相电压和输出直流电压。排查时先看电压采样电路是否正常再看电网侧是不是有大型设备启停造成的浪涌。OverCurrentFailure表示电流超过保护阈值常见原因有三个充电枪接触不良导致接触电阻过大、继电器或接触器粘连、BMS 请求电流和实际输出不匹配。别一上来就换主板先用钳形表卡一下实际电流再对比报文里的电流值很多时候是采样芯片漂移。PowerMeterFailure是电表通信或校验失败。这个故障码特别容易误报尤其是使用模块化电表时RS485接线松动、地址冲突、波特率不匹配都会导致读不到计量数据。有些桩厂为了过认证把电量误差偏大也映射成这个故障码结果平台侧看到PowerMeterFailure就以为硬件坏了实际只是计量参数没配好。2.2 通信与用户交互类故障码EVCommunicationError是直流桩最常见的故障码。它表示充电桩和电动汽车 BMS 之间的通信出现问题比如 CAN 通信超时、物理层断开、绝缘监测失败等。这个码的坑在于它不代表一定是车的问题也可能是桩的 CAN 收发器损坏、隔离电源异常或者充电枪的 CC/CP 信号异常。ReaderFailure指读卡器故障常见于射频读卡模块初始化失败、天线线圈短路、卡片认证流程卡死。如果你发现同一个站点的某个桩频繁上报ReaderFailure先怀疑读卡器排线再怀疑固件版本最后才是硬件损坏。ConnectorLockFailure指充电枪电子锁故障。这个码在交流桩上很典型充电枪插上后无法锁定或解锁。很多现场其实不是锁坏了而是锁舌机械卡涩、门磁开关位置偏移或者枪座里有异物。平台收到这个码后如果远程UnlockConnector返回UnlockFailed基本就是机械卡死必须派人处理。WeakSignal在早些版本里有争议它主要指无线通信模块信号弱或定位信号弱。现在很多桩已经不用 2G/3G 模块但这个码仍然会通过vendorId上报尤其在偏远站点。排查重点是天线位置和运营商覆盖别误判为充电桩主板故障。2.3 内部与安全类故障码GroundFailure是漏电保护相关故障包括接地不良、剩余电流超过阈值、绝缘监测异常。这个码在直流桩里特别重要处理不当有安全风险。现场排查先检查PE线、接地电阻再看绝缘监测模块是否误报。曾经有个项目因为充电桩底座的接地螺栓生锈一下雨就报GroundFailure换了螺栓后再没复发。HighTemperature不一定是环境温度高更多是充电枪端子温度、功率模块温度或者 PCB 板温超过阈值。快充桩大电流充电时如果枪线老化或者端子接触电阻变大温度会迅速上升。我见过过一个案例充电桩每隔十分钟报一次HighTemperature最后拆开枪发现端子已经烧黑再晚几天就是安全事故。所以这个故障码一定要重视。InternalError是大多数平台最头疼的码。它是一个兜底错误规范里表示“充电桩内部发生了未分类错误”。收到这个码首先要看有没有厂商自定义的vendorErrorCode如果没有就需要拉控制板日志、检查看门狗复位标志、堆栈溢出记录。很多InternalError其实不是偶发而是固件里有内存泄漏运行几天后崩溃重启。PowerSwitchFailure指功率开关继电器/接触器故障常见于粘连检测失败、驱动电路损坏。这个码的判断逻辑通常是在断开后检测到触点两端仍有压降或者闭合后检测不到电流。现场维修时要特别小心接触器粘连属于高危故障必须断电检查。ResetFailure出现在充电桩尝试执行复位但失败时。可能是复位电路问题、固件升级后无法正常重启也可能是外部看门狗没有释放。平台下发Reset指令返回Accepted后如果长时间没有收到BootNotification大概率就是卡在启动阶段需要现场断电重启。LocalListConflict是本地授权列表相关故障常见于平台下发SendLocalList后充电桩本地列表版本和平台不一致或者本地写入失败。这个码在离线计费和本地白名单场景中很关键排查时要看GetLocalListVersion返回值再对比平台记录的版本。OtherError是“我也不知道为什么”的错误码。规范允许厂商用它表示未列出的故障但实际项目里很多桩厂把一些临时性故障也归到这里。拿到OtherError必须结合info字段和vendorErrorCode才能定位。如果info也是空的那基本等于没报平台只能做模糊告警。NoError表示没有故障但别急着高兴。它出现在状态为Faulted时本身就是矛盾信号。我遇到过几次都是充电桩固件在异常分支里没有正确填充errorCode默认值给成了NoError。这种情况下平台不能把NoError当成“正常”而要结合其他状态判断是否进入异常保护。3. 容易被当成故障码的“伪故障码”除了ChargePointErrorCodeOCPP 1.6 里还有一批指令响应状态它们也会被团队在排查问题时报成“平台返回错误码”。这些状态虽然不叫故障码但处理不好一样会干扰线上运维。3.1 指令响应里的业务状态码平台给充电桩下发远程指令时充电桩会返回一个状态字段。常见的包括RemoteStartTransaction返回Accepted或RejectedRejected可能是因为充电桩正在充电、未插枪或者本地策略不允许。UnlockConnector返回Unlocked、UnlockFailed或NotSupportedNotSupported表示该桩没有电子锁。ReserveNow返回Accepted、Faulted、Occupied、Rejected、Unavailable。注意它也有一个Faulted表示充电桩处于故障状态无法预约。ChangeAvailability返回Accepted、Rejected、Scheduled。Scheduled通常是因为充电桩正在充电中无法立即切换但计划会在结束后执行。SendLocalList返回Accepted、Failed、NotSupported、VersionMismatch。VersionMismatch是最常见的本地列表版本号不连续导致。这些状态码的价值在于辅助判断平台下发的指令有没有生效。比如ChangeAvailability返回Scheduled时平台不应该立刻把桩标记为可用而是要等后续StatusNotification上报Unavailable后再更新状态。否则就会出现“平台认为已停用但现场还能充”的尴尬。3.2 状态上报里的“非故障状态”也要做区分OCPP 1.6 的ChargePointStatus里有几个状态虽然不带故障码但经常被平台误判成故障SuspendedEVSE、SuspendedEV、Unavailable、Finishing。SuspendedEVSE是充电桩因自身原因暂停输出比如功率模块过温降额、桩端急停被按下SuspendedEV是车辆 BMS 暂停充电比如电池电压达到限值。两者区别很大平台如果只看到状态变成挂起就发工单可能白跑一趟。Unavailable通常表示设备被远程禁用或本地维护属于计划内状态。Finishing则表示充电枪还未拔出但已完成充电正在等待用户拔枪。这些状态在状态机里都有明确迁移路径建议平台把状态迁移图提前设计好而不是一看到非Charging就跳到异常处理分支。4. 实操从一条 Faulted 日志到根因定位光知道枚举值还不够真正考验人的是现场怎么定位。下面这套流程是我在项目里反复用的基本可以覆盖 80% 的故障码排查场景。4.1 工具准备和报文抓取排查 OCPP 故障码至少需要三样东西充电桩设备日志、OCPP 报文记录、平台侧告警事件。设备日志在桩端可以通过调试串口或者远程 SSH 拿OCPP 报文可以用wscat、WebSocket抓包也可以直接在平台网关层打印完整报文。如果手上是一个正在测试的充电桩我推荐先用一个简单的 Python 脚本模拟 OCPP 服务端然后把桩接到自己的服务端上这样能拿到最原始的报文。下面是一段基于websockets库的最小示例用来打印收到的所有请求import asyncio import json import websockets async def handle(websocket): async for raw in websocket: print(RECV:, raw) try: msg json.loads(raw) msg_id msg[1] if msg[0] 2: # CALL action msg[2] if action BootNotification: resp [3, msg_id, {status: Accepted, currentTime: 2025-06-07T14:20:00Z, interval: 60}] else: resp [3, msg_id, {}] await websocket.send(json.dumps(resp)) except Exception as e: print(PARSE_ERROR:, e) async def main(): async with websockets.serve(handle, 0.0.0.0, 8760, subprotocols[ocpp1.6]): await asyncio.Future() asyncio.run(main())在测试环境用这种方式可以直观看到充电桩上报故障时的完整payload尤其是info、vendorErrorCode这两个字段现场很多问题就藏在里面。4.2 定位流程三步走第一步看状态组合。先抓到StatusNotification的完整报文记录status、errorCode、info、timestamp四个字段。比如{ connectorId: 2, status: Faulted, errorCode: OverCurrentFailure, info: Output current 82A, limit 80A, duration 5s, timestamp: 2025-06-07T14:23:11Z }从这段能初步判断是过流保护而不是随机的内部错误。接着再查同一时间段有没有StartTransaction、StopTransaction、MeterValues恢复时间线。第二步查设备日志确认硬件状态。OCPP 报文只能说明桩上报了什么不能说明为什么上报。这时要去控制板日志里找故障发生前的最后几个事件比如relay close failure、meter read timeout、can timeout。如果能对上根因基本就清楚了。第三步复现测试。如果故障是偶发的可以通过远程TriggerMessage请求触发一次StatusNotification让桩立刻上报当前状态。OCPP 1.6 支持TriggerMessage平台可以指定触发BootNotification、Heartbeat、StatusNotification等。这个指令在排查“桩已经离线但平台显示在线”时非常有用。4.3 故障码自测清单我整理了一个高频使用的自测清单每次遇到故障码就按顺序过一遍确认充电桩是否在线心跳间隔是否正常。拉取最新StatusNotification确认status和errorCode组合。查看是否有厂商自定义vendorErrorCode大多数桩厂都会在这个字段里给出更细的故障编号。检查timestamp是否和平台当前时间偏差过大防止时钟错误导致状态误判。查看充电桩控制板日志中的关键告警点。确认平台侧是否最近下发过配置变更或报文版本更新。这套流程下来大多数标准故障码都能定位到具体模块。5. 常见故障码排查与处理速查为了让现场运维更方便我把最常见的故障码和处理建议整理成了表格。这张表不替代厂家手册但能帮你快速判断优先级。故障码常见原因优先排查项处理建议OverVoltage电网电压波动、采样异常输入电压、采样电路检查电网质量校正电压采样系数UnderVoltage电网欠压、线缆压降大输入电压、接线端子检查线缆规格和接线紧固OverCurrentFailure接触不良、继电器粘连实际电流、充电枪接触状态断电检查枪座和继电器PowerMeterFailure电表通信失败、地址冲突RS485接线、电表地址重新配置电表参数EVCommunicationError与BMS通信超时CAN通信线、绝缘监测检查充电枪和车端接口ReaderFailure读卡器故障读卡天线、线序更换读卡模块ConnectorLockFailure电子锁卡涩锁舌、门磁开关清洁或更换电子锁GroundFailure接地不良、漏电流异常PE线、绝缘监测模块测量接地电阻更换绝缘监测HighTemperature端子过热、模块过热枪头温度、模块温度检查枪线端子清理风道InternalError固件异常、内存泄漏控制板日志、复位标志升级固件联系厂家分析PowerSwitchFailure继电器/接触器粘连触点压降、驱动信号断电更换功率开关ResetFailure复位电路异常看门狗、复位引脚检查复位电路LocalListConflict本地白名单版本不一致GetLocalListVersion重新下发本地授权列表OtherError未归类故障info字段和厂商错误码结合厂商手册定位NoError无故障或固件异常状态机逻辑检查固件错误码填充逻辑注意表中的“处理建议”是通用操作不是万能方案。同一个故障码在不同厂商的桩上可能对应完全不同的内部编号还是要以设备厂家提供的文档为准。6. 我踩过的几个 OCPP 故障坑作为负责过 OCPP 接入和运维的人有些坑是必须亲身体会才记得住的。这里挑几个典型的算是帮大家提前避雷。6.1 坑一NoError 出现时别直接当作正常某个项目里有批桩频繁上报Faulted NoError平台侧按“无故障”处理结果实际是急停被按下桩固件却没有正确填写错误码。后来我要求从info字段里捞关键字发现里面写着e-stop pressed这才定位到问题。所以看到NoError别太放心结合状态和厂商字段再看一眼。6.2 坑二HighTemperature 的阈值不是越小越好有一回客户投诉充电桩老是中断日志里全是HighTemperature但现场实测温度只有 60 多度。后来联系桩厂才发现固件里默认的温度保护阈值被设成了 60 度而这家桩的正常工作温度上限是 75 度。平台和桩厂扯了好几天最后只是改了个参数。所以遇到HighTemperature先确认保护阈值配置。6.3 坑三平台把 Unavailable 当成 Faulted 告警另一个项目里运维平台把Unavailable状态也归类为故障结果每次桩被远程禁用告警就刷屏。实际上Unavailable是计划内状态只有Faulted才应该触发故障工单。这个事提醒我状态枚举和错误码的映射关系一定要在平台里单独建一张表规则要清晰。6.4 坑四时间戳错乱导致状态机误判OCPP 1.6 报文里的timestamp如果不准平台侧的故障持续时长、恢复时间都会算错。有一回桩上报Faulted但timestamp比平台时间早了 8 个小时平台直接判定是陈旧消息丢弃了。结果就是桩现场已经故障平台却还显示在线。后来我们在网关层加了时间偏差校验超过 5 分钟就单独标记这才堵住了隐患。OCPP 1.6 的故障码本质上是一个“信号”不是最终答案。排查时要把它放到整条链路上看从桩端硬件、控制板日志到协议报文、平台状态机每一环都可能出问题。我自己现在拿到一条故障码第一反应永远是先看它的上下文而不是急着改配置。如果你正在做一个充电桩接入项目建议从一开始就把标准错误码、厂商错误码、状态枚举、平台告警等级分开建模后面运维会省心很多。