CN103812937A - 一种物联网设备的接入和适配系统 - Google Patents

Abstract

本发明涉及一种物联网设备的接入和适配系统，包括：接入装置，用于自动接收设备的接入请求，进行设备的接入操作；协议匹配装置，用于对接入的设备通过协议的自适应匹配进行解析；数据解释装置，用于对解析后的设备数据进行转换解释。本发明通过该系统，能够将设备和协议作为模块进行开发并重用，同时，也支持将这些模块动态接入到该系统中进行使用，也支持对设备的自适应匹配。这种设备的接入和适配的系统，在实际测试的过程中，运行状况良好，其负载能力能够满足实际情况的要求，具有适用性。

Description

一种物联网设备的接入和适配系统

技术领域

本发明涉及计算机物联网技术领域，尤其涉及一种物联网设备的接入和适配系统。

背景技术

随着当今社会的不断发展和计算机技术的不断普及，物联网的应用越来越广泛。利用物联网技术将资源，即传感器设备的数据获取并解析的应用也越来越广泛。资源设备具有大规模性，异构性以及资源能力有限的特点。即一个项目可能接入大量的传感器，这些传感器资源很可能来自于不同的厂商，采用特定的协议进行解析。倘若这些传感器资源每一个都需要人工进行配置才能正常运行，显然将会是一件非常费时和费力的工作。因此，我们需要资源能够动态地接入，通过自适应系统，能够正确地使用。同时，并且每个资源运作能力有限，不能够将所有的处理步骤都放到资源节点中。如何利用有限的资源运作能力，将接入的数据用正确的资源解析出来，是一个值得关注的问题。综上所述，由于资源设备的大规模性，异构性以及资源能力有限的特点，开发一个资源管理平台，用这个平台来进行资源的接入、资源的自适应匹配以及资源的解释，就显得十分重要。

目前的资源管理平台，采用中间件的方式设计与实现。中间件是处于操作系统和应用程序之间的软件。中间件屏蔽了底层设备的复杂性，使得程序开发人员面对一个简单而统一的开发环境，减少程序设计的复杂性，将注意力集中在自己的业务上，不必再为程序在不同系统软件上的移植而重复工作，从而大大减少了技术上的负担。传统的资源管理平台，将协议接入的部分放到了网关上，通过网关来实现资源的自动接入。这样做容易导致两个方面的问题，一是网关的能力有限，由于资源的大规模性，资源的自动接入就会大量地增加网关的负载，从而导致网关本身的工作效率降低。二是这种方式容易造成单点失效的问题。就是当接入的其中一个协议发生故障的时候，有可能导致整个物联网就无法工作。因此，这种方式有待改善。

于此同时，传统的资源管理采用DPWS(Devices Profile WebServices)实现协议的动态接入。传统的WS定义了大量的标准，这些标准使得数据在传输的时候附带了大量的冗余信息。而DPWS协议将传统的WS协议进行了简化，减轻了数据在传输时候的负载。然而，DPWS仍然属于一种重量级的服务，数据在传输的时候依然携带了大量的冗余信息，这些冗余信息会增加网络的负载。

发明内容

本发明所要解决的技术问题是如何将物联网设备动态地接入到系统中，以及如何对协议进行自适应匹配的问题。

为此目的，本发明提出了一种物联网设备的接入和适配系统，包括：

接入装置，用于自动接收设备的接入请求，进行所述设备的接入操作；

协议匹配装置，用于对接入的所述设备通过协议的自适应匹配进行解析；

数据解释装置，用于对解析后的所述设备数据进行转换解释。

进一步地，所述接入装置，还用于自动接收所述设备的卸载请求。

进一步地，所述接入装置通过软件驱动所述设备的接入操作。

进一步地，所述协议匹配装置，包括：

协议搜寻模块，用于搜寻预先存储的协议栈；

协议分发模块，用于将所述设备初始数据分发给所述协议栈；

协议解析模块，用于通过遍历所述协议栈对所述设备进行所述初始数据的解析；

