Industrielle Waagen verwalten ohne Chaos

Eine Waage an eine Software anzubinden, klingt zunächst nach einer überschaubaren Aufgabe.

IP-Adresse konfigurieren, Verbindung herstellen, Gewicht auslesen – fertig.

In der Praxis sieht es häufig anders aus.

Spätestens wenn in einem Produktionsbetrieb mehrere Waagen unterschiedlicher Hersteller, Baujahre und Baureihen eingesetzt werden, entsteht eine Integrationslandschaft aus unterschiedlichen Schnittstellen, Telegrammformaten und Kommunikationsmechanismen.

Eine Waage liefert das Gewicht über eine serielle Schnittstelle. Die nächste spricht TCP/IP. Eine Kontrollwaage übermittelt komplette Produktionsdatensätze. Ein anderes Gerät liefert auf Anfrage gerade einmal Gewicht und Einheit. Für Tara, Nullstellung oder Statusabfragen gelten wieder andere Befehle.

Solange nur eine oder zwei Waagen integriert werden müssen, lässt sich das meist noch beherrschen.

Bei 20, 50 oder 150 Geräten wird daraus jedoch schnell ein Architekturproblem.

Das eigentliche Problem ist nicht das Gewicht

Ein Gewicht ist technisch betrachtet ein sehr einfacher Wert:

1,204 kg

Die Schwierigkeit liegt darin, diesen Wert zuverlässig aus der jeweiligen Waage zu bekommen und seine Bedeutung zu verstehen.

Je nach Gerät können zusätzlich Informationen vorhanden sein wie:

• Netto-, Brutto- und Taragewicht
• stabiler oder instabiler Gewichtswert
• Artikel oder PLU
• Chargen- und Losnummer
• Sollgewicht und Toleranzgrenzen
• Gut-/Schlecht-Bewertung
• laufende Nummer einer Packung
• Gerätezustand
• Fehlercodes
• Produktionsstatus

Das Problem: Wie diese Informationen übertragen, bezeichnet und codiert werden, unterscheidet sich von Hersteller zu Hersteller und teilweise sogar zwischen Geräteserien desselben Herstellers.

Dazu kommen unterschiedliche Möglichkeiten, die Waage zu steuern. Das Auslesen eines Gewichts ist nur ein Anwendungsfall. In realen Anlagen möchte man beispielsweise auch:

• eine Waage nullen,
• tarieren oder enttarieren,
• einen aktuellen Messwert anfordern,
• den Gerätezustand abfragen,
• eine Verbindung testen,
• Fehler diagnostizieren,
• später eventuell PLUs, Rezepte oder Produktionsparameter übertragen.

Damit wird aus einer vermeintlich einfachen Messwertanbindung eine bidirektionale Maschinenintegration.

Warum gibt es dafür keinen gemeinsamen Standard?

Ganz so einfach ist die Antwort inzwischen nicht mehr.

Mit OPC UA for Weighing Technology existiert heute tatsächlich ein herstellerunabhängiges Informationsmodell speziell für Wägetechnik. Die gemeinsame Initiative von VDMA und OPC Foundation beschreibt unterschiedliche Waagentypen – unter anderem einfache Waagen, Kontrollwaagen, Abfüllwaagen, Laborwaagen und Fahrzeugwaagen – und standardisiert Daten und Funktionen für deren Integration. Version 2.00 der Spezifikation wurde am 26. April 2025 veröffentlicht. (OPC Foundation)

OPC UA ist dabei streng genommen kein klassischer Feldbus, sondern eine herstellerunabhängige Kommunikations- und Informationsmodellierungsplattform. Zusammen mit der Weighing-Companion-Specification können Gewichte, Zustände, Produktionsparameter und Funktionen semantisch einheitlich dargestellt werden. (OPC UA Online Reference)

Damit wäre das Problem theoretisch gelöst.

Theoretisch.

