OPC UA
OPC UA ist die gemeinsame, sichere Sprache, in der Maschinen Daten mit Bedeutung teilen.
Links steht das Leitsystem (der Client), rechts die Maschine mit ihrem OPC-UA-Server. Noch fliesst nichts.
In 30 Sekunden
OPC UA ist der Industrie-Standard, mit dem Maschinen ihre Daten nicht als nackte Zahlen liefern, sondern mit Namen, Einheit und Bedeutung. Damit versteht ein Leitsystem sofort, dass 21.5 die Temperatur in Grad Celsius ist, ohne dass jemand das vorher von Hand einprogrammiert. Weil OPC UA herstellerunabhängig ist und Sicherheit (Verschlüsselung und Zertifikate) fest eingebaut hat, gilt es als das Rückgrat der Industrie 4.0. Du triffst es überall an, wo Maschinen, Leitsysteme (SCADA/MES, also die zentralen Überwachungs- und Steuerungssysteme einer Fabrik) und die Cloud zuverlässig zusammenarbeiten sollen.
Stell dir vor, du kommst als neuer Mitarbeiter in eine grosse Fabrik. Bei einer alten Maschine bekommst du nur eine lange Liste nackter Zahlen in die Hand: 21.5, 1450, 1. Was bedeuten die? Keine Ahnung, du musst jemanden fragen, der ein geheimes Handbuch hat. OPC UA ist der Gegenentwurf: Die Maschine hängt dir einen sauber beschrifteten Katalog hin, durch den du selbst blättern kannst. Da steht: Maschine 1, darunter Temperatur = 21.5 Grad Celsius, Drehzahl = 1450 Umdrehungen pro Minute, Status = Läuft. Jeder Eintrag trägt seinen Namen, seine Einheit und seinen Typ direkt bei sich. Du musst niemanden mehr fragen, die Daten erklären sich selbst. Und der Katalog ist abschliessbar: Nur wer sich mit Ausweis anmeldet, darf hineinsehen, und niemand kann heimlich mitlesen. Und wenn du willst, sagst du: Sag mir Bescheid, sobald sich die Temperatur ändert. Dann meldet sich die Maschine von selbst bei dir, statt dass du ständig nachfragen musst.
Wo trifft man OPC UA an?
Werkzeugmaschinen
In modernen CNC-Fräs- und Drehmaschinen liefert OPC UA über die Branchen-Vorlage UMATI (ein einheitliches Datenmodell für Werkzeugmaschinen) herstellerunabhängige Maschinendaten an das Leitsystem.
Leitsysteme (SCADA/MES)
Ein zentrales Leit- oder Fertigungssystem (SCADA/MES, die Überwachungs- und Steuerungssysteme einer Fabrik) liest über OPC UA die Werte vieler verschiedener Maschinen und stellt sie auf einer Bedienoberfläche dar.
Cloud- und IIoT-Anbindung
Beim Weg der Fabrikdaten in die Cloud und ins IIoT (industrielles Internet der Dinge) dient OPC UA als sichere, selbsterklärende Quelle, aus der Analyse- und KI-Dienste ihre Daten beziehen.
Anlagen-Vernetzung über Hersteller hinweg
Wo Maschinen unterschiedlicher Marken in einer Linie zusammenarbeiten, spricht OPC UA als gemeinsame Sprache, statt dass jede Marke ihr eigenes Protokoll erzwingt.
Energie- und Gebäudetechnik
In grossen Anlagen sammeln Leitstände über OPC UA Messwerte von Sensoren und Steuerungen zentral ein, mit klarer Bedeutung und Einheit.
Digitaler Zwilling
Ein digitales Abbild einer Anlage bezieht seine Live-Werte über OPC UA, weil die Struktur der Daten schon im Adressraum mitgeliefert wird.
Gut geeignet für
- Wenn Maschinen verschiedener Hersteller zusammenarbeiten sollen, weil OPC UA eine herstellerunabhängige, gemeinsame Sprache ist.
- Wenn Daten sich selbst erklären müssen, weil jeder Wert Name, Einheit und Datentyp direkt bei sich trägt.
- Wenn Sicherheit Pflicht ist, weil Verschlüsselung, Signierung und Zertifikate fest eingebaut sind.
- Wenn du komplexe Anlagen sauber abbilden willst, weil sich ganze Anlagen als übersichtlicher Baum aus Bauteilen, Messwerten und aufrufbaren Funktionen abbilden lassen.
- Wenn du plattformunabhängig bleiben willst, weil OPC UA auf Windows, Linux und auf kleinen, fest in Geräte eingebauten Steuer-Computern läuft.
Weniger geeignet für
- Für kleinste, batteriebetriebene Sensoren mit sehr wenig Rechenleistung, hier ist ein leichtgewichtiges Protokoll wie MQTT oder CoAP (schlanke Protokolle für stromsparende Geräte) oft passender.
- Für sehr einfache Abfragen einzelner Zahlenwerte ohne Bedeutungsbedarf, wo das schlanke Modbus TCP (ein sehr einfacher, alter Standard für nackte Zahlenwerte) genügt und weniger Aufwand macht.
- Für harte Echtzeit im Mikrosekunden-Takt zwischen Steuerung und Antrieb, dort sind Feldbus-Systeme wie EtherCAT oder PROFINET (blitzschnelle Direktverbindungen in der Steuerungsebene) zuständig.
- Für die Verteilung an sehr viele Empfänger gleichzeitig ist das klassische Frage-Antwort-Muster von OPC UA schwach; hier braucht es entweder MQTT (das über einen Broker, eine Verteilstation, Nachrichten an viele weiterreicht) oder die neuere PubSub-Betriebsart von OPC UA selbst, die mit wachsender Empfängerzahl besser zurechtkommt.
Fakten
- IEC 62541 (OPC Unified Architecture)
- OPC Foundation
- erste Spezifikation ab 2006, Version 1.0 (ohne Windows-Bindung) 2008; Nachfolger des alten OPC, das nur auf Windows lief und an Microsoft-Technik gebunden war
- Endpoint = Anschlussadresse der Maschine, Standard opc.tcp:// auf Port 4840 (platzsparendes Maschinenformat), zusätzlich Variante über HTTPS
- Client/Server (Browse, Read, Write, Subscribe) plus PubSub-Erweiterung (Teil 14)
- Informationsmodell, Adressraum aus Knoten (Objekte, Variablen, Methoden) mit Metadaten
- Signierung und Verschlüsselung, X.509-Zertifikate, Security Modes (None, Sign, Sign&Encrypt) plus Security Policies (Algorithmen, z. B. Basic256Sha256)
- herstellerunabhängig und plattformunabhängig (Windows, Linux, kleine eingebaute Steuer-Computer)
Im Detail
Das Informationsmodell: Daten mit Bedeutung
Der grosse Unterschied zu älteren Protokollen ist das Informationsmodell. Bei einfachen Systemen liest du nur nackte Zahlen aus nummerierten Speicherplätzen, sogenannten Registern. Was die Zahl bedeutet, steht nirgends im Protokoll, das musst du separat wissen.
OPC UA legt stattdessen einen Adressraum an. Das ist ein durchsuchbarer Baum aus Knoten. Ein Knoten kann ein Objekt sein (zum Beispiel Maschine 1), eine Variable (zum Beispiel Temperatur) oder eine Methode (eine aufrufbare Funktion). Jeder Wert trägt seine Beschreibung direkt bei sich: einen sprechenden Namen, seinen Datentyp und, wo sinnvoll, seine Einheit wie Grad Celsius.
Dadurch erklären sich die Daten selbst. Ein Programm kann durch den Baum blättern und versteht die Struktur, ohne dass ein Mensch vorher ein geheimes Handbuch übersetzt hat.
Client und Server: Browse, Read, Write, Subscribe
OPC UA arbeitet im Kern nach dem Client/Server-Prinzip. Die Maschine oder Steuerung stellt einen OPC-UA-Server bereit, der die Daten anbietet. Ein Client, etwa ein Leit- oder Fertigungssystem, verbindet sich damit und fragt sie ab.
Der Client hat vier Grundwerkzeuge. Mit Browse blättert er durch den Adressraum und entdeckt, was es gibt. Mit Read liest er einen Wert. Mit Write schreibt er einen Wert zurück. Mit Subscribe abonniert er einen Wert.
Ein Abo ist besonders praktisch. Der Client legt sogenannte Monitored Items an, also überwachte Werte. Ändert sich so ein Wert, schickt der Server von selbst eine Notification, eine Meldung. So muss der Client nicht ständig nachfragen, sondern erfährt Änderungen automatisch.
Sicherheit ist fest eingebaut
Anders als viele ältere Industrieprotokolle bringt OPC UA Sicherheit von Haus aus mit. Nachrichten können signiert werden, damit niemand sie unbemerkt verändert, und verschlüsselt werden, damit niemand mitliest.
Grundlage sind X.509-Zertifikate. Jede Anwendung, ob Client oder Server, besitzt ein eigenes Zertifikat, mit dem sich beide Seiten gegenseitig ausweisen. Beim Verbindungsaufbau einigen sie sich auf einen Security Mode (None, Sign oder Sign&Encrypt) und eine Security Policy, die die verwendeten kryptografischen Algorithmen festlegt (zum Beispiel Basic256Sha256).
Die drei Schutzstufen des Security Mode sind: None (kein Schutz), Sign (nur signiert) und Sign&Encrypt (signiert und verschlüsselt). Die Stufe None ist nur für Tests gedacht. In einer echten Anlage nutzt du immer mindestens Sign, besser Sign&Encrypt.
Companion Specifications und PubSub
Damit nicht jeder Hersteller sein eigenes Datenmodell erfindet, gibt es Companion Specifications, also standardisierte Branchen-Vorlagen für eine ganze Branche oder Geräteklasse. Ein bekanntes Beispiel ist UMATI für Werkzeugmaschinen. Dadurch heisst dieselbe Grösse bei jeder Maschine gleich und liegt an derselben Stelle im Baum.
Neben dem klassischen Client/Server-Muster gibt es die PubSub-Erweiterung, beschrieben in Teil 14 der Norm. Damit kann ein Publisher (die sendende Rolle) seine Daten an viele Subscriber (die empfangende Rolle) zugleich verteilen, ohne dass jeder einzeln eine Verbindung aufbaut. Das eignet sich für 1-zu-viele-Szenarien; der Transport läuft über Broker (zum Beispiel MQTT oder AMQP) oder direkt via UDP-Multicast.