随着人力成本和能源成本的增加,自动化并且节能的建筑设备系统运维日益为建筑业主特别是大型公共建筑的管理者所重视。暖通空调是建筑中的用能“大户”,也是控制最复杂的机电系统。建筑自动化(或称建筑智能化系统)是实现建筑设备自动、节能运行的关键。近年来针对暖通空调控制和节能需求产生的专项应用,如制冷站群控、能耗分析管理、变风量控制等等,其实是建筑自动化系统本就应该实现的功能。

　　 建筑自动化并不是一项新的技术。早在20世纪90年代,我国就已在大型公共建筑中普遍设计安装了这一系统。伴随着信息技术的发展,建筑自动化技术也在不断迭代更新。在通信技术上,从20世纪90年代采用的工业总线技术,到为了打通各个信息孤岛而制定的标准协议BACnet,从成熟的无线通信技术如蓝牙、Zigbee等,到今天的热点新技术LoRa和NB-IoT,建筑自动化领域不断引进新的通信解决方案。在集成软件方面,从早期的OPC接口标准,到引进互联网技术经历从C/S架构到B/S架构的转变,再到引进“软件即服务”(SaaS)的理念,这一领域也紧跟软件工程领域的成果。在工程上,制定了一系列工程技术规范来指导和约束从设计到验收的各个环节 ^[1,2,3],并结合信息技术,设计了如组态王、Tridium等组网调试软件。如今,物联网、云计算、人工智能、大数据等热门技术也已经被应用在一些建筑节能优化控制项目上。

　　 然而,虽然建筑自动化紧跟信息领域的发展,并作出了若干精品项目,但是在相当多的实际项目中控制效果普遍并不尽如人意,许多项目中的自动化只不过是在中央机房内实现远程人工监控,能耗水平取决于运行人员的经验和责任心,远没有达到自动优化控制的设计目标 ^[4]。这背后技术层面的原因是什么?既然建筑自动化在各个局部技术环节的改进都不能最终解决问题,那么就有可能是系统整体架构上存在问题。

　　 图1给出了典型的建筑自动化系统架构。要实现控制,就要全面掌握被控系统的信息;而在传统架构中,现场控制器、子系统控制器和中央站之间的网络连接,反映的是通信或者控制层级之间的关系,被控机电设备系统的信息只能在各级控制器的软件中通过配置和建模来定义。这给实际工程实施带来了困难:首先,公共建筑尤其是大型公共建筑中设备众多,要在各级控制器软件上定义成百上千设备的信息和模型并保证没有错误,是一项耗时费力的工作;其次,在软件上定义设备系统模型,要求工程技术人员不仅要熟悉暖通空调领域的知识,还要具备信息技术领域的技能,这要求工程技术人员具备跨学科的专业能力;再次,各个项目具体采用的设备系统结构和组合方式都不同,自控工程师只能结合具体情况为每个项目进行定制化的开发。综上,现有的建筑自动化系统架构与被控系统脱节,需要跨专业的工程师为每个项目进行定制化开发,这必然导致系统建设成本高,周期长;在工程时间紧迫的情况下,难以保证质量。

　　 然而,如今的建筑自动化系统架构是从工业控制领域继承来的,在工业控制领域取得了成功并一直沿用至今。为什么同样的架构却不适合建筑自动化?这是由于建筑和工业控制在成本和灵活性上的要求大不相同。首先,工业控制系统帮助业主创造价值,而建筑自动化系统帮助业主节省成本,工业对控制系统建设阶段的成本没有建筑敏感;其次,工业控制系统的要求稳定,不会像建筑一样,随着租户、使用模式、室内装修、设备更换及运行管理团队的变化而不断调整,因此建筑对控制系统的灵活性要求高。在不断调整的需求下,如果每次调整都需要定制化开发的高成本投入,又不能在短期回收,建筑业主只有放弃建筑自动化系统。

　　 因此,传统的分级中央的架构并不适合建筑自动化系统,需要一种新的架构,能够大幅简化甚至取消定制化的配置建模工作;能够灵活地适应建筑控制管理需求的变化,使控制逻辑灵活快捷地搭载到控制系统;能够打破信息技术与暖通等机电专业的门槛,让真正懂机电和节能的暖通专业实现其节能控制逻辑。

　　 本文第1章从建筑及其机电设备控制需求的角度讨论新型建筑自动化系统的可能性,第2章介绍这种新系统的软硬件组成和关键技术,第3章讨论群智能给建筑自动化行业可能带来的改变,第4章介绍新系统在暖通控制领域的典型应用,第5章是总结。

　　 必须在中央对整个系统进行清晰地定义,是这种分级中央架构的特点,也是它给工程应用设置的门槛。要绕过这一定义过程,就必须改变这种架构。自然界中还有另一种智能系统,像蜜蜂、蚂蚁等昆虫群落,鸟群,鱼群,等等。这些群落中个体之间是平等的,不分层级的;在完成某项工作时,没有某些中央个体指挥调度其他个体,而是靠个体之间相对平等的自组织协作完成任务;个体离开或重新加入群体,不需要注册/注销机制,对整体任务的完成也几乎没有影响。平等、自组织、即插即用是这种群体智能的特点。用在建筑自动化领域,可以实现免配置、灵活组网的目标。近年来,随着信息技术的发展,在某个设备中嵌入芯片使该设备能够自我调节并与其他设备通信,已经是简单易行的事;在暖通空调领域,具备这样能力的制冷机、水泵、空气处理设备也屡见不鲜,这给群智能的实现提供了支撑。

　　 那么,能否用群智能的思路实现建筑自动化?这需要回答以下2个问题:1) 什么是建筑自动化的基本单元?这些基本单元应像上述群落中的个体一样,是标准化、在不同建筑中可复制的。2) 基本单元之间如何协作?这种协作能否做到平等、自组织、免配置、即插即用?

