CN117194160A - 监控dds的方法、装置、设备、介质及车辆 - Google Patents

Abstract

本公开涉及一种监控DDS的方法、装置、设备、介质及车辆，涉及数据监控技术领域，其中，方法包括：响应于监控工具的启动操作创建参与者，基于用户对监控工具界面的选择操作获取用户选择的实体及监控指标；根据所述用户选择的实体及监控指标在所述参与者中创建订阅者，所述订阅者中包括一个或多个数据读取者；通过预设的内建主题获取所述订阅者需要获取的监控数据；所述预设的内建主题通过函数调用的方式获取。本申请通过内建主题实现对DDS的监控，避免一次性传输所有数据类型的大数据包，减少对运行时的影响，同时降低带宽占用。

Description

监控DDS的方法、装置、设备、介质及车辆

技术领域

本公开涉及数据监控技术领域，尤其涉及一种监控DDS的方法、装置、设备、介质及车辆。

背景技术

数据分发服务DDS是对象管理组织在HLA及CORBA等标准的基础上制定的新一代分布式实时通信中间件技术规范，DDS采用发布/订阅体系架构，强调以数据为中心，提供丰富的QoS服务质量策略，能保障数据进行实时、高效、灵活地分发，可满足各种分布式实时通信应用需求，DDS作为一种轻便的、能够提供实时信息传送的中间件技术对于DDS的监控是十分重要的。

现有技术中，对DDS的监控主要通过RTI方式，RTI方式通过内建Topic监控所有实体的指标，提前监控所有指标，然后通过优先级判断决定是否上传至工具端。这种监控所有数据后在对数据进行整体提取分析的方式即需要大量的计算空间大量数据进行集中运算造成计算资源的浪费，且监控实时性也较差检测结果具有滞后性。且RTI的自定义内建Topic是以实体为单位，即每个实体的N个统计指标为一包数据上传，缺点是与单包数据上传相比，数据量增大，会对车端运行时产生更大的影响，同时带宽占用较高，并且RTI方式是提前对所有指标监控，而不是针对订阅者的订阅内容进行监控，对资源造成浪费。

发明内容

为克服相关技术中存在的问题，本公开提供一种监控DDS的方法、装置、设备、介质及车辆。

根据本公开实施例的第一方面，提供一种监控DDS的方法，包括：

响应于监控工具的启动操作创建参与者，基于用户对监控工具界面的选择操作获取用户选择的实体及监控指标；

根据所述用户选择的实体及监控指标在所述参与者中创建订阅者，所述订阅者中包括一个或多个数据读取者；

通过预设的内建主题获取所述订阅者需要获取的监控数据；所述预设的内建主题通过函数调用的方式获取；

根据本公开实施例的第二方面，提供一种监控DDS的装置，包括：

监控指标模块，用于响应于监控工具的启动操作创建参与者，基于用户对监控工具界面的选择操作获取用户选择的实体及监控指标；

订阅者创建模块，用于根据选择的实体及监控指标在所述参与者中创建订阅者，所述订阅者中包括一个或多个数据读取者；

内建主题模块，用于通过预设的内建主题获取所述订阅者所需要获取的监控数据；所述预设的内建主题通过函数调用的方式获取；

根据本公开实施例的第三方面，提供一种电子设备，包括：处理器；用于存储所述处理器可执行指令的存储器；所述处理器，用于从所述存储器中读取所述可执行指令，并执行所述指令以实现本公开第一方面所提供的监控DDS的方法。

根据本公开实施例的第四方面，提供一种计算机可读存储介质，其上存储有计算机程序指令，该程序指令被处理器执行时实现本公开第一方面所提供的监控DDS的方法的步骤。

根据本公开实施例的第五方面，提供一种车辆，存储有一组指令集，所述指令集被所述车辆执行，以实现本公开第一方面所提供的监控DDS的方法。

本公开的实施例提供的技术方案可以包括以下有益效果：内建主题以数据类型为单位，避免一次性传输所有数据类型的大数据包，减少对运行时的影响，同时降低带宽占用，将监控数据根据用户需求进行数据计算及过滤后，以预设时间间隔上传到工具端，避免数据发送频率过大情况下的丢包以及高带宽占用。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。

图1是根据一示例性实施例示出的一种监控DDS的方法的流程图；

