一种基于状态模型的物联网实体互操作引擎的制作方法

本发明属于物联网技术领域，具体涉及一种基于状态模型的物联网实体互操作引擎。

背景技术：

物联网实体(下称实体)的概念指物联网中接入网络、与服务器相连接的设备。物联网实体的互操作是指多个物联网实体，其中某一实体可经由某种条件而触发另外的实体发生某种变化，实现实体间的交互。现有技术中，实体标签基于语义，触发规则由自然语言描述并根据实体的语义标签判断条件触发。一般的互操作流程为：由某一物联网实体上传语义标签，在用户端给出匹配的互操作规则，并由用户下达操作指令至另一物联网实体。

现有方案，实现了规则的配置、联网设备的交互。然而在目前的技术中，设备使用语义标签并以此生成自然语言触发规则的机制，对于只有简单状态的设备而言没有必要的同时也不具有普适性和扩展性，在实际生产生活中难以推广到不同厂商的不同设备。此外，现有技术中，没有解决多设备的并发控制问题，即更多地着眼于两实体交互的简单场景。在复杂的实际应用生产中，面临着大量设备同时进行互操作的并发问题。

技术实现要素：

有鉴于此，本发明提供一种基于状态模型的物联网实体互操作引擎，本发明适用状态机模型，无需考虑用何种语义可表达某种复杂的、难以描述的实体状态，因此达到了抽象化、规则化标签的目的。

实现本发明的技术方案如下：

一种基于状态模型的物联网实体互操作引擎，包括数据库、消息收发模块、状态模型解析模块、触发控制模块及触发指令调度器；

数据库中预先存储有物联网实体的状态模型和触发模型；

消息收发模块，接收物联网实体上传的消息并进行预处理，若消息为触发请求时，将其上传至触发控制模块；接收消息触发指令调度器下发的触发指令消息，生成状态转移指令向物联网实体下发；

触发控制模块，接收到触发请求时，从数据库中调取发送该触发请求的物联网实体的所有触发模型，并与上传消息中的该实体的状态标签进行匹配，若匹配到触发模型，则触发状态模型解析模块从数据库中提取对应被触发实体的状态模型；将收到状态转换函数和触发模型中的触发指令进行匹配，可匹配的触发指令发送给触发指令调度器；

状态模型解析模块，用于从数据库中提取被触发实体的状态模型，并解析出被触发实体的状态转换函数传给触发控制模块；

触发指令调度器，根据调度规则向消息收发模块下发触发指令。

进一步地，本发明在进行触发模型匹配时，当没有匹配到触发模型时，则丢弃该请求或将其上报至用户，等待用户下达触发指令。

进一步地，本发明在进行触发指令匹配时，无法匹配的触发指令被丢弃或上报用户。

进一步地，本发明所述触发模型由互操作发出实体的唯一标识符、其相应状态、互操作响应实体和触发指令构成，表示为“uuid@src_状态@src—uuid@dst_触发指令”，其中“uuid@src”为互操作发出者的唯一标识符,“状态@src”为满足触发时发出者应达到的状态，“uuid@dst”为互操作响应者的唯一标识符，“触发指令”为响应者待执行的触发指令。

进一步地，本发明所述触发指令分为直接触发和条件触发两类，所述条件触发为只有当触发条件被满足时，才可能被触发。

进一步地，本发明所述触发指令表示为“状态1_状态2_time”，状态1和状态2为响应者状态集中的状态符，time为响应者完成状态迁移的时间限制。

进一步地，本发明若状态1不为null，则解读为条件触发，表示“若响应者处于状态1，则在time时间内直接迁移到状态2”，若状态1为null，则为直接触发，表示“响应者须在time时间内从当前状态直接迁移至状态2”，若time为null，即没有时间限制，若time不为null，即有触发时间限制。

进一步地，本发明所述调度规则为fifo规则。

进一步地，本发明所述被触发实体为同一实体时，所述调度规则为：根据触发指令执行前后实体状态安排指令顺序，使得前置条件不被满足的指令，接在后置条件可满足所述前置条件的指令后执行。

进一步地，本发明所述触发状态模型解析模块从数据库中提取对应被触发实体的状态模型为：触发控制模块输出被触发实体编号和两个状态给状态模型解析模块，所述状态模型解析模块根据被触发实体编号从数据库中取出相应状态模型，判断出所述两个状态之间是否可以转移，生成状态转换函数传输给触发控制模块。

有益效果

