面向物联网传感器资源融合服务动态生成方法及中间件

技术领域

本发明涉及物联网技术领域，提供了一种面向物联网传感器资源融合服务动态生成方法及中间件。

背景技术

近年来，随着物联网技术和传感器技术的快速发展，人们工作和生活环境中的传感器越来越多，这些海量传感器构成了能够提供大量原始数据的传感器。然而，针对需要抽象化和集成化数据的上层应用而言，传感器提供的这些低粒度的原始数据很难被直接利用。

物联网技术的发展遵循基础硬件环境建设先行的现代信息技术产业化模式，即未来人们将面临的一个技术难题在于首先具备获取大量集群传感器数据的能力，在此基础上构建相应的智能家居或智慧城市的集成化、智能化的行业应用。依据这种模式，原有先有应用然后再依据应用定制信息数据采集需求的软件设计方法不再适用。而需要依据行业应用的需求来规划应用传感器感知数据输入接口，该应用接口的定制由于综合了传感器数据并面向行业应用的决策与认知的数据维度，因而这一抽象化和集成化的数据粒度通常称为行业应用数据模型，那么如何依据智能家居或智慧城市数据需求，设计自动化数据处理中间件筛选传感器中已有的低粒度的原始设备数据并自动集成为应用需求数据，以支撑未来越来越多新颖且无法预见的行业应用的数据分析、决策支持和可视化技术，将是智能信息处理技术发展的一个关键瓶颈与技术挑战。

海量的传感器能够提供大量的原始感知数据，但是这些大量的低粒度原始数据无法直接被应用所使用。例如一个小区中，每家每户以及小区中的公共区域都有已安装了大量的各类传感器的情况下，该小区的物业需要一个楼宇火灾管理应用来实时监测整个小区是否有火灾发生并进行预防。小区中的温度传感器只能感知某一固定位置的温度，这些温度传感器的数据没有进行关联，楼宇火灾管理应用无法直接获取到某一房间或者某一楼层的火灾的态势，即温度传感器的原始数据无法直接被楼宇火灾管理应用使用。针对应用无法有效利用传感器原始数据这一问题的分析如下：

(1)应用数据需求复杂多变，需要根据不同的数据需求动态生成对应的数据接口，以便应用获取需求数据。一个应用往往需要多种需求数据，而每种需求的数据接口往往是不一致的。例如在火灾管理应用中需要室内温度和室内烟雾浓度这两个数据，而室内温度采用华氏度或者摄氏度来表述，室内烟雾浓度一般采用体积浓度和质量-体积浓度来表述，它们的数据接口并不一致。针对不同的需求数据需要动态生成其对应数据访问接口。

(2)应用所需数据需要对传感器原始感知数据进行一系列的处理和融合才能被应用所使用。例如在一个房间中共有三个温度传感器，它们所检测到的温度数值并不相同，而一个应用需要该房间的室内温度这一数据，因此需要将这三个温度传感器的数据进行处理和融合才能形成应用所需的室温数据，才能被应用使用，因此传感器原始的感知数据需要进行一系列的处理。

(3)智能家居场景下的海量传感器中存在种类繁多的传感器，某一具体的需求数据需要从它们中筛选出合适的传感器来提供原始感知数据支撑。应用中往往需要某一位置的数据，例如需要某一房间的室温数据，那么就需要首先根据一定的规则筛选出该房间内的所有温度传感器，然后根据所需的数据类型筛选出能为该需求数据提供数据支撑的传感器。

发明内容

本发明的目的在于解决现有传感器提供的这些低粒度的原始数据很难被直接利用的问题，首先需要筛选合适的传感器感知设备，然后对这些传感器感知设备的原始数据进行转换和融合处理才能形成能够被应用所直接使用的需求数据。

为了实现上述目的本发明采用以下技术手段：

一种物联网传感器资源管理与应用服务中间件，包括以下模块：应用服务中间件是将传感器的资源数据转换成应用资源数据，为应用提供可以直接使用的数据。

通用资源管理模块：将各传感器都抽象成资源子树，得到传感器资源树，一棵资源子树表示一个传感器的所有信息，所述所有信息即包括对传感器的描述信息，也包括传感器所采集到的感知数据；

应用数据接口生成模块：依据应用的数据需求，动态创建应用资源树和缓存数据表，并生成应用数据服务接口，供应用在需要时主动获取。

服务动态调度模块：依据应用所需的数据以及传感器资源树能够提供的感知资源匹配到对应的服务调度模板，然后动态加载已有的基础服务并进行实例化，最后将这些实例化后的基础服务进行组合，生成数据融合Agent；

