DE102017116539A1

DE102017116539A1 - Prozesssteuerungskommunikation zwischen einem tragbaren Feldwartungswerkzeug und einem Asset-Management-System

Info

Publication number: DE102017116539A1
Application number: DE102017116539.8A
Authority: DE
Inventors: Todd M. Toepke; Joseph D. Fisher; James R. Logerquist; Alan R. Dewey; Alden C. Russell III; Laura Briggs; Ronald Hempel
Original assignee: Fisher Rosemount Systems Inc
Current assignee: Fisher Rosemount Systems Inc
Priority date: 2016-07-22
Filing date: 2017-07-21
Publication date: 2018-01-25
Also published as: GB2552418B; JP7133294B2; GB2552418A; JP2018014104A; US10270853B2; CN107643739A; CN107643739B; GB201710124D0; US20180027071A1

Abstract

Eine Kommunikationsarchitektur Plattform-zu-Plattform für einen Prozesssteuerungs-Messaging-Dienst in einem Prozessleitsystem oder eine andere industrielle Umgebung ermöglicht stationären oder tragbaren industriellen Rechengeräten, miteinander in One-to-One- und One-to-Many-Kommunikation und netzwerkübergreifend, auch über isolierte Netzwerke innerhalb des Prozessleitsystems oder der industriellen Umgebung und über externe Netzwerke übergreifend, zu kommunizieren. Eine anfordernde industrielle Rechengeräteplattform erzeugt eine Nachricht für ein industrielles Zielrechengerät oder ein reagierendes industrielles Rechengerät im Kommunikationsprotokoll der Zielplattform und verpackt die Nachricht in ein Kommunikationsprotokoll des Prozessteuerungs-Messaging-Dienstes. Die Kommunikationsarchitektur decodiert die verpackte Nachricht in das Kommunikationsprotokoll des industriellen Zielrechengerätes und leitet die decodierte verpackte Nachricht an den Bestimmungsort weiter. Die Kommunikationsarchitektur ermöglicht viele unterschiedliche Kommunikationsdienste wie Instant-/Echtzeit-Peer-to-Peer-Messaging, Zeitsynchronisierung, automatische Datenübertragung mit einem Asset-Management-System, Kommunikation mit Feldgeräten über ein Asset-Management-System und Übertragung großer Datenmengen.

Description

