一种电力物联网的事件驱动型消息交互方法与流程

本发明涉及一种消息交互方法，特别是一种电力物联网的事件驱动型消息交互方法。

背景技术：

国网公司经过sg-186和sg-erp建设，以终端为基础，利用自有、租赁网络和信息化系统全面覆盖“发输变配用”各个生产环节的电力物联网初具规模，支撑了“国调、省调、地调”三级调度、输变电状态监测、配电自动化、用电信息采集、电力营销等多项生产业务。随着“云大物移智”、无线接入、互联网等技术的不断演进，电力物联网目前正经历从垂直一体化封闭模式向以水平环节为核心的开放模式转变。但是公司物联网整体建设应用在终端层面的接入方式以及业务性能需求上仍存在下述不适应性：

(1)电力系统终端设备数量日趋增多，类型、物理接口繁杂多样，底层连接协议差异大，功能越发复杂，设备对厂商依赖增强的局面，业务应用开发周期长、扩展困难。传统电力物联网接入中，业务终端与接入设备紧耦合，接入设备和网络重复建设，终端接入安全防护能力不足。同时，需要解决为不同系统的终端异构接入问题以及随之而来的系统间数据共享和业务实时性问题。

(2)电网业务面临实时性、互联互通以及安全要求的提升，传统方式下终端数据全部上传到业务主站的云平台进行集中式处理，会导致较长传输时延，带来带宽以及能耗的浪费，在造成一些时延敏感型应用性能劣化的同时，也会给骨干通信网络、后台业务系统带来巨大的处理压力。同时，需要解决业务系统间的互联互通和业务隔离问题。

为解决以上问题，国网公司推进具备模型适配、数据存储、边缘计算、安全防护等功能边缘物联代理装置研制，通过屏蔽底层网络差异性，打破传统物联网纵向封闭模式，为现场通信网络和广域传输网络建立“枢纽”，协助实现有效的电网态势感知，为提高电网规范化管理能力提供有效支撑。

目前，边缘物联代理装置的软硬件平台架构完成搭建，相应通用功能与专用功能也完成研发进入测试阶段，在实际应用过程中，虽采用物模型的形式将异构的原始数据封装成统一的事件格式，向用户提供标准化的接口，但仍存在因信息化人员对电力业务不熟悉所导致物联应用设计时，存在与业务贴合度不高，或者托管于跨地域分布的智能终端上的业务流程应用无法尽可能快速地响应各种感知事件等情况。

技术实现要素：

本发明的目的在于克服现有技术的不足之处，而提供一种使得物联设备能够作为一种可被业务流程执行引擎所直接解析的资源出现在业务流程对象库中，通过建立事件驱动的业务模型，实现业务流程的自动化提取，大大降低业务应用的开发成本。

一种电力物联网的事件驱动型消息交互方法，首先对电力物联网的物联管理平台、边缘物联代理/智能终端中跨组织或部门的协作业务流程建模，而后定义业务流程资源模型的执行语义，然后提出流程执行引擎对业务模型的解析机制，最后实现微服务体系架构中的消息交互，从而实现消息交互。

本发明的电力物联网的事件驱动型消息交互方法，利用物联管理平台为paas层物联网开放平台，解决海量连接、协议适配、数据存储、设备管理、规则引擎、事件告警等应用开发的共性问题，实现对边缘物联代理装置、智能终端的集中数据采集与管理，并向业务中台提供标准化数据，促进国网的业务融合和数据共享。其中边缘物联代理装置/智能终端为终端标准接入及边缘计算能力提升的通用设备，实现对业务终端的基于不同标准化接口的全业务泛在接入，支持业务敏捷部署和综合接入及智能处理。

物联管理平台、边缘物联代理/智能终端中跨组织或部门的协作业务流程建模，首先构建全生命周期服务管理模型，定义业务流程应用程序服务外部接口，其次，定义业务流程应用程序的内部组件，内部组件包括服务事件管理器、服务状态管理器及服务替换管理器，最后，明确采用流程协作图的方式将业务服务进行连接，通过控制业务节点形成整个业务流程。

为了解决电力物联网跨终端业务流程应用的复杂性和大规模特性，实现分布式的以事件为核心的电力业务流程建模，重点在于判断内部业务流程的最小资源需求和判断业务流程的事件指定序列，同时该序列与其他协作设备的交互结构一致，实现从物理智能设备实体到标准业务流程资源任务的直接映射。

