DE19940230A1 - Interface in Form eines Schattenfunktionsblockes für die Verwendung in einem Prozessregelnetzwerk - Google Patents

Abstract

Ein Prozeßkontroller, der kommunikativ mit einer externen Bereichsvorrichtung über ein Kommunikationsnetzwerk gekoppelt ist, verwendet einen Schattenfunktionsblock, der innerhalb eines Prozeßkontrollers angeordnet ist, um eine Implementierung einer Steuer- oder Regelroutine zu ermöglichen, die sowohl einen internen Funktionsblock, der innerhalb des Prozeßkontrollers angeordnet ist, als auch einen externen Funktionsblock, der innerhalb der externen Bereichsvorrichtung angeordnet ist, verwendet. Der Schattenfunktionsblock enthält einen Kommunikationsport, der mit dem externen Funktionsblock über das Kommunikationsnetzwerk kommuniziert, um dadurch Daten, die den externen Funktionsblock betreffen, zu empfangen, enthält einen Speicher, der die empfangenen Daten gemäß einem Konfigurationsprotokoll des internen Funktionsblocks separiert, und einen Ausgang, der die gespeicherten externen Funktionsblockdaten in den internen Funktionsblock gemäß dem Konfigurationsprotokoll des internen Funktionsblocks liefert. Der Kommunikationsport des Interface-Funktionsblocks kann einen Ausgang enthalten, der Daten, die durch den Kontroller oder den internen Funktionsblock erzeugt worden sind, zu dem externen Funktionsblock unter Verwendung des Kommunikationsprotokolls sendet, welches dem externen Funktionsblock zugeordnet ist.

Description

Die vorliegende Erfindung betrifft Prozeßregelnetzwerke und spezieller einen Prozeßkontroller, der Schattenfunktionsblöc­ ke verwendet, um Informationen wiederzugeben, die externen Funktionsblöcken zugeordnet sind, welche in einem Prozeßre­ gelnetzwerk verteilt sind.

Prozeßregelnetzwerke, wie beispielsweise solche, die in che­ mischen, Mineralöl- oder anderen Prozessen verwendet werden, enthalten im allgemeinen einen zentralisierten Prozeßkontrol­ ler, der kommunikativ mit einer oder mehreren Gebiets- oder Bereichsvorrichtungen gekoppelt ist, die beispielsweise Ven­ tilstellglieder, Schalter, Sensoren (wie z. B. Temperatur-, Druck- und Strömungsratensensoren) usw. sein können. Diese Bereichsvorrichtungen können Steuerfunktionen innerhalb des Prozesses durchführen (wie das Öffnen oder Schließen eines Ventils), können Messungen innerhalb des Prozesses vornehmen, die für die Steuerung oder Regelung der Arbeitsweise des Pro­ zesses verwendet werden, oder können irgendeine andere ge­ wünschte Funktion innerhalb des Prozesses ausführen. Prozeß­ regler wurden in historischer Weise an die Bereichsvorrich­ tungen über eine oder mehrere analoge Signalleitungen oder Busse angeschlossen, die beispielsweise 4-20 mA (Milliampere) Signale zu und von den Bereichsvorrichtungen leiten. Allge­ mein gesagt, empfängt der Prozeßkontroller Signale, welche die Messungen angeben, die durch einen oder durch mehrere Be­ reichsvorrichtungen vorgenommen wurden und/oder andere Infor­ mationen anzeigen, die zu einer oder zu mehreren Bereichsvor­ richtungen gehören, und er verwendet diese Informationen, um eine typische komplexe Steuerroutine zu implementieren, und erzeugt dann Steuersignale, die über die analogen Signalbusse zu einer oder mehreren der Bereichsvorrichtungen gesendet werden, um dadurch den Betrieb des Prozesses zu steuern.

Kürzlich kam Bewegung in die Prozeßregel- oder -steuer- indu­ strie, um bereichsbasierende digitale Kommunikationen in der Prozeßregelumgebung zu implementieren. Beispielsweise hat die Prozeßregelindustrie eine Anzahl von offenen, digitalen oder kombinierten digitalen und analogen Standardkommunikations­ protokollen entwickelt, wie beispielsweise die HART®, PROFIBUS®, WORLDFIP®, Device-Net® und CAN-Protokolle. Diese digitalen Kommunikationsprotokolle ermöglichen es mehreren Bereichsvorrichtungen, an einen bestimmten Bus angeschlossen zu werden, sie unterstützen mehrere und schnelle Kommunika­ tionen zwischen den Bereichsvorrichtungen und dem Kontroller und/oder ermöglichen es den Bereichsvorrichtungen, mehrere und unterschiedliche Typen von Informationen, wie beispiels­ weise Informationen, die den Status und die Konfiguration der Bereichsvorrichtung selbst betreffen, zu dem Prozeßkontroller zu senden. Ferner ermöglichen es diese digitalen Standardpro­ tokolle den Bereichsvorrichtungen, die von unterschiedlichen Herstellern hergestellt wurden, zusammen mit dem gleichen Prozeßregelnetzwerk verwendet zu werden.

Auch gibt es nunmehr Bewegung innerhalb der Prozeßregelindu­ strie, die Prozeßregelung oder -steuerung zu dezentralisie­ ren, wodurch die Prozeßkontroller vereinfacht werden. Eine dezentralisierte Steuerung oder Regelung wird dadurch erhal­ ten, daß bereichsmontierte Prozeßsteuervorrichtungen, wie beispielsweise Ventilstellglieder, Sender usw., eine oder mehrere Prozeßsteuerfunktionen durchführen, und zwar unter Verwendung von Einrichtungen, die in typischer Weise als Funktionsblöcke bezeichnet werden, und indem dann Daten über eine Busstruktur für die Verwendung durch andere Prozeßsteu­ ervorrichtungen (oder Funktionsblöcke) bei der Ausführung an­ derer Steuerfunktionen übertragen werden. Um diese Steuer­ funktionen zu implementieren, enthält jede Prozeßsteuervor­ richtung in typischer Weise einen Mikroprozessor mit der Fä­ higkeit, einen oder mehrere Funktionsblöcke zu implementie­ ren, als auch die Fähigkeit, mit anderen Prozeßsteuervorrich­ tungen zu kommunizieren, und zwar unter Verwendung eines of­ fenen Standardkommunikationsprotokolls. In dieser Weise kön­ nen Bereichsvorrichtungen innerhalb eines Prozeßregelnetz­ werks miteinander verbunden werden, um miteinander zu kommu­ nizieren und um eine oder mehrere Prozeßsteuerfunktionen un­ ter Bildung einer Regelschleife durchzuführen, und zwar ohne Einschreiten eines zentralisierten Prozeßkontrollers. Das ge­ samtdigitale Zweidraht-Busprotokoll, welches durch die Field­ bus Foundation entworfen wird, bekannt als FOUNDATION (einge­ tragene Marke) Fieldbus- (im folgenden als "Fieldbus" be­ zeichnet) Protokoll bekannt ist, ist ein offenes Kommunikati­ onsprotokoll, welches es den Vorrichtungen, die von unter­ schiedlichen Herstellern stammen, ermöglicht, untereinander zusammenzuarbeiten und zu kommunizieren, und zwar über einen Standardbus, um eine dezentralisierte Steuerung innerhalb es Prozesses zu bewirken.

Da digitale Kommunikationsprotokolle und dezentralisierte Steuerungsschemata (wie solche, die in der Fieldbus-Steuer- oder -Regelumgebung verwendet werden) so neu sind, verwenden Prozesse, welche diese Protokolle implementieren, diese le­ diglich in einem eingeschränkten Ausmaß. Als ein Ergebnis un­ terstützen neuere Prozeßkontroller, wie der Delta V- (einge­ tragene Marke) Prozeßkontroller, der durch Fisher-Rosemount Systems hergestellt wird, sowohl analoge als auch digitale Kommunikationsprotokolle und es kann eine Hardware so pro­ grammiert werden, um die Steuerung in einem Prozeß zu imple­ mentieren, der Bereichsvorrichtungen enthält, die unter Ver­ wendung von analogen Standardprotokollen kommunizieren, wie beispielsweise einem 4-20 mA Protokoll, und unter Verwendung von einem oder mehreren neueren digitalen Protokollen, wie dem Fieldbus-Protokoll.

Es stellten sich jedoch Probleme ein, wenn versucht wurde, die Steuerung von analogen und digitalen Bereichsvorrichtun­ gen zu integrieren, und zwar speziell bei den Fieldbus-Be­ reichsvorrichtungen in einem Prozeßregelnetzwerk, welches einen zentralisierten Kontroller verwendet. Da die Steuer­ funktionen für analoge Bereichsvorrichtungen und einige digi­ tale Bereichsvorrichtungen innerhalb des zentralisierten Pro­ zeßkontrollers implementiert sind, werden alle erforderlichen Informationen über diese Bereichsvorrichtungen innerhalb des zentralisierten Prozeßkontrollers empfangen und gespeichert. Dies macht es seinerseits möglich, daß der zentralisierte Prozeßkontroller die Steuerung unterschiedlicher analoger und digitaler Bereichsvorrichtungen integriert, die die momentane Konfiguration und Zustand von Abschnitten des Prozeßregel­ netzwerks darstellt, in welchem diese Vorrichtungen gelegen sind, um Änderungen in der Prozeßregelnetzwerkkonfiguration in bezug auf diese Vorrichtungen usw. vorzunehmen. Wenn je­ doch ein dezentralisiertes Steuerschema, wie beispielsweise das Fieldbus-Steuerschema in einem Teil des Prozesses verwen­ det wird, braucht der zentralisierte Prozeßkontroller keinen direkten Zugriff mehr auf all die laufenden Informationen zu haben, die durch die Prozeßsteuervorrichtungen verwendet wer­ den oder diesen zugeordnet sind, die der dezentralisierten Steuerung unterworfen sind. Tatsächlich sind einige dezentra­ lisierte Prozeßsteuerprotokolle, wie beispielsweise das Fieldbus-Protokoll, spezifisch so ausgelegt, daß es nicht er­ forderlich ist, Informationen zu einem zentralisierten Pro­ zeßkontroller auf einer regulären Grundlage zu senden. Diese Tatsache macht es für den zentralisierten Prozeßkontroller schwierig, die Steuerung von analogen oder anderen digitalen Bereichsvorrichtungen mit den Bereichsvorrichtungen zu inte­ grieren, die der dezentralisierten Steuerung unterworfen sind. Es macht es auch für den zentralisierten Prozeßkontrol­ ler schwierig, den laufenden oder momentanen Zustand der Vor­ richtungen als Modell nachzubilden oder darzustellen, die der dezentralisierten Steuerung unterworfen sind, oder dies in­ nerhalb eines dezentralisierten Abschnitts des Prozeßregel­ netzwerks durchzuführen.

Tatsächlich müssen für den zentralisierten Prozeßkontroller, der die Informationen von dem dezentralisierten Steuerab­ schnitt des Prozeßregelnetzwerks empfängt, die Bereichsvor­ richtungen (oder Funktionsblöcke) innerhalb dieses Abschnitts des Prozesses spezifisch konfiguriert sein, um Informationen direkt zu dem zentralisierten Prozeßkontroller zu senden (was bedeutet, daß der zentralisierte Prozeßkontroller all diese Informationen empfangen und handhaben muß, wobei der größte Teil derselben für die Betriebsweise des zentralisierten Pro­ zeßkontrollers nicht erforderlich ist). Alternativ muß der zentralisierte Prozeßkontroller aktiv anfragen, um die von ihm benötigten Informationen zu empfangen. Da solch einer An­ frage keine höhere Priorität in beispielsweise dem Field­ bus-Protokoll gegeben wird, und zwar zu der Zeit, in der der zen­ tralisierte Prozeßkontroller die angefragten Informationen empfängt, können diese Information veraltet sein. Es ist fer­ ner für den zentralisierten Prozeßkontroller schwierig, wenn nicht unmöglich, Daten anzufragen und zu empfangen, die zu einer spezifizierten Zeit oder Zeitpunkt aktiv oder momentan vorhanden sind. Statt dessen empfängt der zentralisierte Pro­ zeßkontroller lediglich die Daten zu dem Zeitpunkt, zu wel­ chem die Anfrage die Bereichsvorrichtung erreicht. Darüber hinaus ist die Kommunikation zwischen dem zentralisierten Prozeßkontroller und den Bereichsvorrichtungen innerhalb des dezentralisierten Abschnitts des Prozesses hoch spezialisiert und erfordert ein beträchtliches Wissen über das dezentrali­ sierte Steuerprotokoll, was es für den Konstrukteur oder Ent­ wickler der zentralisierten Prozeßsteuerroutine schwierig macht, diese Kommunikation auf einer gewünschten Basis zu im­ plementieren.

Die vorliegende Erfindung zielt auf die Verwendung von Schat­ tenfunktionsblöcken ab, um in einem zentralisierten Prozeß­ kontroller die Steuerung der Funktionsblöcke, die in dem zen­ tralisierten Kontroller vorherrschen, mit solchen zu inte­ grieren, die in einer externen Vorrichtung vorherrschen, wie beispielsweise einer Bereichsvorrichtung. Die vorliegende Er­ findung kann auch dafür verwendet werden, einem Kontroller die Möglichkeit zu geben, Vorrichtungen oder Funktionsblöcke zu steuern oder mit diesen zu kommunizieren, die in einem Kommunikationsnetzwerk gelegen sind oder die ein Kommunikati­ onsprotokoll verwenden, welches von demjenigen verschieden ist, welches der Kontroller verwendet. Speziell wird ein Schattenfunktionsblock in dem zentralisierten Kontroller er­ stellt oder eingerichtet, um die Daten, die einem externen Funktionsblock zugeordnet sind, der in einer externen Vor­ richtung, wie beispielsweise einer Bereichsvorrichtung, gele­ gen ist, zu spiegeln, und zwar in Einklang mit einem dezen­ tralisierten Steuer- und Kommunikationsprotokoll. Die Steuer­ routine des zentralisierten Kontrollers kommuniziert mit dem externen Funktionsblock über den Schattenfunktionsblock, so als ob der externe Funktionsblock durch den zentralisierten Kontroller implementiert wäre. Der Schattenfunktionsblock er­ hält automatisch die momentanen Informationen, die dem exter­ nen Funktionsblock zugeordnet sind, und sendet Befehle zu dem externen Funktionsblock unter Verwendung des Protokolls, wel­ ches dem externen (z. B. dezentralisierten) Steuerprotokoll zugeordnet ist. Im Falle eines Fieldbus-Protokolls wird diese Kommunikation unter Verwendung von sowohl synchronen als auch asynchronen Kommunikationen erreicht. Jedoch kommuniziert der Schattenfunktionsblock mit anderen Funktionsblöcken innerhalb des zentralisierten Kontrollers so, als ob der externe Funk­ tionsblock vollständig durch den zentralisierten Kontroller implementiert wäre.

Unter Verwendung des Schattenfunktionsblockes der vorliegen­ den Erfindung kann die zentralisierte Prozeßsteuerroutine auf den neuesten Stand gebrachte Informationen um den tatsächli­ chen Funktionsblock herum in einer Realzeit oder nahezu auf Realzeitbasis empfangen, da diese Informationen in dem Schat­ tenfunktionsblock gespiegelt werden, der immer für die zen­ tralisierte Prozeßsteuerroutine zugänglich ist. In ähnlicher Weise kann die zentralisierte Prozeßsteuerroutine Befehle zu dem tatsächlichen Funktionsblock dadurch senden, indem sie einen Befehl zu dem Schattenfunktionsblock ungeachtet des Typs oder der Lage der Vorrichtung sendet, in welcher der tatsächliche Funktionsblock gelegen ist. Der Schattenfunkti­ onsblock setzt dann diesen Befehl unmittelbar in Verbindung zu dem tatsächlichen Funktionsblock unter Verwendung geeigne­ ter Kommunikationsbefehle, die dem dezentralisierten Prozeß­ steuerprotokoll zugeordnet sind. Auf diese Weise braucht die zentralisierte Prozeßsteuerroutine keine signifikante Daten­ basissteuerung in bezug auf die Bereichsvorrichtungen durch­ zuführen, und zwar innerhalb des dezentralisierten Steuerab­ schnitts des Prozesses, da die Informationen, die sie für die Bereichsvorrichtungen innerhalb des dezentralisierten Ab­ schnitts des Prozeßregelnetzwerks, in dem Schattenfunktions­ block bzw. den Schattenfunktionsblöcken gelegen sind. In ähn­ licher Weise braucht die zentralisierte Prozeßsteuerroutine nicht spezifische programmiert zu werden, um mit den komple­ xen und fordernden Aufgaben der Kommunikation in dem dezen­ tralisierten Prozeßsteuerprotokoll fertig zu werden, da diese Kommunikation automatisch durch den Schattenfunktionsblock durchgeführt wird.

Gemäß einem Aspekt der vorliegenden Erfindung ist ein Inter­ face oder Schattenfunktionsblock dafür ausgebildet, um in ei­ nem Prozeßkontroller verwendet zu werden, der kommunikativ mit einer externen Vorrichtung über ein Kommunikationsnetz­ werk gekoppelt ist, um dem Prozeßkontroller die Möglichkeit zu geben, eine Steuerroutine unter Verwendung von sowohl dem internen Funktionsblock, der in dem Prozeßkontroller vor­ herrscht, als auch eines externen Funktionsblockes, der in­ nerhalb der externen Vorrichtung vorhanden ist, zu implemen­ tieren. Das Interface oder der Schattenfunktionsblock gemäß diesem Aspekt der Erfindung enthält einen Kommunikationsport mit einem Eingang, der mit dem externen Funktionsblock über das Kommunikationsnetzwerk kommuniziert, um dadurch Daten zu empfangen, die zum externen Funktionsblock gehören, und ent­ hält einen Speicher, der die empfangenen Daten, die zu dem externen Funktionsblock gehören, gemäß einem Konfigurations­ protokoll des internen Funktionsblockes speichert. Wenn es erwünscht ist, kann der Interface-Funktionsblock auch einen Ausgang aufweisen, der die gespeicherten externen Funktions­ blockdaten zu dem internen Funktionsblock liefert, und zwar unter Verwendung des Konfigurationsprotokolls des internen Funktionsblocks. In ähnlicher Weise kann der Kommunikati­ onsport des Interface-Funktionsblocks einen Ausgang enthal­ ten, der Daten (wie beispielsweise verkettete Daten oder Be­ fehle) zu dem externen Funktionsblock sendet, und zwar unter Verwendung eines Kommunikationsprotokolls, welches dem exter­ nen Funktionsblock zugeordnet ist.

In bevorzugter Weise empfängt der Kommunikationsport des In­ terface-Funktionsblocks die Daten, die zu dem externen Funk­ tionsblock gehören, unabhängig von der Operation der internen Funktionsblöcke. In ähnlicher Weise kommuniziert bei einer Ausführungsform der externe Funktionsblock über das Kommuni­ kationsnetzwerk unter Verwendung eines ersten Kommunikations­ protokolls, welches verschieden ist von einem zweiten Kommu­ nikationsprotokoll, welches dem internen Funktionsblock zuge­ ordnet ist, und in diesem Fall kommuniziert der Kommunikati­ onsport mit dem externen Funktionsblock unter Verwendung des ersten Kommunikationsprotokolls und der Ausgang des Inter­ face-Funktionsblocks kommuniziert mit dem internen Funktions­ block gemäß dem zweiten Kommunikationsprotokoll.

Wenn es gewünscht wird, kann das erste Kommunikationsproto­ koll, welches dem externen Funktionsblock zugeordnet ist, ein Fieldbus-Kommunikationsprotokoll sein. In diesem Fall kann der Kommunikationsport eine Interfacevorrichtung (wie bei­ spielsweise eine Interfacekarte) verwenden, die dafür konfi­ guriert ist, um mit der externen Vorrichtung unter Verwendung des Fieldbus-Kommunikationsprotokolls zu kommunizieren, um dadurch eine Kommunikation mit dem externen Funktionsblock vorzunehmen. Der Kommunikationsport kann beispielsweise mit dem externen Funktionsblock unter Verwendung synchroner Kom­ munikationen kommunizieren, wie beispielsweise die Herausge­ ber-/Teilnehmerbeziehungen des Fieldbus-Kommuni­ kationsprotokolls und/oder kann asynchrone Kommunika­ tionen verwenden, wie z. B. die Betrachtungsobjekte in dem Fieldbus-Kommunikationsprotokoll. Allgemeiner kann die exter­ ne Vorrichtung unter Verwendung eines Vorrichtungs-Kommuni­ kationsprotokolls kommunizieren, welches die Kommuni­ kation der logisch verketteten Pakete an Daten unter Verwen­ dung von standardisierten Kommunikationsrufen unterstützt, wie beispielsweise die Betrachtungsobjekte und die Betrach­ tungswarnungen des Fieldbus-Kommunikationsprotokolls, und es kann der Kommunikationsport mit dem externen Funktionsblock unter Verwendung der standardisierten Kommunikationsrufe kom­ munizieren. In ähnlicher Weise kann der Kommunikationsport Alarmanzeigen von dem externen Funktionsblock empfangen und kann diese Alarmanzeigen in dem Speicher für die Verwendung durch den Kontroller speichern.