　　 建筑自动化系统架构的传统研究思路都是从工业控制或者互联网领域直接“拿来”成熟技术方案,但这样的架构缺乏针对建筑及其机电设备系统的思考;笔者尝试从建筑和机电设备系统的特点和需求出发,回答上面2个问题,重新定义建筑自动化。

　　 以往认为传感器、执行器、控制器是自动化系统的组成单元。但是,这些构件并不是建筑的组成部分,用它们作为基本单元组成建筑控制系统,并不能跨过对建筑系统定义这一门槛。我们希望基本单元能够尽可能多地反映建筑及其机电设备的属性,并且不失一般性,使得通过少数几类基本单元,就能完整地拼接建筑及其设备系统,并仅仅通过改变拼接方式,就能得到针对不同建筑项目的建筑自动化系统。

　　 换个视角去看建筑控制系统,如图2所示,可以认为建筑控制系统是由若干种空间单元和源设备单元拼接而成的。

　　 空间是构成建筑的基本单元。对应空间的控制子系统也可以看作是建筑自动化系统的基本单元,即空间单元。空间单元完成空间内所有机电设备的集成控制,包括空调末端、排风、照明、插座、门禁、电动窗或窗帘、火灾探测器等,为空间内用户营造舒适、健康、安全的环境,并保证设备安全节能运行。空间单元彼此按所在位置拼接就覆盖了大部分建筑区域,也即涵盖了大部分建筑机电设备的控制管理需求。空间单元是标准化、在不同建筑中可以复制的。典型空间的控制管理需求和信息内容的共性在不同建筑中大同小异。对于每种典型功能和尺度的建筑空间,空调末端、照明、插座、传感器等都存在某种设计“模数”,即在各种典型空间中的配置密度。因此,可以根据各类典型空间的功能和尺寸,确定其中各种机电设备的最大数量,进而将空间单元中的描述设备运维信息的种类和数量标准化,定义各类空间单元的标准信息集,也即这一类空间的控制系统信息模型。它们是作为建筑自动化系统基本元素的几种基本单元能拼接组成各种建筑的控制系统的基础。

　　 为空间提供各种电源、冷热源、水源、新风源的机电设备,是构成能源和输配系统的组成单元。对应每个设备的控制器(或控制系统)也是建筑自动化系统的基本单元,即源设备单元。与空间单元一样,首先,源设备单元完成设备内部的安全保护、自动调节、故障报警和能源计量等功能;其次,各类源设备单元也是标准化、在不同建筑系统中可以复制的。以制冷机为例,虽然提供设备的厂家不同,制冷原理可以不同,但是从建筑控制和运维的角度所关注的外特性参数是相同的。将所有制冷机用于控制和运维所需要的共性参数提炼出来,形成冷水机组的标准信息集,即制冷机的信息模型。在实际项目中,无论采用的是哪种原理的冷水机组,都用标准化的制冷机单元去对应,作为整体建筑自动化系统中对应冷水机组的相应组成部分。采用同样的方法,可以定义水泵(包括冷水泵、冷却水泵、一级泵、二级泵)、冷却塔、分集水器、空气处理设备(包括组合式空调机组、新风机组)等空调系统中源设备对应的基本单元。针对具体项目,将这些基本单元按照空调水系统或风系统的连接关系进行拼接,就得到了相应的建筑自动化系统。

　　 表1给出了按照上述思路提炼整理的建筑标准单元。通过对几十个实际项目进行模拟设计,已经初步验证用表1中20多种标准单元相互拼接完全可以覆盖这些项目的建筑和电机系统。对于日后可能出现的新型源设备形式,能用表1中某个基本单元对应的就用其对应;否则,也可以增加相应的标准单元定义。

　　 上述基本单元的定义,将机电系统单元与控制系统单元进行了对应。讨论基本单元的协作方式,仍然从被控系统的特点入手分析。在各种建筑机电系统中,控制调节的对象是制冷机、风机、水泵这些机电设备,但本质上是对建筑中的冷热量传递、气流传递、供水网络、人群移动、光和声音传递等这些物理过程进行调节。

　　 表2给出了各种物理过程的描述方程。分析这些物理过程可以发现,它们大部分都可以近似为空间上的二阶或一阶过程。这意味着,这些物理过程与空间位置相关,并且空间距离近时影响大,距离远时影响小。图3给出了火灾发生时烟气和温度的扩散过程。在火源区域烟气浓度和温度最高,在周边区域依次递减。在暖通领域,当某个房间的温度升高时,先向邻室传热,对其他空间的温度影响是逐渐传递过去的。在集中空调系统中,虽然冷水机组是集中冷源,但冷量向各个末端的输送方式并不是像通信网络的星形连接那样,由交换机分别连接各个末端,而是由一根总管按照空间位置由近及远地输送冷量。冷量一定是先到近处,再到远处的末端设备;且相连支路的相互影响最大。

　　 在建筑的各种物理场中,似乎只有变化的发起位置,而不需要某个特定的中心点;物理过程的演变是沿着空间位置关系由近及远发生的。基于这样的认识,上文定义的建筑基本单元,也即建筑控制系统的单元之间,只需要按照空间位置与邻近的单元协作。与邻近单元协作的过程模拟了物理过程由近及远的特点,因此可以不需要特别的控制中心,仅通过基本单元间的局部协作就有可能实现系统整体的优化调节。由于每个单元都与邻近的单元协作,整个系统就按空间位置连接成一整张网格状网络;同一时刻各个单元都在与邻近单元协作,因此这是一张并行计算网络。