全生命周期服务管理模型包含有服务名称、接口类型和统一资源标识三个属性，服务名称包含有业务流程应用程序服务、服务描述、服务处理及服务定义，首先，服务描述通过服务处理程序实现，并生成服务定义文件，然后，使用服务定义文件描述业务流程应用程序服务和调用服务的输入/输出参数，使得多个服务共享一组统一的接口获得资源，而后生成一个服务描述文件。

所述的服务事件管理器，事件管理器作为业务流程应用服务程序之间的通信基础，将智能终端服务被映射到发布订阅网络上实现分布式地执行，当智能终端感知到所处的物联网环境发生变化时，它就会以服务发布者的身份将结构化的信息发送到事件管理器，事件主题的管理采用轻量级目录访问协议，服务订阅者通过ldap订阅感兴趣的事件主题，事件管理器通过基于拥塞控制的方法来确保网络性能。

事件管理器通过基于拥塞控制的方法来确保网络性能具体为：每一个智能终端上部署的业务流程都维持了事件缓冲队列，用变量u表示这个缓冲队列，u的值域是0到1，表示缓冲队列占用百分比。为了使u得值尽可能真实地反映网络性能的真实情况，使用变量f表示这个缓冲队列的瞬时占用率，此外，本文以固定的频率对f进行取值，并根据公式unew＝a·uold+(1-a)f对u的值进行更新，常数a表示u的更新速率。当u的值超过一个预设的阈值时，缓冲队列进入“预警”状态，此时，事件管理器将抑制从发布订阅系统订阅事件的速率，在最坏的情况下，也就是说缓冲队列被完全占用时，事件管理器将会根据优先级顺序对某些事件进行摒弃处理。

所述的服务状态管理器，服务状态管理器用于对服务进行监控和管理，其具体流程为：(1)每个参与协作的智能终端向服务状态管理器定期发送心跳事件，以显示其活动性；

(2)当智能终端在给时域内无法发送心跳事件，服务状态管理器会通过将包含设备id的事件发布到服务事件管理器来报告其不可用性；

(3)挂起业务流程应用程序服务，方法是将其设置为等待状态，直到替换失败的服务；

(4)服务事件管理器收到此事件，它将向服务替换管理器发布一个命令，使其替换不可用的服务。服务替换的基本目标是发现可替换的服务，从而替换不可用的服务；

(5)服务替换管理器请求服务描述文件来获取可用的候选服务列表,然后，服务替换管理器搜索定义文件与不可用服务匹配的服务,一旦检测出候选服务，服务替换管理器将随机选择其中可以替换不可用服务的一个服务；

(6)服务替换管理器用新的业务流程实例替换旧的业务流程实例，并修改服务描述文件,服务替换过程中的核心任务是确保状态同步，这意味着一个服务必须从其被挂起的安全点恢复执行；

(7)服务状态管理器会定期对终端状态进行检查，对业务流程应用程序服务的状态进行持久化，当服务替换完成时，业务流程应用程序将恢复运行。

业务流程建模，采用协作图来描述跨组织或部门的流程间的交互逻辑。

采用协作图来描述跨组织或部门的流程间的交互逻辑。协作图通常包含两个或两个以上的泳池，用它们来表示协作流程图中不同参与者之间的消息交互，是通过使用消息流连接不同的泳池，有时连接的是泳池中具体的流程元素对象。泳池是协作图中业务流程参与者的活动容器，业务流程的参与主体可以是公司、部门或者是单独的个体，其定义包含在partnerrole类中。泳池可以是空白的，或者partnerrole是对用户“透明”的，标识泳池并不总是包含可执行的业务流程。为了使流程图清晰，泳池可以水平或垂直方向进行扩展。泳池的基本功能是为业务流程任务节点之间控制流的执行提供一个容器。控制流可以跨越泳池中泳道的边界，但是不能跨越泳池的边界。

单独的业务流程是完全包含在泳池内，归属于不同泳池的业务流程只有通过消息流才可以进行连接。图3给出这种通过消息流连接不同泳池中对象的方式。

业务流程资源模型的执行语义，为了明确业务流程应用程序服务的外部接口，在服务描述模块构建业务流程资源模型的执行语义，确保保证对业务流程模型中元素对象清晰而准确的理解，其具体操作为：

(1)启动事件：当单独的启动事件触发时，业务流程执行引擎会创建一个新的流程实例，然后执行后续的控制流；

中间事件：流程执行引擎等待特定的事件到达后继续流程的流转,等待时间是从中间事件到达时开始计算的,一旦目标事件到达，马上消除流程，然后执行后续的控制流；

