2.1.1  技術形態(tài)

AUTOSAR CP 是 Classical Platform AUTOSAR 的簡稱，廣泛用于對實時性、安全性要求高的動力域控、底盤域控、車身域控等方面，以達到軟硬件解耦、提高開發(fā)效率、提升軟件復用性等目的。AUTO- SAR CP 規(guī)范不僅提出了軟件分層架構，而且定義了基于該規(guī)范的標準開發(fā)流程，即開發(fā)方法論。下面從開發(fā)方法論、軟件分層架構、工具鏈這三方面詳細說明。

1. 開發(fā)方法論

AUTOSAR    CP  為基于該規(guī)范的系統(tǒng)開發(fā)提供了一個通用的技術方法。它定義了從系統(tǒng)開發(fā)到單個ECU開發(fā)的各個階段，以及在各個階段需要完成的工作內容、需要提供的成果物。開發(fā)一個系統(tǒng)可分解為以下四個階段。

一、開發(fā)抽象系統(tǒng)描述和基于 VFB( 虛擬功能總線，它描述了系統(tǒng)中所有 SWC 之間的交互關系，與ECU 個數(shù)和網(wǎng)絡拓撲無關）的系統(tǒng)描述，如圖 2.1-1 所示。該階段首先基于功能提出對整個系統(tǒng)的技術要求和約束條件，并且從功能視角設計合理高效的系統(tǒng)架構。其次，工程師在車輛電子電氣架構尚未確定之前就開始基于 VFB 進行系統(tǒng)架構設計，將功能視角的系統(tǒng)架構轉為 VFB 視角的系統(tǒng)架構。

圖 2.1-1 抽象系統(tǒng)描述與基于VFB的系統(tǒng)描述

二、開發(fā)系統(tǒng)和子系統(tǒng)，如圖 2.1-2 所示。該階段將整車的電子電氣架構作為輸入，結合網(wǎng)絡拓撲和硬件資源情況將 VFB 視角的 SWC 分配到各個 ECU，并且將 VFB 的接口轉換成能夠在通信總線上傳輸?shù)臄?shù)據(jù)，最后生成 System Extract 和 ECU Extract 供 ECU 軟件集成時使用。

圖 2.1-2系統(tǒng)和子系統(tǒng)開發(fā)

三、開發(fā)應用軟件和基礎軟件。在 VFB 視角的系統(tǒng)架構設計完畢后，即可進行原子級 SWC 開發(fā)包括實現(xiàn)其內部行為，無需關心具體ECU  信息。另一方面，在系統(tǒng)和子系統(tǒng)設計完成后，即可進行基礎軟件開發(fā)。因為基礎軟件獨立于 VFB，所以只要在 ECU 軟件集成前完成開發(fā)即可。

四、ECU 軟件集成。當 ECU Extract、基礎軟件、原子級 SWC 都開發(fā)完成后即可進行 ECU 軟件集成。在該階段工程師定義好 Schedule Table，將 SWC Runnable 分配到 task 中、補充基礎軟件配置、生成 RTE 后即可編譯鏈接生成可執(zhí)行文件。

總的來說，該方法論將汽車嵌入式軟件開發(fā)分為系統(tǒng)架構級、ECU 級和 SWC 級。系統(tǒng)架構級開發(fā)可進行整車級別的軟件架構設計以及相關功能模塊的定義。ECU   級開發(fā)則著重開發(fā)單片機底層軟件。SWC 級開發(fā)則主要開發(fā)具體控制算法。各級開發(fā)可以并行，不同的開發(fā)之間通過標準化的 ARXML 文件進行交互。

2. 軟件分層架構

在 AUTOSAR CP 分層架構中， 自上而下分別為應用軟件層（Application Layer）、運行時環(huán)境（Runtime Environment）、基礎軟件層（Basic Software Layer）, 如圖 2.1-3 所示。

應用軟件層包含若干個軟件組件，軟件組件間通過端口進行交互。每個軟件組件可以包含一個或者多個運行實體，運行實體中封裝了相關控制算法，其運行可由 RTE 事件觸發(fā)。

