**4. Case Study and Real-Time Simulation**

This part explains a case study for validating and surveying the performance of the developed model under different challenges. To do this, it is considered that there is a small village with a lot of residential and commercial consumers, and only 27 of the residential consumers have direct DR contract with the aggregator. This means that the aggregator has no interaction with other consumers that are not participating in the DR programs. In the aggregator network, there are 10 consumers equipped with Photovoltaic (PV) panels as RERs, and five consumers with energy storage system (ESS). The use of RERs makes the aggregator capable to shift the load in the high PV generation periods, as the energy produced by this resource is uncontrollable. Figure 5 shows the village and the related aggregator network. In this case study, a part of the DR participants in the aggregator is being emulated by a set of laboratory equipment, so-called resistive loads bench in this paper. In this way, the aggregator's performance can be surveyed in both simulation and experimental aspects.

**Figure 5.** Schematic of the aggregator network in the case study.

The resistive loads bench consists of six resistive consumer loads that each of which has a nominal capacity of 4 kW. The bench is equipped with a set of controlling and monitoring devices, including a programmable logic controller (PLC) as a central controller of the bench, a set of relays to control the rate of consumption in each load, and a set of energy meters and commercial smart meters in order to monitor the real-time consumption of the loads. To survey both numerical and experimental features of the aggregator, a MATLAB™/Simulink model has been developed representing the electrical network of the 27 consumers in the aggregator model, as Figure 6 shows. Moreover, the OP5600 real-time simulator has been utilized to integrate the resistive loads bench in the Simulink model as hardware-in-the-loop (HIL). In fact, OP5600 executes the Simulink model in real-time enabling the user to control and monitor real hardware resources outside of simulation environments. This is done through several communication protocols as well as Digital and Analog slots in OP5600. More information about the performance of OP5600 and HIL methodology are available in [12].

**Figure 6.** Real-Time simulation model of aggregator integrated with HIL methodology.

Regarding the DR programs, three types of programs are considered that consumers are able to establish with the aggregator, as Table 1 shows. Each program has its own features and specifications, which the aggregator defined according to the instructions and regulations of the upstream network players, such as market operator and DR program manager.


**Table 1.** DR contracts available for consumers to establish with aggregator.

The DR programs and the related remuneration rates shown in Table 1, has been developed by the authors in the scope of their previous works, and only the most relevant description has been mentioned in this part. More detailed information about these DR programs is available in [29]. According to Table 1, if a consumer establishes a contract with the aggregator for DLC T1, it will give permission to the aggregator to directly control its air conditioner, and in exchange, the consumer receives an incentive of 0.05 EUR/kWh for the reduction. In the DLC T2 contract, the aggregator is able to directly control the washing machine and dishwasher of the DR participant for a contractual number

of events per month. Consumers who participate in DLC T2 receive an incentive of 0.06 EUR/kWh for the reduction. The last DR contract that consumers can establish with aggregator is IDRP. As this program is voluntary, the consumer can decide to participate or not. Therefore, a longer notification time is considered for this program, so the consumer has an adequate amount of time to make a decision. Table 2 demonstrates the capacity of the associated devices in all 27 consumers related to the aggregator network. The capacities shown on the same table are in kiloWatt (kW). As is clear in Table 2, each consumer has at least one DR contract with the aggregator. This means that the associated devices dedicated in Table 2, are being controlled by aggregator in DLC T1 and T2 programs, and by consumer itself in IDRP. The capacities shown in Table 2 are an average between the minimum and maximum active power consumption of each during an entire day.


**Table 2.** Controllable devices involved in the DR programs (AC = Air Conditioner, WM = Washing Machine, DW= Dishwasher, WH= Water Heater, FH = Fan Heater).

Furthermore, as Table 2 shows, 85% of consumers are equipped with air conditioner, 26% of them have washing machine, 52% include dish washer, 33% have water heater, and 22% of them have fan heater. Figure 7 illustrates a day-ahead consumption and generation profile of the entire aggregator network as well as available DR capacities presumed for the case study based on Table 2. The data shown in Figure 7 are for a random winter day with a 15-min time interval, and adapted from a research project [30] related to the implementation of an intelligent energy management system in two small cities in Portugal.

The consumption shown in Figure 7 is only related to the aggregator network (27 consumers) and not to the entire village. Moreover, the uncontrollable part of consumption is related to the devices on the consumer side that aggregator has no interaction with them. In this case study, it is considered that the aggregator receives a DR event from the DR program manager with 10 kW as the reduction baseline, starting at 12:00 PM for two hours. Also, the aggregator is notified one hour in advance. The reason for this DR event could be a technical fault or any economic causes in the main grid. Figure 8 shows the DR event applied in the aggregator consumption profile.

**Figure 7.** Aggregator consumption profile and stacked available DR capacities.

As Figure 8 shows, the reduced consumption during the DR event has been shifted to some periods after the event that have a high rate of PV generation. This enables the aggregator to use the energy produced by the local resources. Since the notification time of the event is one hour in advance, the aggregator should reach the reduction baseline for one hour (i.e., ramp period). Therefore, the aggregator starts announcing the consumers one by one to participate in the event. In the meantime, if some consumers have delay on replying to the DR announcement, the aggregator is able to use and discharge the available ESS in order to compensate the response time of the consumers. Also, the aggregator adjusts its internal reduction baseline to around 15 kW for keeping the consumption rate at 20 kW. This is due to overcoming the possible issues during the event, namely some consumers opting out.

**Figure 8.** Proposed DR event applied in the aggregator consumption profile.

In practice, a consumption profile with a 15-min time interval is not that applicable for remuneration and scheduling purposes, as a lot of changes could happen during this time. In some cases, it is possible that the DR program manager pays incentives to the aggregator with a 15-min time interval. However, in the downstream side of the network, as the aggregator is dealing with every single consumer, the 15-min time interval is a long period. Consequently, in order to have a clear vision of the consumption profile during the ramp period and DR event, Figure 9 illustrates the aggregator consumption curve between 11:00 to 14:00, with a 1-min time interval. In the same figure, the uncontrollable part of aggregator consumption is not shown as the focus is given to the controllable part of consumption.

**Figure 9.** Available Demand response programs during ramp period and event.

As is clear in both Figures 7 and 9, almost half of the consumption during ramp period and the event itself is dedicated to DLC T1 (air conditioner), and only a few parts are devoted to DCL T2 (washing machine and dishwasher) and IDRP (water heater and fan heater). As the fan heaters in the IDRP program are resistive loads, they are a suitable target for emulating by resistive loads bench. Thus, in the next section (results) all fan heaters in the aggregator that are associated in the IDRP program are being emulated by the resistive loads bench and the behavior of each device as well as the aggregator facing an actual profile will be scrutinized.
