Digital Twin Series · Level 1 · Communication
Digital Twin Communication and Data Integration
Which protocol should carry this data, where does it sit in the plant network, and how do PLC tags become model variables?
A digital twin is only as good as the data that reaches it. This page covers the three decisions that make that data arrive reliably: which protocol to use on each link, where each system sits in the factory network and which paths are safe, and how the raw tags in a PLC are scaled, named and sent to the virtual model. It ends with best practices you can tick off for your own project.
A guide, not a rule. It scores the protocols against your answers using typical properties. The device and the network usually decide the last choice.
| Protocol | Type | Typical use | Data model | Speed | Security |
|---|
Speeds are typical, indicative values. Real latency depends on the network, the devices and the settings. Security means what the protocol provides itself: many industrial protocols rely on network security around them.
The Purdue model, as used in ISA-95 and in industrial security. Where the edge gateway and the twin sit depends on the design: the edge usually reads from level 1 and 2 and sends data out through the DMZ, and the twin platform can be on-site or in the cloud.
| PLC tag | Raw value | Scaled | Model variable | Quality |
|---|
Step 1 read the tags, step 2 scale them and check them, step 3 map them to variables of the virtual model and publish them with a time stamp. The scaling shown (0 to 27648 raw counts for the full range) is common on analog inputs of some PLCs, so use the range of your own module.
Report by exception sends a value only when it changes by more than a set band. It saves bandwidth, but keep a periodic heartbeat so the receiver knows the link is alive.
| Layer | Examples |
|---|
Examples only, not a recommendation or a complete list.
Figures and product names are indicative. Check each vendor's current documentation before you plan a project.