　　 图4为按照上述分析建立的新型建筑自动化系统示意图。图中,空间单元、空气处理器单元、制冷机单元、水泵单元、冷却塔单元等,按照空间位置关系或水管网连接关系,与邻近的且只与邻近的基本单元连接;每个基本单元都与邻近节点协作控制,以完成系统整体的优化调节。建筑及其机电系统的模型被分散存储和处理:一方面,每个基本单元存储了自己的信息模型,即标准信息集;另一方面,由于系统网络拓扑与建筑平面或机电系统拓扑近似,虽然没有任何单元掌握全局网络结构,但每个单元都清楚掌握局部模型,具有与邻近单元协作的工作机制,这样通过各个单元的相互联系,也就间接地反映了整个系统的状况。

　　 基于上述分析,笔者提出了群智能建筑自动化系统,如图5所示。

　　 笔者开发研制的计算节点(computing processing node,CPN)是群智能建筑自动化系统的关键设备,也即构成并行计算网络骨架的硬件节点。CPN嵌入在各个建筑空间或源设备中,使它们能够成为智能基本单元。

　　 所谓智能包含以下功能:1) 实现基本单元内部的数据采集、安全保护、控制调节、故障诊断和报警、能耗计量等。2) 具备自动辨识和组网能力。一方面通过内置相应基本单元的标准信息集,辨识出自己,作为相应基本单元的“代理”,能够让系统中其他计算节点对应标准信息集找到本地环境与设备的运行参数,并能对设备发出设定指令;另一方面能够辨识区分出所在网络中的各个邻近节点,完成局部系统网络的识别。3) 具备与邻近节点协作计算的能力,从而能支持各种可能的全局控制管理策略。

　　 目前,制冷机、水泵、空气处理设备等源设备产品已经或正在逐步向智能机电设备转变。许多设备产品都已经开始内置控制器,完成设备内部的自动化控制调节。同时,智能传感器、智能执行器也不断完善。鉴于这一发展趋势,为了充分利用现有技术成果,CPN主要完成上述第二项和第三项功能。对第一项功能,CPN提供通信接口与源设备的本地控制器连接,从而能够对应标准数据集获取设备的运行状态,并可以对设备发出运行指令或设定值;而更底层的安全保护和本地调节等功能,由设备的本地控制器完成。当然,由于CPN可以获取设备的实时运行状态并可以对设备发出指令,在没有本地控制器的情况下,也可以利用CPN的计算能力完成部分基本单元内部的控制管理功能。

　　 CPN的结构示意图如图6所示,它提供2套接口。

　　 采用可以实现可靠、高速通信的通信技术保证相邻CPN之间彼此协作所需的高频率迭代计算。CPN不需要绝对通信地址。考虑到空间有上、下、左、右、前、后6个相对位置,每个CPN提供6个不同的接口来区分不同的邻居。

　　 CPN也提供若干种标准通信协议,用来与各种设备或传感器连接。

　　 第一套接口保证CPN之间连接成建筑的计算网络,如图5中间的三维网络所示。如果将整个计算网络视作一台整体多核计算机,那么第一套接口就可以看成是这台多核计算机内部的计算总线。第二套接口实现与建筑中各类实际机电设备的对接,如图5左侧空间单元和源设备单元所示。第二套接口可以看成是计算网络的对外接口,是开放的,采用常见的标准通信技术,并且可以根据具体需求和技术发展进行调整和更新。

　　 组网配置是常规系统架构在工程实施过程中的瓶颈。本质上是在自动化系统的各种软件上构建建筑系统的信息模型,用信息技术重新定义建筑及其机电系统设备。包括:定义与建筑环境和机电设备系统运行参数对应的变量;将变量与真实存在的传感器、执行器等物理设备的参数对接;描述参数与设备或空间的从属关系及其空间位置;描述空间或设备之间的拓扑连接关系,即机电设备系统结构;等等。这些内容在建筑空间和源设备不改变的情况下基本不变,与灵活多变的控制管理策略无关,是自动化系统的基础信息。群智能系统通过在CPN中植入对应建筑基本单元的标准信息集,以及CPN对邻近节点的自动辨识能力,完成上述组网配置工作,实现对建筑自动化系统的自动识别。

　　 建筑基本单元的标准信息集描述了同一类基本单元的共性参数。这些参数都是从系统整体控制和运行维护角度出发所需要关注的,与之无关的基本单元内部运行参数不在标准信息集内。某类建筑基本单元的标准信息集是其与整体控制和运维相关的参数的最大集合,与真实系统关联时,不必保证标准信息集中的每一个参数变量都有数据与之对应。此外,标准信息集规定了其中每个参数的具体描述方法,包括所对应变量的编号、变量的单位、变量的数值描述方法等。

　　 以办公室空间单元的标准信息集为例。通过办公室空间的共性归纳,标准信息集描述了一个30～80 m²典型办公空间的信息模型。在这样一个典型空间中,假设环境参数相对均匀,因此标准信息集中只设计了一套环境参数(包括空调温湿度、空气品质、照度等)的测量值和设定值变量;规定了办公室空间中照明回路、插座、空调末端、围护结构等空间内设备的最大数量,如表3所示;从运行状态参数、执行动作反馈值、设定值、能耗计量信息、故障和报警、额定和静态参数等角度分别规定了各个可能存在的空间内设备的相关变量,如表4所示;规定了上述所有变量在此标准信息集中的唯一编号及每个变量的数值描述方法,包括数值类型、单位、数值内容等,如表5所示。

　　 源设备单元的标准信息集与空间单元类似。只不过,整体控制和运维一般不关心机电设备内部各个部件的运行情况,而只关心外特性的共性参数,因此源设备单元的标准信息集一般将源设备作为一个整体,只描述其外特性参数。以制冷机单元的标准信息集为例,其中包含了描述制冷机运行状态参数、启停动作反馈值、相关设定值、能耗计量信息、故障和报警、额定参数和性能曲线等方面信息的各个变量,规定了各个变量在此标准信息集中的唯一编号,规定了每个变量的数值描述方法,包括数值类型、单位、数值内容等,如表6所示。