绑定模块，用于建立所述设备与匹配协议之间的绑定关系；

发送模块，用于将解析后的数据发送至所述数据解释装置。

进一步地，所述绑定模块还用于建立所述设备与资源之间的绑定关系。

进一步地，所述数据解释装置，包括：

接收模块，用于接收所述协议栈解析后的数据；

第一转换模块，用于通过资源模型将解析后的所述数据转换为资源观测数据；

获取模块，用于通过所述设备与资源的绑定关系，获取传感器标识；

第二转换模块，用于通过所述资源模型将所述传感器标识转换为情景数据。

具体地，所述协议栈包括：协议栈ID、协议层的数量以及最顶层的协议层。

具体地，所述协议栈的建立方式为通过addLayer方式以及removeLayer方式。

通过采用本发明所公开一种物联网设备的接入和适配系统，通过该系统，能够将设备和协议作为模块进行开发并重用，同时，也支持将这些模块动态接入到该系统中进行使用，也支持对设备的自适应匹配。这种设备的接入和适配系统，在实际测试的过程中，运行状况良好，其负载能力能够满足实际情况的要求，具有适用性。

附图说明

通过参考附图会更加清楚的理解本发明的特征和优点，附图是示意性的而不应理解为对本发明进行任何限制，在附图中：

图1示出了本发明实施例中的一种物联网设备的接入和适配系统结构图；

图2示出了本发明实施例中的一种物联网设备的接入和适配系统的组件状态变换图；

图3示出了本发明实施例中的一种物联网设备的接入和适配系统的协议匹配装置的结构图；

图4示出了本发明实施例中的一种物联网设备的接入和适配系统的协议匹配装置中的协议分发模块的结构图；

图5示出了本发明实施例中的一种物联网设备的接入和适配系统的数据解释装置的结构图；

图6示出了本发明实施例中的一种物联网设备的接入和适配系统的协议匹配流程图；

图7示出了本发明实施例中的一种物联网设备的接入和适配系统的资源适配过程的流程图；

图8示出了本发明实施例中的一种物联网设备的接入和适配系统的协议匹配装置中的绑定模块的结构图；

图9示出了本发明实施例中的一种物联网设备的接入和适配系统的协议栈的具体结构。

具体实施方式

下面将结合附图对本发明的实施例进行详细描述。

如图1所述，本发明提供了一种物联网设备的接入和适配系统10，包括：接入装置101、协议匹配装置102以及数据解释装置103。

具体地，接入装置101用于自动接收设备的接入请求，进行设备的接入操作；协议匹配装置102用于对接入的设备通过协议的自适应匹配进行解析；数据解释装置103用于对解析后的设备数据进行转换解释。

进一步地，接入装置101还用于自动接收设备的卸载请求，且接入装置101通过软件驱动设备的接入操作。

具体地，协议匹配装置102包括：协议搜寻模块1021用于搜寻预先存储的协议栈，其中，协议栈包括：协议栈ID、协议层的数量以及最顶层的协议层，且协议栈的建立方式为通过addLayer方式以及removeLayer方式；协议分发模块1022用于将设备初始数据分发给协议栈；协议解析模块1023用于通过遍历协议栈对设备进行初始数据的解析；绑定模块1024用于建立设备与匹配协议之间的绑定关系；发送模块1025用于将解析后的数据发送至数据解释装置。

进一步地，绑定模块1024还用于建立设备与资源之间的绑定关系。

具体地，数据解释装置103包括：接收模块1031用于接收协议栈解析后的数据；第一转换模块1032用于通过资源模型将解析后的数据转换为资源观测数据；获取模块1033用于通过设备与资源的绑定关系，获取传感器标识；第二转换模块1034用于通过资源模型将传感器标识转换为情景数据。

图2示出了本发明实施例中的一种物联网设备的接入和适配系统的组件状态变换图。

简言之，物联网设备的接入和适配系统的关键是在于接入装置和协议匹配装置。

