作者 | 小豆
小編 | 不吃豬頭肉

背景
在現(xiàn)代汽車(chē)電子技術(shù)中，ECU（電子控制單元）的軟件升級(jí)是一項(xiàng)關(guān)鍵任務(wù)。為了提高數(shù)據(jù)傳輸?shù)男屎桶踩?，壓縮刷寫(xiě)技術(shù)應(yīng)運(yùn)而生。通過(guò)數(shù)據(jù)壓縮傳輸，我們可以有效地增加帶寬利用率，減少刷寫(xiě)工具與ECU之間的數(shù)據(jù)傳輸量，從而顯著縮短ECU升級(jí)時(shí)間。此外，為了加強(qiáng)數(shù)據(jù)的安全性和保密性，數(shù)據(jù)傳輸還可以進(jìn)行加密處理。在ISO14229-1規(guī)范中，請(qǐng)求下載服務(wù)（SID=0x34）和請(qǐng)求文件傳輸服務(wù)（0x38）定義了數(shù)據(jù)可以基于壓縮和加密的方式進(jìn)行傳輸。本文以請(qǐng)求下載服務(wù)為例重點(diǎn)介紹數(shù)據(jù)壓縮部分。ISO14229-1：2020規(guī)范中定義請(qǐng)求下載服務(wù)（0x34）的請(qǐng)求報(bào)文格式
根據(jù)ISO14229-1：2020規(guī)范，請(qǐng)求下載服務(wù)（0x34）允許數(shù)據(jù)通過(guò)壓縮和加密的方式進(jìn)行傳輸。在該服務(wù)的請(qǐng)求報(bào)文格式中，”dataFormatIdentifier“是一個(gè)關(guān)鍵的參數(shù)，大小為1個(gè)字節(jié)，其中高四位（bit4-bit7）為參數(shù)”compressionMethod“，定義數(shù)據(jù)是否需要壓縮, 其中低四位（bit0-bit3）為參數(shù)”encryptingMethod“，定義數(shù)據(jù)是否需要加密。若下載的數(shù)據(jù)既不需要壓縮也不需要加密，則該參數(shù)值為0x00，若使用非0x00的值，則表示下載數(shù)據(jù)需要進(jìn)行壓縮、加密，或二者兼有。如”dataFormatIdentifier“此值為0x10，表示下載數(shù)據(jù)需要壓縮不需要加密，如”dataFormatIdentifier“此值為0x11，表示下載數(shù)據(jù)需要壓縮也需要加密。

值得注意的是，下載數(shù)據(jù)的壓縮與加密需求并不影響參數(shù)”addressAndLengthFormatIdentifier

“和”memoryAddress“，但會(huì)影響”memorySize“參數(shù)，該參數(shù)定義了需要刷寫(xiě)數(shù)據(jù)的大小，這個(gè)大小將與通過(guò)TransferData（0x36）服務(wù)傳輸?shù)臄?shù)據(jù)大小進(jìn)行比較。

當(dāng)下載的數(shù)據(jù)是壓縮數(shù)據(jù)時(shí)，由OEM來(lái)定義”memorySize“代表的是壓縮數(shù)據(jù)的大小還是壓縮前數(shù)據(jù)的大小。不同的定義對(duì)于刷寫(xiě)流程的實(shí)現(xiàn)代碼也不相同。
若”memorySize“代表壓縮數(shù)據(jù)的大小，那么當(dāng)TransferData（0x36）服務(wù)將壓縮數(shù)據(jù)傳輸完成后，ECU將根據(jù)“memorySize”參數(shù)來(lái)判斷數(shù)據(jù)是否下載完成，ECU會(huì)比較傳輸?shù)膲嚎s數(shù)據(jù)與”memorySize“參數(shù)定義的數(shù)據(jù)大小是否一致，并相應(yīng)地發(fā)送肯定或否定響應(yīng)。
若”memorySize“代表非壓縮數(shù)據(jù)的大小，那么TransferData（0x36）服務(wù)傳輸?shù)膲嚎s數(shù)據(jù)大小一般小于”memorySize“的值。這時(shí)ECU將接收到的壓縮數(shù)據(jù)解壓，并計(jì)算所有解壓后數(shù)據(jù)大小的總和。在壓縮數(shù)據(jù)傳輸完成后，ECU會(huì)比較解壓后的數(shù)據(jù)大小與”memorySize“參數(shù)定義的數(shù)據(jù)大小是否一致，并相應(yīng)地發(fā)送肯定或否定響應(yīng)。
當(dāng)然，對(duì)于”memorySize“代表壓縮數(shù)據(jù)的大小還是非壓縮數(shù)據(jù)大小，數(shù)據(jù)傳輸完成后ECU判斷下載數(shù)據(jù)是否正確的方法各OEM定義也不盡相同。壓縮前后刷寫(xiě)文件比對(duì)
軟件刷寫(xiě)是指將軟件程序燒錄或者通過(guò)UDS刷寫(xiě)傳輸?shù)紼CU芯片內(nèi)存的特定地址段，然后ECU就會(huì)運(yùn)行該軟件程序，去實(shí)現(xiàn)其特有的功能。常用的ECU刷寫(xiě)文件格式有：.hex，.s19和.bin等。壓縮刷寫(xiě)文件是通過(guò)特定的壓縮算法制作而成。
壓縮前：

刷寫(xiě)文件分3個(gè)邏輯塊，各塊起始地址、結(jié)束地址、長(zhǎng)度為：

