Overly complex control systems have been the cause of many maritime incidents, including two deadly collisions in the US Navy. Investigations found that these incidents were preventable and the result of multiple failures. In designing new systems, we need to be mindful of the potential for malfunction and outright failure.

 

In 2019 the US Navy took a decision to ditch touch screen controls on its destroyers after investigations implicated the touch screens in two deadly collisions. Surveys found that sailors overwhelmingly preferred the use of wheels and throttles over touch screens to control their ships.

 

The investigations and the surveys were conducted after the USS Fitzgerald was involved in a collision with a container ship off the Japanese coast in June 2017, resulting in the loss of seven lives. Ten more lives were lost when the USS McCain collided with a container ship off the coast of Singapore in August 2017.

 

Investigations found that both incidents were preventable and the result of multiple failures. But overly complex control systems, and touch screens in particular, were fundamental to the cause of both incidents.

 

The US Navy is now employing physical throttle and wheel systems that are replacing the touch screens.The US navy's Rear Adm Galinis is quoted as saying, "We got away from the physical throttles, and that was probably the number one feedback from the fleet. Just give us the throttles that we can use."

 

 

 

An accident involving the crash of a Toyota Camry in 2007 resulted in the death of the passenger and serious injury to the driver who lay unconscious in hospital for over a month. The accident eventually resulted in Toyota recalling more than 9 million cars, and paying nearly $3 billion in settlements and fines related to unintended acceleration.

 

The car had crashed at speed after it failed to slow when the driver took her floor off the pedal.  Toyota initially blamed the crash on faulty floor mats. A ten month long investigation conducted by NASA found that they could not prove the accident was caused by faulty cruise control software, but disturbingly they couldn't prove it wasn't.

 

To quote from an article by James Somers in The Atlantic

 

Michael Barr, an expert witness for the plaintiff, had a team of software experts spend 18 months with the Toyota code, picking up where NASA left off. Barr described what they found as “spaghetti code,” programmer lingo for software that has become a tangled mess. Code turns to spaghetti when it accretes over many years, with feature after feature piling on top of, and being woven around, what’s already there; eventually the code becomes impossible to follow, let alone to test exhaustively for flaws.

 

Using the same model as the Camry involved in the accident, Barr’s team demonstrated that there were actually more than 10 million ways for the onboard computer to cause unintended acceleration. They showed that as little as a single bit flip — a one in the computer’s memory becoming a zero or vice versa — could make a car run out of control. The fail-safe code that Toyota had put in place wasn’t enough to stop it. “You have software watching the software,” Barr testified. “If the software malfunctions and the same program or same app that is crashed is supposed to save the day, it can’t save the day because it is not working.”

 

Software is unmoored from anything physical and is constantly being changed, largely because it can be changed so cheaply. The problem with making things out of code as opposed to making physical things is that the complexity is invisible to the eye. We simply don't have the intellectual capacity to grasp its structural configuration in any way that helps us to detect flaws or potential for error in its design.

 

We increasingly rely on computerized navigation systems and electronic controllers for power systems in our yachts. A jammed halyard lock or faulty navigation system might not have the same dire consequences as the examples above, but in designing new systems we need to be mindful of the potential for failure of the systems. I recall a skipper relating a story of being trapped in the Strait of Malacca off Singapore in the middle of the night, surrounded by ships, with no wind, and with no power for his engines or his lights due to a faulty engine controller. I should mention this was several years ago and it was not one of the electric engine brands currently available.

 

All of the examples above are related to the employment of computer code to solve problems, enhance out lives, or make our lives safer. But we can also find many examples where complexity is employed to solve problems where the problem might have been solved more simply, more safely and more effectively with better design of physical elements.

 

We used to mount our dagger boards in foil shaped cases with the board bearing against the inside of the case. This resulted in the risk of the board jamming in the case and being difficult to raise. Now we use rectangular cases with foil shaped plastic bearings to minimize the friction and make the boards easy to raise and lower. But I suspect that many catamaran sailors may have been discouraged by their experience with jammed daggerboards and this might help to explain the popularity of fixed keels in many modern day sailing catamarans.

 

Do I need a swing helm so the helm wheel is not obstructing passageway? Will the swing helm enable me to have a choice between standing outboard with better vision or inboard under shelter from rain and sun. I've been asked these questions several times. It's the wrong question. Maybe there is a solution for both of these problems that simply requires asking the right question and engaging more thoughtful design rather than more technology and increased complexity.

 

Some catamaran designs employ a cockpit immediately behind the mast to avoid having to run lines aft to the cockpit. This design feature necessitates having to be able to quickly evacuate water from the forward cockpit to avoid flooding the cabin in the case of a wave over the deck. It also requires additional engineering to ensure the front of the cabin is not vulnerable to wave damage, and the forward cockpit compromises the space available for the layout of the saloon cabin. 

If the goal is to keep all the control lines close to the foot of the mast there are alternative ways to do this. If the goal is to provide direct access to the foredeck area there are options here too without creating a cockpit between the mast and the saloon cabin. In each case the solution proposed to these design issues needs to be weighed and tested against the problem that is being solved before the final commitment to the solution.