DE10131530A1

DE10131530A1 - Doppelmodus-Foundation Fieldbus-Gerätekonfigurator

Info

Publication number: DE10131530A1
Application number: DE10131530A
Authority: DE
Inventors: Deji Chen; Steve Bonwell; Dan Christensen; Deeann Delguzzi; Neil Peterson; Ram Ramachandran
Original assignee: Fisher Rosemount Systems Inc
Current assignee: Fisher Rosemount Systems Inc
Priority date: 2000-06-30
Filing date: 2001-06-29
Publication date: 2002-07-11
Anticipated expiration: 2021-06-30
Also published as: US6947389B1; JP4834245B2; JP2002118579A; GB0115976D0; HK1063080A1; GB2365147B; GB2365147A; DE10131530B4

Abstract

Ein Doppelmodus-Konfigurator (20) arbeitet im Offlinemodus, um Fieldbus-Geräte (13, 14) und/oder Segmente (10) auf eine typische Weise zu konfigurieren, und im Onlinemodus, um bestimmte Parameter eines Geräts (13, 14) neu zu konfigurieren oder einzustellen, wenn das Gerät (13, 14) mit einem von einem anderen Host gesteuerten Segment (10) verbunden ist, ohne den Onlinebetrieb des Segments (10) zu stören. Der Doppelmodus-Konfigurator (20) kann zur Konfigurierung eines gesamten Segments (10) verwendet werden, indem sowohl Netzwerkeinstellungen als auch Geräteeinstellungen konfiguriert werden, und alternativ zur Konfigurierung von Geräteeinstellungen, ohne einen Einfluss auf die Online-Systemkonfigurationsinformationen, wie die Netzwerkeinstellungen eines Segments (10), auszuüben oder diese zu stören, wenn beispielsweise ein anderes Hostgerät oder Konfigurationsgerät an das Segment (10) angeschlossen wird, um Prozesssteuerungsaktivitäten zu implementieren oder Segmentänderungen vorzunehmen.

Description

DOPPELMODUS-FOUNDATION FIELDBUS-GERÄTEKONFIGURATOR ANWENDUNGSBEREICH DER ERFINDUNG

Die vorliegende Erfindung betrifft allgemein Gerätekonfigura toren zur Verwendung in Prozesssteuerungsnetzwerken und ins besondere einen Foundation Fieldbus-Gerätekonfigurator, der in der Lage ist, Geräte in einen Prozesssteuerungsnetzwerk zu konfigurieren.

BESCHREIBUNG DER ZUGEHÖRIGEN TECHNIK

Große Prozesse wie chemische Prozesse, Erdöl verarbeitende Prozesse sowie andere Herstellungs- und Raffinierungsprozesse enthalten typischerweise zahlreiche Fieldgeräte, die an ver schiedenen Stellen in einer Anlage zur Messung und Steuerung von Prozessparametern angeordnet sind, um so die Steuerung ei nes Prozesses zu bewirken. Diese Fieldgeräte, bei denen es sich beispielsweise um Sensoren wie Temperatur-, Druck- und Durchflusssensoren sowie Steuerelemente wie Ventile und Schal ter handeln kann, sind typischerweise mit einer oder mehreren Steuerungen oder Hostgeräten verbunden, die den Betrieb der Fieldgeräte steuern, um so die Prozesssteuerung zu implemen tieren.

Wie bekannt ist, gibt es zahlreiche offene Standard-Kommunika tionsprotokolle, z. B. die HART®, PROFIBUS®, WORLDFIP®, LON- WORKS®, Device-Net® und CAN-Protokolle, die es ermöglichen, dass Fieldgeräte verschiedener Hersteller innerhalb der glei chen Schleife der Prozesssteuerung verwendet werden. In der Tat kann jedes einem dieser Protokolle entsprechende Field gerät innerhalb eines Prozesses verwendet werden, um mit einer Steuerung, die das Protokoll unterstützt, zu kommunizieren und von dieser gesteuert zu werden, selbst dann, wenn das betref fende Fieldgerät von einem anderen Hersteller als die Steue rung stammt. Das FOUNDATION™ Fieldbus-Protokoll (im Folgenden "Fieldbus-Protokoll") bietet oder ermöglicht eine hoch dezen trale Steuerung, indem es Prozesssteuergeräte wie Ventilstel lungsregler, Sender etc. eine oder mehrere Prozesssteuerfunk tionen ausführen und sie dann Daten über eine Busstruktur zur Verwendung durch andere Prozesssteuergeräte austauschen lässt. Zur Implementierung dieser Steuerfunktionen enthält jedes Pro zesssteuergerät einen Mikroprozessor mit der Fähigkeit, eine oder mehrere Basissteuerfunktionen, die als Funktionsblöcke bezeichnet werden, auszuführen oder zu implementieren, sowie die Fähigkeit, mit anderen das Fieldbus-Kommunikationsproto koll verwendenden Prozesssteuergeräten zu kommunizieren. Auf diese Weise können Fieldgeräte verschiedener Hersteller inner halb einer Prozesssteuerungsschleife miteinander verbunden werden, um miteinander zu kommunizieren und um eine oder, meh rere Prozesssteuerfunktionen oder Steuerschleifen auszuführen.

In einem Fieldbus-Protokoll ist ein Fieldbus-Segment eine Ba siseinheit der Netzwerkkonfiguration und, allgemein gesagt, sind einige Fieldbus-Geräte mit einem jeden solchen Segment verbunden. Zur Konfigurierung eines Segments wird ein Field bus-Konfigurator, bei dem es sich um ein Hostgerät, eine Steuerung oder ein unabhängiges Gerät handeln kann, mit dem Segment verbunden, so dass es mit jedem der Geräte des Seg ments kommuniziert, um jedes der Geräte so zu konfigurieren, dass diese Geräte während der Laufzeit eine koordinierte und sinnvolle Prozesssteuerung ausführen. Während dieses Konfi gurierungsprozesses ordnet der Konfigurator jedem Gerät ein Geräteidentifizierungskennzeichen und eine Geräteadresse auf dem Segment zu, legt die Kommunikationsbeziehungen mit den während des Betriebs des Segments zu verwendenden Geräten fest, plant die Operation der Funktionsblöcke innerhalb der Geräte, plant die Kommunikation zwischen Geräten, konfiguriert Alarme und Trends, die zum Operator oder zu anderen Geräten zu senden sind, stellt anwenderseitige Anwendungsblockparameter und stellt andere Netzwerkparameter ein. Falls gewünscht, kann der Fieldbus-Konfigurator ein Hostgerät sein, dass einen Teil der Prozesssteuerung ausführt, oder er kann ein temporäres Ge rät sein, das zum Aufbau des Segments angeschlossen und nach der Konfigurierung des Segments wieder getrennt wird.

Bekannte Fieldbus-Konfiguratoren jedoch übernehmen die Steue rung eines Segments, um Geräte- und Netzwerkkonfigurations aktivitäten auszuführen. Tatsächlich sind diese Geräte norma lerweise so programmiert, dass sie zumindest für die Dauer, in der der Konfigurator die Konfigurierung des Segments vornimmt, ein primärer Link Active Scheduler (LAS) werden. Als Ergebnis ist es unumgänglich, dass immer nur ein Fieldbus-Konfigurator mit dem gleichen Segment verbunden ist, um das Segment erfolg reich zu konfigurieren, obwohl andere Überwachungsgeräte mit dem Segment verbunden sein können, die das Segment nicht stö ren. Selbst wenn der Konfigurator kein LAS ist, kann eine Un terbrechung aufgrund fehlender Koordinierung zwischen dem Kon figurator und der Kommunikationskonfigurierung eintreten. Ty pischerweise ist diese Einschränkung bei der Konfigurierung eines gesamten Segments kein Problem. Es gibt jedoch Situa tionen, wo es wünschenswert ist, ein Gerät neu zu konfigurie ren oder mit diesem zu kommunizieren, das sich auf einem Seg ment befindet, das bereits einen primären LAS hat, der das Segment steuert, ohne andere Geräte oder Einstellungen des Segments einschließlich der Netzwerkeinstellungen zu stören. Solche Situationen können beispielsweise eintreten, wenn ein Operator ein Segment fern überwacht und ein Fieldgerät kali briert werden muss, oder wenn ein Service-Ingenieur die physi kalische Umgebung zur erfolgreichen Kalibrierung eines Geräts sehen und deshalb zum Gerät gehen und dieses ohne Verwendung des Host kalibrieren muss. In diesen Fällen braucht der Ser vice-Ingenieur einen Gerätekonfigurator, der sich im Feld leicht an das Segment in der Nähe des Geräts anschließen lässt, um einen oder mehrere Geräteparameter zu konfigurieren, ohne dass der Konfigurator die Steuerung der Kommunikationen auf dem Segment übernimmt und ohne die Online-Systemkonfigura tionsinformationen des Segments oder die Kommunikationen auf dem Segment zu stören.

Wie oben erwähnt, können herkömmliche Fieldbus-Konfiguratoren nur zum Reseten von Geräteparametern in einem Segment ver wendet werden, wenn die Verbindung des Konfigurators mit dem Segment mit Sicherheit keine Unterbrechung der Steuerungs schleifen im Segment verursacht. Die DeltaV Fieldbus-Steuerung z. B. weist einem bei einer Standardadresse erscheinenden Gerät automatisch eine Adresse von OxFB bis OxFB zu. OxF8 bis OxFB sind Adressen, die von einem Hostgerät (LAS), welches das Seg ment steuert, verwaltet werden. Aus genau diesem Grund kann beim Verbinden des DeltaV-Konfigurators mit dem Segment zum Reseten bestimmter Geräteparameter während das Segment online arbeitet, das Hostgerät oder der LAS die Kommunikation mit dem betreffenden Gerät verlieren, was die Prozesssteuerungsschlei fen, die im Segment arbeiten, unterbricht. Das Verbinden des DeltaV-Konfigurators mit einem Online-Segment wird typischer weise außerdem zahlreiche andere miteinander in Konflikt ste hende Probleme hervorbringen.

Andererseits gibt es Situationen, in denen es wünschenswert ist, die Netzwerkeinstellungen zu ändern, und in denen solche Einstellungsänderungen keinen Einfluss auf die Konfiguration eines Netzwerks haben. Muss beispielsweise ein Hersteller ein Fieldbus-Gerät vorkonfigurieren, bevor er es ausliefert, kann das Gerät an einen Konfigurator angeschlossen werden, der das Geräteidentifizierungskennzeichen auf die übliche Weise ein stellt. Da hier noch kein arbeitendes Netzwerk beteiligt ist, sind die Netzwerkeinstellungen des Geräts nicht von Bedeutung.

ZUSAMMENFASSUNG DER ERFINDUNG

Die vorliegende Erfindung ist auf einen Doppelmodus- Gerätekonfigurator gerichtet, der in einem Offlinemodus zur Konfigurierung von Geräten und/oder Segmenten und in einem On linemodus zum Neu-Konfigurieren oder Einstellen von Parametern eines Geräts, wenn dieses Gerät mit einem Segment mit einem darin arbeitenden Host oder LAS verbunden ist, arbeiten kann. Bei Verwendung des Doppelmodus-Gerätekonfigurators wie hierin beschrieben kann ein Anwender oder Ingenieur ein und dasselbe Gerät verwenden, um im ersten Fall ein gesamtes Segment zu konfigurieren und im zweiten Fall, um Geräteeinstellungen zu konfigurieren, ohne die Netzwerkeinstellungen eines Segments zu beeinflussen oder zu stören, wenn das Segment zur Imple mentierung von Prozesssteuerungsaktivitäten verwendet wird, die von einem anderen Host oder LAS gesteuert werden.

Gemäß einem Aspekt der vorliegenden Erfindung enthält ein Dop pelmodus-Gerätekonfigurator einen Prozessor, einen Speicher, einen ersten Satz von Routinen, die im Speicher abgelegt und so konzipiert sind, dass sie auf dem Prozessor zur Ausführung von Netzwerkkonfigurationsänderungen ausgeführt werden, und einen zweiten Satz von Routinen, die im Speicher abgelegt und so konzipiert sind, dass sie auf dem Prozessor zur Ausführung von Gerätekonfigurationsänderungen ohne dabei Netzwerkkonfigu rationsänderungen herbeizuführen, ausgeführt werden. Der Ge rätekonfigurator enthält auch einen Modusschalter, der zwi schen einem ersten und zweiten Modus umgeschaltet werden, kann, und eine Konfigurationsroutine zum Starten einer Routine aus dem ersten Satz von Routinen oder einer Routine aus dem zwei ten Satz von Routinen, wenn der Modusschalter auf den ersten Modus gestellt ist, um dadurch das Netzwerk zu konfigurieren, und zum Starten einer Routine aus dem zweiten Satz von Routi nen aber nicht aus dem ersten Satz von Routinen, wenn der Mo dusschalter auf den zweiten Modus gestellt ist.

