摘要

現代交通面臨著日益嚴峻的挑戰，例如無碳交通需求以及對靈活交通解決方案的迫切需求。U-Shift II項目通過模塊化電動汽車架構、驅動單元（驅動板，Driveboard）和車身（艙體，Capsule）的設計來應對這些問題。這種分離式設計使其在不同使用場景中具備高度靈活性。當前的架構范式（如 AUTOSAR）在成本和開發速度方面存在局限性。為解決這些問題，本文提出一種混合軟件架構，將面向信號的架構（如 CAN 總線）與面向服務的架構相融合，以提升靈活性。該混合架構的核心組件是動態鏈接系統（Dynamic Link System），其通過在運行時將艙體專用組件動態集成到驅動板軟件棧中，實現兩種架構的銜接。研究人員基于集成到驅動板原型中的硬件裝置，對所開發系統的性能及功能進行了評估，包括動態鏈接系統的延遲測量和功能測試。此外，基于云的重構流程通過支持空中軟件更新和資源分配，進一步增強了驅動板的通用性。結果表明，這種混合可重構電氣 / 電子（E/E）架構具有良好的應用前景，有望推動向未來電動自動駕駛汽車所需的純面向服務架構平穩過渡。

1. 引言

在快速城市化與技術創新并行的時代，全球交通格局正經歷深刻變革。共享經濟、電動化和自動駕駛汽車的興起這三大關鍵趨勢，正在重塑城市交通，從根本上改變人與貨物在城市內部及城市間的流動方式。隨著城市中心面臨擁堵、環境可持續性和公平可達性等多重挑戰，傳統的個人車輛擁有模式和常規公共交通模式遭遇嚴峻考驗。在此背景下，共享模塊化交通概念應運而生，成為一種可行且具創新性的解決方案，為滿足現代社會的動態需求提供了靈活自適應的框架。共享交通模式與先進電氣 / 電子（E/E）架構的相互作用，將車輛重新定義為智能互聯系統，而非單純的交通工具。通過優先采用基于信號的通信方式，車輛能夠與其組件實現無縫交互，并動態響應周邊環境，構建安全、高效且敏捷的交通網絡。此外，基于服務的軟件集成進一步提升了模塊化程度，使車輛能夠根據當前配置提供定制化功能。

隨著這一趨勢的推進，主流汽車制造商正積極調整以滿足模塊化和可擴展性需求。例如，戴姆勒（Daimler）宣布計劃批量生產模塊化、可擴展的 “貨車電動架構”，該架構在制造過程中將車輛分解為三個可互換單元；起亞（Kia）也于 2024 年國際消費電子展（CES 2024）上推出 “超越車輛平臺”（Platform Beyond Vehicle），采用了類似的設計思路。這些創新使得具備可互換組件的模塊化車輛成為可能，進而支持多樣化的硬件配置。然而，傳統軟件架構通常為固定硬件設置設計，在適應模塊化組件帶來的變異性方面面臨巨大挑戰。面向信號的軟件架構本質上難以高效適配模塊化車輛的動態需求，尤其是當不同配置需要獨特的軟件適配時。

面向服務架構（Service-Oriented Architecture, SOA）為解決這些挑戰提供了可行路徑。通過將軟件功能與特定硬件配置解耦，SOA 能夠在管理模塊化、可擴展車輛架構的復雜性方面實現更高的靈活性、可擴展性和適應性，為更高效、更具創新性的汽車解決方案奠定基礎。SOA 方法已在消費級網絡和云服務領域得到充分驗證，通?；诔谋緜鬏攨f議（HTTP）的應用程序接口（API）進行信息交換。但由于消費級云應用與汽車應用存在本質差異，HTTP 無法在汽車行業中直接應用。為此，當前的標準架構解決方案（如 AUTOSAR Adaptive）已開始聚焦于汽車領域的基于服務架構，并采用基于 IP 的可擴展面向服務中間件（SOME/IP）。

