Wireless spread spectrum ground link-based aircraft data communication system for engine event reporting

Abstract

The system and method of the present invention provides a record of the performance of an aircraft engine. A plurality of sensors sense engine conditions and generate engine data. A ground data link unit is positioned within the aircraft and receives the engine data and stores the engine data within an archival data store. A wideband spread spectrum transmitter that can be part of a transceiver downloads the engine data to a ground based spread spectrum receiver that can be part of a transceiver, and receives the wideband spread spectrum communication signal from the aircraft. It demodulates the wideband spread spectrum communication signal to obtain the engine data.

Description

This application is a

Δf=125 kHz

Solving the equation for Δf produces a result of 125 kHz for a symbol rate of 1 Msps (there are 2 bits/symbol for DQPSK). Solving this same equation for a symbol rate of 355 ksps (1 bit/symbol for DBPSK) produces a result of 44 kHz as shown:
Δf/355 ksps=45°/360°

Δf=44 kHz

The Doppler frequency shift at 2465 MHZ that results from a B737-700 flying at its maximum airspeed of 530 miles/hour with respect to a fixed ground station is approximately 2 kHz. The frequency offset due to Doppler is defined by the following equation:
Δf_d=(v/c)*f_c

• • where v=relative velocity,
    v=(530 mi/hr)(1.61×10³ m/mi)(1 hr/60 min)(1 min/60 sec)=237 m/s
  • where c=speed of light=3×10⁸ m/s
  • and where f_c=2465 MHz
    Δf=(237 m/s)/(3×10⁸ m/s)*2465 MHz=1.95 KHz

The total frequency uncertainty of two transceivers, each mounted on an aircraft flying at maximum speed in opposite directions is as follows:
Δf=(Δf_o+Δf_d+Δf_o+Δf_d)

Δf=(12 kHz+2 kHz+12 kHz kHz+2 kHz)=28 kHz

The resulting 28 kHz of total frequency uncertainty is well within the previously defined limit of 44 kHz for a 355 kbps symbol rate. Therefore, the Doppler shift due to aircraft in flight has a negligible effect on system bit error rate.

The atmospheric absorption loss for a 2.4 GHz ISM Band due to water and oxygen molecule resonance is about 0.0115 dB/mile. This figure of merit is the basis for “other miscellaneous link losses” used to calculate the communication range in the previous section. During heavy rain, the propagation loss for the 2.4 GHz ISM Band increases to nearly 0.5 dB/mile. Weather is usually not a concern for terrestrial applications, because practical distances are normally constrained by multipath interference to less than a mile. For airborne applications, however, where signal fading due to multipath is relatively nonexistent and communication range approaches that of free space, this loss needs to be accounted for in the overall link budget analysis.

The communication range for a GDL air-to-ground link in heavy rain is 11.5 miles (60,650 feet), as shown by the analysis below:

To calculate Receive Power, Pr:
Pr = Pt(dBm) = Gr(dBi) + Gt(dBi) + Lambda{circumflex over ( )}2/(4sd){circumflex over ( )}2(dB) + Lo
Where	dBi = dB's referenced to isotropic gain
	Pt = Transmit power in dBm	Enter Pt:	30.00
	Gt = Transmit antenna gain in dBi	Enter Gt:	0.00
	Gr = Receive antenna gain in dBi	Enter Gr:	5.15
	Lambda (wavelength) = 300/fc in	Enter fc:	2,462.00
	MHZ
	d = Distance in feet	Enter d:	60,650.00
	Lo = Other misc link losses in dB	Enter Lo:	(5.74)
	Pr = Receive power in dBm	Answer Pr:	(96.20)
To calculate Path Loss, Ls:
Ls = Pr(dBm) − Pt(dBm) − Gt(dBi) − Gr(dBi)
Where	Ls = Path Loss in dB	Answer Ls:	(131.35)
To calculate Receive Sensitivity, G/T°:
G/T° = Gr(dBi) − Ts(dB)
Where	F = Receive Noise Figure in dB	Enter F:	7.01
	Tr = Effective Rx noise temp, ° K.	Answer Tr:	1,166.79
	Tr = Effective Rx noise temp,	Answer Tr:	30.67
	(dB-K)
	Tl = Link noise temp, ° K.	Enter Tl:	100.00
	Tp = Antenna physical temp, ° C.	Enter Tp:	43.33
	Ta = Antenna noise temp, ° K.	Answer Ta:	144.49
	Ts = System noise temp, ° K.	Answer Ts:	1,311.29
	Ts = System noise temp, (dB-K)	Answer Ts:	31.18
	G/T° = RX Sensitivity, Gr/Ts in	Answer G/T°:	(26.03)
	dB-K
To calculate No and Pr/No:
No = kT° (dBm/Hz)
Where	K = Boltzmann's Constant (1.38*10{circumflex over ( )}-23)
	T° = Ts in degrees Kelvin
	No = kT° in dBm/Hz	Answer No:	(167.42)
Pr/No = Pr(dBm) − No(dBm)
Where	Pr/No = Received Pr/No in	Answer Pr/No:	71.22
	(dB-Hz)
To calculate Received Eb/No:
Eb/No = Pr/No(dB-Hz) − R(db-bps) + Lo(dB)
Where	R = Data bit rate in kHz	Enter R:	354.84
	Lo = Implementation Loss in dB	Enter Lo:	(5.22)
	Eb/No is in dBs	Answer Eb/No:	10.50
To calculate Link Margin, M:
Where	M = Received Eb/No(dB) − Required Eb/No(dB)
	Required Eb/No in dB, based on	Enter Eb/No:	10.50
	demod
	M = Margin in dB	Answer M:	(0.00)

