商用車CAN總線多幀數據通訊

藺春明，王守勝，高美芹，俞燚

（安徽江淮汽車集團股份有限公司，安徽 合肥 230601）

前言

CAN數據包的長度不超過8個字節，在診斷等場合下會需要傳輸幾十甚至上百字節的數據，為了解決這種情形下的應用矛盾，目前有兩種較好的方案：一是ISO 15765-2標準中在網絡層定義的多幀數據通訊；二是SAE J1939-21標準在數據鏈路層中也定義了多幀數據通訊，二者雖然都是對于多幀數據通訊的實現，但是在實現方式、最大通訊數據量、超時、錯誤處理等上存在較大的差異，下面分別分析兩種多幀數據通訊以及二者之間的差異、優劣、應用趨勢、發展前景等。

1 ISO 15765-2多幀數據通訊

ISO15765協議在傳輸多幀數據的過程中需要對報文進行組包、分包和流控制（FC），ISO15765協議是通過一個控制信息來實現的。

1.1 控制及數據結構

ISO15765定義了一個協議控制信息（PCI）來完成數據的通訊，通過PCI將數據分為單幀（SF）、第一幀（FF）、連續幀（CF）和流控制幀（FC）4種類型的消息幀，通過數據域的PCI區別幀功能類型（本文僅對常規尋址、常規固定尋址進行說明，其他尋址方式的 PCI填充信息會稍有差異）。表1描述了這幾種幀的數據域結構。

表1 數據域結構

表2～表4描述了實現多幀數據通訊的四種PDU類型及數據域結構信息含義：

第一幀的0字節的高4位填充1，表示PDU的類型為第一幀，0字節和1字節共同組成數據包的長度，共12位，所以ISO 15765-2定義的多幀數據通訊的最大數據量為4095字節；2～7字節填充第一幀數據。

表2 第一幀的數據域結構描述

表3 流控制幀的數據域結構描述

表4 連續幀的數據域結構描述

1.2 數據通訊過程

圖1描述了一個完整的基于ISO 15765-2協議定義的多幀數據通訊過程。

圖1 多幀數據通訊過程

發送節點從應用層接收數據后，來判斷是屬于長數據還是短數據。如果數據長度≤7時，數據就會以單幀的形式通訊。生成的單幀PCI（1個字節）、數據和CAN標識符一起組成網絡層PDU傳輸到數據鏈路層。

當數據長度＞7時，就會對數據進行打包，將前6個字節的數據放在 FF幀（第一幀）中，在第一幀的前兩個字節是PCI，包含消息幀的長度。隨后接收數據的節點會發送流控制幀（FC），流控制幀就是告訴發送節點接下來怎么樣發送剩下的數據。流控制幀包含BS（Block Size）和STmin。其中 BS決定了接收節點一次可以接收連續幀的個數。STmin為連續發送連續幀的最小時間間隔。每次發送過程均收到FC，再根據FC發送剩余數據，直至全部數據發送完。

當SF和CF的最后一幀加上PCI的信息不夠8個字節時，即數據域沒有全部使用時，協議規定要填充，具體填充1或0可由OEM定義，目的是在CAN總線上傳輸的數據都是8個字節，省去數據鏈路層去計算DLC。

以上是在發送時的拆裝過程，相反，如果接收來自電控單元的數據時則要完成組裝過程，這時需要一個具有足夠空間的緩存區以存放接收的數據。

1.3 連接超時及錯誤處理

1.3.1 連接超時

在 4種消息幀通訊的過程中，會有 As、Ar、Bs、Br、Cs和Cr六種定時參數約束這四種消息幀的通訊時間和通訊的間隔等。

圖2 時間參數定義

表5 超時定義

1.3.2 錯誤識別與處理

