文章來(lái)源1.浙江吉利新能源商用車發(fā)展有限公司客車事業(yè)部2.浙江吉利新能源商用車集團(tuán)有限公司商用車研究院

客車特別是電動(dòng)客車正向著智能網(wǎng)聯(lián)化快速發(fā)展，客車智能網(wǎng)聯(lián)化要求其具備OTA（OvertheAirTechnology，OTA）功能，從而實(shí)現(xiàn)對(duì)車載系統(tǒng)軟件和數(shù)據(jù)的及時(shí)升級(jí)和管控，提高售后服務(wù)的效率和品質(zhì)。

當(dāng)前主流客車CAN網(wǎng)絡(luò)上的各控制器軟硬件配置差異較大，很多控制器不支持在乘用車領(lǐng)域早已推廣的UDS診斷協(xié)議，需要進(jìn)行有針對(duì)性的差異化設(shè)計(jì)，以滿足當(dāng)前客車對(duì)OTA的需求。本文首先論述OTA實(shí)施的3項(xiàng)關(guān)鍵技術(shù)，然后就客車CAN通信設(shè)計(jì)進(jìn)行分析。

1OTA關(guān)鍵技術(shù)

1.1OTA系統(tǒng)及其平臺(tái)職責(zé)OTA是云端-車端協(xié)同工作的系統(tǒng)，主要由云端的OTA管理平臺(tái)以及車端的無(wú)線接收控制器組成。二者通過(guò)無(wú)線網(wǎng)絡(luò)連接，共同完成車輛的OTA任務(wù)。OTA管理平臺(tái)需能夠設(shè)定多控制器的軟件下載順序、軟件版本登記、當(dāng)前軟件版本號(hào)識(shí)別、目標(biāo)軟件版本號(hào)確認(rèn)、控制器既有軟件備份、新軟件加密傳輸、下載失敗整體回滾等設(shè)定。
OTA管理平臺(tái)一般采用面向服務(wù)的3層體系架構(gòu)設(shè)計(jì)：人機(jī)交互層、業(yè)務(wù)邏輯層和數(shù)據(jù)訪問(wèn)層。人機(jī)交互層為管理員提供了OTA的操作頁(yè)面，如權(quán)限管理、車輛信息管理、下載策略管理、下載任務(wù)管理等。

1.2安全傳輸和安全訪問(wèn)OTA源于個(gè)人移動(dòng)通信終端業(yè)務(wù)，該技術(shù)應(yīng)用在汽車，特別是客車，其功能安全就需要更嚴(yán)格的標(biāo)準(zhǔn)，例如要求支持TLS1.2及以上安全協(xié)議，支持第三方的安全證書和密鑰管理，最終實(shí)現(xiàn)從后臺(tái)到車端的多層級(jí)全方位的防護(hù)。軟件從供應(yīng)商到達(dá)OTA平臺(tái)、OTA平臺(tái)到車端以及車端ECU本身都需采用不同類型的加密機(jī)制來(lái)確保OTA服務(wù)全程安全。在執(zhí)行任何OTA服務(wù)相關(guān)操作之前，需完成OTA云端與OTA車輛端的雙向認(rèn)證。OTA車輛端和OTA云端之間的所有數(shù)據(jù)通信必須有完整檢查機(jī)制和防篡改檢查機(jī)制，過(guò)程傳輸數(shù)據(jù)要進(jìn)行加密，避免OTA服務(wù)實(shí)施成為整車安全的薄弱環(huán)節(jié)。
軟件被下載到車輛終端之前，OTA云端和車端控制器首先根據(jù)PKI/CA認(rèn)證系統(tǒng)進(jìn)行身份雙向認(rèn)證。驗(yàn)證通過(guò)后，OTA服務(wù)端和車端建立起基于TLS1.2協(xié)議的安全通道，保證云端與車端之間信息傳輸?shù)陌踩訹4]。在車端部分，TBOX、HMI和網(wǎng)關(guān)控制器之間的交互信息采用私有協(xié)議密文傳輸，軟件包的加解密通過(guò)在TBOX、HMI和網(wǎng)關(guān)控制器內(nèi)部集成的HSM（硬件安全模塊）來(lái)管理、處理和保存加密秘鑰，防止軟件包被篡改。