With the present invention, it is possible to accommodate a greater number of planes at an airport. At a typical airport, an aircraft may spend 20 minutes at a gate. For example, at one aircraft station with 27 gates, the station can accommodate a peak influx of one aircraft every 45 seconds. A higher influx rate would result in more aircraft on the ground than the 27 gates could accommodate.

With the extended range GDL system of the present invention, it is possible to accommodate a higher influx rate, up to one aircraft every 30 seconds. This analysis clearly illustrates that the GDL system of the present invention provides sufficient bandwidth to accommodate the needs of different airlines. Furthermore, the GDL system of the present invention can be easily expanded to provide twice the capacity by increasing the number of frequency channels used, if necessary.

Table VI shows the departure metrics for an example of 12 busy stations. Based on the assumption that a given aircraft's destination is truly random, the table shows that the probability of having one of these 12 stations as a destination is 54%. The table also shows the probabilities of hitting one of these 12 stations within one to eight trips. The probability of landing at one of these 12 stations within eight flight legs is 99.8%. Given that the average number of flight legs per day is 8.7, then a given aircraft would encounter a GDL equipped airport at least once a day.

TABLE VI
Equipping an Airline's Busiest Stations Results in at Least One GDL Stop Per Day
	Airport	Number	Maintenance	Intermediate	Weekly	GDL	GDL
SWA Stations	Code	of Gates	Operations	Stations	Departures	Priority	Departures
Phoenix	PHX	27	X		1122	1	1122
Las Vegas	LAS	12		X	957	2	957
Houston	IAH	11	X		939	3	939
Dallas	DAL	13	X		909	4	909
Los Angeles	LAX	9			785	5	785
Oakland	OAK	11		X	738	6	738
Chicago Midway	MDW	19	X		690	7	690
St. Louis	STL	8		X	593	8	593
San Diego	SAN	7			527	9	527
San Jose	SJC	6			464	10	464
Baltimore	BWI	6		X	422	11	422
Nashville	BNA	5		X	409	12	409
Total Departures:					15784		8555
	Probability of hitting a GDL Equipped Station in one trip	54.20%
	Probability of hitting a GDL Equipped Station once in 2 trips	79.02%
	Probability of hitting a GDL Equipped Station once in 3 trips	90.39%
	Probability of hitting a GDL Equipped Station once in 4 trips	95.60%
	Probability of hitting a GDL Equipped Station once in 5 trips	97.98%
	Probability of hitting a GDL Equipped Station once in 6 trips	99.08%
	Probability of hitting a GDL Equipped Station once in 7 trips	99.58%
	Probability of hitting a GDL Equipped Station once in 8 trips	99.81%

The 30 second metric for the amount of time it takes to accomplish all file transfers to and from an aircraft once it reaches the ground at one of the proposed 12 GDL equipped stations is based on the following assumptions. Six of the 12 GDL equipped stations have more than 10 gates and six have fewer than 10 gates. The analysis assumes that the once monthly flight deck computer and FMC uploads take place at one of the six GDL equipped stations having fewer than 10 gates. All other routine file transfers are assumed to take place at any of the 12 GDL equipped stations. The supporting analysis is shown in the following Table VII for the airports with more than 10 gates, and Table VIII for the airports with fewer than 10 gates.

TABLE VII
Required Access to GDL Network per Aircraft at GDL
Equipped Stations with More than 10 Gates
				Air vs.
Description	Direction	Size (kB)	When	Gnd
FDC Updates	Upload	10,000	Current	Gnd
FMC Uploads	Upload	1,000	Current	Gnd
Electronic Maintenance	Download	870	Future	Gnd
Logbook
FOQA/Engine Trend	Download	3,390	Current	Gnd
Data
OOOI Time Reports	Download	1	Current	Gnd
Weight & Balance	Upload	10	Future	Gnd
Reports
Flight Release	Upload	10	Future	Gnd
Cabin Maintenance Log	Download	20	Future	Gnd
Graphical Weather	Upload	130	Future	Gnd
Total		4,431
	Time in minutes @ 1.2 Mbps	0.49 29,54202 seconds
	Min rq'd RF Link Data Rate in Mbps	1.33
	Assumptions
	Compression Ration	2.00
	RF Link Overhead	0.67
	Flight/Day Round	8.7
	(2300/264,1)
	Flt-Hrs/Day/Aircraft	11.571
	(8.7 * 1.33)
	Avg Flight Time (hrs)	1.33
	Time Between GDL Stops (days)	1
	No of Gates at Hub/Station	27
	Avg time on Ground at Gate (mins)	20
	Peak Landing Rate (sec)	44.4444444
	Engine Trend Data	586
	(kB/Flt-hr)
	FDC, FMC Updates not included at stations with >10 gates

TABLE VIII
Required Access to GDL Network per Aircraft at GDL
Equipped Stations with Less than 10 Gates
				Air vs.
Description	Direction	Size (kB)	When	Gnd
FDC Updates	Upload	10,000	Current	Gnd
FMC Uploads	Upload	1,000	Current	Gnd
Electronic Maintenance	Download	870	Future	Gnd
Logbook
FOQA/Engine Trend	Download	3,390	Current	Gnd
Data
OOOI Time Reports	Download	1	Current	Gnd
Weight & Balance Reports	Upload	10	Future	Gnd
Flight Release	Upload	10	Future	Gnd
Cabin Maintenance Log	Download	20	Future	Gnd
Graphical Weather	Upload	130	Future	Gnd
Total		15,431
	Time in minutes @ 1.2 Mbps	1.71
	Min rq'd RF Link Data Rate in Mbps	1.55
	Assumptions
	Compression Ration	2.00
	RF Link Overhead	0.67
	Flight/Day Round	8.7
	(2300/264,1)
	Flt-Hrs/Day/Aircraft	11.571
	(8.7 * 1.33)
	Avg Flight Time (hrs)	1.33
	Time Between GDL Stops (days)	1
	No of Gates at Hub/Station	9
	Avg time on Ground at Gate (mins)	20
	Peak Landing Rate (sec)	133.333333
	Engine Trend Data	586
	(kB/Flt-hr)
	FDC, FMC Updates not included at stations with <10 gates

