前言

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

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

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

1.DBC屬性與信號流

1.1 DBC屬性決定報文類型

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

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

應用報文：GenMsgILSupport:Yes

網(wǎng)絡管理報文Yes

XCP報文：

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

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

診斷報文：

功能尋址Yes

物理尋址請求Yes

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

1.2 報文類型決定信號流路徑

以TX報文為例：

普通報文路徑：CAN->CANIF->PDUR->COM

診斷報文路徑:CAN->CANIF->CANTP->PDUR->DCM

XCP報文路徑:CAN->CANIF->XCP

網(wǎng)絡管理報文路徑:CAN->CANIF->CANNM

之所以把PDUR標紅，是因為在下面的配置中方便我們識別PDUR的相關(guān)模塊，這個要在PduRBswModules配置項中選擇的！從這里也可以直接確定，PDUR的PduRBswModules上下文最多只有CANIF,COM,CANTP,DCM。

2. 配置實踐

DBC如下：

我習慣將DBC中所有報文簡單羅列到一個表中，按報文功能進行分類。這樣結(jié)合上面我們的總結(jié)，就對于每個報文的路徑有一個全局的了解。如果項目比較大，報文較多的情況，建議將普通報文之外的報文(NM報文,XCP報文,診斷報文)列出來，因為他們特殊??！

通過觀察DBC屬性，制作報文分類表格：

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

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

2.1 搞定信號路徑

2.1.1 ECUC模塊

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

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

2.1.2CAN模塊

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

對CAN控制器的配置,包括,參考時鐘, 波特率,采樣點,幀類型,處理方式Polling/Interrupt;

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

CAN控制器的配置

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

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

CAN時鐘

Can/CanConfigSet/CanControllers/Clock Frequecy這個值是從芯片的時鐘樹分頻而來, 在MCAL的MCU模塊中指定.

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

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

重同步和采樣點

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

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

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

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

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

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

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

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

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

Sync Jump Width <= 3,

Sync Jump Width <= Min(Seg1, Seg2), 因為一次同步調(diào)整的幅度不能超出相位緩沖段1和2中任意一個!

敲黑板了,下面畫重點:

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

2.1.3CANIF模塊

CANIF的配置主要分2部分

向上:指定各個PDU的上層模塊

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

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

檢查各個PDU的上層模塊

主要配置/CanIf/CanIfInitCfg/CanIfRxPduCfgs和/CanIf/CanIfInitCfg/CanIfTxPduCfgs這兩個小container

結(jié)合我們上面講的知識, 檢查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)

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

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

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

剩下的錯誤在后面的操作中解決。

2.1.4XCP模塊

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

2.1.5PDUR模塊

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

PduRBswModules指定PDUR的上下文模塊

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

普通報文: CANIF->PUDR->COM

診斷報文:CANTP->PDUR>DCM

XCP報文和NM報文繞過PDUR。

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

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

PduRRoutingTables

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

PduR Transmission Confirmation這個錯誤主要是由于PDUR的上下層Confirmation沒有一致，比如一個TX信號，CANIF中將Confirmation UL指定為PDUR，而在PDUR中將Transmission Confirmation設為False，則自然會報錯；又或者在CANIF中將Confirmation UL設為NONE, 而在PDUR中將Transmission Confirmation設為True，則自然會報錯。

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

2.1.6COM模塊

COM模塊非常簡單,其作用就是將總線上的Msg進行卸貨或者裝車,裝車:將信號組裝到Msg里面;卸貨:將Msg拆分成一個個的信號,給應用層或者CDD使用.

2.1.7CANTP模塊

因為診斷協(xié)議中有多幀連續(xù)幀的概念,有些報文一幀是發(fā)不完的, 所以CANTp模塊的主要作用是對CAN I-PDU進行分段和重新組裝，使得I-PDU的長度不大于8個字節(jié)，對CAN FD而言，CAN I-PDU不大于64個字節(jié)。

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

2.2 搞定Hoh和MailBox

（有朋友反應這一塊有很多錯誤，好吧，我們先講這一塊）

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

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

CAN部分MailBox和Filter的配置

CANIF部分Hoh的配置

2.2.1 CAN模塊中MailBox配置

CanHardwareObjects

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

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

Full CAN和Basic CAN

先說結(jié)論:

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.

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

如果你在CanHardwareObjects這個容器下面配置的BasicCAN個數(shù)>1(Tx MailBox>1個或者Rx的MailBox>1個)這個時候你應該會遇到一個報錯:

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

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

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

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

在CanFilterMasks下面設置濾波, 在BasicCAN的MailBox下面設置映射:

再科普以下濾波的設置:

濾波參數(shù)

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

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

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

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

對于0x7D4報文, 0x7D4 & 0x7D4 == 0x7DF & 0x7D4

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

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

進入/CanIf/CanIfInitCfg/CanIfInitHohCfgs/CanIfInitHohCfg/CanIfHrhCfgs這個下面,

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

將XCP報文和普通應用報文與CAN模塊下面的MailBox進行一對一映射!--因為他們是FULL CAN!

并取消CanIfHrhSoftwareFilter.

進入/CanIf/CanIfInitCfg/CanIfInitHohCfgs/CanIfInitHohCfg/CanIfHthCfgs這個下面,安裝上面的步驟操作即可!

接下來為Tx的PDU配置Buffer即可!

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

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

審核編輯：湯梓紅