中文信息在車載網(wǎng)絡CAN總線中的傳輸研究

杜貴鋒，李 銳，王遠波，郭驚宇，王 龍

（陜西重型汽車有限公司汽車工程研究院，陜西 西安 710200）

隨著汽車智能化、網(wǎng)聯(lián)化的發(fā)展，人與車、人與后臺之間進行實時信息交互的應用需求變得越來越多，這種信息交互是通過文字信息、圖形信息或音頻視頻信息進行的，因此，研究文字信息，特別是中文文字信息在車載網(wǎng)絡中的傳輸具有非常重要的現(xiàn)實意義［1］。

中文文字信息在車載網(wǎng)絡中的傳輸，主要涉及中文文字信息編碼類型，以及大塊的文本信息 （CAN總線中指數(shù)據(jù)長度大于8個字節(jié)）通過傳輸協(xié)議進行傳輸兩部分內容。

1 中文信息文字編碼

文字信息的傳輸和存儲基礎是標準字符集，字符集也叫字庫或語言編碼，常用的語言編碼有UTF-8和GBK。UTF-8是國際編碼，俗稱萬國碼，幾乎包含全世界所有國家需要用到的語言編碼 （相當于一個大字庫），比如日文、韓文等都可以用，具有很好的通用性；GBK編碼是中國制訂的，是漢字國標GB2312-80標準的擴展。GBK編碼共收錄漢字和圖形符號21886個，其中漢字 （包括部首和構件）21003個，圖形符號883個。

GBK與UTF-8編碼方式不同，GBK的文字編碼是用雙字節(jié)來表示的，即不論中、英文字符均使用雙字節(jié)來表示，只不過為區(qū)分中文，將其最高位都定成1，其編碼范圍：8140－FEFE；而UTF-8編碼，它對英文使用8位 （即一個字節(jié)），中文使用24位 （3個字節(jié)）來編碼。對于使用中文較多的情況下使用GBK可以節(jié)省空間，而對于英文字符較多的使用場景則用UTF-8資源配置更加合理［2］。

主機廠可根據(jù)車輛的市場定位、銷售區(qū)域，使用不同的編碼。如果車輛為面向國際的銷售，采用UTF-8編碼較為合適；如果國內是主銷，則GKB節(jié)約資源。或者在平臺設計時兩種編碼都配備，根據(jù)車輛最終用戶情況，在車輛下線時進行配置，選定使用文字編碼的類型。具體采用哪種方式，如何配置，應在構建整車電子電器EE架構平臺時進行規(guī)劃設定。

2 CAN總線傳輸協(xié)議

當前車載骨干網(wǎng)絡為CAN總線，CAN采用短幀結構，適用于控制信息的傳輸，實時性強，可靠性高。如果要傳輸超過8個字節(jié)的數(shù)據(jù)信息，則需要通過傳輸協(xié)議進行。傳輸協(xié)議的主要功能就是在發(fā)送端將大塊數(shù)據(jù)拆分成若干小段，從而滿足CAN總線每幀只能傳輸8個字節(jié)的要求，一般稱為拆包；接收端收到數(shù)據(jù)后，按傳輸協(xié)議將數(shù)據(jù)組合還原，也稱為組包。

常用的CAN總線傳輸協(xié)議，主要有兩種：一是SEA J1939標準中在數(shù)據(jù)鏈路層J1939-21定義了多包傳輸協(xié)議，另一個是UDS標準中在網(wǎng)絡層ISO15765-2中實現(xiàn)多包傳輸?shù)墓δ堋EA J1939用于常規(guī)數(shù)據(jù)通信，也用于SEA J1939診斷，ISO 15765-2主要用于UDS診斷。

2.1 J1939傳輸協(xié)議

SEA J1939協(xié)議定義了一個專用的PGN參數(shù)組 （60610（00EB0016））來傳輸拆分后的數(shù)據(jù)，數(shù)據(jù)傳送報文TP.DT的參數(shù)組中，數(shù)據(jù)域的第1個字節(jié)用作消息幀的序號，后7個字節(jié)用來存放有效數(shù)據(jù)。單次可以發(fā)送255×7=1785個字節(jié)的數(shù)據(jù)。協(xié)議定義了點對點傳輸和廣播傳輸兩種形式。

