第四章：SWC与Composition设计——创建SWC、定义Port与Interface、Composition的层级结构
好，咱们进入第四章。这一章可以说是DaVinci Developer实操的核心环节——SWC和Composition的设计。说白了，就是怎么把软件需求变成一个个可落地的组件，再把它们组装起来。
我个人习惯，在设计SWC之前，先想清楚两件事：这个SWC到底负责什么功能？它跟外界怎么通信？想清楚了，再动手去建。
4.1 创建SWC——从零开始搭积木
打开DaVinci Developer，新建一个SWC其实很简单。右键点击Component，选择New SWC。但这里有个坑——SWC的类型选错了，后面全白干。
常见的SWC类型有四种：
| SWC类型 | 适用场景 | 我踩过的坑 |
|---|---|---|
| Application SWC | 纯应用逻辑，比如控制策略、算法 | 大部分功能都用这个 |
| Sensor Actuator SWC | 直接跟硬件打交道的，比如读取ADC | 别把纯逻辑也塞进来 |
| Composition SWC | 用来嵌套子SWC的容器 | 层级别太深，3层以内 |
| Service SWC | 系统级服务，比如NvM、Dcm | 一般由基础软件团队提供 |
举个例子。我在做车身域控制器时，需要设计一个“车窗控制”功能。我创建了一个Application SWC，命名为WndwCtrl_SWC。命名规范很重要，我建议用功能名_SWC的格式，这样后期维护时一眼就能看懂。
4.2 定义Port与Interface——SWC的“嘴巴”和“耳朵”
SWC建好了，它得跟外界说话吧？Port就是它的嘴巴和耳朵。而Interface，就是说话用的“语言协议”。
Port分两种：
- P-Port（提供端口）：SWC对外提供数据或服务。比如车窗SWC提供“当前车窗高度”这个数据。
- R-Port（需求端口）：SWC需要从外界获取数据。比如车窗SWC需要知道“车门是否上锁”。
Interface呢，又分三类：
- Sender-Receiver Interface（S/R）：数据发送与接收，适合周期性数据，比如车速、温度。
- Client-Server Interface（C/S）：请求与响应，适合函数调用，比如“请求打开车窗”。
- Mode Switch Interface：模式切换，比如从“正常模式”切换到“省电模式”。
我记得有一次，一个同事把S/R接口用在了需要确认响应的场景上。结果数据发出去，对方收没收到完全不知道。后来排查了半天，才发现接口类型选错了。所以，选Interface时，先问自己：我需要对方回复吗？
实际操作中，定义Port的步骤是这样的：
- 在SWC上右键，选择New Port。
- 选择Port方向（P-Port或R-Port）。
- 选择或新建Interface。
- 如果是S/R接口，定义Data Element（数据元素）。
- 如果是C/S接口，定义Operation（操作）和参数。
举个例子，车窗SWC需要一个R-Port来获取“车门锁状态”。我这样定义：
Port: R-Port
Interface: DoorLockStatus_IF (S/R类型)
Data Element: DoorLockState (uint8, 0=解锁, 1=上锁)4.3 Composition的层级结构——把积木搭成房子
单个SWC就像一块积木。Composition就是把这些积木搭成房子的框架。在DaVinci Developer里，Composition可以嵌套，形成层级结构。
为什么要用层级？说白了，就是分而治之。一个复杂的系统，如果所有SWC都平铺在顶层，那图会乱成一锅粥。我习惯这样分层：
- 顶层Composition：代表整个ECU或子系统。比如“BCM_Composition”。
- 中间层Composition：代表功能域。比如“Lighting_Composition”、“Wndw_Composition”。
- 底层SWC：具体的功能组件。比如“LeftWndwCtrl_SWC”。
嗯，这里要注意：Composition本身不包含逻辑代码，它只是容器。逻辑都在SWC里。所以别想着在Composition里写代码，那是行不通的。
我在设计一个网关项目时，把Composition分成了三层：
Gateway_Composition (顶层)
├── CanBus_Composition (中间层)
│ ├── CanRx_SWC
│ └── CanTx_SWC
├── Routing_Composition (中间层)
│ ├── SignalRouter_SWC
│ └── PduRouter_SWC
└── Diag_Composition (中间层)
└── UdsHandler_SWC这种结构的好处是：每个Composition可以独立开发、独立测试。CanBus团队只关心CanBus_Composition，Routing团队只关心Routing_Composition。互不干扰。
4.4 实战中的避坑指南
讲几个我亲身经历的坑，你们遇到了可以少走弯路。
坑一：Port连接时类型不匹配
我曾经把两个SWC的Port连在一起，结果RTE生成报错。查了半天，发现两个Port虽然用了同一个Interface，但一个定义的是S/R，另一个定义的是C/S。DaVinci Developer不会自动帮你转换类型，必须手动统一。
坑二：Composition内部Port未暴露
子SWC的Port要跟外界通信，必须在Composition层暴露出来。我见过有人忘了暴露，结果数据死活传不出去。检查方法很简单：在Composition图上，看Port图标有没有“小箭头”指向外部。
坑三：Interface的Data Element顺序
这个坑比较隐蔽。S/R接口的Data Element在发送端和接收端的顺序必须一致。如果不一致，RTE不会报错，但数据会错位。比如发送端发的是[车速, 温度]，接收端按[温度, 车速]解析，那结果就全乱了。
4.5 小结
这一章的内容，说白了就是三件事：建SWC、定义Port、搭Composition。每一步都有细节，但核心思路是清晰的——先想清楚功能边界，再动手设计接口，最后用Composition组织起来。
下一章，我们会讲RTE的配置与代码生成。到时候，这些SWC和Composition就会真正“活”起来，变成可以运行的代码。嗯，敬请期待。