李濟泰 楊 毅
(廣州汽車集團股份有限公司)
車載電控單元在汽車上的應用越來越多,功能也越來越復雜,因此,對車載電控單元應用程序的更新也越來越頻繁。在現有車載電控單元應用程序更新方法中,大部分采用芯片廠商提供的程序燒寫器進行更新,更新時需要拆卸車載電控單元,這對主機廠來說幾乎是不可能的。考慮到目前車載電控單元大部分使用CAN通信,因此采用一種接入車載OBD接口,并通過CAN總線對車載電控單元的應用程序進行更新的刷新系統。這種刷新方式雖然要求電控單元應符合ISO15765定義的刷新規則,但無需拆卸電控單元,也無需考慮電控單元使用的芯片類型,尤其適用于主機廠。
基于ISO15765協議的車載電控單元應用程序刷新系統(下稱刷新系統)原理如圖1所示。該刷新系統由上位機和下位機組成。上位機用作人機界面,一方面執行操作人員的指令,另一方面顯示刷新過程中必要的信息;下位機用作與車載電控單元通信的接口,一方面從上位機接收指令和數據,另一方面與車載電控單元進行通信,完成應用程序的刷新。上、下位機之間的通信采用RS232串口,上層通信協議自定義。下位機與車載電控單元的通信采用CAN總線,上層通信協議采用ISO15765協議。
車載電控單元若要能夠刷新應用程序,必須包含應用程序和引導程序2個可執行的軟件包。在ECU正常運行時,應用程序運行;在ECU進行程序刷新或應用程序失效時,則引導程序運行。應用程序和引導程序需要占據不同的FLASH空間,其中應用程序占據的空間可刷新,而引導程序占據的空間受保護不能刷新,這樣可避免引導程序被誤擦除而不能進行應用程序刷新的情況。RAM用來存儲引導程序或應用程序運行時的臨時變量,可被應用程序和引導程序共用。
上位機發送給下位機的報文稱之為請求,下位機發送給上位機的報文稱之為回復,所有的通信都必須由上位機發起,即先有請求后有回復。幀的長度最大為20個字節,如果報文過長則分成多個幀發送。在請求幀與回復幀之間的間隔及多幀傳輸中,上一個回復幀與下一個請求幀之間的間隔最長為500 ms,一旦超時則通信中斷。
請求幀的定義如表1所列。幀類型包括單幀、首幀、末尾幀和連續幀。單幀表示其內容已經包含了整個報文的內容;首幀表示多幀傳輸中的第1幀;末尾幀表示多幀傳輸的最后一幀;連續幀則表示多幀傳輸中的中間幀。數據長度是指服務標識符和參數的總長度,該長度最大為17個字節,加上同步頭、幀類型和數據長度這3個字節,整個幀的最大長度為20個字節。服務標識符表示該請求的功能,參數與服務標識符相對應。上位機傳輸應用程序給下位機時,服務標識符使用0x36,參數為應用程序具體數據。對于請求下位機刷新車載電控單元的應用程序,服務標識符使用0x31,參數包括命令類型、當前時間和目標ECU地址。命令類型包括開始刷新命令和在刷新過程中請求刷新進度的命令;當前時間用以保證刷新的可追溯性;目標ECU地址可指定當前要刷新的車載電控單元。

表1 請求幀定義
肯定回復的定義如表2所列。幀類型為請求幀類型取反;服務標識符為請求服務標識符取反;參數為執行請求的結果。
否定回復的定義如表3所列。服務標識符為請求服務標識符取反;否定碼表示否定回復的原因。

表2 肯定回復定義

