隨著 ICT 技術的發展，單 SOC 算力可以承擔更多業務，網絡帶寬拓展及低時延、區分服務等特性使得業務部署、功能分配更加靈活，比如 : 感知、融合、規劃、控制、執行可分離解耦，汽車業務功能可分可合、可軟件定義。電子電氣架構從分布式架構到域集中式架構，再到中央集中式架構轉變，分散的 ECU功能集成到域控制器甚至車載中央計算機，這就是多域融合。

汽車電子底層硬件不再是由單一芯片提供簡單的邏輯計算，而是需要復雜的多核 SoC 芯片提供更為復雜控制邏輯以及強大的算力支持。但是多域業務具有不同的技術需求，比如座艙域 IVI 業務強調交互體驗、應用生態豐富，比較適合的操作系統是 Android；儀表盤、輔助駕駛有實時性、可靠性要求，操作系統傾向于 RTLinux、RTOS；智駕域強調大算力融合感知、推演規劃，也有實時性、可靠性要求，也會選擇 RTLinux、RTOS。在域融合的同時，要保證關鍵業務的安全可靠，也要考慮應用生態的可持續性兼容，這就需要有資源隔離技術來支撐在同一 SOC 上切分資源，可并發運行多種操作系統，保障互不干擾。

資源隔離技術有多種，從硬件底層逐層向上包括硬件隔離、虛擬化隔離、容器隔離、進程隔離等。硬件隔離的隔離性最好，單隔離域的性能、安全可靠性最好，但靈活性、可配置性差，不能實現硬件共享，導致整個系統的資源利用率差，不能充分達到軟件定義汽車的目標。容器隔離、進程隔離可以更輕量級地實現業務隔離，但還是在同一個操作系統內，存在著資源干擾、相互安全攻擊的隱患，并且無法支持異構操作系統業務域融合，影響傳統業務繼承，不利于生態發展。在眾多的資源隔離技術中，虛擬化是安全可靠、彈性靈活的優選方案，是軟件定義汽車的重要支撐技術。典型應用場景如圖 1 所示：



圖1 虛擬化典型應用場景

技術形態

Hypervisor 直譯即 “超級監督者” ，也稱為虛擬機監控程序（VMM）。如圖 2 所示，Hypervisor處于 SoC 硬件平臺之上，將實體資源（如 CPU、內存、存儲空間、網絡適配器、外設等 ) 轉換為虛擬資源，按需分配給每個虛擬機，允許它們獨立地訪問已授權的虛擬資源。Hypervisor 實現了硬件資源的整合和隔離，使應用程序既能共享 CPU 等物理硬件，也能依托不同的內核環境和驅動運行，從而滿足汽車領域多元化應用場景需求。



圖2 虛擬化在系統中的位置

在汽車領域，Hypervisior 主要完成以下任務：

CPU 虛擬化：為虛擬機提供 VCPU 資源和運行環境；

內存虛擬化：負責為其自身和虛擬機分配和管理硬件內存資源；

中斷虛擬化：發生中斷和異常時，按需將中斷和異常路由到虛擬機進行處理；

虛擬機設備模擬：根據需求創建虛擬機可以訪問的虛擬硬件組件；

硬件支持 BSP：提供 Hypervisor 在 SoC 上運行的板級支持包，如串口驅動；

虛擬機資源配置：對虛擬機的 CPU，內存，IO 外設等資源進行配置和管理；

虛擬機通信：為虛擬機提供 IPC，共享內存等通信機制。

虛擬機調度：為虛擬機提供優先級和時間片等調度算法；

虛擬機生命周期管理：創建，啟動和停止虛擬機；

虛擬機調測服務：提供控制臺，日志等調試功能；

在汽車領域，Hypervisior 還面臨如下挑戰：

輕量高效。Hypervisor 在帶來軟件定義的靈活性的同時，也導致了軟件棧層次增加，不可避免會有性能損耗。汽車領域的成本敏感特性，注定了降低 CPU、存儲、網絡、GPU 等外設性能損耗的需求貫穿整車項目始終，因此 Hypervisor 的輕量和高效十分重要；

安全可靠。相較于互聯網領域看重的資源動態分配和閑置利用，汽車領域更看重 Hypervisor 的實時性、可靠性、安全性；