基于资源发现的数据管道创建模块：在生成数据融合Agent之后，进行资源发现并从传感器资源树中筛选出应用资源所需的传感器感知资源，然后建立起这些传感器感知资源到数据融合Agent之间的数据管道。

上述技术方案中，应用数据接口生成模块实现具体如下：

应用数据接口生成模块接收到应用的数据需求后，首先需要对应用的数据需求文件解析，然后能根据解析结果创建对应的应用资源树和缓存数据表，并能将应用资源树上更新后的数据写入到对应的缓存数据表中，以供应用在需要的时候主动获取；

具体的数据需求文件解析：

根据数据需求文件的格式和文件中各个字段的定义，能解析出数据需求文件中的相关信息，包括应用的基本信息、应用资源树结构、所需数据的缓存数据表结构、数据所需的传感器感知资源以及每个数据的生成方法。

具体的创建应用资源树：

根据数据需求文件解析出的应用资源树结构，通过资源调度接口创建与之对应的应用资源树，并创建各个应用资源的订阅，以便能及时接收到最新的应用所需数据；

上述技术方案中，还包括缓存数据库管理模块和缓存数据表更新事件发送模块，具体如下：

缓存数据库管理模块：包含缓存数据表创建、缓存数据表删除和完成应用资源到缓存数据的转换。根据数据需求文件解析结果中的缓存数据表结构创建对应的缓存数据表，若缓存数据表已经存在，需要根据解析结果中覆盖还是追加选项字段对己存在的缓存数据表进行操作，应用服务中间件接收到最新的应用资源数据后，能将应用资源数据转换成缓存数据并写入对应的缓存数据表中。

缓存数据表更新事件发送模块：将最新的应用资源数据写入到缓存数据表后，还需要根据解析结果中的应用数据需求信息找到应用的网络连接，并向应用发送缓存数据表已更新的消息。

上述技术方案中，服务动态调度模块实现具体如下：

服务调度模板匹配：

基于已有的服务调度模板，根据应用数据需求以及传感器资源树能够提供的感知资源匹配合适的服务调度模板，然后根据这些传感器感知资源的相关信息确定服务调度模板上基础服务的参数以及它们之间的依赖关系，即得到模板实例化参数；

服务SO动态加载：

基于模板实例化参数从基础服务SO库中加载对应的服务SO，并按照深度优先遍历确定各个服务的调度顺序，最后按照调用顺序启动各个服务实例；

数据融合Agent生成：

依据服务调度模板匹配结果中的服务之间的依赖关系，将动态加载并初始化后的服务实例进行组合，确定它们之间的先后调用关系，生成数据融合Agent。

上述技术方案中，基础服务SO库中包含有各种类型的基础服务，通过动态调度的方式参考服务调度模块库中的调度模板，根据应用数据需求和资源发现的结果，加载这些基础服务构建服务实例，将原始感知数据融合为应用需求数据；基础服务SO库中包含有各种类型的基础服务具体包括单位转换、数据存储类型转换、数据同步和滤波处理。

上述技术方案中，服务动态调度模块还包括：

服务生命周期管理：

对数据融合Agent中的各个服务的生命周期进行管理，能够根据数据融合Agent的具体状态启动服务实例、停止服务实例以及销毁服务实例并回收服务实例所占用的资源；

服务运行时管理：

在服务运行时，需要对服务进行驱动，即把从传感器资源树上获取的数据发送给数据融合Agent，进行数据融合处理，然后将处理好的数据更新到应用资源树上，同时捕获服务运行时可能出现的错误，并能重新启动或者停止服务实例。

上述技术方案中，基于资源发现的数据管道创建模块实现具体如下：

资源发现模块：根据应用数据需求文件解析结果中应用资源所需的传感器感知资源类型和传感器感知资源名称对传感器资源树上资源进行模糊匹配筛选出能够为应用资源提供数据支撑的传感器感知资源；

数据管道构建模块：在获取到所需的传感器感知资源后，生成它们的订阅或者查询指令，构成资源调度脚本，然后通过资源调度接口发送这些脚本构建起从传感器资源树上传感器感知资源到数据融合Agent的数据管道。

实施方式，如根据这些发现的传感器资源ID生成订阅和查询的资源调度脚本，通过这些资源调度脚本来创建传感器感知资源到数据融合Agent之间的数据管道，这样才能获取到传感器的资源数据。

本发明还提供了一种面向物联网传感器资源融合服务动态生成方法，所述的一种物联网传感器资源管理与应用服务中间件实现传感器感知数据的处理和融合。