图2是根据一示例性实施例示出的一种监控DDS的装置框图；

图3是根据一示例性实施例示出的内建主题的数据流向的示意图；

图4是根据一示例性实施例示出的一种电子设备的框图；

图5是根据一示例性实施例示出的一种车辆的框图。

具体实施方式

下面将结合附图详细地对示例性实施例进行描述说明。

应当指出，相关实施例及附图仅为描述说明本公开所提供的示例性实施例，而非本公开的全部实施例，也不应理解本公开受相关示例性实施例的限制。

应当指出，本公开中所用术语“第一”、“第二”等仅用于区别不同步骤、设备或模块等。相关术语既不代表任何特定技术含义，也不表示它们之间的顺序或者相互依存关系。

应当指出，本公开中所用术语“一个”、“多个”、“至少一个”的修饰是示意性而非限制性的。除非在上下文另有明确指出，否则应该理解为“一个或多个”。

应当指出，本公开中所用术语“和/或”，用于描述关联对象之间的关联关系，一般表示至少存在三种关联关系。例如，A和/或B，至少可以表示：单独存在A，同时存在A和B，单独存在B这三种关联关系。

应当指出，本公开的方法实施例中记载的各个步骤可以按照不同的顺序执行，和/或并行执行。除非特别说明，本公开的范围不受相关实施例中步骤的描述顺序限制。

需要说明的是，本公开中所有获取信号、信息或数据的动作都是在遵照所在地国家相应的数据保护法规政策的前提下，并获得由相应装置所有者给予授权的情况下进行的。

技术用语说明

DDS：Data Distribution Service，数据分发服务是一个由对象管理组(OMG)发布的以数据为中心的中间件协议和API标准。DDS集成系统中的各个组件，提供低延迟数据连接、高可靠性以及高可扩展体系结构，以适应商业级物联网(IoT)应用程序的需求。

Entity实体：Entity是所有DDS实体的抽象基类，DDS域下的所有对象都继承自Entity。包括以下类型：DomainParticipant、Publisher、Subscriber、DataWriter、DataReader以及Topic。

DomainParticipant：该实体是服务的入口点，充当发布者、订阅者和主题的工厂，用于跟踪其他实体和服务入口点的容器；

Publisher：负责数据发布的对象，管理一个或多个DataWriters，它充当可以创建任意数量的DataWriters的工厂；

Subscriber：负责接收已发布的数据并使数据可用，Subscriber代表一个或多个DataReader，它充当可以创建任意数量的DataReader的工厂；

DataWriter：是负责数据分发的对象；

DataReader：是用来访问接收到的数据的对象；

Topic:用于标识DataWriter和DataReader之间的每个数据对象。每个主题由名称和数据类型定义。

DDS内置主题：是数据分发服务用来帮助应用程序相互发现的一种特殊主题，中间件自动处理这些主题。应用程序还可以访问它们以获取有关域的信息。

示例性方法

图1是根据一示例性实施例示出的一种监控DDS的方法的流程图，如图1所示，包括以下步骤。

在步骤S110中，响应于监控工具的启动操作创建参与者，基于用户对监控工具界面的选择操作获取用户选择的实体及监控指标；

用户启动监控工具后，会自动创建一个监控工具的DomaiParticipant，用户可以根据监控需求在监控工具的界面上选择需要监控的实体和监控指标；

监控指标至少包括以下任意一项或多项：

时延、吞吐量、心跳、重传、发送端缓存、订阅端缓存、PDP以及EDP；

在步骤S120中，根据所述用户选择的实体及监控指标在所述参与者中创建订阅者，所述订阅者中包括一个或多个数据读取者；

用户可以根据监控需求在监控工具的界面上选择需要监控的实体和监控指标后，监控工具自动创建对应的订阅者和发布者。订阅者中包括一个或多个数据读取者，发布者中包括一个或者多个数据写入者。

在步骤S130中，通过预设的内建主题获取所述订阅者所需要获取的监控数据；所述预设的内建主题通过函数调用的方式获取；

