Modeling of RAS and Relays in Power Flow Contingency Analysis. Jamie Weber

Transcription

1 Modeling of RAS and Relays in Power Flow Contingency Analysis Jamie Weber ext South First Street Champaign, Illinois (217)

2 Transient Stability RAS Models Transient Stability RAS modeling is something special This needs to be better defined May result in user defined model May result in creation of specific models for specific RAS schemes New Line Relay model (FACRI_SC) New Shunt model (FACRI_SS) PowerWorld and other software vendors are looking for guidance here Modeling of these features in the power flow simulations is another consideration 2

3 Power Flow Contingency Analysis Relay and RAS Models Relay Modeling There are many possibilities for this Best choice may be to just let software vendors make modifications to software Automatically support the querying of transient relay models to determine if they may impact the steadystate power flow solutions Will present this concept later in presentation RAS Modeling Remainder of this presentation will show the existing abilities to model steady state RAS schemes in PowerWorld Simulator 3

4 PowerWorld RAS Modeling This has a very long history in PowerWorld Simulator dating to 2000 The contingency analysis tool has been designed from its beginning in about 2000 to include RAS modeling Work done with BPA in timeframe Follow on work at BPA to ensure concepts were inherited in ATC and PVQV tools ( ) Also work with ISO NE and TVA throughout Continued work with BPA recently as well This presentation is a recap of features going back to 2000 and an introduction of some new ones added recently 4

5 Features Related to Modeling Contingency Analysis RAS (1/3) Advanced filtering (created in 2000) Conditional contingency actions (2001) Model Criteria (Model Conditions and Model Filters) CHECK and POSTCHECK actions Lookup tables or expressions in Contingencies (2002) Model Expressions Contingency actions grouped together (2003) Contingency Blocks Contingency Global Actions Storing which actions were triggered What Actually Occurred (2003) Specifying origin of action Blocks, Global Actions (2011) Generation Drop Modeling Injection Group Contingency Actions (2002) Injection Group Generator Scale in Merit Order(2004) 5

6 Features Related to Modeling Contingency Analysis RAS (2/3) Limit Monitoring by Exception (2007) Generation Drop Modeling Revisit Injection Group Generator Open in Merit Order (2009) Accounting for overlapping gen drop (2012) Contingency Action Evaluate Model Expression in Reference State (2012) Full Topology Models (on next page) Contingency Analysis Custom Monitoring Ability to monitor anything during a contingency (2011) Conditional Actions based on Status Only (2012) TOPOLOGYCHECK actions Global RAS Modeling (2012) Use Global Contingency action with new Model Condition Feature: Evaluate in Reference State 6

7 Features Related to Modeling Contingency Analysis RAS (3/3) Using Full Topology Models (node breaker models) (2007) Integrated Topology Processing (Incremental Topology Processing) (2007) Limit Monitoring restriction to Superbus (2008) Open with Breakers contingency actions (2009) Close with Breakers contingency actions (2011) Derived Status and Derived Online (2011) Refinements (2012) 7

8 Advanced Filtering (2000) First Step for Conditional RAS Advanced Filtering is an integral part of Simulator s GUI for all our tools Built directly on top of our case information displays (tables) Any field that you can see in a table can be filtered Table data displays, monitoring, oneline formatting, really everything Filtering is completely generic and available for all objects in Simulator Compare field to a constant (Flow > 500) Compare field to another field (Flow > Limit) Build any logical combinations of conditions and other filters Be careful for circular references when using filters inside filters No maximum on conditions Compare across objects (Branches could be filtered based on whether the voltage was low at either end) 8

9 Advanced Filter Dialog Filter By will be discussed shortly (Advanced or Device) Type of object being filtered Logical Comparator Conditions Use the Find buttons Click to delete a condition 9

10 Field To Field Comparisons Users have the option to include Field To Field comparisons Click the Find Button to choose another field to compare to instead of a constant value. Check the box for Enable Field to Field Comparisons 10

11 Conditional Contingency Actions (2001) Many choices of various contingency actions are available Model Criteria specifies a Boolean condition under which the action should be applied Model Conditions Model Filters When a contingency is applied, these actions only occur if the Model Criteria is true We ll discuss shortly We ll discuss shortly 11

