1 Introduction
Distributed Constraint Optimization Problems (DCOPs) [11, 15, 18]
have emerged as one of the prominent agent models to govern the agents’ autonomous behavior, where both algorithms and communication models are driven by the structure of the specific problem. Since the research field inception a wide variety of algorithms have been proposed to solve DCOPs and typically classified as being either
complete or incomplete, based on whether they can guarantee the optimal solution or they trade optimality for shorter execution times. In addition, each of these classes can be categorized into several groups, depending on the degree of locality exploited by the algorithms (e.g., partial centralization) [9, 10, 16], the way local information is updated (e.g., synchronous [10, 14, 15] or asynchronous [5, 8, 11]), and the type of exploration process adopted (e.g., search-based [9, 11, 19], inference-based [15, 5], or sampling-based [13, 12, 6]).While techniques to solve DCOPs are abundant and have matured substantially since the field inception, the number of DCOP realistic applications and benchmarks used to assess the performance of DCOP algorithms is lagging behind. Typical DCOP algorithms are evaluated on artificial random problems, or simplified problems that are adapted to the often unrealistic assumptions made by DCOP algorithms (e.g., that each agent controls exactly one variable, and that all problem constraints are binary). To assess the performance of DCOP algorithms it is necessary to introduce realistic problem benchmark of deployable applications.
Motivated by these issues, we recently introduced the Smart Home Device Scheduling (SHDS) problem [7], which formalizes the problem of coordinating smart devices (e.g., smart thermostats, circulator heating, washing machines) schedules across multiple smart homes as a multi-agent system (MAS). The SHDS problem is suitable to be modeled as a DCOP due to the presence of both complex individual agents’ goals, describing homes’ energy price consumption, as well as a collective agents’ goal, capturing the energy peaks reduction.
In this document we introduce a set of realistic synthetic benchmarks for the SHDS problem for DCOPs. We report the details of the physical models adopted to simulate smart home sensors and actuators, as well as home environments, and describe how the actuator’s actions affects the environments of a home (e.g., home’s temperature, cleanliness, humidity). The datasets, models, and code adopted to generate the SHDS datasets are available at: https://github.com/persoon/SHDS_dataset.
1.0.1 Dcop
A Distributed Constraint Optimization Problem (DCOP) [11, 18] is described by a tuple , where: is a set of variables; is a set of finite domains (i.e., ); is a set of utility functions (also called constraints), where and is the set of the variables (also called the scope) relevant to ; is a set of agents; and is a function that maps each variable to one agent. specifies the utility of each combination of values assigned to the variables in . A partial assignment is a value assignment to a set of variables that is consistent with the variables’ domains. The utility is the sum of the utilities of all the applicable utility functions in . A solution is a partial assignment for all the variables of the problem, i.e., with . We will denote with a solution, while is the value of in . The goal is to find an optimal solution .
2 Scheduling Device in Smart Homes
A Smart Home Device Scheduling (SHDS) problem is defined by the tuple , where: is a neighborhood of smart homes, capable of communicating with one another; is a set of smart devices, where is the set of devices in the smart home (e.g., vacuum cleaning robot, smart thermostat). is a set of locations, where is the set of locations in the smart home (e.g., living room, kitchen); is the set of state properties of the smart homes (e.g., cleanliness, temperature); is the set of devices state properties (e.g., battery charge for a vacuum robot); is the planning horizon of the problem. We denote with the set of time points; represents the real-time pricing schema adopted by the energy utility company, which expresses the cost per kWh of energy consumed by consumers. Finally, we use to denote the set of all possible states for state property (e.g., all the different levels of cleanliness for the cleanliness property). Figure 1(right) shows an illustration of a neighborhood of smart homes with each home controlling a set of smart devices.
2.1 Smart Devices
For each home , the set of smart devices is partitioned into a set of actuators and a set of sensors . Actuators can affect the states of the home (e.g., heaters and ovens can affect the temperature in the home) and possibly their own states (e.g., vacuum cleaning robots drain their battery power when running). On the other hand, sensors monitor the states of the home. Each device of a home is defined by a tuple , where denotes the relevant location in the home that it can act or sense, is the set of actions that it can perform, maps the actions of the device to the relevant state properties of the home, and maps the actions of the device to its relevant state properties. We will use the following running example throughout this paper.
Example 1
Consider a vacuum cleaning robot with location . The set of possible actions is and the mappings are:
where represents a null state property.

