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.
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.