汽车的联网将主要基于使用各种以太网和 CAN 变体。虽然以太网以其基于服务的 IP 通信和辅助系统级别的 Some/IP 中间件占据主导地位，但基于信号的 CAN 网络将在驱动器和底盘领域长期存在。新的 CAN XL 应该在使这两个根本不同的概念共存并相互协作方面发挥重要作用。这引发了一个问题，即 CAN XL ECU（电子控制单元）是否参与基于服务的通信，以及可能存在的实现这种通信的方式。从广义上讲，部分CAN XL 的关键技术参数已经确定：CAN XL提供高达 10 Mbit/s 的数据速度，并且用户数据的可变长度在1byte到 2 048byte的范围内，它还能够在 CAN XL 帧内传输完整的以太网帧。另外CAN XL 在其他方面与经典 CAN 或 CAN FD 以及基于信号的通信概念反向兼容。这对于小型和紧凑型汽车的电子架构的进一步开发特别有利，高级驾驶员辅助系统 (ADAS) 和自动驾驶不需要以太网高性能通信。CAN XL 可以继续使用现有的网络概念和线束，而无需进行大的修改。面向服务的通信还负责动态数据结构的传输。要传输的数据量仅在应用运行时生成，例如传感器数据融合应用。这些数据不能以典型的基于信号的通信方式静态地映射。相反，通信系统必须动态地序列化数据。SomeIpXf模块负责Autosar经典平台中的序列化。因为它是Autosar中间件级别的一部分，所以它的功能也可以用于串行化CAN XL的动态数据。Some/IP 支持全动态和半动态链接。当网络节点不知道彼此的 IP 和 MAC 地址时，使用完全动态链接。在协议级别上建立动态通信有一些好处：服务可以在网络内重新定位到任何其他所需的节点，而无需修改ECU。这同样适用于 MAC 和 IP 地址。需要时，消费者和提供商可以多次使用地址解析协议 (ARP) 来确定各自的 MAC 和 IP 地址。同样，有时候也需要使用静态 IP 地址和 MAC 地址的半动态链路连接。每个 ECU 都有一个映射表，其中保存了其他网络节点的 IP 和 MAC 地址。此方法也在运行时在服务级别上建立动态通信，但允许更快地启动通信，因为它可以在没有 ARP 的情况下进行。通过半动态链路连接，服务也可以任意移动，因为所有 IP 和 MAC 地址都是已知的。这里的缺点是现在不能再更改 IP/MAC 地址。在这种情况下，所有涉及的 ECU 中的映射表也必须更新。为了发挥其作为以太网和 CAN 域之间链接元素的作用，CAN XL 还应该能够参与面向服务的通信。因此，未来 E/E 架构的设计者非常有兴趣确定 CAN XL 可以在技术方面提供哪些选项。同时，用户不断努力寻找最具成本效益的解决方案。其中的一个关键因素是确定各个解决方案对软件堆栈和 ECU 硬件的要求。第一种可能是在CAN XL上路由以太网帧。为此，可以使用标准的以太网交换机。在硬件方面，有必要在CAN XL网络所连接的端口和CAN XL网络之间开发并合并一个CAN XL PHY。CAN XL PHY应该能够复制所有以太网帧到CAN XL帧，反之亦然，这取决于通信方向。它只在以太网交换机上需要，而在CAN XL节点上常用的收发器就足够了。当然，也可以使用传统网关，如下图所示。对 CAN XL 堆栈的要求要高得多。一旦以太网帧可以合并到 CAN XL 中，CAN XL ECU 中也将需要一个通用的 TCP/IP 堆栈。请记住：嵌入在 CAN XL 帧中的是一个以太网帧，它也包含一个 IP 数据包。反过来，接口层必须能够适应 CAN 和以太网的行为。接口层的CAN部分解包以太网帧，以太网部分解包IP帧。此外，每个 CAN XL 节点都需要一个虚拟 MAC 地址。然后，CAN XL PHY 只需要一个 CAN 帧，用于将以太网接收到的帧进一步传输到 CAN XL，并且每个 CAN XL 节点都有另一个 CAN 帧用于响应数据。可以根据帧中嵌入的 MAC 地址执行过滤功能。在这些条件下，Some/IP、Some/IP-SD 和 ARP 的功能与纯以太网网络中的完全相同，如下图所示。
IP帧路由
第二种可能是使用合适的网关，将IP帧而不是以太网帧路由到CAN XL。网关的任务是将IP帧从以太网帧解包。在网关中适当的路由表的帮助下，网关将嵌入的IP地址识别为要打包在CAN XL帧中并路由到CAN XL网络的数据包。在这里，CAN XL ECU也需要TCP/IP堆栈。对于CAN接口，在实现中只需要做很小的改变，但是TCP/IP协议栈可能会有很大的改变。嵌入在帧中的IP地址可用于过滤。在此场景中，Some/IP和Some/IP- sd的功能与纯以太网中完全相同(如下图)。
从前面提到的两种可能性中，我们可以得出结论:在这两种情况下都可以实现某些/IP功能。以太网帧的路由要求在标准交换机上有一个新的CAN PHY，而在CAN XL ecu上的软件堆栈需要一个新的中间层。当路由IP帧时，也需要改变软件堆栈。软件模块不需要逻辑更改;只需要修改实现。
第三种可能的解决方案是完全放弃 TCP/IP 堆栈。这样做的动机是可以在每个 CAN XL ECU 中节省大约 50 KB 到 100 KB 的 ROM 存储容量，从而能够使用更小、成本更低的控制器。在这里，新引入的“Some/CAN”层取代了软件堆栈中的 TCP/IP (TCPIP) 和套接字适配器 (Soad) 模块。一些/IP 消息在PDU（协议数据单元）路由器模块中进行转换。Some/IP-SD 消息需要在应用程序中反序列化，然后再序列化回相应的 Some/CAN 帧。这样做时，网关将 Some/IP-SD 标头中的 IP 地址和端口号替换为 CAN ID，并将帧标识为“CAN XL 类型”。在以太网中，Some/IP 订阅者侦听专用 (UDP) 端口，而 Some/CAN 订阅者等待特殊的 Some/CAN ID。是否涉及 Some/CAN 帧或服务发现，在报头中由消息值指示。消息值 FFFF 8100h 标识服务发现消息（如下图所示）
Some/IP 通信可以转换为 CAN，无需 TCP/IP 堆栈。这使得 Some/CAN XL CAN 可行，尽管这确实取决于适当扩展的 Autosar 堆栈中的某些软件模块，因此排除了通过硬件的过滤。
如果进一步充分发展Some/CAN方法，硬件滤波仍然是可行的。为此，每个用户将收到一个节点地址。然后，该节点地址启用硬件过滤。在这方面，还需要为服务提供提供多播或广播地址。由于节点地址现在用于寻址，网关必须静态地映射它们。对于动态映射，需要实现合适的CAN节点地址解析解决方案。节点地址将过滤和网络访问分开。这意味着可以在不更改用户的情况下更改优先级。
以上列出了使用CAN XL实现面向服务通信的几个选项。虽然可以设想以太网帧和IP帧的路由，但需要有一种很好的方法来过滤硬件以提高效率。为了实现更小、更经济的控制器，最好通过在CAN XL上免除TCP/IP堆栈来实现Some/ IP通信。早期硬件滤波的问题可以通过引入节点地址来避免中断负载来解决。CAN XL上面向服务通信的具体发展方向还不清楚。要实现的应用程序演示了需要在CAN XL上面向服务这一事实。总的来说，CAN XL完全可以做到这一点。
本站仅提供存储服务，所有内容均由用户发布，如发现有害或侵权内容，请
点击举报。
