The Digital Twin Architecture Guide: From PLC to WebSocket, End to End

What a digital twin actually is

A digital twin is a real-time, synchronized, virtual representation of a physical asset, process, or system. Three things make it a “twin” and not a “model”:

• Real-time data — sensor values from the physical asset, refreshed at the rate the asset changes (100ms for motor vibration, 1s for HVAC, 1m for energy).

• Bidirectional control — write-back to the physical asset (e.g. setpoint changes, start/stop commands), with the same auth and audit as human operators.

• Persistent state — the twin knows its history, not just its current state. You can ask “what was the temperature at 3am Tuesday” and get an answer.

Anything missing one of these three is a dashboard, not a twin.

Layer 1: The physical layer — PLCs, sensors, instruments

The bottom of the stack. Motor vibration sensors, temperature RTDs, pressure transmitters, flow meters, vision cameras, encoders. All connected to a PLC (Siemens S7, Allen-Bradley ControlLogix, Mitsubishi, Beckhoff) or an edge gateway directly.

Protocol mix you’ll see in a real plant

• OPC-UA — modern, secure, self-describing. The default for new installations. ~60% of the modern plants we work with.

• Modbus TCP / RTU — the lingua franca. 30-year-old protocol, still everywhere. ~30% of connections.

• Siemens S7 — Siemens-proprietary, but ubiquitous in European / Indian industrial sites. We have a dedicated S7 driver.

• EtherNet/IP, BACnet, PROFINET — vendor-specific, common in their respective niches.

A real plant has 3-5 protocols running simultaneously. The edge gateway has to speak all of them.

Layer 2: The edge gateway — the unsung hero

The edge gateway is the most important component in the stack. It does five things:

• Protocol translation — Modbus/OPC-UA/S7 in, MQTT out.

• Store-and-forward — local disk cache (typically 24-48 hours) so a network outage doesn’t lose data.

• Local compute — run a small inference model (anomaly detection on vibration), filter noise, aggregate.

• Security boundary — TLS termination, certificate management, mTLS to the cloud broker.

• OTA management — the gateway is remotely updatable. We use BalenaOS or K3s for this.

Hardware we ship

• Small plants (1-10 machines): Raspberry Pi CM4 with industrial I/O hat, or Advantech UNO-220.

• Medium plants (10-100 machines): Advantech MIC-770 V3 or Siemens IOT2050.

• Large plants (100+ machines): Dell Edge Gateway 5200 or HPE Edgeline EL300.

• Air-gapped plants: Same hardware, no internet uplink, only outbound to a private broker on a leased line.

The software stack is the same across all of these: K3s (lightweight Kubernetes) + Mosquitto or EMQX for MQTT + our custom protocol drivers as containers.

Layer 3: The Unified Namespace (UNS) — the data spine

The UNS is the topic hierarchy that every system in the plant publishes to and subscribes from. It’s the central nervous system.

The structure

factory/
  site-1/                    # physical site
    area-A/                  # logical area
      line-1/                # production line
        milling/             # specific machine
          vibration/         # sensor type
            rms              # specific measurement
            peak
            kurtosis
          temperature/
            bearing
            winding
          status/
            running
            fault
            e-stop

Every sensor value in the plant has a unique, hierarchical topic. Any system (dashboards, analytics, ML models, ERP integrations) can subscribe to any slice.

Why UNS is the answer to “where does this data go?”

Without UNS, you have point-to-point integrations: every dashboard, every ML model, every ERP system needs a direct connection to every machine. That’s N×M connections. Adding a new dashboard means re-wiring every machine.

With UNS, every machine publishes to one broker. Any new dashboard subscribes to the broker. That’s N+M connections. Adding a new dashboard means subscribing to topics you already care about.

The UNS pattern is from the Industrial Internet Consortium’s Industrial Internet Reference Architecture. It’s not new. It’s just that most plants haven’t adopted it.

Layer 4: Time-series storage

The UNS broker doesn’t store data long-term. It forwards. The long-term home is a time-series database.

Our default stack

• TimescaleDB — for OT/IT data with relational structure (production orders, batch IDs, shift metadata).

• InfluxDB — for pure time-series (vibration, temperature, pressure).

• ClickHouse — for OLAP queries (cross-plant analytics, OEE rollups).

• QuestDB — for the most extreme ingest rates (1M+ samples/sec).

For 80% of engagements, TimescaleDB alone is enough. The others are for specific scale requirements.

Retention policy

Storage is cheap, but query performance degrades with table size. We use a tiered retention policy:

• 30 days hot (SSD, full resolution)

• 1 year warm (compressed, 1-minute resolution)

• 5 years cold (S3 / Glacier, 1-hour resolution)

• Forever summary (daily / weekly / monthly rollups, never deleted)

Layer 5: The twin application

The top of the stack. The 3D scene, the dashboard, the alerts. What the user actually sees.

Three options we ship

• Web-based 3D twin (Three.js / WebGL). Most flexible, runs in any browser, no install. Best for 80% of cases. We’re shipping this on the Ideaxa demo site.

• Unity / Unreal. For photorealistic visualization (marketing, customer demos, training simulators). 5-10x the engineering cost.

• Native mobile (iOS / Android). For operators in the field, on tablets. React Native + Expo is our default.

WebSocket path from broker to browser

The browser can’t speak MQTT. The pattern we use:

• Browser opens a WebSocket to the edge server.

• Edge server is subscribed to the relevant MQTT topics.

• Messages are forwarded to the browser over WebSocket with a binary or JSON protocol (we use MessagePack for 4x payload reduction).

• Browser parses the message, updates the 3D scene and the dashboards.

End-to-end latency from PLC to browser: typically 200-500ms. Acceptable for monitoring, borderline for control. For control, you bypass the browser and write to the PLC directly via the broker.

Security: ISA/IEC 62443, zones and conduits

Industrial security is a different beast from IT security. The same “zero-trust” principles apply, but the implementation is constrained by legacy equipment and 24/7 operations.

Zones and conduits

ISA/IEC 62443 (the industrial security standard) defines security in terms of zones (groups of assets with similar security requirements) and conduits (the communication paths between zones, with controlled access).

A typical plant has 4-6 zones:

• Zone 0: Safety systems (E-stops, safety PLCs) — highest security, air-gapped if possible

• Zone 1: Critical control (line PLCs, motor drives) — high security, no internet

• Zone 2: Supervisory (SCADA, HMI) — high security, restricted internet

• Zone 3: Operations (MES, historians) — moderate security, controlled internet

• Zone 4: Business (ERP, email) — standard IT security

• Zone 5: External (cloud, vendor remote access) — high security, brokered through DMZ

Each conduit (the connection between zones) has a defined security level, audit logging, and access control. We design and audit these for every engagement.

What this costs, in 2026

Real numbers from a recent Ideaxa engagement for a 50-machine plant:

• Edge hardware: 6 × Advantech MIC-770 at $1,800 each = $10,800

• Network: Managed switches, VLAN config, firewall = $15,000

• Cloud infrastructure: TimescaleDB, MQTT broker, WebSocket gateway on AWS = $1,200/month

• Engineering (one-time): 12 weeks of work at $100/hr = $48,000

• Managed operations (ongoing): 40 hours/month at $120/hr = $4,800/month

Total first-year cost: ~$130,000. Annual operating cost after handover: ~$72,000.

For a 10-plant, 500-machine deployment, multiply by 8-10x, with most of the cost being edge hardware and engineering. Cloud cost scales sub-linearly.