Gemäß einem anderen Aspekt der vorliegenden Erfindung enthält ein Kontroller, der dafür geeignet ist, um kommunikativ an eine Vielzahl von Bereichsvorrichtungen gekoppelt zu werden, einen Speicher und eine Steuerroutine enthalten, die in dem Speicher abgespeichert ist und die durch den Prozessor imple­ mentiert ist, um die Vielzahl der Bereichsvorrichtungen zu steuern. Die Steuerroutine enthält eine Vielzahl von mitein­ ander verbundenen internen Funktionsblöcken, die unter Ver­ wendung eines Kontrollerprotokolls konfiguriert sind, so daß sie durch den Kontroller implementiert werden, und kann einen Interface-Funktionsblock enthalten, der mit einem der mitein­ ander verbundenen internen Funktionsblöcken kommuniziert, un­ ter Verwendung des Kontrollerprotokolls und der mit einem ex­ ternen Funktionsblock kommuniziert, der in einer externen Be­ reichsvorrichtung vorhanden ist, und zwar unter Verwendung eines Bereichsvorrichtungs-Kommunikationsprotokolls. Der In­ terface-Funktionsblock speichert Daten, die zu dem externen Funktionsblock gehören und von dem externen Funktionsblock für die Verwendung durch die Steuerroutine empfangen werden.

Gemäß einem weiteren Aspekt der vorliegenden Erfindung spei­ chert ein Verfahren zum Implementieren einer Steuerroutine innerhalb eines Prozeßkontrollers, innerhalb des Kontrollers eine Vielzahl von miteinander verbundenen internen Funktions­ blöcken, die gemäß einem Kontrollerprotokoll konfiguriert sind, um einen Teil der Kontrollerroutine zu implementieren. Das Verfahren erzeugt auch innerhalb des Kontrollers einen Interface-Funktionsblock, der gemäß dem Kontrollerprotokoll konfiguriert ist, der jedoch mit einem externen Funktions­ block kommuniziert, der in einer externen Bereichsvorrichtung gelegen ist, und zwar unter Verwendung eines Vorrichtungs-Kommuni­ kationsprotokolls, welches der externen Vorrichtung zugeordnet ist. Das Verfahren erzeugt dann eine Steuerrouti­ ne, welche die Vielzahl der miteinander verbundenen internen Funktionsblöcke und den Interface-Funktionsblock verwendet, um den Prozeß zu steuern oder zu regeln und während der Im­ plementierung der Steuerroutine werden Daten gespeichert, die dem externen Funktionsblock zugeordnet sind und von diesem empfangen werden, und zwar in dem Interface-Funktionsblock für die Verwendung durch die Steuerroutine, so als ob der ex­ terne Funktionsblock durch den Kontroller als einer der in­ ternen Funktionsblöcke implementiert wäre.

Das Verfahren kann einem Anwender auch erlauben, die Steuer­ routine dadurch zu konfigurieren, indem jeder eine Anzahl von Funktionsblöcken, die in der Steuerroutine verwendet werden sollen, spezifiziert wird, die Verbindungen zwischen den spe­ zifizierten Funktionsblöcken, die in der Steuerroutine zu verwenden sind, identifiziert werden und die Stelle oder Ort eines bestimmten spezifizierten Funktionsblockes spezifiziert wird, und zwar als ein interner Funktionsblock, der in dem Kontroller implementiert ist, oder als ein externen Funkti­ onsblock, der durch eine Bereichsvorrichtung implementiert ist. In dem Fall, bei welchem ein Funktionsblock in einer ex­ ternen Vorrichtung zu implementieren ist, enthält das Verfah­ ren den Schritt gemäß einer Auswahl einer externen Vorrich­ tung aus einer Liste oder einem Satz von Vorrichtungen, die in dem System verbunden oder angeschlossen sind.

Fig. 1 ist ein schematisches Blockschaltbild eines bei­ spielhaften Prozeßregelnetzwerks, welches zentrali­ sierte und dezentralisierte Prozeßsteuerabschnitte darin enthält;

Fig. 2 ist ein schematisches Blockschaltbild von drei Standardfunktionsblöcken, die einer oder mehreren Fieldbus-Bereichsvorrichtungen zugeordnet sind;

Fig. 3 ist ein Zeitsteuerschema für einen Makrozyklus ei­ nes Segments eines Fieldbus-Busses, der innerhalb des Prozeßregelnetzwerks von Fig. 1 gelegen ist;

Fig. 4 ist ein schematisches Blockschaltbild, welches die Verbindung eines Schattenfunktionsblockes mit ande­ ren Funktionsblöcken herausgreift, die einer zen­ tralisierten Prozeßsteuerroutine zugeordnet sind und innerhalb eines zentralisierten Prozeßkontrol­ lers gelegen sind;

Fig. 5 ist ein Blockdiagramm eines Teiles eines Prozeßre­ gelsystems unter Verwendung des Schattenfunktions­ blockes der vorliegenden Erfindung;

Fig. 6 ist ein Flußdiagramm, welches die Installation ei­ nes Steuermoduls innerhalb des Kontrollers von Fig. 1 veranschaulicht;

Fig. 7 ist ein Flußdiagramm, welches die Installation ei­ nes aktiven Verbindungsgliedplans in dem Fieldbus-Ab­ schnitt des Prozeßregelnetzwerks von Fig. 1 ver­ anschaulicht;

Fig. 8 ist ein Flußdiagramm, welches die Installation von Veröffentlicher-Bindegliedern in dem Fieldbus-Ab­ schnitt des Prozeßregelnetzwerks von Fig. 1 veran­ schaulicht;

Fig. 9 ist ein Flußdiagramm, welches die Installation ei­ ner Vorrichtungskonfiguration in einer Vorrichtung innerhalb des Fieldbus-Abschnitts des Prozeßregel­ netzwerks von Fig. 1 veranschaulicht;

Fig. 10 ist ein Flußdiagramm, welches die Installation ei­ nes Funktionsblockes innerhalb einer Vorrichtung in dem Fieldbus-Abschnitt des Prozeßregelnetzwerks von Fig. 1 veranschaulicht;

Fig. 11 ist ein Flußdiagramm, welches die Betriebsweise des Funktionsblocks und darauf bezogener Komponenten während des Betriebs eines zentralisierten Steuer­ moduls veranschaulicht, und zwar unter Verwendung des Schattenfunktionsblockes; und

Fig. 12 ist ein Flußdiagramm, welches die Kommunikation von Daten und von Schreibanfragen von einem Block in einem zentralisierten Kontroller oder einem Anwen­ der zu einem externen Funktionsblock in einer Be­ reichsvorrichtung unter Verwendung des Schatten­ funktionsblockes der Erfindung veranschaulicht.

Gemäß Fig. 1 ist ein Prozeßregelnetzwerk 10 in Blockdiagramm­ form veranschaulicht. Das Prozeßregelnetzwerk 10 enthält ei­ nen zentralisierten Prozeßkontroller 12, der eine Prozeßsteu­ erroutine, die in diesem gespeichert ist, implementieren kann. Der Kontroller 12 kann, um hier lediglich ein Beispiel zu nennen, der DeltaV (eingetragene Marke) Kontroller sein, der durch Fisher-Rosemount Systems vertrieben wird, und kann an verschiedene Workstations, wie beispielsweise Personalcom­ puter (PCs) 14 über einen Hub 16 und Ethernet-Verbindungen 18 verbunden sein. In dieser Konfiguration können die PCs 14 durch eine oder mehrere Bedienungspersonen oder Anwender ver­ wendet werden, um mit dem Prozeßkontroller 18 eine Kommunika­ tion herzustellen, um dadurch Informationen zu erhalten, die das Prozeßregelnetzwerk 10 betreffen, um den Status des Pro­ zeßregelnetzwerks 10 zu überblicken oder zu ändern, um Infor­ mationen zu erhalten, die die einzelnen Bereichsvorrichtungen innerhalb des Prozeßregelnetzwerks 10 betreffen usw. Wenn der Kontroller 12 aus einem DeltaV-Kontroller besteht, kann er einen graphischen Ausschnitt der Prozeßsteuer- oder -regel­ routine innerhalb des Kontrollers 12 zu dem Anwender liefern, und zwar über einen der PCs 14, wobei die Funktionsblöcke oder Steuerblöcke innerhalb der Prozeßsteuerroutine veran­ schaulicht werden und auch die Art, in welcher diese Funkti­ onsblöcke miteinander verkettet sind, um die Steuerung oder Regelung eines Prozesses zu bewirken. Der Anwender hat die Möglichkeit, die Prozeßsteuer- oder -regelroutine zu ändern, und zwar innerhalb des zentralisierten Prozeßreglers 12, in­ dem er den graphischen Ausschnitt der Funktionsblöcke inner­ halb der Steuer- oder Regelroutine manipuliert, um Funktions­ blöcke von dieser Steuerroutine wegzulassen oder zu dieser hinzuzufügen und/oder den Weg zu ändern, in welchem die Funk­ tionsblöcke, die der Steuerroutine zugeordnet sind, verkettet sind, das heißt den Weg oder die Art, in welcher sie verbun­ den sind.

Wie in Fig. 1 dargestellt ist, ist der zentralisierte Kon­ troller 12 mit zahlreichen Bereichsvorrichtungen (field devi­ ces) verbunden, die über einen Prozeß hinweg verteilt gelegen sind (allgemein durch das Bezugszeichen 19 angezeigt) . Der zentralisierte Kontroller 12 kann über irgendwelche Standard­ typen I/O-Karten 20 und 22 mit den Bereichsvorrichtungen 26, 28, 30, 32, 34 und 36 kommunizieren, die der zentralisierten Steuerung von dem Kontroller 12 unterworfen sind. Die I/O-Karte 20 kann beispielsweise eine analoge I/O-Karte sein, die den Kontroller 12 mit analogen Bereichsvorrichtungen 24 und 26 verbindet, die über 4-20-mA-Busse 38 kommunizieren. In ähnlicher Weise kann die I/O-Karte 22 eine digitale oder kom­ binierte digitale und analoge I/O-Karte sein, die mit digita­ len oder gemischten digitalen und analogen Bereichsvorrich­ tungen in irgendeinem gewünschten Format kommuniziert, inklu­ sive beispielsweise dem 4-20-mA-Analogformat oder irgendeinem bekannten oder standardisierten Digitalformat. Natürlich kön­ nen die Bereichsvorrichtungen 26, 28, 30, 32, 34 und 36 von irgendeinem gewünschten Typ von Bereichsvorrichtungen beste­ hen, beispielsweise aus Sendern, Sensoren, Ventilstellglie­ dern, Ventilsteuervorrichtungen usw. Es sei in Verbindung mit dem Beispiel des in Fig. 1 veranschaulichten Prozeßregelnetz­ werks 10 darauf hingewiesen, daß die Bereichsvorrichtungen 26-36 Abschnitten des Prozesses 19 zugeordnet sind, die einer zentralisierten Steuerung durch die Steuerroutine innerhalb des Kontrollers 12 unterworfen sind.

Der Kontroller 12 ist ebenfalls kommunikativ mit einer Inter­ facekarte 40 verbunden, die ihrerseits mit (oder Teil ist von) einem externen Prozeßregelnetzwerk, in welchem die Pro­ zeßregelung in einer verteilten Weise durchgeführt wird, oder welcher Vorrichtungen enthält, die Funktionsblöcke haben, die unter Verwendung eines Kommunikationsprotokolls kommunizie­ ren, welches verschieden ist von demjenigen, welches inner­ halb des Kontrollers 12 verwendet wird. Bei der in Fig. 1 veranschaulichten Ausführungsform enthält der dezentralisier­ te Prozeßsteuerabschnitt des Prozesses 19 die Interfacekarte 40, einen Bus 42 und zahlreiche Bereichsvorrichtungen 43, 44, 46, 48 und 50, die an den Bus 42 angeschaltet sind. Das ver­ teilte Prozeßregelnetzwerk von Fig. 1 kann beispielsweise ein Fieldbus-Netzwerk sein, welches das Fieldbus-Kommunika­ tionsprotokoll verwendet. Wie im folgenden noch mehr in Ein­ zelheiten erläutert werden wird, kann die Interfacekarte 40 eine aktive Verbindungsglied-Ablaufsteuerung sein, die dem Fieldbus-Kommunikationsprotokoll zugeordnet ist.

Die zentralisierte Prozeßsteuerroutine, die innerhalb des Kontrollers 12 gelegen ist, empfängt Eingangsgrößen von den Bereichsvorrichtungen 26-36 und möglicherweise 43-50, führt Berechnungen und andere Aktivitäten durch, die mit der Steu­ erroutine verbunden sind, und sendet dann Befehle zu den Be­ reichsvorrichtungen über die I/O-Karten 20 und 22 und die In­ terfacekarte 40, um irgendeine gewünschte Steuerung oder Re­ gelung des Prozesses 19 zu implementieren. Es sei jedoch dar­ auf hingewiesen, daß der dezentralisierte Prozeßsteuer- oder -regelabschnitt des Prozeßregelnetzwerks 10 (das heißt derje­ nige, der dem Bus 42 in Fig. 1 zugeordnet ist) seine eigene Prozeßsteuerroutine in einer dezentralisierten Weise imple­ mentieren kann, wie dies hier noch beschrieben wird, und zwar in Verbindung mit der Steuerung, die durch den Kontroller 12 ausgeführt wird. Während somit der Kontroller 12 mit einer Steuerung gekoppelt sein kann und eine gewisse Steuerung über die Vorrichtungen 43-50, die an den Bus 42 angeschlossen sind, ausführen kann, können diese Vorrichtungen auch Steuer­ funktionen implementieren oder Funktionsblöcke, die mit der Steuerung verbunden sind, welche durch den Kontroller 12 im­ plementiert wird, die jedoch statt dessen über die Vorrich­ tungen, die an den Bus 42 angeschlossen sind, verteilt sind.

Während bei der bevorzugten Ausführungsform der dezentrali­ sierte Abschnitt des Prozeßregelnetzwerks 10 das Field­ bus-Kommunikations- und -Steuerprotokoll verwendet, kann irgend­ ein anderes oder gewünschtes Protokoll ebenso verwendet wer­ den, inklusive den Protokollen, die in der Zukunft entwickelt werden. Ferner kann der Schattenfunktionsblock, der hier of­ fenbart ist, dazu verwendet werden, um eine Kommunikation zwischen irgendwelchen zwei unterschiedlichen Steuer- oder Kommunikationsprotokollen durchzuführen, und es liegt keine Beschränkung auf die Verwendung zwischen einer zentralisier­ ten Steuerroutine und einem dezentralisierten Steuer- oder Regelnetzwerk, wie beispielsweise auf eines, welches das Fieldbus-Protokoll verwendet, vor. Es kann beispielsweise zwischen zwei unterschiedlichen zentralisierten Steuerrouti­ nen oder Protokollen, die Steuerblöcke enthalten, verwendet werden. Mit anderen Worten ist der hier beschriebenen Schat­ tenfunktionsblock nicht darauf beschränkt, mit Funktionsblöc­ ken in dem Fieldbus-Protokoll verwendet zu werden oder sogar mit einem Protokoll, welches einer dezentralisierten Steuer­ routine zugeordnet ist, sondern kann auch dazu verwendet wer­ den, einen Kontroller (oder andere Vorrichtung) dazu zu befä­ higen, mit irgendeiner anderen externen Vorrichtung zu kommu­ nizieren, die irgendeinen unterschiedlichen Typ eines Kommu­ nikationsprotokolls verwendet.

Bevor Einzelheiten des Schattenfunktionsblockes der vorlie­ genden Erfindung erläutert werden und die Art, in welcher der zentralisierten Prozeßkontroller 12 solch einen Schattenfunk­ tionsblock verwendet, um eine Steuerung in einem Prozeßregel­ netzwerk zu implementieren, folgt eine allgemeine Beschrei­ bung des Fieldbus-Protokolls, der Bereichsvorrichtungen, die gemäß diesem Protokoll konfiguriert sind, und die Art, in welcher die Kommunikation in dem Abschnitt des Prozeßregel­ netzwerks 10 erfolgt, der das Fieldbus-Protokoll verwendet. Es sei darauf hingewiesen, daß, obwohl des Fieldbus-Protokoll bereits ein relativ neues gesamtdigitales Kommunikationspro­ tokoll ist, welches für die Verwendung in einem Prozeßregel­ netzwerk entwickelt wurde, dieses Protokoll auf dem Gebiet bekannt ist und in Einzelheiten in vielerlei Artikeln, Bro­ schüren und Beschreibungen beschrieben ist, die veröffent­ licht, verteilt und von der Fieldbus Foundation unter anderem verfügbar sind, einer nicht auf Profit basierenden Organisa­ tion, die ihren Sitz in Austin, Texas, hat. Speziell ist das Fieldbus-Protokoll und die Art der Kommunikation mit und die Art der Speicherung von Daten in Vorrichtungen, die das Fieldbus-Protokoll verwenden, in Einzelheiten in den Bedie­ nungsanleitungen beschrieben, mit dem Titel "Communications Technical Specification" und "User Layer Technical Specifica­ tion" von der Fieldbus Foundation.

Allgemein gesagt, besteht das Fieldbus-Protokoll aus einem insgesamt digitalen, seriellen Zweiwege-Kommunikationsproto­ koll, welches eine standardisierte physikalische Schnittstel­ le für eine Zweidrahtschleife oder Bus schafft, die "Feld"- Ausrüstungen, wie beispielsweise Sensoren, Stellglieder, Kon­ troller, Ventile usw., miteinander verbindet, die in einer Meßgeräteausrüstung oder einer Prozeßsteuer- oder -regelumgebung gelegen sind, beispielsweise in einer Fabrik oder Anlage. Das Fieldbus-Protokoll betrifft im Prinzip ein örtliches Bereichsnetzwerk für Bereichsmeßgeräte (Bereichs­ vorrichtungen) innerhalb eines Prozesses, welches diese Be­ reichsvorrichtungen dazu befähigt, Steuerfunktionen an Stel­ len auszuführen, die über eine Prozeßeinrichtung hinweg ver­ teilt sind, und mit einer anderen zu kommunizieren, vor und nach der Ausführung dieser Steuerfunktionen, um eine Ge­ samtsteuer- oder -regelstrategie zu realisieren. Da das Fieldbus-Protokoll es den Steuerfunktionen ermöglicht, über ein Prozeßregelnetzwerk hinweg verteilt zu sein, reduziert es die Arbeitslast des zentralisierten Prozeßkontrollers für diese Bereichsvorrichtungen oder für die Bereiche des Prozes­ ses.

Ein Prozeßsteuer- oder -regelnetzwerk, welches das Field­ bus-Protokoll verwendet, kann einen Host enthalten, der mit einer Anzahl von anderen Vorrichtungen verbunden ist, wie bei­ spielsweise logischen Programmkontrollern, anderen Hostvor­ richtungen und Bereichsvorrichtungen (field devices) über ei­ ne Zweidraht-Fieldbus-Schleife oder -Bus, wie beispielsweise den Bus 42 von Fig. 1. Der Fieldbus-Bus kann unterschiedliche Abschnitte oder Segmente enthalten, die durch Brückenvorrich­ tungen getrennt sind, wobei jeder Abschnitt des Busses einen untergeordneten Satz der Vorrichtungen verbindet, die an den Bus angebracht sind, um Kommunikationen zwischen den Vorrich­ tungen in einer Weise zu ermöglichen, wie sie im folgenden beschrieben wird. In typischer Weise ist eine Konfiguriervor­ richtung in einer der Vorrichtungen gelegen, wie beispiels­ weise einem Host, und ist für die Einrichtung oder Konfigu­ rierung jeder der Vorrichtungen verantwortlich (die "Smart"-Vor­ richtungen insofern sind, als sie jeweils einen Mikropro­ zessor enthalten, der eine Kommunikation durchführen kann und in einigen Fällen Steuerfunktionen durchführen kann), der aber ebenso erkennen kann, wenn neue Bereichsvorrichtungen an den Fieldbus-Bus angeschlossen werden, wenn die Bereichsvor­ richtungen von dem Bus entfernt werden, der Daten erkennen kann, die durch die Bereichsvorrichtungen, welche an den Bus angeschlossen sind, erzeugt werden, und der eine Kopplung mit einer oder mit mehreren Anwenderterminals bewirkt, die in dem Host oder irgendeiner anderen Vorrichtung gelegen sein kön­ nen, welche in irgendeiner Weise an den Host angeschlossen sind.

Der Fieldbus-Bus unterstützt oder erlaubt zweierlei: eine rein digitale Kommunikation und er kann auch ein Stromversor­ gungssignal zu irgendeiner oder zu all den Vorrichtungen, die an ihn angeschlossen sind, übertragen, wie beispielsweise an die Bereichsvorrichtungen. Alternativ kann irgendeine oder können alle Fieldbus-Vorrichtungen ihre eigene Stromversor­ gung besitzen oder können über separate Leitungen mit exter­ nen Stromversorgungen verbunden sein. Das Fieldbus-Protokoll erlaubt es vielen Vorrichtungen/Verdrahtungstopologien, in­ klusive Vielfachvorrichtungen, an das gleiche Paar von Dräh­ ten oder Leitungen angeschlossen zu werden, erlaubt Punkt-zu- Punkt-Verbindungen, in welchen jede Vorrichtung an einen Kon­ troller oder einen Host über ein getrenntes Zweidrahtpaar an­ geschlossen ist (ähnlich den typischen 4-20 mA Analogsyste­ men) und Baum- oder "spur"-Verbindungen realisiert sind, in denen jede Vorrichtung mit einem gemeinsamen Punkt in einem Zweileitungsbus verbunden ist, der beispielsweise aus einem Kabelkasten oder Verzweigungsstück oder einem Abschlußbereich in einer der Bereichsvorrichtungen innerhalb eines Prozeß­ steuer- oder -regelnetzwerks bestehen kann.