　　 标准信息集被嵌入到CPN中。由于CPN与空间或源设备一一对应,这就自然完成了信息所在位置或者信息与设备从属关系的软件描述。由于标准信息集对应建筑及其机电设备系统的构成单元,它们所组合成的建筑自动化系统的数据结构与被控系统一致。植入到各个CPN的标准信息集共同定义了整个系统的软件数据结构。随着CPN拼接成建筑自动化系统,结构化的数据系统随之同步生成。这相当于将软件开发工作部分预先植入CPN中。留给现场工程的只剩下将真实存在的物理参数与相应标准信息集中的变量相对接。

　　 CPN的第二套接口连接提供基于标准通信技术的外设接口实现标准信息集与真实的物理参数的对接。标准通信接口可以保证数据的可靠交换;而数据含义的解析则由标准信息集中各个变量的编号、对应的参数内容、变量数值描述方式等内容规定。在这个意义上,标准信息集其实也是CPN与外设设备的应用层开放通信协议。

　　 空间单元和源设备单元的外设接入工作不完全相同:源设备可以是标准化的产品。生产商可以在其机电设备中嵌入CPN。设备内部各个传感器和执行器信息与CPN及其标准信息集的对接,可以是出厂前在设备生产线上就完成的测试工作。现场工程即插即用,没有额外的外设接入工作。空间的需求是个性化的。现场工程师需要确定空间内部设备应关联到标准信息集提供的同类多个设备中的哪一个。但与常规系统架构下的配置不同,群智能系统中各个空间单元的配置相互解耦,彼此不影响,可以同步并行进行。

　　 根据1.2节的分析,建筑内的物理过程按照空间位置由近及远变化。群智能系统因此被设计成CPN按照空间位置关系就近连接、CPN只与邻近的CPN交互协作的系统形式。在这样的系统架构下,没有任何一个CPN需要知道建筑或机电设备系统的整体结构。整体系统结构的辨识问题被转化为由各个CPN只分别对局部系统结构进行识别的问题。

　　 如2.1节所描述,每个CPN提供6个独立的接口分别连接6个邻近的CPN。由于这6个接口在物理上是彼此独立的,CPN会清晰地区分出来自不同CPN的数据,并给连接在不同接口上的邻近CPN分别取名为1～6号邻居。CPN与邻近CPN之间存在心跳检测机制:如果接收到来自邻近节点的数据就认为相应的邻居存活;如果长期接收不到则认为相应邻居不存在。每个CPN都知道各自对应的基本单元类型。通过与邻近CPN的信息交换,CPN也可以知道各个邻居的类型。在此基础上,每个CPN都会根据节点类型和相应标准信息集内容,设定本地和6个邻居节点的实时运行数据存储空间,从而建立起局部的系统信息模型。

　　 CPN之间的连接线决定了系统的网络结构,也决定了各CPN局部建立的信息模型。随着网络的搭建,系统模型在各个CPN上伴随生成且在邻近的CPN上相互备份。通过这种方式,群智能系统可以自动地识别出整个系统,作为进一步实现控制管理的基础。

　　 群智能系统如何支持各种可能的控制管理任务?笔者认为:各种控制逻辑和管理策略本质上都是一系列计算。如果各种数学计算都能由上述CPN构成的网络准确可靠地完成,那么CPN网络就能够完成由数学计算排列组合而成的多种计算任务序列,从而能够支撑可能存在的各种控制管理功能。但是,在CPN计算网络中:1)不允许要求任何一个节点知道全局信息,每个CPN只能与邻居交互;2)要求所有CPN是平等的,拥有几乎完全相同的计算机制;3)要求计算机制是通用的,算法能自动适应各种CPN网络拓扑和网络规模,与网络结构无关。在上述条件下,还要求计算总能够收敛并得到准确的结果或近似最优的结果,这是否可能实现?

　　 图7为简单的求和计算示例。7个节点组成网络,每个节点各自的本地参数x_i的数值依次为10～70,即x_i=10i,i=1,…,7。对变量进行求和计算得到∑x_i。在网络中,没有任何一个节点知道系统中一共有多少节点,每个节点只知道自己的本地参数x_i,并可以和邻近的节点交互数据。网络中任何一点都可以发起计算。假如由1号节点发起计算,第一步会生成一个以1号节点为根节点的虚拟生成树网络,生成树上每个节点最多只有一个上游节点,可以有多个下游节点。对应图7,节点5和节点6之间的连线取消就是一个以1号节点为根节点的生成树。第二步,从生成树的末端节点开始,每个节点都执行式(1)所示的计算算子,当节点收到所有下游节点传来的数据后触发算子计算,将本地数值与所有下游节点传来的数值相加,再发送给上游节点。

　　 $x{}_{\text{o}\text{u}\text{t}}=x{}_0+{\displaystyle \sum x}{}_{\text{i}\text{n}}(1)$

　　 式中 x_out为输出到上游节点的计算结果;x₀为本地变量数值;x_in为各个下游节点的数值。

　　 对应图7,节点4,5,6,7判断出自己是生成树的末端节点,没有下游节点,按照式(1)计算,就将各自的x_i变量值发送给其上游节点,节点4,5发送给节点2,节点6,7发送给节点3。节点2收到节点4,5的数据后,将本地变量值与其相加,再将结果110发送到其上游节点1;节点3执行类似的操作。节点1收到节点2,3的数值后,计算得到最终结果270。由于它没有上游节点,网络中的计算到此结束,发起节点获得最终计算结果。上述计算过程中,节点4,5,6,7,节点2,3的计算可以分别并行执行,从而充分利用网络中各个节点的计算资源,缩短计算时间。这一计算方法,每个计算节点的处理机制是完全相同的,与系统的网络结构无关,与发起点无关,在各种网络和发起点情况下都可以得到准确的计算结果。

