标签: SOMEIP

什么是 中间件（Middleware） 在了解SOME/IP之前，我们先要了解“中间件（Middleware）”技术。简单来说，中间件是存在于操作系统和用户软件之间的一些中间层软件。它将操作系统提供的接口重新封装，并添加一些实用功能，以提供给用户软件更好的服务。 举例来说，在设计复杂的软件系统时，我们往往会设计很多互相独立的软件单元，一个很大的难题是如何在不同软件单元之间交换数据。对于开发者而言，如果在实现应用软件的同时，再把很多精力放在软件单元之间的通信上，会非常影响效率。于是我们可以设计一个“中间件”，用来管理不同软件之间的数据交互，这使得开发者不用去关心底层的通信，不同软件单元之间的“墙”变得透明。 中间件也有它的缺点，那就是体积和对计算资源的消耗。但是随着时代的发展，硬件的计算能力不断提高，所以中间件的缺点也就不那么明显了。为了简化复杂软件系统的开发（尤其是分布式系统），提高软件的可靠性，中间 件技术越来越不可缺少。除此之外，由于中间件使得用户软件和操作系统实现了“解耦”，也为测试工作带来便利。 在汽车电子领域也存在类似问题。在汽车电子的研发过程中，软件部分的占比越来越高，软件复杂度不断上升，当然ECU的计算能力也不断提升。类似传统的CAN通信——只是简单地把信号广播到总线上——越来越捉襟见肘，难以适应软件/ECU开发新要求。另外，不同的ECU可能有不同的软件架构（不同的操作系统），比如Linux、QNX或AUTOSAR，那么中间件技术将是这些不同系统之间重要的桥梁。 SOME/IP 简史 车载以太网技术伊始，AUTOSAR联盟最初的想法是直接移植现有的中间件解决方案，最好是开源的。列入备选清单的有Etch，Google Protocol Buffers，Bonjour等，理论上这些技术都可以移植到嵌入式系统这种计算能力有限的平台上，但最大的问题并不在于此。需要解决的问题是： 兼容性问题 我们知道AUTOSAR架构下有很多软件组件，它们已经实现了一些类似中间件的功能，并且可以通过专门的工具进行配置。为了避免不兼容，在集成中间件时必须绕过这些AUTOSAR 组件，或者使用完全相同的数据类型，而且需要对中间件进行重新拆分，才能“塞进”AUTOSAR的架构里。 开源软件的知识产权问题 虽然在备选清单上的这些方案都是开源的，但是当采用这些技术时却回避不了相应的知识产权及专利问题。这些开源软件的知识产权一般都掌握在 大型IT公司手中，存在不可预知的变数，即便解决了所有技术问题，也无法完全避开这些知识产权及专利问题。这也是AUTOSAR联盟决定开发一个全新的中间件解决方案（SOME/IP）的主要原因。 所以，SOME/IP天生就是为AUTOSAR量身打造的。从AUTOSAR 4.1起，SOME/IP就是AUTOSAR规范体系的一部分了。 SOME/IP的特点 为了满足汽车内的应用，SOME/IP进行了特殊的设计，特点如下： 面向服务的通信 轻量化 兼容AUTOSAR（唯一兼容AUTOSAR的中间件） 适配不同规模的计算平台 报头格式 图1：S OME/IP 报头格式 （图片引用自 《AUTOSAR SOME/IP Protocol Specification》 ） Message ID Message ID的前两个字节是服务（Service）的唯一识别号，定义为Service ID。每个服务都被分配了一个唯一的Service ID。服务包含了一系列的方法（Method），事件（Event）和字段（Field）。 他们都有一个唯一的Method ID，也就是Message ID的后两个字节，其中0 - 32767为方法（包括Method，Field.Getter以及Field.Setter），32768 – 65535为事件（包括Event和Field.Notify）。比如，多媒体系统中的“音乐播放器”可以作为一个服务“，切换到下一曲目”可以作为一个方法。 Length 包括Request ID，Protocol Version，Interface Version，Message Type，Return Code，Payload在内的长度，占用4个字节。 Request ID Request ID的前两个字节称为Client ID，可以用来识别一个具体的客户端。在整车范围内，Client ID必须是唯一的。比如用户想要通过多功能方向盘模块（客户端）向多媒体系统 （服务 端）发送请求来切换到下一首音乐，而后排娱乐影音控制面板也可以做出相同的请求，那么这两个请求就可以通过Client ID去区分。 后两个字节称为Session ID，可以用来识别来自同一客户端的多次请求。比如多功能方向盘模块（客户端）向多媒体系统（服务端）连续发送了多次请求，服务端可以通过这个字段来区分不同的请求。而服务端也会把Request ID复制到响应消息的相同字段中，这样客户端也能通过Request ID来判断收到的响应是针对哪个请求的。 Protocol Version SOME/IP的版本号，目前为1。 Interface Version 用来识别服务接口的主版本号，由用户定义。比如当服务增加了新的功能，或者发生变更，用户可以定义新的版本号，而客户端或服务端可以通过这个版本号来自动判断兼容性。 Message Type 用来识别不同的消息类型，目前存在五种类型，分别是： REQUEST(0x00) REQUEST_NO_RETURN(0x01) NOTIFICATION(0x02) REPONSE(0x80) ERROR(0x81) Return Code 用来指示请求是否被成功的处理了。 Payload 包含用户自定义的数据。 传输 层协议 SOME/IP 使用的传输层协议可以是TCP、UDP或SOME/IP TP。 如果传输的数据长度超过了1400字节，并且没有严苛的时间延迟要求，使用TCP传输 如果有时间延迟的要求（小于100毫秒），使用UDP传输 如果传输的数据长度超过1400字节，同时要求较小的延迟，可以使用SOME/IP TP 具体使用哪一种传输层协议跟具体的应用场景有关，如果以上提到的传输层协议均不能满足需求，用户还可以选择其他协议，比如1722等。 远程过程调用（R PC ） SOME/IP客户端和服务端之间的通信支持以下几种机制： 有响应的方法（Method with response） 客户端发送请求消息（Request）调用某一方法，服务端通过响应消息（Response）将结果返回给客户端。 图2： 有响应的方法 无响应的方法（Method fire & forget） 客户端发送请求消息（Request）调用某一方法，服务端不回复响应。 图3：无响应的方法 事件（Event） 客户端首先订阅（Subscribe）某一事件组（Event Group），当事件组中的包含的事件发生之后，服务端将通过Notification消息（Notify）通知客户端。Notification 消息不需要接收方进行回复，这一点有点像Fire & Forget消息。 图4：事件 字段（Field） 字段（Field）是客户端可以远程访问的服务端中的变量。 客户端可以通过远程调用Getter方法获取Field的值，也可以通过远程调用Setter方法设置Field的值。另外和Event相似，当客户端订阅了某个事件组，若事件组中包含的Field发生变化，服务端会主动的通过Notification消息通知客户端；当然，用户也可以选择周期发送Notification消息，这就和传统的周期性CAN报文很像了。 Field和Event的区别是：Field是一个持续存在的变量，比如多媒体音量，内灯亮度，车速，环境温度等；而Event指的是一个事件，事件没有发生就不存在，比如发生碰撞，出现故障等。 图5：字段 S OME/IP-SD SOME/IP-SD（Service Discovery，服务发现）是SOME/IP中的服务发现机制，客户端可以通过SOME/IP-SD来查找服务的位置，判断服务的可用性，或者订阅事件组等等，基于SD可以实现车内节点的“即插即用（Plug & Play）”。 SD在传统IT行业并不是一个新鲜事物，但是当这个机制被引入汽车电子领域时却引起了很多争议——因为车内环境是相对比较固定的，和互联网完全不同，我们完全可以将所有配置都固化以提高速度。但是需求和技术是不断动态交替发展的，我们不能以静态的眼光去评价一项技术存在的价值。所以究竟SD何去何从，现在还很难下结论，只能交给时间来验证。 S OME/IP 协议一致性测试 OPEN联盟发布的TC8是目前行业内关于车载以太网的标准测试规范之一，在2.0版本中加入了对SOME/IP协议的测试。 这里需要解释的是，SOME/IP本身只是中间件，它仅提供了若干接口，运行在其上的应用可以使用这些接口来完成通信。所以为了验证中间件的一致性，我们必须依赖应用来触发中间件产生特定的行为。这个应用可以是DUT自带的应用功能，或者是专门为了测试而开发的应用（也就是Test Stub）。按照应用类型的不同，在TC8中SOME/IP的测试分成以下两个部分： SOME/IP Server 这部分测试依赖DUT自身的SOME/IP应用功能，我们会在其中抽取一些典型的服务、方法，用来验证一些比较基础的内容，比如报文格式，基本的RPC和SD机制等。 在测试中，我们通过测试系统来仿真客户端发送请求，并接收DUT的响应。除此之外，在触发应用产生特定行为时，部分测试可能需要某些特殊手段。比如在触发DUT发送Event报文时，可能需要仿真I/O输入，或者开发一个测试用的软件接口。 下面我们通过一条典型测试用例，比如SOMEIPSRV_FORMAT_01，来具体说明测试过程（测试规范原文可参考TC8）： 启动DUT的服务 Tester监听DUT的发送端口 DUT发送Offer Service报文 确认DUT发送的Offer Service报文的Client ID字段为0x0000 停止DUT运行的服务 在这条测试用例中索引的需求为如图6所示，即在SD报文中不使用Client ID，必须将这个字段配置为0x0000。此条测试用例检验DUT发送的SD Offer Service报文中的Client ID字段是否和AUTOSAR规范中定义的是否一致。 图6： SOMEIPSRV_FORMAT_01 引用的A UTOSAR 需求 （图片引用自《 Specification of Service Discovery 》） 下图展示了通过思博伦的TTsuite 完成的部分SOME/IP Server测试报告与测试数据。 图7：部分SOME/IP Server测试报告与测试数据 这里需要注意的是，有些测试用例的执行有一些特殊要求，比如要求DUT实现多个服务，或同一个服务实现多个实例。但是DUT实现的应用和具体的业务流程有关，不一定能够满足这个要求，那么如果要执行这些测试用例，必须在原有应用上做一些修改，才能满足测试的前提条件。 SOME/IP ETS 这部分测试突破了被测控制器自身应用的限制，能够弥补上面提到的Server测试在覆盖度方面的不足。简言之，TC8定义了一个服务，称为ETS（Enhanced Testability Service）。 ETS中包含的各种Method，Event，Field等覆盖了SOME/IP所支持的全部数据类型，并包含了一些特殊的Method，比如resetInterface（用于重启ETS服务）等。 被测控制器集成了ETS后，我们能够对SOME/IP以及SOME/IP-SD进行充分而且全面的验证。关于ETS的更多信息，欢迎垂询北汇信息来进一步了解，我们可为您提供ETS集成的咨询服务。 我们同样选取一条典型测试用例，比如SOMEIP_ETS_21: echoINT8，来说明ETS的测试过程（测试规范原文可参考TC8）： “伪造”一个SOME/IP Request 报文，Method ID为0x000E，也就是echoINT8，在Payload中填入一个INT8类型的数据 发送“伪造”的SOME/IP Request 报文 DUT返回Response报文，Payload中的值和第一步中发送的值相同 这条测试用例索引的AUTOSAR需求如图8所示，即SOME/IP需支持的基本数据类型。在这条测试用例中验证了SINT8（INT8）类型。收到测试系统仿真的SOME/IP请求后，DUT首先会将请求中的Payload进行反序列化，如果得到了一个合法的INT8数据，那么再将这个数据通过序列化填入响应报文的Payload中，这样就验证了INT8类型的序列化功能。 图 8 ： SOMEIP_ETS_21: echoINT8 索引的A UTOSAR 需求 (引用自《 SOME/IP Protocol Specification 》 ) 下图展示了通过思博伦的TTsuite 完成的部分SOME/IP ETS测试报告与测试数据。 图9：部分SOME/IP ETS 测试报告与测试数据 总结 人们常把车载以太网看作是一种仅仅是带宽更大的车内总线技术而已，实际上车载以太网还带来了很多更重要的变革。 比如车载以太网提供的“面向服务”的架构思想。在此之前只有MOST总线才有这种设计，而受制于高昂的成本以及封闭性，目前仅有少数几家厂商在信息娱乐域使用了MOST总线。 站在技术的角度，MOST总线使用面向服务的设计不是没有原因的，因为信息娱乐域所需要的软件接口和数据类型往往十分繁杂，而近些年来在非信息娱乐域的控制器网络中，类似的情况也逐渐显现，而面向服务的架构，包括远程过程调用（RPC），能够很好地简化系统设计。 目前除了发展不太乐观的MOST，其他几乎全被面向信号的通信方式独占了，包括CAN，LIN等。但是近些年来兴起的这些新需求，类似CAN的这种面向信号的通信方式已经越来越不适用了。随着汽车电子系统的功能不断丰富以及车载以太网的应用，我们相信，面向服务的通信将是未来。 部件级SOME/IP一致性测试在测试条件和方法上与传统车载通信测试存在一定差异，而且TC8测试规范以及测试工具链都处于迭代和完善中，给测试人员带来了多方面的挑战。测试过程中的问题需要结合数据进行分析，需不断积累实践经验，这是笔者比较深刻的体会。 另外，从部件级SOME/IP定制应用测试、从系统级和实车级验证的角度，SOME/IP测试已将传统网络测试和功能测试的边界模糊化，这也是需提前储备知识应对的新局面。 参考文献： 《 Automotive Ethernet 》 KIRSTEN MATHEUS and THOMAS KÖNIGSEDER 《 AUTOSAR SOME/IP Protocol Specification 》 《 AUTOSAR SOME/IP Service Discovery Protocol Specification 》

