CN109343834A - 面向无中心建筑智能化系统的编程模型 - Google Patents

Abstract

本发明涉及一种面向无中心建筑智能化系统的编程模型，该模型结合无中心建筑智能化系统架构的特征，定义了建筑单元、社区编程抽象。其中，建筑单元是无中心系统中参与建筑应用任务的建筑实体单元的软件抽象，用来描述建筑实体单元的本地应用任务；而社区是功能上相互关联、共同参与某项网络计算任务的建筑单元集合的软件抽象，用来描述网络计算任务。其次，该模型采用事件触发机制、基于活动的执行机制、社区交互机制，使得建筑应用软件能够适应网络拓扑和节点数目的变化，在降低无中心建筑智能化系统网络编程复杂性的同时，具有较高的可移植性和健壮性，能够满足无中心建筑智能化系统的编程要求。

Description

面向无中心建筑智能化系统的编程模型

技术领域

本发明涉及一种用于扁平化分布式系统的编程模型技术领域，尤其涉及一种面向无中心建筑智能化系统的编程模型。

背景技术

无中心建筑智能化系统(简称无中心系统)是一个由基于空间分布、地位平等的无中心计算节点(Computing Process Node，CPN)连接而成的并行计算网络系统。它将建筑按照空间分布和功能特性划分成多个建筑单元，包括基本空间单元和各类机电设备单元，每个建筑单元由一个CPN来负责管理。并在CPN中内置了一套的建筑标准化数据集(简称标准数据集)，它涵盖了建筑运行中所需要的各类信息，对外开放，并希望成为行业标准。与传统的集散控制系统(Distributed Control System，DCS)或现场总线控制系统(FieldControl System，FCS)相比较，这种扁平化、分布式的系统架构解决了现场配置工作量大、易出错、升级改造困难、跨系统信息共享难以实现等难题。

无中心系统改变了传统建筑智能化系统的开发方式，要求建筑应用软件具有较高的可移植性和健壮性，从而实现将软件开发和建筑系统组态相分离。为此，编程模型应该满足如下要求：

1)要满足“建筑设备控制管理间歇性”的需求。建筑智能化系统中建筑设备的运行管理具有周期性或者人为主观因素的偶然性。传统建筑智能化系统的解决方案依赖于定时器和其他硬件中断的响应式编程(Reactive Programming)。而在无中心系统中，开发人员直接面向标准数据集，无法对CPN硬件进行控制管理。因此，需要在编程模型层面引入相应的机制来满足响应式编程的需求。

2)要满足“建筑单元类型多样性”的需求。在无中心系统中，一项建筑应用任务可能会涉及多种类型的建筑单元，且同种类型的建筑单元一般具有平等的地位、执行相同的程序，而不同类型的建筑单元则差异性较大，需要一种合理的任务组织方式来为此特性提供支撑，从而降低编程的复杂性。

3)要满足“应用软件与网络结构无关性”的需求。不同建筑的无中心系统网络拓扑、节点数量和节点地址各不相同。编程模型需要让建筑应用软件能够适应各种复杂的网络结构。

4)要满足“网络计算任务执行域边界性”的需求。无中心系统中的网络计算任务通常具有“边界性”，即一项网络计算任务只需要部分建筑单元参与，需要在编程模型层面提供灵活的执行域定义方法，以圈定网络计算任务的执行范围。

然而，传统的编程方式(如C语言)主要面向单指令流和内存共享式的计算机，无法满足无中心系统网络并行编程的需求。在分布式内存并行计算机和集群网络中有着广泛应用的消息传递模型MPI(Message Passing Interface)，由于需要显示指定通信地址，程序的可移植性和健壮性不高，无法满足无中心系统应用软件开发与建筑系统组态相分离的要求。此外，一些面向无线传感器网络和多Agent系统的编程模型，虽然对网络并行编程和“无地址交互”提出了不同的解决方案，但是由于领域之间固有的鸿沟，这些方法也不能直接为无中心系统编程提供有效的支持。

发明内容

基于背景技术存在的技术问题，本发明提出一种符合无中心建筑智能化系统编程特点的编程模型，使其能够提高无中心建筑应用软件的可移植性和健壮性，降低编程的复杂度。

一种面向无中心建筑智能化系统的编程模型，该模型包括建筑单元和社区及其动态运行机制；

所述建筑单元是无中心系统中参与建筑应用任务的建筑实体单元的软件抽象，用来描述建筑实体单元的本地应用任务；

