现代智能车机系统1——EEA架构（0）

E/E 架构的演进路线图

汽车电子电气架构（E/E 架构）的演进，本质上是一场算力与数据流的重组运动。它遵循着从"无序到有序"、"从分散到集中"、"从硬件主导到软件定义"的历史必然规律。

1.1 演进路线图：从"诸侯割据"到"中央集权"

博世（Bosch）曾发布过一张经典的架构演进图，将其划分为三个大阶段、六个小步骤。为了便于理解，我们将其提炼为四个关键里程碑：

第一阶段：分布式架构 (Distributed Architecture) ------ 模块化起步

特征："一个功能 = 一个盒子（ECU）"。
逻辑：如果你想加个自动雨刮，就加一个雨刮控制器；想加个电动座椅，就加个座椅控制器。ECU 之间通过低速 CAN 总线点对点通信。
状态：传统的燃油车大多处于此阶段。整车 ECU 数量极多（70-100+），且来自数十个不同的 Tier 1 供应商。

第二阶段：域集中架构 (Domain Centralized) ------ 功能整合

特征："按功能归类"。
逻辑：将功能相似的 ECU 整合到一个算力更强的域控制器 (DCU, Domain Control Unit) 中。行业公认的**"博世五大域"**划分标准确立：
1. 动力域 (Powertrain)：发动机、变速箱、电池、电机。
2. 底盘域 (Chassis)：制动、转向、悬架。
3. 车身域 (Body)：车窗、车灯、门锁、空调。
4. 座舱域 (Cockpit)：仪表、中控、娱乐、HUD。
5. 智驾域 (ADAS/AD)：感知、规划、决策。
状态：目前主流的新能源车型（如小鹏 P7、蔚来 ET7 等）处于此阶段。以太网开始引入，但 CAN 依然是主力。

第三阶段：跨域融合 (Cross-Domain Fusion) ------ 边界打破

特征："域控制器之间的合并"。
逻辑：随着芯片算力（如高通 8295、Orin-X）的过剩，一个芯片可以干两个域的活。
- 舱泊一体：座舱芯片算力闲置时，负责自动泊车。
- 行泊一体：低速泊车和高速行车共用一套智驾域控。
- 驾驶与底盘融合：智驾域直接接管底盘控制，减少通信延迟。
状态：2023-2025 年量产车型的热门架构（如理想 L9、小米 SU7 等）。

第四阶段：中央计算 + 区域控制 (Central & Zonal) ------ 终极形态

特征："物理位置决定一切"。
逻辑：这是特斯拉 Model 3/Y 及 Cybertruck 引领的方向，也是 SDV（软件定义汽车）的物理基础。
- 中央计算 (Central Compute)：全车只有 1 个（或 2 个互为冗余）超级大脑，负责所有逻辑运算、决策和数据处理。
- 区域控制 (Zonal Control) ：全车划分为 4 个（或更多）物理区域（如左前、右前、左后、右后）。区域控制器 (ZCU) 就近连接该区域内的所有传感器和执行器（无论是车灯、雷达还是门锁），它不负责思考，只负责供电和透传数据。
状态：下一代架构的圣杯，目前仅少数先锋车企实现量产，是未来 5-10 年的主流方向。

1.2 分布式架构的终结：CAN 总线与 100+ ECU 的"维护地狱"

为什么分布式架构必须死？因为在智能电动车时代，它已经成为了创新的最大阻碍。这不仅仅是技术问题，更是供应链和成本的灾难。

痛点一：100+ ECU 的"维护地狱" (Integration Hell)

在分布式架构下，一辆豪华车可能有超过 100 个 ECU，分别来自博世、大陆、电装、采埃孚等不同供应商。每个 ECU 都是一个**"黑盒子"**。

软硬绑定的死局：
- 传统的 ECU 是软硬件打包卖的。如果你想修改雨刮的刮刷逻辑（比如增加一个"雪天模式"），你不能直接改代码，你必须发邮件给供应商，让供应商修改固件，重新验证，再发给你。这个周期可能长达 6 个月，且需要支付昂贵的开发费（NRE）。
- 后果：整车厂（OEM）失去了对车辆灵魂的控制权，OTA（空中升级）几乎不可能深入到执行器层面。
代码集成的噩梦：
- 100 个盒子，就有 100 种不同的底层软件架构、100 种私有协议。将它们凑在一起工作，需要进行天文数字级别的集成测试。
- 这就好比让 100 个讲不同方言的人在一个房间里协同工作，光是翻译（网关协议转换）就消耗了大量资源，且极易出错。
供应链管理的灾难：
- 缺芯潮（Chip Shortage）期间，缺一颗几块钱的座椅控制 MCU，整车就无法下线。ECU 数量越多，供应链的"短板效应"越明显，风险越高。

