作者| 糊涂振

出品| 汽車電子與軟件

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

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

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

#01

CAN通訊需求的分析與分解

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

Source:

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

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

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

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

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

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

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

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

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

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

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

#02

如何理解CAN通訊需求

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

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

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

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

對于這條需求，該如何評估，考慮點有：

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

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

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

因此實現(xiàn)的關(guān)鍵點在于硬件，而對于軟件來說，主要涉及工作量。

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

對于這條需求，考慮因素有兩個方面：

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

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

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

source：CANFD an introduction, from Vector

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

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

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

source：CAN_E: Data Frame (vector.com)

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

對于這條需求的理解，可以參考很不錯的兩篇文章（寫的非常清楚）：

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

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

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

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

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

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

Source：

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

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

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

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

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

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

#03

CAN通訊需求總結(jié)

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

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

• CAN總線Bus off處理需求；

• CAN報文的診斷需求，比如ID檢測，超時檢測，Checksum校驗和故障后處理措施等；

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

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