所述社区是功能上相互关联、共同参与某项网络计算任务的建筑单元集合的软件抽象，用来描述需要多个建筑实体单元参与的网络计算任务；

所述动态运行机制主要包括事件触发机制、基于活动的执行机制和社区交互机制。

优选的，在一个建筑应用软件(APP)中可定义多个建筑单元和社区，所述建筑单元和所述社区之间是多对多关系，一个所述建筑单元可以加入多个所述社区，一个所述社区可以存在多种不同类型的所述建筑单元。

优选的，所述建筑单元由建筑单元名称、约束、标准数据、共享变量、事件和本地活动构成；

建筑单元名称：由开发人员指定，作为不同类型建筑单元之间区分彼此的标识，在APP中具有唯一性；

约束：为准确描述建筑单元而定义的一系列约束条件，用来作为所述建筑单元的激活条件；

标准数据：对标准数据集中的数据所进行的引用声明；

共享变量：作用域是整个建筑单元的变量，用于本地活动之间通信；

事件：由开发人员定义的本地活动触发条件，可以用来实现对标准数据、共享变量等信息的监测；

本地活动：包含本地操作且功能相对独立的程序模块。

优选的，所述社区由社区名称、社区定义规则、建筑单元属性、交互变量、事件、交互活动构成；

社区名称：由开发人员指定，作为不同的社区之间区分彼此的标识，在APP中具有唯一性；

社区定义规则：指定参加社区的节点所要满足的约束条件，需要指定建筑单元类型集合T、建筑单元之间耦合关系R和虚拟号V；

建筑单元属性：是社区中的隐含属性，不需要在社区中显式地定义或声明，加入社区的建筑单元中的标准数据和共享变量可以直接在社区中使用；

交互变量：用于建筑单元通信的专用变量，每个交互变量存储着本节点和相邻节点的数据值；

交互活动：是建筑单元参与某项网络计算任务时所执行的程序模块，社区中的所有建筑单元通过执行相同的交互活动来共同完成一项网络计算任务；

事件：由开发人员定义的交互活动触发条件，可以用来实现对标准数据、共享变量等信息的监测。

优选的，所述事件触发机制包括如下步骤：

S1：用户将活动感兴趣的数据信息封装成事件，并将其注册到TOS操作系统的事件队列中；

S2：TOS操作系统对事件进行统一管理，并根据事件需求实时地侦听标准数据集中的数据状态；

S3：当TOS查询到事件发生时，将事件发布给活动，激活其处理程序。

优选的，所述基于活动的执行机制中本地活动和交互活动都能够以事件触发的方式激活；本地活动之间或者本地活动与交互活动之间支持以控制依赖关系来明确控制流。

优选的，本地活动与交互活动之间支持抢占式控制依赖关系，本地活动在执行的过程中可以激活交互活动，当前本地活动会被阻塞，直到交互活动执行完毕。

优选的，交互活动可以被其他节点发送的社区生成消息所激活，发起节点的交互活动执行完毕后会跳转至本地活动，而非发起节点的交互活动执行完后会直接结束。

优选的，所述社区交互机制主要包括三个阶段：

初始化阶段：用于生成社区有向树，并确定每个节点的邻域关系；

交互阶段：本质上是一个循环体，每一次循环都要与相邻节点进行交互，直到满足终止条件为止，节点间传递消息通过交互变量来完成；

结果处理阶段：对交互阶段的计算结果作进一步的处理。

优选的，所述社区有向树的生成步骤如下：

S1：网络计算任务的发起节点激活交互活动，向其他节点发送社区生成消息；

S2：安装相同APP的节点收到消息后，激活自身的交互活动；

S3：根据社区定义规则判断是否加入该社区；

S4：加入社区的每个节点都会保留相邻社区节点的编号，并继续向其他节点转发社区生成消息；

S5：通过社区生成消息在网络中的扩散，最终生成一个社区有向树

与现有技术相比，本发明具有的有益效果在于：

本发明提出一种面向无中心建筑智能化系统的编程模型，“建筑单元”、“社区”编程抽象更加符合领域专家的思维习惯，弥补了应用软件与底层体系结构之间的鸿沟，降低了编程难度；基于事件触发的运行机制满足了建筑设备间歇性控制管理的需求；基于社区交互的运行机制使得网络任务的分配和节点间的通信与节点数量和节点通信地址解耦，实现了将软件开发和建筑系统组态相分离，大大提高了无中心系统应用软件要具有较高的可移植性和健壮性。

附图说明