对于接入装置，可以分为：设备和协议的动态接入部分，其重点在于对设备和协议接入部分在资源管理平台中声明周期的管理，其中，数据解释装置在资源管理平台上。

具体地，从设备和协议开发完成，到接入到具有数据解释装置的资源管理平台中，需要经过未安装、安装、解析、启动、激活状态。而将设备和协议从具有数据解释装置的资源管理平台中卸载，需要经过激活、停止、解析、未安装状态。由此可见，设备和协议在具有数据解释装置的资源管理平台中，总共存在未安装、安装、解析、启动、停止、激活6种状态。这6种状态通过资源管理平台中的触发事件，相互转换。使得设备和协议能够在资源管理平台中正常运作。这6种状态的详细描述如下：

1).UNINSTALLED，未安装状态。处于未安装状态的组件导出的Package和包含的其他资源都是不可使用的。UNINSTALLED的状态值为整型数1，其中，开发完成之后的设备和协议，称为组件。

2).INSTALLED，已安装状态。组件处于已安装状态就意味着它已经通过了资源管理平台的有效性校验并产生了组件标识名，但这时还未对它定义的依赖关系进行解析处理。INSTALLED的状态值为整型数2。

3).RESOLVED，已解析状态。组件处于已解析状态说明资源管理平台已经根据元数据信息中描述的依赖关系成功地在类名空间中找到它所有的依赖包，这时它导出的Package就可以被其他组件导入使用。RESOLVED的状态值为整型数4。

4).STARTING，启动中状态。组件处于启动中状态说明它的start()方法已经被调用，但是还没执行结束。如果start()方法正常执行结束，组件将自动转换到ACTIVE状态；否则，如果start()方法抛出了异常，组件将退回到RESOLVED状态。STARTING的状态值为整型数8。

5).STOPPING，停止中状态。组件处于停止中状态说明它的stop()方法已经被调用，但是还没执行结束。无论stop()是正常结束还是抛出了异常，在这个方法退出之后，组件的状态都将转为RESOLVED。STOPPING的状态值为整型数16。

6).ACTIVE，组件处于激活状态，说明start()方法已经执行完毕，如果没有其他动作，组件将继续维持ACTIVE状态。ACTIVE的状态值为整型数32。

图3示出了本发明实施例中的一种物联网设备的接入和适配系统的协议匹配装置的结构图。

具体地，协议匹配装置的核心为主要维护一个协议仓库，这个仓库存储解析数据消息所使用的各种协议。这些协议能够在系统运行的情况下，动态地接入到系统中或者从系统中删除。当底层设备传输初始数据给系统后，系统中的协议匹配装置会很快搜寻预先存储的协议栈；将设备初始数据分发给协议栈；通过遍历协议栈对设备进行初始数据的解析；同时，建立设备与匹配协议之间的绑定关系，最后将解析后的数据发送至具有数据解释装置的资源平台层。

图4示出了本发明实施例中的一种物联网设备的接入和适配系统的协议匹配装置中的协议分发模块的结构图。

当有一个新的设备接入到系统中并发送消息给系统后，由于对应的资源还没有通过协议描述与某个具体的协议栈进行绑定，故系统首先将原始消息分发给各个协议栈，协议栈尝试使用已有的协议栈进行解析。如果存在能够正确解析消息的协议栈，就将该协议栈与对应的资源描述进行绑定。当该设备第二次发送消息给系统时，系统就通过协议描述找到具体的协议栈对消息进行解析。使用一个绑定模块对所有的绑定关系进行管理，能够定时地解除绑定关系并重新适配，以保证绑定关系的实时性。

进一步地，绑定关系分为两种，一种是将设备与协议栈建立绑定关系。该绑定关系用于当设备传输原始字节流时，调用对应的绑定协议栈对该原始字节流进行解析；另一种绑定关系是设备与资源之间建立的绑定关系。通过该绑定关系，可以将对应的代表传感器部分的数据转换为相应的具有实际意义的资源。