边界事件：对于边界事件，有同步和异步两种处理方式，如果是同步的处理方式，与中间事件一样，流程执行引擎需要等待特定的事件到达来继续流程的流转，如果流程执行引擎一直没有捕获目标事件，那么流程将一直处于挂起状态；如果是异步的处理方式，流程执行引擎会将当前的任务节点执行挂起操作，然后继续执行后续的控制流，而不用一直等待目标事件；

(4)终止事件：终止事件有正常终止事件和异常终止事件两种类型，不论是哪种类型的终止事件，流程执行引擎都会终止与该事件相关联的各种行为，如果一个流程中的所有任务节点都得到了响应，进一步来说也就是，所有的启动事件都己经被触发，所有的控制流都得到执行，且流程实例中不再包含任何一个token，那么这个业务流程将被正常终止，否则其将被异常终止。

针对电力物联网环境下事件驱动的多流程交互设备，其数据来源是离散分布的智能终端，不同的智能终端采集并上传的数据格式不尽相同，因此我们在对其进行路由、转发和处理前，需要将其封装成了统一的事件格式。因此，我们需要了解在业务流程执行时，业务流程引擎对其具体的执行语义，确保业务流程模型中元素对象清晰而准确的理解。

流程执行引擎对业务模型的解析机制,流程执行引擎允许用户通过描述要实现目标需要执行的步骤来对业务目标进行建模，并且使用图形化的方式描述业务流程模型,流程执行引擎关注可执行的业务流程，这些业务流程包含足够的细节，它们可以在任何遵循建模规范的容器中执行,流程执行引擎所涉及的组件包括：核心服务，在启动业务流程时，流程执行引擎会建立会话，这个会话的生命周期与流程实例的生命周期一样，会话需要对知识库进行引用，知识库中包含了所有与业务流程定义相关的信息，通过知识库，业务流程设计人员可以随时查看所需的流程信息，在创建会话时，需要首先创建知识库，加载所有必要的业务流程定义信息，这些流程定义信息可以来自于环境变量、iot系统、或者是流程仓库，然后流程执行引擎就可以实例化一个业务流程，会话提供了对事件进行侦听的功能，通过会话，注册或者删除事件侦听器，事件侦听器内嵌在业务流程的执行引擎中，通过控制业务流程任务节点的启动或停止，实现对业务流程实例运行状态的侦听，事件对象提供对业务流程相关信息的访问权限，业务人员通过流程事件侦听器这个api来创建自己的事件侦听器，在使用事件侦听器api时，这些事件可以被认为是一个堆桟，事件的发生必然是它之前事件执行产生的结果，也必然会对它之后的事件产生影响。

微服务体系架构中的消息交互，在bpmn2.0规范现有的基础上扩展了机器可读模型，首先引入一个活动类的子类，并将物联网环境下的实体设备资源分配直接引入到活动的级别，智能终端设备类继承了活动类的模型关联和属性，通过配置相关参数，智能终端的相关信息将被整合生成json文档，并被传递到流程的执行阶段，其次还设计了接口类来实现智能终端抽象类，接口类继承了baseelement的模型关联和属性，并为智能终端服务类留下标准化接口，所有业务流程元素都包含json结构定义中的id，并通过这些id对业务流程元素实现引用，json支持按id引用和按名称(qname)引用，qname由两部分组成：可选的名称空间前缀和本地部分，当用于引用bpmn2.0元素时，本地部分是流程元素的id。

将业务流程拆分、实现快速开发和部署的微服务体系架构，其具体为：微服务把一个大型的独立的服务拆分成多个微服务单元，从而在不影响整个程序堆栈的前提下对单个组件进行扩展，通过去范式化，将服务直接提供给用户，每个功能模块有自己特定的服务，不同的功能模块相互独立，彼此互不干扰。

综上所述的，本发明相比现有技术如下优点：

本发明提出一种适用于电力业务的事件驱动型消息交互方法，该方法提出一种以事件驱动为特征的将抽象业务具体化的范式，该范式涵盖事件单播、事件广播、任务协作三种模式，该方法侧重于整合离散分布在只能终端、边缘物联代理装置上的流程应用，将其提供的物联网服务内聚为业务流程任务节点，最终实现将电力物联网设备作为业务流程资源在流程元素库中显示，并在流程执行阶段由流程执行引擎进行完全解析，而且有效解决大规模、分布式传感器、电力智能终端与业务数据流直接映射与交互的问题。

附图说明

