充电机与电池管理系统（BMS）之间的通信协议&V2G在AUTOSAR软件中的应用

前言

2021年国内新能源乘用车销量较2020年大增，2021年国内新能源乘用车终端销量达2,910,507辆，同比增长159.9%。其中纯电动车销量2,382,469辆，插电式混合动力销量528,020辆，燃料电池车销量18辆。[1]

https://auto.gasgoo.com/news/202201/21I70289197C501.shtml

考虑到2021年还是新能源（汽车）相关题材基金大火的一年，投资方非常青睐新能源汽车，并且看好未来的发展，几乎所有车厂都在大力推广新能源汽车。除此之外，在过去的几年间，我们还陆续看到了非常多的其他行业厂商加入了（智能）汽车大军，无论是已经布局汽车的华为和百度，还是年中刚刚宣布要在2024年进行量产的小米，我们能够清晰地感受到新能源这个大趋势，从销量上也能看出越来越多的消费者开始接受新能源汽车。

在相关零部件领域，我们也能偶尔听到电池技术升级的新闻，想到一开始只有一两百公里级别续航能力的新能源车，如今再去选购时，会觉得放心很多，基本都能做到300，400公里续航起步，甚至还能在差不多的价格区间买到高达600，700公里续航的车辆。当然，无论电池技术本身如何升级，作为从业者的我们，有一个共同观点是——充电标准能够做到统一，硬件也好，软件也好，都能遵照统一规范进行设计，开发，部署，提升通用性。

和AUTOSAR标准提出的想法类似，以软件开发为例，如果底层软件能够做到通用，那么电池管理或者充电桩软件开发人员能够更加专注于应用体验的提升，而无需对不同厂家的充电桩或者BMS系统进行一次次的开发以及适配。

充电模式

根据国标GB/T18487.1—2015，有四种充电模式[2]：

连接方式

一般来说，充电机与车辆连接方式有三种[2]：

日常生活中，我们一半看到的都是连接方式C的情况。

充电机与BMS之间的通信协议

对于充电机与BMS之间的通信，同样有国标规定。

国标GB/T 27930—2015规定了电动汽车非车载传导式充电机(以下简称充电机)与电池管理系统(Battery Management System,以下简称BMS)之间基于控制器局域网(Control Area Network,以下简称CAN)的通信物理层、数据链路层及应用层的定义。[3]

此标准适用于采用GB/T18487.1规定的充电模式4的充电机与BMS之间的通信,也适用于充电机与具有充电控制功能的车辆控制单元之间的通信。[3]

J1939

本文仅关注于车载软件中和软件相关的部分内容，在这部分中，我们需要关注到SAE J1939-21:2006（商用车控制系统局域网CAN通信协议 第21部分:数据链路层）与SAE J1939-73:2006（商用车控制系统局域网CAN通信协议 第73部分:应用层 诊断）。

实际上欧洲执行的是ISO 15118标准，而日本则执行的是CHAdeMO标准，至于特斯拉，又是另外一种，不过在国内，特斯拉可以提供支持国标的充电适配器以支持非特斯拉专用充电桩[4]。

也有新闻说国标和CHAdeMO会进行共同制定，更具通用性[5]。

什么是J1939

J1939协议是由美国汽车工程师协会（SAE）定义的一组标准。J1939标准用于卡车、公共汽车和移动液压等重型车辆。在许多方面，J1939标准类似于旧版J1708和J1587标准，但J1939标准协议建立在CAN（控制器区域网络，ISO11898）上[6]。

https://www.csselectronics.com/pages/j1939-explained-simple-intro-tutorial

CAN总线提供了通信的基础规范，更偏向于是一个工具——例如电话，但是使用电话的双方如何“对话”？CAN总线并不能完成这样的工作。和我们熟悉的诊断规范UDS类似，在充电国标这里，使用的是J1939协议。

https://www.csselectronics.com/pages/j1939-explained-simple-intro-tutorial

J1939的特点

J1939协议有如下特点[7]：