Es können Daten über die Bussegmente in irgendeiner einer An­ zahl von unterschiedlichen Kommunikationsbauraten oder Ge­ schwindigkeiten gemäß dem Fieldbus-Protokoll gesendet werden. Beispielsweise schafft das Fieldbus-Protokoll eine 31,25-Kbit/­ s-Kommunikationsrate (H1) oder eine 1,0-Mbits- und/oder eine 2,5-Mbit/s-(H2)-Kommunikationsrate, die in typischer Weise für eine fortschrittliche Prozeßsteuerung oder -regelung, Ferneingabe-/-ausgabe und für Hochgeschwindig­ keits-Fabrikautomatisationsanwendungen angewendet werden. In gleicher Weise können über den Fieldbus-Bus Daten unter Ver­ wendung einer Spannungsmode-Signalgebung oder einer Strommo­ de-Signalgebung übertragen werden. Die maximale Länge von ir­ gendeinem Fieldbus-Bus oder -Segment ist nicht strikt be­ grenzt, sondern wird statt dessen durch die Kommunikationsra­ te, den Kabeltyp, die Leitungsgröße, Busleistungsoptionen usw. festgelegt.

Das Fieldbus-Protokoll klassifiziert die Vorrichtungen, die an den Bus angeschlossen werden können, in drei primäre Kate­ gorien, nämlich die Basisvorrichtungen, die Verbindungsma­ stervorrichtungen und die Brückenvorrichtungen. Die Basisvor­ richtungen können kommunizieren, das heißt Kommunikations­ signale auf den Bus senden oder von diesem empfangen, sind jedoch nicht dazu befähigt, die Reihenfolge oder Zeitsteue­ rung der Kommunikation zu steuern, die auf dem Bus auftreten. Die Verbindungsmastervorrichtungen bestehen aus Vorrichtun­ gen, die über dem Bus kommunizieren und die Fähigkeit haben, den Fluß und die Zeitsteuerung der Kommunikationssignale auf den Bus zu steuern. Die Brückenvorrichtungen bestehen aus Vorrichtungen, die dafür konfiguriert sind, um mit einzelnen Segmenten oder Zweigen eines Fieldbus-Busses zu kommunizieren oder diese einzelnen Segmente oder Zweige miteinander zu ver­ binden, um ein größere Prozeßsteuer- oder -regelnetzwerk zu erzeugen. Wenn es gewünscht wird, können die Brückenvorrich­ tungen zwischen unterschiedlichen Datengeschwindigkeiten und/oder unterschiedlichen Datensignalisierungsformaten eine Umwandlung vornehmen, die auf den unterschiedlichen Segmenten des Busses verwendet werden, können Signale verstärken, die zwischen den Segmenten des Busses wandern, können die Signale filtern, die zwischen unterschiedlichen Segmenten des Busses verlaufen, und können lediglich solche Signale durchlassen, die dafür bestimmt sind, durch eine Vorrichtung an einem der Bussegmente empfangen zu werden, an welches die Brücke gekop­ pelt ist und/oder können andere Aktionen vornehmen, die er­ forderlich sind, um unterschiedliche Segmente des Busses zu verbinden. Die Brückenvorrichtungen, welche die Bussegmente verbinden, die mit unterschiedlichen Geschwindigkeiten arbei­ ten, müssen Verbindungsmasterfähigkeiten auf der Seite des Segmentes mit niedrigerer Geschwindigkeit der Brücke besit­ zen.

Jede der Fieldbus-Vorrichtungen besitzt die Fähigkeit, über den Bus zu kommunizieren, und, was wichtig ist, die Fähigkeit unabhängig eine oder mehrere Prozeßsteuerfunktionen durchzu­ führen unter Verwendung von Daten, die durch die Vorrichtung von dem Prozeß erworben wurden, oder von einer unterschiedli­ chen Vorrichtung erworben wurden, und zwar über die Kommuni­ kationssignale auf dem Bus. Die Fieldbus-Vorrichtungen besit­ zen daher die Fähigkeit, direkt Abschnitte einer Gesamtsteu­ er- oder -regelstrategie zu implementieren, die in der Ver­ gangenheit durch einen zentralisierten digitalen Kontroller durchgeführt wurden. Um Steuerfunktionen durchzuführen, ent­ hält jede Fieldbus-Vorrichtung einen oder mehrere standardi­ sierte "Blöcke", die in einem Mikroprozessor innerhalb der Vorrichtung implementiert sind. Speziell enthält jede Field­ bus-Vorrichtung einen Ressourcenblock, Null- oder Mehrfunk­ tionsblöcke und Null- oder Mehrwandlerblöcke. Diese Blöcke werden als Blockobjekte bezeichnet.

Ein Ressourcenblock speichert und überträgt spezifische Vor­ richtungsdaten, die einige Charakteristika einer Field­ bus-Vorrichtung betreffen, inklusive beispielsweise einem Vor­ richtungstyp, einer Vorrichtungsrevisionsanzeige und Anzeigen darüber, wo andere spezifische Vorrichtungsinformationen in­ nerhalb eines Speichers der Vorrichtung erhalten werden kön­ nen. Während verschiedene Vorrichtungshersteller unterschied­ liche Typen der Daten in dem Ressourcenblock einer Bereichs­ vorrichtung speichern können, enthält jede Bereichsvorrich­ tung, die mit dem Fieldbus-Protokoll konform ist, einen Res­ sourcenblock, der einige Daten speichert.

Ein Funktionsblock definiert und implementiert eine Eingabe­ funktion, eine Ausgabefunktion oder eine Steuerfunktion, die der Bereichsvorrichtung zugeordnet ist und es werden somit Funktionsblöcke allgemein als Eingabe-, Ausgabe- und Steuer­ funktionsblöcke bezeichnet. Es können jedoch andere Kategori­ en von Funktionsblöcken existieren, wie beispielsweise Hy­ brid-Funktionsblöcke, oder können auch in der Zukunft entwic­ kelt werden. Jeder Eingabe- oder Ausgabefunktionsblock er­ zeugt wenigstens eine Prozeßsteuereingangsgröße (wie bei­ spielsweise eine Prozeßvariable aus einer Prozeßmeßvorrich­ tung) oder eine Prozeßsteuerausgangsgröße (wie beispielsweise eine Ventilposition, die zu einer Stellvorrichtung gesendet wird), während jeder Steuerfunktionsblock einen Algorithmus verwendet (der in seiner Natur geschützt oder firmeneigen sein kann), um eine oder mehrere Prozeßausgangsgrößen aus ei­ ner oder aus mehreren Prozeßeingangsgrößen und aus Steuerein­ gangsgrößen zu erzeugen. Beispiele von Standardfunktionsblöc­ ken umfassen Analogeingangs(AI)-, Analogausgangs(AO)-, Vor­ spann(B)-, Steuerwähl(CS)-, Diskreteingangs(DI)-, Diskretaus­ gangs(DO)-, Handlade(ML)-, Proportional/Differential(PD)-, Proportional/Integral/Differential(PDI)-, Verhältnis(RA)- und Signalwähl(SS)-Funktionsblöcke. Es existieren jedoch andere Typen von Funktionsblöcken und neue Typen von Funktionsblöc­ ken können festgelegt oder hergestellt werden, um in der Fieldbus-Umgebung zu arbeiten.

Ein Wandlerblock koppelt die Eingangsgrößen und Ausgangsgrö­ ßen eines Funktionsblockes an die örtlichen Hardwarevorrich­ tungen, wie beispielsweise an Sensoren und Vorrichtungsstell­ glieder, um die Funktionsblöcke dazu zu befähigen, die Aus­ gangsgrößen von örtlichen Sensoren zu lesen und die örtlichen Vorrichtungen mit Befehlen zu versehen, um eine oder mehrere Funktionen, wie beispielsweise das Bewegen eines Ventilteiles auszuführen. Wandlerblöcke enthalten in typischer Weise In­ formationen, die erforderlich sind, um Signale zu interpre­ tieren, die durch eine örtliche Vorrichtung abgeleitet wur­ den, und um in richtiger Weise die örtlichen Hardwarevorrich­ tungen zu steuern, wobei diese Informationen beispielsweise Information enthalten, die den Typ einer örtlichen Vorrich­ tung identifizieren, Eichungsinformationen, die einer örtli­ chen Vorrichtung zugeordnet sind, betreffen usw. Ein einzel­ ner Wandlerblock ist in typischer Weise jedem Eingabe- oder Ausgabefunktionsblock zugeordnet.

Die meisten Funktionsblöcke sind dazu befähigt, Alarm oder Ereignisanzeigen zu generieren, basierend auf vorbestimmten Kriterien, und haben die Fähigkeit unterschiedlich in ver­ schiedenen Modi zu arbeiten. Allgemein gesagt, können Funkti­ onsblöcke in einem automatischen Modus arbeiten, in welchem beispielsweise der Algorithmus eines Funktionsblockes automa­ tisch arbeitet; in einem Operatormodus arbeiten, in welchem der Eingang oder der Ausgang eines Funktionsblockes von Hand gesteuert wird; einem Außer-Servicemodus arbeiten, in welche der Block nicht arbeitet; in einem Kaskadenmodus arbeiten, in welchem die Operation des Blockes von der Ausgabegröße eines verschiedenen Blockes beeinflußt wird (durch diesen bestimmt wird); und in einem oder mehreren Entfernungsmodi arbeiten, in welchen ein entfernt gelegener Computer den Modus des Blocks bestimmt. Es existieren jedoch in dem Fieldbus-Proto­ koll andere Betriebsmodi.

Als wichtiges Merkmal besitzt jeder Block die Fähigkeit, mit anderen Blöcken in der gleichen oder unterschiedlichen Be­ reichsvorrichtungen über den Fieldbus-Bus zu kommunizieren, und zwar unter Verwendung von Standardnachrichtenformaten, die durch das Fieldbus-Protokoll festgelegt sind. Als ein Er­ gebnis können Kombinationen von Funktionsblöcken (in den gleichen oder unterschiedlichen Vorrichtungen) miteinander kommunizieren, um eine oder mehrere dezentralisierte Regel­ schleifen zu erzeugen. Es kann somit beispielsweise ein PID-Funktionsblock in einer Bereichsvorrichtung über den Field­ bus-Bus angeschlossen sein, um eine Ausgangsgröße eines AI-Funktionsblocks in einer zweiten Bereichsvorrichtung zu emp­ fangen, um Daten an einen AO-Funktionsblock in einer dritten Bereichsvorrichtung zu liefern, um eine Ausgangsgröße eines AO-Funktionsblocks als Rückkopplungsgröße zu empfangen, um eine Prozeßregelschleife getrennt und neben irgendeinem zen­ tralisierten Kontroller zu erzeugen. Auf diese Weise bewegen Kombinationen von Funktionsblöcken die Steuerfunktionen aus einer zentralisierten DCS-Umgebung heraus, was die Möglich­ keit schafft, daß DCS-Vielfunktionskontroller Überwachungs- oder Koordinationsfunktionen durchführen. Ferner erlauben es die Funktionsblöcke, eine graphische blockorientierte Struk­ tur zu verwenden, und zwar eine einfache Konfiguration eines Prozesses, und ermöglichen die Verteilung der Funktionen un­ ter den Bereichsvorrichtungen von unterschiedlichen Zuliefe­ rern, da diese Blöcke ein konsistentes Kommunikationsproto­ koll verwenden.

Zusätzlich zu dem Merkmal, daß Bereichsvorrichtungen Blockob­ jekte enthalten und implementieren, enthält jede Bereichsvor­ richtung ein oder mehrere andere Objekte, inklusive Verbin­ dungsobjekten, Trendobjekten, Warnobjekten und Betrachtungs­ objekten. Verbindungsobjekte definieren die Verbindungen zwi­ schen den Eingängen und Ausgängen der Blöcke (wie den Funkti­ onsblöcken), und zwar sowohl intern in der Bereichsvorrich­ tung als auch über den Fieldbus-Bus hinweg. Trendobjekte er­ lauben einen örtlichen Trend von Funktionsblockparametern für den Zugriff auf andere Vorrichtungen, wie beispielsweise ei­ nen Host oder einen Kontroller. Trendobjekte halten histori­ sche Kurzzeitdaten, die einige, beispielsweise den Funktions­ blockparameter, betreffen und berichten diese Daten an andere Vorrichtungen oder Funktionsblöcke, und zwar über den Field­ bus-Bus in einer asynchronen Weise. Warnobjekte berichten über Alarme und Ereignisse über den Fieldbus-Bus. Diese Alar­ me oder Ereignisse können irgendein Ereignis betreffen, wel­ ches innerhalb einer Vorrichtung stattfindet oder innerhalb einem der Blöcke einer Vorrichtung. Betrachtungsobjekte sind vordefinierte Gruppierungen von Blockparametern, die in stan­ dardisierten Mensch/Maschine-Schnittstellenbereichen verwen­ det werden und die zu anderen Vorrichtungen gesendet werden können, und zwar unter Verwendung von asynchronen Übertragun­ gen, um eine Betrachtung von Zeit zu Zeit zu ermöglichen.

In Fig. 2 sind drei Fieldbus-Vorrichtungen veranschaulicht, die beispielsweise aus irgendeiner der Bereichsvorrichtungen 43-50 von Fig. 1 bestehen, und diese enthalten Ressourcen­ blöcke 58, Funktionsblöcke 60, 61 oder 62 und Wandlerblöcke 63 und 64. In der ersten Vorrichtung ist der Funktionsblock 60 (der aus einem Eingabefunktionsblock besteht) über den Wandlerblock 63 mit einem Sensor 65 gekoppelt, der beispiels­ weise aus einem Temperatursensor, einem Sollpunkt­ anzeigesensor usw. bestehen kann. In der zweiten Vorrichtung ist der Funktionsblock 61 (der aus einem Ausgabefunktions­ block bestehen kann) über den Wandlerblock 64 an eine Ausga­ bevorrichtung, wie beispielsweise ein Ventil 66, gekoppelt. In der dritten Vorrichtung enthält der Funktionsblock 62 (der aus einem Steuerfunktionsblock bestehen kann) ein Trendobjekt 67, welches diesem zugeordnet ist, um den Trend des Eingangs­ parameters des Funktionsblocks 62 zu ermitteln.

Die Verbindungsobjekte 68 definieren die Verbindungen von Blockparametern von jedem der zugeordneten Blöcke und die Warnobjekte 69 erzeugen Alarme oder Ereignisbenachrichtigun­ gen für jeden der zugeordneten Blöcke. Betrachtungsobjekte 70 sind mit jedem der Funktionsblöcke 60, 61 und 62 zugeordnet und enthalten Gruppendatenlisten für die Funktionsblöcke, zu denen sie zugeordnet sind. Diese Listen enthalten Informatio­ nen, die für jeden eines Satzes von unterschiedlich definier­ ten Betrachtungen erforderlich sind. Natürlich stellen die Vorrichtungen von Fig. 2 lediglich Beispiele dar und andere Zahlen und Typen von Blockobjekten, Verbindungsobjekten, Warnobjekten, Trendobjekten und Betrachtungsobjekten können in irgendeiner Bereichsvorrichtung vorgesehen sein.

Um eine Kommunikation und Steueraktivitäten zu implementieren und auszuführen, verwendet das Fieldbus-Protokoll drei allge­ meine Kategorien der Technologie, die als eine physikalische Schicht, als ein Kommunikations-"Stapel" und eine Anwender­ schicht definiert sind. Die Anwenderschicht enthält die Steu­ er- und Konfigurationsfunktionen, die in Form der Blöcke vor­ gesehen werden (wie beispielsweise den Funktionsblöcken) und Objekte innerhalb irgendeiner bestimmten Prozeßsteuervorrich­ tung oder Bereichsvorrichtung. Die Anwenderschicht ist in ty­ pischer Weise in einer geschützten Weise ausgelegt oder kon­ struiert, und zwar durch den Hersteller der Vorrichtung, muß jedoch die Fähigkeit haben, Nachrichten zu empfangen und aus­ zusenden, und zwar in Einklang mit dem Standardnachrichten­ format, welches durch das Fieldbus-Protokoll festgelegt ist, und muß durch einen Anwender in der standardisierten Weise konfigurierbar sein. Die physikalische Schicht und der Kommu­ nikationsstapel sind erforderlich, um eine Nachrichtenverbin­ dung zwischen unterschiedlichen Blöcken unterschiedlicher Feld- oder Bereichsvorrichtungen in einer standardisierten Weise zu bewirken, und zwar unter Verwendung eines Zweidraht­ busses, und können durch das gut bekannte Open-Systems-Inter­ connect-(OSI)-Schicht-Kommunikationsmodell modelliert sein.

Die physikalische Schicht, die der OSI-Schicht 1 entspricht, ist in jeder Bereichsvorrichtung und in dem Bus eingebettet und arbeitet dahingehend, um elektromagnetische Signale, die von dem Fieldbus-Übertragungsmedium (dem Fieldbus-Zwei­ drahtbus) empfangen werden, in Nachrichten umzusetzen, die durch den Kommunikationsstapel der Bereichsvorrichtung verwendet werden können. Die physikalische Schicht kann als ein Fieldbus-Bus und elektromagnetischen Signalen, die auf dem Bus an den Eingängen und Ausgängen der Bereichsvorrich­ tungen vorhanden sind, betrachtet werden.

Der Kommunikationsstapel, der in jeder Fieldbus-Vorrichtung vorhanden ist, enthält eine Datenverbindungsschicht, die der OSI-Schicht 2 entspricht, eine Fieldbus-Zugriffs-Sub-Schicht und eine Fieldbus-Nachricht-Spezifikationsschicht Die Anwen­ derschicht des Fieldbus-Protokolls besteht aus einer Schicht, die in dem OSI-Protokoll nicht definiert ist. Jede Schicht in dem Kommunikationsstapel ist für die Kodierung und Dekodie­ rung eines Abschnitts der Nachricht oder des Signals verant­ wortlich, welches über den Fieldbus-Bus übertragen wird. Als ein Ergebnis addiert oder entfernt jede Schicht des Kommuni­ kationsstapels gewisse Abschnitte des Fieldbus-Signals, wie beispielsweise die Präambeln, Startbegrenzer und Endebegren­ zer, und in einigen Fällen, dekodiert sie Bandabschnitte des Fieldbus-Signals, um eine Identifizierung darüber durchzufüh­ ren, ob der Rest des Signals oder der Nachricht gesendet wer­ den sollte oder ob das Signal gelöscht werden sollte, da es beispielsweise eine Nachricht oder Daten für Funktionsblöcke enthält, die nicht innerhalb der empfangenden Bereichsvor­ richtung vorhanden sind.

Die Datenverbindungsschicht steuert die Übertragung von Nach­ richten auf dem Fieldbus-Bus und managt den Zugriff auf den Bus gemäß einer deterministischen zentralisierten Busablauf­ steuerung (scheduler), der als ein verbindungsaktiver Abwick­ ler bezeichnet wird, der im folgenden noch mehr in Einzelhei­ ten beschrieben wird. Die Datenverbindungsschicht entfernt eine Präambel von den Signalen auf dem Übertragungsmedium und kann die empfangene Präambel verwenden, um den internen Takt der Bereichsvorrichtung mit dem ankommenden Fieldbus-Signal zu synchronisieren. In ähnlicher Weise wandelt die Datenver­ bindungsschicht die Nachrichten auf dem Kommunikationsstapel in physikalische Fieldbus-Signale um und kodiert diese Signa­ le mit der Taktinformation, um ein "synchrones serielles" Si­ gnal mit einer richtigen Präambel für die Übertragung auf dem Zweidrahtbus oder -schleife zu erzeugen. Während des Dekodie­ rungsprozesses erkennt die Datenverbindungsschicht spezifi­ sche Kodes innerhalb der Präambel, wie beispielsweise Start­ begrenzer und Endebegrenzer, um den Anfang und das Ende einer bestimmten Fieldbus-Nachricht zu identifizieren, und kann ei­ ne Prüfsumme erstellen, um die Integrität des Signals oder der Nachricht, die von dem Bus empfangen wurde, zu verifizie­ ren. In ähnlicher Weise überträgt die Datenverbindungsschicht die Fieldbus-Signale auf den Bus, indem sie Start- und Ende­ begrenzer zu den Nachrichten auf dem Datenkommunikationssta­ pel hinzufügt und indem sie diese Signale auf das Übertra­ gungsmedium zu einer geeigneten Zeit setzt.

Die Fieldbus-Nachrichten-Spezifikationsschicht erlaubt es der Anwenderschicht (das heißt den Funktionsblöcken, Objekten usw. einer Bereichsvorrichtung), über den Bus zu kommunizie­ ren, und zwar unter Verwendung eines Standardsatzes von Nach­ richtenformaten und beschreibt den Kommunikationsservice, die Nachrichtenformate und die Protokollverhaltensweisen, die er­ forderlich sind, um Nachrichten herzustellen, die auf den Kommunikationsstapel zu setzen sind und die für die Anwender­ schicht vorzusehen sind. Da die Fieldbus-Nachrichten-Spezi­ fikationsschicht standardisierte Kommunikationen für die Anwenderschicht liefert, sind spezifische Fieldbus-Nach­ richten-Spezifikations-Kommunikationsdienste für jeden Typ des oben beschriebenen Objekts festgelegt. Beispielsweise enthält die Fieldbus-Nachrichten-Spezifikationsschicht Ob­ jektwörterbuchdienste, die es dem Anwender ermöglichen, in einem Objektwörterbuch einer Vorrichtung zu lesen. Das Ob­ jektwörterbuch speichert Objektbeschreibungen, welche jedes der Objekte beschreiben oder identifizieren (wie beispiels­ weise Blockobjekte), und zwar von einer Vorrichtung. Die Fieldbus-Nachrichten-Spezifikationsschicht ermöglicht auch variable Zugriffsdienste, die es einem Anwender ermöglichen, Kommunikationsbeziehungen, die als virtuelle Kommunikations­ beziehungen (VCRs) bekannt sind und im folgenden beschrieben werden, die einer oder mehreren Objekten einer Vorrichtung zugeordnet sind, zu lesen und zu ändern. Darüber hinaus schafft die Fieldbus-Nachrichten-Spezifikationsschicht ein Kontextmanagement, variable Zugriffsdienste, Ereignisdienste, Hochlade- und Herunterladedienste und Programmaufrufdienste, die alle in Verbindung mit dem Fieldbus-Protokoll gut bekannt sind und daher hier nicht in Einzelheiten beschrieben werden. Die Fieldbus-Zugriffs-Sub-Schicht bildet die Fieldbus-Nach­ richten-Spezifikationsschicht in der Datenverbindungs­ schicht ab.