DDS概述 DDS是OMG在2004年发布的中间件协议和应用程序接口（API）标准，它为分布式系统提供了低延迟、高可靠性、可扩展的通信架构标准。DDS目前在工业、医疗、交通、能源、国防领域都有广泛的应用。OMG（Object Management Group）成立于1989年，是一个开放性的非营利性的计算机行业标准联盟。OMG多年来致力于为工业分布式系统提供可互操作的，可移植的，可复用的软件标准。它的成员包括IT行业的设备供应商，终端用户，政府部门，以及学术组织等。很多我们熟知的标准都来自OMG，比如UML（Unified Modeling Language），CORBA（Common Object Request Broker Architecture）等。 在关于SOME/IP的文章中我们曾简单解释过中间件的概念，即在分布式系统中，中间件是位于操作系统和用户应用程序之间的软件层，它将操作系统提供的资源进行抽象和封装，为应用程序提供各种各样的高级的服务和功能，比如通信或数据共享。中间件的存在简化了应用程序开发者的工作，这使他们能够将注意力放在应用程序本身上，而不必在不同应用程序之间或不同系统之间的数据传输上花太多精力。 DDS最重要的特性是以数据为中心，这是与其他很多通信中间件不同的地方。必依赖其他的上下文信息。同时，DDS能够按照用户定义的方式自动地进DDS的数据共享以Topic为单元，应用程序能够通过Topic判断其所包含的数据类型，而不行存储、发布或订阅数据，使应用程序能够像访问本地数据一样去写入或者读取数据。 DDS实现的数据共享可以理解成一个抽象的“全局数据空间”，任何应用程序，不论开发语言，或者运行的操作系统类型，都可以通过相同的方式访问这个“全局数据空间”，就好像访问本地的存储空间一样。当然“全局数据空间”仅仅是一个抽象的概念，在实现时仍然是分别存储在每个应用程序的本地空间当中。在系统运行时，数据是按需传输或存储的，数据的发布者仅仅发送对方需要的数据，而订阅者仅接收并存储本地应用程序当前需要的数据。 DDS还提供了非常灵活的QoS（Quality of Service）策略，以满足用户对数据共享方式的不同需求，比如可靠性，故障处理等等。针对数据安全性要求比较高的系统，DDS还提供了细颗粒度的数据安全控制，包括应用程序身份认证，权限控制，数据加密等等。 类似于SOME/IP-SD，DDS提供了对数据发布者和订阅者的动态发现机制，这意味着用户不必去配置通信节点的地址或其他属性信息，因为他们在运行的过程中会自动发现对方，并自动完成相关配置，即实现了“即插即用“。 DCPS模型 DCPS（Data-Centric Publish-Subscribe）是DDS标准中定义的以数据为中心的订阅-发布模型。在这个模型中，向“全局数据空间“写入数据的一方称为 Publishers 和 DataWriter ，同样地，在”全局数据空间“中读取数据的一方称为 Subscriber 和 DataReader ，下图中展示了它们之间的逻辑关系。除了DCPS模型，DDS标准中还定义了一套完整的应用程序接口（API），该接口标准是与平台无关的，这意味着不论应用程序使用什么开发语言，或运行在什么平台之上，只要DDS中间件的实现符合DDS标准，那么相关的应用程序即可实现不同平台间的移植。 数据的发送过程，简单来说就是应用程序调用DataWriter对象提供的write方法，把数据传递给Publisher对象，而Publisher负责将数据在网络上发送出去。 数据的接收过程，简单来说就是Subscriber负责从网络上接收数据，并把它存储在对应的DataReader中。应用程序可以为对应的DataReader注册一个回调函数，或者使用DataReader提供的read和take方法来轮询DataReader中的数据。 具体来说，DataWriter在逻辑上从属于Publisher，并受Publisher管理。一个DataWriter只能从属一个Publisher，而Publisher可以拥有多个DataWriter。每一个DataWriter都绑定一个Topic，所以同一个应用程序中可能存在多个DataWriter和Topic，此外还可以为同一个Topic绑定多个DataWriter。 同理，DataReader在逻辑上从属于Subscriber，并受Subscriber管理。一个DataReader只能从属一个Subscriber，而Subscriber可以拥有多个DataReader。每一个DataReader都绑定一个Topic，所以同一个应用程序中可能存在多个DataReader和Topic，此外还可以为同一个Topic绑定多个DataWriter。 这个DSCP模型的工作过程实际上很像日常生活中报纸的发行过程。我们以《人民日报》为例，其中Topic就是“人民日报“，数据即报纸中的文字或者图片，DDS中间件负责报纸发行的所有中间环节和渠道，包括报纸的印刷，存储，运输等等。 QoS策略 用户可以通过设置QoS策略来控制数据在应用程序之间共享的方式，每个DCPS实体，包括Topic，DataWriter，Publisher，DataReader，Subscriber等，都能够独立配置相应的QoS策略。 下面是几种常用的QoS策略： DEADLINE 如果希望某个Topic能够周期更新，可以设置DEADLINE属性。在数据的发布方设置DEADLINE，这意味着应用程序必须以小于DEADLINE的周期去更新Topic，而在数据的订阅方设置DEADLINE，这意味着数据的发布方必须以小于DEADLINE的周期去发布Topic。 LIFESPAN 通过设置LIFESPAN，可以使DataWriter写入的每个数据样本都有一个关联的“到期时间”，超过该时间后，该数据样本不再传送给任何应用程序，并且这些数据将从DataReader缓存中清除。 HISTORY 设置HISTORY属性可以让DataWriter保存并发送旧的采样数据，新的DDS节点如果订阅了相关的Topic，它不仅能够接收到数据的当前值，也能收到一部分历史值，从而了解数据近期的变化趋势 RELIABILITY 为DataWriter设置RELIABILITY属性，可以使数据实现“可靠”的传输，当出现通信错误导致数据采样没有被接收到时，DataWriter会持续重传，直到所有数据被正确接收。 RTPS协议 DDS的标准中并不包含传输层协议，所以不同的DDS实现可能使用不同的消息交互方式，甚至使用不同的传输协议，这就可能导致来自不同厂家的DDS实现是不能互操作的。而随着DDS在大型分布式系统中的应用越来越广泛，制定统一传输层标准的需求越来越强烈。 RTPS（Real-Time Publish Subscribe）就是在此背景下诞生，它主要为了满足工业自动化领域大规模分布式系统的需求，也能够很好的契合DDS协议特点。规范中定义了消息格式，各种使用场景下的消息交互方式等。它的主要特点包括： 1. 提供容错机制，避免单点故障 2. 高扩展性，支持“即插即用” 3. 模块化设计，针对计算能力较弱的平台，可 只实现R TPS 的一个子集功能，并且不会出现兼容性问题 RTPS基于多播、无连接的传输模型，这个模型可以映射到不同的传输协议上，如UDP/IP（这也是目前RTPS标准中唯一被标准化的传输协议）。除此之外，基于TCP的传输，以及基于TSN（Time-Sensitive Networks）的传输的相关标准也在制定中。很多DDS的实现支持除UDP/IP之外的多种传输协议，但并没有遵循统一的标准，因此不同供应商的DDS实现之间可能存在互操作问题。 DDS与SOME/IP DDS与SOME/IP存在诸多不同，但是需要强调的是，二者的设计需求不同，目标应用场景不同，所以我们不能简单的判定孰优孰劣。在选取技术方案时，应考虑具体的应用场景，结合各个方案的功能，性能，成本等多个维度，才能做出合理的选择。我们可以从以下几个方面进行对比，为读者提供参考。 l 通信模式 SOME/IP是面向服务的通信，服务端将方法和数据以服务的形式暴露给其他节点。而DDS最大的特点是以数据为中心，侧重数据的分发，这种模式其实很像传统的面向信号的通信，只不过DDS更灵活，功能更强大。 l 应用程序接口 SOME/IP协议标准中没有定义标准API，所以基于不同SOME/IP实现的应用程序一般是不能互相移植的。DDS制定了多种编程语言的标准API，因此DDS应用程序理论上能够在不同的DDS实现上进行移植。 l 传输协议 SOME/IP支持UDP和TCP，此外，从AUTOSAR 4.3开始支持对大于1400字节的UDP数据进行分段传输，即SOME/IP-TP。DDS则使用前面提到的RTPS协议，至少支持UDP/IP，而很多DDS实现还支持其他传输协议，如TCP。 RTPS实现了与传输无关的可靠性和分段协议，理论上可在任何传输形式之上运行。 l 安全性 SOME/IP本身并不提供数据安全的控制，所以它的安全性依赖于传输协议，比如基于IPsec或TLS上运行。DDS当然也可以在IPsec或TLS上运行，但这并不是首选的方式。DDS提供多种插件，实现了对安全性的更细粒度的控制，比如数据的加密传输，读写权限控制，应用程序身份认证等，并且DDS安全机制与传输协议无关，因此使用任何传输协议都不影响安全机制的实现。 l QoS支持 DDS提供多种QoS策略，而SOME/IP本身不提供QoS的支持，因此只能在传输协议或者应用程序中实现。 l 资源需求 DDS在诸多方面提供了更丰富的特性，这自然就导致了在资源需求上，比如内存占用，比SOME/IP要大得多。 l AUTOSAR平台支持 AUTOSAR Adaptive平台从2018年起开始支持对DDS的绑定，Classic平台目前还并没有支持DDS绑定的规划。而SOME/IP是针对汽车应用定制的，可以无缝部署在AUTOSAR Adaptive和Classic平台中。 DDS测试 OMG组织并不提供DDS软件实现，各厂商可以根据该标准实现自己的DDS。我们可以在DDS官网（https://www.omg.org/dds-directory/）查询DDS的供应商列表，用户可以按照自己的具体需求进行选择。这种由第三方供应商提供的预构建软件，一般称为商业现货软件（COTS）。对于COTS软件，我们在测试策略的选择上与自行开发的软件是不同的。一般来说，COTS软件往往是经过市场和时间验证的产品，其核心部分是比较稳定的，并且已由供应商进行了单元和功能测试。因此我们可以减少对COTS软件本身功能的重新测试，应该更侧重在系统集成测试或性能测试等测试类型上。 下面为大家展示了一个简单的DDS硬件在环（HIL）测试环境。 Figure SEQ Figure \* ARABIC 3 DDS 测试环境示例 为了保证ECU的正常运行环境，并监测或触发ECU的某些行为，我们需要仿真ECU的外围IO信号或者总线信号，这时我们可以借助Vector提供的丰富的IO激励和测量板卡，如VT系统，以及总线接口卡，如VN系列硬件等工具。在测试环境中，我们还需要仿真DDS Writer或者Reader，来发布或订阅ECU的DDS数据，以此来验证被测节点的变量范围，非法值的错误处理机制等。由于CANoe暂不支持DDS节点的仿真功能，我们可以使用开源或者DDS厂商提供的库，如pydds，RTI Connector等，来快速搭建DDS应用程序，并在CANoe中编写接口来控制仿真节点。 测试用例方面，可使用vTESTstudio进行测试用例的设计和管理。vTESTstudio不但提供了图形化和图表化的测试用例设计方式，而且提供多种基于测试参数自动生成测试用例的功能，并支持模糊测试，能够极大的提高测试用例的开发效率和测试覆盖度。 总结 自从汽车在十九世纪末被发明以来，技术的创新就从未停止过。汽车作为一种消费产品，已经从最初的交通工具变成了一种生活方式，正如今天的智能手机不再仅仅是一个打电话的工具而已。通过持续的技术创新和融合，汽车变得更安全，更人性化，更智能，更互联。DDS的引入，无疑是在汽车和互联世界之间打开的另一扇大门。至于DDS能否在汽车行业内得到更广泛的应用，还需要更全面和更细致的评估，但我们期待DDS以其丰富的特性和功能，能够为汽车应用领域带来更多可能性，帮助应对汽车智能化和互联化道路上的更多挑战。 索引文档 Data Distribution Service (DDS) Version 1.4 DDS Security Version 1.1 The Real-time Publish-Subscribe Protocol DDS Interoperability Wire Protocol (DDSI-RTPSTM) Specification Version 2.3

