Start from the decision, not the sensor
Shipboard IoT is not a new idea. Ships have had sensors for decades — the difference now is that the data can leave the ship cheaply and continuously, and that there is a regulatory reason to want it.
The risk is building an expensive telemetry system that changes no decisions. This article is organised around avoiding that.
| Decision to be made | Data required |
|---|---|
| When to clean the hull | Speed, shaft power, draft, trim, weather, over time |
| Whether the main engine is degrading | SFOC, exhaust temperatures, turbocharger speed, pressures |
| Whether to overhaul or defer | Vibration, oil analysis, running hours, load history |
| How much EU ETS cost this voyage created | Fuel by type, voyage classification, at-berth periods |
| Whether the CII trajectory is on track | Fuel, distance, time, cargo pattern |
| Whether a reefer cargo is at risk | Container temperature and alarm status |
| Whether the crew are overloaded | Rest hours, port intensity, work orders completed |
Anything that does not appear in a table like this is telemetry for its own sake.
What to instrument
| Sensor group | Purpose |
|---|---|
| Fuel flow meters (ME, AE, boiler) | The foundation of everything — performance and compliance |
| Shaft torque and speed | Actual power delivered |
| GPS and speed log | Speed over ground and through water |
| Anemometer | Wind for weather correction |
| Draft and trim | Loading condition |
| Engine parameters | Temperatures, pressures, turbocharger data |
| Vibration | Condition monitoring on rotating machinery |
| Tank levels | ROB verification and cross-check on meters |
| Cargo systems (segment specific) | Reefer temperatures, pump parameters, cargo tank conditions |
| Power management | Generator loading, shore power |
Fuel flow metering deserves the top position. It feeds performance analysis, CII, EU ETS and FuelEU simultaneously — and a drifting meter now produces a wrong number with a cash consequence attached.
Getting data ashore
LEO satellite connectivity removed the bandwidth constraint that shaped shipboard architecture for decades. The practical pattern now:
- Onboard collection from sensors and existing automation systems, normalised to a common model
- Local buffering so a connectivity outage loses nothing
- Edge filtering so that raw high-frequency data does not need to be transmitted in full
- Shore ingestion into the fleet data platform
- Reconciliation with the ship's own reported data — the two must agree, and where they do not, that is itself information
The three failure modes
1. No decision owner. Data arrives, nobody is accountable for acting on it. Fix by naming, for each data product, who reviews it and how often.
2. Alert fatigue. Thresholds set too tight, hundreds of alerts, everyone stops looking. Fix by tuning thresholds against actual operational significance and reviewing alert volume monthly.
3. Parallel truth. The IoT system says one thing and the noon report says another, and no one reconciles them. Fix by making reconciliation an explicit, automated report — divergence is a meter calibration signal.
Integration with the ship management system
IoT data is only useful when it connects to the operational record:
| Connection | Result |
|---|---|
| Condition data → PMS jobs | Maintenance triggered by condition, not calendar |
| Fuel data → emissions module | ETS, FuelEU and CII from one source |
| Performance data → commercial | Charter party performance defence |
| Alarm data → QHSE | Incident and near-miss context |
| Running hours → PMS | Accurate interval management |
Data that lives only in a vendor dashboard, disconnected from the PMS and the compliance module, delivers a fraction of its value.
Cyber implications
Every sensor and gateway is an attack surface, and IoT installations frequently bridge OT and IT networks — precisely what IACS UR E26 and E27 are designed to control for ships contracted from 1 July 2024. Requirements to specify at purchase: network segregation, no default credentials, secure remote access with logging, documented update process, and an inventory entry in the ship's computer-based system register.
A realistic implementation path
| Phase | Work |
|---|---|
| 1 | Decide the decisions; write the table at the top of this article for your fleet |
| 2 | Instrument fuel, power and speed on three pilot vessels |
| 3 | Establish reference curves and reconcile with noon reports |
| 4 | Build one report that changes one decision — usually hull cleaning timing |
| 5 | Extend to emissions accounting from the same data |
| 6 | Add condition monitoring on high-consequence machinery |
| 7 | Roll out across the fleet with a fixed standard |
Step 4 is the gate. If the first report does not change a decision, adding more sensors will not help.
cyber requirements per IACS UR E26/E27 and the ISM Code; emissions references to Directive (EU) 2023/959 and Regulation (EU) 2023/1805. Value chart is an indicative model. Reviewed by the Zeaclub Editorial Team, 24 August 2026.
Frequently asked questions
What is maritime IoT?
Connected shipboard sensors and systems that collect operational data continuously and transmit it ashore for analysis and decision-making.
Do we need it if we have noon reports?
Noon reports remain contractually important, but daily averages cannot detect transients, isolate causes or support the granularity that emissions accounting and performance management now require.
What should we instrument first?
Fuel flow, shaft power and speed. Those three feed performance, CII, EU ETS and FuelEU simultaneously.
How do we avoid buying a dashboard nobody uses?
Define the decisions before the sensors, name the person accountable for each report, and require the first deployment to change one specific decision before extending it.