DE10208530A1

DE10208530A1 - Betriebseinheit, Peripheriegerät und Verfahren zum Betrieb eines Peripheriegeräts

Info

Publication number: DE10208530A1
Application number: DE2002108530
Authority: DE
Inventors: Michael Wack
Original assignee: Moeller GmbH
Current assignee: Eaton Industries GmbH
Priority date: 2002-02-27
Filing date: 2002-02-27
Publication date: 2003-09-18

Abstract

Bei elektrischen Produkten, bei denen zur Einbindung bzw. Ansprache derselben aus einem Host-Rechner heraus Treiber-Software oder Beschreibungs- und Konfigurationsdateien benötigt werden, stehen diese bisher nur getrennt von dem entsprechenden Peripheriegerät zur Verfügung und sind beispielsweise über Datenträger oder Web-Sites zunächst zu beschaffen. Bei einem Verfahren zum Betrieb eines Peripheriegerätes mittels einer Host-Einheit, bei dem das Peripheriegerät von der Host-Einheit erkannt, konfiguriert und/oder betrieben wird, ist deswegen vorgesehen, daß für die Konfiguration des Peripheriegerätes eine das Peripheriegerät beschreibende Gerätedatei der Host-Einheit von dem Peripheriegerät zur Verfügung gestellt wird. Entsprechend ist ein Peripheriegerät, aufweisend eine Schnittstelleneinheit zur Bereitstellung eines Kommunikationskanals zu einer Host-Einheit, mit einem Gerätespeicher und einer Konfigurationsmeldeeinheit ausgestattet, welche für einen Datenaustausch mit der Host-Einheit aktivierbar ist. Bei einer Betriebseinheit, aufweisend eine Host-Einheit und ein daran angeschlossenes Peripheriegerät, bei dem das Peripheriegerät von der Host-Einheit erkennbar, konfigurierbar und/oder betreibbar ist, ist ein Peripheriegerät derart ausgestaltet, daß eine für eine Konfiguration des Peripheriegerätes verwendbare und eine das Peripheriegerät beschreibende Gerätedatei auf dem Peripheriegerät der Host-Einheit zur Verfügung gestellt ist.

Description

