1、信號角度

從信號角度，主要想再說明下：信號在CAN總線上是電壓形式，在軟件中是二進制數，這是怎么轉換的？信號在軟件中是如何變化的？

1.1 數模轉換

通過本系列前面文章，我們知道ECU之間通過CAN總線通訊。從信號轉換角度：模擬信號到數字信號，比如接收，如圖1所示。

其具體過程為：在CAN總線上，信號表現為電壓形式，其具體值根據ISO11898和ISO11519標準的定義而來。然后電壓信號經過CAN收發器轉換成數字信號，即邏輯電平0和1。

接著這些邏輯電平序列將被ECU硬件單元處理，丟棄或存入寄存器。反之，發送過程其實就是一個數字信號到模擬信號的轉換過程。

圖1 CAN總線到ECU的信號轉換

這里若需掌握各個環節的細節：

關于CAN總線特性，可通過ISO11898，ISO11519系列標準研究總線的電器和物理特性。

關于信號轉換實現，可研究CAN收發器的原理與特性等。

關于寄存器存儲，可細讀相應的芯片手冊，并動手去配置芯片和調試代碼。

1.2 信號變化

上述的邏輯電平序列有什么規律？有什么作用？通過前面文章我們知道CAN協議標準定義了這些邏輯電平序列，使這些數據有了實際意義，其實就是一些數據幀，遙控幀等的信息。

通過配置CAN硬件單元，比如利用IDE的數據就可以決定ECU是否接收某個CanId的數據，進而再準確將接收的相應數據存入相應的寄存器，比如IDE存入IDE相關的寄存器，DLC存入長度相關的寄存器。

當軟件通過硬件接口訪問相應的寄存器，就可以讀取到對應的數據，比如長度，數據等信息。這樣軟件按照OSI參考模型的架構將這些讀取的數據以協議數據單元（PDU）格式逐層向上傳輸，直到將PDU解包成報文通訊協議規定的信號形式，整個過程如下圖2所示。



圖2 CAN通訊的信號變化過程 這里若研究各個環節的實現：

關于CAN幀定義，可細讀CAN協議和ISO11898-1標準。

關于寄存器的存儲與提取，可研究相應的芯片手冊。

關于CAN通訊架構，可參考OSI參考模型，ISO17356和AUTOSAR文檔等。

2、軟硬件角度

從軟硬件角度，要實現怎么樣CAN通訊功能，就決定了要用怎樣的硬件和軟件。那么從軟件工程師角度，是怎么看硬件？又是怎么看軟件的？

2.1 硬件

從軟件工程師角度，主要是根據芯片手冊，ECU原理圖和其他驅動的用戶手冊來助于對軟件的理解，比如了解CAN的硬件連接，即從總線連接到哪個PIN，PIN連接到什么收發器，收發器連接到芯片的哪些引腳。或者了解提取寄存器數據，要對芯片進行的哪些配置，怎么配置等。或者更深入地就是硬件特性變化會對軟件產生怎樣的影響等等。

2.2 軟件

從前面文章我們知道，先明確了一個清晰的軟件架構，如下圖3的中間部分，再從控制流和數據流考慮。若采用一個極其簡單的架構，如圖3最左側部分，從寄存器提取完數據，直接給應用層去解析。

但這樣的架構顯然滿足不了軟件的安全性，可移植性，可重用性和可擴展性等要求，所以為了滿足這些要求，會采用基于OSI參考模型的AUTOSAR架構，如圖3最右側部分，只允許CAN Driver 訪問硬件，向上只對接CAN Interface，與上層的模塊通訊均由CAN Interface統一管理，通過PduR路由到更多的上層模塊，減少接口等等。

當然前面文章出于內容更易懂且精煉的考慮，采用了圖3中間部分的基于OSI參考模型的AUTOSAR架構的簡約版。

圖3 CAN通訊的軟件架構，引自[1]

這個軟件架構的CAN通訊控制流如下圖4所示。前面文章已經大體上介紹了CAN發送與接收的控制過程，比如不同模塊如何進行數據傳輸，同一模塊中數據傳輸所需具備的條件。另外也介紹了這些過程所涉及的接收通知，發送，發送確認的相關函數與動作。抽象地講就是實現一個功能需先要以一定的時序組織不同的模塊，然后各個模塊要滿足各自一定的條件才去采取執行某些活動，最后考慮這些活動如何具體地一步一步實施。

圖4

當然通過控制流不難發現，數據流也極其重要。基于OSI參考模型，協議數據單元（PDU）在不同的層會有不同的名字，比如數據鏈路層的PDU叫L-PDU，網絡層的PDU叫N-PDU，交互層的PDU叫I-PDU。我們根據這些PDU和其他信息的映射關系，鏈接關系，就可構建起整個CAN通訊功能的數據流，類似于圖5。

這樣使得我們能更好理解AUTOSAR配置工具，比如VECTOR或EB工具配置內容的設置和鏈接關系；也能更深入AUTOSAR的CAN通訊實現原理與方法，比如硬件的訪問機制，從L-PDU到N-PDU到I-PDU的映射邏輯等。

圖5 PDU的傳輸，引自[1]

這里若想研究軟件的各個模塊，可根據ISO11898-1， ISO17356-4和相關AUTOSAR文檔。

3、功能視角

功能需求決定了硬件和軟件，所以先看軟件實現了怎么樣的功能，然后再看軟件具體是怎樣實現的。正如目前文章介紹的只是最常見的CAN通訊發送與接收功能，沒有考慮通訊錯誤的情況，也沒有考慮總線關閉的情況。為了完善CAN通訊基本功能，也為了強化CAN通訊功能，下面將大概列舉出來，也算是預告下后面文章的內容。

對于CAN通訊錯誤的情況，CAN協議標準定義了一套完成的錯誤處理機制。比如： 針對總線信號有定義錯誤幀，下圖6所示。



圖6 錯誤幀定義，引自[2]

針對總線通訊單元有定義主動錯誤，被動錯誤和總線關閉狀態，如圖7所示。




圖7 單元的錯誤狀態，引自[2]

針對CAN通訊網絡有定義無通訊模式，靜默模式，完全通訊模式，如圖8所示。




圖8 CanSM狀態機，引自[3]

對于CAN數據幀數據長度不夠的情況，有提出一種更靈活的CAN數據幀，即CANFD。




圖9 CANFD概念，引自[4]

對于CAN通訊網絡能被喚醒的情況，如下圖10所示。



圖10 具備喚醒的CAN網絡示意，引自[5]

就先列出這些典型的CAN通訊功能，通過這些新功能不難發現：為了應對日益增加的功能需求，不管是針對個人還是企業，硬件還是軟件，其實都需要不斷地進行更新和強化。

到此我們就從3個視角既回顧了CAN通訊的基本發送與接收功能，也提出了CAN通訊的新功能，為了讓大家更加全面且系統地了解CAN通訊功能，后面文章將在CAN發送與接收的主樹干上繼續生枝發葉。

審核編輯：劉清