Preserve equipment data sources and timestamps during integration
Keep source identities, measurement and receipt times, and communication quality when connecting equipment. Identify stale data, offline backfills, and device replacements so alerts and reports remain traceable.
A reading just received by a platform may be seconds old or come from an earlier disconnected period. Treating receipt as a new measurement can assign the wrong time to alerts and reports.
Keeping sources, original times, and communication conditions lets managers establish when a value was produced and what it can support now.
Identify the device and measurement point
Source records should identify the equipment, measurement point, and connection path. When a gateway or existing API forwards data, preserve its source identifier and map it to the platform equipment record. Record rule versions for unit and field conversions.
Display names can change while source mappings remain traceable. Record effective times for equipment replacements, point changes, and document updates. Historical records can then be matched to the configuration in effect at the time.
Give measurement and receipt times distinct roles
Measurement time places a reading in its original moment or interval. Receipt time records when the platform obtained it. Saving both helps identify delays and offline backfills. If the source provides a state-change time, document that meaning explicitly.
| Time field | Question it answers |
|---|---|
| Source measurement or event time | Which period should contain the reading or event? |
| Platform receipt time | When did the data arrive, and was it delayed? |
| Processing time | When was conversion or calculation completed? |
| Manual correction time | When was a historical result changed? |
Use an explicit time zone and agree on storage and display conventions. Where equipment timestamps are unavailable, retain receipt time and label the platform-provided time. Applications requiring precise event order also need checks on device clocks and synchronization.
The OPC UA DataValue definition separates values, status codes, source timestamps, and server timestamps. Other interfaces can preserve time and validity information according to their actual capabilities.
Use communication records to assess validity
Distinguish the last valid reading, last successful read time, and latest failure reason. After a communication failure, a view can retain the reading with its time and show a stale-data or connection warning.
Set staleness thresholds for the update behavior and management use. Slowly updated cumulative readings and time-sensitive alerts may need different thresholds. Preserve the quality status of valid zero values and record read failures separately.
Assign backfills to their original periods
After reconnection, place backfilled data in its original measurement period and record the actual receipt time. Detect repeated messages through source identities, sequence numbers, or agreed unique fields, with documented duplicate-handling rules.
Decide whether historical backfills produce new notifications, become historical events, or require manual follow-up. Reports also need cutoff and revision rules. See the Modbus, MQTT, and API integration guide for connection details.
Verify time and provenance together
During a pilot, compare source data with equipment times, platform receipt times, and displayed values. Then test offline backfills, duplicates, clock differences, and device replacements. Alerts and reports should continue to assign records to the intended periods.
Document time sources, time zones, update and staleness rules, and responsibility for equipment mappings. These records give maintenance staff a basis for handling future device or interface changes.
lvsota’s equipment and data integration service connects devices and existing systems, preserving records for management views and reports. Bring source samples, interface documentation, and intended uses to discuss the connection approach.
Explore Equipment and data integration