Journal of Building Performance Simulation

ISSN: 1940-1493 (Print) 1940-1507 (Online) Journal homepage: www.tandfonline.com/journals/tbps20

Functional mock-up unit for co-simulation import in

EnergyPlus

Thierry Nouidui, Michael Wetter & Wangda Zuo

To cite this article: Thierry Nouidui, Michael Wetter & Wangda Zuo (2014) Functional mock-up
unit for co-simulation import in EnergyPlus, Journal of Building Performance Simulation, 7:3,
192-202, DOI: 10.1080/19401493.2013.808265

To link to this article: https://doi.org/10.1080/19401493.2013.808265

Published online: 19 Jun 2013.

Submit your article to this journal

Article views: 1599

View related articles

View Crossmark data

Citing articles: 24 View citing articles

Full Terms & Conditions of access and use can be found at

https://www.tandfonline.com/action/journalInformation?journalCode=tbps20
Journal of Building Performance Simulation, 2014
Vol. 7, No. 3, 192–202, http://dx.doi.org/10.1080/19401493.2013.808265

Functional mock-up unit for co-simulation import in EnergyPlus

Thierry Stephane Nouiduia∗ , Michael Wettera and Wangda Zuob
a Lawrence Berkeley National Laboratory, Building Technology and Urban Systems, One Cyclotron Road, Berkeley, CA 94720, USA;
b Department of Civil, Architectural, and Environmental Engineering, University of Miami, Miami, FL, USA

(Received 8 November 2012; final version received 21 May 2013 )

This article describes the development and implementation of the functional mock-up unit (FMU) for co-simulation import
interface in EnergyPlus. This new capability allows EnergyPlus to conduct co-simulation with various simulation programs
that are packaged as FMUs. For example, one can model an innovative Heating, Ventilation, and Air Conditioning (HVAC)
system and its controls in Modelica, export the HVAC system and the control algorithm as an FMU, and link it to a model of
the building envelope in EnergyPlus for run-time data exchange. The formal of FMUs is specified in the functional mock-up
interface (FMI) standard, an open standard designed to enable links between disparate simulation programs. An FMU may
contain models, model description, source code, and executable programs for multiple platforms. A master simulator – in
this case, EnergyPlus – imports and simulates the FMUs, controlling simulation time and coordinating the exchange of data
between the different FMUs. This article describes the mathematical basis of the FMI standard, discusses its application to
EnergyPlus, and describes the architecture of the EnergyPlus implementation. It then presents a typical workflow, including
pre-processing and co-simulation. The article concludes by presenting two use cases in which models of a ventilation system
and a shading controller are imported in EnergyPlus as an FMU.
Keywords: functional mock-up interface; functional mock-up unit; co-simulation; building simulation

1. Introduction run-time. We will now discuss three different ways to

EnergyPlus (Crawley et al., 2001) is a whole building perform co-simulation with EnergyPlus.
energy simulation program that models heating, cooling, The first approach is a one-to-one coupling (Figure 1).
lighting, ventilation, and water use in buildings. Energy- In this approach, specific interfaces need to be implemented
Plus has been used for building design (Graça et al., 2004; in EnergyPlus and program B to enable the communication
Wang et al., 2009), fault detection and diagnostics (Jacob between the two programs. These interfaces can only be
et al., 2010; Pang et al., 2012), and energy standard devel- used for the co-simulation between EnergyPlus and pro-
opment (Borgeson and Brager, 2011; Thorton et al. 2011). gram B. To link EnergyPlus with a program C, another set
Since the focus of EnergyPlus is whole annual building of interfaces have to be developed in both programs. The
energy simulation, it is not designed to study the con- one-to-one approach has the benefit to enable a fast com-
trols performance of HVAC systems, to perform detailed munication between the simulation programs. However,
daylighting analysis, or detailed temporal distribution of one has to modify the EnergyPlus code whenever Energy-
indoor airflow and contaminants that are better addressed Plus needs to be linked to another program. Furthermore,
by other simulation programs. To extend the capability of for many practical co-simulations, the computing time is
EnergyPlus for building simulation, EnergyPlus has been dominated by the simulation and not by the data exchange.
linked through co-simulation to various programs from Therefore, fast data exchange is not a high priority.
other domains, such as advanced lighting and daylighting Using the one-to-one approach, (Zhai and Chen, 2005;
simulation, computational fluid dynamics (CFD), multi- Zhai et al., 2002) coupled EnergyPlus with a CFD tool. The
zone airflow network, and HVAC system and controls, for CFD tool was used in this context to provide more accurate
co-simulation. convective heat transfer coefficients between the room air
Co-simulation refers in this context to a technique that and the walls for the load calculation in EnergyPlus. Huang
allows individual component models described by differ- et al. (1999) coupled EnergyPlus with a Conjunction of Mul-
ential algebraic or discrete equations to be simulated by tizone Infiltration Specialists (COMIS) multizone airflow
different simulation programs running simultaneously and network model. Using the boundary condition provided by
exchanging data that depend on state variables during EnergyPlus, COMIS calculated the airflow that was then