Verwandte Anmeldungen
Diese Anmeldung ist eine Fortsetzung der US-Anmeldung Nr. 15/217,112 mit dem Titel „Process Control Communication Architecture“, eingereicht am 22. Juli 2016, deren gesamte Offenbarung hiermit ausdrücklich durch Bezugnahme in diese Schrift aufgenommen wird.
Technisches Gebiet
Die vorliegende Offenbarung bezieht sich allgemein auf Prozessleitsysteme und insbesondere auf eine Prozesssteuerungskommunikation zwischen einem tragbaren Feldwartungswerkzeug und einem Asset-Management-System.
Hintergrund der Erfindung
Verteilte Prozessleitsysteme, wie sie in chemischen, Erdöl- oder anderen Prozessen eingesetzt werden, umfassen typischerweise eine oder mehrere Prozesssteuerungen und Ein-/Ausgabe-(E/A-)Vorrichtungen, die kommunikativ mit mindestens einer Host- oder Bediener-Workstation und mit einem oder mehreren Feldgeräten über analoge, digitale oder kombinierte analoge/digitale Busse oder über eine drahtlose Kommunikationsverbindung oder ein Netzwerk verbunden sind.
Ein (gelegentlich als „Regler“ bezeichneter) Prozessregler, der im Allgemeinen innerhalb der Betriebsanlage oder einer anderen industriellen Umgebung angeordnet ist, empfängt Signale (die manchmal als „Steuereingangssignale“ bezeichnet werden), welche Prozessmessungen anzeigen und die durch diese Signale übertragenen Informationen verwenden, um Steuerroutinen zu implementieren, die dazu führen, dass der Regler Steuersignale (manchmal als „Steuerausgangssignale“ bezeichnet) auf der Grundlage der Steuereingaben und der internen Logik der Steuerroutinen erzeugt. Die Regler senden die erzeugten Steuersignale über Busse oder andere Kommunikationsverbindungen, um den Betrieb von Feldgeräten zu steuern. In einigen Fällen können die Regler die Koordinierung mit Steuerroutinen übernehmen, die von intelligenten Feldgeräten implementiert werden, wie zum Beispiel Highway Addressable Remote Transmitter (HART^®), WirelessHART^® und FOUNDATION^® Fieldbus (manchmal lediglich als „Fieldbus“ bezeichnete) Feldgeräte. Darüber hinaus können in vielen Fällen Betriebsanlagen oder andere industrielle Geräte, die in der Betriebsanlage oder einem anderen industriellen Umfeld betrieben werden, eine Funktion ausführen, die nicht der direkten Steuerung durch den Prozessregler unterliegt, beispielsweise Vibrationserkennungsgeräte, rotierende Vorrichtungen, Stromerzeugungsanlagen usw.
Die Feldvorrichtungen, die typischerweise mit der Steuerung verbunden sind, zu denen beispielsweise Ventile, Ventilstellungsgeber, Schalter und Sender (z. B. Temperatur-, Druck-, Füllstands- und Durchflussmengensensoren) zählen können, befinden sich innerhalb der Prozessumgebung und führen in der Regel physische oder Prozesssteuerungsfunktionen durch. Beispielsweise kann sich ein Ventil in Reaktion auf ein von einem Regler empfangenes Steuerausgangssignal öffnen oder schließen oder an einen Regler eine Messung eines Prozessparameters übermitteln, so dass der Regler die Messung als Steuereingangssignal nutzen kann. Intelligente Feldgeräte, beispielsweise Feldgeräte, die Konformität mit dem bekannten Fieldbus-Protokoll aufweisen, können auch Steuerungsberechnungen, Alarmierungsfunktionen und andere Steuerfunktionen durchführen, die üblicherweise innerhalb eines Reglers implementiert werden. Feldgeräte können so ausgebildet sein, dass sie mit Reglern und/oder anderen Feldgeräten mithilfe verschiedener Kommunikationsprotokolle kommunizieren können. Beispielsweise kann eine Betriebsanlage herkömmliche analoge 4- bis 20-mA-Feldgeräte, HART^®-Feldgeräte, Fieldbus-Feldgeräte und/oder andere Arten von Feldgeräten umfassen.
Die Prozessregler empfangen Signale, die Prozessmessungen von Sensoren oder Feldgeräten und/oder sonstigen die Feldgeräte betreffende Informationen anzeigen und eine Steuerungsanwendung ausführen, welche Prozesssteuerungsentscheidungen trifft, auf der Grundlage der empfangenen Informationen Steuersignale erzeugen und sich mit den Einzelsteuerungen oder Blöcken koordinieren, die in den Feldgeräten ausgeführt werden. Die Einzelsteuerungen im Regler senden die Steuersignale über die Kommunikationsleitungen oder Verbindungen zu den Feldgeräten, um dadurch den Betrieb von zumindest einem Teil der Prozessanlage oder des Prozesssystems zu steuern.
Informationen aus den Feldgeräten und dem Regler werden üblicherweise über eine Datenautobahn einem oder mehreren anderen Hardwaregeräten, beispielsweise Bediener-Workstations, Personal Computer (PCs) oder Rechengeräten, Datenarchivierungen, Berichtsgeneratoren, zentralisierten Datenbanken oder anderen zentralisierten Verwaltungsrechnergeräten zur Verfügung gestellt, die in der Regel, jedoch nicht immer, in Kontrollräumen oder an anderen Orten abseits der raueren Betriebsanlagenumgebung angeordnet sind. Jedes dieser Hardware-Geräte ist in der Regel, jedoch nicht immer, über die Prozessanlage oder über einen Teil der Prozessanlage zentralisiert. Diese Hardwarevorrichtungen führen Anwendungen aus, die beispielsweise einem Bediener ermöglichen können, Funktionen in Bezug auf die Steuerung eines Prozesses und/oder das Betreiben der Prozessanlage auszuführen, beispielsweise das Ändern von Einstellungen der Prozesssteuerroutine, das Ändern des Betriebs der Einzelsteuerungen innerhalb der Regler oder Feldgeräte, die Anzeige des aktuellen Zustands des Prozesses, die Anzeige von Alarmen, die von Feldgeräten und Regler erzeugt werden, das Simulieren des Ablaufs des Prozesses zum Zweck der Schulung von Personal oder der Prüfung der Prozesssteuerungssoftware, das Pflegen und Aktualisieren einer Konfigurationsdatenbank usw. Die von den Hardwaregeräten, Reglern und Feldgeräten verwendete Datenautobahn kann einen drahtgebundenen Kommunikationsweg, einen drahtlosen Kommunikationsweg oder eine Kombination drahtgebundener und drahtloser Kommunikationswege umfassen.
Beispielsweise umfasst das von Emerson Process Management vertriebene Steuersystem DeltaV^TM mehrere Anwendungen, die von verschiedenen Geräten gespeichert und ausgeführt werden, welche sich an unterschiedlichen Stellen innerhalb einer Prozessanlage befinden. Eine Konfigurationsanwendung, die sich in einem oder mehreren Bediener-Workstations oder Rechengeräten befindet, ermöglicht es Benutzern, Prozesseinzelsteuerungen zu erstellen oder zu ändern und diese Prozesseinzelsteuerungen über eine Datenautobahn auf dedizierte verteilte Regler herunterzuladen. Üblicherweise bestehen diese Einzelsteuerungen aus kommunikativ miteinander verbundenen Funktionsblöcken, die Funktionen innerhalb des Steuerungsschemas auf der Grundlage von Eingangssignalen zu diesem ausführen und die Ausgangssignale zu anderen Funktionsblöcken innerhalb des Steuerungsschemas liefern. Die Konfigurationsanwendung erlaubt gegebenenfalls auch einem Konfigurationsdesigner, Bedienerschnittstellen zu erstellen oder zu ändern, die von einer Anzeigeanwendung verwendet werden, um einem Bediener Daten anzuzeigen und ihm zu ermöglichen, Einstellungen, beispielsweise Einstellpunkte, in den Prozesssteuerungsroutinen zu ändern. Jeder dedizierte Regler und in einigen Fällen ein oder mehrere Feldgeräte speichern und führen eine jeweilige Steuerungsanwendung aus, die die ihr zugeordneten und heruntergeladenen Einzelsteuerungen leitet, um eine tatsächliche Prozesssteuerungsfunktionalität zu implementieren. Die Anzeigeanwendungen, die auf einer oder mehreren Bediener-Workstations (oder auf einem oder mehreren entfernten Rechnergeräten in kommunikativer Verbindung mit den Bediener-Workstations und der Datenautobahn) ausgeführt werden können, empfangen Daten von der Steuerungsanwendung über die Datenautobahn und zeigen diese Daten den Prozesssteuerungs-Systemdesignern, Bedienern oder Benutzern unter Verwendung der Bedienerschnittstellen an und können eine beliebige Anzahl unterschiedlicher Ansichten, beispielsweise eine Bedieneransicht, eine Ingenieursansicht, eine Technikeransicht usw. liefern. Eine Datenarchivierungs-Anwendung wird typischerweise in einer Datenarchivierungseinrichtung gespeichert und von dieser ausgeführt, welche einige oder alle über die Datenautobahn verfügbar gemachten Daten erfasst und speichert, während eine Konfigurationsdatenbankanwendung in einem weiteren Computer ausgeführt werden kann, der an die Datenautobahn angeschlossen ist, um die aktuelle Konfiguration der Prozesssteuerroutine und die zugehörigen Daten zu speichern. Alternativ kann sich die Konfigurationsdatenbank in derselben Workstation wie die Konfigurationsanwendung befinden.
Wie oben angemerkt, werden Bedieneranzeigeanwendungen typischerweise systemweit in einer oder mehreren der Workstations implementiert und liefern dem Bedienungs- oder Wartungspersonal Anzeigen bezüglich des Betriebszustands des Steuersystems oder der Vorrichtungen innerhalb der Betriebsanlage. Gewöhnlich werden diese Anzeigen in Form von Alarmanzeigen angezeigt, welche Alarme empfangen, die von Reglern oder Geräten innerhalb der Prozessanlage, von Steueranzeigen, die den Betriebszustand der Regler anzeigen, von anderen Vorrichtungen innerhalb der Prozessanlage, von Wartungsanzeigen, die den Betriebszustand der Geräte innerhalb der Prozessanlage anzeigen, und von anderen erzeugt werden. Diese Anzeigen sind in der Regel so ausgebildet, dass sie Informationen oder Daten aus den Prozesseinzelsteuerungen oder den Geräten innerhalb der Prozessanlage auf bekannte Art und Weise anzeigen. In einigen bekannten Systemen haben Anzeigen eine Grafik, die mit einem physischen oder logischen Element verknüpft ist, das kommunikativ an das physische oder logische Element gebunden ist, um Daten über das physische oder logische Element zu empfangen. Die Grafik kann auf dem Bildschirm auf der Grundlage der empfangenen Daten verändert werden, um beispielsweise zu veranschaulichen, dass ein Tank halb voll ist, um den durch einen Strömungssensor gemessenen Durchfluss zu veranschaulichen usw.
Herkömmliche analoge 4- bis 20-mA-Feldgeräte kommunizieren mit einem Regler über eine (manchmal auch als „Schleife“ oder „Stromschleife“ bezeichnete) Zweidraht-Kommunikationsverbindung, die so ausgebildet ist, dass sie ein 4- bis 20-mA-Wechselstromsignal überträgt, das eine Messung oder einen Steuerbefehl anzeigt. Beispielsweise kann ein Pegelgeber einen Tankpegel erfassen und über die Schleife ein dieser Messung entsprechendes Stromsignal übertragen (z. B. ein 4-mA-Signal für den Füllstand 0 %, ein 12-mA-Signal für den Füllstand 50 % und ein 20-mA-Signal für den Füllstand 100 %). Die Steuerung empfängt das Stromsignal, bestimmt die Tankpegelmessung auf der Grundlage des Stromsignals und führt auf der Grundlage der Tankpegelmessung eine bestimmte Aktion (z. B. Öffnen oder Schließen eines Einlassventils) durch. Bei den analogen 4- bis 20-mA-Feldgeräten gibt es in der Regel zwei Abwandlungen, nämlich Vierdraht-Feldgeräte und Zweidraht-Feldgeräte. Ein Vierdraht-Feldgerät stützt sich für die Kommunikation in der Regel auf einem ersten Satz von Drähten (d. h., die Schleife) und einem zweiten Satz von Drähten für den Strom. Bei einem Zweidraht-Feldgerät wird die Schleife sowohl für die Kommunikation als auch für den Strom benutzt. Diese Zweidraht-Feldgeräte können als „schleifengespeiste“ Feldgeräte bezeichnet werden.
Aufgrund der Einfachheit und Effektivität der Konstruktion führen Prozessanlagen oftmals herkömmliche 4- bis 20-mA-Systeme aus. Leider können herkömmliche 4- bis 20-mA-Stromschleifen an einem bestimmten Zeitpunkt jeweils nur ein einziges Prozesssignal übertragen. Somit kann ein Aufbau mit einem Steuerventil und einem Strömungssender auf einem Rohr, durch welches Material fließt, drei isolierte Stromschleifen erfordern: eine für das Übertragen eines 4- bis 20-mA-Signals, das einen Steuerbefehl für das Ventil anzeigt (z. B., um das Ventil in die Stellung 60 % offen zu bewegen), eine zweite für das Übertragen eines 4- bis 20-mA-Signals, das die tatsächliche Position des Ventils anzeigt (z.B., damit die Steuerung das Ausmaß erkennt, in dem das Ventil auf Steuerbefehle reagiert hat), und eine dritte für das Übertragen eines 4- bis 20-mA-Signals, das einen gemessenen Durchfluss anzeigt. Infolgedessen kann ein herkömmlicher 4- bis 20-mA-Aufbau in einer Betriebsanlage mit einer großen Anzahl von Feldgeräten eine umfangreiche Verdrahtung erfordern, die teuer sein und bei der Einrichtung und Wartung des Kommunikationssystems zu Komplexität führen kann.
In jüngerer Zeit war die Prozesssteuerungsbranche bestrebt, innerhalb der Prozesssteuerungsumgebung digitale Kommunikation umzusetzen. Zum Beispiel verwendet das HART^®-Protokoll die Wechselstrom-Größenordnung der Schleife, um analoge Signale zu senden und zu empfangen, überlagert das Gleichstromsignal jedoch auch mit einem digitalen Wechselstrom-Trägersignal, um die Zweiweg-Feldkommunikation mit intelligenten Feldinstrumenten zu ermöglichen. Als weiteres Beispiel bietet das Fieldbus-Protokoll eine vollständig digitale Kommunikation auf einem (gelegentlich auch als „Segment“ oder „Fieldbus-Segment“ bezeichneten) Zweidraht-Bus. Dieses Zweidraht-Fieldbus-Segment kann an mehrere Feldgeräte gekoppelt werden, um die mehrere Feldgeräte (über eine auf dem Segment verfügbare Gleichspannung) mit Strom zu versorgen und die Kommunikation durch die Feldgeräte (über ein der Gleichstromversorgungsspannung überlagertes Wechselstrom-Digitalkommunikationssignal) zu ermöglichen. Allgemein gesagt, da die angeschlossenen Feldgeräte dasselbe Segment für die Kommunikation verwenden und parallel geschaltet sind, kann zu einem gegebenen Zeitpunkt nur ein Feldgerät eine Nachricht über das Segment übertragen. Dementsprechend wird die Kommunikation auf einem Segment durch eine Vorrichtung koordiniert, die als Link Active Scheduler (LAS) bezeichnet wird. Der LAS ist für die Übergabe eines Tokens zwischen Feldgeräten verantwortlich, die mit dem Segment verbunden sind. Zu einem gegebenen Zeitpunkt kann nur das Gerät mit dem Token über das Segment kommunizieren.
Diese digitalen Kommunikationsprotokolle ermöglichen im Allgemeinen, dass mehr Feldgeräte mit einer bestimmten Kommunikationsverbindung verbunden werden, mehr und schnellere Kommunikation zwischen den Feldgeräten und dem Regler unterstützt wird, und/oder sie erlauben Feldgeräten, mehr und unterschiedliche Arten von Informationen (z. B. Informationen über den Status und die Konfiguration des Feldgerätes selbst) an den Prozessregler und andere in dem Steuerungsnetz oder an dieses angeschlossene Geräte zu senden. Darüber hinaus ermöglichen diese Standard-Digitalprotokolle, dass Feldgeräte unterschiedlicher Hersteller innerhalb des gleichen Prozesssteuerungsnetzes gemeinsam verwendet werden können.
Unabhängig von dem verwendeten Kommunikationsprotokoll können Feldgeräte eine Einrichtung, Konfiguration, Prüfung und Wartung vor Ort erforderlich machen. Wenn beispielsweise ein Feldgerät an einer bestimmten Stelle an einer Prozesssteuerungsanlage installiert werden kann, muss das Feldgerät eventuell programmiert werden und muss dann vor und nach dem Installieren des Feldgerätes unter Umständen erprobt werden. Auch bereits installierte Feldgeräte müssen aus Wartungsgründen regelmäßig überprüft werden, oder wenn beispielsweise ein Fehler erkannt wurde und das Feldgerät für Service oder Reparatur diagnostiziert werden muss.
Im Allgemeinen werden die Konfiguration und das Testen von Feldgeräten vor Ort unter Verwendung eines Handheld-Wartungswerkzeugs, z. B. eines tragbaren Prüfgerätes, durchgeführt. Da viele Feldgeräte in entfernten, schwer zugänglichen Orten installiert sind, ist es für einen Benutzer einfacher, die installierten Geräte an solchen entfernten Standorten mit einem tragbaren Prüfgerät zu testen, statt ein Vollkonfigurations- und Prüfgerät zu verwenden, das unter Umständen schwer, sperrig und nicht tragbar ist, wobei in der Regel erforderlich ist, dass das installierte Feldgerät zum Standort des Diagnosegerätes transportiert wird.
Unabhängig vom verwendeten Kommunikationsprotokoll können Feldgeräte eine Einrichtung, Konfiguration, Prüfung und Wartung erforderlich machen. Wenn beispielsweise ein Feldgerät an einer bestimmten Stelle an einer Prozesssteuerungsanlage installiert werden kann, muss das Feldgerät eventuell programmiert und anschließend vor und nach dem Installieren des Feldgerätes unter Umständen erprobt werden. Auch bereits installierte Feldgeräte müssen aus Wartungsgründen regelmäßig überprüft werden, oder wenn beispielsweise ein Fehler erkannt wurde und das Feldgerät für Service oder Reparatur diagnostiziert werden muss. Bediener verwenden industrielle Rechengeräte zum Konfigurieren, Beheben von Fehlern, Kalibrieren, Analysieren und Ausführen anderer Operationen an Prozesssteuerungsgeräten (z. B. an Reglern, Feldgeräten usw.). Bei einigen bekannten Systemen kann ein Bediener eine Anzahl von Analysen und/oder ein Management eines Feldgerätes unter Verwendung eines stationären industriellen Rechengerätes (z. B. PC, Workstation usw.) durchführen, um Asset-Management, Vibrationsmanagement, Flottenmanagement industrieller Rechengeräte usw. vorzunehmen.
Andererseits kann die Konfiguration und die Prüfung von Feldgeräten an Ort und Stelle unter Verwendung eines tragbaren industriellen Rechengerätes, wie z. B. eines Handheld-Feldkommunikators, eines Kalibrators, eines tragbaren Prüfgerätes usw. durchgeführt werden. Ein Bediener kann das tragbare industrielle Rechengerät physisch an ein Feldgerät anschließen und dann mit dem Feldgerät über das tragbare industrielle Rechengerät zur Diagnose, zur Änderung der Konfiguration, zum Kalibrieren des Feldgerätes usw. kommunizieren. Da beispielsweise viele Feldgeräte in entfernten, schwer zugänglichen Orten installiert sind, ist es für einen Benutzer einfacher, die installierten Geräte an solchen entfernten Standorten mit einem tragbaren Prüfgerät zu testen, statt ein Vollkonfigurations- und Prüfgerät zu verwenden, das schwer, sperrig und nicht tragbar sein kann, wobei in der Regel erforderlich ist, dass das installierte Feldgerät zum Standort des Diagnosegerätes transportiert wird.
Wenn ein Benutzer, beispielsweise ein Servicetechniker, einen Wartungstest und/oder eine Kommunikation mit einem Feldgerät durchführt, ist das tragbare Prüfgerät in der Regel kommunikativ mit einer Kommunikationsverbindung (z. B. einer Stromschleife oder einem Fieldbus-Segment) oder direkt mit einem Feldgerät (z. B. über Kommunikationsanschlüsse des Feldgerätes) verbunden. Das tragbare Prüfgerät versucht zunächst, mit dem Feldgerät zu kommunizieren, beispielsweise durch Senden und/oder Empfangen von digitalen Kommunikationssignalen entlang der Schleife oder des Segments unter Verwendung des von dem Feldgerät unterstützten Kommunikationsprotokolls. Wenn sich die Stromschleife oder das Segment in ordnungsgemäßem Betriebszustand befindet, können die Kommunikationssignale problemlos gesendet und/oder empfangen werden. Wenn jedoch die Schleife, das Segment oder das Feldgerät einen elektrischen Fehler, z. B. einen Kurzschluss oder eine Unterbrechung, aufweist, kann die Kommunikation behindert sein und es kann zur Fehlererkennung eine Diagnose von Schleife, Segment und/oder Feldgerät erforderlich werden.
Wenn ein solcher Fehler erkannt wird, muss ein Techniker möglicherweise eine Vielzahl anderer Werkzeuge verwenden, um das Feldgerät und/oder die Kommunikationsverbindung zu prüfen. Zum Beispiel benötigt der Techniker möglicherweise eine tragbare Stromversorgung, um ein abgelegenes Feldgerät zu versorgen. Der Techniker muss möglicherweise ein abgelegenes Feldgerät mit Strom versorgen, wenn das Feldgerät beispielsweise aufgrund eines anlagenweiten Stromausfalls oder aufgrund eines Problems mit einer lokalen Stromversorgung ohne Strom ist. Als weiteres Beispiel kann der Techniker ein Feldgerät zur Fehlersuche einfach vom Netz abkoppeln, um zu vermeiden, dass andere Feldgeräte und der Rest des Prozessleitsystems beeinträchtigt werden. Der Techniker benötigt unter Umständen auch ein Multimeter, um Strom, Spannung, Widerstand, Impedanz usw. an einem Segment oder einer Schleife zu messen usw. Jedes dieser Werkzeuge kann einen gewissen Platz beanspruchen; für den Techniker im Feld mag das Mitführen unpraktisch sein. Um dieses Problem mit dem Mitführen mehrerer Werkzeuge zu lösen, haben die Hersteller tragbare Prüfgeräte entwickelt, die zur Versorgung einer HART-Schleife mit Strom eine Stromversorgung aufweisen. Leider sind diese mit einer Stromversorgung versehenen tragbaren Prüfgeräte im Allgemeinen nicht in der Lage, Fieldbus-Feldgeräte mit Strom zu versorgen. Außerdem entsprechen die üblichen tragbaren Stromversorgungen und mit Stromversorgung versehenen tragbaren Prüfgeräte häufig nicht den Standards der Intrinsic Safety (IS) und können daher in explosionsgefährdeten Bereichen (z. B. Umgebungen oder Atmosphären, die wegen des Vorhandenseins von explosivem Gas oder Staub explosionsgefährdet sind) nicht gefahrlos verwendet werden.
Darüber hinaus muss der Techniker, wenn sich ein Feldgerät in einem explosionsgefährdeten Bereich befindet, gegebenenfalls überprüfen, ob jedes seiner Werkzeuge in eigensicherer Weise funktioniert. Wenn also in einem explosionsgefährdeten Bereich gearbeitet wird, muss das Werkzeug des Technikers zur Gewährleistung eines gefahrlosen Betriebs den IS-Normen entsprechen. Im Allgemeinen sehen IS-Normen Einschränkungen für elektrische Geräte und Verdrahtungen in explosionsgefährdeten Umgebungen vor, um sicherzustellen, dass die elektrische Ausrüstung und die Verdrahtung keine Explosion auslöst. Um die IS-Normen zu erfüllen, muss elektrisches Gerät generell unter Bwerücksichtigung von zwei Kernkonzepten konstruiert werden: Energiebegrenzung und Fehlertoleranz. In jedem Fall hat die Anforderung der IS-Konformität in einigen Anwendungen zur Entwicklung eines weiteren Satzes von Werkzeugen für die Feldwartung geführt, die unter Umständen unter einem der oben erwähnten Feldgeräteprotokolle oder unter anderen Protokollen funktionieren, welche jedoch ebenfalls IS-konform sind.
Wie oben erwähnt, umfassen die meisten Prozessanlagen und andere industrielle Umgebungen (wie Ölbohrplattformen, Pumpstationen usw.) auch andere industrielle Ausrüstung, wie z. B. rotierende Vorrichtungen, Stromerzeugungs- oder Umwandlungsanlagen, Vibrationsanalyseanlagen usw., die in der Betriebsanlage oder in der industriellen Umgebung eingerichtet, konfiguriert und gewartet werden müssen. Zur Unterstützung dieser Betriebsanlagen kann noch ein weiterer Satz von Feldwartungswerkzeugen benötigt werden, zu dem auch die Konfiguration der Ausrüstung, die Prüfung der Ausrüstung usw. zählt.
Diese Arten industrieller Rechengeräte müssen oftmals auf sichere und zuverlässige Weise mit ordnungsgemäßer Berechtigung kommunizieren und Daten austauschen, und dieses Erfordernis nimmt rasch zu, um immer größere Einsatz- und Funktionsmöglichkeiten zu unterstützen; dies unterstreicht eine Reihe spezifischer Bedürfnisse in Bezug auf Kommunikation und Datenaustausch innerhalb des Prozessleitsystems (d. h. in der Betriebsanlage), separat von der Datenautobahn der Kommunikation zwischen einem Kontrollraum und Prozesssteuerungsgeräten. Obwohl Informationstechnologie-Infrastruktur (IT-Infrastruktur), z. B. Transmission Control Protocol/Internet Protocol (TCP/IP), Authentifizierung, Active Directory usw., in diesen industriellen Umgebungen existiert, sind zusätzliche Mechanismen und Dienste erforderlich, um zusätzliche Sicherheits- und Zugriffskontrollberechtigungen möglich zu machen. Darüber hinaus sind zusätzliche Mechanismen und Dienste erforderlich, um Kommunikation, Messaging, Datenübertragung und andere Einsatzmöglichkeiten zusätzlicher Prozessleitsystemanwendungen zu unterstützen.
Zusammenfassung
Die vorliegende Offenbarung beschreibt eine Kommunikationsarchitektur, die eine sichere und zuverlässige Art und Weise zur Kommunikation zwischen einer externen Cloud, Personal Computern, industriellen Rechengeräten usw. zu anderen industriellen Rechengeräten (z. B. Feldkommunikatoren, tragbaren Prüfgeräten, Kalibratoren usw.) in einem Prozessleitsystem, einer Prozessanlage oder in anderen industriellen Umgebungen liefert. Zu diesen Kommunikationsformen zählen Übertragung großer Datendateien, Echtzeit-Messaging, Datensynchronisierung, Authentifizierung und Autorisierung, Datenübertragung von automatisiertem Asset-Management-, Kommunikation mit einem Prozessinstrument über ein Asset-Management-System und Flottenmanagement tragbarer industrieller Rechengeräte.
Ferner sieht die Kommunikationsarchitektur Sicherheitsmechanismen, insbesondere über die Standard-Informationstechnologiesicherheit hinausgehende zusätzliche Berechtigungsebenen vor, um gegenwärtige und zukünftige Sicherheitsanforderungen in Prozessleitsystemen, Prozessanlagen oder anderen industriellen Umgebungen zu erfüllen. Darüber hinaus erlaubt die Architektur Many-to-Many-Kommunikation, Dateiübertragungen und Operationen zwischen industriellen Rechengeräten. Die Kommunikationsarchitektur läuft mit Protokollunabhängigkeit, so dass sie mit einer Reihe verschiedener Protokoll- und physischen Schichttechnologien wie WLAN, USB usw. funktionsfähig ist. Die Kommunikationsarchitektur läuft auch mit Gerätetypunabhängigkeit, so dass sie mit unterschiedlichen stationären und tragbaren industriellen Rechengeräten funktioniert, und mit Anwendungsunabhängigkeit, so dass sie mit Diensten für eine breite Palette von Software-Anwendungen funktionsfähig ist.
Als ein Merkmal der Kommunikationsarchitektur kann eine Asset-Management-Anwendung mit einer Funktionalität zur Durchführung einer automatischen Synchronisierung von Daten zwischen sich selber und einem industriellen Rechengerät aktiviert werden. In einer Implementierung hat die Asset-Management-Anwendung gegebenenfalls die Möglichkeit, Daten zwischen sich und einem industriellen Rechengerät in Echtzeit zu synchronisieren, da Änderungen an den Daten durch das industrielle Rechengerät vorgenommen werden, während das industrielle Rechengerät über die Kommunikationsarchitektur mit der Asset-Management-Anwendung verbunden ist. Alternativ kann die Asset-Management-Anwendung über die Funktionsfähigkeit verfügen, periodisch und automatisch Daten zwischen sich selber und einem industriellen Rechengerät zu synchronisieren, wann immer das industrielle Rechengerät mit einem durch die Kommunikationsarchitektur definierten Prozesssteuerungs-Messaging-System verbunden ist.
Kurzbeschreibung der Zeichnungen
1 ist ein Blockdiagramm eines verteilten Prozesssteuerungsnetzwerks, das sich innerhalb einer Prozessanlage oder einer anderen industriellen Umgebung befindet, einschließlich industrieller Rechengeräte, die jeweils eine Plattform aufweisen, welche eine Kommunikationsarchitektur zur Plattform-zu-Plattform-Kommunikation verwendet;
2 ist ein Blockdiagramm eines beispielhaften Prozesssteuerungs-Messaging-Netzwerks, das in einem Prozessleitsystem, in einer Prozessanlage oder in einer anderen industriellen Umgebung im Einsatz ist;
3 ist ein Blockdiagramm einer beispielhaften Interaktion zwischen industriellen Rechengeräten unter Verwendung einer Prozesssteuerungs-Messaging-Systemarchitektur;
4 ist eine schematische Beziehung zwischen der Prozesssteuerungs-Messaging-Architektur, den Zugangspunkten, den teilnehmenden Vorrichtungen und den Prozesssteuerungs-Messaging-Diensten;
5A und 5B sind Abbildungen primärer öffentlicher Schnittstellen und Basisklassen, die in einer Prozesssteuerungs-Messaging-Systemarchitektur definiert sind;
6 ist eine Abbildung beispielhafter gemeinsamer Schnittstellen, die durch die Prozesssteuerungs-Messaging-Systemarchitektur implementiert sind;
7 ist ein Sequenzdiagramm eines Anmeldevorgangs zwischen einem industriellen Rechengerät und einem Enrollment-Server;
8 ist ein Sequenzdiagramm einer Anforderungs-/Antwortoperation zwischen einem industriellen Rechengerät und einem Zeitsynchronisierungsserver;
9 ist ein Sequenzdiagramm einer Übertragungsoperation großer Datenmengen zwischen einer Quelle und einem Ziel;
10 ist ein Blockdiagramm eines beispielhaften industriellen Rechengerätes, das schematisch in 1 dargestellt ist;
11 ist die Darstellung eines beispielhaften tragbaren Feldwartungswerkzeugs, das mit einem Feldgerät verbunden und drahtlos mit einem Prozesssteuerungs-Messaging-System gekoppelt ist;
12 ist ein Blockdiagramm des in 11 gezeigten tragbaren Feldwartungswerkzeugs, das ein Beispiel abbildet, in dem das tragbare Feldwartungswerkzeug einen aktiven Kommunikator für die Versorgung von Feldgeräten mit Strom und für die Kommunikation mit Feldgeräten sowie zum drahtlosen Kommunizieren über das Prozesssteuerungs-Messaging-System umfasst;
13 ist ein Blockdiagramm von tragbaren Feldwartungswerkzeugen in Kommunikation mit einem Asset-Management-System, einschließlich der Komponenten des Asset-Management-Systems für das Kommunizieren mit dem tragbaren Feldwartungswerkzeug;
14A–C veranschaulichen beispielhafte Datentabellen, die von einem Server erzeugt und einem tragbaren Feldwartungswerkzeug geliefert werden können, um eine Berechtigungsebene für einen Benutzer zu bestimmen;
15 ist ein Flussdiagramm eines beispielhaften Prozesses für ein tragbares Feldwartungswerkzeug, um mit einem Feldgerät über ein Prozessleitsystem zu kommunizieren;
16 ist ein Flussdiagramm eines beispielhaften Prozesses für einen Werkzeugkommunikationsserver in einem Asset-Management-System, um einem tragbaren Feldwartungswerkzeug die Kommunikation mit einem Feldgerät über ein Prozessleitsystem zu ermöglichen;
17 ist ein Flussdiagramm eines beispielhaften Prozesses für eine gemeinsam genutzte digitale Bibliothek in einem Asset-Management-System, um einem tragbaren Feldwartungswerkzeug die Kommunikation mit einem Feldgerät über ein Prozessleitsystem zu ermöglichen, und
18 ist ein Flussdiagramm eines beispielhaften Verfahrens zum automatischen Synchronisieren von Daten-Sets zwischen einem tragbaren Feldwartungswerkzeug und einer Asset-Management-Anwendung.
Eingehende Beschreibung
1 ist ein Blockdiagramm und ein schematisches Diagramm eines beispielhaften Prozesssteuerungsnetzwerks 100, das in einem Prozessleitsystem, einer Prozessanlage oder einer anderen industriellen Umgebung 10 eingesetzt ist. Das Prozesssteuerungsnetzwerk 100 kann ein Netzwerk-Backbone 105 umfassen, das eine direkte oder indirekte Konnektivität zwischen unterschiedlichen anderen Geräten herstellt. Das Netzwerk-Backbone 105 kann sowohl drahtlose als auch drahtgebundene Kommunikationskanäle oder Links umfassen. Die mit dem Netzwerk-Backbone 105 gekoppelten Vorrichtungen umfassen in verschiedenen Ausführungsformen Kombinationen von Zugangspunkten 72, tragbare industrielle Rechengeräte 112, die Handrechengeräte oder andere tragbare Rechengeräte wie ein Laptop-Computer, ein Tablet-Computer, ein intelligentes Handheld-Gerät, ein tragbares Prüfgerät usw. sein können, stationäre industrielle Rechengeräte 113, beispielsweise einen Personal Computer, eine Workstation usw., die jeweils einen Anzeigeschirm 114 aufweisen, sowie verschiedene andere (nicht dargestellte) Eingabe-/Ausgabe-Vorrichtungen, Server 150, usw.
Wie in 1 dargestellt, ist der Regler 11 mit den Feldgeräten 15–22 über Eingabe/Ausgabe-(E/A-)Karten 26 und 28 verbunden, die jedes gewünschte Prozessleit-Kommunikationsprotokoll, wie z. B. eines oder mehrere der HART-, Fieldbus-, CAN-, Profibususw. Protokolle umsetzen können. In 1 ist der Regler 11 kommunikativ mit den Feldgeräten 15–22 verbunden, um die Steuerung der Feldgeräte 15–22 und somit die Steuerung der Betriebsanlage durchzuführen. Im Allgemeinen können die Feldgeräte 15–22 beliebige Arten von Vorrichtungen wie Sensoren, Ventile, Sender, Positionierer usw. sein, während die E/A-Karten 26 und 28 beliebige Arten von E/A-Vorrichtungen sein können, die ein beliebiges gewünschtes Kommunikations- oder Regler-Protokoll erfüllen. Beispielsweise können die Feldgeräte 15–22 und/oder E/A-Karten 26 und 28 dem HART-Protokoll oder dem Fieldbus-Protokoll entsprechend ausgebildet sein. Der Regler 11 enthält einen Prozessor 30, der eine oder mehrere Prozesssteuerroutinen 38 (oder beliebige Module, Blöcke oder Unterprogramme davon), die in einem Speicher 32 gespeichert sind, implementiert oder überwacht. Im Allgemeinen kommuniziert der Regler 11 mit den Geräten 15–22 und den Host-Computern 113, um einen Prozess in jeder gewünschten Weise zu steuern. Darüber hinaus implementiert der Regler 11 eine Steuerstrategie oder ein Steuerungsschema unter Verwendung von sogenannten (nicht dargestellten) Funktionsblöcken, wobei jeder Funktionsblock ein Objekt oder ein anderer Teil (z. B. ein Unterprogramm) einer Gesamtsteuerroutine ist, die (über als Links bezeichnete Kommunikationsverbindungen) mit anderen Funktionsblöcken in Verbindung steht, um Prozessregelkreise innerhalb des Prozessleitsystems 10 zu implementieren. Funktionsblöcke führen in der Regel eine Eingabefunktion aus, wie sie beispielsweise einem Sender, einem Sensor oder einer anderen Prozessparameter-Messeinrichtung, einer Steuerfunktion zugeordnet ist, beispielsweise einer solchen, die mit einer Steuerroutine verknüpft ist, welche eine PID-, Fuzzy-Logik- usw. -Steuerung ausführt, oder einer Ausgabefunktion, die den Betrieb eines beliebigen Gerätes, beispielsweise eines Ventils, steuert, um eine physische Funktion innerhalb des Prozessleitsystems 10 auszuführen. Natürlich existieren Hybrid- und andere Arten von Funktionsblöcken und können verwendet werden. Die Funktionsblöcke können in dem Regler 11 oder in anderen Geräten gespeichert und von ihnen ausgeführt werden.
Wie in 1 dargestellt, sind drahtlose Gateways 35 und drahtlose Kommunikationsnetzwerke 70 ebenfalls kommunikativ mit dem Netzwerk-Backbone 105 gekoppelt. Die Kommunikationsnetzwerke 70 können drahtlose Geräte 40–58 umfassen, welche drahtlose Feldgeräte 40–46, drahtlose Adapter 52a und 52b, Zugangspunkte 55a und 55b und einen Router 58 umfassen. Die drahtlosen Adapter 52a und 52b können mit nicht-drahtlosen Feldgeräten 48 bzw. 50 verbunden sein. Obwohl in 1 nur eine einzige von einigen der Vorrichtungen dargestellt ist, welche mit dem Netzwerk-Backbone 105 verbunden sind, versteht sich von selbst, dass jede der Vorrichtungen mehrere Instanzen auf dem Netzwerk-Backbone 105 haben könnte und dass die Prozessanlage 10 tatsächlich mehrere Netzwerk-Backbones 105 umfassen kann.
Die industriellen Rechengeräte 112, 113 können kommunikativ mit dem Regler 11 und dem drahtlosen Gateway 35 über das Netzwerk-Backbone 105 verbunden sein. Der Regler 11 kann kommunikativ mit den drahtlosen Feldgeräten 40–46 über das Netzwerk-Backbone 105 und ein drahtloses Gateway 35 verbunden sein. Die Funktion des Reglers 11 kann darin bestehen, einen Batch-Prozess oder einen kontinuierlichen Prozess unter Verwendung wenigstens einiger der Feldgeräte 15–22 und 40–50 zu implementieren. Der Regler 11, beispielsweise der von Emerson Process Management vertriebene DeltaV^TM-Regler, ist kommunikativ mit dem Prozesssteuerungsnetzwerk-Backbone 105 verbunden. Der Regler 11 kann auch kommunikativ mit den Feldgeräten 15–22 und 40–50 mithilfe beliebiger Hardware und Software verbunden sein, die beispielsweise mit Standard-4- bis 20-mA-Geräten, E/A-Karten 26, 28 und/oder jedem beliebigen intelligenten Kommunikationsprotokoll wie dem FOUNDATION^®-Fieldbus-Protokoll, dem HART^®-Protokoll, Wireless HART^®-Protokoll usw. verbunden sind. Bei der in 1 dargestellten Ausführungsform sind der Regler 11, die Feldgeräte 15–22 und die E/A-Karten 26, 28 drahtgebundene Geräte und die Feldgeräte 40–46 sind drahtlose Feldgeräte.
Darüber hinaus können das eine oder die mehreren tragbaren industriellen Geräte 112, welche Feldgeräte-Wartungswerkzeuge, Multimeter, tragbare Schleifenstromversorgungen, Feldgeräte-Konfigurationswerkzeuge usw. sein können, intermittierend kommunikativ mit einem oder mehreren der Feldgeräte 15–22, 40–50 und/oder mit einem oder mehreren der Busse oder Kommunikationsleitungen verbunden sein, mit denen die Feldgeräte 15–22, 40–50 verbunden sind (z. B. eine HART-Schleife, ein Fieldbus-Segment usw.), wobei solche Verbindungen in 1 mit gestrichelten Linien dargestellt sind. Solche Netzwerkverbindungen können jene festverdrahteten Leitungen umfassen, welche ein oder mehrere der Feldgeräte 15–22, 40–50 mit den E/A-Karten 26 und 28 beispielsweise über das Backbone 105 verbinden. Alternativ können die tragbaren industriellen Geräte 112 kommunikativ direkt mit denjenigen der Feldgeräte 15–22, 40–50 (z. B. über auf den Feldgeräten 15–22, 40–50 vorhandene Kommunikationsanschlüsse) verbunden sein. In einigen Fällen können die tragbaren industriellen Geräte 112 dem Feldgerät 15–22, 40–50 oder der Drahtschleife, mit der es verbunden ist, Strom zuführen. Darüber hinaus können die tragbaren industriellen Geräte 112 einem Benutzer ermöglichen, mit einem oder mehreren der Feldgeräte 15–22, 40–50 zu kommunizieren, sie zu konfigurieren, Wartungsaktivitäten an ihnen durchzuführen und/oder sie zu diagnostizieren, wenn diese Feldgeräte in der Betriebsanlage installiert sind. In noch anderen Fällen können die tragbaren industriellen Geräte 112 drahtlose Schnittstellen umfassen, die verwendet werden können, um drahtlos mit einem oder mehreren der Feldgeräte 15–22, 40–50, beispielsweise einer Bluetooth-Schnittstelle, einer WLAN-Schnittstelle oder einer drahtlosen Prozesskontrollprotokollschnittstelle oder -verbindung wie jenen, die das WirelessHART-Protokoll anwenden, verbunden zu werden. Die in dieser Schrift beschriebenen tragbaren industriellen Geräte 112 werden allgemein als zum Konfigurieren, Unterstützen und Warten von Feldgeräten beschrieben und sind somit als Feldgerätekommunikatoren dargestellt, die beispielsweise für Prozessmessvorrichtungen wie Druck-, Temperatur-, Füllstand-, Strömungs-Analysensensoren, Durchflussmesser, Ventilstellungsvorrichtungen usw. verwendet werden können. Jedoch können die tragbaren industriellen Geräte 112 eingesetzt werden, um andere Arten von Vorrichtungen, einschließlich beispielsweise rotierende Vorrichtungen, Vibrationserkennungsgeräte und Auswertegeräte, Stromerzeugungsanlagen, Schalter, Motoren, Pumpen, Kompressoren, Antriebe, mechanische Gefäße wie Tanks, Rohre usw., Stromverteilungsgeräte, Schaltanlagen, Motorsteuerzentralen, andere eigenständige Geräte (beispielsweise nicht kommunikativ mit einem Prozessregler verbundene Geräte) oder andere Arten von Industrieausrüstungen zu unterstützen, mit ihnen verbunden zu werden, zu warten, mit ihnen zu kommunizieren oder anderweitig mit ihnen angewendet zu werden. In diesen Fällen könnten die tragbaren industriellen Geräte 112 verschiedene Arten von Kommunikations- und elektrischer Erzeugungs- und Erfassungshardware (z. B. Spannungs-, Strom-, Impedanz- usw. -erzeugungs und -erfassungsausrüstung) aufweisen, um eine Wartung an, Konfiguration von und/oder Kommunikation mit, diesen anderen Arten von Industrieausrüstungen durchzuführen.
In einigen Ausführungsformen kann das tragbare industrielle Rechengerät 112 an den Standort eines der Feldgeräte 15–22, 40–50 in der Prozessanlage gebracht werden. Das tragbare industrielle Rechengerät 112 kann vorübergehend über eine drahtgebundene und/oder eine drahtlose Verbindung mit dem Feldgerät 15–22, 40–50 zur Kalibrierung, Konfiguration, Fehlersuche, Überwachung, Steuerung oder Ausführung beliebiger anderer geeigneter Operationen auf dem Feldgerät 15–22, 40–50 verbunden sein. Daneben kann das tragbare industrielle Rechengerät 112 vorübergehend über eine drahtgebundene und/oder eine drahtlose Verbindung mit dem Regler 11 zur Kalibrierung, Konfiguration, Fehlersuche, Überwachung, Steuerung oder Ausführung beliebiger anderer geeigneter Operationen auf dem Regler 11 verbunden sein.
Im Betrieb der industriellen Rechengeräte 112, 113 können die industriellen Rechengeräte 112, 113 in einigen Ausführungsformen jeweils eine Benutzerschnittstelle ausführen, die es dem industriellen Rechengerät 112, 113 ermöglicht, eine Eingabe über eine Eingabeschnittstelle zu akzeptieren und eine Ausgabe an eine Anzeige zu liefern. Das industrielle Rechengerät 112, 113 kann Daten (z. B. prozessbezogene Daten wie Prozessparameter, Berechtigungen, Protokolldaten, Sensordaten und/oder beliebige anderen Daten, die erfasst und gespeichert werden können) von dem Server 150 empfangen. In anderen Ausführungsformen kann die Benutzerschnittstelle ganz oder teilweise an dem Server 150 ausgeführt werden, wobei der Server 150 Anzeigedaten an das industrielle Rechengerät 112, 113 übertragen kann. Das industrielle Rechengerät 112, 113 kann über das Backbone 105 von anderen Knoten oder Endpunkten in dem Prozesssteuerungsnetzwerk 100 wie dem Regler 11, dem drahtlosen Gateway 35, anderen industriellen Rechengeräten oder dem Server 150 Benutzerschnittstellendaten empfangen (diese können Anzeigedaten und Berechtigungsdaten umfassen).
In einigen Ausführungsformen können Berechtigungen an dem Server 150 durch einen Systemadministrator beispielsweise im Rahmen eines Registrierungsprozesses für jedes industrielle Rechengerät 112 erzeugt werden. Jede Berechtigung kann eine Zugriffsebene auf ein bestimmtes Prozesssteuerungsgerät spezifizieren beispielsweise einen schreibgeschützten Zugriff, Lese-/Schreibzugriff, Zugriff auf Kalibrierfunktionen, Zugriff auf Konfigurationsfunktionen usw. Der Systemadministrator kann auch Berechtigungen für Benutzer und industrielle Rechengeräte 112, 113 in der Prozessanlage zuordnen. In einigen Ausführungsformen kann der Server 150 kommunikativ mit einer oder mehreren Datenbanken gekoppelt sein, die Angaben zu Berechtigungen, berechtigten Benutzern innerhalb der Prozessanlage, industriellen Rechengeräten innerhalb der Prozessanlage und Zuordnungen zwischen den Berechtigungen, Benutzern und industriellen Rechengeräten speichern. Die Berechtigungen sowie Angaben der entsprechenden Benutzer und industriellen Rechengeräte, die den einzelnen Berechtigungen zugeordnet sind, können an das industrielle Rechengerät 112, 113 übermittelt werden.
Dementsprechend kann das industrielle Rechengerät 112, 113 ein Berechtigungsniveau bestimmen, das der Benutzer für ein Prozesssteuerungsgerät besitzt, welches mit dem industriellen Rechengerät 112, 113 unter Verwendung der dem Benutzer und/oder dem industriellen Rechengerät 112, 113 zugeordneten Berechtigungen im Rahmen der Registrierung des Gerätes 112, 113 mit dem Prozesssteuerungsnetzwerk 100 verbunden ist. Wie in dieser Schrift verwendet, kann sich eine Berechtigungsebene für einen Benutzer auf eine kombinierte Zugriffsebene beziehen, die der Benutzer auf Prozesssteuerungsgeräte innerhalb der Prozessanlage besitzt. Die kombinierte Zugriffsebene kann auf einem Satz von Berechtigungen basieren, die dem Benutzer und/oder dem industriellen Rechengerät 112 zugeordnet sind, wobei jede Berechtigung eine Zugriffsebene auf ein bestimmtes Prozesssteuerungsgerät festlegt. In einigen Ausführungsformen kann sich auch eine Berechtigungsebene für einen Benutzer auf eine kombinierte Zugriffsebene beziehen, die der Benutzer für ein bestimmtes Prozesssteuerungsgerät besitzt. Die kombinierte Zugriffsebene kann auf jeder der dem Benutzer und/oder dem industriellen Rechengerät 112, 113 zugeordneten Berechtigungen beruhen, die eine Zugriffsebene auf das jeweilige Prozesssteuerungsgerät festlegen.
Auf der Grundlage von am industriellen Rechengerät 112, 113 empfangenen Benutzerdaten liefert das industrielle Rechengerät 112, 113 eine Ausgabe (d. h., visuelle Darstellungen oder Grafiken), die anzeigt, ob der Benutzer authentifiziert ist und ob der Benutzer berechtigt ist, auf ein bestimmtes Prozesssteuerungsgerät oder eine bestimmte Funktion zuzugreifen, die am Prozesssteuerungsgerät durchgeführt wird. Beispielsweise kann das industrielle Rechengerät 112, 113 eine ID-Scan-Anzeige bereitstellen, die den Benutzer auffordert, einen elektronischen Identitätsausweis zu scannen. Das industrielle Rechengerät 112, 113 kann auch eine Benutzeranmeldungsanzeige bereitstellen, die den Benutzer auffordert, einen Benutzernamen und ein Kennwort einzugeben. Ebenso kann der Benutzer die Steuerung des Prozesses beeinflussen, indem er am industriellen Rechengerät 112, 113 eine Eingabe vornimmt. Zum Beispiel kann das tragbare industrielle Rechengerät 112 Angaben zu Prozessparametern liefern, die von einer Prozesssteuerungsvorrichtung gemessen werden, welche mit dem tragbaren industriellen Rechengerät 112 verbunden ist. Der Benutzer kann mit dem tragbaren industriellen Rechengerät 112 interagieren, um die vom Prozesssteuerungsgerät genommenen Messungen zu kalibrieren.
In bestimmten Ausführungsformen kann das industrielle Rechengerät 112, 113 jede Art von Client implementieren, beispielsweise einen Thin Client, einen Webclient oder einen Thick Client. Beispielsweise kann das industrielle Rechengerät 112, 113 für den Großteil der Verarbeitung von anderen Knoten, Computern, industriellen Rechengeräten oder Servern abhängen, die für den Betrieb des industriellen Rechengerätes 112, 113 erforderlich sind, wie dies der Fall sein könnte, wenn Speicher, Batterieleistung usw. des industriellen Rechengerätes (z. B. in einer tragbaren Vorrichtung) begrenzt sind. In einem solchen Beispiel kann das industrielle Rechengerät 112, 113 mit dem Server 150 oder mit einem anderen industriellen Rechengerät kommunizieren, wobei der Server 150 oder das andere industrielle Rechengerät mit einem oder mehreren anderen Knoten (z. B. Servern) im Prozesssteuerungsnetzwerk 100 kommuniziert und die Anzeigedaten, die Berechtigungsdaten und/oder die Prozessdaten bestimmen kann, die an das industrielle Rechengerät 112, 113 übertragen werden sollen. Außerdem kann das industrielle Rechengerät 112, 113 beliebige Daten übermitteln, die sich auf die empfangene Benutzereingabe am Server 150 beziehen, so dass der Server 150 die mit der Benutzereingabe zusammenhängenden Daten verarbeiten und entsprechend operieren kann. Anders ausgedrückt, macht das industrielle Rechengerät 112, 113 wenig mehr, als Graphiken darzustellen und als ein Portal für einen oder mehrere Knoten oder Server zu dienen, welche die Daten speichern und die für den Betrieb des industriellen Rechengerätes 112, 113 notwendigen Routinen ausführen. Ein industrielles Thin-Clien-Rechengerät bietet den Vorteil minimaler Hardwareanforderungen an das industrielle Rechengerät 112, 113.
In anderen Ausführungsformen kann das industrielle Rechengerät 112, 113 ein Web-Client sein. In einer solchen Ausführungsform kann ein Benutzer des industriellen Rechengerätes 112, 113 mit dem Prozessleitsystem über einen Browser am industriellen Rechengerät 112, 113 interagieren. Der Browser ermöglicht dem Benutzer, auf Daten und Ressourcen auf einem anderen Knoten oder Server (beispielsweise auf dem Server 150) über das Backbone 105 zuzugreifen. Beispielsweise kann der Browser Daten, z. B. Anzeigedaten, Berechtigungsdaten oder Prozessparameterdaten, vom Server 150 empfangen, so dass der Browser Grafiken zur Steuerung und/oder Überwachung eines Teils oder des gesamten Prozesses abbilden kann. Der Browser kann auch Benutzereingaben (z. B. einen Mausklick auf eine Grafik) empfangen. Die Benutzereingabe kann dazu führen, dass der Browser eine auf dem Server 150 gespeicherte Informationsressource abruft oder darauf zugreift. Beispielsweise kann der Mausklick dazu führen, dass der Browser (beim Server 150) Informationen abruft und anzeigt, die sich auf die angeklickte Grafik beziehen.
In noch anderen Ausführungsformen kann der Großteil der Verarbeitung für das industrielle Rechengerät 112, 113 am industriellen Rechengerät 112, 113 stattfinden. Beispielsweise kann das industrielle Rechengerät 112, 113 eine Berechtigungsebene für den Benutzer bestimmen. Das industrielle Rechengerät 112, 113 kann Daten auch lokal speichern, aufrufen und analysieren.
Im Betrieb kann ein Benutzer mit dem industriellen Rechengerät 112, 113 interagieren, um eine oder mehrere Vorrichtungen in dem Prozesssteuerungsnetzwerk 100 wie etwa eines der Feldgeräte 15–22, 40–50 oder den Regler 11 zu analysieren, zu überwachen, zu konfigurieren, zu kalibrieren, zu steuern oder einen Fehler am Gerät zu beheben. Der Benutzer kann auch mit dem tragbaren industriellen Rechengerät 112 interagieren, um beispielsweise einen Parameter zu modifizieren oder zu ändern, der mit einer im Regler 11 gespeicherten Steuerroutine verbunden ist. Der Prozessor 30 des Reglers 11 implementiert oder beaufsichtigt eine oder mehrere Prozesssteuerroutinen (die in dem Speicher 32 gespeichert sind), welche Steuerschleifen umfassen können. Der Prozessor 30 kann mit den Feldgeräten 15–22 und 40–50 und mit anderen Knoten kommunizieren, die kommunikativ mit dem Backbone 105 verbunden sind. Anzumerken ist, dass beliebige in dieser Schrift beschriebene Steuerroutinen oder -module (einschließlich Qualitätsvorhersage- und Fehlererfassungsmodule oder -funktionsblöcke) veranlassen können, dass Teile davon von unterschiedlichen Reglern oder anderen Geräten implementiert oder ausgeführt werden, falls dies gewünscht ist. Ebenso können die in dieser Schrift beschriebenen Steuerroutinen oder -module, die innerhalb des Prozessleitsystems implementiert werden sollen, beliebige Formen wie Software, Firmware, Hardware usw. annehmen. Steuerroutinen können in jedem gewünschten Softwareformat implementiert werden, beispielsweise durch Verwendung objektorientierter Programmierung, Leiterlogik, sequentieller Funktionsdiagramme, Funktionsblockdiagramme oder beliebiger anderer Softwareprogrammiersprachen oder Designparadigmen. Insbesondere können die Steuerroutinen von einem Benutzer durch das industrielle Rechengerät 112, 113 implementiert werden. Die Steuerroutinen können in jedem beliebigen Speichertyp gespeichert sein, wie z. B. in einem Direktzugriffsspeicher (RAM) oder Nur-Lese-Speicher (ROM). Ebenso können die Steuerroutinen beispielsweise in einem oder mehreren EPROMs, EEPROMs, anwendungsspezifischen integrierten Schaltungen (ASICs) oder anderen Hardware- oder Firmware-Elementen hartcodiert werden. Somit kann der Regler 11 (durch einen Benutzer, der ein industrielles Rechengerät 112, 113 in bestimmten Ausführungsformen verwendet) konfiguriert werden, um eine Steuerstrategie oder Steuerroutine in jeder gewünschten Weise umzusetzen.
Nach wie vor auf 1 verweisend, kommunizieren die drahtlosen Feldgeräte 40–46 in einem drahtlosen Netzwerk 70 unter Verwendung eines drahtlosen Protokolls, wie beispielsweise des Wireless HART-Protokolls. In bestimmten Ausführungsformen kann das industrielle Rechengerät 112, 113 in der Lage sein, mit den drahtlosen Feldgeräten 40–46 unter Verwendung des drahtlosen Netzwerks 70 zu kommunizieren. Solche drahtlosen Feldgeräte 40–46 können direkt mit einem oder mehreren anderen Knoten des Prozesssteuerungsnetzwerks 100 kommunizieren, welche auch für die drahtlose Kommunikation (z. B. mit dem drahtlosen Protokoll) ausgebildet sind. Um mit einem oder mehreren anderen Knoten zu kommunizieren, die für die drahtlose Kommunikation nicht konfiguriert sind, können die drahtlosen Feldgeräte 40–46 ein drahtloses Gateway 35 benutzen, das mit dem Backbone 105 verbunden ist. Natürlich könnten die Feldgeräte 15–22 und 40–46 mit beliebigen anderen Normen oder Protokollen konform sein, etwa drahtgebundenen oder drahtlosen Protokollen, einschließlich aller in Zukunft entwickelten Standards oder Protokolle.
Das drahtlose Gateway 35 ist ein Beispiel für eine Provider-Vorrichtung, die Zugriff auf verschiedene drahtlose Geräte 40–58 eines drahtlosen Kommunikationsnetzwerks 70 bieten kann. Insbesondere stellt das drahtlose Gateway 35 eine kommunikative Kopplung zwischen den drahtlosen Geräten 40–58 und anderen Knoten des Prozesssteuerungsnetzwerks 100 (einschließlich des Reglers 11 von 1A) her. Das drahtlose Gateway 35 stellt eine kommunikative Kopplung in einigen Fällen durch die Routing-, Puffer- und Zeitsteuerungsdienste bereit, um die Schichten der drahtgebundenen und drahtlosen Protokollstapel (z. B. Adressumsetzung, Routing, Paketsegmentierung, Priorisierung usw.) zu senken, während ein Tunneling einer gemeinsamen Schicht oder gemeinsamer Schichten der drahtgebundenen und drahtlosen Protokollstapel erfolgt. In anderen Fällen kann das drahtlose Gateway 35 Befehle zwischen drahtgebundenen und drahtlosen Protokollen übersetzen, die keine gemeinsamen Protokollschichten haben.
Ähnlich den drahtgebundenen Feldgeräten 15–22 können die drahtlosen Feldgeräte 40–46 des drahtlosen Netzwerks 70 physische Steuerungsfunktionen innerhalb der Prozessanlage 10 ausführen (z. B. Öffnen oder Schließen von Ventilen oder Messungen von Prozessparametern). Die drahtlosen Feldgeräte 40–46 sind jedoch so ausgebildet, dass sie unter Verwendung des drahtlosen Kommunikationsprotokolls des Netzwerks 70 kommunizieren, während das drahtgebundene Feldgerät 15–22 konfiguriert ist, um unter Verwendung eines drahtgebundenen Kommunikationsprotokolls (z. B. HART^®, FOUNDATION^® Fieldbus usw.) zu kommunizieren. Als solches sind die drahtlosen Feldgeräte 40–46, das drahtlose Gateway und andere drahtlose Knoten 52–58 des drahtlosen Netzwerks 70 Erzeuger und Verbraucher drahtloser Kommunikationspakete, während die drahtgebundenen Feldgeräte 15–22 Erzeuger und Verbraucher drahtgebundener Kommunikationspakete sind.
In einigen Szenarien kann das drahtlose Netzwerk 70 Nicht-Drahtlosgeräte umfassen. Beispielsweise kann ein Feldgerät 48 von 1A ein 4- bis 20-mA-Altgerät sein, und ein Feldgerät 50 kann ein herkömmliches, drahtgebundenes HART-Gerät sein. Um innerhalb des Netzwerks 70 zu kommunizieren, können die Feldgeräte 48 und 50 mit dem drahtlosen Kommunikationsnetzwerk 70 über einen drahtlosen Adapter 52a oder 52b verbunden sein. Zusätzlich können die drahtlosen Adapter 52a, 52b andere Kommunikationsprotokolle wie beispielsweise FOUNDATION^®-Fieldbus, PROFIBUS, DeviceNet usw. unterstützen. Des Weiteren kann das drahtlose Netzwerk 70 einen oder mehrere Netzwerkzugangspunkte 55a, 55b umfassen, die separate physische Vorrichtungen sein können, welche mit dem drahtlosen Gateway 35 in drahtgebundener Kommunikation stehen, oder es kann mit dem drahtlosen Gateway 35 als integralem Gerät versehen sein. Das drahtlose Netzwerk 70 kann auch einen oder mehrere Router 58 umfassen, um Pakete von einem drahtlosen Gerät zu einem anderen drahtlosen Gerät innerhalb des drahtlosen Kommunikationsnetzwerks 70 weiterzuleiten. Die drahtlosen Geräte 32–46 und 52–58 können miteinander und mit dem drahtlosen Gateway 35 über drahtlose Verbindungen 60 des drahtlosen Kommunikationsnetzwerkes 70 kommunizieren.
In bestimmten Ausführungsformen kann das Prozesssteuerungsnetzwerk 100 andere mit dem Netzwerk-Backbone 105 verbundene Knoten umfassen, die unter Verwendung anderer drahtloser Protokolle kommunizieren. Beispielsweise kann das Prozesssteuerungsnetzwerk 100 einen oder mehrere drahtlose Zugangspunkte 72 umfassen, die andere drahtlose Protokolle wie WLAN oder andere IEEE 802.11 – kompatible drahtlose lokale Netzwerkprotokolle, mobile Kommunikationsprotokolle wie WiMAX (Worldwide Interoperability for Microwave Access), LTE (Long Term Evolution) oder andere ITU-R-(International Telecommunication Union Radiocommunication Sector)-kompatible Protokolle, kurzwellige Funkkommunikation wie Nahfeldkommunikation (NFC) und Bluetooth oder andere drahtlose Kommunikationsprotokolle nutzen. In der Regel erlauben solche drahtlosen Zugangspunkte 72, dass Handheld- oder andere tragbare Rechengeräte (z. B. tragbare industrielle Rechengeräte 112) über ein jeweiliges drahtloses Netzwerk kommunizieren, das sich von dem drahtlosen Netzwerk 70 unterscheidet und das ein anderes drahtloses Protokoll als das drahtlose Netzwerk 70 unterstützt. Beispielsweise kann ein tragbares industrielles Rechengerät 112 eine mobile Workstation oder ein Diagnoseprüfgerät sein, die/das von einem Benutzer innerhalb der Prozessanlage verwendet wird. In einigen Ausführungsformen kommuniziert das industrielle Rechengerät 112, 113 über das Prozesssteuerungsnetzwerk 100 unter Verwendung eines drahtlosen Zugangspunkts 72. In einigen Szenarien können zusätzlich zu tragbaren Rechengeräten eine oder mehrere Prozesssteuerungsvorrichtungen (z. B. Regler 11, verdrahtete Feldgeräte 15–22 oder drahtlose Geräte 35, 40–58) auch unter Verwendung des von den Zugangspunkten 72 unterstützten drahtlosen Netzwerks kommunizieren.
Obwohl 1 einen einzelnen Regler 11 mit einer endlichen Anzahl von Feldgeräten 15–22, 40–50 abbildet, ist dies nur eine beispielhafte und nicht-einschränkende Ausführungsform. Eine beliebige Anzahl von Reglern 11 kann in den Provider-Geräten des Prozesssteuerungsnetzwerks 100 enthalten sein, und jeder der Regler 11 kann mit einer beliebigen Anzahl drahtgebundener oder drahtloser Feldgeräte 15–22, 40–50 kommunizieren, um einen Prozess in der Betriebsanlage 10 zu steuern. Darüber hinaus kann die Prozessanlage 10 auch beliebig viele drahtlose Gateways 35, Router 58, Zugangspunkte 55, 72, tragbare industrielle Rechengeräte 112, stationäre industrielle Rechengeräte 113 und/oder drahtlose Prozesssteuerungs-Kommunikationsnetzwerke 70 umfassen.
In einigen Ausführungsformen kann der Server 150 als Enrollment-Server zum Registrieren und Anmelden industrieller Rechengeräte 112, 113 in einem Prozesssteuerungs-Messaging-Dienst dienen. Das heißt, wo das Prozesssteuerungsnetzwerk 100 eine Kommunikation zwischen verschiedenen industriellen Rechengeräten 112, 113, Servern 150 usw. zulässt, kann ein Prozesssteuerungs-Messaging-Netzwerk logisch von dem Prozesssteuerungsnetzwerk 100 isoliert sein, um eine interne Kommunikation unter und zwischen den industriellen Rechengeräten 112, 113 zu ermöglichen, die einen Prozesssteuerungs-Messaging-Dienst benutzen. Der Prozesssteuerungs-Messaging-Dienst ist eine Gruppierung von Infrastrukturdiensten und Funktionsmöglichkeiten, die im physischen Prozesssteuerungsnetzwerk 100 auf verteilte Weise eingesetzt, logisch jedoch von dem digitalen Kommunikationssteuerungskanal oder der Verbindung isoliert sind, der/die für die Kommunikation zwischen dem Regler 11 und den Feldgeräten 15–52 verwendet wird. Der Prozesssteuerungs-Messaging-Dienst ermöglicht eine sichere, zuverlässige, schnelle/reaktionsfreudige Kommunikation, Nachrichtenzustellung, Datenübertragung und andere Operationen zwischen IT-Systemen, Personal Computern und industriellen Geräten 112, 113. Dabei ermöglicht der Prozesssteuerungs-Messaging-Dienst eine Anzahl anderer vernetzter Funktionsmöglichkeiten, allen voran eine Kommunikation zwischen einem industriellen Rechengerät 112, 113 und einem Feldgerät 15–50 über ein Asset-Management-System, eine Datensynchronisierung zwischen einem industriellen Rechengerät 112, 113 und einem Asset-Management-System, Feldgeräte-Zugriffssteuerung von einem industriellen Rechengerät 112, 113 aus sowie ein Flottenmanagement industrieller Rechengeräte 112, 113, insbesondere tragbarer industrieller Rechengeräte 112. Der Prozesssteuerungs-Messaging-Dienst ersetzt andere IT-Netzwerk- und Sicherheitssysteme und -dienste nicht, sondern erweitert diese IT-Funktionsmöglichkeiten und bietet eine weitere Schicht von Sicherheit/Autorisierung, Diensten und Funktionsmöglichkeiten, die auf die in einem Prozessleitsystem benötigten Arten von Funktionsmöglichkeiten anwendbar sind.
2 ist ein Blockdiagramm eines beispielhaften Prozesssteuerungs-Messaging-Netzwerks 200, das in einem Prozessleitsystem oder einer Prozessanlage 10 (oder einem anderen industriellen Umfeld oder einer anderen industriellen Umgebung) abläuft. Insbesondere kann das Prozesssteuerungs-Messaging-Netzwerk 200 eine Vielzahl tragbarer industrieller Rechengeräte 112a–112e wie Laptop-Computer, Tablet-Computer und Handgeräte zur Feldkommunikation wie auch eine Vielzahl stationärer industrieller Geräte 113a–113c wie Personal Computer und Workstations umfassen. Die verschiedenen industriellen Rechengeräte 112a–112e, 113a–113c können direkt oder indirekt über ein oder mehrere Netzwerk-Backbones 202, 204, 206 verbunden sein. Jedes Backbone 202–206 kann unterschiedlichen Netzwerkebenen innerhalb des Prozessleitsystems entsprechen. Beispielsweise umfasst das Betriebsanlagennetzwerk- und -kommunikationssystem 10 zusätzlich einen Satz von miteinander verbundenen Kommunikationsnetzwerken am Betriebsanlagenstandort (oder an mehreren Betriebsanlagenstandorten). Insbesondere umfassen die in 2 dargestellten Betriebsanlagennetzwerke ein Top-Level- oder Unternehmensnetzwerk 202, ein Verwaltungsnetzwerk auf Betriebsanlagenebene 203 und ein Gerätenetzwerk auf Betriebsanlagenebene 204, das mit einem oder mehreren Steuerungsnetzwerken 206 verbunden ist (von denen nur eines in 2 dargestellt ist). Wie zu verstehen ist, können das Betriebsanlagennetzwerk 204 und das Steuerungsnetzwerk 206 das Netzwerk 105 und die damit verbundenen Subnetzwerke zur Unterstützung der in 1 dargestellten Feldgeräte 15–50 bilden. Das Prozesssteuerungs-Messaging-Netzwerk 200 umfasst ein externes Servernetzwerk 210 oder ist mit einem solchen verbunden, das sich an einem (zur Betriebsanlage oder anderen industriellen Umgebung) externen Ort, beispielsweise in der Cloud, befinden kann.
Wie in 2 dargestellt, umfasst das Unternehmensnetzwerk 202 einen Satz von Geschäftscomputern, Workstations oder anderen geschäftlichen stationären industriellen Rechengeräten 113a–113c, die Geschäftsanwendungen, Buchhaltungsprogramme, Planungsaufgaben usw. umsetzen können, und dieses Netzwerk 202 ist über eine Firewall-Vorrichtung 230 mit dem externen Server-System oder -Netzwerk 210 verbunden. Ebenso ist das Unternehmensnetzwerk 202 mit dem Verwaltungsnetzwerk 203 und mit dem Betriebsanlagennetzwerk 204 über ein DMZ-Gerät oder -System 240 verbunden, das als Netzwerk-zu-Netzwerk-Vermittler dient. Allgemein gesprochen umfasst das Unternehmensnetzwerk 202 mehrere Workstations 113a–113c, die mit einer Kommunikationsverbindung 242 verbunden sind, welche mit jedem geeigneten Kommunikationsstandard, beispielsweise dem Ethernet-Standard IEEE 802.3, vereinbar ist. Wie es üblich ist, teilen sich die Workstations 113a–113c ein Betriebssystem mit Netzwerkfähigkeiten wie das von der Microsoft Corporation hergestellte Windows^TM. Benutzer in verschiedenen Organisationsrollen betreiben die Workstations 113a–113c, um die täglichen Aktivitäten innerhalb der Betriebsanlage, beispielsweise die eines Betriebsanlagenbetreibers, die Unternehmenssysteme, welche die Betriebsanlage verwalten usw., durchzuführen. Zum Beispiel kann der Betriebsanlagenbetreiber Ingenieure, Buchhalter, Marketing-Mitarbeiter und anderes Personal einstellen. Benutzer, die die Workstations 113a–113c betreiben, können einen bestimmten Satz von Berechtigungen haben, die es in der Regel nicht zulassen, dass diese Benutzer auf das Prozessanlagennetzwerk 204 oder das Prozesssteuerungsnetzwerk 206 zugreifen. Andererseits haben diese Benutzer einen weitgehend uneingeschränkten Zugriff auf Hosts im Internet und damit ein relativ hohes Risiko der Gefährdung durch Viren, Malware, Hijacking-Versuche und anderen Cyber-Bedrohungen.
Ebenso enthält das Verwaltungsnetzwerk 203 verschiedene Computer oder Workstations, die über eine Kommunikationsverbindung 244 verbunden sind, welche mit jedem geeigneten Kommunikationsstandard, beispielsweise dem Ethernet-Standard IEEE 802.3, konform ist. Einer oder mehrere der Personal Computer, Workstations oder anderen stationären industriellen Rechengeräte, die als eine Workstation 246 in 2 dargestellt sind, können als eine Flottenmanagementstation dienen, welche ein lokales Content-Repository 247 enthält oder mit diesem verbunden ist, das lokalen Inhalt für verschiedene der tragbaren industriellen Rechengeräte in der Betriebsanlage speichert. Ebenso kann das Verwaltungsnetzwerk 203 einen oder mehrere Prozesssteuerungs-Messagingnetzwerk-Zugangspunkte 208a umfassen, welche drahtlose Zugangspunkte sein können, die einem oder mehreren tragbaren industriellen Rechengeräten 112a–112c (jeweils mit einer drahtlosen Schnittstelle) ermöglichen, eine Verbindung zu dem Netzwerk 203 auf drahtlose Art herzustellen und sich so mit der Workstation 246 für Übertragungen großer Dateien, Messaging usw. zu verbinden, wie es in dieser Schrift eingehender beschrieben ist.
In ähnlicher Weise umfasst das Betriebsanlagennetzwerk 204, welches das Netzwerk 100 von 1 sein kann, verschiedene Computer oder Workstations 260, Datenarchive 262 usw., die Beispiele für stationäres Anlagevermögen oder stationäre Geräte sind, welche über eine Kommunikationsverbindung 264 verbunden sind, die mit jedem geeigneten Kommunikationsstandard, beispielsweise dem Ethernet-Protokoll IEEE 802.3, konform sind. Das Netzwerk 204 ist über einen Zugangspunkt 266, der beispielsweise eine Firewall oder eine Steuereinrichtung sein kann, mit dem Prozesssteuerungsnetzwerk 206 verbunden. Im Allgemeinen können die Workstations 260 Bediener-Workstations sein, die es den Prozess- oder Steuerungsbedienern ermöglichen, die laufenden Operationen der Geräte in dem Prozesssteuerungsnetzwerk 206 (beispielsweise Regler, Feldgeräte usw.) einzusehen und zu steuern, um Betriebsanlagen- oder Online-Steuerungsoperationen durchzuführen. Diese Workstations 260 können verschiedene unterschiedliche Anwendungen umfassen und ausführen, die es Personal wie Bedienern und Wartungspersonal ermöglichen, verschiedene Analysen von Steuerungsanlagen wie Feldgeräte und anderen Arten von Anlagegütern, wie z. B. von rotierenden Vorrichtungen, Vibrationsausrüstung, Stromerzeugungsanlagen usw., vorzunehmen. Wie in 2 dargestellt, können eine oder mehrere der stationären industriellen Rechengeräte, die als Workstation 268 dargestellt sind, als eine Flottenmanagementstation dienen, die ein lokales Content-Repository 270 enthält oder mit diesem verbunden ist, welches lokalen Inhalt für verschiedene der tragbaren industriellen Rechengeräte 112d–112f in der Betriebsanlage speichert. Falls gewünscht, kann die Workstation 268 zur Aufgabe haben, lokalen Inhalt zu verwalten, und das lokale Content-Repository 270 kann lokalen Inhalt für verschiedene der stationären industriellen Rechengeräte ebenso oder an ihrer Stelle speichern. Ebenso kann das Betriebsanlagennetzwerk 204 einen oder mehrere Prozesssteuerungs-Messagingnetzwerk-Zugangspunkte 208b umfassen, welche drahtlose Zugangspunkte sein können, die einem oder mehreren tragbaren industriellen Rechengeräten 112d–112f (jeweils mit einer drahtlosen Schnittstelle) ermöglichen, eine Verbindung zu dem Netzwerk 204 herzustellen und sich so mit der Workstation 268 für Übertragungen großer Dateien, Messaging usw. zu verbinden, wie es in dieser Schrift eingehender beschrieben ist. Die tragbaren industriellen Rechengeräte 112a–112f können mehrere Vorrichtungen desselben Typs (z. B. Feldkommunikatoren, Oszilloskope, Amperemeter usw.) umfassen und können Vorrichtungen verschiedener Typen sowie Vorrichtungen verschiedener Hersteller oder Vorrichtungen mit unterschiedlichen Funktionsmöglichkeiten umfassen.
Wie erkenntlich ist, kann das Steuerungsnetzwerk 206 verschiedene Steuereinrichtungen und Sub-Netzwerke umfassen, wie beispielsweise Regler, Eingabe/Ausgabe-(E/A)-Geräte und Feldgeräte, die über proprietäre oder Prozesssteuerungsnetzwerke wie HART, FOUNDATION Fieldbus, Profibus, CAN und andere Netzwerke verbunden sind, und diese Sub-Netzwerke können jedes gewünschte Prozessleitprotokoll anwenden. Allgemein gesprochen können die tragbaren industriellen Rechengeräte 112a–112f verwendet werden, um Wartungs-, Kassen-, Reparatur-, Prüf-, Kalibrierungs- und Konfigurationsaktivitäten auf diesen Geräten und Sub-Netzwerken durchzuführen. Ebenso kann die Betriebsanlage oder andere industrielle Umgebung andere darin angeordnete Arten von Vorrichtungen umfassen, wie z. B. Schwingungsanalyse- und Überwachungsgeräte, rotierende Vorrichtungen, Stromerzeugungsanlagen usw., die in 2 nicht dargestellt sind, die jedoch unter Verwendung einer oder mehrerer tragbarer industrieller Rechengeräte 112a–112f gewartet, gepflegt, installiert, repariert, geprüft, kalibriert usw. werden können.
Zusätzlich können Kombinationen von Prozesssteuerungs-Messaging-Zugangspunkten 208a–208c auf jedem Netzwerk 202–206 für die direkte oder indirekte Verbindung zwischen den industriellen Rechengeräten 112a–112e, 113a–113c, 246, 268 verteilt werden, um auf das Prozesssteuerungs-Messaging-Netzwerk 200 zuzugreifen (d. h., sich darin zu registrieren und/oder anzumelden) und ihrerseits wiederum auf Prozesssteuerungs-Messaging-Dienste zugreifen. Allgemein gesprochen sind diese Zugangspunkte 208a–208c zumindest logisch von den Zugangspunkten 55a, 55b und dem drahtlosen Gateway 35 isoliert und in einigen Ausführungsformen sind sie von den Zugangspunkten 55a, 55b und dem drahtlosen Gateway 35 sowohl logisch als auch physisch isoliert. Anders ausgedrückt, können die Zugangspunkte 208a–208c in einigen Ausführungsformen dieselbe Hardware wie die Zugangspunkte 55a, 55b und das drahtlose Gateway 35 benutzen, obwohl in anderen Ausführungsformen die Zugangspunkte 208a–208c über ihre eigene, von den Zugangspunkten 55a, 55b und/oder dem drahtlosen Gateway 35 separate, Hardware verfügen. Obwohl in 2, wie auch in 1, nur einzelne von einigen der Vorrichtungen dargestellt sind, die mit den Netzwerk-Backbones 202–206 verbunden sind, versteht sich von selbst, dass jede der Vorrichtungen mehrere Instanzen auf den Netzwerk-Backbones 202–206 haben könnte und dass die Prozessanlage 10 für jede Netzwerkebene tatsächlich mehrere Netzwerk-Backbones 202–206 umfassen kann.
Die DMZ-Schicht oder das DMZ-Gerät 240 hat die Aufgabe, die Prozesssteuerungsschichten oder -netzwerke 204 und 206 sowie das Betriebsanlagennetzwerke oder Gerätenetzwerke der industriellen Umgebung und das Verwaltungsnetzwerk 203 vom Internet oder anderen externen Netzwerken oder öffentlichen Netzwerken, beispielsweise vom Unternehmens-LAN-Netzwerk 202 oder externen Netzwerk 210, zu isolieren. In dem beispielhaften Kommunikationssystem 10 von 2 ist die Betriebsanlagen-LAN-Schicht oder das Unternehmensnetzwerk 202 über eine(n) Router/Firewall 230 mit dem Internet oder einem anderen öffentlichen Netzwerk verbunden und die Betriebsanlagen-DMZ-Schicht 240 ist über eine(n) Router/Firewall als Teil der DMZ 240 mit der Betriebsanlagen-LAN-Schicht oder dem Unternehmensnetzwerk 200 verbunden.
Die Betriebsanlagen-DMZ 240 kann mehrere Server umfassen, beispielsweise einen Antiviren-Server, einen Datenserver und einen Datenarchiv-Server. Wie bekannt ist, stellt eine DMZ-Schicht 240 im Allgemeinen eine zusätzliche Sicherheit für lokale oder Betriebsanlagennetze, wie beispielsweise die Netzwerke 203, 204 und 206, dar, indem sie die direkte Exposition gegenüber einem größeren Netzwerk wie dem Internet auf lediglich einige Hosts (d. h. den Antiviren-Server, Datenserver und Datenarchiv-Server, einen DNS-Server, einen Webserver usw.) begrenzt. Es wird angemerkt, dass die DMZ-Schicht oder das -DMZ-Gerät 240 im Allgemeinen jede Zwischennetzwerkschicht sein kann, die die Sicherheit der Systeme 203, 204 und 206 verbessert, indem der gesamte eingehende und ausgehende Internetverkehr über einen oder mehrere Hosts geleitet wird, die Sicherheitsmerkmale implementieren, um die Kommunikation sicher zu gestalten. Zusätzlich zu dem Prozesssteuerungs-Messaging-Netzwerk 200 innerhalb des Prozessleitsystems oder der Prozessanlage 10 kann das Prozesssteuerungs-Messaging-Netzwerk 200 kommunikativ mit einer Computing-Cloud oder einem anderen externen System 210 an das Prozessleitsystem 10 gekoppelt sein, wobei das externe System 210 eigene IT-Systeme, Infrastruktur usw. einschließlich seiner eigenen Server 212 umfasst. In einigen Ausführungsformen kann das externe System 210 Speicher-, Analyse- und/oder Aktualisierungsdienste als einen dritten Teil für das Prozessleitsystem 10 bereitstellen. Beispielsweise kann das externe System 210 Informationen über die Konfiguration des Prozessleitsystems 10 pflegen, einschließlich des Hochladens von Informationen über die Konfiguration, Diagnose usw., von spezifischen Feldgeräten 15–52 von einzelnen der industriellen Rechengeräte 112a–112e, 113a–113c, 246, 268, Content-Downloads auf die industriellen Rechengeräte 112a–112e, 113a–113c, 246, 268 en masse oder auf einzelne der industriellen Rechengeräte, auf das Lizenz-Management usw.
Darüber hinaus umfasst das externe System 210 von 2 verschiedene Systeme und Komponenten, beispielsweise ein Endbenutzer-Repository 290, einen Notifizierer 292, einen Inhaltsentscheider 294 und einen Inhalts-Downloader 296, die im Allgemeinen zusammenarbeiten können, um den Inhalt zu bestimmen, der auf verschiedene der industriellen Rechengeräte 112a–112e, 113a–113c, 246, 268 heruntergeladen werden muss. Das System 210 kann auch ein oder mehrere Unternehmenssysteme oder Computer 299 enthalten. Die Unternehmenssysteme 299 können für den Kauf oder Erwerb neuer Inhalte für ein oder mehrere der tragbaren Geräte 112a–112e, 113a–113c, 246, 248 verwendet werden und können Hinweise auf einen solchen Kauf oder eine solche Lizenz in Form von Lizenzschlüsseln, Codes usw. liefern. In ähnlicher Weise umfassen die verschiedenen Firewall- und DMZ-Geräte 230 und 240 Programmiervorgänge oder Konfigurationen, die eine sichere Kommunikation zwischen den industriellen Rechengeräten und den Komponenten in dem externen Netzwerk 210 ermöglichen. Beispielsweise umfassen die Workstations 246 und 268 Kommunikations-Software, die es diesen Geräten ermöglicht, die DMZ- und Firewall-Geräte 230 und 240 zu navigieren, um über diese Geräte in einer gesicherten Weise mit dem externen Netzwerk 210 zu kommunizieren.
Genauer gesagt, können die tragbaren industriellen Rechengeräte 112a–112e Feldkommunikatoren, Kalibratoren und andere Arten von tragbaren Geräten umfassen, die in industriellen Umgebungen wie Industrieanlagen, Prozessanlagen, Ölquellen, Pumpstationen usw. zum Konfigurieren, zur Fehlerbehebung, zum Kalibrieren und Ausführen anderer Vorgänge auf Feldgeräten wie Prozessmessgeräten, Ventilen, Positionierern usw., sowie für andere Geräte oder Anlagen, die in industriellen Umgebungen verwendet werden, beispielsweise in rotierenden Vorrichtungen (z. B. Turbinen), Stromerzeugungsanlagen, Schwingungsanalyse- und -erkennungsgeräten usw., eingesetzt werden Natürlich können verschiedene Typen und Marken der industriellen tragbaren Geräte von denselben oder verschiedenen Herstellern hergestellt werden, und verschiedene der tragbaren industriellen Rechengeräte 112a–112e können unterschiedliche Merkmale und Einsatzmöglichkeiten aufweisen. Beispielsweise können einige der tragbaren industriellen Rechengeräte 112a–112e Feldkommunikatoren sein, die auf einem oder mehreren der verschiedenen Sub-Netzwerke 206 in der Betriebsanlage kommunizieren, um mit Feldgeräten wie HART- oder Fieldbus-Feldgeräten zu kommunizieren. Einige der tragbaren industriellen Rechengeräte 112a–112e können Kalibratoren oder Konfiguratoren sein, die Vorrichtungen in der Betriebsanlage, insbesondere Feldgeräte und andere Arten von Vorrichtungen, wie z. B. rotierende Vorrichtungen, Vibrationsanalysatoren usw. kalibrieren oder konfigurieren. Des Weiteren können einige der tragbaren industriellen Rechengeräte 112a–112e elektrische Testfunktionen wie z. B. Amperemeter, Voltmeter, Widerstandsmessinstrumente, Impedanzmessgeräte oder Multimeter sein oder als solche verwendet werden, um Verdrahtung und andere Vorrichtungen in der Betriebsanlage, wie z. B. Stromversorgungen, zu prüfen. Ebenso können einige der tragbaren industriellen Rechengeräte 112a–112e intrinsisch sicher sein und können somit in gefährlichen Umgebungen eingesetzt werden. Einige der tragbaren industriellen Rechengeräte 112a–112e können speziell konfigurierte tragbare Vorrichtungen sein, die von verschiedenen Herstellern hergestellt werden, oder sie können auf einem Allzweckcomputer, beispielsweise einem Laptop, einem Telefon, einem Personal Digital-Assistent (PDA), Tablet-Computer usw. als Softwaremerkmale oder Hardware implementiert oder mit diesen verbunden sein. Die tragbaren industriellen Rechengeräte 112a–112e können in einer oder mehreren Flotten von tragbaren Geräten in beliebiger Weise unter Verwendung von beispielsweise einer der Workstations 246, 268 als Flottenmanagement-Stationen gruppiert werden, basierend auf z. B. Funktionalität, Verwendung, Typ, Hersteller, Benutzer usw. oder einer Kombination dieser und anderer Merkmale. Um eine über die üblichen IT-Sicherheitsmechanismen hinausgehende zusätzliche Sicherheit (z. B. Benutzerauthentifizierung, Active Directory usw.) zu gewährleisten, hält das Prozesssteuerungs-Messaging-Netzwerk 200 eine Netzwerktrennung zwischen externen Netzwerken wie der externen Cloud 210 aufrecht; interne Kommunikationsnetzwerke am Standort des Endbenutzers (d. h., der Betriebsanlage) umfassen typischerweise mehrere isolierte Netzwerke, einschließlich Unternehmensnetzwerke 202, Betriebsanlagennetzwerke 204, Steuerungsnetzwerke 206 usw., und ein Netzwerk-zu-Netzwerk-Vermittler oder eine DMZ-Vorrichtung 240 führt Software aus, die neben den vorhandenen Routern in der Betriebsanlage läuft, um diese Netzwerke miteinander zu verbinden. In einem Beispiel implementiert die DMZ-Software eine Port-Umleitung, die eine Netzwerktrennung beibehält, erlaubt jedoch den Computern oder industriellen Geräten in einem Betriebsanlagennetzwerk einen sicheren Zugriff auf andere Netzwerke einschließlich des externen Cloud-Netzwerks 210. Während das Prozesssteuerungs-Messaging-Netzwerk 200 viel von der gleichen oder einer ähnlichen Hardware wie das Prozesssteuerungsnetzwerk 100 umfassen kann, so bleibt doch das Prozesssteuerungs-Messaging-Netzwerk 200 von dem Prozesssteuerungsnetzwerk 100 logisch isoliert. Gleichzeitig erlauben die auf die Mehrfach-, Isolationsnetzwerke und den Prozesssteuerungs-Messaging-Übermittlungsdienst verteilten Prozesssteuerungs-Messaging-Zugangspunkte 208a–208c eine Kommunikation über mehrere voneinander isolierte Netzwerke hinweg. Wie in dieser Schrift verwendet, können die Netzwerke 202, 203, 204, 206 und die damit verbundenen Vorrichtungen als alle an der gleichen allgemeinen Stelle angeordnet betrachtet werden, welche als eine erste oder eine zweite Stelle bezeichnet wird, oder diese Netzwerke und Vorrichtungen können als an verschiedenen Orten angeordnet betrachtet werden.
Zusätzlich sind die Flottenmanagementstationen 246 und 268 Computer oder Workstations mit Prozessoren, die eine zugehörige Flottenmanagementsoftware ausführen, und die sich in diesem Beispiel am Standort des Endbenutzers oder in der Betriebsanlage befinden. Diese Geräte werden von einem Betriebsanlagen- oder Flottenadministrator als Benutzerschnittstelle verwendet, um beispielsweise jede der identifizierten Flotten tragbarer industrieller Rechengeräte in der Betriebsanlage zu verwalten. Genauer gesagt, werden diese Computer von dem Flottenadministrator der tragbaren (oder stationären) Geräte verwendet, um einige oder alle Aktivitäten in Verbindung mit einer automatischen und halbautomatischen Verwaltung des Inhalts innerhalb der Flotten industrieller tragbarer Geräte 112a–112f sowie, falls gewünscht, von Flotten stationärer Geräte vorzunehmen. Ebenso sind die lokalen Content-Repositories 247 und 270 Datenbanken, die lokal Inhalt für die tragbaren industriellen Rechengeräte 112a–112f (sowie für stationäre Geräte, falls gewünscht) am Standort des Endbenutzers speichern, bevor oder nachdem dieser Inhalt auf die verschiedenen tragbaren industriellen Rechengeräte 112a–112f oder stationären Geräte 113a–113c heruntergeladen worden ist.
Jedoch umfasst in mindestens einer Ausführungsform, wie sie in 2 dargestellt ist, das externe Cloud- oder Serversystem (IT-Systeme, Infrastruktur usw.), das außerhalb der Betriebsanlagennetzwerke liegt, den Inhaltsentscheider 294, der ein Software-Mechanismus ist, welcher generell in der externen Cloud auf der IT-Infrastruktur (Server, Prozessoren etc) läuft, um eine Reihe unterschiedlicher Eingabekriterien auszuwerten und zu bestimmen, welche gefilterten/zielgerichteten Inhalte ein bestimmtes industrielles tragbares Gerät (oder welche Inhalte ein bestimmtes stationäres Gerät) an einem bestimmten Kundenstandort zu haben oder zu verwenden berechtigt ist. Im Allgemeinen speichert oder empfängt der Inhaltsentscheider 294 Eingaben, die die Merkmale, Programmierung, Betriebssysteme, Upgrades usw. (die alle als Inhalt bezeichnet werden) und Konfigurationsinformationen detaillieren, welche Konfigurationsparameter für die industriellen tragbaren Geräte 112a–112f oder stationären Geräte aufführen, und er bestimmt, welchen Inhalt jedes industrielle Gerät in der Flotte von industriellen tragbaren Geräten oder stationären Geräten zu haben erlaubt ist. Darüber hinaus ist der Inhalts-Downloader 296 mit dem Inhaltsentscheider 294 gekoppelt und stellt den industriellen Geräten leistungsfähige, sichere Verbindungen zum Herunterladen von Inhalten zur Verfügung, wie dies durch den Inhaltsentscheider 294 spezifiziert ist, und zwar über die externen und internen Netzwerke der Betriebsanlage, in welcher das industrielle tragbare Gerät oder stationäre Gerät verwendet wird oder sich befindet.
Des Weiteren speichert das Quell-Content-Repository 298 alle Inhalte, die zum Herunterladen auf die industriellen tragbaren Geräte 112a–112f (oder stationären Geräte, falls dies gewünscht wird) verfügbar sind, und stellt diese Inhalte bei Bedarf dem Inhalts-Downloader 296 zur Verfügung, um auf die industriellen tragbaren Geräte 112a–112f (oder stationären Geräte) in der Betriebsanlage heruntergeladen zu werden. Der Notifizierer 292 ist ein Modul (z. B. Software, die auf einem Prozessor ausgeführt wird), das Benachrichtigungen an Benutzer sendet, wenn Inhalt verfügbar wird oder für bestimmte industrielle Geräte heruntergeladen werden kann, beispielsweise wenn der Inhaltsentscheider 294 bestimmt, dass neuer Inhalt unter Verwendung eines der Unternehmenssystemcomputer 299 beschafft (z. B. lizenziert oder gekauft) wurde. Im Allgemeinen umfassen die Unternehmenssystemcomputer 299 Benutzerkonten und Authentifizierungs-, Einkaufs-, Auftragsverwaltungssysteme, einen Anwendungs- oder einen Funktions-Shop usw., die verwendet werden können, um neue Inhalte zu erwerben. Nicht zuletzt ist das Endbenutzerinformations-Repository 290 ein Datenbank- und Kommunikationsmodul, das Endbenutzerinformationen erfasst und speichert, welche die aktuelle Liste von Inhalten und Versionen dieses Inhalts auf jedem industriellen tragbaren Gerät in der Flotte von industriellen tragbaren Geräten 112a–112f und/oder auf jedem eines Satzes von stationären Geräten in einer Flotte von stationären Geräten in einer Betriebsanlage oder anderen industriellen Umgebung betreffen oder aufzählen.
3 ist die Darstellung eines Blockdiagramms einer beispielhaften Interaktion zwischen einem anfordernden Endpunkt (RequestEndpoint) und einem antwortenden Endpunkt (ResponseEndpoint), wie beispielsweise zwischen industriellen Rechengeräten 112, 113 unter Verwendung einer Prozesssteuerungs-Messaging-Systemarchitektur 300. In einem Beispiel dienen die Firewalls 230 und/oder die DMZ 240 als Endpunkte und insbesondere als Zwischenendpunkte für die Umleitung von Meldungen von einem anfordernden Endpunkt netzwerkübergreifend zu einem antwortenden Endpunkt. Wie bereits erwähnt, implementiert die DMZ-Software eine Port-Umleitung, welche eine Netzwerktrennung beibehält, industriellen Rechengeräten jedoch einen sicheren Zugang zu anderen Netzwerken und die Kommunikation mit anderen industriellen Rechengeräten oder mit externen Netzwerken ermöglicht. Als solcher kann ein anfordernder Endpunkt die Firewall oder DMZ als Endpunkt angeben, wobei Informationen in der Anforderung den antwortenden Endpunkt im anderen Netzwerk festlegen. Die Firewall oder DMZ kann die Nachricht empfangen und mit der Sicherheitssoftware die Nachricht zur Umleitung auf den antwortenden Endpunkt mithilfe der Port-Umleitung analysieren und/oder reinigen.
Jeder Endpunkt umfasst eine Plattform und eine Anwendung. Die Interaktion kann in Registrierung, Anmeldung und Teilnahme am Prozesssteuerungs-Messaging-Service aufgeteilt werden. Aus dem Untenstehenden ist zu verstehen, dass die Prozesssteuerungs-Messaging-Systemarchitektur 300 plattformunabhängig ist, so dass sie die Kommunikation zwischen unterschiedlichen Plattformen ermöglicht, insbesondere zwischen anderen industriellen Geräte-Computerplattformen (z. B. Betriebssystemen und Schnittstellen, wie Windows XP, Windows Embedded Compact 2013, Windows 10 usw.) und Feldgeräte-Kommunikationsplattformen (z. B. Fieldbus, HART usw.).
Ferner ermöglicht die Prozesssteuerungs-Messaging-Systemarchitektur 300 die Spezifizierung von Transporttypen/Protokollunabhängigkeiten auf der physischen Schicht (z. B. WLAN, Universal Serial Bus (USB) usw.) für eine bestimmte Anwendung, basierend auf dem am besten passenden Protokoll. Beispielsweise kann ein tragbares industrielles Rechengerät 112a, welches die Prozesssteuerungs-Messaging-Systemarchitektur 300 verwendet, einen WLAN-Transporttyp spezifizieren, wenn über einen drahtlosen Zugangspunkt 208a eine Verbindung zu dem Prozesssteuerungs-Messaging-Dienst hergestellt wird, während das tragbare industrielle Rechengerät 112a einen USB-Transporttyp spezifizieren kann, wenn eine Verbindung zu dem Prozesssteuerungs-Messaging-Dienst zu einem Personal Computer 112b über einen USB-Anschluss hergestellt wird.
Insbesondere umfasst die Prozesssteuerungs-Messaging-Systemarchitektur 300 Komponenten und Dienste, die auf einzelnen industriellen Rechengeräten 112, 113 und zentralisierten Computern, wie beispielsweise dem Server 150, eingesetzt werden. Die Komponenten und Dienste der Prozesssteuerungs-Messaging-Systemarchitektur 300 sind als Abstraktionsschicht mit einem dedizierten Kommunikationsprotokoll über Standard-IT-Infrastruktur und -Dienste (z. B. TCP/IP, Authentifizierung, Active Directory) und insbesondere oberhalb der Transportschicht des Prozesssteuerungsnetzwerks dargestellt. Somit ist das Kommunikationsprotokoll des Prozesssteuerungs-Messaging-Dienstes über dem Netzwerkkommunikationsprotokoll geschichtet, wenn die Transportschicht ein Netzwerkkommunikationsprotokoll aufweist, das dem Prozesssteuerungsnetzwerk (z. B. TCP/IP) entspricht.
Die Prozesssteuerungs-Messaging-Systemarchitektur 300 enthält ferner ein Prozesssteuerungs-Kommunikationsprotokoll (z.B. Fieldbus, HART usw.), das oberhalb des Kommunikationsprotokolls des Prozesssteuerungs-Messaging-Dienstes geschichtet ist. Als solches kann ein anforderndes industrielles Rechengerät das Kommunikationsprotokoll des Zielgerätes, sei es ein anderes industrielles Rechengerät, ein Feldgerät usw. spezifizieren.
Im Allgemeinen ermöglicht die Prozesssteuerungs-Messaging-Systemarchitektur 300 Anforderungsreaktionsoperationen und Operationen zur Übertragung großer Datenmengen zwischen Maschinenplattformen, die über eine drahtlose oder drahtgebundene Verbindung innerhalb der Betriebsanlageninfrastruktur verbunden sind. Die Prozesssteuerungs-Messaging-Systemarchitektur 300 ist so ausgelegt, dass sie verschiedene Aktivitäten für Dienste innerhalb der Betriebsanlage oder einer anderen industriellen Umgebung unterstützt, beispielsweise den Austausch von Informationen zwischen Diensten innerhalb des externen Netzwerks oder der Cloud 210 (z. B. Lizenzierungs- und Aktualisierungsdienste für industrielle Rechengeräte, Webdienste (z. B. Web-Extender-Client) usw.) und Plattformen, die mit dem Prozesssteuerungs-Messaging-Netzwerk 200 verbunden sind (z. B. interne Betriebsanlagesdienste, die im Wesentlichen angemeldete Plattformen umfassen, welche in der Multi-Plattform-Umgebung Dienste erbringen). Jede Plattform kann mehrere Instanzen der Prozesssteuerungs-Messaging-Architektur umfassen, die auf dem System der Plattform (z. B. industrielle Rechengeräte) installiert ist und läuft. Andererseits würde bei einer einfachen Implementierung ein einzelnes Rechengerät (z. B. ein stationäres industrielles Rechengerät) mit einer einzigen Instanz der installierten Prozesssteuerungs-Messaging-Architektur installiert sein, wodurch das eine Rechengerät als Verbindungspunkt für Dienste innerhalb der Betriebsanlage 10 oder des externen Netzwerks 210 dienen würde.
In einer Operation nach Art von Anforderung/Antwort unterstützt die Prozesssteuerungs-Messaging-Systemarchitektur das Senden einer Anforderung an einen Plattformendpunkt und ein Anwendungs-Thema, das durch Senden der Antwort an einen bestimmten Endpunkt in der Anforderung antwortet. Anforderungs- und Antwortaktivitäten beinhalten das Senden und Empfangen von Daten zu und von Endpunkten, die als „RequestEndPoint“ und „ResponseEndPoint“ bezeichnet werden. Der RequestEndPoint ist das Ziel, an das die Anforderung zugestellt wird, und die Quelle/Herkunft der Antwort, während ResponseEndPoint das Ziel, an das die Antwort geliefert wird, und die Quelle/Herkunft der Anforderung ist. RequestEndPoint und ResponseEndPoint umfassen eine Plattform und eine Anwendung. Der Anforderungs-/Antwort-Endpunkt besteht aus einem Thema, einer Anwendung und einer Plattform. Kurz gesagt, beinhaltet die Anforderungs-/Antwortoperation, dass ein Client eine Anforderung (Thema) an eine auf einer Plattform laufende Anwendung sendet und ihm eine Antwort zurückgegeben wird. Die Themen werden in einer Anwendung auf einer Plattform gehostet. Das Thema identifiziert jenes Thema, für das die Anwendung durchgeführt werden soll, wobei der Themenname für alle Themen innerhalb des Anwendungsnamensraums eindeutig ist. Die Anwendung ist der Container, der Themen erhalten hat und die Themen für die Bearbeitung routet. Die Plattform verfügt über einen Prozess, der die Anwendung hostet. Um ein bestimmtes Thema zu erreichen, enthält daher die Anforderungs-Antwort-Nachricht Angaben über die Anwendungs-, Plattform- und Themenidentifikatoren.
Bei einer Operation zur Übertragung großer Datenmengen (Large Data Transfer, „LTD“) unterstützt die Prozesssteuerungs-Messaging-Architektur die Übertragung von Dateien von einem Quellort zu einem Ziel, die als „LDTSource“ bzw. „LDTDestination“ bezeichnet werden. Der LTD-Endpunkt enthält eine PlatformID, die die Quellplattform und die Zielplattform angibt. LDT-Quelle und -Ziel enthalten einen Uniform Resource Locator (URL). LDTSource gibt eine bestimmte Ressource an, während LDTDestination nur den Bestimmungsort angeben muss.
In der Operation des Anforderungs-/Antworttyps (z. B. Instant-/Echtzeit-Messaging, Zeitsynchronisierung) oder in der LDT-Operation kann die Anforderung an die Dienstqualität bei der Kommunikation zwischen Endpunkten spezifiziert sein. Beispielsweise kann die Anforderung eine garantierte Zustellung vorschreiben, wobei eine Kopie der Nachricht vorübergehend in einer Datenbank oder einem anderen Ursprungs-Client-Speicher persistiert wird, während die Fähigkeit des Endpunkt-Clients, die Nachricht zu empfangen, durch Quittierung des Empfangs überprüft wird, wobei an diesem Punkt die Kopie der Nachricht aus der Datenbank gelöscht wird. Andererseits legt die Anforderung möglicherweise weder eine garantierte Zustellung (noch keine garantierte Zustellung) fest und sendet gegebenenfalls die Anforderung ohne Persistierung der Nachricht und ohne Überprüfung der Fähigkeit des Endpunkts zum Empfang der Nachricht. Während eine Operation eine garantierte oder nicht garantierte Zustellung nutzen kann, verwendet die Übertragung großer Datenmengen aufgrund der Größe der Datenübertragung im Allgemeinen eine garantierte Zustellung, während ein Anforderungs-/Antwortdienst, wie z. B. Echtzeit- oder Instant-Messaging, unter Umständen mehr um die zeitgerechte Zustellung besorgt ist und auf die Anwendung einer garantierten Zustellung verzichtet.
4 zeigt eine schematische Beziehung zwischen der Prozesssteuerungs-Messaging-Architektur 300, den Zugangspunkten 302, 306, den teilnehmenden Geräten oder Endpunkten 304, 308 und den Prozesssteuerungs-Messaging-Diensten 310–316. Unter Verwendung der Prozesssteuerungs-Messaging-Systemarchitektur 300, die über alle Geräte in dem Prozesssteuerungs-Messaging-Netzwerk verteilt ist, kann eine Vielzahl von Prozesssteuerungs-Messaging-Diensten 310–316 zwischen und unter den Feldgeräten 304, industriellen Rechengeräten, externen Clouds, Personal Computern 308 usw. wie sichere Kommunikation, Instant-/Echtzeit-Messaging, Dateiübertragung, Datensynchronisierung, Zeitsynchronisierung, Aktualisierung industrieller Rechengeräte-Plattformen vorgesehen sein. Damit jedoch ein beliebiges Gerät und insbesondere tragbare industrielle Rechengeräte 112 an den Prozesssteuerungs-Messaging-Diensten teilnehmen und Dienste nutzen können, welche Kommunikation, Messaging, Datenübertragung und andere Interaktionen mit anderen industriellen Rechengeräten in dem Prozesssteuerungs-Messaging-Netzwerk ermöglichen, müssen industrielle Rechengeräte registriert und beim Prozesssteuerungs-Messaging-Dienst angemeldet sein.
Von Anwendungen oder Diensten werden für die Prozesssteuerungs-Messaging-Systemarchitektur 300 öffentliche Schnittstellendefinitionen verwendet, um verschiedene Aktivitäten auszuführen. In 5A und 5B sind Beispiele primärer öffentlicher Schnittstellen und Basisklassen dargestellt, die in der Prozesssteuerungs-Messaging-Systemarchitektur 300 definiert sind. Wie in 5A gezeigt, ermöglicht eine beispielhafte Schnittstelle (IRequest-Sender) Anforderungen, die auf einem Anwendungs-Thema von einer Plattform zu einer anderen basieren, indem sie eine Zahl oder Klasse von definierten Methoden (RequestSender-Base) verwenden. Die RequestSenderBase ist eine abstrakte Klasse, die die IRequestSender-Schnittstelle implementiert, welche auf der Ebene der Prozesssteuerungs-Messaging-Systemarchitektur 300 definiert ist und der die Infrastruktur (z. B. Messaging) der Prozesssteuerungs-Messaging-Systemarchitektur 300 bekannt ist. Jeder Anforderungssender erbt von der Basisklasse.
Im vorliegenden Beispiel umfassen die definierten Methoden unter Anderem BeginRequest, EndRequest, PauseRequest, ResumeRequest und CancelRequest. BeginRequest ist eine asynchrone Methode, die vom anfragenden Client (ResponseEndpoint) aufgerufen wird, um eine Anforderung zu starten, die auf einem Anwendungs-Thema basiert, das an einen RequestEndpoint übermittelt werden soll. Die BeginRequest-Methode verwendet einen Operationsanforderungsspezifizierer, der die Details der Anforderung enthält, einen asynchronen Callback, der aufgerufen werden soll, wenn die Operation abgeschlossen ist, und ein vom Benutzer bereitgestelltes Objekt, das jede einzelne asynchrone Operationsanforderung von anderen Anforderungen unterscheidet. Die BeginRequest-Methode gibt eine IAsyncOperation zurück, welche jene asynchrone Operation darstellt, die zu diesem Zeitpunkt noch ausstehen könnte.
Die EndRequest-Methode ist jene Methode, die der anfordernde Client nach Beendigung der Anforderung zum Lesen des Abschlussergebnisses aufruft. Die EndRequest-Methode wartet andernfalls darauf, dass die anstehende asynchrone Operation abgeschlossen ist, und verwendet den Verweis auf die anstehende asynchrone Beendigungsanforderung, welche von der BeginRequest-Methode zurückgegeben wird, wenn die asynchrone Operation IAsyncOperation gestartet wird. Die EndRequest-Methode gibt darüber hinaus das Ergebnis der asynchronen Operation zurück. Die Methode PauseRequest ist jene Methode, die der anfordernde Client aufruft, um eine bestimmte asynchrone Operation anzuhalten. Die PauseRequest-Methode nutzt den Verweis auf die anstehende asynchrone Anforderung des Anhaltens, die von der BeginRequest-Methode zurückgegeben wird, wenn die asynchrone Operation IAsyncOperation gestartet wird. Die ResumeRequest-Methode ist jene Methode, die der Client-Endpunkt aufruft, um eine angegebene angehaltene asynchrone Operation fortzusetzen. Die ResumeRequest-Methode verwendet ebenfalls den Verweis auf die anstehende asynchrone Anforderung des Fortfahrens, wie sie von der BeginRequest-Methode zurückgegeben wird, wenn die asynchrone Operation IAsyncOperation gestartet wird. Die Cancel Request-Methode ist jene Methode, die der anfordernde Client aufruft, um eine bestimmte asynchrone Operation abzubrechen, und verwendet den Verweis auf die anstehende asynchrone Anforderung zum Abbrechen, die von der BeginRequest-Methode zurückgegeben wurde, wenn die asynchrone Operation IAsyncOperation gestartet wird.
Wie in dargestellt, verarbeitet eine beispielhafte Schnittstelle (RequestReceiver) Antworten, die auf einem Anwendungs-Thema von einer Plattform zur anderen basieren, unter Verwendung einer Anzahl oder Klasse definierter Methoden (RequestReceiver-Base). Die RequestReceiverBase ist eine abstrakte Klasse, die die RequestReceiver-Schnittstellenmethode definiert oder implementiert und in der Ebene der Prozesssteuerungs-Messaging-Systemarchitektur 300 definiert ist, und der die Infrastruktur (z. B. Messaging) der Prozesssteuerungs-Messaging-Systemarchitektur 300 bekannt ist. Jeder Anforderungsempfänger erbt von der Basisklasse und implementiert die abstrakten Methoden.
Im vorliegenden Beispiel umfassen die definierten Methoden unter Anderem ProcessRequest, ProcessPausing, ProcessResuming, ProcessCancellation, SendResponse und NotifyStateChanged. ProcessRequest ist eine abstrakte Methode (d. h. eine Methode, die deklariert ist, jedoch keine Implementierung enthält – nicht instanziiert werden darf – und eine Unterklasse erfordert, um Implementierungen bereitzustellen), die vom empfangenden Client (RequestEndpoint) aufgerufen wird, um eine eingehende Anforderung basierend auf einem Application-Topic zu verarbeiten. Die ProcessRequest-Methode verwendet den Operationsanforderungsspezifizierer aus der IRequestSender.BeginRequest-Methode, IAsyncOperation, und ruft die SendResponse-Methode auf, sobald die Operation abgeschlossen ist. Die ProcessPausing-Methode ist eine abstrakte Methode, die vom empfangenden Client aufgerufen wird, um eine von der Methode IRequestSender.PauseRequest eingehende Anhalteanforderung für die Operation zu verarbeiten. Die ProcessRequest-Methode verwendet den Operationsanforderungsspezifizierer aus der IRequestSender.BeginRequest-Methode, IAsyncOperation, und ruft die SendResponse-Methode auf, um zu spezifizieren, dass die Methode angehalten werden soll. Die ProcessResuming-Methode ist eine abstrakte Methode, die vom empfangenden Client aufgerufen wird, um eine von der Methode IRequestSender.ResumeRequest eingehende Fortsetzungs-Anforderung für die Operation zu verarbeiten. Die Process-Resuming-Methode verwendet den Operationsanforderungsspezifizierer aus der IRequest-Sender.BeginRequest-Methode, IAsyncOperation, um die Operation zum Fortfahren anzugeben. Die Methode ProcessCancellation ist eine abstrakte Methode, die vom empfangenden Endpunkt aufgerufen wird, um eine von der IRequestSender.CancelRequest-Methode eingehende Abbruchanforderung für die Operation zu verarbeiten. Die Methode ProcessCancellation verwendet den Operationsanforderungsspezifizierer aus der IRequestSender.BeginRequest-Methode, IAsynchOperation, um die Operation zum Abbrechen anzugeben. Die Methode ProcessCancellation kann die SendResponse-Methode aufrufen, wenn die Operation abgebrochen wird. Die SendResponse-Methode ist eine abstrakte Methode, die vom empfangenden Client aufgerufen wird, um die Antwort an den im Request-Spezifizierer angegebenen ResponseEndpoint aus der IRequestSender.BeginRequest-Methode, IAsynchOperation, zu senden. Die SendResponse-Methode verwendet die Anforderungsspezifiziereridentifikation, den Operationsstatus und das Operationsergebnis als Teil der Antwort. Die NotifyStateChanged-Methode ist eine abstrakte Methode, die vom empfangenden Client aufgerufen wird, um eine Änderung der Zustandsbenachrichtigung an den ResponseEndpoint zu senden, der in dem Anforderungsspezifizierer aus der IRequestSender.BeginRequest-Methode, IAsynchOperation, angegeben ist.
Bezugnehmend wiederum auf 5A, ermöglicht die beispielhafte Schnittstelle (ILargeDataTransfer) Übertragungen großer Datenmengen von einer Plattform zu einer anderen unter Verwendung einer Anzahl oder Klasse definierter Methoden (TransferRequestSender). TransferRequestSender implementiert die Schnittstelle ILargeDataTransfer und ist in der Ebene der Prozesssteuerungs-Messaging-Systemarchitektur 300 definiert. Die Schnittstelle ILargeDataTransfer ermöglicht die Instanziierung der Operation der Übertragung großer Datenmengen.
Im vorliegenden Beispiel umfassen die definierten Methoden unter Anderem BeginTransfer, EndTransfer, Pause, Resume und Cancel. Der BeginTransfer ist eine asynchrone Methode, die vom anfragenden Client (ResponseEndpoint) aufgerufen wird, um eine Operation zur Übertragung großer Datenmengen zu starten. Die BeginTransfer-Methode verwendet einen Operationsübertragungsspezifizierer, der die Details der Operation zur Übertragung großer Datenmengen enthält, einen asynchronen Callback, der aufgerufen werden soll, wenn die Operation zur Übertragung großer Datenmengen abgeschlossen ist, und ein vom Benutzer bereitgestelltes Objekt, das jede einzelne asynchrone Operationsanforderung zur Übertragung großer Datenmengen von anderen Operationen zur Übertragung großer Datenmengen unterscheidet. Die BeginTransfer-Methode gibt ein IAsyncResult zurück, welches jene asynchrone Operation zur Übertragung großer Datenmengen darstellt, die zu diesem Zeitpunkt noch ausstehen könnte.
Die EndTransfer-Methode ist eine Methode, die der anfordernde Client nach Abschluss der Übertragung großer Datenmengen aufruft, um das Abschlussergebnis zu lesen. Die EndTransfer-Methode wartet andernfalls darauf, dass die anstehende asynchrone Operation zur Übertragung großer Datenmengen abgeschlossen ist, und verwendet den Verweis auf die anstehende asynchrone Anforderung zur Beendigung der Operation zur Übertragung großer Datenmengen, welche von der BeginTransfer-Methode zurückgegeben wird, wenn die asynchrone Operation IAsyncResult gestartet wird. Die EndTransfer-Methode gibt ferner das Ergebnis der Operation zur Übertragung großer Datenmengen zurück. Die Pause-Methode ist jene Methode, welche der anfordernde Client aufruft, um eine bestimmte asynchrone Operation zur Übertragung großer Datenmengen anzuhalten. Die Pause-Methode verwendet den Verweis auf die anstehende asynchrone Anhalte-Anforderung, die von der BeginTransfer-Methode zurückgegeben wird, wenn die asynchrone Operation zur Übertragung großer Datenmengen IAsyncResult gestartet wird. Die Resume-Methode ist jene Methode, welche der anfordernde Client-Endpunkt aufruft, um eine angegebene angehaltene asynchrone Operation zur Übertragung großer Datenmengen fortzusetzen. In gleicher Weise nutzt die Resume-Methode den Verweis auf die anstehende asynchrone Anforderung zur Übertragung großer Datenmengen, um fortzufahren, wie von der BeginTransfer-Methode zurückgegeben, wenn die asynchrone Operation zur Übertragung großer Datenmengen IAsyncResult gestartet wird. Die Abbruchmethode ist eine Methode, die der anfordernde Client aufruft, um eine spezifizierte asynchrone Operation zur Übertragung großer Datenmengen abzubrechen, und den Verweis auf die anstehende asynchrone Anforderung des Abbrechens der Übertragung großer Datenmengen verwendet, die von der BeginTransfer-Methode zurückgegeben wurde, wenn die asynchrone Operation zur Übertragung großer Datenmengen IAsyncResult gestartet wird. Nachfolgend ein Beispiel für die Prozesssteuerungs-Messaging-Systemarchitektur 300, die eine Übertragung großer Datenmengen erzeugt, instanziiert und einleitet. Erstellen des großen Datenübertragungs-Spezifizierers mit LargeDataTransferSpecifierBuilder:
Einleiten von TransferRequestSender:
Einleiten der Übertragung:
6 zeigt ein Beispiel gemeinsamer Schnittstellen, die durch die Prozesssteuerungs-Messaging-Systemarchitektur 300 implementiert werden. Wie aus 6 ersichtlich umfassen die gemeinsamen Schnittstellen unter Anderem Topic, TopicData, Status, User-Context, IAsyncOperation, AsyncOperationStateChangedEventArgs und AsyncOperationState. Die Topic-Schnittstelle ist eine Klasse, die den Topic-Identifizierer darstellt und als Topic<string> verwendet wird. Die TopicData-Schnittstelle ist eine Klasse, die die Themendaten darstellt. Die Status-Schnittstelle ist ein Statusobjekt, das in Antworten verwendet wird, um zum Beispiel die Zustellung einer Nachricht zu garantieren (oder nicht zu garantieren). Die UserContext-Schnittstelle ist eine Klasse, die Benutzerkontext-Informationen enthält. Ferner implementiert die UserContext-Schnittstelle definierte Methoden, IsEqual (User-Context), die einen UserContext mit einem anderen vergleicht und true zurückgibt, wenn die Kontexte gleich sind. Die IAsyncOperation-Schnittstelle stellt eine asynchrone Operation dar und liefert ein Ereignis für die asynchrone Operationszustandsänderungsbenachrichtigung, StateChanged <AsyncOperationStateChangedEventArgs>, welches auftritt, wenn ein asynchroner Operationszustand geändert wird. Die AsyncOperationStateChangedEventArgs wiederum ist eine Klasse von durch asynchrone Operationszustände geänderten Argumenten. AsynchOperationState liefert asynchrone Operationszustandsinformationen mit den Eigenschaften einer asynchronen Operationsidentifikation (OperationID), dem Typ der asynchronen Operation (Typ) und dem Fortschrittswert der asynchronen Operation (Progress).
Wie in Bezug auf 1 angemerkt, kann der Server 150 in einigen Ausführungsformen als ein Enrollment-Server zum Registrieren und Anmelden industrieller Rechengeräte 112, 113 im Prozesssteuerungs-Messaging-Dienst dienen. Ein Administrator des Prozesssteuerungs-Messaging-Dienstes kann jedes industrielle Rechengerät registrieren. Zum Beispiel können neu lizenzierte industrielle Rechengeräte 112, 113 dem Prozesssteuerungs-Messaging-Netzwerk hinzugefügt und zu diesem Zeitpunkt unter Verwendung eines dem industriellen Rechengerät zugehörigen eindeutigen Identifikators registriert werden. Zu diesem Zeitpunkt kann die Registrierung beliebige Beschränkungen oder Berechtigungen auf dem industriellen Rechengerät definieren, insbesondere auf Abonnements für andere Geräte, mit denen es auf dem Prozesssteuerungs-Messaging-Netzwerk kommunizieren kann, Beschränkungen auf spezifische Prozesssteuerungs-Messaging-Dienste usw. Im Falle eines industriellen Gast-Rechengerätes (wie es beispielsweise von einem externen Auftragnehmer verwendet werden kann, der in dem Prozessleitsystem tätig ist), kann ein industrielles Rechengerät, im Gegensatz zu einem permanenten Zugriff, auf einen vorübergehenden Zugriff auf den Prozesssteuerungs-Messaging-Dienst beschränkt werden. Der Registrierungsprozess kann auch dem industriellen Rechengerät die Netzwerkadresse des Enrollment-Servers mitteilen, so dass der Enrollment-Server dem industriellen Rechengerät gut bekannt ist.
In einer Ausführungsform wird der Anmeldedienst unter Verwendung eines Kommunikationsmoduls an der drahtlosen Schnittstelle eines jeden Gerätes in dem Prozesssteuerungs-Messaging-Netzwerk in Kommunikation mit einem einzigen, bekannten Endpunkt, beispielsweise dem Server 150, erbracht. Jedes Mal, wenn sich ein industrielles Rechengerät (z. B. über einen drahtlosen Zugangspunkt oder über USB) mit dem Prozesssteuerungs-Messaging-Netzwerk verbindet, überprüft der Anmeldedienst die Registrierung, führt Benachrichtigungen an andere Endpunkte durch, die bei dem Prozesssteuerungs-Messaging auf der Grundlage des Abonnementstatus (falls vorhanden) angemeldet sind, und führt zur Aufrechterhaltung der Verbindung und Anmeldestatus periodisch Pings auf das industrielle Rechengerät durch.
7 zeigt ein Beispiel des Anmeldevorgangs 400 zwischen einem industriellen Rechengerät und dem Enrollment-Server 150. In einer Ausführungsform ist der Anmeldevorgang 400 die erste Aktivität, nachdem eine Plattform, beispielsweise ein industrielles Rechengerät, gestartet wurde bzw. sich mit der Prozesssteuerungs-Messaging-Systemarchitektur 300 verbunden hat. Die Plattform ist andernfalls ohne eine erfolgreiche Anmeldung nicht in der Lage, Dienste zu erbringen, die von der Prozesssteuerungs-Messaging-Systemarchitektur 300 angeboten werden. Wie bereits erwähnt, ist der Enrollment-Server ein bekannter Endpunkt für die verschiedenen Plattformen. Als solchen gibt es in einer Multi-Plattform-Umgebung einen designierten Enrollment-Server, der in der Lage ist, Anmeldeanforderungen für alle Plattformen zu validieren, wenn sie eine Verbindung herstellen und starten. Um Plattformen zu validieren, die eine Verbindung aufbauen, ist der Enrollment-Server in der Lage, Dienste, beispielsweise Lizenzierungsdienste, abzufragen.
Sobald es erforderlich ist, dass ein registriertes industrielles Rechengerät an dem Prozesssteuerungs-Messaging-Netzwerk (d. h. als Client/Endpunkt) teilnimmt, beginnt das registrierte industrielle Rechengerät nach der Verbindung der Plattform mit dem Prozesssteuerungs-Messaging-Netzwerk den Anmeldevorgang als eine lokale Operation 402, indem es automatisch eine Anforderung an den Enrollment-Server zur Anmeldung der Plattform einleitet. Die lokale Operation versucht, den Enrollment-Server 404 zu erreichen. Ist der Enrollment-Server nicht verfügbar oder nicht erreichbar, wird keine Anmeldung durchgeführt und es sind zu dem Zeitpunkt keine Prozesssteuerungs-Messaging-Dienste möglich. Die Anmeldung von einer Plattform aus, die mit einer Personal-Computer-Plattform in einer Peer-to-Peer-Beziehung (z. B. USB-Kabelverbindung) direkt verbunden ist, bewirkt, dass die Personal-Computer-Plattform versucht, die Anmeldeanforderung an den Enrollment-Server 150 zu routen (weiterzuleiten), sofern die Personal-Computer-Plattform nicht selbst der Enrollment-Server 150 ist.
Der Enrollment-Server überprüft die Registrierung des industriellen Rechengerätes am Prozesssteuerungs-Messaging-Dienst und veröffentlicht die Adressen von anderen Geräten auf dem Prozesssteuerungs-Messaging-Netzwerk auf der Grundlage des Abonnementstatus des angemeldeten industriellen Rechengerätes 406. Die Anmeldung des industriellen Rechengerätes wird aufgezeichnet, wobei der Enrollment-Server periodisch Pings an das industrielle Rechengerät sendet, um die Anmeldeverbindung und den Status 408 aufrechtzuerhalten. Zu diesem Zeitpunkt kann der Enrollment-Server die Prozesssteuerungs-Messaging-Dienste von der Anmeldung des industriellen Rechengerätes benachrichtigen. Beispielsweise kann der Anmeldedienst einen Upgrade-Dienst benachrichtigen, dass sich ein bestimmtes industrielles Rechengerät verbunden/angemeldet hat, und der Upgrade-Dienst kann seinerseits das industrielle Rechengerät über alle anstehenden Upgrades für seine Plattform informieren.
Nach dem Anmelden eines registrierten industriellen Rechengerätes 112 beim Prozesssteuerungs-Messaging-Dienst werden die Endpunkte (d. h. Ziele) dem angemeldeten (teilnehmenden) Gerät bekannt, und zwar zumindest insofern, als dies durch den Abonnementstatus des angemeldeten Gerätes gestattet ist, unabhängig davon, ob die Endpunkte auf demselben physischen Geräten (z. B. industrielles Rechengerät-zu-industrielles Rechengerät) oder auf verschiedenen physischen Geräten (z. B. industrielles Rechengerät-zu-Feldgerät) oder verschiedenen Plattformen sind. Die Kenntnis der Endpunkte ermöglicht es einem teilnehmenden industriellen Rechengerät, Nachrichten der Zielplattform entsprechend zu strukturieren. Wenn beispielsweise das teilnehmende industrielle Rechengerät mit einem Fieldbus-Feldgerät kommunizieren soll, verwendet das industrielle Rechengerät die Prozesssteuerungs-Kommunikationsprotokollschicht der Prozesssteuerungs-Messaging-Systemarchitektur 300, um die Nachricht im Fieldbus-Protokoll zu erzeugen. Auf ähnliche Weise, wenn das teilnehmende industrielle Rechengerät mit einem HART-Feldgerät kommunizieren soll, nutzt das industrielle Rechengerät die Prozesssteuerungs-Kommunikationsprotokollschicht der Prozesssteuerungs-Messaging-Systemarchitektur 300, um die Nachricht im HART-Protokoll zu erzeugen.
Sobald die Nachricht erzeugt worden ist, verwendet das industrielle Rechengerät 112 die Prozesssteuerungs-Messaging-Protokollschicht der Prozesssteuerungs-Messaging-Systemarchitektur 300, um die erzeugte Nachricht im Protokoll des Prozesssteuerungs-Messaging-Dienstes zu verpacken. In einer Ausführungsform kann die Nachricht so verpackt werden, dass die Nachricht die Nutzlast eines Pakets in dem Protokoll des Prozesssteuerungs-Messaging-Dienstes bildet, wobei das Prozesssteuerungs-Messaging-Dienstprotokoll einen Header mit Information über das Prozesssteuerungskommunikationsprotokoll (z. B. Fieldbus, HART) und eine Netzwerkadresse oder Identifikation des Zielgerätes aufweist.
Sobald die verpackte Nachricht an das Prozesssteuerungs-Messaging-Netzwerk unter Verwendung des Prozesssteuerungs-Messaging-Protokolls übertragen ist, kann das Prozesssteuerungs-Messaging-Netzwerk die Nachricht in das Kommunikationsprotokoll des Zielgerätes unter Verwendung der Information in dem Header auspacken oder decodieren und die ausgepackte Nachricht an das Zielgerät routen/weiterleiten. Sobald die Nachricht an das Zielgerät (Plattform) zugestellt ist, kann die Nachricht, basierend auf dem Nachrichtenthema und/oder der (unten erörterten) Anwendung, zu einem bestimmten Prozess geroutet werden. Beispielsweise wird die Nachricht auf der Grundlage einer spezifizierten Themenanwendung zur Weiterverarbeitung an die Anwendung gesendet. Die Anwendung kann wahlweise die Nachricht (oder Datei, bei Übertragungen großer Datenmengen) kopieren und anschließend, basierend auf dem in der Nachricht angegebenen Thema, die Nachricht zu einem bestimmten Prozess verschieben.
In einem beispielhaften allgemeinen Szenario eines angemeldeten industriellen Rechengerätes, das am Prozesssteuerungs-Messaging-Dienst teilnimmt, muss ein tragbares industrielles Rechengerät zur Durchführung von Arbeitsaktivitäten am Prozesssteuerungs-Messaging-Netzwerk teilnehmen. Das industrielle Rechengerät wird mithilfe der oben beschriebenen Registrierungs- und Anmeldedienste registriert und im Prozesssteuerungs-Messaging-Netzwerk angemeldet. Nach der Anmeldung sendet eine Softwareanwendung auf dem industriellen Rechengerät eine Anforderung an einen Messaging-Dienst der Prozesssteuerungs-Messaging-Dienste, um eine Kommunikation mit einem anderen industriellen Rechengerät herzustellen. Eine Anfrage wird von dem anfragenden industriellen Rechengerät an den bekannten Prozesssteuerungs-Messaging-Dienst gesendet, und eine Auflistung der angeschlossenen Geräte wird abgefragt und wird durch den Anmeldedienst bereitgestellt. Mithilfe der Prozesssteuerungs-Messaging-Systemarchitektur 300 erzeugt und verpackt das anfordernde industrielle Rechengerät seine Nachricht für die Zielvorrichtung, wie oben beschrieben. Im Gegenzug kann die Zielvorrichtung ihre Prozesssteuerungs-Messaging-Systemarchitektur 300 verwenden, um eine Antwortnachricht zu erzeugen und zu verpacken.
8 ist ein Sequenzdiagramm 500, das eine beispielhafte Anforderungs-/Antwortoperation darstellt. Die spezifische Anforderungs-/Antwortoperation dient der Zeitsynchronisierung eines industriellen Rechengerätes mit einer Client-Anwendung als anfordernder Endpunkt und einem Zeitsynchronisierungsserver als empfangender Endpunkt, obwohl zu verstehen ist, dass das Beispielszenario für andere Anforderungs-/Antwort-Operationen, die andere Client-Anwendungen und -Dienste verwenden, allen voran für Anfragen/Antworten, die mehrere Endpunkte umfassen (z. B. Messaging mehrerer industrieller Rechengeräte 112, 113), problemlos abgewandelt werden kann. Unter Bezugnahme auf 8, führt der Time-SyncServer eine Initialisierung und ein Bootstrapping der RequestReceiverBase-Klasse 502 durch. Danach sendet der Endpunkt-Client eine asynchrone GetDateTime-Anforderung 504 und die TimeSyncClient-Anwendung liefert notwendige Spezifizierer 506. Der TimeSyncClient ruft die BeginRequest-Methode der RequestSenderBase 508 auf und RequestSenderBase sendet die Anforderung an die Client-Instanz von MessageBroker 510. Die Client-Instanz von MessageBroker sendet die Nachricht über die Messaging-Infrastruktur des Prozesssteuerungs-Messaging-Systems 512. Auf der Serverseite empfängt eine Serverinstanz von MessageBroker die Nachricht von der Messaging-Infrastruktur 514; die Serverinstanz des Message-Broker gibt die Nachricht an die RequestReceiverBase auf einem Peek-Methodenaufruf 516 zurück. Die RequestReceiverBase empfängt die Nachricht 518 und ruft ihre eigene abstrakte Methode ProcessRequest 520 auf, welche, wie oben beschrieben, eine abstrakte Methode ist, die vom Endpunkt TimeSyncServer, der von RequestReceiverBase erbt, zu implementieren ist. Der Server erzeugt die DateTime-Antwort 522 und der TimeSyncServer sendet die Antwort durch die aufrufende SendResponse-Methode 524 an RequestReceiverBase. Die RequestReceiverBase sendet die Antwort an die Serverinstanz von MessageBroker 526. Request-SenderBase empfängt die Antwortnachricht und ruft eine Callback-Methode 528 auf. Time-SyncClient empfängt die Antwort durch Callback von BeginRequest 530, wobei die Callback-Methode von TimeSyncClient implementiert wird. Der TimeSyncClient ruft die EndRequest-Methode der RequestSenderBase 532 auf und der Client empfängt eine GetDateTime-Antwort 534. Als eine weitere Ausführungsform gibt die Softwareanwendung des anfordernden industriellen Rechengerätes, sobald die Kommunikation hergestellt worden ist, eine Anforderung an die Prozesssteuerungs-Messaging-Dienste aus, mehrere große Datendateien vom anfragenden industriellen Rechengerät zum industriellen Ziel-Rechengerät zu übertragen. Eine Auflistung von Datendateien wird entweder vom anfragenden industriellen Rechengerät oder von industriellen Ziel-Rechengerät angefordert. Auf der Grundlage der Anforderung wird dann ein Dateiübertragungsdienst aktiviert.
9 ist ein Sequenzdiagramm 600, das eine beispielhafte Operation zur Übertragung großer Datenmengen (LDT) darstellt. Die spezifische Operation zur Übertragung großer Datenmengen, obwohl es zu verstehen ist, dass das Beispielszenario für andere Vorgänge zur Übertragung großer Datenmengen, die andere Client-Anwendungen und -dienste verwenden, insbesondere für Operationen zur Übertragung großer Datenmengen zu mehreren Zielen (z. B. Aktualisierungen aus der externen Cloud 210 zu den industriellen Rechengeräten 112, 113), problemlos verändert werden kann. Unter Bezugnahme auf 9 führt ein LDT-Client eine Übertragung großer Datenmengen von der LDT-Quelle zu dem LDT-Ziel durch. Ein LDT-Anforderungsempfänger führt die Start- und Initialisierungsroutinen 602 aus, während ein LDT-Datenserver die Start- und Initialisierungsroutinen 604 ausführt. Der LDT-Client startet eine Übertragungsoperation 606 und die BeginTransfer-Methode des LDT-Anforderungssenders, der einen LDTSpecifier mit der LDT-Quelle/dem LTD-Ziel 608 bereitstellt. Der LDT-Anforderungssender ruft die BeginRequest-Methode der RequestSenderBase auf, die den RequestSpecifier 610 bereitstellt. Die RequestSenderBase sendet die Request Message an die RequestReceiverBase über die Messaging-Infrastruktur 612; die RequestReceiverBase empfängt die RequestMessage, verarbeitet sie und ruft die ProcessRequest-Abstraktionsmethode 614 auf. Die ProcessRequest-Methodenimplementierung des LDT-Anforderungsempfängers ruft die InstantiateTransferring-Nachricht des LDT-Dienstes 616 auf; der LDT-Dienst erstellt eine Übertragungssitzung und sendet die Datenanforderungsnachricht über die Messaging-Infrastruktur 618 an den LDT-Datenserver.
Der LDT-Datenserver empfängt die DataRequest-Nachricht, handhabt sie und sendet Daten über die Messaging-Infrastruktur 620 an den LDT-Dienst. Der LDT-Dienst empfängt wiederum die Daten, handhabt sie und sendet eine Datenanforderungsnachricht für den nächsten Teil der Daten 622. Der LDT-Dienst generiert ein StateChanged-Ereignis 624 und der LDT-Anforderungsempfänger ruft die NotifyStateChanged-Methode der RequestReceiverBase 626 auf. Die RequestReceiverBase NotifyStateChanged-Methodenimplementierung sendet die Fortschrittsnachricht über die Messaging-Infrastruktur 628 an die RequestSender-Base. Die RequestSenderBase empfängt die Fortschrittsnachricht und erzeugt einen ProgressChangedEvent 630.
Der LDT-Dienst schließt nach der Handhabung des letzten Teils der Daten die LDT-Sitzung und erzeugt das StateChanged-(Complete-)-Ereignis 632, während der LDT-Anforderungsempfänger die SendResponse-Methode der RequestReceiverBase 634 aufruft. Die RequestReceiverBase SendResponse-Methodenimplementierung sendet eine Request-Complete-Nachricht über die Messaging-Infrastruktur 636 an die RequestSenderBase. Die RequestSenderBase empfängt die RequestComplete-Nachricht und ruft die Callback-Methode 638 des LDT-Clients auf; der LDT-Client wiederum ruft die EndTransfer-Methode des LDT-Anforderungsabsenders 640 auf. Der LDT-Anforderungsabsender ruft die EndRequest-Methode der RequestSenderBase 642 auf und die RequestSenderBase gibt das RequestResult auf die EndRequest-Methode 644 zurück. Der LDT-Anforderungsabsender gibt das Transferergebnis über die EndTransfer-Methode 646 zurück.
Weitere Ausführungsformen, die aus dem obigen Beispiel zu verstehen sind, können ebenfalls nach der Anmeldung beim Prozesssteuerungs-Messaging-System implementiert werden. Beispielsweise gibt die Softwareanwendung des anfordernden industriellen Rechengerätes eine Anforderung an den Prozesssteuerungs-Messaging-Dienst aus, um ein Echtzeit-/Instant-Messaging mit einem industriellen Ziel-Rechengerät zu beginnen. Der Registrierungsdienst des Prozesssteuerungs-Messaging-Dienstes liefert dem anfordernden industriellen Rechengerät eine Aufstellung von verbundenen/angemeldeten Geräten. Das anfordernde industrielle Rechengerät ist dann in der Lage, Peer-to-Peer-Messaging mit dem angemeldeten industriellen Ziel-Rechengerät zu verwenden.
Sobald die Softwareanwendung des anfordernden industriellen Rechengerätes mit den Prozesssteuerungs-Messaging-Diensten fertig ist, gibt die Softwareanwendung eine Anforderung aus, die Kommunikation mit dem anderen Gerät zu beenden. In einigen Fällen hat das angeschlossene Gerät die Verbindung zum Netzwerk verloren. In jedem Fall aktualisiert der Registrierungsdienst seine interne Liste verbundener/angemeldeter Geräte. Es wird eine Meldung ausgegeben, die anzeigt, dass das Gerät nicht mehr mit dem Prozesssteuerungs-Messaging-Netzwerk verbunden ist.
6 stellt ein Blockdiagramm eines beispielhaften industriellen Rechengerätes 112, 113 dar. Das industrielle Rechengerät 112, 113 kann ein Handgerät oder ein tragbares Rechengerät, beispielsweise ein Laptop-Computer, ein Tablet-Computer, ein mobiles Gerät, Smartphone, Personal Digital Assistant (PDA), ein am Körper tragbares Rechengerät usw. sein. Das industrielle Rechengerät 112, 113 kann eine Anzeige 84, einen oder mehrere Prozessoren oder CPUs 88, einen Speicher 52, einen Speicher mit wahlfreiem Zugriff (RAM) 90, eine Eingabe/Ausgabe-(E/A-)-Schaltung 92 und eine Kommunikationseinheit 86 zum Senden und Empfangen von Daten über ein Local-Area-Netzwerk, Wide-Area-Netzwerk oder ein beliebiges anderes geeignetes Netzwerk umfassen. Die Kommunikationseinheit 86 kann einen NFC- oder RFID-Leser 98 umfassen, um NFC- oder RFID-Signale zu empfangen und zu decodieren. Das industrielle Rechengerät 112, 113 kann mit den Reglern 11, dem Server 150 und/oder einem beliebigen anderen geeigneten Rechengerät kommunizieren.
Der Speicher 52 kann ein Betriebssystem 78, eine Steuereinheit 94 zum Steuern der Anzeige 88 und zur Kommunikation mit Prozesssteuerungsgeräten und ein Authentifizierungs-/Autorisierungsmodul 96 zum Authentifizieren eines Benutzers und zum Bestimmen eines Berechtigungsniveaus des Benutzers umfassen. In einigen Ausführungsformen kann das Authentifizierungs-/Autorisierungsmodul 96 bestimmen, ob ein Benutzer Zugang zu einem verbundenen Prozesssteuerungsgerät hat, sowie die Arten von Operationen, zu deren Ausführung am verbundenen Prozesssteuerungsgerät der Benutzer berechtigt ist. Sobald festgestellt ist, dass der Benutzer berechtigt ist, eine bestimmte Funktion auszuführen, um eine Operation (z. B. eine Konfigurationsfunktion) am angeschlossenen Prozesssteuerungsgerät auszuführen, kann die Steuereinheit 94 die Konfiguration des angeschlossenen Prozesssteuerungsgerätes steuern, indem sie Eingaben des Benutzers empfängt, die Ausgaben des angeschlossenen Prozesssteuerungsgerätes anzeigt und mit dem angeschlossenen Prozesssteuerungsgerät kommuniziert, um Einstellungen an dem angeschlossenen Prozesssteuerungsgerät einzustellen.
Um Benutzer und industrielle Rechengeräte für den Zugriff auf Prozesssteuerungsgeräte zu autorisieren, erzeugt der Server 150 Berechtigungen, die eine Zugriffsebene auf ein bestimmtes Prozesssteuerungsgerät festlegen. Beispielsweise kann eine erste Berechtigung den Zugriff auf Feldgerät A zum Lesen von Daten vom Gerät und zum Ausführen von Überwachungsfunktionen erlauben. Eine zweite Berechtigung kann den Zugriff auf Feldgerät B zum Lesen von Daten auf dem Gerät und Schreiben von Daten auf das Gerät und zum Ausführen von Kalibrier- und Konfigurationsfunktionen erlauben. Zusätzlich kann die zweite Berechtigung eine Zeitdauer (z. B. 1 Stunde) und einen Betriebsanlagenbereich festlegen, innerhalb welcher der Benutzer auf das Prozesssteuerungsgerät zugreifen kann. In einigen Ausführungsformen kann ein Systemadministrator mit dem Server 150 interagieren, um die Berechtigungen zu erzeugen.
Zusätzlich zum Erzeugen der Berechtigungen kann der Server 150 jede Berechtigung einem oder mehreren Benutzern und einem oder mehreren industriellen Rechengeräten zuordnen. Beispielsweise kann der Systemadministrator die erste Berechtigung einer ersten Teilmenge von Benutzern und einer ersten Teilmenge von industriellen Rechengeräten in der Prozessanlage erteilen. In einigen Szenarien kann jeder Benutzer, dem dieselbe Berechtigung erteilt wurde, dieselbe oder eine ähnliche Aufgabenfunktion in der Prozessanlage haben. Beispielsweise können jedem der Wartungstechniker in einer Prozessanlage dieselben Berechtigungen zugeordnet werden. In einigen Ausführungsformen können die Anzeigen von Berechtigungen, Benutzern in der Prozessanlage, industriellen Rechengeräten innerhalb der Prozessanlage und Zuordnungen zwischen den Berechtigungen, Benutzern und industriellen Rechengeräten in einer oder mehreren Datenbanken gespeichert sein, die kommunikativ mit dem Server 150 gekoppelt sind.
In 11 ist ein beispielhaftes tragbares industrielles Rechengerät 112, beispielsweise ein tragbares Feldwartungswerkzeug 700 („Werkzeug 700“) dargestellt, das mit einem Prozesssteuerungsgerät wie einem Feldgerät 760 über eine drahtgebundene Kommunikationsverbindung oder Kanal 750 direkt verbunden sein kann und/oder mit dem Feldgerät 760 über einen drahtlosen Kommunikationskanal eines Prozesssteuerungs-Asset-Management-Systems indirekt verbunden sein kann. In diesem speziellen Beispiel ist das tragbare Feldwartungswerkzeug 700 als ein Feldwartungs-Handwerkzeug dargestellt. In einer Ausführungsform ist das Werkzeug 700 in der Lage, wenn es mit den Anschlüssen des Feldgerätes 760 verdrahtet ist, nicht nur mit dem Feldgerät 760 zu kommunizieren, sondern auch das Feldgerät 760 mit Strom zu versorgen. In einer solchen Ausführungsform kann das Werkzeug 700 ein einzelnes zusammengesetztes Signal, das über die Verbindung 750 übertragen wird, sowohl für die Stromversorgung als auch für die Kommunikation mit dem Feldgerät 760 verwenden. In einer anderen Ausführungsform kann, wenn das Werkzeug 700 kommunikativ mit dem Prozesssteuerungs-Messaging-Netzwerk 200 über einen drahtlosen Kommunikationskanal (z B. über einen Zugangspunkt 720) verbunden ist, das Werkzeug 700 die Prozesssteuerungs-Messaging-Dienste nutzen, um mit dem Feldgerät 760 über ein Prozesssteuerungs-Asset-Management-System zu kommunizieren, welches zur Verwaltung des Feldgerätes 760 eingesetzt wird. Obwohl es als mit dem Zugangspunkt 720 kommunikativ über einen drahtlosen Kommunikationskanal gekoppelt dargestellt ist, kann das Werkzeug 700 das Prozesssteuerungs-Messaging-Netzwerk 200 direkt oder indirekt über einen drahtgebundenen Kommunikationskanal (z. B. Ethernet) entweder mit einem Zugangspunkt, der eine drahtgebundene Verbindung bereitstellt, ein drahtgebundenes Gateway, das eine drahtgebundene Verbindung bereitstellt, oder über ein anderes Computergerät (z. B. einen Personal Computer) mit einer drahtgebundenen oder drahtlosen Verbindung kommunikativ mit dem Prozesssteuerungs-Messaging-Netzwerk 200 koppeln.
In einigen Fällen kann das Werkzeug 700 Probleme mit dem Feldgerät 760 oder mit einer Kommunikationsverbindung/einem Kommunikationskanal in der Anlagenumgebung diagnostizieren, mit der das Feldgerät 760 verbunden ist (z. B. eine HART-Schleife oder ein Fieldbus-Segment, nicht dargestellt). In einigen Fällen kann das Werkzeug 700 mit bestimmten, nach verschiedenen Protokollen konfigurierten Feldgeräten kommunizieren oder diese diagnostizieren. Beispielsweise kann das Werkzeug 700 in der Lage sein, mit herkömmlichen 4-20-Feldgeräten, HART-Feldgeräten und Fieldbus-Feldgeräten zu kommunizieren und diese zu diagnostizieren. Im Gegensatz zu vielen tragbaren Prüfgeräten des Standes der Technik, die einen Benutzer zwingen, mehrere Vorrichtungen zu verwenden und/oder mehrere Kabel und Drähte mit verschiedenen unterschiedlichen Endgeräten zu verbinden, wenn er mit einem Feldgerät kommunizieren und eine Diagnose auf Signale durchführen möchte, die vom Feldgerät gesendet oder empfangen werden, kann das Werkzeug 700 eine einzelne Kommunikationsverbindung mit dem Prozesssteuerungs-Messaging-Netzwerk 200 verwenden, um das Feldgerät 760 zu diagnostizieren, in Betrieb zu nehmen, zu steuern oder anderweitig mit ihm zu kommunizieren. Als solches kann das Werkzeug 700 indirekt mit dem Feldgerät 760 kommunizieren, ohne Kommunikationsanschlüsse auf dem Feldgerät freilegen oder sich physisch mit ihnen verbinden zu müssen.
Darüber hinaus kann das Werkzeug 700 in ausreichendem Maße energiebegrenzt und fehlertolerant sein, um die Standards der intrinsischen Sicherheit (IS) einzuhalten. Beispielsweise kann das Werkzeug 700 so ausgelegt sein, dass alle Komponenten des Werkzeugs 700 und damit alle vom Werkzeug 700 gesendeten und/oder empfangenen Signale (z. B. einschließlich Energie- und/oder Kommunikationssignale) auf Bereiche, die mit IS-Standards konform sind, energiebegrenzt werden. Des Weiteren kann das Werkzeug 700 die Komponenten des Werkzeugs 700 und/oder die von dem Werkzeug 700 übertragenen oder empfangenen Signale „selbst überwachen“, um sicherzustellen, dass die Komponenten und/oder Signale IS-konform bleiben. Zur Veranschaulichung: Das Werkzeug 700 kann eine oder mehrere Komponenten deaktivieren (oder das Werkzeug 700 vollständig deaktivieren), wenn sich eine Komponente oder ein Signal einem mit den IS-Standards verbundenen Schwellenwert annähert oder ihn übersteigt. Dementsprechend kann ein Benutzer, wenn das Werkzeug 700 IS-konform ist, das Werkzeug 700 mit dem Feldgerät 760 oder mit einem Link (z. B. einer HART-Schleife oder einem Fieldbus-Segment) verbinden, mit dem das Feldgerät 760 verbunden ist, im Vertrauen, dass er die IS-Standards nicht verletzen wird, und im Vertrauen, dass er eine explosive Atmosphäre nicht entzünden wird. Kurz gesagt, kann das Werkzeug 700, im Gegensatz zu vielen traditionellen tragbaren Stromversorgungen und PTDs, sicher in explosionsgefährdeten Bereichen eingesetzt werden.
Wie erwähnt, erfolgt der Betrieb des Werkzeugs 700 möglicherweise den IS-Standards entsprechend. Das heißt, das Werkzeug 700 kann möglicherweise in explosionsgefährdeten Bereichen gefahrlos verwendet werden, da die Komponenten des Werkzeugs 700 den IS-Standards entsprechend energiebegrenzt und fehlertolerant sein können. Beispielsweise können die Komponenten des Werkzeugs 700 (i) strombegrenzt auf eine Strombegrenzung (z. B. 250 mA, 300 mA, 350 mA usw.), (ii) spannungsbegrenzt auf eine Spannungsgrenze (z. B. 25 V, 29 V, 35 V usw.) und (iii) leistungsbegrenzt auf eine Leistungsgrenze (z. B. 1 W, 1,3 W, 1,5 W usw.) sein. Das Werkzeug 700 kann eine oder mehrere eingebaute Redundanzen (z. B. automatische Abschaltung, redundante Komponenten usw.) aufweisen, um sicherzustellen, dass ein Komponentenversagen nicht dazu führt, dass diese Energiebegrenzungen überschritten werden.
Das Werkzeug 700 kann ein oder mehrere von: einer Anzeige 722, einem Gehäuse 728, Eingabetasten 732 und einem Klappständer 752 umfassen. Das Gehäuse 728 kann als Handgerät geformt und dimensioniert sein. Das Gehäuse 728 kann eine im Wesentlichen rechteckige kubische Form oder jede andere wünschenswerte Form oder Größe (z. B. diagonal gemessen 5 Zoll, 7 Zoll oder 11 Zoll) aufweisen.
Die Anzeige 722 und die Eingabetasten 732 können an einer Vorderseite des Gehäuses angeordnet sein. Die Anzeige 722 kann ein Touchscreen sein, beispielsweise ein kapazitiver Touchscreen, der die Berührungseingabe über eine kapazitive Erfassung erkennt, oder ein resistiver Touchscreen, der die Berührungseingabe über den ausgeübten Druck erkennt. Die Eingabetasten 732 können physische Tasten wie Drucktasten oder multidirektionale Tasten sein. In einigen Fällen sind die Eingabetasten 732 nicht im Werkzeug 700 enthalten.
Der Klappständer 752 kann zwischen einer flachen Position gegen die Rückseite des Gehäuses 728 und einer nach außen geschwenkten Position von der Rückseite des Gehäuses 728 schwenken. In der flachen Position kann ein Benutzer das Werkzeug 700 tragen und das Werkzeug 700 in ähnlicher Weise benutzen, wie man einen Tablet-Computer benutzen würde. In der nach außen geschwenkten Position kann der Klappständer 752 verwendet werden, um das Wartungswerkzeug 700 in aufrechter Position zu stützen. In einigen Fällen ist der Klappständer 752 nicht im Werkzeug 700 enthalten.
12 stellt ein detaillierteres Blockdiagramm eines beispielhaften Werkzeugs 700 dar. In dieser Ausführungsform enthält das Werkzeug 700 einen aktiven Kommunikator 804 und eine physische Kommunikationsschnittstelle 806, die elektrisch über elektrische Verbindungen 816 und 817 mit dem aktiven Kommunikator 804 verbunden ist, so dass der aktive Kommunikator 804 über die physische Kommunikationsschnittstelle 806 das Feldgerät 760 mit Strom versorgen und mit ihm kommunizieren sowie eine oder mehrere elektrische Eigenschaften von Signalen messen kann, die von dem aktiven Kommunikator 804 gesendet oder empfangen wurden. Wie dargestellt, kann die Kommunikationsschnittstelle 806 durch das Gehäuse 728 so angeordnet sein, dass ein externer Abschnitt der Schnittstelle 806 außerhalb des Gehäuses 728 zugänglich ist, so dass die drahtgebundene Kommunikationsverbindung 750 und das Feldgerät 760 mit der Schnittstelle 806 verbunden werden können.
Der aktive Kommunikator 804 ermöglicht es dem Werkzeug 700, mit dem Feldgerät 760 zu kommunizieren, das Feldgerät 760 zu diagnostizieren, das Feldgerät 760 mit Strom zu versorgen und/oder eine Kommunikationsverbindung in einer Betriebsanlagenumgebung zu diagnostizieren, mit der das Feldgerät 760 verbunden ist (nicht dargestellt). In einigen Fällen kann der aktive Kommunikator 804 konfiguriert sein, um mit mehreren verschiedenen Arten von Feldgeräten (z. B. HART-Feldgeräte und Fieldbus-Feldgeräte) zu kommunizieren und sie zu diagnostizieren, und/oder er kann so konfiguriert sein, dass er den IS-Standards entspricht, so dass er verwendet werden kann, um mit Feldgeräten in explosionsgefährdeten Bereichen zu kommunizieren, sie zu diagnostizieren und mit Strom zu versorgen. Eine oder mehrere Stromversorgungen des aktiven Kommunikators 804 können Schalter zum Deaktivieren der Stromversorgungen enthalten.
Der aktive Kommunikator 804 kann eine Stromversorgung zum Zuführen von Strom zu dem Feldgerät 760, einen Signalcodierer und einen -decodierer (z. B. ein Modem) zum Kommunizieren mit dem Feldgerät 760 und/oder Energiemessschaltungen (z. B. ein Voltmeter und/oder Amperemeter) zum Messen elektrischer Eigenschaften von Signalen umfassen, die von dem aktiven Kommunikator 804 gesendet und empfangen werden. Der aktive Kommunikator 804 kann über die elektrischen Verbindungen 816 und 817 Kommunikationssignale zu dem Feldgerät 760 senden oder von ihm empfangen. Der aktive Kommunikator 804 kann Kommunikationssignale durch Modulieren einer Stromstärke oder einer Frequenz codieren, um einen analogen oder digitalen Wert darzustellen, und kann das Kommunikationssignal auf ein Leistungssignal überlagern, um ein zusammengesetztes Signal zu erzeugen. In einigen Fällen ist die physische Kommunikationsschnittstelle 808 nicht im Werkzeug 700 enthalten.
Das Werkzeug 700 kann eine Steuereinheit 802 umfassen, die kommunikativ mit dem aktiven Kommunikator 804 über einen Kommunikationsbus 814 gekoppelt ist, welcher ausgebildet ist, um den aktiven Kommunikator 804 zu steuern und zu überwachen. Auf einem hohen Pegel kann die Steuereinheit 802 Komponenten des aktiven Kommunikators 804 aktivieren und deaktivieren, um: (i) den aktiven Kommunikator 804 so zu konfigurieren, dass er in Übereinstimmung mit IS-Standards energiebegrenzt bleibt, (ii) den aktiven Kommunikator 804 so konfigurieren, dass er gemäß einem gewünschten Kommunikationsprotokoll (z. B. HART oder Fieldbus) kommuniziert, (iii) den aktiven Kommunikator 804 als Reaktion auf eine an der physischen Kommunikationsschnittstelle 806 vorgenommene Verbindung konfigurieren (z. B. basierend darauf, ob ein Benutzer die Kommunikationsverbindung 750 mit einem Anschlusssatz für HART oder einem Anschlusssatz für Fieldbus verbindet), und/oder (iv) den aktiven Kommunikator 804 für eine bestimmte Feldgeräte-Konfiguration oder einen bestimmten Feldgerät-Typ (z. B. Aktor oder Sender) zu konfigurieren. Allgemein gesprochen ist ein Sender ein Feldgerät, das ausgebildet ist, um eine Messung (z. B. über einen Temperaturfühler, einen Druckfühler, einen Durchflusssensor, einen Niveausensor usw.) zu erhalten und die Messung zu übertragen. Konfiguration oder Art des Feldgerätes kann auf der Grundlage der Benutzereingabe oder auf der Grundlage der Kommunikation mit dem verbundenen Feldgerät bestimmt werden.
Die Steuereinheit 802 kann einen Prozessor 822, einen Speicher 824, der eine oder mehrere Routinen speichert, und eine E/A-Schnittstelle 826 umfassen, die über den Bus 814 kommunikativ mit anderen Komponenten des Werkzeugs 100 gekoppelt ist. Die in dem Speicher 824 gespeicherten Routinen können eine Kommunikationsmanager-Routine 862 zum Aktivieren und Deaktivieren von Komponenten des aktiven Kommunikators 804, wie oben beschrieben, und eine Client-Anwendungsroutine 864 umfassen, die mit dem Feldgerät 760 kommuniziert.
Das Werkzeug 700 kann auch eine Benutzerschnittstelle 810 umfassen, die kommunikativ mit der Steuereinheit 802 über den Bus 814 gekoppelt ist, um eine Benutzerschnittstelle zu schaffen und/oder eine Benutzereingabe (z. B. Touch-Eingabe) zu erfassen, die an der Benutzerschnittstelle 810 empfangen wird. Die Steuereinheit 802 kann die Benutzerschnittstelle an der Benutzerschnittstelle 810 bereitstellen und die Benutzereingabe an der Benutzerschnittstelle 810 durch Ausführen eines in dem Speicher 824 gespeicherten Benutzerschnittstellen-Managers 866 erfassen. Die Benutzerschnittstelle 810 kann die in 11 gezeigte Anzeige 722, wo die Steuereinheit 802 eine visuelle Ausgabe machen kann, sowie ein Audiogerät 844 zur Erbringung von Audioausgaben umfassen. Beispielsweise kann die Benutzerschnittstelle 810 eine grafische Benutzerschnittstelle darstellen, die es einem Benutzer ermöglicht, ein Asset-Management-System auszuwählen, ein Feldgerät auszuwählen, ein Kommunikationsprotokoll für die Kommunikation mit dem Feldgerät auszuwählen, um einen Befehl auszuwählen, der an das Feldgerät übermittelt werden soll, um von dem Feldgerät zu dem Werkzeug 700 übertragene Informationen anzuzeigen usw. Das Audiogerät 844 kann Audio-Alarme oder Benachrichtigungen erzeugen, beispielsweise als Reaktion auf durch das Feldgerät 760 übertragene Alarme.
Ferner kann das Werkzeug 700 eine Leistungsüberwachung 808 (z. B. ein Amperemeter) umfassen, die kommunikativ mit der Steuereinheit 802 über den Bus 814 gekoppelt ist, um einen Strom oder eine Spannung zu messen, der/die mit der Kommunikationsverbindung 750, welche mit der Schnittstelle 806 verbunden ist, in Zusammenhang steht. Der Diagnosemanager 864 der Steuereinheit 802 kann die Leistungsüberwachung 808 verwenden, um ein Signal zu messen, das von dem Werkzeug 700 gesendet und/oder empfangen wird, um zu bestimmen, ob das Signal elektrische Eigenschaften innerhalb eines für ein bestimmtes Protokoll erwarteten Bereichs aufweist. Wenn beispielsweise ein Benutzer das Werkzeug 700 verwendet, um zu versuchen, einem HART-Ventil zu befehlen, sich auf 50 % zu öffnen, kann die Leistungsüberwachung 808 verwendet werden, um sich zu vergewissern, dass das gesendete Signal einen Strom auf oder nahe einem Pegel (z. B. 12 mA) aufweist, der dem HART-Ventil die richtige Interpretation des Signals erlaubt. Der Benutzerschnittstellen-Manager 864 kann von der Leistungsüberwachung 808 gewonnene Messungen anzeigen. In einigen Fällen ist die Leistungsüberwachung 808 nicht im Werkzeug 700 enthalten. Unabhängig davon, ob das Werkzeug 700 die Leistungsüberwachung 808 enthält, kann sich das Werkzeug 700 auf elektrische Messungen stützen, die durch den aktiven Kommunikator 804 gewonnen wurden.
Das Werkzeug 700 kann auch eine drahtlose Kommunikationsschnittstelle 812 umfassen, die über den Bus 814 kommunikativ mit der Steuereinheit 802 gekoppelt ist, um drahtlose Signale zu senden und/oder zu empfangen, so dass das Werkzeug 700 mit anderen Komponenten der Betriebsanlage, insbesondere mit den drahtlosen Zugangspunkten 720, über drahtlose Kommunikationskanäle innerhalb der Betriebsanlage kommunizieren kann. Die drahtlose Schnittstelle 812 kann ein oder mehrere zweckgerechte drahtlose Protokolle wie WLAN (z. B. ein 802.11-Protokoll), Bluetooth (z. B. 2,4 bis 2,485 GHz), Nahfeldkommunikation (z. B. 13,56 MHz), Hochfrequenzsysteme (z. B. Kommunikationssysteme mit 900 MHz, 2,4 GHz und 5,6 GHz) usw. unterstützen.
In 13 ist ein Block und ein schematisches Diagramm des Werkzeugs 700a–700c (einzeln als „Werkzeug 700“ bezeichnet) in Verbindung mit einem Prozesssteuerungs-Asset-Management-System 900 wie beispielsweise den von Emerson Process Management vertriebenen Systemen AMS Suite^TM oder AMS Device Manager^TM dargestellt. Das tragbare industrielle Rechengerät 112, das kommunikativ mit dem Backbone 105 in 1 oben links gekoppelt ist, kann dem Werkzeug 700 entsprechen. In dem in 13 dargestellten Beispiel umfasst das Asset-Management-System 900 einen Asset-Management-Server 902, beispielsweise eine Asset-Management-Serverstation. Der Server 150 von 1 oder ein industrielles Rechengerät auf der Betriebsanlagennetzwerkebene (z. B. die Workstation 268) kann als Asset-Management-Serverstation implementiert sein. In einer Ausführungsform ist der Asset-Management-Server 902 eine eigenständige Station, die Asset-Management-Routinen zum Steuern, Diagnostizieren, Vorhersagen, Dokumentieren, Konfigurieren und anderweitigen Verwalten eines oder mehrerer Feldgeräte 904 dazu durch Betriebsanlagenserver, Modems (z. B. ein HART-Modem) und verschiedene Systemschnittstellen 906 ausführt. Die Feldgeräte 904 sind über einen digitalen Prozesskommunikationskanal, beispielsweise über das Betriebsanlagennetzwerk 204 und das Steuerungsnetzwerk 206, mit den Systemschnittstellen 906 verbunden. Obwohl er als ein einzelner Server dargestellt ist, kann der Asset-Management-Server 902 als mehrere Server vorgesehen werden, wie z. B. als ein Array von Servern oder als individuelle Server. Der Asset-Management-Server 902 umfasst eine Datenbank 908 mit Informationen über jedes der Feldgeräte, industriellen Rechengeräte, Benutzer, Geräteberechtigungen und/oder Benutzerberechtigungen in dem Asset-Management-Gesamtsystem 900. Der Asset-Management-Server 902 führt die Asset-Management-Anwendungen aus, beispielsweise die von Emerson Process Management vertriebene Anwendung AMS Device Manager^TM.
Damit die Werkzeuge 700a–700c mit dem Asset-Management-System 900 kommunizieren können, umfasst der Asset-Management-Server 902 einen Feldwartungswerkzeug-Kommunikationsserver 910. Obwohl er als ein einzelner Server dargestellt ist, kann der Werkzeugkommunikationsserver 910 als mehrere Server vorgesehen werden, z. B. als ein Array von Servern oder als individuelle Server, um eine beliebige Anzahl von Werkzeugen bedienen zu können. Der Werkzeugkommunikationsserver 910 kann für jedes industrielle Rechengerät und insbesondere für tragbare industrielle Rechengeräte verwendet werden, die eine Verbindung mit dem Asset-Management-System 900 benötigen oder mit diesem in Kommunikation stehen müssen. Der Werkzeugkommunikationsserver 910 umfasst eine Prozesssteuerungs-Messaging-Systemarchitektur 912 ähnlich der oben beschriebenen Prozesssteuerungs-Messaging-Systemarchitektur 300, wo die Prozesssteuerungs-Messaging-Systemarchitektur als eine Abstraktionsschicht dargestellt ist, die ein dediziertes Kommunikationsprotokoll des Prozesssteuerungs-Messaging-Dienstes über dem Netzwerkkommunikationsprotokoll und ein dem Kommunikationsprotokoll des Prozesssteuerungs-Messaging-Dienstes überlagertes Prozesssteuerungs-Kommunikationsprotokoll (z. B. Fieldbus, HART usw.) aufweist. Jedes Werkzeug 700a–700 weist ebenfalls eine entsprechende Prozesssteuerungs-Messaging-Architektur 914a–914c auf (einzeln als „Prozesssteuerungs-Messaging-Architektur 914“ bezeichnet). Unter Verwendung der Prozesssteuerungs-Messaging-Architektur 912, 914a–914c können der Werkzeugkommunikationsserver 910 bzw. die Werkzeuge 700a–700c jeweils eine Nachricht im Prozesssteuerungs-Kommunikationsprotokoll des Zielgerätes (z. B. Fieldbus, HART usw.) erzeugen, die Nachricht im Kommunikationsprotokoll des Prozesssteuerungs-Messaging-Dienstes verpacken und die verpackte Nachricht dem in der Transportschicht definierten Netzwerkkommunikationsprotokoll entsprechend übertragen.
Der Werkzeugkommunikationsserver 910 ist mit einer gemeinsam genutzten dynamischen Werkzeugbibliothek 916 verknüpft, welche die Schnittstellen für die Werkzeuge 700a–700c zur Verbindung mit einem Feldgerät 904, zum Senden von Befehlen an das Feldgerät 904, zum Empfangen von Antworten von dem Feldgerät 904 und zum Trennen der Kommunikation mit dem Feldgerät 904 zur Verfügung stellt. In der in 13 gezeigten Ausführungsform ist die gemeinsam genutzte dynamische Bibliothek 916 eine dynamische Verknüpfungsbibliothek (Dynamic Link Library), die mit dem Werkzeugkommunikationsserver 910 und mit einem Validierungswerkzeug 918 zum Validieren jedes der Werkzeuge 700a–700c verbunden ist, wie sie im Asset-Management-System 900 registriert und im Prozesssteuerungs-Messaging-Dienst angemeldet sind. Das Validierungswerkzeug 918 kann darüber hinaus das Werkzeug und einen Benutzer des Werkzeugs als berechtigt für die Kommunikation mit einem angeforderten Feldgerät auf der Grundlage einer vorherigen Registrierung und/oder Anmeldung des Werkzeugs validieren.
Obwohl der Asset-Management-Server 902 in der Ausführungsform von 13 als ein eigenständiger Server dargestellt ist, kann das Asset-Management-System 900, wie erwähnt, mehrere Asset-Management-Server, beispielsweise ein Server-Array oder individuelle Server, umfassen, um eine beliebige Anzahl von Feldgeräten 904 bedienen zu können. Beispielsweise kann in einer weiteren Ausführungsform das Asset-Management-System 900 ein verteiltes System sein, in welchem die Asset-Management-Serverstation 902 wirksam mit einer oder mehreren Client-Stationen 920, beispielsweise den Workstations 260 von 2, über eine drahtgebundene oder drahtlose Verbindung gekoppelt ist. Jede Client-Station 920 kann als eine Asset-Management-Serverstation operieren, die Asset-Management-Anwendungen und Betriebsanlagenserver, Modems (z. B. ein HART-Modem) und verschiedene Systemschnittstellen 922 ausführt. Die Feldgeräte 924 können mit der/den Systemschnittstelle(n) 922 einer beliebigen Client-Station 920 über den digitalen Prozesskommunikationskanal verbunden sein oder anderweitig kommunikativ gekoppelt sein. Jede Client-Station greift aus der Entfernung auf die Datenbank 908 auf dem Asset-Management-Server 902 zu, während die gemeinsam genutzte dynamische Bibliothek 916 das Routing zwischen dem Werkzeugkommunikationsserver 910 und den mit der Client-Station 920 verbundenen Feldgeräten 924 übernimmt. In einigen Ausführungsformen kann die Client-Station 920 eine mobile Workstation sein, die über eine drahtlose Netzwerkverbindung mit dem Asset-Management-Server 902 verbunden ist.
In 14A–14C sind beispielhafte Datentabellen veranschaulicht, die von dem Asset-Management-Server 902 erzeugt und in einer oder mehreren Datenbanken, beispielsweise der Datenbank 908, oder in dem Werkzeug-Validierer 918 gespeichert werden können. Die beispielhaften Datentabellen sind lediglich zur Veranschaulichung dargestellt; die zugehörige Funktionalität kann unter Verwendung eines geeigneten Formats und/oder eines Entwurfs zum Erzeugen, Speichern und Abrufen von Berechtigungen, Benutzern, industriellen Rechengeräten und Zuordnungen zwischen den Berechtigungen, Benutzern und industriellen Rechengeräten implementiert werden. Dementsprechend können die Berechtigungen und Zuordnungen zwischen Berechtigungen, Benutzern und industriellen Rechengeräten in jeder beliebigen geeigneten Weise erzeugt, gespeichert und abgerufen werden. Zwar enthält jede Datentabelle ein paar Einträge, dies dient jedoch lediglich zur Vereinfachung der Darstellung. Jede Datentabelle kann mehrere zehn, Hunderte, Tausende oder jede geeignete Anzahl von Dateneinträgen enthalten.
In 14A ist eine beispielhafte Berechtigungsdatentabelle 930 dargestellt, welche Angaben über mehrere Berechtigungen enthält. Jede Berechtigung kann eine Berechtigungs-ID 932 enthalten, die die Berechtigung eindeutig kennzeichnet. Jede Berechtigung kann auch ein Prozesssteuerungsgerät 934 umfassen, auf das über die Berechtigung (z. B. Feldgerät A, Feldgerät B) zugegriffen werden kann, und eine Zugriffsart der Berechtigung 936 (z. B. Nur-Lesen, Lesen/Schreiben). Zusätzlich können die Berechtigungen einen Bereich der Betriebsanlage umfassen, in dem der Zugriff zugelassen ist 938 (z. B. Betriebsanlagenbereich A, Betriebsanlagenbereich B). Der Bereich kann ein bestimmter Raum innerhalb der Prozessanlage sein, kann unter Verwendung eines Schwellenradius um den Ort eines bestimmten Prozesssteuerungsgerätes bestimmt werden, kann ein Gebäude innerhalb der Prozessanlage sein oder kann jeder andere geeignete Bereich sein. Auf diese Weise kann ein Benutzer nur dann auf ein bestimmtes Prozesssteuerungsgerät zugreifen, wenn sich der Benutzer in der Nähe des Prozesssteuerungsgerätes befindet. Einige Berechtigungen können darauf hinweisen, dass der Zugriff für alle Bereiche zulässig ist.
Des Weiteren können die Berechtigungen Funktionen 940 umfassen, die der Benutzer ausführen kann, um Operationen an dem entsprechenden Prozesssteuerungsgerät auszuführen (z. B. Konfigurieren, Kalibrieren, Fehler beheben, Überwachen, Steuern). In einigen Ausführungsformen können die Funktionen auf der Art des Zugriffs basieren, der in der Berechtigung 936 enthalten ist. Wenn beispielsweise die Berechtigung einen schreibgeschützten Zugriff enthält, ist es dem Benutzer gegebenenfalls nicht möglich, eine Konfigurationsfunktion auszuführen, die das Schreiben in das Prozesssteuerungsgerät erfordert. Die Funktionen können Softwareanwendungen auf einem vom Benutzer gesteuerten industriellen Rechengerät sein oder Funktionsfähigkeiten einer Softwareanwendung sein. Beispielsweise können die Berechtigungen festlegen, auf welche Softwareanwendungen der Benutzer auf dem industriellen Rechengerät zugreifen kann, wenn das industrielle Rechengerät mit einem bestimmten Prozesssteuerungsgerät verbunden ist oder dieses anfordert. Die Berechtigungen können auch festlegen, welche Funktionsfähigkeiten für den Benutzer mit einer bestimmten Softwareanwendung zugänglich sind. Einige Berechtigungen können darauf hinweisen, dass der Zugriff allen Funktionsbereichen erlaubt ist.
Darüber hinaus kann jede Berechtigung eine Zeitdauer 942 umfassen, innerhalb welcher auf ein entsprechendes Prozesssteuerungsgerät zugegriffen werden kann. Die Zeitdauer kann unbegrenzt sein oder kann eine Schwellenzeit für den Zugriff (z. B. 30 Minuten, 1 Stunde, 3 Stunden usw.) umfassen. Auf diese Weise kann ein Benutzer Zugriff auf ein Prozesssteuerungsgerät für eine Schwellendauer haben; sobald die Zeit abläuft, ist der Benutzer möglicherweise nicht mehr in der Lage, mit dem Prozesssteuerungsgerät zu interagieren. Die Dauer kann auch nach einem bestimmten oder wiederkehrenden Tag, einer Woche, einem Monat usw. (z. B. jeden zweiten Dienstag) geplant werden.
Während die beispielhafte Berechtigungsdatentabelle 930 die Datenfelder Berechtigungs-ID 932, Gerät 934, Zugriffsarten 936, Betriebsanlagenbereich 938, Funktionen 940 und Dauer 942 enthält, können bei jeder Berechtigung zusätzliche, weniger oder alternative Datenfelder enthalten sein. In einigen Ausführungsformen können die Berechtigungen von einem Systemadministrator über eine Benutzerschnittstelle auf dem Asset-Management-Server 902 erzeugt werden.
Zusätzlich zu dem Erzeugen der Berechtigungen kann der Asset-Management-Server 902 den Benutzern und den industriellen Rechengeräten in der Prozessanlage die Berechtigungen zuordnen. Ein Benutzer, dem eine Berechtigung zugeordnet ist, kann bei der Verwendung eines industriellen Rechengerätes Zugriff auf das in der Berechtigung enthaltene Prozesssteuerungsgerät erhalten. In einigen Ausführungsformen kann das industriellen Rechengerät auch die Gewährung des Zugriffs auf das Prozesssteuerungsgerät erfordern, damit der Benutzer auf das Prozesssteuerungsgerät zugreifen kann, wenn er das industrielle Rechengerät verwendet. In anderen Ausführungsformen kann der Benutzer, wenn einem der Benutzer und dem industriellen Rechengerät die Berechtigung zum Zugriff auf das Prozesssteuerungsgerät erteilt wurde, über das industrielle Rechengerät auf das Prozesssteuerungsgerät zugreifen.
In jedem Fall veranschaulicht 14B eine beispielhafte Benutzerdatentabelle 950, die Angaben über mehrere Benutzer enthält, die in der Prozessanlage arbeiten. Die Benutzerdatentabelle 950 kann verwendet werden, um für jeden Benutzer Benutzerprofile zu erzeugen. Jeder Benutzer kann eine Benutzer-ID 952 (z. B. 0001, 0002, 0003, XXY, AAC usw.) haben, die den Benutzer eindeutig identifiziert. Jeder Benutzer kann auch eine zugeordnete Aufgabenfunktion 954 innerhalb der Prozessanlage (z. B. Konfigurationsingenieur, Wartungstechniker usw.) haben.
Eine Gruppe von Benutzern kann auch einer Sicherheitsgruppe 956 zugeordnet werden, wobei jedem der Mitglieder einer Sicherheitsgruppe dieselben Berechtigungen zugeordnet werden können. Beispielsweise kann eine erste Sicherheitsgruppe Berechtigungen 1–4 enthalten. Wenn ein Benutzer der ersten Sicherheitsgruppe zugeordnet ist, wird dem Benutzer auch automatisch jede der Berechtigungen 1–4 zugeordnet. Auf diese Weise muss ein Systemadministrator nicht mehreren Benutzern einen gleichen Satz von Berechtigungen zuordnen.
Der Systemadministrator kann einer Sicherheitsgruppe über eine Benutzerschnittstelle auf dem Asset-Management-Server 902 Berechtigungen zuordnen. Beispielsweise kann der Systemadministrator Angaben zu Berechtigungen anzeigen, die zuvor der Sicherheitsgruppe zugeordnet worden sind, und diese in eine Kennung für eine neue Berechtigung eingeben, die der Sicherheitsgruppe zuzuordnen ist (z. B. eine Berechtigungs-ID); er kann die Berechtigung aus mehreren Berechtigungen in einem Dropdown-Menü auswählen oder die Berechtigung der Sicherheitsgruppe in anderer geeigneter Weise zuordnen.
In einigen Ausführungsformen können Mitglieder einer Sicherheitsgruppe Benutzer umfassen, die ein Attribut innerhalb der Prozessanlage, beispielsweise eine gleiche Aufgabenfunktion oder Rolle innerhalb der Prozessanlage, gemeinsam haben. Zum Beispiel kann eine erste Sicherheitsgruppe für Konfigurationsingenieure bestimmt sein, eine zweite Sicherheitsgruppe kann für Wartungstechniker bestimmt sein, eine dritte Sicherheitsgruppe für Betriebsanlagenbetreiber usw. Zusätzlich können Benutzer mehreren Sicherheitsgruppen zugeordnet werden oder können mit vorübergehendem Zugriff auf verschiedene Sicherheitsgruppen ausgestattet werden. Wenn zum Beispiel ein Benutzer vorübergehend außerhalb seiner normalen Aufgabenfunktion eine zusätzliche Aufgabenfunktion wahrzunehmen hat, kann der Benutzer für die zusätzliche Aufgabenfunktion einer anderen Sicherheitsgruppe zugeordnet werden, während der Benutzer auch der Sicherheitsgruppe für seine normale Aufgabenfunktion zugeordnet ist.
In einigen Ausführungsformen wird ein Benutzer automatisch einer Sicherheitsgruppe zugeordnet, die auf der Aufgabenfunktion des Benutzers basiert. In anderen Ausführungsformen ordnet der Systemadministrator dem Benutzer über eine Benutzerschnittstelle auf dem Asset-Management-Server 902 eine Benutzergruppe zu. Beispielsweise kann der Systemadministrator ein Benutzerprofil für den Benutzer anzeigen und in eine Kennung für die Sicherheitsgruppe eingeben, die Sicherheitsgruppe aus mehreren Sicherheitsgruppen in einem Dropdown-Menü auswählen oder den Benutzer einer Sicherheitsgruppe in anderer geeigneter Weise zuordnen.
Die Benutzerdatentabelle 950 kann auch Angaben zu Berechtigungen 958 enthalten, die jedem einzelnen Benutzer zugeordnet sind. In einigen Ausführungsformen können die Berechtigungen, die einem Benutzer zugeordnet sind, den Berechtigungen entsprechen, die den Sicherheitsgruppen des Benutzers zugeordnet sind. Wenn ein Benutzer nicht zu einer Sicherheitsgruppe gehört, oder zusätzlich zu den Berechtigungen, die den Sicherheitsgruppen zugeordnet sind, können die Berechtigungsanzeigen auch dem Benutzer einzeln zugeordnete Berechtigungen enthalten.
Der Systemadministrator kann einem Benutzer über eine Benutzerschnittstelle auf dem Asset-Management-Server 902 Berechtigungen zuordnen. Beispielsweise kann der Systemadministrator ein Benutzerprofil für den Benutzer anzeigen und in eine Kennung für die Berechtigung (beispielsweise eine Berechtigungs-ID) eingeben, die Berechtigung aus mehreren Berechtigungen in einem Dropdown-Menü auswählen oder dem Benutzer eine Berechtigung in anderer geeigneter Weise zuordnen.
Während die beispielhafte Berechtigungsdatentabelle 950 die Datenfelder Benutzer-ID 952, Aufgabenfunktion 954, Sicherheitsgruppe 956 und Berechtigungen 958 enthält, können für jeden Benutzer zusätzliche, weniger oder alternative Datenfelder enthalten sein. Beispielsweise kann die Benutzerdatentabelle 950 auch ein Datenfeld Name, ein Datenfeld Geburtsdatum, ein Datenfeld Wohnanschrift, ein Datenfeld Datum des Beschäftigungsbeginns, Datenfelder für Benutzername und Kennwort usw. enthalten.
In 14C ist eine beispielhafte industrielle Rechengeräte-Datentabelle 960 dargestellt, die Angaben zu industriellen Rechengeräten innerhalb der Prozessanlage enthält. Jedes industrielle Rechengerät kann eine industrielle Rechengeräte-ID 962 (z. B. UI01, UI02, UI03, XXX, BBZ usw.) aufweisen, die das industrielle Rechengerät eindeutig identifiziert. Die industrielle Rechengeräte-Datentabelle 960 kann auch Anzeigen von Berechtigungen 964 enthalten, die den einzelnen industriellen Rechengeräten zugeordnet sind.
Der Systemadministrator kann einem industriellen Rechengerät über eine Benutzerschnittstelle auf dem Asset-Management-Systemserver 902 Berechtigungen zuordnen. Beispielsweise kann der Systemadministrator ein Profil für das industrielle Rechengerät anzeigen und in eine Kennung für die Berechtigung eingeben (z. B. eine Berechtigungs-ID), die Berechtigung aus mehreren Berechtigungen in einem Dropdown-Menü auswählen oder die Berechtigung dem industriellen Rechengerät in anderer sachgerechter Weise zuordnen.
Zusätzlich zu den Berechtigungen, die den industriellen Rechengeräten zugeordnet sind, kann jedes industrielle Rechengerät lizenzierte Funktionen 966 oder lizenzierte Software aufweisen. Beispielsweise kann die Prozessanlage eine Lizenz für eine Softwareanwendung auf einem industriellen Rechengerät erhalten, ohne die Lizenz auf einem anderen industriellen Rechengerät zu erhalten. Selbst wenn dem industriellen Rechengerät die Berechtigung zur Ausführung einer bestimmten Funktion durch den Systemadministrator gemäß den dem industriellen Rechengerät zugeordneten Berechtigungen erteilt wird, darf das industrielle Rechengerät die Funktion möglicherweise nicht ausführen, wenn die Funktion auf dem industriellen Rechengerät nicht lizenziert ist. Beispielsweise ist dem industriellen Rechengerät UI01 die Berechtigung 1 zugeordnet, die dem industriellen Rechengerät UI01 die Berechtigung für die Ausführung von Kalibrierfunktionen auf Feldgerät A gewährt. Jedoch ist gemäß den lizenzierten Funktionen 966 für das industrielle Rechengerät UI01 das industrielle Rechengerät UI01 für die Ausführung von Kalibrierfunktionen nicht lizenziert (z. B. ist die Kalibriersoftware nicht auf dem industriellen Rechengerät UI01 lizenziert). Daher führt das industrielle Rechengerät UI01 die Kalibriersoftware zum Kalibrieren von Feldgerät A nicht aus.
Während die beispielhafte industrielle Rechengeräte-Datentabelle 960 die Datenfelder industrielles Rechengerät ID 962, Berechtigungen 964 und lizenzierte Funktionen 966 enthält, können für jedes industrielle Rechengerät zusätzliche, weniger oder alternative Datenfelder enthalten sein. Beispielsweise kann die industrielle Rechengeräte-Datentabelle 960 auch ein Datenfeld Position enthalten, das die Position innerhalb der Prozessanlage angibt, in der das industrielle Rechengerät bei Nichtgebrauch aufbewahrt wird. Zusätzlich kann die industrielle Rechengeräte-Datentabelle 960 Hersteller und Modell des industriellen Rechengerätes, Systeminformationen zum industriellen Rechengerät usw. umfassen.
In einigen Ausführungsformen kann der Asset-Management-Server 902 periodisch Daten von jeder der Datentabellen 940, 950, 960, wie in den 14A–14C dargestellt, an die industriellen Rechengeräte in der Prozessanlage übertragen, zumindest soweit sie sich auf das einzelne industrielle Rechengerät beziehen. Wenn ein Benutzer versucht, auf eines der industriellen Rechengeräte zuzugreifen, kann das industrielle Rechengerät eine Validierung/Authentifizierung des Benutzers durchführen. Wenn der Benutzer authentifiziert ist, kann das industrielle Rechengerät unter Verwendung der Daten eine Berechtigungsebene für den Benutzer bestimmen.
Die 15 bis 18 sind Flussdiagramme, welche Prozesse des Werkzeugs 700, des Werkzeugkommunikationsservers 910 und der gemeinsam genutzten dynamischen Werkzeugbibliothek 916 für die Kommunikation zwischen dem Werkzeug 700 und einem Feldgerät 924 darstellen. In dem folgenden Beispiel kommuniziert das Werkzeug 700 mit dem Werkzeugkommunikationsserver 910 über das Prozesssteuerungs-Messaging-Netzwerk 200 und verwendet die Prozesssteuerungs-Messaging-Dienste, um mit dem Feldgerät 924 unter Verwendung der oben beschriebenen Prozesssteuerungs-Messaging-Systemarchitektur zu kommunizieren. Als solches ist das Werkzeug 700 in der Lage, sich unter Verwendung des digitalen Prozesskommunikationskanals des Prozessleitsystems (z. B. des Kommunikationssystems von den Asset-Management-Systemstationen 902, 920 und den Feldgeräten 904, 924) kommunikativ mit dem Feldgerät 924 zu koppeln, Befehle an das Feldgerät 924 zu senden, Antworten von dem Feldgerät 924 zu empfangen und sich von dem Feldgerät 924 zu trennen.
Unter Bezugnahme auf 15 wird ein Werkzeugverbindungs- und Kommunikationsprozess (der „Werkzeugprozess 1000“) durch das Werkzeug 700 ausgeführt, bei welchem eine in einem Speicher 824 des Werkzeugs 700 gespeicherte Client-Anwendung 864 bei Block 1002 initiiert wird. Sobald die Client-Anwendung 864 kommunikativ mit dem Feldgerät gekoppelt ist, gibt die Client-Anwendung 864 Rohbefehle aus, um das Feldgerät zu steuern. Im Allgemeinen ist ein Rohbefehl an das Feldgerät ein Befehl in der nativen Sprache oder dem nativen Protokoll des Feldgerätes. Wenn beispielsweise das Feldgerät ein HART^®-Feldgerät ist, ist der Rohbefehl zum Feldgerät ein HART-Befehl (d. h. ein Befehl im HART^®-Kommunikationsprotokoll). In gleicher Weise gilt, wenn das Feldgerät ein Foundation^®-Fieldbus-Gerät ist, ist der Rohbefehl zum Feldgerät ein Foundation^®-Fieldbus-Kommentar (d.h. ein Befehl im Foundation^®-Fieldbus-Kommunikationsprotokoll).
In einem Beispiel ist die Client-Anwendung 864 eine dedizierte Anwendung zum Steuern eines ausgewählten Feldgerätes über den digitalen Prozesskommunikationskanal des Prozessleitsystems, wobei die Anwendung 864 zumindest in der Lage ist, Rohbefehle (Lesen und/oder Schreiben) an das ausgewählte Feldgerät auszugeben. In einem anderen Beispiel ist die Client-Anwendung 864 ein Klon einer vom Asset-Management-Server 902 ausgeführten Asset-Management-Anwendung. Tatsächlich ist das Werkzeug 700 eine Client-Station, die als eine Asset-Management-Serverstation operiert, welche den Asset-Management-Anwendungsklon ausführt, jedoch an Stelle einer Schnittstelle zur direkten Verbindung und Kommunikation mit dem Feldgerät, beispielsweise der physischen Kommunikationsschnittstelle 806, den aktiven Kommunikator 804 und die drahtlose Kommunikationsschnittstelle 812 zur indirekten Kommunikation mit dem Feldgerät über den digitalen Prozesskommunikationskanal verwendet, der das AMS 900 mit den Feldgeräten verbindet.
Unter Verwendung der Client-Anwendung 864 und/oder einer anderen Anwendung, beispielsweise des Benutzerschnittstellen-Managers 866, erzeugt der Werkzeugprozess 1000 auf der Anzeige 722 eine Benutzerschnittstelle, um das Feldgerät 924 bei Block 1004 zu definieren. In einer anderen Ausführungsform kann der Werkzeugprozess 1000 vor oder in Verbindung mit dem Erzeugen einer Anzeige zum Definieren oder Auswählen des Feldgerätes 924 eine Benutzerschnittstelle auf dem Display 722 erzeugen, um das Asset-Management-System zu definieren, mit dem sich das Werkzeug verbinden soll, insbesondere in jenen Fällen, in denen das Werkzeug 700 unter Umständen zur Verbindung mit mehreren Asset-Management-Systemen berechtigt ist. Es kann jedoch der Fall sein, dass der Benutzer und/oder das Werkzeug 700 nur berechtigt sind, eine Verbindung zu einem einzelnen Asset-Management-System herzustellen, wobei in diesem Fall der Werkzeugprozess 700 standardmäßig auf dieses Asset-Management-System zurückgreifen kann.
Allgemein gesprochen hat sich das Werkzeug 700 registriert und/oder angemeldet, sobald die Client-Anwendung 864 bei Block 1002 unter Verwendung der oben beschriebenen Registrierungs- und/oder Anmeldungsprozesse initiiert wurde. Weiterhin weist das Werkzeug 700 eine Identifizierung und Autorisierung(en) des Benutzers für den Zugriff auf das Werkzeug 700 auf. Demgemäß verfügt das Werkzeug 700 über die dem Benutzer und/oder dem Werkzeug 700 zugeordneten Berechtigungen und diese Berechtigungen geben vor, mit welchen Feldgeräten der Benutzer und/oder das Werkzeug 700 zur Herstellung einer Verbindung oder zur Kommunikation berechtigt sind. Als solche kann die Client-Anwendung 864 nur diejenigen Feldgeräte auf der Anzeige 722 anzeigen, für die der Benutzer und/oder das Werkzeug 700 über entsprechende Berechtigungen/Autorisierungen verfügen. In einem anderen Beispiel zeigt die Client-Anwendung 864 Feldgeräte an, die auf der Ebene eines erlaubten Zugriffs auf ein bestimmtes Feldgerät (z. B. Kommunikation, Regelung, Inbetriebnahme, Diagnose usw.) basieren, so dass nur diejenigen Feldgeräte, für die der Benutzer und/oder das Werkzeug 700 die Berechtigung zur Kommunikation besitzen, sowie nur diejenigen Feldgeräte, für die der Benutzer und/oder das Werkzeug 700 die Berechtigung zur Regelung besitzen, sowie nur diejenigen Feldgeräte, für die der Benutzer und/oder das Werkzeug 700 die Berechtigung zur Inbetriebnahme besitzen usw., angezeigt werden. In einem anderen Beispiel kann die Client-Anwendung 864 zum Eingeben einer Geräteidentifikation, beispielsweise einer Kennzeichnung eines Prozesssteuerungsgerätes, welche das Feldgerät eindeutig identifiziert, auffordern, um das Feldgerät zur Kommunikation mit dem Werkzeug 700 spezifisch zu definieren. Um ein Feldgerät für die Kommunikation 1004 zu definieren, ist in jedem Fall die Anzeige der Feldgeräte über das Werkzeug 700 (z. B. über Cursor, physische Schlüssel, Touchscreen usw.) wählbar und/oder sind Feldgeräte auf diese Weise identifizierbar.
Bei Block 1006 authentifiziert/validiert der Werkzeugprozess 1000 den Benutzer und das Werkzeug vor einer Kommunikation zwischen dem Werkzeug 700 und dem Asset-Management-System 900. Insbesondere bestimmt der Werkzeugprozess 1000, ob das Werkzeug 700 bei dem ausgewählten Asset-Management-System 900 (z. B. basierend auf der oben erwähnten Registrierung des Werkzeugs 700 beim Asset-Management-System) registriert worden ist. Zusätzlich kann der Werkzeugprozess 1000 bestimmen, ob der Benutzer über die richtige Zugriffs-/Berechtigungsebene für das ausgewählte Feldgerät 924 auf der Grundlage der oben erwähnten Registrierung und/oder Anmeldung beim Asset-Management-System 900 verfügt. Wenn eine dieser Bedingungen nicht erfüllt ist, kann der Werkzeugprozess 1000 bei Block 1008 einen Fehler an die Benutzerschnittstelle auf dem Werkzeug 700 zurückgeben.
Wenn beispielsweise das Werkzeug 700 mit einem Prozesssteuerungsgerät (z. B. Feldgerät 924) verbunden werden soll, kann das Werkzeug 700 aus dem Speicher 824 eine Kennung, beispielsweise eine Geräte-ID, abrufen, die vom Benutzer aus über die Benutzerschnittstelle 810 das Prozesssteuerungsgerät eindeutig identifiziert (z. B. Feldgerät A, Feldgerät B usw.). In einigen Ausführungsformen kann das Werkzeug 700 während des Anmeldevorgangs eine Benutzer-ID für den Benutzer beziehen. Anschließend kann das Werkzeug einen Satz von Berechtigungen für den Benutzer und für das Werkzeug 700 aus der Benutzerdatentabelle 950 bzw. der Werkzeugdatentabelle 960 abrufen (von denen jede in dem Speicher 824 gespeichert sein kann, soweit die Benutzerdaten und Werkzeugdaten für das jeweilige Werkzeug 700 relevant sind), wobei die Benutzer-ID und die Werkzeug-ID verwendet werden.
In jedem Fall kann das Werkzeug 700 die dem Benutzer und/oder dem Werkzeug 700 zugeordneten Berechtigungen identifizieren, die eine Zugriffsebene auf das mit dem industriellen Rechengerät verbundene Prozesssteuerungsgerät spezifizieren. Wenn keine der Berechtigungen eine Zugriffsebene auf das Prozesssteuerungsgerät angibt, bestimmt das Werkzeug 700, dass der Benutzer keinen Zugriff auf das Prozesssteuerungsgerät hat. Dementsprechend gestattet das Werkzeug 700 dem Benutzer nicht, mit dem Prozesssteuerungsgerät bei Block 1008 zu kommunizieren. In einigen Ausführungsformen kann das Werkzeug 700 eine Nachricht über die Benutzerschnittstelle 810 anzeigen, welche darauf hinweist, dass dem Benutzer der Zugriff auf das verbundene Prozesssteuerungsgerät verweigert wird. Die Nachricht kann eine Erläuterung enthalten, warum dem Benutzer der Zugriff verweigert wird (z. B. weil der Benutzer keine Berechtigung für den Zugriff auf das Prozesssteuerungsgerät hat, das Werkzeug keine Berechtigung für den Zugriff auf das Prozesssteuerungsgerät hat oder weder Benutzer noch Werkzeug eine Berechtigung für den Zugriff auf das Prozesssteuerungsgerät haben). Die Nachricht kann auch Anweisungen für den Zugriff auf das Prozesssteuerungsgerät liefern, beispielsweise Anweisungen zum Abrufen eines Werkzeugs, das die Berechtigung zum Zugriff auf das Prozesssteuerungsgerät hat, oder Anweisungen zur Kontaktaufnahme mit dem Systemadministrator.
Wenn andererseits eine oder mehrere Berechtigungen eine Zugriffsebene auf das Prozesssteuerungsgerät spezifizieren, bestimmt das Werkzeug 700 die Art des Zugriffs, den der Benutzer und/oder das Werkzeug 700 haben können, sowie die Funktionen, die der Benutzer und/oder das Werkzeug 700 durchführen dürfen. Das Werkzeug 700 kann auch einen Bereich identifizieren, in welchem der Benutzer Zugriff auf das angeschlossene Prozesssteuerungsgerät hat. In einigen Ausführungsformen kann das Werkzeug 700 seine Position über einen Positionierungssensor, beispielsweise über ein globales Positionierungssystem (GPS), bestimmen. Das Werkzeug 700 kann dann bestimmen, ob sich die Position innerhalb des Bereichs befindet, in dem der Benutzer Zugriff auf das angeschlossene Prozesssteuerungsgerät hat. Ferner identifiziert das Werkzeug 700 eine Zeitdauer/einen Zeitplan für den Zugriff und kann periodisch die Differenz zwischen der aktuellen Zeit und der Startzeit des Zugriffs auf die Zeitdauer/den Zeitplan vergleichen.
Wenn das Werkzeug 700 und/oder der Benutzer bei Block 1006 validiert sind, initiiert der Werkzeugprozess 1000 eine Verbindungsanforderung bei Block 1010 an das Asset-Management-System 900 über den drahtlosen Kommunikationskanal des Prozesssteuerungsnachrichtennetzes (z. B. über den drahtlosen Zugangspunkt 720). Insbesondere informiert die Verbindungsanforderung das Asset-Management-System 900, dass das Werkzeug 700 und/oder der Benutzer über den digitalen Prozesskommunikationskanal einen Lese- und/oder Schreibzugriff auf das Feldgerät 924 anfordern. Als solche kann die Verbindungsanforderung die Feldgeräte-ID (z. B. die Gerätekennzeichnung), die Benutzer-ID (z. B. eine für den Benutzer eindeutige Kennung) und die ID von Werkzeug 700 (z. B. eine für das Werkzeug 700 eindeutige Kennung) umfassen.
Im Rahmen der Initiierung der Anforderung an das Asset-Management-System 900 bei Block 1010 verwendet das Werkzeug 700 die Prozesssteuerungs-Messaging-Architektur 914, um die Anforderung im Protokoll des Prozesssteuerungs-Messaging-Dienstes zu verpacken. In einer Ausführungsform kann der aktive Kommunikator 804 die Anforderung im Protokoll des Prozesssteuerungs-Messaging-Dienstes verpacken, so dass die Anforderung (z. B. die Feldgeräte-ID, die Benutzer-ID und die Werkzeug-ID) die Nutzlast eines Pakets im Protokoll des Prozesssteuerungs-Messaging-Dienstes bildet, wobei das Prozesssteuerungs-Messaging-Dienstprotokoll einen Header mit Informationen über die Netzwerkadresse oder Identifikation des Werkzeugkommunikationsservers 910 aufweist. Die Anforderung wird dann von der drahtlosen Kommunikationsschnittstelle 812 über den drahtlosen Kommunikationskanal des Asset-Management-Systems 900 an den Werkzeugkommunikationsserver 910 unter Verwendung des Transportprotokolls des drahtlosen Kommunikationskanals übertragen, wobei der Werkzeugkommunikationsserver 910 eine bekannte Netzwerkidentifikation oder Adresse aufweist, die daher dem Werkzeug 700 bekannt ist.
Unter Bezugnahme auf 16 empfängt der Werkzeugkommunikationsserver 910 in einer Werkzeugkommunikationsserververbindung und einem Kommunikationsprozess 1100 (dem „Werkzeugkommunikationsserverprozess 1100“) die Verbindungsanforderung von dem Werkzeug 700 über das Prozesssteuerungs-Messaging-Netzwerk bei Block 1102. Wie oben erwähnt, ermöglicht der Werkzeugkommunikationsserver 910 dem Werkzeug 700, mit dem Asset-Management-System 900 zu kommunizieren. Insbesondere umfasst der Werkzeugkommunikationsserver 910 die Prozesssteuerungs-Messaging-Systemarchitektur 912. Wie die Prozesssteuerungs-Messaging-Systemarchitektur 914 in dem Werkzeug 700 ist auch die Prozesssteuerungs-Messaging-Systemarchitektur 912 für den Werkzeugkommunikationsserver 910 als eine Abstraktionsschicht dargestellt, die ein dediziertes Kommunikationsprotokoll des Prozesssteuerungs-Messaging-Dienstes über dem Netzwerkkommunikationsprotokoll aufweist, und ein Prozesssteuerungsübertragungsprotokoll, das über dem Kommunikationsprotokoll des Prozesssteuerungs-Messaging-Dienstes. geschichtet ist. Unter Verwendung der Prozesssteuerungs-Messaging-Systemarchitektur 912 entpackt der Werkzeugkommunikationsserver 910 die Verbindungsanforderung aus dem Protokoll des Prozesssteuerungs-Messaging-Dienstes oder extrahiert die Verbindungsanforderung anderweitig aus dem Prozesssteuerungs-Messaging-Dienstpaket. Der Werkzeugkommunikationsserver 910 kann dann die Verbindungsanforderung an die gemeinsam genutzte dynamische Werkzeugbibliothek 916, wie z. B. eine dynamische Werkzeug-Verknüpfungsbibliothek (Dynamic Link Library) 916 des Asset-Management-Systems („Werkzeug-DLL 916“), bei Block 1104 übergeben.
Unter Bezugnahme auf 17 empfängt die Werkzeug-DLL 916 in einem Werkzeug-DLL-Verbindungs- und -Kommunikationsprozess 1200 (dem „Werkzeug-DLL-Prozess 1200“) die Verbindungsanforderung von dem Werkzeugkommunikationsserverprozess 1100 bei Block 1202. Unter Verwendung des Werkzeug-Validierers 918 authentifiziert/validiert der Werkzeug-DLL-Prozess 1200 bei Block 1204 den Benutzer und das Werkzeug 700 vor jeder Kommunikation zwischen dem Werkzeug 700 und dem Feldgerät 924. Insbesondere bestimmt der Werkzeug-DLL-Prozess 1200, ob das Werkzeug 700 bei dem Asset-Management-System 900 registriert ist, und stellt unter Umständen fest, ob der Benutzer auf der Grundlage der oben erwähnten Registrierung und/oder Anmeldung beim Asset-Management-System 900 über die richtige Zugriffs-/Autorisierungsebene für das ausgewählte Feldgerät 924 (z. B. zumindest Lesezugriff auf das Feldgerät) verfügt. Wenn eine dieser Bedingungen nicht erfüllt ist, kann der Werkzeug-DLL-Prozess 1200 einen Fehler bei Block 1206 an den Werkzeugkommunikationsserver 910 zurückgeben, der wiederum den Fehler an das Werkzeug 700 zurückgibt, welches den Fehler auf der Benutzerschnittstelle auf dem Werkzeug 700 anzeigen kann. In einer Ausführungsform kann die Anzahl von Werkzeugen 700a–700c, die mit dem Asset-Management-System 900 zu einem beliebigen Zeitpunkt verbunden sein können, begrenzt sein (z. B. aufgrund von Lizenzbeschränkungen, Sicherheitsüberlegungen usw.). Die Werkzeug-DLL 916 kann daher Informationen über die Anzahl von Werkzeugen pflegen, die mit dem Asset-Management-System 900 kommunizieren; falls die Verbindung des in der Verbindungsanforderung an das Asset-Management-System identifizierten Werkzeugs diese Grenze überschreitet, kann die Verbindungsanforderung durch die Werkzeug-DLL 916 abgewiesen und der Fehler bei Block 1206 zurückgegeben werden.
Als Beispiel für die Authentifizierung/Validierung bei Block 1204 kann der Werkzeug-Validierer 918, sobald die Werkzeug-DLL 916 die Verbindungsanforderung empfängt, wie sie von dem Werkzeugkommunikationsserver 910 übergeben wird, die Feldgeräte-ID, die Benutzer-ID und die Werkzeug-ID aus der Verbindungsanforderung abrufen und diese Informationen dem Werkzeug-Validierer 918 übergeben. Anschließend kann der Werkzeug-Validierer 918 einen Satz von Berechtigungen für den Benutzer und für das Werkzeug 700 aus der Benutzerdatentabelle 950 bzw. der Werkzeugdatentabelle 960 (von denen jede in der Datenbank 908 oder in einem Speicher des Werkzeug-Validierers 918 gespeichert sein kann) unter Verwendung der Benutzer-ID und der Werkzeug-ID abrufen.
In jedem Fall kann der Werkzeug-Validierer 918 die dem Benutzer und/oder dem Werkzeug 700 zugeordneten Berechtigungen identifizieren, die eine Zugriffsebene auf das Prozesssteuerungsgerät angeben. Wenn keine der Berechtigungen eine Zugriffsebene auf das Prozesssteuerungsgerät festlegt, bestimmt der Werkzeug-Validierer 918, dass der Benutzer keinen Zugriff auf das Prozesssteuerungsgerät hat. Wenn ferner die zulässige Anzahl von mit dem Asset-Management-System 900 kommunizierenden Werkzeugen ausgeschöpft ist und durch die Verbindung des anfragenden Werkzeugs 700 überschritten würde, bestimmt der Werkzeug-Validierer 918, dass das Werkzeug 700 keinen Zugriff auf das Prozesssteuerungsgerät hat. Dementsprechend gibt der Werkzeug-Validierer 918 einen Fehler an die Werkzeug-DLL 916 zurück, die wiederum den Fehler an den Werkzeugkommunikationsserver 910 zurückgibt, der wiederum den Fehler an das Werkzeug 700 zurückgeben kann. Der Fehler kann eine Erläuterung enthalten, warum dem Benutzer der Zugriff verweigert wird (z. B. weil der Benutzer keine Berechtigung für den Zugriff auf das Prozesssteuerungsgerät hat, das Werkzeug keine Berechtigung für den Zugriff auf das Prozesssteuerungsgerät hat oder weder der Benutzer noch das Werkzeug eine Berechtigung für den Zugriff auf das Prozesssteuerungsgerät haben, oder weil die Anzahl der mit dem Asset-Management-System 900 verbundenen Werkzeuge überschritten ist).
Wenn andererseits eine oder mehrere Berechtigungen eine Zugriffsebene auf das Prozesssteuerungsgerät spezifizieren, bestimmt der Werkzeug-Validierer 918 die Art des Zugriffs, den der Benutzer und/oder das Werkzeug 700 haben kann, sowie die Funktionen, die der Benutzer und/oder das Werkzeug 700 durchführen dürfen. Der Werkzeug-Validierer 918 kann auch einen Bereich identifizieren, in dem der Benutzer Zugriff auf das angeschlossene Prozesssteuerungsgerät hat. In einigen Ausführungsformen kann der Werkzeug-Validierer 918 die Position des Werkzeugs 700 mithilfe eines Positionierungssensors, beispielsweise eines globalen Positionierungssystems (GPS), bestimmen. Der Werkzeug-Validierer 918 kann dann bestimmen, ob sich die Position innerhalb des Bereichs befindet, in dem der Benutzer Zugriff auf das angeschlossene Prozesssteuerungsgerät hat. Ferner identifiziert der Werkzeug-Validierer 918 eine Zeitdauer/einen Zeitplan für den Zugriff und kann periodisch die Differenz zwischen der aktuellen Zeit und der Startzeit des Zugriffs auf die Zeitdauer/den Zeitplan vergleichen.
Als weiterer Teil der Validierung/Authentifizierung bei Block 1204 kann sich die Werkzeug-DLL 916 vergewissern, dass kein anderes Werkzeug mit der in dem Anforderung identifizierten Prozesssteuerungsgerät kommuniziert. Beispielsweise können Verbindungsinformationen für alle Werkzeuge, die mit dem Asset-Management-System 900 verbunden sind, gespeichert werden (z. B. in der Datenbank 908, in einem Speicher des Werkzeug-Validierers 918 usw.), einschließlich des Prozesssteuerungsgerätes, mit dem jedes Werkzeug verbunden ist. Unter Verwendung der in der Verbindungsanforderung vorgesehenen Prozesssteuerungsgeräte-ID kann der Werkzeug-DLL-Prozess 1200 bestimmen, ob ein anderes Werkzeug bereits mit dem angeforderten Prozesssteuerungsgerät in Kommunikation steht. Wenn dies der Fall ist, gibt der Werkzeug-DLL-Prozess 1200 den Fehlerzustand bei Block 1206 an den Werkzeugkommunikationsserver 910 zurück.
Wenn das Werkzeug 700 und/oder der Benutzer im Block 1204 validiert werden, speichert der Werkzeug-DLL-Prozess 1200 die Verbindungsinformationen aus der Verbindungsanforderung bei Block 1208. Zusätzlich kann die Werkzeug-DLL eine Zählung von Werkzeugverbindungen mit dem Asset-Management-System 900 inkrementieren. Wiederum können die Verbindungsinformationen in der Datenbank 908, in einem Speicher des Werkzeug-Validierers 918 usw., gespeichert werden. Die Verbindungsinformation kann zumindest eine Angabe enthalten, dass das Prozesssteuerungsgerät mit einem Werkzeug in Kommunikation steht, wodurch verhindert wird, dass sich nachfolgende Werkzeuge mit dem Feldgerät 924 verbinden. In einer anderen Ausführungsform enthalten die Verbindungsinformationen beliebige der oben unter Bezugnahme auf die 14A–14C erörterten Informationen.
Bei Block 1210 gibt der Werkzeug-DLL-Prozess das Ergebnis der Verbindungsanforderung an den Werkzeugkommunikationsserver 910 zurück. Unter Bezugnahme auf 16 empfängt der Werkzeugkommunikationsserver 910 das Verbindungsergebnis von der Werkzeug-DLL 916 bei Block 1106. Wie oben beschrieben, überträgt der Werkzeugkommunikationsserver 910 mithilfe der Prozesssteuerungs-Messaging-Architektur 912 bei Block 1108 das Verbindungsergebnis zu dem Werkzeug 700. Unter Bezugnahme auf 15 empfängt das Werkzeug 700 seinerseits das Verbindungsergebnis von dem Werkzeugkommunikationsserver 910 bei Block 1012 und beginnt mit dem Ausgeben von Rohbefehlen für das Feldgerät 924 an den Werkzeugkommunikationsserver 910 bei Block 1014 unter Verwendung der Prozesssteuerungs-Messaging-Architektur 914.
Unter erneuter Bezugnahme auf 16 empfängt der Werkzeugkommunikationsserver 910 den Rohbefehl von dem Werkzeug 700 bei Block 1110 und leitet den Rohbefehl an die Werkzeug-DLL bei Block 1112 weiter. Wiederum bezugnehmend auf 17 empfängt die Werkzeug-DLL den Rohbefehl von dem Werkzeugkommunikationsserver 910 bei Block 1212. Jeder Rohbefehl entspricht einer bestimmten vom Benutzer auf dem Werkzeug 700 ausgeführten Funktion, die vom Feldgerät 924 zu befolgen ist. In einer Ausführungsform verwendet die Werkzeug-DLL den Werkzeug-Validierer 918, um zu bestätigen, dass das Werkzeug 700 für jeden Rohbefehl empfing. Ähnlich wie bei Block 1204 bestimmt der Werkzeug-DLL-Prozess, ob das Werkzeug 700 beim Asset-Management-System 900 registriert worden ist; er bestimmt, ob der Benutzer auf der Grundlage der vorgenannten Registrierung und/oder Anmeldung beim Asset-Management-System 900 über die korrekte Zugriffs-/Berechtigungsebene auf das ausgewählte Feldgerät 924 (z. B. zumindest Lesezugriff auf das Feldgerät) verfügt, und er kann bestimmen, ob die Anzahl der Werkzeuge 700, die mit dem Asset-Management-System 900 kommunizieren, die zulässige Anzahl der Werkzeuge nicht übersteigt, der die Kommunikation mit dem Asset-Management-System 900 zum gegebenen Zeitpunkt gestattet ist. Wenn eine dieser Bedingungen nicht erfüllt ist, kann der Werkzeug-DLL-Prozess 1200 einen Fehler bei Block 1216 an den Werkzeugkommunikationsserver 910 zurückgeben, der wiederum den Fehler an das Werkzeug 700 zurückgibt.
Wenn ferner ein Benutzer versucht, eine bestimmte Funktion auf dem Werkzeug 700 auszuführen, um eine Operation am verbundenen Prozesssteuerungsgerät auszuführen, bestimmt der Werkzeug-Validierer 918, ob der Benutzer auf die Funktion zugreifen darf. Zusätzlich bestimmt der Werkzeug-Validierer 918, ob die Funktion auf dem Werkzeug 700 lizenziert ist. Wenn beispielsweise ein Benutzer versucht, eine bestimmte Funktion auf dem Werkzeug 700 auszuführen, kann das Werkzeug 700 eine Anzeige der Funktion an den Werkzeugkommunikationsserver 910 senden, die Bestandteil des Rohbefehls selbst sein kann. Der Werkzeug-Validierer 918 kann dann feststellen, ob der Benutzer Zugriff auf die Funktion hat, indem er Berechtigungen, basierend auf der Benutzer-ID für den Benutzer, der ID für das Werkzeug 700 und/oder der Geräte-ID für das angeschlossene Prozesssteuerungsgerät, abruft. Wenn der Benutzer bei der Interaktion mit dem angeschlossenen Prozesssteuerungsgerät nicht auf die Funktion zugreifen darf und/oder die Funktion nicht auf dem Werkzeug 700 lizenziert ist, kann der Werkzeug-DLL-Prozess 1200 auch bei Block 1216 einen Fehler zurückgeben.
Wenn dem Benutzer der Zugriff auf die Funktion gestattet ist und die Funktion auf dem Werkzeug 700 lizenziert ist, startet die Werkzeug-DLL 916 bei Block 1218 den Rohbefehl an das Feldgerät über einen Gerätekommunikationsschnittstellenbefehl mithilfe einer Gerätekommunikationsschnittstelle/Rohbefehlsschnittstelle und gibt dann an die entsprechende Systemschnittstelle (z. B. den Betriebsanlagenserver 922 der Client-Station 920) den Gerätekommunikationsschnittstellenbefehl aus, eine Operation am verbundenen Prozesssteuerungsgerät bei Block 1220 durchzuführen. Insbesondere ist die Gerätekommunikationsschnittstelle eine Methode, die eine Abstraktionsschicht oberhalb der Anwendungsschicht ist, welche einen Transport oder Kanal zum Übergeben von Nachrichten zwischen Anwendungen und Servern bildet. In diesem Beispiel übergibt die Gerätekommunikationsschnittstelle Rohbefehle von der Client-Anwendung auf dem Werkzeug 700 an die Systemschnittstelle 906 als Argument und ruft das Argument mithilfe der Gerätekommunikationsschnittstelle auf. Wenn beispielsweise der Rohbefehl an der Werkzeug-DLL 916 empfangen wird, ruft die Werkzeug-DLL 916 die Gerätekommunikationsschnittstelle auf und stellt den Rohbefehl als Eingabe für die Gerätekommunikationsschnittstelle bereit, woraufhin der Rohbefehl von der Gerätekommunikationsschnittstellenschicht für die Weitergabe an die Systemschnittstelle 906 zur Ausgabe an das Feldgerät verpackt wird.
In einer Ausführungsform kommuniziert die Gerätekommunikationsschnittstelle mit Feldgeräten in Verbindung mit einem (nicht dargestellten) DDS-Block. Der DDS-Block ist mit einer (nicht dargestellten) Gerätebeschreibungsbibliothek gekoppelt, welche Gerätebeschreibungen (DDs) für die Feldgeräte speichert. Die Gerätekommunikationsschnittstelle verwendet den DDS-Block (der auf die in der Bibliothek gespeicherten DDs zugreift), um ordnungsgemäß mit den Feldgeräten zu kommunizieren, um Informationen aus ihnen zu lesen, Informationen auf sie zu schreiben und Methoden auf ihnen auszuführen. Während des Betriebs greift der DDS auf eine mit einem Feldgerät in einer bekannten Weise verbundene DD zu und interpretiert sie, um Informationen über dieses Feldgerät bereitzustellen oder um eine korrekte Kommunikation mit diesem Gerät zu ermöglichen.
Nach dem Ausgeben eines Gerätekommunikationsschnittstellenbefehls an das Feldgerät empfängt die Werkzeug-DLL 916 eine Antwort von dem Feldgerät über die Systemschnittstelle (z. B. Status von dem verbundenen Feldgerät) bei Block 1222 und übersetzt die Antwort in Antwortinformationen für den Werkzeugkommunikationsserver 910 bei Block 1224.
Unter erneuter Bezugnahme auf 15 und 16 empfängt der Werkzeugkommunikationsserver 910 die übersetzte Antwort von der Werkzeug-DLL 916 bei Block 1114 und überträgt die übersetzte Antwort auf das Werkzeug 700 bei Block 1116. Das Werkzeug 700 erhält seinerseits die übersetzte Antwort von dem Werkzeugkommunikationsserver 910 bei Block 1016. Wie bei Block 1018 angezeigt, setzt sich dieser Prozess der Kommunikation zwischen dem Werkzeug 700 und dem verbundenen Feldgerät 924 fort, bis der Benutzer fertig ist oder bis die dem Benutzer erlaubte Zeit endet. Unter erneuter Bezugnahme auf 16 empfängt der Werkzeugkommunikationsserver 910 weiterhin Rohbefehle von dem Werkzeug 700 und leitet die Rohbefehle an die Werkzeug-DLL 916 weiter, und er empfängt weiterhin Antworten von der Werkzeug-DLL 916 und überträgt die Antworten auf das Werkzeug 700, wie bei Block 1118 angegeben. Unter erneuter Bezugnahme auf 17 empfängt der Werkzeug-DLL-Prozess 1200 weiterhin die von dem Werkzeug 700 ausgegebenen Rohbefehle, übersetzt die Rohbefehle, gibt die übersetzten Befehle an das verbundene Prozesssteuerungsgerät aus, empfängt Antworten und übersetzt die Antworten für das Werkzeug 700, wie bei Block 1226 angegeben.
Unter Bezugnahme auf 15 kann, sobald der Benutzer fertig ist (z. B. durch Schließen der Anwendung, die auf dem Werkzeug ausgeführt wird), das Werkzeug 700 ein Trennsignal an den Werkzeugkommunikationsserver 910 bei Block 1020 ausgeben. Unter Bezugnahme auf 16 empfängt der Werkzeugkommunikationsserver 910 das Trennsignal von dem Werkzeug 700 und leitet das Trennsignal an die Werkzeug-DLL 916 weiter. Unter Bezugnahme auf 17 empfängt die Werkzeug-DLL 916 das Trennsignal von dem Werkzeugkommunikationsserver 910; bei Block 1228 entfernt (z. B. löscht, verschiebt usw.) die Werkzeug-DLL 916 die Verbindungsinformation, welche sich auf die Kommunikationssitzung zwischen dem Werkzeug 700 und dem Feldgerät 924 bezieht. Außerdem dekrementiert die Werkzeug-DLL 916 die Zählung der Werkzeugverbindungen mit dem Asset-Management-System. Als solches kann ein anderes Werkzeug mit dem Asset-Management-System 900 kommunizieren und eine Verbindung mit dem Feldgerät 924 herstellen.
In einigen Fällen kann das Werkzeug 700 verwendet werden, um Änderungen an der Konfiguration eines Feldgerätes 760 lokal (d. h., am Feldgerät) über eine direkte Verbindung mit dem Feldgerät unter Verwendung beispielsweise der physischen Kommunikationsschnittstelle 806 vorzunehmen. In anderen Fällen können am Werkzeug 700 Änderungen an der Benutzerkonfiguration vorgenommen werden. Während die Gerätekonfiguration die gegenwärtige Konfiguration des Feldgerätes am Feldgerät (d. h., lokal zum Feldgerät) darstellt, ist eine Benutzerkonfiguration eine Konfiguration des vom Benutzer gesetzten Feldgerätes, welche jedoch vom Feldgerät getrennt gepflegt wird, wobei die Benutzerkonfigurationen zum Klonen des Feldgerätes (d. h., Konfigurieren eines anderen Feldgerätes auf gleiche Weise), für die Pflege einer Vorlage der Konfiguration des Gerätes (z. B. zum Konfigurieren anderer Feldgeräte in ähnlicher, aber nicht identischer Weise), für die Pflege eines Verlaufs der Konfigurationen des Feldgerätes usw. verwendet werden können.
In noch anderen Fällen können Ereignisse, die mit dem Werkzeug 700 und/oder dem Feldgerät 760 verbunden sind, am Werkzeug 700 als Bestandteil eines Prüfpfads von Ereignissen aufgezeichnet werden, allen voran das Starten und Schließen einer Anwendung zum Verbinden mit dem Asset-Management-System 900 durch einen Benutzer des Werkzeugs 700, das Ändern eines Wertes in dem Feldgerät 760 unter Verwendung des Werkzeugs 700, das Ausführen einer Methode auf dem Feldgerät 760 unter Verwendung des Werkzeugs 700, das Erfassen eines vom Feldgerät 760 eingestellten Zustands (z. B. ein HART^®-Befehl 48-Status, bei dem die Antwort eines Feldgerätes auf einen HART^®-Befehl 3 zum Lesen aller dynamischen Variablen und des Stroms aus dem Feldgerät anzeigt, dass unter HART^®-Befehl 48 zusätzliche Statusinformationen vorliegen), das Inbetriebnehmen/Versorgen des T^MFeldgerätes 760 (z. B. Fieldbus Geräte-Tag und Adresse zugeordnet, drahtloses HART-Gerät-Joinkey und Netzwerk-ID zugeordnet) und das Anmelden und Abmelden eines Benutzers beim Werkzeug 700. Bei jedem dieser Fälle ist es wichtig, diese Daten (Feldgerätekonfiguration, Benutzerkonfiguration, Prüfpfad-Ereignisse) an das Asset-Management-System 900 oder eine Asset-Management-Anwendung weiterzugeben. Beispielsweise ist es wichtig, dass die Inbetriebnahme eines Feldgerätes (z. B. Hinzufügen eines Feldgerätes zum Prozessleitsystem) oder eine Änderung bei der Konfiguration eines Feldgerätes über das gesamte Prozessleitsystem mitgeteilt wird. Ähnlich ist es für das Asset-Management-System 900 wichtig zu wissen, ob sich die Konfiguration eines Benutzers geändert hat, und mit dem Werkzeug 700 und/oder dem Feldgerät 760 verbundene Ereignisse zu kennen.
Gleichzeitig kann es Änderungen innerhalb des Asset-Management-Systems 900 geben, beispielsweise Änderungen an den Sicherheitsinformationen eines Benutzers (z. B. Informationen, die für ein Werkzeug 700 erforderlich sind, um zu validieren, ob der Benutzer des Werkzeugs eine Aktion an einer vorgegebenen Stelle ausführen kann, oder Änderungen bei einer Datensynchronisierungsrichtlinie), die beeinflussen können, wie ein Werkzeug 700 funktioniert oder in welchem Umfang ein Benutzer das Werkzeug 700 verwenden kann/sollte. Daher ist es wichtig, dass dem Werkzeug 700 diese Änderungen an den Sicherheitsinformationen bekannt sind.
18 ist ein Flussdiagramm, das einen Prozess zwischen dem Werkzeug 700 und dem Asset-Management-System 900 zur automatischen Synchronisierung von Informationen zwischen dem Werkzeug 700 und dem Asset-Management-System 900 gemäß einer Synchronisierungsrichtlinie darstellt. Allgemein gesprochen ist die Synchronisierungsrichtlinie ein Satz von Regeln, die definieren, welche Informationen automatisch vom Werkzeug 700 und vom Asset-Management-System 900 gemeinsam genutzt werden können. In den folgenden Beispielen wird die Synchronisierungsrichtlinie mit Verweisen auf die oben erwähnten Feldgerätekonfigurationen, Benutzerkonfigurationen Prüfpfad-Ereignisse und Sicherheitseinstellungen beschrieben, ist jedoch nicht auf diese beschränkt. Beispielsweise verbindet sich das Werkzeug 700 in den folgenden Beispielen automatisch mit dem Asset-Management-System 900, wobei während dieser Zeit das Werkzeug automatisch Feldgerätekonfigurationen, Benutzerkonfigurationen und Prüfpfad-Ereignisse mit dem Asset-Management-System 900 synchronisiert und das Asset-Management-System 900 die Sicherheitseinstellungsinformation automatisch mit dem Werkzeug 700 synchronisiert. In einigen Ausführungsformen hat der Benutzer eine gewisse Kontrolle über Informationen, die automatisch weitergegeben werden. Beispielsweise kann ein Benutzer vorziehen, dass keine Daten oder nur bestimmte Arten von Daten automatisch mit dem Asset-Management-System 900 synchronisiert werden, so dass die verbleibenden Daten manuell an das Asset-Management-System 900 übertragen werden.
Unter Bezugnahme auf 18 wird ein automatischer Synchronisierungsvorgang 1300 durch das Asset-Management-System 900 ausgeführt, um ein Werkzeug 700 zum automatischen Synchronisieren von Datenelementen (z. B. Gerätekonfiguration, Benutzerkonfiguration, Prüfpfad-Ereignisse), die auch als „Daten-Set“ bezeichnet werden, mit dem Asset-Management-System-Server 902 zu autorisieren. Beginnend bei Block 1302 aktiviert eine Asset-Management-Anwendung, beispielsweise AMS Device Manager^TM, die Funktionalität für die Kommunikation mit dem Werkzeug 700.
Sobald die Funktionalität zur Kommunikation mit dem Werkzeug 700 in der Asset-Management-Anwendung aktiviert ist, ermöglicht die Asset-Management-Anwendung einen Berechtigungsstatus für das Werkzeug 700, der festlegt, ob das Werkzeug 700 berechtigt ist, Datenelemente bei Block 1304 mit der Asset-Management-Anwendung zu synchronisieren oder nicht. Als berechtigtes Werkzeug 700 gilt jenes, mit dem die Asset-Management-Anwendung eine Kommunikationssitzung zum Synchronisieren von Datenelementen öffnet, wobei die Kommunikationssitzung ein halb-permanenter Dialog zwischen der Asset-Management-Anwendung und dem Werkzeug 700 ist, um Datenelemente (d. h., einen Daten-Set) automatisch zum Werkzeugkommunikationsserver 910 zu übertragen. Andererseits kann ein nicht berechtigtes Werkzeug 700 keine Kommunikationssitzung mit der Asset-Management-Anwendung öffnen; auch ist das Werkzeug 700 nicht in der Lage, ausgenommen mit Ermittlungsdaten, mit der Asset-Management-Anwendung zu kommunizieren. Der Berechtigungsstatus kann global an allen Stationen innerhalb des Asset-Management-Systems (z. B. Asset-Management-Serverstation 902 und Client Station 920) persistiert werden.
In der Regel ist der Standardberechtigungsstatus, dass das Werkzeug 700 nicht berechtigt ist, Datenelemente mit der Asset-Management-Anwendung zu synchronisieren. Natürlich kann dieser Berechtigungsstatus geändert werden. Insbesondere wenn der Asset-Management-Anwendung das Werkzeug 700 durch einen Ermittlungsprozess bekannt wird, kann die Asset-Management-Anwendung die Berechtigung für das Werkzeug 700 von nicht berechtigt zu berechtigt ändern und dabei die Ebene oder die Merkmale der Synchronisierungsberechtigung für das Werkzeug 700 festlegen. Beispielsweise kann das Werkzeug 700 Ermittlungsdaten über das Prozesssteuerungs-Messaging-Netzwerk 200 senden, wobei die Ermittlungsdaten typischerweise grundlegende Informationen sind, die von dem Werkzeug 700 angekündigt werden, und unter Anderem die mit dem Werkzeug 700 und seinen aktuellen Funktionsfähigkeiten verbundene (z. B. für eine Kommunikationssitzung verfügbare) eindeutige Identifizierung einschließen. Wenn bestätigt wird, dass das Werkzeug 700 und/oder der Benutzer über die Fähigkeit zur Synchronisierung von Datenelementen mit der Asset-Management-Anwendung besitzen (z. B. als eine Funktionalität, die durch den Werkzeug-Validierer 918 ähnlich dem Block 1204 von 17 validiert wird), kann die Asset-Management-Anwendung den Berechtigungsstatus für das Werkzeug 700 für eine Kommunikationssitzung einstellen. Selbstverständlich kann der Berechtigungsstatus für das Werkzeug 700 auch durch die Asset-Management-Anwendung von berechtigt auf nicht berechtigt geändert werden, wobei in diesem Fall alle offenen Kommunikationssitzungen umgehend geschlossen werden.
Im Block 1306 ermöglicht der automatische Synchronisierungsvorgang 1300 eine automatische Synchronisierung verschiedener Daten-Sets (z. B. Gerätekonfigurationen, Benutzerkonfigurationen und Prüfpfad-Ereignisse). Allgemein gesprochen wird die Berechtigung von Daten-Sets durch einen Satz von Regeln oder Richtlinien für das Synchronisieren eines Daten-Sets zwischen einem Werkzeug 700 und der Asset-Management-Anwendung während einer Kommunikationssitzung definiert. Der standardmäßige automatische Synchronisierungsrichtlinienstatus für das Werkzeug 700 kann darin bestehen, die automatische Übertragung aller Arten von Daten-Sets zu autorisieren. In der Regel wird die Synchronisierungsrichtlinie global auf allen Stationen innerhalb des Asset-Management-Systems persistiert und gilt für alle Werkzeuge 700a–700c. Es wird darauf hingewiesen, dass die Synchronisierungsrichtlinie in der Asset-Management-Anwendung aktualisiert oder anderweitig geändert werden kann, obwohl solche Aktualisierungen ebenfalls global persistent sind. Zum Beispiel können die automatischen Synchronisierungsregeln geändert werden, um nur automatisch eine der Gerätekonfigurationen, Benutzerkonfigurationen oder Audit Trail-Ereignisse aus den Werkzeugs 700 zu synchronisieren. In einem anderen Beispiel können die automatischen Synchronisierungsregeln geändert werden, um automatisch zusätzliche Typen von Datenelementen wie Sicherheitseinstellungen aus dem Asset-Management-System mit den Werkzeugen 700 zu synchronisieren.
Nachdem er das Werkzeug 700 berechtigt und die automatischen Synchronisierungsregeln angewendet hat, kann der automatische Synchronisierungsvorgang 1300 automatisch Daten mit dem Werkzeug 700 gemäß den Synchronisierungsregeln synchronisieren. Diese automatische Synchronisierung kann jederzeit durchgeführt werden, wenn sich das Werkzeug 700 mit dem Prozesssteuerungs-Messaging-Netzwerk 200 verbindet und eine Kommunikationssitzung mit der Asset-Management-Anwendung öffnet. Insbesondere verbindet sich das Werkzeug 700 mit dem Prozesssteuerungs-Messaging-Netzwerk 200 und überträgt bei der Einrichtung einer Kommunikationssitzung automatisch den/die Daten-Set(s) zum Werkzeugkommunikationsserver 912 durch Verpacken des Daten-Sets in die des Prozesssteuerungs-Messaging-Netzwerkprotokolls und Übertragen des Daten-Sets über das Prozesssteuerungs-Messaging-Netzwerk 200. Als Reaktion darauf benachrichtigt der Werkzeugkommunikationsserver 912 die Asset-Management-Anwendung, dass zu synchronisierende Daten vorhanden sind. Im Gegenzug initiiert die Asset-Management-Anwendung die Übertragung des Daten-Sets von dem Werkzeugkommunikationsserver 912 zu sich selbst, um so den/die Daten-Set(s) aus dem Werkzeug 700 mit ihren eigenen zu synchronisieren.
Es wird auch angemerkt, dass eine derartige automatische Synchronisierung in Echtzeit während der Entwicklung der Daten-Sets durchgeführt werden kann. Wenn beispielsweise das Werkzeug 700 aktuell mit dem Prozesssteuerungs-Messaging-Netzwerk 200 verbunden ist und/oder eine Kommunikationssitzung mit der Asset-Management-Anwendung hat, während das Werkzeug 700 ein Feldgerät konfiguriert, können die Gerätekonfigurationsdaten wie oben beschrieben synchronisiert werden, während die Konfigurationen am Feldgerät vorgenommen werden. Andererseits können anstelle der automatischen Synchronisierung eines Daten-Sets mit der Asset-Management-Anwendung der/die Daten-Set(s) von einem Benutzer des Werkzeugs 700 manuell übertragen werden. Beispielsweise kann der Benutzer vorziehen, Gerätekonfigurationen und Prüfpfad-Ereignissen die automatische Synchronisierung mit der Asset-Management-Anwendung zu gestatten, jedoch die Benutzer-Konfigurationsdaten in die Asset-Management-Anwendung, welche eine an dem Werkzeug 700 bereitgestellte und/oder an der Asset-Management-Anwendung persistierte Einstellung sein kann, nur manuell zu übertragen.
In einigen Fällen muss ein von der Asset-Management-Anwendung empfangener Daten-Set wegen eines Konflikts mit vorhandenen Daten abgestimmt werden. Beispielsweise kann jeder Daten-Set mit einer eindeutigen Kennung (z. B. einem Benutzerkonfigurationsdatenelement mit einer eindeutigen Kennung „File_01“) assoziiert sein. In der Asset-Management-Anwendung ist jedoch möglicherweise ein Datenelement namens „File_01“ bereits vorhanden. In einem solchen Fall kann der vorhandene Daten-Set über das Asset-Management-System mit den neuen Daten überschrieben oder eine neue eindeutige Identifizierung für das neue Datenelement bereitgestellt werden. Wenn zum Beispiel die Übertragung manuell ist (d. h., der Daten-Set vom Benutzer des Werkzeugs 700 forciert wird), können dem Benutzer Optionen zur Behebung des Konflikts präsentiert werden (z. B. die Wahl, die Datei umzubenennen oder die vorhandene Datei in der Asset-Management-Anwendung mit der neueren Version aus dem Werkzeug 700 zu überschreiben). Wenn die Übertragung automatisch erfolgt, kann das System automatisch einen neuen Namen für das Datenelement angeben, beispielsweise durch Anfügen einer eindeutigen Zahl an die Datei (z. B. „File_01_01“), um sicherzustellen, dass der Name bei Block 1212 eindeutig ist. Bei einer automatischen Übertragung kann dies die Standardauswahl darstellen, da es keine Benutzerüberwachung gibt, um festzustellen, ob die Daten überschrieben werden sollen.
Nach dem Abstimmen des Daten-Sets bei Block 1310 veröffentlicht der automatische Synchronisierungsvorgang 1300 eine Benutzerschnittstellenaktualisierungsmeldung bei Block 1314 an alle Stationen (z. B. Client-Station 920), dass der Daten-Set verändert wurde. Somit hat jede Station innerhalb des Asset-Management-Systems 900 dieselbe Information wie die Asset-Management-Anwendung. Als solches verfügt das gesamte Asset-Management-System 900 über die aktualisierten Informationen (z. B. Gerätekonfiguration, Benutzerkonfiguration usw.), wie sie für das gesamte Asset-Management-System 900 erforderlich sind, um Operationen auf dem Prozessleitsystem effizient auszuführen. Anders ausgedrückt, verfügt das Asset-Management-System 900 über aktuelle Informationen über das Prozessleitsystem, das es verwaltet, einschließlich jener Instanzen, in denen Änderungen im Feld vorgenommen werden, wodurch dem Asset-Management-System 900 eine genaue Ansicht des Prozessleitsystems vermittelt wird. Eine genauere Darstellung des Prozessleitsystems einschließlich der Änderungen an dem/den Daten-Set(s) ermöglicht es dem Asset-Management-System 900, bessere Entscheidungen zu treffen, wenn es Operationen auf dem Prozessleitsystem ausführt. Zusätzlich aktualisiert der automatische Synchronisierungsvorgang 1300 die Benutzerschnittstellen an verschiedenen Stationen bei Block 1316, so dass Bediener (Benutzer) an den Stationen eine genauere Ansicht des Prozessleitsystems haben, zumal solche Ansichten auf der Benutzerschnittstelle angezeigt werden, die möglicherweise von der Änderung des Daten-Sets betroffen sind.
Für die vorstehende Erörterung gelten folgende zusätzliche Überlegungen. In dieser gesamten Spezifikation beziehen sich Aktionen, die als von einem Gerät oder einer Routine ausgeführt beschrieben werden, im Allgemeinen auf Aktionen oder Prozesse eines Prozessors, der die Daten maschinenlesbaren Anweisungen entsprechend verarbeitet oder umformt. Die maschinenlesbaren Befehle können auf einer kommunikativ mit dem Prozessor gekoppelten Speichervorrichtung gespeichert und aus ihr abgerufen werden. Das heißt, dass die in dieser Schrift beschriebenen Verfahren durch einen Satz von maschinenausführbaren Befehlen ausgeführt werden können, die auf einem computerlesbaren Medium (d. h., auf einer Speichervorrichtung) gespeichert sind. Die Anweisungen, wenn sie von einem oder mehreren Prozessoren einer entsprechenden Vorrichtung (z. B. einem Server, einer Benutzerschnittstellenvorrichtung usw.) ausgeführt werden, bewirken, dass die Prozessoren die Methode ausführen. Wo Instruktionen, Routinen, Module, Prozesse, Dienste, Programme und/oder Anwendungen in dieser Schrift als „gespeichert“ oder „in einem computerlesbaren Speicher gespeichert“ oder „auf einem computerlesbaren Medium gespeichert“ bezeichnet werden, gelten transitorische Signale als vom Begriff „gespeichert“ ausgenommen.
Während die Begriffe „Bediener“, „Personal“, „Person“, „Benutzer“, „ Techniker“ und ähnliche andere Begriffe verwendet werden, um Personen in der Prozessanlagenumgebung zu beschreiben, die die in dieser Schrift beschriebenen Systeme, Vorrichtungen und Verfahren verwenden oder mit ihnen interagieren können, sollen diese Begriffe nicht einschränkend wirken. Wenn ein bestimmter Begriff in der Beschreibung verwendet wird, wird der Begriff zum Teil wegen der herkömmlichen Tätigkeiten verwendet, die das Betriebsanlagenpersonal ausübt, es ist jedoch nicht beabsichtigt, das Personal zu begrenzen, das diese bestimmte Tätigkeit ausüben könnte.
Zusätzlich können in dieser Beschreibung mehrere Instanzen Komponenten, Operationen oder Strukturen implementieren, die als einzelne Instanz beschrieben sind. Obwohl einzelne Operationen eines oder mehrerer Verfahren als separate Operationen dargestellt und beschrieben sind, können eine oder mehrere der einzelnen Operationen gleichzeitig durchgeführt werden, wobei nicht erforderlich ist, dass die Operationen in der dargestellten Reihenfolge durchgeführt werden. Als separate Komponenten in Beispielkonfigurationen dargestellte Strukturen und Funktionalitäten können als kombinierte Struktur oder Komponente implementiert werden. Ebenso können als Einzelkomponente dargestellte Strukturen und Funktionalitäten als separate Komponenten implementiert werden. Diese und andere Abwandlungen, Änderungen, Ergänzungen und Verbesserungen fallen in den Schutzbereich des Gegenstandes dieser Schrift.
Sofern nicht ausdrücklich anders vermerkt, bezeichnen in dieser Erörterung verwendete Wörter wie „verarbeiten“, „berechnen“, „bestimmen“, „identifizieren“, „darstellen“, „darzustellen veranlassen“, „anzuzeigen veranlassen“, „anzeigen“ oder dergleichen Aktionen oder Prozesse einer Maschine (z. B. eines Computers), welche Daten bearbeiten oder umwandeln, die als physische (z. B. elektronische, magnetische, biologische oder optische) Größen in einem oder mehreren Speichern (z. B. flüchtiger Speicher, nicht-flüchtiger Speicher oder eine Kombination davon), in Registern oder anderen Maschinenkomponenten, die Informationen empfangen, speichern, senden oder anzeigen, dargestellt sind.
Wenn sie in Software implementiert sind, können beliebige der in dieser Schrift beschriebenen Anwendungen, Dienste und Antriebe in jedem materiellen, nicht-flüchtigen computerlesbaren Speicher, beispielsweise auf einer Magnetplatte, einer Laserplatte, einer Festkörper-Speichervorrichtung, einer molekularen Speichervorrichtung oder einem anderen Speichermedium, in einem RAM oder ROM eines Computers oder Prozessors usw. gespeichert werden. Obwohl offenbart ist, dass die hierin offenbarten Beispielsysteme unter Anderem auch auf Hardware ausgeführte Software und/oder Firmware enthalten, ist zu beachten, dass solche Systeme lediglich der Veranschaulichung dienen und nicht als einschränkend betrachtet werden sollten. Beispielsweise wird in Betracht gezogen, dass beliebige oder alle dieser Hardware-, Software- und Firmware-Komponenten ausschließlich in Hardware, ausschließlich in Software oder in beliebiger Kombination von Hardware und Software ausgeführt sein könnten. Dementsprechend ist für den Durchschnittsfachmann auf dem Gebiet leicht zu erkennen, dass die bereitgestellten Beispiele nicht die einzige Möglichkeit zur Umsetzung solcher Systeme sind.
Während die vorliegende Erfindung unter Bezugnahme auf spezifische Beispiele beschrieben ist, die lediglich der Veranschaulichung dienen und nicht einschränkend für die Erfindung sein sollen, ist es daher für den Durchschnittsfachmann offensichtlich, dass Änderungen, Ergänzungen oder Streichungen an den offenbarten Ausführungsformen vorgenommen werden können, ohne vom Geist und Schutzbereich der Erfindung abzuweichen.
Ebenso versteht sich, dass in jenen Fällen, in denen ein Begriff in diesem Patent mithilfe des Satzes „Wie in dieser Schrift verwendet, wird der Begriff ‘______’ hiermit so definiert, dass er ... bedeutet“ oder einem ähnlichen Satz ausdrücklich definiert ist, es nicht beabsichtigt ist, die Bedeutung des betreffenden Begriffs ausdrücklich oder stillschweigend über seine eindeutige und gewöhnliche Bedeutung hinaus zu begrenzen; auch darf ein solcher Begriff nicht so ausgelegt werden, dass er aufgrund einer in einem beliebigen Abschnitt dieses Patents (ausgenommen im Wortlaut der Patentansprüche) enthaltenen Aussage in seinem Umfang eingeschränkt wird. Soweit ein in den Patentansprüchen am Ende dieses Patents aufgeführter Begriff in diesem Patent durchgängig in einer mit einer einzelnen Bedeutung vereinbaren Art und Weise aufgeführt wird, geschieht dies lediglich aus Gründen der Klarheit, um den Leser nicht zu verwirren, und es ist nicht beabsichtigt, diesen Anspruchsbegriff stillschweigend oder anderweitig auf diese einzige Bedeutung zu beschränken. Schließlich ist nicht beabsichtigt, dass der Umfang eines beliebigen Anspruchselements auf der Grundlage der Anwendung von 35 U.S.C. § 112 (f) und/oder Pre-AIA 35 U.S.C. § 112, sechster Absatz, interpretiert wird, wenn ein Anspruchselement nicht durch das Vortragen des Wortes „Mittel“ und einer Funktion ohne die Erwähnung einer Struktur definiert wird.
Obwohl im vorstehenden Text eine detaillierte Beschreibung zahlreicher verschiedener Ausführungsformen enthalten ist, versteht sich, dass der Geltungsbereich des Patents durch die am Ende dieses Patents aufgeführten Wörter der Ansprüche definiert ist. Die detaillierte Beschreibung ist nur als beispielhaft auszulegen und beschreibt nicht jede mögliche Ausführungsform, da die Beschreibung jeder möglichen Ausführungsform unpraktisch, wenn nicht gar unmöglich wäre. Zahlreiche alternative Ausführungsformen könnten unter Verwendung entweder gegenwärtiger Technologie oder nach dem Anmeldetag dieses Patents entwickelter Technologie umgesetzt werden, was immer noch in den Geltungsbereich der Ansprüche fallen würde.
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

