CN104363290B - 基于插件形式在上位机中实现跨协议组网的方法 - Google Patents

Abstract

本发明涉及一种基于插件形式在上位机中实现跨协议组网的方法，其中包括上位机加载协议插件和设备模板插件；上位机调用协议实体链表中的初始化功能函数，并得到设备描述符集；上位机查询设备描述符集中的设备信息，并找到设备信息所匹配的设备模板；上位机调用所匹配的设备模板中的创建设备对象功能函数来创建设备对象；上位机更新设备对象的配置协议信息和简要描述信息。采用本发明的基于插件形式在上位机中实现跨协议组网的方法，以插件的方式添加任意协议和设备，在不影响程序原有功能的基础实现各种协议无缝兼容，结构简单，移植性强，具有更加广泛的应用范围。

Description

基于插件形式在上位机中实现跨协议组网的方法

技术领域

本发明涉及通讯组网技术领域，尤其涉及物联网通讯组网领域，具体是指一种基于插件形式在上位机中实现跨协议组网的方法。

背景技术

如今智能家居(楼宇)都是得益于低功耗无线通讯技术的逐渐成熟，以及物联网概念的催化，目前智能家居所采用的联网技术最典型的主要有：Wi-Fi(无线保真，一种无线网路通信技术的品牌，由Wi-Fi联盟所持有)、蓝牙、ZigBee(基于IEEE802.15.4标准的低功耗局域网协议，又称紫蜂协议)和Z-Wave(由丹麦公司Zensys一手主导的无线组网规格)等。这些2.4G或者低于1G频率的无线收发协议方案的成熟为建立家庭或者楼宇的设备管理网络提供了基础，上述方案各有特点如下：

1)Wi-Fi适合建立相对复杂，网络规模较大或者数据交互比较大的网络，比如音视频监控或者大规模网络。并且可以实现与广域网的无缝连接。目前缺点是功耗较高，对设备上MCU(Micro Control Unit，微控制器)的要求也比较高从而不适用于使用电池供电的小设备。

2)蓝牙具有相对较高的带宽，可以实时传送数字音频或者简单的模拟音频及数字文件。特别是现在的低功耗蓝牙(V4.0)也非常适合家庭组网。缺点在于传输距离以及接入点(AP)限制了网络规模。相信随着蓝牙技术的进一步成熟，会有更好的前景。

3)ZigBee技术标准化到现在业已11年。从目前来看是非常具有活力的一种方案。ZigBee是开源项目，在非商用情况下可以不用付任何版权费。而且由于ZigBee联盟的存在，使得ZigBee技术充分发展，目前智能家居领域已经超过600家企业的产品进入市场，而智能楼宇方面也有超过400家企业的产品。能如此在物联领域大行其道除了主要受益于ZigBee是开源项目外，它的低功耗还有方便的组网能力是最大卖点。虽然没有大的带宽，但是作为控制报文的传输来说这个带宽却是足够的。再加上ZigBee联盟的存在，使得产品开发时可以得到大量其他ZigBee开发人员的先期实践经验与技术支持。所有这些让ZigBee在家庭(楼宇)自动化领域站稳了脚跟。

4)Z-Wave是独立于ZigBee的另外一大阵营。与ZigBee一样，Z-Wave也有自己的联盟。目前已经有超过300家企业加入。其中包括了GE，Evolve，Ingersoll-Rand，Linear，FAKRO和Sigma Designs。使用了不同于ZigBee(BPSK(Binary Phase Shift Keying，二相相移键控，用于数字信号与高频模拟信号调制的一种方法)/OQPSK(Offset QuadraturePhase Shift Keying，偏移四相相移键控，一种数字调制方法))的GFSK(Gauss frequencyShift Keying，高斯频移监控)调制解调，并且只使用低于1G赫兹的频段。其他与ZigBee可说不分伯仲，所以也得到了大量的拥埠。

另外还有TI自定义的SimpliciTI(由TI主导的开源组网协议)等方案，但市场主流就是上述几种，而且各自建立了庞大的生态系统。很多产品已经能实现安防，灯光控制，窗帘控制，红外控制，报警等功能。控制终端也比较丰富，如：手机，电脑，带显示屏的工控设备等，不一一列举。

然而，物联网的发展也存在以下问题：

1.对于市场来说，可选方案越多，竞争就越激烈，对下游厂商就越有利。但是目前可选方案不算多，而且各自形成了技术壁垒，造成非我即他的场面。特别是ZigBee和Z-Wave两大阵营之间，因为两者同质化程度比较高。

