Making Legacy Hardware Smart: Containers for Existing Machinery
David Hussain 3 Minuten Lesezeit

Making Legacy Hardware Smart: Containers for Existing Machinery

In the theory of Industry 4.0, everything is interconnected, speaks OPC-UA, and delivers clean data streams. The reality in German factory halls is different: milling machines, presses, and injection molding machines that are 10, 15, or even 20 years old. This “legacy hardware” performs mechanically perfectly but is a digital black box.

In the theory of Industry 4.0, everything is interconnected, speaks OPC-UA, and delivers clean data streams. The reality in German factory halls is different: milling machines, presses, and injection molding machines that are 10, 15, or even 20 years old. This “legacy hardware” performs mechanically perfectly but is a digital black box.

For OT decision-makers, the question arises: Do I need to renew the machinery park with million-dollar investments to benefit from AI and data analysis? The answer is: No. With edge containers, we build a digital bridge between old mechanics and modern IT.

The Problem: Language Barriers and Outdated Protocols

Existing machines are often digital islands. They use protocols like Modbus RTU, Profibus, or proprietary serial interfaces.

  1. No Connectivity: The control system often doesn’t even have an Ethernet port.
  2. Lack of Security: Old control systems (SPS/PLC) have no encryption; connecting them directly to the network would be a security risk.
  3. Rigid Logic: Modifications to the machine software are risky, expensive, or impossible due to lack of source code.

The Solution: The Container as a “Universal Translator”

Instead of changing the machine, we place an edge gateway with Kubernetes right next to it. This acts as an interpreter and security guard.

1. Protocol Adapters in Containers

We use specialized container applications (e.g., based on Node-RED or industrial protocol stacks) that speak the language of the old SPS.

  • The Process: The container reads the machine’s registers (e.g., via Modbus), translates the raw data into a modern format (like JSON or MQTT), and sends it to the edge cluster.
  • The Advantage: The machine remains untouched. We only “listen” without disturbing the sensitive process flow.

2. Data Pre-Processing at the Edge

Old machines often produce unstructured data volumes. Transmitting these unfiltered would overload any network.

  • Within the Kubernetes cluster on the shop floor, we prepare the data. We filter out noise, aggregate values, and only send the relevant information (“machine stopped”, “vibration out of norm”) further.

3. Security Through Encapsulation

The edge cluster forms a protective layer. The legacy machine communicates only locally with the gateway. Only the gateway, protected by modern security mechanisms (as described in the previous post), communicates with the rest of the IT world.


Conclusion: Digitization in Existing Systems is an Architecture Topic

You don’t have to scrap your machinery park to become modern. By using containers on a stable edge infrastructure, we make legacy hardware “cloud-ready”. This way, you extend the lifecycle of your equipment and simultaneously gain the data sovereignty you need to optimize your production.

Do you have machines that “don’t communicate”? ayedo supports you in cost-effectively digitizing your existing machinery park and integrating it into your modern data platform.


FAQ

Does the SPS programming need to be changed for the connection? In most cases, no. We use existing communication interfaces of the control system. The container on the edge gateway acts as a passive or active participant on the fieldbus without touching the core code of the machine.

What happens if the edge gateway fails? The machine continues to operate autonomously. Since we only flank the control level for data acquisition and do not replace the primary process logic, the mechanical availability of the system remains 100% intact.

How do we scale this to 50 different machine models? That’s the strength of Kubernetes. We create a standardized container image (template) for each machine type. During rollout, only the specific IP address or register list is configured. This turns an individual tinkering project into a scalable standard.

Can we also send commands to the machine via these containers? Technically, this is possible (e.g., for setpoint specifications). For security reasons, however, we implement strict “write-policies” and manual approval processes to ensure that no unauthorized interventions in the process occur.

Ähnliche Artikel