通過網關電子控制單元（ECU）與 AUTOSAR Classic 結合，已能夠實現總線系統與 SOA 的融合。然而，該系統仍存在兩個主要缺陷：首先，受經濟因素驅動，供應商使用 AUTOSAR 基礎軟件棧的年費高達 10,000 歐元以上，具體金額取決于公司規模和產量；其次，AUTOSAR 的文檔亟待完善。因此，機器人操作系統 2（ROS2）等框架有望成為 AUTOSAR 等當前主流軟件架構解決方案的替代方案，目前已有相關研究致力于開發適用于汽車領域的 ROS2 版本。此外，互聯技術已在汽車行業迅速興起。大多數現代車輛均具備云連接功能，部分車輛（如大眾 ID.3）通過車輛對車輛（V2V）通信，利用歐洲電信標準協會（ETSI）定義的協同感知消息（CAM）和分布式環境通知消息（DENM），提升整體環境感知能力。在原有研究基礎上，本文修訂并擴展了第 3 節，新增第 3.2 節對云重構流程進行詳細描述，同時在第 5 節補充了相關評估內容以適配新增章節。

1.1 問題

U-Shift II 平臺是針對模塊化電動自動駕駛汽車設計的解決方案，旨在應對現代交通挑戰，其車輛概念與首個 U-Shift 項目一脈相承（見圖 1）。在 U-Shift II 項目中，需開發一款道路模塊化車輛，該車輛需無縫整合多種功能和依賴關系，并配備當前的艙體拓撲結構。這種靈活性使得設計適用的電氣 / 電子（E/E）架構成為一項重大挑戰。除供電需求外，艙體還可能配備驅動板在現有系統配置中未預設的傳感器和執行器組，這就要求驅動板能夠兼容這些組件。考慮到這一點，模塊化車輛的典型汽車 E/E 架構很快會達到其性能上限，進而影響其在整體交通領域的潛在價值（優勢）。

圖 1、U-Shift 車輛概念。（a）驅動板與艙體分離狀態 （b）驅動板與艙體連接狀態

1.2 目標

向原生汽車級面向服務架構（SOA）的轉型需要從混合軟件架構入手?；旌宪浖軜嬜鳛橐环N新興系統，能夠彌合當前技術標準與未來軟件定義汽車之間的鴻溝 —— 它既充分利用了 SOA 系統帶來的靈活性和快速開發周期，又能在設定的時間約束內以安全可靠、經濟高效的方式實現信息分發。U-Shift 項目實現了完全自動駕駛功能與基于不同艙體的高度模塊化的結合，為實施和評估混合模塊化軟件架構提供了獨特的驗證平臺。

1.3 貢獻

本文詳細闡述了為自動化模塊化車輛開發的 E/E 架構，該架構通過 U-Shift II 項目中的驅動板原型開發與構建得以實現。在該原型中，本文提出的融合面向服務和面向信號架構的混合軟件架構概念已完成實施與測試。通過動態軟件耦合機制（即動態鏈接），面向信號和面向服務的架構能夠實現艙體拓撲結構及其使用場景的無縫切換，這對整體 E/E 架構提出了新的要求。借助 5G 互聯技術，驅動板能夠利用云計算能力和空中更新（over-the-air updates）功能，提升整體性能、可靠性以及對新型艙體技術的適應性。第 5 節通過測試驗證了所提出的動態鏈接概念的可行性，并提供了性能基準數據，以評估基于云的重構機制的必要性和適用性。

2. 相關研究現狀

汽車行業正經歷從傳統面向信號架構向更靈活的面向服務架構的重大轉型。面向信號的架構歷來是汽車 E/E 系統的核心，其依賴于預定義的通信協議（如控制器局域網（CAN））。這種方法在模塊化車輛中存在局限性，尤其是在可擴展性和靈活性方面，因為它需要靜態配置，這會減緩新功能的快速開發和適配。近期研究圍繞汽車系統中 SOA 實施的多個方面展開，重點包括資源分配、網絡架構、時序可預測性和通信協議。

