在軟件定義汽車這個時代，汽車功能越來越豐富(fu)，隨之ECU越來越多，有些功能靠ECU獨立實現，有些功能則需要多個ECU聯合實現。總體來說，ECU絕大多數情況下都需要與其他ECU進行信息(xi)交互，比如充電功能，車載充電機OBC需要聯合電池管理係統BMS和整車控製器VCU等聯合才能實現。因此，這些ECU采取(qu)怎樣的通訊方式來實現信息(xi)交互？目前，常用的ECU通訊方式有 CAN，LIN和FlexRay，同時隨著汽車電子電器架(jia)構朝著中央集成控製方向(xiang)發展，以太網的應用也越來越廣泛。
source：the software Car: Building ICT Architectures for Future Electric Vehicles
當然不管汽車電子電器架(jia)構發展多麼迅(xun)速，CAN通訊仍將無處不在，持續對ECU之間的信息(xi)交互扮演(yan)著極其關鍵的角色。因此，本文從ECU係統層級角度(du)來探討CAN通訊都會有怎樣的需求，以及如何去理解與評估這些需求。
#01 CAN通訊需求的分析與分解
汽車ECU基本都采用V流程開發，先由OEM提供(gong)功能開發需求，然後經過ECU係統的分析與評估，再分配給ECU軟硬件進行相應的開發與驗證，最後由係統進行驗證和確(que)認。
Source: 一文了解汽車功能開發要做什麼？怎麼做？
本文將側(ce)重點在ECU係統層麵視角來看這些CAN通訊需求。通常ECU係統收到在客戶關於CAN通訊的需求會涉(she)及以下幾(ji)個點:
- ECU需要具(ju)備幾(ji)路CAN，每路CAN的基本要求是什麼；
- 每條CAN需要具(ju)備哪些功能；
- CAN通訊矩陣或DBC是怎樣的。
這些需求就是ECU CAN通訊開發的起點，一般稱為客戶需求或者利(li)益(yi)相關者需求Stakeholder requirement。在ECU係統層麵，係統工(gong)程師(shi)收到這些需求後，會拉(la)上相關利(li)益(yi)者一起來評估這些需求，包括硬件，軟件和功能安全等項(xiang)目內部成員，同時也會和客戶多次對齊，最終(zhong)明(ming)確(que)好(hao)這些CAN通訊需求。
接著係統工(gong)程師(shi)將在ECU係統層麵將需求細(xi)化為ECU係統需求，比如:
- ECU需要兩路CAN，CAN1用於ECU之間的信息(xi)交互，CAN2用於診(zhen)斷和標定；
- 兩路CAN都為CAN FD，仲(zhong)裁段波特率500Kbps，數據段波特率為2Mbps，采樣點均為80%，都支持標準幀和擴展幀格式；
- CAN1需要根據已提供(gong)的CAN通訊矩陣或DBC進行開發；
- CAN1需要支持特定幀報文喚醒，支持局部網絡喚醒功能等。
當然需求細(xi)化分解出來了很重要，但有沒有徹底吃透呢？接下來我們就再進一步來探討。
#02 如何理解CAN通訊需求
就係統工(gong)程師(shi)的經曆來說，當看到這些需求，一方麵要理解需求本身，另一方麵需要知道(dao)這些需求將會涉(she)及的相關利(li)益(yi)方。下麵我們就逐一解析上麵所列舉的CAN通訊需求。
2.1 ECU需要兩路CAN，CAN1用於ECU之間的信息(xi)交互，CAN2用於診(zhen)斷和標定
為什麼ECU通常需要兩路CAN或者更多？主要考慮因素(su)有CAN總線的負(fu)載率以及功能需求等。所以OEM定義一路用作通訊，比如動力總成域上掛(gua)VCU, MCU, BMS 和OBC等。另一路則用於車輛的標定和診(zhen)斷通訊功能，其中標定功能在量產會被禁(jin)用，這路CAN與OBD接口相連，如下所示：
當然也有有些控製器隻有1路CAN，既用於通訊也用於診(zhen)斷標定，比如有些電子泵(beng)產品。
對於這條需求，該如何評估，考慮點有：
- 主要評估當前的控製器硬件是否(fu)滿足(zu)，即從接插件Pin數量是否(fu)足(zu)夠提供(gong)兩路CAN_H和CAN_L；
- PCB是否(fu)有足(zu)夠空間布置兩顆(ke)CAN收發器及其相應的處理電路；
- 微控製器芯片中CAN控製器數量是否(fu)足(zu)夠。
因此實現的關鍵點在於硬件，而對於軟件來說，主要涉(she)及工(gong)作量。
2.2 兩路CAN都為CAN FD，仲(zhong)裁段波特率500Kbps，數據段波特率為2Mbps，采樣點均為80%，都支持標準幀和擴展幀格式；
對於這條需求，考慮因素(su)有兩個方麵：
- 一方麵是控製器硬件，即CAN收發器和MCU的CAN控製器需要支持CAN FD；
- 另一方麵是控製器軟件，CAN通訊功能模塊需要支持CAN FD報文的處理。
- 另外針對CAN數據幀格式，傳輸(shu)速率及采樣，主要涉(she)及軟件開發的內容，另外可能需要確(que)保測試設備支持CAN FD的測試驗證。
source：CANFD an introduction, from Vector
為了更好(hao)地理解這些需求，這裏對這些術語稍(shao)作解釋:
- CAN FD的可變速率。CAN FD采用了兩種位速率：從控製場中的BRS位到ACK場之前（含CRC分界符）稱為數據段速率，如上圖藍色部分，其餘(yu)部分仲(zhong)裁段速率。兩種速率各有一套(tao)位時間定義寄存器，它們除了采用不同的位時間單位TQ外，位時間各段的分配比例也可不同，所以兩者可以設置不同的波特率和采樣點。500Kbps表示1秒鍾(zhong)可以傳輸(shu)500,000bit的數據，2000Kbps表示1秒鍾(zhong)可以傳輸(shu)2000,000bit的數據。
- 標準和擴展格式的數據幀。兩者的區別(bie)在仲(zhong)裁段，標準格式的仲(zhong)裁段包含11位基本ID位和RTR位，而擴展格式的仲(zhong)裁段除了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需要根據已提供(gong)的CAN通訊矩陣或DBC進行開發
主要工(gong)作內容在軟件，包括CAN驅動的配置，CAN報文的收發，CAN報文信號的提取(qu)和轉換(huan)等。對於CAN通訊矩陣中的信號不再做詳(xiang)細(xi)解釋，這裏了解下報文中包含保護或校驗信息(xi)，比如校驗和（Checksum）和滾(gun)動計數器（Rolling Counter）。
- Checksum。它是用來判斷CAN報文傳輸(shu)過程是否(fu)會出現錯(cuo)誤，報文的發送(song)方采用特定的Checksum校驗算(suan)法(fa)計算(suan)一條報文的CRC校驗碼，再將該校驗碼放到該報文數據中，與報文中的其他信號一起發送(song)到CAN總線。然後報文的接收方會讀(du)取(qu)到該校驗碼，同時采用相同的Checksum校驗算(suan)法(fa)計算(suan)出CRC校驗碼，再對比這兩個校驗碼，如果一致，則說明(ming)報文傳輸(shu)過程沒有出現錯(cuo)誤，否(fu)則認為報文傳輸(shu)過程有誤，這條報文有問題。
- Rolling counter。它是用來判斷報文傳輸(shu)過程是否(fu)出現丟幀，報文的發送(song)方發送(song)一條報文就計數器加1，從0累加到15，然後不斷循環(huan)。如果出現計數器不連續或首尾值不對，報文的接收方會認為丟幀。
其實對於整個CAN通訊需求開發內容，CAN通訊矩陣涉(she)及內容最多，並且(qie)貫穿(chuan)整個軟件開發的周期。
2.4 CAN1需要支持特定幀報文喚醒，支持局部網絡喚醒功能等
對於這條需求，需求明(ming)確(que)要特定幀報文喚醒功能，即對控製器硬件設計有要求，選用的CAN收發器芯片要支持特定幀喚醒。其次需求要求支持局部網絡喚醒功能，因此涉(she)及到複雜(za)的網絡管理策略。以底盤(pan)域的網絡喚醒例子來理解，如下所示：
Source：一篇易懂的整車網絡管理指(zhi)南
一個ECU可能存本地喚醒和網絡喚醒等，比如上圖中假設IEB的本地喚醒源是製動踏板(ban)行程傳感器BPS，即某個喚醒場景(jing)下，BPS感知到變化，以硬線信號形(xing)式傳給IEB，那麼處於休(xiu)眠的IEB將被喚醒，對應著圖中1區域。IEB喚醒後將請求喚醒EPS和VCU參與功能控製，這部分與網絡喚醒策略相關。
以上就列舉了一個典型的網絡管理場景(jing)，要實現這樣的場景(jing)，會涉(she)及幾(ji)個方麵內容:
- 喚醒功能邏輯(ji)需求，以怎樣的邏輯(ji)精準識別(bie)喚醒源；
- 網絡管理狀(zhuang)態機需求，采用怎麼樣形(xing)式,AutoSAR NM嗎？以及狀(zhuang)態之間的跳(tiao)轉條件和每個狀(zhuang)態下的動作是怎樣定義的；
- 網絡管理報文需求。網絡管理報文內容是怎麼定義，接收與發送(song)的規則是怎樣的等。
上述這些內容喚醒源檢測會涉(she)及到硬件設計，在硬件具(ju)備的情況下，那麼開發的內容均由軟件來實現。關於網絡管理需求的實現，除了單個ECU自身需求實現，其實與其他ECU強相關，因為這些喚醒場景(jing)由這些ECU共同實現。
#03 CAN通訊需求總結(jie)
當然還有很多CAN通訊需求本文還未(wei)提及展開，比如：
- CAN總線Bus off處理需求；
- CAN報文的診(zhen)斷需求，比如ID檢測，超時檢測，Checksum校驗和故障後處理措施等；
- 功能安全相關的E2E保護需求。
總之，CAN通訊其實是一個非常大的話題，內容非常多非常複雜(za)，不管在主機廠(chang)還是供(gong)應商(shang)，不管是ECU係統還是ECU軟硬件，都有很多相關的工(gong)作需要做，很多細(xi)節需要把(ba)控，更多CAN通訊內容，歡迎(ying)持續關注。
轉自汽車電子與軟件
