ACP WGN WP
16 February 2016
AERONAUTICAL COMMUNICATIONS PANEL (ACP)
WORKING GROUP N (NETWORKING)
Montreal, Canada, 11-20 May, 2005
CPDLC Message Sequencing Issues
Presented by EUROCONTROL
Summary
At the New Orleans ACP/WGN meeting (November 2004), a last minute
modification was made to the PM-CPDLC proposal to include a message
sequence number in the scope of the PM-CPDLC Application Checksum. Since
then, the Eurocontrol Link2000+ Team has conducted an extensive review of the
need for such a sequence number both from the communications and operations
perspectives. This paper records the result of this review and concludes with a
strong recommendation that the proposed message sequence number is removed
from PM-CPDLC.
16/02/2016
TRS164/TW/3/3/43 - Draft 0.4
i
TRS164/TW/3/3/43
CONTENTS
Page
1
WHAT IS MEANT BY “MESSAGE SEQUENCING”? .......................................................................... 1
2
SAFETY CONSIDERATIONS .................................................................................................................. 6
3
CONCLUSION AND RECOMMENDATIONS ....................................................................................... 8
3.1
SUMMARY OF EUROCONTROL LINK2000+ REVIEW.................................................................................... 8
3.2
RECOMMENDATIONS TO WGN ................................................................................................................... 9
A
OPERATIONAL ANALYSIS OF OUT-OF-SEQUENCE MESSAGES .............................................. 11
16/02/2016
Draft 0.4
ii
What is meant by “Message Sequencing”?
1
What is meant by “Message Sequencing”?
There has been a general concern that the delivery, by CPDLC, of “out-of-sequence
messages” could lead to an operational hazard. The first task of the Eurocontrol review was
thus to investigate whether this was true and if so, what is the underlying hazard.
When considering this, a useful input paper was found to be a paper submitted, by Boeing,
to the Industry Rapid Reaction Task Force (IRRF), which was responsible for preparing a
report to Link2000+ on FANS-1/A accommodation. This paper is attached as Annex A, and
is particularly useful because it contains many examples of operational scenarios where
CPDLC and ADS messages are delivered out-of-sequence, and the operational impact of
these scenarios
What is clear from these examples is that not only are there many cases where out-ofsequence delivery does not lead to a hazard, but in-sequence delivery is not itself sufficient
to avoid a hazard. A hazard results only if the pilot executes dependent clearances in a
different order to that intended by the controller, In fact, what is operationally significant is
whether the dependency and the order of execution intended by the sending controller is the
same as that perceived by the receiving aircrew.
This view was backed up by controllers from various regions, with the emphasis placed on
the “order of execution” rather than the “order of transfer”.
The operational requirement can therefore be summarised as:
1. The controller’s intent as to the order of execution of dependent clearances is
clearly and unambiguously communicated to the pilot.
There are of course related requirements in that the pilot is required to execute clearances
in the indicated order, and on the controller to give clear, precise and unambiguous
instructions. However, this is no different to the situation with voice based controller-pilot
communications.
The IRRF paper and Maastricht controllers also argued against an over-prescriptive
approach to message sequencing. In particular:
●
Aborting a CPDLC connection can itself lead to a hazard due to the impact on
controller and aircrew workload, and confusion over which clearances have and
have not been delivered. Hence, aborting a CPDLC connection due to out-ofsequence message delivery when there was no dependency between the
messages delivered out-of-sequence could induce an unnecessary hazard.
●
Delaying delivery of one message in order to ensure in-sequence delivery of an
earlier message that had to be retransmitted is often highly undesirable when there
is no dependency between the messages. Discarding such a message without
presentation to the intended recipient can be equally or even more undesireable.
This is because the unnecessary delay can have an operational impact.
For example, a message that tells you a wheel has fallen off is equally valid whether
it arrives in sequence or out of sequence and discarding it would be operationally
dis-advantageous.
From this, it is clear that the mechanism for communicating the correct order of execution of
dependent clearances should not itself impede the exchange of independent CPDLC
messages. It should be noted that many CPDLC messages are independent of each other
16/02/2016
TRS164/TW/3/3/43 - Draft 0.4
1
TRS164/TW/3/3/43
and can hence be communicated in different relative orders without significantly affecting
the outcome. There are thus further operational requirements:
2. The mechanism for communicating the correct order of execution of dependent
clearances should not itself impede the exchange of independent CPDLC
messages.
and
3. Operationally meaningful data shall not be discarded without human review or
delayed on the sole basis of its delivery being out of the order of transmission.
Requirement 2 is on the mechanism used to convey execution order, while requirement 3
deals with messages that arrive out of order. In general, discarding or delaying messages
just because they arrive out of transmission order is undesirable because this can delay
operationally valid information.
Having established the requirements, it was then necessary to consider how the
requirements are satisfied.
It is understood that, during the development of CPDLC, three possible strategies were
discussed for communicating dependent clearances.
Strategy #1: One Clearance at a time
Under this strategy, which is common with voice communications, and with all current
operational CPDLC implantations (ATN and FANS-1/A), dependent clearances are issued
by a controller, one at a time and in the intended order of execution. The controller waits for
a closure response before issuing the next clearance in the sequence. However, an
independent CPDLC transaction may be opened at any time during the transactions used to
transfer the sequence of dependent clearances.
This strategy ensures the order of execution of dependent clearances, as the controller
waits for the pilot to confirm execution of each clearance before issuing the next one. If the
pilot responds UNABLE to any clearance in the sequence, the controller is responsible for
determining the course of action resulting from a partially completed sequence.
Requirement 1 is satisfied by waiting for a closure response before the next clearance is
issued. Requirement 2 is satisfied because the controller is allowed to start an independent
transaction during the sequence of dependent transactions. The procedure only applies to
CPDLC transactions of the same type. Requirement 3 is also satisfied as there is no need to
discard or delay an out of order transmission; the communications service is not relied upon
to maintain transmission order1.
Strategy #2: Concatenated Messages
Under this strategy, the controller issues a sequence of dependent clearances as a single
concatenated CPDLC message.
There are two cases to consider:
1 However, use of the connection mode transport protocol for ATN CPDLC means that an out of order message
will be delayed in the network.
16/02/2016
Draft 0.4
2
What is meant by “Message Sequencing”?
a) Where the clearances are dependent, in the sense that the pilot must give a single
response to all of them, but the execution order is not important, and
b) Where the clearances are dependent, a single response must be given to all of
them, and the execution order is important.
An example of the first case is a controller concatenating “Cleared direct to <fixname>,
Climb to Flight level 350” into a single CPDLC message. These are dependent clearances,
and the controller wants the crew to do both or neither of them. However, the execution
order is not significant, They are most likely to be performed in parallel.
Use of the second case is more controversial as there is concern that CPDLC semantics are
not well enough understood to permit it. In Europe, the LINK2000+ Operational Focus
Group has, for such reasons, issued initial guidance that these type of clearances are not to
be used. Instead, when there is a required execution order, the controller should always use
Strategy #1 above.
The controversy is over the semantic of message element UM165 THEN and whether it
unambiguously implies an order of execution.
For example, a controller may concatenate “Climb to FL370, Then, Turn Left 30°”. In this
case, the concatenation is again used to signal the dependency but, additionally, the
message element UM165 THEN is used to indicate that there is a required order of
execution, and that the order of execution is the same as the order of the message
elements within the concatenated CPDLC message.
This approach uses concatenation and UM165 THEN to convey the controller’s intent as to
both the dependency and the order of execution of dependent clearances, and relies upon
this interpretation of UM165. As such, the approach meets requirement 1. CPDLC requires
that a single closure response is given and hence the pilot must either accept and execute
the sequence of clearances in its entirety or reply UNABLE. In either case, the controller is
given a clear indication as to the outcome of the sequence of clearances and can decide on
the next action.
Independent CPDLC transactions may be opened before the closure response is received
and hence requirement 2 is also satisfied. Requirement 3 is also satisfied as there is no
need to discard or delay an out of order transmission; the communications service is not
relied upon to maintain transmission order1.
If more dependent clearances need to be issued than can be concatenated into a single
CPDLC message, then this strategy can be combined with strategy #1.
This approach appears workable, however, the use of concatenation for dependent
clearances where the order of execution is significant, awaits agreement on the semantics
of UM165 and is thus considered as currently “for further study”.
Strategy #3: Transmission Order
Under this strategy, dependent clearances are sent as separate CPDLC messages, rather
than being concatenated into the same message. The actual transmission order of the
separate CPDLC messages is used to imply the sequence of execution, with the controller
no longer waiting for a closure response for a clearance before issuing a subsequent
dependent clearance. This is significantly different from the previous strategies where
dependency and execution order is given by the semantics of the CPDLC messages
themselves. Under this strategy, the communications service is being used and relied upon
to indicate dependency and execution order. This has important safety implications,
16/02/2016
TRS164/TW/3/3/43 - Draft 0.4
3
TRS164/TW/3/3/43
demanding a much higher level of assurance from the Communications Service than is
required by the other strategies.
However, there are a number of issues associated with such a strategy:
1. How is the dependency implied given that by no means all CPDLC messages are
dependent on each other? How does the pilot know that two successive but separately
sent messages have a required execution order?
Use of UM165 THEN does not appear appropriate here. For example, how would a
flight crew react to PROCEED DIRECT TO <fixname> + THEN? They could not WILCO
the message as the clearance is incomplete.
UM165 THEN cannot correctly be used on its own. It could be used as in, for example,
THEN + PROCEED DIRECT TO <fixname>, but this is not really compatible with voice
phraseology which would naturally be more explicit (e.g. AT FL350 PROCEED DIRECT
TO <fixname>). This is a CPDLC message (UM75), but in this case the dependency is
being signalled by the message itself and this is a different strategy to relying the
Communications Service.
2. What happens if a pilot responds UNABLE to a message before a subsequent and
dependent clearance arrives? Does the pilot have to respond UNABLE to that message
as well, and how does the pilot know this?
It would seem that the pilot has to assume that each instruction has to be executed in
sequence and if an UNABLE response is given then all subsequent instructions must be
responded to with UNABLE until the controller advises otherwise (although it is not clear
as to how this advice can be given with the current CPDLC message set), and this is,
anyway, unlikely to result in operational satisfaction for either aircrew or controller.
3. ICAO Doc9705 2.3.7.3.2.2 states “When a CPDLC-user queues received messages,
messages with the highest Urgency type shall be placed at the beginning of the queue”.
Thus, mixing dependent clearances with different Urgency attributes can result in a
hazard as an ICAO-compliant system may require that controller’s intended order of
sequence is incorrectly displayed to the pilot.
The controller must hence ensure that messages with different Urgency attributes are
always independent of each other.
The underlying problem with this strategy is that CPDLC lacks a mechanism to group
separate messages together and only the controller is really aware of any dependency
between successive messages. The pilot thus has to assume that all messages are
dependent on the preceding message.
Requirement 1 is met but only by ensuring that requirements 2 and 3 cannot be met. This is
because the receiver must always assume that successive messages are dependent on
each other and must be executed in reception order. There is thus no scope for mixing
independent and dependent instructions as responding UNABLE to one message means
that UNABLE must be the response to subsequent messages, even when they are
independent.
It may be possible for the pilot to exercise a degree of judgement on whether a received
message is dependent on the outcome of a previous message but this is potentially
hazardous as, unless the relationships between every possible message are clearly defined,
there is always the risk of mis-understanding. On the other hand, the HMI cannot permit out
of order display to the pilot as, by definition, the preceding message has not been received
and it is not possible to determine whether there was a dependency on that message.
16/02/2016
Draft 0.4
4
What is meant by “Message Sequencing”?
This strategy does not meet the requirements identified above. The lack of any apparent
mechanism to signal the end of a dependent sequence may also make it unworkable in
practice.
Conclusion
The first two strategies are sufficient for CPDLC, and meet the known operational
requirements for message sequencing in both congested and uncongested airspace. The
third strategy does not meet requirements 2 and 3, and only meets requirement 1 by
imposing onerous procedures on both controller and pilot. Any deviation from these
procedures could quickly result in a hazard.
Strategy #3 is the only one to require that the communications service preserves the
message sequence. Indeed that is its problem. The issues are caused by not using CPDLC
message element semantics to identify dependencies and required execution order.
It is believed that strategies #1 and #2 are sufficient for world-wide use of CPDLC. CPDLC
is not mature enough to support Strategy #3 and any further consideration of Strategy #3
should be for further study.
There may be scope for developing a strategy for issuing dependent clearances in separate
messages, using messages such as UM75 to signal the dependency. This moves the
semantics of the dependency back into CPDLC and should not rely on the Communications
Service to indicate dependency.
The conclusion is that there is no workable CPDLC strategy that requires the
Communications Service to maintain message sequence. Dependency semantics can and
always should be part of CPDLC itself and should not rely on features of the
Communications Service.
16/02/2016
TRS164/TW/3/3/43 - Draft 0.4
5
TRS164/TW/3/3/43
2
Safety Considerations
Eurocae ED-120/RTCA DO-290 “Safety and Performance Requirements Standard for Air
Traffic Data Link Services in Continental Airspace (Continental SPR Standard)” contains the
Safety Objectives and Requirements for continental deployment of en-route CPDLC.
For the ATC Clearance Service (ACL), the Safety Objective relevant to this discussion is
SO-ACL-15 “The likelihood of undetected out of sequence messages used for separation
shall be no greater than remote.”
Following the above analysis, and consideration of requirement 1 above, SO-ACL-15 should
be interpreted as “the likelihood of out of order execution of a sequence of dependent
clearances shall be no greater than remote”.
This “remote” Safety Objective is important for deployment as implementers will have to
demonstrate to a Safety Authority that the probability that this will occur is remote. Both the
design of CPDLC and the software architecture will have to be taken into account when
approval for operational use is granted.
Eurocae ED-120/RTCA DO-290 also contains a number of Safety Requirements. Those that
are linked to SO-ACL-15 are:
SR-ACL-1
When a clearance requires execution of more than one maneuver to
be done in a specific sequence, the clearances shall be put in the order
that they are to be executed in a single uplink message.
SR-ACL-2
Each uplink message shall be uniquely identified for a given aircraftATSU pair.
SR-ACL-3
Each downlink message shall be uniquely identified for a given aircraftATSU pair.
SR-ACL-4
A response message shall indicate to which message it refers.
SR-ACL-7
Messages shall be responded to in their entirety.
SR-ACL-8
Any processing (data entry/encoding/transmitting decoding/displaying)
shall not affect the intent of the message.
SR-ACL-22
Messages shall be transmitted/received in the order that they are sent.
SR-ACL-23
Only one dialogue of a given type shall be open at any time for a given
aircraft-ATSU pair.
SR-ACL-2, SR-ACL-3, SR-ACL-4 and SR-ACL-8 are common requirements for many safety
objectives and are clearly necessary for correct interpretation of CPDLC messages. CPDLC
itself complies with these requirements and implementers are required to demonstrate that
their software implements these features correctly.
SR-ACL-23 is satisfied by the implementation of strategy #1 above. Likewise, SR-ACL-1
and SR-ACL-7 are satisfied by the implementation of strategy #2.
16/02/2016
Draft 0.4
6
Safety Considerations
SR-ACL-22 appears to be specific to strategy #3 and is a necessary condition for the
implementation of strategy #3, but only if the possible CPDLC defect identified in the
previous section is ignored.
These three groups of safety requirements appear to thus align with the strategies
presented earlier and, upon analysis, appear to be alternative and possibly complementary
ways of meeting the Safety Objective, rather than all needing to be satisfied simultaneously.
In particular, given the analysis presented in the preceding section, SR-ACL-22 is probably
inappropriate given that the corresponding strategy is not believed to be workable and a
change to CPDLC in order to resolve this will result in a very different safety requirement.
This analysis has been presented to representatives of Eurocae WG-53/RTCA SC-189 and
has been accepted. A change proposal to ED-120 is thus anticipated in order to bring it into
line with the analysis presented in this paper.
In summary, CPDLC with either strategy #1 or strategies #1 and #2 meets the ED120/RTCA DO-290 Safety Objectives and are sufficient to ensure that dependent
clearances can be communicated using CPDLC. The Safety Requirement that appears to
require that the communications service maintains message sequence only applies to
strategy #3 and is only there because of a defect in CPDLC. It is therefore an inappropriate
and unnecessary requirement.
16/02/2016
TRS164/TW/3/3/43 - Draft 0.4
7
TRS164/TW/3/3/43
3
Conclusion and Recommendations
3.1
Summary of Eurocontrol Link2000+ Review
The following is the agreed conclusion of the Link2000+ Message Sequencing discussion,
as documented and agreed by Link2000+:
16/02/2016

