Next: Case Study Up: Methodology Previous: Building characterization
The underlying energy simulation engine is EPlus [10]. The interactive usage of UBEM is possible because of the integration of Functional Mockup Interface (FMI) into EPlus. FMI [6] is a standardized interface that enables independent models to communicate and exchange data with each other. At first, the input and output variables need to be defined in the IDFs. For this purpose the external interface of EPlus is activated. The input variables (weather data, occupancy, internal electrical load and water use) are defined as "actuators" in this interface with name, name of component, component type, control type, FMU name and initial value. The output variables (gas, water and electricity meters) additionally require the Energy Management System (EMS) of EPlus, which is an internal programming interface to define custom control and modelling routines. In the EMS, every output variable is defined as a "sensor" with name and reference as well as "output variable" with name, EMS name, data type and update frequency. Besides, the output variables necessitate a specification as "variable" in the external interface with name, FMU name and an index key. Figure 4 illustrates how to define an input and output variable in an IDF for the use in FMI.
The IDF files for each building are then converted by the Python script EnergyPlusToFMU.py to Functional Mockup Units (FMU) [41]. An FMU is built as a zip file, which essentially contains the shared libraries with C-functions defining the equations of the model and a XML file defining the variables used. The FMI establishes an hierarchy between the models. EPlus is a slave model, while the Python framework PyFMI [3] is the master model. The master model sets the time step and controls the co-simulations. To run the simulations, PyFMI imports and initializes the FMUs as independent computer processes. In 10-min intervals, current weather data (temperature, relative humidity, wind speed and direction) are accessed via the Application Programming Interface (API) of OpenWeather [45] and subsequently transferred to the individual EPlus process, which simulates one building. The values for occupancy, internal electrical load and water use are obtained from standard profiles used in the utility industry [18] and then changed into schedules in OpenStudio. These schedules describe the normalized variations within one day. Depending on the floor space of the building, the schedule values are modified by the number of habitants. At each time step, the EPlus processes compute with the corresponding input values the heat balance of each building by taking into account the outside temperature, thermal conductivity of the surfaces, heat sinks and sources (heating, human bodies, etc.) in order to estimate the energy required to maintain the indoor target temperature. This demonstrates the capacity to interact with diverse parameters and receive an immediate feedback. After EPlus finishes the computation of gas, water and electricity demand for the time step, the data are imported back to PyFMI. Current carbon intensity of electricity generation, which is retrieved through the API of electricityMap [64], is combined with carbon intensity of fossil fuel combustion to calculate the global warming potential.
The data are finally exported as JSON file and uploaded to the web-interface of UBE-FMI [31]. The web-interface is implemented with the JavaScript library NASA WorldWind [5]. NASA WorldWind is a virtual globe that allows to visualize three-dimensional data. The Collada files of the buildings are also visualised and indicate the global warming potential, energy and water demand of the last time step. Figure 1 summaries the structure of UBE-FMI.
Maikel Issermann
