AUTOSAR实战教程 - 通信协议栈CAN_CANIF_PDUR_CANTP_COM_XCP_ECUC配置一网打尽
通讯协议栈几乎是CP AUTOSAR中最庞杂的一块。由于其涉及的模块比较多(仅实现CAN信号的收发就需要ECUC/CAN/CANIF/CANTP/PDUR/COM/XCP这么多模块的协作！)，且名词概念众多，入门很难。网络上关于各个模块的详细介绍浩如烟海，其深度也让人叹为观止。但没有一篇文章把这些模块串起来！
这就导致对于初学者来说，往往耐心的把各个模块的详细介绍都看完，甚至把AUTOSAR标准文档读完，依然不能建立一个全局的思路。导致在配置通讯协议栈时候，导入DBC之后，一看那么多错误，无从下手或者解决了CANIF的错误，PDUR又出现了新的错误提示，解决了PDUR错误，ECUC又报错...按下葫芦浮起瓢(就像当下的防疫形势)，这种窘境，我相信绝对是每个AUTOSAR初学者都遇到过的。
本文试图从一个全局的高度，自顶向下逐步细化开来。让你在建立全局观之后熟悉通讯协议栈各模块之间的关联然后高屋建瓴学会配置每一项！也希望在此抛砖引玉，彼此交流心得,共同进步。
目录
DBC属性与信号流
DBC属性决定报文类型
报文类型决定信号流路径
配置实践
搞定信号路径
ECUC模块
CAN模块
CANIF模块
XCP模块
PDUR模块
COM模块
CANTP模块
搞定Hoh和MailBox
CAN模块中MailBox配置
CANIF模块中的Hoh(Hth和Hrh)
DBC属性与信号流
DBC属性决定报文类型
不同的DBC属性决定不同功能的报文, 一般实际项目中涉及的报文为4类:应用报文，诊断报文，网络管理报文，XCP报文。不同作用的报文其在协议栈中的信号流路径是不同的。
参考Vector给出的《TechnicalReference_DbcRules_Vector》文档，在DBC文件中对关键属性Attributes的规定如下。
- 应用报文：GenMsgILSupport:Yes
- 网络管理报文:NmAsrMessage:Yes
- XCP报文：
- 根据《TechnicalReference_DbcRules_Vector》规定只要Message中含有大写XCP字样，即可在导入DBC后被Vector的工具自动识别为XCP报文。其他属性同“应用报文：GenMsgILSupport:Yes”
- 如果不用1的方式，也可以在CANIF模块里手动设置其上层模块Upper Layer(PduUserTxConfirmationUL)为XCP模块。其他属性同“应用报文：GenMsgILSupport:Yes”
- 诊断报文：
- 功能寻址:DiagState:Yes
- 物理寻址请求:DiagRequest:Yes
- 物理寻址响应:DiagResponse:Yes(物理寻址和功能寻址的区别请自行摆渡)
报文类型决定信号流路径
以TX报文为例：
普通报文路径：CAN->CANIF->PDUR->COM
诊断报文路径:CAN->CANIF->CANTP->PDUR->DCM
XCP报文路径:CAN->CANIF->XCP
网络管理报文路径:CAN->CANIF->CANNM
之所以把PDUR标红，是因为在下面的配置中方便我们识别PDUR的相关模块，这个要在PduRBswModules配置项中选择的！从这里也可以直接确定，PDUR的PduRBswModules上下文最多只有CANIF,COM,CANTP,DCM。
配置实践
DBC如下：
我习惯将DBC中所有报文简单罗列到一个表中，按报文功能进行分类。这样结合上面我们的总结，就对于每个报文的路径有一个全局的了解。如果项目比较大，报文较多的情况，建议将普通报文之外的报文(NM报文,XCP报文,诊断报文)列出来，因为他们特殊啊！
通过观察DBC属性，制作报文分类表格：
好，接下来进入我们的实战环节。
导入DBC,Update工程, 现在看工具自动配置中遇到的错误还是比较多的, 所以我们接下来的任务就是将这些模块的错误全部Fixed掉!
搞定信号路径
ECUC模块
EcucPduCollection这个Container的作用.数据在CAN通信协议栈各层间都是以PDU形式传输的，为了将各层PDU关联起来，则需要定义全局 PDU（Global PDU）。由于全局PDU不属于任何一个标准BSW模块，所 以AUTOSAR提出了一个EcuC模块来收集一些配置信息。在EcuC模块中定义全局PDU时不需要关心其数据类型，只需要定义PDU长度即可。
所以我们先对照DBC对照检查以下,ECUC/EcucPduCollection对各个PDU(PDU是啥?你可以简单理解成一个PDU就对应总线上的一个Message再附上一个地址信息的这么一个玩意--虽然这种说法不准确,但是它能有助于你去理解)的长度定义是否正确,至于长度之外的错误,先忽略之,后面其他模块配好之后,ECUC中相关错误一般就自动消失了.
CAN模块
CAN模块是直接面向硬件的, 所以CAN模块主要的配置分2部分:
- 对CAN控制器的配置,包括,参考时钟, 波特率,采样点,帧类型,处理方式Polling/Interrupt;
- 和CANIF的联系,即对Hoh和MailBox和Filter的配置)
CAN控制器的配置
本阶段我们只关注CAN控制器的配置! (在后面的步骤中再重点配置Hoh和MailBox和Filte,所以本阶段这三方面的错误先忽略!)
CAN控制器的配置还是比较容易的,如果有什么错误一般根据工具里面给出的提示即可轻易解决。这里科普2个基本知识点, 也是CAN模块一个稍微难懂的概念 - CAN的时钟, CAN的重同步和采样点.
CAN时钟
Can/CanConfigSet/CanControllers/Clock Frequecy这个值是从芯片的时钟树分频而来, 在MCAL的MCU模块中指定.
/Can/CanGeneral/Clock Divider是对上面Can/CanConfigSet/CanControllers/Clock Frequecy的分频, 他们相除的结果在CanControllerBaudrateConfig/CanBaudrateClock中, 比如
Clock Frequecy = 40M, Clock Divider = 1, 则CanBaudrateClock= 40M = 40000KHz.
重同步和采样点
参考文献《CAN总线学习笔记（5）- CAN通信的位定时与同步》这篇博文有非常详尽的介绍（ 如果是Tir1，一般OEM会给出具体的采样点参数值, Autosar工具也会给出参考值）我在这就蜻蜓点水说以下计算原则。
Sync Seg(同步段):长度固定为1Tq, 所以配置工具中没有它的配置.
在Vector的配置工具中, 定义Prop+Seg1 = TSeg1, Seg2 = TSeg2,一开始感觉后别扭,后来发现这样也好,计算采样点位置更加方便了,比如采样点为80%:
(同步段(1) + TSeg1)/(同步段+Tseg1+Tseg2) = 80%,
如果一个BitTime中Tq总和固定了,比如为16个Tq,
同步段(1) + TSeg1 + TSeg2 = 16
根据这个二元一次方程组则很容易算出各段的值.
Sync Seg固定为1, TSeg1 = 11, Seg2 = 4.
SyncJumpWidth:它的值是用于调整相位缓冲段1和相位缓冲段2的值, 用于CAN的同步,比如相位缓冲段1向前增长了3个,则相位缓冲段2向后减少3个Tq.---也就是一次同步中相位缓冲段改变的长度.所以Sync Jump Width的设置有2个原则:
Sync Jump Width <= 3,
Sync Jump Width <= Min(Seg1, Seg2), 因为一次同步调整的幅度不能超出相位缓冲段1和2中任意一个!
敲黑板了,下面画重点:
好了，截止目前，我们把CAN模块的1/2错误都消掉了， 剩下CanHardwareObjects这个容器里面的错误，我们先放下。继续下一步。
CANIF模块
CANIF的配置主要分2部分
- 向上:指定各个PDU的上层模块
- 向下:对Hoh的配置(配置PDU的HOh,对应MailBox和Bufffer,CAN帧的类型)
这一步我们只关注它"向上:指定各个PDU的上层模块"的功能.
检查各个PDU的上层模块
主要配置/CanIf/CanIfInitCfg/CanIfRxPduCfgs和/CanIf/CanIfInitCfg/CanIfTxPduCfgs这两个小container
结合我们上面讲的知识, 检查Davinci Cfg工具/CANIF/Pdu User Tx/Rx Confirmation UL这个配置项对PDU的上层配置是否正确, 即:
- 诊断报文: CANIF之上是CANTP,(CAN->CANIF->CANTP->PDUR->DCM)
- NM报文:CANIF之上是CANNM,(CAN->CANIF->CANNM)
- XCP报文:CANIF之上是XCP,(CAN->CANIF->XCP)
- 普通报文:CANIF之上是PDUR, (CAN->CANIF->PDUR->COM)
如果出现如下错误：
如果不需要Confirmation功能，则可以将Confirmation UL配置项中设为NONE -- 只要到对应模块中检查该PDU确实存在。比如：普通应用报文PDUa，它的上层应该是PDUR， 我们去PDUR中检查，如果它确实被映射到PDUR中了， 则可以在CANIF中将它的Confirmation UL设为NONE.
该容器(/CanIf/CanIfInitCfg/CanIfRxPduCfgs和/CanIf/CanIfInitCfg/CanIfTxPduCfgs)下其他的一些小错误根据工具提示修改即可.
剩下的错误在后面的操作中解决。
XCP模块
主要是配置XCP中用于接收和发送的PDU，如果XcpPdus这一块有错误，则检查你在DBC中和CANIF中指定的XCP收发报文是否已经在XCP中Mapping上了，其他小错误根据提示修改即可。
PDUR模块
PDUR主要有2个作用：对信号的路由，对不同总线信号的网关。
PduRBswModules指定PDUR的上下文模块
根据我们上面的描述，PDUR向下向上的模块分别是：
普通报文: CANIF->PUDR->COM
诊断报文:CANTP->PDUR>DCM
XCP报文和NM报文绕过PDUR。
所以如果你的网咯中没有诊断报文，则PDURBswModules中，PDUR的上下层是CANIF和COM
如果有诊断报文，则PDURBswModules中，PDUR的上下层是CANIF,COM,DCM,CANTP.
PduRRoutingTables
一般工具自动生成的配置，出现错误就在这三个地方。
PduR Transmission Confirmation这个错误主要是由于PDUR的上下层Confirmation没有一致，比如一个TX信号，CANIF中将Confirmation UL指定为PDUR，而在PDUR中将Transmission Confirmation设为False，则自然会报错；又或者在CANIF中将Confirmation UL设为NONE, 而在PDUR中将Transmission Confirmation设为True，则自然会报错。
其他小错误根据提示修改即可。
COM模块
COM模块非常简单,其作用就是将总线上的Msg进行卸货或者装车,装车:将信号组装到Msg里面;卸货:将Msg拆分成一个个的信号,给应用层或者CDD使用.
CANTP模块
因为诊断协议中有多帧连续帧的概念,有些报文一帧是发不完的, 所以CANTp模块的主要作用是对CAN I-PDU进行分段和重新组装，使得I-PDU的长度不大于8个字节，对CAN FD而言，CAN I-PDU不大于64个字节。
这里面的难点应该就是一些时间参数的设定, 这个要结合UDS的14229/15765/11898和主机厂释放的网络规范进行设定.
搞定Hoh和MailBox
（有朋友反应这一块有很多错误，好吧，我们先讲这一块）
CAN模块下面的CanHardwareObjects其实就是MailBox，是硬件上的存在。CANIF下面的Hoh包含Hrh(接收)和Hth(发送)是报文收发的句柄，是一个软件概念。
结合我们上面的工作， 我接下来主要是对
- CAN部分MailBox和Filter的配置
- CANIF部分Hoh的配置
CAN模块中MailBox配置
CanHardwareObjects
先检查CanHardwareObjects这个容器下面, 检查HardwareObject的数量.注意此时HardwareObject还没有和CANIF中的PDU建立任何关系!--这模块的HardwareObject我习惯叫它MailBox!
根据DBC中Message个数, 设置CAN模块下面每个CanHardwareObjects(就是MailBox)的CanHandleType,设为Full CAN还是Basic CAN.
Full CAN和Basic CAN
先说结论:
- Full CAN一个Hoh对应一个MailBox而Basic CAN一个MailBox可以处理多个PDU.
- Full CAN是硬件滤波而Basic CAN软件滤波,因此配成Basic的要设置滤波.
- Full CAN一个Buffer对应一个ID报文,无缓存功能而Basic CAN以FIFO的方式接受特定的多个报文,有缓存功能.
因此:
- 对于诊断报文和NM报文的接收报文必须配置成Basic Can,
- 其他报文最好配成高效的Full CAN.
关于Full CAN和Basic CAN, 这篇文章讲的很详细《【AUTOSAR-CAN】CAN的 “BasicCAN架构” 和 “FullCAN架构”》, 这里我说一下我的理解, 不一定很准确,但有助于理解.
如果你在CanHardwareObjects这个容器下面配置的BasicCAN个数>1(Tx MailBox>1个或者Rx的MailBox>1个)这个时候你应该会遇到一个报错:
这是翻译成人话就是你没有使能Multi BasicCAN或者你么有更高级的授权, 而这个时候你进入CanGeneral这个容器下面却发现不允许使能Multi BasicCAN!!
是不是很崩溃?---没关系, 按下面这样做:
将所有Tx的BasicCAN删除到只剩一个, Rx的BasicCAN删除只剩一个,然后命名(随个人喜好)TxBasicCanMailBoxCommon和RxBasicCanMailBoxCommon.然后设置其Size大小为之前所有BasicCAN的MailBox总和!
最后别忘了给接收的BasicCAN设置滤波,并绑定:
在CanFilterMasks下面设置滤波, 在BasicCAN的MailBox下面设置映射:
再科普以下滤波的设置:
滤波参数
白名单模式计算原则是: received ID & Mask == Code & Mask.
有一个简便的方法就是,Code Value里面填写ID大的那个ID值, Mask Value里面填写ID小的那个ID值.
例如:我只想接受0x7DF和0x7D4这两个报文,将其他报文过滤掉. 根据计算公式,对于0x7DF报文,
0x7DF & 0x7D4 == 0x7DF & 0x7D4
对于0x7D4报文, 0x7D4 & 0x7D4 == 0x7DF & 0x7D4
好了,纵然现在千般错, 先放过.去CANIF模块!
CANIF模块中的PDU(Rx和Tx PDU)
进入/CanIf/CanIfInitCfg/CanIfInitHohCfgs/CanIfInitHohCfg/CanIfHrhCfgs这个下面,
将诊断Rx PDU和网络管理的Rx PDU(他们是Basic Can)都映射到CAN模块下面的RxBasicCanMailBoxCommon上!并勾选CanIfHrhSoftwareFilter.
将XCP报文和普通应用报文与CAN模块下面的MailBox进行一对一映射!--因为他们是FULL CAN!
并取消CanIfHrhSoftwareFilter.
进入/CanIf/CanIfInitCfg/CanIfInitHohCfgs/CanIfInitHohCfg/CanIfHthCfgs这个下面,安装上面的步骤操作即可!
接下来为Tx的PDU配置Buffer即可!
其他一些错误根据工具提示修复即可.这一块相互绑定关系我做个图谱:
截止目前CAN和CANIF的错误就全部消除了
参考文献
CAN总线学习笔记（5）- CAN通信的位定时与同步
【AUTOSAR-CAN】CAN的 “BasicCAN架构” 和 “FullCAN架构”