OPC-basierte Integration von Antrieben in Engineeringsysteme Antriebe beim Namen genannt - wirautomatisierer

OPC-basierte Integration von Antrieben in Engineeringsysteme

Antriebe beim Namen genannt

Anzeige
„Men gave name to all the animals“ hieß ein populäres Lied in den Siebzigern. Schon in der Bibel wurde durch die Vergabe von Namen zum Leben erweckt. Ähnliches haben sich die Initiatoren des Driveserver gedacht. Die Drivecom-Mitglieder wollen die Kommunikation zwischen Feldbus- und modernen Antriebssystemen durch eine Adressierung auf der Grundlage von Namen realisieren. Für den PC-Welt-verwöhnten Anwender wird der Schritt hin zu einem Software-Plug&Play vollzogen.

Dipl.-Ing. Thomas Hadlich ist Abteilungsleiter Automation bei der ifak system GmbH in Barleben

Die Drive-Hersteller können eigentlich stolz auf sich sein. Ihre modernen Antriebsregler übernehmen eigenständig umfangreiche technologische Regelungen und Aufgaben von Steuerungen. Mit standardisierten Feldbussystemen wie Profibus lassen sich diese modularen, dezentralen Maschinenkonzepte einfach umsetzen. Jedoch bei der Integration ihrer Antriebe in bestehende Systeme, die mit verschiedenen Kommunikationsmedien arbeiten, ist bisher bei der Festlegung von Antriebsparametern auf Seiten der Anwender erhebliche manuelle Eingabearbeit erforderlich, obwohl die Antriebshersteller eigene Parametrierwerkzeuge anbieten.
Denn die Darstellung eines Antriebs aus Sicht eines Anwenders unterscheidet sich fundamental von der Darstellung eines Antriebs aus Kommunikationssicht. Ein Anwender arbeitet mit den Parametern des Geräts, normalerweise bezeichnet durch Namen. Aus Kommunikationssicht werden Parameter durch Zahlenpaare (beispielsweise Index, Subindex, Slot, Index) bezeichnet. Viele Anwender akzeptieren und nutzen diese Darstellungsweise, jedoch mit der Einschränkung, dass die Kommunikationssicht in der Regel an das verwendete Kommunikationsprotokoll oder -profil gebunden ist. Das heißt, je nach Protokoll kommt es zu Varianz. Diese Situa-tion resultiert in einem erheblichen Engineeringaufwand. Ein schneller geräteorientierter Datenzugriff würde das Engineering vereinfachen und damit die Kosten mindern.
Ein bequemer Anschluss nach dem Plug&Play-Prinzip braucht aber nicht länger Wunschdenken zu bleiben – wenn es nach dem Willen der Antriebshersteller geht. Die Drivecom-Nutzergruppe, ein Zusammenschluss internationaler Antriebshersteller und Institute, hat nun ein Konzept entwickelt, um die Kommunikationsschnittstellen für den Zugriff auf Antriebe zu standardisieren. Es basiert auf dem Software-Schnittstellenstandard OPC (Object Linking and Embedding for Process Control) in der Version 2.0. Unter Mitwirkung der ifak system GmbH wird die Spezifikation für den Driveserver erarbeitet. Das innovative Konzept sieht mit einer Darstellung der Antriebsvariablen oder der firmenspezifischen Funktionen im Namensraum der OPC-Server eine deutliche Vereinheitlichung der Präsentation vor.
Einbindung in die OPC-Technologie
Die Verwendung der OPC-Schnittstelle in der Prozessautomation hat dazu geführt, dass die Anpassung an spezifische Geräte und Hardware nicht mehr in jeder Applikation realisiert werden muss, sondern von den Herstellern von Automatisierungsgeräten selbst durchgeführt werden kann. Da der Zugriff auf die Prozessdaten vereinheitlicht und die softwaretechnische Anbindung durch den Einsatz von OLE festgelegt wurde, entfallen Anpassungen an die herstellerspezifischen Schnittstellen. Dieses Vorgehen war bisher im Wesentlichen auf die Kommunikationsnetzwerke beschränkt.
Die Spezifikation des Driveserver nutzt diesen Ansatz, um den Engineeringprozess weiter zu vereinfachen, Konfigurationsarbeiten zu minimieren und Kosten zu reduzieren. Allen Anwendungsprogrammen sollen die Spezifikationen des Antriebs einheitlich zur Verfügung gestellt werden. Der Driveserver basiert auf der gereiften OPC-Technologie. Er bildet eine Schicht zwischen einem Anwendungsprogramm mit OPC-Client-Schnittstelle und den Kommunikationsmedien.
Kommunikationsstruktur
Um die Vielzahl der verfügbaren und zukünftigen Kommunikationsmedien für eine Kommmunikation zum Antrieb zu nutzen, basiert die Driveserver-Spezifikation auf einer deutlichen Trennung zwischen Kommunikationsfunktionalität und Driveserver-Funktionalität. Deswegen kommuniziert der Driveserver über ein OPC-Interface. Diese offene Architektur gewährleistet die gewünschte Flexibilität der Feldbussysteme und der verwendeten Antriebskomponenten – ein weiterer entscheidener Schritt hin zu offenen und durchgängigen Automatisierungslösungen.
Der Driveserver bildet die antriebsbezogenen Zugriffe der Applikation auf feldbusbezogene Zugriffe ab. Die OPC-Technologie definiert den gerätebezogenen Zugriff über Namen, das heißt, der Anwender muss nicht mehr berücksichtigen, wie Gerätedaten auf dem jeweiligen Kommunikationsmedium übertragen werden. Diese Namen können je nach Server-Implementierung vorkonfiguriert oder dynamisch angelegt werden.
Der Ansatz des Driveserver kapselt nun die Geräteeigenschaften in einem einbettbaren Objekt funktional. Alle Geräteeigenschaften, deren Repräsentation und deren Zugriff erfolgt über eine funktionale Schnittstelle. Dadurch bleibt das Know-how der Geräte, deren Beschreibungsform und Zugriffsmechanismen bestehen. Der Zugriff erfolgt mit Standardmitteln. Es werden keine Parameter und deren Inhalte, sondern deren Zugriff in einem Namensbildungsverfahren festgelegt. Dieses Vorgehen hat den wesentlichen Vorteil, dass die Gerätehersteller zunächst und auf Dauer ihre eigenen Implementierungen, die sich in den Geräten wieder finden, beibehalten können.
Inbetriebnahme
An der Schnittstelle zwischen Applikation, Driveserver und Bus-Server sind drei Phasen des Datentransfers oder der Inbetriebnahme zu betrachten:
Die Identifikation der Geräte:
Der Driveserver erfragt über das Browse-Interface des Bus-Server nach verfügbaren Geräten am Bus. Über einen herstellerspezifischen Identifikationsalgorithmus, der im Driveserver implementiert ist, werden die Gerätetypen bestimmt und im Browse-Interface des Driveserver zur Anzeige gebracht. Eine Applikation kann mit Hilfe dieser Informationen die Geräte auswählen.
Die Definition von Items als Zugriffsspezifikation (Konfiguration):
Nachdem die Applikation weiß, mit welchem Gerät sie zusammen arbeiten möchte, können im Driveserver eine oder mehrere Gruppen mit Items angelegt werden, die den Geräteparametern entsprechen. Der Driveserver kann durch die vorherige Identifikation der Geräte seinen eigenen Namensraum (anhand einer Gerätebeschreibung) aufbauen. Dies versetzt ihn in die Lage, eventuell nicht auflösbare Geräteparameteranfragen abzuweisen. Fehlerhafte Anfragen können so zuverlässig vermieden werden. Alle Gruppen und Items werden in den betreffenden Bus-Servern ebenfalls angelegt.
Die I/O-Operationen (Transfer):
Nach der Konfiguration des Server kann der eigentliche Datentransfer von der Applikation ausgelöst werden. Hierbei werden auf den Gruppen des Driveserver Lese- oder Schreibbefehle ausgeführt, wodurch alle in der Gruppe enthaltenen Items kommuniziert werden. Dies bedeutet, dass diese Befehle an die unterliegenden Bus-Server weitergeleitet werden und diese die Parameterwerte mit den Geräten austauschen.
Der Driveserver stellt im Sinne der OPC-Definition eine OPC-Server- und eine OPC-Client-Schnittstelle zur Verfügung. Er ist zunächst selbst Client eines Kommunikationsserver, des Bus-Server, da die Kommunikationsschnittstellen typischerweise zu einem Feldbus bestehen. Der Bus-Server kann jedoch grundsätzlich Server eines beliebigen Übertragungsmediums sein. Der Bus-Server übernimmt in der vorgestellten Architektur die Kommunikation mit den Geräten. Er ist in der Regel ein busspezifischer OPC-Server und muss nicht direkt oder ausschließlich auf einen Feldbus zugreifen. Beispielsweise ist ein OPC-Server denkbar, der auf TCP/IP aufsetzt und nur bestimmte Sockets des Betriebssystems nutzt oder der mit anderen (D)COM-Komponenten kommuniziert, die Geräte simulieren.
Die Antriebssoftware im Einsatz
Wenn der Driveserver auf einem Windows-NT-Rechner installiert ist, muss nur noch angegeben werden, mit welchem Feldbus er arbeiten soll. Der Driveserver erkennt jetzt automatisch, welche Antriebsgeräte vorhanden sind, konfiguriert sich und baut so seinen eigenen „Namensraum“ auf. Mit Hilfe der OPC-Browse-Funktion können alle Anwendungsprogramme die spezifischen Antriebsparameter finden und darauf zugreifen. Genau dafür sorgt die einheitliche Struktur im Namensraum.
Eine strukturierte Darstellung der vorhandenen Antriebe am Bus hilft dem Anwender bei der problemlosen Orientierung. Schwerpunkt ist dabei immer die gerätespezifische Sicht. Selten benutzte oder anwenderspezifische Parameter können der Konfiguration im laufenden Betrieb einfach hinzugefügt werden. Beim Wechseln des Fertigungs-produkts oder im Servicefall brauchen dem Driveserver nur die Dateinamen und die gewünschten Aktionen mitgeteilt werden.
Die Integration der Antriebe in die Engineeringsysteme soll sich nicht nur auf einen allgemein gültigen Satz von Konfigurations-, Service- und Diagnosefunktionen begrenzen. Vielmehr wird der Anspruch verfolgt, auch die individuellen Geräteeigenschaften und den Leistungsumfang verschiedener Typen (Gerätevarianz) zu unterstützen. Vom Antriebshersteller mitgelieferte Tools für Planung, Service und Diagnose sollten ebenso als gerätespezifische Softwarekomponenten im System Berücksichtigung finden. So bleiben dem Hersteller genügend Freiheiten, das Erscheinungsbild seiner Geräte in der Engineeringumgebung selbst zu beeinflussen.
Weitere Informationen eA 528
Anzeige

