海量设备数据接入物联网操作的方法及系统与流程

1.本发明涉及物联网技术领域，具体涉及一种海量设备数据接入物联网操作的方法及系统。


背景技术：

2.现有技术中存在以下问题：
3.1、设备协议问题：市面上各个厂家的设备支持的协议不同，如opc，modbus tcp等，不同协议支持的通讯方式也不同，部分智能化设备能主动上报设备数据(其中某些设备上报的数据格式为协议特定格式)，而其余设备需要通过对应的协议被动采集数据；
4.2、设备通讯多样化问题；不同设备支持的通讯方式不尽相同，例如mqtt、tcp、http、coap
5.3、设备数据时效性问题：当接入百万级别的设备，同时设备上报频率相对较高时，设备数据一旦处理不及时，容易导致设备数据延迟问题，甚至导致数据积压；
6.4、设备控制问题：某些设备芯片不够智能化，当发送控制命令过于频繁时，设备可能会出现程序紊乱问题，控制命令与控制响应对应不上。
7.对本文提供了一种海量设备数据接入物联网操作的方法及系统，解决智能设备，需要厂商修改自身的芯片程序，根据alink的方式修改后再上报给阿里云。对于厂商来说，已生产出的设备，让其重新烧制芯片程序的方式，成本是十分高昂的问题，以及非智能设备，无法接入的问题。


技术实现要素：

