CN220325632U - 监测系统 - Google Patents

Abstract

本申请提供一种监测系统，包括：主控件、显示件、队列件、封装件与应用编程接口；主控件控制显示件显示用户界面，并基于用户界面上的输入操作生成控制指令，控制指令包括识别码；队列件连接显示件与应用编程接口，并以先进先出方式存放控制指令；应用编程接口与封装件连接，封装件包括至少两个不同的驱动文件，不同的驱动文件用于激活不同厂商的测试工具；应用编程接口中预存有多个识别码与驱动文件的对应关系，以在接收到控制指令时，基于控制指令中的识别码以及对应关系确定识别码对应的目标驱动文件，调用目标驱动文件，以激活对应厂商的目标测试工具，将控制指令通过目标测试工具进行发送，从而减少用户界面开发人员的工作量以及更加智能化。

Description

监测系统

技术领域

本申请涉及监测技术领域，尤其涉及一种监测系统。

背景技术

在车辆监测中，通常需要同时对一辆车的多个功能件，甚至同时对多辆车进行监测，但是通常情况下一辆车的多个功能件分别由多个厂商生产提供(比如车辆空调系统由A厂商提供，灯光系统由B厂商提供；有的灯光系统中的前灯由C厂商提供，后灯由D厂商提供；有的一部分前灯由E厂商提供，另一部分前灯由F厂商提供)，而各个厂商提供的功能件通常由各厂商提供的CAN总线测试盒工具进行驱动，而CAN总线测试盒工具需要通过对应厂商的驱动文件进行激活才能使用。现有技术中，不同厂商的驱动文件由不同的API(应用编程)接口调用，需要对应开发不同的用户界面才能调用不同的API，当新增厂商提供功能件时，需要对应新增厂商开发新的用户界面以调用新增API，进而调用新增厂商提供的驱动文件，从而激活新增厂商提供的CAN总线测试盒工具，才能对新增厂商提供的功能件进行监测，这极大的增加了用户界面开发人员的工作量，在需要对多个厂商提供的功能件进行监测时，需要切换用户界面，对于用户来说不够便捷。而且用户在监测各功能件时，需要由用户根据需要检测的功能件去判断需要调用哪个驱动文件，这对于用户来说不够智能化。

实用新型内容

为此，本申请提供一种驱动封装结构及监测系统，以解决上述技术问题。

本申请第一方面提供一种监测系统，多个测试工具连接所述监测系统与被监测车辆，所述监测系统包括：主控件、显示件、队列件、封装件与应用编程接口；

所述主控件控制所述显示件显示用户界面；

所述主控件基于所述用户界面上的输入操作而生成控制指令，所述控制指令中包括所述识别码；

所述队列件连接所述显示件与所述应用编程接口，所述队列件以先进先出的方式存放所述控制指令；

所述应用编程接口与所述封装件连接，所述封装件包括至少两个不同的驱动文件，不同的驱动文件用于激活不同厂商的测试工具；

所述应用编程接口中预存有多个识别码与驱动文件的对应关系，以在接收到一控制指令时，基于所述控制指令中的识别码以及所述对应关系确定所述识别码对应的目标驱动文件，并调用所述目标驱动文件，以激活对应厂商的目标测试工具，并将所述控制指令通过所述目标测试工具进行发送，以及通过所述测试工具接收与所述控制指令相关联的反馈信息；

所述队列件以先进先出的方式存放所述反馈信息；

所述主控件控制所述显示件显示所述反馈信息。

本申请中，由于将至少两个不同的驱动文件封装在一封装件中，且该封装件与应用编程接口连接，应用编程接口可以基于控制指令中的识别码以及对应关系确定识别码对应的目标驱动文件，并调用目标驱动文件，以激活目标测试工具将控制指令发送出去，因此，可以仅开发一个用户界面调用一个应用编程接口，由该应用编程接口调用目标驱动文件，从而可以减少用户界面开发人员的工作量。在需要对多个厂商提供的功能件进行监测时，用户可以在同一个用户界面选择对不同的厂商提供的功能件进行监测，相比于需要在不同的用户界面选择对不同厂商提供的功能件进行监测更加便捷。用户在监测各功能件时，应用编程接口可以根据控制指令中的识别码以及对应关系确定识别码对应的目标驱动文件，因此用户只需要在用户界面选择对应的识别码而不用根据需要检测的功能件去判断需要调用哪个驱动文件，对于用户来说更加智能化。

附图说明

