作者| 糊涂振

出品| 汽車(chē)電子與軟件

在軟件定義汽車(chē)這個(gè)時(shí)代，汽車(chē)功能越來(lái)越豐富，隨之ECU越來(lái)越多，有些功能靠ECU獨(dú)立實(shí)現(xiàn)，有些功能則需要多個(gè)ECU聯(lián)合實(shí)現(xiàn)。總體來(lái)說(shuō)，ECU絕大多數(shù)情況下都需要與其他ECU進(jìn)行信息交互，比如充電功能，車(chē)載充電機(jī)OBC需要聯(lián)合電池管理系統(tǒng)BMS和整車(chē)控制器VCU等聯(lián)合才能實(shí)現(xiàn)。因此，這些ECU采取怎樣的通訊方式來(lái)實(shí)現(xiàn)信息交互？目前，常用的ECU通訊方式有 CAN，LIN和FlexRay，同時(shí)隨著汽車(chē)電子電器架構(gòu)朝著中央集成控制方向發(fā)展，以太網(wǎng)的應(yīng)用也越來(lái)越廣泛。

source：the software Car: Building ICT Architectures for Future Electric Vehicles

當(dāng)然不管汽車(chē)電子電器架構(gòu)發(fā)展多么迅速，CAN通訊仍將無(wú)處不在，持續(xù)對(duì)ECU之間的信息交互扮演著極其關(guān)鍵的角色。因此，本文從ECU系統(tǒng)層級(jí)角度來(lái)探討CAN通訊都會(huì)有怎樣的需求，以及如何去理解與評(píng)估這些需求。

#01

CAN通訊需求的分析與分解

汽車(chē)ECU基本都采用V流程開(kāi)發(fā)，先由OEM提供功能開(kāi)發(fā)需求，然后經(jīng)過(guò)ECU系統(tǒng)的分析與評(píng)估，再分配給ECU軟硬件進(jìn)行相應(yīng)的開(kāi)發(fā)與驗(yàn)證，最后由系統(tǒng)進(jìn)行驗(yàn)證和確認(rèn)。

Source:

本文將側(cè)重點(diǎn)在ECU系統(tǒng)層面視角來(lái)看這些CAN通訊需求。通常ECU系統(tǒng)收到在客戶(hù)關(guān)于CAN通訊的需求會(huì)涉及以下幾個(gè)點(diǎn):

• ECU需要具備幾路CAN，每路CAN的基本要求是什么；

• 每條CAN需要具備哪些功能；

• CAN通訊矩陣或DBC是怎樣的。

這些需求就是ECU CAN通訊開(kāi)發(fā)的起點(diǎn)，一般稱(chēng)為客戶(hù)需求或者利益相關(guān)者需求Stakeholder requirement。在ECU系統(tǒng)層面，系統(tǒng)工程師收到這些需求后，會(huì)拉上相關(guān)利益者一起來(lái)評(píng)估這些需求，包括硬件，軟件和功能安全等項(xiàng)目?jī)?nèi)部成員，同時(shí)也會(huì)和客戶(hù)多次對(duì)齊，最終明確好這些CAN通訊需求。

接著系統(tǒng)工程師將在ECU系統(tǒng)層面將需求細(xì)化為ECU系統(tǒng)需求，比如:

• ECU需要兩路CAN，CAN1用于ECU之間的信息交互，CAN2用于診斷和標(biāo)定；

• 兩路CAN都為CAN FD，仲裁段波特率500Kbps，數(shù)據(jù)段波特率為2Mbps，采樣點(diǎn)均為80%，都支持標(biāo)準(zhǔn)幀和擴(kuò)展幀格式；

• CAN1需要根據(jù)已提供的CAN通訊矩陣或DBC進(jìn)行開(kāi)發(fā)；

• CAN1需要支持特定幀報(bào)文喚醒，支持局部網(wǎng)絡(luò)喚醒功能等。

當(dāng)然需求細(xì)化分解出來(lái)了很重要，但有沒(méi)有徹底吃透呢？接下來(lái)我們就再進(jìn)一步來(lái)探討。

#02

如何理解CAN通訊需求

就系統(tǒng)工程師的經(jīng)歷來(lái)說(shuō)，當(dāng)看到這些需求，一方面要理解需求本身，另一方面需要知道這些需求將會(huì)涉及的相關(guān)利益方。下面我們就逐一解析上面所列舉的CAN通訊需求。

2.1 ECU需要兩路CAN，CAN1用于ECU之間的信息交互，CAN2用于診斷和標(biāo)定

為什么ECU通常需要兩路CAN或者更多？主要考慮因素有CAN總線(xiàn)的負(fù)載率以及功能需求等。所以O(shè)EM定義一路用作通訊，比如動(dòng)力總成域上掛VCU, MCU, BMS 和OBC等。另一路則用于車(chē)輛的標(biāo)定和診斷通訊功能，其中標(biāo)定功能在量產(chǎn)會(huì)被禁用，這路CAN與OBD接口相連，如下所示：

