區(qū)域導向的設計將帶給未來的汽車E/E架構巨大的優(yōu)勢（功能更多，但負載更少）。區(qū)域架構需要將許多功能整合到少數(shù)的區(qū)域ECU（即ZCU）中，挑戰(zhàn)在于ZCU的性能、時序和安全方面。瑞薩和ETAS聯(lián)合介紹了他們的通用虛擬化平臺，即MCU、Hypervisor和開發(fā)工具組成的一整套應用和開發(fā)平臺。其將簡化軟件的實現(xiàn)，從而縮短通往新的ZCU時間。

從傳統(tǒng)汽車設計到CASE（Connectivity、Automation、Sharing、Electricity）的趨勢需要整體計算性能的指數(shù)級增長，以及汽車內(nèi)通信負荷的指數(shù)級增長。實現(xiàn)CASE所要求的性能和網(wǎng)絡的復雜性無法通過傳統(tǒng)的E/E架構來實現(xiàn)。這是因為傳統(tǒng)的分布式E/E結構將需要更多的ECU和相應的更復雜、更重的線束。

此外，總的功耗和成本在傳統(tǒng)E/E架構中也將大大增加。因此，向CASE過渡的一個關鍵挑戰(zhàn)是在不增加物理ECU數(shù)量的情況下擴大功能范圍。這就需要一個新的軟件架構，由有能力但成本效益高的硬件解決方案來支撐。

架構的改變需要設計上的權衡

開發(fā)新的、無歷史包袱的ZCU的OEM可以從一開始就采用域（domain）或區(qū)域(zonal)架構，如圖1。然而，在實踐中，許多OEM并不是從零開始，而是需要保留已有的ECU中的軟件。這涉及到從他們現(xiàn)有的分布式E/E架構（一個ECU完全對應一個車輛功能）遷移到區(qū)域架構。架構和支撐技術的變化總是會帶來新的設計的權衡。

主要的挑戰(zhàn)是定義哪些ECU應該被整合，以及在軟件架構中如何把功能集成在一起。此外，需要確定來自不同方（OEM、Tier-1、第三方）的軟件和不同功能安全級別的軟件之間的隔離程度。最后，需要決定在哪里重用現(xiàn)有的軟件，在哪里進行重新設計。

這種決定受到各種因素的影響，如已有的軟件的和計劃新開發(fā)軟件的工作量、供應鏈結構或量產(chǎn)后的軟件維護策略。對于特定的E/E架構，只有通過對不同技術方案的反復對比并且通過從研究型開發(fā)中收集數(shù)據(jù)，才能做出有充分依據(jù)的設計選擇。



圖1. E/E架構對比：今天的分布式架構（左）和未來的面向區(qū)域的E/E架構（ 瑞薩）

區(qū)域架構的挑戰(zhàn)

面向區(qū)域的架構將眾多功能和服務整合到一個ECU中。網(wǎng)絡設計必須要考慮相關的對帶寬、確定性和最大延遲的要求。區(qū)域控制器ZCU顯然需要高計算能力來并行執(zhí)行多個功能。而且，出于功能安全和信息安全的原因，它們還必須確保不受并發(fā)應用程序之間的干擾，并確保時序要求。

大多數(shù)現(xiàn)代ECU將運行 Autosar Classic軟件架構，這是一個基于軟件組件的架構，支持timing和memory的保護，以及許多功能安全和信息安全機制，還能夠通過software cluster實現(xiàn)部分更新。

ECU的軟件來自多個利益相關者方，包括OEM（應用層），Tier-1（中間件和集成），Tier-2（MCAL）和 第三方（如Autosar BSW、OS、安全固件）。這一組利益相關者的軟件集成到一個ECU之內(nèi)在今天已經(jīng)成為一項個重要的工程任務。很難想象同樣的方法將擴展到未來的ZCU。原因有多個。

誰來負責集成來自多個供應商的應用層？當ECU發(fā)生故障時，誰負責？如何在多應用的ECU系統(tǒng)中確保系統(tǒng)安全隔離？各方如何保護知識產(chǎn)權？誰來執(zhí)行根本原因分析和調(diào)試？最后，需要大量的努力來重新測試整個ECU，即使當一個小的軟件組件發(fā)生變化時。

解決這些挑戰(zhàn)的一個辦法是基于Hypervisor的軟件概念，將一個物理ECU擴展為多個虛擬ECU。用Autosar的話說，這里的每個虛擬ECU是一個獨立的ECU，有自己的EcuExtract，通過COM和虛擬網(wǎng)絡與其他虛擬ECU進行通信。這種解決方案允許每個虛擬ECU通過松耦合的方式結合到一個物理ECU中。每個虛擬機（VM）可以單獨編譯和鏈接，并有自己的運行時環(huán)境（RTE）。一個RTE配置的變化并不會引起整個系統(tǒng)的軟件被重新構建。

