In a realistic power system, the following additional points have to be considered.
| a) |
Reactive power capability is not free and unlimited. |
Instead of specifying the reactive power schedule, an operator may prefer to schedule the voltage at the buses at which reactive power is controllable.
| b) |
There may be additional controllable variables (possibly having service costs), like tap settings of tap changing transformers, SVC output, TCSC reactance , HVDC power flow etc. Each controllable variable is likely to have a limit which is dictated by the associated equipment. |
| c) |
Current in the transmission line has to be within values as dictated by the thermal limit. |
| d) |
Security Constraints: Even if we have ensured that we have a least cost real and reactive power schedule for a given newtork and load condition, we would also like to ensure that this schedule is "secure". This means that if there is a disturbance when the system is operating as per this schedule, it should be : |
| 1) |
stable, i.e., it should "settle down" after a credible(realistic) disturbance to a post-fault equilibrium (see Module 2 for a discussion of stability). |
| 2) |
transmission line voltage and current constraints are not violated in the post-disturbance steady state (which may be different from the pre-disturbance steady state due to loss of a component like transmission line). |
Incorporating security constraints rigourously is not an easy task since there can be a large number of realistic disturbances which can take place. Restricting pre-disturbance power flows or phase angular differences across lines is a convenient way to specify Angular Stability constraint.
.An optimal power flow which includes security constraints is called a "security constrained optimal power flow".
If an optimal power flow study is carried out without considering security constraints, i.e., the constraints imposed by the steady state / dynamic behaviour following a potential contingency, then this may call for changes (or usually some minor adjustments) in the final "schedule" in order to satisfy security constraints. This is known as preventive re-scheduling (we shall see an example of this in the next module). |