Um einen Betrieb dieser Schichten zuzulassen oder zu ermögli­ chen, enthält jede Fieldbus-Vorrichtung eine Managementinfor­ mationsbasis (MIB), die aus einer Datenbasis oder Datenbank besteht, die VCRs, dynamische Variable, statistische Größen, Zeitsteuerpläne, Funktionsblockausführungszeitsteuerpläne und eine Vorrichtungsetikette (device tag) und Adresseninforma­ tionen speichert. Natürlich können die Informationen inner­ halb der MIB zugegriffen werden oder zu irgendeiner Zeit un­ ter Verwendung der Standard-Fieldbus-Nachrichten oder -Befehle geändert werden. Ferner ist gewöhnlich eine Vorrich­ tungsbeschreibung für jede Vorrichtung vorgesehen, um einem Anwender oder einem Host einen weiten Überblick an Informa­ tionen in der VFD zu geben. Eine Vorrichtungsbeschreibung, die in typischer Weise in Form einer Sendeerlaubnis, um von einem Host verwendet zu werden, festgelegt ist, speichert In­ formationen, die für den Host erforderlich sind, um die Be­ deutung der Daten in den VFDs einer Vorrichtung zu verstehen.

Wie ersehen werden kann, muß die Implementierung von irgend­ einer Steuerstrategie unter Verwendung der Funktionsblöcke, die über ein Prozeßregelnetzwerk verteilt angeordnet sind, die Ausführung der Funktionsblöcke präzise geplant werden, und zwar in bezug auf die Ausführung von anderen Funktions­ blöcken in einer bestimmten Regelschleife. In ähnlicher Weise muß die Kommunikation zwischen unterschiedlichen Funktions­ blöcken in präziser Weise auf dem Bus geplant werden, so daß die richtigen Daten zu jedem Funktionsblock übertragen wer­ den, bevor dieser Block ein Programm ausführt.

Der Weg, mit welchem unterschiedliche Bereichsvorrichtungen (und unterschiedliche Blöcke innerhalb den Bereichsvorrich­ tungen) über das Fieldbus-Übertragungsmedium kommunizieren, soll nun beschrieben werden. Damit eine Kommunikation statt­ findet, arbeitet eine der Verbindungsmastervorrichtungen auf jedem Segment der Fieldbus-Schleife als ein verbindungsakti­ ver Abwickler (LAS), der aktiv die Kommunikation auf dem zu­ geordneten Segment des Busses abwickelt und steuert. Das LAS für jedes Segment des Busses speichert einen Kommunikations­ plan (einen verbindungsaktiven Plan), der Zeitpunkte enthält, bei denen jeder Funktionsblock von jeder Vorrichtung geplant ist, periodisch die Kommunikationsaktivität auf dem Bus zu starten und auch die Länge der Zeit geplant ist, während wel­ cher diese Kommunikationsaktivität stattfinden muß. Während lediglich eine und nur eine aktive LAS-Vorrichtung auf jedem Segment des Busses vorhanden sein kann, können andere Verbin­ dungsmastervorrichtungen als Backup-LASs dienen und können beispielsweise dann aktiv werden, wenn die momentane LAS aus­ fällt. Die Basisvorrichtungen haben nicht die Fähigkeit, eine LAS zu irgendeinem Zeitpunkt zu werden.

Allgemein gesagt, werden die Kommunikationsaktivitäten über den Bus eingeteilt in Wiederholungsmakrozyklen, die den syn­ chronen Kommunikationsplan für den Bus definieren. Eine Vor­ richtung kann aktiv sein, das heißt Daten zu irgendeinem Seg­ ment des Busses senden oder von diesem empfangen, und zwar selbst wenn sie physikalisch an ein unterschiedliches Segment des Busses angeschlossen ist, und zwar durch eine koordinier­ te Operation der Brücken und der LASs auf dem Bus.

Während jedes Makrozyklusses führt jeder der Funktionsblöcke, die auf einem bestimmten Segment des Busses aktiv sind, ge­ wöhnlich zu einem unterschiedlichen, jedoch präzise geplanten (synchronen) Zeitpunkt oder Zeit ein Programm durch. Wenn der Funktionsblock einen Ausgangsparameter hat, der mit einem an­ deren Parameter extern zu der Vorrichtung verkettet ist, so veröffentlicht der Funktionsblock seine Ausgangsdaten in ei­ ner präzise geplanten Zeit im Ansprechen auf einen Erzwin­ gungsdatenbefehl, der durch die LAS erzeugt wurde. In bevor­ zugter Weise ist jeder Funktionsblock so eingeplant, daß er seine Ausgabedaten kurz nach dem Ende der Ausführungsperiode des Funktionsblockes veröffentlicht. Ferner sind die Daten­ veröffentlichungszeitpunkte der verschiedenen Funktionsblöcke in serieller Form geplant oder einer Ablaufsteuerung unter­ worfen, so daß keine zwei Funktionsblöcke auf einem bestimm­ ten Segment des Busses Daten zur gleichen Zeit veröffentli­ chen. Während der Zeit, während welcher eine synchrone Kommu­ nikation nicht stattfindet, hat jede Bereichsvorrichtung die Möglichkeit, ihrerseits Alarmdaten, Betrachtungsdaten usw. in einer asynchronen Weise zu senden, und zwar unter Verwendung von sendeanfrage-angetriebenen Kommunikationen. Der Ausfüh­ rungs- oder Ablaufplan ist in einer Mangementinformationsba­ sis (MIB) abgespeichert, es sind die Ausführungszeitpunkte der Blöcke in den Funktionsblöcken gespeichert und es sind die Zeitpunkte zum Senden der Zwangsdatenbefehle zu jeder der Vorrichtungen auf einem Segment des Busses in der MIB der LAS-Vorrichtung für dieses Segment gespeichert. Diese Zeit­ punkte werden in typischer Weise als Offsetzeiten gespei­ chert, da sie die Zeiten oder Zeitpunkte identifizieren, zu welchen Funktionsblock ein Programm ausführen oder Daten sen­ den muß, und zwar in einer Versetzung (Offset) vom Anfang ei­ ner "absoluten Verbindungsplanstartzeit", die allen Vorrich­ tungen, die an den Bus angeschlossen sind, bekannt ist.

Um Kommunikationen zwischen jedem Makrozyklus zu bewirken, sendet die LAS einen Zwangsdatenbefehl zu jeder der Vorrich­ tungen auf dem zugeordneten Bussegment gemäß der Liste der Sendezeitpunkte, die in dem verbindungsaktiven Plan gespei­ chert sind. Nach dem Empfang eines Zwangsdatenbefehls veröf­ fentlicht ein Funktionsblock einer Vorrichtung seine Ausgabe­ daten auf dem Bus. Da jeder der Funktionsblöcke typischerwei­ se einer Ablaufsteuerung unterliegt, um ein Programm aus zu­ führen, so daß die Ausführung des Programms dieses Blocks vervollständigt wird, kurz bevor der Block im Plan dafür vor­ gesehen ist, einen Zwangsdatenbefehl zu empfangen, sollten die Daten, die im Ansprechen auf einen Zwangsdatenbefehl ver­ öffentlicht werden, die allerletzten Ausgangsdaten des Funk­ tionsblockes sein. Wenn jedoch ein Funktionsblock in der Pro­ grammausführung langsam ist und keine neuen Ausgangsgrößen verriegelt hat, wenn er den Zwangsdatenbefehl empfängt, ver­ öffentlicht der Funktionsblock die Ausgangsdaten, die während des letzten Laufes des Funktionsblockes erzeugt wurden.

Während der Perioden, in welchen die Zwangsdatenveröffentli­ chungen nicht geplant sind, kann die LAS asynchrone Kommuni­ kationsaktivitäten aktivieren. Um eine asynchrone Kommunika­ tion zu bewirken, sendet die LAS eine Durchlaß-Token-Nach­ richt zu einer bestimmten Bereichsvorrichtung. Wenn eine Bereichsvorrichtung eine Durchlaß-Token-Nachricht empfängt, erlangt diese Bereichsvorrichtung vollen Zugriff auf den Bus (oder ein Segment desselben) und kann asynchron Nachrichten senden, wie beispielsweise Alarmnachrichten, Trenddaten, Ope­ rator-Sollpunktänderungen usw., bis die Nachrichten vervoll­ ständigt sind oder bis eine maximal zugewiesene "Token-Halte­ zeit" verstrichen ist. Danach gibt die Feldvorrichtung den Bus frei (oder irgendein bestimmtes Segment desselben) und die LAS sendet eine Durchlaß-Token-Nachricht zu einer an­ deren Vorrichtung. Dieser Prozeß wird wiederholt, bis die LAS entweder gemäß dem Plan einen Zwangsdatenbefehl aussendet, um eine synchrone Kommunikation zu bewirken, oder die LAS eine Netzwerkwartung durchzuführen hat. Natürlich kann abhängig vom Ausmaß des Nachrichtenverkehrs und der Zahl der Vorrich­ tung und der Blöcke, die an ein bestimmtes Segment des Busses gekoppelt sind, nicht jede Vorrichtung eine Durchlaß-Token-Nach­ richt während jedes Makrozyklusses empfangen.

Fig. 3 veranschaulicht ein Zeitsteuerschema, welches die Zeitpunkte herausgreift, bei den die Funktionsblöcke (mit AL_LOOP1, PID_LOOP1, AI_LOOP2, AO_LOOP1, SS_LOOP2 und PID_LOOP3) ein Programm ausführen, und zwar während jedes Makrozyklusses eines Bus­ segmentes, und die Zeitpunkte, bei denen eine synchrone Kom­ munikation während jedes Makrozyklusses stattfindet, der dem Bussegment zugeordnet ist. In dem Zeitsteuerplan von Fig. 3 ist die Zeit auf der horizontalen Achse aufgetragen und die Aktivitäten, die den unterschiedlichen Funktionsblöcken zuge­ ordnet sind, sind auf der vertikalen Achse veranschaulicht. Die Regelschleife (die zum Zwecke der Erläuterung willkürlich ist), in welcher jeder der Funktionsblöcke arbeitet, ist in Fig. 3 als Indexangabe identifiziert. Somit verweist AI_LOOP1 auf den AI-Funktionsblock von beispielsweise einem Sender, der innerhalb einer ersten Regelschleife arbeitet, PID_LOOP1 verweist auf den PID-Funktionsblock in beispielsweise einem Stellwerk/Ventil, welches innerhalb der ersten Regelschleife arbeitet, usw. Die Blockausführungsperiode von jedem der ver­ anschaulichten Funktionsblöcke ist durch ein kreuz­ strichliertes Kästchen herausgestellt, während jede geplante synchrone Kommunikation durch einen vertikalen Balken in Fig. 3 identifiziert ist.

Somit führt gemäß dem Zeitsteuerplan von Fig. 3 während ir­ gendeines bestimmten Makrozyklusses des Bussegments der AI_LOOP1-Funktionsblock zuerst ein Programm aus, und zwar für die Zeitperiode, die durch das Kästchen 71 spezifiziert ist. Dann, während der Zeitperiode, die durch den vertikalen Bal­ ken 72 angezeigt ist, wird die Ausgangsgröße des AI_LOOP1-Funktions­ blockes auf dem Bussegment im Ansprechen auf einen Zwangsdatenbefehl von der LAS für das Bussegment veröffent­ licht. In ähnlicher Weise zeigen die Kästchen 74, 76, 78, 80 und 80 die Ausführungszeiten der jeweiligen Funktionsblöcke PID_LOOP1, AI_LOOP2, AO_LOOP1, SS_LOOP2 und PID_LOOP3, die für jeden der unterschiedlichen Blöcke verschieden sind, an, während die vertikalen Balken 82, 84, 86, 88 und 89 die Zeiten anzeigen, zu welchen die jeweiligen Funktionsblöcke PID_LOOP1, AI_LOOP2, AO_LOOP1, SS_LOOP2 und PID_LOOP3 Daten auf dem Bussegment veröffent­ lichen.

Wie zu erkennen ist, veranschaulicht das Zeitsteuerschema von Fig. 3 auch die Zeitpunkte oder Zeiten, die für asynchrone Kommunikationsaktivitäten verfügbar sind, die während der Ausführungszeiten von irgendeinem der Funktionsblöcke auftre­ ten können und während der Zeit am Ende des Makrozyklusses, während welcher keiner der Funktionsblöcke ein Programm aus­ führt und wenn keine synchrone Kommunikation auf dem Busseg­ ment stattfindet. Wenn es natürlich gewünscht wird, können unterschiedliche Funktionsblöcke beabsichtigt so eingeplant werden, daß sie ein Programm zur gleichen Zeit ausführen und daß nicht alle Funktionsblöcke Daten auf dem Bus veröffentli­ chen müssen, wenn beispielsweise keine andere Vorrichtung an den Datenteil hat, die durch einen Funktionsblock erzeugt werden.

Bereichsvorrichtungen können Daten veröffentlichen oder über­ tragen und können Nachrichten über den Fieldbus-Bus übertra­ gen, und zwar unter Verwendung von einer der drei virtuellen Kommunikationsbeziehungen (VCRs), die in der Fieldbus-Zu­ griffs-Sub-Schicht des Stapels von jeder Bereichsvorrich­ tung definiert sind. Ein Client/Server-VCR wird für in eine Warteschlange eingereihte, nicht geplante, vom Anwender in­ itialisierte Eins-zu-Eins-Kommunikationen zwischen den Vor­ richtungen auf dem Bus verwendet. Solche in eine Warteschlan­ ge eingereihten Nachrichten werden in der Reihenfolge gesen­ det und empfangen, wie sie für die Aussendung geliefert wer­ den, und zwar gemäß deren Priorität, ohne daß dabei frühere Nachrichten überschrieben werden. Somit kann eine Bereichs­ vorrichtung einen Client/Server-VCR verwenden, wenn sie eine Durchlaß-Token-Nachricht von einem LAS empfängt, um eine An­ fragenachricht zu einer anderen Vorrichtung auf dem Fieldbus- Bus zu senden. Der Anfrager wird als "Client" bezeichnet und die Vorrichtung, die die Anfrage empfängt, wird als "Server" bezeichnet. Der Server sendet eine Antwort, wenn er eine Durchgangs-Token-Nachricht von dem LAS empfängt. Der Cli­ ent/Server-VCR wird beispielsweise dazu verwendet, um opera­ tor-initialisierte Anfragen, wie beispielsweise Sollpunktän­ derungen, Abstimmparameter, Zugriff und Änderungen, Alarmbe­ stätigungen und Vorrichtungs-up und -downloads zu bewirken.

Ein Reportverteiler VCR wird für die in eine Warteschlange eingereiht, nicht geplanten, anwenderinitialisierten Kommuni­ kationen von einer bis mehreren Kommunikationen verwendet. Wenn beispielsweise eine Bereichsvorrichtung mit einem Ereig­ nis- oder einem Trendreport ein Durchgangs-Token von einer LAS empfängt, so sendet diese Bereichsvorrichtung ihre Nach­ richt zu einer "Gruppenadresse", die in der Fieldbus-Zu­ griffs-Sub-Schicht des Kommunikationsstapels dieser Vor­ richtung definiert ist. Die Vorrichtungen, die dafür konfigu­ riert sind, um auf dieses VCR zu horchen, werden den Report empfangen. Der Reportverteilungs-VCR-Typ wird in typischer Weise durch die Fieldbus-Vorrichtungen verwendet, um Alarmbe­ nachrichtigungen zu Bedienungskonsolen zu senden.

Ein Herausgeber/Benutzer-VCR-Typ wird dazu verwendet, um eine bis viele Kommunikationen zu puffern. Die gepufferten Kommu­ nikationen sind solche, die lediglich die späteste Version der Daten speichern und senden und es überschreiben daher neue Daten vollständig die früheren Daten. Die Funktionsaus­ gangsgrößen umfassen beispielsweise gepufferte Daten. Eine "Veröffentlicher"-Bereichsvorrichtung veröffentlicht oder sendet eine Nachricht unter Verwendung des Veröffentli­ cher/Benutzer-VCR-Typs an alle die "Benutzer"-Bereichs-vor­ richtungen an den Fieldbus-Bus, wenn die Veröffentlichervor­ richtung eine Zwangsdatennachricht von der LAS oder von einer Benutzer- oder Teilnehmervorrichtung empfängt. Die Veröffent­ licher-/Benutzerbeziehungen sind vorbestimmt und sind inner­ halb der Fieldbus-Zugriffs-Sub-Schicht des Kommunikationssta­ pels von jeder Bereichsvorrichtung definiert und gespeichert.

Um richtige Kommunikationsaktivitäten über den Fieldbus-Bus sicherzustellen, sendet jede LAS periodisch eine Zeitvertei­ lungsnachricht an alle Bereichsvorrichtungen, die an ein Seg­ ment des Busses angeschlossen sind, was des den empfangenden Vorrichtungen ermöglicht, ihre örtliche Datenverbindungszeit so einzustellen, daß sie miteinander synchronisiert sind. Zwischen diesen Synchronisationsnachrichten wird die Taktzeit unabhängig in jeder Vorrichtung beibehalten, und zwar basie­ rend auf deren eigenem internem Takt. Eine Taktsynchronisati­ on erlaubt es den Bereichsvorrichtungen, die Funktions­ block-Programmausführung mit dem Netzwerk zu synchronisieren.

Wie aus der oben gegebenen Erläuterung des Fieldbus-Kommuni­ kationsprotokolls hervorgeht, erfordert eine Kommunikation mit irgendeiner speziellen Vorrichtung oder einem Funktions­ block, der innerhalb des Fieldbus-Abschnitts des Prozeßregel­ netzwerks 10 gelegen ist, das heißt an den Bus 42 angeschlos­ sen ist, detailliertes Wissen darüber, auf welche Weise die Kommunikation innerhalb des Fieldbus-Protokolls im allgemei­ nen bewirkt wird, als auch eine Betrachtung darüber und ein Wissen davon, wie der Fieldbus-Bus 42 speziell aufgebaut ist und wann Kommunikationen, die diesem zugeordnet sind, geplant sind und erlaubt werden. Dies macht es seinerseits für den Designer der Prozeßregelroutine schwierig, die in dem Kon­ troller 12 implementiert ist, Kommunikationen mit den Vor­ richtungen innerhalb des Fieldbus-Abschnitts des Prozeßregel­ netzwerks zu implementieren und zu planen, das heißt den Vor­ richtungen, die an den Bus 42 angeschlossen sind. Da darüber hinaus Standard- oder reguläre Kommunikationen zwischen den Funktionsblöcken in einer synchronen Weise über den Bus 42 erfolgen, muß der Kontroller 12 so konfiguriert sein, um all diese Kommunikationen oder Nachrichten oder wenigstens die einen zu empfangen, die er zur Ausführung der Steuer- oder Regelroutine benötigt. Es kann eine entmutigende Aufgabe auf Seiten des Kontrollers 12 werden, den Empfang und die Spei­ cherung von all den Informationen zu koordinieren, die auf dem Bus 42 fließen, und zwar in einer Weise, die effizient durch den Kontroller 12 verwendet werden kann, um die Steue­ rung des gesamten Prozesses 19 zu bewirken. Um ferner Infor­ mationen zu empfangen, die nicht synchron über den Bus 42 ge­ sendet werden, muß der Kontroller 12 eine Anfrage nach dieser Information aussenden, die, wie oben erläutert wurde, asyn­ chron über den Bus 42 gesendet wird. Da es für den Kontroller 12 keinen Weg gibt, zu bestimmen oder zu bewirken, wann die asynchrone Anfrage an die geeignete Vorrichtung übergeben wird (da die Zeitsteuerung diese Anfrage direkt durch die an­ deren asynchronen Kommunikationen beeinflußt wird, die auf dem Bus 42 stattfinden), kann der Kontroller 12 Informationen empfangen, die nicht mehr aktuell sind, und zwar zu dem Zeit­ punkt, wenn sie den Kontroller 12 erreichen. In ähnlicher Weise hat der Kontroller 12 keine Möglichkeit zu bestimmen, welche Daten es zu einem spezifischen Zeitpunkt sein sollen oder waren, was bei der Steuerung anderer Vorrichtungen in­ nerhalb des Prozesses 19 wichtig sein kann, die nicht an den Bus 42 angeschlossen sind. Darüber hinaus kann es schwierig oder unmöglich für den Kontroller 12 sein, wichtige Informa­ tionen zu empfangen, die den Status einer Vorrichtung oder eines Funktionsblockes betreffen, und zwar innerhalb des Fieldbus-Abschnitts des Prozesses 19, wie beispielsweise Alarme, die durch solche Funktionsblöcke erzeugt werden.