表3 否定回復定義
下位機與車載ECU之間的通信遵循ISO15765協議,其中網絡層的通信遵循ISO15765-2,應用層的通信遵循ISO15765-3。
ISO15765-2中定義了單幀傳輸和多幀傳輸[1]2種通信方式。在下位機與ECU的通信過程中,如果傳輸的有效數據少于8個,則采用單幀傳輸;如果傳輸的有效數據多于或等于8個,則采用多幀傳輸,依次使用到首幀、流控制幀和連續幀。
ISO15765-3中定義了刷新程序的流程及相關的診斷服務[2]。下位機刷新車載ECU時采用該流程,如圖2所示。
首先,請求整個網絡的節點進入擴展模式,然后關閉所有節點的故障設置以避免其它節點存儲關于被刷新節點的故障,再禁止整個網絡的非診斷的通信以節約刷新所用時間。
目前洋山港已建一、二、三期集裝箱碼頭,岸線總長5 640 m,其中一期工程共布置5個5萬~10萬噸級泊位,二期工程布置4個7萬~10萬噸級泊位,三期工程布置7個7萬~15萬噸級泊位。經加固升級改造,洋山港二、三期碼頭現可靠泊20萬噸級集裝箱船舶。[1]
其次,請求被刷新節點進入刷新模式,由應用程序運行狀態轉換到引導程序運行狀態,然后擦除原應用程序所占據的存儲器空間,再請求傳輸程序傳輸數據到存儲空間,并在數據傳輸完成后檢查數據的一致性。
最后,請求整個網絡的節點進入默認模式,使得被刷新節點重啟,由引導程序運行狀態轉換到新應用程序運行狀態,并使之前關閉的故障設置和非診斷通信重新開啟,整個網絡進入正常運行狀態。
該上位機軟件的開發平臺為National Instrument提供的圖形化虛擬儀器集成開發環境Lab-VIEW 8.5,它具備友好的編程環境及提供了許多實用的控件,給軟件開發帶來了極大的方便[3]。
該上位機功能分為2部分。一部分為傳輸應用程序文件給下位機,并顯示傳輸進度;另一部分為請求下位機刷新車載電控單元的應用程序,并顯示刷新進度。
傳輸應用程序文件的軟件流程如圖3所示。首先,初始化刷新人員所選擇的串口,然后將刷新人員選取的應用程序文件的前16個字節讀取出來,加上同步頭、幀類型、數據長度和服務標識符形成請求幀通過串口發送出去。發送后從串口讀取下位機的回復,收到肯定回復則計算出傳輸進度并顯示,回復超時或否定回復則顯示相應的報錯信息并退出。如果文件沒有發送完畢,則每次循環發送16個字節的數據,直到文件全部發送完畢為止。最后進行CRC校驗,檢測傳輸過程中是否出現了誤傳。
請求下位機刷新車載電控單元的應用程序軟件流程如圖4所示。首先,根據獲取的系統時間、刷新人員所選擇的ECU地址生成開始刷新的請求幀,并通過串口發送出去。發送后從串口讀取下位機的回復,收到肯定回復則將回復中的進度信息提取出來并顯示,回復超時或否定回復則顯示相應的報錯信息并退出。如果刷新沒有100%完成,則循環發送刷新進度的請求,從下位機的回復中獲得實時刷新進度并顯示,直到刷新成功完成為止。
微處理器模塊的主要組成部分為Freescale公司生產的MC9S12XE100。該處理器是一款低成本、低功耗的16位單片機,它包含有64 K字節的RAM、1M字節的FLASH、8個串行通信接口、3個串行外圍接口、2個16通道、12 bit的A/D轉換器、1個8通道的脈寬調節模塊和5個兼容CAN2.0A、B的CAN模塊[4],可滿足與上位機和車載電控單元之間的通信。
高速CAN通信模塊的主要組成部分為NXP公司生產的TJA1040。該CAN收發器完全兼容ISO11898協議,支持最高1 Mbaud的通信速率,具有非常低的電磁輻射和非常高的抗電磁騷擾能力[5]。
低速CAN通信模塊的主要組成部分為NXP公司生產的TJA1054。該低速容錯CAN收發器支持最高125 Kbaud的通信速率。與TJA1040相似,該收發器同樣具有非常低的電磁輻射和非常高的抗電磁騷擾能力[6]。
RS232通信模塊的主要組成部分為DALLAS SEMICONDUCTOR公司生產的低功耗收發器DS276,該收發器完全兼容RS232信號[7]。
該下位機軟件的開發平臺為Freescale提供的一個面向S12(X)系列MCU的集成開發環境Code-Warrior 5.0,它不僅具有很友好的調試環境,而且提供了代碼燒寫工具,配合USBMULTILINK調試/編程器,給軟件開發帶來方便[8]。
該下位機功能可分為2部分。一部分為接收上位機傳過來的應用程序文件;另一部分為刷新車載電控單元的應用程序,并上傳刷新進度。
接收應用程序文件的軟件流程如圖6所示。首先,初始化單片機并循環監測串口是否收到上位機請求。一旦收到應用程序傳輸請求,則在請求中提取出16個字節的應用程序數據并存儲。存儲成功后向串口發送肯定回復;如存儲未成功,則發送否定回復并退出。肯定回復后,根據請求的幀類型是否為末尾幀來判斷文件傳輸是否完畢。如未完畢,則繼續循環從串口中讀取請求,并提取應用程序數據存儲,直到文件傳輸完畢為止。在此過程中,如果出現無效請求或超時,則報錯退出。文件接收完畢后,判斷CRC校驗是否正確。如果正確,置應用程序有效位,結束此次文件傳輸;如果錯誤,則表示此次傳輸失敗,退出。
刷新應用程序的軟件流程如圖7所示。首先,循環監測串口是否收到上位機請求。一旦收到應用程序刷新請求,則在CAN上發送進入擴展模式的診斷請求,與ECU建立診斷通信。如果ECU肯定回復,則在串口回復上位機開始刷新成功;如果ECU否定回復,則在串口上回復CAN通信失敗并退出。回復上位機開始刷新成功后,下位機按照ISO15765-3定義的刷新流程,通過CAN對ECU進行程序刷新,包括關閉故障設置、禁止非診斷通信、進入刷新模式、擦除ECU FLASH里的應用程序代碼空間、請求傳輸新的應用程序數據和傳輸程序數據。在傳輸程序數據的過程中,循環接收上位機周期性發送過來的詢問軟件刷新進度的請求,并根據傳輸數據的進度進行實時回復,便于上位機更新進度條信息。程序數據傳輸完畢后,繼續進行ISO15765-3定義的傳輸數據檢查和進入默認模式。此2步順利完成后,則應用程序的刷新完成。
該刷新系統經過實車測試完全能夠成功刷新符合ISO15765協議的車載電控單元,上位機刷新界面如圖8所示。
具體操作流程如下:首先在設置中選擇串口號、待刷新ECU的名稱和待更新的應用程序二進制文件,并在命令下拉菜單中選擇傳輸應用程序的命令,然后點擊開始;這時,應用程序由上位機傳向下位機,進度條實時顯示傳輸的進度;應用程序傳輸完畢后,在命令下拉菜單中選擇刷新應用程序的命令,并點擊開始;此時下位機更新ECU的應用程序,進度條實時顯示程序更新的進度,直到更新完畢。如果在上述過程中出現錯誤,則顯示有錯誤的文字信息。
設計了基于ISO15765協議的車載電控單元應用程序的刷新系統,并采用了上、下位機的方式,其中上位機用作人機界面,下位機用作上位機和車載電控單元之間的通信接口。經測試,該系統可成功刷新符合ISO15765協議的車載電控單元的應用程序。目前,正在研究將上、下位機的通信由RS232通信改為USB通信,這樣可加快刷新速度。另外,該系統作為一個CAN通信節點,在汽車電子的其它領域也有廣泛的應用前景。
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高級程序設計.北京:清華大學出版社,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 邵貝貝,宮輝,等.嵌入式系統中的雙核技術.北京:北京航空航天大學出版社,2008.