Brownfield-Integration: Alte Maschinen mit moderner Software verbinden

Die Maschine läuft seit 20 Jahren.

Mechanisch funktioniert sie einwandfrei. Die Steuerung arbeitet zuverlässig. Ersatzteile sind verfügbar. Die Mitarbeiter kennen die Anlage und der Produktionsprozess ist eingespielt.

Eigentlich gibt es keinen Grund, sie zu ersetzen.

Dann kommt die Digitalisierung.

Plötzlich sollen Produktionsdaten automatisch erfasst werden. Ein Dashboard soll den Maschinenstatus anzeigen. Das MES benötigt Stückzahlen. Die Qualitätssicherung möchte Prozesswerte auswerten und vielleicht sollen ausgewählte Daten später auch für Energiemanagement, Predictive Maintenance oder KI-Anwendungen zur Verfügung stehen.

Und genau dann stellt sich eine vermeintlich einfache Frage:

Wie bekommen wir die Daten aus der Maschine heraus?

Bei modernen Anlagen lautet die Antwort möglicherweise OPC UA, MQTT oder eine dokumentierte API. Bei älteren Maschinen sieht die Realität häufig anders aus.

Dort findet man:

• serielle Schnittstellen,
• proprietäre TCP-Protokolle,
• Modbus,
• Profibus,
• herstellerspezifische SPS-Kommunikation,
• OPC Classic,
• digitale Ein- und Ausgänge,
• Datenbanken,
• CSV-Dateien,
• oder manchmal überhaupt keine vorgesehene Datenschnittstelle.

Genau diese Situation bezeichnet man als Brownfield-Integration.

Es geht nicht darum, eine neue Fabrik vollständig digital zu planen. Es geht darum, eine bestehende Produktionslandschaft Schritt für Schritt mit moderner Software zu verbinden. Und das ist häufig deutlich schwieriger.

Was bedeutet Brownfield eigentlich?

Der Begriff stammt aus der Unterscheidung zwischen Greenfield und Brownfield.

Bei einem Greenfield-Projekt kann eine neue Anlage weitgehend von Grund auf geplant werden. Kommunikationsschnittstellen, Netzwerke, Security, Datenmodelle und IT-Integration können von Anfang an berücksichtigt werden.

Brownfield bedeutet dagegen: Die Infrastruktur existiert bereits.

Die Produktion läuft. Maschinen verschiedener Generationen und Hersteller sind vorhanden. Steuerungen wurden möglicherweise mehrfach modernisiert. Teile einer Anlage stammen aus den 1990er-Jahren, andere wurden erst vor wenigen Jahren ergänzt.

Die OPC Foundation beschreibt Brownfield-Systeme als bestehende Produktionssysteme, deren interne Datenmodelle häufig vorhanden sind, aber nicht automatisch standardisiert oder maschinenlesbar beschrieben werden. Genau für solche Szenarien behandelt die OPC-UA-Spezifikation ausdrücklich das nachträgliche Retrofit bestehender Maschinen. (OPC UA Online Reference)

Brownfield ist damit eigentlich der Normalfall vieler Produktionsbetriebe. Und genau deshalb reicht es nicht, Digitalisierung nur für neue Maschinen zu planen.

Alt bedeutet nicht schlecht

Eine wichtige Erkenntnis bei Brownfield-Projekten lautet:

Eine alte Maschine ist nicht automatisch eine schlechte Maschine.

Eine mechanisch robuste Produktionsanlage kann noch viele Jahre wirtschaftlich arbeiten. Das Problem liegt häufig nicht in ihrer eigentlichen Funktion. Das Problem liegt an der Grenze zur modernen IT.

Eine ältere Maschine wurde möglicherweise zu einer Zeit entwickelt, als niemand damit gerechnet hat, dass ihre Daten eines Tages in einem Web-Dashboard, einem zentralen MES, einer Cloud-Plattform, einer Datenanalyse oder einer unternehmensweiten API verwendet werden sollen.

