部署视图建模语言：SysML与UML部署图基础
说到部署视图，很多嵌入式工程师第一反应是：“画个框图不就行了？”
嗯，我早年也这么干过。直到有一次，一个多核异构项目，我在白板上画了十几条线，结果硬件团队和软件团队对“这条线到底走的是SPI还是I2C”吵了三天。从那以后，我老老实实开始用SysML和UML部署图来建模。
说白了，部署视图就是一张“物理地图”。它告诉你：代码跑在哪个芯片上？芯片之间怎么连？数据走哪条路？
2.1 为什么需要专门的建模语言？
你想想看，一个典型的嵌入式系统里，可能有MCU、FPGA、DSP、传感器、执行器，还有各种总线。光靠自然语言描述，很容易产生歧义。
我见过最夸张的案例：一个团队用PPT画部署图，箭头画了三种颜色，红色代表I2C，蓝色代表SPI，绿色代表UART。结果新来的同事把红色箭头理解成了“电源线”……
SysML和UML部署图就是为了解决这类问题。它们提供了标准化的符号和关系，让团队里每个人看到同一张图，理解的是同一件事。
核心价值：部署图是架构师与硬件工程师、测试工程师之间的“共同语言”。没有它，你的架构文档就是一本“天书”。
2.2 UML部署图的三大核心元素
UML部署图其实不复杂。我习惯把它拆成三个东西：节点、组件、连接线。记住这三个，你就掌握了80%。
| 元素 | 符号 | 含义 | 我见过的坑 |
|---|---|---|---|
| 节点（Node） | 立方体（3D盒子） | 物理硬件，如MCU、传感器、网关 | 有人把“虚拟机”也画成节点，其实应该用“执行环境” |
| 组件（Component） | 带两个小矩形的盒子 | 软件模块，如任务、驱动、协议栈 | 组件和节点混在一起画，分不清“跑在哪儿” |
| 连接线（Connector） | 实线/虚线/带箭头线 | 物理链路或通信协议 | 不标注协议类型，后期联调时才发现速率不匹配 |
2.3 SysML与UML部署图的区别
很多人问：“我该用SysML还是UML？”
我的建议是：看你的系统复杂度。如果只是单MCU+几个外设，UML部署图完全够用。但如果涉及多层级、多总线、多协议，SysML的扩展能力会让你省很多事。
| 对比维度 | UML部署图 | SysML部署图 |
|---|---|---|
| 起源 | 软件工程 | 系统工程 |
| 节点类型 | 设备、执行环境 | 块（Block），可嵌套 |
| 连接线语义 | 通信路径 | 流、接口、物理链路 |
| 适用场景 | 纯软件部署 | 软硬件协同、多学科系统 |
| 我个人偏好 | 中小型项目 | 大型异构系统 |
小技巧：如果你不确定用哪个，先从UML部署图开始。等发现“节点嵌套”和“流端口”不够用时，再升级到SysML。我手头好几个项目都是这么过渡的，平滑得很。
2.4 节点、组件、连接线的实战关系
光讲理论没意思。咱们直接看一个实际案例：一个智能网关系统。
这张图里，三个节点（主控MCU、无线模块、传感器节点）通过两种连接线（SPI、I2C）互联。每个节点内部又部署了对应的软件组件。
你看，这样画出来，硬件团队知道要留哪些接口，软件团队知道要写哪些驱动，测试团队知道要测哪些通信链路。一张图，三方受益。
我曾经踩过的坑：早期画部署图时，我习惯把“组件”直接写在节点外面，用虚线指向节点。结果评审时，硬件工程师问：“这个组件是单独一个芯片吗？”软件工程师问：“这个组件跑在哪个核上？”后来我改成把组件画在节点内部，再也没人问过这种问题。
2.5 连接线的语义：不只是“一根线”
很多新手画部署图，连接线就是一条直线，什么都不标。这其实浪费了部署图最重要的表达能力。
我个人习惯，每条连接线至少标注三样东西：
- 物理介质：SPI、I2C、UART、CAN、Ethernet
- 速率/带宽：20MHz、400kHz、1Mbps
- 协议栈：Modbus RTU、MQTT-SN、TCP/IP
举个例子，同样是“一根线”，标注“SPI @ 20MHz”和标注“I2C @ 400kHz”，对后续的时序分析和资源估算影响巨大。
经验之谈：连接线的标注越详细，后期联调时扯皮越少。我见过一个项目，就因为没标注“CAN总线速率”，导致两个节点一个配了250kbps，一个配了500kbps，查了整整两天才找到原因。
2.6 SysML的扩展：流端口与接口块
如果你的系统比较复杂，比如有多个子系统通过不同协议交互，UML部署图可能就不够用了。这时候SysML的流端口（Flow Port）和接口块（Interface Block）就派上了用场。
流端口可以理解为“节点上的插座”。它明确规定了数据流的方向和类型。比如一个传感器节点，可以定义两个流端口：一个输出温度数据（float），一个输出湿度数据（float）。
接口块则是对一组流端口的封装。比如“I2C接口块”包含SCL和SDA两个流端口，以及对应的时序约束。
| SysML元素 | 作用 | 类比 |
|---|---|---|
| 流端口（FlowPort） | 定义数据流入/流出节点的接口 | 物理插座 |
| 接口块（InterfaceBlock） | 封装一组流端口及其协议 | 插头标准 |
| 项流（ItemFlow） | 描述流经连接线的具体数据 | 电流 |
我记得在一个车载项目中，我们用SysML的接口块定义了CAN总线的完整协议。每个ECU节点只需要“插上”对应的接口块，通信规则就自动对齐了。后期新增一个ECU，画图时间从半天缩短到半小时。
2.7 部署图的层次化建模
一个复杂的嵌入式系统，不可能一张图画完所有细节。我通常的做法是：分层建模。
- 第0层（系统级）：只画主要节点和它们之间的物理连接。比如“主控板”、“传感器板”、“执行器板”。
- 第1层（板级）：展开每个板子内部的芯片和总线。比如“主控板”内部有MCU、Flash、RAM、电源管理芯片。
- 第2层（芯片级）：展开每个芯片内部的核、外设、内存映射。比如MCU内部有Cortex-M7核、DMA控制器、SPI外设。
这样做的好处是：不同角色的工程师只看自己关心的那一层。项目经理看第0层，硬件工程师看第1层，驱动工程师看第2层。各取所需，互不干扰。
我的习惯：每一层部署图都保留一个“上下文框”，标注当前层属于上一层的哪个节点。这样即使图纸多了，也不会迷路。
2.8 部署图与接口定义的衔接
部署图画完了，下一步就是接口定义。这两者其实是“一张皮”。
部署图中的每条连接线，都应该对应一份接口定义文档（IDD）。IDD里写明：物理层参数、数据格式、时序要求、错误处理机制。
我见过最规范的团队，部署图里的每条连接线都有一个编号，比如“LINK-001”。这个编号直接对应IDD里的章节号。评审时，指着部署图说“这条线有问题”，然后翻到IDD的对应章节，三分钟就能定位问题。
核心原则：部署图是“骨架”，接口定义是“血肉”。没有接口定义的部署图，只是一张漂亮的画。
2.9 常见误区与避坑指南
最后，分享几个我这些年见过的典型错误：
- 误区一：节点画得太抽象。比如只写“MCU”，不写具体型号。结果硬件选型变了，部署图得重画。我的建议：至少写到系列，比如“STM32H7”。
- 误区二：连接线不标协议。画一条线，不写是SPI还是I2C。后期联调时，软件团队和硬件团队各执一词。我的建议：每条线至少标协议和速率。
- 误区三：组件和节点混为一谈。把“协议栈”和“MCU”画在同一层级。我的建议：组件必须放在节点内部，或者用“部署”关系明确指向。
- 误区四：一张图画到底。试图在一张图里塞进所有细节。我的建议：分层建模，每张图只表达一个抽象层级。
我曾经犯过的错：在一个多核项目中，我把所有核、所有外设、所有任务都画在一张部署图上。结果图太大，打印出来要贴满整面墙。评审时，大家盯着图看了十分钟，谁也没找到自己关心的部分。后来我花了三天重新分层，才把评审会开下去。
好了，关于部署视图的建模语言，咱们就聊到这儿。记住三个核心：节点、组件、连接线。画图时多问自己一句：“这张图，硬件工程师看得懂吗？软件工程师看得懂吗？测试工程师看得懂吗？”如果答案都是“能”，那这张图就合格了。