为了更清楚地说明本申请的技术方案，下面将对实施方式中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本申请一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的测试工具与监测系统和被监测车辆的连接示意图；

图2为本申请实施例提供的监测系统的结构示意图；

图3为本申请实施例提供的用户界面结构示意图；

图4为本申请实施例提供的封装件的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有付出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请的描述中，除非另有明确的规定和限定，术语“连接”应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是直接相连，也可以通过中间媒介间接相连，也可以是两个元件内部的连通；可以是通讯连接；可以是电连接。对于本领域的普通技术人员而言，可以根据具体情况理解上述术语在本申请中的具体含义。

在车辆研发测试、车辆成品抽检、车主在购车时以及车辆检修等场景中，常需要对车辆各个功能件进行监测，查看其是否能正常使用。随着CAN总线在车辆上的应用普及，CAN总线可以遍布全车，和所有节点的功能件连接，当车辆进行任何形式的运动时，都会产生独特的CAN数据，也就是说，如果我们能够采集到车辆的CAN信息，就能知道整台车的状态了。当车辆某个节点的功能件出现问题时，我们就用CAN总线测试盒与汽车的CAN总线相连。当检测软件检测出故障码以后，我们就将故障码与总线协议规定的故障码列表进行对照，这样就可以知道车辆哪里出现了故障。其中，功能件包括打火件、刹车件、安全保护件、车灯件、语音件以及空调件等中的至少一个。

请参阅图1，图1为本申请实施例提供的测试工具与监测系统和被监测车辆的连接示意图。

如图1所示，测试工具2连接所述监测系统1与被监测车辆3。其中，监测系统1可以设置在一控制装置中，测试工具2可以为CAN总线测试盒工具，测试工具2可以通过USB数据线连接控制装置，通过串口线与被监测车辆3的CAN总线接口连接，测试工具2可以接收从控制装置发过来的数据帧，并对其进行解析，组成一个CAN消息帧，发送到被监测车辆3的CAN总线接口。另外，测试工具2还可以接收被监测车辆3上的CAN网络数据，并转发到上位机的监测系统1中。

其中，所述控制装置可以包括但不仅限于计算机。

其中，所述监测系统1用于对至少一辆车的多个功能件进行监测，当多个功能件由多个厂商生产提供时，车辆监测通常也需要相应的各厂商提供的测试工具2。

如前所述，所述功能件包括打火件、刹车件、安全保护件、车灯件、语音件以及空调件等中的至少一个。

请结合参阅图2-图4，图2为本申请实施例提供的监测系统的结构示意图；图3为本申请实施例提供的用户界面结构示意图；图4为本申请实施例提供的封装件的结构示意图。

如图2-图4所示，一些实施例中，所述监测系统1包括：主控件10、显示件20、队列件30、封装件41与应用编程接口42。所述主控件10控制所述显示件20显示用户界面50；所述主控件10基于所述用户界面50上的输入操作而生成控制指令，所述控制指令中包括所述识别码。所述队列件30连接所述显示件20与所述应用编程接口42；所述队列件30以先进先出的方式存放所述控制指令。所述应用编程接口42与所述封装件41连接，所述封装件41包括至少两个不同的驱动文件410(比如包括驱动文件A、驱动文件B与驱动文件C)，不同的驱动文件410用于激活不同厂商的测试工具2。所述应用编程接口42中预存有多个识别码与驱动文件410的对应关系，以在接收到一控制指令时，基于所述控制指令中的识别码以及所述对应关系确定所述识别码对应的目标驱动文件410，并调用所述目标驱动文件410，以激活对应厂商的目标测试工具2，并将所述控制指令通过所述目标测试工具2进行发送(可以发送给被监测车辆)，以及通过所述测试工具2接收与所述控制指令相关联的反馈信息(可以接收被监测车辆发送的与所述控制指令相关联的反馈信息)。所述队列件30以先进先出的方式存放所述反馈信息。所述主控件10控制所述显示件20显示所述反馈信息。

本申请中，由于将至少两个不同的驱动文件封装在一封装件41中，且该封装件41与应用编程接口42连接，应用编程接口42可以基于控制指令中的识别码以及对应关系确定识别码对应的目标驱动文件，并调用目标驱动文件，以激活目标测试工具将控制指令发送出去，因此，可以仅开发一个用户界面50调用一个应用编程接口42，由该应用编程接口42调用目标驱动文件，从而可以减少用户界面开发人员的工作量。在需要对多个厂商提供的功能件进行监测时，用户可以在同一个用户界面50选择对不同的厂商提供的功能件进行监测，相比于需要在不同的用户界面50选择对不同厂商提供的功能件进行监测更加便捷。用户在监测各功能件时，应用编程接口42可以根据控制指令中的识别码以及对应关系确定识别码对应的目标驱动文件，因此用户只需要在用户界面50选择对应的识别码而不用根据需要检测的功能件去判断需要调用哪个驱动文件，对于用户来说更加智能化。