∗ Corresponding author. Email: [email protected]

This work was authored as part of the Contributor’s official duties as an Employee of the United States Government and is therefore a work of the United States Government.
In accordance with 17 U.S.C. 105, no copyright protection is available for such works under U.S. Law.
 Journal of Building Performance Simulation 193

Figure 3. Co-simulation of EnergyPlus with programs B and C

using a standard interface approach.

Figure 1. Co-simulation of EnergyPlus with programs B and C EnergyPlus, implement the same standard interface for co-
using a one-to-tone approach. simulation. Since the interface is standardized, it allows
direct coupling of various simulation programs. Till date,
standard interfaces have been used in different applica-
tion domains to couple simulation programs (Accelera,
2012; MODELISAR Consortium, 2012a). Although this
approach combines the advantages of both one-to-one
and middleware approaches, it has not yet been imple-
mented in EnergyPlus. Similar to the one-to-one approach,
it enables the direct link between the simulation programs.
By eliminating the transaction layer, the standard interface
approach is more efficient and less complex than the mid-
dleware approach. This contribution describes the standard
interface which has been implemented in EnergyPlus for
co-simulation.
Figure 2. Co-simulation of EnergyPlus with programs B and C
using a middleware approach. The standard interface we selected for EnergyPlus is
the functional mock-up interface (FMI) standard, which is
an open standard for model exchange and co-simulation
used by EnergyPlus in subsequent heat balance calcula- (MODELISAR Consortium, 2012a). Until 2012, the FMI
tions. Nghiem (2010) also used the one-to-one approach to has been supported by more than 35 (MODELISAR Con-
develop a tool that allows coupling EnergyPlus with Matlab sortium, 2012b) modelling and simulation environments. In
(MathWorks, 2012a) and Simulink (MathWorks, 2012b). the following, we will briefly introduce the FMI standard.
The second approach is a middleware coupling We will then discuss the implementation of the standard in
(Figure 2). The middleware acts as co-simulation mas- EnergyPlus. After that we will show two examples which
ter that orchestrates the simulation and manages the data use the FMI to link EnergyPlus with another program for
exchange between the different simulation programs. In this co-simulation.
approach, each simulation program needs to implement a
specific interface to the middleware. As long as a program
can communicate with the middleware, it can communicate 2. Nomenclature
with any programs linked to the middleware. Compared to (1) We denote by N = {0, 1, 2, . . .} the set of natural
the one-to-one approach, the middleware approach needs numbers and by R the set of real numbers.
significantly less effort to enable co-simulation among (2) Let Xkn be a set containing a sequence {xi }ki=0 for
various tools. some n, k ∈ N and x ∈ Rn . We denote by Xnk the set
Currently, the Building Controls Virtual Test Bed of all k + 1 element sequences in Xkn .
(BCVTB) (Wetter, 2011) is the only middleware which (3) f (·) denotes a function, where (·) stands for the
enables the co-simulation of EnergyPlus with other soft- undesignated variables.
ware and hardware. Through the BCVTB, EnergyPlus can (4) f (x) denotes the value of f (·) for the argument x.
do co-simulation with programs such as Matlab, Simulink,
Dymola (Dassault Systemes AB, 2012), Radiance (Larson
and Shakespeare, 2012), and ESP-r (Clarke, 2012). The 3. FMI standard
BCVTB can also connect to hardware through the BAC- The FMI is the result of the Information Technology for
net stack (ASHRAE, 2004) or through the analogue/digital European Advancement (ITEA2) project MODELISAR.
interface. The FMI standard is a tool-independent standard to sup-
The third approach is to standardize the co-simulation port both model exchange and co-simulation of dynamic
interface (Figure 3). All simulation programs, including models using a combination of XML files, C-header files,
194 T.S. Nouidui et al.

