简述

很多人第一次看 AUTOSAR PduR，都会有一个很自然的疑问：

这东西是不是有点重？

尤其是看完配置代码之后，会更容易产生这种感觉。

因为 PduR 看起来做的事情很简单：

源 PDU ID -> 目标 PDU ID -> 调用目标模块

那我自己维护一张映射表不就行了吗？

对于一些简单 ECU，比如车窗控制器、座椅控制器、灯控节点，通信关系可能非常固定：

COM  <-> LinIfDCM  <-> LinTpLinTp <-> DCM

如果唯一变化点只是不同项目、不同车型之间的 PDU 映射关系，那么完整引入 PduR 是否真的有必要？

这个问题不能简单回答“有”或者“没有”。

更准确的结论是：

PduR 不是一张映射表，但它依赖映射表。对复杂 ECU 或网关节点，PduR 的价值很强。对非网关、路径固定、变体只体现在映射关系上的简单 ECU，PduR 的运行时价值会明显变弱。此时它更多体现为 AUTOSAR 标准接口、工具链和模块边界的价值。

这篇文章就从源码角度聊一下这个边界。

先说结论：PduR 不是为了“查表”而存在

如果只看路由配置，PduR 确实很像一组表。

抽象一下，大概是这样：

typedefstruct{    PduIdType destPduId;    Std_ReturnType (*transmit)(PduIdType id,                               const PduInfoType *info);} RouteType;static const RouteType RouteTable[] = {    { DEST_PDU_0, Target_Transmit0 },    { DEST_PDU_1, Target_Transmit1 }};static const PduIdType MapTable[] = {    0,    1};

如果事情到这里就结束，那确实没必要搞一个完整 PduR。

自己写：

return RouteTable[MapTable[id]].transmit(           RouteTable[MapTable[id]].destPduId,           info);

也能工作。

但源码里的 PduR 并不只做这一步。

它真正处理的是：

哪个模块调用进来当前状态是否合法PDU ID 是否有效目标模块是谁目标 PDU ID 是多少目标函数是否存在发送结果如何返回接收通知如何上报TP 数据如何分段交互取消发送如何传递

所以，PduR 的核心不是“查表”，而是：

统一维护通信模块之间的调用关系。

从源码看，PduR 至少做了三层事情

第一层：接口包装

上层模块不会直接调用 CanTp、LinTp、CanIf 或 LinIf，而是先调用 PduR。

抽象后的接口类似：

Std_ReturnType PduR_DcmTransmit(PduIdType id,                                const PduInfoType *ptr){    return PduR_rDcmTransmit(id, ptr);}

这一层代码很薄，但它有意义。

它让 DCM 看到的是：

我要通过 PduR 发一个诊断 PDU

而不是：

我要判断这次走 CanTp、LinTp，还是别的传输模块

第二层：路由选择

真正的路由逻辑通常在内部函数里。

抽象成代码，大概是：

Std_ReturnType PduR_dDcmTransmit(PduIdType id,                                 const PduInfoType *ptr){    CHECK_PDUR_STATE(E_NOT_OK);    CHECK_POINTER(ptr, E_NOT_OK);    if (id_is_invalid(id) ||        map_is_invalid(id) ||        route_function_is_null(id))    {        report_invalid_pdu();        return E_NOT_OK;    }    return get_transmit_function(id)(               get_destination_pdu_id(id),               ptr);}

这里已经比普通映射多了几件事：

• • 状态检查；
• • 指针检查；
• • ID 范围检查；
• • 路由有效性检查；
• • 目标函数有效性检查；
• • 目标模块调用；
• • 错误路径处理。

这部分逻辑如果不用 PduR，也不是消失了，只是会被你挪到别的地方。

第三层：完整通信闭环

最容易被低估的是这一层。

通信不是只有 Transmit()。

对于 IF 层，至少有：

TransmitRxIndicationTxConfirmation

对于 TP 层，还会有：

StartOfReceptionCopyRxDataCopyTxDataRxIndicationTxConfirmationCancelTransmit

也就是说，PduR 管的不是一个函数调用，而是一组双向关系：