1.3統(tǒng)一軟件刷新標(biāo)準(zhǔn)OTA的核心服務(wù)是完成車載控制器的軟件更新，不同控制器的程序更新使用同一個(gè)軟件診斷刷新規(guī)范是提高OTA運(yùn)行效率和降低OTA服務(wù)成本的必然選擇。ISO14229基于UDS診斷規(guī)范，應(yīng)用于多種數(shù)據(jù)鏈路網(wǎng)絡(luò)，是目前廣泛應(yīng)用的診斷協(xié)議標(biāo)準(zhǔn)，國(guó)內(nèi)主流電動(dòng)客車用控制器如CATL的BMS、主機(jī)廠自研的整車控制器以及匯川MCU基本都支持UDS的診斷刷新服務(wù)。

常見的ECU刷寫文件格式有：Hex、s19、bin等。無(wú)論是哪種格式，這些文件都會(huì)包含：存儲(chǔ)地址、數(shù)據(jù)、校驗(yàn)和（checksum）、記錄類型和記錄長(zhǎng)度信息。IS014229規(guī)范關(guān)于程序更新定義的幾項(xiàng)基本刷寫步驟是：①請(qǐng)求例程控制；②請(qǐng)求下載；③數(shù)據(jù)傳輸；④請(qǐng)求數(shù)據(jù)傳輸退出并驗(yàn)證校驗(yàn)。

2客車端OTA相關(guān)的通信設(shè)計(jì)
客車電動(dòng)化已成為一個(gè)明顯趨勢(shì)，本章節(jié)以電動(dòng)客車為研究對(duì)象，以O(shè)TA需求為中心，針對(duì)電動(dòng)客車網(wǎng)絡(luò)通信從網(wǎng)絡(luò)拓?fù)?、網(wǎng)絡(luò)管理以及人機(jī)交互設(shè)置3方面重點(diǎn)進(jìn)行分析。目前主流電動(dòng)客車的整車CAN網(wǎng)絡(luò)架構(gòu)（網(wǎng)絡(luò)拓?fù)?、通信協(xié)議、控制器CPU算力及存儲(chǔ)能力等）相對(duì)于傳統(tǒng)燃油客車并未完成徹底轉(zhuǎn)型，使得一些近年來(lái)在乘用車領(lǐng)域迅速推廣的智能技術(shù)未能在電動(dòng)客車上得到切實(shí)應(yīng)用，如自動(dòng)導(dǎo)航、輔助駕駛和OTA等。其中OTA技術(shù)的實(shí)施，迫切需要客車網(wǎng)絡(luò)通信系統(tǒng)進(jìn)行升級(jí)設(shè)計(jì)。
2.1客車CAN網(wǎng)絡(luò)拓?fù)湓O(shè)計(jì)2.1.1當(dāng)前客車車載網(wǎng)絡(luò)拓?fù)洮F(xiàn)狀當(dāng)前電動(dòng)客車常見的CAN網(wǎng)絡(luò)拓?fù)涫腔诠δ苡蜻M(jìn)行設(shè)計(jì)，即將功能關(guān)系較為緊密的控制器規(guī)劃在一個(gè)網(wǎng)段，整車網(wǎng)絡(luò)拓?fù)浯蠖嗍荲CU集成網(wǎng)關(guān)或設(shè)置中央網(wǎng)關(guān)控制器的多路通信拓?fù)洹＿@種網(wǎng)絡(luò)拓?fù)鋵?duì)于早期電動(dòng)客車是相對(duì)可靠和實(shí)用的。
2.1.2當(dāng)前客車車載網(wǎng)絡(luò)拓?fù)洳蛔慊贠TA的智能技術(shù)的實(shí)施和更高級(jí)的軟件刷新服務(wù)產(chǎn)生，使得當(dāng)前基于功能域設(shè)計(jì)的網(wǎng)絡(luò)拓?fù)渲饾u暴露出短板，如控制器節(jié)點(diǎn)多、功能重疊，造成軟件反復(fù)開發(fā)升級(jí)，硬件資源冗余或無(wú)拓展性。一個(gè)臨時(shí)的策略是增加網(wǎng)段來(lái)安放新增的控制器，例如增設(shè)底盤域來(lái)布置EPS和EPB。但隨著整車配置和客戶需求的變化，相應(yīng)的VCU或網(wǎng)關(guān)控制器的程序便需要配合更新，如果增加儀表周邊的智能化設(shè)備，例如電子后視鏡和ADAS，對(duì)程序的更新需求會(huì)迅速增加，同時(shí)對(duì)硬件的需求也會(huì)更高，控制器數(shù)量的增加還會(huì)導(dǎo)致CAN線長(zhǎng)度逐漸接近限值。
2.1.3融合域控制器的網(wǎng)絡(luò)拓?fù)湓O(shè)計(jì)自動(dòng)駕駛技術(shù)要求OTA服務(wù)更穩(wěn)定流暢高效，以便及時(shí)關(guān)閉軟件中的漏洞并實(shí)現(xiàn)更好的客戶體驗(yàn)，本著高效刷新的原則，傳統(tǒng)零散的單一功能控制器會(huì)逐漸被高集成度的域控制器所取代，同時(shí)自動(dòng)駕駛技術(shù)要求不同域之間的通信更緊密，比如底盤域和動(dòng)力域，動(dòng)力域和車身域。NAVALE等指出駕駛輔助域和動(dòng)力域也會(huì)因?yàn)橥ㄐ诺脑龆喽饾u融合，相應(yīng)功能的不斷豐富，演變成為整車行駛控制域。
本文提出面向服務(wù)的軟件設(shè)計(jì)思想，自上而下建立整車3級(jí)網(wǎng)絡(luò)拓?fù)洌尤胗蚩刂破鳎≒DC&BDC），車載高性能計(jì)算機(jī)（HPC）的角色，同時(shí)結(jié)合客車的布置特征，加入空間域的設(shè)計(jì)方法，形成一種兼容性強(qiáng)、靈活可靠的網(wǎng)絡(luò)拓?fù)洹?br /> 如圖1所示，車端選擇TBOX作為OTA升級(jí)的主控控制器，該控制器集成OTA升級(jí)的主控程序UC（UpdateControl），作為汽車端升級(jí)控制的主體與OTA平臺(tái)側(cè)進(jìn)行數(shù)據(jù)通信，并控制整車其他控制器完成OTA升級(jí)活動(dòng)。TBOX對(duì)整車主要服務(wù)有：本地ECU配置信息的采集和上報(bào)、與OTA管理平臺(tái)交互獲得升級(jí)策略文件、目標(biāo)升級(jí)包的下載、升級(jí)包安全性和完整性校驗(yàn)、按照升級(jí)策略文件逐個(gè)進(jìn)行升級(jí)包分發(fā)和目標(biāo)ECU升級(jí)流程的發(fā)起、升級(jí)過(guò)程的記錄及上報(bào)、升級(jí)過(guò)程中與HMI的交互。

