Grenzenloser Datenverkehr mit OPC

Wie man Systemgrenzen einfach überwinden und Daten zwischen OPC-Servern und Datenbanken austauschen kann

Autor: Sören Rose, erschienen im SPS-Magazin, HMI-Special 2003, S. 38–39, PDF

OPC hat sich schnell etabliert in der Automatisierungstechnik. Doch leider erlaubt die reale Umsetzung keine Querkommunikation der Server untereinander. Wie man OPC sehr einfach zum echten Softwarebus ausbauen kann, zeigt der folgende Beitrag.

In der Automatisierung hat sich OPC als Datenzugriffsstandard weitgehend durchgesetzt. Daten werden von verschiedensten Clients mit den Servern ausgetauscht: Office-Anwendungen (Excel, Access, ...), Visualisierungen, Betriebsdatenerfassung, Produktionsplanungs-Systeme, Manufacturing Execution Systeme. Die Liste ließe sich beliebig fortführen. Eins ist aber allen gemeinsam, alle sind echte Clients im Sinne des Client-Server Prinzips.

OPC als Softwarebus

OPC wird oftmals als Softwarebus dargestellt. Das heißt, es verbinden sich verschiedene Kommunikationspartner auf ein genormtes Medium um Daten auszutauschen. Dies bedeutet aber für das Modell OPC auch, dass die OPC-Server untereinander ebenfalls Daten austauschen können sollten. In der Realität gibt es diese Möglichkeit aber nicht, da die OPC-Server des OPC DA Standards nur die Server-Schnittstelle implementieren und deswegen keine Daten anderer OPC-Server anbinden können. In der Praxis zeigt sich jedoch oftmals die Notwendigkeit Daten zwischen Automatisierungskomponenten auszutauschen. Innerhalb eines abgeschlossenen Systems ist dies selbstverständlich und stellt kein Problem dar, weil entsprechende Mechanismen existieren. Als Beispiel ist das Einblenden einer E/A-Baugruppe in den Adressbereich einer SPS eine Selbstverständlichkeit. Aber wie sieht es beispielsweise mit einer Wago-I/O-Klemme aus, die mit dem Ethernet verbunden ist ? An dieser Stelle müssen Sonderlösungen erstellt werden, um die entsprechenden Komponenten miteinander kommunizieren zu lassen, obwohl beide Systeme über einen OPC-Server verfügen.

Lösungsmöglichkeiten

Die Daten anderer Automatisierungskomponenten sind mit Daten aus Datenbanken gleichzusetzen. Damit die Komponente ihre Aufgabe erfüllen kann, benötigt sie die entsprechenden Eingabedaten. Ob diese in diesem Fall von einer anderen Komponente oder aus einer Datenbank stammen, ist nicht relevant. Lediglich die Bedeutung der Daten ist eine andere. Von einer anderen Komponente werden aktuelle Betriebszustände abgefragt, wohingegen aus der Datenbank Rezepturen und Parameter geladen werden. Auch die andere Richtung ist durchaus denkbar: Daten, die aus dem Ergebnis der Arbeit einer Komponente entstehen, können in einer Datenbank wertvolles Dokumentationsmaterial sein, z.B. für die Betriebsdatenerfassung.

Den Softwarebus nutzen

Mit dem schon erwähnten Softwarebus sind schon alle Partner in diesem Szenario verbunden: PCs, auf denen die Datenbanken liegen, sowie die verschiedenen OPC Server der Automatisierungskomponenten. Alles was in dieser Umgebung noch fehlt ist eine Instanz, die den Transfer der Daten zu den jeweiligen Interessenten übernimmt.

Client mit Sonderfunktion

Der Datentransfer kann von einem Programm übernommen werden, das sich den Schnittstellen des Softwarebusses anpasst. Aus der OPC Sicht kommt damit nur ein standardmäßiger Client in Frage, der lediglich eine gewisse Sonderfunktion wahrnimmt, weil er die Daten nicht selbst auswertet, sondern nur an den entsprechenden Adressaten weiterleitet.Entsprechend dem OPC Standard würde dieses Programm auch einen durchgängigen Datenbankstandard implementieren, um verschiedenste Datenbanken anzubinden (ADO, ODBC, ...).

OPC Router

Die inray GmbH hat ein solches Programm zur OPC-OPC- und OPC-DB-Kommunikation entwickelt, den inray OPC Router. Dieser Router implementiert eine OPC DA Clientschnittstelle, so dass er zu allen auf dem Markt erhältlichen OPC-Servern kompatibel ist. Datenbanken können mit dem sehr schnellen ADO-Zugriff angebunden werden. Die Datentransfers werden in einer sogenannten Verbindungsliste definiert. Es können jeweils zwei Partner gewählt werden, zwischen denen transferiert wird. Bei jedem Partner wird ein Datenpunkt bzw. eine Datenpunktgruppe (für Tabellen) ausgewählt und ein Trigger definiert, der die Übertragung auslöst. Es werden ereignisgesteuerte, zyklische, regelbasierte und änderungsbasierte Trigger zur Verfügung gestellt. Jeder übertragene Wert kann zudem noch mit einer Normierungsregel verrechnet werden. Da das Programm als NT-Service arbeitet, ist es im Hintergrund tätig. Zudem arbeitet ein Dienst im Gegensatz zu einem Programm auch dann, wenn kein Benutzer am Computer angemeldet ist. Zur Diagnose wird zyklisch eine HTML-Datei vom Router generiert, die lokal oder im Netzwerk (Intranet) betrachtet werden kann, um den Zustand der Verbindungen zu kontrollieren.

Autor: Dipl. Ing. (FH) Sören Rose ist Leiter der Softwareabt. in der inray Industriesoftware GmbH. Sein Aufgabengebiet umfasst u. a. OPC-Client/Server-Entwicklung, Datenbank-Applikationen usw.