CN111447115A

CN111447115A - 一种物联网实体的状态监测方法

Info

Publication number: CN111447115A
Application number: CN202010220048.9A
Authority: CN
Inventors: 张少昂; 张青
Original assignee: Beijing Ruihang Core Technology Co ltd
Current assignee: Beijing aomo Technology Co.,Ltd.
Priority date: 2020-03-25
Filing date: 2020-03-25
Publication date: 2020-07-24
Anticipated expiration: 2040-03-25
Also published as: CN111447115B

Abstract

本发明涉及本发明涉及一种物联网实体的状态监测方法，属于物联网领域；方法包括以下步骤：针对每一类已投入使用的物联网实体，根据其行为特点建立对应的状态监测模型，形成模型数据库；对预接入的物联网实体进行模型匹配，得到对应的状态监测模型后接入物联网；对于接入物联网的实体，根据其使用的状态监测模型，监测实体的状态与行为，进行全生命周期管理和控制，判定所述物联网实体的异常状态。本发明只需要获取实体的状态增量即可实现同步，数据性能和安全性更优，不需要独立的中间同步系统，系统的延迟会有明显的降低，数据的实时性更好，原本因数据同步问题而受限的安全性也将得到极大地改善；在系统扩展性和适应性有较大提高。

Description

一种物联网实体的状态监测方法

技术领域

本发明涉及物联网领域，尤其涉及一种物联网实体的状态监测方法。

背景技术

现有方案中，物联网系统首先需要通过各处的上行节点进行数据信息的采集、清洗，获得不同类型不同区位的物联网节点的行为特征，基于此类行为特征，分析得出各个物联网实体节点的当前状态和全部行为流程。之后各个物联网设备厂商将对于本厂的设备管理软件进行的设计，发放给使用方进行基本的物联网实体的状态监测和管理。

其中比较常见的监测和管理模式是通过一个中间系统来实时维持管理系统和实体设备之间状态信息的同步性。同时定义一些基本操作，用于规范化内部的数据交互格式。在这样一种“协议”的支撑下进行各类内外部的交互。

由此，存在以下问题：

1.包括一个中间系统，解决实体设备和系统内部模型数据的同步性问题，增加软件或者硬件资源上的开销。

2.完成全部同步的信息采集量较大，使得整个系统的延时有所提高，可优化程度大大受限，增加的中间环节导致整体可靠性有所下降。

3.在复杂条件下，系统的扩展能力大大受限，或者只能以牺牲性能为代价来实现新的需求。

4.对于不同设备而言都需要各自不同的同步系统的开发和配置成本也会大大提高。

发明内容

鉴于上述的分析，本发明旨在提供一种物联网实体的状态监测方法，解决监测状态实时同步问题、延迟问题和系统扩展问题。

本发明的目的主要是通过以下技术方案实现的：

本发明公开了一种物联网实体的状态监测方法，包括以下步骤：

对已投入使用的每类物联网实体，建立对应的状态监测模型，形成模型数据库；

对预接入的物联网实体进行模型匹配，得到对应的状态监测模型后接入物联网；

对于接入物联网的实体，根据其使用的状态监测模型，监测实体的状态与行为，进行全生命周期管理和控制，判定所述物联网实体的异常状态。

进一步地，所述状态监测模型包括物联网实体接入物联网生命全周期的预期行为状态和从一个行为状态到下一个行为状态的动作信息，并将所述预期行为状态抽象为节点，将所述动作信息抽象为连接节点的边以及边权；在模型数据库中存储状态监测模型时，将与状态监测模型对应的包括模型部分内部结构、厂商、种类、模型id在内的模型特征信息一并进行存储，并形成所述模型特征信息与状态监测模型的映射关系。

进一步地，所述对预接入的物联网实体进行模型匹配，包括以下步骤：

步骤1)获取预接入的物联网实体的特征信息判断所述模型数据库中是否存在完全对口的模型；如果有，则采用模型数据库中的状态监测模型作为该物联网实体的状态监测模型；如果没有完全对口的模型则进入步骤2)；

步骤2)判断是否能生成近似的状态监测模型模板，如果是，则生成近似的状态监测模型模板，由接入方进行配置后接入物联网，如果没有，则进入步骤3)；

步骤3)手动构造预接入的物联网实体的状态监测模型。

进一步地，所述手动构造预接入的物联网实体的状态监测模型，包含以下步骤：

