2. PduR路由表结构：路由表的数据结构、路由路径的静态配置、路由表生成工具与流程

好，咱们今天来聊聊PduR的路由表。这东西说白了，就是整个PduR模块的“交通地图”。你想想看，一个ECU里那么多CAN、LIN、FlexRay通道，报文从哪进、从哪出、要不要缓存、要不要分段，全靠这张表说了算。

我个人习惯，拿到一个新项目，第一件事就是先看路由表。为什么？因为路由表的结构直接决定了你的通信架构是否合理。我在一个项目中遇到过，有人把路由表配得乱七八糟，结果报文绕来绕去，最后丢包丢得莫名其妙。嗯，咱们今天就把这个“地图”彻底讲透。

2.1 路由表的数据结构

PduR的路由表，在代码层面其实就是一个巨大的结构体数组。每个数组元素对应一条路由路径。我带你看看它的核心数据结构长什么样。

/* PduR路由表核心结构体 */
typedef struct {
    PduIdType   sourcePduHandleId;      /* 源PDU的ID */
    PduIdType   destPduHandleId;        /* 目标PDU的ID */
    PduRRouteType routeType;            /* 路由类型：直通、缓存、分段 */
    PduRDestPduType destPduType;        /* 目标PDU类型：本地、网络、网关 */
    uint8       priority;               /* 路由优先级 */
    uint16      maxPacketSize;          /* 最大报文长度 */
    uint32      routingGroupId;         /* 路由组ID，用于多通道 */
} PduRRoutingTableType;

这里有几个关键字段，我得重点说一下：

• sourcePduHandleId：源PDU的ID。说白了就是报文从哪来。这个ID是全局唯一的，不能重复。
• destPduHandleId：目标PDU的ID。报文要去哪。注意，这个ID可以是同一个ECU内的，也可以是跨ECU的。
• routeType：路由类型。这是最核心的字段。我遇到过有人把直通和缓存搞混，结果报文时序全乱了。
• routingGroupId：路由组ID。这个字段在多通道场景下特别重要。比如一个报文要同时发到CAN和LIN，就得靠这个ID来分组。

2.2 路由路径的静态配置

路由路径的配置，是在开发阶段就定死的。说白了，就是你在代码里写死的一张表。为什么是静态的？因为AUTOSAR要求确定性——运行时不能动态修改路由表，否则你没法保证实时性。

我给大家看一个实际项目中的配置示例：

/* 路由路径静态配置示例 */
const PduRRoutingTableType PduRRoutingTable[] = {
    /* 案例1：CAN报文直通路由 */
    {
        .sourcePduHandleId = 0x01,      /* CAN1接收到的报文 */
        .destPduHandleId   = 0x02,      /* 直接转发到CAN2 */
        .routeType         = ROUTE_DIRECT,  /* 直通，不缓存 */
        .destPduType       = DEST_NETWORK,  /* 目标为网络 */
        .priority          = 1,             /* 高优先级 */
        .maxPacketSize     = 64,            /* 最大64字节 */
        .routingGroupId    = 0x00
    },
    /* 案例2：LIN报文缓存路由 */
    {
        .sourcePduHandleId = 0x03,      /* LIN接收到的报文 */
        .destPduHandleId   = 0x04,      /* 转发到CAN */
        .routeType         = ROUTE_BUFFERED, /* 需要缓存 */
        .destPduType       = DEST_GATEWAY,   /* 网关转发 */
        .priority          = 2,             /* 中等优先级 */
        .maxPacketSize     = 8,             /* LIN报文通常8字节 */
        .routingGroupId    = 0x01
    },
    /* 案例3：多通道分段路由 */
    {
        .sourcePduHandleId = 0x05,      /* CAN FD报文 */
        .destPduHandleId   = 0x06,      /* 转发到多个通道 */
        .routeType         = ROUTE_SEGMENTED, /* 需要分段 */
        .destPduType       = DEST_MULTICAST,  /* 多播 */
        .priority          = 3,             /* 低优先级 */
        .maxPacketSize     = 512,           /* CAN FD最大512字节 */
        .routingGroupId    = 0x02
    }
};

这里有几个配置要点：

• 直通路由：适合小报文、高实时性场景。比如CAN的周期报文，直接转发，不缓存，延迟最低。
• 缓存路由：适合不同速率的通道之间转发。比如LIN到CAN，LIN速度慢，CAN速度快，必须缓存一下。
• 分段路由：适合大报文跨通道传输。比如CAN FD报文要转发到普通CAN，必须分段。

2.3 路由表生成工具与流程

手动写路由表？别傻了，那会累死人的。实际项目中，我们用的是AUTOSAR配置工具，比如Vector的DaVinci、EB的tresos、ETAS的ISOLAR。这些工具能帮你自动生成路由表代码。

我给大家画一张流程图，看看路由表是怎么生成的：

这个流程看起来简单，但每个步骤都有坑。我给大家拆解一下：

1. 通信需求分析：这一步是基础。你得搞清楚ECU之间有哪些报文、什么周期、多大长度。我建议用Excel先把通信矩阵列出来，再导入工具。
2. 配置工具导入：工具支持导入DBC（CAN描述文件）、LDF（LIN描述文件）等。注意，导入后一定要检查，工具有时候会解析错。
3. 图形化配置：这是最爽的一步。你可以在工具里拖拽连线，配置路由路径。但要注意，别拖得太随意，每条路径都要有依据。
4. 自动生成代码：工具会生成PduR_PBcfg.c这样的文件。我建议不要手动修改这个文件，否则下次重新生成就覆盖了。
5. 集成与验证：生成代码后，要集成到工程里做测试。我遇到过生成的路由表有重复ID，结果编译报错，排查了半天。

2.4 路由表生成工具对比

市面上主流的AUTOSAR配置工具，各有千秋。我整理了一个表格，方便大家对比：

工具名称	厂商	优点	缺点	适用场景
DaVinci Developer	Vector	图形化界面友好，支持多协议	价格贵，学习曲线陡	大型项目，多ECU协同
EB tresos Studio	Elektrobit	集成度高，代码生成稳定	配置项多，容易遗漏	中大型项目，AUTOSAR 4.x
ISOLAR-A	ETAS	与Simulink集成好	界面稍显老旧	基于模型的开发
SystemDesk	dSPACE	支持虚拟验证	配置流程复杂	前期架构设计

我个人习惯用DaVinci Developer，因为它的图形化界面确实好用。但如果你预算有限，EB tresos也是个不错的选择。嗯，工具只是工具，关键还是你对路由表的理解。

2.5 路由表生成后的检查清单

每次生成路由表后，我都会做一遍检查。这里分享一个我自己的检查清单：

• ID唯一性检查：所有sourcePduHandleId和destPduHandleId不能重复。
• 路由类型匹配：直通路由的源和目标必须在同一速率通道上。
• 最大报文长度：确保maxPacketSize不超过目标通道的MTU。
• 路由组ID：多通道场景下，确保同一组的ID一致。
• 优先级分配：高实时性报文分配高优先级，避免被低优先级报文阻塞。

好了，关于PduR路由表的结构、配置和生成流程，今天就讲到这里。记住，路由表是PduR的“灵魂”，配好了，整个通信系统就稳了。配不好，后面有你头疼的。

---

可可精品资料库