一种云端测控系统及测控流程的制作方法

1.本发明涉及物联网测控技术领域，具体为一种云端测控系统及测控流程。


背景技术：

2.随着网络技术的快速发展，相应出现了很多基于物联网的数据采集终端、分析和控制的设备和系统。例如，专利号为cn201610872814.3的中国发明专利公开了一种基于docker的web数据采集方法、web服务器及web数据采集系统，该发明基于docker虚拟机容器的轻量级的特性，动态创建docker镜像以实现web数据采集系统的可扩展性，进而解决系统可扩展和设备减耗的问题。
3.然而，现有的基于物联网的远程数据采集实现，不适用于高校实验室的远程实验教学，主要在于以下几个方面：第一、在采集数据时，比如一个压力机的实验，涉及到滑块的位移、加速度、冲压力等各种不同的传感器的同时采集，只有在同一时刻采集的位移、加速度、冲压力的值才具有计算意义，所以不同传感器相同时刻的数据的同步尤为重要；在现有的技术中，鲜有针对多传感器数据同步的处理。第二、基于实验室远程教学的数据采集，侧重点在于实验室内的测控设备系统对传感器的数据采集，同时配合设置只负责存储的云端服务器；所以应该将数据采集、数据处理的过程放在数据采集设备即终端的程序中，可以降低服务器的运算压力；再者，实验室远程教学的并发量相对较低，服务器的动态伸缩意义不大。第三、如果处于远程数据采集的环境下，学生应当需要对实验室现场环境有大致的了解，所以，远程测控系统应该集成实验室环境的视频监控能力。


技术实现要素：

