Einen vollständig konformen OPC UA Server bauen — von der Companion Spec bis zum Brownfield

Es gibt zahlreiche OPC UA Server auf dem Markt. Die meisten davon stellen eine flache Liste von Tags bereit. Man erhält einen Wert, einen Zeitstempel und einen Qualitätscode. Das ist nützlich — sicherlich besser als nichts — aber es verfehlt den eigentlichen Sinn von OPC UA.

Ein konformer OPC UA Server liefert nicht nur Daten. Er stellt ein Informationsmodell bereit: typisierte Objekte, strukturierte Variablen, Ingenieurseinheiten, Alarmbedingungen, Methoden mit definierten Argumenten und Beziehungen zwischen Anlagen. Er implementiert branchenübliche Companion Specifications, sodass jeder Client — von jedem Hersteller — die Daten ohne individuelle Konfiguration verstehen kann.

Einen solchen Server zu bauen ist schwierig. Ihn mit einer realen Fabrik zu verbinden — mit Steuerungen, die Modbus, S7, EtherNet/IP oder proprietäre Protokolle sprechen — ist noch schwieriger.

Dieser Artikel erklärt, wie beides gelingt, und wie moderne Werkzeuge den Prozess konfigurierbar statt programmierbar machen.

Die drei Schichten eines echten OPC UA Servers

Jeder produktive OPC UA Server besteht aus drei Schichten. Die meisten Projekte meistern die erste und scheitern an den beiden anderen.

Schicht 1: das Informationsmodell

Dies ist die semantische Beschreibung Ihrer Anlagen. Keine Tag-Liste — ein Modell. Es definiert:

• Objekttypen. Welche Arten von Anlagen existieren (Pumpen, Förderbänder, Reaktoren, Roboter).
• Variablentypen. Welche Daten jede Anlage bereitstellt (Temperatur, Drehzahl, Zustand, Zyklusanzahl), mit Datentypen und Ingenieurseinheiten.
• Methodentypen. Welche Operationen ausgeführt werden können (Starten, Stoppen, Rücksetzen, Alarm quittieren).
• Ereignistypen. Welche Benachrichtigungen die Anlage sendet (Alarm ausgelöst, Zustandsänderung, Charge abgeschlossen).
• Referenzen. Wie Anlagen zueinander in Beziehung stehen (Pump_3 ist Teil von CoolingLoop_1, die Teil von ProductionLine_A ist).

Eine Companion Specification liefert die Vorlage. PackML beschreibt, wie die Zustandsmaschine einer Verpackungsmaschine modelliert wird. Euromap 77 beschreibt, wie eine Spritzgießmaschine modelliert wird. PADIM beschreibt, wie ein Drucktransmitter modelliert wird.

Ihre Aufgabe ist es, die Companion Spec für Ihre spezifische Ausrüstung zu instanziieren — Ihre konkreten Pumpen, Ihre konkreten Förderbänder, Ihr konkretes Anlagenlayout.

Schicht 2: die Treiberschicht (Brownfield-Konnektivität)

Das Informationsmodell beschreibt, was die Daten bedeuten. Die Treiberschicht beschreibt, woher die Daten kommen.

Bei einer Greenfield-Installation verfügen Sie möglicherweise über moderne Steuerungen, die bereits OPC UA sprechen. In der Realität sind die meisten Fabriken jedoch Brownfield-Umgebungen mit einer Mischung aus:

• Siemens S7 (S7-300, S7-400, S7-1200, S7-1500) — über das S7-Protokoll oder PROFINET.
• Modbus TCP/RTU — die Lingua franca der Prozessinstrumente.
• EtherNet/IP (Allen-Bradley, Rockwell) — mit CIP über Ethernet.
• BACnet — in der Gebäudeautomation.
• MQTT — von IoT-Sensoren und Edge-Geräten.
• CSV/REST/Datenbanken — von Historiensystemen, SCADA und Altsystemen.
• Proprietäre Protokolle — jeder Hersteller hat eines.

Die Treiberschicht verbindet sich mit diesen heterogenen Quellen und bildet deren Rohdatenpunkte auf das semantische Modell ab. Register 40001 eines Modbus-Geräts wird zu CoolingPump.DischargeTemperature mit dem Typ Double, der Einheit °C und einem Ingenieursbereich von 20.0 – 65.0.

Schicht 3: die OPC UA Diensteschicht

Dies ist der OPC UA Stack selbst — die Dienste, die Clients zur Interaktion mit dem Server nutzen:

• Browse. Clients entdecken das Informationsmodell zur Laufzeit.
• Read/Write. Clients lesen Prozesswerte und schreiben Sollwerte.
• Subscribe. Clients empfangen Echtzeit-Updates über überwachte Elemente.
• Call. Clients rufen Methoden auf dem Server auf.
• Events. Clients empfangen strukturierte Alarm- und Ereignisbenachrichtigungen.
• HistoryRead. Clients fragen historische Daten ab.
• Sicherheit. X.509-Zertifikate, Verschlüsselung, rollenbasierte Zugriffskontrolle.

Ein konformer Server implementiert all diese Dienste korrekt — nicht nur Read und Subscribe.

Warum die meisten OPC UA Server scheitern

Flache Tag-Listen

Das häufigste Versagen: Der Server stellt einen flachen Namensraum von Tags bereit — Tag_001, Tag_002, Temperature_Pump3 — ohne Typinformationen, ohne Objekthierarchie, ohne Einheiten, ohne Beziehungen. Das ist im Grunde ein OPC DA Server in einer OPC UA Hülle. Clients können Werte lesen, aber sie können die Daten nicht verstehen.

Hartcodierte Modelle

Viele OPC UA Server codieren das Informationsmodell fest in C++ oder C#. Das Hinzufügen einer neuen Variable erfordert eine Neukompilierung und erneute Bereitstellung des Servers. Eine Änderung der Modellstruktur bedeutet Monate an Entwicklung. Das tötet die Agilität — Fabriken müssen ihre Modelle anpassen, wenn sich Ausrüstung ändert, neue Linien hinzukommen und Companion Specs weiterentwickelt werden.

Keine Brownfield-Konnektivität

Einige Server verfügen über hervorragende OPC UA Stacks, bieten aber keine Möglichkeit, sich mit bestehenden Anlagen zu verbinden. Sie funktionieren bestens mit anderen OPC UA Servern, können aber kein Modbus-Register und keinen S7-Datenbaustein lesen. In einer Brownfield-Fabrik macht sie das als Edge-Aggregationspunkt unbrauchbar.

Sicherheit als nachträglicher Gedanke

Der Server unterstützt OPC UA Sicherheit in der Theorie, aber in der Praxis wird sie nie aktiviert, weil das Zertifikatsmanagement zu komplex ist. Lesen Sie unseren Artikel über GDS, um zu erfahren, warum das wichtig ist und wie man es löst.

Der konfigurierbare Ansatz

Der traditionelle Weg, einen OPC UA Server zu bauen, ist Code zu schreiben: Typen in C++ definieren, Objekte instanziieren, Daten-Callbacks implementieren, Subscriptions verwalten. Das ist mächtig, aber teuer. Jede Änderung erfordert einen Entwickler.

Der moderne Ansatz trennt die drei Schichten in Konfiguration:

1. Modelldefinition (YAML / NodeSet)

Das Informationsmodell wird in einer strukturierten Datei definiert — YAML, XML NodeSet oder ein visueller Designer — nicht im Anwendungscode. Das Modell referenziert Companion Specifications durch Import ihrer NodeSet-Dateien. Ihre benutzerdefinierten Typen erweitern die Typen der Companion Spec.

Das bedeutet:

• Ein Domänenexperte (kein Programmierer) kann das Modell definieren.
• Das Modell wird in Git versioniert.
• Änderungen werden überprüft, verglichen und wie Code zurückgesetzt.
• Dasselbe Modell kann auf mehreren Servern bereitgestellt werden.

2. Treiber-Mapping (Konfiguration)

Das Mapping zwischen dem Informationsmodell und den Brownfield-Datenquellen wird in einer Konfigurationsdatei definiert. Für jede Variable im Modell geben Sie an:

• Quellprotokoll (Modbus, S7, MQTT, OPC UA, CSV, …)
• Verbindungsdetails (IP-Adresse, Port, Rack/Slot für S7, Unit-ID für Modbus)
• Adresse (Registernummer für Modbus, DB/Offset für S7, Topic für MQTT)
• Datentyp und Transformation (Skalierung, Byte-Tausch, Bit-Extraktion)
• Abfrageintervall oder Ereignis-Trigger

Kein Code. Eine Konfigurationsänderung. Wenn die Fabrik eine neue SPS hinzufügt oder einen Transmitter austauscht, aktualisieren Sie das Mapping — nicht die Software.

3. Server-Deployment (containerisiert)

Der Server läuft als Container (Docker, Kubernetes oder nativer Dienst), wobei Modell und Treiberkonfiguration als Dateien eingebunden werden. Ein Modell-Update ist ein Konfigurations-Reload oder Container-Neustart — keine Neukompilierung.

