检察院网站建设方案,制作复杂的企业网站首页,文山专业网站建设哪家好,荆门网站制作公司1 往期回顾 通过《DDS数据分发服务—提升汽车领域数据传输效率》和《DDS—DCPS测试策略介绍及实际案例分析》这两篇文章的介绍#xff0c;相信广大读者对Data Distribution Service(DDS)协议和Data Centric Publish Subscribe(DCPS)测试有了基本了解#xff1a;DDS协议致力于…1 往期回顾 通过《DDS数据分发服务—提升汽车领域数据传输效率》和《DDS—DCPS测试策略介绍及实际案例分析》这两篇文章的介绍相信广大读者对Data Distribution Service(DDS)协议和Data Centric Publish Subscribe(DCPS)测试有了基本了解DDS协议致力于实现功能开发和通信解耦使开发人员更专注处理获取信息而不必维护频繁更新的通信节点DCPS测试则是为了保证不同供应商协议栈的API接口行为符合DDS协议规定简化应用层代码的移植难度。而今天的主题则是The Real-time Publish-Subscribe Protocol DDS Interoperability Wire Protocol Specification(RTPS)的一致性测试将通过一个测试用例来带领大家了解RTPS的报文识别、通信流程和测试过程。
2 RTPS一致性测试
RTPS一致性测试主要测试不同供应商开发的DDS协议栈能否按RTPS协议规定的方式进行通信保证其具有互操作性。那么说到测试首先就要介绍一下测试环境如图1所示 图1 开发环境示意
这个环境中CANoe作为测试节点和以太网网关节点负责控制测试流程、报告生成以及错误注入等功能。在Ubuntu中的DDS UT作为Tester控制器/Ubuntu作为Device Under Test(DUT)两者根据CANoe的指令相互协作完成测试流程 。
2.1测试用例简介
测试目标
验证DUT作为可靠的Reader时当通信过程中发生数据丢失其请求重新发送数据的操作是否正确。
测试步骤
DUT创建可靠的RTPS ReaderTester创建可靠的RTPS WriterTopic与DUT相同启动Tester和DUT待其建立连接后Tester向DUT发送5个DATA消息其中seq_num 3的DATA消息丢失期待DUT发送ACKNACK请求重传seq_num 3的DATA消息检查并记录DUT收到的消息。
通过条件
Tester收到DUT发送的ACKNACK请求重传seq_num 3的DATA子消息DUT收到所有seq_num 1 - 5DATA子消息
测试环境为图1所示其中Tester的IP 192.168.200.110和CANoe部署在同一台电脑上DUT的IP 192.168.100.60部署在另一台电脑上两者通过VN5650交互通信报文而CANoe负责给Tester和DUT下发指令、转发报文、生成测试报告以及错误注入。
2.2测试执行
测试环境按图1部署好后运行CANoe脚本开始测试整体测试结果如图2所示 图2 测试结果展示 图2a是CANoe的以太网Trace窗口截图。图2b是CANoe的测试用例截图采用xml测试节点选中指定测试用例执行即可。
图2c和图2d分别是Tester和DUT的执行结果截图图中展示了测试开始时两端的DUT分别接收了CANoe发送的测试指令包括执行发送数据的间隔、数据个数、数据长度和服务质量Quality of Service (QoS)等。Tester在测试中扮演Writer发送5条DATA数据长度为10byte间隔1000ms并指定QoS的RELIABILITY RELIABLE、DURABILITY PERSISTENT DUT为ReaderQoS与Writer相同测试过程中分别在终端打印了发送和接收的数据同时DDS UT还会将发送和接收的数据分别发送给CANoe这些数据用来判断测试结果最后测试执行完成后分别释放了Writer和Reader。
2.3 报文分析
这里采用Wireshark为大家展示测试过程中的RTPS报文该测试用例的整个报文交互如图3所示: 图3 测试全过程的报文交互流程
图中的INFO_DST、HEARTBEAT、ACKNACK等子消息是非常好理解的指的就是RTPS协议所规定的子消息但是对于DATA消息大家可能会比较疑惑为什么会有这么多DATA子消息DATA(p)、DATA(r) 、DATA(w) 、DATA(m)、DATA、DATA(r[UD])、DATA(w[UD]) 、DATA(p[UD])都是什么作用Wireshark是如何识别并标记这些子消息的
网上介绍这方面的资料很少因此小编在这个方面还是遇到一些坎坷所以先简单介绍下如何解读Wireshark的RTPS报文以及Writer和Reader的交互流程希望可以给读者一些启示。以下是小编对协议的个人理解难免有误欢迎大家在评论区交流共同进步。
对于以上问题首先要回到RTPS协议本身在RTPS[1]协议的9.3.1.3 Predefined EntityIds章节规定了一些entity表1节选了部分Entity。 Entity Corresponding value for entityId_t (NAME value) SPDPbuiltinParticipantWriter ENTITYID_SPDP_BUILTIN_PARTICIPANT_ANNOUNCER {{00,01,00},c2} SPDPbuiltinParticipantReader ENTITYID_SPDP_BUILTIN_PARTICIPANT_DETECTOR {{00,01,00},c7} SEDPbuiltinPublicationsWriter ENTITYID_SEDP_BUILTIN_PUBLICATIONS_ANNOUNCER {{00,00,03},c2} SEDPbuiltinPublicationsReader ENTITYID_SEDP_BUILTIN_PUBLICATIONS_DETECTOR {{00,00,03},c7} SEDPbuiltinSubscriptionsWriter ENTITYID_SEDP_BUILTIN_SUBSCRIPTIONS_ANNOUNCER {{00,00,04},c2} SEDPbuiltinSubscriptionsReader ENTITYID_SEDP_BUILTIN_SUBSCRIPTIONS_DETECTOR {{00,00,04},c7} BuiltinParticipantMessageWriter ENTITYID_P2P_BUILTIN_PARTICIPANT_MESSAGE_WRITER {{00,02,00},c2} BuiltinParticipantMessageReader ENTITYID_P2P_BUILTIN_PARTICIPANT_MESSAGE_READER {{00,02,00},c7}
表1 EntityId_t values fully predefined by the RTPS Protocol
其实这些Predefined Entity由上至下发送的DATA就分别对应Wireshark报文中的DATA(p) 、DATA(w) 、DATA(r)和DATA(m) DATA(*[UD])指的是这些Entity释放时的通知消息而DATA指的是由User-defined Entity发送的消息下面分别介绍下这些DATA的作用。
DATA(p)主要实现协议规定的Simple Participant Discovery Protocol(SPDP)发现流程负责广播自身的单播、多播IP地址和端口号等信息Entity发现后就进入Simple Endpoint Discovery Protocol(SEDP)流程。
DATA(w)由Writer的SEDPbuiltinPublications Entity发出实现SEDP发现流程向Reader公布自身的QoS、Topic等关键信息同理DATA(r)由Reader的SEDPbuiltinSubscriptions Entity发出向Writer公布自身的QoS、Topic等关键信息如果两者Topic相同并且QoS兼容则可以互相发现并通信。
DATA(m)由BuiltinParticipantMessage Entity发出声明自身的活性并公布LIVELINESS QoS的LivelinessQosPolicyKind用于声明存活性的管理归属如图4所示 图4 DATA(m)细节
图中的LivelinessQosPolicyKind 0x0001表示DDS 会自动管理存活状态无需在应用程序中显式地声明指主动调用assert_liveliness()其存活状态。
DATA指的是由User-defined Entity发送的消息Writer向Reader发送Topic的应用数据。
DATA(*[UD])指的是这些Entity释放时的通知消息判断的依据是其inlineQos的flags标志位是否将Unregistered和Disposed置1如图5所示 图5 DATA(r[UD])细节
当我们知道了这些DATA的含义也就知道了典型的RTPS实体是如何相互发现并进行信息交互主要流程如下 成功创建Writer或Reader后进入SPDP阶段分别通过广播的DATA(p)公布自身的Ip和端口号等信息互相发现后进入SEDP阶段通过DATA(w)和DATA(r)交换彼此的QoS和Topic等信息匹配后Wrtier通过DATA向Reader发送Topic的应用数据。如果是可靠通信则Reader必须发送ACKNACK进行确认当报文丢失则通过ACKNACK通知丢失报文的序号Writer会重传丢失的报文同时在约定的时间内通过DATA(m)互相声明存活性当一方程序退出时发送DATA(*[UD])通知对端自身下线了然后结束通信流程。
再回到这个测试用例当知道了DATA报文的“隐藏”含义我们也能通过报文分析整个测试流程。由图3可知当Writer和Reader相互发现并匹配后Writer向Reader发送总计5条DATA消息仔细观察可以发现图中共有6个DATA其中重传了seq_num 3的DATA子消息当发送完第五个子消息后Writer和Reader分别下线并结束测试。
2.4 测试结果
测试完成后CANoe会自动生成测试报告通过报告能更加直观地查看测试过程。我们的脚本实现了全部子消息的报文解析为了方便测试人员清晰的看出测试要点和测试步骤这条测试用例选择性的解析了DATA和ACKNACK如图6所示 图6 CANoe测试报告
CANoe作为网关对通信报文进行转发和错误注入测试过程中转发普通的RTPS报文同时只拦截了第一个seq_num 3的DATA子消息时间戳5.538000模拟了通信过程中报文丢失的情况。当DUT发现seq_num 3的DATA子消息丢失后立刻发送ACKNACK时间戳5.642000消息进行重传Tester收到后立刻重传了“丢失的”DATA消息时间戳5.644609。当DUT收到DATA消息后向CANoe发送了接收到的消息序列时间戳5.644609脚本会验证接收到的是否和发送的时间戳5.537761发送消息时Tester也会把消息序列发送给脚本一致如果一致则该测试用例pass否则fail。
3 结语
由于篇幅有限RTPS相关测试就为大家介绍这些实际测试覆盖报文格式、一致性、QoS等方面总计200多条测试用例能全面测试DDS协议栈的互操作性提前排除通信隐患为汽车通信安全作出保障。 [1] The Real-time Publish-Subscribe Protocol DDS Interoperability Wire Protocol (DDSI-RTPSTM) Specification Version 2.5