Die Erfindung betrifft ein Verfahren zum Betrieb eines Peripheriegeräts mittels einer Host- Einheit, bei dem das Peripheriegerät von der Host-Einheit erkannt, konfiguriert und/oder betrieben wird. Weiter betrifft die Erfindung eine Betriebseinheit, aufweisend eine Host-Einheit und ein daran angeschlossenes Peripheriegerät, bei dem das Peripheriegerät von der Host- Einheit erkennbar, konfigurierbar und/oder betreibbar ist. Die Erfindung betrifft auch ein Peripheriegerät, aufweisend eine Schnittstelleneinheit zur Bereitstellung eines Kommunikationskanals zu einer Host-Einheit, sowie ein Peripheriegerät, das von einer Host-Einheit erkennbar, konfigurierbar und/oder betreibbar ist.
Eine Betriebseinheit weist üblicherweise ein Peripheriegerät auf, das von einer Host-Einheit über einen Bus gesteuert wird. Dabei nimmt das Peripheriegerät üblicherweise die Rolle einer Slave-Einheit ein und arbeitet entsprechend den Anweisungen der Host-Einheit, welche die Stellung einer Master-Einheit hat. Bei einer solchen Betriebseinheit können Peripheriegerät und Host-Einheit über einen Bus miteinander verbunden sein, welcher die Kommunikation zwischen Master und Slave ermöglicht.
Der Bus kann beispielsweise im Rahmen einer Netzwerkumgebung als ein Feldbus ausgebildet sein oder als eine direkte Anschlußverbindung zwischen Master und Slave.
Die genannte Host-Einheit kann beispielsweise eine Master-Speicherprogrammierbare- Steuerung (Master-SPS) im Rahmen eines Leitsystems sein oder ein üblicher Personalcomputer (PC) im Rahmen eines Computernetzwerks oder einer einfachen lokalen PC-Einheit. Ein Peripheriegerät kann im Falle der Master-SPS beispielsweise ein über einen Feldbus angeschlossenes Feldgerät sein. Im Falle des PC kann ein Peripheriegerät beispielsweise ein Drucker, Bildschirm oder ein Modem sein.
In der Automatisierungstechnik wird beispielsweise im Rahmen eines Leitsystems eine Master-SPS mit einem Feldgerät über einen Bus verbunden. Üblich ist beispielsweise ein Profibus als DP- oder FMS-Ausführung. Derartige Betriebseinheiten sind beispielsweise erläutert in "TAGUNGSBAND SPS/IPC/DRIVES, Elektrische Automatisierungstechnik - Systeme und Komponenten, Fachmesse&Kongress", Günther Brandenburg et al., 23.-25. Nov. 1999, Nürnberg, Hüthig. Ebenso findet sich eine Beschreibung üblicher Betriebseinheiten mit speicherprogrammierbaren Steuerungen in "PROFIBUS-DP, Grundlagen, Tips und Tricks für Anwender", Manfred Popp, Hüthig, Heidelberg, 1998. Die in der Automatisierungstechnik üblichen Engineering-Werkzeuge benötigen in der Regel genaue Kenntnisse über Variablen und Parameter des Feldbussystems und vor allem der angeschlossenen Feldbusteilnehmer, also der Peripheriegeräte. Engineering-Werkzeuge umfassen Werkzeuge wie zum Beispiel Programmiersysteme, Feldbus-Konfiguratoren, Inbetriebnahmewerkzeuge, B&B-Systeme, also Systeme zum Bedienen und Beobachten, wie auch Leitsysteme, insbesondere auch Leitsysteme, mit denen eine Visualisierung von Prozessen möglich ist. Engineering-Werkzeuge umfassen auch Werkzeuge, die vergleichbare Aufgaben erfüllen wie die genannten Beispiele. Die genannten Kenntnisse sind nicht Bestandteile eines Engineering-Werkzeugs, insbesondere nicht Bestandteil eines Steuerungsprogramms oder eines Leitsystems. Entsprechende Informationen sind also nicht auf einer Host-Einheit vorhanden. Zur Beschreibung von Geräte- Eigenschaften stehen für Feldgeräte die notwendigen Informationen mit Variablen, Parametern und zum Teil auch die Funktionen in maschinenlesbarer Form zur Verfügung. Die sogenannten Gerätebeschreibungen werden vom Hersteller des Gerätes veröffentlicht, zum Beispiel im Rahmen der Zertifizierung des Gerätes. Eine solche Zertifizierung ist beispielsweise bekannt aus "PROFIBUS-Journal, PROFIBUS-Open Solutions for the World of Automation Juli/Aug. 01" - Seite 6ff: "Geräte-Engineering mit GSD", PROFIBUS Nutzerorganisation e. V. (PNO). Es wird erläutert, daß durch Einlesen der Gerätebeschreibung die Engineering- Werkzeuge auf die Gerätespezifika eingestellt werden können. Bei allen bekannten Feldbussystemen sind solche Beschreibungsdateien auf entsprechenden Datenträgern separat vorhanden. Beispiele für Feldbussysteme sind der Profibus-DP oder der CAN-Bus oder der HART- Bus. Für eine mit dem Profibus-DP arbeitende Betriebseinheit steht eine Gerätedatei beispielsweise als Gerätestammdatei (GSD) oder als Electronic-Device-Description (EDD) zur Verfügung. Im Falle des CAN-Busses steht eine Gerätedatei beispielsweise als Electronic- Data-Sheet (EDS) zur Verfügung. Im Falle eines HART-Busses liegt eine Gerätedatei in Form der Device-Description Language (DDL) vor.
Der Hersteller eines Gerätes liefert üblicherweise die passende Beschreibungsdatei, i. e. Gerätedatei, entweder auf Diskette zu dem Gerät, veröffentlicht diese auf sonstige Weise oder stellt diese auf einem eigenen Web-Server zum Download zur Verfügung. Im Falle des Profibus-DP ist eine solche Download-Version beispielsweise auf dem PNO-Web-Server der obigen Profibus-Nutzerorganisation vorhanden. Der Hersteller muß dafür Sorge tragen, daß alle veröffentlichten Beschreibungsdateien eines Gerätes identisch sind und bei Weiterentwicklungen des Gerätes auf Abwärtskompatiblität geachtet wird. Desweiteren muß sich der Anwender die benötigten Geräte-Beschreibungsdateien, nachdem er sie sich vom Hersteller beschafft hat, in sein Engineering-Werkzeug, zum Beispiel einen Feldbus-Konfigurator, installieren und kann danach mit den Geräten arbeiten. Allerdings liefert üblicherweise eine Gerätedatei, zum Beispiel die GSD-Datei für einen Profibus-DP, eines Feldbusteilnehmers lediglich Informationen über die Anzahl der Bits/Bytes von Ein/Ausgangsdaten und die Anzahl und Typen von Modulen, die in einem Feldgerät angeordnet werden können. Es wird jedoch nicht definiert, was die ausgetauschten Daten darstellen, zum Beispiel wird nicht dargestellt, welche Datentypen (Analog, Digital, Gleitkomma, ganzzahliger Wert usw.) die ausgetauschten Daten darstellen.
Ein bisher üblicher Umgang mit einer Gerätedatei wird beispielsweise in der deutschen Patentanmeldung DE 100 49 025 A1 beschrieben. Bisherige Maßnahmen beschränken sich ausschließlich auf die Ausgestaltung einer GSD-Datei, erstrecken sich allerdings nicht auf eine Einbindung einer Gerätedatei im Rahmen einer Betriebseinheit oder eines Verfahrens zum Betrieb eines Peripheriegeräts.
Bisher muß sich der Anwender die benötigten Geräte-Beschreibungsdateien in ein Engineering-Werkzeug installieren und kann danach mit den Geräten arbeiten. In der DE 100 49 025 A1 wird beschrieben, daß ein Feldbusstrang bestehend aus Feldbusteilnehmern und dem Feldbus-Master unabhängig vom Rest des Steuerungssystems konfiguriert werden muß. Dabei muß der Systemingenieur zunächst das Netzwerk aufbauen. Dann müssen unter Verwendung eines verfügbaren Konfigurations-Tools, welches üblicherweise auf einem PC läuft und mit dem Feldbus-Master verbunden ist, Daten eingegeben werden, die die Feldbusteilnehmer spezifizieren. Das Konfigurations-Tool konfiguriert dann den Feldbus-Master und spezifiziert dabei die Speicherplätze in dem Feldbus-Master zur Verwendung für jedes der Signale, das von einem Feldbusteilnehmer empfangen wird, bzw. an diesen gesendet wird. Im nächsten Schritt muß die SPS programmiert werden, um Daten von den Speicherplätzen der Feldbusteilnehmer zur erhalten und dorthin zu senden. Ein solcher mehrschrittiger Konfigurationsprozeß ist zeitraubend, muß getrennt und neben der Konfiguration des Steuerungssystems durchgeführt werden und erfordert die Eingabe der Daten bezüglich den Feldbusteilnehmern in zwei oder mehr Systemen zu unterschiedlichen Zeitpunkten, was in der Folge zu Fehlern oder Mißständen bei der Konfiguration oder der Dokumentation führen kann.
Betreffend Betriebseinheiten, welche einen PC als Master aufweisen, ist zur Einbindung von Peripherieprodukten, beispielsweise eines Druckers, üblicherweise ein sogenannter Treiber vorgesehen, welcher üblicherweise von Hand über ein Betriebssystem, beispielsweise Microsoft Windows NT, installiert wird. In dem genannten Beispiel wird bevor ein Peripherieprodukt, also beispielsweise der Drucker, verwendet werden kann, dieses installiert und konfiguriert. Dieser Vorgang wird entweder bei der Installation des Betriebssystems oder erst später, wenn ein Peripherieprodukt benötigt wird, vorgenommen. Dazu wird in der Regel ein spezielles Betriebssystemprogramm aufgerufen, aus dem bei diesem Beispiel der gewünschte Drucker ausgewählt und konfiguriert werden kann. Üblicherweise besitzt das Betriebssystem eine Reihe vordefinierter Geräte, aus denen man auswählen kann. Findet sich das Gerät dort nicht, müssen nachträglich über ein separates Datenträgermedium, zum Beispiel über eine Diskette, die notwendigen Beschreibungsdateien, d. h. Treiber, eingelesen und installiert werden. Diese liegen üblicherweise dem Gerät separat bei, beispielsweise in Form einer Diskette, oder können von einer Web-Seite des jeweiligen Herstellers geladen werden. Bei neueren MS-Windows-Versionen kann auch die sogenannte "Plug&Play"-Technik angewendet werden. Diese Technik legt fest, wie sich ein Gerät gegenüber dem Betriebssystem zu erkennen gibt und teilt dabei mit, welche Ressourcen es benötigt und wie ein Software-Treiber beschaffen sein muß, damit Windows ihn nach der Identifikation des Gerätes lokalisieren und laden kann. Durch diese Methode wird der Anwender entlastet, die Installationsprogramme für neue Geräte aufrufen zu müssen. Diese Maßnahme wird automatisch übernommen. Jedoch sind auch in diesem Fall die Gerätetreiber separat auf einem getrennten Datenträgermedium vorhanden, und müssen gegebenenfalls, wie oben beschrieben, manuell nachgeladen werden. Eine Gerätedatei für eine PC-Betriebseinheit, also ein PC-Gerätetreiber, besteht aus beschreibenden Dateien, die das Verhalten des Peripheriegerätes, also in diesem Beispiel des Druckers, sowie die von dem Gerät benötigten Ressourcen (zum Beispiel I/O-Ports, Interrupts usw.) sowie allgemeine Eigenschaften (zum Beispiel Eingabegeräte, Massenspeicher usw.) festlegen und aus Software (Treiber), die in das Betriebssystem installiert werden und den Zugriff auf das Gerät auf einem unteren Niveau durchführen. Die Installation eines Gerätetreibers ist beispielsweise bekannt aus "Peter Norton's Windows NT 4 Workstation", 1997, ISBN 3-87791-889-1, Kapitel 14.1 - "Geräte installieren und entfernen".
Im folgenden wird für die Begriffe "Geräte-Beschreibungsdatei" und "Treiber-Software" der Begriff "Gerätedatei" verwendet. Für die Begriffe "Feldgerät" (zum Beispiele Antriebe, Ventilinseln oder I/O-Feldbuskomponenten, Digital- oder Analog-Zähler usw.), "Feldbusteilnehmer", "PC-Peripherieprodukt", also jede Art von Slave-Geräten (zum Beispiel Drucker, Bildschirm, Bildschirmkarte, Bedienmaus oder Modem), wird der Begriff "Peripheriegerät" verwendet. Für die Begriffe Master-SPS, Leitsystem, PC oder ähnliches, also jede Art einer Master-Einheit, wird der Begriff "Host-Einheit" verwendet. Desweiteren bezieht sich im folgenden der Begriff "Bus" auf jede Art von Datenverbindung zwischen Host-Einheit und Peripheriegerät, also beispielsweise ein Feldbus, eine direkte Datenleitung oder auch eine Funkverbindung.
Die beschriebene Art und Weise der Handhabung von Gerätedateien für Feldgeräte in der Automatisierungstechnik als auch für PC-Peripheriegeräte hat eine Reihe von erheblichen Nachteilen. So ist es in der Regel zur vollständigen und korrekten Nutzung eines Peripheriegerätes zwingend erforderlich, daß eine Gerätedatei eindeutig zu einem Gerät paßt. Wird diese Vorschrift nicht eingehalten, kann das Gerät entweder nicht oder nur teilweise betrieben werden. Es kann aber auch zu einem ungewollten Fehlverhalten kommen, wie dies beispielsweise in der DE 100 49 025 A1 beschrieben ist. Insbesondere kann es im Zuge von Weiterentwicklungen der Geräte für den Anwender notwendig sein, für jede Geräteversion eine Gerätedatei vorzuhalten. Bei der Vielzahl der heute vorhandenen Feldbusteilnehmer bzw. PC- Peripheriegeräten führt dies leicht zu einem erheblichen und zeitraubenden Verwaltungsaufwand. Auch kann es im Zuge von Wartungsarbeiten notwendig sein, ein defektes oder nicht intaktes Gerät auszutauschen. Falls in diesem Fall ein aktuelleres Gerät verwendet wird, und dies ist vor allem im PC-Bereich üblich, für das aber die Konfiguration nicht paßt, kann es im nachfolgenden Betrieb zu Problemen kommen. Speziell im Bereich der vernetzbaren PC- Peripheriegeräte, wie zum Beispiel Drucker, entsteht der Aufwand zur Installation von Gerätedateien pro Arbeitsplatz und nicht pro Gerät. Dies vervielfacht die oben beschriebene Problematik. Insbesondere ist es in größeren Firmen üblich, daß Endgeräte wie Drucker nicht durch die Benutzer, sondern durch spezielles Fachpersonal installiert werden. Damit hat der einzelne Benutzer aber keinen direkten Zugriff auf die benötigten Gerätedateien, die üblicherweise dem Gerät beiliegen. Auch für die Hersteller bedeutet es einen nicht unerheblichen Logistikaufwand, für alle Geräte und alle Versionen auf allen Lieferwegen identische Stände oder Gerätedateien vorzuhalten.
Insbesondere bedeutet es aber für den Anwender von Peripheriegeräten einen erheblichen Aufwand, alle benötigten Gerätedateien an allen Standorten konsistent vorzuhalten. Dies ist beispielsweise der Fall bei verwendeten LapTops von Servicepersonal. Servicepersonal verfügt heute daher in der Regel nicht über Gerätedateien. Im Falle einer Wartungsarbeit kann es daher zu einer Beschaffungsproblematik mit nachfolgenden Stillstandszeiten einer Maschine oder Anlage kommen, was einen erheblichen Kostenaufwand bedeuten kann. Der größte Nachteil liegt jedoch vor allem in der Notwendigkeit einer Installationsprozedur der Gerätedatei durch den Anwender begründet. Neben dem zeitlichen Aufwand, den diese Prozedur benötigt, können hier durch Fehlbedienungen auch Fehlersituationen bei der Installation und beim Betrieb entstehen.
An dieser Stelle setzt die Erfindung an, deren Aufgabe es ist, ein Verfahren zum Betrieb eines Peripheriegeräts und eine Vorrichtung anzugeben, so daß ein Peripheriegerät auf besonders einfache Weise in Betrieb genommen werden kann.
Die Aufgabe wird durch ein Verfahren der eingangs genannten Art gelöst, bei dem erfindungsgemäß für die Konfiguration des Peripheriegeräts eine das Peripheriegerät beschreibende Gerätedatei der Host-Einheit von dem Peripheriegerät zur Verfügung gestellt wird.
Die wesentliche Erkenntnis der Erfindung liegt darin, eine Gerätedatei in einem Peripheriegerät unterzubringen, und mit dem Peripheriegerät zusammen zur Verfügung zu stellen.
Dies hat eine ganze Reihe von Vorteilen gegenüber bisher üblichen Maßnahmen, eine Gerätedatei außerhalb des Peripheriegeräts und auf separaten Datenträgern zur Verfügung zu stellen. So entfällt die Notwendigkeit einer Beschaffung von Gerätedateien komplett. Diese sind nunmehr nämlich in den Geräten selber vorhanden. Es ist deshalb immer sichergestellt, daß die Gerätedatei inhaltlich zu dem Gerät paßt. Eine Verwechslung ist nicht mehr möglich. Es entfallen damit alle logistischen Vorhaltungen zur Speicherung, Sicherung und Konsistenzhaltung von Gerätedateien, da diese in den Geräten selber vorhanden sind. Zudem kann auf bisher notwendige manuelle Installationsprozeduren von Gerätedateien verzichtet werden. Damit werden zum einen Zeit und Kosten gespart, zum anderen können Fehlbedienungen und damit Fehler in der Konfiguration und der Dokumentation nicht mehr auftreten. Beim Hersteller entfallen insbesondere die Vorkehrungen und damit die Kosten, Gerätedateien entweder den Geräten auf separaten Datenträgern, also Diskette oder CD, mitzugeben oder im Internet bzw. bei Mailboxen vorzuhalten. Somit entfallen im wesentlichen die im Zusammenhang mit dem aufgeführten Stand der Technik genannten Nachteile bei einem Verfahren und den Vorrichtungen der vorgeschlagenen Art.
Vorteilhafte Weiterbildungen der Erfindung sind den Unteransprüchen zu entnehmen und geben im einzelnen vorteilhafte Möglichkeiten an, eine Gerätedatei in einem Peripheriegerät zu speichern, eine Gerätedatei aus einem Peripheriegerät zu laden und geeignet zu verwenden, beispielsweise in einem Konfigurationswerkzeug, sowie eine Gerätedatei vorteilhaft auf einer Host-Einheit zu speichern.
Hinsichtlich des Verfahrens wird die Gerätedatei bevorzugt aus dem Peripheriegerät in ein Konfigurationswerkzeug aufgenommen. Das Konfigurationswerkzeug weist bevorzugt ein Software-Modul auf, in das die Gerätedatei geladen wird. Insbesondere handelt es sich dabei also um ein Programm, das vorteilhaft weitgehend alle Schritte vorgibt oder vornimmt, die notwendig sind, eine das Peripheriegerät beschreibende Gerätedatei der Host-Einheit von dem Peripheriegerät zur Verfügung zu stellen. Dies hat den Vorteil, daß der Anwender in der Regel keine Maßnahmen, oder wenn, dann nur vom Konfigurationswerkzeug aufgeforderte Maßnahmen, zu ergreifen hat. Das Konfigurationswerkzeug ist bevorzugt Teil eines anfänglich erläuterten Engineering-Werkzeugs. Das Konfigurationswerkzeug könnte auch als Teil der Host-Einheit ausgebildet sein, insbesondere eine Prozessor-Einheit und/oder einen Speicher aufweisen. In solch einem Speicher könnte beispielsweise eine entsprechende Konfigurationsroutine abgelegt oder von dort ausgeführt werden.
Bevorzugt ist bei dem vorgeschlagenen Verfahren vorgesehen, daß das Konfigurationswerkzeug, um die das Peripheriegerät beschreibende Gerätedatei der Host-Einheit von dem Peripheriegerät zur Verfügung zu stellen, auf einen Bus zugreift, über welchen das Peripheriegerät an der Host-Einheit angeschlossen ist. Ein Bus könnte ein Feldbus oder eine direkte Datenverbindung sein. Mittels dem Konfigurationswerkzeug wird dabei ein Peripheriegerät mit gespeicherter Gerätedatei erkannt, dieses aus dem Anfangszustand in einen Datenaustauschzustand versetzt, die Gerätedatei vom Peripheriegerät zum Konfigurationswerkzeug übertragen und das Peripheriegerät wieder in den Anfangszustand versetzt. Vorteilhaft wird die Gerätedatei zur Host-Einheit übertragen. Der vorgenannte spezielle Ablauf des Verfahrens zum Betrieb des Peripheriegeräts führt dazu, daß das Peripheriegerät erkannt wird und alle notwendigen Informationen über das Peripheriegerät dem Konfigurationswerkzeug, insbesondere der Host-Einheit zur Verfügung stehen. Diese Informationen sind, sollten sie nicht bereits der Host-Einheit, beispielsweise in Form von Standardgerätedateien oder bereits auf der Host-Einheit gespeicherten Gerätedateien, vorliegen, in der entsprechend des vorgeschlagenen Verfahrens in einem Peripheriegerät gespeicherten Gerätedatei vorhanden. Die vorgenannte Weiterbildung des Verfahrensablaufs ermöglicht eine effektive und mit bereits am Einsatzort bestehenden Vorgaben für Host-Einheiten, Bus-Systeme und Peripheriegeräte kompatible Struktur. Nachdem somit, insbesondere nach der vorgenannten Weiterbildung des vorgeschlagenen Verfahrens, der Host-Einheit alle Informationen über angeschlossene Peripheriegeräte zur Verfügung stehen, können diese auf geeignete Weise für den Betrieb konfiguriert und nachfolgend betrieben werden.
Bei der vorgenannten Weiterbildung wird für den Datenaustausch vorteilhaft eine im Peripheriegerät vorgesehene Konfigurationsmeldeeinheit aktiviert, die Gerätedatei vom Peripheriegerät zum Konfigurationswerkzeug übertragen und das Peripheriegerät in den Anfangszustand versetzt, indem insbesondere die Konfigurationsmeldeeinheit des Peripheriegeräts deaktiviert wird. Für die Übertragung der das Peripheriegerät beschreibenden Gerätedatei ist also im Peripheriegerät eine eigens dafür vorgesehene Konfigurationsmeldeeinheit vorgesehen, welche mit dem Konfigurationswerkzeug bei dem vorgeschlagenen Verfahren kommuniziert und den Datenaustausch regelt.
Vorteilhaft wird die Gerätedatei segmentiert übertragen, also in mehreren Teilen. Zum Teil ist es nämlich günstig bzw. notwendig, die Größe eines übertragenen Teils an den Zyklus von Nettodaten anzupassen, der von einem Bus pro Teilnehmer spezifiziert ist. So könnte beispielsweise eine Obergrenze beim Profibus-DP von maximal 246 Bytes für einen Teil spezifiziert sein, so daß die Gerätedatei in Segmenten von maximal 246 Bytes übertragen werden kann.
Im folgenden werden vier bevorzugte Weiterbildungen des vorgeschlagenen Verfahrens beschrieben, welche die Möglichkeit bieten, das vorgeschlagene Verfahren auf ein spezielles Anwendungserfordernis nach Maßgabe von beispielsweise einer Netzwerkumgebung, einer Automatisierungsanforderung oder einer PC-Betriebseinheit, anzupassen.
So kann es im Rahmen einer Weiterbildung beispielsweise vorteilhaft sein, nur ein solches Peripheriegerät, für das der Host-Einheit noch keine Gerätedatei zur Verfügung steht, zu erkennen, und insbesondere nur ein solches in einen Datenaustauschzustand zu versetzen. Dies hat den Vorteil, daß Peripheriegeräte, für welche der Host-Einheit bereits eine Gerätedatei vorliegt, nicht erkannt, angesprochen oder in einen Datenaustauschzustand versetzt werden müssen. Eine solche Vorgehensweise führt zu einer effektiven, zeitsparenden und damit kostensparenden Ausführung des vorgeschlagenen Verfahrens.
Gemäß einer weiteren bevorzugten Weiterbildung des vorgeschlagenen Verfahrens könnte auch eine Allgemein-Gerätedatei vorgesehen sein, welche insbesondere ein Peripheriegerät mindestens für den Zweck des Datenaustausches der Gerätedatei normgerecht beschreibt. Es ist besonders bevorzugt, daß das Peripheriegerät durch die Allgemein-Gerätedatei vorinitialisiert wird, um die Gerätedatei von dem Peripheriegerät der Host-Einheit zur Verfügung zu stellen. Dadurch ist sichergestellt, daß ein Peripheriegerät für den Datenaustausch der Gerätedatei sicher und korrekt erkannt wird. Ein Vorinitialisieren durch eine Allgemein-Gerätedatei hat den Vorteil, daß die Gerätedatei und damit die Beschreibung eines Peripheriegeräts, unabhängig von einer Prüfung auf die spezielle Ausführung eines Peripheriegeräts, entsprechend einer von der Allgemein-Gerätedatei berücksichtigten Norm vorgenommen werden kann. Eine solche pauschale Handhabung aller Peripheriegeräte ermöglicht es, eine das Peripheriegerät beschreibende Gerätedatei der Host-Einheit von dem Peripheriegerät sehr zeiteffektiv zur Verfügung zu stellen.
Gemäß noch einer weiteren vorteilhaften Weiterbildung des vorgeschlagenen Verfahrens könnte die Gerätedatei von dem Peripheriegerät auch einer Klasse-2-Host-Einheit zur Verfügung gestellt werden. Diese könnte einer Klasse-1-Host-Einheit neben- oder untergeordnet sein und als weitgehend autarke Host-Einheit in einem regionalen oder lokalen Netzabschnitt eines Gesamtnetzes eingesetzt sein. Somit kann das vorgeschlagene Verfahren vorteilhaft auch in einer dezentralen Netzwerk- oder Automatisierungsumgebung eingesetzt werden. Unter einer Klasse-1-Host-Einheit wird hier eine Master-Einheit im üblichen Sinne verstanden, wie sie insbesondere bei mehr oder weniger hierarchisch aufgebauten Steuerungssystemen Verwendung findet, so zum Beispiel Suconet-K, Interbus-S, Control-Net oder Device- Net. D. h. eine Klasse-1-Host-Einheit ist im üblichen Sinn einem Bus-Strang zugeordnet, an welchem Strang dann mehrere Peripheriegeräte angeschlossen sein können. Im Rahmen eines solchen eher hierarchisch aufgebauten Steuerungssystems kann dann eine oben genannte Klasse-2-Host-Einheit vorgesehen sein, welche insbesondere zur Parametrisierung der Klasse- 1-Host-Einheit vorgesehen ist, aber auch, ähnlich wie eine übliche Master-Einheit, direkt auf ein Peripheriegerät eines ihm zugeordneten Stranges zugreifen kann. In diesem Sinne ist eine Klasse-2-Host-Einheit also einer Klasse-1-Host-Einheit-nebengeordnet. Dies ist erst recht der Fall bei Steuerungssystemen, die einen an sich schon nur geringfügigen oder gar keinen hierarchischen Aufbau aufweisen, insbesondere ähnlich einem Ether-Net. Aufgrund eines an sich schon eher dezentralen Aufbaues weisen solche Steuerungssysteme per se gleichberechtigte Host-Einheiten auf, wenn mehrere Host-Einheiten vorhanden sind. So ist beispielsweise der Can-Bus ein solches Steuerungssystem. Auch für solche eher nicht hierarchisch aufgebaute Systeme wird im folgenden die Begrifflichkeit von Klasse-1-Host-Einheit und Klasse- 2-Host-Einheit beibehalten. Der Begriff Klasse-2-Host-Einheit bezeichnet also eine Host- Einheit, welche einer Klasse-1-Host-Einheit als mehr oder weniger gleichberechtigte Master- Einheit nebengeordnet sein kann, aber auch untergeordnete Funktionen wahrnehmen kann, die sonst einer Slave-Einheit zukommen. Die Klasse-1-, Klasse-2-Begrifflichkeit wird im folgenden unabhängig von einem hierarchisch aufgebauten oder eher dezentral aufgebauten Steuerungssystem benutzt.
Entweder bei einer Automatisierungsanwendung oder bei einer PC-Anwendung könnte die Gerätedatei vorteilhaft von dem Peripheriegerät der Host-Einheit über einen Feld-Bus zur Verfügung gestellt werden. Gemäß einer auch noch weiteren bevorzugten Weiterbildung des Verfahrens ist es jedoch auch möglich, die Gerätedatei von dem Peripheriegerät der Host- Einheit unter Umgehung des Feld-Busses direkt zur Verfügung zu stellen. Dazu können in dem Peripheriegerät separate Schnittstellen und daran anschließbare entsprechende direkte Datenverbindungen, wie Direktleitungen oder Funkverbindungen, zu einer zentralen oder dezentralen Host-Einheit vorgesehen sein.
Die vorgenannten vier Weiterbildungen des vorgeschlagenen Verfahrens sind lediglich eine bevorzugte Auswahl von möglichen Anpassungen desselben an notwendige Umstände einer Netzwerkumgebung oder Automatisierungsumgebung, insbesondere können diese in Kombination oder alternativ zueinander verwendet werden. Eine Anwendung des vorgeschlagenen Verfahrens oder einer Weiterbildung desselben ist bei allen elektrischen Produkten möglich, wo zur Einbindung bzw. Ansprache derselben als Peripheriegerät aus einem Host-Rechner als Host-Einheit heraus Treiber-Software oder Beschreibungs- oder Konfigurationsdateien als Gerätedatei benötigt wird. Im Automatisierungsbereich sind dies alle Arten von elektrischen Peripheriegeräten wie zum Beispiel Antriebe, Ventilinseln, Bedien- und Beobachtungsgeräte (HMI), SPS als Feldbusteilnehmer, I/O-Feldbuskomponenten (Digital, Analog, Zähler usw.), Temperaturerfassungsmodule und andere Peripheriegeräte, die sich als Teilnehmer an einem Feldbus eignen und/oder üblicherweise als Teilnehmer an einen Feldbus gekoppelt werden. Im PC/IT-Umfeld sind dies zum Beispiel PC-Peripheriegeräte wie ein Drucker, ein Bildschirm, eine Maus oder ein Modem, welche an einem PC über Treiber-Software eingebunden und/oder angesprochen werden.
Das vorgeschlagene Verfahren eignet sich insbesondere in Anwendung auf eine Betriebseinheit und ein Peripheriegerät, bei dem eine Gerätedatei vorgesehen ist.
Die Erfindung führt weiter auf eine Betriebseinheit der eingangs genannten Art, durch welche die Aufgabe betreffend die Vorrichtung gelöst wird und bei der zur Lösung der Aufgabe erfindungsgemäß vorgesehen ist, daß das Peripheriegerät eine für eine Konfiguration des Peripheriegerätes verwendbare und eine das Peripheriegerät beschreibende Gerätedatei aufweist, welche auf dem Peripheriegerät der Host-Einheit zur Verfügung gestellt ist.
Insbesondere kann gemäß einer bevorzugten Weiterbildung die Betriebseinheit eine Klasse-2- Host-Einheit aufweisen, der die Gerätedatei auf dem Peripheriegerät zur Verfügung gestellt ist.
Die Gerätedatei ist dabei vorteilhaft auf dem Peripheriegerät der Host-Einheit über einen Feld-Bus zur Verfügung gestellt. Sie könnte jedoch auch, je nach Anwendung, über eine zusätzliche Schnittstelle unter Umgehung des Feld-Busses der Host-Einheit direkt zur Verfügung gestellt sein.
Zur Aufnahme der Gerätedatei weist die Betriebseinheit vorteilhaft ein Konfigurationswerkzeug auf, welches insbesondere als ein Software-Baustein ausgebildet ist, allerdings auch als Hardware-Komponente zusätzlich oder alternativ vorliegen kann.
Bei der vorgeschlagenen Betriebseinheit ist vorteilhaft bei einem Peripheriegerät eine Konfigurationsmeldeeinheit, insbesondere eine als Software-Baustein ausgebildete Konfigurationsmeldeeinheit vorgesehen.
Schließlich führt die Erfindung hinsichtlich der Aufgabe betreffend die Vorrichtung auf ein Peripheriegerät der eingangs genannten Art, bei dem zur Lösung der Aufgabe erfindungsgemäß ein Gerätespeicher und eine Konfigurationsmeldeeinheit, welche für einen Datenaustausch mit der Host-Einheit aktivierbar ist, vorgesehen ist. Vorteilhaft wird die Konfigurationsmeldeeinheit nach dem Datenaustausch deaktiviert.
Gemäß einer bevorzugten Weiterbildung des vorgeschlagenen Peripheriegerätes ist außerdem eine Prozessoreinheit, eine Peripherie-Schnittstelleneinheit zur Bereitstellung eines Kommunikationskanals zur Peripherie und ein weiterer Datenspeicher vorgesehen.
Gemäß einer besonders vorteilhaften und bevorzugten Weiterbildung des vorgeschlagenen Peripheriegeräts weist der Gerätespeicher eine das Peripheriegerät beschreibende Gerätedatei auf, welche mittels der Konfigurationseinheit der Host-Einheit zur Verfügung gestellt ist.
Die Erfindung hinsichtlich der Aufgabe betreffend die Vorrichtung führt auch auf ein Peripheriegerät der weiteren eingangs genannten Art, bei dem zur Lösung der Aufgabe erfindungsgemäß eine für eine Konfiguration des Peripheriegeräts verwendbare und eine das Peripheriegerät beschreibende Gerätedatei vorgesehen ist, welche auf dem Peripheriegerät der Host-Einheit zur Verfügung gestellt ist.
Die vorgeschlagene Betriebseinheit und/oder das Peripheriegerät ist bevorzugt entsprechend der Umgebung einer speicherprogrammierbaren Steuerung ausgelegt und/oder auch entsprechend der Umgebung eines PC-Systems.
Im folgenden werden bevorzugte Ausführungsformen der Erfindung im Vergleich zum Stand der Technik beschrieben. Dabei ist zu berücksichtigen, daß vielfältige Modifikationen und Änderungen betreffend Form und Detail einer Ausführungsform vorgenommen werden können, ohne von der allgemeinen Idee der Erfindung abzuweichen. Die in der vorstehenden Beschreibung, in der Zeichnung sowie in den Ansprüchen offenbarten Merkmale der Erfindung können sowohl einzeln als auch in beliebiger Kombination für die Verwirklichung der Erfindung wesentlich sein. Die allgemeine Idee der Erfindung ist nicht beschränkt auf die exakte Form oder das Detail der im folgenden gezeigten und beschriebenen bevorzugten Ausführungsformen oder beschränkt auf einen Gegenstand, der eingeschränkt wäre im Vergleich zu dem in den Ansprüchen beanspruchten Gegenstand.
Ausführungsbeispiele und Ausführungsformen der Erfindung werden anhand der Zeichnung beschrieben. Diese soll die Ausführungsformen nicht notwendig maßstäblich darstellen; vielmehr ist die Zeichnung nur zur Erläuterung dienlich, in schematisierter und/oder leicht verzerrter Form ausgeführt. Im Hinblick auf Ergänzungen der aus der Zeichnung unmittelbar erkennbaren Lehren wird auf den einschlägigen Stand der Technik verwiesen. Im einzelnen zeigen die Figuren der Zeichnung in:
Fig. 1 eine Betriebseinheit in Form einer speicherprogrammierbaren Steuerung mit Feldbusumgebung und Peripheriegeräten;
Fig. 2 eine schematische Darstellung eines Verfahrens zum Betrieb eines Peripheriegeräts im Rahmen eines Konfigurationssystems;
Fig. 3 ein Ablaufdiagramm eines Verfahrens zum Betrieb eines Peripheriegerätes gemäß dem Stand der Technik;
Fig. 4 eine bevorzugte Ausführungsform eines Verfahrens zum Betrieb eines Peripheriegerätes, dargestellt in Form eines Ablaufdiagramms für ein Konfigurationsverfahren eines Feldbus;
Fig. 5 eine bevorzugte Ausführungsform eines Peripheriegerätes zur Verwendung bei einer bevorzugten Ausführungsform einer Betriebseinheit, mit einem schematisiert dargestellten Aufbau der bevorzugten Ausführungsform des Peripheriegerätes.
In Fig. 1 ist ein speicherprogrammierbares Steuerungssystem 10 gezeigt, das eine speicherprogrammierbare Steuerungseinheit 11 umfaßt. Dieses weist eine speicherprogrammierbare Steuerung 11a sowie mehrere Steckmodule für anwendungsspezifische Organisations- und Funktionsmodule 11b, eine CPU 11d sowie weitere zur Verfügung stehende freie Steckplätze 11c auf. Über einen Feldbus 13 sind mehrere Peripheriegeräte, hier Feldgeräte 14a, 14b und 14c an die speicherprogrammierbare Steuerungseinheit 11 angeschlossen.
Zur Inbetriebnahme und Programmierung des speicherprogrammierbaren Steuerungssystems 10 ist ein Engineering-System 12 vorgesehen, das insbesondere einen PC aufweist, welcher über eine Kommunikationsverbindung 15 mit den Feldgeräten 14a, 14b und 14c sowie dem Feldbus 13 auch mit der speicherprogrammierbaren Steuerungseinheit 11 verbunden ist.
Bevor die Feldgeräte 14a, 14b und 14c konfiguriert werden können, müßten die Feldgeräte beschreibende Gerätedateien vorliegen. Gemäß dem Stand der Technik werden diese separat und getrennt von den Feldgeräten 14a, 14b und 14c zur Verfügung gestellt. Bei dem in Fig. 1 gezeigten speicherprogrammierbaren Steuerungssystem 10 werden für die Feldgeräte 14a, 14b und 14c entsprechende Gerätedateien auf Disketten 16a, 16b und 16c dem Engineering- System 12 und damit der speicherprogrammierbaren Steuerungs-Einheit 11 als Host-Einheit zur Verfügung gestellt.
Bei einer bevorzugten Ausführungsform der vorgeschlagenen Betriebseinheit ist eine solche Maßnahme allenfalls zusätzlich als mögliche vorteilhafte Ergänzung vorgesehen, da die Gerätedateien gemäß einer bevorzugten Ausführungsform als integraler Teil eines Feldgeräts zur Verfügung gestellt wird.
In Fig. 2 ist ein Konfigurationssystem 20 schematisch dargestellt, welches ein Konfigurationswerkzeug 22 aufweist. Das Konfigurationswerkzeug 22 kann als Software-Modul oder auch als Hardware-Modul ausgebildet sein. Über das Konfigurationsmodul 22 wird unter Verwendung von Gerätedateien 26a, 26b und 26c eine entsprechende Feldgeräte umfassende Dokumentation 25 erstellt, auf Grundlage derer Feldgeräte, wie die Feldgeräte 14a, 14b, 14c in Fig. 1, konfiguriert werden können. Die Dokumentation und/oder die Gerätedateien 26a, 26b und 26c können in einer Konfigurationsdatenbank 24 abgelegt werden. Entsprechende Schnittstellen, Datenverbindungen und Datenaustauschroutinen 23 sind zwischen dem Konfigurationswerkzeug 22 und den Einheiten 24, 25 und 26a-c vorgesehen, sowie entsprechende Schnittstellen, Datenverbindungen und Datenaustauschroutinen 27 zwischen den Einheiten 24, 25 und 26a-c. Außerdem ist eine Kommunikationsverbindung 28 zwischen dem Konfigurationswerkzeug 22 und dem Benutzer als Ein/Ausgabeinheit vorgesehen. Es ist auch eine Peripheriegeräteschnittstelle 29 vorgesehen. An diese ist ein Kommunikationskanal 21, beispielsweise eine direkte Datenverbindung oder ein Feldbus zu einem Feldgerät 14a, 14b, 14c anschließbar. Bei dem in Fig. 2 gezeigten Konfigurationssystem 20 werden die Gerätedateien 26a, 26b und 26c auf Disketten oder einem anderen Datenträgermedium, jedenfalls aber getrennt von einem Feldgerät dem Konfigurationswerkzeug 22 zur Verfügung gestellt. Dies ist bei einer bevorzugten Ausführungsform einer vorgeschlagenen Betriebseinheit oder eines Peripheriegeräts nicht mehr notwendig, da eine ein Peripheriegerät beschreibende Gerätedatei mit dem Peripheriegerät selbst als integraler Bestandteil derselben zur Verfügung gestellt wird.
In Fig. 3 ist in Form eines Ablaufdiagramms ein Konfigurationsverfahren eines Feldbus gemäß dem Stand der Technik dargestellt. Nur wenn in einer Hosteinheit bereits eine Gerätedatei vorliegt kann der Feldbus konfiguriert werden, die Konfiguration in die SPS geladen werden und der Feldbusbetrieb gestartet werden. Sollte dies nicht der Fall sein, muß zunächst eine Gerätedatei beschafft werden, da diese üblicherweise nicht im System oder einem Feldgerät zur Verfügung gestellt wird. Die Beschaffung einer Gerätedatei umfaßt entweder das Auslesen von einem entsprechenden Datenträger oder das Downloaden von einer dafür vorgesehenen Web-Seite. Die Gerätedatei muß dann in einem PC, beispielsweise eines Engineering-Systems eingelesen werden und in einem Konfigurationssystem installiert werden. Dabei würde beispielsweise ein anhand der Fig. 2 beschriebenes Verfahren Anwendung finden. Erst danach könnte die Konfiguration eines Feldbusses erstellt werden.
Ein derartig aufwendiger Verfahrensverlauf ist gemäß dem vorgeschlagenen Verfahren nicht mehr notwendig. Eine bevorzugte Ausführungsform des Verfahrens ist anhand eines Ablaufdiagramms für ein Konfigurationsverfahren eines Feldbus in Fig. 4 schematisch dargestellt. Ist eine Gerätedatei bereits vorhanden, kann eine Feldbuskonfiguration erstellt werden, dieselbe in die SPS geladen werden und der Feldbusbetrieb gestartet werden. Ist eine Gerätedatei jedoch nicht vorhanden, so ergibt sich auch dann ein sehr einfacher Verfahrensablauf. Falls ein verwendetes Konfigurationswerkzeug zum Zeitpunkt der Erstellung der Konfiguration über das Peripheriegerät noch keine Gerätedatei, zum Beispiel aus einer früheren Konfiguration, zur Verfügung hat, liest das Konfigurationswerkzeug diese Information einfach aus dem entsprechenden Feldgerät aus. Dabei kann beispielsweise ein Konfigurationswerkzeug des Profibus DP der Firma Moeller zum Beispiel ein CFG-DP Gerät oder ein Konfigurationswerkzeug für einen COM-Profibus der Firma Siemens Anwendung finden. Dabei ist jedoch das Peripheriegerät entsprechend den vorgeschlagenen Merkmalen ausgelegt. Eine bevorzugte Ausführungsform des Peripheriegerätes wird im folgenden noch anhand der Fig. 5 beschrieben werden.
Im einzelnen wird zur Konfiguration und Inbetriebnahme eines Profibus-DP Feldbusses, beispielsweise durch einen Systemingenieur, zunächst der Feldbus derart aufgebaut, daß alle gewünschten Feldgeräte und der Profibus-DP-Master, also eine verfügbare Host-Einheit, miteinander verbunden werden. Danach wird unter Verwendung eines verfügbaren Konfigurationstools, welches im Einzelfall kompatibel zum CFG-DP Profibus oder beispielsweise auch zum COM-Profibus ist, welches üblicherweise auf einem PC läuft und mit dem Feldbusmaster verbunden ist, Daten eingegeben, die den Master bzw. das Netzwerk spezifizieren. Dazu wird beispielsweise eine verfügbare Baudrate spezifiziert. Danach können die einzelnen Feldgeräte ausgewählt und geeignet parametriert werden. Zur Auswahl eines Teilnehmers bieten die Konfigurationstools Menüs an, die bereits bekannte Teilnehmer darstellen und aus einer internen Datenbank gespeist werden. Neue bisher nicht bekannte Teilnehmer können in die Datenbank aufgenommen werden, indem die GSD-Datei gemäß dem vorgeschlagenen Verfahren aus dem Peripheriegerät selber geladen wird. Selbstverständlich ist es gegebenenfalls auch zusätzlich möglich, eine GSD-Datei wie üblich über ein Datenträgermedium zur Verfügung zu haben.
Um Daten mit einem Profibus-DP Peripheriegerät austauschen zu können, wird der Profibus- DP-Master in der Regel nach Norm EN50170 vorbereitet, welche Norm folgende Telegrammreihenfolge beim Hochlaufen des Slaves, also des Peripheriegerätes, vorsieht:

1. Diagnoseanforderung
2. Stationsadresse ändern (optional)
3. Parametrieren des Teilnehmers
4. Konfigurieren des Teilnehmers
5. Zyklischer Datenaustausch

Eine Gerätedatei gemäß des vorgeschlagenen Verfahrens wird hinsichtlich obiger Telegrammreihenfolge, insbesondere bei der vorliegenden Ausführungsform, zwischen den Schritten 3. und 4. ausgeführt. Je nach Ausprägung des Peripheriegerätes und der Netzwerk- bzw. Automatisierungsumgebung stehen dabei verschiedene Möglichkeiten zur Verfügung, die Gerätedatei in das Konfigurationswerkzeug zu laden. Insbesondere ist eine der weiter unten erläuterten vier Möglichkeiten besonders geeignet für eine bestimmte Netzwerk- bzw. Automatisierungsumgebung. Eine Kombination derselben oder weitere Möglichkeiten sind selbstverständlich auch möglich.
Als besonders bevorzugte Ausführungsform des vorgeschlagenen Peripheriegerätes eignet sich für jede der noch im folgenden zu erläuternden genannten Möglichkeiten ein Peripheriegerät 50 gemäß der Fig. 5, welches zunächst beschrieben wird. Das Peripheriegerät 50 weist eine Prozessoreinheit 56 auf, welche die Wirkungsweise des Peripheriegeräts bestimmt. Die Prozessoreinheit 56 umfaßt einen Controller 56a, einen Speicher 56b und ein Kontrollprogramm 56c. Aufgrund der Befehle des Kontrollprogramms 56c liest der Controller 56a über die Peripherie-Ein/Ausgabeeinheit 57 Daten vom Prozeß bzw. der Peripherie ein und gibt über die Peripherie-Ein/Ausgabeeinheit 57 Daten an den Prozeß bzw. die Peripherie aus. Dabei wird zur Zwischenspeicherung von Daten der Datenspeicher 59 verwendet. Die Kommunikation zwischen den internen Einheiten des Peripheriegeräts 50 erfolgt über einen entsprechenden Datenbus 51. Das Peripheriegerät weist eine Konfigurationsmeldeeinheit 58 auf, welche zur Kommunikation mit einem Konfigurationswerkzeug, beispielsweise einem Konfigurationswerkzeug 22, wie in der Fig. 2 beschrieben, vorgesehen ist. Im Normalbetrieb wird die Konfigurationsmeldeeinheit 58 nicht angesprochen. Diese bleibt daher im Normalbetrieb deaktiviert. Nach Einschalten des Peripheriegerätes erwartet ein solches Gerät in der Regel Parametrier- und Konfigurationsdaten, mit denen von einer Host-Einheit Informationen wie zum Beispiel Adresse, Watchdog-Zeiten, Anzahl der Ein/Ausgabebytes, Baudrate etc. festgelegt werden. Dies geschieht mittels der Gerätedatei. Nach dieser Phase kann das Peripheriegerät in den regulären Betrieb wechseln und Daten, beispielsweise gemäß 4. und 5. der obigen Liste, mit der Host-Einheit austauschen.
Weiter weist das Peripheriegerät 50 einen Gerätedateispeicher 55 auf. Dieser kann als nicht flüchtiger Speicher ausgebildet, zum Beispiel als EEPROM, Flash oder als gepuffertes RAM. Dadurch bleibt der Inhalt des Gerätedateispeichers 55 auch bei einem Netzausfall erhalten. Darüber hinaus kann der Anwender/Systemingenieur den Gerätedateispeicher 55 zwar auslesen aber nicht löschen und damit auch nicht manipulieren, was aus Sicherheitsgründen vorteilhaft ist. Das Auslesen des Gerätedateispeichers 55 ist zu jedem Zeitpunkt möglich, da aus Sicht des Peripheriegeräts 50 nicht klar ist, wann ein Konfigurationswerkzeug die abgelegten Informationen benötigt. Die Konfigurationsmeldeeinheit 58 kann selbstverständlich wie oben bereits beschrieben als Hardwarebaustein ausgeführt sein, sie könnte jedoch auch als Softwarebaustein realisiert sein.
Die oben angesprochenen vier verschiedenen Möglichkeiten, eine Gerätedatei in das Konfigurationswerkzeug zu laden, beispielsweise einem Konfigurationswerkzeug entsprechend dem Konfigurationswerkzeug 22 der Fig. 2, stellen sich nun, beispielsweise angewandt auf ein System gemäß Fig. 1, wie folgt dar:

1. Das Konfigurationswerkzeug scannt zunächst den angeschlossenen Bus ab und erkennt über ein Bit im obligatorischen Diagnosetelegramm die DP-Peripheriegeräte, die eine Gerätedatei im Sinne des vorgeschlagenen Verfahrens speichern. Das Konfigurationswerkzeug geht nur mit dem bzw. den in Frage kommenden Peripheriegeräten in den Zustand "zyklischer Datenaustausch". Vorteilhaft werden bei dieser Ausführungsform des vorgeschlagenen Verfahrens Peripheriegeräte für die bereits eine GSD-Datei vorliegt, nicht angesprochen. Im Peripheriegerät wird nun die Konfigurationsmeldeeinheit 58 aktiviert. In diesem Zustand liefert das Peripheriegerät dann statt der wirklichen E/A- Daten den Inhalt der gespeicherten Gerätedatei, welche vorteilhaft in einem Gerätedateispeicher 55 abgelegt ist. Dabei ist es vorteilhaft möglich, die Gerätedatei in mehreren Teilen segmentiert zu übertragen, da beispielsweise ein Profibus-DP pro Teilnehmer und Zyklus maximal 246 Bytes Nettodaten spezifiziert. Nach der vollständigen und korrekten Übertragung wird die Konfigurationsmeldeeinheit 58 wieder deaktiviert und das Peripheriegerät 50 wechselt wieder in den Anfangszustand zurück. Hat das Konfigurationswerkzeug alle Gerätedateien aller angeschlossenen Peripheriegeräte wie beschrieben empfangen, kann die reguläre Konfiguration wie in der obigen Telegrammreihenfolge aufgeführt mit Punkt 4 fortgeführt werden. Für die hier erläuterte bevorzugte Ausführungsform des vorgeschlagenen Verfahrens ist es notwendig, daß das Konfigurationswerkzeug Zugriff auf den DP-Master, also eine Host-Einheit, hat, um die empfangenen Daten vom Master abzugreifen, als GSD-Datei zusammenzusetzen und geeignet abzuspeichern.
2. Für alle Peripheriegeräte im Sinne der Erfindung führt der Systemingenieur eine spezielle allgemeingültige GSD-Datei aus. Diese Datei beschreibt das DP-Peripheriegerät normgerecht als DP-Teilnehmer, jedoch speziell nur für den Zweck des Ladens der Gerätedatei. Insbesondere ist für solche Peripheriegeräte eine solche Identifikationsnummer vorgesehen. Auf Basis dieser speziellen GSD-Datei erstellt der Systemingenieur eine Konfiguration, die nur solche Teilnehmer enthält, von denen die "regulären" GSD- Dateien fehlen. Das Peripheriegerät erkennt in der Diagnoseanforderung die Identifikationsnummer. Dadurch wird im Peripheriegerät nun die Konfigurationsmeldeeinheit 58 aktiviert. In diesem Zustand liefert das Peripheriegerät dann statt der wirklichen E/A- Daten den Inhalt der gespeicherten Gerätedatei. Diese ist in dem Gerätedateispeicher 55 abgelegt und wird über den internen Bus 51 des Peripheriegerätes an eine Schnittstelle 52 und von da an den Kommunikationskanal 53 zur Host-Einheit, in diesem Fall einem Feldbus, übermittelt. Auch in diesem Fall ist es wie unter 1. bereits beschrieben möglich, die Gerätedatei in mehreren Teilen segmentiert zu übertragen. Die weiteren Konfigurationsschritte folgen wiederum wie bereits unter 1. erläutert, das heißt nach der vollständigen korrekten Übertragung wird die Konfigurationsmeldeeinheit 58 deaktiviert, das Peripheriegerät wechselt in den Anfangszustand und das Konfigurationswerkzeug kann für eine folgende reguläre Konfiguration eingesetzt werden.
3. Es ist auch möglich, daß das Konfigurationswerkzeug über einen Klasse-2-Master, also einem Klasse-1-Master neben oder untergeordnete Host-Einheit, direkt auf den Profibus-DP-Strang zugreift. Dabei wird die Möglichkeit der Kommunikation zwischen einem Klasse-2-Master und einem DP-Peripheriegerät genutzt. Mit den Klasse-2- Funktionen sind Schreibe- und Lesezugriffe auf DP-Peripheriegeräte auch bei gleichzeitigem Betrieb des DP-Busses mit einem Klasse-1-Master möglich. Damit kann eine Gerätedatei wie unter 1. oder 2, mittels Klasse-2-Funktionen aus einem Peripheriegerät geladen werden. Eine entsprechende Kommunikation kann entweder über die bereits erwähnte Schnittstelle 52 und einen daran angeschlossenen Kommunikationskanal zu einem Klasse-1-Master über einen Feldbus 53 erfolgen. Es könnte jedoch auch eine Kommunikation über eine Peripherie Ein/Ausgabeinheit 57 und einen daran angeschlossenen weiteren Bus 57a mit einem Klasse-2-Master erfolgen.
4. Weiterhin kann es notwendig sein, ein Peripheriegerät direkt mit einer Host-Einheit zu verbinden. Dies kann über eine zusätzliche Verbindung an der Schnittstelle 52, welche beispielsweise als serielle Schnittstellenverbindung ausgelegt sein kann, am Peripheriegerät erfolgen. Über eine solche serielle Schnittstellenverbindung 54 würde die Gerätedatei unmittelbar an eine Host-Einheit übertragen werden können. Ein Betrieb am eigentlichen Profibus-DP-Bus 53 ist dazu nicht notwendig. Durch Ansprache der zusätzlichen Schnittstellenverbindung 54 wird die Konfigurationsmeldeeinheit 58 aktiviert. Damit kann das Konfigurationswerkzeug die Gerätedatei auslesen und lokal zur weiteren Nutzung speichern. Nach der vollständigen und korrekten Übertragung wird die Konfigurationsmeldeeinheit 58 deaktiviert. Hat das Konfigurationswerkzeug alle Gerätedateien aller angeschlossenen Peripheriegeräte wie beschrieben empfangen, kann wiederum die reguläre Profibus-DP-Konfiguration entsprechend Punkt 4 der oben angegebenen Telegrammreihenfolge durchgeführt werden.