Denn Produktionsanlagen bestehen selten ausschließlich aus Geräten der neuesten Generation.

Der Maschinenpark ist älter als der Standard

Eine typische Produktionslinie wird nicht vollständig ersetzt, nur weil eine neue Kommunikationsschnittstelle verfügbar ist.

Waagen bleiben häufig viele Jahre oder sogar Jahrzehnte im Einsatz. Entsprechend findet man in einer Fabrik gleichzeitig:

• moderne Waagen mit OPC UA,
• Geräte mit proprietärer TCP-Kommunikation,
• serielle RS232- oder RS485-Schnittstellen,
• herstellerspezifische Telegrammprotokolle,
• ältere Geräte mit eingeschränkten Daten,
• Kontrollwaagen mit komplexen Produktionsdatensätzen.

Genau hier entsteht das eigentliche Integrationsproblem.

Ein neuer Standard hilft bei neuen Maschinen. Er vereinheitlicht aber nicht automatisch den vorhandenen Maschinenpark.

Auch die OPC Foundation weist darauf hin, dass die Weighing Companion Specification bestimmte Anwendungsfälle abbildet und Geräte daneben weiterhin andere Schnittstellen besitzen können. Anwendungsfälle, die gesetzlichen Anforderungen wie der gesetzlichen Eichung unterliegen, werden in der Spezifikation zudem nicht vollständig behandelt. (OPC UA Online Reference)

Für Betreiber bleibt deshalb eine zentrale Frage:

Wie verwaltet man eine heterogene Waagenlandschaft so, als würde sie aus einheitlichen Geräten bestehen?

Die klassische Lösung skaliert schlecht

In vielen Unternehmen beginnt die Digitalisierung mit einer direkten Verbindung.

Die Produktionssoftware kommuniziert direkt mit Waage 1.

Später kommt Waage 2 hinzu.

Dann eine Kontrollwaage eines anderen Herstellers. Danach benötigt auch das MES Gewichte. Die Qualitätssicherung möchte Statistiken. Die Instandhaltung braucht den Gerätestatus. Und ein Dashboard soll die aktuelle Produktion visualisieren.

Schnell entstehen direkte Abhängigkeiten:

Jede Anwendung muss dabei wissen:

• Welcher Hersteller ist das?
• Welches Protokoll spricht das Gerät?
• Wie wird eine Verbindung aufgebaut?
• Wie wird ein Gewicht gelesen?
• Wie sieht die Antwort aus?
• Welche Einheit wird verwendet?
• Wie wird Tara gesetzt?
• Welche Fehlercodes gibt es?
• Wann gilt ein Messwert als gültig?

Das Ergebnis ist eine klassische N×M-Integrationslandschaft.

Mit jeder neuen Waage und jeder neuen Anwendung steigt die Komplexität weiter.

Besser: Herstellerprotokolle am Rand der Architektur beenden

Eine skalierbare Architektur dreht dieses Prinzip um.

Nicht jede Anwendung soll jeden Waagentyp verstehen.

Stattdessen bekommt jeder Gerätetyp einen Adapter beziehungsweise Treiber, der genau eine Aufgabe besitzt:

Das proprietäre Protokoll verstehen und nach außen eine einheitliche Sprache sprechen.

Ab diesem Punkt spielt es für die zentrale Anwendung keine Rolle mehr, ob der ursprüngliche Messwert aus einem proprietären TCP-Telegramm, einer seriellen Verbindung oder einer modernen Schnittstelle stammt.

Aus:

Herstellercode + Protokoll + Telegramm + Skalierung

wird beispielsweise:

Gerät: scale-001
Gewicht: 1.204
Einheit: kg
Stabil: true
Zeitpunkt: 10:15:30.130

Ist ein Gerät in der Lage, mehr Informationen bereitzustellen, können zusätzlich Artikel, Charge, Sollgewicht oder Bewertung übernommen werden.