Um diese Probleme zu überwinden, kann der Kontroller 12 so ausgelegt sein, um die Schattenfunktionsblöcke zu verwenden, um die Kommunikation mit den Vorrichtungen und den Funktions­ blöcken innerhalb des Fieldbus-Abschnitts des Prozeßregel­ netzwerks 10 zu implementieren. Spezieller gesagt, kann die Steuerroutine innerhalb des Kontrollers 12 direkt mit einem Schattenfunktionsblock innerhalb des Kontrollers 12 kommuni­ zieren, der dann automatisch mit einem zugeordneten aktuellen externen Funktionsblock innerhalb einer Bereichsvorrichtung kommuniziert, die an den Bus 42 angeschlossen ist. Der Schat­ tenfunktionsblock innerhalb des Kontrollers 12 ist so konfi­ guriert, um den Stand der und die Daten, die dem aktuellen externen Funktionsblock zugeordnet sind, innerhalb einer Vor­ richtung nach unten zu spiegeln, die an den Bus 42 ange­ schlossen ist, so daß es für die Prozeßsteuerroutinen inner­ halb des Kontrollers 12 so scheint, als ob der tatsächliche externe Funktionsblock zugreifbar ist, ohne vermittels des Fieldbus-Protokolls über den Bus 42 kommunizieren zu müssen. Mit anderen Worten erscheint es für die Prozeßsteuerroutine innerhalb des Kontrollers 12 so, als ob der tatsächliche Funktionsblock innerhalb des Prozeßkontrollers 12 gelegen wä­ re, anstatt unten innerhalb einer externen Bereichsvorrich­ tung, die an den Bus angeschlossen ist, und die Prozeßsteuer­ routine verwendet den Schattenfunktionsblock so wie sie ande­ re Funktionsblöcke innerhalb des Kontrollers 12 verwendet.

Fig. 4 veranschaulicht eine graphische Einzelheit einer Pro­ zeßregelschleife oder eines Moduls 100, der der Prozeßsteuer­ routine zugeordnet ist und durch diese implementiert ist, und zwar innerhalb des Prozeßkontrollers 12. Um die Steuerung des gesamten Prozesses 19 zu implementieren, kann die Prozeßsteu­ er- oder -regelroutine innerhalb des Kontrollers 12 viele solcher Schleifen oder Module implementieren, die in irgend­ einer gewünschten Weise miteinander verbunden sein können. Die herausgegriffene Prozeßregelschleife 100 enthält eine Re­ präsentation eines Aspektes (Flusses) des Prozesses 101, der durch eine Anzahl von Kontrollerblöcken oder Einheiten ge­ steuert wird, speziell durch einen PID-Block 102, der an ei­ nen AO-Block 104, einen ersten AI-Block 106 und einen zweiten AI-Block 108 gekoppelt ist. Jeder der Blöcke 102, 104 und 106 ist eine graphische Einzeldarstellung einer Regelsubroutine (oder eines Objektes innerhalb einer objektorientierten Pro­ grammierumgebung), die der Prozeßregelroutine zugeordnet ist, die in dem Kontroller 12 gespeichert ist, konfiguriert gemäß einem Kontrollerprotokoll, welches dem Kontroller 12 zugeord­ net ist und dazu verwendet wird, um einen Abschnitt einer Ge­ samtregelstrategie in bezug auf den Prozeß 101 zu implemen­ tieren. Jeder der Blöcke der Prozeßregelroutine 100 enthält Eingänge und Ausgänge (durch Eingänge auf der linken und rechten Seite der Blöcke jeweils veranschaulicht) und kann einen Steuer- oder Regelalgorithmus enthalten, der eine ge­ wisse Steuer- oder Regelfunktion durchführt. Verbindungen un­ tereinander oder Verbindungen zwischen den Funktionsblöcken sind als Leitungen oder Linien dargestellt, die von einem Ausgang von einem Block zu einem Eingang eines anderen Blocks verlaufen. Diese Verbindungen geben die Art wieder, in wel­ cher die Kommunikation zwischen den einzelnen Blöcken inner­ halb der Steuerroutine oder Modul implementiert wird, um eine Prozeßregelschleife gemäß einem Kontrollerprotokoll auszufüh­ ren. Somit veranschaulicht die Einzelheit von Fig. 4 nicht nur die Elemente der Regelschleife, die ausgeführt werden, sondern auch die Art, in welcher die Prozeßregelroutine in­ nerhalb des Kontrollers 12 ausgelegt ist, um diese Schleife zu implementieren. Die Prozeßregelroutine kann automatisch geändert oder erneut konfiguriert werden, und zwar durch Be­ wegen der Verbindungen zwischen den Blöcken, durch Addieren oder Weglassen von Blöcken davon usw., wie dies durch den Delta V-Prozeßkontroller ausgeführt wird.

Der PID-Funktionsblock 102, der in Fig. 4 veranschaulicht ist, enthält einen Algorithmus (durch den Kontroller 12 im­ plementiert), der beispielsweise eine Proportional/Inte­ gral/Differential-Regelberechnung ausführt, basierend auf den Eingangsgrößen, die er von den AI-Blöcken 106 und 108 und dem AO-Block 104 empfängt, und der ein Ausgangssteuersignal für den AO-Block 104 erzeugt, welcher seinerseits eine Vorrich­ tung (28 beispielsweise ein Ventil) innerhalb des Prozesses 101 veranlaßt, eine Funktion durchzuführen, wie beispielswei­ se bewirken, daß ein Ventil bewegt wird, um die Strömung ei­ nes Mediums zu erhöhen. Der AO-Block 104 kann einem tatsäch­ lichen Ventil zugeordnet sein und dieses steuern, z. B. das Ventil 28 von Fig. 1, und zwar über die IO-Vorrichtung 20 und die 4-20-mA-Kommunikationsleitung 38. Der AO-Block 104 emp­ fängt eine Messung der tatsächlichen Position des Ventils und liefert diese Messung als eine Rückkopplungsgröße zu dem PID-Funktionsblock 102 über die Verbindung 110. Darüber hinaus empfängt der PID-Funktionsblock 102 Eingangsgrößen von dem AI-Block 106, der beispielsweise einem Sensor, wie einem Tem­ peratursensor, zugeordnet ist, der innerhalb des Prozesses 19 gelegen ist. Dieser Sensor kann beispielsweise der Sensor 34 von Fig. 1 sein, in welchem Fall der AI-Block 106 die Sensor­ meßgrößen über die I/O-Vorrichtung 22 empfängt, und zwar un­ ter Verwendung von Standardnachrichtenübertragungen. Solch eine Verbindung ist in Fig. 4 durch die Verbindung zwischen dem Ausgang, der mit "Fluß" in dem Prozeß 101 bezeichnet ist, und dem Eingang des AI-Blocks 106, der mit "simulate_in" be­ zeichnet ist, veranschaulicht. Die Verarbeitung und die Steuerung der Information, die dem PID-Funktionsblock 102, dem AO-Block 104 und dem AI-Block 106 zugeordnet ist, wird innerhalb des Kontrollers 12 durchgeführt.

Allgemein gesagt, ist innerhalb des Delta V-Steuersystems, das heißt Verwendung des Delta V-Kontrollerkonfigurations­ protokolls jeder der Blöcke 102, 104 und 106 spezifisch kon­ figuriert, um all die Informationen und Daten zu unterstüt­ zen, die den ähnlichen Funktionsblöcken in dem Field­ bus-Protokoll zugeordnet sind und somit für alle Absichten und Zwecke, und ist sehr ähnlich einem Funktionsblock innerhalb des Fieldbus-Protokolls mit der Ausnahme, daß die Steuerfunk­ tionen oder Regelfunktionen durch den zentralen Prozessor 12 durchgeführt werden und daß die Informationen von speziellen Bereichsvorrichtungen über Standardkommunikationsleitungen von dem Prozeßkontroller 12 empfangen und übergeben werden. Somit sind die Abschnitte der Steuer- oder Regelroutine, die in Fig. 4 herausgegriffen ist, welche die Blöcke 102, 104 und 106 enthält, momentan in der Delta V-Umgebung vorgesehen und sind bekannt.

Um die Fieldbus-Integration innerhalb des Kontrollers 12 zu unterstützen, kann die folgende Annäherung versucht werden, und zwar unter Verwendung eines Delta V-Steuersystems (oder eines anderen zentralisierten Steuersystems), bei dem der Ba­ sissatz an Funktionsblöcken, die in dem Steuersystem oder Re­ gelsystem verwendet werden, ähnlich denjenigen ist, die durch das Fieldbus-Protokoll definiert sind. Die externen Fieldbus- oder herstellerspezifischen Funktionsblöcke sind individuell zugeordnet, um in Verbindung mit dem Steuer- oder Regelsystem (oder einem Teil des Steuer- oder Regelsystems) ein Programm auszuführen und die Funktionsblöcke der Fieldbus-Vorrich­ tungen sind in dem Steuer- oder Regelsystem als Schattenfunk­ tionsblöcke wiedergegeben oder reflektiert, welche interne und externe Referenzen unterstützen, so als ob die externen Funktionsblöcke in dem Steuer- oder Regelsystem vorhanden wä­ ren. Das Steuer- oder Regelsystem erneuert automatisch die dynamischen und die statischen Parameter des Schattenfunkti­ onsblocks und leitet Änderungsanfragen zu den geeigneten ex­ ternen Funktionsblöcken unter Verwendung der Schattenfunkti­ onsblöcke. Alarmsignale, die in den externen Vorrichtungen (oder Funktionsblöcken) detektiert werden, werden in den Schattenfunktionsblöcken reflektiert und werden in der Alarm­ verarbeitung des Steuer- oder Regelsystems integriert. Natür­ lich kommuniziert der Schattenfunktionsblock mit den externen Funktionsblöcken unter Verwendung des Kontrollerprotokolls, welches den externen Funktionsblöcken zugeordnet ist, welches verschieden von dem Kontrollerkonfigurationsprotokoll sein kann und typischerweise verschieden ist, welches von dem Kon­ troller verwendet wird, um die Kommunikationen zwischen den Funktionsblöcken intern zu dem Kontroller zu implementieren. Auch können Verbindungen zwischen internen und externen Funk­ tionsblöcken durch den Anwender in einer Weise bestimmt wer­ den, die davon abhängt, wo der Funktionsblock vorhanden ist. Als ein Ergebnis erscheinen während der Steuerdefinition und der Online-Diagnose die Funktionsblöcke als die gleichen, ob sie nun interne (in dem Steuer- oder Regelsystem vorhanden) oder externe (in einer Fieldbus-Vorrichtung vorhanden) sind oder nicht.

Somit ist gemäß der vorliegenden Erfindung der AI-Block 108, der in Fig. 4 so dargestellt ist, daß er ähnlich dem AI-Block 106 ist, tatsächlich ein Schattenfunktionsblock, der so kon­ figuriert ist, daß er mit einem externen Funktionsblock 112 kommuniziert, der beispielsweise innerhalb des Sensors 48 ge­ legen ist, der an den Fieldbus 42 von Fig. 1 angeschlossen ist. Der Schattenfunktionsblock 108 liefert gemessene oder andere Signale, die dem externen Funktionsblock 112 zugeord­ net sind, an den PID-Block 102 über die Verbindungen, die da­ zwischen erstellt wurden. Um anzuzeigen, daß der Block 108 ein Schattenfunktionsblock ist, der einem externen Funktions­ block 112 zugeordnet ist und mit diesem kommuniziert, unter Verwendung des Kommunikationsprotokolls des externen Funkti­ onsblockes 112, ist der Block 108 so dargestellt, daß er eine strichlierte Linie besitzt, die an den AI-Funktionsblock 112 innerhalb der Fieldbus-Vorrichtung 48 angehängt ist. Jedoch kann der Schattenfunktionsblock 108 so dargestellt sein, daß er eine Vorrichtungsetikette (device tag) und/oder einen Blocknamen am Boden desselben besitzt, oder kann in irgendei­ ner anderen gewünschten Weise dargestellt sein, wobei darauf hingewiesen sei, daß die Art, in welcher der Schattenfunkti­ onsblock für einen Anwender als Einzelheit dargestellt ist, nicht kritisch ist, und zwar in Verbindung mit dem Betrieb des Schattenfunktionsblocks. Ferner werden die Eingangsgrößen und Ausgangsgrößen, die dem AI-Funktionsblock 112 zugeordnet sind, innerhalb des Fieldbus-Netzwerks gemäß dem Weg überge­ ben, in welchem das Netzwerk konfiguriert worden ist.

Während der Schattenfunktionsblock 108 auf alle oder die mei­ sten der Informationen zugreift oder spiegelt, die dem tat­ sächlichen Funktions 58041 00070 552 001000280000000200012000285915793000040 0002019940230 00004 57922block 112 zugeordnet sind und/oder durch diesen erzeugt werden, erfolgt irgendeine Verarbeitung, die in bezug auf die AI-Funktionsblock 112 stattfindet (oder in bezug auf irgendeinen anderen Funktionsblock, für den ein Schattenfunktionsblock existiert) in dieser Weise unten in der externen Vorrichtung, nicht in dem Schattenfunktionsblock 108 oder selbst in dem Kontroller 12. Als ein Ergebnis kann der Schattenfunktionsblock 108 so betrachtet werden, als ob er eine Röhre von Informationen zwischen dem PID-Block 102 (oder irgendeinem anderen Block innerhalb des zentralisierten Kontrollers 12) und dem tatsächlichen Funktionsblock 112 bil­ den würde. Der Schattenfunktionsblock 108 ist nicht ein Funk­ tionsblock, der vollständig durch den Kontroller 12 betreib­ bar ist, in dem Sinn, daß der AI-Block 106 und der PID-Block 102 durch den Kontroller 12 betreibbar sind, da der Schatten­ funktionsblock 108 lediglich die Informationen innerhalb des tatsächlichen externen Funktionsblocks 112 spiegelt oder an­ sonsten eine Nachrichtenübertragung zwischen dem Kontroller 12 und dem tatsächlichen externen Funktionsblock 112 vor­ sieht. Nichtsdestoweniger kann durch eine geeignete Operation des Schattenfunktionsblockes der Kontroller 12 den tatsächli­ chen Funktionsblock 112 steuern und mit diesem kommunizieren, so als ob dieser vollständig in dem Kontroller 12 implemen­ tiert wäre. Indem beispielsweise eine Kommunikation mit dem Schattenfunktionsblock 108 durchgeführt wird, unter Verwen­ dung des Kontrollerkonfigurationsprotokolls, kann die Prozeß­ steuer- oder -regelroutine innerhalb des Kontrollers 12 auf den neuesten Stand gebrachte Informationen von dem Funktions­ block 112 empfangen und kann Befehle zu dem Funktionsblock 112 so schnell wie möglich senden, ohne sich darum kümmern zu müssen, wo der tatsächliche Funktionsblock 112 gelegen ist oder auf welche Weise Kommunikationen mit dem tatsächlichen Funktionsblock 112 bewirkt werden. Statt dessen erfolgen die Kommunikationen zwischen dem tatsächlichen Funktionsblock 112 und dem Schattenfunktionsblock 108 automatisch ohne Eingrei­ fen durch die Prozeßsteuerroutine, die lediglich die Schritte ausführen muß, die sie in typischer Weise ausführt, um die Kommunikationen zwischen den Steuer- oder Funktionsblöcken zu implementieren, die innerhalb des Kontrollers 12 gelegen sind. In dieser Weise ermöglicht es der Schattenfunktions­ block einem Kontroller, der Funktionsblöcke innerhalb des Kontrollers implementiert, Funktionsblöcke zu verwenden und mit zu integrieren, die unterschiedliche Kommunikations- oder Konfigurationsprotokolle verwenden und die nicht innerhalb des Kontrollers gelegen sind, sondern die statt dessen in ei­ ner externen Vorrichtung gelegen und in diese implementiert sind, wie beispielsweise einer mikroprozessor-unterstützten Bereichsvorrichtung, die in einer Prozeßumgebung angeordnet ist. Diese hinzugefügte Fähigkeit wird von dem Kontroller 12 in transparenter Weise erreicht, so daß dann, sobald der Schattenfunktionsblock in dem Kontroller 12 aufgebaut ist, die Steuer- oder Regelroutine nicht nachzusuchen braucht, wo der tatsächliche Funktionsblock gelegen ist, um komplexe Kom­ munikationen oder Datenbasismanipulationen durchzuführen, um den externen Funktionsblock 112 zu verwenden.

Wie hervorgeht, speichert der Schattenfunktionsblock 108 die Eingangsgrößen und Ausgangsgrößen der parametrischen Updates, die dem AI-Funktionsblock 112 in einer Datenbasis in dem Kon­ troller 12 zugeordnet sind, und zwar in irgendeinem gewünsch­ ten Format, speichert jedoch in bevorzugter Weise diese in dem gleichen oder einem ähnlichen Format wie die Informatio­ nen, die den Steuerblöcken zugeordnet sind, die durch den Kontroller implementiert sind, das heißt unter Verwendung des Kontrollerkonfigurationsprotokolls. Dies macht die Kommunika­ tion mit dem Schattenfunktionsblock 108 für den Kontroller 12 transparent, das heißt die Prozeßsteuer- oder -regelroutine 100 schafft eine Kommunikation in bezug auf den Schattenfunk­ tionsblock 108 (und somit mit dem tatsächlichen Funktions­ block 112) über die Verbindung in der gleichen Weise wie sie eine Kommunikation in bezug auf die anderen Funktionsblöcke 104 und 106 erzeugt. Während es wünschenswert ist, daß die Funktionsblöcke innerhalb des Kontrollers 12 logisch konfigu­ riert sind, um all die Informationen (oder die meisten) zu unterstützen, die durch das dezentralisierte oder externe Prozeßregelnetzwerk unterstützt werden (wie dies bei dem Del­ ta V-Kontroller und dem Fieldbus-Kommunikationsprotokoll der Fall ist), so ist diese Konfiguration nicht erforderlich. Tatsächlich kann irgendein Kontrolleraufbau unter Verwendung des Schattenfunktionsblockes unterstützt werden, der hier of­ fenbart ist, indem die Daten, die in dem externen Funktions­ block unterstützt werden und in diesem verfügbar sind, in den Daten abgebildet werden, die in der Kontrollerroutine verwen­ det und verfügbar sind.

Allgemein gesagt, um den Betrieb des Schattenfunktionsblockes 108 in dem Fieldbus-Netzwerk zu bewirken, wird der tatsächli­ che Funktionsblock 112 so konfiguriert, um die verketteten Daten zu veröffentlichen und an den Prozeßkontroller 12 (das heißt die Daten, die mit einem anderen Block innerhalb des Kontrollers 12 über eines der Verbindungsglieder, die in Fig. 4 veranschaulicht sind, verbunden sind) oder zu veröffentli­ chen, und zwar über die Schnittstellenkarte 40, unter Verwen­ dung des Veröffentlicher/Teilnehmer-VCR's (das heißt synchro­ nen Kommunikationen) in dem Fieldbus-Kommunikationsprotokoll. Andere nicht verkettete Daten, die dem tatsächlichen Funkti­ onsblock 112 zugeordnet sind, werden an die Schnittstellen­ karte 40 unter Verwendung von asynchronen Kommunikationen bzw. Nachrichtenübertragungen übergeben, unter Verwendung von beispielsweise den Betrachtungsobjekt- oder Warnobjektfunk­ tionen innerhalb des Fieldbus-Protokolls, was in der Modulab­ tastrate des Steuermoduls innerhalb des Kontrollers 12 statt­ findet. Es werden daher in typischer Weise verkettete Daten zu dem Kontroller 12 von dem Funktionsblock 112 in einer sehr viel schnelleren Rate gesendet als andere Daten (weniger zeitsensitive Daten). Umgekehrt werden verkettete Daten, die durch einen Block innerhalb des Kontrollers 12 zu dem Schat­ tenfunktionsblock 108 gesendet werden, unmittelbar an die Schnittstellenvorrichtung 40 weitergeleitet, wo sie auf dem Fieldbus-Bus 42 unter Verwendung von synchronen Standardnach­ richtenübertragungen veröffentlicht werden.