Das Konfigurationsgerät kann einen Kommunikationsstapel zur Kommunikation über das Segment unter Verwendung des Fieldbus- Protokolls und ferner eine Kommunikationsroutine zur Herstel lung einer Kommunikationsverbindung mit einem Fieldbus-Gerät auf dem Segment enthalten, ohne Kommunikationsverbindungen, die von anderen Geräten mit dem Fieldbus-Gerät hergestellt wurden, zu stören. In diesem Fall kann die Kommunikationsrou tine einen ersten Abschnitt enthalten, der virtuelle Eingänge der Kommunikationsbeziehungen (virtual communication relation ship - VCR) wählt, die zur Verwendung im Fieldbus-Gerät zur Verfügung stehen, einen zweiten Abschnitt, der einen der ver wendbaren VCR-Eingänge wählt, einen dritten Abschnitt, der die Kommunikationsverbindung unter Verwendung des gewählten VCR- Eingangs herstellt und einen vierten Abschnitt, der bestimmt, ob die den gewählten VCR-Eingang verwendende Kommunikations verbindung unterbrochen ist, und falls ja, die Operation des ersten, zweiten und dritten Abschnitts der Kommunikationsrou tine veranlasst, um eine neue Kommunikationsverbindung mit dem Fieldbus-Gerät herzustellen.

Falls gewünscht, kann der erste Satz von Routinen mindestens eine Routine zum Zuordnen eines Geräteidentifizierungskennzei chens, eine Routine zum Zuordnen einer Geräteadresse, eine Planungsroutine für die Funktionsblöcke und eine Routine zum Herunterladen eines Kommunikationsplanes enthalten, während der zweite Satz von Routinen mindestens eine Routine zur Ände rung der Gerätekonfiguration, eine Routine zum Modifizieren des Ressourcenblocks, eine Routine zum Modifizieren des Mess wertgeberblocks und eine Routine zum Modifizieren der Funkti onsblöcke enthalten kann.

Das Konfigurationsgerät kann auch eine Anzeige und eine wei tere Routine enthalten, die Konfigurationsinformationen des Fieldbus-Geräts auf dem Segment bestimmt und über die Anzeige darstellt, und die über die Anzeige eine Liste der aktuell mit dem Segment verbundenen Geräte liefert. Außerdem kann das Kon figurationsgerät eine erste Routine "Unzutreffender Modus" enthalten, die bei Einstellen des Modusschalters auf den ers ten Modus bestimmt, ob kein Gerät auf dem Segment ist, und falls kein Gerät auf dem Segment ist, den Start einer Routine aus der ersten Menge Routinen verhindert. Das Konfigurations gerät kann auch eine zweite Routine "Unzutreffender Modus" enthalten, die bei Einstellen des Modusschalters auf den ers ten Modus eine Menge vorgegebener Geräteadressen in Zusammen hang mit Hostgeräten auf dem Segment durchsucht und den Anwen der vor einem möglichen Fehler warnt, wenn sich ein Gerät an einer der vorgegebenen Geräteadressen befindet.

KURZE BESCHREIBUNG DER ZEICHNUNGEN

Fig. 1 ist eine schematisches Blockdiagramm eines beispiel haften Prozesssteuerungssegments unter Verwendung des Field bus-Protokolls;

Fig. 2 ist ein Blockdiagramm eines Beispiels für einen Zwei modus-Gerätekonfigurator, der für das Segment von Fig. 1 ver wendet werden kann;

Fig. 3 ist ein Blockdiagramm einer Kommunikationshierarchie, die innerhalb eines typischen Foundation Fieldbus-Geräts ver wendet wird; und

Fig. 4 ist ein Flussdiagramm der Schritte des Gerätekonfigura tors von Fig. 2 zur Herstellung und zur Aufrechterhaltung nicht störender Kommunikationen mit einem Gerät in einem Fieldbus-Segment.

BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGFORMEN

Während ein Geräte-/Netzwerkkonfigurator detailliert in Zusam menhang mit einem Prozesssteuerungsnetzwerk beschrieben wird, welches Prozesssteuerfunktionen auf eine dezentrale oder ver teilte Weise unter Verwendung des Fieldbus-Protokolls ein setzt, ist darauf hinzuweisen, dass der hierin beschriebene Gerätekonfigurator mit Prozesssteuerungsnetzwerken verwendet werden kann, welche Steuerfunktionen unter Verwendung anderer Typen Fieldgeräte oder busbasierter Kommunikationsprotokolle einsetzen, einschließlich solcher Protokolle, die sich auf an dere als Zweileitungsbusse stützen und Protokolle, die sowohl analoge als auch digitale Kommunikationen unterstützen.

Wie aus Fig. 1 ersichtlich ist, enthält ein Segment 10 eines Prozesssteuerungsnetzwerks, welches das Fieldbus-Kommunika tionsprotokoll verwendet, einen Zweileitungsbus 12, der mit zahlreichen Fieldgeräten 13 und 14 verbunden ist. Ein typi scher oder standardmäßiger Fieldbus-Konfigurator 16 und ein Geräte-/Netzwerkkonfigurator 20, die nachstehend detaillierter beschrieben werden, sind ebenfalls mit dem Bus 12 verbunden. Die Fieldgeräte 13 und 14 können von jedem beliebigen Typ Fieldbus-Geräte sein, während der Fieldbus-Konfigurator 16 je der standardmäßige oder vorhandene Konfigurator sein kann, der mit dem Bus 12 zum Konfigurieren des Segments 10 unter Anwen dung des Fieldbus-Protokolls verbunden werden kann. Falls ge wünscht, können mehr oder andere Geräte mit dem Bus 12 verbun den werden, einschließlich beispielsweise andere Fieldgeräte, eine Steuerung, Hostgeräte etc.

Vor der Erörterung der Einzelheiten des Geräte-/Netzwerkkonfi gurators 20, der zur Konfigurierung des Fieldbus-Segments 10 oder von Geräten auf dem Segment 10 sowohl im Online- als auch im Offline-Modus verwendet werden kann, wird eine allgemeine Beschreibung des Fieldbus-Protokolls, der gemäß diesem Proto koll konfigurierten Fieldgeräte und der Art und Weise, in der Kommunikation und Prozesssteuerung in einem Prozesssteuerungs netzwerk, das das Fieldbus-Protokoll verwendet, ablaufen, ge geben. Obwohl das Fieldbus-Protokoll ein relativ neues digi tales Kommunikationsprotokoll ist, welches zur Verwendung in Prozesssteuerungsnetzwerken entwickelt worden ist, versteht es sich, dass dieses Protokoll im Stand der Technik bekannt ist und detailliert in zahlreichen veröffentlichten Artikeln, Bro schüren und Beschreibungen beschrieben wird, die u. a. von der Fieldbus Foundation, einer Organisation ohne Erwerbscharakter mit Sitz in Austin, Texas, verteilt werden und dort erhältlich sind. Insbesondere das Fieldbus-Protokoll und die Weise der Kommunikation mit und der Speicherung von Daten in Geräten, die das Fieldbus-Protokoll verwenden, werden detailliert in Handbüchern mit dem Titel "Communications Technical Specifica tion" und "User Layer Technical Specification" der Fieldbus Foundation beschrieben, die hiermit in ihrer Gesamtheit aus drücklich einbezogen werden.

Allgemein gesagt ist das Fieldbus-Protokoll ein voll digita les, serielles Zweiwege-Kommunikationsprotokoll, das eine standardisierte physikalische Schnittstelle für eine Zweilei tungs-Schleife oder einen Zweileitungs-Bus bereitstellt, der "Field"-Ausrüstung wie Sensoren, Aktuatoren, Regler, Ventile etc. einer Instrumentierungs- oder Prozesssteuerungsumgebung für z. B. eine Fabrik oder eine Anlage miteinander verbindet. Das Fieldbus-Protokoll stellt praktisch ein lokales Netzwerk für Fieldinstrumente (Fieldgeräte) innerhalb einer Prozessan lage bereit, das es diesen Fieldgeräten ermöglicht, Steuer funktionen an Stellen auszuführen, die über einen Prozess ver teilt sind, und miteinander vor und nach der Ausführung dieser Steuerfunktionen zu kommunizieren, um eine Gesamtsteuerungs strategie zu implementieren. Da das Fieldbus-Protokoll er möglicht, die Steuerfunktionen über ein Prozesssteuerungs netzwerk zu verteilen, verringert es die Komplexität einer zentralen Prozesssteuerung oder macht diese insgesamt über flüssig.

Typischerweise ist ein Konfigurator wie der Konfigurator 16 von Fig. 1 in einem der mit einem Fieldbus-Segment verbundenen Geräte angeordnet, z. B. einem Hostgerät, und ist für den Auf bau oder die Konfigurierung jedes der Geräte verantwortlich (bei denen es sich um "intelligente" Geräte handelt, da jedes einen Mikroprozessor enthält, der in der Lage ist, Kommu nikation und in manchen Fällen Steuerfunktionen auszuführen) sowie für die Erkennung, wenn neue Fieldgeräte an den Bus an geschlossen werden, wenn Fieldgeräte vom Bus entfernt werden, für den Empfang von den Fieldgeräten erzeugten Daten und für den Datenaustausch mit einem oder mehreren Anwenderendgeräten, die in einem Host oder einem anderen mit dem Host auf beliebi ge Weise verbundenen Gerät untergebracht sein können.

Der Fieldbus-Bus 12 unterstützt oder gestattet die rein digi tale Zweiwege-Kommunikation und kann auch ein Spannungssignal an jedes oder alle der Geräte z. B. an die Fieldgeräte 13 und 14 liefern. Alternativ kann bzw. können jedes oder alle der Geräte ihre eigene Spannungsversorgung haben oder über ge trennte Leitungen (nicht dargestellt) mit externen Spannungs versorgungen verbunden sein. Das Fieldbus-Protokoll teilt die Geräte, die mit dem Bus 12 verbunden werden können, in drei Kategorien ein, nämlich in Basisgeräte, in Link-Master-Geräte und in Brückengeräte. Basisgeräte können kommunizieren, d. h. Kommunikationssignale zum Bus senden und von diesem empfangen, sind aber nicht in der Lage, die zeitliche Reihenfolge der auf dem Bus stattfindenden Kommunikation zu steuern. Link-Master- Geräte sind Geräte, die über den Bus kommunizieren und in der Lage sind, den Fluss und die zeitliche Abfolge der Kommunika tionssignale auf dem Bus zu steuern. Brückengeräte sind Gerä te, die zur Kommunikation und Verbindung mit den einzelnen Segmenten oder Zweigen eines Fieldbus-Busses untereinander und zur Schaffung größerer Prozesssteuerungsnetzwerke konfiguriert sind.

Jedes der Geräte auf dem Segment kann über den Bus kommunizie ren und unabhängig eine oder mehrere Prozesssteuerfunktionen mittels der vom Gerät, vom Prozess oder von einem anderen Ge rät über Kommunikationssignale auf dem Bus erworbenen Daten ausführen. Fieldbus-Geräte sind deshalb in der Lage, direkt Teile einer Gesamtsteuerungsstrategie zu implementieren, die in der Vergangenheit von einer zentralen Steuerung ausgeführt wurden. Zur Ausführung von Steuerfunktionen enthält jedes Fieldbus-Gerät einen oder mehrere standardisierte "Blöcke", die in einem Mikroprozessor im Gerät implementiert sind. Ins besondere enthält jedes Fieldbus-Gerät einen Ressourcenblock, keinen oder mehrere Funktionsblöcke und keinen oder mehrere Messwertgeberblöcke. Diese Blöcke werden als Blockobjekte be zeichnet.

Ein Ressourcenblock speichert und kommuniziert gerätespezifi sche Daten in Zusammenhang mit einigen Merkmalen eines Field bus-Geräts einschließlich z. B. eines Gerätetyps, einer Angabe bezüglich einer Geräterevision und Angaben, wo andere geräte spezifische Informationen in einem Speicher des Geräts erhal ten werden können. Obwohl verschiedene Gerätehersteller ver schiedene Datentypen im Ressourcenblock eines Fieldgeräts speichern können, enthält jedes dem Fieldbus-Protokoll ent sprechende Fieldgerät einen Ressourcenblock, der einige Daten speichert.

Ein Funktionsblock definiert und implementiert eine zum Field gerät gehörige Eingangsfunktion, Ausgangsfunktion oder Steuer funktion, so dass Funktionsblöcke allgemein als Eingangs-, Ausgangs- und Steuerfunktionsblöcke bezeichnet werden. Es kön nen jedoch auch andere Kategorien von Funktionsblöcken wie Hy bridblöcke vorkommen oder in Zukunft entwickelt werden. Jeder Eingangs- oder Ausgangsfunktionsblock erzeugt mindestens einen Prozesssteuereingang (wie eine Prozessvariable von einem Pro zessmessgerät) oder einen Prozesssteuerausgang (wie eine Ven tilstellung, die an ein Stellgerät geschickt wird), während jeder Steuerfunktionsblock einen Algorithmus verwendet (der proprietär sein kann), um einen oder mehrere Prozessausgänge aus einem oder mehreren Prozesseinängen und Steuereingängen zu erzeugen. Beispiele für Standardfunktionsblöcke sind die Funk tionsblöcke Analogeingang (analog input AI), Analogausgang (analog output AO), Bias (B), Steuerungswähler (control selec tor CS), diskreter Eingang (discrete input DI), diskreter Aus gang (discrete output DO), manueller Lader (manual loader ML), proportional/differenzierend (PD), proportional/integral/dif ferenzierend (PID), Verhältnis (ratio RA) und Signalselektor (55). Es gibt jedoch auch andere Typen von Funktionsblöcken und neue Funktionsblöcke können definiert oder geschaffen wer den, um in der Fieldbus-Umgebung zu arbeiten. Während das Fieldbus-Protokoll Funktionsblöcke auf eine bestimmte Weise definiert, ist der Begriff Funktionsblock wie hierin verwendet nicht eingeschränkt und gilt für jede Block-, Prozessor-, Software-, Hardware-Konfiguration usw., die eine Prozesssteu erfunktion ausführt.

