OPC. OPC was ist das eigentlich? Das OPC-Handbuch für Jedermann

Transkript

1 OPC was ist das eigentlich? Das OPC-Handbuch für Jedermann Darek Kominek, P. Eng. Alberta, Kanada VORWORT Das OPC-Handbuch für Jedermann ist ein leicht lesbarer Überblick über den am weitesten verbreiteten industriellen offenen Verbindungsstandard OPC. Dieses Whitepaper führt zuerst den OPC zugrunde liegenden Hauptgedanken ein, zeigt, warum sich OPC von herkömmlichen (häufig proprietären) Kommunikationsprotokollen unterscheidet und erklärt, wie OPC dabei hilft, die Beschränkungen solcher nativer Protokolle zu überwinden. Des Weiteren wird erläutert, aus welchen Bausteinen OPC besteht (OPC-Clients und OPC-Server) und wie sie zusammenarbeiten, um den Datenaustausch zu ermöglichen. Dank seiner klaren Illustrationen und dem minimalen Fachjargon hilft OPC-Handbuch für Jedermann -Lesern aller fachlichen Niveaus schnell zu begreifen, was OPC ist und wie sie es nutzen können, um Interkonnektivität in ihren eigenen Umgebungen herzustellen.

2 1. VORWORT 2. Wie OPC das Problem der Konnektivität von Automatisierungsdaten löst 2.1 Gibt es Beispiele für aktive OPC-Installationen in der Praxis? 3. Einführung in OPC 3.1. Was ist OPC? 3.2. Warum OPC dort Erfolg hat, wo gerätespezifische Treiber versagen 3.3. Wie die OPC-Kommunikation funktioniert (in konzeptueller Hinsicht) 3.4. Wie OPC funktioniert (in funktionaler Hinsicht) 3.5. Vorteile bei der Verwendung von OPC-Konnektivität 3.6. Welche Art von Daten unterstützt OPC? 3.7. Unterstützen alle OPC-Verbindungen alle OPC- Spezifikationen? 3.8. Kommt es darauf an, welche OPC-Spezifikation ein OPC- Client oder OPC-Server unterstützt? 4. OPC-Server 4.1. Was ist ein OPC-Server? 4.2. Was leisten OPC-Server? 4.3. Mit welchen Arten von Datenquellen (Geräten) können OPC-Server kommunizieren? 4.4. Wo finde ich einen OPC-Server für Gerät X? 4.5. Wie funktionieren OPC-Server? 4.6. Kann ein OPC-Server eines Anbieters mit OPC-Clients anderer Anbieter kommunizieren? 4.7. Können OPC-Server Informationen mit anderen OPC- Servern austauschen? 5. OPC-Clients 5.1. Was ist ein OPC-Client? 5.2. Was leistet ein OPC-Client? 5.3. Können OPC-Clients gleichzeitig mit mehreren Geräten (OPC-Servern) kommunizieren? 5.4. Wie funktioniert ein OPC-Client? 5.5. Zu wie vielen OPC-Servern kann ein OPC-Client Verbindungen herstellen? 5.6. Können OPC-Clients direkt mit anderen OPC-Clients kommunizieren? 5.7. Wo wird der OPC-Client installiert? 6. Fazit

