2、硬件系统架构设计：功能模块划分、硬件拓扑结构与电源树分析
各位同学，咱们接着聊。上一章我讲了域控制器为什么会出现，这一章咱们直接切入正题——硬件系统架构到底该怎么搭？
说实话，很多刚入行的工程师容易犯一个毛病：一上来就选芯片、画原理图。我当年也干过这事，结果呢？板子画完了发现电源不够用，或者某个传感器接口带宽不够。嗯，这就是典型的「只见树木不见森林」。
所以，做架构设计的第一步，不是画原理图，而是先把功能模块分清楚。
2.1 功能模块划分：感知、决策、执行
自动驾驶的硬件系统，说白了就干三件事：看路、想事、动手。对应到硬件上，就是三个功能域：感知、决策、执行。
核心原则：每个功能域对硬件的需求完全不同，必须独立设计、独立供电、独立监控。
2.1.1 感知模块
感知模块负责「看」。摄像头、激光雷达、毫米波雷达、超声波，这些都是感知的「眼睛」。
我个人习惯把感知模块再细分成两类：
- 视觉感知：摄像头为主，需要高带宽、低延迟的数据传输。我建议用MIPI CSI接口，单路带宽能到4Gbps以上。
- 雷达感知：激光雷达和毫米波雷达，数据量相对小，但对实时性要求极高。一般用GMSL或者以太网。
这里有个坑，我踩过。有一次项目里，我把摄像头和激光雷达的数据都挂在同一条PCIe总线上。结果激光雷达一启动，摄像头画面就开始丢帧。为什么？因为激光雷达的数据突发性太强，把总线带宽占满了。后来我学乖了，感知模块内部也要做数据隔离。
2.1.2 决策模块
决策模块是大脑。它要处理感知数据、做路径规划、发控制指令。
这个模块对算力的要求是最高的。我见过有人用一颗SoC包打天下，结果发现CPU跑满了，GPU闲着，NPU也闲着。这就是典型的「算力不匹配」。
我的建议是：
- 主控SoC：负责AI推理和路径规划，建议用带NPU的芯片，比如Orin、TDA4这类。
- MCU：负责安全监控和冗余控制，必须满足ASIL-D等级。
- FPGA：如果你要做传感器融合或者低延迟处理，FPGA是个好选择。我在一个项目中用FPGA做激光雷达点云预处理，延迟从5ms降到了0.5ms。
个人经验：决策模块的散热设计一定要留余量。我见过一个项目，SoC满载时温度飙到105°C，直接触发降频。自动驾驶在高速上降频？想想都后怕。
2.1.3 执行模块
执行模块负责「动手」。转向、刹车、油门，这些控制指令最终要传到执行器上。
执行模块对实时性和安全性的要求是最高的。你想想看，刹车指令晚1ms，可能就多跑出去几厘米。
我建议：
- 执行模块必须用独立的MCU控制，不能和决策模块共用一颗芯片。
- 通信协议用CAN FD或者FlexRay，延迟要控制在微秒级。
- 必须做冗余设计。我曾经在一个项目中，执行模块的CAN总线断了，结果车子直接失控。从那以后，我所有的设计都要求双路CAN备份。
2.2 硬件拓扑结构：星型、环型、网状
功能模块分好了，接下来就是怎么把它们连起来。这就涉及到拓扑结构了。
常见的拓扑有三种：星型、环型、网状。我一个个说。
2.2.1 星型拓扑
星型拓扑是最常见的。一个中心节点（域控制器），连接所有外围设备（传感器、执行器）。
优点：
- 结构简单，容易扩展
- 故障隔离好，一个设备坏了不影响其他设备
缺点：
- 中心节点是单点故障
- 线束多，成本高
我个人习惯在L2+级别的系统中用星型拓扑。因为结构简单，调试方便。但如果你做L3以上，星型拓扑就不够用了。
2.2.2 环型拓扑
环型拓扑，说白了就是所有设备串成一个环。数据沿着环走，一个设备坏了，数据可以从另一个方向绕过去。
优点：
- 冗余性好，单点故障不影响整体
- 线束少，成本低
缺点：
- 延迟不确定，数据要绕一圈才能到目的地
- 故障诊断复杂
环型拓扑在自动驾驶里用得不多。我见过一些商用车项目用环型，但乘用车很少用。为什么？因为延迟不可控，你想想看，刹车指令绕一圈才到执行器，谁敢用？
2.2.3 网状拓扑
网状拓扑是最可靠的。每个设备都和其他设备相连，任意一条路径断了，都能找到替代路径。
优点：
- 可靠性最高
- 延迟低，路径灵活
缺点：
- 成本高，线束复杂
- 设计难度大
网状拓扑一般用在L4/L5级别的系统中。我记得有一个项目，客户要求「任何单点故障都不能导致功能丧失」。最后我们用了网状拓扑，每个传感器都有两条独立路径连接到域控制器。成本翻了一倍，但安全性确实上去了。
避坑指南：我曾经在一个项目中，为了省钱用了星型拓扑，结果一个摄像头接口坏了，整个感知系统瘫痪。从那以后，我坚持「关键路径必须冗余」。你想想看，一个摄像头坏了，车子还能开；但决策模块坏了，车子就彻底废了。
2.3 电源树与功耗预算分析
电源设计，是硬件架构里最容易出问题的地方。我见过太多项目，板子画完了发现电源不够用，或者某个电压纹波太大导致芯片工作不稳定。
所以，做电源设计的第一步，是画电源树。
2.3.1 电源树结构
电源树，说白了就是一张图，告诉你电从哪来、到哪去、经过哪些转换。
一个典型的自动驾驶域控制器电源树长这样：
12V电池输入
├── 5V (给传感器供电)
│ ├── 摄像头1
│ ├── 摄像头2
│ └── 激光雷达
├── 3.3V (给SoC和MCU供电)
│ ├── SoC核心
│ ├── MCU核心
│ └── FPGA核心
├── 1.8V (给DDR内存供电)
│ ├── DDR4
│ └── LPDDR5
└── 0.8V (给SoC核心供电)
└── SoC Vcore
嗯，这里要注意：每个电压轨都要独立设计，不能共用。为什么？因为不同芯片对电源纹波的要求不一样。SoC核心电压要求纹波小于1%，而传感器供电可以放宽到5%。混在一起，谁都满足不了。
2.3.2 功耗预算分析
功耗预算，就是算清楚每个模块到底吃多少电。
我一般分三步走：
- 统计峰值功耗：每个芯片的datasheet里都有典型功耗和峰值功耗。我建议按峰值功耗算，留20%余量。
- 计算总功耗：把所有模块的峰值功耗加起来，就是总功耗。
- 设计电源方案：根据总功耗选择电源芯片和散热方案。
举个例子，一个L3级别的域控制器，功耗预算大概是这样：
| 模块 | 典型功耗 (W) | 峰值功耗 (W) | 备注 |
|---|---|---|---|
| SoC (Orin) | 45 | 75 | AI推理时功耗最高 |
| MCU | 2 | 3 | 安全监控，功耗低 |
| FPGA | 10 | 15 | 传感器融合 |
| 摄像头 (6路) | 6 | 9 | 每路1.5W |
| 激光雷达 | 15 | 20 | 机械式功耗高 |
| 其他 (接口、存储等) | 5 | 8 | 预留 |
| 总计 | 83 | 130 | 留20%余量后约156W |
关键点：156W的功耗，意味着你需要一个能输出至少15A电流的电源方案。而且散热设计必须跟上，否则芯片分分钟降频。
2.3.3 电源设计中的常见坑
我踩过的坑，分享给你们：
- 电源纹波太大：有一次我用了一颗便宜的DC-DC芯片，结果纹波高达50mV，SoC直接死机。后来换了颗纹波10mV的芯片，问题解决。
- 上电时序不对：SoC要求先上核心电压，再上IO电压。顺序反了，芯片可能烧掉。我建议用电源管理芯片（PMIC）来控制时序。
- 散热不够：一个项目里，我们用了被动散热，结果夏天车内温度60°C，域控制器直接过热保护。后来加了风扇，才勉强压住。
我的习惯：每次做电源设计，我都会先画一张电源树，然后逐级计算功耗。算完之后，再问自己三个问题：
- 峰值功耗下，电源芯片能撑住吗？
- 散热方案能压住吗？
- 有没有冗余设计？
三个问题都回答「是」，我才开始画原理图。
小结
这一章咱们聊了三个核心问题：功能模块怎么分、拓扑结构怎么选、电源树怎么搭。
说实话，这些内容看起来简单，但真正做起来，每个细节都可能翻车。我见过太多项目，因为架构设计没做好，后期改板子改到崩溃。
所以，我的建议是：架构设计阶段，多花点时间，后面能省十倍的时间。
下一章，咱们聊聊芯片选型。嗯，那又是一个大坑。