[其它]英文论文翻译材料.doc

英文文献：aircraft communications addressing and reporting system aircraft communications addressing and reporting system (acars) is a digital datalink system for transmission of short, relatively simple messages between aircraft and ground stations via radio or satellite. the protocol, which was designed by arinc to replace their vhf voice service and deployed in 1978,1 uses telex formats. sita later augmented their worldwide ground data network by adding radio stations to provide acars service. over the next 20 years, acars will be superseded by the aeronautical telecommunications network (atn) protocol for air traffic control communications and by the internet protocol for airline communications.contents1. history of acars 1.1 introduction of acars systems1.2 oooi events1.3 flight management system interface1.4 maintenance data download1.5 interactive crew interface2. how it works 2.1 vhf subnetwork2.2 satcom and hf subnetworks2.3 datalink message types3. example transmissions 3.1 departure delay downlink3.2 weather report uplink3.3 fdams message downlink4. aircraft equipment5. datalink service provider6. ground end system7. arinc specifications8. acronyms and glossary9. gis and data discovery10. see also11. references12. external linkshistory of acars prior to the introduction of datalink, all communication between the aircraft (i.e., the flight crew) and personnel on the ground was performed using voice communication. this communication used either vhf or hf voice radios, which was further augmented with satcom in the early 1990s. in many cases, the voice-relayed information involves dedicated radio operators and digital messages sent to an airline teletype system or its successor systems.introduction of acars systems the engineering department at aeronautical radio, inc (arinc), in an effort to reduce crew workload and improve data integrity, introduced the acars system in july 1978. the first day operations saw about 4000 transactions. a few experimental acars systems were introduced earlier but acars did not start to get any widespread use by the major airlines until the 1980s. the original arinc development team was headed by crawford lane and included betty peck, a programmer, and ralf emory, an engineer. the terrestrial central site, a pair of honeywell level 6 minicomputers, (afeps) software was developed by subcontractor, eno compton of ecom, inc. although the term acars is often taken into context as the datalink avionics line-replaceable unit installed on the aircraft, the term actually refers to a complete air and ground system. the original meaning was arinc communications addressing and reporting system .later, the meaning was changed to airline communications, addressing and reporting system. on the aircraft, the acars system was made up of an avionics computer called an acars management unit (mu) and a control display unit (cdu). the mu was designed to send and receive digital messages from the ground using existing vhf radios. on the ground, the acars system was made up of a network of radio transceivers, managed by a central site computer called afeps (arinc front end processor system), which would receive (or transmit) the datalink messages, as well as route them to various airlines on the network. the initial acars systems were designed to the arinc standard 597. this system was later upgraded in the late 1980s to the arinc 724 characteristic. arinc 724 addressed aircraft installed with avionics supporting digital data bus interfaces. this was subsequently revised to arinc 724b, which was the primary characteristic used during the 1990s for all digital aircraft. with the introduction of the 724b specification, the acars mus were also coupled with industry standard protocols for operation with flight management system mcdus using the arinc 739 protocol, and printers using the arinc 740 protocol. the industry has defined a new arinc characteristic, called arinc 758, which is for cmu systems, the next generation of acars mus.oooi events one of the initial applications for acars was to automatically detect and report changes to the major flight phases (out of the gate, off the ground, on the ground, and into the gate); referred to in the industry, as oooi. these oooi events were determined by algorithms in the acars mus that used aircraft sensors (such as doors, parking brake and strut switch sensors) as inputs. at the start of each flight phase, the acars mu would transmit a digital message to the ground containing the flight phase, the time at which it occurred, and other related information such as fuel on board or origin and destination. these messages were primarily used to automate the payroll functions within an airline, where flight crews were paid different rates depending on the flight phase.flight management system interface in addition to detecting events on the aircraft and sending messages automatically to the ground, initial systems were expanded to support new interfaces with other on-board avionics. during the late 1980s and early 1990s, a datalink interface between the acars mus and flight management systems (fms) was introduced. this interface enabled flight plans and weather information to be sent from the ground to the acars mu, which would then be forwarded to the fms. this feature gave the airline the capability to update fmss while in flight, and allowed the flight crew to evaluate new weather conditions, or alternate flight plans.maintenance data download it was the introduction in the early 1990s of the interface between the fdams / acms systems and the acars mu that resulted in datalink gaining a wider acceptance by airlines. the fdams / acms systems which analyze engine, aircraft, and operational performance conditions, were now able to provide performance data to the airlines on the ground in real time using the acars network. this reduced the need for airline personnel to go to the aircraft to off-load the data from these systems. these systems were capable of identifying abnormal flight conditions and automatically sending real-time messages to an airline. detailed engine reports could also be transmitted to the ground via acars. the airlines used these reports to automate engine trending activities. this capability enabled airlines to better monitor their engine performance and identify and plan repair and maintenance activities. in addition to the fms and fdams interfaces, the industry started to upgrade the on-board maintenance computers in the 1990s to support the transmission of maintenance related information real-time through acars. this enabled airline maintenance personnel to receive real-time data associated with maintenance faults on the aircraft. when coupled with the fdams data, airline maintenance personnel could now start planning repair and maintenance activities while the aircraft was still in flight.interactive crew interface all of the processing described above is performed automatically by the acars mu and the associated other avionics systems, with no action performed by the flight crew. as part of the growth of the acars functionality, the acars mus also interfaced directly with a control display unit (cdu), located in the cockpit. this cdu, often referred to as an mcdu or midu, provides the flight crew with the ability to send and receive messages similar to todays email. to facilitate this communication, the airlines in partnership with their acars vendor, would define mcdu screens that could be presented to the flight crew and enable them to perform specific functions. this feature provided the flight crew flexibility in the types of information requested from the ground, and the types of reports sent to the ground. as an example, the flight crew could pull up an mcdu screen that allowed them to send to the ground a request for various weather information. upon entering in the desired locations for the weather information and the type of weather information desired, the acars would then transmit the message to the ground. in response to this request message, ground computers would send the requested weather information back to the acars mu, which would be displayed and/or printed. airlines began adding new messages to support new applications (weather, winds, clearances, connecting flights, etc.) and acars systems became customized to support airline unique applications, and unique ground computer requirements. this results in each airline having their own unique acars application operating on their aircraft. some airlines have more than 75 mcdu screens for their flight crews, where other airlines may have only a dozen different screens. in addition, since each airlines ground computers were different, the contents and formats of the messages sent by an acars mu were different for each airline. in the wake of the crash of air france flight 447, there has been discussion about making the acars into an online-black-box.2 if such a system were in place, it would avoid the loss of data due to: (1) black-box destruction, and (2) inability to locate the black-box following loss of the aircraft. however the cost of this, due to the high bandwidth requirements, would be excessive and there have been very few incidents where the black boxes were not recoverable.how it works a person or a system on board may create a message and send it via acars to a system or user on the ground, and vice versa. messages may be sent either automatically or manually.vhf subnetwork a network of vhf ground radio stations ensure that aircraft can communicate with ground end systems in real-time from practically anywhere in the world. vhf communication is line-of-sight, and provides communication with ground-based transceivers (often referred to as remote ground stations or rgss). the typical range is dependent on altitude, with a 200-mile transmission range common at high altitudes. thus vhf communication is only applicable over landmasses which have a vhf ground network installed.a typical acars vhf transmission.modeaaircraftb-18722acknakblock id2flightci5118labelb9msg no.l05amessage/klax.ti2/024klaxa91a1satcom and hf subnetworks satcom provides worldwide coverage, with the exception of operation at the high latitudes (such as needed for flights over the poles). hf datalink is a relatively new network whose installation began in 1995 and was completed in 2001. hf datalink is responsible for new polar routes. aircraft with hf datalink can fly polar routes and maintain communication with ground based systems (atc centers and airline operation centers). arinc is the only service provider for hf datalink.datalink message typesacars messages may be of three types: air traffic control (atc) aeronautical operational control (aoc) airline administrative control (aac) atc messages are used to communicate between the aircraft and air traffic control. these messages are defined in arinc standard 623. atc messages are used by aircraft crew to request clearances, and by ground controllers to provide those clearances. aoc and aac messages are used to communicate between the aircraft and its base. these messages are either standardized according arinc standard 633 or defined by the users, but must then meet at least the guidelines of arinc standard 618. various types of messages are possible, and these include fuel consumption, engine performance data, aircraft position, as well as free text data.example of transmissions: departure delay downlink a pilot may want to inform his flight operations department that departure has been delayed by air traffic control (atc). the pilot would first bring up a cmu mcdu screen that allows him to enter the expected time of the delay and the reason for the delay. after entering the information on the mcdu, the pilot would then press a “send” key on the mcdu. the cmu would detect the send key being pushed, and would then generate a digital message containing the delay information. this message may include such information as aircraft registration number, the origination and destination airport codes, the current eta before the delay and the current expected delay time. the cmu would then send the message to one of the existing radios (hf, satcom or vhf, with the selection of the radio based on special logic contained within the cmu). for a message to be sent over the vhf network, the radio would transmit the vhf signals containing the delay message. this message is then received by a vhf remote ground station (rgs). the majority of acars messages are typically only 100 to 200 characters in length. such messages are made up of a one-block transmission from (or to) the aircraft. one acars block is constrained to be no more than 220 characters within the body of the message. for downlink messages which are longer than 220 characters, the acars unit will split the message into multiple blocks, transmitting each block to the rgs (there is a constraint that no message may be made up of more than 16 blocks). for these multi-block messages, the rgs collects each block until the complete message is received before processing and routing the message. the acars also contains protocols to support retry of failed messages or retransmission of messages when changing service providers. once the rgs receives the complete message, the rgs forwards the message to the datalink service providers (dsp) main computer system. the dsp ground network uses landlines to link the rgs to the dsp. the dsp uses information contained in their routing table to forward the message to the airlines or other destinations. this table is maintained by the dsp and identifies each aircraft (by tail number), and the types of messages that it can process. (each airline must tell its service provider(s) what messages and message labels their acars systems will send, and for each message, where they want the service provider to route the message. the service provider then updates their routing tables from this information.) each type of message sent by the cmu has a specific message label, which is contained in the header information of the message. using the label contained in the message, the dsp looks up the message and forwards to the airlines computer system. the message is then processed by the airlines computer system. this processing performed by an airline may include reformatting the message, populating databases for later analysis, as well as forwarding the message to other departments, such as flight operations, maintenance, engineering, finance or other organizations within an airline. in the example of a delay message, the message may be routed via the airlines network to both their operations department as well as to a facility at the aircrafts destination notifying them of a potential late arrival. the transmission time from when the flight crew presses the send key to send the message, to the time that it is processed within an airlines computer system varies, but is generally on the order of 6 to 15 seconds. the messages that are sent to the ground from the cmu are referred to as a downlink message.example of uplink: weather report for a message to be transmitted to the aircraft (referred to as an uplink message), the process is nearly a mirror image of how a downlink is sent from the aircraft. for example, in response to an acars downlink message requesting weather information, a weather report is constructed by the airlines computer system. the message contains the aircraft registration number in the header of the message, with the body of the message containing the actual weather information. this message is sent to the dsps main computer system. the dsp transmits the message over their ground network to a vhf remote ground station in the vicinity of the aircraft. the remote ground station broadcasts the message over the vhf. the on-board vhf radio receives the vhf signal and passes the message to the cmu (with the internal modem transforming the signal into a digital message). the cmu validates the aircraft registration number, and processes the message. the processing performed on the uplink message by the cmu depends on the specific airline requirements. in general, an uplink is either forwarded to another avionics computer, such as an fms or fdams, or is processed by the cmu. for messages (such as a weather report uplink) destined for the cmu, the flight crew can go to a specific mcdu screen which contains a list of all of the received uplink messages. the flight crew can then select the weather message, and have the message viewed on the mcdu. the acars unit may also print the message on the cockpit printer (either automatically upon receiving the message or upon flight crew pressing a print prompt on the mcdu screen).example of downlink: fdams messagemessages are sent to the ground from other on-board systems in a similar manner as the delay message example discussed previously. as an example, an fdams system may have a series of algorithms active to monitor engine exceedance conditions during flight (such as checking engine vibration or oil temperature exceeding normal operating conditions). the fdams system, upon detecting such an event, automatically creates an engine exceedance condition message, with applicable data contained within the body of the message. the message is forwarded to the cmu, using what is referred to as arinc 619 data protocols. the cmu would then transmit the message to the ground. in this case, the service provider routing table for an engine exceedance message is typically defined to have the message routed directly to an airlines maintenance department. this enables airline maintenance pers