4.针对上述情况，为弥补上述现有缺陷，本发明提供了一种云端测控系统及测控流程，该云端测控系统集远程数据采集与存储、采样数据实时可视化、远程设备可控、现场环境可查看的远程实验等解决方案于一体，改变高校实验室传统的数据测控形式，尤其在网络授课不能到实验室做实验的情况下，提供远程的数据采集方式则更加重要。
5.本发明提供如下的技术方案：本发明提出的一种云端测控系统，包括数据库、测控系统端、发布/订阅服务器、测控系统服务器、管理端、管理端服务器、用户端和用户端服务器；
6.所述数据库在测控系统服务器、管理端服务器、用户端服务器之间共享数据；
7.所述测控系统端通过接收用户端指令，采集指定采样通道的指定传感器的数据，控制实验室设备的启动和停止；
8.所述订阅/发布服务器提供测控系统端的接入、协议处理、消息的转发；
9.所述测控系统服务器负责对测控系统端的状态维护、采集数据的异步持久化，测控系统服务器需要订阅测控系统端状态更新(使用terminal/xxx/status表示)、测控系统端通过发布/订阅服务器向用户端推送采样数据(使用terminal/xxx/pushdata)的主题、用户端操作请求(使用client/xxx/operate)的主题，订阅这些主题是将测控系统端的状态、
测控系统端采集的数据、用户端的操作全部实时同步到数据库；
10.所述管理端和管理端服务器负责测控系统端信息、测控系统端采样通道、各通道支持的传感器的维护和版本管理；
11.所述用户端由vue实现的web程序，是采集数据的一端，提供可视化界面，用以连接测控系统端，实时同步地显示采集的数据图表，提供控制实验室设备的控制入口；
12.所述用户端服务器负责用户的登录鉴权、历史采集数据的拉取、测控系统端的可用状态检测以及根据选择的测控系统端拉取该测控系统端下的采样通道和各通道支持的传感器列表。
13.同时，本发明还提供了一种云端测控系统的测控流程，具体包括下列步骤：
14.(1)测控系统端启动：测控系统端启动，发布主题，通过发布/订阅服务器将测控系统端的上线状态发布到测控系统服务器，测控系统服务器将测控系统端上线状态持久化到数据库，此时测控系统端的状态为在线空闲，用户端可以检索到测控系统端，在管理端服务器的作用下管理端检索结果中显示测控系统端为在线空闲，测控系统端上线后订阅用户端操作主题，等待被用户端连接；
15.(2)用户端尝试连接测控系统端：用户端点击页面连接设备按钮，向用户端服务器发起rest请求，申请连接测控系统端，用户端服务器向数据库检索测控系统端的最新状态，数据库返回数据到用户端服务器，如果测控系统端的状态为在线空闲，则允许用户端连接，否则测控系统端无法被连接，用户端服务器反馈用户端；
16.(3)用户端数据采集：用户端点击页面开始采集按钮后，发布主题，测控系统端接收到指令后，开始采集数据，每秒发布一次主题，用户端接收数据后更新视图在页面进行展示；同时由于测控系统服务器也订阅了该主题，所以采集的数据会持久化到数据库中，以便用于下载或分析；用户端点击停止采集按钮，发布主题，测控系统端收到指令后，停止采集；
17.(4)用户端断开连接流程：用户端点击页面断开设备按钮，发布主题，测控系统端接收到指令后，清除本地记录的用户端标记，发布主题，并将状态更新为在线空闲。
18.进一步地，所述测控系统程序实现分为网络层、控制层、执行层和驱动层。
19.进一步地，所述网络层包括mqtt客户端和http客户端，mqtt客户端负责接入物联网，发布和订阅主题，比如发布terminal/xxx/status通知测控系统端状态变更，订阅client/xxx/operate以接收客户端操作请求；http客户端负责测控系统端初次启动的注册以及每次启动向测控系统服务器提交当前版本号；mqtt客户端与订阅/发布服务器交互，http客户端直接与测控系统服务器交互。
20.进一步地，所述控制层负责在mqtt客户端接收到用户端操作请求时，获取并解析用户端操作的数据包，通过操作类型分发调用执行层不同的程序进行处理；在执行层处理完毕后，增加对采样数据的后置处理，如：滤波等操作；控制层调用网络层，通过mqtt客户端将处理结果发布到用户端，该层也维持当前连接测控系统端的用户端标识。
21.进一步地，所述执行层包括采集程序和控制程序两种程序；采集程序对应不同采样通道实例类型分为三种具体的采集程序实现，模拟输入、计数器采集程序负责采样通道实例类型为1和3的采样请求，内置伺服电机驱动器参数读取程序负责采样通道实例类型为2的采样请求，rs232串口转modbus协议采集程序负责采样通道实例类型为4的采样请求，多种采集程序可以同时执行，满足一次请求采集不同类型的数据，多种采集程序之间使用模
拟输入采样时钟(ai/sampleclock)进行时钟同步，维持1秒读取一次采样的采样频率；控制程序根据测控机箱的设计，提供对实验室设备的控制。
22.进一步地，所述驱动层负责测控系统端的驱动，所述测控系统端程序依赖于ni(national instruments)数据采集卡驱动，模拟输入和计数器的采集程序最终会调用ni数据采集卡的驱动。需要额外安装ni数据采集驱动和运行环境。
23.在本方案中无论数据采集还是控制操作，都基于用户端已连接测控系统端这个前提，本方案的架构内有两种连接的概念，一是用户端与发布/订阅服务器保持的mqtt连接，二是用户端通过发布主题与测控系统端建立的虚拟的连接，前者的范围大于后者，后者实际上是通过程序控制并保持的测控系统端的状态，打开连接断开连接只是修改测控系统端的状态，以防止不同的用户端同时占用相同测控系统端，在一个mqtt连接周期内可以打开和断开多次与测控系统端的虚拟连接。在关闭mqtt连接时必须同时修改测控系统端的状态。
24.采用上述结构本发明取得的有益效果如下：本发明提出的一种云端测控系统及测控流程，是基于物联网实现的，在本方案中的用户端与管理端不是必要的，管理端的作用只是为了用户端便捷使用测控系统端，维护并向用户端提供进行数据采集必须的一些配置和基本数据，而且用户端也不限定为pc或其他可以运行用户端程序的设备，用户无论通过什么程序，只要通过mqtt协议，使用约定的主题消息，将数据采集的请求发送到测控系统端，测控系统端就可以将采集的数据返回给用户，只要测控系统端与接入物联网的用户端满足数据采集协议约定的条件即可。
25.本方案提供了一种物联网测控系统的可行性，基于mqtt协议，但不限于mqtt协议，可以替换为socket或其他物联网协议，只要满足请求采集时传入传感器配置信息。
26.本方案的测控系统依赖于ni采集卡的驱动，但是不限于ni采集卡，可以替换为阿尔泰或研华等其他采集卡。
27.本方案的模拟输入以电压测量为基础，但不限于电压测量，也可以替换为测量电流等。限定只测量电压值的目的是将底层程序的函数调用进行简化，通过采集请求中的配置数据将采集的电压值转为压力、加速度、位移等目标单位。所以只要满足传感器支持且能够实现转化则不必限定只采集电压值。
附图说明
28.附图用来提供对本发明的进一步理解，并且构成说明书的一部分，与本发明的实施例一起用于解释本发明，并不构成对本发明的限制。在附图中：
29.图1为本发明的整体结构框图；
30.图2为本发明测控系统端程序实现框图；
31.图3为本发明实施例一的用户端数据采集流程；
32.图4为本发明ni模拟输入采集任务的处理流程；
33.图5为本发明采集任务的处理流程；
34.图6为本发明用户端选择接入物联网的可用的测控系统设备的界面图；
35.图7为本发明用户端选择采样通道实例的样式的截面图；
36.图8为本发明用户端采集数据实时绘制的数据图表；
37.图9为本发明用户端调用测控系统摄像头查看实验室现场图像的示意图。
具体实施方式
38.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例；基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
39.需要说明的是，下面描述中使用的词语“前”、“后”、“左”、“右”、“上”和“下”指的是附图中的方向，词语“内”和“外”分别指的是朝向或远离特定部件几何中心的方向。
40.本方案一种云端测控系统的网络架构，包括测控系统端、发布/订阅服务器、测控系统服务器、数据库、管理端服务器、管理端、用户端服务器和用户端，数据库在测控系统服务器、管理端服务器、用户端服务器之间共享数据。物联网实施方式如图1所示，测控系统的实施方式如图2所示。本方案的实施，依赖于一些软件层面的抽象概念。
41.测控系统端：对应运行在实验室具体的测控机箱设备中的测控程序，包含多个采样通道实例。在程序启动时，根据烧录的配置文件初始化当前设备支持的采样通道映射，配置文件的采样通道映射与测控机箱的硬件设计的端子个数、类型需要一致。采样通道映射的数据如：
42.1)模拟输入类型的映射
43.physical-name:ai0
44.platform-port:101
45.2)计数器类型的映射
46.name:ctr0
47.platform-port:401
48.physical-name表示ni采集卡驱动定义的对应采集卡的模拟输入物理通道的通道名，name表示ni采集卡驱动定义的对应采集卡的计数器物理通道的通道名在实例二中会提到，platform-port表示在测控系统端中定义的采集通道实例的通道号，采集通道映射就是将这两个通道的描述进行一个关联。
49.测控系统端状态：定义1表示在线空闲，0表示离线，2忙碌被占用，3故障。
50.采样通道实例：对应实验室具体的测控机箱设备的一个端子或一个usb接口，每个端子或者usb接口支持不同的传感器实例，采样通道实例需要设置通道号，在当前测控系统端程序中保持唯一，用于匹配用户端上传的数据采集中的采样通道配置，一个采样通道实例的数据如：
51.{
52."id":"",
53."channelnum":"101",
54."channelname":"5v 1号通道",
55."channeltype":1,
56."sensors":[]
[0057]
}
[0058]
，channelnum表示通道号，此通道号与上面提到的platform-port一致，channelnum是用户端和管理端的定义，platform-port是测控系统端中的定义，用户端的数据采集指令就是需要用channelnum去匹配platform-port从而找到物理通道名，然后通过底层驱动采集对应物理通道的数据，channeltype表示采样通道实例类型，sensors表示当前采样通道实例支持的传感器实例。
[0059]
采样通道实例类型：定义1表示模拟输入通道，2表示内置的伺服电机驱动器参数读取通道，3表示计数器通道，4表示rs232转modbus协议采样通道。
[0060]
传感器实例：对应实验室具体的传感器，一个传感器实例的数据如：
[0061]
{
[0062]
"id":"",
[0063]
"sensorname":"位移传感器",
[0064]
"outrangemin":0.000,
[0065]
"outrangemax":50.000,
[0066]
"outunits":2,
[0067]
"outunitname":"mm",
[0068]
"outunitlabel":"linearpos",
[0069]
"transparamm":10.00,
[0070]
"transparamb":0.00,
[0071]
"seriesname":"l"
[0072]
}
[0073]
，outrangemin表示该传感器测量范围的最小值，outrangemax表示该传感器测量范围的最大值，transparamm和transparamb两个字段表示线性函数y＝mx+b的斜率和偏移量，在outunits字段取值为1时，表示采集数据单位为电压值，取值为2时，表示采样数据单位为自定义转换类型时，需要将采集的数据根据线性函数做一个转换，这里通过配置transparamm和transparamb实现了采样通道实例软件层面的复用，在实验室教学场景，传感器的复杂度不高，新增的传感器只要采样数据符合线性变化，即可通过管理端动态创建传感器实例并绑定到具体的采样通道实例，用户端刷新页面重新请求数据即可加载出新增的传感器。
[0074]
测控系统端初次启动时，将测控机箱的mac地址、烧录的测控系统端版本号上传到测控系统服务器，测控系统服务器将当前的测控系统端mac地址注册生成一个设备实例的记录。此设备实例即为测控系统的一个实例。管理端可以编辑这条设备实例信息，创建传感器实例、采样通道实例，并把传感器实例绑定到具体的采样通道实例上，将采样通道实例绑定到设备实例上，采样通道实例的配置应与烧录的配置文件、测控机箱一致。这种配置方式解决了测控系统的多版本控制问题，用户端在选择不同的测控系统端后，用户端服务器会拉取对应测控系统端版本的采样通道实例列表，以及不同版本下采样通道实例支持的传感器实例。
[0075]
实例一
[0076]
本方案使用mqtt协议(messge queuing telemetry transport，消息队列遥测传输协议)的发布/订阅主题来实现消息发送，消息体为json格式字符串，比如测控系统服务
器订阅所有的测控系统端的状态更新的主题，在测控系统端上线时，该测控系统端会发布一个状态更新的主题，测控系统端作为主题的发布者实际上先将消息发布给发布/订阅服务器，发布/订阅服务器作为一个中转再将消息转发到测控系统服务器，所以，在整个架构内，发送的mqtt协议消息实际有一个中转的过程。
[0077]
如图1所示，物联网测控系统分为三端：测控系统端、用户端和管理端。
[0078]
测控系统端通过接收用户端指令，采集指定采样通道的指定传感器的数据，控制电机、电动推杆的启动和停止。
[0079]
测控系统服务器负责对测控系统端的状态维护、采集数据的异步持久化，测控系统服务器需要订阅测控系统端状态更新(使用terminal/xxx/status表示)、测控系统端向用户端推送采样数据(使用terminal/xxx/pushdata)的主题、用户端操作请求(使用client/xxx/operate)的主题，订阅这些主题是将测控系统端的状态、测控系统端采集的数据、用户端的操作全部实时同步到数据库。
[0080]
用户端由vue实现的web程序，是采集数据的一端，提供可视化界面，用以连接测控系统端，实时同步地显示采集的数据图表，提供控制实验室内电机或电动推杆的控制入口。
[0081]
用户端服务器负责用户的登录鉴权、历史采集数据的拉取、测控系统端的可用状态检测以及根据选择的测控系统端拉取该测控系统端下的采样通道和各通道支持的传感器列表。
[0082]
管理端和管理端服务器负责测控系统端信息、测控系统端采样通道、各通道支持的传感器的维护和版本管理。维护的数据在数据采集协议5中使用。
[0083]
订阅/发布服务器提供测控系统端的接入、协议处理、消息的转发。
[0084]
具体的流程如下：
[0085]
测控系统端启动流程：测控系统端启动，发布主题terminal/xxx/status，消息内容为{"terminalid":"","status":1}(status的取值见测控系统端状态的定义)，通过
①②
将测控系统端的上线状态发布到测控系统服务器，测控系统服务器通过
③
将测控系统端上线状态持久化到数据库，此时测控系统端的状态为“在线空闲”，用户端可以检索到测控系统端，管理端检索结果中显示测控系统端为“在线空闲”，测控系统端上线后订阅“用户端操作”主题(以client/xxx/operate为例，以下均以client/xxx/operate表示用户端操作的主题，该消息的数据包内的operate字段表示用户端操作的指令)，等待被用户端连接。测控系统端状态数据包定义中的terminalid表示当前设备实例在数据库中的id。
[0086]
用户端尝试连接测控系统端流程：用户端点击页面连接设备按钮，向用户端服务器发起rest请求
④
，申请连接测控系统端，用户端服务器通过
⑤
向数据库检索测控系统端的最新状态，数据库通过
⑥
返回数据到用户端服务器，如果测控系统端的状态为“在线空闲”，则允许用户端连接，否则测控系统端无法被连接，用户端服务器通过
⑦
反馈用户端。
[0087]
用户端连接测控系统端流程：用户端发布主题client/xxx/operate，消息内容为{"operate":1,"params":{"dataid":""}}(operate的值1在这里表示打开连接操作，dataid表示用户端标识，每个用户端操作的消息内都包含dataid字段用以区分不同的用户端)，通过
⑧⑨
中转到测控系统端，测控系统端接收指令后在本地记录用户端标识，测控系统端发布terminal/xxx/status主题，消息内容为{"terminalid":"","status":2}，再次通过
①②③
的顺序将状态更新为“忙碌被占用”，在当前用户端断开连接之前，其他用户端无
法连接测控系统端。连接完成后，用户端需要订阅主题terminal/xxx/pushdata，以便在采集数据开始后能正确接收到采样数据包，采样数据向terminal/xxx/pushdata主题发布。
[0088]
用户端数据采集流程：用户端点击页面开始采集按钮后，通过
⑧⑨
发布主题client/xxx/operate，消息内容为{"operate":3,"params":{"dataid":"","channels":[]}}(operate的值3在这里表示开始采集操作)，测控系统端接收到指令后，开始采集数据(采集方案实施见实例二)，通过
⑩
每秒发布一次主题terminal/xxx/pushdata，消息内容为采样数据(采样数据包见实例二)，用户端接收数据后更新视图在页面进行展示；同时由于测控系统服务器也订阅了该主题，所以采集的数据会通过持久化到数据库中，以便用于下载或分析。用户端点击停止采集按钮，通过
⑧⑨
发布主题client/xxx/operate，消息内容为{"operate":4,"params":{"dataid":""}}(operate的值4在这里表示停止采集操作)，测控系统端收到指令后，停止采集。
[0089]
用户端断开连接流程：用户端点击页面断开设备按钮，通过
⑧⑨
发布主题client/xxx/operate，消息内容为{"operate":3,"params":{"dataid":""}}(operate的值6在这里表示断开连接)，测控系统端接收到指令后，清除本地记录的用户端标记，发布主题terminal/xxx/status，消息内容为{"terminalid":"","status":1}，并通过
①②③
的顺序将状态更新为“在线空闲”。
[0090]
无论数据采集还是控制操作，都基于用户端已连接测控系统端这个前提，本方案的架构内有两种连接的概念，一是用户端与发布/订阅服务器保持的mqtt连接，二是用户端通过发布client/xxx/operate主题与测控系统端建立的虚拟的连接，前者的范围大于后者，后者实际上是通过程序控制并保持的测控系统端的状态，打开连接断开连接只是修改测控系统端的状态，以防止不同的用户端同时占用相同测控系统端，在一个mqtt连接周期内可以打开和断开多次与测控系统端的虚拟连接。在关闭mqtt连接时必须同时修改测控系统端的状态。
[0091]
实例二
[0092]
如图2所示，本方案的测控系统程序实现分网络层、控制层、执行层和驱动层。
[0093]
网络层：包括mqtt客户端和http客户端，mqtt客户端负责接入物联网，发布和订阅主题，比如发布terminal/xxx/status通知测控系统端状态变更，订阅client/xxx/operate以接收客户端操作请求。http客户端负责测控系统端初次启动的注册以及每次启动向测控系统服务器提交当前版本号。mqtt客户端与订阅/发布服务器交互，http客户端直接与测控系统服务器交互。
[0094]
控制层：负责在mqtt客户端接收到用户端操作请求时，获取并解析用户端操作的数据包，通过操作类型分发调用执行层不同的程序进行处理；在执行层处理完毕后，增加对采样数据的后置处理，如：滤波等操作。控制层调用网络层，通过mqtt客户端将处理结果发布到用户端。该层也维持当前连接测控系统端的用户端标识。
[0095]
执行层：包括采集程序和控制程序两种程序。采集程序对应不同采样通道实例类型分为三种具体的采集程序实现，模拟输入、计数器采集程序负责采样通道实例类型为1和3的采样请求，内置伺服电机驱动器参数读取程序负责采样通道实例类型为2的采样请求，rs232串口转modbus协议采集程序负责采样通道实例类型为4的采样请求，多种采集程序可以同时执行，满足一次请求采集不同类型的数据，多种采集程序之间使用模拟输入采样时
钟(ai/sampleclock)进行时钟同步，维持1秒读取一次采样的采样频率。控制程序根据测控机箱的设计，提供对伺服电机和电动推杆的控制。
[0096]
驱动层：测控系统端程序依赖于ni(national instruments)数据采集卡驱动，模拟输入和计数器的采集程序最终会调用ni数据采集卡的驱动。需要额外安装ni数据采集驱动和运行环境。
[0097]
用户端一个操作请求的处理流程如图3所示，对应实例一中“用户端数据采集流程”的具体实施。
[0098]
控制层通过json反序列化解析出用户端操作数据包，一个完整的数据采集请求包格式为
[0099]
{
[0100]
"operate":3,
[0101]
"params":{
[0102]
"dataid":"1",
[0103]
"frequency":10,
[0104]
"channels":[《channelconfig》,...]
[0105]
}
[0106]
}，
[0107]
frequency表示采样频率，即每秒每个通道采集的样本个数，channels表示要采样的通道实例和传感器实例的配置集合，使用集合是支持多个采样通道实例的同时采集，数组内的每个channelconfig主要字段有但不限于：
[0108]
{
[0109]
"channelnum":"101",
[0110]
"channelname":"5v 1号通道",
[0111]
"sensorname":"位移传感器",
[0112]
"channeltype":1,
[0113]
"outunitname":"mm",
[0114]
"seriesname":"l",
[0115]
"outunits":2,
[0116]
"outrangemin":0,
[0117]
"outrangemax":50,
[0118]
"outunitlabel":"linearpos",
[0119]
"transparamm":10,
[0120]
"transparamb":0,
[0121]
"measureunits”:1,
[0122]
"perval":1024,
[0123]
"initialval":0
[0124]
}
[0125]
用户端代码根据用户在页面的通道选项中选择的传感器，将采样通道实例与传感器实例的字段进行了结合，对应现实情况，在实验室将位移传感器插入了5v1号通道，
channelname(通道显示名称)、sensorname(当前采样的传感器名称)、outunitname(采样数据的单位)、seriesname(数据图表显示的图例名)这些字段都是作为回显用户端采集数据时显示使用，在用户端请求采集数据时同步到数据库中。
[0126]
控制层循环判断每个channelconfig的channeltype字段，根据上文中的定义的采样通道实例类型可知，1表示模拟输入类型，控制层将调用执行层的模拟输入采集程序进行处理，如果所有的channeltype都不是模拟输入类型，那么控制层需要从采样数据映射中取一个模拟输入类型的采样通道创建ni采集任务，原因是为了通过该任务设置采样时钟，同步其他非模拟输入类型采样通道实例的采样频率。模拟输入采集程序底层通过创建ni采集任务实现，ni模拟输入采集任务的处理流程如图4所示。
[0127]
此处需要明确虚拟通道与任务的概念：
[0128]
虚拟通道，ni数据采集中定义，有时简称为通道，是将实体通道和通道相关信息(范围、接线端配置、自定义换算等格式化数据信息)组合在一起的软件实体。
[0129]
任务，ni数据采集中定义，是具有定时、触发等属性的一个或多个虚拟通道。
[0130]
本案例的测控系统程序基于java语言开发，使用jna技术(java native access，提供java在运行期间动态访问本地库如windows的dll的工具类)调用ni数据采集的c语言sdk，以下提及的程序中调用的函数均为c语言定义。
[0131]
创建采集任务，获得任务句柄，使用该句柄控制任务的开始、结束、销毁，对应函数。
[0132]
创建通道，即创建虚拟通道，对应函数：
[0133]
int32 daqmxcreateaivoltagechan(taskhandle taskhandle,const char physicalchannel[],const char nametoassigntochannel[],int32 terminalconfig,float64 minval,float64 maxval,int32units,const char customscalename[])，该函数创建通道采集的是电压值，taskhandle即为第1步创建的任务句柄，physicalchannel为需要采集的通道名称，此处需要设置物理通道名，通过用户端请求的参数channelnum找到对应采样通道映射获取physical-name如：ai0，创建物理通道名dev1/ai0，dev1为ni驱动识别的采集卡的设备名，可以通过nimax程序获取，一般默认值是dev1，nimax程序在安装ni数据采集驱动时自动安装。units为采样数据的单位，minval和maxval分别为当前采样单位下采样数据的测量范围的最小值和最大值，由用户端请求参数的outrangemin和outrangemax设置。本方案的测控系统程序为了实现采样通道实例与传感器实例动态配置，所有接入的传感器采集的都是电压值，用户端请求参数的outunits若为1，则units设置为daqmx_val_volts，该值表示采集电压，outunits若为2，则units设置为daqmx_val_fromcustomscale，该值表示自定义采样单位，也就是将采集的数据通过一个换算将电压值转化为自定义的采样单位，customscalename就是指定这样一个换算的名称，如果采集的是电压，该值可以设置为null，如果采集的是自定义的采样单位，需要调用daqmxcreatelinscale函数设置一个线性换算，该函数会使用前文提到的用户端请求参数中transparamm和transparamb，通过该函数可以创建一种线性换算，在调用该函数时也需要用户端请求参数中的outunitname和outunitlabel，前者表示将电压的单位换算为的目标单位，后者给这个换算定义了名称，然后可以将outunitlabel的值设置到customscalename中，这样就完成了通道的创建。
[0134]
配置采样时钟，根据用户端请求参数frequency调用函数daqmxcfgsampclktiming
进行配置，采样模式设置为连续采样，每通道每秒的采样率设置为frequency的值，在连续采样模式下，将每通道的缓冲区设置为与frequency一致，可以实现连续采样且缓冲区采样样本数达到frequency的数量后，就可以调用读取采集的数据的函数对采样结果进行读取，而缓冲区达到frequency采样数的时间消耗正好为1秒。
[0135]
开始采集任务，调用daqmxstarttask开始采集。
[0136]
读取采样值，需要在一个循环中调用daqmxreadanalogf64函数，因为创建通道时创建的是模拟输入通道，ai即模拟输入，所以在读取的时候相应地也需要模拟输入的读取函数，第3步在配置采样时钟时，可以实现1秒读取一次采样的频率，所以该函数实际上会阻塞当前线程，在第3步配置采样时钟的缓冲区采样数据满之后才能读取到数据。每读取一次采样数据，将采样数据提交给控制层处理，之后判断用户端是否请求停止采集，如果停止采集，则退出循环，进入第6步，否则继续等待读取采样数据。
[0137]
结束，调用daqmxstoptask关闭第1步创建的taskhandle对应的任务，并调用daqmxcleartask释放资源。
[0138]
在ni计数器的数据采集流程与模拟输入大体上一致，区别在于，计数器配置采样时钟依赖于模拟输入的采样时钟，如果当前采集请求中不包含模拟输入类型通道的采集请求，需要额外创建一个模拟输入采集任务并配置采样时钟，然后再配置计数器的采样时钟，二者都使用ai/sampleclock时基。计数器数据采集流程如图5：
[0139]
这里只说明与模拟输入采集的不同之处。
[0140]
在创建计数器采集通道时，需要根据数据采集请求中channelconfig的measureunits字段判断是角位移还是线性位移的采集，measureunits为1时表示采集角位移，为2时表示采集线性位移。两种采集调用创建通道的函数不同，角位移调用daqmxcreateciangencoderchan，需要用到数据采集请求中perval和initialval两个参数，前者表示编码器一圈有多少个脉冲，后者表示测量的初始值；线性位移调用daqmxcreatecilinencoderchan，此时也需要perval和initialval两个参数，不过意义略有不同，前者表示每个脉冲对应的测量距离，后者表示测量的初始值。计数器的物理通道名称与模拟输入不同，通过用户端请求的参数channelnum找到对应采样通道映射获取name如：ctr0，创建物理通道名dev1/ctr0。
[0141]
开始采集任务时，先开始计数器的采集任务，由于计数器配置了模拟输入的采样时基，所以此时不会开始执行采集，需要最后调用模拟输入任务的开始执行后，才会真正开始执行计数器采集任务。
[0142]
读取计数器采样值，与模拟输入不同，使用的是daqmxreadcounterf64，以从计数器通道读取采样结果。
[0143]
在上述采集任务的处理流程5中，每秒向用户端发布一次采样数据，控制得到执行层返回的采样数据后，后置处理如滤波计算完成后，将采样数据封装成采样数据包，格式如下：
[0144][0145]
该数据包在发布之后，用户端和测控系统服务器都会获得，用户端通过绘制图表展示，测控系统服务器将数据存入云端数据库。dataid为用户端标识，pushorder为本次采样数据包的序号，用于保证多个采样数据包的先后顺序，terminalid为测控系统设备的标识，通过dataid可以定位到具体的采集请求，例如当前的采样数据可以匹配采样请求中dataid为1的记录。channels存储的是本次采样的采样通道实例的通道号，此字段是一个数组，数组内每个元素表示一个采样通道实例的通道号，支持同时多个通道的采样，通道号的顺序与采样请求数据包中的channels字段的通道配置信息顺序一致，且通道号与采样请求数据包中的channelnum字段匹配。datas字段表示1秒内固定采样频率具体的采样数据，该字段是一个二维数组，数组元素长度与采样请求数据包的sequence字段(采样频率)一致，datas中的每个元素为对应采样通道的采样数据，顺序与channels中的通道号一致。
[0146]
实例三
[0147]
基于腾讯云实时音视频rtc实现测控系统端的摄像头推流，用户端界面实时展示实验室现场图像。
[0148]
用户端发布主题user/xxx/cameraoperate申请调用测控系统端摄像头；
[0149]
终端服务器监听第1步的主题，接收该消息后，终端服务器创建测控系统端与用户端的关联关系，调用rtc的sdk分别生成用户端和测控系统端对应的签名，发布主题user/xxx/enterroom到用户端，发布主题terminal/xxx/enterroom到测控系统端；
[0150]
用户端接收到enterroom消息后，通过rtc的sdk订阅远端的视频流，等待测控系统端推送视频；测控系统端接收到enterroom消息后，通过rtc的sdk发布视频流。
[0151]
在实验室环境中，可以满足采样数据的采集与云端存储，模拟输入与计数器采样频率最大可达到1khz，并且在采样时基的协调下，采样数据是同步的，如机械运动时采集的加速度、位移、冲压力等数据，多传感器测量值的同步，可以提高后期对采样数据处理的精度。如表格1所示，展示了下载的云端采集数据，在采样频率为100hz时，位移传感器和冲压力传感器1秒内的采样数据变化。
[0152]
表1
[0153]
[0154]
[0155][0156]
[0157]
如图6所示，展示用户端选择接入物联网的可用的测控系统端设备。
[0158]
如图7所示，展示用户端选择采样通道实例的样式，每个通道内通过管理端配置多种传感器实例，用户端为需要采集的通道实例选择具体的传感器实例后，点击开始采集按钮即可提交数据采集请求至测控系统端设备。
[0159]
如图8所示，展示用户端采集数据实时绘制的数据图表，可以切换传感器进行查看，鼠标悬浮可以显示不同通道的传感器具体时刻的采样值。
[0160]
如图9所示，展示用户端调用测控系统端摄像头，查看实验室现场图像，图中显示为实验室的实验器材的运动情况。通过点击“关闭监控”按钮可以取消监控的显示。
[0161]
高扩展性：
[0162]
模拟输入支持多种传感器，如扭矩、螺栓预紧力、电涡流位移、电感式位移、加速度、冲压力、拉压力、拉线式位移等。如果需要接入新增的传感器，只要将传感器采集结果由电压值到目标值的转换配置提交给测控系统端即可；计数器采集支持编码器、光栅尺等，切换不同的编码器和光栅尺，只要将编码器和光栅尺的参数提交给测控系统端即可，不需要修改采集程序代码。
[0163]
要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物料或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物料或者设备所固有的要素。
[0164]
尽管已经示出和描述了本发明的实施例，对于本领域的普通技术人员而言，可以理解在不脱离本发明的原理和精神的情况下可以对这些实施例进行多种变化、修改、替换和变型，本发明的范围由所附权利要求及其等同物限定。

