CAN↔CAN / CAN↔ETH转发到底怎么做？为什么说PduR是“所有通信流量的十字路口”？

前言

在学习AUTOSAR通信栈的时候，很多工程师都有一个共同感受：

COM懂一点 CanIf懂一点 CanDrv也懂一点 唯独PduR看了半天不知道在干什么

打开配置工具：

PduRRoutingPath PduRSrcPdu PduRDestPdu PduRBuffer PduRQueueDepth

一大堆配置项。

但是调试的时候：

收不到信号 看PduR 网关不转发 看PduR CAN转ETH失败 看PduR 诊断不通 还是看PduR

于是很多人发现：

AUTOSAR里最不起眼的模块，却经常是问题根源。

今天我们就彻底讲透：

PduR为什么被称为AUTOSAR通信系统里的“中央交换机”。

PduR出现之前，通信模块是怎么连接的？

假设没有PduR。

发送流程：

COM ├──CanIf ├──LinIf ├──FrIf ├──SoAd ├──DoIP └──CanTp

那么：

每增加一个通信模块，

所有模块都要彼此连接。

例如：

COM -> CanIf COM -> SoAd CanTp -> CanIf CanTp -> SoAd DoIP -> SoAd DoIP -> CanIf

模块数量一多：

连接关系指数增长。

这时候AUTOSAR提出一个思路：

所有数据都先进入一个统一的路由中心。

于是：

PduR诞生了。

• PDU到底是什么？

很多新人一上来就会问：

Signal PDU Frame 到底什么区别？

先看一个实际例子。

ECU发送：

VehicleSpeed = 120km/h EngineSpeed = 3000rpm Gear = D

COM层会把这些信号打包：

Byte0~1 VehicleSpeed Byte2~3 EngineSpeed Byte4 Gear

形成：

TxVehicleInfoPdu

这个整体：

[78 00 B8 0B 04]

就是：

I-PDU

也就是：

PduR真正处理的对象。

所以：

Signal ≠ PDU PDU ≠ Frame

关系如下：

Signal ↓ COM打包 ↓ I-PDU ↓ CanIf封装 ↓ CAN Frame

• PduR到底在路由什么？

答案很简单：

PduR只路由PDU。

它不认识：

VehicleSpeed DoorStatus RPM

它只认识：

PDU ID

例如：

Com_TxPdu_001

进入PduR后：

查Routing Table：

Com_TxPdu_001 ↓ CanIf_TxPdu_005

然后转发。

所以PduR本质上就是：

PDU Router

而不是：

Signal Router

• PduR内部到底长什么样？

很多人以为PduR很复杂。

实际上内部结构非常简单。

核心只有两部分：

Routing Table Buffer

Routing Table

类似：

Source PDU ↓ Destination PDU

例如：

CAN1_RX_100 ↓ CAN2_TX_100

或者：

CAN1_RX_100 ↓ SOAD_TX_001

这就是所谓：

Routing Path

• CAN→CAN转发到底怎么实现？

这是网关ECU最常见场景。

例如：

动力CAN 车身CAN

之间需要交换数据。

收到报文：

CAN1 ID=0x100

流程：

CAN1 ↓ CanIf ↓ PduR ↓ CanIf ↓ CAN2

注意：

PduR根本不解析内容。

它只是：

memcpy()

然后换个出口发出去。

所以很多Gateway ECU：

每天转发几十万条报文。

CPU占用却很低。

原因就在这里。

• PduR真的只是memcpy吗？

很多时候是。

但不完全是。

因为：

PduR还承担：

路由决策

例如：

CAN1 ↓ PduR ├─CAN2 ├─CAN3 └─ETH

一个输入：

多个输出。

这就是：

Fan-out Routing

例如ADAS域控制器：

摄像头数据 ↓ 发送给 仪表 网关 智驾域

PduR会复制多份PDU。

分别发送。

• CAN→Ethernet为什么必须经过PduR？

这是很多新项目最常见的架构。

例如：

CAN ↓ 域控制器 ↓ Ethernet

流程：

CanIf ↓ PduR ↓ SoAd ↓ TcpIp ↓ EthIf

这里PduR完成：

CAN侧入口 ↓ Ethernet侧出口

映射关系。

注意：

很多人误解：

PduR做协议转换

实际上：

不做。

PduR根本不知道：

CAN TCP UDP SOME/IP

是什么。

它只知道：

PDU A 转给 PDU B

• PduR有没有自己的Buffer？

答案：

有

而且非常重要。

因为：

发送端和接收端速度可能完全不同。

例如：

CAN 500kbps Ethernet 100Mbps

又或者：

CAN数据来了 SoAd暂时忙

怎么办？

这时候：

PduR Buffer登场。

• Immediate Routing与Buffered Routing

AUTOSAR支持两种模式。

Immediate Routing

收到立刻转发。

CAN RX ↓ PduR ↓ CAN TX

延迟最小。

适用于：

底盘控制 动力系统

Buffered Routing

先缓存。

CAN RX ↓ PduR Buffer ↓ Task ↓ 发送

适用于：

CAN→ETH DoIP SOME/IP 诊断

• 为什么PduR配置错误最难发现？

因为：

它不会报错。

例如：

COM发出：

Com_SendSignal()

成功。

CanIf也没报错。

但：

PduR路径没配。

结果：

数据直接消失

你看到的现象：

COM正常 CanIf正常 总线没数据

最后查了两天：

PduR RoutingPath漏配置

• 项目中最常见的5种PduR问题

问题1

RX路径漏配

表现：

CAN收到 SWC读不到

问题2

TX路径漏配

表现：

COM发送 总线无报文

问题3

PDU长度不匹配

表现：

偶发数据错乱

问题4

Buffer配置过小

表现：

高负载丢包

问题5

CAN→ETH路由错误

表现：

SOME/IP收不到数据

• PduR、COM、CanIf到底谁在搬数据？

很多人一直分不清。

其实一句话就够：

所以：

COM负责内容 PduR负责路线 CanIf负责运输 CanDrv负责开车

本期总结

PduR看起来只是一个“转发模块”。

但实际上：

它是AUTOSAR通信栈中最核心的枢纽之一。

无论是：

• CAN→CAN Gateway
• CAN→Ethernet Gateway
• DoIP
• SOME/IP
• UDS诊断

几乎所有跨模块通信都必须经过它。

🚗 一句话总结：

PduR不产生数据，也不解析数据，但它决定数据最终能不能到达目的地。

👉下期预告

《AUTOSAR COM中Signal和GroupSignal本质区别是什么，应该如何使用？》

我们将深入拆解：

• Signal和GroupSignal区别
• UpdateBit到底有什么用
• COM发送模式（周期、事件、混合）
• Signal如何一步步变成CAN报文

看看那些天天使用的Com_SendSignal()背后到底发生了什么。