CN111953777B

CN111953777B - 一种物联网平台接入设备管理系统

Info

Publication number: CN111953777B
Application number: CN202010807658.9A
Authority: CN
Inventors: 赵默; 刘欢
Original assignee: Beijing Perfectlight Science And Technology Ltd
Current assignee: Beijing Perfectlight Science And Technology Ltd
Priority date: 2020-08-12
Filing date: 2020-08-12
Publication date: 2022-10-25
Anticipated expiration: 2040-08-12
Also published as: CN111953777A

Abstract

本发明公开了一种物联网平台接入设备管理系统，该系统通过预先设定统一的服务器端、设备端以及用户端的主题分发规则，设定设备联网模型以及设备端与服务端的交互流程，从而各种类型的设备可以按照上述设定内容快速接入物联网平台，并能够自由组网、有效通信，该系统通过设备联网模型定制功能使前后端均可以基于维护统一的设备模型来实现设备的类型多样性，并通过固化设备运行和操作的工作流程，实现了对设备接入的可控性，该系统可扩展性强且更具兼容性。

Description

一种物联网平台接入设备管理系统

技术领域

本发明涉及物联网技术领域，更具体的说是涉及一种物联网平台接入设备管理系统。

背景技术

目前，物联网技术已经渗入到各个领域中，给人们的生产和生活带来了极大的便利，设备联网和通信是物联网技术的基本需求，传统的做法是将设备按照运用的行业领域、使用环境和使用特点进行细分，单独开发对应的联网模块，为细分后的设备单独设计联网后的数据传输协议和内容解析，并以此作为通信规则接入物联网平台进行管理。

但是，上述物联网平台接入设备的方式以及与设备通信的方式存在以下缺陷：

1、由于不同种类的设备所运行的环境差异较大，所选择的设备联网协议也存在较大差异性，因此需要根据接入设备的类型单独设计联网后的数据传输协议，工作量大；

2、由于设备的运行特点差异，设备联网通信时的内容解析各不相同；比如家电类智能设备(下称家电)和工厂生产类智能设备(下称机床)因为工作特点和使用要求不同，两个领域在最初设计时设备抽象模型和通讯指令都不同，好比家电说汉语，机床说英语，因此即使两类设备都接入到互联网上，还是无法直接通信，需要对两类设备单独进行内容解析，才能实现有效通信。

由于现有的物联网平台接入设备的方式以及与设备通信的方式存在以上两点缺陷，在设备都接入到互联网上的情况下，无法做到各类设备快速接入物联网平台并能够自由组网和相互间有效通信，导致硬件开发和物联网平台设计难度大大提升。

因此，如何提供一种能够实现各类设备快速接入物联网平台，并能自由组网和有效通信的物联网平台接入设备管理系统是本领域技术人员亟需解决的问题。

发明内容

有鉴于此，本发明提供了一种物联网平台接入设备管理系统，该系统通过预先设定统一的服务器端、设备端以及用户端的主题分发规则，设定设备联网模型以及设备端与服务端的交互流程，从而各种类型的设备可以按照上述设定内容快速接入物联网平台，并能够自由组网、有效通信。

为了实现上述目的，本发明采用如下技术方案：

一种物联网平台接入设备管理系统，该系统包括：通讯端、设备端、用户端以及服务器端；

所述通讯端基于MQTT协议预先设定设备端向服务器端、服务器端向设备端、服务器端向用户端以及设备端之间的主题分发规则，设计设备联网模型，并对设备端与服务器端的交互流程进行设置；

所述设备端根据所述设备联网模型设置自身的工作状态、权限控制模式以及工作模型，按照所述主题分发规则与所述服务器端或另一设备端通信，并根据所述设备端与服务器端的交互流程执行联网开机以及数据上传任务；

所述用户端用于向所述服务器端发起对所述设备端的操控申请；

