Your Industrial Data Translator Is Holding You Back

The Protocol Problem Was Real. It Was Solved.

Cast your mind back to the early days of industrial connectivity. Your plant floor was a communications nightmare. Modbus talking to nothing, OPC DA servers that required Windows workstations, PLCs from three different vendors using three different communication stacks. The idea that a single piece of software could sit in the middle and speak every language was genuinely revolutionary. That is the world Kepware, MatrikonOPC, and Cogent Real Time Systems were built for. And for that world, they were excellent. 

Kepware's KEPServerEX became an industry standard because it did one thing remarkably well: it connected industrial devices to SCADA, historians, and HMI systems through a reliable OPC bridge. MatrikonOPC filled a similar role, particularly in process industries where complex OPC configurations demanded deep protocol expertise. Products like Litmus Edge and Cumulocity extended that idea to the containerized edge, making it possible to run lightweight data collection agents closer to the equipment.

These tools earned their reputations. But the manufacturing world has changed, and the gap between what a traditional data translator provides and what modern operations actually need has grown from a crack into a chasm.

What a Traditional Data Translator Actually Does

At their core, tools like Kepware and MatrikonOPC are protocol translators. They read raw tag values from a machine, spindle speed, temperature, pressure, alarm status, and republish that data in a format another system can consume, typically OPC UA or OPC DA. That is the entire job. 

The data enters the translator as a raw number. It leaves as a slightly differently formatted raw number. Nothing has been learned about that number. Nothing has been done to understand whether it's normal, dangerous, or trending toward failure. The translator has no memory of what that value was yesterday, last week, or last year.

 To be fair, that was never the translator's job. Traditional architectures expected a historian to store the data, a separate SCADA system to display it, and a data scientist or an expensive analytics platform bolted on top to make sense of it. The translator was just the pipe. 

The problem is that the pipe model creates compounding costs and delays at every stage of the data journey.

The Hidden Cost of the Pipe Model

Configuration takes months, not hours

Setting up a Kepware server for a complex production line is not a quick exercise. A skilled integrator must manually browse device tag trees, map OPC addresses, configure update rates, handle scaling and engineering unit conversions, and then test every connection individually. For a plant with 50 machines and 200 tags each, that's a project measured in weeks or months, not hours.

The resulting configuration lives in a proprietary binary format. It can't be version-controlled in Git. It can't be reviewed in a pull request. It can't be generated automatically or validated programmatically. When you need to add a machine, change a tag name, or migrate to a new server, you start the manual process over again.

You own the data, but it tells you nothing

 Raw tag data from a traditional translator is valuable as an archive. It is much less valuable as an operational intelligence tool. Kepware does not know that spindle_load = 74.2 is three standard deviations above the baseline and has been trending upward for the past 96 hours. It just knows the value is 74.2. The intelligence layer, anomaly detection, predictive maintenance, pattern recognition, requires a completely separate investment. 

Most manufacturers end up with a fragmented stack: Kepware for collection, a historian for storage, a SCADA for visualization, and a third-party AI/ML tool for analysis. Each of these layers carries its own licensing costs, integration requirements, vendor relationships, and failure modes.

Lock-in by design

Traditional translators use proprietary configuration formats that create switching costs which effectively lock customers in. The effort of recreating years of configuration work elsewhere is a powerful argument against ever evaluating alternatives.

The Comparison You Should Be Making

When evaluating industrial data platforms today, the right question is not just "what protocols does it support?" every serious platform supports OPC UA, Modbus, and Ethernet IP. The right questions are: 

• How long does it take to configure and deploy?
• Does it get smarter over time, or does it stay static?
• Can I describe what I want and have it built myself?
• Does it reduce the number of systems I need to maintain?
• Is my configuration portable, version-controlled, and auditable?
• Can it tell me when something is about to break before it breaks?

Measured against these questions, the gap between traditional translators and AI-powered alternatives like DIME becomes clear.

Traditional industrial data translators were built to solve the protocol problem, and they solved it well. But the manufacturing world now demands more than data movement; it demands data intelligence. Stack fragmentation, manual configuration overhead, and the absence of built-in AI are not just inconveniences; they are competitive disadvantages. 

Part 2 explores what an AI-powered data translator looks like, and why DIME represents a genuinely different category of solution.