Ein Messwertgeberblock koppelt die Eingänge und Ausgänge eines Funktionsblocks mit lokalen Hardwaregeräten wie Sensoren und Geräteaktuatoren, um es den Funktionsblöcken zu ermöglichen, die Ausgänge lokaler Sensoren zu lesen und lokale Geräte anzu weisen, eine oder mehrere Steuerfunktionen wie die Bewegung eines Ventilelements auszuführen. Messwertgeberblöcke enthal ten typischerweise Informationen, die zur Interpretation der von einem lokalen Gerät gelieferten Signale und zur ordnungs gemäßen Steuerung lokaler Hardwaregeräte erforderlich sind, einschließlich Informationen, die den Typ eines lokalen Geräts identifizieren, zu einem lokalen Gerät gehörige Kalibrierin formationen etc. Zu jedem Eingangs- oder Ausgangsfunktions block gehört typischerweise ein einzelner Messwertgeberblock.

Jeder Block eines Geräts kann verschieden in verschiedenen Mo di arbeiten und jeder Funktionsblock kann Alarm- oder Er eignisanzeigen auf Basis vorgegebener Kriterien erzeugen. All- gemein gesagt können die Blöcke in einer beliebigen Anzahl verschiedener Modi arbeiten, einschließlich z. B. eines Auto matikmodus, in dem etwa der Algorithmus eines Funktionsblocks automatisch abläuft; einem Operatormodus, in dem der Eingang oder Ausgang z. B. eines Funktionsblocks manuell gesteuert wird; einem Modus "außer Betrieb", in dem der Block nicht ar beitet; einem Kaskadenmodus, in dem die Operation des Blocks vom Ausgang eines anderen Blocks beeinflusst (bestimmt) wird; und einem oder mehreren Fernmodi, in denen ein entfernt ange ordneter Computer den Modus des Blocks bestimmt.

Es ist von Bedeutung, dass jeder Block mit anderen Blöcken im selben oder in verschiedenen Fieldgeräten unter Verwendung von durch das Fieldbus-Protokoll definierten Standard-Meldungs formaten über den Fieldbus-Bus kommunizieren kann. Als Ergeb nis können Kombinationen aus Funktionsblöcken (im selben oder in verschiedenen Geräten) miteinander kommunizieren, um eine oder mehrere dezentrale Steuerungsschleifen zu erzeugen. Somit kann z. B. ein PID-Funktionsblock in einem Fieldgerät über den Bus zum Anschluss eines Ausgangs eines AI-Funktionsblocks in einem zweiten Fieldgerät, zum Liefern von Daten an einen AO- Funktionsblock in einem dritten Fieldgerät und zum Empfangen eines Ausgangs eines AO-Blocks als Rückmeldung zur Erzeugung einer Prozesssteuerungsschleife getrennt und unabhängig von jeder zentralen Steuerung geschaltet sein. Auf diese Weise verlegen Funktionsblöcke Steuerfunktionen aus der Umgebung ei ner zentralen Steuerung, wodurch es möglich wird, dass Multi funktionssteuerungen überwachende oder koordinierende Funktio nen ausführen oder ganz entfallen. Des weiteren bieten Funkti onsblöcke eine grafische blockorientierte Struktur zur einfa chen Konfigurierung eines Prozesses und gestatten die Vertei lung von Funktionen auf die Fieldgeräte verschiedener Herstel ler, da diese Blöcke ein konsistentes Kommunikationsprotokoll verwenden.

Abgesehen davon, dass jedes Fieldgerät Blockobjekte enthält und implementiert, enthält es auch noch ein oder mehrere, ande re Objekte, einschließlich Linkobjekte, Trendobjekte, Alarmie rungsobjekte und Ansichtsobjekte. Linkobjekte definieren die Abschnitte zwischen den Eingängen und Ausgängen der Blöcke (z. B. Funktionsblöcke) sowohl intern zum Fieldgerät als auch über den Fieldbus-Bus. Trendobjekte gestatten den Zugriff durch andere Geräte wie einen Host oder eine Steuerung auf das lokale zeitliche Verhalten der Funktionsblockparameter. Trend objekte halten kurzfristige historische Daten bezüglich bei spielsweise eines Funktionsblockparameters und übergeben diese Daten auf periodischer Basis über den Bus an andere Geräte oder Funktionsblöcke. Alarmierungsobjekte übergeben Alarme und Ereignisse über den Bus. Diese Alarme oder Ereignisse können jedes Ereignis betreffen, das innerhalb des Geräts oder eines der Blöcke im Gerät stattfindet. Ansichtsobjekte sind vorde finierte Gruppierungen von Blockparametern, die in Standard- Mensch/Maschine-Schnittstellen verwendet werden, und können auf periodischer Basis zur Ansicht an andere Geräte geschickt werden.

Zur Implementierung und Ausführung von Kommunikations- und Steueraktivitäten verwendet das Fieldbus-Protokoll drei all gemeine technologische Kategorien, die als physikalische Ober fläche, Kommunikations-"Stapel" und Anwenderoberfläche be zeichnet werden. Die Anwenderoberfläche enthält die Steuer- und Konfigurierungsfunktionen, die in Form von Blöcken (z. B. Funktionsblöcken) und Objekten innerhalb eines bestimmten Pro zesssteuerungsgeräts oder Fieldgeräts bereitgestellt sind. Die Anwenderoberfläche wird typischerweise vom Gerätehersteller als proprietär konzipiert, muss aber in der Lage sein, Meldun gen entsprechend dem im Fieldbus-Protokoll definierten Stan dardmeldungsformat zu empfangen und zu senden und muss vom An wender auf Standardweise konfiguriert werden können. Die phy sikalische Oberfläche und der Kommunikationsstapel sind für die standardisierte Kommunikation unter Verwendung des Zwei leitungsbusses zwischen verschiedenen Blöcken oder verschiede nen Fieldgeräte erforderlich und können mit dem hinreichend bekannten Oberflächenkommunikationsmodell Ogen Systems Inter connect (OSI) modelliert werden.

Die physikalische Oberfläche, die der OSI-Oberfläche 1 ent spricht, ist in jedem Fieldgerät und dem Bus eingebettet und wandelt elektromagnetische Signale vom Fieldbus- Übertragungsmedium (dem Zweileitungsbus) in Meldungen, die vom Kommunikationsstapel des Fieldgeräts verwendet werden können. Die physikalische Oberfläche kann als der Bus 12 und die auf dem Bus 12 an den Eingängen und Ausgängen der Fieldgeräte lie genden elektromagnetischen Signale interpretiert werden. Der in jedem Fieldbus-Gerät vorhandene Kommunikationsstapel enthält eine Datenlink-Oberfläche, die der OSI-Oberfläche 2 entspricht, eine Fieldbus-Zugriffszwischenfläche und eine Fieldbus-Meldungsspezifikationsoberfläche, die der OSI- Oberfläche 7 entspricht. Im Fieldbus-Protokoll gibt es keine entsprechende Struktur für die. OSI-Oberfläche 3-6. Die An wendungen eines Fieldbus-Geräts weisen jedoch eine Anwende roberfläche 8 auf, die nicht im OSI-Protokoll definiert ist. Jede Oberfläche im Kommunikationsstapel ist zuständig für die Codierung oder Decodierung eines Abschnitts der Meldung oder des Signals, die bzw. das auf dem Fieldbus-Bus übertragen wird. Als Ergebnis fügt jede Oberfläche des Kommunikationssta pels bestimmte Abschnitte des Fieldbus-Signals wie Präambeln, Startbegrenzer und Endbegrenzer hinzu oder entfernt diese und decodiert in manchen Fällen die abgetrennten Abschnitte des Fieldbus-Signals, um zu bestimmen, wohin die Reste des Signals oder der Meldung geschickt werden sollten, oder ob das Signal verworfen werden sollte, weil es beispielsweise eine Meldung oder Daten für Funktionsblöcke enthält, die sich nicht im emp fangenden Fieldgerät befinden.

Die Datenlinkoberfläche steuert die Übertragung von Meldungen auf dem Bus und verwaltet den Zugriff auf den Bus gemäß eines deterministischen zentralen Bus-Schedulers mit der Bezeichnung Link Active Scheduler, der nachstehend detailliert beschrieben wird. Die physikalische Oberfläche entfernt eine Präambel von den Signalen im Übertragungsmedium und kann die erhaltene Prä ambel zur Synchronisierung des internen Taktes des Fieldgeräts mit dem eingehenden Fieldbus-Signal verwenden. Die physikali sche Oberfläche wandelt wiederum Meldungen auf dem Kommunika tionsstapel in physikalische Fieldbus-Signale und codiert die se Signale mit Taktinformationen, um ein "synchrones seriel les" Signal mit der richtigen Präambel für die Übertragung auf dem Zweileitungsbus zu erzeugen. Während des Decodierungspro zesses erkennt die physikalische Oberfläche spezielle Codes in der Präambel wie Startbegrenzer und Endbegrenzer zur Kenn zeichnung von Beginn und Ende eine bestimmten Fieldbus-Meldung und kann eine Kontrollsumme zur Verifizierung der Integrität des Signals oder der Meldung, das bzw. die vom Bus erhalten wurde, bilden. Gleichermaßen überträgt die physikalische Ober fläche Fieldbus-Signale auf dem Bus 12, indem an die Meldungen auf dem Kommunikationsstapel Start- und Endbegrenzer angefügt und diese Signale zum geeigneten Zeitpunkt auf das Übertra gungsmedium gelegt werden.

Die Fieldbus-Meldungsspezifikationsoberfläche gestattet der Anwenderoberfläche (d. h. den Funktionsblöcken, Objekten etc. eines Fieldgeräts) die Kommunikation über den Bus 12 unter Verwendung einer Standardmenge von Meldungsformaten und be schreibt die Kommunikationsdienste, Meldungsformate und das Protokollverhalten, die zum Aufbau von Meldungen, die auf den Kommunikationsstapel zu legen und der Anwenderoberfläche be reitzustellen sind, erforderlich sind. Da die Fieldbus- Meldungsspezifikationsoberfläche standardisierte Kommunikatio nen für die Anwenderoberfläche liefert, sind für jedes der oben beschriebenen Objekte spezifische Fieldbus- Kommunikationsdienste für die Meldungsspezifikation definiert. Die Fieldbus-Meldungsspezifikationsoberfläche enthält bei spielsweise Objektwörterbuchdienste, die es einem Anwender ge statten, ein Objektwörterbuch eines Geräts zu lesen. Das Ob jektwörterbuch speichert Objektbeschreibungen, die jedes der Objekte (etwa Blockobjekte) beschreiben oder identifizieren. Die Fieldbus-Meldungsspezifikationsoberfläche liefert auch Kontextmanagementdienste, mit denen ein Anwender den Status virtueller Kommunikationsbeziehungen (VCR), die hierin später beschrieben werden, zu lesen und zu ändern. Außerdem stellt die Fieldbus-Meldungsspezifikationsschicht variable Zugriffs dienste, Ereignisdienste, Hochfahr- und Herunterfahrdienste und Programmaufrufdienste bereit, die im Rahmen des Fieldbus- Protokolls hinreichend bekannt sind, und deshalb hier nicht im Einzelnen beschrieben werden. Die Fieldbus-Zugriffszwischen fläche bildet die Fieldbus-Meldungsspezifikationsoberfläche in eine Datenlinkoberfläche ab.

Um eine Operation dieser Oberflächen zu gestatten oder zu er möglichen, enthält jedes Fieldbus-Gerät eine Managementinfor mationsbasis (MIB), bei der es sich um eine Datenbasis han delt, die VCR's, dynamische Variable, Statistiken, Zeitpläne der Link Active Scheduler, Zeitpläne der Funktionsblockausfüh rung sowie Geräteidentifizierungskennzeichen- und Adressinfor mationen speichert. Natürlich kann auf die Informationen in der MIB jederzeit mittels Standard-Fieldbus-Meldungen oder -Befehlen zugegriffen oder sie können geändert werden. Das weiteren wird im Allgemeinen eine Gerätebeschreibung mit jedem Gerät bereitgestellt, um dem Anwender eine umfassende Ansicht der Informationen im VFD (virtual Fieldbus device) zu geben. Eine Gerätebeschreibung, der typischerweise ein Token zuge ordnet werden muss, damit sie von einem Host verwendet werden kann, speichert Informationen, die Daten und Verfahren be schreiben, die mit Daten eines Geräts arbeiten, einschließlich einer menschlichen Schnittstelle für Funktionen wie Kalibrie rung oder Diagnose.