The “message out of sequence” hazard occurs when a sequence of dependent
clearances is executed out of sequence i.e. the pilot executes the clearances in a
different sequence to that intended by the controller. This is the agreed interpretation of
ED-120/DO-290 H-ACL-15 .

The Safety Objective is therefore to ensure that the controller’s intent as to the order of
execution of dependent clearances is preserved during the execution of the clearances
by the pilot.

The above is viewed as the correct interpretation of SO-ACL-15 (The likelihood of
undetected out of sequence messages used for separation shall be no greater than
remote).

When a controller needs to issue a sequence of dependent clearances, the controller is
required to issue that clearance as a single concatenated CPDLC message; the order in
which the clearances occur in the message specifies the order of execution. This
requirement is echoed by ED-120 SR-ACL-1 (When a clearance requires execution of
more than one manoeuvre to be done in a specific sequence, the clearances shall be
put in the order that they are to be executed in a single uplink message.)

ED-120 SR-ACL-7 (Messages shall be responded to in their entirety) ensures that the
pilot must provide a single unambiguous response to a sequence of dependent
clearances.

When a controller needs to issue a clearance that is dependent on the successful
outcome of a clearance that had been issued earlier, they are required to wait until the
execution of that earlier clearance has been completed before the new clearance is
issued. This outcome may be determined by a pilot report or through surveillance
information.