2.如果最终消费者(个人或者单位)需要的产品分别需要两种方案时就遇上了麻烦。因为两个产品互相不兼容，这样就需要上层应用来区分处理两个网络的管理和访问接口，抑或需要两个应用来分别进行管理。大大增加了开发投入与产品质量风险，并且很多都是重复开发。

3.目前厂商在开发定位自己的智能家居或者智能楼宇产品的时候往往被迫先选好立场。要么使用ZigBee，要么使用Z-Wave，选好之后与被弃用方案就基本绝缘。这无异于增加了生产企业的开发风险。每个方案都有自己的优劣。如果不能取长补短那研发的产品很可能存在缺陷。

4.长期分立而不能合作的方案无益于市场实际需求的解决。对整个智能家庭(楼宇)领域来说也难以有一个最大化的促进。

物联网以小网(连接家庭或楼宇)，中网(连接社区)，大网(连接世界)为构成元素。而目前智能家庭(楼宇)就是小网的代表，在整个物联网概念中是基石。小网的发展健康与否直接关系物联网的成败。尽管从产品角度还有成本问题(动辄几千上万的产品费用也是影响智能家居/楼宇快速普及的一个因素)，另外，低效的开发模式也会造成开发成本(影响产品价格)上扬。

发明内容

本发明的目的是克服了上述现有技术的缺点，提供了一种以插件的方式添加任意协议和设备，在不影响程序原有功能的基础实现各种协议无缝兼容的基于插件形式在上位机中实现跨协议组网的方法。

为了实现上述目的，本发明的基于插件形式在上位机中实现跨协议组网的方法具有如下构成：

该基于插件形式在上位机中实现跨协议组网的方法，其主要特点是，所述的方法包括以下步骤：

(1)上位机加载协议插件，并将新生成的协议实体添加至协议实体链表中；

(2)所述的上位机加载设备模板插件，并创建所述的设备模板插件对应的设备模板；

(3)所述的上位机查询协议实体链表，并调用所述的协议实体链表中的初始化功能函数；

(4)所述的上位机通过所述的初始化功能函数得到设备描述符集；

(5)所述的上位机查询所述的设备描述符集中的设备信息，并找到所述的设备信息所匹配的设备模板；

(6)所述的上位机调用所匹配的设备模板中的创建设备对象功能函数来创建设备对象，并添加至设备对象链表中；

(7)所述的上位机更新所述的设备对象的配置协议信息和简要描述信息。

进一步地，所述的上位机加载协议插件，包括以下步骤：

(1.1)所述的上位机判断协议插件目录下是否存在所述的协议插件的文件；

(1.2)如果判断结果为所述的插件协议插件目录下存在所述的协议插件的文件，则继续步骤(1.3)，否则继续步骤(1.4)；

(1.3)所述的上位机加载所述的协议插件的文件；

(1.4)所述的上位机停止加载协议插件。

更进一步地，所述的将新生成的协议实体添加至所述的协议实体链表，包括以下步骤：

(1.5)所述的上位机判断是否存在协议插件入口函数，如果是，则继续步骤(1.6)，否则返回上述步骤(1.1)；

(1.6)所述的上位机调用所述的协议插件入口函数，并将新生成的协议实体添加至所述的协议实体链表中。

进一步地，所述的上位机加载设备模板插件，包括以下步骤：

(2.1)所述的上位机判断设备模板插件目录下是否存在所述的设备模板插件的文件；

(2.2)如果判断结果为所述的设备模板插件目录下存在所述的设备模板插件的文件，则继续步骤(2.3)，否则继续步骤(2.4)；

(2.3)所述的上位机加载所述的设备模板插件的文件；

(2.4)所述的上位机停止加载设备模板插件。

更进一步地，所述的创建所述的设备模板插件对应的设备模板，包括以下步骤：

(2.5)所述的上位机判断是否存在设备模板插件入口函数，如果是，则继续步骤(2.6)，否则返回上述步骤(2.1)；

(2.6)所述的上位机调用所述的设备模板插件入口函数，并将新生成的设备模板添加至所述的设备模板链表中。

更进一步地，其特征在于，所述的步骤(1)之前，包括以下步骤：

(0)所述的上位机判断是否收到远程设备的初始化请求，如果是，则继续步骤(1)，否则继续步骤(0)。

