Ieee Standard Common Format For Transient Data Exchange Comtrade

IEEE C37.
111-1991
IEEE Standard Common Format for

Transient Data Exchange (COMTRADE)
for Power Systems
Sponsor
Power System Relaying Committee
of the
IEEE Power Engineering Society
Approved June 27, 1991

IEEE Standards Board
Abstract: A common format for the data files and exchange medium needed for the interchange of various
types of fault, test, or simulation data is defined. Sources of transient data are described, and the case of
diskettes as an exchange medium is recommended. Issues of sampling rates, filters, and sample rate
conversions for transient data being exchanged are discussed. Files for data exchange are specified, as is
the organization of the data. A sample file is given.
Keywords: Configuration file, data file, header file, transient data
The Institute of Electrical and Electronics Engineers, Inc.

345 East 47th Street, New York, NY 10017-2394, USA
Copyright © 1991 by the
Institute of Electrical and Electronics Engineers, Inc.
All rights reserved. Published 1991
Printed in the United States of America
ISBN 1-55937-156-0
No part of the publication may be reproduced in any form, in an electronic retrieval system or otherwise without the
prior written permission of the publisher.
Authorized licensed use limited to: York University. Downloaded on March 04,2015 at 09:40:17 UTC from IEEE Xplore. Restrictions apply.
IEEE Standards documents are developed within the Technical Committees of the IEEE Societies and the Standards
Coordinating Committees of the IEEE Standards Board. Members of the committees serve voluntarily and without
compensation. They are not necessarily members of the Institute. The standards developed within IEEE represent a
consensus of the broad expertise on the subject within the Institute as well as those activities outside of IEEE that have
expressed an interest in participating in the development of the standard.
Use of an IEEE Standard is wholly voluntary. The existence of an IEEE Standard does not imply that there are no other
ways to produce, test, measure, purchase, market, or provide other goods and services related to the scope of the IEEE
Standard. Furthermore, the viewpoint expressed at the time a standard is approved and issued is subject to change
brought about through developments in the state of the art and comments received from users of the standard. Every
IEEE Standard is subjected to review at least every five years for revision or reaffirmation. When a document is more
than five years old and has not been reaffirmed, it is reasonable to conclude that its contents, although still of some
value, do not wholly reflect the present state of the art. Users are cautioned to check to determine that they have the
latest edition of any IEEE Standard.
Comments for revision of IEEE Standards are welcome from any interested party, regardless of membership affiliation
with IEEE. Suggestions for changes in documents should be in the form of a proposed change of text, together with
appropriate supporting comments.
Interpretations: Occasionally questions may arise regarding the meaning of portions of standards as they relate to
specific applications. When the need for interpretations is brought to the attention of IEEE, the Institute will initiate
action to prepare appropriate responses. Since IEEE Standards represent a consensus of all concerned interests, it is
important to ensure that any interpretation has also received the concurrence of a balance of interests. For this reason
IEEE and the members of its technical committees are not able to provide an instant response to interpretation requests
except in those cases where the matter has previously received formal consideration.
Comments on standards and requests for interpretations should be addressed to:
Secretary, IEEE Standards Board

445 Hoes Lane
P.O. Box 1331
Piscataway, NJ 08855-1331
USA
IEEE Standards documents are adopted by the Institute of Electrical and Electronics Engineers without regard to
whether their adoption may involve patents on articles, materials, or processes. Such adoption does not assume
any liability to any patent owner, nor does it assume any obligation whatever to parties adopting the standards
documents.
Foreword
[This Foreword is not a part of IEEE C37.111-1991, IEEE Standard Format for Transient Data Exchange (COMTRADE) for Power
Systems.]
The increasing use of digital computer-based protection, oscillography, measurement, and control functions in electric
power substations has created a potential for accumulating large quantities of digital records of power system transient
events. In addition to these sources of digital data, analog and digital power-system simulators also may be used to
generate transient digital records. The users of these records are faced with the problem of having to cope with
different formats used by each of these systems to generate, store, and transmit these records.
COMTRADE defines a common format for storing digital records of transient events. This standard is to be used for
facilitating physical exchange of data files on storage media. It is hoped that this standard will be of considerable value
to the users and producers of digital data files describing transient events on electric power systems.
At the time that it developed this standard, the COMTRADE Working Group had the following membership:
A. G. Phadke, Chair
J. A. Jodice, Vice Chair
M. G. Adamiak D. C. Dawson M. Lefrancois

J. D. Brandt D. Fulton H. I. Mehta
J. A. Bright E. M. Gulachenski R. J. Murphy
R. O. Burnett, Jr. D. Hollands D. Robertson
C. H. Castro A. T. Howard M. S. Sachdev
T. W. Cease D. Jerrings J. S. Thorp
D. M. Clark M. Kezunovic E. A. Udren
G. Clough D. J. Lawerence M. A. Xavier
At the time that it reviewed and approved this standard for balloting, the Relay Channels Subcommittee had the
following membership:
E. A. Udren, Chair
P. R. Drum, Vice Chair
B. Bozoki J. W. Ingleson H. S. Smith

R. J. Fernandez S. L. Nilsson J. E. Stevens
J. W. Hohn A. G. Phadke J. A. Zipp
D. Hollands E. T. Sage
J. D. Huddleston, III L. J. Schulze
At the time that it balloted and approved this standard for submission to the IEEE Standards Board, the Power System
Relaying Committee of the IEEE Power Engineering Society had the following membership:
J. R. Boyle, Chair
J. Zulaski, Vice Chair
A. T. Giuiante, Secretary
J. C. Appleyard J. L. Blackburn H. J. Calhoun

R. E. Arehart J. Blose J. W. Chadwick
C. W. Barnett B. Bozoki D. M. Clark
E. A. Baumgartner J. A. Bright D. E. Colwell
R. W. Beckwith W. R. Brownlee S. P. Conrad
J. Berdy A. A. Burzese C. J. Cook
iii
A. N. Darlington R. H. Jones A. C. Pierce
D. C. Dawson E. W. Kalkstein J. M. Postforoosh
R. W. Dempsey T. L. Kaschalk O. F. Pumphrey
R. E. Deitrich K. J. Khunkhun G. D. Rockefeller
J. B. Dingier J. L. Koepfinger M. S. Sachdev
H. Disante J. S. Komisarek E. T. Sage
P. R. Drum W. C. Kotheimer D. E. Sanford
L. L. Dvorak L. E. Landoll L. Scharf
W. A. Elmore J. R. Latham L. J. Shculze
J. T. Emery J. R. Linders H. S. Smith
E. J. Emmerling H. J. Marieni J. E. Stephens
M. K. Enns W. J. Marsh, Jr. W. M. Strang
J. Esztergalyos Ca A. Mathews A. Sweetana
W. E. Feero G. E. May F. Y. Tajaddodi
R. J. Fernandez R. J. Moran R. P. Taylor
S. E. Grier C. J. Mozina J. S. Thorp
C. H., Griffin J. J. Murphy E. A. Udren
K. R. Gruesen T. J. Murray W. H. VanZee
E. A. Guro K. K. Mustaphi J. M. Vanderleck
R. W. Haas G. R. Nail V. Varneckas
R. E. Hart T. Niessink D. R. Volzka
R. W. Hirtler S. L. Nilsson F. Von Roeschlaub
J. W. Hohn R. W. Ohnesorge C. L. Wagner
S. H. Horowitz G. C. Parr J. W. Walton
J. Huddleston, III R. W. Pashley T. E. Wiedman
J. W. Ingleson A. G. Phadke A. E. Zocholl
When the IEEE Standards Board approved this standard on June 27, 1991, it had the following membership:
Marco W. Migliaro, Chair