Table IX shows one basis for estimating the size of the combined FOQA/Engine Trend Data Files. The number of 12 bit words and some sample rates are based on the B757-200 FOQA files that are currently downloaded for one known airline. In this example, these files are approximately 345,600 bytes in size per flight hour. The contained parameters are sampled once every second, once every two seconds, once every four seconds, and once every 64 seconds. The file size increases from previous files because some parameters are sampled as often as four times/seconds for 15 minutes of every one hour flight. Some parameters are sampled as often as once per second instead of one every two or four seconds for the duration of the flight.

TABLE IX
Basis for Estimating FOQA/Engine Trend Data File Size
Estimated FOQA/Engine Trend Data File Size
	Number of		Flight		Flight
Parameter	12 Bit	Sample	Duration	Sample	Duration	File
Type	Words	Rate (Hz)	(mins)	Rate (Hz)	(mins)	Size
Miscellaneous,	32	0.015625	15	0.015625	45	2700
Noncritical
Startup, Take-	20	4	15	1	45	189000
off, Shutdown
Flight Duration	20	1	15	1	45	108000
Critical
Miscellaneous,	53	1	15	1	45	286200
Critical
TOTAL	125				Uncompressed	585900

FIG. 9 illustrates one possible airline network architecture in one embodiment of the present invention. The entire network is based on the ubiquitous, Internet standard TCP/IP protocols. A future TCP/IP to TP4/CLNP gateway is shown for compatibility with the current industry baseline for ATC networking. For purposes of clarity, reference numerals describing this aspect of the present invention will being in the 500 series.

FIG. 9 illustrates this efficient system showing the aircraft system by dashed line indicated at 500, a GDL airport terminal indicated by dashed line at 502, and the dispatch, flight operations indicated by dashed line at 504. These three units connect into the public switched telephone network and airline wide area network 506, which includes representative pubic switches. The aircraft system includes a GDL unit 510 positioned on an aircraft that connects via a data connection 512 to the GDL airport terminal 502 with a bridge 514 and a gateway 516 to Sun SPARC computer terminal 518 as a representative processor. The GDL airborne unit also connects to an Ethernet backbone 520 that can connect via a wireless link 522 to a flight deck computer 524, an ASCII printer as part of a flight deck printer 526, and a cabin PC 528. The GDL airborne unit 510 can also connect to the FDAM/DFDAU/DMU 530 and a cabin telecommunications unit (CTU), i.e., telephone switch, 532 outside the system. The telephone switch can connect voice and data through a part 22.801 air-ground radio telephone or other cellular service to an air-ground radio tower 534 and a radio net 538 through an Iridium or other satellite service provider 538. Voice only communication can be established via a VHF comm transceiver 540 through the airline's private radio network. At the dispatch flight operations 504, dispatch telephone 542 can connect through the airline's PBX/PABX 548 to router and gateway 544, 546 as known to those skilled in the art. These components connect to various terminals 550, which could include IBM or Sun SPARC work stations as known to those skilled in the art. Additionally, for engine event reporting, data relating to engine events can be reported directly to an engine trending area having a gateway 554 and Sun workstations 556.

As noted above, the ground data link network of the present invention can use standard TCP/IP network protocols along with Ethernet data link protocols to provide computer communications among the GDL networked host. The TCP/IP protocol incorporates Internet networking, allowing host peer-to-peer connectivity. The GDL network implements this technology into a private network as illustrated in FIG. 9 for GDL host communications. The example of the merging of an airline network and GDL network is now described with reference once again to FIG. 9.

The GDL Wide Area Network (WAN) hardware architecture could include multiple airport terminal local area networks (LANs) and a single Airline Operational Control Center (AOCC) LAN. Components within each LAN include multiple host nodes (such as the illustrated Sun workstations, PCs, wireless access nodes) and a network gateway. Each LAN could provide a 10 or 100 megabit Ethernet connection to implement the data link protocol, as is well known to those skilled in the art. Each host attachment to the LAN could be accomplished via an Ethernet based network interface card (NIC). Each LAN could include an ISDN gateway attachment for inter-LAN communication, providing 64 kbit to 256 kbit data transmissions.

Each GDL network host would typically have Commercial Off The Shelf (COTS) software installed providing network connectivity control. This would include Ethernet drivers for the NICs and a TCP/IP network kernel implementing transport and Internet TCP/IP network layer protocols. Each host includes TCP/IP application protocols to implement common network operations. In addition, various TCP/IP network sever applications could be installed on Sun workstations to support typical networking operations (ex. FTP, Email, NFS).

The GDL network could be pre-configured as a private TCP/IP network. Each LAN in the network could be identified as a subnet domain and assigned a unique subnet identified IP address. Each network component attached to a subnet could be assigned a unique IP address for that particular domain. This would be a static IP address assignment and would not be altered after installation. A domain name server would not be employed on the GDL network, and therefore, each host would contain internal IP address information of other GDL host for network connectivity. Each networked host would be an identification table containing available host names matched with assigned IP addresses. The host network applications would use either an IP address or host name to identify and communication with another host on the network.

