5 ms·

Airbus is known for their "dark cockpit" concept which is similar. Essentially, the presence of indicator lights or icons on MFDs should indicate to pilots that

Airbus is known for their "dark cockpit" concept which is similar. Essentially, the presence of indicator lights or icons on MFDs should indicate to pilots that some action needs to be taken. Ideally, the action needed is the same one done by pressing the button that has lit up. This should make it easier for pilots to identify what needs attention, especially when something abnormal happens. A similar strategy they've taken, which the computing industry could learn from, is a central fault management system which prioritizes any faults or alarms that occur during flight and only minimally alerts pilots (e.g. single warning light) if they do not require immediate attention. Instead of distracting pilots with minor alarms, minor faults are displayed for review after landing, when they are actionable by reporting the problems to maintenance. If an emergency does occur in flight, having all fault indications displayed in one place by severity hopefully makes it faster/easier for pilots to understand the problem.

hilbert42 6y ago
Fair enough, but unfortunately Airbus did not extend that concept to the fault 'system' in the A380. When a Trent 900 engine in Qantas flight 32 exploded and cut through the control lines the pilots were overwhelmed by the amount of error data to the extent that they had considerable difficulty in interpreting the data. https://en.wikipedia.org/wiki/Qantas_Flight_32 https://en.wikipedia.org/wiki/Qantas_Flight_32 In this emergency, it's clear the fault indicators (and the data they supplied) were not fit for purpose. If you get a chance it is worth watching the documentary where the cabin crew discuss the problem. It seems to me that there were other problems too with insufficient redundancy built into the control of the aircraft's ailerons (insufficient resiliency in a critical system) but that's off-topic here.
liotier 6y ago
Same with commands with no output in nominal execution - output only happens in case of error
- kibwen 6y ago
  This one's a little trickier to apply: if e.g. I'm executing a command to update some rows in a database, a successful execution can tell me how many rows were changed. If the number seems too high or too low, that's useful for setting off my own internal alarms that something might have been wrong with my query.
- scottLobster 6y ago
  Which is kind of a dark pattern for anything even a little time consuming. A pilot can tell just by looking out the window/flying the plane as to whether the plane is moving. Software however can hang up for all sorts of reasons and never complete execution. You might be waiting on a network timeout for an hour because some didn't code that piece properly, or some random hardware error causes a stall. Reasonable visibility into the real-time operations of the program is useful for the same reasons package tracking numbers are useful.
  - inamberclad 6y ago
    > A pilot can tell just by looking out the window Not in IMC
    - t0mas88 6y ago
      Then by looking at the PFD
      - AceyMan 6y ago
        I first read that as "by looking at the PNF", which almost makes sense. If the first officers eyes are bulging out of his skull, you clearly have a problem... :-D
        t0mas88 6y ago
        Hahaha, and if he's hanging from his seatbelts you're either pulling negative G's or flying upside down ;-)
  - saagarjha 6y ago
    One extremely useful debugging "superpower" is just to sample a process when its hung–the stack trace can often give you a good idea what it is doing, even if the UI doesn't.
    - hashhar 6y ago
aeternum 6y ago
If the fault can be resolved by pushing a button and the system knows which button, why not remove the button entirely? If a human decision is needed before pushing the button then there may be some risk in making it too easy since the human will just push any lit up button.
- ponker 6y ago
  There are situations where the system is 90% sure that something is correct but needs the pilot to confirm. For example, you start flying off your planned course. Should it correct automatically? Probably not, there might be a reason the pilot is doing this.
- droffel 6y ago
  > If a human decision is needed before pushing the button then there may be some risk in making it too easy since the human will just push any lit up button. Pilots receive training before they fly a plane, these are not laypeople.
  - aeternum 6y ago
    Ideally yes, but as we saw with the 737-MAX the training isn't always available or correct even in the aviation industry (and if they can't get it right then other industries have little hope). I'd argue a better UX would be to light up two or more buttons making the potential decisions more clear. Might be even better to use a touchscreen so that more context can be provided.
- jcrawfordor 6y ago
  I think one easy example to think about is a landing configuration alarm. This usually sounds when the altitude is below a certain altitude (must be landing) but the flaps are up (or something else is not according to the handbook landing instructions). Could also be landing gear up but I think that was a common enough problem that newer commercial aircraft tend to have a dedicated "gear not down" alarm just for that case. It's a situation where there's a pretty clear action to be taken (extend flaps) but that change will meaningfully impact flight dynamics, will need application of elevators and changes to trim, etc. and so changing it without pilot input could be a real hazard. I think a lot of more subtle situations fall into the same category of there being a pretty clear corrective action, but the pilot needs to have positive awareness of when that change occurs, and may decide to delay action or do something else. We can pretty easily draw analogy to this kind of thing in computing. Database migrations are one I've run into - nice for them to be completely automated in routine situations, but because they can result in downtime or old versions not working in some cases it's a good idea to run migrations with an engineer "in the loop" for uptime critical software. If it's automated they click the button and do nothing, but having the button to click ensures that they're aware of the change and present in case of problems.
ahartmetz 6y ago
In well-designed old style cockpits, all indicators pointed upwards when their value was nominal. Same idea.
- dTal 6y ago
  What cockpits are these? Analog dial cockpits have been standard since WW2 if not before, and consist of: - Attitude indicator (no needle, horizontal when straight and level) - Altitude indicator (vertical at 0 feet) - Airspeed indicator (vertical at 0 knots) - Turn and slip indicator (horizontal when straight and level) - Directional Gyro (always vertical, numbers on rim rotate) - Vertical Speed indicator (horizontal when neither climbing or descending) I struggle to come up with a single instrument in which vertical is a desirable direction to indicate, during flight.
  - heelix 6y ago
    Oil temp and vacuum for me. Only 1950's, so not quite WW2 vintage. :P
  - GauntletWizard 6y ago
    Oil pressure. Engine temperature. Pump operating speed. All of the things which used to be the domain of the flight engineer but have since been phased out by automation.
  - OnlyOneCannolo 6y ago
    None of those things have a fixed nominal value. They're not health indicators.

hilbert42 6y ago

Fair enough, but unfortunately Airbus did not extend that concept to the fault 'system' in the A380. When a Trent 900 engine in Qantas flight 32 exploded and cut through the control lines the pilots were overwhelmed by the amount of error data to the extent that they had considerable difficulty in interpreting the data. https://en.wikipedia.org/wiki/Qantas_Flight_32 https://en.wikipedia.org/wiki/Qantas_Flight_32 In this emergency, it's clear the fault indicators (and the data they supplied) were not fit for purpose. If you get a chance it is worth watching the documentary where the cabin crew discuss the problem. It seems to me that there were other problems too with insufficient redundancy built into the control of the aircraft's ailerons (insufficient resiliency in a critical system) but that's off-topic here.

liotier 6y ago

Same with commands with no output in nominal execution - output only happens in case of error

kibwen 6y ago
This one's a little trickier to apply: if e.g. I'm executing a command to update some rows in a database, a successful execution can tell me how many rows were changed. If the number seems too high or too low, that's useful for setting off my own internal alarms that something might have been wrong with my query.
scottLobster 6y ago
Which is kind of a dark pattern for anything even a little time consuming. A pilot can tell just by looking out the window/flying the plane as to whether the plane is moving. Software however can hang up for all sorts of reasons and never complete execution. You might be waiting on a network timeout for an hour because some didn't code that piece properly, or some random hardware error causes a stall. Reasonable visibility into the real-time operations of the program is useful for the same reasons package tracking numbers are useful.
- inamberclad 6y ago
  > A pilot can tell just by looking out the window Not in IMC
  - t0mas88 6y ago
    Then by looking at the PFD
    - AceyMan 6y ago
      I first read that as "by looking at the PNF", which almost makes sense. If the first officers eyes are bulging out of his skull, you clearly have a problem... :-D
      - t0mas88 6y ago
        Hahaha, and if he's hanging from his seatbelts you're either pulling negative G's or flying upside down ;-)
- saagarjha 6y ago
  One extremely useful debugging "superpower" is just to sample a process when its hung–the stack trace can often give you a good idea what it is doing, even if the UI doesn't.
  - hashhar 6y ago

aeternum 6y ago

If the fault can be resolved by pushing a button and the system knows which button, why not remove the button entirely? If a human decision is needed before pushing the button then there may be some risk in making it too easy since the human will just push any lit up button.

ponker 6y ago
There are situations where the system is 90% sure that something is correct but needs the pilot to confirm. For example, you start flying off your planned course. Should it correct automatically? Probably not, there might be a reason the pilot is doing this.
droffel 6y ago
> If a human decision is needed before pushing the button then there may be some risk in making it too easy since the human will just push any lit up button. Pilots receive training before they fly a plane, these are not laypeople.
- aeternum 6y ago
  Ideally yes, but as we saw with the 737-MAX the training isn't always available or correct even in the aviation industry (and if they can't get it right then other industries have little hope). I'd argue a better UX would be to light up two or more buttons making the potential decisions more clear. Might be even better to use a touchscreen so that more context can be provided.
jcrawfordor 6y ago
I think one easy example to think about is a landing configuration alarm. This usually sounds when the altitude is below a certain altitude (must be landing) but the flaps are up (or something else is not according to the handbook landing instructions). Could also be landing gear up but I think that was a common enough problem that newer commercial aircraft tend to have a dedicated "gear not down" alarm just for that case. It's a situation where there's a pretty clear action to be taken (extend flaps) but that change will meaningfully impact flight dynamics, will need application of elevators and changes to trim, etc. and so changing it without pilot input could be a real hazard. I think a lot of more subtle situations fall into the same category of there being a pretty clear corrective action, but the pilot needs to have positive awareness of when that change occurs, and may decide to delay action or do something else. We can pretty easily draw analogy to this kind of thing in computing. Database migrations are one I've run into - nice for them to be completely automated in routine situations, but because they can result in downtime or old versions not working in some cases it's a good idea to run migrations with an engineer "in the loop" for uptime critical software. If it's automated they click the button and do nothing, but having the button to click ensures that they're aware of the change and present in case of problems.

ahartmetz 6y ago

In well-designed old style cockpits, all indicators pointed upwards when their value was nominal. Same idea.

dTal 6y ago
What cockpits are these? Analog dial cockpits have been standard since WW2 if not before, and consist of: - Attitude indicator (no needle, horizontal when straight and level) - Altitude indicator (vertical at 0 feet) - Airspeed indicator (vertical at 0 knots) - Turn and slip indicator (horizontal when straight and level) - Directional Gyro (always vertical, numbers on rim rotate) - Vertical Speed indicator (horizontal when neither climbing or descending) I struggle to come up with a single instrument in which vertical is a desirable direction to indicate, during flight.
- heelix 6y ago
  Oil temp and vacuum for me. Only 1950's, so not quite WW2 vintage. :P
- GauntletWizard 6y ago
  Oil pressure. Engine temperature. Pump operating speed. All of the things which used to be the domain of the flight engineer but have since been phased out by automation.
- OnlyOneCannolo 6y ago
  None of those things have a fixed nominal value. They're not health indicators.