中文  |  English
所在位置:市场活动 > 客户案例与技术文章

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

前言


CAN总线作为车载总线中极为重要的一部分,已经经历了相当长时间的考验,而第二代CAN总线(即CAN FD)也在近几年里逐步实现大规模的应用,与此同时,第三代CAN总线(CAN XL)也将要正式推出。本文将为大家分享CAN XL的相关内容。


为什么要推出CAN XL


1)填补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。

image.png 

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


2)增加最大报文长度

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

为什么CAN XL要极大地增加最大报文长度? 这就涉及到第三点:如何与以太网的10BASE-T1S形成有力竞争。


3)竞争力

前面提到了对垒双方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的特点


1)通信速率:10 MBit/s以上

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


2)帧结构

 image.png

图2 CAN XL帧结构


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

3)SDT、AF

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

 image.png

图三 SDT定义


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


4)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设计为同样的值,继续按照之前的方式使用。


5)VCID

VCID参照了以太网中VLAN的概念,将VLAN ID应用到CAN XL上,即在数据链路层允许进行虚拟网络的划分。与VLAN的相同,这种虚拟网络划分使得通信可以摆脱一部分物理拓扑的限制,也能提高数据的安全性。其实这种虚拟网络在当前CAN中存在类似的机制(AUTOSAR Partial Network,后文简称PN),也就是说,如果我们使用CAN XL中的VCID,我们就可能出现3种局部网络:通过软件实现PN而形成的上层局部网络(包含网络管理和上层应用);通过VCID实现的数据链路层的局部网络;通过PN收发器实现PN而形成的物理层局部网络(主要应用网络管理)。如何将这3种机制融为一体可能会是CANXL落地后需要考虑的部分。


对于选择10BASE-T1S还是CAN XL,考虑哪些方面


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


1)用在哪里

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


CAN XL典型应用场景:在以太网作为主干网的架构中,CAN XL用作其下一级网段,满足对数据吞吐、实时性有较高要求,需与域控或区域控制器构建更灵活的交互机制的通信需求。基于这种场景,CAN XL可能是更优的选择(即本文的核心观点:兼容性)。


如果选择10BASE-T1S,车内CAN信号的交互需要经过UDP/TCP包的重组,可能还需要考虑丢包、延迟等协议不同带来的差异。


2)成本

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


3)沿用件的情况

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


4)休眠、唤醒

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


总结


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


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



注:文中部分图片来源于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