所述服务器端根据所述设备端设置的权限控制模式配置对所述设备端的控制权限，并按照所述主题分发规则与所述设备端或用户端通信；接收所述用户端的操控申请，并将所述设备端反馈的申请结果回传至所述用户端；在所述操控申请通过后，根据所述设备端与服务器端的交互流程接收所述设备端上传的数据，并对数据进行解析处理和存储。

本发明提供的系统选用为低宽带、高延迟网络而设计的MOTT协议作为底层通信协议，基于MOTT协议设计得到上述主题分发规则。在设计该主题分发规则时，本发明将物联网平台内的服务器以及客户访问物联网平台的客户终端(即上述的用户端，如电脑、笔记本或者智能手机)都看做是连接进物联网的一台设备，包括服务器和客户端在内的所有接入设备均会有一个物联网内位移的身份标识符SN(SerialNo)码，SN码有以下几点要求：

1、接入物联网的真实设备由客户定制SN码的规则，设备出厂时将SN码写入硬件中，保证每台设备有自己唯一的身份识别SN码；像中国公民身份证的身份证号一样，该SN码一旦确定如没有其他特殊原因不能修改；

2、客户端接入物联网平台由程序随机生成唯一标示SN码，同时作为作为MQTT客户端ID使用；

3、服务器端(针对负载均衡的服务器组也看做一个整体)拥有固定的身份标示符SN码：“server”。该关键字不能被其他接入的设备使用。

进一步地，所述通讯端包括主题分发管理模块、设备联网管理模块以及交互流程管理模块；

所述主题分发管理模块用于分别设定设备端向服务器端、服务器端向设备端、服务器端向用户端以及设备端之间通信的主题结构以及接收端的订阅规则；

所述设备联网管理模块用于设置设备端的工作状态以及服务器端对应的状态，设置设备端的权限控制模式以及服务器端对应的控制权限，并设置设备端的工作模型；

所述交互流程管理模块用于对设备端与服务器端通讯和交互数据的流程进行设计。

进一步地，所述设备端的工作状态包括关机状态、待机状态、运行状态和锁定状态。

其中，所述待机状态具体包括本地工作模式和远程模式。

设备在接入平台后设备端工作状态需要和服务器端的状态进行一一对应，这样可以保证设备状态在任何一端都不会失控。

因此，对应上述设备端的工作状态，所述服务器端对应的状态包括离线状态、设备开机未连接状态、在线待机状态、设备运行状态以及设备锁定无操作权状态。

具体地，所述设备端的权限控制模式包括本地模式、观摩模式以及远控模式；设备端在工作时最少需要使用上述中的其中一种权限控制模式，具体根据设备自身特点进行选取。

服务器端对设备的控制权限管理与设备端对应的也分为三种权限状态，因此，所述服务器端对应的控制权限以文件系统的概念来说，包括不可读不可写、可读不可写以及可读可写三种状态。

更进一步地，设备端与服务器端通讯和交互数据的流程包括开机流程、观摩模式下的工作流程、远控模式下的工作流程、实时数据的上传流程和断点续传流程以及历史记录上传流程等。

除上述列举的流程外，还可以设计其他的交互流程，如设备校时流程。交互流程在设计时，首先要有设备状态满足，其次是流程发起方，再就是应答方合规的回应，才能实现整个流程。

进一步地，所述设备端的工作模型包括工作模式设定模型、工作参数模型、监控参数模型、历史记录模型以及临时数据模型；

所述工作模式设定模型用于设定和通知所述设备端当前的工作模式；

所述工作参数模型用于传输设备端在工作时从外部获取的各种设定参数；

所述监控参数模型用于传输设备端在工作时产生并向外发送的数据；

历史记录模型用于传输设备端在运行过程中产生的记录信息；

临时数据模型用于暂存设备端在工作时自定义编辑的参数以及临时性的不需要物联网平台保存的参数。