因为本发明采用上述技术手段，因此具备以下有益效果：

1、本发明通过在传感器和应用之间增加一层应用服务中间件来实现根据应用的数据需求动态生成应用的数据服务接口，然后根据应用所需的数据基于服务调度模板动态加载对应的基础服务生成数据融合Agent，最后根据应用需求数据所需传感器的规则，筛选出对应的传感器，并建立传感器到数据融合服务的数据管道，实现了传感器中的原始数据通过应用服务中间件的自动处理与融合最后供应用使用。

2、为应对应用的动态数据需求，本申请定义了应用数据需求规范，应用按照此规范提出数据需求，由中间件动态生成需求数据服务接口，并为之提供数据。当有需求数据生成后，应用能够直接从动态生成的数据服务接口获取依据底层感知设备数据融合而成的数据，简化了应用获取数据的流程。同时，为支持对时延敏感的数据需求，在完成一帧数据的融合后，会将该数据融合事件发送给应用以便能被及时读取。

3、为根据应用的数据需求生成应用数据，本申请定义了应用数据生成规则，针对不同需求数据的生成规则，中间件基于服务调度模板从基础服务库中动态调度基础服务生成数据融合Agent，完成从传感器数据到应用需求数据的转换与融合。

4、传感器中有大量的不同种类的感知设备，要依据这些感知设备生成不同的应用需求数据，需要从大量感知设备中筛选出合适的设备。本申请实现了基于传感器感知设备资源层的资源发现，能够基于传感器感知设备的各个属性发现能够提供数据支撑的感知设备。还能监听这些传感器感知设备上下线事件，动态地建立或者删除传感器感知设备资源到数据融合服务之间的数据管道。

附图说明

图1是整体框架简图；

图2是数据需求文件的发送方式示意图；

图3是数据需求文件中的JSON实体类图；

图4是应用资源树和缓存数据表创建过程；

图5是缓存数据生成和事件发送的示意图；

图6是应用缓存数据生成流程图；

图7是服务动态调度模块详细设计图；

图8是服务动态调度模块进行服务模板匹配的示意图；

图9是对多个传感器感知资源数据进行平均处理的服务调度模板示例；

图10是数据融合Agent的生成过程；

图11是传感器感知设备动态变化的示例；

图12是按照流程生成数据融合Agent的示例；

图13是基于资源发现的数据管道创建模块详细设计图；

图14是数据管道构建流程图。

具体实施方式

以下将对本发明的实施例给出详细的说明。尽管本发明将结合一些具体实施方式进行阐述和说明，但需要注意的是本发明并不仅仅只局限于这些实施方式。相反，对本发明进行的修改或者等同替换，均应涵盖在本发明的权利要求范围当中。

另外，为了更好的说明本发明，在下文的具体实施方式中给出了众多的具体细节。本领域技术人员将理解，没有这些具体细节，本发明同样可以实施。

本发明提供了一种物联网传感器资源管理与应用服务中间件，包括以下模块：应用服务中间件是将传感器的资源数据转换成应用资源数据，为应用提供可以直接使用的数据。

通用资源管理模块：将各传感器都抽象成资源子树，得到传感器资源树，一棵资源子树表示一个传感器的所有信息，所述所有信息即包括对传感器的描述信息，也包括传感器所采集到的感知数据；

应用数据接口生成模块：依据应用的数据需求，动态创建应用资源树和缓存数据表，并生成应用数据服务接口，供应用在需要时主动获取。

服务动态调度模块：依据应用所需的数据以及传感器资源树能够提供的感知资源匹配到对应的服务调度模板，然后动态加载已有的基础服务并进行实例化，最后将这些实例化后的基础服务进行组合，生成数据融合Agent；

基于资源发现的数据管道创建模块：在生成数据融合Agent之后，进行资源发现并从传感器资源树中筛选出应用资源所需的传感器感知资源，然后建立起这些传感器感知资源到数据融合Agent之间的数据管道。

上述技术方案中，应用数据接口生成模块实现具体如下：

应用数据接口生成模块接收到应用的数据需求后，首先需要对应用的数据需求文件解析，然后能根据解析结果创建对应的应用资源树和缓存数据表，在应用资源树被更新后，该模块能够将应用资源树上的资源数据转换为缓存数据写入到缓存数据库中并向应用发送缓存数据已更新的事件消息，以便应用能够根据自身需求从缓存数据库中读取最新的缓存数据。

具体的数据需求文件解析：