文獻提出了一種基于優化的 SOA 資源分配方法，該方法利用數學優化對服務參數進行調度，同時考慮數據流與服務內計算之間的依賴關系，研究聚焦于車輛 ECU 內部及跨多個服務和 ECU 的本地資源優化。文獻通過仿真環境研究了軟件定義網絡（SDNs）與面向服務架構的融合，旨在支持車輛中的動態網絡配置，驗證了利用 SOME/IP 協議通過 SDN 實現動態面向服務網絡架構的可行性。此外，文獻對 SOME/IP 中的發現階段進行了形式化時序分析，強調了 SOA 發現階段在確定車輛子系統就緒狀態中的重要性，因為該階段的完成時間是影響整體系統性能的關鍵參數。文獻通過案例研究探討了基于 SOME/IP 和可編程數據平面的 SOA 分布式反饋控制回路汽車應用的實施，驗證了將 SOME/IP 感知融入汽車 SOA 應用和網絡設備的潛在優勢。同時，研究人員也在持續努力提升 SOA 實施的性能和平臺獨立性。文獻提出的 Bitroute SOME/IP 是 SOME/IP 通信協議的一種新實現，側重于執行性能和部署平臺獨立性，滿足了現代汽車系統對可擴展、高效通信中間件的需求。這些汽車領域 SOA 應用的進展，標志著車輛軟件架構在靈活性、可擴展性和效率方面取得了顯著進步。

UNICARagil 研究項目與 U-Shift 項目類似，基于可擴展驅動平臺和多種使用單元，但與 U-Shift 不同的是，該項目的作者為其自動駕駛車輛解決方案采用了原生 SOA 方法。正如文獻所指出的，目前結合以太網、CAN 和 FlexRay 的混合面向信號與面向服務架構在實際應用中更為可行。文獻首次通過實際案例研究展示了混合面向服務架構的相關成果；文獻則在基于信號的傳統 CAN 和 ECU 驅動的 AUTOSAR Classic 與通過以太網構建 SOA 的 Adaptive 平臺的背景下，探討了混合軟件架構的應用。相關研究現狀表明，為充分發揮模塊化自動駕駛電動汽車所需的純 SOA 優勢，基于當前面向信號的行業現狀，通過混合架構實現可控過渡是一種合適的中間解決方案。在汽車應用的 SOA 與云技術交叉領域，系統正朝著更動態、靈活和互聯的方向發展。文獻提出了一種編排器（Orchestrator），用于將汽車 E/E 架構動態擴展至云端，為非安全關鍵功能提供空中控制（COTA）能力。這種方法與邊緣和云環境中的服務編排趨勢相一致，例如工業車輛目標檢測研究所展示的應用。文獻提出了一種多層 SOA，該架構為異構計算硬件提供抽象，并促進云計算和大數據分析與高級自動駕駛技術的融合。為確保云計算中的高可用性并提升服務質量（QoS），文獻提出了多種復制策略，并將其分為面向數據和面向服務的方法。此外，文獻展示了車輛更新管理系統，該系統將車內通信網絡與車外服務（包括云車輛服務）相連。

云計算技術在汽車領域的應用正逐步擴展至汽車軟件架構的在線重構。通過云計算擴展車載計算和存儲能力催生了云基車輛功能的概念 —— 利用云能力增強車輛控制策略，并實現僅依靠車載資源難以達成的新功能。文獻強調了車輛云連接的潛力，能夠在云端運行計算密集型機器學習模型，例如降低城市公交車空調系統的能源消耗。借助云的可擴展性和計算能力，可采用專家混合（mixture-of-experts）方法，通過門控機制（gating mechanism）基于特定上下文數據動態選擇專用模型，以優化車輛功能并適應不同場景。文獻提出了一種用于汽車系統中以太網 TSN（時間敏感網絡）的重構協議，該協議通過云實現動態空中網絡操作，具備流量隔離、失效恢復和性能調整等功能，通過重構提升安全性和用戶體驗。此外，文獻提出了一種成本感知的多維度重構方法，用于動態路由應用，利用基礎設施即代碼（infrastructure-as-code）模塊實現高效資源分配和閑置組件的重新調度。最后，文獻提出了一種智能云管理系統，該系統利用知識庫對云資源進行建模、管理服務級別協議（SLA），并通過 RESTful 服務優化資源分配。

3. 混合E/E架構概念

3.1 動態鏈接系統架構

