在軟件定義汽車這個時代，汽車功能越來越豐富，隨之ECU越來越多，有些功能靠ECU獨立實現(xiàn)，有些功能則需要多個ECU聯(lián)合實現(xiàn)。總體來說，ECU絕大多數(shù)情況下都需要與其他ECU進行信息交互，比如充電功能，車載充電機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
當然不管汽車電子電器架構(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軟硬件進行相應(yīng)的開發(fā)與驗證，最后由系統(tǒng)進行驗證和確認。
Source: 一文了解汽車功能開發(fā)要做什么？怎么做？
本文將側(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)層面將需求細化為ECU系統(tǒng)需求，比如:
- ECU需要兩路CAN，CAN1用于ECU之間的信息交互，CAN2用于診斷和標定；
- 兩路CAN都為CAN FD，仲裁段波特率500Kbps，數(shù)據(jù)段波特率為2Mbps，采樣點均為80%，都支持標準幀和擴展幀格式；
- CAN1需要根據(jù)已提供的CAN通訊矩陣或DBC進行開發(fā)；
- CAN1需要支持特定幀報文喚醒，支持局部網(wǎng)絡(luò)喚醒功能等。
當然需求細化分解出來了很重要，但有沒有徹底吃透呢？接下來我們就再進一步來探討。
#02 如何理解CAN通訊需求
就系統(tǒng)工程師的經(jīng)歷來說，當看到這些需求，一方面要理解需求本身，另一方面需要知道這些需求將會涉及的相關(guān)利益方。下面我們就逐一解析上面所列舉的CAN通訊需求。
2.1 ECU需要兩路CAN，CAN1用于ECU之間的信息交互，CAN2用于診斷和標定
為什么ECU通常需要兩路CAN或者更多？主要考慮因素有CAN總線的負載率以及功能需求等。所以O(shè)EM定義一路用作通訊，比如動力總成域上掛VCU, MCU, BMS 和OBC等。另一路則用于車輛的標定和診斷通訊功能，其中標定功能在量產(chǎn)會被禁用，這路CAN與OBD接口相連，如下所示：
當然也有有些控制器只有1路CAN，既用于通訊也用于診斷標定，比如有些電子泵產(chǎn)品。
對于這條需求，該如何評估，考慮點有：
- 主要評估當前的控制器硬件是否滿足，即從接插件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%，都支持標準幀和擴展幀格式；
對于這條需求，考慮因素有兩個方面：
- 一方面是控制器硬件，即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ù)段速率，如上圖藍色部分，其余部分仲裁段速率。兩種速率各有一套位時間定義寄存器，它們除了采用不同的位時間單位TQ外，位時間各段的分配比例也可不同，所以兩者可以設(shè)置不同的波特率和采樣點。500Kbps表示1秒鐘可以傳輸500,000bit的數(shù)據(jù)，2000Kbps表示1秒鐘可以傳輸2000,000bit的數(shù)據(jù)。
- 標準和擴展格式的數(shù)據(jù)幀。兩者的區(qū)別在仲裁段，標準格式的仲裁段包含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需要根據(jù)已提供的CAN通訊矩陣或DBC進行開發(fā)
主要工作內(nèi)容在軟件，包括CAN驅(qū)動的配置，CAN報文的收發(fā)，CAN報文信號的提取和轉(zhuǎn)換等。對于CAN通訊矩陣中的信號不再做詳細解釋，這里了解下報文中包含保護或校驗信息，比如校驗和（Checksum）和滾動計數(shù)器（Rolling Counter）。
- Checksum。它是用來判斷CAN報文傳輸過程是否會出現(xiàn)錯誤，報文的發(fā)送方采用特定的Checksum校驗算法計算一條報文的CRC校驗碼，再將該校驗碼放到該報文數(shù)據(jù)中，與報文中的其他信號一起發(fā)送到CAN總線。然后報文的接收方會讀取到該校驗碼，同時采用相同的Checksum校驗算法計算出CRC校驗碼，再對比這兩個校驗碼，如果一致，則說明報文傳輸過程沒有出現(xiàn)錯誤，否則認為報文傳輸過程有誤，這條報文有問題。
- Rolling counter。它是用來判斷報文傳輸過程是否出現(xiàn)丟幀，報文的發(fā)送方發(fā)送一條報文就計數(shù)器加1，從0累加到15，然后不斷循環(huán)。如果出現(xiàn)計數(shù)器不連續(xù)或首尾值不對，報文的接收方會認為丟幀。
其實對于整個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：一篇易懂的整車網(wǎng)絡(luò)管理指南
一個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)容:
- 喚醒功能邏輯需求，以怎樣的邏輯精準識別喚醒源；
- 網(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é)
當然還有很多CAN通訊需求本文還未提及展開，比如：
- CAN總線Bus off處理需求；
- CAN報文的診斷需求，比如ID檢測，超時檢測，Checksum校驗和故障后處理措施等；
- 功能安全相關(guān)的E2E保護需求。
總之，CAN通訊其實是一個非常大的話題，內(nèi)容非常多非常復(fù)雜，不管在主機廠還是供應(yīng)商，不管是ECU系統(tǒng)還是ECU軟硬件，都有很多相關(guān)的工作需要做，很多細節(jié)需要把控，更多CAN通訊內(nèi)容，歡迎持續(xù)關(guān)注。
轉(zhuǎn)自汽車電子與軟件