附图用来提供对本发明的进一步理解，并且构成说明书的一部分，与本发明的实施例一起用于解释本发明，并不构成对本发明的限制。在附图中：

图1是本发明提出的无中心建筑智能化系统编程模型示意图；

图2是本发明中编程抽象建筑单元结构图；

图3是本发明中编程抽象社区结构图；

图4是本发明中事件触发机制示意图；

图5是本发明中基于活动的执行机制示例图；

图6是本发明中社区交互机制示意图；

图7是基于无中心平台的变风量系统示意图；

图8是本发明应用于变风量系统的APP编程框架；

图9是本发明应用于变风量系统的APP控制流分析图。

具体实施方式

下面结合具体实施例对本发明作进一步解说。

实施例1

如图1所示，本发明公开的编程模型定义了“建筑单元”和“社区”等领域概念，并作为一阶实体来构造和实现无中心系统的建筑应用软件。“建筑单元”是无中心系统中参与建筑应用任务的建筑实体单元的软件抽象，用来描述建筑实体单元的本地应用任务；“社区”是功能上相互关联、共同参与某项网络计算任务的建筑单元集合的软件抽象，用来描述需要多个建筑实体单元参与的网络计算任务。其次，该编程模型采用了事件触发机制、基于活动的执行机制和交互机制。事件触发机制主要关注如何通过响应式的运行机制来满足了“建筑设备控制管理间歇性”的编程需求；执行机制主要关注APP在单个节点中是如何依托活动来完成各项复杂的功能；交互机制则主要关注多个节点之间是如何通过交互行为来完成网络计算任务。

如图2所示，“建筑单元”由“建筑单元名称”、“约束”、“标准数据”、“共享变量”、“事件”和“本地活动”等成分构成。其中，“本地活动”是“建筑单元”的动态行为，其他则为“建筑单元”的静态属性，且允许“共享变量”、“事件”和“本地活动”设置为空。下面分别对各成分进行阐述：

1)“建筑单元名称”由开发人员指定，作为不同类型“建筑单元”之间区分彼此的标识，在APP中具有“唯一性”。

2)“约束”是为了准确描述建筑实体单元而定义的一系列约束条件。“建筑单元”只有在“约束”与建筑实体单元的特征信息相匹配的情况下才会被激活。例如，将约束条件设置为“θ！＝NULL”，表示标准数据集中存在VAV BOX阀门开度θ的实时数据，因此，它只有在安装了VAV BOX的建筑空间单元中才会被激活。

3)“标准数据”一栏是用于对所需要访问的标准数据进行引用声明，也就是说“建筑单元”只能访问被声明过的标准数据。

4)“共享变量”作用域是整个“建筑单元”，可以被“建筑单元”中的“本地活动”共享，因此，它可以用于“本地活动”之间的通信。为了保证访问的安全性，规定其读写操作具有“同步性”，即同一时刻只能允许一个“本地活动”进行访问。

5)“事件”是由开发人员根据实际功能需求定义的活动(包括“本地活动”和“交互活动”)执行的触发条件，可以用来实现对标准数据、共享变量等信息的监测。例如，“建筑单元”将“TR>35”定义为“事件”后(TR为空气温度值)，当空气温度值高于35℃时，会立即发布给该“建筑单元”并触发相应的“本地活动”。

6)“本地活动”是包含一系列本地操作且功能相对独立的程序模块，可以被时间或其他特定事件触发执行，也可以按照控制依赖关系有序地执行。“本地活动”是建筑单元的个体行为，不涉及复杂的交互行为。“本地活动”在“建筑单元”中可能存在一个或多个，也可能不存在，后者表示“建筑单元”仅参加“社区”的网络计算任务。

如图3所示，“社区”由“社区名称”、“社区定义规则”、“建筑单元属性”、“交互变量”、“事件”、“交互活动”构成。下面分别对各成分进行阐述：

1)“社区名称”由开发人员指定，作为不同的社区之间区分彼此的标识，在APP中具有“唯一性”。

2)“社区定义规则”是形式化描述社区的方法，具有“无歧义性”，能够准确地圈定网络计算任务的执行范围，从而满足“网络计算任务边界性”的要求。具体而言，“社区定义规则”将社区表示为三元组：

Community＝<T,R,V>.

·T表示建筑单元类型的集合。在无中心系统中，相同类型的建筑单元通常作为网络计算任务执行域的基本单元，因此，将T作为描述社区的重要元素，通过指定T可以将不同类型的建筑单元区分开。