and C-code in source or binary form. The FMI standard run the FMUs, typically together with other models. An
consists of two main parts: FMU may either require the simulator to perform numerical
integration (model exchange) or be self-integrating (co-
• The first part is FMI for model exchange. This part of simulation). An FMU is distributed in the form of a zip
the standard specifies how a modelling environment file that contains
can generate C-code of a dynamic system model that
can be utilized by other modelling and simulation
• shared libraries, which contain the implementation
environments. The exported model is independent
of the FMI functions and/or source code of the FMI
of the target simulator because it does not use a
functions,
simulator-specific header file as in other approaches
• an XML file, also called the model description file,
(MODELISAR Consortium, 2010b).
which contains the variable definitions as well as
• The second part is FMI for co-simulation, an inter-
meta-information of the model,
face standard for coupling two or more simulation
• additional files such as tables, images, or documen-
programs in a co-simulation environment. The data
tation that might be relevant for the model.
exchange between sub-systems is restricted to dis-
crete communication points in time. In the time
between two communication points, the sub-systems Figure 4 shows a schematic view of the structure of a
are solved independently from each other by their zip file of an FMU with the model description file, shared
individual solver. A master algorithm controls the libraries for different target machines, as well as additional
data exchange between sub-systems and the synchro- resource information such as documentation, bitmaps, and
nization of all slave simulation programs (slaves). All tables.
information about the slaves, which is relevant for the Figure 5 shows the dataflow of model exchange and co-
communication in the co-simulation environment, is simulation using the FMI standard. For model exchange,
provided in a slave-specific XML file (MODELISAR simulation program A will export an FMU through its FMU
Consortium, 2010a). for model exchange export interface. The exported FMU is
called “FMU for model exchange”. It does not include any
A simulation model or program which implements the numerical solver. The FMU for model exchange is then
FMI standard is called functional mock-up unit (FMU). imported into simulation program B through the FMU for
An FMU comes along with a small set of easy-to-use model exchange import interface. The numerical solver of
C-functions (FMI functions) whose input and return argu- simulation program B is used to solve both sub-systems A
ments are defined by the FMI standard. These C-functions and B.
can be provided in source and/or binary form. The FMI For co-simulation, simulation program A will export
functions are called by a simulator to create one or more an FMU through its FMU for co-simulation export inter-
instances of the FMU. The functions are also used to face. The exported FMU is called “FMU for co-simulation”.

Figure 4. Structure of a zip file of an FMU.

 Journal of Building Performance Simulation 195

Figure 5. Dataflow of model exchange and co-simulation using the FMI standard.

It contains the model and numerical solver that can exe- FMUs and EnergyPlus. In the current implementation, the
cute independently. The FMU for co-simulation is then data exchange is done at the beginning of each zone time
imported into simulation program C through the FMU step. There is no iteration between the FMUs and Ener-
for co-simulation import interface. Simulation program C gyPlus, and the synchronization of the data exchange is
can then use its co-simulation master algorithm to link controlled by EnergyPlus.
sub-systems A and C.
Since this paper is focusing on co-simulation, we use
“FMU” and “FMU import” as abbreviations for “FMU 5. Architecture of the FMU import
for co-simulation” and “FMU for co-simulation import”, Figure 6 shows the architecture of the connection between
respectively, below. EnergyPlus and two FMUs. EnergyPlus imports the FMUs
that connect to its external interface. These FMUs are
generated by external simulation environments that imple-
4. Implementation ment the FMU for co-simulation export interface. See
EnergyPlus is a simulation program written in Fortran. It MODELISAR Consortium (2012a) for a list of simulation
consists of many program modules that calculate the energy programs that export FMUs. In the external interface, the
consumption of a building. In EnergyPlus, all program mod- input/output signals that are exchanged between the FMUs
ules are controlled by a Solution Manager (DOE, 2011a). and EnergyPlus are mapped to EnergyPlus objects.
The loops are divided into supply and demand sides, and the The external interface can map to four new EnergyPlus
solution scheme generally relies on successive substitution input objects called:
iteration to reconcile supply and demand. To link Ener-
gyPlus to one or multiple FMUs, the EnergyPlus module • ExternalInterface:FunctionalMockup
ExternalInterface (DOE, 2011b) has been modi- UnitImport:To:Schedule,
fied so that data can be exchanged during run-time between • ExternalInterface:FunctionalMockup
EnergyPlus and FMUs. A shared library compiled from C UnitImport:To:Actuator,
has been developed for this. This library contains all func- • ExternalInterface:FunctionalMockup
tions needed to interface with FMUs. The primary functions UnitImport:To:Variable, and
in this shared library are called at run-time to unzip the • ExternalInterface:FunctionalMockup
FMUs, instantiate, initialize, set, and get values of defined UnitImport:From:Variable.
variables and execute single time steps. In addition to the
libraries, the EnergyPlus input data dictionary has been The ExternalInterface:FunctionalMockup
extended with four new objects. These objects are used to UnitImport:To:Schedule object can be used to
map the input/output signals that are exchanged between the overwrite schedules and the ExternalInterface:
196 T.S. Nouidui et al.

