System Overview

Twinise is a telemetry pipeline for digital twin workflows. It moves data from field hardware to cloud ingestion, then into Unreal Engine for real-time visualization and logic.

Architecture At A Glance

Twinise has four layers:

1. Edge devices collect signals from sensors.
2. Devices publish structured telemetry over MQTT to per-device topics (devices/<id>/telemetry).
3. Twinise Cloud ingests, stores, and routes device streams.
4. Clients — including the Unreal runtime — subscribe over STOMP on secure WebSockets and bind values to scene behavior.

Edge Layer

Devices are provisioned over BLE with:

• Wi-Fi credentials
• A per-device access token

The hardware ID is factory-assigned and encoded in the device's QR label; the publish interval is set in firmware.

Typical metrics include:

• Temperature and humidity
• Light, time-of-flight distance, and IMU motion

Other sensor types, vibration among them, we integrate on request.

Cloud Layer

Cloud services are responsible for:

• Device registry and online/offline status
• MQTT ingest of device telemetry through a Mosquitto broker
• History stored at 1-second resolution, written in batches at most 60 seconds behind live
• Stream fanout to consumers over STOMP on SockJS/WebSockets (including Unreal clients)

Devices publish JSON to per-device topics; the platform's listener service forwards every frame to live subscribers immediately, then batches it into storage.

Runtime Layer (Unreal)

The Unreal plugin receives telemetry, maps device_id values to actors/components, and updates runtime systems:

• Material parameters
• Niagara systems
• Gameplay/logic events
• Render-target and composite heatmaps

Core Data Flow

1. Sensor sample is captured on device.
2. Device publishes a flat JSON payload of metric keys.
3. Cloud ingests the payload, stores it, and streams it to subscribers.
4. Unreal client receives update and applies bindings.

Security And Reliability Baseline

• Devices authenticate to the broker with their device ID and access token, validated by the platform; a device may publish only to its own topics
• Platform APIs and client streams run over TLS; device transport hardening is in active development
• Per-device access tokens are delivered at provisioning over BLE, not compiled into firmware
• Battery devices sleep between publishes and reconnect on the next wake cycle
• The platform marks a device connected on broker authentication, active on its first telemetry frame, and disconnected when the session drops

Related Pages

• Unreal Engine Integration
• Telemetry Schema Baseline
• Troubleshooting Guide