A Realistic Dataset for the Smart Home Device Scheduling Problem for DCOPs

02/22/2017 ∙ by William Kluegel, et al. ∙ University of Michigan New Mexico State University 0

The field of Distributed Constraint Optimization has gained momentum in recent years thanks to its ability to address various applications related to multi-agent cooperation. While techniques to solve Distributed Constraint Optimization Problems (DCOPs) are abundant and have matured substantially since the field inception, the number of DCOP realistic applications and benchmark used to asses the performance of DCOP algorithms is lagging behind. To contrast this background we (i) introduce the Smart Home Device Scheduling (SHDS) problem, which describe the problem of coordinating smart devices schedules across multiple homes as a multi-agent system, (ii) detail the physical models adopted to simulate smart sensors, smart actuators, and homes environments, and (iii) introduce a DCOP realistic benchmark for SHDS problems.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 2

page 3

page 4

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

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.

Figure 1: Illustration of a Neighborhood of Smart Homes

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.

The ASR of Equation (1) is illustrated in Figure 1(left) by dotted red lines on the graph. The PSRs are not shown as they must hold for all time steps.

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.

In the example of Figure 1, the evaluated schedule is a feasible schedule since the trajectories of both the battery_charge and cleanliness states satisfy both the active scheduling rule (1) and the passive scheduling rules (2) and (3).

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

Figure 2: Floor plans for a small (left), medium (center), and large (right) house.

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
Table 1: House structural parameters.

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
Table 2: List of sensors.

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
Table 3: List of actuators.

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
Table 4: Electric vehicles [3] and robotic vacuum cleaner[1] batteries physical model.

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
Table 5: Pacific Gas & Electric Co. pricing schema

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
Table 6: Scheduling (active) rules
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
Table 7: Scheduling (active) rules

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
Table 8: Physical models: Values and assumptions

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
Table 9: Des Moines
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
Table 10: Boston
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
Table 11: San Francisco

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.