在 6 月 28 日的第二屆英飛凌汽車創新峰會上，英飛凌科技正式發布了采用28 納米工藝技術生產的 AURIX? TC4x 系列微控制器（MCU），進一步增強其 AURIX? 微控制器家族的產品陣容。

圖1

#01 產品 Overview

1.1 AURIX? TC4x 產品總覽

2014 年，英飛凌推出了第一代 AURIX? TC2x  系列，首次在單片機中集成多達三個 TriCore?  內核，為汽車電子帶來了前所未有的多核處理能力。

2018 年，第二代 AURIX? TC3x 系列推出，進一步將多核處理能力提升到新高度，集成多達六個 TriCore? 內核。該系列在實時性能、功能安全（最高等級 ASIL-D）、信息安全等方面表現卓越，特別適用于各種汽車應用，也在市場上或得了巨大的成功。

如今，英飛凌推出了新一代 AURIX? TC4x  系列。該系列采用新一代 TriCore?  1.8 內核，并引入了增強性能的加速器套件，包括并行處理單元（PPU），為人工智能和實時控制應用提供強大支持。主要面向電氣化領域（BMS、逆變器等）、區域控制、ADAS、底盤和車身控制領域，如下圖所示：

圖2

1.2 AURIX? TC4x 功能概述

針對上述場景，TC4x 從功能安全、信息安全、高速內部通信路由、內核等方面做了進一步提升，整體架構如下圖所示：

圖3

與 TC3x 相比，TC4x 系列各方面進一步升級：

1）CPU 升級

• TriCore?從 v1.6.2 升級到 v1.8，頻率從 300MHz 提升到 500MHz，最高支持 6 對鎖步核同時運行，算力已逼近低端 SoC，例如 TC4Dx 系列算力可達 8000 DMIPS（雙核 A53 算力 7360 DMIPS）；

• 新增兩級 MPU，引入虛擬化功能；

• 新增雙精度浮點運算，滿足 IEEE754-2019；

• 新增 128bit load\store 指令以提升效率。

2）NvM 升級

• 容量上最高支持 25MB NVM，基于 TC3xx 的 A\B SWAP 機制進行迭代優化，真正實現了零停機升級；

• 在后續產品中引入 RRAM 技術，該技術與臺積電共同研發已久，這對汽車 OTA 格局是不小的沖擊。

3）新增加速引擎

• PPU（Parallel Processing Unit) ：并行處理單元，旨在替 CPU 完成復雜信號處理和數學運算 ，助力 AI 功能在 MCU 中的安全實現；

• CSRM（Cyber Security Real-time Module）\CSS（Cyber Security Satellite）：硬件密碼加速器；與 TC3x HSM 相比，TC4x 提供兩個不同的硬件加密模塊，支持的加密算法和加密性能得到進一步提升，在后量子密碼時代獨樹一幟；

• CRE（CAN Routing Engine）\DRE（ Data Routing Engine) ：數據路由引擎；硬件層面實現 CAN-CAN 、CAN-ETH 、CAN-MEM 數據的路由和轉發。

4）新增可擴展高速通信接口

• PCIe

• CAN XL

• 5Gbps Ethernet

上述接口在區域控制器中以以太網環形網絡架構中實現了高帶寬 、低延遲的效果。

接下來，我們就詳細解讀其關鍵技術。

#02 關鍵技術解讀

2.1 NvM

2.1.1 NvM 容量

NvM 容量和 RWW（Read-while-Write）特性向來是 Tier 1 、OEM 在產品芯片選型時最關心的 Feature 之一。

為適應新的區域控制器架構要求，支持多應用融合，TC4x 延續了 TC3x 的 NvM 設計精髓并做出優化，每個內核可通過獨立接口快速訪問 2 個 PFlash Bank，實現真正零待機 SOTA；設計出獨立 Security P\DFlash ，保證 Host 與 HSM 之間物理隔離，具體示意如下：

圖4

CPU 通過 PFI 接口可以獨立訪問與之關聯的 PFlash Bank，實現快速指令訪問，并且由于 CPU 關聯兩塊 PFlash ，實現了 RWW，對 SOTA 非常友好。

通過 DMU 訪問 DFlash ；通過 DMU 、FSI 對 P\D Flash 進行操作；

Host 每個 PFlash Bank 容量為 2MB， 最高支持 24MB(6 CPU*2 Bank*2 MB) ，Security PFlash 為 1MB， 總計 25MB；

DFlash0 最高 1MB，DFlash1 為 128KB，均用于 EEPROM。

從地址映射上，仍然延續 TC3x 的 Cacheable 地址 8H，Non-Cacheable 地址 AH，這在使用習慣上是非常好的繼承。

然而隨著 MCU 算力要求不斷提高，倒逼工藝制造向先進制程進發，28nm、22nm 甚至 16nm 已經被提上日程，但 eFlash 微縮化困難嚴重阻礙了進程，該瓶頸亟待解決。

2.1.2 RRAM 開辟 NvM 新道路

據臺積電官網介紹，英飛凌與臺積電早已聯合研發 RRAM(Resistive RAM) ，致力打破 22nm、 28nm 車規 MCU 的 NvM 瓶頸。

RRAM 相比于 eFlash ，具有更高的擴展性、更低的成本和更低的功耗。

作為結構最簡單的存儲技術，它看上去像一個三明治，絕緣介質層（阻變層）被夾在兩層金屬之間，形成由上、下電極和阻變層構成金屬-介質層-金屬（ metal-insulator-metal ，簡稱 MIM）三層結構。