Die Informationen, die von dem tatsächlichen Funktionsblock 112 gesendet werden, werden automatisch in den Schattenfunk­ tionsblock 108 gesetzt und stehen somit für die Steuer- oder Regelroutine in dem Kontroller 12 zu jeder Zeit zur Verfü­ gung. Um diese Operation zu bewirken, nimmt die Schnittstel­ lenkarte 40 (die Teil eines Kommunikationsports des Schatten­ funktionsblockes sein kann) teil an den veröffentlichten Ver­ bindungsparameterdaten, die durch den Funktionsblock 112 er­ zeugt wurden, und liefert diese Informationen zu dem Prozeß­ kontroller 12 in der Rate, die durch die Ausführungsrate des Funktionsblockes innerhalb des Makrozyklusses des Field­ bus-Segments festgelegt ist, an welches der externe Funktions­ block 112 angeschlossen ist. In ähnlicher Weise erhält die Schnittstellenkarte 40 (die typischerweise das LAS des Field­ bus-Segments ist) die Betrachtungsobjekte und/oder Warnobjek­ te des tatsächlichen Funktionsblocks in einer Rate, die durch die Abtastrate des Kontrollermoduls festgelegt ist, in wel­ chem der Schattenfunktionsblock 108 vorhanden ist, das heißt in der Rate, in welcher die Steuer- oder Regelroutine 100 in dem Kontroller 12 die Blöcke implementiert, die dieser zuge­ ordnet sind. Wie dies bekannt ist, enthält das Field­ bus-Protokoll vier Typen von Betrachtungsobjekten, die die norma­ lerweise dynamischen (Betrachtungsobjekt 1), normalerweise statischen (Betrachtungsobjekt 2), alle dynamischen (Betrach­ tungsobjekt 3) und alle statischen (Betrachtungsobjekt 4) Va­ riablen speichern. Die Schnittstellenkarte 40 ist so konfigu­ riert, um automatisch auf einer periodischen Grundlage oder durch Aussenden einer Anfrage nach solchen Informationen das dynamische Betrachtungsobjekt 3 zu empfangen, welches die Werte für alle die dynamischen Variablen enthält, die dem tatsächlichen Funktionsblock 112 zugeordnet sind. Nach Emp­ fangen dieser Betrachtungsobjektinformationen speichert die Schnittstellenkarte 40 die Informationen in einer Datenbasis oder Datenbank, die durch den Schattenfunktionsblock zugreif­ bar ist, und der Schattenfunktionsblock 108 erneuert die Va­ riablen, die sich dadurch geändert haben, wodurch diese va­ riablen Werte für die Prozeßsteuer- oder -regelroutine inner­ halb des Kontrollers 12 verfügbar werden. Wenn eine der dyna­ mischen Variablen (die statische Revisionsvariable) eine Än­ derung an einer statischen Variablen anzeigt, kann der Schat­ tenfunktionsblock oder die Software innerhalb der Schnitt­ stellenkarte 40 anfragen, daß das Betrachtungsobjekt 4 (alle statischen Variablen) zu dem Schattenfunktionsblock 108 ge­ sendet werden, um die statischen Variablen auf den neuesten Stand zu bringen. Bei der bevorzugten Ausführungsform emp­ fängt die H1-Schnittstellenkarte 40 fortlaufend das Betrach­ tungsobjekt 3 in der Modulabtastrate des Steuermoduls 100 in­ nerhalb des Kontrollers 12.

Wie oben dargelegt ist, kann der Kontroller 12 (oder irgend­ ein Funktionsblock desselben) Befehle zu dem aktuellen Funk­ tionsblock 112 innerhalb des Fieldbus-Netzwerks über den Schattenfunktionsblock 108 einfach dadurch senden, indem ein Parameter innerhalb des Schattenfunktionsblockes 108 geändert wird. Diese Parameteränderung wird automatisch nach unten zu dem AI-Funktionsblock 112 über einen Ausgang des Schatten­ funktionsblockes 108 gesendet, wo er dazu verwendet wird, um die Konfiguration des AI-Funktionsblockes 112 zu ändern. Wäh­ rend die Datenänderung oder der Einschreibbefehl in dem tat­ sächlichen Funktionsblock 112 nicht zu exakt der gleichen Zeit durchgeführt wird, zu der dieser durch den Schattenfunk­ tionsblock 108 empfangen wird, und zwar vom Standpunkt des Kontrollers 12 aus, erfolgt diese Änderung sehr schnell und wird in den Schattenfunktionsblock 108 zurück reflektiert, wenn die Änderung tatsächlich vorgenommen wurde. Diese Be­ triebsweise ermöglicht es dem Kontroller 12 und speziell dem PID-Funktionsblock 102, innerhalb des Kontrollers 12 eine Än­ derung zu bewirken, indem lediglich diese Änderung in eine Speicherstelle eingeschrieben wird, die dem Schattenfunkti­ onsblock 108 zugeordnet ist und indem danach die Kommunikati­ on automatisch vorgenommen wird, ohne daß dabei irgendwelche speziellen Kommunikationsaktivitäten ausgeführt werden müs­ sen, die erforderlich sind, um Daten in das Fieldbus-Netzwerk hinein zu bekommen und heraus zu bekommen.

Neben den Eingangs- und Ausgangsparameterdaten können andere Typen von Daten, wie beispielsweise Modus- und Statusdaten, zwischen einem Kontrollerfunktionsblock (das heißt einem in­ ternen Funktionsblock) und dem Schattenfunktionsblock 108 übertragen werden als auch zwischen dem Schattenfunktions­ block 108 und dem tatsächlichen externen Funktionsblock 112. Natürlich wird diese Information mit den Betrachtungsobjekt- oder Warnobjektinformationen von dem externen Funktionsblock 112 zu dem Schattenfunktionsblock 108 gesendet. In ähnlicher Weise können solche Modus- und Statusdaten an den Schatten­ funktionsblock 108 von einem internen Funktionsblock inner­ halb des Kontrollers 12 übermittelt werden und es können die­ se Daten dann an den externen Funktionsblock 112 für die Ver­ wendung geliefert werden. Der Statusparameter eines Funkti­ onsblockes zeigt in typischer Weise die Qualität der Messung oder der Daten an, die durch den Funktionsblock geliefert werden, und kann Gründe liefern, warum eine schlechte Quali­ tät existiert. Er kann auch eine Grenze anzeigen, wie bei­ spielsweise eine hohe oder niedrige Grenze, welche die Daten erreichen können. Der Modusparameter zeigt in typischer Weise an, welcher Modus des Funktionsblocks eingeschaltet ist, wel­ cher beispielsweise ein Handmodus, ein Automatikmodus oder ein Kaskadenmodus sein kann, wie dies durch das Field­ bus-Protokoll festgelegt ist.

Darüber hinaus wird eine Alarmdetektion basierend auf Alarm­ signalen, die in dem tatsächlichen externen Funktionsblock erzeugt werden, vorgesehen, da Ereignisse und Berichte durch den externen Funktionsblock automatisch als dynamische Para­ meter erzeugt werden, die dann durch die Betrachtungs- oder Warnobjekte dem Schattenfunktionsblock 108 angeboten werden. Als ein Ergebnis kann eine Alarminformation, die den externen Funktionsblock betrifft, von dem Kontroller 12 betrachtet und verwendet werden.

Obwohl natürlich der Block 108 hier als Schattenfunktions­ block beschrieben wurde, können irgendwelche Blöcke innerhalb der Fig. 4 ebenfalls oder alternativ Schattenfunktionsblöcke sein.

Die Vorteile, die mit der Verwendung eines Schattenfunktions­ blockes verbunden sind, wie beispielsweise dem Schattenfunk­ tionsblock 108, der in Fig. 4 veranschaulicht ist, bestehen darin, daß dieser es dem Prozeßregeldesigner ermöglicht, die Steuerung oder Regelung innerhalb eines zentralisierten Pro­ zeßkontrollers 12 zu implementieren unter Verwendung von ex­ ternen Funktionsblöcken, das heißt Funktionsblöcken, die tat­ sächlich innerhalb einer verschiedenen Vorrichtung implemen­ tiert sind und die unterschiedlichen Kommunikationsprotokol­ len unterworfen sind. In Verbindung mit dem Schattenfunkti­ onsblock braucht ein Designer oder Konstrukteur sich nicht darum zu kümmern, daß der externe Funktionsblock einem unter­ schiedlichen Kommunikations- oder Steuer- oder Regelprotokoll zugeordnet ist oder in einer unterschiedlichen Vorrichtung gelegen ist, da die Nachrichtenübermittlung zwischen dem Schattenfunktionsblock und dem externen Funktionsblock auto­ matisch erfolgt und auch transparent für die Steuer- oder Re­ gelroutine. Wenn ferner einmal ein Schattenfunktionsblock im­ plementiert ist und läuft, ist es einfach ein Modell darüber zu erstellen, was sich innerhalb des gesamten Prozeßregelsy­ stems ereignet, und zwar ohne sich darum zu kümmern, ob Ak­ tionen innerhalb einer Fieldbus- oder anderen externen Vor­ richtung auftreten oder innerhalb des Kontrollers auftreten, da der Schattenfunktionsblock für den Kontroller und den An­ wender bewirkt, daß es so scheint, daß der tatsächliche Funk­ tionsblock in dem Kontroller implementiert ist, obwohl dies real nicht der Fall ist.

Wenn ein gemeinsamer Funktionsblocksatz und Schattenfunkti­ onsblöcke in dem Steuer- oder Regelsystem verwendet werden, um Funktionsblöcke wiederzugeben, die externen Vorrichtungen zugeordnet sind, kann die Steuer- oder Regelstrategie zu Be­ ginn ohne das Wissen ausgelegt werden, ob ein bestimmter Funktionsblock dieser Strategie in dem Steuer- oder Regelsy­ stem vorhanden sein wird oder in einer externen Vorrichtung vorhanden sein wird, und es können Anwenderanwendungen auf die Schattenfunktionsblöcke zugreifen (welche die externen Funktionsblöcke wiedergeben oder als Modell darstellen), und zwar in exakt der gleichen Weise wie sie auf die Steuer- oder Regelsystemfunktionsblöcke zugreifen. Auch werden Alarme, die durch die externe Vorrichtung detektiert werden, voll in die Steuersystemalarmverarbeitung durch den Schattenblock inte­ griert, mit der Möglichkeit, daß diese Alarme in exakt der gleichen Weise für die externen Funktionsblöcke erscheinen wie für Funktionsblöcke, die innerhalb des Steuer- oder Re­ gelsystems vorhanden sind.

Die Konfiguration, Implementierung und Verwendung eines Schattenfunktionsblockes wird nunmehr in Einzelheiten unter Hinweis auf die Fig. 5-13 beschrieben. Fig. 5 veranschaulicht den physikalischen Aufbau eines Abschnitts des Prozeßregel­ netzwerks von Fig. 1 mehr in Einzelheiten. Die Anwenderwork­ station 150, die aus irgendeinem der PCs 14 von Fig. 1 beste­ hen kann, ist kommunikativ mit dem Kontroller 12 verbunden, der seinerseits über die Schnittstellenkarte 40 mit der Be­ reichsvorrichtung 48 verbunden ist, welche den Funktionsblock 112 darin enthält. Wie in Fig. 5 veranschaulicht ist, besitzt der Kontroller 12 einen oberen Abschnitt 152, in welchem die Steuerroutine 100 (enthaltend den Schattenfunktionsblock 108) implementiert ist, und einen unteren Abschnitt, der eine Da­ tenbasis oder Datenbank 156 enthält, um Eingangs- und Aus­ gangsinformationen zu speichern, die von der Schnittstellen­ karte 40 als auch von anderen I/O-Karten empfangen werden. Allgemein gesagt, ist die Schnittstellenkarte 40 so konfigu­ riert, um automatisch verkettete Daten zu empfangen, die durch den Funktionsblock 112 veröffentlicht werden, und zwar über den Veröffentlicher/Teilnehmer-VCR (in der Veröffentli­ chungsrate, die durch den Makrozyklus des Fieldbus-Busses 42 festgelegt ist), und um diese Daten in der unteren Datenbank 156 zu speichern, wo sie dem Schattenfunktionsblock 108 in der Abtastrate des Steuermodus 100 innerhalb des Kontrollers 12 angeboten werden. In ähnlicher Weise ist die Schnittstel­ lenkarte 40 so konfiguriert, um die verketteten Daten, die durch einen Funktionsblock innerhalb des Kontrollers 12 er­ zeugt werden, auf dem Fieldbus-Bus 40 zu veröffentlichen, un­ ter Verwendung synchroner Nachrichtenübermittlungen innerhalb des Fieldbus-Netzwerks. Auch ist die Schnittstellenkarte 40 so konfiguriert, um periodisch anzufragen nach (unter Verwen­ dung asynchroner Nachrichtenübertragungen) Betrachtungs- und/­ oder Alarmdaten von dem Funktionsblock 112 und um diese Informationen in der unteren Datenbank 156 zu speichern, um sie an den Schattenfunktionsblock 108 in der Abtastrate des Kontrollermoduls 100 zu liefern.

Die Schnittstellenkarte 40 und/oder die Datenbasis 156 kann einen Kommunikationsport des Schattenfunktionsblockes 108 um­ fassen, kann Teil von diesem sein oder kann durch diesen ge­ steuert sein, der Kommunikationen zwischen dem Schattenfunk­ tionsblock 108 und dem externen Funktionsblock 112 implemen­ tiert. Der Kommunikationsport enthält einen Eingang, der von dem externen Funktionsblock 112 Daten empfängt, und zwar un­ ter Verwendung des Kommunikationsprotokolls des externen Funktionsblocks 112, und enthält einen Ausgang, der mit dem externen Funktionsblock 112 in Verbindung steht, um Daten (inklusive Schreibbefehlen) an den externen Funktionsblock 112 unter Verwendung des Kommunikationsprotokolls des exter­ nen Funktionsblocks 112 zu senden. Natürlich kann der Kommu­ nikationsport des Schattenfunktionsblocks 108 in der Software und/oder einer anderen Hardware in dem Kontroller zusätzlich oder in Verbindung mit der Schnittstellenkarte 40 und der Da­ tenbank 156 implementiert sein.

Um eine Steuer- oder Regelroutine unter Verwendung eines Schattenfunktionsblocks zu konfigurieren, kann ein Anwender bei der Workstation 150 irgendwelche Standardwerkzeuge ver­ wenden, wie beispielsweise solche, die durch das Delta V-Steuer- oder -Regelsystem geschaffen werden, um zu Beginn das Prozeßregelsystem zu konfigurieren. Im allgemeinen ermögli­ chen es die DeltaV-Konfigurationswerkzeuge einem Anwender, Blöcke darzustellen, zu konfigurieren und miteinander zu ver­ binden, wie beispielsweise diejenigen, die in Fig. 4 veran­ schaulicht sind, um eine oder mehrere Regelschleifen zu im­ plementieren oder zu konstruieren oder Module, die der Steu­ er- oder Regelroutine zugeordnet sind. Zum Zwecke der Erläu­ terung kann die Steuerroutine zum Steuern eines Prozesses ir­ gendeine Anzahl von Modulen enthalten, von denen jeder ir­ gendeine Anzahl von gewünschten Blöcken enthalten kann, die eine Anzahl von Regelschleifen implementieren. Während der Konfiguration oder der Konstruktion eines Prozeßregelmoduls kann ein Anwender die Verwendung eines Funktionsblocks aus­ wählen, der innerhalb einer Vorrichtung extern zum Kontroller 12 gelegen ist (wie beispielsweise einen Funktionsblock in­ nerhalb einer der Fieldbus-Vorrichtungen des Prozeßregelsy­ stems). In diesem Fall kann das Konfigurationswerkzeug, wel­ ches dem Kontroller 12 zugeordnet ist, so konstruiert sein, um den Anwender zu fragen, die physikalischen der Verbindun­ gen der Vorrichtung zu dem Kontroller 12 zu spezifizieren und andere Vorrichtungs- und Funktionsblockkonfigurationsinforma­ tionen zu spezifizieren, die für die anfängliche Konfigurati­ on der Vorrichtung und/oder des Funktionsblockes innerhalb der Vorrichtung gemäß dem Kommunikationsprotokoll dieser Vor­ richtung erforderlich sind (z. B. das Fieldbus-Kommunikations­ protokoll). Der Anwender kann dann aufgefordert werden, diese Informationen in irgendeiner gewünschten Weise zu liefern, wie beispielsweise über die Verwendung von Dialogkästchen. Natürlich hängt die exakte Information, die benötigt wird, von dem Typ der Vorrichtung und des Funktionsblockes ab, der spezifiziert wird, wie dies von einem Fachmann in Verbindung mit dem Vorrichtungsprotokoll, welches verwendet wird, wie beispielsweise dem Fieldbus-Protokoll, zu erkennen ist.

Ein Weg, um zu spezifizieren, daß ein Funktionsblock durch eine bestimmte externe Vorrichtung (wie beispielsweise eine Fieldbus-Vorrichtung) zu implementieren ist, besteht darin, den Anwender dazu zu bringen, den Funktionsblock, der inner­ halb einer externen Vorrichtung gelegen ist, zu spezifizie­ ren, unter Verwendung eines Browsers (oder einer anderen Software) oder einer Liste oder durch Herausgreifen der ex­ ternen Vorrichtungen, die an den Kontroller angeschlossen sind, und dann Auswählen von einer der aufgelisteten externen Vorrichtungen als die Vorrichtung, in welcher der Funktions­ block zu implementieren ist. Ein anderer Weg besteht darin, den Funktionsblock auf dem Bildschirm auszuwählen und dann diesen Funktionsblock auf eine Einzelheit eines Blocks in ei­ ner externen Vorrichtung durch Drag and Drop zu bewegen. Ir­ gendeine dieser oder irgendeine andere gewünschte Aktion kann dem Konfigurationswerkzeug mitteilen, daß der Funktionsblock, der implementiert werden soll, innerhalb der externen Vor­ richtung liegt, und kann das Konfigurationswerkzeug veranlas­ sen, den Anwender nach der spezifischen Vorrichtung und den Funktionsblockkonfigurationsinformationen zu fragen, die er­ forderlich sind, um den speziellen externen Funktionsblock zu konfigurieren und auf diesen zuzugreifen. Beide diese Verfah­ ren ermöglichen es einem Anwender, einen Funktionsblock in einer externen Vorrichtung aus einer Liste von externen Vor­ richtungen für die Ausführung eines Programms auszuwählen.

Wenn der Anwender spezifiziert, daß ein externer Funktions­ block zu verwenden ist (das heißt extern vom Kontroller 12), so erstellt die Konfigurationsroutine dann einen Schatten­ funktionsblock in dem Kontroller und unternimmt Schritte, um die Fieldbus-Vorrichtung und den Funktionsblock innerhalb der Vorrichtung zu konfigurieren, wie dies im folgenden beschrie­ ben wird. Natürlich erlaubt es das Konfigurationswerkzeug in bevorzugter Weise dem Anwender, alle die Blöcke, die zu ver­ wenden sind, zu spezifizieren, ebenso die Örtlichkeiten oder Lagen solcher Blöcke (das heißt, ob irgendein Block in exter­ nen Vorrichtungen gelegen ist) und auch die Verbindungen zwi­ schen den Blöcken, bevor die Schattenblöcke implementiert werden und die externen (z. B. Fieldbus-)Vorrichtungen initia­ lisiert werden. Dies ermöglicht es, die Konfiguration des ex­ ternen Netzwerks einmal auszuführen, nach dem die Örtlichkeit oder Lage von allen den Blöcken und auch die Natur von allen Verbindungen zwischen den Funktionsblöcken spezifiziert wor­ den ist.

In Verbindung mit der Befähigung des Kontrollers, die Parame­ terdaten für die Funktionsblöcke innerhalb der externen Vor­ richtungen einzusehen oder Zugriff auf diese zu haben (über den Schattenfunktionsblock), kann die Schnittstellenkarte 40 auch Vorrichtungs- und Segmentstatusinformationen an den Kon­ troller für Diagnosezwecke liefern. Die Schnittstellenkarte 40 kann beispielsweise eine Liste empfangen, die eine Identi­ fikation der Vorrichtungen enthält, die angenommenermaßen an einem bestimmten Abschnitt oder Segment des Fieldbus-Netz­ werks angehängt oder angeschlossen sind, und sachdienliche Informationen über jede der identifizierten Vorrichtungen enthalten. Die Schnittstellenkarte 40 kann dann periodisch Informationen (über synchrone oder asynchrone Nachrichtenver­ bindungen) erhalten, welche die Vorrichtungen betreffen, die tatsächlich an das Fieldbus-Segment angeschlossen sind oder die das Segment selbst betreffen, und kann diese Informatio­ nen mit den Informationen innerhalb der empfangenen Liste vergleichen. Auf diese Weise kann die Schnittstellenkarte 40 bestimmen, ob die Bereichsvorrichtungen fehlen oder nicht an das Fieldbus-Netzwerk angeschlossen sind, ob falsche Be­ reichsvorrichtungen an das Fieldbus-Netzwerk angeschlossen sind, ob eine Bereichsvorrichtung sich dem Service entzieht, usw. In ähnlicher Weise kann die Schnittstellenkarte 40 be­ stimmen, ob Segmentwertprobleme auftreten, so als ob keine Nachrichtenverbindung über den Fieldbus-Bus existiert. Wenn es gewünscht wird, kann die Schnittstellenkarte 40 diese Vor­ richtungs- und Segmentstatusdaten an den Kontroller (oder an­ dere Vorrichtung) für Diagnosezwecke senden.

Ferner kann die Schnittstellenkarte 40 die Kommunikation und den Zeitsteuerstatus eines Fieldbus-Segments für Diagnose­ zwecke überwachen. Insbesondere kann die Schnittstellenkarte 40 automatisch an den Daten teilhaben, die durch die Be­ reichsvorrichtungen auf dem Fieldbus-Bus veröffentlicht wer­ den, und kann die empfangenen Daten analysieren, um bei­ spielsweise Zeitsteuerprobleme oder andere Probleme auf dem Fieldbus-Bus zu ermitteln. Wenn es gewünscht wird, kann die Schnittstellenkarte 40 die ankommenden Daten zeitlich prägen und speichern und dann Statistiken aufbewahren, die jeden Funktionsblock oder Vorrichtung betreffen, der oder die an den Bus angeschlossen ist und/oder Statistiken aufbewahren, die das Segment des Busses betreffen. Beispielsweise kann die Schnittstellenkarte 40 die minimalen und maximalen Zeiten zwischen Datenerneuerungen bestimmen, und zwar für bestimmte publizierte Daten, und kann bestimmen, ob diese Zeiten inner­ halb eines zulässigen Bereiches liegen, um festzustellen, ob Kommunikationsprobleme existieren. In ähnlicher Weise kann die Schnittstellenkarte 40 die Zeiten, zu welchen bestimmte Daten angenommenermaßen auf dem Bus zu veröffentlichen sind, mit der tatsächlichen Zeit vergleichen, zu welcher diese Da­ ten auf dem Bus veröffentlicht werden, kann verbrauchte Da­ tenzählwerte für die Funktionsblöcke oder Vorrichtungen über­ wachen und kann irgendwelche anderen gewünschten Statistiken aufbewahren, um Zeitsteuerungs- oder andere Kommunikations­ fehler auf dem Bus zu detektieren. Natürlich können irgend­ welche anderen publizierten Daten überwacht werden, um die Kommunikations- oder Zeitsteuerprobleme auf dem Bus zu be­ stimmen. Wie oben dargelegt wurde, können die statistischen Informationen, die durch die Schnittstellenkarte 40 erzeugt oder gespeichert werden, für irgendeinen Funktionsblock, Vor­ richtung oder Segment des Busses aufbewahrt werden und können zu dem Kontroller (oder irgendeiner anderen Vorrichtung) für Diagnosezwecke gesendet oder von dem Kontroller gelesen wer­ den.