Video aktuell

VX25 - Michael Schell, Hauptabteilungsleiter Produktmanagement bei Rittal, stellt das neue Großschranksystem vor.

Aktuelle Ausgabe

Newsletter

Unsere Dosis Wissensvorsprung für Sie. Jetzt kostenlos abonnieren!

Webinare & Webcasts

Technisches Wissen aus erster Hand

Videos

Hier finden Sie alle aktuellen Videos

Alle Whitepaper

Hier finden Sie alle Whitepaper unserer Industrieseiten

Anzeige

Industrie.de Infoservice

Vielen Dank für Ihre Bestellung!
Sie erhalten in Kürze eine Bestätigung per E-Mail.
Von Ihnen ausgesucht:
Weitere Informationen gewünscht?
Einfach neue Dokumente auswählen
und zuletzt Adresse eingeben.
Wie funktioniert der Industrie.de Infoservice?
Zur Hilfeseite »
Ihre Adresse:














Die Konradin Verlag Robert Kohlhammer GmbH erhebt, verarbeitet und nutzt die Daten, die der Nutzer bei der Registrierung zum Industrie.de Infoservice freiwillig zur Verfügung stellt, zum Zwecke der Erfüllung dieses Nutzungsverhältnisses. Der Nutzer erhält damit Zugang zu den Dokumenten des Industrie.de Infoservice.
AGB
datenschutz-online@konradin.de