Side sticks and shared situational awareness

27/07/2011 — 3 Comments

Why something as simple as control stick design can break an aircrew’s situational awareness

One of the less often considered aspects of situational awareness in the cockpit is the element of knowing what the ‘guy in the other seat is doing’. This is a particularly important part of cockpit error management because without a shared understanding of what someone is doing it’s kind of difficult to detect errors.

Now as Endsley the father of Situational Awareness (SA) theory points out sharing a common understanding of a situation requires ‘devices’ to ensure that the crew are working from a common set of information as a prerequisite.

When we consider crew flight control inputs, though perhaps not immediately recognisable, a traditional device used to share information in the cockpit is the ‘old school’ central style pilot control stick or yoke.

In traditonally laid out cockpits where the two controls were interlinked the Non Flying Pilot (NFP) could use his control to visually determine what the control inputs were being applied by the Flying Pilot (FP). As is fairly obvious the location of the control in the central FOV of the NFP also ensured maximum attensity.

Additionally by putting his hands on the stick or yoke the NFP could also obtain a direct kinesthetic feedback as to what the FP’s force inputs were as well. Useful under high workload conditions where eyes might be busy elsewhere in the cockpit.

Enter the glass cockpit’s side controller, such as we see in the current Airbus A3X cockpit designs. From a design perspective this is treated as a single operator input device and because of this does not provide force or displacement feedback cross cockpit with the result that the shared kinesthetic cue of traditional central control yokes have been lost.

Compounding the problem the location of the controller’s on the ouboard side of each pilot’s seat significantly reduces the visual attensity of the controller’s handgrip position.

In fact the location of the hand controllers, determined by the arm’s neutral seated grasp position requires the field of regard of the NFP to lower further down into the cockpit in comparison to a central yoke control.

… The commander commented that although he realised that the landing was not going to be normal, he was aware that it was impossible to “watch the sidestick all the time”. He stated that he “always liked to try”, but “usually failed” to watch the sidestick inputs effectively, because he “liked to see what was going on outside”…

AAIB Bulletin 6/2009, Airbus A321-211, G-DHJH , Manchester hard landing incident

In the Manchester incident quoted above for example, while the PF commenced his flare at the right time subsequent analysis of the FDR found that his pitch up control input was simply too small, something hard to detect from the other side of the cockpit.

The thing to remember about side stick controls is that they evolved first in single seat fighter aircraft in which shared SA was simply not an issue. In the context of fighter combat having a controller that only requires small displacement inputs (i.e is sensitive) is an advantage when working under high G manouevres and in reacting quickly as part of ACM. A side located controller also simplifies the ejection envelope design problem and allows better visibility of centre line mounted displays.

However the operational advantages of a side controller in a multi-crew passenger aircraft are I believe less certain. While it certainly reduces cockpit clutter is a more sensitive controller really required or desirable? At the end of the day the provision of a side controller may have more to do with reducing the cost and complexity of the control interface than any clear operational advantage.

Unfortunately the unintended result of translating that control interface into a different operational context and not recognising that the central control stick served more functions than just a control input device is a loss of shared common information in a multi-crew environment.

From an error detection perspective this means that the NFP has a much less immediate idea of what the FP is inputting to the controls. In addition to find out requires active communication between the crew which requires attentional resources, that may well be in short supply during an in-flight emergency.

So over all I’d expect that side stick fitted cockpits would have a greater likelihood for undetected flying pilot errors especially when the other members of the crew have had have their attention fully engaged in dealing with an emergency, which may go some of the way to explaining why the sustained control back inputs made by the pilot flying on AF 447 were unchallenged by the other members of the crew.

This post is part of the Airbus aircraft family and system safety thread.

Postscript. Providing cross cockpit feedback of what the flying pilot is doing does not automatically mean a return to the traditional and, let’s admit it, somewhat clunky, central control yoke design either. It would actually be quite simple to provide an ‘illuminated bar’ display adjacent to each controller grip to indicate what the displacement input was on the active controller.

