Following discussion in Committee B on 17 March, it was suggested that material be drafted for Committee review regarding limitations to the number of Datalink types a controller should be required to work in a given airspace.

The following is a draft of possible wording for Technical Policy:

Controllers must not be required to utilize more than one disparate Datalink system in any unit of airspace. If aircraft equipped with more than one type of Datalink functionality are operating in the same airspace, the communications between these aircraft and the controller must be functionally identical.

Here are some of the aspects that must be considered in relation to this proposed policy:

An agreed upon level of Datalink functionality can be enforced, via automation, for a particular airspace. Aircraft that cannot meet this level of functionality are never presented to the controller as Datalink-equipped, and no downlinks from these aircraft are accepted.

A variation of this method would be to also have an agreed upon level of minimum common functionality between the various types of airborne Datalink equipages, and this would be the only functionality supported by the ground automation. Aircraft with a level of functionality greater than this agreed upon minimum would be prohibited, via automation, from performing these functionalities with the ground system.

Automation (e.g., “dual stacks”) can provide to the controller some level of functional transparency between disparate aircraft Datalink equipages. There are, however, several areas of caution that must be noted with this approach.

First, a fundamental principle in Datalink has been that the message presented to the controller or pilot should be identical the presentation on the other end. This is the basis for much of the debate regarding languages for presenting Datalink messages and also discussions as to whether symbols such as up arrows could substitute for the word “climb.” If automation is used to formulate an “approximately similar” message between aircraft Datalink systems that do not share an identical message set, it raises serious questions about the certification of a system that does not show a controller and pilot exactly identical presentations of a common communication.

Second, it would be operationally unacceptable for the automation to provide this transparency simply by providing error indications to the controllers whenever they attempted to uplink messages to aircraft that could not support that particular message. Even though error messages are an integral part of a Datalink system, their use in this manner would not constitute true functional transparency.

Third, most of the attention on differences between Datalink systems (FANS and ATN) has dealt mainly with message sets. While this is a real problem and must be addressed, there are potentially greater problems in the areas of system performance and specifications. SARPS (Standards and Recommended Practices) and Guidance Material that are being written by ICAO Panels for the ATN Datalink system set standards in the areas of message delivery times, prioritization of ATC over AOC messages, and message display and alerting attributes. Even if the differences in message sets can be accommodated, it may still be unwise to mix Datalink equipages in the same airspace if the system performance characteristics of one will degrade the entire systems performance (e.g., round trip message delivery times) to the point that the system becomes operationally unacceptable.

Conclusion

The Committee is invited to review the presented material and decide if a change in Technical Policy is necessary.