前言

通訊協(xié)議棧幾乎是CP AUTOSAR中最龐雜的一塊。由于其涉及的模塊比較多(僅實(shí)現(xiàn)CAN信號(hào)的收發(fā)就需要ECUC/CAN/CANIF/CANTP/PDUR/COM/XCP這么多模塊的協(xié)作！)，且名詞概念眾多，入門很難。網(wǎng)絡(luò)上關(guān)于各個(gè)模塊的詳細(xì)介紹浩如煙海，其深度也讓人嘆為觀止。但沒(méi)有一篇文章把這些模塊串起來(lái)！

這就導(dǎo)致對(duì)于初學(xué)者來(lái)說(shuō)，往往耐心的把各個(gè)模塊的詳細(xì)介紹都看完，甚至把AUTOSAR標(biāo)準(zhǔn)文檔讀完，依然不能建立一個(gè)全局的思路。導(dǎo)致在配置通訊協(xié)議棧時(shí)候，導(dǎo)入DBC之后，一看那么多錯(cuò)誤，無(wú)從下手或者解決了CANIF的錯(cuò)誤，PDUR又出現(xiàn)了新的錯(cuò)誤提示，解決了PDUR錯(cuò)誤，ECUC又報(bào)錯(cuò)...按下葫蘆浮起瓢，這種窘境，我相信絕對(duì)是每個(gè)AUTOSAR初學(xué)者都遇到過(guò)的。

本文試圖從一個(gè)全局的高度，自頂向下逐步細(xì)化開(kāi)來(lái)。讓你在建立全局觀之后熟悉通訊協(xié)議棧各模塊之間的關(guān)聯(lián)然后高屋建瓴學(xué)會(huì)配置每一項(xiàng)！也希望在此拋磚引玉，彼此交流心得,共同進(jìn)步。

1.DBC屬性與信號(hào)流

1.1 DBC屬性決定報(bào)文類型

不同的DBC屬性決定不同功能的報(bào)文, 一般實(shí)際項(xiàng)目中涉及的報(bào)文為4類:應(yīng)用報(bào)文，診斷報(bào)文，網(wǎng)絡(luò)管理報(bào)文，XCP報(bào)文。不同作用的報(bào)文其在協(xié)議棧中的信號(hào)流路徑是不同的。

參考Vector給出的《TechnicalReference_DbcRules_Vector》文檔，在DBC文件中對(duì)關(guān)鍵屬性Attributes的規(guī)定如下。

應(yīng)用報(bào)文：GenMsgILSupport:Yes

網(wǎng)絡(luò)管理報(bào)文Yes

XCP報(bào)文：

根據(jù)《TechnicalReference_DbcRules_Vector》規(guī)定只要Message中含有大寫XCP字樣，即可在導(dǎo)入DBC后被Vector的工具自動(dòng)識(shí)別為XCP報(bào)文。其他屬性同“應(yīng)用報(bào)文：GenMsgILSupport:Yes”

如果不用1的方式，也可以在CANIF模塊里手動(dòng)設(shè)置其上層模塊Upper Layer(PduUserTxConfirmationUL)為XCP模塊。其他屬性同“應(yīng)用報(bào)文：GenMsgILSupport:Yes”

診斷報(bào)文：

功能尋址Yes

物理尋址請(qǐng)求Yes

物理尋址響應(yīng)Yes(物理尋址和功能尋址的區(qū)別請(qǐng)自行擺渡)

1.2 報(bào)文類型決定信號(hào)流路徑

以TX報(bào)文為例：

普通報(bào)文路徑：CAN->CANIF->PDUR->COM

診斷報(bào)文路徑:CAN->CANIF->CANTP->PDUR->DCM

XCP報(bào)文路徑:CAN->CANIF->XCP

網(wǎng)絡(luò)管理報(bào)文路徑:CAN->CANIF->CANNM

之所以把PDUR標(biāo)紅，是因?yàn)樵谙旅娴呐渲弥蟹奖阄覀冏R(shí)別PDUR的相關(guān)模塊，這個(gè)要在PduRBswModules配置項(xiàng)中選擇的！從這里也可以直接確定，PDUR的PduRBswModules上下文最多只有CANIF,COM,CANTP,DCM。