进一步地，所述主题分发管理模块设定的设备端向服务器端通信的主题结构包括设备端的SN码、固定值”service”以及消息分类标签tag。

进一步地，所述消息分类标签tag包括：

运行状态标签status，表征发布设备命令和设备状态相关的数据；

工作模式标签model，表征向服务器发布设备当前所处的工作模式；

参数设置标签set，表征向服务器发布设备运行的设定参数，所述参数格式为K-V值；

实时数据标签rundata，表征向服务器发送与业务相关的实时监控，参数格式为K-V值；

监控数据标签monitor，表征向服务器发送设备性能相关实时监控，参数格式为K-V值；

历史记录标签history，表征发送因本地模式或者掉线导致服务器未保存的工作记录；

临时数据标签tempdata，表征保留主题，或者不需保存的临时数据；以及

错误代码标签error，表征向服务器上报设备端错误。

经由上述的技术方案可知，与现有技术相比，本发明公开提供了一种物联网平台接入设备管理系统，该系统通过预先设定统一的服务器端、设备端以及用户端的主题分发规则，设定设备联网模型以及设备端与服务端的交互流程，从而各种类型的设备可以按照上述设定内容快速接入物联网平台，并能够自由组网、有效通信，该系统通过设备联网模型定制功能使前后端均可以基于维护统一的设备模型来实现设备的类型多样性，并通过固化设备运行和操作的工作流程，实现了对设备接入的可控性，该系统可扩展性强且更具兼容性。

附图说明

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

图1为本发明提供的一种物联网平台接入设备管理系统的结构架构示意图；

图2为本发明实施例中设备工作模型示意图；

图3为本发明实施例中设备开机流程示意图；

图4为本发明实施例中观摩模式下的工作流程示意图；

图5为本发明实施例中远控模式下的工作流程示意图；

图6为本发明实施例中实时数据上传和断点续传工作流程示意图；

图7为本发明实施例中历史记录上传的工作流程示意图；

图8为本发明实施例中设备校时过程的工作流程示意图。

具体实施方式

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

参见附图1，本发明实施例公开了一种物联网平台接入设备管理系统，该系统包括：通讯端1、设备端2、用户端3以及服务器端4；

通讯端1基于MQTT协议预先设定设备端向服务器端、服务器端向设备端、服务器端向用户端以及设备端之间的主题分发规则，设计设备联网模型，并对设备端与服务器端的交互流程进行设置；

设备端2根据设备联网模型设置自身的工作状态、权限控制模式以及工作模型，按照主题分发规则与服务器端或另一设备端通信，并根据设备端与服务器端的交互流程执行联网开机以及数据上传任务；

用户端3用于向服务器端4发起对设备端2的操控申请；

服务器端4根据设备端2设置的权限控制模式配置对设备端2的控制权限，并按照主题分发规则与设备端2或用户端3通信；接收用户端3的操控申请，并将设备端2反馈的申请结果回传至用户端3；在操控申请通过后，根据设备端2与服务器端4的交互流程接收设备端2上传的数据，并对数据进行解析处理和存储。

在本实施例中，系统内设备端2的底层结构具体包括以下几部分：

1、硬件驱动部分

由于产品设计需要，硬件驱动接口可以使用不同厂家的MCU或者接口，所以此部分的设计不具有统一性，各个产品做物联时，需要按串口编写初始化和收发程序。

2、MQTT协议收发部分

此部分将编写统一的收发函数库。

首先对WIFI通讯模块的通讯部分做相应的驱动。再次对数据的收发和数据解析编写统一的函数库。如设置数据的发送转换为ASCII，收到数据解析为相应的数据类型，也由函数库来执行。

3、命令执行部分

对函数库解析的命令和数据，通讯设备需要进行相关的具体运行操作，由产品各自本身设置参数进行对应，对其功能执行模块不做更改，仅需要读取其过程数据以及启动和完成标志。

具体地，通讯端1包括主题分发管理模块11、设备联网管理模块12以及交互流程管理模块13；