设定物联网实体接入物联网整个生命周期内的状态集合；

建立基于上述状态集合的状态转移关系，以及各个转移所对应的实体行为；

设定模型初始状态；

设定包括错误恢复、告警在内的状态异常信息。

进一步地，所述物联网实体生命周期管理，根据所述物联网实体使用的状态监测模型，以及当前实体设备的状态，当所述物联网实体发生了预设的行为时，实体状态即切换到状态监测模型上相应的目标节点的位置上；当实体发生了未预设的行为时，无法切换到状态监测模型上相应的目标节点的位置上，判定所述物联网实体发生异常状态。

进一步地，所述全生命周期管理和控制流程如下：

步骤S301、物联网系统监测物联网实体的当前状态S；

步骤S302、系统等待，直至当前发生了一个使物联网实体的状态变化的外部事件T；

步骤S303、判断外部事件T所引起的状态变化是否符合状态监测模型中状态变化的规则；如果符合，则进行步骤304，否则进行步骤305；

步骤S304、当前状态可正常进行转移，则根据外部事件T的规则，正常地允许将状态切换到下一个状态S₁，并跳转到步骤S302；

步骤S305、当前状态无法进行转移，出现状态异常，将此状态异常写入异常日志中。

进一步地，所述物联网系统设定为忽略模式，当前状态无法进行转移，出现状态异常时，则直接保留原状态S，并跳转到步骤S302进行系统等待。

进一步地，所述物联网系统设定为初始化模式，当前状态无法进行转移，出现状态异常时，则将状态强制重置为初始状态S₀，并跳转到步骤S302进行系统等待。

进一步地，所述物联网系统设定为手动处理模式，则等待管理员进行手动操作后，并跳转到步骤S302进行系统等待。

进一步地，在物联网监测实体的状态与行为时，通过获取物联网实体的状态增量来实现数据的同步，根据物联网实体执行的行为带来的状态增量，在对应的状态监测模型中推导出当前状态，实现当前状态的数据同步。

本发明有益效果如下：

1、相比现有解决方案需要强制同步所有数据，本发明方案中只需要获取实体的状态增量即可实现同步，数据性能和安全性更优。

2、相比于原技术需要收集实体设备的全部状态数据，本发明方案对数据收集的数量要求少了很多，不需要独立的中间同步系统，系统的延迟会有明显的降低，数据的实时性更好，原本因数据同步问题而受限的安全性也将得到极大地改善。

3、相比现有的技术中系统体系扩展性眼中严重受限，本发明方案中，以一套相对统一且与具体实体无关的交互模式，用于将各实体基于各自的状态监测模型进行集中管理，系统扩展性和适应性有较大提高。

本发明的其他特征和优点将在随后的说明书中阐述，并且，部分的从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

附图说明

附图仅用于示出具体实施例的目的，而并不认为是对本发明的限制，在整个附图中，相同的参考符号表示相同的部件。

图1为本发明实施例中的状态监测方法流程图；

图2为本发明实施例中的手动构造状态监测模型方法流程图；

图3为本发明实施例中的全生命周期管理和控制方法流程图。

具体实施方式

下面结合附图来具体描述本发明的优选实施例，其中，附图构成本申请一部分，并与本发明的实施例一起用于阐释本发明的原理。

本发明的一个具体实施例，公开了一种物联网实体的状态监测方法，如图1所示，包括以下步骤：

步骤S101、针对每一类已投入使用的物联网实体，根据其行为特点建立对应的状态监测模型，形成模型数据库；

物联网实体的类别定义为如下几个特征的集合：实体厂商、实体类型(例如烟感、热感、门锁等)、实体型号。此外，对于同厂商或同类型的实体，常常会有较多的相似点(交互协议、交互格式、状态监测模型等相似)，实际应用场景下系统可以基于这些有相似点的实体让配置者基于一个模板进行修改。

物联网实体的行为特点包含以下几部分：1、所包含的状态集合；2、所包含的状态转移集合；3、模型的告警和恢复规则。

行为特点是一个和状态监测模型相对应的概念，区别在于行为特点面向的是物联网实体在现实中的业务逻辑，而状态监测模型则是基于行为特点的一个抽象表述。

具体的，所述状态监测模型包括物联网实体接入物联网生命全周期的预期行为状态和从一个行为状态到下一个行为状态的动作信息，并将所述预期行为状态抽象为节点，将所述动作信息抽象为连接节点的边以及边权，构成一张物联网实体的状态转移图。从而将实体的状态转移模式全面、精准、可视化、可数据化地建立模型。

