李英凱，王志海，張方偉，廖中華，楊 超

（浙江吉智新能源汽車科技有限公司，浙江 杭州 518034）

隨著車輛向電氣化方向發(fā)展，整車控制器數(shù)量及代碼量越來越多。再加上FOTA功能在國(guó)內(nèi)越來越受到重視，如何縮短整車程序更新時(shí)間變得越來越重要。本文結(jié)合影響程序更新的因素，從工程化角度分析適用性。

1 影響因素說明

1.1 網(wǎng)絡(luò)帶寬

程序更新作為短時(shí)大數(shù)量傳輸?shù)膽?yīng)用，加大車載網(wǎng)絡(luò)帶寬是最有效的方式。這涉及到整車網(wǎng)絡(luò)架構(gòu)調(diào)整，而且由于網(wǎng)絡(luò)連接的特殊性，必定導(dǎo)致多控制器甚至整車所有控制器變更，難度頗大。

從具體網(wǎng)絡(luò)類型來說，CAN、CANFD、Ethernet-T1均為整車主流應(yīng)用方案。以博世公司發(fā)布的整車電子電器架構(gòu)發(fā)展方向說明Ethernet-T1大概率成為整車主干網(wǎng)，CAN、CANFD構(gòu)成域內(nèi)子網(wǎng)。如圖1所示。

圖1 博世發(fā)布的EE架構(gòu)發(fā)展預(yù)測(cè)

從程序更新效率出發(fā)，域內(nèi)子網(wǎng)往往是限制更新速度的關(guān)鍵。就CAN而言，目前市場(chǎng)主流車型多采取125、250、500kb／s三種速率。為了提升程序更新效率，架構(gòu)設(shè)計(jì)工程師對(duì)CAN線波特率應(yīng)首選500kb／s，逐步放棄較低的波特率。

CANFD作為CAN的升級(jí)版通信方式，其優(yōu)點(diǎn)明顯，主機(jī)廠引入方便。但考慮車型歷史包袱、供應(yīng)商資源等限制，整車切換的案例并不多見。FD tolerant節(jié)點(diǎn)和FD節(jié)點(diǎn)混合組網(wǎng)，在車輛正常工作時(shí)其用CAN報(bào)文通信，在程序更新時(shí)對(duì)支持CANFD的節(jié)點(diǎn)切換為FD通信，如此可在整車提前上一兩個(gè)CANFD節(jié)點(diǎn)，既可驗(yàn)證技術(shù)成熟度又方便后期其余節(jié)點(diǎn)逐步向FD切換，不失為一個(gè)過渡方案。

1.2 程序更新流量負(fù)載率

程序更新流量負(fù)載率加大多受限于網(wǎng)關(guān)路由能力、更新節(jié)點(diǎn)報(bào)文接收能力、Tester節(jié)點(diǎn)報(bào)文發(fā)送能力等。項(xiàng)目推進(jìn)過程中需對(duì)路由節(jié)點(diǎn)、節(jié)點(diǎn)報(bào)文接收能力提出明確要求，不出現(xiàn)幀顛倒、丟幀的情況，以此保證較高負(fù)載率下的更新成功率。

1.3 有效載荷

此主要是針對(duì)目前主流程序更新方案依賴于診斷服務(wù)實(shí)現(xiàn)。在CAN／CANFD環(huán)境下由15765封裝UDS服務(wù)，在Ethernet環(huán)境下為13400封裝UDS服務(wù)。有效載荷加大主要有兩方面，一為分配塊大小時(shí)考慮將每幀報(bào)文占滿，另一方面為約定控制器接收塊大小的下限。前者是考慮不出現(xiàn)填充字節(jié)，后者為杜絕頻繁發(fā)起數(shù)據(jù)傳輸請(qǐng)求、格式字節(jié)及等待應(yīng)答造成的時(shí)間浪費(fèi)。

1.4 Bootloader獨(dú)立的網(wǎng)絡(luò)層時(shí)間參數(shù)

有別于Application的應(yīng)用場(chǎng)景，Bootloader應(yīng)獨(dú)立定義比Application更快的時(shí)間參數(shù)。以CAN節(jié)點(diǎn)為例，STmin參數(shù)在Bootloader的定義多快于Application。

1.5 并行更新

并行更新主要用于車內(nèi)多域之間、同一域多網(wǎng)段之間，由于網(wǎng)絡(luò)的獨(dú)立性，依靠路由節(jié)點(diǎn)對(duì)多網(wǎng)段同時(shí)更新。此方案主要應(yīng)用于主干網(wǎng)帶寬明顯高于各子網(wǎng)時(shí)，依靠多子網(wǎng)并行，提高主干網(wǎng)利用率，節(jié)約時(shí)間。

從工程角度，此方案應(yīng)用的前提是將控制器程序更新Tester功能轉(zhuǎn)移到網(wǎng)關(guān)控制器。另需將信息安全機(jī)制同步轉(zhuǎn)移。以一典型FOTA方案說明，圖示見圖2。

1.6 同步處理