SF_DL錯誤：SF_DL=0 或者SF_DL＞7（常規尋址）接收方網絡層應忽略接收到的單幀，且接收方無 indication；FF_DL＞接收方的緩存，那么接收方網絡層應中斷報文接收，接收方發送 FC，其中 FS=Overflow，接收方無 indication；FF_DL＜=7/6（常規尋址模式為7，擴展或混合尋址為6），網絡層忽略FF，接收方無indication，且不發送FC；SN錯誤：CF N_PDU中的SN錯誤，報文接收應被中斷，接收方網絡層應指示上層＜Result＞=N_WRONG_SN；SN 錯誤：CF N_PDU中的SN錯誤，報文接收應被中斷，接收方網絡層應指示上層＜Result＞=N_WRONG_SN；FS錯誤：如果發送方網絡層發現接收到的FC N_PDU中的FS錯誤，那么報文發送應被中斷，發送方網絡層應確認上層＜Result＞=N_INVALID_FS；N_WFTmax：接收方最多連續發送多少個等待FC幀個數，本地變量，僅可以在多幀報文發送過程中接收方網絡實體中定義，系統初始化時應設置正確，使用這個變量用于避免發送方節點一直處于等待FC狀態；ST錯誤：發送方接收到的FC中的STmin設置為保留值時，發送方繼續發送 CF，只是各個CF之間的間隔時間為協議最大值（7F-127ms），發送方和接收方沒有錯誤向各自上層報告。

非預期幀的處理：在多幀報文通訊過程中，任何一方接收到的非期望報文（同一個N_AI），總線設計者確定總線采用全雙工或半雙工，然后依據節點處于接收狀態，發送狀態及空閑狀態時，接收到非預期報文，網絡層的處理方法不同：①半雙工狀態，網絡層處于發送狀態，收到任何數據報文，均忽略；②全雙工狀態，除SF和物理尋址的FF外，包括功能尋址FF均作忽略處理，且不向上層報告。

表6 STmin定義

多幀報文的發送必須使用物理尋址，如果多幀報文的發送是功能尋址則需忽略功能尋址第一幀。

2 SAE J1939-21數據通訊

1個SAE J1939消息幀的數據場不超過8個字節，因此，如果要發送的數據長度超過8個字節，就需要將消息幀分成幾個不超過8個字節的消息幀分包發送。

2.1 控制及數據結構

表7～表14描述了實現連接管理及數據通訊的數據結構。

SAE J1939-21數據數據通訊中對于TP.DT(數據傳送)數據域的結構定義見表7，數據場的第1個字節從1開始作為消息幀的序號，后7個字節用來存放數據，所以可發送255×7=1785個字節的數據（255表示最大能夠發送的包數，范圍1～255包；7表示每包消息幀的字節數，2～8位為存放數據位）。數據包按照包編號順序發送，最后一個數據包未用的字節以0xFF填充。

表7 TP.DT數據域結構

表8 TP.DT參數組描述

表9 TP.CM參數組描述

表10 TP.CM_RTS參數描述

表11 TP.CM_CTS參數描述

表12 TP.CM_EndofMsgAck參數描述

表13 TP.CM_Abort參數描述

表14 TP.CM_BAM參數描述

消息幀被接收以后按序號重新組合成原來的數據，消息幀的重組過程正好是拆分包的逆向過程。

2.2 數據通訊過程

連接管理主要對節點之間連接的建立和關閉、數據的傳送進行管理，其中定義了發送請求幀、發送清除幀、結束應答幀、連接失敗幀及用來全局接收的廣播幀5種幀結構。節點之間的連接通過1個節點向目的地址發送1個發送請求幀而建立。在接收發送請求幀以后，節點如果有足夠的空間來接收數據并且數據有效，則發送1個發送清除幀，開始數據的傳送；如果存儲空間不夠或數據無效等原因而節點需要拒絕連接，則發送連接失敗幀，連接關閉；如果數據接收全部完成，則節點發送1個結束應答幀，連接關閉。

2.2.1 點對點會話