ED-120 SR-ACL-23 (Only one dialogue of a given type shall be open at any time for a
given aircraft-ATSU pair) avoids potential confusion that could result from a controller
issuing a new clearance before the pilot had responded to an earlier clearance. .

ED-120 SR-ACL-23 does not prevent a controller issuing a different type of instruction
(e.g. an SSR Code Change) before the response to a clearance has been received. The
response to (e.g. an SSR Code Change) may also be received before the response to
the clearance. Neither the communications system nor the HMI should prevent this
behaviour i.e. out of sequence responses to CPDLC messages of different dialogue
types must not be prevented.

It is noted that SR-ACL-2 (Each uplink message shall be uniquely identified for a given
aircraft-ATSU pair), SR-ACL-3 (Each downlink message shall be uniquely identified for
a given aircraft-ATSU pair), SR-ACL-4 (A response message shall indicate to which
message it refers), SR-ACL-8 (Any processing (data entry/encoding/ transmitting/
decoding/displaying) shall not affect the intent of the message) are also required in
order to meet SO-ACL-15. However, they are otherwise outside of the scope of this
discussion.
Draft 0.4
8
Conclusion and Recommendations

It is noted that ICAO Doc9705 2.3.7.3.2.2 (When a CPDLC-user queues received
messages, messages with the highest Urgency type shall be placed at the beginning of
the queue) permits the receiver to reorder messages by Urgency and that this does not
have an interoperability or safety impact.