NIST weist ausdrücklich darauf hin, dass Legacy-Komponenten die Integration moderner Systeme erschweren können, beispielsweise weil ältere Kommunikationsverfahren oder Sicherheitsmechanismen eingesetzt werden. Gleichzeitig kann der vollständige Austausch solcher Systeme wirtschaftlich oder betrieblich unattraktiv sein. (NIST)

Die interessante Frage lautet deshalb nicht:

„Wie ersetzen wir alle alten Maschinen?"

Sondern:

„Wie schaffen wir eine moderne Schnittstelle um eine Maschine, die selbst nicht modernisiert werden muss?"

Das erste Problem: Jede Maschine spricht eine andere Sprache

Nehmen wir einen fiktiven Produktionsbetrieb. Dort stehen:

Maschine A
Siemens SPS
S7-Kommunikation

Maschine B
ältere Steuerung
Modbus TCP

Maschine C
Herstellerprotokoll über TCP

Maschine D
RS232

Maschine E
OPC Classic

Maschine F
modern
OPC UA

Nun soll ein zentrales Produktionssystem auf alle Maschinen zugreifen. Die naive Lösung wäre:

                 ┌──► Maschine A / S7
                 │
                 ├──► Maschine B / Modbus
Produktionssoftware
                 ├──► Maschine C / proprietär
                 │
                 ├──► Maschine D / RS232
                 │
                 ├──► Maschine E / OPC Classic
                 │
                 └──► Maschine F / OPC UA

Damit muss die zentrale Software plötzlich sechs unterschiedliche Technologien verstehen. Für jede Maschine braucht sie Wissen über:

• Verbindungsaufbau,
• Adressierung,
• Datenformat,
• Datentypen,
• Skalierung,
• Fehlermeldungen,
• Timeouts,
• Reconnect-Verhalten,
• Gerätebesonderheiten.

Das funktioniert vielleicht für fünf Maschinen. Bei 50 oder 200 Maschinen entsteht daraus eine schwer wartbare Integrationslandschaft.

Das eigentliche Ziel ist deshalb nicht Konnektivität

Eine TCP-Verbindung zu einer SPS herzustellen, ist noch keine echte Integration. Auch ein erfolgreich gelesener Registerwert bedeutet noch nicht, dass die darüberliegende Software versteht, was dieser Wert bedeutet.

Angenommen, eine Maschine liefert:

DB20.DBW14 = 327

Technisch wurde ein Wert erfolgreich gelesen. Aber was bedeutet 327?

Ist es eine Temperatur, eine Stückzahl, eine Geschwindigkeit, ein Fehlercode, ein Rohwert eines Sensors, ein Sollwert?

Und falls es eine Temperatur ist:

327 °C?
32,7 °C?
327 K?

Genau hier unterscheidet sich Konnektivität von Integration.

Konnektivität bedeutet: Wir können Daten übertragen. Integration bedeutet: Wir wissen, was diese Daten bedeuten und können sie unabhängig von der konkreten Maschine verwenden.

Deshalb braucht Brownfield eine Übersetzungsschicht

Eine robuste Architektur beendet die herstellerspezifische Kommunikation möglichst nahe an der Maschine. Beispielsweise:

Maschine A
   │
   │ S7
   ▼
Adapter
   │
   ▼
einheitliches Datenmodell

Eine andere Maschine verwendet vielleicht Modbus:

Maschine B
   │
   │ Modbus TCP
   ▼
Adapter
   │
   ▼
einheitliches Datenmodell

Nach oben liefern beide jedoch dieselbe Struktur. Zum Beispiel:

{
  "machineId": "line-01",
  "state": "RUNNING",
  "productionCount": 12431,
  "timestamp": "2026-08-10T13:30:12.428Z"
}

Die zentrale Anwendung muss dann nicht mehr wissen, ob der Wert ursprünglich DB20.DBW14 oder Modbus Register 40127 war. Die technische Besonderheit endet im Adapter.

Das ist eines der wichtigsten Architekturprinzipien für Brownfield-Systeme:

Proprietäre Maschinenkommunikation sollte nicht durch die gesamte Softwarearchitektur getragen werden.

Ein Edge-Gateway kann diese Grenze bilden

