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.2CAN模塊

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.3CANIF模塊

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.4XCP模塊

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

2.1.5PDUR模塊

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.6COM模塊

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

2.1.7CANTP模塊

因為診斷協議中有多幀連續幀的概念,有些報文一幀是發不完的, 所以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的錯誤就全部消除了

來源：坐看云起會有時

審核編輯：劉清