## 2 Architecture of the Multi-Communication-Based DR System
### Design for Grid-Side Architecture and Functions  
The architecture of the grid side is shown in Figure 2.  
As mentioned before, the UP is the interface of electric utilities for the DR system. In the design of the proposed DR system, the functions and environment provided by the DRAS are accessed through internet communication, although, on many occasions, DRAS is included in the utilities. This is because (1) there are diverse departments in a utility with diverse requirements and safety levels, while the access through communication are more easily to manage; (2) the implementation platforms can be diverse languages and platforms, as long as network connectivity is included. This measure is expected to make the system more versatile on occasions where the electricity markets are operating.  
Due to the central role of DRAS, the technologies and strategies applied to it need to be highly stable and generic. In order to satisfy the requirements for multi-LA and multi-UP connections, multiple communication interfaces are necessary, which are mature in the present internet applications. Considering mass data and instruction transformation, only fiber communication connections could retain the pressure. Therefore, the communication methods linked with DRAS are mostly based on internet in the wired form, which represents the main cost in the communication part of this system.  
In addition to the choice of communication methods, another important function of DRAS and big LAs needed is the potential assessment of DR resources, which is the base of load aggregation and multi-task parallel operation. As for the functions shown in Figure 3, DRAS needs to assess and record the resources occupied by each DR task, preventing the resource tasks from exceeding the system limit. In the meantime, adjusting DR potential with real-time operation data is also required by the DRAS. The strategies of DR potential assessment in this work refer to our previous work [11].  
As Figure 3 shows, DR services provided by the proposed DR system are divided into two categories according to time scale and strategy mechanism. The first one is traditional DR, including peak clipping, congestion control, and economy optimization. The tasks belonging to this category are characterized by a long time scale with unstrict demands and no mandatory demands, which are often applied with market trading mechanisms. The other one is quick DR, acting as a spinning reserve for emergency accidents like frequency modulation and renewable energy accommodation, named \"ancillary services\" in OpenADR [12]. In contrast to the former, the tasks in this one are characterized by a short time scale, requiring deterministic response behaviors which should be settled in a day-ahead schedule. In the present implementation, each LA is asked to contribute a certain share as a quick DR reserve, and the others are left to participate in other DR mechanisms.  
Figure 3: Diagram of potential assessment of demand response automatic server (DRAS).  
Figure 2: The architecture of the grid side.  
In terms of specific technology, the DRAS is accommodated on a Linux server at present, with MySQL chosen as the database implementation. A dedicated internet communication architecture is necessary for stable and secure communications between the DRAS and UP, DRAS, and main LAs.