Häufig befindet sich diese Übersetzungsschicht direkt im Produktionsnetz. Zum Beispiel auf einem Industrie-PC, einem Edge-Computer, einem Gateway, einem bestehenden Server oder teilweise direkt auf der Maschinensteuerung.

┌──────────── Produktionsnetz ────────────┐

 Maschine A ─┐
 Maschine B ─┼──► Edge Gateway
 Maschine C ─┘          │
                        │
└───────────────────────┼─────────────────┘
                        │
                        ▼
                 moderne Schnittstelle
                        │
                        ▼
                     MES / IT

Das Gateway spricht auf der Maschinenseite beispielsweise S7, Modbus, RS232, proprietäres TCP oder OPC Classic – und stellt nach oben OPC UA, MQTT, AMQP oder REST bereit.

Genau solche Retrofit-Muster werden auch im OPC-UA-Umfeld eingesetzt: Die OPC Foundation zeigt Brownfield-Integrationen, bei denen vorhandene Feld- und Maschinenprotokolle über moderne Controller oder Gateways aufgenommen und anschließend über OPC UA sowie standardisierte Informationsmodelle höheren Ebenen bereitgestellt werden. (OPC Foundation)

Muss deshalb alles auf OPC UA umgebaut werden?

Nein.

OPC UA ist für Brownfield ein sehr wichtiger Baustein, aber kein Selbstzweck. Wo ein Gerät bereits OPC UA unterstützt, ist eine standardisierte Schnittstelle natürlich attraktiv. Besonders interessant wird OPC UA durch seine Möglichkeit, nicht nur Daten zu transportieren, sondern deren Struktur und Bedeutung in einem Informationsmodell abzubilden.

Die OPC Foundation sieht ausdrücklich auch die Möglichkeit vor, vorhandene Maschinen nachträglich über eine OPC-UA-Schicht verfügbar zu machen. (OPC UA Online Reference)

Legacy-Maschine
      │
      │ proprietäres Protokoll
      ▼
Gateway / Adapter
      │
      │ OPC UA
      ▼
MES / SCADA / Datenplattform

Aber nicht jeder Anwendungsfall benötigt zwingend OPC UA. Für bestimmte Datenflüsse kann MQTT sinnvoll sein. Für Backend-Workflows möglicherweise AMQP. Für einzelne Service-Aufrufe REST.

Das Ziel sollte deshalb nicht lauten:

„Wir müssen überall OPC UA verwenden."

Sondern:

„Wir wollen die proprietäre Kommunikation an einer klar definierten Grenze beenden."

Standardisierung beginnt erst oberhalb des Maschinenprotokolls

Nehmen wir drei Maschinen verschiedener Hersteller. Alle besitzen einen Betriebszustand.

Maschine A liefert:

0 = STOP
1 = RUN
2 = ERROR

Maschine B:

10 = READY
20 = ACTIVE
90 = FAULT

Maschine C:

RUNNING = true
FAULT = false

Technisch sind das völlig unterschiedliche Modelle. Für ein zentrales System könnte daraus aber beispielsweise werden:

OFFLINE
IDLE
RUNNING
STOPPED
ERROR

Jetzt besitzt die Gesamtanlage erstmals ein gemeinsames Verständnis eines Maschinenzustands. Genau dasselbe gilt für Produktionsmengen, Auftragsnummern, Geschwindigkeiten, Temperaturen, Qualitätswerte, Störungen, Betriebsarten und Energieverbrauch.

Brownfield-Integration ist deshalb mindestens genauso sehr ein Datenmodellierungsproblem wie ein Kommunikationsproblem.

Nicht jede Maschine kann dieselben Daten liefern

Hier liegt gleichzeitig eine der größten Herausforderungen. Eine neue Maschine liefert vielleicht:

Maschinenzustand
Auftrag
Artikel
Sollgeschwindigkeit
Istgeschwindigkeit
Stückzahl
Ausschuss
Energieverbrauch
Fehlercodes
Wartungsinformationen

Eine ältere Anlage liefert möglicherweise nur:

läuft
steht
Stückimpuls

Ein gemeinsames Datenmodell darf deshalb nicht voraussetzen, dass jede Maschine dieselben Fähigkeiten besitzt. Eine sinnvolle Architektur muss Unterschiede zulassen.