Ein praktisches Beispiel

Betrachten Sie eine pharmazeutische Produktionslinie mit:

• 3 Reaktorbehältern (Siemens S7-1500 SPS, S7-Protokoll)
• 12 Prozessinstrumenten (Endress+Hauser, Modbus TCP)
• 1 Verpackungsmaschine (Beckhoff, EtherNet/IP)
• 1 Clean-in-Place-Anlage (CIP) (älteres Modbus RTU über serielle Gateway)

Schritt 1: Modell definieren.

Importieren Sie die PADIM Companion Specification für Prozessinstrumente, das ISA-88 BatchML-Modell für Reaktorsequenzen und PackML für die Verpackungsmaschine. Definieren Sie Ihren spezifischen Reaktortyp, indem Sie den BatchML-Reaktor um Ihre benutzerdefinierten Variablen erweitern (Rührerdrehzahl, Manteltemperatur, pH-Wert). Instanziieren Sie drei Reaktoren, zwölf Instrumente, eine Verpackungsmaschine und eine CIP-Anlage.

Schritt 2: Treiber konfigurieren.

Bilden Sie den Temperatur-Sollwert von Reactor_1 auf die S7-1500 unter IP 10.0.1.10, DB100, Offset 0, Typ REAL ab. Bilden Sie den Messwert von FlowMeter_7 auf Modbus TCP unter IP 10.0.2.7, Register 30001, Typ Float32, Byte-Reihenfolge BigEndian ab. Bilden Sie den Zustand von Packager_1 auf EtherNet/IP unter IP 10.0.3.1, CIP-Pfad 1/0/Assembly/100 ab. Bilden Sie die Schrittnummer von CIP_Skid auf Modbus RTU über die serielle Gateway unter IP 10.0.4.1, Unit-ID 1, Register 40010 ab.

Schritt 3: Bereitstellen.

Starten Sie den OPC UA Server. Clients, die sich verbinden, sehen einen vollständig navigierbaren Adressraum mit typisierten Objekten, Ingenieurseinheiten, Alarmbedingungen und Methoden — alles gespeist von Live-Daten aus vier verschiedenen Protokollen. Der Client weiß nicht und interessiert sich nicht dafür, ob die Daten von Modbus, S7 oder EtherNet/IP stammen. Er sieht OPC UA.

Was Konformität wirklich bedeutet

Ein „konformer" OPC UA Server ist nicht einfach einer, der einen Zertifizierungstest besteht. In der Praxis bedeutet Konformität:

Wichtigste Erkenntnisse

1. Eine flache Tag-Liste ist kein OPC UA Server. Ein echter OPC UA Server stellt ein Informationsmodell bereit — typisierte Objekte mit Struktur, Einheiten und Beziehungen.

2. Companion Specifications liefern die Vorlagen. Ihre Aufgabe ist es, diese für Ihre spezifische Ausrüstung zu instanziieren.

3. Brownfield-Konnektivität ist der schwierige Teil. Ihr Server muss semantische Variablen auf Modbus-Register, S7-Datenbausteine, EtherNet/IP-Tags und MQTT-Topics abbilden.

4. Der moderne Ansatz ist Konfiguration statt Code. Modell in YAML, Treiber-Mapping in der Konfiguration, Deployment als Container.

5. Konformität geht über Tags hinaus. Sie umfasst Sicherheit, Alarme, Historie, Navigation, Methoden und Diagnose.

Referenzen

1. OPC Foundation — OPC UA Part 5: Information Model. opcfoundation.org
2. OPC Foundation — OPC UA Companion Specifications. opcfoundation.org/developer-tools/documents
3. ISA — ISA-88 / PackML. isa.org
4. FieldComm Group — PA-DIM. fieldcommgroup.org
5. Euromap — Euromap 77/83. euromap.org

Das ist es, was wir bei Sterfive bauen. Omni-Edge ist ein vollständig konfigurierbarer OPC UA Server, der Companion Specifications implementiert, sich über integrierte Treiber (S7, Modbus, MQTT, EtherNet/IP und mehr) mit Brownfield-Anlagen verbindet und als leichtgewichtiger Container bereitgestellt wird. OPC UA Modeler ermöglicht es Ihnen, das Informationsmodell visuell zu definieren und als NodeSet-Datei zu exportieren, die Omni-Edge direkt konsumiert. Kein Code erforderlich. Sprechen wir über Ihr Deployment.