veri cation of control sequences within ......that we use to express control sequences and simu-late...

Verification of Control Sequences within OpenBuildingControl

Michael Wetter, Antoine Gautier, Milica Grahovac, Jianjun HuLawrence Berkeley National Laboratory

Berkeley, CA, USA

Abstract

The OpenBuildingControl project develops tools andprocesses for the performance evaluation, specifica-tion and verification of building control sequences.This paper describes the tools developed to verifythat building control sequences are implemented asspecified in a vendor-neutral, executable specifica-tion. The verification is done by testing whethertrended time series, compared to the simulated con-trol response, are within user-specified tolerances fortime and for the trended variable. Morever, sequencediagrams are used for inspection of the control re-sponse.

The paper gives an overview of the OpenBuilding-Control process and describes tools for the controlverification. It presents and example in which we suc-cessfully verified that an actual implemented controlsequence conforms to its vendor-independent specifi-cation. It closes with discussion of experiences col-lected during this verification and with alternate ap-proaches that can improve the operational perfor-mance of buildings.

Introduction

A significant fraction of inefficiency in buildings iscaused by sub-optimal design, implementation andcommissioning of control sequences (Fernandez et al.,2017). Barwig et al. (2002) report that the mostfrequent control related failures are due to softwarefaults, accounting for 32% of all reported failures.Gnerre and Fuller (2017) reports that the lack of anon-ambiguous, executable control sequence specifi-cation prolongs the commissioning and decreases thequality of the control sequence verification, therebyincreasing the fault probability over the lifetime ofthe system. Moreover, as building control sequencesbecome increasingly complicated, a manual verifi-cation as is done today during commissioning be-comes difficult due to the various timers, interlocksand mode switches that are present in advancedsequences such as the ones published in ASHRAEGuideline 36 (ASHRAE, 2018).

To contribute to the increased use of advanced controlsequences and their error-free implementation, we are

executing a project called OpenBuildingControl. TheOpenBuildingControl project develops tools and pro-cesses for the performance evaluation, specificationand verification of building control sequences. Itaims to provide methodologies and tools to close thegap between energy modeling tools, controls specifi-cation and verification of correct implementation ofcontrol sequences. The project specified a workflow,described below, that starts with instantiating andpossible adapting a control sequence from a library,optionally test its performance using energy simula-tion, exporting the sequence in a vendor independentformat for cost estimation and subsequent implemen-tation on control product lines by control providers,and formal verification of the correct implementationof the sequence by commissioning providers.

The focus of this paper is to describe the process andsoftware for the verification of this control implemen-tation. Given a set of control input signals, such asmeasured room and outside air temperatures, the ver-ification tests formally whether measured control out-puts, such as setpoints or actuator signals from thebuilding automation system, agree with these signalsas computed using the original specification. Thisprocess is to be done as part of the building com-missioning. Related work from the project can befound as follows: The overall project is documentedat https://obc.lbl.gov. Wetter et al. (2018a) de-scribe a vendor-independent language called ControlDescription Language (CDL), which is a subset of theModelica language (Mattsson and Elmqvist, 1997)that we use to express control sequences and simu-late their behavior. Wetter et al. (2018b) describethe overall workflow and discuss simulation of con-trol sequences with an energy model in the loop.They also show that changing the control sequencefor a variable air volume flow system between a se-quence published by ASHRAE in 2006 and a sequencepublished in ASHRAE Guideline 36, annual HVACsite electricity use is reduced by 30%, thereby in-dicating the importance of control sequences to re-duce energy use. Moreover, the large difference of1/3 of HVAC site electricity use questions the va-lidity of today’s common practice of idealizing con-trol sequences in building energy simulation. To re-

________________________________________________________________________________________________

________________________________________________________________________________________________ Proceedings of the 16th IBPSA Conference Rome, Italy, Sept. 2-4, 2019

885

https://doi.org/10.26868/25222708.2019.210722

https://obc.lbl.gov