图1是本发明的智慧物联体系总体架构示意图。

图2是本发明的物联管理平台、边缘物联代理/智能终端的建模示意图。

图3是服务描述模型示意图。

图4是事件管理器模型示意图。

图5是消息流连接不同泳池中业务流程对象示意图。

图6是事件创建业务流程示意图。

图7是流程执行引擎功能组件示意图。

图8是知识库、会话及流程实例示意图。

图9是具有多个输出控制流的任务节点的行为。

具体实施方式

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

实施例1

一种电力物联网的事件驱动型消息交互方法，首先对电力物联网的物联管理平台、边缘物联代理/智能终端中跨组织或部门的协作业务流程建模，而后定义业务流程资源模型的执行语义，然后提出流程执行引擎对业务模型的解析机制，最后实现微服务体系架构中的消息交互，从而实现消息交互。

边缘物联代理装置、智能终端为终端标准接入及边缘计算能力提升的通用设备，实现对业务终端的基于不同标准化接口的全业务泛在接入，支持业务敏捷部署和综合接入及智能处理。

本方法聚焦于为物联管理平台、边缘物联代理/智能终端，实现物联管理平台与边缘物联代理装置中电力业务流程的自动化建模，提出一种基于事件驱动型消息交互方法，该方法为通用方法，可实现与业务终端、业务系统的自协同。

跨组织或部门的协作业务流程建模

为实现物联管理平台、边缘物联代理/智能终端中，跨组织或部门的协作业务流程建模，首先构建全生命周期服务管理模型，定义业务流程应用程序服务外部接口，其次，定义业务流程应用程序的内部组件，包括服务事件管理器、服务状态管理器(含服务替换管理器)，最后，明确采用流程协作图的方式将业务服务进行连接，通过控制业务节点形成整个业务流程。

1)全生命周期服务管理模型

为对电力物联网环境下事件驱动的多流程交互系统进行有效的管理，本发明从业务流程设计人员的角度出发，设计了这个完整的生命周期服务管理模型，以便用户可以通过简单的api对业务模块进行集成。一个业务流程应用通过标准化的接口对外提供服务。

服务包含以下的属性：服务名称、接口类型和统一资源标识。首先，服务描述通过服务处理程序实现，并生成服务定义文件。然后，使用服务定义文件描述业务流程应用程序服务和调用服务的输入/输出参数。这种设计的最终目标是允许多个服务共享一组统一的接口，然后生成一个服务描述文件。

2)服务事件管理器

在电力物联网敏感的业务流程应用中，事件居于核心位置，它对服务的发现有着极其重要的作用。本发明设计了事件管理器作为业务流程应用服务程序之间的通信基础。此外，这些智能终端服务被映射到发布订阅网络上实现分布式地执行。当智能终端感知到所处的物联网环境发生变化时，它就会以服务发布者的身份将结构化的信息发送到事件管理器。本发明采用轻量级目录访问协议来对事件主题进行管理。服务订阅者通过ldap订阅感兴趣的事件主题。

此外，由于海量的感知事件需要在异构的传感器网络中进行转发、路由和处理，这对网络性能是一种挑战。因此，事件管理器通过基于拥塞控制的方法来确保网络性能。每一个智能终端上部署的业务流程都维持了事件缓冲队列，用变量u表示这个缓冲队列，u的值域是0到1，表示缓冲队列占用百分比。为了使u得值尽可能真实地反映网络性能的真实情况。使用变量f表示这个缓冲队列的瞬时占用率。此外，本文以固定的频率对f进行取值，并根据公式unew＝a·uold+(1-a)f对u的值进行更新，常数a表示u的更新速率。当u的值超过一个预设的阈值时，缓冲队列进入“预警”状态。此时，事件管理器将抑制从发布订阅系统订阅事件的速率。在最坏的情况下，也就是说缓冲队列被完全占用时，事件管理器将会根据优先级顺序对某些事件进行摒弃处理。

3)服务状态管理器

为了实现业务流程应用程序服务的透明执行，设计服务状态管理器来对服务进行监控和管理，具体流程如下：

每个参与协作的智能终端向服务状态管理器定期发送心跳事件，以显示其活动性。

当智能终端在给时域内无法发送心跳事件，服务状态管理器会通过将包含设备id的事件发布到服务事件管理器来报告其不可用性。

挂起业务流程应用程序服务，方法是将其设置为等待状态，直到替换失败的服务。