運行時環(huán)境作為應用軟件層與基礎軟件層交互的橋梁，為軟硬件分離提供了可能，是 VFB 的具體實現(xiàn)。RTE 可以實現(xiàn)軟件組件間、基礎軟件間以及應用軟件組件與基礎軟件之間的通信。RTE 封裝了基礎軟件層的服務、提供了標準化接口，使得應用軟件層可以通過 RTE 接口調用基礎軟件服務。此外 RTE 抽象了ECU 之間的通信，即 RTE 使用標準化接口將 ECU 之間的通信抽象為軟件組件之間的通信。

基礎軟件層又可分為四層，包括服務層、ECU 抽象層、微控制器抽象層和復雜驅動。各層又由一系列基礎軟件組件構成，包括系統(tǒng)服務、存儲服務、通信服務等，它們主要用于提供標準化的基礎軟件服務。

圖 2.1-3 AUTOSAR CP軟件分層架構

服務層提供了汽車嵌入式系統(tǒng)軟件常用的一些服務，包括系統(tǒng)服務、存儲服務以及通信服務三大部分。還提供包括網(wǎng)絡管理、存儲管理、模式管理和實時操作系統(tǒng)等服務。ECU 抽象層與 ECU 平臺相關，但與微控制器無關，包括板級硬件抽象、存儲硬件抽象、通信硬件抽象和 I/O 硬件抽象。該層將 ECU 結構進行了抽象，負責提供統(tǒng)一的訪問接口，實現(xiàn)對通信、存儲器或者 I/O 的訪問，從而不需要考慮這些資源是由微控制器片內還是片外提供的。微控制器抽象層是實現(xiàn)不同硬件接口統(tǒng)一化的特殊層，包括微控制 器驅動、存儲驅動、通信驅動以及 I/O 驅動。通過微控制器抽象層可將硬件封裝起來，避免上層軟件直接對微控制器的寄存器進行操作。最后，由于對復雜傳感器和執(zhí)行器進行操作的模塊涉及嚴格的時序問題， 難以抽象，所以在 AUTOSAR CP 規(guī)范中沒有被標準化，統(tǒng)稱為復雜驅動。

如上所述，AUTOSAR  CP  良好的分層架構為軟硬件之間解耦、軟件模塊之間解耦提供了堅實的保障。

3.  工具鏈

V 模型是目前汽車電子軟件開發(fā)過程中采用的主流開發(fā)模式，V 模型左側統(tǒng)稱為設計階段，主要涵蓋業(yè)務需求分析（Requirement Analysis）、系統(tǒng)設計（System Design）、架構設計（Architectural De- sign）、模塊設計（Module Design）和編碼（Coding）五個階段。V 模型右側統(tǒng)稱為測試階段，涵蓋單元測試（Unit Testing）、集成測試（Integration Testing）、系統(tǒng)測試（System Testing）和驗收測試（Ac- ceptance Testing）四個階段。在V 模型左側，當前主流商用工具鏈可以全面支撐 AUTOSAR CP 開發(fā)方法論中提到的系統(tǒng)架構級、ECU 級和 SWC 級開發(fā)，詳細請參考圖 2.1-4 AUTOSAR CP 工具鏈。

圖 2.1-4 AUTOSAR CP工具鏈

參照 AUTOSAR CP 方法論和開發(fā)流程，開發(fā)工具主要分為以下四類：

一、系統(tǒng)設計工具。一般由 OEM 使用，主要用于完成軟件組件框架（端口、端口接口、數(shù)據(jù)類型、運行實體、觸發(fā)事件）的設計及框架代碼生成；實現(xiàn)軟件組件間通信端口的連接；導入 DBC、LDF 等傳統(tǒng)網(wǎng)絡描述性文件實現(xiàn)軟件組件向 ECU 映射等工作。

二、軟件組件設計工具。一般由 Tier1 使用，主要用于軟件組件框架的搭建，生成符合 AUTOSAR 規(guī)范的代碼與軟件組件 ARXML 文件。之后將 ARXML 文件導入 Matlab Simulink 后可繼續(xù)進行控制算法模型開發(fā)，開發(fā)完成后通過自動代碼生成獲得的 C 代碼將用于 ECU 軟件集成。