根据数据需求文件的格式和文件中各个字段的定义，能解析出数据需求文件中的相关信息，包括应用的基本信息、应用资源树结构、所需数据的缓存数据表结构、数据所需的传感器感知资源以及每个数据的生成方法。

为方便本领域技术人员更好的理解本发明构思，数据需求文件解析做进一步的说明：

数据需求文件是应用开发者根据应用所需的数据进行分析得到。应用开发者编写好数据需求文件后应用在启动的时候通过网络发送到应用服务中间件中。如图2所示是数据需求文件的发送方式示意图。在应用服务中间件中建立一个TCP服务端监听某一指定端口，以便接收到来自应用的数据需求文件。该数据需求文件是通过网络流的方式进行发送，应用服务中间件接收到该网络流数据后，首先将其转换为字符串文件。应用服务中间件把该文件传入到数据接口生成模块的数据需求文件解析模块进行解析。数据接口生成模块接收到的文件是JSON格式的文件，因此需要首先对该JSON格式的文件进行解析，按照应用数据需求文件中的各个字段建立实体类，然后定义各个字段与类成员变量的转换关系，得到数据需求文件的内存对象。

图3是数据需求文件中的JSON实体类图。在该图中，DataType枚举类定义了常见的基础数据类型用于表示缓存数据表中每一列的数据类型，这些数据类型几乎在所有的数据库中都能找到对应的存储类型，因此应用可以通过数据需求文件来配置这些类型生成缓存数据表。其他的实体类是与数据需求文件中的各个字段相对应，定义了这些对应的实体类后，对于JSON文件的解析，可以采用JSON文件解析库就能完成JSON文件到内存对象的转换。

由于数据需求文件中填写的内容可能是简写，例如资源路径写的相对路径而非绝对路径，因此需要将这些可能存在简写的部分替换成能够唯一标识某一资源或者某一服务的字符串。然后调用对应的方法创建应用资源树和缓存数据表，最后让服务动态调度模块根据数据需求加载对应的基础服务。

具体的创建应用资源树：

根据数据需求文件解析出的应用资源树结构，通过资源调度接口创建与之对应的应用资源树，并创建各个应用资源的订阅，以便能及时接收到最新的应用所需数据；

上述技术方案中，还包括缓存数据库管理模块和缓存数据表更新事件发送模块，具体如下：

缓存数据库管理模块：包含缓存数据表创建、缓存数据表删除和完成应用资源到缓存数据的转换。根据数据需求文件解析结果中的缓存数据表结构创建对应的缓存数据表，若缓存数据表已经存在，需要根据解析结果中覆盖还是追加选项字段对已存在的缓存数据表进行操作，应用服务中间件接收到最新的应用资源数据后，能将应用资源数据转换成缓存数据并写入对应的缓存数据表中。

缓存数据表更新事件发送模块：将最新的应用资源数据写入到缓存数据表后，还需要根据解析结果中的应用数据需求信息找到应用的网络连接，并向应用发送缓存数据表已更新的消息。

在完成应用数据需求文件的解析后，便得到需要创建的应用资源树结构和缓存数据表的定义。

参见图4是应用资源树和缓存数据表创建过程。

将JSON文件转换成对应的实体类后，就能得到应用需要的数据以及各个需求数据的存储类型单位频率等信息。然后就可以依据这些信息建立应用资源树。对于每个需求数据，都要建立与之对应的资源子树来存储该数据的相关信息。首先需要遍历所有的需求数据，然后数据的所有属性信息按照通用资源管理平台的Req请求的标准进行封装，并通过该平台提供的资源创建接口发起创建请求，依次进行。需要将所有的需求数据对应的资源子树都创建完成，并保证每个创建请求的结果都成功，若不成功就应当及时向应用反馈信息。如此便完成了应用资源树的创建。

创建完应用资源树后，还需要创建与之对应的缓存数据表。这些数据表是创建在通用的数据库中，以便应用读取这些数据。所以需要根据这些应用需求数据的属性信息来生成创建表的SQL命令。SQL命令在创建表时的关键信息是表的每一个字段名称和字段的存储类型，这些信息在应用需求数据的属性信息中都存在，因此可以依据缓存数据库的类型生成SQL命令。同时对于缓存数据表还需要创建数据表的行号和数据生成时间这两个数据列。缓存数据表的这两个字段能够方便向应用发送数据更新事件，并告知应用是哪一行数据在什么时候被更新。SQL命令生成后就采用缓存数据库的接口发送并执行。