第一，本发明规则化、抽象化物联网实体状态标签，简化对物联网实体的描述，适应物联网实体真实状态，达到更高的普适性及扩展性。本发明使用状态机模型将物联网实体的运作抽象为状态机模型，使用状态机中的状态描述实体以替代语义标签，状态转换函数表达某实体状态的迁移。语义需要根据不同实体不同状态而设定，然而使用状态机，则两实体的不同状态可用同一状态符表示。不同实体的状态集与状态如何表示无关，只与状态集中状态的数量有关。因此达到了抽象化、规则化标签的目的。也因此无需考虑用何种语义可表达某种复杂的、难以描述的实体状态，使用状态集中的某种状态符既可表达，实现了更优越的普适性和扩展性。

第二，本发明由于使用基于状态模型的触发模型，具有条件触发、直接触发两种触发模式，并可配置时间参数，并非是“某实体状态达到某阈值则直接触发另一实体”的简单互操作场景，更加贴合实体在实际场景中的使用。

第三，本发明设计的引擎具有在“多实体并发互操作”的场景下，调度触发请求的功能。采用fifo规则，先来的请求先被处理，超过条数限制的请求直接抛弃，保证了并发场景下，处理请求的有序性和高效性。

附图说明

图1为本发明物联网实体互操作引擎的示意图；

图2为有限状态机模型的示意图；

图3为触发模型的解析与处理流程图；

图4为响应者状态机模型的示意图；

具体实施方式

下面结合附图和具体实例对本发明进行详细说明。

本发明实施例一种基于状态模型的物联网实体互操作引擎，包括数据库模块、消息收发模块、状态模型解析模块、触发控制模块及触发指令调度器共五个模块，与设备端(物联网实体集合)和用户端构成一个物联网系统。

数据库存储实体状态模型、触发模型和物联网实体上传的相关信息记录。

消息收发模块作为消息上行和下行的中间处理模块，接收物联网实体上传的状态消息，并进行预处理，当消息为实体的状态消息时，则存入数据库中，当消息为触发请求时，将其传输至触发控制模块中，接收触发指令调度器下发的触发指令消息，生成状态转移指令向物联网实体下发；

触发控制模块，接收到触发请求时，从数据库中调取发送该触发请求的物联网实体的所有触发模型，并与上传消息中的该实体的状态标签进行匹配，若匹配到触发模型，则触发状态模型解析模块从数据库中提取对应被触发实体的状态模型，将收到状态转换函数和触发模型中的触发指令进行匹配，可匹配的触发指令发送给触发指令调度器；

状态模型解析模块，用于从数据库中提取被触发实体的状态模型，并解析出被触发实体的状态转换函数传给触发控制模块；

触发指令调度器，根据调度规则向消息收发模块下发触发指令。

本系统的工作原理为：某物联网实体a将当前状态信息包装为一个消息上传至消息收发模块，消息收发模块进行消息的预处理，即解析消息，检查消息是否合法，实体的状态标签是否在其状态模型的状态集中，若不在，则根据设置，可以将这个消息记为异常，并上报用户，若在，则进一步判断消息的类型，若是普通消息，例如为当前状态记录消息，则将该消息进行存储，若消息为触发类消息，则向触发控制模块发送触发请求，触发控制模块从数据库中提取触发模型，与实体的状态标签匹配，具体为：触发控制模块从数据库中调取实体a的所有触发模型与实体a的状态标签进行匹配，若没有匹配到任何触发模型，可以丢弃该请求或将其上报至用户，等待用户下达触发指令；若匹配到触发模型，则从数据库提取对应被触发实体b的状态模型，从状态模型解析模块获取被触发实体b的状态转换函数，与触发模型中的触发指令匹配，无法匹配的触发请求被丢弃或上报用户，可匹配的需求发送给触发指令调度器，触发指令调度器根据调度规则，将触发指令下发给消息收发模块。最终由消息收发模块处理触发指令，并包装为一个状态转移指令消息下发给另一实体。

例如，某烟感在检测到较高烟雾浓度时进入警报状态，此烟感将其警报状态以及其他物理信息包装为一个触发消息上传到消息收发模块，消息收发模块检查消息判定为合法后向触发控制模块发送触发请求，触发控制模块匹配到烟感报警时触发模型，解析到触发指令，触发烟感所在楼层的报警器报警。

如图2所示，本引擎是基于状态机模型实现的，一个状态机模型中包括有穷状态集和状态转换函数(即图2中的箭头所示状态转换关系)，其中有穷状态集包括起始状态和终止状态集，状态转换函数可用状态转换表来表示。物联网实体的状态标签即可用图2中状态1、2、3中的某一个状态符表示。

图2可表示某种电饭煲的状态转换。状态1为电饭煲关闭，状态2为煮饭模式，状态3为保温模式。当开始煮饭时，状态1迁移至状态3；饭煮好了，则电饭煲状态由2迁移至3；用户开饭时，关闭电饭煲，状态由3转移至1。