Machine A
Capabilities:
✓ state
✓ productionCount
✓ currentOrder
✓ speed
✓ alarm

Machine B
Capabilities:
✓ state
✓ productionCount
✗ currentOrder
✗ speed
✓ alarm

Das ist wesentlich realistischer als der Versuch, Daten zu erfinden, die eine Maschine technisch gar nicht liefern kann.

Manchmal gibt es überhaupt keine digitale Schnittstelle

Was passiert bei Maschinen, die keinerlei brauchbare Kommunikationsschnittstelle besitzen? Auch dann ist eine Integration oft möglich. Man kann beispielsweise bestehende Signale erfassen:

Maschine läuft        → digitaler Ausgang
Maschine Störung      → digitaler Ausgang
Produktion            → Impuls

Über zusätzliche Sensorik können weitere Informationen gewonnen werden:

Stromaufnahme
Vibration
Temperatur
Druck
Durchfluss

Eine einfache Retrofit-Lösung könnte deshalb so aussehen:

Alte Maschine
    │
    ├── Betriebsignal ─┐
    ├── Störung ───────┤
    └── Stückimpuls ───┤
                       ▼
                    IO-Modul
                       │
                       ▼
                    Gateway
                       │
                       ▼
               Produktionssystem

Damit erhält man vielleicht nicht alle Daten einer modernen Maschinensteuerung. Aber unter Umständen bereits genug für Betriebszustand, Stillstandserkennung, Stückzahl, Laufzeit und einfache OEE-Auswertungen.

Brownfield bedeutet deshalb auch: Mit den vorhandenen Möglichkeiten den größtmöglichen Nutzen erzielen, statt auf perfekte Daten zu warten.

Lesen ist einfacher als Schreiben

Ein weiterer wichtiger Punkt wird bei Retrofit-Projekten häufig unterschätzt. Es macht einen erheblichen Unterschied, ob eine Integration nur Daten liest oder aktiv in die Maschine schreibt.

Daten lesen:
Maschine ─────► Software

Befehle schreiben:
Software ─────► Maschine

Beim Schreiben können Funktionen ausgelöst werden wie Auftrag wechseln, Rezept setzen, Geschwindigkeit verändern, Maschine starten oder Parameter ändern. Damit verändert die IT unmittelbar den Produktionsprozess. Die Anforderungen an Berechtigungen, Validierung, Fehlersicherheit, Auditierung und Zustandsprüfung steigen erheblich.

Deshalb ist es oft sinnvoll, Brownfield-Projekte zunächst read-only zu starten.

Zuerst Daten sichtbar machen. Dann verstehen. Dann standardisieren. Und erst danach entscheiden, welche Rückkanäle tatsächlich notwendig sind.

Ein typischer Einstieg: Maschinenzustände erfassen

Viele Digitalisierungsprojekte starten mit einer sehr einfachen Frage: Welche Maschinen laufen gerade?

Dafür braucht man möglicherweise nur wenige Informationen:

machineId
state
timestamp

Zum Beispiel:

{
  "machineId": "machine-17",
  "state": "RUNNING",
  "timestamp": "2026-08-10T13:42:10Z"
}

Mit diesen Informationen können bereits Fragen beantwortet werden wie: Wie lange war die Maschine produktiv? Wann trat ein Stillstand auf? Wie lange dauerte der Stillstand? Welche Maschinen stehen gerade? Wie unterscheiden sich Schichten?

Erst danach kann die Integration erweitert werden. Zum Beispiel um:

Artikel
Auftrag
Stückzahl
Geschwindigkeit
Störgrund
Qualitätsdaten

Das ist häufig sinnvoller, als beim ersten Projekt sofort jedes verfügbare SPS-Register in eine Datenbank zu übertragen.

Der häufigste Fehler: Wir lesen einfach alles aus

Eine SPS enthält möglicherweise Tausende Variablen. Technisch könnte man versuchen, möglichst viele davon zu speichern. Damit entsteht schnell:

DB1.DBX0.1
DB1.DBW4
DB12.DBD36
DB82.DBX4.5
M120.3
MW204