三、MCAL/BSW 配置及 RTE 代碼生成工具。MCAL 配置工具主要用于底層驅動的配置與配置代碼生成、BSW 配置工具主要用于基礎軟件協(xié)議棧的配置與配置代碼生成，生成后的配置代碼需要與工具供應商提供的靜態(tài)代碼一同進行 ECU 軟件集成。RTE 代碼生成工具以軟件組件 ARXML 或基礎軟件配置ARXML 為輸入，生成符合 AUTOSAR CP 標準的 RTE 代碼，向軟件組件提供可靠的通信和調度服務。

四、編譯與調試工具。用于 ECU 軟件集成時的編譯與調試。由于 AUTOSAR CP 工程代碼量十分龐大， 所以對編譯器和調試器的要求也相對較高。

此外，目前市面上的 AUTOSAR  工具鏈都是桌面應用程序，這使工具鏈的維護和升級都不方便，并且由于應用程序在各個電腦上都是獨立的，所以其資源是不可共享的，使開發(fā)效率降低。而隨著 5G 和千兆網(wǎng)絡的普及，在未來，AUTOSAR 工具鏈由桌面應用程序發(fā)展為 Web 應用程序成為可能。具有超大帶寬、超低時延、更加穩(wěn)定可靠等特征的寬帶網(wǎng)絡結合超強性能的 Web 應用程序服務器，以及 Web 應用程序本身的優(yōu)勢，這使得工具鏈供應商可以更加方便的維護及更新工具，開發(fā)者們更加高效、友好的合作開發(fā)。

2.1.2  技術發(fā)展趨勢

AUTOSAR CP 發(fā)展歷史悠久，從誕生到現(xiàn)在已經(jīng)有近 20 年的歷史。本章節(jié)將從當前痛點分析角度來闡述 AUTOSAR CP 存在的問題和未來發(fā)展趨勢。

AUTOSAR CP 帶來的優(yōu)勢和便利前文已經(jīng)敘述了很多，但是它也不是完美的，在實際應用過程中也存在一些問題，下面將從五個方面分別闡述。

一、架構充分解耦導致標準和接口規(guī)范繁多。不可否認 AUTOSAR CP 的規(guī)范文檔非常詳盡，但正是兩百多個多達幾萬頁的標準文檔讓一些傳統(tǒng)的嵌入式工程師望而止步。同時 AUTOSAR CP 提出了很多新概念，比如標定量通過描述文件進行描述；應用接口不通過傳統(tǒng)全局變量的方式與底層軟件交互，而是對接口進行描述定義通過 RTE 統(tǒng)一接口進行匹配等。AUTOSAR CP 的軟件開發(fā)理念和傳統(tǒng)嵌入式工程師的認知偏差也是其普及率不高的原因之一。

二、工具鏈價格昂貴國產(chǎn)研發(fā)之路任重而道遠。動輒幾百上千萬的軟件使用授權費對 OEM、Tier1 來說都是很大的研發(fā)投入。盡管國內已經(jīng)有普華基礎軟件、經(jīng)緯恒潤、東軟睿馳、中汽創(chuàng)智等幾家供應商開始布局工具鏈的開發(fā)，但國產(chǎn)工具鏈的研發(fā)推廣之路依然任重而道遠。

三、工具鏈之間兼容性差影響合作開發(fā)的靈活性。在實際項目中并沒有體現(xiàn)出 AUTOSAR CP 軟件模塊的復用性和獨立性。由于各廠商對 AUTOSAR CP 規(guī)范的理解并不完全一致，而且各廠商的工具也并不完全兼容，導致 OEM 集成各家供應商開發(fā)的軟件模塊需要花費大量的精力和時間。原本希望借助 AU- TOSAR CP 標準統(tǒng)一的優(yōu)勢合作開發(fā)，但是因為工具鏈的兼容性問題而不得不統(tǒng)一工具鏈的使用，嚴重限制了合作開發(fā)的靈活性。