Block0：起始地址：0x80138020 結(jié)束地址：0x801FFFDF 長(zhǎng)度：0xC7FC0

Block1：起始地址：0x80300020 結(jié)束地址：0x804FFFDF 長(zhǎng)度：0x1FFFC0

Block2：起始地址：0xA0078020 結(jié)束地址：0xA0137FFF 長(zhǎng)度：0xBFFE0

壓縮后：

壓縮后刷寫(xiě)文件仍分3個(gè)邏輯塊，各塊起始地址、結(jié)束地址、長(zhǎng)度為：

Block0：起始地址：0x80138020 結(jié)束地址：0x8015E60E 長(zhǎng)度：0x265EF

Block1：起始地址：0x80300020 結(jié)束地址：0x80448DD7 長(zhǎng)度：0x148DB8

Block2：起始地址：0xA0078020 結(jié)束地址：0xA00AD0F6 長(zhǎng)度：0x350D7

可以發(fā)現(xiàn)，壓縮前后的刷寫(xiě)文件邏輯塊數(shù)量未變化，起始地址未變化，各邏輯塊的數(shù)據(jù)長(zhǎng)度變小了，對(duì)應(yīng)的結(jié)束地址也產(chǎn)生了變化。每個(gè)邏輯塊獨(dú)立壓縮
對(duì)于壓縮前刷寫(xiě)文件中分為多個(gè)邏輯塊，在壓縮之后的邏輯塊數(shù)量未發(fā)生變化的情況可稱(chēng)之為“每個(gè)邏輯塊獨(dú)立壓縮”。與之不同，也存在“整體壓縮”的方式。
整體壓縮
壓縮前：

刷寫(xiě)文件分3個(gè)邏輯塊，各塊起始地址、結(jié)束地址、長(zhǎng)度為：

Block0：起始地址：0x8FC0060 結(jié)束地址：0x9194FFF 長(zhǎng)度：0x1D4FA0

Block1：起始地址：0x91C0000 結(jié)束地址：0x91D9EBF 長(zhǎng)度：0x19EC0

Block2：起始地址：0x9200000 結(jié)束地址：0x9237FFF 長(zhǎng)度：0x38000

壓縮后：

壓縮后刷寫(xiě)文件只有1個(gè)邏輯塊，無(wú)起始地址。

對(duì)于“整體壓縮方式”，刷寫(xiě)流程中內(nèi)存擦除（EarseMemmory）服務(wù)和0x34（RequestDownload）服務(wù)中起始地址等信息由ECU供應(yīng)商或者OEM定義。壓縮刷寫(xiě)日志分析
非壓縮刷寫(xiě)日志:
壓縮刷寫(xiě)日志：

通過(guò)分析刷寫(xiě)日志，我們可以發(fā)現(xiàn)壓縮刷寫(xiě)與非壓縮刷寫(xiě)的主要區(qū)別在于：1.請(qǐng)求下載服務(wù)（SID=0x34）指令參數(shù)（dataFormatIdentifier）不同。

非壓縮：刷寫(xiě)工具發(fā)送：34 00 44 A0 07 80 00 00 10 00 01

壓縮：刷寫(xiě)工具發(fā)送：34 10 44 A0 07 80 00 00 03 50 F7

其中10代表：使用壓縮數(shù)據(jù)；00代表：使用非壓縮數(shù)據(jù)。
2.請(qǐng)求下載服務(wù)（SID=0x34）指令參數(shù)（memorySize）不同。

非壓縮刷寫(xiě)：刷寫(xiě)工具發(fā)送：34 00 44 A0 07 80 00 00 10 00 01

壓縮刷寫(xiě)：刷寫(xiě)工具發(fā)送：34 10 44 A0 07 80 00 00 03 50 F7

非壓縮刷寫(xiě)中請(qǐng)求下載服務(wù)（SID=0x34）中memorySize大小大于壓縮刷寫(xiě)中的memorySize大小，如果最大塊長(zhǎng)度值一致，則對(duì)于后續(xù)數(shù)據(jù)傳輸服務(wù)（SID=0x36）的個(gè)數(shù)，壓縮刷寫(xiě)則要小于非壓縮刷寫(xiě)。

如日志中壓縮刷寫(xiě)與非壓縮刷寫(xiě)最大塊長(zhǎng)度值皆為0xFFF,可計(jì)算出：

非壓縮刷寫(xiě)后續(xù)數(shù)據(jù)傳輸服務(wù)（SID=0x36）的個(gè)數(shù)為257個(gè)；

壓縮刷寫(xiě)后續(xù)數(shù)據(jù)傳輸服務(wù)（SID=0x36）的個(gè)數(shù)為54個(gè)；

數(shù)據(jù)傳輸服務(wù)（SID=0x36）的個(gè)數(shù)越少，則所需數(shù)據(jù)傳輸?shù)臅r(shí)間也就越少，這也就是壓縮刷寫(xiě)可以提升刷寫(xiě)效率的主要原因。總結(jié)
隨著ECU軟件功能的日益復(fù)雜，提高ECU軟件升級(jí)效率變得尤為重要，Bootloader作為一項(xiàng)必不可少的功能軟件，其高效的刷寫(xiě)方式是實(shí)現(xiàn)ECU軟件更新的關(guān)鍵。目前，北匯信息已經(jīng)完成壓縮刷寫(xiě)測(cè)試方案的落地，期待與感興趣的朋友進(jìn)行交流合作。