Ein Data Lake voller solcher Werte ist aber noch keine Digitalisierung. Ohne Kontext weiß später niemand mehr, was ein Wert bedeutet, welche Einheit er besitzt, welche Maschine ihn erzeugt, ob er ein Ist- oder Sollwert ist oder ob seine Bedeutung durch ein SPS-Update verändert wurde.

Deshalb sollte bereits beim Edge- beziehungsweise Integrationslayer aus technischen Adressen eine fachliche Struktur entstehen.

Aus:

DB12.DBD36

wird beispielsweise:

machine.production.speed.actual

value: 128.4
unit: units/min

Damit entsteht aus einem Steuerungswert eine Information.

Semantik wird langfristig wichtiger als das Protokoll

Genau hier liegt eine große Stärke standardisierter Informationsmodelle. OPC UA ermöglicht nicht nur den Transport von Daten, sondern auch deren strukturierte Beschreibung. Companion Specifications standardisieren dabei Modelle für bestimmte Branchen und Maschinentypen. Die OPC Foundation nennt gerade für Brownfield-Szenarien das nachträgliche Mapping vorhandener Daten auf moderne OPC-UA-Modelle als möglichen Retrofit-Ansatz. (OPC UA Online Reference)

Das ist langfristig entscheidend. Denn eigentlich möchte ein MES nicht wissen:

Siemens DB37.DBD4

Es möchte wissen:

ActualSpeed

Eine Datenanalyse möchte nicht wissen:

Modbus Register 40187

Sie möchte wissen:

EnergyConsumption

Und ein Dashboard sollte keinen herstellerspezifischen Fehlercode interpretieren müssen. Es möchte:

MachineState = ERROR

Was passiert, wenn die Verbindung zur IT ausfällt?

Eine Maschine sollte nicht plötzlich stehen bleiben, weil das MES neu gestartet wird, die Internetverbindung ausfällt, die zentrale Datenbank nicht erreichbar ist oder ein Cloud-Dienst gerade eine Störung besitzt.

Deshalb sollte die Produktionsfunktion möglichst unabhängig von der darüberliegenden Datenerfassung bleiben.

              Produktionsprozess
                     │
                     │ funktioniert autonom
                     ▼
                   Maschine
                     │
                     ▼
                Edge Gateway
                     │
              Verbindung gestört
                     X
                     │
                  zentrale IT

Je nach Anwendungsfall kann das Edge-System Daten lokal zwischenspeichern und später übertragen. Solche lokalen Buffering-Mechanismen werden auch bei kommerziellen Brownfield-Gateways eingesetzt, um Daten bei Kommunikationsunterbrechungen nicht unmittelbar zu verlieren. (OPC Connect)

Die Digitalisierung einer Maschine sollte ihre Verfügbarkeit möglichst nicht reduzieren.

Und dann kommt Cybersecurity

Ein besonders kritischer Fehler wäre:

Die Maschine besitzt ein altes Netzwerkprotokoll – also öffnet man dieses Protokoll einfach vom Produktionsnetz bis in die Unternehmens-IT.

ERP
 │
 │
 ▼
Firewall
 │
 ▼
alte SPS

Damit wird eine Legacy-Schnittstelle plötzlich in einer Umgebung exponiert, für die sie ursprünglich möglicherweise nie entwickelt wurde.

NIST weist bei OT-Systemen ausdrücklich darauf hin, dass deren besondere Anforderungen an Verfügbarkeit, Zuverlässigkeit und Sicherheit berücksichtigt werden müssen. Gleichzeitig erhöht eine stärkere Verbindung von OT- und IT-Systemen die Bedeutung geeigneter Netzwerkarchitekturen und Schutzmaßnahmen. (NIST)

Eine bessere Architektur kann deshalb so aussehen:

Produktionsnetz
      │
      ▼
Edge / Integrationsdienst
      │
      ▼
definierte Schnittstelle
      │
      ▼
OT-DMZ / Firewall
      │
      ▼
Unternehmens-IT

Damit endet das Legacy-Protokoll innerhalb einer kontrollierten Zone. Nach oben wird eine moderne, klar definierte Schnittstelle verwendet. Das schafft eine wesentlich sauberere Sicherheitsgrenze.