四、自動化程度低導致開發(fā)和集成效率偏低?；A軟件與應用軟件的接口集成需要大量的手動配置工作，不僅操作上低效出錯率高，而且在錯誤檢查方面也不如傳統(tǒng)軟件集成方便。對于某些錯誤提示往往不能快速定位錯誤原因，對于某些需求追加或變更往往不能快速對應。針對這一痛點，國內大部分 OEM 都已經(jīng)開始使用自動化腳本工具直接操作 ARXML 來代替這種重復性的工作。

五、代碼可讀性差導致調試困難。這是代碼生成工具普遍存在的問題，和 MATLAB 的 AUTOSAR 工具箱生成的代碼一樣，一些 AUTOSAR 工具鏈的 RTE 代碼生成工具生成的代碼可讀性也較差，這給軟件調試帶來了不少麻煩。例如在調試基于  SOMEIP  的服務通信時需要根據(jù)服務請求信號、提供信號的數(shù)據(jù)流向和函數(shù)調用關系，一層一層地查詢才能理解整個通信過程。

2.1.3  關鍵技術解讀

1.  基礎軟件多核分配

基礎軟件多核分配是發(fā)揮多核系統(tǒng)并行計算、負載均衡、快速響應優(yōu)勢的關鍵技術。沒有基礎軟件的多核分配，就算應用軟件做了多核分配，多核系統(tǒng)的優(yōu)勢將受到核間通信效率的制約，甚至系統(tǒng)整體性能還不如單核。實現(xiàn)基礎軟件多核分配的主要技術手段有主衛(wèi)星方式（Master/Satellites）和通信協(xié)議棧分割（Com-Stack Split）兩種。

一、主衛(wèi)星方式。如圖 2.1-5 主衛(wèi)星方式的基礎軟件分割所示，該方式可適用于 Dem、FiM、WdgM、Com、NvM、XCP、EcuM 等基礎軟件組件。當這些組件提供的服務需要被多個核使用時可以考慮主衛(wèi)星方式，即衛(wèi)星給其所在核的其他模塊提供服務接口并將收到的服務請求通過主衛(wèi)星通信傳遞給主星，主 星協(xié)調、過濾和接收各衛(wèi)星的服務請求并進行處理，最后將處理結果通過主衛(wèi)星通信反饋給衛(wèi)星。由于主衛(wèi)星之間的工作分配 AUTOSAR CP 并未標準化，所以用戶可自定義。一種極端情況是主星具備全部功能， 衛(wèi)星僅為同核其他模塊提供服務接口并將服務請求轉發(fā)到主星上處理；另一種極端情況是衛(wèi)星和主星一 樣具備全部功能并不需要主星處理服務請求，它只需要與主星保持必要信息的同步。

圖 2.1-5 主衛(wèi)星方式的基礎軟件分割

由于衛(wèi)星提供的接口可以被該核的其他模塊直接調用并通過高效的主衛(wèi)星通信與主星交互，從而避免了低效的 Client/Server 通信，大大提高了多核系統(tǒng)中基礎軟件的服務效率。另外由于主衛(wèi)星可并行處理服務請求，因此 CPU 負載可以被有效平衡、基礎軟件的服務速度也得到提高。

二、通信協(xié)議棧分割方式。該方式通過一個增強型的 PduR 引入FIFO 隊列（無需自旋鎖）或 Buffe（r  需

要配合自旋鎖）這樣的數(shù)據(jù)結構對跨核 PDU 進行路由，可將不同類型的總線協(xié)議棧分配到不同的核，如將 CAN 協(xié)議棧和以太網(wǎng)協(xié)議棧分配到不同的核。通過這樣的協(xié)議棧分割可達到 CPU 負載均衡及提升多核系統(tǒng)實時性的目的。

2.  軟件集群技術

軟件集群（Software Cluster）在R20-11 版本中被首次提出，是 AUTOSAR CP 在軟件架構方面的一次創(chuàng)新，其本質是利用二進制接口技術實現(xiàn)更為靈活的軟件集成與更新。

