李濟泰 楊 毅

（廣州汽車集團股份有限公司）

1 前言

車載電控單元在汽車上的應(yīng)用越來越多，功能也越來越復(fù)雜，因此，對車載電控單元應(yīng)用程序的更新也越來越頻繁。在現(xiàn)有車載電控單元應(yīng)用程序更新方法中，大部分采用芯片廠商提供的程序燒寫器進行更新，更新時需要拆卸車載電控單元，這對主機廠來說幾乎是不可能的?？紤]到目前車載電控單元大部分使用CAN通信，因此采用一種接入車載OBD接口，并通過CAN總線對車載電控單元的應(yīng)用程序進行更新的刷新系統(tǒng)。這種刷新方式雖然要求電控單元應(yīng)符合ISO15765定義的刷新規(guī)則，但無需拆卸電控單元，也無需考慮電控單元使用的芯片類型，尤其適用于主機廠。

2 車載電控單元應(yīng)用程序刷新系統(tǒng)原理

基于ISO15765協(xié)議的車載電控單元應(yīng)用程序刷新系統(tǒng)（下稱刷新系統(tǒng)）原理如圖1所示。該刷新系統(tǒng)由上位機和下位機組成。上位機用作人機界面，一方面執(zhí)行操作人員的指令，另一方面顯示刷新過程中必要的信息；下位機用作與車載電控單元通信的接口，一方面從上位機接收指令和數(shù)據(jù)，另一方面與車載電控單元進行通信，完成應(yīng)用程序的刷新。上、下位機之間的通信采用RS232串口，上層通信協(xié)議自定義。下位機與車載電控單元的通信采用CAN總線，上層通信協(xié)議采用ISO15765協(xié)議。

車載電控單元若要能夠刷新應(yīng)用程序，必須包含應(yīng)用程序和引導(dǎo)程序2個可執(zhí)行的軟件包。在ECU正常運行時，應(yīng)用程序運行；在ECU進行程序刷新或應(yīng)用程序失效時，則引導(dǎo)程序運行。應(yīng)用程序和引導(dǎo)程序需要占據(jù)不同的FLASH空間，其中應(yīng)用程序占據(jù)的空間可刷新，而引導(dǎo)程序占據(jù)的空間受保護不能刷新，這樣可避免引導(dǎo)程序被誤擦除而不能進行應(yīng)用程序刷新的情況。RAM用來存儲引導(dǎo)程序或應(yīng)用程序運行時的臨時變量，可被應(yīng)用程序和引導(dǎo)程序共用。

3 刷新系統(tǒng)設(shè)計

3.1 上、下位機上層通信協(xié)議制定

上位機發(fā)送給下位機的報文稱之為請求，下位機發(fā)送給上位機的報文稱之為回復(fù)，所有的通信都必須由上位機發(fā)起，即先有請求后有回復(fù)。幀的長度最大為20個字節(jié)，如果報文過長則分成多個幀發(fā)送。在請求幀與回復(fù)幀之間的間隔及多幀傳輸中，上一個回復(fù)幀與下一個請求幀之間的間隔最長為500 ms，一旦超時則通信中斷。

請求幀的定義如表1所列。幀類型包括單幀、首幀、末尾幀和連續(xù)幀。單幀表示其內(nèi)容已經(jīng)包含了整個報文的內(nèi)容；首幀表示多幀傳輸中的第1幀；末尾幀表示多幀傳輸?shù)淖詈笠粠?；連續(xù)幀則表示多幀傳輸中的中間幀。數(shù)據(jù)長度是指服務(wù)標識符和參數(shù)的總長度，該長度最大為17個字節(jié)，加上同步頭、幀類型和數(shù)據(jù)長度這3個字節(jié)，整個幀的最大長度為20個字節(jié)。服務(wù)標識符表示該請求的功能，參數(shù)與服務(wù)標識符相對應(yīng)。上位機傳輸應(yīng)用程序給下位機時，服務(wù)標識符使用0x36，參數(shù)為應(yīng)用程序具體數(shù)據(jù)。對于請求下位機刷新車載電控單元的應(yīng)用程序，服務(wù)標識符使用0x31，參數(shù)包括命令類型、當前時間和目標ECU地址。命令類型包括開始刷新命令和在刷新過程中請求刷新進度的命令；當前時間用以保證刷新的可追溯性；目標ECU地址可指定當前要刷新的車載電控單元。