圖5

RRam 利用阻變原理實現存儲等功能，基于阻變層中導電通路（一般稱為 conductive filament, 導電細絲）實現，通過在上、下電極施加不同的脈沖電壓激勵，使介質層發生阻變，產生物理性變化。

導電細絲會在阻變層中呈現導通或斷開兩種狀態：非易失性的低阻態（Low Resistance State， LRS） 或高阻態（ High Resistance State， HRS），從而實現了“0”，“ 1”狀態的區分和存儲。

了解其原理后，作為軟件工程師最關心的還是怎么用，如果能做到軟件移植平滑，指令操作上比TC3xx更簡單，這將在OEM/Tier1做區域控制器產品選型時是一個非常棒的加分項。

英飛凌與臺積電聯合開發 RRAM 已有十余年， 技術上是否有更進一步的創新？ 未來會用在 TC4x 哪些產品型號，我們拭目以待。

2.2 SOTA

之前我們描述了 TC4x 關于 NvM 的排布，很明顯一顆 CPU 關聯 2 塊 PFlash Bank 是非常有利于 SOTA 實現。

在 TC3x 上面我們基于硬件做 A\B SWAP，特別是 TC39x 系列，雖然說存在異步域的情況，但在邏輯地址和物理 bank 的映射上還是存在讓人困惑的地方，如下圖：

圖6

可以看到，雖然邏輯地址沒有改變，但在不同地址映射模式下 PF0\1 與 PF2\3 切換，PF4 與 PF5 切換，最容易讓人迷糊的就是邏輯地址與物理 Bank 的映射問題，鎖板子的事情常常發生。

這個問題在 TC4x 系列有所緩解，在不使用硬件 SOTA 機制的情況下(這里暫時不聊 HSM PFlash)，最高可支持 6 核 24MB 線性地址訪問(0x8000 0000-0x817F FFFF) ，如下圖：

圖7

那當我們使用了 SOTA 機制，好玩的來了，如下圖：

圖8

地址做成了連續，該模式下 Host 最高支持 12MB，同時，為了不混淆，還特意將 Inactive Back 的地址往后挪了一點(0x8200 0000) ，這樣咱們在使用上就明晰了很多。

TC4x 的 SOTA 支持兩種地址映射，上圖為 A 模式， B 模式下灰色和橙色 Bank 對調即可。

當然 HSM 同理，雖然它只有一個 1MB 的 PFlash，仍然支持 A\B SOTA，看來這個 Flash IP 還重新規劃了 Bank 容量的。

在 SOTA 使能和配置方面，繼續使用 UCB 進行 SOTA 的使能和 Bank 切換，經典的 55h 對應 A 地址映射，AA 對應 B 地址映射。

總結下來，TC4x 應該是總結了 TC3x 用戶反饋，并且基于區域控制器做了場景分析，從使用上來看更為方便，也更容易理解。

那么聊到了區域控制，就不可避免地要談多功能融合，而對于一顆 MCU 來說芯片資源是有限的，因此資源競爭資源隔離成為了區域控制器實現的關鍵技術路徑。

一般來講，應基于硬件資源隔離是最可靠的方式，但是不能資源共享給應用；于是虛擬化隔離出現了，接下來我們從虛擬化技術分類開始，掌握 TC4x 虛擬化的基本概念。

2.3 虛擬化

2.3.2 虛擬化技術

虛擬化技術按照虛擬化層次通常可以分為硬件虛擬化和操作系統虛擬化兩類。

2.3.2.1 硬件虛擬化

硬件虛擬化依賴 Hypervisor（虛擬機監視器）和 CPU 的虛擬化擴展，根據 Hypervisor 部署方式，可進一步細分為 Type1 和  Type2 兩類；

• Type1 類型的虛擬化

Hypervisor 直接運行在裸硬件上，也叫作裸機虛擬化，如下圖，

圖9

該類型的 Hypervisor 能夠直接操作控制硬件并管理多個虛擬機（ Guest VM）。每個虛擬機都有自己的操作系統和應用程序，可以完全獨立運行。

• Tpye2 類型的虛擬化

與 Type1 類型的虛擬機不一樣，Type2 類型虛擬化是指在已經裝載好 OS 的硬件上運行 Hypervisor，這個軟件作為應用程序管理多個 Guest VM。

圖10

可以看到，Type 1 和  Type2 的虛擬化最大區別在于 Type 1 的 Hypervisor 可以直接操作硬件，沒有多余的開銷，性能相對較高；Type2 的 Hypervisor 訪問硬件資源，還必須經過 Host OS。

因此在汽車領域，由于對功能安全等級、實時性有較高要求，一般均使用 Type1 的 Hypervisor，Hypervisor 之上直接運行多個客戶操作系統  (GuestOS)；

那么 Hypervisor 是如何來管理和隔離硬件資源，保證各個不同功能的應用程序的資源使用安全和資源調度？

個人理解，資源安全需要從 vCPU 調度隔離、內存隔離、存儲隔離、中斷虛擬化及隔離 、網絡隔離等方面來保證安全，如下圖：

圖11

在 vCPU 的調度中，常見的Armv8-R 架構提供了 EL0-EL2的等級，每個等級可運行的指令不一樣，通常EL0 運行 APP，EL1 運行 GuestOS，EL2 運行Hypervisor（負責 vCPU的上下文切換），實現 GuestOS 和Hypervisor的隔離。

2.3.2.2 操作系統虛擬化