12 Model Conditions and Model Filters Model Condition (couples two things) Particular object An Advanced Filter definition Model Condition is met if the advanced filter to the particular object is TRUE TRUE Model Condition means action is applied Model Filter A Boolean expression of other Model Conditions and Model Filters TRUE Model Filter means action is applied 12

13 Conditional Contingency Actions Choose Object Type Model Conditions (2001) Choose Object Build Advanced Filter Definition 13

14 Conditional Contingency Actions Model Filters (2001) Just piece together a list of Model Conditions or Filters and a logical comparison Logical comparison for the Model Conditions Give the Model Filter a name and save Similar to the Advanced Filter Dialog Click to Modify Model Conditions Model Filters may contain Model Conditions or other Model Filters 14

15 Conditional Contingency Actions: Action Status (2001) Action Status Specifies when action should be applied (i.e. when criteria should be evaluated) Contingency Processing in 2001 was as follows 1. Apply ALWAYS actions and true CHECK actions (Note: CHECK actions are evaluated in reference state) 2. Update topology (branch, bus status) 3. Solve power flow 4. Apply true POSTCHECK actions 5. Repeat steps 2 4 until no more POSTCHECK actions become true We will discuss TOPOLOGYCHECK shortly 15

16 Contingency Model Expressions Types Expressions: mathematical expressions involving one or more model fields Model Field can be any field of any object in the model Lookup Tables: return a value based on the values of one or two model fields May be used inside Some kinds of contingency elements Set Gen MW to Model Expression See earlier slide Advanced Filters Model Conditions Examples Gen Drop Equal to a Lookup Table Gen Drop Equal to 40% of Interface Flow 16

17 Contingency actions grouped together (2002) Contingency Blocks Provide a grouping of contingency actions A contingency definition can then refer to the contingency block Multiple contingencies might do the same set of actions Frankly, the need for this became much less with enhanced contingency definitions of Injection Group, Interface actions, etc. Contingency Global Actions Define a list of contingency actions that are inherited by ALL contingency definitions Only makes sense if these are all conditional Allows you to setup definitions such as a branch that monitors a line flow and trips the line if it s too high Useful for modeling relays and RAS 17

18 What Actually Occurred? (2003) Consequence of Conditional Actions Need a mechanism to report what action were Applied and which were Skipped Implemented in 2003 Improvements to GUI in 2008 Need a mechanism to report the origin of the contingency action that is applied or skipped (2011) ELEMENT BLOCK GLOBAL Future RELAY model? List of What Actually Occurred is part of the results of a contingency (similar to how violations are part of the results) 18

19 Straightforward Future Addition Conceptually a Relay Model in power flow contingency analysis would act similar to Contingency action that opens a device (or devices) Status = POSTCHECK Model Criteria = Model Condition based on Violating Bus Voltage Limit Over Line Current Apparent Impedance looking down line is inside Impedance Region (distance relay) Potential addition to power flow contingency analysis Force software to directly use transient stability relay models in power flow contingency analysis Note: do NOT force extra definition of actions 19

20 Future: Transient Relay Models in the Power Flow Contingency Internally Simulator would automatically evaluate steady state implications of the stability relay models at the same time that existing POSTCHECK actions are evaluated Assume in power flow contingency that post contingency states exists forever Timing data in relay models would be ignored as state exists forever Over current relays would just look at the minimum current threshold from transient model Voltage based relays would look at largest minimum voltage and smallest maximum voltage Distance/Impedance relays would evaluate highest zone for model What Actually Occurred results would indicate if any of these actions are initiated User Requirements for this feature Define your stability relay models Check a box to enable this new feature Potential auto reporting options Automatically report as a contingency violation if any relay models actual operate 20

21 Contingency Limit Monitoring by Example: Ignore a particular line during a particular contingency We know it can be alleviated (instead of explicit RAS modeling) Exception (2007) Create exceptions to Limit Monitoring settings for specific contingencies and monitored elements Not recommended Basically means I know there is RAS but I don t want to model it, and don t tell me about these violations 21