針對驅動板的應用場景，動態鏈接系統架構成為應對艙體技術不斷發展所帶來挑戰的可行解決方案。由于 CAN 總線等基于信號的系統本質上具有靜態特性，需要一個定義明確的信息流接口來銜接混合軟件架構中的面向服務和面向信號組件。此外，面向信號的 ECU 更新頻率較低，通常在車間大修期間進行。為確保驅動板的通用性，通用動態鏈接系統消息至關重要。動態鏈接系統（DLS）消息包含兩個核心部分：通用信息字段（UIF）和對應的規則標識符（RID）。UIF 作為唯一標識符，規定了如何解析 DLS 消息中的數據；RID 本質上是編排器（Orchestrator）動態鏈接 X 服務的接口定義，為驅動板和艙體之間建立標準化通信協議。這種設計確保了向后兼容性和向前兼容性，即驅動板能夠理解采用不同技術和功能的艙體發送的消息?；?RID 的設計使 DLS 架構能夠支持模塊化和可擴展的交互：當開發出新的艙體功能時，可以引入相應的 RID 對這些新功能進行定義，而無需修改區域控制器 ECU 的軟件。這種模塊化特性確保驅動板保持通用性，能夠支持多種艙體，而無需進行根本性的重新設計或軟件更新。

DLS 消息中的 UIF 用作傳輸各類數據的容器，包括傳感器讀數、控制指令和狀態更新。艙體服務通過 DLS 消息與驅動板的面向信號組件（如 CAN 總線和其他通信總線）進行交互。UIF 中封裝的信息經過轉換和雙向路由，實現驅動板與艙體之間高效、標準化的通信。該架構為不同艙體技術之間的無縫交互提供了穩健且具適應性的平臺。DLS 的一個關鍵特性是艙體在運行時的動態集成，因此需要即插即用（Plug-and-Play）兼容性以支持艙體的連接和斷開流程。圖 2 展示了完整的 DLS 架構。如圖左側所示，多個艙體中的一個（艙體 X）通過 DLS 與驅動板連接，首先向驅動板編排器共享其艙體類型（見圖 3）。隨后，編排器與艙體服務后端（Capsule Service Backend）通信，下載對應的動態鏈接 X 服務，并將其集成到已運行的 SOA 中。當新的艙體與驅動板連接時，會通過其艙體類型進行自我聲明；經過握手流程后，驅動板首先下載新服務并啟動艙體專用的動態鏈接 X 服務。一旦該動態鏈接 X 準備就緒，會發送聲明消息；在收到艙體 X 的最終確認標志后，動態鏈接 X 服務開始運行。該動態鏈接 X 可支持多種應用場景：例如，根據艙體類型，艙體可能配備自身的電池存儲系統，該系統既可以為驅動板的電池存儲提供支持，也可以反過來平衡兩者的荷電狀態（SoC）。

通過交換以特定 RID 編碼的 SoC 信息，驅動板能夠動態調整功率分配，平衡艙體和驅動板之間的 SoC，確保能源資源的優化利用、延長續航里程，并防止電池深度放電，進而延長電池壽命。另一個應用場景是基于艙體重量的電機控制器調整：通過艙體內的傳感器將重量信息傳輸至驅動板，DLS 能夠根據艙體重量自適應調整電機控制器參數。例如，對于承載可變負載的艙體，電機控制器可以動態調整扭矩輸出或再生制動設置，以根據當前負載優化性能和效率。從安全角度考慮，DLS 能夠實現艙體和驅動板安全關鍵元件的耦合（例如，人員運輸艙體的門鎖與驅動板的電機使能信號）。其他應用還包括同步艙體和驅動板的同類執行器（如燈光控制），實現整體系統的實時監控等。為確保 CAN 總線在保持 SOA 靈活性的同時實現消息的及時傳輸，系統會保留兩個域之間最近一次成功的傳輸數據。

圖 2、基于文獻的動態鏈接系統架構

圖 3、新 DLS X 軟件組件（SWC）的啟動流程及艙體與驅動板之間的示例性交互

3.2 云賦能軟件重構

在云端運行軟件組件（SWC）具有多項優勢。云集成的核心優勢在于能夠在 SWC 中動態融入實時數據和外部信息，例如當前天氣數據或交通預測，這些數據可被實時處理并適配單個車輛的個性化需求。此外，云能夠支持構建綜合車隊數據庫，集中存儲和匯總車隊中所有車輛的信息。云外包的另一個優勢是突破車輛硬件的資源限制：云系統提供近乎無限的計算和存儲能力，使得計算密集型和數據密集型應用能夠在不占用車載系統資源的情況下運行。最后，云架構確保外包功能和數據的全球可用性 —— 無論車輛位于何處，相關信息都可以被提供、更新和使用，這對于全球運營的車隊尤為有利。在云端運行 SWC 之前，必須首先評估其卸載可行性（見圖 4）。