以投入使用的物联网密码门锁为例，根据物联网密码门锁的开、关、密码验证、离线等具体的行为，建立的状态监测模型中的状态节点包括：

节点①offline，具体指离线状态；

节点②opened，具体指开启状态；

节点③closed，具体指关闭状态；

节点④confirming，具体指密码验证状态；

将离线状态offline设置为初始状态；

连接状态节点的边包括：

a)E_start(offline→opened，offline→closed)，即节点①到节点②或节点③的连线，对应物联网密码门锁从离线状态到上线状态的开启状态或关闭状态的上线行为；

b)E_shutdown(opened→offline，closed→offline)，即节点②或节点③到节点①的连线，对应物联网密码门锁从上线状态的开启状态或关闭状态到离线状态的下线行为；

c)E_close(opened→closed)，即节点②到节点③连线，对应物联网密码门锁从开启状态到关闭状态的正常关门行为；

d)E_confirm(closed→confirming)即节点③到节点④连线，对应物联网密码门锁正常开锁行为的输入密码阶段；

e)E_open(confirming→opened)即节点④到节点②连线，对应物联网密码门锁正常开锁行为的认证通过后的开锁动作；

以上为正常状态转移的情况。

优选的，还可以设置异常状态转移的情况；如将节点③直接到节点②连线，即直接closed→opened的行为(没有经历E_confirm和E_open两个完整步骤)，则可以视为出现了非法开门行为；

此外，对于未进行定义的状态变化模式，也都可以分别定义成的异常的处理关联。

通过对每一类投入使用的物联网实体建立如上例所述的状态监测模型，可实现对物联网实体进行全面、精准、可视化、可数据化的全寿命的监测和管理。

具体的，可使用包括页面配置、可定制化配置或者图形化用户配置接口等方法建立物联网实体的状态监测模型。

上述模型数据库中的状态监测模型可以是由物联网实体的厂商直接提供的官方的状态监测模型也可以是由其他用户配置好的该型号的物联网实体的状态监测模型。

并且，在模型数据库中存储状态监测模型时，会将与模型对应的部分内部结构、厂商、种类、模型id等特征信息一并进行存储；所述特征信息可由厂商或者其他用户提供。

步骤S102、对预接入的物联网实体进行模型匹配，得到对应的状态监测模型后接入物联网；

具体的匹配及接入方法包括以下步骤：

步骤1)根据预接入的物联网实体的特点判断步骤S101中建立的模型数据库中是否存在完全对口的模型；如果有，则采用数据库中的状态监测模型作为该物联网实体的状态监测模型，将该物联网实体接入物联网；如果没有完全对口的模型则进入步骤2)；

具体的，所述完全对口指的是预接入的物联网实体包含与模型数据库中存储的状态监测模型具有完全相同的特征信息；

如在预接入新实体的时候，将可直接获得新实体的厂商、种类、模型id等特征信息与模型数据库中存储的特征信息进行查找匹配，匹配成功则可将模型数据库中特征信息与之匹配的模型作为预接入的物联网实体的状态监测模型进行套用。

步骤2)判断是否可生成近似的状态监测模型模板，如果是，则生成近似的状态监测模型模板，由接入方进行配置后接入物联网，如果没有，则进入步骤3)；

所述可生成近似的状态监测模型模板是根据包括预接入的物联网实体类型在内的特征信息，在模型数据库中匹配相似的状态监测模型，以此为模板进行相应的配置形成新的与该实体对应的状态监测模型。

采用近似的状态监测模型模板因为对于大部分的设备，即便没有绝对匹配的现成模型，但是总是大概率会有类似的现成模型存在的；比如对于某个厂的物联网门锁，即便目前数据库里面还没有它的模型，但是总该有类似的其他厂的锁之类的模型是可供参考。基于上述的原理，基于包括类型在内的特征信息，通过智能推荐算法或深度学习算法，在模型数据库中匹配相似的状态监测模型。

在采用近似的状态监测模型模板进行匹配相似的状态监测模型时，根据物联网实体和现有相似状态监测模型的相同处和差异处，而基于现有相似模型进行修改后，生成新的状态监测模型，一方面可用于物联网实体本次接入物联网，另一方面可将生成的状态监测模型存入模型数据库，作为后续相同的物联网实体的状态监测模型使用，通过近似的状态监测模型模板可以减少建立状态监测模型的工作量，并且参照现有的成熟的状态监测模型，可以是新建立的状态监测模型更加准确。