當(dāng)然也有有些控制器只有1路CAN，既用于通訊也用于診斷標(biāo)定，比如有些電子泵產(chǎn)品。

對(duì)于這條需求，該如何評(píng)估，考慮點(diǎn)有：

• 主要評(píng)估當(dāng)前的控制器硬件是否滿(mǎn)足，即從接插件Pin數(shù)量是否足夠提供兩路CAN_H和CAN_L；

• PCB是否有足夠空間布置兩顆CAN收發(fā)器及其相應(yīng)的處理電路；

• 微控制器芯片中CAN控制器數(shù)量是否足夠。

因此實(shí)現(xiàn)的關(guān)鍵點(diǎn)在于硬件，而對(duì)于軟件來(lái)說(shuō)，主要涉及工作量。

2.2 兩路CAN都為CAN FD，仲裁段波特率500Kbps，數(shù)據(jù)段波特率為2Mbps，采樣點(diǎn)均為80%，都支持標(biāo)準(zhǔn)幀和擴(kuò)展幀格式；

對(duì)于這條需求，考慮因素有兩個(gè)方面：

• 一方面是控制器硬件，即CAN收發(fā)器和MCU的CAN控制器需要支持CAN FD；

• 另一方面是控制器軟件，CAN通訊功能模塊需要支持CAN FD報(bào)文的處理。

另外針對(duì)CAN數(shù)據(jù)幀格式，傳輸速率及采樣，主要涉及軟件開(kāi)發(fā)的內(nèi)容，另外可能需要確保測(cè)試設(shè)備支持CAN FD的測(cè)試驗(yàn)證。

source：CANFD an introduction, from Vector

為了更好地理解這些需求，這里對(duì)這些術(shù)語(yǔ)稍作解釋:

• CAN FD的可變速率。CAN FD采用了兩種位速率：從控制場(chǎng)中的BRS位到ACK場(chǎng)之前（含CRC分界符）稱(chēng)為數(shù)據(jù)段速率，如上圖藍(lán)色部分，其余部分仲裁段速率。兩種速率各有一套位時(shí)間定義寄存器，它們除了采用不同的位時(shí)間單位TQ外，位時(shí)間各段的分配比例也可不同，所以?xún)烧呖梢栽O(shè)置不同的波特率和采樣點(diǎn)。500Kbps表示1秒鐘可以傳輸500,000bit的數(shù)據(jù)，2000Kbps表示1秒鐘可以傳輸2000,000bit的數(shù)據(jù)。

• 標(biāo)準(zhǔn)和擴(kuò)展格式的數(shù)據(jù)幀。兩者的區(qū)別在仲裁段，標(biāo)準(zhǔn)格式的仲裁段包含11位基本ID位和RTR位，而擴(kuò)展格式的仲裁段除了11位基本ID位和RTR位外，還包含SRR位，IDE位和18位擴(kuò)展ID位。即標(biāo)準(zhǔn)格式可表示的CAN ID（11位）范圍為 0X000~0X7FF，而擴(kuò)展格式可表示的CAN ID（29位）范圍為0X00000000~0X1FFFFFFF。如下所示：

source：CAN_E: Data Frame (vector.com)

2.3 CAN1需要根據(jù)已提供的CAN通訊矩陣或DBC進(jìn)行開(kāi)發(fā)

對(duì)于這條需求的理解，可以參考很不錯(cuò)的兩篇文章（寫(xiě)的非常清楚）：

主要工作內(nèi)容在軟件，包括CAN驅(qū)動(dòng)的配置，CAN報(bào)文的收發(fā)，CAN報(bào)文信號(hào)的提取和轉(zhuǎn)換等。對(duì)于CAN通訊矩陣中的信號(hào)不再做詳細(xì)解釋?zhuān)@里了解下報(bào)文中包含保護(hù)或校驗(yàn)信息，比如校驗(yàn)和（Checksum）和滾動(dòng)計(jì)數(shù)器（Rolling Counter）。

• Checksum。它是用來(lái)判斷CAN報(bào)文傳輸過(guò)程是否會(huì)出現(xiàn)錯(cuò)誤，報(bào)文的發(fā)送方采用特定的Checksum校驗(yàn)算法計(jì)算一條報(bào)文的CRC校驗(yàn)碼，再將該校驗(yàn)碼放到該報(bào)文數(shù)據(jù)中，與報(bào)文中的其他信號(hào)一起發(fā)送到CAN總線(xiàn)。然后報(bào)文的接收方會(huì)讀取到該校驗(yàn)碼，同時(shí)采用相同的Checksum校驗(yàn)算法計(jì)算出CRC校驗(yàn)碼，再對(duì)比這兩個(gè)校驗(yàn)碼，如果一致，則說(shuō)明報(bào)文傳輸過(guò)程沒(méi)有出現(xiàn)錯(cuò)誤，否則認(rèn)為報(bào)文傳輸過(guò)程有誤，這條報(bào)文有問(wèn)題。