The GDL IP address is a 32-bit “class A” IP address, and is used for private network operation (10.0.0.0 domain). In this described embodiment, this IP address format consists of four fields: class, network identifier, subnet identifier, and host identifier. Table X describes the GDL IP address format using the TCP/IP standard with subnetting for the GDL network.

TABLE X
Class A-IP Address Format
		Network	SubNet	Host
	Class	ID	ID	ID
0	1	7	8	15	16	31
	Fieldname	Bit Position	Purpose
	Class	0	Class A IP format
	Network ID	1-7	Private Network ID
	SubNet ID	8-15	Subnet ID
	Host ID	16-31	Individual host ID

In order to integrate the GDL and another computer network, an organized plan for the resultant network architecture is developed. Typically, an airline network uses TCP/IP network protocol over an Ethernet data link backbone. Naturally, there may be areas of incompatibility that would have to be resolved for this integration effort. The GDL network architecture has the flexibility for modifications to conform with other TCP/IP based networks. When the integration effort is complete, the revised representative airline and GDL network would be viewed as a single operational computer network, rather than two distinct inter-connected networks.

Some airline networks are formed as a private WAN network utilizing TCP/IP for the network protocol along with a 10 megabit Ethernet to support the network data link. Because both airline and GDL networks incorporate Ethernet to provide the data link network functionality, this networking area should be compatible. Cabling for the GDL network typically uses 10Base-T for physical connectivity requirements, however, it is adaptable to other existing Ethernet cabling standards.

For inter-networking activities, GDL utilizes ISDN gateways to provide network connectivity. However, GDL is not limited to ISDN and can incorporate other exiting gateway components utilized by the representative airline.

Since both the airline and GDL network hosts, include a TCP/IP network kernel and Ethernet drivers, the basic network software control for each network component should be in place. In addition, any server functionality to be shared between the networks needs examination to ensure proper operation. Also there may be a merging of some software process currently used on both networks into a single network application (e.g., Email server). This requires verification of the associated network operation within the integrated network structure.

Each host on the airline and GDL network employs a TCP/IP network kernel to implement networking activities. However, the capability of the network configuration between these two systems requires additional consideration. The TCP/IP standard requires a unique 32-bit IP address assignment to identify each individual network host.

The format of the GDL IP address is configured to incorporate subnet addressing. This addressing scheme provides a three-level hierarchy of identification: network, subnet and host identification. This subnetting implementation allows for multiple network domains within the GDL global network structure. Each GDL airport terminal system is assigned a particular subnet domain and all network hosts within that domain are assigned IP addresses using the subnet identification. Integration of the airline network and GDL network will require a review of the IP address format used within each network. Assuming the airline network utilizes network domains and there exist available IP addresses, the GDL network would adapt the airline address format.

For host network identification, each host on the GDL network has been pre-assigned a unique IP address. This is a static address and will not change following installation. However, should the airline network require the use of a dynamic IP address assignment (e.g., dynamic host configuration protocol), the present GDL network component IP address allocation scheme can be reconfigured to obtain its IP address from the airline IP address allocation network server.

To connect to a computer on the GDL network, each GDL host has an internal table, containing IP addresses and associated computer names, and listing all other available hosts on the network. Whenever a computer name is selected for connection, the address table is utilized to determine the associated host IP address. However, should the airline employ a domain name structure and utilize a Domain Name Server (DNS) for IP address lookup, the GDL host can be reconfigued to make use of such a server to supply host addresses for network connectivity.

There are also two fundamental issues to be ddressed when implementing a representative airline network architecture, which are a departure from traditional networks. The first is how to address the mobile aircraft LANs that roam from subnet to subnet. The second is, given multiple network connection options and associated costs, how to route files via the most economical path, while taking into consideration message priorities. The solution to the latter issue is illustrated in the flow chart shown in FIG. 10.

The cost based routing algorithm shown in FIG. 10 is implemented in the GDL airborne segment, for files originating onboard the aircraft and in the system controller located at the airline operational control center, for files originating from the ground network.

As shown in the flow chart in FIG. 10, when the IP datagram is received (Block 600), a determination is made whether the GDL path is available (Block 602). If it is , then the datagram is sent via the ground data link unit (Block 604). If it is not available, then a determination is made whether the file transfer has priority (Block 606). If that determination is high, it is sent via the ATG phone (Block 608). If it is not, then a file transfer is delayed until a ground data link path is available (Block 610).

The proposed method for addressing the mobile aircraft LANs is an extension of the method GDL currently addresses the issue. When an aircraft lands at a GDL equipped airport, an IP address is dynamically assigned to it by a DHCP sever application hosted on the sun SPARC server shown in the GDL airport terminal equipment rack in FIG. 9. Each GDL equipped airport is a different subnet on the WAN. The temporary DHCP IP address is, in effect, an alias that the GDL airborne segment uses to transfer files over the TCP/IP based network. A system controller (SC) at an airline operational control center recognizes the GDL airborne segment by its tray number, which is a hard coded series of pins at an ARINC 600 connector interface. The system controller maintains a database relationship between tray numbers and aircraft tail numbers.

The GDL airborne segment is an end node or “client” on the network. It can also be a router for other clients on the aircraft LAN. To address this difference, it is possible to use a mobile IP, which is an extension to IP, and a recent Internet standard specified in RFC 2002. A mobile IP consists of three components: mobile nodes, foreign agents and a home agent. A system controller at an airline operational control center is the home agent.

