Digital Twin Creation Workflow

This tutorial uses the iCraft server cluster status monitoring example to explain step-by-step how to build a real-time monitoring digital twin from scratch — including data planning, 3D element mapping, UI prompt integration, front-end data pushing, interaction, and deployment best practices.


Detailed Steps & Implementation Recommendations

Define Monitoring Metrics & Thresholds

  • Common metrics: CPU usage, memory utilization, service uptime, network throughput, etc.

  • Threshold Strategy (Example):

    • Normal (Green)

    • Warning (Yellow): Metric > 80%

    • Critical (Red): Metric > 90%

    Use distinct colors and icons in the UI/animation for instant anomaly identification. This case uses a similar threshold strategy to switch node state colors.


Prepare 3D Scene & Element Naming

  • In the iCraft Editor, place each server or service node as an independent object in the scene to build a complete interactive 3D environment.

  • Naming Convention: Assign predictable element names (e.g., SVC-DTS-01, SVC-DB-02). The front-end script will locate elements precisely via player.getElementsByName(name).

  • For overall cluster status visualization, prepare different materials or animations for each state (e.g., flashing, breathing highlight, pipeline flow effects).


Design Status Cards & Tips

  • Tip:For quick single-point inspection; keep design concise (service name, status icon, key values).

  • StatusCard:Persistent or click-triggered data card, supporting frosted glass / card UI styles.


Integrate iCraftPlayer

Use @icraft/player-react to import and render the player in your component:

onReady:After the scene is ready, use player.getElementsByName(...) to find default active elements and initialize tooltips. onClick:When the user clicks a scene element, clear old tooltips, then create/inject a new StatusCard container based on the current mode and display content.

  • Properly manage element.tip (reset, updateInnerHTML, updateVisible).

  • Clear old fixed containers on click to avoid DOM memory leaks.


Data Flow & Update Mechanism (Simulated or Real Push)

  • Update Frequency: Refresh activeData every 100ms to simulate near-real-time monitoring (in production, frequency depends on data source and performance). Use setInterval(..., 100) to configure the interval.

  • Data Acquisition: Connect via WebSocket, Server-Sent Events, or timed REST API polling. Map latest data to corresponding elements and update the StatusCard DOM content.

  • Concurrency & Throttling: For large node volumes, use throttling, batch updates, or update only visible/focused nodes to reduce rendering overhead.


Interaction Modes: Floating / Fixed

  • Floating Tooltip: Follows the mouse or element position for quick inspection; suitable for exploratory monitoring.

  • Fixed StatusCard: Toggled via a switch. Creates a fixed DOM container attached to the player (e.g., top-right corner) for persistent display of critical node information.


State Visualization Strategy

  • Combine colors (green/yellow/red), icons, and simple animations (breathing / flashing) for fast anomaly detection in the global view.

  • When data exceeds thresholds:

    • Change material color

    • Trigger element “alert animation”

    • Highlight alarm items on the StatusCard

  • For critical alerts, add sound or global pop-up reminders (use sparingly to avoid noise and false alarms).


Testing, Performance & Deployment

  • Local Testing: Validate data updates, interactions, and visuals using a local data simulator first.

  • Performance Monitoring: Track FPS, memory usage, and DOM node count. Mass real-time updates may cause bottlenecks; reduce refresh rate or switch to event-driven updates (only on data changes) if needed.

  • Security: For real data streams, ensure authentication and TLS encryption on WebSocket/HTTP channels to prevent sensitive data leakage on the client.

  • Deployment: Package the final scene as .iplayer or embed it into a web page for integration into monitoring dashboards or control consoles.


Demo


Sample Code Structure

index.tsx:React entry component. Manages iCraft Player initialization, user interaction, tooltip/fixed card display, and timed data update logic.


index.module.css:Page-level layout styles for index.tsx.


StatusCard.tsx:React component for rendering service node status cards and state UI.


StatusCard.module.css:Style definitions for StatusCard.tsx.


interface.ts:Type interface module defining component data structures and type constraints.


utils.ts:Utility and simulated data source module for fetching/generating real-time data.

Last updated