1. J1939使用的波特率典型值为250K，也能支持500K。J1939 CAN ID使用29bit的CAN扩展帧。
2. 大部分J1939消息都是在CAN总线上以广播形式发送，部分数据可以通过请求的方式进行获取。
3. J1939消息由18bit的PGN（Parameter Group Numbers 参数组编号）进行识别，J1939的信号称为SPN（Suspect Parameter Numbers 可疑参数编号）。
4. J1939的消息以intel字节序进行发送，J1939传输协议最大支持1785字节的PGN。

PGN与SPN

如上图所示，PGN长度为18 bit，是标准CAN扩展帧ID的29 bit中从第九个bit位开始的18个bit。在J1939通信当中，PGN作为唯一的帧标识符，来识别何种设备或者何种消息，以及其包含消息的具体含义。

假设我们收到了一个CAN ID为0x0CF00401的消息，那么PGN值为0x0F004（61444），此时我们可以查阅J1939-71手册，得知它代表的是“发动机电控单元1-EEC1”，同时还列有七个SPN各自代表的含义：

我们先来了解一下PF(PDU Format)，当PF的值在0~239（<240）时，代表PDU1格式，用来点对点通信，此时PS(PDU Specific)表示目标地址。而当PF值>=240时，代表PDU2格式，用来做广播通信，此时PS字段用来作组扩展，和PF一起共同作为广播参数组，组的数量大大增加。

因为Data Page占一个bit，0代表当前属于页0，1代表当前属于页1，也就是说PGN所代表的组的数量可以增加一倍。

有了PGN，我们就能找到对应SPN的含义，仍然以上文假设的J1939消息为例，我们能够注意到其中含义为Engine Speed的SPN，所在位置为第4个字节开始的2个字节，也即0x68与0x13，由于已经提到过字节的发送顺序为intel字节序，所以我们用来进行计算的值应当是0x1368，也即十进制的4968。

同时，我们计算实际具有物理含义的值时，使用上方的公式，采用的精度为每bit位代表0.125rpm，偏移量为0，最终得到的引擎转速为621rpm。

消息类型

J1939一共定义了5个类型的消息：命令，请求，广播/响应，确认，组功能。

类型	说明
命令	普通PGN，支持PDU1和PDU2
请求	专用PGN--0x00EA00 仅支持PDU1（点对点）目标地址255（全局目标地址）
广播/响应	普通PGN，支持PDU1和PDU2
确认	专用PGN--0xE800 仅支持PDU1（点对点）目标地址255（全局目标地址）
组功能	专用PGN 用作专用功能，网络管理以及多包功能

命令

消息类型为命令的J1939消息，包括从某个地址源命令特定目的地或者全局目的地的参数群，目的地址收到命令消息之后，将采取特定的动作。命令的消息可能包括传动控制，地址请求，扭矩/速度控制等等。

请求

消息类型为请求的J1939消息，可以从全局范围或者特定目的地请求信息。

请求消息有定义对应的PGN，59904，对应的PF值为234。SPN仅包含三个字节的数据，代表请求的PGN消息。我们常见的请求消息就包括诊断消息。

广播/响应

广播或者响应消息，既可以是某个设备主动提供的广播消息，也可以是某个命令或请求的响应。

确认

确认消息，是对于特定命令、请求的ACK或者NACK响应。确认消息也有固定的PGN值 ，59392，对应的PF值为232。

确认类型有肯定应答，否定应答，拒绝应答，无法应答四种。

组功能

组功能消息应用于特殊功能，例如专用功能，网络管理功能，多包传输功能等。

J1939 transport protocol (TP) 传输协议

之前所讲的PGN与SPN，都是基于不大于8个字节的J1939消息，当我们需要发送大于8个字节数据的消息时，我们就需要用到J19393传输协议。

https://www.csselectronics.com/pages/j1939-explained-simple-intro-tutorial

J19393TP存在两种类型通信：Connection Mode以及Broadcast Announce Message（BAM）。