表1 請求幀定義

肯定回復(fù)的定義如表2所列。幀類型為請求幀類型取反；服務(wù)標識符為請求服務(wù)標識符取反；參數(shù)為執(zhí)行請求的結(jié)果。

否定回復(fù)的定義如表3所列。服務(wù)標識符為請求服務(wù)標識符取反；否定碼表示否定回復(fù)的原因。

表2 肯定回復(fù)定義

表3 否定回復(fù)定義

3.2 ISO15765協(xié)議的使用

下位機與車載ECU之間的通信遵循ISO15765協(xié)議，其中網(wǎng)絡(luò)層的通信遵循ISO15765-2，應(yīng)用層的通信遵循ISO15765-3。

ISO15765-2中定義了單幀傳輸和多幀傳輸[1]2種通信方式。在下位機與ECU的通信過程中，如果傳輸?shù)挠行?shù)據(jù)少于8個，則采用單幀傳輸；如果傳輸?shù)挠行?shù)據(jù)多于或等于8個，則采用多幀傳輸，依次使用到首幀、流控制幀和連續(xù)幀。

ISO15765-3中定義了刷新程序的流程及相關(guān)的診斷服務(wù)[2]。下位機刷新車載ECU時采用該流程，如圖2所示。

首先，請求整個網(wǎng)絡(luò)的節(jié)點進入擴展模式，然后關(guān)閉所有節(jié)點的故障設(shè)置以避免其它節(jié)點存儲關(guān)于被刷新節(jié)點的故障，再禁止整個網(wǎng)絡(luò)的非診斷的通信以節(jié)約刷新所用時間。

目前洋山港已建一、二、三期集裝箱碼頭，岸線總長5 640 m，其中一期工程共布置5個5萬～10萬噸級泊位，二期工程布置4個7萬～10萬噸級泊位，三期工程布置7個7萬～15萬噸級泊位。經(jīng)加固升級改造，洋山港二、三期碼頭現(xiàn)可靠泊20萬噸級集裝箱船舶。[1]

其次，請求被刷新節(jié)點進入刷新模式，由應(yīng)用程序運行狀態(tài)轉(zhuǎn)換到引導(dǎo)程序運行狀態(tài)，然后擦除原應(yīng)用程序所占據(jù)的存儲器空間，再請求傳輸程序傳輸數(shù)據(jù)到存儲空間，并在數(shù)據(jù)傳輸完成后檢查數(shù)據(jù)的一致性。

最后，請求整個網(wǎng)絡(luò)的節(jié)點進入默認模式，使得被刷新節(jié)點重啟，由引導(dǎo)程序運行狀態(tài)轉(zhuǎn)換到新應(yīng)用程序運行狀態(tài)，并使之前關(guān)閉的故障設(shè)置和非診斷通信重新開啟，整個網(wǎng)絡(luò)進入正常運行狀態(tài)。

3.3 上位機軟件設(shè)計

該上位機軟件的開發(fā)平臺為National Instrument提供的圖形化虛擬儀器集成開發(fā)環(huán)境Lab-VIEW 8.5，它具備友好的編程環(huán)境及提供了許多實用的控件，給軟件開發(fā)帶來了極大的方便[3]。

該上位機功能分為2部分。一部分為傳輸應(yīng)用程序文件給下位機，并顯示傳輸進度；另一部分為請求下位機刷新車載電控單元的應(yīng)用程序，并顯示刷新進度。