图2亦可表示一架空调的状态转换。状态1为空调关闭，状态2为制冷模式，状态3为待机模式。当打开空调制冷时，状态1迁移至状态2；温度到达设置值时，状态2迁移至状态3；当温度升高到设定阈值时，状态3重新迁移至状态2；当用户不需要空调时，空调从当前状态迁移至1。

上述对状态机的解释并未罗列出所有状态转移，但是通过两个例子可以看出，两种不同实体的状态可以用统一状态集表示，抽象了实体状态和行为。

本发明的一实施例中触发模型由互操作发出实体的唯一标识符、其相应状态、互操作响应实体和触发指令构成，可表示为“uuid@src_状态@src—uuid@dst_触发指令”。其中“uuid@src”为互操作发出者的唯一标识符,“状态@src”为满足触发时发出者应达到的状态，“uuid@dst”为互操作响应者的唯一标识符，“触发指令”为响应者待执行的触发指令。

本发明的一实施例触发指令分为直接触发、条件触发，并可带有时间限制条件，由响应者须满足的当前状态、须迁移至的状态和限制时间构成，可表示为“状态1_状态2_time”。状态1和状态2为响应者状态集中的状态符，time为响应者完成状态迁移的时间限制。若状态1不为null，则解读为条件触发“若响应者处于状态1，则在time时间内直接迁移到状态2”；否则为直接触发，解读为“响应者须在time时间内从当前状态直接迁移至状态2”。若time为null，即没有时间限制，则默认time为无穷大。

例如，针对烟感触发，报警器只有关闭、空闲(开)、在使用的状态。如果不配置状态1，那么无论报警器在什么状态，都使其转变为在使用的状态。如果状态1配置为空闲，那么只有报警器当前是空闲时才能被触发。对于time，如果不配置，在可触发的情况下，触发指令下达后，报警器响应这个触发指令没有时间限制，1s就响应或30min后才响应都可以，但是如果配置了时间限制，比如1min，那么报警器收到触发指令后必须在1min内警报火情。

如图3所示，触发控制模块解析触发模型，并处理触发请求。对条件触发模型解析出的触发条件可表示为“若发送消息的实体的uuid等于‘uuid@src’，实体的当前状态等于‘状态@src’，且编号‘uuid@dst’的实体的当前状态为状态1，从状态1可迁移至状态2”，对于满足条件的需求的处理为生成时间限制为time的触发指令“编号为‘uuid@dst’的实体的状态向状态2迁移”，无法匹配到模型的触发需求直接被抛弃或上报用户。对直接触发模型解析出的触发条件可表示为“若发送消息的实体的uuid等于‘uuid@src’，实体的当前状态等于‘状态@src’，编号为‘uuid@dst’的实体可从当前状态迁移至状态2”，对于满足条件的需求的处理为生成时间限制为time的触发指令“编号为‘uuid@dst’的实体的状态向状态2迁移”，无法匹配到模型的触发需求直接被抛弃或上报用户。由于一个实体在单位时间内可执行的触发指令有限，可选择配置其单位时间执行触发指令条数限制，当一个单位时间的时间窗内，若触发控制模型解析到超出限制条数的需求，则直接抛弃该需求。

本发明一实施例中，调度规则可采用优化的方法，当单位时间内收到了被触发的物联网实体为同一实体的指令，则可对其进行规划，根据触发指令执行前后实体状态安排指令顺序，使得前置条件不被满足的指令a接在后置条件可满足指令a前置条件的指令后执行。例如，对某一在状态3的响应者，有在单位时间内按先后顺序进入的3条无时间限制的指令，指令1为“响应者状态直接向状态4迁移”，指令2为“若响应者在状态1，则其状态向状态2迁移”，指令3为“若响应者在状态3，则其状态向状态1迁移”，该响应者的状态机如图4所示。

若采用fifo算法，虽然效率高，可以快速地处理完三条指令，但是前两条指令会被抛弃。但是假如用户需要较高的互操作执行率(被响应者执行的触发请求数/总触发请求数)，则fifo的效果并不理想，可以使用优化算法，将指令执行顺序调整为指令3、指令2、指令1，则三条指令都可以被执行。

本发明一实施例中，触发控制模块从状态模型解析模块提取的状态转换函数也可以换为一个布尔值，由触发控制模块给出实体编号和两个状态，状态模型解析模块根据实体编号从数据库取出相应状态模型后，可直接解析判断两个状态间是否可转移，并将结果返回给触发控制模块。假若状态模型中的状态转换函数以二维表的形式直接存储在数据库，则可直接根据编号和两个状态在数据库中检索两状态是否有可迁移的关系。

本发明将物联网实体的互操作集成至一个物联网实体互操作引擎，实现了实体状态模型与触发模型的配置和解析、互操作需求的调度和执行，通过所述引擎，达到工程化的交互，解决上述现有技术存在的问题。

综上所述，以上仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。