更进一步地，所述的上位机查询协议实体链表，包括以下步骤：

(3.1)所述的上位机判断是否查询找到所述的协议实体链表，如果是，则继续步骤(3)，否则继续步骤(3.2)；

(3.2)所述的上位机启动异步事件服务；

(3.3)所述的上位机进入正常工作状态，并等待其它调用指令。

采用了本发明的基于插件形式在上位机中实现跨协议组网的方法，具有以下社会效益：

1、可以兼容多种技术

本发明可以把不同公司的组网技术糅合在一起，生产厂商提供符合本设计协议插件标准的协议就能扩容进来，减少重复设计，节省人力与物力成本。

2、可以兼容不同公司产品

只要符合设备插件接口标准的设备就可以无缝接入系统，所以只需要专注于设备微控制器(MCU)程序的实现即可，无需考虑上位机的实现，这样工作量将会比全系统设计减少90％以上，对于有些公司想尽快推出产品非常有利，工期的缩短也许可以带来巨大的经济效益。

3、降低开发成本

因为插件接口的标准定义，是以应用软件在操作网络资源的时候非常规范，不用针对每个网络做相应的初始化，也不用针对每个设备做相应的初始化。应用软件实现的目的和流程得到统一。

4、移植性强

本发明的插件接口具有强大的可移植性，提高软件开发效率，对企业的智能家居设计及其他物联网设计提供极大的便利，应用范围也十分广泛。

附图说明

图1为本发明的基于插件形式在上位机中实现跨协议组网的方法的流程图。

图2为本发明的智能家居系统的硬件结构图。

图3为本发明的系统内核结构示意图。

图4为本发明的架构内核的调用关系示意图。

图5为本发明的加载各类插件的框架流程图。

图6为本发明的一个具体实施例的完整流程图。

图7为本发明的网络结构示意图。

具体实施方式

为了能够更清楚地描述本发明的技术内容，下面结合具体实施例来进行进一步的描述。

针对目前的技术问题，解决方案包括以下内容：

1.实现多种组网技术的插件化(Plug-in)，添加新组网协议只需增加一个协议插件且该插件按照设计要求实现即可正常工作，同时，允许第三方设计的协议产品接入，比如在已有ZigBee协议的基础上，增加一个Z-Wave的协议插件就可以实现扩网；

2.实现设备对象类型模板的插件化(Plug-in)，添加新类型设备模板只需添加插件且插件按照设计要求实现即可正常工作，允许第三方设计的产品接入；

3.实现设备与协议的分离，通过软件抽象，把协议的收发功能动态配置给设备，如此，同样的设备，改装了RF(Radio Frequency，射频)模块就能接入新的协议网络中去。

4.软件架构可以在Windows，Linux，Android，IOS运行起来，可以适应各种环境。

通过以上四个方面的设计，就可以做到各种组网技术及远程设备的全方位融合，只要用户愿意，设计方可以添加任意协议和设备，而且只是以插件的方式，丝毫不影响原有的功能。理论上来说无需修改应用程序本身，就可以实现各种协议的无缝融合。

请参阅图1，在一种实施方式中，本发明的基于插件形式在上位机中实现跨协议组网的方法包括以下步骤：

(1)上位机加载协议插件，并将新生成的协议实体添加至协议实体链表中；

(2)所述的上位机加载设备模板插件，并创建所述的设备模板插件对应的设备模板；

(3)所述的上位机查询协议实体链表，并调用所述的协议实体链表中的初始化功能函数；

(4)所述的上位机通过所述的初始化功能函数得到设备描述符集；

(5)所述的上位机查询所述的设备描述符集中的设备信息，并找到所述的设备信息所匹配的设备模板；

(6)所述的上位机调用所匹配的设备模板中的创建设备对象功能函数来创建设备对象，并添加至设备对象链表中；

(7)所述的上位机更新所述的设备对象的配置协议信息和简要描述信息。

在一种优选的实施方式中，所述的上位机加载协议插件，包括以下步骤：

(1.1)所述的上位机判断协议插件目录下是否存在所述的协议插件的文件；

(1.2)如果判断结果为所述的插件协议插件目录下存在所述的协议插件的文件，则继续步骤(1.3)，否则继续步骤(1.4)；

(1.3)所述的上位机加载所述的协议插件的文件；

(1.4)所述的上位机停止加载协议插件。

