Identify challenges for applying “controller in the loop” simulation in distributed automation of energy distribution systems and suggest ways of overcoming those challenges.
This seems to be related to the concept of " decentalized control" where local controllers , with just local information, are used for controlling an integrated system ( a system composed of several subsystems). However, this strategy can be dangerous for stabilzation purposes , and the overall control design can result in global instability of the whole system , if the connecting gains in-between the various subsystems are sufficiently high and they are not taken into account in the design of the various local controllers. That, is if coupling links are neglected for a decentralized control the system can be still stable but in the case when the coupling gains are high, the stability can be lost.
If the question at hand is to understand as a task to simulate energy distribution system (top level control loop, loop operated by main controller) that has embedded automation instances (lower level control loops, subordinate control loops, loops operated by subordinate controllers), then, firstly, it would be commonly described as "hardware in the loop simulation" (HIL simulation). The rationality of the term is linked to the historical fact that any control requires some hardware. The utility of the term is in the larger number of scientific papers, which one can find on the topic by the HIL key-phrase.
The most daunting issue in simulation of embedded systems is lack of information about dynamic properties of the instances.
Starting at lower level control instance, one can be constrained by the ability of upper level instances to deliver consistent input in case of highly variable load. The only reliable way to design the lower-level-control-loop properly is to know the exact set of rules by which the upper-level-control-loop operates. It is often not given. The problem is quite common in every-day-life. It is usually approached by reverse engineering, black-box stress testing, and other techniques that are generally referred to as inductive scientific method.
Starting at upper level control instance, one can be constrained by the demands variability. Among the demand variability, the lower level controllers can consume according to a linear or a non-linear function.
Linear consumers can be easily dealt with. The only issue here is the amount of subordinate controllers. Use techniques meant for resolving quantitative complexity.
The nonlinear consumers are a headache. Lower-level-control-loops have commonly shorter system time than the supplier's (upper level loop) system time. Upper level controller can't predict load reliably due to non-linearity. Thus it can't drive the supply side quick enough. Typical real life solutions here are :1) safety switches and blackouts, i.e. denial of service at the expense of consumers. 2) bypass that throws away excess output at the expense of supplier. A HIL simulation should be able to model such cases. I.e. it should be able to handle extreme cases in addition to normal operations point control.
Another possibility to deal with nonlinear consumers is to gain information about subordinate controllers and their set of rules. Sometimes it helps to improve predictability. If some load-changing factors can be tracked by the main controller as proper as the subordinate controller tracks them, the lower level set of rules can be considered by an extended model in main controller. To describe the lower level loops use techniques that are generally referred to as deductive scientific method. If your system grows too big, you may want to investigate topics like simplified computing, solver efficiency, and finally think about balance and how to justify costs of computation by simulation precision gains.