一般會話的通訊過程參考圖3：圖3描述了基于請求、應答模式的連接管理及數據通訊過程，發送節點請求傳輸一個PGN為65259的數據包，字節長度為23字節，包長度為4包，接收節點允許單次連續發送不超過2包的數據，通訊過程按照一般正常過程完成連接管理及數據通訊。

圖3 點對點會話過程

要求某一個數據包重發：參考圖4虛線框內，接收節點要求把PGN65259的第2包數據重發，發送節點下一幀把第2包數據重新發送一遍。

圖4 數據包重發過程

利用RTS的最大數據包能力：參考圖5虛線框內，發送節點單次連續發送5包數據。

圖5 RTS的最大數據包通訊

2.2.2 廣播會話

圖6描述了基于廣播模式的數據通訊過程：發送節點廣播請求傳輸一個PGN為65260的數據包，字節長度為17字節，包長度為3包，通訊過程按照一般正常過程完成數據通訊。

圖6 廣播會話通訊過程

2.3 連接超時及錯誤處理

2.3.1 連接超時

超時功能：控制報文的發送速率，留給對方足夠的處理時間，防止長時間等待。

超時處理：點對點會話中，等待方發送放棄連接報文，退出通訊過程；廣播公告中，直接退出通訊過程。

表15 超時的時間參數設定

2.3.2 錯誤識別與處理

1）連接關閉的情形：

①BAM 報文的連接關閉情形：發送節點發送最后一包DT；響應節點接收到最后一包DT，出現一次T1連接超時。

②RTS/CTS報文連接關閉情形：發送節點完成數據通訊后接收到 TP.CM_EndOfMsgAck；發送了放棄連接報文；接收到放棄連接報文。響應節點完成數據通訊后發送TP.CM_EndOfMsgAck；接收到放棄連接報文；發送了放棄連接報文。

2）連接限制的情形：

①同一時刻，發送節點對一個節點只能發起一個點對點會話。

②發送節點同一時刻只能發起一個廣播公告。

③連接狀態下，如果接收節點不支持另一個連接，必須發送放棄連接報文進行拒絕。

④接收節點必須能夠同時接收來自多個不同節點的連接（包括點對點會話和廣播公告）。

⑤接收節點能夠同時支持由同一個發送節點發起的一個點對點會話和一個廣播公告。

3 兩種多幀數據通訊差異

CAN數據包的長度不超過8個字節，在診斷等場合下會需要傳輸幾十甚至上百字節的數據，無論ISO 15765-2還是SAE J1939-21均能很好的解決多幀數據通訊的功能，只是二者在實現思想及細節上存在一定差異。

3.1 連接管理、數據通訊

ISO15765-2定義了一個PCI來完成連接管理及數據的通訊，PCI放置在數據域的第1～3字節，通過PCI將數據分為SF、FF、CF和FC 4種類型的消息幀及對應的控制信息，4種數據幀共用一個ID，通過PCI來區別幀的功能類型及對應的控制信息。節點之間的連接管理及數據通訊控制信息均是通過PCI來體現。

而SAE J1939-21則是通過PGN TP.CM來實現節點之間的連接管理，包括：發送請求、發送允許、結束應答、連接失敗及用來全局接收的廣播功能的實現，5種功能的控制信息則是填充到對應數據域的第1字節內。SAE J1939-21實現數據通訊則是通過PGNTP.DT來實現，數據域第1字節填充數據包的編號，第2～7字節填充具體數據。節點之間的連接管理及數據通訊控制信息是通過兩個 PGN及對應的控制字節來實現的。

3.2 數據域結構

由于二者在通訊模式、實現策略上的差異性，二者的數據域結構也存在一定的差異，第2、3章節已詳細說明，此章節就不再詳述，但是二者基于對報文組包、拆包及連接控制的核心思想都是相通的，都是為了實現多幀通訊的功能。

3.3 最大數據長度