Es versteht sich, dass zur Implementierung jeder Steuerungs strategie unter Verwendung von über ein Prozesssteuerungs netzwerk verteilten Funktionsblöcken die Ausführung der Funk tionsblöcke bezüglich der Ausführung anderer Funktionsblöcke in einer bestimmten Steuerungsschleife präzise geplant sein muss. Gleichermaßen muss die Kommunikation zwischen verschie denen Funktionsblöcken auf dem Bus präzise geplant sein, so dass dem Funktionsblock die richtigen Daten zur Verfügung ge stellt werden, bevor er ausgeführt wird.

Nunmehr wird beschrieben, auf welche Weise verschiedene Field geräte (und verschiedene Blöcke innerhalb der Fieldgeräte) über das Fieldbus-Übertragungsmedium kommunizieren. Damit eine Kommunikation stattfindet, arbeitet eines der Link-Master- Geräte auf einem Segment des Busses als Link Active Scheduler (LAS), der die Kommunikation auf dem zugehörigen Segment des Busses aktiv plant und steuert. Der LAS für jedes Segment speichert und aktualisiert einen Kommunikationsplan (einen Link Active Schedule), der die Zeiten enthält, zu denen jeder Funktionsblock jedes Geräts planmäßig seine periodische Kommu nikationsaktivität auf dem Bus startet, sowie die Zeitdauer, während der diese Kommunikationsaktivität stattfinden soll. Obwohl für jedes Segment des Busses ein und nur ein aktives LAS-Gerät vorhanden sein kann, können andere Link-Master- Geräte als Reserve-LAS fungieren und aktiv werden, wenn bei spielsweise der aktuelle LAS ausfällt.

Allgemein gesagt sind die Kommunikationsaktivitäten über den Bus in sich wiederholende Makrozyklen unterteilt, von denen ein jeder eine synchrone Kommunikation für jeden auf einem be stimmten Segment des Busses aktiven Funktionsblock und eine oder mehr asynchrone Kommunikationen für einen oder mehrere der Funktionsblöcke oder Geräte, die auf einem Segment des Busses aktiv sind, enthält. Während jedes Makrozyklus wird je der der Funktionsblöcke, der auf einem bestimmten Segment des Busses aktiv ist, in im Allgemeinen verschiedenen, aber präzi se geplanten (synchronen), Zeitpunkten ausgeführt und heraus gegeben in einem anderen präzise geplanten Zeitpunkt seine Ausgangsdaten auf diesem Segment des Busses als Antwort auf einen vom entsprechenden LAS erzeugten zwingenden Datenbefehl. Vorzugsweise ist für jeden Funktionsblock die Herausgabe sei ner Ausgangsdaten kurz nach dem Ende der Ausführungsdauer des Funktionsblocks geplant. Des weiteren sind die Zeiten der Her ausgabe der Daten der verschiedenen Funktionsblöcke seriell geplant, so dass nicht zwei Funktionsblöcke eines bestimmten Segments des Busses Daten gleichzeitig herausgeben. Während der Zeit, in der keine synchrone Kommunikation stattfindet, kann jedes Fieldgerät nacheinander Alarmdaten, Ansichtsdaten etc. auf asynchrone Weise mittels Token getriebener Kommunika tion übertragen. Die Ausführungszeiten werden in der Manage mentinformationsbasis (MIB) des Geräts, in dem der Funk tionsblock steht, gespeichert, während wie oben erwähnt die Zeiten zum Senden der zwingenden Datenbefehle an jedes der Ge räte auf einem Segment des Busses in der MIB des LAS-Geräts für dieses Segment gespeichert werden. Diese Zeiten werden ty pischerweise als Offsetzeiten gespeichert, da sie die Zeiten kennzeichnen, zu denen ein Funktionsblock als Offset gegenüber jeder Wiederholung des Makrozyklus ausgeführt werden oder Da ten senden soll. Der Makrozyklus wird kontinuierlich wieder holt, beginnend von einer "absoluten Linkplanungszeit", die alle mit dem Bus 12 verbundenen Fieldgeräte kennen.

Um also Kommunikationen während jedes Makrozyklus zu bewirken, sendet der LAS gemäß der Liste von Übertragungszeiten, die im Link Active Schedule gespeichert sind, einen zwingenden Daten befehl an jedes der Geräte auf dem Bussegment. Bei Empfang ei nes zwingenden Datenbefehls gibt ein Funktionsblock eines Ge räts seine Ausgangsdaten auf den Bus 12 heraus. Da die Ausfüh rung jedes der Funktionsblöcke typischerweise so geplant ist, dass sie kurz vor dem planmäßigen Empfang eines zwingenden Da tenbefehls abgeschlossen ist, dürften die als Antwort auf ei nen zwingenden Datenbefehl herausgegebenen Daten die neuesten Ausgangsdaten des Funktionsblocks sein. Wird jedoch ein Funk tionsblock langsam ausgeführt oder hat er keine zwischenge speicherten neuen Ausgänge, wenn er den zwingenden Datenfehl empfängt, gibt der Funktionsblock die Ausgangsdaten, die wäh rend des letzten Ablaufs des Funktionsblocks erzeugt wurden, heraus.

Nachdem der LAS einen zwingenden Datenbefehl an jeden der Funktionsblöcke eines bestimmten Segments des Busses geschickt hat und während der Zeit, in der die Funktionsblöcke ausge führt werden, kann der LAS asynchrone Kommunikationsaktivitä ten bewirken. Um eine asynchrone Kommunikation zu bewirken, sendet der LAS eine Meldung mit Passiertoken an ein bestimmtes Fieldgerät. Empfängt ein Fieldgerät eine Meldung mit Passier token, hat dieses Fieldgerät vollen Zugriff auf das Segment und kann asynchrone Meldungen schicken wie z. B. Alarmmeldun gen, Trenddaten, seitens des Operators vorgenommene Änderungen der Sollwerte etc., bis die Meldungen vollständig sind oder bis eine maximale zugewiesene "Tokenhaltezeit" abgelaufen ist. Danach gibt das Fieldgerät den Segmentbus frei und der LAS schickt eine Meldung mit Passiertoken an ein anderes Gerät. Dieser Prozess wiederholt sich bis zum Ende des Makrozyklus oder bis der LAS planmäßig einen zwingenden Datenbefehl sen det, um eine synchrone Kommunikation zu bewirken. Je nach Auf kommen des Meldungsverkehrs und der Anzahl der Geräte und Blocks, die mit einem bestimmten Segment des Busses gekoppelt sind, ist es natürlich möglich, dass nicht jedes Gerät während jedes Makrozyklus eine Meldung mit Passiertoken erhält.

Fieldgeräte können Daten und Meldungen unter Verwendung einer von drei virtuellen Kommunikationsbeziehungen (virtual com munication relationships - VCR), die in der Fieldbus-Zugriffs zwischenfläche des Stapels jedes Fieldgeräts definiert sind, über den Bus herausgeben und übertragen. Eine Client/Server- VCR dient für wartende, ungeplante, vom Anwender veranlasste Eins-zu-Eins-Kommunikationen zwischen Geräten auf dem Bus. Solche Meldungen in Warteschlangen werden in der Reihenfolge, in der sie zur Übertragung aufgegeben werden, entsprechend ih rer Priorität gesendet und empfangen, ohne dass frühere Mel dungen überschrieben werden. Ein Fieldgerät kann also eine Client/Server-VCR verwenden, wenn es eine Meldung mit Passier token von einem LAS erhält, um eine Anforderungsmeldung an ein anderes Gerät auf dem Bus zu senden. Der Anforderer ist der "Client" und das die Anforderung erhaltende Gerät ist der "Server". Der Server sendet eine Anwort, wenn er eine Meldung mit Passiertoken vom LAS erhält. Die Client/Server-VCR wird beispielsweise verwendet, um seitens des Anwenders veranlaßte Anforderungen wie Änderungen der Sollwerte, Zugriff zum Ab stimmen der Parameter und Änderungen, Bestätigungen von Alar men und Herauf- und Herunterladen von Geräten zu bewirken.

Eine Listenverteilungs-VCR wird für wartende, ungeplante, vom Anwender veranlasste Eins-zu-Vielen-Kommunikationen verwendet. Empfängt beispielsweise ein Fieldgerät mit einer Ereignis- oder Trendliste eine Meldung mit Passiertoken von einem LAS, sendet dieses Fieldgerät seine Meldung an eine "Gruppenadres se", die in der Fieldbus-Zugriffsunterschicht des Kommunika tionsstapels dieses Geräts definiert ist. Geräte, die so kon figuriert sind, dass sie diese VCR anhören, erhalten die Li ste. Der Typ der Listenverteilungs-VCR wird typischerweise von Fieldbus-Geräten verwendet, um Alarmmeldungen an die Operator- Bedienungsplätze zu senden.

Ein VCR-Typ Herausgeber/Bezieher wird für gepufferte Eins-zu- Vielen-Kommunikationen verwendet. Gepufferte Kommunikationen sind solche, die nur die neueste Version der Daten speichern und senden, so dass neue Daten frühere Daten vollständig über schreiben. Funktionsblockausgänge z. B. enthalten gepufferte Daten. Ein Herausgeber-Fieldgerät gibt heraus oder sendet eine Meldung unter Verwendung des VCR-Typs Herausgeber/Bezieher an alle Bezieher-Fieldgeräte auf dem Bus, wenn das Herausgeber- Gerät eine zwingende Datenmeldung vom LAS oder von einem Be zieher-Gerät erhält. Die Herausgeber/Bezieher-Beziehungen sind vorkonfiguriert und in der Fieldbus-Zugriffszwischenfläche des Kommunikationsstapels jedes Fieldgeräts definiert und gespei chert.

Um korrekte Kommunikationsaktivitäten über den Bus sicherzu stellen, schickt jeder LAS in regelmäßigen Abständen eine Zeitverteilungsmeldung an alle mit einem Segment des Busses verbundenen Fieldgeräte, die es den empfangenden Geräten er möglicht, ihre lokale Anwendungszeit aufeinander synchron ein zustellen. Zwischen diesen Synchronisierungsmeldungen wird die Taktzeit unabhängig in jedem Gerät auf Basis von dessen eige nen internen Takt eingehalten. Die Taktsynchronisierung er möglicht den Fieldgeräten das Anbringen von Zeitstempeldaten im gesamten Fieldbus-Netzwerk, um beispielsweise anzugeben, wann Daten erzeugt wurden.

Des Weiteren speichert jeder LAS (und andere Link-Master- Geräte) auf jedem Bussegment eine "Live-Liste", bei der es sich um eine Liste aller Geräte handelt, die mit dem betref fenden Segment des Busses verbunden sind, d. h. um alle Geräte, die ordnungsgemäß auf eine Meldung mit Passiertoken antworten. Der LAS erkennt kontinuierlich neue zu einem Bussegment hin zugefügte Geräte, indem er regelmäßig Abtastknotenmeldungen an Adressen schickt, die sich nicht in der Live-Liste befinden. In der Tat wird von jedem LAS gefordert, mindestens eine Adresse abzutasten, nachdem er einen Zyklus des Sendens von Meldungen mit Passiertoken an alle Fieldgeräte der Live-Liste abgeschlossen hat. Befindet sich ein Fieldgerät an der abgeta steten Adresse und empfängt eine Abtastknotenmeldung, schickt das Gerät sofort eine Abtastantwortmeldung zurück. Bei Erhalt einer Abtastantwortmeldung fügt der LAS das Gerät zur LiVe- Liste hinzu und bestätigt dies mit einer Knotenaktivierungs meldung an das abgetastete Fieldgerät. Ein Fieldgerät bleibt so lang auf der Live-Liste, wie dieses Fieldgerät ordnungsge mäß auf Meldungen mit Passiertoken antwortet. Ein LAS nimmt das Feldgerät jedoch aus der Live-Liste, wenn es nach drei aufeinander folgenden Versuchen das Token weder verwendet noch es unverzüglich zum LAS zurückschickt. Wird ein Fieldgerät in die Live-Liste hinzugefügt oder aus dieser entfernt, sendet der LAS Änderungen der Live-Liste an alle anderen Link-Master- Geräte im entsprechenden Segment des Busses 12, damit jedes Link-Master-Gerät eine aktuelle Kopie der Live-Liste führt.