Die oben genannten vier Beispiele wurden anhand des DP-Busses erläutert, könnten aber ebenso auf andere Bus-Systeme übertragen werden. Bezugszeichenliste 11 Host-Einheit
13 Feld-Bus
14a, 14b, 14c Peripheriegerät
22 Konfigurationswerkzeug
50 Peripheriegerät
53 Feld-Bus
54 Schnittstelle
55 Gerätedatei
56 Prozessoreinheit
58 Konfigurationsmeldeeinheit
59 Datenspeicher

Claims

1. Verfahren zum Betrieb eines Peripheriegeräts (14a, 14b, 14c, 50) mittels einer Host- Einheit (11), bei dem das Peripheriegerät (14a, 14b, 14c, 50) von der Host-Einheit (11) erkannt, konfiguriert und/oder betrieben wird, dadurch gekennzeichnet, daß für die Konfiguration des Peripheriegeräts (14a, 14b, 14c, 50) eine das Peripheriegerät (14a, 14b, 14c, 50) beschreibende Gerätedatei (55) der Host-Einheit (11) von dem Peripheriegerät (14a, 14b, 14c, 50) zur Verfügung gestellt wird.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die Gerätedatei (55) aus dem Peripheriegerät (14a, 14b, 14c, 50) in ein Konfigurationswerkzeug (22) aufgenommen wird.