步骤3)手动构造预接入的物联网实体的状态监测模型；

如图2所示，具体包含以下步骤：

步骤S201、设定物联网实体接入物联网整个生命周期内的状态集合；

本实施例中的状态监测模型不需要每时每刻严格同步状态，而只需要通过之前已经可以确保正确的状态，和在此之后的所有行为记录(对应各个状态转移)，即可依次推导各个时间点上的状态；因此需要设定物联网实体接入物联网整个生命周期内的各状态集合，用于对联网实体进行检测。

步骤S202、建立基于上述状态集合的状态转移关系，以及各个转移所对应的实体行为；

步骤S203、设定模型初始状态；

步骤S204、设定包括错误恢复、告警在内的状态异常信息。

以物联网门锁为例的手动构造状态监测模型如下：

(1)设定{offline，opened，closed，confirming}为全寿命的状态集合，依次表示离线、开启、关闭、确认中状态(覆盖了门锁设备的整个生命周期)。

(2)设定转移关系E_start、E_shutdown、E_open、E_confirm、E_ctose。对应开机、关机、开启、确认、关闭五种实体行为。

(3)设定模型初始状态为offline，对应门锁初始状态为离线状态(关机)。

(4)设定模型的告警规则R_broken，当发生closed→opended时触发(对应锁被异常开启的情况)，对外进行一次告警。

当然，也可以对其他未进行定义的状态变化模式，设定成其他的告警规则。

通过步骤S102的模型匹配方法，实现了对各种预接入的物联网实体的模型匹配，用于后续的状态与行为的监测，具有较好的系统扩展性和适应性，解决了现有技术中系统体系扩展性受限的问题。

步骤S103、对于接入物联网的实体，根据其使用的状态监测模型，监测实体的状态与行为，进行全生命周期管理和控制，判定所述物联网实体的异常状态。

所述物联网实体生命周期管理，根据其使用的状态监测模型，以及当前实体设备的状态，当实体设备发生了预设的行为时，即在实体设备的状态切换动作和切换条件与状态监测模型中的相同时，设备的状态即切换到状态监测模型上相应的目标节点的位置上；当实体设备发生了未预设的行为时，无法切换到状态监测模型上相应的目标节点的位置上，判定所述物联网实体发生异常状态。

如图3所示，具体的全生命周期管理和控制流程如下：

步骤S301、系统监测物联网实体的当前状态S(初始状态为S₀)；

步骤S302、系统等待，直至当前发生了一个使物联网实体的状态变化的外部事件T(S→S₁)；

步骤S303、判断外部事件T(S→S₁)所引起的状态变化是否符合状态监测模型中状态变化的规则；如果符合，则进行步骤304，否则进行步骤305；

所述外部事件T(S→S₁)所引起的状态变化包括前行为状态、下一个行为状态以及从当前行为状态到下一个行为状态的动作信息。

步骤S304、当前状态可正常进行转移，则根据外部事件T(S→S₁)的规则，正常地允许将状态切换到下一个状态S₁，并跳转到步骤S302；

步骤305、当前状态无法进行转移，出现状态异常，将此状态异常写入异常日志中，同时以邮件、短信等形式反馈给相关系统管理员。

在步骤305中，对于出现异常的情况，

若系统设定为忽略模式，则直接保留原状态S，并跳转到步骤S302；

若系统设置为初始化模式，则将状态强制重置为S₀，并跳转到步骤S302；

若系统设置为手动处理模式，则等待管理员进行手动操作后，跳转到步骤S302。

具体的，所述管理员的手动操作根据近期所记录下来的模型行为日志以及错误日志进行。

在本实施例中，所述物联网实体出现状态异常包括两种，一种是物联网实体本身出现了故障，另一种是与物联网实体相关的消息传达出现了缺失或者错位；当出现这两种情况的任一种时，都意味着物联网实体和系统数据的一致性出现了问题，除了需要通知系统管理员之外，系统还会对此进行诸如强制同步之类的校准处理，以避免接下来引发一连串更多的问题。

