未来车载网络将主要以Ethernet和CAN总线组合呈现。虽然Ethernet在ADAS领域以基于服务的IP通信和SOME/IP技术占据主导地位，但基于信号的CAN网络仍将在动力和底盘系统中长期存在。第三代CAN总线CAN XL将“连接”这两种本质不同的总线系统，并在协同通信方面起到决定性作用。CAN XL究竟能否支持基于服务的通信？若可以，其可能实现基于服务通信的途径有哪些？
CAN XL规范已明确定义某些关键性技术参数：高达10Mbit/s的通信速度，数据场支持1...2048字节的可变范围，并且能够支持报文内传输完整的以太网报文。此外CAN XL可兼容CAN或CAN FD(基于信号的通信系统)，为小型和紧凑型车辆的电子架构的进一步发展提供便利，因为这些车型目前并不需要采用基于高性能的以太网通信来满足高级别ADAS系统和自动驾驶系统(AD)的需求。CAN XL使复用现有的车载通信网络和线束系统成为可能，而无需进行大的“整改”。
CAN XL将是最佳“协同”方案
尽管基于Ethernet面向服务的IP通信在未来会大行其道，而SOME/IP-SD仍旧将在SOME/IP通信中扮演举足轻重的作用。SOME/IP支持服务提供方(数据发送端)和服务消费方(数据接收端)之间建立动态链接，由谁提供通信数据或服务并不是应用程序关心的重点。
面向服务的通信还负责动态数据的传输，例如传感器数据融合仅在应用程序运行时才使用感知系统采集的数据。基于信号通信的静态映射数据无法满足此类应用需求，这需要通信系统必须支持动态地序列化数据。在AUTOSAR Classic平台中SomeIpXf模块负责序列化工作，属于AUTOSAR基础软件的一部分，因此可考虑用于序列化CAN XL的动态数据。
CAN XL实现基于服务的通信
CAN XL作为以太网和CAN总线之间的“桥梁”，需要支持面向服务的通信。对于未来的E/E架构的设计者而言，其感兴趣之处在于CAN XL究竟可以在技术上提供哪些可实现的可能性；同时，需要探索性价比更优的解决方案，关键因素之一是确定各种解决方案对软件协议栈和ECU硬件方面的要求。
CAN XL路由转发Ethernet报文
第一种可能方案是在CAN XL上直接路由转发以太网帧，因此可以使用标准的以太网交换机。在硬件方面，有必要在连接CAN XL网络的端口和CAN XL总线之间开发并集成CAN XL 物理端口。CAN XL物理端口应支持将以Ethernet帧直接拷贝到CAN XL帧，反之亦然。这个功能仅限于以太网交换机上使用，因为其它CAN XL节点采用自身的收发器就足够；当然也可使用传统网关控制器来实现(如图1)。
图1 Ethernet和CAN XL/CAN混合网络示意
这种方案对CAN XL协议栈的要求较高。CAN XL支持传输Ethernet报文的前提是CAN XL控制器协议栈必须集成TCP/IP模块，原因在于CAN XL报文中嵌入了Ethernet报文，其中Ethernet报文包含了IP数据包。此外通信接口部分协议栈必须同时适配CAN和Ethernet通信行为。通信接口协议栈中的CAN模块需支持将以太网帧拆包，而以太网部分支持将IP帧拆包。此外，每个CAN XL节点都需支持虚拟MAC地址功能，同时协议栈支持基于报文中MAC地址的过滤功能。然后CAN XL 物理端口仅需要一帧CAN报文，即可将Ethernet总线接收的帧进一步传输到CAN XL总线上，并且每个CAN XL节点都支持通过另一帧CAN报文响应数据。当满足上述条件时，SOME/IP、SOME/IP-SD和ARP的功能则与车载以太网完全相同(图2)。
图2 通过CAN XL实现Ethernet通信架构
CAN XL路由转发IP报文
第二种可能的方案是通过网关直接将IP帧而非以太网帧路由到CAN XL。网关的任务是从以太网帧中拆分IP帧。借助网关节点中配置的IP路由表，网关将依据IP地址识别IP数据包，打包在CAN XL帧中并路由到CAN XL总线上。这种情况下CAN XL控制器同样需要TCP/IP协议栈模块。CAN接口模块在实现时改动较小，但TCP/IP协议栈需要进行较大的更改。协议栈支持配置基于IP地址的过滤功能。在这种情况下，SOME/IP和SOME/IP-SD的功能也与车载以太网保持一致(图3)。
图3 通过CAN XL实现IP通信架构
通过上述两种方案可以得出：CAN XL均可实现采用SOME/IP中间件的服务通信。基于Ethernet帧的路由需在标准交换机上新增CAN XL物理端口，而CAN XL ECU的软件协议栈则需要一个新的中间层；基于路由IP帧时，协议栈模块需要修改适配实现。硬件过滤在两种方案中都是可用的，但有可能会占用大量资源。
CAN XL不集成TCP/IP实现SOA – SOME/CAN
第三种可能的解决方案是完全舍弃TCP/IP协议栈。如此可为每个CAN XL ECU节省约50-100kB的ROM存储空间，从而可以采用体积更小，成本更低的控制器芯片。引入全新的“SOME/CAN”层替代传统Ethernet协议栈中的TCP/IP和Socket Adaptor模块。SOME/CAN是来自Vector的CAN XL专家提出的建议，如果市场感兴趣则还需详细定义具体规范和实现方式。网关控制器负责实现SOME/IP到SOME/CAN的路由转发功能。PDU Router模块实现SOME/IP消息的转换。在应用程序中反序列化SOME/IP-SD消息，然后再序列化返回到相应的SOME/CAN消息。在这个过程中，网关将SOME/IP-SD报头中的IP地址和端口号替换为CAN ID，并将帧标识为“ CAN XL Type”。至此，CAN XL报文嵌入在被修改的SOME/IP报文中，故可称作“SOME/CAN报文”。在以太网中，SOME/IP用户监听专用(UDP)端口，而SOME/CAN用户则等待特殊的SOME/CAN ID。帧头中通过消息指示位来标识SOME/CAN消息是否基于服务发现通信，即通过消息值0xFFFF 8100标识为服务发现消息(图4)
图4 新增SOME/CAN模块实现SOME/IP序列化
如图4所示，无需TCP/IP协议栈即可实现SOME/IP通信转换为CAN。尽管需要适当扩展AUTOSAR协议栈中的某些软件模块，但这是SOME/CAN可行性的基础。目前尚未包含硬件过滤的功能。
CAN XL硬件过滤功能
如果CAN XL硬件过滤功能是必要的，则还需对SOME/CAN协议做进一步的开发工作。为此，每个节点需分配一个节点地址，然后采用节点地址实现硬件过滤。同时还必须为服务提供方实现多播或广播地址的功能。由于节点地址用于寻址，因此网关必须实现静态映射节点地址。对于动态映射，还需定义适当的地址解析方案来实现CAN XL节点寻址功能。节点地址将过滤和网络访问分开，即意味着在不更改节点地址情况下，仍旧可实现底层通信优先级灵活调整。
总结与展望
文中列举了CAN XL实现基于服务通信的多种方法。虽然可以通过Ethernet帧或IP实现路由转发，但均不能满足高效的硬件过滤。建议在CAN XL上放弃TCP/IP协议栈来实现SOME/IP通信，从而可采用体积更小、成本更优的芯片。通过引入节点地址的手段来避免硬件频繁中断处理。目前尚不清楚CAN XL上究竟承载哪些应用，但未来可期：某些应用程序(如算法融合)已经表明需要在CAN XL上进行面向服务的通信。总之，CAN XL“为此而生”。
END