Donald C. Loughry, Vice Chair
Andrew G. Salem, Secretary
Dennis Bodson Donald N. Heirman Lawrence V. McCall

Paul L. Borrill Kenneth D. Hendrix Donald T. Michael*
Clyde Camp John W. Horch Stig L. Nilsson
James M. Daly Ben C. Johnson John L. Rankine
Donald C. Fleckenstein Ivor N. Knight Ronald H. Reimer
Jay Forster* Joseph L. Koepfinger* Gary S. Robinson
David F. Franklin Irving Kolodny Terrance R. Whittemore
Ingrid Fromm Michael A. Lawler
Thomas L. Hannan John E. May, Jr.
*Member Emeritus
Adam Sicker
IEEE Standards Project Editor
iv
CLAUSE PAGE
1. Introduction .........................................................................................................................................................1
1.1 Purpose....................................................................................................................................................... 1
1.2 Need for a Common Format ...................................................................................................................... 1
2. Sources of Transient Data ...................................................................................................................................1
2.1 Digital Fault Recorders .............................................................................................................................. 1

2.2 Analog Tape Recorders.............................................................................................................................. 2
2.3 Digital Protective Relays ........................................................................................................................... 2
2.4 Transient Simulation Programs.................................................................................................................. 2
2.5 Analog Simulators...................................................................................................................................... 2
3. Data Exchange Medium......................................................................................................................................2
3.1 Introduction ................................................................................................................................................ 2

3.2 Recommended Medium ............................................................................................................................. 3
4. Data Exchange Sampling Rates ..........................................................................................................................3
4.1 Introduction ................................................................................................................................................ 3

4.2 Sampling Process Structure ....................................................................................................................... 3
4.3 Interpolation ............................................................................................................................................... 6
5. Files for Data Exchange ......................................................................................................................................7
5.1 Header File (xxxxxxxx.HDR).................................................................................................................... 7

5.2 Configuration File (xxxxxxxx.CFG).......................................................................................................... 7
5.3 Data File (xxxxxxx.DAT) .......................................................................................................................... 7
6. Organization of Transient Data...........................................................................................................................8
6.1 Header Files ............................................................................................................................................... 9

6.2 Configuration Files .................................................................................................................................... 9
6.3 Data Files ................................................................................................................................................. 13
6.4 Preparation of Fault Data Diskettes ......................................................................................................... 14
6.5 Binary Data Files ..................................................................................................................................... 14
7. Sample File .......................................................................................................................................................15
7.1 SASKO1.HDR ......................................................................................................................................... 15

