[SystemSafety] Fwd: Re: Chicago controller halts Delta jet's near-miss....

[Bernd Sieker]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 21.06.2015 10:36, Peter Bernard Ladkin wrote:
> On 2015-06-21 01:28 , Les Chambers wrote:
>> It seems to me that the ATC - Pilot voice protocol is missing a
>> step. ... In concept, a safer protocol might look like this: ATC:
>> You are cleared for takeoff Pilot: My understanding is that I am
>> cleared for takeoff ATC: Your understanding is correct
> 
> This misses crucial information, namely addressing, which is
> critical in a multiuser broadcast context. A clearance is preceded
> by a call sign, and an ACK is succeeded by the call sign. Call 
> signs may be abbreviated, which can lead to confusion when the
> abbreviations are close, and when transmissions are stepped on,
> which might have been the case in the incident in question. So
> let's correct for call signs, and translate into the standard
> ATC-aircraft controlled language. What you suggest is:
> 
>> [1] ATC: [call sign] Cleared for takeoff [2] CRW: Cleared for
>> takeoff [call sign] [3] ATC: [call sign] Affirmative

The takeoff clearance must also always include the runway; starting
somewhere around 2009 ICAO phraseology has the runway designation
before the "Cleared for takeoff", but that is not universally
observed. In general, the call sign should precede the call, but on
short readbacks it is acceptable to say the call sign at the end.

So, [1] ATC: [call sign] <[further instructions]> <[wind]> [runway
designation] Cleared for takeoff, [2] <[further instructions]> [runway
designation] Cleared for takeoff [call sign]

The runway designation in this case was part of the clearance, the
readback was stepped on, so we don't know, CVRs will help here.

Sylvia Wrigley's blog "Fear of Landing" has an interesting page where
she has collected some known facts (including the relevant snippets
from LiveATC) and her own observations:

http://fearoflanding.com/accidents/details-of-the-frightening-near-miss-at-chicago-midway/

As far as we can tell, in this case, [1] is missing the callsign
altogether. After both acknowledge at the same time, [1] is repeated
in a very rapdfire voice. (the clearance was already qualified "no
delay", because another aircraft was on final for 04) The transcript
above reads as if the request for clearance verification was then
preceded by SouthWest's callsign, abbreviated to "thirty-eight
twenty-eight", but I cannot understand that.

Normally, saying both the runway and the callsign creates some
redundancy, as normally only one aircraft should be ready for
departure on any one runway. Except that sometimes this is not the case:

Recently in Hannover, I was told to "line up and wait" (in our little
Socata MS880) on runway 09R at an intersection, and I could hear that
a 737 was also told to "line up and wait 09R" at the threshold. So
there were now two aircraft lined up and ready on the same runway at
the same time, where we sat waiting for some 4 minutes. (The reason
for the delay was an ambulance helicopter that had been given
clearance to fly directly to the apron across the runway.) All went
well for us, but it was a (very) slightly worrying feeling to know a
big jet was sitting behind me which I couldn't see.


> 
> Steps 1 and 2 are required. Step 3 is not; if Step 2 is not
> correctly executed, then Controller will respond:
> 
>> [1] ATC: [call sign] Cleared for takeoff [2] CRW: Cleared for
>> takeoff [other call sign] [3] ATC: <other call sign> Negative
>> [other call sign]
> 
> or
> 
>> [1] ATC: [call sign] Cleared for takeoff [2] CRW: Cleared for
>> takeoff [other call sign] [3] ATC: [other call sign] Negative
>> [other call sign]; <[call sign] Cleared for takeoff>
> 
> which, if you analyse it, works just as well, and is more
> efficient. (the "<...>" indicates an optional expression.) Don't
> forget that this may be interspersed with other transmissions, for 
> example
> 
>> [2'] CRW: Cleared for takeoff [call sign]
> 
> in which case the option will not be exercised.
> 
> There is no good reason for a controller to ACK a correct readback,
> and it would complicate matters cognitively when transmissions take
> up almost all the air time, which often happens at a major
> airport.
> 
> Further, complete expression as whole phrases doesn't illustrate
> the resilience of the language in the face of partial obscuration,
> which is an important feature.
> 
> Cushing (op. cit. antea) provided a grammar for such communications
> in his book. Cushing is a linguist, but his grammar was partially
> incorrect and also structurally more complex than need be. 
> Twelve-thirteen years ago, some people working with me fixed it.
> See Review of the Cushing Grammar, by Martin Ellermann and Mirco
> Hilbert at 
> http://www.rvs.uni-bielefeld.de/publications/Papers/hillermann-critique.pdf
> and Building a Parser for ATC Language, by the same authors, at 
> http://www.rvs.uni-bielefeld.de/publications/Papers/hillermann-critique.pdf
>
>  PBL
> 
> Prof. Peter Bernard Ladkin, Faculty of Technology, University of
> Bielefeld, 33594 Bielefeld, Germany Je suis Charlie Tel+msg +49
> (0)521 880 7319  www.rvs.uni-bielefeld.de
> 
> 
> 
> 
> _______________________________________________ The System Safety
> Mailing List systemsafety at TechFak.Uni-Bielefeld.DE
> 

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJVhrT9AAoJEPCgtsw5k0hSfjAIAKJIwds4BNuRy5oE5Fo2xVmv
gTf2tmOz7AhZL8ltLJVjkj+E/43Hw6j+hqi0JZrFQ3E2277s3MtpdTaJUkUL4WZm
Sd4M2yhUXGp4KHvyejUHKPQ42Ij0sGRpMtL9NmzQ8BCOBbTvPHTsMBGb5qPYIYmK
R+bIqxOqZlppDyX4s2z7yA/bf8RS6pyhdDD9Vp3wbxZlsH0oTwdENm7va/1nb9Z1
JFSKUJf1xqjLFI0HS0eULMPY0IL26OESdKZrJhgj3QFkm5AdBasBKSkruRFzmova
2v24tBBpzyGSy4/b+qqBQ0dlCcWhZD93IrDE/KfsfhlZx8Kew4qfEtVKtLsonl4=
=n+Os
-----END PGP SIGNATURE-----