第2章：SecOC协议栈架构
好，咱们进入正题。上一章聊了SecOC是干什么的，这一章我们看看它到底在AUTOSAR架构里怎么待着。说白了，就是搞清楚SecOC模块住在哪、跟谁打交道、怎么干活。
2.1 SecOC在AUTOSAR架构中的层级
AUTOSAR架构分三层：应用层、RTE运行时环境、基础软件层。SecOC属于基础软件层，具体在通信服务这一块。我习惯把它想象成一个「安检员」——它不负责造数据，也不负责发数据，它只负责给数据加「安全封印」。
来看层级关系：
| 层级 | 模块 | 职责 |
|---|---|---|
| 应用层 | SWC（软件组件） | 生成原始信号/数据 |
| RTE | 运行时环境 | 路由信号到通信模块 |
| 基础软件层 | COM / PDU Router | 信号打包成PDU |
| 基础软件层 | SecOC | 添加认证标签、新鲜度值 |
| 基础软件层 | CanIf / LinIf / EthIf | 发送到总线 |
嗯，这里要注意：SecOC不是直接挂在总线驱动上的。它夹在PDU Router和接口层之间。为什么这么设计？我当年做第一个项目时也纳闷过——后来发现，这样能让SecOC对上层应用完全透明。应用层根本不知道SecOC的存在，它只管发信号，剩下的安全活儿SecOC全包了。
2.2 与PDU Router的关系
PDU Router是整个通信的「交通枢纽」。所有PDU（协议数据单元）都要经过它。SecOC就挂在PDU Router的出口处，像个检查站。
具体流程是这样的：
- 发送方向：PDU Router把PDU交给SecOC → SecOC计算MAC（消息认证码）并追加新鲜度值 → 返回给PDU Router → 继续往下发
- 接收方向：PDU Router收到PDU → 交给SecOC验证 → 验证通过再返回给PDU Router → 往上送
关键点：SecOC和PDU Router之间是「请求-响应」模式。SecOC不主动抢数据，都是PDU Router叫它干活它才干。
我记得有一次调试，发现PDU老是丢。查了半天，原来是PDU Router的缓冲区配置太小，SecOC处理完返回时缓冲区满了。所以啊，配置SecOC时一定要同步检查PDU Router的缓冲区大小，这个坑我替你们踩过了。
2.3 与CSM（加密服务管理）的交互
CSM是AUTOSAR里专门管加密的模块。SecOC自己不干加密的苦活累活，它只负责调度——说白了，SecOC是「包工头」，CSM是「技术工人」。
交互流程：
- SecOC发起请求：需要计算MAC时，SecOC调用CSM的接口
- CSM执行运算：CSM调用底层的Crypto Driver（硬件加密引擎或软件加密库）
- CSM返回结果：把计算好的MAC值还给SecOC
个人建议：如果你的芯片有硬件加密模块（HSM），一定要让CSM配置成硬件模式。软件算MAC太慢了，我在一个项目里试过，软件算一个AES-128 MAC要花2ms，硬件只要50μs。你想想看，如果一帧报文周期是10ms，软件算MAC直接吃掉20%的时间片，这谁受得了？
CSM和SecOC之间还有个重要概念——Job。每个MAC计算请求就是一个Job。SecOC可以同时发起多个Job，CSM会排队处理。我曾经遇到过一个问题：多个SecOC PDU同时请求MAC计算，CSM队列满了，后面的请求直接被丢弃。解决方案是增大CSM的Job队列深度，或者调整SecOC的处理优先级。
2.4 整体数据流
把上面这些串起来，一个完整的SecOC数据流是这样的：
发送方向：
SWC → RTE → COM → PDU Router → SecOC（加MAC+新鲜度） → PDU Router → CanIf → CAN总线
接收方向：
CAN总线 → CanIf → PDU Router → SecOC（验证MAC+新鲜度） → PDU Router → COM → RTE → SWC避坑指南：我曾经在接收方向踩过一个坑——SecOC验证失败后，默认行为是丢弃PDU。但有些场景下，你需要把验证失败的PDU也上报给应用层做诊断。这个配置项叫「SecOCVerificationFailedNotification」，记得根据需求打开或关闭。
2.5 小结
这一章我们理清了SecOC在AUTOSAR里的位置：
- 它住在PDU Router和接口层之间
- 它跟PDU Router是「你叫我我才干活」的关系
- 它跟CSM是「包工头和技术工人」的关系
下一章我们深入SecOC的核心——新鲜度值和MAC的计算细节。到时候我会拿一个实际项目的配置案例来讲，保证你听完就能上手配。