主题分发管理模块11用于分别设定设备端向服务器端、服务器端向设备端、服务器端向用户端以及设备端之间通信的主题结构以及接收端的订阅规则；

设备联网管理模块12用于设置设备端2的工作状态以及服务器端4对应的状态，设置设备端2的权限控制模式以及服务器端4对应的控制权限，并设置设备端2的工作模型；

交互流程管理模块13用于对设备端2与服务器端4通讯和交互数据的流程进行设计。

在本实施例中，主题分发管理模块11主要负责入网及通信协议的设计，具体包括以下三部分：

1、硬件联网

设备的硬件联网基本采用以下三种方式：

通过有线的方式连接网管进行联网：该方式好处是能提供稳定的网络环境，缺点是设备放置要求不灵活，运行环境要求很高。

通过无线wifi的方式联网：可以很方便的搭建设备的联网环境，并且设备端有很多wifi联网模块可供开发使用。

蜂窝网络联网：可通过4G/5G等蜂窝网络技术进行联网，对设备放置地址几乎无限制，缺点是蜂窝网络的运营和使用必须借助像中国移动、中国联通、中国电信这样的企业进行，成本较高。

2、通信协议

本实施例选择了为低带宽、高延迟网络而设计的MQTT协议作为底层通信协议。

3、基于MQTT协议的主题分发规则

该主题分发规则基于的基本理念是：认为物联网平台服务器(以下简称服务器)和客户访问物联网平台的客户终端(如电脑、笔记本或者手机终端，以下简称客户端)都看做是连接进物联网的一台设备。包括服务器和客户端在内的所有接入设备都会有一个物联网内的唯一身份标示符SN码(SerialNo)，SN码有以下要求：

接入物联网的真实设备由客户定制SN码的规则，设备出厂时将SN码写入硬件中保证每台设备有自己唯一的身份识别SN码；像中国公民身份证的身份证号一样，该SN码一旦确定如没有其他特殊原因不能修改；

客户端接入物联网平台由程序随机生成唯一标示SN码，同时作为作为MQTT客户端ID使用；

服务器端(针对负载均衡的服务器组也看做一个整体)拥有固定的身份标示符SN码：”service”。该关键字不能被其他接入的设备使用。

基于以上设计MQTT协议主题分发规则如下：

A.设备向服务器发布消息

设备端向服务器通信的主题分为三层结构，具体可以参见下表1：

表1设备向服务器发送的主题结构

第一层	第二层	第三层
			deviceSN	Fixedvalue:“service”	tag
该设备的SN码	固定值：”service”	消息分类标签

其中，固定值”service”，表示向服务器发送设备；

设备端向服务器端发送的数据按照业务逻辑通过MQTT主题的tag位进行了分类，tag标签的详细内容可以参见下表2：

表2 tag标签详情列表

其中，临时数据：该主题是为了满足设备这样的特殊需求：设备向控制端(如手机APP、浏览器页面、微信小程序)客户直接发送的不需要经过后端保存的数据。这就有点像硬件上点对点通信的方式。比如临时性的监控参数、一次性的结果数据或者一些每次运行时都需要向用户上报的初始化参数等等。

服务器端订阅规则为：服务器重启或者启动时必须立刻自动订阅主题过滤器：”+/service/#”。不论何时都不能取消对该主题过滤器的订阅。服务器的订阅必须设置允许的最大QoS等级为QoS2。

B.服务器向设备发布消息

服务器端向设备端通信的主题分为两层，具体结构可以参见下表3：

表3服务器向设备下发的主题结构

第一层	第二层
		Fixedvalue:“service”	deviceSN
固定值：”service”	该设备的SN码

第一层：固定值”service”，表示该信息由服务器发送；

第二层：接收端设备的SN码；消息的逻辑部分在消息体中体现。

