李英凱,王志海,張方偉,廖中華,楊 超
(浙江吉智新能源汽車科技有限公司,浙江 杭州 518034)
隨著車輛向電氣化方向發(fā)展,整車控制器數量及代碼量越來越多。再加上FOTA功能在國內越來越受到重視,如何縮短整車程序更新時間變得越來越重要。本文結合影響程序更新的因素,從工程化角度分析適用性。
程序更新作為短時大數量傳輸的應用,加大車載網絡帶寬是最有效的方式。這涉及到整車網絡架構調整,而且由于網絡連接的特殊性,必定導致多控制器甚至整車所有控制器變更,難度頗大。
從具體網絡類型來說,CAN、CANFD、Ethernet-T1均為整車主流應用方案。以博世公司發(fā)布的整車電子電器架構發(fā)展方向說明Ethernet-T1大概率成為整車主干網,CAN、CANFD構成域內子網。如圖1所示。

圖1 博世發(fā)布的EE架構發(fā)展預測
從程序更新效率出發(fā),域內子網往往是限制更新速度的關鍵。就CAN而言,目前市場主流車型多采取125、250、500kb/s三種速率。為了提升程序更新效率,架構設計工程師對CAN線波特率應首選500kb/s,逐步放棄較低的波特率。
CANFD作為CAN的升級版通信方式,其優(yōu)點明顯,主機廠引入方便。但考慮車型歷史包袱、供應商資源等限制,整車切換的案例并不多見。FD tolerant節(jié)點和FD節(jié)點混合組網,在車輛正常工作時其用CAN報文通信,在程序更新時對支持CANFD的節(jié)點切換為FD通信,如此可在整車提前上一兩個CANFD節(jié)點,既可驗證技術成熟度又方便后期其余節(jié)點逐步向FD切換,不失為一個過渡方案。
程序更新流量負載率加大多受限于網關路由能力、更新節(jié)點報文接收能力、Tester節(jié)點報文發(fā)送能力等。項目推進過程中需對路由節(jié)點、節(jié)點報文接收能力提出明確要求,不出現幀顛倒、丟幀的情況,以此保證較高負載率下的更新成功率。
此主要是針對目前主流程序更新方案依賴于診斷服務實現。在CAN/CANFD環(huán)境下由15765封裝UDS服務,在Ethernet環(huán)境下為13400封裝UDS服務。有效載荷加大主要有兩方面,一為分配塊大小時考慮將每幀報文占滿,另一方面為約定控制器接收塊大小的下限。前者是考慮不出現填充字節(jié),后者為杜絕頻繁發(fā)起數據傳輸請求、格式字節(jié)及等待應答造成的時間浪費。
有別于Application的應用場景,Bootloader應獨立定義比Application更快的時間參數。以CAN節(jié)點為例,STmin參數在Bootloader的定義多快于Application。
并行更新主要用于車內多域之間、同一域多網段之間,由于網絡的獨立性,依靠路由節(jié)點對多網段同時更新。此方案主要應用于主干網帶寬明顯高于各子網時,依靠多子網并行,提高主干網利用率,節(jié)約時間。
從工程角度,此方案應用的前提是將控制器程序更新Tester功能轉移到網關控制器。另需將信息安全機制同步轉移。以一典型FOTA方案說明,圖示見圖2。
此處主要針對控制器對燒寫報文的接收與Flash寫入做同步處理。不再等待完整多幀報文接收完再傳遞到應用程序處理,變更為接收一幀處理一幀。需要注意不同芯片對Flash操作的最小字節(jié)數目不一致,控制器要協調好報文流有效數據與Flash操作之間的關系。此方式也有助于減少控制器對接收Buffer的要求,有助于增大1.3部分提到的塊大小。除Flash操作外,校驗部分同樣適用于同步處理。具體項目而言,對于單一控制器采取同步處理還是串行處理應實際測試后作出決定。以CAN更新為例,圖3表示燒寫報文流接收與Flash操作之間的關系。

圖2 典型FOTA方案框圖

圖3 報文流與Flash寫入關系
在數據傳送前對數據進行壓縮并在控制器內完成數據解壓還原,以此達到減少數據傳輸的目的。應用場景決定了壓縮算法必須選取無損壓縮且契合逐幀接收、逐幀解壓的特點。
但在工程應用時,由于解壓操作是在控制器內部完成,壓縮比、解壓效率、RAM消耗是選取解壓算法的重要指標。解壓效率上限受制于1.6部分提到的同步處理,即報文接收到執(zhí)行解壓、寫Flash,其操作完成時間應早于下一幀報文?;谧值涞膲嚎s方式 (LZSS、LZMA等)都可以是壓縮算法的備選方案,項目開展應根據控制器實際情況評估。
另外需補充一點,由于壓縮升級方案其釋放升級文件為壓縮后的數據,其地址信息、長度與控制器解壓完地址信息、長度不對應。燒寫流程中應說明控制器內存起始地址、控制器內解壓后數據長度、壓縮數據長度的位置。以ISO14229-1 2013定義刷寫流程為例,在擦除內存命令使用控制器實際內存起始地址、實際長度,請求下載命令使用實際起始地址和壓縮后數據長度。
圖4中SW Part 1示意為非壓縮升級,SW Part 2示意為壓縮升級。非壓縮升級 (SW Part 1)的刷寫文件Data Block與控制器內存儲地址一一對應。壓縮升級 (SW Part 2)的控制器內Data Block明顯大于刷寫文件Compressed Data Block,其通過刷寫文件Compressed Data Block與控制器內對應Data Block起始地址相同,確定Data Block位置,長度信息通過后續(xù)的校驗命令確認。

圖4 壓縮升級在控制器內內存對應示意
增量升級是進一步減小升級文件的手段,一般配合壓縮一起使用,進一步減少需傳遞的文件大小。增量更新從模型上可以描述為目標升級文件和原文件通過對比獲取差異信息包,控制器內部將差異信息與原文件計算獲得目標文件,完成升級。
由于車載控制器多為嵌入式系統,更新過程中并無太多富余的Flash存儲完整差異信息、備份完整的原文件信息,但控制器內原文件為查分計算的基礎,故常見于通過在Flash上分配一塊備份區(qū)間,分批次對原文件所占內存空間進行更新。示例見圖5。

圖5 增量升級框圖示意
增加帶寬、負載率、有效載荷及調整網絡層時間參數通過提升更新數據的傳遞速度提升更新效率。并行更新和同步處理旨在將程序更新的串行動作改變?yōu)椴⑿袆幼?,壓縮升級和增量升級則將目光集中于縮小升級包大小。對于后者由于和控制器硬件關聯性較大,更多時候為主機廠提出技術方向各個零部件供應商結合實際考慮實現方式。
實際項目過程中,為提升程序更新效率,往往多個方案共同應用。通過多種手段將控制器更新時間控制在需求之下。