This paper gives an overview and examples of various approaches to system simulation in buildings. Advantages and disadvantages of the different methods with respect to problems commonly encountered in building performance evaluation are described. Merits and drawbacks of the various methods and approaches are illustrated by case study material. Finally some conclusions and directions for future work are indicated.
Energy simulation in the building context has until recently been focused primarily on the building side of the overall problem domain. However, buildings are really an integration of energy systems comprising not only the whole of building form and fabric, but also plant and various other environmental control systems.
Energy consumption in buildings accounts typically for over 30 - 40% of the national total annual energy consumption. Heating, ventilating, and air-conditioning (HVAC) systems are major energy users in buildings. When considering the costs of a new building, some 30% up to 50% is related to HVAC systems in case of commercial buildings, and 5% up to 10% in case of domestic buildings. Hence, both with respect to environmental impact and economics, the ability to make sensible and well based decisions regarding the choice and design of HVAC systems, is of the utmost importance.
We now see that modelling of HVAC systems and associated (air) flow phenomena in the context of building design and building performance evaluation, is rapidly gaining more and more interest in both the building and environmental engineering communities. This paper intends to give a brief overview of system simulation approaches for building performance evaluation purposes.
An ASHRAE Task Group (ASHRAE 1975) formulated a definition of system (or plant) simulation applicable to "Energy Requirements for Heating and Cooling of Buildings" as:
They also stated that:
In comparison to those for building side issues, the range of modelling and simulation approaches for environmental control systems is much greater. When allowing very coarse distinctions, one could categorize simulation systems and models as: steady-state or dynamic, general or domain specific, stand-alone or integrated, open or closed, conceptual or explicit, process based or component based, sequential or simultaneous, input/output oriented or based on conservation representations, etcetera.
In terms of steady-state versus dynamic, the above mentioned ASHRAE Task Group acknowledged that a future goal would require analysis of dynamic plant performance. However the current consensus amongst the modelling community still seems to be that dynamic system operation can be approximated by series of quasi steady-state operating conditions, provided that the time-step of the simulation is large compared to the dynamic response time of the HVAC equipment. Obviously this is not the case in dynamic control system simulations in which calculations need to be performed almost on a second-by-second time scale. However, in the current case of system simulation for building performance evaluation the latter is usually not necessary. In terms of general versus specific, non-domain specific simulation systems such as MATLAB/SIMULINK, TUTSIM, EASY5x, etc, (instead of full references, a table identifying the author organization of each simulation system is attached) are quite popular in other engineering areas. However they are apparently not often used for building energy simulation; check for instance the proceedings of past conferences on System Simulation in Buildings (held at the University of Liege in 1982, 1986, 1990, and 1994) or the proceedings of past IBPSA conferences (Vancouver 1989, Nice 1991, and Adelaide 1993). As elaborated elsewhere (Schijndel and Hensen 1993), in case of block diagram programs the main reasons for this are:
- unless the building and plant is very strongly simplified, the number of 'blocks' will be very large resulting in excessive CPU usage;
- for the same reasons, the number of 'blocks' and connections will soon become very large, which usually results in administration problems (lost in "spaghetti" structure);
- non-availability of typical building energy 'boundary condition generators' (for instance for processing weather data, predicting insolation and shading, etc);
- non-availability of typical building energy 'result analyzers' (for instance for assessing comfort, converting energy to fuel, etc);
- users have to take care of numerical modelling issues such as time and space discretisation (accuracy and stability) and avoidance of 'algebraic loops' (solvability);
- users first have to learn the syntactical and semantical properties of the program. For these reasons, this paper is only concerned with domain specific approaches.
Although plant oriented programs like TRNSYS and HVACSIM+ could in origin be labeled as stand-alone, these and most currently used building energy simulation packages now aim to enable an integral approach of building and plant.
Open versus closed (meaning extensions can only be achieved via editing and re-compiling existing code) is an important issue in terms of flexibility. However, since most current building energy modelling systems are effectively closed - and due to space constraints - this issue is also not considered here.
One way of discriminating between various approaches to building systems modelling and simulation is by considering the level of abstraction - ranging from purely conceptual to fully explicit - in terms of user specification and/or mathematical/ numerical representation as summarized in Table 1.
Table 1 System simulation abstraction levels
In the case of LEVEL A, specification and representation of plant systems is purely conceptual in that only the room processes are considered. This means that a user may specify whether heat supply or removal is completely from the air (representing air heating or cooling), from within a construction (representing for instance floor heating or a cooled ceiling), or a mix of convection and radiation (in case of for example radiators or convectors). Basically in this approach the heating or cooling loads are estimated assuming some imposed indoor temperature profile, or alternatively the indoor temperatures are estimated in case the assumed heating or cooling capacities would be exceeded. Disadvantages of this approach are that only the room processes are considered. All other processes in the plant (generation, distribution, and control) are assumed to be ideal. Subsequently this approach only results in 'gross' energy requirements and will not be able to predict fuel consumption or energy required for distribution of working fluids. The main advantages of this approach are versatility and flexibility, and a user needs only to know about the room side processes. An example in this category is one of the system simulation approaches on offer in ESP-r.
In the case of LEVEL B, the specification by the user is in terms of (real) systems like variable-air-volume, variable temperature constant volume, constant-volume zone re-heat system, four pipe fan coil, residential wet central heating, etc. Behind the scenes the mathematical and numerical representation is often a combination of Level A and Level C approaches. The main disadvantage of this approach is the restriction imposed on the user due to the limited number of systems which are usually on offer. The main advantage of this approach is the relative ease of problem definition for the user. Examples of simulation systems operating on this level are DOE-2, BLAST, and TSBI3.
In the case of LEVEL C both the specification by the user and the internal representation is in terms of individual plant components like fan, duct, heating coil, boiler, pump, pipe, etc., which are connected to form complete systems. Two main approaches can be distinguished in terms individual component models:
-input-output based, in which each separate part of the system (building zone, single component, sub-system etc.) is represented by an equivalent input-output relationship. These are connected to comprise the whole system in such a way that the output from one component is fed into the next as an input. Advantages of this method are: a mixture of modelling methods (analytical, numerical, internal look-up table, etc.) may be used for the different configuration components thus enabling piecemeal component model development from simple to more complex descriptions; and because of the highly modular structure it is relatively easy to add or change certain component models. In the past most input-output based simulation systems used a sequential solution approach. This means that for each simulation time step, computation starts at a known boundary condition, followed by calculation of each subsequent (according to some prescribed path) component until the whole system is dealt with. Although very simple to implement, this solution technique has a number of serious drawbacks. A sequential approach will cause problems when control dynamics are to be incorporated; when the evaluation of one component needs information of a component further down the calculation stream; and usually also when there are recirculating loops in the system. Different component linking protocols and iterative solution techniques are used to minimize such problems. Currently, many input-output based modelling systems employ special integration techniques to allow for simultaneous solution of the whole system thus avoiding the above mentioned problems. However, since components are handled separately, it is not possible in an input-output based approach to take into account "integral system" aspects such as for instance establishing the operating point of a fan or pump as a function of the pressure-flow characteristics of the rest of the system. Most contemporary system simulation environments use this input-output based modelling technique. Well known examples are TRNSYS and EMGP 3.
-conservation equation based, in which HVAC system modelling is achieved by a modular, component-wise approach, involving representation of plant parts (a part of a component, a component, a sub-system, etc.) by discrete nodal schemes and by the derivation of energy and mass flow equation sets which represent whole-system, inter-node exchanges over time and space dimensions. These equations are essentially time-averaged discretised heat and mass conservation statements which are combined to form the plant system matrix. Thus all equations are solved simultaneously for each simulation time step. The plant system matrix is the system linking protocol and so a number of the problems associated with the sequential approach are overcome. Since, in this approach basically the equations are discretised linear approximations, it is virtually impossible to use this approach for problems involving highly non-linear relations such as those encountered in networks with unknown fluid flow or unknown power flow. So although conceivable in principle, this approach is also not suited for tackling the above mentioned "integral system" problem of the operating point of a fan or pump. Examples of conservation equation based systems are HVACSIM+ and ESP-r.
In the case of LEVEL D the specification by the user is in terms of individual components linked to form complete systems as in the case of Level C. However, at this level the internal representation is further divided in for instance energy balance concepts, flow balance concepts, power balance concepts, etc. Each balance is then solved simultaneously for the whole system. This problem partitioning technique has several advantages. The first advantage is the marked reduction in overall matrix dimensions and degree of sparsity. A second advantage is that it is possible to easily remove partitions as a function of the problem in hand; for example when the problem incorporates energy balance only considerations, flow balance only considerations, energy + flow, flow + power, and so on. But the most important advantage is that different partition solvers can be used which are well adapted for the equation types in question - highly non-linear, differential and so on, thus enabling solution of "integral system" prob- lems which cannot be handled at level C.
Obviously there are often dominating thermodynamic and/ or hydraulic couplings between the different partitions. If a variable in one partition (say air temperature in a duct) depends on a variable of state solved within another partition (say the air flow), it is important to ensure that both values match in order to preserve the thermodynamic integrity of the system. In the case of ESP-r - which can also operate on this Level D - two methods are offered to handle these couplings: (1) a time step control facility, and (2) iteration mechanisms.
As elaborated later, the main disadvantages of levels C and D are the required user knowledge and effort, and the amount and (non-)availability of the plant definition parameters. In reality the distinctions between these levels of abstraction are not so clear cut. Often programs operate on different levels, or combine different levels.
In reality there are also more levels than indicated above: component models may be combined to form meta-components, or alternatively component models can be broken up into smaller parts (see eg Chow 1995).
Figure 1 Role of building and plant models (Clarke 1985)
Obviously when the level of abstraction changes from conceptual to more and more explicit, the number of parameters which need to be supplied increase dramatically; this is often a problem in practice since several of the values and/or parameters may not be known to the user. Also the CPU requirements will increase. On the other hand the amount and diversity of output will increase resulting in a greater potential for solving a particular problem.
In terms of which level of approach is more appropriate for which type of building performance evaluation problem, and referring to Figure 1 (Clarke 1985), clarke hilger 1985 the level A and level B approaches are particularly suited for building design problems related to reduction of energy requirement, whereas level C and level D approaches are needed for plant design problems related to reduction of energy or fuel consumption. In general, the former type of problem is much more common in practice.
Explicit system simulation depends heavily on available plant component models. Important literature sources with respect to plant component modelling are by Stoecker (1975), Hanby and Clarke (1988), Lebrun and Liebecq (1988), stoecker procedures 1975 hanby clarke catalogue 1988 lebrun liebecq synthesis 1988 a compilation by various researchers (IEA 1988), iea booklets 1988 and for instance proceedings of past conferences on System Simulation in Buildings (held at the University of Liege in 1982, 1986, 1990, and 1994), of past IBPSA conferences (Vancouver 1989, Nice 1991, and Adelaide 1993), and of past ASHRAE bi-annual conferences. Other sources are the documentation related to various simulation systems like for instance TRNSYS, EMGP 3, ESP-r, and HVACSIM+.
In case one wants to re-use these models in a particular simulation environment, serious reformulation is usually necessary. Developing or adjusting models is often difficult and time consuming. This is the background for relatively recent incentives to facilitate this process for instance through establishment of data-bases of component models (Lebrun & Liebecq 1988, Brandemuehl et al 1992, Bourdouxhe et al 1994). lebrun liebecq 1988 user ghent Brandemuehl Gabel Andresen 1992 ASHRAE toolk- it secondary HVAC Bourdouxhe Grodent Lebrun 1994 ASHRAE toolkit primary HVAC Another important project which aims to make reuse of models easier is the development of a "neutral model format" (Sahlin, Bring & Kolsaker 1995), sahlin Bring Kolsaker 1995 future trends nmf which should enable easy exchange of component models (via specific translators) between various simulation environments.
Merits and drawbacks of the various methods and approaches is best illustrated by case study material. What follows is a typical example for each level of abstraction. Although these examples could have been generated using a variety of simulation environments, the examples presented here are all based on ESP-r for obvious reasons. Due to space constraints the case descriptions need to be very compact.
This concerns a small three zone building where the objective was to compare indoor temperatures and energy requirements assuming floor heating and air heating respectively.
Figure 2 Model of the building
In keeping with early design investigations ESP-r provides a level of plant systems which are `ideal' in their representations ie. they have no inertia or time dependent characteristics, and operate on the building side only. At this level, the "plant" is simply described as a building control function (which may change over time) which is defined by: sensor location, actuator location, and control law. The sensor (measuring any nodal state variable, an outdoor condition, or some derived combination of the previous) transmits some variable to the control law (an algorithm representing control characteristics, for example: building pre-heat, fixed heat injection or extraction, PID control, optimum start controller, etc). Actuators exist to transmit the output of a controller to some part in the building.
Figure 3 Display-area air temperature and system load for the air and floor heating system
In the current case study, floor heating is simply modelled by placing the "actuator" of a building control function to be positioned within the floor. Air heating is modelled by placing the "actuator" at the air node. Some simulation results (covering 5 working days plus 2 days off) are shown in Figure 3. From the results it can be concluded that (1) in order to reach the desired set-points the floor heating system needs to have a higher capacity than the air system, (2) deviation from set-points are likely to be higher in case of floor heating, and (3) in the current design the energy requirement is much higher in case of the floor heating. From this it follows for the overall design: in case of floor heating the insulation of the floor should be increased, otherwise both the installed heating capacity, and the heating energy requirement will be too high, and in addition to that the response of the heating system will be much too low.
Although this case study represents a simplistic approach to system simulation (for which almost no parameters were needed to describe the system), some valuable conclusions could be drawn with respect to the overall design.
This case study concerns the applicability of displacement ventilation (Hensen and Hamelinck 1995). Of particular interest were the design constraints and energy consequences relative to a mixing ventilation system. The modelling of both systems is schematically indicated in Figure 4. For modelling the displacement systems, we used a mix of the level A and level C approach and it was also necessary to incorporate an air flow network.
Figure 4 Schematic of displacement and mixing ventilation
Validation with experimental results showed good agreement. Using models of the two types of ventilation system a number of simulations were carried out for a "standard" office module (3.6 x 5.4 x 2.7 $m sup 3$, one outside wall, 40% double glazing) and assuming a Dutch climatic reference year.
The most important design constraint for application of displacement ventilation turned out to be the casual gains due to people, lighting and office appliances.
The overall annual energy consumption for cooling can be up to 10% lower in case of a displacement system when the casual gains are relatively low. However, at casual gains higher than 30 $W / m sup 2$ the advantage, in terms of cooling energy consumption, of a displacement system disappears. At casual gains above about 35 $W / m sup 2$, and a ceiling height of 3 ... 3.5 $m$, a displacement system needs an additional cooled ceiling. In that case, the energy consumption for cooling will be considerably higher than in case of a mixing system only.
In the current study, electricity consumption was not taken into account. As evidenced by other authors the difference between the systems decreases when electricity consumption is included.
This case study represents a less simplistic approach to system simulation (still almost no parameters were needed to describe the actual system). Although an important aspect such as fan electricity consumption could not be taken into account on this level of abstraction, some valuable conclusions could still be drawn with respect to the overall performance.
This case study also concerns building and plant thermal interaction.
Figure 5 The room and heating system
It was inspired by findings from experiments with a wet central heating system controlled by a mechanical room thermostat. The results showed that decreasing the thermostat's acceleration heating (which is used to raise the temperature of the sensitive element more rapidly towards the switch-off temperature in order to decrease the room air temperature differential) resulted in both larger air temperature swings, but - more surprisingly - also in much lower fuel consumption. For information regarding the acceptability of the resulting indoor temperature fluctuations and on the potential energy saving of this strategy, the reader is referred to (Hensen 1990) or (Hensen 1993) respectively.
Imagine a building and plant configuration as schematically shown in Figure 5. The living room is serviced by (part of) a wet central heating system, comprising: a (two node model) radiator, a (two node model) high efficiency condensing boiler (scaled down to accommodate the current single radiator system), a pump delivering a fixed water flow rate, piping as indicated, and a mechanical room thermostat located in the living room. Although the system part of the model comprises only 6 components, already 51 parameters are needed in order to define these components.
Figure 6 Thermal load and sustained deviation between air temperature and set point (21.5 C). Note enlarged y-axis scaling!
The degree of acceleration heating is one of the primary parameters with respect to resulting room air temperatures. There is however yet another factor which influences the room temperature: the thermal load of the system (which affects the cycle frequency of the boiler). This is clearly demonstrated by Figure 6 which shows the room air temperature and its deviation from the (constant !) thermostat set-point in relation to the ambient temperature. The latter is obviously a measure for the thermal load imposed on the heating system. When compared to average climatic conditions for The Netherlands, the data for January 13 represent an extremely cold day, while the data for January 15 represent a fairly average day. Aside from the (elsewhere reported) consequences for fuel consumption, it will be clear from the results that for a mechanical thermostat a set-point indication in terms of air temperature is really not appropriate.
This case study represents an explicit approach to system simulation. Relative to the previous case studies, the number of parameters needed to describe the actual system is very high. However, the information to be gained from the simulations is also much richer. In contrast to the previous levels where simulations are based on some presumed indoor temperature profile, at this level of abstraction it is actually possible to predict air temperatures and fuel consumption given the building and plant configuration.
As a final example consider the case of a low energy house as schematically shown in Figure 7 (Clarke, Hensen and Kelly 1995).
Figure 7 The low energy house
The features of the building include mechanical ventilation, heat recovery, photovoltaic panels incorporated into the roof, high levels of insulation and a conservatory acting as a solar ventilation pre-heat. The model consists of four zones: living area, bedroom, loft space and conservatory. Obviously the building is insulated to a very high level. The floor of the conservatory has a high thermal mass to aid heat storage and also to reduce temperature fluctuations which may have a detrimental effect on comfort in the adjoining living-space. The building occupants are absent for most of the day; thermal and electrical loads are therefore most pronounced in the morning and in the evening.
The ventilation system consists of inlet and outlet fans passing through a plate heat exchanger unit. The supply air is heated to comfort requirements by a battery of electrically heated coils. Solar heated air from the conservatory is transferred to the living space in the morning when the temperature of the conservatory air is greater than the living space air and living space air temperature air is below the comfort point.
Six solar panels are located on the south facing roof of the structure. Each panel has a maximum power output of 30 W. The data for the panels is taken from manufacturer's data. One of the questions to be asked is whether the panels will produce enough power to drive the fans in the ventilation system.
Figure 8 Power simulation output
In this case the system side of the model comprises a plant energy balance network, air flow network, and a power flow network. The reason for this is that we wanted to investigate "integral system" aspects such as performance of the conservatory fans both as a function of air flows and pressures elsewhere in the configuration, and as a function of the power output of the photovoltaic panels.
The total number of plant components is 20 and the number of parameters describing all plant components is 238.
The simulation was run over the period 20 - 26 April, a period where useful solar energy gains can be used to reduce building energy consumption. At this level of representation the variety of results is very big, and ranges from temperatures to energy flows, mass flows, pressures, electric currents and voltages, etc. As an example Figure 8 shows some results in terms of the electrical components within the configuration. From those results it is obvious that the photovoltaics will provide only a minimal contribution towards tèe energy savings of the building. In this particular building the bulk of energy savings will come from the passive solar features and heat recovery. Here no further conclusions will be given with respect to this particular building.
This case study represents an even more explicit approach to system simulation. Relative to the previous case study, the number of necessary plant parameters is again much higher. The reason to go to this level of representation is the actual problem being posed. In order to investigate the "integral system" issues as present in this case study, this level of detail is simply needed.
After indicating the need, this paper has described and demonstrated various approaches to system simulation for building performance evaluation. An attempt was made to illustrate merits and drawbacks by case study material. Although - especially in the early design stages - conceptual plant modelling has a lot of advantages, it must be clear that explicit approaches have much more potential for solving real world problems related to for instance building and plant interaction.
It may be concluded that - except for highest level conceptual modelling - plant simulation is rather complicated from a user point of view. Not surprisingly the complications grow with the level of explicitness. This is because at the same time, the required/ assumed HVAC system knowledge of the user increases, the sheer number of plant definition parameters grows, the availability of data for those parameters decreases (manufacturers often do not have the data available which is needed for the models), and analyzing the (increasing amount of) results becomes more complicated.
Also from a developer point of view the complications (and challenges !) increase with the level of explicitness and detail. This is due to the physics underlying say a component, but more often it is due to the interactions with other parts of the HVAC system or with the building. Especially with regard to the latter, it is important that when system simulation is used for building performance evaluation the building should not be represented as just another plant component imposing a load on the system, but should be represented taking into account all energy and mass flow paths by modelling the overall system in an integrated fashion.
In the area of system simulation there is just a lot of work to be done. When compared to the building side, one could argue that every "new" component is like a new type of building in itself. We should not only work towards enabling re-use of existing component models (ie co-operation at source code level by exchanging component models (for instance incorporation of TRNSYS models in ESP-r (Aasem 1993)) or in a more generic way by expressing models in NMF (Sahlin et al 1995)), and towards enabling coupling of programs on the product model and results level (as in the COMBINE initiative (Augenbroe 1994)), but also towards concurrent coupling of programs at run-time level. The latter can be done for domain specific programs but would potentially have much more scope (in terms of research, application, education, etc) if it was also done for general non-domain specific simulation environments.
Building energy simulation is now ready to be applied on a wide scale in engineering education and research, and in practice.
However, in many respects, system simulation for building performance evaluation is only just starting. There are trends and initiatives towards bringing system simulation to practice (see for instance (Lebrun 1994)).
It might be worthwhile considering whether an organization such as IBPSA could (and wants to) also play a role in these trends, for instance by organizing a concerted action in this area or simply by setting up a special interest group in this field.
Author organizations of simulation systems mentioned in this paper:
BLAST University of Illinois, Ubrana-Champaign Il, USA
DOE-2 University of California, Berkeley CA, USA
EASY5x Boeing Computer Services, USA
EMPG3 University of Leuven, Heverlee, Belgium.
ESP-r ESRU, University of Strathclyde, Scotland
HVACSIM+ National Institute of Standards and Technology, Gaithersburg MD, USA
Matlab/Simulink The Math Works Inc., USA
TRNSYS University of Wisconsin, Madison, USA
TSBI3 Danish Building Research Institute
Tutsim Twente University of Technology, Enschede, The Netherlands
