CAN XL和10BASE-T1S的数据线性能

1. 更高、更快、更远、更慢

在我们的日常生活、运动、技术发展中，一切都是为了让事情变得更好、更快或更进一步。很难记住发明比以前慢的东西被称为创新，但这正是汽车以太网所发生的事情。

图 1：以太网和 CAN 规范路线图

第一个 100MBit/s 和 1000MBit/s 版本已成功开发并推向市场，其物理层允许自动协商以简化系统集成。在过去十年末，开发了仅支持 10MBit/s 的汽车以太网版本，其物理层与 100MBit/s 和 1GBit/s 版本不兼容；业绩明显下降。

OEM 要求退回到较旧的拓扑样式和较低的速度，以缩小较低速度等级应用在每个以太网端口成本方面的性能差距。CAN FD 当时支持 2MBit/s，并随着时间的推移提高到 5MBit/s。CAN 周围的社区也看到了对更高带宽和更长有效载荷的需求，并开始开发一种改进的 CAN 标准，称为 CAN XL。

在第一部分中，我们将简要概述 CAN XL 和 10MBit/s 以太网，它们之间有什么区别。在第二部分中，我们描述了潜在的用例以及对硬件和软件的影响。

2. 10MBit汽车协议

甚至 CAN XL 和 10BASE-T1S 也是在不同的标准化机构中开发的，在业界的广泛支持下，过程几乎相同。

图2：标准开发方案

CAN XL 技术工作的基础是在 CAN in Automation （CiA） 中完成的。在稳定文件后，它被移交给 ISO 以创建一个国际标准。这一过程仍在进行中，预计将于 2023 年完成，并获得批准的国际标准。CiA 将作为技术委员会和用户联盟继续推动 CAN 标准。

以太网规范由 IEEE 拥有和维护。所有标准化工作都是在一个工作组内完成的，该工作组创建了 2019 年草案，以纳入 IEEE 802.3 主要标准。由于 IEEE 是一个独立于行业的组织，OPEN 联盟负责扩展汽车要求的规范。对于 OPEN Alliance 规范的长期维护，还涉及 ISO。

2.1 CAN XL – 更高的速度、更多的有效载荷和附加功能

尽管 CAN XL 为 CAN FD 提供了完全的向后兼容性，但帧格式已得到广泛更新。在这篇文章中，我将介绍主要差异并概述新领域的意图。在以后的文章中，我们将介绍更多细节，包括更新的位时序更改、位填充和错误信号通知规则。

CAN XL 遵循 CAN FD 的概念，具有低速仲裁阶段（最高 1MBit/s）和高速数据阶段。CAN XL 数据阶段位时间被指定为高达 10MBit/s。CAN XL 的另一个关键特性是有效载荷长度可达 2048 字节。此外，CAN XL 完全向后兼容 CAN FD。

图 3：CAN XL 帧格式

图 3 显示了 CAN XL 帧格式，命名了不同的字段区域，并指出了标称位时间的使用位置以及高速位时间的开始位置。简要说明了关键更改之后 - 如您所见，几乎所有内容都已更新。

优先级 ID——这个 11 位长的字段是以前称为“基本标识符”的字段。CAN XL 在第一个仲裁字段中仅支持 11 位。

IDE——仅仅因为不支持标识符扩展，该位总是作为显性位传输。

XLF ， resXL – 这两位（XLF 为隐性，resXL 为显性）编码后一帧为 CAN XL 数据帧。

广告– “仲裁到数据序列”是从标称数据位时间切换到 XL 数据位时间发生的点。与在单个位中完成更改的 CAN-FD 相比，CAN XL 中的转换需要更长的时间以增加此敏感过程的稳健性，从而允许收发器更改为快速模式，其中 TX 节点可以在推/拉模式下运行。

SDT—— “服务数据单元类型”是描述有效载荷类型的上层信息。该字段相当于以太网协议中的 EtherType。SDT 由 CiA 611-1 定义。

SEC——该位指示帧是否在有效负载中包含简单或扩展内容，并且是从上层提供的。

DLC– 数据长度代码字段与之前版本的含义相同。使用这个 11 位长的字段，指示从 1 字节到 2048 字节的数据字段。

SBC – 填充比特计数字段提供有关仲裁字段中动态填充比特数量的信息。在后面的文章中，我们将详细介绍 stuff bit 规则。该值将由协议控制器计算。

PCRC – 前言 CRC 字段是根据迄今为止解释的仲裁字段和控制字段中的大多数位计算得出的 CRC。目的是获得对标头信息的额外保护。

VCID—— “虚拟 CAN 网络 ID”应该支持 CAN 总线上的虚拟化，就像以太网网络中的 VLAN 概念一样。

自动对焦– 接受字段，也由上层提供，是用于帧分类的附加 32 位，可以看作是对降低的优先级标识符字段的补偿。

数据字段——在该字段中，实际有效载荷由上层提供，其中字节编号从 0 到 DLC。

FCRC – 帧 CRC 是根据目前看到的所有动态比特计算的

FCP – 格式检查模式允许接收器确认他仍然与发送器在比特流上同步，并宣布 CAN XL 数据阶段结束。这是对该领域的一个非常简单的解释。

