4 ms·

I disagree from the article. There is no paradox in automation, just a simple sensationalism desire from the authors. Everyday, there are thousands of accident

I disagree from the article. There is no paradox in automation, just a simple sensationalism desire from the authors. Everyday, there are thousands of accidents in the world(mainly cars) just because human errors,like distractions, and if no automation existed there will be dozens of airplane accidents everyday, given the enormous number of flights. It's not human intervention what is needed, it's just something as simple as a proper error reporting system. If an accelerometer fails and nothing happens, just report :ACCELEROMETER FAILED and problem solved. That a GPS failed, just report: GPS FAILED, and problem solved. Just change the redundant accelerometer, GPS when in land-port. This is what human beings do, when one eye-ear-inertial information has nothing to do with the other, we got dizziness sick. If someone designed the system badly, is not fault of automation, it's fault of the engineers. Debugging and testing is important.

RiderOfGiraffes 17y ago
They're not saying that automation doesn't reduce accidents. They are saying that the accidents that occur now are sometimes caused by the human operators becoming deskilled because of the automation. When you say: " ... it's just something as simple as a proper error reporting system." you make it clear that you don't work in automated real-time systems. I do, and it's more complex than you seem to think. I know of a case similar to the grounding of the Royal Majesty. In that case, again, the GPS antenna became disconnected. There was a proper error reporting procedure that was defined and documented, and yet still no one fixed the antenna, and still everyone trusted the AIS/GPS system even though it was reporting as broken. In the same way that Windows users are "trained" to click "OK" on every pop-up dialog, so they were "trained" by their day-in, day-out experience to trust the system even though they'd been told it was broken. You also say: Debugging and testing is important. I don't think there would be many who would disagree with you, but are you suggesting that the systems described had had no debugging or testing? Of course not. They had been debugged and tested. Exhaustively. And knowing something of the field, most likely rather more than you imagine. Bugs remain, and when they surface, humans need to be able to take over swiftly and accurately. Increasing automation makes it less likely that they do so. Even if you've had extensive and intensive training, if you don't use it for six months then you are unlikely to remember it all in an emergency. That's the message of the article, and I endorse it, because I personally have seen it happening.
- xcombinator 17y ago
  Hello I never said it was simple, I say it has to be simple. But the human being is way complex and error reporting are so simple. Simple doesn't mean "easy". IMHO engineers try to do complex systems they don't understand, instead of simpler ones. I have worked in automated real-time systems, and I was not bad at it. And yes, I have seen real industries working with duct tape fixes, hanging cables when there was parts movement,that was a calling for disaster, but I will never take responsibility of it with my handstroke because if I let them go I will go to jail if it happens. I know what is stopping a production chain for doing something the "right way" and having the owners eyes on you while they are losing thousands of euros every not working minute. That is the proper and original meaning of Murphy Law, if you let something to happen, it will. Even when proper training, people do stupid things just because they can when you let them. I had in my family an airplane pilot from the early days when 50% of their colleagues had died from crashes. A friend of him died trying a "macho" demonstration to her girlfriend with his little plane. If you try to do stupid things with a commercial airline, it won't let you unless you deactivate the automation(and give explanation of why you did so).
- skorgu 17y ago
  The issue, then, becomes training. As you say we're used to ignoring entire classes of alert so having a documented process for how to handle specific alert conditions and training with that process isn't comomon. Like any other skill, use it or lose it: train with arbitrary automation failures so the skill of triage is exercised and make sure there is up-to-date documentation that's easily referenced. It's not quite avionics-level but at my work SOP is that every automated process be documented as human-readable text which is easily visible if the automated process encounters an error condition.
deleted 17y ago
[deleted]

RiderOfGiraffes 17y ago

They're not saying that automation doesn't reduce accidents. They are saying that the accidents that occur now are sometimes caused by the human operators becoming deskilled because of the automation. When you say: " ... it's just something as simple as a proper error reporting system." you make it clear that you don't work in automated real-time systems. I do, and it's more complex than you seem to think. I know of a case similar to the grounding of the Royal Majesty. In that case, again, the GPS antenna became disconnected. There was a proper error reporting procedure that was defined and documented, and yet still no one fixed the antenna, and still everyone trusted the AIS/GPS system even though it was reporting as broken. In the same way that Windows users are "trained" to click "OK" on every pop-up dialog, so they were "trained" by their day-in, day-out experience to trust the system even though they'd been told it was broken. You also say: Debugging and testing is important. I don't think there would be many who would disagree with you, but are you suggesting that the systems described had had no debugging or testing? Of course not. They had been debugged and tested. Exhaustively. And knowing something of the field, most likely rather more than you imagine. Bugs remain, and when they surface, humans need to be able to take over swiftly and accurately. Increasing automation makes it less likely that they do so. Even if you've had extensive and intensive training, if you don't use it for six months then you are unlikely to remember it all in an emergency. That's the message of the article, and I endorse it, because I personally have seen it happening.

xcombinator 17y ago
Hello I never said it was simple, I say it has to be simple. But the human being is way complex and error reporting are so simple. Simple doesn't mean "easy". IMHO engineers try to do complex systems they don't understand, instead of simpler ones. I have worked in automated real-time systems, and I was not bad at it. And yes, I have seen real industries working with duct tape fixes, hanging cables when there was parts movement,that was a calling for disaster, but I will never take responsibility of it with my handstroke because if I let them go I will go to jail if it happens. I know what is stopping a production chain for doing something the "right way" and having the owners eyes on you while they are losing thousands of euros every not working minute. That is the proper and original meaning of Murphy Law, if you let something to happen, it will. Even when proper training, people do stupid things just because they can when you let them. I had in my family an airplane pilot from the early days when 50% of their colleagues had died from crashes. A friend of him died trying a "macho" demonstration to her girlfriend with his little plane. If you try to do stupid things with a commercial airline, it won't let you unless you deactivate the automation(and give explanation of why you did so).
skorgu 17y ago
The issue, then, becomes training. As you say we're used to ignoring entire classes of alert so having a documented process for how to handle specific alert conditions and training with that process isn't comomon. Like any other skill, use it or lose it: train with arbitrary automation failures so the skill of triage is exercised and make sure there is up-to-date documentation that's easily referenced. It's not quite avionics-level but at my work SOP is that every automated process be documented as human-readable text which is easily visible if the automated process encounters an error condition.

deleted 17y ago

[deleted]