從ECU系統視角理解CAN通訊需求

作者| 糊涂振

出品| 汽車電子與軟件

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

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

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

#01

CAN通訊需求的分析與分解

汽車ECU基本都采用V流程開發，先由OEM提供功能開發需求，然后經過ECU系統的分析與評估，再分配給ECU軟硬件進行相應的開發與驗證，最后由系統進行驗證和確認。

Source:

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

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

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

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

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

接著系統工程師將在ECU系統層面將需求細化為ECU系統需求，比如:

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

• 兩路CAN都為CAN FD，仲裁段波特率500Kbps，數據段波特率為2Mbps，采樣點均為80%，都支持標準幀和擴展幀格式；

• CAN1需要根據已提供的CAN通訊矩陣或DBC進行開發；

• CAN1需要支持特定幀報文喚醒，支持局部網絡喚醒功能等。

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

#02

如何理解CAN通訊需求

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

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

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

當然也有有些控制器只有1路CAN，既用于通訊也用于診斷標定，比如有些電子泵產品。

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

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

• PCB是否有足夠空間布置兩顆CAN收發器及其相應的處理電路；

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

因此實現的關鍵點在于硬件，而對于軟件來說，主要涉及工作量。

2.2 兩路CAN都為CAN FD，仲裁段波特率500Kbps，數據段波特率為2Mbps，采樣點均為80%，都支持標準幀和擴展幀格式；

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

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

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

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

source：CANFD an introduction, from Vector

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

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

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

source：CAN_E: Data Frame (vector.com)

2.3 CAN1需要根據已提供的CAN通訊矩陣或DBC進行開發

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

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

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

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

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

2.4 CAN1需要支持特定幀報文喚醒，支持局部網絡喚醒功能等

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

Source：

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

以上就列舉了一個典型的網絡管理場景，要實現這樣的場景，會涉及幾個方面內容:

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

• 網絡管理狀態機需求，采用怎么樣形式,AutoSAR NM嗎？以及狀態之間的跳轉條件和每個狀態下的動作是怎樣定義的；

• 網絡管理報文需求。網絡管理報文內容是怎么定義，接收與發送的規則是怎樣的等。

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

#03

CAN通訊需求總結

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

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

• CAN總線Bus off處理需求；

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

• 功能安全相關的E2E保護需求。

總之，CAN通訊其實是一個非常大的話題，內容非常多非常復雜，不管在主機廠還是供應商，不管是ECU系統還是ECU軟硬件，都有很多相關的工作需要做，很多細節需要把控，更多CAN通訊內容，歡迎持續關注。