　　 图8为求解线性方程组计算的例子。图中只有4个节点,它们彼此连接成环状。每个节点都有一个未知数x_i,节点i和j之间的相互影响用参数a_ij描述,线性方程组Ax=b描述了各个节点未知数满足的约束方程,其中,x=[x₁,x₂,x₃,x₄]^T,b=[b₁,b₂,b₃,b₄]^T。根据群智能建筑自动化系统假设,节点之间连接反映的是其位置关系,也即各自物理场相互影响的关系。以节点1为例,由于其只连接了节点2和4,表明节点1的物理场只与节点2和4发生关系,和节点3没有关系。因此矩阵A中反映节点1和3关系的系数值为0。由于每个节点都只允许了解本地和邻居的信息,因此各个节点只掌握部分参数,如图8中1号节点的示例。

　　 线性方程组的算子为

　　 $\begin{array}{l}x{}_0=\frac{b{}_0-{\displaystyle \sum _{m=1}^{6}a}{}_{m}x{}_m}{a{}_0}(2)\\ (x{}_{0,k}-x{}_{0,k-1}){}^2<\epsilon {}_0,k=1,2,3,\cdots (3)\end{array}$

　　 式(2),(3)中 x₀为本地计算结果;a₀,b₀为本地参数;a_m,x_m分别为与第m个邻居的相关系数及第m个邻居传来的计算结果;k为计算次数;ε₀为收敛阈值。

　　 每一次调用算子计算出本地的变量x₀,都会发送给所有邻居,从而触发邻居节点继续调用该算子进行迭代计算,直到每个节点2次计算出的结果满足式(3)所示的收敛条件。当系统中不再有节点触发算子时,整个计算结束。此时,各个节点最后计算得到的变量x₀就是方程的解,且每个节点只获得了与自己有关的解。可以证明,上述迭代计算在不同的规模和拓扑结构下都是收敛的,并且收敛速度不随系统规模变化 ^[6]。

　　 从上述2个例子可以看到,在没有任何节点掌握全局信息且所有节点处理机制完全相同的情况下,可以只通过邻近节点间的相互协作实现整体的计算任务。

　　 笔者对各种常用数学计算都作了类似的并行算法设计,并通过数学证明、硬件计算实验等方式验证了算法的可行性。大部分并行算法都采用这样的机制:将计算拆成基本算子,完全相同地植入每一个CPN。每个算子都是一小段运算,其输入来自于本地或者邻居的信息,其运算结果会发送给相应的邻居,触发邻居的算子运算。计算由某个或某些节点率先触发,然后在相邻节点间依次或迭代进行,直到所有CPN达成计算完成条件。计算结束后各个节点分别得到计算结果。新增或删除节点不需要额外的注册或注销机制。系统会自动适配因节点规模和网络结构变化导致计算问题的改变,自动对新问题计算得到正确结果。这类似于昆虫群落的协作机制:依靠植入在各昆虫体内、几乎一致的基因代码指导个体行为,通过个体间的简单交互完成整体的任务;昆虫群落的各种行为仅是调用相应功能的不同基因代码;群体的任务可以由任何昆虫个体发起,每项工作都是由群体共同完成的。

　　 图9列举了已通过验证、CPN计算网络可以实现的并行计算函数。包括最基本的数学运算、常用的优化算法,以及建筑管理领域知识相关的应用算法等,它们形成了3层算法函数库。就像植入在昆虫体内用于执行不同任务的基因代码一样,库中函数的算子也被植入在CPN节点中,供各种控制管理任务调用。

　　 在此基础上,笔者开发了一套分布式操作系统,用来协调调度各个CPN的工作。称其为“分布式操作系统”,是因为系统中任何一项计算任务都是由CPN构成的群体通过分布协作的方式共同完成的。分布式操作系统主要有以下功能:1) 使CPN具备自我辨识和局部系统辨识的能力;2) 将标准信息集和并行计算函数库平等地植入每个CPN;3) 响应应用程序要求,执行并行计算任务序列,依照时序触发具体的计算任务,完成应用程序;4) 当系统中有多个应用程序时,调度CPN响应不同应用程序的时序,尽可能充分利用CPN计算能力,缩短应用程序完成时间,提高计算效率;5) 实现系统安全保护、用户和项目权限管理、在线升级等功能。

　　 分布式操作系统对外提供一系列API(application programming interface)接口。通过这些API接口可以实现变量管理、定义或触发计算、定义或触发计算任务序列、获取计算结果等功能。用API指令序列定义并行计算任务序列,从而可以将暖通工程师的控制管理思路转化为CPN计算网络能够理解执行的代码。

　　 群智能建筑自动化系统的应用软件,是实现建筑机电设备实时优化控制和数据分析的程序,是基于分布式操作系统提供API编辑的并行计算任务序列。分布式操作系统提供的API接口是开放的,因此任何人都可以在这样的操作系统上根据自己的理解编辑应用软件。编程工作从基于专业计算机语言“累码”的工作转变为计算任务工序的设计,这为各专业工程师降低了门槛,有助于他们将专业领域知识应用在建筑自动控制领域。由于操作系统内置了各种建筑基本单元的标准数据集,这相当于在建筑中内置了一套标准的结构化数据;操作系统提供的并行计算库中的函数又可以通过邻居节点间相互协作自动适配不同的系统结构、自组织完成计算,据此开发的应用程序也可以自动适配不同的系统结构;因此基于群智能分布式操作系统的应用软件可以是通用程序,而不是为某个项目定制的专用软件。分布式操作系统和控制应用软件的关系,就像手机操作系统和手机APP的关系。在群智能建筑自动化系统中,用户也可以像手机用户那样从云端应用商店中灵活地下载、删除应用软件,根据需求随时自定义建筑的“智能”。因此,有时也将群智能系统中的应用软件称为“APP”。

