一、AUTOSAR网关概述

1.1 网关在车载网络中的角色

说到网关，我先问大家一个问题：一辆现代汽车里有多少个ECU？

我做过的一个项目，光是车身域就有30多个ECU。这些ECU分布在不同的网络上——有的跑CAN，有的跑LIN，还有的跑FlexRay甚至以太网。它们之间怎么通信？

答案就是网关。

网关的核心角色，说白了就是「翻译官」和「交通警察」。

• 协议转换：把CAN上的报文转成以太网能识别的格式
• 路由转发：决定哪个报文该去哪条总线
• 信号映射：把A节点的车速信号映射给B节点用
• 网络隔离：不让一条总线的故障扩散到另一条

我记得有一次，客户抱怨说空调控制偶尔失灵。查了半天，发现是CAN总线上的一个错误帧把网关堵死了，导致空调的报文一直没转发过去。这就是网关隔离没做好的典型问题。

1.2 AUTOSAR网关与传统网关的区别

传统网关怎么做？

我早年做的一个项目，网关就是一颗MCU，跑着裸机代码。收到CAN报文，查一个静态路由表，然后转发出去。简单粗暴，但问题很多：

• 路由表写死在代码里，改一次要重新刷写
• 不支持动态配置，扩展性差
• 没有标准化的诊断接口
• 不同供应商的网关，代码风格千奇百怪

AUTOSAR网关就不一样了。

它把网关功能抽象成了标准化的模块。你想想看，不管底层是CAN还是以太网，上层都用同样的接口去配置路由。这就是AUTOSAR的厉害之处。

对比项	传统网关	AUTOSAR网关
路由配置	硬编码，改一次刷一次	通过ARXML配置，可动态调整
协议支持	通常只支持CAN/LIN	CAN、LIN、FlexRay、以太网全支持
诊断能力	需要自己实现	标准化的DCM模块
可扩展性	差，加一个新功能要动底层	好，模块化设计，加功能加配置就行
安全性	基本没有	支持SecOC、加密通信

我个人习惯，在评估一个网关方案时，先看它是不是基于AUTOSAR架构。如果是，后续的维护成本会低很多。

1.3 网关路由策略的分类

路由策略，说白了就是「报文该怎么走」的规则。AUTOSAR网关支持三种路由策略：

1.3.1 报文路由（PDU Routing）

这是最基础的路由方式。一个CAN报文从总线A进来，网关直接把它转发到总线B上去。

嗯，这里要注意：报文路由是「透传」的，网关不修改报文内容。它只负责查路由表，决定这个PDU该去哪个目标总线。

我曾经遇到过一个坑：客户要求把CAN报文路由到以太网。我一开始想当然地以为直接转发就行，结果发现CAN和以太网的PDU格式完全不同。后来才意识到，报文路由只适用于同种总线之间。

1.3.2 信号路由（Signal Routing）

信号路由就灵活多了。网关可以把一个报文里的某个信号提取出来，放到另一个报文里。

举个例子：

• CAN总线上有个报文ID=0x100，包含车速信号
• 以太网上有个SOME/IP报文，也需要车速信号
• 网关把车速信号从CAN报文里拆出来，塞进以太网报文里

这就是信号路由的典型场景。我建议大家在设计信号路由时，一定要注意信号的周期和时效性。车速信号是10ms更新一次，你路由到以太网上变成100ms更新一次，那下游节点拿到的数据就不准了。

1.3.3 诊断路由（Diagnostic Routing）

诊断路由是专门给UDS诊断用的。诊断仪通过网关访问不同总线上的ECU。

诊断路由有个特点：它需要支持「物理寻址」和「功能寻址」两种模式。

• 物理寻址：诊断仪指定要访问哪个ECU，网关只转发给那个ECU
• 功能寻址：诊断仪发一个广播，所有相关ECU都要响应

我记得有一次，客户说诊断刷写总是超时。查了半天，发现是网关的功能寻址配置错了，导致广播报文只转发给了一个ECU，其他ECU根本没收到。这就是配置细节没注意的后果。

知识体系总览

下面这张图，是我自己总结的AUTOSAR网关路由策略的知识体系。你可以把它当作本章的「地图」：

这张图把三种路由策略的关系和子项都列出来了。报文路由最简单，信号路由最灵活，诊断路由最特殊。实际项目中，这三种策略经常组合使用。

比如我做过的一个网关项目：

• 动力总成CAN上的车速信号，用信号路由转发到以太网
• 车身CAN上的门窗控制报文，用报文路由转发到LIN总线
• 诊断仪通过诊断路由访问所有ECU

三种策略各司其职，配合得刚刚好。

---