Understanding OPC

OPC-Interoperabilität: offene Konnektivität durch offene Standards

OPC ist eine Client-/Server-Technologie. Eine Anwendung agiert als Server, der die Daten bereitstellt, und die andere als Client, der die Daten nutzt.

OPC ist ein allgemein anerkannter industrieller Kommunikationsstandard, der den Austausch von Daten zwischen Geräten und Steuerungsanwendungen mehrerer Anbieter ohne Beschränkungen durch Eigentumsrechte ermöglicht. Ein OPC-Server ermöglicht die kontinuierliche Kommunikation von Daten zwischen SPSen in der Werkstatt, im Einsatz befindlichen RTUs, HMI-Stationen und Softwareanwendungen auf Desktop-PCs. Auch wenn die Hardware und Software von verschiedenen Anbietern stammen, ist dank OPC Compliance kontinuierliche Echtzeitkommunikation möglich.

OPC hat zu einer besseren Zusammenarbeit zwischen Technologieanbietern und Technologienutzern geführt. Mithilfe von OPC können Anbieter im Automationsbereich Lösungen bereitstellen, die wirklich offen sind, sodass die Benutzer eine größere Auswahl an Automationsanwendungen zur Verfügung haben. Für die Branche ist dies eine spannende Zeit. Interoperabilität, offene Lösungen und Entscheidungsfreiheit haben es Fachleuten im Automationsbereich weltweit ermöglicht, die Vorteile der OPC-Integration in industriellen Anwendungen zu nutzen.

OPC bedeutet offene Konnektivität für die industrielle Automation und die Unternehmenssysteme zur Unterstützung der Branche. Interoperabilität wird durch die Erstellung und Pflege von nicht proprietären, offenen Standardspezifikationen sichergestellt. Die erste Spezifikation eines OPC-Standards war das Ergebnis der Zusammenarbeit von mehreren weltweit führenden Anbietern von Automationslösungen mit Microsoft. Die Spezifikation basierte ursprünglich auf den OLE COM- und DCOM-Technologien von Microsoft und definierte einen Standardsatz von Objekten, Schnittstellen und Methoden für die Verwendung in Prozesssteuerungs- und Fertigungsautomationsanwendungen, um Interoperabilität zu ermöglichen. Die COM/DCOM-Technologien stellten den Rahmen für die zu entwickelnden Softwareprodukte dar. Inzwischen gibt es Hunderte von OPC Data Access-Servern und -Clients.

OPC-Standards basieren auf allgemeinen Computing-Technologien. Die Produkte der OPC-Mitglieder umfassen eine breite Palette an Tools für verschiedene Zielgruppen – von Personen, die Standardprodukte vorziehen, über erfahrenere Ingenieure, die die Effizienz eines Toolkits schätzen, bis hin zu Entwicklern, die die ganze Anwendung selbst erstellen möchten.

Übersicht über OPC Data Access

Diese Spezifikation beschreibt die OPC COM-Objekte und die von den OPC-Servern implementierten Schnittstellen. OPC-Server werden von verschiedenen Anbietern bereitgestellt, und ein OPC-Client kann eine Verbindung zu OPC-Servern mehrerer Anbieter herstellen.

Mit dem vom Anbieter bereitgestellten Code werden die Geräte und Daten bestimmt, auf die jeder Server zugreifen kann, sowie die Datennamen und die Details zum physischen Datenzugriff durch den Server. Genaue Angaben zu Benennungskonventionen folgen in einem Abschnitt weiter unten.

Die Objekte, aus denen sich ein OPC-Server auf hoher Ebene zusammensetzt, sind ein Server, eine Gruppe und ein Element. Im OPC-Serverobjekt werden Informationen über den Server gepflegt, und das Serverobjekt dient als Container für OPC-Gruppenobjekte. Im OPC-Gruppenobjekt werden Informationen über das Objekt selbst gepflegt, und es stellt den Mechanismus für die Aufbewahrung und logische Anordnung der OPC Items bereit.