图5示出了本发明实施例中的一种物联网设备的接入和适配系统的数据解释装置的结构图。

具体地，通过协议解析得到的数据是基于传感器的。其得到的主要数据包含：设备号、PLC号、传感器号、值。采用基于语义的资源解释，就可以将对应的解析值转换为具有实际意义的观测值。

进一步地，该语义解析的过程分为两个部分，首先，将原始数据通过元数据转换为资源观测数据，此时，数据已经具备了实际的意义。接下来，将对应的传感器标识转换为具有实际意义的资源。经过这两部转换之后，数据具有了实际意义，能够用来正确标识一个具有具体意义的资源的值。

图6示出了本发明实施例中的一种物联网设备的接入和适配系统的协议匹配流程图。

步骤S601，新的协议到来，令初始化循环访问变量i=0。

步骤S602，获取协议仓库中第i个协议。

步骤S603，用迭代的方式逐一获取协议仓库中的协议与添加协议进行比较。

步骤S604，若相同，则继续进行协议仓库中的协议迭代，运行i++。

步骤S605，当与添加协议比较不相同时，则继续判断是否存在相同协议。

步骤S606，若存在相同协议，则将协议加入到仓库中；若不存在相同协议，则步骤S607进行退出。

具体地，当有一个按照规范开发的协议接入并启动时，系统首先获取到该协议的名称，其中，协议名称是协议的唯一标识，不同的协议所拥有的名称是不一样的，然后，系统获取到具有数据解释装置的资源管理平台中的协议仓库，其中，协议仓库中包含了已经接入的所有的协议，这些协议拥有不同的名称。

进一步地，通过遍历协议仓库中的所有协议并与接入的协议进行对比，确保接入的协议不会出现重复。当删除协议时，首先需要找到协议仓库中对应的协议，然后将其进行删除。

进一步地，将设备和协议作为最基本的模块进行开发，让具有数据解释装置的资源管理平台负责维护对设备和协议的声明周期进行维护，对于声明周期的转换提供相对应的操作。这样，接入的设备和协议就能够实现动态接入的效果，而设备的接入除了接口规范不同之外，其余的操作过程与协议的接入原理大致是相同的。

图7示出了本发明实施例中的一种物联网设备的接入和适配系统的资源适配过程的流程图。

具体地，当设备向系统发送消息时，首先检查设备是否通过协议描述与具体的协议栈建立了绑定关系。如果已经存在绑定关系，就直接调用该协议栈进行解析。否则，将该消息分发给所有的协议栈进行解析。协议栈接到对应消息后，首先访问协议栈的顶层协议层中的协议对消息进行解析，如果解析成功并且没有剩余的消息时，返回解析成功的标志；如果还有剩余消息并且该协议层不是最底层时，递归调用下一层协议的analyze方法进行解析；若是解析失败就直接返回。在最底层协议解析成功后，若还有剩余消息未解析，则返回失败。否则，返回成功。

进一步地，倘若解析成功，通过协议描述将发送对应消息的设备与具体的协议栈建立一个绑定关系。绑定模块会对这个绑定关系进行管理。

图8示出了本发明实施例中的一种物联网设备的接入和适配系统的协议匹配装置中的绑定模块的结构图。

步骤S801，获取连接实例的标志名。

步骤S802，获取协议栈。

步骤S803，判断是否存在与标识名相等的连接实例。

步骤S804，若不存在与标识名相等的连接实例，则绑定失败，退出。

步骤S805，若存在与标识名相等的连接实例，则获取封装后的连接实例。

步骤S806，判断是否已经建立绑定关系。

步骤S807，若建立了绑定关系，则删除该绑定关系。

步骤S808，若没有建立绑定关系，则设置绑定关系。

步骤S809，判断绑定关系是否超时。

步骤S810，若绑定关系超时，则删除绑定关系。

步骤S811，若绑定关系没有超时，等待一段时间。