Fig. 6 veranschaulicht ein Flußdiagramm 200, welches den Weg anzeigt, in welchem ein Schattenfunktionsblock innerhalb des Kontrollers 12 erstellt werden kann. Während die Flußdiagram­ me der Fig. 6-12 eine Anzahl von Blöcken veranschaulichen, sei darauf hingewiesen, daß diese Blöcke lediglich eine Se­ quenz von Schritten angeben, die auszuführen sind, und daß die Schritte in der Software oder in irgendeiner anderen ge­ wünschten Weise ausgeführt werden können. Die Flußdiagramm­ blöcke der Fig. 6-12 stellen jedoch nicht notwendigerweise Funktionsblöcke oder Kontrollerblöcke dar, ähnliche den Funk­ tionsblöcken, die in Fig. 4 veranschaulicht sind.

Bei einem Block 201 empfängt der Kontroller 12 ein Modul-Installationsskript von der Anwenderworkstation, die auf ei­ nem der PCs 14 von Fig. 1 bestehen kann. Das Modul-Instal­ lationsskript wird durch das Konfigurationswerkzeug erzeugt, welches durch die Anwenderworkstation abläuft oder auf dieser Anwenderworkstation läuft, und enthält alle Informationen, die erforderlich sind, um die Objekte (in einer objektorien­ tierten Programmiersprache) zu erstellen, die den Funktions­ blöcken eines Steuermoduls in dem Kontroller 12 zugeordnet sind. Das heißt, das Installationsskript konfiguriert die Blöcke (wie beispielsweise die Funktionsblöcke, die dem Steu­ ermodul 100 von Fig. 4 zugeordnet sind) und die Verbindungen zwischen solchen Blöcken, die durch die Verbindungen (Links) definiert sind. Natürlich werden all diese Informationen durch den Anwender geliefert, während dieser das Konfigurati­ onswerkzeug verwendet. Wenn ein Funktionsblock durch einen externen Funktionsblock zu implementieren ist, wie beispiels­ weise einen in einer Bereichsvorrichtung, erzeugt ein Block 202 einen Schattenfunktionsblock innerhalb des Kontroller 12, und zwar durch Erzeugen eines Objektes (innerhalb einer ob­ jektorientierten Programmiersprache), welches ähnlich ist den Funktionsblöcken für andere Vorrichtungen, die innerhalb des Kontrollers gelegen sind, ausgenommenen dieses führt keiner­ lei Steuerfunktionen durch. Während die Schattenfunktions­ blöcke in bevorzugter Weise als ein Objekt in einer objekt­ orientierten Programmierumgebung erzeugt werden, können sie unter Verwendung irgendeiner anderen Programmierumgebung er­ zeugt werden, die dem Kontroller 12 zugeordnet ist oder von diesem verwendet wird.

Wenn ein Schattenfunktionsblock aufgebaut wird, veranlaßt der Block 202 die Schnittstellenkarte 40, den tatsächlichen Funk­ tionsblock innerhalb der Fieldbus-Vorrichtung abzutasten und Informationen von dem tatsächlichen Funktionsblock zu erhal­ ten, die erforderlich sind, um zu Beginn den Schattenfunkti­ onsblock zu konfigurieren. Ferner erstellt der Block 202 die Datenbankstellen innerhalb der unteren Datenbank 156 des Kon­ trollers 12, an die die Schnittstellenkarte 12 Betrachtungs­ objekt- und Warnobjektdaten als auch verkettete Parameterda­ ten eingeben sollte, die von dem tatsächlichen Funktionsblock erhalten werden. Der Block 202 informiert auch die Schnitt­ stelle 40 darüber, wie oft Betrachtungsobjekt- und Warnobjek­ tinformationen basierend auf der Abtastrate des Moduls 100 angefragt werden sollen.

Nachdem der Block 202 einen Schattenfunktionsblock in dem Kontroller erzeugt hat und die geeigneten Verbindungen zwi­ schen der Datenbank 156, dem Schattenfunktionsblock 108 und der Schnittstellenkarte 40 identifiziert hat, konfiguriert ein Block 203 die untere Datenbasis 156, um die gespeicherten verketteten Parameterdaten (das heißt diejenigen, die durch die Schnittstellenkarte 40 unter Verwendung des synchronen Veröffentlicher/Teilnehmer-VCRs erhalten wurden) an den Schattenfunktionsblock zu liefern, anstelle der Daten, die für die verketteten Parameter unter Verwendung der Objektope­ ration erhalten werden. Dies ist erforderlich, um sicherzu­ stellen, daß die zuletzt erstellten Daten für die verketteten Parameter (das heißt diejenigen, die durch die synchronen Kommunikationen in dem Fieldbus-Netzwerk erhalten wurden) dem Schattenfunktionsblock 108 angeboten werden anstelle der Da­ ten, die für diese Parameter unter Verwendung der Betrach­ tungslistenoperation erhalten werden (was asynchron erfolgt).

Wenn ein Steuermodul, der einen Schattenfunktionsblock ver­ wendet, zu Beginn konfiguriert wird, muß das Fieldbus-Kommu­ nikationsnetzwerk ebenfalls konfiguriert werden, um die er­ forderlichen synchronen und asynchronen Nachrichtenübertra­ gungen zwischen dem aktuellen Funktionsblock 112 und dem Schattenfunktionsblock 108 zu unterstützen. Die Fig. 7-12 veranschaulichen Flußdiagramme, welche die Schritte heraus­ greifen, die beim Konfigurieren des Fieldbus-Netzwerks invol­ viert sind, um die Schattenfunktionsblöcke zu unterstützen. Während die Fig. 7-10 als getrennte Flußdiagramme dargestellt sind, können sie gleichzeitig oder nahezu gleichzeitig ausge­ führt werden.

Fig. 7 zeigt ein Flußdiagramm 210, welches dazu verwendet werden kann, einen verbindungsaktiven Plan oder Ablaufsteue­ rung in dem Fieldbus-Netzwerk zu erstellen. Ein Block 211 in­ nerhalb des Kontrollers 12 empfängt das LAS-Plan-In­ stallationsskript, wie es durch das Konfigurationswerkzeug für das Fieldbus-Kommunikationsnetzwerk entwickelt wurde, und zwar nach Inbetrachtziehung aller synchroner Nachrichtenüber­ tragungen, die über den Fieldbus-Bus stattfinden müssen, in­ klusive solcher, die für die Schattenfunktionsblöcke erfor­ derlich sind. Natürlich kann dieses Installationsskript unter Verwendung bekannter Werkzeuge erzeugt werden, die für das Fieldbus-Kommunikationsprotokoll verfügbar sind, die auch in dem Konfigurationswerkzeug des Kontrollers 12 integriert sein können. Ein Block 212 installiert dann den LAS-Plan (Abwick­ ler) an dem angepeilten Fieldbus-Port, der beispielsweise die Schnittstellenkarte 40 aus Fig. 5 sein kann.

Danach erzeugt ein Block 213 automatisch Teilnehmerverbindun­ gen und VCRs innerhalb des Fieldbus-Netzwerks basierend auf den Daten, die durch die Fieldbus-Vorrichtungen veröffent­ licht werden. Speziell werden diese Teilnehmerverbindungen derart erzeugt, daß die Schnittstellenkarte 40 teil hat an den verketteten Parametern der Fieldbus-Funktionsblöcke, für Schattenfunktionsblöcke innerhalb des Kontrollers 12 existie­ ren. In ähnlicher Weise gibt die Schnittstellenkarte 40 Daten heraus, die durch die Funktionsblöcke innerhalb des Kontrol­ lers 12 erzeugt werden und die zu den Schattenfunktionsblöc­ ken innerhalb des Kontrollers 12 als ein verketteter Parame­ ter gesendet werden. Allgemein gesagt, agiert die Schnitt­ stellenkarte 40 als ein Funktionsblock-Proxy für die verket­ teten Daten zu und von den Schattenfunktionsblöcken. Ferner wirkt die Schnittstellenkarte 40 als ein Funktionsblock- Proxy, um nach Betrachtungsobjekt- und Warnobjektinformatio­ nen von den tatsächlichen oder aktuellen Funktionsblöcken an­ zufragen, für welche Schattenfunktionsblöcke existieren, um die nicht verketteten Daten zu erneuern, die den Schatten­ funktionsblöcken innerhalb des Kontrollers 12 zugeordnet sind.

Ein Block 214 bildet dann den LAS-Installationsstatus in dem Kontroller (oder DeltaV-)Status ab, so daß der Kontroller 12 bestimmen kann, ob die LAS-Installation akzeptiert worden ist oder durch das Fieldbus-Netzwerk abgewiesen wurde. Dies er­ möglicht es dem Kontroller 12 zu verifizieren, ob die Instal­ lation des Fieldbus-Netzwerks stattgefunden hat.

Fig. 8 veranschaulicht ein Flußdiagramm 220, welches die Schritte zeigt, die dazu verwendet werden, um die Veröffent­ licher-Verbindungen innerhalb des Fieldbus-Netzwerks zu er­ stellen. Ein Block 221 in dem Kontroller 12 empfängt die Ver­ öffentlicher-Verbindungen, die durch das Workstation-Konfi­ gurationswerkzeug für das Fieldbus-Netzwerk erzeugt wur­ den, und ein Block 222 sendet dann diese Veröffentlicher-Ver­ bindungen (publisher links) zu der Schnittstellenkarte 40, um die Veröffentlicher-Verbindungen zu erstellen und auch die zugeordneten VCRs, die erforderlich sind, um die Schatten­ funktionsblockkommunikationen als auch andere Kommunikationen auf dem Funktionsblock 42 zu unterstützen.

Fig. 9 zeigt ein Flußdiagramm 230, welches die Schritte ver­ anschaulicht, die der Installation einer Vorrichtungskonfigu­ ration innerhalb einer Fieldbus-Vorrichtung zugeordnet sind. Ein Block 231 empfängt das Vorrichtungskonfigurations-In­ stallationsskript von der Workstation, konfiguriert durch das Konfigurationswerkzeug, nachdem all die Verbindungs- und anderen Informationen für diese Vorrichtung erstellt worden sind. Ein Block 232 löscht dann die frühere Konfiguration in der Vorrichtung, indem sie geeignete Befehle zu der Vorrich­ tung über die Schnittstellenkarte 40 sendet. Während es nicht strikt erforderlich ist, wurde es als wünschenswert gefunden, die frühere Vorrichtungskonfiguration zu löschen, bevor ver­ sucht wird, eine neue Vorrichtungskonfiguration in der Field­ bus-Vorrichtung zu installieren, um dadurch Installationspro­ bleme zu vermeiden.

Ein Block 233 installiert dann die VCRs und ein Block 234 in­ stalliert die Verbindungen, die erforderlich sind, um die Kommunikation gemäß dem verbindungsaktiven Plan und die Ver­ öffentlicher/Teilnehmerbeziehungen, die für das Field­ bus-Netzwerk erstellt wurden, zu implementieren. Ein Block 235 installiert dann die Fieldbus-Startliste in der Vorrichtung, was die Funktionsblock-Programmausführung von dieser Vorrich­ tung mit der Programmausführungen von anderen Funktionsblöc­ ken in anderen Vorrichtungen des Fieldbus-Netzwerks synchro­ nisiert. Danach installiert ein Block 236 den Makrozyklus der Vorrichtung, nachdem dieser Makrozyklus berechnet worden ist oder bestimmte worden ist, um all den synchronen Kommunika­ tionen Rechnung zu tragen, die zwangsweise über den Bus 42 stattfinden müssen, welcher dem Fieldbus zugeordnet ist.

Fig. 10 zeigt ein Flußdiagramm 240, welches die Schritte ver­ anschaulicht, die dazu verwendet werden, um einen speziellen oder bestimmten Funktionsblock innerhalb einer bestimmten Vorrichtung innerhalb des Fieldbus-Netzwerks zu erstellen. Ein Block 241 empfängt zuerst ein Funktionsblock-In­ stallationsskript, wie es durch das Konfigurationswerkzeug entwickelt wurde. Ein Block 242 installiert dann den nächsten Funktionsblock und Programmausführungsperiodenparameter, wie dies in typischer Weise vorgenommen wird, wenn ein Field­ bus-Funktionsblock konfiguriert wird. Danach setzt ein Block 243 den Funktionsblockmodus außer Service, was erforderlich ist, um die Werte innerhalb des Funktionsblockes zu ändern. Ein Block 244 installiert dann die gemäß dem Funktionsblockpara­ meter konfigurierten Werte oder die Anwenderprioritäten (overrides) (das heißt die anwenderdefinierten Werte) inner­ halb des Funktionsblockes. Diese durch den Anwender konfigu­ rierten Werte können in irgendeiner Weise erstellt werden, wie beispielsweise durch die Verwendung von Dialogboxen in der Workstation während der Konfiguration des Prozeßregelsy­ stems. Danach stellt ein Block 245 den Funktionsblockmodus auf den konfigurierten Wert ein, so daß der Funktionsblock in Einklang mit der Art arbeitet, in welcher dieser konfiguriert ist.

Es sei darauf hingewiesen, daß die Flußdiagramme der Fig. 7-9 lediglich die normalen Schritte angeben, die dazu verwendet werden, um ein Fieldbus-Netzwerk zu konfigurieren. In diesem Fall trägt jedoch die Erstellung des Fieldbus-Netzwerks Rech­ nung hinsichtlich der und enthält die Veröffentli­ cher/Teilnehmerverbindungen und VCRs, die erforderlich sind, um den Betrieb von irgendeinem der Schattenfunktionsblöcke innerhalb des Kontrollers 12 zu unterstützen. Natürlich kann die Anwenderworkstation oder der Kontroller 12 das Field­ bus-Netzwerk automatisch konfigurieren, basierend auf den Infor­ mationen, die durch den Anwender über die Erstellung des Re­ gelsystems während der Konfiguration dieses Systems geliefert werden.

Gemäß Fig. 11 veranschaulicht ein Flußdiagramm 250 die Be­ triebsweise eines Schattenfunktionsblockes, wenn ein Steuer­ modul, der diesen Schattenfunktionsblock enthält, auf dem Kontroller 12 läuft, um die Prozeßsteuerung oder -regelung durchzuführen. Wie zu erkennen ist, implementiert der Kon­ troller 12 die Blöcke innerhalb eines bestimmten Moduls (wie beispielsweise die Blöcke 102, 104, 106 und 108 von Fig. 4) in der Modulabtastrate, die dem Modul zugeordnet ist. Die Kommunikation von verketteten Daten (wie denjenigen, die durch die Verbindungen in dem Diagramm von Fig. 4 definiert sind) zwischen den aktuellen Fieldbus-Funktionsblöcken und den Schattenfunktionsblöcken erfolgt in der synchronen Makro­ zyklusrate des Fieldbus-Netzwerks, die verschieden sein kann von der Modulabtastrate des Kontrollers 12. Als ein Ergebnis werden die Daten für die verketteten Parameter in typischer Weise in der unteren Datenbank 156 des Kontrollers 12 in ei­ ner unterschiedlichen (gewöhnlich schnelleren) Rate als die Daten für nicht verkettete Parameter gespeichert.

Wenn der Schattenfunktionsblock in dem Kontroller 12 imple­ mentiert ist, tastet ein Block 252 die Betriebsdaten ab, die innerhalb der unteren Datenbank 156 des Kontrollers 12 ge­ speichert sind. Das heißt, es werden während jeder Modulperi­ ode die Betriebsdaten, die in der unteren Datenbank 156 ge­ speichert wurden, durch den Schnittstellenmodul 40 gelesen. Ein Block 254 ermittelt, ob die Abtastung voranschreitet. Wenn dies nicht der Fall ist, erneuert ein Block 256 den Blockfehler in dem Schattenfunktionsblock, stellt den Schat­ tenfunktionsblock-Ausgangsstatus auf schlecht ein und stellt die Port-Integrität so ein, um dem Kontroller 12 anzuzeigen, daß der Schattenfunktionsblock ausgefallen ist und daß daher ein Problem in bezug auf den externen Funktionsblock oder in bezug auf Nachrichtenübertragungen mit dem externen Funkti­ onsblock innerhalb des Fieldbus-Netzwerks auftreten kann. Wenn solch ein Fehler detektiert wird, werden die Schatten­ funktionsblockdaten nicht erneuert (da diese Daten alt sind oder in jedem Fall schlechte Daten sind) und es wird die Er­ neuerungsoperation der Daten innerhalb des Schattenfunktions­ blocks für diesen Modulabtastzyklus angehalten. Wenn jedoch die Abtastung voranschreitet, kopiert ein Block 258 die emp­ fangenen Betriebsdaten in dem Schattenfunktionsblock. Natür­ lich enthalten die Betriebsdaten nicht nur die Daten, die durch die Betrachtungs- und Warnobjekte in der Modulabtastra­ te erhalten werden, sondern auch die Daten für die verkette­ ten Parameter, die erhalten wurden und in die untere Daten­ bank 156 in einer Rate eingeschrieben werden, die durch den Makrozyklus des Fieldbus-Netzwerks festgelegt wird.

Ein Block 260 ermittelt dann, ob der statistische Revisions­ parameter, der dem tatsächlichen Funktionsblock zugeordnet ist (der durch die Betrachtungsobjektoperation geliefert wird) zugenommen hat. Wenn dies der Fall ist, instruiert ein Block 252 die Schnittstellenkarte 40, die statischen Daten, die dem Fieldbus-Funktionsblock zugeordnet sind, zu lesen und diese statischen Daten zu der unteren Datenbank 156 zu lie­ fern, wo diese Daten gelesen werden und in den Schattenfunk­ tionsblock eingesetzt werden. Wie dies bekannt ist, zeigt der statische Visionsparameter an, ob irgendwelche statischen Da­ ten, die normalerweise durch die statische Betrachtungsliste vorgesehen werden, geändert wurden. Wenn der statische Revi­ sionsparameter nicht erhöht wurde, werden keine der stati­ schen Daten geändert und es ist nicht erforderlich, diese Da­ ten während jedes Zyklusses des Steuermoduls zu lesen. Wenn jedoch die statische Datenrevision zugenommen hat, dann haben sich einige der statischen Daten geändert und es müssen diese statischen Daten gelesen werden und in den Schattenfunktions­ block gesetzt werden, so daß der Schattenfunktionsblock die Daten spiegelt, die tatsächlich innerhalb des externen Funk­ tionsblocks vorhanden sind.

Nachdem die statischen Daten erhalten worden sind oder die statische Revision nicht zugenommen hat, bildet ein Block 264 die Fieldbus-Alarme (und andere Daten, wenn dies erforderlich ist) in den Alarmen (oder anderen Datenbereichen) des Kon­ trollers 12 ab. Diese Abbildung kann unter Verwendung einer Nachschlagetabelle erreicht werden oder durch irgendeine an­ dere Abbildungstechnik. Die abgebildeten Alarmgrößen (und an­ dere Daten) werden dann in dem Schattenfunktionsblock gespei­ chert, um durch andere Steuerblöcke des Steuermoduls verwen­ det zu werden. Die Alarmgrößen können auch für einen Anwender dargestellt werden oder in irgendeiner anderen gewünschten Weise verwendet werden.

Danach ermittelt ein Block 266, ob die Daten für die verket­ teten Parameter veraltet sind (das heißt nicht mehr aktuell sind). Solch eine Anzeige wird in regulärer Weise in den Fieldbus-Kommunikationen erzeugt und sie zeigt an, daß die empfangenen Daten nicht in dem allerletzten Makrozyklus des Fieldbus-Netzwerks erzeugt wurden, was anzeigen kann, daß ein Zeitsteuerproblem oder ein anderes Problem innerhalb des Fieldbus-Netzwerks existieren kann. Wenn die Verkettungspara­ meterdaten veraltet sind, markiert ein Block 268 die Aus­ gangsdaten als BadNotConnected, was den Modus oder Status von anderen Funktionsblöcken innerhalb des Kontrollers 12 ändern kann. Danach oder wenn die verketteten Daten nicht veraltet sind, macht ein Block 270 die Betriebsdaten für andere Blöcke innerhalb des Kontrollers 12 sichtbar und der Kontroller 12 fährt damit fort, basierend auf den neuen Betriebsdaten zu arbeiten.

