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

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