3 responses to Side sticks and shared situational awareness


    I understand the issue you have raised here and they are not new.

    But the point you miss is that:

    1. The position of the sidestick or yold (777) does not indicate the position of any flight controls. The sidestick-yolk (777) is mearly one (of many) inputs into a flight control computer.

    2. For the same reason that the sidestick provides no feedback from the flight controls, feedback from the other pilot is less important.

    3. Just as the position of a thruist lever means nothing in practice (its the thrust guage that tells you the REAL thrust), so the stick position versus fligh path relationship is also irrelevant.

    4. Rule 1 of commanding a FBW aircraft – you don’t care or know what inputs the other pilot of flight control computers are making, you only know whether the flight path is acceptable. If the flight path is not acceptable, then it is the pilot’s responsibility to take over (from the AutoPilot or other pilot) and correct the flight path.

    In summary, the automation provided by FBW (which is truely remarkable (especially in providing trick to reduce the VMCG speed and subsequent performance) comes at the cost of requiring the pilot to know how to fly the aircraft when the FBW reconfigures.

    An average conventional pilot is a busy and average pilot. However an average FBW pilot is probably not moving much (when everything is normal) and an inherent danger when the FBW fails and the aircraft reverts to a more direct law.

    Air Traffic Control agencies refuse to endorse advanced and automated ATC systems that can double the traffic but that do not degrade gracefully when the power lug is pulled.

    However in the air, we have pilots getting ever less training to work in more complex and automated aircraft without (I think) sufficient knowledge, training and experience to understand how to fly these complex machines when the automatics fail.

    FBW is fantastic, but only in the right knowledgable hands. It should never be suggested that FBW (thouroughour all its modes and reversions) is easy!

    Not everyone can drive a racing car – and not every pilot will be a good FBW pilot. But a good FBW pilot can achieve great things.

      Matthew Squair 27/07/2011 at 5:34 pm

      Richard, thanks for your comments.

      In response you are right that while protection laws are working the automation provides the safety net either warning the pilot (as per Boeing) or constraining (as per Airbus). A problem with this paradigm is that when the normal flight protections are lost (as happened in AF 447) who is ‘riding shotgun’?

      Another problem comes about when you can put hazardous inputs into the controls and the flight laws don’t (are not designed to) catch them. For example if I’m landing and don’t pull the nose up in a flare I can land nose gear first which is extremely dangerous. I know of one instance where a pilot (flying a FBW side controller equiped aircraft) was found to be persistently carrying out this action. This ‘routine’ violation was only found after a particularly punishing landing caused significant nose gear damage. CRM is about picking up these sort of errors, very difficult when you’re not interacting with the other pilot.

      I actually don’t differentiate between the automation and crew when considering CRM, I find this helps clarify the discussion. If the automation mediates communication between crew that mediation should support a common understanding between FP, NFP and computer of what is going on. In the case of AF447 did the NFP and captain understand that the FP was putting in persistant control back inputs? Should they have to ask?

      A fundamental question, should we design systems to support aircrew in maintaining a common understanding of the situation because that is necessary when the automation fails? My answer is yes, I see providing this ‘added’ redundant communication as a bit like structural design margins, while it’s not necessary under normal conditions, when an unexpected event occurs you rely upon it..

      Although I didn’t emphasise the point in the post, a final issue for me is that with computers there has been a significant shift of data into the visual/audio channel, so while ‘in the olden days’ you could get a physical feel from control displacement or force feedback this information has tended to migrate into the visual/uadio channels which has the potential at times of crisis to overload that sensory channel.

      Despite the added complexity I think there are very good cognitive engineering reasons to spread information inputs over several channels (and redundantly across channels). An example of this is the ‘stick shaker’ feedback versus the audible ‘stall warning’ versus a flashing ‘stall’ indicator on a glass panel.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s