3. Verfahren nach Anspruch 2, bei dem das Konfigurationswerkzeug (22) ein Software- Modul aufweist, in das die Gerätedatei (55) geladen wird.

4. Verfahren nach Anspruch 2, dadurch gekennzeichnet, daß das Konfigurationswerkzeug (22) Teil der Host-Einheit (11) ist, insbesondere eine Prozessor-Einheit und/oder einen Speicher aufweist.

5. Verfahren nach Anspruch 2, dadurch gekennzeichnet, daß das Konfigurationswerkzeug (22) auf einen Bus (13) zugreift, das Peripheriegerät (14a, 14b, 14c, 50) mit gespeicherter Gerätedatei (55) erkannt wird, das Peripheriegerät (14a, 14b, 14c, 50) aus dem Anfangszustand in einen Datenaustauschzustand versetzt wird, die Gerätedatei (55) vom Peripheriegerät (14a, 14b, 14c, 50) zum Konfigurationswerkzeug (22), insbesondere zur Host- Einheit (11), übertragen wird und das Peripheriegerät (14a, 14b, 14c, 50) in den Anfangszustand versetzt wird.

6. Verfahren nach Anspruch 5, dadurch gekennzeichnet, daß das Konfigurationswerkzeug (22) für den Datenaustausch im Peripheriegerät (14a, 14b, 14c, 50) eine Konfigurationsmeldeeinheit (58) aktiviert und/oder deaktiviert.

