3. 硬件拓扑抽象：CPU、MCU、FPGA、DSP、传感器、执行器在部署视图中的表示
部署视图说白了，就是告诉团队——你的软件跑在什么硬件上，这些硬件之间怎么连的。我见过不少项目，架构图画得漂漂亮亮，结果一部署发现CPU负载爆了，或者FPGA和MCU之间的接口根本对不上。嗯，这就是硬件拓扑没抽象好。
这一章，我们就把嵌入式世界里最常见的几种处理单元和外围器件，在部署视图里该怎么画、怎么标、怎么定义接口，一次性说清楚。
3.1 处理单元的核心抽象：节点与 stereotype
在部署视图中，每个物理硬件单元都是一个「节点」（Node）。节点之间用通信路径连接。我个人习惯用 UML 部署图的 stereotype 来区分不同类型的处理器。
| 处理单元 | Stereotype 标记 | 典型用途 | 我在项目中踩过的坑 |
|---|---|---|---|
| CPU | <<CPU>> |
运行 Linux/RTOS，处理复杂逻辑、网络协议栈 | CPU 选型时没算中断响应时间，导致实时任务丢帧 |
| MCU | <<MCU>> |
裸机或小型 RTOS，控制、采集、低功耗场景 | MCU 的 Flash 和 RAM 容量经常被低估，尤其是通信协议栈 |
| FPGA | <<FPGA>> |
高速并行处理、自定义接口、硬件加速 | FPGA 的时序约束没在部署视图中体现，导致综合后跑不起来 |
| DSP | <<DSP>> |
音频、雷达、电机控制等数字信号处理 | DSP 的 DMA 通道分配经常和 CPU 冲突，需要提前规划 |
我的习惯： 每个节点除了 stereotype，还会加一个属性标签，比如
{OS=Linux 5.10} 或 {Freq=400MHz}。这样一看就知道这个节点的能力边界。
3.2 传感器与执行器的抽象：外围设备节点
传感器和执行器不是处理单元，但它们必须出现在部署视图中。为什么？因为接口定义需要它们。
我通常把传感器和执行器抽象为两种 stereotype：
<<sensor>>：数据流入系统，比如 IMU、摄像头、温度传感器。<<actuator>>：数据流出系统，比如电机、舵机、加热器。
每个外围设备节点必须标注：
- 通信接口类型：I2C、SPI、UART、CAN、Ethernet。
- 数据速率要求：比如 100Hz 采样，或者 1Mbps 带宽。
- 供电与电气特性：3.3V 还是 5V，电流需求。
我曾经犯过的错： 在一个无人机项目中，我只在部署视图里画了传感器节点，没标注接口速率。结果飞控 MCU 的 I2C 总线被三个传感器共享，速率不够，导致数据采集丢包。后来我强制要求：每个外围设备节点必须带一个「接口约束」标签。
3.3 硬件拓扑结构图：一个完整的示例
下面这张 SVG 图展示了一个典型的嵌入式系统硬件拓扑。它包含一个 CPU（运行 Linux）、一个 MCU（运行 FreeRTOS）、一个 FPGA（做图像预处理）、两个传感器和一个执行器。
核心原则： 部署视图中的每一条连线，都必须对应一个明确的接口定义。如果连线上只写了「SPI」，那这个视图是不合格的。至少要写 SPI 速率、主从关系、数据格式。
3.4 接口定义的三个层次
你想想看，光画个拓扑图够吗？不够。接口定义要落到三个层次上，缺一不可。
| 层次 | 内容 | 交付物 |
|---|---|---|
| 物理层 | 引脚号、电平标准、阻抗匹配、连接器型号 | 原理图引脚表、PCB 布局约束 |
| 数据链路层 | 帧格式、校验方式、流控机制、地址分配 | 通信协议文档、寄存器映射表 |
| 应用层 | 消息 ID、数据字段定义、超时重传策略 | API 头文件、消息序列图 |
我的做法： 在部署视图的每个节点旁边，加一个「接口矩阵」表格的引用。比如
{参见 IF-MATRIX-03}。这样架构图不会太拥挤，但又能追溯到详细定义。
3.5 避坑指南：硬件拓扑抽象中的常见错误
- 把软件组件画进硬件节点：部署视图只放物理硬件，软件组件是组合视图的事。混在一起会让团队搞不清谁负责什么。
- 忽略电源域和时钟域：我曾经在一个多板系统中，CPU 和 FPGA 用不同电源轨，结果上电时序不对，FPGA 配置失败。后来我在部署视图里加了一个「电源域」分组。
- 不标注冗余和容错：如果系统要求高可用，部署视图里必须画出冗余节点和切换路径。否则测试阶段才发现单点故障。
- 接口速率只写理论值：SPI 标 10MHz 没问题，但实际线长、负载电容都会降速。我习惯在接口约束里写「有效速率」和「最差情况速率」。
记住： 部署视图不是给硬件工程师看的，是给整个团队看的。软件工程师需要知道数据从哪里来、到哪里去、延迟多少。测试工程师需要知道哪些接口需要覆盖。项目经理需要知道硬件成本分布。所以，抽象层次要适中，信息要完整。