图3是根据一示例性实施例示出的内建主题的数据流向的示意图，根据图3可知应用程序发送的所有数据传输都要经过DDSI-RTPS层，本发明实施例中通过在DDSI-RTPS进行埋点上报的方式可以获取到所有监控指标的相关数据，埋点的技术实质，是先监听软件应用运行过程中的事件，当需要关注的事件发生时进行判断和捕获，现在常见的埋点上报方法有手动埋点、可视化埋点、无埋点；手动埋点，也叫代码埋点，即纯手动写代码，调用埋点SDK的函数，在需要埋点的业务逻辑功能位置调用接口，上报埋点数据，手动埋点让使用者可以方便地设置自定义属性、自定义事件；可视化埋点通过可视化交互的手段，代替上述的代码埋点，将业务代码和埋点代码分离，提供一个可视化交互的页面，输入为业务代码，通过这个可视化系统，可以在业务代码中自定义的增加埋点事件等等，最后输出的代码耦合了业务代码和埋点代码；无埋点则是前端自动采集全部事件，上报埋点数据，由后端来过滤和计算出有用的数据。

每个通过函数调用收集到的数据都会以主题的方式被订阅，这种主题叫内建主题，内建主题可以有多个，每个监控指标都可以是一种内建主题。如以时延、吞吐量、心跳、重传、发送端缓存、订阅端缓存、PDP以及EDP为单位内建主题，如下所示为一个内建主题：