7.2 SASKO1.CFG.......................................................................................................................................... 16
7.3 SASK01.DAT .......................................................................................................................................... 17
Annex A (Informative) Bibliography ...........................................................................................................................18
Annex B (Informative) Program for Sampling Frequency Conversion........................................................................19
Annex C (Informative) Data and File Structure............................................................................................................22
IEEE Standard Common Format for
Transient Data Exchange (COMTRADE)
for Power Systems
1. Introduction
The rapid evolution and implementation of digital devices for fault and transient data recording and testing in the
electric utility industry has generated the need for a standard format for the exchange of such data for use with various
devices to enhance and automate the analysis, testing, evaluation, and simulation of the power system and related
protection schemes during fault and disturbance conditions.
1.1 Purpose
This standard defines a common format for the data files and exchange medium needed for the interchange of various
types of fault, test, or simulation data.
1.2 Need for a Common Format
The proliferation and implementation of digital devices for the acquisition, analysis, simulation, and testing of power-
system equipment has made available a profusion and variety of data that has not been readily available in the past.
Since this data may come from a variety of sources, from different manufacturers using proprietary or other standard
formats, a common format standard is necessary to facilitate the exchange of such data between devices with diverse
applications but that have the capability of utilizing digital data from other devices.
2. Sources of Transient Data
There are several possible sources of transient data for exchange.
2.1 Digital Fault Recorders
Digital fault recorders for monitoring power-system voltages, currents, and events are supplied by several
manufacturers. These devices record analog signals by periodically sampling them and converting the measured
IEEE C37.111-1991 IEEE STANDARD COMMON FORMAT FOR TRANSIENT
signals to digital values. Typical recorders monitor 16–64 analog channels and a comparable number of event (contact
status) inputs. Sampling rates, analog-to-digital converter resolution, record format, and other parameters have not
been standardized.
2.2 Analog Tape Recorders
Analog tape recorders record analog signals on magnetic tape, usually using frequency-modulation techniques.
Recorded tapescan be played back to drive oscilloscopes or plotters for visual examination of the recorded waveforms.
Typical recorders monitor up to 32 analog signals.
By employing suitable hardware and software, the signals recorded on the analog tapes can be converted to digital
records in any desired format. The fidelity of the resultant output is dependent upon the limitations of both the analog
recorder and the digital-conversion system. The loss in fidelity can be minimized by a proper choice of the sampling
system.
2.3 Digital Protective Relays
New relay designs using microprocessors are currently being developed and marketed. Some of these relays have the
ability to capture and store relay input signals in digital form and transmit this data to another device. In performing
this function, they are similar to digital fault recorders, except that the nature of the recorded data may be influenced
by the needs of the relaying algorithm. As with the digital fault recorders, record format and other parameters have not
been standardized.
2.4 Transient Simulation Programs
Unlike the above devices that record actual power system events, transient simulation programs produce transient data
by analyzing mathematical models of the power system. Because this analysis is carried out by a digital computer, the
results are inherently in digital form suitable for digital data dissemination.
While originally developed for the evaluation of transient overvoltages in power systems, these programs are finding
increasing usage in other types of studies, including test cases for digital relaying algorithms. Because of the ease with
which the input conditions of the study can be changed, transient simulation programs can provide many different test
cases for a relay.
2.5 Analog Simulators
Analog simulators model power system operations and transient phenomena, with scaled values of resistance,
inductance, andcapacitance, operating at greatly reduced values of voltage and current. The components usually are
organized with similar line segments that can be connected together to form longer lines. The frequency response of the
analog simulator primarily is limited by the equivalent length of the model segment and typically ranges from 1–5 kHz.
As with the output of analog tape recorders, the analog output of the simulator could be converted to digital records with
appropriate filtering and sampling.
3. Data Exchange Medium
3.1 Introduction
Electric power utilities record fault data for post-fault analysis, for determining the nature and location of the fault, and
for keeping a record for future use. The data are generally stored as oscillograms on magnetic tapes and in computer
2 Copyright © 1991 IEEE All Rights Reserved
DATA EXCHANGE (COMTRADE) FOR POWER SYSTEMS IEEE C37.111-1991
files. An oscillogram contains voltage and current waveforms that can be examined and analyzed. Digital computers
cannot record voltage and current waveforms directly. The waveforms are quantized forstorage in computer files. More
recently, personal computers have been used to record fault data on diskettes and cassettes.
It is not convenient to transport magnetic tapes that are used with main-frame computers, in the form of reel-to-reel or
cassettes, between utilities and individual users. This is especially true if the users are separated by long distances or
are located in different countries. Also, the recipient of a magnetic tape must have a computer system compatible with
the system on which the tape was prepared. It is more convenient to transport cassettes than to transport magnetic
tapes. However, recording data to and from cassettes is a slow process.
3.2 Recommended Medium
The most commonly-used computer systems today are personal computers equipped with drives for diskettes. Double-
sided, double-density, 5 1/4 in diskettes store approximately 360 Kb of text and data. Double-sided, double-density,
microfloppy 3 1/2 in diskettes store approximately 720 Kb. The double-sided, high-density 1.2 Mb 5 1/4 in floppy
diskettes and 1.44 Mb 3 1/2 in microfloppy diskettes are increasing in popularity. Both the 5 1/4 in diskettes and 3 1/2 in
microfloppy diskettes are very wellsuited for the task of data exchange. They can be placed easily in padded envelopes
and sent by mail from one location to another. Because of their widespread use and the convenience with which they can
be sent to another location by mail, it is recommended that diskettes be used for exchanging fault data. However,
individuals exchanging data may use other mutually acceptable media.
4. Data Exchange Sampling Rates
4.1 Introduction
This section is concerned with issues of sampling rates, filters, and sample rate conversions for transient data being
exchanged. Of special concern is the case in which data is captured at a high sample rate but a lower sample rate is
required by the device or software using the data. The simple expedient of dropping every nth sample is NOT the
correct way of making the conversion. This section discusses the correct way to perform this common function as well
as other related topics.
Since it is difficult to anticipate all future uses of such standard test cases (e.g., future algorithms, architectures,
microprocessors), it seems clear that high accuracy and high sampling rates are desirable in the test cases. That is,
although many existing digital relays use 12 bit accuracy, 16 bit or higher resolution A/D converters may be used in the
near future. The sampling rate issue is similar. Samples obtained at a sampling frequency of 240 Hz, for example, must
be obtained using a filter with a cut-off frequency of 120 Hz to avoid aliasing. It is straightforward to convert these
samples to samples at higher sampling frequencies, but the effect of the anti-aliasing filter cannot be removed. That is,
it is possible to obtain samples at 960 Hz equivalent to the output of the 120 Hz anti-aliasing filter, but it is not possible
to obtain samples at 960 Hz of the original (unfiltered) signal.
4.2 Sampling Process Structure
It is therefore recommended that the original samples be obtained (after a proper anti-aliasing filter, if necessary) at as
high an accuracy and as high a sampling rate as possible in a given installation. However, specific choices of sampling
rates (see sampling rate tables in 4.3) could make further use of the data much easier. Consider data obtained at a
sampling rate of fs Hz. It would be most convenient if there were some standard technique to convert from the data at
fs Hz to data that would have been obtained by the user's proposed system shown in Fig 1.
Developments in digital signal processing present an efficient solution to the problem if there are integers L and M
such that
Copyright © 1991 IEEE All Rights Reserved 3
Lf s = Mf o = f LCM (1)
where
fLCM represents the least common multiple. The solution is shown in Fig 2.
The box labeled FIR in Fig 2 is a finite impulse response equivalent of the analog filter shown in Fig 1 at a sampling
rate of Lfs Hz. Eq 1 is the key to the solution, and it limits sampling rates to some extent.
The process of converting from samples at frequency fs to samples at frequency fo is to determine the frequency fLCM
such that Eq 1 is satisfied, provide an FIR description of the desired analog filter, and implement Fig 2. The FIR
description of the analog filter is a table of numbers corresponding to a digital filter description at the sampling
frequency fLCM. A standard technique for the FIR design might be to use an impulse equivalent filter where the nth
entry in the table was the impulse response of the analog filter at the nth sample time. Other FIR filter design programs
are available (see [B3])1 along with a program that implements Fig 2. The transient response of the FIR filter at the
beginning of the data must also be considered. If the FIR duration is one period of the nominal power system
frequency, then a total of two periods of prefault data should be included in the standard cases. Artificial prefault data
can be supplied if it is not present. The FORTRAN program CONVERT (see Appendix B) is an implementation of Fig
2 that is an alternative to the program in Section 8.2 of [B3]. The program is an illustration of the impulse invariant FIR
filter for a second-order low-pass filter. Fig 3 shows the output samples at 720 Hz with an input sampled at 4320 Hz.
Figure 1— Typical Signal Processing
Figure 2— DSP Solution
1
The numbers in brackets, when preceded by the letter “B,” correspond to the Bibliography in Appendix A.
Figure 3— Example of Sample Bate Conversion
A further simplification would result if a single fLCM were specified. The simplification would be that the user would
have to specify a single FIR representation of the desired analog filtering at the specified fLCM. Unfortunately, a single
fLCM that would satisfy all the sampling rates known to the working group would be so large as to make the description
of an FIR filter unwieldy. The solution is to use two different common multiple frequencies f1LCM and f2LCM. Each
frequency would produce a short list of sampling frequencies corresponding to an integer number of samples per cycle
at the nominal power-system frequency. Conversions between frequencies in a single list would be particularly simple.
Conversions between frequencies that are not in a single list would require that the user determine the appropriate fLCM
for the application and then follow the same procedure. The two lists of recommended sampling frequencies are shown
in Tables 1 and 2 for both 50 Hz and 60 Hz fundamental frequencies. It is assumed that the sampling frequencies are
independent of the actual power-system frequency and that the columns “samples per cycle” in Tables 1 and 2 are
interpreted as the number of samples per cycle at the nominal power system frequency of 50 or 60 Hz.
NOTE — The higher sampling frequencies in Tables 1 and 2 are artifacts of the technique of sampling rate conversion and data
sharing. It is not intended that the high sampling rates be used tocapture traveling wave phenomena. It is expected that
the lower frequencies in Tables 1 and 2 will be the norm.
Table 1— Frequencies Corresponding to fLCM= 384 × fbase

Samples/Cycle
Samples/cycle f for 60 Hz f for 50 Hz
384 23040 19200
192 11520 9600
128 7680 6400
96 5760 4800
64 3840 3200
48 2880 2400
32 1920 1600
24 1440 1200
16 960 800
12 720 600
8 480 400
6 360 300
4 240 200
Table 2— Frequencies Corresponding to fLCM = 3200 × fbase