DAS——在数据到仲裁序列中，比特率从 XL 数据比特时间切换到标称比特时间。

ACK/EOF – 帧以已知的确认时隙和 EOF 序列结束，其格式没有改变。

在媒体访问方案上，与以前的 CAN 版本相比没有变化，CAN XL 仍然遵循 CSMA/CR 原则。

2.2 10BASE-T1

在对 CAN XL 说了很多话之后，让我们看看 10MBit 汽车以太网，准确地说，是 IEEE 802.3cg 中定义的 10 MBit/s 单对以太网 （SPE）。10MBit SPE 的 MAC 层协议与其他以太网协议没有区别，无需进一步解释。

图 4：IEEE 802.3cg ［4］ 的范围

相反，IEEE 定义了一个物理层，以满足汽车行业在稳健性、实施成本和布线方面的需求。结果是具有不同应用目标的两个不同物理层。

10BASE-T1L – 这是 10MBit/s SPE 的“长距离”变体，允许长达 1000 米的电缆长度。这种点对点变体超出了汽车应用的范围，但可用于卡车、火车和其他车辆技术。

10BASE-T1S – 这是“短距离”变体，电缆长度可达 25 米，并允许使用 10 厘米短截线的总线拓扑结构。为了避免共享总线拓扑上的冲突，该标准定义了一个可选的协调子层，称为 PLCA（物理层冲突避免）。

PLCA ——PLCA 的目标是在吞吐量、延迟和公平性方面改进多点（总线）拓扑上以太网 （CSMA/CD） 中现有的冲突检测机制。重要的是要知道这种“仲裁”纯粹发生在 PHY 级别，MAC 在以下描述的过程中不发挥任何作用。

图 5：PLCA 循环示例 ［2］

在 PLCA 系统中，每个 PHY 都分配有一个唯一的 PHY ID，范围从 0 到 255。ID 为 0 的 PHY 是 PLCA 协调器。总线上的每个 PHY 都知道 PHY 的数量。PLCA 使用循环方案，其中每一轮都由 PLCA 协调器发送一个信标来触发。PLCA 方案中的每个参与者，包括协调器，在 BEACON 之后按照 PHY ID 的顺序都有一个传输机会。

传输机会只是一个机会。如果一个节点没有要传输的东西，系统中的下一个 PHY 会在超时时间之后获得他的机会。如果一个节点有一个传输挂起，它被允许在他的传输机会内开始传输一个帧。如果系统配置允许，一个节点还可以传输多个帧，即所谓的突发。它们每条消息的有效负载长度可以不同。

这种调度方案避免了总线冲突和重新传输，从而降低了可用带宽并保证了系统内传输机会的公平性。在此 PLCA 机制之上，可以在 MAC 层启用其他整形功能，例如 Credit Base 整形或 Time Aware Shaping。

3. CAN XL 和 10BASE-T1S 之间的比较——获胜者是……

赢家是用户。两种协议都提供允许应用程序传输更长有效载荷并在总线上实现接近 10Mbit/s 的传输速度的数据速率。甚至媒体访问方案都不一样，我们分两种方式来比较。

3.1 数据报效率

两种协议在数据报中都有报头和报尾形式的开销（例如寻址、协议字段、CRC）。在 CAN XL 中，效率进一步受到仲裁阶段和数据阶段填充位和不同总线速度的影响。

图 6：数据报效率比较

图 6通过将开销上的花费与有效载荷位上花费的时间相比较，绘制了数据报在有效载荷上的效率。

CAN XL 受到较慢的仲裁阶段和更大的报头和更多开销位的影响。以 1MBit/s 而不是 500kBit/s 运行仲裁阶段可以显着提高较短帧的数据报效率。有人可能会完美地争辩说，在 CAN XL 中，协议类型和接受字段是用户日期而不是开销。这将使 CAN XL 更接近 10BASE-T1S 的曲线。

3.2 总线循环效率

如果我们观察 PLCA 循环而不是单个数据报，情况正在发生变化。

图 7：PLCA 循环示例

让我们假设系统配置如图 7 所示，并假设只有 PHY 9 有未决传输。在这种情况下，总线保持未使用状态的时间是超时时间的 9 倍，在这种情况下我们假设为 24 位。此外，BEACON 所需的额外时间，效率变化如图 8 所示。

图 8：总线循环效率示例

在 CAN XL 中，等待任何传输机会不会降低总线效率，但仍需要考虑空闲时间和 EOF 序列。然而，在 512 字节有效载荷的典型操作条件下，两种协议显示出相同的效率。

四、结论与展望

这两种协议都是为了处理新 E/E 架构的要求而开发的，并在 10MBit/s 区域提供预期的性能。除了这里简要解释的协议字段之外，在更高级别协议的可用性方面还有其他一些增强，例如，安全性或功率传输的考虑。

协议的效率取决于用例、系统配置和扩展功能的使用。更喜欢哪种变体更像是一个哲学或战略问题。从我们的角度来看，这两种协议都有可能在不同应用中的相同车载网络 （IVN） 中使用。

审核编辑：郭婷