The GDL airborne segment (AS) acts as a foreign agent for the other mobile nodes connected to it on the aircraft LAN, as well as its own foreign agent. When the AS comes up, it attempts to register with a GDL wireless router. If it is successful, it recognizes that it has proximal access to a GDL equipped airport and requests a temporary IP address from the DHCP server. It then registers this “care of” address with the home agent, i.e., the SC, and acts as its own foreign agent. It then sends out a “foreign” broadcast message to the other aircraft clients, and acts as their foreign agent as well. When the AS leaves the GDL equipped airport and can no longer receive a probe signal, it dials up the SC via the ATG phone system, informs the home agent of its presence on the home network, and defaults to its home network fixed IP address. Once the AS registers its home IP with the home agent, unless it has high priority files to transfer, it terminates the call to avoid usage fees. If the AS is on its home network, IP addressing and datagram delivery to and from the AS, work as they would without mobile IP. A possible mobile IP approach is illustrated in FIGS. 11A and 11B.

As shown clearly in FIG. 11A, the mobile node (OPC) 700 communicates with the mobile node/foreign agent 702 of the ground data link airborne system (AS). This in turn can communication with the ATC phone system 704. The system controller 706 acts as a home agent. FIG. 11B illustrates an example of the GDL airborne system acting as its own foreign agent on a foreign subnet and a foreign agent for other mobile nodes. Instead of an ATG phone system radio tower, an airport terminal equipment rack 708. Steps are similar as in those steps of FIG. 11A except between the mobile node/foreign agent 702 and the airport terminal equipment rack 708 acting as a PHX station.

From the perspective of the aircraft LAN mobile nodes, they are typically on a foreign subnet and use the mobile IP provided to them from the AS acting as a foreign agent. The AS sends out a “foreign” broadcast message to the other aircraft mobile nodes and its current IP, depending on whether its connection options are the ATG phone system or GDL, respectively. If the GDL connection option is available, then the AS sends out its temporary DHCP IP address, or “foreign” address, which the aircraft LAN mobile nodes register with the home agent as their “care of” address. If the GDL connection option is not available, then the AS sends out its fixed IP address, or “home” address, which the aircraft LAN mobile nodes register with the home agent as their “care of” address.

Once the mobile nodes have registered with the home agent, all IP traffic addressed to them is received by the home agent, encapsulated in another IP datagram, and then “tunneled” to the foreign agent. The foreign agent forwards the datagrams to their respective mobile nodes. In the reverse direction, the mobile nodes can bypass the home agent and send diagrams directly to their destination.

Table XI provides an example of how the GDL system controller will keep track of available data communication options so that ground originating network traffic can be routed to the aircraft in the most cost effective manner possible. The table shows that the system controller identifies the phone number associated with each individual aircraft and either its static, or “home” IP address, or its temporary DHCP “foreign” IP address. The process described in the preceding paragraphs guarantees that the lowest cost routing option is used for high priority messages, since the AS always registers its temporary DHCP “foreign” IP address if it has proximal access to a GDL equipped airport. For low priority file transfers, the AS and SC store the files until the GDL connection option is available.

TABLE XI
Dynamic Messaging Address Table
Tail	Tray	Static Phone	AS Static	AS Dynamic
Number	Number	Number	“Home” IP	“Foreign” IP
N631	xxxxxx	xxx.xxx.xxxx	xx.x.xxx.xx	xx.x.xxx.xx
N632	xxxxxx	xxx.xxx.xxxx	xx.x.xxx.xx	xx.x.xxx.xx

The following list describes the process steps that result in updating the dynamic IP address of a GDL accessible aircraft:

1. N631 lands at a GDL equipped station.

2. N631 registers with the network and is assigned a dynamic IP address.

3. N631 registers its temporary “foreign” IP and its tray number (xxxxxx) with the home agent, i.e., SC.

4. SC maintains the dynamic massaging address table.

5. SC uses the temporary “foreign” IP, when available, for all file transfers.

6. N631 leaves the GDL equipped station and can no longer receive the ABS probe.

7. N631 registers its “home” IP address with the home agent, i.e., SC.

8. SC replaces the temporary “foreign” IP with the “home” IP.

9. ABS returns surrendered IP address to DHCP pool.

10. SC always knows what data massaging connection options are available.

11. SC utilizes dynamic IP for all low priority and in-range high priority massaging.

12. SC utilizes static IP for high priority massaging when aircraft is not GDL accessible.

13. SC utilizes ubiquities TCP/IP protocol stack for all file transfers, independent of connection method.

It is also possible to use the ground data link unit of the present invention to automatically distribute various updates of flight management computer navigation database files for the air transport industry. These updated files can have customized performance factors on a per aircraft basis.

As known, the air transport industry is required by the International Civic Aviation Organization (ICAO) to update its navigation database files every 28 days. As a result, air carriers typically purchase these files from a company like Jeppesen, a leader in the navigation data services industry. Jeppesen offers a NavData Direct Update Service which converts the navigation database from the standard ARINC 424 specified format to an airline's vendor specific avionics system. Using computer software developed by the avionics manufacturer and licensed to Jeppesen, ARINC 424 data is formatted into customized updates that can then be loaded directly into the airline's specific navigation equipment. A common media used to transfer this information is the IBM PC compatible 3.5″ high density floppy disk.

Airlines receive, copy and disseminate navigation database files to every aircraft in their fleet every 28 days. A programmable data loader device is used to copy the files from the floppy disk to the aircraft's flight management computer (FMC) 160 (FIG. 15). Typically each aircraft contains one or two FMCs and either one or two interface connectors located in the flight deck. When the FMC is reprogrammed with a new navigation database, customized performance factors such as drag factor and fuel flow are reset to the default values contained on the navigation database media. If the performance factors for a given aircraft should be different than the default values, then these aircraft specific performance factors are recorded before the new navigation database is loaded. Once the new navigation database is loaded, these default performance factors must then be manually reprogrammed back to their original value.

The programmable data loader receives its power from the FMC database loader interface connector. Once the programmable data loader powers up and passes its internal self test, status is displayed indicating that the unit is ready for operation and the floppy is inserted into the disk drive. The file transfer begins automatically. Status is displayed on the programmable data loader that indicates whether or not the data transfer is in progress or complete. If the files reside on more than one floppy, a disk change status is indicated to alert the user to swap disks. If the data transfer fails, power is cycled to reset the data loader and the process starts over.

Following the navigation database update, a series of manual process steps are followed to verify that the FMC was programmed correctly. Because the FMC is designated as “flight critical,” it is important to verity that it has been programmed correctly. The IDENT page on the CDU is checked to verity that the new NAV DATA has been loaded. The type of aircraft and the type of engines are verified to reflect the correct aircraft configuration. The OP PROGRAM part number and the NAV DATA part number are verified against the proper part numbers obtained from the airline's technical operation's department. Today's date is verified to be within the validity start and end dates of the navigation database that was loaded. If the default performance factors are used, then the drag factor and fuel flow factors are also verified to be correct.

Once the first FMC is programmed, the process is either repeated for the second FMC using the data loader, or the files are copied from the first FMC to the second FMC, depending on the aircraft and the availability of a second interface connector. Once both FMCs have been programmed with the new navigation database, any custom performance factors that need to be changed from their default values are manually reprogrammed. One of the functions of the FMC is to provide an energy management function to optimize flight performance based on cost, time, fuel or range. The energy management function is tailored to an individual airline's operation economics, local fuel costs and the constraints of the air traffic environment. Performance factors tend to be grouped as a function of every airframe/engine combination. Drag factor, fuel flow, maneuver margin, approach speeds, optimum altitude, maximum altitude, minimum cruise time, minimum rate of change of climb, and minimum rate of change of cruise, are examples of performance factors that may be customized to a value that is different from the default values. These performance factors are manually programmed via the control/display unit (CDU) and are stored in the FMC's non-volatile memory. These performance factors are typically changed in both FMCs at the same time, following the navigation database update.

These performance factors can be considered as falling into two categories: static and dynamic. Drag factor is an example of a static performance factor that does not change from month to month unless the aircraft is physically modified. Cost index is an example of a dynamic performance factor that can change on a per flight basis. If the flight is late in departing and the airline wishes to make up time, the cost index can be set to a lower value. This permits the aircraft to fly at a lower than optimum cruise altitude and change altitude as a faster rate. This is less fuel efficient and therefore increases operating cost. If the flight is on schedule, the cost index can be set to a higher value. This constrains the aircraft to change altitude at a slower rate and fly at a higher, more fuel efficient cruise altitude. This reduces operating cost.

The logistics involved in planning, tracking and accomplishing the task of updating each aircraft's flight management computer every 28 days is a formidable task. Most airlines have a great deal of diversity in their aircraft fleet, in terms of airframe manufacturers, e.g., Boeing, McDonnell Douglas, Lockheed, Airbus, etc., families, e.g., B737, B757, B767, models, e.g., B757-300, B737-500, B737-700, etc. This translates to dozens of airframe/engine combinations in hundreds of aircraft that are spread over thousands of miles and are constantly in motion and subject to highly dynamic scheduling changes. Sufficient copies of required floppy disks are obtained and deployed along with programmable loader devices so that these new uploads can take place monthly at numerous sites within minimum disruption to airline operations. The air transport industry's entire process of disseminating, programming, verifying and customizing the navigation database is essentially a manual operation.

To further complicate the process, the FMC is not the only avionics equipment that requires periodic software updates. Dozens of other equipment require periodic updates and the list is growing in newer production aircraft. Just getting the right disks to the right aircraft at the right time requires significant effort and resources.

Generic airframe/engine based navigation database files can be customized on a tail number unique basis. New navigation database files for each airframe/engine combination in an airlines, fleet are obtained every 28 days from a service such as Jeppesen's NavData Direct Update Service. In a preferred embodiment, these files are obtained directly from a secure Jeppesen web site via an Internet connection over the Public Switched Telephone Network (PSTN). A variety of security features are implemented to authenticate the source files and ensure the integrity of the file transfer process. These files are downloaded to a directory on the GDL system controller. The performance factors for each aircraft in the airlines' fleet is maintained in a database resident on the GDL system controller on a per tail number basis. This database is accessed by a software application which customizes the Jeppesen provided navigation database files based on the unique performance factors for each aircraft. This software application creates a unique set of navigation database files for each tail number in the fleet inventory.

The present invention also provides a system for automatically delivering new navigation database files to the aircraft. These tail number unique navigation databases files are disseminated via the PSTN to aircraft specific directories resident on airport base station servers contained within airport terminal equipment racks installed at GDL-equipped airports.

When aircraft land at GDL-equipped airports, the GDL airborne segment installed on each aircraft connects to the airport base station server via a wireless LAN connection. The GDL airborne segment moves the new navigation database files from the tail number unique directory on the airport base station server to a directory resident within the GDL airborne segment.

The present invention also provides a method for reprogramming the FMC with the new navigation database files. Once the new navigation database files have been retrieved, the FMC is reprogrammed via the programmable data loader interface. The GDL airborne segment is wired in parallel to the programmable data loader interface connector located in the flight deck. When power is removed from the GDL airborne unit, a high impedance is presented to the FMC interface in order to preserve the existing method for reprogramming the FMC using a programmable data loader. This GDL airborne unit interface design is such that the GDL airborne unit is only electrically connected to the FMC when the GDL airborne unit has received new navigation database files, the aircraft is on the ground, and the GDL airborne unit is powered on. When these conditions are met, the GDL airborne unit reprograms the FMC with the new tail number unique navigation database files. The GDL airborne unit interface is also designed so that failures cannot affect FMC performance.