文獻已開展相關前期研究，其成果可納入該評估流程。評估過程分為兩個步驟：第一步基于實時性要求或汽車安全完整性等級（ASIL）等標準，確定功能的運行相關性；如果某功能被判定為非運行相關，則進一步評估其云卸載適用性。這種適用性由定量和定性標準共同決定：定量標準包括硬件計算層面的潛在節能效果，以及由于云端處理速度更快而可能實現的響應時間縮短；定性評估則關注外包功能的潛在附加值（如車隊學習的收益），并將其納入評估流程。評估流程最終會為每個功能分配一個標準化的適用性評分（范圍在 0 至 1 之間），評分越高表明該功能越適合云卸載。在云端運行 SWC 的主要優勢在于，不僅可以為某一功能提供一個通用模型，還可以提供多個專家模型（expert model）。專家模型是一種專用機器學習模型，基于特定上下文或數據集訓練而成，因此在其應用領域具有極高的性能。然而，仍需要一個通用基礎模型作為備用方案，以應對沒有合適專家模型可用的情況。使用通用基礎模型作為備用方案至關重要，確保即使在沒有合適或可用的專家模型時，系統仍能正常運行。該基礎模型可作為一種通用解決方案，在廣泛的上下文范圍內提供可接受的結果，但相較于專用專家模型，其性能可能較低。專家模型與基礎模型的結合使系統兼具靈活性和效率，能夠動態適應各種需求和數據上下文。

圖4、使用門控機制和選擇專家網絡的上下文對云中的軟件組件進行重新配置

以一個覆蓋所有可能上下文領域的通用機器學習模型為起點，同時需要多個專家模型，每個專家模型針對特定上下文進行訓練。這些專家模型應具有明確的應用場景，并可根據上下文進行調整。此外，這些專家模型可以在系統運行過程中逐步學習和整合：隨著新上下文的出現或現有上下文的演變，系統可以通過訓練和集成新的專用模型不斷完善其專業能力。這種動態方法使系統能夠隨著時間的推移持續提升性能。當向云端發送請求時，需要通過門控機制（見圖 4）選擇合適的專家模型。門控機制可以是簡單的查找表，也可以是可訓練的機制（如神經網絡或決策樹）?；谳斎霐祿?，系統會決定哪個專家模型與當前任務相關；如果沒有合適或可用的專家模型，則選擇通用模型或覆蓋范圍最廣的模型。根據所選專家模型，軟件會進行相應重構并在云端運行（見圖 4）。重構過程包括動態加載所需模型、調整處理流程，并確保與輸入數據格式的兼容性；隨后通過分配必要的計算資源編排軟件執行，最終將結果通過通信通道反饋給車輛。

4. 原型搭建

可持續交通的目標可以通過模塊化電動汽車架構實現 —— 使用數量更少但日均使用時間更長的車輛完成必要的出行任務。為實現最高程度的模塊化，U-Shift II 車輛概念打破了傳統結構，將車輛分為驅動單元（驅動板）和車身（艙體）（見圖 1a、b），圖中展示了一個驅動板原型與前序項目中的人員運輸艙體。驅動板集成了全自動電動汽車運行所需的所有組件，包括電驅動系統、電池系統、控制單元和環境傳感器。自動駕駛功能通過舒曼等人（Schumann et al.）提出的新型混合 A* 路徑規劃算法實現，該算法融合了驅動板的獨特駕駛特性。車輛的具體應用場景由所選艙體決定：根據艙體類型的不同，車輛可支持乘客運輸、食品配送、自行車回收或貨物物流等多種用途。底盤中嵌入的升降機構使車輛能夠在無需外部協助的情況下自主拾取和對接艙體。

驅動板的核心設計要求是能夠適配不同艙體的多樣化架構，以應對現代交通的挑戰。這種適應性確保其能夠兼容艙體技術的持續進步和動態發展。由于驅動板生產后可能會出現新的艙體設計、功能和配置，因此必須具備適應這些變化的能力，以在各種車輛應用中保持有效性和通用性。這種適應性對于驅動板在快速發展的技術環境中保持相關性至關重要。圖 5 展示了 U-Shift II 系統中用于動態鏈接的硬件搭建。該搭建分為兩個主要部分：第一部分位于驅動板前部，包含支持面向服務和面向信號架構集成的組件（以藍色突出顯示），還包括與驅動板關鍵組件（如編排器）對接的艙體耦合機制。編排器負責管理通信并運行面向服務架構；dSpace 微自動箱（MAB）用作區域控制器，作為具備實時能力的快速原型系統，負責管理驅動板上大多數傳感器和執行器的控制與通信。該系統通過面向信號的方式進行通信，利用多種 CAN 總線組件滿足硬實時要求。