以物联网密码门锁为例，如果出现了直接的closed→opened状态变化模式，则说明有两种可能性：一种为非法入侵，门被非正常方式打开；另一种可能性为门实际上正在被正常打开(走的是正常的E_confirm、E_open流程)，但是中间变化到confirming状态的时候出现了丢包的情况，导致此状态变化未能及时反馈给模型方面。对于前一种情况，系统管理员方面需要紧急处理，模型本身也可以采取措施(触发报警、紧急锁死等)；对于后一种情况，则需要进行数据的同步处理，以免由于状态不同步而引发后续连锁错误。

优选的，在本实施例中，可通过获取物联网实体的状态增量来实现数据的同步，无需每次都直接对状态进行同步，而是根据执行的行为带来的状态增量，在对应的状态监测模型中推导出当前状态，实现当前状态的数据同步；

例如，在对物联网门锁的监测过程中，假设物联网门锁最后被确认的状态为closed，且后续监测物联网门锁经历的状态为E_confirm、E_open两个状态，则在物联网门锁的状态监测模型中可以推导出当前状态为opened，就可以进行opened状态的数据同步。基于这一特性，我们不再需要每次都直接对状态进行一次同步，而是根据执行的行为进行推导即可。

该特点相比于现有的需要收集实体设备的全部状态数据的同步方法，对数据收集的数量要求少了很多，不需要独立的中间同步系统，系统的延迟会有明显的降低，数据的实时性更好，原本因数据同步问题而受限的安全性也将得到极大地改善，数据性能和安全性更优。

进一步地，为了实现通过建立状态监测模型、创建实体、以及维护状态几个基本行为，就可以通过本实施例公开的物联网实体的状态监测方法，对物联网实体进行状态监测和管理，还公开了用于状态监测模型查询维护的接口和实体查询维护的接口，从而将具体实体和数据与业务系统实现解耦，实现监测过程与具体程序语言无关，底层解耦，和所使用的实体类型无关，极大提高了移植型和兼容性。

首先，对物联网实体的状态监测模型的基本数据结构定义包括：

1、状态(state)，状态机中的最基本结构。可对应状态机图上的一个节点。数据结构要素包含状态名称(state name)，且需要保证该名称在状态机范围内独一无二。

2、转移(transaction)，状态机中的最基本结构。可对应状态机图上的一条有向边。数据结构要素包含转移名称(transaction name)、起始状态(source state)和目标状态(target state)，转移名称需要保证该名称在状态机范围内独一无二，且保证对于同一组起始状态和目标状态(有序对)，至多存在一个转移。

3、状态监测模型(state model)，本实施例设计的核心结构。包含模型名称(modelname)和模型结构(model structure，由状态、转移成)，模型名称需要保证在当前系统范围内独一无二。

4、状态实体(state instance)，本实施例设计的核心结构。包含模型名称(modelname)、实体名称(instance name)和实体状态(instance state)，实体名称需要保证在当前系统范围内独一无二。

基于上述的基本数据结构，对于状态监测模型的查询维护，提供如下模型接口：

1、模型创建接口(create_model)

接口数据包括：

输入值：{S}、{T}、N_model、S_init；依次代表状态(state)集合、转移(transaction)集合、模型名称(model name)和初始状态(initial state)。

输出值：O_create，用于表示创建成功与否。

模型创建接口基于状态、转移、告警三个集合建立业务逻辑，构建状态机模型。具体步骤如下：

a.将全部的状态用转移进行连接，构成一个完整的状态机。

b.生成模型后，将判断模型是否合法且完整(模型图是否联通，是否所有状态均可达，初始状态是否位于状态集合中)。

c.如果不合法，则创建过程结束，创建失败；否则跳至d。

d.模型正式入库，创建成功。

本实施例提供的模型创建接口可用于创建模型，为状态监测模型管理部分最为关键的一个接口。可用于直接构建完整的状态监测模型，创建成功的状态监测模型将用于后续实体的管理。

2、模型删除接口(create_model)

接口数据包括：

输入值：N_model。表示模型名称(model name)。

输出值：O_delete。表示是否删除成功。

模型删除接口实现将指定名称的模型进行删除的业务逻辑。具体步骤如下：

a.判断当前系统内是否有名为N_model的模型存在。

b.如果不存在，则删除过程结束，删除失败；否则跳至iii。

c.模型正式从库中删除，并删除此模型下属全部实体，删除成功。

本实施例提供的模型删除接口用于删除状态监测模型，与创建模型接口相对。值得注意的是删除模型操作也将一并删除模型下属的全部实例。