发送请求：上层 -> PduR -> 下层接收通知：下层 -> PduR -> 上层发送确认：下层 -> PduR -> 上层TP 数据：传输协议 <-> PduR <-> 上层模块

如果只是写一张发送映射表，只解决了最简单的一段。

后面的确认、接收、TP 缓冲、取消发送，仍然要有人维护。

那为什么简单 ECU 会觉得 PduR 很弱？

因为这个感觉是合理的。

以一个车窗控制器为例，它可能只有 LIN 通信，通信关系也比较稳定：

COM  <-> LinIfDCM  <-> LinTp

它不是网关节点，不需要做：

CAN -> LINLIN -> CANCAN1 -> CAN2

也没有复杂的多目标路由。

如果这个 ECU 的变体点只有：

哪个 COM PDU 对应哪个 LIN PDU哪个 DCM PDU 对应哪个 LinTp PDU哪个 LinTp PDU 对应哪个 DCM PDU

那确实可以把变化集中到映射表里。

甚至可以在代码生成阶段直接生成静态绑定：

Std_ReturnType Window_ComTransmit(const PduInfoType *info){    return LinIf_Transmit(WINDOW_LIN_TX_PDU_ID, info);}Std_ReturnType Window_DcmTransmit(const PduInfoType *info){    return LinTp_Transmit(WINDOW_LINTP_TX_PDU_ID, info);}

不同车型只换生成出来的 ID：

#define WINDOW_LIN_TX_PDU_ID    ...#define WINDOW_LINTP_TX_PDU_ID  ...

这样做有明显优点：

• • 调用链更短；
• • 代码更直接；
• • 调试更容易；
• • ROM/RAM 更小；
• • 生成配置更轻；
• • 对简单 ECU 更友好。

所以，如果只从运行时能力看，简单非网关 ECU 中的 PduR 确实可能显得偏重。

这里要把话说准确：

简单非网关 ECU 需要“路由关系配置”，但不一定需要“完整 PduR 运行时能力”。

PduR 会不会导致模块膨胀？

会有这个风险。

但要分开看。

源码包膨胀

供应商交付的 PduR 源码通常会包含很多能力：

• • IF 路由；
• • TP 路由；
• • IF Gateway；
• • TP Gateway；
• • Buffer Pool；
• • Multicast；
• • Routing Path Group；
• • Post-build 配置。

这些能力放在源码包里，看起来模块很大。

但源码存在，不代表最终都会进入镜像。

二进制膨胀

最终二进制取决于配置和编译优化。

很多 PduR 实现会对单路由场景做优化，把完整查表退化成静态绑定：

#if defined(PDUR_CONFIG_SINGLE_ROUTE)#define PduR_GetTransmitId(id)      (id)#define PduR_GetTransmitFunc(id)    (SingleTarget_Transmit)#else#define PduR_GetTransmitId(id)      (RouteTable[MapTable[id]].destPduId)#define PduR_GetTransmitFunc(id)    (FunctionTable[RouteTable[MapTable[id]].funcIndex])#endif

这说明 PduR 实现本身也知道：

单一固定路由，不应该承担完整多路由模型的运行时成本。

架构复杂度膨胀

这个成本在简单 ECU 里最明显。

即使最终二进制不大，PduR 仍然会带来：

• • 多一层配置；
• • 多一层生成代码；
• • 多一层初始化；
• • 多一层跳转；
• • 多一层 PDU ID 追踪；
• • 调试时多一层调用栈。

对于资源敏感、通信关系简单的 ECU，这部分成本不能忽略。

那为什么非网关 ECU 里还经常保留 PduR？

因为 PduR 在这里的价值，不完全是运行时路由。

更多是标准化集成。

1. 保持 AUTOSAR 模块边界

AUTOSAR 希望 COM、DCM、CanTp、LinTp、CanIf、LinIf 之间通过标准接口连接。

如果 DCM 直接调用 LinTp，COM 直接调用 LinIf，当然可以跑。

但这就变成项目自定义集成方式。

后续如果要换供应商模块、换配置工具、换通信路径，成本会变高。

