II. PHILOSOPHY
The design of the Common Data Format (CDF) evolved from
a collection of philosophical ideas and goals into a series of
rules defining a specification. These rules were intended to
provide a rigid framework for implementors to work within when
generating a CDF media. In an attempt to provide a high level
of flexibility in this structure, which was a primary goal in
the design, the CDF was created as a series of "user-defined
bins" which need only be described, both in size and content,
using the appropriate keywords. A directory block must be the
first section on any CDF media. Flexibility is maintained by
allowing a variable number of directory blocks, as long as the
number of directory blocks is defined and identified in the leading
directory block. The same holds true for the header blocks.
The CDF structure requires that a header block containing certain
variables lead off every data file. Flexibility is maintained
again by allowing multiple header blocks. Each header variable
must adhere to a strict format. Part of this format is an ASCII
identifier, therefore any number of customer-specific parameters
can be added in the customer area of the header. The different
sections within both the directory and header are separated by
the "@" string delimiters. If there is frequency calibration
information for the data in a file, these must follow the last
header block. The flexibility is maintained by allowing different
types of calibration data to be used. The implementor is required
to specify, again using appropriate keywords, the type of data
being used in the @CALIBRATION list in the header.
The data section of each file is a collection of data records.
These data records contain up to three sub-records which must
be written in a specific order and format. Samples within these
sub-records are used to store dynamic parameters, target position
information and the actual radar data (either raw or processed).
Flexibility is maintained by allowing unnecessary sub-records
to be omitted and by permitting the included sub-records to be
variable in size and content. The sub-records are actually "bins"
of a user-defined size which can be filled with user-specified
information. The size and content of these bins are defined in
the header of each file. The result is that, while adhering to
a rigid structure, the CDF can be used to efficiently store a
large variety of data types. Table 2 lists all the currently
accepted keywords (including units) which can be used to specify
the type of data stored in the POSITION and DATA sub-records.
Also shown are the choices CALIBRATION data. The appropriate
identification strings are written in the @POSITION, @DATA and
@CALIBRATION sections of the header.
The Common Data Format specification is designed to be a rigid
framework of user-defined data. This makes it flexible enough
to accommodate the largest possible number of radar ranges and
existing formats. A single translator program can read all generated
CDF media. There is enough configuration information provided
in the directory and header blocks to allow for the software to
"modify" itself during run-time. This should allow
data to be shared between the ranges, which was the goal of the
CDF. In the event that this flexible structure breaks down at
some later date, there is a version
number in the directory which can be utilized to allow for "major"
changes to the format in the future.
Table 2
ALLOWED KEYWORDS
@DATA
KEYWORD CONTENTS FORMAT
CC-Link.