Security Constrained Optimal Power Flow (SCOPF)
Conceptually, the difference between OPF and SCOPF is:
-
OPF (N-0): An OPF solution is a process to dispatch the system which minimizes the production cost while ensuring all transmission elements are loaded at or below their respective rated capabilities.
- SCOPF (N-x): In addition to satisfying the conditions of the OPF, the SCOPF finds a generation dispatch that, should any specified N-x contingency event occur, all transmission elements will remain within specified ratings. If appropriate, a different set of transmission limits can be applied to contingency events to reflect different allowable limits under emergency conditions. Note that by definition the generation profile to satisfy the SCOPF requirements will result in a higher production cost than from the OPF alone.
Aurora models (N-x) contingencies, where x is the number of elements that are out of service during a contingency event. There is no upper limit to x in the SCOPF methodology. The inclusion of a Contingency table ‘in study’ will invoke Aurora’s SCOPF dispatch logic.
Aurora calculates line outage distribution factors (LODFs) for each contingency enabled in the Contingency table. LODF’s mathematically describe how a change in the status of an element (e.g. open/closed) will impact power flows on all branches. (Simulation Options à Nodal Solution Settings allows the user to specify a Branch flow violation tolerance; default = 0.002).
Independent system operators (ISOs) that operate nodal markets (e.g., PJM, ERCOT) publish a list of critical contingencies. These lists consist of single contingency (N-1) events as well as double (N-2) or higher (N-3+) contingency events. For example, ERCOT’s contingency list from 2010 lists ~6500 potential contingencies, of which ~2500 are enabled (actively modeled/planned for), as single contingencies. In Aurora, unique contingency sets are defined by a Contingency ID in the Contingency table. Each Contingency ID must consist of at least one record of type contingency (N-1) or multiple records (N-x). Optionally, a specific branch or corridor (or both) may be specified to be monitored with a given contingency. If no monitored branch or corridor is specified, then the model will enforce all globally monitored branch limits (See Nodal Input Tables à Contingency table).
Aurora employs an iterative or successive OPF methodology where overloads found in one iteration become constraints in successive OPF solutions for a given solution hour. First, Aurora will find an OPF solution (base or pre-contingency) for the given solution hour. Then, when analyzing multiple contingencies (e.g. ERCOT’s ~2,000 N-1 contingencies), Aurora will identify the worst violations (greatest overload) occurring on each remaining transmission element caused by the study contingency set, and will re-dispatch to ensure all monitored elements are within post-contingency limits.
For example, assume contingency 1 (branch 1 out) and contingency 2 (branch 2 out) are both specified to monitor branch 3, which has a limit of 100 MW. If contingency 1 would cause a flow of 110 MW (overload by 10 MW) and contingency 2 would cause a flow of 130 MW (overload by 30 MW), then Aurora’s SCOPF will re-dispatch to satisfy the contingency 2 case and keep the post-contingency flows on branch 3 <= 100 MW. Aurora will then analyze the remainder of the system to see if any new elements are overloaded under either base or post-contingency conditions. This iterative process will continue until a dispatch is found that honors all specified branch limits. In practice, Aurora usually finds a solution in 2 or 3 iterations and is very fast.
Conversely, if the LODFs indicate that even with contingencies no branch limit would be violated, then the SCOPF is already done (results are the same as with the already-completed OPF) and there is no need to re-dispatch (this would be rare in practice, but possible for certain generation/demand profiles).
Security Constrained OPF Logic