应用资源树和缓存数据表都被创建后，还需要建立它们之间的映射关系，因为应用资源子树和缓存数据表都是由数据需求处理模块创建。因此，该模块内部只需要一个哈希表便能存储资源子树和缓存数据表的映射关系，当创建好资源子树和缓存数据表后，就将该资源子树的资源ID和缓存数据表名称放入哈希表中进行缓存。然后还需要通过通用资源管理系统提供的订阅接口，订阅该资源子树的数据变化，这样便建立了资源子树与缓存数据表之间的映射关系。在创建应用资源树时，首先根据资源树的挂载点和数据需求文件的内容生成创建应用资源树的batchReq，然后调用对应的接口发送这些batchReq完成应用资源树的创建。最后要保证这些应用资源树的节点都能创建成功，若创建失败，则后续步骤将无法继续，需要返回具体的错误信息。

具体的应用数据缓存生成由应用数据接口生成模块的资源树到缓存数据表转换模块和缓存数据表数据更新事件发送模块完成。应用资源树被创建后，会建立起它到缓存数据表的对应关系，并通过通用资源管理系统的订阅接口对各个应用资源树都进行了订阅。

图5是缓存数据生成和事件发送的示意图。当应用资源树上的数据被更新后会将资源数据通知到转换模块中。转换模块首先会将资源数据转换成缓存数据，即将资源数据的数据格式和数据存储类型转换成对应SQL插入语句。在此时需要从之前存储的映射关系的哈希表获取到该资源ID所对应的缓存数据表名称。最后生成一个完整的SQL插入命令，将该缓存数据插入到缓存数据表中。当缓存数据表插入成功后，就需要向应用发送数据更新事件。数据更新事件发送模块首先会将本次数据更新的行号，更新时间，更新表的名称，更新时间类型封装成一个消息，然后通过之前存储的该应用的网络连接发送该消息，完成数据更新时间的发送。

图6是应用缓存数据生成流程图。该流程图的开始是接收到应用资源树的资源数据更新通知。但是该数据更新通知可能是资源树结构变化的通知，所以有可能其中并没有包含应用需求数据。根据通知事件类型可以知道是否包含应用需求数据，若没有包含则该流程直接退出，不再进行其他处理。若存在应用需求数据，则需要对所有的应用需求数据进行遍历，将该通知中包含的所有应用需求数据都更新到缓存数据库中。

在遍历时，将正在遍历的应用需求数据按照SQL更新语句的格式进行封装，得到SQL更新语句。然后调用缓存数据的SQL语句执行接口执行更新操作。然后更新成功后就将本次更新的数据表名、行号、更新事件和更新事件类型封装成数据更新消息发送给应用。若该消息发送失败，则说明应用已经断开网络连接或者网络连接被重置，表示应用不需要缓存数据表更新事件。那么下一次就不需要给该应用发送缓存数据更新事件。在遍历完所有的数据后，需要将本次更新的数据数量累加上行号，下一次更新时便知道已经更新的行数。在向应用发送数据更新消息时，首先需要将要发送的缓存数据表名、更新事件和更新的行号封装成message对象，然后通过JSON工具将该消息序列化成消息字符串，最后从数据需求文件缓存中找到应用的网络URL，然后调用网络发送模块的send方法发送该消息。

上述技术方案中，服务动态调度模块实现具体如下：

参见图7是服务动态调度模块的详细设计图。服务动态调度模块的输入数据来自于数据管道创建模块创建的从传感器感知设备资源到应用服务中间件的数据管道。数据接口生成模块根据接收到的所需应用数据需求向服务动态调度模块发送模板实例化参数。服务动态调度模块根据服务调度模板库中的服务模板进行匹配，确保已有的基础服务能够完成将传感器感知设备资源转换成应用需求数据，以及它们之间的依赖关系；然后服务动态调度模块从基础服务SO库中加载对应的服务生成数据融合Agent；接着根据基础服务所依赖的传感器感知资源获取到感知资源到服务实例之间的数据管道；最后服务动态调度模块调用服务实例的接口启动对应的数据融合Agent。

服务调度模板匹配：

基于已有的服务调度模板，根据应用的数据需求以及传感器存在的传感器列表选择合适的服务调度模板，然后根据这些传感器感知资源的相关信息确定服务调度模板上基础服务的参数以及它们之间的依赖关系，即得到模板实例化参数；

服务SO动态加载：

基于模板实例化参数从基础服务SO库中加载对应的服务SO，并按照深度优先遍历确定各个服务的调度顺序，最后按照调用顺序启动各个服务实例；

数据融合Agent生成：

