Wenn MQTT der leichtgewichtige Bote der vernetzten Welt ist, dann ist OPC UA ihr industrieller Diplomat — der Standard, der Maschinen, Steuerungen und Software völlig verschiedener Hersteller einander verstehen lässt, mit eingebauter Sicherheit und Bedeutung. Es ist das Rückgrat von Industrie 4.0. Dieser Leitfaden setzt voraus, dass Sie nichts darüber wissen. Am Ende verstehen Sie, wie OPC UA von der Grundidee bis ins Detail funktioniert, und Sie haben einen echten OPC-UA-Server und einen Client gebaut und betrieben, der Live-Daten durchsucht, liest, schreibt und abonniert. Kurz: Sie können selbst ein echtes OPC-UA-Projekt bauen.
Was OPC UA wirklich ist
OPC UA (Open Platform Communications — Unified Architecture) ist ein offener Standard zum Austausch industrieller Daten zwischen Geräten und Systemen. Aber es ist mehr als ein Weg, Bytes zu bewegen: Es bewegt Bedeutung. Wo ein einfaches Protokoll die Zahl 22.5 senden würde, sendet OPC UA "eine Variable namens Temperature, vom Typ Double, in Grad Celsius, zugehörig zu Machine1, zuletzt aktualisiert zu dieser Zeit, die Sie lesen dürfen". Es vereint Kommunikation, ein reiches Datenmodell und starke Sicherheit in einem Rahmen — genau deshalb ist es zur Sprache moderner Fabriken geworden.
Die große Idee: modellierte Daten, nicht nur Nachrichten
MQTTs große Idee war Publish/Subscribe. OPC UAs große Idee ist das Informationsmodell. Jeder Server stellt seine Daten als strukturierten, durchsuchbaren Baum verbundener Nodes dar — fast wie ein Dateisystem für eine Maschine. Ein Client muss nicht vorab wissen, was existiert; er kann den Server durchsuchen (browsen) und die Maschinen, ihre Sensoren, ihre Einstellungen und sogar die ausführbaren Aktionen entdecken. Diese selbstbeschreibende Struktur lässt einen brandneuen Client eine Maschine verstehen, die er nie zuvor gesehen hat.
Die Kernrollen: Server und Client
- Ein OPC-UA-Server lebt auf oder nahe einem Gerät — einer SPS, einer Maschine oder einem Gateway — und stellt dessen Daten und Fähigkeiten als Modell bereit, auf das andere Systeme zugreifen.
- Ein OPC-UA-Client verbindet sich mit einem Server, um Werte zu lesen, Einstellungen zu schreiben, Methoden aufzurufen oder Änderungen zu abonnieren. Ein SCADA-System, ein MES, ein Cloud-Connector oder ein einfaches Skript sind alle Clients.
Anders als bei MQTT gibt es im klassischen Modell keinen zentralen Broker: Clients verbinden sich direkt mit Servern. (OPC UA bietet auch einen neueren Publish/Subscribe-Modus, später behandelt, der broker-ähnliches Messaging ergänzt.)
Der Adressraum: Nodes, Objects, Variables, Methods
Alles, was ein Server anbietet, liegt in seinem Adressraum — dem durchsuchbaren Baum. Der Baum besteht aus Nodes, und die wichtigen Arten sind:
- Objects — Container, die ein Ding darstellen, etwa
Machine1. - Variables — die eigentlichen Datenwerte, etwa
TemperatureoderMotorCurrent. - Methods — Aktionen, die ein Client aufrufen kann, etwa
StartoderReset.
So erscheint eine einzelne Maschine als Object mit mehreren Variables und einigen Methods — ein vollständiges, selbstbeschreibendes Bild dessen, was sie ist und was sie kann.
NodeId und Namespaces: wie alles adressiert wird
Jeder Node hat einen eindeutigen Bezeichner, die NodeId. Eine NodeId hat zwei Teile: einen Namespace-Index (zu welchem Hersteller oder Modell er gehört) und einen Bezeichner innerhalb dieses Namespace. Sie werden ständig Referenzen wie 2:Temperature sehen, wobei 2 der Namespace-Index und Temperature der Name ist. Namespace 0 ist für die Standard-OPC-UA-Definitionen reserviert; Ihre eigenen Daten liegen in einem Namespace, den Sie registrieren (oft Index 2). Namespaces zu verstehen ist der Schlüssel, jede OPC-UA-Adresse richtig zu lesen.
Das Informationsmodell: Daten mit Bedeutung
Weil OPC UA Datentypen, Einheiten und Beziehungen beschreibt, haben ganze Branchen Standardmodelle veröffentlicht — sogenannte Companion Specifications — damit zum Beispiel jeder Roboter oder jede Spritzgussmaschine ihre Daten gleich darstellt. Das bedeutet, ein für eine Maschine geschriebener Client versteht oft eine andere von einem anderen Hersteller mit wenig oder keiner Änderung. Diese geteilte, bedeutungsvolle Struktur hebt OPC UA wirklich von einem reinen Transportprotokoll ab.
Services: was ein Client tatsächlich tun kann
Ein Client interagiert mit einem Server über einen festen Satz von Services. Die wesentlichen sind leicht zu erfassen:
- Browse — den Adressraum erkunden, um zu entdecken, was existiert.
- Read — den aktuellen Wert einer Variable holen.
- Write — einen Wert oder eine Einstellung ändern.
- Call — eine Methode (Aktion) auf dem Server ausführen.
- Subscribe — sich automatisch benachrichtigen lassen, wenn sich Werte ändern.
Fast jede OPC-UA-Anwendung besteht aus diesen wenigen Bausteinen.
Subscriptions und Monitored Items: Änderungen bekommen, statt sie zu holen
Einen Wert ständig zu lesen, um zu sehen, ob er sich geändert hat, ist verschwenderisch. Stattdessen erstellt ein Client eine Subscription und fügt Monitored Items hinzu — die konkreten Variablen, die ihn interessieren. Der Server sendet dann nur eine Benachrichtigung, wenn sich ein Wert tatsächlich ändert (oder in einem gewählten Intervall). Das ist effizient und echtzeitfähig, und so empfangen Dashboards und Historians Live-Daten, ohne den Server zu überlasten.
Sicherheit: eingebaut, nicht angeflanscht
Hier glänzt OPC UA gegenüber älteren Industrieprotokollen. Sicherheit ist Teil des Standards selbst, kein Zusatz:
- Verschlüsselung und Signierung schützen jede Nachricht vor Abhören und Manipulation.
- Zertifikate lassen Client und Server ihre Identität beweisen, bevor Daten fließen.
- Benutzer-Authentifizierung (Benutzername/Passwort oder Zertifikate) steuert, wer sich verbinden darf.
- Security Policies legen genau fest, welche Verschlüsselungsstärke genutzt wird.
Eine korrekt konfigurierte OPC-UA-Verbindung ist von Grund auf sicher — einer der größten Gründe, warum ihr in kritischen industriellen Umgebungen vertraut wird.
Sessions, Secure Channels und Transport
Beim Verbinden baut ein Client zuerst einen Secure Channel auf (die verschlüsselte, authentifizierte Leitung) und öffnet darauf eine Session (das logische Gespräch). Der Großteil der Kommunikation nutzt den effizienten Binärtransport, adressiert als opc.tcp://host:4840. OPC UA definiert außerdem einen neueren PubSub-Modus, der Daten über MQTT oder UDP für eine Eins-zu-viele-Verteilung senden kann — er verbindet OPC UAs reiche Modellierung mit MQTT-artigem Messaging. Zu wissen, welcher Transport wann passt, gehört zum Entwurf eines guten Systems.
Einen SDK/Stack wählen
Man implementiert OPC UA selten von Hand; man nutzt einen bewährten Stack. Zum Lernen und für Python-Projekte ist asyncua (eine reine Python-Bibliothek) ausgezeichnet und das, was wir unten verwenden. Für hochperformante oder eingebettete Server ist open62541 (C) die führende Open-Source-Wahl und läuft sogar auf Mikrocontrollern. Java hat Eclipse Milo, Node.js hat node-opcua, und kommerzielle Stacks von Herstellern ergänzen Werkzeuge und Support. Wie bei MQTT bleiben die Konzepte über alle hinweg gleich.
Praxis, Teil 1: einen OPC-UA-Server betreiben
Bauen wir etwas Echtes. Installieren Sie die Python-Bibliothek mit pip install asyncua. Folgendes ist ein vollständiger, funktionierender OPC-UA-Server, der eine Maschine mit einer Live-Temperaturvariable bereitstellt:
import asyncio
from asyncua import Server
async def main():
server = Server()
await server.init()
server.set_endpoint("opc.tcp://0.0.0.0:4840/freeopcua/server/")
# eigenen Namespace registrieren (liefert einen Index, meist 2)
uri = "http://example.org/factory"
idx = await server.register_namespace(uri)
# ein Object fuer die Maschine und eine Variable darin anlegen
machine = await server.nodes.objects.add_object(idx, "Machine1")
temperature = await machine.add_variable(idx, "Temperature", 20.0)
await temperature.set_writable() # Clients duerfen sie auch schreiben
async with server:
print("Server laeuft auf opc.tcp://localhost:4840/freeopcua/server/")
value = 20.0
while True:
await asyncio.sleep(1)
value += 0.5
await temperature.write_value(value)
asyncio.run(main())
Starten Sie ihn, und Sie haben einen echten OPC-UA-Server, der eine sich ändernde Temperatur bereitstellt. Sie können ihn sogar mit einem kostenlosen Client-Werkzeug wie UaExpert visuell durchsuchen.
Praxis, Teil 2: verbinden, browsen, lesen und schreiben mit einem Client
Nun ein Client, der sich mit diesem Server verbindet, die Variable findet, sie liest und einen neuen Wert schreibt:
import asyncio
from asyncua import Client
async def main():
url = "opc.tcp://localhost:4840/freeopcua/server/"
async with Client(url=url) as client:
# vom Objects-Ordner zu unserer Variable browsen
machine = await client.nodes.objects.get_child(["2:Machine1"])
temperature = await machine.get_child(["2:Temperature"])
# aktuellen Wert LESEN
value = await temperature.read_value()
print("Temperatur ist:", value)
# neuen Wert SCHREIBEN
await temperature.write_value(25.0)
print("25.0 geschrieben")
asyncio.run(main())
Beachten Sie das Präfix 2: — das ist der Namespace-Index, den wir im Server registriert haben. Starten Sie den Server, dann den Client, und Sie haben einen vollständigen Umlauf: Ihr Client hat eine Maschine entdeckt, ihre Temperatur gelesen und geändert — mit Bedeutung an jedem Wert.
Praxis, Teil 3: Live-Änderungen abonnieren (und ein Hinweis zu Embedded-Servern)
Ständiges Abfragen ist verschwenderisch; lassen Sie den Server Ihnen Änderungen zusenden. Dieser Client abonniert und reagiert jedes Mal, wenn sich die Temperatur ändert:
import asyncio
from asyncua import Client
class SubHandler:
def datachange_notification(self, node, val, data):
print("Neue Temperatur:", val)
async def main():
url = "opc.tcp://localhost:4840/freeopcua/server/"
async with Client(url=url) as client:
machine = await client.nodes.objects.get_child(["2:Machine1"])
temperature = await machine.get_child(["2:Temperature"])
handler = SubHandler()
sub = await client.create_subscription(500, handler) # 500 ms
await sub.subscribe_data_change(temperature)
await asyncio.sleep(30) # 30 Sekunden lang zuhoeren
asyncio.run(main())
Für ein echtes Gerät kann derselbe Server direkt auf der Hardware laufen. Mit open62541 kann ein eingebettetes Gateway oder sogar ein leistungsfähiger Mikrocontroller einen OPC-UA-Server in C bereitstellen:
#include <open62541/server.h>
#include <open62541/server_config_default.h>
int main(void) {
UA_Server *server = UA_Server_new();
UA_ServerConfig_setDefault(UA_Server_getConfig(server));
UA_VariableAttributes attr = UA_VariableAttributes_default;
UA_Double temperature = 22.5;
UA_Variant_setScalar(&attr.value, &temperature,
&UA_TYPES[UA_TYPES_DOUBLE]);
attr.displayName = UA_LOCALIZEDTEXT("en-US", "Temperature");
UA_Server_addVariableNode(server,
UA_NODEID_STRING(1, "temperature"),
UA_NODEID_NUMERIC(0, UA_NS0ID_OBJECTSFOLDER),
UA_NODEID_NUMERIC(0, UA_NS0ID_ORGANIZES),
UA_QUALIFIEDNAME(1, "Temperature"),
UA_NODEID_NUMERIC(0, UA_NS0ID_BASEDATAVARIABLETYPE),
attr, NULL, NULL);
UA_Server_runUntilInterrupt(server); // bis zum Stopp bereitstellen
UA_Server_delete(server);
return 0;
}
In dem Moment, in dem das läuft, kann jeder OPC-UA-Client — auch Ihr Python-Client aus Teil 2 — diese Variable direkt von der Hardware durchsuchen und lesen. Das ist die Kraft eines geteilten Standards.
Alles zusammen: die Architektur eines echten Projekts
Sie haben nun jedes Teil für eine echte industrielle Anwendung. Ein typisches OPC-UA-Projekt sieht so aus:
- Maschinen und SPS stellen ihre Daten als OPC-UA-Server bereit (viele moderne SPS können das nativ; ältere erhalten ein Gateway).
- Ein SCADA- oder MES-System agiert als Client, durchsucht und abonniert diese Server für Monitoring und Steuerung.
- Ein Historian oder eine Datenbank abonniert und zeichnet jede Änderung über die Zeit auf.
- Ein Cloud- oder IT-Connector überbrückt OPC UA zum Unternehmen — oft mit OPC UA PubSub über MQTT, um Daten effizient nach oben zu senden.
- Sicherheit — Zertifikate, Verschlüsselung und Benutzerrechte — schützt jede Verbindung durchgängig.
Jedes Konzept dieses Leitfadens — Adressraum, NodeIds, Services, Subscriptions, Sicherheit — hat hier eine klare Rolle. Zu verstehen, wie sie zusammenpassen, ist der Unterschied zwischen dem Anbinden eines Geräts und dem Entwurf einer sicheren, herstellerneutralen Fabrik.
Best Practices und häufige Fehler
- Entwerfen Sie Ihr Informationsmodell bewusst — nutzen Sie Companion Specifications, wo es sie gibt, damit andere Ihre Daten verstehen.
- Bevorzugen Sie Subscriptions gegenüber ständigem Lesen für Live-Daten.
- Niemals im "no security"-Modus im Betrieb laufen — immer Zertifikate und Verschlüsselung aktivieren.
- Verwalten Sie Zertifikate sauber — das Vertrauen zwischen Client und Server hängt davon ab.
- Wählen Sie den richtigen Transport — klassisches Client/Server zur Steuerung, PubSub zur großflächigen Verteilung.
- Verwechseln Sie Namespace-Indizes nicht — derselbe Name in einem anderen Namespace ist ein anderer Node.
Wie es weitergeht
Sie verstehen OPC UA nun von der Grundidee bis zu einem funktionierenden, gesicherten Projekt und haben sowohl einen Server als auch einen Client betrieben, inklusive Live-Subscriptions. Die natürlichen nächsten Schritte sind: zertifikatsbasierte Sicherheit am Server aktivieren, eine echte Maschine mit Objects, Variables und Methods modellieren, sich mit einer echten SPS verbinden und mit OPC UA PubSub zur Cloud überbrücken. Jeder baut direkt auf dem Fundament auf, das Sie jetzt haben.
OPC UA ist einfach zu beginnen und tief zu meistern — und ein sicheres, gut modelliertes, herstellerneutrales System über eine echte Fabrik zu entwerfen, ist genau die Arbeit, die ich tue. Wenn Sie Maschinen für Monitoring, Steuerung oder die volle Industrie-4.0-Integration anbinden und es sauber entwickelt haben möchten, nehmen Sie Kontakt auf — ich helfe Ihnen gern.
EN