| 编辑推荐: |
本文主要介绍了车载网关在汽车电子电气架构中的真实角色和核心功能,希望对你的学习有帮助。
本文来自于从零学嵌入式 ，由火龙果软件Alice编辑，推荐。 |
|
很多人知道车上有"网关"这个零件，但问到它具体干什么，往往答不上来。说它是路由器吧，车上的网络又不完全等于以太网。说它是翻译器吧，它翻译的到底是CAN信号还是什么别的东西。模糊的理解直接导致一个后果：车上通信出了任何问题，第一反应就是"查查网关"。网关成了一个筐，什么都往里装。这篇文章把车载网关的真实角色讲清楚。
先给结论： 车载网关是车内不同通信网络之间的枢纽节点，它的核心价值是实现跨域数据的可靠传递，同时保护关键网络不被其他网络的流量和故障所影响。 理解这句话，三个关键词：跨域、可靠、保护。
一、为什么车内需要网关
要理解网关为什么存在，先看看现代汽车的网络架构有多复杂。
一辆普通家用车里，通常有5到8个独立的通信网络。动力总成域有动力CAN，底盘有底盘CAN，车身有车身CAN和LIN网络，娱乐系统用以太网，智驾系统也有独立的以太网，诊断和OBD还有专门的诊断CAN。
这些网络加在一起，可能承载了上百个ECU之间数千个信号的数据交换。
为什么不能统一成一个网络？三个根本原因。
第一，实时性要求不同。 底盘的ESP和智驾的ADCU需要毫秒级甚至微秒级的实时响应，这个延迟不能因为网络拥塞而有任何波动。
如果把实时控制报文和娱乐视频流混在同一条总线上，视频数据量一大，ESP的控制信号就可能延迟，后果不堪设想。所以必须分开。
第二，电气特性不同。 高速CAN用差分信号、120Ω终端电阻，波特率最高1Mbps；车载以太网用100Base-Tx或1000Base-T1，带宽可以达到百兆甚至千兆；LIN是主从式单线通信，波特率只有20Kbps。
三种网络物理层完全不同，电压域、信号标准都不一样，不能直接互联。
第三，安全等级不同。 动力总成和底盘域的信号直接影响行车安全，不能被任意节点访问。娱乐系统连着外部互联网，有被攻击的风险。
如果娱乐以太网和底盘网络直接互通，娱乐域的漏洞就可能波及行车安全。
基于这三点，车内必须有某种设备来桥接这些隔离的网络，这就是网关存在的根本原因。
图1：典型乘用车通信网络拓扑，中央网关连接所有域控制器和子网络
二、网关的五大核心职责
理解了为什么需要网关，接下来看网关具体干什么。车载网关的工作可以拆解为五大职责，每一项都有明确的技术含义。
1. 协议转换
这是网关最核心的功能，也是最复杂的一个。
不同网络之间传递数据，绝不是简单的"把CAN帧复制到以太网上"这么简单。CAN报文是面向信号的，8字节的数据载荷里包含了若干个定义好的信号，每个信号的起始位、长度、分辨率、偏移量都在DBC文件里规定好了。
以太网传输的是基于服务的IP数据包，数据的封装方式和CAN完全不同。
协议转换要做的事情，可以分为三个层次：
第一层：帧格式转换。 CAN帧只有8字节，ID范围是11位标准帧或29位扩展帧；以太网帧可以承载最多1500字节的数据（标准以太网），车载以太网通过TSN扩展可以传输更大的数据包。网关首先要处理的是帧长度的适配问题——CAN的8字节数据放到以太网帧里，需要重新定义数据边界。
第二层：信号解析与重组。 CAN帧里的信号含义由DBC文件定义，比如字节0是SOC高字节、字节1是SOC低字节，组合起来才是真实的SOC值。以太网服务的数据格式由ARXML或SOME/IP IDL文件定义。网关在转发时需要知道这个信号"是什么意思"，不能只做原始字节的复制。
第三层：语义映射。 这是SOA架构下网关的新能力。CAN的信号是"发布-订阅"式的，一个信号发出来，所有节点都能收到。以太网的SOME/IP是"请求-响应"式的，需要明确哪个客户端调用哪个服务。网关如果要做智能路由，就必须理解两侧的语义，把CAN的信号发布转换为服务调用，或者把服务请求转换为CAN信号的发送。
// 示例：电池SOC信号从CAN到以太网的转换
//
// CAN帧原始数据（DBC定义）
CanId: 0x100
Byte[0]: SOC_H (高8位，分辨率0.4%/bit，偏移量0)
Byte[1]: SOC_L (低8位)
Byte[2]: Temp_H (温度高字节，-40°C偏移，1°C/bit)
// ... 其他信号
// 网关处理过程：
// 1. 解析CAN帧 → 提取SOC值
soc = ((SOC_H << 8) | SOC_L) * 0.4; // 单位：%
temp = Temp_H - 40; // 单位：°C
// 2. 封装为SOME/IP服务（ARXML定义）
ServiceID: 0x1234
MethodID: 0x01 // GetBatteryStatus
Payload: {
battery_soc: 75.2, // float32
temperature: 28.0, // float32
timestamp: 1700000 // uint32，毫秒级时间戳
}
// 3. 通过以太网发送到IVI（目标IP: 192.168.1.50）
Ethernet_Transmit(service_msg);
|
反过来，当以太网上收到一个服务请求，要把结果回写到CAN网络上时，网关要做的是：从以太网服务响应中提取数据字段，按照DBC定义重新打包为CAN帧，发送到目标CAN总线上。这个过程叫"服务到信号的反向映射"。
2. 跨域报文路由与过滤
网关不是把所有报文都转发出去，而是根据路由表决定哪些报文转发、转发到哪里、什么时候转发。路由规则是OEM在整车通讯矩阵中定义的，通常包含以下几种类型：
- 透明转发（Pass-through） ：A网的某个报文原封不动地复制到B网。典型场景是法规要求的OBD诊断报文——外部诊断仪连接OBD端口，网关必须把诊断请求透传到相关网络，并把响应透传回来。
- 信号提取转发（Signal Extraction） ：从CAN帧里提取一个或多个信号，重新打包后发送到以太网。这种路由是"多对一"的，多个CAN信号被提取后组合成一个新的服务消息。
- 服务映射（Service Mapping） ：在SOA架构下，把CAN信号映射为SOME/IP服务（Signal-to-Service），或者把服务调用反向映射为CAN信号发送。这种路由是双向的。
- 条件过滤转发（Conditional Routing） ：只有满足特定条件时才转发。比如车速大于30km/h时才允许把某个信号转发到娱乐域显示；或者只有动力电池处于充电状态时才把充电相关信息发送到T-Box上传云端。
路由表是静态配置的，在项目开发阶段由OEM的通讯工程师定义，网关供应商根据通讯矩阵配置路由表。路由表配置错误会导致信号传不到、信号传错、或者信号延迟。
3. 网络隔离与安全防护
网关的第三个核心职责是"保镖"——保护关键安全网络不被其他网络的流量和故障所影响。
具体来说有三个层面。
带宽隔离（Bandwidth Isolation）。 娱乐以太网连着4G/5G模块，用户可以在车里刷视频、听在线音乐。如果娱乐流量和智驾控制流量共享同一条以太网骨干网络，高峰时段娱乐流量可能把带宽占满，智驾的控制指令就可能被延迟或丢包。
网关需要实现QoS（服务质量）策略，确保关键报文的传输时延和带宽优先级。简单来说就是：智驾的报文永远先走，娱乐的报文排队等着。
故障隔离（Fault Isolation）。 CAN网络有个特点：某个节点硬件故障（比如CAN_H和CAN_L短路）会导致整条总线 Bus Off，所有节点都无法通信。
如果底盘CAN发生了Bus Off，网关必须把这个故障隔离在底盘域内部，不能让它影响动力CAN和智驾以太网。中央网关通常会为每个连接的网络通道实现独立的收发器控制，任何一个通道的故障不会传染到其他通道。
访问控制（Access Control）。 某些控制指令有安全等级要求。比如安全气囊的展开信号、安全带提醒的强制静音指令，只能由特定域发出，不能被随意伪造。网关需要实现信号级的访问控制验证——在转发报文之前，检查发送者的身份和权限。
如果一个来自娱乐域的以太网请求试图伪造底盘域的安全控制指令，网关应该直接丢弃这条报文。
此外，在智能网联时代，网关还需要承担一部分车载防火墙的功能：对外部通信（T-Box、OBD远程诊断）进行入站过滤，防止恶意攻击通过车联网入口渗透到车内关键网络。这部分功能在ISO/SAE 21434（汽车网络安全）标准中有明确要求。
4. 网络管理与时间同步
网关还深度参与整车的网络唤醒和休眠管理。
当驾驶员解锁车辆或按下启动按钮时，网关是第一个收到唤醒信号的节点。网关被唤醒后，会按照预定义的唤醒序列，依次唤醒各个域控制器：先唤醒动力域（发动机启动需要最快的响应），再唤醒底盘域，最后唤醒娱乐域。
整个唤醒时序由网关统一协调，确保各域控制器在正确的时间进入工作状态。
反过来，当车辆熄火、驾驶员离开后，网关需要协调各域的有序休眠。休眠的顺序同样重要——如果车身域先休眠了，锁车信号就无法被接收；如果智驾域还没休眠完就被切断电源，可能会丢失未保存的标定数据。
// 网关唤醒序列（简化）
WakeUp_Sequence():
1. Gateway收到KL15唤醒信号
2. 网关初始化各通信通道（CAN/Ethernet/LIN）
3. 唤醒动力域CAN（发送网络管理报文）
4. 等待动力域确认唤醒 → 唤醒底盘域CAN
5. 等待底盘域确认唤醒 → 唤醒车身域
6. 等待车身域确认唤醒 → 唤醒智驾以太网
7. 等待智驾域确认 → 唤醒娱乐以太网
8. 所有域就绪 → 网关进入正常工作状态
Sleep_Sequence():
1. 网关收到KL15关闭信号
2. 按逆序发送休眠请求：娱乐域 → 智驾域 → 车身域 → 底盘域 → 动力域
3. 等待各域确认休眠（超时保护：500ms）
4. 所有域休眠后，网关进入深度休眠（保留LIN唤醒能力）
|
时间同步是另一个关键职责。在智能驾驶场景中，多个传感器（摄像头、毫米波雷达、激光雷达）需要在精确的时间同步下工作。
如果摄像头在T=100ms时刻检测到一个障碍物，雷达在T=100ms+5ms才检测到同一个障碍物，控制模块收到两个有时间差的数据，决策就可能出错。
网关通常兼任时间网关（Time Gateway）的角色。它从T-Box或仪表获取GNSS时间基准（或者从以太网获取PTP时间），然后将时间同步消息分发到各个子网络。
在CAN总线上，通过CanTSyn模块发送SYNC和FUP报文；在以太网上，通过gPTP（IEEE 802.1AS）进行时间同步。网关在两个网络之间做时间的桥接——从以太网接收时间基准，转换成CAN的时间格式，再分发给CAN网络上的各ECU。
5. 诊断与OTA的桥梁
很多人不知道的是，网关还是整车诊断和OTA升级的重要通道。
当4S店或维修站用诊断仪连接OBD接口时，诊断请求通过OBD端口进入网关，网关再把这个请求转发到对应的目标网络。
比如读取BMS的故障码，网关就把请求转发到动力CAN；读取车灯模块状态，就转发到车身CAN。诊断响应也是同样的路径返回。
在OTA场景下，T-Box接收云端推送的软件更新包，通过以太网发送到中央网关，网关再将更新包分发到目标ECU。这个过程需要网关对数据做完整性校验、版本确认、增量分发等处理。几百MB的更新包如果全部走CAN传输是不现实的，以太网网关就是OTA高速通道的入口。
三、网关的硬件形态：从独立盒子到中央计算平台
网关在车上的物理形态经历了三个阶段的演变，反映了整车电子电气架构的演进。
第一阶段：独立网关控制器。 早年的车联网架构比较简单，网关是一个单独的ECU，安装在仪表台下方或者前舱内，物理上是一个黑色的金属盒子，通过高速CAN、LIN、以太网接口与其他网络相连。
这种形态的网关功能单一，配置固定，主要做报文转发，更新困难，通常需要到4S店用专用工具才能刷新软件。典型产品如博世、大陆的独立网关。
第二阶段：集成进域控制器。 随着域控制器架构的兴起，网关功能逐渐被整合进车身域控制器或者中央计算平台。现在的车身域控制器往往集成了网关功能，可以同时处理CAN路由、以太网交换、LIN主从通信。
这种形态降低了ECU数量和整车线束成本，但软件复杂度大幅上升——网关软件需要和其他域应用共存，对实时性和安全性的要求更高。典型产品如NXP S32G系列、Renesas RH850/F1KH系列。
第三阶段：软件定义的服务网关。 在中央计算平台架构下，网关不再是一个固定的硬件产品，而是一组软件服务，运行在高性能的计算平台上。
请求路由到哪里、服务如何编排、数据如何分发，全部由软件决定。这种形态给OTA更新带来了极大便利——网关的路由逻辑可以像手机APP一样随时更新，新增一条路由规则不需要更换硬件。
图3：网关从独立硬件到软件定义平台的演进路径
四、AUTOSAR架构下的网关实现
在AUTOSAR体系里，网关功能主要通过三个基础软件模块的协作来实现。
PduR（PDU Router） 是网关的核心路由引擎。它负责接收来自任意通信接口的PDU，根据预配置的路由表，决定这个PDU应该转发到哪个下层接口。CAN收到报文就转发到以太网，或者以太网收到SOME/IP请求就转发到CAN——这个路由决策由PduR完成。路由表在配置阶段静态定义，网关ECU上电后，PduR模块按照路由表执行转发逻辑。
PduR支持两种路由模式： I-PDU网关 （Interface层网关）和 I-PDU TP网关 （传输协议层网关）。前者用于长度不超过8字节的报文直接转发，后者用于需要分片重组的长报文（比如诊断的非标准会话，需要通过TP层拆成多帧CAN帧发送）。
CanIf / EthIf / LinIf 负责和底层硬件接口打交道。CanIf把PDU转换成CAN帧格式，或者把收到的CAN帧还原为PDU；EthIf处理以太网帧和TCP/UDP数据包的封装与解析。这些接口层模块对PduR屏蔽了底层的硬件差异，让PduR可以用统一的PDU格式做路由决策。
ComM 负责协调网关各通信通道的网络状态。当某个通道需要唤醒或休眠时，ComM协调相关通道同步进入对应状态。在配置了Partial Network（局部网络）的情况下，ComM还会根据PNC（Partial Network Cluster）的状态决定通道是否需要保持唤醒。
// AUTOSAR架构下，网关转发CAN1报文到CAN2的完整流程
// ===== 接收阶段 =====
// 1. CanDriver收到CAN1上的物理帧，产生中断
Can_Isr_Rx(CAN1_HwHandle);
// 2. CanIf将硬件帧封装为I-PDU，调用PduR的上层接口
CanIf_RxIndication(CanIfRxPduId = PDU_ID_CAN1_BMS, PduInfoPtr);
// 3. PduR查询路由表，发现这条PDU需要转发到CAN2
// 路由表配置：PDU_ID_CAN1_BMS → PDU_ID_CAN2_BMS_display
PduR_RxIndication(PduRPduId = PDU_ID_CAN1_BMS, PduInfoPtr);
// ===== 转发阶段 =====
// 4. PduR调用CanIf的下层接口发送
PduR_CanIfRoutingPath[DestPduId].PduRPathTransmit =
CanIf_Transmit(CanIfTxPduId = PDU_ID_CAN2_BMS_display, PduInfo);
// 5. CanIf将PDU转换为硬件帧格式
CanIf_Transmit(TxPduId, PduInfoPtr);
// 6. CanDriver将帧发送到CAN2总线
Can_Write(CanHth = CAN2_TX_HTH, PduInfoPtr);
// ===== 确认阶段 =====
// 7. CAN2发送成功后，逐层上报确认
Can_TxConfirmation(CAN2_Hth);
CanIf_TxConfirmation(PDU_ID_CAN2_BMS_display);
PduR_TxConfirmation(PDU_ID_CAN1_BMS); // 通知源PDU已转发完成
Com_TxConfirmation(PDU_ID_CAN2_BMS_display); // 通知上层COM
|
这段代码流程说明了AUTOSAR网关的工作原理： 每一条路由路径在PduR里都是静态配置的 ，路径的两端分别是源接口（CAN1）和目标接口（CAN2）。PduR不产生数据，只做数据的搬运工——从哪个口进、走哪条路由、到哪个口出，全部由配置决定。
结尾
总结一下。车载网关不是"多接几根线的转接头"，它是整车通信网络的枢纽，承担着五大核心职责：协议转换、跨域路由、安全隔离、网络管理，以及诊断和OTA的通道。
理解网关的关键，是理解它在整个架构中的位置——它处于所有网络的交叉点，是数据流通的必经之路。
正是因为这个位置特殊，网关的配置质量和运行状态直接影响整车的通信可靠性。一个路由表配置错了，可能导致某个功能完全失效；网关软件宕机了，可能导致多个域同时失联。
随着电子电气架构从分布式走向域集中、再走向中央计算平台，网关的角色也在不断进化：从早期的独立报文转发器，到域控制器里的集成路由模块，再到未来SOA架构下的服务编排节点。
技术形态变了，但"连接不同网络、保证通信可靠"的核心定位始终没变。
理解网关，其实就是理解整车的通信架构。网关搞清楚了，其他ECU之间的通信问题就容易排查了。
| 
订阅
