If they rebooted it, and it started working again, would you just walk away? Or would you try to figure out why the fuck it needed to be rebooted in the first place?

▲

onefiftymike 9 hours ago | parent | next [-]

The vast majority of the problems were a system that missed the time window to report it's self test. A reboot got things in order.

It was a small fleet, so we had a pretty good idea if the same problem kept popping up so we could look more into that system.

A few fault codes were well known enough that if you called with that one the answer was to shut down and find a hotel, you aren't going anywhere and no reboot will take care of it. (bad detectors in the engines for about 10 years until a redesign)

▲

SoftTalker a day ago | parent | prev [-]

Thales or Collins or Honeywell or whoever provided the system would. The technician at the airport would only follow a procedure listed on a checklist, which probably includes rebooting the system.

▲

cyphar 16 hours ago | parent [-]

Ironically there have been a fair few cases of aircraft incidents where components were reported as bad by pilots but the issue couldn't be reproduced on the ground and "it worked" after a reboot and self-test so they just kept using it (with this cycle repeating multiple times). Often there were clear physical problems (cracked solder joints, stuck microswitches, broken insulation) that were only discovered after a catastrophic failure but could've been discovered with a more inquisitive engineering culture.

I would argue a "just reboot it" culture leads to more problems -- engineers should be empowered to diagnose problems before they become catastrophic. In the world of software we even have mechanisms for extracting data from failed systems to root cause them later, and yet most people do not take that step before "just reboot[ing] it".

[1]: AirAsia 8501, Lauda Air 004, and SmartLynx Estonia 9001 come to mind.

▲

electroweak 13 hours ago | parent | next [-]

But these intermittent failures lead to delays and worse. The sheer cost of repeat events leads to action. If deferrable at all the standard troubleshooting is mostly remove and replace. The repair and reliability processes identify these rogue units fairly fast and the actual rates of that in a well functioning airline are very low.

	▲	SoftTalker 10 hours ago \| parent [-]
		Yes, I remember a flight that sat at the gate past departure time, the explanation to the passengers was that some essential piece of equipment wasn't functioning, they had tried restarting it, and it was going to be replaced. About 30 minutes late, we were on our way.

▲

hgomersall 14 hours ago | parent | prev | next [-]

Right, rebooting only really makes sense if you understand why the reboot is going to fix the problem. As in, corrupted volatile state is reasonably fixed with a reboot. Any hardware issues or persistent state problems could well get worse.

▲

Merrill 14 hours ago | parent | prev [-]

The following is a few decades old --

A physicist, an engineer, and a computer programmer are driving down a steep mountain pass when the car’s brakes fail.

The car speeds out of control around sharp turns, nearly flying off the edge before they miraculously manage to skid to a stop at the bottom.

Shaken up, they discuss what to do next:

• The physicist says: "We need to calculate the friction coefficients in the brake pads and model the temperature rise to figure out why they failed."

• The engineer says: "I have a few tools in the trunk. I’ll take a look underneath and see if I can fix the mechanical failure."

• The programmer says: "Why don't we get back in and see if it's reproducible?"