SOA测试系列 | S2S路由功能浅析及测试解读之问答集锦

随着国内外汽车电子架构日益复杂，面向服务的架构（Service-Oriented Architecture，SOA）设计理念逐渐从IT行业走进了汽车人的视野，近年来国内外的各OEM开始逐步推进基于SOA的整车架构。在此推进与演化过程中，S2S（Services To Signal）作为面向信号和面向服务的系统之间的交互桥梁也逐渐成为了非常基础和重要的功能。

最近，北汇信息在CSDN、视频号、B站以及百家号账户上同步进行了一次直播（回放视频已上线），一起探讨S2S的功能和针对S2S的测试解决方案。鉴于直播的时间关系，有些问题没能展开回复，此次发布文字版的问答精选，以飨读者。

1， 延时的一般要求是多少？

这类的延时要求取决于各OEM的需求中对于延时的要求，与信号路由类似，此外还和总线类型有关，CAN、LIN、FlexRay由于通信机制存在差异，延时要求各不相同。一般是几毫秒或10多毫秒这个量级。

2， 功能逻辑是基于信号还是基于Service instance？

这两种都存在。

3， 对于多个源端的情况（信号或者参数来自不同，DUT不能同时收到所有的源端信息），我们如何配置transmission triggers，是否每个源端都需要配置？

每个信号都可以将transmission triggers配置成true或者false。若配置成true，则在源端收到时就会在目标端触发发送，反之则不会触发目标端的发送。

4， E2E不正确时，S2S的转发具体是什么行为？

对于Service转Signal，若Service端的E2E不正确，那么改变Service端的参数值，对应Signal端的信号值不会跟着Service端改变，而是维持Last value。Signal转Service端同理，若Signal端的E2E不正确，服务端的服务参数同样不会随信号变化。此外，E2E不正确时在另一端（目标端）可以反馈E2E错误（目标端信号或者服务参数指示源端E2E错误）。

5， TLS是否可以用CAPL实现？

TLS的仿真和测试工程都可以使用CANoe CAPL脚本编程开发实现。

6， 域控的外围I/O资源的服务化测试和S2S测试有何区别？

域控外围I/O资源的服务化测试，主要特点为：源端的信息来自于I/O资源（比如传感器的硬线信号），测试服务中的所承载的参数或数据，是否和I/O资源所要表征的状态一致（如开关的断开和闭合时对应的服务参数，是否分别与开关当前状态一致），此类测试属于功能测试的范围，比如原子服务/设备抽象服务的功能测试。S2S和上述基于域控外围I/O资源的服务化测试的区别是，S2S的源端信息来自于Service和Signal，这里的Service和Signal来源于以太网或者其他总线，而非域控本身的I/O资源。

7， 北汇信息提供的解决方案是用工具生成CANoe工程吗？

CANoe工程的各类文件（如.cfg、.tes）都是有特定格式的文本文件，从技术角度生成CANoe工程是可行的。目前北汇已经完成的S2S测试，暂时没有采用生成整个CANoe工程的方案。目前的方案是依据测试规范，通过CAPL及其它编程语言完成标准测试工程开发，而是通过定制开发的工具来解析S2S转发关系表，提取标准测试工程运行所需要的参数，从而完成测试工程的自动化配置。此方案可以减少由于S2S转发表变化而导致需要重新手动配置CANoe测试工程的工作量。

8， 用于测试开发的输入文件应该包含哪些信息？

主要包括如下三类输入信息：

1）S2S需求规范；

2）Service、Signal、E2E相关的信息（ARXML中包含，或者提供同样包含相关信息的其它类型的数据库文件）

3）S2S转发关系表

4）其他输入（需求规范中涉及的如SecOC等需求对应的输入物）

9， 基于服务的通信除了AUTOSAR的AP外还有其他的类型（如ROS2），这种AUTOSAR架构以外的S2S实现能否大致介绍下吗？

基于服务的通信用AUTOSAR的AP以外的方式实现（如ROS2或其他），这类的S2S的实现方式和基于AP的实现方案比较类似。同时直播中提到的转发过程存在逻辑转换的S2S转发大多都是基于此类方案。

10， 可以基于ARXML文件替换转发关系表，实现测试吗？

我们知道ARXML中可以包含service和signal的相关信息，以及E2E相关信息，若ARXML中定义了且完整体现了S2S转发关系信息，则也可以通过解析ARXML（替换转发关系表）的方式来实现S2S的测试。当前我们所遇到的情况，S2S转发关系表大都只是单独的文件来体现，而service、signal和E2E信息在ARXML中体现。

11， 直播中提到的S2S有两种部署方案，一个是在CP，一个是在AP，这两种应该怎么选？

直播中提到的两种部署方案是基于AUTOSAR提供的两种方案，实际上S2S的实现方案还有这两种方案以外的方案。具体需要根据整车E/E架构和控制器的软件架构去综合评估选用哪种方案，这两种方案并没有优劣之分，适用的情况和场景不同，但基于AP的方案灵活性要高一些。下图体现的是CP上部署S2S时的架构。

12， 服务测试和信号测试是否采用同一种测试方案？

S2S中信号转服务的测试和服务转信号的测试是有所不同的。首先从仿真来说前者仿真信号，后者仿真服务；其次我们对信号的监控和采集与对服务的监控和采集方法也是不同的，信号发送类型大致有周期型、事件型、事件周期型，服务接口类型有Event、Method、Field，针对不同的信号发送类型和服务接口类型，测试逻辑也会存在差异，不过总体框架都是在源端仿真，在目标端监控。

13，SOME/IP有类似CAN的那种DBC吗？

目前SOME/IP主要的数据库格式是XML或者ARXML的，我们可以通过CANoe导入XML或ARXML文件来进行SOME/IP的service的仿真。

14，若服务端采用DDS方案，当前北汇信息的仿真方案是什么样的？

从22年第四季度新发布的CANoe16.0 SP3开始，CANoe支持相对通用的DDS的仿真，在这之前，我们使用开源或者 DDS 厂商提供的库，如 pydds，RTI Connector 等，来快速搭建 DDS应用程序，并在 CANoe 中编写接口来控制仿真节点，详情可以参考我们往期直播中DDS相关的内容。目前来看，由于对DDS标准理解及实现存在差异，所以DDS仿真往往需要分析所选择DDS协议栈的特点，进行一定的定制或适配的工作。