Samples/Cycle
Samples/cycle f for 60 Hz f for 50 Hz
3200 192000 160000
1600 96000 80000
800 48000 40000
640 38400 32000
400 24000 20000
320 19200 16000
200 12000 10000
160 9600 8000
128 7680 6400
100 6000 5000
80 4800 4000
64 3840 3200
50 3000 2500
40 2400 2000
32 1920 1600
20 1200 1000
16 960 800
10 600 500
8 480 400
4 240 200
4.3 Interpolation
The preceding is based on the assumption that the original data consist of the samples taken directly after a properly-
designed anti-aliasing filter. The possibility that the data to be shared has been processed digitally must also be
considered. If the digital processing can be represented as a linear shift-invariant operation that preserves the original
sampling rate of fs Hz, then it is straightforward to invert the digital processing. As an example, let the original samples
be the sequence x(n) and assume that the average over the first four samples is used to produce the sequence y(n), i.e.,
1
y ( n ) = --- [ x ( n ) + x ( n – 1 ) + x ( n – 2 ) + x ( n – 3 ) ] (2)
4
Given the sequence y(n), it is possible to recover x(n) with
x ( n ) = 4y ( n ) – x ( n – 1 ) – x ( n – 2 ) – x ( n – 3 ) (3)
A more serious problem is encountered if decimation is involved in the digital processing, i.e., samples are eliminated
and data is produced at a lower sampling rate. In the previous example, this might correspond to sharing only every
fourth sample of y(n) to form
z ( n ) = y ( 4n ) (4)
There is a program in [B3] for least-squares interpolation, i.e., to recover the missing samples from the sequence y(n).
It assumes however, that the sequence y(n) is band limited to a bandwidth consistent with the lower sampling rate. If
the digital filtering has effectivelyreduced the bandwidth, then the interpolation should be successful. The digital
filtering (averaging) provided by Eq 2 may in fact be acceptable; and, in time-critical applications, may be the only
practical technique that can be used. In the absence of appropriate digital filtering, however, decimation introduces
aliasing. In the previous example, if every fourth sample of the original sequence x(n) is retained, this corresponds to
sampling the original signal at fs/4 Hz but with an anti-aliasing filter with too large a bandwidth. The nonfundamental
frequencies present in the waveforms will be distorted by aliasing. It is recommended that decimation be avoided if
possible and that it only used after appropriate analog or digital filtering.
5. Files for Data Exchange
The standard files shall be ASCII files. Each event shall have three types of files associated with it (see Appendix C for
background information on files and data storage). Each of the three types carries a different class of information:
header, configuration, and data.
File names are in the form “xxxxxxxx.yyy.” The xxxxxxxx part of the name is used to identify the file, i.e., FAULT1
or TEST_2. The yyy portion of the file name is used to identify the type of file and is known as the file name extension
“.HDR” for header, “.CFG” for configuration, and “.DAT” for data. (See 6.5 for the use of binary files.)
5.1 Header File (xxxxxxxx.HDR)
The header file is created by the originator of the fault data using a word processor program. The data is intended to be
printed and read by the user. The creator of the header file can include any information in any format desired.
Suggestions for information to include are given in Section 6.
Most word processors can save data in either of two formats. One format contains special characters specific to the
particular word processor being used. The other format contains only the text characters typed. The second format
should be used for data exchange so that any word processor program can be used to read or print the data. This format
is often called “ASCII format” by word processor programs. If no command exists in your word processor to create
such a file, an alternative method of creating the file is to use the print functions of the word processor to print the text
to a disc file.
5.2 Configuration File (xxxxxxxx.CFG)
The configuration file is intended to be read by a computer program and therefore must have its data in a specific
format. The data in the configuration file is information needed by a computer program in order to properly interpret
the transient data.
This data includes items such as sample rates, number of channels, line frequency, channel information, etc. Details of
the exact data and format of the configuration file are given in Section 6.
The configuration file can be created either with a word processing program or by a computer program that makes the
configuration file from information available in the data that is the source of the transient record. If a word processor
is used to create the configuration file, it must save the data in ASCII format as described in 5.1 above.
5.3 Data File (xxxxxxx.DAT)
The data file contains the value of each sample of each input channel. The number stored for a sample is usually the
number produced by the device that samples the input waveform.
The stored data may be either zero based, or it may have a zero offset. Zero-based data goes from a negative number
to a positive number, e.g., −2000 to +2000. Zero-offset numbers are all positive with a positive number chosen to
represent zero, e.g., 0 to 4000, with 2000 representing zero. Conversion factors specified in the configuration file
define how to convert the data values to engineering units.
In addition to data representing analog inputs, inputs that represent on/off signals are also frequently recorded. These
are often referred to as digital inputs, digital channels, digital subchannels, event inputs, logic inputs, binary inputs,
contact inputs, or status inputs. In this Standard, this type of input is referred to as a status input. The state of a status
input is represented by a number “1” or “0” in the data file.
A detailed description of the data file format is given in Section 6..
6. Organization of Transient Data
When exchanging transient data, it is necessary to include with the data the information that describes the
circumstances surrounding the transient. Such information is usually formatted and stored differently than the actual
data values. The information provided in transient files includes the following:
1) Textual descriptions of the circumstances surrounding the transient

2) The configuration of the transient recorder at the time of recording
3) The data values
Descriptive information is most easily entered and interpreted in an ASCII format. It is contained in relatively small
files and varies so widely that it is difficult to describe a format that would include every circumstance.
On the other hand, although the configuration information (e.g., number and type of channels, channel descriptors,
scaling factors) is textual, it is highly predictable and thus can be entered in a predetermined format that can be read by
a software program.
Data values are even more predictable. They are generally stored in a binary formatbecause it requires less storage
space, and the number of values to be stored is quite large. The disadvantage of binary files is that they are not as
portable as ASCII files. Since the purpose of thisdocument is to describe a standard for data exchange, it is
recommended that the data values be converted to an ASCII format for this purpose.
More importantly, the recommendations of the format are motivated by the CIGRE Report by WG 34.01 [B1]. The
CIGRE document specifies an ASCII format for both the textual information in free format and the data values in a
fixed format.
To be compatible with CIGRE, the following file types are required:
1) A header file that corresponds to the CIGRE header file and contains the textual, descriptive information in a
free-form ASCII format
2) A data file also corresponding to the CIGRE data file that contains the data values
In addition, this standard requires a configuration file that contains the specific configuration of the transient recorder
that acquired the data in a fixed ASCII format so that it is machine readable.
For a single transient record, there should be one header file and one configuration file. However, there might be
multiple data files if the data does not fit onto a single floppy diskette.
The following sections describe the content and format of each of these file types.
6.1 Header Files
The intent of the header is to provide supplementary information in a narrative manner for the user to better understand
the conditions of the transient record. The header file is not intended to be manipulated by an applications program.
6.1.1 Content
Where appropriate, the following items should be included in the header file:
1) Description of the power system prior to disturbance

