Comment by jcrawfordor | Hacker News Reader

Comment by jcrawfordor | Hacker News Reader

Parent Full thread

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.

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

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.

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.

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.

I've recently learnt this trick too but am having a hard time manually diffing stack-traces. Do you know of some tool that can help me analyze samples of stack-traces?

"Analyze samples of stack traces" is what a profiler does. Can you feed such information into a profiler (such as pprof or perf-report)?

On macOS I just use Activity Monitor's sampling tool, which gives me the hottest stack trace. Something similar probably exists for other platforms? If not, you can emulate it poorly by attaching a debugger and repeatedly interrupting execution and seeing if anything shows up many times–if your program is truly stuck, it will generally be easy to see why because it'll show up in all your traces.

One of the first things humans discovered about flight is that you can't trust your senses.

Yes, but you can trust your senses enough to tell you're in the air and not yet dead.

Software with no output doesn't give you even that.

> A pilot can tell just by looking out the window

Not in IMC

Then by looking at the PFD

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

Hahaha, and if he's hanging from his seatbelts you're either pulling negative G's or flying upside down ;-)

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

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.

Oil temp and vacuum for me. Only 1950's, so not quite WW2 vintage. :P

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.

None of those things have a fixed nominal value. They're not health indicators.

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.

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

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.

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.

I think you touch on what might be an easier example to demonstrate with here:

"GEAR NOT DOWN"

So the plane has determined you are close to the ground, but the landing gear is not extended.

What is the proper course of action?

If you're trying to land on a runway or other normal surface (i.e., 99 cases out of a hundred type of thing) the appropriate action would be to extend the landing gear.

In that other case though, extending the landing gear in preparation for something like an emergency water landing is certain to take something which has a surprisingly good survival rate and turn it into a mass casualty event.

So we're left with the choice between "do the usual thing automatically, and rely on the pilot to remember to override it in the rare event of an emergency" or "alert the pilot and rely on them to evaluate whether it's the right thing for their current situation and conditions".

I would definitely argue for the latter. Especially in this specific example increasing cognitive load during exceptional situations to make the unexceptional more convenient is probably not what we want to do. The plane is not aware of the actual situation the plane is in. The pilot is.

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.

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

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.

Reply on news.ycombinator.com