对垒以太网10BASE-T1S，CAN XL能后来居上么？

前言

为什么要推出CAN XL

  填补CAN FD与100BASE-T1之间的空白   

当前常用车载总线既包括低速率的总线，这些总线覆盖了5MBit/s及以下的应用（目前CAN FD的典型速率是2MBit/s，后续可能会升级至5MBit/s），也包含高速率的总线，即车载以太网（100/1000BASE-T1）。而在“复兴号”和“绿皮车”之间，需要较为合适运载手段，以在成本、性能、速率之间取得平衡，顺应新的应用场景需求。

大家可能会问，FlexRay总线是否可以？

●

只要对FlexRay总线有所应用，会了解其开发成本、不友善的刷写应用、不利于拓展的拓扑结构等都影响了更广泛的推广应用，从而被放弃。

所以在10 MBit/s通信的“gap”区间，出现了2种易于推广的方案：从高速率通信技术下沉而来，即10BASE-T1S；从低速率总线升级提升而至，即CAN XL。

图1 填补CANFD与100BASE-T1之间的空白

   增加最大报文长度   

最大报文长度与通信速率是相辅相成的，更快的通信速率意味着可以使用更大的数据长度。CAN XL被设计为至少实现10 MBit/s的通信速率，最大支持2048字节的单帧传输。从CAN FD最大支持64字节的报文长度，到CAN XL最大支持2048字节，报文长度的提升有了质的飞跃。而我们知道，通常以太网报文的单帧最大长度为1518字节，这意味着我们可能会在CAN XL上运行TCP/IP协议。

为什么CAN XL要极大地增加最大报文长度？

这就涉及到第三点

如何与以太网的10BASE-T1S形成有力竞争

   竞争力   

前面提到了对垒双方10BASE-T1S与CAN XL大致信息。先说10BASE-T1S，其上层协议完全使用TCP/IP，物理拓扑上则变成了类似CAN的总线形式，总的来说特点就是降低成本。得益于以太网上层应用的成熟性，10BASE-T1S能更好地将外部应用向车内扩展。但是，车内如何与当前车载网络技术融合是很大的挑战，这在我看来也正是CAN XL在着力解决的问题：兼容性。

CAN XL一方面是从CAN FD衍生，继承了CAN FD的特性（如仲裁机制、错误检测等等），能很好的衔接以CAN为主的车内通信（主要是指基于信号的通信方式）；另一方面，CAN XL对其协议做了很大的扩展，允许在CAN XL上运行TCP/IP，或者说：既然10BASE-T1S的核心竞争力是成熟的TCP/IP协议和丰富的上层应用，那么秉承打不过就加入的策略，CAN XL期望做到对以太网上层协议的良好兼容（特别是面向服务的通信方式）。

这也正是本文前面所说，早期的CAN XL需求更多的是解决速率瓶颈，但随着不断演进，兼容性、“包容性”变成了非常关键的要素。那么接下来我们介绍一下CAN XL的特点，探讨下其怎样实现这种兼容性。

CAN XL的特点

   通信速率：10 MBit/s以上   

首先是其通信速率，设计为10 MBit/s以上（典型速率可能为12 MBit/s，但不会超过20 MBit/s），但由于CAN XL还没有完全落地，实际的参数需要等正式标准化结束后才有定论。

   帧结构   

图2 CANXL帧结构

帧结构总体与CAN FD一致，帧的头尾是低速模式（约1MBit/s），帧主体是高速模式，高速模式和低速模式通过特定字段划分。帧格式的简要说明如下：

Priority ID、AF（Acceptance Field）：与CAN ID相比，CAN XL把优先级和message ID的概念做了拆分，Priority ID用于处理优先级，AF用于表示message ID，后文做额外说明；

XL：这个字段包含多个bit，表示此报文是标准CAN报文、CAN FD报文还是CAN XL报文（即兼容CAN、CAN FD）；

ADS（Arbitration Data Sequence）、DAS（Data Arbitration Sequence）：速率转换的过渡字段，用于低速率转高速率、高速率转低速率；

SDT（SDU Type）：指示数据类型，后文做额外说明；

SEC：表示是否为加密数据，由于目前的资料有限，可能需要等CAN XL正式发布后再讨论其作用与否；

SBC（Stuff Bit Count）、PCRC、FCRC、FCP（Format Check Pattern）：用于CRC校验、错误检测，由于可携带数据长度增加了很多，因此设计了前后2处的CRC检验，CRC的长度也相应扩展；

VCID（Virtual CAN Network ID）：类似以太网中的VLAN，后文做额外说明；

   SDT、AF   

前面提到，CAN XL可以兼容以太网上层协议和CAN通信，这部分的内容正是由SDT和AF字段实现。SDT类比于Ethernet Ⅱ的类型字段，表明CAN XL报文携带什么样的数据；AF是用于寻址的字段，类比于CAN ID和以太网的MAC地址，根据SDT的不同值，AF可以有不同的寻址方式。比如当SDT=0x3，AF就是传统的CAN ID，报文携带的数据就是传统CAN报文的数据；SDT=0x4，AF表示以太网中目标MAC地址，报文就表示为以太网报文。

图三 SDT定义

