！！！写在前面：（需求分析）基于Autosar架构开发符合国标快充的CAN通信，同时决定启用J1939Tp模块进行拆包和组合的可以参考此文。！！！
开发路径如下：
/----------------------------------------开始-----------------------------------------/
一、制作DBC
制作符合GBT 27930-2015《电动汽车非车载传导式充电机与电池管理系统之间的通信协议》标准的DBC，报文属性最好设置为J1939Tp，方便导入后识别快充报文。
二、ISOLAR-AB & EB配置（以9.2.1为例）
2.1系统信息配置
2.2.1方法一:通过导入DBC以及手动配置信息（参考普通CAN配置，此处略）
2.2.2方法二：通过移植其它工程完成配置信息移植（参考普通CAN配置，此处略）
2.2BSW配置
配置路径符合该图即可：
ECUC模块：配置传输过程中使用的PDU，作为数据转发的容器，如果使用的DBC已经涵盖了RTS，CTS，TPDT以及对应的超过8字节或其它想通过J1939Tp拆包的报文，那么导入并更新BSW配置后，只需检查ECUC的PDU中是否生成需要的模块即可。
COM模块：如果导入的DBC不带J1939Tp属性，那么在这里需要配置好收发用到的PDU，并且注意，如果想控制其发送的时机，可以通过callout函数返回值置位0或者1来实现，这个是快充逻辑实现时需要控制其报文发送时机以达到与充电桩交互的目的。
PDUR模块：用于分发信息，上承COM模块（COM2PDUR/PDUR2COM），下接J1939Tp模块（PDUR2J1939Tp/J1939Tp2PDUR），同时要在其BSWMoulde模块中新增上J1939Tp模块。
J1939Tp模块：这个是核心配置，对于发送来说，用于承接上层发出来的数据，并将其拆分并通过TPDT帧发送出去，对于接收来说，用于组合同一PGN的信息构成大于8字节的信息往COM层传输。
具体配置如下，以CMDT发送举例：
1、通用配置：J1939TpGeneral
2、通道参数配置：J1939TpTxChannel
3、CTS报文配置：J1939TpRxFcNPdu
4、RTS报文配置：J1939TpCmNPdu
5、DT（数据帧）报文配置：J1939TpDtNPdu
6、数据页配置：J1939TpTxPg & J1939TpTxNSdu
CanIf：用来和J1939Tp交互，具体来说就是和J1939TP交互RTS，CTS，TPDT帧，配置的概念和普通CAN一致。（另注：假如手动增加快充报文发送路径，涉及复用Mailbox时记得配置好Basic类型并根据实际的EB版本配置合适的报文过滤帧）
ECUM模块：配置初始化函数，初始化函数名称应与供应商提供的静态代码包中的相同，例如J1939Tp_Init等，不配置时也要手写在代码启动的初始化段进行初始化。
2.3RTE配置（略）
用于配置主函数运行周期，在BSW生成后，可以在更新ECUC配置（也有人称之为抽取ECUC配置）时将main函数拖到对应的运行周期合集下再生成RTE代码。不配置时就随意找一个符合发送周期的周期函数手动增加J1939Tp的main函数，但如果是针对快充开发的周期必须在10ms或以下才能符合国标。
2.4ASW配置（略）
与应用层交互配置，用于暴露提供给上层的COM接口，与普通CAN配置无异，按照实际项目需求配置即可
2.5EB配置（略）
同普通CAN配置。
三、代码修改（略）
四、测试
J1939通信流程：
BAM（广播模式，即一对多发送）
第一帧：通知报文（发送节点）{通知在座的各位节点我要发送信息了}
20（特征值即控制字，占1Byte）+ 帧长度（单位是字节，占2Byte）+ 包数（占1Byte）+ 填充码FF （占1Byte）+ PGN码（占3Byte）
（第二帧：对于支持BAM的充电交互逻辑的来说，第二帧可能会恢复确认帧，根据具体需求进行开发）
第二帧到第N帧：数据帧（发送节点）
包数（占1Byte） + 报文内容（其余字节），另外对于未使用位常填充为FF或者 00，具体根据实际开发需求进行开发，默认推荐FF，进行配置时这个也是默认值。
（最终帧：对于支持BAM的充电交互逻辑的来说，最后一帧可能会恢复重组报文，根据具体需求进行开发）
CMDT（点对点发送）
第一帧：通知报文（发送节点）
10（特征值即控制字，占1Byte）+ 帧长度（单位是字节，占2Byte）+ 包数（占1Byte）+ 填充码FF （占1Byte）+ PGN码（占3Byte）
第二帧：回复报文（接收节点）{告诉发送节点可以发送的包数和开始序号}
11（特征值即控制字，占1Byte）+ 允许发送的数据包数(占1Byte) + 开始发送的数据包的序号 （占1Byte) + FF（占1Byte）+ PGN码（占3Byte）
第三帧：数据报文（发送节点）
数据包序号（占1Byte） + 数据内容
然后重复第二帧和第三帧的交互，当然也有的第二帧回复报文直接要求一次性把包全发出来的，这个时候后续就不用报文交互，第二帧到最后一帧都直接发出数据报文。
略略略。。。
（最终帧：重组帧，看具体充电交互是否最终需要发一组重组报文出来）
/----------------------------------------结束-----------------------------------------/
补充说明：
BUGFIX调试：
4.1其余路CAN正常通信，快充CAN报超时或者错误帧
- 优先考虑MCAL波特率配置有问题
- 其次考虑配置时BSW层中某些传输的序号的问题，通常表现为结构体中某些信号的序号混乱
- 再者考虑CAN收发软件或者硬件存在问题，检查波特率是否设置为250kb，检查环路是否构成两个终端电阻
- 最后考虑静态代码或者配置出现问题，检查配置中对应配置的can通道，检查静态代码是否集成不对，缺少收发路径，检查J1939Tp模块配置
4.2传输报文周期不对
- 优先考虑配置错了发送周期
- 其次考虑在更新ECUC时的函数周期是否配置正常
- 再者考虑是不是有其它任务争抢导致任务阻塞
- 最后考虑是不是负载率太高了
- 如果还不行看一下MCAL配置是不是异常
- 再不行的话，删除重配
#########如果小伙伴需要协助开发，可以来咸鱼<肥鱼杂货店>找我呀###########
1720
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
