第二章 架构分层策略：明确混编边界，定义SWC与BSW模块的交互接口
好，咱们接着聊。上一章我们讲了为什么要混编，以及混编可能踩的坑。这一章，我重点说说怎么在架构层面把这件事理顺。
说白了，混编最怕什么？最怕代码像一团乱麻，AUTOSAR的SWC里直接调了非AUTOSAR的全局变量，非AUTOSAR的驱动又偷偷改了BSW的配置。这种代码，我见过太多。维护起来，那叫一个酸爽。
所以，核心就一句话：划清边界，定义接口。边界清晰了，两边各干各的，互不干扰。接口定义好了，两边又能协同工作。这才是混编的正确姿势。
2.1 混编架构的核心分层原则
我个人习惯，把整个系统分成三层来看：
- 应用层（SWC层）：跑AUTOSAR的SWC，或者你写的非AUTOSAR应用代码。这一层只管业务逻辑。
- 中间层（RTE + 适配层）：这是混编的关键。RTE负责AUTOSAR SWC之间的通信。适配层负责把非AUTOSAR代码“包装”成AUTOSAR能理解的样子。
- 基础软件层（BSW层）：包括OS、MCAL、通信栈、诊断栈等。这一层，我建议尽量保持纯AUTOSAR，别乱动。
你想想看，这样一分，问题就简单了。非AUTOSAR代码只能通过适配层跟BSW打交道，不能直接捅到BSW内部去。SWC也只能通过RTE跟外界通信，不能直接调用BSW的函数。
核心原则：非AUTOSAR代码不能直接调用BSW模块的内部API。必须通过一个“适配层”或“封装层”进行转换。
2.2 定义SWC与非AUTOSAR代码的交互接口
这里我分两种情况来讲。
2.2.1 情况一：SWC需要调用非AUTOSAR代码的功能
比如，你的SWC里有个算法，需要用到一段已有的、经过验证的非AUTOSAR信号处理库。怎么办？
我的做法是：在RTE层面定义一个Client-Server接口。SWC作为Client，发送请求。然后，在RTE的底层，我写一个“Wrapper SWC”或者一个“BSW模块的扩展”，作为Server，去调用那个非AUTOSAR库。
代码示例（伪代码，描述接口定义）：
// RTE 接口定义 (SWC 视角)
// Client-Server 接口: SignalProcessing
// 操作: ProcessSignal(InputSignal) -> OutputSignal
// SWC 内部调用
OutputSignal = Rte_Call_SignalProcessing_ProcessSignal(InputSignal);
// 适配层实现 (非AUTOSAR侧)
// 这个函数由适配层提供，被RTE回调
Std_ReturnType Adapter_ProcessSignal(const SignalType* Input, SignalType* Output) {
// 调用非AUTOSAR的库函数
NonAutosar_SignalLib_Process(Input, Output);
return E_OK;
}
嗯，这里要注意。这个适配层的代码，我建议放在一个独立的C文件中，不要跟BSW的代码混在一起。编译的时候，也单独建一个组件。
2.2.2 情况二：非AUTOSAR代码需要读取SWC的数据
这种情况更常见。比如，一个非AUTOSAR的Bootloader，需要知道当前系统有没有故障码。
我的建议是：不要直接读SWC的内部变量。而是通过BSW的NvM模块或者Dcm模块来间接获取。
具体做法：SWC把故障码状态写入NvM。非AUTOSAR代码通过NvM的API（当然，也是经过适配层封装过的）去读取。
我的经验：我曾经在一个项目里，非AUTOSAR代码直接通过指针访问了SWC的全局变量。结果SWC升级后，变量地址变了，整个Bootloader就挂了。从那以后，我坚决要求所有跨边界的数据访问，都必须经过BSW的标准化服务。
2.3 定义BSW模块与非AUTOSAR代码的交互接口
BSW模块，比如MCAL、CanIf、EcuM，它们有自己标准的AUTOSAR接口。非AUTOSAR代码想用这些功能，怎么办？
答案还是：适配层。
我举个例子。非AUTOSAR代码想发一帧CAN报文。它不能直接调用Can_Write()，因为Can_Write()是MCAL的API，它的调用上下文、参数格式都是为AUTOSAR栈设计的。
正确的做法是：
- 非AUTOSAR代码调用适配层提供的接口，比如
Adapter_Can_SendMessage(MessageId, Data, Length)。 - 适配层内部，把参数转换成AUTOSAR CanIf层需要的格式，然后调用
CanIf_Transmit()。
表格对比一下直接调用和适配层调用的区别：
| 方式 | 优点 | 缺点 |
|---|---|---|
| 直接调用BSW API | 简单直接，开发快 | 耦合度高，BSW升级或更换时，非AUTOSAR代码必须改 |
| 通过适配层调用 | 解耦，BSW变化不影响上层代码 | 多了一层调用，有轻微性能损耗 |
我个人强烈推荐第二种。那点性能损耗，跟维护成本比起来，根本不值一提。
2.4 实战中的边界划分清单
好了，理论说完了。我给大家列一个我在项目中实际使用的检查清单。每次做混编架构评审时，我都会拿着这个清单过一遍。
- 数据流边界：所有跨边界的数据交换，是否都通过RTE或BSW的标准化服务（NvM, Dcm, CanIf等）？有没有直接的内存访问？
- 控制流边界：非AUTOSAR代码是否直接调用了BSW模块的内部函数？是否都经过了适配层？
- 时序边界：非AUTOSAR代码是否在中断中直接调用了RTE的API？这会导致RTE的调度混乱。必须通过OS的Task机制来桥接。
- 资源边界：非AUTOSAR代码是否直接操作了MCAL的寄存器？这绝对禁止。必须通过MCAL的API。
我曾经踩过的坑：有一个项目，工程师为了图方便，在非AUTOSAR的中断服务函数里直接调用了 EcuM_SetWakeupEvent()。结果导致EcuM的状态机紊乱，系统无法正常休眠。查了三天才找到原因。所以，中断里绝对不能直接调用BSW模块的API，必须通过OS的Task来间接处理。
2.5 总结一下
这一章的核心，就是建立“边界意识”。
把系统分成三层，定义好每一层之间的接口。非AUTOSAR代码和AUTOSAR代码，就像两个国家，通过“海关”（适配层）进行贸易。你不能让一个国家的公民直接跑到另一个国家的政府大楼里去办公，对吧？
下一章，我会具体讲讲适配层的代码怎么写，以及如何用AUTOSAR的配置工具来管理这些混编组件。到时候见。