Kann eine ältere Waage nur Gewicht und Einheit liefern, bleibt sie trotzdem integrierbar.

Ein gemeinsames Datenmodell darf nicht voraussetzen, dass jedes Gerät dieselben Fähigkeiten besitzt.

Eine zentrale Schicht statt immer neuer Punkt-zu-Punkt-Verbindungen

Damit entsteht eine andere Architektur:

Die zentrale Waagenebene übernimmt dabei nicht die Aufgabe der Waage. Sie ersetzt weder die eichrelevante Funktion noch die lokale Maschinensteuerung.

Ihre Aufgabe ist Integration.

Sie schafft eine gemeinsame Sicht auf Geräte, Messwerte, Zustände und Funktionen.

Damit wird aus vielen einzelnen Waagen erstmals eine verwaltbare Waagenlandschaft.

Doch dann kommt das nächste Problem: Datenmenge

Bei wenigen Tischwaagen spielt Datenvolumen kaum eine Rolle.

Bei Produktions- und Kontrollwaagen sieht das anders aus.

Nehmen wir ein einfaches Beispiel:

150 Geräte liefern jeweils zwei Messwerte pro Sekunde.

Das ergibt:

300 Nachrichten pro Sekunde

oder:

25.920.000 Nachrichten pro Tag.

Und dabei wurden Gerätestatus, Fehler, Befehle und andere Ereignisse noch gar nicht berücksichtigt.

Die zentrale Anwendung direkt mit allen Geräten kommunizieren und anschließend jeden Datensatz synchron weiterverarbeiten zu lassen, wird damit zunehmend unattraktiv.

Eine industrielle Architektur braucht eine Entkopplung zwischen Datenerfassung und Datenverarbeitung.

RabbitMQ als Datenautobahn zwischen Edge und Anwendung

Hier kommen Message Broker wie RabbitMQ ins Spiel.

Statt einen Messwert direkt an einen bestimmten Empfänger zu schicken, veröffentlicht der Waagentreiber das Ereignis auf einer zentralen Messaging-Infrastruktur.

RabbitMQ funktioniert damit vereinfacht wie eine Datenautobahn. Produzenten erzeugen Nachrichten. Konsumenten verarbeiten sie. Beide Seiten müssen nicht mit derselben Geschwindigkeit arbeiten.

Entsteht kurzfristig mehr Last, können Nachrichten in Queues gepuffert und anschließend verarbeitet werden. Gleichzeitig lassen sich mehrere Consumer einsetzen, um Verarbeitung horizontal zu skalieren.

Damit wird die Waagenkommunikation von der eigentlichen Datenverarbeitung entkoppelt. Das ist insbesondere dann wichtig, wenn Hunderte Geräte unabhängig voneinander Daten liefern.

Eine Queue ist aber noch keine Hochverfügbarkeit

Ein Message Broker löst nicht automatisch jedes Verfügbarkeitsproblem. Für industrielle Anwendungen muss auch die Messaging-Infrastruktur entsprechend ausgelegt werden.

RabbitMQ stellt dafür beispielsweise Quorum Queues zur Verfügung. Sie replizieren Queue-Inhalte über mehrere Cluster-Knoten und verwenden einen Konsensmechanismus auf Basis von Raft. Fällt der führende Knoten einer Queue aus, kann ein anderer Replikatknoten die Führung übernehmen. (RabbitMQ Reliability Guide)

Ein typisches Szenario besteht aus drei RabbitMQ-Knoten. Bei einer Quorum Queue mit drei Replikaten kann ein einzelner Knoten ausfallen, während weiterhin eine Mehrheit verfügbar bleibt. RabbitMQ empfiehlt für replizierte Quorum Queues eine ungerade Anzahl von Mitgliedern; die Standardgröße liegt bei drei. (RabbitMQ Quorum Queues)

