曝光臺 注意防騙 網曝天貓店富美金盛家居專營店坑蒙拐騙欺詐消費者

database. Although the type of data stored in the two systems was basically identical, the designers created the
databases to solve the individual problems of each sys-
tem. In other words, the data was not interchangeable.
This was not a problem because so few of the systems were in use, but as the implementation of
RNAV systems expanded, a world standard for airborne navigation databases had to be created.
In 1973, Aeronautical Radio, Inc. (ARINC) sponsored
the formation of a committee to standardize aeronautical databases. In 1975, this committee published the
first standard (ARINC Specification 424), which has
remained the worldwide-accepted format for coding
airborne navigation databases.
There are many different types of RNAV systems certified for instrument flight rules (IFR) use in the NAS.
The two most prevalent types are GPS and the multisensor FMS.
Figure A-1. Area Navigation Receivers.
A-2
Most GPSs operate as stand-alone RNAV systems. A
modern GPS unit accurately provides the pilot with the
aircraft’s present position; however, it must use an airborne navigation database to determine its direction or
distance from another location unless a latitude and
longitude for that location is manually entered. The
database provides the GPS with position information
for navigation fixes so it may perform the required geodetic calculations to determine the appropriate tracks,
headings, and distances to be flown.
Modern FMSs are capable of a large number of functions including basic en route navigation, complex
departure and arrival navigation, fuel planning, and
precise vertical navigation. Unlike stand-alone navigation systems, most FMSs use several navigation inputs.
Typically, they formulate the aircraft’s current position
using a combination of conventional distance measuring
equipment (DME) signals, inertial navigation systems
(INS), GPS receivers, or other RNAV devices. Like
stand-alone navigation avionics, they rely heavily on airborne navigation databases to provide the information
needed to perform their numerous functions.
DATABASE CAPABILITIES
The capabilities of airborne navigation databases
depend largely on the way they are implemented by the
avionics manufacturers. They can provide data about a
large variety of locations, routes, and airspace segments
for use by many different types of RNAV equipment.
Databases can provide pilots with information regarding airports, air traffic control frequencies, runways,
special use airspace, and much more. Without airborne
navigation databases, RNAV would be extremely limited.
PRODUCTION AND DISTRIBUTION
In order to understand the capabilities and limitations
of airborne navigation databases, pilots should have a
basic understanding of the way databases are compiled
and revised by the database provider and processed by
the avionics manufacturer.
THE ROLE OF THE DATABASE PROVIDER
Compiling and maintaining a worldwide airborne navigation database is a large and complex job. Within the
United States (U.S.), the Federal Aviation Administration
(FAA) sources give the database providers information,
in many different formats, which must be analyzed,
edited, and processed before it can be coded into the
database. In some cases, data from outside the U.S.
must be translated into English so it may be analyzed
and entered into the database. Once the data is coded
following the specifications of ARINC 424 (see
ARINC 424 later in this appendix), it must be continually updated and maintained.
Once the FAA notifies the database provider that a
change is necessary, the update process begins.
1
The
change is incorporated into a 28-day airborne database
revision cycle based on its assigned priority. If the
information does not reach the coding phase prior to its
cutoff date (the date that new aeronautical information
can no longer be included in the next update), it is held
out of revision until the next cycle. The cutoff date for
aeronautical databases is typically 21 days prior to the
effective date of the revision.
2
The integrity of the data is ensured through a process
called cyclic redundancy check (CRC). A CRC is an
error detection algorithm capable of detecting small
bit-level changes in a block of data. The CRC algorithm
treats a data block as a single (large) binary value. The
data block is divided by a fixed binary number (called a
“generator polynomial”) whose form and magnitude is
determined based on the level of integrity desired. The
remainder of the division is the CRC value for the data
block. This value is stored and transmitted with the corresponding data block. The integrity of the data is
　
中國航空網 m.k6050.com
航空翻譯 www.aviation.cn
本文鏈接地址：Instrument Procedures Handbook (IPH)儀表程序手冊下(161)