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