MPCPy: An Open-Source Software Platform for Model Predictive Control in Buildings

David H. Blum1 and Michael Wetter1

1
Lawrence Berkeley National Laboratory,
Energy Technologies Area
Building Technology and Urban Systems Division
Berkeley, CA, U.S.A.

based setpoint managing without consideration of all of

Abstract
the necessary information to decide an optimal
Within the last decade, needs for building control performance trajectory for a given objective. This
systems that reduce cost, energy, or peak demand, and includes forecasts of weather, energy prices, and
that facilitate building-grid integration, district-energy building occupancy. In addition, the current control
system optimization, and occupant interaction, while systems do not provide meaningful feedback to operators
maintaining thermal comfort and indoor air quality, have about the impact of certain control actions on system
come about. Current PID and schedule-based control performance, which may help operators better manage
systems are not capable of fulfilling these needs, while systems according to their objectives.
Model Predictive Control (MPC) could. Despite the
Conversely, model predictive control (MPC) can meet
critical role MPC-enabled buildings can play in future
the emerging requirements of building control systems.
energy infrastructures, widespread adoption of MPC
MPC uses system performance models, which include
within the building industry has yet to occur. To address
all of the relevant information, to forecast performance
barriers associated with system setup and configuration,
and optimize control inputs with respect to a given
this paper introduces an open-source software platform
objective. These models can also provide useful
that emphasizes use of self-tuning adaptive models,
feedback to system operators or building occupants for a
usability by non-experts of MPC, and a flexible
number of operating scenarios.
architecture that enables application across projects.
A large body of work has shown that MPC can help
Introduction enable buildings to meet these new requirements
(Rockett and Hathway 2016). However, despite its
Background
widespread adoption in other industries (Qin and
In an effort to limit climate change and decrease Badgwell, 2003) and success in research, it has not been
operating costs, energy systems have become the focus widely adopted in the building industry, except for a few
of widespread concern. This is especially true with companies offering MPC as a software service for
those systems associated with buildings, which account commercial buildings (BuildingIQ 2016, QCoefficient
for approximately 71% (EIA 2016a) of electricity use 2016) and campus central plants (Johnson Controls
and 40% (EIA 2016b) of total primary energy use in the 2015). Rockett and Hathway (2016) point out several
U.S. While buildings play the largest role in energy use, factors that contribute to the lack of penetration of MPC
they are largely ill-equipped to handle new performance into industry, with the foremost being 1) the lack of
requirements brought about by new concerns. These long-term trials showing the effectiveness of MPC and
requirements include energy or carbon minimization, 2) the expense and skill required for installation and
peak demand minimization, integration with electrical maintenance. This is particularly true for initial model
and thermal district energy system operations, and configuration and maintaining model accuracy as
occupant and operator feedback and connectivity. Many building operation changes over time. We believe these
of these requirements depend upon a building being able factors go hand-in-hand, where the high costs of
to consider time-based incentives in the operation of installation and maintenance have prevented numerous
multiple subsystems towards a common objective. long-term trials, and the low number of long-term trials
Examples include shifting peak afternoon cooling loads have prevented the development of robust modeling and
towards morning hours, reducing energy use during installation approaches.
times of high energy prices, coordinating PV generation,
electric vehicle charging, and occupant service to limit Paper Objective
the stress on the electric grid, and responsiveness to In order to address the problem of high system setup and
occupants. maintenance costs, increase the number of trials of MPC
in buildings, and facilitate widespread adoption of MPC
Advancing the State of the Art
in the building industry, this paper introduces the
Current state of the art building control systems rely on a development of an open-source software platform for
combination of PID feedback control and schedule-

Proceedings of the 15th IBPSA Conference 1381

San Francisco, CA, USA, Aug. 7-9, 2017 https://doi.org/10.26868/25222708.2017.351
MPC in buildings, MPCPy, available on the LBNL to address all aspects for building MPC in an externsible
Simulation Research Group github site at way, is freely available, and is provided open-source.
https://github.com/lbl-srg/MPCPy under a modified BSD The remainder of the paper will describe the architecture
license. A number of specific features are expected to of MPCPy and present examples to showcase its
contribute to the solution: capabilities. This paper will not address open research
 An emphasis is put on the use of adaptive models, questions about proper adaptive model configurations
which use measurements of the building and learning procedures, nor will it address guidelines
performance to continually update and remain for connecting to building automation systems (BAS).
accurate enough for control optimization, as However, it is expected that MPCPy could be used
illustrated in Figure 1. Such models are expected to extensively to answer these and other questions.
drastically reduce model setup and maintenance
costs. Architecture
 Automatic model parameter estimation and MPCPy is designed using an object-oriented approach
