汽車架構變化趨勢

在分享中央計算軟件架構之前，我們先簡單說明一下汽車架構變化趨勢，總的來說，主要包含以下階段： 分布式架構：ECU 數量超過 100 個以上，每個 ECU 承擔相對獨立的功能系統。持續維護數量日益增加的 ECU 變得越發復雜和費時費力。 功能域架構：域功能合并后，一方面可以減少 ECU 數量（縮減芯片和外殼的總體成本）。另一方面，軟件應用集中化部署后有利于軟件功能升級和管理。然而，要實現跨域功能的交互，系統設計依然繁瑣且沒有效率。 中央計算+區域控制架構：功能邏輯上移到中央計算，區域控制器控制數據和配電。實現硬件和軟件的解耦，便于軟件快速迭代。

圖-汽車架構變化趨勢 中央計算+區域控制架構的核心是分布式計算系統，通過遠程過程調用（RPC）實現各個主機之間的資源和算力共享。區域控制器掌握的是該區域的控制器與傳感器的硬件資源，以及一定的算力處理邊緣計算。 而中央計算集群擁有高性能計算能力，圖像資源采集，以及接入云端資源的能力。它們之間需要交互才能創造出新的用戶體驗和使用場景，為支持這種分布式計算系統，就需要一套強大的 RPC 機制：

互聯網行業 RPC 框架 - 應用級的服務框架： Dubbo/Dubbox、Google gRPC、Spring Boot/Spring Cloud - 遠程通信協議： RMI、Socket、SOAP(HTTP XML)、REST(HTTP JSON)

車內中央計算+區域控制RPC框架 - 應用級的服務框架： 具代表性的如大眾 VW.OS，國內外整車廠都已經開始了應用級服務框架的定義和設計。 - 遠程通信協議： SOME/IP,DDS,REST,MQTT等輕量級通信協議 其中 SOME/IP 是專門為車載領域設計的基于服務的 RPC 通信協議，其他幾種協議在其他行業已運用。

圖 - RPC通信概覽 上圖出現的 Client, Server 是 RPC 通信的基本元素。一個完整的 RPC 框架，包含了服務發現、服務質量、網絡傳輸、序列化等組件，其中“RPC 協議”就指明了程序如何進行網絡傳輸和序列化。

圖 - 完整RPC框架 AUTOSAR 標準文檔中包含了多個 SOME/IP 相關的文檔。它們是：

SOME/IP Protocol 1.SOME/IP on wire-format (Serialization)： -Structure of Header Format -How the different data types are serialized as per SOME/IP 2.Protocol for Event and RPC-based communication -Transport Protocol（同時支持UPD和TCP） -Rules that govern the RPC for SOME/IP

SOME/IP Service Discovery（SD） 1. 定位服務實例： 2.檢測服務實例是否在運行（即服務實例的狀態） 3.發布/訂閱行為的管理

SOME/IP Transport Protocal（TP） - 對長數據的數據流控制：

SOME/IP Transformation -填充 SOME/IP Header 和 Payload 的規則

下圖中SOME/IP Demon管理服務的注冊，服務的通信建立和轉發。

圖- SOME/IP RPC框架

中央計算架構代理的挑戰

混合算力要求

在自動駕駛和網絡互聯需求下，對中央計算算力提出更高的要求，同時傳統的車身，底盤，動力等功能上移，也需要中央計算單元具有實時安全計算的能力。 以下是推功能算力的估算

主動安全與自動駕駛

- NCAP & L2：大于20 TOPS - Auto-Pilot: 大于40 TOPS - RoboTaxi: 大于200 TOPS

車身控制，底盤，動力域總和： - 大于10000 DMIPS

核間高速通信

以下場景使得對核間的數據通信需求增加，為核間高速通信，可靠通信提出了要求。

主動安全與自動駕駛：龐大的視覺及雷達數據

大數據收集，log & Trace 數據

信號與服務的轉換

功能分配

功能組件分布部署在中央計算集群以及區域控制器上，對以下方面提出要求。

功能合理部署

提高組件復用性

優化組件的相互調用

中央計算單元發展路徑

中央計算早期雛形

于2011 年，奧迪 A8就開始了定位于 L3 系統的研發，其核心模塊 ZFAS雖然是自動駕駛控制器，但也可以認為它是中央計算的早期雛形。它是異構的系統架構，包含MobiEye EyeQ3，NVIDIA K1, Cycline, Aurix.

圖- Audi ZFAS 在這樣一個典型的異構系統中，處理器之間的通信是什么復雜的，其采用的主要技術有：