具体地，绑定模块中存储着一个绑定仓库。该绑定仓库存储了目前系统中建立的所有绑定关系。建立绑定关系的方式有两种，一种是手动建立，一种是通过适配的方式建立。

进一步地，手动建立指的是通过配置界面手动建立一个协议栈，并将协议栈与对应的设备建立绑定关系，该方式提供一个协议栈制作的界面，可以选择需要进行绑定的设备标识、该协议栈的层次、该协议栈的名字以及对应的每个协议层次上所使用的协议。对于手动绑定的协议栈，其协议栈的各种相关参数都是固定的，无需再对设备传递的原始字节流进行适配。此种方式主要用于需要系统首先给设备发送数据请求消息的设备，这种方式要求使用人员必须对设备有着比较清楚的了解。

另一种方式是通过设备首先发送的消息进行解析，解析之后将正确的协议栈通过协议描述与设备绑定。该种方式需要对协议栈进行组装。具体地，这种方式首先构建协议栈中的第1层，该协议栈循环遍历协议仓库中存在的所有协议并调用该协议对原始字节流进行解析，倘若解析成功，就获取到剩下的未解析字节流。若未解析字节流为空，则解析成功，将该生成的协议栈与对应的设备建立绑定关系；如果未解析字节流不为空，则构建协议栈的第2层，然后再次调用协议仓库中存在的所有协议对剩余未解析字节流进行解析。如此操作，直到不存在剩余字节流或者该层遍历协议仓库解析失败。对于后面一种情况，将回到上一层继续遍历进行解析直到不存在上一层为止。若是已返回到第1层，并且遍历协议仓库仍然解析失败。则说明该原始字节流解析失败，解析该原始字节流需要制作额外的协议。经过上述步骤，整个自动绑定的过程就实现了。该绑定过程需要设备首先向资源管理平台发送原始字节流，这个原始字节流能够构建出完整的协议栈。自动绑定的好处在于，无需使用人员手动为设备设定绑定关系，倘若存在大量的设备，并且这些设备所使用的协议相差不大时，使用自动绑定可以避免大量的手动绑定操作，让使用人员将节省的时间投入到需要的工作中。

进一步地，建立绑定关系之后，需要对绑定关系进行管理。当绑定关系失效的时候，需要将绑定关系移除。解除主要有两种情况：一种是使用绑定的协议栈解析消息失败，另一种是绑定关系过期，需要重新建立绑定关系。

具体地，对于第一种情况，在调用绑定关系失败之后，将该绑定关系移除即可；对于第二种情况，则为其开启一个线程，当到达设定时间时，该线程移除绑定关系，然后终止即可。

如上所述的绑定关系指的是设备与协议栈建立的绑定关系，在具有数据解释装置的资源管理平台中，还存在着另一种绑定关系，就是设备同资源之间建立的绑定关系。由于设备一经使用，其对应的资源的意义就不会改变。因此，可以使用资源模型来存储设备与资源的绑定关系。在每次使用设备之前，为设备在资源模型中设立绑定关系，通过资源模型，就可以将得到的传感器标识转换为对应的实体信息。

图9示出了本发明实施例中的一种物联网设备的接入和适配系统的协议栈的具体结构。

具体地，使用协议栈是因为初始数据，即原始消息的解析可能需要不止一个协议。因此，每一个协议栈必须包含一个或者多个协议层次，每一个层次包含一个独立的用于解析消息所需要的协议。其中，一个协议栈包含协议栈ID，协议层的数量和最顶层的协议层，且协议栈可以通过addLayer和removeLayer方法来动态地构建。可以通过getUpper和getLower方法来遍历所有的协议层次。通过analyze方法则可以调用对应协议层中的协议对消息进行解析。

进一步地，按照同样的方法设计generate方法，即生成请求消息。不同的是，generate构造消息的时候，是从最底层协议一直到最顶层协议。按照上述解析过程处理之后，数据递交到具有数据解释装置的资源平台层。资源平台层主要负责进行数据解释的工作，即由数据解释装置来执行完成的。