2.2 Device Schedules
To control the energy profile of a smart home we need to describe the behavior of the smart devices acting in the smart home during time. We formalize this concept with the notion of device schedules.
We use to denote the action of device at time step , and to denote the set of actions of the devices in at time step .
Definition 1 (Schedule)
A schedule is a sequence of actions for the devices in within the time interval from to .
Consider the illustration of Figure 1(left). The top row of Figure 1(left) shows a possible schedule for a vacuum cleaning robot starting at time 1400 hrs, where each time step is 30 minutes. The robot’s actions at each time step are shown in the colored boxes with letters in them: red with ‘S’ for stop, green with ‘R’ for run, and blue with ‘C’ for charge.
At a high-level, the goal of the SHDS problem is to find a schedule for each of the devices in every smart home that achieve some user-defined objectives (e.g., the home is at a particular temperature within a time window, the home is at a certain cleanliness level by some deadline) that may be personalized for each home. We refer to these objectives as scheduling rules.
2.3 Scheduling Rules
We define two types of scheduling rules: Active scheduling rules (ASRs) that define user-defined objectives on a desired state of the home (e.g., the living room is cleaned by 1800 hrs), and Passive scheduling rules (PSRs) that define implicit constraints on devices that must hold at all times (e.g., the battery charge on a vacuum cleaning robot is always between 0% and 100%). We provide a formal description for the grammar of scheduling rules in Section 3.4.
Example 2
The scheduling rule (1) describes an ASR defining a goal state where the living room floor is at least 75% clean (i.e., at least 75% of the floor is cleaned by a vacuum cleaning robot) by 1800 hrs:
living_room cleanliness 75 before 1800 | (1) | ||
battery_charge 0 always | (2) | ||
battery_charge 100 always | (3) |
and scheduling rules (2) and (3) describe PSRs stating that the battery charge of the vacuum robot needs to be between 0 and 100 % of its full charge at all the times:
We denote with a scheduling rule over a state property , and time interval . Each scheduling rule indicates a goal state at a location or on a device of a particular state property that must hold over the time interval . The scheduling rule goal state is either a desired state of a home, if it is an ASR (e.g., the cleanliness level of the room floor) or a required state of a device or a home, if it is a PSR (e.g., the battery charge of the vacuum cleaning robot).
Each rule is associated with a set of actuators that can be used to reach the goal state. For instance, in our Example (2), correspond to the vacuum cleaning robot , which can operate on the living room floor. Additionally, a rule is associated with a sensor capable of sensing the state property . Finally, in a PSRs the device can also sense its own internal states.
2.4 Feasibility of Schedules
To ensure that a goal state can be achieved across the desired time window the system uses a predictive model of the various state properties. This predictive model captures the evolution of a state property over time and how such state property is affected by a given joint action of the relevant actuators. We describe the details of the physical predictive models used to generate our benchmark set in Section 3.3.
Definition 2 (Predictive Model)
A predictive model for a state property (of either the home or a device) is a function , where denotes an infeasible state and .
In other words, the model describes the transition of state property from state at time step to time step when it is affected by a set of actuators running joint actions :
(4) |
where is a function describing the effect of the actuators’ joint action on state property . We assume here, w.l.o.g. that the state of properties are numeric—when this is not the case, a mapping to the possible states to a numeric representation can be easily defined.
Notice that a recursive invocation of a predictive model allows us to predict the trajectory of a state property for future time steps, given a schedule of actions of the relevant actuators . Let us formally define this concept.
Definition 3 (Predicted State Trajectory)
Given a state property , its current state at time step , and a schedule of relevant actuators , the predicted state trajectory of that state property is defined as:
(5) |
Consider the device scheduling example in Figure 1(left). The predicted state trajectories of the battery_charge and cleanliness state properties are shown in the second and third rows of Figure 1(left). These trajectories are predicted given that the vacuum cleaning robot will take on the schedule shown in the first row of the figure. The predicted trajectories of these state properties are also illustrated in the graph, where the dark grey line shows the states for the robot’s battery charge and the black line shows the states for the cleanliness of the room.
Notice that to verify if a schedule satisfies a scheduling rule it is sufficient to check that the predicted state trajectories are within the set of feasible state trajectories of that rule. Additionally, notice that each active and passive scheduling rule defines a set of feasible state trajectories. For example, the active scheduling rule of Equation (1) allows all possible state trajectories as long as the state at time step 1800 is no smaller than 75. We use to denote the set of states that are feasible according to rule of state property at time step . More formally, a schedule satisfies a scheduling rule (written as ) iff:
(6) |
where is the state of state property at time step .
Definition 4 (Feasible Schedule)
A schedule is feasible if it satisfies all the passive and active scheduling rules of each home in the SHDS problem.
2.5 Optimization Objective
In addition to finding feasible schedules, the goal in the SHDS problem is to optimize for the aggregated total cost of energy consumed.
Each action of device in home has an associated energy consumption , expressed in kWh. The aggregated energy across all devices consumed by at time step under trajectory is:
(7) |
where is the action of device at time in the schedule . The cost associated to schedule in home is:
(8) |
where is the home background load produced at time , which includes all non-schedulable devices (e.g., TV, refrigerator), and sensor devices, which are always active, and is the real-time price of energy per kWh at time .
The objective of an SHDS problem is that of minimizing the following weighted bi-objective function:
(9) | ||||
subject to: | (10) |
where are weights, is the aggregated monetary cost across all homes ; and is a quadratic penalty function on the aggregated energy consumption across all homes . Since the SHDS problem is designed for distributed multi-agent systems, in a cooperative approach optimizing may require each home to share its energy profile with each other home. To take into account data privacy concerns and possible high network loads, we decompose the set of homes into neighboring subsets of homes , so that can be optimized independently within each subset. These coalitions can be exploited by a distributed algorithm to (1) parallelize computations between multiple groups and (2) avoid data exposure over long distances or sensitive areas. Finally, constraint (10) defines the valid trajectories for each scheduling rule , where is the set of all scheduling rules of home .
2.6 DCOP Mapping
One can map the SHDS problem to a DCOP as follows:
Agents: Each agent in the DCOP is mapped to a home .
Variables and Domains: Each agent controls the following set of variables:
For each actuator and each time step , a variable whose domain is the set of actions in . The sensors in are considered to be always active, and thus not directly controlled by the agent.
An auxiliary interface variable whose domain is the set , which represents the aggregated energy consumed by all the devices in the home at each time step .
Constraints: There are three types of constraints:
Local soft constraints (i.e., constraints that involve only variables controlled by the agent) whose costs correspond to the weighted summation of monetary costs, as defined in Equation (8).
Local hard constraints that enforce Constraint (10). Feasible schedules incur a cost of 0 while infeasible schedules incur a cost of .
Global soft constraints (i.e., constraints that involve variables controlled by different agents) whose costs correspond to the peak energy consumption, as defined in the second term in Equation (9).
3 Model Parameters and Realistic Data Set Generation
This section describes the parameters and models adopted in our SHDS datasets generation. We first describe the house structural parameters, which are used in turn to calculate the house predictive models. Next, we report a detailed list of the smart devices adopted in our datasets, discussing their power consumptions and effects on the house environments. We then describe the predictive models adopted to capture changes in the house’s environments and devices’ states. Finally, we report the BNF for the scheduling rules introduced in Section 2.3, and the pricing scheme adopted in our experiments.
3.1 House Structural Parameters
We consider three house sizes (small, medium, and large). The floor plans for three house structures are shown in Figure 2. Our house structural model simplifies the floor plans shown in Figure 2 by ignoring internal walls. This abstraction is sufficient to capture the richness of the predictive models introduced in Section 2.4. Table 1 reports the parameters of the houses adopted in our SHDS dataset. The house sizes are expressed in meters (). The walls height is assumed to be and the window area denotes the area of the walls covered by windows. The overall heat transfer coefficient (also referred to as U-value) describes how well a building element conducts heat. It is defined as the rate of heat transfer (in watts) through one unit area () of a structure divided by the difference in temperature across the structure [17].
Fix Reference here
The walls material is considered to be a poured concrete () with a Heat-Transfer Coefficient () of . We consider vertical double glazed windows, with distance between glasses whose Heat-Transfer Coefficient () is . Additionally, we consider a wood roof with insulation, with Heat-Transfer Coefficient () of . Finally, we consider a wood door, with Heat-Transfer Coefficient of . These are commonly adopted materials in the US house construction industry [17]. We assume a background load consumption which account of a medium-size refrigerator (), a wireless router (), and a set of light bulbs (collectively ) [17]. The heat gain from the background house appliances is computed according to [17](Table 9.8). We consider the heat gain from people within the house, and computed as in [17](Table 9.7), assuming a metabolic rate as light office work.
Structural Parameters | small | medium | large | Structural Parameters | small | medium | large |
house size () | 1.1 | 1.1 | 1.1 | ||||
walls area () | 67.2 | 96 | 129.6 | lights energy density () | 9.69 | 9.69 | 9.69 |
window area () | 7.2 | 10 | 16 | background load (kW) | 0.166 | 0.166 | 0.166 |
3.9 | 3.9 | 3.9 | background heat gain (W) | 50 | 50 | 50 | |
2.8 | 2.8 | 2.8 | people heat gain (Btu/h) | 400 | 400 | 400 |
3.2 Smart Devices
In this section we report the complete list of smart devices (sensors and actuators) adopted by the smart homes in our SHDS datasets.
Sensors Table 2 reports the sensors adopted in our SHDS problem. For each sensor, we report an identifier (ID), the state property (see Section 2.1) it senses, and its location in the house. All sensors are considered to be constantly active, sensing a single state property at a location (e.g., an air temperature sensor is located in a house room, a charge sensor is located on a device).
ID | State property | Location | ID | State property | Location |
01 | air temperature | house room | 08 | dish cleanliness | appliance |
02 | floor cleanliness (dust) | house room | 09 | air humidity | house room |
03 | temperature | appliance | 10 | luminosity | house room |
04 | battery charge | appliance | 11 | occupancy | house room |
05 | bake | appliance | 12 | movement | house room |
06 | laundry wash | appliance | 13 | smoke detector | house room |
07 | laundry dry | appliance |
Actuators Table 3 reports the list of the actuators. It tabulates the type of actuator and its model, its possible actions, the power consumption (in kWh), the state properties affected by each of its action, and the effects () on the associated predictive models in the small, medium, and large house sizes. The latter represent the incremental quantity which affects the physical system, given the action of the actuator, as defined in Equation 4. We detail the calculation of the house and devices physical models below.
Actuator | Model | Actions | Consumption (kWh) | State properties (ID) | Effects Small() | Effects Medium() | Effects Large() |
Heater | Bryant 697CN030B | off | |||||
fan | |||||||
heat | |||||||
Cooler | LG LW1212ER | off | |||||
fan | |||||||
cool | |||||||
Waterheater | E52-50R-045DV | off | |||||
on | |||||||
Vacuum Bot | iRobot Roomba 880 | off | |||||
vacuum | |||||||
charge | |||||||
Electric Vehicle | Tesla Model S | off | |||||
charge | |||||||
Clothes Washer | GE WSM2420D3WW | off | |||||
wash (Regular) | |||||||
spin (Regular) | |||||||
rinse (Regular) | |||||||
wash (Perm-Press) | |||||||
spin (Perm-Press) | |||||||
rinse (Perm-Press) | |||||||
wash (Delicates) | |||||||
spin (Delicates) | |||||||
rinse (Delicates) | |||||||
Clothes Dryer | GE WSM2420D3WW | off | |||||
on (Regular) | |||||||
on (Perm-Press) | |||||||
on (Timed) | |||||||
Oven | Kenmore 790.91312013 | off | |||||
bake | |||||||
broil | |||||||
Dishwasher | Kenmore 665.13242K900 | off | |||||
wash | |||||||
rinse | |||||||
dry |
switch columns state property with consumption
3.3 Physical models
In this section we describe the physical models used to compute the effects values of the actuators’ actions on a predictive model (see Table 3). These values, in turn, are adopted within the SHDS predictive models as described in Equation (4).
Battery (Dis)charge Model The battery charge/discharge model we adopt for our battery-powered devices is as follows. For a given battery with capacity (expressed in KWh), voltage , and electric charge (expressed in ampere-hour (Ah)), and assuming a 100% charging/discharging efficiency, the battery charge time and discharge time are computed respectively as:
(11) |
expressed in hours, where and are, respectively, the charging amperage and the in-use amperage. Following https://goo.gl/l5TGtz and https://goo.gl/NmO0fY we report the battery parameters for our Electric Vehicle and robotic vacuum cleaner in Table 4. The devices’ action effects for charging and discharging time are computed by dividing the total charging and discharging times by .
Tesla Model S | iRobot Roomba 880 | |||
Slow Charge | Regular Charge | Super Charger | ||
240 | 240 | 240 | 120 | |
354 Ah | 354 Ah | 354 Ah | 3 Ah | |
48 A | 72 A | 500 A | 1.25 A | |
60 A | 60 A | 60 A | 0.75 A | |
7 hr 22 min | 5 hr | 43 min | 2 hr 24 min | |
6 hr | 6 hr | 6 hr | 4 hr |
Air Temperature Model The air temperature predictive model is computed following standard principle of heating and ventilation [17] and described as follows. Let be the ventilation conductance: where is the volume flow rate, set to , is the density of the air, set to 0.75, and is the specific heat of the air, set to 0.24 following [17]. The house heat loss coefficient is:
(12) |
where , , and are respectively, the heat transfer coefficients for the walls, roof, and windows of the house, and , , and are respectively the the areas for walls, roof, and windows. Their values are provided in Table 1. Let and be the current and a target temperatures; the heating load is given by:
(13) |
The heating load defines the quantity of heat per unit time (in BTU) that must
be supplied in a building to reach the target temperature , from the
given temperature .
Given the heating load and the heater capacity of a heater/cooler,
the time the device needs to run to reach the desired temperature is given by:
.
Heating or cooling load is also effected by the outdoor and indoor temperature difference.
Consider the example where = and = , and the outdoor temperature changes from to = .
We can calculate the new load due to change in temperature by the following relationship given below:
(14) |
The above expression shows that an outdoor temperature drops of , causes the heating load to increase by a factor of 1.4 (w.r.t. the previous heating load ). In our model we need to compute the change in temperature per time step (). This can be done using the heat loss relationship:
(15) |
where is the mass of the air and is the specific heat of air. In our model, depends on volume flow rate of an air in the house, and = .
Water Temperature Model The rise in the water temperature per unit of time ( value) is dependent on the difference in the water temperature flowing into the water heater and the amount of water flowing out of the water heater, as well as water usage We considered a gas-fired demand water heater(tankless). The water usage depends on household size and multiple user activities To calculate the water temperature, in our model, we used the highest potential peak water usage following [2, 4], and corresponding to 26.50 liters/min (small house), 29.34 liters/min (medium house), and 38.38 liters/min (large house). The rise in temperature is for 18.93 liters/minute of water usage [2]. Thus the rise in temperature for our small, medium, and large house, are, respectively, , , and .
Can you use liters rather than gallons?
Cleanliness Model Our floor cleanliness model is computed by using the equation: where, represents the area of the room (in m) and is the amount of time (in minutes) it takes the robotic vacuum cleaner to vacuum the entire room. Consumer reports found that it took 57 minutes for the Roomba to clean a 17.84 m room [1] (which is approximately /min). In our experiment’s datasets we use three different areas. , , and
. Thus the the estimated times to cover a 100% floor for the small, medium, and large houses are, repsectively:
153.35, 306.71, and 575.08 minutes. The corresponding value of Table 3 (which is a percentage) is computed as:All other predictive models (e.g., laundry wash and dry, bake, dish cleanliness, etc.) simply capture the time needed for a device to achieve the required goals by checking that accumulated device effects achieves the desired property. This is discussed in the dataset generation, in Section 4.
3.4 Scheduling Rules
We report, as follows, the complete Backus-Naur Form (BNF) for the scheduling rules for a smart home , introduced in Section 2.2
In our dataset the device states are mapped to numeric values, i.e., , for all .
3.5 Pricing Schema
For the evaluation of our SHDS datasets we adopted a pricing schema used by the Pacific Gas & Electric Co. for its customers in parts of California,111https://goo.gl/vOeNqj which accounts for 7 tiers ranging from $0.198 per kWh to $0.849 per kWh, reported in Table 5
time start | 0:00 | 8:00 | 12:00 | 14:00 | 18:00 | 22:00 |
time end | 7:59 | 11:59 | 13:59 | 17:59 | 21:59 | 23:59 |
price ($) | 0.198 | 0.225 | 0.249 | 0.849 | 0.225 | 0.198 |
4 SHDS Dataset
We now introduce a dataset for the SHDS problem for DCOPs. We generate synthetic microgrid instances sampling neighborhoods in three cities in the United States (Des Moines, IA; Boston, MA; and San Francisco, CA) and estimate the density of houses in each city. The average density (in houses per square kilometers) is 718 in Des Moines, 1357 in Boston, and 3766 in San Francisco. For each city, we created a 200m200m grid, where the distance between intersections is 20m, and randomly placed houses in this grid until the density is the same as the sampled density. We then divided the city into (=) coalitions, where each home can communicate with all homes in its coalition. Finally, we ensure that there no two coalitions are disjoint. Tables 9, 10, and 11 report, respectively, the Des Moines, Boston, and San Francisco instances, where we vary (i) the number of agents ()—up to 1883 for the largest instances—, (ii) the number of coalitions (), and (iii) the number of actuators within each home .
Each home device has an associated active scheduling rule that is randomly generated, and a number of passive rules that must always hold. The parameters to generate active and passive rules are reported, respectively, in Table 6 and Table 7. The time predicates for these rules are generated at random within the given horizon. Additionally, the relations and goals states are randomly generated sampling from the sets corresponding, respectively, to the columns and of Table 6.
We generate a total of problem instances (available at: https://github.com/persoon/SHDS_dataset). We set , and report in Table 8 a summary of the parameters’ settings for our smart homes physical models.
Room | air temperature | |||
Room | floor cleanliness | |||
Electric Vehicle | charge | |||
Water heater | temperature | |||
Clothes Washer | laundry wash | |||
Clothes Drier | laundry dry | |||
Oven | bake | |||
Dishwasher | dishes cleanliness |
Room | air temperature | 0 | EV | charge | 100 | ||
Room | air temperature | 30 | Water heater | temperature | 10 | ||
Room | floor cleanliness | 0 | Water heater | temperature | 42 | ||
Ooom | floor cleanliness | 100 | Oven | bake | |||
Roomba | charge | 0 | Clothes Washer | laundry wash | |||
Roomba | charge | 100 | Clothes Drier | laundry dry | |||
EV | charge | 0 | Dishwasher | dishes cleanliness |
Additionally, we provide upper bounds (in the obj column) for each for the instances (Tables 9, 10, and 11 report a subset of the SHDS dataset) by solving an uncoordinated DCOP, where each agent reports its best schedule found with a local Constraint Programming solver222We adopt the JaCoP solver (http://www.jacop.eu/) as subroutine, within a 10 seconds timeout.
Physical model | Parameter | Value (small house) | Value (medium house) | Value (large house) |
Air Temperature | 100 | 200 | 400 | |
148.48 | 296.86 | 593.75 | ||
1.0 | 1.0 | 1.0 | ||
0.75 | 0.75 | 0.75 | ||
0.24 | 0.24 | 0.24 | ||
352.24 | 544 | 764.75 | ||
22 | 22 | 22 | ||
10 | 10 | 10 | ||
4226.88 | 6528 | 9177 | ||
Floor Cleanliness | 48 m | 96 m | 180 m | |
153.35 min | 306.71 min | 575.08 min | ||
0.652% | 0.326% | 0.174% | ||
Water Temperature | household size | 2 | 3 | 4 |
liters/min usage | 26.50 | 29.34 | 38.38 | |
27.9 | 25.2 | 19.2 |
What are the in Table 7?
instance | sim. time (s) | obj | avg price ($) | avg power (kWh) | largest peak (kW) | |||
dm_7_1_3 | 7 | 1 | 3 | 28.00 | 458.27 | 1.11 | 5.55 | 8.75 |
dm_7_1_4 | 7 | 1 | 4 | 36.00 | 1385.70 | 1.83 | 9.18 | 16.85 |
dm_7_1_5 | 7 | 1 | 5 | 26.00 | 1936.87 | 2.36 | 11.30 | 20.21 |
dm_7_1_6 | 7 | 1 | 6 | 51.00 | 5122.10 | 4.06 | 19.78 | 29.55 |
dm_7_4_6 | 7 | 4 | 6 | 69.00 | 52335.95 | 4.08 | 19.57 | 32.02 |
dm_21_1_3 | 21 | 1 | 3 | 25.00 | 1280.79 | 1.06 | 5.28 | 26.28 |
dm_21_1_4 | 21 | 1 | 4 | 18.00 | 4101.46 | 1.80 | 9.06 | 48.62 |
dm_21_1_5 | 21 | 1 | 5 | 12.00 | 6070.22 | 2.44 | 11.69 | 59.66 |
dm_21_1_6 | 21 | 1 | 6 | 29.00 | 16252.47 | 4.06 | 20.03 | 92.30 |
dm_21_16_6 | 21 | 16 | 6 | 15.00 | 16435.40 | 40.43 | 200.72 | 944.80 |
dm_35_1_3 | 35 | 1 | 3 | 36.00 | 2349.93 | 1.12 | 5.58 | 44.52 |
dm_35_1_4 | 35 | 1 | 4 | 45.00 | 6982.77 | 1.81 | 9.06 | 85.63 |
dm_35_1_5 | 35 | 1 | 5 | 40.00 | 10055.69 | 2.48 | 11.73 | 99.33 |
dm_35_1_6 | 35 | 1 | 6 | 52.00 | 26355.29 | 4.02 | 19.67 | 154.89 |
dm_35_32_6 | 35 | 32 | 6 | 22.00 | 26215.24 | 4.03 | 19.66 | 152.40 |
dm_71_1_3 | 71 | 1 | 3 | 71.00 | 4814.35 | 1.13 | 5.62 | 91.13 |
dm_71_1_4 | 71 | 1 | 4 | 30.00 | 14548.58 | 1.83 | 9.20 | 170.78 |
dm_71_1_5 | 71 | 1 | 5 | 100.00 | 20180.40 | 2.43 | 11.63 | 201.66 |
dm_71_1_6 | 71 | 1 | 6 | 102.00 | 53406.99 | 4.03 | 19.72 | 314.30 |
dm_71_64_6 | 71 | 64 | 6 | 49.00 | 53170.13 | 4.01 | 19.63 | 316.57 |
dm_251_1_3 | 251 | 1 | 3 | 161.00 | 17167.95 | 1.13 | 5.62 | 320.5 |
dm_251_1_4 | 251 | 1 | 4 | 151.00 | 50798.96 | 1.82 | 9.14 | 599.9 |
dm_251_1_5 | 251 | 1 | 5 | 286.00 | 73057.18 | 2.48 | 11.80 | 721.0 |
dm_251_1_6 | 251 | 1 | 6 | 535.00 | 188736.13 | 4.02 | 19.63 | 1117.5 |
dm_251_128_6 | 251 | 128 | 6 | 66.00 | 188258.87 | 4.03 | 1.96 | 1110.78 |
instance | sim. time (s) | obj | avg price ($) | avg power (kWh) | largest peak (kW) | |||
bo_13_1_3 | 13 | 1 | 3 | 16.00 | 843.75 | 1.06 | 5.33 | 17.36 |
bo_13_1_4 | 13 | 1 | 4 | 32.00 | 2761.91 | 1.87 | 9.40 | 31.75 |
bo_13_1_5 | 13 | 1 | 5 | 80.00 | 3707.74 | 2.52 | 11.86 | 37.01 |
bo_13_1_6 | 13 | 1 | 6 | 77.00 | 9181.61 | 4.03 | 19.41 | 53.59 |
bo_13_8_6 | 13 | 8 | 6 | 25.00 | 9513.77 | 4.02 | 19.50 | 57.03 |
bo_40_1_3 | 40 | 1 | 3 | 20.00 | 2651.70 | 1.11 | 5.53 | 50.03 |
bo_40_1_4 | 40 | 1 | 4 | 26.00 | 8016.06 | 1.84 | 9.23 | 92.99 |
bo_40_1_5 | 40 | 1 | 5 | 48.00 | 11335.13 | 2.50 | 11.75 | 111.41 |
bo_40_1_6 | 40 | 1 | 6 | 63.00 | 30507.66 | 4.07 | 19.78 | 179.32 |
bo_40_32_6 | 40 | 32 | 6 | 29.00 | 29978.17 | 4.08 | 19.71 | 177.39 |
bo_67_1_3 | 67 | 1 | 3 | 5.00 | 4625.82 | 1.12 | 5.59 | 88.89 |
bo_67_1_4 | 67 | 1 | 4 | 25.00 | 13218.52 | 1.80 | 9.01 | 158.50 |
bo_67_1_5 | 67 | 1 | 5 | 26.00 | 19166.54 | 2.40 | 11.68 | 193.20 |
bo_67_1_6 | 67 | 1 | 6 | 128.00 | 49565.08 | 4.00 | 19.56 | 293.76 |
bo_67_64_6 | 67 | 64 | 6 | 21.00 | 50847.42 | 4.04 | 19.70 | 298.76 |
bo_135_1_3 | 135 | 1 | 3 | 45.00 | 8981.98 | 1.11 | 5.53 | 172.25 |
bo_135_1_4 | 135 | 1 | 4 | 170.00 | 27602.08 | 1.83 | 9.16 | 325.76 |
bo_135_1_5 | 135 | 1 | 5 | 114.00 | 38668.73 | 2.45 | 11.64 | 386.87 |
bo_135_1_6 | 135 | 1 | 6 | 184.00 | 102105.12 | 4.04 | 19.77 | 598.08 |
bo_135_128_6 | 135 | 128 | 6 | 78.00 | 101369.93 | 4.04 | 19.69 | 596.32 |
bo_474_1_3 | 474 | 1 | 3 | 949.00 | 31864.64 | 1.11 | 5.56 | 600.63 |
bo_474_1_4 | 474 | 1 | 4 | 159.00 | 95450.24 | 1.82 | 9.11 | 1136.34 |
bo_474_1_5 | 474 | 1 | 5 | 1230.00 | 136395.09 | 2.46 | 11.73 | 1358.24 |
bo_474_1_6 | 474 | 1 | 6 | 411.00 | 356417.23 | 4.04 | 19.70 | 2106.18 |
bo_474_256_6 | 474 | 256 | 6 | 49.40 | 35510.81 | 4.03 | 19.66 | 2092.18 |
instance | sim. time (s) | obj | avg price ($) | avg power (kWh) | largest peak (kW) | |||
sf_37_1_3 | 37 | 1 | 3 | 121.00 | 2621.67 | 1.13 | 5.67 | 4.77 |
sf_37_1_4 | 37 | 1 | 4 | 121.00 | 7666.59 | 1.85 | 9.30 | 89.67 |
sf_37_1_5 | 37 | 1 | 5 | 151.00 | 10345.77 | 2.53 | 11.67 | 102.47 |
sf_37_1_6 | 37 | 1 | 6 | 116.00 | 28216.43 | 4.00 | 19.75 | 166.31 |
sf_37_32_6 | 37 | 32 | 6 | 30.00 | 26926.71 | 4.00 | 19.45 | 158.23 |
sf_112_1_3 | 112 | 1 | 3 | 31.00 | 75331.60 | 1.11 | 5.54 | 143.33 |
sf_112_1_4 | 112 | 1 | 4 | 47.00 | 23099.46 | 1.84 | 9.25 | 270.51 |
sf_112_1_5 | 112 | 1 | 5 | 244.00 | 32254.58 | 2.44 | 11.73 | 319.10 |
sf_112_1_6 | 112 | 1 | 6 | 59.00 | 84245.82 | 4.04 | 19.66 | 493.40 |
sf_112_64_6 | 112 | 64 | 6 | 78.00 | 85088.67 | 4.06 | 19.79 | 496.49 |
sf_188_1_3 | 188 | 1 | 3 | 162.00 | 124835.94 | 1.11 | 5.52 | 234.68 |
sf_188_1_4 | 188 | 1 | 4 | 163.00 | 381943.73 | 1.82 | 9.14 | 452.78 |
sf_188_1_5 | 188 | 1 | 5 | 142.00 | 547287.48 | 2.47 | 11.82 | 533.91 |
sf_188_1_6 | 188 | 1 | 6 | 230.00 | 140592.96 | 4.04 | 19.62 | 830.50 |
sf_188_128_6 | 188 | 128 | 6 | 430.00 | 141294.31 | 4.02 | 19.68 | 830.99 |
sf_376_1_4 | 376 | 1 | 4 | 556.00 | 74580.82 | 1.81 | 9.06 | 894.12 |
sf_376_1_5 | 376 | 1 | 5 | 735.00 | 108104.93 | 2.48 | 11.74 | 1072.98 |
sf_376_1_6 | 376 | 1 | 6 | 1033.00 | 283038.14 | 4.03 | 19.69 | 1667.89 |
sf_376_256_6 | 376 | 256 | 6 | 302.00 | 28306328 | 4.04 | 19.73 | 1652.88 |
5 Conclusions
With the proliferation of smart devices, the automation of smart home scheduling can be a powerful tool for demand-side management within the smart grid vision. In this paper we proposed the Smart Home Device Scheduling (SHDS) problem, which formalizes the device scheduling and coordination problem across multiple smart homes as a multi-agent system, and its mapping to a DCOP. Furthermore, we described in great details the physical models adopted to model the smart home’s sensors and actuators, as well as the physical model regulating the effect of the devices actions on the house environments properties (e.g., temperature, cleanliness). Finally, we reported a realistic dataset for the SHDS problem for DCOPs which includes 2351 instances of increasing difficulty.
References
- [1] Roomba 880 specs. http://www.consumerreports.org/products/robotic-vacuum/roomba-880-290102/specs/. [Online; accessed 18-February-2017].
- [2] Sizing a new water heater. https://www.energy.gov/energysaver/sizing-new-water-heater. [Online; accessed 18-February-2017].
- [3] Tesla model s specifics. https://www.tesla.com/models.
- [4] Typical water used in normal home activities. http://www.pittsfield-mi.gov/DocumentCenter/View/285. [Online; accessed 18-February-2017].
- [5] A. Farinelli, A. Rogers, A. Petcu, and N. Jennings. Decentralised coordination of low-power embedded devices using the Max-Sum algorithm. In AAMAS, pages 639–646, 2008.
- [6] F. Fioretto, W. Yeoh, and E. Pontelli. A dynamic programming-based MCMC framework for solving DCOPs with GPUs. In Proceedings of the International Conference on Principles and Practice of Constraint Programming (CP), pages 813–831, 2016.
- [7] F. Fioretto, W. Yeoh, and E. Pontelli. A multiagent system approach to scheduling devices in smart homes. In AAMAS, page (to appear), 2017.
- [8] A. Gershman, A. Meisels, and R. Zivan. Asynchronous Forward-Bounding for distributed COPs. JAIR, 34:61–88, 2009.
- [9] K. Hirayama and M. Yokoo. Distributed partial constraint satisfaction problem. In CP, pages 222–236, 1997.
- [10] R. Mailler and V. Lesser. Solving distributed constraint optimization problems using cooperative mediation. In AAMAS, pages 438–445, 2004.
- [11] P. Modi, W.-M. Shen, M. Tambe, and M. Yokoo. ADOPT: Asynchronous distributed constraint optimization with quality guarantees. AIJ, 161(1–2):149–180, 2005.
- [12] D. T. Nguyen, W. Yeoh, and H. C. Lau. Distributed Gibbs: A memory-bounded sampling-based DCOP algorithm. In AAMAS, pages 167–174, 2013.
- [13] B. Ottens, C. Dimitrakakis, and B. Faltings. DUCT: An upper confidence bound approach to distributed constraint optimization problems. In AAAI, pages 528–534, 2012.
- [14] J. Pearce and M. Tambe. Quality guarantees on k-optimal solutions for distributed constraint optimization problems. In IJCAI, pages 1446–1451, 2007.
- [15] A. Petcu and B. Faltings. A scalable method for multiagent constraint optimization. In IJCAI, pages 1413–1420, 2005.
- [16] A. Petcu, B. Faltings, and R. Mailler. PC-DPOP: A new partial centralization algorithm for distributed optimization. In IJCAI, pages 167–172, 2007.
- [17] M. J. W and J. E. , Braun. Principles of Heating, Ventilation and Air Conditioning in Buildingss. Wiley, 2012.
- [18] W. Yeoh and M. Yokoo. Distributed problem solving. AI Magazine, 33(3):53–65, 2012.
- [19] W. Zhang, G. Wang, Z. Xing, and L. Wittenberg. Distributed stochastic search and distributed breakout: Properties, comparison and applications to constraint optimization problems in sensor networks. AIJ, 161(1–2):55–87, 2005.
Comments
There are no comments yet.