Historical Replay in a Digital Twin: What the Timeline Needs
Historical replay must answer where an object was, what state it was in and which events existed at a specified time. The timeline is only the control. Accuracy depends on historical records, object mappings, time definitions and versions. Current values cannot reconstruct the past on their own, and animation should not invent missing facts.
On this page5 sections
Choose between replaying a screen and reconstructing business state
If the requirement is to see what appeared on a display, assess screen recording. If users need to seek to a time, inspect equipment, filter alarms or compare areas, they need queryable historical data. The deliverables differ: a recording preserves pixels, while state replay must align 3D objects, lists, trends and event details to one selected time.
A first release can cover one area, one equipment type and an explicit period. Identify the positions, operating states, alarms and actions to reconstruct. Mark fields without a historical source as unavailable rather than applying their current values to the past. Retain identifiers that explain records for equipment that has since been renamed or removed.
Separate occurrence time from the time the system learned about it
Apache Flink's time-processing documentation distinguishes event time from processing time and explains the need to handle out-of-order and late records. Even without Flink, preserve the business occurrence time and the platform's receipt or registration time. Agree the time zone, precision and ordering of events with equal timestamps.
Suppose a device stops at 10:00, but its record arrives at 10:08 after connectivity returns. A reconstruction using the complete later record should show it stopped after 10:00. A review of what the system knew at the time may show only a last-known or unknown state until 10:08. Both views can be useful. Select the one required for the review rather than silently rewriting the information available to the operator.
Choose a historical query method and retain mapping versions
If an existing historical database can query equipment state at a specified time, assess reuse first. Evaluate event records and snapshots when the requirement warrants reconstructing business changes. Microsoft's Event Sourcing guidance describes rebuilding state from events and using snapshots to reduce replay work, while explaining the added complexity. A timeline alone is not a reason to redesign the entire business system.
Each seek needs a defined starting state and the changes up to the target time. Seeking backward must not retain a future state. Associate snapshots with the data boundary, object mappings and rule versions. When equipment moves, floors change or alarm thresholds are revised, decide whether to reproduce the old scene or display historical data in today's scene, and identify the version used.
Continuous position samples can use agreed interpolation to make motion readable, but estimated paths are not measurements. Cesium SampledProperty exposes interpolation and extrapolation settings. Discrete changes such as alarms, switches and work-order status need explicit transitions, and long missing-data periods should remain visible as gaps.
Keep late entries and corrections explainable
A manual late entry should retain the occurrence time, registration time, operator and reason. A correction should also reference the original record. For a formal review, preserve the data cutoff or revision used for replay. If a later entry changes the same period's result, users can then identify what was added instead of encountering a silently overwritten value.
A duplicate event must not increase counts twice, and out-of-order changes need a defined reconstruction rule. Separate historical queries from live control. Replaying an old alarm must not dispatch another work order, send another notification or operate equipment. Obtain current state again when returning to live mode, rather than leaving values from the selected historical time on screen.
Verify results with a small dataset of known outcomes
Have business users approve records with expected states, then compare continuous playback with direct seeking. A recording of smooth animation is insufficient evidence. The following samples can support a first release, with their quantity and time range set for the actual scope.
| Sample | Action | Expected check |
|---|---|---|
| One start or stop event | Seek before and after it, then backward | Scene, details and list agree at the selected time |
| Duplicate, out-of-order and late records | Reload the same period | No double counting; the agreed late-entry view is applied |
| Missing data or an object without history | Seek into gaps and range boundaries | Unknown states are explicit, not invented |
| A model or rule change | View periods on both sides of the change | The version is explainable and objects remain correctly mapped |
| Return to live mode | Stop replay and obtain current state | History triggers no new operations; current values are correct |
Authorize historical queries for the current viewer as well. If equipment previously belonged to another area, agree whether its earlier records are available to that viewer. Access to an object today should not automatically grant access to its entire history.
Retain samples, expected states, query parameters, data and rule versions, and test results. Agree historical retention, query permissions and response targets for large seeks. Reuse the same samples after interface or model changes to determine whether they affected the established review capability.