2) Name of the station
3) Identity of the line, transformer, reactor, capacitor, or circuit breaker that experienced the transient
4) Length of the faulted line
5) Positive and zero-sequence resistances and reactances
6) Capacitances
7) Mutual coupling between parallel lines
8) Locations and ratings of shunt reactors and series capacitors
9) Nominal voltage ratings of transformer windings
10) Transformer power ratings and winding connections
11) Parameters of the system behind the nodes where the data was recorded (e.g., equivalent positiveand zero
sequence impedances of the sources)
12) Description of how the data was obtained, whether it was obtained at a utility substation or by simulating a
system condition on a computer program such as EMTP
13) Description of the anti-aliasing filters used
14) Description of analog mimic circuitry
15) Number of discs on which the case data is stored
The following additional configuration information should be included in this section in order to be compatible with
CIGRE [B1]:
1) The format in which the data is recorded

2) The headings of the columns of the data table
6.1.2 Filenames
Header filenames have the “.HDR “extension to distinguish them from configuration and data files and to serve as a
convention that is easy to remember and identify. All files must have the same filename, differing only by the
extensions that indicate the type of files.
6.1.3 Format
The header files are free-form ASCII files of any length. ASCII files can be read by simple editors and word
processors.
6.2 Configuration Files
The intent of the configuration file is to provide the information necessary for a computer program to read and interpret
the data values in the associated data files. Some of this information might be duplicated in the header file (e.g.,
number of channels) to be compatible with CIGRE [B1].
The configuration file is in a predefined, fixed format so that a computer program does not have to be customized for
each configuration file. It is in an ASCII format so that it can be read by humans as well as computers.
6.2.1 Content
The configuration file has the following information:
1) Station name and identification

2) ) Number and type of channels
3) Channel names, units, and conversion factors
4) Line frequency
5) Sample rate and number of samples at this rate
6) Date and time of first data value
7) Date and time of trigger point
8) File type
6.2.2 Filenames
Configuration filenames have the “.CFG” extension to distinguish them from header and data files.
6.2.3 Format
The configuration file is a standard ASCII file of a fixed or predetermined format. It must be included on every data
diskette.
The file is divided into lines. Each line is terminated by a carriage return and line feed: 〈CR,LF〉. Commas are used to
separate elements within a line. For missing data items, the separator commas are retained with no spaces between the
commas.
The information in the file must be listed in the exact order and fixed-order format shown in 6.2.3.1−6.2.3.6.
Deviations from this format will result in misinterpretations by the computer.
6.2.3.1 Station Name and Identification
The configuration file begins with the station name and the station identification.
station_name,id 〈CR,LF〉
where:
station_name=the unique name of the recorder

id= the unique number of the recorder
6.2.3.2 Number and Type of Channels
This statement contains the number and type of channels as they occur in each data record in the data file:
TT,nnt,nnt 〈CR, LF〉
where:
TT= total number of channels

nn= number of channels of
t= types of input (A=analog/D=status).
6.2.3.3 Channel Information
This is a group of lines containing channel information. There is one line for each channel as follows:
nn,id,p,cccccc,uu,a,b,skew,min,max 〈CR,LF〉
nn,id,p,cccccc,uu,a,b,skew,min,max 〈CR,LF〉
nn,id,m 〈CR,LF〉
nn,id,m 〈CR,LF〉
where:
nn= channel number

id= channel name
p= channel phase identification (e.g., A,B,C,N,R,Y,B)
cccccc= circuit/component being monitored
uu= channel units (kV, kA, etc.)
a= real number (see below)
b= real number. Channel conversion factor is ax+b [i.e., a recorded value of x corresponds to (ax+b) in units
uu specified above]
skew= real number. Channel time skew (in µs) from start of sample period
min = an integer equal to the minimum value (lower limit of sample range)for samples of this channel
max = an integer equal to the maximum value (upper limit of sample range) for samples of this channel
m= (0 or 1) the normal state of this channel (applies to digital channels only)
Repeat the “nn,id,p,cccccc,uu,a,b,skew,min,max” sequence as often as necessary to provide the channel names, phase,
units, and conversion factors for each of the channels in the order in which they occur in the data. Phase, circuit
component, and conversion factors are not necessary for digital channels and thus are omitted.
In the above record format specification, the lines separated by ellipsis represent analog channels and the last two lines
represent digital channels.
6.2.3.4 Line Frequency
The line frequency is listed on a separate line in the file:
lf 〈CR,LF〉
where:
lf = line frequency in Hz (50 or 60)
6.2.3.5 Sample Rate Information
This section contains the total number of sample rates followed by a list containing each sample rate and the number
of the last sample at the given rate.
nrates 〈CR, LF〉

sssss1,endsamp1 〈CR,LF〉
sssss2,endsamp2 〈CR,LF〉
…
sssssn,endsampn 〈CR,LF〉
where:
nrates = number of different sample rates in the data file

sssss1 – sssssn =the sample rate in Hz
endsamp1 – endsampn =last sample number at this rate
6.2.3.6 Date/Time Stamps
There are two date/time stamps: the first one is for the first data value in the data file and the second one is for the
trigger point. They are of the following format:
mm/dd/yy,hh:mm:ss.ssssss 〈CR,LF〉
mm/dd/yy,hh:mm:ss.ssssss 〈CR,LF〉
where:
mm = month (01–12)
dd = day of month (01–31)
yy = last two digits of year
hh = hours (00–23)
mm = minutes (00–59)
ss.ssssss =seconds (from 0 sec to 59.999999 sec)
6.2.3.7 File Type
The data file type is identified as being an ASCII file by the file type identifier ft.
ft 〈CR,LF〉
where:
ft = ASCII
6.2.4 Example Configuration File
Great Oaks Substation,25<CR,LF>

