Failure mode effect analysis (FMEA) is done early in the design phase along with root cause analysis. In the example of the ship grounded, not sure why the captain decided to sail closer to the shore, however, auto navigation should have shown the safe level for the correct depth.
"Expect the best, but prepare for the worst" certainly seems to apply in this situation. While we can not prepare for scenarios yet unimagined, it certainly makes sense to prepare for known risks. However, the human element will always be an uncontrollable variable. I designed a test set that required a cylinder to come down with some force over the test bed. In order to prevent the operator from inadvertently getting a finger smashed, I used two thumb switches and programmed it so that both switches must be blocked in order for the test to run and the cylinder to actuate. One of the engineers informed me after their visit to the plant it was installed at, that the workers had simply stuck a glove to block the thumb switch sensor on one side - totally negating my built in safety design. I guess I should have anticipated the human element, but one can only go so far in anticipating the actions of those who will be operating the equipment...
Excellent article, Prof Petroski. I read an article recently about the Titanic's maiden voyage. Apparently the crew was warned there were icebergs in the area by a ship that had just moved through the area the Titanic was heading toward. The crew of the Titanic even acknowledged the warning.
A big part of my work involves analyzing failures after they happen. (Fortunately, most of the time they're failures which occur during in-house testing, not in the field). The rest of my work involves trying to apply these lessons to prevent failures from happening in the first place.
It's not only important to learn from failures -- it's important to learn the correct lessons from failures. Whenever you are trying something new, if anything goes wrong, the knee-jerk reaction is to blame whatever is new in the design. For example, if you are trying out a plastic bearing and you experience a failure, many people will conclude that plastic bearings are simply no good. Then, for the next decade, if anyone suggests using a plastic bearing, the response will be, "We tried that before and it didn't work."
There's also a tendency to throw the kitchen sink at a problem. Often, when a part fails, different engineers may suggest three or four possible changes to the design or manufacturing of the part which might (or might not) fix the problem. There may be pressure from management to "just get it fixed," which might mean implementing all of the changes at the same time and hoping one of them works.
Sometimes, this results in the problem going away, and the engineers look like heroes to management for solving the problem in such a timely manner. But really, nothing has been learned. Worse, in the tribal knowledge of the engineering organization, one of the changes which actually had no effect may undeservedly get the credit for fixing the problem. Once this becomes part of the conventional wisdom, it may prove very difficult to dispell.
Finally, I'd like to point out that wishful thinking is not a successful design strategy. Occasionally, when a failure occurs, people try to convince themselves that the conditions under which it occurred were so unique that it will never repeat itself. This is especially true of failures which occur in testing, where there's a tendency to attribute any difficult-to-explain failures to the test method and assume they won't happen in the real world. If that's really the case, then you should try to come up with a more representative test method. But in any case, if you're arguing that a failure should be ignored, you'd better make damn sure you're right.
The Titanic disaster is a result of too many flaws stacked up to survive. Eliminate any one of the flaws, and the result would be vastly different. Had the bulkhads been full-height, the progressive flooding would not have occurred. Had there been enough lifeboats, the loss of life would have been minimal. Had the captain chosen to slow down in poor visibility conditions, the collision could have been avoided or been inconsequential.
Professor Petroski's point that lessons are learned from the failures is accurate: the SS Andrea Doria / MS Stockholm disaster proves it. The Andrea Doria was unable to launch half her lifeboats due to severe listing, but the ship's better design permitted it to stay afloat for 11 hours, allowing other ships to arrive in time to rescue all aboard. Only the design helped; having enough lifeboats wasn't enough to prevent loss of life.
There were lessons not learned though: the collision still occurred in low visibility conditions.
Even TODAY, ship collisions occur in fog, despite shipboard radar and GPS technology:
This quickly turns into a discussion of ethics. "Proactive Failure Analysis" should have predicted the Tylenol poisonings which created the safety sealing industry. A broken red lens on a train signal should have predicted the folly of using "white means go" for traffic signals. O-Ring elasticity measurements should have prevented the loss of the Challenger, and research into the toxicity of poly-alcohols (sugars) should have pointed to an epidemic of diabetes and heart disease.
We should always be mindful of risk analysis, but unless we are willing to live in the society described in Minority Report, perhaps the best thing we can do is learn the truth of our mistakes quickly and incorporate those lessons as we continue to evolve our technology...
Robots that walk have come a long way from simple barebones walking machines or pairs of legs without an upper body and head. Much of the research these days focuses on making more humanoid robots. But they are not all created equal.
The IEEE Computer Society has named the top 10 trends for 2014. You can expect the convergence of cloud computing and mobile devices, advances in health care data and devices, as well as privacy issues in social media to make the headlines. And 3D printing came out of nowhere to make a big splash.
For industrial control applications, or even a simple assembly line, that machine can go almost 24/7 without a break. But what happens when the task is a little more complex? That’s where the “smart” machine would come in. The smart machine is one that has some simple (or complex in some cases) processing capability to be able to adapt to changing conditions. Such machines are suited for a host of applications, including automotive, aerospace, defense, medical, computers and electronics, telecommunications, consumer goods, and so on. This discussion will examine what’s possible with smart machines, and what tradeoffs need to be made to implement such a solution.