Figure 6. Architecture of the FMU import.

FunctionalMockupUnitImport:To:Actuator 7. Mathematics of data exchange for the FMU import

and ExternalInterface:FunctionalMockup This section describes the data exchange between Ener-
UnitImport:To:Variable objects can be used in gyPlus and FMUs. Prior to describing the data exchange
place of energy management system (EMS) actuators between EnergyPlus and FMUs, some definitions and ter-
and EMS variables. These objects have similar func- minologies used in the remainder of this document will be
tionality as the objects Schedule:Compact, Energy introduced.
ManagementSystem:Actuator and Energy Consider a model that is described by a system of dif-
ManagementSystem:GlobalVariable, except that ferential algebraic equations. We say that a variable is a
their numerical value is obtained from the external inter- differential variable if its derivatives are present in the dif-
face at the beginning of each zone time step and will remain ferential algebraic equations. Otherwise, we say that the
constant during the zone time step. The external interface variable is an algebraic variable (Fabian et al., 2008).
also uses the ExternalInterface:Functional Because in subsequent discussions, we will distinguish
MockupUnitImport:From:Variable object which between algebraic and differential variables, we now intro-
reads EnergyPlus objects Output:Variable and duce a new notation for different system of equations that
EnergyManagementSystem:OutputVariable to involve algebraic and differential variables. Let n, m, q ∈ N,
send data from EnergyPlus to FMUs. and let x1 ∈ Rn , x2 ∈ Rm , and u ∈ Rq .

• If x1 and x2 are differential variables, then the system

6. Workflow of the FMU import is
We identified two major steps when conducting co- F(ẋ1 , x1 , ẋ2 , x2 , u, t) = 0,
simulation with FMUs in EnergyPlus: pre-processing and
where
co-simulation. The pre-processing step generates a section
of an EnergyPlus input file that can be used to configure the F : Rn × Rn × Rm × Rm × Rq × R → Rn+m .
FMU import. The input file defines the input and output vari-
ables for both EnergyPlus and the FMUs. The co-simulation • If x1 is a differential variable and x2 is an algebraic
step performs co-simulation. variable, then the system is
To support the user in the pre-processing step, we devel-
oped an FMU parser which unzips and extracts relevant G(ẋ1 , x1 , x2 , u, t) = 0,
information from the model description file of the FMU
and writes them in a temporary EnergyPlus input file. The where
model description file is an XML file which contains the
definition of all variables in the model in a standardized G : Rn × Rn × Rm × Rq × R → Rn+m .
way. The FMU parser is a code written in C that includes
Expat (Clark et al., 2011), which is an XML parser library • If x1 is an algebraic variable and x2 is a differential
written in C. variable, then the system is
In the co-simulation step, the user launches the simula-
tion by invoking EnergyPlus with the EnergyPlus input file. H (x1 , ẋ2 , x2 , u, t) = 0,
After EnergyPlus detects that the FMU import is activated,
it will call the FMU parser and unzip the related FMU for where
executable files and description files. After that, EnergyPlus
will conduct the co-simulation with FMUs. H : Rn × Rm × Rm × Rq × R → Rn+m .
 Journal of Building Performance Simulation 197

since the third and fourth cases will require the FMU to
be solved numerically in the iteration solver loop of Ener-
gyPlus. This will necessitate (a) the ability of the FMU
to reject time steps (MODELISAR Consortium, 2010a),
which is currently not supported by major tool vendors that
export FMUs, and (b) the ability of EnergyPlus to save its
state variables and reset them when needed. This capability
is hard to achieve in EnergyPlus, as it does not have a data
structure for storing and resetting state variables. In the next
sections, we describe and discuss the mathematics used for
the data exchange in use cases 1 and 2.
Figure 7. System with one FMU linked to EnergyPlus.

7.1. Use case: linking EnergyPlus and FMU through