optimization problem formulation together with that promotes extensibility and is scripted in Python 2.7.
flexible data input modules reduce the required The architecture is adapted from a tool-based
MPC and programming expertise of users. architecture approach for computer-aided control design
software (Barker et al. 1993 and Jobling et al. 1994), and
 The use of open software standards enable is shown in Figure 2. In such an architecture, tools are
contributions from other researchers and adoption developed to perform very specific functions, and then
by industry, while maintaining code maintenability are supported by common processing agents and
and longevity due to the use of standards that have combined to perform various tasks. In MPCPy, four
support in many industrial sectors. class modules represent the tools needed for MPC:
 An extensible architecture enables rapid  ExoData classes collect external data and process it
development and distribution of new MPC methods. for use within MPCPy.
 System classes represent real or emulated systems
to be controlled, collecting measurements from or
providing control inputs to the systems.
 Models classes represent system models for MPC,
managing model simulation, estimation, and
validation.
 Optimization classes formulate and solve the MPC
optimization problems using Models objects.
Supporting the four tools are three modules for data
handling and processing during run-time:
 Variable and Unit classes together maintain the
association of static or timeseries data with units.
 Utility classes provide functionality needed across
tools and for interactions with external components.
MPCPy does not contain any of its own model
specifications or solvers. Instead, it relies on external
software, modeling languages, and solvers. While
dependencies can be expanded to include other software,
Figure 1 – MPCPy emphasizes the use of self- these external components are currently based on the
adapting models for MPC optimization. Modelica (Mattsson and Elmqvist 1997) and Functional
Mock-up Interface (FMI 2016) open standards, with
system emulation models and MPC models able to be
While previous research has developed software defined as native Modelica files or as Functional Mock-
frameworks for MPC in buildings, most have been up Units (FMU). An FMU is a zipped file containing
developed for specific project requirements (such as data the variables and equations of a model that can be used
sources, processing methods, building simulation to exchange the model between simulation programs.
packages, and optimziation solvers) and are not made Optionally, solvers and additional data can be packaged
available for public use. Those that are offered to the as well. Substantial development of the application of
public in some way require costly commercial software,
such as MATLAB (Zakula et al. 2014, Bernal et al.
2012, Sturzenegger et al. 2014), or are focused on one
aspect of the MPC process, such as reduced-order model
development (Sturzenegger et al. 2014, DeConinck et al.
2016). In contrast, the framework introduced here looks

Proceedings of the 15th IBPSA Conference 1382

San Francisco, CA, USA, Aug. 7-9, 2017
 variable objects upon instantiation and act upon the
variable data depending on the action. Each unit is part
of a quantity type. For example the unit degC is a
temperature quantity. Each quantity has a base unit in
which all data is stored, which follows the convention
defined by the Modelica Standard Library (Modelica
Association 2016). The display unit, however, defines
the conversion of the data to that base unit upon input, or
conversion from that base unit upon display or output.
The DisplayUnit class defines these required methods,
with additional methods specified in quantity-specific
classes.

Figure 2 – MPCPy architecture.

these standards to building simulation and optimization

