Vertikale Integration

OPC im Ethernet

Autor: Rainer Beudert, erschienen in der Elektronik Praxis 4/2004, S. 38–39, PDF

Sie stehen als Elektrokonstruktionsleiter, verantwortlicher Projektingenieur oder als Planer zukünftiger Produktionslinien vor der Entscheidung OPC als Standardschnittstelle einzuführen. Sie stellen sich aber folgende Fragen: Warum soll ich mich überhaupt für OPC entscheiden? Wie schnell ist OPC eigentlich? Können zwei OPC-Server direkt miteinander kommunizieren? Welche Produkte stehen mir für das geplante OPC-Projekt zur Verfügung? Kann ich OPC-Daten auch über das Internet austauschen? Was muss ich auf Hardwareseite tun, um per OPC kommunizieren zu können? Anhand von Anwendung und Produktbeispielen werden praktische Lösungen rund um OPC und Ethernet vorgestellt.

Warum soll ich mich für OPC entscheiden?

Die Ablösung proprietärer Lösungen durch offene, herstellerunabhängige Standards ist ein in allen Bereichen der Industrie zu beobachtender Trend, bietet er doch dem Kunden die Möglichkeit einer Systemzusammenstellung nach seinem eigenen Leistungsprofil.

Für die Anbindung von Visualisierungssystemen und ähnlichen, macht OPC schon seit 1998 verstärkt von sich reden. Anfänglich belächelt („Wer setzt schon Microsoft für seine Automatisierungsaufgaben ein.“), hat sich OLE FOR PROCESS CONTROL bei vielen Anlagenbauern, aber auch Maschinenbauern zu einer festen Größe für die preiswerte, flexible und skalierbare Verbindung von Automatisierungshardware an Standardsoftwarekomponenten entwickelt.
Trotzdem stellt man sich vor der Realisierung eines OPC-Projektes zur Anbindung von Visualisierungen, Datenbanken und ähnlichem die Frage: Wie viele Datenpunkte kann ich maximal über OPC aus einer Steuerung erfassen? Welche Aktualisierungsraten kann ich mit OPC erreichen? Welchen Einfluss hat meine gewählte Hardware, meine Busanschaltung und welchen Einfluss hat das Systemdesign des PCs auf dem der OPC-Server und der OPC-Client installiert sind?

Über die Performance der OPC-Schnittstelle unter Laborbedingungen wurde schon mehrfach berichtet unter anderem von Lange/Iwanitz in ihrem Buch „ OLE for Process Control. Grundlagen, Implementierung und Anwendung“ (Hüthig-Verlag 2002) und von Hadlich/Szczepandski in ihrem Beitrag „Die Performance von OPC beim zyklischen Datentransport“ (Ifak-Systems 1999). Eines der wesentlichen Ergebnisse aus diesen Messungen ist die starke Abhängigkeit von der Prozessorleistung der CPU des OPC-Server-Rechners sowie die Belastung dieses Rechners durch zusätzliche Prozesse oder Applikationen.

Doch welche Einflüsse haben die anderen Komponenten in einer solchen Datenkette wie im Bild am Beispiel des INAT OPC-Server TCPIPH1 im S5 / S7 - Umfeld gezeigt. Der INAT OPC-Server TCPIPH1 wurde für die OPC-Anbindung von S5/S7-Steuerungen via Ethernet, aber auch für die Anbindung von Wago-/Beckhoff- und Phoenix-Contact-Klemmen und MODICON-Steuerungen via Modbus on TCP entwickelt. Seit kurzem gehört auch die Anbindung von Allen Bradley-Steuerungen via EtherNet/IP zum Funktionsumfang.

In einer solchen Kommunikationskette sollten neben der OPC-Schnittstelle auch das Netzwerkdesign, die Leistungsfähigkeit der CPU der Steuerung und last but not least die Performance der eingesetzten Ethernet-Anschaltung (INAT S7-TCP/IP oder CP-443-1 von Siemens, Echolink oder Wago) berücksichtigt werden.

Die CPU/CP-Schnittstelle

Pollt man mit dem INAT-OPC-Server und einem beliebigen Client die Daten aus nur einer Steuerung, so sucht man die limitieruden Faktoren aus Seiten der Steuerung.