此外，這些虛擬機有完全的對處理器硬件訪問權。而且，對一個虛擬機的改變不一定需要對整個系統(tǒng)進行重新測試，一個虛擬機可以獨立于整個系統(tǒng)重新啟動，這有助于最大限度地減少同一ECU上其他不相關功能的停機時間。

Zone ECU的硬件

瑞薩RH 850/U2x系列微控制器用于下一代區(qū)域/集成ECU，支持各種嵌入式硬件的針對區(qū)域應用的關鍵功能。此外，高性能的NoC（片上網(wǎng)絡）結構可以確保每個單獨的集成應用在外設和內(nèi)存訪問方面的實時性。



圖2. RH 850/U2A：用于單芯片的跨區(qū)域平臺集成多種車身和底盤應用（ 瑞薩）

RH 850/U2A MCU被設計成一個跨領域的平臺，適用于高端車身和底盤應用，以滿足日益增長的將多種應用集成到單個芯片的硬件需求，如圖2?；?8納米工藝技術，32位RH 850/U2A MCU建立在瑞薩用于底盤控制的RH 850/Px系列和用于車身控制的RH 850/Fx系列的關鍵功能之上，以提供更好的性能。



圖3. 由于其更高的性能水平和高達32MB的內(nèi)存，RH 850/U2B系列被定位在RH 850/U2A系列之上，如圖3。它旨在成為一個對成本敏感的單片機，以實現(xiàn)所述的區(qū)域架構概念。

RH 850/U2x MCU配備了最新的硬件支撐技術以支持多個ASIL-D軟件分區(qū)的集成。Hypervisor輔助功能使得以高性能方式運行Hypervisor操作系統(tǒng)成為可能，包括快速上下文切換以及靈活適應的Hypervisor中斷概念。服務質量（QoS）為所有總線主節(jié)點提供延遲監(jiān)測和主動調(diào)節(jié)功能，以確保最低帶寬始終可用。該功能僅在RH 850/U2B MCU上提供。

存儲器保護單元（MPU）實現(xiàn)了總線主節(jié)點對存儲器和其他資源訪問的隔離。一個高度靈活的外圍存儲器和外圍模塊的保護系統(tǒng)在資源層面上提供保護。額外的安全功能包括多個單獨的錯誤輸出信號，以確保在軟件分區(qū)層面的單獨處理。此外，AES128鎖步模塊的多個實例確保了無沖突和確定性的安全保障通信。為了涵蓋無等待的空中更新（OTA），能夠對單個Flash Bank進行背景操作，使個別軟件分區(qū)能夠獨立更新。

來自ETAS的ZCU軟件

ETAS的Hypervisor RTA-HVR支持Renesas RH 850/U2x，以滿足嚴格的汽車功能安全和信息安全要求。RTA-HVR使用瑞薩RH 850/U2x系列的硬件虛擬化功能來創(chuàng)建多個虛擬機。每個虛擬機都有一個或多個虛擬CPU核、一段內(nèi)存空間和一組外設。

每個VM是一個獨立的可編譯和可刷新的ECU軟件，可以由第三方構建并交付。RTA-HVR支持Autosar Classic平臺，并靈活地將物理CPU核分配給虛擬機。如果一個虛擬機對一個或多個CPU核有唯一的訪問權，那么虛擬機之間就沒有調(diào)度開銷。如果多個虛擬機共享一個CPU核，可以應用靜態(tài)配置的輪流調(diào)度或由RH 850/U2x后臺中斷驅動的動態(tài)預約式調(diào)度。

RTA-HVR使用MPU和保護概念在虛擬機之間提供空間隔離，為每個虛擬機劃分內(nèi)存和外設空間。

此外，RTA-HVR提供了一種稱為虛擬設備擴展（VDE）的機制，允許ECU集成商為ZCU定制虛擬和物理外設之間的綁定。VDE提供了一種在虛擬機之間共享外設的安全方式，例如，當需要一個外設的虛擬機數(shù)量超過硬件中的物理外設數(shù)量時。這里的典型例子是以太網(wǎng)控制器、硬件安全模塊和看門狗，或帶有額外CAN通道的擴展，如圖4。



圖4. VDE能夠創(chuàng)建完全虛擬的外設，以實現(xiàn)虛擬機之間對通信通道的優(yōu)化（ 瑞薩）