痛点二：CAN 总线的带宽瓶颈

CAN (Controller Area Network) 总线是上个世纪 80 年代的产物，虽然它稳定可靠，但在大数据时代已显老态龙钟。

带宽不足：
- 传统 CAN 的速率仅为 500 kbps ，升级版的 CAN-FD 也仅为 2-5 Mbps。
- 对比需求 ：一颗 800 万像素摄像头的数据量是 1-2 Gbps ；一颗激光雷达是 500 Mbps。
- 后果：CAN 总线就像乡村土路，根本跑不动自动驾驶的法拉利。如果不换架构，所有的高阶传感器数据都无法汇聚。
实时性与抖动：
- CAN 采用"仲裁机制"（谁优先级高谁先说话），在总线负载率高（>40%）时，低优先级的信号会被延迟发送。
- 对于自动驾驶的刹车和转向控制，这种**随机的延迟（Jitter）**是致命的。我们需要的是确定性的通信（引出后文的 TSN）。

痛点三：线束"巨蛇"的重量

在分布式架构中，所有的信号线都是**"点对点"或"星型发散"**的。

现象：为了连接 100 个 ECU 和数百个传感器，车内线束总长度可达 4-6 公里 ，重量高达 50-80 公斤。
影响：
- 增重：线束是仅次于发动机和底盘的第三重部件，直接影响电动车的续航里程。
- 装配难：线束像一条巨蛇盘踞在车身内部，主要靠人工安装，自动化率极低，且一旦装错极难排查。
- 成本高：铜价上涨导致线束成本居高不下。

结论：

分布式架构是机械时代的产物，它追求的是**"功能的叠加"；而智能时代追求的是 "能力的融合"。为了实现软件定义汽车，必须打碎这 100 个黑盒子，用 中央计算重塑大脑，用 以太网重塑神经，用区域架构**重塑骨骼。

1.3 域控中间态：五大域的划分逻辑与"数据孤岛"困局

为了解决分布式架构中 ECU 数量爆炸和软件无法迭代的问题，博世（Bosch）等 Tier 1 巨头率先提出了"域"（Domain）的概念。其核心思想是：将功能相近的 ECU 整合，由一个算力较强的域控制器 (DCU) 统一管理。

这就像把 100 个散兵游勇，整编成了 5 个集团军。

1. 五大功能域的划分逻辑

目前行业公认的经典划分方式是**"五大域"**。这种划分并非随意为之，而是基于功能属性、实时性要求和安全等级的差异。

(1) 动力域 (Powertrain Domain)

管辖范围：发动机/电机、变速箱、电池管理 (BMS)、车载充电机 (OBC)。
特性：高安全等级 (ASIL-C/D)，极高的实时性要求。
逻辑：这是汽车的心脏。无论是燃油还是电动，动力输出的策略优化（如扭矩分配、能量回收）都需要在毫秒级内闭环，必须集中管理。

(2) 底盘域 (Chassis Domain)

管辖范围：制动系统 (ESP/iBooster)、转向系统 (EPS)、悬架系统 (CDC/空气悬架)。
特性：最高安全等级 (ASIL-D)，容错率极低。
逻辑：这是汽车的小脑。随着线控底盘技术的发展，底盘域正逐渐与智驾域产生深度耦合（例如：自动驾驶发出的"左转"指令，需要底盘域精准执行）。

(3) 车身域 (Body Domain)

管辖范围：车灯、门锁、车窗、雨刮、电动尾门、座椅调节、空调风门。
特性：低安全等级 (ASIL-B/QM)，功能繁杂，逻辑简单。
逻辑：这是汽车的躯干。车身域是目前集成度最高的部分，很多车企已经将 BCM (车身控制器) 与网关集成，形成了 BGM (Body Gateway Module)。

(4) 智能座舱域 (Smart Cockpit Domain)