便捷適配。在汽車領域，芯片類型和操作系統豐富多樣，嵌入式虛擬化的一大特點就是異構，Hypervisor 必須具備快速適配不同的底層硬件和上層操作系統的能力。

技術發展趨勢

2.1 云邊端虛擬化關鍵技術差異化

虛擬化技術最早可以追溯到 20 世紀 60 年代，IBM 開發了虛擬機監視器軟件，將計算機硬件虛擬分割成一個或多個虛擬機，可支持多名用戶對大型計算機的同時、交互的訪問。隨著 21 世紀通用服務器算力的提升，云計算蓬勃發展，作為底層支撐技術的云虛擬化也快速迭代演進。后來算力從云、邊、端逐步下沉，也就伴隨著出現了邊緣虛擬化、端側嵌入式虛擬化。它們的典型架構、關鍵技術需求如圖 3 所示。



圖3 云邊端虛擬化典型架構及關鍵技術需求

（1） 云側虛擬化

其特點是硬件平臺基本同構，大量節點構成集群，架構設計以吞吐能力優先，要支持多業務并發，虛擬化要滿足集群負載均衡、節能降耗的資源調度策略，在進行跨節點虛擬機調配過程中，要保證業務無中斷遷移。虛擬機故障時，要能保證從檢查點恢復，減少業務損失，虛擬機要能支持 CPU 算力、內存、存儲空間、網絡、GPU、外設等能力的彈性擴展，還要能超分配，以便提升數據中心的運營收益。

（2） 邊側虛擬化

是在某些特定業務的邊緣節點上，采用通用 ICT 架構，支持多種業務的動態部署，典型如 SDN、NFV。其技術特點是：基于通用硬件平臺、行業定制的管理部署平臺，實現軟硬解耦、軟件定義，多功能節點按需部署、彈性組網，一般會采用 1+1 或者 N+1 冗余方式保證業務高可用，在 5G 電信網元中需要考慮 5G 業務端到端實時性，Hypervisor、虛擬機、通信協議棧都需要設計考慮。

（3） 端側虛擬化

端側典型特點是異構，其芯片架構、處理能力都差異較大。一般是單芯片方案，不存在著集群、主備間的虛擬機遷移，因此比較強調高安全、單節點高可靠，比如會有功能安全 ASIL 等級要求，同時對于實時性、確定性有更強的要求。另外，端側資源更加有限、成本更敏感，因此要求 Hypervisor 輕量化、高性能。

2.2 虛擬化模型趨勢

Hypervisor 可以劃分為兩大類，一類是 Type1 裸機型，Hypervisor 直接運行在硬件設備上的，也叫做 Bare-Metal Hardware Virtualization（裸機虛擬化環境）；一類是 Type2 主機托管型，也叫做 Hosted Virtualization （主機虛擬化環境）。圖 4 展示了兩種 Hypervisor 的分層架構。



圖4 Type1和Typer2型Hypervisor

Type2 型 Hypervisor 需要借助宿主操作系統來管理 CPU、內存、網絡等資源，由于 Hypervisor 和硬件之間存在一個宿主操作系統，Hypervisor 及 VM 的所有操作都要經過宿主操作系統，所以就不可避免地會存在延遲、性能損耗，同時宿主操作系統的安全缺陷及穩定性問題都會影響到運行在之上的 VM（虛擬機），所以 , Type-2 型 Hypervisor 主要用于對性能和安全要求不高的場合，比如 : 個人 PC 系統。

Type1 型的 Hypervisor 不依賴主機操作系統，其自身具備操作系統的基礎功能。設計上更簡潔，直接運行于硬件之上，整體代碼量和架構更為精簡，對內存和存儲資源要求更少，可滿足自動駕駛車控系統功能安全等級要求，也具備進行形式化驗證的條件。所以汽車操作系統更適合使用 Type 1 型 Hypervisor。

隨著微內核操作系統技術的發展，很多基于微內核操作系統設計的 Hypervisor 依賴的 Host OS 已經非常精簡，只包括基本的、不變的功能，如 : CPU 調度和內存管理，設備驅動和其他可變組件處于內核之外，這類 Hypervisor 應當歸于 Type1、還是 Type2，業內存在分歧。總體來說，微內核 Hypervisor 更小、更穩定、擴展性更好，更適合用于嵌入式虛擬化場合。

2.3 Hypervisor 與虛擬機協作技術路線