6,4A,2D <CR,LF>
1,Line 1 Phase A Voltage,A,,kV,200.,0.,0,4096 ·CR,LF>
2,Line 2 Phase B Voltage,B,,kV,200.,0.,0,4096 <CR,LF>
3,Bus Current,A,,kA,100.,0.,0.,04096 <CR,LF>
4,Line 2 Phase A Voltage,A,,kV,200.,0.,0.,0,4096 <CR,LF>
1,Breaker #XX Open,0 <CR,LF>
2,Breaker #YY Closed,0 <CR,LF>
60 <CR,LF>
2 <CR,LF>
5184,1298 <CR,LF>
2592,1400 <CR,LF>
06/25/88,23:12:14.089045 <CR,LF>
06/25/88,23:12:19.000011 <CR,LF>
ASCII <CR,LF>
6.3 Data Files
The intent of the data files is to contain the actual data values of the transient data. The data must conform exactly to
the format defined in the configuration file so that the data can be read by a computer program.
6.3.1 Content
The data file shall contain the data values in rows and columns where each row consists of a set of data values preceded
by a sequence number and the time for that set of data values. No other information is contained in the data file.
6.3.2 Data Filenames
Data filenames shall have the “.DAT” extension to distinguish them from header and configuration files and to serve
as a convention that is easy to remember and identify. The filename itself would be the same for header, configuration,
and data files to associate header and configuration files with the data files.
In the event that there are multiple data files, the last two characters of the “.DAT” extension should be changed from
“AT” to the sequence number of the file, allowing up to 99 files.
6.3.3 Data File Format
The data files should be divided into rows. Each row is divided into n+2 columns where n is the number of channels
in the recording. The number of data rows varies with the length of the recording and thus affects the length of the file.
The number of columns is dependent on the recording system and also affects the file length.
Column one contains the sample number, an integer (I10), of the data set in that row. The second column is the time
of the data in µs, an integer (I10), from the beginning of the record. The third and remaining columns contain the data
values that represent voltages, currents, and status information. Successive samples are separated by carriage return
and line feed.
6.3.4 Format of Data Values
The data values shall be represented in the integer format of six digits (I6) separated by commas. Missing values shall
be represented by 999999. Status information (I1) shall be represented by ones and zeroes.
6.3.5 End of File Mark
An ASCII End of File (EOF) marker (‘1A’ HEX) shall be placed immediately following the carriage return/line feed
(〈CR,LF〉) of the last record of the file.
6.3.6 Example Data Sample
Fig 4 shows an example data sample as specified in this standard. It is extracted from the example configuration file in
6.2.4 and has four analog values and two status values.
If all the data values do not fit on the same line, they shall be continued without carriage return/line feed. The last value
shall be terminated with carriage return/line feed. The next line begins with the sample number and or the next data set.
Figure 4— Example of Data Sample
6.4 Preparation of Fault Data Diskettes
6.4.1 Format
The transient data diskettes shall be in an IBM PC2 compatible MS DOS format as described in [B2].
All three file types are in the ASCII format.
6.4.2 File Creation
The header and text files shall be created in ASCII format using whatever editors and word processors are preferred.
Many word processors convert files to an ASCII format for export purposes.
The data files will be generated by a software program not described in this document. If the data does not fit in a single
file (due to floppy diskette storage limitations), then multiple data files will need to be created.
6.4.3 File Transfer
All files will be in ASCII format and may be transferred to the diskettes using editors, word processors, software
utilities, or the standard MS DOS COPY command.
Multiple data files for a single transient will need to be combined into a single file after transfer.
6.5 Binary Data Files
Binary data files are desirable in some applications and can be accommodated in the COMTRADE standard. If binary
data files are to be used, a suitable program to convert the binary file to the COMTRADE ASCII format must
accompany the binary data file.
2®IBM PC is a registered trandemark of IBM Corporation.

®
MS DOS is a registered trademark of Microsoft Corporation.
The ft field defined in 6.2.3.7 may be used to specify a binary data file. Set ft = BINARY in this field. The binary data
files shall use the same structure as that used for the ASCII data files: each data sample record will consist of 16 bit
integers arranged as follows:
n tt A 1 A2······Ak D1 D2······Dm
where:
n= sample number, in four bytes

tt= sample time in &macro;s, in four bytes
A1
· = analog sample values in two bytes for each channel
Ak
D1
· = status values of 16 digital inputs in each 16 bit word
Dm
NOTES:
1 — The least significant bit of a word is assigned to the smallest input channel number belonging to that group of 16 channels.
Thus, bit 0 of D 1 is the status of digital input number 1, while bit 1 of D2 is the status of digital input number 18.
2 — In storing a word, the low byte of the word is stored first, then the high byte.
3 — Missing data in a binary file is represented by FFFF.
7. Sample File
This section includes copies of three sample files: the header, the configuration, and the data file recorded at a utility
substation. The files are recorded in ASCII. The header file, named SASKO1.HDR, the configuration file, named
SASKO1.CFG, are alphanumerical in nature, and the data file, named SASKO1.DAT, contains numerical information.
7.1 SASKO1.HDR
Saskatchewan Power Corporation

2025 Victoria Avenue
Regina Sask.
Canada S4P 0S1
Currents and voltages and digital outputs in this file were sampled from the Condie terminal of the 230 kV
transmission line number 907, from Condie to Popular River. The Condie switching station, P2C, is located near
Regina in the Province of Saskatchewan, Canada. The 230 kV transmission line branches into a tee at the Condie end.
On each side of the branch is a circuit breaker. The currents in the two branches are sampled and the sum of the
currents in the two branches (i.e., current in the line) is also sampled.
This case concerns a disturbance on the transmission system of the Saskatchewan Power Corporation. The type of fault
and its location are not known. The parameters of the system element on which the fault was experienced and the
source impedances are, therefore, not known.
The operating conditions that existed immediately prior to the occurrence of the disturbance were not recorded.
However, six cycles of predisturbance data are recorded in this file, and the operating conditions can be calculated
from that data.
The disturbance occurred on 1983-04-13 at 13:53:23 hours.
Six cycles of pretransient data and eight cycles of post-transient data are on the file. In total, there are fourteen cycles
of data recorded on the file.
Data samples have been obtained at 480 Hz.
Anti-aliasing filters used for recording this data were second-order Butterworth filters that have a cutoff frequency of
180 Hz.
No mimics were used in this case.
All data is recorded as offset binary integers with 0 corresponding to −10 V and 4096 corresponding to +9.995 V. Data
is recorded in the format I6. Data is separated within each record by a comma.
Columns three through six contain the sampled values of the measured sum of the currents in the two branches.
Columns seven through ten contain the sampled values of the measured currents in one of the branches of the tee.
Columns 11 through 14 contain the sampled values of the measured currents in the other branch of the tee. In each
case, three phase currents and the sum of the three phase currents (representing the 3I0 current) are sampled. Columns
15 through 17 contain sampled values of the measured phase voltages. The sampled values of the measured power are
recorded in column 18. This totals 16 channels of analog data. The status of 16 event channels is also recorded. The
event channels monitor the flags on relays associated with the line. The time skew of recording within each data set is
not known and is set to zero. The nature of data in each column and the scaling factor for each operating parameter is
as defined in the configuration file.
7.2 SASKO1.CFG
CONDIE, 230 <CR, LF>

32, 16A, 16D <CR, LF>
1,RC1 CURRENT,A,907,A,.7808,0.,0.,0,4096<CR,LF>
2,RC1 CURRENT,B,907,A,. 7808,0.,0.,0,4096<CR,LF>
3,RC1 CURRENT,C,907,A,. 7808,0.,0.,0,4096<CR,LF>
4,RC1 CURRENT,N,907,A,.7808,0.,0.,0,4096<CR,LF>
5,AC4 CURRENT,A, 907,A,.7808,0.,0.,0,4096<CR,LF>
6,AC4 CURRENT,B,907,A,.7808,0.,0.,0,4096<CR,LF>
7,AC4 CURRENT,C,907,A,. 7808,0.,0.,0,4096<CR,LF>
8,AC4 CURRENT,N,907,A,. 7808,0.,0.,0,4096<CR,LF>
9,BC4 CURRENT,A,907,A,. 7808,0.,0.,0,4096<CR,LF>
10,BC4 CURRENT,B,907,A,.7808,0.,0.,0,4096<CR,LF>
11,BC4 CURRENT,C,907,A,. 7808,0.,0.,0,4096<CR,LF>

