The recent grounding of the cruise ship Costa Concordia is a tragic reminder that even a vessel equipped with the latest instruments of technology is not guaranteed safe passage through threatening waters. The human element, embodied in this case in the ship captain's decision to sail dangerously close to shore (something reported to have been a not unheard of practice with cruise ships), can always negate technological prowess. Images of the ship resting on its side like a beached white whale showed how vulnerable even something so gigantic can be to the unintended consequences of human nature.
But we seem never to learn; the incident off the Italian coast occurred almost exactly 100 years after an even more tragic marine disaster.
On April 10, 1912, the innovatively designed ocean liner Titanic was heralded as an "unsinkable" success even before the ship left the dock. As we all know, it sank on its maiden voyage. But now, a century later, let us engage in a thought experiment.
Let us assume that the Titanic did not have the bad luck of being in the same place at the same time as a giant North Atlantic iceberg. Had the ship not had its unfortunate encounter, it might have reached New York safely, and the success of its design would have been "proven." The more times the Titanic crossed and recrossed the ocean, the more confident the ship's captain, owner, and potential passengers would have become in its extraordinary seaworthiness.
Competing steamship companies would likely have wanted to emulate the Titanic's success, but they would also have wanted to make distinguishing changes that they believed would be improvements, whether for technical, economic, or commercial advantage. Larger, faster, and more opulent ocean liners would then likely have been designed and built. To make them more competitive financially, the newer ships would have been made with thinner hulls and carried fewer lifeboats. After all, the design of their new ship was based on the unsinkable, unsunk, and thus eminently successful Titanic.
But as we know from its colossal failure to reach New York, even the Titanic could not withstand its collision with an iceberg -- a fatal flaw in the ship's design. All subsequent ocean liners whose design was closely based on the supposedly successful Titanic would likely also have had the same latent flaws as their paragon.
In fact, because of the overconfidence in the ship's success, the inevitable use of thinner steel in their hulls would have made the derivative ships even more vulnerable, and the fewer lifeboats would have made any accident at sea potentially more tragic. Chances are, one of these "improved" ships would eventually have had the bad luck of being in the same place at the same time as a fateful iceberg. Only then might the folly of thinner hulls and fewer lifeboats, not to mention a fatally flawed bulkhead design, have become incontrovertibly evident.
Successful change comes, not from emulating success and trying to better it, but from learning from and anticipating failure, whether actually experienced or hypothetically imagined.
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.
That is a huge question, Mydeisgn. They could have slowed down, they could have headed south. They did neither after receiving numerous warnings. He's a minute-by-minute account:
Yes, there is a fine line between anticipating failure and paranoia, and the design must go on. The perfect is the enemy of the good, but the key question is always how good is good enough.
Anticipating failure is great, but the engineer must know the fine line between probable cause and paranoia. At some point the design goes on - fears or no.
But true, arrogance seemed to be part of the Titanic's design criteria.
"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...
Rob, as a part of curiosity I would like to know even though the crew came to know about the iceberg well in advance, why they didn't change the root or any other saftey precautions.
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...
On April 21, NASA launched a novel project, putting into orbit three satellites that employ an off-the-shelf commercial smartphone as the control system.
The legacy endpoint devices that control our critical infrastructure (utility systems, water treatment plants, military networks, industrial control systems, etc.) are some of the most vulnerable devices on the Internet.
In a switched-capacitor filter, capacitors and switches take the place of resistors and accurately reproduce the characteristics of continuous-time Bessel, Butterworth, and elliptical filters.
From Dell / Intel® New Paradigms in Design Work Scott Hamilton, vertical market strategist for Dell Precision workstations, 5/2/2013 5
Early in my career, I worked as a draftsman and remember the days of drawing on vellum with numbered pencils and Mylar with plastic lead. This was a fun experience in the sense that I ...
I've been using workstations for more than 10 years and love finding ways to get more performance from my system. With demanding professional applications that require more power each ...
A lasting memory from my first job as an engineer in an auto assembly plant is standing on hard concrete at six in the morning, vending-machine coffee clutched in hand, listening to ...
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 radio show will show what’s possible with smart machines, and what tradeoffs need to be made to implement such a solution.
To save this item to your list of favorite Design News content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
Tweet This
2 