管辖范围：仪表盘、中控大屏、副驾屏、HUD、流媒体后视镜、T-Box、DMS 摄像头。
特性：注重用户体验，高算力需求，迭代速度快（向消费电子看齐）。
逻辑：这是汽车的脸面。传统的仪表和娱乐系统分离，现在通过 Hypervisor 技术，用一颗 SoC (如 8155/8295) 就能驱动多块屏幕，实现"一芯多屏"。

(5) 自动驾驶域 (ADAS/AD Domain)

管辖范围：摄像头、毫米波雷达、激光雷达、高精定位。
特性：海量数据吞吐，极高 AI 算力需求。
逻辑：这是汽车的大脑。它负责处理感知数据，进行规划决策，是整车算力的巅峰。

2. "数据孤岛" (Data Silo) 问题：域控架构的阿喀琉斯之踵

虽然域控架构大大减少了 ECU 数量，但它引入了一个新的、棘手的问题：域与域之间的隔离。

每个域控制器就像一个独立的"信息烟囱"，它们内部通信很快，但跨域通信却很慢且复杂。

痛点一：跨域功能开发极难

想象一个典型的智能化场景------"迎宾模式"：

当车主走近车辆，车灯闪烁（车身域），门把手弹出（车身域），座椅自动后退（车身域），中控屏播放欢迎动画（座舱域），底盘悬架降低以便上车（底盘域）。

现状：要实现这个功能，需要协调 3 个域控制器。开发者需要在车身域写代码，在座舱域写代码，在底盘域写代码，还要定义复杂的跨域通讯协议。
后果：开发链条极长，联调困难，任何一个域的响应延迟都会导致体验割裂（比如人坐进去了，座椅还没退到位）。

痛点二：算力与传感器无法复用

传感器浪费 ：
- 座舱域有一个摄像头看驾驶员是否疲劳 (DMS)。
- 智驾域也有摄像头看路。
- 但智驾域很难借用座舱域的摄像头数据来辅助判断（例如结合驾驶员视线和路况判断变道意图），因为视频流数据量太大，跨域传输带宽不足。
算力闲置 ：
- 在高速公路上开 ACC 时，座舱芯片（8155）可能在摸鱼（只显示导航）。
- 在自动泊车时，智驾芯片（Orin）可能火力全开，但座舱芯片依然在摸鱼。
- 后果：由于算力是物理隔离的，无法像云计算那样"弹性调度"，导致硬件成本的巨大浪费。

痛点三：线束依然繁杂

虽然域内线束减少了，但传感器和执行器依然是**"功能导向布线"**。

例子：位于车尾的倒车雷达（智驾域）和位于车尾的电动尾门（车身域），虽然物理上靠得很近，但它们的线束必须分别绕过整个车身，分别连接到位于车头的智驾域控和车身域控。
后果：线束长度并未达到最优解，依然存在大量的"折返跑"布线。

结论：

域控架构虽然解决了"乱"的问题，但没有彻底解决"通"的问题。为了打破这些无形的墙，我们需要进一步打破功能的边界，按物理位置 重新架构------这就是下一章 Zonal (区域) 架构 诞生的原动力。

1.4 跨域融合：打破边界的逻辑与新问题

当芯片算力（尤其是 SoC）开始过剩，而跨域通信带宽成为瓶颈时，工程师们自然会想到：为什么不把两个关系好的域控制器合并成一个？

1. 融合的底层逻辑：效率至上

跨域融合的核心驱动力是降本（Cost Down）和提效（Efficiency Up）。

(1) 物理集成 (Physical Integration) ------ 省钱

做法：把两块 PCB 板塞进一个铁盒子里，共用散热器、外壳、供电模块，甚至共用一颗 MCU 做安全监控。
收益：
- BOM 成本降低：少了一个盒子、少了一套接插件、少了一套线束插头。
- 重量减轻：对于电动车来说，减重就是加续航。

背景：座舱芯片（如 8295）的 NPU 算力达到了 30 TOPS，而泊车功能只需要 10-20 TOPS。
做法：在座舱芯片空闲时（比如泊车时，用户不玩游戏），分出一部分算力给智驾算法。
收益：省掉了一颗独立的泊车芯片（如 TDA4），直接省下几百块成本。

(3) 通信优化 (Communication Optimization) ------ 降延迟