（1） 全虛擬化

最初的虛擬化是通過軟件模擬具有完整硬件系統功能的、運行在一個隔離環境中的計算機系統，即通過軟件虛擬硬件設備提供給 GuestOS 使用，優點是 GuestOS 不感知外部真實硬件環境、不用改動。由于 Guest OS 中每次訪問全虛擬化硬件都要陷入到 Hypervisor 中，直接導致該方式虛擬的硬件性能較差，一般只用來模擬如串口等比較簡單的硬件。對硬件的模擬可以在 Hypervisor 中直接模擬，也可以將請求傳遞到其他 VM 中進行模擬，如在某一 VM 中通過 QEMU 進行模擬。

（2） 硬件輔助虛擬化

Intel 最早提出硬件輔助虛擬化技術，由硬件直接提供共享功能，支持多 GuestOS 的訪問，減少軟件虛擬技術帶來的延時和性能損耗。Intel 提出了分別針對處理器 & 內存、IO、網絡的 Intel VT-x、Intel VT-d 和 Intel VT-c 技術等。隨著 ARM 算力提升，從移動端向邊緣、甚至云算力中心發展，ARM 也在不斷增強其硬件輔助虛擬化技術，比如 stage 2 頁表轉換、虛擬異常等。

（3） 半虛擬化

在硬件輔助虛擬化技術不完善、不強大的發展階段，或者對于某些復雜外設的共享復用，為避免全虛擬化的性能問題，可以采用 GuestOS 與 Hypervisor 協作的半虛擬化技術。這種技術一般應用于 IO 設備虛擬化，采用前后端的方式來實現 IO 設備虛擬化，在 Guest OS 中實現前端驅動，在 Hypervisor 或 Host OS 中實現后端驅動，前后端一般按照 VirtIO 標準來實現，后端驅動作為硬件的實際訪問方。

Guest OS 中前端驅動通過 Virt Queue 等通信機制與后端驅動進行通信，前端驅動將 Guest OS 的請求傳遞給后端驅動，后端驅動將請求發送給硬件驅動，處理完后將結果再傳回給前端驅動。半虛擬化相對全虛擬化實現的硬件性能較好，且可實現相對比較復雜的硬件，比如 : 塊設備，網卡，顯示設備等。具體如圖 5 所示。



圖5 半虛擬化Pass-through資源分配

Hypervisor 支持將硬件資源直接分配給其上虛擬機中 Guest OS 使用，無需通過 Hypervisor 進行地址和指令翻譯。例如 : 串口資源、USB 資源等接口比較豐富的資源可以通過 Pass-through 直接分配給某虛擬機使用。設備控制器一般都是以 MMIO 方式來訪問的，所以只需要將控制器地址區域映射到 VM 就可實現設備控制器的分配，同時還需要分配一個設備硬件中斷對應的虛擬中斷到該 VM，直接透傳的方式就是 VM 獨占訪問該硬件，所以在性能上是最好的。

關鍵技術解讀

3.1 CPU 虛擬化和節能降耗技術

車載高性能處理器一般采用多核 CPU 架構。在 SMP（Symmetric Multi-Processing 對稱多處理）架構下，Hypervisor 調度器會根據 CPU 的親和性配置讓客戶機操作系統在指定的 CPU 上運行，虛擬機的操作系統可按照自己的調度方式，比如:優先級方式在 CPU 上進行任務調度。為了最大化地利用系統資源，Hypervisor 也支持多個虛擬機對某個 CPU 的共享使用。

在共享核上，Hypervisor 可通過優先級或時間分區方式對虛擬機進行調度，確保虛擬機運行時間和調度策略是確定的。Hypervisor 的調度算法需要確保不能夠出現分區內某個虛擬機出現死循環或故障而長期占用處理器資源，導致其他虛擬機的業務無法得到合理時間配額的問題。 虛擬機調度還需要考慮節能降耗問題，在工作負載較高的情況下系統提升主頻提升用戶體驗，在工作負載較低的情況下系統自動節能降頻提升續航。

車載高性能處理器本身為了節能降耗需求設計為大小核架構，CPU 以及之上運行的復雜操作系統需要支持大小核調度，動態調頻，低功耗設置，關閉 CPU 核，休眠（Suspend to RAM/Suspend to Disk）等節能降耗功能。系統虛擬化后，CPU 等物理資源都需要Hypervisor 才能直接訪問，Hypervisor 調度算法也需要完成對虛擬機節能降耗的支持。