连接模式用于与特定设备的通信，而BAM则用于与整个网络当中。

如上图所示，ECU先发送了一个BAM包，BAM包中指定了多包消息的PGN值以及即将要发送的包的数量以及数据字节长度。在BAM之后，最大可以跟随255个数据报文，每一个报文的第一个字节指定了当前的序列号码（1到255），然后是7个字节的数据。所以，J1939中多包消息最大能够传输的字节数为1785。

最后一个数据报文包含至少一个字节的数据，未使用到的字节用FF填充。在BAM场景下，消息之间的时间间隔约为50-200ms。

对于接收方，需要做的是，在接收到BAM消息后，初始化一个新的sequence，从6-8字节中得到PGN值，然后由后续数据传输过程中报文的2-8字节的数据组成最终消息的完整数据。

J1939诊断

J1939协议也规定了一部分PGN用来做不同的诊断服务，这些诊断消息（Diagnostic Message, DM）基本上覆盖了UDS诊断的功能，同时也兼容OBD诊断。

不同于UDS诊断需要由上位机主动激活诊断服务，J1939 ECU在标准操作过程中也会发送诊断消息[8]。

类似地，记录地DTC也可以通过工具读出来，包括对应的SPN，FMI，OC，CM。

https://www.vector.com/int/en/know-how/protocols/sae-j1939/

SPN在这里用来代表某种故障码，占19bit，应用层文档已经定义了用来做诊断用的SPN。

FMI（Failure Mode Identifier，故障模式ID）代表发生错误的类型，例如超出范围，短路，校准错误等，占5 bit。

OC（Occurrence Counter，发生次数），记录故障发生的次数，每当故障从非激活状态进入到激活状态时，OC计数器加1，当数值为126时，激活次数的增加不再影响计数器，OC值保持为126[9]。

CM（SPN Conversion Method，SPN转换模式）定义了DTC的字节对齐方式。过去的J1939规范定义过三种方式，目前版本仅支持一种，如果CM bit位设置为0，那么则代表当前最新的方法，如果为1，则代表过去三种方法其中之一，具体使用的哪一种，由系统设计者决定。

国标GB/T 27930—2015

国标中定义了，充电机和BMS的地址为不可配置地址，无法用配置工具改变，也不允许使用任何服务（诊断）方式进行修改。

充电总体流程

充电总体流程图

整个重点过程包括六个阶段：物理连接完成，低压辅助上电，充电握手阶段，充电参数配置阶段，充电阶段和充电结束阶段。

在各个阶段，充电机和BMS如果在规定的时间内没有收到对方报文或者没有收到正确的报文，会被判定为超时，超时时间一般默认为5秒。超时后，BMS或者充电机还需要发送错误保温，进入错误处理状态。如果充电结束阶段出现故障，则直接结束充电流程。

报文类型及定义

具体报文类型及定义这里不重复说明，详细可阅读国标全文。

AUTOSAR中的J1939 Stack

对于J1939 Stack的实现各家都大同小异，这里以EB产品为例，提供了如下四个模块：

• J1939Tp，处理数据分拆与组装，数据流控制，超时监控等等
• J1939Dcm，处理诊断通信
• J1939Rm，处理请求，确认消息
• J1939Nm，处理地址声明参数组消息的接收与发送

另外，在测试/记录工具这一块儿，CSS有CANdege，Vector有CANoe。当然了，由于是基于CAN通信，所以有任何一个CAN消息检测工具，然后配合python脚本也是能做到数据解析、记录的。

J1939Dcm

AUTOSAR规范中使用的是J1939规范中的部分诊断消息(DMx)，

J1939Tp

长度不大于8字节的N-SDU的发送

当发送的字节不超过8字节时，发送流程如上图所示，数据不需要被分段发送。

点对点通信模式数据发送

当数据长度大于8个字节，直接发送给接收端时，采用的是上图所示流程。

数据发送前需要先发送CM RTS(Request to Send)以初始化一次本次数据传输，在收到CM CTS（Clear to Send）后代表握手成功。然后开始进行数据传输，直至最后收到确认消息，消息发送完毕。