服务事件管理器收到此事件，它将向服务替换管理器发布一个命令，使其替换不可用的服务。服务替换的基本目标是发现可替换的服务，从而替换不可用的服务。

服务替换管理器请求服务描述文件来获取可用的候选服务列表。然后，服务替换管理器搜索定义文件与不可用服务匹配的服务。一旦检测出候选服务，服务替换管理器将随机选择其中可以替换不可用服务的一个服务。

服务替换管理器用新的业务流程实例替换旧的业务流程实例，并修改服务描述文件。服务替换过程中的核心任务是确保状态同步，这意味着一个服务必须从其被挂起的安全点恢复执行。

服务状态管理器会定期对终端状态进行检查，对业务流程应用程序服务的状态进行持久化，当服务替换完成时，业务流程应用程序将恢复运行。

4)业务流程建模

采用协作图来描述跨组织或部门的流程间的交互逻辑。协作图通常包含两个或两个以上的泳池，用它们来表示协作流程图中不同参与者之间的消息交互，是通过使用消息流连接不同的泳池，有时连接的是泳池中具体的流程元素对象。泳池是协作图中业务流程参与者的活动容器，业务流程的参与主体可以是公司、部门或者是单独的个体，其定义包含在partnerrole类中。泳池可以是空白的，或者partnerrole是对用户“透明”的，标识泳池并不总是包含可执行的业务流程。为了使流程图清晰，泳池可以水平或垂直方向进行扩展。泳池的基本功能是为业务流程任务节点之间控制流的执行提供一个容器。控制流可以跨越泳池中泳道的边界，但是不能跨越泳池的边界。

单独的业务流程是完全包含在泳池内，归属于不同泳池的业务流程只有通过消息流才可以进行连接。图3给出这种通过消息流连接不同泳池中对象的方式。

(2)业务流程资源模型的执行语义

为了明确业务流程应用程序服务的外部接口，在服务描述模块构建业务流程资源模型的执行语义，确保保证对业务流程模型中元素对象清晰而准确的理解。

对于某些元素对象，目前的物模型建模规范只提供概念模型，而该模型的相关信息并不能在流程执行引擎中得到完全的解析，这种不可操作元素对象，可以手动编写供流程执行引擎解析的代码。

业务流程在其内部的启动事件触发时被实例化，除非启动事件参与包含其他启动事件的会话，否则每次启动事件都会创建新的流程实例。如果该流程实例中的起动事件与创建流程实例的启动事件共享相关的信息，那么后续的启动事件将会被路由到该流程实例。含有全局流程变量的业务流程不能包含空的启动事件，也不能有无输入控制流的网关或活动，事件网关除外。

为了方便业务流程设计人员对控制流进行定义，采用令牌描述正在执行的流程的行为，令牌将“遍历”处于控制流中的元素对象。流程元素的行为可以通过描述它们在“遍历”流程控制流时如何与令牌交互来定义。通常情况下，基于建模规范的建模器或建模工具不需要实现任何形式的令牌。如果activity没有输入的控制流，那么它将在子流程得到实例化时进行实例化操作。activity也可以是控制流的来源，如activity有多条输出的控制流，那么当其状态变为“完成”时，每一条输出的控制流都将获得一个token。有条件和无条件的多个输出控制流的混合被认为是并行和包含拆分的组合，如图9所示。

如果activity没有任何的输出控制流，那么该activity将在不生成任何token的情况下完成，然后其相应的执行语义也将被终止。token在控制流中的流转没有时间的限制，与流程实例具有相同的生命周期。对于具体的业务流程，流程的执行语义体现在各个具体的任务节点中。事件类型的流程执行引擎的执行语义有：

启动事件：当单独的启动事件触发时，业务流程执行引擎会创建一个新的流程实例，然后执行后续的控制流。

中间事件：流程执行引擎等待特定的事件到达后继续流程的流转。等待时间是从中间事件到达时开始计算的。一旦目标事件到达，马上消除流程，然后执行后续的控制流。

边界事件：对于边界事件，有同步和异步两种处理方式。如果是同步的处理方式，与中间事件一样，流程执行引擎需要等待特定的事件到达来继续流程的流转，如果流程执行引擎一直没有捕获目标事件，那么流程将一直处于挂起状态；如果是异步的处理方式，流程执行引擎会将当前的任务节点执行挂起操作，然后继续执行后续的控制流，而不用一直等待目标事件。

