Technical Brief: VX-Olympus Architecture — From Sensor to Dashboard in Under 60 Seconds

Overview

This technical brief describes the VX-Olympus data pipeline architecture — the sequence of system components that process a sensor reading from physical measurement to dashboard display. Understanding this architecture is useful for:

• Engineers evaluating VX-Olympus as a platform for IoT application development
• Systems integrators planning device connectivity and protocol selection
• Operations teams understanding the latency characteristics of the monitoring system
• Developers building integrations on top of VX-Olympus APIs

The pipeline covers six layers: the device layer, the connectivity layer, the ingestion and protocol handling layer, the rule engine and processing layer, the storage layer, and the presentation layer. Each layer contributes to overall system latency and data fidelity.

Layer 1: Device Layer

The device layer encompasses the physical sensor, the on-device firmware, and the transmission schedule.

Sensor Measurement and Sampling

Physical sensors convert a physical quantity (temperature, vibration, pressure, light, moisture, current) into an electrical signal, which the sensor’s microcontroller converts to a digital value. The sampling rate — how often the sensor takes a reading — is firmware-configured and determines the temporal resolution of the data.

Common sampling rates in industrial IoT deployments:

• Temperature: 1–15 minute intervals (thermal changes are slow)
• Vibration (RMS average): 1–5 minute intervals for condition monitoring
• Current/power: 15-second to 1-minute intervals for energy monitoring
• GPS position: 30-second to 5-minute intervals for asset tracking
• Event-based: Device reports immediately on a defined trigger (door open, threshold breach) regardless of the scheduled interval

The sampling rate and the transmission schedule are independent in many sensor designs. A sensor may sample at 1-minute intervals but only transmit if the value has changed beyond a configured threshold (delta compression) or on a scheduled interval (e.g., every 15 minutes regardless of change).

Transmission Timing

For battery-powered LoRaWAN devices, transmission timing is designed for energy efficiency. A Class A device transmits when it has data to send (or on a scheduled interval), then listens briefly for a downlink before returning to sleep. Total active time per transmission cycle: 500 ms to 3 seconds. Sleep time between transmissions: minutes to hours.

For always-on MQTT devices connected via Ethernet or Wi-Fi, data is published to the MQTT broker as soon as it is ready — no battery-driven sleep cycle.

Layer 2: Connectivity Layer

The connectivity layer is the radio link between the device and the network infrastructure.

LoRaWAN Path

A LoRaWAN transmission:

1. Device generates the uplink payload (typically 10–50 bytes for a sensor reading)
2. LoRa radio transmits the payload over the 915 MHz (US) band
3. One or more LoRaWAN gateways within range receive the packet
4. Gateways forward the packet to the network server (IoT SimpleLink) via standard internet or local network
5. IoT SimpleLink authenticates the device, deduplicates packets from multiple gateways, decrypts the payload, and forwards the decoded data to VX-Olympus via HTTPS POST

LoRaWAN gateway-to-network-server transmission adds 100–500 ms latency. IoT SimpleLink processing and forwarding adds 200–800 ms. Total connectivity layer latency for LoRaWAN: 0.5–1.5 seconds after the radio transmission completes.

MQTT Path

An MQTT device connects directly to VX-Olympus’s MQTT broker over TCP/IP. The publish-subscribe model provides near-real-time delivery:

1. Device publishes a message to a device-specific topic
2. VX-Olympus MQTT broker receives the message
3. Internal broker routing delivers the message to the VX-Olympus data ingestion service

MQTT broker-to-ingestion latency: 10–100 ms for a well-configured deployment.

Other Protocols

HTTP/HTTPS POST: Device makes an HTTP request to VX-Olympus ingestion endpoint. Latency similar to MQTT for single-message posts; slightly higher for large payload sizes due to TCP connection overhead.

Modbus/OPC-UA: These are polled protocols. The VX-Olympus Modbus/OPC-UA client periodically requests data from the target device. Effective latency is determined by the poll interval — a 30-second poll interval means maximum 30-second data freshness.

Layer 3: Ingestion and Protocol Handling

The ingestion layer receives raw device data and normalizes it to VX-Olympus’s internal data model.

Payload Decoding

Most IoT sensor devices send binary payloads — compact, encoded data that requires a decoder to parse. For example, a LoRaWAN temperature sensor might send a 4-byte payload where bytes 0–1 represent temperature (signed 16-bit integer, 0.01°C resolution) and bytes 2–3 represent battery voltage.

VX-Olympus stores a payload decoder for each device profile — a JavaScript function that transforms the raw bytes into named fields with units:

function decode(bytes) {
  return {
    temperature: (bytes[0] << 8 | bytes[1]) * 0.01,
    battery_mv: (bytes[2] << 8 | bytes[3])
  };
}