3.2 IO 設備虛擬化

出于性能考慮，一般嵌入式領域多使用半虛擬化技術。半虛擬化技術需要 Guest OS 中的前端驅動與Hypervisor 中的后端驅動配合實現。前端驅動將 Guest OS 的請求通過 Hypervisor 提供的通信機制發送給后端驅動，后端驅動通過調用物理驅動實現對設備的訪問。這就涉及到不同廠商的 Guest OS 與不同廠商的 Hypervisor 生態對接問題。

Virtio 是目前最流行的一種 I/O 半虛擬化解決方案。Virtio 是 OASIS 標準組管理的開放協議和接口，以使得虛擬機能夠標準化方式訪問 IO 設備。Virtio 于 2016 年 3 月正式標準化，2020 發布 V1.1 版本。Virtio 標準采用通用和標準化的抽象模型，支持設備類型不斷增加，性能高效，在云計算領域廣泛應用，開源活躍度高，Linux 等操作系統已有穩定的前端驅動代碼。

大部分商業和開源 Hypervisor 都已經支持Virtio 標準。 Virtio 是車載行業比較常用的半虛擬化技術的實現，如圖 6 所示，在 Guest OS 內部虛擬一條設備總線 Virtio-bus，通過 Virtio Ring 雙向通信機制，前端驅動與掛載在 Virtio-bus 上遵循 Virtio 標準的后端虛擬設備，進行訪問與通信。Virtio 提供了全面的 Virtio 總線和設備控制接口，包括 virtio-net， virtio-blk， virtio-console， virtio-input 等。



圖6 Virtio虛擬化實現模型

利用 virtio-blk 技術實現塊設備共享

塊設備是使用緩存機制讀寫的存儲設備，分配給 Hypervisor 所在的操作系統進行管理。virtio-blk driver 是符合 virtio 標準的塊設備驅動，vdev virtio block 是后端的虛擬塊設備，virtio blk driver 通過該vdev 設備完成對物理塊設備的讀寫，并獲取執行結果。

利用 virtio-net 技術實現跨系統通信

Virtio-net 實現了多系統間點對點的通信，Guest 系統內部的 virtio-net driver 通過 virtqueue 與Hypervisor 所在系統的 virtio-net 設備進行全雙工通信，實現多系統之間的控制類、配置類的指令、數據的交互。適合音視頻流以外的數據傳輸，穩定性較好，因 virtqueue 的控制邏輯復雜，對實時性有一定影響。

利用 virtio 技術實現觸摸共享

觸摸設備是字符型設備，通過 virtio-input driver、vdev-input 實現前端驅動和后端設備。設備端通過 virtqueue 向驅動上報觸摸坐標數據。

3.3 實時性技術

實時性是嵌入式實時操作系統的關鍵性能指標。Hypervisor 的實時性是整個系統實時性的基礎，如果 Hypervisor 無法及時調度到客戶機操作系統運行，客戶機操作系統也不能取得較好的實時性指標。衡量 Hypervisor 實時性主要指標包括中斷延遲和調度延遲。

中斷延遲以硬件發生中斷時刻為起始時間，以虛擬機收到 Hypervisor 注入的中斷時刻為截止時間，在各種壓力情況下最長延時時間即為中斷延時。調度延遲是指以高優先級的虛擬機進程就緒為起始時刻，以該高優先的虛擬機進程得到調度運行為截止時刻，在系統各種壓力情況下最長的延時時間即為調度延遲。

中斷虛擬化后，當外界中斷產生時，Hypervisor 收到并以最快的速度注入到虛擬機，使得 Hypervisor 對虛擬機中斷處理時間足夠少。Hypervisor 優化虛擬機的切換時間，盡量減少 Hypervisor 上關中斷和關搶占的時間，盡量少使用內核鎖，當高優先級的虛擬機需要切換運行時，能最快速度切換至高優先級虛擬機上運行。

3.4安全和可靠性技術

功能安全、信息安全和可靠性是車控操作系統產品可靠安全運行的必要組成部分。Hypervisor 為智能汽車域控制器提供基礎運行環境，其安全性和可靠性是保證整個系統功能安全和可靠的基礎和核心。Hypervisor 需按照汽車功能安全 ISO26262 ASIL-D 最高標準進行設計，開發和測試，其功能安全需求由域控制器產品的安全需求分解產生。