进一步地，由于对数据进行解释的介质有很多种，可以通过数据库配置资源模型和绑定关系，也可以通过本体库建立资源模型和绑定关系。因此，提供一个数据解释的接口，该接口完成数据解释的功能。根据不同的实际情况，可以选择不同的实现方式。在大多数的实验中，使用本体库的方式对该过程进行模拟。通过本体库建立的资源模型，将对应的原始数据通过元数据转换为对应的观测数据，再通过设备与资源建立的绑定关系，将传感器标识转换为对应的资源，数据解释的功能即可完成。转换成情景数据之后，还可以通过资源模型产生事件。

进一步地，要产生事件，首先需要定义一个事件规则。主要需要定义这个事件对应的资源和实体，以及产生事件的规则。例如：要生成一个超限事件。就需要知道这个超限事件对应的资源和实体。

为了方便理解上述实例，进行举例：该超限事件对应的实体是A小区B栋楼C房，资源是室内温度。就需要在资源模型中为该事件设置对应的实体为A小区B栋楼C房，资源为室内温度。而该超限事件对应的规则是当室内温度高于30度时，报警。因此，在资源模型中将该超限事件对应的规则设置为室内温度高于30度。假设该事件为报警事件，当对应的设备传输原始字节流并经过解析和解释后，得到对应的实体和资源，且其值大于30，那么，就会产生报警事件提示用户室内温度过高，需要采取相应措施，经过数据解释和事件产生后，资源管理平台的工作完成，之后会将数据递交到应用层，供各个应用程序使用。

本发明提供一种物联网设备的接入和适配系统，通过该系统，能够将设备和协议作为模块进行开发并重用，同时，也支持将这些模块动态接入到该系统中进行使用，也支持对设备的自适应匹配。这种设备的接入和适配系统，在实际测试的过程中，运行状况良好，其负载能力能够满足实际情况的要求，具有适用性。

虽然结合附图描述了本发明的实施方式，但是本领域技术人员可以在不脱离本发明的精神和范围的情况下做出各种修改和变型，这样的修改和变型均落入由所附权利要求所限定的范围之内。

Claims (8)

1.一种物联网设备的接入和适配系统，其特征在于，包括：

接入装置，用于自动接收设备的接入请求，进行所述设备的接入操作；

协议匹配装置，用于对接入的所述设备通过协议的自适应匹配进行解析；

数据解释装置，用于对解析后的所述设备数据进行转换解释。

2.如权利要求1所述的系统，其特征在于，所述接入装置，还用于自动接收所述设备的卸载请求。

3.如权利要求1所述的系统，其特征在于，所述接入装置通过软件驱动所述设备的接入操作。

4.如权利要求1所述的系统，其特征在于，所述协议匹配装置，包括：

协议搜寻模块，用于搜寻预先存储的协议栈；

协议分发模块，用于将所述设备初始数据分发给所述协议栈；

协议解析模块，用于通过遍历所述协议栈对所述设备进行所述初始数据的解析；

绑定模块，用于建立所述设备与匹配协议之间的绑定关系；

发送模块，用于将解析后的数据发送至所述数据解释装置。

5.如权利要求1所述的系统，其特征在于，所述绑定模块还用于建立所述设备与资源之间的绑定关系。

6.如权利要求1所述的系统，其特征在于，所述数据解释装置，包括：

接收模块，用于接收所述协议栈解析后的数据；

第一转换模块，用于通过资源模型将解析后的所述数据转换为资源观测数据；

获取模块，用于通过所述设备与资源的绑定关系，获取传感器标识；

第二转换模块，用于通过所述资源模型将所述传感器标识转换为情景数据。

7.如权利要求4所述的系统，其特征在于，所述协议栈包括：协议栈ID、协议层的数量以及最顶层的协议层。

8.如权利要求4所述的系统，其特征在于，所述协议栈的建立方式为通过addLayer方式以及removeLayer方式。

Images