## 4. Scope of Proposed DR System Application  
The purpose of our work was to implement an economical and practical DR system; thus, it was necessary to consider the requirements of diverse types of DR programs. The main characteristics of DR programs are highlighted in Table 1[1]. The main concerns for the system design are requirements regarding computation, communication, and control. Therefore, the scope of the proposed DR system application was determined through the analysis of these DR requirements.  
\begin{table}
\begin{tabular}{c c c c c c} \hline \hline
**DR Program** & **Scheme Type** & **Rule** & **Situation** & **Activation Period** & **Response Type** \\ \hline Time of Use (ToU) & Price-based & Non-dispatchable & Periodic & \begin{tabular}{c} Varies hourly, intraday, \\ and seasonally \\ \end{tabular} & Customer side \\ \hline \multirow{2}{*}{\begin{tabular}{c} Real-Time Pricing (RTP) \\ \end{tabular} } & \multirow{2}{*}{\
\begin{tabular}{c} Price-based \\ \end{tabular} } & \multirow{2}{*}{Non-dispatchable} & \multirow{2}{*}{Periodic} & \multirow{2}{*}{
\begin{tabular}{c} Varies hourly, intraday, \\ and seasonally \\ \end{tabular} } \\ \cline{1-1} \cline{5-5}  & & & & Variable within a day \\ \cline{1-1} \cline{5-5}  & & & Both & Causative/periodic & At any time \\ \hline Interruptible & & & & & \\ \hline Bidding & Inentive-based & Dispatchable & Causative & At any time \\ \cline{1-1} \cline{5-5} Direct Load Control (DLC) & & & & Utility side \\ \cline{1-1} \cline{5-5} Emergency & & & & & \\ \hline \hline \end{tabular}
\end{table}
Table 1. Comparison for demand response (DR) programs.  
Figure 5. Smart terminal for the proposed DR system: (**a**) schematic of key blocks and functions in the smart terminal; (**b**) circuit diagram of its implementation.  
Computation exists in procedures like data processing and decision-making. The DRAS and multi-agents are regulated from existing computation infrastructures in traditional power systems, and open to updates of software and hardware. Therefore, the proposed system has enough ability to undertake computation tasks with no geography or facility limitations. Whether the programs in Table 1 belong to dispatchable or non-dispatchable rules, the DR system proposed can provide centralized and decentralized computation capacities.  
(b) Communication and control requirements  
In practical operation cases, whether the programs work well highly depends on the performance of the system in communication and control, and the tolerance for communication and control failure and latency is different among programs [15]. As Table 1 shows, for price-based programs like time of use (ToU), critical-peak pricing (CPP), and real-time pricing (RTP), time tolerance is relaxed to allow bi-directional trades to be executed. Furthermore, periodical and practicable behaviors are easy to optimize and valuable for communication resources.  
For incentive-based programs, the situation is different. Some incentive-based programs like direct load control (DLC) and emergencies operate at one direction mode and happen casually, as required by the power system safety. For the use of public communication connections and third-party agents in the proposed method, the communication requirements for these programs cannot be satisfied.  
To compensate for the communication shortcomings, a \"local check-and-action\" method is proposed and integrated into the design of the system, involving potential assessment and terminal operation strategies which are described in Sections 2 and 3. Meanwhile, the DR programs designed for spinning reserves or emergencies should be adjusted to satisfy a decentralized local action mode. This method was validated to be practical in the case study.