Für zuverlässige Übertragung gehören allerdings weitere Mechanismen dazu. Publisher Confirms ermöglichen dem Sender festzustellen, ob RabbitMQ eine Nachricht tatsächlich übernommen hat. Auf Consumer-Seite wird über Acknowledgements bestätigt, dass eine Nachricht erfolgreich verarbeitet wurde. (RabbitMQ Confirms)

Ausfallsicherheit entsteht nicht durch ein einzelnes Produkt, sondern durch das Zusammenspiel von Puffern, Bestätigungen, Replikation, Wiederholungsmechanismen und idempotenter Verarbeitung.

Und was passiert mit Befehlen an die Waage?

Waagenintegration ist nicht nur eine Einbahnstraße.

Neben Messwerten werden häufig auch Befehle benötigt:

READ_WEIGHT
TARE
CLEAR_TARE
ZERO
TEST_CONNECTION
RECONNECT

Später können – abhängig vom Gerät – Funktionen wie PLU-, Rezept- oder Parameterwechsel hinzukommen.

Auch hier zahlt sich die Abstraktionsschicht aus.

Eine übergeordnete Anwendung muss nicht wissen, dass Hersteller A zum Tarieren einen bestimmten ASCII-Befehl erwartet und Hersteller B dafür eine völlig andere Telegrammstruktur verwendet.

Die Anwendung fordert lediglich an:

TARE scale-001

Der zuständige Treiber übersetzt diesen neutralen Befehl in die Sprache der jeweiligen Waage.

Damit wird nicht nur das Lesen, sondern auch das Bedienen und Diagnostizieren der Geräte herstellerunabhängig.

Genau an dieser Stelle setzt xpand.weight an

Aus dieser Problemstellung ist xpand.weight entstanden.

Das Ziel ist nicht, ein weiteres proprietäres Waagenprotokoll zu schaffen. Im Gegenteil.

xpand.weight bildet eine Zwischenschicht zwischen den vorhandenen Waagen und der darüberliegenden IT- und OT-Landschaft.

                    xpand.weight
                         |
        +----------------+----------------+
        |                |                |
        v                v                v
   Bizerba          Hersteller B     Generic TCP/
    Driver             Driver           Serial
        |                |                |
        v                v                v
      Waage            Waage            Waage

Jeder Treiber versteht sein konkretes Gerät. Nach oben werden Geräteinformationen, Messwerte und Zustände dagegen vereinheitlicht.

Dadurch kann eine zentrale Oberfläche beispielsweise anzeigen:

• Welche Waagen sind vorhanden?
• Welche Geräte sind online?
• Wann kam der letzte Messwert?
• Welches Gewicht liegt aktuell an?
• Ist der Gewichtswert stabil?
• Welcher Treiber ist verbunden?
• Gibt es Kommunikationsfehler?
• Welche Befehle unterstützt das Gerät?
• Wie lautet die Antwort auf einen ausgeführten Befehl?

Die Bedienoberfläche muss das Herstellerprotokoll nicht kennen.

OPC UA oder xpand.weight? Eigentlich ist das die falsche Frage

Eine solche Abstraktionsschicht steht nicht im Wettbewerb zu OPC UA. Im Gegenteil.

Wo eine Waage OPC UA und insbesondere das standardisierte Weighing-Informationsmodell unterstützt, ist das eine hervorragende Grundlage für eine saubere Integration. Die OPC-UA-Spezifikation ermöglicht sowohl den Zugriff auf Messdaten als auch – abhängig vom Waagentyp – auf Zustände, Produktionsparameter und Methoden. (OPC UA Online Reference)

Das Problem sind die Geräte, die diese Schnittstelle nicht besitzen.

Eine praxisgerechte Architektur muss deshalb beides unterstützen:

moderne standardisierte Schnittstellen
              +
vorhandene proprietäre Schnittstellen
              |
              v
     gemeinsames Datenmodell

Der Standard wird damit nicht ersetzt.