在一种更优选的实施方式中，所述的将新生成的协议实体添加至所述的协议实体链表，包括以下步骤：

(1.5)所述的上位机判断是否存在协议插件入口函数，如果是，则继续步骤(1.6)，否则返回上述步骤(1.1)；

(1.6)所述的上位机调用所述的协议插件入口函数，并将新生成的协议实体添加至所述的协议实体链表中。

在一种优选的实施方式中，所述的上位机加载设备模板插件，包括以下步骤：

(2.1)所述的上位机判断设备模板插件目录下是否存在所述的设备模板插件的文件；

(2.2)如果判断结果为所述的设备模板插件目录下存在所述的设备模板插件的文件，则继续步骤(2.3)，否则继续步骤(2.4)；

(2.3)所述的上位机加载所述的设备模板插件的文件；

(2.4)所述的上位机停止加载设备模板插件。

在一种更优选的实施方式中，所述的创建所述的设备模板插件对应的设备模板，包括以下步骤：

(2.5)所述的上位机判断是否存在设备模板插件入口函数，如果是，则继续步骤(2.6)，否则返回上述步骤(2.1)；

(2.6)所述的上位机调用所述的设备模板插件入口函数，并将新生成的设备模板添加至所述的设备模板链表中。

在一种更优选的实施方式中，其特征在于，所述的步骤(1)之前，包括以下步骤：

(0)所述的上位机判断是否收到远程设备的初始化请求，如果是，则继续步骤(1)，否则继续步骤(0)。

在一种更优选的实施方式中，所述的上位机查询协议实体链表，包括以下步骤：

(3.1)所述的上位机判断是否查询找到所述的协议实体链表，如果是，则继续步骤(3)，否则继续步骤(3.2)；

(3.2)所述的上位机启动异步事件服务；

(3.3)所述的上位机进入正常工作状态，并等待其它调用指令。

在实际应用中，如图2～4所示，一个智能家居系统从硬件层次结构上一共分为三层，从上往下依次为：

主机(上位机)；

设备HUB(集线器，例如USB dongle等)；

设备端点。

从软件上可以分为四层：

应用层，实现设备对象的枚举与访问管理。并且提供系统事件处理的回调函数。

内核层，实现对协议与设备的动态加载以及系统异步事件的处理与转发(安卓系统为服务层)；

协议层，为所属对象提供访问途径；

设备对象或组件层；

其中，架构内核通过加载插件并创建设备对象形成了三个链表，即设备模板链表、协议实体链表以及设备对象链表，后两个链表之间有通讯上的从属关系。如图3中箭头表示这种从属关系。

注：设备模板与设备模板插件一一对应，是用来实时创建设备对象实体的。

内核异步消息处理服务专门用来处理各个协议网络传来的事件。这些事件可能有：传感器报警，设备异常(如电池电量不足)，新设备接入等。

异步消息格式如下：

32bit设备唯一序号，16bit消息类型，16bit消息长度，可变长与消息长度对应的消息实体。

为了方便APP层能够对消息进行统一分析与派发并处理，上述的异步消息格式有必要做这么一个统一定义(否则APP层需必须为每种自定义的消息提供相应的回调函数，如此定义可以简化APP层的消息处理)。注册的异步事件回调函数将会处理每一个消息，根据设备唯一序号可以找到对应的设备，根据消息类型调用不同的处理，并把消息实体当作处理函数的参数。

为了使APP(Application，应用程序，目前一般是指智能终端上的应用，比如苹果，安卓终端上的应用，但是本文泛指上层应用)能正常访问设备，还需要内核提供如下接口(这些不在本发明中定义)：

A.让APP启动内核工作和停止内核工作的接口

B.让APP能够获取所有设备对象句柄的接口

C.让APP能注册异步事件回调函数的接口，供异步事件处理服务调用

D.让APP对设备对象进行操作的方法由设备对象自己自由定义

本设计中不对设备对象的实现做具体定义，但是为了实现设备与协议的隔离，对设备进行抽象后，实际的实现方式可以如图4所示，包括以下内容。

1.架构内核通过加载插件获得协议实体链表；

2.架构内核通过加载插件获得设备模板链表；

3.架构内核通过与设备描述符集匹配的设备模板创建设备对象来获得设备对象链表；

4.通过设备对象的方法来配置协议，比如setProtocol()；

5.提供设备对象句柄给APP；

6.APP通过设备对象句柄调用对象中的方法；