设备端订阅规则为：设备端必须在嵌入程序中设定死自己的订阅主题：”service/devSN”。保证在开机后第一时间订阅该主题并且不论何时都不能取消对该主题的订阅。设备端的订阅必须设置允许的最大QoS等级为QoS0。

C.服务器端和客户端(即用户端)之间的通信

服务器端和用户端是物联网平台的软件实现，在软件架构中分别称为后端和前端；合理的软件架构是前后端分离的，两部分程序的结构性通讯都是由HTTP协议来完成的，但是针对物联网数据的实时特性，一般使用websocket协议，考虑到设备端和服务器(后端)已经实现MQTT协议决定前端同时嵌入MQTT客户端也通过MQTT协议和后端、设备端进行通信。

服务器端与用户端的通信主题结构如下表4所示：

表4服务器和客户端通信主题列表

设备状态通知：后端用来向前端实时推送对应设备的平台状态。

平台消息通知：将提升客户体验的弹出框通知功能单独抽离出来，使用MQTT的指定主题单独发送实时消息内容并在前端弹出展示。包括但不限于以下内容：设备状态变更提示内容、设备(或者工作组)工作流程状态变更提示内容、平台公告推送内容、操作提示消息内容、设备(或者工作组)数据监控异常通知内容等等。

本实施例公开的系统实现了服务器端前端和后端的分离：后端负责业务逻辑，前端负责显示逻辑。后端业务模块化管理，增强了系统的可拓展性和设备接入的兼容性。后端设计了一系列高可用的对外接口，使得任何支持http(TCP/IP)的设备都可以接入平台收发数据。

上述三种通信过程，可以归结为设备接入物联网主题订阅规则，下面对设备间组网主题规则进行说明。

D.设备和设备之间的通信(设备自建工作组)

设备端之间通信的主题分为两层结构，具体可以参见下表5：

表5设备之间通信主题结构

第一层	第二层
		deviceSN	groupID
该设备的SN码	需要通信的设备组ID

设备端订阅规则为：设备端之间通信需要先组成一个设备工作组，工作组内多台设备协同工作，只有在工作组内的设备才能通信，且某一设备发送的消息，工作组内的其他设备均可以接收到，工作组可以随时创建、管理和删除。当设备加入工作组时应立刻订阅主题：”+/groupID”。

在本实施例中，设备联网管理模块12主要负责设计接入物联网的设备模型，即设备联网模型，具体实现方案如下：

1、设备状态模型设计

设备状态在设备端自己(本地)和服务器端各自需要维护一个闭环体系。在设备接入平台后，根据MQTT设备状态，设备端工作状态和服务器端对应的状态需要按照映射关系进行一一对应，以保证设备状态在任何一端都不会失控。上述的对应关系如下表6所示。

表6设备状态模型列表

2、设备的权限模型设计

设备端控制权限：

设备端最少需要使用下表7中其中一个权限控制模式，具体需要根据设备的自身特点选取并实现下列合适的权限控制模式。

表7设备端控制权限列表

服务器端控制权限：

服务器端从业务逻辑层面将设备控制权限分为：

操作权：该权限在平台属于临时授予的对某设备的操作权限，这也意味着随时会被被它的上级权限账号剥夺，它的上级别账号就是所有权权限。

所有权：该权限在平台属于永久授权的对某设备的操作权限(当然平台超级管理员可以进行所有权收回等管理)，这意味所有权账号对设备有完全的管理权(不止是享受设备端开放的完整的远程控制权限，还享受平台的一些特殊的管理服务特权)和设备操作权的临时性授权权限。该权限等同于在设备端本地操作，是对设备的最高控制权。

服务器对设备的控制权限管理与设备端对应的也分为三种权限状态，以文件系统的概念来说就是：

不可读不可写：无法查看设备更谈不上可控制；

可读不可写：可以查看设备信息但无操作权；

可读可写：有该设备的操作权。

