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

From: Bernd Sieker < >
Date: Sun, 21 Jun 2015 14:58:37 +0200


-----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_xxxxxx >

-----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-----



The System Safety Mailing List
systemsafety_at_xxxxxx Received on Sun Jun 21 2015 - 14:58:49 CEST

This archive was generated by hypermail 2.3.0 : Thu Apr 25 2019 - 04:17:07 CEST