-
Die Erfindung betrifft ein System zur Visualisierung von Statusinformationen von wenigstens einem Feldgerät, welches über ein Bussystem mit einer Bedieneinheit mittels eines PC-basierten Bedientools kommuniziert.
-
Zur Diagnose, Parametrierung oder Visualisierung von mittels eines Bussystems verbundenen Feldgeräten werden üblicherweise Systeme in Form von PC-basierten Programmen (Engineering Tools) verwendet. Diese Systeme kommunizieren über eine vorgegebene, meist standardisierte Kommunikationstechnologie (Ethernet, PROFIBUS, HART usw.) mit dem jeweiligen Feldgerät und stellen an einer üblicherweise direkt am Bussystem oder an einem Steuerungsrechner der Feldgeräte angeschlossenen Bedieneinheit mit Display eine Visualisierung zur Verfügung. Eine Visualisierung stellt beispielsweise aus dem Feldgerät ausgelesene Parameter in graphischer, tabellarischer oder numerischer Weise am Display dar und stellt ggf. Eingabemasken zur Verfügung, über die entsprechende Geräteparameter eingegeben und zur Parametrierung an das jeweilige Feldgerät übertragen werden können.
-
Um eine Vielzahl von Feldgeräten von einer zentralen Warte aus zu bedienen, steht eine Bediensoftware als Bedientool oder Bedienwerkzeug zur Verfügung, die unter einer gemeinsamen Bedienoberfläche den Zugriff auf die unterschiedlichen Feldgeräte ermöglicht. Diese Bedientools bieten Funktionen zur Darstellung der realen Bustopologie, sie bieten, weiterhin zusätzliche Bedienoberflächen zum Einrichten und Überwachen der einzelnen Feldgerate sowie Bedienoberflächen zur Buskonfiguration. Diese Bedientools stellen eine Architektur, einen Rahmen oder einen Frame zur Verfügung, der beispielsweise für ein einheitliches Erscheinungsbild von Anzeigen und Bedienelementen von Feldgeräten sorgt.
-
Beispiele für Bedientools sind Produkte wie bspw. PACTwareTM, Fieldcare oder Fieldmate, die auf der FDT/DTM (Field Device Tool/Device Type Manager)-Technologie basieren. Die FDT/DTM-Technologie stellt eine Reihe von definierten Schnittstellen zur Verfügung, über die eine FDT-Rahmenapplikation (z. Bsp. PACTwareTM) mit den integrierten DTMs als Treibersoftware der Gerätehersteller kommunizieren kann. Diese Schnittstellen ermöglichen den Geräteherstellern eine freie Nutzung sämtlicher Windows-Bedien-elemente zur Gestaltung der Bedienoberfläche des jeweiligen Feldgerätes.
-
Eine andere Technologie wird mittels des Electronic Device Description (EDD)-Konzepts bzw. des Enhanced EDD (EEDD)-Konzepts verfolgt. Für die Beschreibung der Bedienoberfläche existiert eine spezielle Beschreibungssprache, die sogenannte Device Description Language (DDL), hierauf beruht bspw. das Produkt SIMATIC PDM der Firma Siemens. Nur Elemente, die in dieser Beschreibungssprache zur Verfügung stehen, können zur Gestaltung der Bedienoberfläche verwendet werden. Die DDL stellt eine Basistechnologie dar, die von den Lieferanten der Host-Systeme zur Entwicklung stabiler Mensch-Maschine- und Automatisierungsschnittstellen benutzt wird. Auf der DDL basierende Feldgeräte werden unabhängig vom Hersteller in identischer Art und Weise mit den verschiedenen Host-Systemen verknüpft. Sind Änderungen des Host-Betriebssystems (DD-Host) notwendig, so kann der Lieferant des Host-Systems alle Änderungen durchführen, die Beschreibungen der Feldgeräte (Field Device Descriptions, FDD) bleiben davon unberührt.
-
Beiden Technologien ist gemeinsam, dass sie für sich gesehen noch nicht nutzbar sind. Die Nutzbarkeit wird erst dadurch erreicht, dass für die zu bedienenden Feldgeräte die zugehörigen Gerätetreiber geladen werden, dies sind im Falle der FDT-Technologie der DTM (Device Type Manager) und im Falle der DD-Hosts die FDD (Field Device Description).
-
Zur Integration eines Feldgerätes in ein Bedientool ist eine Beschreibung der Bedienoberfläche des jeweiligen Feldgeräts nötig. Eine solche Beschreibung der Bedienoberfläche wird für jedes Feldgerät individuell erstellt. In dieser Beschreibung sind Geräteparameter, d. h. die Gerätebeschreibung in einer Beschreibungssprache beschrieben, so dass die Parameter von dem Bedientool interpretiert werden können. Damit die Bedienoberfläche dann aber tatsächlich mit einem Feldgerät kommunizieren kann, muss zuvor noch die tatsächlich verwendete Topologie der realen Geräte innerhalb der Bedienoberfläche nachgebildet werden.
-
Ein Beispiel für eine reale Topologie ist in 1 dargestellt. In diesem Beispiel ist ein Personalcomputer (PC) 10 als Bedieneinheit über eine serielle Schnittstelle 3 mit einer Steuereinheit 23 verbunden. Die Steuereinheit 23 weist einen Feldbus 5 auf, an welchem die Feldgeräte 14 und 15 angeschlossen sind. Auf der Bedieneinheit 10 ist ein oben beschriebenes Bedientool installiert, welches eine entsprechende Bedienoberfläche erzeugt.
-
In 2 wird beispielhaft gezeigt, wie diese Topologie gemäß 1 in einer der oben genannten Bedienoberflächen nachgebildet werden muss. Diese grafische Darstellung der Bus/Geräte-Struktur nach 1 ist als Baumstruktur ausgeführt. In der Bedienoberfläche müssen für jeden Teilnehmer die passenden Informationen wie z. B. der eingesetzte Gerätetyp, der verwendete Bustyp (z. B. Profibus, Foundation Fieldbus, etc.) die eingestellten Busadressen usw. richtig eingetragen werden, damit die Gerätetreiber dann auch mit den realen Geräten kommunizieren können. Die nachgebildete Bus/Geräte-Struktur wird in diesem Umfeld üblicherweise als Projekt bezeichnet und demnach als Projektdatei abgespeichert.
-
Das Nachbilden einer solchen Topologie in einem Bedientool bzw. Bedienprogramm erfordert einiges an Fachwissen über die verwendeten Feldgeräte und muss in der Bedienoberfläche in allen Punkten korrekt erfolgen. Dies hat sich bei Bedientools, die nur manuelles Nachbilden der Topologie unterstützen, als sehr fehlerträchtig erwiesen. Aus diesem Grunde bieten einige Bedientools bereits Lösungen mit automatisiertem Projektaufbau. Angestoßen durch den Programmstart des Bedientools oder dadurch, dass der Anwender eine bestimmte Funktion im Bedientool betätigt, führt dieses selbsttätig eine Funktion aus, die durch gezieltes Abfragen des angeschlossenen Bussystems einen automatisierten Projektaufbau für die jeweilige Bustopologie leistet. Derart generierte Projektdateien enthalten bereits die Informationen über Gerätetypen, deren Busadressen und die Busstrukturen. Speziell im Falle des Bedientools PACTwareTM sind solche Lösungen verfügbar, die auch komplexe Busstrukturen über mehrere Hierarchieebenen hinweg nachbilden können.
-
Wie bereits verdeutlicht wurde, repräsentiert jedes Objekt der Projektdatei ein Feldgerät der realen Topologie. Somit liegt es nahe, dass der Aufruf des jeweiligen Gerätetreibers direkt durch die Auswahl in der Projektdatei von statten geht. In 3 ist abgebildet, wie das Selektieren von Objekt „Device 1” die Bedienoberfläche des zugehörigen Gerätetreibers „Device 1” als zweites Fenster öffnet, in welchem Parameter 1 und 2, Funktionen „Function 1” und „Function 2” sowie ein Zustand „State 1” aufgerufen werden können. Damit kann der Benutzer in dieser Bedienoberfläche sämtliche Einstellungen des Feldgeräts „Device 1” überprüfen (Function 1, Function 2) bzw. ändern (Parameter 1, Parameter 2). Auch kann er in dieser Bedienoberfläche Informationen zum aktuellen Gerätestatus (State 1) abfragen. Somit wäre es möglich, sich durch einzelnes Öffnen aller Gerätetreiber-Bedienoberflächen einen Überblick über den aktuellen Anlagenstatus zu verschaffen. In kleinen Anlagen ist ein solches Vorgehen möglich um den Anlagenstatus immer wieder zu prüfen. Handelt es sich aber um größere Anlagen mit beispielsweise einigen hundert Feldgeräten, so ist dieses Vorgehen nicht praktikabel.
-
Aus diesem Grunde wurde die FDT-Schnittstelle um eine Methode zur verbesserten Diagnose erweitert. Dies ermöglicht für die FDT-Rahmenanwendung die Nutzung der DTM-Instanzen der Projektdatei für aktives Abfragen der Diagnoseinformationen der einzelnen DTMs ohne die Erfordernis des expliziten Öffnens der DTM-Benutzeroberfläche. Dabei liefert dieses Verfahren die Diagnoseinformation bereits in Form einer sogenannten „verdichteten” Anzeige nach NE 107 (NAMUR-Empfehlung 107). Die NE 107 trägt bereits dem Umstand Rechnung, dass der Benutzer nur die für ihn wichtigsten Informationen erhält. Demnach wurden in dieser Empfehlung die langen Listen an unterschiedlichen Fehlercodes kategorisiert und somit auf 4 grundlegende Fehlerzustände reduziert. Die hier erwähnte Methode liefert nur noch die fünf Informationen („OK” und 4 Fehlerzustände) aus der NE 107 an die Rahmenanwendung. Die vier Fehlerzustände repräsentieren die folgenden Kategorien gemäß folgender Tabelle:
-
In 4 ist dargestellt, wie diese neue Methode innerhalb der Projektansicht einer FDT-Rahmenanwendung genutzt werden kann. Die grafische Darstellung der Bus/Geräte-Struktur entspricht derjenigen nach 2, weist jedoch zusätzliche Anzeigefelder A1, A2 und A3 für die Steuereinheit PLC1, das Feldgerät „Device 1” bzw. das Feldgerät „Device 2” auf. Diese Anzeigefelder A1 bis A3 können mit einem der vier Symbole nach der NE 107 gemäß der obigen Tabelle belegt werden. Auf diese Art und Weise kann der Benutzer schnell überblicken, welche Geräte in der Gesamtanlage überprüft werden müssen. In 4 wird für den Status OK der Feldgerätes „Device 1” und der Steuereinheit PLC 1 ein Haken, für den Status „Ausfall” des Feldgerätes „Device 2” wird das entsprechende Symbol aus der obigen Tabelle angezeigt.
-
Diese Funktion kann genutzt werden, wenn die DTMs mit der erforderlichen Schnittstelle ausgestattet sind und die Bedienoberfläche diese Funktion ausführt und die Ergebnisse darstellt. Da die Methode in den FDT-Standard aufgenommen wurde, werden künftige Produkte diese Methode auch unterstützen können.
-
Durch entsprechende Zusatzfunktionen mit Bedienoberflächen in der FDT-Rahmenanwendung besteht somit auch grundsätzlich die Voraussetzung, dass die einzelnen Statusinformationen zu einem Gesamtanlagenstatus zusammengefasst werden und in der FDT-Rahmenanwendung angezeigt werden könnten. Die Abfrage der einzelnen Statusinformationen kann hierbei automatisiert zyklisch vorgenommen werden.
-
Der Nachteil einer solchen Lösung ist jedoch, dass der Benutzer sich innerhalb einer Bedienoberfläche bewegt, die primär zum Einstellen und Bedienen einzelner Geräte innerhalb einer Gesamtanlage konzipiert ist und demnach grundsätzlich hierfür ausgerichtet ist. Dies erfordert allerdings eine hohe Anzahl an Bedienelementen, was typischerweise für ungeübte Benutzer zu unübersichtlichen Benutzeroberflächen führt.
-
Ferner sind Bedientools bekannt, die zusätzlich Bedienoberflächen zur Programmierung der eigentlichen Steuerungsfunktionen anbieten. In hochintegrierten Lösungen werden Bedienoberflächen speziell zur Programmierung von Visualisierungsfenstern für Prozessvariable in grafisch aufwändigen Darstellungen angeboten. Ein Anbieter solcher Bedientools ist zum Beispiel das Engineeringsystem „System 800xA” der Firma ABB. Die Visualisierungsfenster bieten zwar alle denkbaren Anzeigevarianten für den Benutzer, sie müssen aber individuell neu programmiert werden. Für die Programmierung derartiger Lösungen müssen die Anlagenbetreiber häufig spezialisierte Ingenieurbüros bemühen, was mit hohen Kosten verbunden ist. Im Falle von Änderungen oder Erweiterungen in der Anlage müssen wiederum entsprechende Anpassungen mit erneut hohen Kosten vorgenommen werden.
-
Zur Integration eines Feldgerätes in ein Bedientool ist eine Beschreibung der Bedienoberfläche des jeweiligen Feldgeräts nötig. Die Bedienoberfläche wird für jedes Feldgerät individuell erstellt. In der Bedienoberfläche sind Geräteparameter, d. h. die Gerätebeschreibung in einer Beschreibungssprache beschrieben, so dass die Parameter von dem Bedientool interpretiert werden können. Weil die Beschreibungssprache für die jeweilige Bedientoolarchitektur standardisiert ist, ist es möglich, die Bedienung von Feldgeräten unterschiedlicher Hersteller unter dem gemeinsamen Bedientool zusammenzuführen.
-
Es ist Aufgabe der vorliegenden Erfindung, ein System zur Visualisierung von Statusinformationen von Feldgeräten, welche über ein Bussystem mit einer Bedieneinheit mittels eines PC-basierten Bedientools kommunizieren, zu schaffen, das eine komprimierte und übersichtliche Überwachung der Feldgeräte ermöglicht, so dass für eine Bedienperson sofort erkennbar ist, ob die zu überwachende Anlage im zulässigen Bereich operiert oder für Teile der Anlage ein Wartungsbedarf besteht, ohne dass diese Bedienperson irgendwelche Bedientools aufrufen und starten oder Informationen in komplexen und unübersichtlichen Bedienoberflächen zusammensuchen muss.
-
Diese Aufgabe wird gelöst durch ein System mit den Merkmalen des Patentanspruchs 1.
-
Ein solches System zur Visualisierung von Statusinformationen von wenigstens einem Feldgerät, welches über ein Bussystem mit einer Bedieneinheit mittels eines PC-basierten Bedientools kommuniziert, zeichnet sich erfindungsgemäß dadurch aus, dass das PC-basierte Bedientool für den Datenaustausch mit einer in eine graphische Benutzeroberfläche der Bedieneinheit eingebettete Minianwendung (Gadget, Applet) eine Schnittstelle aufweist, wobei mittels der Minianwendung die Statusinformationen angezeigt werden.
-
Mit einer solchen Minianwendung (Gadget, Applet), vorzugsweise einer WindowsTM-Minianwendung kann der Anwender an seiner Bedieneinheit den Anlagestatus der mit einem Feldbus verbundenen Feldgeräte erkennen, ohne dass hierfür die Zustände der einzelnen Feldgeräte in einer komplexen Bedienoberfläche abgeprüft werden müssen. Ferner können solche Minianwendungen auf eine vorgegebene Aufgabe fokussiert und immer im Vordergrund einer Bedienoberfläche dargestellt werden.
-
Unter einer Minianwendung, auch Widget oder Applet genannt, wird ein kleines Computerprogramm verstanden, das in eine graphische Benutzeroberfläche oder Webseite eingebunden wird. In der Regel handelt es sich bei solchen Minianwendungen um Hilfs- bzw. Dienstprogramme oder Tools (Uhr, Wetter, oder auch eine Suchboxfunktion). Diese Minianwendungen benötigen eine Umgebung, die über eine Programmierschnittstelle Grundfunktionen und Ressourcen bereitstellt und können somit nicht als eigenständige, unabhängige Programme auf einem Betriebssystem verwendet werden.
-
Solche Minianwendungen sind für Host PC's mit WindowsTM Betriebssystemen „Microsoft Windows Vista” oder „Microsoft Windows 7” bekannt und ermöglichen eine kompakte Darstellung von wichtigen Daten, die auf dem WindowsTM-Desktop in einem dafür vorgesehen Bereich dargestellt werden.
-
Eine vorteilhafte Ausgestaltung der Erfindung sieht für die Architektur des PC-basierten Bedientools die FDT/DTM (Field Device Tool/Device Type Manager)-Technologie oder das EDD/DDL (Electronic Device Description/Device Description Language-) bzw. EEDD/DDL (Enhanced Electronic Device Description/Device Description Language)-Konzept vor, vorzugsweise werden als Statusinformationen die der NAMUR-Empfehlung NE107 entsprechenden Statusinformationen zur Verfügung gestellt. Damit ist eine besonders übersichtliche Darstellung aller Feldgeräte möglich, da dem Bedienpersonal lediglich eine der fünf Statusinformationen der NE107 als jeweilige Diagnoseinformation für alle zu überwachende Feldgeräte angeboten wird.
-
Damit ist es möglich, mehrere Feldgeräte mit gerätespezifischen PC-basierten Bedientools vorzusehen, die auf unterschiedlichen Architekturen bestehen, deren Betriebszustand mit der erfindungsgemäßen Minianwendung in einer einzigen und übersichtlichen Darstellung angezeigt werden.
-
Die Erfindung wird nachstehend anhand von Ausführungsbeispielen unter Bezugnahme auf die beigefügten Figuren ausführlich beschrieben. Es zeigen:
-
1 eine schematische Darstellung einer Topologie eines Feldbusses mit zwei Feldgeräten zur Erläuterung des erfindungsgemäßen Systems,
-
2 eine schematische Darstellung der auf einer Bedienoberfläche nachgebildeten Bus/Geräte-Struktur nach 1,
-
3 eine schematische Darstellung der Bedienoberfläche nach 2 mit einem selektierten Objekt,
-
4 eine schematische Darstellung der auf einer Bedienoberfläche nachgebildeten Bus/Geräte-Struktur nach 1 mit einer Darstellung von Diagnoseinformationen gemäß der NAMUR-Empfehlung 107,
-
5 eine schematische Darstellung der Softwarekomponenten des erfindungsgemäßen Systems als Ausführungsbeispiel,
-
6 eine schematische Darstellung der Statusinformationen von drei Feldgeräten in einer Minianwendung gemäß des erfindungsgemäßen Systems nach 5, und
-
7 eine weitere schematische Darstellung der Statusinformationen eines ausgewählten Feldgerätes in einer Minianwendung gemäß des erfindungsgemäßen Systems nach 5.
-
Die 1 bis 4 wurden bereits in der Beschreibungseinleitung erläutert.
-
Zur Erläuterung des ersten Ausführungsbeispiels gemäß 5 wird Bezug genommen auf eine Feldbusstruktur gemäß 1, die jedoch anstelle von zwei Feldgeräten 14, nämlich Device 1 und Device 2, drei Feldgeräte 14 aufweisen, die im Folgenden als Device 1, Device 2 und Device 3 bezeichnet werden.
-
Auf der Bedieneinheit 10, ein Personalcomputer PC mit Bildschirm ist ein Bedientool für die Feldgeräte Device 1, Device 2 und Device 3 installiert. Dieses Bedientool kann bspw. auf der FDT/DTM-Technologie basieren oder auf dem EDD-Konzept. Diese Situation ist in 5 dargestellt, die eine schematische Darstellung der Bedieneinheit 10 (einschließlich Bildschirm) mit einer ausführungsbeispielgemäßen Softwarestruktur. Diese Softwarestruktur besteht aus dem Bedientool 20, welches eine Schnittstelle 50 zu einer Minianwendung 30 aufweist, die in eine graphische Benutzeroberfläche 40 eingebettet ist. Diese Schnittstelle 50 dient dazu, vorgegebene Statusinformationen der Feldgeräte an die Minianwendung zur Anzeige weiterzugeben. Weist diese als PC ausgebildete Bedieneinheit 10 ein WindowsTM Betriebssystem auf, stehen die entsprechenden WindowsTM Minianwendungen zur Verfügung, die in die WindowsTM Benutzeroberfläche eingebettet sind.
-
Bei den an den Feldbus 5 (1) angeschlossen drei Feldgeräten Device 1, Device 2 und Device 3 ist die grafische Darstellung der Minianwendung in 6 in Form einer Tabelle mit drei Zeilen und einer Spalte dargestellt. In der ersten Spalte sind die Statuszustände „State” und in der zweiten Spalte die Bezeichnungen der Feldgeräte „Device 1”, „Device 2” und „Device 3” eingetragen. Als Statuszustand dient einer der 5 entsprechend der NE107 vorgeschlagenen fünf Informationen, also der Zustand „in Ordnung” bzw. „OK” sowie die vier Fehlerzustände: Funktionskontrolle, Außerhalb der Spezifikation, Wartungsbedarf und Ausfall. Dabei wird zur Kennzeichnung des Statuszustandes entweder ein „Haken” als grafisches Symbol für den Zustand „OK” oder eines der grafischen Symbole für die vier Fehlerzustände gemäß der NE 107 gesetzt. Diese Statusinformationen werden zyklisch von dem Bedientool abgefragt und über die Schnittstelle 50 mittels der Minianwendung 30 grafisch dargestellt.
-
Eine solche Minianwendung wird auf dem Desktop der Bedieneinheit 10 an einer frei wählbaren Stelle ständig im Vordergrund angezeigt. Da das Bedientool die Betriebszustände bzw. die Statusinformationen der Feldgeräte zyklisch abfragt und in der Minianwendung darstellt, sind die aktuellen Statusinformationen für das Bedienpersonal in einer übersichtlichen Darstellung ständig verfügbar.
-
Solche Minianwendungen können einfach konfiguriert werden, um den Informationsinhalt der Anzeige an vorgegebene Forderungen anzupassen. So kann entsprechend 7 eine Anzeige einer Minianwendung nur auf die Darstellung der Statusinformationen eines bestimmten Feldgerätes „Device 1” beschränkt werden. Diese grafische Darstellung besteht daher lediglich aus einer Zeile mit zwei Spalten, die den Zustand „State” und die Bezeichnung des zu überwachenden Feldgerätes „Device 1” eingetragen. Als Statuszustand dienen die in der Minianwendung gemäß 6 beschriebenen Symbole der Empfehlung NE 107.
-
Anstelle des PCs 10 kann auch die Steuereinheit 23 (1) als Bedieneinheit dienen, auf der dann das Bedientool 20 mit der Schnittstelle 50 und den Minianwendungen 30 installiert und betrieben werden.