再把上述三种控制权限状态根据设备的平台状态和账号级别对相关账号进行映射和授权，达到精准控制的目的。因为其复杂性本实施例通过下表8和表9进行说明。

表8物联网平台用户账号权限的划分列表

权限代号	许可范围
		4	平台所有账号
3	设备所有权账号和其所有下属子账号
		2	设备所有权账号和其授予操作权限的子账号
1	设备所有权账号
		0	无账号

表9物联网平台对设备权限的控制规则

3、设备的工作模型设计

首先，将设备看做一个容器，设备的工作模式看做黑匣子模型，参见附图2，设备容器中在工作模式一到工作模式N下，各个黑匣子模型工作状态下有入参(控制命令和设定参数)，出参(实时监控数据、临时数据、历史数据)。

设备的工作模型大致可分为：

工作模式设定模型：用于设定和通知该设备所处于哪种工作模式下，例如空调包括制冷、制热、除湿等工作模式；

工作参数模型：设备在工作时需要从外部获取到的各种设定参数，每种工作模式都有自己独立的工作参数模型；

监控参数模型：设备工作时产生并向外发送的数据参数模型；

历史记录模型：很多设备(如实验室设备、工厂的工艺性设备)每次运行过程会产生整个过程的记录信息，这些信息作为历史记录保存在物联网平台非常有用。所以设计了历史记录模型来传输这些信息并保存在物联网平台上；

临时数据模型：设备可随时自定义编辑的参数和在工作状态下临时性的不需要物联网平台保存的参数数据模型。

在本实施例中，交互流程管理模块13主要负责管理设备端与服务器端通讯和交互数据的交换动作规则，在设计交互流程的过程中，在确保正常足够的通讯的条件下，尽量避免使用重复不必要的交互信息。流程设计首先有设备状态满足，其次是流程发起方，再就是应答方合规的回应。

设备端与服务器端通讯和交互数据的流程包括设备开关机、设备本地运行、设备远程运行、设备数据上传、设备历史数据上传、设备断点续传、设备临时数据上传以及其他工作流程。

本实施例中具体对开机流程、观摩模式下的工作流程、远控模式下的工作流程、实时数据的上传流程和断点续传流程、历史记录上传流程以及其他流程中的设备校时流程共六个流程进行详细说明。

下面对上述的各个流程执行过程做详细的说明：

(1)开机流程

参见附图3，开机流程的过程如下：

设备端联网成功后，在status主题下下发9|至服务器端，服务器端设置设备状态为”online”，并返回状态码”A:1|”至设备端，设备端成功进入待机状态。

(2)观摩模式下的工作流程

参见附图4，观摩模式下的工作流程如下：

设备成功待机处于观摩模式，用户端向服务器端申请观摩，服务器发送命令”A:2|”至设备端，设备端判定申请是否通过，不通过时，在status主题下发送”3|”通知用户端申请被拒；通过时，设备端在status主题下发送”2|”，并判定实验是否开始，实验未开始时，通知服务器端等待运行；实验开始时，(只能在)设备端设置参数并上报服务器端，服务器端返回状态码”A:1|”，并设置设备状态为”run”，开始运行并进入实时数据上传流程。

(3)远控模式下的工作流程

参见附图5，远控模式下的工作流程如下：

设备成功待机处于远控模式，用户端向服务器端申请远控，服务器端发送命令”A:4|”到设备端，设备端判定申请是否通过，若申请不通过，在status主题下回复”5|”，通知用户端申请被拒；若申请通过，设备端在status主题下回复”4|”，服务器端下发工作模式，设备端在status主题下反馈”18|”，服务器端下发参数设置，设备端判定解析是否成功，若不成功，触发error并通知用户端，若成功，设备端在set主题下向服务器端反馈解析的参数设置，服务器端验证收到的参数设置，并发送运行命令”A:6|”至设备端，设备端在status主题下回复”1|”，服务器端设置设备状态为”run”，设备端开始运行并进入实时数据上传流程。

