第二章：新能源架构概览
各位同学，咱们今天聊聊新能源EE架构的全貌。说实话，这个题目我讲了不下二十遍，但每次都有新感悟。新能源车的电子电气架构，这几年变化太快了，从分布式到域控，再到中央计算，几乎是一年一个样。
2.1 典型新能源EE架构演进
先说说我最早接触的分布式架构。那时候一辆车上有几十个ECU，每个ECU管自己的那一亩三分地。门控管门控，车窗管车窗，彼此之间通过CAN总线聊聊天。这种架构的好处是简单，坏处嘛——线束重得像条蟒蛇，软件升级得一个个刷。
后来行业开始往域控方向走。我个人习惯把域控分成五类：动力域、底盘域、车身域、座舱域和智驾域。每个域有一个高性能的域控制器，把原来分散的ECU功能收拢起来。我在2019年参与过一个项目，把七个车身ECU合并成一个域控，线束减重了30%，但软件复杂度翻了三倍。
再往后就是中央计算架构了。说白了，就是一台超级计算机管所有事。一个中央计算平台，加上几个区域控制器（Zonal Controller），区域控制器只管IO和供电，算力全部集中。嗯，这里要注意，这种架构对功能安全的要求，比之前高了不止一个量级。
| 架构类型 | ECU数量 | 算力集中度 | 功能安全难度 |
|---|---|---|---|
| 分布式 | 30-50个 | 低 | 低（各管各的） |
| 域控 | 5-8个域控 | 中 | 中（域内耦合） |
| 中央计算 | 1-2个中央+区域 | 高 | 高（单点故障风险） |
2.2 功能安全在架构中的位置
功能安全不是贴在架构上的标签，而是长在架构里的骨架。我经常跟团队讲，别把功能安全当成最后补的作业，那样你会哭的。
在域控架构里，功能安全主要落在每个域控制器内部。比如动力域，ASIL等级通常是D，因为涉及到扭矩控制，一旦出错可能车就窜出去了。座舱域相对宽松，ASIL B就够了，毕竟屏幕黑了你还能靠边停车。
到了中央计算架构，情况就复杂了。一个中央计算平台同时跑着智驾、动力、底盘的功能，安全等级从QM到ASIL D混在一起。这就引出了一个关键问题——混合关键性（Mixed Criticality）。
核心原则：高ASIL的功能不能受低ASIL功能的影响。这是铁律，没得商量。
我在一个项目中遇到过这样的情况：智驾模块（ASIL D）和娱乐模块（QM）跑在同一个SoC上，结果娱乐模块的内存泄漏把智驾模块拖垮了。从那以后，我坚持所有高安全等级的功能必须做时间隔离和空间隔离。
2.3 安全机制与冗余设计
安全机制说白了就是两件事：检测故障和处理故障。检测到了怎么办？降级、切换、还是安全停车？这取决于你的安全目标。
我给大家列几个常用的安全机制：
- 锁步核（Lockstep Core）：两个核跑同样的指令，结果不一致就报错。我在英飞凌TC397上用过，效果不错，但功耗翻倍。
- ECC内存：单比特纠错，双比特检测。别小看这个，宇宙射线打中内存的概率比你想象的高。
- 看门狗（Watchdog）：软件跑飞了，硬件帮你复位。但要注意，独立看门狗和窗口看门狗的区别。
- 故障响应时间（FTTI）：从故障发生到系统响应，必须在规定时间内完成。这个时间窗口很窄，通常只有几十毫秒。
避坑指南：我曾经在一个项目中，看门狗的超时时间设得太长，结果软件卡死了3秒才被复位。3秒在高速上是什么概念？车已经跑出去近百米了。后来我把超时时间压到了100ms以内。
2.3.1 冗余设计策略
冗余不是简单的「多备一份」，而是要有多样性（Diversity）。什么意思？你想想看，如果主系统和备份系统用同样的芯片、同样的算法、同样的编译器，那一个bug就能同时干掉两个系统。
我常用的冗余策略有三种：
- 1oo2（One out of Two）：两个通道，任何一个都能独立完成任务。适合ASIL D的场景。
- 2oo2（Two out of Two）：两个通道必须一致才能输出。适合安全性和可用性都高的场景。
- 2oo3（Two out of Three）：三取二，航空级冗余。新能源车上用得少，成本太高。
举个例子，线控制动系统（Brake-by-Wire）通常用1oo2架构。主控制器失效了，备份控制器立刻接管。但要注意，切换时间不能超过FTTI，否则系统已经进入不安全状态了。
2.3.2 实际项目中的冗余设计
我记得有个项目是做自动驾驶域控，要求ASIL D。我们用了两颗TDA4芯片做1oo2冗余，但问题来了——两颗芯片的供电、时钟、通信都得独立。最后我们做了双路供电、双路CAN、双路以太网，连PCB都做了物理隔离。
测试的时候发现，一颗芯片的电源纹波干扰到了另一颗。查了半天，原来是地平面没分开。嗯，这就是细节，做功能安全的人，得有一颗「强迫症」的心。
警告：冗余设计不是万能的。如果两个通道共享同一个失效模式（比如同一个电源芯片、同一个晶振），那冗余就变成了「假冗余」。做FMEA的时候一定要识别共因失效（Common Cause Failure）。
2.4 架构层面的安全分解
安全分解（Safety Decomposition）是个好东西。什么意思？就是把一个ASIL D的需求，分解成两个ASIL B的需求。这样你就不用所有东西都按最高标准做，成本能降不少。
举个例子，自动紧急制动（AEB）要求ASIL D。我可以分解成：感知模块ASIL B + 执行模块ASIL B。两个模块独立开发，互不干扰。但前提是——独立性必须被证明。
怎么证明独立性？我在项目中常用的方法：
- 硬件层面：独立的电源域、独立的时钟域、独立的通信通道
- 软件层面：不同的内存分区、不同的任务调度、不同的开发团队
- 工具链层面：不同的编译器、不同的静态分析工具
你想想看，如果两个模块用了同一个内存控制器，那一个模块的故障就可能污染另一个模块的数据。独立性不是嘴上说说，是要落实到每一行代码、每一根走线上的。
2.5 小结
新能源EE架构从分布式走到中央计算，功能安全的挑战越来越大。我个人觉得，未来五年，中央计算+区域控制的架构会成为主流，而功能安全会从「附加项」变成「必选项」。
下一章我们会深入聊安全分析的方法论，包括HARA、FMEA、FTA这些工具怎么用。到时候我会拿一个真实的项目案例来拆解，保证你们听完就能上手。
记住一句话：架构决定上限，安全决定下限。没有安全，再好的架构也是空中楼阁。