is ongoing (Wetter et al. 2015 and Wetter and Treeck
2015). JModelica (Modelon AB 2009), an open-source
Modelica compiler, is used to compile native Modelica
models, simulate FMUs, and solve optimization
problems, while EstimationPy (Bonvini et al. 2014) can Figure 3 – Variables and Units class diagram. Classes
be used for model parameter and state estimation using labelled “A” are abstract, “C” are concrete.
FMUs. Therefore, any Modelica library can be used to
create native Modelica models, including the Modelica
Buildings Library (Wetter et al. 2014) or any from the ExoData
Annex 60 collaboration (Wetter et al. 2015), as can any ExoData classes are responsible for the representation of
modeling software capable of generating FMUs. While exogenous data, with methods to collect this data from
there exist methods to solve control optimization various sources and process it for use within MPCPy.
problems using highly detailed, non-differentiable Exogenous data is separated according to a data class
models (Wetter 2001), we strongly recommend the use and each data class has a specified variable organization
of differentiable models for control optimization, which in the form of a Python dictionary. This allows for an
can be solved very efficiently (Wetter et al. 2016). internal understanding of where objects should look for
The following sections will detail the features of the specific data and the use of specific checks for each data
Variables, Units, ExoData, Systems, Models, and class. At the time of this writing, there are eight types of
Optimization module classes. data classes: Weather, Internal, Controls, Constraints,
Prices, Parameters, and Other Inputs.
Variables and Units
Figure 4 presents a basic UML class diagram showing
Variable and Units classes allow MPCPy to effectively
the relationship of ExoData classes. At the top is the
associate data with units as well as handle timeseries
Type class that contains common methods for all
data separately from static (constant) data. The Python
exogenous data class types. Then, there exists an
package Pandas (McKinney 2010) is integrated into the
abstract class for each exogenous data class, which
handling of timeseries variables, bringing to MPCPy the
inherits the Type class and adds additional methods
many useful features Pandas has to offer for data
specific for that data class. These include assertions that
storage, cleaning, resampling, interpolation, and
particular variables fall within limits or methods for
statistical analysis.
manipulating the data dictionary for that data class.
Figure 3 presents a basic Unified Modeling Language Finally, source-specific classes inherit the type-specific
(UML) class diagram, commonly used in the field of data classes and add methods required to collect data
software development, showing the relationship of from a particular source. For example, an EPW file or
Variables and Units classes. The Variable class defines CSV file may be the source of weather data. At the time
common methods for MPCPy variables, while the Static of this writing, aside from this choice, CSV files must be
and Timeseries classes inherit the Variable class and the source of all other data types. However, similar to
implement methods more specific to data that is constant the EPW and CSV example, the class designs allow for
and time-varying respectively. Units are added to easy addition of other data class sources and types.

Proceedings of the 15th IBPSA Conference 1383

San Francisco, CA, USA, Aug. 7-9, 2017
 model, estimate parameters or states based on measured
system data, and validate the model based on measured
system data. These are often reduced-order or simplified
models when compared to a system emulation model.
Figure 6 presents a basic UML class diagram showing
the relationship of Models classes. The Model class
contains common methods for an MPC-suited model.
The Model class has two classes for an estimation
method and a validation method. The Estimate class
contains methods common for solving parameter or state
estimation problems. Implementations of the Estimate
Figure 4 – ExoData class diagram. Classes labelled class contain specific methods required to setup and
“A” are abstract, “C” are concrete. solve the estimation problem with various algorithms.
For example, the estimation problem may be formulated
Systems as an optimization problem, to be solved in JModelica,
Systems classes represent the controlled systems, with or formulated for an Unscented Kalman Filter (UKF),
methods to collect measurements from or set control implemented by EstimationPy. Meanwhile, the Validate
inputs to the system. This representation can be real or class contains methods common for validating the
emulated using a detailed simulation model. A common estimation process and concrete implementations of this
interface to the controlled system in both cases allows class apply more specific validation algorithms. For
for algorithm development and testing on a simulation example, this could be calculating the RMSE between
with easy transition to the real system. Similar to measured data and simulated data with estimated
exogenous data, measurement data has a specified parameters. Lastly, the Modelica class inherits the
variable organization in the form of a Python dictionary Model class and adds methods to handle Modelica and
in order to aid its use by other objects. FMI-based models. Many of these methods are inherited
Figure 5 presents a basic UML class diagram showing from an FMU class in the Utilities module, not described
the relationship of Systems classes. The System class in detail here. The class design of models is in such a
contains common methods for all system types. Then, way that allows for adding other estimation and
real and emulated system classes inherit the top-level validation methods as well as model formats.
System class and add methods that are more specific.
For example, the emulated system class requires
methods to simulate a model, rather than establish a
connection with a data server or control system serving a
real system. Finally, concrete classes inherit the system
type methods and implement methods that are more
specific for the emulation or real system source type. At
the time of this writing, MPCPy only supports emulation
by FMU simulation, however, the class design allows for
adding emulation methods and real system sources.

Figure 6 – Models class diagram. Classes labelled “A”

are abstract, “C” are concrete.

Optimization
Optimization classes represent MPC optimization
problems, with methods to setup and solve such
problems.
Figure 7 presents a basic UML class diagram showing
the relationship of Optimization classes. The
Figure 5 – Systems class diagram. Classes labelled “A” Optimization class implements methods for setting up
are abstract, “C” are concrete. and solving an MPC optimization problem. It has two
classes for a problem and an optimization package. The
Problem class contains common methods for defining an
Models optimization problem. Implementations of Problem add
Models classes represent system models that can be used specific methods to setup a particular problem type. At
for MPC optimization, with methods to simulate the

Proceedings of the 15th IBPSA Conference 1384