2. 让工具链统一生成

PduR 很适合被配置工具生成。

工具只需要描述：

源 PDU  -> 路由路径  -> 目标 PDU  -> 目标模块

无论复杂节点还是简单节点，都可以使用同一套模型。

这对量产项目很重要。

3. 保留扩展余量

一个 ECU 今天可能只是简单 LIN 节点。

但后续项目可能增加：

• • 新诊断链路；
• • 新网络；
• • 新通信用户；
• • 新配置变体；
• • 网关需求。

如果一开始完全绕开 PduR，后续扩展时可能要重新整理模块边界。

4. TP 接口仍然需要闭环

即使不是网关，只要用了 TP，就还有：

StartOfReceptionCopyRxDataCopyTxDataRxIndicationTxConfirmationCancelTransmit

这些接口可以自己静态适配，也可以交给 PduR。

PduR 的好处是，这些接口都在同一套标准模型下。

所以，可以不用 PduR 吗？

可以，但要看前提。

如果是非 AUTOSAR 标准化项目，或者项目允许裁剪标准模块边界，并且 ECU 足够简单，可以直接生成静态映射。

这种做法并不低级。

它可能更小、更快、更容易验证。

但代价是：

• • 标准模块边界变弱；
• • 后续扩展能力变弱；
• • 工具链通用性变弱；
• • 跨项目复用能力变弱；
• • 需要自己维护确认、取消和 TP 回调闭环。

换句话说，不使用 PduR 不是“不用路由”，而是：

自己实现一个更小、更固定的路由层

对于简单 ECU，这可能是合理选择。

对于复杂 ECU，这很容易演变成另一个自定义 PduR。

网关节点和非网关节点，PduR 的价值不一样

这个区分很关键。

对于网关节点或复杂 ECU：

PduR = 配置化路由 + 运行时路由服务

它要处理多模块、多网络、多路由、多目标、网关缓冲、TP 回调和路由控制。

这时 PduR 是通信架构里的核心模块。

对于简单非网关 ECU：

PduR 可以退化为：PDU 映射配置 + 很薄的接口适配层

它不一定承担复杂路由，只是保持 AUTOSAR 模块边界和工具链一致性。

如果唯一变体就是映射表，那么静态生成映射关系，确实可能比完整 PduR 更轻。

所以不能简单说：

没有 PduR 就一定难以维护

也不能简单说：

PduR 只是多余的一层

正确的问题应该是：

这个 ECU 的通信复杂度，是否值得引入完整 PduR？

最后的工程判断

PduR 的价值要分场景看。

如果是复杂 ECU、网关节点、多网络节点，PduR 很有价值。它把通信关系、PDU ID、函数调用、确认回调、TP 过程和网关能力收敛到统一模型里。

如果是车窗控制器这类简单非网关 ECU，通信路径固定，唯一变化点只是 PDU 映射表，那么完整 PduR 的运行时价值确实会变弱。

这种情况下，更务实的选择可能是：

保留配置化映射裁剪运行时复杂度生成静态绑定代码只保留必要的薄适配层

最终结论：

PduR 不是映射表，但它依赖映射表。PduR 不是每个 ECU 都强依赖的运行时模块，但它是 AUTOSAR 标准通信栈的重要集成边界。对复杂 ECU，PduR 是通信架构的核心；对简单非网关 ECU，PduR 可以被裁剪成薄适配层，甚至在非标准化项目中被静态映射替代。

工程上不要迷信模块，也不要为了省一层调用就破坏边界。

真正应该判断的是：

这个 ECU 是需要完整路由能力，还是只需要一份稳定的映射关系？

这个问题想清楚了，PduR 应该保留、裁剪，还是替代，就比较清楚了。

本文参考的源码文件

• • PduR/PduR_PBcfg.c
• • PduR/PduR_Cfg_Internal.h
• • PduR/PduR_UpTp.c
• • PduR/PduR_dUpTp.c
• • PduR/PduR_LoTp.c
• • PduR/PduR_dLoTp.c
• • PduR/PduR_dLoIf.c