Alte Maschinen sollten nicht plötzlich Internet-Geräte werden

Eine SPS, die seit 15 Jahren isoliert in einem Produktionsnetz arbeitet, wurde möglicherweise nie dafür entwickelt, direkt aus dem Internet erreichbar zu sein, sich gegen moderne Angriffsmethoden zu schützen, aktuelle TLS-Versionen zu unterstützen oder moderne Benutzer- und Rollenmodelle bereitzustellen.

NIST nennt genau solche Einschränkungen älterer Komponenten als Herausforderung bei der digitalen Transformation von OT-Systemen. (NIST)

Der Edge-Layer besitzt deshalb noch eine zweite Funktion. Er ist nicht nur Protokollübersetzer. Er kann auch eine technologische und sicherheitstechnische Grenze zwischen Legacy-System und moderner Infrastruktur bilden.

Vom Protokolladapter zum gemeinsamen Maschinenmodell

Eine skalierbare Brownfield-Architektur könnte beispielsweise so aussehen:

                 ┌── Maschine A / S7
                 │
                 ├── Maschine B / Modbus
                 │
                 ├── Maschine C / TCP
                 │
                 └── Maschine D / RS232
                           │
                           ▼
                 Treiber / Adapter
                           │
                           ▼
                  gemeinsames Modell
                           │
                           ▼
                 Messaging / API Layer
                           │
            ┌──────────────┼──────────────┐
            ▼              ▼              ▼
           MES         Dashboard      Analytics

Damit kennen MES und Dashboard nur noch das gemeinsame Maschinenmodell. Sie müssen die ursprünglichen Maschinenprotokolle nicht verstehen. Das ist insbesondere dann wertvoll, wenn eine Maschine später ersetzt wird.

Was passiert beim Maschinentausch?

Angenommen, machine-17 ist eine ältere Maschine von Hersteller A. Heute:

Hersteller A
    │
    ▼
Driver A
    │
    ▼
machine-17

Nach zehn Jahren wird sie durch eine neue Maschine von Hersteller B ersetzt. Dann ändert sich idealerweise nur:

Hersteller B
    │
    ▼
Driver B
    │
    ▼
machine-17

Die darüberliegenden Systeme arbeiten weiterhin mit machine-17 und denselben fachlichen Informationen: state, productionCount, order, speed, alarms.

Das ist echte Entkopplung. Nicht alle Maschinen sprechen dieselbe Sprache. Sondern:

Für die darüberliegenden Anwendungen spielt ihre Sprache keine Rolle mehr.

Damit wird aus Retrofit eine langfristige Architektur

Brownfield-Integration wird häufig als einmaliges Projekt betrachtet: „Wir müssen diese eine alte Maschine irgendwie anbinden." Das führt schnell zu Sonderlösungen.

Die bessere Frage lautet:

Wie integrieren wir die nächste Maschine?

Und danach:

Wie integrieren wir Maschine Nummer 50?

Spätestens dann braucht es wiederverwendbare Prinzipien:

1. standardisierte Geräteidentität,
2. getrennte Treiber,
3. gemeinsames Datenmodell,
4. einheitliche Events,
5. definierte Commands,
6. Monitoring,
7. Logging,
8. Security,
9. Versionierung,
10. zentrale Konfiguration.

Damit entsteht aus einzelnen Retrofit-Projekten eine Integrationsplattform.

Messaging kann die nächste Stufe der Entkopplung schaffen

Sobald mehrere Systeme dieselben Maschinendaten verwenden, entsteht ein weiteres Problem. Soll jede Maschine direkt mit jedem Zielsystem kommunizieren?

Maschine
   ├──► MES
   ├──► Dashboard
   ├──► Historisierung
   ├──► QS
   └──► Analytics

Das skaliert schlecht. Eine Messaging-Infrastruktur kann diese Systeme voneinander entkoppeln.

Maschine
   │
   ▼
Edge / Driver
   │
   ▼
Message Broker
   │
   ├──► MES
   ├──► Dashboard
   ├──► Historisierung
   └──► Analytics