ZCU的虛擬化方案

為了支持ZCU的概念開發(fā)，集成多個應用，ETAS和瑞薩已經(jīng)開發(fā)了ZCU的虛擬化解決方案平臺。它結合了RH 850/U2x MCU和RTA-HVR的功能，包括預配置的虛擬機，每個虛擬機都包含使用ETAS的Autosar Classic平臺RTA-CAR的ECU軟件。另外還提供了一個基于PC的設計工具包，用于觀察實驗室環(huán)境下的運行行為，如圖5。



圖5. ZCU虛擬化實驗環(huán)境（ 瑞薩）

ZCU虛擬化解決方案平臺為RH 850/U2x MCU提供了一個預配置和預構建的軟件實現(xiàn)，作為一個易于啟動的開發(fā)平臺。它包含演示軟件和benchmark環(huán)境，使汽車客戶能夠快速開始為他們的ZCU項目進行設計探索。圖6顯示了兩種可供選擇的硬件。

ZCU PoC軟件棧包括一個RTA-HVR配置和四個虛擬機。每個虛擬機都被配置為在完整的ETAS RTA-CAR Autosa CP軟件棧上運行一套簡單的Autosar SWC（軟件組件模板）。虛擬機之間的通信使用RTA-HVR，VDE用于虛擬CAN，虛擬看門狗，以及訪問RH 850/U2x硬件資源。

RTA-HVR被配置為三個不同的有代表性的虛擬機配置，如下所示：

VM A：分配一個單獨的CPU核，單獨運行一個系統(tǒng)軟件 VM B0和VM B1：各分配一個單獨的CPU核，兩個虛擬機上運行一個系統(tǒng)軟件 VM C與VM D：共享一個CPU核，并各自單獨運行一個系統(tǒng)軟件，如圖7。



圖7. 設計探索工具中的虛擬機結構（ 瑞薩） 提供了兩種可供選擇的RTA-HVR配置，可以探索虛擬機調(diào)度策略的差異。

實時虛擬機狀態(tài)數(shù)據(jù)

ZCU虛擬化解決方案平臺提供了一個名為 "Design Exploration Tool "的PC應用程序，可以捕捉和顯示實時虛擬機狀態(tài)數(shù)據(jù)。運行所提供的不同的RTA-HVR調(diào)度策略，可以使開發(fā)人員輕松地與將嵌入式硬件和軟件集成起來。同時，可以使用ZCU虛擬化解決方案平臺研究故障注入虛擬機等功能，如觸發(fā)內(nèi)存非法訪問，測量性能和系統(tǒng)時間、以及RH 850/U2x硬件功能，如 OTA 或 QoS。

ZCU 虛擬化解決方案平臺與RH 850/U2x硬件一起發(fā)售，RH 850/U2A啟動套件或RH 850/U2B小板，RTA-HVR的二進制Flash軟件鏡像和每個虛擬機已構建好的鏡像，以研究調(diào)度和片上刷新，以及設計工具。

想了解更多信息的用戶可以申請三個月的評估許可證。包括Renesas RH 850 MCAL與配置工具，ETAS RTA-CAR工具用于配置和代碼生成，RTA-HVR的原型軟件，以及所有配置文件、源代碼和調(diào)試器腳本，使用戶能夠擴展或創(chuàng)建ZCU。

ETAS RTA-CAR工具又包括用于系統(tǒng)和應用軟件配置的ISOLAR-A以及用于基礎軟件配置的ISOLAR-B、RTA-RTE（Autosar RTE的代碼生成器），RTA-OS，以及RTA-BSW（Autosar基本軟件模塊的代碼生成器，包括CAN通信）。其他開發(fā)工具，如GreenHills RH 850/U2x編譯器（2019.1.5）和Lauterbach Trace32調(diào)試器或RH 850/U2x的瑞薩E2調(diào)試器。

總結

未來E/E架構的開發(fā)者面臨的任務是在不增加物理ECU數(shù)量的情況下擴展功能。解決方案是一個新的軟件架構和功能強大但成本低廉的硬件。區(qū)域架構要求ECU具有足夠的處理能力，以并行地運行各種應用程序，軟件通常來自不同的開發(fā)方，要求沒有干擾，而且每個軟件都確保實時性。

RH 850/U2A和RH 850/U2B微控制器，連同RTA-HVR Hypervisor，被設計用來支持這種集成控制器的開發(fā)。通過ZCU虛擬化解決方案平臺，瑞薩和ETAS提供了一套軟件包，支持客戶分析、開發(fā)、評估測試和展示未來E/E架構的ECU。


審核編輯：劉清