操作系統虛擬化一般就是指容器技術，由操作系統內核提供的資源隔離和控制功能，創建出多個相互隔離但共享系統內核的用戶空間實例，從而實現對多系統運行能力的支持。

進一步講，容器技術就是將操作系統所管理的計算機資源，包括進程、文件、設備、網絡等分組，然后交給不同的容器使用。

容器中運行的進程只能看到分配給該容器的資源。從而達到隔離與虛擬化的目的。實現容器技術需要用到 Namespace 及 cgroups 技術。

典型代表就是 Docker 公司在 2013 推出的輕量級虛擬化技術--Docker 。結構如下圖：

圖12

在這種虛擬化機制下，操作系統內核被每個容器共享，每個容器使用相同的 OS，由 OS 來分配資源，不過正是因為這種多個 App 共享內核的機制，可能存在漏洞或攻擊風險。因此目前容器化場景在汽車中還沒看到實際應用。

2.3.2 MCU 為什么要提虛擬化

在汽車行業里，虛擬化的概念最先由座艙域引入，目的是在同一顆 SoC 上實現儀表和中控兩個系統的功能，在 Hypervisor 的管理下基本可以不修改舊代碼就可移植到最新的硬件上，如下圖：

圖13

隨著區域控制器概念的提出，以前底盤、車身域控下掛節點的功能有可能會被整合或者直接移植到高性能的區域控制器 MCU 中，這種集成難度和整合工作難度不小；

試想，BCM、PowerControl、BMS 等功能即使在 OEM 里也是不同部門進行開發，在操作系統、硬件資源上差異可能很大，要想減輕集成難度，充分利用 MCU 資源，在沒有虛擬化的情況下勢必需要重新規劃軟硬件架構；

再惡劣的情況，如果下掛子節點是由供應商黑盒交付，OEM 想要完成集成工作，引入虛擬化是最省錢省事的方案，如下圖：

圖14

在上述示意中，我們通過 VM(Virtual Machine，虛擬機)來實現上述集成工作。虛擬機模擬了一個完整的計算機系統，包括處理器、內存、存儲設備和其他硬件，這就意味著在同一臺物理計算機上可以同時運行多個操作系統和應用程序。

其中，VM0 用于運行 Hypervisor，用于創建和管理虛擬化環境，例如 VM1-4，同時還負責 VM1-4 的時間調度、資源管理、數據通信等；VM1 用于電池管理系統、VM2 涵蓋了 DC/DC 和充電功能 、VM3 集成了 Inverter 和 PDC，VM4 可以運行車身控制，每個 VM 都可以使用獨立的操作系統（ RTOS、AUTOSAR OS 等等），從某種意義上講，VM1-4 甚至都認為自己獨占了整個 MCU 資源。而從硬件角度，CPU0 里既包含了 VM1 還包含了 VM2，CPU1 里包含了 VM2 和 VM3，依次類推。

2.3.3 TC4x 的虛擬化

由于 VMn 是基于時間片分時復用芯片資源，因此對于算力和硬件虛擬化特性都提出來以前 MCU 沒有的新需求。

TC4x 設計了 TC1.8 ，最高主頻可達 500MHz，算力上得到巨大增加。

同時支持虛擬化輔助功能，該功能可以根據需要進行使能；

針對虛擬化，每個核有三套獨立硬件資源 HRHV 、HRA 、HRB，可支持最大 8 個 VM，其中 VM0 運行 hypervisor，VM1 運行實時虛擬機，VM2-7 運行其他 VM，如下圖所示：

圖15

• HRVH – Hypervisor hardware resource（ VM0）；

• HRA – Real time virtual machine hardware resource (VM1)；

• HRB – Other virtual machine hardware resource (VM2-7)。

MCU 上電后，如果內核支持虛擬化，那么所有 HRHV 里的資源均可以被訪問了，這個時候啟動代碼就可以開始設置 Hypervisor 需要的狀態，這里面包含了虛擬化功能的使能、關于 NMI 處理層級的配置(Hypervisor 或者普通 VM 處理) 、目標 VM 的序號等等，如下圖：

圖16

既然每個核支持最大 8 個 VM，那么針對中斷的處理也有對應 8 套資源，那么就引發了幾個問題：

• 假設被分配到的 VM 此時還沒有運行怎么辦？

• 假設被分配到的 VM 此時正在處理中斷怎么辦？

我們按照正常物理中斷處理流程做出假設，VM 之間也可以進行搶占，得到如下：

正常時間片為 2000us，VM1 占用 500us，VM2 占用 1000us，VM3 占用 500us；

當 VM2 正在運行時，此時來了一個 VM1 的中斷，該中斷可以搶占 VM2 的時間，所以此時 Hyperviosr 需要將 VM2 的上下文保存，并切換到 VM1，讓其完成 ISR 處理，然后恢復現場 VM2 繼續運行；

當 VM3 正在運行時，此時來了一個 VM2 的中斷，但它不可搶占 VM3 的時間，所以需要 VM3 運行完畢后切換到 VM2 的 ISR 進行處理，當然這里也擠壓了 VM1 的時間。

TC4x 是如何實現上述功能的呢？

在他們的設計中，每個中斷 SRN 都可以被拓展分配給 1 個 VM；每個 VM 都有自己獨立的中斷狀態控制寄存器，包括當前 VM 中斷系統是否使能(簡稱 VMIE) 、當前 VM 的優先級(簡稱 VMCP) 、Pending 中斷優先級(簡稱 VMPIP)；