傳輸應(yīng)用程序文件的軟件流程如圖3所示。首先，初始化刷新人員所選擇的串口，然后將刷新人員選取的應(yīng)用程序文件的前16個字節(jié)讀取出來，加上同步頭、幀類型、數(shù)據(jù)長度和服務(wù)標識符形成請求幀通過串口發(fā)送出去。發(fā)送后從串口讀取下位機的回復(fù)，收到肯定回復(fù)則計算出傳輸進度并顯示，回復(fù)超時或否定回復(fù)則顯示相應(yīng)的報錯信息并退出。如果文件沒有發(fā)送完畢，則每次循環(huán)發(fā)送16個字節(jié)的數(shù)據(jù)，直到文件全部發(fā)送完畢為止。最后進行CRC校驗，檢測傳輸過程中是否出現(xiàn)了誤傳。

請求下位機刷新車載電控單元的應(yīng)用程序軟件流程如圖4所示。首先，根據(jù)獲取的系統(tǒng)時間、刷新人員所選擇的ECU地址生成開始刷新的請求幀，并通過串口發(fā)送出去。發(fā)送后從串口讀取下位機的回復(fù)，收到肯定回復(fù)則將回復(fù)中的進度信息提取出來并顯示，回復(fù)超時或否定回復(fù)則顯示相應(yīng)的報錯信息并退出。如果刷新沒有100%完成，則循環(huán)發(fā)送刷新進度的請求，從下位機的回復(fù)中獲得實時刷新進度并顯示，直到刷新成功完成為止。

3.4 下位機硬件設(shè)計

微處理器模塊的主要組成部分為Freescale公司生產(chǎn)的MC9S12XE100。該處理器是一款低成本、低功耗的16位單片機，它包含有64 K字節(jié)的RAM、1M字節(jié)的FLASH、8個串行通信接口、3個串行外圍接口、2個16通道、12 bit的A/D轉(zhuǎn)換器、1個8通道的脈寬調(diào)節(jié)模塊和5個兼容CAN2.0A、B的CAN模塊[4]，可滿足與上位機和車載電控單元之間的通信。

高速CAN通信模塊的主要組成部分為NXP公司生產(chǎn)的TJA1040。該CAN收發(fā)器完全兼容ISO11898協(xié)議，支持最高1 Mbaud的通信速率，具有非常低的電磁輻射和非常高的抗電磁騷擾能力[5]。

低速CAN通信模塊的主要組成部分為NXP公司生產(chǎn)的TJA1054。該低速容錯CAN收發(fā)器支持最高125 Kbaud的通信速率。與TJA1040相似，該收發(fā)器同樣具有非常低的電磁輻射和非常高的抗電磁騷擾能力[6]。

RS232通信模塊的主要組成部分為DALLAS SEMICONDUCTOR公司生產(chǎn)的低功耗收發(fā)器DS276，該收發(fā)器完全兼容RS232信號[7]。

3.5 下位機軟件設(shè)計

該下位機軟件的開發(fā)平臺為Freescale提供的一個面向S12（X）系列MCU的集成開發(fā)環(huán)境Code-Warrior 5.0，它不僅具有很友好的調(diào)試環(huán)境，而且提供了代碼燒寫工具，配合USBMULTILINK調(diào)試/編程器，給軟件開發(fā)帶來方便[8]。

該下位機功能可分為2部分。一部分為接收上位機傳過來的應(yīng)用程序文件；另一部分為刷新車載電控單元的應(yīng)用程序，并上傳刷新進度。

接收應(yīng)用程序文件的軟件流程如圖6所示。首先，初始化單片機并循環(huán)監(jiān)測串口是否收到上位機請求。一旦收到應(yīng)用程序傳輸請求，則在請求中提取出16個字節(jié)的應(yīng)用程序數(shù)據(jù)并存儲。存儲成功后向串口發(fā)送肯定回復(fù)；如存儲未成功，則發(fā)送否定回復(fù)并退出。肯定回復(fù)后，根據(jù)請求的幀類型是否為末尾幀來判斷文件傳輸是否完畢。如未完畢，則繼續(xù)循環(huán)從串口中讀取請求，并提取應(yīng)用程序數(shù)據(jù)存儲，直到文件傳輸完畢為止。在此過程中，如果出現(xiàn)無效請求或超時，則報錯退出。文件接收完畢后，判斷CRC校驗是否正確。如果正確，置應(yīng)用程序有效位，結(jié)束此次文件傳輸；如果錯誤，則表示此次傳輸失敗，退出。