Hypervisor 上運行了多個虛擬機，一個虛擬機的異常不能傳遞至其他虛擬機。Hypervisor 能獲取到當前系統整體健康狀態，當虛擬機發生異常時，Hypervisor 應實時監控系統健康狀態，有效地隔離故障，并在最小波及范圍內修復異常，保障系統持續可用。

Hypervisor 加入汽車軟件棧，會導致縱向上軟件棧層次增加，橫向上業務軟件復雜度增加，而汽車的安全可靠要求強于既有的云側虛擬化、邊緣虛擬化，因此虛擬化安全性正日益得到行業的關注。這些安全性包括：

虛擬機管理器和虛擬機之間的信任鏈問題。利用虛擬化技術在一個可信物理平臺上創建出多個虛擬機，并將從硬件可信根開始構建的信任鏈傳遞到每一個虛擬機，從而在一個可信物理平臺上構建多個虛擬的可信計算平臺，有些解決方案缺乏虛擬機管理器到虛擬機之間的信任鏈驗證；

虛擬機間的攻擊：惡意入侵者可以通過利用虛擬機管理程序中的漏洞，通過同一物理主機上存在的另一個虛擬機來獲得對虛擬機的控制，從而破壞目標虛擬機；

虛擬機逃逸：利用虛擬機軟件或者虛擬機中運行的軟件的漏洞進行攻擊，以達到攻擊或控制虛擬機宿主操作系統的目的。

為了提高 Hypervisor 的安全性，建立相應的安全性目標很重要，下表簡要列出相關要求：



Hypervisor 的安全性能力可以從三個維度進行提升。

（1） 需要建立安全邊界

如圖 7 所示，這個邊界由 Hypervisor 嚴格定義并且實施。Hypervisor 安全邊界的保密性、完整性和可用性需要得到保證。邊界能防御一系列攻擊，包括側向通道信息泄漏、拒絕服務和特權提升。虛擬機監控程序安全邊界還提供網絡流量、虛擬設備、存儲、計算資源和所有其他虛擬機資源的隔離能力。



圖7 安全邊界 整體虛擬化安全架構如圖 8 所示。安全邊界的保密性可以通過傳統的密碼學方法來實施。完整性通過可信度量機制來保障，可信報告機制實現不同虛擬環境的可信互通，監控機制動態度量實體的行為，發現和排除非預期的互相干擾。虛擬技術提供的隔離機制將實體運行空間分開。



圖8 整體虛擬化安全架構

安全邊界的隔離通過Hypervisor的vCPU調度隔離安全、內存隔離、網絡隔離和存儲隔離技術來支持，實現了同一物理機上 Hypervisor 和虛擬機、虛擬機之間的隔離。

（2） 需要建立深度防御漏洞的緩解機制 對于安全邊界存在的潛在漏洞，Hypervisor 需要有一定的技術手段進行主動防御，這些技術手段包括地址空間布局隨機化（ASLR）、數據執行保護（DEP）、任意代碼保護、控制流保護和數據損壞保護等。

（3） 建立強大的安全保障流程 與 Hypervisor 相關的攻擊面包括虛擬網絡、虛擬設備和所有跨虛擬機表面，所有虛擬機攻擊面都建議實施威脅建模、代碼審核、模糊（fuzzed）測試，通過建立自動化構建及環境，觸發定期安全檢查。

虛擬化技術作為云計算場景的重要技術，在 10 多年的生產實踐中已經積累了很多安全范式，這些經驗也可被汽車場景借鑒。但是與云場景相比，汽車場景的虛擬化技術也有其特殊性，如虛擬機不需要動態遷移 / 創建，Hypervisor 有功能安全等級的要求等等，其安全性手段需要在實踐中不斷豐富和完善。

典型應用案例

在汽車智能化發展歷程中，虛擬化主要應用于智能座艙、智能駕駛、智能網關等融合場景。智能駕駛受技術成熟度、政策法規所限，基本處于預研、方案原型階段。智能網關業務功能相對同構，并且有可能進一步融合到其他場景方案中。因此，目前主要的應用案例集中在智能座艙中。