為了實現運行 VM 在收到其他 VM 中斷時可被搶占，新增了搶占閾值寄存器，簡稱 THR，好玩的就來了。

假設當前正在運行 VM1，此時來了一個 VM0 的中斷，如果此時進來的 Pending 中斷優先級高于 VM0 配置的搶占閾值，同時高于 VM0 的當前優先級，那么 Hypervisor 就需要進行上下文切換，返回到VM0 處理中斷，偽代碼如下：

if (INT.VM_coming == current VM){        if ((VMPIP > VM_coming.VMCP) && (VM_coming.IE )        {               isr_routine();          }        else        {                Keep INT Pending          }}else (INT.vm_coming == VM0 ){        if ((VMPIP > VM0.VMCP) && (VMPIP > VM0.THR)
        {            Switch to HRHV                isr_routine();        }        else        {            Keep INT Pending        }}

同理，如果當前 VM0、VM1、VM2 同時運行，也需要執行上述步驟 。如 VM2 要搶占 VM1 時，由于 VM1 獨享 HRA，因此可直接切換到 HRB 讓 VM2 進行中斷處理。

本質上，這樣的機制和透傳很像，只是我們可以通過 Hypervisor 配置每個 VM 的中斷狀態控制器寄存器、搶占閾值寄存器來實現中斷實時性的控制，  例如：

當我們把閾值配置為最大時，此時誰也無法進行搶占(Trap 除外)，只能得到時間片走完；如果閾值配置為最小，那就是直接透傳，這時候性能最優。

2.3.4 基于 TC4x 的 Hypervisor

通過 2.3.3 小結，我們對 TC4xx 的虛擬化有了一定的了解，也不難看出，其中最關鍵的還是運行在裸板上的 Hypervisor 軟件。

目前已知的 關于MCU Hypervisor 軟件主要由基礎軟件供應商提供，例如Vector 的 veHypervisor，基于 Type1Hypervisor 架構實現，滿足 ASIL-D 要求，如下圖：

圖17

EB 與英飛凌聯合開發基于 AURIX TC4x 的 AutoCore OS 和 EB tresos Embedded Hypervisor，支持 OEM 和 Tier 1 更輕松地開發和部署基于  AUTOSAR Classic 標準的汽車 E/E 架構，助力下一代車輛的加速開發：

圖18

ETAS RTA Lightweight Hypervisor

圖19

不管上述各家對于 Hypervisor 的描述如何變化，本質上還是在強調在一顆 MCU 里多 VM 場景的并行運行和資源隔離，不僅要支持不同操作系統，還要需要穩定安全高效的時間調度機制來支持多 VM。

2.4 加速器

2.4.1 PPU

在 ADAS 領域里，大家很有默契地幾乎都用 TC39x 系列作為功能安全島，除此之外 MCU 還承接車內 CAN 報文收發，雷達數據等輔助處理，常見架構如下：

圖20

根據雷達在汽車布局位置分為前雷達(Front Central Radar) 、側后雷達(Side-Rear Radar)以及泊車系統使用的超聲波雷達(Ultra Sonic Sensor)；

根據測距不同分為 24GHz 和 77GHz 雷達，可見信號處理上的復雜性；而在雷達數據的處理上通常都會用到快速傅里葉變換(FFT)用于頻率分析、波束形成等等，在數據處理上針對單個數據點使用標量算法，針對多個數據點組合進行向量運算等，在波束形成時進行矩陣運算，在 TC3x 系列中，我們使用 RIF 和 SPU 來完成上述計算，如下圖：

圖21

而隨著智能駕駛邁向新的階段，復雜應用模型需要更強大的計算能力，為此，TC4x 產品里設計出并行處理單元 PPU( Parallel Processing Unit) ，用于實現數據處理需求大或執行時間要求快的模型，例如信號濾波、算法處理、模型預測控制等。
PPU 其結構如下：

圖22

• 標量處理單元里包含了一顆 32bit 標量核，它支持雙精度浮點運算，用于執行大量標量運算；

• 向量 DSP 處理單元，位寬 128~256bit ，支持 SIMD(單指令多數據)指令，支持浮點向量運算、專用信號處理，提高計算效率；

• DMA、Memory：分別用于數據搬運，輸入和輸出臨時存儲等。

除了智駕方面應用，PPU 也可應用在電機矢量控制上，在算法上坐標變換使用三角函數、觀測器迭代、鎖相環鑒相等等操作是非常消耗 MCU 的計算資源，PPU 中的 Vector DSP 單元可以有效加速實時觀測計算，從而幫助 Tricore 提高運行效率。

PPU 還可用于基于 AI 的電池診斷，包括鍍鋰層檢測，電池健康狀態(SoH)和老化軌跡預測，剩余使用壽命（RUL）預測等等。

在開發 PPU 時，我們可以結合相關應用模型和 PPU 對應軟件庫。

Mathworks 在官方提供了基于 TC4x 的 Tricore 與 PPU 通信的模型、基于 PPU 的電機矢量控制模型等；

新思科技為 TC4x 的 PPU 提供了豐富的軟硬件支持，在向量 DSP、神經網絡處理、AUTOSAR 適配等提供了豐富的資源，例如 MetaWare Development Toolkit、MetaWare Neural Network SDK 用于基于 PPU 優化的模型變異等等；

圖23

總體而言，PPU 主要是為了 Tricore 承接了 A I 、電機控制、區域控制等復雜的信號處理和數學運算；由于 PPU 本身特性，在計算效率上更快，Tricore 則主要用于控制，這與現有異構 SoC 的設計理念已經非常相似了；我想這也是未來 MCU 的發展趨勢之一。

2.4.2 數據路由加速器

在整車中央計算平臺等架構里的網絡通信概念通常以以太網為主干，它連接了中央計算平臺、各區域控制器；在區域控制器里使用其他通信網絡連接下掛節點。

架構概念如下：

圖24

目前主流的車內通信手段是以 CAN \ CANFD 和車載以太網為主，區域控制器間通過以太網為通信，在區域內仍以 CAN、CANFD 為主 。因此，不同域之間的 ECU 節點進行通信，就必須要經由 CAN->ETH->CAN 的通信路徑，所以這中間就存在如下問題：

• 以太網應該使用什么傳輸協議保證 CAN 的有效 paly load 不丟失；

• CAN 是周期廣播形式，以太網多是點對點事件觸發，這需要做什么樣的優化？

• 區域控制器承接部分網關作用，在數據路由上需要達到什么樣的性能？

對于網關來說，最重要的就是路由數據一致性和時效性。在 AUTOSAR 技術視角里，報文的路由基本都會放在PduR層級進行處理。以CANFD路由到CAN 為例，通常會經過 CAN0->CanIf->PduR->CanIf->CAN1 這樣一個路徑，其路由表在PduR 定義，顯而易見，這在數據延遲方面做不到性能最優，我曾經為了百 us 級的路由在 CanIf 層手擼了一套定制化的PduR，頭大不已。因此一直在想如果在硬件設計這樣一套路由機制，將PduR中的路由表承接下來，那這數據路由的延遲將會大大降低，概念如下圖所示：

圖25

為此，英飛凌 TC4x 提出了 DRE、CRE 等等用于 CAN2ETH 、CAN2CAN 等數據路由硬件加速功能。

TC4x 芯片所有加速硬件的總體結構如下：

圖26

我們主要介紹 CRE 和 DRE 兩個模塊。

• CRE： 位于 CAN 模塊內部， 可用于路由 CAN 消息到模塊內部其他節點。

TC4x 支持 5 個 CAN 模塊，每個 CAN 支持 4 個節點，總計 20 個 CAN Channel。在每個 CAN 模塊內部有一個 CRE(CAN Routing Engine) ， 用戶只需要配置相應的路由表（寄存器），即可實現模塊內部節點間的 CAN  路由，如下：

圖27

• DRE： 用于 CAN 和 Ethernet 的相互路由，和 CRE 完成 CAN 幀到不同 CAN 模塊的路由。DRE 最重要功能就是把 CAN 幀路由給 Ethernet 幀，這就涉及到我們前面提到的問題：這種  CAN->ETH 應該以什么樣的格式對數據進行封裝？

在 DRE 里采用的是 ACF 格式對 CAN 進行封裝。ACF 全稱 AVTP Control Format，它是 AVTP 協議的子集，AVTP（Audio/Video Transport Protocol）里定義了 CAN\CANFD ACF message 數據格式，如下圖：

圖28

在兩個區域內節點需要互相通信時，發送端通過 DRE 將 CAN 報文封裝 ACF 格式數據，接收端接到以太報文后根據協議提取 CAN 報文。

除此之外，DRE 配合 CRE 可完成 CAN 報文路由到特定系統 SRAM、指定其他 CAN 模塊的不同節點。

2.5 信息安全

2.5.1 TC4x 信息安全系統概述

隨著 R155\R156 、國家標準《汽車整車信息安全技術要求》等汽車網絡安全法規逐步強制執行，汽車網絡安全的重要性被提升了到新的高度，因此從 OEM 到 Tier 1 再到 Tier 2 急需從 Security 方面優化各自產品。

TC4x 系列在吸納 TC3x HSM 子系統的優點后，針對當前區域控制器重構信息安全系統，首創 CyberSecurity Cluster 的概念，規劃出 CSRM（ Cyber Security Real-time Module）和 CSS （ Cyber Security Satellite） 兩個子系統，如下圖所示：

圖29

CSRM 和 CSS 主要負責密碼算法硬件加速，除了支持國際密碼算法，還支持國家密碼算法 SM2\3\4 ，其中：

CSRM 包含：

• 非對稱算法加速引擎，支持 RSA 和 ECC；

• 隨機數生成器，支持 TRNG、DRNG 和 HRNG；

• CSCU 用于與其他核通信、控制調試訪問、PIN 腳輸出等

CSS 主要用于對稱和摘要算法加速，包含：

• 內部私有 RAM 用于存儲密鑰和 IV；

• 內部支持多達 21 個通道(1 個給 CSRM 獨享)支持不同密碼任務；

在 Cluster里，除 CSRM、CSS 外，還包括 TC1.8替代 TC3x中HSMM3內核、內部獨立的 PFlash 和DFlash，同時可以用過軟件配置各種外設成為 Cluster 里的部件，例如配置 Secure SPI與外部 TPM 交互。在 inSE的大背景下，該方案提升了 OEM\Tier 1 在布局汽車網絡安全的靈活性和可靠性。

2.5.2 針對通信場景的優化

從上圖可以看到支持 sym 和 hash 算法的 CSS 在布局中更為靠近 Host CPU，這樣做的目的是什么呢？簡單來講，架構變化要么是性能優化，要么是安全優化，安全這塊目前看不出來，但是從性能的優化我們需要從特定場景進行思考。

在 CP AUTOSAR 中，基礎軟件開發工程師大多從 SecOC 入門信息安全。在現有 MCU 里，針對 SecOC 數據驗簽的做法通常是 Hsot CPU 將待校驗數據放置 Host 共享內存并置起請求 Flag，HSM CPU 側輪詢或者中斷接收該 Flag 后去共享內存獲取數據并進行加解密，如下圖：

圖30

這種針對 ECU 間的安全通信在當前架構下對 MCU 的 HSM\SHE 等要求不算嚴苛，但是在區域控制器多功能融合、多 VM 通信的場景下，當前 MCU 就存在加密引擎實例和性能不夠、多 Host 通道不足的問題，例如當區域控制器里融合了網關和 BMS 功能，當二者同時要使用 HSM 時，勢必會形成資源競爭；

在車聯網的大背景下，TLS 被引入到 DoIP 安全會話流程，在車機端也被用于車云通信，而 TLS 的引入也帶來了巨大的通信負載（ 4 次握手，比 TCP 還多一次），流程定義了，那么只能在密碼服務的性能做優化。

為此 CSS 站了出來，它提供獨立的 SRISlave 接口（類似 TC3x 的 Bridge 模塊）來實現與 CPU 之間的通信，內置 21 個獨立通道和多個對稱、摘要實例來實現多主機的并行訪問，相較于之前 Host、HSM 之間交互，Host 僅需配置 SRISlave 接口里的特殊寄存器，即可完成 SYM 和Hash 引擎的使用。理論上省卻了 Host 與 HSM 通信交互，提供了多通道平行接口，確實可以提高不少效率。

咱們做出這樣一個暢想：在 SecOC AES-CMAC 校驗時只需要告訴引擎在哪里獲取數據，引擎自動獲取數據并分塊、填充完成數據校驗，不需要像以前通知 HSM CPU 去獲取數據，手寫代碼對數據進行分塊、做填充。從代碼層面上至少省卻了通信這一大模塊，然后減少 For 循環分塊填充數據到引擎的代碼，效率大大增加。

2.5.3 針對強標的對策

隨著車輛網的發展，汽車網絡安全已經被提升到了需要強制 OEM 考慮和執行的階段，耳熟能詳的就是 UNECE R155、 R156 以及對應國標《汽車整車信息安全技術要求》、《汽車軟件升級通用技術要求》。

以 R155 為例，讀過這份標準的同學應該最開始都是云里霧里，它主要涉及汽車的網絡安全管理體系（ CSMS）及特定車輛型式認證（ VTA）兩部分。

前者要求每個 OEM 都必須有一個穩定的網絡安全管理體系，但是沒有具體說應該如何去建立；后者要求 OEM 去識別特定車型的相關網絡安全風險，但傳統汽車人對這塊確實一頭霧水。

為此，ISO 和 SAE 與 2021 年聯合發布了 ISO\SAE 21434 標準，旨在指導 OEM、Tier1 如何建立起有效的網絡安全組織，同時為車輛的整個生命周期(從研發到報廢)建立起有效的流程體系，以保證其免受信息\網絡安全攻擊。

換句話說，R155 是指導性文件，告訴做什么；ISO\SAE 21434 是執行性文件，告訴 OEM 怎么做。

圖31

由于 R155 針對 OEM 提出了宏觀綱領，那么分解到 Tier 1 、2 ，自然就需要 21434 來進行指導如何干活；

TC4x 信息安全子系統不僅符合 EVITA-Full，還通過了 ISO\SAE 21434 的認證，英飛凌從企業內部建立起 CSMS(Cyber Security Management System) ，針對風險評估方法、概念階段、產品開發、運維、持續網絡安全活動等方面定義了相關流程，致力于輔助加速 OEM 針對 R155 的認證。

2.6 功能安全

2.6.1 SMU 繼續發揮作用

如果說重構的信息安全系統是 TC4x 在跨域融合產品的亮點，那么 TC4x 的功能安全則是整個芯片正常運行的基石。

在 TC4x 中，大部分功能安全機制沿用 TC3x，而與我們開發最相關的 SMU 仍繼續發光發熱。在 TC3x SMU 的基礎上，新增了關于 Security Domain 的 alarm 處理模塊，同時設計了 Security 方面的 alarm；為滿足區域控制下多 vECU 對于 alarm 處理的資源競爭，設計了兩個 safety  alarm 處理模塊。

其結構如下圖：

圖32

雖然沒有了解到具體 Safety Manual，但是從 SMU 整體架構我們不難得出，所有功能安全機制觸發的 alarm 可以被分為三大類：

• Safety 相關的 alarm；

• Security 相關的 alarm；

• Safety 和 Security 兼顧的 alarm。

因此，針對這些 alarm 的處理，首先就是需要選擇路由給哪些 alarm 處理模塊。在 SMU 模塊里提供了 alarm 選擇功能，可以根據寄存器配置路由給不同的處理模塊等，那么路由到目標處理模塊后，對應行為是什么呢？

不難推測，為實現 TC3x 到 TC4x 的平穩遷移，當然就是繼續采用內部行為和外部行為，如下圖：

圖33

內部行為對應 NMI、 IRQ、SYS_RESET、CPU_RESET，外部行為毫無疑問就是 FSP 等。

不過在 SMU_CS 的處理上，由于涉及到 Security，因此行為多在 Security 子系統里內部處理，包括 CSIRQ\NMI\RET，以及特殊的對所有秘鑰上鎖、對 Debug 方面進行上鎖等。

針對信息安全子系統設計的相關 Security\Safety 機制，解答了我一直以來的疑惑，Security 與 Safety 到底應該如何融合：個人理解，雖然 Safety 和 Security 有各自的重點和側重點，但它們的共同目標都是保護車輛、乘員和其他道路使用者的安全；同時二者關系也非常緊密，例如車輛的信息系統受到黑客攻擊或惡意軟件感染，可能會導致車輛失去控制、系統故障或其他安全問題，從而危及車輛和乘員的安全。

正如我們設計系統安全啟動功能時，不僅要從 Safety 角度進行 HARA 分析，還需要從 Security 角度進行 TARA 分析，雙劍合璧，才能加固系統。

2.6.2  功能安全閉環設想

在區域控制器架構下，不同 vECU 都會有自己的功能安全方案，有些方案甚至已有量產經驗，那么在做跨入融合如何降低集成成本？我們這樣設想，vECU 在運行中感覺不到自己是虛擬環境里，那么我們仍然可以從以往控制器的功能安全方案中吸取經驗。

英飛凌官方應用筆記對于TC3xxSMU使用上強烈推薦與之搭配的PMICTLF35584、TransceiverTLE9252v，從而形成較為完整的系統級功能安全解決方案，如下圖所示：

圖34

TC3x 的 ErrorPin(P33.8) 與 PMIC TLF35584 的 Error PIN 相連接， 35584 在接收到相應的錯誤狀態后，可以通過 SSx(Safety State)腳再向外輸出錯誤狀態，例如控制逆變器功能降級、通知 Transceiver 關閉通信等，使 ECU 進入到安全狀態。

采用這樣的思路，在區域控制器的大背景下，需要解決的就是多 vECU 對于 SMU 的資源競爭。

我們以 SMU 中 Alarm 行為 IRQ 為例來預估這樣一條路徑，如下圖所示：

圖35

當功能安全機制觸發對應 IRQ 行為的 alarm 給到 SMU 后，通過 IR 給到目標 CPU，然后就是中斷虛擬化的處理，Hypervisor 下對 VM 調度進行上下文切換，并通知相應 VM 進行功能降級。

如果使用到了 FSP，我們最關心的 Error Pin 繼續兼容 TC3x， 并在此基礎上新增了兩個 PIN，這樣相對來說資源上是能夠支持與外部 PMIC 或者用戶自定義引腳相連。

在 TC4x 推出的同時，配套 PMIC TLF4xx85 也同時推出，提供整套電源管理方案。

2.7 TC4x 在調試、標定上的優化

2.7.1 Overlay 繼續沿用

TC1.8 繼續沿用 CPU 視角下的 Overlay，這個功能我之前已經講過多次，主要是用于 XCP 中頁切換的實現同時也減少軟件標定棧集成工作，具體如下：

當我們在上位機選擇 WP 時，此時對應下位機(ECU)應該反饋 RAM 的值；選擇 RP 時，對應下位機應該反饋 Flash 的值，如下圖：

圖36

在最初沒有 Overlay 功能，要實現頁切換，需要定義多塊 RAM，其中包括一塊臨時 RAM，如下圖：

圖37

切換 WP 或者 RP，為保證 WP 數據不丟失，此時需要將 WP copy 至 Temp RAM；然后將 Flash 值 Copy 至 RAM；而這樣內存 COPY 對于資源消耗和性能都有比較大的影響，為此英飛凌基于內核視角提出了 overlay 機制，如下圖：

圖38

這樣的好處在于，假設修改標定量導致系統進入臨界工況，例如車速突然增加(同一油門踏板開度，不同輸出曲線)；此時快速切回 RP，可有效降低工程事故。

需要注意的是，當虛擬化開啟后，如何通過 MPU 、Hypervisor 來保證不同 VM 的資源隔離，特別是對于 overlay 的 Flash 的選定，這是需要在實際工程中進行重新布局和調整。

2.7.2 調試系統

在調試系統上繼續沿用 TC3x 的 Debug 接口，例如 JTAG\DAP\DAPE； 不過針對 Trace 接口提出了新的優化。整體架構如下圖：

圖39

在之前我們做高速測量時供應商都會針對 Trace 接口設計相應的 POD 接口，具體結構如下圖所示：

圖40

這對于 OEM 或者 Tier 1 在使用上有成本和性能上的綜合考慮。

在 TC4x 的設計中，Trace 的數據可以通過 SRI 總線路由到 ETH 和 SRAM；我們做出這樣猜想，在高速測量場景中，可以直接通過 ETH 將 Trace 數據給到上位機，這樣不僅節省了成本，也提高了效率：

圖41

在上圖中，Trace 數據通過 Trace 模塊存放在 SRAM(作為臨時 Buffer) ，CPU 僅需觸發 DMA 搬運數據到 ETH 模塊，通過 Ethernet 與標定測量系統進行數據傳輸，雖然會消耗很少部分 CPU 資源，但是相較于之前 MCU 從通用性和成本上確實提升了不少。

2.8 工具鏈及生態解讀

2.8.1 集成開發環境及調試器

據統計，目前我們常用的商業版集成開發環境(含編譯器)Tasking、Hightec、GHS 全面支持 TC4x 產品，調試器勞特巴赫、iSystem、PLS 均已全面支持。

圖42

圖43

英飛凌也推出里免費集成開發環境 ADS Limited，將代碼編寫、編譯、調試融為一體，供 TC4x 新用戶上手評估。

圖44

2.8.2 基于 TC4x 的 AUTOSAR 基礎軟件

英飛凌本身不提供 AUTOSAR 基礎軟件，但行業中的主流 AUTOSAR 工具鏈廠商都已完成了 TC4X 的適配，國產的包括東軟睿馳、普華基礎軟件、經緯恒潤，國際廠商包括 Vector、ETAS、EB、SIEMENS 都對 TC4x 做了適配。

圖45  東軟睿馳基于 TC4x 的配套產品

#03 區域控制器 MCU 資源對比

#04 區域控制器市場前景預測

2019 年，特斯拉這條鯰魚帶來的汽車電動化、智能化、網聯化震撼人心，隨著這股風潮的推動，汽車電子電氣架構逐步由傳統分布式 ECU 向域控/中央集中架構方向發展。

在以往傳統分布式 E/E 架構下，汽車智能化程度的提高主要依靠整車 ECU 數量的增加，往往一臺高端車型的 ECU 數量就超百個；然而 ECU 數量的增加勢必造成整車布線復雜冗長、線束成本劇增，同時不同 ECU 之間信息交互的效率和精度也大打折扣，為此域控概念開始提出。

博世關于整車EE 架構的演進在之前文章里已經談過多次，它主要是依據控制器功能劃分為動力域、底盤域、信息娛樂域、自動駕駛域和車身域五大域控，這也是目前多數 OEM 的架構；

特斯拉領先一步，根據空間位置分為 CCM（中央計算模塊）、LBCM（左車身域控）、RBCM（右車身域控），這也是中央集中架構的雛形。

雖然上述兩類控制器均帶有域，但是英語單詞上存在比較大的差異，

• 域控制器：DomainController ，針對的是控制器功能，我們常見的是五域架構：智駕域、座艙域、動力域、底盤域、車身域就是此類域控制器；它按功能對整車布線，以提供對整個車輛的控制。但隨著智能網聯汽車發展，新的需求和功能導致ECU 增多（據統計智能汽車含 100-150 個ECU），汽車內部布線逐步復雜。從電源到ECU 再到執行器的連接導致了整車布線多半是打補丁的方式，冗余且浪費。這種方式在未來智能駕駛的實現有著極大的擴展限制。

• 區域控制器：Zonal Controller ，面向的是整車空間的一個布局，在區域控制器下可能會實現多個功能，這也是下一代 MCU 考慮的事情，在硬件層面重新規劃 I/O 等硬件資源，打破域控架構下的原有功能邊界，大大縮短了布線長度，簡化了電源和信號傳輸，并釋放了更多空間，為下一次電子電氣架構演進奠定了基礎。

當架構逐漸集中，對于汽車軟件功能新增和聚合的需求也日益凸顯。據《中國汽車基礎軟件發展白皮書》統計，智能網聯汽車運行代碼量已經高達 2 億行，在未來 L3\L4 及以上級別的自動駕駛汽車代碼量甚至會增加到4 億行 。代碼量的增加對汽車芯片的資源、算力、外設、性能的要求與日俱增，這對在汽車芯片占比高達 30% 的 MCU 提出了更大的挑戰，各大國際 MCU 廠商紛紛加大投入，融入新技術，即將推出的汽車 MCU 產品更像是一顆低端 SoC 芯片，這對以往基于 MCU 研發的工程師來說將會是一個新的領域。

那么具體來看，區域控制器會為整車帶來什么的好處？

1）線束減少影響整車重量

據統計，在當前功能域架構下的整車線束在 50-60 公斤，展開長度可達 5-6 公里，這對于電動汽車的成本、日常使用續航等有著重大影響；采用區域架構可以有效減少線束，減輕了車輛的重量。這對電動汽車尤其有益，因為每節省一公斤就意味著里程的增加和性能的提高。特斯拉采用類區域控制架構，將整車線束重量減小至至 20 公斤，大家可以發現在 18 、19 年續航里程上國產電動車宣傳都有一點虛高，特斯拉則是實打實標稱；

值得一提的是隨著車輛從 12V 電氣系統遷移到 48V 電氣系統，可以在更低的電流下提供相同的功率，從而減少電線的厚度和相應的重量，這種重量進一步得到改善。通過更細的線束和更簡單的布線，也為其他功能系統騰出了更多的空間。

2）提升整車制造裝配的效率

隨著區域架構采用標準化和模塊化的設計，整車裝配線進一步簡化，模塊化使得線束可以預組裝，標準化使得整車裝配模塊即插即用。這些進步帶來了更大的靈活性，更容易自動化，更少的錯誤，并大大降低了電氣子系統的制造成本。

3）簡化 OTA 難度

在分布式甚至功能域架構下，ECU 個數仍居高不下；如今智能網聯大背景下，汽車軟件 OTA 更加頻繁，因此 OEM 需花費大量成本、人力資源來協調和管理 ECU 供應商的軟件更新和管理。

在中央集成+區域控制架構下，ECU 數量減少，中央計算平臺與區域控制器采用以太環網進行數據交互，區域控制器下掛節點利用高速總線接入網絡，不僅簡化了 OTA 升級節點個數，還提高了 OTA 升級速度。

就目前來說，域集中已經成為了汽車行業共識，我們可以從主機廠發布的域架構可以看出，汽車電子電氣架構沿著預軌道發展，正朝著中央式進發，如下圖所示：

圖46

“ 中央集成+ 區控制器”架構將是長期趨勢，也是當前汽車未來研發重點。

END