• Rolling counter。它是用來(lái)判斷報(bào)文傳輸過(guò)程是否出現(xiàn)丟幀，報(bào)文的發(fā)送方發(fā)送一條報(bào)文就計(jì)數(shù)器加1，從0累加到15，然后不斷循環(huán)。如果出現(xiàn)計(jì)數(shù)器不連續(xù)或首尾值不對(duì)，報(bào)文的接收方會(huì)認(rèn)為丟幀。

其實(shí)對(duì)于整個(gè)CAN通訊需求開(kāi)發(fā)內(nèi)容，CAN通訊矩陣涉及內(nèi)容最多，并且貫穿整個(gè)軟件開(kāi)發(fā)的周期。

2.4 CAN1需要支持特定幀報(bào)文喚醒，支持局部網(wǎng)絡(luò)喚醒功能等

對(duì)于這條需求，需求明確要特定幀報(bào)文喚醒功能，即對(duì)控制器硬件設(shè)計(jì)有要求，選用的CAN收發(fā)器芯片要支持特定幀喚醒。其次需求要求支持局部網(wǎng)絡(luò)喚醒功能，因此涉及到復(fù)雜的網(wǎng)絡(luò)管理策略。以底盤(pán)域的網(wǎng)絡(luò)喚醒例子來(lái)理解，如下所示：

Source：

一個(gè)ECU可能存本地喚醒和網(wǎng)絡(luò)喚醒等，比如上圖中假設(shè)IEB的本地喚醒源是制動(dòng)踏板行程傳感器BPS，即某個(gè)喚醒場(chǎng)景下，BPS感知到變化，以硬線(xiàn)信號(hào)形式傳給IEB，那么處于休眠的IEB將被喚醒，對(duì)應(yīng)著圖中1區(qū)域。IEB喚醒后將請(qǐng)求喚醒EPS和VCU參與功能控制，這部分與網(wǎng)絡(luò)喚醒策略相關(guān)。

以上就列舉了一個(gè)典型的網(wǎng)絡(luò)管理場(chǎng)景，要實(shí)現(xiàn)這樣的場(chǎng)景，會(huì)涉及幾個(gè)方面內(nèi)容:

• 喚醒功能邏輯需求，以怎樣的邏輯精準(zhǔn)識(shí)別喚醒源；

• 網(wǎng)絡(luò)管理狀態(tài)機(jī)需求，采用怎么樣形式,AutoSAR NM嗎？以及狀態(tài)之間的跳轉(zhuǎn)條件和每個(gè)狀態(tài)下的動(dòng)作是怎樣定義的；

• 網(wǎng)絡(luò)管理報(bào)文需求。網(wǎng)絡(luò)管理報(bào)文內(nèi)容是怎么定義，接收與發(fā)送的規(guī)則是怎樣的等。

上述這些內(nèi)容喚醒源檢測(cè)會(huì)涉及到硬件設(shè)計(jì)，在硬件具備的情況下，那么開(kāi)發(fā)的內(nèi)容均由軟件來(lái)實(shí)現(xiàn)。關(guān)于網(wǎng)絡(luò)管理需求的實(shí)現(xiàn)，除了單個(gè)ECU自身需求實(shí)現(xiàn)，其實(shí)與其他ECU強(qiáng)相關(guān)，因?yàn)檫@些喚醒場(chǎng)景由這些ECU共同實(shí)現(xiàn)。

#03

CAN通訊需求總結(jié)

上文就從ECU系統(tǒng)視角介紹完了CAN通訊主要需求有哪些，怎么理解這些需求以及這些需求需要誰(shuí)來(lái)實(shí)現(xiàn)。

當(dāng)然還有很多CAN通訊需求本文還未提及展開(kāi)，比如：

• CAN總線(xiàn)Bus off處理需求；

• CAN報(bào)文的診斷需求，比如ID檢測(cè)，超時(shí)檢測(cè)，Checksum校驗(yàn)和故障后處理措施等；

• 功能安全相關(guān)的E2E保護(hù)需求。

總之，CAN通訊其實(shí)是一個(gè)非常大的話(huà)題，內(nèi)容非常多非常復(fù)雜，不管在主機(jī)廠(chǎng)還是供應(yīng)商，不管是ECU系統(tǒng)還是ECU軟硬件，都有很多相關(guān)的工作需要做，很多細(xì)節(jié)需要把控，更多CAN通訊內(nèi)容，歡迎持續(xù)關(guān)注。