7.设备对象的方法是对设备某个功能的抽象，方法底层调用协议中的sendto，recvfrom来实现与实际设备之间的通信。

如图3中，协议P的sendto与recvfrom被配置给设备对象O，设备对象O中的方法setFunc()和getFunc()在底层调用这两个协议功能函数来收发数据，与设备进行实际交互，Set类方法只需调用sendto就可以，而get类方法则既需要调用sendto还需要调用recvfrom。

为了让协议和设备对象插件化，必须统一插件的接口，插件必须是高度概括好的功能性模块，所有的接口必须是风格一致，名字一致，实现功能也要基本一致。插件接口分为两类：

1.入口函数，负责插件的初始化工作。

2.功能函数，提供外部调用插件定义功能的方法。

总而言之，通过调用插件的入口函数，就可以创建插件实体，并利用插件里的接口函数进行操作，由于加载插件的核心内容相同，请参阅图5，为加载各类插件的框架流程图。

在一个具体实施例中，协议插件的入口函数为“RMS_API rms_protocl_library_Setup(**protocol)”，通过调用插件中的这个入口函数可以得到一个protocol实体，并对实体进行资源初始化，具体包括以下两个方面：

(a)给协议实体赋值下面四个功能函数；

(b)初始化协议实体的旗语，队列等多线程同步成员，用于与设计的内核进行通信。

协议插件的功能函数包括以下结构体：

“RMS_ERRORTYPE (*init) (remote_endpoints_set_descriptor**ppepsetdesc)；

RMS_ERRORTYPE (*sendto) (RMS_BYTE data,RMS_U32length)；

RMS_ERRORTYPE (*recvfrom) (RMS_BYTE data,RMS_U32length)；

RMS_ERRORTYPE (*deinit) (RMS_PTR pPriv)；”

Init功能函数负责初始化协议工作，但是不同于入口函数，功能函数会对协议网络进行探索(discover)工作，并会给调用者一个设备描述符集，通过调用设备描述符集，就可以创建现有协议网络中所有网络设备的对象(内容自定义)，sendto与recvfrom是对应协议的最基本的收发接口，通过这个接口可以方便地与网络设备对象进行双向互动，参数分别为一段要发送或者接收数据的内存指针和要发送或接收数据的长度，长度单位与内存的指针类型对应，deinit用于释放之前创建或者申请的所有资源，包括内存，旗语和队列等，参数为protocol实体指针。

其中，设备描述符集的结构体如下表所示：

在实际应用中，为了规范系统软件安装结构，所有的协议插件都将被放入一个安装目录下的固定协议插件目录“protocol”并且插件都以“.so”或者“.dll”的后缀方式命名，加载协议插件的步骤如下：

1)搜索protocol目录下插件文件，如果有，跳转到2)，否则到6)；

2)加载协议插件的文件并搜索符号“rms_protocl_library_Setup”；

3)如果存在这个符号进入步骤4)，否则进入步骤5)；

4)引出该协议插件的入口函数进行调用，并添加生成的protocol实体到协议实体链表；

5)回到步骤1)；

6)退出加载流程。

根据上述步骤列出的伪代码如下：

经过遍历所有插件文件，就可以获得一个协议实体链表供之后的网络探索(遍历)使用。

此外，在一个具体实施例中，设备模板插件的入口函数为：

“RMS_API rms_component_library_Setup(**component_template)”

通过调用该设备模板插件入口函数可以得到一个component_template插件实体，并对实体进行资源初始化，具体包括以下两方面：

(a)赋值功能函数

(b)赋值component_template内的name成员，通过name成员可以与设备描述符集中的设备名进行匹配，从而确认设备从属于哪个component_template。

需注意，此component_template实体并非设备对象实体本身，准确的说是一种设备对象模板，根据不同的设备类型将会有不同种类的设备对象模板，一种模板通过调用功能函数可以创建理论上不限数目的设备对象。

设备模板插件的功能函数为：

“RMS_ERRORTYPE(*ComponentConstructor)(RMS_HANDLETYPE*,RMS_STRING)”

设备模板插件的功能函数只有一个，从定义上来讲就是根据设备对象的名字来创建设备对象实体。ComponentConstructor只负责创建设备对象(真正的设备对象)，而不负责销毁，因为销毁的工作留给了设备对象自身，不需要插件实体来重复劳动。

