TelemetryLabThe premise. A ship's engine reports hundreds of live values, temperatures, pressures, speeds, alarms, up to the vessel's automation system, which shows the crew gauges and threshold alarms; how much more gets stored varies by installation, and turning any of it into longitudinal intelligence is rare everywhere. The raw data is right there, and much of it travels as plain readable values in the legacy protocols still common aboard. What stands between that stream and usable intelligence is not encryption. It is a codebook, the map that says what each value means, plus the processing that turns decoded signals into decisions. This analysis maps who holds that codebook, what the law says about it, and what extraction yields once the data flows. It is built from public documentation, standards and precedent; the worked examples below illustrate established condition-monitoring practice, and nothing here describes TelemetryLab's own methods.
The data travels in the open. The meaning is what's locked.
The industrial protocols a ship's machinery speaks, Modbus above all, date from an era before encryption; the original Modbus, introduced by Modicon in 1979, has no protocol-native encryption, and the legacy forms still dominate the in-service fleet (newer secured variants and authenticated interfaces exist, and remain the exception aboard). A read the owner authorizes can observe that traffic without disturbing it. What it gets is rows of numbered registers holding raw numbers. Turning a register into an engineering fact takes the codebook: the register map or tag list written when the ship's systems were commissioned. That document, not any cipher, decides who can make sense of the machine.
That map is maintained, versioned, per-project intellectual property, and it sits at the heart of what the engine maker's and the automation vendor's cloud products package and sell. A legitimate product. It is also why a shipowner can own the machine, own its operational data by contract, and still not know what register 40137 means. The interesting question is not whether the codebook exists. It is how much of the data you can reach, lawfully, without buying it back.
The architecture, and the one layer that matters
Four places, reached differently. The engine's own controls feed the operational data up to the vessel's automation system, which re-exposes it over standard protocols. That shared layer is the read point. The deepest diagnostics run on the engine maker's own subsystem, beside the shared bus, not on it. The shape below is the common architecture; exact interfaces vary by model, options and commissioning.
The cloud product optional · subscription
The engine maker's and automation vendor's fleet-data services. A maintained codebook plus analytics, sold on top of data the vessel already produces. Useful, and never the only path to the data.
The integrated automation system owner-authorized
The vessel's central monitoring and control layer (in wide service, systems from vendors such as Kongsberg and ABB). In the common architecture it aggregates the engine's temperatures, pressures, speed, load and alarms as engineering values and re-exposes them over standard protocols. An owner-authorized, read-only connection here observes that data, designed and governed so it cannot command the machinery; where wanted, the path can be made physically one-way.
The maker's diagnostics subsystem segregated · by request
Per-cylinder combustion measurement (cylinder pressure and firing behavior) runs on the engine maker's own dedicated system next to the engine. It is not published onto the shared bus. A segmentation fact, not an absence of signal.
The engine's control system internal
Runs the engine. Its values reach the outside world aggregated through the automation system above, which is exactly where a third party should read them.
How much you can reach, and what each level asks
In our read, the first two tiers carry most of the monitoring, safety and cost value, and neither requires a deal with the engine maker. The recurring pivot is owner authorization.
No vessel-specific codebook needed
Where the engine or genset speaks the standardized protocols (SAE J1939, NMEA 2000), roughly 30 to 40 standardized parameters decode with public community decoders and published references: speed, load, temperatures, pressures, fuel rate, hours, trouble codes.
The bulk of the value
The full operational envelope, roughly 150 to 400 channels: per-cylinder exhaust temperatures, turbocharger, charge air, lube oil, bearings, oil mist, cooling, fuel. The codebook here is the integrator's commissioning tag list, which the owner may hold in the yard's delivery documentation or can direct the integrator to enable; on newer OPC UA systems many tags describe themselves.
Combustion truth, on request
Per-cylinder pressure and firing behavior live on the maker's own diagnostics subsystem. Where an engine carries permanent cylinder-pressure monitoring, the owner can request access to the data that system already produces; whether a continuous export exists is case-specific. Optional depth on top, never the gate.
Why this is a pathway, not a workaround
Every tier rests on owner authorization, the contractual and statutory access rights behind it, and a read-only path governed by the vessel's cyber architecture.
Who owns the data
Where the industry's standard ship-management contract governs, vessel data generated under it is the owner's property (BIMCO SHIPMAN 2024, Clause 22), and industry best-practice guidance on data ownership urges manufacturers to provide access to the information needed to interpret machinery data.
The statutory right
In EU scope, the Data Act (applying since 12 September 2025) gives the equipment user a right to the readily-available data a connected product generates, plus the metadata needed to interpret it, and the right to share both with a third party. It stops short of compelling a vendor's full proprietary decode package, trade secrets stay protected, and it is untested at sea. The load-bearing part is the principle it sets: a qualified statutory access right that sits with the user, not the vendor.
Class and cyber
For newbuilds contracted since July 2024, class cyber rules (IACS UR E26/E27) put a shipboard data connection through zoning, inventory, trust and management-of-change controls, with the specifics set by the vessel's approved cyber architecture. In-service ships address it through the owner's ISM cyber-risk process (IMO MSC.428(98)). Either way, a read-only connection is governed, not prohibited.
The precedent
Independent marine performance-monitoring vendors already run on owner-authorized shipboard data, connecting through standard onboard interfaces and their own sensors, with no engine-maker cloud product as the access route. The feasibility is practice, not theory.
Where the access picture ends
Three edges, and none of them contradicts the headline that most of the value is reachable in the owner's own data.
The fuller map can be vendor-gated
Where the owner does not hold the commissioning tag list and the tags are not self-describing, the automation integrator enables the export, commissioned per vessel, sometimes at cost. The owner's lever is their standing as the paying customer: access to the data their own equipment produces is a reasonable, contractable ask.
The deepest layer is off the shared bus
Combustion measurement sits on the maker's own subsystem. Where permanent cylinder-pressure monitoring is fitted, access to its data can be requested; where a vessel only carries a portable, walk-the-engine tool, there is no continuous feed to ask for. Which of the two a given vessel has is the honest gating question for this tier.
Legacy hulls expose less
A share of the in-service fleet is older, mechanically governed, or simply not digitally instrumented. You cannot extract what was never measured. The access picture is real where the data exists, and honest about where it does not.
What extraction yields
The raw material is each cylinder's exhaust gas temperature, already flowing to the automation layer. Processed against the engine's mean and a load-aware baseline (normal at full power is abnormal at half), a single cylinder's slow divergence can become visible long before any fixed threshold trips. Per-cylinder balance is the classic first check on a large engine, and here it is a computation, extracted from signals the alarm panel already receives one at a time.
Turbocharger speed easing down, charge-air pressure easing down, exhaust temperature before the turbine creeping up. No one of those trips an alarm early, and no single threshold catches the pattern. Correlated and trended together they can yield a fouling signature with real lead time, which turns cleaning from a calendar guess into a priced decision: the fuel penalty of waiting against the port time of acting.
The mandated protection against a crankcase explosion is an oil-mist detector, a single-purpose device that trips at a threshold. The same physics also shows up earlier as a correlated trend: oil-mist concentration creeping while a bearing temperature rises. Extracted from the feed as a joint signature, the developing condition can surface with time to plan an inspection, a window in front of the mandated trip, never a replacement for it.
We came to this from cars
Our earlier analyses mapped the same architecture in vehicles: a modern car broadcasts hundreds of safety-relevant signals on its internal bus, and the decode databases that make them legible exist only because a community reconstructed the maps the industry didn't publish. The recall record shows what that unprocessed layer costs. A deep-sea two-stroke behind a proprietary automation stack is about as far from a passenger car as machines get, and the shape repeats: raw values in the open, meaning held close, intelligence waiting on extraction. If the pattern holds in the most conservative machine class afloat, it is not an automotive quirk. The same shape waits wherever machines produce data. The raw data is abundant, and contract and statute keep moving it toward the owner.
The codebook is the moat. And the intelligence, all of it, still has to be extracted.
Scope, and what this is not
This analysis covers one slice: lawful access to large marine engine telemetry, and the intelligence extraction that access supports. It is built from public documentation, standards, law and vendor precedent. It does not cover non-engine ship systems or other machine domains, it does not describe extraction methods, and it makes no claim about any specific vessel, contract or deployment. Signal counts are engineering estimates; any real engine's exposed set is confirmed on the vessel. Nothing here proposes adding hardware to an engine, and every access path described is passive, read-only, and runs on the owner's authorization.
Sources
Standards and protocols
- Introduction to Modbus and its history (Modicon, 1979) Modbus Organizationofficial
- The Modbus protocol examined: plain values, register address vs meaning Redbot Securitystrong secondary
- NMEA 2000, the marine CAN standard NMEAofficial
- CANBoat: open NMEA 2000 PGN decoder and public database open projectopen reference
Engine and automation architecture, and the precedent
- Ensemble anomaly detection on the main engine of a working bulk carrier (150+ vessel-wide streams, 1 Hz, 10 months) Sensors (MDPI) / PMCpeer-reviewed
- Kongsberg K-Chief integrated marine automation system Kongsberg Maritimevendor
- ABB marine automation and digital systems ABBvendor
- Kongsberg K-IMS: owner-controlled information flow and third-party data replication Kongsberg Digitalvendor
- Everllence (MAN Energy Solutions) CEON, the engine maker’s cloud data product Everllencevendor
- Approaching a shipboard automation system: an engineer’s field walkthrough ETO Insightstrade
- Insatech Marine performance monitoring: an independent vendor running on owner-authorized shipboard data Insatech Marinevendor · live precedent
- METIS Ship Connect: automated shipboard data acquisition into a third-party analytics platform The Maritime Executivetrade
Data ownership, class and cyber
- EU Data Act: user access rights to connected-product data (applies from 12 September 2025) European Commissionprimary
- Regulating data in the maritime sector: the Data Act applied to shipboard systems SWZ Maritimestrong secondary
- BIMCO SHIPMAN 2024 (Clause 22: vessel data) BIMCOprimary
- A best-practice guide to data ownership in maritime Lloyd’s Register Horizonsindustry guidance
- IACS UR E26 and E27: cyber resilience of ships (newbuilds contracted from 1 July 2024) IACSprimary
- IMO maritime cyber risk management (MSC.428(98)) IMOprimary