SPD will normally dispatch the lowest-cost generation to meet demand (allowing for co-optimisation of energy and reserves).
About security constraints
When unconstrained dispatch does not allow the System Operator's security policies to be met (for example, if transmission assets are expected to be operated beyond rated short-term capability after any defined contingent event) then a security constraint is applied in SPD.
Security constraints may be applied as:
- a temporary constraint – to deal with an outage situation when some assets are not available
- a permanent constraint – when the normal integrated power system capability and expected generation offers and demand may not result in secure operation.
The Simultaneous Feasibility Test (SFT) software automatically creates security constraints that are applied to SPD, these are published through schedules in WITS.
In addition to the automatically created constraints created by the SFT software the spreadsheet below contains constraints that the System Operator develops using non-automated processes (manual constraints). This list is updated when the constraints in the list are either created or revised.
Where practicable this information will be published two weeks prior to the date the constraints are intended to be first used. Note this may not always be possible where manual constraints have been identified as being required due to the automatic scheduling process not being able to mitigate a security issue which runs one week out.
Manual Constraints (updated 11 Mar 2024)
SFT constraint assessments
Participants may request an SFT constraint assessment to be performed and posted to the industry via POCP or the System Operator website. The purpose of such assessments is to provide an indication of what the limiting security constraints may be during a particular outage or grid configuration. To request a SFT constraint assessment email: [email protected].
A set of generation scenarios used for SFT constraint assessments has been agreed by the constraint information working group; this is a living document and is updated based on experience. The aim of the list is to ensure scenarios which will identify unique constraints are studied, while keeping scenarios to a minimum so that studies are performed efficiently and turn around for requests is as quick as possible.
SFT calculation methodology
The System Operator is required, to advise:
- an explanation of the methodology and procedures it will employ in formulating constraints, including how information about stability and transmission limits are used to define constraint parameters
- when the information can be published
- automated processes and systems used in formulating constraints.
We are also required to advise participants of the constraint percentage threshold, this is the threshold at which SFT constraints are created. The initial threshold for SFT constraints is 90% and 0% for manual constraints. The above is best illustrated in the linked process flowcharts
| Name/Link to Diagram | Description |
|---|---|
| Process Overview | This diagram shows the SFT Security Constraint development process used by the SFT application. |
| Security Constraint creation process with SFT | Page 1 of this diagram shows the process used by the SFT Constraint Builder to create Security Constraints, page 2 is the same diagram with additional details added |
Procedures for Managing Security Constraints
We use a number of procedures to manage the creation and maintenance of security constraints. The documents that maybe of interest to market participants are published below: