TUTORIAL ON TRANSIENT DATA RECORDS

SOFTSTUF, INC
Preface
This book is a tutorial on event files, serial communications, and substation integration.
Chapters 1 through 3 focus on event files. The included topics are standard and proprietary
event formats, COMTRADE format, file saving schemes, and file naming schemes. Chapter 4
discusses managing and viewing event files; it describes the need for a universal event file
manager and addresses the memory issues related to storing event files. Chapter 5 focuses on
serial communications; it introduces a novel approach to integrating and controlling
microprocessor based equipment in the substation.

The tutorial is not intended to make you an expert but to familiarize you with the process of
retrieving, saving, naming, managing, and viewing event files.
Table of Contents

CHAPTER 1 - EVENT FILES ......................................................................................................... 1

1.1 Background ......................................................................................................................... 1
1.2 Files..................................................................................................................................... 1
1.3 Event File Types .................................................................................................................. 2

CHAPTER 2 - COMTRADE ....................................................................................................... 5

2.1 Introduction ......................................................................................................................... 5
2.2 Overview ............................................................................................................................. 5
2.3 Applications......................................................................................................................... 8
2.4 Troubleshooting ................................................................................................................... 8
2.5 Compatibility ....................................................................................................................... 8

CHAPTER 3 - EVENT FILE NAMING SCHEMES ............................................................................ 9

3.1 Introduction ......................................................................................................................... 9
3.2 Filenames ............................................................................................................................ 9
3.3 Coding Schemes ................................................................................................................ 10
3.4 Naming An Event File ....................................................................................................... 11
3.5 Naming Formats ................................................................................................................ 12
3.6 Compatibility ..................................................................................................................... 13

CHAPTER 4 - MANAGING & VIEWING EVENT FILES ................................................................ 14

4.1 Event Manager................................................................................................................... 14
4.2 Event Viewer ..................................................................................................................... 15
4.3 Memory Issues................................................................................................................... 16

CHAPTER 5 - SERIALLY ACCESSED DEVICES............................................................................ 18

5.1 Introduction ....................................................................................................................... 18
5.2 Serially Accessed Device Types......................................................................................... 19
5.3 Integration ......................................................................................................................... 21
5.4 Control............................................................................................................................... 23
5.5 Benefits ............................................................................................................................. 28

Figures & Tables

FIGURE 1.1 COMTRADE ASCII FORMAT .............................................................................................. 3
FIGURE 1.2 COMTRADE BINARY FORMAT ............................................................................................ 3
FIGURE 1.3 PROPRIETARY ASCII FORMAT .............................................................................................. 4
FIGURE 1.4 PROPRIETARY BINARY FORMAT............................................................................................ 4
TABLE 3.1 OPERATING SYSTEM FILE NAMING FORMATS ...................................................................... 10
FIGURE 4.1 EVENT FILE MANAGER ....................................................................................................... 14
FIGURE 4.2 EVENT FILE DISPLAY .......................................................................................................... 15
FIGURE 4.3 UNIVERSAL DISPLAY INTERFACE ........................................................................................ 16
TABLE 4.1 COMPRESSION PROGRAM PERFORMANCE............................................................................. 16
TABLE 4.2 COMPRESSION PROGRAM PERCENT REDUCTION (%0 MEANS NO REDUCTION) ...................... 17
FIGURE 5.1 SUBSTATION DATA CONCENTRATOR .................................................................................. 20
FIGURE 5.2 NETWORK TOPOLOGIES ...................................................................................................... 22
FIGURE 5.3 SINGLE LINE DIAGRAM ....................................................................................................... 24
FIGURE 5.4 PERIODIC POLLING & DISPLAY ........................................................................................... 26
FIGURE 5.5 CONTROL MENUS ............................................................................................................... 27
 Chapter 1 – Event Files

C H A P T E R 1

Event Files
Event files or digital fault records of power system abnormalities are generated from recording
and measurement devices within Substations. Digital fault recorders (DFR’s), sequence of
events recorders (SER’s), transformer monitors, and relays capture, archive, and transmit data to
remote locations for analysis. Event files are saved in various formats depending on the type and
manufacturer of the recording device. A standard format for saving event files called Common
Format for Transient Data Exchange (COMTRADE) is gaining popularity among equipment
operators and manufacturers. This chapter provides a survey of the commonly used formats for
saving event files.

1.1 Background
Digital data exists in the form of bits and bytes. These bits and bytes are stored using various
types of data storage mediums such as magnetic, optical, magneto-optical, flash, or holographic
memory. Regardless of the type of storage, medium storage devices can be partitioned into
multiple partitions or drives. Each partition is a separate storage device and can be formatted
independently. A drive is formatted by the operating system software in order to organize data
into files, files into directories, and directories into hierarchical structures.

There are several types of data storage formats or file systems that are commonly used for
personal computers (PC’s). These file systems include and are not limited to the file allocation
table (FAT12, FAT16 and FAT32) formats, and the NT File System (NTFS) format. FAT16 is
the most common format and is installed in the majority of currently available PC’s. Under the
FAT format, the memory on a given drive is divided into tracks and tracks are divided into
sectors. Typically, there are 512 bytes of data allocated per sector.

1.2 Files
Files are assigned filenames and saved in groups of allocation units called clusters. A cluster is a
group of sectors. The cluster size varies from 4 to 64 sectors per cluster, and it is the smallest
block of memory that is allocated by the operating system for saving files. The assigned
filenames are recorded separately in a system file called the FAT file. Each filename entry in the
FAT file is tagged with a set of special attributes plus a 32 bit address pointer to define the
starting location of the file contents on the drive. The special attributes include “A” for archive,
“R” for read-only, and “H” for hidden. A filename is composed of two parts. The first part of
the filename is the name and the second part is the extension. The extension is normally used to
specify the type of the file contents such as “.EXE” for executable file and “.DOC” for document
file. In general, the data contents of a file are either the American Standard Code for Information
Interchange (ASCII) format or the binary format, which uses an 8 bit numeric grouping.

1
 Chapter 1 – Event Files

ASCII files are viewed by using an ASCII editor such as the DOS EDIT or the Windows
NOTEPAD programs. Binary files are viewed by using a hexadecimal editor such as the Norton
Utilities editor. The order in which ASCII or binary bytes are saved and the meaning of each
byte is usually defined in the software documentation or user manuals and is specified as the file
format. The format of a given file is either standard or proprietary. There are many different
types of standard and proprietary formats. The fixed ASCII format, the comma delimited
format, the drawing exchange format (DXF) and the COMTRADE ASCII format are examples
of standard ASCII file formats. The executable program format, the bit-mapped file format, and
the COMTRADE binary format are examples of standard binary file formats. The REL, SEL,
and DLP relay data formats are examples of proprietary ASCII file formats and the DFR, PMU,
and RTU data formats are examples of proprietary binary file formats.

1.3 Event File Types

Event files are classified as either standard or proprietary, ASCII or binary. There is only one
commonly used standard format for saving event files in ASCII or binary form. The standard is
the IEEE C37.111 COMTRADE. Although the majority of the current microprocessor based
substation devices are not naturally compatible with the COMTRADE format; this standard is
gaining popularity among manufacturers and equipment operators. Figure 1.1 shows an example
of the standard COMTRADE ASCII format and figure 1.2 shows an example of the standard
COMTRADE binary format. There are also many proprietary ASCII and binary event file
formats produced by many different manufacturers. Proprietary formats vary depending on the
type and manufacturer of the originating equipment. Figure 1.3 shows an example of a
commonly used proprietary ASCII format from a relay and figure 1.4 shows an example of a
proprietary binary format from a DFR.

The data for a specific event or for multiple events may be saved in one file or in multiple files.
In other words, event files and event occurrences have a many to many relationship. The
COMTRADE format, for example, defines three files per event as shown in figures 1.1 and 1.2.
The three files share the same name but have different extensions: “.HDR”, “.CFG”, and
“.DAT”. The first file is the header file. This header file contains general information about the
event such as the type and manufacturer of the recording device and the operator comments. The
second file is the configuration file. The configuration file contains specific information such as
substation name, fault data and time, number of analog and digital channels, scale values,
sampling frequencies, etc.. The third file is the data file and it contains the event data. In
another format, the data for multiple events is saved in one file. Such files originate from certain
types of relays in response to a “HIS” or “EVE” command as shown in figure 1.3. Other
proprietary file formats use hidden files to hold the header and configuration information. Such
files originate from certain types of DFR equipment in response to a fault occurrence or an
external trigger as shown in figure 1.4.

2
 Chapter 1 – Event Files

Figure 1.1 COMTRADE ASCII Format

Figure 1.2 COMTRADE Binary Format

3
 Chapter 1 – Event Files

Figure 1.3 Proprietary ASCII Format

Figure 1.4 Proprietary Binary Format

4
 Chapter 2 – COMTRADE

C H A P T E R 2

COMTRADE
The COMTRADE format is used by various devices to aid engineers in the analysis, testing, and
simulation of the power system during fault and disturbance conditions. The format is gaining
popularity among many power utilities and manufacturers. COMTRADE files that are generated
by different programs are not always exchangeable and in some cases troubleshooting is
necessary. This chapter provides a brief description of the COMTRADE format. It also
addresses simulation and analysis applications, and offers methods for troubleshooting
compatibility problems.

2.1 Introduction
Digital records of power system abnormalities are generated or captured by various recording,
measurement, and control devices within substations. A large number of these records can be
generated during a storm or during routine testing, switching, and maintenance operations.
Digital records can also be generated by devices that simulate and model power systems.
There are many formats for storing digital records on computer disks. The format for a given
record is usually defined by the manufacturer of the originating device. Each manufacturer
provides their own computer programs to process records that are generated by their own
devices. The users of digital records are faced with the problem of having to learn how to
operate multiple programs in order to handle records that are generated by various devices. The
problem is amplified by the fact that the users can not use all of the available programs while
inspecting a specific record. They can only use those programs that are compatible with the
format of the record being inspected.

In 1991, recognizing that a common format for saving digital records was needed to enhance
compatibility across programs and between users, members of the IEEE Power Engineering
Society developed the IEEE C37.111 Standard Common Format for Transient Data Exchange
(COMTRADE). This standard was defined in order to facilitate the physical exchange of digital
records as data files that are saved on computer disks. Today, the standard is popular among
users of digital records and a growing number of computer programs that support this standard
are being introduced. An overview of the standard is presented in the next section.

2.2 Overview
A digital record that is saved in COMTRADE format consists of three files. The files are header,
configuration, and data. Each one of these files contains a separate class of information and has
a standard filename extension, however, all of these files have the same filename name. A brief
description for each of these files is included in the next paragraphs.

5
 Chapter 2 – COMTRADE

The header file is an ASCII text file that is manually created from a text editor. The header
filename is designated by the “.HDR” extension and there is no specific format for arranging the
file contents. The file contents may contain any description or analytic observation about the
digital record. The header file is only useful to the user and not processed by application
programs. An example of the header file is shown in figure 2.1.

Waveform Information:
Station: EXAMPLE STATION NO. 1 DAU 32 N
Prefault-Time: 01/18/1992 10:02:02.191
Fault-Time: 01/18/1992 10:02:02.270
Save-Time: 06/28/1995 02:35:12
Process-Time: 04/07/1998 13:11:18

Events/Sensors Activity Summary:

> Fst Lst Fst-Change Lst-Change Changes Description
N N 10:02:02.279 10:02:02.321 016 1-PCB 1216 EXAMPLE 1
N A 10:02:02.321 10:02:02.352 003 2-PCB 1226 EXAMPLE 2
N N 10:02:02.262 10:02:02.643 006 5-161KV BUS POTENTIAL UV
N N 10:02:02.265 10:02:02.325 002 6-161KV BUS POTENTIAL UF
N N 10:02:02.374 10:02:02.375 001 8-DATA CHECKSUM ERROR N/C

Figure 2.1 COMTRADE .HDR File

The configuration file is an ASCII text file that is automatically created by a computer program.
The filename is designated by the “.CFG” extension and the file contents are arranged into four
formatted sections. The first section defines the station name, recording device identification
number, and total number of analog and digital input channels in the digital record. The second
section is a list of analog information that defines the title, unit, scale value, maximum value, and
minimum value for each of the analog input channels. The third section is a list of digital
information that defines the title and original state for each of the digital input channels. Finally,
the fourth section defines the line frequency, sampling rate, number of samples, time of first
sample, time of trigger point, and file type (ASCII or binary) for the data file. An example of the
configuration file is shown in figure 2.2.

The data file is either an ASCII text file or a compressed binary file that is automatically created
by a computer program. The data filename is designated by the “.DAT” extension and the file
contents are the actual data values of the input channels in the digital record. The contents are
formatted as a table of sample values. Each row in the table contains a set of values that are
separated by commas. The first two values in the set are the row number and the time at which
the set was recorded. The remaining values are the sample values for each of the analog and
digital input channels in the record. An example section of an ASCII data file is shown in figure
2.3.

6
 Chapter 2 – COMTRADE

EXAMPLE STATION NO. 1 DAU 32 N,32

15,7A,8D
1,161KV 01-G BUS POTENTIAL,,,kV, 0.479615,0.0,0.0,-511,511
2,161KV 02-G BUS POTENTIAL,,,kV, 0.479615,0.0,0.0,-511,511
3,161KV 03-G BUS POTENTIAL,,,kV, 0.479615,0.0,0.0,-511,511
4,161KV 01 CURRENT,,, A, 43.187479,0.0,0.0,-511,511
5,161KV 02 CURRENT,,, A, 43.187479,0.0,0.0,-511,511
6,161KV 03 CURRENT,,, A, 43.187479,0.0,0.0,-511,511
7,161KV RES CUR.,,, A, 43.187479,0.0,0.0,-511,511
1,PCB 1216 EXAMPLE,1
2,PCB 1226 EXAMPLE,1
3,PCB 1236 EXAMPLE,1
4,161KV CAR. REC,1
5,161KV BUS POTENTIAL UV,1
6,161KV BUS POTENTIAL UF,1
7,EXTERNAL START,1
8,DATA CHECKSUM ERROR N/C,0
60
1
5184,47
01/18/1992,10: 2: 5.136
01/18/1992,10: 2: 5.215
ASCII

Figure 2.2 COMTRADE .CFG File

1,192,252,-233,-19,0,0,0,0,1,1,0,1,1,1,1,0
2,384,243,-243,0,0,0,0,0,1,1,0,1,1,1,1,0
3,576,232,-252,20,0,0,0,0,1,1,0,1,1,1,1,0
4,768,220,-260,40,0,0,0,0,1,1,0,1,1,1,1,0
5,960,207,-267,60,0,0,0,0,1,1,0,1,1,1,1,0
6,1152,192,-273,79,0,0,0,0,1,1,0,1,1,1,1,0
7,1344,176,-276,98,0,0,0,0,1,1,0,1,1,1,1,0
8,1536,160,-279,117,0,0,0,0,1,1,0,1,1,1,1,0
9,1728,142,-280,135,0,0,0,0,1,1,0,1,1,1,1,0
10,1920,124,-279,153,0,0,0,0,1,1,0,1,1,1,1,0
11,2112,105,-277,171,0,0,0,0,1,1,0,1,1,1,1,0
12,2304,85,-274,187,0,0,0,0,1,1,0,1,1,1,1,0
13,2496,65,-269,203,0,0,0,0,1,1,0,1,1,1,1,0
14,2688,45,-263,218,0,0,0,0,1,1,0,1,1,1,1,0
15,2880,25,-255,231,0,0,0,0,1,1,0,1,1,1,1,0
16,3072,5,-246,243,0,0,0,0,1,1,0,1,1,1,1,0
17,3264,-16,-235,253,0,0,0,0,1,1,0,1,1,1,1,0
18,3456,-36,-223,262,0,0,0,0,1,1,0,1,1,1,1,0
19,3648,-56,-210,269,0,0,0,0,1,1,0,1,1,1,1,0
20,3840,-76,-196,276,0,0,0,0,1,1,0,1,1,1,1,0
Figure 2.3 COMTRADE .DAT File

7
 Chapter 2 – COMTRADE

2.3 Applications
The COMTRADE standard has a number of useful applications. The ability to process digital
records that are generated from separate types of recording devices using the same program is
key among the useful applications of this standard. Using the COMTRADE format,
manufacturers of recording equipment can concentrate on the business of manufacturing
recorders without having to develop the computer programs to process and display their digital
records. Such programs can be written independent from the manufacturers by other companies
that specialize in software development.

Other useful applications of the COMTRADE format are in simulation and modeling of the
power system under fault and disturbance conditions. Data derived from power system models
or actual recorded events can be used to drive test equipment thus providing the early detection
of possible protection inadequacies that may lead to equipment misoperation. For example, a
digital record of a transient event can be reproduced into a relay in order to study the relay
response for that class of transient event. In addition, digital records can also be interactively
created using fault modeling computer programs. Computer made digital records can be used to
mimic severe, critical or abnormal power system transient conditions.

2.4 Troubleshooting
The COMTRADE standard is not free of problems. COMTRADE records that are created by
one program can not always be read by another program. The problem appears when multiple
interpretations of the format occur. For example, some programs require that the date be
formatted to 8 characters (i.e.: 04/07/98) while other programs may create the date with 6
characters (i.e.: 4/7/98). Computer programs are sensitive to variations in numeric formats,
occurrences of empty spaces, and use of reserved separators in textual fields.

In general, the majority of the problems in exchanging a record between programs could be
solved by using a text editor to adjust the contents of the record configuration file. The best way
to troubleshoot these problems is to compare side by side the contents of the configuration file of
the problematic record with the contents of the configuration file of a valid record. In certain
cases, the data file contents of the problematic record could require adjustment. In those cases,
the ASCII type data file is adjusted using a text editor and the compressed binary type data file is
adjusted using a hexadecimal editor.

2.5 Compatibility
Standards are revised. In fact, the COMTRADE standard format was recently revised. When
standards are revised compatibility issues emerge. There are many parameters that effect
compatibility. The main concern is that some revisions may impose additional requirements that
produce compatibility problems and require substantial programming support. To be on the safe
side, programs developed to support COMTRADE should not impose restrictions on the
maximum and minimum lengths of data fields. The current standard specifies a comma as the
main separator between consecutive data fields. Such formats are very flexible in that the
minimum or maximum length of a data field does not have to be predefined. The length of the
field is simply measured as the distance between two consecutive comma separators.

8
 Chapter 3 – Event File Naming Schemes

C H A P T E R 3

Event File Naming Schemes

A number of techniques are available for assigning unique filenames to event files. Typical
information used for assigning such filenames originates from the affected substation, recording
device, device type, manufacturer, date, and event severity. The information used for naming
event files has to be represented in a short sequence of filename characters. There are only 52
characters available for naming files in DOS and 245 characters for Windows NT. A filename
can be up to 11 characters long in DOS, and 253 characters long in Windows NT. This chapter
provides a survey of popular formats for coding key event information into the filename.
Compatibility issues between DOS and Windows NT are also discussed.

3.1 Introduction
The set of characters that compose an event filename are essential to the computer and to the
frequent user. The event filename is the only key for both computer and user to access the event
file contents. Without friendly filenames, the frequent user has trouble handling large numbers
of files.

Programs that perform trend analysis, data archival, remote reporting, and similar applications
have to sift through and access a large number of files directly from disk. Accessing the contents
of a file directly from disk is much slower than accessing the filename of the file. The use of
filenames provides a quicker response because they are stored separately in a system file and can
be loaded into memory using a single disk access operation. Specifically, all of the filenames
stored on a given disk directory can be read using a single disk access operation, whereas,
accessing the contents of the files requires a single disk access operation per file. Therefore,
processing speed for application programs can be significantly increased by designing the
programs to read key event information from the filenames. Reading key event information
from the filenames reduces the total number of disk access operations.

The alternative to reading key event information from the filename is to develop a database of
search fields for all of the event files on disk. However, developing a database is costly and
requires a substantial programming effort.

3.2 Filenames
Filenames are used by the operating system for allocation, by the end-user for filing, and by the
application programs for processing of files. The following table contains information about
assigning filenames in Concurrent DOS (CDOS), DOS, Windows 3.x, Windows 95, and
Windows NT.

9
 Chapter 3 – Event File Naming Schemes

Operating System Total Filename Characters Filename Length

(Name + Extension)
CDOS 62 [0-9\A-Z\a-z] 11 (8+3)
DOS 52 [0-9\A-Z\+] 11 (8+3)
Windows 3.x 52 [0-9\A-Z\+] 11 (8+3)
Windows 95/98/NT 245 [0-9\A-z\+] 253 (250+3)
Table 3.1 Operating System File Naming Formats

A filename is composed of two parts. The first part of a filename is the name and the second
part of the filename is the extension. The extension is normally used to specify the type of the
file. In general, there are three different types of files. The first type is executable files such as
programs “.EXE” and dynamic libraries “.DLL”. The second type is system files such as
directories “..” and batch files “.BAT”. The third type is data files such as text “.TXT”, graphics
“.DXF”, and event files “.CFG”. Application developers and frequent users are not required to
follow the above specifications for assigning extensions and are free to invent and follow their
own rules. In fact, the user could create a file named “anything.EXE” and use it as a data file.
As long as the operating system is not asked to run the bogus executable file, no errors occur.

Filenames are listed in a system file called the allocation table (file allocation table “FAT” for
DOS, and NT file system “NTFS” for Windows NT). The allocation table is stored on disk in a
reserved area called the system area. The table can be loaded to memory directly from disk, or
can be loaded indirectly through calls to the operating system. Each entry in the table
corresponds to a single file on disk and has a filename, a list of attributes (such as “A” for
archive and “H” for hidden), and the starting address of the file contents.

3.3 Coding Schemes

Filenames are limited in size, therefore, to place the maximum amount of key event information
in the filename the information must be compressed. Compression or coding is the art of
representing a long sequence of information with a brief sequence of characters such as the
ASCII character codes. A number of data compression schemes have been documented. They
include but are not limited to run-length coding, half-byte packing, Huffman coding, dictionary
coding, and adaptive dictionary coding.

Run-length coding is a data compression technique in which repeated symbols are counted and
then replaced by the resulting count. For example, the information
CDEFFFFGGGGGGG333333333 is reduced to CDE^F4^G7^39. However, this technique does
not always work. For example, the information ABCDEFGH...XYZ-0123456789 does not
compress.

Half-byte packing is a procedure used to mask out repeated patterns in character bits. For
example, the characters 7 and 14 are represented by the bit patterns 0000-0111 and 0000-1110,
and can be packed in one byte by masking out the upper 4 bits from both characters. The
resulting byte has the bit pattern 0111-1110. However, character bits are not always repetitive
and bit manipulation is not natural for a byte based machine.

10
 Chapter 3 – Event File Naming Schemes

Huffman coding is a simple method where the probability or relative frequency of the occurrence
of each symbol in a stream of information is used to compress the information. Symbols with
highest probability are assigned to codes with shortest length. For example, since the term
“filename” appears frequently in this paper, it can be assigned the code “$” which saves 7
characters per appearance.

Dictionary and adaptive dictionary coding are compression methods similar to Huffman coding.
Instead of assigning short codes to frequent terms or phrases, terms are replaced by pointers to
their location in a dictionary or a list of unique entries. Repeated terms are reduced to repeated
pointers. In the adaptive method, repeated terms are replaced with pointers to their initial place
of occurrence. For example, PKZIP, a popular file compression program, uses a similar adaptive
technique.

The above methods are designed to compress information using the standard ASCII character
set. However, certain ASCII characters such as “, ?, /, \, <, >, *, |, and : can not be used in
naming files, therefore applying these methods could produce non-valid filenames. To eliminate
this problem an alternate code set is assigned to the ASCII characters that can be used in naming
files. The alternate code set is normally called the filename character set. In the next section, a
hybrid of the above methods is used to compress event information using the alternate filename
character set.

3.4 Naming An Event File

It is useful to code key event information (keys) into the event filename. Commonly, coded keys
are severity measure (from 0 to 9), date and time (from 1/1/1980-00:00:00.000 to 12/31/2079-
23:59:59.999), substation name (up to 24 characters), recorder type and manufacturer (up to 24
characters), and recorder number (from 0 to 9999). The worst case scenario is to compress all of
the above keys, up to 74 characters total, down to 11 filename characters in DOS. In that case,
the “/”, “-“, “:”, and “.” characters of the date and time keys are repeated symbols and can be
ignored. Thus, only 68 characters have to be compressed down to 11 DOS filename characters.

The substation name, recorder type, and recorder number keys account for 52 of the remaining
68 characters. The values remain constant for all of the event files that are generated by the
same recorder. In other words, they are repeated terms and their frequency depends on the
recorder number. They can be combined and replaced by a pointer to an entry in a dictionary or
in a list of recorders, which means, 52 of the 68 characters can be replaced with 1 pointer. Thus,
16 characters and 1 pointer have to be compressed down to 11 DOS filename characters.

A DOS filename character can be any one of 52 available codes. Clearly, the month (1 to 12),
day (1 to 31), and hour (1 to 23) keys have values that are under 52 and can be represented with
3 separate filename characters, which means, 6 of the 16 characters compress down to 3 filename
characters. Thus, 10 characters and 1 pointer have to be compressed down to 8 DOS filename
characters.

11
 Chapter 3 – Event File Naming Schemes

The minute (up to 59) and second (up to 59) can not be compressed with 2 separate filename
characters. These keys reach values, which can not be represented by the available 52 codes.
However, by utilizing the first 32 codes of the alternate code set to emulate a 5 bit register, a
filename character can be used as a register of up to 5 flags. Thus, a value of up to 104 can be
compressed down to 1 filename character and 1 flag. If the value of the key being compressed
exceeds 52, then the value minus 52 is coded and the flag is set. If the value does not exceed 52,
then the value is coded and the flag is reset. The 4 characters of the minute and second keys
compress down to 2 filename characters and 2 flags. Thus, 6 characters and 1 pointer have to be
compressed down to 5 DOS filename characters and 3 flags.

The severity measure (up to 9), year (up to 99 years from the year 1980), and millisecond (up to
999) keys compose the final 6 characters. These characters can be aligned to form 3 numbers,
each being 2 digits wide, which compresses down to 3 filename characters and 3 flags. Thus, 1
pointer has to be compressed down to 2 DOS filename characters.

Unfortunately, the pointer must be able to index up to 9999 dictionary entries. This requires 2
filename characters and 2 flags. Thus, the initial 74 ASCII characters can be compressed down
to 11 DOS filename characters and 2 flags. Therefore, one final trick is required to procure 2
more flags. Since the month and hour keys have values that are always under 26, and since the
52 codes of a filename character divide into 2 groups of 26 codes, then the month and hour keys
can be assigned to codes that are either from the lower or from the upper 26 codes. That takes
care of the 2 extra flags.

In conclusion, the 11 characters of a DOS filename do provide the space needed to compress up
to 74 characters of key event information. However, this type of compression does not normally
result in friendly filenames. The frequent user needs a program to decode and display the key
information.

3.5 Naming Formats

A number of event filename formats are in use today. These formats are organized in three
classes. The classes are called associated, coded, and sequenced. Associated means that the
filename extension defines the type of data storage format. For example, the extensions “.HDR”,
“.CFG”, “.DAT”, and “.INF” are used to indicate that the file contents are compatible with the
IEEE COMTRADE standard. The non-extension part of an associated filename, or the name, is
left at the discretion of the user and could be assigned in a coded or sequenced way.

Coded means that the filename contains some information about the event. In this case, the
storage format is usually manufacturer specific. For example, certain files that are generated
from digital fault recorders have the event date and time (up to 12/31/2079-23:59:59.99) and the
recorder number (up to 255) coded in the filename. The recorder number is coded in the first 2
characters of the name, which is friendly up to recorder number 99, and the date and time are
coded in the last 9 characters of the filename.

The sequenced filenames format is an incremental approach to naming files. The sequence may
appear in the file name or just in the extension characters. This method is valid because the

12
 Chapter 3 – Event File Naming Schemes

resulting filenames are always unique. However, the total number of files that can be saved
before the files begin to overwrite is limited by the number of characters assigned to the
sequence. If multiple recorders are used then the recorder number is also coded in the filename.
For example, some DFR files have the substation name (up to 4 characters), the event number
(up to 9999), and the channel numbers (up to 3 characters) coded in the filename. A file named
“MART1743.RCL” indicates that the event was recorded at the Martin substation and that the
event number is 1743. The “.RCL” extension means that the file contents are from the lower
group of the input channels.

3.6 Compatibility
The DOS style filenames are the most popular and the most restrictive. The 95 and NT
generation of Windows significantly relaxed the DOS restrictions. A filename can now be up to
253 characters long and the filename characters can be any one of 245 ASCII codes. DOS
filenames are compatible with NT, but NT file names are not always compatible with DOS.
Compatibility is lost either when the filename is longer than 11 characters or when any character
is assigned an ASCII value outside the 52 legal DOS codes.

It is also worth while to mention that even though NT allows upper and lower case characters in
filenames, NT itself is not case sensitive. In other words, “HELLO_MY_FRIEND.TXT” and
“hello_my_friend.txt” are the same file. In addition, NT’s NTFS naming convention is not
portable. This is mainly because it requires a system area of about 4 Mbytes in size. If saved to
a floppy disk the above file is renamed to “HELLO_^1.TXT” which follows the DOS naming
convention. If a sequence of filenames also begin with the characters “HELLO_”, then the 10th
file in the sequence is named “HELLO^10.TXT”, the 100th file in the sequence is named
“HELL^100.TXT”, and so on.

13
 Chapter 4 – Managing & Viewing Event Files

C H A P T E R 4

Managing & Viewing Event Files

Managing and viewing event files is different from managing other types of PC files. Usually,
the Windows 3.1 file manager or the NT explorer programs provide many features for managing
files (copy, move, delete, search, and so on). However, when it comes to managing or viewing
event files these programs are not so friendly and fail if used to manage certain types of DFR
records.

4.1 Event Manager

The many to many relationship of event files means that event files should be managed using an
event file manager or fault explorer program as shown in figure 4.1. The event file manager
program inspects the filenames of the directory files and infers the type and manufacturer of the
originating equipment for each file. Once the origin of a file is determined then the proper
format is loaded and all of the associated files are mapped. When the file is copied or moved all
of the mapped files are also copied or moved. In addition, the event file manager provides query
capabilities to search for specific event files based on date and time of event occurrence.

Figure 4.1 Event File Manager

14
 Chapter 4 – Managing & Viewing Event Files

4.2 Event Viewer

Viewing the contents of an event file using file manager or explorer is a difficult task. Even
though these files can be associated with ASCII and binary editors and with various
manufacturer supplied programs, it is not useful to learn a variety of proprietary programs with
various operating nuances or to view event data in ASCII or binary form as shown in figures 1.3
and 1.4. Since the event file manager has the formats for reading various types of event files
then the manager can become the display program that provides a common operator interface for
managing and viewing event files, as shown in figure 4.2. Event files originating from various
types of equipment can be viewed in the same way using a universal interface as shown in figure
4.3.

Figure 4.2 Event File Display

There are few event file managers available today and none that are available off-the-shelf. This
is due to the lack of availability of a robust standard that can induce progressive competition
among companies developing microprocessor based equipment in order to simplify the process
of handling event information. Fortunately, COMTRADE is rapidly gaining popularity and
many of the new digital fault recording and power quality measurement equipment are being
designed with COMTRADE compatibility. As these new devices replace the existing systems
and the COMTRADE format matures to a more useful and robust standard, more and more event
file managers become available.

15
 Chapter 4 – Managing & Viewing Event Files

Figure 4.3 Universal Display Interface

4.3 Memory Issues

Memory is an issue because a large number of event files can be generated during a storm,
during switching, or testing and maintenance operations. Saving large numbers of event files
requires substantial memory especially if the files have ASCII contents. In this case, the
implementation of useful compression techniques saves substantial memory. A good number of
data compression programs are widely available today. WinZip for example is the most popular.
These data compression programs are based on coding techniques that include but are not limited
to run length coding, bit packing, dictionary coding and adaptive dictionary coding. A list of off-
the-shelf data compression programs along with a qualitative measure of their performance is
shown in tables 4.1 and 4.2.

File Type File Size ARJ LHA RAR PKZIP WinZip

COMTRADE ASCII 2,382KB 405KB 410KB 457KB 414KB 461KB
COMTRADE Binary 582KB 320KB 336KB 299KB 314KB 313KB
DFR Packed 4,081KB 308KB 406KB 361KB 315KB 377KB
ASCII Event 96KB 6.9KB 7.1KB 7.5KB 7KB 7.4KB
Table 4.1 Compression Program Performance

16
 Chapter 4 – Managing & Viewing Event Files

File Type ARJ LHA RAR PKZIP WinZip

COMTRADE ASCII 83% 82.8% 80.8% 82.7% 80.6%
COMTRADE Binary 45.1% 42.3% 48.6% 46.1% 46.3%
DFR Packed 92.4% 90.1% 91.2% 92.3% 90.8%
ASCII Event 98.2% 92.6% 92.2% 92.7% 92.3%
Table 4.2 Compression Program Percent Reduction (%0 means no reduction)

There is also a limit to the total number of files that can be saved on a given drive. In many
cases, this limit is reached even if there is plenty of unused memory still available on the drive.
The reason for this limit is that the operating system allocates memory for holding files in
collections of clusters. If you save a file of size one byte then the operating system allocates one
whole cluster of available memory. Recall that the size of a cluster varies from 4 sectors (2048
bytes) to 64 sectors (32,768 bytes) which means that saving a large number of small files is a
considerable waste of memory. However, in the FAT32 file system portions of the wasted
memory can be utilized under the proper conditions for saving file contents and for temporary
use by the operating system during allocation of virtual memory

17
 Chapter 5 – Serially Accessed Devices

C H A P T E R 5

Serially Accessed Devices

A vast array of serially accessed devices can be found in the substation. Such devices may
include DFR’s , protective relays, sequence of event (SOE’s), transformer monitors, supervisory
control and data acquisition (SCADA) systems, video cameras, and other measurement and
control equipment . These devices are produced by various manufacturers each having there
own unique operating nuances. To benefit from the strength of this technology it is essential for
the user to integrate and network all serially accessed devices onto a common platform with
software capable of communicating in multiple languages or protocols. The successful
integration enables the user to access all data available in a common format. It can also be
employed to provide control capabilities for future substation automation projects. This chapter
addresses the software and hardware issues that are essential for the successful development of a
common integration and control platform for substation devices. It also presents a novel method
for providing closed loop control from animated CAD drawings.

5.1 Introduction
Today many Utilities have benefited from the introduction of microprocessor devices into the
substation environment. Utilities have replaced the light beam oscillograph with DFR’s, that are
capable of capturing, analyzing, and archiving faults more rapidly, accurately, and efficiently,
and are remotely operable. Electro-mechanical relays have given way to microprocessor relays
that clear faults faster, employ fault location algorithms, offer ocillographic capabilities, and
provide remote interrogation. Meters and monitors also have power quality functions that
provide trending abilities and can also be viewed and acted upon remotely. Data from these
devices are used to check and update system models, replay suspicious relay operations, and
used to develop better restoration procedures.

Developers of these devices have created and adhered to many distinct protocols using different
operating platforms and software packages without the benefit of an industry standard as a guide.
Due to this rapid growth and expansion of microprocessor technology within the substation new
operating deficiencies have developed. The diverse and incompatible nature of each
manufacturer that was once considered of minor consequence is now of major concern. Rising
communication costs, limited manpower resources, and expanded computer knowledge and
acceptance in the Substation environment has generated interest in a comprehensive integration
program. The dilemma or deficiencies that have developed are associated with communication,
integration and storage of data generated by and from these new microprocessor devices. The
technology to integrate and control a large array of serially accessed devices is currently
available and is cost effective. Many manufacturers are busy replacing their old stand-alone
designs for operator interfaces and control units with new microprocessor based technologies.
Developers everywhere are using desktop, laptop, palmtop and embedded computers in their
latest designs. These computers can be equipped with keyboards, mice, touch screens,
microphones, cameras, and many serial ports. It is time to explore the potential of this
technology for improving substation operations.

18
 Chapter 5 – Serially Accessed Devices

The amount of serially accessed devices in the substation is overwhelming. Relays are accessed
serially and so are digital fault recorders, cameras and motion detectors. To work with these
devices, the operator has to learn how to communicate with them. Currently each manufacturer
provides some form of interface panel or master station to operate their line of equipment. The
operator is faced with the problem of having to learn how to communicate in multiple languages.
The data recorded by substation devices is paramount for analysis and troubleshooting of the
power system. Any delays in the acquisition of such data or in the execution of control
procedures that are due to the diversity of the substation devices can be eliminated by integrating
the devices. The devices are integrated by placing a local area network in the substation and by
installing a common operator interface on the network server or control computer to allow for
communications with the various types of devices. Refer to figure 5.1.

The benefits of integrating substation devices are many. Companies can save money by
replacing port switches, phone switches, meter displays, and so on with a network. Considerable
time and manpower can be saved by having immediate access to crucial information such as
fault location and relay targets from the control computer. Device operations over long periods
of time can be tracked, trended, and analyzed by reviewing the volumes of data archives
available at the control computer. New operators can be trained quickly and control procedures
can be greatly enhanced by using a single control computer for all of the serially accessed
devices in the substation. Most importantly, the design is cost effective. Today’s high-end PC’s
and multiport networks offer high performance at very low prices.

5.2 Serially Accessed Device Types

Serially accessed devices are produced by many different manufacturers and are capable of
performing many different functions. Regardless of the manufacturer, there are only two ways to
serially communicate. To communicate serially bytes are either transmitted to a device or
received from the device. The order in which bytes are transmitted or received and the meaning
of each byte is usually defined in some document or manual called the protocol. Protocols are
divided into two categories. A protocol is either an ASCII or a binary (hexadecimal) protocol.
Some protocols are standard (DNP, MOD-BUS, FTP, TCP/IP, EDI...), others are proprietary. In
order to communicate with multiple devices having various protocols the control computer
software uses a library of device dependent programs or drivers. Each driver in the library
corresponds to a specific type of protocol for a specific device. Drivers are written with a text
editor and are easily added to the system library. The syntax for writing drivers can vary from a
full natural language (BASIC, Pascal, FORTRAN, C...) to a simple easy to learn script language.
The following are examples of script drivers:

[ASCII COMMAND EXAMPLE]

DRIVER#=1
TYPE=ASCII
TXCOMMAND=METER^[13;10]
TXPERIOD=7
RXSTRIP=N1, S1, T40, D0, C08, “Response Line #1”, H4, X54, Y8

19
 Chapter 5 – Serially Accessed Devices

GPS

Monitor

RELAY

Keyboard

DFR PC

SER Rocketport Panel 1

Rocketport Panel 2

RTU
Remote Boot Switch

CAMERA

PHONE

.
.
. UPS

Figure 5.1 Substation Data Concentrator

20
 Chapter 5 – Serially Accessed Devices

[BINARY COMMAND EXAMPLE]

DRIVER#=2
TYPE=binary
TXCOMMAND=00 01 02 03 04 05 41 55 1E B8 0A 0B 0C 0D 0E 0F
TXPERIOD=4
RXSTRIP=N1, S11, T1, D2, C7, “ Hex type”, H6, X28, Y5
RXSTRIP=N1, S2, T2, D1, C7, “ Int type”, H4, X1, Y8
RXSTRIP=N1, S7, T4, D3, C7, “Real type”, H4, X28, Y8

In the above examples the driver name is defined between braces and is considered unique. The
driver number must also be unique and is assigned using the “DRIVER#” command. The
“TYPE” command is used to specify the type of protocol and is set to ASCII or binary. Once
launched, the driver periodically transmits the sequence of bytes specified in “TXCOMMAND”
once every “TXPERIOD” (specified in seconds). The response data is automatically captured,
buffered, and parsed by the “RXSTRIP” command. The “RXSTRIP” command is used to
extract specific values from the response buffer and display the queried information on the
screen. The RXSTRIP commands are defined below:

“N” is the line number or block to strip from,

“S” is the starting byte number to strip,
“T” is the total number of bytes to strip,
“D” is the type of data to read (0=ASCII, 1=Integer, 2=Hex, and 3=Real),
“ “ is the header to display ahead of the stripped data,
“H” is the header color,
“X” is the column number to display,
“Y” is the row number, and
“C” is the display color.

Most serially accessed devices in the substation communicate at low baud rates (2400 or 9600
baud). When a large array of these devices, say 128 devices are considered collectively, the
resulting data transfer rates may exceed 0.1 Megabytes/Second. Such rates however, are easily
handled by current PC’s with ample time left over for other functions such as processing,
archiving, and event reporting. The current data transfer rate through the PC bus for Industry
Standard Architecture (ISA) is 2.4 Megabytes/Second or 32 Megabytes/Second for Enhanced
ISA (EISA).

5.3 Integration
Integration of serially accessed substation devices is accomplished by placing the devices on a
local area network. Substation devices are networked using a multi-drop (RS485) or a star
(RS232/RJ45) topology. In the multi-drop topology, the devices are placed on a ring network
where only one of the devices can talk at any given time. In the star topology, all of the
networked devices can talk at the same time because each device has a direct link to the control
computer’s hub or multiport panel, as shown in figure 5.2.

21
 Chapter 5 – Serially Accessed Devices

CONTROL
COMPUTER
ÿ ÿ ÿ

Device Device Device Device Device Device

1 2 3 4 5 6

a) MULTIDROP TOPOLOGY

. . . Device
N

Device
N+1

CONTROL
COMPUTER Device
HUB N+2

Device
N+3

. . . Device
N+4

b) STAR TOPOLOGY

Figure 5.2 Network Topologies

22
 Chapter 5 – Serially Accessed Devices

To define the most desired or expedient method to communicate with the proposed integration
scheme an example of what takes place during a storm is reviewed. During a storm, many
devices may begin to transmit at the same time. A star topology is more suitable because it
provides for communications with multiple devices at the same time and it does not require
prioritization of networked devices in order to overcome the bottleneck problem. In this
application the control computer does not have to be a “super-duper” workstation, any 100
Megahertz PC with 32 Megabytes of RAM, 2 Gigabytes of storage and 64 serial input ports is
more than adequate.

The duties of the control computer software are many. The software continuously scans the
network for unsolicited data such as event summaries from relays, executes the system drivers to
solicit specific data from the networked devices, processes and saves all of the captured data to
disk, reports critical data to a remote computer in the office or control center, and frequently
moves the saved data to an archive directory. If the archive directory size exceeds a specified
value, the software deletes the oldest data or records. While the control computer software is
doing all of that, it also provides for uninterrupted terminal to device communications with any
one of the networked devices and has an operator friendly interface for quick configuration of
the available ports and for viewing of captured data.

5.4 Control
Once the substation devices are properly integrated, a new world of control applications
emerges. DFR records can be electronically analyzed and cross checked with relay events and
SOE points. Decisions can now be made about the state of the power system and acted upon
automatically when an event has occurred. The decision making capabilities of such a system
are limited only by the amount of knowledge (rules, methods, templates...) that are built into the
software. Using expert system software design techniques allows many years of expertise and
experience to be programmed into the knowledge-base. With this type of technology, true
substation automation is only a few steps away, but what is the first step?

The first step in providing automatic control software for substation operations is to provide a
control interface for the operator. Clearly, the most qualified applicant for a substation control
interface is the substation single line diagram. Single line diagrams of electric power substations
are created and frequently updated using some form of CAD software such as AutoCAD, Visio,
TurboCAD, Drafix, or MEDUSA. All of these CAD programs can be used to create or exchange
drawings using a standard industry format called DXF (drawing exchange format).

In order to provide a flexible, upgradable, and maintainable control interface the control
computer software uses an internal driver for reading and displaying line drawings from DXF
files. The operator simply enters the name of the file and the line diagram appears full screen, as
shown in figure 5.3. At this point many developers argue that what we have is a great picture,
but this is not just a great picture it is a great picture that is displayed on the control computer
screen in the substation. Recall that the control computer has direct access to the substation
devices and is performing various integration activities in the background. The tools are already
in place to deliver commands to the networked devices and to feed back the responses to the
control computer.

23
 Chapter 5 – Serially Accessed Devices

ARKEY
44KV

CAP. BANK 1,2,3

LOCK OUT RESET
EAST
BARKEY
44KV

CAP. BANK 1,2,3

AUTO MANUAL

BARKEY
44KV

Figure 5.3 Single Line Diagram

24
 Chapter 5 – Serially Accessed Devices

Solicited and unsolicited data are continuously being captured and processed and specified
information is being stripped and displayed to screen. All that the operators have to do is to
ensure that the information that is being stripped and displayed does not overwrite the lines and
circuits of the displayed single line diagram. This merger of DXF drawings and periodically
lunched drivers delivers an even greater picture as shown in figure 5.4. Meter quantities can now
be read directly from the substation drawings that are displayed on the control computer monitor.

To give this picture added life and to provide flexibility in the development and implementation
of the substation control scheme the control computer software allows the operator to pick and
execute drivers directly from the control interface. The operator navigates through a sequence of
menus called control menus, highlights a listed driver, and runs the appropriate driver to perform
the appropriate task. Refer to figure 5.5. Like drivers, control menus can also be created by the
operator and are easily added to the control interface. The format for writing control menus is
the same script language previously defined for writing drivers. The only difference between
control menus and drivers is that drivers have “TXPERIOD” commands and execute periodically
while control menus don’t use this command. Control menus are only executed upon request.
The request could come from the operator or from another driver. Drivers that parse the
response data and extract selected information are also used to compare the extracted
information with predefined thresholds and to perform necessary actions by calling other control
drivers. The following is an example of a simple control scheme to open or close a breaker.

[Open Breaker]
DRIVER#=3
TYPE=ASCII
TXCOMMAND=OPEN

[Close Breaker]
DRIVER#=4
TYPE=ASCII
TXCOMMAND=CLOSE

[Breaker 546 South Arkey]

DRIVER#=5 &3 &4

In this example driver #5 is a control menu, and drivers #3 and #4, that are called by driver #5
are control drivers. Theoretically, as more and more commands and program structures are
supported by the script language operators are able to develop, in the field, complex control
procedures with relative simplicity and a text editor.

25
 Chapter 5 – Serially Accessed Devices

ARKEY
44KV
IA: 1.22 OPEN
IB: 1.26
IC: 1.27 A GT
P: 5.78 TCF LO
Q: 0.78

CAP. BANK 1,2,3

EAST LOCK OUT RESET
BARKEY
44KV

IA: 1.24 OPEN