依据服务调度模板匹配结果中的服务之间的依赖关系，将动态加载并初始化后的服务实例进行组合，确定它们之间的先后调用关系，生成数据融合Agent。

上述技术方案中，数据融合Agent的动态生成是由服务动态调度模块实现的，在动态生成的过程中，首先根据要生成的数据选择服务调度模板，然后确定服务调度模板中的各个参数，最后依据这些参数对服务调度模板进行实例化，得到与服务调度模板对应的数据融合Agent。服务动态调度模块的服务模板匹配功能，是根据服务调度模板中服务之间依赖关系，以及应用数据接口生成模块提供的需求，资源发现模块提供的感知资源等一系列参数进行匹配，以生成数据融合Agent。

图8是服务动态调度模块进行服务模板匹配的示意图。在服务调度模板中，矩形框表示资源，椭圆形框表示服务实例。他们之间构成一个有向无环的依赖关系图，该图的叶子节点必须是感知资源，这样才能保住所有的服务都能获得足够的输入数据。同时，该图中不能存在环，若存在环，那么将会出现循环依赖，相当于一个递归函数没有出口，整个函数将陷入死循环。若有多个资源，则会构成多棵这样的依赖关系树。

在进行服务模板匹配时，首先要确定感知资源的数量。因为在服务调度模板之中感知资源的个数会导致依赖它的其他服务的变化，因此需要先确定感知资源的数量。感知资源的数量确定后，该资源后面的频率同步、存储类型转换和单位转换服务的数量才能确定，才能依次确定这些服务的输入输出参数。然后再比较该感知资源的数据发生频率是否与所有感知资源的最低频率相同，若不相同那么该资源需要进行频率同步，并计算出频率同步服务所需的参数。资源数据存储类型和资源数据的单位匹配过程也是如此，先确定感知资源数据的存储类型和单位是否与应用资源相同，若不相同就需要匹配到对应的能够进行转换的服务，并根据感知资源和资源确定服务的启动参数。如图9所示，是对多个传感器感知资源数据进行平均处理的服务调度模板示例。服务调度模板示例中展示了一个服务调度模板中所需填写的所有字段。模板中包含了模板的一些基本信息，如模板ID、模板名称和模板描述。还有所需的感知资源和输出的应用资源，以及服务模板中所涉及的所有服务和服务之间的依赖关系。

表1是所有字段的详细描述。模板ID、模板名称和模板描述是模板的基本信息，其中为防止多个模板重名的情况，采用模板ID来唯一标识一个模板。模板名称和模板描述是方便模板编写人员对模板进行区分，它们都是String类型。其中模板描述可以不用填写。

表1服务调度模块字段说明

传感器感知资源和应用资源是服务调度模板的输入和输出，因为可能有多个输入和输出，因此他们都是Array类型。在Array中包含了多个Object来表示多个不同的资源。serviceNodes和serviceRelations定义了服务调度模板中所涉及的所有服务和服务之间的依赖关系，因为多个服务互相依赖会构成一个依赖树，serviceNodes表示这个服务依赖树的节点，serviceRelations表示这个服务依赖树的边。这个服务依赖树中一般会包含多个serviceNode和serviceRelation，因此它们两者都是Array类型。同时，它们也必须填写否则无法构成一个服务依赖树。ServiceNodes和serviceRelation中包含了多个serviceNode和serviceRelation来表示每个节点和边的信息。

表2是perceptionResource和situationResource字段所包含Object的详细信息。perceptionResource和situationResource相当于一个函数输入和输出的描述。因此name字段相当于函数的形参名称，type字段相当于函数形参的类型，value字段相当于函数的实参的值。表3是serviceNodes字段中包含的ServiceNode的详细信息。ServiceNode表示一个服务节点，name字段是该服务节点的名称，在模板中可以通过该name引用该服务节点。Path字段表示该服务节点所在文件系统的位置，实例化该模板时，可以根据该字段加载对应的服务SO文件。ArgsList字段是Array类型的，表示该服务节点在实例化时的输入参数，这些输入参数在进行模板匹配的时候确定，然后传入到服务实例中初始化该服务。表4是serviceRelations字段中serviceRelation的详细描述。前面已经提到seviceRelation相当于服务依赖树的一条边。上表中的name可以类比为边的起点，dependency是可以类比为边的终点，dependencyType可以类比为边的终点的类型，而repeatable表示该依赖边是否能重复。在进行模板匹配时可以根据此字段来匹配到多个传感器感知资源。

表2感知资源和应用资源字段说明