3 2. Wie OPC das Problem der Konnektivität von Automatisierungsdaten löst HMI Prozessdatenarchiv Anwendung A B C D A B C D C D spezifische Treiber Heutzutage wird Automatisierung in allen wichtigen Industriezweigen intensiv genutzt. Obwohl unterschiedliche Branchen häufig unterschiedliche spezifische Geräte, Steuersysteme und Anwendungen verwenden, sehen sich alle mit einer rasch wachsenden Herausforderung konfrontiert: der Frage, wie sich Daten sowohl zwischen all diesen Komponenten als auch mit dem Rest des Unternehmens austauschen lassen. SPS / PLC PLS / DCS RTU Sensor Abbildung 1: Das Problem spezifischer Treiber: Jede Anwendung benötigt einen geräte- oder anwendungsspezifischen Treiber, damit sie mit den jeweiligen Geräten kommunizieren kann. Treiber können nicht von Anwendung zu Anwendung wiederverwendet werden, weil jede Anwendung ihre eigenen Datenformate verwendet. Bevor wir betrachten, was OPC ist und wie es eines der größten Kommunikationsprobleme im Automatisierungsbereich löst, schaut man sich am besten zuerst an, welche Probleme es bislang gab. Es folgt eine Liste von Faktoren, die traditionell die größten Probleme beim Datenaustausch verursacht haben, jeweils gefolgt von einer kurzen Erklärung, welche Auswirkung OPC auf diese Probleme hat: Proprietäre Protokolle: Anbieter setzten häufig proprietäre Protokolle ein, die es den Produkten einer bestimmten Produktlinie erlaubten, miteinander zu kommunizieren, die aber spezielle Treiber benötigten, um mit den Produkten anderer Anbieter zu kommunizieren. Zusätzliche Komplikationen ergaben sich dadurch, dass verschiedene Produktlinien desselben Anbieters häufig nicht miteinander kommunizierten, wodurch zusätzliche Anschlüsse erforderlich wurden. OPC löst dies, indem es dafür sorgt, dass es für den Datenempfänger nicht mehr erforderlich ist zu wissen, wie die Datenquelle ihre Daten kommuniziert oder organisiert. OPC eliminiert die Notwendigkeit spezifischer Treiber für jede neue Anwendung und Datenquelle. Spezifische Treiber: Jede durchgängige Verbindung erforderte einen spezifischen Treiber, um die Kommunikation zwischen speziellen Endpunkten zu erleichtern. Wenn zum Beispiel ein HMI mit einer SPS kommunizieren musste, brauchte er einen speziellen HMI-Treiber, der für das spezielle Protokoll, das die SPS verwendete, geschrieben wurde. Wenn diese SPS-Daten archiviert werden sollten, musste das Prozessdatenarchiv seinen eigenen Treiber haben, weil der spezifische Treiber für den HMI nur für die Kommunikation mit dem HMI verwendet werden konnte, nicht aber für das Prozessdatenarchiv. Wenn kein spezifischer Treiber für die jeweiligen Endpunkte verfügbar war, war die Herstellung der Datenkommunikation schwierig und teuer. OPC eliminiert die Notwendigkeit spezieller Treiber für jede neue Anwendung und Datenquelle. In Abbildung 1 sieht man wie ein einziger Standard-SPS-Treiber über einen OPC- Konnektor vom HMI und dem Prozessdatenarchiv gemeinsam genutzt wird, was darüber hinaus den Vorteil hat, dass der OPC-Anschluss nur eine Verbindung zur SPS benötigte wodurch sich die Auslastung des Controllers reduziert. Komplexität der Integration: Die Verwendung spezifischer Treiber zwischen allen Endpunkten hatte zur Folge, dass selbst bei einer geringen Anzahl von Geräten und Anwendungen schnell viele Treiber zum Einsatz kamen. Wenn dasselbe HMI auf verschiedenen Computern lief, die alle mit demselben Gerät kommunizierten, musste derselbe Treiber auf jedem einzelnen Computer installiert und konfiguriert werden. Wenn die HMIs mit weiteren Geräten kommunizierten, benötigte jedes HMI sein eigenes Paket spezifischer Treiber für jedes dieser Geräte. So wurde die Versionspflege zum Alptraum.

