Connecting data from old machines into a database sounds like something that can be solved by buying a gateway. Those who have actually done it know this isn't the case. Protocol conversion is usually the fastest step to complete, but the real engineering time is spent after the conversion.
This article aims to explain why there are still two layers of discrepancy between "protocols are connected" and "data can be used for decision-making."
First Layer: Different Protocols
This is the most obvious and easiest layer to handle. A common situation in the same factory is: equipment from ten years ago uses Modbus RTU, five years ago uses Modbus TCP, new equipment supports OPC UA, some specialized machines only have the vendor's proprietary protocol, and a few machines only output CSV to an industrial PC.
This layer has mature solutions. Gateways, protocol converters, and OPC UA servers can unify different physical interfaces into a single reading method. Most integration projects feel good about their progress here because they can see numbers starting to flow.
The problem is, numbers flowing does not equal numbers being usable.
Second Layer: Different Time Baselines
Every piece of field data has a timestamp, but the source of that timestamp is often inconsistent.
- A PLC's timestamp might be a count since the device was powered on, not an absolute time.
- The timestamp added by a gateway is "the time it was read," not "the time the event occurred"; the difference between the two depends on the polling cycle.
- Clocks on different devices drift independently, potentially differing by tens of seconds after a week.
- Data retransmitted after a network interruption may arrive in a different order than the order in which events occurred.
Trend charts for a single device are unaffected. However, if you want to answer "Did the vibration anomaly on device A occur after the batch change on device B?", the discrepancy in time baselines will directly make the answer unreliable. And cross-device causal relationships are precisely what the field most wants to know.
This layer doesn't require a faster network, but rather a clear explanation of each timestamp's source, precision, and correction method, and making this explanation visible to subsequent users.
Third Layer: Different Semantics
This layer is discussed the least, yet it most often stalls projects in later stages.
Two devices from different manufacturers both output a field called "temperature." One measures the bearing casing, the other measures the coolant inlet. Both have a status bit called "in operation," but one includes warm-up time, while the other does not. Three shifts each have their own habits for defining the completion time of a "line change."
When this data is imported into the same table and plotted on the same dashboard, the differences are masked by visual uniformity. Any subsequent judgment based on this table inherits this error, and it becomes very difficult to trace back.
Semantic discrepancies cannot be automatically eliminated by technology, because it's not a technical problem—it's knowledge of "what this field represents in this factory, on this line, for this shift," residing in people's minds. What can be done is to explicitly write down this knowledge and bind it to the data, allowing every use to trace back to its definition.
So, What Needs to Be Solved?
If the goal is merely "to store numbers," completing the first layer is sufficient. If the goal is "to enable this data to support traceable decisions," then the real work lies in addressing the latter two layers:
- Traceable Source: Every piece of data can state which device it came from, through which process, and how it was obtained.
- Interpretable Time: The source and precision of timestamps are known, not assumed to be reliable.
- Defined Semantics: The meaning of a field has a clear owner, and changes are recorded.
- Assessable Quality: Users know under what circumstances this data should not be used for judgment.
These four things cannot be retroactively added after integration is complete, because by then the original context is lost. They must be preserved simultaneously at the moment of connection.
X·Neurons' Role in This Matter
X·Neurons' Protocol Adaptive Connector (PAC) addresses precisely this scope: simultaneously bringing in source, time baseline, and semantic definitions when connecting devices, rather than just transferring values. Currently, all X·Neurons capabilities are in a candidate state; we are describing expected behavior in co-validation, not released, directly purchasable features.
It's also important to clarify the boundaries: this approach will not replace your existing PLC, SCADA, or MES, nor will it automatically generate semantic definitions—that step still requires the participation of people familiar with the field. What it can do is ensure that once these definitions are written down, they can be continuously applied and traced by the system.
If You Are Currently Evaluating
Regardless of which approach you ultimately choose, there are a few questions worth clarifying beforehand, as they determine whether the data will still be usable after integration is complete:
- Who generated the timestamp for this data? What is the margin of error?
- Where is the definition of this field written? Who has the authority to change it?
- When equipment is replaced or firmware is upgraded, how is the comparability of existing data handled?
- If, three years from now, you need to look back at the basis for a judgment, can it be traced?
Asking these questions now costs a few meetings. Discovering them only after integration is complete costs a rework.