CAN XL和10BASE-T1S的网关性能

在上一篇文章中，我们对 10MBit/s 汽车协议 CAN XL 和 10BASE-T1S 做了一些解释。现在我们将关注潜在的用例以及对硬件和软件的影响。

一、10Mbit协议应用实例

CAN XL 或 10BASE-T1S 可用作现有 CAN FD 或其他网络协议的替代品，其中应用要求超过提供的带宽。还有一些新的用例可以专门使用这些协议。

一个示例是连接麦克风和扬声器以实现主动降噪、道路降噪或 e-Call 应用。对于这些应用，机舱内放置了多个麦克风和扬声器。网络流量处于 CAN FD 无法提供的范围内。随着远离专门为单一应用开发的通信协议的趋势，OEM 首选更通用的协议，例如 CAN XL 和汽车以太网。图像

图 1：音频示例

以类似的方式，低带宽要求的传感器使用现有协议连接，形成按区域或域组织的子网络。这些子网络通常通过网关连接到剩余的车载网络 （IVN），该车载网络通常使用 100MBit/s 或更高范围内的以太网连接（图 2）。

如今，需要将 CAN 消息从一个通道传输到另一个通道的网关 ECU 已经是一个复杂的组件。添加提供更多带宽和更长有效载荷的协议将进一步增加复杂性，并且在使用与今天相同的硬件和软件策略时需要明显更高的处理性能。

网关 ECU 应该只转发消息或 PDU，但不处理数据内容。在实践中，网关 ECU 修改数据并具有条件转发规则。未来将避免对网关模块的这些扩展，以遵循基于消息的通信概念或面向服务的体系结构 （SOA） 的方法。下面我们将基于纯消息转发网关进行讨论。图像

图 2：网络层次结构

2. 10MBit 协议的以太网网关功能

分析网关模块的作用是将消息从一种协议传输到另一种协议，而不改变消息的内容。

有两个因素会影响执行网关操作所需的 CPU 资源。首先，产生需要处理的净数据速率的有效载荷长度。第二，触发网关进程的事件率。仅查看总线利用率（总线负载）是不够的，因为它是总线上的活动和事件率的组合。假设网关 ECU 需要将任何给定协议上游传输到以太网接口，则需要三个基本步骤，对这两个因素具有不同的依赖性：

步骤1：将消息从接收接口传输到内存中。CPU 资源利用率取决于在一个时间间隔内要传输的数据量，与总线上有很多短帧还是少数长帧无关。然而，净数据速率决定了这项任务。

步骤 2：构造目标以太网消息。如果源协议已经是以太网消息（例如，10BASE-T1S），简单的交换功能就足够了。如果源协议不是以太网，则依赖于协议的入口报头必须由以太网报头替换。如果例如使用具有较低有效载荷长度的协议并且在将传输协议提供给上游接口之前应将其删除，则此任务可能非常复杂。CPU 负载取决于处理的有效负载大小以及事件率。

步骤 3：使构建的以太网消息可用于目标接口并启动传输。假设以太网接口对内存中的指针进行操作，传输的事件率决定了所需的 CPU 负载。

图 3：网关运行性能

图 3 显示了一个简单的 CAN FD、CAN XL 和 10BASE-T1S 到以太网网关的超过 1 秒的累积 CPU 处理时间，用于 50% 的总线负载和 256 字节的有效负载。

从所需的处理时间来看，10BASE-T1S 似乎需要比 CAN XL 更多的 CPU 时间来处理总线上的流量。事实上，每个有效负载需要相同数量的处理时间。从网络数据速率我们可以看出，10BASE-T1S 比 CAN XL 高 30% 左右。10BASE-T1S 的处理时间在同一地区与 CAN XL 不同。在查看处理时间相对较短但净数据速率非常低的 CAN FD 时，必须考虑同样的因素。

从今天的网关应用和 ECU 设计可以明显看出，在当前的事件和数据速率下，延迟要求很难满足。随着协议提供更多带宽，实现目标将更加困难。假设连接了多个 CAN 和以太网通道，在相同总线负载的情况下，处理时间比现在高 3 到 4 倍。需要开发解决方案来克服这种情况。