Table 1. Use cases with different system configurations.
differential variables
Use cases EnergyPlus FMU This use case could be for an application where a wall with
a phase change material (PCM) is modelled in an FMU and
1 Model1 Model2
(differential variable) (differential variable)
linked to a room model in EnergyPlus. The room dry-bulb
2 Model1 Model2 temperature is the differential variable in EnergyPlus and the
(differential variable) (algebraic variable) temperature of the wall with PCM is the differential variable
3 Model1 Model2 in the FMU. Each system solves a differential equation that
(algebraic variable) (differential variable) is connected to the differential equation of the other system.
4 Model1 Model2
For simplicity, we assume that y1 (·) = x1 (·) and y2 (·) =
(algebraic variable) (algebraic variable)
x2 (·). The systems are described by the ordinary differential
equations
• If x1 is an algebraic variable and x2 is an algebraic
variable, then the system is 0 = f 1 (ẋ1 , x1 , x2 ), with x1 (0) = x1,0 , (1)
0 = f (ẋ , x , x ),
2 2 2 1
with x (0) = x .
2 2,0
(2)
I (x1 , x2 , u, t) = 0,
where The first system computes, for k ∈ {0, . . . , N } and some
F̃ 1 : Xnk × Xm
k × Rk+1 → R , the sequence
n

I : Rn × Rm × Rq × R → Rn+m .
x1 (tk+1 ) = F̃ 1 (x1k , x2k , t k+1 ), (3)
Throughout this section, let N denote the number of time
steps and let tk with k ∈ {0, . . . , N } denote the synchroniza- k ×
and, similarly, simulator 2 computes for some F̃ 2 : Xm
tion time instants. We will use the superscripts 1 and 2 to Xnk × Rk+1 → Rm ,
denote the variables and the functions that compute the next
state variable of the simulators 1 and 2, respectively. x2 (tk+1 ) = F̃ 2 (x2k , x1k , t k+1 ), (4)
Figure 7 shows a case where an FMU is linked to an
EnergyPlus model for co-simulation. The FMU and Ener- with initial conditions x1 (0) = x1,0 and x2 (0) = x2,0 . The
gyPlus could be linked through differential or algebraic functions F̃ 1 (·, ·, ·, ·) and F̃ 2 (·, ·, ·, ·) are used to compute
variables. the values of the state variables at the new time instant.
Table 1 shows the different system configurations that To advance from time tk to tk+1 , each system uses its own
are possible. time integration algorithm. At the end of the time step, Ener-
gyPlus sends the new state x1 (tk+1 ) to the FMU and receives
• In the first case, the variables x1 and x2 are differential the state x2 (tk+1 ) from the FMU. The same procedure is
variables in EnergyPlus and in the FMU. done by the FMU.
• In the second case, the variable x1 is a differential
variable and the variable x2 is an algebraic variable.
• In the third case, the variable x1 is an algebraic 7.2. Use case: linking EnergyPlus and FMU through
variable and the variable x2 is a differential variable. algebraic and differential variables
• In the fourth case, the variable x1 is an algebraic This use case could arise in an application where a fan is
variable and the variable x2 is an algebraic variable. modelled in an FMU and is linked to a room model in Ener-
gyPlus. The room temperature is the differential variable
The current implementation of the FMU import in Ener- in EnergyPlus and the pressure difference of the fan is the
gyPlus supports the first and second system configuration algebraic variable in the FMU. For simplicity, we assume
198 T.S. Nouidui et al.

that y1 (·) = x1 (·) and y2 (·) = x2 (·). In this application, the shows the linkage between the FMU and EnergyPlus. The
systems are described by the equations HVAC system was implemented in Modelica and exported
as an FMU. The room model was modelled in Energy-
0 = g 1 (ẋ1 , x1 , x2 ), with x1 (0) = x1,0 , (5) Plus. The HVAC system computes sensible and latent heat
0 = g 2 (x2 , x1 ). (6) gain required to maintain a room set point temperature and
humidity. The FMU needs as inputs the room dry-bulb
Let N denote the number of time steps and let tk with temperature (TRooMea), the outdoor dry-bulb temperature
k ∈ {0, . . . , N } denote the time steps. We use the same (TDryBul), the room air relative humidity (rooRelHum),
superscripts 1 and 2 as for the first case to denote the vari- and the outdoor air relative humidity (outRelHum). The
able and the function that computes the next variable of the outputs of the FMU are the sensible (QSensible) and
simulators 1 and 2, respectively. The first system computes, latent (QLatent) heat transported across the thermodynamic
for k ∈ {0, . . . , N } and some G̃ 1 : Xnk × Xm boundary of air inlet and outlet of the thermal zone.
k × Rk+1 → R ,
n

