## Case Study
### Functional Verification  
The schematic diagram of the functional verification platform is shown in Figure 6. The experimental system covers all the necessary elements in the proposed DR system, such as the UP and HEM platform, DRAS, HIG, and communication lines. For the functions carried out by LAs which also run on the DRAS and HEMS with different parameters and strategies, the segment of the function run by LAs is ignored in the functional verification. The system in Figure 6 was installed in a real customer building. (a) System monitoring  
The first step was to test the system's monitoring ability, which provides the real-time operation status of the power system and acts as the basis for various power system control decisions including DR. In addition, the privacy of customers also needs to be considered in the data collection. The load information available to the UP is shown in Figure 7. For the mask strategy of the HIG (LA) in this case, the values of peak, average, and valley loads in the building are sent to the upper agents (DRAS in this case) every 10 min. Although the details for a single appliance did not expose the UP, the information for most DR decisions is enough. For example, the peak appeared from 12:00 p.m. to 4:00 p.m. (the hottest time of the day), which means that the main contributions might be air conditioners, which are DR-friendly loads. In addition, during the peak time, maximum load was sometimes two times higher than average load, which means the peak load occupied a really short time compared to high values where many DR programs and researches were devoted to curtailing them. (b) Communication performance  
The second step was to test the remote monitoring and control abilities of the proposed DR system, which has important meaning for DR tasks. During the test, dozens of remote breaks were executed with a long communication distance over 100 km, which was near to a normal direct control distance from the DRAS to customers; the delay curve is shown in Figure 8.  
Figure 6: Experimental platform for the functional verification. Figure 7: Curve of load data accessed on grid side. As mentioned before, IoT was applied for wider-area mass access, while the internet was used for stable high-speed transmissions. The test results presented in Figure 8 imply that the communication delay was much lighter than for the IoT even when the internet connections were 100 km away, while the IoT was in the building. The communication performance gap provides the feasibility of taking the internet as the communication method between important infrastructures. From the overall communication test results, the delay was acceptable at under 3.5 s. It should be noted that the fluctuations of the IoT are mainly due to the polling style in Lora, and the performance may differ from other IoT technologies. (c) Local action ability  
Because a \"local detection and action\" strategy was proposed to address quick DR problems in this paper, the ability and performance of the proposed system in a local action also needed to be checked. Therefore, this subsection tests the local action ability of this system, which is the basic function of supporting quick DR tasks. The relay protection tester in Figure 6 was hooked with a smart terminal, and a frequency threshold was applied as the quick DR task indicator. When the output frequency of the relay protection tester dropped below the threshold, the smart terminal acted. The delays between the time output frequency dropped to the threshold and the time terminal action was recorded (Figure 9). The figure shows that the delays were mainly 100-120 ms. The causes for the delay were mainly the strategies needing four cycles to confirm that the accident occurred. Moreover, the zero-crossing switch strategy also increased the time. The results of the functional verification demonstrate that the proposed DR system has large-scale monitoring and control capability and the ability to undertake the system's multi-time-scale DR tasks described before.