Einführung zu OPC

Überblick

OPC (OLE for Process Control) ist eine Standardschnittstelle für die Kommunikation zwischen zahlreichen Datenquellen, darunter Geräte in Produktionsstätten, Laborausstattung, fest eingebaute Prüfsysteme und Datenbanken. Um den Aufwand bei der Entwicklung gerätespezifischer Protokolle zu verringern, Unstimmigkeiten zwischen Geräten möglichst auszuschließen, Support bei Änderungen der Hardwarefunktionen zu bieten und Zugriffskonflikte bei Prozesssteuerungssystemen zu vermeiden, hat die OPC Foundation einige Standardschnittstellen festgelegt, die es beliebigen Clients erlauben, auf OPC-konforme Geräte zuzugreifen. Die meisten Anbieter von Datenerfassungs-, Steuer- und Regelungsgeräten für die Industrie, wie etwa speicherprogrammierbare Steuerungen (SPSen) und Programmable Automation Controllers (PACs), haben ihre Geräte so ausgelegt, dass sie mit dem Standard der OPC Foundation eingesetzt werden können.

Inhalt

  1. COM/DCOM
  2. OPC-Implementierung
  3. OPC für Anwendungen mit hoher Kanalanzahl
  4. Einsatz von OPC mit LabVIEW
  5. Einsatz von LabVIEW als OPC-Client
  6. Einsatz von LabVIEW als OPC-Server
  7. Links auf thematisch verwandte Seiten

COM/DCOM

Die zugrundeliegende Schicht der Spezifikation OPC Data Access (DA) beruht auf der COM/DCOM-Technologie von Microsoft, die eine Kommunikation zwischen Prozessen bei verschiedenen Programmiersprachen für das Windows-Betriebssystem ermöglicht. Bei modernen Betriebssystemen werden Prozesse gekapselt, um mehr Stabilität und Sicherheit zu bieten. COM stellt eine Schicht für die Kommunikationsschnittstelle bereit, die lokale und dezentrale Prozeduraufrufe zwischen Prozessen erlaubt. DCOM (Distributed COM) ist die Erweiterung von COM und unterstützt die Kommunikation zwischen Objekten auf Netzwerkrechnern.

Mit DCOM kann eine Sicherheitstransparenz erreicht werden, durch die verteilte Anwendungen dann ohne sicherheitsspezifische Kodierung oder Entwicklungen beim Client oder den Komponenten sicher sind. Entwickler und Administratoren können bei DCOM nämlich die Sicherheitseinstellungen für jede Komponente konfigurieren. So wie Windows-Betriebssysteme Administratoren das Festlegen von Zugriffssteuerungslisten (ACLs) für Dateien und Verzeichnisse erlauben, speichert DCOM ACLs für Komponenten. Diese ACLs zeigen an, welche Benutzer oder Benutzergruppen Zugriff auf eine Komponente einer bestimmten Klasse haben.  Zusätzliche Spezifikationen zur DCOM-Sicherheit liefert der Beitrag DCOM Technical Overview auf der TechNet-Website von Microsoft. 

OPC-Implementierung

OPC sorgt dafür, dass Client- und Serveranwendungen miteinander kommunizieren können. Der Standard ist als Abstraktionsschicht zwischen Industrienetzwerken und proprietären SPS-Treibern konzipiert. Er spezifiziert das Verhalten, das die Schnittstellen ihren Clients bereitstellen sollen. Die Clients wiederum empfangen die Daten von den Schnittstellen mittels gängiger Funktionsaufrufe und Methoden. Folglich kann, solange ein Computeranalyse- oder Datenerfassungsprogramm ein OPC-Client-Protokoll umfasst und der Treiber eines Industriegeräts eine entsprechende OPC-Schnittstelle hat, das Programm mit dem Gerät kommunizieren. Die Spezifikation beinhaltet auch ein Protokoll für den Einsatz von Datensteuerungssystemen und Anwendungsdatenbanken sowie Online-Datenzugriff, Alarm- und Ereignisbehandlung und historischen Datenzugriff (HDA) für alle diese Datenquellen.