2. 配置實(shí)踐

DBC如下：

我習(xí)慣將DBC中所有報(bào)文簡(jiǎn)單羅列到一個(gè)表中，按報(bào)文功能進(jìn)行分類。這樣結(jié)合上面我們的總結(jié)，就對(duì)于每個(gè)報(bào)文的路徑有一個(gè)全局的了解。如果項(xiàng)目比較大，報(bào)文較多的情況，建議將普通報(bào)文之外的報(bào)文(NM報(bào)文,XCP報(bào)文,診斷報(bào)文)列出來(lái)，因?yàn)樗麄兲厥獍。?/p>

通過(guò)觀察DBC屬性，制作報(bào)文分類表格：

好，接下來(lái)進(jìn)入我們的實(shí)戰(zhàn)環(huán)節(jié)。

導(dǎo)入DBC,Update工程, 現(xiàn)在看工具自動(dòng)配置中遇到的錯(cuò)誤還是比較多的, 所以我們接下來(lái)的任務(wù)就是將這些模塊的錯(cuò)誤全部Fixed掉!

2.1 搞定信號(hào)路徑

2.1.1 ECUC模塊

EcucPduCollection這個(gè)Container的作用.數(shù)據(jù)在CAN通信協(xié)議棧各層間都是以PDU形式傳輸?shù)模瑸榱藢⒏鲗覲DU關(guān)聯(lián)起來(lái)，則需要定義全局 PDU（Global PDU）。由于全局PDU不屬于任何一個(gè)標(biāo)準(zhǔn)BSW模塊，所 以AUTOSAR提出了一個(gè)EcuC模塊來(lái)收集一些配置信息。在EcuC模塊中定義全局PDU時(shí)不需要關(guān)心其數(shù)據(jù)類型，只需要定義PDU長(zhǎng)度即可。

所以我們先對(duì)照DBC對(duì)照檢查以下,ECUC/EcucPduCollection對(duì)各個(gè)PDU(PDU是啥?你可以簡(jiǎn)單理解成一個(gè)PDU就對(duì)應(yīng)總線上的一個(gè)Message再附上一個(gè)地址信息的這么一個(gè)玩意--雖然這種說(shuō)法不準(zhǔn)確,但是它能有助于你去理解)的長(zhǎng)度定義是否正確,至于長(zhǎng)度之外的錯(cuò)誤,先忽略之,后面其他模塊配好之后,ECUC中相關(guān)錯(cuò)誤一般就自動(dòng)消失了.

2.1.2CAN模塊

CAN模塊是直接面向硬件的, 所以CAN模塊主要的配置分2部分:

對(duì)CAN控制器的配置,包括,參考時(shí)鐘, 波特率,采樣點(diǎn),幀類型,處理方式Polling/Interrupt;

和CANIF的聯(lián)系,即對(duì)Hoh和MailBox和Filter的配置)

CAN控制器的配置

本階段我們只關(guān)注CAN控制器的配置! (在后面的步驟中再重點(diǎn)配置Hoh和MailBox和Filte,所以本階段這三方面的錯(cuò)誤先忽略!)

CAN控制器的配置還是比較容易的,如果有什么錯(cuò)誤一般根據(jù)工具里面給出的提示即可輕易解決。這里科普2個(gè)基本知識(shí)點(diǎn), 也是CAN模塊一個(gè)稍微難懂的概念 - CAN的時(shí)鐘, CAN的重同步和采樣點(diǎn).

CAN時(shí)鐘

Can/CanConfigSet/CanControllers/Clock Frequecy這個(gè)值是從芯片的時(shí)鐘樹(shù)分頻而來(lái), 在MCAL的MCU模塊中指定.

/Can/CanGeneral/Clock Divider是對(duì)上面Can/CanConfigSet/CanControllers/Clock Frequecy的分頻, 他們相除的結(jié)果在CanControllerBaudrateConfig/CanBaudrateClock中, 比如

Clock Frequecy = 40M, Clock Divider = 1, 則CanBaudrateClock= 40M = 40000KHz.

重同步和采樣點(diǎn)