　　 需要说明的是:和手机端的APP不同,群智能建筑自动化系统的应用软件只运行在由CPN构成的计算网络上,主要解决建筑及其机电系统的实时控制、管理、数据分析等问题,不解决人机交互问题。

　　 传统的中央站需要同时实现全局优化控制和人机交互2个功能。但全局优化控制要求的实时性高,而人机交互功能对实时性的要求一般。在常规系统中,整个系统的数据都汇总到中央,虽然方便了用户对系统整体运行情况的查阅,但为了同时保证全局控制的实时性,对系统延时、中央站处理能力等都提出了极高的要求。群智能建筑自动化系统将这2个功能解耦:用CPN计算网络完成实时要求高的优化控制和数据诊断工作,人机交互功能用PC和移动终端领域的成熟方案解决。既然整个CPN网络是一台并行计算机,且每个CPN都可以提供WiFi等外部接口,因此可以用PC或移动终端从任何一个外部接口接入群智能系统,触发系统中数据查询和统计的应用程序,获得建筑整体的运行数据和统计报表,完成人机交互功能。这样可以充分利用相关领域的成果,提升人机交互的用户体验。

　　 群智能采用与常规系统完全不同的技术架构,因此可能在建筑自动化系统的实施流程、开发过程、应用维护等方面带来新的模式,进而导致相关参与方的分工和角色发生改变。

　　 图10为传统技术和群智能技术实施流程的对比。传统系统设计流程如图10a所示。工作在被控对象设备系统确定后才能开始。

　　 首先要确定控制功能,包括测量哪些参数、控制哪些设备、采用何种策略等等;然后才能根据功能需求逐步深化设计和安装调试。然而,在一般工程中,建设方和运营方通常不是一套人员,运营方的功能需求很难准确地传递到设计阶段;此外,商业建筑的运行管理需求随着建筑经营阶段不断调整,即使是运营方也很难在设计阶段就准确预测未来的管理问题,也就很难清晰地定义功能需求。因此设计阶段的功能定义往往与实际的需求相差万里。由于传统架构下系统结构和控制器配置选型与功能紧密相关,当功能需求相对设计方案发生变化时,要么重新执行图10a的流程,要么用人工控制弥补系统对功能变化的缺口。

　　 群智能系统将计算能力与具体功能解耦:建筑控制需求虽然可能不断变化,但建筑空间、建筑内的大型机电设备在建筑建成后却不经常改变;与之相对应,群智能系统将CPN植入空间和源设备这些已确定结构的建筑基本单元中,用CPN连接成的计算网络构成建筑自动化系统的骨架。需要灵活变化的是室内环境监测和控制用到的传感器、开关等末端设备,以及控制逻辑、运行策略等;与之对应,群智能系统允许相关末端设备可以通过无线接口等随着应用需求灵活添加或删除,由于相应设备所对应的参数已经通过基本单元的标准信息集结构化地植入群智能系统,局部设备的调整只需要与设备所在空间CPN进行关联,而不影响系统其他部分的软硬件设置;控制策略和应用软件可以随时下载到CPN网络内置的分布式操作系统中,下载即运行。

　　 因此,群智能系统的设计和实施将平台与功能设计分开,采用平台+功能的方式,如图10b所示。当建筑平面和源设备系统结构确定后,就可以进行CPN网络设计。即使没有确定末端测量哪些室内参数,控制哪些末端设备,以及采用何种控制策略,也可以根据控制管理功能所覆盖区域、空间结构,以及与末端“模数”相关的机电设备系统专业知识,将空间划分成多个模块,为每个空间模块设置一个CPN,并按照空间模块的相邻关系设计出网络结构,如图11所示。在工程实施阶段,当建筑结构完成后,即使传感器或末端机电设备没有安装,也可以像安装电源插座那样,先将CPN网络安装在建筑空间。CPN计算网络安装完成后,群智能系统平台就已经完成部署。之后,再根据功能设计安装和连接室内环境测量、控制设备等,各个空间设备的连接与安装彼此独立,不相互影响,可以并行展开。最后,再根据控制管理策略需求,从云端应用软件库或应用商店中选择已经过充分测试的应用软件,下载到CPN网络,应用软件下载即运行。

　　 常规建筑自动化系统架构下,控制策略开发是一项定制化开发工作。一方面,制冷机台数、制冷量匹配、一级泵/二级泵系统结构等建筑机电系统等设置在不同项目中往往不同,优化控制策略需要根据具体的系统形式调整控制逻辑;另一方面,即使采用相同的控制逻辑,通用控制器的I/O通道与传感器、执行器的实际对应关系在不同工程项目中也通常不同,需要根据实际情况调整控制软件。然而在实际工程中,建筑自动化系统开始调试的时间通常在机电设备安装之后,距离开业和项目整体工程验收的时间点往往只有几周时间。时间短、任务重,二次开发程序难以被全面测试。业主着急开业,供应商着急收款,很多问题都潜伏下来,一直延续影响日后系统运行,也就难以保证预期的优化控制效果。

　　 群智能系统采用标准信息集和自组织的计算方法,可以将工程调试过程转化为更可靠的产品开发过程。

　　 一方面, CPN可以被嵌入到各种源设备中,将其升级为群智能设备。CPN可以与设备原有的本地控制器集成在一起。本地控制器是一种专用控制器,实现设备工艺过程的参数监测、安全运行、优化调节、能源计量等功能,通过通信接口与CPN交互标准信息集中描述的外部运行参数;CPN是设备在群智能系统中的代理,自动辨识邻居设备,辨识本设备在系统中的位置,负责与系统中其他基本单元一起实现系统整体的协调运行。嵌入到源设备中的CPN是智能设备的一部分。传感器和执行器与本地控制器的连接、CPN与本地控制器的连接、本地控制器内部的控制软件都在产品出厂前由制造商进行过充分的测试,这其实是将传统流程中的单机调试和配置工作转移到产品制造过程中,从而大幅提高可靠性。标准化的群智能设备产品只要安装在项目中,按照系统结构彼此连接,下载相应的群智能应用软件,就可以即插即用自动实现全局优化控制,而不要额外的控制系统及相应的调试工作,从而大幅减少了定制化调试工作。对设备制造商来说,只是嵌入CPN,对产品生产和测试流程改变不大,并不增加多少成本,同时却使得设备具备了全局优化能力,获得了建筑自动化的一部分控制市场。

