Why AI Needs Unified Telemetry on a Mixed-OEM Fleet
Why AI needs unified telemetry comes down to one problem: each manufacturer names signals, scales units and identifies machines in its own way, so the same reading means different things to a model. Mapping everything into one shared schema before any model touches it fixes that once, instead of rebuilding connectors for every new tool.
Why does AI fail on mixed-OEM telemetry?
It fails because the same physical reading arrives under different names, units, identifiers and time bases, and a model cannot know they are equivalent. The model is rarely the weak point. The data underneath it is.
The LF Edge project describes the mechanism. Data from different sources may have different names or units, and missing name or unit changes can lead to errors in coding and erroneous results. Its example is three sources labelling the same measurement "Time," "time" and "Elapsed time." Each label is correct alone. Combined, they cause trouble. A chief engineer would see that two RPM fields are the same thing in a second. A model has to be told.
What makes OEM telemetry incompatible?
Four layers differ: signal names, units, machine identifiers, and structure or export format. A fifth, the time basis, causes quieter errors. Check them in that order. A name mismatch is the easiest to see, and an identity mismatch is the hardest to undo.
The OPC Foundation puts it this way: equipment from multiple vendors arrives with its own data structures, naming conventions, units of measure and integration methods. Each new asset brings its own tag names, event structures and metadata. Downstream systems then have to be reconfigured.
| Layer | Mixed engine-room example | Normalization step |
|---|---|---|
| Signal name | A main engine package and a genset controller describe similar events in their own words | Map each vendor signal to one shared field with a written definition |
| Unit | One source reports time to the thousandth of a second, another to the second | Convert to a single unit at the pipeline |
| Identifier | The same engine appears under different asset names in each platform | Assign one normalized identifier per machine |
| Time basis | Time counted from sensor power-on versus a network clock | Align to one reference clock |
| Transport | A bus message from an engine versus a Modbus register on a monitoring system | Bridge or gateway, then map meaning |
How do marine engines and onboard systems publish data?
Which standard a machine uses depends on its builder and its role aboard. Engines and onboard systems on yachts commonly publish over an NMEA 2000 network, and Modbus RS485 is common in yacht monitoring.
A NMEA 2000 to Modbus gateway datasheet shows the pattern. That product converts NMEA 2000 messages from engines, tank senders, generators, AC monitors, battery banks, battery chargers and control switches to the Modbus RS485 format. It does so because large yacht monitoring systems use Modbus RS485. The gateway solves a transport problem. It leaves open whether one builder's "coolant temp" equals another's.
Why do standards alone not give you comparable data?
A bus or protocol standard moves bytes in an agreed format. It does not make one builder's signal equal another's, and it does not tie a reading to a named asset.
Use a simple rule. If your tool cannot receive the data at all, you have a protocol gap, and a gateway or a standard interface fixes it. If the tool receives everything but gives shaky answers across makes, you have a meaning gap. Names, units, identity and relationships need a schema. Our approach is to normalize into one schema with normalized identifiers and typed relationships. A reading is then tied to a specific machine, not left as an anonymous number in a column.
Standards bodies know this. The OPC Foundation notes that standardized information models define how assets should be represented consistently, including how units, states and alarms should be read. That layer sits above transport.
Why are AI and ML results unreliable on inconsistent sensor data?
Models learn one machine's patterns and often fail when the machine, sensor set or environment changes. Unit or name errors add false results on top.
The research is consistent. One study of IIoT anomaly classification found that models perform well when training data comes from the same machine. As soon as the machine is changed, repaired or moved to a different environment, the prediction often fails. A paper on condition monitoring notes that a classical algorithm cannot adapt to the addition, removal or failure of a data source. Work on rare-failure prediction addresses equipment of the same family that differs in sensor configuration. Failures are rare to begin with, so little data exists to absorb the extra noise.
What does a unified data model do?
It defines each shared field, its unit, identity and relationships once, so equivalent readings land in the same place. Before pointing a tool at a schema, ask whether every field has a written definition and whether every reading links to an identified machine.
LF Edge recommends a separate system to handle these issues before coding or modelling is done, so inferences stay accurate and trusted. It also notes that the conversions can run at the edge, which keeps remote inference isolated from non-unified data. Keep one more distinction in mind. Machine-readable data differs from merely digitized data: a scanned PDF or CSV export is digital, but built for a person to read.
What are the common approaches: semantic models, digital twins, asset administration shell?
OPC UA companion specifications and unified namespaces are the best documented. Digital twins and the asset administration shell serve similar purposes of describing an asset consistently, and you can judge them against the same checklist.
With OPC UA, the OPC Foundation says a shared NodeSet defines the standard once, so all participating systems exchange data in a common structure. The VDMA guideline calls manufacturer-independent data exchange through uniform interfaces the central challenge of Industrie 4.0. LF Edge's unified namespace aims to let operations, support and management communicate without error. None of these requires replacing existing systems. A schema layer can work on top of them.
How do you compare equipment across manufacturers reliably?
Normalize first, then baseline each asset against its peers on shared fields and units. Anomaly methods only work on comparable inputs.
Picture an operations manager comparing two vessels with different engines. First confirm both feed the same fields in the same units. Only then does a peer baseline mean anything. Multi-system research points the same way. The M²AD framework for anomaly detection across multiple systems outperformed existing methods by 21% on average in its evaluations. Its real-world case study covered 130 assets in Amazon Fulfillment Centers. That is a warehouse benchmark, not marine, and it says nothing about what any fleet would gain. It does show that methods built for many systems beat single-system ones.
What does point-to-point integration cost, and how does a shared data layer reduce it?
Every new asset or tool needs its own remapping, and small OEM changes break dashboards. A shared layer does the translation once.
The OPC Foundation says engineering teams spend a lot of time normalizing and remapping data instead of using it. It adds that even small changes from one OEM to another can break downstream applications, dashboards and analytics. When more resources go to integration than to insight, the return on investment is lost. We call the recurring version the integration tax, and we don't put a dollar figure on it. The same logic applies beyond telemetry. Warranty claims across vendors and a unified model across MES modules hit the same wall.
If you want to see how a unified model would be built from your own systems, start with a demo at sailplan.com, or read more in our other insights. Visit SailPlan to get started.
Related resources
SailPlan builds the machine-readable data model that makes every AI tool in your stack actually work. Request a demo to see it in action.