Firmware-Over-EtherCAT on a Vessel Mid-Voyage
Pushing a firmware update to 1,200 sensor cells while the ship is at sea sounds simple. Doing it safely is not. Here is what the procedure looks like.
Once a fleet of sensor cells is in service across multiple vessels, firmware updates become a logistical problem rather than a technical one. You cannot send an engineer to every ship, and you cannot risk pushing a bad update to a deck that is mid-voyage. The procedure below is how we do it without bricking anything.
The update flow
- New image is signed and version-pinned. Segment master verifies before any rollout.
- A single canary cell on each deck receives the update first, in isolation.
- Canary runs for a full 24-hour observation window with a parallel old-firmware peer.
- Bulk rollout proceeds only with explicit master approval and a per-cell timeout.
- Any cell that fails to come back within the timeout is auto-rolled back from the master.
What we will not do
- Push firmware during a confirmed alert window. Operator confirmation required to even queue.
- Push to more than one segment master simultaneously on a vessel.
- Push without a verified rollback image already staged on the master.
How RoRoSAFE helps
RoRoSAFE's grid is updated with this procedure, so improvements reach the ship without a port call or a service visit. For an operator, detection keeps improving across the fleet without taking monitoring offline in an uncontrolled way. The limits described in the article on what will not be done at sea are part of that design.
Pilot: one deck · installed alongside the berth · no drydock · 6 months of dashboard access
Questions, answered
How do you update firmware on sensor cells while a ship is at sea?+
Carefully and in stages. A new image is signed and version-pinned, then a single canary cell per deck updates first in isolation and runs a 24-hour observation window against an old-firmware peer. Bulk rollout proceeds only with explicit master approval and a per-cell timeout, and any cell that doesn't return in time is auto-rolled back.
What will the system never do during a firmware update?+
It will not push firmware during a confirmed alert window (operator confirmation is required even to queue), will not push to more than one segment master on a vessel simultaneously, and will not push without a verified rollback image already staged on the master.
Why such an elaborate procedure for an OTA update?+
Because a safety system that bricks itself during an update is no longer a safety system. The procedure exists because the failure mode is unacceptable, not because the firmware is fragile — the conservatism is deliberate.
Continue the thread
Why EtherCAT Ring Topology for Marine Sensors
Star-topology fieldbuses fail open when one run is damaged. A redundant ring keeps the segment master talking to every node, even with a cut cable.
The Data Pipeline From Deck to Bridge
A walk-through of every hop the data takes — sensor cell, segment master, vessel server, bridge console — and the latency budget at each.