Der Datenzugriffsserver hat drei Unterteilungen:

  • Server: umfasst alle Gruppenobjekte
  • Gruppe: pflegt Informationen zur Gruppe, beinhaltet und organisiert die OPC-Objekte
  • Objekt: beinhaltet eine einzigartige Kennung, die innerhalb der Gruppe verwaltet wird. Die Kennung dient als Referenz für die einzelne Datenquelle sowie als Wert, Qualität und Zeitstempelangabe. Der Wert bezeichnet die Daten von der Quelle. Der Qualitätsstatus liefert Informationen zum Gerät. Der Zeitstempel bezeichnet die Zeit, in der die Daten abgerufen wurden.

Eine OPC-Anwendung greift auf alle Objekte über die OPC-Gruppe zu statt über das Objekt selbst. Die Gruppe beinhaltet auch eine spezifische Aktualisierungsrate für sich selbst, die dem Server mitteilt, mit welcher Geschwindigkeit dem OPC-Client Datenänderungen bereitgestellt werden sollen. Ein für jede Gruppe festgelegter Totbereich teilt dem Server mit, dass Werte abzulehnen sind, falls Änderungen daran unterhalb des spezifizierten prozentualen Totbereichsanteils liegen.

Der OPC-Server sorgt bei den Clients auch für die Alarm- und Ereignisbehandlung. Innerhalb eines Servers ist ein Alarm ein ungewöhnlicher Zustand mit spezieller Bedeutung für den Client: eine Bedingung, die mit dem Zustand des Servers, einer Gruppe oder eines Objekts innerhalb des Servers verbunden wird. Wenn beispielsweise der Wert einer Datenquelle, der die reale Temperatur eines Mischers darstellt, unterhalb einer bestimmten Temperatur fällt, schickt der OPC-Server einen Alarm an die Anwendung, so dass diese entsprechend auf die niedrige Temperatur reagiert. Ereignisse sind messbare Vorkommnisse, die für den Server und den Client wichtig sind. Dazu zählen Systemfehler, Änderungen der Systemkonfiguration und Maßnahmen des Bedieners.

OPC umfasst zudem HDA-Standards. Bei HDA (Historical Data Access) handelt es sich eine Möglichkeit des Zugriffs auf Daten, die von älteren Engines gespeichert wurden, darunter Server für die Speicherung von Rohdaten sowie komplexe Datenspeicher- und Analyseserver. Dieses Merkmal von OPC sorgt für eine Interoperabilität proprietärer Datenbanksysteme.

OPC für Anwendungen mit hoher Kanalanzahl

Das von der OPC Foundation bestimmte Design, die Ziele und die Beweggründe für die Industriestandardisierung von Steuer- und Regelsystemen ermöglichten die Implementierung von Systemen mit hoher Kanalanzahl, die effizient und gut erweiterbar sind.

Entwickler von Client-Software und Nutzer dieser Anwendungen sind bei der Implementierung einer Lösung, die ihren Anforderungen entspricht, flexibler, weil Daten in Gruppen organisiert sind und die Kennzeichnung bzw. Identifizierung von Datenpunkten von der Client-Software festgelegt wird. Die Gruppierung ist bei großen Sätzen von Datenquellen von Vorteil, da so die Daten besser organisiert sind und der Verweis auf ähnliche Datensätze erleichtert wird. Bei einer OPC-Anwendung versieht ein Tag einen I/O-Punkt mit einer einzigartigen Kennung. Gemäß der OPC-Spezifikation ist die Client- bzw. die Server-Software für das Benennen von Tags zuständig. Die Software kann Tags programmatisch benennen oder festlegen, dass der Benutzer die Tags benennt. Diese Flexibilität ist ein entscheidender Faktor bei der Möglichkeit der Client-Software, Lösungen bereitzustellen, die für Anwendungen mit hoher Kanalanzahl zugeschnitten sind.