Nunmehr sei erneut auf Fig. 1 und 2 verwiesen, in denen der Doppelmodus-Geräte/Netzwerkkonfigurator 20 dargestellt ist, der zur Konfigurierung des Segments 10 oder eines Geräts auf dem Segment 10 verwendet werden kann, während andere Konfigu ratoren oder Hostgeräte am Segment 10 angebracht sind oder nicht. Insbesondere kann der Konfigurator mit dem Bus 12 des Segments 10 (oder direkt mit einem Gerät auf dem Segment 10) zur jeder gewünschten Zeit oder an jedem gewünschten Ort ver bunden und in einem ersten Modus, d. h. einem Offlinemodus, verwendet werden, um beliebige der Geräte auf dem Segment 10 sowie Netzwerkeinstellungen im Segment ähnlich die der Stan dard-Fieldbus-Konfigurator 16 zu konfigurieren. Außerdem kann der Konfigurator 20 in einem zweiten Modus, d. h. einem Online modus, verwendet werden, in dem der Konfigurator 20 mit dem Bus 12 oder einem Gerät verbunden werden kann, um gerätespezi fische Parameter oder Einstellungen zu konfigurieren, ohne die Steuerung über den Bus 12 zu übernehmen und ohne die Netzwerk einstellungen der mit dem Bus 12 verbundenen Geräte zu beein flussen. Auf diese Weise kann der Konfigurator 20 mit einem Gerät kommunizieren und ein Gerät neu konfigurieren, während dieses Gerät und/oder andere Geräte online arbeiten, um die Prozesssteuerung auszuführen, aber ohne die Netzwerkein stellungen des Segments 10 oder andere auf dem Segment 10 stattfindenden Kommunikationen zu stören. Allgemein gesagt sind Netzwerkeinstellungen Parameter, über die Übereinstimmung aller Geräte für die Kommunikation miteinander besteht, wie maximale Ansprechverzögerung, maximale inaktive Zeit zur Bean spruchung der LAS-Verzögerungen etc.

Wie in Fig. 1 dargestellt enthält der Konfigurator 20, bei dem es sich um ein Hostgerät, einen Laptop oder einen tragbaren Computer oder jeden anderen Rechnertyp handeln kann, einen Prozessor 22 und einen Speicher 24, der Programmen, Routinen und Daten speichert, die im Prozessor 22 ausgeführt oder von diesem verwendet werden. Wie in Fig. 2 dargestellt kann das Gerät 20 außerdem eine Anzeige 26 enthalten, bei der es sich um jeden gewünschten Type Anzeige handeln kann, z. B. ein LED-, ein LCD-, einen Plasma-Bildschirm etc. Die Architektur des Konfigurators 20 enthält eine physikalische Oberfläche 28, die zum Anschluss und zum Trennen an den bzw. vom Fieldbus-Bus 12 ausgeführt ist, um Kommunikationen über den Bus auf stan dardmäßige Weise zu ermöglichen, und einem Fieldbus-Kommuni kationsstapel 30, der auf Standardweise arbeitet, um Fieldbus- Kommunikationen auszuführen. Allgemein gesagt sind die physi kalische Oberfläche 28 und der Kommunikationsstapel 30 Stan dard-Fieldbus-Oberflächen, wie sie in jedem Fieldbus-Gerät verwendet werden. Eine Reihe Programme oder Subroutinen 31 sind im Speicher 24 in einer Anwenderoberfläche 32 gespeichert und werden im Prozessor 22 implementiert, um verschiedene Ty pen Kommunikationen und Operationen über den Bus 12 auszufüh ren.

Der Konfigurator 20 enthält außerdem einen Modusschalter 34, der beispielsweise ein Hardware- oder ein Softwareschalter sein kann. Der Modusschalter oder das Einstellelement 34 re gelt den Modus des Konfigurators 20 entweder auf einen Off linemodus, in dem ein Konfigurator 35 als Standard-Fieldbus- Konfigurator, indem er die Steuerung über den Bus 12 annimmt und Netzwerkeinstellungen mittels der Routinen 31 wie erfor derlich konfiguriert, oder einen Onlinemodus, in dem ein Kon figurator 35 nur eine begrenzte Anzahl der Routinen oder Pro zeduren 31 verwendet, um dadurch sicherzustellen, dass die im plementierten Konfigurationsaktivitäten die Onlinesystem konfigurationsinformationen, die Netzwerkeinstellungen und an dere Onlinekonfigurationsinformationen wie LAS-Pläne etc. nicht stören.

Falls gewünscht kann die Konfiguration 35 eine erste Kon figurationsroutine 36 enthalten, die als Netzwerkkonfigurator arbeitet und die Zugriff auf alle Routinen 31 hat, und eine zweite Konfigurationsroutine 38, die als Gerätekonfigurator arbeitet und Zugriff auf nur einen Teil der Routinen 31 hat. Insbesondere enthält die Menge der Routinen oder Prozeduren 31 zwei Basistypen Routinen, einschließlich eines ersten Typs, der die Netzwerkeinstellungen steuert oder beeinflusst, und eines zweiten Typs, der die Geräteeinstellungen steuert, ohne Onlinesystemkonfigurationsinformationen zu beeinflussen. Sämt liche Routinen 31 stehen dem Offlinekonfigurator 36 zur Aus führung von Standard-Fieldbus-Konfigurationsaktivitäten zur Verfügung. Diese Aktivitäten (und Routinen oder Prozeduren 31) beinhalten beispielsweise die Zuordnung von Geräteidentifizie rungskennzeichen und Geräteadressen innerhalb des Segments, die Festlegung von Kommunikationsbeziehungen mit den während des Betriebs des Segments auf Standardweise zu verwendenden Geräten, die Planung der Operation der Funktionsblöcke inner halb der Geräte, die Planung von Kommunikationen zwischen Ge räten, die Konfigurierung von Alarmen und Trends, die an den Operator oder andere Geräte zu senden sind, die Einstellung von anwenderseitigen Anwendungsblockparametern und die Ein stellung anderer Netzwerkparameter. Im Offlinemodus hat also der Konfigurator 20 die gesamte Funktionalität eines typischen Fieldbus-Konfigurators, der sowohl das Fieldbus-Segment als auch die Geräte auf dem Segment konfiguriert und in dieser Ei genschaft die volle Kontrolle über das Segment 10 im Betrieb übernimmt. Ebenfalls im Offlinemodus plant der Konfigurator 36 vorübergehend alle Funktionsblöcke des zu konfigurierenden Ge räts und löscht dessen Änderungen, sobald der Anwender mit dem Gerät fertig ist.

Ist jedoch der Modusschalter oder das Einstellelement 34 auf den Onlinemodus eingestellt, übernimmt der Konfigurator 38 nicht die Kontrolle über das Segment 10 oder führt Kommuni kationen oder andere Aktivitäten aus, die die Onlinesystem konfigurationsinformationen des Segments 10 stören. Dieser On linemodus kann z. B. verwendet werden, wenn nur eines oder meh rere der Geräte des Segments konfiguriert werden sollen, um beispielsweise Geräteabstimmungen oder Diagnosen auf dem Seg ment 10 auszuführen, wenn ein Hostgerät bereits eine "live" Prozesssteuerung auf dem Segment 10 ausführt. Im Onlinemodus sind bestimmte der Routinen oder Prozeduren 31 (d. h. die erste Menge Routinen) für den Onlinekonfigurator 38 nicht verfügbar, was es dem Konfigurator 20 ermöglicht, gleichzeitig mit ande ren Konfiguratoren oder Hostgeräten z. B. einem LAS, der auf dem Segment 10 arbeitet, zu arbeiten.

Insbesondere wird der Onlinekonfigurator 38 im Onlinemodus keine Geräteidentifizierungskennzeichen, Geräteadressen, Pläne der Funktionsblöcke ändern oder andere Aktionen durchführen, die normalerweise von LAS eines Live-Segments gesteuert und normalerweise von einem Konfigurationsgerät eingestellt wer den. Statt dessen konfiguriert der Onlinekonfigurator 38 nur solche Geräteparameter, die in enger Beziehung mit dem Gerät selbst stehen, anstelle von Parametern, die das Segment 10 oder die Steuerungsschleifen im Segment 10 betreffen. Die Ein stellungen, die der Onlinekonfigurator 38 konfigurieren kann (d. h. die Routinen 31, auf die er Zugriff hat), beinhalten die Modifizierung der statischen Parameter eines Ressourcenblocks, eines Messwertgeberblocks und eines Funktionsblocks eines Ge räts. Die Routinen 31, auf die der Onlinekonfigurator 38 nicht zugreifen oder verwenden kann, beinhalten die Planung von Funktionsblöcken, die Zuordnung von Geräteadressen, die Ein stellung von Netzwerkparametern, die Erstellung von Steu erungsschleifen, das Herunterladen von Kommunikationsplänen und das Löschen von Gerätekonfigurationen. Im Onlinemodus än dert der Gerätekonfigurator 20 also nur statische Block parameter. Des Weiteren kann der Gerätekonfigutator 20 eine Anzeigeroutine 42 enthalten, die auf eine Liste von Geräten auf dem Segment, eine Liste der Ressourcenblöcke, Messwert geberblöcke und Funktionsblöcke in einem Gerät, die Lese- und Schreibparameter dieser Blöcke und Kommunikationsstatistiken zugreift und diese auf der Anzeige 26 anzeigt, alles unter Verwendung von Standard-Fieldbus-Kommunikationen oder Anfor derungen.

Im Onlinemodus verwendet der Konfigurator 35 eine spezielle Kommunikationsroutine 44, um Kommunikationen mit einem neu zu konfigurierenden Gerät aufzubauen. Diese Routine 44, die nach stehend detaillierter beschrieben wird, dient dazu, dem Kon figurator 35 die Kommunikation mit einem Gerät zu ermöglichen, ohne Kommunikationsverbindungen, die von anderen Konfigura tionsgeräten oder mit dem Segment 10 verbundenen LAS zu zer stören. Die Kommunikationsprozedur 44 wird verwendet, weil es wünschenswert ist, dass der Konfigurator 20 über den Bus mit dem zu ändernden Gerät durch Aufbau nur der Kommunikations verbindungen, die zur Arbeit an dem zu ändernden Gerät erfor derlich sind, kommuniziert, wodurch der Verkehr im Netzwerk reduziert wird. Im Onlinemodus braucht außerdem der Konfigu rator 20 keine Gerätedetailinformationen zu lesen, es sei denn, der Anwender wünscht solche Informationen, was ebenfalls weniger Verkehr im Segment erzeugt.

Bei erstmaliger Verbindung mit dem Segment 10 wird der Online konfigurator 38 so konfiguriert, dass er sich dem Segment 10 als Gastgerät präsentiert, um die Anzeigeroutine 42 zur Er kennung und Anzeige der Geräte auf dem Segment 10 für den An wender über beispielsweise die Anzeige 26 zu verwenden und mit einem bestimmten Gerät auf dem Segment zu kommunizieren, wenn und falls ein Anwender dieses Gerät wählt. Der Online konfigurator 38 konfiguriert nur Geräte an bestimmten Adressen (etwa Feldgeräteadressen, aber nicht Host- oder Gastadressen) und der Anwender kann die Menge Adressen bestimmen, an denen ein Gerät konfigurierbar ist. Die dem Anwender angezeigten In formationen können in jeder Form angezeigt werden und werden in einer Ausführungsform in ähnlicher Form wie unter dem Win dows® NT Explorer angezeigt.

Während des Betriebs entscheidet der Anwender mit dem Modus schalter 34, welcher Modus verwendet werden soll. Im Offline modus weist der Konfigurator 20 einem Gerät auf dem Segment erforderlichenfalls vorübergehend eine Adresse zu. Im Online modus ist jedoch eine bestimmte Funktionalität des Gerätekon figurators 20, nämlich die erste oben bezeichnete Menge Rou tine deaktiviert, um eine gegenseitige Beeinflussung mit dem Hostgerät zu vermeiden. Um einen Anwender daran zu hindern, versehentlich eine Verbindung mit einem Live-Segment herzu stellen, wenn sich der Gerätekonfigurator 20 im Offlinemodus befindet, enthält der Gerätekonfigurator 20 eine erste Routine 46 "Unzutreffender Modus", die prüft, ob ein Gerät mit einer oder mehreren Adressen gekoppelt ist, die typischerweise von einem Standardgerätekonfigurator, Host oder LAS verwendet wer den, und falls ein Gerät an einer dieser Adressen vorhanden ist, den Anwender warnt, dass ein anderer Konfigurator auf dem Segment vorhanden ist. Diese Adressen können die sein, die von Fieldbus-Konfiguratoren verwendet werden, und werden typi scherweise vom Anwender bereitgestellt. Der Konfigurator 20 enthält außerdem eine zweite Routine 48 "Unzutreffender Mo dus", die den Betrieb des Offlinekonfigurators 36 anhält, wenn kein Gerät auf dem Segment erkannt wird, an das der Konfi gurator 20 gekoppelt ist. In diesem Fall wird sich der Off linekonfigurator 36 nicht auf dem Segment präsentieren und der Anwender muss statt dessen den Konfigurator 36 bei Wahl reak tivieren. Die Routine 48 hindert einen Anwender daran, den Offlinegerätekonfigurator 36 versehentlich erneut an ein Live- Segment anzuschließen, nachdem an einem Offlinesegment gear beitet wurde, ohne den Konfigurator 20 abzuschalten, da dann, wenn der Konfigurator 36 von einem Segment getrennt ist, die Routine 48 keine Geräte auf dem Segment erkennt und die Opera tion des Geräte/Netzwerkkonfigurators 20 anhält, bis der An wender einen Reset vornimmt.

Im Vergleich dazu übernehmen bekannte Fieldbus-Konfiguratoren die vollständige Kontrolle über das Segment. Befinden sich zwei davon auf demselben Segment, können sie miteinander in Konflikt geraten. Sie werden z. B. beide automatisch versuchen, einem Gerät eine permanente Adresse zuzuweisen, um mit diesem Gerät zu kommunizieren. Selbst bei Konfiguration als Basis gerät, werden manche bekannte Konfiguratoren dennoch Adressen zuweisen. Der Konfigurator 20 kann jedoch im Onlinemodus neben bekannten Konfiguratoren oder anderen Zweimodus-Konfiguratoren 20, die auf demselben Segment laufen, bestehen. Während außer dem bekannte oder Standard-Fieldbus-Überwachungswerkzeuge auf einem Live-Segment nebeneinander bestehen können, können diese Werkzeuge nicht auf Geräteinformationen zugreifen.

Zur Durchführung nicht störender Kommunikationen bei Verbin dung mit dem Bus 12 im Onlinemodus ist die Kommunikations routine oder der Algorithmus 44 so ausgelegt, dass Kommunika tionen mit einem Gerät in einem Segment, in dem ein anderes Host- oder LAS-Gerät arbeitet, möglich sind, ohne die von dem das Segment steuernden LAS festgelegten Kommunikationspara meter zu überschreiben oder zu zerstören. Insbesondere ver wendet die Kommunikationsroutine 44 ein nicht störendes vir tuelles Kommunikationsbeziehungskonzept, um auf die Anwender anwendung in einem Gerät zuzugreifen.

Bei der Konfigurierung eines Fieldbus-Segmentes hat typischer weise ein Hostgerät die vollständige Kontrolle über das ge samte Segment und sämtliche Geräte auf dem Segment. Um auf die Funktionsblockinformationen in jedem Gerät zuzugreifen, kann der Host nahezu jeden verfügbaren Virtual Communication Rela tionship (VCR)-Eingang wählen und jeden lokalen Selektor ver wenden. Des Weiteren braucht der Host an den Geräten vorge nommene Änderungen nicht zu bereinigen. Als Ergebnis können zwei Fieldbus-Konfiguratoren aufgrund der Art und Weise, wie diese Geräte die Geräte-VCR-Eingänge in das Gerät schreiben, normalerweise nicht dasselbe Gerät gleichzeitig konfigurieren.

Die hierin beschriebene Kommunikationsroutine oder der Prozess 44 ist in der Lage, auf ein Gerät auf dem Segment zuzugreifen und es zu konfigurieren, während in der Zwischenzeit ein ande res Hostgerät das Netzwerk konfiguriert oder steuert. Die Rou tine 44 schreibt nur minimal in den Geräte-VCR-Eingang, um ei ne Kommunikation mit dem Gerät herzustellen, und stellt die Kommunikationen wieder her, wenn der verwendete VCR-Eingang von einem anderen Host zerstört wird. Des Weiteren hinterlässt die Kommunikationsroutine 44 minimale Änderungen am VCR-Ein gang, der wieder verwendbar ist, nachdem die Routine 44 endet oder die Kommunikation beendet.

Wie oben erwähnt, wird die Foundation Fieldbus-Netzwerkkommu nikation über verschiedene Oberflächen verwirklicht. Ein typi sches Fieldbus-Gerät 50 ist in Fig. 3 dargestellt und enthält von unten nach oben eine physikalische Oberfläche (Physical Layer - PHY), eine Datenverbindungsoberfläche (Data Link Layer - DLL), eine Fieldbus-Zugriffszwischenfläche (Fieldbus Access Sublayer - FAS), eine Fieldbus- Meldungsspezifikationsoberfläche (Fieldbus Message Spectfica tion Layer - FMS) und eine Anwenderanwendungsoberfläche (User Application Layer). Das Fieldbus-Gerät 50 wird als ein oder mehrere virtuelle Fieldbus-Geräte (Virtual Fieldbus Devices - VFD) am Netzwerk dargestellt und jedes virtuelle Gerät hat ein System-VFD 56, das System- und Netzwerkmanagementinformationen enthält, sowie ein oder mehrere Anwenderanwendungs-VFD's 58, die Funktionsblockinformationen enthalten.

Die Information in einem VFD ist in einem Objektwörterbuch (Object Dictionray - OD) organisiert. Ein Client im Netzwerk oder Segment greift über virtuelle Kommunikationsbeziehungen (VCR), die in der FMS-Oberfläche definiert sind, auf die OD's zu. Der Client kann ein anderes Gerät oder eine andere Überwa chungs-/Konfigurierungsausrüstung im Netzwerk und insbesondere der Konfigurator 20 sein. Die VCR-Parameter sind an den VCR- Eingängen an beiden Enden der Verbindung gespeichert und ent halten die lokale Adresse, die Fernadresse, das VFD, auf das zuzugreifen ist, den VCR-Typ und Kommunikationskoeffizienten. Tabelle 10 der FF-940-1.4 Fieldbus-Norm enthält die verschie denen Typen VCR und ihre Parameter im Fieldbus-Protokoll. Im Allgemeinen enthält die Adresse eine Abschnittsnummer (die das Segment betrifft, auf dem sich das Gerät befindet), eine Kno tenadresse im Abschnitt (die für jedes Gerät auf einem Segment eindeutig ist) und einen VCR-Selektor, der verschiedene Teile oder Abschnitte des Geräts betrifft. Eine Verbindung wird zwi schen zwei Geräten aufgebaut, wenn ihre VCR-Eingangsparameter übereinstimmen.

Allgemein gesagt gibt der Client zuerst eine Anforderung für einen Verbindungsaufbau an das Gerät aus. Die Anforderung be sagt, welche lokale Adresse im Gerät zu verwenden ist, und das Gerät lokalisiert dann den lokalen VCR-Eingang, der dieser lo kalen Adresse entspricht, und bestimmt diese lokale Adresse für die VCR-Verbindung. Ein VCR-Eingang stimmt mit einer loka len Adresse überein, wenn sein lokaler Selektorparameter dem gleichen Wert in der lokalen Adresse entspricht. Die Fieldbus Foundation definiert einen lokalen Selektor für den Zugriff auf das Systemmanagement-OD vor. Um auf ein Anwenderanwen dungs-OD zugreifen zu können, muss der Client zunächst einen verwendbaren VCR-Eingang im Gerät suchen, dessen Parameter än dern, falls erforderlich, und dann eine Verbindung mit dem Eingang herstellen.

Wie bekannt ist, sind die VCR-Eingänge im System-OD gespei chert. Ein Gerät hat eine feste Anzahl VCR-Eingänge und manche davon können fest codiert sein, d. h. die Typen, der lokale Se lektorwert etc. sind voreingestellt. Einige der VCR-Eingänge können auch leer sein, wobei in diesem Fall der Client jede VCR an diesem Eingang definieren kann. Ein Gerät hat einen vorkonfigurierten VCR-Eingang, wobei der reservierte lokale Selektor von der Fieldbus Foundation für den Zugriff auf das System-OD definiert ist. Ein Client braucht diesen VCR-Eingang für den Zugriff auf das System-OD nicht zu lokalisieren. Er kann eine Anforderung für die Herstellung einer Verbindung mit diesem reservierten lokalen Selektor ausgeben.

Typischerweise gibt es nur ein Hostgerät im Netzwerk, das die Geräte vollständig konfiguriert. Dieses Host- oder LAS-Gerät überschreibt VCR-Eingänge für seine eigenen Zwecke und es ist nicht notwendig, sich Gedanken zu machen, ob die VCR verfügbar ist oder ob ihre Eingänge korrekt sind. Ein ungültiger oder doppelter lokaler Selektor wird vermieden, da das Hostgerät die vollkommene Kontrolle hat und in alle VCR-Eingänge schrei ben kann. In den meisten Fällen nimmt das Hostgerät die Ände rungen der VCR-Eingänge des Geräts nicht zurück. Natürlich sind für andere Überwachungsgeräte, die keine VCR-Verbindungen zum Gerät herstellen müssen, die vom Hostgerät vorgenommenen Änderungen nicht von Belang.

Versuchen jedoch zwei Clients wie zwei Konfiguratoren gleich zeitig auf das Anwenderanwendungs-OD eines Geräts zuzugreifen, können sie erfolgreich sein oder nicht, je nachdem, ob sich ihre jeweiligen VCR-Eingänge stören. Das Ziel der hierin be schriebenen Kommunikationsroutine 44 ist, den Zugriff eines Client auf die Anwenderanwendung des Geräts sicherzustellen, unabhängig davon, ob ein anderer Host im Netzwerk existiert. Des Weiteren versucht die Routine 44 in den VCR-Eingängen so wenig Spuren wie möglich zu hinterlassen, nachdem der Client das Netzwerk verlässt. Als Ergebnis kann die Routine 44 in ei nem konfigurierenden Nicht-Host-Client verwendet werden, der zusammen mit einem Hostgerät existiert, z. B. der oben be schriebene Konfigurator im Onlinemodus, in einem Offline- Konfigurator, der ein Gerät für den Betrieb vorbereitet, oder sogar in einem herkömmlichen Hostgerät, das das gesamte Field bus-Segment konfiguriert.

Nunmehr sei auf Fig. 4 verwiesen, in der ein von der Routine 44 verwendeter Kommunikationsalgorithmus 100 in Form eines Flussdiagramms dargestellt ist. Zum Zwecke dieser Erläuterung ist der VCR-Typ für den Zugriff auf das Anwenderanwendungs-OD ein Client/Server, das Gerät, auf das der Zugriff erfolgt, wird als Server bezeichnet und der Client ist der den Zugriff auf das Gerät anfordernde Client, in diesem Fall der Geräte/ Netzwerkkonfigurator 20, der im Onlinemodus arbeitet. Ein Block oder Schritt 104 initialisiert zunächst Konfigurations daten, indem eine Liste von für die Kommunikation nicht zu verwendenden Selektorwerten erzeugt oder darauf zugegriffen wird, und indem die für die Verwendung verfügbaren VCR im Ge rät bestimmt werden. Die nicht zu verwendenden Selektorwerte sind die Selektorwerte, die bereits von den VCR verwendet wer den, die im Gerät für andere Kommunikationen über den Bus 12 verwendet werden. Typischerweise sollte im Fieldbus-Protokoll der Wert der lokalen Selektoren im Bereich von 0x20 bis OxF7 liegen. Der Schritt 104 schließt jedoch ausdrücklich bestimmte Adressen aus, von denen bekannt ist, dass sie von anderen Hostgeräten verwendet werden, um dadurch mögliche Konflikte mit Hostgeräten im Netzwerk zu verhindern. Weiß beispielsweise der Algorithmus 100 oder ein Anwender, dass ein fester lokaler Selektor von anderen Hostgeräten verwendet wird, kann dieser Selektorwert in die Liste der nicht zu verwendenden Selektor werte eingetragen werden und der Algorithmus 100 wird diesen Selektor nicht zur Kommunikation mit dem Gerät verwenden. Die se Maßnahme verhindert nicht nur mögliche Konflikte mit dem Rost, der diesen Selektorwert verwendet, sondern verringert auch die Notwendigkeit der Neuerstellung von späteren VCR- Verbindungen, wenn der andere Host die vom Clientgerät (d. h. dem Gerätekonfigurator 20) hergestellte vorübergehende Ver bindung löscht.

Der Block 104 bestimmt auch eine Anzahl verwendbarer VCR-Ein gänge im Server (das Gerät, auf das zugegriffen wird), aus de nen zu wählen ist. Natürlich kann es im Servergerät mehr ver wendbare VCR-Eingänge geben als unbedingt gebraucht werden. In jedem Fall entscheidet der Schritt 104, wie viele der VCR- Eingänge, die es im Gerät gibt, verwendet werden können. Der Schritt der Bestimmung nicht zu verwendender lokaler Selekto ren kann gleichzeitig mit dem Schritt der Bestimmung verfüg barer VCR-Eingänge erfolgen, falls gewünscht, da der Selek torwert für jeden VCR-Eingang, der als nicht verwendbar be stimmt wird, in die Liste der nicht zu verwendenden Selektor werte eingetragen wird. In jedem Fall gilt, dass aus je mehr VCR-Eingängen gewählt wird, umso mehr Speicherplatz benötigt wird, aber umso geringer die Möglichkeit ist, dass es Kon flikte mit anderen Konfiguratoren oder Hostgeräten gibt. Na türlich kann der Anwender diese Parameter einstellen (d. h. wie viele Selektoren und VCR-Eingänge zu speichern sind), oder sie können vorkonfiguriert und im Speicher zur Verwendung durch den Algorithmus 100 abgelegt werden.