the sequence This is an application of the first use case where the dif-
ferential variables are room dry-bulb temperature and room
x1 (tk+1 ) = G̃ 1 (x1k , x2k , t k+1 ), (7) air relative humidity in EnergyPlus, and sensible and latent
heat provided by the HVAC system in the FMU. We also
and, similarly, simulator 2 computes for G̃ 2 : Rm × Rn × sent the outdoor dry-bulb temperature and outdoor air rel-
R → Rm the sequence ative humidity from EnergyPlus to the FMU. These are,
however, functions of time that are not part of an algebraic
x2 (tk+1 ) = G̃ 2 (xk2 , xk1 , tk+1 ), (8) loop and hence can be sent from one tool to another without
changing the mathematical structure of the coupled system.
with initial conditions x1 (0) = x1,0 . The functions G̃ 1 (·, ·, ·, ·) Figure 9 shows the Modelica implementation of the
and G̃ 2 (·, ·, ·) are used to compute the value of the state HVAC model with the four inputs that will be linked to
and algebraic variables at the new time step. To advance outputs of EnergyPlus and the two outputs that will be con-
from time tk to tk+1 , system 1 uses its own time integration nected to the inputs of EnergyPlus. The Modelica model
algorithm. At the end of the time step, EnergyPlus sends represents an air-based heating system with an ideal heater
the new state x1 (tk+1 ) to the FMU and receives the value and an ideal humidifier in the supply duct. The heater
x2 (tk+1 ) from the FMU. and humidifier are controlled with a feedback loop that
The coupling schemes described in Sections 7.1 and tracks the room air temperature and room air humidity. The
7.2 are based on loose coupling (Hensen, 1999), which is ideal heater adds heat to the thermal zone in the amount
easier to implement, requires shorter synchronization time Q̇ = yh · Q̇0 and the humidifier adds water vapour in the
steps, is numerically more robust, and computed faster in amount ṁw = yw · ṁw,0 , where yh and yw are the output
the experiments reported by Trčka et al. (2007). signals of controllers that track the return air temperature
and water vapour concentration, and Q̇0 and ṁw,0 are the
nominal heating and humidification capacities.
8. Applications
To link the FMU with EnergyPlus, we send from
8.1. Coupling an HVAC system model, implemented in the FMU to EnergyPlus two schedule values for the
an FMU, with a room model in EnergyPlus latent and sensible heat gain and from EnergyPlus to
In this example, an HVAC system implemented in an the FMU four output variables for the outdoor dry-bulb
FMU is linked to a room model in EnergyPlus. Figure 8 temperature, outdoor air relative humidity, room dry-bulb

Figure 8. System with an HVAC system modelled in an FMU and a room model modelled in EnergyPlus (Q̇ is the heat flow rate, T is
the temperature, ṁw is the water mass flow rate, and Xw is the water vapour mass fraction).
 Journal of Building Performance Simulation 199

Figure 9. Modelica implementation of the HVAC model which is exported as an FMU.

temperature, and room air relative humidity at each QLatent(tk ) and sends these values to EnergyPlus. The
zone time step. This can be accomplished by using two simulation is performed at a 1 min time step.
objects of type ExternalInterface:Functional
MockupUnitImport:To:Schedule to write values
in EnergyPlus and four objects of type ExternalInt 8.2. Coupling a shading controller, implemented in an
erface:FunctionalMockupUnitImport:From: FMU, with a shading device in EnergyPlus
Variable to read values from EnergyPlus. During the In this example, a shading controller, represented by a finite
simulation, the two models are coupled by setting dur- state machine, was implemented in Modelica and exported
ing the time interval t ∈ [tk , tk+1 ) the boundary condi- as an FMU. It was then linked to a shading device which
tions of the HVAC system model to the room dry-bulb is part of an EnergyPlus room model. Figure 10 shows the
temperature TRooMea(tk ), to the room relative humid- coupling between the shading controller and EnergyPlus.
ity rooRelHum(tk ), to the outdoor dry-bulb tempera- The inputs of the FMU are the room dry-bulb temperature
ture TDryBul(tk ), and to the outdoor relative humidity (TRoo) and the solar irradiation (ISolExt) that is incident on
outRelHum(tk ). These values are sent from EnergyPlus the window. The output of the FMU is the shading actuation
to the FMU. The HVAC system model in the FMU then signal (yShade). The room model with the window and the
computes the sensible and latent heat QSensible(tk ) and shading device, which will be controlled by the FMU, has

Figure 10. System with a shading controller in an FMU and a room model with a shading device modelled in EnergyPlus.
200 T.S. Nouidui et al.

Figure 11. Modelica implementation of the shading controller model which is exported as an FMU.