3. 软硬件网关优化

查看图表，已经显示了最明显的解决方案；消除将数据从 CPU 移动到内存的负担。这不是典型的 CAN 方法。传统上，CAN 使用本地 IP 存储器作为本地发送和接收缓冲区。这对于经典 CAN 来说是可以接受的，对于 CAN FD 来说是可以接受的。随着有效载荷数量的增加和更高的数据速率，这种方法将会改变。CAN 的几种实现方式已经允许通过需要编程和配置的系统 DMA 进行数据传输。这种方法很少使用，因为 DMA 很难在 Autosar 环境中使用。将来，DMA 功能将成为 IP 的一部分，对软件完全透明。接收到的数据“出现”在定义的系统内存中的 FIFO 和缓冲区中，并且可以直接访问；传输数据相同。这一概念已经用于瑞萨的以太网接口，并将扩展到 CAN XL 协议控制器。这种简单增强的效果如图 5 所示。

路由过程中需要注意的第二个过程是传入 CAN XL/10BASE-T1S 消息和传出 100BASE-T1 消息之间的缓冲区处理和信息交换过程。

一个典型的、面向层的实现将提供两个进程（图 4 左侧），其中传入进程从其接收缓冲池中保留一个缓冲区，并在缓冲区填满后通知传出消息进程有关待传输的未决消息。由于独立的结构和处理，接收到的消息需要转移到新分配的缓冲区中进行进一步处理。为了构造传出消息，必须准备一个新的传输头，并且需要在头之后将接收缓冲区中的数据复制到新缓冲区。在这个复制操作之后，原始缓冲区可以被传入消息进程释放。传输完成后，分配的传输缓冲区将被释放回用于传出消息的池中。

这种方法有两个主要缺点。首先，即使在像这里这样的情况下，当在继续之前没有依赖或等待条件时，也必须尽量减少进程间通信。其次，指针操作应该优先于数据复制操作。

图 4：框架组装流程

图 4 的右侧以简化的过程显示为复杂的设备驱动程序，其中传入和传出通信接口共享一个公共缓冲区池。这消除了双重分配和释放缓冲区以及进程间通信的需要。Renesas 的以太网通信接口中的扩展指针操作支持允许灵活地创建以太网消息而无需任何复制操作，并支持使用报头模板。这种结构还允许聚合来自传入接口的消息，排列它们，并轻松创建以太网消息，例如遵循 IEEEE 1722 隧道协议。

图 5 显示了优化硬件和软件时对 CPU 利用率的影响。瑞萨电子准备了一个演示集，其中 CAN XL 和 10BASE T1S 被传输到 100BASE-T1 以太网骨干网。为了简化和比较的公平性，CAN XL 的有效负载已经包含一个 IPv4 标头。因此，CAN XL 的网关功能在添加以太网 L2 报头时减少。对于 10BASE-T1S，只实现了软件开关的功能。

在图的最左侧，我们看到没有任何优化的 CPU 处理时间。

在中间部分，DMA传输用于将数据从通信接口传输到系统内存。新消息的创建仍然是通过复制操作和动态标头创建来完成的。

在图的右侧，我们使用优化的软件流程，使用一个复杂的驱动程序，该驱动程序使用一个公共缓冲池和用于标头模板和有效负载数据的指针操作。

图 5：优化效果

4 结论

10MBit 通信协议会给网关 CPU 带来额外的负载。通过巧妙的软件方法和硬件特性，所需的 CPU 性能不会随着带宽和净数据速率的增加而增加。

Renesas 的以太网通信接口提供自动数据传输并支持指针操作，以便在系统内存中进行复杂的消息组合。下一代 CAN XL 接口将朝着相同的方向发展。

10BASE-T1S 和 CAN XL 都将拥有它们主导的应用领域。它们由值得信赖的标准化机构开发，并在提供产品和解决方案的行业中拥有包括瑞萨在内的支持者。

审核编辑：郭婷