没有硬件实验室，怎么测 OCPP 1.6 充电桩

大多数 OCPP 缺陷不是电气问题。是少了一个字段、写错一个枚举值，或者状态机接受了一条本该拒绝的 StartTransaction。这些都不需要电流真的流过——也就是说，绝大部分 OCPP 测试可以在一台笔记本上完成。

以下是我们推荐给那些还在等硬件、或者有硬件但没法为每次提交都占用它的团队的方案。

先决定你在测哪一边

这听起来是废话，却是白费力气的第一大来源。人们嘴里的「OCPP 测试」其实是两件互相独立的事：

测一台充电桩。 你有一份应该会讲 OCPP 的固件，你想知道它到底会不会。你需要一个行为像 CSMS、并且会评判充电桩发出内容的东西。

测一套 CSMS。 你有一个后端，你想知道它能不能接住真实充电桩的行为。你需要一个行为像充电桩、并且可以被指使去乱来的东西。

这两件事需要的工具是相反的，为其中一件做的工具，对另一件几乎没用。先把这个决定做了。

测一台充电桩

把充电桩指向一个你自己控制的 CSMS，然后看它说什么。充电桩并不知道、也不在乎那个端点是生产环境的基础设施，还是你机器上的一个进程。

把充电桩的中央系统 URL 设成你的端点。几乎每台充电桩都会在 Web 界面或配置文件里暴露这一项，通常长这样：

wss://10.0.1.50:9000/ocpp/CP001

然后按顺序走一遍消息流程，因为后面的消息依赖前面的：

1. BootNotification。 检查 chargePointVendor 和 chargePointModel 是否都在——两者都是必填，而早期固件里两者常常留空。确认充电桩遵守你回的 interval，而不是用写死的值。
2. Heartbeat。 确认它按你在 BootNotification 响应里给的间隔到来，并且当你用 ChangeConfiguration 改动之后，充电桩会跟着调整。
3. StatusNotification。 让接口依次走过 Available、Preparing、Charging、Finishing。留意规范不允许的状态迁移，也留意那种在指整站时却上报 connectorId: 0 的充电桩。
4. StartTransaction / StopTransaction。 用你能返回的每一种 AuthorizationStatus 去检验 idTag 的处理——Accepted、Blocked、Expired、Invalid、ConcurrentTx。拒绝一笔交易是被测得最少、坏得最多的那条路径。
5. MeterValues。 确认采样间隔与配置一致，单位和 measurand 的取值也和你预期的一样。

这个练习里最有价值的部分，是故意返回失败。能正确处理 Accepted、却在 Blocked 上翻车的固件极其常见，因为幸福路径是唯一被人走过的那条。

测一套 CSMS

这一边你需要一台模拟充电桩，而让模拟器有用的，不是它能把一次充电会话跑完。是它能做出真实充电桩在出岔子时会做的那些事。

值得自动化的场景：

• 冷启动。 一台 CSMS 从未见过的充电桩发来 BootNotification。它是自动纳管，还是拒绝？
• 交易中途重连。 在一笔进行中的交易期间断掉 socket，然后重连。交易必须活下来；电表读数不能从头开始。
• 时钟偏差。 发送差了几个小时的时间戳。无条件信任充电桩时钟的 CSMS，会产出无法对账的计费记录。
• 重复的 StartTransaction。 同一个 idTag、同一个接口，发两次。ConcurrentTx 的存在是有原因的。
• 离线队列灌入。 断线期间把消息缓存起来，重连时一次性灌过去。天真的 CSMS 实现就是在这里丢数据的。
• 畸形报文。 缺必填字段、类型错误、未知枚举值。CSMS 应该回一个 CALLERROR，而不是关掉连接或者把 worker 弄崩。

规模也重要，但比人们想的要晚。一百台模拟充电桩能帮你找出并发缺陷；一万台找出的多半是你数据库的上限，那是另一场调查。

放进 CI

把这一切用软件来做的理由，是软件可以在每次提交时跑。一个有用的 OCPP CI 任务大致长这样：

1. 启动被测的 CSMS
2. 对着它启动 N 台模拟充电桩
3. 跑一段脚本化的场景——连接、启动、授权、充电、停止、断开
4. 对结果状态下断言：交易已关闭、电表读数单调、没有孤立会话
5. 拆掉环境并输出报告

这能抓住硬件测试抓得太晚的那些回归。一个改动破坏了 StopTransaction 的原因码，在 CI 里发现很便宜，在现场试点里发现很贵。

这套方法覆盖不到什么

对局限保持诚实很重要，因为一套绿灯却掩盖了一整类故障的测试集，比没有测试集更糟。

电气与安全行为。 接触器时序、接地故障检测、温度降额、紧急停止。这些在 OCPP 上全都看不见，也全都无法模拟。

真实的网络状况。 充电桩活在运营商 NAT 后面的蜂窝链路上。丢包、数秒级延迟、静默断连——localhost 上的模拟器不会重现这些，而它们要为相当大一部分生产事故负责。

厂商的怪癖。 每家制造商都会在规范的某个角落上做出不同的解读。这些只能靠接上那家厂商的真实硬件才能发现，没有替代品。

正式认证。 通过你自己的测试并不等于 OCPP 认证。那件事仍然要走 OCA 的流程和他们的测试工具。

所以一个合理的方案大致是这个形状：软件测试持续、低成本地抓住大多数缺陷；硬件测试确认只有硬件才能确认的东西；等前两项都干净了，再去做认证。

工具

这个领域有不错的开源工作——docile-charge-point 可脚本化，而且已经存在多年；Python 的 ocpp 库给了你两边都能用的构件。

我们为第一件事做了 TestPilot——一个评判充电桩并导出一致性报告的 CSMS——为第二件事做了 SimPilot，它对着你的后端模拟充电桩，包括上面那些故障模式。如果你想要的是把协议层放进自己的 Go 服务里，而不是在旁边放一个工具，那么 OcppPilot 就是另外两者所依赖的那个库。