DE102009000899A1

DE102009000899A1 - Austausch von Projektdaten zwischen Planungsanwendungen der Prozessautomatisierungstechnik

Info

Publication number: DE102009000899A1
Application number: DE102009000899A
Authority: DE
Inventors: Francois De Goulle Ichtertz; Thiemo Fichter; Axel PÖSCHMANN; Alfred Polle
Original assignee: Endress and Hauser Process Solutions AG
Current assignee: Endress and Hauser Process Solutions AG
Priority date: 2009-02-16
Filing date: 2009-02-16
Publication date: 2010-08-19

Abstract

Ein Servicemodul zur Ausführung auf einem Rechner, auf dem eine Planungsanwendung zur Projektierung eines Feldbussystems sowie eine zugeordnete lokale Datenbank mit Projektdaten zu einem Projekt installiert ist, wobei das Servicemodul dazu ausgelegt ist, Veränderungen der Projektdaten zu dem Projekt zu verfolgen und Projektdaten aus der lokalen Datenbank bei Bedarf an andere an dem Projekt beteiligte Rechner zu übermitteln, und wobei das Servicemodul dazu ausgelegt ist, von anderen an dem Projekt beteiligten Rechnern Benachrichtigungen über Veränderungen der Projektdaten zu dem Projekt zu empfangen und Projektdaten von anderen an dem Projekt beteiligten Rechnern entsprechend von Anweisungen eines Benutzers ganz oder teilweise in die lokale Datenbank zu übernehmen.

Description

