本文将介绍如何将记录的SOME/IP报文在以太网网络中回放，并给出在CANoe PRO Option Ethernet中的实际操作方法。该方法同样适用于其他无法直接回放的网络协议，如TCP、含SecOC的网络数据等。
01
SOME/IP简介
SOME/IP通信协议允许以多种方式交换复杂的数据类型，例如远程过程调用（RPC），通知事件（Notification Event）和Field。通常，我们会使用SOME/IP-SD服务发现协议来建立通信。SOME/IP-SD协议允许服务提供方（Server端）将其服务接口提供为一个或多个Event Group，提供该服务即意味着该服务可用。服务消费方（Client端）可以检索到特定的服务接口并进行订阅使用。SOME/IP-SD也使服务提供方可以知道是否有服务消费方对该数据感兴趣。在没有服务消费方时，服务提供方将不会发送任何数据。服务消费方接收相关数据时，需先使用SOME/IP-SD通过UDP连接到服务提供方。实际SOME/IP数据传输时使用UDP还是TCP取决于服务接口的Reliable标志，显然TCP连接传输被认为更可靠。如果多个服务消费方订阅了同一个Event或Field，则由服务提供方决定使用UDP多播还是多个TCP单播进行传输。
详细的SOME/IP协议描述和说明，可以参阅AUTOSAR的相关规范。
02
SOME/IP回放原理介绍
本文中介绍的“回放”并非指对log文件的离线分析，而是指基于此前真实ECU通讯或仿真的记录log文件，通过CANoe将log文件中的有效数据在Real Bus场景下动态地发送给被测ECU。
为什么回放不是一个简单的事情？
CANoe用户通常习惯使用内置的Replay Block模块进行数据回放，这种方法对于CAN总线是可行的。典型的汽车CAN网络通信机制是：发送方从一开始就会周期性或事件性地发送CAN报文数据，接收方使用CAN总线上的数据。从通信层的角度看，发送方和接收方没有协商的链路，所有CAN ID都是预先共享的，并且在Payload中的信号也是静态分配好的。但也有例外，例如涉及到点对点（Peer-to-Peer）通讯的诊断数据回放。
图1：对于广播CAN报文的监听记录
如图1所示，记录的CAN报文通常可以直接通过CANoe的Replay Block回放，需要注意的是控制回放的报文不要与DUT或仿真节点发出的报文冲突。这可以通过合适的数据库设置或CANoe的节点过滤机制来解决（如图2）。如果有E2E保护或SecOC等安全加密机制在CAN通讯中使用的话，上述方式将不再适用，此时回放的复杂程度和以太网回放相当。
图2：通过CANoe过滤并回放记录的CAN报文
典型的以太网通讯机制相比于CAN有了显著变化。因为以太网通常是基于交换机而不是总线形式的网络，因此应尽可能避免广播通信，最好使用单播或多播来替代普通的广播通信，确保充分利用当前网络及其网段的带宽，因此要求发送方和接收方相互了解。此外一些通信参数，如IP地址、TCP/UDP端口号，可能是由服务提供方和消费方动态分配的，任何时间点都可能发生变化，且不是预先已知的。由于SOME/IP协议在UDP/TCP和IP层之上，这些通信原理在SOME/IP中间件及其使用的SOME/IP-SD协议中都会用到。此外，SOME/IP也很可能搭配Security相关协议使用。
由于上述因素，很明显无法通过Replay block简单地回放报文。原因总结如下：
>
请求（Request）/响应（Response）模式的使用会导致回放时间不匹配；
>
由于回放时的通信参数（IP/Port/各Header参数等）和记录文件中的信息不匹配，无法与DUT建立通信；
>
在E2E或网络安全机制中，由于动态计算结果与记录文件中的信息不匹配，ECU不会接收回放报文，回放报文会被认为是错误信息或重放攻击；
>
由于记录文件中与当前DUT的TCP状态机中Sequence Number或TCP帧序列不匹配，TCP不会接收这些回放报文……
解决策略概述
为了解决上述问题，可以建立一个残余总线仿真网段（RBS，Remain Bus Simulation）。RBS网段与DUT实时建立通信，不依赖于记录文件。若需要发送与记录文件相同的数据，需要从记录文件中解析并提取有效数据内容，并放入RBS网段中进行仿真发送。不过，从报文的角度看，这只与原数据相似，因为报文本身来自于RBS而非记录文件。因此一般会创建一个Gateway节点，将一个网段中的记录文件数据进行提取/转换，转发至与DUT真实通信的第二个RBS网段中。
上述方法一般适用于应用层数据回放，如果待解决的问题位于应用层以下（比如传输层、数据链路层等），则该方法将不适用。
基于信号的回放
如上文所述，对应用层信号进行回放时，将会建立一个RBS网段对需要回放的信号处理后发送。RBS将确保正确建立所需的通信连接，使DUT处于适当及活动的状态。此外RBS网段也将处理Safety和Security相关机制，比如CRC或SecOC MAC的计算。
图3：通过记录文件中的真实信号结合CANoe RBS对DUT进行激励
基于信号的回放优势是降低了用户从零创建完整RBS仿真逻辑的复杂度。然而，如果有非常多的信号数量或复杂的数据类型，这种方式的扩展性就不是很好了。因为信号需要逐个通过CAPL提取，再给到RBS网段并发送，这会引入大量的CAPL代码编写和维护工作。
点击本文末尾“阅读原文”可下载示例工程，其中的ReplayGateway_Signal示例工程包含2个网段，共用相同的数据库。
图4：实际CANoe回放网段对信号提取并激励至RBS网段的示意图
“Ethernet”网段提供RBS仿真功能用于与DUT建立连接并保持活跃状态。RBS仿真会基于CANoe的交互层（IL，Interaction Layer）DLL文件实现，即CANoeILNL_AUTOSAR_Eth.dll。CAMF作为回放仿真的节点，ADAS作为接收回放数据的ECU。当前示例中的“Ethernet”网段不包含任何CAPL脚本。
“Eth_Input”网段通过Replay Block处理和回放记录文件数据，在该网段中的Signal节点里将会关联“SignalCopy.can”CAPL脚本文件，用于提取和处理选定要回放的信号。一旦该信号在原始回放网络中被获取，将通过该CAPL脚本文件转发至RBS仿真网段中发出。例如，使用on serviceSignal_update函数用于捕获回放至“Eth_Input”网段中的信号/事件，而后可通过$符号或SetServiceSignal()函数将捕获到的信号传输至真实RBS网段“Ethernet”实现对外发送。
基于PDU的回放
由于SOME/IP协议被设计为无缝适配AUTOSAR，因此AUTOSAR PDU和SOME/IP传输以太网帧的方式非常相似。每个单独的SOME/IP数据发送可以认为是发送了一个AUTOSAR PDU，多个PDU被打包到UDP或TCP的Payload中进行发送。AUTOSAR PDU的数据格式如图5所示，PDU包括1个64bits的报头Header，后面跟着Payload。报头会分为32bits的报文ID和32bits的长度信息。由于二者Header格式相似，SOME/IP报文可以按照AUTOSAR PDU的格式进行整体处理。
图5：AUTOSAR PDU数据格式及对SOME/IP的映射
实际上，在很多汽车以太网络中，AUTOSAR PDU和SOME/IP通信会同时使用。基于此，CANoe后台的SOME/IP交互层是基于AUTOSAR交互层之上的，SOME/IP交互层和AUTOSAR交互层可以共享很多CAPL函数，比如针对PDU的部分。此时可以使用CANoe中标准的AUTOSAR PDU相关函数库，可以在不依赖数据库或交互层的情况下解析收发的PDU。AUTOSAR PDU相关函数库还提供了一个CAPL事件句柄来区分AUTOSAR PDU。
基于PDU的回放与基于信号的回放思路相同，一个网段的数据信息会被提取并转发到另一个RBS网段，不同之处在于数据信息处理的颗粒度。使用基于PDU的回放，可以一步解决提取和转发SOME/IP服务的所有信号，无需访问具体SOME/IP服务，而是直接访问AUTOSAR PDU。与SOME/IP服务不同，AUTOSAR PDU有on PDU事件句柄可以捕获，并将该PDU通过RBS网段的交互层发出。
在当前ReplayGateway_PDU.cfg示例工程中，“Eth_Input”网段里“Sysvar”节点关联的CAPL文件，通过on PDU *来实现对SOME/IP报文整体捕获处理，并针对PDU Length、PDU SOME/IP Message Data、PDU ID分别提取并赋值给中间系统变量。
而后在“Ethernet”网段里“CAMF”节点中的CAPL代码，将使用on sysvar_update捕获中间系统变量更新，转换为符合SOME/IP格式的ID、Length、Payload数据，并通过OnSomeIpPrepareEvent和OnSomeIpProcessTxMessage回调函数进行赋值并发出。
基于PDU的回放另一个优势是减少CAPL代码量，仅相关的PDU（SOME/IP服务）需要被处理即可，而不需关心具体每个信号。同时，复杂的数据类型，比如动态长度数组或可选类型的信号也可以隐式支持。然而，由于全部的信号都是作为一大块字节处理的，如果需要对单个信号进行修改操作，则需要额外的CAPL编程。
时序
实际通信的时序行为可能无法很好地反映原始时序行为。这是因为RBS仿真网络取代了原本的以太网报文，时序也同样被覆盖。然而，如果CANoe没有遇到性能问题，那么信号更新的相对时序在大多数情况下都是可以接受的。值得注意的是，RBS网段只有在DUT已订阅的情况下才会传输更新的信号值，如果DUT的启动时间早于记录文件里的时间，RBS仿真网段会默认将所有信号值设置为0。为了解决这个问题，可以对Replay Block的启动时间进行配置。
图6：CANoe中基于信号的回放效果
03
总结
上述CANoe示例工程可点击“阅读原文”下载。
使用CANoe可实现各类总线报文的记录与回放，包括各类基于调度表、点对点连接、包含网络安全加密机制的报文仿真和回放，同时可对回放过程中的数据进行篡改，并基于回放数据对ECU进行测试。
如有问题，欢迎联系
support@cn.vector.com
END
维克多中国
微信号｜Vector维克多
Bilibili | 维克多汽车技术
info@cn.vector.com
021-2283 4688
请点击“阅读原文”查看CANoe示例工程