4 Der Datenverkehr und damit die Gerätelast werden durch die Verwendung von OPC-Verbindungen erheblich reduziert, weil alle Clients eine einzige Verbindung mit der Datenquelle nutzen. Durch die Verwendung von OPC wird die Integration bedeutend einfacher, denn sobald eine OPC-Verbindung für eine bestimmte Datenquelle konfiguriert ist, können alle OPCfähigen Anwendungen Daten mit dieser Datenquelle austauschen, ohne dass man sich um weitere spezifische Treiber kümmern muss. Geräte - und Controller-Last: Jeder Treiber stellt seine eigene Verbindung mit dem Gerät oder Controller her, mit dem er kommunizieren soll. Bei der großen Anzahl gerätespezifischer Treiber, die in einer typischen Installation verwendet wurden, wurde der Controller von den Anwendungen, mit denen er kommunizieren musste, häufig mit vielen Anfragen nach derselben Information bombardiert. Darüber hinaus konnten viele Geräte nur eine begrenzte Anzahl gleichzeitiger Verbindungen annehmen. Wenn die Anzahl von Treibern, die versuchten, eine Verbindung mit einem Gerät herzustellen, die Anzahl dessen möglicher Verbindungen überstieg, waren weitere Behelfsmaßnahmen erforderlich. Der Datenverkehr, also die Gerätelast, wird durch die Verwendung von OPC-Verbindungen erheblich reduziert, weil ein einzelner gerätespezifischer OPC-Anschluss nur eine einzige Verbindung zur Datenquelle benötigt und dabei gleichzeitig mit vielen Anwendungen kommuniziert. Überalterung bestehender Infrastruktur: Wenn Anbieter neue Produkte einführen, hören sie eines Tages auf, ältere Versionen zu unterstützen. Wenn eine neue Version eines HMI herauskommt, benötigt er möglicherweise sein eigenes Paket an Gerätetreibern, das unter Umständen Verbindungen mit einem Gerät nicht mehr unterstützt, die von der früheren Version des HMI noch unterstützt wurden. OPC verlängert die Nutzungsdauer von Altsystemen So ermöglicht OPC es selbst den neuesten Anwendungen, mit den ältesten Systemen zu kommunizieren. OPC verlängert die Nutzungsdauer von Altsystemen, denn sobald eine OPC-Verbindung für ein Altsystem konfiguriert ist, ermöglicht sie jeder OPC-fähigen Anwendung (und die meisten sind es), mit dem Altsystem zu kommunizieren, unabhängig davon, ob die Anwendung nativ die Kommunikation mit dem Altsystem unterstützt oder nicht. So ermöglicht OPC es selbst den neuesten Anwendungen, mit den ältesten Systemen zu kommunizieren. Unternehmensweite Datenkonnektivität: Mit dem steigenden Bedarf an Automatisierungsdaten im gesamten Unternehmen sind Probleme mit der Datenkonnektivität verbunden, weil Anwendungen auf Unternehmensseite nicht dafür ausgelegt wurden, mit Geräten und Controllern zu kommunizieren. Dies kann möglicherweise eine zusätzliche Last für die Automatisierungsinfrastruktur bedeuten und verschiedene Probleme bezüglich der Automatisierungssicherheit hervorrufen. OPC ermöglicht einen echten unternehmensweiten Austausch von Automatisierungsdaten, indem es bewährten Anwendungen erlaubt, Daten mit Automatisierungsdatenquellen auszutauschen, ohne dass gerätespezifische Treiber installiert werden müssen man braucht dafür lediglich eine OPC-Verbindung Gibt es Beispiele für aktive Installationen in der Praxis? Ja. Um praktische Beispiele dafür zu sehen, wie OPC eingesetzt wurde, um verschiedene Konnektivitätsprobleme mit Daten von Drittanbietern zu lösen, sehen Sie sich bitte diese OPC-Fallstudien an (

5 3. Einführung in OPC 3.1. Was ist OPC? Anwendung OPC DATENEMPFÄNGER ABSTRAKTION OPC ist die weltweit am stärksten verbreitete standardbasierte Datenkonnektivitätsmethode. Sie dient dazu, eine der größten Herausforderungen in der Automatisierungsbranche zu lösen: Wie kann man die Kommunikation zwischen Geräten, Controllern und/oder Anwendungen herstellen, ohne sich in den üblichen treiberbedingten Konnektivitätsproblemen zu verfangen? Geräte Controller DATENQUELLE 3.2. Warum OPC dort Erfolg hat, wo gerätespezifische Treiber versagen Abbildung 2: OPC dient als abstrakte Schicht zwischen Datenquellen und Datenempfänger und ermöglicht so die Kommunikation, ohne dass die eine Seite etwas über das native Protokoll der anderen wissen muss. Der Schlüssel für den Erfolg von OPC bei der Herstellung wirklich anbieterunabhängiger Verbindungen liegt darin, dass OPC die Implementierungseigenschaften von Datenquelle (z. B. SPS) und Datenempfänger (z. B. HMI) abstrahiert, sodass Daten zwischen ihnen ausgetauscht werden können, ohne dass sie etwas über das native Verbindungsprotokoll und die interne Datenorganisation des jeweils anderen wissen müssen. Dies steht im klaren Gegensatz zu einem Ansatz mit gerätespezifischen Treibern und dem Schreiben von Anwendungen, die per Definition sowohl mit der Datenquelle als auch mit dem Datenempfänger nativ kommunizieren müssen Wie die OPC-Kommunikation funktioniert (in konzeptueller Hinsicht) Man kann sich OPC als eine Art abstrakte Schicht vorstellen, die zwischen der Datenquelle und dem Datenempfänger liegt, sodass diese Daten austauschen können, ohne irgendetwas voneinander zu wissen Wie OPC funktioniert (in funktionaler Hinsicht) OPC Client- / Server-Architektur Anwendung DATENEMPFÄNGER OPC Client OPC Server Anwendungsprogrammierschnittstelle (Application Programming Interface, API) OPC ABSTRAKTION Modbus Geräte DATENQUELLE Abbildung 3: OPC-Client/Server-Architektur bei näherer Betrachtung der OPC-Abstraktionsschicht werden zwei Komponenten deutlich: ein OPC- Client und ein OPC-Server. OPC-Spezifikationen legen den Datenaustausch zwischen diesen beiden Komponenten fest. Die OPC- Geräteabstraktion wird erzielt, indem zwei spezielle OPC-Komponenten verwendet werden, der OPC-Client und der OPC-Server. Beide werden im folgenden Abschnitt beschrieben. Es ist wichtig anzumerken, dass die Tatsache, dass Datenquelle und Datenempfänger über OPC miteinander kommunizieren können, noch lange nicht bedeutet, dass deren jeweilige Protokolle nicht länger nötig sind oder durch OPC ersetzt werden. Im Gegenteil diese nativen Protokolle und/oder Schnittstellen sind immer noch vorhanden, kommunizieren aber lediglich mit einer der beiden OPC-Komponenten. Dafür tauschen die OPC-Komponenten Informationen miteinander aus, und der Kreis schließt sich. Daten können von der Anwendung zum Gerät übertragen werden, ohne dass Anwendung und Gerät direkt miteinander kommunizieren müssen Vorteile bei der Verwendung von OPC-Konnektivität Eine OPC-fähige Anwendung kann frei mit jeder OPC-fähigen Datenquelle kommunizieren, die für sie im Netzwerk sichtbar ist, ohne dass sie irgendwelche Treibersoftware benötigt, die für die Datenquelle spezifisch ist: 1. OPC-fähige Anwendungen können mit so vielen OPC-fähigen Datenquellen wie nötig kommunizieren. Es gibt keine in OPC enthaltene Begrenzung für die Anzahl hergestellter Verbindungen. 2. OPC ist heute so verbreitet, dass für fast jedes moderne und ältere Gerät auf dem Markt ein OPC-Anschluss verfügbar ist. Der Einstieg in die OPC-Nutzung ist ganz einfach.

6 OPC löst die Herausforderungen, die mit der Arbeit mit verschiedenen OPC-fähige Datenquellen können ausgetauscht, ausgewechselt oder aufgerüstet werden, ohne dass die von der Anwendung (Datenempfänger), die mit der Datenquelle über OPC kommuniziert, genutzten Treiber aktualisiert werden müssen. Nur der OPC-Server für die jeweilige Datenquelle muss auf dem aktuellen Stand gehalten werden. Die Anwender können die Geräte, Controller und Anwendungen frei wählen, die am besten für ihre Projekte geeignet sind, ohne sich fragen zu müssen, von welchem Anbieter sie kommen und ob sie auch miteinander kommunizieren werden so wird Vernetzung zur Realität. Datenkategorien einhergehen, indem unabhängig spezifiziert wird, wie jede einzelne Kategorie übertragen wird Welche Art von Daten unterstützt OPC Die geläufigsten Arten von Automatisierungsdaten, die zwischen Geräten, Controllern und Anwendungen übertragen werden, verteilen sich auf drei große Kategorien: Echtzeit-Daten Verlaufsdaten Alarm- und Ereignisdaten Jede der oben genannten Kategorien unterstützt auch einen großen Bereich von Werttypen. Einige geläufige Beispiele für diese Datentypen sind Integer-, Fließkomma-, String-, Datumsdaten und verschiedene Array-Typen, um nur einige zu nennen. OPC löst die Herausforderungen, die mit der Arbeit mit diesen verschiedenen Datenkategorien einhergehen, indem unabhängig spezifiziert wird, wie jede einzelne Kategorie über die OPC-Clientund-OPC-Server-Architektur übertragen wird. Die drei OPC-Spezifikationen, die den drei Datenkategorien entsprechen, sind: 1. OPC Data Access (OPC DA) Spezifikation für die Übertragung von Echtzeitdaten 2. OPC Historical Data Access (OPC HDA) Spezifikation für die Übertragung von Verlaufsdaten 3. OPC Alarms & Events (OPC A&E) Spezifikation für die Übertragung von Alarm- Informationen 3.7. Unterstützen alle OPC-Verbindungen alle OPC-Spezifikationen? Man sollte sich vorsichtshalber erkundigen, welche OPC-Spezifikationen eine OPC-Verbindung unterstützt, bevor man sie für die Nutzung in einem Projekt auswählt. Nein, OPC-Verbindungen müssen nicht alle OPC-Spezifikationen unterstützen. Historisch sind OPC-Server am häufigsten, die Echtzeitdaten unterstützten, gefolgt von OPC-HDA- Implementierungen. Man sollte sich vorsichtshalber erkundigen, welche OPC-Spezifikationen eine OPC-Verbindung unterstützt, bevor man sie für die Nutzung in einem Projekt auswählt Kommt es darauf an, welche OPC-Spezifikation ein OPC-Client oder OPC-Server unterstützt? Ja, das ist entscheidend. Zwar nutzen alle drei OPC-Spezifikationen (OPC DA, OPC HDA, OPC A&E) die gleiche zugrunde liegende OPC-Client/Server-Architektur, um die verschiedenen Datenkategorien zu übertragen, dennoch müssen der OPC-Client und der OPC- Server dieselbe OPC-Spezifikation unterstützen, um die Übergabe der Daten vom einen zum anderen korrekt zu koordinieren und um korrekt mit dem Datenempfänger bzw. der Datenquelle zusammenzuarbeiten.

7 4. OPC-Server 4.1. Was ist ein OPC-Server? Ein OPC-Server ist eine Software-Anwendung, ein standardisierter Treiber, der speziell geschrieben wurde, um eine oder mehrere OPC-Spezifikationen umzusetzen. Das Wort Server in OPC-Server bezieht sich nicht auf den verwendeten Computertyp, sondern reflektiert seine Beziehung zu seinem OPC-Gegenstück, dem OPC-Client Was leisten OPC-Server? OPC-Server sind Konnektoren, die man sich als Übersetzer zwischen dem OPC-Bereich und dem nativen Kommunikationsprotokoll oder der Kommunikationsschnittstelle der Datenquelle vorstellen kann. Da OPC bidirektional ist, können OPC-Server sowohl von einer Datenquelle lesen als auch in sie schreiben. Die OPC-Client/OPC-Server-Beziehung ist eine Master/Slave-Beziehung, und das bedeutet, dass ein OPC-Server nur dann Daten an eine/von einer Datenquelle überträgt, wenn ihm ein OPC-Client dies befiehlt. OPC-Server können praktisch mit jeder Datenquelle kommunizieren Mit welchen Arten von Datenquellen (Geräten) können OPC-Server kommunizieren? OPC-Server können praktisch mit jeder Datenquelle kommunizieren, deren Ausgabe über elektronische Mittel gelesen oder geschrieben werden kann. Eine kurze Liste möglicher Datenquellen umfasst zum Beispiel: Geräte, SPS/PLC, PLS/DCS, RTUs, elektronische Waagen, Datenbanken, Prozessdatenarchive, Webseiten und automatisch aktualisierende CSV-Dateien. Für die Kommunikation mit einem dieser Geräte muss lediglich ein OPC- Server verwendet werden, der das entsprechende native Protokoll bzw. die entsprechende native Schnittstelle verwendet. Sobald ein derartiger OPC-Server konfiguriert ist, kann jede OPC-fähige Anwendung (bei entsprechender Berechtigung) die Kommunikation mit der Datenquelle aufnehmen, ohne sich darum zu kümmern, wie die Datenquelle nativ kommuniziert Wo finde ich einen OPC-Server für Gerät X? Es gibt zwar viele Anbieter, die OPC-Server mit ihren Geräten, Controllern und Anwendungen ausliefern, es gibt aber auch viele, die das nicht tun. MatrikonOPC ist der weltweit größte Anbieter von hochwertigen OPC-Verbindungen für Hunderte von Geräten. Ein guter Ausgangspunkt ist die MatrikonOPC-Server-Website oder ein Anruf direkt bei MatrikonOPC Wie funktionieren OPC-Server? Anwender müssen zwar nichts darüber wissen, wie OPC-Server im Inneren funktionieren, um sie nutzen zu können, doch hilft ein konzeptionelles Verständnis der Abläufe, um zu begreifen, warum Qualität und Leistungs-fähigkeit der OPC-Server von verschiedenen Anbietern stark schwanken.

8 Konzeptionelle Anatomie eines OPC-Servers OPC-Kommunikationsmodul Übersetzungs-/Mapping-Modul Natives Kommunikationsmodul Protokoll API Abbildung 4: Konzeptionelle Anatomie eines OPC-Servers konzeptionell kann ein OPC-Server in drei Module gegliedert werden: das OPC-Kommunikationsmodul, das Übersetzungs-/Mapping-Modul und das native Kommunikationsmodul. Ein konzeptioneller Blick auf die innere Funktionsweise eines OPC-Servers zeigt Folgendes: OPC-Kommunikationsmodul: Dieser Teil des OPC-Servers ist verantwortlich für die korrekte Kommunikation mit einem bestimmten OPC-Client. Gut geschriebene OPC-Server müssen die OPC-Spezifikation(en), die sie implementieren, voll-ständig einhalten, um sicherzustellen, dass sie korrekt mit den OPC-Clients kommunizieren. Natives OPC-Kommunikationsmodul: Der OPC-Server sollte für die Kommunikation mit der Datenquelle die effizienteste Methode verwenden. In manchen Fällen heißt das, sich über das native Protokoll der Datenquelle direkt mit ihr zu verbinden, während es in anderen Fällen bedeutet, mit der Datenquelle über deren spezifischen Treiber über eine Anwendungsprogrammierschnittstelle (Application Programming Interface, API) zu kommunizieren. Normalerweise nutzt der OPC-Server die Kommunikationsmöglichkeiten des Gerätes umso besser, je mehr Erfahrung der Anbieter des OPC-Servers mit dem Gerät hat. Übersetzungs-/Mapping-Modul: Hier vollzieht sich der ganze Zauber in einem OPC-Server. Dieses Modul hat die Aufgabe, die vom OPC-Client eingehenden OPC-Anfragen korrekt zu interpretieren und sie in die richtigen nativen Anfragen umzusetzen, die dann an die Datenquelle geschickt werden, und umgekehrt. Wenn dies effizient geschieht, kann der OPC-Anbieter die Last der Datenquelle minimal halten und dabei den Datendurchsatz maximieren Kann ein OPC-Server eines Anbieters mit OPC-Clients anderer Anbieter kommunizieren? Gut geschriebene OPC- Server müssen die OPC- Spezifikation(en), die sie implementieren, vollständig einhalten. Ja, wenn sowohl der OPC-Client als auch der OPC-Server mit denselben OPC-Spezifikationen konform sind, sollten sie unabhängig davon, von welchem Anbieter die jeweilige OPC-Komponente stammt, miteinander kommunizieren können Können OPC-Server Informationen mit anderen OPC-Servern austauschen? OPC-Server kommunizieren nicht direkt miteinander, sie sind nur dafür ausgelegt, mit OPC-Clients zu kommunizieren. Jedoch gibt es von Matrikon OPC-Dienstprogramme wie MatrikonOPC Data Manager ( ), die speziell dafür entwickelt wurden, diese OPC-Server-zu- OPC-Server-Kommunikation zu erleichtern. OPC-Clients 5.1. Was ist ein OPC-Client? Ein OPC-Client ist eine Software, die dafür geschrieben wurde, mit OPC-Konnektoren zu kommunizieren. Er verwendet die Art des Datenaustausches, die durch eine bestimmte Spezifikation der OPC-Foundation definiert wurde.

9 5.2. Was leistet ein OPC-Client? Konzeptionelle Anatomie eines OPC-Clients Protokoll API Anwendungskommunikationsmodul Übersetzungs-/Mapping-Modul OPC-Kommunikationsmodul Abbildung 5: Konzeptionelle Anatomie eines OPC-Clients da der OPC- Client ein Spiegelbild des OPC-Servers ist, kann man ihn sich ebenfalls als aus drei Modulen bestehend vorstellen: aus der nativen Anwendungskommunikation, dem Übersetzungs-/Mapping-Modul und dem Kommunikationsmodul. In konzeptueller Hinsicht: OPC-Clients repräsentieren einen Datenempfänger. Sie initiieren und steuern die Kommunikation mit OPC-Servern je nachdem, was die Anwendung, in die sie eingebettet sind, von ihnen verlangt. OPC-Clients übersetzen die Kommunikationsanfragen einer gegebenen Anwendung in eine OPC-äquivalente Anfrage und schicken sie an den entsprechenden OPC-Server zur Verarbeitung. Wenn im Gegenzug OPC-Daten vom OPC-Server zurückkommen, übersetzt der OPC-Client diese in das native Format der Anwendung zurück, sodass die Anwendung korrekt mit den Daten arbeiten kann. In technischer Hinsicht: OPC-Clients sind Software-Module, die von einer Anwendung verwendet werden, um mit jedem konformen OPC-Server, der für sie im Netzwerk sichtbar ist, kommunizieren zu können. Normalerweise sind OPC-Clients in Anwendungen wie HMIs, Paketen zur Trendberechnung, Prozessdatenarchiven und Berichteditoren eingebettet, um sie inhärent OPC-fähig zu machen. Für gewöhnlich bezeichnet man die Anwendung mit dem eingebetteten OPC-Client als OPC-Client, obwohl nur die OPC-Implementierung der wirkliche OPC-Client ist Können OPC-Clients gleichzeitig mit mehreren Geräten (OPC-Servern) kommunizieren? Die Antwort darauf besteht aus zwei Teilen: 1. Semantik: Man muss sich in Erinnerung rufen, dass OPC-Clients auslegungsgemäß nur mit OPC-Servern kommunizieren können, nicht mit Endgeräten oder anderen Datenquellen. Dies ist erforderlich, weil OPC-Clients protokollunabhängig bleiben müssen sonst würde sich die Gerätetreiber-Falle der Vergangenheit wieder auftun. 2. Ja, OPC-Clients können mit mehreren OPC-Servern gleichzeitig kommunizieren. Effektiv bedeutet dies, dass ein OPC-Client Daten von mehreren Datenquellen über die jeweiligen OPC-Server lesen und in sie schreiben kann Wie funktioniert ein OPC-Client? OPC-Clients können mit mehreren OPC-Servern gleichzeitig kommunizieren. Wie der OPC-Server kann auch der OPC-Client konzeptuell in drei Module gegliedert werden: das Anwendungskommunikationsmodul, das Übersetzungs-/Mapping-Modul und das OPC-Kommunikationsmodul. Deren Funktionen werden im Folgenden beschrieben. OPC -Kommunikationsmodul: Der OPC-Client ist zwar nicht so tief involviert wie der OPC-Server (der OPC-Server-Anteil ist komplizierter), es ist aber dennoch entscheidend für den OPC-Client, sich korrekt zu verhalten, wenn er eine Verbindung zu einem OPC-Server herstellt, Daten mit ihm austauscht und die Verbindung wieder trennt, ohne den OPC-Server instabil werden zu lassen. Anwendungskommunikationsmodul: Der OPC-Client wird normalerweise so geschrieben, dass er innerhalb einer speziellen Anwendung funktioniert; er nutzt also wenige Aufrufe an die Anwendungsprogrammierschnittstelle (API), damit Daten von der Anwendung über den OPC-Client an den OPC-Server/die Datenquelle übergeben werden können. Ein allgemeiner OPC-Client kann auch über ein Protokoll mit einer Anwendung kommunizieren statt über eine API, wenn die Anwendung ein solches Protokoll unterstützt. (Ein Beispiel dafür ist der MatrikonOPC-Client

10 for ODBC, der SQL-Anweisungen über ODBC nutzt, um mit einer relationalen Datenbankanwendung zu kommunizieren.) es besteht keine theoretische Beschränkung, zu wie vielen OPC-Servern ein OPC-Client eine Verbindung herstellen kann. Übersetzungs -/Mapping-Modul: Eine Hauptfunktion des OPC-Clients ist die bidirektionale Übersetzung von Informationen, wenn die Anwendung, die der OPC-Client repräsentiert, fordert, dass Daten vom Endgerät oder von der Datenquelle gelesen bzw. in das Gerät oder die Datenquelle geschrieben werden Zu wie vielen OPC-Servern kann ein OPC-Client Verbindungen herstellen? Die kurze Antwort lautet mit so vielen wie nötig. Innerhalb des OPC-Systems besteht theoretisch keine Beschränkung, zu wie vielen OPC-Servern ein OPC-Client eine Verbindung herstellen kann Können OPC-Clients direkt mit anderen OPC-Clients kommunizieren? Nein. OPC-Client-zu-OPC-Client-Verbindungen sind in OPC nicht definiert. Unterstützt wird nur die OPC-Client/OPC-Server-Architektur. Wenn eine Anwendung OPC-Daten an andere Clients liefern soll, muss sie über einen eigenen OPC-Server verfügen. Dieser OPC- Server wird es dann den OPC-Clients anderer Anwendungen ermöglichen, diese Anwendung als OPC-Datenquelle zu nutzen Wo wird der OPC-Client installiert? OPCs Plug-&-Play- Ansatz in Bezug auf Datenkonnektivität führte dazu, dass seine Popularität schnell stieg. OPC-Clients werden normalerweise in die Anwendungen eingebaut, die sie verwenden, wie zum Beispiel HMIs oder Prozessdatenarchive. Wenn die betreffende Anwendung aus irgendeinem Grund keinen eingebauten OPC-Client hat, ist beim Anbieter der Anwendung möglicherweise ein entsprechender OPC-Client erhältlich oder aber bei einem Fremd-OPC-Anbieter wie MatrikonOPC. Ein anwendungsexterner OPC-Client würde mit der Anwendung normalerweise über eines der nativen Protokolle dieser Anwendung kommunizieren. In diesem Fall müsste der OPC-Client nicht einmal auf demselben Computer wie die Anwendung liegen. 6. Fazit Copyright Matrikon Inc 2010 Dieses Whitepaper hat erklärt, wie OPC die wachsende Herausforderung der modernen Industrie beim Datenzugriff- und -austausch zwischen Geräten, Controllern und Anwendungen löst, unabhängig davon, wie deren native Verbindungen aussehen oder von welchem Anbieter sie stammen. In einer allgemeinen Beschreibung wurde erläutert, was OPC ist; dann wurde erklärt, was OPC-Clients und OPC-Server (die OPC-Bausteine) sind und welche Rolle sie bei der OPC-Kommunikation spielen. Man benötigt zwar keine tiefgründigen Kenntnisse der Funktionsweise von OPC, um es nutzen zu können, aber eine gewisse Vertrautheit mit seinen wichtigsten Konzepten ist dennoch von Vorteil. Der Plug-&- Play-Ansatz von OPC in Bezug auf Datenkonnektivität führte dazu, dass seine Popularität schnell stieg, sodass OPC heute zur weltweit beliebtesten Datenkonnektivitätstechnologie aufgestiegen ist. Aufgrund seiner Flexibilität wird OPC auf allen Unternehmensebenen und über alle Branchen hinweg genutzt Tel.: +49 (221) Fax: +49 (221) Web: OPC Americas Asia-Pacific Europe Middle East Africa