智能座艙域融合也是在近幾年啟動，正在不斷迭代演進中。受芯片算力、虛擬化技術成熟度、生態鏈對于虛擬化解決方案的掌控能力等因素影響，有些廠商同時采用了硬隔離方案來實現域融合，一方面最大程度地沿用既有技術能力，有確定性保障，但是缺少了軟件定義的靈活性，智能化程度有限，是域融合的一種可選方案。

在嵌入式虛擬化技術方面，國外的 QNX、OpenSynergy、PikeOS 等有先發優勢，尤其在汽車領域已耕耘多年，因此在這兩年涌現了較多的應用案例。在智能本土化發展的趨勢帶動下，國內這幾年也出現了不少芯片廠商、獨立軟件廠商研發嵌入式虛擬化技術、產品、解決方案，如中瓴智行的 RAITE Hypervisor(RHOS)、中興 GoldenOS、斑馬智行的 AliOS Hypervisor、中汽創智 CAIC Hypervisor 等。

4.1 智能座艙域控制器產品

某廠家智能座艙域控制器產品，如圖 9 和圖 10 所示，基于高通 8155、瑞薩 R-Car H3 處理器，采用 QNX Hypervisor，搭載 QNX Host、 Android P/R/S Guest OS, 可配置輸出最多 6 塊高清大屏獨立顯示，集成了娛樂系統、液晶儀表、車身控制、DMS、APA 等功能，支持獨立四音區、多屏互動和音視頻分享，集成度高，在長城、長安、宇通客車等多款車型上適配量產。 另外，國產化方案芯馳 X9HP+ 平臺，采用硬分區、Hypervisor 兩種方案靈活配置實現中低端智能座艙域控制器產品。

4.2RHOS 智能座艙域控制器平臺

（1） NXP I.MX8QM 座艙域控制器 某廠家基于自研的 Type-1 型虛擬化軟件 RHOS(Raite Hypervisor OS)，適配支持了 NXP I.MX8QM，提供一個輕量、靈活的汽車智能座艙虛擬化解決方案，已在東風車型量產上市。其系統架構如圖 11所示：



圖11 NXP I.MX8智能座艙系統架構

在 SoC 上運行 Hypervisor 后可支持同時運行多個操作系統，比如 Linux 系統可以運行實時性和安全性較高的業務，如全液晶儀表等，可以擴展運行 DMS、HUD 等業務。另外一個虛擬機運行 Android 操作系統，上面部署信息娛樂等安全性和實時性要求較低的業務。為保證系統具備良好的市場競爭力，域控制器兼容 TBOX 功能需求，系統能夠支持休眠喚醒和快速啟動。

Linux 和 Android 虛擬機可按需進行資源的配置，包括內存、CPU、存儲空間、外設等。該架構支持系統升級，包括對虛擬機和 Hypervisor 的升級，支持異常日志記錄，包括虛擬機內核和 Hypervisor 日志。 多屏交互是智能座艙重要的應用場景，Android 的 APP 應用程序可以通過 Hypervisor 推送到 Linux儀表進行顯示。



圖12 虛擬機多屏交互架構

Android 和 Linux 儀表交互的方案如圖 12 所示。NXP I.MX8QM 芯片有兩個以上顯示接口，每個顯示接口可以接 2 個顯示屏，當 Android 系統需要投射信息到儀表屏幕時，儀表顯示屏的 Overlay 圖層可以進行投屏內容的顯示。系統交互零延遲、零拷貝，多系統交互不額外占用 CPU 和 GPU 資源。

通過Hypervisor 虛擬化技術實現跨系統多屏交互，有效提高了行車安全性，并降低智能座艙的硬件成本。

（2） MT8675 座艙域控制器

RHOS 通過適配支持MT8675，形成一個功能豐富、性價比高的一機多屏智能座艙域控制器解決方案，已獲得多個車廠量產項目。其總體系統架構如圖 13 所示：



圖13 MT8675智能座艙系統架構

MT8675 只提供了一個 GPU，座艙域需要在儀表和中控上共享使用 GPU 資源。RHOS 實現了 GPU虛擬化共享，并通過性能優化，達到業界領先的虛擬化效果（損耗 < 6%）。RHOS 支持 Suspend to RAM 功能，MT8675 A 核完全下電，滿足智能座艙待機靜態功耗小于 4mA 要求。