Deterministic 以太網 – Time Trigger Ethernet

平臺軟件中間件 – MotionWise Middleware(Communication, Safety, TimeSync, Platform service)

圖- Audi ZFAS異構系統概況

異構系統的核間通信

異構系統的核間通信是個難題，通常情況下會包含 MCU, GPU, FPGA, MPU 系統，在它們之間需要保證高性能的實時消息通信，并且要支持面向服務，以及核間互不干擾。 對于每個異構系統內的操作系統，在它們之間應設計高速核間消息通信的機制，以及通信式樣，典型的有Client-Server 通信式樣。

圖-異構系統的核間通信

異構系統操作系統

MCU 系統，常見的有多核 AutoSAR 軟件架構，或者使用 MCU Hypervisor 方案。 GPU 系統，管道式的軟件架構局多，采用 RTOS 之上運行 Runtime, Library，Appliation 的方案。 MPU 系統，使用虛擬化方案運行多個 High Level OS，每個 OS 之上運行各自的中間件以及上層應用軟件。

圖-異構系統的操作系統

異構系統的將來 - 單 SoC 系統

新硬件技術使得分離的芯片架構可以集成到單獨芯片，實現“一顆芯片上的軟件架構”。 單 SoC 系統優勢:

在不同域和功能分區之間高效地共享高帶寬數據。

更好地利用車內資源共享和設計功能回退機制

更有利于硬件抽象化設計

減少傳統單體系統的規模（高集成度，高復雜性地模塊）

硬件變種減少

減少暴露在外的通信總線，減少信息安全攻擊的路徑

縮小產品尺寸

圖- 異構系統轉向單SoC系統

混合關鍵系統

中央計算架構的變化使得多種安全等級的應用運行在同一個系統中，特別是單 SoC 系統后，"混合關鍵性"額外的重要。 “混合關鍵系統”應允許在同一高性能處理器上并行托管 1 個或多個安全關鍵性功能/系統，以及其他不受控制甚至是惡意的功能/系統，但絕不會對該安全關鍵性功能/系統產生任何負面影響 。 例如娛樂系統中通常會允許安裝用戶自定義應用程序，這些應用程序將成為風險的來源。通常的對策是讓這些應用運行在容器定義的沙盒環境中，對這些應用程序僅開放受限制的訪問權限。

圖-混合關鍵系統 在功能安全軟件需求的章節中有提到，不同 Safety Level SWC 組件Co-existence和 Freedom from interference 的問題。 下圖舉例說明了 Interference 的干擾源，及做到 Freedom from interfence 相對應的措施。

圖-干擾源及應對措施

中央計算單元功能分配

對于單 SoC 方案的中央計算單元，它具備以下能力，這些能力可以指導布局應用功能。

將 ASIL-B 到 ASIL-D，具備 FuSa 要求的 SWC，以及 QM 的軟件組件部署在同一個 SoC 系統之上。

核間通信 IPC -信好與服務的轉換

- 數據收集(Log & Trace) - 其他各類數據交換(OTA, IDS...)

擁有視覺處理能力, 支持 OpenVX, 流水線處理, 圖像并行處理

集成R核 MCU 后，擁有快速應用啟動功能，支持集成車身，網關等功能

A 核可以部署和人機界面，多媒體，互聯等相關的應用

圖-中央計算單元的功能分配

應用示例

在中央計算+區域控制的架構中，有兩種不同的設計風格體現，一個是基于服務的式樣，另一就是基于信號的式樣。 現階段傳統的執行器與傳感器仍是基于 CAN/LIN 信號的設計的，而中央計算單元已可以依照基于服務的式樣設計。這兩種不同的設計風格由區域控制器完成基于信號的世界與基于服務的世界轉換。 以下應用示例涵蓋了中央計算單元，區域控制器，執行傳感器的互動過程。 示例需求描述:

當啟停開關按下后，車輛電源模式切換到 ON 檔。

當車速大于 5km/h，則執行車輛上鎖。

整個執行過程如下：

區域控制器直接采集啟停開關，同時通過 CAN 通信收集車速信號

區域控制器完成信號至服務的轉換，以服務的內容提供給中央計算單元，之間通過以太網通信。

中央計算之內的應用之間的接口也是以服務方式通信，采用操作系統系統的 Local IPC 機制，如 Local Unit Socket。

經由上次邏輯處理后，再調用某區域控制器提供的服務，如上鎖操作。

最后區域控制器將上鎖指令轉換為 CAN 或者 LIN 的報文，由門模塊執行上鎖的操作。

圖-中央計算與區域架構應用示例

責任編輯：彭菁