In einer Ausführungsform liest der Schritt 104 jeden VCR-Ein gang im Gerät und ergreift folgende Schritte für jeden Ein gang. Ist der VCR-Eingang leer, wird seine Indexnummer und Kennzeichnung als leer gesichert. Ist der VCR-Eingang ein nicht verwendbarer Eingang, wird sein lokaler Selektorwert in der Liste nicht verwendbarer lokaler Selektoren gesichert. An dernfalls muss der VCR-Eingang ein voreingestellter und ver wendbarer Eingang sein. In diesem Fall werden alle VCR- Eingangsparameter gesichert. Ein verwendbarer Eingang kann ein fest codierter Eingang oder ein verwendbarer sein, der zuvor von anderen Clients eingestellt wurde.

Allgemein prüft also der Schritt 104 jeden VCR-Eingang im Ser vergerät und bestimmt, ob jeder der VCR-Eingänge entweder leer oder vorkonfiguriert ist. Ein leerer Eingang kann für die ge wünschte Kommunikationsverbindung konfiguriert werden und wenn ja, speichert der Schritt 104 die Indexnummer jedes leeren Eingangs. Bei einem vorkonfigurierten Eingang prüft der Schritt 104 zuerst, ob der Eingang von dem Typ ist, der für die gewünschte Kommunikation verwendet werden kann, und be stimmt, ob dieser Eingang frei zur Verwendung ist. Ist der Eingang verwendbar und frei, sichert der Schritt 104 die Para meter dieses Eingangs. Für jeden vorkonfigurierten Eingang kann der Schritt 104 den lokalen Selektor des Eingangs für ei ne spätere Verwendung sichern, wenn der Algorithmus 100 einen lokalen Selektor wählen muss. Bestimmte Fieldbus-Geräte haben nur vorkonfigurierte VCR-Eingänge und deshalb geht der Algo rithmus 100 nicht davon aus, dass es immer einen leeren Ein gang gibt, der verwendet werden kann, sondern sucht statt des sen nach vorkonfigurierten Eingängen.

Als Nächstes wählt ein Block oder Schritt 106 einen VCR-Ein gang des Geräts aus den gesicherten verwendbaren VCR-Eingän gen. Ist kein verwendbarer VCR-Eingang vorhanden, versagt der Algorithmus 100 und der Anwender kann zum derzeitigen Zeit punkt nicht auf das Anwenderanwendungs-OD des Geräts zugrei fen. Nachdem der Algorithmus 100 alle VCR-Eingänge des Server geräts durchlaufen hat und eine Menge verwendbarer VCR-Eingän ge gesichert hat, entscheidet der Schritt 106, welcher VCR- Eingang zu verwenden ist. Um die Möglichkeit von Konflikten zu verringern, wird ein Zufallsalgorithmus verwendet, um einen der verwendbaren Eingänge zu wählen. Hier können zwei Prinzi pien befolgt werden. Erstens, der Schritt 106 versucht, den ersten verwendbaren Eingang zu vermeiden, wenn es genug ver wendbare gibt, da die meisten Konfiguratoren oder Hostgeräte die Neigung haben, den ersten Eingang, auf den sie treffen, zu verwenden. Zweitens kann die Zufälligkeit mit der Netzwerk adresse oder einem anderen eindeutigen Wert für den Client ge koppelt werden, was zur Vermeidung einer Situation beiträgt, in der zwei den Algorithmus 100 verwendende Clients denselben VCR-Eingang wählen. Die Zufälligkeit ist wichtig, da der ge wählte VCR-Eingang immer noch durch andere Geräte übernommen werden kann, in welchem Fall die den VCR-Eingang verwendende Verbindung verloren ist und neu hergestellt werden muss. Je weniger oft diese Situation auftritt, um so schneller und bes ser wird die Kommunikation mit dem Servergerät sein.

Als Nächstes legt ein Block oder Schritt 108 eine VCR-Verbin dung mit dem Gerät auf eine standardmäßige Weise unter Ver wendung des gewählten VCR-Eingangs und eines der nicht verwen deten Selektorwerte fest. Die Kommunikation beginnt dann in Schritt 110. Bei einem leeren VCR-Eingang schreibt der Schritt 108 die Parameterwerte, die für die serverseitige VCR angefor dert sind, in den Eingang. Bei einem verwendbaren Eingang wer den die clientseitigen Parameter entsprechend den Werten im Servergerät eingestellt. Der für einen leeren Eingang verwen dete lokale Selektor wird so gewählt, dass er nicht einer der verbotenen ist (d. h. einer aus der Liste nicht verwendbarer lokaler Selektoren) oder von einem anderen Eingang verwendet wird. In beiden Fällen wird der Fernadressparameter im Gerät als 0 belassen. Das Ziel ist, den VCR-Eingang im Servergerät wiederverwendbar für andere Konfiguratoren oder Hosts zu ma chen, sobald der Algorithmus 100 die Verbindung aufgibt.

Als Alternative kann der Schritt 108 die Clientadresse in den VCR-Eingang des Geräts schreiben und ihn später auf seine ur sprüngliche Einstellung zurücksetzen, wenn der Konfigurator 20 fertig ist. Diese Vorgehensweise erfordert jedoch einen Reset am Ende der Kommunikationsprozedur, aber bevor der Konfigura tor 20 vom Segment getrennt wird. Ist der Konfigurator 20 häu fig mit dem Netzwerk gekoppelt, um in einem kurzen Zeitraum Kommunikationen auszuführen, möchte sich der Anwender typi scherweise vom Netzwerk trennen können, ohne sich um einen Re set kümmern zu müssen. Außerdem ist der Reset manchmal nicht möglich, da die Kommunikation mit dem Gerät verloren geht.

In jedem Fall kann der Konfigurator 20 nach Herstellen des Kommunikationsabschnitts die Routinen oder Prozeduren 31 aus führen, um die Geräteeinstellungen wie oben unter Bezugnahme auf Fig. 2 beschrieben zu ändern, und um mit dem Gerät zu kom munizieren wie in Block oder Schritt 110 dargestellt. Während der Kommunikation bestimmt jedoch ein Block oder Schritt 112, ob die Kommunikationsverbindung unterbrochen ist (normaler weise durch Prüfung, ob eine Zeitüberwachungsdauer abläuft) und falls ja, veranlasst er den Kommunikationsalgorithmus, Schritte 104 bis 110 zu wiederholen. Wie oben erwähnt wird die Clientadresse nicht in den VCR-Eingang des Geräts geschrieben, wodurch derselbe Eingang später von anderen Geräten verwendet werden kann. Ein Nachteil dieser Vorgehensweise ist, dass an dere Konfiguratoren oder Hosts den verwendeten Eingang irr tümlich als immer noch verwendbar betrachten, während der Kon figurator 20 unter Verwendung des VCR-Eingangs kommuniziert, und diese anderen Geräte den VCR-Eingang übernehmen können. Durch die Verwendung einer Zufallswahl in Schritt 106 wird versucht, diese Möglichkeit zu vermeiden, was jedoch nicht im mer gelingt. In dem seltenen Fall also, in dem die Verbindung durch ein den VCR-Eingang übernehmendes anderes Gerät beendet wird, reinitialisiert der Algorithmus 100 die Verbindung, in dem er einen anderen VCR-Eingang sucht. Die Bedeutung von Schritt 112 ist nicht nur im VCR-Eingangskonflikt zu sehen, sondern auch in den Fällen, in denen das Hostgerät in seinem Netzwerkkonfigurierungsprozess sämtliche VCR-Eingänge löscht.

Es versteht sich also, dass der Algorithmus 100 ein nicht stö rendes VCR-Erstellungsverfahren bereitstellt, um auf Anwender anwendungs-/Funktionsblockinformationen in einem Fieldbus- Gerät zuzugreifen. Herkömmliche Fieldbus-Konfiguratoren stel len keine nicht störenden Verbindungen her, da sie im Wesent lichen die VCR-Eingänge im Gerät überschreiben können, um ih ren Anforderungen zu entsprechen. Im Ergebnis gibt es bei die sen Geräten kein Problem, einen verwendbaren Eingang zu fin den, keine Probleme mit Verbindungsunterbrechungen und keine Notwendigkeit, die VCR-Eingänge rückzusetzen. Alle diese Fak toren müssen jedoch berücksichtigt werden, wenn versucht wird, mehr als einen Konfigurator im selben Netzwerk oder Segment zu verbinden.

Des weiteren arbeitet der Algorithmus 100 sowohl für Einzel- als auch Mehrkonfiguratorfälle, so dass mehr als ein Konfigu rator gleichzeitig auf die Anwenderanwendung des Geräts und die Prozessinformationen zugreifen kann. Der Algorithmus 100 ist nicht störend und unterbricht keine bestehende Geräte-VCR- Verbindung. Als Ergebnis kann der den Algorithmus 100 verwen dende Konfigurator jederzeit vom Netzwerk getrennt werden, oh ne den VCR-Eingang in einem nicht verwendbaren Zustand zu hin terlassen, was bedeutet, dass der Eingang von anderen Geräten ohne Weiteres verwendet werden kann. Des weiteren bestimmt der Algorithmus 100 einen lokalen Selektor fliegend. Bei Ver wendung eines leeren VCR-Eingangs ist der lokale Selektor also nicht fest, sondern statt dessen so gewählt, dass er mit, kei nen vorhandenen Eingängen in Konflikt gerät. Da der Algorith mus 100 nach vorkonfigurierten oder leeren VCR-Eingängen sucht, kann er mit verschiedenen Typen Fieldbus-Geräten ver wendet werden, einschließlich Geräten mit oder ohne leere VCR- Eingänge.

Obwohl der Konfigurator 20 hierin als mit einer Funktionalität beschrieben worden ist, die von einem oder mehreren Programmen oder Routinen in einem Prozessor und einem Speicher implemen tiert wird, versteht es sich, dass der Konfigurator 20 als je der beliebige Gerätetyp konstruiert sein kann und dass die verschiedenen Elemente des Konfigurators 20 in Hardware, Firm ware oder Software erzeugt oder implementiert werden können, die in jedem beliebigen Computertyp, auf Disk oder einem ande ren Speichergerät gespeichert ist. Bei einer Implementierung in Software könnte der Konfigurator 20 in jeder gewünschten Programmiersprache programmiert und in einer Standard-Mehr zweck-CPU oder einer speziell konzipierten Hardware oder Firm ware implementiert werden wie z. B. ASIC's, falls gewünscht. Bei einer Software-Implementierung kann die Software in jedem computerlesbaren Speicher z. B. auf einer Magneto Disk, einer Laser Disk, einer Optical-Disk oder einem anderen Speicherme dium, in einem RAM oder ROM eines Computers oder Prozessors etc. gespeichert werden. Diese Software kann gleichermaßen über jedes bekannte oder gewünschte Lieferverfahren an einen Anwender oder ein Gerät innerhalb eines Prozesssteuerungs ystems geliefert werden, einschließlich z. B. eine computerles bare Disk oder einen anderen transportablen Computer speichermechanismus, oder über einen Kommunikationskanal modu liert werden wie z. B. eine Telefonleitung, das Internet, eine Satellitenverbindung, eine Funkverbindung etc. (die als gleichwertig oder austauschbar mit einem transportierbaren Speichermedium für die Bereitstellung solcher Software gel ten). Da des Weiteren die vorliegende Erfindung unter Bezugnahme auf bestimmte Beispiele beschrieben worden ist, die nur als bei spielhaft und nicht als einschränkend zu sehen sind, versteht es sich für den Durchschnittsfachmann, dass Änderungen, Hinzu fügungen oder Streichungen an den offenbarten Ausführungsfor men vorgenommen werden können, ohne Geist und Gültigkeitsbe reich der Erfindung zu verlassen.

Claims

1. Konfigurationsgerät (20) zur Anwendung in der Konfigurle rung eines Foundation Fieldbus-Segments (10) mit:
einem Prozessor (22),
einem Speicher (24),
einem ersten Satz von Routinen, die im Speicher (24) ab gelegt und so konzipiert sind, dass sie auf dem Prozessor (22) zur Ausführung von Netzwerkkonfigurationsänderungen ausgeführt werden,
einem zweiten Satz von Routinen, die im Speicher (24) ab gelegt und so konzipiert sind, dass sie auf dem Prozessor (22) zur Ausführung von Gerätekonfigurationsänderungen ohne Netz werkkonfigurationsänderungen herbeizuführen, ausgeführt wer den;
einem Modusschalter (34), der zwischen einem ersten und einem zweiten Modus umgeschaltet werden kann, und
einer im Speicher (34) abgelegten Konfigurationsroutine, die zur Ausführung auf dem Prozessor (22) ausgeführt ist, um eine Routine aus dem ersten Satz von Routinen oder eine Routi ne aus dem zweiten Satz von Routinen zu starten, wenn der Mo dusschalter (34) auf den ersten Modus gestellt ist, um dadurch das Netzwerk zu konfigurieren, und zum Starten einer Routine der zweiten Menge aber nicht der ersten Menge, wenn der Modus schalter (34) auf den zweiten Modus gestellt ist.

2. Konfigurationsgerät (20) nach Anspruch 1, das des Weite ren einen Kommunikationsstapel (30) zur Kommunikation über das Segment (10) unter Verwendung des Fieldbus-Protokolls enthält.

