本文為臭皮匠試驗室觀點。轉載請請註明出處。
之前在文章《電動汽車動力總成解讀︱模擬世界與數字世界》中提到的，我們所處的世界，是一個由用無限多種顏色、無數種音調，無數種氣味繪製而成的世界，所有的這些元素都可以理解成一個模擬訊號，他們是構建這個世界的元素。而CAN匯流排技術（Controller Area Network），類似於我們的神經系統，遍佈於我們身體的各個部分，透過某種規則，與身體的各個節點之間互動，接收和傳送資訊，從而感受世界、改造世界。今天我們就來聊聊上80年代由BOSCH公司開發的CAN匯流排技術。
▼
文章結構如下：
1。 什麼是CAN匯流排技術？
2。 為什麼需要CAN匯流排？
3。 為什麼是CAN匯流排被廣泛應用？
4。 CAN匯流排報文是如何傳輸的？（傳輸方式）
4。1 CAN報文/訊號/物理量
4。2 模擬訊號與數字訊號
4。3 CAN匯流排物理結構
4。4 傳輸方式
5。 CAN協議幀結構
6。 OSI網路結構與AUTOSAR架構
6。1 OSI網路結構
6。2 AUTOSAR架構
7。 CAN報文的傳送、確認和接收
7。1 報文的傳送、確認
7。2 報文的接收
1。 什麼是CAN匯流排技術？
CAN，即Controller Area Network，二十世紀八十年代由BOSCH公司為解決現代汽車中眾多ECU之間的資料交換而開發的一種單工穿行通訊協議。
可以將CAN匯流排理解成我們的神經系統，它遍佈於我們身體的各個部分，透過某種規則，與身體的各個節點之間互動，傳送或接收訊息。
也可以將其理解成電話會議，一旦某一節點有傳送請求，該資訊將輸入網路，其他節點共同接收，接收節點判斷是否使用該資訊。
備註： 單工 ， 指 同一時間，只能有一個ECU單元向匯流排傳送資料，而其他ECU只能做為接收節點。
2。 為什麼需要CAN匯流排？
正如之前在文章《電動汽車動力總成解讀︱模擬世界與數字世界》中提到的，我們所處的世界，是一個由用無限多種顏色、無數種音調，無數種氣味繪製而成的世界，所有的這些元素都可以理解成一個模擬訊號，他們是構建這個世界的元素。
而人類，作為高階動物，正式透過相互交流、合作，對這個世界進行了改造。將這一概念放到汽車上：人類透過文字、聲音、影象來交流，為了提升交流效率，誕生了“網路”技術；汽車不同部件之間則透過線束來實現，同樣，為了提升資訊交換的效率、簡化系統，誕生了“匯流排”技術。
3。 為什麼是CAN匯流排被廣泛應用？
早期的網路結構有很多，為什麼CAN匯流排技術得以推廣應用，主要以下幾點原因：
低成本
中央整合控制
魯棒性高
高效（仲裁機制）
靈活性高
4。 CAN匯流排報文是如何傳輸的？（傳輸方式）
4。1 CAN報文/訊號/物理量
介紹之前先對CAN報文/訊號/物理量的概念做下區分，三句話概括：
任何報文都可以在匯流排的節點之間傳遞
任何報文的資料位元組都可以分解成訊號
訊號可以用物理量形式表示
4。2 模擬訊號與數字訊號
之前我們介紹過模擬訊號與數字訊號，詳見文字《電動汽車動力總成解讀︱模擬世界與數字世界》。
我們所處的世界，是一個由用無限多種顏色、無數種音調，無數種氣味繪製而成的世界，所有的這些元素都可以理解成一個模擬訊號，他們是構建這個世界的元素。ECU之間透過CAN匯流排的通訊過程，與人類透過音訊、影片的過程是一樣的，即數字量與模擬量之間的轉換。
4。3 CAN匯流排物理結構
如下圖所示為CAN匯流排物理結構，基本形式為： CAN_H + CAN_L + 各個節點（Nodes）。
其中，
CAN_H/CAN_L：以雙絞形式纏繞；
節點：CAN收發器（Transceiver） + CAN控制器（Controller），控制器的 Tx 傳送端腳、Rx 接收端腳，而收發器直接連線在雙絞線上。
CAN總線上的訊號，即為電壓形式表現的差分訊號，由 CAN_H和CAN_L兩根訊號線組成，分為顯性電平（dominant）和隱性電平（recessive）兩種型別。其中顯性電平規定為邏輯0，隱性電平則為邏輯1，如下圖所示。
4。4 傳輸方式
當CPU需要傳送資料時候，CAN Controller給Transceiver傳送需求的資料，CAN Transceiver將其傳送給CAN 匯流排，透過CAN_H和CAN_L兩根線實現整車各ECU節點之間的串聯，接收資料類似過程。
綜上，整車ECU各節點之間CAN匯流排的通訊方式，簡單理解如下：
傳送 ：Transceiver 將上層傳遞的資料進解析成電壓訊號 （根據ISO 11898/ISO11519定義），並傳遞至BUS。
接收 ： Transceiver 將BUS訊號轉變為二進位制訊號給CAN Controller；CPU將CAN Controller傳送的資料進行解析、提取，經過相應運算，控制感測器和執行器。
瞭解了CAN總線上報文的傳遞方式和邏輯電平序列的應用，那麼這些邏輯電平序列要如何使用呢？
5。 CAN協議幀結構
為了說明上述邏輯電平序列的使用方式，需要了解CAN協議幀的結構。
CAN協議標準裡對這些邏輯點評序列做了定義，使這些資料欄位有了靈魂，標準中對CAN協議幀的定義有以下4種類型：
資料幀：用於傳送單元向接收單元傳輸資料的幀
遙控幀：用於接收單元向具有相同ID的傳送單元請求資料的幀
錯誤幀：用具當檢測出錯誤時，向其他單元通知錯誤的幀
過載幀：用於接收單元通知其尚未做好接收準備的幀
簡單來講，正式透過上述對報文訊號協議幀的規範，使我們ECU之間的通訊定位準確、邏輯清楚、資訊完善、響應及時、魯棒性高，限於篇幅，具體幀結構的展開形式和應用方法本文不做詳細介紹，感興趣的可以自行搜尋，如有時間我也會再做總結。
通訊邏輯和方法已大致瞭解，那麼具體要怎麼實現CAN通訊功能呢？
6。 OSI網路結構與AUTOSAR架構
為了滿足軟體的可以執行、可擴充套件性和安全效能等，我們引入基於OSI網路結構的AUTOSAR架構，如下圖所示。
6。1 OSI網路結構
OSI網路結構定義如下，其核心目的時為了將協議、服務和介面明確區分，解決異種節點互聯時的相容性問題。
對於車規級CAN網路通訊，只對 物理層、資料鏈路層、應用層 做了邏輯上定義，其他暫無需關注。
物理層： 利用傳輸介質對資料鏈路層提供物理連線，負責資料流的物理傳輸，傳輸單位是0和1。
資料鏈路層： 在通訊實體間建立資料鏈路聯接，傳輸的基本單位為“幀”，可分為兩部分MAC（介質訪問控制子層） + LLC（邏輯鏈路控制子層）。
其中，MAC——規定如何在物理線路上傳輸幀，LLC——對在同一條網路鏈路上的裝置之間的通訊進行管理。
應用層：實現對物理層資料層資料的解析，即VCU透過哪些ID通訊，報文長度，資料所代表的訊號，訊號含義等。
6。2 AUTOSAR架構
下圖為基於OSI網路結構的AUTOSAR架構中的通訊站。可以看出，HW訪問只有透過Driver實現，CAN If模組與其對接，同時，CAN If統一管理與service層的通訊，透過PduR路由到更多上層模組，減少了介面。
7。 CAN報文的傳送、確認和接收
7。1 報文的傳送、確認
簡單來講，報文傳送的過程，即使用者向服務提供者發出請求（request），然後提供者向用戶確認請求結果（confirm）的過程，如下圖所示：
詳細說明下這一過程：
Step1。 BSW透過Com_SendSignal週期性排程Com模組中的Com_MainFunctionTx函式，Com模組從快取中讀取需要傳送的資料；
Step2。 Com模組的Com_MainFunction_Tx函式將呼叫PduR模組的PduR_ComTransmit函式，將資料傳遞給PduR
Step3。 PduR模組路由到下層模組，呼叫CanIf模組的CanIf_Transmit函式，資料被傳遞至下層CanIf
Step4。 CanIf模組呼叫Can Driver模組Can_Write函式
Step5。 Can_Write函式將訪問仲裁、資料長度和資料暫存器，透過Can Driver訪問Can HW，將資料寫入相應暫存器（透過數資料協議單元PDU）
Step6。 以POLLING作為CAN 傳送的處理方式（三種，詳見標準），BSW Scheduler週期性排程Can Driver模組的Can_MainFunction_Write函式
Step7。 Can Driver 透過Can_MainFunction_Write函式訪問Can HW中相關暫存器，讀取資料供上層確認
Step8。 讀取後，呼叫CanIf的CanIf_TxComfirmation函式，將資料上傳至CanIf
Step9。 CanIf呼叫PduR模組的PduR_TxConfirmation函式，將資料傳到PduR模組
Step 10。 PduR模組路由到Com模組，呼叫Com_TxConfirmation函式，確認傳送狀態。
其中1~5為傳送階段，6~10為確認階段，其中具體的函式呼叫規則和定義可參見《AUTOSAR- Specification of CAN Interface》。
7。2 報文的接收
報文接收的過程，即服務提供者通知所服務使用者的過程（indication），過程與上述確認過程類似，這裡不做贅述。
以上就是關於CAN匯流排技術的基本內容，實際應用中會涉及很多細節，標準中對應章節有規範，對某一方面感興趣或者有疑問的讀者可以後臺留言，歡迎交流。