Commodore Control-System Failure: Why Backup Controls Must Be Usable

This article applies where a yacht relies on software-controlled machinery, propulsion, steering, thrusters, stabilisers, power management, alarms, tanks, hydraulics, doors, platforms, or guest-facing automation that can affect vessel operation.

Applicability depends on the installed automation architecture, class and flag requirements, control authority, backup or manual-control arrangements, vendor support model, and whether the software can affect movement, alarms, emergency response, or machinery safety.

Do not investigate only the failed screen, PLC, HMI, or workstation. Investigate the whole control chain.

Include:

• What the operator was trying to control.
• Which screen, controller, station, or software process accepted the command.
• Which actuator, valve, motor, engine, thruster, breaker, or hydraulic function should have responded.
• Which alarms or fault indications were visible.
• Which backup or manual controls existed.
• Whether the crew had practised using those controls under time pressure.
• What the last known good software and configuration baseline was.

The practical question is simple: when the normal screen stops being trustworthy, can the yacht still control the physical system?

On 5 June 2021, the high-speed passenger ferry Commodore was transiting northbound on New York's East River when it lost primary steering and speed control to the two port-hull water jets and grounded in Bushwick Inlet, Brooklyn.

The incident involved 107 passengers and 7 crew. One minor injury was reported, there was no pollution, and NTSB estimated vessel damage at about USD 2.5 million.

This is not a yacht incident, and it was not a simple "PLC backup" case. It is still highly relevant to yachts because it shows how software, display hardware, control architecture, operator assumptions, SMS procedures, and backup-control training can combine into a physical loss of control.

For yacht teams, Commodore is a reminder that a backup control is not a backup strategy unless the crew can recognise when to use it and can operate it immediately.

Commodore was a 137-foot high-speed aluminium catamaran passenger ferry built in 2018. It operated commuter service between Manhattan and New Jersey and was fitted with four MTU propulsion engines driving Rolls-Royce Kamewa water jets.

The vessel's primary steering and propulsion control system was Kongsberg Maritime's CanMan Touch system. On the bridge, two main touchscreen displays were fitted at the centre control station. The main A display processed command inputs for the port water jets and engines. The main B display processed command inputs for the starboard side.

That detail matters. The failed display was not only a visual screen. It was part of the command path.

Commodore also had port and starboard backup control panels at the main station. Those backup controls were electrically separated from the main system and had their own power supply. If the primary controls failed, the operator could activate the backup panels and control the water jet buckets, steering nozzles, and engine clutches through direct hydraulic-control activation.

In other words, the vessel had a fallback. The problem was that it was not used in time.

On the day of the incident, Commodore had been idle for four days and then returned to service. The crew completed a startup checklist that included propulsion, power, steering, engine, and jet-alarm checks. The NTSB report says no active failures were noted.

At about 1607, while the ferry was running full ahead at nearly 38 knots and approaching the East 35th Street terminal, the jet alarm panel indicated control failure for both port water jets. At the same time, the main A touchscreen went blank.

From that moment, the vessel was in a demanding failure mode. The starboard controls were still responding. The port controls were not. The port water jets stayed at full ahead. The starboard side responded to the captain's commands.

When the captain pulled the thrust levers back to neutral, the starboard water jets slowed, but the port water jets remained at full ahead. The ferry immediately began turning to starboard. When the captain then commanded full reverse, the starboard side responded again, while the port side continued ahead. The asymmetric thrust kept the turn developing.

The captain attempted to reconnect the port water jet controls through the primary control system. He later moved to the port wing station and again attempted to regain control through the touchscreen interface. The ferry entered Bushwick Inlet and grounded less than two minutes after the first control-failure alarm.

The port hull was breached. Seawater entered the port engine room. Emergency responders transferred passengers and crew ashore. Commodore was later refloated and drydocked for repair.

After the event, a Kongsberg service engineer extracted data from the display-screen SD cards, except from the failed main A display.

The investigation found that the CanMan Touch software had been generating a very large number of error messages before the grounding. NTSB reported that logs showed about 200,000 failure messages from 1 June to 5 June.

The software behaviour mattered because the display screens booted from SD cards. Those cards stored the software needed to run the display functions, along with logs and the root file system. The error-message activity caused large configuration files to be written repeatedly to the SD card. Flash memory has a finite write life. Eventually, the SD card for main A failed.

When that happened, the main A display could not restart. Because main A processed command inputs for the port water jets and engines, the loss of that display also removed the primary control path for the port side.

This is where Commodore becomes more than a "screen went blank" story.

The yacht lesson is that a display, HMI, embedded computer, PLC memory card, industrial PC, control server, or touchscreen can be part of the operational command chain. If it is treated as only a user interface, the failure mode may be misunderstood.

The backup controls were available and later tested as functioning. The NTSB report says post-incident testing confirmed the backup controls worked as designed.

The issue was recognition and response.

The crew saw a blank display, port water jet control-failure alarms, and a vessel that did not respond as expected. The captain focused on reconnecting the primary control system. That was understandable in the moment, but it was not the effective recovery path.

The vessel's SMS contained backup and manual-control information. It also required loss-of-steering and loss-of-propulsion drills. But the NTSB found that monthly drills did not include shifting to the backup control system. Training records showed backup control was covered as a training area, but the captain and mate did not have to demonstrate practical proficiency.

That distinction matters for yachts.

A signed familiarisation form can prove that a topic was mentioned. It does not prove that the watchkeeper can operate the fallback under pressure, in a noisy wheelhouse, with guests or passengers onboard, while the vessel is still moving.