BAM发送

当发送数据大于8个字节，并且需要发送给整个网络时，采用上图所示流程。首先发送CM BAM消息初始化本次发送，然后开始在每个Main Function中进行数据发送。当最后一个报文成功发送后，本次发送流程结束。

J1939Nm

和AUTOSAR其他网络管理不同，J1939的网络管理并不是要去处理ECU的睡眠与唤醒，而是给每一个ECU分配一个唯一的地址。

在J1939当中，定义0xEE00这个PGN值用来做Address Claimed（地址声明，AC），当ECU启动时ECU发出此声明表示自己期待分配某一地址，如果另一个ECU拥有同一个地址并且有更高的优先级，那么ECU需要在发送CannotClaimAddress（AC消息，但源地址为无效值0xFE）后进入静默状态。

J1939Rm

J1939 Request Management用来管理请求消息的接收与发送，将请求数据转发到其他模块进行处理，以及对应确认消息的回复。上面提到的诊断功能，同样需要用到Rm模块，例如：

V2G/AUTOSAR解决方案

V2G，即Vehicle to Grid，现在电动汽车以及充电桩的参与者越来越多，由于充电桩可能会有一套自己的硬件以及软件逻辑，如何能让充电应用能够无缝地集成到基于AUTOSAR的ECU当中，显得尤为重要。

类似于我们将AUTOSAR集成到某一个芯片上，往往需要芯片厂家提供硬件以及必要的底层驱动给到AUTOSAR软件开发商去进行集成验证，充电桩的厂家除了部署自己的充电桩以外，也可以提供驱动以及必要的软件栈给到软件开发商，由他们将这些软件集成到AUTOSAR软件当中，这样对于使用了AUTOSAR软件的电池应用开发者来说，能够节省大量时间以及成本。

以欧洲使用的ISO15118规范为例，由某些嵌入式厂家将软件（下图蓝色部分），预集成了在EB的Classic AUTOSAR软件当中，这样开发者就只需进行必要的定制化配置，就能直接与充电桩进行数据交换并进行充电。

不过这套方案是基于以太网的，对于国标使用的J1939，笔者还不太清楚国内是否有相关的专业软硬件提供商做这一块的工作，并且是否与各家AUTOSAR软件供应商有合作也未知。如果有知道的欢迎评论留言进行交流。

---

撰文不易，还请点赞/喜欢/收藏，鼓励一下。

本文同步首发于公众号“车载嵌入式软件开发”。

参考

1. ^2021年新能源汽车终端销量榜：比亚迪超53万辆问鼎冠军 长城汽车跻身前五 2021年新能源汽车终端销量榜：比亚迪超53万辆问鼎冠军 长城汽车跻身前五-盖世汽车资讯
2. ^ab电动汽车传导充电系统第1部分:通用要求 在线预览|GB/T 18487.1-2015
3. ^ab电动汽车非车载传导式充电机与电池管理系统之间的通信协议 在线预览|GB/T 27930-2015
4. ^新国标充电适配器 Charging & Adapter Product Guides | Tesla
5. ^新版GB/T充电接口曝光 CHAdeMO与中国共同制定新标准即将落地 新版GB/T充电接口曝光 CHAdeMO与中国共同制定新标准即将落地_车家号_发现车生活_汽车之家
6. ^J1939协议简介 J1939 协议简介|联系专门从事J1939协议和车辆应用软件的Kvaser技术伙伴
7. ^J1939 Explained - A Simple Intro [2021] J1939 Explained - A Simple Intro [2023]– CSS Electronics
8. ^Open Standard for Networking and Communication in the Commercial Vehicle Sector SAE J1939 Know-how | Vector

9.  J1939 Diagnostics - Part 1 J1939 Diagnostics - Part 1 - Embedded Flakes

充电机与电池管理系统（BMS）之间的通信协议&V2G在AUTOSAR软件中的应用 - 知乎 (zhihu.com)