San Francisco, CA, USA, Aug. 7-9, 2017
the time of this writing, MPCPy supports parameter
estimation, energy minimization, and energy cost
minimization. The Package class contains common
methods for setting up an optimization package to solve
the defined optimization problem. Implementations add
specific methods for a particular optimization package.
At the time of this writing, MPCPy supports the use of
JModelica as a package. Note that an implementation of
a Package should be able to solve any of the problems
defined by a Problem class. In this way, the class design
allows for the addition of other problem types, such as
peak load minimization or demand response
maximization, and optimization packages.

Figure 8 – .mo file to .mop file modifications for an

energy cost minimization problem with grey text
representing original .mo code, red text representing
case-specific code additions, and black code
representing general code additions.

Figure 7 – Optimization class diagram. Classes labelled

“A” are abstract, “C” are concrete. Variable and Unit Management
We begin by defining a single static variable with units
A key feature of MPCPy is the ability to automatically of oC, which may represent a thermostat setpoint.
setup and solve optimization problems, requiring only >>> from mpcpy import variables
model files, exogenous input data, and optimization >>> from mpcpy import units
>>> T_set = variables.Static('T_set',20,units.degC)
constraints. At the time of this writing, this feature is >>> print(T_set)
supported for models defined in native Modelica and Name: T_set
Variability: Static
problem types of parameter estimation, energy Quantity: Temperature
minimization, and energy cost minimization using Display Unit: degC
JModelica as an optimization package. This automated
process begins with automatic modification of the given The first two lines of code import the Variables and
native Modelica model file (.mo) into an Optimica Units modules from MPCPy. The third line instantiates
(Akesson 2008) Modelica file (.mop) based on the the static variable with three arguments; name, data, unit.
optimization problem type. This includes the objective Printing the variable displays relevant information about
of the problem type chosen, constraints on model states, the variable, including that it has a quantity of
or identification of parameters or states to be estimated. temperature. Therefore, the data is actually stored in
Figure 8 shows example modifications that are made for units of Kelvin. We can check this by getting the base
an energy cost minimization problem. Next, the .mop unit and data of the variable.
file is used by JModelica to instantiate an optimization >>> T_set.get_base_unit()
problem. Upon solver runtime, the optimization mpcpy.units.K
problem is combined with solution-specific information >>> T_set.get_base_data()
293.15
and passed to the optimization solver. This solution-
specific information includes exogenous input data or The data can also be displayed in the display units.
measurement data required for model estimation.
>>> T_set.display_data()
20.0
Examples
This section presents a number of examples to show the The display unit can also be changed.
capabilities of MPCPy. Examples are for variable and >>> T_set.set_display_unit(units.degF)
unit management, collecting exogenous data, building >>> T_set.display_data()
68.0
emulation, model estimation and validation, and control
optimization. Note that the examples are simple and Note that functionality is the same with timeseries
emphasize the processes enabled by MPCPy, not the variables, however, data is supplied in the form of a
specific outcomes of those processes. Pandas series variable with a timestamp index instead of
a single value. By default, the Pandas timeseries

Proceedings of the 15th IBPSA Conference 1385