Die Erfindung betrifft ein Servicemodul gemäß dem Oberbegriff des Anspruchs 1 sowie ein Computersystem gemäß dem Oberbegriff des Anspruchs 6. Des weiteren betrifft die Erfindung ein Verfahren zur Übernahme von Projektdaten gemäß dem Anspruch 19.
In der Prozessautomatisierungstechnik werden vielfach Feldgeräte eingesetzt, die zur Erfassung und/oder Beeinflussung von Prozessvariablen dienen. Beispiele für derartige Feldgeräte sind Füllstandsmessgeräte, Massedurchflussmessgeräte, Druck- und Temperaturmessgeräte etc., die als Sensoren die entsprechenden Prozessvariablen Füllstand, Durchfluss, Druck bzw. Temperatur erfassen.
Zur Beeinflussung von Prozessvariablen dienen Aktoren, z. B. Ventile oder Pumpen über die der Durchfluss einer Flüssigkeit in einem Rohrleitungsabschnitt bzw. der Füllstand in einem Behälter geändert werden kann.
Als Feldgeräte werden im Prinzip alle Geräte bezeichnet, die prozessnah eingesetzt werden und die prozessrelevante Informationen liefern oder verarbeiten.
Eine Vielzahl solcher Feldgeräte wird von der Firma Endress+Hauser hergestellt und vertrieben.
Für die Planung und den Entwurf eines Feldbussystems mit einer Vielzahl von angeschlossenen Feldgeräten werden von verschiedenen Herstellern geeignete Planungsanwendungen angeboten. Es gibt Planungsanwendungen wie z. B. FieldCare, mit denen sich insbesondere die Geräteparameter der verschiedenen Feldgeräte festlegen lassen. Derartige Planungsanwendungen dienen also in erster Linie zur Parametrierung und Konfiguration der Feldgeräte.
Andere Planungsanwendungen wie z. B. ControlCare dienen dagegen in erster Linie zur Definition der Steuerungs- und/oder Regelungsfunktionalität innerhalb des Feldbussystems und definieren so das Zusammenwirken der verschiedenen Feldgeräte.
Daneben gibt es auch Planungsanwendungen zur Visualisierung des Feldbussystems, zur Diagnose des Feldbussystems sowie für ein Ressourcen- und Lieferungsmanagement zu einem Projekt.
Jeder dieser Planungsanwendungen ist in der Regel eine eigene Datenbank mit einem eigenen Bestand an Projektdaten zugeordnet. Projektdaten müssen daher häufig für jede Planungsanwendung separat eingegeben werden.
Aufgabe der Erfindung ist es, das Zusammenwirken von verschiedenen Planungsanwendungen der Prozessautomatisierungstechnik zu verbessern.
Gelöst wird diese Aufgabe durch die in den Ansprüchen 1, 6 und 19 angegebenen Merkmale.
Vorteilhafte Weiterentwicklungen der Erfindung sind in den Unteransprüchen angegeben.
Das erfindungsgemäße Servicemodul ist zur Ausführung auf einem Rechner vorgesehen, auf dem eine Planungsanwendung zur Projektierung eines Feldbussystems sowie eine zugeordnete lokale Datenbank mit Projektdaten zu einem Projekt installiert ist. Das Servicemodul ist dazu ausgelegt, Veränderungen der Projektdaten zu dem Projekt zu verfolgen und Projektdaten aus der lokalen Datenbank bei Bedarf an andere an dem Projekt beteiligte Rechner zu übermitteln. Außerdem ist das Servicemodul dazu ausgelegt, von anderen an dem Projekt beteiligten Rechnern Benachrichtigungen über Veränderungen der Projektdaten zu dem Projekt zu empfangen und Projektdaten von anderen an dem Projekt beteiligten Rechnern entsprechend von Anweisungen eines Benutzers ganz oder teilweise in die lokale Datenbank zu übernehmen.
Mit Hilfe der erfindungsgemäßen Servicemodule wird es jeder Planungsanwendung ermöglicht, Projektdaten zu übernehmen, die in den lokalen Datenbanken von anderen Planungsanwendungen gespeichert sind. Die dort gespeicherten Datenbestände können ganz oder teilweise in die eigene lokale Datenbank übernommen werden.
Die Übernahme von Projektdaten aus anderen Planungsanwendungen führt in vielen Fällen zu einer Arbeitserleichterung, weil Projektdaten wie beispielsweise Geräteparameter oder Topologiedaten nicht mehrmals in verschiedene Planungsanwendungen eingegeben werden müssen. Statt die Projektdaten mehrfach einzugeben, können die Projektdaten mit Hilfe der erfindungsgemäßen Servicemodule von einer anderen Planungsanwendung übernommen werden. Dadurch wird insbesondere bei komplexeren Automatisierungsprojekten die Arbeitsproduktivität verbessert.
Darüber hinaus führte die bisher erforderliche Mehrfacheingabe von Projektdaten auch zu Fehlern und Inkonsistenzen. In einer ersten Planungsanwendung wird beispielsweise versehentlich eine andere Hardwareversion eines Feldgeräts angegeben als in einer zweiten Planungsanwendung. Infolge derartiger Fehler kommt es dann zu Unverträglichkeiten und Fehlern bei der Zusammenarbeit der beiden Planungsanwendungen.
Durch Einsatz der erfindungsgemäßen Servicemodule können diese Fehler vermieden werden. Infolge des Datenaustauschs zwischen verschiedenen Planungsanwendungen erhält man einen konsistenten Bestand an Projektdaten, der dann von allen Planungsanwendungen genutzt werden kann.
Indem die Möglichkeit geschaffen wird, Projektdaten aus einer ersten Planungsanwendung ganz oder teilweise in eine zweite Planungsumgebung zu übernehmen, werden die heterogenen Planungstools zu einer integrierten Planungsumgebung für Projekte der Prozessautomatisierungstechnik zusammengeführt. Über die Servicemodule sind die Planungsanwendungen miteinander gekoppelt und können Projektdaten austauschen. Mit Hilfe der Servicemodule wird ohne Zutun des Benutzers eine Verbindung zwischen den lokalen Datenbanken der Planungsanwendungen erzielt, wobei sich die Planungsanwendungen selbst miteinander vernetzen. Auf diese Weise kommt es zu einer Autokonfiguration der verschiedenen Planungsanwendungen.
Dabei ist es insbesondere von Vorteil, wenn die verschiedenen zu einem Projekt gehörigen Projektdaten mit einer Projektkennung abgespeichert werden. Anhand der Projektkennung können zusammengehörige Projektdaten einander zugeordnet werden.
Nachfolgend ist die Erfindung anhand mehrerer in der Zeichnung dargestellter Ausführungsbeispiele näher erläutert.
Es zeigen:
1 mehrere Planungsanwendungen zur Projektierung eines Feldbussystems sowie das zugehörige Feldbussystem;
2 eine Topologie eines Feldbussystems;
3 eine alternative Ausführungsform der Erfindung; und
4A, 4B, 4C ein Ablaufschema zur Übernahme von Projektdaten einer ersten Planungsanwendung durch eine zweite Planungsanwendung.
In 1 ist in der unteren Hälfte ein Feldbussystem dargestellt, welches mehrere an einen Feldbus 100 angeschlossene Feldgeräte 101, 102 und 103 umfasst. An den Feldbus 100 ist eine speicherprogrammierbare Steuerung 104 angeschlossen, welche die von den Feldgeräten 101, 102, 103 ermittelten Messwerte in regelmäßigen Zeitabständen ausliest und basierend auf diesen Messwerten eine Steuerung oder Regelung des Feldbussystems realisiert.
Zur Parametrierung und Konfiguration des Feldbussystems ist ein weiterer Rechner 105 an den Feldbus 100 angeschlossen. Mittels des Rechners 105 können die Feldgeräte 101, 102, 103 sowie die speicherprogrammierbare Steuerung 104 konfiguriert und parametrisiert werden. Zu diesem Zweck sind auf dem Rechner 105 ein oder mehrere Kontroller 106 implementiert, die eine Schnittstelle zum Feldbussystem zur Verfügung stellen. Über die Kontroller 106 können Parameter in entsprechende Speicherbereiche der Feldgeräte geschrieben werden.
Während in 1 ein Feldbussystem mit drei Feldgeräten 101, 102, 103 gezeigt ist, umfassen Feldbussysteme für komplexere Prozessautomatisierungsprojekte häufig eine wesentlich größere Anzahl von Feldgeräten, beispielsweise mehrere hundert Feldgeräte. Zur Konfigurierung und Parametrierung derartiger Feldbussystem und zum Aufsetzen der Steuerungs- oder Regelungsfunktionalität für das Feldbussystem gibt es eine Vielzahl von Planungsanwendungen und Entwicklungsumgebungen, die von verschiedenen Herstellern angeboten werden.
In dem in 1 gezeigten Beispiel sind drei Rechner 107, 108, 109 zur Programmierung des Feldbussystems vorgesehen. Die drei Rechner 107, 108, 109 sind über ein Netzwerk 110 miteinander verbunden. Darüber hinaus sind die drei Rechner 107, 108, 109 über das Netzwerk 110 auch mit dem Rechner 105 verbunden, um so auf das Feldbussystem zugreifen zu können. Bei dem Netzwerk 110 kann es sich beispielsweise um ein LAN (Local Area Network) oder um ein WLAN (Wireless Local Area Network) handeln.
Auf dem Rechner 107 sind zwei verschiedene Planungsanwendungen 111 und 112 installiert, wobei jede der Planungsanwendungen die erstellten und bearbeiteten Projektdaten in einer zugeordneten lokalen Datenbank speichert. Dabei ist der Planungsanwendung 111 eine lokale Datenbank 113 zugeordnet, und der Planungsanwendung 112 ist eine lokale Datenbank 114 zugeordnet.
Auf dem Rechner 108 sind zwei weitere Planungsanwendungen 115 und 116 zusammen mit zugeordneten lokalen Datenbanken 117 und 118 installiert. Dabei speichert die Planungsanwendung 115 ihre Projektdaten in der zugehörigen lokalen Datenbank 117, während in der lokalen Datenbank 118 die Projektdaten der Planungsanwendung 116 abgelegt sind.
Auf dem Rechner 109 sind eine weitere Planungsanwendung 119 sowie eine zugehörige lokale Datenbank 120 installiert, in der die Projektdaten der Planungsanwendung 119 gespeichert werden.
Bei der Planungsanwendung 111 kann es sich beispielsweise um eine Planungsanwendung zum Festlegen von Parametern der Feldgeräte sowie von deren Funktionsblocks handeln. Eine Planungsanwendung dieser Art ist unter dem Namen „FieldCare” bekannt. Mit der Planungsanwendung 111 wird die Konfiguration und Parametrisierung der einzelnen Feldgeräte 101, 102, 103 des Feldbussystems durchgeführt. Beispielsweise spezifiziert der Benutzer für jedes der Feldgeräte 101, 102, 103 den Gerätetyp, die Hardwareversion, die Softwareversion sowie die auf Seiten des Feldgeräts vorhandenen Funktionsblocks. Darüber hinaus können beispielsweise Geräteparameter eines Feldgeräts festgelegt sowie Bereichsgrenzen und/oder Alarmgrenzen für einzelne Parameter definiert werden. Insbesondere kann mit der Planungsanwendung 111 beispielsweise eine Topologie des Feldbussystems definiert werden. Die von der ersten Planungsanwendung 111 erfassten Projektdaten werden in der zugehörigen lokalen Datenbank 113 gespeichert.
Die Planungsanwendung 111 kann darüber hinaus nicht nur zum Festlegen von Parametern der Feldgeräte, sondern auch zur Verfolgung und Überwachung der Parameterwerte eingesetzt werden. Auf diese Weise kann mit der Planungsanwendung 111 die Funktion der Feldgeräte 101, 102, 103 kontrolliert werden.
Bei der Planungswendung 112 kann es sich beispielsweise um eine Planungsanwendung für ein Ressourcen- und Lieferungsmanagement zu einem Prozessautomatisierungsprojekt handeln. Eine Planungsanwendung dieser Art ist unter dem Namen „SupplyCare” bekannt. Beispielsweise können mit Hilfe der Planungsanwendung 112 die Füllstande von Tanks und Containern erfasst, die für einen Prozess benötigten Mengen von Chemikalien und Lösungsmitteln bestimmt und Nachbestellungen bei verschiedenen Zulieferern veranlasst werden. In der zugehörigen lokalen Datenbank 114 sind daher beispielsweise Parameter wie Füllstand, Massefluss, Volumenfluss abgelegt, zusammen mit Daten, die zur Bestimmung der benötigten Mengen benötigt werden.
Bei der Planungsanwendung 115 kann es sich beispielsweise um eine Planungsanwendung zum Aufsetzen einer Steuerungs- oder Regelungsfunktionalität für das Feldbussystem handeln. Eine derartige Planungsanwendung ist unter dem Namen „ControlCare” bekannt. Dabei wird mit Hilfe der Planungsanwendung 115 definiert, welche Eingangsgrößen und Messwerte in welcher Weise miteinander zu verknüpfen sind, um geeignete Stellgrößen zur Steuerung und/oder Regelung der Systemabläufe im Feldbussystem zu generieren. Als Eingangsgrößen dienen dabei zum einen die von den Feldgeräten bereitgestellten Messgrößen und Geräteparameter. Die Steuerungs- oder Regelungsfunktionalität kann beispielsweise mit Hilfe von PID(Proportional, Integral, Differential)-Reglern definiert werden, welche eine Vielfalt von Verknüpfungen zwischen Messwerten, Eingangsparametern, aufintegrierten Eingangsgrößen und differenzierten Eingangsgrößen ermöglichen. Die Steuerungs- und/oder Regelungsfunktionalität des Systems kann beispielsweise mit Hilfe einer grafischen Benutzeroberfläche aufgesetzt werden. Die von der Planungsanwendung benötigten Projektdaten werden in der lokalen Datenbank 117 gespeichert, in der neben Geräteparametern und Daten zu Topologie des Systems insbesondere auch Daten zur Steuerungs- und Regelungsfunktionalität des Feldbussystems abgelegt werden.
Die Planungsanwendung 116 ist beispielsweise eine Planungsanwendung zur Visualisierung eines Feldbussystems oder von Abläufen im Feldbussystem. Die Planungsanwendung 116 stellt eine grafische Oberfläche zur Verfügung, mit der sowohl die Abläufe im System als auch der Status des Systems grafisch veranschaulicht werden. Die von der Planungsanwendung 116 benötigten Projektdaten, insbesondere Geräteparameter, Topologiedaten zur Topologie des Feldbussystems sowie Daten zur Steuerungs- und/oder Regelungsfunktionalität, sind in der zugehörigen lokalen Datenbank 118 gespeichert.
Bei der Planungsanwendung 119 kann es sich beispielsweise um eine Planungsanwendung zur Diagnose eines Feldbussystems handeln. Die Planungsanwendung 119 ist insbesondere dazu ausgelegt, die aktuellen Betriebsparameter der verschiedenen Feldgeräte des Feldbussystems zu verfolgen und mit Sollbereichen zu vergleichen, um auf diese Weise festzustellen, ob die Feldgeräte funktionsgemäß arbeiten. Bei der Festlegung der Sollbereiche kann beispielsweise auch die Steuerungs- und/oder Regelungsstrategie innerhalb des Feldbussystem mit berücksichtigt werden. Die von der Planungsanwendung 119 benötigten Projektdaten sind in der zugehörigen lokalen Datenbank 120 gespeichert, welche daher insbesondere Geräteparameter, Daten zu Funktionsblocks der Feldgeräte, Topologiedaten, Daten zu Bereichsgrenzen oder zu Alarmgrenzen, sowie Daten zur Steuerungs- und/oder Regelungsfunktionalität enthält.
In 2 ist eine schematische Darstellung der Topologie eines Feldbussystems. gegeben. In dem gezeigten Beispiel sind an einen Feldbus 200 drei Feldgeräte 201, 202, 203 angeschlossen. Bei dem ersten Feldgerät 201 handelt es sich um ein Feldgerät zur magnetisch-induktiven Durchflussmessung, bei dem zweiten Feldgerät 202 handelt es sich um ein Feldgerät zur Coriolis-Durchflussmessung, und bei dem dritten Feldgerät 203 handelt es sich um ein Feldgerät zur Füllstandsmessung. Zu den beiden Feldgeräten 201 und 202 sind darüber hinaus auch die Funktionsblocks des jeweiligen Feldgeräts dargestellt. Das Feldgerät 201 umfasst einen Physical Block 204 („PHY”), ein Device Management 205 („DM”), einen Analog Input Block 206 („AI”), einen Transducer Block 207 („TRD”) sowie zwei Totalizer-Blocks 208, 209 („TOT”). Das Feldgerät 202 umfasst einen Physical Block 210 („PHY”), ein Device Management 211 („DM”), zwei Analog Input Blocks 212, 213 („AI”) und einen Totalizer-Block 214 („TOT”). Die Bedeutung und Funktionalität dieser Funktionsblocks ist im Bereich der Prozessautomatisierungstechnik bekannt.
Topologiedaten der in 2 gezeigten Art werden insbesondere von der Planungsanwendung 115 zum Aufsetzen einer Steuerungs- oder Regelungsfunktionalität, von der Planungsanwendung 116 zur Visualisierung des Feldbussystems und von der Planungsanwendung 119 zur Diagnose des Feldbussystems benötigt, unter Umständen aber auch von den anderen Planungsanwendungen 111 und 112 genutzt.
Entsprechend der erfindungsgemäßen Lösung ist auf jedem Rechner 107, 108, 109, der zur Bearbeitung des Prozessautomatisierungsprojekts genutzt wird und auf dem entsprechende Planungsanwendungen installiert sind, mindestens ein Servicemodul 121, 122, 123 vorgesehen, das für den Austausch von Projektdaten mit den anderen an das Netzwerk 110 angeschlossenen Rechnern zuständig ist.
Bisher konnten die einzelnen Planungsanwendungen lediglich auf die Projektdaten in ihrer eigenen lokalen Datenbank zugreifen. Beispielsweise konnte die Planungsanwendung 111 nur auf die in ihrer lokalen Datenbank 113 gespeicherten Projektdaten zugreifen. Daher mussten die benötigten Projektdaten für jede Planungsanwendung jeweils separat eingegeben werden, was häufig dazu führte, dass bestimmte Daten, beispielsweise zu Gerätetyp, Hardwareversion und Softwareversion eines Feldgeräts sowie zur Topologie des Feldbussystems, mehrfach eingegeben werden mussten.
Mit Hilfe der erfindungsgemäßen Servicemodule wird es jeder Planungsanwendung ermöglicht, Projektdaten zu übernehmen, die in den lokalen Datenbanken von anderen Planungsanwendungen gespeichert sind. Die dort gespeicherten Datenbestände können ganz oder teilweise in die eigene lokale Datenbank übernommen werden.
Beispielsweise kann die Planungsanwendung 111 weiterhin auf ihre lokale Datenbank 113 zugreifen. Zusätzlich kann die Planungsanwendung 111 aber über das Servicemodul 121 Projektdaten übernehmen, die in der lokalen Datenbank 114 der Planungsanwendung 112 gespeichert sind. Außerdem kann die Planungsanwendung 111 über das Servicemodul 121, das Netzwerk 110 und das Servicemodul 122 Projektdaten der lokalen Datenbank 117 übernehmen, die der Planungsanwendung 115 zugeordnet ist. Dadurch wird eine Übernahme von Projektdaten aus einer Planungsanwendung in eine andere Planungsanwendung und ein Austausch von Projektdaten zwischen verschiedenen Planungsanwendungen ermöglicht, und zwar auch dann, wenn die verschiedenen Planungsanwendungen von verschiedenen Herstellern stammen.
Dabei werden die verschiedenen zu einem Projekt gehörigen Projektdaten vorzugsweise mit einer Projektkennung abgespeichert, die eine einfache und eineindeutige Zuordnung der Projektdaten eines Projekts zueinander ermöglicht.
Die Möglichkeit, Projektdaten von anderen Planungsanwendungen zu übernehmen, führt in vielen Fällen zu einer Arbeitserleichterung, weil Projektdaten wie beispielsweise Geräteparameter oder Topologiedaten nicht mehrmals in verschiedene Planungsanwendungen eingegeben werden müssen. Statt die Projektdaten mehrfach einzugeben, können die Projektdaten mit Hilfe der erfindungsgemäßen Servicemodule von einer anderen Planungsanwendung übernommen werden. Dadurch wird insbesondere bei komplexeren Automatisierungsprojekten die Arbeitsproduktivität verbessert.
Darüber hinaus führte die bisher erforderliche Mehrfacheingabe von Projektdaten auch zu Fehlern und Inkonsistenzen. In einer ersten Planungsanwendung wird beispielsweise versehentlich eine andere Hardwareversion eines Feldgeräts angegeben als in einer zweiten Planungsanwendung. Infolge derartiger Fehler kommt es dann zu Unverträglichkeiten und Fehlern bei der Zusammenarbeit der beiden Planungsanwendungen.
Derartige Fehler und Inkonsistenzen können durch Einsatz der erfindungsgemäßen Servicemodule vermieden werden. Infolge des Datenaustauschs zwischen verschiedenen Planungsanwendungen erhält man einen konsistenten Bestand an Projektdaten, der dann von allen Planungsanwendungen genutzt werden kann.
Ein weiterer Vorteil ist, dass der Austausch von Projektdaten zwischen verschiedenen Planungsanwendungen mit Hilfe der erfindungsgemäßen Servicemodule auf wohldefinierte und nachvollziehbare Art und Weise erfolgt. Es gibt jeweils einen durch eine Zeitmarke, also durch Datum und Uhrzeit, gekennzeichneten Stand der Projektdaten. Dadurch können auch im Nachhinein die verschiedenen Veränderungen der Projektdaten nachvollzogen werden, und es wird ein besserer Schutz vor Datenverlust erzielt.
Indem die Möglichkeit geschaffen wird, Projektdaten aus einer ersten Planungsanwendung ganz oder teilweise in eine zweite Planungsumgebung zu übernehmen, werden die heterogenen Planungstools zu einer integrierten Planungsumgebung für Projekte der Prozessautomatisierungstechnik zusammengeführt. Über die Servicemodule sind die Planungsanwendungen miteinander gekoppelt und können Projektdaten austauschen. Mit Hilfe der Servicemodule wird ohne Zutun des Benutzers eine Vernetzung der Planungsanwendungen erzielt, wobei sich die Planungsanwendungen selbst organisieren.
Im folgenden wird anhand des in 1 gezeigten Beispiels weiter dargestellt, wie die Möglichkeit zur Übernahme von Projektdaten aus einer anderen Planungsanwendung beim Aufsetzen eines Projekts der Automatisierungstechnik genutzt werden kann.
Bei der Programmierung eines Feldbussystems werden beispielsweise zuerst mittels der Planungsanwendung 111 Geräteparameter der verwendeten Feldgeräte festgelegt. Sobald dies geschehen ist, kann mittels der Planungsanwendung 115 eine geeignete Steuerungs- oder Regelungsfunktionalität für das Feldbussystem aufgesetzt werden. Dabei kann die Planungsanwendung 115 über die Servicemodule 122 und 121 auf Projektdaten in der lokale Datenbank 113 der Planungsanwendung 111 zugreifen. Insbesondere kann die Planungsanwendung 115 Daten zu Gerätetyp, Hardwareversion, Softwareversion, Geräteparameter, Angaben zu Bereichsgrenzen Funktionsblöcken etc. der verwendeten Feldgeräte aus der lokalen Datenbank 113 übernehmen. Anschließend kann der Benutzer die Steuerungs- und/oder Regelungsfunktionalität für das Feldbussystem festlegen, beispielsweise durch Definition geeigneter PID(Proportional, Integral, Differential)-Parameter.
Sobald der Benutzer die Steuerungs- und/oder Regelungsfunktionalität für das Feldbussystem definiert hat und die entsprechenden Parameter in der lokalen Datenbank 117 gespeichert sind, kann die Inbetriebnahme des Feldbussystems erfolgen. Während des Betriebs des Feldbussystems kann die Planungsumgebung 111 zum Überwachen der Geräteparameter der Feldgeräte und somit zum Überwachen der Funktion der Feldgeräte genutzt werden. Dabei kann die Planungsanwendung 111 die Projektdaten zur Steuerungs- und Regelungsfunktionalität des Feldbussystems mit Hilfe der Servicemodule 121 und 122 aus der lokalen Datenbank 117 übernehmen.
Darüber hinaus umfasst das in 1 gezeigte Computersystem die Planungsanwendungen 112, 116, 119 mit den jeweils zugeordneten lokalen Datenbanken 114, 118, 120. Auch die Planungsanwendungen 112, 116, 119 können Daten zu Gerätetyp, Hardwareversion, Softwareversion, Geräteparameter, Angaben zu Bereichsgrenzen Funktionsblöcken etc. der verwendeten Feldgeräte aus der lokalen Datenbank 113 der Planungsanwendung 111 übernehmen und in ihren lokalen Datenbanken 114, 118, 120 speichern.
In 3 ist eine alternative Ausführungsform der Erfindung gezeigt. Auf einem Rechner 300 sind eine Planungsanwendung 301 und eine Planungsanwendung 302 installiert, wobei der Planungsanwendung 301 eine lokale Datenbank 303 zugeordnet ist, und wobei der Planungsanwendung 302 eine lokale Datenbank 304 zugeordnet ist. Außerdem umfasst das Computersystem einen weiteren Rechner 305 mit einer Planungsanwendung 306 und einer lokalen Datenbank 307. Der Rechner 300 und der Rechner 305 sind über ein Netzwerk 308 miteinander verbunden.
Im Unterschied zu der in 1 gezeigten Ausführungsform ist in 3 jeder der Planungsanwendungen 301, 302, 306 ein eigenes Servicemodul zugeordnet. Der Planungsanwendung 301 ist das Servicemodul 309 zugeordnet, der Planungsanwendung 302 ist das Servicemodul 310 zugeordnet, und der Planungsanwendung 306 ist das Servicemodul 311 zugeordnet. Daher erfolgt bei dieser Ausführungsform der Austausch von Projektdaten auch zwischen den lokalen Datenbanken 303 und 304 auf dem Rechner 300 über die Servicemodule 309 und 310.
In den 4A bis 4C ist dargestellt, wie in einer Anwendung A Projektdaten bearbeitet und verändert werden und die veränderten Projektdaten dann von einer Anwendung B in eine lokale Datenbank B übernommen werden. Bei dem in den 4A bis 4C gezeigten Beispiel ist die Anwendung A zusammen mit der zugehörigen lokalen Datenbank A auf einem ersten Rechner 400 installiert, während die Anwendung B zusammen mit der lokalen Datenbank B auf einem zweiten Rechner 401 installiert ist. Der erste Rechner 400 und der zweite Rechner 401 sind über ein Netzwerk 402 miteinander verbunden.
In 4A ist gezeigt, wie in einem Schritt 403 der erste Rechner 400 durch den Benutzer A hochgefahren wird. Dabei wird automatisch das für den Datenaustausch zwischen verschiedenen Rechnern zuständige Servicemodul A gestartet. Das Servicemodul A schickt in regelmäßigen Zeitabständen an sämtliche an einem Projekt beteiligten Rechner eine Anfrage, ob der jeweilige Rechner aktiv ist oder nicht. Eine derartige Anfrage „Probe Service Request” wird im Schritt 404 vom Servicemodul A auch an den zweiten Rechner 401 geschickt. Da der Rechner 401 jedoch ausgeschaltet ist, bleibt diese Anfrage unbeantwortet.
Im Schritt 405 startet der Benutzer A die Anwendung A, beispielsweise die Anwendung „FieldCare”, und beginnt an einem Automatisierungsprojekt mit Projektkennung X zu arbeiten. Die Anwendung A sendet daraufhin im Schritt 406 einen Befehl „Register (Anwendungskennung, Projektkennung, Datenbank-Link)” an das Servicemodul A. Mit diesem Befehl wird dem Servicemodul A mitgeteilt, dass die Anwendung A aktiv ist, dass der Benutzer A an dem Projekt mit Projektkennung X arbeitet, und dass Datenbank A die zugehörige lokale Datenbank ist. Diese Informationen werden vom Servicemodul A im Schritt 407 „Store Active Project Information” gespeichert.
Während der Arbeit an dem Projekt mit Projektkennung X werden vom Benutzer A Projektdaten erstellt bzw. verändert. Diese Veränderung der Projektdaten ist in 4A als Schritt 408 eingezeichnet. Die Anwendung A aktualisiert daraufhin im Schritt 409 die zugehörige lokale Datenbank A und sendet im Schritt 410 eine entsprechende Nachricht „Project Change (Anwendungskennung, Projektkennung, Datenbank-Link)” an das Servicemodul A. Mit dieser Nachricht wird dem Servicemodul A mitgeteilt, dass es von Seiten der Anwendung A zu einer Veränderung der Projektdaten des Projekts mit Projektkennung X gekommen ist, wobei die veränderten Projektdaten in der lokalen Datenbank A gespeichert sind. Die Information über die veränderten Projektdaten wird vom Servicemodul A im Schritt 411 „Store Active Project Information” gespeichert. Der Benutzer A beendet seine Arbeit an dem Projekt mit Projektkennung X und schließt im Schritt 412 die Anwendung A.
Der weitere Ablauf des Verfahrens ist in 4B dargestellt. Im Schritt 413 wird der zweite Rechner 401 hochgefahren. Dabei wird automatisch auf dem zweiten Rechner 401 das Servicemodul B gestartet. Die in Schritt 414 vom Servicemodul A über das Netzwerk 402 an den zweiten Rechner 401 gesendete Anfrage „Probe Service Request” geht daher erstmals nicht ins Leere, sondern erreicht das Servicemodul B. Das Servicemodul B schickt daraufhin im Schritt 415 eine Antwort „Probe Service Response” an das Servicemodul A. Dadurch erfährt das Servicemodul A, dass der zweite Rechner 401 eingeschaltet ist, und übermittelt im Schritt 416 einen Befehl „Project Update Request (Anwendungskennung, Projektkennung)” an das Servicemodul B. Mit diesem Befehl wird dem Servicemodul B mitgeteilt, dass zu dem Projekt mit Projektkennung X von Seiten der Anwendung A veränderte Projektdaten vorliegen. Diese Information wird im Schritt 417 „Store Active Project Information” auf Seiten des Servicemoduls B gespeichert.
Um die veränderten Projektdaten vom ersten Rechner 400 zu erhalten, übermittelt das Servicemodul B im Schritt 418 einen entsprechenden Befehl „Read Database Request (Anwendungskennung, Projektkennung)” an das Servicemodul A des ersten Rechners 400. Das Servicemodul A greift daraufhin im Schritt 419 mit Hilfe des Befehls „Read Local Database (Anwendungskennung, Projektkennung)” auf die lokale Datenbank A zu und liest die von der Anwendung A geänderten Projektdaten aus der Datenbank A aus. Mit der Antwort „Read Database Response (Data)” werden die ausgelesenen Daten im Schritt 420 vom Servicemodul A zum Servicemodul B übermittelt, wobei das Servicemodul B die geänderten Daten im Schritt 421 „Temp Store Changed Project Data” als temporäre Datei abspeichert.
Im Schritt 422 schickt das Servicemodul A eine erneute Anfrage „Probe Service Request” an den zweiten Rechner 401. Da der zweite Rechner 401 eingeschaltet und das Servicemodul B aktiv ist, beantwortet das Servicemodul B diese Anfrage im Schritt 423 mit einer entsprechenden Antwort „Probe Service Response”. Auf diese Weise kann das Servicemodul A den aktuellen Systemstatus verfolgen.
Die weiteren Verfahrensschritte sind in 4C dargestellt. Der Benutzer B startet im Schritt 424 die Anwendung B auf dem zweiten Rechner 401 und bearbeitet mit der Anwendung B das Projekt mit Projektkennung X. Bei der Anwendung B könnte es sich beispielsweise um die Anwendung „ControlCare” handeln. Im Schritt 425 wird von der Anwendung B ein Befehl „Register (Anwendungskennung, Projektkennung, Datenbank-Link)” an das Servicemodul B übermittelt, um darüber zu informieren, dass die Anwendung B gestartet wurde, dass an dem Projekt mit Projektkennung X gearbeitet wird, und dass die Datenbank B als lokale Datenbank verwendet wird. Diese Informationen werden von dem Servicemodul B im Schritt 426 „Store Active Project Information” gespeichert.
Das Servicemodul B stellt nun durch Vergleich der Projektkennungen fest, dass zu dem Projekt mit Projektkennung X geänderte Projektdaten vorliegen, und informiert die Anwendung B darüber im Schritt 427 mit der Nachricht „Inform User About New Project Data”. Daraufhin zeigt die Anwendung B dem Benutzer B in Schritt 428 an, dass geänderte Projektdaten vorliegen. Der Benutzer B kann nun entscheiden, ob er die von der Anwendung A geänderten Projektdaten ganz oder teilweise übernehmen will oder nicht. Im dargestellten Beispiel entscheidet sich der Benutzer B für den Import der Daten und gibt im Schritt 429 einen entsprechenden Befehl „Import Data (Anwendungskennung, Projektkennung, Datensatzkennung, Datenbank-Link)” an die Anwendung B. Mit Hilfe der Datensatzkennung kann der Benutzer B spezifizieren, welche Teile der Daten er importieren will und welche nicht. Der Befehl „Import Data (Anwendungskennung, Projektkennung, Datensatzkennung, Datenbank-Link)” wird im Schritt 430 an das Servicemodul B übermittelt. Auf Seiten des Servicemoduls B sind die geänderten Projektdaten als temporäre Datei gespeichert. Die geänderten Projektdaten werden vom Servicemodul B entsprechend den mit dem Befehl „Import Data” gegebenen Anweisungen in die Datenbank B geschrieben. Dies geschieht im Schritt 431 „Update Database”. Die von der Anwendung A geänderten Projektdaten stehen jetzt auch für die Anwendung B zur weiteren Bearbeitung des Projekts mit der Projektkennung X zur Verfügung.
Der Benutzer B kann nun das Projekt mit Projektkennung X über die Anwendung B weiter bearbeiten. Im Rahmen dieser Bearbeitung werden durch den Benutzer B im Schritt 432 erneut Projektdaten geändert bzw. hinzugefügt. Im Schritt 433 „Update Database” wird die lokale Datenbank B durch die Anwendung B entsprechend aktualisiert. Außerdem übermittelt die Anwendung B im Schritt 434 eine Nachricht „Project Change (Anwendungskennung, Projektkennung, Datenbank-Link) an das Servicemodul B, um das Servicemodul B über die Veränderung der Projektdaten zu informieren. Diese Information über die Veränderung der Projektdaten wird vom Servicemodul B im Schritt 435 „Store Active Project Information” gespeichert. Darüber hinaus übermittelt das Servicemodul B im Schritt 436 einen Befehl „Project Update Request (Anwendungskennung, Projektkennung)” an das Servicemodul A auf dem ersten Rechner 400, um auch den ersten Rechner 400 darüber zu informieren, dass es durch die Anwendung B auf dem zweiten Rechner 401 zu einer Modifikation der Projektdaten zu dem Projekt mit Projektkennung X gekommen ist. Die von Seiten der Anwendung B geänderten Projektdaten können dann von der Anwendung A übernommen werden.