Decoded data maps to the device’s telemetry model — defined field names, data types, and units. This normalization means the rule engine and storage layer work with consistently structured data regardless of the device hardware or payload encoding.

Device Authentication

Each incoming message is validated against the device registry:

• Is this device registered?
• Is the authentication credential valid?
• Is the device within its allowed message rate?

Messages from unregistered devices or with invalid credentials are rejected. Rate limiting prevents a malfunctioning device from flooding the ingestion pipeline.

Latency at this layer: 50–200 ms

Layer 4: Rule Engine Processing

After ingestion, each telemetry message passes through the rule engine for evaluation against configured rule chains.

Node-RED Rule Evaluation

VX-Olympus uses Node-RED as the visual rule execution environment. Rule chains are evaluated asynchronously — the telemetry message triggers evaluation in parallel with storage write, so rule evaluation does not add to the storage latency path.

A typical rule chain evaluation:

1. Incoming telemetry message received by the rule engine
2. Filter nodes evaluate whether this message is relevant (right device type? right time of day?)
3. Threshold comparison node evaluates the telemetry value against configured threshold
4. If threshold exceeded: action nodes execute (send SMS, POST webhook, write to device state)
5. If threshold not exceeded: message logged and chain exits

Complex rules with multiple conditions (AND/OR logic across multiple telemetry fields or multiple time windows) add additional evaluation time.

Rule engine latency: 50–500 ms depending on rule complexity. Simple threshold rules evaluate in under 100 ms. Multi-condition rules with historical data lookups may take up to 500 ms.

Alert Delivery

When a rule chain triggers an alert action:

• SMS notification: 5–30 seconds (depends on SMS gateway)
• Email notification: 5–60 seconds (depends on email delivery)
• Webhook POST: 200 ms–2 seconds (depends on target endpoint response)
• In-platform notification: appears immediately at next dashboard refresh

Layer 5: Storage Layer

Time-Series Storage

Telemetry data is written to VX-Olympus’s time-series database after ingestion. The database is optimized for:

• High write throughput (thousands of data points per second)
• Time-range queries (all readings for device X between time A and time B)
• Aggregation queries (hourly average, daily max/min) computed efficiently

Each telemetry entry stores: device ID, timestamp (millisecond precision), field name, value, and quality flags.

Write latency: 10–50 ms for a standard telemetry write.

Device State

Beyond time-series history, VX-Olympus maintains a current state record for each device — the last reported value for each telemetry field. This state record is the source for dashboard real-time widgets (gauges, status indicators) — they read from the state record rather than querying historical time-series, which enables low-latency dashboard updates.

State update latency: 10–30 ms after storage write.

Layer 6: Presentation Layer

Dashboard Widget Rendering

VX-Olympus dashboards connect widgets to data sources:

• Real-time widgets (gauges, status indicators): Subscribe to device state updates via WebSocket. The widget updates whenever the device state changes — no polling required.
• Historical widgets (trend charts, analytics): Query time-series data for the configured time window on load, then subscribe to new data appended in real time.

Dashboard update latency after state write: 100–500 ms (WebSocket delivery + browser rendering).

End-to-End Latency Summary

The dominant latency component is the device’s transmission schedule — a sensor that reports every 15 minutes has a maximum data freshness lag of 15 minutes regardless of how fast the rest of the pipeline runs. For event-driven sensors that transmit immediately on threshold breach, the pipeline-to-dashboard path runs in 2–10 seconds for MQTT-connected devices.

Deployment Sizing Considerations

VX-Olympus’s cloud deployments (AWS, Azure) scale horizontally — additional processing capacity is added at the ingestion, rule engine, and storage layers as device count grows. A deployment handling 100 devices uses the same architecture as one handling 100,000 — the underlying infrastructure scales to match the load.

On-premises deployments size the server hardware to the expected device count and telemetry rate. The architecture scales from pilot to 10,000-device deployment. General guidelines for on-premises server sizing:

• Under 1,000 devices: standard 4-core, 16GB RAM server
• 1,000–10,000 devices: 8–16 core server with 32–64GB RAM and SSD storage
• Above 10,000 devices: distributed deployment with separate ingestion, processing, and storage nodes

Data Retention

VX-Olympus stores time-series telemetry at configured retention periods:

• Default retention: 1 year for raw telemetry
• Aggregated data (hourly/daily summaries): indefinite by default
• Configurable: retention can be adjusted per device group or per organization

Related Technical Briefs

This brief covers the overall pipeline architecture. Related briefs cover specific layers in depth:

• Technical Brief: MQTT vs HTTP vs CoAP — Choosing the Right IoT Protocol — connectivity layer protocol selection
• Technical Brief: Rule Chains and Business Logic in VX-Olympus — rule engine depth
• Technical Brief: Multi-Tenant Security Architecture — security and RBAC

Talk to our team about sizing a VX-Olympus deployment for your device count and latency requirements.