San Francisco, CA, USA, Aug. 7-9, 2017
specified is assumed to be in UTC time, however, zones having exterior walls, one facing east and the
optional arguments upon instantiation allow for other facing west. For example purposes, we model
timeseries in local time zones to be specified as well. each zone having a single convective heater. An
The timeseries is converted to UTC time for storage, emulation model is built using components from the
though can be again converted to local upon data Modelica Buildings Library, namely three thermally
display. connected instances of the
Buildings.ThermalZones.Detailed.MixedAir, and
Collecting Exogenous Data
exported as a model-exchange FMU v 2.0. Peak internal
Next, we would like to collect exogenous data from a loads total 20 W/m2 with a 40%-40%-20% split between
source. First, we collect weather data from an EPW file. convective, radiative, and latent and a typical weekday
>>> from mpcpy import exodata office schedule. For demonstration purposes the
>>> weather = exodata.WeatherFromEPW('path.epw') building is located in Chicago, IL, a time zone that is
>>> weather.collect_data('1/1/2015', '1/4/2015')
UTC-6:00.
The first line of code imports the exodata module from
MPCPy. The second line instantiates a weather data
object with an EPW file as the source, while the third
line collects data from the file for the time-period
specified. The time-period can be in any form
recognizable to Pandas or a custom format, optionally
defined upon object instantiation.
Figure 9 – LBNL71T test building, used for
Now, we collect weather data from a CSV file. demonstration of MPCPy.
>>> variable_map = {'TemperatureF' : First, we must define what measurements we wish to
. . . ('weaTDryBul', units.degF),
. . . 'Dew PointF' :
take from the model. The code shown below defines a
. . . ('weaTDewPoi', units.degF), measurement dictionary by indicating the name of the
. . . 'Humidity' : variable we wish to measure and its sample rate. Note
. . . ('weaRelHum', units.percent),
. . . 'Sea Level PressureIn' : that upon simulation, the output reporting time-step is
. . . ('weaPAtm', units.inHg), equal to the minimum defined measurement sample rate.
. . . 'WindDirDegrees' :
. . . ('weaWinDir', units.deg), >>> measurements = {};
. . . ‘Wind SpeedMPH' : >>> measurements['wesTdb'] = {'Sample' :
. . . ('weaWinSpe', units.mph)}; . . . variables.Static('wesTdb_sample', 600, units.s)};
>>> weather = >>> measurements['halTdb'] = {'Sample' :
. . . exodata.WeatherFromCSV( . . . variables.Static('halTdb_sample',1200, units.s)};
. . . 'path.csv', variable_map, >>> measurements['easTdb'] = {'Sample' :
. . . time_header = 'TimePDT', . . . variables.Static('easTdb_sample',1200, units.s)};
. . . tz_name = 'from_geography',
. . . geography = [37.8716, -122.2727]);
>>> weather.collect_data('1/1/2015', '1/4/2015') With the measurements defined, we can instantiate our
building emulation object, simulate the building, and
The first line of code defines a mapping dictionary plot the measurements.
between the header columns of the CSV file and the
>>> from mpcpy import systems
input variables in the emulation or MPC models. The >>> from matplotlib import pyplot as plt
dictionary keys are the column headers and the value of >>> building = systems.EmulationFromFMU(
. . . 'path.fmu', measurements,
each key is a tuple of the model input name and data . . . weather_data = weather.data, \
units as displayed in the CSV file. Note that using the . . . internal_data = internal.data, \
Variable and Units classes, the data is automatically . . . control_data = control.data, \
. . . parameter_data = parameters.data, \
converted to the base unit for use within the model. The . . . tz_name = weather.tz_name);
second line of code instantiates a weather object with a >>> building.collect_measurements(
. . . '1/1/2015', '1/4/2015');
CSV file as a source and the variable map already >>> plt.figure(1)
defined. A few optional arguments are shown as well, >>> for key in self.building.measurements.keys():
which define which CSV column header name contains . . . variable =
. . . building.measurements[key]['Measured'];
the timestamps and in which time zone the timestamps . . . variable.set_display_unit(units.degC);
are. By default, the object will read timestamps from a . . . variable.display_data().plot(label = key);
. . . plt.legend();
column header “Time” or “Timestamp” and will assume . . . plt.ylabel(variable.quantity_name + '[' +
UTC time. Additional arguments for specifying a . . . variable.display_unit.name + ']');
custom timestamp format and data cleaning algorithms
are available, but not discussed further here. The first line of code imports the Systems module from
MPCPy and the second imports the matplotlib package
Building Emulation (Hunter 2007). The third line of code instantiates the
Next, we look to simulate a building emulation model. building system object as an FMU and with the
The building we will use is based on a test facility on the measurement dictionary already defined. Other optional
Berkeley Lab campus, called LBNL71T and shown in arguments of the instantiation define the exogenous data
Figure 9. It is a three-zone facility, with two of the to use, collected as shown before, parameters of the

Proceedings of the 15th IBPSA Conference 1386

San Francisco, CA, USA, Aug. 7-9, 2017
 emulation model, and the building time zone. Note that solar irradiation incident on the wall. Windows are
