U.S. patent application number 10/733968 was filed with the patent office on 2004-11-11 for method and system for the navigation and control of vehicles at an airport and in the surrounding airspace.
This patent application is currently assigned to H. Robert Pilley. Invention is credited to Pilley, Harold R., Wortley, Lois V..
Application Number | 20040225432 10/733968 |
Document ID | / |
Family ID | 26815797 |
Filed Date | 2004-11-11 |
United States Patent
Application |
20040225432 |
Kind Code |
A1 |
Pilley, Harold R. ; et
al. |
November 11, 2004 |
Method and system for the navigation and control of vehicles at an
airport and in the surrounding airspace
Abstract
A navigation and airport control and management method and
system for aircraft and surface vehicles. The system incorporates
the use of differential GPS to provide increased accuracy and
robustness for aircraft and vehicles using GPS as the primary
terminal area navigation system. An antenna is precisely located
and identified with GPS compatible coordinate references. GPS
signals are received with the antenna and supplied to a
differential GPS base station. The base station calculates
psuedorange and delta range corrections for each tracked satellite.
Calculated differential corrections are then broadcast to vehicles
in the local area using a radio transmitter. Vehicles receive the
broadcast differential corrections and calculate differentially
corrected position, velocity and time (PVT) information. This
information is used on aboard the vehicle for navigational or
automatic dependent surveillance purposes. At an airport control
and management system ADS broadcasts are received and used for
control purposes. The construction of precise digital maps
compatible with GPS is used for vehicle onboard navigation and for
air traffic control situation display purposes. The digital maps
include airport features such as runways, taxiways, gate areas,
geographical features nearby the airport and other pieces of useful
in formation.
Inventors: |
Pilley, Harold R.; (Ringe,
NH) ; Wortley, Lois V.; (Leominster, MA) |
Correspondence
Address: |
Harold R. Pilley
P.O. Box 439
Berkeley Heights
NJ
07922
US
|
Assignee: |
H. Robert Pilley
|
Family ID: |
26815797 |
Appl. No.: |
10/733968 |
Filed: |
December 11, 2003 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10733968 |
Dec 11, 2003 |
|
|
|
09871328 |
May 31, 2001 |
|
|
|
09871328 |
May 31, 2001 |
|
|
|
09598001 |
Jun 20, 2000 |
|
|
|
6314363 |
|
|
|
|
09598001 |
Jun 20, 2000 |
|
|
|
09032313 |
Feb 27, 1998 |
|
|
|
6195609 |
|
|
|
|
09598001 |
Jun 20, 2000 |
|
|
|
08651837 |
May 21, 1996 |
|
|
|
5740047 |
|
|
|
|
09598001 |
Jun 20, 2000 |
|
|
|
08524081 |
Sep 6, 1995 |
|
|
|
5867804 |
|
|
|
|
09598001 |
Jun 20, 2000 |
|
|
|
08117920 |
Sep 7, 1993 |
|
|
|
5548515 |
|
|
|
|
08117920 |
Sep 7, 1993 |
|
|
|
07758852 |
Sep 12, 1991 |
|
|
|
08117920 |
Sep 7, 1993 |
|
|
|
07659681 |
Feb 25, 1991 |
|
|
|
Current U.S.
Class: |
701/117 |
Current CPC
Class: |
G16Z 99/00 20190201;
G01C 23/00 20130101; G01S 19/49 20130101; G08G 5/0082 20130101;
G01S 5/0009 20130101; G01S 19/15 20130101; G08G 5/0013 20130101;
G08G 5/025 20130101; G01S 19/071 20190801; G01S 1/047 20130101;
G08G 5/0026 20130101; G01S 19/20 20130101; G01S 19/41 20130101;
G08G 5/0043 20130101 |
Class at
Publication: |
701/117 |
International
Class: |
G08G 001/00 |
Claims
1. An airport navigation method for a plurality vehicles selected
from the group comprising aircraft and surface vehicles, said
method comprising a. installing a GPS reference antenna at a known
physical location, said physical location being GPS referenced; b.
preparing an airport map that is GPS referenced; said map
containing at least one digital representation of features selected
from the group comprising runways, taxiways, gate areas,
geographical features of the area surrounding the airport,
topography surrounding the airport, approach paths, departure paths
and identified obstructions; c. providing said map to a vehicular
navigation computer system; d. receiving GPS signals at said GPS
reference antenna; e. providing said received GPS signals to a
Differential GPS base station; f. calculating with said
Differential GPS base station differential corrections; g.
providing said differential corrections to a radio transmitter; h.
broadcasting using said radio transmitter, said differential
corrections to said vehicle; i. receiving using a radio receiver
located on said vehicle said broadcast differential corrections; j.
receiving GNSS signals using a GNSS antenna located on said vehicle
and providing said received GNSS signals to a differential GNSS
receiver located on said vehicle; k. providing said received
differential corrections to said differential GPS receiver; l.
calculating using said differential GPS receiver at least one
differentially corrected information element selected from the
group comprising 3-dimensional position, 2-dimensional horizontal
position, vertical position, 3-dimensional velocity, speed,
heading, vertical rate and time; m. navigating said vehicle using
said differentially corrected information using said vehicular
navigation computer system that displays said location of said
vehicle on said digital map.
2. An airport control and management method for a plurality
vehicles selected from the group comprising aircraft and surface
vehicles, said method comprising a. installing a GPS reference
antenna at a known physical location, said physical location being
GPS referenced; b. preparing an airport map that is GPS referenced;
said map containing at least one digital representation of features
selected from the group comprising runways, taxiways, gate areas,
geographical features of the area surrounding the airport,
topography surrounding the airport, approach paths, departure paths
and identified obstructions; c. providing said map to an airport
control and management computer system; d. receiving GPS signals at
said GNSS reference antenna; e. providing said received GPS signals
to a Differential GPS base station; f. calculating with said
Differential GPS base station differential corrections; g.
providing said differential corrections to a radio transmitter; h.
broadcasting using said radio transmitter, said differential
corrections to said vehicle; i. receiving using a radio receiver
located on said vehicle said broadcast differential corrections; j.
receiving GPS signals using a GPS antenna located on said vehicle
and providing said received GPS signals to a differential GPS
receiver located on said vehicle; k. providing said received
differential corrections to said differential GPS receiver; l
calculating using said differential GPS receiver at least one
differentially corrected information element selected from the
group comprising 3-dimensional position, 2-dimensional horizontal
position, vertical position, 3-dimensional velocity, speed,
heading, vertical rate and time; m. broadcasting differentially
corrected position information indicative of said vehicle location
using a radio transmitter located on said vehicle; n. receiving
said broadcast position information at said control and management
computer system; o. presenting said airport map on a display of
said airport control and management computer system and p.
displaying the location of said vehicle in said presented airport
map using said received broadcast position information.
3. An airport navigation system, the system comprising: a. a GPS
antenna used to receive broadcast signals from GPS satellites, said
GPS antenna located at a known location, identified with
3-dimensional GPS compatible coordinates; b. a differential GPS
base station that receives GPS signals from said GPS antenna; c.
means within said differential GPS base station to calculate
differential corrections consisting of psuedorange corrections; d.
a radio transmitter connected to said differential GPS base
station; e. means within said differential GPS base station to send
psuedorange corrections to said radio transmitter; f. a radio
receiver located on a vehicle selected from the group comprising
aircraft and surface equipment; g. means on said vehicle to receive
said psuedorange corrections using said radio receiver and means to
provide said psuedorange corrections to an onboard differential GPS
receiver; h. means to calculate a differentially corrected position
using said onboard differential GPS receiver and said received
psuedorange corrections and i. means to navigate said vehicle using
said differentially corrected GPS position.
Description
[0001] This invention is a Continuation of application Ser. No.
09/871,328 filing date May 31, 2001 currently pending, which is a
Divisional Application of application Ser. No. 09/598,001 filing
date Jun. 20, 2000 now U.S. Pat. No. 6,314,363, which is Divisional
Application of application Ser. No. 09/032,313 filing date Feb. 27,
1998 now U.S. Pat. No. 6,195,609, and is a continuation in part of
application Ser. No. 08/651,837, filed May 21, 1996 now U.S. Pat.
No. 5,740,047, and is Divisional Application of application Ser.
No. 08/524,081 filing date Sep. 6, 1995 now U.S. Pat. No.
5,867,804, from Document Disclosure # 360870 dated Sep. 2, 1994,
Book "GPS Based Airport Operations, Requirements, Algorithms and
Analysis, Publication Date Sep. 14, 1994, Copyright Registration
Nov. 10, 1994, and is a continuation in part of Ser. No. 08/117,920
filed Sep. 7, 1993 now U.S. Pat. No. 5,548,515, which is a
continuation of application Ser. No. 08/117,920 filed Sep. 7, 1993
now U.S. Pat. No. 5,548,515, which is a continuation in part of
Ser. No 07/758,852 filed Sep. 12, 1991 abandon, and a continuation
in part of Ser. No. 07/659,681 Jun. 9. 1992 abandon, which is the
US national phase of PCT/US-91/07575 filed Oct. 9, 1991 abandon,
which is a continuation in part of Ser. No. 07/758,852 filed Sep.
12, 1991 abandon, which is a continuation in part of Ser. No.
07/593,214 filed Oct. 9, 1990 now U.S. Pat. No. 5,200,902.
BACKGROUND
[0002] 1. Field of the Invention
[0003] The use of GNSS in the airport environment plays an
important role in the navigation and control of vehicles comprised
of aircraft and surface equipment. To meet the accuracy and
integrity of demanding airport navigation and control operations,
differential GNSS is used. Differential GNSS reference receivers
located at precise GNSS surveyed locations provide differential
corrections over an RF datalink to differential GNSS capable
receivers located aboard vehicles. Two Federal Aviation
Administration programs build on this demonstrated technique of the
applicant, specifically the Wide Area Augmentation System and the
Local Area Augmentation System. Supporting the navigation function,
descriptive digital maps indicative of airport surrounding terrain
and airport physical features are used in the vehicles for
navigation and by air traffic controllers for the control of
airport operations. In uncontrolled airports without controllers
the pilot and vehicle operators control their movement
independently using differential GNSS navigation.
[0004] 2. Description of Prior Art
[0005] Today's airport terminal operations are complex and varied
from airport to airport. Airports today are, in many cases, the
limiting factor in aviation system capacity. Each airport has a
unique set of capacity limiting factors which may include; limited
tarmac, runways, suitable approaches, navigational or/and Air
Traffic Control (ATC) facilities.
[0006] Furthermore, operational requirements in the terminal area
involve all facets of aviation, communication, navigation and
surveillance. The satisfaction of these requirements with
technological/procedural solutions should be based upon three
underlying principles; improved safety, improved capacity and cost
effectiveness.
[0007] Today airport air traffic control procedures and general
airport aviation operations are based on procedures from the
1950's. These air traffic control procedures were initially
developed to separate aircraft while in the air. The initial
separation surveillance system was a radar system consisting of a
rotating radar antenna. The antenna rotated typically about once
every 4.8 seconds while transmitting a signal, another receiving
antenna picks up a reflected signal from a target. The surveillance
system then calculated a range (based on transit time) and an
azimuth angle based on the physical orientation of the antenna. The
2-dimensional position was then usually plotted on a display with
other detected targets, objects and clutter. Radar today relies on
faster rotating antennas or electronically scanned antennas to
provide more frequent updates and higher resolution. To further
enhance the performance of the target returns, provide altitude
information and an identifier, a transponder is used on the
aircraft. The transponder is the key element in radar surveillance
systems, since without it no identification and no altitude
information is provided to the air traffic control system.
[0008] Surveillance data from multiple surveillance systems
(radars) is then discretely mosaiced or "tiled" into a
semi-continuous system. Controllers today separate traffic visually
by the rule of "green in between" the target tracks. This is a
highly manual method for separation of aircraft, placing stress on
the controllers and limits any true automation assistance for the
controller.
[0009] In the high density and high precision airport environment
numerous single function airport systems have been developed over
the years to support air traffic control and pilot needs. Precise
landing navigation is currently provided by the Instrument Landing
System (ILS), while airside navigation is provided by VOR/DME,
LORAN and NDB's. Airport air traffic controller surveillance is
provided thorough visual means, airport surface detection radar
(ASDE), secondary surveillance radar, parallel runway monitoring
radar and in some cases primary radar. Each of these systems is
single function, local in nature and operation and provides
accuracy which is a function of distance to the object being
tracked. Merging these navigation and surveillance systems into a
4-dimensional seamless airport environment is technically difficult
and expensive. MIT Lincoln Laboratories is attempting to provide an
improved radar based Air Traffic Control environment and has
received three U.S. Pat. Nos. 5,374,932, 5,519,618 and 5,570,095
reflecting those efforts. These patents relate to improvements of
the current localized surveillance and navigation airport
environment without the use of GNSS compatible seamless techniques
as described herein by Pilley.
[0010] These localized systems have served the aviation system well
for nearly 50 years and numerous mishaps have been prevented over
this period through their use. With the advent of new
multi-function technologies superior performance is available at a
fraction of the cost of today's current single function systems.
The technologies of Global Navigation Satellite Systems, digital
communication and low cost commercial computers can support
seamless 4-dimensional airport operations at smaller airports
unable to justify the heavy financial investment in today's single
function navigation and surveillance systems.
[0011] The FAA, NASA, the Defense Department and private industry
are active utilizing elements of the applicants methods and systems
demonstrated over a decade ago. Specific United States Programs
involving this technology are:
[0012] FAA Capstone
[0013] FAA Ohio River Valley Project
[0014] FAA Safe Flight 21
[0015] NASA Runway Incursion Protection System (RIPS)
[0016] Others are also demonstrating and developing similar systems
in prior years included: Haken Lans (GP&C) of Sweden is
demonstrating the use of Differential GPS with Self Organizing Time
Division Multiple Access datalink communications. The invention of
Haken Lans is described in World Intellectual Property Organization
document # 93/01576. The invention of Fraughton describes an
airborne system for collision avoidance in U.S. Pat. No. 5,153,836.
The inventions of Lans and Fraughton fail to provide the seamless 4
dimensional GNSS compatible operational and processing environment
of Pilley and fail to include the digital map of Pilley.
[0017] After the demonstrations of the applicant it became clear
that this technology had great application in airport operations.
After a decade the industry is accepting the concepts, deploying
systems and equipping vehicles.
BACKGROUND OF THE INVENTION
[0018] The inventor having been involved with the FAA's Advanced
Automation System became aware that airport program segments were
not getting the attention they deserved, nor were advanced
technologies being investigated. The inventor set out to
demonstrate that new technologies could be used to support seamless
airport navigation and surveillance. The multi-year efforts of the
inventors are summarized in the book titled:
[0019] GPS BASED AIRPORT OPERATIONS, Requirements, Analysis,
Algorithms US copyright # TX U.S. Pat. No. 3,926,573, (Library of
Congress # 94-69078), (ISBN 0-9643568-0-5). This bookprovides much
of the back ground for this patent application. In addition to the
book the following publications and professional papers have been
published by the inventor in efforts of due diligence to promote
this life saving technology.
[0020] PUBLICATIONS:
[0021] Institute of Navigation, ION GPS-91, Sep. 12, 1991,
Technical Paper, "Airport Navigation and Surveillance Using GPS and
ADS".
[0022] GPS WORLD Magazine, 10-91, Article, "GPS, Aviation and
Airports the Integrated Solution".
[0023] 71st Transportation Research Board, Annual Meeting, Jan. 14,
1992, Technical Paper, "Applications of Satellite CNS in the
Terminal Area".
[0024] Institute of Navigation National Technical Meeting, Jan. 28,
1992, Technical Paper, "Terminal Area Surveillance Using GPS".
[0025] Institute of Navigation, ION GPS-92, Technical Paper,
"Collision Prediction and Avoidance Using Enhanced GPS".
[0026] Institute of Navigation, 49th Annual Meeting, June 1993,
Technical Paper, "Runway Incursion Avoidance Using GPS".
[0027] Airport Surface Traffic Automation Technical Information
Group FAA & Industry Forum, Jul. 15, 1993, Presentation.
[0028] Commercial Aviation News, Jul. 19, 1993, "Airport Test to
Look at Collision Avoidance".
[0029] IEEE Vehicle Navigation and Intelligent Vehicle (VNIS),
Conference, Oct. 14, 1993, Technical Paper, "Demonstration Results
of GPS for Airport Surface Control and Management". Institute of
Navigation, ION GPS-93, Sep. 23, 1993, Technical Paper,
[0030] "GPS for Airport Surface Guidance and Traffic Management".
Avionics Magazine, 10-93, "Differential GPS Runway Navigation
System Demonstrated".
[0031] IEEE PLANS '94, April 1994, Technical Paper, "GPS, 3-D Maps
and ADS Provide A Seamless Airport Control and Management
Environment".
[0032] Institute of Navigation, ION GPS-94, Sep. 22, 1994,
Technical Paper, "DGPS for Seamless Airport Operations".
[0033] Presentation Seattle, Washington, May 9, 1995. International
Civil Aviation Organization of the United Nations, Advanced Surface
Movement Guidance and Control (SMGCS) meeting, Presentation and
demonstration "GPS based SMGCS".
[0034] As the list of presentations and publications shows the
inventors have been active in getting the government and the
aviation community to accept this life saving cost effective
airport technology.
[0035] The United States alone currently contains some 17,000
airports, heliports and seabases. Presently only the largest of
these can justify the investment in dedicated navigation and
surveillance systems while the vast majority of smaller airports
have neither. Clearly, a new approach is required to satisfy
aviation user, airport operator, airline and ATC needs.
[0036] It would therefore be an advance in the art to provide a
cost effective Airport Control and Management System which would
provide navigation, surveillance, collision prediction, zone/runway
incursion and automated airport lighting control based on the
Global Navigation Satellite System (GNSS) as the primary position
and velocity sensor on board participating vehicles. It would be
still a further advance of the art if this system were capable of
performing the navigation, surveillance, collision prediction,
lighting control and zone/runway incursion both on board the
aircraft/vehicles and at a remote ATC, or other monitoring
site.
[0037] With the advent of new technologies such as the Global
Positioning System, communication and computer technology, the
application of new technologies to the management of our airports
can provide improved efficiency, enhanced safety and lead to
greater profitability for our aviation industry and airport
operators.
[0038] On Aug. 12, 1993, Deering System Design Consultants, Inc.
(DSDC) of Deering, N.H., successfully demonstrated their Airport
Control & Management System (AC&M) to the Federal Aviation
Administration (FAA). After many years of development efforts, the
methods and processes described herein were demonstrated to Mike
Harrison of the FAA's Runway Incursion Office, officials from the
FAA's Satellite Program Office, the FAA New England Regional
Office, the Volpe National Transportation System Center, the New
Hampshire Department of Transportation, the Office of U.S. Senator
Judd Gregg and the Office of U.S. Representative Dick Swett. This
was the first time such concepts were reduced to a working
demonstrable system. The inventor has taken an active stand to
promote the technology in a public manner and, as such, may have
informed others to key elements of this application. The inventor
has promoted this technology. The inventor's airports philosophy
has been described in general terms to the aviation industry since
it was felt industry and government awareness was necessary. The
intent of this Continuation application to identify and protect
through letters of Patent techniques, methods and improvements to
the demonstrated system.
[0039] With these and other objects in view, as will be apparent to
those skilled in the art, the improved airport control and
management invention stated herein is unique, novel and promotes
the public well being.
SUMMARY OF THE INVENTION
[0040] This invention most generally is a system and a method for
the control of surface and airborne traffic within a defined space
envelope. GNSS-based, or GPS based data is used to define and
create a 3-dimensional map, define locations, to compute
trajectories, speeds, velocities, static and dynamic regions and
spaces or volumes (zones) including zones identified as forbidden
zones. Databases are also created, which are compatible with the
GNSS data. Some of these databases may contain, vehicle information
such as type and shape, static zones including zones specific to
vehicle type which are forbidden to the type of vehicle, notice to
airmen (notams) characterized by the information or GNSS data. The
GNSS data in combination with the databases is used, for example,
by air traffic control, to control and manage the flow of traffic
approaching and departing the airport and the control of the flow
of surface vehicles and taxiing aircraft. All or a selected group
of vehicles may have GNSS receivers. Additionally, all or a
selected group may have bi-directional digital data and voice
communications between vehicles and also with air traffic control.
All of the data is made compatible for display on a screen or
selected screens for use and observation including screens located
on selected vehicles and aircraft. Vehicle/aircraft data may be
compatibly superimposed with the 3-dimensional map data and the
combination of data displayed or displayable may be manipulated to
provide selected viewing. The selected viewing may be in the form
of choice of the line of observation, the viewing may be by layers
based upon the data and the objective for the use of the data.
[0041] It is, therefore, an object of this invention to provide the
following:
[0042] 1.) A 4-D process logic flow which provides a "seamless"
airport environment on the ground and in the air anywhere in the
world with a common 3-D coordinate reference and time
[0043] 2.) An Airport Control and Management Method and System
which utilizes GNSS, 3-D maps, precise waypoint navigation based on
the ECEF reference frame, a digital full duplex communication link
and a comprehensive array of processing logic methods implemented
in developed operational software
[0044] 3.) An Airport Control and Management Method and System
where a vehicle based 4-D navigational computer and ATC computer
utilize the same coordinate reference and precise time
standard.
[0045] 4.) A database management method compatible with 3-D
waypoint storage and presentation in 3-D digital maps.
[0046] 5.) A automated method utilizing the precise 3-D airport map
for the definition and creation of airport routes and travel
ways.
[0047] 6.) A 4-D process logic flow which provides precise vehicle
waypoint navigation in the air and on the ground. This process
allows for monitoring of on or off course conditions for vehicles
and aircraft operating within the airport space envelope on board
the vehicle.
[0048] 7.) A 4-D process logic flow which provides precise ATC
waypoint navigation mirroring of actual vehicles in the air and on
the ground at ATC. This process allows for monitoring of on or off
course conditions for vehicles and aircraft operating within the
airport space envelope at the ATC computer
[0049] 8.) A 4-D process logic flow performed on board the vehicle
which provides for precise collision prediction based on
3-dimensional zones
[0050] 9.) A 4-D process logic flow performed at the ATC computer
which provides for precise collision prediction based on
3-dimensional zones
[0051] 10.) A collision detection management method which utilizes
the application of false alarm reducing methods
[0052] 11.) An ATC process logic flow which detects 3-D runway
incursions. The process logic then generates message alerts and
controls airport lights
[0053] 12.) An ATC zone management method which utilizes the
application of false alarm reducing methods
[0054] 13.) A vehicle process logic flow which detects 3-D runway
incursions. The process logic then generates message alerts and
sounds tones within the vehicle or aircraft
[0055] 14.) A vehicle zone management method which utilizes the
application of false alarm reducing methods
[0056] 15.) A 4-D ATC process logic flow which manages ground and
air "Clearances" with precise waypoint navigation aboard the
vehicle and at the ATC computer.
[0057] 16.) A 4-D ATC process logic flow which manages ground and
air "Clearances" incorporating an integrated system of controlling
airport lights.
[0058] 17.) A 4-D vehicle process logic flow which manages ground
and air "Clearances" with an integrated system of waypoint
navigation.
[0059] 18.) A method of management for 3-D spatial constructs
called zones
[0060] 19.) A method of management for 3-D graphical constructs
called zones
[0061] 20.) A method of management for the automated generation of
a zones database at any airport
[0062] 21.) A database management method for the storage of zones
data. Zones database management methods are used aboard the vehicle
and at ATC
[0063] 22.) A operational management method where the ATC computer
provides navigational instructions to vehicles and aircraft. The
instructions result in a travel path with clear paths defined being
displayed in an airport map
[0064] 23.) A operational management method where the ATC computer
provides navigational instructions to vehicles and aircraft The
instructions result in waypoints being entered into a 4-D
navigation computer
[0065] 24.) A datalink message content which supports the above
management methods and processes
[0066] 25.) A redundant system architecture which satisfies life
critical airport operations
[0067] 26.) Methods for navigation within the airport environment
using map displays, controller clearances and automation techniques
in the cockpit and at ATC
[0068] 27.) An integrated airport controller automation interface
which supports GNSS compatible processing.
[0069] 28.) A method for managing GNSS travel path information,
clearances and conformance monitoring using broadcast GNSS
trajectory information and automatic dependent surveillance.
[0070] More specifically, the elements mentioned above form the
process framework of the invention stated herein
BRIEF DESCRIPTION OF DRAWINGS
[0071] The invention, may be best understood by reference to one of
its structural forms, as illustrated by the accompanying drawings,
in which:
[0072] FIG. 1 depicts the high-level Airport Control and Management
processing elements and flow
[0073] FIG. 2 represents an example of a cylindrical static zone in
a 3-D ALP. This zone could be graphically displayed in a layer of
the ALP
[0074] FIG. 3 represents an example of a static zone around a
construction area of the airport and is used in zone incursion
processing in the vehicles and at the ATC Processor
[0075] FIG. 4 represents an example of a dynamic zone which travels
with a moving vehicle, in this case the zone represents the minimum
safe clearance spacing which would be used in zone based collision
detection processing in the vehicles and at the ATC processor
[0076] FIG. 5 represents an example of a route zone which is
defined by navigational waypoints and is used for on.backslash.off
course processing and is used in the vehicles and at the ATC
Processor
[0077] FIG. 6 represents an example of a 3-D ATC zone, used to
segregate tracked vehicles to particular ATC stations
[0078] FIG. 7 illustrates the construction of a 3-D runway zone
[0079] FIG. 8 shows a map display with surface waypoints and travel
path
[0080] FIG. 9 shows a map display with departure waypoints and
travel path
[0081] FIG. 10 illustrates the 4-D collision detection mechanism
employed in the Airport Control and Management System
[0082] FIG. 11 depicts a waypoint processing diagram showing the
earth and ECEF coordinate system, expanded view of airport
waypoints, further expanded view of previous and next waypoint
geometry with present position, the cross hair display presentation
used in the developed GPS navigator
[0083] FIG. 12 graphs latitude, Longitude plot of a missed approach
followed by a touch and go with waypoints indicated about every 20
seconds
[0084] FIG. 13 graphs altitude vs. time for missed approach
followed by touch and go, waypoints are indicated about every 20
seconds
[0085] FIG. 14 graphs ECEF X and Y presentation of missed approach
followed by a touch and go with waypoints indicated about every 20
seconds
[0086] FIG. 15 graphs ECEF Z versus time of missed approach
followed by touch and go, with waypoints about every 20 seconds
[0087] FIG. 16 shows a block diagram of on.backslash.off course
processing
[0088] FIG. 17 shows a missed approach followed by a touch and go
GPS trajectory displayed in a 3-D airport map
[0089] FIG. 18 shows an ECEF navigation screen with navigational
window insert and 3-D digital map elements
[0090] FIG. 19 shows the area navigation display with range rings,
course and bearing radial lines, and altitude to true course
indicators
[0091] FIG. 20 depicts the GPS sliding cross hair landing display
indicating too low (go up) and too far right (turn left)
[0092] FIG. 21 illustrates the GPS approach cone with digital map
elements showing current position with respect to true course
line
[0093] FIG. 22 depicts the demonstration system airport
communications diagram showing processor, DGPS base station, radio
elements and message flows
[0094] FIG. 23 depicts the demonstration system AC&M hardware
block diagram showing various elements of the system
[0095] FIG. 24 depicts the demonstration system aircraft hardware
block diagram
[0096] FIG. 25 depicts the demonstration system vehicle #1 hardware
block diagram
[0097] FIG. 26 depicts the demonstration system vehicle #2 hardware
block diagram
[0098] FIG. 27 shows the navigator display compass rose area
navigator and cross hair sliding precision approach display in
combination with waypoint information, position, velocity, range to
the waypoint, cross track error, speed, heading and distance to
true course
[0099] FIG. 28 depicts the airport system single controller
station, non redundant design
[0100] FIG. 29 depicts the airport system redundant single
controller station
[0101] FIG. 30 depicts the airport system redundant dual controller
station
[0102] FIG. 31 depicts the map temporal differential correction
system diagram
[0103] FIG. 32 depicts the differential GPS system diagram
[0104] FIG. 33 depicts the closed loop differential GPS system
diagram
[0105] FIG. 34 depicts the computer human interface using a touch
screen
[0106] FIG. 35 depicts Control Facility and Selected Aircraft
elements with RF datalink message flow and Controller Display
inputs and actions related to an off course condition.
[0107] FIG. 36 identifies Computer Functionality of the AC&M
Processor and Graphic Processor. Bold elements represent functions
necessary for supporting the controller--computer human interface
for sending travel paths to an aircraft, displaying position of an
aircraft on a display, performing automated conformance monitoring,
detecting an off course condition, displaying an alert and
ultimately sending a new travel path to the aircraft.
[0108] FIG. 37 contains selected text from the Specification
indicative of the automated computer detected off course means
using conformance monitoring (mirrored navigation at the AC&M
station) and associated controller actions to attempt to bring off
course aircraft back on course
DESCRIPTION OF PREFERRED EMBODIMENT
AC&M Processing Overview
[0109] The primary Airport Control and Management (AC&M)
functions of the invention utilize a Cartesian ECEF X, Y, Z
coordinate frame compatible with GNSS. FIG. 1 provides additional
detail for the operational elements of the AC&M processing. The
GNSS signals broadcast by the vehicles 8 are processed by the Real
Time Communication Handler 3 and sent to AC&M Operational
Control 1. The Operational Control 1 uses the GNSS data to perform
the following processing functions 5: position projections,
coordinate conversions, zone detection, collision prediction,
runway incursion detection, layer filter, alarm control, and
lighting control. If waypoints have been issued to the vehicle 8,
mirrored waypoint navigation is also performed by the AC&M
processing. The Operational Control 1 interfaces directly to the
Graphical Control 2. Graphics messages, including GNSS data and
coded information pertaining to zone incursions, possible collision
conditions, or off course conditions detected by the AC&M
Processing, are passed to the Graphical Control 2. The Graphical
Control 2 interprets this data and updates the display presentation
accordingly.
[0110] The Operational Control 1 function also receives inputs from
the Controller/Operator Interface 6. The Controller/Operator
Interface uses the data received by Controller/Operator Inputs 7 to
compose ATC commands which are sent to the Operational Control 1
function for processing. Commands affecting the presentation on the
computer display screen are sent by the Operational Control 1
function to the Graphical Control 2 . ATC commands composed by the
Controller/Operator Interface 6 processing that do not require
further AC&M processing are forwarded directly to the Graphical
Control 2 to update the display screen. Both the Operational
Control 1 function and Graphical Control 2 processing have access
to the Monumentation, Aircraft/Vehicle, Static Zones, Waypoints,
Airport Map, ATIS Interface and Airport Status and other low level
data bases 9 to process and manipulate the presentation of map and
vehicle data on a computer display screen.
[0111] More specifically, each vehicle 8 supports the capability to
transmit a minimum of an identifier, the GNSS referenced position
of one or more antennas, velocity, optional acceleration and time
reports. Since this data is broadcast, it is accessible to the
airport control tower, other aircraft and vehicles in the local
area, and various airline monitoring or emergency command centers
which may perform similar processing functions. ATC commands,
processed by the Controller/Operator Interface 6 and Operational
Control 1 function are passed to the Real Time Communication
Handler 3 for transmission to the aircraft/vehicle(s) 8. Upon
receipt of ATC messages, the vehicle(s) 8 return an acknowledgment
message which is received by the Real Time communication Handler 3
and passed to the Operational Control 1 function. Differential GNSS
corrections are generated by the Differential GPS Processor 4 and
passed to the Real Time Communication Handler 3 for broadcast to
the vehicles. The Real Time Communication Handler 8 performs the
following functions at a minimum:
[0112] a. Initialize ATC computer communication lines
[0113] b. Initialize radio equipment
[0114] c. Establish communication links
[0115] d. Receive vehicle identifier, positions, velocity, time and
other information
[0116] e. Receive information from ATC Processor to transmit to
vehicle(s)
[0117] f. Receive ATC acknowledgment messages from vehicle(s)
[0118] g. Transmit information to all vehicles or to selected
vehicles by controlling frequency and/or identifier tags
[0119] h. Monitor errors or new information being transmitted
[0120] i. Receive and broadcast differential correction data
[0121] The AC&M techniques and methods described herein provide
for GNSS compatible 4-Dimensional Airport Control and
Management.
The 3-D Digital Airport Layout Plan
[0122] The combination of ECEF navigation combined with NAD 83
(Lat, Lon, MSL and State Plane) and WGS 84 (X,Y,Z) based 3-D
airport features are necessary in constructing an airport layout
plan (ALP). The Airport Control and Management System (AC&M)
requires that navigation and Automatic dependent Surveillance (ADS)
information used in collision detection processing share the same
coordinate frame. The processing methods described herein, require
very accurate and properly monumented airport layout plans.
Physical features surrounding the airport may be surveyed in a
local coordinate frame and, as such, require accurate
transformation into the airport map/processing coordinate frame.
For these reasons, the use of multi-monumented coordinate
references is mandatory for such map construction and survey.
Clearly, highly accurate 3-D maps are required when using precise
GNSS based navigation, collision avoidance and overall Airport
Control and Management for life critical airport applications.
[0123] The 3-D ALP database and display presentation support the
concept of zones. The display of zone information is managed using
the Map Layer Filter. Zones are two and three dimensional shapes
which are used to provide spatial cueing for a number of design
constructs. Static zones may be defined around obstacles which may
pose a hazard to navigation such as transmission towers, tall
buildings, and terrain features. Zones may also be keyed to the
airport's NOTAMS, identifying areas of the airport which have
restricted usage. Dynamic zones are capable of movement. For
example, a dynamic zone may be constructed around moving vehicles
or hazardous weather areas. A route zone is a 3-D zone formed along
a travel path such as a glide slope. Zone processing techniques are
also applied to the management of travel clearances and for the
detection of runway incursions. Zones may also be associated with
each aircraft or surface vehicle to provide collision prediction
information.
Operational Projections
[0124] AC&M projection processing utilizes received GNSS ADS
messages from a datalink. The complete received message is then
checked for errors using CRC error detection techniques or a error
correcting code. The message contains the following information, or
a subset thereof, but not limited to: PVT ADS DATA
1 PVT ADS DATA ID# 8 Characters VEHICLE TYPE 4 Characters CURRENT
POSITION: X = ECEF X Position (M) 10 Characters Y = ECEF Y Position
(M) 10 Characters Z = ECEF Z Position (M) 10 Characters X2 = ECEF
X2 Position (M) 2 Characters * Y2 = ECEF Y2 Position (M) 2
Characters * Z2 = ECEF Z2 Position (M) 2 Characters * X3 = ECEF X3
Position (M) 2 Characters * Y3 = ECEF Y3 Position (M) 2 Characters
* Z3 = ECEF Z3 Position (M) 2 Characters * VX = ECEF X Velocity
(M/S) 4 Characters VY = ECEF Y Velocity (M/S) 4 Characters VZ =
ECEF Z Velocity (M/S) 4 Characters AX = ECEF X Acceleration (M/S2)
2 Characters # AY = ECEF Y Acceleration (M/S2) 2 Characters # AZ =
ECEF Z Acceleration (M/S2) 2 Characters # TIME 8 Characters TOTAL
CHARACTERS/MESSAGE: 80 Characters * OPTIONAL FIELD, FOR DETERMINING
VEHICLES ATTITUDE IN 3-D DIGITAL MAP DATA BASE # OPTIONAL
ACCELERATION FIELD
[0125] A database is constructed using the ADS message reports. The
AC&M processing converts the position and velocity information
to the appropriate coordinate frame (if necessary, speed in knots
and a true north heading). Simple first and second order time
projections based upon position, velocity and acceleration
computations are used. The ability to smooth and average the
velocity information is also possible using time weighted
averages.
ECEF Position Projection Technique
[0126]
2 PROJECTED X = X + (VX)(t) + (AX)(t.sup.2)/2 PROJECTED Y = Y +
(VY)(t) + (AY)(t.sup.2)/2 PROJECTED Z = Z + (VZ)(t) +
(AZ)(t.sup.2)/2
[0127] This set of simple projection relationships is used in the
collision prediction and zone incursion processing methods.
Zone Database
[0128] Zone areas may be defined in the initial map data base
construction or may be added to the map database using a 2-D or 3-D
data entry capability. The data entry device may be used to
construct a zone using a digital map in the following manner:
[0129] Using the displayed map, the data entry device is used to
enter the coordinates of a shape around the area to be designated
as a zone. (An example may be a construction area closed to
aircraft traffic listed in the current NOTAMS.)
[0130] The corners of the polygon are saved along with a zone type
code after the last corner is entered. Circles and spheres are
noted by the center point and a radius, cylinders are noted as a
circle and additional height qualifying information. Other shapes
are defined and entered in a similar fashion.
[0131] The zone is stored as a list of X, Y, Z coordinates. Lines
connecting the points form a geometric shape corresponding to the
physical zone in the selected color, line type and style in the
proper layer of the base map.
[0132] Zone information may then be used by collision detection and
boundary detection software contained in the AC&M system. This
processing software is explained later in this specification.
[0133] FIG. 2 depicts a 3-D cylindrical static zone around a
hypothetical utility pole. This zone 10 is added into the airport
map 11, while the specific coordinates (center point of base 12,
radius of circular base 13, and the height 14) are saved to the
zone file list in a convenient coordinate frame. Below is an
example of a zone which is stored in the zone database.
3 IDENTIFIER PARAMETER Utility pole Type of Zone Center of base X,
Y, Z Radius of base R Height of the cylinder H
[0134] The 3-D digital map 11 is then updated using a series of
graphic instructions to draw the zone 10 into the map with specific
graphic characteristics such as line type, line color, area fill
and other characteristics.
[0135] A database of zone information containing zones in surface
coordinates such as X & Y state plane coordinates and mean sea
level, ECEF referenced X, Y, Z and others are accessible to the
AC&M Processing. The database may consist of, but is not
limited to the following type of zones.
4 OBJECT OF THE ZONE TRANSMISSION TOWERS AIRPORT CONSTRUCTION AREAS
CLOSED AREAS OF AIRPORT MOUNTAINS TALL BUILDINGS AREAS OFF TAXIWAY
AND RUNWAY RESTRICTED AIRSPACE INVISIBLE BOUNDARIES BETWEEN AIR
TRAFFIC CONTROLLER AREAS APPROACH ENVELOPE DEPARTURE ENVELOPE AREAS
SURROUNDING THE AIRPORT MOVING ZONES AROUND AIRCRAFT/VEHICLES
Zone Processing
[0136] The zone information is retrieved from a zone database. As
the AC&M Processor receives current ADS reports, information on
each position report is checked for zone incursion. Further
processing utilizes velocity and acceleration information to
determine projected position and potential collision hazards. If a
current position or projected position enters a zone area or
presents a collision hazard an alert is generated.
[0137] A zone is any shape which forms a 2-D or 3-D figure such as
but not limited to a convex polygon (2-D or 3-D), or a circular
(2-D), spherical (3-D), cylindrical (3-D) or conical shape
represented as a mathematical formula or as a series of coordinate
points. Zones are stored in numerous ways based upon the type of
zone. The coordinate system of the map and the units of measure
greatly affect the manner in which zones are constructed, stored
and processed.
[0138] The invention described herein utilizes four primary types
of 2-D and 3-D zones in the Airport Control and Management
System.
Four Primary Zone Types
[0139] The first type zone is a static zone as shown in FIG. 3.
Static zones represent static non-moving objects, such as radio
towers, construction areas, or forbidden areas off limits to
particular vehicles. The zone 15 shown in the FIG. 3 represents a
closed area of the airport which is under construction. The zone 15
is a 3-D zone with a height of 100 Meters 16, since it is desired
not to have aircraft flying low over the construction site, but
high altitude passes over the zone are permitted. An example of a
permitted flyover path 17 and a forbidden fly through path 18 are
shown in the figure. The fly through will produce a zone incursion,
while the flyover will not.
[0140] A second zone type is shown in FIG. 4 and represents a
dynamic zone 19 which moves with a moving vehicle or aircraft.
Dynamic zones may be sized and shaped for rough check purposes or
may be used to describe the minimum safe clearance distance. The
dynamic zone is capable of changing size and shape as a function of
velocity and or phase of flight and characterized by vehicle or
aircraft type.
[0141] The third type zone is shown in FIG. 5 and is a route zone
20 . Route zones are described though the use of travel waypoints
21 and 22. The waypoints 21 and 22 define the center line of a
travel path, the zone has a specified allowable travel radius X1,
Y1 at Waypoint 1 21 and X2, Y2 at Waypoint 2 22 for the
determination of on or off course processing. For simplicity X1 may
equal X2 and Y1 may equal Y2. On course 23 operations result in
travel which is within the zone, while off course 24 operations
result in travel which is outside the zone and result in an off
course warning.
[0142] The fourth type zone(s) shown in FIG. 6 is a 3-D zone which
is dynamic and used to sort ATC traffic by. This type zone is used
to segregate information to various types of controller/operator
positions, i.e. ground control, clearance delivery, Crash Fire and
Rescue and others. Travel within a particular zone automatically
defines which ATC position or station the traffic is managed by.
For example travel within zone 1 25 is directed to ATC ground
station, while travel within zone 2 26 is directed to ATC Clearance
Delivery position. The ATC zone concept allows for automatic
handoff from one controllers position to the other as well as
providing overall database the management automation.
[0143] The construct of zones is very important to the overall
operation of the described invention herein. Further examples of
zone processing methods and zone definition is provided below.
EXAMPLE 1
[0144] A cylindrical zone on the airport surface constructed using
the state plane coordinate system would be represented as the
following:
5 Center point of circle CXsp value, CYsp value Elevation (MSL)
Elev = constant, or may be a range Circle radius CR value
[0145] The detection of a zone incursion (meaning that the position
is within the 2-D circle) is described below.
6 Convert position to State Plane coordinates Current or projected
position Xsp, Ysp Subtract circle center Xsp - CXsp = DXsp from
current position Ysp - CYsp = DYsp Determine distance from
DXsp.sup.2 + Dysp.sup.2 = Rsp.sup.2 circle center Test if position
is in Rsp <= CR circle If true continue If not true exit not in
zone Test if position is Min Elev <= Elev <= Max Elev within
altitude range (a cylindrical zone)
[0146] If the above conditions are met, the position is in the 3-D
cylindrical zone. It can be seen that the basic methods used here
are applicable to other grid or coordinate systems based on linear
distances.
EXAMPLE #2
[0147] A cylindrical zone on the airport surface (normal with the
airport surface) constructed using the Earth Centered Earth Fixed
coordinate system is stored using three axis (X, Y, Z).
7 Convert current position to ECEF X, Y, Z Center point of circle
CX value, CY value, CZ value Circle radius CR value Determine
distance from (X - CX) = DX current or projected position (Y - CY)
= DY to center of circle (Z - CZ) = DZ Determine radial distance
DX.sup.2 + DY.sup.2 + DZ.sup.2 = R.sup.2 to circle center point
from current position Test position to see if it R <= CR is in
sphere of radius R If true continue If not true exit not in zone
Determine the vector between VC = CXE + CYE + CZE the center of the
circle and the center of mass of the earth Calculate its magnitude
VC.sup.2 = CXE.sup.2 + CYE.sup.2 + CZE.sup.2 Determine the vector
between the V = VX + VY + VZ center of mass of the earth and the
current or projected position Calculate its magnitude V.sup.2 =
VX.sup.2 + VY.sup.2 + VZ.sup.2 Determine the difference between V -
VC = 0 the two vectors, if result = 0 then in the 2-D zone, if the
result is <0 then position is below, if >0 then position is
above the zone To check for incursion into an ECEF cylindrical
zone, the following is tested for. Test if position is Min VC <=
V <= Max VC within Vector range (a cylindrical zone) Where Min
VC represents the bottom of the cylinder Max VC represents the top
of the cylinder
[0148] The final two tests use an approximation which greatly
simplifies the processing overhead associated with zone incursion
detection. The assumption assumes that over the surface area of an
airport, the vector between the center of mass of the earth
circular zone center and the vector from the current position to
the center of the circle are coincident. That is, the angle between
the two vectors is negligible.
[0149] The second assumption based on the first approximation is
that, rather than perform complex coordinate reference
transformations for zone shapes not parallel with the earth's
surface, projections normal to the surface of the earth will be
used. Zones which are not parallel with the earth's surface are
handled in a manner similar to that applied to on or off course
waypoint processing using rotation about a point or center
line.
[0150] EXAMPLE #3
[0151] A zone which is shaped like a polygon is initially defined
as a series of points. The points may be entered using a data entry
device and a software program with respect to the digital map or
they may be part of the base digital map. The points are then
ordered in a manner which facilitates processing of polygon zone
incursion. The following examples indicate how a (4 sided) polygon
is stored and how an airport surface zone incursion is performed
using both the state plane coordinates and Earth Centered Earth
Fixed X, Y, Z coordinates.
8 Convert Position to SP Xsp, Ysp, State Plane Zone Vertices X1sp,
Y1sp; X2sp, Y2sp; Order in a clockwise X3sp, Y3sp; X4sp, Y4sp
direction Height of 3- D zone min Elev max Elev Determine min &
max Xspmax, Xspmin, Yspmax, Yspmin values for X & Y Perform
rough check Is Xspmin <= Xsp <= Xspmax of current position Is
Yspmin <= Ysp <= Yspmax or projected position If both true
then continue with zone checking If not true exit, not in zone
Calculate the slope (Y2sp - Y1sp)/(X2sp - X1sp) = M of the line
between points 1 & 2 Calculate the slope of M.sup.-1 = -Mnor
the line from the present position normal to the line between
points 1 & 2 Determine the equation Y1sp - M * X1sp = L between
points 1 & 2 Determine the equation Ysp - Mnor * Xsp = LN for
the line normal to the line between points 1 & 2 and position
Determine the intersection intXsp = (LN - L)/(M - Mnor) of both
lines intYsp = Mnor * intXsp + (Ysp - Mnor * Xsp) Determine the
offset from Xsp - intXsp = DXsp position to intersect Ysp - intYsp
= DYsp point on the line between points 1 & 2 Perform check to
see which Check the sign of DXsp side of the line the position
Check the sign of Dysp is on (note sign change as function of
quadrant & direction in which points are entered in) If the
point is on the proper Meaning the signs are side continue and
check o.k. the next line between points 2 & 3 and perform the
same analysis If the line is on the wrong side of the line, then
not in the zone hence exit If point is on the proper side of all
(4) lines of polygon then in 2-D zone Note: If the zone vertices
are entered in a counter clockwise direction the sign of DXsp and
DYsp are swapped. Test if position is Min Elev <= Elev <= Max
Elev within altitude range (a 3-D polygon zone)
EXAMPLE #4
[0152] A further example is provided in the definition of a 3-D
runway zone using ECEF X,Y,Z. A list of runway corners is
constructed using the 3-D map and a data entry device and an
automated software tool. The runway zone is shown in FIG. 7.
[0153] The horizontal outline the runway 27 by selecting the four
corners C1,C2,C3,C4 in a clockwise direction 28, starting anywhere
on the closed convex polygon formed by the runway 27
[0154] Define the thickness of the zone (height above the runway)
29
[0155] The 4 corner 3-D coordinates and min and max altitudes are
obtained through the use of a program using the ALP, then
conversion are performed if necessary to convert from ALP
coordinates to ECEF X, Y, Z values.
9 C1 = X1, Y1, Z1 C2 = X2, Y2, Z2 C3 = X3, Y3, Z3 C4 = X4, Y4, Z4
MINALT = SQRT(XMIN.sup.2 + YMIN.sup.2 + ZMIN.sup.2) MAXALT =
SQRT(XMAX.sup.2 + YMAX.sup.2 + ZMAX.sup.2) HEIGHT = MAXALT -
MINALT
[0156] Define the (4) planes formed by the vectors originating at
the center of mass of the earth and terminating at the respective
four runway corners. Represent the 4 planes by the vector cross
product as indicated below:
10 XP1 = C1 .times. C2 XP2 = C2 .times. C3 XP3 = C3 .times. C4 XP4
= C4 .times. C1
[0157] Store the vector cross products in the polygon zones
database, where the number of stored vector cross products equals
the number of sides of the convex polygon
[0158] Determine if the present position or projected position is
within the zone (PP=position to be checked)
PP=PX1, PY1, PZ1
[0159] Determine the scalar Dot product between the current
position and the previously calculated Cross Products
11 DP1 = PP * XP1 DP2 = PP * XP2 DP3 = PP * XP3 DP4 = PP * XP4
[0160] If the products are negative then PP is within the volume
defined by intersection planes, if it is positive then outside the
volume defined by the intersecting planes.
[0161] Note: the signs reverse if one proceeds around the zone in a
counter clockwise direction during the definition process
[0162] Determine if PP is within the height confines of the
zone
[0163] Determine the magnitude of the PP vector, for an origin at
center of mass of the earth.
PPM=SQRT[(PX1).sup.2+(PY1).sup.2+(PZ1).sup.2]
[0164] Compare PPM=(PP magnitude) to minimum altitude of zone and
maximum altitude of zone
MINALT<=PPM<=MAXALT
[0165] If the above relationship is true then in the zone.
[0166] If false then outside of the zone
[0167] An alternate method of determining if the present position
PP is within a zone which is not normal to the earth's surface is
determined using a method similar to that above, except that all N
sides of the zone are represented as normal cross products, the
corresponding Dot products are calculated and their total products
inspected for sign. Based upon the sign of the product PP is either
out of or inside of the zone.
[0168] An example of actual Zone and Runway Incursion software code
is contained shown below. The actual code includes interfaces to
light control, clearance status, tones and other ATC functions.
[0169] Since the extension to polygons of N sides based upon the
previous concepts are easily understood, the derivation has been
omitted for the sake of brevity.
[0170] In summary two mathematical methods are identified for
detecting zone incursions into convex polygons, one based on the
equation and slope of the lines, the other is based on vector cross
and dot product operators.
[0171] The concept of zones, regardless as to whether they are
referenced to surface coordinates, local grid systems or ECEF
coordinates, provide a powerful analytical method for use in the
Airport Control and Management System.
Zone Based Clearances
[0172] The airport control and management system manages overall
taxi, departure and arrival clearances in a unique and novel manner
through the use of zone processing. A departure ground taxi
clearance is issued to the selected vehicle. The waypoints and
travel path are drawn into the map aboard the selected vehicle. The
vehicle(s) then use the presented taxi information to proceed to
the final waypoint. AC&M processing uses this clearance
information to mask runway zone incursions along the travel path.
Since runway incursions are masked for only the selected vehicle
and for zones traversed no runway incursion alert actions or
warning lights are produced when following the proper course.
Should the position represent movement outside of the extablished
corridor, an alert is issued signifing an off course condition
exist for that vehicle. Upon the vehicle exit from a particular
"cleared" zone, the mask is reset for that zone. Once the last
waypoint is reached the clearance is removed and the zone mask is
reset. The description below details how such clearances are
managed.
Surface Departure Clearance Management Method
[0173] 1. The operator or controller wishes to issue a surface
departure clearance to a specific vehicle.
[0174] 2. Through the use of a data entry device such as a touch
screen or keyboard or mouse, issue waypoints command is selected
for surface departure waypoints
[0175] 3. The operator is asked to select a specific vehicle from a
list of available aircraft and vehicles
[0176] 4. The vehicle data window then displays a scrollable list
of available vehicles contained in a database which are capable of
performing operations of departure clearance
[0177] 5. The operator then selects the specific vehicle using a
data entry device such as a touch screen or other data entry
device
[0178] 6. A list is then displayed in a scrollable graphical window
of available departure travel paths for the selected vehicle
[0179] 7. The operator then selects from this list using a data
entry device such as a touch screen or other data entry device
[0180] 8. Upon selection of a particular departure path the
waypoints and travel path are drawn into a 3-D ALP. The purpose of
presentation is to show the controller or operator the actual path
selected
[0181] 9. The controller or operator is then asked to confirm the
selected path. Is the selected path correct? Using a data entry
device such as a touch screen or other data entry device a
selection is made.
[0182] 10. If the selected path was not correct, then the command
is terminated and no further action is taken
[0183] 11. If the selection was correct the following steps are
taken automatically.
[0184] a. AC&M processing sends to the selected vehicle using a
radio duplex datalink, the clearance, 4-D waypoint and travel path
information
[0185] b. The selected vehicle upon receipt of the ATC command
replies with an acknowledgment. The acknowledgment is sent over the
full duplex radio datalink to the AC&M processing
[0186] c. Should the AC&M processing not receive the
acknowledgment in a specified amount of time from the selected
vehicle, a re-transmission occurs up to a maximum of N
re-transmissions
[0187] d. The vehicle upon receiving the ATC command then "loads"
the 4-D navigator with the 4-D waypoint information. A map display
contained in the vehicle then draws into the 3-D ALP the departure
travel path as shown in FIG. 8. This figure shows travel path as 30
in the digital ALP 31 while actual waypoints are shown as (14)
spheres 32.
Departure Clearance Management Method
[0188] 1. The operator or controller wishes to issue a departure
clearance to a specific aircraft
[0189] 2. Through the use of a data entry device such as a touch
screen or keyboard or mouse, issue waypoints command is selected
for departure waypoints
[0190] 3. The operator is asked to select a specific vehicle from a
list of available aircraft
[0191] 4. The vehicle data window then displays a scrollable list
of available aircraft contained in a database which are capable of
performing operations of departure clearance
[0192] 5. The operator then selects the specific vehicle using a
data entry device such as a touch screen or other data entry
device
[0193] 6. A list is then displayed in a scrollable graphical window
of available departure travel paths for the selected vehicle
[0194] 7. The operator then selects from this list using a data
entry device such as a touch screen or other data entry device
[0195] 8. Upon selection of a particular departure path the
waypoints and travel path are drawn into a 3-D ALP. The purpose of
presentation is to show the controller or operator the actual path
selected
[0196] 9. The controller or operator is then asked to confirm the
selected path. Is the selected path correct? Using a data entry
device such as a touch screen or other data entry device a
selection is made.
[0197] 10. If the selected path was not correct, then the command
is terminated and no further action is taken
[0198] 11. If the selection was correct the following steps are
taken automatically.
[0199] a. AC&M processing sends to the selected vehicle using a
radio duplex datalink, the clearance, 4-D waypoint and travel path
information
[0200] b. The selected vehicle upon receipt of the ATC command
replies with an acknowledgment. The acknowledgment is sent over the
full duplex radio datalink to the AC&M processing
[0201] c. Should the AC&M processing not receive the
acknowledgment in a specified amount of time from the selected
vehicle, a re-transmission occurs up to a maximum of N
re-transmissions
[0202] d. The vehicle upon receiving the ATC command then "loads"
the 4-D navigator with the 4-D waypoint information. A map display
contained in the vehicle then draws into the 3-D ALP the departure
travel path as shown in FIG. 9. This figure shows travel path as 34
in the digital ALP 35 while actual waypoints are shown as (5)
spheres 36.
[0203] 12. Upon AC&M receiving the acknowledgment, the
following is performed:
[0204] a. the zone mask is updated indicating that the selected
vehicle has a clearance to occupy runway(s) and taxiway(s) along
the travel path. This mask suppresses zone runway incursion logic
for this vehicle.
[0205] b. the zone based lighting control processing then activates
the appropriate set of airport lights for the issued clearance in
this case Take Off Lights
[0206] 13. The vehicle now has active navigation information and
may start to move, sending out ADS message broadcasts over the
datalink to other vehicles and the AC&M system
[0207] 14. The selected vehicle ADS messages are received at the
AC&M system and at other vehicles.
[0208] 15. AC&M processing using information contained in the
ADS message performs mirrored navigational processing, as outlined
in a latter section.
[0209] 16. Zone incursion checking is performed for every received
ADS message using position projection techniques for zones
contained in the zones database
[0210] 17. Should a zone incursion be detected, the zone mask is
used to determine if the incurred zone is one which the vehicle is
allowed to be in. If the zone is not in the zone mask then a
warning is issued. Should the zone be that of a Runway, a Runway
Incursion Alert is Issued and the appropriate airport lights are
activated.
[0211] 18. The ADS position is used to determine when the vehicle
leaves a zone. When the vehicle leaves the zone, the clearance mask
is updated indicated travel though a particular zone is complete.
When this occurs the following steps are initiated by the
AC&M:
[0212] a. the zones mask is updated
[0213] b. airport light status is updated
[0214] If the exited zone was a Runway, operations may now occur on
the exited runway
[0215] 19. The vehicle continues to travel towards the final
waypoint
[0216] 20. At the final waypoint the navigator and the map display
are purged of active waypoint information, meaning the vehicle is
where it is expected to be. New waypoints may be issued at any time
with a waypoints command function.
[0217] AC&M zones based clearance function as presented here
provides a unique and automated method for the controlling and
managing airport surface and air clearances.
Collision Detection
[0218] Collision detection is performed through the zones
management process. The basic steps for collision detection and
avoidance are shown below in a general form. FIG. 10 shows
graphically what the following text describes.
[0219] 1. Vehicle Position, Velocity and Time (PVT) information are
received for all tracked vehicles. The following processing is
performed for each and every ADS vehicle report
[0220] 2. PVT information is converted to the appropriate
coordinate system if necessary and stored in the database
[0221] 3. A rough check zone 38 and 39 is established based on the
current velocity for each vehicle in the database
[0222] 4. Every vehicle's rough check radius is compared with every
other vehicle in the database. This is done simply by subtracting
the current position of vehicle V from the position of vehicle V+1
in the database to determine the separation distance between each
vehicle and every other vehicle in the database. This is performed
in the ECEF coordinate frame.
[0223] 5. For each pair of vehicles in the database that are within
the sum of the two respective rough check radii values; continue
further checking since a possible collision condition exists, if
not within the sum of the rough check radii do no further
processing until the next ADS message is received
[0224] 6. For each set of vehicles which have intersecting rough
check radii project the position ahead by an increment of Time (t)
using the received vehicle velocity and optionally acceleration
information. Projected positions at time=T1 are shown by two
circles 40 and 41 the minimum safe clearance separation for the
fuel truck R1 and aircraft R2 respectively.
[0225] 7. Determine the new separation distance between all
vehicles which initially required further checking. Compare this
distance to the sum of minimum safe clearance distances R1 and R2
for those vehicles at the new incremented time. The minimum safe
clearance distances R1 and R2 are contained in a database and is a
function of vehicle velocity and type. Should the separation
distance 42 between them be less than the sum of the minimal safe
clearance distances R1+R2, then generate alert warning condition.
Record the collision time values for each set of vehicles checked.
If no minimum safe clearance distance is violated then continue
checking the next set of vehicles in a similar fashion. When all
vehicles pairs are checked then return to the start of the vehicle
database.
[0226] 8. Increment the projection time value (T+t) seconds and
repeat step 7 if separation was greater than the sum of the minimal
safe separation distance R1+R2. Continue to increment the time
value to a maximum preset value, until the maximum projection time
is reached, then process next pair of vehicles in a similar
fashion, until the last vehicle is reached at that time start the
process over. If minimum safe clearance (R1+R2) was violated
compare the time of intersection to the previous time of
intersection. If the previous intersection time is less than the
new intersection time the vehicles are moving apart, no collision
warning generated. In the event that the vehicles are moving
together, meaning the intersection times are getting smaller,
determine if a course change is expected based upon the current
waypoints issued, and if the course change will eliminate the
collision condition. If a course change is not expected or if the
course change will not alleviate the collision situation then
generate alert. If the projection time T is less than the maximum
projection time for warning alerts, generate a warning. If the
projection time T is greater than the maximum projection time for a
warning alert and less than the maximum projection time for a watch
alert, generate a watch alert. If the projection time T is greater
than the maximum projection time for a watch alert generate no
watch alert.
[0227] 9. The warning condition generates a message on the ALERT
display identifying which vehicles are in a collision warning
state. It also elevates the layer identifier code for those
vehicle(s) to an always displayed (non-maskable) warning layer in
which all potentially colliding vehicles are displayed in RED. 10.
The watch condition generates a message on the ALERT display
identifying which vehicles are in a collision watch state. It also
elevates the layer identifier code for that vehicle(s) to an always
displayed (non-maskable) watch layer in which all potentially
colliding vehicles are displayed in YELLOW.
[0228] 11. The process continually runs with each new ADS message
report.
Collision Processing Software Example
[0229] The sample code below performs the above collision
processing, without the routine which checks for course changes, to
reduce false alarms.
[0230]
/******************************************************************-
****
[0231] File Name: collpred.c
[0232] Description: collpred.c contains the routines which update
the vehicle database and perform collision prediction
algorithms.
[0233] Units: get_veh_index, store_remote_msg, chk_for_collisions,
convert_veh
[0234]
/*------------------------------------------------------------------
-----*/
[0235] #include <stdio.h>
[0236] #include <string.h>
[0237] #include <stdlib.h>
[0238] #include <graph.h>
[0239] #include <math.h>
[0240] #include "veh.h"
[0241] #include "sio.h"
[0242] #include "coord.h"
[0243] #include "color.h"
On or Off Course Processing
[0244] The AC&M processing performs mirrored navigational
processing using the same coordinate references and waypoints as
those aboard the vehicles. In this manner the ATC system can
quickly detect off course conditions anywhere in the 3-D airport
space envelope and effectively perform zone incursion processing
aboard the vehicles and at the AC&M.
[0245] The AC&M processing software converts the position and
velocity information to the appropriate coordinate frame (zone
& map compatible) using techniques described previously.
Waypoints based upon the precise 3-dimensional map are used for
surface and air navigation in the airport space envelope. The
capability is provided to store waypoints in a variety of
coordinate systems, such as conventional Latitude, Longitude, Mean
Sea Level, State Plane Coordinates, ECEF X, Y, Z and others. The
navigational waypoint and on course--off course determinations are
preferred to be performed in an ECEF X, Y, Z coordinate frame, but
this is not mandatory.
[0246] The following mathematical example is provided to show how
waypoints and trajectories are processed in Latitude, Longitude,
Mean Sea Level and in ECEF X, Y, Z. An actual GNSS flight
trajectory is used for this mathematical analysis. The flight
trajectory has been previously converted to an ECEF X, Y, Z format
as have the waypoints using the previously described techniques.
FIGS. 11,12,13,14,15 are used in conjunction with the following
description.
[0247] FIG. 11 depicts the ECEF waypoint processing used in the
AC&M. The ECEF coordinate system 43 is shown as X,Y,Z, the
origin of the coordinate system is shown as 0,0,0. The coordinate
system rotates 44 with the earth on its polar axis. The airport 45
is shown as a square patch. An enlarged side view of the airport 46
is shown with (4) waypoints 47. A further enlargement shows the
Present Position 48 (PP), the Next Waypoint 49 (NWP) the Previous
Waypoint (PWP) 50. The True Course Line 58 is between the Next
Waypoint 49 and Previous Waypoint 50. The vector from the Present
Position 48 to the Next Waypoint 49 is vector TNWP 51. The Velocity
Vector 52 and the Time Projected Position is shown as a solid black
box 53. The Projected Position 53 is used in zone incursion
processing. The 3-D distance to the true coarse is represented by
the Cross Track Vector 54 XTRK. The vector normal to the earth
surface at the present position and originating at the center of
mass of the earth is shown as 55. This vector is assumed to be in
the same direction of the vertical axis 56. The lateral axis 57 is
perpendicular to the vertical axis and perpendicular to the true
course line 58 between the Next Waypoint 49 and the Previous
Waypoint 50. The Navigational Display 59 shows the Present Position
48 with respect to the True Course Line 58.
[0248] The following equations describe the processing performed in
the AC&M while FIGS. 12, 13, 14, and 15 represent plots of the
actual trajectory information.
12 Variable Definition .OMEGA. = the number of degrees per radian
57.295779513 .alpha. = semi major axis, equatorial radius 6378137
meters e = earth's eccentricity 0.0818182 TALT = ellipsoidal
altitude of trajectory position (meters) WALT = ellipsoidal
altitude of the waypoint positions (meters) .rho. = earth's radius
of curvature at the position or waypoint r = 2-d equatorial radius
(meters) R = first estimate of the radius of curvature (meters)
s.phi. = the ratio of ECEF Z value divided by R (meters) RC =
radius of curvature at the present position (meters) h = altitude
with respect to the reference ellipsoid (meters) .lambda. =
longitude of position in radians .phi. = latitude of position in
radians ENU = East, North, Up coordinate reference XYZ = East,
North, Up vector distance (meters) to waypoint VELENU = East,
North, Up velocity in (meters/sec) DISTENU = East, North, Up scalar
distance to waypoint VELEMUMAG = East, North, Up Velocity magnitude
(scalar) meters/sec NBEAR = True North Bearing T = Time in seconds
p.sub.wT = Earth's radius of curvature at the waypoint Waypoint
indexes through a list of waypoints Waypoints are indexed as a
function of position p.sub.T = Earth's radius of curvature at the
GNSS position Position LA.sub.T = Latitude LO.sub.T = Longitude
TALT.sub.T = altitude Waypoint WLA.sub.wT = Waypoint Lat.
WLO.sub.wT = Waypoint Lon. WALT.sub.wT = altitude Position X.sub.T
= ECEF X Y.sub.T = ECEF Y Z.sub.T = ECEF Z Waypoint A.sub.T =
Waypoint ECEF X B.sub.T = Waypoint ECEF Y C.sub.T = Waypoint ECEF
Z
[0249] EARTH RADIUS OF CURVATURE DETERMINATION 1 wT := 2 1 - 2 sin
( LA wT ) 2 T := 2 1 - 2 sin ( LA T ) 2
[0250] AT WAYPOINT AT GNSS POSITION
[0251] CONVERT TRAJECTORY TO ECEF COORDINATES
X.sub.T:=(TALT.sub.T+.rho..sub.T).multidot.cos(LA.sub.T).multidot.(LO.sub.-
T)
Y.sub.T:=(TALT.sub.T+.rho..sub.T).multidot.cos(LA.sub.T).multidot.sin(LO.s-
ub.T)
Z.sub.T:=[TALT.sub.T+.rho..sub.T).multidot.(1-e.sup.2)].multidot.sin(LA.su-
b.T)
[0252] CONVERT WAYPOINTS TO ECEF COORDINATES
A.sub.wT:=(WALT.sub.wT+.rho..sub.wT).multidot.cos(WLA.sub.wT).multidot.cos-
(WLO.sub.wT)
B.sub.wT:=(WALT.sub.wT+.rho..sub.wT).multidot.cos(WLA.sub.wT).multidot.sin-
(WLO.sub.wT)
C.sub.wT:=[WALT.sub.wT+.rho..sub.wT.multidot.(1-e.sup.2)].multidot.sin(WLA-
.sub.wT)
[0253] FIND VECTOR FROM PRESENT POSITION TO NEXT WAYPOINT
T=TIME OF TRAJECTORY DATA MATRIX INDEX
TIME INTO TRAJECTORY=61 SECONDS
[0254] CONSTRUCT ECEF WAYPOINT MATRIX Q 2 Q := [ A 0 B 0 C 0 A N B
N C N A 2 N B 2 N C 2 N A 3 N B 3 N C 3 N A 4 N B 4 N C 4 N A 5 N B
5 N C 5 N A 6 N B 6 N C 6 N A 7 N B 7 N C 7 N ]
[0255] WAYPOINT SELECTION CRITERIA #1 TIME BASED
[0256] TIME BASED WAYPOINT SELECTION TECHNIQUE DETERMINE NEXT
WAYPOINT FROM PRESENT POSITION 3 G n := until [ [ T N ( 1 + n ) ] -
1 , n + 1 ]
[0257] WAYPOINT SELECTION CRITERIA #2 POSITION BASED UTILIZES THE
CONCEPT OF ZONES, SEE ZONES 4 Q = [ 1491356.373377693 -
4435534.380128561 4319696.328998308 1491105.506082756 -
4434843.777395391 4320510.100123271 1491191.231021753 -
4434078.221408217 4321279.195524782 1491403.123106249 -
4433316.762941022 4322016.015673301 1491013.940737782 -
4432855.368457528 4322641.896808126 1490386.073951513 -
4432652.821583812 4323015.562834505 1489735.707050711 -
4432541.026386314 4323262.840511303 1489205.896384193 -
4432860.450400459 4322985.406680132 ]
[0258] DETERMINE VECTOR BETWEEN PREVIOUS AND THE NEXT WAYPOINT
Qa:=(Q.sub.a+1,0-Q.sub.a,0 Q.sub.a+1,1-Q.sub.a,1
Q.sub.a+1,2-Q.sub.a,2)
PP:=(X.sub.T Y.sub.T Z.sub.T) PRESENT POSITION
NWP:=[A.sub.N.multidot.(1+a) B.sub.N.multidot.(1+a)
C.sub.N.multidot.(1+a)] NEXT WAYPOINT
TNWP:=NWP-PP VECTOR DISTANCE TO THE NEXT WAYPOINT
AT FLIGHT TIME T=61 SECONDS, THE NEXT WAYPOINT IS THE FOLLOWING X,
Y, Z DISTANCE FROM THE CURRENT POSITION
TNWP=(-394.0104406164 424.5394341322 588.6638708804)
[0259] DETERMINE THE MAGNITUDE OF THE DISTANCE TO THE WAYPOINT
DIST:={square root}{square root over
((TNWP.sup.<0>).sup.2+(TNWP.sup-
.<1>).sup.2+(TNWP.sup.<2>).sup.2)}
[0260] DIST=825.8347966318 METERS
[0261] NEXT DETERMINE IF THE SPEED SHOULD REMAIN THE SAME, OR
CHANGE
[0262] TIME EXPECTED AT NEXT WAYPOINT IS 80 SECONDS INTO TRAJECTORY
CURRENT VELOCITY IS BASED UPON GNSS RECEIVER DETERMINATION 5 VX :=
TNWP < 0 > 80 - T
[0263] VX=-20.7373916114 M/S X ECEF VELOCITY TO REACH WAYPOINT ON
TIME
[0264] COMPARE CURRENT X VELOCITY TO REQUIRED X VELOCITY, IF LESS
INCREASE IN VELOCITY, IF GREATER THAN REQUIRED VELOCITY DECREASE
VELOCITY 6 VY := TNWP < 1 > 80 - T
[0265] VY=22.3441807438 M/S Y ECEF VELOCITY TO REACH WAYPOINT ON
TIME
[0266] COMPARE CURRENT Y VELOCITY TO REQUIRED Y VELOCITY, IF LESS
INCREASE IN VELOCITY, IF GREATER THAN REQUIRED VELOCITY DECREASE
VELOCITY 7 VZ := TNWP < 2 > 80 - T
[0267] VZ=30.9823089937 M/S Z ECEF VELOCITY TO REACH WAYPOINT ON
TIME
[0268] COMPARE CURRENT Z VELOCITY TO REQUIRED Z VELOCITY, IF LESS
INCREASE IN VELOCITY, IF GREATER THAN REQUIRED VELOCITY DECREASE
VELOCITY
VELECEF:={square root}{square root over
((VX.sup.2)+(VY.sup.2)+(VZ.sup.2))- } VELOCITY MAGNITUDE
[0269] VELECEF=43.4649892964 M/S
[0270] VELECEF=(-20.737 22.344 30.982)
[0271] DETERMINE THE ON COURSE OFF COURSE NAVIGATIONAL DATA
[0272] UNIT VECTOR PERPENDICULAR TO PLANE OF QA AND TNWP 8 NP := Qa
T .times. TNWP T Qa T .times. TNWP T NP = ( 0.2375540749 -
0.7054483132 0.6677654819 )
[0273] UNIT VECTOR PERPENDICULAR TO PLANE OF QA AND NP 9 UN := NP
.times. Qa T NP .times. Qa T UN = ( - 0.8621137731 - 0.4698689823 -
0.1896918074 )
[0274] CROSS TRACK ERROR
[0275] XTRK:=UN.multidot.TNWP.sup.T
[0276] XTRK=28.5392020973
[0277] CALCULATE CROSS TRACK VECTOR 10 VXTRK := XTRK UN VXTRK = ( -
24.6040392 - 13.4096858447 - 5.4136528281 )
[0278] UNIT VECTOR FROM PRESENT POSITION TO NEXT WAYPOINT 11 UTNWP
:= TNWP T TNWP T UTNWP = ( - 0.4771056417 0.514073076 0.7128106896
)
[0279] UNIT VECTOR OF PRESENT POSITION 12 UPP := PP T PP T UPP = (
0.2341833314 - 0.6961209085 0.6786559129 )
[0280] UNIT VECTOR OF NEXT WAYPOINT 13 UNWP := ( NWP T NWP T ) UNWP
= ( 0.2341210312 - 0.6960529621 0.6787470933 )
[0281] CHECK AGAINST GREAT CIRCLE TECHNIQUE
GREAT CIRCLE ANGLE .beta.:=a cos(UNWP.multidot.UPP)
.beta..multidot..OMEGA.=0.0074290102 DEGREES
[0282] DETERMINE RANGE TO NEXT WAYPOINT FROM PRESENT POSITION h=0
SHOULD BE THE SAME AS DIST WHEN ALT IS NEARLY AT ELLIPSOID 14 R3 :=
( NWP T + PP T ) 2 R3 = 825.7511698494 R3 - DIST = - 0.0836267824
METERS METERS
[0283] `THE ECEF ANALYSIS COMPARES TO GREAT CIRCLE ANALYSIS VERY
CLOSELY`
[0284] CONVERTING BACK TO LAT. LON AND MSL
[0285] DETERMINE GEODETIC PARAMETERS (LAT, LON & EL)
13 15 r := ( PP < 0 > ) 2 + ( PP < 1 > ) 2 16 R := ( 1
- e 2 ) 2 r 2 + ( PP < 2 > ) 2 17 s := ( PP < 2 > ) 2 R
2 18 RC := 2 1 - e 2 s 2 19 h := R - ( 1 - e 2 ) RC 1 - e 2 + e 2 s
2 h = 287.6967718417 20 := atan [ ( PP T ) 1 ( PP T ) 0 ] 21 :=
atan [ ( PP T ) 2 r ( 1 - e 2 ) ] .lambda. .multidot. .OMEGA. =
-71.40645 .phi. .multidot. .OMEGA. = 42.930575339
[0286] CONVERT TO ENU COORDINATES 22 ENU := [ - sin ( ) cos ( ) 0 -
sin ( ) cos ( ) - sin ( ) sin ( ) cos ( ) cos ( ) cos ( ) cos ( )
sin ( ) sin ( ) ]
[0287] FIND ENU VECTOR FROM PRESENT POSITION TO NEXT WAYPOINT
[0288] EAST DISTANCE
[0289] NORTH DISTANCE
[0290] UP DISTANCE 23 XYZ := ENU ( TNWP T ) XYZ = ( -
238.0792858938 790.6424859464 14.3465805212 )
[0291] EAST VEL.
[0292] NORTH VEL.
[0293] UP VEL 24 VELENU := ENU ( VELECEF T ) M / S VELENU = ( -
12.5301751909 41.6123344504 0.7550895802 ) DISTENU:={square
root}{square root over ((XYZ.sub.0).sup.2+(XYZ.sub.1).s-
up.2+(XYZ.sub.2).sup.2)}
[0294] DIST=825.8347966318 METERS
VELENUMAG:={square root}{square root over
((VELENU.sub.0).sup.2+(VELENU.su-
b.1).sup.2+(VELENU.sub.2).sup.2)}
[0295] VELENUMAG=43.4644892872 M/S
[0296] THE ECEF APPROACH AND THE ENU APPROACH PRODUCE THE SAME
RESULTS SO IT IS POSSIBLE TO USE EITHER COORDINATE REFERENCE TO
CONTROL THE NECESSARY SPEED TOTHE WAYPOINT
[0297] FIND TRUE NORTH BEARING ANGLE TO NEXT WAYPOINT USING TANGENT
25 NBEAR := atan ( XYZ 0 XYZ 1 ) NBEAR = - 16.7581666051
DEGREES
[0298] ADJUST FOR TRIGONOMETRIC QUADRANTS AND YOU HAVE THE TRUE
BEARING
[0299] Should the Range to the Waypoint become larger than the
previous range of the waypoint a waypoint may not have
automatically indexed. This situation could occur if the vehicle
did not get close enough to the waypoint to index automatically or
an ADS message may have been garbled and the waypoint did not
index, due to a lost ADS message. In this case the following
analysis is performed:
[0300] a) temporarily increment the waypoint index
[0301] b) find the vector between the vehicles present position
(PP) and the next waypoint (NWP)
Vector to the next waypoint, TNWP=NWP(X,Y,Z)-PP(X,Y,Z)
[0302] c) Determine the current vehicle velocity vector
VEL=(VX,VY,VZ)
[0303] d) Determine the Dot Product between the Velocity Vector and
Vector TNWP
COS .theta.=TNWP dot VEL
[0304] e) If A< COS .theta.<B then keep current waypoint
index
[0305] Where A and B are between 0 and 1 and represent an
adjustable value based on the allowable vehicle velocity angular
deviation from the true course
[0306] If -1<COS .theta.<=0 then return to previous waypoint
index and generate wrong way alert The above technique can be
expanded to include curved approach, using cubic splines to smooth
the transitions between waypoints. A curved trajectory requires
changes to the above set of equations. Using the technique of cubic
splines, one can calculate three cubic equations which describe
smooth (continuous first and second derivatives) curves through the
three dimensional ECEF waypoints. The four dimensional capability
is possible when the set of cubic equations is converted into a set
of parametric equations in time. The table below depicts an ECEF
waypoint matrix which is used in cubic spline determinations.
Typical Waypoint ECEF Matrix
[0307] The AC&M processing utilizes the combination of precise
ECEF X, Y, Z navigation and waypoints. Waypoints may be stored in a
data file for a particular runway approach, taxi path or departure
path. Waypoints may be entered manually, through the use of a data
entry device. A list of waypoints describing a flight and or taxi
trajectory is then assigned to a particular vehicle. To further
supplement waypoint processing expected arrival time may be added
to each waypoint as well as velocity ranges for each phase of
flight. In this manner, 4 dimensional airport control and
management is provided utilizing a GNSS based system. Mathematical
processing is used in conjunction with precise waypoints to define
flight trajectories. The mathematics typically uses cylindrical
shapes but is not limited to cylinders, cones may also be used, and
are defined between adjacent waypoints. Typical on or off course
processing is outlined below and is shown in FIG. 16.
EXAMPLE 1
Missed Waypoint, with off Course Condition
[0308] a. Construct the True Course line between the previous
waypoint 61 and the next waypoint 62
[0309] b. Determine the shortest distance (cross track error 64)
from the current position 63 to the line 60 between the previous
waypoint 61 and next waypoint 62
[0310] c. Determine the magnitude of cross track error
[0311] d. Compare the magnitude of the cross track error to a
predefined limit for total off course error shown as 65 in the
figure.
[0312] e. Construct an mathematical cylindrical zone centered on
the line between the previous 61 and next waypoint 62 with radius
equal to the off course threshold 65.
[0313] f. If the magnitude of the cross track error 64 is greater
than the off course threshold 65 then raise flag and generate alert
(off course).
[0314] g. Determine the necessary velocity to reach next waypoint
on schedule, as shown previously
[0315] h. Is necessary velocity within preset limits or
guidelines?
[0316] i. Check actual current velocity against preset limits and
necessary velocity, If above preset limits, raise flag and issue
alert to slow down. If below preset limits, raise flag and issue
alert to speed up
[0317] j. Automatically index to the following waypoint 66 when the
position is within the index waypoint circle 67
[0318] k. Should wrong way be detected (positions 68 and 69), index
ahead to the next to waypoint pair 66 and 62 and check direction of
travel 71 (Velocity) against the line 72 between the waypoints 66
and 62, if the direction of travel is within a preset angular range
70 (A to B degrees) and not off course. If the check is true
meaning not off course and headed towards next waypoint then index
permanently to waypoint set 66 and 62, no alert generated
[0319] l. In the event that an off course condition and wrong way
occur (position 69) a message is formatted which updates the layer
filter for the target which is off course, an alert is generated,
the waypoints are returned to the initial settings and action is
taken to bring vehicle back on course possibly using a set of new
waypoints
[0320] m. In the event of a velocity check which indicates that the
speed up or slow down velocity is outside of an approved range,
generate a warning the speed for vehicle is out of established
limits, Preset speed over ground limits are adjusted for current
air wind speed.
[0321] n. The controller reviews the situation displayed and if
necessary invokes a navigational correction message to be sent to
the Real Time Communication Handler, and then broadcast by radio to
the aircraft off course or flying at the wrong speed. The
controller at this time may change the expected arrival time at the
next waypoint if so necessary
EXAMPLE 2
Missed Waypoint, with on Course Processing
[0322] a. Construct the True Course line between the previous
waypoint 66 and the next waypoint 72
[0323] b. Determine the shortest distance (cross track error 73)
from the current position 74 to the line between the previous
waypoint 66 and next waypoint 72
[0324] c. Determine the magnitude of cross track error
[0325] d. Compare the magnitude of the cross track error to a
predefined limit for total off course error shown as 75 in the
figure.
[0326] e. Construct an mathematical cylindrical zone centered on
the line between the previous waypoint 66 and next waypoint 72 with
radius equal to the off course threshold 75
[0327] f. If the magnitude of the cross track error 73 is greater
than the off course threshold 75 then raise flag and generate alert
(off course).
[0328] g. Determine the necessary velocity to reach next waypoint
on schedule, as shown previously
[0329] h. Is necessary velocity within preset limits or
guidelines?
[0330] i. Check actual current velocity against preset limits and
necessary velocity, If above preset limits, raise flag and issue
alert to slow down. If below preset limits, raise flag and issue
alert to speed up
[0331] j. Automatically index to the following waypoint 76 when the
position is within the index waypoint circle 77
[0332] k. Should wrong way be detected (position 74), index ahead
to the next to waypoint pair 76 and 72 and check direction of
travel 78 (Velocity) against the the line 80 between the waypoints
76 and 72, if the direction of travel is within a preset angular
range 79 (A to B degrees) and not off course. If the check is true
meaning not off course and headed towards next waypoint then index
permanently to waypoint set 76 and 72, no alert generated
[0333] l. In the event of a velocity check which indicates that the
speed up or slow down velocity is outside of an approved range,
generate a warning the speed for vehicle is out of established
limits, Preset speed over ground limits are adjusted for current
air wind speed.
[0334] m. The controller reviews the situation displayed and if
necessary invokes a navigational correction message to be sent to
the Real Time Communication Handler, and then broadcast by radio to
the aircraft off course or flying at the wrong speed. The
controller at this time may change the expected arrival time at the
next waypoint if so necessary
[0335] The AC&M processing performs all on or off course
processing determinations and the displays information related to
on or off course or late or early arrival conditions.
Alert Display Function
[0336] Within the AC&M system collision alerts, zone, off
course and improper speed warnings are handled somewhat differently
than normal position updates. When the AC&M processing
recognizes a warning condition, the aircraft(s)/vehicle(s) involved
are moved to a special ALP layer. The layer filter controls what
graphic parameters a particular vehicle or aircraft is displayed
with. The change in the layer from the default vehicle layer
signifies that the target has been classified as a potential
collision, zone intrusion risk, off course condition or improper
speed.
AC&M Control Zones
[0337] ATC Control Zones are used to sort and manage air and
surface traffic within the airport space envelope. The AC&M
Control Area is divided into AC&M Control Zones. Typically the
outer most airport control zone interfaces with an en route zone.
Aircraft within the 3-D AC&M zone transmit their GNSS derived
positions via an on board datalink. The GNSS data is received by
the airport AC&M equipment. The AC&M Processing determines
the ECEF AC&M Control Zone assignment based on the aircraft's
current position and assigns the aircraft to the map layer
associated with that Control Zone. Mathematical computations as
defined previously, are used to determine when a vehicle is in a
particular control zone.
[0338] As an aircraft enters the AC&M or transitions to another
ATC Control Zone, a handoff is performed between the controllers
passing and receiving control of that aircraft. Surface traffic is
handled in the same manner. With this AC&M scenario, each
controller receives all target information but suppresses those
layers that are not under his control. In this manner the
controller or operator views on those vehicles or aircraft in his
respective control zone. Should there be a collision condition
across an ATC zone boundary the conflicting vehicles will be
displayed in a non-surpressable layer.
[0339] All targets within an AC&M Control Zone would be placed
in the appropriate map layer for tracking and display purposes.
Layer coding for each tracked target can be used to control graphic
display parameters such as line type, color, line width as well as
be used as a key into the underlying database for that object.
[0340] Additional AC&M Control Zones may be defined for other
surface areas of the airport, such as construction areas, areas
limited to specific type of traffic, weight limited areas and
others. These areas may be handled through ATC but will most or be
controlled by airline or airport maintenance departments. The
concept of a zone based AC&M system integrated with 3-D map
information provides a valuable management and navigational
capability to all vehicles and aircraft within the airport space
envelope.
Entering Waypoints
[0341] The AC&M processing defined herein allows the user to
enter waypoints using the digital map as a guide. To enter a series
of waypoints the controller simply uses the map which may provide
plan and side views of the airport space envelope. The cursor is
moved to the appropriate point and a selection is made by pressing
a key. The position is then stored in a list with other waypoints
entered at the same time. The user is then prompted to enter a name
for the waypoint list and an optional destination. Lastly, the
waypoints converted the appropriate coordinate frame and are then
saved to a file or transmitted to a particular vehicle. In this
manner the user may add and define waypoints.
Defining Zones
[0342] The user may define zones using the digital map as a guide.
To enter a series of zones the controller simply uses the map which
may provide plan and side views of the airport space envelope. The
cursor is moved to the appropriate point and a selection is made by
pressing a key. The position is then stored in a list with other
zone definition points. The controller is then prompted to enter a
name for the zone (pole, tower, construction area, etc.) and type
of zone (circle, sphere, box, cylinder, etc.). Lastly, the zones
are converted to the appropriate coordinate frame and saved to a
file or transmitted to a particular vehicle. In this manner the
user may define additional zones.
[0343] The ability to quickly and accurately define zones is key to
the implementation of a zones based AC&M capability.
ADS Message Format Considerations
[0344] The definition and standardization of a `seamless` aviation
system datalink format(s) is critical to the implementation of a
GNSS-based aviation system.
Sample ADS Message Format
[0345] Perhaps the most basic issue which must be resolved in the
determination of the datalink format, is the selection of the
coordinate system and units for the GNSS-derived position and
velocity data. Compatibility with digital and paper maps,
navigation system and overall mathematical processing efficiency
play major roles in the selection of the coordinate reference.
Below is a list of criteria which are used in this
determination:
ADS Message Format Criteria Definitions
[0346]
14 WORLD WIDE USE The coordinate reference system is recognized
throughout the world. Scale does not change as a function of where
you are on the earth. SIMPLE NAVIGATION The coordinate system lends
itself MATHEMATICS to simple vector navigational mathematics.
COMPATIBLE WITH The coordinate reference can COMPLEX 4-D CURVED
support curved trajectory PATH 4-D NAVIGATION mathematics.
FUNCTIONS COMPATIBLE WITH Is compatible with management MANAGEMENT
SYSTEM operations at ATC and aboard A/Vs. COMPATIBLE WITH SPACE The
coordinate system is compatible OPERATIONS with low earth orbit or
space-based operations. NAD83 AND WGS84 REF. The reference system
is compatible with NAD 83 and WGS 84 SINGLE ORIGIN The system has
one single point origin. LINEAR SYSTEM The system is a linear
coordinate system and does not change scale as a function of
location. UNITS OF DISTANCE The coordinate system is based on units
of distance rather than angle NO DISCONTINUTITIES The coordinate
reference system is continuous world wide.
[0347] The ECEF X, Y, Z Cartesian coordinate system satisfies all
of the above criteria. Other systems may be used such as, Universal
Transverse Mercator, Latitude, Longitude and Mean Sea Level and
other grid systems but additional processing overhead and
complexities are involved. A representative ADS message structure
is provided below:
15 SAMPLE AIRPORT ECEF MESSAGE CONTENT ID # 8 Characters VEHICLE
TYPE 4 Characters CURRENT POSITION: ECEF X Position (M) 10
Characters ECEF Y Position (M) 10 Characters ECEF Z Position (M) 10
Characters ECEF X2 Position (M) 4 Characters * ECEF Y2 Position (M)
4 Characters * ECEF Z2 Position (M) 4 Characters * ECEF X3 Position
(M) 4 Characters * ECEF Y3 Position (M) 4 Characters * ECEF Z3
Position (M) 4 Characters * ECEF X Velocity (M/S) 5 Characters ECEF
Y Velocity (M/S) 5 Characters ECEF Z Velocity (M/S) 5 Characters
NEXT WAYPOINT (WHERE HEADED INFORMATION): ECEF X 10 Characters ECEF
Y 10 Characters ECEF Z 10 Characters TIME 8 Characters
[0348] A bit oriented protocol, representing the same type of
information, may be used to streamline operations and potential
error correction processing. (The asterisks denote optional fields
which may be used to determine the attitude of an aircraft.)
[0349] The individual fields of the ADS message are described
below:
[0350] ID (8 Character Word, Alpha-Numeric)
[0351] The ID field is used to identify the particular vehicle or
aircraft. For aircraft this is typically the flight number or, in
the case of GA or private aircraft, the tail number. For airport
surface vehicles it is the vehicle's callsign.
[0352] Type of Vehicle (4 Character Word, Alpha-Numeric)
[0353] The vehicle type is used to identify the A/V's type
classification. Numerous type classifications may be defined to
categorize and identify various aircraft and surface vehicles.
[0354] Current ECEF X,Y,Z Position (10 Characters by 3 Words)
[0355] The ECEF X,Y,Z position fields provide the vehicle's
position at the time of the ADS transmission in ECEF X,Y,Z
coordinates. The position is calculated by the GPS receiver. Based
on the system design, these values may or may not be smoothed to
compensate for system latencies. The message length of 10
characters provides a sign bit in the most significant digit and 9
digits of positional accuracy. The least significant digit
represents 0.1 meter resolution. This provides a maximum ADS
distance of +9999999.9 which translates to an altitude of about
3600 KM above the earth's surface, providing sufficient coverage to
support low earth orbiting satellites and spacecraft.
[0356] Delta Positions (Relative Positions, 4 Characters by 6
Words)
[0357] Delta positions are used to represent the positional offset
of two other GPS antenna locations. These locations can be used to
determine the attitude of the aircraft or its orientation when it
is not moving. All delta distances are calculated with respect to
the current ECEF position. Straight forward ECEF vector processing
may then be used to determine the attitude and orientation of the
aircraft with respect to the ECEF coordinate frame. An
ECEF-to-local on board coordinate system (ie. North, East, Up)
conversion may be performed if necessary. Accurate cross wind
information can be determined on the ground and on board the
aircraft from delta position information. Delta positions may also
be used as 3-D graphical handles for map display presentations.
[0358] The message length of 4 characters provides a sign bit in
the most significant digit and 3 digits of delta position accuracy.
The least significant digit represents 0.1 meter resolution.
[0359] ECEF X,Y,Z Velocity (5 Characters by 3 Words)
[0360] The fields represent the A/V's ECEF X,Y,Z velocity in meters
per second. Tenth of a meter/second resolution is required during
the ground phase of GPS based movement detection, latency
compensation, zone and collision detection processing.
[0361] The message length of 5 characters provides a sign bit in
the most significant digit and 4 digits of velocity accuracy.
[0362] Next Waypoint (10 Characters by 3 Words)
[0363] These fields describe where the A/V is currently headed, in
terms of the ECEF X,Y,Z coordinates of the next waypoint. This
provides intent information which is vital to the collision
avoidance functions.
[0364] Time (Universal Coordinated Time) 8 Characters
[0365] This field identifies the Universal Coordinated Time at the
time of the ADS transmission. This time is the GPS derived UTC time
(in seconds) plus any latency due to processing delays
(optional).
[0366] The ADS message format provides a very valuable set of
information that simplifies mathematical processing. Since the ECEF
cartesian coordinate frame is native to every GPS receiver, no
additional GPS burden is incurred. This type of ADS broadcast
message information is more than adequate for precision ground and
air operations as well as for general ATC/airport control and
management functions.
Overview of Candidate ADS Architectures
[0367] Many communication technologies are available which can
provide ADS capability. Many of the systems already exist in some
form today, but may require modification to meet the requirements
of ADS in the terminal area. In evaluating datalink candidates, it
is important that future airport standards are not compromised by
forcing compatibility with the past. Systems should develop
independently in a manner designed to achieve the systems' maximum
operational benefits. Transitional elements and issues of
compatibility with current systems are better handled through the
implementation of translators which do not detract from a future
system's true potential.
[0368] Mode S Interrogation
[0369] The Mode S system is in use today and is compatible with
today's en route radar and Terminal Radar Approach Control
(TRACON)-based air traffic control systems. Current Mode S 1030 MHZ
interrogation is performed using Mode S radars which scan at the
4.8 second rate. The scan rate represents the rotational period of
the scanning antenna. When a target is interrogated by the radar
pulse, the aircraft or vehicle broadcasts its GPS-based information
to air traffic control at 1090 MHZ. In this manner, ADS information
is received by ATC and by other interrogating sources.
[0370] Numerous problems exist with any interrogation technique
which has multiple interrogators. For radar systems to provide
seamless coverage, surface, parallel runway and airport
surveillance radars are required. Aircraft and surface vehicles
would require the use of a transponder which broadcasts a response
at 1090 MHZ when interrogated at 1030 MHZ. In an environment where
multiple interrogations are required, system complexities increase
dramatically. Early ATCRBS, Mode A and Mode C systems were troubled
with too many unsynchronized interrogation requests. This resulted
in cross talk, garble and loss of transmission bandwidth. Further
complicating the airport environment is the possibility of
reflected signals which interrogate areas of the airport outside
the view of the surveillance radar. This clogs the 1090 channel and
further complicates surveillance processing. Airborne Mode S
transponder operation requires that squitter messages be broadcast
when in the air and turned off on the ground. A Mode S squitter is
a periodic repetitive broadcast of ADS information. This, by
definition, will interfere with airport interrogation broadcasts
and essentially create a self jamming system.
[0371] Any airport ADS system utilizing a Mode S interrogation
capability would require almost a ground up development effort
encompassing the myriad of necessary surveillance systems.
[0372] Mode S Squitter (GPS Squitter)
[0373] Similarly, the Mode S squitter utilizes the Mode S
frequencies. A squitter is a randomly timed broadcast which is
rebroadcast periodically. The Mode S squitter broadcasts GPS
information at a periodic rate at 1090 MHZ with a bit rate of 1
MBPS. Current thinking requires that the ADS system be compatible
with the Traffic Collision Avoidance System (TCAS). The TCAS system
currently uses a 56 bit squitter message that must be turned off in
the low altitude airport environment since it will interfere with
other radar processing activities performed on the ground. Turning
TCAS off inside the terminal area (where most midair problems and
airport surface collisions occur) defeats the system's operational
benefits where they are needed most. Operationally this is
unacceptable.
[0374] A modified 112 bit squitter message has been proposed by MIT
Lincoln Laboratories. With this approach, the GPS data is
squittered twice per second to support ground and low altitude
operations. The proposed Mode S squitter operation has distinct
advantages over the Mode S interrogation method. Broadcasts are
generated from all aircraft and (potentially) surface vehicles.
Message collisions are possible, especially when the number of
users is increased. If a collision occurs, the current message is
lost and one must wait for the next message to be transmitted. At a
two hertz transmission rate, this is not a significant problem.
Analysis performed by MIT Lincoln Laboratories indicates that an
enhanced Mode S squitter has potential to support operations at
major airports.
[0375] The integration of the Mode S Squitter, as currently
defined, is not without risk. This implementation requires a fleet
update to convert to the 112 bit fixed format. Procedural issues of
the switch-over between the 56 and 112 bit operation remain
problematic. Operation in metroplex areas such as New York may
create operationally dangerous conditions. Airside TCAS and ASR 56
bit transponder responses would be turned off based on phase of
flight to be compatible with 112 bit squitter messages used at low
altitudes and on the ground. In metroplex areas, confusion is
almost certain for both the pilot and air traffic controller when
systems are turned off and on. Further modifications may be
required to ground and vehicular equipment should these issues be a
significant problem.
[0376] The 112 bit fixed squitter length message, as defined in May
1994, fails to take advantage of precise GNSS velocity information.
This is a significant limiting factor in the proposed squitter
message format. The current squitter message is designed to be
compatible with today's radar processing software and is not
designed to fully capitalize on GNSS and ADS capabilities.
[0377] Aviation Packet Radio (AVPAC)
[0378] AVPAC radio is currently in use with services provided by
ARINC and may be a viable candidate to provide ADS services. Again,
a GPS-based squitter or an interrogator-initiated broadcast is
utilized at aeronautical VHF frequencies. Work is underway to adapt
AVPAC to support both voice and data transmissions. A Carrier Sense
Multiple Access (CSMA) protocol is utilized on multiple VHF
frequencies
[0379] Aircraft Communications Addressing & Reporting
System
[0380] Another communication system currently in use by the
aviation industry is ACARS. ACARS is a character oriented protocol
and currently transmits at 2400 baud. Work is underway to increase
the baud rate to support more complex message formats.
[0381] VHF/UHF Time Division Multiple Access (TDMA)
[0382] An interesting communication scheme currently under test and
development in Sweden utilizes TDMA operation. TDMA is similar to
communication technologies used by the United States military and
others. In this system, each user is assigned a slot time in which
to broadcast the ADS message. A single or multiple frequency system
may be utilized based upon total traffic in the area. Upon entering
an airport area, the user equipment listens to all slot traffic.
The user equipment then selects an unused broadcast time slot.
Precise GPS time is used to determine the precise slot. ADS
broadcasts are then transmitted at a periodic rate. Broadcasts
typically repeat at one second intervals. Should a collision be
detected upon entering a new location, the system then transmits on
another clear time slot. Since all time slots are continuously
received and monitored, all necessary information for situational
awareness and collision avoidance is available.
[0383] This system maximizes the efficiency of the broadcast link
since, in a steady state environment, no transmission collisions
can occur. A time guard band is required to assure that starting
and ending transmissions do not overlap. The size of the guard band
is a function of GPS time accuracy and propagation delay effects
between various users of the system. Another feature of this system
is an auto-ranging function to the received broadcasts. This is
possible due to the fact that the ADS slot transmissions are
defined to occur at precise time intervals. It is then possible,
using a GNSS synchronized precise time source, to determine the
transit time of the ADS broadcast. By multiplying the speed of
light by the transit time, one may calculate the 1-dimensional
range to the transmitting object. In reality, a more precise
direction, distance and predicted future location is obtainable
from the ADS message information itself.
[0384] Code Division Multiple Access (CDMA) Spread Spectrum
[0385] CDMA spread spectrum ADS broadcasts utilize a transmission
format similar to that used in the GPS satellites. PRN codes are
utilized to uniquely identify the sending message from other
messages. The number of users able to simultaneously utilize an
existing channel depends upon the PRN codes used and the resulting
cross correlation function between the codes. This implementation
is being utilized commercially in wireless computer systems with
data rates exceeding 256 KBPS. In a frequency agile environment,
this implementation may be able to provide secure ADS services.
[0386] Cellular Telephone
[0387] Cellular technology is rapidly changing to support the large
potential markets of mobile offices and personal communication
systems. CCITT and ISDN standards will provide both voice, video
and data capability. Cellular communication may be used by surface
vehicles and aircraft for full duplex data link operations. ADS
broadcast message formats receivable by ATC and other users will
require changes to commercially available services. Cellular
telephone has the mass market advantage of cost effective large
scale integration and millions of users to amortize development
costs over. This particular technology holds promise, and bears
watching.
[0388] As the above examples show, a number of datalinks exist or
may be modified to provide ADS services. It is not the intent of
this specification to rigidly define a particular datalink.
[0389] ADS Operational Considerations
[0390] To fully exploit the ADS concepts presented in this
specification, a new set of operational procedures and processing
techniques are necessary. The ADS concept will provide the
controller and the Aircraft/Vehicle (A/V) operator with the best
possible view of the airport environment. With highly accurate 3-D
position and velocity information, many new operational
capabilities are possible which will provide increased efficiency
and safety improvements. The following sections show how precise
ADS information is used in seamless airport control and
management.
Definition Of Compatible Waypoints
[0391] Waypoints based upon the precise 3-D map and standard
surface, approach and departure paths are used for surface and air
navigation in the 3-D airport space envelope. Waypoints may be
stored in a variety of coordinate systems, such as conventional
Latitude, Longitude, Mean Sea Level; State Plane Coordinates; ECEF
X, Y, Z; and others. The navigational waypoint and on/off course
determinations are preferred to be performed in an ECEF X, Y, Z
coordinate frame, but this is not mandatory.
[0392] Waypoints and navigation processing should be defined and
designed for compatibility with air and ground operations,
including precision approach capability. The same information and
processing techniques should be in place on board the A/V's and at
the AC&M. The AC&M performs mirrored navigational
processing using the same coordinate references and waypoints as
those on board the A/Vs. In this manner, the AC&M system can
quickly detect off course and `wrong way` conditions anywhere in
the 3-D airport space envelope at the same time these conditions
are detected on board the A/V's.
Waypoint Navigation Mathematics
[0393] The following mathematical example is provided to show how
waypoints and trajectories are processed in the ECEF X, Y, Z
coordinate reference frame. An actual DGPS flight trajectory is
used for this mathematical analysis. The flight trajectory and
waypoints have been previously converted to an ECEF X, Y, Z
format.
[0394] FIG. 11 presented in the earilier ON Or Off Course
Processing section depicts the major ECEF waypoint elements which
are used throughout the following navigation mathematical
processing example. The following example utilizes an ECEF Waypoint
Matrix. In this example, the next waypoint (NWP) is element 5 in
the matrix and the previous waypoint (PWP) is element 4. The values
for the waypoints are shown in the examples. The range to the
waypoint is determined from the current position. The range is
compared to the previous range for possible off course or wrong way
conditions. If the range is increasing, the waypoint auto-indexing
distance may have been exceeded even though the vehicle is on
course. In this situation, the waypoint index is temporarily
indexed and checking is performed to determine whether the velocity
vector is pointing within X degrees of the next waypoint (in this
example it is set to +/-90 degrees). Based upon the outcome, a
wrong way signal is generated or the waypoints are indexed. The
ECEF cross track vector (XTRK) is determined and projected on to
the vertical axis, local lateral axis and the plane tangent with
the earth's surface at the current position.
16 CONSTRUCT TRAJECTORY VECTOR OF PRESENT POSITION (PP) INDEX TO
NEXT WAYPOINT 26 PP < t > := [ x t y t z t ] i := 1 PRESENT
POSITION WAYPOINT INDEX 27 PP < t > = ( 1490699.03159201 -
4432742.69262449 4322846.19931227 ) 28 wpin 1 := floor ( t n ) 29
WP = ECEF X ECEF Y ECEF Z [ 1491356.37337769 - 4435534.38012856
4319696.32899831 1491105.50608276 - 4434843.77739539
4320510.10012327 1491191.23102175 - 4434078.22140822
4321279.19552478 1491403.12310625 - 4433316.76294102
4322016.0156733 1491013.94073778 - 4432855.36845753
4322641.89680813 1490386.07395151 - 4432652.82158381
4323015.56283451 1489735.70705071 - 4432541.02638631
4323262.8405113 1489205.89638419 - 4432860.45040046
4322985.40668013 1488862.17692919 - 4433298.26186174
4322564.11714943 1488577.40869804 - 4433715.22689756
4322248.17133335 1488250.73266894 - 4434298.26191826
4321864.00370927 ] WAYPOINT MATRIX Q WAYPOINT INDICES PREVIOUS NEXT
30 pwp := wpin 1 31 n wp := wpin 1 + 1 pwp = 4 nwp = 5 PREVIOUS
WAYPOINT PWP := (WP.sub.pwp,0 WP.sub.pwp,1 WP.sub.pwp,2) 32 PWP T =
( 1491013.94073778 - 4432855.36845753 4322641.89680813 ) NEXT
WAYPOINT NWP := (WP.sub.nwp,0 WP.sub.nwp,1 WP.sub.nwp,2) 33 NWP T =
( 1490386.07395151 - 4432652.82158381 4323015.56283451 ) DEFINE
VECTOR BETWEEN WAYPOINTS FOR CURRENT TRAJECTORY TIME BWP :=
NWP.sup.T - PWP.sup.T 34 BWP = ( - 627.8667862699 202.5468737194
373.6660263799 ) DISTANCE BETWEEN THE WAYPOINTS
.vertline.BWP.vertline. =758.2006572307 DEFINE VECTOR BETWEEN
PRESENT POSITION & NEXT WAYPOINT TNWP := NWP.sup.T -
PP.sup.<t> 35 TNWP = ( - 312.9576405 89.8710406795
169.36352224 ) DISTANCE TO THE WAYPOINT (RANGE)
.vertline.TNWP.vertline. = 367.019470009 CHECK RANGE TO SEE IF A
WAYPOINT HAS BEEN MISSED IF VEH. N RANGE > PREVIOUS VEH. N RANGE
THEN PERFORM TEST: INCREMENT WAYPOINT INDEX FIND THE VECTOR LINE
BETWEEN THE CURRENT POSITION AND NEXT WAYPONT TNWP = NWP(X,Y,Z) -
PP(X,Y,Z) CALCULATE ECEF CURRENT POSITIONS VELOCITY VECTOR VEL =
(VX,VY,VZ) CALCULATE DOT PRODUCT BETWEEN THE VELOCITY VECTOR AND
TNWP COS .theta. = TNWP(X,Y,Z) dot VEL(VX,VY,VZ)
.vertline.TNWP.vertline. = SRT[(X * X) + (Y * Y) + (Z * Z)]
.vertline.VEL.vertline. = SRT[(VX*VX)+(VY*VY)+VZ*VZ)] COS .theta. =
[(X*VX)+(Y*VY)+(Z*VZ)]/(.vertline.TNWP.vertline.*.vertline.VEL.vertline-
.) IF 0 < COS .theta. < 1 THEN KEEP CURRENT WAYPT INDEX,
MISSED AUTO WAYPOINT INDEX DISTANCE IF -1 < COS .theta. <=0
THEN GO BACK TO PREVIOUS WAYPOINT FLASH WRONG WAY PRESENT POSITION
NEXT WAYPONT 36 PP < t > = ( 1490699.03159201 -
4432742.69262449 4322846.19931227 ) 37 NWP T = ( 1490386.07395151 -
4432652.82158381 4323015.56283451 ) UNIT VECTOR PERPENDICULAR TO
PLANE CONTAINING INTER- SECTING LINES TNWP & LINE UNIT NORMAL
FROM DESIRED TRACK BETWEEN WAYPOINTS TO THE PRESENT POSITION POINT
38 NP := BWP .times. TNWP BWP .times. TNWP 39 UN := NP .times. BWP
NP .times. BWP 40 NP = ( 0.0568495318 - 0.8345970318 0.547919634 )
41 UN = ( - 0.557688735 - 0.4817501474 - 0.6759438367 ) CROSS TRACK
ERROR CALCULATIONS CROSS TRACK MAGNITUDE DETERMINATION XTRK := UN
.multidot. TNWP XTRK = 16.7573345255 CROSS TRACK VECTOR
DETERMINATION VXTRK := UN .multidot. XTRK VXTRK -8.0728483774
DETERMINE THE ADJUSTED POSITION The adjusted position is the point,
on the line between the previous and next waypoint which is normal
to the present position. ADJ.sup.<t> := PP.sup.<t> +
VXTRK 42 ADJ < t > = ( 0.234070768 - 0.696038475 0.6787792844
) DETERMINE THE UNIT VECTOR IN THE DIRECTION FROM CENTER OF MASS OF
THE EARTH TO ADJUSTED POSITION This vector is in the local vertical
direction and for all practical purposes in the vertical direction
at the actual user position, since the separations are very small
compared to the length of the vector. 43 UVADJ := ADJ < t >
ADJ < t > 44 UVADJ = ( 0.234070768 - 0.696038475 0.6787792844
) FIND THE PROJECTION OF THE XTRACK VECTOR ON TO THE UNIT VECTOR
This distance represents the vertical distance to true course
VERTDIST := VXTRK .multidot. UVADJ VERTDIST -4.2570109135 FIND THE
LATERAL AXIS OF XTRK INFORMATION The lateral axis represents
horizontal distance to true course from the current position. A
number of steps are necessary in this determination and are
outlined below. FIRST FIND THE VECTOR PERPENDICULAR TO THE PLANE
FORMED BY THE XTRK AND THE UVADJ VECTOR 45 UVPER := VXTRK .times.
ADJ < t > VXTRK .times. ADJ < t > 46 UVPER = ( -
0.8245345664 0.2278021297 0.5179275418 ) FIND THE VECTOR (VLAT)
WHICH LIES IN THE PLANE FORMED BY UVADJ AND VXTRK WHICH IS
PERPENDICULAR TO THE UVADJ VECTOR IT IS KNOWN THAT VLAT DOT UVADJ =
0 AND UVPER DOT VLAT = 0 SOLVE FOR VLAT BY USING SIMULTANEOUS
EQUATIONS EQUATION #1 47 UVADJ VLAT 0 + 0 UVADJ V 1 LAT + 1 UVADJ 2
VLA T 1 = 0 EQUATION #2 48 UVPER VLAT 0 + 0 UVPER V 1 LAT + 1 UVPER
2 VLA T 1 = 0 49 SUBSTITUTE AND SOLVE IN TERMS OF VLA T 2 50 UVADJ
0 UVPER 0 = - 0.2838822986 51 UVADJ 1 UVPER 1 = - 3.0554520095
DEFINE VARIABLES FOR EQUATION SUBSTITUTION 52 VLATX := ( - UVADJ 1
UVPER 1 ) UVPER 2 + UVADJ 2 ( UVADJ 1 UVPER 1 ) UVPER 0 + UVADJ 0
53 VLATY := ( - UVADJ 0 UVPER 0 ) UVPER 2 + UVADJ 2 ( UVADJ 0 UVPER
0 ) UVPER 1 + UVADJ 1 DEFINE VLAT VECTOR NOTE: VLAT(Z) TERM WILL
CANCEL OUT WHEN FINDING UNIT VECTOR VLAT := (VLATX VLATY 1) VLAT =
(0.989509706 1.3079658867 1) DETERMINE THE LOCAL LATERAL AXIS UNIT
VECTOR 54 UVLAT := VLAT VLATX 2 + VLATY 2 + 1 2 55 UVLAT T = (
0.5151248629 0.6809086804 0.5205859627 ) PERFORM CHECK TO SEE IF
UVLAT IS PERPENDICULAR TO UVADJ UVADJ .multidot. UVLAT.sup.T =
5.5511151231 .multidot. 10.sup.-17 CLOSE ENOUGH TO ZERO IS
PERPENDICULAR PERFORM CHECK TO SEE IF UVLAT IS PERPENDICULAR TO
UVPER UVPER .multidot. UVLAT.sup.T = 0 IT IS PERPENDICULAR PROJECT
THE CROSS TRACK TO THE LATERAL AXIS LATDIST := VXTRK .multidot.
UVLAT.sup.T LATDIST = -16.2075944693 VERTDIST = -4.2570109135 The
sign of the lateral distance (LATDIST) and vertical distance
(VERTDIST) determine whether one turns right or left or goes up or
down to true course
[0395] From a simplicity standpoint, the ECEF coordinate frame
provides direct GPS compatibility with minimal processing overhead.
The system is based upon the ECEF world wide coordinate frame and
provides for 4-D gate-to-gate navigation without local coordinate
reference complications. Furthermore, it is directly compatible
with zone processing functions as described in earlier
sections.
[0396] The above techniques can also be expanded to include curved
approaches using cubic splines to smooth the transitions between
waypoints. A curved trajectory requires changes to the above set of
equations. Using cubic splines, one can calculate three cubic
equations which describe smooth (continuous first and second
derivatives) curves through the 3-D ECEF waypoints. Additional
information on the use of splines may be found in mathematical and
numerical programming text books. Four dimensional capability is
possible when the set of cubic equations is converted into a set of
parametric equations in time.
Display Graphics and Coordinated References
[0397] Three dimensional display graphics, merged with GPS sensor
inputs, provide exciting new tools for airport navigation, control
and management. Today's airport users operate in a 4-dimensional
environment as precisely scheduled operations become increasingly
important in an expansion-constrained aviation system. The 4-D
capability of GPS integrated with precise 3-D airport maps and
computer graphics, provide seamless airport safety and capacity
enhancements. The merger of these technologies provides precise,
real-time, 3-D situational awareness capability to both the A/V
operators and the air traffic controller.
[0398] The FIG. 17 shows a missed approach 81 on runway 35 followed
by a touch and go 82 on runway 24 at the Manchester Airport. The
power of such a situation display 83 presentation for the air
traffic controller can be instantly recognized. Upon closer
inspection, it becomes increasingly clear that GPS and precise
graphical maps can be a valuable asset in air and ground
navigation.
[0399] For the air traffic controller, 3-D situational awareness
displays, supplemented with navigation status information, are
sufficient. For the pilot navigating in a 3-D world, a 3-D terrain
or airport map superimposed with graphical navigational information
would be extremely valuable, particularly in adverse weather
conditions.
[0400] The FIG. 18 combines the elements of precise ECEF
navigational information with a 3-D airport map. The key element in
the construction of the map is compatibility with the navigation
display, where the selection of map and navigation coordinate
frames is of paramount importance. Upon inspection of computer
graphical rotation and translational matrices, it becomes clear
that, for processing speed and mathematical efficiency, the
Cartesian coordinate system is preferred for the map database. A
3-D X,Y,Z digital map presentation provides the most efficient path
to 2-D screen coordinates through the use of projection
transformations.
[0401] The integration of GPS-based navigation information with
digital maps suggests that new methods of navigation processing
should be considered. In the past, aircraft typically relied on a
signal in space for instrument-based navigation. The instrument
landing system (ILS) consists of a localized directed signal of
azimuth and elevation. The VOR-DME navigation system uses a signal
in space which radiates from an antenna located at a particular
latitude and longitude. Altitude is determined from pressure
altitude. Current, 2-D radar surveillance systems are also based
upon a localized coordinate reference, usually to the center of the
radar antenna. Again, altitude information is from barometric
pressure readings which vary with weather. The integration of
localized navigation and surveillance systems and 3-D ATC and
navigational display presentations require an excessive number of
coordinate conversions, making the process overly difficult and
inaccurate.
[0402] To minimize navigational and display overhead, a Cartesian
X,Y,Z coordinate system is used for the navigation computations,
map database and display presentations. Many X,Y,Z map database
formats are in use today, but many are generated as a 2-D
projection with altitude measured above mean sea level. Two
examples of this type of system are Universal Transverse Mercator
(UTM) and State Plane Coordinate System (SPCS). Neither one of
these systems is continuous around the world, each suffer from
discontinuities and scale deformity. Furthermore, neither of these
systems is directly compatible with GPS and also requires
coordinate conversions. If the map, travel path waypoints,
navigational processing, navigational screen graphics and airport
control and management functions are in the Cartesian coordinate
frame, the overall processing is greatly simplified.
[0403] In the graphical navigation display FIG. 18, the perspective
is that of a pilot from behind his current GPS position 84. From
this vantage point 85, the pilot can view his current position 84
and his planned travel path 86. As the aircraft moves, its precise
ECEF X,Y,Z velocity 87 components are used to determine how far
back 88 and in what direction the observation is conducted from.
This is determined by taking the current ECEF velocity 87, negating
it and multiplying it by a programmable time value (step-back
time). When applied to the aircraft's current position 84, this
results in an observation point 89 which is always looking at the
current position 84 and ahead in the direction of travel 87.
[0404] Once the observation point 89 is established in the 3-D
Cartesian coordinate system, an imaginary mathematical focal plane
90 is established containing the current position 84. The focal
plane 90 is orthogonal to the GPS-derived ECEF velocity vector 87.
The mathematical focal plane 90 represents the imaginary surface
where the navigation `insert` 91 will be presented. The focal plane
is always, by definition, orthogonal to the viewing point 85. The
travel path 86 composed of ECEF X,Y,Z waypoints (92-95) is drawn
into the 3-dimensional map. The point on the true travel path 86
which is perpendicular to the current position 84 represents the
center 96 of the navigational insert screen 91. The orientation of
the navigational insert with respect to the horizontal axis is
determined by the roll of the aircraft. The roll may be determined
through the use of multiple GPS antennas located at known points on
the aircraft or may be determined by inertial sensors and then
converted to the ECEF coordinate frame. Vector mathematics
performed in the ECEF coordinate frame are then used to determine
the new rotated coordinates of the navigation screen insert 91. The
rotated coordinates are then translated through the use of the
graphical translation matrix and drawn into the 3-D map 97.
[0405] The final step is the placement of the current position
`cross-hair` symbol 84 with respect to travel path 86. The
aircraft's GPS position, previous and next waypoints are used to
determine the ECEF cross track vector 98. The cross track vector 98
is then broken down into its local vertical 99 and local lateral
100 (horizontal) components. (Local components must be used here
since the vertical and lateral vectors change as a function of
location on the earth.) The cross-hair symbol 101 is then drawn on
to the focal (image) plane 90 surface at the proper offset from the
true course position indicated by the center of the navigation
screen insert 96. Thus, this display provides precise navigation
information (lateral and vertical distance to true course) with
respect to true course, provides information on 3-D airport
features and shows the planned 3-D travel path. The element of time
may also be presented in this display format as an arrow (drawn in
the direction of travel) of variable length where the length
indicates speed up or slow down information.
[0406] The construction of this type of display in other than ECEF
coordinates entails substantial coordinate conversion and
additional processing. Again, for simplicity and compatibility with
proven 3-dimensional graphic techniques, an ECEF Cartesian X,Y,Z
coordinate framework is desired.
GPS Navigator Display
[0407] Various display formats are used to provide the GPS
navigational information to the pilot. The area navigation display
shown in FIG. 19 features auto-scaling range 102 rings 103 which
provide course, 104 bearing 105 and range distance to the waypoint.
The length of the course 104 and bearing lines 105 superimposed on
the ring scale 103 are proportional to the distance from the
waypoint. The compass orientation of the bearing line 105 provide
the course to travel from the current position to the waypoint. The
course line 104 indicates the compass direction of current travel.
The display also provides altitude information as a auto-scaling
bar chart display 106 with indicated go up or down information.
[0408] In this manner the area navigation display provides the
following:
[0409] 1. Range to the waypoint based on length of the line and an
autoranging scale
[0410] 2. Compass heading to travel to the waypoint
[0411] 3. Compass heading of current travel
[0412] 4. Autoranging altitude navigation bar graph display
[0413] The GPS landing display is shown in FIG. 20. This display is
activated when the first GPS waypoint at the top of the glide slope
is reached. The precision landing display is composed of a simple
heavy cross 107 which moved about on an X Y graticuled cross hair
display 108. Textual TURN LEFT/TURN RIGHT and GO UP/GO DOWN
messages are presented to the pilot when the aircraft is more than
a predetermined amount eg. 10.0 meters off of true course.
[0414] Another display format utilizing a 3-D map is provided in
FIG. 21. This display technique provides a 3-D view of the
approaching airport as viewed from the aircraft's position. The
techniques described above for the cross hair navigation screen are
identical to those used in the 3-D approach presentation. In the
3-D approach presentation, a conical zone 109 is constructed around
the line 110 between the landing approach waypoints. The apex of
the cone is at the touch down point 111 and the base of the cone is
at the top of the glide slope waypoint. This 3-D object is viewed
normal to the line between the current and previous waypoint as
shown in FIG. 21.
[0415] The cone is sliced at the point on the line (formed by the
current and previous waypoint) perpendicular to the present
position 112. The resulting cross section then effectively
represents the cross hair symbology implemented in the graphical
GPS landing display. The current position is then displayed within
the conical cross section 113 of the glide slope zone 109. A
position not in the center of the display means the aircraft is not
on true course. For example, a position report in the upper right
of the display cross section means the aircraft is too high and too
far to the right. In this case the pilot should turn left and go
down. As the aircraft gets closer to the touch down point, the
conical cross section scale gets smaller. Once the touchdown
waypoint 114 is reached, the display reverts to a plan view of the
airport similar to that shown in FIG. 8 which is then used for
surface navigation. The graphical nature of this display format is
useful in the air and on the ground, but requires very fast
graphical and computational performance. The advantage of this
system is that it minimizes many of the navigational calculations
such as cross track errors, but requires moderate spatial graphical
computations and fast display performance.
Waypoint Database Definition Software Example
[0416] Waypoints
[0417]
/******************************************************************
[0418] File Name: way.c
[0419] Description: way.c contains the routines used to enter and
save the waypoint data.
[0420] Units: store_wps, calc_navdata,
[0421] #include <stdio.h> /* standard input/output */
[0422] #include <math.h> /* MSC math library */
[0423] #include <string.h> /* MSC string routines
[0424] #include <graph.h> /* MSC graphics routines */
[0425] #include <stdlib.h> /* MSC standard library routines
*/
[0426] #include <bios.h> /* MSC bios routines */
[0427] #include "coord.h" /* coordinate definitions */
[0428] #include "sio.h" /* CAD/NAV global declarations
[0429] #include "veh.h" /* vehicle data */
[0430] #include "lights.h" /* lighting definitions */
AC&M Subsystems
[0431] Communications Processor and Communication Flow
[0432] The processing of data communications within the airport is
a key element of any GPS-based airport control and management
system. A minimum of three types of messages must be addressed:
[0433] (1) the broadcast of Differential GPS correction messages to
the vehicles
[0434] (2) the transmission and receipt of Automatic Dependent
Surveillance (ADS) messages
[0435] (3) the transmission of control messages from the AC&M
to the vehicle and vice versa.
[0436] A high level block diagram of the Airport Communications
System and its interfaces to other major elements of the AC&M
subsystem is provided in FIG. 22.
[0437] In this design, all ADS and A/V messages are received by the
AC&M Processor 115 and are forwarded to the COMM Processor 116
for re-transmission to the vehicles. The AC&M Processor is also
used to compose ATC messages which are also forwarded to the
vehicles through the COMM interface or passed to the local Graphics
Processor 117 to control the situation display presentation. The
COMM processor 116 also transmits the differential correction
messages generated by the reference station 118 directly to the
vehicles.
[0438] Differential GPS Overview
[0439] Real time differential correction techniques compensate for
a number of error sources inherent to GPS.
[0440] The idea is simple in concept and basically incorporates two
or more GPS receivers, one acting as a stationary base station 118
and the other(s) acting as roving receiver(s) 119, 120. The
differential base station is "anchored" at a known point on the
earth's surface. The base station receives the satellite signals,
determines the errors in the signals and then calculates
corrections to remove the errors. The corrections are then
broadcast to the roving receivers.
[0441] Real time differential processing provides accuracy of 10.0
meters or better (typically 1.0-5.0 meters for local differential
corrections). The corrections broadcast by the base station are
accurate over an area of about 1500 km or more. Typical positional
degradation is approximately a few millimeters of position error
per kilometer of base station and roving receiver separation.
[0442] Through the implementation of local differential GPS
techniques, SA errors are reduced significantly while the
atmospheric errors are almost completely removed. Ephemeris and
clock errors are virtually removed as well.
[0443] Antenna Placement
[0444] A site survey of potential differential base station sites
should be performed to determine a suitable location for the GPS
antenna. The location should have a clear view of the sky and
should not be located near potentially reflective surfaces (within
about 300 meters). The antenna site should be away from potentially
interfering radiation sources such as radio, television, radar and
communications transmitters. After a suitable site is determined, a
GPS survey should be conducted to determine the precise location of
the GPS antenna--preferably to centimeter level accuracy. This
should be performed using survey grade GPS equipment.
[0445] Survey grade GPS equipment makes use of the 19 and 21
centimeter wavelength of the L1 and L2 GPS transmissions. Real time
kinematic or post processing GPS surveys may be conducted. Real
time kinematic utilizes a base station located at a precise
location which broadcasts carrier phase correction and processing
data to a radio receiver and processing computer. Code, carrier
integral cycles and carrier phase information are used at the
survey site to calculate the WGS 84 antenna position. In the post
processing survey mode, subframe information, time, code, carrier,
and carrier phase data are collected for a period of time. This
data is later post processed using precise ephemerides which are
available from a network of international GPS sites. The collected
information is then post processed with post-fit precise orbital
information.
[0446] Base Station Operational Elements
[0447] The precisely surveyed location of the GPS antenna is
programmed into the reference station as part of its initial
installation and set up procedures. Industry standard reference
stations determine pseudo range and delta range based on carrier
smoothed measurements for all satellites in view. Since the exact
ECEF position of the antenna is known, corrections may be generated
for the pseudo range and delta range measurements and precise time
can be calculated.
[0448] Naturally occurring errors are, for the most part, slow
changing and monotonic over the typical periods of concern. When SA
is not invoked, delta range corrections provide a valid method of
improving positional accuracy at the roving receivers using less
frequent correction broadcasts. With the advent of SA and its
random, quick changing non-monotonic characteristics, delta range
corrections become somewhat meaningless and may actually degrade
the system performance under some conditions.
[0449] As shown previously in FIG. 22 the DGPS correction messages
are broadcast by the reference station and received by the roving
receivers. The corrections are applied directly to the differential
GPS receiver. The DGPS receiver calculates the pseudo range and the
delta range measurements for each satellite in the usual manner.
Prior to performing the navigation solution, the received pseudo
range and delta range corrections are applied to the internal
measurements. The receiver then calculates corrected position,
velocity and time data.
[0450] Since differential GPS eliminates most GPS errors, it
provides significant improvements in system reliability for life
critical airport operations. Short term and long term drift of the
satellite orbits, clocks and naturally occurring phenomenon are
compensated for by differential GPS as are other potential GPS
satellite failures. Differential GPS is mandatory in the airport
environment from a reliability, accuracy and fault compensating
perspective.
[0451] As with autonomous GPS receiver operation, multipath is a
potential problem. The differential reference station cannot
correct for multipath errors at the roving receiver(s). Antenna
design and placement considerations, and receiver design
characteristics remain the best solutions to date in the
minimization of multipath effects.
[0452] ADS Messages
[0453] ADS messages are generated on board each vehicle and
broadcast to the AC&M System. The message format is shown
below:
[0454] MSG Header, Vehicle ID, Vehicle Type, ECEF X, ECEF Y, ECEF
Z, ECEF X VEL, ECEF Y VEL, ECEF Z VEL <CR><LF>
[0455] On board each vehicle, the GPS-based position and velocity
data is converted to Earth Centered Earth Fixed (ECEF) coordinates
for use in the navigation and zone processing algorithms if
necessary. For simplicity, this format is used in the ADS
transmission as well. Upon receipt of an ADS message, the AC&M
Processor 115 forwards the message to the COMM Processor 116 then
stores the data in the vehicle database. The stored ECEF position
and velocity data is used to perform collision prediction, zone
incursion, lighting control and navigation processing at the
AC&M station.
[0456] ATC Messages
[0457] Air Traffic Control (ATC) messages are composed using the
AC&M station. The ATC messages are used locally to control the
AC&M graphics display 117 or present current status information
to the user. ATC message are also broadcast to the vehicles 119 and
120 through the COMM Processor 116. All ATC messages utilize an
explicit acknowledgment message. If an acknowledgment is not
received within a defined time interval, the message is
automatically retransmitted. The standard format is shown
below.
[0458] $ATC, MESSAGE TYPE, VEHICLE ID, MESSAGE DATA
<CR><LF>
[0459] Error Detection and Correction
[0460] In the demonstration prototype system, Cyclical Redundancy
Checking (CRC) is performed on all messages, with the exception of
the [RTCM-104] differential correction messages generated in the
Base Station 118. In this scheme, ADS messages are discarded if an
error is detected in the received message. This has not been a
significant problem for the prototype system since the next message
is received in one (1.0) second. The ATC messages directed to
specific vehicles also support CRC error detection. ATC messages
are "addressed" to a specific A/V and expect an explicit
acknowledgment. Upon receipt of an ATC message, the A/V sends back
a valid "message received" acknowledgment. The ATC message is
discarded by the A/V if an error is detected. In this case, no
message received acknowledgment is generated. If no "message
received" acknowledgment is received by the AC&M 115 within a
preset time interval, the original message is immediately
retransmitted. ATC messages require a corresponding acknowledgment
since they may represent critical controller instructions and
airport and safety operations could be compromised if the message
fails to reach its destination.
[0461] The CRC system operated effectively in the demonstration
prototype system, but a more robust communication error detection
and correction capability may be required for end state deployment.
Forward error correction and Viterbi--Trellis techniques provide a
cost effective forward error correction capability. These
techniques are widely used in commercial modem technology and are
available in Application Specific Integrated Circuits (ASIC). Wide
spread use of the technology makes it very cost effective for use
in future airport communication systems.
AC&M Processor and AC&M Processing Flow
[0462] A block diagram of the AC&M Processor is provided in
FIG. 23.
[0463] The AC&M Processor 121 is based on a 33 MHz 386
processor with a 387 math co-processor. This processor performs the
following functions:
[0464] Interfaces to communication digital datalinks
[0465] Receives ADS vehicle broadcasts
[0466] Receives acknowledgment messages from vehicles
[0467] Generates and transmits messages to vehicles
[0468] Performs collision prediction processing for each
vehicle
[0469] Monitors zone and runway incursion conditions
[0470] Controls runway intersections and runway clearance
lights
[0471] Maintains and controls vehicle, waypoint and zone
databases
[0472] Performs navigational processing for on-off course
checking
[0473] Performs map layer control and assignment
[0474] Sends vehicle reports and commands to Graphic Processor for
situation display
[0475] Provides a touch screen and keyboard command interface
[0476] Representative command functions are described in the
following section.
[0477] Touch Screen
[0478] The AC&M touch screen provides an efficient means of
command input for interfacing to the airport management system. The
touch screen is used to perform the following high level
functions:
[0479] Command interface to the Graphics Processor
[0480] Command interface to the AC&M Processor
[0481] Communication interface to properly equipped vehicles and
aircraft
[0482] Display of various AC&M data lists
[0483] Display of vehicle status information
[0484] The touch screen is organized into four discrete display
areas--the Command List, the Message Composition and Response
(MC&R) Window, the Alerts Window, and the Vehicle List. The
following figure shows the touch screen layout used during the
final demonstration. FIG. 34 depicts the touch screen with
representative information.
[0485] The Command List, as shown on the right in the figure below,
is used to provide key high level command functions. When a command
is invoked, it is emphasized in the Command List and remains
emphasized until the command is canceled or completed.
[0486] After command selection, the valid command options are
displayed in the large MC&R window to the left. The MC&R
window has two major functions--it is used to compose ATC messages
and it is used to display information to the operator. During
message composition, the MC&R window is used to prompt the
operator and provide a series of options relating to the content
and destination of the message. The MC&R window also serves as
the display presentation medium for list displays such as the
Vehicle Data display.
[0487] Critical watch and warning messages are presented to the
operator in the Alerts window of the touch screen. The Alerts
window displays messages generated as a result of a potential
collision condition, zone incursion or off course
determination.
[0488] The Vehicle List provides the operator with a list of the
active vehicles. Vehicles may be selected from the list during the
message composition activities.
[0489] Numerous commands have been implemented to demonstrate the
capability of the touch screen data entry device. Representative
command functions are described in the following section.
[0490] AC&M Command List Touch Screen
[0491] The AC&M touch screen provides an efficient means of
command input for interfacing to the airport management system. The
touch screen is used to perform the following high level
functions:
[0492] Command interface to the Graphics Processor
[0493] Command interface to the AC&M Processor
[0494] Communication interface to properly equipped vehicles and
aircraft
[0495] Display of various AC&M data lists
[0496] Display of vehicle status information
[0497] The touch screen is organized into four discrete display
areas--the Command List, the Message Composition and Response
(MC&R) Window, the Alerts Window, and the Vehicle List. The
following figure shows the touch screen layout used during the
final demonstration. FIG. 34 depicts the touch screen with
representative information.
[0498] The Command List, as shown on the right in the figure below,
is used to provide key high level command functions. When a command
is invoked, it is emphasized in the Command List and remains
emphasized until the command is canceled or completed.
[0499] After command selection, the valid command options are
displayed in the large MC&R window to the left. The MC&R
window has two major functions--it is used to compose ATC messages
and it is used to display information to the operator. During
message composition, the MC&R window is used to prompt the
operator and provide a series of options relating to the content
and destination of the message. The MC&R window also serves as
the display presentation medium for list displays such as the
Vehicle Data display.
[0500] Critical watch and warning messages are presented to the
operator in the Alerts window of the touch screen. The Alerts
window displays messages generated as a result of a potential
collision condition, zone incursion or off course
determination.
[0501] The Vehicle List provides the operator with a list of the
active vehicles. Vehicles may be selected from the list during the
message composition activities.
[0502] Numerous commands have been implemented to demonstrate the
capability of the touch screen data entry device. Representative
command functions are described in the following section.
[0503] AC&M Command List
[0504] ARRIVAL WAYPOINTS
[0505] The ARRIVAL WAYPOINTS command is issued to grant a landing
clearance to an approaching aircraft and provide it with a set of
waypoints for the landing operation. The command is invoked by
touching the ARRIVAL WAYPOINT soft function key on the AC&M
touch screen.
[0506] Upon invocation, the following steps are followed:
[0507] 1. The ARRIVAL WAYPOINTS soft function key is
highlighted.
[0508] 2. The list of valid vehicle ids is displayed in the VEHICLE
LIST window. The user is prompted to select one of the
vehicles.
[0509] 3. Upon selection of a valid vehicle, a description of each
predefined arrival waypoint path is displayed in the MESSAGE
COMPOSITION AND RESPONSE (MC&R) window. The user is prompted to
select one of the waypoint lists.
[0510] 4. Upon selection of the waypoint list, the corresponding
waypoints are drawn into the AC&M's digital map display. The
user is then prompted as to whether the waypoints are correct.
[0511] 5. If the user accepts the waypoints, an ATC message is
composed and transmitted to the vehicle.
[0512] The waypoints are automatically loaded into the AC&M's
mirrored navigator. The MC&R window is cleared and a message
completed indicator is displayed.
[0513] 6. If the user does not accept the waypoints, the waypoints
drawn into the map display are cleared, the MC&R window is
cleared and no waypoints are processed.
[0514] DEPARTURE WAYPOINTS
[0515] The DEPARTURE WAYPOINTS command is issued to grant a takeoff
clearance to a departing aircraft and provide it with a set of
waypoints for the operation. The command is invoked by touching the
DEPARTURE WAYPOINT soft function key on the AC&M touch
screen.
[0516] Upon invocation, the following steps are followed:
[0517] 1. The DEPARTURE WAYPOINTS soft function key is
highlighted.
[0518] 2. The list of valid vehicle ids is displayed in the VEHICLE
LIST window. The user is prompted to select one of the
vehicles.
[0519] 3. Upon selection of a valid vehicle, a description of each
predefined departure waypoint path is displayed in the MESSAGE
COMPOSITION AND RESPONSE (MC&R) window. The user is prompted to
select one of the waypoint lists.
[0520] 4. Upon selection of the waypoint list, the corresponding
waypoints are drawn into the AC&M's digital map display. The
user is then prompted as to whether the waypoints are correct.
[0521] 5. If the user accepts the waypoints, an ATC message is
composed and transmitted to the vehicle. The waypoints are
automatically loaded into the AC&M's mirrored navigator. The
MC&R window is cleared and a message completed indicator is
displayed.
[0522] 6. If the user does not accept the waypoints, the waypoints
drawn into the map display are cleared, the MC&R window is
cleared and no waypoints are processed.
[0523] SURFACE WAYPOINTS
[0524] The SURFACE WAYPOINTS command is issued to grant a ground
clearance to an aircraft or surface vehicle and provide it with a
set of waypoints for the operation. The command is invoked by
touching the SURFACE WAYPOINT soft function key on the AC&M
touch screen.
[0525] Upon invocation, the following steps are followed:
[0526] 1. The SURFACE WAYPOINTS soft function key is
highlighted.
[0527] 2. The list of valid vehicle ids is displayed in the VEHICLE
LIST window. The user is prompted to select one of the
vehicles.
[0528] 3. Upon selection of a valid vehicle, a description of each
predefined surface waypoint path is displayed in the MESSAGE
COMPOSITION AND RESPONSE (MC&R) window. The user is prompted to
select one of the waypoint lists.
[0529] 4. Upon selection of the waypoint list, the corresponding
waypoints are drawn into the AC&M's digital map display. The
user is then prompted as to whether the waypoints are correct.
[0530] 5. If the user accepts the waypoints, an ATC message is
composed and transmitted to the vehicle. The waypoints are
automatically loaded into the AC&M's mirrored navigator. The
MC&R window is cleared and a message completed indicator is
displayed.
[0531] 6. If the user does not accept the waypoints, the waypoints
drawn into the map display are cleared, the MC&R window is
cleared and no waypoints are processed.
[0532] CLEAR PATH WAYPOINTS
[0533] The CLEAR PATH WAYPOINTS command is issued to manually end a
previously granted clearance and clear any pending waypoints for a
specific vehicle. The command is invoked by touching the CLEAR PATH
WAYPOINTS soft function key on the AC&M touch screen.
[0534] Upon invocation, the following steps are followed:
[0535] 1. The CLEAR PATH WAYPOINTS soft function key is
highlighted.
[0536] 2. The list of valid vehicle ids is displayed in the VEHICLE
LIST window. The user is prompted to select one of the
vehicles.
[0537] 3. Upon selection of a valid vehicle, a clear waypoints
command is issued to the vehicle, clearing its remaining waypoints.
Similarly, the clearance status and waypoints at the AC&M
system are cleared as well.
[0538] AIRPORT LIGHTS
[0539] The AIRPORT LIGHTS command is issued to manually change the
status of a specific set of runway approach, departure or
intersection lights. The command is invoked by touching the AIRPORT
LIGHTS soft function key on the AC&M touch screen.
[0540] Upon invocation, the following steps are followed:
[0541] 1. The AIRPORT LIGHTS soft function key is highlighted.
[0542] 2. Each lighting system and its current status (ON or OFF)
is displayed in the MC&R window. The user is prompted to select
the desired light(s) from the window.
[0543] 3. Upon selection of a set of lights, the status is toggled
and the corresponding lights on the map lighting board are changed
accordingly.
[0544] VEHICLE FILTER
[0545] The VEHICLE FILTER command is issued to enable or suppress
the display of a particular type of vehicle by altering the status
of its graphic layer. The command is invoked by touching the
VEHICLE FILTER soft function key on the AC&M touch screen.
[0546] Upon invocation, the following steps are followed:
[0547] 1. The VEHICLE FILTER soft function key is highlighted.
[0548] 2. The current vehicle types are displayed in the MC&R
window with the current filter status (ON or OFF) as shown:
17 LIMITED ACCESS AREA GROUND VEHICLE ON EMERGENCY/SERVICE GROUND
VEHICLE ON ARRIVAL AIRCRAFT ON DEPARTURE AIRCRAFT ON ALL VEHICLES
ON
[0549] 3. The user has the capability to suppress and re-enable
various vehicle types by selecting it from the MC&R window.
[0550] 4. Upon selection, the user is prompted to accept the
command. If the command is selected, the vehicle type's status is
toggled and the vehicle is either suppressed from the map display
or re-displayed if previously suppressed.
[0551] Vehicle types which are suppressed are not displayed on the
AC&M graphics display unless they are in a collision or zone
incursion condition.
[0552] 5. If NO is selected, the vehicle type's status remains
unchanged.
[0553] LAYER FILTER
[0554] The LAYER FILTER command is issued to manually change the
status of a specific graphic layer. Layers which are masked are no
longer displayed. The command is invoked by touching the LAYER
FILTER soft function key on the AC&M touch screen.
[0555] Upon invocation, the following steps are followed:
[0556] 1. The LAYER FILTER soft function key is highlighted.
[0557] 1. The current LAYER types are displayed in the MC&R
window with the current filter status (ON or OFF) as shown
below:
18 LAYER TYPE STATUS RANGE RINGS ON RANGE RINGS, 5 MILE INCREMENTS
ON AIRPORT LIGHTING SYSTEMS (RNWY 35) OFF AIRPORT LIGHTING SYSTEMS
(RNWY 24) OFF TRACKED SURFACE VEHICLES (LIMITED ACCESS) ON TRACKED
SURFACE VEHICLES (FULL ACCESS) ON TRACKED DEPARTURE AIRCRAFT ON
TRACKED ARRIVAL AIRCRAFT ON ARRIVAL WAYPOINTS OFF DEPARTURE
WAYPOINTS OFF SURFACE WAYPOINTS OFF CUSTOM WAYPOINTS DEFINITION OFF
AIRPORT SURFACE ZONES OFF WEIGHT LIMITED ZONES OFF RESTRICTED
TRAVEL AREA OFF AIRSPACE HAZARD ZONES OFF OPEN CONSTRUCTION ZONES
OFF CLOSED CONSTRUCTIONS ZONES OFF
[0558] 3. The user has the capability to suppress and re-enable
various layers by selecting it from the MC&R window.
[0559] 4. Upon selection, the user is prompted to accept the
command. If the command is selected, the layer's status is toggled
and the layer is either suppressed from the map display or
re-displayed if previously suppressed.
[0560] Vehicle types which are suppressed are not displayed on the
AC&M graphics display unless they are in a collision or zone
incursion condition. Special category, watch or warning layers are
never suppressed.
[0561] 5. If NO is selected, the layer's status remains
unchanged.
[0562] VEHICLE DATA
[0563] The VEHICLE DATA command is issued to display status
information for a particular vehicle. The vehicle data is displayed
in the MC&R window. The command is invoked by touching the
VEHICLE DATA soft function key on the AC&M touch screen. Upon
invocation, the following steps are followed:
[0564] 1. The VEHICLE DATA soft function key is highlighted.
[0565] 2. The list of valid vehicle ids is displayed in the VEHICLE
LIST window. The user is prompted to select one of the
vehicles.
[0566] 3. Upon selection of a valid vehicle, data corresponding to
that vehicle is displayed in the MC&R window. The data is
updated automatically as the vehicle's ADS messages are received at
the AC&M. The data includes the vehicle id, tag, type, minimum
safe distance for collision processing, heading and speed. If the
vehicle has been assigned waypoints the current waypoint, 3-D range
and cross track error are also displayed. The vehicle data remains
displayed until another soft function key is invoked.
[0567] DISPLAY VIEW
[0568] The DISPLAY VIEW command is issued to change the display
view presented on the situation display. The command is invoked by
touching the DISPLAY VIEW soft function key on the AC&M touch
screen.
[0569] Upon invocation, the following steps are followed:
[0570] 1. The DISPLAY VIEW soft function key is highlighted.
[0571] 2. Upon invocation, the following display view options are
displayed in the MC&R window:
19 VIEW ID DESCRIPTION 00 PLAN VIEW 10 MILE RANGE 01 PLAN VIEW 5
MILE RANGE 02 PLAN VIEW 1 MILE RANGE 03 PLAN VIEW .5 MILE RANGE 04
RUNWAY 35 05 RUNWAY 17 06 RUNWAY 24 07 RUNWAY 06 08 GATE AREA 09
FIRE, CRASH AND RESCUE 10 TERMINAL BUILDING 11 3D VIEW RUNWAY 35 12
3D VIEW RUNWAY 17 13 3D VIEW RUNWAY 24 14 3D VIEW RUNWAY 06 15
APPROACH VIEW RUNWAY 35 16 APPROACH VIEW RUNWAY 17 17 APPROACH VIEW
RUNWAY 24 18 APPROACH VIEW RUNWAY 06
[0572] 3. Upon selection of the desired view, the AC&M map
display is redrawn. AIRPORT LIGHTS: the system also demonstrates
the capability to control; airport lights based on GPS inputs and
current clearance status.
20 INTER- ACTIVITY LANDING SECTION TAKEOFF DESCRIPTION LIGHTS
LIGHTS LIGHTS NO ACTIVITY STATE (RUNWAY 35) RED OFF RED (RUNWAY 17)
RED OFF RED TAKE OFF CLEARANCE GIVEN - 35 (35 - TAKEOFF END) RED
OFF RED (17 - OPPOSITE END) RED OFF RED AIRCRAFT ENTERS RNWY 35
ZONE (35 - TAKEOFF END) RED RED GREEN (17 - OPPOSITE END) RED RED
RED TAKE OFF COMPLETED (35 - TAKEOFF END) RED OFF RED (17 -
OPPOSITE END) RED OFF RED LANDING CLEARANCE ISSUED - 35 (35 -
APPROACH END) GREEN RED RED (17 - OPPOSITE END) RED RED RED ARRIVAL
AIRCRAFT EXITS RUNWAY (RUNWAY 35) RED OFF RED (RUNWAY 17) RED OFF
RED RUNWAY INCURSION OCCURRED (RUNWAY 35) FLASH FLASH FLASH
RED/GREEN RED/OFF RED/GREEN (RUNWAY 17) FLASH FLASH FLASH RED/GREEN
RED/OFF RED/GREEN RUNWAY INCURSION ENDS (RUNWAY 35) RED OFF RED
(RUNWAY 17) RED OFF RED
[0573] Airport lighting control techniques are provided as a
demonstration mechanism and are not intended to dictate a specific
lighting scheme for airports.
[0574] Situation Display
[0575] A vehicle database is maintained by the AC&M and on
board `fully equipped` vehicles to provide a situational awareness
capability to the controller and/or vehicle operator. GPS-based
situational awareness requires the integration of a datalink
between the aircraft, surface vehicles and the AC&M system. In
the demonstration prototype system, the position and velocity
information determined on board each vehicle is broadcase over and
experimental VHF datalink and received by the AC&M. At the
AC&M, the message is assembled into a dynamic vehicle database.
As each ADS message is received, the following fields in the
vehicle database are updated:
[0576] Vehicle I
[0577] Vehicle Type
[0578] Position (ECEF X,Y,Z)
[0579] Velocity (ECEF X,Y,Z)
[0580] In order to present the vehicle position data graphically,
the following information is also maintained in the vehicle
database:
[0581] Layer ID
[0582] Vehicle Color
[0583] Each vehicle is assigned a map layer based on vehicle type.
The digital airport map features numerous object oriented layers
which are used to segregate various types of graphical information.
By assigning vehicles to specific map layers, spatial filtering may
be performed on a layer by layer basis. Color my be assigned by
layer or by individual vehicle.
[0584] Position reporting functions operating on a moving platform
potentially suffer from a positional error introduced by processing
time. To compensate for this factor, the precise DGPS derived ECEF
velocity components are used to project the position ahead. As each
ADS message is received, a latency compensation time projection
factor is applied in an ECEF Velocity.times.Time relationship. The
new, projected ECEF position is then considered the current
position, is stored in the vehicle database and is used throughout
the navigation and collision prediction algorithms.
[0585] Once the dynamic vehicle database is constructed, a
sequential scanning of the database is performed as new ADS
position reports are received. Vehicles outside of the defined
range are filtered out. Vehicles within range are displayed in the
3-D airport map. In this manner, graphical situational awareness is
provided at the AC&M and on board the vehicles/aircraft.
[0586] Collision Prediction Processing
[0587] As ADS messages are received, collision prediction
processing is performed using the current GPS data and the
information stored in the vehicle database. The following database
fields are used in the collision prediction processing:
21 Collision Time Time (secs) when a collision may occur Collision
Count Number of potential collisions detected Collision Condition
Warning or watch state detected Collision Separation Current
collision separation Radius Vehicle's minimum separation radius
[0588] A `rough check` is performed to determine if there are any
vehicles in the immediate vicinity of the current vehicle. The
current vehicle's position is projected ahead using a defined
MAXIMUM_PROJECTION_FACTOR. The vehicle database is sequentially
scanned. The position of the first vehicle in the database is
projected ahead in the same manner. If the projected positions
intersect, further collision checking is performed.
[0589] When further collision checking is warranted, the current
vehicle's position is projected ahead by incrementing time in one
second intervals. At each interval, an imaginary sphere is drawn
around the vehicle using a predefined radius based on the vehicle's
minimum safe separation. Similarly, the position of the next
vehicle in the database is projected ahead. If the two imaginary
spheres intersect and the time interval of the intersection is less
than or equal to the MINIMUM_WARNING_TIME factor, a collision
warning condition is generated. If the two imaginary spheres
intersect at a time interval greater than the MINIMUM_WARNING_TIME
but less than the MINIMUM_WATCH_TIME, a collision watch condition
is generated.
[0590] If a collision watch condition is generated, the vehicles in
the watch condition are displayed in YELLOW on the AC&M map
display. A warning message is displayed to the operator in the
Alerts window of the touchscreen. If a warning condition is
detected, the vehicle's symbol is displayed in RED on the graphics
screen and a warning message is displayed in the Alert window.
[0591] During any collision condition, the vehicle's symbol is
moved to a dedicated watch or warning map layer. These layers are
reserved for critical operations and cannot be suppressed by the
user.
[0592] The following collision data was generated from actual
collision tests and represents two surface vehicles driving towards
each other. During this test scenario, the following factors were
used:
22 MINIMUM_WARNING_TIME 3 seconds MINIMUM_WATCH_TIME 7 seconds
RADIUS, VEHICLE 03 7 meters RADIUS, VEHICLE 04 7 meters
[0593] Note that a COLLISION WATCH is detected when the distance
between the two vehicles is less than the sum of its radii. A
COLLISION WARNING is detected when the intersection occurs within
the MINIMUM_WARNING_TIME of 3 seconds or less. Also note that as
soon as the vehicles pass one another and the distance between them
begins to increase, no WATCH or WARNING condition is detected.
[0594] VEH=03 DIST=74.9 PROJ TIME=1 SECONDS
[0595] VEH=03 DIST=64.7 PROJ TIME=2 SECONDS
[0596] VEH=03 DIST=54.5 PROJ TIME=3 SECONDS
[0597] VEH=03 DIST=44.3 PROJ TIME=4 SECONDS
[0598] VEH=03DIST=34.2 PROJ TIME=5 SECONDS
[0599] VEH=03DIST=24.0 PROJ TIME=6 SECONDS
[0600] VEH=03DIST=14.0 PROJ TIME=7 SECONDS COLLISION WATCH
[0601] VEH=04DIST=70.0 PROJ TIME=1 SECONDS
[0602] VEH=04DIST=59.7 PROJ TIME=2 SECONDS
[0603] VEH=04DIST=49.5 PROJ TIME=3 SECONDS
[0604] VEH=04DIST=39.2 PROJ TIME=4 SECONDS
[0605] VEH=04DIST=29.0 PROJ TIME=5 SECONDS
[0606] VEH=04DIST=18.8 PROJ TIME=6 SECONDS
[0607] VEH=04DIST=8.9 PROJ TIME=7 SECONDS COLLISION WATCH
[0608] VEH=03DIST=64.1 PROJ TIME=1 SECONDS
[0609] VEH=03DIST=53.7 PROJ TIME=2 SECONDS
[0610] VEH=03DIST=43.4 PROJ TIME=3 SECONDS
[0611] VEH=03DIST=33.1 PROJ TIME=4 SECONDS
[0612] VEH=03DIST=22.8 PROJ TIME=5 SECONDS
[0613] VEH=03DIST=12.7 PROJ TIME=6 SECONDS COLLISION WATCH
[0614] VEH=04DIST=59.1 PROJ TIME=1 SECONDS
[0615] VEH=04DIST=48.6 PROJ TIME=2 SECONDS
[0616] VEH=04DIST=38.1 PROJ TIME=3 SECONDS
[0617] VEH=04DIST=27.6 PROJ TIME=4 SECONDS
[0618] VEH=04DIST=17.1 PROJ TIME=5 SECONDS
[0619] VEH=04DIST=7.0 PROJ TIME=6 SECONDS COLLISION WATCH
[0620] VEH=03DIST=53.3 PROJ TIME=1 SECONDS
[0621] VEH=03DIST=42.7 PROJ TIME=2 SECONDS
[0622] VEH=03DIST=32.3 PROJ TIME=3 SECONDS
[0623] VEH=03DIST=21.8 PROJ TIME=4 SECONDS
[0624] VEH=03DIST=11.4 PROJ TIME=5 SECONDS COLLISION WATCH
[0625] VEH=04DIST=47.8 PROJ TIME=1 SECONDS
[0626] VEH=04DIST=37.1 PROJ TIME=2 SECONDS
[0627] VEH=04DIST=26.4 PROJ TIME=3 SECONDS
[0628] VEH=04DIST=15.8 PROJ TIME=4 SECONDS
[0629] VEH=04DIST=5.4 PROJ TIME=5 SECONDS COLLISION WATCH
[0630] VEH=03DIST=41.9 PROJ TIME=1 SECONDS
[0631] VEH=03DIST=31.2 PROJ TIME=2 SECONDS
[0632] VEH=03DIST=20.5 PROJ TIME=3 SECONDS
[0633] VEH=03DIST=9.9 PROJ TIME=4 SECONDS COLLISION WATCH
[0634] VEH=04DIST=36.6 PROJ TIME=1 SECONDS
[0635] VEH=04DIST=25.9 PROJ TIME=2 SECONDS
[0636] VEH=04DIST=15.3 PROJ TIME=3 SECONDS
[0637] VEH=04DIST=5.4 PROJ TIME=4 SECONDS COLLISION WATCH
[0638] VEH=03DIST=31.9 PROJ TIME=1 SECONDS
[0639] VEH=03DIST=21.2 PROJ TIME=2 SECONDS
[0640] VEH=03DIST=10.6 PROJ TIME=3 SECONDS COLLISION WARNING
[0641] VEH=04DIST=26.6 PROJ TIME=1 SECONDS
[0642] VEH=04DIST=15.9 PROJ TIME=2 SECONDS
[0643] VEH=04DIST=5.6 PROJ TIME=3 SECONDS COLLISION WARNING
[0644] VEH=03DIST=14.4 PROJ TIME=1 SECONDS
[0645] VEH=03DIST=4.6 PROJ TIME=2 SECONDS COLLISION WARNING
[0646] VEH=04DIST=10.6 PROJ TIME=1 SECONDS COLLISION WARNING
[0647] VEH=03DIST=5.9 PROJ TIME=1 SECONDS COLLISION WARNING
[0648] VEH=04 DIST=2.9 PROJ TIME=1 SECONDS COLLISION WARNING
[0649] DIST=5.4, VEHICLE SEPARATION IS INCREASING, STOP PROCESSING
. . .
[0650] Zone Incursion Processing
[0651] A 3-D map database and ECEF mathematical processing
algorithms support the concept of zones. Zones are three
dimensional shapes which are used to provide spatial cueing for a
number of constructs unique to DSDC's demonstration system. Zones
may be defined around obstacles which may pose a hazard to
navigation, such as transmission towers, tall buildings, and
terrain features. Zones may also be keyed to the airport's NOTAMS,
identifying areas of the airport which have restricted usage.
[0652] Zones are represented graphically on the map display and
mathematically by DSDC's zone processing algorithms. Multi-sided
zones are stored in a zone database as a series of points. Each
zone is assigned a zone id and type. The zone type is used to
determine whether a particular zone is off-limits for a specific
vehicle type.
[0653] Zone information is maintained in the zone database. A zone
incursion status field is also maintained for the vehicle in the
vehicle database. If the vehicle is currently inside a zone, this
field is used to store the zone's id. If the vehicle is not inside
a zone, this field is zero (0).
[0654] At the AC&M, zone incursion processing is performed in a
manner similar to the collision processing described previously. As
each vehicle report is received, it is projected ahead by
incrementing time up to a MAX_ZONE_PROJECTION_FACTOR. At each
interval, the vehicle's projected position is compared to each line
of the zone as defined by its endpoints. If the vehicle's position
is inside all of the lines comprising the zone and the current
projection time is less than the MIN_ZONE_WARNING factor, a zone
incursion warning is generated. If the vehicle's position is inside
the zone and the current projection time is less than the
MIN_ZONE_WATCH factor but greater than the MIN_ZONE_WARNING factor,
a zone incursion watch is generated. As in the collision
processing, a zone incursion watch or warning will result in a
message displayed to the operator and a change in layer assignments
for the affected vehicle.
[0655] A zone incursion condition is automatically cleared when the
vehicle exits the zone. All zones are defined as 3-dimensional
entities and may be exited laterally or vertically. Heights may be
assigned to `surface` zones individually or collectively. The
concepts of 3-dimensional zones is critical to an airport
environment to prevent passing aircraft from triggering
ground-based zones.
[0656] Runway Incursion Processing
[0657] If a zone incursion is detected, a further check is
performed to determine if the vehicle is entering or inside a
runway zone. For Manchester Airport, five (5) runway zones have
been defined:
[0658] RNWY_35_ZONE
[0659] RNWY_17_ZONE
[0660] RNWY_24_ZONE
[0661] RNWY_06_ZONE
[0662] RNWY_INT_ZONE "RUNWAY INTERSECTION VOLUME"
[0663] An additional field is maintained in the vehicle database to
indicate whether a runway incursion state has been detected. As
with the zone incursion field, the runway incursion value is set to
the id of the zone (i.e., the runway) if an incursion is currently
occurring and is set to zero (0) if there is no runway
incursion.
[0664] If the vehicle is entering or inside a runway zone and is
not cleared for that zone, a runway incursion condition is
generated at the AC&M. As in any zone incursion situation, a
watch or warning message is displayed in the AC&M Alerts window
and the vehicle's symbol is moved to the dedicated watch or warning
map layer, changing its color to YELLOW or RED. In addition, the
runway incursion results in a status change in the runway's
landing, takeoff and intersection lights forcing the lights to
flash on the affected (and related) runway(s). The following table
describes the lighting states for runway incursions in each of the
five runway zones.
23 RNWY 35 RNWY 17 RNWY 24 RNWY 06 ACTIVITY DESCRIPTION A D I A D I
A D I A D I INCURSION - RNWY 35 FLASH FLASH NO CHANGE NO CHANGE
INCURSION ENDS DEFAULT DEFAULT NO CHANGE NO CHANGE INCURSION - RNWY
17 FLASH FLASH NO CHANGE NO CHANGE INCURSION ENDS DEFAULT DEFAULT
NO CHANGE NO CHANGE INCURSION - RNWY 24 NO CHANGE NO CHANGE FLASH
FLASH INCURSION ENDS NO CHANGE NO CHANGE DEFAULT DEFAULT INCURSION
- RNWY 06 NO CHANGE NO CHANGE FLASH FLASH INCURSION ENDS NO CHANGE
NO CHANGE DEFAULT DEFAULT INCUR. - INTERSECTION FLASH FLASH FLASH
FLASH INCURSION ENDS DEFAULT DEFAULT DEFAULT DEFAULT KEY: A =
APPROACH LIGHTS FLASH = RED/GREEN DEFAULT = RED D = DEPARTURE
LIGHTS FLASH = RED/GREEN DEFAULT = RED I = INTERSECTION LIGHTS
FLASH = RED/OFF DEFAULT = OFF
[0665] A runway incursion is automatically terminated when the
incurring vehicle exits the runway. When the incursion condition is
terminated, the lights on the affected runway return to their
default state. As in all zone definitions, runway zones are
3-dimensional entities. Runway zones are assigned a height of
approximately 100 meters above the surface of the runway in the
prototype demonstration system. Therefor, a runway incursion occurs
only when an uncleared vehicle enters the zone at the surface
level. Demonstration prototype lighting software is provided
below:
Lighting Control Software Example
[0666]
24 /*******************************************************-
********* LIGHTS.H Description: lights.h contains the global
constants and data structures for the airport lights.
****************************************************************/
#define LIGHT_ADDR 0x300 /* address of digital IO board */ /*-
light bit settings, digital I/O card -*/ #define LANDING_35 0x01
#define LANDING_17 0x02 #define LANDING_24 0x04 #define LANDING_06
0x08 #define TAKEOFF_17 0x10 #define TAKEOFF_06 0x20 #define
TAKEOFF_35 0x40 #define TAKEOFF_24 0x80 /*----- light status states
-----*/ #define NO_ACTIVITY 0 #define RUNWAY_INCURSION 1 #define
LANDING 2 #define TAKEOFF 3 #define SURFACE 5 /*---- ruwnay id
----*/ #define RNWY_35 35 #define RNWY_17 17 #define RNWY_24 24
#define RNWY_06 6 #define RNWY_INT 1
/****************************************************************
File Name: LIGHTS.C Description: lights.c contains the procedures
used update the airport lighs Units : initialize_lights,
update_lights, update_clearance_lights, get_runway_clear,
process_clearance
****************************************************************/
#include <stdio.h> /* standard input/output */ #include
<graph.h> /* MSC graphics routines */ #include
<string.h> /* MSC string routines */ #include
<stdlib.h> /* MSC standard library */ #include <math.h>
/* MSC math library */ #include "sio.h" /* serial input/output */
#include "lights.h" /* airport light definitions */ #include
"veh.h" /* vehicle data */ #include "coord.h" /* coordinate data */
/*-------------------- external functions --------------------*/
void store_wps(char wp_id[12],int wpindex); /*--------------------
external variables --------------------*/ extern VEHICLE_DATA
veh[MAX_VEHS]; /* vehicle database */ extern unsigned curr_lights;
/* current light settings */ /*-------------------- global
variables --------------------*/ short current_clearance; /* set if
any vehicle is cleared */ char veh_cleared[8]; /* vehicle cleared
for landing/takeoff*/ short veh_clear_status;/* clearance status
for curr vehicle */ short end_of_wps; /* end of clearance/ wps */
/*------------------------ -----------------------------------
UNIT: initialize_lights( ) DESCRIPTION: initialize_lights sets the
airport lights to their default settings - RED for landing and
takeoff lights and OFF for runway intersection (i.e., stop) lights.
-------------------------- ---------------------------------*/
initialize_lights( ) { update_lights(NO_ACTIVITY,RNWY_35);
update_lights(NO_ACTIVI- TY,RNWY_17);
update_lights(NO_ACTIVITY,RNWY_24);
update_lights(NO_ACTIVITY,RNWY_06); }
/*---------------------------------------------------------- UNIT:
update_lights DESCRIPTION: this routine resets the lights on the
specified runway based. ------------------------------------
-----------------------*/ update_lights(int activity_type, int
rnwy) { switch (rnwy) { case RNWY_35 : case RNWY_17 : switch
(activity_type) { case NO_ACTIVITY : curr_lights = curr_lights
& 0xAC; break; } break; case RNWY_24 : case RNWY_06 : switch
(activity_type) { case NO_ACTIVITY : curr_lights = curr_lights
& 0x53; break; } break; case RNWY_INT : switch (activity_type)
{ case NO_ACTIVITY : curr_lights = 0; break; } break; } /* write
new light settings to board */ outp(LIGHT_ADDR,curr_lights); }
/*------------------------ -----------------------------------
UNIT: update_clearance_lights DESCRIPTION: this routine updates the
specified clearance lights for a landing or takeoff operation. The
landing/ takeoff light for the specified runway is enabled, then
the remaining landing/taxi lights for both runway ends are
disabled. INPUTS: curr_clear - clearance issued by ATC
----------------------------------------------------------*/
update_clearance_lights(short curr_clear) { /* based on current
clearance, affected runway and the current status of the runway's
lights, update the lights */ switch (curr_clear) { case LANDING_35
: if ((curr_lights & LANDING_35) = = 0) curr_lights =
curr_lights + LANDING_35; break; case LANDING_17 : if ((curr_lights
& LANDING_17) = = 0) curr_lights = curr_lights + LANDING_17;
break; case LANDING_24 : if ((curr_lights & LANDING_24) = = 0)
curr_lights = curr_lights + LANDING_24; break; case LANDING_06 : if
((curr_lights & LANDING_06) = = 0) curr_lights = curr_lights +
LANDING_06; break; case TAKEOFF_35 : if ((curr_lights &
TAKEOFF_35) = = 0) curr_lights = curr_lights + TAKEOFF_35; break;
case TAKEOFF_17 : if ((curr_lights & TAKEOFF_17) = = 0)
curr_lights = curr_lights + TAKEOFF_17; break; case TAKEOFF_24 : if
((curr_lights & TAKEOFF_24) = = 0) curr_lights = curr_lights +
TAKEOFF_24; break; case TAKEOFF_06 : if ((curr_lights &
TAKEOFF_06) = = 0) curr_lights = curr_lights + TAKEOFF_06; break; }
/* write new light settings to board */ outp(LIGHT_ADDR,curr_ligh-
ts); } /*----------------------------------------------------
------- UNIT: get_runway_clear DESCRIPTION: determines the landing
or takeoff flag setting INPUTS: int rw_id - id of runway char *
msg_type - arrival or takeoff ------------------------
-----------------------------------*/ int get_runway_clear(int
rw_id, char *msg_type) { /**- local variables -**/ int clear_stat;
/* clearance status */ /* update current clearance (clear_stat)
based on the designated runway (rw_id) and type of clearance
(ARRIVAL) or (TAKEOFF) */ switch (rw_id) { case RNWY_35 : if
(strstr(msg_type,"ARR") != NULL) clear_stat = LANDING_35; else
clear_stat = TAKEOFF_35; break; case RNWY_17 : if
(strstr(msg_type,"ARR") != NULL) clear_stat = LANDING_17; else
clear_stat = TAKEOFF_17; break; case RNWY_24 : if
(strstr(msg_type,"ARR") != NULL) clear_stat = LANDING_24; else
clear_stat = TAKEOFF_24; break; case RNWY_06 : if
(strstr(msg_type,"ARR") != NULL) clear_stat = LANDING_06; else
clear_stat = TAKEOFF_06; break; default : clear_stat = SURFACE; }
return(clear_stat); } /*-------------------------------
---------------------------- UNIT: process_clearance for arrival
(landing) waypoints and $ATC,004,veh id,waypoint id for departure
(takeoff) waypoints INPUTS: char clearance_msg[MAX_STR]
-------------------------------------------- ---------------*/
process_clearance(char clearance_msg[MAX_STR]) { /**- local
variables -**/ char wp_id[12]; /* waypoint id */ char *token; /*
character field from ATC msg */ int rw_id; /* id of runway cleared
for operation */ int veh_index; /* index into veh database for
current veh */ int slen; /* string length */ int i; /* counter */
/* parse clearance message */ token = strtok(clearance_msg,","); /*
$ATC */ token = strtok(NULL,","); /* message type */ token =
strtok(NULL,","); /* vehicle id */ strcpy(veh_cleared,token); token
= strtok(NULL,","); /* waypoint id */ /* extract waypoint
information */ slen = strlen(token) - 2; for (i = 0; i < slen;
i++) wp_id[i] = token[i]; wp_id[i] = `.backslash.0`; /* get runway
id from waypoint information */ if (strstr(wp_id,"35") != NULL)
rw_id = RNWY_35; else if(strstr(wp_id,"24") != NULL) rw_id =
RNWY_24; else if (strstr(wp_id,"17") != NULL) rw_id = RNWY_17; else
if (strstr(wp_id,"06") != NULL) rw_id = RNWY_06; else rw_id = 0; /*
find vehicle in vehicle database */ veh_index =
find_veh_index(veh_cleared); if (veh_index != -1) /* if vehicle
found in database */ { /* set clearance based on message type and
selected runway */ current_clearance = current_clearance -
veh[veh_index].clear_status; veh[veh_index].clear_status =
get_runway_clear(rw_id,wp_id); current_clearance =
veh[veh_index].clear_status + current_clearance; /* extract and
store waypoint data */ store_wps(wp_id,veh[veh_index].wpindex);
veh[veh_index].currwp = NO_WP; end_of_wps = FALSE; /* update lights
immediately for arrival aircraft */ if (strstr(wp_id,"ARR") !=
NULL) update_clearance_lights(current_clearance); } /* if vehicle
in database */ }
[0667] DESCRIPTION: process_clearance parses the clearance or
departure message issued by the controller via the touch screen.
update_clearance_lights is then called to change the specified
light settings.
[0668] The message format is: $ATC,002,veh id,waypoint id
[0669] If the vehicle is entering or inside a runway zone and the
vehicle has a clearance, a runway incursion is not detected. A
clearance is issued by the AC&M operator using the ARRIVAL
WAYPOINTS, DEPARTURE WAYPOINTS or SURFACE WAYPOINTS functions.
[0670] When a clearance is issued, a global CURRENT_CLEARANCE flag
is updated. The CURRENT_CLEARANCE flag is used to maintain the
current airport light settings. A separate clearance status flag is
also maintained in the vehicle database for each vehicle. As the
vehicle approaches a runway zone, its clearance status flag is read
to determine whether a runway incursion condition should be
generated. Clearances are terminated automatically when the vehicle
reaches the last waypoint. Clearances may also be manually cleared
by the AC&M operator through the CLEAR PATH WAYPOINTS function.
When the clearances are terminated, the global CURRENT_CLEARANCE
flag and individual vehicle clearance flags are updated.
[0671] ECEF Waypoint Navigation
[0672] After waypoints have been issued to a vehicle or vehicles,
the AC&M performs a set of navigation functions, mirroring
those performed on board the vehicle using the ADS position
reports. A set of waypoints is maintained for each cleared vehicle.
The vehicle's current 3-D range to the waypoint and cross track
error is computed for each subsequent ADS report. A determination
as to whether the vehicle is on or off course is also made. If an
off course condition is detected, a warning message is displayed to
the operator in the AC&M's Alerts window.
[0673] To support the AC&M's mirrored navigation processing,
the following fields are maintained in the vehicle database:
[0674] Waypoint Index
[0675] Current Waypoint
[0676] Cross Track Error
[0677] 3D Range to Waypoint
[0678] Wrong Way Indicator
[0679] The Waypoint Index is the ID of the waypoint list assigned
to the vehicle and the Current Waypoint is the waypoint the pilot
is navigating towards.
[0680] At any time after the assignment of waypoints to the
vehicle, the vehicle's 3-D range to the waypoint, cross track
error, current waypoint, speed and heading information may be
displayed in the MC&R window using the VEHICLE DATA
function.
Graphics Processor and AC&M Interface
[0681] The Graphics Processor (GP) 122 interfaces to the AC&M
Processor 121 via a dedicated communication link 123. The GP is
currently based on a 66 mHz 486 processor with a VESA Video Local
Bus. This processor performs the following functions:
[0682] Receives graphics commands from AC&M
[0683] Interprets graphics commands
[0684] Performs the graphic display functions
[0685] Provides situational awareness capability
[0686] Manages the view and content of the display presentation
[0687] Maintains local map-based waypoint, zone and map layer
databases
[0688] Interface with large graphics display hardware
[0689] Two types of messages are received by the GP:
[0690] (1) vehicle position messages
[0691] (2) display commands
[0692] Upon receipt of an ADS report, the AC&M Processor
converts the vehicle's ECEF X,Y,Z position to the map's coordinate
system if required and determines the appropriate map layer for the
vehicle based on the vehicle's type and any collision or zone
incursion conditions. If the vehicle is moving, the newly formatted
message is sent to the GP. Stationary vehicle's are not redisplayed
in the map but remain displayed in their last reported position.
The message format is shown below:
[0693] $TRK,vehicle id,map layer,map x, map y, mapz
coordinates<CR><LF>
[0694] Display commands are also generated by the AC&M
Processor 121 and sent to the GP 122. Numerous AC&M commands,
including ARRIVAL WAYPOINTS, DEPARTURE WAYPOINTS, SURFACE
WAYPOINTS, CLEAR PATH WAYPOINTS, DISPLAY VIEW, VEHICLE FILTER and
LAYER FILTER affect the display presentation on the GP. An
acknowledgment is returned to the AC&M Processor 121 when a
display command message is received by the GP 122.
[0695] LAYER ASSIGNMENTS
[0696] The GP 122 supports up to 256 unique layers which are used
for the display and segregation of graphic information. The layer
assignments are provided below.
25 MAP LAYER ASSIGNMENTS LAYER # DESCRIPTION MODE 0-2 AIRPORT MAP
RUNWAYS, TAXIWAYS, TRAVEL PATHS ALWAYS 3 RANGE RINGS ON DEMAND 4
EXPANSION TBD 5 RANGE RINGS, 5 MILE INCREMENTS ON DEMAND 6-8
EXPANSION TBD 9 AIRPORT LIGHTING SYSTEMS (RNWY 35) ON DEMAND 10
AIRPORT LIGHTING SYSTEMS (RNWY 24) ON DEMAND 11 TRACKED SURFACE
VEHICLES (LIMITED ACCESS) ALWAYS 12 TRACKED SURFACE VEHICLES (FULL
ACCESS) ALWAYS 13 TRACKED DEPARTURE AIRCRAFT ALWAYS 14 TRACKED
ARRIVAL AIRCRAFT ALWAYS 15-19 EXPANSION TBD 20 ARRIVAL WAYPOINTS ON
DEMAND 21 DEPARTURE WAYPOINTS ON DEMAND 22 SURFACE WAYPOINTS ON
DEMAND 23 CUSTOM WAYPOINTS DEFINITION ON DEMAND 24 EXPANSION TBD 25
AIRPORT SURFACE ZONES ON DEMAND 26 WEIGHT LIMITED ZONES ON DEMAND
27 RESTRICTED TRAVEL AREA (WINGSPAN, ETC.) ON DEMAND 28 AIRSPACE
HAZARD ZONES ON DEMAND 29 OPEN CONSTRUCTION ZONES ON DEMAND 30
CLOSED CONSTRUCTIONS ZONES ON DEMAND 31-60 EXPANSION TBD 61 WATCH
LAYER (COLOR = YELLOW) ALWAYS 62 WARNING LAYER (COLOR = RED)
ALWAYS
Vehicles
[0697] AC&M System Functional Matrix
[0698] Many of the functions performed at the AC&M Processor
are also performed on board the vehicles. Three vehicles, equipped
with varying configurations of hardware and software, have been
used in a number of prototype demonstrations. The matrix below
lists the major functions and the vehicles on which they are
performed.
26 VEHICLE FUNCTIONAL MATRIX FULL LIMITED ACCESS ACCESS AIR-
VEHICLE VEHICLE FUNCTION AC&M CRAFT 1 2 Receive & process
DGPS N Y Y Y corrections Formats and transmits N Y Y Y ADS posn
& vel. data Receives remote ADS Y N Y N messages Displays ADS
positions Y N Y N in map display Performs dynamic Y N Y N collision
processing Performs zone incursion Y Y Y Y processing Performs
runway incursion Y N N N processing Controls airport lights Y N N N
Formats ATC commands Y N N N Receives ATC commands N Y Y Y Performs
waypoint Y Y Y N navigation Displays current position N Y Y N in
moving map display
[0699] Hardware block diagrams for each of the three prototype
vehicle types are provided in the figures which follow, starting
with the Aircraft System FIG. 24.
[0700] Differential GPS data is provided by a GPS GOLD DGPS
receiver 124 and a differential data link 125. GPS position,
velocity, and time information is supplied to the dual 486 based
processing unit. The first 486 processor, or Navigation (NAV)
Processor 126, receives GPS Receiver 124 information and performs
the following functions:
[0701] Coordinate conversions from Lat/Lon/MSL to ECEF X, Y, Z
[0702] Position projections
[0703] Zone and runway incursion checking
[0704] Map layer control
[0705] General ECEF waypoint navigation and on/off course
processing
[0706] ECEF-based precision landing navigation
[0707] Access to waypoint and zone databases
[0708] Transmission of graphic instructions to second 486 processor
127
[0709] Broadcast of position and velocity data over ADS datalink
128
[0710] Control of communication digital datalinks
[0711] Support for monochrome flat panel display 129
[0712] The second 486 processor, the Aircraft Graphics Processor
(AGP) 127, receives graphics instructions from the NAV Processor
126 and performs the following functions:
[0713] Graphics command translations and interpretations
[0714] Graphic display functions
[0715] Display presentation view and content management
[0716] Support for monochrome flat panel display 130
[0717] The functions supported in the aircraft are actually a
slightly modified version of those performed by the AC&M
Subsystem. The use of common hardware and operational software
elements simplified the prototype demonstration development
efforts.
[0718] The full access surface vehicle (Vehicle #1) high level
block diagram is provided in FIG. 25.
[0719] Again, differential GPS data is provided by a DGPS receiver
131 and a differential data link 132. GPS position, velocity, and
time information are supplied to the dual 486 based processing
unit. The first 486 processor, the Navigation Processor (NAV) 133,
receives GPS information and performs the following functions:
[0720] Coordinate conversions from Lat/Lon/MSL to ECEF X, Y, Z
[0721] Position projections
[0722] Collision prediction processing
[0723] Zone and runway incursion checking
[0724] Layer control
[0725] General ECEF waypoint navigation (optional)
[0726] Access to vehicle, waypoint and zone databases
[0727] Transmission of graphic instructions to second 486 processor
134
[0728] Broadcast of position and velocity data over ADS datalink
135
[0729] Receipt of remote ADS messages from other vehicles
[0730] Control of communication digital datalinks
[0731] Support for flat panel LCD display
[0732] The second 486 processor, the Vehicle Graphics Processor
(VGP) 134 receives graphics instructions from the NAV Processor 133
and performs the following functions:
[0733] Graphics command translations and interpretations
[0734] Graphic display functions
[0735] Situational awareness capability
[0736] Display presentation view and content management
[0737] Support for flat panel LCD display 136
[0738] The functions supported in the full access surface vehicle
are identical to those performed in the aircraft with a couple of
additions. The full access vehicle receives remote ADS messages
from other vehicles operating within the airport space envelope.
This information is used to provide a situational awareness
capability on board the vehicle. Full collision detection
processing is also implemented.
[0739] The limited access surface vehicle (Vehicle #2) is equipped
with developed hardware and software as shown in FIG. 26.
[0740] Since no graphic display is provided on Vehicle #2, a single
386-based processor 137 is utilized. Again, differential GPS data
is provided by an on board DGPS receiver 138 and a differential
data link 139. GPS position, velocity, and time information is
supplied to the 386 based processing unit 137 which performs the
following functions:
[0741] Coordinate conversions from Lat/Lon/MSL to ECEF X, Y, Z
[0742] Position projections
[0743] Zone and runway incursion checking
[0744] Access to zone database
[0745] Sounds audible warning when zone incursion is detected
140
[0746] Broadcast of position and velocity data over ADS datalink
141
[0747] The functions supported in Vehicle #2 are actually a subset
of those supported in the aircraft and Vehicle #1.
[0748] Communications
[0749] Each vehicle is equipped with a VHF/UHF radio capable of
full duplex communications. The radio interfaces to an integrated
modem/GPS interface card. The radio modem is used to receive
differential corrections, ADS messages, and ATC command messages
forwarded by the COMM Processor. Local GPS messages are received by
the vehicle's Navigation (NAV) processor. The GPS position and
velocity data is converted to the ECEF coordinate frame,
reformatted and transmitted to the AC&M Processor over the same
radio.
[0750] Navigation Processor and Navigation
[0751] Navigation functions are performed on board the vehicle when
waypoints are received from the AC&M Processor via the VHF
datalink. Two navigation screens are provided, a cross hairs
display for airborne applications and a map-based display for
ground operations.
[0752] Upon receipt of the waypoint message from the AC&M
Processor, the waypoint id is extracted and used to identify the
predefined waypoint path. The waypoints are automatically loaded
into the vehicle's ECEF navigation system and drawn into the
vehicle's map display. FIG. 27 shows the airborne navigation
display produced with the previously listed software routines.
[0753] The navigator display format is unique since it provides
conventional course, bearing and range information and actual
position with respect to the true course. The display portion on
the right side of the screen is driven by NEU surface parameters
while the display at the left is driven directly by ECEF X, Y, Z
parameters. This display format may be used for all phases of
flight.
[0754] The algorithms for 3-D range to the waypoint, transitioning
to the next waypoint, cross track error, on/off course and wrong
way determination are identical to those performed at the AC&M
Processor.
[0755] For ground taxi operations, map-based waypoint navigation
was found to be preferable. FIG. 8 shows a waypoint path from the
Crash, Fire and Rescue (CFR) Station to the East Terminal Ramp
drawn in the on board digital map display.
[0756] FIG. 9 depicts the predefined waypoint path for a departure
on Runway 35.
[0757] Zones Processing
[0758] All surface vehicles are capable of performing static zone
incursion processing. The zone processing algorithms are identical
to those implemented at the AC&M system with the addition of an
audible tone generated when an incursion occurs.
[0759] Collision Detection Processing
[0760] The fully equipped vehicle (FEV) is capable of performing
collision prediction processing based on the vehicle's current
position (and velocity) and the remote vehicles' ADS messages.
[0761] As the ADS messages are received, they are parsed and stored
in the local vehicle database. Collision processing is performed
each second, upon receipt of the FEV's GPS position and velocity
data. After each GPS update, projections are performed on the FEV's
current position and compared to the projected positions for each
vehicle stored in the local database. In the same manner as
described for the AC&M Processor, potential collision watch and
warning conditions are detected between the FEV and other vehicles.
However, collisions between two remote vehicles are not detected.
Collisions tests are only performed with respect to the FEV itself
and those in its vicinity.
[0762] Graphic Processor and Moving Map Display
[0763] Both the FEV and the aircraft are capable of displaying
their current position with respect to an on board moving map
display. As the vehicle's position approaches the edge of the map
display, the map is automatically panned and redrawn with the
vehicle centered in the display. When the vehicle is on the airport
surface, the map is drawn with a north orientation at a 0.25 mile
plan view perspective. When the vehicle is more than one mile from
the center of the map, the map is automatically redrawn at a ten
(10) mile scale.
[0764] Situational Awareness
[0765] The FEV is capable of displaying the positions of remote
vehicle positions in the on board moving map display. As ADS
messages are received from the COMM Processor, the remote vehicles'
positions are checked to see if they would appear on the current
display view. If the positions are outside of the current view,
they are discarded. Positions within the current view are drawn
into the map display.
[0766] Layer--Color Control
[0767] As at the AC&M processor, the FEV's situational
awareness display uses color cues to indicate vehicles in a
collision or zone incursion condition. As ADS and GPS messages are
received and processed by the on board NAV Processor, graphics
messages are formatted and sent to the local Graphics Processor
(GP). These graphics messages are identical to those created at the
AC&M Processor and include the vehicle id, layer id and map
x,y,z position.
Coordinate Conversions Software Example
[0768]
/****************************************************************
[0769] File Name: COORD.H
[0770] Description: coord.h contains the global definitions and
record structures for waypoint and current
[0771] position data. Waypoint lists are stored by type--arrival,
departure, missed approach or surface.
[0772]
*****************************************************************/
[0773] #define GRND_ALT 92 /* indicates ground level, specific to
Manchester Airport */
[0774] /* coordinate type (coord_type) definitions */
[0775] #define DECDEG 1 /* lat/lon decimal degrees */
[0776] #define NHSPM 2 /* NH state plane meters */
[0777] #define NHSPF 3 /* NH state plane feet */
[0778] /* conversion factors for map/decimal degree conversions
*/
[0779] double LRLON; /* lon for lower right corner of map */
[0780] double LRLAT; /* lat for lower right corner of map */
[0781] double ULLON; /* lon for upper left corner of map */
[0782] double ULLAT; /* lat for upper left corner of map */
[0783] double LRX; /* map x coordinate--lower right */
Over Coming Error Sources
[0784] Map Temporal Differential Correction
[0785] Map temporal differential corrections are a simple and
effective means of reducing error sources in GPS operation for
short periods of time when Selective Availability is not active.
FIG. 31 depicts the map temporal correction elements.
[0786] Map temporal corrections utilize at least one precisely
surveyed location in the local area. The surveyed location may be
determined from a monument marker or may be determined using a
highly accurate digital or paper map. A GPS receiver and
(optionally) a processing computer are co-located at the known
location with the GPS antenna carefully positioned at the survey
point. The receiver/computer remains at the known location for a
period of time and, when enough data has been collected, determines
pseudo range correction and pseudo range rate factors. These
correction factors may then be applied to the differential GPS
receiver to determine a corrected position. These factors are used
in subsequent position determinations until another map temporal
correction is applied.
[0787] Map temporal corrections are the simplest form of closed
loop differential correction. As the name implies, temporal
corrections degrade with time as the receiver moves within the
local area. SA significantly reduces the benefits of a temporal
differential correction approach. When SA is not active, the short
term (30 minute) accuracy of this technique is very good (a meter
or two), since all error sources are reduced. One additional
limiting factor is that the same satellites must be used during
roving operations as those used at the surveyed location. This may
be accomplished through software control to ensure a `selected` set
of satellites are used for a given GPS session.
[0788] Regional Differential Corrections and Differential
Overview
[0789] Real time differential correction techniques compensate for
a number of error sources inherent to GPS. The idea is simple in
concept and basically incorporates two or more GPS receivers, one
acting as a stationary base station and the other(s) acting as
roving receiver(s). The differential base station is "anchored" at
a known point on the earth's surface. The base station receives the
satellite signals, determines the errors in the signals and then
calculates corrections to remove the errors. The corrections are
then broadcast to the roving receivers.
[0790] Real time differential processing provides accuracies of
10.0 meters or better (typically 1.0-5.0 meters for local
differential corrections). The corrections broadcast by the base
station are accurate over an area of about 1500 km or more. Typical
positional degradation is approximately a few millimeters of
position error per kilometer of base station and roving receiver
separation. FIG. 32 shows the basic elements for real time
differential GPS (DGPS) operations.
[0791] Through the implementation of local differential GPS
techniques, SA errors are reduced significantly while the
atmospheric errors are almost completely removed. Ephemeris and
clock errors are virtually removed as well.
27 ERROR SOURCES CORRECTED OR REDUCED BY DGPS USER RANGE ERRORS
(URE) 1 SIGMA MAGNITUDES WITHOUT DGPS WITH DGPS SATELLITE CLOCK
& NAV. 2.7 0 EPHEMERIDES & PREDICTION 2.7 0 ATMOSPHERIC
IONOSPHERIC 9.0 0 TROPOSPHERIC 2.0 .15* SELECTIVE AVAILABILITY
30.0# 0 TOTAL RSS 31.6 .15 *Tropospheric effects are a local
phenomenon and are a function of the altitude difference from the
base station to the roving receiver and the local elevation angle
of the satellite. #To counteract the effects of SA, differential
corrections must be generated, transmitted and utilized in the GPS
receiver at a rate sufficient to compensate for the rate of change
of SA.
[0792] Differential GPS can introduce an additional error, if not
employed properly. The age of the differential correction must be
monitored at the GPS receiver. As the differential correction ages,
the error in the propagated value increases as well. This is
particularly true for `virulent` strains of SA where the errors
introduced slew quickly over very short time intervals.
[0793] Operational Elements
[0794] The precisely surveyed location of the GPS antenna is
programmed into the reference station as part of its initial
installation and set up procedures. Industry standard reference
stations determine pseudo range and delta range based on carrier
smoothed measurements for all satellites in view. Since the exact
ECEF position of the antenna is known, corrections may be generated
for the pseudo range and delta range measurements and precise time
can be calculated.
[0795] Naturally occurring errors are, for the most part, slow
changing and monotonic over the typical periods of concern. When SA
is not invoked, delta range corrections provide a valid method of
improving positional accuracy at the roving receivers using less
frequent correction broadcasts. With the advent of SA and its
random, quick changing non-monotonic characteristics, delta range
corrections become somewhat meaningless and may actually degrade
the system performance under some conditions.
[0796] As shown previously in FIG. 32, the DGPS correction messages
are broadcast by the reference station and received by the roving
receivers. The corrections are applied directly to the differential
GPS receiver. The DGPS receiver calculates the pseudo range and the
delta range measurements for each satellite in the usual manner.
Prior to performing the navigation solution, the received pseudo
range and delta range corrections are applied to the internal
measurements. The receiver then calculates corrected position,
velocity and time data. Typical DGPS position and velocity
performance is presented in the table below.
28 COMPARISON OF TYPICAL GPS POSITION AND VELOCITY MEASUREMENTS
USING COMMERCIAL NAVIGATION TYPE RECEIVERS (ACCURACIES ARE A
FUNCTION OF CORRECTION AGE) THIS EXAMPLE USES CORRECTION AGE = 5
SECONDS WITHOUT DGPS WITH DGPS CODE RCVR CARRIER RCVR CODE RCVR
CARRIER RCVR 2-D POSITION <100 M <40 M <10 M <2 M 3-D
POSITION <176 M <80 M <18 M <4 M VELOCITY knots <10
KN <5 KN <.1 KN <.1 KN TIME* <300 ns <100 ns <100
ns <50 ns *The time accuracy is highly dependent upon the type
of receiver. Specialized, precise time receivers provide accuracies
in the 5 to 25 nanosecond range. Most navigational receivers do not
provide this level of time accuracy since it is not required for
general navigation.
[0797] Since differential GPS eliminates most GPS errors, it
provides significant improvements in system reliability for life
critical airport operations. Short term and long term drift of the
satellite orbits, clocks and naturally occurring phenomenon are
compensated for by differential GPS as are other potential GPS
satellite failures. Differential GPS is mandatory in the airport
environment from a reliability, accuracy and fault compensating
perspective.
[0798] As with autonomous GPS receiver operation, multipath is a
potential problem. The differential reference station cannot
correct for multipath errors at the roving receiver(s). Antenna
design and placement considerations, and receiver design
characteristics remain the best solutions to date in the
minimization of multipath effects.
[0799] DGPS provides the means to eliminate most GPS system errors.
The remaining errors are related to receiver design and multipath.
Not all GPS receivers and reference stations are created equal,
some are distinctly better than others. The selection of the
reference station and the roving receivers has a significant effect
on the overall system accuracy.
[0800] Compensating for Receiver Error
[0801] Receiver errors are not corrected using an `open loop`
differential correction method as described above. These errors may
be reduced when a `closed loop` differential technique is employed.
FIG. 33 presents a high level block diagram of a `closed loop`
differential system.
[0802] FIG. 33 has additional elements over the standard
differential system configuration. A second GPS antenna is
installed at a precisely surveyed antenna location and a stationary
GPS receiver is co-located with the reference station. This
receiver accepts differential correction inputs generated by the
reference station. The stationary GPS receiver incorporates the
pseudo range corrections in the normal manner and determines DGPS
position and velocity. The corrected position and velocity are then
compared to the stationary receivers known position and velocity
(0,0,0). The ECEF delta position and velocity data are then used by
the reference station processing to further refine the pseudo range
and delta range corrections which are broadcast to the roving
receivers. Processing software which minimizes the position and
velocity errors is used. This technique requires that the roving
receivers be identical to the stationary GPS receiver located at
the reference station site. That is, the roving receivers must
exhibit receiver errors similar to those on the stationary DGPS
receiver.
Integrity and Multi-sensor Systems
[0803] The issues of integrity and fault monitoring are a major
concerns for any technology considered for the life critical
application of air transport and air traffic control. The
integration of GPS with other technologies provides a higher degree
of fault detection capability, a potentially improved GPS
navigational performance, and the potential of limited navigation
support should a catastrophic GPS failure occur aboard the
vehicle.
[0804] The integration of GPS with an inertial system can be used
to improve the dynamic performance of the navigation solution.
Dynamic sensors may provide jerk, acceleration and velocity
information to aid in the navigation solution. Sole means inertial
navigation may be used in conjunction with GPS. The integration of
GPS with inertial systems usually require 12 (or higher) state
Kalman filter solutions techniques .
[0805] The concept of Receiver Autonomous Integrity Monitoring
(RAIM) is accepted as a potential integrity monitoring system. The
RAIM concept requires that the GPS receiver and/or navigation
system include the required "smarts" to diagnose its own health
using additional satellites, redundant hardware and specialized
internal software processing. RAIM standards are currently being
developed for industry approval.
[0806] When combined with other sensors such as WAAS, inertial,
baro altimeter and internal RAIM processing, GPS will have superior
accuracy, fault tolerance and fault detection capability.
Fault Tolerance and High Availability
[0807] Any system which controls life critical operations at an
airport must support fault tolerance and high availability. At the
same time, the system must be cost effective and support technology
insertion. High system availability may be achieved through a
custom design process utilizing selected and screened components
for high Mean Time Between Failure (MTBF). Alternatively, high
availability may be achieved through system redundancy using
components of non-custom, commercial-off-the-shel- f design. The
following paragraphs introduce a few of the concepts which are
later utilized in the system_design analysis.
[0808] AVAILABILITY: Availability is defined as the probability
that a system will operate to specification at any point in time,
when supported with a specific level of maintenance and spares.
[0809] MEAN TIME BETWEEN FAILURES (MTBF): The mean time a piece of
equipment will remain operational before it is expected to
fail.
[0810] RELIABILITY: The inherent probability that a piece of
equipment or hardware will remain operational for a period of time
(t). It is expressed as follows:
-(t/MBTF)
R(t)=e
[0811] TRAVEL TIME: The travel time is measured from the time of
failure to the time the repair technician and required spare parts
arrive at the failed equipment.
[0812] MEAN TIME TO RECONFIGURE (MTTC): The mean time a system is
inoperable as measured from the time of failure to the time of full
operation. Typically, reconfiguration time involves bringing on
line redundant systems in an effort to provide continued
service.
[0813] MEAN TIME TO REPAIR AND CERTIFY (MTTRC): The mean time of
the actual repair and recertification activities as measured from
the time of arrival of the failed equipment to the time which the
equipment is on line, certified and declared operational.
[0814] MEAN TIME TO REPAIR (MTTR): MTTR is the sum of
TRAVEL+MTTC+MTTRC.
Availability Example
[0815] The following analysis builds upon elements of the system
composed of off the shelf components arranged in a redundant
configuration. Commercial industrial single board computers are
connected with other commercial elements in the manner as shown in
the FIGS. 28, 29, 30. This approach provides cost effectiveness,
COTS technology insertion, declining COTS life cycle costs and high
availability. The analysis starts with no design redundancy FIG.
28, and ends describing a two controller station redundant
architecture FIG. 30.
[0816] This example will determine the overall reliability and
availability of the architecture shown in FIG. 28. The requirement
for system availability for this terminal area system comes from
the FAA Advanced Automation Program (AAS). The AAS program defines
the system yearly availability to be 0.99995 determined using a 2
hour travel time which is added to any other system down time. The
major elements of the airport system shown in FIG. 28.
29 KEY OPERATIONAL PARAMETERS AVALABILITY* AVAIL := 0.99995 TRAVEL
TIME (HRS)* TRAVEL := 2.0 *= FROM FAA ADVANCED AUTOMATION
SPECIFICATION TIME TO AUTO CONFIGURE (HRS) MTTC := .025 90 SECONDS
MEAN TIME TO REPAIR AND CERTIFY (HRS) MTTRC := .25 (TESTED SPARES,
FAULT ISOLATED TO LRU) MEAN TIME TO REPAIR (MTTR) MTTR := MTTRC +
MTTC + TRAVEL MTTR = 2.275 SPECIFIC COMPONENT PARAMETERS SINGLE
BOARD COMPUTER 142, 143 MEAN TIME BETWEEN FAILURES (HRS) SBC :=
90000 SBC RELIABILITY (RSBC) 56 RSBC := e - YR SBC RSBC = 0.907254
DIGITAL RADIO TRANSCEIVER 144 MEAN TIME BETWEEN FAILURES (HRS) XCVR
:= 75000 DIGITAL RADIO TRANSCEIVER RELIABILITY (RXMTR) 57 RXCVR :=
e - YR XCVR RXCVR = 0.889763 TOUCH SCREEN 145 MEAN TIME BETWEEN
FAILURES (HRS) TOUCH := 100000 TOUCH SCREEN RELIABILITY (RTOUCH) 58
RTOUCH := e - YR TOUCH RTOUCH = 0.916127 LOW VOLTAGE DC POWER
SUPPLY 146 MEAN TIME BETWEEN FAILURES (HRS) LVPS := 500000 LOW
VOLTAGE POWER SUPPLY RELIABILITY (RLVPS) 59 RLVPS := e - YR LVPS
RLVPS = 0.982633 FLAT SCREEN DISPLAY 147 MEAN TIME BETWEEN DIS :=
75000 FAILURES (HRS) FLAT SCREEN DISPLAY RELIABILITY (RDIS) 60 RDIS
:= e - YR DIS RDIS = 0.889763 AIRPORT LIGHTING UNIT 148 MEAN TIME
BETWEEN FAILURES (HRS) Interface only, no light bulbs or individual
light switches LITE := 250000 AIRPORT LIGHTING UNIT RELIABILITY
(RLITE) 61 RLITE := e - YR LITE RLITE = 0.965567 REDUNDANT ARRAY of
INEXPENSIVE DISKS (RAID 149 MTBF (HRS) RAID := 150000 RAID
RELIABILITY (RRALD) 62 RRAID := e - YR RAID RRAID = 0.943273 LOCAL
AREA NETWORK 150 MEAN TIME BETWEEN FAILURES (HRS) LAN := 87600
LOCAL AREA NETWORK RELIABILITY (RLAN) 63 RLAN := e - YR LAN RLAN =
0.904837 KEYBOARD 151 MEAN TIME BETWEEN FAILURES (HRS) KBD := 75000
KEYBOARD RELIABILITY (RKBD) 64 RKBD := e - YR KBD RKBD = 0.889763
DIFFERENTIAL BASE STATION 152 MEAN TIME BETWEEN FAILURES (HRS) DIFF
:= 100000 DIFFERENTIAL BASE STATION RELIABILITY (RDIFF) 65 RDIFF :=
e - YR DIFF RDIFF = 0.916127
[0817] This particular analysis is for a single controller station,
multiple stations could be used simply by duplicating the design
elements. The controller must have the following capabilities to
perform his airport duties:
[0818] 1. have full duplex voice and data communications
[0819] 2. a controlling AC&M display and graphic display
[0820] 3. a command touch screen capability or keyboard
[0821] 4. differential GPS for all navigation
[0822] 5. airport lighting interface (independent bulbs and
switches may fail without loss of function)
[0823] The minimal set of controller actions require the following
hardware and associated software to be operational.
[0824] 1. radio transceiver (voice and data function)
[0825] 2. AC&M display, SBC server, and RAID
[0826] 3. Graphic display, SBC,
[0827] 4. a low voltage power supply
[0828] 5. a command and control touch screen or a keyboard
[0829] 6. minimal configuration operational software
[0830] 7. a LAN assembly
[0831] 8. a differential GPS base station
[0832] 9. a airport lighting interface
[0833] The hardware elements can be connected in a minimal hardware
configuration and the overall availability can be compared to the
specified value of 0.99995
Initial Series Reliability
[0834]
RINT:=RSBC.sup.2.multidot.RXCVR.multidot.RTOUCH.multidot.RLVPS.mult-
idot.RDIS.sup.2.multidot.RRAID.multidot.RLAN.multidot.RDIFF.multidot.RLITE-
.multidot.RKBD
[0835] RINT=0.350629
[0836] The initial MTBF for the series string is determined below.
66 MTBFINT := - ( YR ) ln ( RINT ) MTBFINT = 8358.56594
[0837] Initial availability based upon series minimum configuration
is 67 MTBFINT MTBFINT + MTTR = 0.999728
[0838] As expected availability does not meet the specification,
system redundancy will be necessary to achieve the design goal. To
meet the required availability a system MTBF of about 45,000 hours
will be necessary with a 2.275 hour mean time to repair. A new
architecture is shown in FIG. 29.
Airport System, Single Redundant Controller Station
[0839] Redundant radio transceivers will be necessary since a
single point failure is unacceptable in this component. Parallel
radio transceiver reliability is determined below:
RXCVRP:=RXCVR+RXCVR-RXCVR.multidot.RXCVR.multidot.RXCVRP=0.987848
[0840] Redundant LVPS are required for the same reason.
RLVPSP RLVPS RLVPS (RLVPS.multidot.RLVPS) RLVPSP=0.999698
[0841] Redundant Local Area Networks are also required, since a
single point failure can not be tolerated in communications between
the AC&M SBC and Graphic SBC.
RLANP:=RLAN+RLAN-(RLAN.multidot.RLAN) RLANP=0.990944
[0842] Redundant Differential GPS are also required, since a_single
point failure can not be tolerated in airport navigation
functions.
RDIFFP:=RDIFF+RDIFF-(RDIFF.multidot.RDIFF) RDIFF=0.916127
[0843] Redundant airport lighting control interfaces are
required.
RLITEP:=RLITE RLITE (RLITE.multidot.RLITE) RLITEP=0.998814
[0844] The keyboard and the touch screen provide the same
capability, hence may be treated as a parallel redundant system
element. The keyboard/touch screen combination is found below:
RTOU.sub.--KBD:=RKBD+RTOUCH-(RKBD.multidot.RTOUCH)
RTOU.sub.--KBD=0.990754
[0845] An extra display surface will be added to display
information. This display capability will be used should a failure
occur in an AC&M display or in a graphic situation display. A 2
of 3 display scenario is used for successful mission completion.
Should a failure occur auto reconfiguration must occur within the
specified time allocation. To determine exactly what the 2 out of 3
display process represents, a probability analysis is performed.
The probability is determined from the series elements which make
up the display function. One display channel may fail while the two
others provide the necessary information. The third display is used
to provide non mission critical information when acting as a hot
spare.
Series Display Channel Elements
RSDIS:=RDIS.multidot.RSBC.multidot.RRAID.multidot.RSDIS=0.761448
[0846] In the 2 of 3 scenario the possible operating combinations
must add to one; meaning the probability of all of the possible
operating modes must add to 1. The operating combinations are
identified below:
[0847] 1. all 3 serial display channels are operational
[0848] 2. one channel is down and the other two are operational
[0849] 3. two channels are down and only one is operating
[0850] 4. all channels are down
[0851] Unreliability is Defined as:
Q:=1-RSDIS
[0852] The Probability is Defined Below:
RTOTAL:=RSDIS.sup.3+3.multidot.RSDIS.sup.2.multidot.Q+3.multidot.RSDIS.mul-
tidot.Q.sup.2+Q.sup.3
RTOTAL=1 All combinations do add to 1
[0853] Two of Three Operational Reliability is:
R2OF3:=RSDIS.sup.33.multidot.RSDIS.sup.2.multidot.Q+0+0
R2OF3=0.856429
[0854] Now the overall system reliability and availability
functions may be evaluated.
RFINAL:=R2OF3.multidot.RXCVRP.multidot.RLVPSP.multidot.RTOU.sub.--KBD.mult-
idot.RLANP.multidot.RDIFFP.multidot.RLITEP RFINAL=0.82354
[0855] 68 MTBFFIN := - ( YR ) ln ( RFINAL ) MTBFFIN = 45121.264957
FINALAV := MTBFFIN MTBFFIN + MTTR FINALAV = 0.99995
[0856] From a hardware perspective the system meets requirements.
The system software must be able to detect hard and soft failures
and must be able to fault isolate the failed device. Parallel
hardware redundancy and "smart" software provide the necessary
fault monitoring, fault containment and fault identification to the
LRU level. Operational software is tailored to the specific
application, but the hardware is based upon COTS standards to allow
for future technology insertion and cost effective replacement.
[0857] Multiple controller stations may be added to support larger
airport systems. In this case a slightly different architecture is
utilized. Common elements are shared by multiple stations. In the 2
station architecture shown parallel differential GPS base stations,
parallel lighting control interfaces, parallel Local Area Networks
and parallel transceivers are utilized. Since a redundant
capability is provided with multiple controller stations consisting
of 2 of 3scenario increased availability is provided as shown in
FIG. 30.
The Reliability of the Two Controller Station is Found Below
RSTAT:=R2OF3.multidot.RTOU.sub.--KBD.multidot.RLVPSP
RSTAT=0.848255
[0858] The Reliability of the Shared Elements Follows
REXT:=RLVPSP.multidot.RXCVRP.multidot.RDIFFP.multidot.RLITEP.multidot.RLAN-
P REXT=0.97057
[0859] Reliability of the Two Parallel 2 of 3 Controller Stations
is
RSTATP:=RSTAT+RSTAT-(RSTAT.multidot.RSTAT) RSTATP=0.976973
[0860] Reliability of the Two Controller Station Airport System
is
RTOT:=RSTATP.multidot.REXT RTOT=0.948222
[0861] System Total MTBF is 69 MTBF := - ( YR ) ln ( RTOT ) MTBF =
164763.651199
[0862] System Availability is 70 AVAIL := MTBF MTBF + MTTR AVAIL =
0.999986
[0863] Further availabilty improvements and cost reduction may be
realized when configured with multiple controller stations. The 2
of 3display channel operation may be reduced to 2 single display
channels and RAIDS may be eliminated while still meeting
availability goals when operating with multiple redundant
reconfigurable controller stations.
Airport Layout Plan
[0864] The U.S. FAA recommends the development of digitized Airport
Layout Plans (ALPs). In an ALP, the existing and proposed land and
facilities required in the operation and development of the airport
are provided in a scaled drawing. Each ALP should include the
following information: airport facilities--runways, taxiways,
ramps, service roads, navigation aids, and buildings
[0865] airspace matters--existing and planned approach/missed
approach/departure procedures, special use and controlled airspace,
control zones and traffic patterns
[0866] obstructions to air and ground navigation
[0867] airport topography
[0868] precise airport monumentation
[0869] If designed properly, the ALP should be suitable for use in
airport master plan activities, emergency work, maintenance,
navigation and ATC.
[0870] GPS Compatible Monumentation
[0871] Airport ALP generation or mapping activities may use any
number of map coordinate systems based on a number of earth datums
or ellipsoid references. Standardization of the mapping techniques
and references are key in the development of any successful
multi-use mapping program. In addition to the selection of a
standard reference system, the interface to the local area
surrounding the airport must be addressed. Accurate cross
referenced monumentation points are necessary to allow for a smooth
transition between the local coordinate system and the one used in
the airport maps or in the navigation system. In the U.S., local
State Plane Coordinate Systems (SPCS) form the baseline for most
local mapping activities. As such, the ALPs for all U.S. airports
should be monumented with reference points to provide for accurate
coordinate conversion between World Geodetic Survey of 1984 (WGS
84) Latitude--Longitude, Earth Centered Earth Fixed (ECEF) X, Y, Z
and local SPCSs or Universal Transverse Mercator (UTM). GPS and
conventional survey techniques are recommended for such
monumentation.
[0872] The surveyed accuracy of the multi-use airport map is
recommended to be better than 0.5 meters for the horizontal and 0.1
meter for elevation. Of particular interest are the Airport Runway
Touch Down Marker Reference Points (the precise coordinates of the
center of a runway's touch down marker) and the Airport Runway
Reference Points (the precise coordinates along the centerline path
of the runway). In addition, the precise locations of all turn outs
and turn ins should be identified in the airport map database.
[0873] Earth reference systems used in these locations should be
ECEF X,Y,Z, North American Datum of 1983 (NAD 83) or WGS 84
latitude, longitude, MSL. These three models are compatible with
GPS-based navigation. Should the positions not be in one of these
coordinate reference systems, then local airport multi-coordinate
reference monumentation should be used to support the required
coordinate conversions.
[0874] Airport map latitude, longitude projections should be based
upon the Transverse Mercator, Lambert Conformal Conic, or Hotine
Oblique Mercator These projections are used in state plane
coordinate systems. Additional information on reference systems and
projections is available in North American Datum of 1983 (NAD 83),
by Charles R. Schwartz.
[0875] The Manchester, N.H. (NH) airport map used in numerous test
activities was initially in NH State Plane Coordinate System feet.
This coordinate system was chosen for compatibility with existing
maps and because it represented distances in linear feet rather
than in degrees of latitude and longitude. The map was later
converted to NH state plane meters and ECEF X,Y,Z representations.
Manchester Airport was carefully surveyed and monumentation was
performed at multiple sites around the airport. The monumented
points were referenced to the ECEF Cartesian Coordinate System, NAD
83 Latitude, Longitude and Mean Sea Level (MSL), and the NH State
Plane. Coordinate conversions were performed using the monumented
points shown below.
30 MULTI-REFERENCE MONUMENTATION FLAGPOLE RUNWAY 35 END MONUMENT
SITE #1 MONUMENT SITE #2 NEW HAMPSHIRE STATE PLANE COORDINATES NH
SPCS X = 1045137.57 FT E NH SPCS X = 1048524.02 FT E NH SPCS Y =
158006.05 FT N NH SPCS Y = 154481.07 FT N NH ALT = 225.04 FT NH ALT
= 215.73 FT NH ALT = 68.59 M NH ALT = 65.75 M NAD83 LAT, LON, MSL
LAT83 = 42.933325800 N LAT83 = 42.923628275 N LON83 = 71.439298894
W LON83 = 71.426691202 W MSL = 225.04 FT MSL = 215.73 FT MSL ALT =
68.59 M MSL ALT = 65.75 M ECEF X, Y, Z COORDINATES ECEF X =
1488741.9 M ECEF X = 1489950.5 M ECEF Y = -4433764.7 M ECEF Y =
-4434130.5 M ECEF Z = 4322109.2 M ECEF Z = 4321318.4 M GEOID HT =
-28.24 M GEOID HT = -28.24 M WGS ALT = 40.35 M WGS ALT = 37.51
M
[0876] North American Datum of 1983
[0877] NAD 83 is a reference datum for the earth replacing the
North American Datum of 1927 (NAD 27). It was developed over many
years through international efforts of many people. It was the
largest single project ever undertaken by the National Geodetic
Survey (NGS), spanning 12 years.
[0878] The task involved 1,785,772 survey observations at 266,436
sites in North and Central America, Greenland and the Caribbean
Islands. The observations were made with all types of survey and
measurement equipment from satellites to tape measures. The
ultimate task was to develop an earth model which satisfied a set
of 1,785,722 simultaneous equations. The task was performed using a
least squares approach and Helmert blocking. The purpose was to
update NAD 27, calculate geoid heights at 193,241 control points
and the deflections of vertical at the control points.
[0879] The NAD 83 reference uses the Geodetic Reference System of
1980 (GRS 80) ellipsoid based on the Naval Surface Warfare Center
9Z-2 (NSWC 9Z-2) doppler measurements. The ellipsoid is positioned
to be geocentric and have cartesian coordinate orientation
consistent with the definition of Bureau International de l'Heure
(BIH) Terrestrial System of 1984.
[0880] NAD 83 data sheets contain information to update North
American 1927 references. The data sheets contain new information
which is relevant for precise surveys and users of GPS equipment.
These include: precise latitude and longitude [DDD MM SS.sssss],
latitude--longitude shift in seconds of degree from NAD 27 to NAD
83, elevation above the geoid with standard error, geoid height and
standard error, state plane and Universal Transverse Mercator (UTM)
coordinates. These fundamental corrections and ellipsoid constants
are the basic parameters used in many coordinate conversions and
navigational programs and form the basis of modem survey
measurements. GRS 80 used by NAD 83 has the following fundamental
parameters:
31 NAD 83 PARAMETERS PARAMETER VALUE UNITS Semimajor axis* 6378137
M Angular velocity* 7292115 .times. 10.sup.-11 RAD/SEC
Gravitational constant* 3986005 .times. 10.sup.8 M.sup.3/SEC.sup.2
Dynamic form factor 108263 .times. 10.sup.-8 unnormalized Semiminor
axis* 6356752.314 M Eccentricity squared 0.00669438002290
Flattening 0.00335281068118 Polar Radius of Curvature* 6399593.625
M (*Denotes values which are identical to WGS 84, underline denotes
differences between NAD 83 and WGS 84)
[0881] World Geodetic Survey of 1984
[0882] WGS 84 was developed by the U.S. Department of Defense. The
reference system started with the same initial BIH conventions as
NAD 83 but, over the development, some parameters changed slightly.
The geocentric ECEF system is based on a cartesian coordinate
system with its origin at the center of mass of the earth. The
system defines the X and Y axis to be in the plane of the equator
with the X axis anchored 0.554 arc seconds east of 0 longitude
meridian and the Y axis rotated 90 degrees east of the X axis. The
Z axis extends through the axis of rotation of the earth. The WGS
84 reference uses the GRS 80 ellipsoid as does NAD 83. WGS 84
includes slight changes to GRS 80 parameters which are identified
below:
32 WGS 84 PARAMETERS PARAMETER VALUE UNITS Semimajor axis* 6378137
M Angular velocity* 7292115 .times. 10.sup.-11 RAD/SEC
Gravitational constant* 3986005 .times. 10.sup.8 M.sup.3/SEC.sup.2
Dynamic form factor normalized -484.16685 .times. 10.sup.-6
Semiminor axis* 6356752.314 M Eccentricity squared 0.00669437999013
Flattening 0.00335281066474 Polar Radius of Curvature* 6399593.625
M (*Denotes values which are identical to NAD 83, underline
indicates where differences occur between NAD 83 and WGS 84)
[0883] Comparison of NAD 83 and WGS 84
[0884] The North American Datum of 1983 (NAD 83) and World Geodetic
Survey of 1984 (WGS 84) attempt to describe the surface of the
earth from two different perspectives. NAD 83 describes the surface
of North America using the Geodetic Reference System of 1980 (GRS
80) ellipsoid and over 1.7 million actual measurements. A least
squares Helmert blocking analysis was performed by National
Geodetic Survey (NGS) on these measurements to determine the best
fit solution to the actual measurements. NAD 83 uses monumented
reference points across the country to precisely reference various
coordinate systems such as the State Plane Coordinate Systems. WGS
84 incorporates positional references using GPS and local
references. Position determination by GPS incorporates precise
Keplerian orbital mechanics and radio positioning technology.
Clearly, the two systems are describing the same thing, but the
methods of determining a position are different.
[0885] Both NAD 83 and WGS 84 are based on BIH conventions. Though
both are based on the GRS 80 ellipsoid, small changes have occurred
between the two systems during their development. The basic
difference in the dynamic form factor was attributed to GRS 80
using the unnormalized form while WGS 84 used a normalized form and
rounded to eight significant figures. Since other parameters
derived from the dynamic form factor differences usually appear
after the eighth decimal place, most experts feel that the
computational differences are of no significance.
[0886] Computations to determine the latitude and longitude from
ECEF X,Y,Z coordinates highlight the small difference in the two
reference systems. It has been shown that the maximum error between
the two reference systems occurs at a latitude of 45 degrees.
(Refer to North American Datum of 1983, Charles R. Schwartz) No
error occurs between the two systems in the determination of
longitude. The maximum error amounts to 0.000003 seconds of arc
which amounts to a latitude shift of 0.0001 meters. For all
practical purposes, the computational differences between the two
systems are negligible. This is an important point for, if the two
earth models differed in basic latitude and longitude computations,
serious charting and navigational problems would occur and GPS
navigation based on NAD 83 referenced maps would be seriously
limited.
[0887] Both WGS 84 and NAD 83 have many common points used as local
reference points. The differences between the two systems may reach
several meters in rare locations, but on the average the systems
should be identical. Generally, measurement errors and equipment
inaccuracies introduce more error than the differences in the two
systems.
[0888] For airport mapping and GPS navigation we can assume that
errors due to the differences between the NAD 83 and WGS 84
ellipsoid models are negligible. This implies that either system
can be used in calculating navigational entities and performing
precise mapping with GPS navigation. The monumented New Hampshire
points established on NAD 83 near the airport are well within the
measurement accuracy of the GPS survey and navigation equipment.
The documented offsets between NAD 83 and WGS 84 for New Hampshire
are 0.0 meters in the Y direction and -0.5 meters in the X
direction.
Photogrammetry
[0889] Photogrammetry techniques incorporating ground reference
point(s) are recommended for creating electronic ALP's. Various
techniques may be employed to generate digital ALP's including
aerial photogrammetry and ground based moving platforms with
integrated video cameras and sensors. The collected image data may
be post processed to produce a highly accurate 2 or 3-D digital map
of the surrounding area.
[0890] A digital map of Manchester (NH) Airport was created to
support early test activities. The digital map was based on aerial
photogrammetry and GPS ground control using postprocessing
software. A Wild Heerbrugg aerial camera equipped with forward
motion compensation was used to capture the photogrammetry. The 3-D
digitalization was performed using a Zeiss stereoscopic digitizing
table. During the digitalization process, numerous object oriented
map layers were constructed to segregate various types of map
information. The resulting 3-D digital map had a relative
horizontal accuracy of better than 1.0 meter and a relative
vertical accuracy of better than 0.1 meter across the airport.
3-D Graphics Formats
[0891] Many digital map formats are in widespread use today.
Translators are available to convert from one computer format to
another. Maps may be in either raster format (such as those
generated by image scanning) or vector format (those developed on
CAD and digitizing equipment). The vector format provides a much
more robust environment for developers of ATC and map display
systems. Vector based drawings are represented by individual
vectors which can be controlled and modified individually or
collectively. This enables the developer to manage these entities
at a high level rather than at the individual pixel level. The
vectors may represent specific geographical features (entities) in
the map which may be assigned to a particular map layer in a
particular user defined color.
[0892] Since the map and ATC situation display are in a vector
format, a convenient method of graphically identifying and
manipulating information is available. The selection of a graphical
symbol on the screen through the use of a pointing device can be
used to access an entity-related database or initiate an
entity-based processing function. With raster-based images, there
is no simple way to segregate the various pieces of map or graphic
information for high level management.
[0893] Raster formats represent a series of individual pixels, each
pixel controlled as a function of a series of control bits.
Typically a series of three (3) words are used to describe the Red,
Green and Blue (RGB) intensity of each pixel. Each pixel of
information represents the smallest piece of the image and has no
information about the larger graphical entity that it is part of.
From a management perspective, this introduces additional
complications for even the simplest graphical manipulation tasks
such as suppressing the display of a series of raster based
topographical contour lines in the airport map.
[0894] A high level management capability is required for ALP
graphic entity control. The current raster-based maps do not
provide this functionality, hence additional processing is required
each time the map is displayed or modified. For raster-based maps
to provide this capability, the pixel elements must be functionally
organized in some manner to support the higher level management
functions described in this application. For this reason, raster
scan map formats are not recommended for ALPs at this time.
[0895] Vector formats may be in ASCII or binary and may be
constructed using different rules for their generation. The example
below uses the AutoCAD.TM. DXF standard drawing format. (AutoCAD is
a registered trademark of AUTODESK, Inc.) AutoCAD.TM. is one of the
most popular Computer Aided Design (CAD) software packages in the
world today and is typical of vector ALP formats. The DXF map
format may be easily converted to almost any CAD drawing
format.
33 AUTOCADTM DXF ALP FORMAT NEW HAMPSHIRE STATE PLANE ECEF X, Y, Z
FEET METERS 3DFACE 3DFACE 8 8 BUILDING BUILDING 10 10 1046289.75
1489279.59 20 20 154935.219 -4434265.78 30 30 256.499 4321428.53 11
11 1046289.75 1489277.26 21 21 154935.219 -4434258.83 31 31 223.7
4321421.72 12 12 1046245.375 1489258.04 22 22 155032.25 -4434243.98
32 32 223.7 4321443.43 13 13 1046245.375 1489260.37 23 23 155032.25
-4434250.92 33 33 256.499 4321450.24 0 0
[0896] The two formats shown above represent the vertical side of a
building which is, by AutoCAD.TM. convention, a 3-D face. Since the
two coordinate systems are different, one must appropriately set
the respective viewpoint for each display. This is accomplished in
the initial ALP DXF configuration declarations. In a similar
fashion, the drawing could be converted to other coordinate systems
such as Universal Transverse Mercator (UTM) using a DXF coordinate
conversion utility program such as TRALAINE.TM. (available from
Mentor Software, Thornton, Colo.
[0897] The above example represents just one of the thousands of
entities making up an ALP. Many commercial graphical libraries and
commercial CAD software products are available today for the
construction and use of ALPs and other 3-D graphic entities.
[0898] The use of modern digital Computer Aided Design (CAD)
techniques is required for the development of electronic map
databases. The use of GPS-based, ground referenced photogrammetry
with post processing 2 or 3-D digitalization provides a cost
effective, highly accurate and automated method of constructing the
2 or 3-D ALP.
[0899] An industry or international standard format for the
construction and interchange of digital graphical information
should be used. Numerous standards are established with readily
available software translators for conversions between the various
formats. Map file formats may be binary or ASCII characters.
3-D Object Oriented Map Layers
[0900] When stored in a digital format, the ALP should be arranged
in object oriented map layers. Proper layering of information
provides the capability to present only the information that is
needed for a particular purpose. For example, navigational maps
should not necessarily include all the digital layers of the ALP. A
simplified version of the map showing only runways, taxiways,
navigational references (landmarks) and gate areas should be used.
The use of specific layers of interest provides the following
advantages:
[0901] minimizes possible confusion in presenting too much
information to the pilot or controller
[0902] decreases reaction times of controller and pilot by only
presenting what is needed
[0903] reduces computer memory requirements
[0904] minimizes computer processing requirements
[0905] provides faster display updates (fewer pixels to redraw)
[0906] 3-D Digital Map Coordinate Systems
[0907] In order to integrate GPS navigational data with 2 or3-D
maps, the potential map formats must be evaluated for compatibility
and ease of use with the navigational output and coordinate
reference system. The table below lists twelve of the most likely
combinations.
34 COMBINATIONS OF MAPS, NAVIGATIONAL PARAMETERS AND MATHEMATICAL
COORDINATE REFERENCES MATHEMATICAL DIGITAL NAVIGATIONAL COORDINATE
# MAP FORMAT I/O FORMAT REFERENCE 1. LAT, LON, MSL LAT, LON, MSL
LAT, LON, MSL 2.* LAT, LON, MSL LAT, LON, MSL ECEF 3. LAT, LON, MSL
STATE ECEF PLANE/UTM 4. LAT, LON, MSL ECEF ECEF 5. STATE STATE
STATE PLANE/UTM PLANE/UTM PLANE/UTM 6. STATE LAT, LON, MSL LAT,
LON, MSL PLANE/UTM 7.* STATE LAT, LON, MSL ECEF PLANE/UTM 8. STATE
ECEF ECEF PLANE/UTM 9. ECEF ECEF ECEF 10.* ECEF LAT, LON, MSL ECEF
11. ECEF LAT, LON, MSL LAT, LON, MSL 12. ECEF STATE STATE PLANE/UTM
PLANE/UTM (UTM = Universal Transverse Mercator)
[0908] Other permutations are possible for the different
combinations of coordinate systems, map references and navigational
output formats. Other combinations can be "made to work", but based
on arithmetic precision, map availability and software complexity,
the combinations identified with an asterisk satisfy the evaluation
criteria most effectively. The table below presents a compliancy
matrix, where each of the twelve combinations are evaluated against
a set of criteria. The criteria used are described in greater
detail following the table.
35 COMPLIANCY MATRIX * * * MAPPING FORMAT: 1 2 3 4 5 6 7 8 9 10 11
12 EXISTING MAP DATA Y Y Y Y Y Y Y Y N N N N RECOGNIZABLE MAP Y Y Y
Y Y Y Y Y N N N N CONV. SW EXISTS Y Y Y Y Y Y Y Y Y Y Y Y EASY
3D-2D CONV Y Y Y Y Y Y Y Y N N N N MULTI-USE FORMAT Y Y Y Y Y Y Y Y
N N N N WORLD WIDE SYSTEM Y Y Y Y N N N N Y Y Y Y LINEAR SYSTEM N N
N N Y Y Y Y Y Y Y Y GPS COMPATIBLE Y Y Y Y N N N N Y Y Y Y SEAMLESS
SYSTEM N N N N N N N N Y Y Y Y NAV INPUT-OUTPUT: RECOGNIZABLE Y Y N
N N Y Y N N Y Y N ACCEPTED STANDARD Y Y N N N Y Y N N Y Y N WORLD
WIDE USE Y Y N Y N Y Y Y Y Y Y N GPS COMPATIBLE Y Y N Y N Y Y Y Y Y
Y N CHARTS AVAILABLE Y Y N N Y Y Y N N Y Y Y COORD REFERENCE:
RECOGNIZABLE REF. Y N N N Y Y N N N N Y Y WORLD WIDE USE Y Y Y Y N
Y Y Y Y Y Y N SIMPLE NAV. MATH. N Y Y Y Y N Y Y Y Y N Y NAD83 &
WGS84 REF Y Y Y Y Y Y Y Y Y Y Y Y SINGLE 3D ORIGIN N Y Y Y N N Y Y
Y Y N N LINEAR SYSTEM N Y Y Y Y N Y Y Y Y N Y UNITS OF DISTANCE N Y
Y Y Y N Y Y Y Y N Y * * * TOTAL YES COUNT: 15 18 13 15 12 14 17 14
13 16 13 11 MAPPING: CRITERIA DEFINITIONS COMPATIBILITY WITH
Existing digital map data is available for the airport EXISTING MAP
DATA and surrounding area. RECOGNIZABLE MAP A map which is
instantly recognizable, one which resembles the surface on which we
live. The map should not need to be differentially corrected from
the reference geoid. CONVERSION SW EXISTS Commercially available
software exists to convert from one 3-D map reference system to the
other EASY 3D-2D CONVERSION Digital map presentations can be easily
converted from 3-D to 2-D by setting the altitude to zero without
any additional mathematical conversions in the raw map data or in
the 3-D graphical interface. MULTI-USE FORMAT The map data is in a
standard format which can satisfy multi-use needs such as Master
Plans, construction needs, ATC and general navigation. WORLD WIDE
SYSTEM References in the map are with respect to world wide datums
and accepted world wide mapping units. LINEAR SYSTEM The axes and
units of the map are linear and represent distance. GPS COMPATIBLE
Mapping units and presentations are directly compatible with
existing GPS receiver output formats and calculation references.
SEAMLESS SYSTEM Maps do not have mathematical/physical
discontinuity, the map format must be seamless on a world wide
basis. For example UTM maps do not cover polar regions and map
edges do not match on 6 degree boundaries when placed together.
NAVIGATIONAL OUTPUT: RECOGNIZABLE The final navigational output
should be instantly recognizable; i.e. if LAT, LON, MSL output is
used, one can instantly visualize a location on the earth, while if
ECEF outputs are given it is difficult to visually picture a point
in space. ACCEPTED STANDARD Navigational format is an accepted
standard; i.e. LAT, LON, MSL WORLD WIDE USE The navigational format
is usable over the entire world. GPS COMPATIBLE Navigational format
is compatible with existing GPS receiver outputs. CHARTS AVAILABLE
Paper and digital charts are available. COORDINATE REFERENCE: WORLD
WIDE USE The coordinate reference system is recognized throughout
the world. SIMPLE NAVIGATION The coordinate system lends itself to
simple linear MATHEMATICS navigational mathematics. NAD83 AND WGS84
REF. The reference system is compatible with North American Datum
of 1983 and World Geodetic Survey of 1984. SINGLE ORIGIN The system
has one and only one origin. LINEAR SYSTEM The system is a linear
coordinate system. UNITS OF DISTANCE The coordinate system is based
on units of distance rather than angle. * Suggested combinations 2,
7, 10
[0909] To illustrate the differences between GPS trajectories
displayed in maps using different coordinate systems, the following
plot examples are provided. FIG. 12 shows a plan view of latitude
versus longitude. FIG. 14 shows the same trajectory in ECEF X and Y
coordinates. FIG. 13 depicts the MSL Altitude versus Time while
FIG. 15 shows the ECEF X values versus Time. Note the distortion
between the latitude, longitude, MSL altitude and the ECEF X,Y, and
Z coordinates. (The small rectangles on each plot represent
waypoints along the trajectory path.)
[0910] Plotting points in the map database requires that the
navigational computations provide output which is compatible with
the map database coordinates. Combination # 7 in the previous Table
includes a map database which is in a State Plane Coordinate System
and a navigational output in latitude, longitude and MSL.
Additional conversions are required to convert the navigational
data to state plane coordinates prior to plotting the points in the
map database. A more convenient map, navigational and coordinate
reference frame is required.
[0911] ALP Summary and Recommendations
[0912] Future airport maps or modifications to existing maps should
make every attempt to utilize recent technological advances in
their construction. The following items are guidelines for future
map development:
[0913] Precise, 3-D airport maps (ALPs) should be created and
maintained for all major and reliever airports.
[0914] ALPs should be constructed to satisfy multiple user
requirements.
[0915] Electronic graphical design tools should be used in ALP
construction. Computer Aided Design tools should be used wherever
possible.
[0916] Standard graphical formats (either ASCII character or
industry standard binary file formats) should be used.
[0917] The concept of electronic layers should be used to identify
and isolate entities in the map database.
[0918] Airport Reference Points (ARPs) should be located at
precisely monumented positions around the airport. ARPs should be
referenced to the coordinate systems of interest (such as
LAT,LON,MSL, ECEF X,Y,Z and the SPCS).
[0919] At least three (3) ARPs, located within the airport confines
in areas which are not likely to be disturbed, are recommended.
Where possible, these points should be placed in the far corners of
the airport to form a triangle. These points should be surveyed
with GPS based survey equipment and monumented physically on the
ground and within the digital map database.
[0920] ARPs should be recomputed as necessary to assure accuracy of
the navigation and ATC functions. Re-monumentation may be required
as a part of airport construction and expansion. Natural phenomena
such as plate tectonics, may force re-monumentation of the airport.
When ARP positions change more than 0.5 meters horizontally and 0.1
meters vertically, re-monumentation is recommended.
[0921] Areas used by aircraft such as runways, taxiways, gate areas
and ramps should be surveyed to a horizontal accuracy of 0.5 meters
horizontally and elevation to 0.1 meters.
[0922] The use of photogrammetry is suggested as an efficient means
of creating a digital database of an existing airport.
[0923] Earth reference systems used for the various map projections
should be the NAD 83 or WGS 84. Older, previously accepted datums
which do not correlate with GPS navigation or surveys should be
avoided.
[0924] ALPs should be compatible with cockpit instrumentation and
ATC databases.
[0925] GPS calibration areas should be located at all gates or
areas where aircraft remain stationary. These areas should be
identified in the airport digital map. The purpose of the
calibration area is to allow the pilot to check the accuracy of the
on board GPS equipment.
[0926] Cost effective and highly accurate mapping technology is
available to allow for the generation of multi-use maps which
should be compatible with a host of platforms and potential uses.
The exploitation of these common use maps will enhance master
planning, aviation and Air Traffic Control (ATC) capabilities. Maps
developed to national standards will provide a cost effective
navigational and ATC data base.
Summary, Ramification and Scope
[0927] The presented invention provides a valuable enhancement to
the current airport environment. This enhancement will result in
safer air travel and more efficient operation of our currently
capacity limited airports. Human blunders in the cockpit and in the
control tower have cost hundred of lives in the past. Seamless
airport air/ground operations will result in lower air traffic
controller and pilot workloads through the use of automation
processing. Advanced situational awareness displays showing travel
paths, and clearance compatible mirrored navigation automation
processing will reduce the likelihood of human blunders in the
control tower and in the cockpit resulting in a safer airport
environment. The elimination of out dated single function
navigation and surveillance systems will result in significant cost
savings for the airport authority and the FAA. The cost effective
nature of this GNSS based airport control and management system
will allow deployment at smaller airports resulting in safer
operations and better on time performance throughout the whole
aviation system.
[0928] It is obvious that minor changes may be made in the form and
construction of the invention without departing from the material
spirit thereof. It is not, however, desired to confine the
invention to the exact form herein shown and described, but is
desired to include all such a properly come within the scope
claimed.
* * * * *