Die Client-Software legt zudem die Geschwindigkeit fest, mit der der Server dem Client neue Daten bereitstellt. Da die Datenveröffentlichung dem Server zugewiesen ist, muss die Client-Software keine zeitraubende Datenabfrage durchführen. So steht mehr Zeit für die Analyse und das Datenloggen zur Verfügung. Des Weiteren wird die Client-Software vielmehr zum reaktiven Objekt, das auf die Ankunft neuer Daten wartet. Somit ist dann der Client ereignisgesteuert und kann große Datensätze viel effizienter handhaben.  

Der Client legt Totbereiche auf dem Server fest. Auf diese Weise kann er bestimmen, welche Daten wichtig sind. Die weniger wichtigen werden nicht berücksichtigen. Aufgrund des Prozentanteils des Totbereichs werden Werte abgelehnt, die sich nicht über einen bestimmten prozentualen Anteil des zuvor aufgezeichneten Werts hinaus verändern. Indem moderate Totbereichwerte etabliert werden, erhält der Client nur Informationen über Kanäle, die ihm wichtig erscheinen. So wird er nicht mit unnötigen Informationen überflutet. Er erhält damit die Möglichkeit, eine viel größere Anzahl an Kanälen zu überwachen.

Da OPC inzwischen Industriestandard ist, kann die Client-Software eine Verbindung zu fast jedem verfügbaren Gerät herstellen. Die Client-Software ist jetzt mit vielen Gerätetypen kompatibel, so dass sie auch vor dem Hintergrund großer Gerätezahlen und -varianten entwickelt werden kann. Die oben aufgeführten OPC-Eigenschaften sind nur ein Auszug aus einer ganzen Reihe von Vorteilen für Entwicklungssoftware, wenn OPC-Anbindungsmöglichkeiten genutzt werden, um Anwendungssoftware mit hoher Kanalanzahl zu implementieren.

Einsatz von OPC mit LabVIEW

Mithilfe von NI LabVIEW können Entwickler OPC-Systeme integrieren. Sowohl OPC-Clients als auch -Server lassen sich an LabVIEW-Anwendungen anbinden, um Daten auszutauschen. Dies ist bei LabVIEW hauptsächlich durch die Engine für Umgebungsvariablen (Shared Variable Engine, SVE) möglich. Die SVE wird mit der Installation von LabVIEW als Dienst auf dem Rechner installiert. Mithilfe der proprietären Technologie namens NI Publish-Subscribe Protocol (NI-PSP) verwaltet die SVE Aktualisierungen von Umgebungsvariablen. Sobald Umgebungsvariablen an die SVE übertragen werden, arbeitet die SVE als separater Prozess auf dem Rechner. So stehen beispielsweise die SVE-Objekte nach einem Neustart des Rechners automatisch zur Verfügung, unabhängig davon, ob LabVIEW oder ein VI ausgeführt wird. Überdies ist die SVE weiterhin für Aktualisierungen jederzeit verfügbar und wird solange ausgeführt, bis sie angehalten wird. Einzelheiten zu Netzwerk-Umgebungsvariablen liefert der Artikel Gepufferte Netzwerk-Umgebungsvariablen: Komponenten und Architektur in der NI Developer Zone.

Abb. 1: Die Engine für Umgebungsvariablen kann entweder ein OPC-Client oder ein Server sein.

Für OPC fungiert die SVE als vermittelnde Stelle zwischen NI-PSP-Datenobjekten und anderen Anwendungen. I/O-Server können als OPC-Clients konfiguriert werden. Diese Funktionalität ist Teil des LabVIEW Datalogging and Supervisory Control (DSC) Module. Die SVE lässt sich als OPC-Server konfigurieren, um NI-PSP-Datenobjekte im Netzwerk zu veröffentlichen, so dass andere OPC-Clients mit diesen Objekten interagieren können.