22 Modeling Generation Dropping A common RAS scheme Contingency Blocks (2002) Initially added to allow grouping of generator outages or scaling Can be used for anything else though Injection Group Contingency Actions (2002) Gave ability to OPEN all generation in an injection group Gave ability to SET or CHANGE MW output (done by scaling generation) Injection Group Generator Scale in Merit Order(2004) Scale in Merit Order allowed you to scale up (or down) generation one at a time to max (or min) limits until total MW change achieved Generator Open in Merit Order (2009) Allows you to specify an amount of gen to reduce by opening generators Opens generation until all gens would exceed the specified amount Accounting for overlapping gen drop (2012) Possible for multiple RAS to operate simultaneously Multiple RAS may ask to open the same generation Accounting for overlap means that if multiple schemes are operating then subsequent ones will count drops from earlier schemes in their MW totals Contingency Action Evaluate Model Expression in Reference State (2012) Needed so you can properly arm the amount of generation drop 22

23 Example of Injection Group Contingency Action Assume Injection Group named John Day gen is defined Change the total John Day generation by 500 MW by opening generator in merit order 23

24 Contingency Analysis: Overlapping Gen Drop (2012) Accounting for Overlapping Generation when using merit order generation dropping Drop 500 MW from Injection Group #1 Drop 400 MW from Injection Group #2 Order matters: Group #1 will drop 500 MW, but when going to drop Group #2, if there is overlap and 200 MW of generation in Group #2 was already dropped due to Group #1 dropping, then only an additional 200 MW will be dropped. You won t always get 900 MW of dropping (example above would only drop 700 MW) Note: default behavior is to take into account this overlap. This may be turned off in the Basic Contingency Modeling options 24

25 RAS models before 2012 Typically the RAS model is modeled explicitly with the line outage contingency that triggers the RAS to occur Just automatically apply the gen drop for instance for a particular line outage Possible make a Contingency Block that performs this and refer to Contingency Block from outages that use this RAS Limitations of this If line is out in the reference state you must modify your contingency definitions Otherwise the RAS is initiated in contingency though no change Data maintenance issue Will not capture the cascading outage that trigger RAS when Line A overloads Trip Line A causes Line B to trip which triggers RAS associated with Line B Basically, unless you have all these RAS and relays enabled in your contingency run, the Simulation will NOT show cascade of Southwest Blackout 25

26 Evaluate Model in Reference State (2012) Needed to arm the amount of generation drop based on Reference State only Important if there are POSTCHECK actions Possible that other POSTCHECK actions have occurred and you re iterating back on subsequent POSTCHECK actions with a new system state. Example: Amount of generation drop is based on a two dimensional nomogram which is a function of two interface flows The arming level is handle based on the reference state, not what the MW flow happens to be at a particular point in contingency analysis process Use Model Expression Lookup Table (Simulator supports 1D and 2D lookups tables) For amount to drop, point to Model Expression Check box for Evaluate Model in Reference State 26

27 Custom Contingency Monitoring (2011) Ability to monitor anything during a contingency (2011) Specify an object type Choose either All objects of that type Choose a specific object Choose Field to Monitor Pre Filter Advanced Filter applied to object in Reference State Post Filter Advanced Filter applied to object in post contingency state Options to never report violation if value doesn t change by threshold 27

28 Conditional Actions based on Status Only (2012) Users of Simulator had a persistent problem in some contingency runs when using RAS RAS is configured to open 2,000 MW of generation when Line X trips Before 2012, this was achieved by configuring a POSTCHECK action that looks at the branch status and trips generation if the branch is out of service Works most of the time, but... What if the outage of Line X results in an unsolvable steady state power flow solution? Basically means that the RAS scheme is actually preventing a voltage collapse from occurring This means that the POSTCHECK action is never evaluated because the power flow solution failed. Solution: TOPOLOGYCHECK actions 28

29 NEW Contingency Analysis: TOPOLOGYCHECK (2012) TOPOLOGYCHECK Contingency Element Status. Contingency Processing now goes as follows 1. Apply ALWAYS actions and true CHECK actions 2. Update topology (branch, bus status) 3. Apply true TOPOLOGYCHECK actions 4. Solve power flow 5. Apply true POSTCHECK actions and true TOPOLOGYCHECK actions 6. If any POSTCHECK or TOPOLOGYCHECK actions are done then repeat steps 2 5 Note: TOPOLOGYCHECK should only be used with Model Conditions related to bus/branch statuses 29