·R表示建筑单元之间的耦合关系。社区不仅仅是满足类型要求的建筑单元的简单集合，正如第1节“网络计算任务执行域的边界性”所分析的那样，在同一社区中的建筑单元之间往往具有较强的物理耦合关系(例如由同一风管网相连接的几个房间单元)，而不同社区的建筑单元则耦合关系较弱。因此，在定义社区时需要指定建筑单元之间的耦合关系。

·V是用户定义的虚拟号。在面向一些具有较强人为因素的应用中(例如统计特定几间办公室耗能)，社区成员的组成具有较强的随机性。因此，社区定义时引入了虚拟号，虚拟号相同的建筑单元会组成一个社区，虚拟号的值不是有由开发人员指定，而是由工程人员现场指定。

3)“建筑单元属性”是社区中的“隐含属性”，即不需要在社区中显式地定义或声明。当“建筑单元”加入社区后，“建筑单元”中的“标准数据”和“共享变量”可以直接在社区中使用。

4)“交互变量”专用于建筑单元之间的通信。每个交互变量实质上是一个一维数组，交互变量I，数组的第一位I0存储着本节点的变量数值，I1-Im存储着m个相邻节点的变量值。

5)社区中的“事件”主要是“交互活动”的触发条件，使用前需要事先在社区中进行定义。

6)“交互活动”是“建筑单元”参与某项网络计算任务时所执行的程序模块，社区中的所有“建筑单元”通过执行相同的“交互活动”来共同完成一项网络计算任务。建筑单元在执行“交互活动”时往往会不断地与其他的建筑单元交互信息，直到满足结束条件为止；

如图4所示“事件触发机制”的机理，用户将活动感兴趣的数据信息封装成事件，并将其注册到TOS操作系统的事件队列中；TOS操作系统对事件进行统一管理，并根据事件需求实时地侦听标准数据集中的数据状态；当TOS查询到事件发生时，将事件发布给活动，激活其处理程序。

“基于活动的执行机制”主要依托本地活动和交互活动来实现建筑应用任务，下面结合图5所给的执行示例，对编程模型的执行机制进行介绍：

本地活动和交互活动都能够以事件触发的方式激活，如本地活动b和交互活动B。本地活动之间或者本地活动与交互活动之间能够以控制依赖关系的方式相互关联，从而明确它们之间的控制流。例如，当活动a执行完毕后会通过分支关系同时激活活动d和活动c；此后又通过合并依赖关系，待d和c执行完成后激活活动e。在NCpro中，活动的并发是以隐式的方式实现的，即不存在控制依赖关系且满足自身执行条件的活动，可以同时执行，如活动d和活动c。

本地活动与交互活动之间支持“抢占式”控制依赖关系，即当本地活动在执行的过程中可以激活相应的交互活动，从而来发起一项网络计算任务。此时，当前的本地活动会被一直阻塞到交互活动执行完毕。例如，当本地活动b执行到抢占点时，会被阻塞并激活交互活动A，待到交互活动A执行完毕后，又会返回抢占点继续执行本地活动b。与本地活动不同的是，交互活动除了可以被本地活动和事件激活外，还可以被其他节点发送的“社区生成消息”所激活。此时，节点不是网络计算任务的发起节点，交互活动执行完后会直接结束(如图中虚线箭头所指示的执行路径)。

如图6所示，“社区交互机制”包括三个阶段：初始化阶段主要的任务是生成“社区有向树”。图6中CPN1(网络计算任务的发起节点)激活交互活动A后，在初始化阶段会向其他节点发送“社区生成消息”。安装相同APP的节点收到消息后，会激活自身的交互活动A，并在初始化阶段根据“社区定义规则”判断是否加入该社区。通过“社区生成消息”在网络中的扩散，最终会生成一个“社区有向树”，有向树中的每个节点都会保留与自己相邻节点的编号。

交互阶段本质上是一个循环体，每一次循环都要与相邻节点进行交互，直到满足终止条件为止。此部分是网络计算的主体。节点间传递消息是通过交互变量来完成的，以交互变量I为例，每次对I0进行写操作时，都会将其隐式地发送给相邻节点，以更新邻居节点中的变量值。交互变量的数组长度不是由编程人员指定，而是根据社区有向树中邻居节点的数量来动态确定。

在结果处理阶段，可以对交互阶段的计算结果作进一步的处理(例如修改标准数据集中设备的设定值)，此阶段不再涉及与其他节点的交互行为。

实施例2