看到这里，有读者应该会意识到，这里存在一个问题。CAN XL通过SDT和AF的组合可以表明一个以太网报文，但是以太网报文中3个重要字段：源MAC地址、目标MAC地址、类型在CAN XL中只截取了目标MAC地址。目前看CAN XL可能是打算将整个以太网报文都放进data field中，再增加帧头等信息，但笔者认为这不是一个很好的方式，可能需要等CAN XL正式发布后我们再来探讨下这部分内容。

   Priority ID、AF    

CAN依据优先级进行仲裁，而在CAN和CAN FD中，优先级和message ID使用相同载体，这也使得在系统设计时会将重要信号放在高优先级的报文中。但CAN XL将优先级和message ID做了分开处理，即Priority ID和AF。这意味着可以有更灵活的设计方式，同时由于SDT的划分，CAN XL报文同样也可以采用源地址和目标地址的寻址方式（即SDT=0x2， Node Addressing）。但考虑到CAN已经使用了很多年，出于沿用和过渡的考虑也可以将Priority ID和AF设计为同样的值，继续按照之前的方式使用。

   VCID   

VCID参照了以太网中VLAN的概念，将VLAN ID应用到CAN XL上，即在数据链路层允许进行虚拟网络的划分。与VLAN的相同，这种虚拟网络划分使得通信可以摆脱一部分物理拓扑的限制，也能提高数据的安全性。其实这种虚拟网络在当前CAN中存在类似的机制（AUTOSAR Partial Network，后文简称PN）。

也就是说，如果我们使用CAN XL中的VCID，我们就可能出现3种局部网络：通过软件实现PN而形成的上层局部网络（包含网络管理和上层应用）；通过VCID实现的数据链路层的局部网络；通过PN收发器实现PN而形成的物理层局部网络（主要应用网络管理）。如何将这3种机制融为一体可能会是CAN XL落地后需要考虑的部分。

CAN XL

 对于选择10BASE-T1S还是CAN XL

考虑哪些方面

前面提到很多关于CAN XL的内容，但总的来讲，其与10BASE-T1S各有优劣，尤其是当前CAN XL还未正式发布（所有的内容都可能存在变更），那么在此仅基于应用落地的考虑谈谈如何做出选择：

   用在哪里   

在考虑成本等因素前，或许需要先梳理清楚为什么要引入这些技术，应用场景是什么。

● CAN XL典型应用场景：

在以太网作为主干网的架构中，CAN XL用作其下一级网段，满足对数据吞吐、实时性有较高要求，需与域控或区域控制器构建更灵活的交互机制的通信需求。基于这种场景，CAN XL可能是更优的选择（即本文的核心观点：兼容性）。如果选择10BASE-T1S，车内CAN信号的交互需要经过UDP/TCP包的重组，可能还需要考虑丢包、延迟等协议不同带来的差异。

   成本   

成本将会成为能否广泛推广应用的核心点。虽然CAN XL在设计时就考虑过其成本应该低于10BASE-T1S，但硬件成本只是一方面，软件开发各环节成本可能会是压倒骆驼的最后一根稻草。

   沿用件的情况   

沿用件本身应该算作成本的一环，但这里把沿用件单独拿出来分析，是由于车型的更迭不是一蹴而就的过程，会有较长的过渡期，甚至某些样件或技术会一直沿用。这种情况下，新技术的引入必须考虑与沿用件和原技术的兼容情况。

   休眠、唤醒   

这里的“休眠、唤醒”指的是低功耗相关行为，当前的车载以太网对于休眠唤醒的深度支持大多需要I/O或者CAN端口作为控制来实现，这对于车内网络来说显然不够灵活并且也产生额外的成本，或是需要10BASE-T1S的PHY同样支持TC10所定义的Sleep/Wake-up机制。而CAN XL由于继承了CAN本身的休眠唤醒特性且可兼容CAN，有着天然的优势（CAN XL可以使用标准CAN报文作为唤醒信号，而不需要为了适应高速率做额外定义）。

总结

虽然CAN XL未正式发布，但从目前的技术文档来看其潜力很大，尤其是其既保留了CAN本身的优势、特点，又能对以太网进行衔接。因此需要大家保持关注，提前做好技术储备。

北汇信息专注于汽车电子测试，与众多OEM和Tier1合作，在车载通信、诊断刷写、OTA、车内网络安全、域控制器功能测试等领域积累了丰富的经验。我们会持续关注CAN XL的后续进展，持续分享。

注：文中部分图片来源于http://www.bosch-semiconductors.com/media/ip_modules/pdf_2/can_xl_1/canxl_intro_20210225.pdf

参考文献

[1] CiA 610-1 CAN XL specifications and test plans Part 1: Data link layer and physical coding sub-layer requirements

[2] CiA 610-2 CAN XL Part 2: Data link layer and physical signaling conformance test plan

[3] CiA 610-3 CAN XL specifications and test plans - Part 3: Physical media attachment sub-layer requirements

[4] http://www.bosch-semiconductors.com/media/ip_modules/pdf_2/can_xl_1/canxl_intro_20210225.pdf

[5] TC10 Wake-upSleep Specification for Automotive Ethernet