刷新應(yīng)用程序的軟件流程如圖7所示。首先，循環(huán)監(jiān)測串口是否收到上位機請求。一旦收到應(yīng)用程序刷新請求，則在CAN上發(fā)送進入擴展模式的診斷請求，與ECU建立診斷通信。如果ECU肯定回復(fù)，則在串口回復(fù)上位機開始刷新成功；如果ECU否定回復(fù)，則在串口上回復(fù)CAN通信失敗并退出?；貜?fù)上位機開始刷新成功后，下位機按照ISO15765-3定義的刷新流程，通過CAN對ECU進行程序刷新，包括關(guān)閉故障設(shè)置、禁止非診斷通信、進入刷新模式、擦除ECU FLASH里的應(yīng)用程序代碼空間、請求傳輸新的應(yīng)用程序數(shù)據(jù)和傳輸程序數(shù)據(jù)。在傳輸程序數(shù)據(jù)的過程中，循環(huán)接收上位機周期性發(fā)送過來的詢問軟件刷新進度的請求，并根據(jù)傳輸數(shù)據(jù)的進度進行實時回復(fù)，便于上位機更新進度條信息。程序數(shù)據(jù)傳輸完畢后，繼續(xù)進行ISO15765-3定義的傳輸數(shù)據(jù)檢查和進入默認模式。此2步順利完成后，則應(yīng)用程序的刷新完成。

4 試驗結(jié)果

該刷新系統(tǒng)經(jīng)過實車測試完全能夠成功刷新符合ISO15765協(xié)議的車載電控單元，上位機刷新界面如圖8所示。

具體操作流程如下：首先在設(shè)置中選擇串口號、待刷新ECU的名稱和待更新的應(yīng)用程序二進制文件，并在命令下拉菜單中選擇傳輸應(yīng)用程序的命令，然后點擊開始；這時，應(yīng)用程序由上位機傳向下位機，進度條實時顯示傳輸?shù)倪M度；應(yīng)用程序傳輸完畢后，在命令下拉菜單中選擇刷新應(yīng)用程序的命令，并點擊開始；此時下位機更新ECU的應(yīng)用程序，進度條實時顯示程序更新的進度，直到更新完畢。如果在上述過程中出現(xiàn)錯誤，則顯示有錯誤的文字信息。

5 結(jié)束語

設(shè)計了基于ISO15765協(xié)議的車載電控單元應(yīng)用程序的刷新系統(tǒng)，并采用了上、下位機的方式，其中上位機用作人機界面，下位機用作上位機和車載電控單元之間的通信接口。經(jīng)測試，該系統(tǒng)可成功刷新符合ISO15765協(xié)議的車載電控單元的應(yīng)用程序。目前，正在研究將上、下位機的通信由RS232通信改為USB通信，這樣可加快刷新速度。另外，該系統(tǒng)作為一個CAN通信節(jié)點，在汽車電子的其它領(lǐng)域也有廣泛的應(yīng)用前景。

1 ISO15765-2.Road vehicles—Diagnostics on Controller Area Networks（CAN）—Part 2：Network layer services.International Organization for Standardization，2004.

2 ISO15765-3.Road vehicles—Diagnostics on Controller Area Networks（CAN）—Part 3：Implementation of unified diagnostic services （UDS on CAN）.International Organization for Standardization，2004.

3 楊樂平，李海濤，等.LabVIEW高級程序設(shè)計.北京：清華大學(xué)出版社，2003.

4 Freescale Semiconductor.MC9S12XEP100 Reference Manual Covers MC9S12XE Family.Rev.1.222010.

5 Philips Semiconductors.TJA1040 High speed CAN transceiver data sheet.2003.

6 NXP Semiconductors.TJA1054 Fault-tolerant CAN transceiver data sheet.2010.

7 DALLAS SEMICONDUCTOR.DS276 Low Power Transceiver Chip.1999.

8 邵貝貝，宮輝，等.嵌入式系統(tǒng)中的雙核技術(shù).北京：北京航空航天大學(xué)出版社，2008.