the weather data comes from the Chicago, IL EPW file, modelled with a single resistor and solar transmittance
while internal load data and heater control signals come coefficient. Lastly, interior partitions between zones are
from separate CSV files. The fourth line of code modelled with two resistors and a single capacitor. The
simulates the emulation model for the time-period components are modelled using the Modelica Standard
specified, according to the building time zone. Finally, Library and Modelica Buildings Library.
the last lines of code plot the measurements using the While this paper shows the approach of building a
Pandas plot function and MPCPy variable attributes. library of reduced order model components is promising,
Figure 10 shows the resulting plot. the purpose of this model is not to represent answers to
questions about what the proper reduced-order model
configurations is to use for multi-zone buildings and
HVAC systems. Also, this example does not address
methods to improve model training, including necessary
model excitation or data characteristics. Rather, the
model’s purpose here is to be a suitable demonstration of
MPCPy capabilities. These other important questions
are saved for future work, and can be exercised using
MPCPy. We are now ready to instantiate, estimate, and
validate the reduced order model.
>>> from mpcpy import models
>>> model = models.Modelica(
. . . models.JModelica,
. . . models.RMSE,
. . . building.measurements,
Figure 10 – Mean zone air temperatures of LBNL71T in . . . moinfo =
. . . ('path.mo', 'package.model', libraries)
Chiacgo, IL from January 1-3. . . . weather_data = weather.data, \
. . . internal_data = internal.data, \
. . . control_data = control.data, \
. . . parameter_data = parameters.data, \
Model Estimation . . . tz_name = weather.tz_name);
Next, we look to estimate the parameters of a reduced- >>> model.estimate('1/1/2015', '1/4/2015',
. . . ['wesTdb', 'halTdb', 'easTdb']);
order model of our emulated building, shown in Figure >>> building.collect_measurements(
11. The reduced order model is an RC circuit that . . . '1/4/2015', '1/5/2015');
models sensible heat transfer only. Each zone interior is >>> model.measurements = building.measurements;
>>> model.validate('1/4/2015', '1/5/2015',
modelled with two capacitances with a resistance 'respath', plot = 1);
between them, representing the air capacitance and
interior thermal mass capacitance. The zone exterior The first line of code imports the Models module from
walls are modelled with two resistances and one thermal MPCPy. The second line of code instantiates the model
capacitance as well as a solar absorbance coefficient for object with an estimation method (JModelica), validation

Figure 11 – RC model representing the LBNL71T test building, used for demonstration of MPCPy. The parameters
to train are shown next to each component Modelica diagram.

Proceedings of the 15th IBPSA Conference 1387

San Francisco, CA, USA, Aug. 7-9, 2017
method (calculate RMSE), system measurements, and exogenous data object from a CSV file and contains
Modelica model information, as well as exogenous data timeseries information about greater-than-or-equal-to
as collected before. The system measurements are and less-than-or-equal-to constraints on state variables
passed using the measurement dictionary formulated and their derivatives, as well as initial value, final value,
after collecting measurements with the building object. or cyclic (initial equals final) constraints. For this
The model information requires the file path, model path example, the zone mean air temperatures are constrained
within the file, and any libraries required to compile the to between 22°C and 25°C, their derivatives are
model. The parameter data is collected from a CSV as constrained to less than 2 K/h, and their initial and final
exogenous data and contains information about the values must be equal. This cyclic constraint assumes
parameters in the model to be estimated, including their that neighbouring days would have similar conditions
minimum and maximum values, initial guesses, and and preferred performance. The heater control signals
covariances (applicable to the UKF estimation method if are constrained to between 0 and 1. The last line of code
used). The third line of code estimates the model solves the optimization problem over the time period
parameters using the specified period of measurement specified. Note that all other exogenous data, such as
data (Jan. 1-3) and measurement variables. weather and internal loads, are included in the model
object that is passed. The optimization will optimize all
variables in the “control_data” attribute of the model,
which in this case are the heater control signals.
Lastly, the objective is changed to minimize energy cost.
>>> opt_problem.set_problem_type(
. . . optimization.EnergyCostMin);
>>> opt_problem.optimize('1/2/2015', '1/3/2015',
. . . price_data = prices.data);

Here, we add price data, collected as an exogenous data

object as shown previously, to the optimize statement.
The price data is automatically integrated with the model
optimization, in this case multiplying together with the
defined objective variable, “Ptot.” In the case
demonstrated, the price of electricity is five times higher
Figure 12 – Mean zone air temperatures over the during the hours of 6:00 PM, 7:00 PM, and 8:00 PM
validation period on Jan. 4 for LBNL71T RC model local time than the rest of the day. The solutions to the
Shown in local time. energy minimization and energy cost minimization
problems are presented in Figures 13 and 14. Notice that
temperature constraints are not violated and the inclusion
Finally, the last three lines of code validate the model
of price spikes incentives a significant shift in heating
using data from the day after the training period using
power away from the hours with higher prices.
the specified period of measurement data, with the
validation results output to a defined directory path. The Discussion
results of model validation are shown in Figure 12. The
The examples showed the systematic, yet flexible,
RMSE for wesTdb, halTdb, and easTdb are 0.32 K, 0.27
approach MPCPy takes to setup MPC for buildings,
K, and 0.40 K for the training period, and 0.18 K, 0.20
upon which industry and researchers can build and test
K, and 0.58 K for the validation period.
their implementations. Variables and Units provide
Control Optimization flexibility during the input and output of data with
Lastly, we optimize heater control to minimize energy respect to data units and timeseries time zones.
use and cost while maintaining thermal comfort. Exogenous data of various types and with different data
sources and formats can be combined together for use
>>> from mpcpy import optimization during model simulation, estimation, validation, and
>>> self.opt_problem =
. . . optimization.Optimization(model, optimization. Common interfacing with real and
. . . optimization.EnergyMin, emulated systems eases transition from controller
. . . optimization.JModelica,
. . . 'Ptot', development to application. Automatic setup of model
. . . constraint_data = self.constraints.data); parameter estimation and optimization algorithms
>>> opt_problem.optimize('1/2/2015', '1/3/2015');
minimizes the user programming and expertise
requirements. Lastly, an extensible architecture enables
The first line of code imports the Optimization module new data sources, simulation procedures, problem types,
from MPCPy. The second line of code instantiates an and solver methods to be added in the future.
optimization problem object by defining the model to
use, the optimization problem, the optimization solver, Conclusion
the objective variable within the model, which is total The requirements of building control systems are
power in this case (variable “Ptot”), and constraint data. growing in a way that requires improved information
The model is the model object instantiated as shown processing and decision making over the state of the art.
previously. The constraint data is collected as an