been implemented in EnergyPlus. The shading controller model is the shading actuation signal computed in the FMU.
was implemented in Modelica and exported as an FMU. During the simulation, the two systems are coupled by
This is an application of the second use case where setting during the time interval t ∈ [tk , tk+1 ) the boundary
the differential variable is the room dry-bulb temperature conditions of the shading controller to the room dry-bulb
in EnergyPlus, and the algebraic variable is the shading temperature TRoo(tk ) and to the solar irradiation incident on
actuation signal in the FMU. We also sent the solar irradi- the window ISolExt(tk ). These values are sent from Ener-
ation from EnergyPlus to the FMU which is not part of an gyPlus to the FMU. The shading controller in the FMU
algebraic loop and thus can be sent from one tool to another then computes the actuation signal yShade(tk ) and sends
without changing the mathematical structure of the coupled this value to EnergyPlus. The simulation and reporting are
system. performed at a 10 min time step.
Figure 11 shows the Modelica implementation of the The coupling of the two systems in EnergyPlus can
shading controller which has been modelled using a finite be achieved by using either one object of type Extern
state machine of the Modelica Standard Library. The finite alInterface:FunctionalMockupUnitImport:
state machine switches between the states nightShadeDe- To:Actuator or one object of type External
ployed, noShade, and dayShadeDeployed depending on the Interface:FunctionalMockupUnitImport:To:
guards defined in the transitions. Input of the EnergyPlus Variable to write values to EnergyPlus and two
 Journal of Building Performance Simulation 201

Figure 12. Simulation results showing the solar radiation incident on the shading device, and the shade actuation signal computed in the
FMU (1 means that the shade is deployed).

objects of type ExternalInterface:Functional Acknowledgements

MockupUnitImport:From:Variable to read val- This research was supported by the Assistant Secretary for Energy
ues from EnergyPlus. Efficiency and Renewable Energy, Office of Building Tech-
Figure 12 shows how the shading controller sets the nologies of the US Department of Energy, under Contract No.
DE-AC02-05CH11231.
night shade to be active during the time when the incident
solar radiation on the windows is smaller than the threshold
of 5 W/m2 , which is defined in the transition of the shading
controller model.
References
Accelera. 2012. “Accelera Systems Initiative.” Accessed March 1,
9. Conclusion 2013. http://www.accellera.org/downloads/standards/
Leveraging the FMI standard and creating an FMU import systemc
interface in EnergyPlus allowed EnergyPlus to be coupled ASHRAE. 2004. “ANSI/ASHRAE Standard 135-2004. BACnet –
A Data Communication Protocol for Building Automation
with any simulation tool that is exported as an FMU for co- and Control Networks.” Accessed March 1, 2013.
simulation. With the FMU import interface in EnergyPlus, http://www.bacnet.org/
it is possible prior to simulate a building to (a) subdivide the Borgeson, S., and G. Brager. 2011. “Comfort Standards and Vari-
building into different domains such as envelope, HVAC, ations in Exceedance for Mixed-Mode Buildings.” Building
and controls, (b) model each domain in the simulation tool Research and Information 39 (2): 118–133.
Clark, J., C. Cooper, and F. Drake. 2011. “Expat XML Parser.’
which is best suited for the problem at hand, for exam- Accessed September 19, 2012. http://sourceforge.net/
ple, Modelica for HVAC, Simulink for controls, EnergyPlus projects/expat
for the envelope, (c) export the HVAC and the controls as Clarke, J. 1974–2012. “ESP-r.” Accessed March 1, 2013.
FMUs, and (d) link them through the FMU import interface http://www.esru.strath.ac.uk/Programs/ESP-r.htm
in EnergyPlus. The FMI standard is a promising approach, Crawley, D. B., L. Lawrie, F. Winkelmann, F. Buhl, J. Huang,
C. Pedersen, R. Strand et al. 2001. “EnergyPlus: Creating
developed by the co-simulation community and applied by a New-Generation Building Energy Simulation Program.”
the building simulation community. It is currently supported Energy and Buildings 33 (4): 319–331.
by a growing number of tools. We believe this approach Dassault Systemes AB. 1991–2012. “Dymola Dynamic Modeling
to be robust and be able to contribute to solving chal- Laboratory.” Accessed March 1, 2013. http://www.3ds.com/
lenges faced in integrated building simulations. Future work products/catia/portfolio/dymola
DOE (Department of Energy). 2011a. “EnergyPlus Engineer-
should include the evaluation of the performance of the ing Reference.” Accessed March 1, 2013. http://apps1.eere.
co-simulation approach versus mono-simulation where the energy.gov/buildings/energyplus/pdfs/engineeringreference.
entire simulation is done in a single environment. pdf
202 T.S. Nouidui et al.

