來源 | 汽車ECU開發(fā)
汽車OTA最早出現(xiàn)是在2012年，特斯拉推出的Modes S首次采用OTA技術(shù)，更新范圍包括人機交互、自動駕駛、動力電池系統(tǒng)等模塊，當時特斯拉可以通過OTA完成鑰匙卡漏洞、提升續(xù)航里程、提高最高速度、提升乘坐舒適度等，讓車的功能迭代更加靈活和便捷。隨后，國內(nèi)的蔚來、理想、小鵬、比亞迪等也陸續(xù)推出了可以實現(xiàn)OTA的車型?，F(xiàn)如今，OTA升級，已不是新能源車型的“專屬”，部分傳統(tǒng)燃油車也可以實現(xiàn)，OTA技術(shù)開始被豐田、福特、大眾、寶馬等傳統(tǒng)車企所嘗試。隨著越來越多的智能功能的加入，汽車行業(yè)漸漸形成“無OTA不智能”的科技風向。
系統(tǒng)功能設計
OTA 系統(tǒng)功能示意如圖1示，系統(tǒng)包含網(wǎng)關、 智能天線、車用防火墻、 ADAS 攝像頭、 ADAS 域控制器、 座艙域控制器、以及 OTA 平臺。
OTA 平臺端具備車輛管理、車型管理、軟件版本管理以及任務的發(fā)布和推送的能力。平臺端也具備管理的屬性，包括賬號體系、權(quán)限體系等，支持 OEM 的不同部門、不同科室、不同職能工程師在平臺上實施 OTA 相關操作，并查看 OTA 任務執(zhí)行情況。其中推送的軟件包的格式采用 UCM 定義的格式。
智能天線通過車載以太網(wǎng)、 BT、 BLE、 Wi-Fi、 3G/4G 實現(xiàn)了車身控制、遠程控制、遠程診斷、 OTA 功能。在AUTOSAR OTA Demo 系統(tǒng)中， 智能天線負責與 OTA 云端認證、通信；負責所有控制器升級文件下載、驗簽、備份；負責所有控制器升級條件檢測、升級策略執(zhí)行；負責控制器升級文件解析。
車用防火墻執(zhí)行網(wǎng)絡安全隔離，禁止越權(quán)訪問；車載防火墻策略管理、動態(tài)更新；對域間數(shù)據(jù)交互提供安全防護機制；邊界入侵防御檢測等功能。
座艙域控制器中的 HMI 界面用于整個系統(tǒng)升級流程的人機交互即升級控制操作和升級狀態(tài)信息顯示。座艙域控制器中的升級應用程序，與 AUTOSA 自適應平臺架構(gòu)中的 CM（通訊管理） 、 DM（診斷管理） 、 UCM（更新配置管理） 模塊相配合完成系統(tǒng)中各模塊升級的管控。
ADAS 攝像頭傳感器，接收網(wǎng)關轉(zhuǎn)發(fā)的 UDS 報文， 解析加密升級包， 執(zhí)行 CRC 校驗，并支持斷點續(xù)傳升級。ADAS 域控制器通過 OTA 持續(xù)升級， 優(yōu)化不在法律法規(guī)范圍內(nèi)行人/車輛表現(xiàn)、 新增商用車車型及新交通標志的感知識別、優(yōu)化功能控制邏輯及增加新的自動駕駛特性等。
網(wǎng)關負責將座艙域控制器、 ADAS 域控制器、 車用防火墻組成以太網(wǎng)相結(jié)合的局域網(wǎng)絡，保證了各模塊之間安全可靠的數(shù)據(jù)通信， 并將以太網(wǎng)數(shù)據(jù)與 CAN 報文進行協(xié)議轉(zhuǎn)換，連接車用防火墻與 ADAS 攝像頭。
整個系統(tǒng)的升級邏輯過程如下圖 2所示。
網(wǎng)絡拓撲設計
系統(tǒng)的網(wǎng)絡拓撲如圖3所示。OTA 平臺與智能天線之間采用 4G 網(wǎng)絡通訊。智能天線與網(wǎng)關通過以太網(wǎng)進行連接，通訊協(xié)議采用 SOME/IP 及 DoIP 協(xié)議。以太網(wǎng)使用 100Base-T1 的車載以太網(wǎng)標準。網(wǎng)關使用了 1 路 CAN 接口和 3 路 Ethernet 接口，其中 CAN 總線的通訊速率為 500Kbit/s，以太網(wǎng)總線的通訊速率為 100Mbit/s。其中 CAN 總線連接網(wǎng)關與 ADAS 攝像頭。網(wǎng)關通過將智能天線的 DoIP 診斷報文轉(zhuǎn)換為 UDS on CAN 診斷報文，來對 ADAS 攝像頭進行刷新。
圖 3 OTA 演示系統(tǒng)網(wǎng)絡拓撲示意
OTA平臺
AUTOSAR OTA Demo 項目中構(gòu)建了一個固件、 APP、分區(qū)、配置等升級方案，通過平臺端配置軟件包，推送給到車端。接收到軟件包后，車端將自動執(zhí)行平臺配置的升級策略，從而實現(xiàn)對不同 ECU 上的軟件進行安裝管理。AUTOSAR AP 上的 UCM 標準定義，規(guī)范了軟件包的格式、管理以及發(fā)布流程。艾拉比憑借自身平臺端的特點和 AP 的優(yōu)點，對方案進行了整合，對平臺端的軟件包的格式和車端的軟件安裝管理流程做了重新的改造，構(gòu)建了一套能夠適應 AUTOSAR 的軟件升級流程。整合后，該方案可以同時適應 AUTOSAR 和非AUTOSAR的平臺
OTA 平臺架構(gòu)如圖4所示， 包括車輛管理、車型管理、軟件版本管理以及任務的發(fā)布和推送的能力。平臺端也具備管理的屬性，包括賬號體系、權(quán)限體系等，支持 OEM 的不同部門、不同科室、不同職能工程師在平臺上實施 OTA 相關操作，并查看 OTA 任務執(zhí)行情況。
車云間的管道借助 4G、 HTTPS、 MQTT、 CDN 等互聯(lián)網(wǎng)領域的成熟通信技術(shù)，一方面確保通訊符合信息安全規(guī)范；另一方面借助高帶寬、網(wǎng)絡分發(fā)技術(shù)，提高軟件包觸達到每一輛車的概率，確保輛車都能得到 OTA 服務。
OTA 升級可以分為三個階段，即生成更新包、傳輸更新包、安裝更新，整個階段通過網(wǎng)絡通信鏈接，最終實現(xiàn)終端代碼和數(shù)據(jù)的更新，進而改善終端的功能和服務。其中，更新包采用 AUTOSAR 自適應平臺的 UCM 中的規(guī)范。
UCM 輸入的安裝單位是軟件包，如圖5所示。該軟件包包含（ Container）一個或多個可執(zhí)行文件。除了應用程序和配置數(shù)據(jù)外，每個軟件包都包含一個軟件包 Manifest，該 Manifest 提供源數(shù)據(jù)，例如軟件包名稱、 版本、 依賴關系以及特定的供應商信息，以便用戶根據(jù)該信息制定特殊的處理方式。
智能天線
智能天線是基于 Broad-Reach 技術(shù)開發(fā)的智能以太網(wǎng)鯊魚鰭天線模塊,集成了 Tuner、GPS、 3G/4G/5G、 BT、 Wi-Fi、 BLE、 RKE、 TPMS 射頻模塊。智能天線把射頻數(shù)據(jù)轉(zhuǎn)換為數(shù)字信號，重新編碼后通過車載以太網(wǎng)與車內(nèi)各 ECU 通信，為各節(jié)點設備提供包括收音機服務、 定位/慣導服務、 遠程控制服務、4G/5G、 V2X 等多種接入服務。
在 OTA Demo 系統(tǒng)中，智能天線基于 AUTOSAR 自適應平臺開發(fā) OTA Client、 UCM、 CM、 DM 等軟件功能模塊，進而實現(xiàn)對系統(tǒng)中各模塊的升級管理。智能天線控制器軟件架構(gòu)如圖 6。
OTA Client 是升級的主控者，其一方面與 OTA 云服務器連接獲取升級信息和升級包，一方面與 UCM、 CM、DM 配合進行升級流程的管控。
CM 模塊主要用來實現(xiàn)智能天線與座艙域控制器之間的升級命令和升級狀態(tài)信息的傳輸。CM 是基于 SOA 的AUTOSAR 自適應平臺的一個核心功能模塊，負責分布式實時嵌入式環(huán)境中應用程序之間通信的方方面面，實現(xiàn)AUTOSAR 自適應平臺平臺應用各級之間面向服務的通信，包括進程內(nèi)、 進程間和 ECU 間的進程通信。CM 的主要功能有提供 Service、 Method、 Event、 Field 的相關 API， ECU 之間采用 SOME/IP 通信， 如圖7所示。
UCM 是 Update and Configuration Management 的縮寫，在 AUTOSAR AP 上屬于服務類型（平臺基礎服務），主要提供軟件升級和配置管理功能，通過 ara::com 提供軟件升級服務的訪問接口。
UCM 內(nèi)部由一個或多個類組成，如圖8所示，協(xié)同完成某一類的操作。PackageManager 是 UCM 服務的核心構(gòu)件，負責實現(xiàn) Spec 定義的各個功能接口，實現(xiàn)和客戶端的各種業(yè)務交互邏輯。其它組件是 PackageManager 的工具組件，被 PackageManager 使用以實現(xiàn)相應的基礎操作。Receiver 是 UCM PackageManager 用來完成升級包接收的組件，實現(xiàn)了升級包接收過程中的資源申請、 傳輸控制、 數(shù)據(jù)緩存、 包完整性校驗。
Extractor 是 PackageManager 用來實現(xiàn)對壓縮包進行提取的工具。Extractor 向 PackageManager 提供抽象接口，可實現(xiàn)對 zip 壓縮包的提取功能。
Parser 是 PackageManager 用來解析 Manifest 文件內(nèi)容，獲取軟件的依賴、 版本、 名稱、 校驗和， 引用等。Parser 同時用來解析平臺已安裝應用的版本、 名字等信息、 軟件包信息、 供客戶端獲取已安裝應用列表、 軟件包列表等。Parser 從軟件安裝路徑 (/opt/function/) 中讀application.json 文件，組織成 SoftClusterInfo。
Storage 是 PackageManager 用來處理存儲相關的操作的工具構(gòu)件，主要用于將緩存數(shù)據(jù)固化到 NVM，在軟件固化操作中不刪除原有數(shù)據(jù)，而是采用覆蓋方式。
Transaction 用于實現(xiàn)安裝后的激活和回退操作。在軟件安裝或升級后，重新啟動可能會遇到各種原因的錯誤，這時客戶端可以采取回退操作，將系統(tǒng)回退到安裝或升級之前的狀態(tài)。UCM 在客戶端調(diào)用 Activate 接口后，首先需要檢查應用的依賴，依賴檢查通過之后，調(diào)用 EM 接口依次啟動本次升級涉及的應用（ 該信息保存在升級包的 manifest 文件中） ，根據(jù) EM 的返回值判斷升級是否成功。在這個過程中只要有一個應用啟動出錯， UCM認為此次升級失敗，并將出錯信息報告給 Client。如果軟件激活全部成功，則激活完成， UCM 報告升級成功。
DM （ Diagnostic Management） 作為一個服務模塊，為 AUTOSAR AP 平臺提供診斷服務，對外通過 DoIP與診斷儀交互，對內(nèi)通過 ara::com 為需要被診斷的應用提供服務。DM 主要分成 DCM， DEM 兩個模塊。其中DCM（ Diagnostic Communication Management）主要負責診斷通信管理， 也就是 UDS 相關命令的處理。DEM（ Diagnostic Event Management）即診斷事件管理，主要負責軟件平臺內(nèi)部事件的處理。
在 AUTOSAR OTA Demo 系統(tǒng)中，使用 DM 進行升級包的診斷傳輸對其他設備進行升級，主要包括車輛發(fā)現(xiàn)， 建立連接， UDS 診斷三個過程，其實現(xiàn)細節(jié)如下：
車輛發(fā)現(xiàn)流程的目的是將節(jié)點的 DoIP 屬性告訴給當前局域網(wǎng)內(nèi)其它 DoIP 節(jié)點。其它 DoIP 節(jié)點可根據(jù)自己的業(yè)務需求，決定是否與其建立連接通訊。Server 有兩種方式將自己的 DoIP 屬性告訴給 Client：
a) 上電后，主動發(fā)送 3 次 vehicle announcement message，在消息中攜帶邏輯地址、 VIN、 EID 等信息，如圖9中 a 處所示；
b) 由 Client 在適當時機以廣播方式發(fā)送 vehicle identification request，收到該消息的 Server 以單播的形式回復 vehicle identification response 消息，其中攜帶邏輯地址、 VIN、 EID 等信息。如圖9中 b、c 處所示。
Client 與 Server，只有建立連接后，才能夠進行 UDS 通信，建立連接分為 3 個步驟：
a) Client 主動與 Server 建立 TCP 連接，如圖 10 中 a 處所示；
b) Client 發(fā)送 routing activation request 消息請求激活路由， Server 根據(jù)實際情況同意或者拒絕激活請求，激活結(jié)果通過發(fā)送 routing activation response 消息告知 Client，如圖10中 b 處所示；
c) 若 Client 與 Server 之前長時間沒通信， Server 會主動發(fā)送 alive check request 消息，檢測 Client 是否還正常工作，若 Client 沒有發(fā)送 alivecheck response 消息， Server 將斷開與 Client 建立好的連接，如圖10中 c 處所示。
Client 已經(jīng)通過車輛發(fā)現(xiàn)，獲得了當前局域網(wǎng)內(nèi)所有 DoIP 節(jié)點的信息，并且與所有的 DoIP 節(jié)點都已經(jīng)建立好連接， Client 可通過邏輯 ID、 VIN、 EID 以提前定義好的 UDS 升級流程對網(wǎng)絡中的某個節(jié)點發(fā)起升級包傳輸請求，如圖11所示。
不管 CAN 控制器還是 Ethernet 控制器， 軟件刷寫流程相同， 參見圖12。
1. 進入擴展診斷會話（ $10 03）：診斷設備通過功能尋址， 以 3s 的周期發(fā)送擴展模式請求報文（ $10 03），使 CAN 網(wǎng)絡中所有電控單元進入擴展診斷會話。
2. 刷寫條件檢查（ $31）：診斷設備通過物理尋址，發(fā)送例程控制服務（$31 01 02 03）， 檢查目標控制器是否滿足刷寫前提條件。
3. 禁止記錄 DTC（ $85）：診斷設備通過功能尋址， 使用 DTC 設置服（$85）， 禁止 CAN 網(wǎng)絡中的電控單元記錄 DTC。
4. 關閉通信（ $28）：診斷設備通過功能尋址， 使用通信控制服（$28），禁止 CAN 網(wǎng)絡中的電控單元發(fā)送和接收非診斷報文。
5. 進入編程會話（ $10 02）：診斷設備通過物理尋址，使電控單元進入編程會話。當應用程序在運行時，電控單元可以從應用程序跳轉(zhuǎn)至引導加載程序。
6. 安全訪問（ $27）：診斷設備通過物理尋址， 對電控單元進行安全訪問（$27），所有可刷寫的電控單元應支持安全訪問服務。
-
接收到另外一個安全訪問請求（不論請求格式、內(nèi)容、安全級別等是否有效）。
-
電控單元切換到另外一個診斷會話，或電控單元切換到相同的診斷會話。
-
-
-
7. 寫入指紋信息（ $2E F1 84）：診斷設備通過物理尋址寫入指紋信息到電控單元。
8. （可選） Flash 驅(qū)動刷寫：刷寫 Flash 驅(qū)動至電控單元中指定的 RAM 地址。刷寫序列由請求下載（ $34），數(shù)據(jù)傳輸（ $36） 和請求退出傳輸（ $37） 3 個服務請求組成。如果電控單元不需要刷寫 Flash 驅(qū)動，請?zhí)敛襟E 10 執(zhí)行。
9. （可選） 軟件 CRC32 校驗（ $31）：如果電控單元不需要刷寫 Flash 驅(qū)動，請?zhí)敛襟E 10 執(zhí)行。刷寫Flash 驅(qū)動完成后，診斷設備通過例程控制服務（ $31） 啟動校驗，診斷設備將電控單元計算的校驗值與設備端的校驗值相比較。若兩者相等，證明數(shù)據(jù)刷寫成功。
10. 擦除存儲器相應區(qū)域（ $31 FF 00）：該功能使用例程控制服務（ $31） 執(zhí)行存儲器擦除程序。該例程被調(diào)用前，請求擦除的邏輯塊的有效狀態(tài)位必須設為無效，防止刷寫過程沒有成功結(jié)束而意外執(zhí)行應用程序步驟。
11. 應用程序刷寫：刷寫應用程序至電控單元中指定的非易失性存儲器地址。刷寫序列由請求下載（ $34），數(shù)據(jù)傳輸（ $36） 和請求退出傳輸（ $37） 3 個服務請求組成。
12. 軟件 CRC32 校驗（ $31）詳情見步驟 9
13. 刷寫兼容性檢查。完成應用程序刷寫后，電控單元應執(zhí)行刷寫兼容性檢查， 并根據(jù)檢查結(jié)果更新軟件兼容性狀態(tài)參數(shù)。
14. 電控單元重啟（ $11）：電控單元通過硬件復位，擦除 RAM 中的 Flash 驅(qū)動代碼，并使應用程序生效。
15. 進入擴展會話（ $10）：診斷設備使用功能尋址，通過會話控制服務使所在 CAN 網(wǎng)絡的電控單元進入擴展會話。
16. 打開通信（ $28）：診斷設備通過功能尋址， 使用通信控制服務（$28） 使所在 CAN 網(wǎng)絡的電控單元恢復正常通信。
17. 打開記錄 DTC 功能（ $85）：診斷設備通過功能尋址， 打開記錄 DTC 功能。允許 CAN 網(wǎng)絡中連接的電控單元記錄 DTC。
18. 進入默認會話（ $10）：診斷設備使用功能尋址，通過會話控制服務使所在 CAN 網(wǎng)絡的電控單元進入默認會話。
車用防火墻
隨著車載網(wǎng)絡技術(shù)的迅速發(fā)展， 伴隨而來的網(wǎng)絡攻擊也日益嚴重， 車用防火墻作為一道網(wǎng)絡安全的屏障，可有效抵御來自外部的網(wǎng)絡攻擊。車用防火墻具備如下功能：
1、網(wǎng)絡安全隔離，禁止越權(quán)訪問
3、對域間數(shù)據(jù)交互提供安全防護機制
車用防火墻是基于由東軟睿馳自主研發(fā)的 Neusar aCore 基礎軟件開發(fā)的。NeuSAR aCore 是一套面向自動駕駛、 V2X 等應用能夠滿足高性能計算和高帶寬通訊的基礎軟件，全面支持 AUTOSAR 自適應平臺標準。圖 13展現(xiàn)了車用防火墻的軟件架構(gòu)。
圖13 NeuSAR aCore 基礎軟件架構(gòu)示意圖
在 OTA demo 系統(tǒng)中，各域控制器采用的升級方案都是基于 AUTOSAR 自適應平臺實現(xiàn)的。車用防火墻的OTA 升級策略是通過診斷傳輸升級包+UCM 的技術(shù)實現(xiàn)的。車用防火墻首先會接收到來自網(wǎng)關的車輛識別請求， 然后將自身信息（ 邏輯地址、 VIN 等） 反饋給網(wǎng)關， 網(wǎng)關就會保存和車用防火墻之間的連接信息。接下來網(wǎng)關會發(fā)送一系列用于準備升級的診斷請求，比如切換到編程會話下， 檢查域控制器是否滿足刷寫條件，安全訪問驗證等。在一切準備工作做好之后， 開始傳輸升級包， NeuSAR aCore 主要處理 3 種服務請求：
1、0x38RequestFileTransfer 服務， 將和升級有關的信息發(fā)送給域控制器，并等待域控制器反饋升級信息；
2、0x36TransferData 服務， 負責傳輸升級數(shù)據(jù)；
3、0x37RequestFileTransfer 服務，負責校驗數(shù)據(jù)傳輸是否完成。完成升級傳輸之后， 還會對升級文件的正確性和依賴性進行檢查。升級文件放置在特定位置，并通知 UCM 客戶端使用此文件進行更新；UCM 客戶端識別升級文件之后，會使用標準服務接口 PackageManagement 將軟件包傳輸給 UCM 服務端，并控制和管理 UCM 服務端的升級流程；UCM 服務端接收升級包后，在 UCM 客戶端的指導下，進行升級包的升級校驗、處理、激活等步驟。
圖14 NeuSAR aCore 診斷模塊功能框圖
如上所述， OTA 升級主要涉及兩大技術(shù)模塊：升級和配置管理（ UCM）和診斷（ DM）。Neusar aCore 中的UCM 功能集群用于安裝、更新和刪除應用程序。UCM 功能集群包括三個終端：升級包制作端、 UCM 服務端和UCM 客戶端。升級包制作端在編譯環(huán)境上，首先使用上位機配置升級包內(nèi)容，然后在編譯環(huán)境上制作出對應升級包，最后將升級包上傳到 UCM 客戶端（ OTA 平臺） 。UCM 客戶端負責控制和管理 UCM 服務端的升級流程，實現(xiàn)軟件升級，并獲取軟件包和升級過程的相關信息。UCM 服務端負責進行軟件升級的具體操作。NeuSAR aCore 中的診斷模塊使用基于車載以太網(wǎng)的診斷技術(shù) Diagnostics over Internet Protocol（ DoIP）和統(tǒng)一診斷服務 Unified Diagnostic Services（ UDS） 兩種協(xié)議。DoIP 協(xié)議就是通過網(wǎng)絡協(xié)議進行診斷通信，規(guī)定了測試設備與域控制器之間的診斷通信交互方式和報文格式。UDS 協(xié)議規(guī)定了一系列的診斷服務，比如讀取 DID、例程控制和域控制器刷寫等服務， 方便售后和產(chǎn)線人員查找和解決問題。圖14展示了NeuSARaCore 中診斷模塊的功能框架。
座艙域控制器與屏幕
OTA Demo 系統(tǒng)中，座艙域控制器中開發(fā)了 HMI 界面用于整個系統(tǒng)升級流程的人機交互即升級控制操作和升級狀態(tài)信息顯示。座艙域控制器中的升級應用程序，與 AUTOSAR 自適應平臺中的 CM、 DM、 UCM 模塊相配合完成系統(tǒng)中各模塊升級的管控。
升級應用程序通過 CM 模塊與智能天線中的 OTA Client 進行通信，實現(xiàn)升級應用程序向 OTA Client 發(fā)起升級相關的控制命令，同時獲取相應的狀態(tài)信息用于顯示在 HMI 中，智能天線中運行 SOME/IP 客戶端，域控制器中運行 SOME/IP 服務端，兩者之間通信的詳細過程如下：
服務發(fā)現(xiàn)的目的是將 SOME/IP 節(jié)點所提供服務的服務 ID、 實例 ID、 端口號、 IP 地址告知組播網(wǎng)絡里的其它SOME/IP 節(jié)點。其它 SOME/IP 節(jié)點，可根據(jù)自己的業(yè)務需求選擇是否跟該節(jié)點進行 SOME/IP 通信。Server有兩種方式將服務 ID、實例 ID 等信息告知 Client：
1、Server 以固定間隔時間，周期性的發(fā)送 offer service 消息，該消息中攜帶 服務 ID、實例 ID、端口號、IP 地址等信息，如圖16中 a 處所示。
2、由 Client 在適當時機以組播方式發(fā)送 request server 消息，收到該消息的 Server 以單播的形式回復offer service 消息，其中攜帶邏輯地址、 VIN、 EID 等信息。如圖16中 b、 c 處所示。
首先 IVI 需要先訂閱該 event 所在事件組， 如圖 2-18 中 a 處所示，然后 IVI 通過 method 向 Smart Antenna發(fā)起檢查更新請求， Smart Antenna 從 OTA Server 獲取是否有更新、更新包大小、版本號、發(fā)布描述信息等，并將這些信息通過 event 發(fā)送給 IVI， 如圖17中 b、 c 處所示。
首先 IVI 需要先訂閱該 event 所在事件組， 如圖 2-19 中 a 處所示，然后 IVI 通過 method 向 Smart Antenna發(fā)起下載更新包請求， Smart Antenna 從 OTA Server 下載更新包，并將下載狀態(tài)與進度通過 event 實時發(fā)送給 IVI， 如圖18中 b、 c、 d、 e 處所示。
首先 IVI 需要先訂閱該 event 所在事件組，如圖 2-20 a 處所示，然后 IVI 通過 method 向 Smart Antenna 發(fā)起安裝更新包請求， Smart Antenna 通過 DM 和 UCM 功能模塊對各個模塊進行升級，并將安裝狀態(tài)與進度通過 event 發(fā)送給 IVI， 如圖19中 b、 c、 d、 e 處所示。
升級應用程序通過 DM 模塊從 OTA Client 接收升級包，并將升級包傳輸給 UCM 模塊做具體的升級動作。座艙域控制器使用 UCM 的 Update 功能實現(xiàn)程序更新，其升級流程分為三個階段：數(shù)據(jù)包傳輸，數(shù)據(jù)包處理，激活。其各階段各狀態(tài)細節(jié)如下：
1. 升級應用程序調(diào)用 TransferStart 接口發(fā)起軟件包傳輸，進入到 Transferring。這一過程 UCM 為升級應用程序分配代表本次傳輸任務的 ID 識別碼，為接收軟件包預先申請資源，做好接收準備。TransferStart接口要求客戶端傳入要傳輸?shù)能浖拇笮 ?br style="outline: 0px;max-width: 100%;text-align: -webkit-auto;text-size-adjust: auto;box-sizing: border-box !important;overflow-wrap: break-word !important;">
2. 在 Transferring 狀態(tài)，升級應用程序調(diào)用 TransferData 接口傳輸數(shù)據(jù)，由于軟件包體積一般比較大，無法一次傳輸，所以需要將數(shù)據(jù)包分解成數(shù)據(jù)塊， TransferData 接口要求升級應用程序傳入該次傳輸?shù)臄?shù)據(jù)塊計數(shù)（ 1,2,3…）。
3. 升級應用程序調(diào)用 TransferExit 結(jié)束傳輸，如果此時 UCM 接收到的數(shù)據(jù)總和等于軟件包大小，則成功結(jié)束此次傳輸，進入到 Transferred 狀態(tài)，其它情況均為出錯，進入 Error 狀態(tài)。
4. 在 Transferred 狀態(tài)，升級應用程序可以調(diào)用 DeleteTransfer 將軟件包刪除。
5. 在 Transferred 狀態(tài)， 升級應用程序可以調(diào)用 ProcessSwPackage 接口發(fā)起軟件包處理任務，進入到Processing 狀態(tài)，在此狀態(tài)下客戶端可以調(diào)用 GetProcessProgress 接口查詢處理進度。軟件包的處理內(nèi)容包括對軟件包進行解壓縮，讀取 manifest 內(nèi)容，獲取軟件安裝的相關配置信息，將正在運行中的相關應用關閉，將相關的文件（ 包括應用文件、 配置數(shù)據(jù)、 標定文件、 manifest 等） 拷貝到相應的路徑或從相關路徑移除，軟件包中由廠商提供的 metadata 指明了在該階段 UCM 需要執(zhí)行的操作。在軟件包處理完畢之后進入到 Processed 狀態(tài)。在 Uninstall 操作中，需要檢查依賴完整性，即如果有依賴于要卸載的程序的應用時，則報錯，不能進行卸載作業(yè)。
6. 在 Processed 階段升級應用程序可以調(diào)用 Revert-ProcessSwPackages 接口將處理軟件包造成的系統(tǒng)文件的改變恢復到處理前的狀態(tài) Transferred，也可以調(diào)用 Activate 接口將所有的處理激活，此時將進入到Activating 狀態(tài)。
7. 在激活過程如果出現(xiàn)任何錯誤將會回到 Processed，升級應用程序也可以調(diào)用 Rollback 接口，將系統(tǒng)恢復到激活之前的狀態(tài)。激活過程首先進行依賴完整性檢查，所有的依賴都滿足之后重啟應用或系統(tǒng)。
8. 激活完成之后（ 升級的應用處于運行狀態(tài)）， 升級應用程序可以調(diào)用 Finish 接口， UCM 在此時會清理升級過程中的中間數(shù)據(jù)、 緩存數(shù)據(jù)、 軟件包等，本次升級作業(yè)結(jié)束。
ADAS域控制器
作為被升級端的 ADAS 域控制器，福瑞泰克基于 AUTOSAR 自適應平臺，通過 DoIP 總線，在控制器中ARA:DIAG 服務處理函數(shù)中實現(xiàn)了 0x38,0x36,0x37 基于以太網(wǎng)協(xié)議棧的診斷服務。
當 0x37 指令傳輸完軟件升級包時，會觸發(fā) UCM Client 實例， UCM Client 實例通過控制器內(nèi)部總線 SOME/IP去調(diào)用 UCM 的各個服務。在 UCM 服務中，Activation/Verification 會判斷軟件包的有效性， 如果軟件包無效， 程序流回滾， 如果有效， 則完成升級。
圖22 福瑞泰克域控制器 Package Manager 狀態(tài)圖
AUTOSAR OTA Demo 項目中， 網(wǎng)關負責將智能天線、 座艙域控制器、 ADAS 域控制器、 ADAS 攝像頭、 車用防火墻組成 CAN 與以太網(wǎng)相結(jié)合的局域網(wǎng)絡，保證了各模塊之間安全可靠的數(shù)據(jù)通信。硬件上采用了 NXP 公司的基于 MPC5748G 芯片的開發(fā)板進行實現(xiàn)。它提供了 8 路 CAN 接口， 5 路以太網(wǎng)（百兆）接口，使用優(yōu)化技術(shù)后以太網(wǎng)速率可達 6Gbps。
CAN 功能實現(xiàn)主要包括三個部分：物理層、數(shù)據(jù)鏈路層和網(wǎng)絡層。物理層通過電路設計，實現(xiàn) CAN 信號差分電壓，保證 CAN 信號數(shù)據(jù)的正確傳輸；數(shù)據(jù)鏈路層需保證 CAN 信號數(shù)據(jù)的正常收發(fā)，即將 CAN 電路信號轉(zhuǎn)換為對應的 CAN 數(shù)據(jù)，此部分工作是由 MCU 內(nèi)部 CAN 控制端口實現(xiàn)的，而軟件層次上則需要開發(fā)相應的 CAN驅(qū)動程序，保證 CAN 控制端口的正常工作；網(wǎng)絡層是根據(jù) ISO 15765-2 規(guī)范定義進行開發(fā)的，實現(xiàn)了 CAN 數(shù)據(jù)包的分幀、 組包以及流控制功能。
以太網(wǎng)功能實現(xiàn)基于物理層電路設計，開發(fā)了網(wǎng)絡端口驅(qū)動層程序，保證了以太網(wǎng)數(shù)據(jù)的正常傳輸。根據(jù)網(wǎng)關功能實現(xiàn)的需要，在驅(qū)動層的基礎上移植了 LwIP 協(xié)議棧，實現(xiàn)對 IPv4 和 IPv6 等協(xié)議的支持，同時開發(fā)了 DoIP服務端用以保證安全穩(wěn)定的完成升級流程。