表3 ServiceNode字段说明

表4 ServiceRelation字段说明

以上是一个服务调度模板所有字段的详细描述。该服务调度模板定义了多个服务实例之间的依赖关系、所依赖的感知资源以及能够输出的应用资源。上面的服务调度模板示例是输入多个相同类型的感知资源，对这多个资源数据进行平均然后输出一个应用资源的服务调度模板。根据上面对服务调度模板的定义，还可以编写拥有其他功能的服务调度模板。

上述技术方案中，基础服务SO库中包含有各种类型的基础服务，通过动态调度的方式参考服务调度模块库中的调度模板，根据数据需求和资源发现的结果，加载这些基础服务构建服务实例，将原始感知数据融合为应用需求数据。基础服务SO库中包含有各种类型的基础服务具体包括单位转换、数据存储类型转换、数据同步和滤波处理。

上述技术方案中，数据融合Agent的生成过程如图10所示。数据融合Agent的生成流程描述如下：

步骤1、根据应用数据需求生成规则中的描述信息从服务调度模板库中选择对应的服务调度模板；

步骤2、根据传感器感知资源的数量确定服务匹配模板中的输入资源数量；

步骤3、根据应用资源和感知资源的频率、数据存储类型和数据的单位等信息确定服务调度模板中各个基础服务和对应的启动参数；

步骤4、根据模板中的基础服务，从基础服务SO库中找到对应的动态链接库文件并加载；

步骤5、将加载好的服务实例的输入输出句柄按照模板中的依赖关系进行深度优先遍历确定调用各个服务的先后顺序；

步骤7、依次调用各个基础服务的启动接口，启动服务实例，完成数据融合Agent生成；

服务动态调度模块的输入是资源发现的结果。服务动态调度模块首先需要根据应用的数据需求和传感器能够提供的传感器数据匹配到对应的服务，并找到这些服务之间的依赖关系。若无法找到所依赖的其他服务或者传感器感知资源则匹配失败，提示应用应该安装新的传感器或者编写需要的服务SO才能继续运行。若所有所依赖的服务以及服务所依赖的感知资源都在资源发现结果中存在，那么即表示匹配成功。

服务调度模板既包含各个服务之间的依赖关系，也能以此确定各个服务的启动参数。服务动态调度模块根据服务依赖关系图在服务库中找到对应的服务SO，并将其动态链接到当前进程中。对于动态链接到当前进程的服务，便可以得到的函数调用句柄。依赖服务匹配结果中的服务运行参数调用该函数句柄就能启动该服务，完成服务的加载。在所有的服务都加载完成后，就根据服务依赖关系图中的依赖关系来构建服务与资源之间的订阅通知或者数据查询关系，构建他们之间的数据流管道。即先构建该服务调度模板中的每个节点，然后再构建服务调度模板中的所有边。

通过以上流程能够建立好传感器资源和应用资源的数据流，数据流在经过服务时会被处理成应用需要的资源数据。服务与服务之间的数据流是被服务动态调度模块所管理的，他们之间的数据流是根据它们之间的函数调用关系来控制，在各个服务加载后就已经确定。而资源与服务之间的数据流需要采用资源操作相关接口来实现。

例如从传感器感知资源到应用数据之间的数据流是通过资源的订阅/通知和请求/响应实现。即当某一个被订阅的资源被更新后，就会收到该资源的更新通知，该资源的更新数据可以从该通知中获得。而其他的资源就需要采用请求响应的模式从感知资源层中查询获得。针对数据融合Agent与应用资源之间的数据流则是采用资源更新的方式，将数据融合Agent的输出数据封装成资源数据，通过应用资源树的操作接口发送更新请求。

数据融合Agent的输入来自传感器资源树上的传感器设备资源数据，输出是应用资源树上的应用数据需求资源。应用数据资源的数量是根据应用的需求而定的，然而一个具体的要素由多个传感器设备资源生成。同时，这些传感器设备可能由于某些原因进行动态变化，导致传感器设备所对应的传感器感知资源是不确定的。因此，数据融合Agent应当处理感知资源动态变化的情况，即需要及时发现传感器感知资源的变化并创建或者删除对应的数据管道。