Er wird dort genutzt, wo er vorhanden ist. Und dort, wo er fehlt, sorgt ein Treiber für die notwendige Übersetzung.

Das eigentliche Ziel: Austauschbarkeit

Der größte Vorteil einer solchen Architektur zeigt sich oft erst Jahre später.

Angenommen, eine bestehende Waage wird ersetzt.

In einer klassischen Punkt-zu-Punkt-Integration müssen möglicherweise MES, Produktionssoftware, Dashboard und weitere Anwendungen angepasst werden.

Mit einer Abstraktionsschicht ändert sich nur die unterste Ebene:

vorher:

Hersteller A --> Driver A --+
                            +--> einheitliche Schnittstelle
                            |
nachher:                    |
Hersteller B --> Driver B --+

Für die darüberliegenden Systeme bleibt scale-001 weiterhin scale-001.

Genau das ist echte Herstellerunabhängigkeit.

Nicht die Behauptung, dass alle Hersteller dieselbe Sprache sprechen. Sondern eine Architektur, in der es für den Rest der Anwendung keine Rolle mehr spielt, welche Sprache das konkrete Gerät spricht.

Was gutes Waagen-Management deshalb leisten sollte

Wer industrielle Waagen zentral verwalten möchte, sollte weniger auf einzelne Protokolle und stärker auf die Gesamtarchitektur achten. Ein nachhaltiges Konzept sollte mindestens folgende Prinzipien berücksichtigen:

1. Herstellerprotokolle kapseln
   Proprietäre Kommunikation gehört in getrennte Treiber und nicht in die Geschäftslogik.
2. Ein gemeinsames Datenmodell verwenden
   Gewicht, Einheit, Stabilität, Status und Geräteidentität sollten herstellerneutral dargestellt werden.
3. Gerätefähigkeiten berücksichtigen
   Nicht jede Waage kann dieselben Informationen liefern oder dieselben Befehle ausführen.
4. Kommunikation und Verarbeitung entkoppeln
   Eine Messaging-Ebene verhindert, dass jede Anwendung direkt mit jeder Waage kommunizieren muss.
5. Ausfallsicherheit von Anfang an einplanen
   Queues, Replikation, Acknowledgements und Wiederholungsmechanismen sind bei produktionsrelevanten Daten wichtiger als späteres Nachrüsten.
6. Brownfield mitdenken
   Eine Architektur, die nur mit neuesten OPC-UA-Geräten funktioniert, löst das Problem vieler bestehender Produktionsanlagen nicht.
7. Standards nutzen, wo sie verfügbar sind
   OPC UA for Weighing Technology ist ein wichtiger Schritt zur Herstellerunabhängigkeit und sollte bei neuen Geräten berücksichtigt werden.

Fazit: Der Standard allein löst den Maschinenpark nicht

Die Wägetechnik bewegt sich in die richtige Richtung.

Mit OPC UA for Weighing Technology existiert inzwischen ein herstellerübergreifendes Informationsmodell, das viele der bisherigen Integrationsprobleme adressiert.

Die industrielle Realität besteht aber noch lange aus einem Mix verschiedener Generationen, Hersteller und Schnittstellen.

Deshalb lautet die entscheidende Frage nicht:

„Welches Protokoll verwendet unsere Waage?"

Sondern:

„Wie bauen wir unsere Architektur so auf, dass das Protokoll der einzelnen Waage für den Rest unseres Systems keine Rolle mehr spielt?"

Genau dort beginnt modernes Waagen-Management.

Eine herstellerneutrale Treiberschicht, ein gemeinsamer Datenvertrag und eine skalierbare Messaging-Infrastruktur machen aus vielen unterschiedlichen Einzelgeräten eine gemeinsam verwaltbare Systemlandschaft.

xpand.weight ist unser Ansatz, genau diese Lücke zwischen bestehender Wägetechnik und moderner IT-/OT-Architektur zu schließen.