This invention automates the following rocess steps:

1. Customizing the default performance factors in advance for each individual aircraft.

2. Delivering the new navigation database files to the aircraft.

3. Programming the FMC with the new navigation database files.

The fourth step is verifying that the FMC was programmed correctly. In a sense, this step is accomplished automatically via the file transfer protocol and acknowledgement process defined in the ARINC 603 or ARINC 615 airborne computer data loader specification. Based on the flight critical nature of the FMC, the inventors do not imply that this step completely eliminates the need to manually verify that the FMC was programmed correctly once the new navigation database has been loaded.

This application is related to copending patent application entitled, “WIRELESS-BASED AIRCRAFT DATA COMMUNICATION SYSTEM WITH AUTOMATIC FREQUENCY CONTROL,” “WIRELESS SPREAD SPECTRUM GROUND LINK-BASED AIRCRAFT DATA COMMUNICATION SYSTEM WITH VARIABLE DATA RATE,” “WIRELESS SPREAD SPECTRUM GROUND LINK-BASED AIRCRAFT DATA COMMUNICATION SYSTEM WITH APPROACH DATA MASSAGING DOWNLOAD,” “WIRELESS SPREAD SPECTRUM GROUND LINK-BASED AIRCRAFT DATA COMMUNICATION SYSTEM WITH AIRBORNE AIRLINE PACKET COMMUNICATIONS,” and “WIRELESS SPREAD SPECTRUM GROUND LINK-BASED AIRCRAFT DATA COMMUNICATION SYSTEM FOR UPDATING FLIGHT MANAGEMENT FILES,” which are filed on the same date and by the same assignee, the disclosures which are hereby incorporated by reference.

Many modifications and other embodiments of the invention will come to the mind of one skilled in the art having the benefit of the teachings presented in the foregoing description and the associated drawings. Therefore, it is to be understood that the invention is not to be limited to the specific embodiments disclosed, and that the modifications and embodiments are intended to be included within the scope of the dependent claims.

Claims

1. A system for providing a record of the performance of an aircraft engine comprising:

a plurality of sensors positioned on the aircraft for continuously sensing engine conditions during an entire flight of the aircraft from at least take-off to landing and generating engine data relating to the continuously sensed operation of the engine during an entire flight of the aircraft from at least take-off to landing;

a ground data link unit positioned within the aircraft and operatively connected to said plurality of sensors for receiving said engine data, said ground data link unit comprising:

a) a an archival data store operative to accumulate and continuously store the engine data during the entire flight of the aircraft from at least take-off to landing to create an archival store of such engine data, and

b) a wideband spread spectrum transceiver coupled to said data store, and comprising a transmitter that is operative to download said engine data that has been accumulated and stored by said archival data store during the entire flight of the aircraft from at least take-off to landing over a wideband spread spectrum communication signal after the aircraft completes its flight and land at an airport; and

a ground based spread spectrum transceiver for receiving the wideband spread spectrum communication signal from the aircraft and demodulating the wideband spread spectrum communication signal to obtain the accumulated engine data representative of the performance of the engine during an entire flight of the aircraft from take-off to landing.

2. A system according to claim 1, wherein said aircraft includes a FADEC engine control system, wherein said sensors are operatively connected to said FADEC engine control system.

3. A system according to claim 1, wherein said sensors are positioned to sense at least one of said core compartment bleeding, sump pressurization, sump vent, active clearance control, and low pressure and high pressure recoup.

4. A system according to claim 1, wherein said sensors are positioned to sense at least one of oil pressure, oil temperature, fuel flow and engine hydraulics.

5. A system according to claim 1, and further comprising a plurality of sensors loaded throughout the aircraft for sensing routine aircraft conditions and generating parametric data such as received by a flight data recorder representative of aircraft flight performance during a flight of said aircraft.

6. A system according to claim 5, and further comprising a multiplexer connected to said plurality of sensors and ground data link unit for receiving the parametric data and multiplexing the parametric-data for delivery to said ground data link unit.

7. A system according to claim 1, and further comprising a ground based sever connected to said ground based spread spectrum receiver for receiving said engine data for further processing of said engine data.

8. A system according to claim 1, and further comprising a remote flight operations center operatively coupled to said ground based spread spectrum transceiver for receiving and processing engine data downloaded from said aircraft.

9. A system according to claim 1, wherein the wideband spread spectrum communication signal comprises a direct sequence spread spectrum signal.

10. A system according to claim 1, wherein the wideband spread spectrum communication signal comprises a frequency hopping spread spectrum signal.

11. A system according to claim 1, wherein said data store comprises an archival data store.

12. A system according to claim 1, wherein said ground data link unit is operative to store flight performance data and downloaded said flight performance data over side wideband spread spectrum communication signal.

13. A method of providing a record of the performance of an aircraft engine comprising:

continuously sensing engine conditions during an entire flight of the aircraft from at least take-off to landing and generating engine data relating to the continuously sensed operation of the engine during an entire flight of the aircraft from at least take-off to landing;

collecting accumulating and continuously storing engine data within a ground an archival data store of a ground data link unit during at least initial take-off of an aircraft from an airport and during an entire flight of the aircraft from at least take-off to landing to create an archival store of such engine data;

processing the engine data within a central processing unit of the ground data link unit to determine engine problems;

upon initial take-off, downloading the engine data that has been collected during initial take-off accumulated and continuously stored within said archival data store during an entire flight of the aircraft from at least take-off to landing over a wideband spread spectrum communication signal to a ground based spread spectrum receiver; and

