TRANSITIONAL USE OF ARINC SPECIFICATION 622 (1994)

COMMENTS ON DRAFT REPORT ON ATNP/1 AGENDA ITEM 2:

"COMMUNICATION ASPECTS OF INTERFACING APPLICATIONS TO THE ATN (E.G...TRANSITIONAL USE OF ARINC SPECIFICATION 622",
14 JUNE 1994.

2.1.2 The lack of an identified body responsible for development of operational requirement definition for ground/ground applications should be addressed somewhere within ICAO.  Economic pressures may drive early implementation of regional capabilities that must be consistant for use by all users.  The current implementation of ATIS in four areas resulted in four different protocols. 

2.2.1.2     These conclusions are very debatable.  The overriding consideration in determining a transition path is to start with as little change as possible.  Then incrementally modify the system in consideration of cost/benefit to provide more capability.  Rely on actual performance rather than predictions to assess system capability.  Recognise the importance of new learnings gained by taking a methodic development cycle, rather than leaping forward only to realize that other directions were more cost effective. 

The motivating factor is to get airplanes from point A to point B in an efficient manner while also providing the airplane operators choice in type of airplane, equipment equippage, operational profile, and schedule.  These motivating factors will stimulate taking best advantage of whatever system capabilities are provided and also provide a basis for comparison when making cost/benefit analysis. 

There are really two fundamental areas to be developed; the applications developed for use by the flight crew and air traffic control and the end to end air/ground communications services required to SUPPORT the applications.  The applications should be the overriding consideration and the communications services development decisions should be based on cost/benefit analysis with respect to improvements in the utilization of the applications. 

2.2.2.2     The essence of the problem is stated here.  How can you most easily implement bit oriented applications?

2.2.2.3     It is important to recognize the inherent capability in place today.  Beyond the physical memory capability available in a management unit to support enhanced communications protocols, there is further consideration of the development of essential level airplane functions along with adequate flight managment functions and crew interface and alerting capability.  The operators will invest in new equipment when it makes sense.  Only a very few visionary operators will spend the money based only on promises.  There must be a tangible benefit.  Early investment in the airborne applications, not the communications service will surely reap more benefit in the early stages.

Based on the B747-400 FANS-1 development program, it appears that with minor modification of the ACARS management units, installation of Data 2 SATCOM, use of existing INMARSAT ground earth stations, development of an ARINC 622 application within the service providers, commitment to support inter-networking between service providers, and the existing ground ground services available today, we can support any application.  There will be some unforeseen changes, not everything will be perfect from the start, but there is no inherhent limitation either, other than transport performance. 

It is important to recognize that the inherent transport performance is not greatly influenced by communications protocols.  It is greatly influenced by the available RF spectrum and power available.  In fact, it is arguable that the unique ACARS protocols developed today are in fact quite efficient in comparison to true OSI protocols, given the low available bandwidth in air ground communications.

2.2.2.4     There are two fundamental applications being developed, CPDLC and ADS.  Given the existing use of HF in remote areas, a reliable means of two way communication for routine communications can actually result in a reduction in seperation.  The addition of a surveillance capability along with a backup voice communications capability will provide additional reductions in seperation.  The use of satellite communications will support all of these application requirements. 

ARINC 622 implementation does support the most cost effective transition to early application of bit oriented applications.

2.2.2.6     The use of ARINC 622 in a domestic airspace is easily mis-understood.  Airplanes flying in cruise over barren land masses with no terrestrial communications and with no radar services surely will benefit from the use of satellite data communications.  ARINC 622 is the most cost effective approach to early use of satellite data communications.  If terrestrial communications are available, such as VHF service, than the use of voice can be utilized, although this does not stimulate the use of automation, only data communications will enable true automation.  In any case, the choice of medium and protocol must be made in light of performance requirements determined by the applications.  Aircraft seperation is a major factor in determining performance requirements.  Terminal applications would have the most demanding requirements, and enroute the least demanding.  The choice of protocol would have much less influence in comparison to RF air ground performance.

2.2.3.2.1.1 The investment in ground and airborne software is considerable.  Changes to working software must be considered very carefully, given the historically finicky nature it's development takes.  Early investment in applications will reap the earliest benefits.  It is the burden of each software development to account for eventual change.  The simplest development is made with a mature system.  The use of an existing communications network will enable the earliest development of operational applications.  However, these applications should be developed in a structured manner to allow for eventual changes in protocol.

2.2.3.2.1.3 It is accepted that the use of ACARS and ARINC 622 will not provide everything that ultimately might be available with the ATN and OSI.  However, these differences can be accounted for in developing applications.

2.2.3.2.2.1 Message integrity requirements are determined by the certificating agencies.  For essential level communications, to prevent hazerdously misleading data from being presented, the use of at least a 16 bit end to end CRC will be required.