图11是传感器设备动态变化的示例。在图11中有两类传感器，它们的感知数据分别被数据融合Agent-A和数据融合Agent-B所处理，然后更新到应用资源树上对应的应用数据需求资源上。其中传感器有可能动态变化，例如某个房间内新安装了一个A传感器，那么A传感器所对应的资源子树就会增加。此时数据融合Agent-A就会检测到有新的温度传感器接入到感知资源层，并且该感知资源能够为应用数据雪球提供数据支撑。就会创建该感知资源到数据融合Agent-A的数据管道，在进行数据处理时就会获取该感知资源数据并进行相应的处理。某个B传感器可能因为出现故障导致掉线，而从传感器资源树上消失。此时数据融合Agent-B就会检测到有一个B传感器下线，而删除该传感器所对应的感知资源到数据融合Agent-B的数据管道，在下一次数据处理时忽略该感知资源。

图12是按照流程生成数据融合Agent的示例，该示例中假设应用需要室温这一要素，且在此时，对应房间中共有三个温度传感器可以用于生成室温要素。该图展示了数据融合Agent的生成过程，然后数据融合Agent就开始处理数据。假设处理过程中，有温度计2出现故障，被基于资源发现的模块发现温度计2下线，然后通知给服务动态调度模块。当温度计2下线后，服务动态调度模块会删除跟他相关的服务实例，并开始正常运行处理数据。假设此后房间主人又在此房间中安装了一个新的温度计4。安装好的温度计4上线后，会被基于资源发现的数据管道创建模块发现，创建好管道之后通知服务动态调度模块，新的温度计4已上线。此时服务调度模块会根据模板为该温度计加载基础服务，并将这些服务的输出连接到数据融合Agent中。接着数据融合Agent就可以将三个在线的温度计的数据融合成室温。

上述技术方案中，基于资源发现的数据管道创建模块具体如下：

参见图13是应用服务中间件中数据管道创建模块的详细设计图。应用数据接口生成模块处理完数据需求文件后，能够得到所需的应用数据以及传感器感知设备的查找规则。基于资源发现的数据管道创建模块可以根据传感器感知设备的查找规则发现能够为应用资源提供数据支撑的传感器感知设备资源，并建立起传感器感知资源到中间件的数据管道。除此之外，数据管道创建模块还能根据这些规则发现传感器感知设备的上下线，为服务动态调度模块提供支撑，以启动或者停止某些服务。

资源模糊查询是通过资源名称或者资源ID进行正则匹配，筛选出要查询的资源。资源发现是根据应用数据的标签或者传感器设备的ID发现对应的传感器感知资源。当传感器资源树和应用资源树上有新的资源被创建后，资源发现流程就会被触发。因此当有新的传感器感知设备资源或者应用需求数据资源后，资源发现模块会在第一时间发现该传感器感知设备资源或者应用需求数据资源。

基于资源发现的数据管道创建模块对外提供了初始化方法、资源发现方法和通知接收方法。在该模块初始化的时候，会从传感器资源树上发现所有的传感器感知设备，并将这些感知设备的信息缓存。当外部调用资源发现时，就直接从缓存中发现对应的传感器，并将发现结果进行缓存，以便后续多次进行传感器发现时快速返回。

资源模糊查询和资源发现模块找到应用需求数据资源所需的传感器感知资源后，资源调度脚本生成模块根据资源发现的结果生成了资源调度脚本。从传感器资源树中获取资源数据，有订阅和查询两种模式。其中订阅是事件触发机制，即先订阅某一个传感器感知资源的资源更新事件，当该资源被更新后，就会发送该资源更新事件。资源查询只能采用轮询的方式不断的请求才能获取到最新数据。数据融合Agent的输入来自于资源调度脚本中的订阅或者查询语句的结果。因此通过资源调度脚本建立传感器感知资源到数据融合Agent的数据管道。

图14是基于资源调度脚本的数据管道构建流程图。资源调度脚本中的资源数据获取方式若是资源订阅语句则说明数据管道是由资源更新通知驱动。若不是资源订阅语句，则说明数据管道是由定时器的超时事件驱动。在数据管道构建时，首先判断资源调度脚本中的资源数据获取方式，若是资源订阅方式，则说明数据管道是由资源更新通知驱动，发送该资源订阅语句进行订阅操作。若订阅失败就打印日志然后退出，订阅成功就将订阅的资源ID作为key，脚本文件中其他语句作为value存入到哈希表中。若不是资源订阅发送，则说明数据管道是由定时器的超时事件驱动，需要根据应用资源所需的频率启动一个定时器，然后将定时器的ID和脚本文件内容存入哈希表中。以便在接收到定时器超时事件时，根据定时器的ID从哈希表中取出对应的资源调度脚本。取出资源调度脚本后，依次执行脚本的资源查询语句，查询传感器感知资源的资源数据，最后将查询到的资源数据发送给对应的数据融合Agent。