7. Verfahren nach Anspruch 5, dadurch gekennzeichnet, daß, nachdem das Peripheriegerät (14a, 14b, 14c, 50) im Anfangszustand ist, eine Konfiguration des Peripheriegeräts (14a, 14b, 14c, 50) erfolgt.

8. Verfahren nach Anspruch 5, dadurch gekennzeichnet, daß die Gerätedatei (55) segmentiert übertragen wird.

9. Verfahren nach Anspruch 5. dadurch gekennzeichnet, daß ein Peripheriegerät (14a, 14b, 14c, 50), für das keine Gerätedatei der Host-Einheit (11) zur Verfügung steht, erkannt wird, insbesondere in einen Datenaustauschzustand versetzt wird.

10. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß das Peripheriegerät (14a, 14b, 14c, 50) durch eine Allgemein-Gerätedatei vorinitialisiert wird, um die Gerätedatei (55) von dem Peripheriegerät (14a, 14b, 14c, 50) der Host-Einheit (11) zur Verfügung zu stellen.

11. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die Gerätedatei (55) von dem Peripheriegerät (14a, 14b, 14c, 50) einer Klasse-2-Host-Einheit zur Verfügung gestellt wird.

12. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die Gerätedatei (55) von dem Peripheriegerät (14a, 14b, 14c, 50) der Host-Einheit (11) über einen Feld-Bus (13, 53) zur Verfügung gestellt wird.