由于二者數據格式定義的差異性，所以二者在最大數據傳輸長度上也不同，其中ISO15765-2的為4095字節，SAE J1939-21的為1785字節。

3.4 超時及錯誤處理

為了控制數據的發送速率，留給控制器足夠的處理時間，防止長時間等待，應對總線異常狀況，超時處理和故障處理策略的定義是非常必要的。二者為了數據通訊功能的實現均提供了完善的超時功能及故障處理策略。二者在超時參數的定義及故障處理策略上根據自身通訊機制的差異分別作了詳細的定義，差異較大。

4 優劣分析及應用趨勢

從二者的差異性可以看出，SAE J1939-21數據通訊在通訊模式、實現策略上更為復雜，對于主機廠、供應商等開發應用者來說更難理解和應用。ISO15765-2定義的數據結構上相較更為緊湊，對數據域的利用率也更高，在傳輸同等數據量的情況下，通訊效率也更高。ISO15765-2支持的最大數據長度為4095字節，SAE J1939-21為1785字節。從技術角度分析，ISO15765-2的數據通訊略優于SAE J1939-21定義的數據通訊。

另外，多幀數據通訊一般應用于診斷場合，依附于診斷協議的推廣而被推廣，所以診斷協議的應用推廣狀況代表著兩種多幀數據通訊的推廣情況。ISO 15765-2屬于ISO的體系，一般和ISO 11898、ISO 14229等協議規范共同組成整車的總線協議，一般應用在乘用車領域。SAEJ1939-21由于屬于SAE J1939系列協議的體系，所以在SAE J1939通訊協議的場合中應用廣泛，應用車型主要包含中大型卡車和客車等。IS0 15765診斷協議是全球統一診斷協議IS014229基于CAN總線的具體應用，IS0 15765和IS014229的組合形成的診斷協議標準經過多年的發展和應用已非常完善與成熟，適用于電控單元的在線配置、開發標定、售后維修和軟件升級等，在乘用車及中小型的商用車上得到非常廣泛的應用。SAE J1939是美國汽車工程師協會制定的專門針對重型車應用的通訊、診斷協議，由于SAE J1939起步稍晚，其定義的增強型診斷實現機制異常復雜，尤其是診斷服務不夠完善，所以若想進一步推廣還需做大量的完善工作。

目前無論從技術的角度還是從各自所從屬的診斷協議的推廣狀況來看，ISO15765-2的多幀數據通訊都要優于 SAE J1939-21定義的多幀數據通訊。所以筆者大膽預測，未來ISO15765-2的多幀數據通訊憑借自身的技術優勢及和 ISO 14229、ISO 15765的依附關系會進一步擴大應用范圍，包括乘用車，中小型商用車，甚至是采用SAE J1939系統通訊的控制器，SAEJ1939-21多幀數據通訊的應用范圍可能將進一步被蠶食，局限于DM1、DM2（SAE J1939定義的當前故障、歷史故障診斷服務）等有限的診斷服務中。

5 結論

兩種多幀數據多幀數據通訊雖在通訊原理、機制、實現手段、細節等方面存在較大的差異，但是二者基于對報文組包、拆包及連接控制的核心思想都是相通的，都是為了實現多幀通訊的功能。只有充分理解和掌握這些協議的原理、機制等，才能更加方便、精準地指導汽車總線設計、驗證，了解汽車的故障，準確快速地分析、解決汽車出現的問題。而主機廠也應根據自身及外界發展趨勢合理選擇適合自身的多幀數據通訊，通過長遠的平臺規劃，以提高整車的系統兼容性。

[1] SAEJ1939-21:DataLinkLayer,2006.

[2] SAEJ1939-71:VehicleApplicationLayer,2010.

[3] SAEJ1939-73:ApplicationLayerDiagnostics,2010.

[4] IS015765-2:Roadvehicles Diagnosticson ControllerArea Networks(CAN),Part2:Networklayerservices,2004.