IEEE 802.11 [0062]
IEEE 802.3 [0066]
Ethernet-Standard IEEE 802.3 [0067]
Ethernet-Protokoll IEEE 802.3 [0068]
802.11-Protokoll [0132]

Claims

Verfahren zur Datensynchronisierung zwischen einem tragbaren Feldwartungswerkzeug und einer Prozesssteuerungs-Asset-Management-Systemanwendung innerhalb eines Prozessleitsystems, wobei das Verfahren Folgendes umfasst: automatisches Übertragen, durch das tragbare Feldwartungswerkzeug, eines Daten-Sets an einen Kommunikationsserver für tragbare Feldwartungswerkzeuge innerhalb des Prozesssteuerungs-Asset-Management-Systems über einen drahtlosen Kommunikationskanal des Prozesssteuerungs-Asset-Management-Systems als Reaktion auf eine Veränderung in einem Daten-Set, wobei das Prozesssteuerungs-Asset-Management-System über einen digitalen Prozesskommunikationskanal kommunikativ mit einem Feldgerät gekoppelt ist, wobei der Daten-Set durch einen Satz von Regeln für die automatische Synchronisierung des Daten-Sets zwischen dem tragbaren Feldwartungsgerät und der Prozesssteuerungs-Asset-Management-Systemanwendung während einer Kommunikationssitzung zwischen dem tragbaren Feldwartungsgerät und der Prozesssteuerungs-Asset-Management-Systemanwendung definiert wird, wobei das tragbare Feldwartungsgerät und der Kommunikationsserver für tragbare Feldwartungswerkzeuge jeder für sich über einen Rahmen eines über einem Kommunikationsprotokoll des Prozesssteuerungs-Asset-Management-Systems geschichteten Kommunikationsprotokolls verfügt und das Protokoll des Prozesssteuerungs-Asset-Management-Systems über ein Netzwerk-Kommunikationsprotokoll geschichtet ist, und wobei der Daten-Set im Kommunikationsprotokoll des Prozesssteuerungs-Asset-Management-Systems verpackt ist; Anzeigen an die Prozesssteuerungs-Asset-Management-Systemanwendung, durch den Kommunikationsserver für tragbare Feldwartungswerkzeuge, als Reaktion auf eine automatische Übertragung des Daten-Sets, dass der Daten-Set aus dem Kommunikationsserver für tragbare Feldwartungswerkzeuge zur Synchronisierung mit der Prozesssteuerungs-Asset-Management-Systemanwendung bereit ist; Einleiten, durch die Prozesssteuerungs-Asset-Management-Systemanwendung als Reaktion auf die Anzeige, einer Übertragung des Daten-Sets vom Kommunikationsserver für tragbare Feldwartungswerkzeuge zur Prozesssteuerungs-Asset-Management-Systemanwendung zum Synchronisieren eines Daten-Sets in der Prozesssteuerungs-Asset-Management-Anwendung mit dem Daten-Set aus dem tragbaren Feldwartungswerkzeug; Veröffentlichen, durch die Prozesssteuerungs-Asset-Management-Systemanwendung als Reaktion auf einen Abschluss der Übertragung des Daten-Sets, einer Benutzerschnittstellen-Aktualisierungsmeldung an eine Vielzahl von Prozesssteuerungs-Asset-Management-Systemstationen, dass der Daten-Set verändert wurde; Aktualisieren, durch die Benutzerschnittstelle an einer oder mehreren der Vielzahl von Prozesssteuerungs-Asset-Management-Stationen, einer von der Veränderung des Daten-Sets betroffenen Anzeigeansicht, und Ausführen, durch das Prozesssteuerungs-Asset-Management-System, einer Operation des Prozessleitsystems, bei der eine Veränderung des Daten-Sets erfolgt.
Verfahren von Anspruch 1, ferner umfassend: automatische kommunikative Koppelung des tragbaren Feldwartungswerkzeugs mit dem Kommunikationsserver für tragbare Feldwartungswerkzeuge über den drahtlosen Kommunikationskanal als Reaktion auf eine Veränderung im Daten-Set auf dem tragbaren Feldwartungswerkzeug, wobei das automatische Übertragen des Daten-Sets das automatische Übertragen, durch das tragbare Feldwartungswerkzeug, des Daten-Sets an den Kommunikationsserver für tragbare Feldwartungswerkzeuge innerhalb des Prozesssteuerungs-Asset-Management-Systems über den drahtlosen Kommunikationskanal des Prozessleitsystems nach der kommunikativen Koppelung des tragbaren Feldwartungswerkzeugs mit dem Kommunikationsserver für tragbare Feldwartungswerkzeuge umfasst.
Verfahren nach einem der Ansprüche 1 oder 2, insbesondere nach Anspruch 1, ferner umfassend: Senden, durch das tragbare Feldwartungswerkzeug, von Ermittlungsdaten über den drahtlosen Kommunikationskanal, wobei die Ermittlungsdaten eine eindeutige Identifizierung des tragbaren Feldwartungswerkzeugs umfassen; Einstellen, durch die Prozesssteuerungs-Asset-Management-Anwendung als Reaktion auf das Empfangen der Ermittlungsdaten, eines Berechtigungsstatus für das tragbare Feldwartungswerkzeug von: (1) nicht berechtigt für das automatische Übertragen des Daten-Sets an den Verbindungsserver für tragbare Feldwartungswerkzeuge auf (2) berechtigt für das automatische Übertragen des Daten-Sets an den Verbindungsserver für tragbare Feldwartungswerkzeuge, und Persistieren, durch die Prozesssteuerungs-Asset-Management-Anwendung, des Berechtigungsstatus des tragbaren Feldwartungswerkzeugs auf die Vielzahl von Prozesssteuerungs-Asset-Management-Stationen.
Verfahren nach einem der Ansprüche 1 bis 3, insbesondere nach Anspruch 1, wobei der Daten-Set eines oder mehrere der Folgenden umfasst: eine Benutzerkonfiguration, welche eine separat vom Feldgerät gepflegte Konfiguration des Feldgerätes darstellt, ein Prüfpfad-Ereignis, welches eine Aufzeichnung eines Ereignisses darstellt, an dem das Feldgerät und oder das tragbare Feldwartungswerkzeug beteiligt sind, eine Sicherheitseinstellung, welche eine Sicherheitseinstellung darstellt, die das tragbare Feldwartungswerkzeug und/oder den Benutzer eines tragbaren Feldwartungswerkzeugs betrifft, sowie eine Feldgerätekonfiguration, welche eines Konfiguration eines zu dem Feldgerät lokalen Feldgerätes darstellt und, insbesondere wobei das automatische Übertragen eines Daten-Sets das automatische Übertragen, durch das tragbare Feldwartungswerkzeug, einer Benutzerkonfiguration an den Kommunikationsserver für tragbare Feldwartungswerkzeuge als Reaktion auf eine Veränderung bei der Benutzerkonfiguration des Feldgerätes umfasst, und/oder, wobei das automatische Übertragen eines Daten-Sets das automatische Übertragen, durch das tragbare Feldwartungswerkzeug, eines Prüfpfad-Ereignisses an den Kommunikationsserver für tragbare Feldwartungswerkzeuge als Reaktion auf einen Eintritt eines Ereignisses umfasst, an dem das Feldgerät und/oder, das tragbare Feldwartungswerkzeug beteiligt sind, und, insbesondere, wobei das Ereignis einen oder mehrere der folgenden umfasst: Starten oder Schließen einer Client-Anwendung auf dem tragbaren Feldwartungswerkzeug, wobei die Client-Anwendung eine Schnittstelle zum Prozesssteuerungs-Asset-Management-System besitzt, einen in dem Feldgerät geänderten Wert, eine auf dem Feldgerät ausgeführte Methode, Erfassung eines von dem Feldgerät eingestellten Status, eine Inbetriebnahme des Feldgerätes und das Anmelden oder Abmelden eines Benutzers an dem tragbaren Feldwartungswerkzeug, und/oder, wobei das automatische Übertragen eines Daten-Sets das automatische Übertragen, durch das tragbare Feldwartungswerkzeug, einer Sicherheitseinstellung an den Kommunikationsserver für tragbare Feldwartungswerkzeuge als Reaktion auf eine Veränderung bei einer Sicherheitseinstellung umfasst, die das Feldwartungswerkzeug und/oder, einen Benutzer des tragbaren Feldwartungswerkzeugs betreffen, und/oder, wobei das automatische Übertragen eines Daten-Sets das automatische Übertragen, durch das tragbare Feldwartungswerkzeug, einer Feldgerätekonfiguration an den Kommunikationsserver für tragbare Feldwartungswerkzeuge als Reaktion auf eine Veränderung an der lokalen Konfiguration des Feldgerätes umfasst, und/oder, ferner umfassend das Aktivieren oder Deaktivieren der Synchronisierung einer oder mehrerer von Benutzerkonfiguration, Prüfpfad-Ereignis, Sicherheitseinstellung und Feldgerätekonfiguration.
Verfahren nach einem der Ansprüche 1 bis 4, insbesondere nach Anspruch 1, wobei das automatische Übertragen des Daten-Sets an den Kommunikationsserver für tragbare Feldwartungswerkzeuge das automatische Übertragen des Daten-Sets an den Kommunikationsserver für tragbare Feldwartungswerkzeuge umfasst, sobald Veränderungen an dem Daten-Set vorgenommen werden, falls sich das tragbare Feldwartungswerkzeug bereits in Kommunikation mit dem Kommunikationsserver für tragbare Feldwartungswerkzeuge befindet.
Verfahren nach einem der Ansprüche 1 bis 5, insbesondere nach Anspruch 1, wobei das automatische Übertragen des Daten-Sets an den Kommunikationsserver für tragbare Feldwartungswerkzeuge das automatische Übertragen des Daten-Sets an den Kommunikationsserver für tragbare Feldwartungswerkzeuge nach Herstellung von Kommunikation zwischen dem tragbaren Feldwartungswerkzeug und dem Kommunikationsserver für tragbare Feldwartungswerkzeuge umfasst, falls Veränderungen an dem Daten-Set vorgenommen werden, wenn sich das tragbare Feldwartungswerkzeug nicht in Kommunikation mit dem Kommunikationsserver für tragbare Feldwartungswerkzeuge befindet.
System zur Synchronisierung eines Daten-Sets zwischen einem tragbaren Feldwartungswerkzeug und einer Prozesssteuerungs-Asset-Management-Systemanwendung innerhalb eines Prozessleitsystems, wobei das System Folgendes umfasst: einen Kommunikationsserver für tragbare Feldwartungswerkzeuge, und eine kommunikativ mit dem Kommunikationsserver für tragbare Feldwartungswerkzeuge gekoppelte Prozesssteuerungs-Asset-Management-Systemanwendung, wobei der Kommunikationsserver für tragbare Feldwartungswerkzeuge: ausgebildet ist, um sich mit dem tragbaren Feldwartungswerkzeug über einen drahtlosen Kommunikationskanal kommunikativ zu koppeln, und ausgebildet ist, um einen Daten-Set aus dem tragbaren Feldwartungswerkzeug über den drahtlosen Kommunikationskanal zu empfangen, wobei der Daten-Set durch einen Satz von Regeln für die automatische Synchronisierung des Daten-Sets zwischen dem tragbaren Feldwartungswerkzeug und der Prozesssteuerungs-Asset-Management-Systemanwendung während einer Kommunikationssitzung zwischen dem tragbaren Feldwartungswerkzeug und der Prozesssteuerungs-Asset-Management-Systemanwendung definiert ist, das tragbare Feldwartungswerkzeug und der Kommunikationsserver für tragbare Feldwartungswerkzeuge jeder für sich über einen Rahmen eines über ein Kommunikationsprotokoll des Prozesssteuerungs-Asset-Management-Systems geschichtetes Kommunikationsprotokolls des Feldgeräts verfügen und das Protokoll des Prozesssteuerungs-Asset-Management-Systems über ein Netzwerk-Kommunikationsprotokoll geschichtet ist, und wobei der Daten-Set im Kommunikationsprotokoll des Prozesssteuerungs-Asset-Management-System verpackt ist, und ausgebildet ist, um der Prozesssteuerungs-Asset-Management-Systemanwendung automatisch anzuzeigen, dass der Daten-Set aus dem Kommunikationsserver für tragbare Feldwartungswerkzeuge zur Synchronisierung mit der Prozesssteuerungs-Asset-Management-Systemanwendung nach Empfang des Daten-Sets aus dem tragbaren Feldwartungswerkzeug bereit ist, wobei die Prozesssteuerungs-Asset-Management-Systemanwendung: ausgebildet ist, um automatisch eine Übertragung des Daten-Sets aus dem Kommunikationsserver für tragbare Feldwartungswerkzeuge zu der Prozesssteuerungs-Asset-Management-Systemanwendung einzuleiten, um einen Daten-Set in der Prozesssteuerungs-Asset-Management-Anwendung mit dem Daten-Set aus dem tragbaren Feldwartungswerkzeug nach Eingang der Anzeige zu synchronisieren, ausgebildet ist, um eine Benutzerschnittstellen-Aktualisierungsmeldung an eine Vielzahl von Prozesssteuerungs-Asset-Management-Stationen zu veröffentlichen, dass der Daten-Set verändert wurde, und ausgebildet ist, um eine Operation des Prozessleitsystems auszuführen, bei der eine Veränderung des Daten-Sets erfolgt.
System nach Anspruch 7, wobei der Kommunikationsserver für tragbare Feldwartungswerkzeuge ausgebildet ist, um Ermittlungsdaten zu empfangen, die vom tragbaren Feldwartungswerkzeug über den drahtlosen Kommunikationskanal ausgesendet wurden, und die Ermittlungsdaten an die Prozesssteuerungs-Asset-Management-Anwendung weiterzugeben, wobei die Ermittlungsdaten eine eindeutige Identifizierung des tragbaren Feldwartungswerkzeugs umfassen, und wobei die Prozesssteuerungs-Asset-Management-Anwendung ausgeführt ist, um: einen Berechtigungsstatus für das tragbare Feldwartungswerkzeug als Reaktion auf das Empfangen von Ermittlungsdaten einzustellen von: (1) nicht berechtigt für das automatische Übertragen des Daten-Sets an den Verbindungsserver für tragbare Feldwartungswerkzeuge auf (2) berechtigt für das automatische Übertragen der Feldgerät-Konfigurationsdatei an den Verbindungsserver für tragbare Feldwartungswerkzeuge, und den Berechtigungsstatus des tragbaren Feldwartungswerkzeugs auf die Vielzahl von Prozesssteuerungs-Asset-Management-Stationen zu persistieren.
System nach einem der Ansprüche 7 oder 8, insbesondere nach Anspruch 7, wobei der Daten-Set eines oder mehrere der Folgenden umfasst: eine Benutzerkonfiguration, welche eine separat vom Feldgerät gepflegte Konfiguration des Feldgerätes darstellt, ein Prüfpfad-Ereignis, welches eine Aufzeichnung eines Ereignisses darstellt, an dem das Feldgerät und oder das tragbare Feldwartungswerkzeug beteiligt sind, eine Sicherheitseinstellung, welche eine Sicherheitseinstellung darstellt, die das tragbare Feldwartungswerkzeug und/oder den Benutzer eines tragbaren Feldwartungswerkzeugs betreffen, sowie eine Feldgerätekonfiguration, welche eine Konfiguration eines zu dem Feldgerät lokalen Feldgerätes darstellt, und/oder, wobei das Ereignis eines oder mehrere der folgenden umfasst: Starten oder Schließen einer Client-Anwendung auf dem tragbaren Feldwartungswerkzeug, wobei die Client-Anwendung eine Schnittstelle zum Prozesssteuerungs-Asset-Management-System besitzt, einen in dem Feldgerät geänderten Wert, eine auf dem Feldgerät ausgeführte Methode, Erfassung eines von dem Feldgerät eingestellten Status, eine Inbetriebnahme des Feldgerätes und das Anmelden oder Abmelden eines Benutzers an dem tragbaren Feldwartungswerkzeug, und/oder, wobei die Prozesssteuerungs-Asset-Management-Anwendung für das Aktivieren oder Deaktivieren der Synchronisierung eines oder mehrerer von Benutzerkonfiguration, Prüfpfad-Ereignis, Sicherheitseinstellung und Feldgerätekonfiguration ausgeführt ist.
System nach einem der Ansprüche 7 bis 9, insbesondere nach Anspruch 7, wobei der Kommunikationsserver für tragbare Feldwartungswerkzeuge für den Empfang des Daten-Sets ausgeführt ist, sobald Veränderungen an dem Daten-Set am tragbaren Feldwartungswerkzeug vorgenommen werden, falls sich das tragbare Feldwartungswerkzeug bereits in Kommunikation mit dem Kommunikationsserver für tragbare Feldwartungswerkzeuge befindet.
System nach einem der Ansprüche 7 bis 10, insbesondere nach Anspruch 7, wobei der Kommunikationsserver für tragbare Feldwartungswerkzeuge ausgeführt ist, um den Daten-Set an den Kommunikationsserver für tragbare Feldwartungswerkzeuge nach Herstellung von Kommunikation zwischen dem tragbaren Feldwartungswerkzeug und dem Kommunikationsserver für tragbare Feldwartungswerkzeuge zu empfangen, falls Veränderungen an dem Daten-Set vorgenommen werden, wenn sich das tragbare Feldwartungswerkzeug nicht in Kommunikation mit dem Kommunikationsserver für tragbare Feldwartungswerkzeuge befindet.
Ein tragbares Feldwartungswerkzeug, umfassend: ein Gehäuse; einen im Gehäuse angeordneten Prozessor; einen im Gehäuse angeordneten und in Wirkbeziehung mit dem Prozessor gekoppelten Speicher; eine im Gehäuse angeordnete und in Wirkbeziehung mit dem Prozessor und dem Speicher angeordnete drahtlose Kommunikationsschnittstelle, wobei die Kommunikationsschnittstelle ausgeführt ist, um sich kommunikativ mit einen drahtlosen Kommunikationskanal eines Prozesssteuerungs-Asset-Management-Systems zu koppeln; eine im Gehäuse angeordnete und mit der drahtlosen Kommunikationsschnittstelle kommunikativ gekoppelte Kommunikationsschaltung, wobei die Kommunikationsschaltung ausgeführt ist, um das Kommunikationssignal für den drahtlosen Kommunikationskanal unter Verwendung eines Rahmens eines Kommunikationsprotokolls eines Feldgerätes zu codieren, das über ein Kommunikationsprotokoll des Prozesssteuerungs-Asset-Management-Systems geschichtet ist, und wobei das Prozesssteuerungs-Asset-Management-System über ein Netzwerk-Kommunikationsprotokoll geschichtet ist; und eine Client-Anwendung, die im Speicher gespeichert ist und ausgeführt ist, um bei der Ausführung durch einen Prozessor automatisch einen Daten-Set an einen Kommunikationsserver für tragbare Feldwartungswerkzeuge innerhalb des Prozesssteuerungs-Asset-Management-Systems über einen drahtlosen Kommunikationskanal des Prozesssteuerungs-Asset-Management-System als Reaktion auf eine Veränderung am Daten-Set zu übertragen, wobei der Daten-Set durch einen Satz von Regeln für die automatische Synchronisierung des Daten-Sets zwischen dem tragbaren Feldwartungsgerät und der Prozesssteuerungs-Asset-Management-Systemanwendung während einer Kommunikationssitzung zwischen dem tragbaren Feldwartungsgerät und der Prozesssteuerungs-Asset-Management-Systemanwendung definiert ist, und wobei der Daten-Set im Kommunikationsprotokoll des Prozesssteuerungs-Asset-Management-Systems verpackt ist.
Tragbares Feldwartungswerkzeug von Anspruch 12, wobei die Kommunikationsschaltung für den intrinsisch sicheren Betrieb ausgeführt ist.
Tragbares Feldwartungswerkzeug nach einem der Ansprüche 12 oder 13, insbesondere nach Anspruch 12, wobei die Client-Anwendung bei Ausführung durch den Prozessor ferner ausgeführt ist, um: das tragbare Feldwartungswerkzeug mit dem Kommunikationsserver für tragbare Feldwartungswerkzeuge über den drahtlosen Kommunikationskanal als Reaktion auf eine Veränderung im Daten-Set auf dem tragbaren Feldwartungswerkzeug automatisch kommunikativ zu koppeln, wobei die Client-Anwendung bei Ausführung durch den Prozessor für das automatische Übertragen des Daten-Sets zu dem Kommunikationsserver für tragbare Feldwartungswerkzeuge über den drahtlosen Kommunikationskanal des Prozessleitsystems nach der kommunikativen Koppelung des tragbaren Feldwartungswerkzeugs mit dem Kommunikationsserver für tragbare Feldwartungswerkzeuge ausgebildet ist, und/oder, wobei die Client-Anwendung ferner ausgebildet ist, um bei Ausführung durch den Prozessor Ermittlungsdaten über den drahtlosen Kommunikationskanal auszusenden, wobei die Ermittlungsdaten eine eindeutige Identifizierung des tragbaren Feldwartungswerkzeugs umfassen.
Tragbares Feldwartungswerkzeug nach einem der Ansprüche 12 bis 14, insbesondere nach Anspruch 14, wobei der Daten-Set eines oder mehrere der Folgenden umfasst: eine Benutzerkonfiguration, welche eine separat vom Feldgerät gepflegte Konfiguration des Feldgerätes darstellt, ein Prüfpfad-Ereignis, welches eine Aufzeichnung eines Ereignisses darstellt, an dem das Feldgerät und oder das tragbare Feldwartungswerkzeug beteiligt sind, eine Sicherheitseinstellung, welche eine Sicherheitseinstellung darstellt, die das tragbare Feldwartungswerkzeug und/oder den Benutzer eines tragbaren Feldwartungswerkzeugs betrifft, sowie eine Feldgerätekonfiguration, welche eines Konfiguration eines zu dem Feldgerät lokalen Feldgerätes darstellt, und, insbesondere, wobei die Client-Anwendung ausgebildet ist, um bei Ausführung durch den Prozessor eine Benutzerkonfiguration automatisch an den Kommunikationsserver für tragbare Feldwartungswerkzeuge als Reaktion auf eine Veränderung an der Benutzerkonfiguration des Feldgerätes zu übertragen, und/oder, wobei die Client-Anwendung ausgebildet ist, um bei Ausführung durch den Prozessor automatisch ein Prüfpfad-Ereignis an den Kommunikationsserver für tragbare Feldwartungswerkzeuge als Reaktion auf einen Eintritt eines Ereignisses zu übertragen, an dem das Feldgerät und/oder das tragbare Feldwartungswerkzeug beteiligt sind, und/oder, wobei das Ereignis eines oder mehrere der folgenden umfasst: Starten oder Schließen einer Client-Anwendung auf dem tragbaren Feldwartungswerkzeug, wobei die Client-Anwendung eine Schnittstelle zum Prozesssteuerungs-Asset-Management-System besitzt, einen in dem Feldgerät geänderten Wert, eine auf dem Feldgerät ausgeführte Methode, Erfassung eines von dem Feldgerät eingestellten Status, eine Inbetriebnahme des Feldgerätes und das Anmelden oder Abmelden eines Benutzers an dem tragbaren Feldwartungswerkzeug, und/oder wobei die Client-Anwendung ausgebildet ist, um bei Ausführung durch den Prozessor eine Sicherheitseinstellung automatisch an den Kommunikationsserver für tragbare Feldwartungswerkzeuge als Reaktion auf eine Veränderung bei der Sicherheitseinstellung zu übertragen, die das tragbare Feldwartungswerkzeug und/oder einen Benutzer des tragbaren Feldwartungswerkzeugs betrifft, und/oder, wobei die Client-Anwendung ausgebildet ist, um bei Ausführung durch den Prozessor eine Feldgerätekonfiguration automatisch an den Kommunikationsserver für tragbare Feldwartungswerkzeuge als Reaktion auf eine Veränderung an der lokalen Konfiguration des Feldgerätes zu übertragen, und/oder, wobei die Client-Anwendung ferner ausgebildet ist, um bei Ausführung durch den Prozessor die Synchronisierung von einem oder mehreren von Daten-Sets für Benutzerkonfiguration, Prüfpfad-Ereignis, Sicherheitseinstellung, Feldgeräteeinstellung mit der Prozesssteuerungs-Asset-Management-Systemanwendung zu aktivieren oder zu deaktivieren.
Tragbares Feldwartungswerkzeug nach einem der Ansprüche 12 bis 15, insbesondere nach Anspruch 12, wobei die Client-Anwendung ferner ausgebildet ist, um bei Ausführung durch den Prozessor automatisch den Daten-Set zum Kommunikationsserver für tragbare Feldwartungswerkzeuge zu übertragen, sobald Veränderungen an dem Daten-Set vorgenommen werden, falls sich das tragbare Feldwartungswerkzeug bereits in Kommunikation mit dem Kommunikationsserver für tragbare Feldwartungswerkzeuge befindet.
Tragbares Feldwartungswerkzeug nach einem der Ansprüche 12 bis 16, insbesondere nach Anspruch 12,, wobei die Client-Anwendung ausgebildet ist, um bei Ausführung durch den Prozessor den Daten-Set automatisch an den Kommunikationsserver für tragbare Feldwartungswerkzeuge zu übertragen, sobald die Kommunikation zwischen dem tragbaren Feldwartungswerkzeug und dem Kommunikationsserver für tragbare Feldwartungswerkzeuge hergestellt ist, falls Veränderungen an dem Daten-Set vorgenommen werden, wenn sich das tragbare Feldwartungswerkzeug nicht in Kommunikation mit dem Kommunikationsserver für tragbare Feldwartungswerkzeuge befindet.
Ein computer-lesbares Speichermedium, welches Instruktionen enthält, die mindestens einen Prozessor dazu veranlassen, ein Verfahren nach einem der Ansprüche 1 bis 6 zu implementieren, wenn die Instruktionen durch mindestens einen Prozessor ausgeführt werden.