建筑能耗软件协同开发及可靠性技术方法
2020-02-04孙红三苏小红
孙红三， 燕 达， 周 欣， 黄 宇， 苏小红， 郭 勇
(1.清华大学建筑节能研究中心， 北京 100084； 2.东南大学建筑学院， 南京 210009； 3.广州大学土木工程学院， 广州 510006； 4.哈尔滨工业大学计算机科学与技术学院， 哈尔滨 150001)
随着中国城镇建设的飞速发展，建筑节能已成为建筑可持续发展的最重要课题之一。由于建筑物及其环境控制系统受气候条件、围护结构、设备系统和控制策略等众多因素影响，以及新型围护结构、人行为、机电系统、可再生能源系统等新技术的不断发展，使得建筑能耗全性能模拟技术成为建筑节能的关键问题之一，并且促使了建筑能耗模拟技术不断地面临着新的技术发展挑战。而建筑全性能仿真软件则是仿真模拟的直接工具，也是实施建筑设计、运行、节能诊断等绿色建筑研究与应用中必不可少的手段。
目前，保持持续开发、得到业内广泛认可的模拟软件主要有：ESP-r、DOE-2、IES
考虑到建筑新型围护结构、人行为因素、可再生能源等多种影响因素越来越丰富和复杂，对于建筑能耗全性能模拟仿真软件，不仅需注重软件的性能，还需重点考虑软件具有可移植、可扩展、不断更新的持续发展特性，并且需要建立多个具有不同功能、独立知识产权的软件组件来实现联合模拟计算体系[3]；同时，还要特别关注软件的代码质量、精确度、可靠性等可持续发展的关键问题。
基于国家重点研发计划，面对所承担的软件协同开发研究项目“建筑全性能仿真平台内核开发”，联合国内多家长期从事建筑能耗领域研究工作的知名高校、科研院所以及建筑软件开发企业等，建立了一套软件协同开发的管理体系、软件可靠性检测、软件准确性检验方法，实现多家协同开发、科学性强、准确高效的建筑全性能仿真平台内核(简称“平台内核”)，为中国绿色建筑发展提供关键技术支撑。建立平台协同构建→代码质量管理→准确性验证三阶段开发体系，实现软件开发技术的提升，确保平台内核的开发管理、代码质量以及软件可靠性。
1 协同开发管理体系
建筑全性能平台内核功能模块多、模块结构各异、独立性强；面对其多个团队参加、多项独立功能集成、计算可靠准确等开发需求，采用基于Web服务器的GitLab平台进行代码管理、协同开发与集成，建立了平台内核的协同开发体系。协同开发技术路线如图1所示。
图2 联合仿真平台内核架构Fig.2 Architecture of co-simulation platform kernel
图1 软件协同开发技术路线Fig.1 Technical route of collaborate software development
1.1 建筑全性能平台内核
基于已有的DeST软件技术研究及开发，提出建筑全性能仿真平台内核的体系结构，图2所示为平台内核架构。其中，内核主控单元的本体计算部分主要包括室温、负荷、采光、地下传热、中庭气流等功能模块；主控的机电系统部分主要包括末端系统、空气处理、冷热源、用能系统等功能模块以及功能模型接口(functional mock-up interface，FMI)处理模块；而从属功能模型单元(functional mock-up unit，FMU)单元主要包括室内空气品质、热湿动态耦合传递、变物性围护结构、人行为、可再生能源系统等独立功能模块。
考虑到软件的兼容性和扩展性，以及适应软件工具碎片化、模型重用和其他独立开发模型产权保护等多项问题，采用国际上成熟和通用的基于功能模型接口(FMI)/功能模型单元(FMU)的多模块联合仿真(co-simulation)架构，建立全性能联合仿真平台架构及技术解决方案，实现以建筑热过程和机电系统为核心主控单元，人行为、变物性围护等独立FMU模块为从属单元的主控(master)/从属(slave)模式动态联合计算[4]。
1.2 协同开发与联合模拟
由于各个开发团队都是独立开发本身的模型及功能模块，因此需要具有统一的模块集成接口。2008年，由Daimler发起，28个欧洲伙伴参与的Modelisar项目制订了国际通用模型接口标准FMI；基于该标准，许多建筑能耗模拟软件都开发了FMI标准接口，如EnergyPlau、Modelica、Simulink 等，实现联合多个独立仿真工具为一体，各自基于FMI接口标准独立开发，保持其自身的知识产权，灵活有效地完成了多功能模块联合模拟计算[5-6]。
FMI接口包括标准函数接口和模型变量描述文件两个部分。FMI标准函数接口包括：一组符合C语言标准的函数接口，接口名称形式为“模型标识符(identifier)-标准函数接口名称”；FMI模型变量描述文件(ModelDescription.xml)包括FMI属性信息、变量属性、变量类型等模型变量描述信息。
平台内核多方协同开发的核心过程由以下三部分组成。
(1)主控开发团队。基于GitLab开发管理平台，提交管理所开发的建筑热过程模块、机电系统、FMI接口等平台主控单元代码，协同开发团队只能下载、参考主控单元代码；同时，还建立了FMU软件开发工具包(SDK)，使得协同开发团队在此基础(统一的FMI接口)上，开发自身的功能模型单元FMU。
(2)协同开发团队。基于主控开发团队提供的SDK，基于所研发的模块模型，开发自身的FMU，并且以FMI/FMU模式实现与主控单元的联合模拟计算。
(3)多模块联合模拟过程。协同开发的多模块联合模拟过程，是以主控开发团队开发的建筑热过程模块、机电系统、FMI接口等模块为主控单元，协同开发独立FMU为从属单元(如人行为、变物性围护等)，主要通过“准备”“仿真”“结束”三个阶段，实现主控/从属模式的多模块动态联合模拟计算；动态联合计算过程如图3所示。
图3 协同开发的多模块联合模拟过程Fig.3 Process of multi module co-simulation on collaborative development
1.3 协同开发管理
基于软件工程方法，全面考虑项目管理、分析、设计、程序的编写、测试和质量控制等；针对软件协同开发的需求，建立了软件内核协同开发管理、软件质量控制检验、软件准确性测试与检验方法，实现多家协同、科学性强、准确高效的平台内核协同开发。软件协同开发管理流程如图4所示，其中三个主要阶段如下。
(1)软件协同开发管理。基于GitLab平台建立项目内部的对代码进行管理，实现多团队的多人协同软件开发管理以及联合调试与运行。同时进行项目文档的服务管理，包括：软件设计文档、开发技术文档、使用说明书、测试案例及说明等。
(2)软件质量控制检验。为了控制所开发的软件质量，相应开发了两个Web端的软件质量控制检验工具：功能模块正确性检验工具以及代码缺陷检测工具；用于所有开发团队在不同地点进行在线独立软件单元检验，以便保证各个独立软件单元的功能正确性及软件中潜伏的各种错误和缺陷，确保平台内核的开发质量以及可靠性。
(3)软件准确性测试与检验。软件准确性测试与检验是采用了ASHRAE-140国际建筑能耗模拟软件对比标准，对研发的平台内核通过程序间对比、实测验证两种方法进行检验。本检验方法不仅在检验过程中对平台计算内核进行勘误和修正，更重要的是，通过验证过程，可以证明全性能仿真平台在计算建筑性能方面的有效性和准确性。
图4 软件协同开发管理流程Fig.4 Process on management of collaborative software development
2 软件质量控制检测方法
软件测试及可靠性是软件开发任务的重要环节，对于由多个单位联合开发的软件平台，每个开发团队负责其中的一个模块开发与测试，这是一个复杂的系统工程。开发的代码质量检测工具及功能正确性在线测试系统，支撑各团队独立完成所开发的功能模块的正确性，以及平台内核集成的开发质量与可靠性。
2.1 代码质量检测工具
研究基于缺陷模式的C++缺陷检测方法，以拓展检测更多类型的缺陷，并集成具有互补能力的多种缺陷检测工具，使之能够检测更多类型的缺陷，降低漏报和误报，提高缺陷检测的准确率[7-8]。
首先在研究开源工具Cppcheck基本工作原理的基础上，研究基于缺陷模式的C++缺陷检测方法，将12种C++缺陷模式抽象成为正则表达式，并设计和实现相应的缺陷检测方法。然后，为了进一步降低缺陷的漏报和误报，研究将改进的Cppcheck、Clang Static Analyzer和Flawfinder工具集成的方法。开发了C++代码缺陷检测工具，功能结构如图5所示。
利用缺陷检测工具对平台内核初始版本进行了测试，检测出的缺陷类型和数目统计如表1所示，其中，缺陷为三大类：①故障类缺陷，例如内存泄漏、未初始化变量；②缓冲区溢出等导致系统安全问题的缺陷；③可能存在问题的可疑代码，例如死代码等。由此针对性地指导了平台内核代码修改，有效地保证了代码开发质量。
该检测工具能够有效检测软件缺陷，多种工具相结合检测出的同一缺陷正确率更高，从而能够有效辅助开发人员检测和消除软件缺陷，提高所开发软件的可靠性。
2.2 软件正确性在线测试系统
整个平台内核由大量独立模块组成，并且这些模块由多个单位协同开发，这就给内核的联合测试带来不便，并且每个模块的测试数据量都庞大，无法通过人工方式对结果数据进行误差分析。为此，开发了软件正确性在线测试系统，该系统是一个分布式测试平台，其系统结构如图6所示。
图5 缺陷检测工具功能结构Fig.5 Functional structure of defect-detection tools
表1 平台内核初始版本的缺陷检测结果
联合测试的过程：首先，每个模块实现者创建测试项目，根据需要，在项目中创建一个或多个测试用例(包括指定的测试结果)，并设置测试精度；其次，将被测代码从代码管理平台同步到测试平台，进行编译和语法检测；最后，自动进行测试，并给出评测结果。测试者可以根据给出的测试结果，调整算法，最终达到要求；联合测试的界面如图7所示。
图6 分布式测试系统结构Fig.6 Structure of distributed test system
图7 联合测试操作界面Fig.7 Operation interface of co-simulation test
软件协同开发研究项目的实际应用表明，该测试平台解决了复杂的平台内核模块的联合测试问题，能够高效快速地进行模块的联合测试，大大提高了的测试效率，保证了平台内核及各独立模块的功能计算正确性。
3 软件准确性检验
模拟仿真结果能否正确地反映模拟对象的实际情况，直接影响到模拟研究结果的可靠性和推广性，是建筑模拟领域的热点问题。为了对建筑能耗模拟软件性能展开评估判断，行业内提出了各种各样的软件验证的方法。美国暖通工程师协会(American Society of Heating，Refrigerating and Air-Conditioning Engineers， ASHRAE)提出的ASHRAE-140标准是国际建筑能耗模拟软件进行自我程序检查与准确性验证的经典标准，其全称为建筑能源分析计算机程序评价标准方法。目前国际上主流的建筑能耗模拟软件均参与这个验证过程，包括Energyplus、DOE-2、ESP等。
依据ASHRAE-140 标准，采用软件对比与实测验证方法，开展平台内核的模拟测试与实测验证工作。
3.1 能耗模拟软件间对比
ASHRAE-140标准针对计算建筑物及其供热通风与空气调节(heating, ventilation and air conditioning，HVAC)系统热性能的软件，标准中详细规定了评估这些软件技术能力和适用性的标准测试方法[9]。
采用ASHRAE-140标准，对研发的全性能仿真平台进行性能检验。其中负荷性能测试部分，共包含17个基础案例和22个深入案例。空调采暖系统性能测试部分，共包含34个空调系统测试案例和11个采暖系统测试案例。
负荷对比算例的计算对比结果主要包括全年尖峰热负荷、全年尖峰冷负荷、全年累计热负荷、全年累计冷负荷、无空调全年室温。空调采暖系统性能测试部分的计算对比结果主要包括送风机电耗、冷凝侧风机电耗、压缩机电耗、系统总电耗、盘管总负荷、房间总负荷、空调系统性能系数、室内平均温度、含湿量、锅炉总负荷、锅炉总输入负荷、燃气消耗量和风机电耗指标。以上计算指标共453项，其中针对负荷对比算例的计算项共148项，针对空调设备系统性能测试算例的计算项共266项，针对采暖设备系统性能测试算例计算项共39项。负荷对比算例和空调采暖设备系统性能测试算例偏差率的百分比频率统计结果如表2所示。
表2 算例偏差率的百分比频率统计
从表2可见，平台软件内核的计算结果完全落在其他软件计算区间内的共322项，占比71.1%；偏差率的百分比落在(0，5%]区间内共72项，占比15.9%；偏差率的百分比落在(5%，10%]区间共33项，占比7.3%；偏差率的百分比落在(10%，20%]区间共11项，占比2.4%；偏差率的百分比落在(20%，+∞)区间共15项，占比3.3%。最大偏差率发生在计算案例195的尖峰冷负荷项上，该案例只有1个软件提供了计算结果，因此难以对计算结果的真实偏差情况进行客观判断。
由以上分析可知，对于大部分负荷对比算例和空调采暖设备系统性能测试算例，平台软件内核与其他参与测试的建筑能耗模拟软件对比计算结果较为吻合，绝大部分算例的计算结果偏差在5%以内，符合ASHRAE-140标准的软件性能评价指标。
3.2 模拟与实测对比验证
选取不同气候区的三个公共建筑，对其全年实际能耗数据进行监测。同时，收集模拟计算需要的必要参数，如气象参数、围护结构、建筑功能等，将仿真平台内核的模拟结果与实测数据进行详细校验，其误差满足ASHRAE-140 标准，即：统计值误差不大于5%，瞬时值误差不大于15%[10]。
3.2.1 模拟仿真
选取河南郑州(寒冷地区)、福建宁德(夏热冬冷地区)、广东东莞(夏热冬暖地区)地区的三座公共建筑。收集包括建筑图纸和暖通空调图纸等相关计算机辅助设计(CAD)图纸，以及建筑所在城市的气象参数文件，从而得到围护结构几何尺寸、热物性参数、室内设计参数、空调设备参数及全年气象参数的信息。为保证模拟仿真与实际情况一致，对收集到的参数均进行现场调研校核，最终参数以现场调研参数为准。
三座建筑模型如图8所示。运行平台内核的各个模拟仿真过程，最终得到全年8 760 h的能耗模拟数据。
图8 建筑模型图Fig.8 Architectural models
3.2.2 实测能耗数据处理
暖通空调分项监测数据的主要特征：在供冷季内的冷水机组、冷冻水泵等开启比例，会随着室外气象状况的变化而变化；而对于商管租户与公区照明数据，则与建筑内人流量相关；除特殊节日外，日人流量在某一数值上下浮动；全年同一时刻照明与设备开启比例高度相似。
另外，由于设备故障及人员操作失误等原因，导致各分项能耗监测数据出现缺失和异常，异常数据主要为两类：①数值异常，由于设备故障或人员操作失误等原因，导致数值短时间内出现不合常理的波动；②数据缺失，由于信号传输中断或设备损坏等问题，导致数据出现“0”或者缺省。按照逐月、逐日到逐时的顺序，采用可视化图形(折线图、热点图)、箱形图判断数据中的异常值，邻近点均值法、回归填补法等方法填补剔除的异常值与缺失值。处理流程如图9所示。
图9 实测数据处理流程Fig.9 Process flow of measured data
3.2.3 结果对比校验
将仿真平台内核的计算结果与全年实测能耗数据进行详细校验，检验标准采用ASHRAE-140标准的统计值误差NMBE(normalized mean bias error)和瞬时值误差CV(RMSE)(coefficient of variation of the root-mean-square error)[10]，模拟数据与实测数据对比如图10所示。
三座公共建筑的全年供冷期内模拟与实测数据误差值如表3所示，均满足规范ASHRAE-140标准。
图10 模拟数据与实测数据比较Fig.10 Comparison between simulated data and measured data
表3 模拟与实测结果对比误差值
4 结论
对于建筑模拟技术研究及软件开发，都面临着多因素联合模拟仿真、综合性能分析等问题；而建筑全性能模拟软件的开发工作具有功能模块繁多、模块结构各异、多团队协同开发集成、可靠准确验证等需求。针对性地提出了建筑能耗模拟软件协同开发管理体系，采用GitLab代码管理平台、参与方协同开发、多方联合集成模拟及Web端的在线调试检验方法，给出了软件可靠性在线检测工具，以及ASHRAE-140标准的软件准确性检验方法，建立了一套多家协同、科学可靠、准确高效的协同开发管理体系，实现了建筑全性能仿真平台内核的开发研制。
建立的“平台协同构建→代码质量管理→准确性验证”三阶段开发体系实现了多个团队的协同开发与集成，同时高效地提升了代码质量，并且推广了国际化软件准确性检验方法，实现了建筑全性能联合仿真软件开发技术及方法的提升。
随着建筑能耗技术研究的深入、多模块联合仿真以及建筑信息模型技术的不断普及与发展，必将促进建筑节能模拟技术的全面发展。将坚持以解决实际工程问题为导向，继续深入探讨基于多模块联合仿真的协同开发技术路径，在丰富建筑模拟功能的同时，不断提高模拟软件的准确性和可靠性，并实现建筑模拟技术在工程应用中的进一步推广。
