How to Map OEM Telemetry Signals to One Field

Map each OEM's signal to one canonical field by matching its physical quantity, then convert raw counts using the resolution and offset from that OEM's J1939/71 or DBC definition so both values land in the same unit. Keep the vendor's original label as a source attribute, not the field name.

What protocols do engine OEMs use to publish telemetry?

Most marine and heavy-duty engines speak J1939 over CAN, where each measurement is identified by a PGN (message) and SPN (signal). Names differ because OEMs add proprietary PGNs on top of the SAE library, and the same PGN number can mean different things on J1939 versus NMEA 2000.

The SAE J1939 standard defines a catalog of PGNs and SPNs with fixed names, units and scaling. A Garmin chartplotter manual lists standard signals such as engine speed at PGN 61444, SPN 190, and manifold exhaust gas temperature at PGN 65031 Garmin J1939 Information. Manufacturers layer their own PGNs on top of this base set, so two engines from different builders may report the same physical quantity under different PGN numbers or SPN names.

On a marine bus, J1939 and NMEA 2000 share the same 29-bit ISO 11783 frame header but assign different meanings to the same PGN numbers, so a gateway often bridges the two CANboat J1939 documentation. This means you cannot assume a PGN number is safe to reuse across bus types without checking the protocol context.

How do you inventory every signal an OEM engine exposes?

For each signal record five attributes: the vendor's label, the engineering unit, the resolution (units per bit), the offset, and the sampling rate. J1939/71 or the DBC file supplies resolution, offset and range; the PLC or gateway configuration window confirms scaling and unit as deployed.

A J1939 technical reference shows that SPN 110 (Engine Coolant Temperature) carries a data length of 1 byte, a resolution of 1 °C per bit, an offset of −40 °C, and a data range from −40 to 210 °C Data Acquisition from HD Vehicles Using J1939 CAN Bus. The Schneider Electric J1939 configuration guide instructs engineers to verify scaling, offset and unit in the Conversion window of the TX signals tab, noting that the J1939 protocol does not directly support REAL data types Schneider Electric J1939 Interface Configuration. The CANboat documentation adds bit width and signed/unsigned type for each SPN, such as 16 bits unsigned for engine RPM at SPN 190 CANboat J1939 documentation.

Record the sampling rate from the gateway or PLC configuration, not from the J1939 standard itself, because transmission rate is set by the device's firmware and may differ between OEMs.

How do you design one canonical field for a measurement?

Pick one field name and one unit, for example engine_coolant_temp_c in degrees Celsius, and keep the vendor's original label as a source attribute rather than the field name. A multi-model database pattern supports this by adding a semantic integration layer that maps each vendor's format into the shared schema Multi-model database framework for IoT sensor data.

The canonical field name should describe the physical quantity, not the vendor's marketing term. If one OEM calls it "Coolant Temp" and another calls it "EWT," both map to the same field. The source attribute preserves the vendor label for traceability and debugging without polluting the query vocabulary. This keeps downstream queries, alerts and cost analysis working against one consistent name regardless of which OEM built the asset.

How do you convert raw counts to engineering units?

Multiply the raw integer by the resolution, then add the offset. Both values land in the same canonical field.

The Kvaser J1939 introduction walks through a similar calculation for engine speed: raw value 0x1ADF is 6879 decimal, scaled at 0.125 rpm per bit with offset 0, giving just under 859.875 rpm SAE J1939 Introduction. The ADZ SMC transducer document describes the same pattern for a proprietary pressure format: received data is multiplied by the resolution, then the offset is subtracted, with both values found in the device documentation ADZ SMC Technical Description. The arithmetic is identical across OEMs; only the resolution and offset values change.

How do you handle 0xFF sentinels and error flags?

When a device does not have data available for a given parameter, the byte that should have contained this parameter is set to 0xFF so that a receiver knows that the data is missing. Separately, flag physically impossible values and flatlined probes as data-quality events. Each case gets a different action: exclude, alert, or quarantine.

A 0xFF sentinel means the sensor did not report a value for that cycle. Exclude it from the canonical field and log a dropout count. A physically impossible reading, such as a coolant temperature above the sensor's stated range of 210 °C for SPN 110, triggers an alert for operator review. A flatlined probe that reports the same value across many cycles is quarantined for maintenance inspection. Data quality logic that catches sentinel values, dropouts, flatlined probes, drift and impossible readings once for every asset prevents these bad values from corrupting downstream analysis.