1）點對點傳輸。發(fā)送節(jié)點和接收節(jié)點之間虛擬連接的建立與關閉，傳輸協(xié)議包含的幀格式大致分為2類：TP.CM和TP.DT。在TP.CM中定義了5種幀格式：發(fā)送請求幀 （TP.CM_RTS），準備發(fā)送幀 （TP.CM_CTS），結束應答幀 （TP.EndofMsgACK），連接失敗幀 （TP.Conn_Abort）以及用來全局接收的廣播幀 （TP.CM_BAM）。TP.DT用于具體數(shù)據(jù)傳送。發(fā)送請求幀 （TP.CM_RTS）用于發(fā)送節(jié)點 （A節(jié)點）向目的節(jié)點 （B節(jié)點）發(fā)送請求與之建立通信連接，準備發(fā)送幀（TP.CM_CTS）是B節(jié)點向A節(jié)點表示已答應其請求并做好了數(shù)據(jù)接收準備，至此A、B節(jié)點之間的通信連接建立完畢，接下來A節(jié)點就通過數(shù)據(jù)幀TP.DT向B節(jié)點持續(xù)發(fā)送數(shù)據(jù)幀，在最后一幀信息發(fā)送完畢后，A節(jié)點會發(fā)送一個消息結束應答信息 （TP.EndofMsgACK），然后在一定時間后A、B節(jié)點會斷開連接；若發(fā)送雙方在傳輸過程中任一方出現(xiàn)故障（超時、故障、資源不足等）均可發(fā)送連接失敗幀 （TP.Conn_Abort）來斷開連接。

2）廣播傳輸。如果消息是發(fā)送到多個節(jié)點或者是全局，則不需要數(shù)據(jù)流控制和關閉的管理功能，只需要通過廣播消息來通知消息的發(fā)送即可。SEA J1939-21定義了一個專用的PGN參數(shù)組 （60416（00EC0016））用于多包傳輸?shù)倪B接管理。該報文中，數(shù)據(jù)域的首字節(jié)為控制字節(jié)，通過改變控制字節(jié)的數(shù)據(jù)可以實現(xiàn)不同的控制功能，完成數(shù)據(jù)傳輸過程的連接管理。發(fā)送節(jié)點首先要發(fā)送一條廣播公告消息TP.CM_BAM，向其他節(jié)點申明自己要發(fā)送多包消息，之后直接開始發(fā)送數(shù)據(jù)，而不必等待接收節(jié)點的響應，數(shù)據(jù)發(fā)送完畢后也不關閉連接［3］。J1939多幀傳輸如圖1所示。

圖1 J1939多幀傳輸

2.2 ISO 15765傳輸協(xié)議

通過ISO 15765的網(wǎng)絡傳輸協(xié)議也可實現(xiàn)對大塊數(shù)據(jù)的傳輸。該協(xié)議是通過一個控制信息PCI（Protocol control information傳輸控制協(xié)議）來完成大塊數(shù)據(jù)的拆分、組裝的，通過PCI將數(shù)據(jù)分為單幀 （SF）、第1幀 （FF）、連續(xù)幀 （CF）和流控制幀 （FC）4種類型的消息幀，通過數(shù)據(jù)域的PCI區(qū)別幀功能類型，其數(shù)據(jù)結構見表1。

表1中：如果CAN消息的數(shù)據(jù)域的第1個字節(jié)的7-4位為0，即N_PCItype=0，則為單幀 （SF）；如果CAN消息的數(shù)據(jù)域的第1個字節(jié)的7-4位為1，即N_PCItype=1，則為首幀（FF）；如果CAN消息的數(shù)據(jù)域的第1個字節(jié)的7-4位為2，即N_PCItype=2，則為連續(xù)幀 （CF）；如果CAN消息的數(shù)據(jù)域的第1個字節(jié)的7-4位為3，即N_PCItype=3，則為流控幀 （FC）。

流控幀就是告訴發(fā)送節(jié)點如何發(fā)送剩下的數(shù)據(jù)，F(xiàn)S為數(shù)據(jù)流傳輸?shù)臓顟B(tài)信息，當FS=0時，代表接收方已經(jīng)準備就緒，發(fā)送方可以發(fā)送序列幀；當FS=1時，發(fā)送方繼續(xù)等待流控幀且復位N_BS的超時定時器；當FS=2時，代表接收方的內存不夠，發(fā)送方須結束數(shù)據(jù)傳輸。BS為接收方發(fā)送一個流控幀后可以接收連續(xù)幀的數(shù)量，當BS=0時，接收方不再發(fā)送流控幀，發(fā)送方可以持續(xù)發(fā)送直到數(shù)據(jù)傳輸完成。ST為連續(xù)發(fā)送連續(xù)幀的最小時間間隔［4］。ISO 15765單幀傳輸與多幀傳輸如圖2所示。