背景：智驾域需要控制底盘域（转向/刹车）。如果两个域分开，信号要走：智驾 SoC -> 智驾 MCU -> 以太网/CAN -> 网关 -> 底盘 MCU。链路长，延迟大。
做法：智驾与底盘融合。信号直接在板内通过 SPI/PCIe 传输，或者在同一颗 MCU 内部通过内存拷贝传输。
收益：控制延迟从 10ms 级降低到 us 级，车辆操控更精准。

2. 三大主流融合路径

目前行业内最典型的三种跨域融合形态：

(1) 舱泊一体 (Cockpit-Parking Integration)

融合对象 ：智能座舱域 + 自动泊车 (APA)。
逻辑：泊车是低速场景，安全性要求相对高速智驾低，且泊车时需要调用座舱的 360 环视摄像头和屏幕显示。两者数据源高度重合。
代表方案：基于高通 8155/8295 单芯片方案。
状态：已大规模量产，成为中低端车型的标配。

(2) 行泊一体 (Driving-Parking Integration)

融合对象 ：高速行车 (L2+) + 低速泊车。
逻辑：以前行车用 Mobileye（封闭黑盒），泊车用别的芯片。现在为了降本，用一颗大算力芯片（如 Orin-X 或地平线 J5）统吃行车和泊车，传感器分时复用。
状态：目前智驾领域的主流方案。

(3) 驾舱融合 (Driving-Cockpit Fusion) ------ 真正的硬骨头

融合对象 ：智能座舱 + 智能驾驶。
逻辑：这是通往中央计算的必经之路。将全车最贵的两颗芯片（座舱 SoC 和智驾 SoC）放在一起，甚至合并为一颗超级芯片（如 NVIDIA Thor）。
挑战：这也是目前争议最大、技术难度最高的方向。

3. 跨域融合带来的新问题：牵一发而动全身

虽然融合看起来很美，但在工程落地时，车企和 Tier 1 遭遇了前所未有的挑战。

问题一：开发架构的撕裂 (Organizational Silo)

康威定律 ：软件架构反映了组织架构。
现状：车企内部通常有"座舱部"和"智驾部"，这是两个庞大的、独立的部门，甚至汇报给不同的副总裁。
冲突：现在要做"舱驾融合"，这块板子归谁管？操作系统选谁的？资源（内存/带宽）怎么分？
结果：技术融合了，但人没融合。大量的内耗导致项目延期。很多车企被迫成立"数字化中心"或"软件中心"来统筹。

问题二：混合临界安全 (Mixed-Criticality Safety)

本质矛盾 ：
- 座舱 (Android)：追求快、炫、新。死机了重启就行，那是 QM (质量管理) 等级。
- 智驾 (RTOS/QNX)：追求稳、准、狠。死机了会死人，那是 ASIL-D 等级。
挑战：当两者跑在同一块板子甚至同一颗芯片上时，如何保证 Android 的崩溃绝对不会影响刹车任务？
解法：必须引入极其复杂的 Hypervisor (虚拟化) 和 硬件隔离 (Firewall) 技术，开发难度指数级上升。

问题三：供应链的重新洗牌

旧模式：买博世的底盘、买伟世通的座舱、买德赛的智驾，回来组装。
新模式：融合控制器太复杂，没有一家传统供应商能单独搞定。
趋势：
- 车企自研：为了掌控灵魂，车企开始自己画板子，自己写底层软件。
- Tier 0.5 出现：像大疆、华为这种能提供全栈能力的供应商变得强势，传统 Tier 1 被边缘化为代工厂。

结论：

跨域融合是通往终极架构的**"练兵场"**。它迫使车企在组织架构、软件能力和供应链管理上进行深刻变革。只有跨过了这道坎，才有可能驾驭真正的 中央计算 + Zonal 架构。

1.5 终极形态：中央计算 + 区域控制 (Central & Zonal)

如果我们把汽车比作一个人，那么：

分布式架构是"单细胞生物"的集合，每个细胞自己管自己。
域控架构是"无脊椎动物"，有几个神经节分别管手和脚，但不够协调。
中央+区域架构则是"脊椎动物"，有一个发达的大脑（中央计算）和分布在四肢的神经末梢（区域控制）。

这一架构的核心革命在于：彻底解耦了"物理连接"与"逻辑控制"。

1. 物理分区：ZCU (Zone Control Unit) ------ 汽车的"神经末梢"

