Abdul_Ardate
66 Pages

Abdul_Ardate

Course Number: ECE 00000288, Fall 2009

College/University: Iowa State

Word Count: 10638

Rating:

Document Preview

On-line computation of system operating limits with respect to thermal constraints by Abdul Kader Abou-Ardate A thesis submitted to the graduate faculty in partial fulfillment of the requirements for the degree of MASTER OF SCIENCE Major: Electrical Engineering Program of Study Committee: James McCalley (Major Professor) Chen-Ching Liu Sarah Ryan Iowa State University Ames, Iowa 2006 Copyright Abdul Kader...

Unformatted Document Excerpt
Coursehero >> Iowa >> Iowa State >> ECE 00000288

Course Hero has millions of student submitted documents similar to the one
below including study guides, practice problems, reference materials, practice exams, textbook help and tutor support.

Course Hero has millions of student submitted documents similar to the one below including study guides, practice problems, reference materials, practice exams, textbook help and tutor support.

computation On-line of system operating limits with respect to thermal constraints by Abdul Kader Abou-Ardate A thesis submitted to the graduate faculty in partial fulfillment of the requirements for the degree of MASTER OF SCIENCE Major: Electrical Engineering Program of Study Committee: James McCalley (Major Professor) Chen-Ching Liu Sarah Ryan Iowa State University Ames, Iowa 2006 Copyright Abdul Kader Fathi Abou-Ardate, 2006. All rights reserved. ii TABLE OF CONTENTS LIST OF FIGURES ........................................................................................................... iv LIST OF TABLES............................................................................................................. vi CHAPTER 1. INTRODUCTION ........................................................................................1 CHAPTER 2. THE DISPATCHER TRAINING SIMULATOR ........................................5 2.1 Energy Control System ........................................................................................... 6 2.2 Long term Dynamic Simulation.............................................................................. 7 2.2.1 Numerical Solution method ..................................................................... 8 2.3 The Instructional Subsystem................................................................................. 11 2.4 Elements of the AREVA DTS .............................................................................. 12 2.4.1 The Simulator subsystem....................................................................... 13 2.4.2 The SCADA subsystem ......................................................................... 15 2.4.3 The Generation subsystem..................................................................... 17 2.4.4 The Transmission subsystem ................................................................. 18 2.4.5 The e-terra PC Link ............................................................................... 18 CHAPTER 3. THE SOL AND ITS CALCULATION......................................................19 3.1 Generation Shift Factors (GSF) ............................................................................ 19 3.2 Line Outage Distribution Factors (LODF) ........................................................... 20 3.3 System Operating Limit (SOL)............................................................................. 21 3.4 SOL illustration on a numerical example ............................................................. 22 3.5 Generalized version of the SOL............................................................................ 24 3.6 Algorithm for choosing the right SOL.................................................................. 26 3.6.1 Case I ..................................................................................................... 26 3.6.2 Case II .................................................................................................... 27 3.6.3 Case III................................................................................................... 27 iii 3.6.4 Case IV................................................................................................... 28 3.6.5 Case V.................................................................................................... 29 CHAPTER 4. IMPLEMENTATION OF THE SOL SOFTWARE ..................................30 4.1 Microsoft Foundation Classes............................................................................... 32 4.2 The MFCDDE Library.......................................................................................... 32 4.3 The TNT and JAMA Libraries ............................................................................. 32 4.4 The XML file ........................................................................................................ 33 CHAPTER 5. SIMULATION RESULTS .........................................................................35 5.1 The test system...................................................................................................... 35 5.2 DTS simulations.................................................................................................... 37 5.3 SOL software simulation from base case.............................................................. 39 5.3.1 The DOUGLAS:HANOVER tie-line .................................................... 43 5.3.2 The KINCARD:HANOVER tie-line ..................................................... 44 5.3.3 The LAKEVIEW:RICHVIEW tie-line.................................................. 45 5.3.4 The CEYLON:MARTDALE tie-line .................................................... 46 5.3.5 The PICTON:CHENAUX tie-line......................................................... 47 5.3.6 The STINSON:HOLDEN tie-line.......................................................... 48 5.4 Testing the SOL values......................................................................................... 48 5.5 Taking action to relief overload ............................................................................ 51 CHAPTER 6. CONCLUSIONS AND RECOMMENDED FUTURE WORK ................55 6.1 Conclusions........................................................................................................... 55 6.2 Recommended future work................................................................................... 56 REFERENCES ..................................................................................................................57 iv LIST OF FIGURES Figure 1: Nomogram showing acceptable operating conditions for two generation groups [2] ................................................................................................... 2 Figure 2: DTS used in training.................................................................................................. 5 Figure 3: EMS/DTS interface [13] ........................................................................................... 6 Figure 4: Partitioned system formulation [19].......................................................................... 9 Figure 5: Block diagram of primary and secondary control of generator............................... 10 Figure 6: Elements of the DTS [23]........................................................................................ 12 Figure 7: AREVA DTS main control display......................................................................... 14 Figure 8: AREVA DTS area status display ............................................................................ 15 Figure 9: EMS/DTS databases................................................................................................ 16 Figure 10: 3-Bus system before stress .................................................................................... 23 Figure 11: 3-Bus system after stress ....................................................................................... 23 Figure 12: 3-Bus system after stress & contingency of circuit 2-3......................................... 23 Figure 13: SOL for circuit 1-3 ................................................................................................ 24 Figure 14: SOL Case I ............................................................................................................ 27 Figure 15: SOL Case II ........................................................................................................... 27 Figure 16: SOL Case III.......................................................................................................... 28 Figure 17: SOL Case IV ......................................................................................................... 28 Figure 18: SOL Case V........................................................................................................... 29 Figure 19: SOL software flowchart ........................................................................................ 31 Figure 20: EMP60 oneline diagram........................................................................................ 35 Figure 21: EMP60 simplified representation.......................................................................... 36 Figure 23: Pre-contingency condition for PICTON:CHENAUX........................................... 38 Figure 24: Post-contingency conditions after the outage of CEYLON:MARTDALE, PICTON:CHENAUX at 120% load ....................................................................................... 39 Figure 25: SOL software interface and output........................................................................ 40 Figure 26: Generation and Load profile for area EAST ......................................................... 41 Figure 27: Generation and Load profile for area WEST ........................................................ 42 v Figure 28: Generation and Load profile for area ECAR......................................................... 42 Figure 29: Flow vs SOL for DOUGLAS:HANOVER ........................................................... 43 Figure 30: Flow vs SOL for KINCARD:HANOVER ............................................................ 44 Figure 31: Flow vs SOL for LAKEVIEW:RICHVIEW......................................................... 45 Figure 32: Flow vs SOL for CEYLON:MARTDALE ........................................................... 46 Figure 33: Flow vs SOL for PICTON:CHENAUX................................................................ 47 Figure 34: Flow vs SOL for STINSON:HOLDEN................................................................. 48 Figure 35: Post-contingency conditions, PICTON:CHENAUX 118% overload ................... 49 Figure 36: Post-contingency conditions, CEYLON:MARTDALE at 100% load.................. 50 Figure 37: Post-contingency conditions, CEYLON:MARTDALE at 100% load.................. 50 Figure 38: Flow vs SOL for DOUGLAS:HANOVER after rescheduling ............................. 51 Figure 39: Flow vs SOL for KINCARD:HANOVER after rescheduling .............................. 52 Figure 40: Flow vs SOL for LAKEVIEW:RICHVIEW after rescheduling ........................... 52 Figure 41: Flow vs SOL for CEYLON:MARTDALE after rescheduling.............................. 53 Figure 42: Flow vs SOL for STINSON:HOLDEN after rescheduling................................... 53 Figure 43: Flow vs SOL for PICTON:CHENAUX after rescheduling & re-dispatching ...... 54 vi LIST OF TABLES Table 1: Real-time/DTS SCADA differences......................................................................... 17 Table 2: Real-time/DTS RTGEN differences......................................................................... 17 Table 3: Sample of the XML file............................................................................................ 34 Table 4: EMP60 model load distribution................................................................................ 36 Table 5: EMP60 model generation ......................................................................................... 37 1 CHAPTER 1. INTRODUCTION Power system security is the ability of the power system to respond to disturbances. Security assessment is performed on-line as a function of the energy management system (EMS) software available in the control centers of most power systems. The conceptually simplest approach that is available within almost all control center EMSs is to determine whether current conditions are secure or insecure. This is done by simulating all contingencies in a pre-specified set, under the current conditions, and for each one, identifying whether post-contingency performance criteria is satisfied or not. Although this approach does not identify boundaries associated with safe operating regions, it does indicate whether current conditions are within those boundaries or not. In another approach, analysts, in an off-line environment, identify security boundaries which just define acceptable and unacceptable post-contingency performance under a given contingency for the most restrictive credible contingency in terms of pre-contingency operating parameters [1]. Many utility companies in North America use a two-dimensional graph called a nomogram which is used online by operators to characterize the security boundaries. Nomograms are defined by boundaries set with respect to limits representing various security criteria [1]. Figure 1 illustrates a nomogram where the boundaries reflect limitations due to different network violations including thermal overload, transient instability, transient voltage dips, voltage instability, and small-signal instability [2]. In practice, these boundaries are identified through the use of repeated simulation of the network, and for dynamic constraints, of machine dynamics. These simulations involve simultaneous solution of a large number of nonlinear algebraic equations, at a minimum, and may also involve numerical integration of a very large differential-algebraic system. As a result, boundary determination for on-line use, which is time-constrained to several minutes, has been very challenging. One approach that has been well-researched is to perform the simulations off-line and then condense the resulting information using a pattern recognition approach such as a neural network [1, 3, 4]. Although conceptually appealing, this approach has not been accepted in practice because of the uncertainty in accuracy of the resulting online information. 2 Figure 1: Nomogram showing acceptable operating conditions for two generation groups [2] The North American Electric Reliability Council (NERC) has recently formalized the notion of security boundary using the term "system operating limit" (SOL). The SOL is defined by NERC [5] as the value (such as MW, MVar, Amperes, Frequency or Volts) that satisfies the most limiting of the prescribed operating criteria for a specified system configuration to ensure operation within acceptable reliability criteria. System Operating Limits are based upon certain operating criteria. These include, but are not limited to: Facility Ratings (Applicable pre- and post- Contingency equipment or facility ratings) Transient Stability Ratings (Applicable pre- and post-Contingency Stability Limits) Voltage Stability Ratings (Applicable pre- and post- Contingency Voltage Stability) System Voltage Limits (Applicable pre- and post- Contingency Voltage Limits) For a given disturbance-performance criteria and stress direction, the SOL is the maximum pre-contingency flow for which all contingencies in the set satisfy the performance criteria. A system for which all conditions are within their SOLs is secure. A system for which one SOL is violated is insecure. 3 SOLs are complex because they depend on operating conditions, reliability criteria, facility ratings, and pre- and post-contingency system performance. This is in contrast to simply comparing existing flows to facility ratings, a common conceptual error that leads to overstated transmission capacity. Many methods and techniques have been introduced for the computation of the SOLs. One paper presents SOLs with respect to voltage collapse by using the binary search (also referred to as the dichotomic search or bisection method) [6]. A similar approach has been discussed for transient angle stability assessment [7]. The notion of SOL is also essential to the application of NERC's transmission loading relief (TLR) levels. Inspection of NERC's operating manual [5] confirms the centrality of SOL in administering TLRs. For many power systems, particularly tightly interconnected ones such as those found in the eastern US interconnection, thermal overload is the most common limiting condition, i.e., most SOLs are due to thermal overload. Even when this is not the case, i.e., when other problems are more constraining than thermal overload, knowledge of the thermal overload boundary is useful as it provides a maximal operating region, i.e., operators are certain that power system conditions must at least be within the boundaries imposed by the thermal overload constraints. This thesis develops a fast way for calculating the SOL for any line imposed by reliability criteria for NERC's class B (i.e., N-1) contingencies. Although the method is limited to SOLs associated with thermal constraints only, it is very fast and therefore capable of presenting on-line results to operators. The method makes use of linear sensitivity factors introduced in [8], also known as Power Transfer Distribution Factors (PTDF). PTDFs have been widely used for contingency analysis [9], Available Transmission Capacity (ATC) calculations [10], TLR procedures [11], and Congestion Revenue Rights (CRR) Applications [12]. The developed algorithm is integrated with the AREVA dispatch training simulator (DTS) and provides operators with each circuit's SOL, which is the maximum flow on that line for which all contingencies result in satisfying reliability criteria. The remainder of this thesis is organized as follows. Chapter 2 describes the generic dispatcher training simulator and discusses the components of the AREVA DTS. Chapter 3 discusses the algorithm developed in this thesis work for calculating the SOL. Chapter 4 4 provides an insight to the implementation of the SOL software using Visual C++ and all the other tools associated with it. Chapter 5 gives simulation results and some validations to the calculated values of the SOL, and Chapter 6 provides conclusions and some recommended future work related to this thesis work. 5 CHAPTER 2. THE DISPATCHER TRAINING SIMULATOR The DTS is a dispatcher training simulator that is intended to train power system dispatchers for routine and emergency scenarios in a controlled, safe off-line manner, as illustrated in Figure 2 where an instructor (on the right) is developing scenarios that are observed by students (on the left). Students are supposed to take action with respect to the scenarios developed by the instructor, as if they were actually at the EMS console within the energy control center. The DTS also has other uses, including real-time prediction and analysis, an engineering tool for operations planning, tuning of EMS applications, a test-bed for new EMS functions, factory acceptance tests, and demonstrations. In the training mode, the instructor sets up scenarios including such events as equipment outages, relay actions, unit output changes, and communication failures. Using these predefined events, the instructor can simulate the actions of power plant and substation operators, neighbouring utility dispatchers, emergency operations, and acts of nature. Figure 2: DTS used in training 6 The DTS is composed of three main subsystems; Energy control system, power system dynamic simulation and an instructional subsystem. Figure 3 provides the components and functionalities of the AREVA DTS/EMS applications interface [13]. References [14, 15, 16, 17] describe the dispatcher simulation process and the models employed in the dispatcher training simulator systems. DTS Instructor DTS Instructional Subsystem Events Simulation Control Power System Simulation DYNAMICS Powerflow Load Model Power Prime Movers Topology Flow Processing Solution Relays data retrieval Network Applications controls Generation Applications SCADA Applications Dispatcher Trainee Figure 3: EMS/DTS interface [13] 2.1 Energy Control System The energy control system emulates normal EMS functions and is the only part of the DTS with which the trainee interacts as shown in Figure 3. It is composed of the supervisory control and data acquisition (SCADA) system, generation control system, network applications and all other EMS functions. The power system model consists of a detailed description of the components and topology of the system and schedules to model the dynamic behaviour of generation, load, 7 and circuit breakers. The dynamics function (long term dynamics are used) simulates prime movers and relays, and calculates island frequencies. DTS power flow calculates the state of the electrical network in consideration to network topology changes, load schedules and prime mover mechanical power. The Long term dynamics simulation details are presented in the next section. Full references on long term dynamic simulations in the DTS environment are provided in [18, 19, 20]. 2.2 Long term Dynamic Simulation The focus of long term dynamics simulation is to analyze the affects of disturbances for extended periods of time on the bulk power system. The assumption of uniform system frequency makes it possible to use numerical step-size of one or more seconds for long term studies, as opposed to a fraction of a cycle for transient stability. The power system model has to simulate the behavior of the real power system; therefore, power system models used in the DTS are based on long term dynamic simulation techniques. The power system model is divided into two groups, the dynamic models group (represented by differential equations) which contains the elements present at the generation plants and protection relays, and the static models group (represented by algebraic equations) which contains the elements that form the power system network. The dynamic models are solved by using numerical integration methods whereas the solution of the network static model is performed by power flow solution methods. Long term power system models include [21, 22]: Plants and prime movers (a) Fossil-Fueled steam turbine and controls (b) Bas turbine and controls (c) Hydro turbine and controls (d) Boiling water reactor and controls System frequency Electric generation and network (a) Synchronous machine 8 (b) Excitation system functions (c) AC transmission lines (d) Transformers (e) Loads AGC (a) Area Model (b) Unit model Relays (a) Under-frequency load shedding (b) Generator under-frequency (c) Under-voltage (Generator and load) (d) Loss of Excitation (e) Distance (f) General purpose (Timed) 2.2.1 Numerical Solution method The principal power system components in long term dynamics simulation is presented in Figure 4 taken from [19]. The system is partitioned into two parts: the generation system and the electrical network. PL, PE and PD refer to scheduled Load, scheduled generation and demanded real power respectively. 9 Figure 4: Partitioned system formulation [19] The specified numerical solution of the system equations is computed by the application of trapezoidal rule integration method. For each time-step, all system variables are incremented by solving the complete system of difference and algebraic equations. The system of difference equations is solved by heuristic procedure of alternately solving the generation system and the electrical network until the interface variables converge. The equations are presented as as a differential-algebraic set, as follows: i) Differential equations & x = Ax + Bu (1) ii) Power flow equations f ( x) = 0 (2) Where x: u: State vector Input signal to generator and controller A,B : Constant coefficient matrix Various numerical integration methods may be applied in solving the above system of equations. One relatively straightforward method is to use a portioned approach whereby the 10 differential equations are solved for a short duration, then the algebraic equations are solved, and then the cycle repeats itself, with each half-cycle making use of information from the other half-cycle. In this case, the integration may be performed in using several different methods, but the trapezoidal rule is perhaps most common because of its stability under relatively large step sizes. To illustrate the operation of the DTS on a simple one-machine system, consider that the system is in power balance. Initially, the power flow is solved, and since it is in power balance, as long as there is no change, there are no dynamics. At the instant a change occurs (e.g., change in demand, or a circuit outage, or a generator outage) then there is a non-zero PD. This activates the dynamics according to the block diagram of Figure 5. 1 R KI s 1 1 + sTH 1 1 + sTT KP 1 + sTP Figure 5: Block diagram of primary and secondary control of generator In Figure 5, the "power system" model is referred to as a "uniform frequency" model, which implies that the frequency of the entire interconnection is uniform at any one instant in time. In this case, the total system inertia H, the system load damping constant D, and the desired frequency f0 determine the power system time constant Tp according to TP = and the gain Kp is determined by the system load damping D according to K P = Pg is the increment in command input to the valve Pv is the increment in steam valve opening 1 . D 2H , f oD 11 PT is the increment in mechanical power output from the turbine The differential equations corresponding to the above block diagram are: & = KP 1 P TP TP Pv , P = PT PD 1 & PT = TT 1 PT TT Pv , Pg = Pref R 1 1 & Pv = Pg TH TH & Pref = K T These equations are solved using numerical integration, typically using a trapezoidal integration rule with 1 second time steps as previously described. Following a certain number of time steps, the real power generation in the power flow is updated by PT, and the power flow equations are thus resolved. The difference between the swing bus generation as a function of the power flow solution, and the swing bus generation as a function of PD update, is the new PD. This value of PD is then used to initialize the dynamic equations for the next cycle of integration. The model presented in Figure 5 is appropriate if all generators have identical characteristics and the inertia is a composite value. Otherwise, repeated blocks need to be added corresponding to the primary and secondary controls of each unit and PD will be shared between the units as a function of their inertia constants, H. The solution of the electrical network is formulated as a power flow solution typically using a fast-decoupled algorithm which tracks from a previous solution unless there is a topology change providing power system data such as MWs, MVARs, KV, etc. 2.3 The Instructional Subsystem The Instructional Subsystem provides means for the instructor to: Load and initialize DTS databases in the DTS environment Save, retrieve, and remove DTS savecases Start, stop, or pause the simulation Set or reset simulation time 12 Define and modify event scenarios 2.4 Elements of the AREVA DTS The AREVA DTS uses the same power system applications, displays, and controls used by the dispatcher in the energy management system. It is composed of SCADA, RTGEN, RTNET and ALARM as shown in Figure 6 [23]. SCADA ALARM INSTRUCT RTGEN RTNET EMS Subsystem Power System Applications + Power System Dynamic Simulation Subsystem Prime mover and Relay Dynamics/Powerflow + Instructional Subsystem DTS control/Events Figure 6: Elements of the DTS [23] The supervisory control and data acquisition (SCADA) system collects data from the monitoring technologies (remote terminal units at substations and power plants), issues control demands, and enters status and analog data. The real-time generation controller (RTGEN) automatically controls generator MW outputs to regulate frequency and interchange; schedules deration, fuel use, and base-point for generating units; schedules sale and purchase of power; and calculates and monitors reserves for each operating area. The ALARM function provides information for investigation of computer and power system problems, notifies the dispatcher of abnormal and uncommanded equipment operation, maintains alarm summary displays, and prints alarm logs. The main differences between the 13 DTS and the EMS are in the SCADA and RTGEN functions (the ALARM function is identical). References [23,24, 25, 26, 27, 28] provide complete documentation of the AREVA EMS and DTS systems. A summary of these documents is provided in this section in order to provide a realistic sense of typical features in a DTS. 2.4.1 The Simulator subsystem The AREVA Simulator provides an off line representation of the monitored power system that can be used to simulate its real time operation and control in the energy control center. It uses the same interfaces and is composed of much of the same software as the realtime EMS. It is originally intended for supplying a realistic environment to system dispatchers in training for practicing various operating tasks under both normal and emergency conditions. For this thesis, the simulator is used for providing real-time simulation of the power system as a test bed for the integration of the SOL software. The AREVA simulator uses a power system dynamical model to create a simulated operating environment. The model contains a detailed description of the components and topology of the system; and a set of schedules for modeling the future status of energy transactions, generation, loads, and circuit breakers. The state of the transmission system is calculated by successive Newton's method power flows, usually every 2 to 8 seconds, and their results are used to update the SCADAMOM database after each iteration. IEEE standard long term dynamics models are used to simulate the dynamic behavior of the generating units' prime movers. Thus, transient responses and inter-machine oscillations are not modelled. The AREVA simulator also includes protection relay models for simulating the action of over current, over/under voltage, over/under frequency and synchro-check relays. Figure 7 provides the AREVA DTS main control display from where the instructor has the ability to control the DTS. Figure 8 displays the generation area status where operators monitor the frequency, Area Control Error (ACE) and transactions in their control area. 14 Figure 7: AREVA DTS main control display 15 Figure 8: AREVA DTS area status display 2.4.2 The SCADA subsystem SCADA manages the data acquisition and supervisory control capabilities for the real-time monitoring and control of the power system. Data acquisition gathers, manages and processes data by scanning remote terminal units (RTUs) installed in the substations and presenting the data to the SCADA processor. The SCADA processor validates the data and performs quality and limit checking before storing it in the real-time SCADA database. 16 The SCADA database provides an updated picture of the power system which allows a real-time monitoring of the state of the devices using a tabular or graphical trend displays. The SCADA database holds three types of power system information; analog values, status values and count values. In the AREVA environment, the SCADA database is called SCADAMOM as seen in Figure 9 below. Modeling applications On-line applications On- Genesys Modeler SCADAMOM Description of the data acquisition and control system _____________________________ GENMOM Description of the generators and automatic generation control Description of tie-lines and interchanges transactions _____________________________ NETMOM Description of the network topology, components and schedules _____________________________ DTSMOM Description of prime movers and relays SCADA RTGEN Powerflow DYNAMICS DTSPSM Figure 9: EMS/DTS databases Supervisory control allows operators to remotely control devices in the field such as open/close of circuit breakers, change the tap position of transformers or change control set points. However the DTS SCADA receives data and handles control requests from a simulator instead of RTUs and devices from the field. Differences between the real-time SCADA and the DTS SCADA are summarized in Table 1 below. 17 Table 1: Real-time/DTS SCADA differences Real-time SCADA SCADA scans physical RTUs. DTS SCADA SCADA scans network model solved by Powerflow. Controls received by DTS controls interpreter. SCADA scan triggered by completion of simulation solution. SCADA communication problems simulated. Controls received by RTU driver. SCADA scans at predefined intervals. Communication problems and failures detected by SCADA. 2.4.3 The Generation subsystem The generation subsystem provides many functions for operational scheduling of the generating subsystem within the control areas monitored by the EMS system. These functions include automatic generation control (AGC), interchange transaction scheduling, load forecasting, economic dispatch and unit commitment. Real-time functions are provided by the RTGEN application of the EMS system. It enables operators to observe, analyse and control real-time generation within the control area. The principle function of the RTGEN is the AGC, a closed loop control algorithm that provides three primary objectives: To maintain the frequency of the system at the scheduled value To maintain net power interchanges between neighbouring control areas To maintain the most economic generation of units Table 2 below provides the application differences between real-time RTGEN and DTS RTGEN. Table 2: Real-time/DTS RTGEN differences Real-time RTGEN AGC is run for the control area. Transactions based on real life. DTS RTGEN AGC is run for all operating areas. Instructor must set up all transactions between external operating areas. 18 2.4.4 The Transmission subsystem Network applications are divided into real-time applications and study applications. These functions determine the state of the power system network, the level of security and how to improve the security and economics of the network. The functions that are included in the transmission subsystem are: Topology processing State estimation Security analysis and security dispatch function Contingency analysis Short circuit analysis Voltage Reactive power dispatch Power flow and optimal power flow Outage scheduler Transfer limits calculation 2.4.5 The e-terra PC Link The e-terra PC link is a tool provided by the e-terra Habitat environment of the AREVA EMS that enables communication between the EMS/DTS databases and external applications running under Microsoft Windows. This functionality is provided by the dynamic data exchange (DDE) service of windows through the execution of the HABDDE program of the AREVA platform. Complete information about the e-terra PC link can be found in [28]. The software built as part of this research work for automated SOL calculation makes use of the Windows DDE service for exchanging information with the e-terra PC Link tool in real time. 19 CHAPTER 3. THE SOL AND ITS CALCULATION Computation of SOLs is limited to those associated with circuit overloads as overload analysis is amenable to efficient analysis via linearization. The approach taken is to use generation shift factors (GSFs) and line outage distribution factors (LODFs) [8] to compute pre-contingency flow limitations on any designated circuit as a function of a specified operating condition, a contingency list, a designated stress direction, and circuit emergency overload ratings. The definitions for GSFs and LODFs are provided first. 3.1 Generation Shift Factors (GSF) The GSFs are linear estimates of the ratio: change in flow to change in power injection at a bus. A change of injection at bus i ( Pi) results in a change of MW power flow on line ( f ), and the ratio of f to Pi is the GSF and is given by a i = f / Pi. Thus the change in flow on circuit due to change in injection Pi is f = a i Pi. It is noted that Pi necessarily implies an equal and opposite change in injection elsewhere in the network. This other change is designated as Pj, recognizing that Pi = Pj. The GSFs are computed from the DC power flow which is a completely linear, noniterative power flow algorithm. It assumes all node voltages equal to the nominal (1.0 pu), thus providing a linear set of equations that relate the vector of node angles vector of nodal injections P: r r P = B. Where: ' Bii = N to the j 1 ' Bij = 1 xij i j 1 , xij The power flows through the branches (lines and transformers) of the network are then calculated as: 20 f l = Pij = 1 xij ( i j ) for a Since the DC power flow is a linear model, a change in bus phase angles given set of changes in the bus power injections are given by: r r = [X ] P Where X = [B ] The 1 values are equal to the derivative of the bus angles with respect to a change in power injection at bus i. Then using f l = Pnm = 1 xl ( n m ) The required sensitivity factor for a branch connecting buses n and m with respect to the injection at node i can be obtained by: a li = df l d 1 = dPi dPi xl ( n m ) a li = 1 ( X ni xl X mi ) Where x is the reactance for circuit terminated at buses m and n, and Xni and Xmi are the elements of matrix X in position (n,i) and (m,i), respectively. 3.2 Line Outage Distribution Factors (LODF) The LODFs are linear estimates of the ratio: change in flow on circuit due to outage of circuit k, denoted by f , to pre-contingency flow on circuit k, denoted by fk0. In other words, it provides the fraction of pre-contingency flow on circuit k that appears on circuit following outage of circuit k, and is given by d ,k = f / fk0. It is then clear that the change in flow on circuit due to the outage of circuit k is given by f = d ,k fk0 In a similar manner presented in the previous section for calculating the GSFs, the LODF for a branch connecting buses i and j after the outage of the branch k between nodes n and m can be obtained by: 21 d l,k xk (X in X jn X im + X jm ) xl = x k ( X nn + X mm 2 X nm ) due to the removal of the branch k from the network. The line outage is In this case, the line outage distribution factor represents the change of the power flowing in branch modeled by adding two power injections to the system, one at each end of the line to be dropped. Further details on the GSFs and LODFs are provided in [8]. 3.3 System Operating Limit (SOL) The SOL for circuit occurs under the condition that f l0 + f l = f lmax (3) where f max is the emergency overload rating for circuit . The goal is to identify the value of flow on circuit , denoted f 0, that makes (3) true, under the condition that flows are changed due to a stress defined by Pi (e.g., a generation shift between buses i and j, or an increase in load at bus j compensated by an increase in generation at bus i) and an outage of circuit k. There are two network changes that determine f . One is the stress, which is given by fl (1) = ali Pi + alj Pj = (ali alj ) Pi (4) The other is the outage of circuit k, f (2) = d ,k fk0. However, the flow on circuit k will be affected by the stress according to fk = (aki akj) Pi. Therefore, fl ( 2) = d l,k f k0 + d l ,k (aki a kj ) Pi (5) Combining (4) (representing the increase in flow on circuit due to the stress) and (5) (representing the increase in flow on circuit due to the outage), the combined change is fl = fl (1) = (ali + fl ( 2) alj ) Pi + d l,k f k0 + d l,k (aki akj ) Pi (6) It is critical to calculate the amount of stress Pi necessary to increase the flow on circuit to f max, as expressed by (3). To determine this amount of stress, is (6) substituted into (3), resulting in 22 f lmax = f l0 + (a li + d l ,k (a ki alj ) Pi + d l , k f k0 a kj ) Pi (7) Solving (7) for Pi to obtain: Pi = f lmax a li a lj + d l , k (a ki f l0 d l , k f k0 a kj ) (8) following the increased stress The SOL for circuit is then the flow on circuit resulting from Pi, - Pj, which can be computed from Equations (3) and (4), resulting in f lSOL = f l0 + (a li alj ) Pi (9) Substituting (8) into (9) results in f SOL l = f + 0 l (a li a lj ) f lmax a li a lj + d l ,k (a ki ( f l0 d l ,k f k0 a kj ) ) (10) The SOL computed by (10) is a pre-contingency value and therefore represents a value that an operator can easily monitor. However, the constraint is driven by the postcontingency scenario. Thus, if the operator keeps the flow on circuit computed by (10), circuit will not overload if circuit k is outaged. Equation (10) provides the SOL of circuit with respect to a particular contingency, below the value which is the outage of circuit k. For a given contingency list, one must compute (10) for each contingency on the list, and then the contingency that gives the lowest value in (10) actually determines the SOL. This is not computationally intensive, but it can be made even less computational by recognizing that only a few contingencies typically drive a particular SOL. 3.4 SOL illustration on a numerical example Figure 10 represents a simple 3-bus system with generation, load and MW line flows with their corresponding direction. The continuous and emergency ratings of the bus1bus3 circuit are 1200 MW and 1300 MW, respectively. The SOL on circuit 1-3 is the maximum MW flow on circuit 1-3 such that the reliability criteria are satisfied, for a stress direction from Bus1 to Bus3. 23 300 MW Bus 2 Total=500 Total=200 900 MW Total=700 Bus 1 Bus 3 1200 MW Figure 10: 3-Bus system before stress Increasing generation on bus1 to 1000 MW and increasing load at bus3 to 1300 MW creates a flow increase of 67 MW on circuit 1-3, as shown in Figure 11. 300 MW 100 333 Total=233 1000MW Bus 2 333 Total=533 200 Total=767 Bus 1 667 100 Bus 3 1300 MW Figure 11: 3-Bus system after stress Loss of circuit 2-3 will increase the flow on circuit 1-3 to 1300 MW (thermal limit) as seen in Figure 12. 300 MW Bus 2 Lose Cct 2-3! 1000MW Total=1300 Bus 1 Bus 3 1300 MW Figure 12: 3-Bus system after stress & contingency of circuit 2-3 Finally, it is observed that the SOL for circuit 1-3 is exactly 767 MW as shown in Figure 13. 24 300 MW Bus 2 Total=500 Total=200 900 MW Total=700 Bus 1 SOL=767 Bus 3 1200 MW Figure 13: SOL for circuit 1-3 3.5 Generalized version of the SOL The GSFs are linear estimates of the change in flow on any monitored line due to a change in generation at any bus in the system. Therefore, the effects of simultaneous changes on several buses can be calculated using superposition. The same concept applied in section II is used to describe a more generalized form of the SOL which allows the stress direction in the system to include multiple buses. In section II, the SOL was limited to the change in generation at bus i compensated by an equal but opposite change in generation at bus j. In this section, the change in injection in a set of buses WG is compensated by an equal but opposite change in injection by another set of buses WL; this determines the stress direction. The elements of WG and WL contain proportionality factors which are the proportion of generation pickup from each unit. Therefore, the change in flow on line due to change in injections at the buses represented in vectors WG and WL is determined by two network changes. One is the stress, which is fl (1) = i [a li i PG WG (i )] + j [a lj PL W L ( j ) ] (11) = [a li WG (i )] j [a lj WL ( j) ] P The other is the outage of circuit k. However, the flow on circuit k will also be affected by the stress fk = i [a ki WG (i)] j [a kj WL ( j) ] P Therefore, the outage of circuit k after being affected by the stress gives the second network change f (2) 25 fl ( 2) = d lk f k0 + d lk i [a ki WG (i )] j [a kj WL ( j ) ] P (12) Combining the increase in flow on circuit fl = fl = i due to the stress ( f (1)) and the increase on circuit due to the outage of circuit k ( f (2)) is given by (1) + fl ( 2) [a li WG (i)] j [a j lj WL ( j) ] P + d lk f k0 (13) + d lk i [a ki WG (i)] [a kj WL ( j) ] P In this case, it is desired that the amount of stress P necessary to increase the flow on circuit to f f l0 + i max . As a result, substituting (13) into (3) results in [a li WG (i)] j [a lj WL ( j) ] P + d lk f k0 + d lk i [a ki WG (i )] j [a kj WL ( j) ] (14) P = f lmax Solving for P gives P= i flmax fl0 dlk fk0 [ali WG (i)] j [a lj WL ( j) + dlk i ] [aki WG (i)] j [a kj WL ( j) ] (15) The SOL for circuit is then the flow on circuit following the increase stress resulting from PG, - PL, which results in f lSOL = f l0 + i [ali WG (i)] j [a lj WL ( j ) ] P (16) Substituting (15) into (16) results in [ali WG (i)] flSOL = fl0 + i i j [a lj WL ( j) flmax ]( fl0 dlk fk0 ) WL ( j) [ali WG (i)] j [a lj WL ( j) + dlk i ] [aki WG (i)] j [a kj ] (17) 26 3.6 Algorithm for choosing the right SOL The SOL software algorithm developed in this work requires, for each monitored line, the calculation of all SOLs associated with each contingency in the system. In theory, the lowest SOL value for the monitored line would correspond to the most restrictive contingency and therefore the SOL value for that line. However, tests and simulations revealed some exceptions to the fact that the lowest value in the SOL list determines the SOL. The SOL developed in this thesis work depends on two factors; stress and contingency. It is important to realize that the user-defined stress can either increase or decrease the MW flow on some monitored line depending on the topology of the system. The contingency, as well, can either increase or decrease the MW flow on some line also depending on the topology of the system. Both stress and contingency affect the MW flow on some monitored line when: Both increase the flow on Stress increases and contingency decreases the flow on Stress decreases and contingency increases the flow on Both decrease the flow on To illustrate how the different stress and contingency combinations affect the SOL, different cases are presented next. 3.6.1 Case I Both stress and contingency increase the MW flow on the monitored line . Figure 14 illustrates this case. This is an ideal case where the contingency k will not overload line is secure) and the amount of stress is nothing but the security margin for line . ( 27 fLMAX Stress Contingency k SOL = fL0 + Stress fL0 Figure 14: SOL Case I 3.6.2 Case II This case is representative of an insecure line , where the contingency k results in an overload on line . Because of that, the stress has an opposite affect on and offloads its flow by an amount necessary to take the post-contingency flow of to f max. This case is illustrated in Figure 15 and clearly shows that the flow on insecure scenario. Stress fLMAX violates the calculated SOL indicating an Contingency k fL0 SOL = fL0 + Stress Figure 15: SOL Case II 3.6.3 Case III A case where the contingency k decreases the MW flow on is shown below in Figure 16. The affect of contingency k requires a high value of stress to increase the post-contingency 28 flow on to f max. The resulting SOL value could be higher than f max in some situations as in Figure 16. fLMAX SOL = fL0 + Stress Stress fL0 Contingency k Figure 16: SOL Case III 3.6.4 Case IV This is where the stress decreases the flow on while the contingency increases the to f max, the stress has to be large flow on . In order to take the post-contingency flow on enough to increase pre-contingency flow on k to a value necessary to take the postcontingency flow on to f max. This case is illustrated in Figure 17 where it is noticed that the resultant SOL value is less than f 0 indicating an insecure case when its not. fLMAX fL0 SOL = fL0 + Stress Stress Contingency k Figure 17: SOL Case IV 29 3.6.5 Case V Here is a situation where both stress and contingency decrease the flow on line . In order to take the post-contingency flow on to f max, the stress has to be large enough to result in reversing the pre-contingency flow on k to a value that will increase the postcontingency flow on to f max. This is represented in Figure 18 where the SOL value could be in an opposite direction of f 0. fLMAX Contingency k fL0 SOL = fL0 + Stress Stress Figure 18: SOL Case V The five cases presented above show how the affect of stress and contingency influence the SOL of some monitored line . Yet, the only SOLs of interest are the ones given in cases I & II because these two cases generate SOL corresponding to the most limiting effects or the worst contingency scenario. On the other hand, Cases 3-5 are misleading and can be ignored. Case III results in SOL larger than f max, case IV generates SOLs lower than f 0; a misleading value indicating an insecure scenario when its not, case IV provides an SOL in the opposite direction of f 0; another misleading value that is unusable in the SOL values this work is trying to calculate. 30 CHAPTER 4. IMPLEMENTATION OF THE SOL SOFTWARE Using visual C++, a program has been developed for implementing thermal SOLs developed earlier in chapter 2. The SOL software makes use of AREVA's DTS by performing a real-time assessment and collecting the necessary electrical status data from the DTS to calculate the SOLs of the lines provided by the EMP60 model. The interface with the AREVA DTS makes use of the dynamic data exchange (DDE) service of Microsoft Windows using AREVA's HABDDE server. The SOL software collects line flows, their corresponding thermal emergency rating, and their reactance and impedance characteristics from the DTS. Every SCADA cycle (8 seconds), the SOL software calculates the GSFs and LODFs and implements an algorithm composed of the equations developed in chapter 3 along with a selection algorithm to provide the SOL for all the circuits in the system for a given stress direction that can be entered by the user through an easy to use interface. Each SOL is determined by a single contingency, which will be called the limiting contingency. There are many contingencies to address, and so, at least in theory, one must compute the SOL for each contingency on the list, and then the contingency that gives the lowest value determines the SOL. The SOL algorithm's chart is provided in Figure 19 and the SOL software is described in more details in the next sections. Complete references on Visual C++ are provided in references [29, 30, 31]. 31 Figure 19: SOL software flowchart 32 4.1 Microsoft Foundation Classes Microsoft Foundation Classes (MFC) is a large library of C++ classes developed by Microsoft for Windows-based applications written in C++, MFC provides an enormous head start. One of the hardest parts of developing C++ programs is designing a logical hierarchy of classes. With MFC, this work has already been done. Thus, MFC has been used to implement the SOL software. 4.2 The MFCDDE Library Microsoft Windows makes it easy to exchange data between different applications. Dynamic Data Exchange (DDE) is the most flexible method when there is a need to transfer data automatically. DDE is a Microsoft Windows protocol that lets two or more programs running under Windows exchange data simultaneously. DDE allows you to set up applications to pass both data and commands from one to the other. Normally one application requests the transfer and the other responds. The application that does the requesting is called the client application, and the application that responds is called the server. (This is not to be confused with the terms client and server as they are used internally within a database program or in a network of computers.) The information passing between client and server is called the conversation. MFCDDE is a library that enables the use of the DDE of Microsoft Windows. Full documentation on this library is provided in reference [32]. MFCDDE connects the SOL software to AREVA's DTS and enables the transfer of all the necessary information through the HABDDE program of AREVA, which makes all the DTS databases available to external applications running under Microsoft Windows. 4.3 The TNT and JAMA Libraries The Template Numerical Toolkit (TNT) is a collection of interfaces and reference implementations of numerical objects useful for scientific computing in C++. The toolkit defines interfaces for basic data structures, such as multidimensional arrays and sparse matrices, commonly used in numerical applications. The goal of this package in this thesis work is to provide matrix manipulation for the X and B matrices. 33 The JAMA library makes use of the matrix manipulations provided in the TNT library to perform LU decomposition on the B matrix to provide its inverse that is the X matrix. The LU decomposition splits the B matrix into a lower triangular matrix L and an upper triangular matrix U, where: B = (LU ) For large-scale power systems, calculations usually involve huge number of parameters creating the need for fast and efficient calculations. Since B' is singular, the TNT library allows its reduction by taking a reference bus (bus 1 is used as a reference bus in this thesis work). Inverting the B' matrix is computationally exhaustive and so the LU decomposition technique provided by the JAMA library to get the X matrix is used. MFCDDE, JAMA and TNT libraries are taken from references [32, 33, 34] respectively. 4.4 The XML file The eXtensible Markup Language (XML) [35] is a technique of using a document, such as a text file, to describe information and making that information available to whatever and whoever can take advantage of it. The description is done so the document can be created by one person or company and used by another person or another company without having to know who first created the document or how it works. This is because the document thus created is not a program, it is not an application: it is just a text-based document. Because XML is very flexible, it can be used in regular Windows applications, in databases, in web-based systems (Internet), in communication applications, in computer networks, in scientific applications, etc. An XML file has been build as part of this thesis work to introduce the DTS information. The XML file works as a data bridge between the SOL software and the AREVA DTS by identifying what information to be extracted and their corresponding locations. A small portion of the XML file is provided in Table 5 below where a certain branch is being tagged for extracting its information. 34 Table 3: Sample of the XML file <Branch Id='37' Name='BRIGHTON31:BRIGHTON32:1' Type='1'> <FromBus Units='Id'>13</FromBus> <ToBus Units='Id'>14</ToBus> <CktN>1</CktN> <Parameters> <R Units='pu'>0</R> <X Units='pu'>0.01</X> <B Units='pu'>0</B> </Parameters> <XFMRInfo> <ControlBus Side='0' Units='Id'>0</ControlBus> <XfmrRatio Units='pu'>1</XfmrRatio> <PhaseShift Units='Rad'>0</PhaseShift> <Step Units='pu'>0</Step> <ControlLimits> <MinTap Units='pu'>0</MinTap> <MaxTap Units='pu'>0</MaxTap> <MinVar Units='MW'>0</MinVar> <MaxVar Units='MW'>0</MaxVar> </ControlLimits> </XFMRInfo> <Ratings> <Rating Units='MVA' Level='1'>9999</Rating> <Rating Units='MVA' Level='2'>9999</Rating> <Rating Units='MVA' Level='3'>9999</Rating> </Ratings> EMSData> <EMSRecord Field='1' Variable='EMS MW FROM'></EMSRecord> <EMSRecord Field='1' Variable='EMS MW TO'></EMSRecord> <EMSRecord Field='1' Variable='EMS MVAR FROM'></EMSRecord> <EMSRecord Field='1' Variable='EMS MVAR TO'></EMSRecord> </EMSData> <Breakers> </Breakers> 35 CHAPTER 5. SIMULATION RESULTS 5.1 The test system AREVA's DTS provide a default 60 bus system called the EMP60, which contains all the information required to run the DTS. The EMP60 model contains complete substation, generation and transmission information to simulate real EMS functions. The online diagram of the entire EMP60 model is provided in Figure 20. However, a simplified representation of the EMP60 model was developed and provided in Figure 21. The system has a peak load of 6,110 MW and generation capacity of 10,865 MW. Figure 20: EMP60 oneline diagram 36 Figure 21: EMP60 simplified representation As seen in Figure 21, the EMP60 model is composed of three areas: EAST, WEST and ECAR where area EAST is the main control area. Load profile and generation resources for each area are provided in Tables 3 and 4 respectively. Table 4: EMP60 model load distribution Area Min Load (MW) Max Load (MW) EAST WEST ECAR Total 612 2,209 1,165 3,986 919 3,244 1,947 6,110 37 Table 5: EMP60 model generation Control Area Unit Rated MVA Min MW Max MW Total Max MW EAST WEST ECAR DOUGLAS:CT1_COMB_CYC DOUGLAS:CT2_COMB_CYC DOUGLAS:G1 DOUGLAS:G2 DOUGLAS:ST_COMB_CYC HEARN:G1 HEARN:G2 LAKEVIEW:GEN1_GENERATOR BVILLE:1 WVILLE:1 CHENAUX:1 CHFALLS:1 CHFALLS:2 HOLDEN:1 NANTCOKE:1 Total 50 50 800 800 40 600 600 800 900 1,000 1,300 800 900 2,200 1,100 11,940 10 10 50 50 10 50 50 50 0 50 50 50 0 50 50 530 50 50 1,000 700 40 500 500 700 825 925 1,100 700 825 2,000 950 10,865 3,540 1,750 5,575 5.2 DTS simulations To complete the description of the DTS, simulated events are presented in this work to further explain the motives and use of the SOL described in chapter 2. In the following simulation case, an outage scenario was established to simulate an overload condition on the EMP60 model of the DTS. Figures 22 represents line PICTON:CHENAUX respectively where the system appears to be secure and no limit violations are present. Line PICTON:CHENAUX has a MW flow of 594 MW and a transfer limit of 750 MW. However, the outage of line CEYLON:MARTDALE as seen in Figure 23 seems to increase the flow on the monitored line to 837 MW; a 120% overload. Line CHENAUX:CHFALLS is also affected by the outage of CEYLON:MARTDALE and approaches its limit. The system appears to be in a secure state, yet the simulation shows that the system is not secure. 38 The advantage of the SOL calculation as will be seen in the next section is that it gives operators real-time thermal limits for the lines to avoid sudden overloads due to outages as seen in the simulation case described above. Figure 22: Pre-contingency condition for PICTON:CHENAUX 39 Figure 23: Post-contingency conditions after the outage of CEYLON:MARTDALE, PICTON:CHENAUX at 120% load 5.3 SOL software simulation from base case The operation of the SOL software and its integration with the AREVA DTS was tested on the EMP60 power system model. The SOL software takes a stress as an input from the user and presents operators with the chosen monitored line's SOLs updated every 8 seconds along with the corresponding limiting circuit as shown in Figure 24. 40 Figure 24: SOL software interface and output There are 6 tie-lines connecting various areas of the system to one another. Areas ECAR and WEST are connected through lines HOLDEN:STINSON, CHENAUX:PICTON and MARTDALE:CEYLON. While lines LAKEVIEW:RICHVIEW, HANOVER:KINCARD and DOUGLAS:HANOVER connect the EAST and WEST areas. All tie-lines in the EMP60 model are 345 kV lines and are responsible for transferring energy back and forth between areas; online monitoring of tie-lines is essential to monitor the imports and exports of each area. The EMP60 model is simulated through the AREVA DTS over the course of 19 hour period resulting in the MW flow verses the SOL values for the five tie-lines discussed in the previous section. Investigation of the generation and load curves for the EMP60 model over the course of the simulation results in Figures 25 27 representing the change of generation 41 and load in the three areas of the EMP60 model. It is clear that the EAST and ECAR areas have access generation while the WEST area has a shortage in generation. Ge neration & Load curve (EAST) 3500 3000 2500 2000 MW 1500 1000 500 0 1/3/2000 3:14 1/3/2000 5:38 1/3/2000 8:02 1/3/2000 10:26 1/3/2000 12:50 Tim e 1/3/2000 15:14 1/3/2000 17:38 1/3/2000 20:02 1/3/2000 22:26 Generation Load Figure 25: Generation and Load profile for area EAST 42 Generation & Load curve (W EST) 3500 3000 2500 2000 MW 1500 1000 500 0 1/3/2000 3:14 1/3/2000 5:38 1/3/2000 8:02 1/3/2000 10:26 1/3/2000 12:50 Tim e 1/3/2000 15:14 1/3/2000 17:38 1/3/2000 20:02 1/3/2000 22:26 Generation Load Figure 26: Generation and Load profile for area WEST Generation & Load curve (ECAR) 3500 3000 2500 2000 MW 1500 1000 500 0 1/3/2000 3:14 1/3/2000 5:38 1/3/2000 8:02 1/3/2000 10:26 1/3/2000 12:50 Tim e 1/3/2000 15:14 1/3/2000 17:38 1/3/2000 20:02 1/3/2000 22:26 Generation Load Figure 27: Generation and Load profile for area ECAR 43 This generation and load profile defines the stress that needs to be defined to calculate the SOLs corresponding to the five tie-lines connecting the different areas. Clearly, the stress of the system is represented by an increase in generation at areas EAST and ECAR compensating an increase in load at area WEST. Using this stress, the EMP60 model was simulated for a 19-hour period to monitor the behavior of the six tie-lines mentioned earlier against the SOLs calculated by the SOL software. The results are provided below for each individual tie-line. 5.3.1 The DOUGLAS:HANOVER tie-line This tie-line connects area EAST to area WEST and has a thermal emergency rating of 675 MW as shown in Figure 28. This line is a special case where the SOL is the same as the thermal emergency rating of the line. This is because DOUGLAS substation has only one connection to the system through HANOVER and has no limiting circuit. The line does violate its SOL and thermal emergency rating twice during the 19-hour period. Flow vs SOL for DOUGLAS:HANOVER 800 700 600 500 MW 400 300 200 100 0 1/3/2000 3:14 1/3/2000 5:38 1/3/2000 8:02 1/3/2000 10:26 1/3/2000 12:50 Time 1/3/2000 15:14 1/3/2000 17:38 1/3/2000 20:02 1/3/2000 22:26 Flow SOL Thermal Figure 28: Flow vs SOL for DOUGLAS:HANOVER 44 5.3.2 The KINCARD:HANOVER tie-line This line connects EAST to area WEST as well and has a thermal emergency rating of 675 MW as shown in Figure 29. The simulation shows that MW flow on the line is well below its thermal emergency rating and its calculated SOL as well. This is a case where the line seems to be secure and no congestion is encountered. Flow vs SOL for KINCARD:HANOVER -800 -700 -600 -500 MW -400 -300 -200 -100 0 1/3/2000 3:14 1/3/2000 5:38 1/3/2000 8:02 1/3/2000 10:26 1/3/2000 12:50 Time 1/3/2000 15:14 1/3/2000 17:38 1/3/2000 20:02 1/3/2000 22:26 Flow SOL Thermal Figure 29: Flow vs SOL for KINCARD:HANOVER 45 5.3.3 The LAKEVIEW:RICHVIEW tie-line This is another line which connects area EAST to area WEST with a thermal emergency rating of 675 MW as provided in Figure 30. This case clearly represents a secure line with a very small security margin though. The MW flow on the line doesn't violate the thermal emergency rating or the calculated SOL through the 19-hour simulation but the results in Figure 30 clearly show that the line is not far from violating its SOL. Flow vs SOL for LAKEVIEW :RICHVIEW 800 700 600 500 MW 400 300 200 100 0 1/3/2000 3:14 1/3/2000 5:38 1/3/2000 8:02 1/3/2000 10:26 1/3/2000 12:50 Time 1/3/2000 15:14 1/3/2000 17:38 1/3/2000 20:02 1/3/2000 22:26 Flow SOL Thermal Figure 30: Flow vs SOL for LAKEVIEW:RICHVIEW 46 5.3.4 The CEYLON:MARTDALE tie-line Connecting area ECAR to area WEST and holding a thermal emergency rating of 675 MW is the CEYLON:MARTDALE tie-line provided in Figure 31. Although the MW flow on the line is well below its thermal emergency rating, it clearly violated the calculated SOL throughout most of the 19-hour period simulation. This is a case where the SOL is most useful to operators because evaluating the condition of the line by just observing the thermal emergency rating is misleading and doesn't show the vulnerability of the current system condition. Flow vs SOL for CEYLON:MARTDALE -800 -700 -600 -500 MW -400 -300 -200 -100 0 1/3/2000 3:14 1/3/2000 5:38 1/3/2000 8:02 1/3/2000 10:26 1/3/2000 12:50 Time 1/3/2000 15:14 1/3/2000 17:38 1/3/2000 20:02 1/3/2000 22:26 Flow SOL Thermal Figure 31: Flow vs SOL for CEYLON:MARTDALE 47 5.3.5 The PICTON:CHENAUX tie-line PICTON:CHENAUX also connects area ECAR to area WEST and has a thermal emergency rating of 750 MW as shown in Figure 30. The line is in violation of its SOL throughout the 19-hour period simulation and in violation of its thermal emergency rating between 8:02 am and 9:50 am. The line is clearly congested and the SOL gives operators an indication of the immediate need to offload the line and perhaps avoid the thermal overloading of the line which, in many cases, causes zone 2 and zone 3 relay tripping which in turn could start cascading outages leading to a system collapse or blackout. Flow vs SOL for PICTON:CHENAUX -900 -800 -700 -600 MW -500 -400 -300 -200 -100 0 1/3/2000 3:14 1/3/2000 5:38 1/3/2000 8:02 1/3/2000 10:26 1/3/2000 12:50 Time Flow SOL Thermal 1/3/2000 15:14 1/3/2000 17:38 1/3/2000 20:02 1/3/2000 22:26 Figure 32: Flow vs SOL for PICTON:CHENAUX 48 5.3.6 The STINSON:HOLDEN tie-line STINSON:HOLDEN connects area ECAR to area WEST and has a thermal emergency rating of 675 MW as provided in Figure 33. The MW flow changes from one direction to another as observed and so does the SOL indicating a secure line for any N-1 contingency. Again, the SOL shows a security margin much smaller than just looking at thermal emergency rating. Flow vs SOL for STINSON:HOLDEN -800 -600 -400 MW -200 0 200 400 1/3/2000 3:14 1/3/2000 5:38 1/3/2000 8:02 1/3/2000 10:26 1/3/2000 12:50 Time 1/3/2000 15:14 1/3/2000 17:38 1/3/2000 20:02 1/3/2000 22:26 Flow SOL Thermal Figure 33: Flow vs SOL for STINSON:HOLDEN 5.4 Testing the SOL values Simulation of the EMP60 power system model from base case results in violations of the SOLs calculated from the SOL software in addition to thermal emergency rating violations as well. PICTON:CHENAUX, CEYLON:MARTDALE and DOUGLAS:HANOVER are in clear violation of their SOLs as presented in Figures 31 and 32. To verify the accuracy of the SOLs calculated by the SOL software, the limiting circuits for PICTON:CHENAUX and CEYLON:MARTDALE are outaged at 4:00 am and 5:00 am respectively. At 4:00 am PICTON:CHENAUX is violating its SOL, as expected, the outage 49 of the limiting circuit (CEYLON:MARTDALE) leads to line overload above the thermal emergency limit as provided in Figure 34. At 5:00 am, the MW flow on CEYLON:MARTDALE equals the SOL limit, and as expected, the outage of the limiting circuit increases the MW flow to its thermal emergency rating as shown in Figure 35. The DTS simulation at the AREVA DTS at 5:00 am is shown in Figure 36 with the one-line diagram of part of the EMP60 model. Flow vs SOL for PICTON:CHENAUX -900 -800 -700 -600 MW -500 -400 -300 -200 -100 0 1/3/2000 3:14 1/3/2000 5:38 1/3/2000 8:02 1/3/2000 10:26 1/3/2000 12:50 Time Flow SOL Thermal Post-contingency flow 1/3/2000 15:14 1/3/2000 17:38 1/3/2000 20:02 1/3/2000 22:26 Figure 34: Post-contingency conditions, PICTON:CHENAUX 118% overload 50 Flow vs SOL for CEYLON:MARTDALE -800 -700 -600 -500 MW -400 -300 -200 -100 0 1/3/2000 3:14 1/3/2000 5:38 1/3/2000 8:02 1/3/2000 10:26 1/3/2000 12:50 Time 1/3/2000 15:14 1/3/2000 17:38 1/3/2000 20:02 1/3/2000 22:26 Flow SOL Thermal Post-contingency flow Figure 35: Post-contingency conditions, CEYLON:MARTDALE at 100% load Figure 36: Post-contingency conditions, CEYLON:MARTDALE at 100% load 51 5.5 Taking action to relief overload The simulation of EMP60 model from base case clearly shows an over-scheduling of transactions between EAST and WEST and also between ECAR and WEST as well. The EAST and WEST areas initially have 900 MW of scheduled transaction, yet Figure 27 shows a violation in the SOL by 47 MW, so the transaction is reduced to 800 MW. Areas ECAR and WEST have a scheduled transaction of 1000 MW and Figures 31 and 32 reveal the SOL violations of tie-lines PICTON:CHENAUX and CEYLON:MARTDALE by over 400 MW. Reducing the transaction from 1000 MW to 500 MW relieves the tie-lines. However, to compensate the load in area WEST, generator BVILLE is brought online. Simulation results are provided in Figures 3742. DOUGLAS:HANOVER, KINCARD HANOVER, LAKEVIEW:RICHVIEW, CEYLON:MARTDALE and STINSON:HOLDEN have no SOL violation throughout the entire simulation period. Flow vs SOL for DOUGLAS:HANOVER 800 700 600 500 MW 400 300 200 100 0 1/3/2000 3:14 1/3/2000 5:38 1/3/2000 8:02 1/3/2000 10:26 1/3/2000 12:50 Time 1/3/2000 15:14 1/3/2000 17:38 1/3/2000 20:02 1/3/2000 22:26 Flow SOL Thermal Figure 37: Flow vs SOL for DOUGLAS:HANOVER after rescheduling 52 Flow vs SOL for KINCARD:HANOVER -800 -600 -400 MW -200 0 200 400 600 1/3/2000 3:14 1/3/2000 5:38 1/3/2000 8:02 1/3/2000 10:26 1/3/2000 12:50 Time 1/3/2000 15:14 1/3/2000 17:38 1/3/2000 20:02 1/3/2000 22:26 Flow SOL Thermal Figure 38: Flow vs SOL for KINCARD:HANOVER after rescheduling Flow vs SOL for LAKEVIEW:RICHVIEW 800 700 600 500 MW 400 300 200 100 0 1/3/2000 3:14 1/3/2000 5:38 1/3/2000 8:02 1/3/2000 10:26 1/3/2000 12:50 Time 1/3/2000 15:14 1/3/2000 17:38 1/3/2000 20:02 1/3/2000 22:26 Flow SOL Thermal Figure 39: Flow vs SOL for LAKEVIEW:RICHVIEW after rescheduling 53 Flow vs SOL for CEYLON:MARTDALE -800 -700 -600 -500 MW -400 -300 -200 -100 0 1/3/2000 3:14 1/3/2000 5:38 1/3/2000 8:02 1/3/2000 10:26 1/3/2000 12:50 Time 1/3/2000 15:14 1/3/2000 17:38 1/3/2000 20:02 1/3/2000 22:26 Flow SOL Thermal Figure 40: Flow vs SOL for CEYLON:MARTDALE after rescheduling Flow vs SOL for STINSON:HOLDEN -800 -600 -400 -200 MW 0 200 400 600 800 1/3/2000 3:14 1/3/2000 5:38 1/3/2000 8:02 1/3/2000 10:26 1/3/2000 12:50 Time 1/3/2000 15:14 1/3/2000 17:38 1/3/2000 20:02 1/3/2000 22:26 Flow SOL Thermal Figure 41: Flow vs SOL for STINSON:HOLDEN after rescheduling 54 Figure 42 shows the change in flow verses SOL for PICTON:CHENAUX. At 9:14 am, the line starts violating its SOL, to offload the line and bring it down to an acceptable value below the SOL, a re-dispatch in generation is required. The GSF matrix calculated in the SOL software contains the necessary information to provide the generator that has the most effect on the line. Generator CHENAUX:CHX1 is the most influential generator on PICTON:CHENAUX and reducing its generation by 230 MW results in decreasing the flow from 508 MW to 367 MW a value below the SOL making the line secure. Flow vs SOL for PICTON:CHENAUX -800 -700 -600 -500 MW -400 -300 -200 -100 0 1/3/2000 3:14 1/3/2000 5:38 1/3/2000 8:02 1/3/2000 10:26 1/3/2000 12:50 Time 1/3/2000 15:14 1/3/2000 17:38 1/3/2000 20:02 1/3/2000 22:26 Flow SOL Thermal Figure 42: Flow vs SOL for PICTON:CHENAUX after rescheduling & re-dispatching 55 CHAPTER 6. CONCLUSIONS AND RECOMMENDED FUTURE WORK 6.1 Conclusions This thesis proposes an automated online computation of thermal SOLs using a combination of linear sensitivity factors; GSFs and LODFs. A Visual C++ program was developed for automated computation of real-time thermal SOL for any line imposed by reliability criteria for NERC's class B (N-1) contingencies. The interface with the AREVA eterra platform is built on the DDE service provided by Microsoft Windows using AREVA's HABDDE server. Every SCADA cycle, the SOL software calculates the PTDFs of the system and implements an efficient and fast algorithm to provide the thermal SOL for all the circuits in the system for a given stress direction. This method is very fast and therefore capable of presenting on-line results to operators in EMS centers. Two versions of the SOLs are presented, a simple 2-bus SOL implemented on a 4-bus system, and a generalized SOL which can include any number of buses to determine any stress. The developed SOL software takes a stress as an input by having the user chose the "From" and "To" buses to determine the direction of the stress. The advantage of online SOLs is providing constant monitoring of line flows and their corresponding SOLs thus helping operators maintain a more secure system. As seen from the simulations, Line flows and SOLs are always monitored and, in case of an SOL violation, the SOL software has the necessary information in the GSF matrix to relief the corresponding violation using a predetermined set of the generating units available. The AREVA DTS proved to be a very valuable tool and served as a test bed for the SOL software developed in this thesis work. Through the DTS, it was possible to acquire a real system, be able to extract all the necessary information for calculation of the SOL, test the calculated SOLs and apply different scenarios and simulations to further test the developed SOL software. The resulting SOLs, although dependant on linear factors, provide very good approximations for the loading of the lines. 56 6.2 Recommended future work In order to make the thermal SOLs developed in this thesis work practical, a number of steps are required. Integrate the SOL algorithm of this work directly into the DTS and allow operators to monitor the SOL through one-line diagram of the system side by side with the MW flow of each line Integrate an algorithm which investigates the load forecast and accordingly identifies the stress in the system with respect to the committed generation. Create an alarm when the MW flow of any line approaches a certain percentage of the calculated SOL (10 or 15%) Allow a trend option of the SOL to graphically monitor flow verses SOL Develop an algorithm to offload the lines that are violating their SOLs based on the linear GSF calculated by the SOL software Insert recommendations automatically into the EMS. A real-time generation control using a set of predetermined generation resources could be implemented just like the AGC function in the EMS/DTS 57 REFERENCES [1] J. D. McCalley, S. Wang, Q. L. Zhao, G. Z. Zhou, R. T. Treinen, A. D. Papalexopoulos, Security Boundary Visualization for Systems Operation, IEEE Trans. On Power Systems, Vol.12, May 1997, pp.940 947. [2] K. Morison, L. Wang, Power System Security Assessment, IEEE power & energy magazine, September/October 2004. [3] C. A. Jensen, M. A. El-Sharkawi, and R. J. Marks, Location of Operating Points on the Dynamic Security Border using Constrained neural Network Inversion, Proc. Int. Conf. Intelligent Systems Applications to Power Systems (ISAP '97), Seoul, Korea, 1997. [4] C. A. Jensen, R. D. Reed, R. J Marks, M. A. El-Sharkawi, Jae-Byung Jung, R. T. Miyamoto, G. M. Anderson, and C. J. Eggen, Inversion of feed-forward neural networks: Algorithms and applications, Proceedings of the IEEE , Volume: 87 Issue: 9 , Sept. 1999 Page(s): 1536 -1549. [5] NERC, NERC Operating Manual, June 15, 2006. [6] T. Van Cutsem, C. Moisse, R. Mailhot, Determination of secure operating limits with respect to voltage collapse, IEEE Trans. On Power Systems, Vol.14, February 1999. [7] R. J. Marceau, R. Mailhot, F. D. Galiana, A generalized shell for dynamic security analysis in operations planning, IEEE Trans. On Power Sustems, Vol. 8, 1993. [8] A. J. Wood and B. F. Wollenberg, Power Generation, Operation, and Control. New York: John Wiley & Sons, Inc., 1996. [9] M. Muslu, R. D. Shultz, An expert system for contingency analysis in power systems, Power Symposium, 1990. Proceedings of the Twenty-Second Annual North American, October 1990, pp. 373 380. 58 [10] S. Grijalva, P. W. Sauer, J. D. Weber, Enhancement of linear ATC calculations by the incorporation of reactive power flows, IEEE Trans. On Power Systems, Volume 18, Issue 2, May 2003, pp.619 624. [11] H. H. Yan, PTDF and TLR from a power marketer's perspective, IEEE Power Engineering Society Summer Meeting, volume 1, July 1999, pp.156 161. [12] M. Lui, G. Gross, Role of distribution factors in congestion revenue rights applications, IEEE Trans. On Power Systems, volume 19, Issue 2, May 2004, pp.802 810. [13] M. E. El-Hawary, Electrical Energy Systems. Boca Raton, Florida: CRC Press LLC, 2000. [14] J. R. Latimer, R. D. Masiello, A Dispatcher Training Simulator System, Minnesota Conference, October 12-13, 1976. [15] J. R. Latimer, R. D. Masiello, Design of a Dispatcher Training Simulator, PICA, May 1977. [16] R. D. Masiello, D. M. Morrison, Dispatcher Training Simulator: Present & Future, 1981 [17] T. E. DyLiacco, M. K. Enns, J. D. Schoeffler, J. J. Quara, D. L. Rosa, C. W. Jurkoshek, M. D. Anderson, Considerations in Developing and Utilizing Operator Training Simulators, PICA 83, Houston, May 1983, pp. 293-99. [18] K. Saikawa, M. Goto, Y. Imamura, M. Takato, T. Kante, Real Time Simulation of Large-Scale power system Dynamics for a Dispatcher Training Simulator, 84 WM 0980, December 1984, pp. 3496-3501. [19] K. Hemmaplardh, J. W. Lamont, J. W. Manke, W. R. Pauly, Considerations for a Long Term Dynamics Simulation Program, IEEE, 85 SM 500-4. 59 [20] K. Hemmaplardh, E. G. Gate, R. A. Hamond, S. A. Scakett, Applications of Dynamic Models in Dispatcher Training Simulation and in Other System Dynamic Performance Studies, IEEE, Trans., v. PAS-104, n. 6, June 1985, pp. 1349. [21] M. Prais, C. Johnson, A. Bose and D. Curtice, Operator Training Simulator: Component Models, IEEE Transactions on Power Systems, Vol. 4, No. 3, August 1989. [22] M. Prais, C. Johnson, A. Bose and D. Curtice, Operator Training Simulator: Algorithms and Test Results, IEEE Transactions on Power Systems, Vol. 4, No. 3, August 1989. [23] DTS Instructor Course Workbook, version 2.3, AREVA T&D, July 2003. [24] e-terra SCADA operator's guide, version 2.3, AREVA T&D, September 2004. [25] e-terra Generation operator's guide, version 2.3, AREVA T&D, September 2004. [26] e-terra Transmission operator's guide, version 2.3, AREVA T&D, September 2004. [27] e-terra Simulator instructor's guide, version 2.3, AREVA T&D, September 2004. [28] e-terra PC link user's guide, version 5.5, AREVA T&D, September 2004. [29] J.R. Berryhill, C++ scientific programming, New York, NY: John Wiley & Sons, 2001. [30] B. Stroustrup, The C++ programming language, Indianapolis, IN: Addison Wesley, 1997. [31] E. Olafsen, K. Scribner, K. D. White, MFC programming with Visual C++ 6, Sams Publishing, June 1999. [32] MFCDDE, version 1.0, Julian Smart, December 23, 1996. 60 [33] JAMA, Mathworks and NIST <http://math.nist.gov/javanumerics/jama> [34] TNT, NIST, version 1.2.4, Gaithersburg. [35] H. Williamson, XML: The complete reference, Berkeley, CA: Osborne/McGraw- Hill, 2001.
MOST POPULAR MATERIALS FROM ECE
MOST POPULAR MATERIALS FROM Iowa State