4、网关角色与功能：中央网关与域网关的职责划分，路由转发策略，网关硬件架构选型

好，咱们今天聊聊网关。说实话，在混合网络架构里，网关就是那个「交通枢纽」。没有它，CAN总线和以太网就是两套独立的系统，根本玩不到一块去。

我个人习惯把网关比作「翻译官+交警」的结合体。它既要懂CAN的报文格式，又要懂以太网的TCP/IP协议栈，还得在两者之间做快速转发。嗯，这里要注意，网关的角色不是一成不变的，它分中央网关和域网关，职责完全不同。

4.1 中央网关 vs 域网关：谁该干什么？

先说说中央网关。它就像整车的大脑，负责跨域通信。我参与过一个项目，中央网关挂接了动力域、底盘域、车身域和智能座舱域。所有跨域的数据，比如「发动机转速要传给仪表盘」，都得经过它。

中央网关的核心职责：

• 跨域路由：把CAN域的数据转发到以太网域，或者反过来。
• 协议转换：CAN的ID过滤、DBC信号解析，到以太网的SOME/IP服务发现，它都得管。
• 安全隔离：不同域的安全等级不一样。动力域要求高实时性，座舱域可以容忍延迟。中央网关得做防火墙。
• 诊断路由：UDS诊断请求从以太网进来，中央网关要能路由到对应的CAN节点。

那域网关呢？它更「专一」。比如一个智能座舱域控制器，内部可能既有以太网交换机，又有CAN接口。它只负责本域内的数据交换，不参与跨域。

我曾经踩过一个坑：某项目把域网关当中央网关用，结果域内通信延迟暴增。为什么？因为域网关的CPU性能有限，处理不了大量跨域路由表。所以，职责划分要清晰——中央网关管「面」，域网关管「点」。

4.2 路由转发策略：三种场景的实战解析

路由转发是网关的核心功能。我把它拆成三种场景：CAN-to-CAN、CAN-to-Eth、Eth-to-Eth。每种场景的转发策略都不一样。

4.2.1 CAN-to-CAN 转发

这个最传统。两个CAN网络，比如动力CAN和车身CAN，通过网关连接。转发策略很简单：基于CAN ID的静态路由表。

举个例子：

// 伪代码：CAN-to-CAN 路由表
路由表项：
  - 源CAN: 动力CAN (ID范围 0x100-0x1FF)
  - 目标CAN: 车身CAN (ID范围 0x200-0x2FF)
  - 动作: 转发，并做ID映射（0x100 -> 0x200）

// 实际项目中，我习惯用位掩码做过滤
if ( (can_id & 0x700) == 0x100 ) {
    // 转发到车身CAN
    send_to_can_bus(can_id | 0x100, data);
}

这里有个避坑指南：我曾经遇到过CAN总线负载率过高的问题。原因是网关把所有的报文都转发了，没有做DLC（数据长度码）检查和周期抑制。后来我加了一个「周期转发限制」——同一个ID的报文，1秒内最多转发10次。嗯，效果立竿见影。

4.2.2 CAN-to-Eth 转发

这个就复杂了。CAN报文是短帧（8字节），以太网帧是长帧（1500字节）。怎么把CAN报文塞进以太网？

我建议用SOME/IP协议。SOME/IP可以把多个CAN信号打包成一个以太网服务。比如：

// SOME/IP 服务定义
service ID: 0x1234 (发动机状态服务)
method: getEngineSpeed
  - 输入: 无
  - 输出: uint16 engineSpeed (来自CAN ID 0x0A)

// 网关收到CAN报文 0x0A 后，更新本地缓存
// 当以太网客户端请求时，直接返回缓存值

实际项目中，我见过两种策略：

• 实时转发：CAN报文一到，立即封装成UDP包发出去。延迟低，但网络带宽浪费大。
• 周期打包：每10ms收集一次CAN报文，打包成一个以太网帧。带宽利用率高，但延迟增加。

我个人习惯用「混合模式」：关键信号（如刹车状态）实时转发，非关键信号（如车窗位置）周期打包。你想想看，刹车信号延迟1ms可能出事故，车窗信号延迟100ms谁在乎？

4.2.3 Eth-to-Eth 转发

这个相对简单，就是二层交换或三层路由。但要注意，车载以太网通常用AVB（音频视频桥接）或TSN（时间敏感网络）做流量整形。

举个例子：

// 基于VLAN的转发策略
if (eth_frame.vlan_id == 10) {
    // 动力域流量，优先级高，走TSN队列
    enqueue_tsn_queue(eth_frame, priority=7);
} else if (eth_frame.vlan_id == 20) {
    // 座舱域流量，优先级低，走普通队列
    enqueue_normal_queue(eth_frame, priority=3);
}

这里要注意，Eth-to-Eth转发不能简单「存转发」。因为车载网络对延迟敏感，我建议用「直通转发」模式——收到帧头就立刻开始转发，不用等整个帧收完。当然，这需要硬件支持。

4.3 网关硬件架构选型

硬件选型，说白了就是「算力、接口、成本」的平衡。我见过三种主流方案：

方案类型	核心芯片	适用场景	优缺点
MCU+独立CAN控制器	Infineon TC3xx + NXP SJA1105	低端中央网关	成本低，但CAN通道数有限（最多8路）
MPU+以太网交换机	NXP i.MX8 + Marvell 88Q5050	高端中央网关	算力强，支持TSN，但功耗高
FPGA+软核	Xilinx Zynq + 自定义IP	定制化域网关	灵活性极高，但开发周期长

我个人比较推荐第二种方案。为什么？因为MPU可以跑Linux或QNX，方便做协议栈和路由表管理。我在一个项目中用了i.MX8，配合Marvell的交换机芯片，轻松实现了8路CAN和4路以太网的路由转发。

但要注意，硬件选型时一定要考虑「余量」。我曾经选了一颗MCU，算力刚好够用。结果后期加了OTA功能，CPU负载直接飙到90%。嗯，从那以后我选型都留30%的余量。

最后说一句，网关的硬件架构选型，一定要和软件架构一起考虑。比如，你选了MPU方案，那就要考虑要不要上Linux。Linux的好处是生态好，但实时性差。如果要做TSN，我建议用RT-Linux或者直接上QNX。

好了，这一章就聊到这里。下一章我们聊聊「网络管理与诊断：DoIP、UDS on Ethernet、网络唤醒与休眠」。这些内容在实际项目中非常实用，尤其是DoIP，现在的新车基本都标配了。