Claims

Ein Servicemodul (121) zur Ausführung auf einem Rechner (107), auf dem eine Planungsanwendung (111) zur Projektierung eines Feldbussystems sowie eine zugeordnete lokale Datenbank (113) mit Projektdaten zu einem Projekt installiert ist, dadurch gekennzeichnet, dass – das Servicemodul (121) dazu ausgelegt ist, Veränderungen der Projektdaten zu dem Projekt zu verfolgen und Projektdaten aus der lokalen Datenbank (113) bei Bedarf an andere an dem Projekt beteiligte Rechner (108, 109) zu übermitteln, und – das Servicemodul (121) dazu ausgelegt ist, von anderen an dem Projekt beteiligten Rechnern (108, 109) Benachrichtigungen über Veränderungen der Projektdaten zu dem Projekt zu empfangen und Projektdaten von anderen an dem Projekt beteiligten Rechnern (108, 109) entsprechend von Anweisungen eines Benutzers ganz oder teilweise in die lokale Datenbank (113) zu übernehmen.
Servicemodul nach Anspruch 1, dadurch gekennzeichnet, dass das Servicemodul dazu ausgelegt ist, andere an dem Projekt beteiligte Rechner über Veränderungen der Projektdaten zu benachrichtigen.
Servicemodul nach Anspruch 1 oder Anspruch 2, dadurch gekennzeichnet, dass das Servicemodul dazu ausgelegt ist, auf eine Benachrichtigung von einem anderen Rechner hin Projektdaten von dem anderen Rechner anzufordern.
Servicemodul nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Servicemodul dazu ausgelegt ist, von einem anderen Rechner empfangene Projektdaten zunächst als temporäre Datei zu speichern und dann entsprechend von Anweisungen des Benutzers ganz oder teilweise in die lokale Datenbank zu übernehmen.
Servicemodul nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass neue oder veränderte Projektdaten zusammen mit einer Projektkennung gespeichert werden.
Ein Computersystem mit – einer ersten Planungsanwendung (111) zur Projektierung eines Feldbussystems, einer der ersten Planungsanwendung (111) zugeordneten ersten lokalen Datenbank (113), in der erste Projektdaten zu einem Projekt gespeichert sind, und einem ersten Servicemodul (121), wobei die erste Planungsanwendung (111), die erste lokale Datenbank (113) und das erste Servicemodul (121) auf einem ersten Rechner (107) installiert sind, – einer zweiten Planungsanwendung (115) zur Projektierung des Feldbussystems, einer der zweiten Planungsanwendung (115) zugeordneten zweiten lokalen Datenbank (117), in der zweite Projektdaten zu dem Projekt gespeichert sind, und einem zweiten Servicemodul (122), wobei die zweite Planungsanwendung (115), die zweite lokale Datenbank (117) und das zweite Servicemodul (122) auf dem ersten Rechner (107) oder auf einem mit dem ersten Rechner (107) über ein Netzwerk (110) verbundenen zweiten Rechner (108) installiert sind, gekennzeichnet durch – ein erstes Servicemodul (121), das auf dem ersten Rechner (107) installiert ist, – ein zweites Servicemodul (122), das auf dem Rechner installiert ist, auf dem die zweite Planungsanwendung (115) und die zweite lokale Datenbank (117) installiert sind; – wobei das erste Servicemodul (121) dazu ausgelegt ist, Veränderungen der ersten Projektdaten zu verfolgen und erste Projektdaten aus der ersten lokalen Datenbank (113) bei Bedarf zum zweiten Servicemodul (122) zu übermitteln, und – wobei das zweite Servicemodul (122) dazu ausgelegt ist, erste Projektdaten vom ersten Servicemodul (121) entsprechend von Anweisungen eines Benutzers ganz oder teilweise in die zweite lokale Datenbank (117) zu übernehmen.
Computersystem nach Anspruch 6, dadurch gekennzeichnet, dass das erste Servicemodul dazu ausgelegt ist, das zweite Servicemodul über Veränderungen der ersten Projektdaten zu benachrichtigen.
Computersystem nach Anspruch 6 oder Anspruch 7, dadurch gekennzeichnet, dass das zweite Servicemodul dazu ausgelegt ist, auf eine Benachrichtigung von dem ersten Servicemodul hin erste Projektdaten von dem ersten Servicemodul anzufordern.
Computersystem nach einem der Ansprüche 6 bis 8, dadurch gekennzeichnet, dass das zweite Servicemodul dazu ausgelegt ist, von dem ersten Servicemodul empfangene Projektdaten zunächst als temporäre Datei zu speichern und dann entsprechend von Anweisungen des Benutzers ganz oder teilweise in die zweite lokale Datenbank zu übernehmen.
Computersystem nach einem der Ansprüche 6 bis 9, gekennzeichnet durch eines oder mehrere der folgenden Merkmale: – die Benachrichtigung über eine Veränderung der ersten Projektdaten wird vom ersten Servicemodul an alle an dem Projekt beteiligten Rechner geschickt; – neue oder veränderte Projektdaten werden zusammen mit einer Projektkennung gespeichert; – neue oder veränderte Projektdaten werden zusammen mit einer Projektkennung gespeichert, und das zweite Servicemodul ist dazu ausgelegt, eine Projektkennung von empfangenen Projektdaten mit einer Projektkennung eines aktiven Projekts der zweiten Planungsanwendung zu vergleichen; – die Projektdaten sind jeweils einem Feldbussystem oder einem Feldbussegment zugeordnet; – das erste Servicemodul ist dazu ausgelegt, Veränderungen der ersten Projektdaten jeweils zusammen mit einer Zeitmarke abzuspeichern.
Computersystem nach einem der Ansprüche 6 bis 10, dadurch gekennzeichnet, dass es sich bei der ersten Planungsanwendung um eine Planungsanwendung zum Festlegen und Verfolgen von Parametern von Feldgeräten handelt, dass es sich bei der zweiten Planungsanwendung um eine Planungsanwendung zum Aufsetzen einer Steuerungs- oder Regelungsfunktionalität für das Feldbussystem handelt, und dass die Planungsanwendung zum Aufsetzen der Steuerungs- oder Regelungsfunktionalität für das Feldbussystem dazu ausgelegt ist, auf Anweisung des Benutzers Projektdaten aus der ersten lokalen Datenbank zu übernehmen.
Computersystem nach Anspruch 11, dadurch gekennzeichnet, dass die Planungsanwendung zum Aufsetzen der Steuerungs- oder Regelungsfunktionalität für das Feldbussystem dazu ausgelegt ist, aus der ersten lokalen Datenbank mindestens eines der folgenden zu übernehmen: Daten zum Gerätetyp eines Feldgeräts, Daten zur Hardwareversion eines Feldgeräts, Daten zur Softwareversion eines Feldgeräts, Daten zum Betriebsmodus eines Feldgeräts, Daten zu Funktionsblocks eines Feldgeräts, Geräteparameter eines Feldgeräts, Daten zu Bereichsgrenzen eines Geräteparameters, Daten zu Alarmgrenzen eines Geräteparameters, Topologiedaten zur Topologie des Feldbussystem oder eines Feldbussegments.
Computersystem nach einem der Ansprüche 6 bis 10, dadurch gekennzeichnet, dass es sich bei der ersten Planungsanwendung um eine Planungsanwendung zum Aufsetzen einer Steuerungs- oder Regelungsfunktionalität für das Feldbussystem handelt, dass es sich bei der zweiten Planungsanwendung um eine Planungsanwendung zum Festlegen und Verfolgen von Parametern von Feldgeräten handelt, und dass die Planungsanwendung zum Festlegen und Verfolgen von Parametern von Feldgeräten dazu ausgelegt ist, auf Anweisung des Benutzers Daten zur Steuerungs- oder Regelungsfunktionalität des Feldbussystems Projektdaten aus der ersten lokalen Datenbank zu übernehmen.
Computersystem nach Anspruch 13, dadurch gekennzeichnet, dass die Planungsanwendung zum Festlegen und Verfolgen von Parametern von Feldgeräten eingesetzt wird zur Überwachung von Feldgeräten des Feldbussystems.
Computersystem nach einem der Ansprüche 6 bis 10, dadurch gekennzeichnet, dass es sich bei der zweiten Planungsanwendung um eine Planungsanwendung für ein Ressourcen- und Lieferungsmanagement zu dem Projekt handelt, und dass die Planungsanwendung für das Ressourcen- und Lieferungsmanagement zu dem Projekt dazu ausgelegt ist, auf Anweisung des Benutzers Projektdaten aus der ersten lokalen Datenbank zu übernehmen.
Computersystem nach einem der Ansprüche 6 bis 10, dadurch gekennzeichnet, dass es sich bei der zweiten Planungsanwendung um eine Planungsanwendung zur Diagnose des Feldbussystems handelt, und dass die Planungsanwendung zur Diagnose des Feldbussystems dazu ausgelegt ist, auf Anweisung des Benutzers Projektdaten aus der ersten lokalen Datenbank zu übernehmen.
Computersystem nach einem der Ansprüche 6 bis 10, dadurch gekennzeichnet, dass es sich bei der zweiten Planungsanwendung um eine Planungsanwendung zur Visualisierung des Feldbussystems oder von Abläufen im Feldbussystem handelt, und dass die Planungsanwendung zur Visualisierung des Feldbussystems oder von Abläufen im Feldbussystem dazu ausgelegt ist, auf Anweisung des Benutzers Projektdaten aus der ersten lokalen Datenbank zu übernehmen.
Computersystem nach einem der Ansprüche 6 bis 17, dadurch gekennzeichnet, dass die aus der ersten lokalen Datenbank übernommenen Projektdaten mindestens eines von folgenden umfassen: Daten zum Gerätetyp eines Feldgeräts, Daten zu Hardwareversion eines Feldgeräts, Daten zu Softwareversion eines Feldgeräts, Daten zum Betriebsmodus eines Feldgeräts, Daten zu Funktionsblocks eines Feldgeräts, Geräteparameter eines Feldgeräts, Daten zu Bereichsgrenzen eines Geräteparameters, Daten zu Alarmgrenzen eines Geräteparameters, Diagnosedaten eines Feldgeräts, Topologiedaten zur Topologie des Feldbussystem oder eines Feldbussegments, Daten zur Steuerungs- oder Regelungsfunktionalität des Feldbussystems.
Verfahren zur Übernahme von Projektdaten in einem Computersystem mit – einer ersten Planungsanwendung (111) zur Projektierung eines Feldbussystems, einer der ersten Planungsanwendung (111) zugeordneten ersten lokalen Datenbank (113), in der erste Projektdaten zu einem Projekt gespeichert sind, und einem ersten Servicemodul (121), wobei die erste Planungsanwendung (111), die erste lokale Datenbank (113) und das erste Servicemodul (121) auf einem ersten Rechner (107) installiert sind, – einer zweiten Planungsanwendung (115) zur Projektierung des Feldbussystems, einer der zweiten Planungsanwendung (115) zugeordneten zweiten lokalen Datenbank (117), in der zweite Projektdaten zu dem Projekt gespeichert sind, und einem zweiten Servicemodul (122), wobei die zweite Planungsanwendung (115), die zweite lokale Datenbank (117) und das zweite Servicemodul (122) auf dem ersten Rechner (107) oder auf einem mit dem ersten Rechner (107) über ein Netzwerk (110) verbundenen zweiten Rechner (108) installiert sind, wobei das Verfahren aufweist: – Verfolgen von Veränderungen der ersten Projektdaten in der ersten lokalen Datenbank (113) durch das erste Servicemodul (121); – Benachrichtigen des zweiten Servicemoduls (122) auf dem zweiten Rechner (108) darüber, dass Veränderungen der ersten Projektdaten vorliegen; – Übermitteln von Projektdaten bei Bedarf vom ersten Servicemodul (121) zum zweiten Servicemodul (122); – Übernehmen der übermittelten Projektdaten ganz oder teilweise entsprechend von Anweisungen eines Benutzers in die zweite lokale Datenbank (117).
Verfahren nach Anspruch 19, gekennzeichnet durch folgenden weiteren Schritt: Abspeichern der übermittelten Projektdaten in einer temporären Datei, und Übernehmen der Projektdaten ganz oder teilweise entsprechend von Anweisungen eines Benutzers in die zweite lokale Datenbank.