(4)工作状态下实时数据上传和断点续传流程

参见附图6，工作状态下实时数据上传和断点续传流程的部分流程如下：

设备成功运行并处于远控/观摩模式，在rundata主题下向服务器端上传数据，服务器端接收数据，并对数据进行解析处理和存储，设备端判定实验是否结束，若未结束，则继续在rundata主题下向服务器端上传数据，若结束，设备端在status主题下通知服务器端实验完成”6|”或”7|”，然后设备重新待机，服务器端不需要反馈，并设置设备状态为”online”，然后处理是按数据并设置实验结束状态。

(5)历史记录上传流程

参见附图7，历史记录上传流程具体如下：

设备成功待机处于远控模式，用户端向服务器端申请查看历史记录，服务器端向设备端发送命令”A:9|”并设置设备状态为”locked”，设备端在history主题下上传历史记录数据集，并判定上传是否完毕，若未完毕，继续在history主题下上传历史记录数据集，若完毕，设备端在status主题下发送”17|”至服务器端，服务器端确认是否接受完毕，若未接收完毕，发送命令”A:9|”参数至设备端，设备端继续在history主题下上传历史记录数据集；若接收完毕，服务器端向设备端发送命令”A:1|”并设置设备状态为”online”，设备端清除存储并待机。

(6)其他流程

参见附图8，本实施例以设备校时流程为例进行说明，流程具体如下：

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims

1.一种物联网平台接入设备管理系统，其特征在于，包括：通讯端、设备端、用户端以及服务器端；

所述通讯端包括主题分发管理模块、设备联网管理模块以及交互流程管理模块；

所述主题分发管理模块用于分别设定设备端向服务器端、服务器端向设备端、服务器端向用户端以及设备端之间通信的主题结构以及接收端的主题订阅规则；

所述交互流程管理模块用于对设备端与服务器端通讯和交互数据的流程进行设计；

所述设备端根据所述设备联网模型设置自身的工作状态、权限控制模式以及工作模型，按照所述主题分发规则与所述服务器端或另一设备端通信，并根据所述设备端与服务器端的交互流程执行联网开机和数据上传任务；

所述设备端的权限控制模式包括本地模式、观摩模式以及远控模式；

所述服务器端对应的控制权限包括不可读不可写、可读不可写以及可读可写；

2.根据权利要求1所述的一种物联网平台接入设备管理系统，其特征在于，所述设备端的工作状态包括关机状态、待机状态、运行状态和锁定状态。

3.根据权利要求2所述的一种物联网平台接入设备管理系统，其特征在于，所述待机状态具体包括本地工作模式和远程模式。

4.根据权利要求1所述的一种物联网平台接入设备管理系统，其特征在于，所述服务器端对应的状态包括离线状态、设备开机未连接状态、在线待机状态、设备运行状态以及设备锁定无操作权状态。

5.根据权利要求1所述的一种物联网平台接入设备管理系统，其特征在于，设备端与服务器端通讯和交互数据的流程包括开机流程、观摩模式下的工作流程、远控模式下的工作流程、实时数据的上传流程和断点续传流程以及历史记录上传流程。

6.根据权利要求1所述的一种物联网平台接入设备管理系统，其特征在于，所述设备端的工作模型包括工作模式设定模型、工作参数模型、监控参数模型、历史记录模型以及临时数据模型；

临时数据模型用于暂存设备端在工作时自定义编辑的参数以及临时性的参数。

7.根据权利要求1所述的一种物联网平台接入设备管理系统，其特征在于，所述主题分发管理模块设定的设备端向服务器端通信的主题结构包括设备端的SN码、固定值”service”以及消息分类标签tag。

8.根据权利要求7所述的一种物联网平台接入设备管理系统，其特征在于，所述消息分类标签tag包括：

错误代码标签error，表征向服务器上报设备端错误。