此處主要針對(duì)控制器對(duì)燒寫報(bào)文的接收與Flash寫入做同步處理。不再等待完整多幀報(bào)文接收完再傳遞到應(yīng)用程序處理，變更為接收一幀處理一幀。需要注意不同芯片對(duì)Flash操作的最小字節(jié)數(shù)目不一致，控制器要協(xié)調(diào)好報(bào)文流有效數(shù)據(jù)與Flash操作之間的關(guān)系。此方式也有助于減少控制器對(duì)接收Buffer的要求，有助于增大1.3部分提到的塊大小。除Flash操作外，校驗(yàn)部分同樣適用于同步處理。具體項(xiàng)目而言，對(duì)于單一控制器采取同步處理還是串行處理應(yīng)實(shí)際測(cè)試后作出決定。以CAN更新為例，圖3表示燒寫報(bào)文流接收與Flash操作之間的關(guān)系。

圖2 典型FOTA方案框圖

圖3 報(bào)文流與Flash寫入關(guān)系

1.7 壓縮升級(jí)

在數(shù)據(jù)傳送前對(duì)數(shù)據(jù)進(jìn)行壓縮并在控制器內(nèi)完成數(shù)據(jù)解壓還原，以此達(dá)到減少數(shù)據(jù)傳輸?shù)哪康?。?yīng)用場(chǎng)景決定了壓縮算法必須選取無損壓縮且契合逐幀接收、逐幀解壓的特點(diǎn)。

但在工程應(yīng)用時(shí)，由于解壓操作是在控制器內(nèi)部完成，壓縮比、解壓效率、RAM消耗是選取解壓算法的重要指標(biāo)。解壓效率上限受制于1.6部分提到的同步處理，即報(bào)文接收到執(zhí)行解壓、寫Flash，其操作完成時(shí)間應(yīng)早于下一幀報(bào)文?；谧值涞膲嚎s方式 （LZSS、LZMA等）都可以是壓縮算法的備選方案，項(xiàng)目開展應(yīng)根據(jù)控制器實(shí)際情況評(píng)估。

另外需補(bǔ)充一點(diǎn)，由于壓縮升級(jí)方案其釋放升級(jí)文件為壓縮后的數(shù)據(jù)，其地址信息、長(zhǎng)度與控制器解壓完地址信息、長(zhǎng)度不對(duì)應(yīng)。燒寫流程中應(yīng)說明控制器內(nèi)存起始地址、控制器內(nèi)解壓后數(shù)據(jù)長(zhǎng)度、壓縮數(shù)據(jù)長(zhǎng)度的位置。以ISO14229-1 2013定義刷寫流程為例，在擦除內(nèi)存命令使用控制器實(shí)際內(nèi)存起始地址、實(shí)際長(zhǎng)度，請(qǐng)求下載命令使用實(shí)際起始地址和壓縮后數(shù)據(jù)長(zhǎng)度。

圖4中SW Part 1示意為非壓縮升級(jí)，SW Part 2示意為壓縮升級(jí)。非壓縮升級(jí) （SW Part 1）的刷寫文件Data Block與控制器內(nèi)存儲(chǔ)地址一一對(duì)應(yīng)。壓縮升級(jí) （SW Part 2）的控制器內(nèi)Data Block明顯大于刷寫文件Compressed Data Block，其通過刷寫文件Compressed Data Block與控制器內(nèi)對(duì)應(yīng)Data Block起始地址相同，確定Data Block位置，長(zhǎng)度信息通過后續(xù)的校驗(yàn)命令確認(rèn)。

圖4 壓縮升級(jí)在控制器內(nèi)內(nèi)存對(duì)應(yīng)示意

1.8 增量升級(jí)

增量升級(jí)是進(jìn)一步減小升級(jí)文件的手段，一般配合壓縮一起使用，進(jìn)一步減少需傳遞的文件大小。增量更新從模型上可以描述為目標(biāo)升級(jí)文件和原文件通過對(duì)比獲取差異信息包，控制器內(nèi)部將差異信息與原文件計(jì)算獲得目標(biāo)文件，完成升級(jí)。

由于車載控制器多為嵌入式系統(tǒng)，更新過程中并無太多富余的Flash存儲(chǔ)完整差異信息、備份完整的原文件信息，但控制器內(nèi)原文件為查分計(jì)算的基礎(chǔ)，故常見于通過在Flash上分配一塊備份區(qū)間，分批次對(duì)原文件所占內(nèi)存空間進(jìn)行更新。示例見圖5。

圖5 增量升級(jí)框圖示意

2 結(jié)論與建議

增加帶寬、負(fù)載率、有效載荷及調(diào)整網(wǎng)絡(luò)層時(shí)間參數(shù)通過提升更新數(shù)據(jù)的傳遞速度提升更新效率。并行更新和同步處理旨在將程序更新的串行動(dòng)作改變?yōu)椴⑿袆?dòng)作，壓縮升級(jí)和增量升級(jí)則將目光集中于縮小升級(jí)包大小。對(duì)于后者由于和控制器硬件關(guān)聯(lián)性較大，更多時(shí)候?yàn)橹鳈C(jī)廠提出技術(shù)方向各個(gè)零部件供應(yīng)商結(jié)合實(shí)際考慮實(shí)現(xiàn)方式。

實(shí)際項(xiàng)目過程中，為提升程序更新效率，往往多個(gè)方案共同應(yīng)用。通過多種手段將控制器更新時(shí)間控制在需求之下。