圖 2.1-6 軟件集群技術示例

如圖 2.1-6 軟件集群技術示例所示，通過軟件集群技術 AUTOSAR CP 軟件架構被分割成了兩個獨立的軟件集群，分別為應用軟件集群（Applicative Software Cluster）和主軟件集群（Host Software Cluster）兩部分。其中應用軟件集群可以單獨編譯，其搭載一組關聯(lián)度較高的 SWC ；主軟件集群也可以單獨編譯，其除了可以搭載 SWC 之外還必須搭載基礎軟件（包含 OS 和 MCAL）。一個控制器中可以存在多個高度解耦的應用軟件集群，但是只能且必須存在一個主軟件集群，分別將應用軟件集群和主軟件集群燒寫至目標板后即可形成完整的、可執(zhí)行的程序。這樣的軟件架構創(chuàng)新使得軟件的開發(fā)與集成變得更加靈活，尤其是當需要更新軟件功能時，無需更新全部軟件，只要更新特定的軟件集群即可。

如圖 2.1-6 軟件集群技術示例中的藍框所示，各個軟件集群就像是控制器上的一塊塊拼圖，而這些拼圖之間是通過軟件集群連接塊（Software Cluster Connection）拼接起來的。軟件集群連接塊由三部分組成，分別是二進制清單（Binary Manifest），跨軟件集群通信（Cross Cluster Communication）， 代理模塊（Proxy Modules）。其中最關鍵的是二進制清單，它在編譯階段產(chǎn)生且 AUTOSAR CP 規(guī)定了其標準格式，它為各個軟件集群編譯后文件（Binary Objects）之間提供了定義良好的接口，從而能將其連接在一起形成完整的可執(zhí)行文件。圖 2.1-7 軟件集群的連接展示了二進制清單連接兩個軟件簇的例子， 其中軟件集群 A 運行時需要一個資源（Require Resource，指軟件集群運行時所需要的一切，或是 S/R 接口，或是 NV 塊），而這個資源正好可以由軟件集群 B 提供（Provide Resource）。軟件集群 A/B 的二進制清單中都分別存儲了這個資源的基本信息包括：資源屬性（Require/Provide）、資源類型（S/R、NV 塊等）、資源 ID、句柄一覽表（Handle，即用于訪問該資源的信息如數(shù)據(jù)指針、函數(shù)指針、數(shù)據(jù)等）等。對于軟件集群 A 來說，因為在其單獨編譯階段沒有相應的 Provide Resource，所以其二進制清單的句柄一覽表被默認值填寫且是可修改的，如圖 2.1-7 黃色框所示。對于軟件集群 B 來說，因為其具備固定的Provide Resource，所以其二進制清單的句柄一覽表在編譯時已確定且是不可修改的，如下圖綠色框所示。如果在燒寫時進行軟件集群連接，那么目標板內的軟件集群連接器軟件（On-board Software Cluster Connector）負責在燒寫的同時，將軟件集群 B 中資源的句柄拷貝至軟件集群 A 中資源的句柄，從而完成兩個軟件集群的連接。

圖 2.1-7 軟件集群的連接

跨軟件集群通信用于支撐 VFB 通信。而代理模塊分為高代理模塊（High Proxy Modules）和低代理模塊（Low Proxy Modules）兩部分，其中高代理模塊位于應用軟件集群代替原先的基礎軟件模塊提供符合  AUTOSAR  標準的接口，低代理模塊位于主軟件集群負責實現(xiàn)真正的基礎軟件模塊功能，二者之間通過二進制清單連接。

2.1.4  典型應用案例

本章節(jié)將分享幾個基于 AUTOSAR CP 基礎協(xié)議棧的典型應用案例供讀者參考。

1.  SOME/IP 應用案例

在某公司 L3+ 自動駕駛項目中，整車和傳感器通過 CAN 總線與自動駕駛域控制器的 MCU 進行交互， MCU 再將從 CAN 總線接收到的數(shù)據(jù)組包轉發(fā)給 SOC 的各應用模塊，MCU 與 SOC 之間則通過基于以太網(wǎng)的 SOME/IP 通信協(xié)議進行交互。