在 Zonal 架构下，我们不再问"这个控制器管什么功能？"，而是问"这个控制器在哪里？"。

(1) 划分原则：位置优先 (Location-Based)

全车通常被划分为 4 个（或更多）物理区域，每个区域部署一个 ZCU (区域控制器)：

左前区 (Front-Left Zone)：位于左前轮眉或 A 柱附近。
右前区 (Front-Right Zone)：位于右前轮眉或 A 柱附近。
左后区 (Rear-Left Zone)：位于左后轮眉或 C 柱附近。
右后区 (Rear-Right Zone)：位于右后轮眉或 C 柱附近。

(2) ZCU 的职责：全能的"搬运工"

ZCU 是一个标准的**"混合信号处理中心"**，它干三件事：

I/O 代理 (I/O Aggregator) ：
- 该区域内的所有设备（左大灯、左前雷达、左前门锁、左前车窗电机、左前空调风门等），不管它是属于车身域还是智驾域，统统就近接入这个 ZCU。
- 线束革命：这消灭了跨越全车的长线束。左大灯的线只需要 0.5 米接到左前 ZCU，而不需要 4 米接到车身控制器。
电源分配 (Power Distribution) ：
- ZCU 还是该区域的智能配电盒。它通过内部的 eFuse (电子保险丝) 给上述设备供电，并监控电流健康状态。
协议转换 (Gateway) ：
- 它将传感器发来的 CAN/LIN 信号，打包成以太网数据包，通过一根高速光纤/网线，扔给中央大脑。它不处理业务逻辑，只做透传。

2. 逻辑集中：中央大脑 (Central Compute) ------ 汽车的"灵魂"

当所有的传感器和执行器都接入 ZCU 后，它们就变成了没有思想的"手脚"。所有的思考，都汇聚到了中央计算单元 (CCU - Central Compute Unit)。

(1) "上帝视角"的控制

在中央大脑中，软件不再被一个个 ECU 的硬件围墙隔开，而是运行在一个统一的操作系统之上。

跨域协同变得无比简单 ：
- 以前的"迎宾模式"需要协调 3 个控制器。
- 现在的代码可能就是两行： Python
  复制代码
```
if (User.Approach()):
    ZoneFL.Door.Open(); // 调用左前区域的车门服务
    ZoneFL.Seat.MoveBack(); // 调用左前区域的座椅服务
    Cockpit.Screen.PlayAnimation();
```
- 所有硬件资源都在一个资源池里，开发者可以像写手机 App 一样调用全车能力。

(2) 传感器与执行器的"哑巴化"

这是 Zonal 架构最激进的一步。

旧模式：智能雨刮器里有个 MCU，它决定什么时候刮。
新模式：雨刮器电机只是一块磁铁和线圈。中央大脑通过视觉算法判断雨量，计算出最佳刮刷频率，直接发指令给 ZCU，ZCU 输出 PWM 波驱动电机。
意义：
- OTA 能力质变：如果我想优化雨刮的刮刷节奏（比如增加"渐进式启动"），我只需要升级中央大脑的一行代码，而不需要去刷雨刮电机的固件（这在以前几乎是不可能的）。
- 成本转移：把分散在 100 个末端设备的 MCU 成本砍掉，集中投入到中央大脑的高性能芯片上。

3. Zonal 架构的"一增一减"

减法：线束与装配

线束长度：从 4-6km 减少到 <1.5km（Tesla Model Y 实测）。
线束重量：减少 50% 以上。
装配自动化：线束结构变简单了，机器人可以代替人工进行自动化装配（这正是马斯克推崇的 Alien Dreadnought 工厂理念）。

增法：通信与算力

通信压力 ：所有的原始数据（Raw Data）都要传给中央，对骨干网带宽要求极高。这直接催生了 10G 车载以太网 和 TSN 的需求。
算力压力 ：中央大脑一旦死机，全车瘫痪。因此，中央大脑必须具备极高的算力冗余 和双机热备机制。

结论：

中央计算 + 区域控制架构，是软件定义汽车 (SDV) 的物理容器。没有这个架构，所谓的 SDV 只是空中楼阁；有了这个架构，汽车才真正拥有了进化的肉体。

1.6 区域控制器 (ZCU) 详解：全能的"边缘管家"