spond to the need for better representing controlsand integrate energy modeling with the control de-livery process, we are currently redesigning Ener-gyPlus through a project called Spawn of Energy-Plus (https://www.energy.gov/eere/buildings/downloads/spawn-energyplus-spawn).

This paper is structured as follows: We first give anoverview of the control design and deployment pro-cess. Next, we present tools developed to conductverification of the correct implementation of the con-trol sequences. Then, we present an example and weclose with discussions and conclusions.

Verification

To put the verification of the control sequence intothe context of the overall workflow, we now describethe process that we follow in OpenBuildingControlfor selecting, deploying and verifying a control se-quence. Given regulations and efficiency targets, la-beled as (1) in Figure 1, a design engineer selects,configures, tests and evaluates the performance of acontrol sequence using building energy simulation (2),starting from a control sequence library that containsASHRAE Guideline 36 sequences, as well as any user-added sequences (3), linked to a model of the mechan-ical system and the building (4). If the sequencesmeet closed-loop performance requirements, the de-signer exports a control specification, including thesequences and functional verification tests expressedin the Controls Description Language CDL (5). Op-tionally, for reuse in similar projects, the sequencescan be added to a user-library (6). This specificationis used by the control vendor to bid on the project (7)and to implement the sequence (8) in product-specificcode. Prior to operation, a commissioning providerverifies the correct functionality of these implementedsequences by running functional tests against the elec-tronic, executable specification in a commissioningand functional verification tool (9). If the verificationtests fail, the implementation needs to be correctedand the tests repeated until the tests pass.

For closed-loop performance assessment, step (2)in the figure, Modelica models of the HVACsystems and controls (Wetter et al., 2014) canbe linked to a Modelica envelope model (Wet-ter et al., 2011) or to an EnergyPlus envelopemodel. This can currently be done through theExternal Interface (http://simulationresearch.lbl.gov/fmu/EnergyPlus/export/index.html). Amore direct coupling is in development through theSpawn of EnergyPlus project. Library of control se-quences, step (3), have been released with the Mod-elica Buildings Library 5.0.0 and more sequences arecurrently added to this library. To export controlsequences in a vendor-neutral format, step (5), atranslator from CDL to a json intermediate format isbeing developed at https://github.com/lbl-srg/

modelica-json. The json intermediate format is in-

tended to be used as input for cost estimation toolsand translators to vendor-specific product lines. Thistranslators also outputs an English language descrip-tion of the control sequence and its block diagramrepresentation.

Methodology

We will now describe how to verify the correct imple-mentation of control sequences. Note that this steponly verifies that the control logic is implemented cor-rectly. Hence, it should be conducted in addition toother functional tests, such as tests that verify thatsensor and actuators are connected to the correct in-puts and outputs, that sensors are installed properlyand that the installed mechanical system meets thespecification.

For clarity, we remind that this verification testswhether the implementation of the control sequenceconforms with its specification. In contrast, valida-tion would test whether the control sequence, to-gether with the building system, is such that it meetsthe building owner’s need, which is done in step (2)in Figure 1.

The process is as follows: A commissioning agent ex-ports trended control inputs and outputs and storesthem in a CSV file. The commissioning agent thenexecutes the CDL specification for the trended inputs,and compares the following:

1. Whether the trended outputs and the outputscomputed by the CDL specification are close toeach other.

2. Whether the trended inputs and outputs leadto the expected sequence diagrams, for example,whether an air handler’s economizer outdoor airdamper is fully open when the system is in freecooling mode.

Technically, step 2 is not needed if step 1 succeeds.However, feedback from mechanical designers indi-cate the desire to confirm during commissioning thatthe sequence diagrams are indeed correct (and hencethe original control specification is correct for thegiven system).

Figure 2 shows the verification flow diagram. Ratherthan using real-time data through BACnet or otherprotocols, set points, inputs and outputs of the actualcontroller are stored in an archive, here a CSV file.This allows to reproduce the verification tests, and itdoes not require the verification tool to have access tothe actual building control system. During the veri-fication, the archived data are read into a Modelicamodel that conducts the verification. The verifica-tion will use three blocks. The block labeled inputfile reader reads the archived data, which may typi-cally be in CSV format. As this data may be directlywritten by a building automation system, its unitswill differ from the units used in CDL. Therefore, the

________________________________________________________________________________________________


886

https://www.energy.gov/eere/buildings/downloads/spawn-energyplus-spawn

https://www.energy.gov/eere/buildings/downloads/spawn-energyplus-spawn

http://simulationresearch.lbl.gov/fmu/EnergyPlus/export/index.html

http://simulationresearch.lbl.gov/fmu/EnergyPlus/export/index.html

https://github.com/lbl-srg/modelica-json

https://github.com/lbl-srg/modelica-json

Figure 1: Overview of the OpenBuildingControl control design, deployment and verification process.

controller plant

controlsignal

disturbances disturbances

++

++

measurementsignal

setpoint

archive

controlspecification

sequencechart

time seriesverification

verification

input filereader

unitconversion

Figure 2: Overview of the verification that tests whether the installed control sequence meets the specification.

block called unit conversion converts the data to theunits used in the CDL control specification.

Next, the block labeled control specification is thecontrol sequence specification in CDL format. This isthe specification that was exported during design andsent to the control provider. Given the set points andmeasurement signals, it outputs the control signals

according to the specification. The block labeled timeseries verification compares this output with trendedcontrol signals, and indicates where the signals differby more than a prescribed tolerance in time and insignal value. The block labeled sequence chart createsx-y or scatter plots. These can be used to verify forexample that an economizer outdoor air damper hasthe expected position as a function of the outside air

________________________________________________________________________________________________


887

temperature.

Below we further describe the blocks in the box la-beled verification.

Modules of the verification test

To conduct the verification, the following models andtools are used.

Input file reader

Input files are read with Modelica.Blocks.Sources.

CombiTimeTable from the Modelica Standard Library.

Unit conversion

Building automation systems store physical quanti-ties in various units. To convert them to the unitsused by Modelica and hence also by CDL, we devel-oped the Modelica package Buildings.Controls.OBC.

UnitConversions that provides blocks to convert be-tween SI units and units that are commonly used inthe HVAC industry.

Sequence chart

To create sequence charts, we developed the Modelicapackage Modelica.Utilities.Plotters. This packageconsists of models that generate time series plots orscatter plots, and save them in one or multiple htmlfiles. The plotters allow for example to plot controlsequences such as the one shown in Figure 5. Theblocks that accumulate the data to be plotted can beactivated and deactivated, for example to plot dataonly when the HVAC system is operating for at least5 minutes.

Time series verification

We developed a cross-platform, C-based soft-ware called funnel (https://github.com/lbl-srg/funnel) to conduct time series comparison. The soft-ware reads two CSV files, one containing the refer-ence data set and the other the test data set. BothCSV files contain time series that need to be com-pared against each other. The comparison is per-formed by computing a funnel around the referencecurve. For this funnel, users can specify the toleranceswith respect to time and with respect to the trendedquantity. The L1-norm is used to build the toler-ance domain. The algorithm then checks whether thetime series of the test data set is within this domain.For points outside the domain, it computes the cor-responding error.

Examples

We will now present examples for the sequence dia-gram verification and the time series verification.

Sequence diagram verification

This is an example of the verification that testswhether an implemented control sequence leads tothe expected relationship between the values of thecontrol signal and the controlled variable, as visual-ized in a sequence diagram.

We verified that an implementation of the Guide-line 36 supply air temperature heating and cool-ing setpoint sequence Buildings.Utilities.Plotters

.Examples.SingleZoneVAVSupply_u leads to the ex-pected sequence diagram as illustrated in Figure 3.While in this example we used the control output ofthe CDL implementation, during commissioning onewould use the control signal from the building au-tomation system.

tem

pera

ture

01 0.5 0 10.50.25 0.75

TMax

TMin

TMin - 1.1 K (= TMin - 2 F)

TSetZon

heating loop signal cooling loop signal

set point forcooling coil

set point for heating coiland for economizer

speed yHeaMax

yCooMax

yMin

TZon- Tout

Figure 3: Control sequence diagram for the variableair volume flow single zone control sequence fromASHRAE Guideline 36.

Figure 4 shows the verification model that we createdusing Modelica. On the left are the blocks that gen-erate the control input. In a real verification, thesewould be replaced with a file reader that reads datathat have been archived by the building automationsystem. In the center is the control sequence imple-mentation. Some of its output is converted to degreeCelsius, and then fed to the plotters on the right thatgenerate a scatter plot for the temperatures and ascatter plot for the fan control signal. The block la-beled plotConfiguration configures the file name forthe plots and the sampling interval.

Simulating the model shown in Figure 4 generatesan html file that contains the scatter plots shown inFigure 5. The plots complies with the specificationprovided in Figure 3.

Sequence output time series verification

The process for the time series verification is as fol-lows: Given a CDL specification of the implementedcontrol sequence, a commissioning agent trends thesequence inputs and the outputs, reads the trendedinputs into the CDL specification, executes the CDLspecification, and verifies CDL computed outputsagainst the trended control outputs. This will be donefor the top-level sequences as well as for lower levelsequences.

In this example we validated a trended output of acontrol sequence that defines the cooling coil valveposition. The cooling coil valve sequence is a part of

________________________________________________________________________________________________


888

https://github.com/lbl-srg/funnel

https://github.com/lbl-srg/funnel

plotConfiguration

delay=0heaCooConSig

+-1

+1

scaTem

x

y

THea_degC

K

degC

TCoo_degC

K

degC

scaYFan

x

y

setPoiVAV

T

u

uHea

uCooTSupHeaEco

TSupCoo

yTZon

TOut

y

TZonSet

TZon

k=273.15 + 28TOut

k=273.15 + 22

uHea

duration=0.25 s

uCoo

duration=0.25 sTSetZon

k=273.15 + 23

Figure 4: Modelica model that verifies the sequencediagram.

Figure 5: Scatter plots that show the control sequencediagram generated from the simulated sequence.

the ALC EIKON control logic implemented in build-ing 33 on the main LBNL campus in Berkeley, CA.The subsequence is shown in Figure 6. It consistsof a proportional-integral (PI) controller that tracksthe supply air temperature, an upstream subsequencethat enables the controller and a downstream outputlimiter that is active in case of low supply air tem-peratures.

We created a CDL specification of the same coolingcoil valve position control sequence, shown in Fig-ure 7, to validate the recorded output. We recordedtrend data in 5 second intervals for the supply airtemperature, the supply air temperature setpoint, theoutdoor air temperature, the VFD fan enable status,and the VFD fan feedback. The output of the subse-quence is the cooling coil valve position.

The input and output trends were processed with ascript that converts them to the format required bythe data readers. The data used in the example be-gins at midnight on June 7 2018. In addition to theinput and output trends, we recorded all parameters,such as the hysteresis offset, shown in Figure 6(a),and the controller gains, shown in Figure 6(b), to use

them in the CDL implementation.

We configured the CDL PID controller parameterssuch that they correspond to the parameters of theALC PI controller. The ALC PID controller imple-mentation is described in the ALC EIKON softwarehelp section, while the CDL PID controller is de-scribed in the info section of the model Buildings.

Controls.OBC.CDL.Continuous.LimPID. The ALC con-troller tracks the temperature in degree Fahrenheit,while CDL uses SI units. An additional implementa-tion difference is that for cooling applications, theALC controller uses direct control action, whereasthe CDL controller needs to be configured to use re-verse control action, which can be done by setting itsparameter reverseAction to true. Furthermore, theALC controller outputs the control action in percent-ages, while the CDL controller outputs a signal be-tween 0 and 1. To reconcile the differences, the ALCcontroller gains were converted for CDL as follows:The CDL PI controller proportional gain, kp,cdl, wasset to

kp,cdl = u kp,alc, (1)

where u = 9/5 is a ratio of one degree Celsius (orKelvin) to one degree Fahrenheit of temperature dif-ference, and kp,alc is the proportional gain of the ALCPI controller, as obtained from the settings illustratedat Figure 6(b). The CDL integrator time constantwas calculated as

Ti,cdl =kp,cdl Ialcu ki,alc

, (2)

where Ialc is the ALC controller interval at which theintegral error gets updated, and ki,alc is the integralgain of the ALC PI controller, shown in Figure 6(b).

Both controllers were enabled throughout the wholevalidation time. Figure 8 shows the Modelica modelthat was used to conduct the verification. On the lefthand side are the data readers that read the input andoutput trends from files. Next are unit converters,and a conversion for the fan status between a realvalue and a boolean value. These data are fed intothe instance labeled cooValSta, which contains thecontrol sequence as shown in Figure 7. The plotterson the right hand side then compare the simulatedcooling coil valve position with the recorded data.

Figure 9, which was produced by the Modelica modelusing blocks from the Buildings.Utilities.Plotters

package, shows the trended input temperatures forthe control sequence (top plot), the trended and sim-ulated cooling valve control signal for the same timeperiod (middle plot), which are practically on topof each other, and a correlation error between thetrended and simulated cooling valve control signal(bottom plot).

The small difference we observed between modeledvs. trended results is due to the following factors:

________________________________________________________________________________________________


889

Figure 6: ALC EIKON specification of the cooling coil valve position control sequence. (a) ALC EIKON outdoorair temperature hysteresis to enable/disable the controller. (b) ALC EIKON PI controller parameters.

Limiter forlow TSupEnbale/Disable

Controller

PI

limPI

yCooValMin

k=uMin

yCooValMax

k=uMax

TOutCooCut - TOutDeltaTOutCooCut

TOutThr

FanFeeCut - FanFeeDeltaFanFeeCut

uFanFeeThr

higLim

TSupMin

k=TSupHigLim

TSupMax

k=TSupHighLimand

andIntErr

min

min()

change

cha

BI

booToRea

pro

uFanSta

uFanFee

TSup

TSupSet

TOut

yCooVal

Figure 7: CDL specification of the cooling coil valveposition control sequence.

• ALC EIKON uses a discrete time step for thetime integration with a user-defined time steplength, whereas CDL uses a continuous time in-tegrator that adjusts the time step based on theintegration error.

• ALC EIKON uses a proprietary algorithm for theanti-windup, which differs from the one used inthe CDL implementation.

Despite these differences, the computed and the sim-ulated control signals show good agreement, which isalso demonstrated by verifying the time series withthe funnel software, whose output is shown in Fig-

TOut_F

TSupSetpoint_F

coolingValveSignal

fanFeedback

fanStatus

TSupply_F

cooValSta

V

k=0.01

percConv plotConfiguration

delay=0

correlation

x

y

timSerRes

t

timSerInp

t

0.5

greEquThrk=0.01

percConv1

from_degF

degF

K

from_degF1

degF

K

from_degF2

degF

K

to_degC

K

degC

to_degC1

K

degC

to_degC2

K

degC cSVWriter

getInstanceName() + ".csv"getInstanceName() + ".csv"5 s

CSV

Figure 8: Modelica model that conducts the verifica-tion.

ure 10. The exceeding error on the control signal isless than 2% and is located during the startup tran-sient after a long shut off period, representing lessthan 2% of the simulated time period.

Discussion

The example shows successful verification based ona small test case. In this example, we started withan actual implementation and created its CDL equiv-alent for the verification. In the workflow shown inFigure 1, the sequence in CDL would be a startingpoint for the implementation of the actual sequence,and therefore this step would not be needed. How-ever, due to differences in the dynamic response ofequipment, some control gains may have to be tuneddifferently in the actual implementation, and somecontrollers may use autotuning for PI gains. This

________________________________________________________________________________________________


890

Trended input signals

Cooling valve control signal: reference trend vs. modeled result

Modeled result/recorded trend correlation

time [h]

time [h]

Trended cooling valve signal

0 10 20 30 40 50 60 70 80 90

10

12

14

16

18

20

22 Supply air temperature, [degC]

Supply air temperature setpoint, [degC]

Outdoor air temperature, [degC]

0 10 20 30 40 50 60 70 80 90

0

0.2

0.4

0.6

0.8

1 Cooling valve control signal, modeled

Cooling valve control signal, trended

0 0.2 0.4 0.6 0.8 1

0

0.2

0.4

0.6

0.8

1

Mod

eled

coo

ling

valv

e si

gnal




time [h]

time [h]


0 10 20 30 40 50 60 70 80 90

10

12

14

16

18

20




0 10 20 30 40 50 60 70 80 90

0

0.2

0.4

0.6

0.8



0 0.2 0.4 0.6 0.8 1

0

0.2

0.4

0.6

0.8

1

Mod

eled

coo

ling

valv

e si

gnal




time [h]

time [h]


0 10 20 30 40 50 60 70 80 90

10

12

14

16

18

20




0 10 20 30 40 50 60 70 80 90

0

0.2

0.4

0.6

0.8



0 0.2 0.4 0.6 0.8 1

0

0.2

0.4

0.6

0.8

1

Mod

eled

coo

ling

valv

e si

gnal

Time [h]

Coo

ling

valv

e si

gnal

Tem

pera

ture

[deg

C]

Figure 9: Plot, generated by plotters in the Modelica model shown in Figure 8, that compares the cooling valvecontrol signal between ALC EIKON and the simulation. Upper: Trended input signals. Middle: Simulated andtrended control signal, which are almost overlapping. Lower: Simulated and trended control signal correlation.

may have to be reflected in the CDL implementa-tion used for the verification, unless the differencesare within the user-configurable tolerances, which forpractical applications can likely be set considerablylarger than what we used to generate Figure 10.

While we conducted our verification offline for threedays, tools could be extended to conduct continuousverification to ensure that sequences are not gettinginadvertently changed or disabled by the operator,such as after a manual override. Such continuous ver-ification could contribute to the sustained high per-formance operation of buildings.

The difficulties that we have encountered while con-ducting the verification using trended data were re-lated to the temporal resolution of the trended dataand to the lack of information about the proprietarycontrol blocks, such as the PI controller. A small sam-ple time interval is required to capture fast changes incontrol input and output signals. For large sequences,this may cause problems as today’s building controlsystems have limited capabilities to trend large datastreams at high frequency. More field verification isrequired to see how big the compounding effect isof model mismatch between CDL and vendor-specific

implementations of certain control blocks, such as aPI controller, differences in control parameters thatmay be tuned in the field, such as PI gains, and com-munication delays of actual hardware.

We also considered in a development version1 the useof performance-oriented tests such as ”Room air tem-perature shall be within the setpoint ±0.5 Kelvin forat least 45 min within each 60 minute window and”Damper signal shall not oscillate more than 4 timesper hour between a change of ±0.025 (for a 2 minutesample period)”. However, discussions with designengineers and commissioning providers showed thatthere is currently no accepted threshold that couldbe used to turn such performance-oriented statementsinto formal, testable requirements. We believe this isa need that should be addressed, in particular as itcan aid commissioning of both, actual implementa-tions as well as simulation models.

Besides these tests, we also considered automaticfault detection and diagnostics methods that wereproposed for inclusion in ASHRAE guidelines, and we

1Modelica Buildings Library, commit https:

//github.com/lbl-srg/modelica-buildings/commit/

454cc7521c0303d0a3f903acdda2132cc53fe45f.

________________________________________________________________________________________________


891

https://github.com/lbl-srg/modelica-buildings/commit/454cc7521c0303d0a3f903acdda2132cc53fe45f



0 50000 100000 150000 200000 250000 300000

0

0.2

0.4

0.6

0.8

1

00.005

0.010.015

0.02

reference

test

error

time (s)

y (-

)er

ror

[y]

Figure 10: Verification of the cooling valve controlsignal y with the funnel software. Error computedwith an absolute tolerance in time of 1 s and a relativetolerance in y of 1%.

considered using methods such as described in Veron-ica (2013) that automatically detect faulty regulation,including excessively oscillatory behavior. However,as it is not yet clear how sensitive these methods areto site-specific tuning, and because field tests are on-going in a NIST project, we did not implement them.

It is also outside the scope of our verification to testwhether the I/O points are connected properly, themechanical equipment is installed and functions cor-rectly, and the building envelope is meeting its spec-ification.

Conclusions

Based on a small example, we demonstrated success-ful verification between an actual control responseand the response computed by a model expressedin the Control Description Language during threesummer days. Having an executable specification ofthe control sequence would allow the buildings in-dustry to conduct formal verification tests that en-sure that the design intent is indeed implemented inthe real control system. As programming errors arethe leading cause of control related problems (Barwiget al., 2002), and because control sequences can affectHVAC annual site energy use by one third (Wetteret al., 2018b), such a formal process seems to be animportant contribution to consistently achieving highperformance buildings.

Tools could be extended to conduct the verificationcontinuously to ensure that sequences are not get-ting inadvertently changed or disabled by the opera-tor, such as after a manual override. Such continuousverification could further contribute to the sustainedhigh performance operation of buildings.

Acknowledgments

This research was supported by the Assistant Sec-retary for Energy Efficiency and Renewable Energy,

Office of Building Technologies of the U.S. Depart-ment of Energy, under Contract No. DE-AC02-05CH11231, and the California Energy CommissionsElectric Program Investment Charge (EPIC) Pro-gram.

We thank Chris Weyandt from LBNL for his supportwith data collection and sequence implementation.

ReferencesASHRAE 2018. ASHRAE Guideline 36-2018 – High

Performance Sequences of Operation for HVACsystems. ASHRAE.

Barwig, F. E., House, J. M., Klaassen, C. J., Arde-hali, M. M., and Smith, T. F. 2002. The nationalbuilding controls information program. SummerStudy on Energy Efficiency in Buildings, PacificGrove, CA. ACEEE.

Fernandez, N. E., Katipamula, S., Wang, W., Xie,Y., Zhao, M., and Corbin, C. D. 2017. Impactsof commercial building controls on energy savingsand peak load reduction. Technical Report 25985,PNNL.

Gnerre, B. and Fuller, K. 2017. When building con-trols veer off course. In Facility Executive, vol-ume 462707, page 32. Group C Media, Inc., TintonFalls, NY.

Mattsson, S. E. and Elmqvist, H. 1997. Modelica – Aninternational effort to design the next generationmodeling language. In Boullart, L., Loccufier, M.,and Mattsson, S. E., editors, 7th IFAC Symposiumon Computer Aided Control Systems Design, pages1–5, Gent, Belgium.

Veronica, D. A. 2013. Automatically detecting faultyregulation in HVAC controls. HVAC&R Research,19(4):412–422.

Wetter, M., Grahovac, M., and Hu, J. 2018a. Controldescription language. In 1st American ModelicaConference, Cambridge, MA, USA.

Wetter, M., Hu, J., Grahovac, M., Eubanks, B., andHaves, P. 2018b. Openbuildingcontrol: Modelingfeedback control as a step towards formal design,specification, deployment and verification of build-ing control sequences. In Proc. of Building Perfor-mance Modeling Conference and SimBuild, pages775–782, Chicago, IL, USA.

Wetter, M., Zuo, W., and Nouidui, T. S. 2011. Mod-eling of heat transfer in rooms in the Modelica”Buildings” library. In Proc. of the 12-th IBPSAConference, pages 1096–1103. International Build-ing Performance Simulation Association.

Wetter, M., Zuo, W., Nouidui, T. S., and Pang, X.2014. Modelica buildings library. Journal of Build-ing Performance Simulation, 7(4):253–270.

________________________________________________________________________________________________


892

veri cation of control sequences within ......that we use to express control sequences and simu-late...

Documents