常用的  SOME/IP  以太網(wǎng)消息類型有：REQUEST、REQUEST_NO_RETURN、NOTIFICATION、RE-SPONSE。其中  REQUEST  為期待響應的請求，客戶端有需求時才會向服務端發(fā)送請求，且客戶端會等待服務端反饋的結果。例如，客戶端如果需要向服務端請求 VIN 碼，則可發(fā)送 REQUEST 類型的消息。RESPonSE 則為響應消息，即服務端的用于響應客戶端 REQUEST 類型的報文。例如：客戶端向服務端請求 VIN 碼，服務端則通過 RESPonSE 類型的消息給客戶端回復 VIN 碼。REQUEST_NO_RETURN 為 不期待響應的請求，客戶端有需求時才會向服務端發(fā)送請求，但客戶端不關注結果。例如，客戶端如果 需要向服務端請求打開車窗，客戶端可發(fā)送 REQUEST_NO_RETURN 類型的消息。NOTIFICATION 為事 件通知，客戶端先向服務端訂閱消息，服務端當發(fā)現(xiàn)被訂閱的消息發(fā)生變化時則主動通知客戶端。例如， 客戶端向服務端訂閱車速信息，服務端如果發(fā)現(xiàn)車速變化則可發(fā)送 NOTIFICATION 類型的消息給客戶端。

在本案例中，由于 MCU 與 SOC 的通信數(shù)據(jù)具有數(shù)據(jù)量大、通信數(shù)據(jù)類型確定、數(shù)據(jù)周期性發(fā)送等特點，因此 SOME/IP 消息采用 NOTIFICATION 類型。自動駕駛域控制器的軟件架構如圖 2.1-8 所示。

圖 2.1-8 自動駕駛域控制器軟件架構

MCU 一側基于 AUTOSAR CP 搭建應用軟件， 主要包括三個應用模塊：VDC（Vehicle Data Center）將整車相關 CAN 數(shù)據(jù)做預處理，此類 CAN 數(shù)據(jù)主要指 VCU、EPS、EPB 等控制器數(shù)據(jù)；XDC（X Sensor Data Center）將各傳感器的 CAN 數(shù)據(jù)做預處理，此類 CAN 數(shù)據(jù)主要指毫米波雷達、組合導航、智能攝像頭等傳感器數(shù)據(jù)；IDC（Internal Data Center）將預處理后的 CAN 數(shù)據(jù)轉換成以太網(wǎng)數(shù)據(jù)并通過 SOME/IP 協(xié)議發(fā)送到 SOC 一側。SOC 一側基于 AUTOSAR AP 搭建，其中 SDC（Service Date Center）將以太網(wǎng)數(shù)據(jù)轉換為 SOC 應用模塊所需要的數(shù)據(jù)。在 SOME/IP 通信中，SOC 側的 SDC 作為客戶端，啟動后即開始訂閱 MCU 側的所有已知服務，MCU 一側收到訂閱后即開始以固定周期向 SDC 側發(fā)送訂閱的報文，為保證實時性，SOME/IP 的數(shù)據(jù)傳輸周期與 CAN 報文周期一致。

SOME/IP 序列化方式采用大端一字節(jié)對齊。因為一字節(jié)對齊是最簡單的對齊方式，大多編譯器很容易實現(xiàn)；并且采用一字節(jié)對齊，序列化后沒有冗余數(shù)據(jù)，報文的有效負載段都是有意義的數(shù)據(jù)，所以總體傳輸效率得到了一定提升。另外，SOME/IP 通信報文中的 Payload 也會添加時間戳和 Rolling Counter 等信息，SOC 一側的應用在使用 MCU 傳來的數(shù)據(jù)之前，會先把時間戳取出來，并作數(shù)據(jù)校驗、對齊、分析等工作。SOME/IP 報文結構如圖 2.1-9 所示。

圖 2.1-9 SOME/IP報文結構