Einsatz von LabVIEW als OPC-Client

Das DSC Module stellt OPC-Client-I/O-Server für die Kommunikation mit allen Servern bereit, die über eine OPC-Serverschnittstelle gemäß OPC Foundation verfügen. Dadurch kann LabVIEW mit jeder SPS kommunizieren, die mit einem OPC-Server arbeitet. Ein OPC-Client-I/O-Server wird alle verfügbaren OPC-Server, die auf einem lokalen Rechner oder einem Netzwerkrechner installiert sind und ausgeführt werden, auflisten. Abbildung 2 zeigt die Beziehung zwischen den Komponenten, die an der Kommunikation zwischen LabVIEW und einer SPS beteiligt sind.

Abb. 2: LabVIEW und die SVE können über OPC mit SPSen kommunizieren.

SPSen stellen Daten im Netzwerk bereit. Ein OPC-Serverprogramm nutzt den proprietären Treiber der SPS, um OPC-Tags für jeden physikalischen Ein- und Ausgang an der SPS zu erzeugen. National Instruments bietet mit den NI-OPC-Servern eine OPC-Serverlösung an: Die NI-OPC-Server beinhalten eine Liste an Treibern für viele in der Branche gebräuchliche SPSen. Eine entsprechende Liste unterstützter SPSen ist in der NI Developer Zone unter Liste unterstützter Messgeräte- und Treiber-Plugins für NI-OPC-Server zu finden. Die im Lieferumfang des DSC Module enthaltenen OPC-Client-I/O-Server können mithilfe des OPC-DA-Standards Verbindungen zu jedem OPC-Tag herstellen. Die verschiedenen OPC-Client-I/O-Server innerhalb der SVE können mit unterschiedlichen Aktualisierungsraten, Prozentanteilen des Totbereichs und Abfragezyklen konfiguriert werden. Die SVE stellt eine PSP-URL für jeden OPC-Tag bereit, an den andere Umgebungsvariablen gebunden werden können, indem die Aliasing-Funktion aktiviert wird. Nachdem die Umgebungsvariablen in die SVE übertragen wurden und Werte erhalten, kann LabVIEW mithilfe eines VIs leicht Umgebungsvariablen lesen und schreiben.  

Einsatz von LabVIEW als OPC-Server

Die SVE kann als OPC-Server dienen. Dabei ist die SVE als OPC-Server nicht mit NI-OPC-Servern zu verwechseln, denn ihr fehlen bestimmte erforderliche proprietäre SPS-Treiber. Sie kann mit einer Netzwerk-Umgebungsvariablen OPC-Tags erstellen, zu denen ein OPC-DA-Client eine Verbindung herstellen kann. So können LabVIEW-VIs einfach mit anderer OPC-Client-Software kommunizieren.

Abb. 3: Die Engine für Umgebungsvariablen als OPC-Server

Eine häufige Anwendung für den Einsatz von SVE als OPC-Server sind Datenerfassungsgeräte von National Instruments und ein NI-DAQmx-Treiber, um einen virtuellen DAQmx-Kanal einzurichten. Auf diesen Kanal kann dann von einer NI-PSP-URL verwiesen werden. Dadurch kann die SVE eine Umgebungsvariable mit den Werten verbinden, die vom Datenerfassungsgerät gelesen werden. Sie nutzt anschließend OPC-DA-Standards, um OPC-Tags für die Umgebungsvariable zu erstellen. Auf diese Weise kann ein OPC-Client ein Datenerfassungsgerät auslesen und Daten darauf festhalten. Eine genaue Anleitung bietet der Beitrag Einsatz der Netzwerk-Umgebungsvariablen in LabVIEW und OPC mit NI-DAQmx in der NI Developer Zone.

Links auf thematisch verwandte Seiten

Nach oben