12,BC4 CURRENT,N,907,A,.7808,0.,0.,0,4096<CR,LF>
13,P VOLTAGE,A,907,kV,.0559,0.,0.,0,4096<CR,LF>
14,P VOLTAGE,B,907,kV,.0559,0.,0.,0,4096<CR,LF>
15,P VOLTAGE,C ,907,kV,.0559,0. ,0. ,0,4096<C R,LF>
16, TRANSDUCER POWER,,,MW,0.100,0.,0.,0,4096<CR,LF>
17,BR 2I-1 907L,0 <CR, LF>
18,R 2IN-1 907L,0 <CR, LF>
19,Y 2IN-1 907L,0 <CR, LF>
20,B 2IN-1 907L,0 <CR,LF>
21,Z1 INST 2IN-1 907L,0 <CR,LF>
22,Z2 START 2IN-1 907L,0 <CR, LF>
23,Z3 START 2IN-1 907L,0 <CR, LF>
24,Z2 TIMED 2IN-1 907L,0 <CR, LF>
25,Z3 TIMED 2IN-1 907L,0 <CR,LF>
26, PST 2I-1 907L,0 <CR,LF>
27, 94-IR 907L,0 <CR,LF>
28, 94-IY 907L,0 <CR,LF>
29, 94-1B 907L,0 <CR,LF>
30, 85-2 907L,0 <CR,LF>
31, 79X-1 907L,0 <CR,LF>
32, 77A-I 907L,0 <CR, LF>
60 <CR,LF>
1 <CR,LF>
480, 200 <CR, LF>
04/13/83,13:53:22.900000 <CR,LF>
04/13/83,13:53:23.000000 <CR,LF>
ASCII <CR,LF>
7.3 SASK01.DAT
1, 0, 002090, 001827, 002092, 002044, 002024, 002052, 002052,

002040, 002260, 001807, 002056, 002040, 000663, 003422, 002054, 001052,
0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, CR,LF
2, 002083, 002244, 001936, 001918, 002044, 002026, 002038, 002060,
002042, 002302, 001957,········
0, 0,········
········
····
··
·
·
0, 0, 0, 0, 0, 0, 0, CR,LF
Annex A Bibliography
(Informative)
[B1] “Digital Protection Techniques and Substation Functions,” Final report, CIGRE Working Group 34.01, A.G.
Phadke (Convener), France, June 1989.
[B2] Duncan, R. Advanced MS DOS, Microsoft Press, 1986.
[B3] “Programs for Digital Signal Processing,” Edited by DSP Committee of the IEEE ASSP Society, 0-87942-128-
2, IEEE Press, 1979.
Annex B Program for Sampling Frequency Conversion
(Informative)
C PROGRAM CONVERT
C CONVERTS SAMPLES TAKEN AT ONE RATE TO A SECOND
C RATE
C USER SUPPLIED FILTER IS IN FOR020.DAT
C DATA IS IN FOR021.DAT
C OUTPUT IS IN FOR025.DAT
C
C NFMAX = THE MAXIMUM LENGTH OF THE FILTER
C
PARAMETER NFMAX = 3600
C 3600 CORRESPONDS TO ONE CYCLE
C
C LFAC = THE NUMBER OF TENTHS OF A DEGREE BETWEEN
C SAMPLES IN INPUT
PARAMETER LFAC=50
C FSAMP=THE INPUT SAMPLING FREQUENCY
PARAMETER FSAMP = 4320
C NSIZE = THE MAXIMUM LENGTH OF THE INPUT DATA
C STRING
PARAMETER NSIZE = 720
INTEGER*2 DBUF (NSIZE)
DIMENSION HFIL (NFMAX),ZTD1 (NFMAX)
338
DATA N0/0/
C
C GET FILTER RESPONSE
READ (20,*) NA, NB
IF (NB.LE.NFMAX) GO TO 6
WRITE (6, 5)
5 FORMAT(3X, ‘DECIMATION FILTER IS TOO LONG’)
STOP
C
6 NBF=NB / LFAC
IF(NB.EQ.NBF*LFAC) GO TO 10
WRITE (6, *) ‘FILTER LENGTH INDIVISIBLE BY LFAC’
STOP
C
10 READ(20,*) (HFIL(JJ),JJ=1,NB)
C
C
C***********************************************
C
C
C
C WRITE (6, 18)
18 FORMAT(1H$, ‘ENTER TOTAL NUMBER OF SAMPLES TO BE
$ PROCESSED’ )
READ ( 6, * ) ITIME
C
READ (21, *) (DBUF (JJ) , JJ=1, ITIME)

