-
Die Erfindung betrifft ein Feldgerät gemäß dem Oberbegriff des Anspruchs 1 sowie ein Feldbussystem gemäß Anspruch 10. Des weiteren betrifft die Erfindung ein Verfahren zur Überwachung einer Änderungshistorie eines Feldgeräts gemäß dem Oberbegriff des Anspruchs 12.
-
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.
-
In der Prozessautomatisierungstechnik können Störungen des Prozessablaufs zu fehlerhaften Erzeugnissen führen. Insbesondere in Bereichen wie beispielsweise der Lebensmittelverarbeitung oder im Pharmabereich können die Auswirkungen gravierend sein. Insofern ist es wichtig, dass die Prozessautomatisierungstechnik definiert und nachvollziehbar arbeitet und dass die Abläufe während des Herstellungsprozesses auch nachträglich nachzuvollziehen sind.
-
Aufgabe der Erfindung ist es, die Überwachung von Konfigurations- oder Zustandsänderungen in einem Feldbussystem zu vereinfachen.
-
Gelöst wird diese Aufgabe durch die in den Ansprüchen 1, 10 und 12 angegebenen Merkmale.
-
Vorteilhafte Weiterentwicklungen der Erfindung sind in den Unteransprüchen angegeben.
-
Ein erfindungsgemäßes Feldgerät zum Anschluss an einen Feldbus ist dazu ausgelegt, über den Feldbus Daten mit einem Hostrechner auszutauschen. Das Feldgerät umfasst ein Änderungshistorie-Erfassungsmodul, welches dazu ausgelegt ist, vorher festgelegte Konfigurations- oder Zustandsänderungen des Feldgeräts zu erfassen und als Änderungshistorie-Daten in einem Änderungshistorie-Speicher abzuspeichern. Das Feldgerät umfasst den Änderungshistorie-Speicher, welcher dazu ausgelegt ist, die Änderungshistorie-Daten zu den vom Änderungshistorie-Erfassungsmodul erfassten Konfigurations- oder Zustandsänderungen des Feldgeräts zu speichern.
-
Das erfindungsgemäße Feldgerät ermöglicht eine Aufzeichnung der Änderungshistorie durch das Feldgerät selbst. Durch Überprüfen der aufgezeichneten Änderungshistorie kann nachträglich überprüft werden, ob vorgegebene Standards beim Herstellungsprozess, wie sie beispielsweise im Lebensmittel- und Pharmabereich festgelegt sind, eingehalten wurden. Auf diese Weise kann beispielsweise beurteilt werden, ob eine bestimmte Charge eines produzierten Produkts eine vertrauenswürdige Qualität besitzt oder nicht.
-
Bei den bisherigen Verfahren zur Dokumentation der Änderungshistorie wurden die Änderungen nur auf Seiten des Hostrechners aufgezeichnet. Dies hatte den Nachteil, dass nur diejenigen Änderungen in der Änderungshistorie aufgezeichnet wurden, die über den Feldbus zu den Feldgeräten übermittelt wurden. Bei den bisherigen Verfahren war es nicht möglich, Änderungen der Hardware-Konfiguration oder Software-Aktualisierungen automatisch zu erfassen, weil diese Änderungen direkt am Feldgerät vorgenommen wurden und auf Seiten des Hostrechners unter Umständen nicht bekannt waren. Um eine vollständige Änderungshistorie zu erhalten, mussten derartigen Änderungen bisher manuell vom Bedienpersonal eingegeben werden, was störanfällig und zeitintensiv war. Konfigurations- oder Parameteränderungen, die unmittelbar am Feldgerät eingegeben wurden, etwa über die Serviceschnittstelle oder die Vor-Ort-Schnittstelle des Feldgeräts, konnten mit den bisher verwendeten Verfahren nicht erfasst werden.
-
Bei der erfindungsgemäßen Lösung dagegen wird die Änderungshistorie für jedes Feldgerät auf Seiten des Feldgeräts selbst erfasst. Dies bietet eine Reihe von Vorteilen. Zum einen können zusätzlich zu den Änderungen, die über den Feldbus vorgenommen werden, auch solche Änderungen erfasst werden, die unmittelbar am Feldgerät selbst vorgenommen werden, also beispielsweise über die Serviceschnittstelle oder die Vor-Ort-Schnittstelle des Feldgeräts. Darüber hinaus können auf Seiten des Feldgeräts auch Änderungen der Hardware-Konfiguration und/oder der Softwarekonfiguration erfasst und gespeichert werden, beispielsweise ein Austausch eines Hardwaremoduls, ein neu hinzugefügtes Hardwaremodul oder eine vollständige oder teilweise Softwareaktualisierung. Außerdem kann auf Seiten des Feldgeräts das Auftreten von vorbestimmten Ereignissen (beispielsweise wenn die Temperatur des Mediums einen vorgegebenen Grenzwert überschreitet) erkannt und dokumentiert werden. Ein weiterer Vorteil ist, dass diese Änderungen und Ereignisse vom Änderungshistorie-Erfassungsmodul auf Seiten des Feldgeräts automatisiert erfasst und dokumentiert werden können. Durch die Verlagerung der Änderungshistorie-Erfassung weg vom Hostrechner und hin zu den einzelnen Feldgeräten kann daher eine umfassende Dokumentation der Änderungshistorie automatisch erstellt werden, ohne dass hierzu manuelle Eingaben des Bedienpersonals notwendig sind.
-
Die auf Seiten des jeweiligen Feldgeräts aufgezeichneten Änderungshistorie-Daten können vom Hostrechner abgefragt und ausgewertet werden.
-
Nachfolgend ist die Erfindung anhand von in der Zeichnung dargestellten Ausführungsbeispielen näher erläutert.
-
Es zeigen:
-
1 einen Überblick über ein erfindungsgemäßes Feldbussystem;
-
2 den Aufbau eines erfindungsgemäßen Feldgeräts;
-
3 ein Ablaufdiagramm, das die Erkennung neuer Hardware beim Hochstarten zeigt;
-
4 ein Ablaufdiagramm, das die Erkennung neuer Hardware in regelmäßigen zeitlichen Abständen zeigt;
-
5 ein Ablaufdiagramm, das die Erkennung neuer Software zeigt;
-
6 ein Ablaufdiagramm, das zeigt, wie Parameteränderungen erkannt und dokumentiert werden; und
-
7 ein Ablaufdiagramm, das zeigt, wie vorher festgelegte Ereignisse erkannt und abgespeichert werden.
-
In 1 ist ein erfindungsgemäßes Feldbussystem gezeigt, in dem Konfigurations- oder Zustandsänderungen auf Seiten der Feldgeräte in Form einer Änderungshistorie aufgezeichnet werden können. Das Feldbussystem umfasst einen Hostrechner 100, der über einen Feldbus 101 mit verschiedenen an den Feldbus 101 angeschlossenen Feldgeräten 102, 103 kommunizieren kann. Bei dem Feldbus 101 kann es sich beispielsweise um einen Feldbus entsprechend einem der etablierten Standards Fieldbus Foundation, Profibus, HART handeln. Alternativ kann es sich bei dem Feldbus 101 um einen Feldbus entsprechend den Industrial Ethernet Standards EtherNet/IP, Profinet, EtherCat, Modbus TCP, etc. handeln. Auf Seiten des Hostrechners 100 ist ein Geräteverwaltungswerkzeug 104 installiert, mit dem eine Parametrierung und Konfiguration der an den Feldbus 101 angeschlossenen Feldgeräte 102, 103 durchgeführt werden kann. Über das Geräteverwaltungswerkzeug 104 können die Parameter dieser Feldgeräte abgerufen und überwacht werden. Vorzugsweise handelt es sich bei dem Geräteverwaltungswerkzeug 104 um ein Geräteverwaltungswerkzeug gemäß dem Standard FDT (Field Device Tool), beispielsweise um das Programm „FieldCare” der Fa. Endress + Hauser. Um die einzelnen an dem Feldbus 101 angeschlossenen Feldgeräte dem Gerätetyp entsprechend ansprechen zu können, werden in das Geräteverwaltungswerkzeug 104 Treiberdateien 105 eingebunden, die den einzelnen Feldgeräten 102, 103 zugeordnet sind und die Eigenschaften dieser Feldgeräte spezifizieren. Bei den Treiberdateien 105 kann es sich beispielsweise um Treiberdateien gemäß dem Standard DTM (Device Type Manager) handeln.
-
Bei dem erfindungsgemäßen Feldbussystem ist auf Seiten der Feldgeräte 102, 103 jeweils eine History-Funktionalität implementiert, welche die Aufgabe hat, Konfigurations- oder Zustandsänderungen des Feldgerätes in Form einer Änderungshistorie chronologisch aufzuzeichnen. Zur Verwirklichung einer derartigen History-Funktionalität ist auf Seiten des Feldgeräts 102 eine History-Komponente 106 vorgesehen, welche eine Mehrzahl von vorher festgelegten Konfigurations- oder Zustandsänderungen erkennt und dokumentiert.
-
Bei den zu verfolgenden Konfigurations- oder Zustandsänderungen kann es sich beispielsweise um Änderungen der Werte von vorher festgelegten Parametern handeln, es kann sich aber auch um das Auftreten von vorher festgelegten Ereignissen handeln. Darüber hinaus können auch Änderungen der Hardware-Konfiguration, beispielsweise der Austausch oder das Hinzufügen von Hardwaremodulen, von der History-Komponente 106 erkannt werden. Auch Änderungen der Softwarekonfiguration, wie beispielsweise die vollständige oder teilweise Aktualisierung der Software, können von der History-Komponente 106 erkannt und dokumentiert werden. Außerdem ist es beispielsweise möglich, dass die History-Komponente 106 das Hochfahren und Herunterfahren des Feldgeräts 102 jeweils protokolliert.
-
Sämtliche von der History-Komponente 106 erkannten Konfigurations- oder Zustandsänderungen werden von der History-Komponente 106 in einen eigens hierfür vorgesehenen History-Speicher 107 geschrieben. Vorzugsweise wird zu jeder Konfigurations- oder Zustandsänderung, die von der History-Komponente 106 aufgezeichnet wird, eine Zeitmarke mit abgespeichert, die angibt, wann die jeweilige Änderung aufgetreten ist. Die Zeitmarken werden von einem Zeitgeber 108 zur Verfügung gestellt, der auf Seiten des Feldgeräts 102 vorgesehen ist. Gemäß einer bevorzugten Ausführungsform wird der Zeitgeber 108 bei jedem Hochstarten des Feldgeräts 102 auf Null gesetzt. Gemäß einer alternativen Ausführungsform ist der Zeitgeber 108 auch als Echtzeit-Zeitgeber implementiert und stellt Zeitmarken in Echtzeit zur Verfügung. Da die History-Komponente 106 jede zu protokollierende Konfigurations- oder Zustandsänderung des Feldgeräts 102 zusammen mit einer zugehörigen Zeitmarke im History-Speicher 107 abspeichert, baut sich im History-Speicher 107 eine chronologisch fortlaufende Änderungshistorie auf, die einen umfassenden Überblick über die auf Seiten des Feldgeräts 102 vorgefallenen Änderungen und Ereignisse ermöglicht. Dabei ist es von Vorteil, den History-Speicher 107 als eigenständige, von den Hardware-Modulen des Feldgeräts 102 unabhängige Speichereinheit auszubilden, welche vorzugsweise am Gehäuse oder am Sensor des Feldgeräts 102 fest angebracht ist. Dadurch wird verhindert, dass der History-Speicher 107 beim Austauschen eines Hardware-Moduls ebenfalls mit ausgetauscht wird. Indem der History-Speicher 107 als separate Speichereinheit realisiert ist, kann die Änderungshistorie des Feldgeräts 102 über längere Zeiträume hinweg unbeeinflusst von eventuellen Änderungen der Hardware-Konfiguration aufgezeichnet werden. Dadurch wird es insbesondere auch möglich, Änderungen der Hardware-Konfiguration und insbesondere den Austausch von Hardware-Modulen über längere Zeiträume hinweg in der Änderungshistorie zu dokumentieren.
-
Auf Seiten des Feldgeräts 103 ist ebenfalls eine History-Komponente 109 vorgesehen, die dazu ausgelegt ist, Konfigurations- oder Zustandsänderungen des Feldgeräts 103 zu erkennen. Die erkannten Konfigurations- oder Zustandsänderungen werden dann zusammen mit einer Zeitmarke, die von einem Zeitgeber 111 zur Verfügung gestellt wird, im History-Speicher 110 als Änderungshistorie abgespeichert.
-
Insofern ist in den History-Speichern 107, 110 jeweils die Änderungshistorie des jeweiligen Feldgeräts 102, 103 gespeichert. Der Hostrechner 100 kann über den Feldbus 101 auf die Feldgeräte 102, 103 zugreifen und die in den History-Speichern 107, 110 gespeicherten History-Daten auslesen. Auf Seiten des Hostrechners 100 können sämtliche von den verschiedenen Feldgeräten des Feldbussystems aufgezeichneten History-Daten zusammengeführt werden, um auf diese Weise eine Änderungshistorie des Gesamtsystems zu erhalten. Diese Änderungshistorie des Gesamtsystems kann dann weiter ausgewertet werden. Insbesondere kann überprüft werden, ob vorgegebene Standards beim Herstellungsprozess, wie sie beispielsweise im Lebensmittel- und Pharmabereich festgelegt sind, eingehalten wurden.
-
Industrielle Herstellungsprozesse für Pharmazeutika und Lebensmittel sind besonders sicherheitskritisch, weil Störungen des Prozessablaufs zu fehlerhaften Erzeugnissen und zu Gesundheitsgefahren für die Verbraucher führen können. Insofern ist es wichtig, dass die Prozessautomatisierungstechnik definiert und nachvollziebar arbeitet und dass die Abläufe während des Herstellungsprozesses auch nachträglich nachzuvollziehen sind. Um dies zu erreichen, gibt es eine Reihe von Industriestandards bzw. Regelwerken, welche Anforderungen an die Konfiguration und Arbeitsweise der Prozessautomatisierungstechnik definieren. Als Beispiele können die Standards FDA 21 CFR Part 11 sowie GAMP 5 (Good Automation Manufacturing Practise) angeführt werden.
-
Die vorliegende Erfindung bietet die Möglichkeit, systemübergreifend eine Änderungshistorie aufzuzeichnen und dann zu überprüfen, ob sich die an den einzelnen Feldgeräten vorgenommenen Konfigurations- oder Zustandsänderungen im Rahmen der vorgegebenen Regeln bewegen. Auf diese Weise kann beurteilt werden, ob eine bestimmte Charge eines produzierten Produkts eine vertrauenswürdige Qualität besitzt oder nicht.
-
Bei den bisherigen Verfahren zur Dokumentation der Änderungshistorie wurden die Änderungen nur auf Seiten des Hostrechners aufgezeichnet. Dies hatte den Nachteil, dass nur diejenigen Änderungen in der Änderungshistorie aufgezeichnet wurden, die über den Feldbus zu den Feldgeräten übermittelt wurden. Bei den bisherigen Verfahren war es nicht möglich, Änderungen der Hardware-Konfiguration oder Software-Aktualisierungen automatisch zu erfassen, weil diese Änderungen direkt am Feldgerät vorgenommen wurden und auf Seiten des Hostrechners unter Umständen nicht bekannt waren. Um eine vollständige Änderungshistorie zu erhalten, mussten derartigen Änderungen bisher manuell vom Bedienpersonal eingegeben werden, was störanfällig und zeitintensiv war. Konfigurations- oder Parameteränderungen, die unmittelbar am Feldgerät eingegeben wurden, etwa über die Serviceschnittstelle oder die Vor-Ort-Schnittstelle des Feldgeräts, konnten mit den bisher verwendeten Verfahren nicht erfasst werden.
-
Bei der erfindungsgemäßen Lösung dagegen wird die Änderungshistorie für jedes Feldgerät auf Seiten des Feldgeräts selbst erfasst. Dies bietet eine Reihe von Vorteilen. Zum einen können zusätzlich zu den Änderungen, die über den Feldbus vorgenommen werden, auch solche Änderungen erfasst werden, die unmittelbar am Feldgerät selbst vorgenommen werden, also beispielsweise über die Serviceschnittstelle oder die Vor-Ort-Schnittstelle des Feldgeräts. Darüber hinaus können auf Seiten des Feldgeräts auch Änderungen der Hardware-Konfiguration und/oder der Softwarekonfiguration erfasst und gespeichert werden, beispielsweise ein Austausch eines Hardwaremoduls, ein neu hinzugefügtes Hardwaremodul oder eine vollständige oder teilweise Softwareaktualisierung. Außerdem kann auf Seiten des Feldgeräts das Auftreten von vorbestimmten Ereignissen (beispielsweise wenn die Temperatur des Mediums einen vorgegebenen Grenzwert überschreitet) erkannt und dokumentiert werden. Darüber hinaus kann mit Hilfe der History-Komponente jeweils das Hoch- bzw. Herunterfahren des Feldgeräts dokumentiert werden. Ein weiterer Vorteil ist, dass diese Änderungen und Ereignisse von der History-Komponente auf Seiten des Feldgeräts automatisiert erfasst und dokumentiert werden können. Durch die Verlagerung der History-Funktionalität weg vom Hostrechner und hin zu den einzelnen Feldgeräten kann daher eine umfassende Dokumentation der Änderungshistorie automatisch erstellt werden, ohne dass hierzu manuelle Eingaben des Bedienpersonals notwendig sind.
-
Die auf Seiten des jeweiligen Feldgeräts aufgezeichneten History-Daten können vom Hostrechner abgefragt und ausgewertet werden. Hierzu ist vorzugsweise ein neuartiges DTM-Modul für das Geräteverwaltungswerkzeug vorgesehen, welches die Änderungshistorie des Feldgeräts abfragt und dem Benutzer eine Visualisierung der History-Daten bietet. Außerdem kann eine Druckfunktion zur Verfügung gestellt werden, welche notwendige Basis-Dokumente für die sicherheitstechnische Abnahme eines Herstellungsprozesses erzeugt und ausdruckt. Die ausgedruckten Dokumente werden dann unterzeichnet und abgelegt. Mit derartigen Abnahmedokumenten kann belegt werden, dass ein bestimmter Herstellungsprozess den vorgegebenen Standards entspricht. Derartige Abnahmedokumente werden insbesondere für Herstellungsprozesse im Lebensmittel- und Pharmabereich benötigt, können darüber hinaus aber auch allgemein im Qualitätsmanagement eingesetzt werden.
-
Wenn ein Benutzer Parameter eines Feldgeräts ändert, eine Konfigurationsänderung durchführt oder neue Software auf einem Feldgerät installiert, so ist das unter sicherheitstechnischen Aspekten als kritischer Vorgang zu werten, weil durch eine fehlerhafte Konfiguration eines Feldgeräts der gesamte Herstellungsprozess eines Lebensmittels oder eines Arzneimittels beeinträchtigt werden kann. Es kann daher sinnvoll sein, von einem Benutzer zu verlangen, dass er sich gegenüber dem System identifiziert, bevor er irgendwelche Änderungen am Feldbussystem vornimmt. Dabei ist es auch möglich, verschiedenen Benutzergruppen unterschiedliche Zugriffsrechte einzuräumen. Der Benutzer kann sich entweder gegenüber dem Hostrechner oder unmittelbar gegenüber dem Feldgerät legitimieren. Diese Legitimierung kann beispielsweise mittels einer elektronischen Signatur erfolgen, deren Integrität dann von dem jeweiligen Gerät geprüft wird. Dabei ist es von Vorteil, wenn die Signatur den gesetzlichen Vorgaben entspricht, die in Deutschland durch das Signaturgesetz Paragraph 2 Nr. 3 (entsprechend der EU-Richtlinie 1999/93/EG), in der Schweiz durch das Bundesgesetz über Zertifizierungsdienste im Bereich der elektronischen Signatur, und in Österreich über das Signaturgesetz (ÖSig Paragraph 2 Nr. 1 und ÖSig Paragraph 2 Nr. 3) festgelegt sind. Dabei werden drei verschiedene Stufen der elektronischen Signatur unterschieden, nämlich eine allgemeine elektronische Signatur, eine fortgeschrittene elektronische Signatur sowie eine qualifizierte elektronische Signatur. Zur Implementierung einer fortgeschrittenen elektronischen Signatur kann beispielsweise das Verschlüsselungsverfahren PGP („Pretty Good Privacy”) eingesetzt werden, das mit einem öffentlichen und einem geheimen Schlüssel arbeitet. PGP kann auf Seiten des Feldgeräts auf einfache Weise implementiert werden.
-
Nachdem sich der Benutzer gegenüber dem Feldbussystem identifiziert hat, ist er für das Feldbussystem als Initiator von Änderungen erkennbar. Wenn auf Seiten des Feldgeräts 102 beispielsweise eine Parameteränderung oder eine Softwareaktualisierung vorgenommen wird, kann die History-Komponente 106 erkennen, welcher Benutzer die Änderung vorgenommen hat. In diesen Fällen kann die History-Komponente 106 zusammen mit Informationen über die Parameteränderung oder die Softwareaktualisierung im History-Speicher 107 abspeichern, wer die jeweilige Änderung veranlasst hat. In diesem Fall umfasst die im History-Speicher 107 gespeicherte Änderungshistorie auch die Kennungen der Benutzer, die die jeweiligen Änderungen veranlasst haben.
-
2 gibt einen Überblick über die Komponenten eines erfindungsgemäßen Feldgeräts 200. Das Feldgerät 200 umfasst einen Prozessor 201, einen flüchtigen Speicher 202, beispielsweise ein RAM, einen nichtflüchtigen Speicher 203, beispielsweise ein EEPROM oder ein FRAM, sowie einen separaten History-Speicher 204 zum Speichern der History-Daten. Der History-Speicher 204 ist vorzugsweise am Gehäuse oder am Sensor des Feldgeräts 200 angebracht. Darüber hinaus umfasst das Feldgerät 200 einen Zeitgeber 205, der Zeitmarken für die Einträge im History-Speicher 204 zur Verfügung stellt. Im nichtflüchtigen Speicher 203 ist unter anderem eine Ladekomponente 206 gespeichert, die auch als „Bootloader” bezeichnet wird. Beim Hochfahren des Feldgeräts 200 ist die Ladekomponente 206 für das Starten der Applikationssoftware 207 zuständig. Darüber hinaus ist die Ladekomponente 206 dafür zuständig, auf eine entsprechende Anforderung hin mittels eines sogenannten „Flash-Update” eine vollständige oder teilweise Aktualisierung der Applikationssoftware 207 durchzuführen.
-
Bei dem erfindungsgemäßen Feldgerät 200 umfasst die Applikationssoftware 207 eine History-Komponente 208, die dazu ausgelegt ist, eine Vielzahl von vorher festgelegten Konfigurations- oder Zustandsänderungen zu erkennen und im History-Speicher 204 zu dokumentieren. Zu diesem Zweck umfasst die History-Komponente 208 eine Mehrzahl von verschiedenen Modulen. Bei der in 2 gezeigten Ausführungsform umfasst die History-Komponente 208 beispielsweise ein Anschalt-/Abschaltmodul 209, welches das Hochfahren und Herunterfahren des Feldgeräts 200 protokolliert, ein Eventmodul 210, welches das Auftreten von vorher festgelegten Ereignissen erkennt und dokumentiert, ein Softwareerkennungsmodul 211, welches die aktuelle Softwareversion abfragt, sowie ein Hardwareerkennungsmodul 212, welches die aktuelle Hardwareversion abfragt. Darüber hinaus umfasst die History-Komponente 208 ein Änderungsprüfmodul 213, welches die aktuelle Hardware- oder Softwareversion mit der bisherigen Hardware- oder Softwareversion vergleicht, um festzustellen, ob eine Änderung aufgetreten ist. Außerdem umfasst die History-Komponente 208 ein Speicherzugriffsmodul 214, welches die Zugriffe auf den History-Speicher 204 durchführt und die Konfigurations- oder Zustandsänderungen im History-Speicher 204 abspeichert.
-
Die Applikationssoftware 207 umfasst darüber hinaus eine Parameterverwaltung 215. Die Parameterverwaltung 215 überwacht beispielsweise, ob ein Benutzer zur Änderung eines Parameters berechtigt ist, ob Bereichsgrenzen eines Parameters eingehalten werden, wie die einzelnen Parameter miteinander verknüpft sind, in welchen Einheiten ein bestimmter Parameter angegeben werden soll etc. Die Parameterverwaltung 215 umfasst ein Modul 216 zur Parameteränderungsverfolgung, welches die Aufgabe hat, Änderungen von Parameterwerten zu identifizieren. Das Modul 216 zur Parameteränderungsverfolgung arbeitet eng mit der erfindungsgemäßen History-Komponente 208 zusammen, um Änderungen der Werte von bestimmten vorher festgelegten Parametern zu erkennen und zu dokumentieren.
-
Mit Hilfe des erfindungsgemäßen Feldgeräts 200 können eine oder mehrere der folgenden Konfigurations- oder Zustandsänderungen erkannt und aufgezeichnet werden: das Herauf- und Herunterfahren des Feldgeräts 200, das Auftreten von vorher festgelegten Ereignissen, Änderungen von vorher festgelegten Parametern, Änderungen der Softwareversion und Änderungen der Hardwareversion. Im Folgenden wird anhand der in den 3 bis 7 gezeigten Ablaufdiagramme beschrieben, wie die Erkennung und Protokollierung der einzelnen Konfigurations- oder Zustandsänderungen des Feldgeräts 200 bewerkstelligt wird.
-
In 3 ist der Ablauf beim Hochstarten des Feldgeräts 200 gezeigt, wobei beim Hochstarten eine Hardwareerkennung durchgeführt wird. Im ersten Schritt 300 wird die Applikationssoftware 207 durch die Ladekomponente 206 gestartet. Im darauffolgenden Schritt 301 wird der Systemstart durch das Anschalt-/Abschaltmodul 209 dokumentiert, indem ein entsprechender Eintrag zusammen mit einer Zeitmarke, die vom Zeitgeber 205 zur Verfügung gestellt wird, in den History-Speicher 204 geschrieben wird. Anschließend wird im Schritt 302 das Hardwareerkennungsmodul 212 aufgerufen. Im Schritt 303 ermittelt das Hardwareerkennungsmodul 212 den Typ, die Version und die Seriennummern der Hardwaremodule des Feldgeräts. Hierzu liest das Hardwareerkennungsmodul 212 einen festgelegten Speicherbereich der Hardwaremodule aus. Im nächsten Schritt 304 wird das Änderungsprüfmodul 213 aufgerufen, und die Informationen über Typ, Version und Seriennummern der Hardwaremodule werden dem Änderungsprüfmodul 213 übergeben. Das Änderungsprüfmodul 213 hat nun die Aufgabe, zu ermitteln, ob sich die Hardware des Feldgeräts geändert hat. Hierzu prüft das Änderungsprüfmodul 213 im Schritt 305, ob Typ, Version und Seriennummern der aktuellen Hardwaremodule, die im Schritt 303 ermittelt wurden, mit den gespeicherten Werten übereinstimmen. Falls Typ, Version und Seriennummer übereinstimmen, hat sich die Hardware nicht geändert. Entsprechend Schritt 306 muss in diesem Fall kein Eintrag in den History-Speicher 204 geschrieben werden. Falls dagegen die aktuellen Werte nicht mit den gespeicherten Werten übereinstimmen, dann hat sich die Hardware geändert, und es muss ein Eintrag in den History-Speicher 204 geschrieben werden. Zu diesem Zweck wird im Schritt 307 das Speicherzugriffsmodul 214 aufgerufen, dessen Aufgabe es ist, auf den History-Speicher 204 zuzugreifen. Im Schritt 308 wird ein die neue Hardware betreffender Eintrag in den History-Speicher 204 geschrieben, beispielsweise Typ, Version und Seriennummer der neuen Hardwaremodule, zusammen mit einer vom Zeitgeber 205 zur Verfügung gestellten Zeitmarke.
-
Derartige die Hardware-Konfiguration betreffende Einträge im History-Speicher 304 könnten beispielsweise folgendermaßen aussehen:
- – Modul M1 (Modul „Sensormodul/Vorverstärker”): Ausgangsmodul M1a, Modul M1b eingebaut (Zeitmarke des Einschaltens von M1b);
- – Modul M17 (Modul „Kommunikationsmodul”): Kommunikationsmodul M17a, Modul M17b eingebaut (Zeitmarke des Einschaltens von M17b).
-
Zusätzlich zu der beim Hochstarten durchgeführten Hardwareerkennung kann in regelmäßigen zeitlichen Abständen eine Hardwareerkennung durchgeführt werden. Diese periodisch durchgeführte Hardwareerkennung ist in 4 dargestellt. Entsprechend Schritt 400 ruft die Applikationssoftware 207 in regelmäßigen zeitlichen Abständen das Hardwareerkennungsmodul 212 auf. Beispielsweise kann das Hardwareerkennungsmodul 212 jeweils in Abständen von ca. 1 Minute aufgerufen werden. Im folgenden Schritt 401 ermittelt das Hardwareerkennungsmodul 212 den Typ, die Version sowie die Seriennummern der Hardwaremodule, indem jeweils ein festgelegter Speicherbereich der Hardwaremodule des Feldgeräts ausgelesen wird. Im Schritt 402 wird das Änderungsprüfmodul 213 aufgerufen, und die ausgelesenen Informationen über die Hardware werden an das Änderungsprüfmodul 213 übergeben. Im Schritt 403 überprüft das Änderungsprüfmodul 213, ob sich die Hardware des Feldgeräts geändert hat. Hierzu vergleicht das Änderungsprüfmodul 213 den aktuellen Typ, die Version und Seriennummern der Hardwaremodule mit den gespeicherten bisherigen Werten der Hardwaremodule. Falls die aktuellen Werte mit den bisherigen Werten übereinstimmen, hat sich die Hardware nicht geändert. Entsprechend Schritt 404 muss in diesem Fall kein Eintrag in den History-Speicher 204 geschrieben werden. Falls die aktuellen Werte dagegen von den bisherigen Werten abweichen, dann hat sich die Hardwarekonfiguration geändert, und dies wird im History-Speicher 204 protokolliert. Im Schritt 405 wird das Speicherzugriffsmodul 214 aufgerufen, welches den Zugriff auf den History-Speicher 204 durchführt. Im Schritt 406 wird ein entsprechender Eintrag in den History-Speicher 204 geschrieben, welcher insbesondere den Typ, die Version sowie die Seriennummer der neuen Hardwaremodule umfasst, zusammen mit einer vom Zeitgeber 305 zur Verfügung gestellten Zeitmarke.
-
Anhand von 5 soll im Folgenden dargestellt werden, wie die History-Komponente 208 Softwareaktualisierungen dokumentiert. Derartige Softwareaktualisierungen sind in der Regel mit einem „Flash-Update” des nicht-flüchtigen Speichers 203 verbunden. Im Schritt 500 befindet sich das Feldgerät 200 im Wartemodus. Im darauffolgenden Schritt 501 wird geprüft, ob eine Flash-Anforderung vorliegt. Wenn dies nicht der Fall ist, bleibt das System im Wartemodus (Schritt 500). Wenn dagegen eine Flash-Anforderung vorliegt, dann wird im darauffolgenden Schritt 502 geprüft, ob die aktuell angebotene Software zum Gerätetyp und zu den Hardwaremodulen des Feldgeräts 200 passt. Falls die Software nicht zur Hardware passt, wird entsprechend Schritt 503 der Flash-Update nicht durchgeführt. Falls die angebotene Software zur Hardware passt, geht das Feldgerät in Schritt 504 in den Flash-Updatemodus über. Im Schritt 505 empfängt das Feldgerät 200 über die Feldbusschnittstelle oder über die Serviceschnittstelle einen Strom von Datenpaketen, welche die neue Software enthalten. Die Ladekomponente 206 sorgt dafür, dass die empfangenen Daten im flüchtigen Speicher 202 abgelegt werden. Im darauffolgenden Schritt 506 wird das Softwareerkennungsmodul 211 aufgerufen. Das Softwareerkennungsmodul 211 ermittelt die Softwareversion der neuen Software anhand der Header der empfangenen Datenpakete. Im Schritt 507 wird das Änderungsprüfmodul 213 aufgerufen, wobei die vom Softwareerkennungsmodul 211 ermittelte Version der empfangenen Software an das Änderungsprüfmodul 213 übergeben wird. Im Schritt 508 prüft das Änderungsprüfmodul 213, ob die Version der soeben empfangenen Software mit der bisherigen Softwareversion übereinstimmt oder nicht. Falls die neue Softwareversion mit der bisherigen Softwareversion übereinstimmt, ist es entsprechend Schritt 509 nicht notwendig, einen Flash-Update des nicht-flüchtigen Speichers vorzunehmen. Entsprechend wird auch kein Eintrag in den History-Speicher 204 geschrieben. Falls sich dagegen die neue Softwareversion von der bisherigen Softwareversion unterscheidet, dann wird diese Änderung der Software im History-Speicher 204 dokumentiert. Hierzu wird im Schritt 510 das Speicherzugriffsmodul 214 aufgerufen, welches den Zugriff auf den History-Speicher 204 durchführt. Im Schritt 511 wird ein Eintrag zu der neuen Softwareversion in den History-Speicher 204 geschrieben, welcher insbesondere die Version der Software sowie eine vom Zeitgeber 205 zur Verfügung gestellte Zeitmarke umfasst. Darüber hinaus wird auch der Benutzer, der die Softwareaktualisierung initiiert hat, in dem betreffenden Eintrag im History-Speicher 204 vermerkt. Im Folgenden sind Beispiele von entsprechenden Einträgen im History-Speicher 204 aufgeführt:
- – Software S1 für Modul M1 (Modul „Sensormodul/Vorverstärker”): Ausgangssoftware S1a, Software S1b aufgespielt/Flash-Update (Zeitmarke für Einschalten S1b, Benutzer A);
- – Software S17 für Modell M17 (Modul „Kommunikationsmodul”): Ausgangssoftware S17a, Software S17b aufgespielt/Flash-Update (Zeitmarke für Einschalten S17b, Benutzer B).
-
Erst nachdem der entsprechende Eintrag im History-Speicher 204 angelegt ist, wird im darauffolgenden Schritt 512 das eigentliche Flash-Update durchgeführt. Dadurch ist sichergestellt, dass es auch dann einen Eintrag im History-Speicher 204 gibt, wenn es während des Flash-Updates zu Störungen kommt. Während des Flash-Updates wird die im flüchtigen Speicher 202 gespeicherte neue Software in den nicht-flüchtigen Speicher 203 kopiert und ersetzt dort die bisher verwendete Software.
-
In der Änderungshistorie des Feldgeräts 200 werden darüber hinaus auch Änderungen von Parametern dokumentiert. Dabei arbeitet die History-Komponente 208 eng mit der Parameterverwaltung 215 und dem Modul 216 zur Parameteränderungsverfolgung zusammen. In 6 ist dargestellt, wie eine Änderung eines Parameters erkannt und protokolliert wird.
-
Allgemein werden Parameter, wie in Schritt 600 gezeigt, durch die Parameterverwaltung 215 prozessiert. Im Schritt 601 erkennt das Modul 216 zur Parameteränderungsverfolgung eine Änderung eines zu dokumentierenden Parameters. Daraufhin wird im Schritt 602 das Speicherzugriffsmodul 214 der History-Komponente 208 aufgerufen. Im Schritt 603 greift das Speicherzugriffsmodul 214 auf den History-Speicher 204 zu und speichert einen Eintrag zu der Parameteränderung im History-Speicher 204. Dabei kann der Eintrag im History-Speicher 204 folgende Angaben umfassen: den neuen Parameterwert, eine Parameter-ID, d. h. eine Kennung, die den geänderten Parameter eindeutig identifiziert, sowie eine vom Zeitgeber 205 zur Verfügung gestellte Zeitmarke. Darüber hinaus kann in dem Eintrag auch gespeichert werden, welcher Benutzer die Parameteränderung veranlasst hat.
-
Im Folgenden sind beispielhaft einige Einträge zu Parameteränderungen angegeben, wie sie im History-Speicher 204 abgespeichert werden:
- – Parameter P1 (Parameter „Einheit Massefluss”): Ausgangswert A1a, Parameterwert auf Alb geändert (Zeitmarke P1 b, Benutzer A);
- – Parameter P17 (Parameter „Schleichmenge”): Ausgangswert A17a, Parameterwert auf A17b geändert (Zeitmarke P17b, Benutzer B).
-
Darüber hinaus können durch die History-Komponente 208 bestimmte vorher festgelegte Ereignisse oder „Events” erkannt und dokumentiert werden. Hierzu ist in der History-Komponente 208 das Eventmodul 210 vorgesehen. In dem in 7 dargestellten Ablaufdiagramm ist die Erkennung und Protokollierung eines Ereignisses dargestellt.
-
Im Schritt 700 befindet sich das Eventmodul 210 in Warteposition. Im Schritt 701 wird ermittelt, ob eines der vorher festgelegten Ereignisse eingetreten ist oder nicht. Dabei wird zwischen „ankommenden Ereignissen” („Event Appearing”) und „abgehenden Ereignissen” („Event Disappearing”) unterschieden. Ankommende Ereignisse bezeichnen einen Übergang von einem inaktiven Zustand zu einem aktiven Zustand, wohingegen abgehende Ereignisse einen Übergang von einem aktiven Zustand zu einem inaktiven Zustand bezeichnen. Solange in Schritt 701 keines der vorher festgelegten Ereignisse erkannt wird, bleibt das Eventmodul 210 in Warteposition (Schritt 700). Wenn eines der vorher festgelegten Ereignisse erkannt wird, wird im nächsten Schritt 702 das Speicherzugriffsmodul 214 aufgerufen, welches dazu ausgelegt ist, Zugriffe auf den History-Speicher 204 durchzuführen. Im Schritt 703 wird das ankommende oder abgehende Ereignis in den History-Speicher 204 geschrieben. Der das Ereignis betreffende Eintrag im History-Speicher umfasst dabei eine Eventnummer, die das aufgetretene Ereignis eindeutig bezeichnet, sowie eine Zeitmarke, die angibt, wann das entsprechende Ereignis aufgetreten ist. Diese Zeitmarke wird vom Zeitgeber 205 zur Verfügung gestellt. Darüber hinaus kann in dem Eintrag gespeichert sein, ob es sich um ein ankommendes Ereignis („Event Appearing”) oder um ein abgehendes Ereignis („Event Disappearing”) handelt.
-
Im Folgenden sind Beispiele von Einträgen im History-Speicher 204 aufgeführt, die sich auf das Auftreten von vorher festgelegten Ereignissen beziehen:
- – Event E1 (Event „Medium inhomogen”): Ausgangswert E1 inaktiv, Event E1 tritt auf (Zeitmarke T1b);
- – Event E17 (Event „Schleichmenge aktiv”): Ausgangswert E17 aktiv, Event E17 ist nicht mehr aktiv (Zeitmarke T17b).
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Nicht-Patentliteratur
-
- EU-Richtlinie 1999/93/EG [0035]