Commodore's grounding was not caused by one weak point. It was a chain.

The technical chain was:

• Software generated repeated error messages.
• The system wrote heavily to the display SD card.
• The SD card failed.
• The main A display could not restart.
• Primary control of the port water jets and engines was lost.
• The port side stayed at full ahead while the starboard side responded to commands.

The operational chain was:

• The active failures were not identified before departure.
• The crew did not interpret the failure quickly enough.
• The captain tried to reconnect the primary system instead of shifting immediately to backup control.
• The backup control mode had not been practised as a real emergency action.
• The SMS did not give a short, time-critical sequence for this specific loss-of-control condition.

For yacht teams, that is the useful lesson. Control-system incidents rarely stay inside one box. Software behaviour, storage media, alarms, operator training, procedures, and fallback controls all interact.

A yacht may not use the same water jet control system. The pattern is still familiar.

Comparable yacht systems include:

• Propulsion and thruster control.
• PMS and generator control.
• Stabiliser and fin control.
• Tank-transfer automation.
• Hydraulic platforms, shell doors, passerelles, and tender garages.
• HVAC plant and chilled-water controls.
• Bridge-integrated machinery displays.
• Alarm-monitoring and vessel-management systems.

The common risk is not that all of these systems will fail like Commodore. The common risk is that the normal interface may fail in a way that leaves a physical system in its last state, partial state, or degraded state while the operator keeps trying the normal screen.

That is why yacht control-system governance should focus on actual authority, not screen ownership.

Ask:

• What can this interface command?
• What happens if it freezes, reboots, or loses storage media?
• Does the actuator hold last state, fail safe, stop, close, open, or continue?
• What independent backup exists?
• Has the crew used the backup while the system is live?

If a yacht has a control-system incident, build the investigation around three timelines.

First, build the event timeline.

• When did the first abnormal indication appear?
• What did the operator command?
• What actually moved, stopped, opened, closed, or continued?
• Which alarms appeared?
• Which station had control?
• Which backup or manual action was attempted?
• When did the system become safe again?

Second, build the software and configuration timeline.

• What software and firmware versions were installed?
• When was the last update, upload, parameter change, or vendor attendance?
• Was a backup taken before the change?
• Was the installed version known and recorded?
• Were logs overwritten, cleared, or unavailable?
• Was the affected controller, memory card, HMI, or industrial PC preserved?

Third, build the training and procedure timeline.

• What did the SMS or yacht procedure say?
• Was there a short emergency sequence?
• Had the crew practised the backup control?
• Was the drill realistic or only a discussion?
• Did the procedure match the installed equipment?

If those timelines do not line up, that is usually where the lesson sits.

Before anyone overwrites or replaces the control system, preserve evidence.

Minimum evidence:

• Current PLC, HMI, industrial PC, firmware, and application versions.
• Screenshots or photos of fault pages and alarms.
• Controller diagnostic logs.
• HMI project files and runtime exports.
• Backup files and timestamps.
• Vendor work orders and remote-support records.
• Network and control-system architecture.
• Photos of control stations, panels, labels, and backup controls.
• Crew statements about what they saw and what they tried.
• Any failed SD card, memory card, controller, module, or workstation.

Do not let a support visit silently "fix" the evidence. If immediate safety requires action, copy what can be copied first and record what was changed.

The mitigation is not simply "take backups." Backups matter, but Commodore shows that recovery also depends on recognition, procedure, and human-machine design.

Use four control layers.

First, control the software baseline.

• Keep a register of PLC, HMI, controller, and firmware versions.
• Record vendor updates, parameter changes, and configuration uploads.
• Store known-good backups in more than one controlled location.
• Test restore procedures before relying on them.

Second, control the fallback.

• Identify every backup, local, manual, and emergency-stop option.
• Label control-transfer states clearly.
• Test fallback controls during commissioning and after software changes.
• Include fallback operation in periodic drills.

Third, control the operator response.

• Write short emergency sequences for time-critical failures.
• Limit how many reconnect attempts are allowed before fallback action.
• Train crew to recognise when the normal interface is no longer authoritative.
• Practise the sequence at the actual station, not only in a meeting.

Fourth, control vendor work.

• Require pre-change backup evidence.
• Record what was changed and why.
• Require post-change testing of normal and degraded modes.
• Keep remote-access logs.
• Close the change only when the yacht has the updated baseline and rollback path.

This case is especially relevant after refit or system upgrade.

During commissioning, do not only prove that the touchscreen works in normal mode. Prove what happens when it does not.

The acceptance test should include:

• Loss of display.
• Loss of communication.
• Failed controller restart.
• Failed sensor value.
• Loss of primary station.
• Transfer to backup station.
• Local or manual operation.
• Emergency stop or isolation.
• Alarm visibility at the station where the crew will actually be.

For yachts, this is where technical and management interests meet. A beautiful control interface is not enough. The yacht needs evidence that the system remains controllable when the primary interface is wrong, blank, frozen, or unavailable.

After a control-system incident or near miss, useful corrective action should go beyond replacing a card, rebooting a screen, or uploading a fresh project.

Closeout should include:

• Root cause or best-supported technical explanation.
• Corrected software, configuration, or hardware.
• Preserved pre-fix evidence.
• Updated software baseline.
• Verified backup and restore route.
• Tested fallback controls.
• Updated emergency procedure.
• Crew familiarisation on the actual installed system.
• Management sign-off where the system affects safety, movement, or operational continuity.

If the incident exposed a design issue, record it as a design issue. Do not hide it as crew error.