在传统的汽车架构中，我们习惯了 BCM（车身控制器）、门模块、空调控制器。但在 Zonal 架构中，这些名字都将消失，取而代之的是 ZCU-FL (左前) 、ZCU-FR (右前) 、ZCU-RL (左后) 、ZCU-RR (右后)。

ZCU 的设计哲学只有一条：位置即正义。

1. 物理定义：打破功能的结界

(1) 按位置划分 (Location-Based)

ZCU 的部署完全取决于物理拓扑，而非功能属性。

例子：
- 左前 ZCU (Zone-FL) 可能连接了：左大灯（车身域）、左前轮转速传感器（底盘域）、左前毫米波雷达（智驾域）、前雨刮电机（车身域）、冷却液泵（动力域）。
- 在以前，这 5 个零件分别连到 5 个不同的控制器。现在，因为它们物理上都离"左前轮眉"最近，所以统统插在 Zone-FL 上。
收益：
- 就近接入：传感器到控制器的线束长度被压缩到极致（通常 < 1米）。
- 接插件标准化：全车 4 个 ZCU 的硬件设计可以是完全一样的（通过软件配置区分），极大降低了供应链管理的复杂度。

2. 功能定义：三位一体的角色

ZCU 不是一个简单的接线板，它是一个高集成度的智能节点，承担着三大核心职责。

(1) 角色一：电源中心 (Power Hub) ------ 智能配电

ZCU 是该区域的"电力心脏"。它直接从蓄电池/DCDC 取电，然后分配给挂在它下面的几十个负载。

去保险丝化 (eFuse) ：
- ZCU 内部集成了数十个 HSD (高边驱动/智能功率开关) 芯片，也就是 eFuse。
- 可编程保护：我们可以通过软件设定每个接口的熔断电流。例如，给大灯的接口限流 5A，给雷达的接口限流 1A。
- 故障隔离：如果左大灯短路了，ZCU 会微秒级切断大灯供电，并上报给中央大脑，而不会影响插在旁边的雷达。
- 能耗管理：当车辆进入"哨兵模式"且电量低时，中央大脑发令，ZCU 可以切断除摄像头以外所有非必要负载的电源。

(2) 角色二：数据网关 (Data Gateway) ------ 协议转换

ZCU 下面挂的设备五花八门，通信协议各不相同。ZCU 的任务是将这些"方言"翻译成"普通话"。

下行接口 (Downlink) ：
- CAN/CAN-FD：连接雷达、传统 ECU。
- LIN：连接车窗、氛围灯、雨量感应器。
- A2B：连接麦克风、扬声器。
- Analog/Digital I/O：采集温度传感器电压、读取开关状态。
上行接口 (Uplink) ：
- 车载以太网 (1000Base-T1 / 10G-T1)。
工作流：ZCU 收到 LIN 总线上的"车窗位置"信号 -> 封装成以太网 UDP/SOMEIP 包 -> 通过骨干网发送给中央大脑。反之亦然。

(3) 角色三：I/O 代理 (I/O Proxy) ------ 边缘驱动

ZCU 还需要具备一定的驱动能力，直接控制那些"哑巴"执行器。

H 桥驱动：ZCU 内部集成 H 桥电路，直接输出大电流驱动车窗升降电机、后视镜折叠电机。
PWM 生成：中央大脑只发指令"LED 亮度 50%"，ZCU 负责生成对应的 PWM 波形来点亮氛围灯。
实时性补救 ：
- 虽然逻辑上收了，但某些极高实时性的功能（如防夹手算法），可能会保留在 ZCU 本地执行，以避免来回传输的时延造成夹伤。这就是**"边缘计算"**在 ZCU 上的体现。

3. ZCU 的硬件形态

一个典型的 ZCU 硬件架构通常包含：

主控 SoC/MCU ：通常选用 Infineon Aurix TC3xx/TC4xx 或 NXP S32Z/E 系列。
- 要求：高算力（处理协议转换）、高实时性、高功能安全 (ASIL-D)。
以太网 Switch：用于连接骨干网和其他 ZCU（环网冗余）。
功率级 (Power Stage)：密密麻麻的 eFuse 芯片和电机驱动芯片，占据了 PCB 板 60% 的面积。

结论：

ZCU 是 Zonal 架构的基石。它让上层的中央大脑可以从繁琐的硬件细节中解脱出来，专注于业务逻辑；同时它接管了底层的脏活累活（配电、驱动、协议转换），实现了软硬解耦的物理隔离。