參考文獻(xiàn)《CAN總線學(xué)習(xí)筆記（5）- CAN通信的位定時(shí)與同步》這篇博文有非常詳盡的介紹（ 如果是Tir1，一般OEM會(huì)給出具體的采樣點(diǎn)參數(shù)值, Autosar工具也會(huì)給出參考值）我在這就蜻蜓點(diǎn)水說(shuō)以下計(jì)算原則。

Sync Seg(同步段):長(zhǎng)度固定為1Tq, 所以配置工具中沒(méi)有它的配置.

在Vector的配置工具中, 定義Prop+Seg1 = TSeg1, Seg2 = TSeg2,一開(kāi)始感覺(jué)后別扭,后來(lái)發(fā)現(xiàn)這樣也好,計(jì)算采樣點(diǎn)位置更加方便了,比如采樣點(diǎn)為80%:

(同步段(1) + TSeg1)/(同步段+Tseg1+Tseg2) = 80%,

如果一個(gè)BitTime中Tq總和固定了,比如為16個(gè)Tq,

同步段(1) + TSeg1 + TSeg2 = 16

根據(jù)這個(gè)二元一次方程組則很容易算出各段的值.

Sync Seg固定為1, TSeg1 = 11, Seg2 = 4.

SyncJumpWidth:它的值是用于調(diào)整相位緩沖段1和相位緩沖段2的值, 用于CAN的同步,比如相位緩沖段1向前增長(zhǎng)了3個(gè),則相位緩沖段2向后減少3個(gè)Tq.---也就是一次同步中相位緩沖段改變的長(zhǎng)度.所以Sync Jump Width的設(shè)置有2個(gè)原則:

Sync Jump Width <= 3,

Sync Jump Width <= Min(Seg1, Seg2), 因?yàn)橐淮瓮秸{(diào)整的幅度不能超出相位緩沖段1和2中任意一個(gè)!

敲黑板了,下面畫重點(diǎn):

好了，截止目前，我們把CAN模塊的1/2錯(cuò)誤都消掉了， 剩下CanHardwareObjects這個(gè)容器里面的錯(cuò)誤，我們先放下。繼續(xù)下一步。

2.1.3CANIF模塊

CANIF的配置主要分2部分

向上:指定各個(gè)PDU的上層模塊

向下:對(duì)Hoh的配置(配置PDU的HOh,對(duì)應(yīng)MailBox和Bufffer,CAN幀的類型)

這一步我們只關(guān)注它"向上:指定各個(gè)PDU的上層模塊"的功能.

檢查各個(gè)PDU的上層模塊

主要配置/CanIf/CanIfInitCfg/CanIfRxPduCfgs和/CanIf/CanIfInitCfg/CanIfTxPduCfgs這兩個(gè)小container

結(jié)合我們上面講的知識(shí), 檢查Davinci Cfg工具/CANIF/Pdu User Tx/Rx Confirmation UL這個(gè)配置項(xiàng)對(duì)PDU的上層配置是否正確, 即:

診斷報(bào)文: CANIF之上是CANTP,(CAN->CANIF->CANTP->PDUR->DCM)

NM報(bào)文:CANIF之上是CANNM,(CAN->CANIF->CANNM)

XCP報(bào)文:CANIF之上是XCP,(CAN->CANIF->XCP)

普通報(bào)文:CANIF之上是PDUR, (CAN->CANIF->PDUR->COM)

如果出現(xiàn)如下錯(cuò)誤：

如果不需要Confirmation功能，則可以將Confirmation UL配置項(xiàng)中設(shè)為NONE -- 只要到對(duì)應(yīng)模塊中檢查該P(yáng)DU確實(shí)存在。比如：普通應(yīng)用報(bào)文PDUa，它的上層應(yīng)該是PDUR， 我們?nèi)DUR中檢查，如果它確實(shí)被映射到PDUR中了， 則可以在CANIF中將它的Confirmation UL設(shè)為NONE.

該容器(/CanIf/CanIfInitCfg/CanIfRxPduCfgs和/CanIf/CanIfInitCfg/CanIfTxPduCfgs)下其他的一些小錯(cuò)誤根據(jù)工具提示修改即可.

剩下的錯(cuò)誤在后面的操作中解決。

2.1.4XCP模塊