Tests zeigten, dass unabhängig von der eingesetzten CP der Datenfluss mit steigender Anzahlt an Punkten zunehmend von der CPU/CP-Schnittstelle der Daten beeinflusst wird. Hier spielen wiederum die Blockungsgrenzen, das CP-spezifische Zugriffsverfahren und die Datenstruktur in der SPS die entscheidende Rolle.

Aus Performance-Gründen warten die Ethernet_CPs nicht, bis ein vollständiges Ethernet-Frame zum Datentransfer ansteht, sondern senden mit Erreichen der Blockungsgrenze die Daten auf das Ethernet.

Die Netzwerkanschaltung am Server

Kritischer ist da schon die Anbindung des OPC-Server-Rechners an das Netzwerk zu betrachten. Sollen besonders viele Kommunikationsteilnehmer mit diesem Server verbunden werden, ist der Einsatz von leistungsfähigen Fast Ethernet oder Gigabit-Netzwerk-Karten unabdingbar.

In einer singulären Kommunikationskette mit Rockwell-TestOPC-Client, INAT-OPC-Server und einer S7-416 mit Ethernt-CP (S7-TCP/IP, CP-443-1), werden die Daten bis zur jeweiligen Blockungsgrenze im einstelligen Millisekunden-Bereich übertragen. Der Engpass wird bei einer solchen Anordnung meist beim CP oder der CPU zu suchen sein.
Interessant wird es, wenn der INAT-OPC-Server mehrere Verbindungen zu diversen Steuerungen aufbaut. 20000 Items im Poll-Modus (as fast as possible) aus 5 bis 15 Steuerungen bei einer Refresh-Rate von etwa zwei Sekunden sind dabei je nach Rahmenbedingung nicht ungewöhnlich.

Im ereignisgesteuerten Send/Receive-Direkt-Modus können aufgrund der geringeren Netto-Übertragunsmenge noch weit mehr Datenpunkte überwacht werden.

OPC-Daten auch über’s Internet tauschen?

Will man OPC-Server und OPC-Client auf verteilten Rechnersystemen einsetzen, werden die Daten über die DCOM-Schnittstelle ausgetauscht. Was in einem lokalen Netz sehr gut funktioniert, bereitet beim Übergang ins Internet und beim Passieren von Firewalls massive Probleme.

Mit OPC-Tube bietet die INAT eine Lösung an, mit der die DCOM-Schnittstelle als einfach COM-Schnittstelle angesprochen wird. Damit ist die Kommunikation über Netzwerkgrenzen hinweg möglich.

Mit OPC-Tube wird auch DCOM eine einfach TCP/IP-Socket-Kommunikation, die Netzwerkgrenzen und Firewalls sehr einfach überwindet. OPC-Tube wird es als Client und als Server-Variante geben. Der Client, der nach einem Remote-Server browsed wird diesen OPC-Server unter seinen lokalen Servereinträgen finden.

Können zwei Server direkt Daten tauschen?

Die meisten Visualisierungssysteme bieten heute OPC-Schnittstellen, die die Daten eines beliebigen OPC-Servers verarbeiten. Deshalb wird OPC auch oftmals als Sofwarebus dargestellt. Das heißt, es verbinden sich verschiedene Kommunikationspartner auf einem gemeinsamen Medium um Daten auszutauschen. Dieses Modell greift nicht für die Kommunikation von OPC-Servern untereinander, da dies im derzeitig verbreiteten OPC-DA-Standard nicht vorgesehen ist. In der Praxis zeigt sich jedoch oft die Notwendigkeit, Daten zwischen Automatisierungs-Komponenten auszutauschen.

Eine Lösung bietet der hier vorgestellte OPC Router, der als OPC-Client die beteiligten Komponenten einfach als Datenquelle und Datensenke definiert. Als Standard-OPC-Client sorgt der OPC-Router dafür, dass Daten zwischen zwei Servern aber auch zwischen Servern und Datenbanken ohne aufwändige Programmierung ausgetauscht werden.

Fazit

Setzt man auf die Standards OPC und Ethernet, so wird der vertikale Datentransport von der Steuerung bis zur Applikation, sei es Visualisierung, Datenbank oder Archivierung, sehr einfach und transparent. Sogar die herstellerunabhängige Kommunikation zwischen verschiedenen Hardwarekomponenten gelingt. Aufwändige Programmierung und teures Engineering werden bei der Realisierung von Automatisierungsaufgaben durch preiswerte und leistungsfähige Standardlösungen ersetzt.

Dr. Rainer Beudert ist Schulungsleiter bei der INAT GmbH, Nürnberg