module Statistics{

struct Writer{

Monitor::Guid guid；

sequence<char>topic；

sequence<char>type；

int64 creation_time；

uint64 xmit_byte；

uint64 xmit_count；

uint32 rexmit_count；

uint64 heartbeat_count；

uint32 ack_count；

uint32 nack_count；

int32 whc_adaptive；

uint32 whc_low；

uint32 whc_high；

uint32 whc_high_init；

uint32 throttle_count；

uint32 unacked_bytes；

}；

在现有的监控技术中RTI通过内建Topic监控所有实体的指标，提前监控所有指标，通过优先级判断决定是否上传至工具端，RTI的自定义内建Topic是以实体为单位，即每个实体的N个统计指标为一包数据上传，缺点是与单包数据上传相比，数据量增大，会对车端运行时产生更大的影响，同时带宽占用较高。而通过采用本申请实施例的监控DDS的方法，以数据类型为单位，避免一次性传输所有数据类型的大数据包，减少对运行时的影响，同时降低带宽占用，DDS端将数据按秒进行统计后上传给工具端，避免数据发送频率过大情况下的丢包以及高带宽占用。经过验证本申请实施例的监控DDS的方法DDS运行时的影响<0.5％，而且监控的指标多少不会对运行时产生显著影响，因此在使用工具链监控DDS运行数据时，采用本发明实施例提供的监控DDS的方法能够取得较为显著的效果。

本申请实施例提供的另一实施例中，监控数据以聚合上传的方式上传到监控工具界面，所述聚合上传具体包括：

将所述监控数据根据用户需求进行数据计算及过滤后，以预设时间间隔上传到监控工具界面。

例如，发送时延时上传每秒发送端和订阅端的总时延和总计数；发送吞吐量时上传每秒发送端发送的总吞吐量和总计数，或者订阅端接收的总吞吐量和总计数；发送心跳时上传每秒发送端的总计数；发送重传时上传每秒发送端的总计数；发送端缓存时上传每秒发送端的缓存总量；订阅端缓存发送上传每秒订阅端的缓存总量；发送时PDP上传每秒发送的总计数；发送EDP时上传每秒发送的总计数；

通过采用本发明实施例，具备如下有益效果：

内建主题以数据类型为单位，避免一次性传输所有数据类型的大数据包，减少对运行时的影响，同时降低带宽占用，DDS端将监控数据通过采用定时上传的方式，如默认为1s，可根据需要修改为3s或者5s，避免数据发送频率过大情况下的丢包以及高带宽占用，实际使用中证明了将数据提前进行计算和过滤后并不会对系统性能造成大的影响，经统计运行时的影响<0.5％。

示例性装置

图2是根据一示例性实施例示出的一种监控DDS的装置框图。参照图2，该装置200包括监控指标模块210，订阅者创建模块220和内建主题模块230。

该监控指标模块210，用于响应于监控工具的启动操作创建参与者，基于用户对监控工具界面的选择操作获取用户选择的实体及监控指标；

用户启动监控工具后，会自动创建一个监控工具的DomaiParticipant，用户可以根据监控需求在监控工具的界面上选择需要监控的实体和监控指标；

监控指标至少包括以下任意一项或多项：

时延、吞吐量、心跳、重传、发送端缓存、订阅端缓存、PDP以及EDP；

订阅者创建模块220，用于根据选择的实体及监控指标在所述参与者中创建订阅者，所述订阅者中包括一个或多个数据读取者；

用户可以根据监控需求在监控工具的界面上选择需要监控的实体和监控指标后，监控工具自动创建对应的订阅者和发布者。订阅者中包括一个或多个数据读取者，发布者中包括一个或者多个数据写入者。

内建主题模块230，用于通过预设的内建主题获取所述订阅者所需要获取的监控数据；所述预设的内建主题通过函数调用的方式获取；

应用程序发送的所有数据传输都要经过DDSI-RTPS层，所以通过在DDSI-RTPS函数打点的方式可以获取到所有监控指标的相关数据，每个函数打点收集到的数据都会以主题的方式被订阅，这种主题叫内建主题，内建主题可以有多个，每个监控指标都可以是一种内建主题。

本申请实施例提供的另一实施例中，监控数据以聚合上传的方式上传到监控工具界面，所述聚合上传具体包括：

将所述监控数据根据用户需求进行数据计算及过滤后，以预设时间间隔上传到监控工具界面。

例如，发送时延时上传每秒发送端和订阅端的总时延和总计数；发送吞吐量时上传每秒发送端发送的总吞吐量和总计数，或者订阅端接收的总吞吐量和总计数；发送心跳时上传每秒发送端的总计数；发送重传时上传每秒发送端的总计数；发送端缓存时上传每秒发送端的缓存总量；订阅端缓存发送上传每秒订阅端的缓存总量；发送时PDP上传每秒发送的总计数；发送EDP时上传每秒发送的总计数；

本公开装置实施例与上述发明实施例的技术方案相对应，各模块具体的操作可参照方法实施例中的描述理解，此处不再赘述。

示例性电子设备

图4是根据一示例性实施例示出的一种电子设备400的框图。该电子设备400可以是车辆控制器、车载终端、车载计算机或者其他类型的电子设备。

参照图4，电子设备400，可包括至少一个处理器410和存储器420。处理器410可以执行存储在存储器420中的指令。处理器410通过数据总线与存储器420通信连接。除存储器420外，处理器410还可通过数据总线与输入设备430、输出设备440、通信设备450通信连接。

处理器410可以是任何常规的处理器，诸如商业可获得的CPU。处理器还可以包括诸如图像处理器(Graphic Process Unit，GPU)，现场可编程门阵列(Field ProgrammableGate Array，FPGA)、片上系统(System on Chip，SOC)、专用集成芯片(ApplicationSpecific Integrated Circuit，ASIC)或它们的组合。

存储器420可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

在本公开实施例中，存储器420中存储有可执行指令，处理器410可以从所述存储器420中读取所述可执行指令，并执行所述指令以实现上述示例性实施例中任一所述的监控DDS的方法的全部或部分步骤。

示例性计算机可读存储介质

除了上述方法和装置以外，本公开的示例性实施例还可以是计算机程序产品或存储有该计算机程序产品的计算机可读存储介质。该计算机产品中包括计算机程序指令，该计算机程序指令可被处理器执行，以实现上述示例性实施例中任一方法中描述的的全部或部分步骤。

所述计算机程序产品可以以一种或多种程序设计语言的任意组合来编写用于执行本申请实施例操作的程序代码，所述程序设计语言包括面向对象的程序设计语言，诸如Java、C++等，还包括常规的过程式程序设计语言，诸如“C”语言或类似的程序设计语言以及脚本语言(例如Python)。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。

所述计算机可读存储介质可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以包括但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子包括：具有一个或多个导线电连接的静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘，或者上述的任意合适的组合。

示例性车辆

图5是根据一示例性实施例示出的一种车辆500的框图。该车辆500可以是燃油车辆、混合动力车辆、电动车辆、燃料电池车辆或者其他类型的车辆。

参照图5，车辆500可包括多个子系统，例如，驱动系统510、控制系统520、感知系统530、通信系统540、信息显示系统550以及计算处理系统560。车辆500还可以包括更多或更少的子系统，且各个子系统还可以包括多个部件，在此不一一赘述。

该驱动系统510，包括为车辆500提供动力运动的组件。例如，发动机、能量源、传动装置等。

该控制系统520，包括为车辆500提供控制的组件。例如，车辆控制、座舱设备控制、驾驶辅助控制等。

该感知系统530，包括为车辆500提供周边环境感知的组件。例如，车辆定位系统、激光传感器、语音传感器、超声波传感器、摄像设备等。

该通信系统540，包括为车辆500提供通信连接的组件。例如，移动通信网络(如，3G、4G、5G网络等)、WiFi、蓝牙、车联网等。

该信息显示系统550，包括为车辆500提供各种信息显示的组件。例如，车辆信息显示、导航信息显示、娱乐信息显示等。

该计算处理系统560，包括为车辆500提供数据计算和处理能力的组件。计算处理系统560可包括至少一个处理器561和存储器562。处理器561可以执行存储在存储器562中的指令。

处理器561可以是任何常规的处理器，诸如商业可获得的CPU。处理器还可以包括诸如图像处理器(Graphic Process Unit，GPU)，现场可编程门阵列(Field ProgrammableGate Array，FPGA)、片上系统(System on Chip，SOC)、专用集成芯片(ApplicationSpecific Integrated Circuit，ASIC)或它们的组合。

存储器562可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

在本公开实施例中，存储器562中存储有一组指令集，处理器561可以执行该指令集，以实现上述示例性实施例中任一所述的DDS监控的方法的全部或部分步骤。

本领域技术人员在考虑说明书及实践本公开后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

Claims (10)

1.一种监控DDS的方法，其特征在于，包括：

响应于监控工具的启动操作创建参与者，基于用户对监控工具界面的选择操作获取用户选择的实体及监控指标；

根据所述用户选择的实体及监控指标在所述参与者中创建订阅者，所述订阅者中包括一个或多个数据读取者；

通过预设的内建主题获取所述订阅者需要获取的监控数据；所述预设的内建主题通过函数调用的方式获取。

2.根据权利要求1所述的监控DDS的方法，其特征在于，所述监控指标至少包括以下任意一项或多项：

时延、吞吐量、心跳、重传、发送端缓存、订阅端缓存、PDP以及EDP。

3.根据权利要求1所述的通过内建Topic实现监控DDS的方法，其特征在于，所述预设的内建主题的获取步骤具体包括：

根据所述监控指标建立内建主题。

4.根据权利要求1所述的监控DDS的方法，其特征在于，所述通过预设的内建主题获取所述订阅者所需要获取的监控数据具体包括：

在发布者发布的数据以及原DDS通信中的订阅者的数据中获取订阅者所需要获取的监控数据，所述发布者包括一个或者多个数据写入者。

5.根据权利要求1所述的监控DDS的方法，其特征在于，所述监控数据以聚合上传的方式上传到监控工具界面，所述聚合上传具体包括：

将所述监控数据根据用户需求进行数据计算及过滤后，以预设时间间隔上传到监控工具界面。

6.根据权利要求1所述的监控DDS的方法，其特征在于，所述函数调用发生在DDS中间件的DDSI-RTPS层。

7.一种监控DDS的装置，其特征在于，包括：

监控指标模块，用于响应于监控工具的启动操作创建参与者，基于用户对监控工具界面的选择操作获取用户选择的实体及监控指标；

订阅者创建模块，用于根据选择的实体及监控指标在所述参与者中创建订阅者，所述订阅者中包括一个或多个数据读取者；

内建主题模块，用于通过预设的内建主题获取所述订阅者所需要获取的监控数据；所述预设的内建主题通过函数调用的方式获取。

8.一种电子设备，其特征在于，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

所述处理器，用于从所述存储器中读取所述可执行指令，并执行所述指令以实现所述权利要求1-6中任一所述的监控DDS的方法方法。

9.一种计算机可读存储介质，其上存储有计算机程序指令，其特征在于，该程序指令被处理器执行时，以实现所述权利要求1-6中任一所述的监控DDS的方法的步骤。

10.一种车辆，其特征在于，

存储有一组指令集，所述指令集被所述车辆执行，以实现所述权利要求1-6中任一所述的监控DDS的方法。