1、信號角度

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

1.1 數(shù)模轉(zhuǎn)換

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

其具體過程為：在CAN總線上，信號表現(xiàn)為電壓形式，其具體值根據(jù)ISO11898和ISO11519標準的定義而來。然后電壓信號經(jīng)過CAN收發(fā)器轉(zhuǎn)換成數(shù)字信號，即邏輯電平0和1。

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

圖1 CAN總線到ECU的信號轉(zhuǎn)換

這里若需掌握各個環(huán)節(jié)的細節(jié)：

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

關(guān)于信號轉(zhuǎn)換實現(xiàn)，可研究CAN收發(fā)器的原理與特性等。

關(guān)于寄存器存儲，可細讀相應(yīng)的芯片手冊，并動手去配置芯片和調(diào)試代碼。

1.2 信號變化

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

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

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



圖2 CAN通訊的信號變化過程 這里若研究各個環(huán)節(jié)的實現(xiàn)：

關(guān)于CAN幀定義，可細讀CAN協(xié)議和ISO11898-1標準。

關(guān)于寄存器的存儲與提取，可研究相應(yīng)的芯片手冊。

關(guān)于CAN通訊架構(gòu)，可參考OSI參考模型，ISO17356和AUTOSAR文檔等。

2、軟硬件角度

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

2.1 硬件

從軟件工程師角度，主要是根據(jù)芯片手冊，ECU原理圖和其他驅(qū)動的用戶手冊來助于對軟件的理解，比如了解CAN的硬件連接，即從總線連接到哪個PIN，PIN連接到什么收發(fā)器，收發(fā)器連接到芯片的哪些引腳?；蛘吡私馓崛〖拇嫫鲾?shù)據(jù)，要對芯片進行的哪些配置，怎么配置等?；蛘吒钊氲鼐褪怯布匦宰兓瘯浖a(chǎn)生怎樣的影響等等。

2.2 軟件

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

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

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

圖3 CAN通訊的軟件架構(gòu)，引自[1]

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

圖4

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

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

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

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

3、功能視角

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

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



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

針對總線通訊單元有定義主動錯誤，被動錯誤和總線關(guān)閉狀態(tài)，如圖7所示。




圖7 單元的錯誤狀態(tài)，引自[2]

針對CAN通訊網(wǎng)絡(luò)有定義無通訊模式，靜默模式，完全通訊模式，如圖8所示。




圖8 CanSM狀態(tài)機，引自[3]

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




圖9 CANFD概念，引自[4]

對于CAN通訊網(wǎng)絡(luò)能被喚醒的情況，如下圖10所示。



圖10 具備喚醒的CAN網(wǎng)絡(luò)示意，引自[5]

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

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

審核編輯：劉清