其中，所述至少两个不同的驱动文件410为不同厂商的驱动文件。

其中，所述应用编程接口42的数量为一个，或者包括多个相同的应用编程接口42。该应用编程接口42中包括多个函数功能集，比如：inrCan_Open()、inrCan_Close()、SendMsg()以及RecvMsg()等。

一些实施例中，所述识别码包括厂商ID，即，应用编程接口42中可以预存各个厂商ID与各个厂商提供的驱动文件的对应关系，当接收到厂商ID时，应用编程接口可以基于该厂商ID及对应关系确定需要调用的驱动文件。

从而，用户在监测目标功能件时，只需要知道监测的目标功能件的厂商ID，并在用户界面选择对应的厂商ID，而不需要知道监测的目标功能件对应的驱动文件，便可以调用目标驱动文件，从而激活目标测试工具2，完成对目标功能件进行监测，由于通常来说用户对厂商ID比对驱动文件名称更加熟悉，因此，用户选择厂商ID相比于选择驱动文件名称更加方便。

需要知道的是，在其他实施例中，所述识别码还可以是用户约定俗成的编号等，并不局限于所举的例子。

其中，所述对应关系可以为识别码(比如厂商ID)与驱动文件410的对应关系，比如：厂商ID为ZLG CAN，对应的驱动文件410为ZLG驱动文件。

其中，所述控制指令为数据帧，所述反馈消息为CAN消息帧，所述测试工具2用于对数据帧进行解析并组成CAN消息帧，以及对CAN消息帧进行解析并组成数据帧。一些实施例中，数据帧包括帧起始(表示数据帧的开始)、仲裁段(表示该帧优先级的段)、控制段(表示数据的字节数与保留位的段)、数据段(数据内容)、CRC(循环冗余校验码)段(检查帧的传输错误的段)、应答场段(表示确认正常接收的段)与帧结束(表示帧结束的段)。所述CAN消息帧包括：数据帧(用于传送数据)、远程帧(用于请求数据)、超载帧(用于扩展帧序列的延迟时间)与错误帧(用于当局部检测出错条件后产生一个全局信号出错帧)。

一些实施例中，当所述封装件41包括新增驱动文件410时，所述应用编程接口42中相应地新增预存与所述新增驱动文件410相关联的对应关系。

即，当新增厂商提供功能件时，新增厂商相应地也会提供测试工具2与激活该测试工具2的驱动文件410，此时需要将新增厂商提供的驱动文件410封装进所述封装件41，此时相应地，需要在应用编程接口42中新增标识码(比如新增厂商的ID)与新增厂商提供的驱动文件410对应关系进行预存，以在接收到新增厂商的ID时，基于该厂商ID与对应关系调用相应的驱动文件410。

从而，应用编程接口42在接收到控制指令中的识别码时，可以基于识别码以及新增预存的对应关系确定识别码对应的目标驱动文件410，并调用目标驱动文件410，而不必如现有技术中新增驱动文件时，便需要新增一接口以调用新增驱动文件。

相应地，当所述封装件包括新增驱动文件410时，所述用户界面50还包括与所述新增驱动文件410关联的新增识别码选择项。

从而，基于用户针对新增识别码选择项的输入操作而生成识别码，当该识别码发送至应用编程接口42时，应用编程接口42可以基于该识别码以及相应的对应关系确定识别码对应的目标驱动文件410，并调用目标驱动文件410，而不必如现有技术中新增驱动文件时，便需要新增用户界面以供用户输入，从而调用新增驱动文件。

如图3所示，一些实施例中，所述用户界面50包括识别码选择件51，所述识别码选择件51基于用户的输入操作而显示多个识别码选择项510，并基于用户对其中一个所述识别码选择项510的输入操作而确定所选择的识别码。

比如：识别码选择件51包括P CAN选择项、ZLG CAN选择项、USB CAN选择项与CANoe选择项，用户可以通过鼠标点击、触控输入、手势输入或者语音输入等方式选择P CAN选择项，所述识别码选择件51则根据用户的操作确定识别码为P CAN。

