Safety in design is an important aspect of avoiding disasters.

Developing a specification for a boat has complex inter-related design issues. These must be resolved with safety and performance uppermost. Resolution should be based on robust systems to mitigate risks, and provide contingency fall backs and the capability to recover from disasters. These systems should be loosely, not tightly, coupled.

At the outset, you must understand your main design goal – the intended use of your boat in a safe and effective manner – and price/performance range. The overall design and finish should conform to tradition (e.ggram., wood interiors), a reasonable degree of luxury and practicality (e.g., non-slip deck instead of high-maintenance teak), innovation, and provide a robust set of mechanical systems meeting international and industry standars.

Ideally, robust systems are completely independent with redundant backup.^[1][2] Where they must be interdependent, they are loosely coupled (mutually independent or well separated). This can be expressed as a variant of Occam'sSecond Razor: ^[3] “Do not needless multiply dependencies among the parts of a system.” ^[4] In tightly coupled systems, the loss of one component can bring down others. In a loosely coupled system the opposite is true.

Well separated has two meanings in this context:

• Interdependent systems are well separated if their interface is loosely coupled.
• Independent systems in close proximity are tightly coupled if they can damage each other.

For example:

• AAmpere (amp), SI unit of electrical current gearbox in the sump of an engine that shares engine oil is more tightly coupled than a separate gearbox attached through a clutching mechanism.
• A water hose running next to the electrical panel is tightly coupled.

The water hose is an example of systems that interact in unexpected ways.

Robust systems have time for recovery: a fuel system that you can switch to a second set of filters if one set clogs is an example where redundancy provides time to fix the problem without incurring a disaster.

Robust systems also provide a lot of information about their true state. A ball cock valve that rises when it is opened is better than a fancy modern type where you can’t tell from the handle whether it is open or closed.

A temperature sensor and indicator that fails to zero is better than one that fails to ‘overheated’. If the water temperature gauge on your engine fails and drops to zero, it won’t take long to figure out that everything seems normal and that you have time to figure things out. If it fails in the other direction, you might be panicked into shutting down the engine. Maybe you skimped on the size of the house bank, and this happened just as the alternators were going to kick in. Now you have an engine shut down and dangerously low batteries. Next…well you get the picture.

You can reduce the probability of an operational disaster by analysing a dependency tree. Systems that are mutually dependent on a common subsystem are easy to identify so, in particular, look for systems that interact in unexpected ways.

Many boats supplement diesel propulsion with propane in the galley. Propane is much cleaner than diesel, and easier to cook with. It's also more explosive. While diesel will burn, it will not explode. Diesel flashes at 100-160 °Fdegree Fahrenheit, depending on the grade, while propane flashes at -156 °F. (An alternative is to use ACAlternating current if you have enough electrical power.)

Safety at sea is paramount. Ideally, a boat should be:

• Easy to drive under storm conditions
• Self-righting from a knockdown of 90-130 degrees (65-70 is the norm in the industry)
• Able to withstand an accidental grounding

Finally, don’t ignore security. Unrest and piracy are on the increase.

References

1. ↑ Normal Accidents, Charles Perrow, Princeton University Press; Updated edition (September 27, 1999), ISBN 0691004129
2. ↑ What Went Wrong?: Case Studies of Process Plant Disasters, Trevor A. Kletz, Gulf Professional Publishing; 4 edition (June 23, 1998) ISBN 0884159205
3. ↑ . “One should not increase, beyond what is necessary, the number of entities required to explain anything”, William of Occam (1285-1349), http://pespmc1.vub.ac.be/occamraz.html
4. ↑ Kendall Grant Clark, Reviewing Web Architecture, http://www.xml.com/pub/a/2004/02/11/deviant.html