It is noted that there are also situations where a it is desirable that a CPDLC Message is
uplinked before the response to an earlier message has been received. For example,
where a change in SSR Code is required shortly after a clearance has been issued. The
meaning of “dialogue type” in ED-120 needs to be clarified to ensure such cases are
fully understood.

It is noted that the OFG has recommended that when dependent clearances are
concatenated into the same CPDLC message, they should be separated by the
message element UM165 THEN.
It is thus concluded that:
(a) ensuring the execution order of dependent clearances by the pilot is the same as that
intended by the controller, is a Safety Requirement,
(b) preserving the transmission order of CPDLC messages themselves, on receipt, is not a
Safety Requirement.
This is because H-ACL-15 is fully mitigated by SR-ACL-1 and SR-ACL-7 (together with SRACL-2, 3, 4 and 8) for clearances that require execution of more than one manoeuvre in a
specific sequence. SR-ACL-23 also avoids potential confusion that could result from a
controller erroneously issuing a clearance of the same dialogue type of an earlier CPDLC
message and for which a response was outstanding.
ED-120 SR-ACL-22 (Messages shall be transmitted/received in the order that they are sent)
thus appears to have no useful role to play.
It is proposed that SR-ACL-22 should no longer reference SO-ACL-15 and that the
reference from SR-ACL-22 to SO-ACL-15 should be deleted.
3.2
Recommendations to WGN
ICAO ACP/WGN is invited to:
1. Review the analysis presented in this paper.
2. Remove the addition of a message sequence number from the scope of the PMCPDLC checksum, as there is no requirement on the communications service to
maintain message sequence.
The recommendation to remove the message sequence number from the scope of the PMCPDLC checksum is a strong recommendation, not only because it is unnecessary but also
because its implementation will adversely affect ground CPDLC implementations that place
the ATN End System in a separate front end processor or server (which is the case with all
known implementations). This is because the PM-CPDLC checksum should be generated
when the message is first originated if it is to give the maximum safety benefit, and then
communicated end-to-end without modification.
However, in a distributed architecture there are potentially several points of message
origination and messages may be originated by both automatic and manual processes. A
shared sequence number is difficult to manage in such a system and regeneration of the
16/02/2016
TRS164/TW/3/3/43 - Draft 0.4
9
TRS164/TW/3/3/43
checksum in the front end processor is the only realistic implementation strategy, thus
adding an additional point at which a failure could occur.
16/02/2016
Draft 0.4
10
Conclusion and Recommendations
A
Operational Analysis of Out-Of-Sequence Messages
Acknowledgement: This annex contains an updated version of a paper with the above title
prepared by Boeing ATM and submitted to the IRTF for Link2000+.
A.1
Introduction
One of the concerns over use of FANS-1/A (reference: ED100/DO258) in domestic airspace
is the lack of a systematic prevention of out-of-sequence datalink message delivery.
This is not currently viewed as an issue in oceanic environments using FANS-1/A, so
Boeing wanted to understand the operational requirement better in order to arrive at a
solution that would satisfy the domestic environment without jeopardizing oceanic FANS-1/A
utility.
To understand the requirement better, operational analysis was conducted, as outlined in
this paper. Operational scenarios involving out-of-sequence message delivery were laid out,
and then two aspects were considered for each scenario:
1. We listed the operational impact of allowing the out-of-sequence deliveries to occur.
2. We listed the operational effects of introducing a communications layer solution for
assuring in-sequence delivery to upper layers of automation (i.e. sequence of delivery is
assured across the communications ‘pipe’, but is not assured or within any automation
or systems above the ‘pipe’, to include the CPDLC and ADS applications themselves).
With this solution, the solution was designed to deliver messages in sequence, but
should any messages be received out of sequence the messages would be discarded
without notification to the recipient and the communications ‘pipe’ removed without
further use.
Note: This particular solution to in-sequence delivery assurance was specifically
examined because it is a solution that has been proposed for resolving this issue, and
its impact on oceanic operations needed to be looked at to ensure it would be
acceptable in existing datalink operational regions.
To completely understand the context, we started with a voice-only scenario. This may
seem strange for a datalink analysis, but it helped understand more clearly both the
operational hazard and the potential solutions.
A.2
Operational Context
The following scenarios concern some out-of-sequence exchanges that could arise from
using CPDLC and ADS.
The operational context for these sequences is:
1. Congested, continental en-route airspace.
2. Mode C radar surveillance is available.
3. VHF R/T channel is available, and is the primary communications tool for tactical
communications, communications requiring immediate responses, and communications
involving complex constructs and instruction sequences.
16/02/2016
TRS164/TW/3/3/43 - Draft 0.4
11
TRS164/TW/3/3/43
Note: The term “complex constructs and instruction sequences” in the above context
is not intended to include route clearances and similar lengthy messages. Such
exchanges are complex in the sense that a lot of data is exchanged, which lend
themselves very well to data link. The above refers to complexities in the sense that
subtle operational nuances, dependencies, and meanings are being conveyed in a
format and sequence not routinely seen on the ground or in the air.
4. Primary use of data link is CPDLC for routine communications only.
5. CPDLC is used strategically. Data link is not to be used for immediate separation
purposes under normal circumstances.
6. No voice readback is required for any message.
A.3
Out-Of-Sequence Message Scenarios
A.3.1
Dependant Clearances, Delivered in Sequence via Voice
In the following sequence, two clearances are sent in rapid sequence via voice, with the
second clearance dependant upon the first.
Using voice the clearances arrive in sequence, but are operationally acknowledged out-ofsequence.
A.3.1.1
Sequence
No.
1. Via R/T:
[point]”
ATSU
Aircraft
“cleared direct to
2. Via R/T:
“climb to and
maintain [level]”
A.3.1.2
Comment
This clearance is
only
to
be
executed if the
aircrew
accepts
the direct routing.
3.
Via R/T: “Wilco, climb to
[level].”
4.
Via R/T: “Unable, direct to
[point].”
Conclusion
The above “voice only” scenario was included to clarify the operational situation being
discussed. Two points are apparent:
1.
Even when messages arrive in sequence (voice or data link), unless a stipulation is
placed on the crew to answer them in sequence, the out-of-sequence hazard still exists.
This, in turn, means that simply embedding an “in-sequence-delivery” function in the
communications chain does not resolve the envisaged hazard.
16/02/2016
Draft 0.4
12
Conclusion and Recommendations
2.
The operational need and desirability of the above scenario should be confirmed during
the hazard analysis for out-of-sequence delivery of messages. A common reaction to
the above scenario during draft internal and external reviews was to question its
operational viability.
Controllers would normally either wait for the acknowledgement of the first clearance to
issue a second, dependent clearance, or they would choose a clearer construct (e.g.
“Cleared direct to [position], when steady on track, climb to [level]”).
Both of these reactions would appear to apply to data link as well, with the latter
equating to a ‘concatenated’ CPLDC uplink.
The overall conclusion is that the operational viability of this “out-of-sequence” scenario
needs to be clarified. If it proves viable, then a communications-level in-sequence
assurance mechanism is insufficient to resolve the scenario.
A.3.2
Dependant Clearances, Delivered in Sequence via Data link
In the following sequence, two clearances are sent in rapid sequence via data link, with the
second clearance dependent upon the first.
As with the preceding scenario, the clearances arrive in sequence, but are operationally
acknowledged out-of-sequence.
A.3.2.1
Sequence
No.
A.3.2.2
ATSU
Aircraft
1
Uplink “cleared
[point]”
direct
2
Uplink “climb to and maintain
[level]”
Comment
to
This clearance is
only
to
be
executed if the
aircrew accepts the
direct routing.
3
Wilco, climb to [level].
4
Unable, direct to [point].
Conclusion
This scenario demonstrates the same two points as the voice scenario (ref:0), this time in a
data link context:
1.
Even when messages arrive in sequence (voice or data link), unless a stipulation is
placed on the crew to answer them in sequence, the out-of-sequence hazard still exists.
This, in turn, means that simply embedding an “in-sequence-delivery” function in the
communications chain does not resolve the envisaged hazard.
16/02/2016
TRS164/TW/3/3/43 - Draft 0.4
13
TRS164/TW/3/3/43
2.
The operational need and desirability of the above scenario should be confirmed during
the hazard analysis for out-of-sequence delivery of messages.
Controllers should either wait for the acknowledgement of the first clearance to issue a
second, dependent clearance, or they should choose a clearer construct (e.g. a single
concatenated CPDLC message containing both clearances with the dependency clear
in the message, e.g. “cleared direct to [point] then climb to and maintain [level]”).
The overall conclusion is that the operational viability of this “out-of-sequence” scenario
needs to be clarified. If it proves viable, then a communications-level in-sequence
assurance mechanism is insufficient to resolve the scenario.
A.3.3
Dependant Clearances, Delivered and Answered in Sequence via Data
link
In the following sequence, two clearances are sent in rapid sequence via data link, with the
second clearance dependent upon the first.
As with the preceding scenario, the clearances arrive in sequence. However, in this
scenario the clearances are also operationally acknowledged in sequence, so all parts of
the end-to-end chain handled the messages in exactly the sequence intended by the issuing
controller.
A.3.3.1
Sequence
No.
A.3.3.2
ATSU
Aircraft
2
Uplink “climb to and maintain
[level]”
2
Uplink “cleared
[point]”
direct
Comment
This clearance is
only
to
be
executed if the
aircrew accepts the
subsequent direct
routing.
to
3
Wilco, climb to [level].
4
Unable, direct to [point].
Conclusion
Like the first to scenarios, this scenario (ref: 0 and 0) demonstrates that the underlying
hazard is not resolved by in-sequence message delivery.
1.
Even when messages arrive in sequence (voice or data link), and the crew answers
them in sequence, the underlying hazard still exists.
This, in turn, means that simply embedding an “in-sequence-delivery” function in the
communications chain does not resolve the envisaged hazard.
16/02/2016
Draft 0.4
14
Conclusion and Recommendations
2.
The operational need and desirability of the above scenario should be confirmed during
the hazard analysis for out-of-sequence delivery of messages.
Controllers should either wait for the acknowledgement of the first clearance to issue a
second, dependent clearance, or they should choose a clearer construct (e.g. a single
concatenated CPDLC message containing both clearances with the dependency clear
in the message, e.g. “cleared direct to [point] then climb to and maintain [level]”).
The overall conclusion is that the operational viability of this scenario needs to be clarified. If
it proves viable, then a communications-level in-sequence assurance mechanism is
insufficient to resolve the hazard.
A.3.4
Dependent Clearances, Delivered Out-Of-Sequence
In the following sequence, two clearances are sent in rapid sequence via data link, with the
second clearance dependent upon the first.
The clearances arrive out-of-sequence, and are operationally acknowledged in their order of
arrival.
A.3.4.1
Sequence
No.
ATSU
Aircraft
Comment
1. Uplink “cleared direct to
[point]”
2. Uplink
“climb
maintain [level]”
A.3.4.2
to
and
This clearance is
only
to
be
executed if the
aircrew
accepts
the direct routing.
3.
Aircrew
receives
and
Wilco’s climb to [level].
4.
Aircrew
receives
and
Unable’s cleared direct to
[point].
Conclusion
The above scenario results in exactly the same operational hazard as the first two, though
the cause is different. In this scenario the cause of the hazard is that the clearances were
delivered out of sequence, while in the first two they were simply acknowledged out of
sequence.
16/02/2016
TRS164/TW/3/3/43 - Draft 0.4
15
TRS164/TW/3/3/43
1.
This scenario demonstrates that the hazard is in out-of-sequence display and
acknowledgement of the uplinks. This hazard arrives solely through the use of
dependent and unacknowledged clearances by the controller.
Once the messages are identified as “out-of-sequence”, system-level functions could
be introduced to take the appropriate operational action (e.g. display to the crew only in
order).
2.
The operational need and desirability of the above scenario should be confirmed during
the hazard analysis for out-of-sequence delivery of messages.
Controllers should either wait for the acknowledgement of the first clearance to issue a
second, dependent, clearance, or they should choose a clearer construct (e.g. a single
concatenated CPDLC message containing both clearances with the dependency clear
in the message, e.g. “cleared direct to [point] then climb to and maintain [level]”).
The overall conclusion is that the operational viability of the “out-of-sequence” scenario
needs to be clarified. If it proves viable, then a communications-level in-sequence
assurance mechanism is insufficient to resolve that scenario.
A.3.5
Dependent Clearances with Conflicting Alerting Attributes
In the following sequence, two clearances are sent in rapid sequence via data link, with the
second clearance dependent upon the first.
The clearances arrive in sequence, but because of the operationally defined alerting
attributes in the FANS or ATN specifications, they are operationally acknowledged out-ofsequence.
A.3.5.1
Sequence
No.
16/02/2016
ATSU
Aircraft
1
Uplink “cleared
[point]”
direct
2
Uplink “immediately climb to
and maintain [level]”
Comment
to
This clearance is
only
to
be
executed if the
aircrew
accepts
the direct routing.
3
Aircrew
Wilco’s
“immediately climb to and
maintain [level].”
Aircrew reacts to
the higher alerting,
and responds to
this message first.
4
Aircrew Unable’s “cleared
direct to [point].”
Message received
prior to above, but
answered second.
Draft 0.4
16
Conclusion and Recommendations
A.3.5.2
Conclusion
The above scenario results in exactly the same operational hazard as the first two, though
the cause is different. In this scenario the cause of the hazard is that the clearances were
delivered in-sequence, but the message alerting attributes drew the attention of the crew to
the second message and they responded to the two messages out-of-sequence.
1.
This scenario demonstrates that the hazard is in display and out-of-sequence
acknowledgement of the uplinks. This hazard arrives solely through the use of
dependent and unacknowledged clearances by the controller.
System-level functions could be introduced to take the appropriate operational action
(e.g. prevent the crew from acknowledging the messages out of order).
2.
The operational desirability of preventing the crew from answering messages out-ofsequence should be analyzed.
For dependant clearance cases, controllers should wait for the acknowledgement of the
first clearance to issue a second, dependent, clearance.
3.
This scenario may indicate contradictory provisions should both alerting attributes insequence delivery be required. If all messages are expected to be dealt with in the
order of issuance by the controller, than different alerting attributes for messages may
be inappropriate, as they appear to be indicating that crews should respond to some
messages out-of-sequence.
Similar contradictions may be present in the use of urgency attributes for messages. If
two messages are delivered in sequence, but then reversed during queuing and transit
to aircrew HMI, as required by datalink specifications, the end-to-end effect is still outof-sequence delivery. Although communications layers delivered the messages in
sequence, upper layers delivered them out-of-sequence as specified.
The overall conclusion is that a communications layer solution will not resolve this scenario,
and may in fact be overridden by other parts of the same datalink specification set which
then contributes to the potential for the envisaged hazard to occur. The operational viability
of this “out-of-sequence” scenario needs to be clarified. If it proves viable, then a
communications-level in-sequence assurance mechanism is insufficient to resolve it.
A.3.6
Independent Clearances, Delivered Out-Of-Sequence
In the following sequence, two clearances are sent in rapid sequence via data link, with no
dependency between the clearances. This is a common operational scenario for the initial
data link sector under the operational context stated.
The clearances arrive out-of-sequence, and are operationally acknowledged in their order of
arrival (i.e. out of sequence).
A.3.6.1
Sequence
No.
16/02/2016
ATSU
Aircraft
1
Uplink “cleared
[point]”
2
Uplink “climb to and maintain
direct
Comment
to
TRS164/TW/3/3/43 - Draft 0.4
17
TRS164/TW/3/3/43
No.
ATSU
Aircraft
Comment
[level]”
A.3.6.2
3
Aircrew
receives
and
Wilco’s climb to [level].
4
Aircrew
receives
and
Unable’s cleared direct to
[point].
Conclusion
No hazard arises from the above scenario. The clearances arrive out-of-sequence, and are
operationally acknowledged in their order of arrival (i.e. out of sequence).
1)
Because the controller did not issue the second clearance under the assumption that
the first would be acknowledged, there is no hazard associated with this scenario.
2)
This scenario is operationally viable, is not a hazard, but if the underlying in-sequence
assurance mechanism forced an abort of the connection because of the out-ofsequence delivery, it would result in total loss of the comm. channel with neither
clearance dialogue completed.
3)
Loss of the comm. channel may, in itself, result in a hazard that would otherwise not
have occurred (ref 0 and 0).
The overall conclusion is that operationally benign “out-of-sequence” exchanges can occur
with no hazard arising. However, a communications-level in-sequence assurance
mechanism that mandated removal of the CPDLC connection if out-of-sequence is detected
may in fact cause new problems for the controller and aircrew involved.
A.3.7
Independent Clearances, Delivered Out-Of-Sequence, with Latent
Message Check
In the following sequence, two clearances are sent in rapid sequence via data link, with no
dependency between the clearances.
The clearances arrive out-of-sequence, due to network congestion causing a media switch
or e.g. FANS-1/A internetworking. Both arrive after a two-minute latency check in the aircraft
(latency value chosen to allow multi-airspace use, and to match Europe’s operational
dialogue warning timer).
A.3.7.1
Sequence
No.
16/02/2016
ATSU
Aircraft
1
Uplink “cleared
[point]”
direct
2
Uplink “climb to and maintain
[level]”
Comment
to
Draft 0.4
18
Conclusion and Recommendations
No.
A.3.7.2
ATSU
Aircraft
3
Aircrew receives climb to
[level], with a warning that
it is old and he should
verify it.
4
Aircrew receives “direct to
[point]”, with a warning that
it is old and should be
verified.
Comment
Conclusion
Any hazard arising from the above scenario is at least partially mitigated by the latent
message check.
Even if no check for out-of-sequence messages is done, crews will receive an advisory that
something needs to be verified if the out-of-sequence message arrives after a given
parameter. As a probable cause of out-of-sequence messages is either network congestion
or internetworking, delays will be inherent to many cases of out-of-sequence messages, and
this will result in a latent message error.
This means that if a latent message check is in place, out-of-sequence messages are only a
problem if:
A. The out-of-sequence messages are dependent upon each other.
B. The second message is issued without waiting for an operational acknowledgement to
the first.
C. The messages are issued, reversed, and delivered within two minutes (or whatever
latency check parameter is used).
The overall conclusion is that this “out-of-sequence” scenario is not a hazard, because no
dependency between unacknowledged uplinks occurs. The scenario also shows that a
latent message alerting mechanism can partially mitigate hazards arising from out-ofsequence delivery, if such hazards are established.
A.3.8
Independent Out-Of-Sequence Downlinks Cause Abort
In the following sequence, two downlinks are sent in rapid sequence via data link, with no
dependency between them.
The downlinks are detected as arriving out-of-sequence by the communications, are
discarded without notification to the user, and the CPDLC channel is removed as a result.
Another clearance dialogue is in progress at the time.
16/02/2016
TRS164/TW/3/3/43 - Draft 0.4
19
TRS164/TW/3/3/43
A.3.8.1
Sequence
No.
1
ATSU
Aircraft
Comment
Uplink “climb to and maintain
[level]”
2
Wilco to [level]
3
Downlink “request direct to
[posn]”
Climb begins
Comm system unable to
deliver
messages
in
sequence
and
aborts
CPDLC connection.
4
Ground never sees Wilco.
Unless LACK is used,
Controller does not know if
the clearance uplink was
received.
A.3.8.2
Conclusion
Three conclusions can be drawn from this scenario:
1.
No hazard would have arisen from the out-of-sequence delivery itself.
2.
Choosing a communications-level in-sequence assurance mechanism that results in
removal of the communications channel, the above non-hazardous out-of-sequence
delivery resulted in loss of CPDLC.
If data link is being relied upon for capacity increases, or to allow other safety critical
changes, then loss of CPDLC may be a hazard in itself.
Likelihood of occurrence is an important parameter to establish as input to any future
analysis on this scenario.
3.
If LACK is not used on the ground, then a hazard may occur from a communicationslevel in-sequence assurance mechanism that results in removal of the CPDLC channel
when out-of-sequence delivery is detected. In this case, the controller would not know
whether the clearance had been delivered or not unless a LACK or MAS mechanism
was used.
A communications-level in-sequence assurance mechanism, a secondary requirement
may be LACK / MAS.
The overall conclusion of this scenario is that one or more hazard(s) may result a
communications-level in-sequence assurance mechanism that results in removal of the
CPDLC channel when out-of-sequence delivery is detected, though no hazard arises from the
out-of-sequence delivery itself. This should be looked at during the safety assessment.
16/02/2016
Draft 0.4
20
Conclusion and Recommendations
A.3.9
Independent Out-Of-Sequence Downlinks Cause Abort (2)
In the following sequence, two downlinks are sent in rapid sequence via data link, with no
dependency between them.
The downlinks arrive out-of-sequence, and result in removal of the CPDLC channel when
out-of-sequence delivery is detected. No clearance dialogue is in progress at the time.
A.3.9.1
Sequence
No.
ATSU
Aircraft
1
Downlink “Request [level]”
3
Downlink “MAYDAY”
Comment
Comm system unable to
deliver
messages
in
sequence
and
aborts
CPDLC connection.
4
A.3.9.2
Ground never sees MAYDAY
Conclusion
It is understood that crews would normally not rely on data link alone to notify an
emergency. However, in some cases it may be the only appropriate means available.
The overall conclusion of this scenario is that one or more hazard(s) may result from a
communications-level in-sequence assurance mechanism that results in removal of the
CPDLC channel when out-of-sequence delivery is detected, though no hazard would have
arisen from the out-of-sequence delivery itself (quite the reverse – this out-of-sequence was
beneficial). This should be looked at during the safety assessment.
Likelihood of occurrence is an important parameter to establish as input to any future
analysis on this scenario.
A.3.10 Out-Of-Sequence ADS Downlinks Cause Abort
In the following sequence, two ADS downlinks are sent in sequence via data link, with no
dependency between them.
The downlinks arrive out-of-sequence, and result in removal of the ADS channel when outof-sequence delivery is detected.
A.3.10.1 Sequence
No.
1
16/02/2016
ATSU
Aircraft
Comment
Downlink ADS Report 1
TRS164/TW/3/3/43 - Draft 0.4
21
TRS164/TW/3/3/43
No.
ATSU
Aircraft
3
Comment
Downlink ADS Report 2
Comm system unable to
deliver ADS Reports in
sequence and aborts ADS
connection.
4
Ground does not see any
ADS reports, and must reset
the surveillance connection if
surveillance data desired.
A.3.10.2 Conclusion
If the ADS link is used as a primary function, required for e.g. reduced separation or
increased capacity, the above scenario needs to be analyzed to see if it is a hazard.
Hazards could arise from either the reversed reports, or removal of the ADS comm.
channel.
The overall conclusion of this scenario is that one or more hazard(s) may result from a
communications-level in-sequence assurance mechanism that results in removal of the ADS
channel when out-of-sequence delivery is detected, though no hazard would have arisen
from the out-of-sequence delivery itself. This should be looked at during the safety
assessment.
Likelihood of occurrence is an important parameter to establish as input to any future
analysis of this scenario.
A.3.11 Multi-Aircraft, Dependant Clearance, Tactical CPDLC Scenario
In the following sequence, three aircraft are involved in the sequences and CPDLC is being
used for immediate separation purposes, with dependencies between the clearances.
This scenario is one of those used by OPLINK in definition processes for the ATN
requirement and solution. It therefore shows the hazard envisaged by that ICAO Panel.
This scenario is not in keeping with the currently stated operational concept for air/ground
datalink in congested airspace (i.e. CPDLC for strategic use only, with voice used for tactical
communications.
A.3.11.1 Sequence
No.
1
2
16/02/2016
ATSU
Aircraft
Uplink “climb to and maintain
[FL390]” to aircraft 1
Comment
Aircraft 1 now at
FL370.
From aircraft 2 “request to
climb to FL370”
Draft 0.4
Aircraft 2 now at
FL350
22
Conclusion and Recommendations
No.
3
ATSU
Aircraft
Uplink “maintain [FL350] and
await further instructions” to
aircraft 2
4
5
7
An
alternative
response
would
simply be “Unable”.
Aircraft 1: Receives and
‘Wilco’s’ “climb to [FL390]”
Uplink “climb to and maintain
[FL370]” to aircraft 2.
6
Comment
Climb
begins.
Controller
observes start of
climb
on
SSR
though no ‘Wilco’
received yet.
Does so on the
basis of observing
SSR
climb
on
aircraft 1, above.
Aircraft 2: Receives and
‘Wilco’s’ “climb to [FL370]”
Uplink “climb to and maintain
[FL350]” to aircraft 3.
Climb
begins.
Controller
observes start of
climb on SSR, but
has
not
yet
received ‘Wilco’.
Aircraft 3 now at
FL330.
Controller does this
on the basis of
observing climb on
aircraft 2, above.
8
Aircraft
2:
Receives
“maintain
[FL350]
and
await further instructions””
Reverts to voice,
but
may
take
action right away
on this clearance
and go back to 350
prior to contacting
the controller.
A.3.11.2 Conclusion
The potential hazard is found at event 8. This case does not apply to the currently defined
operational concept for congested en-route airspace, and assumes a specific response to
the downlink event rather than simply “Unable” which would not result in this confusion.
For other operational concepts, the following observations (not conclusions) are good
starting points for subsequent analysis:
This scenario is a hazard if:
A.
16/02/2016
The controller does not use voice at any stage, despite the complexity of the situation.
TRS164/TW/3/3/43 - Draft 0.4
23
TRS164/TW/3/3/43
B.
The aircrew of aircraft 2 does not use voice prior to executing the second clearance.
C. The controller uses datalink tactically (i.e. for immediate separation purposes). The
potential operational environment envisaged was a holding stack in lower airspace, with
CPDLC used tactically.
D. The controller issues contradictory messages without waiting for a response to the
initial message being contradicted.
E.
The controller does not clarify the above contradiction via voice.
F.
The controller issues multiple clearances dependent upon each other, without waiting
for confirmation of the clearances.
G. No latency check is in place on the aircraft to identify and warn crews of old messages.
The overall conclusion is that the operational viability of this “out-of-sequence” scenario
needs to be clarified. If it proves viable, then a communications-level in-sequence
assurance mechanism appears insufficient to resolve the scenario.
A.3.12 Confusing CPDLC Downlink Scenario
In the following sequence, two downlinks are received out-of-sequence.
A.3.12.1 Sequence
No.
ATSU
Comment
1
Downlink
[FL350]”
“request
2
Downlink
[FL360]”
“request
3
Receives “request [FL360]
and
uplinks
“climb
to
[FL360]”
4
5
16/02/2016
Aircraft
Aircraft
receives
and
‘Wilco’s’ “climb to [FL360]
Receives “request [FL350]”
Message
arrives
out of sequence,
and
controller
wonders if aircraft
wants to descend
now.
Draft 0.4
24
Conclusion and Recommendations
A.3.12.2 Conclusion
The following conclusions can be drawn from the above scenario, as a basis for further
analysis.
1.
The sequence creates confusion, but is not a direct hazard.
2.
In a VHF environment, as in the congested en-route airspace being considered,
reversion to R/T is the simple solution (assuming the controller doesn’t ignore the
request and leave it to the crew to raise it if it’s an issue).
The overall conclusion is that this scenario should be looked at in more detail for other
environments, in particular to discover if a communications-level in-sequence assurance
mechanism that results in removal of the CPDLC channel when out-of-sequence delivery is
detected is appropriate in this case.
A.4
Conclusion
A.4.1
Missing Scenarios?
It’s understood that key, operationally viable, scenarios may be missing from this analysis. If
such scenarios are known, they should be included. Inputs are solicited.
A.4.2
Out-of-Sequence Delivery a Hazard In This Environment?
A.4.2.1
Is it a Hazard?
Out-of-sequence messages are not a hazard in the operational context outlined at A.2
above. As long as CPDLC is being used without dependency between an unacknowledged
clearance and a subsequent clearance, no hazard is apparent.
Just as for voice, the hazard only arises if controllers issue clearances dependent upon
each other, without getting an operational acknowledgement first.
Just as with voice, use of data link to issue multiple clearances, with an unstated
dependency between these clearances, and issuance prior to acknowledgement between
them, is not in keeping with the currently understood operational context for data link in
congested en-route airspace.
Irrespective of the underlying technology and message order assurance mechanisms, such
usage is not recommended without additional operational analysis. As for voice, using data
link in this way requires different procedures and a new end-end safety analysis to examine
the full ramifications of such use. This analysis should include things such as aircrew ability
to access and acknowledge messages outside their order of delivery and, if the hazards
appear to be limited to specific operational environments or ground systems, restrictions on
ground system message issuance prior to previous message acknowledgement.
A.4.2.2
Is Automatic Comm. Channel Removal (abort) a Good Solution?
Automatic removal of the CPDLC or ADS channel on the basis of out-of-sequence delivery
detection does not appear appropriate to this airspace.
This solution reacts to a nuisance occurrence (out-of-sequence delivery), by removing the
communications channel entirely and forcing aircrew and controller to recover all open
dialogues through R/T. This includes dialogues unaffected by the out-of-sequence delivery.
16/02/2016
TRS164/TW/3/3/43 - Draft 0.4
25
TRS164/TW/3/3/43
The result is therefore potentially more of a nuisance, and possibly even a hazard, than the
occurrence that triggered it.
Moreover, unless manual or automatic reconnection is put in place on the ground, the
comm. channel is removed for this flight for the duration of its transit through this and any
other sectors of the ATC Center. Manual reconnection will not always be utilized, even if
available, and automatic reconnection is an expensive undertaking, which brings new safety
hazards to be resolved. In either case, the cost/benefit equation is negatively impacted. The
next ATC Center may also be affected, as the aircrew must now logon to this center and
may have been expecting automatic hand-off.
For this airspace, delivery of the message with clear notification of its out-of-sequence state,
to higher-level automation and/or the controller or pilot involved, may be a better solution.
This would allow the delivery sequence to be dealt with according to its operational
ramifications.
A.4.3
Out-of-Sequence Delivery a Hazard in Other Environments?
If out-of-sequence message delivery is identified as a hazard in other operational
environments:
1. Controlling message sequences within the communications layers appears insufficient.
Additional requirements may be necessary to ensure that in-sequence clearances
cannot be acknowledged out-of-sequence.
2. Controlling message sequences within the communications layers may be overridden at
the higher automation layers through alerting or any number of other requirements
either in the same datalink specifications or in other specifications imposed on the
receiving systems). This should be checked to ensure it would not result in the same
hazard.
3. Controlling message sequences within the communications layers, and removing the
comm. channel on any occurrence of out-of-sequence messages appears to be
inappropriate. It prevents operationally acceptable sequences from occurring without
loss of all communications associated with the link.
Local requirements, preventing issuance of messages prior to confirmation that
the previous message has been received, may be more suitable if the operational
situations driving this requirement are unique to an area or unit.
4. Controlling message sequences within the communications layers, and removing the
comm. channel on any occurrence of out-of-sequence messages, may create new
hazards if the data link channel in question is lost when being relied upon for e.g.
capacity increases or separation reductions. This needs to be analyzed.
5. An alternative, and perhaps more suitable requirement for all environments, may be
along the lines of:
As a general principle messages should be delivered in sequence. If they cannot be,
out-of sequence messages shall be delivered and notified to the recipient as out-ofsequence.
Such a construct would appear to address all the scenarios outlined in this paper.
6.
16/02/2016
A key consideration in defining the solution is to establish the expected rate of
occurrence. This should be done for FANS-1/A as a first step.
Draft 0.4
26