　　 另一方面,CPN计算网络自识别、自组织的能力,可以实现同一套分布式算法对不同机电系统形式的自适应。对开发者而言,建筑自动化系统的策略不再是定制化的程序开发,而变成通用软件产品开发。开发过程不只针对某一特定建筑项目,经过从简单到复杂不同拓扑结构和规模的CPN网络的充分测试,可以得到稳定可靠的通用应用软件。充裕的开发测试时间和系统的开发流程可以大幅提高控制策略的品质。一次开发过程得到的软件可以在多个项目中应用,从而又可以大幅降低软件开发成本。

　　 系统实施方式从工程到产品的变化,可能进一步引起建筑自动化行业参与各方分工合作方式的变化。常规架构下,计算机、通信、自动化等专业是主导,虽然机电设备工程师、节能运维人员等更具备机电设备和节能运行方面的知识,但系统架构、编程方式、组网调试等都增加了信息技术门槛,使得很多建筑和机电专业人员望而却步;而信息技术科学的工程师又难以深入理解机电设备,因此往往不能实现高水平的控制效果。群智能技术面向空间和源设备这些建筑基本单元定义信息系统,使得建筑自动化系统容易被建筑和机电工程师理解;通过标准化的计算节点实现自识别、自组织,将组网配置等信息系统工程问题大幅简化;这些降低了建筑自动化系统的信息技术门槛,使得非信息科学专业的设备制造商、节能服务企业、物业运维企业、业主、研究学者等都能加入这一领域,发挥各自的专业优势,共同推进建筑自动化领域的发展。

　　 传统建筑自动化系统,业主一旦选定供应商往往就被绑定在供应商的产品体系下。群智能系统采用开放的分布式操作系统,任何开发者都可以基于操作系统提供的API设计控制策略和应用软件,业主也可以选用来自不同开发者的应用软件。这类似于从传统手机到智能手机的变化:传统手机的功能完全由制造商定义,而智能手机其实是每个人根据自己的需求,通过下载不同功能的APP定义的个性化手机。不同的建筑有不同的建筑运维管理需求,随着管理者的不同、管理目标的调整而不断发生变化。群智能技术通过CPN计算网络构建了灵活开放的硬件平台,用户可以按需灵活下载、删除应用软件,定义个性化的建筑自动化系统。

　　 群智能是可以实现跨机电设备系统集成控制管理的通用平台方案。从2016年起,陆续在办公楼、商场、体育场馆等多个类型的项目中得到应用,实现对冷热源、空调、照明、遮阳等机电设备系统的优化控制,以及环境监测、能耗计量、物业巡检等功能。在这过程中也解决了一些暖通空调控制传统意义上的难点问题,取得了改善环境品质、提高运维效率、降低运行能耗的效果。

　　 变风量系统控制一直是暖通空调系统控制的热点,群智能技术曾被用在深圳某办公室改造项目中解决变风量控制问题。在改造前,电动风阀可以远程手动调节,但没有实时控制策略。管理人员只是根据初调节的结果,让各个风阀分别保持在某个固定的开度,以保证各个建筑区域不会过热,不会引起投诉。但建筑中许多区域存在过冷现象。此次改造业主曾考虑安装压力无关的变风量箱,但考虑到设备和工程成本,最终还是选择尝试用控制策略解决问题。这个项目用了20 人·d,完成了总计超过2万m²空调面积、多个变风量系统的调试。

　　 如图12所示,为AHU设置一个CPN,实现AHU的控制调节;同时为每个可调节风阀所在的室内空间安装一个CPN节点,测量该空间温度,调节相应的风阀;所有CPN一起完成变风量系统的优化调节。CPN之间按照空间位置连接成树枝状拓扑;由于风道是沿着空间敷设的,CPN的连接拓扑也是风道的拓扑。

　　 整个变风量系统的控制策略包含AHU内部控制策略、风阀末端的本地调节,以及风阀解耦协作控制、总送风量调节4个部分。其中,AHU内部控制策略和风阀末端的本地调节都是基本单元内部的控制调节任务,可以选用成熟的控制算法实现 ^[8]。需要CPN之间相互协作完成的是风阀解耦协作控制和总送风量调节。

　　 压力无关型变风量箱通过增加串级控制环节来解耦各风阀的调节,从风阀动作效果来看,如果邻近风阀开度增大,即使本地的冷热量需求不变,本地风阀也会相应地开大。在本应用案例中,虽然没有压力无关型变风量箱,但可以在每个CPN中植入如式(4)所示的算子。

　　 $\text{Δ}{\rm K}{}_0=\text{Δ}k{}_0+\underset{m=1,\cdots ,6}{{\displaystyle \max }}\{\alpha \text{Δ}{\rm K}{}_m\}(4)$

　　 式中 ΔK₀为最终的本地风阀调节量,是综合考虑邻近阀门变化量后的修正结果;Δk₀为因本地负荷变化引起的风阀开度调节需求,由风阀末端本地调节逻辑得出;α为在[0,1)区间的系数,可以是经验值,也可以由在线自学习算法得出;ΔK_m为各邻近风阀的调节量。

　　 按照式(4),任何节点阀门的最终开度都是本地控制需求和相应邻近阀门调节的综合结果。对风阀开度的修正会从发起点开始,沿着CPN网络由近及远地扩散,修正效果依次递减,远离发起点的风阀几乎不需要修正。