3、模型状态增加接口(delete_state)

接口数据包括：

输入值：N_model、N_state。依次表示状态监测模型名称(model name)和状态名称(state name)。

输出值：O_create。表示是否创建成功。

模型状态增加接口实现为指定名称的状态监测模型添加指定名称的状态的业务逻辑。具体步骤如下：

a.判断当前系统内是否有名为N_model的状态监测模型。

b.如果不存在，则创建过程结束，创建失败；否则，获取此状态监测模型，跳转至c。

c.判断当前模型内是否有名为N_state的状态。

d.如果存在，则创建过程结束，创建失败；否则，跳转至e。

e.在当前模型中正式新增名为N_state的状态，更新状态监测模型，创建成功。

本实施例提供的模型状态增加接口用于对当前状态监测模型进行修改，添加状态。

4、模型状态删除接口(delete_state)

接口数据包括：

输出值：O_delete。表示是否删除成功。

模型状态删除接口实现为指定名称的状态监测模型删除指定名称的状态的业务逻辑。具体步骤如下：

a.判断当前系统中是否有名为N_model的状态监测模型。

b.如果不存在，则删除过程结束，删除失败；否则，获取此状态监测模型，跳转至c。

c.判断当前模型内是否有名为N_state的状态。

d.如果不存在，则删除过程结束，删除失败；否则跳至e。

e.状态正式从状态监测模型中删除，同时与此状态直接关联的转移和告警也将被一同删除，删除成功。

本实施例提供的模型状态删除接口用于对当前状态监测模型进行修改，删除现有状态。

5、模型状态转移创建接口(create_transaction)

接口数据包括：

输入值：N_model、N_transaction、

依次表示模型名称(modelname)、转移名称(transaction name)、转移起始状态名称(source state name)和转移目标状态(target state name)。

输出值：O_create。表示是否创建成功。

模型状态转移创建接口实现为指定的状态建立转移的业务逻辑。具体步骤如下：

a.判断当前系统中是否有名为N_model的状态监测模型。

c.判断当前模型中是否有尚无名为N_transaction的转移，且状态

和状态

之间是否尚无转移(即上述两条件是否同时满足)。

d.如果不同时满足，则创建过程结束，创建失败；否则，跳转至e。

e.正式创建从状态

到状态

的转移，命名为N_transaction，存入当前状态监测模型，创建成功。

本实施例提供的模型状态转移创建接口用于对当前状态监测模型进行修改，基于当前状态监测模型创建新的转移。

5、模型状态转移删除接口(delete_transaction)

接口数据包括：

输入值：N_model、N_transaction。依次表示模型名称(model name)、转移名称(transaction name)。

输出值：O_delete。表示是否删除成功。

模型状态转移创建接口实现为删除指定的状态转移的业务逻辑。具体步骤如下：

a.判断当前系统中是否有名为N_model的状态监测模型。

c.判断当前状态监测模型中是否存在名为N_transaction的转移。

d.如果不存在，则删除过程结束，删除失败；否则，跳转至e。

e.从状态监测模型中删除当前转移，更新状态监测模型，删除成功。

本实施例提供的模型状态转移删除接口用于对当前状态监测模型进行修改，基于当前状态删除现有转移。

对于物联网实体的查询维护，提供如下模型接口：

1、实体创建接口(create_instance)

接口数据包括：

输入值：N_model、N_instance。依次表示模型名称(model name)和实体名称(instancename)

输出值：O_create。表示创建是否成功。

业务逻辑具体如下：

a.判断当前系统中是否有名为N_model的状态监测模型。

c.判断当前系统中是否有名为N_instance的状态实例。

d.如果不存在，则创建过程结束，创建失败；否则，获取此状态实例，跳转至e。

e.创建新实例，命名为N_instance，将其当前状态设置为

(即当前状态监测模型创建时设置的S_init)，存入数据库，创建成功。

所述实体创建接口可用于基于现有状态监测模型创建新的状态实体，为本部分核心功能之一。

2、实体删除接口(delete_instance)

接口数据包括：

输出值：O_delete。表示删除是否成功。

业务逻辑具体如下：

a.判断当前系统中是否存在名为N_model的状态监测模型；

b.如果不存在，则删除过程结束，删除失败；否则，获取此状态监测模型，跳转到c；

c.判断当前系统中是否存在名为N_instance的状态实例；