Die OPC-Gruppen bieten eine Methode für Clients zum Organisieren der Daten. Die Gruppe kann beispielsweise Elemente in einer bestimmten Berichts- oder Bedieneranzeige darstellen. Daten können gelesen und geschrieben werden. Auf Ausnahmen basierende Verbindungen können auch zwischen dem Client und Elementen in der Gruppe erzeugt und nach Bedarf aktiviert bzw. deaktiviert werden. Ein OPC-Client kann die Geschwindigkeit konfigurieren, mit der ein OPC-Server die Datenänderungen dem OPC-Client bereitstellen sollte. Es gibt zwei Arten von Gruppen: öffentlich und lokal. Öffentliche Gruppen lassen eine Client-übergreifende gemeinsame Nutzung zu, bei lokalen Gruppen ist dies auf einen Client beschränkt. (Informationen zum Ziel, Zweck und zur Funktionalität sowie weitere Einzelheiten finden Sie im Abschnitt zu öffentlichen Gruppen.) Für die öffentlichen Gruppen gibt es außerdem spezielle optionale Schnittstellen. Der Client kann innerhalb jeder Gruppe ein oder mehrere OPC Items definieren.

Die OPC Items stellen Verbindungen zu Datenquellen innerhalb des Servers dar. Aus der Perspektive der benutzerdefinierten Schnittstelle ist ein OPC Item für einen OPC-Client nicht als Objekt zugänglich. Deswegen wird für ein OPC Item keine externe Schnittstelle definiert. Der gesamte Zugriff auf OPC Items erfolgt über ein OPC-Gruppenobjekt, das das OPC Item enthält, oder einfach an der Stelle, an der das OPC Item definiert ist.

Mit jedem Element ist ein Wert, eine Angabe zur Qualität und ein Zeitstempel verknüpft. Der Wert liegt in Form einer VARIANTE vor, und die Qualitätsangabe ähnelt der Angabe durch den Fieldbus.

Beachten Sie, dass die Elemente nicht die Datenquellen darstellen; sie sind nur Verbindungen zu ihnen. Beispielsweise sind die Tags in einem DCS-System unabhängig davon vorhanden, ob gerade ein OPC-Client darauf zugreift. Das OPC Item sollte nur als Angabe der Datenadresse betrachtet werden und nicht als die tatsächliche physische Datenquelle, die von der Adresse referenziert wird.

Details zu OPC Data Access

OPC ist zwar primär für den Zugriff auf Daten aus einem vernetzten Server ausgelegt, OPC-Schnittstellen können jedoch an vielen Stellen einer Anwendung verwendet werden. Auf der untersten Ebene ermöglichen sie die Übertragung von Rohdaten aus den physischen Geräten in ein SCADA- oder DCS-System bzw. von einem SCADA- oder DCS-System in die Anwendung. Aufgrund der Architektur und des Designs kann ein OPC-Server eingerichtet werden, der es zulässt, dass eine Clientanwendung auf Daten von vielen OPC-Servern zugreift, die von vielen verschiedenen OPC-Anbietern auf unterschiedlichen Knoten eines einzelnen Objekts bereitgestellt werden.

Die OPC-Spezifikation gibt die COM-Schnittstellen oder die Art der Schnittstellen an. Die Implementierung dieser Schnittstellen gibt sie jedoch nicht an. Sie beschreibt das Verhalten, das die Schnittstellen den Clientanwendungen, die sie verwenden, bereitstellen sollen. Dazu gehören Beschreibungen der Architekturen und der Schnittstellen, die für diese Architekturen am besten geeignet erscheinen. Wie alle COM-Implementierungen ist die Architektur von OPC ein Client-/Server-Modell, in dem die OPC-Serverkomponente eine Schnittstelle für die OPC-Objekte bereitstellt und diese verwaltet.

Bei der Implementierung eines OPC-Servers sind verschiedene spezifische Aspekte zu berücksichtigen. Der Kernpunkt ist die Häufigkeit der Datenübertragung auf physische Geräte über Kommunikationspfade, die nicht freigegeben werden können. Aus dem Grund wird erwartet, dass der OPC-Server eine lokale oder Remote-EXE-Datei umfasst, die für die effiziente Datensammlung von einem physischen Gerät verantwortlich ist.

Eine OPC-Clientanwendung kommuniziert mit einem OPC-Server über die angegebenen OPC-Schnittstellen (benutzerdefinierte oder Automationsschnittstelle). OPC-Server müssen die benutzerdefinierte Schnittstelle implementieren; die Implementierung der Automationsschnittstelle ist optional.

Ein In-Process-Handler (OPC Handler) kann zur Ordnung der Schnittstelle und Bereitstellung zusätzlicher Funktionen auf Elementebene der OPC-Automationsschnittstelle verwendet werden.

