architecture

System Overview

How Twinise devices, cloud services, and Unreal runtime components work together.

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 (device/<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, humidity, and pressure (BME280 sensor nodes)
  • Energy, vibration, air-quality, and other readings via simulated device types used during development

Cloud Layer

Cloud services are responsible for:

  • Device registry and online/offline status
  • MQTT ingest of device telemetry
  • Time-series persistence
  • Stream fanout to consumers over STOMP on secure WebSockets (including Unreal clients)

Devices publish JSON to per-device topics; the platform's listener service ingests and stores accepted frames.

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
  • UI overlays

Core Data Flow

  1. Sensor sample is captured on device.
  2. Device publishes a JSON payload with timestamp and 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

  • Platform API and client streams use TLS (HTTPS/WSS); device transport authentication and hardening are in active development
  • Per-device access tokens are delivered at provisioning over BLE, not compiled into firmware
  • Devices retry the connection a bounded number of times, then resume at the next wake cycle
  • The hub gateway buffers telemetry in memory and uploads in batches; battery devices publish once per wake cycle

Related Pages