d.如果不存在，则删除过程结束，删除失败；否则，获取此状态实例，跳转到e；

e.正式删除当前实例，删除成功。

所述实体删除接口可用于删除现有的状态实体，用于本状态系统中的实体维护。

3、实体状态变更接口(instance_state_change)

接口数据包括：

输入值：N_model、N_instance、N_state。依次表示模型名称(model name)、实体名称(instance name)和状态名称(state name)

输出值：O_change。表示变更状态是否成功

业务逻辑具体如下：

a.判断当前系统中是否存在名为N_model的状态监测模型。

b.如果不存在，则变更状态过程结束，变更状态失败；否则，获取此状态监测模型，跳转到c。

c.判断当前系统中是否存在名为N_instance的状态实例。

d.如果不存在，则变更状态过程结束，变更状态失败；否则，获取此状态实例，跳转到e。

e.判断当前实例中是否存在名为N_state的状态。

f.如果不存在，则变更状态过程结束，变更状态失败；否则，获取此状态，设为S′，跳转到g。

g.设实体当前状态为S，判断当前状态监测模型中是否存在从S到S′的转移。

h.如果不存在，跳转至i；否则，设此转移为T，跳转至j；

i.系统判定为当前实体状态出现异常转移行为，触发告警机制，将相关信息(N_model、N_instance、S、S′，以及当前时间等)发送给告警接收端。变更状态异常(注：变更状态异常为一种独立状态，不同于变更状态失败，专门用于表示触发异常的情况)。

J.触发转移T，当前实例状态正式变更为S′，变更状态成功。

所述实体变更接口可用于同步各实体的实时状态，跟踪实体的动向，同时对异常行为进行拦截和告警，为本状态管理方法的核心接口。

以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。

Claims

1.一种物联网实体的状态监测方法，其特征在于，包括以下步骤：

2.根据权利要求1所述的状态监测方法，其特征在于，所述状态监测模型包括物联网实体接入物联网生命全周期的预期行为状态和从一个行为状态到下一个行为状态的动作信息，并将所述预期行为状态抽象为节点，将所述动作信息抽象为连接节点的边以及边权；在模型数据库中存储状态监测模型时，将与状态监测模型对应的包括模型部分内部结构、厂商、种类、模型id在内的模型特征信息一并进行存储，并形成所述模型特征信息与状态监测模型的映射关系。

3.根据权利要求1所述的状态监测方法，其特征在于，所述对预接入的物联网实体进行模型匹配，包括以下步骤：

步骤3)手动构造预接入的物联网实体的状态监测模型。

4.根据权利要求3所述的状态监测方法，其特征在于，所述手动构造预接入的物联网实体的状态监测模型，包含以下步骤：

设定物联网实体接入物联网整个生命周期内的状态集合；

设定模型初始状态；

设定包括错误恢复、告警在内的状态异常信息。

5.根据权利要求1所述的状态监测方法，其特征在于，所述物联网实体生命周期管理，根据所述物联网实体使用的状态监测模型，以及当前实体设备的状态，当所述物联网实体发生了预设的行为时，实体状态即切换到状态监测模型上相应的目标节点的位置上；当实体发生了未预设的行为时，无法切换到状态监测模型上相应的目标节点的位置上，判定所述物联网实体发生异常状态。

6.根据权利要求5所述的状态监测方法，其特征在于，所述全生命周期管理和控制流程如下：

步骤S301、物联网系统监测物联网实体的当前状态S；

7.根据权利要求6所述的状态监测方法，其特征在于，所述物联网系统设定为忽略模式，当前状态无法进行转移，出现状态异常时，则直接保留原状态S，并跳转到步骤S302进行系统等待。

8.根据权利要求6所述的状态监测方法，其特征在于，所述物联网系统设定为初始化模式，当前状态无法进行转移，出现状态异常时，则将状态强制重置为初始状态S₀，并跳转到步骤S302进行系统等待。

9.根据权利要求6所述的状态监测方法，其特征在于，所述物联网系统设定为手动处理模式，当前状态无法进行转移，出现状态异常时，则等待管理员进行手动操作后，并跳转到步骤S302进行系统等待。

10.根据权利要求1-9任一所述的状态监测方法，其特征在于，在物联网监测实体的状态与行为时，通过获取物联网实体的状态增量来实现数据的同步；根据物联网实体执行的行为带来的状态增量，在对应的状态监测模型中推导出当前状态，实现当前状态的数据同步。