圖5、U-Shift II原型硬件設置

搭建MAB 和編排器運行的軟件組件旨在促進面向信號和面向服務架構之間的動態集成。為滿足驅動板的實時性能要求，并確保安全關鍵功能在指定時間約束內執行，MAB 以 1 kHz 的時鐘頻率運行，該配置確保所有控制驅動板的關鍵任務都能可靠執行。MAB 與網絡中其他控制單元之間通過以太網接口使用 UDP 協議建立通信，這種方式實現了面向服務架構元素與驅動板面向信號框架的無縫集成。

交換機用作編排器、MAB 和可能連接的艙體之間的物理接口。正常運行時，MAB、編排器和艙體之間通過高精度精密時間協議（PTP）主時鐘實現時間同步。硬件搭建的第二部分以綠色標識，代表艙體及其與驅動板之間的耦合機制，提供機械、電力和網絡耦合，確保 U-Shift II 的完全模塊化。艙體內至少包含一個小型 ECU，作為編排器與艙體之間的接口。作為云服務提供商，我們利用內部服務器基礎設施為 U-Shift II 創建專用虛擬機（VM），作為艙體服務后端（CSB）。該 VM 支持垂直和水平擴展，以滿足驅動板更新部署和其他 SWC 執行的需求。驅動板在需要時通過基于高級加密標準（AES）的 IPSec 安全 VPN 連接與 CSB 建立通信，確保驅動板與 CSB 之間通信的真實性和安全性。

5. 測試與評估

實驗中，基于上述兩個場景對 DLS 架構的實現進行了評估：首先是共享所連接艙體的重量信息，該信息可用于優化 MAB 內的控制參數；其次，為測量從動態鏈接 X 服務到面向信號 CAN 總線的信號同步傳輸延遲，對驅動板的燈光執行器（CAN 總線系統的組件）進行控制。在包含延遲信息的測試中，首先通過 PTP 直接同步編排器 PC 和 MAB，其中 MAB 作為主時鐘。通過約 9000 個測試點對 PTP 同步性能進行觀測（見圖 6），結果顯示 MAB 與編排器的中位時間偏差為 56 μs，最大異常值峰值為 246 μs。因此，在測試的硬件搭建中，同步的最壞情況可近似為 250 μs。

圖 6 所示結果反映了 U-Shift II 驗證平臺所用特定硬件搭建的性能，但相關原理和性能可擴展至該解決方案。從編排器到 MAB 的平均傳輸時間為 1.23 ms，低于 2.5 ms（可視為車輛中兩個控制單元之間的最壞情況傳輸時間）。這意味著即使是前文提到的電池關閉或緊急制動等安全關鍵功能，也有望通過動態鏈接接口進行控制（盡管本研究未明確涉及這些功能）。傳輸時間的方向性差異源于 MAB 的固定時鐘 —— 為保持實時能力，該時鐘頻率被嚴格設定，且由于其他任務的計算時間需求，無法進一步降低。為在 CAN 總線上進一步處理和發送相應消息，消息到達 CAN 總線并激活燈光平均需要額外 1.25 ms。當重量信息成功從編排器傳輸至 MAB 后，MAB 會根據重量設置各種模型變量（如軌跡跟蹤控制參數）。

圖6、MAB和編排器的PTP同步

結果圖7展示了 MAB 和編排器執行的消息幀序列及相應信息提取過程。上方測試圖顯示了未分離的原始 UIF 消息幀（為清晰起見已進行顏色標注），注意圖中包含兩個坐標軸（否則刻度差異過大）；第二個測試圖為對應的 RID（正確解析信息所需的關鍵）。接收 DLS 消息的 MAB 可將 RID 用作上下文標記，以確定如何解析 UIF 中包含的信息。這種上下文解析確保每個組件根據其特定需求和功能處理數據，該過程可在下方兩個測試圖中看到（信息被分離并相應處理）：當 RID 值為 11 時，驅動板共享 CAN 總線的左轉向燈同步信息至編排器（進而傳輸至艙體的動態鏈接 X 服務）；而當 RID 等于 10 時，艙體共享其當前重量信息，該重量信息可用于進一步調整控制器參數以提升性能。