13. Verfahren nach Anspruch 1 bis 11, dadurch gekennzeichnet, daß die Gerätedatei (55) von dem Peripheriegerät (14a, 14b, 14c, 50) der Host-Einheit (11) unter Umgehung des Feld- Busses (53) direkt (54) zur Verfügung gestellt wird.

14. Betriebseinheit, aufweisend eine Host-Einheit (11) und ein daran angeschlossenes Peripheriegerät (14a, 14b, 14c, 50), bei dem das Peripheriegerät (14a, 14b, 14c, 50) von der Host-Einheit (11) erkennbar, konfigurierbar und/oder betreibbar ist, dadurch gekennzeichnet, daß das Peripheriegerät (14a, 14b, 14c, 50) eine für eine Konfiguration des Peripheriegeräts (14a, 14b, 14c, 50) verwendbare und eine das Peripheriegerät (14a, 14b, 14c, 50) beschreibende Gerätedatei (55) aufweist, welche auf dem Peripheriegerät (14a, 14b, 14c, 50) der Host-Einheit (11) zur Verfügung gestellt ist.

15. Betriebseinheit nach Anspruch 14, gekennzeichnet durch eine Klasse-2-Host-Einheit, der die Gerätedatei (55) auf dem Peripheriegerät (14a, 14b, 14c, 50) zur Verfügung gestellt ist.

16. Betriebseinheit nach Anspruch 14, dadurch gekennzeichnet, daß die Gerätedatei (55) auf dem Peripheriegerät (14a, 14b, 14c, 50) der Host-Einheit (11) über einen Feld-Bus (13, 53) zur Verfügung gestellt ist.

17. Betriebseinheit nach Anspruch 14, dadurch gekennzeichnet, daß die Gerätedatei (55) auf dem Peripheriegerät (14a, 14b, 14c, 50) der Host-Einheit (11) über eine zusätzliche Schnittstelle (54) unter Umgehung eines Feld-Busses (13, 53) direkt zur Verfügung gestellt ist.

18. Betriebseinheit nach einem der Ansprüche 14 bis 17, gekennzeichnet durch ein Konfigurationswerkzeug (22) zur Aufnahme der Gerätedatei (55).

19. Betriebseinheit nach einem der Ansprüche 14 bis 18, dadurch gekennzeichnet, daß das Peripheriegerät (14a, 14b, 14c, 50) eine Konfigurationsmeldeeinheit (58), insbesondere einen als Konfigurationsmeldeeinheit (58) ausgebildeten Software-Baustein, aufweist.

20. Betriebseinheit nach einem der Ansprüche 14 bis 19, gekennzeichnet durch Auslegungsmerkmale einer speicherprogrammierbaren Steuerung.

21. Betriebseinheit nach einem der Ansprüche 14 bis 19, gekennzeichnet durch Auslegungsmerkmale eines PC-Systems.

22. Peripheriegerät (50), aufweisend eine Schnittstelleneinheit (54) zur Bereitstellung eines Kommunikationskanals zu einer Host-Einheit (11), gekennzeichnet durch einen Gerätespeicher (55) und eine Konfigurationsmeldeeinheit (58), die für einen Datenaustausch mit der Host-Einheit (11) aktivierbar ist.

23. Peripheriegerät (50) nach Anspruch 22, dadurch gekennzeichnet, daß die Konfigurationsmeldeeinheit (58) nach dem Datenaustausch deaktivierbar ist.

24. Peripheriegerät (50) nach Anspruch 22 oder 23, gekennzeichnet durch eine Prozessor- Einheit (56), eine Peripherie-Schnittstelleneinheit (57) zur Bereitstellung eines Kommunikationskanals zur Peripherie und einen weiteren Datenspeicher (59).

25. Peripheriegerät (50) nach einem der Ansprüche 22 bis 24, dadurch gekennzeichnet, daß der Gerätespeicher (55) eine das Peripheriegerät beschreibende Gerätedatei aufweist, welche mittels der Konfigurationseinheit (58) der Host-Einheit (11) zur Verfügung gestellt ist.

26. Peripheriegerät (14a, 14b, 14c, 50), insbesondere ein Peripheriegerät (50) nach einem der Ansprüche 22 bis 25, das von einer Host-Einheit (11) erkennbar, konfigurierbar und/oder betreibbar ist, gekennzeichnet durch eine für eine Konfiguration des Peripheriegeräts (14a, 14b, 14c, 50) verwendbare und eine das Peripheriegerät (14a, 14b, 14c, 50) beschreibende Gerätedatei, welche auf dem Peripheriegerät (14a, 14b, 14c, 50) der Host-Einheit (11) zur Verfügung gestellt ist.