Proceedings of the 15th IBPSA Conference 1388

San Francisco, CA, USA, Aug. 7-9, 2017
 (a) (a)

(b) (b)
Figure 13 – Zone mean air temperature (a) and heater Figure 14 – Zone mean air temperature (a) and heater
power (b) solutions for energy minimization of LBNL71T power (b) solutions for energy cost minimization of
RC model on Jan. 2nd. Shown in local time. LBNL71T RC model on Jan. 2nd. Shown in local time.

Past research and few demonstrations have shown that Future functionality also includes application of MPCPy
MPC can meet these new requirements. However, the at various system scopes, including the room, building,
building industry has yet to see widespread adoption of and campus levels. Development of a Modelica
MPC control systems, likely due to high setup costs and component library for MPC applications is planned by
maintenance for individual sites. To address these Wetter and Treeck (2015). Demonstrations of MPCPy at
barriers, this paper introduces a freely available open- real sites are planned to take place over the next five
source MPC platform for buildings based on open years by LBNL and collaborators. However, we hope
standards, called MPCPy, available on the LBNL that the public release provides others an opportunity to
Simulation Research Group github site at demonstrate its capabilities as well, contribute to its
https://github.com/lbl-srg/MPCPy under a modified BSD development, and create a community of users.
license. The platform emphasizes the use of adaptive The current version of MPCPy is v0.1. Development is
models, whose parameters can be learned over time with ongoing for the support of the public release, including
measured building data, and the automation of model additional features, documentation, error handling,
learning and optimization problem setup and solving. regression testing, and interface adjustments. Updates
Both of these features are expected to significantly will be released periodically according to user feedback
reduce the required system setup time and expertise. In and developer progress. To contribute to this project’s
addition, MPCPy is designed for extensibility and based development or inquiry about collaboration, visit the
on open-source standards so that new data sources, MPCPy github site or contact the authors.
model types, procedures, and problems can be added
over time without sacrificing code longevity. Acknowledgements
Immediate future work is three-fold, having to do with This research was supported by the Assistant Secretary
functionality, demonstration, and support for the public for Energy Efficiency and Renewable Energy, Office of
release. Additional functionality includes methods for Building Technologies of the U.S. Department of
real system implementation, support for additional Energy, under Contract No. DE-AC02-05CH11231.
optimization problems, such as peak load minimization, This work is funded by the U.S.-China Clean Energy
and incorporation of occupant behaviour models. Research Center (CERC) 2.0 on Building Energy
Efficiency (BEE).

Proceedings of the 15th IBPSA Conference 1389