圖 7、接收的原始UIF消息及基于RID的分離信息

圖8展示了 CPU 利用率與消息頻率隨時間變化的關系。測試中通過基準測試（benchmark）以更好地理解高 CPU 負載的影響：紅線標記基準測試開始，CPU 負載從約 5% 的基礎負載在 30 s 內線性上升至 100%。隨著利用率的提升，服務頻率從遠高于 90 Hz 驟降至 40 Hz，且在 CPU 利用率恢復至基礎負載前，服務頻率始終遠低于 100 Hz 的目標頻率。服務頻率的下降和上升均發生在 CPU 利用率約為 60% 時，這表明 CPU 利用率與服務頻率之間存在明顯相關性 —— 更精確地說，兩者的相關系數為 -0.39，提示存在中等程度的負相關。因此，運行過程中應避免高 CPU 負載。如圖 8 所示，額外軟件組件（如艙體專用 SWC）不斷增長的計算需求可能會對傳感器數據處理性能產生負面影響，進而可能影響自動駕駛功能的有效性，最壞情況下可能導致這些功能無法正常執行。為避免這種情況，應盡可能將資源密集型非安全關鍵任務卸載至云端；通過僅重新分配非時間關鍵型 SWC，可有效緩解這一限制。

圖 8、CPU利用率對SWC頻率的影響

6. 結論

總之，新型 DLS 架構在解決模塊化道路車輛概念開發中的關鍵挑戰方面展現出巨大潛力。通過實現不同艙體和驅動板組件之間的無縫通信、適應性和集成，DLS 支持多種高級功能（包括安全關鍵特性），例如將電機控制與艙體安全機制耦合，或動態平衡驅動板與艙體（如配備）電池存儲之間的荷電狀態（SoC）。研究團隊與合作伙伴共同開發了全尺寸驅動板原型，該原型采用了所提出的混合 E/E 架構。初步測試證實，DLS 實現了面向信號架構與 SOA 之間的低延遲連接。測試涵蓋多種雙向消息，結果令人鼓舞 —— 特別是動態鏈接消息滿足了硬實時要求。DLS 具備適應新艙體技術的靈活性，即使在驅動板已投入使用后仍可適配。通過編排器和 MAB，可利用所提出的 RID（定義通用信息字段）動態調整交互。此外，云賦能軟件重構支持將 SWC 卸載至云端，帶來增強計算能力、實時數據處理和全球可用性等優勢。這種重構過程通過專家模型和門控機制實現，能夠為特定上下文動態選擇最合適的模型，優化性能和資源利用。

在混合軟件架構的背景下，本研究聚焦于面向信號架構中的單一總線協議，這與本研究的原型驅動特性相一致。盡管原型基于單一總線協議構建，但所用方法仍具有靈活性，為未來研究探索其他協議在汽車應用中的更廣泛可行性奠定了基礎。為將基于云的重構方法推廣至其他 E/E 架構，需開展單獨研究以確定系統能力 —— 因為不同的總線協議、物理傳輸層和處理單元可能導致不同的行為（例如延遲特性）。未來研究需要解決連接故障、安全挑戰、新艙體拓撲結構集成以及不同 E/E 架構的比較等問題。為提高對連接故障的魯棒性，當前系統會保留面向服務和面向信號架構之間最近一次成功的傳輸數據；可通過增加內部冗余或傳輸錯誤時的備用功能進一步增強所提出系統的可靠性。在網絡安全方面，盡管基于 AES 加密的 IPSec 提供了堅實基礎，但仍可通過添加網絡攻擊檢測和緩解措施進一步提升安全運行水平。

此外，需要通過不同艙體拓撲結構對系統進行評估，以驗證 DLS 的可行性和可擴展性。為此，研究團隊正在積極收集大量數據，為進一步分析和與替代技術的直接比較提供支持。關于不同 E/E 架構的比較，未來研究將重點考察多個 CAN 域和其他車載網絡與 DLS 架構的交互方式。同時，研究團隊正積極收集原型數據以評估系統性能，并將探索艙體中安全關鍵通信的集成策略。

（添加微信號NewCarRen咨詢）