8.针对现有技术的不足，本发明公开了一种海量设备数据接入物联网操作的方法及系统，用于解决智能设备，需要厂商修改自身的芯片程序，根据alink的方式修改后再上报给阿里云。对于厂商来说，已生产出的设备，让其重新烧制芯片程序的方式，成本是十分高昂的问题，以及非智能设备，无法接入的问题。
9.本发明通过以下技术方案予以实现：
10.第一方面，本发明提供了一种海量设备数据接入物联网操作的方法，包括以下步骤：
11.北向应用通过dmc提供的open api下发指令，然后发送给twin，并通过twin判断定义的协议类型；
12.若是私有协议则根据用户定义的脚本引擎得到对应结果后进入下一步，若为官方协议则直接进入下一步；
13.将任务发送给proxy；并根据定义的物模型，判断是否要等待控制响应，然后根据通讯类型下发数据至设备；
14.设备反馈控制结果至twin，twin做对应的逻辑处理，完毕后通过dmc再将控制结果返回给北向应用。
15.更进一步的，所述方法中，twin根据接收到的控制任务，找到对应的设备，根据定义的协议类型，如果是官方协议，标记设备为控制中，将任务发送给proxy。
16.更进一步的，所述方法中，twin根据接收到的控制任务，找到对应的设备，根据定义的协议类型，如果是私有协议，则将收到的控制任务，根据用户定义的脚本，通过脚本引擎得到对应结果，再发往proxy。
17.更进一步的，所述方法中，在twin收到设备控制结果时，如果检测到设备为私有协议类型，则将结果经过脚本引擎处理并得到真实结果。
18.更进一步的，所述方法中，proxy根据定义的物模型，判断是否要等待控制响应，如果不需要，则直接返回，反之则等待设备响应。
19.更进一步的，所述方法中，proxy收到数据后，根据设备定义的通讯类型，选择对应的通讯通道下发数据给设备，当收到设备控制结果时，发给twin。
20.更进一步的，所述方法中，设备上报数据时，通过proxy到达twin，根据定义的设备类型选择是否需要协议解析，再发送给dmc，然后回复给proxy一条回应，proxy再发给设备。
21.更进一步的，所述方法中，dmc收到设备数据后，通过mqtt发送设备实时值，再将其存储到时序数据库中。
22.第二方面，本发明提供了一种海量设备数据接入物联网操作的系统，用于实现第一方面所述的海量设备数据接入物联网操作的方法，包括
23.通信层proxy，用于提供不同通讯方式的接入；
24.影子设备层twin，用于针对每个设备，模拟对应的影子设备，实时处理设备上报的每一条数据，并对北向应用下发的设备控制，设定一定的任务队列，通过一次下发并等待控制回应的方式，同时其他控制任务进行阻塞，确保控制任务的有序性；
25.设备管理层dmc，用于对设备数据进行定量、定时的存储，存储到时序数据库influxdb中；将设备数据通过mqtt的方式推送给应用层，供用户实时获取；对外提供api接口，访问设备实时数据与历史数据。
26.本发明的有益效果为：
27.本发明提供了代理层用于设备接入，并分别实现了mqtt,tcp,http,coap等通讯组件。同时提供了私有协议脚本的方式接入可主动通讯，但设备协议为厂商自定义的设备。而对于需要被动通讯的设备，将其抽象为子设备，通过网关接入。从而针对各自厂家特定的设备，提供不同的方式快速接入，并在北向应用侧，获取到设备数据，进而解决了智能设备，需要厂商修改自身的芯片程序，根据alink的方式修改后再上报给阿里云。对于厂商来说，已生产出的设备，让其重新烧制芯片程序的方式，成本是十分高昂的问题，以及非智能设备，无法接入的问题。
附图说明
28.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
29.图1是海量设备数据接入物联网操作的系统结构图；
30.图2是本发明实施例官方协议下发过程流程图；
31.图3是本发明实施例私有协议下发过程流程图；
32.图4是本发明实施例设备上报数据过程流程图。
具体实施方式
33.为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
34.实施例1
35.本实施例提供了一种海量设备数据接入物联网操作的方法，包括以下步骤：
36.北向应用通过dmc提供的open api下发指令，然后发送给twin，并通过twin判断定义的协议类型；
37.若是私有协议则根据用户定义的脚本引擎得到对应结果后进入下一步，若为官方协议则直接进入下一步；
38.将任务发送给proxy；并根据定义的物模型，判断是否要等待控制响应，然后根据通讯类型下发数据至设备；
39.设备反馈控制结果至twin，twin做对应的逻辑处理，完毕后通过dmc再将控制结果返回给北向应用。
40.本实施例根据指令集操作系统提出的ilink通讯格式开发而成。而市面上的物联网，如阿里云，定义了一套alink规范，设备需要按照其提供的数据格式，通过mqtt上报。
41.本实施例方法进行性能压测结果如下：在100万tcp设备接入+5000qps数据上报情况下，运行了至少7天，从kafka消费情况看，基本没有出现波动，十分平稳，cpu占用比较稳定，平均占用25％，最高大约43％，内存平均占用67g，运行influxdb的硬盘io全程稳定，读写速率约143iops，写入约35mb/s，整个设备集成平台能够保持稳定运行状态。
42.本实施例支持不同类型的设备接入，并高效处理，同时保证顺序。同时，方便各种厂商与集成商的设备接入，同时方便获取设备实时数据。
43.实施例2
44.在具体实施层面，参见图2所示，本实施例提供了一种官方协议下发过程，具体如下：
45.北向应用通过dmc提供的open api，控制某个设备，调用定义的物模型中某项能力，本实施例进行优选时，如写入属性或者调用服务。
46.dmc接收到该指令时，发送给twin。
47.twin根据接收到的控制任务，找到对应的设备，根据定义的协议类型，如果是官方协议，不需要进行特定处理，标记设备为控制中，将任务发送给proxy；
48.proxy根据定义的物模型，是否要等待控制响应，如果不需要，则直接返回，反之则等待设备响应。
49.proxy收到数据后，根据设备定义的通讯类型，选择对应的通讯通道下发数据给设备；当收到设备控制结果时，发给twin。
50.twin收到设备控制结果后,做对应的逻辑处理，完毕后发给dmc；
51.dmc再将控制结果返回给调用方。
52.本实施例进行通讯类型优选时，如mqtt，tcp。
53.参见图3所示，本实施例提供了一种私有协议下发过程，具体如下：
54.本实施例私有协议的下发过程大体与官方协议相同，只是在twin检测到设备为私有协议类型时，需要将收到的控制任务，根据用户定义的脚本，通过脚本引擎得到对应结果，再发往proxy。
55.本实施例在twin收到设备控制结果时，如检测到设备为私有协议类型，需要将结果经过脚本引擎处理并得到真实结果。
56.参见图4所示，本实施例提供了一种设备上报数据过程，具体如下：
57.本实施例设备上报数据的流程，与控制流程相反，从下而上。
58.本实施例设备上报的数据通过proxy到达twin，根据定义的设备类型选择是否需要协议解析，再发送给dmc，然后回复给proxy一条回应，proxy再发给设备。
59.本实施例dmc收到设备数据后，通过mqtt发送设备实时值，再将其存储到时序数据库中。
60.实施例3
61.本实施例提供了一种海量设备数据接入物联网操作的系统，包括
62.通信层(proxy)：提供不同通讯方式的接入，本实施例进行优选时，如coap、mqtt、tcp、http。
63.影子设备层(twin)：针对每个设备，模拟对应的影子设备，实时处理设备上报的每一条数据。并对北向应用下发的设备控制，设定一定的任务队列，通过一次下发并等待控制回应的方式，同时其他控制任务进行阻塞，确保控制任务的有序性。
64.设备管理层(dmc)：对设备数据进行定量、定时的存储，存储到时序数据库influxdb中；将设备数据通过mqtt的方式推送给应用层，供用户实时获取；对外提供api接口，访问设备实时数据与历史数据。
65.本实施例首先抽象了proxy这一抽象层，对于各种设备的数据上报与控制命令下发，根据对应的通讯方式，提供了良好的支持，并可横向拓展。
66.本实施例中，当proxy收到设备数据后，将其存放到了kafka中，使用kafka可持久化消息这一功能保证当服务宕机重启后，仍可获取到之前的设备数据，而不会丢弃。
67.本实施例twin层，对于每个设备进行了数据隔离，当不同设备的上报频率不同时，上报数据过快的设备，不会影响到其他正常上报频率的设备。并结合对应的业务逻辑，对设备控制任务的下发，做到了一个控制命令的下发，对应一条控制响应，不会出现顺序紊乱的问题。
68.本实施例dmc层，将设备数据的最新值存储在内存中，方便api接口的访问获取；同时定时存储到redis中，服务宕机重启后可重新获取，不会丢失；并将设备实时数据，通过定时定量的方式存储到时序数据库influxdb中。
69.综上，本发明提供了代理层用于设备接入，并分别实现了mqtt,tcp,http,coap等通讯组件。同时提供了私有协议脚本的方式接入可主动通讯，但设备协议为厂商自定义的设备。而对于需要被动通讯的设备，将其抽象为子设备，通过网关接入。从而针对各自厂家
特定的设备，提供不同的方式快速接入，并在北向应用侧，获取到设备数据，进而解决了智能设备，需要厂商修改自身的芯片程序，根据alink的方式修改后再上报给阿里云。对于厂商来说，已生产出的设备，让其重新烧制芯片程序的方式，成本是十分高昂的问题，以及非智能设备，无法接入的问题。
70.以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。