如图3所示，一些实施例中，所述用户界面50包括发送CAN消息输入框52和接收CAN消息输入框53；所述发送CAN消息输入框52接收用户的输入而生成消息队列，所述接收CAN消息输入框53用于接收所述反馈信息。

如图3所示，一些实施例中，所述用户界面50还包括启动CAN控制项54和停止CAN控制项55。当用户点击启动CAN控制项54时，开始发送控制指令以及能够接收反馈信息，用户点击停止CAN控制项55时，停止发送控制指令以及停止接收反馈信息。

如图1与图2所示，其中，主控件10、显示件20、队列件30、封装件41与应用编程接口42均位于上位机中。

一些实施例中，所述队列件30可以为随机存取存储器(random access memory，RAM)，其用作外部高速缓存，以第一队列的形式缓存所述主控件10发送的控制指令，以及所述测试工具2发送的针对所述控制指令的反馈信息。通过示例性但不是限制性说明，许多形式的随机存取存储器(random access memory，RAM)可用，例如静态随机存取存储器(static RAM，SRAM)、动态随机存取存储器(DRAM)、同步动态随机存取存储器(synchronousDRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(double data rate SDRAM，DDRSDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(synchlink DRAM，SLDRAM)和直接内存总线随机存取存储器(direct rambusRAM，DR RAM)。所述驱动封装结构40可以设置在储存器中，所述显示件20为显示屏，所述主控件10可以为中央处理器(Central Processing Unit，CPU)，通用处理器，数字信号处理器(Digital Signal Processor，DSP)，专用集成电路(Application-Specific IntegratedCircuit，ASIC)，现场可编程门阵列(Field Programmable Gate Array，FPGA)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。

以上是本申请实施例的实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请实施例原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也视为本申请的保护范围。

Claims (11)

1.一种监测系统，多个测试工具连接所述监测系统与被监测车辆，其特征在于，所述监测系统包括：主控件、显示件、队列件、封装件与应用编程接口；

所述主控件控制所述显示件显示用户界面；

所述主控件基于所述用户界面上的输入操作而生成控制指令，所述控制指令中包括识别码；

所述队列件连接所述显示件与所述应用编程接口，所述队列件以先进先出的方式存放所述控制指令；

所述应用编程接口与所述封装件连接，所述封装件包括至少两个不同的驱动文件，不同的驱动文件用于激活不同厂商的测试工具；

所述应用编程接口中预存有多个识别码与驱动文件的对应关系，以在接收到一控制指令时，基于所述控制指令中的识别码以及所述对应关系确定所述识别码对应的目标驱动文件，并调用所述目标驱动文件，以激活对应厂商的目标测试工具，并将所述控制指令通过所述目标测试工具进行发送，以及通过所述测试工具接收与所述控制指令相关联的反馈信息；

所述队列件以先进先出的方式存放所述反馈信息；

所述主控件控制所述显示件显示所述反馈信息。

2.根据权利要求1所述的监测系统，其特征在于，当所述封装件包括新增驱动文件时，所述应用编程接口中相应地新增预存与所述新增驱动文件相关联的对应关系。

3.根据权利要求2所述的监测系统，其特征在于，当所述封装件包括新增驱动文件时，所述用户界面还包括与所述新增驱动文件关联的新增识别码选择项。

4.根据权利要求1所述的监测系统，其特征在于，所述至少两个不同的驱动文件为不同厂商的驱动文件。

5.根据权利要求1所述的监测系统，其特征在于，所述应用编程接口的数量为一个，或者包括多个相同的应用编程接口。

6.根据权利要求1所述的监测系统，其特征在于，所述识别码包括厂商ID。

7.根据权利要求1所述的监测系统，其特征在于，所述用户界面包括识别码选择件，所述识别码选择件基于用户的输入操作而显示多个识别码选择项，并基于用户对其中一个所述识别码选择项的输入操作而确定所选择的识别码。

8.根据权利要求1所述的监测系统，其特征在于，所述用户界面包括发送CAN消息输入框和接收CAN消息输入框；所述发送CAN消息输入框接收用户的输入而生成消息队列，所述接收CAN消息框用于接收所述反馈信息。

9.根据权利要求1所述的监测系统，其特征在于，所述用户界面还包括启动CAN控制项和停止CAN控制项。

10.根据权利要求1所述的监测系统，其特征在于，所述主控件、所述显示件与所述队列件以及所述驱动封装结构均位于上位机中。

11.根据权利要求1所述的监测系统，其特征在于，所述监测系统用于对至少一辆车的多个功能件进行监测。