图7给出了无中心系统中典型的应用案例—变风量空调系统，其中，空气处理机组(AHU)内置了专有CPN，负责对AHU内部可控装置进行调节；末端可调节装置(VAVBOX)由所在房间中的CPN进行管理；CPN之间通过有线连接成网络。变风量系统的控制策略如下：

1)感知需求负荷的变化。当某个房间感知到需求负荷发生变化时，根据标准数据集中的相关信息(温度设定值T_s、档位设定值G_s、温度测量值T_R等)计算出自身需求风量Q。

2)求解各房间的风阀开度。发起网络计算任务(执行域是风管网所连接的所有房间)，各房间通过不断与相邻房间交互需求风量Q_i和风阀阻抗S_i，反复迭代求解，S_i最终会趋于稳定值(即目标解)；各房间根据求解出的S_i来更新自身的阀门开度θ_i。

3)计算系统总风量需求。AHU定时发起网络计算任务(执行域是整个变风量系统)，通过执行网络求和操作计算出系统总风量需求Q_sum。

4)调节风机转速。AHU根据系统总风量需求Q_sum和风机频率特性曲线来控制风机转速F_S。

如图8所示，APP中包含V-box和AHU两类“建筑单元”，分别对应着末端房间和空气处理机组；同时，根据“计算风阀开度”和“计算总的需求风量”两个网络计算任务执行域的特点，分别定义了社区A和社区B。定义社区A时，建筑单元类型T(即T::V-box)表示社区中的建筑单元的类型是“V-box建筑单元”，即安装有BOX的建筑空间单元；建筑单元之间的耦合关系R(即R::CONTO Duct)表示“建筑单元连接着同一个风管”。同理，社区B圈定的范围是“由同一个风管所连接的所有安装BOX的建筑空间单元和AHU建筑设备单元”。

在“V-box建筑单元”中，事件1可以实现对温度设定值T_s、VAV BOX档位设定值G_s和温度测量值T_r的监测；本地活动a主要的功能是通过T_s、G_s、T_r来求取房间的需求风量Q，即：Q＝f₁(T_s,G_s,T_r)。在建筑单元AHU中，事件2(Timer＝10min)为时间触发事件，触发周期为10分钟；本地活动c的主要功能是通过末端房间总的需求风量Q_sum和风机的性能曲线(其中C_x和C_y为风机性能曲线参数)来调节风机转速F_s，即F_s＝f₂(Q_sum,C_x,C_y)。

交互活动A和交互活动B分别用来完成“计算风阀开度”和“计算总的需求风量”两个网络计算任务。交互活动A与社区A绑定，并在“交互阶段”基于交互变量(风阀阻抗X_S和需求风量X_Q)完成了与相邻节点的迭代计算，从而求解出风阀阻抗X_S的目标解，即：X_S＝f₃(Q,X_S[i],X_Q[i])(其中X_S[i]和X_Q[i]分别表示邻居的风阀阻抗和需求风量)。各房间根据自身所求得的风阀阻抗重新调节风阀开度Op，即：Op＝f₄(X_S)。交互活动B与社区B绑定，并通过网络求和算子(SUM()函数)完成对需求总风量Q_sum的求解。

如图9所示，在运行阶段，APP执行流：(1)假设房间b人为调整了温度设定值，事件1触发本地活动a，从而计算出房间b的需求风量；待本地活动a执行完毕后，交互活动A被激活，并发起“计算风阀开度”的网络任务，并向外广播“社区A的生成消息”。房间a和房间c在收到消息后，自身的交互活动A被激活；由于三个房间都满足社区A的定义规则，最终会生成由三个房间所组成的社区A计算网络，并通过交互风阀阻抗X_S和需求风量X_Q共同完成“计算风阀开度”的网络计算任务。(2)同理，在AHU中，事件2的触发周期为10分钟，每次时间到达后，会触发AHU的本地活动c；在本地活动c执行过程中会发起“计算总的需求风量”的网络计算任务，并依次激活各建筑单元APP中的交互活动B；AHU的交互活动B执行结束后会返回本地活动c，继续完成对风机转速的调节。

以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，根据本发明的技术方案及其发明构思加以等同替换或改变，都应涵盖在本发明的保护范围之内。

Claims (10)

1.一种面向无中心建筑智能化系统的编程模型，其特征在于，该模型包括建筑单元和社区及其动态运行机制；

所述建筑单元是无中心系统中参与建筑应用任务的建筑实体单元的软件抽象，用来描述建筑实体单元的本地应用任务；

