摘要
在充电桩接入运营平台之前，研发和联调人员通常需要反复验证 WebSocket 连接、OCPP 报文、充电状态变化、异常状态和长连接心跳。如果每次测试都依赖真实硬件，不仅准备周期长，还会受到现场网络、车辆和电气环境的影响。本文介绍一套自研 OCPP 1.6 充电桩模拟系统，重点说明它如何把充电桩抽象为可管理、可连接、可操作的测试对象，并通过设备管理、枪状态模拟、报文日志和并发测试帮助研发人员定位协议兼容问题。
一、为什么需要充电桩模拟系统
OCPP 1.6 采用基于 WebSocket 的持续连接模型，充电桩与平台之间会持续交换启动、状态、计量、心跳和交易相关消息。协议联调中的问题，往往不是单个接口能否返回，而是连接建立、消息方向、状态机和时序是否同时正确。
自研模拟系统的价值在于，将这些需要硬件配合的动作转换为后台可重复执行的测试步骤：研发人员可以创建模拟桩，配置其连接地址，手动连接或断开，控制充电枪状态，启动或停止充电，模拟故障，并在同一界面查看设备状态和报文记录。这样可以在接入真实设备前，先验证平台的协议处理能力。
二、系统整体结构
从使用视角看，系统由四个相互配合的部分组成：
设备管理：维护模拟充电桩及其连接参数，展示在线、离线和未激活等设备状态。
连接与会话：根据模拟桩配置建立或关闭 WebSocket 会话，持续维护设备连接状态。
枪状态与充电控制：对连接器执行可用、插枪、充电、暂停和故障等状态操作，并支持开始或停止充电。
日志与测试：保存请求类、请求数据、回复数据和时间信息，支持按测试任务批量管理设备并形成测试结果。
典型数据流可以概括为：测试人员在后台发起操作，模拟器将操作转换为 OCPP 1.6 消息或设备状态变化；平台接收消息后完成解析、业务处理和响应；系统再把原始请求、响应和处理时间写入日志，形成可追溯记录。
三、设备管理与连接控制
设备管理页面以卡片方式展示模拟桩。每个设备对象包含设备编码、WebSocket 地址、电流、电压、功率、连接器数量、连接器状态和累计电量等信息。页面提供新增电桩、导入电桩、批量删除和清空电桩等维护能力，适合在测试环境中快速准备一组设备。
图 1 设备管理页面：展示连接状态、功率参数、连接器状态及操作入口
连接控制与设备状态分开呈现：设备层面可以执行连接、断开和报文查看；连接器层面可以执行充电、停止、状态切换和故障模拟。这样的拆分符合充电桩实际对象模型，也便于分别验证“设备是否在线”和“连接器是否处于正确状态”。
四、连接器状态模拟与充电流程
真实充电流程并不是简单的“点击开始”和“点击结束”，而是多个状态之间的转换。模拟系统通过连接器操作入口，让测试人员可以主动构造不同阶段的状态，用于验证平台的状态机和异常处理。
可用：连接器处于空闲状态，可以接受新的充电请求。
插枪：模拟车辆已经连接，但充电尚未正式开始。
充电：模拟交易进行中，可以观察充电功率、电流和计量值的变化。
暂停：模拟车辆侧或设备侧暂时停止输出的场景。
故障：模拟过压、读卡器故障、弱信号或其他错误，用于验证平台告警和恢复逻辑。
在联调过程中，建议先完成“连接器可用 → 插枪 → 开始充电 → 停止充电 → 恢复可用”的主流程，再逐项加入暂停、断开和故障场景。每一步都应同时观察设备状态、充电计量和报文日志，避免只验证页面结果而遗漏协议层问题。
五、OCPP 1.6 报文交互与日志观测
OCPP 1.6 的报文通常封装在 WebSocket 文本帧中，常见消息类型包括 CALL、CALLRESULT 和 CALLERROR。CALL 用于发起请求，CALLRESULT 用于返回成功结果，CALLERROR 用于返回错误。实际联调时，除了检查 JSON 是否可解析，还需要核对消息方向、唯一标识、Action、字段类型和响应时序。
系统的充电桩日志页面提供了请求类型、请求类、请求数据、回复数据和请求时间等字段。下图展示了 HeartbeatRequest 的真实日志记录：模拟设备周期性发送心跳请求，平台返回包含 currentTime 的响应，日志同时保留了请求和回复 JSON。
图 2 充电桩日志页面：记录 HeartbeatRequest 的请求、回复和时间信息
以心跳为例，可以用下面的最小流程检查平台实现：
确认 WebSocket 连接已经建立，且设备标识与会话一致。
确认设备能够发送 HeartbeatRequest，消息格式为 OCPP 1.6 约定的数组结构。
确认平台返回 CALLRESULT，并在 payload 中提供有效的 currentTime。
确认日志保存了请求与响应，并能根据设备编码和时间定位原始记录。
同样的方法可以用于验证 BootNotification、StatusNotification、MeterValues、Authorize、StartTransaction、StopTransaction、RemoteStartTransaction 和 RemoteStopTransaction 等典型交互。具体 Action 是否启用，应以当前模拟器版本和测试配置为准。
六、并发测试与批量操作
当单桩流程验证通过后，下一步通常是验证平台在多设备同时接入时的表现。系统提供并发测试入口，可以新建一个测试任务，选择全部设备或手动选择设备，并在测试详情中批量执行连接、开始充电、结束充电和断开等操作。
图 3 并发测试页面：创建并发测试任务并管理测试结果
并发测试的重点不是单纯增加设备数量，而是观察多个会话同时发生时，平台是否仍能正确区分设备编码、连接器编号、消息唯一标识和交易标识。建议重点记录以下指标：
连接成功率：设备发起连接后，平台是否在预期时间内完成会话建立。
首包时延：从连接建立到第一条有效 OCPP 消息的耗时。
消息关联正确率：请求和响应是否始终通过唯一标识正确匹配。
状态一致性：页面显示的在线、充电、停止和故障状态是否与日志一致。
异常恢复能力：断开、重连、超时和错误响应后，设备是否可以回到可测试状态。
七、一个可落地的测试用例
这个用例覆盖了接入、状态、交易和日志四类检查点，适合用作平台接入前的冒烟测试。出现失败时，应优先依据日志中的请求类、请求数据、回复数据和时间进行定位，而不是只根据页面上的最终状态判断原因。
八、工程实践中的注意事项
测试环境与生产环境隔离：模拟器应使用独立账号、独立设备编码和独立 WebSocket 地址，避免误连生产系统。
敏感信息不进入公开文章：发布截图前检查账号、密码、Cookie、内部域名、真实设备编号和令牌。
协议版本明确：OCPP 1.6 的字段和消息类型不能直接套用 OCPP 2.0.1，测试报告中应标注协议版本。
状态转换可重复：每个测试用例都应定义初始状态和结束状态，确保失败后能够快速恢复并重跑。
保留原始报文：业务日志适合检索，原始 JSON 更适合定位字段、编码和时序问题，两者都应保留。
九、总结
OCPP 1.6 充电桩模拟系统的核心不是提供一个简单的后台列表，而是把充电桩接入测试中最难复现的部分结构化：长连接可以被管理，连接器状态可以被主动构造，充电流程可以被重复执行，报文可以被完整观测，多设备场景可以被批量验证。
通过这套方式，研发人员可以先在可控环境中完成协议接口、状态机、交易流程和异常恢复的验证，再进入真实桩和真实运营环境联调，从而缩短问题定位路径，降低现场调试成本。对于后续演进，建议继续完善测试报告、消息过滤、失败重试、脚本化场景和更多 OCPP 1.6 Action 的覆盖，让模拟系统从“手工操作工具”逐步发展为“可编排的协议测试平台”。