30 TOPOLOGYCHECK Status Message Log Contingency pre processing CHECK and unconditional actions Skipped actions because Model Criteria not met Actions applied with TOPOLOGYCHECK status met Start the power flow Light blue indicates contingency element Pink indicates Global Action 12HW_PowerWorld_RAS_Test_Case_New_Features.pwb 30

31 Global RAS Modeling (2012): Reference State Evaluations Model Condition Option Evaluate in Contingency Reference State Disable if True in Contingency Reference State Example: Model Filter that takes the OR of three Model Conditions that test whether particular lines are Open As soon as one of the lines is opened by a contingency, the model filter will evaluate to TRUE and you ll trigger appropriate actions. Reference State Contingency Opening Line A Line A Open (FALSE) Line A Open (TRUE) Line B Open (FALSE) Line C Open (FALSE) Line Loss FALSE Line B Open (FALSE) Line C Open (FALSE) Line Loss TRUE Works great as long as all three lines are CLOSED in the Reference State 31

32 Contingency Analysis: Disable if TRUE in Reference State What if Line A is OPEN in the Reference State? This logic will end up returning TRUE for EVERY contingency Reference State Line A Open (TRUE) Line B Open (FALSE) Line C Open (FALSE) Line Loss TRUE Disable if TRUE in Reference State Option means The Model Condition is completely ignored! It s like the Model Condition doesn t even exist. The result of this will depend on the type of logic the model condition is fed into Contingency Opening Line A Line A Open (TRUE) Line B Open (FALSE) Line C Open (FALSE) Line Loss FALSE 32

33 Contingency Analysis: Disable if TRUE in Reference State Reminder Global Contingency Actions are a list of contingency elements that are included as part of every contingency solution Implication: Specify an action as part of the Global Contingency Actions using the Disable if TRUE in Reference State choice This allows you to model a global RAS in the power flow contingency action Define one record in Global Contingency Action and you don t need to manage which contingencies use it Also allows potential for cascading RAS under any contingency 33

34 Using Full Topology Models (node breaker models) Highlights Related to Contingency Analysis Integrated Topology Processing (2007) Contingency Analysis Incremental Topology Processing Limit Monitoring restriction to Superbus (2008) Open with Breakers contingency actions (2009) Close with Breakers contingency actions (2011) Derived Status and Derived Online (2011) Improvements for special situations in

35 History of Software Development History of the Contingency Analysis Tool Initial development in early PowerWorld Simulator versions before 1999 Work with BPA to make conditional actions and many advanced features ( ) Work with ISO New England to implement features for full topology models ( ) Work with ISO NE and TVA on Full Topology Model ( ) Work with BPA to permit more generic modeling of RAS ( ) Global RAS so don t need to embed RAS in particular contingencies Allows use in full topology models Consistent modeling for all users inside BPA History of other tools in Simulator are very similar A handful of customers drive the incremental development in lots of small projects Almost all of Simulator s tools have been made in this manner ATC, PVQV, OPF, SCOPF, OPF Reserves, Scheduled Actions, SimAuto, Integrated Topology Processing, Transient Stability, Sensitivity tools, Connection tools, etc Only exception we can think of is GIC (nobody even did this previously) 35

36 Software Development Process More than 100 small incremental tasks done over more than 13 years with several clients As small as a 0.5 person days, no bigger than 2 person months Project Timing Most tasks are spelled out with 3 5 days of software development time and a deliverable within 2 weeks Expectation is that user will test the new features immediately and within a few days we re certain it functions as desired Feedback with the PowerWorld developer and actual end user is frequent (weekly, if not daily at times) Even large project get broken up into small tasks so progress can be measured and user is constantly engaged in providing feedback Why do it this way? Software developer doesn t understand what the user needs Often the user isn t certain either Small tasks ensure everyone learns quickly what works and what doesn t constant short engagements builds trust Nice thing about software is manufacturing process is free (compile, move file to web server, notice) 36