圖2 15765單幀傳輸與多幀傳輸

3 中文信息在CAN總線系統(tǒng)中傳輸

一般來講，人機、人與后臺之間的信息交互，大段的文字信息數(shù)量較少，類似短信、微信量級的居多。大段中文文字傳輸應用場景，一般在FOTA時升級或后臺進行資訊推送時可以用到，在FOTA升級中，特別是在商用車中，F(xiàn)OTA還是個新鮮事物，車主們難免會對遠程升級FOTA心存顧慮，因此，F(xiàn)OTA升級前需要將升級原因等相關資訊的信息全面、完整地推送給車主，有利于駕駛員進行積極配合，獲取升級授權，使得FOTA升級得以順利進行。全面、完整的升級資訊傳輸，勢必需要大段的文字信息來進行表述［5］。

3.1 車載網(wǎng)絡CAN總線中文信息傳輸時間以及對總線負載的影響

信息傳輸時間，按GBK編碼，每個漢字占2個字節(jié)，按推送500字提示信息計，傳輸總數(shù)據(jù)量為1 000字節(jié)，按每幀傳輸7個字節(jié)計，需要傳輸?shù)膸瑪?shù)=1 000／7+1=144幀，如果定義連續(xù)幀之間的傳輸時間間隔為50 ms，所需的傳輸時間為：144×50=7 200 ms=7.5 s，傳輸1 000字的提示信息需要15 s。CAN總線波特率按照500k計，傳輸時總線的負載約增加0.6%左右，對于250 k的波特率，負載增加也不會超過1.5%，對總線負載影響很小。如果選擇在整車15下電后，車載終端啟動對多媒體進行傳輸，相當于將整車的休眠時間推遲15 s。

3.2 傳輸協(xié)議選擇

兩種多包傳輸協(xié)議雖然在實現(xiàn)方式、最大傳輸數(shù)據(jù)量、超時、錯誤處理等方面存在著較大的差異，但是二者基于對數(shù)據(jù)拆包、組包及連接控制的核心思想都是相通的，都是為了實現(xiàn)多包傳輸功能。ISO 15765-2一般應用在乘用車領域；而SEA J1939-21主要應用于中大型貨車和客車。SEA J1939-21傳輸協(xié)議在傳輸模式、實現(xiàn)策略上更為復雜，對于主機廠、供應商等開發(fā)應用者來說更難于理解、應用。ISO 15765-2定義的數(shù)據(jù)結構相比更為緊湊，對數(shù)據(jù)域的利用率也更高，在傳輸同等數(shù)據(jù)量的情況下，傳輸效率更高。ISO 15765-2支持的最大數(shù)據(jù)長度為4095B，優(yōu)于SEA J1939-21的1785B。從技術角度分析，ISO 15765-2的傳輸協(xié)議優(yōu)于SEA J1939-21定義的傳輸協(xié)議［6］。

對于乘用車，一般較少使用SEA J1939協(xié)議，因此采用ISO 15765-2網(wǎng)絡層傳輸協(xié)議進行文字的傳輸是最經(jīng)濟的選擇。

對于商用車，基本采用的是SEA J1939協(xié)議，UDS用于離線診斷，因此，中文信息的傳輸可以采用SEA J1939-21傳輸協(xié)議，也可以采用ISO 15765-2協(xié)議進行。一般對于類似短信、微信級別的文字信息傳輸，可以用SEA J1939協(xié)議進行傳輸。對大塊的文字傳輸，如FOTA前的信息交互提示，因為傳輸?shù)臅r間等因素，建議采用ISO 15765-2協(xié)議，在車輛下電情況下進行傳輸。

4 結束語

中文信息傳輸?shù)膶崿F(xiàn)，可顯著提高車輛人機交互的主觀感受，提升車輛的智能化水平。文中就傳統(tǒng)汽車網(wǎng)絡CAN總線上實現(xiàn)中文信息的傳輸，特別是大塊的中文信息，在E-E架構設計時，所涉及的傳輸協(xié)議、文字編碼、傳輸時機的選擇以及對總線負載的影響進行了分析。研究表明，大塊的中文信息在車載網(wǎng)絡CAN總線中傳輸是切實可行的。