主要是配置XCP中用于接收和發(fā)送的PDU，如果XcpPdus這一塊有錯(cuò)誤，則檢查你在DBC中和CANIF中指定的XCP收發(fā)報(bào)文是否已經(jīng)在XCP中Mapping上了，其他小錯(cuò)誤根據(jù)提示修改即可。

2.1.5PDUR模塊

PDUR主要有2個(gè)作用：對(duì)信號(hào)的路由，對(duì)不同總線信號(hào)的網(wǎng)關(guān)。

PduRBswModules指定PDUR的上下文模塊

根據(jù)我們上面的描述，PDUR向下向上的模塊分別是：

普通報(bào)文: CANIF->PUDR->COM

診斷報(bào)文:CANTP->PDUR>DCM

XCP報(bào)文和NM報(bào)文繞過(guò)PDUR。

所以如果你的網(wǎng)咯中沒(méi)有診斷報(bào)文，則PDURBswModules中，PDUR的上下層是CANIF和COM

如果有診斷報(bào)文，則PDURBswModules中，PDUR的上下層是CANIF,COM,DCM,CANTP.

PduRRoutingTables

一般工具自動(dòng)生成的配置，出現(xiàn)錯(cuò)誤就在這三個(gè)地方。

PduR Transmission Confirmation這個(gè)錯(cuò)誤主要是由于PDUR的上下層Confirmation沒(méi)有一致，比如一個(gè)TX信號(hào)，CANIF中將Confirmation UL指定為PDUR，而在PDUR中將Transmission Confirmation設(shè)為False，則自然會(huì)報(bào)錯(cuò)；又或者在CANIF中將Confirmation UL設(shè)為NONE, 而在PDUR中將Transmission Confirmation設(shè)為True，則自然會(huì)報(bào)錯(cuò)。

其他小錯(cuò)誤根據(jù)提示修改即可。

2.1.6COM模塊

COM模塊非常簡(jiǎn)單,其作用就是將總線上的Msg進(jìn)行卸貨或者裝車,裝車:將信號(hào)組裝到Msg里面;卸貨:將Msg拆分成一個(gè)個(gè)的信號(hào),給應(yīng)用層或者CDD使用.

2.1.7CANTP模塊

因?yàn)樵\斷協(xié)議中有多幀連續(xù)幀的概念,有些報(bào)文一幀是發(fā)不完的, 所以CANTp模塊的主要作用是對(duì)CAN I-PDU進(jìn)行分段和重新組裝，使得I-PDU的長(zhǎng)度不大于8個(gè)字節(jié)，對(duì)CAN FD而言，CAN I-PDU不大于64個(gè)字節(jié)。

這里面的難點(diǎn)應(yīng)該就是一些時(shí)間參數(shù)的設(shè)定, 這個(gè)要結(jié)合UDS的14229/15765/11898和主機(jī)廠釋放的網(wǎng)絡(luò)規(guī)范進(jìn)行設(shè)定.

2.2 搞定Hoh和MailBox

（有朋友反應(yīng)這一塊有很多錯(cuò)誤，好吧，我們先講這一塊）

CAN模塊下面的CanHardwareObjects其實(shí)就是MailBox，是硬件上的存在。CANIF下面的Hoh包含Hrh(接收)和Hth(發(fā)送)是報(bào)文收發(fā)的句柄，是一個(gè)軟件概念。

結(jié)合我們上面的工作， 我接下來(lái)主要是對(duì)

CAN部分MailBox和Filter的配置

CANIF部分Hoh的配置

2.2.1 CAN模塊中MailBox配置

CanHardwareObjects

先檢查CanHardwareObjects這個(gè)容器下面, 檢查HardwareObject的數(shù)量.注意此時(shí)HardwareObject還沒(méi)有和CANIF中的PDU建立任何關(guān)系!--這模塊的HardwareObject我習(xí)慣叫它MailBox!

根據(jù)DBC中Message個(gè)數(shù), 設(shè)置CAN模塊下面每個(gè)CanHardwareObjects(就是MailBox)的CanHandleType,設(shè)為Full CAN還是Basic CAN.

Full CAN和Basic CAN

先說(shuō)結(jié)論:

Full CAN一個(gè)Hoh對(duì)應(yīng)一個(gè)MailBox而B(niǎo)asic CAN一個(gè)MailBox可以處理多個(gè)PDU.

