Introduction to OPC

Überblick

OPC is a standard interface to communicate between numerous data sources, including devices on a factory floor, laboratory equipment, test system fixtures, and databases. To alleviate duplication efforts in developing device-specific protocols, eliminate inconsistencies between devices, provide support for hardware feature changes, and avoid access conflicts in industrial control systems, the OPC Foundation defined a set of standard interfaces that allow any client to access any OPC-compatible device. Most suppliers of industrial data acquisition and control devices, such as Programmable Logic Controllers (PLCs) and Programmable Automation Controllers (PACs), are designed to work with the OPC Foundation standard.

Contents

COM/DCOM

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

OPC Implementation

OPC allows client and server applications to communicate with each other. OPC is designed to be an abstraction layer between industrial networks and proprietary PLC drivers. The OPC standard specifies the behavior that the interfaces are expected to provide to their clients; and the clients receive the data from the interfaces using standard function calls and methods. Consequently, as long as a computer analysis or data acquisition program contains an OPC client protocol, and an industrial device driver has an associated OPC interface, the program can communicate with the device. The specification also includes a protocol for working with data control systems and application databases, as well as online data access, alarm and event handling, and historical data access for all of these data sources.


The data access server has three divisions:

  • Server − Contains all of the group objects
  • Group − Maintains information about itself and contains and organizes the OPC items
  • Item − Contains a unique identifier held within the group. The identifier acts as a reference for the individual data source, as well as value, quality, and timestamp information. The value is the data from the source. The quality status gives information about the device. The timestamp is the time that the data was retrieved.

An OPC application accesses all items through the OPC group rather than through the item itself. The group also contains a specific update rate for itself, which tells the server at what rate to make data changes available to the OPC client. A deadband specific for each group tells the server to reject values if they have changed by less than a specified deadband percentage.

The OPC server also provides alarm and event handling to clients. Within a server, an alarm is an abnormal condition of special significance to the client − a condition associated with the state of the server, a group or an item within the server. For example, if a data source value that represents the real-world temperature of a mixer drops below a certain temperature, the OPC server will send an alarm to the application, so that the application will properly handle the low temperature. Events are detectable occurrences that are important to the server and client, such as system errors, system configuration changes, and operator actions.

OPC also incorporates historical data access standards, which are a way to access the data stored by historical engines, including raw data storage servers and complex data storage and analysis servers. This feature of OPC allows interoperability of proprietary database systems.

OPC Ideal for High Channel Count Applications

The OPC Foundation’s stated design, goals, and motivation for industry standardization of control systems have enabled the implementation of high-channel-count systems that are efficient and highly scalable.

Client software developers and users of these applications have greater flexibility in implementing a solution that is tailored to their needs because data is organized into groups and the naming, or tagging, of data points is determined by the client software. Grouping is beneficial in dealing with large sets of data sources because it provides greater organization of the data as well as easy reference to similar sets of data. In an OPC application, a tag gives a unique identifier to an I/O point. Based on the OPC specification, the client or server software is responsible for naming tags. The software can programmatically name tags or specify that the user name tags. This flexibility is a significant factor in the ability of client software to provide solutions that are tailored for high-channel-count applications.

Client software also specifies the rate at which the server supplies new data to the client. Because the server is responsible for data publication, the client software does not need to perform time-consuming data polling, which frees up more time for analysis and data logging. Moreover, the client software instead becomes a reactive object that waits for new data to arrive. Therefore, the client becomes event-driven and handles large sets of data much more efficiently.  

The client also specifies deadbands on the server, which allows the client to determine which data is important and then disregard data that is insignificant. Deadband percentages reject values that do not change more than a certain percentage from the previous value recorded. By establishing moderate deadband values, the client receives only information about channels which the client deems essential. This prevents the client from being flooded with superfluous information. In this way, the client can monitor a much greater number of channels.

Because OPC is now an industry standard, client software can connect to almost every vendor device available. Client software now is compatible with many types of devices, so the software can be designed with large numbers and varieties of devices in mind. These are a few of the many OPC characteristics that give development software a huge advantage when you use OPC connectivity to implement high-channel-count application software.

Using OPC in LabVIEW

LabVIEW allows developers to integrate with OPC systems. You can connect both OPC clients and servers to LabVIEW applications to share data. The primary component that allows LabVIEW to perform this action is the Shared Variable Engine (SVE). The SVE is installed as a service on the computer when LabVIEW is installed. Using a proprietary technology called the NI Publish-Subscribe Protocol (NI-PSP), the SVE manages shared variable updates. Once you deploy Shared Variables to the SVE, the SVE works as a separate process running on the computer. For example, regardless if LabVIEW or a VI runs, the SVE items will automatically be available after the computer restarts. Moreover, the SVE will continue to be accessible for updates at any time and continue to run until stopped. For more detailed information about network-published shared variables, refer to the NI Developer Zone article Buffered Network-Published Shared Variables: Components and Architecture.

Figure 1. The Shared Variable Engine Can Be Either an OPC Client or a Server

For OPC, the SVE acts as the middleman between NI-PSP data items and other applications. You can configure I/O servers to be OPC clients. This functionality is included in the LabVIEW Datalogging and Supervisory Control (DSC) Module. You can configure the SVE as an OPC server to publish NI-PSP data items to the network so other OPC clients can interact with them.

Using LabVIEW as an OPC Client

The DSC Module provides OPC Client I/O servers for communicating with any server implementing the OPC Foundation OPC server interface.  This allows LabVIEW to communicate with any PLC that is interacting with an OPC Server. An OPC Client I/O server will list all available OPC servers that are installed and running on a local or network computer.  Figure 2 shows the relationship of the components involved in communication between LabVIEW and a PLC.

Figure 2. LabVIEW and the SVE Can Communicate with PLCs through OPC

PLCs publish data to the network. An OPC Server program uses the PLC’s proprietary driver to create OPC tags for each physical I/O on the PLC. National Instruments provides an OPC Server solution with NI OPC Servers. NI OPC Servers contains a list of drivers for many of the industry’s PLCs. For a list of supported PLCs, refer to the NI Developer Zone article Supported Device & Driver Plug-in List for NI-OPC Server. The OPC Client I/O servers provided with the DSC Module can connect to each OPC tag using the OPC DA standard. You can configure the multiple OPC Client I/O servers in the SVE with different update rates, deadband percentages, and reconnect poll rates. The SVE provides a PSP URL for each OPC tag that other Shared Variables can bind to by enabling aliasing. Once you deploy the Shared Variables in the SVE and the Shared Variables receive values, LabVIEW can easily read and write to the Shared Variables using a VI.  

Using LabVIEW as an OPC Server

The SVE can act as an OPC server. However, the SVE as an OPC server should not be confused with NI OPC Servers, because the SVE does not contain essential proprietary PLC drivers. The SVE can take a network-published Shared Variable and create OPC tags that an OPC DA client can connect to. This allows LabVIEW VIs to easily communicate with other OPC client software.

Figure 3. The SVE as an OPC Server

A common application for using the SVE as an OPC Server involves employing National Instruments Data Acquisition (DAQ) devices and an NI-DAQmx driver to set up a DAQmx Virtual Channel. This DAQmx Virtual Channel can then be referenced by an NI-PSP URL. Therefore, the SVE can bind a network-published Shared Variable to the values being read by the DAQ device. The SVE then uses OPC DA standards to create OPC tags for the Shared Variable. In this way, an OPC client can read and write to the DAQ device. For a step-by-step process on publishing a DAQ device I/O to an OPC client, refer to the NI Developer Zone article Using the LabVIEW Network-Published Shared Variable and OPC with NI-DAQmx.