技术特征：
1.一种云端测控系统，其特征在于：包括数据库、测控系统端、发布/订阅服务器、测控系统服务器、管理端、管理端服务器、用户端和用户端服务器；所述数据库在测控系统服务器、管理端服务器、用户端服务器之间共享数据；所述测控系统端通过接收用户端指令，采集指定采样通道的指定传感器的数据，控制实验室设备的启动和停止；所述订阅/发布服务器提供测控系统端的接入、协议处理、消息的转发；所述测控系统服务器负责对测控系统端的状态维护、采集数据的异步持久化，测控系统服务器需要订阅测控系统端状态更新、测控系统端通过发布/订阅服务器向用户端推送采样数据的主题、用户端操作请求的主题，订阅这些主题是将测控系统端的状态、测控系统端采集的数据、用户端的操作全部实时同步到数据库；所述管理端和管理端服务器负责测控系统端信息、测控系统端采样通道、各通道支持的传感器的维护和版本管理；所述用户端由vue实现的web程序，是采集数据的一端，提供可视化界面，用以连接测控系统端，实时同步地显示采集的数据图表，提供控制实验室设备的控制入口；所述用户端服务器负责用户的登录鉴权、历史采集数据的拉取、测控系统端的可用状态检测以及根据选择的测控系统端拉取该测控系统端下的采样通道和各通道支持的传感器列表。2.根据权利要求1所述的一种云端测控系统的测控流程，其特征在于：具体包括下列步骤：(1)测控系统端启动：测控系统端启动，发布主题，通过发布/订阅服务器将测控系统端的上线状态发布到测控系统服务器，测控系统服务器将测控系统端上线状态持久化到数据库，此时测控系统端的状态为在线空闲，用户端可以检索到测控系统端，在管理端服务器的作用下管理端检索结果中显示测控系统端为在线空闲，测控系统端上线后订阅用户端操作主题，等待被用户端连接；(2)用户端尝试连接测控系统端：用户端点击页面连接设备按钮，向用户端服务器发起rest请求，申请连接测控系统端，用户端服务器向数据库检索测控系统端的最新状态，数据库返回数据到用户端服务器，如果测控系统端的状态为在线空闲，则允许用户端连接，否则测控系统端无法被连接，用户端服务器反馈用户端；(3)用户端数据采集：用户端点击页面开始采集按钮后，发布主题，测控系统端接收到指令后，开始采集数据，每秒发布一次主题，用户端接收数据后更新视图在页面进行展示；同时由于测控系统服务器也订阅了该主题，所以采集的数据会持久化到数据库中，以便用于下载或分析；用户端点击停止采集按钮，发布主题，测控系统端收到指令后，停止采集；(4)用户端断开连接流程：用户端点击页面断开设备按钮，发布主题，测控系统端接收到指令后，清除本地记录的用户端标记，发布主题，并将状态更新为在线空闲。3.根据权利要求2所述的一种云端测控系统的测控流程，其特征在于：所述测控系统程序实现分为网络层、控制层、执行层和驱动层。4.根据权利要求3所述的一种云端测控系统的测控流程，其特征在于：所述网络层包括mqtt客户端和http客户端，mqtt客户端负责接入物联网，发布和订阅主题；http客户端负责测控系统端初次启动的注册以及每次启动向测控系统服务器提交当前版本号；mqtt客户端
与订阅/发布服务器交互，http客户端直接与测控系统服务器交互。5.根据权利要求4所述的一种云端测控系统的测控流程，其特征在于：所述控制层负责在mqtt客户端接收到用户端操作请求时，获取并解析用户端操作的数据包，通过操作类型分发调用执行层不同的程序进行处理；在执行层处理完毕后，增加对采样数据的后置处理；控制层调用网络层，通过mqtt客户端将处理结果发布到用户端，该层也维持当前连接测控系统端的用户端标识。6.根据权利要求5所述的一种云端测控系统的测控流程，其特征在于：所述执行层包括采集程序和控制程序两种程序；采集程序对应不同采样通道实例类型分为三种具体的采集程序实现，模拟输入、计数器采集程序负责采样通道实例类型为1和3的采样请求，内置伺服电机驱动器参数读取程序负责采样通道实例类型为2的采样请求，rs232串口转modbus协议采集程序负责采样通道实例类型为4的采样请求，多种采集程序可以同时执行，满足一次请求采集不同类型的数据，多种采集程序之间使用模拟输入采样时钟进行时钟同步，维持1秒读取一次采样的采样频率；控制程序根据测控机箱的设计，提供对实验室设备的控制。7.根据权利要求6所述的一种云端测控系统的测控流程，其特征在于：所述驱动层负责测控系统端的驱动，所述测控系统端程序依赖于ni数据采集卡驱动，模拟输入和计数器的采集程序最终会调用ni数据采集卡的驱动。需要额外安装ni数据采集驱动和运行环境。

技术总结
本发明公开了一种云端测控系统，包括数据库、测控系统端、发布/订阅服务器、测控系统服务器、管理端、管理端服务器、用户端和用户端服务器；所述数据库在测控系统服务器、管理端服务器、用户端服务器之间共享数据，同时还公开了该云端测控系统的测控流程。本发明涉及物联网测控技术领域，具体提供了一种云端测控系统及测控流程，该云端测控系统集远程数据采集与存储、采样数据实时可视化、远程设备可控、现场环境可查看的远程实验等解决方案于一体，改变高校实验室传统的数据测控形式，尤其在网络授课不能到实验室做实验的情况下，提供远程的数据采集方式则更加重要。据采集方式则更加重要。据采集方式则更加重要。


技术研发人员：邱俊 林功海 贺森亮
受保护的技术使用者：贝尔数据科技（大连）有限公司
技术研发日：2023.05.25
技术公布日：2023/9/14