Damit muss der Treiber nicht wissen, welche Anwendungen seine Daten später verwenden. Er veröffentlicht lediglich ein Ereignis – beispielsweise MACHINE_STATE_CHANGED oder PRODUCTION_COMPLETED. Die interessierten Systeme verarbeiten diese Ereignisse anschließend unabhängig voneinander.

Gerade bei größeren Maschinenparks wird damit aus Brownfield-Integration zunehmend eine Frage moderner verteilter Softwarearchitektur.

Was sollte man zuerst integrieren?

Ein Brownfield-Projekt sollte nicht mit der Technologie beginnen.

Nicht: „Wir wollen MQTT." oder: „Wir brauchen OPC UA."

Sondern mit einer fachlichen Frage. Zum Beispiel:

Wir möchten Maschinenstillstände automatisch erfassen.

Die Reihenfolge lautet also:

Problem
  ↓
benötigte Information
  ↓
verfügbare Maschinendaten
  ↓
technische Anbindung
  ↓
Standardisierung
  ↓
zentrale Verwendung

Nicht umgekehrt.

Ein realistisches Brownfield-Projekt könnte so starten

Stufe 1 – Maschine verstehen

Dokumentieren:

• Hersteller
• Maschinentyp
• Steuerung
• Baujahr
• Netzwerk
• vorhandene Schnittstellen
• verfügbare Dokumentation

Stufe 2 – Datenbedarf definieren

Nicht alle Daten sammeln. Sondern beispielsweise:

Betriebszustand
Stückzahl
aktiver Auftrag
Fehler

Stufe 3 – Verbindung herstellen

Zum Beispiel über S7, Modbus, OPC, TCP, RS232 oder digitale IO.

Stufe 4 – Daten standardisieren

Aus:

DB20.DBX1.3 = TRUE

wird:

machine.state = RUNNING

Stufe 5 – Daten zentral verfügbar machen

Zum Beispiel über OPC UA, REST, MQTT oder AMQP.

Stufe 6 – Monitoring ergänzen

Zusätzlich sollte sichtbar werden:

• Ist die Maschine erreichbar?
• Wann kamen zuletzt Daten?
• Ist der Treiber verbunden?
• Welche Version läuft?
• Treten Kommunikationsfehler auf?

Stufe 7 – Weitere Maschinen integrieren

Jetzt zeigt sich, ob tatsächlich eine Plattform entstanden ist oder nur eine Einzellösung.

Genau hier setzen wir bei xpand an

Bei xpand betrachten wir Maschinenintegration nicht als Sammlung einzelner Punkt-zu-Punkt-Schnittstellen. Das Ziel ist, die Besonderheiten unterschiedlicher Maschinen möglichst früh zu kapseln und oberhalb dieser Schicht mit einheitlichen Daten und Schnittstellen weiterzuarbeiten.

Das Prinzip entspricht beispielsweise auch der Architektur hinter xpand.weight:

proprietäre Waage
       │
       ▼
 herstellerspezifischer Treiber
       │
       ▼
 gemeinsames Datenmodell
       │
       ▼
 zentrale Anwendung

Dasselbe Grundprinzip lässt sich auf viele andere industrielle Geräte übertragen. Aus einer herstellerspezifischen Schnittstelle wird eine klar definierte Systemgrenze. Darüber können moderne Softwarekomponenten arbeiten, ohne jedes Legacy-Protokoll selbst kennen zu müssen.

Brownfield bedeutet nicht, Legacy für immer mitzuschleppen

Das Ziel einer solchen Architektur ist nicht, alte Technologien möglichst lange zu konservieren. Im Gegenteil.

Es geht darum, sie kontrolliert einzukapseln.

Legacy
  │
  ▼
Adapter
  │
  ▼
moderne Systemgrenze

Wenn die Maschine später ersetzt wird, verschwindet der entsprechende Adapter. Die darüberliegende Architektur kann bestehen bleiben.

Genau dadurch lässt sich ein Maschinenpark schrittweise modernisieren. Nicht:

heute alles alt
      ↓
Großprojekt
      ↓
morgen alles neu

sondern:

Maschine 1 modernisieren
      │
Maschine 2 integrieren
      │
Maschine 3 ersetzen
      │
Maschine 4 nachrüsten
      │
      ▼
gemeinsame Architektur bleibt bestehen

Die OPC Foundation beschreibt gerade diese schrittweise Modernisierung bestehender Produktionssysteme als einen wichtigen Brownfield-Anwendungsfall für standardisierte Schnittstellen wie OPC UA. (OPC Connect)

Was eine gute Brownfield-Architektur leisten sollte

Wer bestehende Maschinen mit moderner Software verbinden möchte, sollte einige Grundprinzipien berücksichtigen.

1. Die Maschine nicht unnötig verändern

Wenn eine Produktionsanlage zuverlässig arbeitet, sollte die Digitalisierung möglichst wenig Einfluss auf ihre eigentliche Steuerungsfunktion haben.

2. Proprietäre Kommunikation kapseln

S7-Adressen, Modbus-Register oder Herstellertelegramme gehören in einen Adapter – nicht in MES, Dashboard und ERP.

3. Daten fachlich beschreiben

Ein Wert benötigt mindestens Kontext:

Was?
Von welchem Gerät?
Welche Einheit?
Wann?
Welcher Zustand?

4. Unterschiede zwischen Maschinen zulassen

Nicht jedes Gerät besitzt dieselben Fähigkeiten. Ein gemeinsames Modell muss auch reduzierte Legacy-Geräte sinnvoll darstellen können.

5. Moderne Standards an der Systemgrenze einsetzen

OPC UA, MQTT, AMQP oder REST können oberhalb des Legacy-Layers eine saubere Schnittstelle schaffen.

6. Security von Beginn an berücksichtigen

Ein Legacy-Protokoll sollte nicht nur deshalb durch mehrere Netzwerkzonen freigeschaltet werden, weil dies technisch am einfachsten erscheint. OT-Systeme benötigen Sicherheitskonzepte, die ihre besonderen Anforderungen an Zuverlässigkeit und Verfügbarkeit berücksichtigen. (NIST)

7. Mit einem konkreten Anwendungsfall beginnen

Nicht „alle Daten sammeln". Sondern beispielsweise: Stillstände automatisch erfassen.

8. Für die nächste Maschine planen

Eine erfolgreiche Brownfield-Architektur muss wiederholbar sein. Denn nach der ersten Maschine kommt fast immer die zweite.

Fazit: Eine alte Maschine braucht nicht zwingend eine neue Steuerung

Brownfield-Integration ist eine der wichtigsten Aufgaben industrieller Digitalisierung. Nicht weil alte Maschinen grundsätzlich problematisch wären. Sondern weil Produktionsanlagen wesentlich länger leben als IT-Technologien.

Während Softwarearchitekturen, Kommunikationsstandards und Sicherheitsanforderungen sich schnell verändern, können Maschinen Jahrzehnte produktiv im Einsatz bleiben.

Die Lösung kann deshalb nicht darin bestehen, auf einen Zeitpunkt zu warten, an dem plötzlich jede Maschine dieselbe moderne Schnittstelle besitzt. Stattdessen braucht es eine Architektur, die beide Welten verbindet:

bestehende Maschine
        +
Legacy-Protokoll
        │
        ▼
Adapter / Edge Layer
        │
        ▼
einheitliches Datenmodell
        │
        ▼
moderne Schnittstellen
        │
        ▼
MES / Dashboard / Analytics / IT

Das Ziel ist nicht, eine 20 Jahre alte Maschine in eine moderne Cloud-Anwendung zu verwandeln. Das Ziel ist, eine klare Grenze zu schaffen.

Auf der einen Seite darf die Maschine weiterhin mit der Technologie arbeiten, für die sie gebaut wurde. Auf der anderen Seite bekommt die moderne Software die standardisierten Informationen, die sie benötigt.

Genau dann wird aus einem heterogenen Maschinenpark eine integrierbare Systemlandschaft.

Und genau das ist der Kern einer guten Brownfield-Strategie:

Nicht alles neu bauen – sondern das Bestehende so kapseln, dass Neues darauf aufbauen kann.