　　 各空间CPN可以根据式(4)的计算结果各自判断是否存在风量不足的情况:如果风阀开度增量与当前开度之和超过100%,说明风量不足。变风量系统的总送风量通过调用植入在CPN中的“求与”计算和“求最大值”计算,分别计算得到各个末端是否存在风量不足的情况,以及系统中各个末端阀门开度的最大值。如果系统中有风量不足的情况,就增加风机转速;如果末端风阀开度的最大值小于90%,说明送风机转速偏高,降低风机转速;其他情况保持风机转速不变。

　　 图13显示了风阀开度和房间温度在上述控制策略下的实际运行效果。可以看到:各个风阀都在自动调节;调节过程平稳,没有相互影响导致的振荡;房间温度始终控制在设定值附近,没有过冷的区域。图14为下载运行上述变风量控制策略前后风机能耗的对比。由于末端风阀能够自动调节,避免了部分区域过冷的情况,送风机能耗大幅降低。

　　 在大型集中空调系统中,制冷机能耗通常是空调系统能耗中最主要的组成部分。制冷机的台数控制本是建筑自动化系统的任务范围,近年来越来越多的业主开始将这块业务划分给制冷机设备厂商,一方面由于控制公司难以从设备厂商那里获得不同工况条件下的制冷机性能曲线族,另一方面也因为设备厂商更熟悉暖通空调专业。在实现制冷站群控时,制冷机设备厂商也普遍采用传统的建筑自动化技术体系;但是如前所述,由于各个工程项目的制冷机台数、各制冷机制冷能力配置等不同,在传统技术架构下控制策略需要定制化开发。这使得本来只做制冷机产品的企业,还要有自动化工程管理能力,而与设备厂商熟悉的产品生产维保模式不同。群智能技术以单个制冷机设备为基本单元,通过将CPN植入到制冷机产品中让其升级为智能产品。群智能制冷机彼此可以自组织协作实现全局优化控制。设备厂商可以延续产品生产制造的管理模式,不必担心工程管理的问题,同时又能实现制冷机群控的优化效果。

　　 群智能算法要求嵌入了CPN的智能制冷机都掌握自己各种工况条件下制冷机COP随负荷率的变化曲线,但任何一个智能制冷机都不需要知道其他制冷机的性能曲线。制冷机性能曲线可以是设备厂商在出厂前内置的,也可以通过现场测试或自学习算法后期得到。要求并联的各台智能制冷机彼此连接成链状的计算网络。加入计算网络的制冷机可以是不同型号、不同制冷量,甚至不同厂家的制冷机。算法可以由任何一台制冷机发起计算。

　　 图15为平等植入在每台制冷机中的制冷机加减机控制算法的算子流程图 ^[8]。系统可以以20 min为间隔,每隔一段时间就触发一次优化计算。任何一台制冷机都可以触发计算。每次调用算子的计算,各个制冷机都会根据预期的相对效率和从邻近输入的需要本制冷机承担的制冷量判断本机是否运行:如果输入制冷量为正值,说明系统中其他制冷机提供的总制冷量不足,还需要新的制冷量,则本机应该运行;如果输入制冷量为负,说明提供的总制冷量已经超过需要,则本制冷机应该停止运行。同时,根据制冷机在当前工作条件下的性能曲线计算如果达到预期效率制冷机能够提供的制冷量,并与上次算子计算的本地制冷量相比,将二者的差值与输入制冷量相加;得到Δ并输出给下一个邻近节点。对于第一次执行算子的情况,以当前制冷机的实际制冷量作为Δ执行上述运算。如果所有节点都执行过当前预期效率下的计算且每个制冷机都尝试过运行和停止2个状态,Δ仍然较大,则说明当前预期效率不可及,发起节点下调预期效率,再进行下一轮的迭代计算;如果输出Δ结果小于阈值δ,说明在当前的预期效率下,各个制冷机计算得到的运行/停止状态能够满足制冷量需求,这就是本次计算的结果,同时最后的预期效率就是执行了新的制冷机运行/停止设定之后,各个制冷机所能达到的效率。

　　 图16为上述制冷机台数控制算法在珠海某制冷机测试台项目中制冷机的逐时开启台数结果,可以看到制冷机台数随负荷波动自动调整,并且与理论上的最优结果基本一致。这个项目的现场安装和调试只用了2 人·d。图17为长三角地区某大型商业项目应用上述算法在8月内各台制冷机运行负载量的统计结果。图18为该项目中制冷机在8月各典型工况条件下的性能曲线。可以看到,各台制冷机都主要工作在COP较高的60%～80%的负荷率下。上述2个案例的算法完全相同,是下载同一控制算法APP而实现,不需要针对项目的二次定制开发。此外,群智能算法与常规的制冷站群控系统相比的另一项特点是可以自适应机电设备检修和维保管理。任何一台设备检修、停止,群智能算法都可自动选用其他设备,不需要单独另行开发算法。

　　 本文介绍了一种仿照昆虫群落工作机制,可以自组网、自辨识、自协作的新型建筑自动化系统,同时介绍了新系统在暖通空调典型控制中的应用。不同于以往从工业控制或互联网领域直接继承的信息技术,这是从建筑和机电控制需求出发重新设计的新型系统。这项研究工作的初衷是改变目前建筑自动化系统普遍存在的组网调试周期长、成本高,系统改造和策略更新不灵活,暖通空调专业知识落地困难等问题。经过多年的研究和工程验证,已经初步验证了这套新系统架构的可行性,与传统技术相比展现出实施快、算法自动适配项目、灵活性高、开发过程更开放等优势。群智能是建筑自动化领域的一次技术革命性尝试,在分布式算法、工程实施方法、软件编程环境等方面还需要更深入地研究,需要在更多的工程应用中不断完善。