San Francisco, CA, USA, Aug. 7-9, 2017
References Computer Aided Control Systems Design, Gent,
Belgium, April 28-30.
Akesson, J. (2008). Optimica – An extension of
Modelica supporting dynamic optimization. In McKinney, W. (2010). Data structures for statistical
Proceedings of the 6th International Modelica computing in Python. In Proceedings of the 9th
Conference, Bielefeld, Germany, March 3-4, 57-66. Python in Science Conference, Austin, Texas, June
28 – July 3, 51-56.
Barker, H. A., M. Chen, P. W. Grant, C. P. Jobling, and
P. Townsend (1993). Open architecture for Modelica Association (2016). Modelica Standard
computer-aided control engineering. IEEE Control Library. https://github.com/modelica/Modelica. Last
Systems 13(2), 17-27. accessed Nov. 18, 2016.
Bernal, W., M. Behl, T. X. Nghiem, and R. Mangharam Modelon AB (2009). Jmodelica.org – Open source
(2012). MLE+: A tool for integrated design and Modelica platform for modeling, simulation, and
deployment of energy efficient building controls. In optimization. Available online at
Proceedings of Buildsys 2012, Toronto, Canada, http://jmodelica.org/. Last accessed Nov. 18, 2016.
November 6. QCoefficient, Inc. (2016). http://qcoefficient.com/. Last
Bonvini, M., M. Wetter, and M. D. Sohn (2014). An accessed Nov. 18, 2016.
FMI-based framework for state and parameter Qin, S., and T. Badgwell (2003). A survey of industrial
estimation. In Proceedings of the 10th International model predictive control technology. Control
Modelica Conference, Lund, Sweden, March 10-12, Engineering Practice 11(7), 733-764
647-656.
Rockett, P. and E. Hathway (2016). Model-predictive
BuildingIQ (2016). https://buildingiq.com/. Last control for non-domestic buildings: a critical review
accessed Nov. 18, 2016. and prospects. Building Research & Information,
De Coninck R., F. Magnusson, J. Akesson, and L. DOI: 10.1080/09613218.2016.1139885.
Helsen (2016). Toolbox for development and Sturzenegger, D., D. Gyalistras, V. Semeraro, M.
validation of grey-box building models for
Morari, and R. S. Smith (2014). BRCM Matlab
forecasting and control. Journal of Building
Toolbox: Model generation for model predictive
Performance Simulation 9(3), 288-303.
building control. In Proceedings of the 2014
EIA (2016a). Monthly Energy Review October 2016, American Control Conference (ACC), Portland, OR,
Table 7.6. Available online at June 4-6, 1063-1069.
http://www.eia.gov/totalenergy/data/monthly/pdf/se
c7_19.pdf. Last accessed Nov. 18, 2016. Wetter, M. (2001). GenOpt – A generic optimization
program. In Proceedings of the 7th International
EIA (2016b). Monthly Energy Review October 2016,
IBPSA Conference, Rio de Janeiro, Brazil, August
Table 2.1. Available online at
13-15, 601-608.
http://www.eia.gov/totalenergy/data/monthly/pdf/se
c2_3.pdf. Last accessed Nov. 18, 2016. Wetter, M., W. Zuo, T. S. Nouidui, and X. Pang (2014).
Modelica Buildings library. Journal of Building
FMI (2016). Functional Mock-up Interface. Available
Performance Simulation 7(4), 253-270.
online at https://www.fmi-standard.org/start. Last
accessed Nov. 18, 2016. Wetter, M., M. Fuchs, P. Grozman, L. Helsen, F.
Jorissen, M. Lauster, D. Muller, C. Nytsch-Geusen,
Hunter, J. D. (2007). Matplotlib: A 2D graphics
D. Picard, P. Sahlin, and M. Thorade (2015). IEA
environment. Computing in Science and
EBC Annex 60 Modelica Library -- An international
Engineering 9(3), 90-95.
collaboration to develop a free open-source model
Jobling, C. P., P. W. Grant, H. A. Barker, and P. library for buildings and community energy
Townsend (1994). Object oriented programming in systems. In Proceedings of the 14th Conference of
control system design: a survey. Automatica 30(8), International Building Performance Simulation
1221-1261. Association, Hyderabad, India, Dec. 7-9.
Johnson Controls (2015). Johnson Controls helps Wetter, M., and C. van Treeck (2015). IBPSA Project 1.
Stanford University drastically reduce water and Available Online at https://ibpsa.github.io/project1/.
energy use in new central plant. Available online at Last accessed Mar. 3, 2017.
http://www.johnsoncontrols.com/media-
Wetter, M., M. Bonvini, and T. S. Nouidui (2016).
center/news/press-releases/2015/06/15/johnson-
Equation-based languages – A new paradigm for
controls-helps-stanford-university-drastically-
building energy modelling, simulation and
reduce-water-and-energy-use-in-new-central-plant.
optimization. Energy and Buildings 117, 290-300.
Last accessed Nov. 18, 2016.
Zakula, T., P. R. Armstrong, and L. Norford (2014).
Mattsson, S. E. and H. Elmqvist (1997). Modelica – An
Modeling environment for model predictive control
international effort to design the next generation
of buildings. Energy and Buildings, 85, 549-559.
modeling language. In 7th IFAC Symposium on

Proceedings of the 15th IBPSA Conference 1390

San Francisco, CA, USA, Aug. 7-9, 2017