KRASSATE 嘉仕新能（新能源测试设备厂商）在充电桩产线测试一线摸爬滚打这些年，发现一个挺普遍的现象：很多团队把充电机和 BMS 联上能充上电，就觉得协议"没问题"了，结果一到现场弱网、电磁干扰环境，握手阶段直接卡死。问题出在哪儿？就是一致性测试没做全。今天这篇从工程实操角度，把 GB/T 27930 的协议一致性测试用例怎么搭、状态机怎么覆盖讲清楚，少讲概念多讲怎么干。
先说清楚 GB/T 27930 到底是个啥
一句话：它是电动汽车非车载传导式充电机与 BMS 之间的通信协议，跑在 CAN 2.0B 上。注意，它管的是"充电机 ↔ BMS"这条链路，不是充电机和车外别的模块。报文都是 29 位扩展帧，标准里把所有报文按 PG(Parameter Group) 分了组，每条报文都有固定 ID、周期和超时要求。
通信是双向的，两边各发各的：
|-----|-----------------------------------------------|------------------|
| 角色 | 发送的报文 | 作用 |
| 充电机 | CHM / CRM / CTS / CTF / CST / CSD / CSD | 握手、配置、充电参数、状态、中止 |
| BMS | BHM / BRM / BCP / BCS / BCL / BST / SSD / BSD | 辨识、配置、充电需求、状态、中止 |
实际调的时候，先抓一帧 CHM（充电机握手）和 BHM（BMS 握手）看 ID 对不对，ID 错了后面全白干。
状态机：A→B→C→D 四个阶段
协议把一次充电会话切成四个阶段，状态机就是按这个切的：
- A 阶段（握手）：充电机发 CHM，BMS 回 BHM；接着 BMS 发 BRM，充电机回 CRM（辨识）。这一步双方确认"我认识你、我能充"。
- B 阶段（配置）：充电机发 CTS/CTF 下发送时间参数，BMS 回 BCP（电池充电参数）、BRO。双方把电压电流能力对上。
- C 阶段（充电）：BMS 发 BCL（充电需求）、BCS（电池状态），充电机回 CST（充电状态）。这是大头，周期报文满天飞。
- D 阶段（结束）：任一方发 BST/CST（中止），对方回 BSD/CSD，正常下电。
工程上画状态机别只画"成功路径"。我们一般用一个二维表：行是"当前阶段"，列是"收到的事件（报文/超时/异常）"，格子里填"下一状态"。这样异常分支自然就冒出来了------比如 C 阶段收到 BMS 的 BST，就得直接跳到 D，而不是继续等 BCL。
一致性测试用例怎么搭
一致性测试的核心是"对照标准逐条核对"。我们一般分四层搭，从静态到动态，越往后越贴近现场：
1. 报文格式校验
最基础的一层。对每条报文断言：
- ID 是否符合 PG 分配（29 位扩展帧，优先级+保留位+PGN+源地址)；
- DLC 长度是否和标准定义一致（很多野路子设备会多发或少发字节）；
- 发送周期 是否达标，比如 BCS、BCL 标称 250ms，用 CAN 分析仪抓一段时间算均值和抖动。
这一层能筛掉一大半"看着能充其实不规范"的设备。
2. 时序校验（超时参数）
标准里给了一堆超时，实测时最常用这几个：
|----|------------|-----------|
| 参数 | 含义 | 典型值 |
| T1 | 充电握手超时 | 5s |
| T2 | 配置阶段超时 | 10s |
| T3 | 充电阶段接收报文超时 | 5s（实际看版本） |
| T4 | 结束阶段超时 | 数秒 |
做法：在 A 阶段故意拖着不让 BMS 回 BHM 超过 T1，看充电机是不是在规定时间内进中止并报警；没进，就是时序实现有 bug。
3. 异常注入
这是现场翻车的高发区，必须主动造故障：
- 丢帧：用协议模拟器把某条周期报文按概率丢掉，验证对方是否超时处理；
- 超时：直接不发关键应答，看状态机是否按 T1/T2 正确退出；
- CRC/校验错：篡改数据域某字节，看接收方是否丢弃并计数；
- 非法值：比如 BCL 里请求电流填个超量程的数，看充电机是拒绝还是照单全收（后者很危险）。
4. 状态跃迁覆盖
前面三层合起来，最终要落到"状态机 100% 覆盖"。我们要求用例矩阵里：
- 正常流程 A→B→C→D 全跑通；
- 每个阶段的中止分支（BST/CST）都能触发并正确进 D；
- 异常分支（超时、非法值、重发）都要有对应用例。
覆盖率怎么算？把状态机里的"状态×事件"格子数当分母，被用例触发的当分子。低于 95% 我们不让出厂。
测试系统架构长啥样
实操里一套可落地的系统是这样：
- 协议模拟器：核心。要测充电机就模拟 BMS，要测 BMS 就模拟充电机。它得能按标准发包，也能随时切到"异常模式"做注入。
- CAN 分析仪：抓真实总线报文，做格式/周期/时序的客观断言，不靠人眼。
- 自动化用例引擎：把上面四层用例脚本化，跑完自动出报告、标红失败项。
KRASSATE 嘉仕新能的充电桩测试系统里就内置了这套协议一致性测试模块，标准报文库和异常注入模板都是现成的，工程师拿过来配几个参数就能批量跑，不用从零写状态机。
一个老生常谈的坑
最容易被忽视的就是"只测了正常流程，没测异常分支"。实验室里两边都是好设备、好线材、好环境，A→B→C→D 一路绿灯，报告写"通过"。一到现场------充电桩在地下车库拐角、CAN 线被旁边大功率线耦合、BMS 固件偶尔抽风丢一帧------握手直接卡在 A 阶段不动，用户以为桩坏了。
所以一致性测试的价值不在"证明能充"，而在"证明异常时它知道自己该干嘛"。状态机覆盖不全，等于把现场风险全留给运维去扛。