车载以太网（BroadR-Reach）已经在汽车摄像头领域得到了应用，并逐步扩展到其他应用领域。为了实现带宽的高效利用，车载以太网采取与CAN总线通信方式相反的支持动态的、面向服务的通信。因此，相应的开发工具也必须要能够支持面向服务的协议，如SOME/IP（Scalable service-Oriented MiddlewarE over IP）。
 

本文以SOME/IP为例介绍如何实现动态的、面向服务的IP网络残余总线仿真，如图1所示。并从媒介访问、同步以及仿真控制的角度进行探讨，希望可以给相关开发人员提供一些有价值的参考。

图1 车载网络测试示例

基于SOME/ IP的服务协议使用
 

在以太网（IP）领域，有众多协议可供选择，从而导致一种错误的印象：即现有协议可以直接用于车内所有可想象到的应用程序。但是，车载网络并非从零开始，所选用的协议也要能满足特定的需求。比如，新的协议要能很好地适配于当前的车载网络系统，特别是涉及到AUTOSAR架构的良好集成以及在出现通信错误情况下如何确保时间延迟的快速反应机制。宝马开发并定义的SOME/IP，是一种可以满足汽车使用需求的开放式协议。Vector提供基于SOME/IP的完整工具链，包括TCP/IP协议栈、服务发现（Service Discovery）和BroadR-Reach以太网驱动程序等。
 

SOME/IP提供面向服务的通信接口，与当前汽车主要总线CAN的面向信号的通信方式有很大不同，如图2所示。SOME/IP可以大致分为三个部分：服务发现（Service Discovery，SD），远程过程调用（Remote Procedure Call，RPC）以及访问进程数据。ECU通过SD在网络中查找服务或者提供服务，客户端（Client）通过RPC去调用SD提供的方法，如图3（Part A）所示。此外，ECU还可以将特定事件设置为通知，如图3（Part B）所示，由服务端（Server）ECU自动向客户端ECU发送服务内容。客户端ECU的应用程序也可通过读写函数去访问任意特定进程的数据，如图3（Part C）所示。SOME/IP期望以一种最优的方式利用带宽并实现灵活的通信方式，其数据库格式有FIBEX（FIBEX 4.1或更高版本）和ARXML（AUTOSAR4.1或更高版本）。

图2 SOME/IP提供可用于标定的接口

图3 SOME/IP访问方式

基于CANoe的SOME/IP网络仿真应用

在残余总线仿真中，SOME/IP作为复杂的协议和中间件，设计时较为灵活。为了尽可能地降低工程的复杂度，在CANoe中与SOME/IP相关的绝大部分配置都可以自动化完成，前提条件是标准格式的数据库文件（比如FIBEX或ARXML）。CANoe中SOME/IP的仿真功能基于SomeIP_IL.dll以及CANoeILNL_AUTOSAR_ETH.DLL实现，可在Simulation Setup中将上述dll文件分配给对应的仿真节点并配置其SOME/IP交互层属性。

> 在以太网网段里添加FIBEX或ARXML数据库文件

图4.1 添加数据库

> 鼠标右击数据库文件，选择Node Synchronization，选择需要创建的节点，点击>>按钮，点击Next、Finish即可

图4.2 创建仿真节点

> 在Simulation Setup界面，鼠标右击bus node分配相应的dll文件（dll文件存储在CANoe安装目录下Exec32文件夹中）

图4.3 分配dll文件

至此，一个完整的残余总线仿真环境已经搭建完成。用户还可以通过右击Network node，选择Component Configuration，修改服务的发送方式，如图5所示，服务发现以及订阅后的通知就会周期性的发送，进一步的功能还可以通过CAPL编程实现，例如读写信号值，调用Method等。

图5 配置IL属性

在CANoe->Trace窗口可以查看SOME/IP的通信过程，如图6所示。

图6 Trace窗口

CANoe 11.0版本中新增一个EthernetNetwork Monitor分析窗口，可以方便地查看SOME/IP各节点的订阅关系和相关服务信息，如图7所示。

图7 Ethernet Network Monitor

如果没有数据库或者数据库不完整的话，CANoe也可以直接通过相关dll文件封装好的函数，利用CAPL去创建服务（Event/Method），以及实现Event的触发发送和Method的调用，相关函数在CANoe的帮助文档中都有示例可供参考，如图8所示。

图8 CAPL脚本

利用测试工具实现灵活的访问网络

利用测试工具能够以最优的方式去实现复杂的测试任务，比如残余总线仿真，需要工具可以灵活、高效地访问物理媒介，如图9所示。通过对物理媒介的访问，开发人员可以修改网络上传输的数据来生成错误的测试用例（如CRC错误）。但如果仅仅只是监测分析两个节点之间的通信行为，则需要一种特殊的测量方法来实现透明、无干扰的访问物理媒介。虽然逻辑上Open Alliance BroadR-Reach（OABR）是一种总线系统，但从物理层角度来看属于点对点连接，所以这种特殊的测量方法是很有必要的。解决方案之一是在系统中使用的交换机上增加一个额外的监控端口，但由于成本原因，不是所有交换机都会预留监控端口。在这种解决方案中，交换机会将所有接收到的数据转发到监控端口，从而产生两个问题：一是转发的数据没有共同的时间基准，因为没有时戳；二是交换机只会将有效的数据转发给监控端口，导致对一些错误的分析变得困难。

图9 VN5610在不同应用案例中的使用

为了最大限度地减小媒介访问对网络分析的影响，引入了一种名为TAP（TestAccess Point）的分析方法。与标准的数据转发不同，通过TAP可以在不影响节点通信的前提下透明地分析网络，如图9所示。根据具体需求，TAP可以工作在两种不同的模式：

> 被动模式：可以保证恒定的较短的延迟时间，但是只能监听物理媒介。

> 主动模式：在数据转发过程中可以插入额外数据，但是会有一定的延迟。

由于主动模式要对数据流进行处理，而流控涉及到了数据链路层（OSI Layer2），因此不能用在物理层（OSI Layer1）。与此同时，流控不能保证恒定的等待时间。无论选择哪一种模式，为了尽可能精确地分析PacketData（分组数据），都需要获得尽可能接近物理层的精确时间戳。由于网络分析通常关注多个以太网路径，同时还需考虑汽车上其他的总线网络，因此这些时间戳必须要与其他接口设备进行同步。

选择合适的开发工具

基于以上的考虑，每个开发者在选择相应的开发工具时都可以先思考下面五个问题：

> 工具是否能够支持面向服务的通信，比如SOME/IP？

> 工具是否能够提供日志记录以及在有或者没有违反协议的情况下控制仿真？

> 工具是否能够支持访问主流的车载网络，如OABR，CAN，FlexRay和MOST？

> 接口是否可以灵活的用作镜像的TAP转换器以及交换机？

> 支持多种网络类型的接口是否能够与常用的总线系统和IP网络同步？

软件CANoe.Ethernet与硬件VN5610A/VN5640可以满足上述的所有要求。通过CANoe.Ethernet可以实现以太网通信的监测、以太网节点仿真、以太网数据链路层及其上层协议测试。以太网接口卡VN5610A包含两路以太网通道和两路高速CAN/CAN FD通道，VN5640接口卡支持16路以太网通道和两路高速CAN/CAN FD通道。16路以太网中包含12路车载以太网通道和4路标准以太网通道。VN5640可工作于Standalone模式下，脱离上位机实现2层交换机的报文转发功能，同时还提供数字/模拟IO通道。Vector一直致力于为用户提供高效优质的产品和服务，CANoe.Ethernet与VN5610A/VN5640的组合在行业中得到了广泛应用。