1
SAE J1939诞生及应用背景
在车载网络通信系统设计过程中，常见套路是根据功能设计信号，然后将信号打包组成报文，定义报文ID及发送周期等。此过程中，因工程师的经验及习惯等不同，设计结果肯定会不一样，这样会导致可复用性差，车型升级或供应商变更时需重新开发软件，开发成本大。在乘用车领域，因产品更新迭代快，功能花样多，产品量大且利润高，采用这种设计方法能最大程度发挥设计灵活性，乘用车一直采用这种设计方式。但是在商用车领域（或其它工程机械领域），这种开发方式就不合适了。
商用车注重实用性，功能较为单一，产品生命周期长，产量小利润不高，这些特点要求商用车在电子电气架构设计开发时需进行某种约束，以最大程度实现软硬件的复用，从而节省开发成本。
J1939在此需求下诞生，其主要实现了以下内容：
（1）根据常见功能，定义相关信号，信号的长度、精度、偏移量等均进行标准化定义
（2）将相关信号按功能需求等进行打包，对报文类型、周期、ID等进行标准化定义，对各信号在报文中的位置进行标准化定义
商用车在进行通信设计时，针对常见的功能，可直接从协议中选取标准报文组成通信矩阵，从而节省设计成本及软件开发成本。
2
SAE J1939网络设计简介
当前在商用车网络设计领域，常用组合如下：物理层选用非屏蔽双绞线，使用250Kbits/s或500Kbits/s的通信速率；数据链路层遵循J1939_21；网络管理使用OSEK网络管理或AUTOSAR网络管理；诊断使用J1939_73的DM报文或DM1报文+UDS的组合。鉴于此，本文只介绍SAE J1939协议在商用车通信系统设计及诊断系统设计领域的应用。
通信系统设计，即设计通信矩阵及DBC，是定义报文及信号的过程。相关内容在J1939_21及J1939_71（现被J1939_DA替代）有定义。
诊断系统设计在J1939_73协议中有定义，该协议定义了DTC的格式及诊断报文的类型。
在介绍具体的设计前，先认识一下J1939帧的ID场及两个重要概念PGN（Parameter Group Number）/SPN（Suspect Parameter Number）。毫不夸张地说，J1939的网络设计，就是选取PGN，定义报文ID的过程。
2.1 基本概念介绍
SPN：可疑参数号，有两处应用，代表信号或诊断故障位置。在通信DBC中，每一个信号就是一个SPN。
PGN：参数组号，将一组SPN打包在一起，组成一个参数组，给该参数组一个编号，即为PGN。
在通信矩阵或DBC中，PGN对应报文，SPN对应报文内信号。J1939协议对常见控制器常见功能的信号（SPN）均做了标准化定义，并将其打包成标准的报文（PGN）。商用车通信设计时，根据功能选用相关的PGN即可。目前J1939协议已标准化定义了1500+个PGN以及20000+个SPN。
从J1939_DA协议SPNs & PGNs页选取一个PGN作示例：
PGN=1024的报文为XBR报文，用于对制动系统进行控制，报文内包含7个信号（含Checksum和Counter），即上表中的7个SPN，每个信号的长度、精度、偏移量、数值范围、初始值等均在协议中有定义。任意ECU如需对制动进行控制，使用XBR报文即可。设计者可以根据功能，选用该报文中部分SPN（不一定要求选用全部SPN），但不允许改变SPN在该PGN中的字节排布。
PGN值与报文ID密切相关，从报文的ID中可以计算PGN值，也可根据PGN值设计报文的ID。换句话讲，根据报文ID，即可知道PGN及报文的内容；选定PGN，报文的ID也即确定。
J1939帧PDU格式如下表，PDU中29位的ID包含的信息量很大。
P场：Priority，优先级，调整该值可改变报文在总线上的仲裁优先级
EDP及DP：扩展数据页及数据页，当前均为0
PF：PDU format，确定PDU格式，如PF值区间为0~239（0x00~0xEF），则表明是PDU1格式，如区间为240~255（0xF0~0xFF），则表明是PDU2格式。该场是PGN的组成部分
PS：PDU Specific，如为PUD1格式，则该场表示帧的目标地址，如为PDU2格式，则表示组扩展GE（用于扩展PGN的个数）
SA：Source Address，源地址
在ID场中，Priority值根据需要调整，EDP和DP一般均为0，PF和PS决定了报文的PGN，SA体现了报文的发送节点。
PGN由24个bits组成，其组成内容如下：
一般来讲，EDP和DP均为0，且处于PGN组成部分的高位字节，可以直接忽略，计算PGN时，只用考虑PF字节和PS字节。
以报文0x0C010B00及0x18FE414A为例，解释报文ID及PGN
解析：报文Priority为3，仲裁优先级较高（一般默认报文Priority为6）；PF为0x04，在0x00~0xEF区间内，表明是PDU1格式；PS为0x0B，当报文为PDU1格式时，该字节表示报文目标地址，查询J1939_DA协议SPNs & PGNs页，可知该地址表示EBS（商用车制动控制器）；SA为0x00，查询J1939_DA协议，该地址表示EMS（发动机控制器）。该报文的PGN为0x000400，转化为十进制为1024，表示XBR报文。从该ID内容可以看出，该报文是发动机控制器发给制动控制器，进行制动相关的请求。
解析：报文Priority为6，默认的仲裁优先级；PF为0xFE，在0xF0~0xFF区间内，表明是PDU2格式；PS为0x41，当报文为PDU1格式时，该字节表示组扩展，与PF字节一起组成PGN；SA为0x4A，查询J1939_DA协议，该地址表示Tbox（发动机控制器）。该报文的PGN为0x00FE41，转化为十进制为65089，查询J1939_DA，可知该报文为LCMD报文（Lighting Command）。该报文是Tbox节点发出来的，用于进行灯光控制的报文，BCM等节点可能接收。具体的接收节点，可以在通信矩阵及DBC中定义。
2.2 通信系统设计
认识报文的ID及PGN/SPN后，可以很容易地进行J1939通信设计。下面小编实例带大家进行商用车通信系统设计：
假设功能：ADAS控制车辆灯光（远近光、转向灯等）
涉及节点：ADAS、BCM
源地址：查询J1939_DA协议。根据协议，BCM源地址为0x21，ADAS的源地址未分配，可根据预留范围自定义为0x64
PGN选取：灯光控制使用PGN 65089（LCMD），十六进制为0x00FE41
根据以上信息，可确定该报文的ID为0x18FE4164。J1939定义的LCMD报文包含32个SPN，每个SPN代表某种灯的控制信号，根据灯光控制需要，选取相关的SPN作为报文的信号。报文的ID、各信号的定义完全遵循J1939_DA，即可完成报文的设计。
特殊情况，如果开发中碰到新功能，该功能在J1939协议中无对应的PGN，此时，可以自由地设计报文，类似于乘用车CAN通信矩阵的设计，但须注意部分细节，下面小编带大家看具体实例说明。
假设功能：无人驾驶挖掘机摄像头采集环境信息传给ADAS
涉及节点：ADAS、Camera
源地址：查询J1939_DA协议。根据协议，Camera的源地址未分配，可根据预留范围自定义为0x65
ID设计：ID场PF字节必须为0xFF，表示自定义报文。ID可以设计为0x18FF0165
信号设计：根据实际需求设计，但需注意，信号长度最少为2bits，且枚举值中最大值必须为预留。如摄像头遮蔽状态信号，理应设计如下：2 bits，0x0: no block; 0x1:blocked, 0x2: Invalid; 0x3: Reserved
2.3 诊断系统设计
由于UDS协议的优势，其在商用车上的应用越来越多，但是，商用车诊断设计时，必须考虑J1939协议的DM1报文，法规强制要求商用车支持DM1报文，商用车仪表上故障灯均由DM1报文控制点亮。
J1939协议中，每一类诊断报文均有自己的PGN，也就是说，可以通过报文ID直接判断报文是否是诊断报文以及是哪一种诊断报文。比如，DM1报文的PGN为65226，十六进制为0x00FECA。据此可知，BCM节点发出的DM1报文为0x18FECA21。
DM1报文数据场中，第一个字节为故障指示灯状态，该字节就是用来点亮故障指示灯的，具体点亮哪个指示灯，需看第三个字节开始的DTC。
J1939的DTC与UDS使用的DTC格式不同，其格式如下：
SPN：可疑参数位置，表示故障发生位置
FMI：失效模式
CM：转化模式，一般不考虑
OC：发生次数
在J1939诊断系统设计中，首先根据需求确定需选用的DM报文种类，一旦选定DM报文种类，再结合报文的发送节点，报文的ID就自然而然确定；之后进行报文DTC相关的设计即可。
3
SAE J1939总结
整体而言，J1939网络设计工作远比乘用车CAN通信系统设计简单。在进行设计时，根据需求，从协议中选用相关报文即可。如果设计过程中严格遵守J1939协议，那么，不同工程师的设计结果会高度一致，且设计文件的可读性强，出错概率低。因此，进行商用车的网络设计时，建议主机厂要求供应商严格遵守J1939协议。
J1939标准化定义的特性，导致在实车破解及实车改装工作上，该协议有极大的便利。如果车辆严格遵守J1939协议，那么，理论上，可以轻易破解车辆的CAN网络拓扑及大多数报文（通过ID可知晓发送节点及PGN，只要不是自定义的PGN，均可通过协议查找出报文名称及信号）。在商用车进行自动驾驶功能改装时，即使没有整车DBC，也可以轻易获取车辆的制动、转向、驱动等关键信号，从而实现自动驾驶相关的控制。
J1939协议的应用可以极大简化设计工作，且软件复用性高，节省开发成本，但是，该协议也有不足，如PGN/SPN的更新速度无法满足商用车日益增长的功能需求，车辆通信内容可以轻易破解等。当然，J1939协议工作组一直存在，也在一直推动协议的更新及优化，这个就不用我们操心了。
本文只是简单介绍J1939的基本概念及常见使用方法，有很多细节内容没有展开。事实上，J1939作为一个协议族，有很多内容值得深挖，多个子协议均可作为一个专题进行详细介绍。如果大家对J1939协议感兴趣，请持续关注我们的公众号并在下方留言，我们共同探讨，一起进步~
更多精彩推荐：
基于PREEvision的AUTOSAR Adaptive设计——上篇
基于PREEvision的AUTOSAR Adaptive设计——下篇