本案例中的 SOME/IP 協(xié)議均基于 UDP 協(xié)議開發(fā)，它在用戶有需求的時候才發(fā)送報文，這種方法有以下幾點優(yōu)勢：

一、傳輸效率高。與 CAN 等周期性的網(wǎng)絡相比，總線上不會出現(xiàn)過多不必要的數(shù)據(jù)，從而減少了資源消耗，點對點的全雙工傳輸模式也讓通信效率變得更高。

二、通信速率快。對于雷達這類較大的數(shù)據(jù)，需要 MCU 能在短時間內及時地將數(shù)據(jù)傳輸?shù)?SOC，使用以太網(wǎng)是目前各類總線通信中速率最快的，它最能滿足大數(shù)據(jù)量的通信需求。

三、數(shù)據(jù)長度長。CAN-FD 報文數(shù)據(jù)長度最大 64 字節(jié)，LIN 報文數(shù)據(jù)長度最大 8 字節(jié)，單幀 Flex- ray 報文數(shù)據(jù)長度最大 254 字節(jié)，而基于 UDP 的以太網(wǎng)單幀報文長度可達 1500 字節(jié)，能滿足大數(shù)據(jù)的通信需求。

四、實現(xiàn)較簡單。以太網(wǎng)已有成熟的 TCP/IP 協(xié)議棧，基于 Linux 平臺還有開源的 Vsomeip 協(xié)議棧，可直接移植使用。

2.  時間同步應用案例

在智能駕駛中，時間是一個非常重要的參數(shù)，各個系統(tǒng)中需要保證時間一致，其中包括車云系統(tǒng)之 間時間一致；域控之間時間一致；域控與各個 ECU 之間時間一致；ECU 與各個傳感器之間時間一致等。車云系統(tǒng)為保證時間一致，常在車載 ECU 中加裝 GPS 模塊，ECU 通過 GPS 數(shù)據(jù)與云平臺時間保持一致。車內系統(tǒng)（域控之間、域控與 ECU 之間、ECU 與傳感器之間）為保證時間一致主要采用：PTP（Precision Time Protocol 高精度時間同步協(xié)議）、PPS（同步脈沖信號）、AUTOSAR CP 同步方案等。

如圖 2.1-10 多傳感器融合系統(tǒng)中，Camera ECU 通過高精度攝像頭采集車道線、障礙物、標識等信息；Radar ECU 通過毫米波雷達進行障礙物、障礙物速度等信息的采集；Camera/Radar ECU 通過CAN-FD 將處理的數(shù)據(jù)交給 ADCU 進行數(shù)據(jù)融合，ADCU 中自帶 GNSS 芯片保證與云端時間一致。由于該系統(tǒng)對數(shù)據(jù)實時性、真實性要求比較高，所以需要保證 Camera/Radar ECU 采集的數(shù)據(jù)時間一致。為了達到該目的，如圖 2.1-11 時間同步步驟所示，本案例采用了 AUTOSAR CP 時間同步解決方案，即ADCU 作為 Time Master 實體，Camera/Radar ECU 作為 Time Slave 實體，由 ADCU 對 Camera/Ra- dar ECU 進行時間同步。

圖 2.1-10 多傳感器融合系統(tǒng)

圖 2.1-11 時間同步步驟

時間同步的步驟與方法如下：

一、ADCU 以 1s 為周期發(fā)送同步幀，即圖中 t1 時刻發(fā)送 t0 時刻的時間戳。

二、Camera/Radar ECU 在 t2 時刻收到同步幀后，記錄 t2 時刻的時間戳。

三、ADCU 間隔固定時間（100ms）后發(fā)送跟隨幀，發(fā)送內容即Δt0 時間。

四、Camera/Radar ECU 在t3 時刻接收到跟隨幀后，進行絕對時間計算并將絕對時間更新到 ECU 中， 公式為：t3 = t0 +Δt0 + t3–t2。

注：本章有關AUTOSAR 的內容是AUTOSEMO 會員單位的經(jīng)驗解讀，僅供行業(yè)參考。