凌露露 趙芬
摘要:毫米波雷達用于盲區(qū)監(jiān)測系統(tǒng)時,一種連接方法是僅一個雷達掛接在車身網(wǎng)絡上,而另一個雷達無法直接與車身網(wǎng)絡通信,因此也無法通過OBD直接升級軟件。該文提出一套基于UDS的軟件升級方案,在傳統(tǒng)下位機Bootloader中增加主從通訊功能,使得兩個雷達能同時完成軟件升級。經(jīng)實際應用,設計的Bootloader在盲區(qū)監(jiān)測系統(tǒng)和前碰撞預警系統(tǒng)中都能可靠地升級應用軟件。
關鍵詞:Bootloader;毫米波雷達;車載;盲區(qū)監(jiān)測系統(tǒng);UDS
中圖分類號:TP368? ? ? 文獻標識碼:A
文章編號:1009-3044(2021)09-0218-03
開放科學(資源服務)標識碼(OSID):
The Design and Implementation of a CAN Bootloader in Vehicle Millimeter Wave Radar
LING Lu-lu, ZHAO Fen
(The 38th Research Institute of China Electronics Technology Group Corporation, Hefei 230088, China)
Abstract: When millimeter wave radars are used in a blind spot detection (BSD) system, where only one radar working as the main radar is connected to the vehicle network directly, the sub radar that cannot communicate with vehicle network cannot be programed by OBD interface. In order to achieve the program upgrade of two radars, a program upgrade method based on unified diagnostic services (UDS) is proposed. The method adds a master-slave communication function in traditional Bootloader. The Bootloader designed is proved that it can upgrade software correctly and reliably in BSD system and forward collision warning (FCW) system.
Key words: Bootloader ; Millimeter wave radar; Vehicle-mounted; BSD; UDS
1 背景
為了解決因汽車外后視鏡存在視覺盲區(qū)易導致交通事故的問題,越來越多的汽車裝配了盲區(qū)監(jiān)測系統(tǒng),通過在汽車后保險杠內安裝2個毫米波雷達傳感器,監(jiān)測側后方車輛[1]。當雷達系統(tǒng)有功能改進時,需要進行軟件升級,這就要求雷達控制器具備在線刷寫能力。Bootloader是運行于主程序之前的一段小程序,主要完成應用程序下載和更新任務[2-3]。現(xiàn)有的Bootloader方案大都是針對單一控制器,對于有兩個控制器的系統(tǒng),需要在傳統(tǒng)Bootloader中增加一部分功能以達到兩個控制器同時更新軟件的目的。
UDS(unified diagnostic services)診斷服務協(xié)議有一套完善的國際體系標準,可以提升整車廠汽車電子產品的管理能力和效率,也為零部件廠商開發(fā)診斷部分功能提高復制性,減少開發(fā)周期和成本[4]。
本文基于UDS設計了一套應用于車載毫米波雷達的軟件升級方案,可以用于配備兩個毫米波雷達的盲區(qū)檢監(jiān)測系統(tǒng),也適用于僅有一個雷達的前碰撞預警系統(tǒng)。
2 車載毫米波雷達系統(tǒng)介紹
毫米波雷達用于盲區(qū)監(jiān)測時,一般需要兩個雷達模塊,分別安裝在車尾兩側。若僅一個雷達模塊(主雷達)連接到車身網(wǎng)絡上,則另一個雷達模塊(從雷達)與主雷達需通過內部私有CAN連接。從雷達所需的車速、方向盤轉角等車身信息都由主雷達轉發(fā)。
盲區(qū)監(jiān)測雷達系統(tǒng)進行軟件升級時,主雷達能通過OBD口按照正常的Bootloader流程進行在線升級,由于從雷達未連接到車身網(wǎng)絡,所以無法接收到刷新上位機的刷新數(shù)據(jù),此時,需要主雷達在FLASH數(shù)據(jù)接收完畢并且通過校驗后將刷新數(shù)據(jù)轉發(fā)給從雷達。
3 CAN Bootloader的下位機設計
3.1 Flash存儲空間分配
在線升級需要編寫兩個項目程序,分別寫在FLASH的不同區(qū)域,一個項目是應用程序,是產品正常工作時執(zhí)行的程序,另一個是Boot引導程序,用于引導程序啟動和程序更新。以TI公司的DSP芯片TMS320F28335為例,該芯片有8塊FLASH空間A~H,每塊FLASH大小為32KB[5],其中,應用程序占據(jù)其中3個(E、F、G),地址從0x308000到0x31FFFF;為了避免引導程序被誤擦除而不能進行應用程序刷新的情況,給Bootloader代碼分配單獨的一塊FLASH空間A,地址從0x338000到0x33FFFF;應用程序是否有效等信息占據(jù)另一塊單獨的FLASH空間B,地址從0x330000到0x337FFF。
雷達系統(tǒng)上電復位后,首先運行在Bootloader中,根據(jù)車廠要求,可設置在Bootloader中需要停留的時間Tstay,Tstay時間后,讀取FLASH中的應用程序有效標志,若應用程序有效則跳轉到應用程序,否則一直運行在Bootloader中。
3.2 下位機Bootloader流程
ISO15765-3中對刷新流程及相關診斷服務進行了定義,不同車廠可能對其有些許改動,一般的刷新流程依次為:進入刷新模式、安全校驗、擦除、請求數(shù)據(jù)傳輸、傳輸程序數(shù)據(jù)、請求退出傳輸、程序一致性校驗、復位。
下位機Bootloader程序的整體流程如圖1所示。下位機Bootloader在CAN中斷中接收刷新上位機發(fā)送的診斷報文,報文的解析與響應的組裝由診斷服務處理模塊執(zhí)行。對于擦除、傳輸程序數(shù)據(jù)以及程序一致性校驗服務,診斷服務處理模塊只是分別發(fā)起對FLASH的擦除、寫以及校驗請求,真正的擦寫、校驗操作由FLASH任務管理模塊執(zhí)行。
3.3 主從通訊管理
主從通訊管理模塊是為了實現(xiàn)主從雷達的交互,若檢測到從雷達的存在,主雷達則在自身軟件升級成功后將刷新數(shù)據(jù)傳遞給從雷達。
該模塊的功能是依據(jù)主從屬性執(zhí)行各自的狀態(tài)機函數(shù),在Bootloader中接收到診斷報文的雷達模塊將自身設為“主”,主雷達的主從交互狀態(tài)機狀態(tài)就會從“空閑”切換到“發(fā)送復位命令”,通過私有CAN發(fā)送數(shù)個控制報文(報文頭為0x00)幀(若從雷達收到該報文,會從應用程序跳到Bootloader,并回饋響應報文),發(fā)送完成后狀態(tài)機自動切換到“等待復位響應”,主從雷達交互邏輯如圖2所示。
主雷達在“等待復位的響應”狀態(tài)只停留1s,若在這期間內收到控制信息幀的響應報文,主從交互狀態(tài)機就會從“等待復位響應”切換到“空閑”,否則狀態(tài)機切換到“刷新成功”,主從屬性設為“單一”,表明只有一個雷達存在,該系統(tǒng)為前碰撞預警系統(tǒng)。
主雷達檢驗程序一致性成功才會開始做刷新數(shù)據(jù)傳輸?shù)臏蕚涔ぷ鳎瑢⒅鲝慕换顟B(tài)機直接切換到“請求FLASH數(shù)據(jù)傳輸”。該狀態(tài)下,主雷達將存儲應用程序代碼的各連續(xù)FLASH塊的起始地址、大小和總的連續(xù)數(shù)據(jù)塊個數(shù)發(fā)給從雷達。從雷達收到“請求FLASH數(shù)據(jù)傳輸”命令后,會對當前的下載條件進行檢查,檢查成功才會反饋正響應,同時,從雷達第一次收到該命令時還會擦除存儲應用程序的所有FLASH區(qū)域。
“開始發(fā)送FLASH數(shù)據(jù)”“FLASH數(shù)據(jù)發(fā)送中”“等待傳輸FLASH數(shù)據(jù)的響應”三個狀態(tài)配合完成一個連續(xù)數(shù)據(jù)塊的刷新數(shù)據(jù)的發(fā)送,“開始發(fā)送FLASH數(shù)據(jù)”狀態(tài)下發(fā)送數(shù)據(jù)報文,每發(fā)送100幀數(shù)據(jù)報文就會進入“等待數(shù)據(jù)發(fā)送響應”狀態(tài)等待從雷達將800個字節(jié)成功寫入FLASH的響應,數(shù)據(jù)的分包傳輸保證了傳輸?shù)挠行?,一方面能避免因一次性?shù)據(jù)傳輸過多導致的從雷達寫FLASH時間久而錯失后續(xù)的數(shù)據(jù)報文,另一方面,若出現(xiàn)丟幀或者從雷達未能及時處理這些報文,主雷達能及時發(fā)現(xiàn),進而中止傳輸。
刷新數(shù)據(jù)全部傳輸完畢后,狀態(tài)機會轉到“發(fā)送校驗命令”,主雷達發(fā)送校驗命令幀,從雷達收到該報文會進行全部刷新數(shù)據(jù)的校驗。
主雷達收到從雷達校驗成功的響應報文就會將狀態(tài)機切換到“刷新成功”,此時,主雷達才會給刷新上位機回饋校驗程序一致性成功的正響應報文,進而結束整個系統(tǒng)的軟件升級過程。
主從雷達交互的整個過程中,若從雷達在某一階段未能成功往后執(zhí)行,如接收到的FLASH數(shù)據(jù)塊起始地址不正確、未成功寫入FLASH等,均會回饋一條“負響應”報文。
4 CAN Bootloader的上位機實現(xiàn)
上位機主要配合下位機完成HEX格式的升級文件的下載,主要模塊構成如下:
1)文件加載模塊:為了保證升級系統(tǒng)的適用性,該模塊應能解析任意的符合HEX標準格式的文件。需要解析出的內容包括連續(xù)數(shù)據(jù)塊個數(shù)、各數(shù)據(jù)塊的起始地址、數(shù)據(jù)長度以及每個數(shù)據(jù)塊的有效數(shù)據(jù)。
2)網(wǎng)絡狀態(tài)管理模塊:網(wǎng)絡狀態(tài)分為主狀態(tài)和子狀態(tài),主狀態(tài)包括多幀發(fā)送/接收、單幀發(fā)送/接收、空閑和超時,為了滿足ISO15765標準,每個主狀態(tài)根據(jù)當前報文類型(首幀、流控幀、連續(xù)幀)又進行了劃分。
網(wǎng)絡狀態(tài)管理模塊根據(jù)當前主/子狀態(tài)類型、網(wǎng)絡定時器是否超時來切換主狀態(tài),同時重設網(wǎng)絡定時器以及子狀態(tài),以保證請求中各幀的有序發(fā)送以及響應的接收。
3)報文接收處理模塊:Can模塊每次只接收一幀報文,報文接收處理模塊需要根據(jù)報文類型(單幀、首幀、連續(xù)幀、流控幀)切換網(wǎng)絡狀態(tài),與網(wǎng)絡狀態(tài)管理模塊配合完成請求與響應的發(fā)送和接收。
4)響應處理模塊:負責處理響應報文,同時也是下一條請求發(fā)送前的預處理。
若收到的是0x78負響應,不做任何處理,重新設置響應接收超時時間后繼續(xù)等待下一條響應。
為了避免接收到的報文并非上次請求對應的響應、響應格式錯誤等問題,每一條請求服務都事先設定了正確的響應內容,若收到的響應內容與設定不符,則清除本次所有請求服務序列、恢復網(wǎng)絡狀態(tài)至空閑,同時提示用戶。
每條請求都對應一個響應處理函數(shù)的接口,該函數(shù)有可能是對本次響應進行解析,也有可能是填充下一條請求報文內容。若響應內容正確,則根據(jù)請求直接進入與之對應的響應處理函數(shù)。例如收到請求傳輸?shù)捻憫缶涂梢愿鶕?jù)響應中最大塊數(shù)據(jù)長度以及本次計劃傳輸?shù)倪B續(xù)數(shù)據(jù)塊大小計算后續(xù)需要的傳輸程序數(shù)據(jù)請求的個數(shù),根據(jù)文件加載模塊讀取的有效數(shù)據(jù)填充這些傳輸數(shù)據(jù)請求,并確定與之對應的響應,同時確定收到正確響應后的回調函數(shù),即計算數(shù)據(jù)傳輸進度。
5 結束語
本文基于車載毫米波雷達對應用程序更新的需求,提出了一套基于UDS的Bootloader方案,該方案不僅適用于單個雷達的前碰撞預警系統(tǒng),也適用于兩個雷達的盲區(qū)監(jiān)測系統(tǒng)。測試表明,開發(fā)的Bootloader能穩(wěn)定擦寫FLASH,正確下載應用程序,能很好地應用在兩種雷達系統(tǒng)中。
參考文獻:
[1] 李華俊.盲區(qū)監(jiān)測變道輔助系統(tǒng)標定方法的研究[J].汽車電器,2017(9):7-11.
[2] 楊勝兵,萬宏偉,薛冰,等.基于CCP協(xié)議的車載控制器軟件刷新系統(tǒng)設計[J].自動化與儀表,2017,32(7):39-44.
[3] 樂志國,金啟前.電動汽車整車控制器 BootLoader 功能開發(fā)[J].佳木斯大學學報(自然科學版),2014,32(2):237-241,261.
[4] 汪春華,白穩(wěn)峰,劉胤博,等.基于CAN總線UDS服務BootLoader應用開發(fā)[J].電子測量技術,2017,40(2):166-170.
[5] 張卿杰,徐友,左楠.手把手教你學DSP:基于TMS320F28335[M].北京:北京航空航天大學出版社,2015.
【通聯(lián)編輯:謝媛媛】