部分控制器的軟件包較大，通過(guò)CAN通信傳輸時(shí)間較長(zhǎng)，OTA數(shù)據(jù)傳輸介質(zhì)需要考慮更高效的非CAN通道的數(shù)據(jù)傳輸方式，如圖1中人機(jī)交互界面的程序升級(jí)設(shè)計(jì)了LVDS的數(shù)據(jù)傳輸辦法。
2.2整車網(wǎng)絡(luò)管理設(shè)計(jì)2.2.1OTA對(duì)整車網(wǎng)絡(luò)管理的需求一般OTA要求其所服務(wù)的控制器統(tǒng)一支持基于UDS的診斷刷新協(xié)議，要求整車進(jìn)行OTA之前，同網(wǎng)段ECU實(shí)現(xiàn)以下需求。
1）接收UDS診斷服務(wù)指令，實(shí)現(xiàn)應(yīng)用層通信的關(guān)閉，包含但不限于關(guān)閉常規(guī)應(yīng)用報(bào)文和網(wǎng)絡(luò)管理報(bào)文。
2）接收UDS診斷服務(wù)指令，停止或者恢復(fù)診斷故障代碼的檢測(cè)和記錄，包含但不限于關(guān)閉常規(guī)應(yīng)用報(bào)文和網(wǎng)絡(luò)管理報(bào)文。
2.2.2非UDS控制器網(wǎng)絡(luò)管理的設(shè)計(jì)客車生產(chǎn)設(shè)計(jì)往往存在客戶對(duì)部分電氣配置的指定，難以實(shí)現(xiàn)統(tǒng)一支持UDS協(xié)議，為使支持UDS的控制器能夠穩(wěn)定實(shí)施OTA服務(wù)，需采取措施來(lái)避免非UDS協(xié)議的控制器在OTA過(guò)程中的通信沖突。電動(dòng)客車部分控制器的喚醒條件如下。
1）整車上下電流程強(qiáng)關(guān)聯(lián)控制器：VCU、BMS、低壓配電盒等，其喚醒條件一般有充電信號(hào)有效、ON擋電有效。
2）客戶指定件：胎壓監(jiān)測(cè)、電子駐車等，其喚醒條件一般是ON擋電有效。
3）儀表總線模塊和公交調(diào)度系統(tǒng)一般要求ACC電即喚醒工作。
對(duì)于與整車上下電流程強(qiáng)關(guān)聯(lián)的非UDS控制器，通過(guò)補(bǔ)充CAN通信協(xié)議建立UDS需求的OTA通信管制和DTC管制。對(duì)于客戶指定的與整車上下電無(wú)關(guān)聯(lián)的一般電器件，可以統(tǒng)一由BCM對(duì)其電源進(jìn)行邏輯控制實(shí)現(xiàn)UDS需求的通信管制和DTC管制，該方案的實(shí)施需要控制器配合程序修改和BCM配電邏輯的定向開發(fā)。
2.2.3預(yù)約升級(jí)場(chǎng)景下的網(wǎng)絡(luò)管理預(yù)約升級(jí)場(chǎng)景中，TBOX需支持遠(yuǎn)程喚醒功能，在預(yù)約時(shí)間到時(shí)遠(yuǎn)程喚醒TBOX并判斷車輛OTA前置條件均通過(guò)后，啟動(dòng)升級(jí)流程對(duì)目標(biāo)控制器進(jìn)行升級(jí)。對(duì)于控制器不具備在整車OFF擋時(shí)被喚醒刷寫升級(jí)的，需TBOX喚醒BCM并提供ON擋電，在ON擋電狀態(tài)下完成刷寫升級(jí)。升級(jí)過(guò)程中BCM需限制車內(nèi)大功率用電負(fù)荷如空調(diào)、前照燈等，避免24V蓄電池電量消耗過(guò)快導(dǎo)致OTA服務(wù)中斷。
2.3OTA升級(jí)人機(jī)交互OTA人機(jī)交互界面是用戶執(zhí)行OTA升級(jí)流程的操作入口，通常將OTA的升級(jí)界面設(shè)計(jì)在整車HMI端。升級(jí)界面的內(nèi)容包含升級(jí)任務(wù)通知、升級(jí)前置條件確認(rèn)、免責(zé)條款告知、軟件下載、確認(rèn)安裝等主要流程。整車端的OTA升級(jí)的交互流程如圖2所示，圖2流程中，確認(rèn)下載和前置條件步驟需用戶手動(dòng)確認(rèn)，其余為程序自動(dòng)。前置條件選項(xiàng)可能會(huì)需要用戶反復(fù)操作以確保整車按標(biāo)準(zhǔn)流程完成程序升級(jí)，為避免用戶在確認(rèn)升級(jí)后誤斷鑰匙電或一鍵下低壓電造成控制器升級(jí)異常，OTA模式下BCM模塊會(huì)強(qiáng)制整車ON擋電，強(qiáng)制時(shí)間一般不超過(guò)30min，VCU會(huì)自動(dòng)完成高壓回路的斷電處理，期間如用戶因緊急情況需中斷升級(jí)可以通過(guò)整車總閘斷電處理，后臺(tái)將記錄升級(jí)日志并及時(shí)向客戶反饋異常中斷原因并告知其系統(tǒng)風(fēng)險(xiǎn)。

3結(jié)束語(yǔ)
OTA技術(shù)是客車智能網(wǎng)聯(lián)化的必經(jīng)之路，本文介紹了OTA實(shí)施的關(guān)鍵技術(shù)，論述了一種電動(dòng)客車OTA實(shí)現(xiàn)方案，并分析了電動(dòng)客車實(shí)施OTA需要考慮的CAN通信技術(shù)，為電動(dòng)客車OTA系統(tǒng)設(shè)計(jì)提供了參考。