公眾號前面幾篇文章，筆者已經對FOTA、SOTA、信息安全等內容進行了系統性的綜述。從本期開始，筆者將開設技術專欄，分別對上述主題展開更詳細、深入的介紹，以饗讀者，也期望在和同行的交流中碰撞出更四射的火花。

首先推出的是FOTA技術專欄，專欄第一篇文章，筆者將介紹整車部分控制器FOTA技術實現所需仰賴的底層技術之一：UDS刷寫。

UDS刷寫簡述

UDS（Unified Diagnostic Services，統一診斷服務）刷寫，指的是基于應用層協議（ISO 14229)和網絡層協議（與通信物理層相關，如面對CAN總線的ISO 15765-2）定義的控制器軟件升級流程。

UDS刷寫應用對象一般為采用ETH/CAN/LIN等總線通訊的車載傳統控制器。車載傳統控制器主芯片以MCU為主，MCU上主要運行嵌入式實時操作系統。UDS刷寫主要是通過診斷上位機（Tester）給車載傳統控制器發送定義好的診斷服務命令實現。

與車載傳統控制器相對應的是存在高算力芯片的控制器，民間常稱之為智能控制器。此類控制器一般存在雙分區結構且具有滿足POSIX標準的操作系統（一般為Android、QNX或Linux等），其軟件升級流程一般自主實現，本文介紹的UDS刷寫技術暫不適用此類控制器。

UDS線下刷寫的應用歷史已有幾十年，最典型的應用場景是在4S店。帥氣的技師們扛著電腦或者專用的診斷儀對車輛控制器進行軟件升級便是UDS線下刷寫的最生動體現。在這一場景中，電腦或診斷儀作為上位機，通過車輛OBD口接入整車網絡總線，并將升級包（一般為hex，s19格式）按主機廠定義的的刷寫流程對車輛控制器進行刷寫。

UDS線上刷寫的應用伴隨著FOTA技術的成熟而得到不斷推廣。在FOTA的通用技術架構下，一般由FOTA的升級主控（升級Master）作為上位機，升級主控從云端下載升級包，并按照固定的刷寫流程或者升級包中配置的刷寫流程，對車輛上的對手件進行刷寫。

UDS刷寫無論線下還是線上，都離不開控制器中Bootloader以及UDS協議的支持，在正式介紹UDS刷寫流程之前，筆者先簡介上述兩部分內容。

Bootloader

Bootloader稱為引導加載程序，是軟件執行的第一步，無論是否使用操作系統，Bootloader都是必須執行的。

我們日常辦公電腦中的Windows系統是由BIOS引導啟動的，BIOS開機自檢并分配資源后，將Bootloader 讀到系統的內存中。隨后Bootloader獲取電腦控制權，將指針帶到系統內核，開始啟動操作系統。

上文介紹的車載傳統控制器啟動過程同樣離不開Bootloader的幫助。Bootloader初始化硬件設備，建立內存空間映射圖，將系統的軟硬件環境帶到一個合適狀態，以便為最終調用操作系統內核準備好正確的環境。在控制器軟件升級過程中，Bootloader進入編程會話后會擦除指定地址的程序，并寫入新的程序，從而實現控制器的軟件升級，后文會詳細闡述該過程。

UDS協議

UDS協議就是ISO 14229標準的別名，全稱為統一診斷服務的應用層協議，標準規范了基于Bootloader的刷寫過程。各家主機廠均是基于UDS協議制定企業的診斷刷寫規范，在控制器的SOR階段會一同釋放給供應商。

對于各控制器的供應商而言，刷寫流程的統一簡化了開發復雜度。UDS協議可在不同的汽車網絡通信（例如CAN、LIN、 Flexray、 Ethernet 和 K-line）上實現，最常用的為UDSonCAN和UDSonIP（DoIP）兩種。下圖為ISO 14229中各車內總線實現UDS協議的網絡模型圖。

以UDSonCAN舉例， CAN總線協議是汽車內最常使用的總線協議，每幀僅有8字節，ISO 15765-2解決了ISO 11898協議中定義的經典CAN數據鏈路層與ISO 14229協議中定義的應用層數據長度不一致的問題。ISO 15765-2中定義的內容包括網絡層和傳輸層的協議，包括尋址方式（物理尋址、功能尋址），組包方式、協議控制信息、流量控制以及時間控制。

UDS協議是一種交互協議，呈現一問一答的通信方式，提供了26種服務，各服務在報文中通過SID（Service Identifier，診斷服務ID）來區分。在UDS刷寫流程中，主要應用的服務如下表所示。

10/27/11/3E等服務是基礎診斷和通信相關服務，作用是切換系統的會話模式、安全模式解鎖、重啟ECU以及保持鏈接活躍；

22/2E讀寫DID的服務主要是為了讀取版本號、VIN等信息，同時寫入諸如指紋、VIN碼等相關信息（OEM自定義）；

85/28服務主要是為了暫停其他控制器網絡報文的發送和DTC的設置，使得刷寫條件和網絡帶寬能達到最佳的狀態；