Wie ersehen werden kann, veranschaulicht das Flußdiagramm von Fig. 11 die Betriebsweise der Erneuerung des Schattenfunkti­ onsblocks, um sicherzustellen, daß dieser die Daten spiegelt, die dem externen Funktionsblock innerhalb einer externen Vor­ richtung zugeordnet sind. Jedoch kann der Schattenfunktions­ block auch Daten zu dem externen Funktionsblock übertragen und Schreibbefehle an den externen Funktionsblock senden. Solche Daten und Schreibbefehle können von einem Anwender, beispielsweise bei einer Workstation, vorgesehen werden oder können an anderen Funktionsblöcken innerhalb des Kontrollers 12 entspringen und von diesen ausgesendet werden, und zwar über die erstellten Verbindungen. Gemäß Fig. 12 veranschau­ licht ein Flußdiagramm 280 die Schritte, die unternommen wer­ den, um Daten oder Schreibbefehle zu einem externen Funkti­ onsblock über den Schattenfunktionsblock zu senden. Bei einem Block 281 schreibt ein Steuerblock innerhalb des Kontrollers 12 Daten über eine Eingangsverbindung in den Schattenfunkti­ onsblock ein. Alternativ kann ein Anwender einen Schreibbe­ fehl an den Schattenfunktionsblock über eine Anwenderschnitt­ stelle senden, was es einem Anwender ermöglicht, z. B. von Hand einen Sollwert oder einen anderen Wert, der dem externen Funktionsblock zugeordnet ist, zu ändern. Der Schattenfunkti­ onsblock sendet dann unmittelbar einen Schreibbefehl oder an­ dere Daten an die Schnittstellenkarte 40. Wenn solche Daten oder Befehl einem verketteten Parameter zugeordnet sind oder ist, veröffentlicht die Schnittstellenkarte 40 die Daten auf dem Fieldbus-Bus für den externen Funktionsblock zu einem ge­ eigneten oder synchronen Zeitpunkt, wie dieser durch den Ma­ krozyklus des Fieldbus-Netzwerks festgelegt ist. Wenn der Schreibbefehl oder die Daten nicht einem verketteten Parame­ ter zugeordnet ist bzw. sind, verwendet die Schnittstellen­ karte 40 asynchrone Nachrichtenübertragungen, um den Befehl oder die Daten an den externen Funktionsblock zu übermitteln. Danach empfängt der externe Funktionsblock die Daten oder den Befehl und erneut deren oder dessen Attributparameter ent­ sprechend. Diese Änderungen werden dann über die Schnittstel­ lenkarte 40 unter Verwendung von Veröffentlicher/Teil­ nehmer-Kommunikationen zurück übertragen, als auch die Betrachtungs­ objektoperation, und es werden die neuen Daten in die untere Datenbank 156 gesetzt, wo dann während des nächsten Abtastzy­ klusses des Steuermoduls diese Daten in den Schattenfunkti­ onsblock eingesetzt werden.

Wenn der Block 282 eine Schreibanfrage an die Schnittstellen­ karte 40 sendet und diese Anfrage zu dem externen Funktions­ block gesendet wird, empfängt die Schnittstellenkarte 40 eine Antwort von dem Funktionsblock, die anzeigt, ob der Schreibvorgang vervollständigt worden ist oder ob die Daten angenommen oder empfangen wurden. Die Schnittstellenkarte 40 sendet ihrerseits diese Antwort zu dem Schattenfunktions­ block. Wenn der Schreibvorgang fehlgeschlagen ist, kann die Status-, Alarm- oder Fehlereinstellung des Schattenfunktions­ blocks geändert werden, um diesen Fehler zu reflektieren. Wenn beispielsweise eine Schreibanfrage, die einem verkette­ ten Parameter zugeordnet ist, nicht empfangen wurde oder nicht richtig durch die Schnittstelle 40 implementiert wurde, kann dies in dem Fehlerstatus des Schattenfunktionsblocks an­ gezeigt werden. Wenn es gewünscht wird, wenn ein Schreibbe­ fehl, der von einem Anwender stammt, fehlschlägt, implemen­ tiert zu werden, kann ein Block 283 eine Anzeige über den Fehlschlag für den Anwender bei der Workstation senden oder zu irgendeiner anderen Anwenderschnittstelle, um dadurch den Anwender über den fehlgeschlagenen Versuch zu unterrichten, in den externen Funktionsblock zu schreiben.

Während sich die Beschreibung auf die Implementierung und die Verwendung eines einzelnen Schattenfunktionsblockes 108 ge­ richtet hat, sei darauf hingewiesen, daß viele Schattenfunk­ tionsblöcke in dem gleichen Steuermodul oder Kontroller im­ plementiert werden können, um es dem Steuermodul oder Kon­ troller zu ermöglichen, viele externe Funktionsblöcke zu ver­ wenden. Ferner können Schattenfunktionsblöcke implementiert werden unter Verwendung irgendeines externen Prozeßsteuer- oder -regel-Kommunikationsprotokolls (neben dem Fieldbus-Proto­ koll) und können dazu verwendet werden, mit irgendeinem Typ eines Funktionsblocks zu kommunizieren, inklusive irgend­ einem Funktionsblock, der ähnlich ist mit oder der gleiche ist wie irgendeiner der unterschiedlichen Funktionsblöcke, die durch das Fieldbus-Protokoll spezifisch identifiziert und unterstützt werden. Obwohl darüber hinaus Schattenfunktions­ blöcke hier so beschrieben wurden, als ob sie einem externen Funktionsblock zugeordnet sind, und zwar in der Form, in wel­ cher das Fieldbus-Protokoll einen "Funktionsblock" definiert, sei darauf hingewiesen, daß die Verwendung des Ausdrucks "Funktionsblock" hier nicht auf das beschränkt ist, was das Fieldbus-Protokoll als einen Funktionsblock definiert, son­ dern statt dessen irgendein anderer Typ eines Blocks, Pro­ gramms, einer Hardware, Firmware usw. enthalten ist, die mit irgendeinem Typ eines Steuersystems oder Regelsystems und/oder Kommunikationsprotokoll zugeordnet ist und die dazu verwendet werden kann, um eine gewisse Steuerfunktion oder Regelfunktion zu implementieren. Obwohl somit Funktionsblöcke typisch die Form von Objekten annehmen, und zwar innerhalb einer objektorientierten Programmierumgebung, muß dies nicht der Fall sein und statt dessen können andere logische Einhei­ ten dazu verwendet werden, um eine bestimmte Steuerung oder Regelung (inklusive Eingabe- und Ausgabe-)Funktionen inner­ halb einer Prozeßsteuerumgebung oder Prozeßregelumgebung aus­ zuführen.

Obwohl ferner der Schattenfunktionsblock, der hier beschrie­ ben wurde, in bevorzugter Weise in einer Software implemen­ tiert wird, die beispielsweise in einem Kontroller oder einer anderen Prozeßsteuervorrichtung gespeichert ist, kann sie al­ ternativ oder zusätzlich in einer Hardware, Firmware usw. in gewünschter Weise implementiert sein. Wenn sie in einer Soft­ ware implementiert ist, kann der Schattenfunktionsblock der vorliegenden Erfindung in irgendeinem computerlesbaren Spei­ cher gespeichert sein, wie beispielsweise einer Magnetplatte, einer Laserplatte oder einem anderen Speichermedium, in einem RAM oder ROM eines Computers usw. In ähnlicher Weise kann diese Software an einen Anwender oder eine Vorrichtung aus ge­ liefert werden, und zwar über irgendein bekanntes oder ge­ wünschtes Auslieferungsverfahren, inklusive beispielsweise über einen Nachrichtenübertragungskanal, wie beispielsweise eine Telefonleitung, das Internet usw.

Obwohl auch der Schattenfunktionsblock der vorliegenden Er­ findung in Einzelheiten in Verbindung mit einem Prozeßregel­ netzwerk beschrieben wurde, welches die Prozeßsteuerfunktio­ nen in einer dezentralisierten oder verteilten Weise unter Verwendung eines Satzes von Fieldbus-Vorrichtungen implemen­ tiert, sei darauf hingewiesen, daß der Schattenfunktionsblock der vorliegenden Erfindung in Verbindung mit Prozeßregelnetz­ werken verwendet werden kann, die Steuerfunktionen ausführen, unter Verwendung von anderen Typen von Bereichsvorrichtungen und Kommunikationsprotokollen, inklusive der Protokolle, die auf anderen als den zwei Leitungsbussen basieren, und Proto­ kollen, die analog und/oder digitale Nachrichtenübertragungen unterstützen. Der Schattenfunktionsblock der vorliegenden Er­ findung kann beispielsweise in irgendeinem Prozeßregelnetz­ werk verwendet werden, welches Vorrichtungen verwendet, die in Einklang mit dem HART-, PROFIBUS-, usw. Kommunikationspro­ tokollen oder irgendeinem anderen Kommunikationsprotokoll stehen, die es nunmehr gibt oder die in der Zukunft entwic­ kelt werden können. In ähnlicher Weise kann, wenn dies ge­ wünscht wird, der Schattenfunktionsblock der vorliegenden Er­ findung in Prozeßregelnetzwerken verwendet werden, die keine verteilten Steuerfunktionen haben, sondern statt dessen einen zentralisierten Kontroller oder ein Steuer- oder Regelschema verwenden, um die Vorrichtungen darin zu steuern oder zu re­ geln.

Während die vorliegende Erfindung in bezug auf spezifische Beispiele beschrieben wurde, die dazu dienen, die Erfindung lediglich zu veranschaulichen, jedoch nicht einzuschränken, ist es für Fachleute offensichtlich, daß Änderungen, Ergän­ zungen oder Weglassungen bei den offenbarten Ausführungsfor­ men vorgenommen werden können, ohne dadurch die Idee und den Rahmen der vorliegenden Erfindung zu verlassen.

Claims (29)

1. Interface-Funktionsblock für die Verwendung in einem Prozeßkontroller, der kommunikativ mit einer externen Vorrichtung über ein Kommunikationsnetzwerk gekoppelt ist, wobei der Prozeßkontroller folgendes implementiert:

• - eine Steuerroutine unter Verwendung eines internen Funktionsblockes, welcher innerhalb des Prozeßkon­ trollers angeordnet ist, und
• - einen externen Funktionsblock, der in der externen Vorrichtung angeordnet ist, wobei der Interface-Funkti­ onsblock folgendes aufweist:
• - einen Kommunikationsport mit einem Eingang, der mit dem externen Funktionsblock über das Kommunikations­ netzwerk kommuniziert, um Daten, die den externen Funktionsblock betreffen, zu empfangen, und
• - einen Speicher, der die empfangenen Daten, die den ex­ ternen Funktionsblock betreffen, gemäß einem Kommuni­ kationsprotokoll des internen Funktionsblockes spei­ chert.

2. Interface-Funktionsblock nach Anspruch 1, der ferner einen Ausgang umfaßt, der die Daten, die den ex­ ternen Funktionsblock betreffen, an den internen Funkti­ onsblock gemäß dem Kommunikationsprotokoll des internen Funktionsblockes liefert.

3. Interface-Funktionsblock nach Anspruch 2, bei dem der Eingang des Kommunikationsports die Daten, die den externen Funktionsblock betreffen, unabhängig von der Operation des internen Funktionsblockes emp­ fängt.

4. Interface-Funktionsblock nach Anspruch 2, bei dem der externe Funktionsblock über das Kommunikati­ onsnetzwerk unter Verwendung eines ersten Kommunikati­ onsprotokolls kommuniziert, welches verschieden ist von einem zweiten Kommunikationsprotokoll, das dem Konfigu­ rationsprotokoll des internen Funktionsblockes zugeord­ net ist und bei dem der Eingang des Kommunikationsports mit dem externen Funktionsblock unter Verwendung des er­ sten Kommunikationsprotokolls kommuniziert und der Aus­ gang mit dem internen Funktionsblock gemäß dem zweiten Kommunikationsprotokoll kommuniziert.

5. Interface-Funktionsblock nach Anspruch 4, bei dem das erste Kommunikationsprotokoll ein Field­ bus-Kommunikationsprotokoll ist und bei dem der Eingang des Kommunikationsports mit dem externen Funktionsblock un­ ter Verwendung des Fieldbus-Kommunikationsprotokolls kommuniziert.

6. Interface-Funktionsblock nach Anspruch 5, bei dem der Eingang des Kommunikationsports eine Schnittstellenvorrichtung verwendet, die konfiguriert ist, um mit der externen Vorrichtung unter Verwendung des Fieldbus-Kommunikationsprotokolls zu kommunizieren, um mit dem externen Funktionsblock zu kommunizieren.

7. Interface-Funktionsblock nach Anspruch 1, bei dem der Kommunikationsport mit dem externen Funkti­ onsblock unter Verwendung synchroner Nachrichtenübertra­ gungen kommuniziert.

8. Interface-Funktionsblock nach Anspruch 1, bei dem der Kommunikationsport mit dem externen Funkti­ onsblock unter Verwendung synchroner und asynchroner Nachrichtenübertragungen kommuniziert.

9. Interface-Funktionsblock nach Anspruch 1, bei dem die externe Vorrichtung unter Verwendung eines Vorrichtungskommunikationsprotokolls Nachrichten über­ mittelt, welches die Kommunikation von logisch verkette­ ten Paketen von Daten unter Verwendung von standardi­ sierten Kommunikationsanrufen unterstützt und bei dem der Kommunikationsport mit dem externen Funktionsblock unter Verwendung der standardisierten Kommunikationsan­ rufe kommuniziert, die dem Vorrichtungskommunikations­ protokoll zugeordnet sind.

10. Interface-Funktionsblock nach Anspruch 9, bei dem das Vorrichtungskommunikationsprotokoll ein Fieldbus-Kommunikationsprotokoll ist und bei dem der Kommunikationsport mit der externen Vorrichtung unter Verwendung von Betrachtungsobjekten innerhalb des Field­ bus-Kommunikationsprotokolls kommuniziert.

11. Interface-Funktionsblock nach Anspruch 1, bei dem der Kommunikationsport eine Alarmanzeige von dem externen Funktionsblock empfängt und bei dem der Spei­ cher die empfangene Alarmanzeige speichert.

12. Interface-Funktionsblock nach Anspruch 1, bei dem der Kommunikationsport ferner einen Ausgang ent­ hält, welcher Daten zu dem externen Funktionsblock unter Verwendung eines Kommunikationsprotokolls sendet, wel­ ches dem externen Funktionsblock zugeordnet ist.

13. Kontroller, der dafür ausgebildet ist, um kommunikativ an eine Vielzahl von Bereichsvorrichtungen gekoppelt zu werden, wobei eine der Bereichsvorrichtungen einen ex­ ternen Funktionsblock enthält, der unter Verwendung ei­ nes Vorrichtungskommunikationsprotokolls Nachricht über­ trägt, wobei der Kontroller folgendes aufweist:
einen Prozessor;
einen Speicher; und
eine Steuerroutine, die in dem Speicher gespeichert ist und durch den Prozessor implementiert wird, um die Viel­ zahl der Bereichsvorrichtungen zu steuern, wobei die Steuerroutine folgendes enthält:

• - eine Vielzahl von miteinander verbundenen inter­ nen Funktionsblöcken, die so konfiguriert sind, um ein Kontrollerprotokoll zu verwenden und durch den Kontroller implementiert sind, und
• - einen Interface-Funktionsblock, der mit einer der Vielzahl der miteinander verbundenen inter­ nen Funktionsblöcke unter Verwendung des Kon­ trollerprotokolls kommuniziert, und der mit dem externen Funktionsblock innerhalb einer der Be­ reichsvorrichtungen unter Verwendung des Vor­ richtungskommunikationsprotokolls kommuniziert, wobei der Interface-Funktionsblock Daten spei­ chert, die den externen Funktionsblock betref­ fen, welche von dem externen Funktionsblock emp­ fangen wurden.

14. Kontroller nach Anspruch 13, bei dem der Interface-Funktionsblock die Daten, die den externen Funktionsblock betreffen, unabhängig von der Operation der Vielzahl der internen Funktionsblöcke emp­ fängt.

15. Kontroller nach Anspruch 13, bei dem das Vorrichtungskommunikationsprotokoll ein Fieldbus-Kommunikationsprotokoll ist und bei dem der In­ terface-Funktionsblock mit dem externen Funktionsblock unter Verwendung des Fieldbus-Kommunikationsprotokolls kommuniziert.

16. Kontroller nach Anspruch 15, bei dem der Interface-Funktionsblock mit dem externen Funktionsblock unter Verwendung von Betrachtungsobjekten innerhalb des Fieldbus-Kommunikationsprotokolls kommuni­ ziert.

17. Kontroller nach Anspruch 15, bei dem der Interface-Funktionsblock mit dem externen Funktionsblock unter Verwendung von Teilneh­ mer /Herausgeber-Nachrichtenübertragungen innerhalb des Fieldbus-Kommunikationsprotokolls kommuniziert.

18. Kontroller nach Anspruch 13, bei dem der Interface-Funktionsblock Daten, welche die Eingangsgrößen und Ausgangsgrößen des externen Funkti­ onsblockes betreffen, empfängt und speichert.

19. Kontroller nach Anspruch 13, bei dem der Interface-Funktionsblock Daten, die Alarm­ größen betreffen, welche durch den externen Funktions­ block erzeugt wurden, empfängt und speichert.

20. Kontroller nach Anspruch 13, bei dem der Interface-Funktionsblock Daten, die den Mo­ dus des externen Funktionsblockes betreffen, empfängt und speichert.

21. Kontroller nach Anspruch 13, bei dem der Interface-Funktionsblock Daten, die durch eine der Vielzahl der internen Funktionsblöcke erzeugt wurden, zu dem externen Funktionsblock sendet.

22. Kontroller nach Anspruch 13, bei dem der Interface-Funktionsblock einen Befehl, der durch den Kontroller erzeugt wurde, zu dem externen Funktionsblock sendet.

23. Verfahren zum Implementieren einer Steuer- oder Regel­ routine in einem Prozeßkontroller, der kommunikativ mit einer Bereichsvorrichtung gekoppelt ist, wobei die Be­ reichsvorrichtung einen externen Funktionsblock auf­ weist, der in ihr angeordnet ist und unter Verwendung eines Vorrichtungskommunikationsprotokolls Nachrichten überträgt, wobei das Verfahren die folgenden Schritte umfaßt:

• - Speichern einer Vielzahl von miteinander verbundenen internen Funktionsblöcken in dem Kontroller, der gemäß einem Kontrollerprotokoll konfiguriert ist, um diese als Teil der Steuer- oder Regelroutine zu implementie­ ren;
• - Erzeugen eines Interface-Funktionsblockes innerhalb des Kontrollers, der gemäß dem Kontrollerprotokoll konfiguriert ist, wobei der Interface-Funktionsblock mit dem externen Funktionsblock unter Verwendung des Vorrichtungskommunikationsprotokolls kommuniziert;
• - Erzeugen einer Steuer- oder Regelroutine, welche die Vielzahl der miteinander verbundenen internen Funkti­ onsblöcke und den Interface-Funktionsblock verwendet, um den Prozeß zu steuern oder zu regeln; und
• - Speichern von Daten in dem Interface-Funktionsblock während der Implementierung der Steuer- oder Regelrou­ tine, die dem externen Funktionsblock zugeordnet sind und von diesem empfangen werden.

24. Verfahren nach Anspruch 23, welches ferner den Schritt der Verwendung des Interface-Funkti­ onsblockes für eine Kommunikation mit dem externen Funktionsblock aufweist, um Daten, die dem externen Funktionsblock zugeordnet sind, unabhängig von der Ope­ ration der internen Funktionsblöcke zu erneuern.

25. Verfahren nach Anspruch 23, welches ferner den Schritt einer Verwendung des Inter­ face-Funktionsblockes umfaßt, um weitere Daten zu dem externen Funktionsblock zu übertragen, um die Konfigura­ tion des externen Funktionsblockes zu ändern.

26. Verfahren nach Anspruch 23, welches ferner folgende Schritte enthält:

• - einem Anwender erlauben, die Steuer- oder Regelrouti­ ne dadurch zu konfigurieren, indem jeder eine Anzahl von Funktionsblöcken, die in der Steuer- oder Regel­ routine zu verwenden sind, spezifiziert wird,
• - die Verbindungen zwischen den spezifizierten Funkti­ onsblöcken, die in der Steuer- oder Regelroutine zu verwenden sind, zu identifizieren, und
• - die Lage eines bestimmten spezifizierten Funktions­ blockes als einen internen Funktionsblock zu spezifi­ zieren, der in dem Kontroller implementiert ist, oder als externen Funktionsblock zu spezifizieren, der durch die Bereichsvorrichtung implementiert ist.

27. Verfahren nach Anspruch 26, bei dem der Schritt der Spezifizierung der Lage des be­ stimmten spezifizierten Funktionsblockes als den exter­ nen Funktionsblock den folgenden Schritt aufweist:

• - Auswählen einer externen Vorrichtung, in welcher der externe Funktionsblock zu implementieren ist, aus ei­ ner Liste von externen Vorrichtungen, die an den Kon­ troller angeschlossen sind.

28. Verfahren nach Anspruch 23, bei dem der Schritt der Speicherung der Daten, die dem externen Funktionsblock zugeordnet sind, den folgenden Schritt aufweist:

• - Speichern einer Alarmanzeige, die durch den externen Funktionsblock in dem Interface-Funktionsblock er­ zeugt wird,
  und bei dem das Verfahren des weiteren folgenden Schritt aufweist:
• - Verwendung der Alarmanzeige, die in dem Interface-Funkti­ onsblock gespeichert ist, zum Triggern einer Alarmverarbeitung innerhalb des Kontrollers.

29. Verfahren nach Anspruch 23, welches ferner den folgenden Schritt aufweist:

• - Darstellung der Steuer- oder Regelroutine durch Dar­ stellen einer Wiedergabe der internen Funktionsblöcke, einer Wiedergabe des Interface-Funktionsblocks und von Wiedergaben der Verbindungen zwischen den internen Funktionsblöcken und den Interface-Funktionsblöcken, so daß der Interface-Funktionsblock den externen Funk­ tionsblock repräsentiert.