IB: 1.21 A GT
IC: 1.26 TCF LO
CAP. BANK 1,2,3
AUTO MANUAL
P: 5.80
Q: 0.80

BARKEY
44KV
IA: 1.29 OPEN
IB: 1.23
IC: 1.30 A GT
P: 5.74 TCF LO
Q: 0.76

Figure 5.4 Periodic Polling & Display

26
 Chapter 5 – Serially Accessed Devices

ARKEY
44KV

IA: 1.22 OPEN

IB: 1.26
IC: 1.24 A GT
CONTROL MENU
P: 5.78 TCF LO
Q: 0.78 CANCEL MENU
PCB 536 SOUTH ARKEY
EAST PCB 546 NORTH CARKEY CAP. BANK 1,2,3
LOCK OUT RESET
BARKEY PCB 556 BARKEY 44KV LINE
44KV PCB 750 DARKEY 115KV LINE
MOD 537 EAST FARKEY
IA: 1.23 OPEN
MOD 547 WEST GARKEY
IB: 1.29 A MOD 557
GTHARKEY 44KV LINE
IC: 1.27 TCF LO
CAP. BANK 1,2,3
AUTO MANUAL
P: 5.80
Q: 0.80

BARKEY
44KV

IA: 1.28 OPEN

IB: 1.25
IC: 1.29 A GT Lay Dam
P: 5.82 TCF LO 44KV
Q: 0.74

Figure 5.5 Control Menus

27
 Chapter 5 – Serially Accessed Devices

5.5 Benefits
The number one beneficiary of this design is maintainability. The control computer is designed
to run unmanned for very long periods of time. Captured data is automatically archived and
deleted, system abnormalities are reported to the office immediately, and the control computer
can be accessed remotely. In addition, major upgrades to the control computer software such as
modifying the substation diagram or adding more control schemes and drivers to integrate new
devices can be easily done by the operator. Such technology will have a considerable impact on
the way in which substation equipment is operated in the future.

Tracking of device operations over long periods of time is essential for the early detection of
undesirable trends such as transformer failures. In order to simplify the process of early
detection, the control computer software maintains a database of captured data. The database is
essential for trend analysis and is saved in standard ASCII delimited format so it can be viewed
or processed by other programs. Undesirable trends can be discovered manually by searching
through the database contents or automatically by launching queries.

The substation control system is designed to last. All of the employed hardware components are
based on available open architecture market technology. If you need more space or speed, buy a
bigger or faster computer. If you need more ports, buy an extra panel, plug and play. In
addition, the software components of the system are also based on industry standard formats
such as the IEEE ASCII and binary serial communications and the DXF format. All of these
generic and standard components that are used by the system qualify this system to be the
prototype of substation control systems for the next century.

As Utilities continue to replace their aging infrastructure with serially accessible devices the
need to integrate all substation microprocessor devices onto one user friendly platform becomes
imperative. The ability to interrogate DFR’s, microprocessor relays, smart meters and monitors
quickly and efficiently becomes a high priority in a competitive customer oriented and down
sized environment. Integrating and utilizing the present microprocessor arrangements for
capturing data such as relay targets, or oscillographic data adds value to the corporation.
Utilizing this method of integrating devices from various manufacturers allows for secure
substation automation using off the shelf technology and provides operators with the choice of
selecting from manufacturers that produce the best equipment for the application.

28
Index
control applications, 24
A control computer, 20
allocation table, 10 control driver
American Standard Code for Information examples, 26
Interchange, 1 control drivers, 26
ASCII, 1, 2, 6, 8 control equipment, 19
ASCII character set, 11 control interface, 26
ASCII editors, 16 control menu
examples, 26
B control menus, 26
control software, 24
baud rates, 22
binary, 1, 2, 6, 8 D
binary editors, 16
data acquisition, 20
C data compression programs, 17
data compression schemes
CAD, 19 adaptive dictionary coding, 11
CAD software, 24 dictionary coding, 11
cluster, 1 half byte packing, 10
clusters, 18 huffman coding, 11
coding event filenames, 11 run length coding, 10
communication protocols, 20 data files, 5
compression programs, 17 data storage formats, 1
compression techniques data storage mediums, 1
adaptive dictionary coding, 17 data transfer rates, 22
bit packing, 17 device drivers
dictionary coding, 17 commands, 22
run length coding, 17 examples, 20
COMTRADE, 1, 2, 5, 16 script language, 20
new standard, 8 device drivers
troubleshooting, 8 ASCII, 22
COMTRADE file format binary, 22
configuration, 6 DFR, 1
analog summary, 6 digital fault recorders, 1
data summary, 6 digital fault records, 1
digital summary, 6 digital records, 5
record summary, 6 DOS, 9
configuration file, 2 DOS filenames, 11
data, 6 drawing exchange format (DXF), 24
data file, 2 DXF, 24
header, 6
header file, 2 E
COMTRADE format, 2
Enhanced ISA (EISA), 22
event file format classes M
associated, 12 microprocessor devices, 19
coded, 12 multi-drop network, 22
sequenced, 13 multiport panel, 22
event filenames, 9
event files, 1 N
event files manager, 15
memory issues, 17 NT File System (NTFS), 1
event files viewer, 16 NTFS, 10
expert system, 24
P
F plug, and play, 29
FAT, 10 power system models, 8
FAT32, 18 proprietary event file formats
fault location, 20 ASCII, 2
file allocation table (FAT), 1 binary, 2
file attributes, 1, 10 proprietary file formats
file systems, 1 ASCII, 2
file types binary, 2
data, 10 protocols, 19
executable/dynamic libraries, 10
system, 10 R
filename character set, 9 relay targets, 20
filenames, 1 relays, 1
character set, 11 ring network, 22
coded keys, 11
Concurrent DOS, 9 S
disk access operation, 9 script language, 20
DOS, 9, 13 sequence of events recorders, 1
key event information, 9 SER, 1
Windows 3.x, 9 serial communication, 20
Windows 95/98/NT, 9, 13 serially accessed devices, 20
DFR’s, 19
I
relays, 19
IEEE C37.111 Standard Common Format SCADA systems, 19
for Transient Data Exchange, 5 SOE’s, 19
IEEE COMTRADE standard, 12 transformer monitors, 19
IEEE Power Engineering Society, 5 video cameras, 19
Industry Standard Architecture (ISA), 22 single line diagram, 24
standard file formats
L ASCII, 2
local area network, 20 binary, 2
multidrop, 22 star topology network, 22
star topology, 22 storage formats, 5
substation control, 24
substation control interface, 24
substation integration unsolicited data, 24
benefits, 20 Utility Communications Architecture
(UCA), 2
T
transformer monitors, 1 V
trend analysis, 29 virtual memory, 18

U W
universal event display, 16 Windows NT, 9
Notes
Notes
Notes
Notes
Notes