2.2.3.2.2.2 The air ground communications system developed for ACARS does support recovery mechanisms.  A message received with bad BCS will be ignored.  A message not acknowledged is considered.  For air to ground messages, the lack of acknowledgement will result in the message being retained for delivery whenever possible.  For ground to air messages, a message will be returned to the originator detailing the message delivery status. 

Each element of the communications path has some inherent reliability.  Ultimately, however, there will be procedures to account for the failure to communicate via data link, triggered by timers to alert the originator that the message was not delivered.

2.2.3.2.2.3 No matter what choice of protocol, there will be an alternate procedure to deal with a data link failure, or for non-routine or emergancy communications.  Satellite voice is expected to provide this backup.

2.2.3.2.2.4 There is some advantage in developing a robust application in the end systems to ensure maximum performance.

2.2.3.2.2.5 The ACARS convergance function mearly provides a means to convert a bit oriented message into a form suitable for transport across a character oriented network.  This is accomplished by converting each four bits into a hex character (0-9, A-F).  The AFN requires the initial contact request from the airplane contain a four letter ICAO code, which the communications service provider will convert to a seven digit network address.  From that point forward, the airplane and ATC applications will transfer communications as required with no further intervention from the service provider.  This is very likely to be a similar process with any protocol.

2.2.3.2.2.6 The sequencing of message delivery can be an issue.  The sequencing of multi-block messages can influence their timely delivery to the end user.  The ACARS network provides adequate means to sequence messages.  Ultimate loss of a message due to mis-sequencing is accounted for procedurally.  Other protocols may improve the performance of delivery of messages, but the ultimate benefit of this must be consistant with the incremental cost to provide the other protocols.

The use of satellite data communications ensures efficient use of RF spectrum.  This will not change with respect to end system protocol.  The use of ACARS in a VHF environment, with CSMA protocol does introduce some disruption in message delivery.  This can be compensated by providing adequate frequencies and robust frequency management.  The choice of protocol has minimal impact on the method of flow control.

ARINC 622 does not provide any inherent flow control.

2.2.3.2.2.8 The development of applications using ARINC 622 and the ACARS network will be driven by benefits.  If there is sufficient benefit, the end applications may be modified to provide for a more robust service while using these protocols.

2.2.3.2.2.9 No matter what protocol chosen, there will be procedures to deal with unforeseen or unlikely events.  No matter which protocol is chosen, there will be procudures to deal with a breakdown in air ground communications.  No matter which protocol is chosed, procedures will be developed to make the best use of provided capability.

2.2.3.2.2.10      It is understood that the smooth transition to utilization of data communcations in any form is of paramount concern.  Frustration in early stages could indeed introduce some reluctance to use of these applications.  However, for any development to take place, you must change something.  There must be some benefit to offset the cost of change.  By taking small steps, such as concentrating on development of applications first, and providing incremental benefit in light of any communications performance limitations, the most logical and satisfactory development can take place.  Procedures will be developed as required. 

2.2.3.2.11  The early introduction of ATM applications will be stimulated by the benefits provided by these applications.  The most signicant benefit will be lower operating costs and increased operating flexibility provided to the airplane operator.  In addition, there will be likely increases in safety by the use of more reliable air ground communications medium, such as satellite communications.  Pilot and controller workload are a consideration, but a reduction in their workload is not the primary benefit.

2.2.3.2.3.2 The use of the ACARS labels with ARINC 622 addressing does not provide an oppressive burden on avionics hardware.

2.2.3.2.3.3 Context management or directory services being developed for the ATN are indeed different from the ARINC 622 AFN.  Unfortunately, only the AFN is developed today; much work remains to finalize context management or the directory services.  There will be differences between how each of them operate.

2.2.3.2.4.1 The issue of priority must be kept in context with the performance requirements of the applications and the benefits that are being granted.  A communications network that meets the performance requirements should be considered acceptable even if it does not provide true use of priority.  There will be cases when messages are processed out of sequence from their inherent priority.  However, in any case, the system must be robust enough to provide acceptable performance.

Clearly, there must be some discipline in utilization of the ACARS network for ATS.  The use of single block messages should be encouraged to give the network maximum flexibility.  However, system performance is the ultimate goal, with or without priority.  It is possible that to achieve an incremental improvement in seperation at some point will require system performance that can be gauranteed only with priority.  At that point, there will be some comparison of the cost of upgrading versus the benefit of further reductions in seperation standards.

2.2.3.2.4.2 It is planned that the network will alert the originator of a message if it is not delivered.  At that point, it is possible that the user will utilize alternate procedures, such as direct voice contact.  However, routine messaging without exceptional problems will not require any extra-oridanry procedures.