功能函数第一个参数将会返回设备对象的句柄(Handle)，所有对设备本身的操作都将利用这个句柄来完成。第二个参数是传入的是位于设备描述符集中的设备名，遍历设备描述符集就可以获得设备对象链表。设备对象内部具体实现可以自行定义，但是必须定义方法能够把设备所属的协议以及sendto函数与recvfrom函数进行配置。这样抽象的设备对象就能与组网中实际的硬件设备进行通信。应用层对待设备对象操作如同实际硬件设备进行操作。

在实际应用中，为了规范系统软件安装结构，所有的设备对象模板插件都将被放入一个安装目录下的固定设备模板插件目录“component”并且插件都以“.so”或者“.dll”后缀方式命名，与协议插件加载基本相同，加载设备模板插件的步骤如下：

1)搜索component目录下插件文件，如果有，跳转到2)，否则到6)；

2)加载插件文件并搜索符号“rms_component_library_Setup”；

3)如果存在这个符号进入步骤4)，否则进入步骤5)；

4)引出该入口函数进行调用，并添加生成的component_template设备模板到设备模板链表

5)回到步骤1)；

6)退出加载流程。

根据上述步骤列出的伪代码如下：

经过遍历所有插件文件，就可以获得一个设备模板链表，网络探索后的结果就可以供这些模板使用(网络设备描述符中含有各个设备的名称，通过名称即可创建设备对象，如功能函数所实现)。

如图7中的网络结构示意图包含了如下元素：

A)电视机与智能机顶盒，可以是电脑，或者手机(前提是能连接设备HUB)

B)三种协议对于的设备HUB，对应Wi-Fi，ZigBee，Z-Wave网络

C)视频监控设备，属于Wi-Fi网络

D)灯光控制器，属于ZigBee网络

E)烟雾监测器，属于ZigBee网络

F)燃气探测器，属于Z-Wave网络

G)温度监测器，属于Z-Wave网络

H)布放撤防控制器，属于Z-Wave网络

智能机顶盒上的APP启动后，先调用初始化接口，来加载三种协议的插件以及预定义好的设备模板插件，并探索三个网络中所有设备的简要描述(profile)信息组成设备描述符集，最后根据这些信息创建所有图中设备的对象实体。然后在APP就可以看到所有这些设备图标，并看到内部信息。用户就可以在屏幕上对设备进行相应的操作(set/get)，比如配置电源管理信息，同步时间，或者打开视频监控的画面。同时接收传感器过来的数据，比如温度监测器，就能看到温度曲线。动态接入的设备会在APP上弹出信息栏，由用户决定是不是添加进来。只要退出接口不被调用就可以一直访问这些网络中的设备。

再结合图6所示的流程图进一步讲解过程：

在步骤601，等待初始化状态

在步骤602，没有收到初始化接口调用就继续等待，否则进入正常工作状态：步骤603。

在步骤603，加载协议插件比如ZigBee，Z-Wave和Wi-Fi的协议插件。

在步骤604，加载设备模板插件，比如摄像头类型设备模板，电灯控制型设备模板。

在步骤605-607，遍历协议实体，并调用协议实体中的功能函数init来获取设备描述符集。然后遍历描述符集中的设备信息调用匹配的设备模板中的功能函数ComponentConstructor(创建设备对象功能函数)来创建设备对象。并为设备对象配置协议信息(protocol)和简要描述信息(profile)。遍历完成后进入步骤608

在步骤608，启动异步事件服务，用来处理网络中出现的异步事件，并调用注册的APP回调函数。

在步骤609，进入正常工作状态，等待APP调用接口(接口包括：获取所有设备对象句柄的接口，设备对象本身提供的成员函数，注册的回调函数，退出接口等)。

在步骤610，退出。

采用了本发明的基于插件形式在上位机中实现跨协议组网的方法，具有以下社会效益：

1、可以兼容多种技术

本发明可以把不同公司的组网技术糅合在一起，生产厂商提供符合本设计协议插件标准的协议就能扩容进来，减少重复设计，节省人力与物力成本。

2、可以兼容不同公司产品

只要符合设备插件接口标准的设备就可以无缝接入系统，所以只需要专注于设备微控制器(MCU)程序的实现即可，无需考虑上位机的实现，这样工作量将会比全系统设计减少90％以上，对于有些公司想尽快推出产品非常有利，工期的缩短也许可以带来巨大的经济效益。

3、降低开发成本