所述社区是功能上相互关联、共同参与某项网络计算任务的建筑单元集合的软件抽象，用来描述需要多个建筑实体单元参与的网络计算任务；

所述动态运行机制主要包括事件触发机制、基于活动的执行机制和社区交互机制。

2.根据权利要求1所述的一种面向无中心建筑智能化系统的编程模型，其特征在于，该模型可定义多个建筑单元和社区，所述建筑单元和所述社区之间是多对多关系，一个所述建筑单元可以加入多个所述社区，一个所述社区可以存在多种不同类型的所述建筑单元。

3.根据权利要求1所述的一种面向无中心建筑智能化系统的编程模型，其特征在于，所述建筑单元包括：

建筑单元名称：由开发人员指定，用于区分不同类型的建筑单元且具有唯一性；

约束：为准确描述建筑单元而定义的一系列约束条件，用来作为所述建筑单元的激活条件；

标准数据：对标准数据集中的数据所进行的引用声明；

共享变量：作用域是整个建筑单元的变量，用于本地活动之间通信；

事件：由开发人员定义的本地活动触发条件，可以用来实现对标准数据、共享变量等信息的监测；

本地活动：包含本地操作且功能相对独立的程序模块。

4.根据权利要求1所述的一种面向无中心建筑智能化系统的编程模型，其特征在于，所述社区包括：

社区名称：由开发人员指定，用于区分不同的社区且具有唯一性；

社区定义规则：指定参加社区的节点所要满足的约束条件，需要指定建筑单元类型集合T、建筑单元之间耦合关系R和虚拟号V；

建筑单元属性：是社区中的隐含属性，不需要在社区中显式地定义或声明，加入社区的建筑单元中的标准数据和共享变量可以直接在社区中使用；

交互变量：用于建筑单元通信的专用变量，每个交互变量存储着本节点和相邻节点的数据值；

交互活动：是建筑单元参与某项网络计算任务时所执行的程序模块，社区中的所有建筑单元通过执行相同的交互活动来共同完成一项网络计算任务；

事件：由开发人员定义的交互活动触发条件，可以用来实现对标准数据、共享变量等信息的监测。

5.根据权利要求1所述的一种面向无中心建筑智能化系统的编程模型，其特征在于，所述事件触发机制包括如下步骤：

S1：用户将活动感兴趣的数据信息封装成事件，并将其注册到TOS操作系统的事件队列中；

S2：TOS操作系统对事件进行统一管理，并根据事件需求实时地侦听标准数据集中的数据状态；

S3：当TOS查询到事件发生时，将事件发布给活动，激活其处理程序。

6.根据权利要求1所述的一种面向无中心建筑智能化系统的编程模型，其特征在于，所述基于活动的执行机制中本地活动和交互活动都能够以事件触发的方式激活；本地活动之间或者本地活动与交互活动之间支持以控制依赖关系来明确控制流。

7.根据权利要求6所述的一种面向无中心建筑智能化系统的编程模型，其特征在于，本地活动与交互活动之间支持抢占式控制依赖关系，本地活动在执行的过程中可以激活交互活动，当前本地活动会被阻塞，直到交互活动执行完毕。

8.根据权利要求6所述的一种面向无中心建筑智能化系统的编程模型，其特征在于，交互活动可以被其他节点发送的社区生成消息所激活，发起节点的交互活动执行完毕后会跳转至本地活动，而非发起节点的交互活动执行完后会直接结束。

9.根据权利要求1所述的一种面向无中心建筑智能化系统的编程模型，其特征在于，所述社区交互机制主要包括三个阶段：

初始化阶段：用于生成社区有向树，并确定每个节点的邻域关系；

交互阶段：本质上是一个循环体，每一次循环都要与相邻节点进行交互，直到满足终止条件为止，节点间传递消息通过交互变量来完成；

结果处理阶段：对交互阶段的计算结果作进一步的处理。

10.权利要求9所述的一种面向无中心建筑智能化系统的编程模型，其特征在于，所述社区有向树的生成步骤如下：

S1：网络计算任务的发起节点激活交互活动，向其他节点发送社区生成消息；

S2：安装相同APP的节点收到消息后，激活自身的交互活动；

S3：根据社区定义规则判断是否加入该社区；

S4：加入社区的每个节点都会保留相邻社区节点的编号，并继续向其他节点转发社区生成消息；

S5：通过社区生成消息在网络中的扩散，最终生成一个社区有向树。