31/34/36/37則是數據下載相關服務，負責數據下載的請求、傳輸和退出。

UDS刷寫流程

會話模式是診斷領域非常重要的一個狀態機，不同的會話模式是用來區分診斷服務執行權限。UDS協議定義了三種會話模式：默認會話、編程會話、擴展會話，不同的會話模式可以相互切換。在Application中可使用默認會話模式和擴展會話模式。在Bootloader中可使用默認會話模式和刷新會話模式。

會話切換流程如下圖所示，主要通過0x10服務在三種會話模式之間切換。

UDS刷寫流程包括三部分：預編程階段、主編程階段和后編程階段，如下圖所示。其中，白色框步驟為功能尋址，藍色框步驟為物理尋址。各家主機廠會根據實際情況對方案進行微調。其中Client為升級客戶端，往往由診斷儀或FOTA master擔任。Server指的是升級控制器端。

一、預編程階段

此階段是刷寫前的網絡準備工作，主要內容包括（1）檢查升級前置條件；（2）提高刷寫網絡速度；（3）禁止其他ECU的網絡報文并關閉DTC設置。

1、Client功能尋址發送0x10服務將所有控制器切換至擴展會話模式，以支持0x85服務和0x28服務；

2、Client物理尋址發送0x31服務至Server，判斷當前是否滿足升級的前置條件，如點火狀態，車速等判斷；

3、Client功能尋址發送0x85和0x28服務，禁用CAN總線上各Server的網絡報文和DTC設置；

4、Client通過0x22服務讀取控制器的DID數據；

5、Client在會話過程中通過0x3E服務保持與Server的會話模式

二、主編程階段

此階段是控制器的刷寫主流程，在Bootloader的編程會話模式下進行，步驟如下：

1、Client功能尋址發送0x10服務將待刷寫的Server切換到編程會話模式；

2、Client通過0x2E服務將指紋寫入Server，例如本次刷寫人的身份；

3、Client通過0x27服務向Server求安全模式的seed，并根據約定的算法得到key，Server驗證通過后解鎖安全模式。安全模式的作用是以防電控單元被意外地擦除或未經授權地刷新；

4、Client通過0x31服務擦除Server指定地址段的程序；

5、Client通過0x34服務請求數據下載，Server回復一次0x36服務傳輸數據的Block的最多字節數；

6、如果0x34服務得到了正確響應，Client就開始使用0x36服務啟動數據傳輸。下載的數據是連續的，可使用34-36-36…-37命令實現。如果數據不連續，則需要重新進行0x34服務；

7、所有的0x36服務完成后，Client通過0x37服務請求退出傳輸；

8、Client通過0x31服務不同的子功能對程序的完整性和一致性進行驗證；

9、校驗完成后0x11服務對Server復位。

三、后編程階段

1、Client通過0x10服務恢復控制器的默認會話；

2、Client通過0x14服務清除Server中的故障碼，整個刷寫流程結束。

多路并行刷寫

當前FOTA升級的一般策略是串行升級，即每個控制器升級完成后再對下一個控制器進行升級，單一時間只對一個控制器進行升級。如任務中有多個車輛控制器需要升級，則會對本次任務的升級時長和車輛電瓶電量提出挑戰。如果能夠在FOTA中并行刷寫多個控制器，充分利用總線帶寬，可減少OTA升級時長，實現整車的快速升級。

因此，并行刷寫在FOTA的應用引起了各家主機廠的關注。產線的線下診斷儀刷寫其實已實現了并行刷寫，優勢在于可縮減產線的工位數，并提高生產效率。當前并行刷寫常用的做法為上位機開啟多個刷寫線程。不同總線間的并行刷寫相對容易實現，如同時對CAN總線上的控制器和車載以太網上的控制器在同一時間進行刷寫，總線之間的干擾并不大。

而對連接在同一網關下，不同路CAN上的兩個控制器進行刷寫，如Body CAN和Info CAN上的控制器并行刷寫。上位機開啟多個線程并且打開多個CAN通道 ，可通過通道號的不同對每個控制器進行識別，防止報文傳輸過程中不同控制器的報文相互沖突造成的報文混亂問題，實現了一上位機對多控制器的CAN報文傳輸。

與此同時，雖然開辟更多的RAM去處理診斷指令可以使得刷寫速率更快，但是資源開銷問題也不容小視。尤其當總線轉換時，傳輸層和網絡層的資源開銷也會上升。上位機的RAM資源的消耗，處理能力足夠與否，都需要O主機廠按實際情況和需求評估。

小結

本期簡單介紹了UDS刷寫的基礎知識，下一期，FOTA技術專欄將會介紹智能控制器常用的升級方式，A/B升級（汽車OTA領域的標桿企業ABup，其英文名稱前兩個字母寓意也來源于此）。

往期精彩：

FOTA信息安全，一篇看不懂的綜述

SOTA技術概述

車聯網信息安全概述