demodulating within the ground based spread spectrum receiver the wideband spread spectrum communication signal to obtain the engine data representative of the operation of the engine during an entire flight of the aircraft from take-off to landing for further processing.

14. A method according to claim 13, and further comprising the step of forwarding the engine data to a ground based server connected to the ground based spread spectrum receiver and processing the engine data within the ground based server.

15. A method according to claim 13, wherein the wideband spread spectrum communication signal comprises a direct sequence spread spectrum signal.

16. A method according to claim 13, wherein the wideband spread spectrum communication signal comprises frequency hopping spread spectrum signal.

17. A method of providing a record of the performance of an aircraft engine comprising:

continuously sensing engine conditions during an entire flight of the aircraft from at least take-off to landing and generating engine data relating to the continuously sensed operation of the engine during an entire flight of the aircraft from at least take-off to landing;

collecting accumulating and continuously storing engine data within an archival data store of a ground data link unit during engine operation during an entire flight of the aircraft from at least take-off to landing to create an archival store of such continuously monitored engine data;

downloading the engine data that has been collected accumulated and stored within the archival data store during the entire flight of the aircraft from at least take-off to landing over a wideband spread spectrum communication signal to a ground based spread spectrum receiver after the aircraft completes its flight and lands at an airport; and

demodulating within the ground based spread spectrum receiver the wideband spread spectrum communications signal to obtain the engine data representative of the operation of the engine during an entire flight of the aircraft from take-off to landing for further processing.

18. A method according to claim 17, and further comprising the step of collecting engine data within an archival data store of the ground data link unit.

19. A method according to claim 17, and further comprising the step of collecting engine data during at least initial take-off of the aircraft.

20. A method according to claim 19, and further comprising the step of downloading the engine data upon initial take-off.

21. A method according of claim 17, wherein the wideband spread spectrum communication signal comprises a direct sequence spread spectrum communication signal.

22. A method according to claim 17, wherein the wideband spread spectrum communication signal comprises a frequency hopping spread spectrum communication signal.

23. A method according to claim 17, wherein the ground based spread spectrum receiver comprises a transceiver.

24. A method of providing a record of the performance of an aircraft engine comprising:

continuously sensing engine conditions during an entire flight of the aircraft from at least take-off to landing and generating engine data relating to the continuously sensed operation of the engine during an entire flight of the aircraft from at least take-off to landing;

accumulating and continuously storing the engine data within an archival data store of a ground data link unit during the entire flight of the aircraft from at least take-off to landing to create an archival store of such continuously monitored engine data;

downloading the engine data that has been accumulated and stored during the entire flight of the aircraft from at least take-off to landing over a wideband spread spectrum communications signal to a ground based spread spectrum receiver after the aircraft completes its flight and land at an airport; and

demodulating within the ground based spread spectrum receiver the wideband spectrum communications signal to obtain the engine data representative of the operation of the engine during an entire flight of the aircraft from take-off to landing for further processing.

25. A method according to claim 24, and further comprising the step of collecting the engine data from a FADEC engine control system.

26. A method according to claim 24, and further comprising the step of downloading the engine data upon initial take-off.

27. A method according to claim 24, wherein the wideband spread spectrum communications signal comprises a direct sequence spread spectrum communications signal.

28. A method according to claim 24, wherein the wideband spread spectrum communications signal comprises a frequency hopping spread spectrum communications signal.

29. A method according to claim 24, wherein the ground based spread spectrum receiver comprises a transceiver.

30. A method according to claim 24, and further comprising the step of continuously collecting the engine data from a plurality of sensors positioned on the aircraft that sense engine conditions and continuously generate engine data relating to operation of the engine.

31. A method of providing data of the performance of an aircraft engine comprising:

continuously monitoring the performance of the aircraft engine during at least two entire flights of the aircraft from at least take-off to landing;

generating engine data representative of the continuously monitored aircraft engine during the at least two entire flights of the aircraft from at least take-off to landing;

accumulating and continuously storing the continuously generated engine data within a ground data link unit positioned within the aircraft during the at least two entire flights of the aircraft from at least take-off to landing to create an archival store of such continuously monitored engine data;

after the aircraft completes its at least two flights and lands at an airport, transmitting the accumulated, stored generated engine data from the ground data link unit over a wideband spread spectrum communications signal to a ground based spread spectrum receiver; and

demodulating the received spread spectrum communications signal to obtain the accumulated engine data representative of the performance of the aircraft engine during the at least two entire flights of the aircraft from take-off to landing.

32. A method according to claim 31, and further comprising the step of transmitting the accumulated generated engine data from the ground data link unit to a cellular infrastructure that includes the ground based spread spectrum receiver.

33. A method according to claim 31, and further comprising the step of transmitting the accumulated generated aircraft data over a frequency hopping spread spectrum communications signal.

34. A method according to claim 31, and further comprising the step of transmitting the accumulated generated engine data over a direct sequence spread spectrum communications signal.

35. A method according to claim 31, and further comprising the step of transmitting the generated engine data automatically after the aircraft has landed.

36. A method according to claim 31, and further comprising the step of uploading data to the ground data link unit over a wideband spread spectrum communications signal after the aircraft has landed.

37. A method according to claim 31, and further comprising the step of selecting a frequency channel for transmitting the accumulated generated engine data from a plurality of available frequency channels.

38. A method according to claim 37, and further comprising the step of selecting a frequency channel based on communication limitations of a governing jurisdiction in which the ground based spread spectrum receiver is located.

39. A method according to claim 31, and further comprising the step of transmitting the accumulated generated engine data from the ground based spread spectrum transceiver to a flight operations center for further processing.

40. A method according to claim 31, and further comprising the step of storing the generated engine data within a memory of the ground data link unit.