3. Konfigurationsgerät (20) nach Anspruch 1 oder 2, das des Weiteren eine Kommunikationsroutine (44) enthält, die im Spei cher (24) abgelegt und zur Ausführung auf dem Prozessor (22) ausgeführt ist, um einen Kommunikationsabschnitt mit einem Fieldbus-Gerät (13, 14) auf dem Segment (10) herzustellen, ohne die von anderen Geräten mit dem Fieldbus-Gerät (13, 14) herge stellten Kommunikationsabschnitte zu stören.

4. Konfigurationsgerät (20) nach einem der Ansprüche 1 bis 3, bei dem die Kommunikationsroutine (44) einen ersten Ab schnitt enthält, der virtuelle Eingänge der Kommu nikationsbeziehungen (virtual communication relationship - VCR) bestimmt, die zur Verwendung im Fieldbus-Gerät (13, 14) zur Verfügung stehen und nicht von anderen Geräten verwendet werden, einen zweiten Abschnitt, der einen der verwendbaren VCR-Eingänge wählt, und einen dritten Abschnitt, der die Kom munikationsverbindung unter Verwendung des gewählten VCR- Eingangs herstellt.

5. Konfigurationsgerät (20) nach einem der Ansprüche 1 bis 4, bei dem der dritte Abschnitt einen lokalen Selektor verwen det, um die Kommunikationsverbindung, die den gewählten VCR- Eingang verwendet, herzustellen.

6. Konfigurationsgerät (20) nach einem der Ansprüche 1 bis 5, bei dem die Kommunikationsroutine des Weiteren einen vier ten Abschnitt enthält, der bestimmt, ob die den gewählten VCR- Eingang verwendende Kommunikationsverbindung unterbrochen ist, und falls ja, die Operation des ersten, zweiten und dritten Abschnitts der Kommunikationsroutine veranlasst, um eine neue Kommunikationsverbindung mit dem Fieldbus-Gerät (13, 14) herzu stellen.

7. Konfigurationsgerät (20) nach einem der Ansprüche 1 bis 6, bei dem der zweite Abschnitt so ausgeführt ist, dass er ei nen der verwendbaren VCR-Eingänge zufällig wählt.

8. Konfigurationsgerät (20) nach einem der Ansprüche 1 bis 7, bei dem die erste Menge Routinen mindestens eine Routine zum Zuordnen eines Geräteidentifizierungskennzeichens, eine Routine zum Zuordnen einer Geräteadresse, eine Planungsroutine für die Funktionsblöcke und eine Routine zum Herunterladen ei nes Kommunikationsplanes enthält.

9. Konfigurationsgerät (20) nach einem der Ansprüche 1 bis 8, bei dem die zweite Menge Routinen mindestens eine Routine zur Änderung der Gerätekonfiguration, eine Routine zum Modifi zieren des Ressourcenblocks, eine Routine zum Modifizieren des Messwertgeberblocks und eine Routine zum Modifizieren der Funktionsblöcke enthält.

10. Konfigurationsgerät (20) nach einem der Ansprüche 1 bis 9, das des Weiteren eine Anzeige (26) und eine weitere Routine enthält, die über die Anzeige (26) Konfigurationsinformationen des Fieldbus-Geräts (13, 14) auf dem Segment (10) bestimmt und anzeigt.

11. Konfigurationsgerät (20) nach einem der Ansprüche 1 bis 10, bei dem die weitere Routine eine Liste der aktuell mit dem Segment (10) verbundenen Geräte bestimmt und über die Anzeige (26)anzeigt.

12. Konfigurationsgerät (20) nach einem der Ansprüche 1 bis 11, bei dem die Konfigurationsroutine eine Routine "Unzutref fender Modus" enthält, die bei Einstellen des Modusschalters (34) auf den ersten Modus bestimmt, ob kein Gerät auf dem Seg ment (10)ist, und falls kein Gerät auf dem Segment (10) ist, den Start einer Routine aus dem ersten Satz von Routinen ver hindert.

13. Konfigurationsgerät (20) nach einem der Ansprüche 1 bis 12, bei dem die Konfigurationsroutine eine Routine "Unzutref fender Modus" enthält, die bei Einstellen des Modusschalters (34) auf den ersten Modus eine Menge vorgegebener Geräteadres sen in Zusammenhang mit Hostgeräten auf dem Segment (10) durchsucht und den Anwender vor einem möglichen Fehler warnt, wenn sich ein Gerät an einer der vorgegebenen Geräteadressen befindet.

14. Konfigurationsgerät (20) zur Anwendung in der Konfigurle rung eines Foundation Fieldbus-Segments, mit dem ein oder mehr Fieldbus-Geräte (13, 14) kommunikativ verbunden sind, mit:
einem Prozessor (22);
einem Speicher (24),
einem Satz von Routinen, die im Speicher (24) abgelegt und so konzipiert sind, dass sie auf dem Prozessor (22) zur Ausführung von Gerätekonfigurationsänderungen an Fieldbus- Geräten (13, 14) ausgeführt werden,
einem Kommunikationsstapel (30) zur Kommunikation auf dem Fieldbus-Segment (10);
einer im Speicher (24) abgelegten Konfigurationsroutine, die so ausgeführt ist, dass sie auf den Prozessor (22) ausge führt wird, um eine Routine aus dem Satz von Routinen zu star ten, um ein Fieldbus-Gerät (13, 14) unter Verwendung des Kommu nikationsstapels (30) zu konfigurieren; und
einer im Speicher (24) abgelegten Kommunikationsroutine, die so ausgeführt ist, dass sie eine Kommunikation mit dem Fieldbus-Gerät (13, 14) herstellt, ohne Kommunikationen, die zwischen dem Fieldbus-Gerät (13, 14) und anderen mit dem Field bus-Segment (10) gekoppelten Geräten hergestellt wurden, zu unterbrechen.

15. Konfigurationsgerät (20) nach Anspruch 14, bei dem die Kommunikationsroutine einen ersten Abschnitt enthält, der die virtuellen Eingänge der Kommunikationsbeziehungen (virtual communication relationship - VCR) bestimmt, die zur Verwendung im Fieldbus-Gerät (13, 14) zur Verfügung stehen und nicht von anderen Geräten zu verwenden sind, einen zweiten Abschnitt, der einen der verwendbaren VCR-Eingänge wählt und einen drit ten Abschnitt, der eine Kommunikationsverbindung mit dem Fieldbus-Gerät (13, 14) unter Verwendung des gewählten VCR- Eingangs herstellt.

16. Konfigurationsgerät (20) nach Anspruch 14 oder 15, bei dem die Kommunikationsroutine des Weiteren einen vierten Ab schnitt enthält, der bestimmt, ob die den gewählten VCR- Eingang verwendende Kommunikationsverbindung unterbrochen ist, und falls ja, die Operation des ersten, zweiten und dritten Abschnitts der Kommunikationsroutine veranlasst, um eine neue Kommunikationsverbindung mit dem Fieldbus-Gerät (13, 14) herzu stellen.

17. Konfigurationsgerät (20) nach einem der Ansprüche 14 bis 16, bei dem der dritte Abschnitt einen lokalen Selektor ver wendet, um die Kommunikationsverbindung, die den gewählten VCR-Eingang verwendet, herzustellen.

18. Konfigurationsgerät (20) nach einem der Ansprüche 14 bis 17, bei dem der zweite Abschnitt so ausgeführt ist, dass er einen der verwendbaren VCR-Eingänge zufällig wählt.

19. Konfigurationsgerät (20) nach einem der Ansprüche 14 bis 17, bei dem der Satz von Routinen mindestens eine Routine zur Änderung der Gerätekonfiguration, eine Routine zum Modifizie ren des Ressourcenblocks, eine Routine zum Modifizieren des Messwertgeberblocks und eine Routine zum Modifizieren der Funktionsblöcke enthält.

20. Konfigurationsgerät (20) nach einem der Ansprüche 14 bis 19, das des Weiteren eine Anzeige (26) und eine weitere im Speicher (24) abgelegte Routine enthält, die so ausgeführt ist, dass sie auf dem Prozessor (22) ausgeführt wird, um über die Anzeige (26) Konfigurationsinformationen des Fieldbus- Geräts (13, 14) zu bestimmen und anzuzeigen.

21. Konfigurationssystem zur Anwendung in einem Gerät mit ei nem Prozessor (22), der ein Foundation Fieldbus-Segment konfi guriert, mit:
einem Speicher (24),
einem ersten Satz von Routinen, die im Speicher (24) ab gelegt und so konzipiert sind, dass sie auf dem Prozessor (22) zur Ausführung von Netzwerkkonfigurationsänderungen ausgeführt werden,
einem zweiten Satz von Routinen, die im Speicher (24) ab gelegt und so konzipiert sind, dass sie auf dem Prozessor (22) zur Ausführung von Gerätekonfigurationsänderungen ohne Netz werkkonfigurationsänderungen herbeizuführen, ausgeführt wer den;
einem Moduseinstellelement (34), das auf einen ersten und einen zweiten Modus gestellt werden kann, und
einer im Speicher (24) abgelegten Konfigurationsroutine, die zur Ausführung auf dem Prozessor (22) ausgeführt ist, um eine Routine aus dem ersten Satz von Routinen oder eine Routi ne aus dem zweiten Satz von Routinen zu starten, wenn die Mo duseinstellung der erste Modus ist, um dadurch das Netzwerk zu konfigurieren, und zum Starten einer Routine aus dem zweiten Satz aber nicht aus dem ersten Satz, wenn die Moduseinstellung der zweite Modus ist.

22. Konfigurationssystem nach einem der Ansprüche 14 bis 21, das des Weiteren eine im Speicher (24) abgelegte Kommunikati onsroutine enthält, die so ausgeführt ist, dass sie auf dem Prozessor (22) ausgeführt wird, um Kommunikationen mit einem Fieldbus-Gerät (13, 14) auf dem Segment (10) herzustellen, ohne Kommunikationsabschnitte zu stören, die von anderen Geräten mit dem Fieldbus-Gerät (13, 14) hergestellt worden sind.

23. Konfigurationssystem nach einem der Ansprüche 14 bis 22, bei dem die Kommunikationsroutine einen ersten Abschnitt ent hält, der die virtuellen Eingänge der Kommunikationsbeziehun gen (virtual communication relationship - VCR) bestimmt, die zur Verwendung im Fieldbus-Gerät (13, 14) zur Verfügung stehen und nicht von anderen Geräten verwendet werden, einen zweiten Abschnitt, der einen der verwendbaren VCR-Eingänge wählt, und einen dritten Abschnitt, der die Kommunikationsverbindung un ter Verwendung des gewählten VCR-Eingangs herstellt.

24. Konfigurationssystem nach einem der Ansprüche 14 bis 23, bei dem der dritte Abschnitt einen lokalen Selektor verwendet, um die Kommunikationsverbindung, die den gewählten VCR-Eingang verwendet, herzustellen.

25. Konfigurationssystem nach einem der Ansprüche 14 bis 24, bei dem die Kommunikationsroutine des weiteren einen vierten Abschnitt enthält, der bestimmt, ob die den gewählten VCR- Eingang verwendende Kommunikationsverbindung unterbrochen ist, und falls ja, die Operation des ersten, zweiten und dritten Abschnitts der Kommunikationsroutine veranlasst, um eine neue Kommunikationsverbindung mit dem Fieldbus-Gerät (13, 14) herzu stellen.

26. Konfigurationssystem nach einem der Ansprüche 14 bis 25, bei dem der erste Satz von Routinen mindestens eine Routine zum Zuordnen eines Geräteidentifizierungskennzeichens, eine Routine zum Zuordnen einer Geräteadresse, eine Planungsroutine für die Funktionsblöcke und eine Routine zum Herunterladen ei nes Kommunikationsplanes enthält.

27. Konfigurationssystem nach einem der Ansprüche 14 bis 26, bei dem der zweite Satz von Routinen mindestens eine Routine zur Änderung der Gerätekonfiguration, eine Routine zum Modifi zieren des Ressourcenblocks, eine Routine zum Modifizieren des Messwertgeberblocks und eine Routine zum Modifizieren der Funktionsblöcke enthält.

28. Konfigurationssystem nach einem der Ansprüche 14 bis 27, bei dem die Konfigurationsroutine eine Routine "Unzutreffender Modus" enthält, die bei einer Moduseinstellung auf den ersten Modus bestimmt, ob kein Gerät auf dem Segment (10) ist, und falls kein Gerät auf dem Segment (10) ist, den Start einer Routine aus dem ersten Satz von Routinen verhindert.

29. Konfigurationssystem nach einem der Ansprüche 14 bis 28, bei dem die Konfigurationsroutine eine Routine "Unzutreffender Modus" enthält, die bei einer Moduseinstellung auf den ersten Modus eine Menge vorgegebener Geräteadressen in Zusammenhang mit Hostgeräten auf dem Segment (10) durchsucht und den Anwen der vor einem möglichen Fehler warnt, wenn sich ein Gerät an einer der vorgegebenen Geräteadressen befindet.