DOE (Department of Energy). 2011b. “External Interface Guide MODELISAR Consortium. 2010a. “Functional Mock-up Inter-
for EnergyPlus.” Accessed March 1, 2013. http://apps1.eere. face for Co-simulation.” Accessed March 1, 2013. https://
energy.gov/buildings/energyplus/pdfs/externalinterfaces_ svn.modelica.org/fmi/branches/public/specifications/FMI_
application_guide.pdf for_CoSimulation_v1.0.pdf
Fabian, G., D. van Beek, and J. Rooda. 2008. “Substitute Equa- MODELISAR Consortium. 2010b. “Functional Mock-up Inter-
tions for Index Reduction and Discontinuity Handling.” face for Model-Exchange.” Accessed March 1, 2013. https://
In Proceedings of the Third International Symposium on svn.modelica.org/fmi/branches/public/specifications/FMI_
Mathematical Modeling, Vienna, Austria. for_ModelExchange_v1.0.pdf
Graça, G., P. Linden, and P. Haves. 2004. “Use of Simulation in Nghiem, T. 2010. “MLE+: a Matlab-EnergyPlus Co-simulation
the Design of a Large, Naturally Ventilated Office Building.” Interface.” Accessed March 1, 2013. http://www.seas.upenn.
Building Services Engineering Research and Technology edu/∼nghiem/software.html
25 (3): 211–221. Pang, X., M. Wetter, P. Bhattacharya, and P. Haves. 2012. “A
Hensen, J. L. M. 1999. “A Comparison of Coupled and De-coupled Framework for Simulation-Based Real-Time Whole Build-
Solutions for Temperature and Air Flow in a Building.” ing Performance Assessment.” Building and Environment 54
ASHRAE Transactions. American Society of Heating, Refrig- (August): 100–108.
erating, and Air-Conditioning Engineers 105 (2): 962–969. Thorton, B. A., M. I. Rosenberg, E. E. Richmand, W. Wang,
Huang, J., F. Winkelmann, F. Buhl, C. Pedersen, D. Fisher, R. Y. Xie, J. Zhang, H. Cho et al. 2011. “Achieving
Liesen, R. Taylor et al. 1999. “Linking the COMIS Multizone the 30% Goal: Energy and Cost Savings Analysis of
Airflow Model with the EnergyPlus Building Simulation Pro- ASHRAE Standard 90.1-2010.” Accessed March 1, 2013.
gram.” In Proceedings of Building Simulation 1999, Kyoto, http://www.pnl.gov/main/
Japan, 1065–1070. publications/external/technical_reports/PNNL-20405.pdf
Jacob, D., S. Dietz, S. Komhard, C. Neumann, and S. Herkel. 2010. Trčka, M., J. L. M. Hensen, and M. Wetter. 2007. “Compari-
“Black-Box Models for Fault Detection and Performance son of Co-simulation Approaches for Building and HVAC/R
Monitoring of Buildings.” Journal of Building Performance Simulation.” In Proceedings of the 10th IBPSA Conference,
Simulation 3 (1): 53–62. Beijing, China, 1418–1425.
Larson, G. W., and R. A. Shakespeare. 1988–2012. “Radiance.’ Wang, L. P., J. William, and P. Jones. 2009. “Case Study of Zero
Accessed March 1, 2013. http://radsite.lbl.gov/radiance/ Energy House Design in UK.” Energy and Buildings 41 (11):
MathWorks. 1994–2012a. “MATLAB the Language of Tech- 1215–1222.
nical Computing.” Accessed March 1, 2013. http://www. Wetter, M. 2011. “Co-simulation of Building Energy and Con-
mathworks.com/products/matlab/ trol Systems with the Building Controls Virtual Test Bed.”
MathWorks. 1994–2012b. “MATLAB the Language of Tech- Journal of Building Performance Simulation 3 (4): 185–203.
nical Computing.” Accessed March 1, 2013. http://www. Zhai, Z., and Q. Chen. 2005. “Performance of Coupled Building
mathworks.com/products/simulink/ Energy and CFD Simululations.” Energy and Buildings 37
MODELISAR Consortium. 2008–2012a. “Functional Mock-up (4): 333–344.
Interface.” Accessed March 1, 2013. https://fmi-standard.org/ Zhai, Z., Q. Chen, P. Haves, and J. Klems. 2002. “On Approaches
MODELISAR Consortium. 2008–2012b. “Functional Mock- to Couple Energy Simulation and Computational Fluid
up Interface Support Tools.” Accessed March 1, 2013. Dynamics Programs.” Building and Environment 37 (8–9):
https://www.fmi-standard.org/tools 857–864.