“中间件”是一个比较抽象和宽泛的概念，它并不特指一种具体的技术，其概念起源于复杂分布式软件系统的开发，其目的是实现软件组件之间进行数据交换，使软件组件之间实现解耦。这种数据交换通常是通过网络进行，而中间件的任务就是确保网络本身对软件组件是透明的。比如我们所熟知的SOME/IP就是一种典型的中间件技术实现。使用中间件能够简化系统的开发，提高管理和测试效率。 车载网络通信的中间件有其特殊之处。车载软件系统可能十分复杂，这些系统可能分布在一个ECU的不同模块里，或在同一个ECU模块的不同进程中，也可能分布在不同ECU中。这些不同的模块或不同的ECU可能使用不同的软件架构和操作系统，比如符合POSIX要求的类Unix操作系统（如Linux和QNX），Classic AUTOSAR系统，Adaptive AUTOSAR系统等，中间件在这些不同的系统之间起到了重要的桥梁作用。 SOME/IP是最早应用在汽车上的通信中间件，在2014年由宝马率先实现了量产。但是近年来汽车行业对中间件技术的探索并未停止，目前主要有两个方向。 一是对SOME/IP进行功能上的扩展 ，其主要的思路是给SOME/IP添加TLV（TypeLength Value）支持，以实现更好的灵活性。我们知道SOME/IP的序列化采用了比较静态的定义方式，比如SOME/IP的Payload中的参数的类型，参数的顺序，字节序等，都是在配置文件中静态定义的，那么应用程序在使用这些类型时，必须要严格遵循配置文件中的定义去解析数据。所谓TLV，简单来说就是给每个参数添加一些附加的“标签”信息，比如类型信息，长度信息，这样应用程序可以依赖这些“标签”信息动态解析参数。对TLV的支持将使软件系统进一步解耦，让应用程序以更灵活的方式使用SOME/IP。但是灵活性和高效率往往是鱼与熊掌不可兼得，引入TLV的缺点也是显著的，额外的“标签”信息将占用更多的Payload空间，这会降低带宽的利用率，对实时性有一定影响（尤其是对于资源有限的小型ECU）。 二是DDS（Data Distribut ion Service） 。DDS是目前国防，航空等领域广泛应用的通信中间件技术，我们曾在往期文章中介绍过。DDS的核心规范有两个，分别是DDS specification，以及 DDSI-RTPS specification。DDS specification定义了DDS的应用程序接口和基本行为，DDSI-RTPS specification定义了DDS的传输实现，目的是实现不同DDS产品的互操作性。除此之外，DDS在2017年发布了DDS-RPC规范，使得DDS能够基于发布-订阅模型实现远程过程调用（RPC），满足SOA架构的需求。 DDS和SOME/IP是在不同的应用场景和不同的需求下诞生的技术，所以它们之间注定有很大的区别。DDS有着更丰富的特性，尤其是对QoS的支持。但是相对于SOME/IP，DDS也有显著的不足。首先，RTPS消息头部十分冗长，这会降低传输效率和实时性。另一方面，汽车作为一个相对封闭的系统，为了降低功耗，经常需要频繁的唤醒和休眠，这就要求系统有非常快的启动速度，而DDS并不是为这种场景设计的，DDS可能必须经过深入的优化才能满足严苛的时间要求。最后，DDS目前只能在Adaptive AUTOSAR框架下运行，Classic AUTOSAR目前并不支持，尽管有厂商使用复杂驱动（DDS）的方式在Classic AUTOSAR平台集成了DDS，但这并不是一种完美的解决方案。首先Classic AUTOSAR平台往往资源有限，同时又有严苛的实时性要求，在其之上运行DDS显得代价高昂；其次，通过复杂驱动意味着和硬件强相关，这会丧失软件的可移植性，对于DDS这种基础软件组件，厂商要付出更多的开发、测试和维护的成本，这实际上也不符合AUTOSAR的初衷。 尽管目前有一些技术问题需要解决，但不可否认的是，DDS依然前途光明，国内很多OEM已经将DDS作为了下一代电子电器架构的基础通信技术，甚至已经实现了量产。 DDS 的测试策略和方案探讨 DDS 协议一致性测试 DDS本质上一种传统的工业基础软件，用户购买了软件，然后在系统里每个节点上进行“安装”。所以我们可以看到很多商用的DDS软件产品，在其内部的测试流程中，有一个很重要的环节是“安装测试（Install tests）”，目的是验证DDS产品在常见平台的兼容性。而用户在集成了DDS之后并不会过多的对DDS产品本身进行验证，更侧重应用层测试。所以这就造成了目前DDS生态里缺少像TC8这种行业内标准化的测试规范，以及相应的测试工具。 车载电子电器系统的计算平台五花八门，不同OEM，不同车型平台，不同项目，其搭载的系统平台（包括芯片架构，操作系统等）可能都有不同，这些不同的平台相互的组合情况更难以计数。这种背景下，只依赖DDS产品供应商内部的“安装测试”似乎显得不足。 此外，正如上文所讨论，为了让DDS的功能和性能更符合车内通信的要求，用户需要对DDS产品进行定制裁剪和优化，尤其是针对非标准计算平台实现的DDS（如Classic AUTOSAR平台），在这个过程中用户需要对产品进行充分的测试，才能保证裁剪或优化后的软件仍然是可靠的。 不同DDS产品之间的互操作也是不可忽视的问题。OMG组织并不提供DDS软件实现，各厂商可以根据该标准实现自己的DDS。尽管DDS发布了DDSI-RTPS规范来保证不同DDS实现之间的互操作性，但是这里提到的“互操作性”，可能并没有经过充分的测试和验证。尽管软件开发者可能会在内部的产品测试阶段进行与其他产品的互操作测试，但是这很难覆盖DDS的所有功能特性，也很难覆盖目前市面上所有DDS产品的所有可能出现的组合。此外，DDS的软件实现经常与OMG规范产生偏离，比如DDS实现不支持某些OMG规范中的特性，或者DDS实现中增加了OMG规范中没有要求的额外的功能特性，这种情况可能也会引发互操作问题。基于这种考虑，用户根据实际情况对系统进行针对性的互操作测试也许是更好的选择。 为了满足这种需求，北汇信息正与合作伙伴开展DDS一致性测试测试包的开发工作，以实现DDS产品在特定平台下的功能特性一致性验证，具体包括： ▲ API 接口测试 ▲ DDS 基本行为测试 ▲ QoS 测试 ▲ DDS Discovery 测试 ▲ X-Types 测试 ▲ DDS-Security 测试 ▲ 互操作测试 ▲ 性能测试 DDS 配置测试 DDS一个很大的特点是支持“开箱即用”，即用户不需要对系统做任何特殊配置即可使用DDS，比如IP地址，端口号，DDS系统中每个Participant，DataReader和DataWriter的ID等等，所有的这一切都是由DDS/RTPS进行自动配置，动态的发现系统里的节点。用户只需要在IDL文件中定义自己的类型，就可以进行应用程序的开发，这对网络架构设计者和应用开发者都非常的友好。 为了满足不同系统对中间件功能和性能不同的需求，DDS也提供了多种方式允许用户对DDS的行为特性进行进一步调节，比如QoS配置，RTPS通信层面的配置等。如果说用户进行了这些配置工作，我们需要设计测试方案来验证这些配置的一致性。这一部分可基于Vector CANoe option Ethernet，通过编程和定制开发来实现。使用Vector提供的多种以太网接口卡，编写脚本进行RTPS消息的解析，并从中提取这些配置信息，验证其与用户配置规范的一致性。 图1 DDS配置测试部分条目参考 图2基于CANoe实现的DDS配置测试工程示例 DDS 服务接口测试 服务接口测试的核心工作是服务请求的仿真，这意味着测试工具要集成DDS中间件，使其能够仿真客户端的行为。遗憾的是，截至此文撰写时，行业内尚无针对DDS服务测试的成熟的货架式工具。 北汇信息基于积累的工程经验，通过定制化开发，目前可提供多种服务仿真方案以完成DDS服务接口测试。比如利用CANoe的Socket或FDX接口，或其他测试框架（如Robot Framework和ECU TEST），开发“DDS适配器”，来完成服务的仿真和测试。 图3 基于CANoe FDX实现的“DDS适配器”示意图 总结 随着软件定义汽车和车载以太网的快速发展，传统IT行业很多分布式系统技术也逐步的运用到汽车中，比如我们今天提到的中间件技术。然而引入这些不同的技术时，我们必须意识到，汽车除了是一个智能终端设备，它的本质属性是交通工具，在把汽车交付到消费者手中之前，厂商应进行充分的验证和测试，保证产品的质量。 本篇文章介绍了中间件的概念，以及SOME/IP，DDS等技术，结合北汇信息多年来在电子电器测试方面的经验，对DDS以及基于DDS的SOA系统的测试策略进行探讨，并简单介绍了北汇信息提供的测试方案，后续将给大家带来DDS一致性测试等内容的专题介绍。