What standards supply shared field names and semantics?

SAE J1939/71 defines the standard PGN and SPN catalog with names, units and scaling. OPC UA's PA-DIM specification adds a three-level device identification that ties a field to a specific physical device. For marine assets, NMEA 2000 shares the ISO 11783 frame header with J1939 but uses different PGN meanings, so a marine gateway often bridges the two.

The PA-DIM specification from the OPC Foundation introduces ProductInstanceUri, ID Link and ILString as a practical three-level identification system that aligns with how process automation plants operate PA-DIM Brochure. This gives each device a global identity separate from the signal name, so a replaced engine does not break the field mapping. The SAE J1939/71 document supplies the signal-level vocabulary: parameter names, units, resolution and offset for every standard SPN. Together, these two standards cover device identity and signal semantics without tying the schema to any single vendor.

How do you verify the mapping before going live?

Pick two engines from different OEMs and run a single query using the canonical field name and unit; if both return comparable readings without manual conversion, the mapping holds. Cross-check a handful of raw captures against the J1939/71 scaling table to confirm the arithmetic, then let data-quality logic watch for sentinel values and drift on every asset going forward.

A practical test is to capture one minute of raw J1939 frames from each engine, decode the SPN values using the documented resolution and offset, and compare them against a handheld multimeter or OEM diagnostic tool. If the decoded values match within sensor tolerance, the conversion is correct. Once verified, the mapping becomes a static table that only changes when hardware is replaced or firmware is updated.

Where does this fit in a broader fleet data architecture?

The canonical telemetry schema is one layer of a unified model that also joins manuals, procedures, maintenance history and ERP records under the same field names. Once readings share one field and unit, a single monitoring rule covers every vessel and every make, and the same schema feeds anomaly detection, cost-per-hour analysis and AI tools through one API.

When each manufacturer's gateway uploads independently, the same vessel may pay for several parallel streams, each with its own naming and timestamps. Normalizing before transmission or storage means a single rule set covers every asset, reducing both bandwidth cost and the number of rules an engineer must maintain. The unified schema also lets a query join a live coolant temperature reading with the relevant maintenance procedure and the last service record in one call, which is where operational value comes from.

What do you do when an OEM's proprietary PGN has no SAE equivalent?

Record the proprietary PGN and SPN in your inventory with the OEM's documented scaling, then map it to the nearest canonical field if the physical quantity matches a standard measurement. If no equivalent exists, create a new canonical field and document the OEM source so the mapping is auditable.

The SAE library plus manufacturer extensions from Cummins, Detroit Diesel, Volvo and PACCAR cover most commercial-vehicle signals iMatrix J1939 SAE Library. The gaps are usually marine-specific or very new parameters that have not yet entered the standard. When you create a new field, name it by physical quantity and unit, not by OEM term, so the schema stays vendor-neutral.

How do you keep the mapping current after a retrofit?

Assign each machine a permanent asset identifier separate from the vendor's equipment tag, so a replaced engine or controller does not break history. When a retrofit changes the signal set, re-run the inventory for that asset and update the mapping table; the canonical field names stay stable even as the underlying PGN/SPN or register changes.

A vendor's own equipment tag can collide or change after a retrofit, which is why the permanent identifier must be independent. The mapping table then becomes a living document: each row ties a canonical field to a specific PGN/SPN or register for a specific asset, and the row is updated when hardware changes. This keeps historical data comparable across engine swaps without re-labeling old records.

For a deeper look at how unified telemetry supports anomaly detection across mixed OEM equipment, see Time Series Anomaly Detection for Vessel Telemetry. To explore how technician knowledge ties into the same schema, read Searchable Technician Knowledge for Vessel Engine Rooms. More articles on fleet data architecture are available in SailPlan Insights. If you want to see how this mapping applies to your fleet, start a conversation with our team.

Related resources

• Time Series Anomaly Detection for Vessel Telemetry
• Searchable Technician Knowledge for Vessel Engine Rooms
• Insights — SailPlan