因为插件接口的标准定义，是以应用软件在操作网络资源的时候非常规范，不用针对每个网络做相应的初始化，也不用针对每个设备做相应的初始化。应用软件实现的目的和流程得到统一。

4、移植性强

本发明的插件接口具有强大的可移植性，提高软件开发效率，对企业的智能家居设计及其他物联网设计提供极大的便利，应用范围也十分广泛。

在此说明书中，本发明已参照其特定的实施例作了描述。但是，很显然仍可以作出各种修改和变换而不背离本发明的精神和范围。因此，说明书和附图应被认为是说明性的而非限制性的。

Claims (7)

1.一种基于插件形式在上位机中实现跨协议组网的方法，其特征在于，所述的方法包括以下步骤：

(1)上位机加载协议插件，并将新生成的协议实体添加至协议实体链表中；

(2)所述的上位机加载设备模板插件，并创建所述的设备模板插件对应的设备模板；

(3)所述的上位机查询协议实体链表，并调用所述的协议实体链表中的初始化功能函数；

(4)所述的上位机通过所述的初始化功能函数得到设备描述符集；

(5)所述的上位机查询所述的设备描述符集中的设备信息，并找到所述的设备信息所匹配的设备模板；

(6)所述的上位机调用所匹配的设备模板中的创建设备对象功能函数来创建设备对象，并添加至设备对象链表中；

(7)所述的上位机更新所述的设备对象的配置协议信息和简要描述信息；

所述的上位机通过遍历插件目录获取插件文件，从而动态进行协议插件和设备模板插件的加载；

所述的上位机通过所述的初始化功能函数进行网络探索工作，从而获取网络当前在线设备描述符集；

所述的上位机通过设备对象的句柄直接调用设备对象中的方法来远程操控实际设备。

2.根据权利要求1所述的基于插件形式在上位机中实现跨协议组网的方法，其特征在于，所述的上位机加载协议插件，包括以下步骤：

(1.1)所述的上位机判断协议插件目录下是否存在所述的协议插件的文件；

(1.2)如果判断结果为所述的插件协议插件目录下存在所述的协议插件的文件，则继续步骤(1.3)，否则继续步骤(1.4)；

(1.3)所述的上位机加载所述的协议插件的文件；

(1.4)所述的上位机停止加载协议插件。

3.根据权利要求2所述的基于插件形式在上位机中实现跨协议组网的方法，其特征在于，所述的将新生成的协议实体添加至所述的协议实体链表，包括以下步骤：

(1.5)所述的上位机判断是否存在协议插件入口函数，如果是，则继续步骤(1.6)，否则返回上述步骤(1.1)；

(1.6)所述的上位机调用所述的协议插件入口函数，并将新生成的协议实体添加至所述的协议实体链表中。

4.根据权利要求1所述的基于插件形式在上位机中实现跨协议组网的方法，其特征在于，所述的上位机加载设备模板插件，包括以下步骤：

(2.1)所述的上位机判断设备模板插件目录下是否存在所述的设备模板插件的文件；

(2.2)如果判断结果为所述的设备模板插件目录下存在所述的设备模板插件的文件，则继续步骤(2.3)，否则继续步骤(2.4)；

(2.3)所述的上位机加载所述的设备模板插件的文件；

(2.4)所述的上位机停止加载设备模板插件。

5.根据权利要求4所述的基于插件形式在上位机中实现跨协议组网的方法，其特征在于，所述的创建所述的设备模板插件对应的设备模板，包括以下步骤：

(2.5)所述的上位机判断是否存在设备模板插件入口函数，如果是，则继续步骤(2.6)，否则返回上述步骤(2.1)；

(2.6)所述的上位机调用所述的设备模板插件入口函数，并将新生成的设备模板添加至设备模板链表中。

6.根据权利要求1至5任一项所述的基于插件形式在上位机中实现跨协议组网的方法，其特征在于，所述的步骤(1)之前，包括以下步骤：

(0)所述的上位机判断是否收到远程设备的初始化请求，如果是，则继续步骤(1)，否则继续步骤(0)。

7.根据权利要求1至5任一项所述的基于插件形式在上位机中实现跨协议组网的方法，其特征在于，所述的上位机查询协议实体链表，包括以下步骤：

(3.1)所述的上位机判断是否查询找到所述的协议实体链表，如果是，则继续步骤(3)，否则继续步骤(3.2)；

(3.2)所述的上位机启动异步事件服务；

(3.3)所述的上位机进入正常工作状态，并等待其它调用指令。