标签: 中间件

01 软件定义汽车对测试的影响 OEM和供应商之间传统的合作模式是由OEM释放技术需求，供应商按照需求进行软件和硬件实现，最终交付的是完整的软硬件系统 。随着集中式架构的逐步演进，这种合作模式正在被打破——标准化的高性能硬件平台、高级操作系统、中间件以及虚拟化技术得以应用，使硬件越来越抽象化，可以使应用程序脱离硬件，相对独立的进行开发和测试。这就允许ECU的开发可以进行更细致的分工，比如硬件由供应商A提供，操作系统和基础软件由供应商B进行开发或集成，应用软件由供应商C开发等等。可以说OEM和供应商的合作模式更灵活了。 OEM作为集成方，需要对来自不同供应商的模块进行“验收测试”，其目的是确认该模块是否按照需求进行实现。 根据需求类型可以将验收测试划分为三个部分：针对行业标准的验收测试，针对OEM企业标准的验收测试，以及针对车型项目需求的验收测试 。其中每个部分又根据测试方法的不同而分成两种类型，分别是静态审查和动态测试。 OEM和供应商的合作模式的改变对其中动态测试的部分的影响很大。进行动态测试时，测试环境需要为被测对象提供运行环境，并且能够仿真系统中的其他部分（或称残余系统）与被测对象的交互。在传统的OEM和供应商的合作模式下，供应商交付的是ECU实体，是包含软件和硬件的一整套系统，所以这时候所谓的动态测试指的就是ECU的HiL测试。 这种情况下ECU和残余系统的交互实现方案相对来说是标准化的，如CAN/LIN等总线信号以及I/O信号，目前有非常成熟的解决方案。而当OEM和供应商的合作模式改变之后，供应商交付物的形态更加多样，它可能是一个完整的ECU，或者一个操作系统，或者一个中间件，或者一个应用软件。这种多样性对动态测试环境的搭建带来了挑战，比如把应用程序作为被测对象，我们需要模拟被测对象依赖的全部环境，包括操作系统、依赖库和硬件等，十分困难。因为测试方案不像原来一样标准化了，测试系统很难像流水线一样生产出来。 新的模式下，我们需要和每一个客户深入沟通，明确测试对象是什么，边界在哪里，需求是什么，然后才能进一步评估，制定合适的测试方案 。 02 DDS中间件的测试策略 DDS中间件即是上述新模式下的一个典型例子，那么如何对这种产品进行测试呢？ 对于成熟的标准的软件产品，比如Linux，QNX等，我们其实并不需要对其核心功能进行太多测试，因为软件厂商或开发者会在产品开发过程中进行大量测试，市场和时间也能充分证明其质量的可靠性，这也是我们选择成熟软件模块的意义所在。然而，当我们把来自不同供应商的标准产品放到同一个系统或网络中协同工作时，必须考虑到它们之间是否兼容，也就是互操作问题。 那么对DDS来说，会出现互操作问题吗？这需要分情况讨论。 如果参与DDS通信的节点均是基于高性能SoC实现，并且运行标准操作系统（如Linux，QNX等），得益于DDS良好的可移植性和OS无关的特性，OEM可以采用成熟的商业产品或开源产品，然后部署在每个节点中。此时，若所有节点运行着相同的来源和版本的DDS中间件，显然这种模式下我们可以忽略互操作的问题。 然而，目前也有不少厂商正在尝试或已经实现向MCU中集成DDS中间件。受限于MCU性能和资源，DDS软件必须经过适当裁剪和优化才能在MCU的环境下运行。同时，MCU软硬件高度耦合，软件移植、复用和维护并不容易，这种情况下我们可能不能再将其视为成熟的软件模块，厂商因此需要对DDS软件进行大量的测试来保证DDS系统的质量。这种情况下， 为了避免与其他DDS软件互通时产生交互问题，互操作测试是必不可少的 。除了上述情况， 如果DDS中间件来源或版本存在差别，互操作性测试也将是十分必要的 。 除了互操作测试，另一个更重要的关注点是系统测试，具体来说是DDS中间件集成至目标平台后，会不会出现系统性问题。因为车载电子电器系统的计算平台五花八门，不同车型平台，不同项目，其搭载的系统平台（包括芯片架构，操作系统等）可能都有不同，甚至还有像基于MCU的DDS这种嵌入式软件，这些不同的平台相互的组合情况，DDS QoS配置组合情况，以及复杂的网络配置情况（如DDS-TSN），更难以计数。尽管DDS协议栈厂商可能会验证DDS产品与常见平台的兼容性，但是这很难覆盖所有可能的系统配置。所以我们认为在上述情况下对DDS中间件进行功能和性能测试是有必要的。 03 DDS协议测试工具介绍 基于上文对测试策略的讨论和实践总结，北汇信息与南京臻融软件科技合作开发了DDS协议测试套件，该产品能够在特定系统环境下验证DDS中间件的功能和性能，以及不同的DDS产品之间的互操作性。 南京臻融软件科技有限公司多年来专注于DDS产品与相关工具链的自主研发。 其产品ZRDDS是我国首个100%自主研制并被OMG组织官方认证的DDS产品。 图1：DDS协议测试的测试框架示意 图1显示了DDS协议测试的测试框架示意。上位机中运行的DDS Test Frame软件能够提供图形化的用户界面，具备测试用例管理，测试用例执行监控，测试报告生成，测试系统配置等功能。DDS Tester是专门为测试而开发的应用程序，在开始测试之前需要将此应用植入被测系统的每个节点内部。测试执行过程中，上位机将指令下发至DDS Tester，DDS Tester按照指令内容执行操作，比如调用某个应用程序接口，并将结果返回至上位机。其角色类似于TC8 TCP/IP测试中的Upper Tester。得益于DDS标准化的应用程序接口，理论上DDS Tester可在不同供应商的DDS产品之间轻松移植。 当然，DDS节点并不一定只通过以太网进行通信，其它还包括板载交换机的介质无关接口，共享内存，或者本地环回网络等等，测试环境可以根据系统的实际情况进行搭建。 DDS协议测试规范/用例完全自主设计开发，并且在多年的项目实践中不断进行迭代和优化，目前可以覆盖OMG DDS 1.4所定义的DCPS的核心功能，包括DDS应用程序接口的行为，QoS行为，以及性能测试，共计400余条测试用例，通过所开发的测试脚本套件，全部可实现自动化执行。 04 DDS协议测试实践 如下示例展示了DDS测试的执行过程。 图2：测试环境 图3：DDS Tester 运行界面 测试环境如图2所示，为便于展示，被测系统为Windows主机中运行的两台Ubuntu虚拟机，两台虚拟机中均运行DDS Tester。被测DDS为某DDS中间件产品，目前在汽车行业内已经得到较广应用。 在上位机软件DDS Test Frame中选择并执行测试用例，如图4所示。 图4：在DDS Test Frame中执行测试用例 我们以DisposeWTimeStamp_WrongHandle这条失败的测试用例来说明一下测试问题的分析步骤。测试步骤如下表所示。 在这条测试用例中，DDS Test Frame发送指令，使DDS Tester创建同一个Topic的两个数据，分别为Data1和Data2，Topic中指定“key”为键，不同键值的两个数据应视为同一个Topic的两个不同的实例。之后创建对应的DDS实体，包括DomainParticipant，Topic，Publisher，以及DataWriter，并使用Data1和Data2分别在DataWriter中进行注册，获得两个句柄Handle1和Handle2，分别指向key为1和2的两个Topic实例，Data1和Data2。当取消注册时，DDS Tester使用了错误的句柄，即使用Data1和Handle2来取消注册，按照OMG DDS标准的描述，这时DDS应向应用程序返回“PRECONDITION_NOT_MET”，但实际返回为“OK”。 通过以上示例我们可以看到，被测DDS并没有完全按照OMG DDS标准进行实现。在实际项目中，这样的偏离可能导致系统不能达到设计预期的功能或者性能。DDS作为支撑起整车分布式系统的重要的框架性软件，我们需要谨慎的评估每一个对需求的实现偏离，因为其影响的范围可能并不局限于某个应用程序或某个应用场景，它可能影响的是整个分布式系统。 DDS协议测试套件中的测试用例能够在实际系统环境下遍历几乎所有应用程序接口，以及所有可能出现的调用接口的参数组合情况，并且能够评估整个系统在不同场景下的性能表现，实现了对DDS中间件的全面和深入的测试和评估。 05 总结 本篇文章探讨了DDS中间件的测试策略，并介绍了北汇信息与臻融软件科技推出的测试套件，然后通过一个示例展示了测试执行和分析问题的过程。如果想了解更多关于DDS协议测试套件的信息，欢迎联系我们。 在过去的一年，除本文所介绍DDS协议测试，北汇落地实践了若干DDS相关的测试开发项目，包括基于OEM定制需求的DDS通信测试、S2S测试、DDS应用类测试，后续会有相关的文章持续与大家分享，敬请关注。

什么是 中间件（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

短信中间件是一种独立的系统软件或服务程序，分布式应用软件借助这种软件在不同的技术之间共享资源。通过本数据库接口，能使你现有的系统（如OA、CRM、ERP等系统）轻松实现无线办公功能，无论你用的是哪种开发语言（VB\VC\VFP\asp\jsp\java\pb\delphi...）支持GSM短信猫设备类型 短信猫中间件使用步骤：   第1步：正确连接手机、短信猫（或其它短信设备）到电脑 第2步：启动“Sms_Server.exe”，实际应用中可以让本接口程序开机时自动运行并最小化（见设置）。 第3步：正确设置端口参数，点击“启动连接”按钮（本步也可设为自动执行，见设置） 第4步：在您原有的系统中通过操作程序目录下的的数据库data.mdb（或SQL中的表）进行手机短信的收发，例如：要发送短信，只需在data.mdb的outbox表中添加记录，系统就会自动发送（详见下面说明）