AUTOSAR实战教程-通信协议栈介绍

1.DBC属性与信号流

1.1 DBC属性决定报文类型

不同的DBC属性决定不同功能的报文, 一般实际项目中涉及的报文为4类:应用报文，诊断报文，网络管理报文，XCP报文。不同作用的报文其在协议栈中的信号流路径是不同的。

参考Vector给出的《TechnicalReference_DbcRules_Vector》文档，在DBC文件中对关键属性Attributes的规定如下。

          

应用报文：GenMsgILSupport:Yes

网络管理报文Yes

XCP报文：

根据《TechnicalReference_DbcRules_Vector》规定只要Message中含有大写XCP字样，即可在导入DBC后被Vector的工具自动识别为XCP报文。其他属性同“应用报文：GenMsgILSupport:Yes”

如果不用1的方式，也可以在CANIF模块里手动设置其上层模块Upper Layer(PduUserTxConfirmationUL)为XCP模块。其他属性同“应用报文：GenMsgILSupport:Yes”

诊断报文：

功能寻址Yes

物理寻址请求Yes

物理寻址响应Yes(物理寻址和功能寻址的区别请自行摆渡)

1.2 报文类型决定信号流路径

以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。

2. 配置实践

DBC如下： 

我习惯将DBC中所有报文简单罗列到一个表中，按报文功能进行分类。这样结合上面我们的总结，就对于每个报文的路径有一个全局的了解。如果项目比较大，报文较多的情况，建议将普通报文之外的报文(NM报文,XCP报文,诊断报文)列出来，因为他们特殊啊！

通过观察DBC属性，制作报文分类表格：

 好，接下来进入我们的实战环节。

导入DBC,Update工程, 现在看工具自动配置中遇到的错误还是比较多的, 所以我们接下来的任务就是将这些模块的错误全部Fixed掉!

2.1 搞定信号路径

2.1.1 ECUC模块

EcucPduCollection这个Container的作用.数据在CAN通信协议栈各层间都是以PDU形式传输的，为了将各层PDU关联起来，则需要定义全局 PDU（Global PDU）。由于全局PDU不属于任何一个标准BSW模块，所 以AUTOSAR提出了一个EcuC模块来收集一些配置信息。在EcuC模块中定义全局PDU时不需要关心其数据类型，只需要定义PDU长度即可。

所以我们先对照DBC对照检查以下,ECUC/EcucPduCollection对各个PDU(PDU是啥?你可以简单理解成一个PDU就对应总线上的一个Message再附上一个地址信息的这么一个玩意--虽然这种说法不准确,但是它能有助于你去理解)的长度定义是否正确,至于长度之外的错误,先忽略之,后面其他模块配好之后,ECUC中相关错误一般就自动消失了.

2.1.2 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这个容器里面的错误，我们先放下。继续下一步。

2.1.3 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)下其他的一些小错误根据工具提示修改即可.

剩下的错误在后面的操作中解决。

 2.1.4 XCP模块

主要是配置XCP中用于接收和发送的PDU，如果XcpPdus这一块有错误，则检查你在DBC中和CANIF中指定的XCP收发报文是否已经在XCP中Mapping上了，其他小错误根据提示修改即可。

2.1.5 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，则自然会报错。

其他小错误根据提示修改即可。

2.1.6 COM模块

COM模块非常简单,其作用就是将总线上的Msg进行卸货或者装车,装车:将信号组装到Msg里面;卸货:将Msg拆分成一个个的信号,给应用层或者CDD使用.

2.1.7 CANTP模块

因为诊断协议中有多帧连续帧的概念,有些报文一帧是发不完的, 所以CANTp模块的主要作用是对CAN I-PDU进行分段和重新组装，使得I-PDU的长度不大于8个字节，对CAN FD而言，CAN I-PDU不大于64个字节。

这里面的难点应该就是一些时间参数的设定, 这个要结合UDS的14229/15765/11898和主机厂释放的网络规范进行设定.

2.2 搞定Hoh和MailBox

（有朋友反应这一块有很多错误，好吧，我们先讲这一块）

CAN模块下面的CanHardwareObjects其实就是MailBox，是硬件上的存在。CANIF下面的Hoh包含Hrh(接收)和Hth(发送)是报文收发的句柄，是一个软件概念。

结合我们上面的工作， 我接下来主要是对

CAN部分MailBox和Filter的配置

CANIF部分Hoh的配置

2.2.1 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模块!

2.2.2 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的错误就全部消除了

来源：坐看云起会有时

审核编辑：刘清