Es wird außerdem erwartet, dass der Server die von den verschiedenen Clients angeforderten Datenzugriffe konsolidiert und optimiert, um die Kommunikation mit den physischen Geräten effizienter zu gestalten. Bei Eingaben (Lesevorgängen) werden die vom Gerät zurückgegebenen Daten für die asynchrone Verteilung oder synchrone Sammlung durch verschiedene OPC-Clients gepuffert. Bei Ausgaben (Schreibvorgängen) aktualisiert der OPC-Server die Daten der physischen Geräte für die OPC-Clients.

Bei der aktuellen OPC Data Access-Spezifikation handelt es sich um Version 3.0. KEPServerEX bietet vollständige Unterstützung für OPC DA 3.0 seit 2005.

Die Geschichte von OPC

Im Jahr 1994 bildeten Anbieter aus vielfältigen Industriebereichen ein Konsortium, das heute als OPC Foundation bekannt ist. Die OPC Foundation hat es sich zum Ziel gesetzt, eine einzelne Client-/Serverspezifikation zu entwickeln, die es jedem Anbieter ermöglichen sollte, Software und Anwendungen zu entwickeln, die eine schnelle und zuverlässige gemeinsame Nutzung von Daten erlaubten. Gleichzeitig sollte auf die proprietären Schemata verzichtet werden, die dafür verantwortlich waren, dass diese Anbieter doppelten Entwicklungsaufwand hatten.

Die erste von der OPC Foundation entwickelte Spezifikation war die Data Access-Spezifikation 1.0a, die Anfang 1996 veröffentlicht wurde. Mithilfe dieser Spezifikation konnten die Anbieter Client-/Serversoftware in kurzer Zeit entwickeln.

Ein wichtiges Ziel der OPC Foundation und der Data Access-Spezifikation bestand darin, die Anforderung zu eliminieren, dass Anbieter von Clientanwendungen einen eigenen proprietären Satz von Kommunikationstreibern entwickeln mussten. Für viele Anbieter war der Aufwand für die Entwicklung zahlreicher Kommunikationstreiber größer als der Aufwand für die Entwicklung der eigentlichen Clientanwendungen. Dank der OPC-Technologie konnten sich die Anbieter nun fast ausschließlich auf die Entwicklung der Clientanwendungen konzentrieren. Die Data Access-Spezifikation definiert die Erstellung der Client- und der Server-Anwendungsschnittstelle. Bei genauer Einhaltung der Spezifikation kann sich ein Anbieter von Clientanwendungen darauf verlassen, dass jeder OPC-Server, den es für ein industrielles Gerät gibt, die für den Datenzugriff benötigte Konnektivität bereitstellen kann. Faktoren wie Markteinführungszeit oder Zuverlässigkeit stellen für OPC-Anwendungen nicht länger eine Einschränkung dar.

OPC bietet Endbenutzern den zusätzlichen Vorteil, dass sie zur Lösung von Anwendungsproblemen die am besten geeignete Software auswählen können. Wenn eine Anwendungssoftware in der Vergangenheit nicht über den benötigten Kommunikationstreiber verfügte oder der verfügbare Treiber nicht die gewünschte Leistung erbrachte, gab es dafür nur eine Lösung: Der Anwendungsanbieter musste überzeugt werden, den gewünschten Treiber zu entwickeln oder den vorhandenen Treiber zu reparieren. Und beide Lösungswege waren gewöhnlich mit einem größeren Zeitaufwand verbunden. Dank OPC müssen die Endbenutzer die Ressourcenbeschränkungen der Anbieter von Clientanwendungen nicht länger in Kauf nehmen. Die Benutzer haben jetzt eine Vielzahl an Anbietern von OPC-Servern zur Auswahl, wenn es darum geht, auf eine neue Treiberanforderung einzugehen oder ein Leistungsproblem zu lösen. Und die Anbieter von Clientanwendungen können sich jetzt ungestört auf die kontinuierliche Verbesserung ihrer Kernprodukte konzentrieren, da sie nicht mehr auf Kommunikationsprobleme und -anforderungen eingehen müssen.

Kepware hat es sich zum Ziel gesetzt, innerhalb der OPC-Umgebung zu einem führenden Anbieter von OPC-Servern zu werden – und zwar durch die Bereitstellung eines Produkts, das zuverlässig und benutzerfreundlich ist. Hinter KEPServerEX steckt ein jahrelanger Entwicklungsaufwand in den Bereichen Kommunikationstreiber und OPC-Technologie.

Hier finden sich viele Informationen zu OPC. Aber wie funktioniert die OPC-Spezifikation?

Um weitere Informationen zum OPC-Standard zu erhalten, besuchen Sie die OPC Foundation, oder laden Sie das eBook Understanding OPC von Kepware herunter.