Open Collections

UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Implementation of a real time simulator for protective relay testing Calviño-Fraga, Jesús 1999

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
831-ubc_1999-0407.pdf [ 2.79MB ]
Metadata
JSON: 831-1.0065261.json
JSON-LD: 831-1.0065261-ld.json
RDF/XML (Pretty): 831-1.0065261-rdf.xml
RDF/JSON: 831-1.0065261-rdf.json
Turtle: 831-1.0065261-turtle.txt
N-Triples: 831-1.0065261-rdf-ntriples.txt
Original Record: 831-1.0065261-source.json
Full Text
831-1.0065261-fulltext.txt
Citation
831-1.0065261.ris

Full Text

IMPLEMENTATION OF A REAL TIME SIMULATOR FOR PROTECTIVE RELAY TESTING by JESUS CALVINO-FRAGA. Electronics Engineer, Simon Bolivar University, 1987 A THESIS SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF APPLIED SCIENCE in THE FACULTY OF GRADUATE STUDIES DEPARTMENT OF ELECTRICAL ENGINEERING We accept this thesis as conforming /tojjie reaun^d standard The University of British Columbia June 1999 © Jesus Calvino-Fraga, 1999 In presenting this thesis in partial fulfilment of the requirements for an advanced degree at the University of British Columbia, I agree that the Library shall make it freely available for reference and study. I further agree that permission for extensive copying of this thesis for scholarly purposes may be granted by the head of my department or by his or her representatives. It is understood that copying or publication of this thesis for financial gain shall not be allowed without my written permission. Department of e^6CfR^/^C £AjCi/A/£tFKiflj G The University of British Columbia Vancouver, Canada Date ^ C i y 2 6 DE-6 mm Abstract Details on the implementation of the Real-Time simulator for protective relay tester on an off-the-shelf hardware platform are presented. This simulator is a particular implementation of the OVNI simulator (Object Virtual Network Integrator) being developed at the Power System Simulation Laboratory of the University of British Columbia. This report includes the details on the implementation of fast and accurate models for current and coupling-capacitor voltage transformers. Also described are the details on the implementation of accurate timing and other operating system related issues. The user interface program, as well as details on the hardware/software implementation of the simulator are also presented. i i Contents Abstract ii Contents iii List of Tables v List of Figures vi Acknowledgements vii I. Introduction 1 II. Real-Time Relay Tester 8 1 Requirements 8 2 The Core Source Code 11 3 Hardware Configuration for the Real Time Relay Tester 12 4 Running Test Cases 13 5 The Configuration File 16 6 Inline Options 18 III. Interfacing the Real Time Simulator With External Devices 20 1 Switches and Digital Inputs 20 2 Reading and Processing External Switching Events 21 3 Analog Outputs 23 4 Preconditioning the Analog Outputs: Current and Voltage Transformers. 24 4.1 Current Transformers 25 4.2 Coupling-Capacitor Voltage Transformers 30 IV. Accurate Real Time 36 1 Using an Internal Counter as Time Reference 36 1.1 The Real Time Simulator and the CTC 37 1.2 Configuring and using CTC Counter 0 Under Phar Lap TNT 38 1.3 Measuring the Execution Time Using the CTC 42 2 Using an External Interrupt as the Source for the Time Reference 44 3 Using the Time Stamp Counter 45 iii 3.1 Measuring the Execution Time Using the RDTSC Instruction 49 4 Comparison of the Different Methods Used to Generate the Time Reference 50 V. The Monitoring Computer 53 1 Hardware requirements for the Monitoring Computer 53 2 The Monitoring Program 55 VI. Conclusions and Recommendations 58 VII. References 60 Appendix I. Test Case Files. 62 1 Circuit Schematic 63 2 Preprocessor Input File 63 3 The real-time simulator input file 65 Appendix II. Microtran Input File for the CT Simulation. 71 iv List of Tables Table 1. Preprocessor File structure 15 Table 2. The "DACS" section was created for this version of the simulator 16 Table 3. The configuration file rtns.cnf 19 Table 4. Formulas used to calculate the values of the circuit in figure 12 28 Table 5. Formulas used to calculate the values of the circuit in figure 18 34 V List of Figures Figure 1. Typical setup of a TNA for relay testing 3 Figure 2. Typical setup of a playback simulator for relay testing 4 Figure 3. Setup of a real time simulator for relay testing 5 Figure 4. Magnitude and Phase responses of the used integration rules 9 Figure 5. The Implemented real time relay tester 12 Figure 6. Steps to create and run a test case in the real-time relay tester 14 Figure 7. A simple test case 20 Figure 8. Transitions in the digital inputs are not instantaneous 22 Figure 9. The state machine used to debounce digital inputs 23 Figure 10. Equivalent circuit of a current transformer 25 Figure 11. Piece-wise representation of a nonlinear inductance 26 Figure 12. Discrete time representation of the circuit in figure 10 26 Figure 13. Resulting output current obtained using the implemented model and the same circuit simulated using Microtran 29 Figure 14. Coupling-capacitor voltage transformer (CCVT) circuit 30 Figure 15. Equivalent circuit for the CCVT 31 Figure 16. Simplified version of the equivalent circuit for the CCVT 32 Figure 17. Discrete time representation of the circuit in figure 16 33 Figure 18. Frequency response of the detailed circuit of figure 15 as reported by Hou and Roberts in [19] (dashed line) and for the simplified circuit of figure 16 (solid line) 35 Figure 19. Block diagram of the CTC present in x86 computers 37 Figure 20. Execution times per time step found using the CTC 44 Figure 21. Execution times per time step found using the RDTSC instruction 50 Figure 22. A snapshot of the monitoring program 57 Figure 23. Analog output 9 is used to signal switching events 57 vi Acknowledgements I would like to thank the following people for their contribution to this thesis: Dr. Jose R. Marti for his supervision and financial support, and To Roberto Rosales for all his help and guidance. Jesus Calvino-Fraga vii I. Introduction Power system networks are protected by devices called Relays. In general terms, a relay is a device originally used in telegraphy, that has a coil, which when energized by a weak receiving current attracts an armature that closes a contact in the line ahead, "giving a 'relayed' signal of renewed 'strength' " [5].. A similar approach was used in the early days of power systems for the protection of its components; although now, protective relays are quite more elaborate than just coils, armatures and contacts. According to Mason in [4], the function of a protective relay is to remove from service any element from the power system when it suffers a short circuit, or when it starts to operate in any abnormal manner. In this approach, the relay is responsible for tripping (i.e., opening) the circuit breaker that disconnects the faulty element from the system. The relay bases the decision of tripping the circuit breaker on the information it gets from the faulty element such as currents, voltages, power, etc. Since their humble origin as simple electromechanical devices, protective relays have grown in complexity and performance. Today relays are microprocessor based, which makes them very flexible. This flexibility comes with a price though. Since the relay is so dependent for its correct operation on a given setup, its behavior cannot be guaranteed unless it is appropriately tested. It is not practical to test a relay by means of directly connecting it to the power system. Most times, it is very difficult to create the required conditions for a 1 given test case, not to mention the loss of revenue caused by taking out of service any portion of the power system, or the risk involved in such kind of tests. A better approach is required for relay testing. More suitably, relay testing is performed by means of using a driver to simulate the system the relay is intended to protect. Electric power systems are usually very complex, making them difficult to simulate. This is the main problem for relay testing: the availability of a suitable testing device or driver. Currently, there are three kinds of drivers to perform relay testing: Analog Scaled Network Simulators, Playback Digital simulators, and Real-Time simulators. Analog Scaled Network Simulators, also called Transient Network Analyzers or TNAs, were the first, and up to the middle 1970s the only, network simulators available for relay testing. They are basically a scaled representation of the network they are intended to simulate [2][5]. The main advantage of this kind of simulators is that they are capable of receiving feedback from the relay, so the relay affects the behavior of the network. Their main disadvantage is their high cost, bulky size, and the lack of flexibility to adapt to different network configurations. Analog scaled simulators have also problems simulating some network elements such as transmission lines, where most of the parameters depend on the actual size and configuration of the line [6]. The overall error associated with this kind of simulators is around ±2%, which corresponds to the typical error of the components the simulator is made of [5]. The typical setup to perform relay testing using Analog Scaled Simulators is shown in figure 1. The currents and voltages of the equivalent system are scaled down, then they are amplified before being fed to the relay under test. The trip 2 signals provided by the relay are used to control the breakers in the equivalent system. Oscilloscopes or data acquisition computers are used to monitor the relevant parameters of the test. S e a 1 e d N e t u o r k S i m u l a t o r fimpl i - T i e n s D a t a ftdaiuisiti o n C o m p u t e r Figure 1. Typical setup of a TNA for relay testing Play-back digital simulators use some form of recorded information which corresponds to the system the relay is intended to protect. Initially, the recorded information came from real electric systems, where similar conditions as those required for the test had occurred. In the middle 1970s, the Electromagnetics Transients Program EMTP [9] began displacing TNAs to simulate power system transient conditions. The EMTP represented an important advance from analog simulators in cost, size, and precision. It did not take long before the EMTP and derived programs began to be used for testing relays. The typical setup for testing relays using playback simulators is shown in figure 2 [2]. It consists of a pair of computers, A/D converters and power amplifiers. One of the computers is used to simulate the system the relay is intended to protect and to generate the data files of currents and voltages required to test the relay. Then, those data files are fed RELAY 3 into a second computer called the play back computer. The play back computer scales the currents and voltages, transforms them to analog signals using digital to analog converters (D/As), and finally, feeds them to the power amplifiers. The output of the power amplifiers is then fed to the relay under test. S i m u l a t i o n Computer P1ay—Back Computer D / A Conven t e n s Amp1 i f i e r s RELAY Figure 2. Typical setup of a playback simulator for relay testing The trip signals provided by the relay, as well as other signals of interest, are monitored by the play-back computer, although any other scheme of monitoring, such as an additional computer, could be used [9]. It should be noticed that in this scheme it is not possible for the relay under test to trip the equivalent circuit breakers in the simulated circuit. That is why play-back digital simulators are also known as "open loop relay testers" [8]. Testing times are usually short, due to the finite storage capacity of the play-back computers. Normal simulation times are around 5 minutes. The overall error associated with playback simulators is basically the error introduced by the simulation of the network: around ± 3 % . 4 Real time simulators are the most recent drivers used for relay testing. They simulate the network and output the required currents and voltages in real time, allowing the relay to interact with the simulation of the network they are intended to protect. Up to the end of the 1980s, this type of simulators were not feasible because of the high computational requirements of the simulation algorithms [6][10]. Since then, improvements in both the simulation algorithms and hardware platforms have made possible the implementation of some real-time simulators. All the real-time simulators for relay testing in the market today are based on improved EMTP-like algorithms. The typical configuration for relay testing using a real-time simulator is shown in figure 3. S i m u l a t i o n Computer D / A Conven t ens ftmpl i - F i e r s RELAY D a t a A c q u i s i t i o n Computer Figure 3. Setup of a real time simulator for relay testing Real-time simulators consist, basically, of a simulation computer, a monitoring computer, D/A converters, and power amplifiers [11]. In this scheme, the simulation computer is responsible for running the simulation of the network, scaling the resulting voltages and currents, and converting them to physical signals by using D/A converters and power amplifiers. The amplified signals are then fed 5 into the relay under test. The trip signals of the relay are fed back to the network simulation computer, which uses that information to modify the configuration of the equivalent network that is being simulated. That is the reason why real-time simulators are also called feedback simulators. The output signals of the relay under test, as well as all the voltages and currents of interest, are also fed to the data acquisition computer, where the results of the test can be analyzed. Simulation times can last as large as required; there is no inherent time limit at which to stop the simulation, as there is with play-back simulators. Similarly to play-back simulators, the overall error associated with real-time simulators is basically the error introduced by the simulation of the network: around ±3%. The work described in this thesis report is part of the OVNI project [22] to develop a general-purpose real-time power system simulator based on personal computers and standard off-the-shelf components. In particular, the work in this thesis corresponds to the development of a software/hardware interface that allows the application of OVNI to the real-time closed-loop testing of protective relays. This implementation has been highly successful and simulation times as low as 20 ps/step have been achieved for systems of about 24 nodes using four analog outputs using a standard Pentium II 400 MHz computer. This system size is normally adequate for testing of protective relays. The power system simulation software used for the relay tester is the RTNS code [12] written by Luis Linares. Additional software developed for the relay tester include the user interface routines, models for current transformers and coupling-capacitor voltage transformers, plus the low-level I/O interface routines. 6 The achieved small simulation time greatly decreases the errors for the higher frequencies response of the real time simulator. This increased frequency response, however, poses a bigger demand for the implemented models of current and voltage transformers. The models implemented in this thesis are accurate up to 6 kHz, while it was still possible to keep the computational burden imposed on the total simulation time to less than 0.5 us/step per simulated transformer. The feed-back mechanism, I/O operations, and the use of an accurate time reference are also described. The program used in the monitoring computer is described as well. Finally some conclusions and recommendations are listed to improve future versions of the OVNI simulator. 7 II. Real-Time Relay Tester 1 Requirements Most of the requirements for the real time simulator are listed in the operational committee report of the IEEE Working Group F-8 of Relay Input Sources [8]. Among the requirements are: • Simulation step of 50 jus or less for an adequate output signal bandwidth. This is, by far, the hardest requirement to achieve in any real time simulator for relay testing. For instance, it has been suggested that a signal bandwidth of 2000 Hz, in which the numerical error is 3% or less, must be achieved in order to properly test relays [6]. The main integration rules used in OVNI are the trapezoidal rule and the backward Euler rule. However, for the implementation of the model for current transformers performed in this project, a new integration rule developed by this author is used. Figure 4 shows the magnitude and phase response for the trapezoidal rule and for Calvino's rule. The frequency at which the total error of 3% begins is about 2 0 % of the Nyquist frequency (fN) for both rules. Therefore, the maximum time step for the simulation (At) can be calculated using the formula: 2000Hz = 0.2 -fN=>fN= 100007/z 1 1 / „ = ^ 1 0 0 0 0 / / z = =>At = 50us J N 2At 2At ^ 8 Figure 4. Magnitude and Phase responses of the used integration rules Feedback. Feedback is referred to as the ability of devices, external to the simulation computer, to modify the network being simulated. These devices could be either the monitoring computer or the relay under test. This feature is achieved in this implementation by reading binary inputs from a digital input board, and mapping them to switches in the network being simulated in the simulation computer. Long Simulation Times. This is one of the features of real time simulators for relay testing that cannot be easily achieved using other kind of simulators. For this implementation of OVNI there is not a designed maximum simulation time, in fact the simulator has been let run for more than 200 straight hours with no numerical stability problems. Program monitoring. A suitable user interface has to be provided in order to allow easy control and monitoring of the simulation computer. For this implementation of the real time simulator a monitoring program was written using LabWindows/CVI from National Instruments, running under Windows 95/98/NT. The program allows the creation and downloading of test cases to the simulation computer, simulation of faults, and capture and presentation of the generated data. Other important requirements developed in our group's work are the following: • Time step accuracy. This important requirement is not listed in [8], but turned out to be very important for the implementation of the real time simulator. For example, consider a test case in which a time step of 21.789 u.s is required, but a time step of 23 us is the one that can be generated. Then, the resulting simulation will have an error of about 5.56%. This error appears as a frequency shift in the analog outputs of the simulator. For instance, if a 60 Hz signal is expected for the time step of 21.789 (is, then the resulting frequency will be 63.34 Hz for the 23 us time step. This difference could be very important for the correct operation of some relays which require a 60 Hz input frequency to perform computations accurately [7][13]. The methods used to achieve an accurate time step in OVNI are described in chapter IV of this thesis report. • Off-the-shelf components. From its beginning [6], it has been a basic premise of the OVNI project that the simulator should be built using only off-the-shelf hardware components, and that the software should be written using a standard high-level compiler, with easily available development tools. At present, the hardware solution is built around Intel Pentiums PC's while the C/C++ programming language is used for software development. 10 2 The Core Source Code This implementation of OVNI is based on the code written by Luis Linares in 1993 and reported in [12]. This code is written in standard ANSI C. As reported in [12], great importance was given to the fact of making the code compatible with any computer platform with a standard ANSI C compiler. However, some relaxation of this requirement has been necessary for some instructions which are hardware related, such as I/O operations. The original code included the following network elements: • Lumped elements: resistances, inductances, and capacitances. Both inductances and capacitances are implemented using the trapezoidal rule of integration. • Lossless transmission lines. • Voltage sources. • Metal-Oxide varistors, MOV. • Switches. For this relay-testing implementation, the following elements were added and are described with more detail in chapter III of this report: • Current transformers. • Coupling-capacitor voltage transformers. The following elements were modified to properly interface with the hardware: • Current and voltage outputs • Switches These changes are also described in chapter III of this report. 11 3 Hardware Configuration for the Real Time Relay Tester The basic hardware configuration presented in figure 3 was used for the implementation of the real time simulator (figure 5). It consists of two" computers: one of them is a high performance computer, used to run the core software for the real time simulator. The other is used to generate test cases and to monitor and control the simulation computer. The real time relay tester uses the TNT Embedded ToolSuite operating system from Phar Lap Software Inc. running in the core computer, and Windows 95 running in the monitoring computer with software developed using LabWindows/CVI from National Instruments (figure 5). A/D DO \ \ Simulation I , , , I I I ; ; Computer D/A | 1—| ^ 1^ I 'RTS-TNT^'^M-DDH-Power Amp. LabWindovus/CVI Pentium ll-200MHz PJS-TNT8.5 Pentium II-400MHz 1 Relay Under Test Figure 5. The Implemented real time relay tester Under this scheme, the simulation computer, while running the core software, reads the digital input port attached to it, and maps each bit to an equivalent switch in the system being simulated. The digital inputs can either represent faults or breakers. If they are used as faults, they are connected directly to the monitoring computer through one of its digital output ports. Otherwise, they are connected to the relay under test, which should be able to trip the simulated 12 circuit from the system conditions created by the faults introduced using the monitoring computer. The voltages and currents required by the relay under test are generated using a digital to analog converter (DAC) board installed in the simulation computer. These signals, once properly amplified, are fed to the relay under test. In order for the monitoring computer to have feedback of what is happening during the simulation, an analog to digital converter (ADC) board is used to capture the outputs of the simulation computer and present them to the user. 4 Running Test Cases The process of creating and running a test case using the OVNI simulator for relay testing was kept basically the same as in the original code of RTNS [12]. As shown in figure 6a , the process of creating a case with RTNS is as follows: 1. Using a text editor, a test case file with extension RTP describing the circuit required in the simulation is created. 2. The RTP file is converted into a file suitable for the real time simulator core program, by means of a pre-processor. The resulting file has extension RTI. 3. The RTI file is passed to the real time simulation program which generates an output file with the desired currents and voltages for each time step in a file with extension OUT. The differences in the process for the generation of a test case for the real-time relay tester (figure 6b) are in the third step, where instead of storing the 13 desired voltages and currents in a file, they are converted to physical voltages using digital to analog converters. Text Text Editor: Editor . RTP , RTP .RTI Pre Pre Proccessor Proccessor .RTI Simulator ,OUT (a) * Simulator D/A Converters Figure 6. Steps to create and run a test case in the real-time relay tester The format of the preprocessor input file RTP, as well as the preprocessor itself are described in [12]. The data file is divided into sections. Each section begins with the keyword .BEGIN, followed by an identifying label, and ends with the keyword END, followed by the same identifying label. The original format was created with six different sections: GENERAL-DATA, LUMPED, LINES, SOURCES , SWITCHES, and OUTPUT (table 1). 14 . B E G I N F I L E . B E G I N GENERAL-DATA (. . .) .END GENERAL-DATA . B E G I N LUMPED (. . .) .END LUMPED . B E G I N L I N E S . B E G I N L I N E - 0 (. . .) ' .END L I N E - 0 . B E G I N L I N E - 1 ( . . . ) .END L I N E - 1 . B E G I N L I N E - 2 ( . . . ) . END L I N E - 2 .END L I N E S . B E G I N SOURCES ( . . . ) .END SOURCES . B E G I N SWITCHES (...) .END SWITCHES . B E G I N OUTPUT ( . . . ) .END OUTPUT . B E G I N DACS . B E G I N TO ( . . . ) . END TO . B E G I N T l (...) .END T l .END DACS .END F I L E Table 1. Preprocessor File structure An additional section, DACS, was added to the preprocessor input file, since the implementation of the relay tester required models for current and voltage transformers. This section tells the preprocessor about the number of analog outputs the simulation is going to handle, as well as the type and component values of each transformer (table 2). Three types of output devices can be specified by means of using the appropriate keyword: CCVTfor coupling-capacitor voltage transformers, CT for current transformers, or NONE when just a scaled value of the desired voltage or current is desired. Detailed information regarding 15 the design of the CTs and CCVTs is presented in chapter III. Table 2 shows examples of the three types of output devices. TO corresponds to a CCVT whose output has to be generated using logical DAC 0. The actual I/O address for DAC 0 is specified using the configuration file rtns.cnf, to be explained later. A similar example is presented for a CT labeled T1 and a direct output labeled T 2 . .BEGIN DACS t o t a l : 2 .BEGIN TO type: CCVT por t : 0 CI: 9.97E-08 C2: 3.00E-10 Cc: 1.30E-10 Lc: 0.708 Rc: 628 Rf: 37.5 Lf: 0.73 Cf: 9.6E-06 R: 100 r a t i o a : 5000 r a t i o b : 110 .END TO .BEGIN T l type: CT por t : 1 L f [ 0 ] : 1.0E-02 L f [ 1 ] : 1.0E-03 Lf [2] : 1.OE-04 I f [ 0 ] : 4.5E+00 I f [ 1 ] : 6.5E+00 I f [2] : 8.0E+00 Rf: 1.0E+03 Ls: 5.0E-04 Rs: 5.0E-01 Lb: 5.0E-04 Rb: 1.25 r a t i o : 120 .END T l .BEGIN T2 type: NONE por t : 2 s c a l i n g : 1000 .END T2 .END DACS Table 2. The "DACS" section was created for this version of the simulator 5 The Configuration File Since the simulator has to be able to work with different commercially available analog output boards, a configuration file, rtns.cnf, is used to map the individual I/O addresses of each digital to analog converter to a logical output port. The configuration file also specifies both the initialization and the shutdown sequences for the analog output board. The following keywords are used: DAC_enable: - Marks the beginning of the instructions to set up and enable the analog output board. 16 DAC_disable: - Marks the beginning of the instructions to disable and/or shut down the analog output board. base: word - Set the base address for the DAC board. All I/O operations are done adding the corresponding number to the base. For example, if base is set to 0x280, an input operation to address 0x281 looks like iw: 0x1. If absolute addresses are preferred, base must be set to 0. There could be as many base statements as required in the configuration file. This allows the use of more than one analog output board at the same time in the real time simulator. end: - Marks the end, either of the DAC_enable or DAC_disable sections. iw: port - Reads a word (16 bits) from the given port. ib: port - Reads a byte (8 bits) from the given port ow: port value - Writes a word (16 bits) to the given port. ob: port value - Writes a byte (8 bits) to the given port. di: port - Sets the address for the digital input port. dac: logic physical - Assigns a physical DAC output address to a logical address. Any other words, as well as indentation, are ignored. Table 3 shows the configuration file used for the AT-AO-10 DAC board from National Instruments. This file was constructed using the configuration guidelines suggested in the AT-AO-10 DAC board manual [15]. 17 6 Inline Options A useful set of command input options was also added to the real time simulator. These options are of great importance for test case time measurement, as well as for the control of the simulation. These options are: t - Instructs the simulator to find the execution time per time step for a given case. The average, minimum, and maximum execution time, for 2000 time steps are reported. These times depend on the particular test case, as well as the speed of the computer being used. The simulator will not run any case whose maximum time step execution time is larger than the required integration time step, unless option n is specified. n - Instructs the simulator to run the case even if the required execution time per integration time step is smaller than the maximum physical time step. This option is useful for debugging purposes only, p - Produces the file 'rtimes.m' which lists the execution times per time step. This file can be plotted using Matlab. The plots of figures 22 and 23 were generated using this option. d - Display all information messages. This option is useful for debugging purposes only. e - Ignore Start/Stop signal. A dedicated digital input pin is used to either start or stop the simulation in the core computer. If the real time simulator senses this signal in logical zero before starting a test case, it waits until the signal goes to logical one before proceeding. By using this option the real 18 time simulator starts the simulation without waiting for the external signal to go to logical one. RTNS Hardware c o n f i g u r a t i o n f i l e f o r N a t i o n a l Instruments ATAO10 DAC_enable: base: OxlCO /*Maps the l o g i c a l DAC to the P h y s i c a l DAC */ dac: 0 OxOC dac: 1 OxOE dac: 2 0x10 dac: 3 0x12 dac: 4 0x14 dac: 5 0x16 dac: 6 0x18 dac: 7 OxlA dac: 8 OxlC dac: 9 OxlE / ^ I n i t i a l i z e AT-AO-10 as recommended i n the manual*/ ow: 0x0a 0x0000 ob: 0x09 0x18 ob: 0x06 0x03 ow: 0x09 0x0058 ow: 0x02 0x0000 ow: 0x04 0x0000 iw: OxOC ow: OxOA 0x0089 /*No d i g i t a l outputs, only i n p u t s * / ow: 0x02 0x0000 ow: 0x04 0x0000 ow: 0x00 0x0000 /*S e l e c t a l l DACS f o r e x t e r n a l update using counter 1*/ ow: 0x02 0x00f8 / * I n i t a l i z e a l l outputs to 0 v o l t s * / ow: OxOC 0 ow: OxOE 0 ow: 0x10 0 ow: 0x12 0 ow: 0x14 0 ow: 0x16 0 ow: 0x18 0 ow: OxlA 0 ow: OxlC 0 ow: OxlE 0x3ff /*Map the d i g i t a l i n p u t s * / d i : 0x00 end: DAC_disable: base: OxlCO ow: OxOA 0x0009 ow: 0x02 0x00f8 end: Table 3. The configuration file rtns.cnf 19 III. Interfacing the Real Time Simulator With External Devices The process of interfacing the real time simulator with external devices, either the relay under test or the monitoring computer, is achieved by using digital inputs to control the simulated circuit breakers (switches), and digital to analog converters to output the current and voltages from the system's solution to the equipment under test. 1 Switches and Digital Inputs The code of RTNS was modified to add dynamic "on-the-fly" switching events while the simulator is running. For instance, suppose that the circuit of figure 7 has to be simulated. The output of the simulation, to be connected to the relay under test, would be the current ' i ' flowing through the inductance. For this particular case, two switching events can change the topological configuration of the circuit: One is the circuit breaker, which when open, causes the current to go to 0. The other, is the fault that, when closed, causes the current to increase by a large value. Figure 7. A simple test case 20 Under normal conditions, the circuit has the breaker closed and the fault open. In the real-time relay tester the breaker operation is commanded by an external device: the relay under test. To achieve this task, both switches are logically mapped as bits in a digital port, which is read periodically. Based on the read in information, the logical switches are set or reset to reflect the condition present in the digital port. Two important factors have to be taken into account when logical switches are mapped to a digital input port. One is that switching events are, by nature, random (that is, they can occur at any moment). The other is that the number of events is not fixed for each test case, instead, they can increase or decrease dynamically. To handle these conditions, two important changes were made to the original simulator code: • Switching events were converted from a dynamically allocated linked list, to a statically allocated stack of events. This change is very important, since allocating memory space for new events in the linked list method proved to be very slow: about 10 \xs (minimum) per event in a Pentium Pro 200. • Switching events can be added dynamically to the stack. Therefore, these random events can be conveniently handled by the real time simulator. 2 Reading and Processing External Switching Events Reading external switching events in the real time simulator is quite simple. Only one instruction is required: "din = inp (BinlnPort);" were BinlnPort is specified in the configuration file rtns.cnf using the keyword "din:". Since in this implementation of the simulator, an analog output board with eight built in digital 21 inputs was used (AT-AO-10 from National Instruments), a maximum of eight switches can be set and used. One of these switches is being used for another function though. Since in the real time simulator timing is critical, it is not possible to run cases in real time and at the same time make calls to the operating system in order to check the computer standard I/O devices (serial ports, keyboard, etc.) . This implies that once the simulator is started, an external signal has to be used in order to stop the simulation and go back to the operating system. This signal is one out of the eight available digital inputs. Once the digital inputs are read, a "debounce state machine" is run in order to get rid of spurious or noisy inputs. This is very important, especially if the digital inputs are connected to mechanical or electromechanical contacts. Figure 8 shows how a "bouncing" digital input looks like. After the state is changed (in this case, from logical zero to logical one), the signal does not stabilize itself into logical one until some time has passed. This time is usually in the range of 5 to 50 ms, with multiple transitions in between. Since the real time simulator is operating in a 50 us or less time frame, these multiple transitions could be interpreted as multiple switching operations. A debounce algorithm was implemented to prevent this situation. i State changes 5 to 50 ms Figure 8. Transitions in the digital inputs are not instantaneous 22 Figure 9 shows the diagram for the implemented debounce state machine. As it can be seen in the diagram, the code of the state machine does not lock up the computer while waiting for the debounce time to pass. Instead, it executes each state only once per simulation time step. Figure 9. The state machine used to debounce digital inputs 3 Analog Outputs It is through analog outputs that the results of the simulation are put into the real world. This information, after properly conditioned using power amplifiers, is fed to the relay under test. By nature, all the simulation results of the real time simulator are digital. These digital values are converted using digital to analog converters. There are numerous commercially available off-the-shelf boards that can perform this function. For this implementation, a DAC board from National Instruments was used: the AT-AO-10. This board provides up to ten digital to analog converters, and eight digital inputs. The analog outputs have a resolution 23 of 12 bits (11 bits + sign), with a range of ±10V. One of the main advantages of using this board is that each port can be set with a single I/O operation. This is very important since the drivers provided by the manufacturer are quite slow (about 600 us to set each individual output!), and completely inadequate for this implementation of the simulator. Although using direct I/O access to set the analog outputs is relatively fast, it still takes an important amount of time. For instance, it was found experimentally that each I/O instruction takes between 1.7 to 2.2 us, depending on the computer being used. Therefore, for very fast computers, as in the case of a Pentium II 400, the specified number of outputs for a particular test case has a big impact on the simulation time step. For example, for a particular test case in which three output currents and three output voltages are required, the simulation time is about 25 us. The total number of I/O operations is seven (six for the analog outputs, one for digital input), for a total of about 12 us. This represents almost 50% of the simulation time! Unfortunately, commercially available analog output boards have to fulfill the standard computer expansion bus specifications, which have set the timing for I/O accesses for the above indicated values since the early members of the X 8 6 family of computers. It should be expected, as computers become even faster, that new I/O standards will be created, and faster digital to analog boards will be developed. 4 Preconditioning the Analog Outputs: Current and Voltage Transformers. Although the real time simulator can feed the relay under test with directly scaled voltages and currents, it is usually desired to simulate, as closely as 24 possible, the signals the relay is going to see when installed in the field. Normally, the relay gets the required currents and voltages from the power system through instrument transformers. These transformers have an important effect on the signals provided to the relay. Therefore they have to be accurately implemented in the real time simulator. 4.1 Current Transformers The equivalent circuit used to simulate current transformers (CT) is the one proposed by Marti, Linares, and Dommel in [16] as well as Lucas and McLaren in [17], shown in figure 10. It consists of a core loss resistance Rf, a magnetizing branch in the form of a non-linear inductance L, a secondary side branch composed of Rl and LI, and the burden branch composed of Lb and Rb. The non-linear inductance of the equivalent circuit can be represented as a piece-wise inductance as shown in figure 11. Up to three segments are suggested in [16] to define the corresponding inductances as well as the range of currents for which those inductances have to be applied. Figure 12 shows the discrete time representation of the circuit of figure 10. Components Rl and LI as well as Lb and Rl LI Figure 10. Equivalent circuit of a current transformer 25 Rb are collapsed into two sets of discrete time elements: gl and hi for Rl and LI; gb and hb for Lb and Rb. Since the trapezoidal rule of integration can have difficulties in the solution of circuits with discontinuities [18], the following rule is proposed here: dx_fr s 1.6966 • x(t) - 2.6598 • x(t - At) +1.2298 • x(t - 2At) - 0.2666 • x(t - 3 At) dt At Flux 1 1 1 2 Current Figure 11. Piece-wise representation of a nonlinear inductance V1 "(X) S f 5 h Q J 3 X V2 T Figure 12. Discrete time representation of the circuit in figure 10 26 Although this rule has more terms to evaluate than the trapezoidal rule, it has the advantage that it is immune to the effect of inductance zone changes for non-linear inductors, greatly reducing the amount of computations required. Using this rule, the formulas for the representation of the elements in the discrete time circuit of figure 12 are listed in table 4. Some of the formulas in the current transformer model are evaluated only once, while others are evaluated at run time, as indicated in the table. The circuit of figure 12 can then be solved using nodal analysis. The resulting equations are: a) Evaluated only once gaa = gl + g + gf gbb = gl + gb kd = gaa • gbb - gl • gl gaa kaa = kbb kd gbb kd , , gl kab = — kd b) Evaluated at run time h = L - h - h l h b = hi - hb v l = ha • kbb + hb • kab v2 = ha • kab + hb • kaa 27 It should be noticed that, since g is obtained from a piece-wise inductance, it consists of an array of values. This implies that constants kaa, kbb, and kab are arrays as well, and their values actually depend in which zone of operation the piece-wise inductance is located. ForL For Rl and LI For Lb and Rb Evaluated only once En At " k 0 L n 0.2666 gl = At AtRl + k n L l gb = At AtRb + k n Lb kl = k n L l •1.2298 K = 2.6598 AtRl + k n L l k a , =k l -k a k b l - kl • k b k c l = k l - k c kb = k 0 L b AtRb + k n Lb k a b = kb • k a k b b = kb • k b k c b = kb • k c Evaluated Every time step h = k a i L ( t -3At) + k b i L ( t -2At) + k c i L ( t - A t ) hl = k a l i L 1 (t-3At) + k b l i L 1 ( t -2At) + k c l i L 1 ( t -At) hb = k a b i L b (t-3At) + k b b i L b ( t -2At) + k c b i L b ( t -At ) Table 4. Formulas used to calculate the values of the circuit in figure 12 In figure 13, the result of this implementation of the model is compared against the same circuit simulated using Microtran (the UBC version of the EMTP). In both cases, the secondary current is plotted. The results of both simulations are identical, so it appears to be only one plot in the figure. The Microtran input data file used to simulate the CT equivalent circuit is included in the appendices. 28 100 0.06 Time s 0.12 Figure 13. Resulting output current obtained using the implemented model and the same circuit simulated using Microtran 29 4.2 Coupl ing-Capaci tor Voltage Transformers The model used to simulate coupling-capacitor voltage transformers is the one suggested by Hou and Roberts in [19]. It consists of coupling capacitors, compensating reactor, step down transformer, and a ferroresonance suppression circuit (figure 14). line voltage C1 step-down transformer ferroresonance supresion circuit C 2 compensating reactor relay voltage Figure 14. Coupling-capacitor voltage transformer (CCVT) circuit Hou and Roberts [19] replaced the compensating reactor, step-down transformer, and ferrorresonance suppression circuit in figure 14 with their equivalent circuit. The resulting circuit is shown in figure 15. It consists of the following components: Vm: intermediate voltage level Ce: equivalent CCVT capacitance (C1+C2) Cc: stray capacitance of the compensating reactor Lc: inductance of the compensating reactor Rc: copper resistance of the compensating reactor Cp: stray capacitance of the transformer Lp: leakage inductance of the transformer Rp: copper resistance of the transformer Cf: capacitance of the suppressing circuit Lf: inductance of the suppressing circuit Rf: loading resistance of the suppressing circuit mLf: middle tap of the suppressing inductor 30 Figure 15. Equivalent circuit for the CCVT This equivalent circuit has been shown to be appropriate to simulate the CCVT for a wide bandwidth of about 10 kHz [19]. On the other hand, due to the high number of nodes and lumped elements, the circuit is too complex to be economically simulated in real-time. In order to achieve a fast real-time model, some of the bandwidth of the circuit can be sacrificed in favor of speed. Particularly the components related to the step-down transformer (Lp, Rp, Cp) are considerably smaller than the other components of the equivalent circuit. For instance, if Cp is neglected, and the values of Rp and Lp are added to Rc and Lc, three lumped elements are saved, as well as a node. The ferroresonance suppression circuit can also be simplified. If inductances Lf and Lfm are represented as an air core inductance instead of an autotransformer, one additional node and one additional lumped element are saved. Kezunovic and Nilsson in [20] are not much in favor of this simplification 31 since the equivalent circuit of the ferrorresonance suppression circuit has a quality factor Q considerably smaller than the real circuit. This condition can be easily solved by forcing the circuit to have a larger Q just by multiplying Cf and dividing Lf by a fixed factor. The simplified version of the circuit is shown in figure 16. Cc Ce Vi Lc+Lp Cf J - 1 Lf R l Rf Figure 16. Simplified version of the equivalent circuit for the CCVT The discrete time version of the circuit in figure 17 is presented in figure 18. Notice that the components Rc+Rp and Lc+Lp are collapsed into one single discrete element represented by g3 and h3. In the same way, Cf, Lf and Rf are also collapsed into one single discrete element represented by gt and ht. 32 h2 e Figure 17. Discrete time representation of the circuit in figure 16 The formulas for the discrete time representation of the circuit in figure 17 were derived using the trapezoidal rule of integration. Some of the formulas are evaluated only once, while others are evaluated at run time (table 5). The circuit can be solved for voltages V1 and V2 using the formulas: Evaluated only once: gaa = g l + g2 + g3 gbb = g2 + g3 + gt gab = g2 + g3 kd = (gaa * gbb) - gab 2 kaa = Z % kbb = k a b ^ Evaluated every time step: ha = h 2 - h l - h 3 + g l * V i hb = h 3 - h 2 + ht V, =ha*kbb + hb*kab 33 V 2 = hb * kaa + ha * kab Where V2 is the voltage we are interested in. For the capacitance Ce For the capacitance Cc For the components Rc+Rp and Lc+Lp For the ferroresonance suppression circuit: Evaluated only once gi =' 2Ce At 2Cc At At 6 3 2Lc + RcAt 2 L c - R c A t k = 1 2Lc + RcAt k 2 =(k, + l ) g 3 R L f -2 L f At g Lf R Lf At R c f " 2 C f g C f = R R pf Cf R C f R L f R C f + R L f 1 ^ ' R P f + R f k 3 = R P f g . k 4 = 1 - R f g , Evaluated every time step h2=2g2(V2-Vl)-h2 h3 = kfy + k2(v;-v2) Va = k 4 V 2 + R f h t h L = 2 g L f V a + h L h c = 2 gc f v a - h 'c h t = ( h c - h L ) k 3 Table 5. Formulas used to calculate the values of the circuit in figure 18 Figure 18 compares the transfer function of the simplified circuit in figure 16 against the detailed circuit of figure 15 as reported by Hou and Roberts in [19]. The results show that the simplified circuit is accurate enough for the ranges of frequencies of 10 to 6000 Hz. 34 35 IV. Accurate Real Time Achieving real time with the real time simulator is done by means of using an accurate time reference. Since the real time relay tester implemented here is intended to work in the range of tens of (is, a time reference with a resolution of 1 LIS or better is desired. Another important requirement of the time reference is that it has to be adjustable, in order to achieve an appropriate range of possible time steps. In a PC computer, whose microprocessor belongs to the x86 family, the time reference could be obtained from one of the internal counters, an external source through an interrupt, or in some processors, such as the Pentium family of Intel CPUs, by using the CPU time stamp counter. 1 Using an Internal Counter as Time Reference A convenient time reference source for personal computers based on the x86 microprocessors can be obtained from one of its three available counters. Since the first IBM PC based in the 8088 microprocessor appeared, and up to today's high performance Pentium based PCs, these counters have been available and basically unchanged. These three counters are bonded together in a single counter timer chip (CTC). This chip used to be the Intel 8253 for the earlier PCs, but was later replaced by an improved and backward compatible CTC, the Intel 8254. Figure 19 shows a diagram of the CTC. The input frequency for each counter is 1.193181667 MHz; a value inherited from the first IBM PC that operates with a crystal frequency of approximately 4.77 MHz, that is, 1.193 MHz * 4. As 36 shown in figure 19, counter 0 is normally used to keep the operating system tick clock. To achieve this task efficiently, the output of counter 0 is connected to external interrupt 0 and mapped as vector interrupt 8. In computers running DOS, this counter is set to produce a tick clock period of approximately 55 ms. Other operating systems, such as Windows and Linux, set this counter to a different time tick. Counter 1 is used to refresh the dynamic memory. Since memory refreshing is a task that has to be performed continuously, this counter cannot be used to perform general timing tasks. Finally, counter 2 is used as a tone generator for the computer speaker. The output of this counter is ANDed to an enable signal before it is fed to the speaker driver. Therefore it is possible to inhibit the speaker output and use counter 2 for general timing applications. 1.19318166 MHz 8254 CTC Counter 0 Counter 1 Counter 2 Counter 2 Gate Speaker Enable S y s t e m Tick . IRQ o > Int 8 Memory — • Refresh Logic Figure 19. Block diagram of the CTC present in x86 computers 1.1 The Real Time Simulator and the C T C A version of the real time simulator for relay testing was implemented using the CTC counter 0 as reference timer. This timer, as well as timers 1 and 2, has a resolution of 16 bits, that is, one in 65536 multiples of the input frequency period. 37 Since the timer is driven by a reference frequency of 1.193181667 MHz, the achievable resolution of this timer is: 5 = — = 0.8380953442859 /is 1.193181667MHz This implies that the actual simulation time step must be an integer value of 5. To achieve the maximum possible performance, the computer must be operated in 32 bits mode. For current x86 computer architectures, this implies the use of a 32 bit compiler. Since the output of counter 0 is connected to the microprocessor interrupt 0, this imposes an important limitation on the possible operating system to be used. For instance, Win32 operating systems (which include Microsoft Windows 95/98/NT) are very restrictive regarding the use and configuration of counter 0, I/O ports, and interrupts. Fortunately there are other commercially available 32 bits operating systems that offer more flexibility for these types of requirements. One such operating system is TNT Embedded ToolSuite from Phar Lap Software Inc. TNT is a 32 bit real time operating system. It supports most commercially available C compilers, such as Microsoft Visual C++, Borland C/C++, and Watcom C++. It provides libraries to access I/O ports and to set and use interrupts. 1.2 Configuring and using C T C Counter 0 Under Phar Lap T N T Counter 0 of CTC is configured by writing and reading from the appropriate I/O ports. There are four I/O ports available to configure the CTC. One of them is the control word [21] while the other three are used to set and read the values of 38 each individual counter. In x86 based computers, these I/O ports are mapped as 8 bit ports as follows: Register I/O port Counter 0 0x40 Counter 1 0x41 Counter 2 0x42 Control Word Register 0x43 The control word register is used to set the particular mode of operation of each counter. The format of this register is: D 7 D 6 D 5 D 4 D 3 D 2 D i D o SC1 SCO RW1 RW0 M2 M1 M0 BCD Bits 7 and 6 of the control word register are used to select the particular counter to be configured. In order to select counter 0, SC1 and SCO have to be set to 0. Bits 5 and 4 indicate the mode in which the counter is going to accept or report data. For 16 bits operation, RW1 and RW0 have to be set to 1. Bits 3 to 1 set the mode of the counter. The CTC supports up to six modes of operation. One of them, mode 2, is designed to operate as Real Time Clock interrupt. In this mode of operation the counter works as a divide-by-N counter. When the count is completed, the counter generates a low pulse, it reloads the set value for the counter, and the process is repeated indefinitely. In order to set the counter to mode 2, the values of M2 and M0 have to be set to 0, while M1 has to be set to 1. Finally, bit 0 defines the numeric format in which the counter is going to be loaded. If BCD is set to 0, the counter counts in binary mode, and a maximum resolution of 16 bits can be achieved, that is 1 in 65536 counts can be set. If BCD is set to 1, the counter counts in decimal mode, and only a load value between 1 and 10000 39 can be set. For programming convenience, the binary mode is preferred, then BCD is set to 0. Once the mode of operation of counter 0 is selected, the actual value of the counter can be set. This value depends on the desired simulation time step. To calculate the value to be set in the counter the following formula is used: *= * 0.8380953442859 jus where the time step At is given in LIS. Since N is an integer, the result is rounded off. This could produce some error in the resulting simulation, if the value of At is not an integer multiplier of 8. This error is not very high, though. For example, if the required time step is about 24.65 LIS, the expected error would be 1.4%. Below is listed the C code used in the real time simulator to set counter 0 as the time reference. Function outp is provided with the Phar Lap TNT libraries. / * S e t u p t h e ' h a r d w a r e ' d e l t a t * / t i m e r _ v a l u e = ( i n t ) ( d e l t a T * C L K I N ) ; t i m e r _ l o w = ( u n s i g n e d c h a r ) t i m e r _ v a l u e % 0 x l 0 0 ; t i m e r _ h i g h = ( u n s i g n e d c h a r ) t i m e r _ v a l u e / 0 x l 0 0 ; / * S e t c o m p u t e r t i m e r t o d e l t a T * / o u t p ( T I M E R 0 , t i m e r _ l o w ) ; / * L o a d h i g h a n d l o w c o u n t s * / o u t p ( T I M E R 0 , t i m e r h i g h ) ; Once the timer is set, the computer has an interrupt source with the desired time step. Now it is necessary to tell Phar Lap TNT which routine (handler) is going to run every time the interruption is generated. Phar Lap provides two functions to achieve this task: • EtsSavelnterruptHandler, which saves the current interrupt handler pointer. This has to be done, since the interrupt must be restored to its original pointer once the program finishes. 40 • EtsSetlnterruptHandler, which sets a new interrupt handler. The code below shows the interrupt handler for the real time simulator under Phar Lap TNT. v o i d S T K C A L L T i m e r l n t H a n d l e r ( E T S I N T R E G S * p R e g s ) { S i m u l a t i o n ( ) ; s t e p + + ; / * D o n e p r o c e s s i n g t h e t i m e r i n t e r r u p t . I s s u e a n E O I t o t h e 8 2 5 9 . * / o u t p ( P I C 1 _ B A S E + P I C _ C M D , P I C _ N S E O I ) ; r e t u r n ; } 41 1.3 Measur ing the Execution Time Using the C T C Using one of the timers on the CTC, it is possible to measure how much time it would take to run a specific test case. This is important in the real time simulator because the real time execution of a particular case has to be guaranteed. To perform this task, either counter 0 or 2 can be used. The code below shows the routines used to measure the run time in the real time simulator. v o i d t i m e r _ s t a r t ( v o i d ) { u n s i g n e d c h a r d a t a _ i n ; _ d i s a b l e ( ) ; / * U s e s T I M E R 2 t o c o u n t t h e e l a p s e d t i m e * / d a t a _ i n = i n p ( P C _ C S ) ; / ^ D i s a b l e s T I M E R 2 * / d a t a _ i n &= O x f e ; o u t p ( P C _ C S , d a t a _ i n ) ; o u t p ( C 8 2 5 4 , T 2 0 S ) ; / * C o n f i g u r e s T I M E R 2 a s " o n e - s h o t " * / o u t p ( T I M E R 2 , 0 ) ; / * L o a d h i g h a n d l o w c o u n t s * / o u t p ( T I M E R 2 , 0 ) ; d a t a _ i n = i n p ( P C _ C S ) ; / * E n a b l e T I M E R 2 * / d a t a _ i n |= 1; o u t p ( P C _ C S , d a t a _ i n ) ; / * H e r e s t a r t s c o u n t i n g ! ! ! * / } u n s i g n e d i n t t i m e r _ e n d ( v o i d ) { u n s i g n e d c h a r d a t a _ i n ; u n s i g n e d c h a r c o u n t _ h i g h , c o u n t _ l o w ; o u t p ( C 8 2 5 4 , T 2 L ) ; / * L a t c h T I M E R 2 * / c o u n t _ l o w = i n p ( T I M E R 2 ) ; / * R e a d T I M E R 2 * / c o u n t _ h i g h = i n p ( T I M E R 2 ) ; d a t a _ i n = i n p ( P C _ C S ) ; / * D i s a b l e s T I M E R 2 * / d a t a _ i n &= O x f e ; o u t p ( P C _ C S , d a t a _ i n ) ; o u t p ( C 8 2 5 4 , T 2 S W ) ; / * R e c o n f i g u r e s T I M E R 2 o f 8 2 5 4 t o i t s d e f a u l t * / _ e n a b l e () ; r e t u r n ( 0 x 1 0 0 0 0 - ( ( c o u n t _ h i g h * 0 x l 0 0 ) + c o u n t _ l o w ) ) ; In this implementation, counter 2 is used. The first routine, timer_start, initializes and starts the counter. This routine runs with interrupts disabled. Since Phar Lap TNT uses counter 2 for some internal timing tasks, the counter may not 42 report the correct time unless interrupts are disabled. This introduces some error because latency time of interrupts as well as the load of the operating system are not taken into account. On the other hand, for fast CPUs, such as Pentium Pro 200 and up, those times are very small, and their effect in the final result is not relevant. Since the resolution of the counter is 0.8381 us, the maximum measurable time using this technique is 54.9 ms. The second routine, called timer_end, reports the elapsed time, resets counter 2 to its default mode of operation, and enables interrupts. Since the counters in the CTC are down counters, the final result is obtained by subtracting 65536 from the obtained value. The final result, when multiplied by 0.8381 us, yields the execution time of a particular case in microseconds. The real time simulator can save this values into a Matlab compatible file, that can be plotted later. Figure 2 shows the execution time plot for the case listed in the appendix, run in a Pentium II 400 computer. Observe that the execution time could be different from time step to time step. For this particular case, the time step of the simulation must be set to a value larger than about 22.5 us, which is the maximum execution time per time step shown in figure 20. 43 1.8-1.7-1.6--| c l I I 1 1 1 1 50 100 150 200 250 300 Time Step Figure 20. Execution times per time step found using the CTC 2 Using an External Interrupt as the Source for the Time Reference The method for using an external interrupt to obtain the time reference for the real time simulator is identical to that used with counter 0 and interrupt 0. A suitable device, capable of generating the required interrupt pace, could be connected to an available interrupt. In this case, the method to set the interrupt timing would be different, as well as the I/O ports assigned for such operation. For example, one of the I/O boards manufactured by National Instruments and used in the real time simulator, the AT-AO-10 [15], provides three counters in a single 8253 CTC, each one clocked at a frequency of 1 MHz. Two of these counters, counters 0 and 1, are connected to external interrupts. Since the I/O ports 44 addresses, as well as the interrupt request number for that particular board depend on user selection, that information must be known beforehand. Also the input frequency for the particular board or device being used must be known in order to calculate the appropriate constants needed to set the hardware time step. By using this approach, better time step resolutions than those provided by the internal counter 0 can be achieved. Notice nevertheless, that the resolution provided by the counters of the AT-AO-10 board (1.0 LIS) is not as good as the one provided by the PC's internal counter 0 (0.8381 us). 3 Using the Time Stamp Counter Starting with the Pentium family of microprocessors, Intel added an instruction for performance monitoring. That instruction, called RDTSC (Read Time Stamp Counter), reports the number of clock cycles the CPU has been running since start up or reset [14]. Although not recommended for general profiling, it can be conveniently applied to achieve accurate timing with the simulator. Before using this instruction to implement real time though, two factors have to be taken into account. First, the instruction RDTSC is not available in most compilers or assemblers, so it has to be defined or used through its opcodes. Second, the clock frequency of the CPU has to be known. The first factor can be easily solved by including in-line assembly in the corresponding C program. In Borland C++, the implementation of this instruction looks like: 45 { db OxOF db 0x31 mov t i m e low, eax mov t i m e h i g h , edx } where OxOF and 0x31 are the opcodes of RDTSC. The instruction returns a 64-bit number in the extended registers eax and edx. If the CPU clock frequency is known, the time the computer has been running since power up, or since a hardware reset, can be calculated using: # cycles CPU _ Frequency If the CPU clock frequency is given in MHz, the resulting time is in microseconds. The second factor, the CPU clock frequency, can be either input as a parameter or found using an appropriate algorithm. This task is very easy to achieve if a second source of timing is available. Fortunately, one good source of timing is already implemented in the real time simulator using Phar Lap TNT: counter 2. The idea now is to measure the execution time of a given piece of code, both using counter 2 and the RDTCS instruction. Since both times have to be approximately equal, the CPU clock frequency can be calculated: 46 ( c l i d b O x O F d b 0 x 3 1 m o v t i m e _ l o w , e a x m o v t i m e _ h i g h , e d x } t i m e r _ s t a r t ( ) ; f o r ( i = 0 ; K 2 0 0 0 0 ; i++) i n p ( 0 x 6 1 ) ; t i m e = t i m e r _ e n d ( ) ; a s m { d b O x O F d b 0 x 3 1 s u b e a x , t i m e _ l o w s u b e d x , t i m e _ h i g h d i v t i m e m o v c y c l e s , e a x s t i } c l o c k = c y c l e s * C L K I N ; / * C L K I N = 1 . 1 9 3 M H z * / Notice that the routine is measuring how much time it will take to perform 20000 input operations to port 0x61. Since I/O operations are very slow (in the order of 1 to 2 LIS) and take more or less the same time for all the processors of the x86 family, the loop should take between 20 ms to 40 ms to execute. Those times are small enough not to overflow counter 2, whose maximum counting capability is about 55 ms. Once the CPU clock frequency is known, a time polling scheme can be implemented to achieve the desired physical time step. First, it is necessary to calculate how many CPU cycles are required to implement the time step. This can be done using the formula: # cycles = At • CPU_ Frequency Where #cycles is an integer. The polling scheme is implemented by constantly reading the time stamp counter and comparing the elapsed time with the number of CPU cycles needed to achieve the desired time step. The code below shows 47 the implementation of the polling scheme in one of the versions of the real time simulator. w h i l e ( g e t _ o u t = = 6 ) { S i m u l a t i o n ( ) ; step++; do { /*Waste t h e remanding t i m e i n t h i s d e l t a T * / asm { db OxOF db 0x31 mov EndL, eax } } w h i l e ( ( E n d L - S t a r t L ) < = c y c l e s ) ; S t a r t L = E n d L ; } Since the simulation of a given case must take less time than the required time step, some time has to be wasted. Once that time is consumed, the cycle is repeated until the simulation is stopped. 48 3.1 Measuring the Execution Time Using the RDTSC Instruction The RDTSC instruction can be used to measure the execution time of a given test case with a very high resolution. Notice that the resolution of the time stamp counter depends on the CPU clock. For instance, for a 400 MHz Intel Pentium II computer, the resolution of the counter is 2.5 ns; considerably better than the 0.8381 us of internal counter 2. The process of measuring time using the RDTSC is quite simple when the CPU clock is known. The code below shows how this was implemented in the real time simulator. a s m { c l i } f o r ( s t e p = 0 ; s t e p < M A X B U F F ; s t e p + + ) { a s m { d b O x O F d b 0 x 3 1 m o v S t a r t L , e a x } S i m u l a t i o n ( ) ; a s m { d b O x O F d b 0 x 3 1 m o v E n d L , e a x } t i m e s _ b u f f e r [ s t e p ] = ( E n d L - S t a r t L ) / C P U _ c l o c k ; ) a s m ( s t i ) Again, the code is run with interrupts disabled, and the resulting times per simulation step are stored in an array of double precision numbers. This array can be saved and plotted using Matlab. Figure 21 shows the execution time plot for a particular simulation case when it was run in a Pentium II 400. The results are similar to those presented in figure 20, with the exception of a higher resolution in the time (vertical) axis. 49 2.4-2.3-2.2-1.8-1.7-1.6-H c l I I 1 1 1 1 50 100 150 200 250 300 Time Step Figure 21. Execution times per time step found using the RDTSC instruction 4 Comparison of the Different Methods Used to Generate the Time Reference The described methods used to achieve accurate real time have advantages and disadvantages. The main advantage of using the internal counters is that they are ever present; that is, they are part of the computer design, and likely to be present in new computer models for many years to come. Their main disadvantage is their limited resolution of 0.8381 us, which limits somewhat the allowable time steps in which the error is very small. Jitter is another important disadvantage associated with interrupts, especially when the times involved are 50 very small, as is the case in this implementation of OVNI. Jitter is a condition that appears due to small differences between the service time of two consecutive interrupts [1]. Jitter must not be confused with latency, which is the delay between the time in which the interruption is generated and the time it is serviced by the CPU . In fact, if latency were constant, there would be no jitter. In this implementation of the real time simulator for relay testing, when using counter 0 as time reference, jitter can be up to 0.5 [is. Jitter can manifest itself as a high frequency in the analog outputs but it is not likely to produce any problems in the relay under test. Since jitter appears every time the interrupts are used, the problem is present when an external time reference and an interrupt are used. The main advantage of using an external time reference is that it allows the implementation of multiprocessor systems sharing the same external time reference. Also, if an external time reference with a better resolution than 0.8131 |j,s is available, it will be advantageous to use it. There are more advantages than disadvantages to using the CPU time stamp counter as implemented here rather than an external clock. The main advantage of using the CPU time stamp counter is its very high resolution, which can be as fine as 2 ns in a Pentium III 500 CPU . Since the use of the time stamp counter does not involve interrupts, jitter is practically eliminated. This independence also makes the code very easy to port to Win32 and DOS 32-bit-DPMI environments, in which the use of the CTC could be restricted and the use of 32 bit interrupt handlers is not a straight forward task. The main disadvantage is that it may not be present in some processors. It is not present, for example, in 51 some Cyrix high performance CPUs, but It is available in all AMD K6 CPUs as well as in all Intel Pentium models, and it is available even in some late 486 CPUs models [14]. 52 V. The Monitoring Computer As mentioned in the previous chapters, the monitoring computer allows the user of the real time simulator to control and monitor the simulation computer. The following are the functions the monitoring computer is able to provide: • Creation of test cases. • Simulation computer initialization and shutdown. • Test case downloading. • On-line triggering of faults and other switching events. • Simulation computer monitoring and data gathering. • Data analysis. 1 Hardware requirements for the Monitoring Computer In addition to all the required hardware to properly run Windows 95/98/NT, the monitoring computer should be able to interface with the simulation computer. This interface is required for two main tasks: to interact with the TNT Embedded operating system from Phar Lap Inc. running in the simulation computer, and to interact with the core of the real time simulator. The communication with Phar Lap is required in order to provide access to local files in the monitoring computer, such as test cases and configuration files from the simulation computer. Phar Lap provides with their operating system a communication cable and a driver program that can be run under Windows: runemb.exe. This cable, once attached to the parallel ports of both computers, creates the required file sharing environment. By using runemb.exe, test cases can be directly started from the 53 monitoring computer. Once the simulation program is running, it restrains itself from using Pharlap standard I/O routines since they are very slow. A more basic way of communication is then established with the monitoring computer: direct access to I/O ports and to the analog outputs. In order to access the analog outputs and digital inputs of the simulation computer, the monitoring computer requires the appropriate data acquisition hardware. The selected hardware is a multi I/O board from National Instruments, the AT-MIO-16. This board provides 16 analog inputs with a resolution of 12 bits (11 bits + sign), eight digital I/O pins, and two analog outputs with a resolution of 12 bits (11 bits + sign). The drivers provided by National Instruments are used to access the AT-MIO-16. This board is connected to the board installed in the simulation computer, the AT-AO-10, as follows: AT-MIO-16 AT-AO-10 Digital out 0 Digital in 0 Digital out 7 Digital in 7 Analog Input 0 Analog Output 0 Analog Input 9 Analog Output 9 Since analog inputs 10 to 15 and the two analog outputs in the AT-MIO-16 are not used, they are left unconnected. Digital outputs 0 to 6 are used as external switches that can be used to simulate faults or any other kind of switching operations in the simulation computer. Digital output 7 is used to synchronize the 54 execution of the simulation program, or to stop a simulation that is already running. Analog input 9 is being used to indicate the exact moment at which a switching operation occurs in the simulation computer. This signal is generated by the simulation computer throughout analog output 9. The simulation computer keeps this signal either at +5V or -5V, until a switching operation is executed. At that particular time step, the simulation computer inverts the polarity of analog output 9. By using this technique, the monitoring computer can use the voltage generated with analog output 9 as a trigger event to store waveforms or to perform any other required actions. 2 The Monitoring Program The monitoring program was created using LabWindows/CVI from National Instruments, and runs under Windows 95/98/NT. This development tool offers important advantages for the creation of the monitoring program: • A graphical user interface development tool that accelerates and simplifies the creation and programming of standard Windows graphical programs. • Compatible ANSI C software. Since the core software of the simulation computer was developed using also ANSI C, the programming language was kept uniform in the entire real time simulator. • Direct support for National Instruments data acquisition boards, in particular for the AT-MIO-16 analog to digital converter, used in the monitoring computer. Figure 22 shows a snapshot of the user interface program. The program can perform the following monitoring functions: 55 Communication with the simulation computer using the program runemb.exe provided with the ETS TNT real time operating system form Pharlap Inc. Generation of switching events. Capture and display of the output waveforms generated by the simulation computer. Only the inputs selected by the user are currently captured and displayed. Storage and printing of the captured waveforms. By using the signal provided by the simulation computer through analog output 9, the monitoring computer can freeze the waveforms captured from the other analog ports in order to display the transient waveform at the exact moment of commutation (figure 23). 56 E 3 Real Time Simulator for Relay Testinii i File Simulation 0.0E+0 -9.9E-3 19.9E-3 29.SE-3-; ,.39.8E-3 4S.8E-3 - 5&8E-3," 83;?£-'3- 73.7E-3 " S3 BE-3 - 93.6E-3| $5.00000 Upper Limit (V) 17 Channel 1 R Channel 2 Channel 3 f~ Channel 4 P Channel 5 I - Channel G f~ Channel 7 l~* Channel 8 r~ Channel 3 fl? Channel 10 Lower Limit (V) P0 P1 P2 P3 P4 P5 PG Off ™ * On „ , „ , Required deltaT -25.14 juS Read Mode ' E3 Consecutive Actual deltaT _25jU _J uS On H Latest Error in deltaT X iO.OOOO Number of Scans Scan Rate (Hz) ^j25iT""j ^J25G0M' '^" j p~2,~9 Execution time 21.79 £Mn.0M.§JF.[nfl] uS Figure 22. A snapshot of the monitoring program T ' ' 1 1 1 ' / V I / ' V I / Y ' V / Y V i : / / \ i / A \ / A i / A: \ \ J t ^ | K \ r f | \ l / \ \ f J l \ / / \ l.| / 1 1 / • / \ i / /* 1 \ / l 'i ly J i v I i v / • \ \f «—r-Analog output 9 i 1 1 1 0 0.02 0.04 0.06 Time 0.08 0.1 Figure 23. Analog output 9 is used to signal switching events 57 VI. Conclusions and Recommendations The implementation of the real time simulator for relay testing was successfully completed using only off-the-shelf equipment. The resulting simulator, built around standard, readily available computers and operating systems, has shown a performance that surpasses even multiprocessor computers. The fact that personal computers become faster year after year, makes the development of this real time simulator for relay testing a very promising one, both in performance and price. For example, the first working tests of the simulator were performed using a Pentium Pro 200 MHz as core computer, with a simulation time step of about 49 u.s per step. After some time, a Pentium II 400 MHz computer was made available. The process of updating the simulator to use this new computer took less than an hour, and the same test case now runs in about 23 (is per step. An improvement of more than 100%! By the time this report had been written, a Pentium III 500 MHz was already commercially available. Currently, it is in the digital to analog converters where the bottle neck is. The converter used in the simulator, the AT-AO-10 from National Instruments is a EISA bus expansion card. By design, EISA expansion boards can perform an I/O operation in about 2 p.s. This can be improved either by using a digital to analog converter board for a different bus specification, such as PCI, in which these times can be as less as 1/3 the time required by EISA; or by using digital to analog converters in which the ports are mapped as memory, since EISA memory access takes only 1 (is. 58 Since the simulator is now so fast, more detailed component models can be represented with higher detail while staying within the 50 LIS time step. In particular, models for full frequency dependent transmission lines, coupled inductances, and more detailed models for coupling-capacitor voltage transformers can be implemented. 59 VII. References [I] Heidenstrom, K (No date). FAQ / Application notes: Timing on the PC family under DOS. Available ftp://ftp.simtel.net/pub/simtelnet/msdos/info/pctim003.zip [2] M. G. Adamiak and S. G. Saldanha, "Digital Simulators Expedite Relay Performance Evaluation" IEEE Computer Applications in Power, pp. 18-22, April 1996. [3] A. G. Phadke and J . S. Thorp, "Computer Relaying for Power Systems," John Wiley & Sons, New York, 1993, pp.1-8. [4] C. Russell, "The Art and Science of Protective Relays," John Wiley & Sons, New York, 1956, pp.1-14, 70-84. [5] The Electric Council, "Power system protection," Macdonald & Co. (Publishers) Ltd, London, 1969, Vol. 1, pp. 202-205. [6] J . R. Marti and L. R. Linares, "Real-Time EMTP-Based Transients Simulation", IEEE PES summer Meeting, Paper No. 93SM 511-6-PWRS, Vancouver, B.C., July 1993 [7] G E C Alsthom T&D Protection & Control Limited, "Type LFZR High-Speed Numerical Distance Relays", Publication R-4117B, England, 1996. [8] IEEE Working Group F-8 of Relay Input Sources, "Digital Simulator Performance Requirements for Relay Testing", IEEE Transactions on Power Delivery, Vol. 13, No. 1,pp 78-84, January 1998. [9] M. Agrasar, J . R. Hernandez, F. Uriondo, J . Amategui, J . M. Gallastegui, and J . L. Martinez "Optimized Relay Testing Systems", IEEE Computer Applications in Power, Vol. 10, No. 4, October 1997, pp. 55-59. [10] M. Kezunovic, J . Domaszewicz, V. Skendzic, M. Aganagic, J . K. Bladow, S. M. McKenna and D. M. Hamai, "Design, Implementation and Validation of Real-Time Digital Simulator for Protection Relay Testing," IEEE Transactions on Power Delivery, Vol. 11, No. 1, January 1996, pp. 158-164. [II] J . White, "Advanced Relay Testing," IEE Colloquium on Instrumentation in the Electrical Supply Industry, London, 1993, pp. 12/1-12/6 60 [12] Linares, Luis, "A real Time Simulator for Power Electric Networks", Thesis Report, The University of British Columbia, 1993. [13] Johns, A. T, Salman S.K. Digital Protection for Power Systems. London : P. Peregrinus on behalf of the Institution of Electrical Engineers, 1995. [14] Intel, 1997. Using the RDTSC Instruction for Performance Monitoring Available: http://developer.intel.com/drg/pentiumll/appnotes/RDTSCPM1.HTM [15] National Instruments. AT-AO-6/10 User Manual. September 1994. [16] Marti, J . R. Linares, L. R. Dommel, H. W. Current transformers and coupling-capacitor voltage transformers in real-time simulations. IEEE Transactions on Power Delivery , 12, January '97, 164-8 [17] Lucas, J . R. and McLaren P. G. Improved Simulation Models for Current and Voltage Transformers in Relay Studies. Transactions on Power Delivery, Vol. 7 No.1 January 1992, pp. 152-159. [18] Marti, Jose R. Lin, Jiming: Suppression of numerical oscillations in the EMTP IEEE Transactions on Power Systems , 4, My '89, 739-45. [19] Hou, D. Roberts, J . (1995) Capacitive Voltage Transformers: Transient Overreach Concerns and Solutions for Distance Relaying. Available: http://www.selinc.com/techpprs/6005.pdf [20] Lj. Kojovic, M. Kezunovic, S.L. Nilsson. Computer Simulation of a Ferroresonance Suppression Circuit for Digital Modeling of Coupling Capacitor Voltage Transformers, ISMM Conference on Computer Applications in Design, Simulation and Analysis, Orlando, March 1992. [21] Intel, 1999. 82C54 CHMOS Programmable Interval Timer. Available: ftp://download.intel.com/design/periphrl/datashts/23124406.pdf [22] J . R. Marti, L. R. Linares, J . Calvino, H. W. Dommel, OVNI: An object approach to real-time power system simulators, Proceedings of the 1998 International Conference on Power System Technology, Powercon'98, Beijing, China, April 18-21, 1998, pp. 977-981. 61 Appendix I. Test Case Files. 62 1 Circuit Schematic 2 Preprocessor Input File + + I Input f i l e f o r the Real Time Preprocessor I I (Format: RT-PREP V.3.02) I I Generated Automatical;/ by Suso's Schematics I I Copyright (c) Jesus Calvino-Fraga 1996-1998 I + + .BEGIN FILE .BEGIN GENERAL-DATA deltaT: 23.47E-6 totalTime: 30000 numLumped: 12 numLines: 3 numSources: 6 numOutNodes: 3 .END GENERAL-DATA BEGIN LUMPED L 1 739 nOa n l a c a l c C u r r : yes MOV: no L 1 739 nOb nib c a l c C u r r : no MOV: no L 1 739 nOc n l c c a l c C u r r : no MOV: no L 3 685 n3a n4a c a l c C u r r : no MOV: no L 3 685 n3b n4b c a l c C u r r : no MOV: no L 3 685 n3c n4c c a l c C u r r : no MOV: no R 2 n l a n2a c a l c C u r r : no MOV no R 2 nib n2b c a l c C u r r : no MOV no R 2 n l c n2c c a l c C u r r : no MOV no R 3 n4a n5a c a l c C u r r : no MOV no R 3 n4b n5b c a l c C u r r : no MOV no R 3 n4c n5c c a l c C u r r : no MOV no END LUMPED .BEGIN LINES .BEGIN LINE-0 phases: 3 Zc: 621.9 275.3 290.9 delay: 0.4710e-3 0.3416e-3 0.3399e-3 nodes: nOa no n6a no nOb no n6b no nOc no n6c no q-matrix: 0.58702696 -0.40302458 0.70710678 0.55427582 0.82086139 0.00000000. 0.58702696 -0.40302458 -0.70710678 .END LINE-0 .BEGIN LINE-1 phases: 3 Zc: 621.9 275.3 290.9 delay: 0.4710e-3 0.3416e-3 0.3399e-3 63 nodes: n6a no n9a no n6b no n9b no n6c no n9c no q-matrix: 0.58702696 -0.40302458 0.70710678 0.55427582 0.82086139 0.00000000 0.58702696 -0.40302458 -0.70710678 .END LINE-1 .BEGIN LINE-2 phases: 3 Zc: 621.9 275.3 290.9 delay: 0.4710e-3 0.3416e-3 0.3399e-3 nodes: n7a no n3a no n7b no n3b no n7c no n3c no q-matrix: 0.58702696 -0.40302458 0.70710678 0.55427582 0.82086139 0.00000000 0.58702696 -0.40302458 -0.70710678 .END LINE-2 .END LINES .BEGIN SOURCES 408000 0 n2a 408000 120 n2b 408000 -120 n2c 408000 0 n5a 408000 120 n5b 408000 -120 n5c .END SOURCES .BEGIN SWITCHES t o t a l : 6 GROUNDa n7a c l o s e : 1 open: 1 c l o s e : 0 open: 0 GROUNDb n7b c l o s e : 1 open: 1 c l o s e : 0 open: 0 GROUNDc n7c c l o s e : 1 open: 1 c l o s e : 0 open: 0 n9a n7a c l o s e : 1 open: 1 c l o s e : 1 open: 3600 n9b n7b c l o s e : 1 open: 1 c l o s e : 1 open: 3600 n9c n7c c l o s e : c l o s e : 1 open: 3600 .END SWITCHES .BEGIN OUTPUT n7a n7b n7c .END OUTPUT .BEGIN DACS t o t a l : 4 .BEGIN TO type: CCVT por t : 0 1 open: 1 CI Cc Rf R: 9.97E-08 1.30E-10 37.5 100 r a t i o a : 5000 .END tO .BEGIN T l type: CCVT po r t : 0 CI: 9.97E-08 Cc: 1.30E-10 Rf: 37.5 R: 100 r a t i o a : 5000 .END t l .BEGIN T2 type: CCVT po r t : 0 C2: Lc: Lf: 3.00E-10 0.708 Rc: 0.73 Cf: 628 9.6E-06 r a t i o b : 110 C2: 3.00E-10 Lc: 0.708 Rc: 628 Lf : 0.73 Cf: 9.6E-06 r a t i o b : 110 64 I, CI Cc Rf R: 9.97E-1.30E-37.5 100 08 10 C2 Lc Lf r a t i o a .END t2 .BEGIN T3 type: CT por t : Lf [0] I f [0] 5000 1. Rf Ls Lb r a t i o .END t3 .END DACS . END FILE 3.00E-10 0.708 Rc: 0.73 Cf: 628 9.6E-06 r a t i o b : 110 OE-02 4.5E+00 OE+03 0E-04 0E-04 120 Lf [1] I f [1] 1.0E-03 6.5E+00 Rs : Rb: 5.0E-1.25 01 Lf [2] I f [2] 1.0E-04 8 . 0E+00 3 The real-time simulator input file .BEGIN FILE .BEGIN GENERAL-DATA i n i t C o n d i t i o n s : no totalTime: 3 . 000000000e+04 deltaT: 2 . 344116268e-05 lumped: 12 l i n e s : 3 3ph-blocks: 3 6ph-blocks: 2 9ph-blocks: 0 12ph-blocks: 0 sources: 6 .END GENERAL-DATA .BEGIN NODES 1 n2a 2 n2b 3 n2c 4 n5a 5 n5b 6 n5c 7 nOa 8 n6a 9 nOb 10 n6b 11 nOc 12 n6c 13 n9a 14 n9b 15 n9c 16 n7a 17 n3a 18 n7b 19 n3b 20 n7c 21 n3c 22 n l a 23 nib 24 n l c 25 n4a 26 n4b 27 n4c .END NODES .BEGIN BLOCKS .BEGIN BLOCK-30 s i z e : 3 sources: no nodes: 8 n6a 10 n6b 12 n6c numSwStatus: 1 in i t S w S t a t u s : 0 A: switchStatus: 0 1.99292884026491777e+02 5.83883972222633432e+01 1.96913298072615248e+02 5. 38428835383524174e+01 5.83883972222633361e+01 1.99292884026491748e+02 .END BLOCK-30 .BEGIN BLOCK-31 s i z e : 3 sources: no nodes: 13 n9a 14 n9b 15 n9c numSwStatus: 8 in i t S w S t a t u s : 0 A: switchStatus: 0 3.98585768052983553e+02 1.16776794444526686e+02 3.93826596145230496e+02 1.07685767076704835e+02 1.16776794444526672e+02 3.98585768052983497e+02 switchStatus: 1 0.00000000000000000e+00 0.00000000000000000e+00 3.59613584006456620e+02 0.00000000000000000e+00 8.52272518004302384e+01 3.69492344854398993e+02 65 switchStatus: 2 3.63959310992398400e+02 0.00000000000000000e+00 0.00000000000000000e+00 7.30593100161196816e+01 0.00000000000000000e+00 3.63959310992398343e+02 switchStatus: 3 0.00000000000000000e+00 0.00000000000000000e+00 0.00000000000000000e+00 0.00000000000000000e+00 0 . 00000000000000000e+00 3.49293762897262638e+02 switchStatus: 4 3.694 9234 4 854 398937e+02 8.52272518004302384e+01 3.59613584006456620e+02 0.00000000000000000e+00 0.00000000000000000e+00 0.00000000000000000e+00 switchStatus: 5 0.000000O0000000000e+OO 0.00000000000000000e+00 3.39955032075384167e+02 0.00000000000000000e+00 0.00000000000000000e+00 0.00000000000000000e+00 switchStatus: 6 3.49293762897262638e+02 0.00000000000000000e+00 0.00000000000000000e+00 0.00000000000000000e+00 0.00000000000000000e+00 0.00000000000000000e+00 switchStatus: 7 9.99999999999999945e-21 0.00000000000000000e+00 9.99999999999999945e-21 0.00000000000000000e+00 0.00000000000000000e+00 9.99999999999999945e-21 END BLOCK-31 BEGIN BLOCK-32 s i z e : 3 sources: no nodes: 16 n7a 18 n7b 20 n7c numSwStatus: 8 i n i t S w S t a t u s : 4 h: switchStatus: 0 3.98585768052983553e+02 1.16776794444526686e+02 3.93826596145230496e+02 1.07685767076704835e+02 1.1677679444 4526672e+02 3.98585768052983497e+02 switchStatus: 1 0.00000000000000000e+00 0.00000000000000000e+00 3.59613584006456620e+02 0.00000000000000000e+00 8.52272518004302384e+01 3.69492344854398993e+02 switchStatus: 2 3.63959310992398400e+02 0.00000000000000000e+00 0 .00000000000000000e+00 7.30593100161196816e+01 0 . 00000000000000000e+00 3.63959310992398343e+02 switchStatus: 3 0.00000000000000000e+00 0.00000000000000000e+00 0.00000000000000000e+00 0.00000000000000000e+00 0.00000000000000000e+00 3.492937 628972 62 638e+02 switchStatus: 4 3.694 92344854398937e+02 8 .52272518004302384e+01 3.59613584006456620e+02 0 .00000000000000000e+00 0 . 00000000000000000e+00 0.00000000000000000e+00 switchStatus: 5 0.00000000000000000e+00 0.00000000000000000e+00 3.39955032075384167e+02 0.00000000000000000e+00 0.00000000000000000e+00 0.00000000000000000e+00 switchStatus: 6 3.4 92 937 628972 62 638e+02 0.00000000000000000e+00 0 . 00000000000000000e+00 0.00000000000000000e+00 0 . 00000000000000000e+00 0.00000000000000000e+00 switchStatus: 7 9.99999999999999945e-21 66 0.00000000000000000e+00 9.99999999999999945e-21 0.00000000000000000e+00 0.00000000000000000e+00 9.99999999999999945e-21 . END BLOCK-32 . BEGIN BLOCK-60 s i z e : 6 sources: yes nodes: 22 n l a 7 nOa 9 1 n2a 2 n2b 3 shots: 711 numSwStatus: 1 i n i t S w S t a t u s : 0 A: switchStatus: 0 1.99217017430485721e+00 1. 41130876103967151e+00 1. 0 6400989979774610e-01 9 .28460299667946964e-02 1. 41517513799524464e-03 1.23488882289107880e-03 1.41130876103967151e+00 nOb n2c 11 nOc 23 nib 24 n l c 1.06110293567250892e+02 7.99983716836193892e+00 6. 98069746911563538e+00 1.06400989979774596e-01 1.06400989979774596e-01 9.28460299667946964e-02 1.41517513799524464e-03 1.05387909216378958e+02 7.99983716836193803e+00 1. 06110293567250878e+02 1.40170076421910528e+00 1.99204238415714352e+00 1.06400989979774596e-01 1.99217017430485743e+00 Gab: -5.00000e-01 0.00000e+00 0.00000e+00 0.00000e+00 0.00000e+00 0.00000e+00 0.00000e+00 0.00000e+00 0.00000e+00 0.00000e+00 -5.00000e-01 0.00000e+00 0.00000e+00 0.00000e+00 0.00000e+00 0.00000e+00 0.00000e+00 -5.00000e-01 sources: 4.08000e+05 0. 4.08000e+05 120. 4.08000e+05 -120. .END BLOCK-60 .BEGIN BLOCK-61 s i z e : 6 sources: yes nodes: 25 n4a 17 n3a 19 4 n5a 5 n5b 6 shots: 711 numSwStatus: 1 i n i t S w S t a t u s : 0 A: switchStatus: 0 2.98687230023942618e+00 1. 61107098655156422e+00 1. 99080392248369792e-01 1.76426935880495905e-01 1.88164232466082534e-03 1.66752931322738571e-03 1. 61107098655156422e+00 00 n2a 00 n2b 00 n2c n3b 21 n3c 26 n4b 27 n4c n5c 1.70453565876536658e+02 2.10629842124266773e+01 1.86662168138667006e+01 1.99080392248369875e-01 1.99080392248369820e-01 1.7 6426935880495989e-01 1.88164232466082534e-03 1.68838133533455448e+02 2.10629842124266737e+01 1.70453565876536658e+02 1.59580245189057468e+00 2.98672798707664189e+00 1.99080392248369847e-01 2.98 687230023942618e+00 Gab: -3.33333e-01 0.00000e+00 0.00000e+00 0.00000e+00 0.00000e+00 0.00000e+00 0.00000e+00 0.00000e+00 0.00000e+00 0.00000e+00 -3.33333e-01 0.00000e+00 0.00000e+00 0.00000e+00 0.00000e+00 0.00000e+00 0.00000e+00 -3.33333e-01 sources: 4.08000e+05 0.00 n5a 4.08000e+05 120.00 n5b 4.08000e+05 -120.00 n5c .END BLOCK-61 END BLOCKS BEGIN OUTPUT numOutNodes: 3 n7a n7b n7c 67 recordEveryOther: 1 END OUTPUT BEGIN LUMPED L 1 73900e+00 nOa n l a current: yes MOV: no L 1 73900e+00 nOb nib current: no MOV no L 1 73900e+00 nOc n l c current: no MOV no L 3 68500e+00 n3a n4a current: no MOV no L 3 68500e+00 n3b n4b current: no MOV no L 3 68500e+00 n3c n4c current: no MOV no R 2 00000e+00 n l a n2a current: no MOV no R 2 00000e+00 nib n2b current: no MOV no R 2 00000e+00 n l c n2c current: no MOV no R 3 00000e+00 n4a n5a current: no MOV no R 3 00000e+00 n4b n5b current: no MOV no R 3 00000e+00 n4c n5c current: no MOV no END LUMPED BEGIN LINES .BEGIN LINE-0 phases: 3 delay: 4.7100e-04 Zc: 621.90 Q: 5.8702696e-01 -4 5.5427582e-01 8 5.8702696e-01 -4 3.4160e-04 275.30 3.3990e-04 290.90 0302458e-01 7.0710678e-01 2086139e-01 0.0000000e+00 0302458e-01 -7.0710678e-01 2 .8629197e-03 -6.7850268e-04 -5.7468770e-04 2.9415655e-03 -6.7850268e-04 2.8629197e-03 c a l c C u r r : no no no no no no nodes: nOa n6a nOb n6b .END LINE-0 .BEGIN LINE-1 phases: 3 delay: 4.7100e-04 nOc n6c Zc: Q: 5. 5. 5. 621.90 8702696e-5427582e-8702696e-01 01 01 3.4160e-275.30 04 .0302458e-01 .2086139e-01 .0302458e-01 3.3990e-04 290.90 7.0710678e-01 0.0000000e+00 -7 .0710678e-01 2.8629197e-03 -6. 7850268e-04 -5.7468770e-04 2.9415655e-03 -6.7850268e-04 2.8629197e-03 c a l c C u r r : no no no no no no nodes: n6a n9a n6b n9b n6c n9c . END LINE-1 .BEGIN LINE-2 phases: 3 delay: 4.7100e-04 3.4160e-04 Zc: 621.90 275.30 Q: 5 . 8702696e-01 -4.0302458e-01 5.5427582e-01 8.2086139e-01 5.8702696e-01 -4.0302458e-01 3.3990e-04 290.90 7.0710678e-01 0.0000000e+00 -7.0710678e-01 2.8629197e-03 -6.7850268e-04 -5.7468770e-04 2.9415655e-03 -6.7850268e-04 2.8629197e-03 c a l c C u r r : no no no no no no nodes: n7a n3a n7b n3b n7c n3c .END LINE-2 END LINES BEGIN SWITCHES t o t a l : 6 switch: 0 GROUNDan7a n7a i n i t i a l l y C l o s e d : yes b l k : 2 pos: 0 numGaLink 68 gaLink: 24 add: no switch: 1 GROUNDbn7b n7b i n i t i a l l y C l o s e d : yes gaLink: 26 add: no switch: 2 GROUNDcn7c n7c i n i t i a l l y C l o s e d : yes gaLink: 28 add: no switch: 3 n9a n7a i n i t i a l l y C l o s e d : gaLink: 19 add: switch: 4 n9b n7b i n i t i a l l y C l o s e d : gaLink: 21 add: switch: 5 n9c n7c i n i t i a l l y C l o s e d : no bl k : 2 pos: 1 numGaLink bl k : pos: no no no no bl k : 1 pos: b l k : 1 pos: numGaLink numGaLink numGaLink b l k : 1 pos: 2 numGaLink gaLink: events: 6 23 add: no t 1 00e+00 sw: 3 openOperation: no t 1 00e+00 sw: 4 openOperation: no t 1 00e+00 sw: 5 openOperation: no t 3 60e+03 sw: 3 openOperation: yes t 3 60e+03 sw: 5 openOperation: yes t 3 60e+03 sw: 4 openOperation: yes END SWITCHES BEGIN DACS t o t a l : 4 .BEGIN TO type: CCVT po r t : 0 CI C2 Cc Lc Rc Rf Lf 9.970000e-08 3.000000e-10 1.300000e-10 7.080000e-01 6.280000e+02 3.750000e+01 7.300000e-01 Cf: 9.600000e-06 R: 1.000000e+02 r a t i o a : 5.000000e+03 r a t i o b : 1.100000e+02 . END TO .BEGIN T l type: CCVT por t : 0 CI C2 Cc Lc Rc Rf Lf Cf R: r a t i o a : r a t i o b : .END T l .BEGIN T2 type: CCVT por t : 0 9.970000e-08 3.000000e-10 1.300000e-10 7.080000e-01 6.280000e+02 3.750000e+01 7.300000e-01 9.600000e-06 1.000000e+02 5.000000e+03 1.100000e+02 CI C2 Cc Lc Rc Rf Lf Cf R: r a t i o a r a t i o b .END T2 .BEGIN T3 type: p o r t : Lf[0] : L f [ 1 ] : 970000e-08 000000e-10 300000e-10 080000e-01 280000e+02 750000e+01 300000e-01 600000e-06 000000e+02 000000e+03 100000e+02 CT 3 1.000000e-02 1.000000e-03 69 Lf[2] : 1 000000e-04 I f [0] : 4 500000e+00 I f [ 1 ] : 6 500000e+00 I f [2] : 8 000000e+00 Rf: 1 000000e+03 Ls : 5 000000e-04 Rs : 5 000000e-01 Lb: 5 000000e-04 Rb: 1 250000e+00 r a t i o : 1 200000e+02 .END T3 .END DACS .END FILE Appendix II. Microtran Input File for the CT Simulation. 71 + + I I n p u t f i l e f o r M i c r o t r a n I I G e n e r a t e d A u t o m a t i c a l y b y S u s o ' s S c h e m a t i c s I I C o p y r i g h t ( c ) J e s u s C a l v i n o - F r a g a 1 9 9 6 - 1 9 9 8 I * . . . . . . . C a s e i d e n t i f i c a t i o n c a r d * F i l e i n f o r m a t i o n : * D a t a f i l e n a m e : c : \ M T \ c t . d a t * S c h e m a t i c f i l e n a m e : c : \ M T \ c t . s c h * D a t e o f c r e a t i o n o f D a t a f i l e : 0 7 - 2 1 - 1 9 9 9 ; t i m e : 1 6 : 4 2 : 2 5 * E q u i v a l e n t c i r c u i t o f a c u r r e n t t r a n f o r m e r * * . . . . . . . T i m e c a r d 2 3 . 0 E - 6 0 . 1 2 * . . . . . . . L u m p e d R L C b r a n c h m a i n 1 0 0 0 m a i n N 0 0 1 0 . 5 N 0 0 1 N 0 0 2 0 . 5 s e e m e 1 . 2 5 N 0 0 2 s e e m e 0 . 5 $ = = E n d o f l e v e l 1 : L i n e a r a n d n o n l i n e a r e l e m e n t s = = = = = = = = * * . . . . . . . S w i t c h e s a n d p i e c e w i s e l i n e a r e l e m e n t s 9 3 m a i n 1 0 . 0 5 0 . 3 9 3 m a i n 1 0 e 2 0 1 . 2 5 . 0 . 3 2 5 $ = = = E n d o f l e v e l 2 : S w i t c h e s a n d p i e c e w i s e l i n e a r e l e m e n t s = = = * * . . . . . . . V o l t a g e o r c u r r e n t s o u r c e s 1 4 m a i n - 1 1 0 0 60 - 9 0 . 0 0 . 0 $ = = = E n d o f l e v e l 3 : S o u r c e s = = = = = = = = = = = = = = = = = = * . . . . . . . . V o l t a g e - o u t p u t n o d e s 1 $ = = = L e v e l 5 : E n d o f d a t a c a s e = = = = = = = = = = = = = = = = = 72 

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
http://iiif.library.ubc.ca/presentation/dsp.831.1-0065261/manifest

Comment

Related Items