1. 为什么我把GB/T27930当车桩联调的第一道坎来学先交代一下背景。我做充电桩嵌入式软件和BMS联调有几年了头一次独立负责车桩联调时手里只有一份协议PDF和一台上位机抓包工具。那时候最痛苦的还不是代码怎么写而是报文到了总线上面对密密麻麻的十六进制数据根本不知道哪条是握手、哪条是参数配置、哪条是故障上报。翻协议文档翻到头晕一个字一个字对还是容易搞混。后来经验多了才明白GB/T27930-2015这套协议本质上就是一整套车和桩对话的规则。它规定了非车载传导式充电机与电池管理系统BMS之间通过CAN总线通信的语言什么时候说话、先说哪句、数据放在哪个字节、出了问题怎么报告。这套标准适用的对象是直流充电场景也就是大家常说的快充桩。只要充电功率超过一定门槛、需要用充电机直接给动力电池充电基本都绕不开它。说它是第一道坎是因为整个通信过程分为握手、辨识、参数配置、充电、充电结束这五个阶段阶段之间有严格的状态流转关系。任何一个阶段的报文ID配错、字节偏移算错、CRC校验不过都会导致充电启动失败。而这些问题在实车上往往不会直接告诉你哪错了只会显示绝缘检测失败BMS超时连接中断这类模糊信息。这篇文章我不打算罗列协议全文而是按一次完整的充电流程来走一遍——从低压辅助上电开始到手握手、辨识、参数配置、正式充电再到故障中止把每一条关键报文的CAN ID、字节定义、传输方向、易错点全部拆开讲。给正在做车桩联调、充电桩开发或BMS测试的工程师一份可以直接对照着排查的实操笔记。{% hint styleinfo %} 协议版本说明GB/T27930-2015是在2011版基础上修订的2015版调整了部分报文周期、超时时间、故障等级分类等内容。本文以2015版为准如果项目里遇到2011版的老车老桩字节定义和超时参数会有差异对接时务必先确认双方版本。 {% endhint %}2. 看懂CAN 2.0B扩展帧报文ID才算真正会读2.1 29位标识符拆解优先级、PGN、源地址GB/T27930-2015基于CAN 2.0B扩展帧传输CAN ID长度是29位不是CAN 2.0A的11位标准帧。光这一点就坑过不少人有些工程师直接把J1939的标准帧格式套过来解析出来全是乱的因为两者位分配逻辑完全不同。29位ID的分配规则在行业里有个基本共识按从高位到低位排列bit 26 ~ bit 28优先级Priority占3位对应ID的最高3位。GB/T27930里报文优先级一般取6二进制110。计算时要注意CAN ID在代码里通常用十六进制表示0x18开头就是优先级6的常见写法。bit 8 ~ bit 25PDU格式与组扩展共18位其中包含PFPDU格式和PSPDU特定组合后形成PGN参数组编号。bit 0 ~ bit 7源地址Source Address占8位。BMS的源地址在2015版里规定为0xF4充电机的源地址为0x56。我在做抓包分析时习惯先把完整CAN ID写成二进制再按这个位数切分。比如一条ID为0x18FF56F4的报文二进制展开后高3位是110对应优先级6中间的18位是PGN低8位0xF4说明这条报文是BMS发的。至于PGN怎么算要分PDU1和PDU2两种格式下面细说。2.2 PDU1与PDU2格式的判断方法PDU格式的判断看PF字节大小。如果PF在0到239之间属于PDU1格式报文是点对点定向传输PS字段为目标地址如果PF在240到255之间属于PDU2格式报文是广播发送PS字段为组扩展。具体到PGN的计算规则PDU1格式下PGN的高位字节等于PF低位字节为0。例如PF0x01则PGN0x010000。PDU2格式下PGN等于PF左移8位加上PS。例如PF0xFFPS0x56则PGN0xFF56。为什么要纠结这个因为在CANoe或者PCAN的报文解析窗口里直接显示的是CAN ID而不是PGN。如果不懂PF和PS的区分看到0x18FF56F4和0x180156F4会误以为它们PGN相同或者指向同一个参数组实际上一个是广播报文、一个是定向报文含义完全不同。联调现场很多对不上版本号的问题根源就是这里算错了。2.3 终端电阻与波特率不解决物理层后面全是玄学报文解析的前提是物理层稳定。直流充电桩与BMS之间通常使用250kbps波特率也就是CAN 2.0B的标准波特率之一。但250k只是默认值国标通信协议中没有强制规定波特率必须是多少实际项目里也可能出现500kbps。我遇到过一辆车和桩的波特率设置不一致现象是抓包工具里偶尔能看到报文、大部分时间超时因为波特率不匹配导致错误帧率极高。物理层另一个高频坑是终端电阻。CAN总线两端需要各接一个120欧姆的终端电阻总线上只有跨接在CANH和CANL之间的60欧姆等效电阻时信号质量才正常。有些充电桩的控制器板上默认没焊终端电阻靠外部接线联调时如果发现波形振铃严重、总线进入bus-off先量电阻不要急着调软件。{% hint styleinfo %} 判断总线物理层是否正常有个笨办法用万用表量CANH与CANL之间应该有约60欧姆。如果量到120欧姆说明只有一端接了终端电阻如果量到接近0说明总线某处短路或电阻焊错位置。 {% endhint %}3. 握手与辨识阶段从低压上电到版本对齐的逐字节拆解3.1 握手阶段整体状态流程一次完整的直流充电启动从物理连接完成之后开始。低压辅助电源上电后BMS先开始周期性发送BMS握手报文简称BRM也叫BRO等待充电机回应。充电机收到BRM后回发充电机握手报文简称CRM/CRO。双方完成握手进入辨识阶段。这里有个容易混淆的点GB/T27930-2015里握手阶段有专门的报文辨识阶段也有专门的报文。实际开发中经常听到BRM、BRO、CRM、CRO、BHM、CHM这一串缩写如果不理清顺序看抓包数据时就会乱。我按实际抓包顺序整理如下阶段报文缩写发送方方向周期说明握手BRM/BROBMSBMS→充电机250msBMS握手报文含BMS版本号和电池类型握手CRM/CRO充电机充电机→BMS250ms充电机握手报文含充电机版本号并确认握手成功辨识BHM/BHOBMSBMS→充电机250msBMS辨识报文含BMS最高允许充电总电压辨识CHM/CHO充电机充电机→BMS250ms充电机辨识报文含充电机最低/最高输出能力确认辨识完成辨识BRM/BRO二次交互双方双向按需部分实现中版本信息需要二次确认具体看双方协议实现我特意在表格里把BROBHOCHO这类带O的缩写也列出来了因为很多协议文档的ASCII码图里报文名称用的是BRM、BHM但实际报文代号却是BRO、BHO。同一个报文名称和代号并存新手很容易对不上号。3.2 BMS握手报文BRM逐字节说明BRM报文是BMS上电后第一条主动发出的报文整车端通常会在低压上电、VCU或BMS唤醒后开始发送。CAN ID一般为0x1801F456其中0x18对应优先级60x01是PF0xF4是PS目标地址为BMS自己说明这是从充电机视角看的目标地址0x56是源地址充电机地址。等等上面这个ID算出来源地址是0x56也就是充电机发的。发方是BMS怎么源地址会是0x56这里要多说一句在J1939协议族里CAN ID里的源地址字段指向发送节点但在GB/T27930的很多报文里ID往往经过重新映射不同整车厂商实现并不完全统一。我实测过不同品牌车辆同样一条BRM报文有的车用0x1801F456有的车用0x18FFF456ID定义上存在差异。因此实际开发时不要死记某篇文章给的标准ID要以你项目所依据的协议版本号和实测抓包为准。标准文本对各报文的PGN定义有规定但落地映射到CAN ID时厂家实现会有差异。这个坑我在第三节末尾单独说。BRM报文的数据段8字节一般定义为第1字节BMS版本号主版本如0x01第2字节BMS版本号副版本如0x0A第3字节电池类型01表示铅酸02表示镍氢03表示锂离子04表示超级电容第4字节电池序号或厂商编码第5字节BMS软件版本号第6字节BMS硬件版本号第7字节保留或厂商自定义第8字节保留或厂商自定义注意具体字节分配在标准原文里有定义但厂商自定义区域经常被拿来扩展。我见过有整车厂把电池额定容量、电池串并数塞进这两个保留字节的做法。解析时如果发现自己的桩收到的BRM报文数据段和协议文档对不上不要急着改代码先用厂商提供的实车数据字典核对。3.3 充电机握手报文CRM与辨识确认逻辑充电机收到有效的BRM报文后开始发送CRM报文回应。CRM报文数据段关键字节是充电机握手成功标志和充电机版本号充电机版本号主版本、副版本各占一个字节握手成功标志在特定字节位置置为0xAA表示成功0x55表示失败有些厂家的实现会在0xAA/0x55基础上增加其他含义。这里有一个容易踩的时序坑2015版协议规定BMS在发出BRM报文后等待充电机CRM报文如果超时未收到BMS会持续发送BRM并可能上报故障。但部分老桩在收到BRM后不会立刻回CRM而是先完成绝缘检测等内部流程导致BMS侧已经超时了。联调时如果看到BMS端一直报握手超时不要只怀疑桩没发CRM先确认桩是否在内部检测阶段堵塞了主循环。辨识阶段的核心是版本对齐和电气参数范围匹配。BMS辨识报文BHMBHO里包含BMS最高允许充电总电压充电机辨识报文CHMCHO里包含充电机最低输出能力和充电机最高输出能力。双方要通过这几个数值判断彼此的电压范围是否匹配不匹配就直接中止连参数配置阶段都进不去。{% hint styleinfo %} 实车联调中握手阶段最常见的失败原因不是代码逻辑错误而是报文周期不匹配。BMS按250ms周期发BRM充电机如果按500ms周期回CRM某些BMS实现会在300ms内判定超时。别问为什么有些车能充有些车不能充先把周期对齐。 {% endhint %}4. 参数配置与充电阶段BCP/BCL/BCS/BSM/CCS如何分工4.1 参数配置阶段的核心报文BCP握手和辨识完成之后进入参数配置阶段。这一阶段最核心的报文是BMS参数配置报文BCP由BMS发送给充电机。BCP报文里携带的是充电机做功率计算和电压电流配置所必需的全部参数动力蓄电池单体最高充电电压、最高充电电流、最高充电总电压、最低充电总电压、电池额定容量、电池单体数量、动力蓄电池允许的最高温度、最低温度等。以单体最高充电电压为例字节定义通常是两个字节精度0.1V也就是实际电压值 原始值 × 0.1V。如果原始值为0x04D2十进制1234实际电压就是123.4V。最高充电总电压同样按0.1V缩放最高充电电流按0.1A缩放额定容量按0.1Ah缩放。每一个参数都涉及数据偏移和缩放解析时最忌讳直接把原始值当物理量用。BCP报文的数据段在标准里定义为13个字节超过了一帧CAN报文8字节的上限所以实际传输时走的是多帧传输协议也就是ISO-TP或者J1939的传输协议机制。关于多帧报文的拆包和组包我放到文章第6节专门讲这里先不展开。充电机收到BCP后需要根据电池参数计算自身是否具备充电能力。如果充电机输出电压范围与电池电压范围不匹配或者最大输出电流小于电池需求充电机会回发CSP参数配置报文置失败标志并附上失败原因。BMS收到失败标志后会进入错误处理或直接中止充电。4.2 正式充电阶段BCL控制需求BCS实时上报参数配置成功后BMS开始发送电池充电需求报文BCL充电机根据BCL的内容实时调整输出电压和电流。BCL报文的核心字段包括充电电压需求和充电电流需求分别按0.1V和0.1A缩放。充电机解析BCL后执行电压环和电流环调节然后通过充电机充电状态报文CCS上报当前实际输出电压、输出电流、充电模式、充电机故障状态等。BCL是充电过程中实时性要求最高的报文之一周期通常是50ms甚至更短。如果充电机在50ms内没有收到新的BCL报文BMS侧或充电机侧都会判定通信超时并触发保护动作。这里有一个很现实的工程问题充电机主控的CAN接收队列深度不够当总线上同时存在BCL、BCS、BSM、CCS等多条周期报文时偶尔会发生丢帧。一帧BCL丢失可能没关系连续丢几帧就触发保护了。建议在充电机代码里单独为BCL配置FIFO或专用接收邮箱并加超时看门狗计数器。BCS报文是BMS充电状态报文由BMS周期发送包含电池当前SOC、当前充电总电压、当前充电电流以及最高单体电压和最高温度等。它的作用主要是让充电机掌握电池当前状态便于在电池接近满充时进行涓流切换或准备停止充电。BCS和BCL配合使用BCL提需求BCS报实际。4.3 BSM报文与单体电压温度监控BSM电池状态信息报文是充电阶段定时上报的电池状态快照周期一般较长常见的是100ms到1s不等具体看厂商实现。报文里包含电池最高单体电压、最高电压单体编号、最高温度、最高温度编号、最低温度、最低温度编号、电池组电压、电池组电流等信息。我调试时遇到过一种情况BMS上报的BSM报文里最高单体电压和BCS里的最高单体电压数值对不上一个越来越高一个恒定不变。查到最后发现是BMS端的BSM报文和BCS报文来自两路不同的采样一路是充电机采样电路一路是BMS自身采集两者本身就有微小差异。但如果两个数值差异过大充电机会统一采用更保守的数值进行保护。所以解析时不要只看一条报文就下结论要把BCL、BCS、BSM三类报文的电压、电流、温度交叉比对。4.4 充电机侧的CCS报文与CML报文CCS报文由充电机周期发送字段包括实际输出电压、实际输出电流、充电机当前工作模式、充电机故障状态等。充电模式常见定义0x01为恒压充电模式0x02为恒流充电模式0x03为恒功率充电模式。充电机在从恒流转恒压的切换瞬间CCS里的充电模式字段会变化BMS也会根据这个字段调整自己的需求策略。CML充电机最大输出能力报文则是在正式充电前或充电过程中由充电机告知BMS自己的最大输出能力范围包括最大输出电压、最小输出电压、最大输出电流。BMS会根据CML限制BCL里的电压电流需求确保不超出充电机能力。如果BMS需求超过了CML的限定值现场常见现象是充电机按自己的最大能力输出但BMS端认为输出不足报故障。这种情况在电池包电压平台较低而充电机电压范围下限较高时特别容易出现。{% hint styleinfo %} BCL、BCS、BSM三者的采样时间基准不同解析时要把时间戳打上。很多现场问题看单帧数据都对但画成曲线后就会发现问题——比如电流需求已经降到0实际输出电流还在几十安不等这说明充电机的控制环响应滞后不是协议解析问题。 {% endhint %}5. 中止充电与故障诊断BST/CST状态字背后的判断逻辑5.1 正常中止流程双方如何礼貌地停止充电充电完成或人为停止时BMS会发送BST报文BMS中止充电报文充电机收到后回发CST报文充电机中止充电报文双方确认后停止功率输出。BST报文和CST报文都有中止充电状态和中止充电原因两个关键字段数据段格式高度相似。BST报文里中止充电原因常见的定义有0x01表示电池充满0x03表示电池温度过高0x04表示电池电压过高0x05表示电池单体电压过高0x06表示充电电流过大0x07表示电池绝缘故障0x08表示通信超时0x09表示BMS内部故障。具体定义在2015版协议里有明确列表不同厂家可能在此基础上扩展但通用故障码基本一致。这里说一个很多初级工程师容易忽略的点充电机收到BST报文后应该立即停止功率输出而不是等CST发送完成后再停。因为BST报文本身就是一个保护信号BMS发出BST的同时可能已经切断了接触器如果充电机继续输出会产生拉弧或电压冲击。正确做法是CAN接收中断里解析到BST且中止原因为非正常类型时直接置停止PWM标志硬件层面切断输出。5.2 故障诊断如何从故障字里定位根因GB/T27930-2015里的故障诊断核心就是阅读BST/CST里的故障字以及充电过程中BCS/CCS报文里的故障标志位。但故障字只是结果真正要快速定位故障需要把故障字、阶段状态、关键参数三者联动来看。举个例子。现场充电桩报电池绝缘故障先不用急着拆BMS。把抓包数据拉出来看BST报文里中止充电原因是否为0x07绝缘故障然后看BCS报文里当前电池总电压、当前充电电流、电池最高温度是否异常。如果BCS显示电池总电压为零那很可能是高压采样回路断开或接触器未吸合属于电气连接问题而不是电池本身绝缘损坏如果BCS显示电压正常、电流正常只是绝缘故障字置位那就要查充电桩侧的绝缘检测模块可能是检测模块本身误报。另一个典型场景是通信超时故障。BMS报文周期是250ms充电机如果200ms没收到BCL就判定超时实际车桩双方周期配置不一致就会频繁报通信超时。这时候看CAN报文时间戳最直观如果某条周期性报文的实际周期和预期周期明显不符比如BSM报文周期被刷成了1s而充电机期望250ms那就是BMS端报文周期配置问题。5.3 故障等级一级故障、二级故障、三级故障的区别2015版协议把故障分成不同的级别充电机要根据故障级别采取不同的响应策略。一级故障属于致命故障立即停止输出断开接触器二级故障属于严重故障需要降功率或限流运行三级故障属于一般故障可维持运行但需要在界面提示。我在联调中遇到过一种情况BMS发出的BSM报文里某个故障标志位从0变1又变回0充电机因此没有做任何保护动作。这个案例提醒我故障处理逻辑里必须加持续时间判断或重复次数判断单帧故障标志置位可能是干扰或瞬时抖动连续3帧或持续50ms以上才应该认定故障成立。这个防抖逻辑如果不加充电桩会在高速上频繁跳枪用户体验很差。{% hint styleinfo %} 故障诊断的排查链路建议按物理层→链路层→应用层→策略层四步走。物理层查终端电阻、CANH/CANL电压链路层查报文ID、周期、错误帧应用层查具体字节含义策略层查故障判定阈值和响应动作。跳过前两层直接查应用层会浪费大量时间因为很多应用层问题本质是CAN收发器信号质量差导致报文错乱。 {% endhint %}6. 长报文拆包与组包一帧装不下的数据怎么传6.1 为什么会出现多帧传输CAN 2.0B扩展帧的数据场最多8个字节而BCP报文有13个字节BSM报文内容也多单帧根本装不下。GB/T27930-2015沿用了SAE J1939的传输协议Transport Protocol机制来处理多帧数据。传输协议的基本过程是发送方先发一个连接初始化请求TP.CM通知接收方自己要发送的数据总长度和封装的消息个数接收方确认后发送方按顺序发送数据传输帧TP.DT每帧带一个帧序号接收方按序号重组数据。整个过程中任何一帧丢失或序号错乱接收方都会丢弃整个消息不做部分数据重组。在抓包工具里TP.CM和TP.DT报文会单独显示但要注意它们和普通应用报文共用同一个CAN ID空间所以在代码里区分时要用PF/PS来判断。总线上看到连续的、相同ID的8字节数据包很可能就是一帧多字节应用报文被拆成了多个传输帧。6.2 传输协议的会话流程细节J1939传输协议的关键报文类型包括TP.CM连接管理报文其中又区分RTS请求发送、CTS允许发送、EOM消息结束等子功能TP.DT数据传输帧最多可传0xFF个数据包每包8字节最后一个包不足8字节的部分填充0xFF接收方的处理逻辑一般是收到TP.CM后解析总字节数然后回复TP.CM/CTS发送方按每次最多16个包每包8字节的分组策略发送TP.DT接收方收满后回复EOM完成整个消息接收。这里有一个容易出错的地方BCP报文总长度是13字节但实际有效内容可能只有11字节剩余字节是填充字节。解析时如果直接用13字节去映射字段最后两个字节会解析出无意义的0xFF。正确做法是按照协议定义的有效长度截取再逐字段映射。6.3 多帧超时的典型问题传输协议中有一个超时计时器概念。发送方发送TP.CM后接收方必须在规定时间内回复CTS接收方发送CTS后发送方必须在规定时间内开始发送TP.DT。任何一方超时整个传输会话都会终止。在实车环境中CAN总线负载率过高或接收缓冲区过小容易导致TP.CM丢失传输会话无法建立。处理这种问题建议在CAN驱动层增加传输协议状态机并记录当前会话状态和超时时间。一旦超时主动放弃本次会话并重新等待下一次TP.CM防止僵尸会话占用缓冲区。我在调试中发现有些桩的协议栈在会话超时后没有正确清理缓冲区导致后续其他报文排队全部卡死最终表现为上电后整个充电流程不启动重启后才能恢复。{% hint styleinfo %} 分析多帧报文时抓包工具的时间戳非常关键。打开相对时间显示看TP.CM、TP.DT每一帧之间的间隔。正常情况下TP.DT之间的间隔在几毫秒以内如果间隔突然拉长到几十毫秒说明发送方任务调度有问题或者总线被更高优先级报文抢占严重。 {% endhint %}7. 实测中最容易翻车的几件事附排查思路7.1 CAN ID映射不一致同一个协议不同厂家各有私心这是我在多个项目里踩过最深的一个坑。GB/T27930-2015标准文本中定义了报文的功能和PGN但具体到CAN ID的落地实现不同整车厂和桩企存在差异。有的厂家把BMS握手报文发成0x1801F456有的发成0x18FFF456还有的在27位标识符基础上嵌入了厂商自定义位。建议做法是新项目联调启动前先向对方要一份通信矩阵表或DBC文件CAN数据库格式不要只在嘴上确认我们都用国标。拿到DBC之后导入CANoe或Wireshark的CAN插件里让DBC去做ID到信号名的解析不要自己硬编码ID到报文的映射关系。这样即使对方后续更新了映射只需要更新DBC即可。7.2 字节顺序Motorola格式与Intel格式的混用GB/T27930-2015协议整体偏向J1939风格但报文内部字节序存在Motorola大端和Intel小端混用的情况。一个8字节报文里有些字段按Motorola排列有些按Intel排列这在CANoe的DBC文件里可以通过字节序属性配置但在手工解析时非常容易搞错。举个具体的例子某报文的充电电压需求字段跨两个字节如果按Motorola解析是0x04D2电压123.4V按Intel解析就会变成0xD204实际值会变成负数或巨大值。手工分析时遇到跨字节数值型字段先确认是高字节在前还是低字节在前不要想当然。用CANoe加载DBC解析则不会有这个问题。我自己的习惯是凡是跨两个字节以上的数值字段先用原始值换算物理量做个合理性检查。电压、电流、温度都有明确的物理范围超范围时大概率是字节序或缩放系数算错。7.3 报文周期超时参数不一致国标协议对每类报文有建议周期但BMS和充电机实际配置的周期可能不同。BCL报文有的BMS发50ms有的发100ms、250msBSM报文有的发1s有的发500ms。如果充电机侧的接收超时判断时间写死了比如固定100ms而某车型BMS的BCL周期是250ms就会导致周期性报通信超时故障。排查这类问题用抓包统计功能最直接。在CANoe或PCAN的统计窗口里看每条报文的最小周期、最大周期、平均周期。如果实际周期符合预期但充电机还是报超时那就去查充电机代码里的超时计时器初始化值很可能因为某个全局变量被意外清零导致计时器从未启动。7.4 绝缘检测与物理连接状态的影响充电机在握手阶段之前通常要做绝缘检测绝缘检测结果不通过充电机不会进入下一步。这个逻辑是在BMS通信流程之外的但经常被误认为协议问题。遇到一直握手但总是不成功的情况先用万用表量充电机输出端正负极与地之间的绝缘电阻排除硬件故障后再抓CAN报文分析协议状态。绝缘检测和通信握手是并行还是串行取决于充电机厂家设计。有些桩是先绝缘、后握手串行流程绝缘检测模块卡住时BMS侧永远收不到握手回应有些桩是边绝缘、边握手两者独立BMS能正常收到握手回应但功率输出被绝缘检测逻辑锁住。两种现象的抓包结果完全不同排查方向也不同。7.5 bus-off恢复机制CAN控制器进入bus-off状态后一般需要128个空闲位才能恢复正常通信。充电机主控与充电模块通信、与BMS通信共用同一路CAN时如果一个节点的收发器质量差导致持续错误就会把整条总线的错误计数器拉高最终进入bus-off。这种情况下抓包工具会看到大量错误帧然后总线静默一段时间又突然冒出一堆正常报文。应对措施是把BMS通信和充电模块通信分到不同的CAN通道上如果必须共用就把BMS通信的CAN控制器错误状态中断打开在bus-off发生后主动复位CAN控制器。同时检查CAN收发器芯片的型号和总线电容匹配保证高速传输下的信号质量。{% hint styleinfo %} 联调现场如果抓包发现错误帧率超过总线总体流量的5%不要急着分析应用层报文先停机检查物理层。CAN的错误帧在正常工况下应该是零或接近零超过1%就该警惕了。 {% endhint %}8. 从抓包到定位问题的完整排查实例8.1 故障现象描述一次现场联调车型是某纯电动公交桩是新做的120kW一体式直流桩。现象是插枪后界面显示充电连接中大约10秒后跳到BMS通信超时然后整个充电流程复位重来。反复几次都一样偶尔有一次能进入充电但几秒后又跳枪。8.2 排查过程与结论第一步用CANoe连接充电机与BMS之间的CAN总线抓取完整的上电和握手阶段报文。发现BMS确实在发BRM报文周期250msID和数据内容看起来正常。充电机侧也发出了CRM回应报文。表面上双方都发了但BMS好像没有收到CRM因为BMS的报文状态一直停留在BRM重发阶段。第二步用万用表检查CAN总线终端电阻CANH到CANL之间约60欧姆正常。再用示波器看CANH和CANL波形发现低电平段有振铃幅值超过CAN规范要求的压差范围但还没到完全不可用的程度。仔细检查发现BMS端的线束是临时飞线长度超过2米且未使用双绞线这是实实在在的信号质量问题。第三步更换双绞屏蔽线并缩短飞线距离后BMS能正常收到CRM握手阶段通过。但进入辨识阶段后充电机收到BMS辨识报文后一直不进入参数配置。再抓包看发现充电机的内部状态机卡在等待绝缘检测完成这一步而绝缘检测模块因为采样回路虚接一直没有给出检测结果。修复绝缘检测采样线后整个充电流程恢复正常。这个实例说明现场很多协议问题实际上是物理层和外部逻辑问题。我每次做车载联调第一步永远是先确认线束、终端电阻、电源地确认这一步没问题之后才敢动代码。9. 最后分享几个我能直接抄作业的经验这套协议我前前后后做过三轮完整的产品对接沉淀下来几条最实用的经验写在这里供大家参考。第一所有报文解析代码里务必把缩放系数和字节序做成配置表不要散落在业务逻辑里。GB/T27930的字段缩放规则多且杂0.1V、0.1A、1%、0.1℃都有一旦算错排查时间是以天计的。做成配置表后至少能保证解析规则统一可维护。第二抓包分析时优先使用带DBC导入的工具。Wireshark的CAN插件、CANoe、PCAN-Explorer都支持DBC导入后信号名直接显示在报文旁边能节省大量对字节定义的时间。如果没有DBC就先用协议文档把每个报文的字节偏移、位宽、缩放系数整理成Excel再对着Excel解析。第三协议标准里写的最小周期和最大周期在实际代码里要按照最小周期的一半作为接收超时判断的初步参考值。比如BCL报文周期50ms接收超时可以设成100ms但不能设成10ms。超时设置太短会误报太长则保护不及时具体要结合实车测试数据和客户保护需求标定。第四做故障诊断功能时除了解析故障字一定要加故障恢复逻辑。GB/T27930里的故障码有恢复机制有些故障清除后可以重新开始充电流程有些必须断电重启才能恢复。不要把所有故障都做成锁死状态否则一次误报就要断大电运营方会疯掉。第五多帧报文解析的代码在交付前一定要用异常注入工具测试。人为丢一个TP.CM、丢一个TP.DT、把TP.DT的帧序号改乱看接收方协议栈能否正确丢弃并等待超时重启会话。不做这个测试就永远不知道现场遇到传输丢包时程序会不会卡死。这几点是我在多次通宵联调之后用头发换来的经验。如果早几年有人跟我说这些我至少能少熬三个通宵。希望这篇文章能帮你少走一些弯路。
GB/T27930-2015车桩通信协议实战解析：从CAN报文到故障诊断
1. 为什么我把GB/T27930当车桩联调的第一道坎来学先交代一下背景。我做充电桩嵌入式软件和BMS联调有几年了头一次独立负责车桩联调时手里只有一份协议PDF和一台上位机抓包工具。那时候最痛苦的还不是代码怎么写而是报文到了总线上面对密密麻麻的十六进制数据根本不知道哪条是握手、哪条是参数配置、哪条是故障上报。翻协议文档翻到头晕一个字一个字对还是容易搞混。后来经验多了才明白GB/T27930-2015这套协议本质上就是一整套车和桩对话的规则。它规定了非车载传导式充电机与电池管理系统BMS之间通过CAN总线通信的语言什么时候说话、先说哪句、数据放在哪个字节、出了问题怎么报告。这套标准适用的对象是直流充电场景也就是大家常说的快充桩。只要充电功率超过一定门槛、需要用充电机直接给动力电池充电基本都绕不开它。说它是第一道坎是因为整个通信过程分为握手、辨识、参数配置、充电、充电结束这五个阶段阶段之间有严格的状态流转关系。任何一个阶段的报文ID配错、字节偏移算错、CRC校验不过都会导致充电启动失败。而这些问题在实车上往往不会直接告诉你哪错了只会显示绝缘检测失败BMS超时连接中断这类模糊信息。这篇文章我不打算罗列协议全文而是按一次完整的充电流程来走一遍——从低压辅助上电开始到手握手、辨识、参数配置、正式充电再到故障中止把每一条关键报文的CAN ID、字节定义、传输方向、易错点全部拆开讲。给正在做车桩联调、充电桩开发或BMS测试的工程师一份可以直接对照着排查的实操笔记。{% hint styleinfo %} 协议版本说明GB/T27930-2015是在2011版基础上修订的2015版调整了部分报文周期、超时时间、故障等级分类等内容。本文以2015版为准如果项目里遇到2011版的老车老桩字节定义和超时参数会有差异对接时务必先确认双方版本。 {% endhint %}2. 看懂CAN 2.0B扩展帧报文ID才算真正会读2.1 29位标识符拆解优先级、PGN、源地址GB/T27930-2015基于CAN 2.0B扩展帧传输CAN ID长度是29位不是CAN 2.0A的11位标准帧。光这一点就坑过不少人有些工程师直接把J1939的标准帧格式套过来解析出来全是乱的因为两者位分配逻辑完全不同。29位ID的分配规则在行业里有个基本共识按从高位到低位排列bit 26 ~ bit 28优先级Priority占3位对应ID的最高3位。GB/T27930里报文优先级一般取6二进制110。计算时要注意CAN ID在代码里通常用十六进制表示0x18开头就是优先级6的常见写法。bit 8 ~ bit 25PDU格式与组扩展共18位其中包含PFPDU格式和PSPDU特定组合后形成PGN参数组编号。bit 0 ~ bit 7源地址Source Address占8位。BMS的源地址在2015版里规定为0xF4充电机的源地址为0x56。我在做抓包分析时习惯先把完整CAN ID写成二进制再按这个位数切分。比如一条ID为0x18FF56F4的报文二进制展开后高3位是110对应优先级6中间的18位是PGN低8位0xF4说明这条报文是BMS发的。至于PGN怎么算要分PDU1和PDU2两种格式下面细说。2.2 PDU1与PDU2格式的判断方法PDU格式的判断看PF字节大小。如果PF在0到239之间属于PDU1格式报文是点对点定向传输PS字段为目标地址如果PF在240到255之间属于PDU2格式报文是广播发送PS字段为组扩展。具体到PGN的计算规则PDU1格式下PGN的高位字节等于PF低位字节为0。例如PF0x01则PGN0x010000。PDU2格式下PGN等于PF左移8位加上PS。例如PF0xFFPS0x56则PGN0xFF56。为什么要纠结这个因为在CANoe或者PCAN的报文解析窗口里直接显示的是CAN ID而不是PGN。如果不懂PF和PS的区分看到0x18FF56F4和0x180156F4会误以为它们PGN相同或者指向同一个参数组实际上一个是广播报文、一个是定向报文含义完全不同。联调现场很多对不上版本号的问题根源就是这里算错了。2.3 终端电阻与波特率不解决物理层后面全是玄学报文解析的前提是物理层稳定。直流充电桩与BMS之间通常使用250kbps波特率也就是CAN 2.0B的标准波特率之一。但250k只是默认值国标通信协议中没有强制规定波特率必须是多少实际项目里也可能出现500kbps。我遇到过一辆车和桩的波特率设置不一致现象是抓包工具里偶尔能看到报文、大部分时间超时因为波特率不匹配导致错误帧率极高。物理层另一个高频坑是终端电阻。CAN总线两端需要各接一个120欧姆的终端电阻总线上只有跨接在CANH和CANL之间的60欧姆等效电阻时信号质量才正常。有些充电桩的控制器板上默认没焊终端电阻靠外部接线联调时如果发现波形振铃严重、总线进入bus-off先量电阻不要急着调软件。{% hint styleinfo %} 判断总线物理层是否正常有个笨办法用万用表量CANH与CANL之间应该有约60欧姆。如果量到120欧姆说明只有一端接了终端电阻如果量到接近0说明总线某处短路或电阻焊错位置。 {% endhint %}3. 握手与辨识阶段从低压上电到版本对齐的逐字节拆解3.1 握手阶段整体状态流程一次完整的直流充电启动从物理连接完成之后开始。低压辅助电源上电后BMS先开始周期性发送BMS握手报文简称BRM也叫BRO等待充电机回应。充电机收到BRM后回发充电机握手报文简称CRM/CRO。双方完成握手进入辨识阶段。这里有个容易混淆的点GB/T27930-2015里握手阶段有专门的报文辨识阶段也有专门的报文。实际开发中经常听到BRM、BRO、CRM、CRO、BHM、CHM这一串缩写如果不理清顺序看抓包数据时就会乱。我按实际抓包顺序整理如下阶段报文缩写发送方方向周期说明握手BRM/BROBMSBMS→充电机250msBMS握手报文含BMS版本号和电池类型握手CRM/CRO充电机充电机→BMS250ms充电机握手报文含充电机版本号并确认握手成功辨识BHM/BHOBMSBMS→充电机250msBMS辨识报文含BMS最高允许充电总电压辨识CHM/CHO充电机充电机→BMS250ms充电机辨识报文含充电机最低/最高输出能力确认辨识完成辨识BRM/BRO二次交互双方双向按需部分实现中版本信息需要二次确认具体看双方协议实现我特意在表格里把BROBHOCHO这类带O的缩写也列出来了因为很多协议文档的ASCII码图里报文名称用的是BRM、BHM但实际报文代号却是BRO、BHO。同一个报文名称和代号并存新手很容易对不上号。3.2 BMS握手报文BRM逐字节说明BRM报文是BMS上电后第一条主动发出的报文整车端通常会在低压上电、VCU或BMS唤醒后开始发送。CAN ID一般为0x1801F456其中0x18对应优先级60x01是PF0xF4是PS目标地址为BMS自己说明这是从充电机视角看的目标地址0x56是源地址充电机地址。等等上面这个ID算出来源地址是0x56也就是充电机发的。发方是BMS怎么源地址会是0x56这里要多说一句在J1939协议族里CAN ID里的源地址字段指向发送节点但在GB/T27930的很多报文里ID往往经过重新映射不同整车厂商实现并不完全统一。我实测过不同品牌车辆同样一条BRM报文有的车用0x1801F456有的车用0x18FFF456ID定义上存在差异。因此实际开发时不要死记某篇文章给的标准ID要以你项目所依据的协议版本号和实测抓包为准。标准文本对各报文的PGN定义有规定但落地映射到CAN ID时厂家实现会有差异。这个坑我在第三节末尾单独说。BRM报文的数据段8字节一般定义为第1字节BMS版本号主版本如0x01第2字节BMS版本号副版本如0x0A第3字节电池类型01表示铅酸02表示镍氢03表示锂离子04表示超级电容第4字节电池序号或厂商编码第5字节BMS软件版本号第6字节BMS硬件版本号第7字节保留或厂商自定义第8字节保留或厂商自定义注意具体字节分配在标准原文里有定义但厂商自定义区域经常被拿来扩展。我见过有整车厂把电池额定容量、电池串并数塞进这两个保留字节的做法。解析时如果发现自己的桩收到的BRM报文数据段和协议文档对不上不要急着改代码先用厂商提供的实车数据字典核对。3.3 充电机握手报文CRM与辨识确认逻辑充电机收到有效的BRM报文后开始发送CRM报文回应。CRM报文数据段关键字节是充电机握手成功标志和充电机版本号充电机版本号主版本、副版本各占一个字节握手成功标志在特定字节位置置为0xAA表示成功0x55表示失败有些厂家的实现会在0xAA/0x55基础上增加其他含义。这里有一个容易踩的时序坑2015版协议规定BMS在发出BRM报文后等待充电机CRM报文如果超时未收到BMS会持续发送BRM并可能上报故障。但部分老桩在收到BRM后不会立刻回CRM而是先完成绝缘检测等内部流程导致BMS侧已经超时了。联调时如果看到BMS端一直报握手超时不要只怀疑桩没发CRM先确认桩是否在内部检测阶段堵塞了主循环。辨识阶段的核心是版本对齐和电气参数范围匹配。BMS辨识报文BHMBHO里包含BMS最高允许充电总电压充电机辨识报文CHMCHO里包含充电机最低输出能力和充电机最高输出能力。双方要通过这几个数值判断彼此的电压范围是否匹配不匹配就直接中止连参数配置阶段都进不去。{% hint styleinfo %} 实车联调中握手阶段最常见的失败原因不是代码逻辑错误而是报文周期不匹配。BMS按250ms周期发BRM充电机如果按500ms周期回CRM某些BMS实现会在300ms内判定超时。别问为什么有些车能充有些车不能充先把周期对齐。 {% endhint %}4. 参数配置与充电阶段BCP/BCL/BCS/BSM/CCS如何分工4.1 参数配置阶段的核心报文BCP握手和辨识完成之后进入参数配置阶段。这一阶段最核心的报文是BMS参数配置报文BCP由BMS发送给充电机。BCP报文里携带的是充电机做功率计算和电压电流配置所必需的全部参数动力蓄电池单体最高充电电压、最高充电电流、最高充电总电压、最低充电总电压、电池额定容量、电池单体数量、动力蓄电池允许的最高温度、最低温度等。以单体最高充电电压为例字节定义通常是两个字节精度0.1V也就是实际电压值 原始值 × 0.1V。如果原始值为0x04D2十进制1234实际电压就是123.4V。最高充电总电压同样按0.1V缩放最高充电电流按0.1A缩放额定容量按0.1Ah缩放。每一个参数都涉及数据偏移和缩放解析时最忌讳直接把原始值当物理量用。BCP报文的数据段在标准里定义为13个字节超过了一帧CAN报文8字节的上限所以实际传输时走的是多帧传输协议也就是ISO-TP或者J1939的传输协议机制。关于多帧报文的拆包和组包我放到文章第6节专门讲这里先不展开。充电机收到BCP后需要根据电池参数计算自身是否具备充电能力。如果充电机输出电压范围与电池电压范围不匹配或者最大输出电流小于电池需求充电机会回发CSP参数配置报文置失败标志并附上失败原因。BMS收到失败标志后会进入错误处理或直接中止充电。4.2 正式充电阶段BCL控制需求BCS实时上报参数配置成功后BMS开始发送电池充电需求报文BCL充电机根据BCL的内容实时调整输出电压和电流。BCL报文的核心字段包括充电电压需求和充电电流需求分别按0.1V和0.1A缩放。充电机解析BCL后执行电压环和电流环调节然后通过充电机充电状态报文CCS上报当前实际输出电压、输出电流、充电模式、充电机故障状态等。BCL是充电过程中实时性要求最高的报文之一周期通常是50ms甚至更短。如果充电机在50ms内没有收到新的BCL报文BMS侧或充电机侧都会判定通信超时并触发保护动作。这里有一个很现实的工程问题充电机主控的CAN接收队列深度不够当总线上同时存在BCL、BCS、BSM、CCS等多条周期报文时偶尔会发生丢帧。一帧BCL丢失可能没关系连续丢几帧就触发保护了。建议在充电机代码里单独为BCL配置FIFO或专用接收邮箱并加超时看门狗计数器。BCS报文是BMS充电状态报文由BMS周期发送包含电池当前SOC、当前充电总电压、当前充电电流以及最高单体电压和最高温度等。它的作用主要是让充电机掌握电池当前状态便于在电池接近满充时进行涓流切换或准备停止充电。BCS和BCL配合使用BCL提需求BCS报实际。4.3 BSM报文与单体电压温度监控BSM电池状态信息报文是充电阶段定时上报的电池状态快照周期一般较长常见的是100ms到1s不等具体看厂商实现。报文里包含电池最高单体电压、最高电压单体编号、最高温度、最高温度编号、最低温度、最低温度编号、电池组电压、电池组电流等信息。我调试时遇到过一种情况BMS上报的BSM报文里最高单体电压和BCS里的最高单体电压数值对不上一个越来越高一个恒定不变。查到最后发现是BMS端的BSM报文和BCS报文来自两路不同的采样一路是充电机采样电路一路是BMS自身采集两者本身就有微小差异。但如果两个数值差异过大充电机会统一采用更保守的数值进行保护。所以解析时不要只看一条报文就下结论要把BCL、BCS、BSM三类报文的电压、电流、温度交叉比对。4.4 充电机侧的CCS报文与CML报文CCS报文由充电机周期发送字段包括实际输出电压、实际输出电流、充电机当前工作模式、充电机故障状态等。充电模式常见定义0x01为恒压充电模式0x02为恒流充电模式0x03为恒功率充电模式。充电机在从恒流转恒压的切换瞬间CCS里的充电模式字段会变化BMS也会根据这个字段调整自己的需求策略。CML充电机最大输出能力报文则是在正式充电前或充电过程中由充电机告知BMS自己的最大输出能力范围包括最大输出电压、最小输出电压、最大输出电流。BMS会根据CML限制BCL里的电压电流需求确保不超出充电机能力。如果BMS需求超过了CML的限定值现场常见现象是充电机按自己的最大能力输出但BMS端认为输出不足报故障。这种情况在电池包电压平台较低而充电机电压范围下限较高时特别容易出现。{% hint styleinfo %} BCL、BCS、BSM三者的采样时间基准不同解析时要把时间戳打上。很多现场问题看单帧数据都对但画成曲线后就会发现问题——比如电流需求已经降到0实际输出电流还在几十安不等这说明充电机的控制环响应滞后不是协议解析问题。 {% endhint %}5. 中止充电与故障诊断BST/CST状态字背后的判断逻辑5.1 正常中止流程双方如何礼貌地停止充电充电完成或人为停止时BMS会发送BST报文BMS中止充电报文充电机收到后回发CST报文充电机中止充电报文双方确认后停止功率输出。BST报文和CST报文都有中止充电状态和中止充电原因两个关键字段数据段格式高度相似。BST报文里中止充电原因常见的定义有0x01表示电池充满0x03表示电池温度过高0x04表示电池电压过高0x05表示电池单体电压过高0x06表示充电电流过大0x07表示电池绝缘故障0x08表示通信超时0x09表示BMS内部故障。具体定义在2015版协议里有明确列表不同厂家可能在此基础上扩展但通用故障码基本一致。这里说一个很多初级工程师容易忽略的点充电机收到BST报文后应该立即停止功率输出而不是等CST发送完成后再停。因为BST报文本身就是一个保护信号BMS发出BST的同时可能已经切断了接触器如果充电机继续输出会产生拉弧或电压冲击。正确做法是CAN接收中断里解析到BST且中止原因为非正常类型时直接置停止PWM标志硬件层面切断输出。5.2 故障诊断如何从故障字里定位根因GB/T27930-2015里的故障诊断核心就是阅读BST/CST里的故障字以及充电过程中BCS/CCS报文里的故障标志位。但故障字只是结果真正要快速定位故障需要把故障字、阶段状态、关键参数三者联动来看。举个例子。现场充电桩报电池绝缘故障先不用急着拆BMS。把抓包数据拉出来看BST报文里中止充电原因是否为0x07绝缘故障然后看BCS报文里当前电池总电压、当前充电电流、电池最高温度是否异常。如果BCS显示电池总电压为零那很可能是高压采样回路断开或接触器未吸合属于电气连接问题而不是电池本身绝缘损坏如果BCS显示电压正常、电流正常只是绝缘故障字置位那就要查充电桩侧的绝缘检测模块可能是检测模块本身误报。另一个典型场景是通信超时故障。BMS报文周期是250ms充电机如果200ms没收到BCL就判定超时实际车桩双方周期配置不一致就会频繁报通信超时。这时候看CAN报文时间戳最直观如果某条周期性报文的实际周期和预期周期明显不符比如BSM报文周期被刷成了1s而充电机期望250ms那就是BMS端报文周期配置问题。5.3 故障等级一级故障、二级故障、三级故障的区别2015版协议把故障分成不同的级别充电机要根据故障级别采取不同的响应策略。一级故障属于致命故障立即停止输出断开接触器二级故障属于严重故障需要降功率或限流运行三级故障属于一般故障可维持运行但需要在界面提示。我在联调中遇到过一种情况BMS发出的BSM报文里某个故障标志位从0变1又变回0充电机因此没有做任何保护动作。这个案例提醒我故障处理逻辑里必须加持续时间判断或重复次数判断单帧故障标志置位可能是干扰或瞬时抖动连续3帧或持续50ms以上才应该认定故障成立。这个防抖逻辑如果不加充电桩会在高速上频繁跳枪用户体验很差。{% hint styleinfo %} 故障诊断的排查链路建议按物理层→链路层→应用层→策略层四步走。物理层查终端电阻、CANH/CANL电压链路层查报文ID、周期、错误帧应用层查具体字节含义策略层查故障判定阈值和响应动作。跳过前两层直接查应用层会浪费大量时间因为很多应用层问题本质是CAN收发器信号质量差导致报文错乱。 {% endhint %}6. 长报文拆包与组包一帧装不下的数据怎么传6.1 为什么会出现多帧传输CAN 2.0B扩展帧的数据场最多8个字节而BCP报文有13个字节BSM报文内容也多单帧根本装不下。GB/T27930-2015沿用了SAE J1939的传输协议Transport Protocol机制来处理多帧数据。传输协议的基本过程是发送方先发一个连接初始化请求TP.CM通知接收方自己要发送的数据总长度和封装的消息个数接收方确认后发送方按顺序发送数据传输帧TP.DT每帧带一个帧序号接收方按序号重组数据。整个过程中任何一帧丢失或序号错乱接收方都会丢弃整个消息不做部分数据重组。在抓包工具里TP.CM和TP.DT报文会单独显示但要注意它们和普通应用报文共用同一个CAN ID空间所以在代码里区分时要用PF/PS来判断。总线上看到连续的、相同ID的8字节数据包很可能就是一帧多字节应用报文被拆成了多个传输帧。6.2 传输协议的会话流程细节J1939传输协议的关键报文类型包括TP.CM连接管理报文其中又区分RTS请求发送、CTS允许发送、EOM消息结束等子功能TP.DT数据传输帧最多可传0xFF个数据包每包8字节最后一个包不足8字节的部分填充0xFF接收方的处理逻辑一般是收到TP.CM后解析总字节数然后回复TP.CM/CTS发送方按每次最多16个包每包8字节的分组策略发送TP.DT接收方收满后回复EOM完成整个消息接收。这里有一个容易出错的地方BCP报文总长度是13字节但实际有效内容可能只有11字节剩余字节是填充字节。解析时如果直接用13字节去映射字段最后两个字节会解析出无意义的0xFF。正确做法是按照协议定义的有效长度截取再逐字段映射。6.3 多帧超时的典型问题传输协议中有一个超时计时器概念。发送方发送TP.CM后接收方必须在规定时间内回复CTS接收方发送CTS后发送方必须在规定时间内开始发送TP.DT。任何一方超时整个传输会话都会终止。在实车环境中CAN总线负载率过高或接收缓冲区过小容易导致TP.CM丢失传输会话无法建立。处理这种问题建议在CAN驱动层增加传输协议状态机并记录当前会话状态和超时时间。一旦超时主动放弃本次会话并重新等待下一次TP.CM防止僵尸会话占用缓冲区。我在调试中发现有些桩的协议栈在会话超时后没有正确清理缓冲区导致后续其他报文排队全部卡死最终表现为上电后整个充电流程不启动重启后才能恢复。{% hint styleinfo %} 分析多帧报文时抓包工具的时间戳非常关键。打开相对时间显示看TP.CM、TP.DT每一帧之间的间隔。正常情况下TP.DT之间的间隔在几毫秒以内如果间隔突然拉长到几十毫秒说明发送方任务调度有问题或者总线被更高优先级报文抢占严重。 {% endhint %}7. 实测中最容易翻车的几件事附排查思路7.1 CAN ID映射不一致同一个协议不同厂家各有私心这是我在多个项目里踩过最深的一个坑。GB/T27930-2015标准文本中定义了报文的功能和PGN但具体到CAN ID的落地实现不同整车厂和桩企存在差异。有的厂家把BMS握手报文发成0x1801F456有的发成0x18FFF456还有的在27位标识符基础上嵌入了厂商自定义位。建议做法是新项目联调启动前先向对方要一份通信矩阵表或DBC文件CAN数据库格式不要只在嘴上确认我们都用国标。拿到DBC之后导入CANoe或Wireshark的CAN插件里让DBC去做ID到信号名的解析不要自己硬编码ID到报文的映射关系。这样即使对方后续更新了映射只需要更新DBC即可。7.2 字节顺序Motorola格式与Intel格式的混用GB/T27930-2015协议整体偏向J1939风格但报文内部字节序存在Motorola大端和Intel小端混用的情况。一个8字节报文里有些字段按Motorola排列有些按Intel排列这在CANoe的DBC文件里可以通过字节序属性配置但在手工解析时非常容易搞错。举个具体的例子某报文的充电电压需求字段跨两个字节如果按Motorola解析是0x04D2电压123.4V按Intel解析就会变成0xD204实际值会变成负数或巨大值。手工分析时遇到跨字节数值型字段先确认是高字节在前还是低字节在前不要想当然。用CANoe加载DBC解析则不会有这个问题。我自己的习惯是凡是跨两个字节以上的数值字段先用原始值换算物理量做个合理性检查。电压、电流、温度都有明确的物理范围超范围时大概率是字节序或缩放系数算错。7.3 报文周期超时参数不一致国标协议对每类报文有建议周期但BMS和充电机实际配置的周期可能不同。BCL报文有的BMS发50ms有的发100ms、250msBSM报文有的发1s有的发500ms。如果充电机侧的接收超时判断时间写死了比如固定100ms而某车型BMS的BCL周期是250ms就会导致周期性报通信超时故障。排查这类问题用抓包统计功能最直接。在CANoe或PCAN的统计窗口里看每条报文的最小周期、最大周期、平均周期。如果实际周期符合预期但充电机还是报超时那就去查充电机代码里的超时计时器初始化值很可能因为某个全局变量被意外清零导致计时器从未启动。7.4 绝缘检测与物理连接状态的影响充电机在握手阶段之前通常要做绝缘检测绝缘检测结果不通过充电机不会进入下一步。这个逻辑是在BMS通信流程之外的但经常被误认为协议问题。遇到一直握手但总是不成功的情况先用万用表量充电机输出端正负极与地之间的绝缘电阻排除硬件故障后再抓CAN报文分析协议状态。绝缘检测和通信握手是并行还是串行取决于充电机厂家设计。有些桩是先绝缘、后握手串行流程绝缘检测模块卡住时BMS侧永远收不到握手回应有些桩是边绝缘、边握手两者独立BMS能正常收到握手回应但功率输出被绝缘检测逻辑锁住。两种现象的抓包结果完全不同排查方向也不同。7.5 bus-off恢复机制CAN控制器进入bus-off状态后一般需要128个空闲位才能恢复正常通信。充电机主控与充电模块通信、与BMS通信共用同一路CAN时如果一个节点的收发器质量差导致持续错误就会把整条总线的错误计数器拉高最终进入bus-off。这种情况下抓包工具会看到大量错误帧然后总线静默一段时间又突然冒出一堆正常报文。应对措施是把BMS通信和充电模块通信分到不同的CAN通道上如果必须共用就把BMS通信的CAN控制器错误状态中断打开在bus-off发生后主动复位CAN控制器。同时检查CAN收发器芯片的型号和总线电容匹配保证高速传输下的信号质量。{% hint styleinfo %} 联调现场如果抓包发现错误帧率超过总线总体流量的5%不要急着分析应用层报文先停机检查物理层。CAN的错误帧在正常工况下应该是零或接近零超过1%就该警惕了。 {% endhint %}8. 从抓包到定位问题的完整排查实例8.1 故障现象描述一次现场联调车型是某纯电动公交桩是新做的120kW一体式直流桩。现象是插枪后界面显示充电连接中大约10秒后跳到BMS通信超时然后整个充电流程复位重来。反复几次都一样偶尔有一次能进入充电但几秒后又跳枪。8.2 排查过程与结论第一步用CANoe连接充电机与BMS之间的CAN总线抓取完整的上电和握手阶段报文。发现BMS确实在发BRM报文周期250msID和数据内容看起来正常。充电机侧也发出了CRM回应报文。表面上双方都发了但BMS好像没有收到CRM因为BMS的报文状态一直停留在BRM重发阶段。第二步用万用表检查CAN总线终端电阻CANH到CANL之间约60欧姆正常。再用示波器看CANH和CANL波形发现低电平段有振铃幅值超过CAN规范要求的压差范围但还没到完全不可用的程度。仔细检查发现BMS端的线束是临时飞线长度超过2米且未使用双绞线这是实实在在的信号质量问题。第三步更换双绞屏蔽线并缩短飞线距离后BMS能正常收到CRM握手阶段通过。但进入辨识阶段后充电机收到BMS辨识报文后一直不进入参数配置。再抓包看发现充电机的内部状态机卡在等待绝缘检测完成这一步而绝缘检测模块因为采样回路虚接一直没有给出检测结果。修复绝缘检测采样线后整个充电流程恢复正常。这个实例说明现场很多协议问题实际上是物理层和外部逻辑问题。我每次做车载联调第一步永远是先确认线束、终端电阻、电源地确认这一步没问题之后才敢动代码。9. 最后分享几个我能直接抄作业的经验这套协议我前前后后做过三轮完整的产品对接沉淀下来几条最实用的经验写在这里供大家参考。第一所有报文解析代码里务必把缩放系数和字节序做成配置表不要散落在业务逻辑里。GB/T27930的字段缩放规则多且杂0.1V、0.1A、1%、0.1℃都有一旦算错排查时间是以天计的。做成配置表后至少能保证解析规则统一可维护。第二抓包分析时优先使用带DBC导入的工具。Wireshark的CAN插件、CANoe、PCAN-Explorer都支持DBC导入后信号名直接显示在报文旁边能节省大量对字节定义的时间。如果没有DBC就先用协议文档把每个报文的字节偏移、位宽、缩放系数整理成Excel再对着Excel解析。第三协议标准里写的最小周期和最大周期在实际代码里要按照最小周期的一半作为接收超时判断的初步参考值。比如BCL报文周期50ms接收超时可以设成100ms但不能设成10ms。超时设置太短会误报太长则保护不及时具体要结合实车测试数据和客户保护需求标定。第四做故障诊断功能时除了解析故障字一定要加故障恢复逻辑。GB/T27930里的故障码有恢复机制有些故障清除后可以重新开始充电流程有些必须断电重启才能恢复。不要把所有故障都做成锁死状态否则一次误报就要断大电运营方会疯掉。第五多帧报文解析的代码在交付前一定要用异常注入工具测试。人为丢一个TP.CM、丢一个TP.DT、把TP.DT的帧序号改乱看接收方协议栈能否正确丢弃并等待超时重启会话。不做这个测试就永远不知道现场遇到传输丢包时程序会不会卡死。这几点是我在多次通宵联调之后用头发换来的经验。如果早几年有人跟我说这些我至少能少熬三个通宵。希望这篇文章能帮你少走一些弯路。