IPTR=1
C
30 WRITE (6, 35)
35 FORMAT(1H$, ‘ENTER THE DESIRED PROCESSING RATE’)
READ ( 6, * ) DRATE
MFAC=IF IX (FSAMP *LFAC/DRATE )
IF (MFAC*DRATE.EQ.FSAMP*LFAC) GO TO 40
C
WRITE (6, *) ‘RATE IS UNACHIEVABLE—TRY AGAIN’
GO TO 30
C
WRITE (6, *) ‘ INTERPOLATION FACTOR = ‘ , LFAC
WRITE (6, *) ‘DECIMATION FACTOR =’ ,MFAC
C****************************************
C
DO 500 I=1, ITIME
DT=(I-10/4320
X=FLOAT (DBUF (IPTR))
WRITE (26, *) DT, X
C
C
DO 120 J=I,NBF-1
INDX=NBF+I-J
120 ZTD1 (INDX)=ZTD1 (INDX-1)
ZTD1 (1) =X
C
C
NO=NO +LFAC
IF (N0.LT.MFAC) GO TO 500
C
NO=NO−MFAC
C
ZOUT=0.
DO 130 J=1,NBF
INDX=J*LFAC-N0
130 ZOUT=ZOUT+HFIL(INDX)*ZTD1(J)
ZOUT= ZOUT / F SAMP
WRITE (25,*) DT, ZOUT
C
500 CONTINUE
STOP
END
C***************************************
PROGRAM FIR
C***************************************
C IMPULSE INVARIANT DESIGN FOR SECOND ORDER
C LOW PASS FILTER WITH REAL POLES AT -S1 AND -S2
C
C TRANSFER FUNCTION = A*Si*S2/(S+S1)(S+S2)
C
C SAMPLING RATE OF 216000 AT 60 HZ
C 180000 AT 50 HZ
C
C ONE CYCLE DURATION FINITE IMPULSE RESPONSE FILTER

C OBTAINED BY WRITING THE PARTIAL FRACTION
C EXPANSION OF THE TRANSFER FUNCTION AND FORMING
C THE IMPULSE RESPONSE IN THE FORM
C H (T) =SUM{CI*EXP (-SI*T) }
C***************************************
C
DIMENSION H(3600)
S1=394.
S2=2620.
C MAKE GAIN AT 60 HZ = 1
C G60=INVERSE OF THE 60 HZ GAIN
C
G60=(SQRT((Sl**2+(377)**2)*(S2**2+(377)**2)))/(Sl*S2)
C1=G60*S1*S2/(-S1+S2)
C2=G60*S1*S2/(S1-S2)
WRITE (20, *) 1, 3600
C
DO 100 I=1,3600
DT= (I-l)/21600
H (I) =C1*EXP (-DT* S 1) +C2*EXP (-DT*S2)
WRITE (20, *) H (I)
100 CONTINUE
STOP
END
Annex C Data and File Structure
(Informative)
A file is a set of related records treated as a unit and stored in some form of computer memory. Each file has a name
that is used to gain access to the data stored in the file. This section describes some of the ways data is stored in files.
C.1 File Codes
Data is stored in files as a series of binary bits. Each bit can be either a 1 or a 0. The bits are organized in groups of eight
bits called bytes. When a computer reads the data in a file, it reads the data as a series of bytes.
A1.1 Binary Data
The eight bits in a byte represent 256 possible combinations. They can be used, therefore, to represent the numbers
from 0 to 255. If larger numbers are needed, several bytes can be used to represent a single number. For example, 2
bytes (16 bits) can represent the numbers from 0 to 65535. When the bytes are interpreted in this fashion, they are
known as binary data.
A1.2 ASCII Data
As an alternative to a byte representing the numbers 0 to 255, it could be used to represent 255 different symbols. The
American Standard Code for Information Interchange (ASCII) is a standard that lists symbols that match 127 of the
combinations of 8 binary bits. For example, the byte 01000001 represents an “A"while 01100001 represents an “a.”
With 127 different combinations, it is possible to represent all of the keys on the keyboard plus many other special
symbols. To represent a number in ASCII format requires one byte for each digit of the number. COMTRADE uses
ASCII data format.
C.2 Categories of Files
There are three rudimentary forms of files used on computer systems. The use of the file determines the category.
These categories are summarized as executable files, text files, and data files.
A2.1 Executable Files
Executable files contain a sequence of instructions suitable for processing by a computer. Computer programs are
stored in executable files. There are no executable files used by COMTRADE.
A2.2 Text Files
Text files generally consist of bytes representing “ASCII” data (see Section A1) in which each byte represents a letter,
number, or symbol (e.g., A or 3 or +). Text files generally imply data in the form of words and sentences readable by
a person.
A2.3 Data Files
Data files may contain either numerical or textual data. The numerical data can be stored as either binary or ASCII
data. Binary data is generally used when large amounts of data are to be stored because it uses less storage space (e.g.,
3 bytes of binary data can represent numbers from 0 to 16,777,215 whereas 3 bytes of ASCII data can represent the
numbers from 0 to 999). ASCII numbers have the advantage that they can be directly examined by standard computer
hardware and software. Binary numbers must be processed by application-specific software to be meaningful. All
numbers in COMTRADE are stored in ASCII format.
C.3 Types of Files
There are 2 different methods used to access text and data files. The bytes in the file can either be accessed in random
sequence or in sequential order.
A3.1 Random Access Files
Random access files are types of files in which the data records can be retrieved or stored in any random sequence. The
access time for each record is independent of the location of the data. Each data record has a specific address that can
be used for reading or writing. Random access files are not used in COMTRADE.
A3.2 Sequential Files
Sequential files are accessed by reading or writing each data record in sequence. All COMTRADE files are sequential.

Ieee Standard Common Format For Transient Data Exchange Comtrade

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ieee Standard Common Format For Transient Data Exchange Comtrade

Uploaded by

Copyright:

Available Formats

IEEE C37.

IEEE Standard Common Format for

Approved June 27, 1991

The Institute of Electrical and Electronics Engineers, Inc.

Comments on standards and requests for interpretations should be addressed to:

Secretary, IEEE Standards Board

M. G. Adamiak D. C. Dawson M. Lefrancois

B. Bozoki J. W. Ingleson H. S. Smith

J. C. Appleyard J. L. Blackburn H. J. Calhoun

Marco W. Migliaro, Chair

Dennis Bodson Donald N. Heirman Lawrence V. McCall

2. Sources of Transient Data ...................................................................................................................................1

2.1 Digital Fault Recorders .............................................................................................................................. 1

3. Data Exchange Medium......................................................................................................................................2

3.1 Introduction ................................................................................................................................................ 2

4. Data Exchange Sampling Rates ..........................................................................................................................3

4.1 Introduction ................................................................................................................................................ 3

5. Files for Data Exchange ......................................................................................................................................7

5.1 Header File (xxxxxxxx.HDR).................................................................................................................... 7

6. Organization of Transient Data...........................................................................................................................8

6.1 Header Files ............................................................................................................................................... 9

7. Sample File .......................................................................................................................................................15

7.1 SASKO1.HDR ......................................................................................................................................... 15

Annex A (Informative) Bibliography ...........................................................................................................................18

Annex B (Informative) Program for Sampling Frequency Conversion........................................................................19

Annex C (Informative) Data and File Structure............................................................................................................22

1.2 Need for a Common Format

2. Sources of Transient Data

There are several possible sources of transient data for exchange.

2.1 Digital Fault Recorders

2.2 Analog Tape Recorders

2.3 Digital Protective Relays

2.4 Transient Simulation Programs

2.5 Analog Simulators

3. Data Exchange Medium

2 Copyright © 1991 IEEE All Rights Reserved

3.2 Recommended Medium

4. Data Exchange Sampling Rates

4.2 Sampling Process Structure

Copyright © 1991 IEEE All Rights Reserved 3

Figure 1— Typical Signal Processing

Figure 2— DSP Solution

4 Copyright © 1991 IEEE All Rights Reserved

Figure 3— Example of Sample Bate Conversion

Table 1— Frequencies Corresponding to fLCM= 384 × fbase

Copyright © 1991 IEEE All Rights Reserved 5

Table 2— Frequencies Corresponding to fLCM = 3200 × fbase

Given the sequence y(n), it is possible to recover x(n) with

6 Copyright © 1991 IEEE All Rights Reserved

5. Files for Data Exchange

5.1 Header File (xxxxxxxx.HDR)

5.2 Configuration File (xxxxxxxx.CFG)

5.3 Data File (xxxxxxx.DAT)

Copyright © 1991 IEEE All Rights Reserved 7

A detailed description of the data file format is given in Section 6..

6. Organization of Transient Data

1) Textual descriptions of the circumstances surrounding the transient

To be compatible with CIGRE, the following file types are required:

8 Copyright © 1991 IEEE All Rights Reserved

6.1 Header Files

1) Description of the power system prior to disturbance

1) The format in which the data is recorded

6.2 Configuration Files