Overview
Every sensor that connects to an IoT platform produces a stream of timestamped values. This stream — raw telemetry — is the raw material for operational intelligence. But raw telemetry is not intelligence any more than raw iron ore is a machine part.
The transformation from raw telemetry to asset intelligence is a data modeling problem. It requires a data architecture that: stores telemetry at full resolution for historical analysis; maintains a current state record that reflects the asset’s condition right now; links telemetry to the physical asset’s identity and context; connects sensor readings to maintenance events, configuration changes, and operational history; and enables the queries that operational decisions require.
This technical brief covers VX-Olympus’s data model for digital asset twins — from the lowest level (raw telemetry records) to the highest (the asset intelligence that supports maintenance planning, anomaly detection, and eventually AI-driven insights).
The Data Model Layers
VX-Olympus organizes data about physical assets in five layers, each building on the previous:
Layer 1: Raw Telemetry Records
The lowest layer is the time-series telemetry record — every sensor reading, at full time resolution, stored in the time-series database.
Record structure:
device_id: "plant-a/floor-2/motor-14b/temp-sensor-1"
timestamp: 2024-07-15T14:23:47.523Z
field: "bearing_temp_celsius"
value: 30.7
quality: "GOOD"
Storage characteristics:
- Millisecond timestamp precision
- Quality flag (GOOD, STALE, OUT_OF_RANGE) attached to each record
- Full resolution storage for the configured retention period (default: 1 year for raw telemetry)
- Compressed storage using delta encoding and run-length compression for values that change slowly
- Indexed by device_id and timestamp for efficient range queries
Time-series query patterns:
- Get all readings for device X between time A and time B
- Get the last N readings for device X
- Get the minimum, maximum, and average for device X in a time window
- Get all devices with a reading above threshold T in the last hour
The time-series layer is the source of truth for historical analysis. All aggregate calculations (rolling averages, baselines, trend analysis) derive from this layer.
Layer 2: Normalized State Records
The state record layer maintains the current value for each telemetry field for each device — the “what is happening right now” view.
State record structure:
device_id: "plant-a/floor-2/motor-14b"
last_update: 2024-07-15T14:23:47.523Z
fields: {
bearing_temp_celsius: 30.7,
motor_current_amps: 4.2,
vibration_rms_g: 0.18,
running_status: true,
operating_hours: 4,823
}
alert_status: "WATCH"
last_alert: "bearing_temp_celsius above 8°F baseline"
Why state records exist separately from time-series: Dashboard real-time widgets (gauges, status indicators) need the current value for a device. They could query the time-series database for the most recent record per field, but that query — at scale, for hundreds of devices simultaneously — is expensive and slow.
State records are maintained as a low-latency, always-current snapshot. When a new telemetry record arrives and is stored in the time-series layer, VX-Olympus simultaneously updates the state record with the new value. Dashboards read from state records; they do not query time-series directly for real-time display.
State record update flow: New telemetry → stored in time-series → state record updated (< 30 ms) → dashboard WebSocket subscription notified → widget updates.
Layer 3: Asset Identity and Context
The identity layer connects the sensor data stream (device_id based) to the physical asset it represents and to the operational context where it operates.
Asset identity record:
asset_id: "motor-14b"
name: "Drive Motor — Press Line 2, Station 14B"
asset_type: "electric_motor"
manufacturer: "Nidec"
model: "T3S-215TC"
serial_number: "NT3-2201447"
rated_horsepower: 25
rated_rpm: 1,760
installation_date: "2018-03-12"
warranty_expiry: "2023-03-12"
location: "Building A / Floor 2 / Press Line 2 / Station 14B"
parent_asset: "press-line-2-station-14" (the machine this motor drives)
monitored_by: ["plant-a/floor-2/motor-14b/temp-sensor-1",
"plant-a/floor-2/motor-14b/vibration-1",
"plant-a/floor-2/motor-14b/current-ct-1"]
What the identity layer enables:
- Navigating from a sensor to the physical asset it monitors (“which motor does this temperature sensor measure?”)
- Navigating from a physical asset to all its sensors (“what sensors monitor this motor?”)
- Understanding the asset’s position in the equipment hierarchy (“this motor drives Station 14B, which is part of Press Line 2”)
- Retrieving identity information at alert time (“the bearing replacement requires Nidec part #NT3-21-BRG-FC, compatible with model T3S-215TC”)
Layer 4: Maintenance and Event History
The history layer connects the sensor data stream to the events that have affected the physical asset over time.
Event types stored against each asset:
- Alert events: Every alert that fired for this asset (timestamp, triggering field, value, threshold, severity, acknowledgment)
- Maintenance events: Every work order generated for this asset (date, description, findings, parts used, labor hours, technician)
- Configuration events: Every change to threshold settings, polling interval, or device profile for this asset
- Operational events: Scheduled shutdowns, production starts, shift changes (linked to asset operating periods)
Maintenance history record (example):
work_order_id: "WO-2024-3847"
asset_id: "motor-14b"
triggered_by: alert_id "ALERT-2024-0714-023"
alert_condition: "bearing_temp_celsius > baseline + 15°F for 2+ hours"
date_created: 2024-07-14T22:15:00Z
date_completed: 2024-07-15T08:30:00Z
work_performed: "Replaced drive end bearing. Greased load end bearing."
parts_used: [{part: "NT3-21-BRG-FC", qty: 1, cost: 142.00}]
labor_hours: 2.5
post_repair_reading: {bearing_temp_celsius: 27.4}
What the history layer enables:
- Understanding whether current readings are anomalous in the context of the asset’s history (“is 30.7°F a high temperature for this motor? the baseline is 27°F, and the last bearing replacement was when the same reading reached 33°F”)
- Identifying patterns in failure frequency (“this motor has needed bearing replacement 3 times in 18 months — is there a root cause?”)
- Calculating maintenance costs per asset, per asset type, per production line
- Mean time between failures (MTBF) calculation for each asset based on actual failure history
Layer 5: Derived Intelligence
The top layer is derived from the lower layers — computed values, statistics, and assessments that represent the asset’s intelligence state.
Baseline: A rolling statistical summary of normal operating behavior for this specific asset. Computed from recent time-series history (typically 30 days, recalculated daily).
baseline_bearing_temp: {
mean: 27.2°F,
std_dev: 1.1°F,
p95: 29.1°F, (95th percentile — exceeded only 5% of the time normally)
computed_from: "2024-06-16 to 2024-07-15, excluding maintenance windows"
}
Alert thresholds based on this baseline (“alert if temperature exceeds mean + 3 × std_dev”) automatically adapt to the specific asset’s actual operating characteristics — not generic industry values.
Health Score: A synthetic metric summarizing current asset condition as a value from 0 (critical failure) to 100 (excellent health). Computed from:
- Current deviation from baseline across all monitored parameters
- Recent alert frequency
- Time since last maintenance
- Trend direction (improving, stable, deteriorating)
Health scores enable portfolio-level views: “which 10% of assets in Building A have the lowest health scores this week?”
Predicted Time to Maintenance: For assets with enough maintenance history to support pattern analysis — assets that have had similar alert patterns followed by maintenance events — VX-Olympus can estimate when the current condition pattern is likely to require maintenance.
Data Flow Architecture
The complete flow from sensor to intelligence:
- Sensor transmits a reading
- VX-Olympus ingestion layer authenticates and decodes the payload
- Decoded values are written to the time-series database (Layer 1)
- State record is updated with the new values (Layer 2)
- Rule engine evaluates the state record against alert thresholds
- If an alert fires: the alert event is recorded in the history layer (Layer 4)
- If an alert triggers a maintenance work order: the work order is created and linked to the asset identity (Layers 3 and 4)
- Periodically (daily): baseline recalculation from recent time-series history (Layer 5)
- Continuously: health score updated from current state, recent alerts, and maintenance history (Layer 5)
Query Patterns for Asset Intelligence
The data model’s value is expressed in the queries it enables:
“Show me the temperature history for Motor 14B for the past 30 days with the baseline overlaid.” Time-series query + baseline from Layer 5. Visualized as a time-series chart with a baseline band.
“Which motors in Press Line 2 have had more than 2 maintenance events in the past 12 months?” Maintenance history query (Layer 4) filtered by asset type and location (Layer 3), aggregated by event count.
“When the current alert for Motor 14B fires, what does the sensor reading look like relative to the last time this alert condition occurred?” Alert history (Layer 4) + time-series query for the reading context around the previous alert event.
“Show me all assets in the facility with health scores below 60, ranked by worst health first.” Health score query (Layer 5) filtered by location (Layer 3), sorted by score.
These queries — the ones that produce operational decisions — are not possible without the data model. The raw telemetry alone (Layer 1 only) answers “what was the temperature at this timestamp?” but not “is this temperature unusual for this asset, and what happened last time this pattern occurred?”
Preparing Data for AI Layers
The data model described in this brief is also the foundation for AI-driven features — anomaly detection, failure prediction, maintenance scheduling optimization. AI models require:
- Sufficient history: the baseline calculation and anomaly detection require 30+ days of normal operation history
- Labeled events: maintenance events and alert acknowledgments that confirm whether an alert represented a real condition provide ground truth for supervised learning
- Feature engineering: derived metrics (baseline deviation, rate-of-change, time since maintenance) are more informative features for ML models than raw readings
The VX-Olympus data model builds these requirements into the platform architecture. The data structure that supports current operational intelligence is the same structure that supports AI features — the investment in correct data modeling from the beginning pays forward into future analytical capabilities.
Conclusion
The difference between a sensor platform and an asset intelligence system is the data model. Telemetry records are the foundation; the asset twin structure — identity, history, baseline, health score — is what transforms telemetry into the context that operational decisions require.
VX-Olympus’s five-layer data model provides this structure for every connected asset. The current reading is meaningful in the context of the asset’s history, identity, and baseline. Maintenance decisions are informed by the pattern of the data, not just the current value. And the data foundation is designed to support AI-driven insights as deployment history accumulates.
Talk to our team about data architecture for your VX-Olympus deployment.