3、软件架构设计：AUTOSAR架构下的DoIP模块、SOME/IP与DoIP的关系、网关中间件设计模式
好，我们进入第三章。这一章，咱们聊聊软件架构。
说实话，很多工程师做DoIP网关，上来就撸代码。结果呢？协议栈耦合严重，诊断刷写一卡顿，定位问题要翻遍整个工程。我早期也犯过这个错。后来被AUTOSAR的架构理念“教育”了一番，才明白——架构设计，才是性能优化的起点。
3.1 AUTOSAR架构下的DoIP模块
AUTOSAR把DoIP模块拆得很干净。它不是一个孤立的“黑盒子”，而是分层协作的产物。我个人习惯把DoIP模块分成三层来看：
- DoIP传输层（DoIP_Tp）：负责TCP/UDP socket管理、报文分片重组。说白了，就是管“怎么把数据发出去”。
- DoIP协议层（DoIP_Pr）：解析DoIP头部，处理路由激活、诊断请求/响应。这是核心逻辑所在。
- DoIP应用层（DoIP_App）：对接上层的诊断服务（比如UDS），或者用户自定义的扩展功能。
为什么要分这么细？我在项目中遇到过一个问题：某次客户要求支持同时处理8个诊断连接。如果所有逻辑揉在一起，光是socket事件分发就能把CPU吃满。分层之后，传输层只管收发，协议层只管解析，应用层只管业务。每一层都可以独立优化。
关键点： DoIP模块在AUTOSAR中通常作为BswM（基础软件管理器）的一个受控模块。它的状态机与ECU的上下电、网络管理状态紧密绑定。不要把它当成一个“一直运行”的服务。
嗯，这里要注意：AUTOSAR的DoIP模块配置项非常多。比如DoIPGeneral里的DoIPMaxSocketConnections，这个参数直接影响并发能力。我见过有人配成1，结果只能连一个诊断仪，还以为是代码bug。
3.2 SOME/IP与DoIP的关系
很多新手会问：SOME/IP和DoIP，到底啥关系？
你想想看，DoIP是“诊断协议”，它跑在TCP/UDP上，目的是让诊断仪能远程刷写、读故障码。SOME/IP是“服务发现与通信协议”，它跑在UDP/TCP上，目的是让ECU之间能动态发现服务、调用方法。
它们俩，其实是“兄弟关系”，不是“替代关系”。
在网关里，它们经常共存：
- DoIP：负责外部诊断仪与网关的通信。诊断仪发个0x10 02（诊断会话控制），网关通过DoIP接收，再转发给目标ECU。
- SOME/IP：负责网关内部与各个ECU的通信。网关收到DoIP诊断请求后，可能通过SOME/IP的Event或Method，把请求转发给智能传感器。
我曾经在一个项目中，把DoIP和SOME/IP的socket混在一起处理。结果呢？SOME/IP的SD（服务发现）报文和DoIP的AliveCheck报文互相干扰，导致诊断连接频繁超时。后来我强制把它们分到不同的任务优先级里，问题才解决。
我的建议： 如果网关同时支持DoIP和SOME/IP，一定要在架构设计阶段就明确：DoIP走独立的Socket通道，SOME/IP走另一组。不要复用同一个接收线程。否则，SOME/IP的周期性广播会挤占DoIP的实时诊断流量。
说白了，DoIP追求的是“确定性延迟”，SOME/IP追求的是“动态灵活性”。两者设计哲学不同，混在一起必须做隔离。
3.3 网关中间件设计模式
网关中间件，是DoIP模块的“骨架”。我常用的设计模式有三种，这里分享给你：
3.3.1 管道-过滤器模式（Pipeline-Filter）
这是我最喜欢的一种。把DoIP报文的处理流程拆成一个个独立的Filter：
- Filter 1：Socket接收 —— 从TCP/UDP缓冲区读取原始字节流。
- Filter 2：DoIP头部解析 —— 提取协议版本、负载类型、长度。
- Filter 3：路由决策 —— 根据目标逻辑地址，决定转发到哪个内部ECU。
- Filter 4：协议转换 —— 如果需要，把DoIP报文转成SOME/IP或CAN诊断报文。
- Filter 5：发送 —— 把转换后的报文发出去。
每个Filter只做一件事。这样，你想优化“路由决策”的性能，只需要改Filter 3，其他不动。我在项目中用这个模式，把诊断报文的端到端延迟从15ms降到了5ms。
// 伪代码示例：管道-过滤器模式
typedef struct {
void (*process)(uint8_t* data, uint32_t len);
} Filter_t;
Filter_t pipeline[] = {
{socket_receive},
{doip_header_parse},
{route_decision},
{protocol_convert},
{transmit}
};
void DoIP_MainFunction(void) {
for (int i = 0; i < sizeof(pipeline)/sizeof(Filter_t); i++) {
pipeline[i].process(buffer, length);
}
}
避坑指南： 我曾经在Filter之间直接传递原始指针，结果某个Filter异常修改了数据，导致后续Filter全部崩溃。后来我强制要求：每个Filter必须拷贝一份数据，或者使用不可变缓冲区。性能损失不大，但安全性提升很多。
3.3.2 事件驱动模式（Event-Driven）
网关里有很多异步事件：Socket收到数据、定时器超时、内部ECU上报状态。用事件驱动模式，把这些事件统一投递到一个事件队列里，然后由主循环或任务逐个处理。
这样做的好处是：你不用在每个中断里做复杂处理。中断只负责“投递事件”，主循环负责“处理事件”。我见过有人直接在Socket接收中断里做DoIP协议解析，结果中断延迟过高，导致系统看门狗复位。
3.3.3 状态机模式（State Machine）
DoIP连接本身就是一个状态机：
| 状态 | 说明 | 典型事件 |
|---|---|---|
| LISTEN | 等待客户端连接 | TCP连接建立 |
| INITIALIZE | 等待路由激活 | 收到路由激活请求 |
| ACTIVE | 正常诊断通信 | 诊断请求/响应 |
| DIAGNOSTIC_SESSION | 诊断会话进行中 | 会话切换、超时 |
| CLOSING | 连接关闭中 | TCP断开、超时 |
每个状态对应一组处理函数。状态切换清晰，代码可读性极高。我建议每个DoIP连接实例都维护一个独立的状态机，不要全局共享。
总结一下： 管道-过滤器模式适合“数据流处理”，事件驱动模式适合“异步事件处理”，状态机模式适合“连接生命周期管理”。三者可以组合使用。比如：用事件驱动接收Socket数据，用管道-过滤器处理数据，用状态机管理连接状态。
嗯，这一章内容不少。你消化一下。下一章，我们开始聊“性能优化实战”，我会拿一个真实项目中的DoIP网关延迟问题，手把手带你分析、定位、优化。