终止事件：终止事件有正常终止事件和异常终止事件两种类型。不论是哪种类型的终止事件，流程执行引擎都会终止与该事件相关联的各种行为。如果一个流程中的所有任务节点都得到了响应，进一步来说也就是，所有的启动事件都己经被触发，所有的控制流都得到执行，且流程实例中不再包含任何一个token，那么这个业务流程将被正常终止，否则其将被异常终止。

(3)流程执行引擎对业务模型的解析机制

流程执行引擎允许用户通过描述要实现目标、需要执行的步骤来对业务目标进行建模，并且使用图形化的方式描述业务流程模型。流程执行引擎关注可执行的业务流程，这些业务流程包含足够的细节，因此它们实际上可以在任何遵循建模规范的容器中执行，所涉及的组件如下：

本发明以jbpm为基础工具，对业务流程执行引擎中的核心api介绍。在启动业务流程时，流程执行引擎会建立会话，这个会话的生命周期与流程实例的生命周期一样。会话需要对知识库进行引用，知识库中包含了所有与业务流程定义相关的信息，通过知识库，业务流程设计人员可以随时查看所需的流程信息。在创建会话时，我们需要首先创建知识库，加载所有必要的业务流程定义信息，这些流程定义信息可以来自于环境变量、iot系统、或者是流程仓库，然后流程执行引擎就可以实例化一个业务流程。

知识库通常情况下只需被创建一次，且能同时被多个会话所共享。值得注意的是，知识库可以被业务人员动态地修改，这也就意味着在业务流程执行阶段，业务人员可以添加或者删除流程实例。在具体的应用场景中，业务人员可以根据需求来创建任意多个会话。图8描述了知识库、会话及流程实例间的关系。

在jbpm的核心api中，会话提供了对事件进行侦听的功能。通过会话，注册或者删除事件侦听器。事件侦听器内嵌在业务流程的执行引擎中，通过控制业务流程任务节点的启动或停止，实现对业务流程实例运行状态的侦听。事件对象提供对业务流程相关信息的访问权限，业务人员通过流程事件侦听器这个api来创建自己的事件侦听器。在使用事件侦听器api时，这些事件可以被认为是一个堆桟，也就是说，事件的发生必然是它之前事件执行产生的结果，也必然会对它之后的事件产生影响。

(4)微服务体系架构中的消息交互

本发明采用基于事件的资源模型，将系统的不同功能模块通过预定义好的接口联接。本发明将提出新的面向资源的建模规范，作为对bpmn2.0规范的扩展。在业务流程层集成智能终端设备时，面临两个主要挑战。首先，智能终端设备作为特殊类型的业务流程资源不能在基本元素库中直接使用。其次，流程执行引擎无法在业务流程管理环境中以未知的json格式来直接解析与智能终端相关的服务。现有bpmn2.0规范不能在同一个业务流程模型的不同级别上同时考虑这两个问题。本发明在bpmn2.0规范现有的基础上扩展了机器可读模型。

尽管bpmn2.0规范己经支持在活动级别对物联网环境下的资源进行分配，但它仍无法在业务流程引擎中以未知的json格式来直接解析与智能终端相关的服务。为了解决该问题，首先引入一个活动(activity)类的子类，并将物联网环境下的实体设备资源分配直接引入到活动的级别。智能终端设备类(sensordevice)继承了活动类的模型关联和属性。通过配置相关参数，智能终端的相关信息将被整合生成json文档，并被传递到流程的执行阶段。

在这种情况下，流程执行引擎可以在运行时找到可用的物联网设备类。然而，智能终端设备类的定义是抽象的，因为它只能定义资源的类型，而不详细说明如何引用实体资源。因此，我们设计了接口(interface)类来实现智能终端抽象类。接口类继承了baseelement的模型关联和属性，并为智能终端服务(sensorsevice)类留下标准化接口。

所有业务流程元素都包含json结构定义中的id，并通过这些id对业务流程元素实现引用。json支持按id引用和按名称(qname)引用。qname由两部分组成：可选的名称空间前缀和本地部分。当用于引用bpmn2.0元素时，本地部分应该是流程元素的id。

表1给出了接口类的附加属性和模型关联，表2中描述了相应的json模式定义规范。智能终端的基本功能是感知周围环境并将异构的感知数据发送到物联管理平台。但是，每个智能终端都有其特定的功能和数据格式。例如，温度传感器采集文本格式数据，红外成像传感器采集图像格式，监视器传感器采集视频格式数据。为了更好地在流程引擎中解析它们，将原始数据封装为统一的消息格式.

表1接口类的附加属性和模型关联

表2json模式定义规范

本实施例未述部分与现有技术相同。