Full CAN是硬件濾波而B(niǎo)asic CAN軟件濾波,因此配成Basic的要設(shè)置濾波.

Full CAN一個(gè)Buffer對(duì)應(yīng)一個(gè)ID報(bào)文,無(wú)緩存功能而B(niǎo)asic CAN以FIFO的方式接受特定的多個(gè)報(bào)文,有緩存功能.

因此:

對(duì)于診斷報(bào)文和NM報(bào)文的接收?qǐng)?bào)文必須配置成Basic Can,

其他報(bào)文最好配成高效的Full CAN.

關(guān)于Full CAN和Basic CAN, 這篇文章講的很詳細(xì)《【AUTOSAR-CAN】CAN的 “BasicCAN架構(gòu)” 和 “FullCAN架構(gòu)”》, 這里我說(shuō)一下我的理解, 不一定很準(zhǔn)確,但有助于理解.

如果你在CanHardwareObjects這個(gè)容器下面配置的BasicCAN個(gè)數(shù)>1(Tx MailBox>1個(gè)或者Rx的MailBox>1個(gè))這個(gè)時(shí)候你應(yīng)該會(huì)遇到一個(gè)報(bào)錯(cuò):

這是翻譯成人話就是你沒(méi)有使能Multi BasicCAN或者你么有更高級(jí)的授權(quán), 而這個(gè)時(shí)候你進(jìn)入CanGeneral這個(gè)容器下面卻發(fā)現(xiàn)不允許使能Multi BasicCAN!!

是不是很崩潰?---沒(méi)關(guān)系, 按下面這樣做:

將所有Tx的BasicCAN刪除到只剩一個(gè), Rx的BasicCAN刪除只剩一個(gè),然后命名(隨個(gè)人喜好)TxBasicCanMailBoxCommon和RxBasicCanMailBoxCommon.然后設(shè)置其Size大小為之前所有BasicCAN的MailBox總和!

最后別忘了給接收的BasicCAN設(shè)置濾波,并綁定:

在CanFilterMasks下面設(shè)置濾波, 在BasicCAN的MailBox下面設(shè)置映射:

再科普以下濾波的設(shè)置:

濾波參數(shù)

白名單模式計(jì)算原則是:received ID & Mask == Code & Mask.

有一個(gè)簡(jiǎn)便的方法就是,Code Value里面填寫ID大的那個(gè)ID值, Mask Value里面填寫ID小的那個(gè)ID值兩個(gè)數(shù)按位與后的值.

例如:我只想接受0x7DF和0x7D4這兩個(gè)報(bào)文,將其他報(bào)文過(guò)濾掉. 根據(jù)計(jì)算公式,對(duì)于0x7DF報(bào)文,

0x7DF & 0x7D4 == 0x7DF & 0x7D4

對(duì)于0x7D4報(bào)文, 0x7D4 & 0x7D4 == 0x7DF & 0x7D4

好了,縱然現(xiàn)在千般錯(cuò), 先放過(guò).去CANIF模塊!

2.2.2 CANIF模塊中的PDU(Rx和Tx PDU)

進(jìn)入/CanIf/CanIfInitCfg/CanIfInitHohCfgs/CanIfInitHohCfg/CanIfHrhCfgs這個(gè)下面,

將診斷Rx PDU和網(wǎng)絡(luò)管理的Rx PDU(他們是Basic Can)都映射到CAN模塊下面的RxBasicCanMailBoxCommon上!并勾選CanIfHrhSoftwareFilter.

將XCP報(bào)文和普通應(yīng)用報(bào)文與CAN模塊下面的MailBox進(jìn)行一對(duì)一映射!--因?yàn)樗麄兪荈ULL CAN!

并取消CanIfHrhSoftwareFilter.

進(jìn)入/CanIf/CanIfInitCfg/CanIfInitHohCfgs/CanIfInitHohCfg/CanIfHthCfgs這個(gè)下面,安裝上面的步驟操作即可!

接下來(lái)為Tx的PDU配置Buffer即可!

其他一些錯(cuò)誤根據(jù)工具提示修復(fù)即可.這一塊相互綁定關(guān)系我做個(gè)圖譜:

截止目前CAN和CANIF的錯(cuò)誤就全部消除了

審核編輯：湯梓紅