2.2.3.2.4.3 The ACARS management unit is programmed to give priority to messages originating in the end system implementing ATS over messages originating in the maintenance computer, for example.

2.2.3.2.5.1 The use of ARINC 622 and the ACARS network does provide an optimal means to develop ATS applications.  These ATS applications should be developed with enough flexibility to allow for transition to an ATN environment when it is developed and becomes available.

2.2.3.2.5.2 The ACARS network using ARINC 622 is a reliable network with acceptable functionality and performance to support ATS applications.  The benefits received will be based on the performance demonstrated by the system.

2.2.3.2.5.3 The only drawback to using the ACARS network with ARINC 622 is based on potential performance limitations.  However, the RF limitations in the air ground communications mediums represents the most significant limitation in throughput.  However, this same RF capability will be utilized in the ATN, and will also be a limitation to that network.

2.2.3.2.5.4 It is important to recognise the development of procedures and workload of users of ATS, but the overriding consideration is to improve airplane operations.  The use of ACARS and ARINC 622 allow for early benefits to be achieved.  It is arguable, in comparison of this to the existing HF voice radio environment, that controller and pilot workload for routine communications will be reduced considerably.

2.2.3.3.2   There is no modification required to utilize data 2 satellite communications with the ACARS network.  The use of a mode S airborne data link will require implementation of new ACARS and mode S equipment.

2.2.3.3.3   The means of connecting to the ACARS network from ATC facilities may be different from the means to ultimately connect to the ATN.  To what degree these two paths are common has not been determined.

2.2.3.3.4   To what exent were aircraft operators planning on supporting ARINC 622, as this was primarily for pilot and controller data link?  Existing operators have applications that work today with the ACARS network.  No modification is required if ARINC 622 is added to support ATS.

2.2.3.3.5   <I DO NOT HAVE APPENDIX 1, BUT IT MUST BE RESPONDED TO...>

2.2.3.4.1   It is true that ARINC 622 functionality is subject to change.  The process is open to anyone to participate in, although ultimately only the airlines themselves make decisions.  The airlines make their decisions in light of direct impact of changes as well as in consideration of other factors, such as compatibility with ground systems.

2.2.3.5.2.1 The ATS end system has the means to determine which subnetwork to utilize.  The ACARS management unit is preprogrammed to favor one medium over another, primarily because of recurring cost considerations.  Strictly speaking, performance and reliability will not be impacted for ATS messaging, as it will be sent over any available means.  VHF and satellite communications should be considered reliable.

2.2.3.5.3.1 There are limited service providers for the ACARS networks.  Will this change when we move towards the ATN?

2.2.3.5.4.2 It is reasonable to presume that the regulatory agents will require adequate means to ensure message integrity and prevent hazerdously misleading data from being presented.  It is expected that the use of an end to end 16 bit CRC coupled with a limited valid character set is adequate.

2.2.3.5.4.3 Each air ground subnetwork has unique means to ensure reliable data transfer.  The issue of data integrity falls either in availability of data or corruption of data.  In this context, for enroute data link, the criteria to meet is improbable to present hazerdously misleading data.  This is an end to end requirement.  ARINC 622 provides for means to achieve this criteria.  The ADSP criteria of 10-7 for some applications must be considered with respect to the applications that are being proposed for early implementation with the ACARS network.

2.2.3.5.4.4 ARINC 622 does provide adequate integrity for applications being considered for early implementation using the ACARS network.

2.2.3.5.5.1 Despite considerable mechanisms used within the ACARS, both in the airborne and ground component, it is true that there are failure mechanisms which will not accurately reflect message delivery.  One example is if the ACARS to FMC bus fails; at least one message will be declared to have been delivered, but in fact it is not delivered all the way to the FMC.  But in this case, there will be procedures requiring positive acknowledgement of intentions by the end user.  A clearance to climb must be followed with a WILCO.  A request to climb would be followed with a clearance to climb.  If the originator of a message is informed the message was delivered, but no response has been received, the originator will have procedures related to this (for example, establish voice communications.

2.2.3.6.1   ARINC 622 was not developed solely because of physical limitations with respect to existing avionics.  The ACARS network exists today.  ARINC 622 provided a very easy means to utilize this existing network to support early introduction of ATS.

2.2.3.6.2   <I am unclear what is being suggested in this paragraph.  Is it being suggested that there is no other transition path given current avionics?>

2.2.3.6.5   There is no fundamental limitation with the use of ARINC 622 and the ACARS network other than system performance.  As long as performance is adequate for applications being considered, it is adeqaute.  The inherent performance limitations are not with protocol, but rather with air ground bandwidth.  These limitations will be present regardless of the protocol used.