DE102017124551A1 - Vorrichtung und verfahren für dynamische gerätebeschreibungssprachmenüs - Google Patents

Vorrichtung und verfahren für dynamische gerätebeschreibungssprachmenüs Download PDF

Info

Publication number
DE102017124551A1
DE102017124551A1 DE102017124551.0A DE102017124551A DE102017124551A1 DE 102017124551 A1 DE102017124551 A1 DE 102017124551A1 DE 102017124551 A DE102017124551 A DE 102017124551A DE 102017124551 A1 DE102017124551 A1 DE 102017124551A1
Authority
DE
Germany
Prior art keywords
ddl
menu
constructs
user interface
graphical
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102017124551.0A
Other languages
English (en)
Inventor
Christian James Kulus
Walter Hendrik Sigtermans
Thanh Ngan Truong
Katie Grams Urbanski
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fisher Rosemount Systems Inc
Original Assignee
Fisher Rosemount Systems Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fisher Rosemount Systems Inc filed Critical Fisher Rosemount Systems Inc
Publication of DE102017124551A1 publication Critical patent/DE102017124551A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00Programme-control systems
    • G05B19/02Programme-control systems electric
    • G05B19/418Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM]
    • G05B19/41845Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM] characterised by system universality, reconfigurability, modularity
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/048Interaction techniques based on graphical user interfaces [GUI]
    • G06F3/0481Interaction techniques based on graphical user interfaces [GUI] based on specific properties of the displayed interaction object or a metaphor-based environment, e.g. interaction with desktop elements like windows or icons, or assisted by a cursor's changing behaviour or appearance
    • G06F3/0482Interaction with lists of selectable items, e.g. menus
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00Programme-control systems
    • G05B19/02Programme-control systems electric
    • G05B19/18Numerical control [NC], i.e. automatically operating machines, in particular machine tools, e.g. in a manufacturing environment, so as to execute positioning, movement or co-ordinated operations by means of programme data in numerical form
    • G05B19/409Numerical control [NC], i.e. automatically operating machines, in particular machine tools, e.g. in a manufacturing environment, so as to execute positioning, movement or co-ordinated operations by means of programme data in numerical form characterised by using manual data input [MDI] or by using control panel, e.g. controlling functions with the panel; characterised by control panel details or by setting parameters
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B23/00Testing or monitoring of control systems or parts thereof
    • G05B23/02Electric testing or monitoring
    • G05B23/0205Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults
    • G05B23/0208Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterized by the configuration of the monitoring system
    • G05B23/0216Human interface functionality, e.g. monitoring system providing help to the user in the selection of tests or in its configuration
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/048Interaction techniques based on graphical user interfaces [GUI]
    • G06F3/0484Interaction techniques based on graphical user interfaces [GUI] for the control of specific functions or operations, e.g. selecting or manipulating an object, an image or a displayed text element, setting a parameter value or selecting a range
    • G06F3/04847Interaction techniques to control parameter settings, e.g. interaction with sliders or dials
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00Program-control systems
    • G05B2219/30Nc systems
    • G05B2219/32Operator till task planning
    • G05B2219/32128Gui graphical user interface
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00Program-control systems
    • G05B2219/30Nc systems
    • G05B2219/32Operator till task planning
    • G05B2219/32144Define device description using dd files
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00Program-control systems
    • G05B2219/30Nc systems
    • G05B2219/33Director till display
    • G05B2219/33273DCS distributed, decentralised controlsystem, multiprocessor
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00Program-control systems
    • G05B2219/30Nc systems
    • G05B2219/36Nc in input of data, input key till input tape
    • G05B2219/36169Remote, host controlled, operated manual data input, keyboard
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00Handling natural language data
    • G06F40/10Text processing
    • G06F40/166Editing, e.g. inserting or deleting
    • G06F40/186Templates
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02PCLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
    • Y02P90/00Enabling technologies with a potential contribution to greenhouse gas [GHG] emissions mitigation
    • Y02P90/02Total factory control, e.g. smart factories, flexible manufacturing systems [FMS] or integrated manufacturing systems [IMS]

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • Automation & Control Theory (AREA)
  • Theoretical Computer Science (AREA)
  • Manufacturing & Machinery (AREA)
  • Quality & Reliability (AREA)
  • User Interface Of Digital Computer (AREA)
  • Testing And Monitoring For Control Systems (AREA)
  • Programmable Controllers (AREA)

Abstract

Ein Verfahren und System konfiguriert eine Device Description Language(DDL)-Oberfläche auf einem DDL-basierten Host-System in einer Prozessanlage. Unter Verwendung einer Gerätebeschreibungsidentifikation aktualisiert das System und Verfahren das Host-System mit der Gerätebeschreibung für ein ausgewähltes Prozesssteuergerät. Die Gerätebeschreibung schließt Menüs für das ausgewählte Prozesssteuergerät ein. Das Verfahren und das System legen die DDL-Menükonstrukte aus der Gerätebeschreibung dem Host-System gegenüber offen, so dass das Host-System in der Lage ist, die DDL-Konstrukte als vom Benutzer auswählbare Elemente auf einer Konfigurationsoberfläche zu präsentieren, wo DDL-Konstrukte hinzugefügt, gelöscht und/oder modifiziert werden können, um eine DDL-Oberfläche unabhängig von dem Menü für das Prozesssteuergerät zu erzeugen, wie es in der Gerätebeschreibung bereitgestellt wird.

Description

  • GEBIET DER TECHNIK
  • Die vorliegende Offenbarung betrifft allgemein Prozesssteuerungssysteme innerhalb von Prozessanlagen und genauer ein dynamisches Erzeugen und Modifizieren von Gerätebeschreibungssprach- bzw. Device-Description-Language-Menüs.
  • HINTERGRUND
  • Prozesssteuerungssysteme werden in großem Umfang in Fabriken und/oder Anlagen verwendet, in denen Produkte hergestellt oder Prozesse gesteuert werden (z.B. Chemieproduktion, Kraftwerkssteuerung usw.). Prozesssteuerungssysteme werden auch bei der Gewinnung von natürlichen Ressourcen, wie beispielsweise in Öl- und Gasförderungs- und -leitungsprozessen usw. verwendet. In der Tat kann praktisch jeder Herstellungsprozess, Ressourcengewinnungsprozess usw. durch die Anwendung eines oder mehrerer Prozesssteuerungssysteme automatisiert werden. Es ist anzunehmen, dass die Prozesssteuerungssysteme letztendlich auch in der Landwirtschaft stärker eingesetzt werden.
  • Prozesssteuerungssysteme wie sie beispielsweise in chemischen, Erdöl- und anderen Prozessen verwendet werden, schließen in der Regel eine oder mehrere zentralisierte oder dezentralisierte Prozesssteuereinrichtungen ein, die über analoge, digitale oder kombinierte analoge/digitale Busse kommunikationstechnisch mit mindestens einer Host- oder Bediener-Workstation und mit einer oder mehreren Prozesssteuereinrichtungs- und -instrumentierungsvorrichtungen, beispielsweise Feldgeräten, gekoppelt sind. Feldgeräte, bei denen es sich beispielsweise um Ventile, Ventilsteller, Schalter, Sender und Sensoren (z.B. um Temperatur-, Druck- und Durchflusssensoren) handeln kann, führen Funktionen innerhalb des Prozesses aus, wie das Öffnen oder Schließen von Ventilen und das Messen von Prozessparametern. Die Prozesssteuereinrichtung empfängt Signale, die Prozessmesswerte oder Prozessvariablen angeben, die von den Feldgeräten hervorgebracht werden oder die mit diesen assoziiert sind, und/oder andere Informationen, die diese Feldgeräte betreffen, verwendet diese Informationen, um eine Steuerroutine zu implementieren, und generiert dann Steuersignale, die über einen oder mehrere von den Bussen zu den Feldgeräten geschickt werden, um den Ablauf des Prozesses zu steuern. Informationen von den Feldgeräten und der Steuereinrichtung werden in der Regel einer oder mehreren von einer Bediener-Workstation ausgeführten Anwendungen verfügbar gemacht, um einen Bediener in die Lage zu versetzen, gewünschte Funktionen in Bezug auf den Prozess durchzuführen, beispielsweise Betrachten des aktuellen Prozessstatus, Modifizieren des Prozessablaufs usw.
  • Die verschiedenen Geräte innerhalb der Prozessanlagen können in physischen oder logischen Gruppen miteinander verbunden werden, um einen logischen Prozess, beispielsweise eine Regelschleife zu erzeugen. Ebenso kann eine Regelschleife mit anderen Regelschleifen und/oder Geräten verbunden werden, um Untereinheiten zu erzeugen. Eine Untereinheit kann mit anderen Untereinheiten verbunden werden, um eine Einheit zu erzeugen, die ihrerseits mit anderen Einheiten verbunden werden kann, um einen Bereich zu erzeugen. Prozessanlagen schließen im Allgemeinen miteinander verbundene Bereiche ein, und Wirtschaftseinheiten schließen im Allgemeinen Prozessanlagen ein, die miteinander verbunden sein können. Infolgedessen schließt eine Prozessanlage zahlreiche Hierarchieebenen mit miteinander verbundenen Einrichtungen ein, und ein Wirtschaftsunternehmen kann miteinander verbundene Prozessanlagen einschließen. Anders ausgedrückt können Einrichtungen, die zu einer Prozessanlage gehören, oder Prozessanlagen selbst, zu Gruppen zusammengefasst werden, um Einrichtungen höherer Ebenen zu bilden.
  • Die Art und Weise, wie Prozesssteuerungssysteme implementiert werden, hat sich im Laufe der Jahre verändert. Prozesssteuerungssysteme älterer Generationen wurden in der Regel unter Verwendung zweckgebundener, zentralisierter Hardware und Kabelverbindungen implementiert.
  • Jedoch werden moderne Prozesssteuerungssysteme in der Regel unter Verwendung eines stark verteilten Netzwerks aus Workstations, intelligenten Steuereinrichtungen, intelligenten Feldgeräten und dergleichen implementiert, von denen manche oder alle einen Teil einer übergeordneten Prozesssteuerungsstrategie oder -planung umsetzen können. Genauer gesagt schließen die meisten modernen Prozesssteuerungssysteme intelligente Feldgeräte und andere Prozesssteuerungskomponenten ein, die über einen oder mehrere digitale Datenbusse kommunikationstechnisch miteinander und/oder mit einer oder mehreren Prozesssteuereinrichtungen verbunden sind. Zusätzlich zu intelligenten Feldgeräten können moderne Prozesssteuerungssysteme auch analoge Feldgeräte einschießen wie beispielsweise 4-20 Milliampere(mA)-Geräte, 0-10 Volt-Gleichspannungs(VDC)-Geräte usw., die in der Regel direkt mit Steuereinrichtungen gekoppelt werden und nicht mit einem gemeinsamen Datenbus oder dergleichen.
  • In einer typischen Industrie- oder Prozessanlage wird ein verteiltes Steuerungssystem (distributed control system, DCS) verwendet, um viele der industriellen Prozesse zu steuern, die in der Anlage durchgeführt werden. Die Anlage kann einen zentralisierten Steuerraum aufweisen, der ein Computersystem aufweist mit einer Benutzer-Eingabe/Ausgabe (I/O), einer Platten-I/O und anderen peripheren Geräten, die auf dem Gebiet der Computertechnik bekannt sind, mit einer oder mehreren Prozesssteuereinrichtungen und mit Prozess-I/O-Teilsystemen, die kommunikationstechnisch mit dem zentralisierten Steuerraum verbunden sind. Außerdem ist bzw. sind in der Regel ein oder mehrere Feldgeräte mit den I/O-Teilsystemen und mit den Prozesssteuereinrichtungen verbunden, um Steuer- und Messaktivitäten innerhalb der Anlage zu implementieren. Während das Prozess-I/O-Teilsystem mehrere I/O-Ports einschließen kann, die mit den verschiedenen Feldgeräten überall in der Anlage verbunden sein können, können die Feldgeräte verschiedene Arten von analytischer Ausrüstung, Siliciumdrucksensoren, kapazitiven Drucksensoren, Widerstands-Temperatursensoren, Thermoelementen, Dehnungsmessstreifen, Endschaltern, Ein/Aus-Schaltern, Durchflussgebern, Druckgebern, Füllstandsschaltern, Waagen, Messwandlern, Ventilstellern, Ventilsteuereinrichtungen, Aktoren, Magnetspulen, Leuchtanzeigen oder irgendwelchen anderen Geräten, die typischerweise in Prozessanlagen verwendet werden, einschließen.
  • Wie hierin verwendet, umfasst der Ausdruck „Feldgerät“ diese Geräte ebenso wie alle anderen Geräte, die eine Funktion in einem Steuerungssystem erfüllen. Auf jeden Fall können Feldgeräte beispielsweise Eingabegeräte (z.B. Geräte wie Sensoren, die Statussignale liefern, durch die Prozesssteuereinrichtungsparameter wie beispielsweise Temperatur, Druck, Durchsatz usw. angegeben werden) sowie Steuerungsantriebe oder -aktoren beinhalten, die als Reaktion auf Befehle, die von Steuereinrichtungen und/oder anderen Feldgeräten erhalten werden, Aktionen durchführen.
  • Herkömmlicherweise werden analoge Feldgeräte über Stromschleifen aus zweiadrigen verseilten Doppelkabeln miteinander verbunden, wobei jedes Gerät über ein einzelnes zweiadriges verseiltes Doppelkabel mit der Steuereinrichtung verbunden wird. Analoge Feldgeräte sind in der Lage, innerhalb einer spezifizierten Reichweite auf ein elektrisches Signal zu antworten oder ein solches zu senden. In einer typischen Konfiguration liegt üblicherweise ein Spannungsdifferential von etwa 20-25 Volt zwischen den beiden Adern des Doppelkabels vor, und ein Strom von 4-20 mA fließt durch die Schleife. Ein analoges Feldgerät, das ein Signal an den Steuerraum sendet, moduliert den Strom, der durch die Stromschleife fließt, wobei der Strom proportional ist zu der vom Sensor abgefühlten Prozessvariablen.
  • Ein analoges Feldgerät, das unter der Kontrolle des Steuerraums eine Aktion durchführt, wird durch die Stärke des Stroms, der durch die Schleife fließt, gesteuert, und dieser Strom wird vom I/O-Port des Prozess-I/O-Systems moduliert, der seinerseits von der Steuereinrichtung gesteuert wird. Herkömmliche zweiadrige analoge Geräte mit aktiver Elektronik können auch bis zu 40 Milliwatt Leistung von der Schleife aufnehmen. Analoge Feldgeräte, die mehr Leistung benötigen, werden üblicherweise anhand von vier Adern mit der Steuereinrichtung verbunden, wobei zwei von den Adern das Gerät mit Leistung versorgen. Solche Geräte werden in der Technik als vieradrige Geräte bezeichnet und sind in ihrer Leistungsaufnahme nicht beschränkt, wie dies für die zweiadrigen Geräte typisch ist.
  • Ein diskretes Feldgerät kann ein binäres Signal senden oder beantworten. Typischerweise arbeiten diskrete Feldgeräte mit einem 24 Volt-Signal (entweder Wechsel- oder Gleichspannung), einem 110 oder 240 Volt-Wechselspannungssignal oder einem 5 Volt-Gleichspannungssignal. Natürlich kann ein diskretes Gerät so gestaltet sein, dass es gemäß einer elektrischen Spezifikation arbeitet, die von einer bestimmten Steuerungsumgebung verlangt wird. Ein diskretes Eingabe-Feldgerät ist einfach ein Schalter, der die Verbindung mit der Steuereinrichtung herstellt oder unterbricht, während ein diskretes Ausgabe-Feldgerät eine Aktion aufgrund des Vorliegens oder des Fehlens eines Signals von der Steuereinrichtung durchführt.
  • Historisch gesehen hatten herkömmliche Feldgeräte meistens entweder einen einzelnen Eingang oder einen einzelnen Ausgang, der direkt mit der primären Funktion in Beziehung stand, die von dem Feldgerät ausgeführt wurde. Zum Beispiel besteht die einzige Funktion, die von einem herkömmlichen Widerstands-Temperatursensor implementiert wird, in der Übermittlung einer Temperatur durch Modulieren des Stroms, der durch das zweiadrige verseilte Doppelkabel fließt, während die einzige Funktion, die von einem herkömmlichen analogen Ventilsteller implementiert wird, darin besteht, ein Ventil auf Basis der Stärke des Stroms, der durch das zweiadrige Doppelkabel fließt, irgendwo zwischen einer vollständig offenen und einer vollständig geschlossenen Stellung zu positionieren.
  • In jüngerer Zeit werden Feldgeräte verfügbar, die Teil von hybriden Systemen sind, die digitale Daten über die Stromschleife legen, die verwendet wird, um analoge Signale zu übertragen. Ein solches hybrides System ist in der Steuerungstechnik als Highway Addressable Remote Transducer (HART)-Protokoll bekannt. Das HART-System verwendet die Stärke des Stroms in der Stromschleife, um ein analoges Steuersignal zu senden oder um eine abgefühlte Prozessvariable zu empfangen (wie im herkömmlichen System), aber es legt außerdem ein digitales Trägersignal über das Stromschleifensignal. Das HART-Protokoll nutzt den Bell 202 Frequency Shift Keying (FSK)- bzw. Frequenzumtastungsstandard, um die digitalen Signale auf einer niedrigen Ebene über die analogen 4-20 mA-Signale zu legen. Dadurch können Zweiwege-Feldkommunikationen stattfinden, und es ist möglich, über die normale Prozessvariable hinaus zusätzliche Informationen an ein/von einem intelligenten Feldgerät zu übermitteln. Das HART-Protokoll kommuniziert mit 1200 bps, ohne das 4-20 mA-Signal zu unterbrechen, und ermöglicht einer Host-Anwendung (einem Master), zwei oder mehr digitale Aktualisierungen pro Sekunden von einem Feldgerät zu erhalten. Da das digitale FSK-Signal phasenkontinuierlich ist, gibt es keine Interferenz mit dem 4-20 mA-Signal.
  • Das FSK-Signal ist relativ langsam und kann daher Aktualisierungen einer sekundären Prozessvariablen oder eines anderen Parameters mit einer Rate von ungefähr 2-3 Aktualisierungen pro Sekunde liefern. Im Allgemeinen wird das digitale Trägersignal verwendet, um sekundäre und Diagnoseinformationen zu senden, und wird nicht verwendet, um die primäre Steuerfunktion des Feldgeräts zu erfüllen. Beispiele für Informationen, die über das digitale Trägersignal geliefert werden, schließen sekundäre Prozessvariablen, Diagnoseinformationen (einschließlich von Sensordiagnostik, Gerätediagnostik, Stromleitungsdiagnostik und Prozessdiagnostik), Betriebstemperaturen, eine Sensortemperatur, Kalibrierungsinformationen, Geräte-ID-Nummern, verwendete Materialien, Konfigurations- oder Programmierungsinformationen usw. ein. Somit kann ein einzelnes hybrides Feldgerät eine Reihe verschiedener Eingangs- und Ausgangsvariablen aufweisen und kann eine Reihe verschiedener Funktionen implementieren.
  • In jüngerer Zeit wurde ein neueres Steuerprotokoll von der Instrument Society of America (ISA) definiert. Das neue Protokoll wird allgemein als Fieldbus bezeichnet und wird genauer als SP50 bezeichnet, ein Akronym für Standards and Practice Subcommittee 50. Das Fieldbus-Protokoll definiert zwei Unterprotokolle. Ein H1-Fieldbus-Netzwerk sendet Daten mit einer Rate von bis zu 31,25 Kilobits pro Sekunde und liefert Leistung zu Feldgeräten, die mit dem Netzwerk verbunden sind. Ein H2-Fieldbus-Netzwerk sendet Daten mit einer Rate von bis zu 2,5 Megabits pro Sekunde, liefert keine Leistung zu Feldgeräten, die mit dem Netzwerk verbunden sind, und ist mit redundanten Übertragungsmedien versehen. Fieldbus ist ein nicht-proprietärer offener Standard und hat sich mittlerweile in der Industrie durchgesetzt, und von daher wurden viele Arten von Fieldbus-Geräten entwickelt, die in Prozessanlagen verwendet werden. Fieldbus-Geräte werden zusätzlich zu anderen Arten von Feldgeräten, wie HART- und 4-20 mA-Geräten, verwendet, wobei mit jeder dieser unterschiedlichen Arten von Geräten eine separate Unterstützungs- und I/O-Kommunikationsstruktur assoziiert ist.
  • Neuere intelligente Feldgeräte, die typischerweise alle von digitaler Natur sind, weisen Wartungsmodi und verbesserte Funktionen auf, auf die ältere Steuersysteme nicht zugreifen können oder die nicht mit ihnen kompatibel sind. Auch wenn sich alle Komponenten eines verteilten Steuersystems an den gleichen Standard (beispielsweise den Fieldbus-Standard) halten, kann es sein, dass die Steuerausrüstung eines Herstellers nicht in der Lage ist, auf die sekundären Funktionen oder auf sekundäre Informationen zuzugreifen, die von den Feldgeräten eines anderen Herstellers bereitgestellt werden.
  • Typischerweise schließen die Kommunikationsprotokolle, die von diesen Foundations definiert werden, Standards ein, die spezifizieren, wie sich die einzelnen Geräte anhand der sogenannten Device Description (DD) bzw. Gerätebeschreibung selbst identifizieren und wie sie mit einem Prozesssteuerungssystem kommunizieren, wobei DD die Anwendungsschicht des Protokolls und verschiedene Benutzeroberflächendefinitionen definiert, die nötig sind, um mit dem Gerät zu kommunizieren. DD wird in der bekannten und gut unterstützten Device Description Language (DDL) (auch als elektronische Device Description Language (EDDL)) geschrieben, die als ein Standard der Internationalen Elektrotechnischen Kommission (z.B. IEC 61804) etabliert wurde. Jeder Gerätetyp: weist typischerweise seine eigene DD auf, das heißt eine formale Beschreibung der Daten und Betriebsabläufe für ein Feldgerät, einschließlich von Variablen, Daten (Parametern) Kommunikation (Adressinformationen), Verfahren, Befehlen/Operationen (z.B. Kalibrierung) und grafischen Benutzeroberflächen (z.B. Menüs und Anzeigeformaten), die mit verschiedenen Merkmalen des Geräts assoziiert sind. Generell sind Informationen über jede für einen Zugriff offene Variable des Geräts in der Gerätebeschreibung enthalten, um dadurch die Kompatibilität des Geräts und dessen Kommunikationsmöglichkeiten zu definieren. Solche Variablen schließen beispielsweise Prozessmesswerte, etwaige abgeleitete Werte und alle internen Parameter des Gerätes ein, wie Reichweite, Sensortyp, auswählbare Linearisierung, verwendete Materialien, Hersteller, Prüfnummer usw. Die DDL gibt dem Host-System oder der Host-Anwendung vor, wie die Informationen in der DD für das Gerät zu übermitteln, zu decodieren und anzuzeigen sind.
  • Die DDs für verschiedene Geräte werden typischerweise auf mehrere verschiedene Arten verwendet. Wenn beispielsweise eine Prozessanwendung oder eine Host-Anwendung in einer Prozessanlage implementiert wird, kann es sein, dass das Wartungspersonal, das für die Wartung der Prozessanwendung zuständig ist, Hilfeinformationen zu verschiedenen Parametern verschiedener Geräte benötigt. Ebenso können System-Designer, die eine Prozessanwendung schreiben, eine DD verwenden, um weitere Informationen über ein Gerät zu erlangen. Gerätehersteller stellen DDs im Allgemeinen auf einem computerlesbaren Medium bereit, so dass diese DDs leicht in verschiedene Computer eines Prozesssteuerungssystems oder in verschiedene zu einer Prozessanlage gehörende Anwendungen kopiert werden können. Genauer gesagt stellen Gerätehersteller typischerweise eine DD für jedes von ihnen hergestellte Gerät bereit, die in DDL die mit dem Gerät assoziierten Parameter, die Art und Weise, wie mit dem Gerät zu kommunizieren ist, Beschränkungen für das Gerät, usw. definiert.
  • Auf DDL basierende Hosts können die DD für ein Gerät in DDL lesen und interpretieren, um die Art des Geräts und die mit dem Gerät assoziierten wichtigen Parameter, Beschränkungen usw. zu bestimmen, deren Sichtbarkeit für den Benutzer nach Meinung eines DD-Entwicklers (z.B. eines Geräteherstellers, einer Protokoll-Foundation) wichtig ist. Von daher werden die DDL-Konstrukte (wie Variablen, Verfahren, Befehle, Menüs und Anzeigeformate, wie Bilder, Graphen, Raster, Wellenformen und Diagramme) vom DDL-basierten Host oder der Host-Anwendung interpretiert und dem Benutzer angezeigt. Der DDL-basierte Host kann die mit dem Gerät assoziierten Parameter, Beschränkungen usw. als die inhärenten Eigenschaften oder Parameter des grafischen Elements für das Gerät definieren. Der DDL-basierte Host kann auch Programme aufweisen, um Visualisierungen für das Gerät auszuwählen oder zu definieren, und kann ein oder mehrere generische Skripts auswählen, die zur Bereitstellung grundlegender Aktionen und Animationen für das Gerät verwendet werden können, entweder auf Basis von Informationen aus der DD oder auf Basis von Templates, die für den von der DD für das Gerät definierten Gerätetyp gespeichert sind. Ressourcen-Dateien können auch verwendet werden, um die DDL-Informationen in eine Anzeige umzuwandeln. Jedoch werden die Ressourcen-Dateien typischerweise vom DD-Entwickler entworfen, und in einem solchen Fall ist die Anzeige, auch wenn sie in gewissem Umfang konfigurierbar ist, um Visualisierungen und Animationen für das Gerät zu definieren, im Allgemeinen statisch im Hinblick auf die Anzeige von Informationen, und der Benutzer ist daran gebunden, die Informationen zu betrachten, die von der Ressourcen-Datei des Entwicklers spezifiziert werden. Von daher kann nicht der Benutzer bestimmen, welche Informationen er betrachtet und/oder in welcher Art und Weise er die Informationen betrachtet. Was die grafische Benutzeroberfläche für das Gerät betrifft, die von der DD spezifiziert wird, so kann es sein, dass sich der Benutzer durch zahlreiche Menüs hangeln muss, um die Informationen zu finden, die der Benutzer als wichtig erachtet.
  • KURZFASSUNG
  • Ein System und Verfahren zum Konfigurieren eines Device Description Language(DDL)-Menüs ermöglicht einem Benutzer das Konfigurieren und Behalten von DDL-Menüs, um Informationen zu betrachten, die der Benutzer für wichtig hält, statt Informationen betrachten zu müssen, die auf Ressourcen-Dateien basieren, die vom Entwickler der Gerätebeschreibung bereitgestellt werden. Der Benutzer ist in der Lage, Prozessgeräte auszuwählen und Menüelemente auszuwählen, die diesen Prozessgeräten zugeordnet sind, um sie zum DDL-Menü hinzuzufügen, einschließlich von Menüelementen aus anderen Gerätebeschreibungen für andere Prozessgeräte, auch wenn die Gerätebeschreibungen von anderen Entwicklern (z.B. anderen Prozessgeräteherstellern) kommen. Die Menüs können auf einem DDL-Host gespeichert und vom Benutzer nach Bedarf aktiviert werden, um die Informationen auf dem Menü zu betrachten. Ein Benutzer ist auch in der Lage, das Menü mit neuen Menüelementen zu rekonfigurieren.
  • Das hierin offenbarte System und Verfahren versieht einen DDL-Host mit einer aktualisierten Gerätebeschreibung für ein Prozesssteuergerät nach Wahl des Benutzers. Die Gerätebeschreibung schließt unter anderem Menüs und/oder Anzeigeformate ein für die Betrachtung von Informationen über das Prozesssteuergerät. DDL-Menükonstrukte aus der Gerätebeschreibung werden aus der Gerätebeschreibung heraus offengelegt und auf einer Konfigurationsoberfläche angezeigt, so dass der Benutzer in der Lage ist, DDL-Menükonstrukte, die für den Benutzer wichtig sind, auszuwählen. Der Benutzer kann dann die DDL-Menükonstrukte zum DDL-Menü hinzufügen und konfigurieren, um das DDL-Menü gemäß den Präferenzen des Benutzers zu konfigurieren. Die DDL-Menüs werden auf die verschiedenen DDL-Menükonstrukte gemappt, an deren Betrachtung der Benutzer ein Interesse hat. Das DDL-Menü wird vom DDL-Host bewahrt, so dass der Benutzer DDL-Menüs nach Bedarf aktivieren oder deaktivieren kann und das DDL-Menü durch Hinzufügen neuer DDL-Menükonstrukte, Modifizieren von DDL-Menükonstrukten innerhalb des DDL-Menüs oder durch Löschen von DDL-Menükonstrukten aus dem DDL-Menü rekonfigurieren kann.
  • Figurenliste
    • 1 ist eine kombinierte Block- und Prinzipdarstellung eines verteilten Prozesssteuerungssystems gemäß dieser Offenbarung.
    • 2 ist eine Blockdarstellung eines DDL-basierten Host-Systems eines verteilten Prozesssteuerungssystems, das über das Internet mit verschiedenen Datenbanken vernetzt ist, gemäß dieser Offenbarung;
    • 3 ist ein Ablaufschema eines Beispiels für eine Konfigurationsroutine für eine grafische DDL-Benutzeroberfläche zum Konfigurieren einer neuen grafischen DDL-Benutzeroberfläche, die von einem DDL-basierten Host bewahrt wird, gemäß dieser Offenbarung;
    • 4 ist ein Beispiel für eine grafische Benutzeroberfläche zum Erzeugen einer grafischen DDL-Benutzeroberfläche gemäß dieser Offenbarung;
    • 5 ist ein Beispiel für eine grafische Benutzeroberfläche zum Auswählen von Geräten zur Erzeugung einer grafischen DDL-Benutzeroberfläche gemäß dieser Offenbarung;
    • 6 ist ein Ablaufschema eines Beispiels für eine Gerätebeschreibungsabrufroutine zum Abrufen von Gerätebeschreibungen eines ausgewählten Geräts gemäß dieser Offenbarung;
    • 7 ist ein Beispiel für eine grafische Benutzeroberfläche, auf der eine grafische DDL-Benutzeroberfläche gemäß dieser Offenbarung erzeugt und konfiguriert werden kann;
    • 8 ist ein Beispiel für ein Sequenzdiagramm, das die Interaktionen zwischen Prozessen bei der Erzeugung eines benutzerdefinierten Gerätebeschreibungsmenüs zeigt, das von einem DDL-basierten Host-System bewahrt wird, gemäß dieser Offenbarung;
    • 9 ist ein Beispiel für eine grafische Benutzeroberfläche, die ein benutzerdefiniertes Gerätebeschreibungsmenü zeigt;
    • 10 ist ein Ablaufschema für ein Beispiel für eine Menü-Aktivierungsroutine zum Aktivieren einer grafischen DDL-Benutzeroberfläche gemäß dieser Offenbarung;
    • 11 ist ein Ablaufschema eines Beispiels für eine Gerätebeschreibungsmenü-Bearbeitungsroutine zum Bearbeiten einer vorhandenen grafischen DDL-Benutzeroberfläche gemäß dieser Offenbarung;
    • 12 ist ein Ablaufschema eines Beispiels für eine Geräte-Hinzufügungsroutine zum Hinzufügen von DDL-Menükonstrukten für ein neues Gerät zu einer vorhandenen grafischen DDL-Benutzeroberfläche gemäß dieser Offenbarung;
    • 13 ist ein Ablaufschema eines Beispiels für eine DDL-Menü-Modifizierungsroutine zum Modifizieren von Menükonstrukten in der grafischen DDL-Benutzeroberfläche gemäß dieser Offenbarung;
    • 14 ist ein Ablaufschema eines Beispiels für eine Menükonstrukt-Löschungsroutine zum Löschen von DDL-Menükonstrukten von der grafischen DDL-Benutzeroberfläche gemäß dieser Offenbarung;
    • 15 ist ein Ablaufschema eines Beispiels für eine DDL-Menükonstrukt-Hinzufügungsroutine zum Hinzufügen von DDL-Menükonstrukten zu der grafischen DDL-Benutzeroberfläche gemäß dieser Offenbarung; und
    • 16 ist ein Ablaufschema eines Beispiels für eine DDL-Menükonstrukt-Modifizierungsroutine zum Modifizieren von DDL-Menükonstrukten in der grafischen DDL-Benutzeroberfläche gemäß dieser Offenbarung;
  • AUSFÜHRLICHE BESCHREIBUNG
  • Wie in 1 dargestellt ist, schließt ein kabelgebundenes verteiltes Prozesssteuerungssystem 10 eine oder mehrere Prozesssteuereinrichtungen 12 ein, die mit einer oder mehreren Host-Workstations oder -Computern 14 verbunden sind (bei denen es sich um jede Art von Personal Computer oder Workstation handeln kann). Die Prozesssteuereinrichtungen 12 sind auch mit Bänken von Eingabe/Ausgabe(I/O)-Geräten 20, 22 verbunden, von denen jedes seinerseits mit einem oder mehreren Feldgeräten 25-39 verbunden ist. Die Steuereinrichtungen 12, die, nur als Beispiel, von Fisher-Rosemount Systems, Inc. verkaufte DeltaV™-Steuereinrichtungen sein können, sind kommunikationstechnisch beispielsweise über eine Ethernet-Verbindung 40 oder einen anderen Kommunikations-Link mit den Host-Computern 14 verbunden. Ebenso sind die Steuereinrichtungen 12 kommunikationstechnisch unter Verwendung von beliebiger Hardware und Software, die beispielsweise mit 4-20 mA-Standardgeräten assoziiert ist, und/oder eines beliebigen intelligenten Kommunikationsprotokolls wie der Fieldbus- oder HART-Protokolle mit den Feldgeräten 25-39 verbunden Wie allgemein bekannt ist, implementieren oder überwachen die Steuereinrichtungen 12 Prozesssteuerroutinen, die in ihnen gespeichert oder auf andere Weise mit ihnen assoziiert sind, und kommunizieren mit den Geräten 25-39, um einen Prozess auf jede gewünschte Weise zu steuern.
  • Die Feldgeräte 25-39 können zu jeder Art von Geräten, beispielsweise Sensoren, Ventilen, Sendern, Stellungsgebern usw. gehören, während die I/O-Karten innerhalb der Bänke 20 und 22 zu jeder Art von I/O-Geräten gehören können, die für jedes gewünschte Kommunikations- oder Steuerungsprotokoll wie HART, Fieldbus, Profibus usw. geeignet sein können. In der in 1 dargestellten Ausführungsform sind die Feldgeräte 25-27 4-20 mA-Standardgeräte, die über analoge Leitungen mit der I/O-Karte 22A kommunizieren. Die Feldgeräte 28-31 sind als HART-Geräte dargestellt, die mit einem HART-kompatiblen I/O-Gerät 20A verbunden sind. Ebenso sind die Feldgeräte 32-39 intelligente Geräte, wie Fieldbus-Feldgeräte, die über einen digitalen Bus 42 oder 44 beispielsweise unter Verwendung von Fieldbus-Protokollkommunikation mit den I/O-Karten 20B oder 22B kommunizieren. Natürlich könnten die Feldgeräte 25-39 und die Bänke aus I/O-Karten 20 und 22 außer den 4-20 mA-, HART- oder Fieldbus-Protokollen auch jedem anderen gewünschten Standard oder Protokoll entsprechen, einschließlich etwaiger Standards oder Protokolle, die in der Zukunft entwickelt werden.
  • Jede von den Steuereinrichtungen 12 ist so konfiguriert, dass sie eine Steuerungsstrategie unter Verwendung dessen implementiert, was allgemein als Funktionsblöcke bezeichnet wird, wobei jeder Funktionsblock ein Teil (z.B. eine Subroutine) einer Gesamt-Steuerroutine ist und (über Kommunikationsverbindungen, die als Links bezeichnet werden) in Verbindung mit anderen Funktionsblöcken operiert, um Prozesssteuerschleifen innerhalb des Prozesssteuerungssystems 10 zu implementieren. Von Funktionsblöcken werden in der Regel eine Eingabefunktion, beispielsweise eine solche, die mit einem Sender, einem Sensor oder einem anderen Prozessparametermessgerät assoziiert ist, eine Steuerfunktion, beispielsweise eine solche, die mit einer Steuerroutine assoziiert ist, die eine PID-, Fuzzy-Logik- oder ähnlichen Steuerung durchführt, oder eine Ausgabefunktion, die den Betrieb irgendeines Gerätes, beispielsweise eines Ventils steuert, um gewisse physische Funktionen innerhalb des Prozesssteuerungssystems 10 auszuführen, ausgeführt. Natürlich existieren hybride und andere Arten von Funktionsblöcken. Gruppen dieser Funktionsblöcke werden als Module bezeichnet. Funktionsblöcke und Module können in der Steuereinrichtung 12 gespeichert und von dieser ausgeführt werden, was typischerweise der Fall ist, wenn diese Funktionsblöcke mit 4-20 mA-Standardgeräten und manchen Arten von intelligenten Feldgeräten verwendet werden oder assoziiert sind, oder sie können von den Feldgeräten selbst gespeichert oder implementiert werden, wie es mit Fieldbus-Geräten der Fall sein kann. Auch wenn beschrieben wird, dass das in 1 dargestellte Steuerungssystem 10 eine Funktionsblocksteuerungsstrategie verwendet, könnte die Steuerungsstrategie auch unter Verwendung anderer Konventionen wie Ladder-Kontaktplänen, sequenziellen Ablaufdiagrammen usw. und unter Verwendung beliebiger proprietärer und nicht-proprietärer Programmierungssprachen implementiert oder entworfen werden.
  • Darüber hinaus kann mindestens eine der Workstations 14 Benutzeroberflächenanwendungen einschließen, um einen Benutzer, beispielsweise einen Bediener, einen Konfigurationsingenieur, Wartungspersonal usw. in die Lage zu versetzen, sich mit dem Prozesssteuerungsnetz innerhalb der Anlage zu verbinden. Genauer gesagt kann die Workstation 14 eine oder mehrere Benutzeroberflächenanwendungen einschließen, die an einem Prozessor innerhalb der Workstation 14 ausgeführt werden können, um mit einer Datenbank, den Steuermodulen oder anderen Routinen innerhalb der Steuereinrichtungen 12 oder I/O-Bänke 20, 22, mit den Feldgeräten 25-39 und den Modulen innerhalb dieser Feldgeräte usw. zu kommunizieren, um Informationen von der Anlage zu erhalten, beispielsweise Informationen in Bezug auf den aktuellen Status des Prozesssteuerungssystems 10. Die Benutzeroberflächenanwendungen können diese gesammelten Informationen verarbeiten und/oder auf einem Anzeigegerät, das mit einer oder mehreren von den Workstations 14 assoziiert ist, anzeigen. Die gesammelten, verarbeiteten und/oder angezeigten Informationen können beispielsweise Prozessstatusinformationen, Alarme und Warnungen, die innerhalb der Anlage erzeugt werden, Wartungsdaten usw. sein. Ebenso kann eine oder können mehrere Anwendungen von den Workstations 14 gespeichert und ausgeführt werden, um Konfigurierungsaktivitäten durchzuführen, wie die Erzeugung oder Konfigurierung der Module, die innerhalb der Anlage ausgeführt werden sollen, um Steuerungsbedieneraktivitäten durchzuführen, wie das Ändern von Sollwerten oder anderer Steuerungsvariablen innerhalb der Anlage usw. Natürlich werden die Anzahl und der Typ der Routinen nicht durch die hierin angegebene Beschreibung beschränkt, und es können auch eine andere Anzahl und andere Arten von mit Prozesssteuerung in Zusammenhang stehenden Routinen von den Workstations 14 gespeichert und ausgeführt werden, falls gewünscht. Die Workstations 14 können beispielsweise auch über das Internet, ein Extranet, einen Bus, das Ethernet 40 usw. mit einem Corporate-WAN ebenso wie mit einem Computersystem verbunden sein, wodurch eine Fernüberwachung oder -kommunikation mit der Anlage 10 von entfernten Orten aus möglich ist.
  • Wie aus der Erörterung von 1 hervorgeht, wird die Kommunikation zwischen den Workstations 14 und den Steuereinrichtungen 12 und zwischen den Steuereinrichtungen 12 und den Feldgeräten 25-39 mit kabelgebundenen Kommunikationsverbindungen implementiert, einschließlich von einer oder mehreren HART-, Fieldbus- oder kabelgebundenen 4-20 mA-Kommunikationsverbindungen. Wie oben angegeben, können die kabelgebundenen Kommunikationsverbindungen innerhalb der Prozessumgebung von 1 jedoch durch drahtlose Kommunikationseinrichtungen auf eine Weise ersetzt werden, die zuverlässig ist, die leicht einzurichten und zu konfigurieren ist, die einen Bediener oder einen anderen Benutzer in die Lage versetzt, die Funktionsfähigkeit des drahtlosen Netzwerks zu analysieren oder zu betrachten, usw.
  • Zum Beispiel können drahtlose Netzwerke überall im Prozesssteuerungssystem eingesetzt werden. Infolgedessen können manche oder alle von den I/O-Geräten innerhalb eines Prozesssteuerungssystems, beispielsweise Sensoren und Stellantriebe, unter Verwendung von kabelgebundenen Techniken, drahtlosen Techniken oder Kombinationen davon eingesetzt und kommunikationstechnisch mit dem Prozesssteuerungssystem verbunden werden. Zum Beispiel kann eine kabelgebundene Kommunikation zwischen manchen der Steuereinrichtungen 12, den Workstations 14 und den Feldgeräten 25-31 beibehalten werden, während zwischen anderen von den Steuereinrichtungen 12, den Workstations 14 und den Feldgeräten 32-39 eine drahtlose Kommunikation eingerichtet werden kann. Drahtlose Technologien können unter anderem ZigBee, WiFi, Bluetooth, Ultra Wideband (UWB) usw. oder irgendeine andere drahtlose Technologie mit kurzer Reichweite ebenso wie Satelliten-, Wi-Max- und andere drahtlose Übertragungen einschließen. Genauer gesagt können drahtlose Technologien jedes im Handel erhältliche serienmäßige Produkt einschließen, mit dem Steuerdaten versendet werden können. Ein Netzwerkprotokoll kann über der drahtlosen Technologie implementiert werden, oder ein neuer Prozesssteuerungsstandard kann für die drahtlose Kommunikation entwickelt werden.
  • Wie in 2 dargestellt ist, kann ein DDL-basiertes Host-System 50, das Teil des Prozesssteuerungssystems 10 und genauer gesagt einer Workstation 14 sein kann, eine Anzahl von Host-Anwendungen einschließen, um das Prozesssteuerungssystem 10 und insbesondere die Feldgeräte 25-39 zu überwachen und zu betreiben. Zum Beispiel kann das Host-System 50 Host-Anwendungen für die Prozesssteuerung, Simulierung, Wartung, Diagnose, Konfiguration usw. einschließen. Das Host-System 50 (oder jede Host-Anwendung) kann auch eine lokale Bibliothek oder Datenbank 52 aufweisen, in der die Gerätebeschreibung (DD) von einem oder mehreren der Feldgeräte 25-39 gespeichert ist. Wie in 2 dargestellt ist, ist das Host-System 50 mit dem Internet 54 verbunden, und dies kann entweder eine direkte Verbindung oder eine indirekte Verbindung (z.B. über das Ethernet 40) sein. In einer alternativen Ausführungsform kann das Internet 54 vollständig oder zum Teil durch ein Corporate-WAN ersetzt sein.
  • Wie in 2 dargestellt ist, ist das Host-System 50 kommunikationstechnisch über das Internet 54 mit einer Anzahl von Datenbanken oder Systemen verbunden, von denen jede(s) mit dem Prozesssteuerungssystem 10 kommunizieren kann. Zum Beispiel kann ein Management-Informationssystem 56 verschiedene Informationen aus dem Prozesssteuerungssystem 10 sammeln, unter anderem Einsatz, Produktion usw. Verschiedene DD-Datenbanken, wie eine HART-Communication-Foundation-Datenbank 58, eine FOUNDATION-Fieldbus-Datenbank 60, eine PROFIBUS(Process Field Bus)-Datenbank 62, eine Geräteherstellerdatenbank, wie eine Emerson-Process-Management-Datenbank 64 usw., können ebenfalls über das Internet 54 kommunikationstechnisch mit dem Host-System 50 verbunden sein. Die Datenbanken 56, 58, 60, 62, 64 können Informationen über verschiedene Geräte enthalten, die im Prozesssteuerungssystem 10 verwendet werden, einschließlich von Gerätebeschreibungen für die Geräte. Zum Beispiel kann die HART-Communication-Foundation-Datenbank 58 Gerätebeschreibungen für verschiedene HART-Geräte enthalten, die im Prozesssteuerungssystem 10 verwendet werden, die FOUNDATION-Fieldbus-Datenbank 60 kann Gerätebeschreibungen für verschiedene Fieldbus-Geräte enthalten, die im Prozesssteuerungssystem 10 verwendet werden, und die PROFIBUS-Datenbank 62 kann Gerätebeschreibungen für verschiedene PROFIBUS-Geräte enthalten, die im Prozesssteuerungssystem 10 verwendet werden. Die Gerätebeschreibungen können auch in verschiedenen Datenbanken, die von verschiedenen Herstellern bereitgestellt werden, beispielsweise in der Emerson-Process-Management-Datenbank 64, für verschiedene Geräte von diesem Gerätehersteller, die im Prozesssteuerungssystem 10 verwendet werden, gespeichert sein.
  • Wie oben angegeben, ist eine Gerätebeschreibung eine formale Beschreibung der Daten und Betriebsabläufe für eine Art von Feldgerät, einschließlich von Variablen, Daten (Parametern), Kommunikation (Adressinformationen), Verfahren, Befehlen/Operationen (z.B. Kalibrierung) und grafischen Benutzeroberflächen (z.B. Menüs und Anzeigeformaten), die mit verschiedenen Merkmalen des Geräts assoziiert sind, und wird in der bekannten und gut unterstützten Device Description Language (DDL) vom Gerätehersteller oder DD-Entwickler geschrieben. Zum Beispiel spezifiziert der Standard IEC 61804-3:2010(E) der Internationalen Elektrotechnischen Kommission (IEC) die Electronic Device Description Language (EDDL) als generische Sprache zur Beschreibung der Eigenschaften von Feldgeräten, wie Geräteparametern und Abhängigkeiten, Gerätefunktionen (z.B. Simulationsmodus, Kalibrierung usw.), grafischen Darstellungen (z.B. Menüs, verbesserten Benutzeroberflächen usw.), Interaktionen mit Steuergeräten, Grafikerstellungssystemen und persistentem Datenspeicher. Typischerweise wird die Gerätebeschreibung als elektronische Datendatei bereitgestellt, beispielsweise als Textdatei mit einer „DDL“-Erweiterung, die gemäß der Device Description Language-Spezifikation erstellt worden ist, in der die spezifischen Merkmale und Funktionen des Geräts beschrieben sind, einschließlich von Details zu Menüs und Merkmalen grafischer Anzeigen, die von dem DDL-basierten Host-System 50 zu verwenden sind, um auf sämtliche Parameter und Daten in den entsprechenden Feldgeräten zugreifen zu können. Im Allgemeinen ist die Gerätebeschreibung eine Reihe von zusammengesetzten Ausdrücken, die das Format eines kennzeichnenden Wortes und eines Namens verwendet, und schließt jede für einen Zugriff offenstehende Variable für ein Gerät ein, wie Prozessmesswerte, abgeleitete Werte und interne Parameter wie einen Bereich, Sensortyp, verwendete Materialien usw. Zum Beispiel schließen Ausdrücke für die Gerätebeschreibung im Allgemeinen unter anderem VARIABLEs, MENUs, COMMANDs und METHODs ein, von denen jeder seine eigenen strukturierten Informationen aufweist.
  • VARIABLE kann jeder Wert oder Datentyp (z.B. eine ganze Zahl, ein Fließkomma, ein alphanumerisches Zeichen usw.) sein, der in dem Feldgerät enthalten ist oder vom Host-System 50 verwendet wird, um mit dem Feldgerät zu interagieren (z.B. ein Druck in einem Druckgeber, eine obere und eine untere Bereichsgrenze, ein Geräte-Tag usw.). Die strukturierten Informationen für VARIABLE können ferner die Art, wie VARIABLEs angezeigt werden soll (z.B. einen Variablennamen), assoziierte Geräte, Hilfedateien usw. spezifizieren. Für jeden COMMAND bzw. Befehl spezifiziert die Gerätebeschreibung die Datenstruktur für fast alles, was mit dem Befehl assoziiert ist (z.B. Abfrage, Antwort, Status, Antwortbedeutung usw.). Ein COMMAND-Ausdruck wird für jeden Befehl bereitgestellt, der von dem Gerät erkannt wird. METHOD ist ein Satz von Operationen, die der Host an dem Gerät durchzuführen hat (z.B. Installation, Kalibrierung, Befehle usw.). Ein Bediener kann METHOD beispielsweise durch eine MENU-Option aufrufen, die über den Host präsentiert wird, wobei der Satz von Operationen in der Reihenfolge ausgeführt wird, in der die Operationen geschrieben wurden. MENU ist eine Präsentation für den Endbenutzer. Sie kann verwendet werden, um dem Bediener VARIABLEs, Informationen oder anderen MENUs zu präsentieren.
  • Der DDL-basierte Host 50 schließt eine Konfigurationsoberfläche ein, die einen Endbenutzer in einer Prozessanlage, beispielsweise einen Bediener, in die Lage versetzt, eine grafische DDL-Benutzeroberfläche unter Verwendung von Informationen aus der DD für die einzelnen vom Benutzer ausgewählten Geräte zu konfigurieren, so dass der Host 50 individuell angepasste Menüs auf Basis von MENU-Konstrukten innerhalb der DD dynamisch erzeugen und bewahren kann. Genauer gesagt ermöglicht die Benutzeroberfläche dem Benutzer die Auswahl von DDL-Konstrukten für die individuell angepasste grafische DDL-Benutzeroberfläche durch Offenlegen der DDL-Konstrukte aus der DD gegenüber dem Host 50 und verständliches Erklären/Präsentieren der DDL-Konstrukte ebenso wie etwaiger Abhängigkeiten, die sich ergeben können. Ausgewählte DDL-Konstrukte, und genauer Menükonstrukte, können einer grafischen DDL-Benutzeroberfläche hinzugefügt werden, so dass die grafische DDL-Benutzeroberfläche auf die ausgewählten DDL-Konstrukte gemappt wird, wobei die konfigurierte grafische DDL-Benutzeroberfläche (das individuell angepasste Menü) gespeichert wird und jederzeit abgerufen werden kann. Die konfigurierte grafische DDL-Benutzeroberfläche kann vom Benutzer aktiviert werden, um Daten zu sehen, die über die grafische DDL-Benutzeroberfläche präsentiert werden, die verborgen werden, die mit neuen oder zusätzlichen DDL-Konstrukten rekonfiguriert werden, die mit DDL-Konstrukten für ein neues oder zusätzliches Gerät (z.B. zusätzliche DDs) rekonfiguriert werden, die durch Modifizieren vorhandener DDL-Konstrukte innerhalb der grafischen DDL-Benutzeroberfläche rekonfiguriert werden, usw. Somit kann der Benutzer Menüs auf Basis von Informationen, die für den Benutzer die größte Bedeutung haben, individuell anpassen, und ist an vom Hersteller entworfene oder vom DD-Entwickler entworfene Menüs gebunden. Der DDL-basierte Host 50 bewahrt die Integrität der DDL-Konstruktinformationen und gibt Befehle aus, die nötig sind, um die Datenwerte der DDL-Konstrukte zu erfassen.
  • Allgemein gesprochen können die Konfigurierung, die Speicherung und das Abrufen von grafischen DDL-Benutzeroberflächen unter Verwendung von DDL-Konditionalen, FILE-Daten und LOCL-Variablen bewerkstelligt werden. Wie in der Industrie bekannt ist, beinhalten DDL-Konditionale Child-Objekte, die von einer Variablen abhängen. Angesichts dessen, dass interne Abhängigkeiten, beispielsweise Abhängigkeiten zwischen Variablen oder Parametern, komplex sein können, ist der DDL-Konditional eine Logik, die diese Abhängigkeiten bewältigt. Genauer gesagt ermöglicht die Verwendung von DDL-Konditionalen der Konfigurationsoberfläche nicht nur das Anzeigen von DDL-Konstrukten, die zur Auswahl oder Eingabe zur Verfügung stehen, sondern auch von etwaigen Abhängigkeiten, die sich beim Auswählen eines Konstrukts oder bei der Vornahme einer Eingabe ergeben könnten. Auf ähnliche Weise können die DDL-Konditionale bewirken, dass die Konfigurationsoberfläche DDL-Konstrukte „verbirgt“, die für das ausgewählte Konstrukt oder die Eingabe nicht relevant sind. Die Verwendung des Ausdrucks „verbergen“ soll, wie allgemein verständlich ist, entweder das Verbergen der DDL-Konstrukte, so dass sie nicht sichtbar sind, das Nichtzulassen der Auswahl der DDL-Konstrukte oder einer Eingabe (zum Beispiel das Ausgrauen von Menükonstrukten) bedeuten. Wenn der Benutzer zum Beispiel einen Geräteparameter (z.B. die Temperatur) auswählt, kann die Konfigurationsoberfläche alle Informationen, Symbole, Variablen usw., die mit dem Parameter nichts zu tun haben, „verbergen“ und nur die DDL-Konstrukte, die für diese Auswahl relevant sind (z.B. Temperatureinstellungen, Temperatureinheitsoptionen usw.) übriglassen. Von daher bewirken DDL-Konditionale, dass die Konfigurationsoberfläche nur DDL-Konstrukte bereitstellt, die für das zuvor ausgewählte DDL-Konstrukt zulässig oder relevant sind, und die Verwendung des zuvor ausgewählten DDL-Konstrukts in der grafischen DDL-Benutzeroberfläche kann die Auswahl eines oder mehrerer von diesen DDL-Konstrukten zur Bedingung haben. Angesichts der manchmal riesigen Anzahl von DDL-Konstrukten und Abhängigkeiten können diese DDL-Konditionale auch genutzt werden, um den Benutzer bei der Konfigurierung eines Menüs zu unterstützen, .
  • Die Präferenzen des Benutzers für die vom Benutzer konfigurierte grafische DDL-Benutzeroberfläche (z.B. ausgewählte DDL-Menükonstrukte, Werte usw.) können als DDL-Dateidatenstruktur gespeichert werden, die als FILE-Daten bezeichnet wird, wo die Werte bestimmter Variablen in der Benutzerdatenbank gespeichert werden können. Diese Variablen werden als LOCAL-Variablen bezeichnet und ihre Werte müssen nicht in der Geräte-Firmware gespeichert werden, anders als bei anderen DDL-Variablen (d.h. Gerätevariablenwerten), die in der Geräte-Firmware gespeichert werden. Durch das Speichern der Präferenzen als FILE-Daten muss für grafische DDL-Benutzeroberflächen die vorhandene Firmware nicht geändert werden, da die FILE-Dateien keine zusätzlichen Arbeiten an dem Gerät an sich erfordern. Das heißt, die Konfiguration einer grafischen DDL-Benutzeroberfläche wird außerhalb des Geräts am DDL-basierten Host 50 in der DDL vorgenommen. Zu diesem Zweck werden die LOCAL-Variablen nicht in dem Gerät gespeichert, sondern werden stattdessen als DDL FILE-Daten gespeichert. Die DDL FILE-Daten wirken somit als lokale Ressourcen-Datei, welche die grafische DDL-Benutzeroberfläche auf die DDL-Menükonstrukte mappt, die der grafischen DDL-Benutzeroberfläche hinzugefügt werden. Wenn die grafische DDL-Benutzeroberfläche aktiviert wird, nutzt der DDL-basierte Host (oder die DDL-basierte Host-Anwendung) die FILE-Daten, um die DDL-Informationen (z.B. die DDL-Menükonstrukte, Variablenwerte usw.) in eine Anzeige umzuwandeln.
  • Im Folgenden wird ein Beispiel für einen partiellen Pseudocode einer DDL für eine grafische DDL-Benutzeroberfläche, die FILE-Daten nutzt, bereitgestellt, einschließlich einer Variablen und eines Menüs zur Betrachtung der Variablen:
              FILE user_configuration
              {
              configure_param1 //Benutzereinstellungen in der
       Benutzerdatenbank gespeichert
              configure_param2
              configure_param3
              }
              MENU process_variables_root_menu
              {
              LABEL „Process Variables“; // Titel des Bildschirms
       (Gruppenfelder, Seiten) kann benutzerdefinierbar sein
              STYLE WINDOW;
              ITEMS
              { switch( configure_param1 ) // Benutzereinstellungen
       werden verwendet, um das
                    { Bildschirmlayout zu bestimmen
                           case 0:
                           gauge_showing_pressure
                           break;
                        case 1:
                           sweep_chart_plotting_pressure
                           break;
                        default:
                           pressure_value_as_text,
                           COLUMNBREAK,
                           pressure_upper_range_value,
                           COLUMNBREAK,
                           pressure_lower_range_value
                           break;
              } } }

             VARIABLE configure_param1

              {
              LABEL „Process Variables First Item“
              CLASS LOCAL;
              DEFAULT 0;
              TYPE ENUMERATION;
              ITEMS
                 {
                 0, „Gauge of PV“;
                 1, „Sweep Chart of PV“;
                 2, „PV as Text“
                 }
  • In dem } oben angegebenen Beispiel können vom Benutzer konfigurierte Menüpräferenzen (configure_param1, configure_param2 und configure_param3) definiert und lokal als FILE-Daten (user_configuration) in der Benutzerdatenbank gespeichert werden, beispielsweise im DDL-basierten Host 50. Die Verwendung des FILE-Ausdrucks in der DDL ruft die Menüpräferenzen, wenn die DDL beispielsweise von der Workstation 14 verwendet wird, um die grafische DDL-Benutzeroberfläche anzuzeigen.
  • Der MENU-Ausdruck beschreibt die grafische Benutzeroberfläche (process_variables_root_menu), mit der eine Variable geholt werden soll, und implementiert eine Benutzereinstellung (configure_param1) wie oben angegeben, um das Layout der Oberfläche zu bestimmen. Dann werden die Details der Präferenzen für die grafische Benutzeroberfläche (z.B. Druckmesser, Druckdiagramm, Werte) definiert, wobei „switch“ eine Änderung gegenüber dem voreingestellten Menü signalisiert, das in der DD vom Hersteller oder DD-Entwickler bereitgestellt wurde. Im obigen Beispiel werden der Titel des Bildschirms und der Stil der Anzeige mit LABEL („Process Variables“) bzw. STYLE WINDOW spezifiziert. Das Bildschirmlayout wird dann anhand der Benutzerpräferenz (configure_param1) bestimmt. In diesem Beispiel definiert die Benutzerpräferenz (configure_param1), wie die Informationen (Druck) angezeigt werden sollen, was für dieselben Informationen in einem oder mehreren Formaten (z.B. Druckmesser, Diagramm, Text) (gauge_showing_pressure, sweep_chart_plotting_pressure, pressure_value_as_text) sein kann. Diese Formate sind Teil des DDL-MENU-Konstrukts der DD.
  • Wie oben angegeben, bezeichnen Konditionale die Verwendung von Child-Objekten, die von einer Variablen abhängen. Wenn der Benutzer beispielsweise die Anzeige so konfiguriert, dass eine Druckvariable überwacht wird, wird erwartet, dass der Druck zwischen oberen und unteren Grenzwerten gehalten wird, wobei ein Druckmesswert, der außerhalb dieser Grenzwerte liegt, eine Warnung oder einen Alarm auslöst. Somit kann bzw. können dadurch, dass die grafische Benutzeroberfläche so konfiguriert wird, dass sie die Variable Druck zeigt, der Konditional oder die Child-Objekte für die oberen und unteren Bereichswerte für den Druck hervorgebracht werden. Ein Benutzer ist in der Lage, die Variable (Druck) und andere Menükonstrukte, die mit der Variablen assoziiert sind (z.B. Messanzeige, Diagramm, Text), auszuwählen, und ihm werden automatisch Child-Objekte (z.B. andere Variablen) präsentiert, die von der Variablen abhängen (z.B. pressure_upper_range_value, pressure_lower_range_value), die zur grafischen Benutzeroberfläche hinzuzufügen sind. Die DDL-Konditionale können eine solche Auswahl auch zwingend erforderlich machen, so dass die Einbeziehung des Menükonstrukts (z.B. des Drucks) in die grafische Benutzeroberfläche die Auswahl eines weiteren Menükonstrukts (z.B. pressure_upper_range_value, pressure_lower_range_value) zur Bedingung hat.
  • Der VARIABLE-Ausdruck beschreibt die Variablendaten, die gemäß der im MENU-Ausdruck beschriebenen grafischen Benutzeroberfläche (process_variables_root_menu) anzuzeigen sind. Eine Variable kann jeder Wert oder Datentyp sein (z.B. eine Aufzählung, eine ganze Zahl, ein Fließkomma, ein alphanumerisches Zeichen usw.), der in dem Feldgerät enthalten ist oder vom Host-System 50 verwendet wird, um mit dem Feldgerät zu interagieren (z.B. ein Druck in einem Druckgeber, eine obere und eine untere Bereichsgrenze, ein Geräte-Tag usw.). Die strukturierten Informationen für eine Variable können ferner die Art und Weise, wie die Variable angezeigt wird, einen Anzeigenamen, assoziierte Geräte, Hilfedateien usw. spezifizieren. Im obigen Beispiel ist die Variable Druck ein Aufzählungswert (TYPE ENUMERATION) mit dem Anzeigenahmen „Process Variables First Item“. Das ITEMS-Attribut spezifiziert ausgewählte Elemente der DD, die dem Benutzer angezeigt werden („Gauge of PV“, „Sweep Chart of PV“, „PV as Text“).
  • Um eine grafische DDL-Benutzeroberfläche für ein spezifisches Gerät oder eine spezifische Gerätegruppe, wie eine Gerätefamilie oder eine logische Gerätegruppierung, wie eine Schleife, eine Einheit, ein Bereich usw., zu erzeugen, wird (werden) die DD(s) für das (die) Gerät(e) abgerufen, und alle DDL-Menükonstrukte innerhalb der DD werden offengelegt. 3 ist ein Ablaufschema einer Konfigurationsroutine 100 für eine grafische DDL-Benutzeroberfläche zum Konfigurieren einer neuen grafischen DDL-Benutzeroberfläche, die vom DDL-basierten Host 50 bewahrt wird. Wie in 3 dargestellt ist, bestimmt die Konfigurationsroutine 100 in Block 102, ob ein Befehl empfangen wurde, eine grafische DDL-Benutzeroberfläche für ein Gerät (oder eine Gruppe von Geräten) zu konfigurieren. 4 liefert ein Beispiel für eine grafische Benutzeroberfläche (GUI), aus der ein Benutzer die Option auswählen kann, eine grafische DDL-Benutzeroberfläche für ein Gerät oder eine Gruppe von Geräten zu erzeugen („Create User Defined Menue“). Wie in 4 gezeigt ist, kann die Option zur Erzeugung eines benutzerdefinierten Menüs über ein Geräteverwaltungswerkzeug bereitgestellt werden, beispielsweise den AMS® Device Manager, der als Teil der von Emerson Process Management™ verkauften AMS® Suite bereitgestellt wird. Wie in 4 gezeigt ist, kann die Option aus einem Dropdown-Menü in der GUI-Werkzeugleiste oder durch Auswählen des Geräts (der Geräte) ausgewählt werden, beispielsweise durch Rechtsklick auf den Namen oder das Symbol des Geräts (der Geräte), wodurch ein Menü mit der Option anzeigt wird, eine grafische DDL-Benutzeroberfläche für das Gerät (die Geräte) zu erzeugen. Sobald der Benutzer die Option zur Erzeugung einer grafischen DDL-Benutzeroberfläche ausgewählt hat, kann die GUI ein Fenster oder einen Frame anzeigen, wie in 5 gezeigt ist, um daraus die grafische DDL-Benutzeroberfläche zu konfigurieren. Das Fenster von 5 ist ein Beispiel für eine Anzeige für eine Konfigurationsoberfläche zur Erzeugung und Konfigurierung von grafischen DDL-Benutzeroberflächen, die dem Benutzer präsentiert werden kann, um bestimmte Geräte aus der Liste auszuwählen und die DDL-Konstrukte offenzulegen und das Menü für das (die) ausgewählte(n) Gerät(e) zu konfigurieren.
  • Nach dem Empfangen eines Befehls zum Konfigurieren einer grafischen DDL-Benutzeroberfläche im Block 102 bestimmt die Konfigurationsroutine 100 in Block 104, ob ein Gerät oder eine Gruppe von Geräten ausgewählt wurde. Ein Benutzer kann ein oder mehrere Geräte bzw. Devices aus der Liste von Geräten auswählen, die in der GUI präsentiert wird, beispielsweise Device1-Device6, wie in 4 gezeigt ist. Das (die) vom Benutzer ausgewählte(n) Gerät(e) können solche Geräte sein, die der Kontrolle/dem Zugriff des Benutzers unterliegen und/oder die in einer bestimmten physischen oder logischen Gruppe von Geräten enthalten sind. Wenn der Benutzer beispielsweise ein Bediener ist, kann dem Benutzer eine Liste solcher Geräte präsentiert werden, zu deren Überwachung und/oder Kontrolle bzw. Steuerung der Benutzer berechtigt ist. Alternativ oder zusätzlich dazu kann die Liste der Geräte, die dem Benutzer präsentiert wird, aus solchen bestehen, die in einer physischen und/oder logischen Gruppe enthalten sind, beispielsweise in einer Schleife, einer Einheit, einem Bereich usw. Wie in 4 gezeigt ist, sind Device1-Device6 beispielsweise alle Geräte für einen bestimmten Ausrüstungsgegenstand.
  • Der Benutzer kann Geräte beispielsweise durch Ziehen des Symbols, durch welches das in der Liste präsentierte Gerät darstellt wird, in das in 5 gezeigte Konfigurationsfenster (d.h. durch Drag-and-Drop) auswählen. Alternativ dazu kann das (können die) ausgewählte(n) Gerät(e) dem Konfigurationsfenster automatisch hinzugefügt werden, wenn der Benutzer durch Auswählen des Geräts (der Geräte) die Option auswählt, eine grafische DDL-Benutzeroberfläche zu erzeugen (z.B. durch Rechtsklick auf das Gerätesymbol). Die Konfigurationsroutine 100 kann nach einer vorgegebenen Zeitspanne automatisch enden (Timeout) (Block 106).
  • Sobald ein oder mehrere Geräte ausgewählt wurden, ruft die Konfigurationsroutine 100 in Block 108 die DD für das (die) ausgewählte(n) Gerät(e) ab. Die DD für ein Gerät kann, falls sie zuvor von dem Gerät selbst bereitgestellt wurde, aus der DD-Bibliothek 52 des DDL-basierten Hosts 50 abgerufen werden, oder aus dem Management-Informationssystem 56, aus einer der verschiedenen DD-Datenbanken 58, 60, 62 oder aus der Geräteherstellerdatenbank 64 abgerufen werden. 6 ist ein Beispiel für eine DD-Abrufroutine 200 zum Abrufen von Gerätebeschreibungen eines in Block 108 von 3 ausgewählten Geräts. Beginnend mit Block 202 verbindet sich der DDL-basierte Host 50 mit dem Gerät und fragt unter Verwendung eines bekannten Befehls eine DD-Identifikation für das Gerät ab. Die DD-Identifikationsabfrage kann in dem Protokoll spezifiziert sein, das für die Kommunikation mit dem Gerät verwendet wird. Wenn beispielsweise das HART-Protokoll verwendet wird, kann ein Befehl #0 an das Gerät gesendet werden, um die DD-Identifikation für dieses Gerät abzufragen. Die Abfrage an das Gerät kann vom DDL-basierten Host 50 über den Kommunikations-Link 40 oder über irgendeinen anderen Kommunikations-Link zwischen dem DDL-basierten Host 50 und dem Gerät gesendet werden.
  • Im Block 204 wird als Reaktion auf die vom Block 202 gesendete Abfrage die DD-Identifikation von dem Gerät empfangen, und die empfangene DD-Identifikation für das Gerät wird im Speicher gespeichert. Bekanntlich kann die von dem Gerät bereitgestellte DD-Identifikation Informationen wie eine Hersteller-ID, eine Gerätekennung, eine Geräteprüfnummer usw. für das Gerät enthalten. Im Block 206 bestimmt die DD-Abrufroutine 200, ob der DDL-basierte Host 50 (oder die DDL-basierte Host-Anwendung) die DD für das Gerät hat, unter Verwendung der Geräteinformationen innerhalb der empfangenen DD-Identifikation. Zum Beispiel kann der Block 206 eine Suche in der lokalen DD-Bibliothek 52 oder der Host-Anwendung am DDL-basierten Host 50 nach der von der DD-Identifikation des Geräts identifizierten DD beinhalten.
  • Wenn bestimmt wird, dass der DDL-basierte Host 50 die DD für das Gerät nicht hat, identifiziert die DD-Abrufroutine 200 in Block 208 eine DD-Datenbank, beispielsweise die mit dem Internet 54 verbundene HART-Datenbank 58, welche die DD für das Gerät hat, und sendet eine Abfrage an die Datenbank, um die DD für das Gerät zu erhalten. DD-Datenbanken können durch Senden einer Abfrage über das Internet 54 und Analysieren von Antworten auf eine solche Abfrage identifiziert werden. Natürlich können die Internetadressen in Frage kommender oder bekannter DD-Datenbanken, wie der HART-Datenbank 58, der FOUNDATION-Fieldbus-Datenbank 60, der PROFIBUS-Datenbank 62 oder einer oder mehrerer Herstellerdatenbanken 64 usw. vom DDL-basierten Host 50 gespeichert werden, der sich mit diesen Datenbanken verbinden kann, um nach der gewünschten DD zu suchen. Die DD-Abrufroutine 200 kann auch jede gewünschte Suchmaschine, jeden gewünschten Browser usw. verwenden, um nach der gewünschten DD zu suchen. Falls gewünscht, kann die DD-Abrufroutine 200 mit dem Bediener unter Verwendung eines interaktiven Bildschirms interagieren, um den Bediener in die Lage zu versetzen, beim Auffinden der geeigneten DD im Internet 54 behilflich zu sein. Wenn eine Datenbank gefunden wird, welche die DD für das Gerät enthält, sendet die DD-Abrufroutine 200 eine Abfrage an die Datenbank, um die DD für das Gerät zu erhalten. Eine solche Abfrage an die Datenbank kann einige oder alle von den Informationen enthalten, die in der DD-Identifikation für das Gerät enthalten sind, die in Block 204 erhalten wurde.
  • Nachdem die DD für das Gerät in Block 208 in den DDL-basierten Host 50 heruntergeladen wurde, oder wenn in Block 206 bestimmt wird, dass der DDL-basierte Host 50 die DD für das Gerät hat, aktualisiert die DD-Abrufroutine 200 den DDL-basierten Host 50 in Block 210. Ein Benutzer kann spezifizieren, dass der DDL-basierte Host 50, falls notwendig, automatisch im Hinblick auf DDs aktualisiert wird. Alternativ dazu kann in Block 210 ein Befehl zum Aktualisieren des DDL-basierten Hosts 50 mit einer gewünschten DD gesendet werden. Eine Aktualisierung des DDL-basierten Hosts 50 mit der DD für das Gerät kann das Speichern der DD für das Gerät an einem spezifischen Ort im Speicher und, falls nötig, das Einfügen eines Rufs an diesen spezifischen Ort in den DDL-basierten Host 50 beinhalten. Das Aktualisieren des DDL-basierten Hosts 50 mit der DD für das Gerät kann auch das Einfügen der DD für das Gerät in die DD-Bibliothek 52 beinhalten.
  • Wie wiederum in 3 dargestellt ist, liest die Konfigurationsroutine 100, nachdem die DD für das (die) ausgewählte(n) Gerät(e) abgerufen wurde, die DD für das Gerät und legt alle DDL-Menüs und DDL-Menükonstrukte (z.B. Menüpunkte oder Parameter, die in einem Menü angezeigt werden, wie Variablen, Graphen, Bilder, Raster, Diagramme usw.) innerhalb der DD dem DDL-basierten Host 50 (oder der Host-Anwendung) gegenüber offen. Zum Beispiel kann die Konfigurationsroutine 100 die DD durchmustern und analysieren, um dem Benutzer alle DDL-Menükonstrukte über die Konfigurationsoberfläche verfügbar zu machen, so dass die DDL-Menükonstrukte und -werte der Konfigurationsroutine 100 ebenso wie zusätzlichen Routinen, die noch beschrieben werden, bereitgestellt werden können, um eine grafische DDL-Benutzeroberfläche zu gestalten mit vom Benutzer gewünschten Menüoptionen und Parametern, die auf die grafische DDL-Benutzeroberfläche anzuwenden sind. Es sei klargestellt, dass der Hersteller trotzdem Beschränkungen für einen Zugriff des Benutzers wollen kann. Von daher ermöglichen die DDL-Menüs und DDL-Menükonstrukte dem Benutzer die Konfigurierung der grafischen DDL-Benutzeroberfläche in Bezug darauf, wie der Benutzer die Informationen angezeigt bekommt, gestatten dem Benutzer aber nicht unbedingt ausnahmslos alle Informationen zu sehen. Das heißt, die Daten, die normalerweise im voreingestellten Gerätemenü angezeigt werden, das aus der vom Gerätehersteller entwickelten Ressourcen-Datei erzeugt wird, bleiben für den Benutzer verfügbar, aber durch die Offenlegung des DDL-Menüs und der DDL-Menükonstrukte werden dem Benutzer gegenüber keine weiteren Daten offengelegt. Vielmehr werden durch Offenlegen des DDL-Menüs und der DDL-Menükonstrukte die Menükonstrukte, die der Benutzer bereits im vorangestellten Gerätemenü betrachten kann, zur Wahl gestellt, so dass der Benutzer in der Lage ist, die Art und Weise zu konfigurieren, wie die Daten in der grafischen DDL-Benutzeroberfläche präsentiert werden sollen.
  • In Block 112 werden die DDL-Menükonstrukte dem Benutzer auf der Konfigurationsoberfläche präsentiert, für die ein Beispiel in 7 gezeigt ist. Wie in 7 gezeigt ist, präsentiert die Konfigurationsoberfläche die offengelegten DDL-Menükonstrukte („Params“) in einem Menükonstrukt-Template 300. Auch wenn sie beispielhaft als Variable# (Variable1, Variable2, Variable3 usw.) gezeigt sind, werden die Namen der DDL-Menükonstrukte auf solche Weise präsentiert und klar beschrieben, dass sie für den Benutzer verständlich sind. Zusätzlich zu dem Menükonstrukt-Template 300 kann auch ein Menüstil-Template 302 bereitgestellt werden, um Optionen für unterschiedliche Arten von Menüs zu präsentieren (z.B. Gruppenfeld, Fenster, Menü, Seite). Ein Konfigurations-Template 304 dient als Template für die grafische DDL-Benutzeroberfläche und stellt einen Bereich bereit, in dem der Benutzer die grafische DDL-Benutzeroberfläche gestalten kann.
  • Ein DDL-Menükonstrukt kann in Block 114 gemäß den Präferenzen des Benutzers (z.B. im Hinblick auf Platzierung, Menüstil usw.) ausgewählt und in Block 116 zu der grafischen DDL-Benutzeroberfläche hinzugefügt werden. Zum Beispiel kann der Benutzer, wie in 7 dargestellt ist, bestimmte grafische Symbole, welche die DDL-Menükonstrukte darstellen, aus dem Menükonstrukt-Template 300 auswählen, die Symbole in das Konfigurations-Template 304 ziehen und die DDL-Menükonstrukte dort platzieren, wo der Benutzer sie haben möchte. Innerhalb des Konfigurations-Templates 304 kann der Benutzer die Menükonstrukte auf jede gewünschte Weise anordnen. Ebenso kann der Benutzer ein Symbol, das einen Menüstil darstellt, aus dem Menüstil-Template 302 auswählen, das Symbol in das Konfigurations-Template 304 ziehen und den Menüstil dort platzieren, wo der Benutzer ihn haben möchte. Innerhalb des Konfigurations-Templates 304 kann der Benutzer die Menüstile und/oder Menükonstrukte auf jede gewünschte Weise anordnen. Statt einer grafischen DDL-Benutzeroberfläche, die alle relevanten Informationen zur Überwachung eines spezifischen Geräts zeigt, kann der Benutzer mehrere Geräte auswählen und beispielsweise auswählen, dass die Temperaturvariable für jedes Gerät auf einer grafischen DDL-Benutzeroberfläche angezeigt werden soll, um dadurch eine grafische DDL-Benutzeroberfläche zu erzeugen, die individuell so angepasst ist, dass sie nur Temperaturmesswerte, nur Druckmesswerte oder nur andere Variablen für mehrere Geräte zeigt, wobei es sich um ein Merkmal handelt, das von voreingestellten Menüs aus einer Geräte-DD nicht unterstützt wird, da die DDs so spezifiziert sind, dass sie nur ein bestimmtes Gerät oder einen bestimmten Gerätetyp zeigen.
  • Wenn in Block 116 ein Menükonstrukt zu der grafischen DDL-Benutzeroberfläche hinzugefügt wird, kann die Konfigurationsroutine 100 auch bestimmen, ob das hinzugefügte Menükonstrukt eine oder mehrere Abhängigkeiten aufweist (z.B. Child-Objekte, die von einer Variablen abhängen). In einem solchen Fall kann die Konfigurationsroutine 100 die Steuerung in Block 118 zum Block 114 zurückspringen lassen und nur die Menükonstrukte präsentieren, die von dem zuvor unter Verwendung der DDL-Konditionale ausgewählten Menükonstrukt abhängig sind. Wenn beispielsweise die hinzugefügte Variable für ein ausgewähltes Gerät der Druck ist, können Abhängigkeiten die sich aus dem Druck ergeben, beispielsweise obere und untere Bereichswerte, kritische Parameter sein. Unter Verwendung von DDL-Konditionalen kann die Konfigurationsroutine 100 alle anderen Menükonstrukte „verbergen“ und dem Benutzer nur Menükonstrukte für den oberen und den unteren Bereich für den Druck präsentieren. Ferner kann die Konfigurationsroutine 100 unter Verwendung von DDL-Konditionalen sogar verhindern, dass der Benutzer das Menü abschließt und speichert, wenn nicht alle Konditionale abgearbeitet wurden, so dass die Einbeziehung des Menükonstrukts in die grafische DDL-Benutzeroberfläche die Auswahl weiterer Menükonstrukte zur Bedingung hat.
  • DDL-Konditionale können auch verwendet werden, um den Benutzer bei der Konfigurierung des Menüs anzuleiten, angesichts dessen, dass ein Gerät (oder eine Gerätegruppe) zahlreiche Menükonstrukte innerhalb der DD aufweisen kann. Während die Konfigurationsroutine 100 Menükonstrukte für den Zweck der Konfigurierung einer grafischen DDL-Benutzeroberfläche offenlegt, können DDL-Konditionale auch verwendet werden, um die dem Benutzer präsentierten Menükonstrukte dadurch zu vereinfachen, dass nur ein Teilsatz von Menükonstrukten präsentiert wird und alle anderen „verborgen“ werden, und dann nur solche Menükonstrukte präsentiert werden, die für das zuvor ausgewählte Menükonstrukt relevant sind. Zum Beispiel kann die Konfigurationsroutine 100 zu Anfang nur die Variablen für das (die) ausgewählte(n) Gerät(e) (z.B. Druck, Temperatur usw.) präsentieren, während alle anderen Menükonstrukte (z.B. Graphen, Diagramme, Abhängigkeiten usw.) für die Variablen „verborgen“ werden. Sobald die Variable (z.B. Druck) ausgewählt wurde, können alle anderen Menükonstrukte (einschließlich der nicht-ausgewählten Variablen) verborgen oder anderweitig nicht-auswählbar gemacht werden, außer denen, die für die ausgewählte Variable relevant sind (z.B. Druckgraphen, Druckdiagramme, Druckabhängigkeiten usw.). Sobald die DDL-Konditionale für eine Variable abgearbeitet worden sind, kann die Konfigurationsroutine 100 dazu zurückkehren, nur die Variablen für das (die) ausgewählte(n) Gerät(e) zu präsentieren.
  • In einer Ausführungsform kann auch die Präsentation relevanter Menükonstrukte auf DDL-Konditionalen basieren. Wenn ein Benutzer beispielsweise die Variable „Druck“ auswählt, kann die Konfigurationsroutine 100 dann Menükonstrukte für die oberen und unteren Bereichswerte für den Druck präsentieren. Erst nachdem der Benutzer die Menükonstrukte für die oberen und unteren Bereichswerte ausgewählt hat, präsentiert die Konfigurationsroutine 100 Menükonstrukte für Graphen, Diagramme usw. für den Druck. Somit werden die Graphen, Diagramme usw. von den oberen und unteren Bereichswerten für den Druck abhängig gemacht, die ihrerseits von der Variablen Druck abhängen. Auf diese Weise können DDL-Konditionale genutzt werden, um selbst relevante Menükonstrukte voneinander abhängig zu machen, um den Benutzer durch die Konfiguration zu leiten. In manchen Fällen können die DDL-Konditionale zwingend notwendig sein (z.B. das Auswählen oberer und unterer Bereichswerte für den Druck), so dass die Konfigurationsroutine 100 nicht fortschreitet oder dem Benutzer nicht erlaubt, das Menü abzuschließen und zu speichern, solange das Menükonstrukt nicht ausgewählt worden ist. In anderen Fällen können die DDL-Konditionale optional sein (z.B. das Auswählen eines Graphen oder eines Diagramms für den Druck). Somit kann die Verwendung von DDL-Konditionalen verwendet werden, um den Benutzer durch die Konfiguration des Menüs zu leiten, ohne den Benutzer durch die Anzahl von DDL-Menükonstrukten, die als Optionen verfügbar sind, welche in die grafische DDL-Benutzeroberfläche einbezogen werden können, zu überfordern.
  • Falls der Benutzer mit der Konfigurierung der grafischen DDL-Benutzeroberfläche fertig ist, was in Block 118 bestimmt wird, kann das Menü in Block 120 gespeichert werden. Falls nicht, kann die Steuerung für die Auswahl des nächsten DDL-Menükonstrukts zu Block 114 zurückkehren. Wenn die konfigurierte grafische DDL-Benutzeroberfläche in Block 120 gespeichert wird, wird die grafische DDL-Benutzeroberfläche mit dem DDL-basierten Host 50 gespeichert. Genauer gesagt wird die grafische DDL-Benutzeroberfläche als FILE-Daten gespeichert, wobei die Werte der gewählten DDL-Menükonstrukte in der Benutzerdatenbank gespeichert werden, beispielsweise in der des DDL-basierten Hosts 50. Die DDL-Menükonstrukte können als FILE-Daten als LOCAL-Variablen gespeichert werden, statt mit dem Gerät gespeichert zu werden. Durch Speichern der Benutzerpräferenzen als FILE-Daten können grafische DDL-Benutzeroberflächen erzeugt und gespeichert werden, ohne dass bereits vorhandene Firmware geändert werden müsste und ohne dass zusätzliche Änderungen an dem Gerät an sich nötig wären. Das heißt, die Lösung liegt ausschließlich innerhalb der DDL. Somit ist der Benutzer in der Lage, eine grafische DDL-Benutzeroberfläche zu konfigurieren, die dynamisch erzeugt und vom DDL-basierten Host 50 bewahrt wird. Die Konfigurationsoberfläche, wie sie beispielsweise in 4, 5 und 7 gezeigt ist, ermöglicht dem Benutzer, die DDL-Menükonstrukte auszusuchen und zu wählen, die für den Benutzer wichtig sind, wobei diese Konstrukte der grafischen DDL-Benutzeroberfläche hinzugefügt werden. Wie weiter unten ausführlicher erörtert wird, kann der Benutzer die grafische DDL-Benutzeroberfläche jederzeit rufen und aktivieren, die grafische DDL-Benutzeroberfläche verbergen und die grafische DDL-Benutzeroberfläche mit unterschiedlichen DDL-Menükonstrukten rekonfigurieren.
  • 8 ist ein Sequenzdiagramm, das die Interaktion zwischen Prozessen bei der Erzeugung und Konfigurierung einer grafischen DDL-Benutzeroberfläche zeigt, die von einem DDL-basierten Host-System 50 auf Basis des in 3 offenbarten Verfahrens bewahrt wird. Beginnend mit einer DDL-Host-Anwendung 350, die auf dem DDL-basierten Host 50 ausgeführt werden kann, wird ein asynchroner Ruf zur Erzeugung eines neuen benutzerdefinierten Menüs („create“) an eine Menüerzeugeroberfläche 352 ausgegeben. Die DDL-Host-Anwendung 350 kann eine Anwendung aus der AMS® Suite sein, und die Menüerzeugeroberfläche 352 kann die Konfigurationsoberfläche zur Erzeugung und Konfigurierung von Menüs sein, die in 5 und 7 dargestellt ist, wobei der Ruf von der AMS®-Anwendung an die Konfigurationsoberfläche zur Erzeugung von Menüs ergeht. Der Ruf zur Erzeugung einer neuen grafischen DDL-Benutzeroberfläche kann als Reaktion auf einen Befehl zur Konfigurierung einer grafischen DDL-Benutzeroberfläche in Block 102 von 3 ergehen, wenn der Benutzer die Option „Create User Defined Menu“ in 4 auswählt. Daraufhin kann ein anderer asynchroner Ruf zur Erzeugung der grafischen DDL-Benutzeroberfläche („create“) von der Menüerzeugeroberfläche 352 an eine Gerätefinderoberfläche 354 ergehen, beispielsweise an den AMS® Device Manager oder ein anderes Geräteverwaltungswerkzeug, das in 4 abgebildet ist. Alternativ dazu kann der Ruf zur Erzeugung einer neuen grafischen DDL-Benutzeroberfläche von der Menüerzeugeroberfläche 352 ausgehen, wenn diese bereits auf anderem Wege gestartet worden ist. Ebenso kann der Ruf zur Erzeugung einer neuen grafischen DDL-Benutzeroberfläche von der Gerätefinderoberfläche 354 kommen, beispielsweise wenn der Benutzer im Geräteverwaltungswerkzeug ein Gerät aus der Geräteliste auswählt, wie unter Bezugnahme auf 4 erörtert wurde, in welchem Fall der Ruf von der Gerätefinderoberfläche 354 an die Menüerzeugeroberfläche 352 ergeht.
  • Der Ruf zur Erzeugung eines neuen benutzerdefinierten Menüs bewirkt, dass die Gerätefinderoberfläche 354 einen synchronen Aufruf („GetDEvices“) an eine Datenspeicherungsanwendung 356 ausgibt, um eine Liste von Geräten abzurufen, die dem Benutzer zur Auswahl präsentiert wird, wie in Block 104 in 3. Als Reaktion darauf schickt die Datenspeicherungsanwendung 356 eine Liste von Geräten („Device List“) an die Gerätefinderoberfläche 354. Die Liste der Geräte kann aus solchen bestehen, für deren Überwachung und/oder Kontrolle der Benutzer die Berechtigung hat, oder aus Geräten innerhalb einer bestimmten Schleife oder Einheit oder eines bestimmten Bereichs usw., auf Basis einer Auswahl der Schleife oder der Einheit oder des Bereichs usw., die in der Gerätefinderoberfläche vorgenommen wird. Wenn der Benutzer beispielsweise eine bestimmte Einheit unter Verwendung eines Navigationsbaums usw. ausgewählt hat, können die Geräte für diese Einheit (einschließlich aller Schleifen innerhalb dieser Einheit) aus dem Datenspeicher 356 abgerufen werden. Falls der Benutzer unter Verwendung eines Navigationsbaums eine bestimmte Schleife innerhalb einer Einheit ausgewählt hat, können die Geräte für diese Schleife ebenso aus dem Datenspeicher 356 abgerufen werden.
  • Die Gerätefinderoberfläche 354 kann dem Benutzer dann diese Geräte präsentieren, und als Reaktion darauf kann die Gerätefinderoberfläche 354 eine Nachricht von außen von der Sequenz empfangen, die eine Auswahl mindestens eines Geräts vom Benutzer anzeigt („Device Selection“), was Block 104 von 3 entspricht. Als Reaktion darauf wird eine asynchrone Nachricht („Device“) von der Gerätefinderoberfläche 354 an die Menüerzeugeroberfläche 352 gesendet, durch die das (die) ausgewählte(n) Gerät(e) bezeichnet wird (werden). Die Erzeugeroberfläche 352 gibt dann einen synchronen Ruf („GetDeviceParameters“) an die Datenspeicherungsanwendung aus, um alle DDL-Menükonstrukte für das (die) ausgewählte(n) Gerät(e) abzurufen. Der Ruf zum Abrufen des DDL-Menükonstrukts kann eine Subroutine in der Datenspeicherungsanwendung 356 aufrufen, um die DD für das (die) ausgewählte(n) Gerät(e) abzurufen, wie in Block 108 von 3 und in 6 dargestellt ist.
  • Die Datenspeicherungsanwendung 356 antwortet der Menüerzeugeroberfläche 352 mit der Liste von Menükonstrukten für das (die) ausgewählte(n) Gerät(e) („DeviceParameters“), und dann werden die Menükonstrukte gegenüber dem oder vom Menüerzeuger 352 offengelegt, so dass sie dem Benutzer präsentiert werden können. Die Menüerzeugeroberfläche 352 kann dann von außen von der Sequenz eine synchrone Nachricht („Select Parameters/Add to Menu“) empfangen, welche die DDL-Menükonstrukte anzeigt, die vom Benutzer für die Hinzufügung zu dem Menü ausgewählt worden sind, was den Blöcken 114-118 von 3 und der in 7 abgebildeten Oberfläche entspricht.
  • Die Hinzufügung von Menükonstrukten zur grafischen DDL-Benutzeroberfläche kann das Mapping der grafischen DDL-Benutzeroberfläche auf das ausgewählte DDL-Menükonstrukt beinhalten. Das Mapping der grafischen DDL-Benutzeroberfläche auf das ausgewählte DDL-Menükonstrukt kann das Einfügen eines Rufs oder Befehls zum Aufrufen des DDL-Menükonstrukts, wenn die grafische DDL-Benutzeroberfläche aktiviert wird, in die FILE-Daten der grafischen DDL-Benutzeroberfläche beinhalten, Das Mapping kann auch das Hinzufügen eines Werts, der mit dem DDL-Menükonstrukt verknüpft (gemappt) ist, zu den FILE-Daten der grafischen DDL-Benutzeroberfläche beinhalten. Betrachtet man beispielsweise das oben angegebene Beispiel für einen partiellen Pseudocode der DDL für eine grafische DDL-Benutzeroberfläche, für die FILE-Daten verwendet werden, so können die DDL-Menükonstrukte „gauge_showing_pressure“, „sweep_chart_plotting_pressure“ und „pressure_value_as_text“ als Rufe dienen zum Anzeigen der grafischen Darstellungen der DDL-Menükonstrukte auf dem Anzeigegerät, wenn die grafische DDL-Benutzeroberfläche aktiviert wird. Die Variable (Druck) weist Werte „0“, „1“ und „2“ auf, die jeweils auf die DDL-Menükonstrukte „gauge_showing_pressure“, „sweep_chart_plotting_pressure“ und „pressure_value_as_text“ gemappt werden.
  • Sobald die DDL-Menükonstrukte ausgewählt und hinzugefügt worden sind, wird ein asynchroner Ruf zum Speichern der grafischen DDL-Benutzeroberfläche an den Datenspeicher 365 ausgegeben („Save Menu“), was dem Block 120 von 3 entspricht. Wie oben erörtert wurde, kann die grafische DDL-Benutzeroberfläche als DDL-FILE-Daten am DDL-basierten Host 50 gespeichert werden. Der DDL-basierte Host 50 ist für die Bewahrung der Integrität der Informationen des DDL-Menükonstrukts verantwortlich, wenn diese während der Konfigurationsroutine 100 aus dem zugehörigen Gerät abgefragt werden und offengelegt werden, wobei die DDL-Menükonstrukte lokal gespeichert werden können, beispielsweise in der DD-Datenbank 52. Der DDL-basierte Host 50 gibt ferner Befehle aus, die nötig sind, um die Datenwerte der DDL-Konstrukte zu erfassen. Wenn die DDL-Konstrukte beispielsweise innerhalb der FILE-Daten als Rufe dienen, interpretiert der DDL-basierte Host 50 diese Rufe und gibt Befehle aus zum Abfragen der DDL-Konstrukte für die grafische DDL-Benutzeroberfläche aus der lokalen Datenbank und zum Anzeigen der DDL-Konstrukte als Teil der grafischen DDL-Benutzeroberfläche.
  • Ein Beispiel für eine vom Benutzer konfigurierte grafische DDL-Benutzeroberfläche ist in 9 gezeigt, wobei diese ein Bild (eine grafische Darstellung) (360) des ausgewählten Geräts, grafische Darstellungen der vom Benutzer ausgewählten Variablen 362-368 zusammen mit Feldern 370-378 für die Eingabe von Werten für die Variablen und eine MENU-Option 380 zum Aufrufen von DDL METHOD einschließt. Nachdem die grafische DDL-Benutzeroberfläche gespeichert worden ist, kann die grafische DDL-Benutzeroberfläche in einem Menü-Geräte-Template (z.B. einem Fenster oder einem Frame) betrachtet werden. Unter Verwendung einer DDL-Host-Anwendung, beispielsweise einer Anwendung aus der ASM® Suite, kann die grafische DDL-Benutzeroberfläche durch Auswählen einer Shortcut-Leiste 382, als Navigationsmenüoption 384 oder durch Auswählen eines Geräts (z.B. durch Rechtsklicken auf einen Gerätenamen oder ein Gerätesymbol) aus einer Geräteliste, um ein Kontextmenü mit der grafischen DDL-Benutzeroberfläche als Option erzeugen, aktiviert oder gerufen werden. Auch wenn sie als „new menu“ angezeigt werden, können die Benennungen für diese Optionen die gleichen sein wie für die grafische DDL-Benutzeroberfläche, die vom Benutzer gespeichert wird.
  • 10 ist ein Ablaufschema eines Beispiels für eine Aktivierungsroutine 400 für eine grafische DDL-Benutzeroberfläche zum Aktivieren einer grafischen DDL-Benutzeroberfläche aus einer DDL-Host-Anwendung wie AMS® Device Manager. Beginnend mit Block 402 wird die DDL-Host-Anwendung beispielsweise unter Verwendung des DDL-basierten Hosts 50 oder einer anderen Workstation 14 gestartet. Die DDL-Host-Anwendung kann dem Benutzer im Block 404 mindestens ein Gerät auflisten oder anderweitig anzeigen, beispielsweise Geräte, die der Benutzer zu überwachen und/oder zu kontrollieren befugt ist. Wie bereits angegeben, kann das Gerät innerhalb einer bestimmten Schleife oder Einheit oder eines bestimmten Bereichs usw. enthalten sein. Alternativ oder zusätzlich dazu kann die DDL-Host-Anwendung eine oder mehrere Menüoptionen, die mit den Geräten assoziiert sind, anzeigen, wie im Block 406, einschließlich des voreingestellten Standard-DD-Menüs, das vom Hersteller des Geräts oder vom Entwickler der DD bereitgestellt wird, und etwaiger konfigurierter grafischer DDL-Benutzeroberflächen für das ausgewählte Gerät.
  • Der Benutzer kann ein Menü auf verschiedenen Wegen auswählen, unter anderem durch Auswählen des Geräts aus der Liste angezeigter Geräte oder durch Auswählen einer grafischen DDL-Benutzeroberfläche aus den angezeigten Menüoptionen. Zum Beispiel kann eine grafische DDL-Benutzeroberfläche in Block 408 aus den Menüoptionen ausgewählt werden, wonach die ausgewählte grafische DDL-Benutzeroberfläche in Block 410 gestartet wird. Wenn in Block 412 ein Gerät ausgewählt wird, beispielsweise durch Rechtsklick auf einen Gerätenamen oder ein Gerätesymbol, kann die Menüaktivierungsroutine 400 in Block 414 bestimmen, ob eine grafische DDL-Benutzeroberfläche existiert oder nicht. Falls ja, kann die Auswahl eines Geräts bei 412 bewirken, dass in Block 416 ein Kontextmenü mit der grafischen DDL-Benutzeroberfläche als Option erzeugt wird. Sobald die Option für die grafische DDL-Benutzeroberfläche ausgewählt worden ist, wird die grafische DDL-Benutzeroberfläche in Block 418 gestartet. Falls keine grafische DDL-Benutzeroberfläche existiert, kann die Menüaktivierungsroutine 400 in Block 420 bewirken, dass ein Standard-Kontextmenü erzeugt wird. Sobald die Option für ein voreingestelltes Standard-Gerätemenü ausgewählt wurde, wird in Block 422 unter Verwendung der DD und der Ressourcen-Datei für das Gerät das voreingestellte Standard-Gerätebeschreibungsmenü gestartet.
  • Sobald eine grafische DDL-Benutzeroberfläche erzeugt, konfiguriert und gespeichert worden ist, kann die grafische DDL-Benutzeroberfläche bearbeitet werden, um ein oder mehrere DDL-Menükonstrukte innerhalb der grafischen DDL-Benutzeroberfläche zu modifizieren (z.B. ein Konstrukt zu löschen, ein Konstrukt hinzuzufügen, ein Konstrukt zu modifizieren) oder um DDL-Menükonstrukte für ein neues Gerät hinzuzufügen. 11 ist ein Beispiel für eine Bearbeitungsroutine 500 zum Modifizieren oder Hinzufügen eines Geräts zu einer vorhandenen grafischen DDL-Benutzeroberfläche. Beginnend mit Block 502 werden die grafischen DDL-Benutzeroberflächen des Benutzers angezeigt. Die grafischen DDL-Benutzeroberflächen können in einer GUI präsentiert werden, die der ähnelt, die in 9 gezeigt ist, wodurch der Benutzer eine grafische DDL-Benutzeroberfläche aus einer Shortcut-Leiste 382 oder als Navigationsmenüoption 384 auswählen kann. In einem Beispiel kann die Option zur Bearbeitung der ausgewählten grafischen DDL-Benutzeroberfläche aus der Werkzeugleiste oder durch Auswählen (z.B. durch Rechtsklick) der grafischen DDL-Benutzeroberfläche, die in der Shortcut-Leiste 382 oder im Navigationsmenü 384 aufgelistet ist, vorgenommen werden, um ein Kontextmenü mit einer Option zur Bearbeitung der grafischen DDL-Benutzeroberfläche zu erzeugen.
  • Sobald in Block 504 eine grafische DDL-Benutzeroberfläche mit der Option zur Bearbeitung der grafischen DDL-Benutzeroberfläche ausgewählt worden ist, werden die DDL-Menükonstrukte für die grafische DDL-Benutzeroberfläche in Block 506 offengelegt. Ähnlich wie bei der Offenlegung von DDL-Menükonstrukten in Block 110 von 3 durchmustert und analysiert die Bearbeitungsroutine 500 die grafische DDL-Benutzeroberfläche, um dem Benutzer alle DDL-Menükonstrukte über die Konfigurationsoberfläche verfügbar zu machen, so dass die DDL-Menükonstrukte und -werte innerhalb der grafischen DDL-Benutzeroberfläche dem Benutzer angezeigt werden. Außerdem kann die Bearbeitungsroutine 500 die DD für das (die) Gerät(e), die abgerufen wurde, als die grafische DDL-Benutzeroberfläche ursprünglich erzeugt oder zuvor konfiguriert wurde, abrufen, falls der Benutzer der grafischen DDL-Benutzeroberfläche ein DDL-Menükonstrukt hinzufügen will. Die Bearbeitungsroutine 600 kann ebenfalls die DD durchmustern und analysieren, um dem Benutzer alle DDL-Menükonstrukte über die Konfigurationsoberfläche verfügbar zu machen. Falls die DD nicht innerhalb der DD-Bibliothek 52 gespeichert worden ist, kann die Bearbeitungsroutine 500 die DD-Abrufroutine 200 von 6 nutzen.
  • Nachdem die DDL-Menükonstrukte im Block 508 offengelegt wurden, werden die DDL-Menükonstrukte in Block 508 dem Benutzer auf der Konfigurationsoberfläche präsentiert. Die Konfigurationsoberfläche kann die gleiche sein, die in 7 gezeigt ist, wobei die grafische DDL-Benutzeroberfläche zur Bearbeitung im Konfigurations-Template 304 angezeigt wird. Sobald die DDL-Menükonstrukte offengelegt wurden und die grafische DDL-Benutzeroberfläche zur Bearbeitung präsentiert wird, können dem Benutzer Optionen für die Bearbeitung der grafischen DDL-Benutzeroberfläche präsentiert werden, beispielsweise zum Modifizieren der grafischen DDL-Benutzeroberfläche oder zum Hinzufügen von DDL-Menükonstrukten für ein neues Gerät zur grafischen DDL-Benutzeroberfläche. Auf Basis der Auswahl des Benutzers, wie in Block 510 bestimmt, kann die Bearbeitungsroutine 500 in Block 512 ein oder mehrere DDL-Menükonstrukte für ein neues Gerät zu der grafischen DDL-Benutzeroberfläche hinzufügen oder die grafische DDL-Benutzeroberfläche in Block 514 modifizieren, beispielsweise durch Hinzufügen, Löschen oder Modifizieren eines DDL-Menükonstrukts.
  • Um in Block 512 DDL-Menükonstrukte für ein neues Gerät hinzuzufügen, kann eine neue Geräteroutine 600 aufgerufen werden, wie in 12 gezeigt ist. Die neue Geräteroutine kann der Gerätebeschreibungs-Konfigurationsroutine 100 ähneln, die in 3 gezeigt ist. Genauer werden beginnend mit Block 602 die Geräte, für die DDL-Menükonstrukte hinzugefügt werden können, abgerufen und dem Benutzer präsentiert, beispielsweise unter Verwendung des in 4 gezeigten Geräteverwaltungswerkzeugs. Die Geräte-Hinzufügungsroutine 600 bestimmt in Block 604, ob ein Gerät oder eine Gerätegruppe ausgewählt worden ist. Ein Benutzer kann ein oder mehrere Geräte aus der Liste von Geräten auswählen, die in der GUI des Geräteverwaltungswerkzeugs präsentiert wird. Wie bei der Erzeugung einer grafischen DDL-Benutzeroberfläche kann das (können die) vom Benutzer ausgewählte(n) Gerät(e) die Geräte sein, die der Kontrolle/dem Zugriff des Benutzers unterliegen und/oder die innerhalb einer bestimmten physischen oder logischen Gruppe von Geräten enthalten sind. Der Benutzer kann Geräte beispielsweise durch Ziehen des Symbols, durch welches das in der Liste präsentierte Gerät darstellt wird, in das Konfigurationsfenster 304 von 5 (d.h. durch Drag-and-Drop) auswählen. Alternativ dazu kann das (können die) ausgewählte(n) Gerät(e) dem Konfigurationsfenster 304 automatisch hinzugefügt werden, wenn der Benutzer das (die) Gerät(e) auswählt (z.B. durch Rechtsklick auf das Gerätesymbol). Die Konfigurationsroutine 600 kann nach einer vorgegebenen Zeitspanne automatisch enden (Timeout) (Block 606).
  • Nachdem mindestens ein Gerät ausgewählt wurde, ruft die Geräte-Hinzufügungsroutine 600 in Block 608 die DD für das (die) ausgewählte(n) Gerät(e) ab. Die DD für das Gerät kann, falls sie zuvor von dem Gerät selbst bereitgestellt wurde, aus der DD-Bibliothek 52 des DDL-basierten Hosts 50 oder aus dem Management-Informationssystem 56, aus einer der verschiedenen DD-Datenbanken 58, 60, 62 oder aus der Geräteherstellerdatenbank 64 abgerufen werden. Die Geräte-Hinzufügungsroutine 600 kann die DD-Abrufroutine 200 von 6 zum Abrufen der DD eines ausgewählten Geräts im Block 608 nutzen.
  • Wenn die DD für das (die) ausgewählte(n) Gerät(e) abgerufen wurde, liest die Geräte-Hinzufügungsroutine 600 die DD für das neue Gerät aus und legt in Block 610 alle DDL-Menüs und DDL-Menükonstrukte (z.B. Menüposten oder Parameter, die in einem Menü angezeigt werden, wie Variablen, Graphen, Bilder, Raster, Diagramme usw.) innerhalb der DD gegenüber dem DDL-basierten Host 50 (oder der Host-Anwendung) offen. Die Geräte-Hinzufügungsroutine 600 kann die DD durchmustern und analysieren, um dem Benutzer alle DDL-Menükonstrukte über die Konfigurationsoberfläche verfügbar zu machen, so dass die DDL-Menükonstrukte und -werte der Geräte-Hinzufügungsroutine 600 bereitgestellt werden können, um der grafischen DDL-Benutzeroberfläche DDL-Menükonstrukte hinzuzufügen. Wie in 3 werden bei der Offenlegung des DDL-Menüs und der DDL-Menükonstrukte die Menükonstrukte, die der Benutzer bereits im vorangestellten Gerätemenü betrachten kann, für das ausgewählte Gerät genommen und zur Wahl gestellt, so dass der Benutzer auswählen kann, welche DDL-Menükonstrukte der grafischen DDL-Benutzeroberfläche hinzugefügt werden sollen.
  • In Block 612 werden die DDL-Menükonstrukte für das neue Gerät dem Benutzer auf einer Konfigurationsoberfläche präsentiert, beispielsweise derjenigen von 7. Wie in dem Beispiel von 7 kann die grafische DDL-Benutzeroberfläche, die gerade bearbeitet wird, im Konfigurations-Template 304 angezeigt werden, wobei die offengelegten DDL-Menükonstrukte in einem Menükonstrukt-Template 300 bereitgestellt werden. Die offengelegten DDL-Menükonstrukte im Menükonstrukt-Template 300 können bloß diejenigen sein, die in Block 610 für das neue Gerät offengelegt worden sind, oder sie können die DDL-Menükonstrukte für das neue Gerät ebenso wie die DDL-Menükonstrukte einschließen, die in der grafischen DDL-Benutzeroberfläche verwendet werden, und/oder die DDL-Menükonstrukte für das (die) Gerät(e), die abgerufen wurden, als die grafische DDL-Benutzeroberfläche ursprünglich erzeugt und konfiguriert wurde,
  • Sobald die DDL-Menükonstrukte offengelegt wurden und präsentiert werden, kann im Block 614 ein DDL-Menükonstrukt gemäß den Präferenzen des Benutzers (z.B. im Hinblick auf Platzierung, Menüstil usw.) ausgewählt und in Block 616 zu der grafischen DDL-Benutzeroberfläche hinzugefügt werden. Zum Beispiel kann der Benutzer, wie wiederum in 7 dargestellt ist, bestimmte grafische Symbole, welche die DDL-Menükonstrukte darstellen, aus dem Menükonstrukt-Template 300 auswählen, die Symbole in das Konfigurations-Template 304 ziehen und die DDL-Menükonstrukte dort platzieren, wo der Benutzer sie haben möchte. Innerhalb des Konfigurations-Templates 304 kann der Benutzer die Menüstile und/oder Menükonstrukte auf jede gewünschte Weise anordnen. Der Prozess zum Hinzufügen eines DDL-Menükonstrukts zu der grafischen DDL-Benutzeroberfläche kann der gleiche sein wie in Block 116 der oben beschriebenen 3. Wenn ein Menükonstrukt in Block 616 zum Menü hinzugefügt wird, verwendet die Geräte-Hinzufügungsroutine 600 das oben mit Bezug auf 3 beschriebene Konzept der DDL-Konditionale für etwaige Variablen, die Abhängigkeiten aufweisen, und um den Benutzer bei der Bearbeitung der grafischen DDL-Benutzeroberfläche zu leiten.
  • Wenn der Benutzer mit der Hinzufügung von DDL-Menükonstrukten für ein neues Gerät zur grafischen DDL-Benutzeroberfläche fertig ist, wie in Block 618 bestimmt wird, kann die Steuerung zur Bearbeitungsroutine 500 zurückkehren. Falls nicht, kann die Steuerung zu Block 614 zurückkehren, während die Geräte-Hinzufügungsroutine 600 auf die Auswahl des nächsten DDL-Menükonstrukts wartet.
  • Falls sich der Benutzer im in 11 gezeigten Block 514 dafür entscheidet, die grafische DDL-Benutzeroberfläche zu bearbeiten, kann die Bearbeitungsroutine 500 eine Modifikationsroutine 700 aufrufen, wie in 13 gezeigt ist. Beginnend mit Block 702 wird ein DDL-Menükonstrukt auf Basis einer Benutzereingabe aus der Anzeige von DDL-Menükonstrukten Block 508 ausgewählt, beispielsweise durch Ziehen eines grafischen Symbols, das ein im Menükonstrukt-Template 300 präsentiertes DDL-Menükonstrukt darstellt, in das Konfigurations-Template 304 von 7 (d.h. durch Drag-and Drop), durch Ziehen eines Symbols, das ein im Konfigurations-Template 304 präsentiertes DDL-Menükonstrukt darstellt, aus dem Konfigurations-Template 304 heraus oder durch Rechtsklicken auf ein Symbol, das ein DDL-Menükonstrukt darstellt, um ein Kontextmenü mit Optionen zur Bearbeitung des DDL-Menükonstrukts anzuzeigen, Wie oben angegeben, können die DDL-Menükonstrukte, die dem Benutzer präsentiert werden, sowohl DDL-Menükonstrukte, die in der gerade bearbeiteten grafischen DDL-Benutzeroberfläche verwendet werden, als auch DDL-Menükonstrukte für das mindestens eine Gerät einschließen, die abgerufen wurden, als die grafische DDL-Benutzeroberfläche ursprünglich erzeugt und konfiguriert oder zuvor bearbeitet wurde.
  • Sobald ein DDL-Konstrukt in Block 702 ausgewählt worden ist, kann die Modifikationsroutine 700 voranschreiten, um dem Benutzer Optionen zum Modifizieren der grafischen DDL-Benutzeroberfläche zu präsentieren, beispielsweise zum Löschen des DDL-Menükonstrukts von der grafischen DDL-Benutzeroberfläche, zum Hinzufügen des DDL-Menükonstrukts zu der grafischen DDL-Benutzeroberfläche oder zum Modifizieren eines DDL-Menükonstrukts in der grafischen DDL-Benutzeroberfläche. In einer Ausführungsform kann die Art und Weise, wie das DDL-Menükonstrukt ausgewählt wird, die Option zum Modifizieren der grafischen DDL-Benutzeroberfläche automatisch aufrufen. Wenn der Benutzer beispielsweise ein Symbol im Konfigurations-Template 304, das ein DDL-Menükonstrukt darstellt, aus dem Konfigurations-Template 304 herauszieht, kann die Modifikationsroutine 700 diese Aktion als Löschen des DDL-Menükonstrukts von der grafischen DDL-Benutzeroberfläche interpretieren und in Block 704 eine DDL-Menükonstrukt-Löschungsroutine aufrufen. Ebenso kann die Modifikationsroutine 700 dann, wenn der Benutzer ein Symbol, das ein DDL-Menükonstrukt darstellt, aus dem Konfigurations-Template 300 in das Konfigurations-Template 304 zieht, diese Aktion als Hinzufügung des DDL-Menükonstrukts zur grafischen DDL-Benutzeroberfläche interpretieren und in Block 706 eine DDL-Menükonstrukt-Hinzufügungsroutine aufrufen. Wenn der Benutzer auf ein Symbol im Menükonstrukt-Template 300 klickt, das ein DDL-Menükonstrukt darstellt, kann die Modifikationsroutine 700 diese Aktion als Modifizierung des DDL-Menükonstrukts interpretieren und in Block 708 eine DDL-Menükonstrukt-Modifizierungsroutine aufrufen. Alternativ oder zusätzlich dazu kann jede der Modifikationsoptionen in den Blöcken 704, 706, 708 über ein Kontextmenü (z.B. durch Rechtsklicken auf ein Symbol, welches das DDL-Menükonstrukt darstellt) und/oder über das Werkzeugleistenmenü aufgerufen werden.
  • 14 ist ein Beispiel für eine DDL-Menükonstrukt-Löschungsroutine 800, die in Block 704 von 13 gezeigt ist, zum Löschen eines DDL-Menükonstrukts von einer grafischen DDL-Benutzeroberfläche. Beginnend mit Block 802 kann die DDL-Menükonstrukt-Löschungsroutine 800 verifizieren, dass ein DDL-Menü ausgewählt worden ist, und bei Block 804 wird das ausgewählte DDL-Menükonstrukt gelöscht. Als Beispiel kann dann, wenn die Modifikationsroutine 700 die Aktion des Ziehens eines Symbols, welches das DDL-Menükonstrukt darstellt, aus dem Inneren des Konfigurations-Templates 304 aus dem Konfigurations-Template 304 heraus interpretiert, Block 802 verwendet werden, um die Bewegung des Symbols auf der Konfigurationsoberfläche nachzuverfolgen, wobei das Löschen des DDL-Menükonstrukts von der grafischen DDL-Benutzeroberfläche in Block 804 erst dann stattfindet, wenn das Symbol außerhalb des Konfigurations-Templates 304 „abgelegt“ worden ist. Wenn die Option zum Löschen eines DDL-Menükonstrukts über ein Kontextmenü aufgerufen wird, kann Block 802 verwendet werden, um zu verifizieren, dass der Benutzer das Symbol für ein DDL-Menükonstrukt (z.B. durch Rechtsklick) ausgewählt hat, und das DDL-Menükonstrukt in Block 804 löschen, wenn der Benutzer die Löschen-Option aus dem Kontextmenü auswählt. Wenn die Option zum Löschen eines DDL-Menükonstrukts über das Werkzeugleistenmenü aufgerufen wird, kann Block 802 ebenso verwendet werden, um zu verifizieren, dass der Benutzer ein DDL-Menükonstrukt ausgewählt hat (z.B., dass der Benutzer auf das DDL-Menükonstrukt geklickt hat, um es zu löschen, oder dass die Auswahl der Löschen-Option vom Werkzeugmenü eine Liste von DDL-Menükonstrukten hervorbringt, die zum Löschen ausgewählt werden können).
  • Man beachte, dass mehrere DDL-Menükonstrukte gleichzeitig gelöscht werden können, beispielsweise unter Verwendung einer Maus, um einen Rahmen um die Symbole mehrerer DDL-Menükonstrukte zu zeichnen und die ausgewählten DDL-Konstrukte anhand eines der oben beschriebenen Verfahren zu löschen. Die DDL-Menükonstrukt-Löschungsroutine 800 kann in Block 806 verifizieren, ob der Benutzer mit dem Löschen von DDL-Menükonstrukten fertig ist, beispielsweise durch Verlangen, dass der Benutzer bestätigt, dass das DDL-Menükonstrukt gelöscht werden soll, und/oder durch Fragen, ob der Benutzer weitere DDL-Menükonstrukte löschen will. Wenn der Benutzer mit dem Löschen von mindestens einem DDL-Menükonstrukt von der grafischen DDL-Benutzeroberfläche fertig ist, wie in Block 806 bestimmt wird, kann die Steuereinrichtung zur Bearbeitungsroutine 500 von 11 zurückkehren. Falls nicht, kann die Steuereinrichtung zu Block 802 zurückkehren, während die DDL-Menükonstrukt-Löschungsroutine 800 auf die Auswahl des nächsten DDL-Menüs wartet, das von der grafischen DDL-Benutzeroberfläche gelöscht werden soll.
  • 15 ist ein Beispiel für eine DDL-Menükonstrukt-Hinzufügungsroutine 900, die in Block 706 von 13 gezeigt ist, zum Hinzufügen eines DDL-Menükonstrukts zu einer grafischen DDL-Benutzeroberfläche. Wenn die DDL-Menükonstrukte aus der DD für das (die) Gerät(e), die abgerufen wurden, als die grafische DDL-Benutzeroberfläche ursprünglich erzeugt und konfiguriert wurde oder zuvor bearbeitet wurde, in Block 506 von 11 nicht bereits offengelegt wurden (beispielsweise, wenn nur die DDL-Menükonstrukte in der grafischen DDL-Benutzeroberfläche offengelegt wurden), können die DDL-Menükonstrukte aus dieser DD in Block 902 offengelegt werden. Ähnlich wie bei der Offenlegung von DDL-Menükonstrukten in Block 110 von 3 und in Block 506 von 11 durchmustert und analysiert die Bearbeitungsroutine 900 die DD, um dem Benutzer alle DDL-Menükonstrukte über die Konfigurationsoberfläche verfügbar zu machen, so dass die DDL-Menükonstrukte und -werte innerhalb der grafischen DDL-Benutzeroberfläche dem Benutzer angezeigt werden.
  • Nachdem die DDL-Menükonstrukte im Block 902 offengelegt wurden, werden die DDL-Menükonstrukte in Block 904 dem Benutzer auf einer Konfigurationsoberfläche präsentiert. Die Oberfläche kann die gleiche sein, die in 7 gezeigt ist, wobei die DDL-Konstrukte im Menükonstrukt-Template 302 angezeigt werden. Sobald die DDL-Menükonstrukte offengelegt worden sind und präsentiert werden, kann in Block 906 ein DDL-Menükonstrukt ausgewählt werden und in Block 908 zu der grafischen DDL-Benutzeroberfläche hinzugefügt werden. Der Prozess zum Hinzufügen eines DDL-Menükonstrukts zu der grafischen DDL-Benutzeroberfläche kann der gleiche sein wie in Block 116 der oben beschriebenen 3. Zum Beispiel kann ein Benutzer das grafische Symbol für ein DDL-Menükonstrukt aus dem Menükonstrukt-Template 302 auswählen, das Symbol in die grafische DDL-Benutzeroberfläche im Konfigurations-Template 304 ziehen und das Symbol an jedem gewünschten Ort innerhalb des Konfigurations-Template 304 ablegen. DDL-Konditionale können in Block 906 ebenfalls berücksichtigt und genutzt werden, wobei die DDL-Menükonstrukt-Hinzufügungsroutine 900 die Steuerung in Block 910 zum Block 906 zurückbringen kann, um die Konditionale abzuarbeiten, wie ebenfalls oben beschrieben wurde.
  • Wenn der Benutzer mit dem Hinzufügen von DDL-Menükonstrukten zu der grafischen DDL-Benutzeroberfläche fertig ist, wie in Block 910 bestimmt wird, kann die Steuerung zur Bearbeitungsroutine 500 von 11 zurückkehren. Falls nicht, kann die Steuerung zu Block 906 zurückkehren, während die DDL-Menükonstrukt-Hinzufügungsroutine 900 auf die Auswahl des nächsten DDL-Menüs wartet, das zur grafischen DDL-Benutzeroberfläche hinzugefügt werden soll.
  • 16 ist ein Beispiel für eine DDL-Menükonstrukt-Modifizierungsroutine 1000, die in Block 708 von 13 gezeigt ist, zum Modifizieren eines DDL-Menükonstrukts in einer grafischen DDL-Benutzeroberfläche. Beginnend mit Block 1002 wird ein DDL-Menükonstrukt innerhalb der grafischen DDL-Benutzeroberfläche ausgewählt. Zum Beispiel kann der Benutzer auf ein oder mehrere grafische Symbole der DDL-Menükonstrukte in der grafischen DDL-Benutzeroberfläche, die innerhalb des Konfigurations-Templates 304 angezeigt werden, klicken oder einen Rahmen darum herum zeichnen. Der Benutzer kann dann eine Option auswählen, um einen Wert des mindestens einen ausgewählten DDL-Menükonstrukts über ein Kontextmenü oder die Werkzeugleiste zu modifizieren. Alternativ dazu kann das einfache Auswählen des DDL-Menükonstrukts eine Auswahl der Option zum Modifizieren des DDL-Menükonstrukts darstellen.
  • Im Block 1004 wird der neue Wert für das DDL-Menükonstrukt empfangen. Zum Beispiel kann der Benutzer neue Werte für VARIABLE eingeben, unter anderem für obere und untere Bereichsgrenzwerte, Wert, Datentyp, Name usw. Ebenso kann der Benutzer durch Ziehen des Symbols für das ausgewählte DDL-Menükonstrukt innerhalb des Konfigurations-Templates 304 an einen gewünschten Ort neue Werte für die Platzierung des DDL-Menükonstrukts innerhalb der grafischen DDL-Benutzeroberfläche eingeben. Sobald der neue Wert eingegeben und in Block 1004 empfangen wurde, kann das DDL-Menükonstrukt in Block 1006 aktualisiert werden. Wenn der Benutzer mit dem Modifizieren von DDL-Menükonstrukten in der grafischen DDL-Benutzeroberfläche fertig ist, wie in Block 1008 bestimmt wird, kann die Steuereinrichtung zur Bearbeitungsroutine 500 von 11 zurückkehren. Falls nicht, kann die Steuereinrichtung zu Block 1002 zurückkehren, während die DDL-Menükonstrukt-Modifizierungsroutine 1000 auf die Auswahl des nächsten DDL-Menükonstrukts wartet, das in der grafischen DDL-Benutzeroberfläche modifiziert werden soll.
  • Wiederum unter Bezugnahme auf in 11 kann die Steuereinrichtung zur Bearbeitungsroutine 500 zurückkehren, wenn ein DDL-Menükonstrukt gelöscht, hinzugefügt und/oder modifiziert wurde, oder auch wenn ein DDL-Menükonstrukt von einem neuen Gerät zum vom Benutzer konfigurierten Menü hinzugefügt wurde. Falls der Benutzer mit der Modifizierung der grafischen DDL-Benutzeroberfläche fertig ist, was in Block 516 bestimmt wird, kann die aktualisierte grafische DDL-Benutzeroberfläche in Block 518 gespeichert werden. Falls nicht, kann die Steuereinrichtung für die nächste Modifikation in der grafischen DDL-Benutzeroberfläche zu Block 508 zurückkehren. Wenn die aktualisierte grafische DDL-Benutzeroberfläche in Block 518 gespeichert wird, wird die aktualisierte grafische DDL-Benutzeroberfläche mit dem DDL-basierten Host 50 gespeichert wie in Block 120 von 3. Genauer gesagt wird die aktualisierte grafische DDL-Benutzeroberfläche als FILE-Daten gespeichert, wobei die Werte der gewählten DDL-Menükonstrukte in der Benutzerdatenbank gespeichert werden, beispielsweise in der des DDL-basierten Hosts 50, statt mit dem Gerät gespeichert zu werden. Wiederum kann durch Speichern der Benutzereinstellungen als FILE-Daten eine grafische DDL-Benutzeroberfläche erzeugt und gespeichert werden, ohne dass bereits vorhandene Firmware geändert werden müsste und ohne dass zusätzliche Änderungen an dem Gerät an sich nötig wären.
  • Auch wenn im obigen Text eine ausführliche Beschreibung zahlreicher verschiedener Ausführungsformen der Erfindung geliefert wurde, sei klargestellt, dass der Bereich der Erfindung vom Wortlaut der Ansprüche definiert wird, die am Schluss dieser Patentschrift stehen. Die ausführliche Beschreibung ist nur als Beispiel aufzufassen und beschreibt nicht jede mögliche Ausführungsform der Erfindung, da die Beschreibung jeder möglichen Ausführungsform nicht sinnvoll, wenn nicht sogar unmöglich wäre. Es könnten zahlreiche alternative Ausführungsformen implementiert werden, für die entweder aktuelle Technologie oder Technologie verwendet werden könnten, die erst nach der Anmeldung dieses Patents entwickelt werden könnte, und die trotzdem im Bereich der Ansprüche liegen würden, durch die diese Erfindung definiert wird.
  • Auch wenn die Technik der Konfigurierung der grafischen DDL-Benutzeroberfläche und ihrer Elemente als Routinen beschrieben wurde, die an einer Workstation oder einem Server implementiert werden können, kann sie auch in Hardware, Firmware usw. implementiert werden und kann von jedem anderen Prozessor implementiert werden, einschließlich von mehreren Prozessoren. Somit können die hierin beschriebenen Elemente in einer Standard-Mehrzweck-CPU oder in speziell entworfener Hardware oder Firmware, wie einer anwendungsspezifischen integrierten Schaltung (ASIC) oder einem anderen kabelgebundenen Gerät, implementiert werden, falls gewünscht. Wenn sie in Software implementiert werden, kann die Software-Routine in einem beliebigen computerlesbaren Speicher gespeichert werden, beispielsweise auf einer Magnetplatte, einer Laserplatte oder einem anderen Speichermedium, in einem RAM oder ROM eines Computers oder Prozessors, in einer beliebigen Datenbank usw.
  • Von daher können beliebige Modifikationen und Variationen an den hierin beschriebenen und dargestellten Techniken und Strukturen vorgenommen werden, ohne vom Gedanken und Bereich der vorliegenden Erfindung abzuweichen. Somit sollte klargeworden sein, dass die hierin beschriebenen Verfahren und Vorrichtungen nur der Erläuterung dienen und den Bereich der Erfindung nicht beschränken.
  • Claims (23)

    1. Verfahren zum Konfigurieren einer Device Description Language(DDL)-Oberfläche auf einem DDL-basierten Host-System in einer Prozessanlage, wobei das Host-System mit mehreren Prozesssteuergeräten verbunden ist, die in der Prozessanlage verwendet werden, wobei das Verfahren umfasst: an einem Host-System Empfangen einer Gerätebeschreibungsidentifikation von einem Ausgewählten von den mehreren Prozesssteuergeräten, wobei die Gerätebeschreibungsidentifikation eine Gerätebeschreibung für das Ausgewählten von den mehreren Prozesssteuergeräten identifiziert, wobei die Gerätebeschreibung Daten und Betriebsabläufe für das Ausgewählte von den mehreren Prozesssteuergeräten umfasst, einschließlich von Variablen, Verfahren, Befehlen, Menüs oder Anzeigeformaten, die mit einem oder mehreren Merkmalen des Ausgewählten von den mehreren Prozesssteuergeräten assoziiert sind; Aktualisieren des Host-Systems mit der Gerätebeschreibung, die durch die empfangene Gerätebeschreibungsidentifikation identifiziert wird, um die Daten und Betriebsabläufe für das Ausgewählte von den mehreren Prozesssteuergeräten, das in der durch die Gerätebeschreibungsidentifikation identifizierten Gerätebeschreibung beschrieben wird, einzubeziehen; Offenlegen von DDL-Menükonstrukten aus der Gerätebeschreibung gegenüber dem Host-System, wobei die DDL-Menükonstrukte vom Host-System als vom Benutzer auswählbare Elemente über eine Konfigurationsoberfläche bereitgestellt werden; und durch das Host-System Hinzufügen eines oder mehrerer Ausgewählter von den offengelegten DDL-Menükonstrukten zu einer grafischen DDL-Benutzeroberfläche als Reaktion auf eine erste Eingabe, durch welche das eine oder die mehreren Ausgewählten von den offengelegten DDL-Menükonstrukten zu der grafischen DDL-Benutzeroberfläche hinzugefügt werden.
    2. Verfahren nach Anspruch 1, wobei das Hinzufügen von Ausgewählten von den offengelegten DDL-Menükonstrukten zu der grafischen DDL-Benutzeroberfläche umfasst: Mappen eines Ausgewählten von den offengelegten DDL-Menükonstrukten auf eine grafische Darstellung des Ausgewählten von den offengelegten DDL-Menükonstrukten innerhalb der grafischen DDL-Benutzeroberfläche und/oder wobei das Hinzufügen von Ausgewählten von den offengelegten DDL-Menükonstrukten zum DDL-Menü umfasst: Mappen eines Ausgewählten von den offengelegten DDL-Menükonstrukten auf einen Wert des Ausgewählten von den offengelegten DDL-Menükonstrukten innerhalb der grafischen DDL-Benutzeroberfläche.
    3. Verfahren nach einem der Ansprüche 1 bis 2, insbesondere nach Anspruch 1, wobei ein oder mehrere Erste von den offengelegten DDL-Menükonstrukten ein Zweites von den offengelegten DDL-Menükonstrukten zur Bedingung haben, wobei das Verfahren ferner umfasst: Präsentieren der offengelegten DDL-Menükonstrukte über ein Anzeigegerät; wobei das Hinzufügen des zweiten Ausgewählten von den offengelegten DDL-Menükonstrukten zu der grafischen DDL-Benutzeroberfläche bewirkt, dass das Anzeigegerät nur das eine oder die mehreren ersten Ausgewählten von den offengelegten DDL-Menükonstrukten für eine anschließende Auswahl präsentiert.
    4. Verfahren nach einem der Ansprüche 1 bis 3, insbesondere nach Anspruch 1, ferner das Speichern der Ausgewählten von den offengelegten DDL-Menükonstrukten, die zur grafischen DDL-Benutzeroberfläche hinzugefügt werden, als DDL-Dateistruktur auf dem Host-System getrennt von der Gerätebeschreibung umfassend und/oder wobei die DDL-Dateistruktur die grafische DDL-Benutzeroberfläche auf die Ausgewählten von den offengelegten DDL-Menükonstrukten, die zur grafischen DDL-Benutzeroberfläche hinzugefügt werden, mappt und dafür ausgelegt ist, die Ausgewählten von den offengelegten DDL-Menükonstrukten, die zur grafischen DDL-Benutzeroberfläche hinzugefügt werden, in eine Anzeige grafischer Darstellungen in der grafischen DDL-Benutzeroberfläche umzuwandeln und/oder ferner das Rekonfigurieren der grafischen DDL-Benutzeroberfläche umfassend, wobei das Rekonfigurieren der grafischen DDL-Benutzeroberfläche umfasst: Offenlegen der Ausgewählten von den DDL-Menükonstrukten, die zur grafischen DDL-Benutzeroberfläche hinzugefügt werden, so dass die Ausgewählten von den offengelegten DDL-Menükonstrukten, die zur grafischen DDL-Benutzeroberfläche hinzugefügt werden, vom Host-System als vom Benutzer auswählbare Elemente über die Konfigurationsoberfläche bereitgestellt werden; und durch das Host-System Löschen von einem oder mehreren von den Ausgewählten von den offengelegten DDL-Menükonstrukten von der grafischen DDL-Benutzeroberfläche als Reaktion auf eine zweite Eingabe, durch welche das eine oder die mehreren Ausgewählten von den offengelegten DDL-Menükonstrukten von der grafischen DDL-Benutzeroberfläche gelöscht werden und/oder ferner das Rekonfigurieren der grafischen DDL-Benutzeroberfläche umfassend, wobei das Rekonfigurieren der grafischen DDL-Benutzeroberfläche umfasst: Offenlegen der Ausgewählten von den DDL-Menükonstrukten, die zur grafischen DDL-Benutzeroberfläche hinzugefügt werden, so dass die Ausgewählten von den offengelegten DDL-Menükonstrukten, die zur grafischen DDL-Benutzeroberfläche hinzugefügt werden, vom Host-System als vom Benutzer auswählbare Elemente über die Konfigurationsoberfläche bereitgestellt werden; und durch das Host-System Ändern eines Wertes von einem oder mehreren von den Ausgewählten von den offengelegten DDL-Menükonstrukten in der grafischen DDL-Benutzeroberfläche als Reaktion auf eine zweite Eingabe, durch die der Wert des einen oder der mehreren Ausgewählten von den offengelegten DDL-Menükonstrukten in der grafischen DDL-Benutzeroberfläche geändert wird.
    5. Verfahren nach einem der Ansprüche 1 bis 4, insbesondere nach Anspruch 4, ferner das Rekonfigurieren der grafischen DDL-Benutzeroberfläche umfassend, wobei das Rekonfigurieren der grafischen DDL-Benutzeroberfläche umfasst: am Host-System Empfangen einer zweiten Gerätebeschreibungsidentifikation von einem zweiten Ausgewählten von den mehreren Prozesssteuergeräten am, wobei die zweite Gerätebeschreibungsidentifikation eine zweite Gerätebeschreibung für das zweite Ausgewählte von den mehreren Prozesssteuergeräten identifiziert, wobei die zweite Gerätebeschreibung Daten und Betriebsabläufe für das zweite Ausgewählte von den mehreren Prozesssteuergeräten umfasst, einschließlich von DDL-Menükonstrukten, die mit dem zweiten Ausgewählten von den mehreren Prozesssteuergeräten assoziiert sind; Offenlegen der DDL-Menükonstrukte aus der zweiten Gerätebeschreibung gegenüber dem Host-System, so dass die DDL-Menükonstrukte vom Host-System als vom Benutzer auswählbare Elemente über die Konfigurationsoberfläche bereitgestellt werden; durch das Host-System Hinzufügen von Ausgewählten von den offengelegten DDL-Menükonstrukten aus der zweiten Gerätebeschreibung zur grafischen DDL-Benutzeroberfläche als Reaktion auf eine zweite Eingabe, durch welche die Ausgewählten von den offengelegten DDL-Menükonstrukten aus der zweiten Gerätebeschreibung des zweiten Ausgewählten von den mehreren Prozesssteuergeräten zu der grafischen DDL-Benutzeroberfläche hinzugefügt werden.
    6. Konfigurationssystem für eine grafische Device Description Language(DDL)-Benutzeroberfläche mit einer DDL-basierten Host-Anwendung, die dafür ausgelegt ist, auf einem Host-System in einer Prozessanlage ausgeführt zu werden, wobei das Host-System mit mehreren Prozesssteuergeräten verbunden ist, die in der Prozessanlage verwendet werden, wobei das Konfigurationssystem für die grafische DDL-Benutzeroberfläche umfasst: einen Prozessor; eine Anzeigeeinheit; eine Datenbank, die funktionsmäßig mit dem Prozessor gekoppelt ist und dafür ausgelegt ist, DDL-Menükonstrukte zu speichern, wobei die DDL-Menükonstrukte aus einer Gerätebeschreibung offengelegt werden, wobei die Gerätebeschreibung Daten und Betriebsabläufe für ein Prozesssteuergerät umfasst, einschließlich von Variablen, Verfahren, Befehlen, Menüs oder Anzeigeformaten, die mit einem oder mehreren Merkmalen des Prozesssteuergeräts assoziiert sind; eine Anzeigenanwendung, die auf einem computerlesbaren Gerät gespeichert ist und dafür ausgelegt ist, auf dem Prozessor ausgeführt zu werden, um eine Anzeige auf der Anzeigeeinheit für die in der Datenbank gespeicherten DDL-Menükonstrukte zu erzeugen, wobei die Anzeige ein Menükonstrukt-Template, das die DDL-Menükonstrukte präsentiert, und ein Oberflächenkonfigurations-Template, das eine grafische DDL-Benutzeroberfläche präsentiert, einschließt, wobei die Anzeigenanwendung dafür ausgelegt ist, auf dem Prozessor ausgeführt zu werden, um eine erste Eingabe zu ermöglichen, durch die verschiedene von den DDL-Menükonstrukten innerhalb des Menükonstrukt-Templates ausgewählt werden, um ein DDL-Menükonstrukt zu spezifizieren, das zu der grafischen DDL-Benutzeroberfläche hinzugefügt werden soll, und um ein grafisches Element, das mit dem ausgewählten DDL-Menükonstrukt assoziiert ist, im Oberflächenkonfigurations-Template zu präsentieren, um die grafische DDL-Benutzeroberfläche zu konfigurieren, wobei die grafische DDL-Benutzeroberfläche vom Host-System bewahrt wird.
    7. Konfigurationssystem für eine grafische DDL-Benutzeroberfläche nach Anspruch 6, wobei das Menükonstrukt-Template einen Navigationsbaum mit mehreren Ordnern einschließt, die verschiedene Gruppen der DDL-Menükonstrukte spezifizieren, wobei die Anzeigeanwendung dafür ausgelegt ist, auf dem Prozessor ausgeführt zu werden, um eine zweite Eingabe zu ermöglichen, durch die verschiedene von den Ordnern innerhalb des Navigationsbaums ausgewählt werden, um Gruppen der DDL-Menükonstrukte zu spezifizieren, die angezeigt werden sollen, und um die DDL-Menükonstrukte, die mit einem auswählbaren Ordner assoziiert sind, im Menükonstrukt-Template zu präsentieren.
    8. Konfigurationssystem für eine grafische DDL-Benutzeroberfläche nach einem der Ansprüche 6 oder 7, insbesondere nach Anspruch 6, wobei ein oder mehrere erste DDL-Menükonstrukte von einem zweiten DDL-Menükonstrukt abhängen, wobei die Anzeigeanwendung dafür ausgelegt ist, auf dem Prozessor ausgeführt zu werden, um als Reaktion auf eine Eingabe, durch die das zweite DDL-Menükonstrukt ausgewählt wird, nur das eine oder die mehreren ersten DDL-Menükonstrukte im Menükonstrukt-Template zur Auswahl zu präsentieren, und dafür ausgelegt ist, eine zweite Eingabe zu ermöglichen, durch die nur die ersten DDL-Menükonstrukte ausgewählt werden, die zur grafischen DDL-Benutzeroberfläche hinzugefügt werden sollen.
    9. Konfigurationssystem für eine grafische DDL-Benutzeroberfläche nach einem der Ansprüche 6 bis 8, insbesondere nach Anspruch 6, wobei die grafische DDL-Benutzeroberfläche vom Host-System als DDL-Dateidatenstruktur bewahrt wird und/oder wobei die DDL-Dateistruktur die grafische DDL-Benutzeroberfläche auf die verschiedenen Ausgewählten von den DDL-Menükonstrukten, die zur grafischen DDL-Benutzeroberfläche hinzugefügt werden, mappt und dafür ausgelegt ist, die verschiedenen Ausgewählten von den DDL-Menükonstrukten, die zur grafischen DDL-Benutzeroberfläche hinzugefügt werden, in eine Anzeige grafischer Darstellungen in der grafischen DDL-Benutzeroberfläche umzuwandeln.
    10. Konfigurationssystem für eine grafische DDL-Benutzeroberfläche nach einem der Ansprüche 6 bis 9, insbesondere nach Anspruch 6, wobei die Anzeige ein Prozesssteuergeräte-Template einschließt, das grafische Darstellungen der mehreren Prozesssteuergeräte präsentiert, und wobei die Anzeigeanwendung dafür ausgelegt ist, auf dem Prozessor ausgeführt zu werden, um eine zweite Eingabe zu ermöglichen, mit der verschiedene von den Prozesssteuergeräten ausgewählt werden, und um die DDL-Menükonstrukte, die mit den Ausgewählten von den Prozesssteuergeräten assoziiert sind, im Menükonstrukt-Template zu präsentieren und/oder wobei die Anzeigeanwendung dafür ausgelegt ist, auf dem Prozessor ausgeführt zu werden, um eine dritte Eingabe zu ermöglichen, durch die ein erstes DDL-Menükonstrukt, das mit einem ersten Ausgewählten von den Prozesssteuergeräten assoziiert ist, ausgewählt wird, das zur grafischen DDL-Benutzeroberfläche hinzugefügt werden soll, und um ein grafisches Element, das mit dem ersten ausgewählten DDL-Menükonstrukt assoziiert ist, im Oberflächenkonfigurations-Template zu präsentieren, um die grafische DDL-Benutzeroberfläche zu konfigurieren, und wobei die Anzeigeanwendung dafür ausgelegt ist, auf dem Prozessor ausgeführt zu werden, um eine vierte Eingabe zu ermöglichen, durch die ein zweites DDL-Menükonstrukt, das mit einem zweiten Ausgewählten von den Prozesssteuergeräten assoziiert ist, ausgewählt wird, das zur grafischen DDL-Benutzeroberfläche hinzugefügt werden soll, und um ein grafisches Element, das mit dem zweiten ausgewählten DDL-Menükonstrukt assoziiert ist, im Oberflächenkonfigurations-Template zu präsentieren, um die grafische DDL-Benutzeroberfläche zu konfigurieren.
    11. Konfigurationssystem für eine grafische DDL-Benutzeroberfläche nach einem der Ansprüche 6 bis 10, insbesondere nach Anspruch 6, ferner umfassend: eine Konfigurationsanwendung für eine grafische DDL-Benutzeroberfläche, die auf einem computerlesbaren Gerät gespeichert ist und die dafür ausgelegt ist, auf dem Prozessor ausgeführt zu werden, um eine Gerätebeschreibungsidentifikation von einer Ausgewählten von mehreren Prozesssteuergeräten zu empfangen, wobei die Gerätebeschreibungsidentifikation die Gerätebeschreibung für das Ausgewählte von den mehreren Prozesssteuergeräten identifiziert, wobei die grafische DDL-Benutzeroberfläche ferner dafür ausgelegt ist, auf dem Prozessor ausgeführt zu werden, um das Host-System mit der Gerätebeschreibung zu aktualisieren, die durch die empfangene Gerätebeschreibungsidentifikation identifiziert wird, und um DDL-Menükonstrukte aus der Gerätebeschreibung des Host-Systems offenzulegenund/oder wobei die Konfigurationsanwendung für die grafische DDL-Benutzeroberfläche dafür ausgelegt ist, auf dem Prozessor ausgeführt zu werden, um ein Ausgewähltes von den offengelegten DDL-Menükonstrukten auf eine grafische Darstellung des Ausgewählten von den offengelegten DDL-Menükonstrukten innerhalb der grafischen DDL-Benutzeroberfläche zu mappen und/oder wobei die Konfigurationsanwendung für die grafische DDL-Benutzeroberfläche dafür ausgelegt ist, auf dem Prozessor ausgeführt zu werden, um ein Ausgewähltes von den offengelegten DDL-Menükonstrukten auf einen Wert des Ausgewählten von den offengelegten DDL-Menükonstrukten innerhalb der grafischen DDL-Benutzeroberfläche zu mappen und/oder wobei die Konfigurationsanwendung für die grafische DDL-Benutzeroberfläche dafür ausgelegt ist, die grafische DDL-Benutzeroberfläche auf die verschiedenen Ausgewählten von den DDL-Menükonstrukten, die zur grafischen DDL-Benutzeroberfläche hinzugefügt werden, zu mappen, und dafür ausgelegt ist, die verschiedenen Ausgewählten von den offengelegten DDL-Menükonstrukten, die zur grafischen DDL-Benutzeroberfläche hinzugefügt werden, in eine Anzeige grafischer Darstellungen in der grafischen DDL-Benutzeroberfläche umzuwandeln.
    12. Konfigurationssystem für eine grafische DDL-Benutzeroberfläche nach einem der Ansprüche 6 bis 11, insbesondere nach Anspruch 6, ferner umfassend: eine Bearbeitungsanwendung für eine grafische DDL-Benutzeroberfläche, die auf einem computerlesbaren Gerät gespeichert ist und die dafür ausgelegt ist, auf dem Prozessor ausgeführt zu werden, um die Ausgewählten von den DDL-Menükonstrukten, die zu der grafischen DDL-Benutzeroberfläche hinzugefügt werden, offenzulegen, wobei die Ausgewählten von den offengelegten DDL-Menükonstrukten, die zur grafischen DDL-Benutzeroberfläche hinzugefügt werden, vom Host-System als vom Benutzer auswählbare Elemente über das Oberflächenkonfigurations-Template bereitgestellt werden, wobei die Bearbeitungsanwendung für die grafische DDL-Benutzeroberfläche ferner dafür ausgelegt ist, auf dem Prozessor ausgeführt zu werden, um eine zweite Eingabe zu ermöglichen, durch die eines oder mehrere von den Ausgewählten von den offengelegten DDL-Menükonstrukten von der grafischen DDL-Benutzeroberfläche gelöscht werden, und um das eine oder die mehreren von den Ausgewählten von den offengelegten DDL-Menükonstrukten als Reaktion auf eine zweite Eingabe, durch die das eine oder die mehreren von den Ausgewählten von den offengelegten DDL-Menükonstrukten von der grafischen DDL-Benutzeroberfläche gelöscht werden, von der grafischen DDL-Benutzeroberfläche zu löschen.
    13. Konfigurationssystem für eine grafische DDL-Benutzeroberfläche nach einem der Ansprüche 6 bis 12, insbesondere nach Anspruch 6, ferner umfassend: eine Bearbeitungsanwendung für eine grafische DDL-Benutzeroberfläche, die auf einem computerlesbaren Gerät gespeichert ist und die dafür ausgelegt ist, auf dem Prozessor ausgeführt zu werden, um die Ausgewählten von den DDL-Menükonstrukten, die zu der grafischen DDL-Benutzeroberfläche hinzugefügt werden, offenzulegen, wobei die Ausgewählten von den offengelegten DDL-Menükonstrukten, die zur grafischen DDL-Benutzeroberfläche hinzugefügt werden, vom Host-System als vom Benutzer auswählbare Elemente über das Oberflächenkonfigurations-Template bereitgestellt werden, wobei die Bearbeitungsanwendung für die grafische DDL-Benutzeroberfläche ferner dafür ausgelegt ist, auf dem Prozessor ausgeführt zu werden, um eine zweite Eingabe zu ermöglichen, durch die ein Wert von einem oder mehreren von den Ausgewählten von den offengelegten DDL-Menükonstrukten in der grafischen DDL-Benutzeroberfläche geändert wird, und um den Wert des einen oder der mehreren von den Ausgewählten von den offengelegten DDL-Menükonstrukten als Reaktion auf eine zweite Eingabe, durch die der Wert des einen oder der mehreren Ausgewählten von den offengelegten DDL-Menükonstrukten in der grafischen DDL-Benutzeroberfläche geändert wird, zu ändern.
    14. Konfigurationssystem für eine grafische DDL-Benutzeroberfläche nach einem der Ansprüche 6 bis 13, insbesondere nach Anspruch 6, ferner umfassend: eine Bearbeitungsanwendung für eine grafische DDL-Benutzeroberfläche, die auf einem computerlesbaren Gerät gespeichert ist und dafür ausgelegt ist, auf dem Prozessor ausgeführt zu werden, um eine zweite Gerätebeschreibungsidentifikation von einem zweiten Ausgewählten von den mehreren Prozesssteuergeräten am Host-System zu empfangen, wobei die zweite Gerätebeschreibungsidentifikation eine zweite Gerätebeschreibung für das zweite Ausgewählte von den mehreren Prozesssteuergeräten identifiziert, wobei die zweite Gerätebeschreibung Daten und Betriebsabläufe für das zweite Ausgewählte von den mehreren Prozesssteuergeräten umfasst, einschließlich von DDL-Menükonstrukten, die mit dem zweiten Ausgewählten von den mehreren Prozesssteuergeräten assoziiert sind, wobei die Bearbeitungsanwendung für die grafische DDL-Benutzeroberfläche ferner dafür ausgelegt ist, die DDL-Menükonstrukte aus der zweiten Gerätebeschreibung dem Host-System gegenüber offenzulegen, wobei die DDL-Menükonstrukte aus der zweiten Gerätebeschreibung vom Host-System als vom Benutzer auswählbare Elemente über das Menükonstrukt-Template bereitgestellt werden, wobei die Bearbeitungsanwendung für die grafische DDL-Benutzeroberfläche ferner dafür ausgelegt ist, eine zweite Eingabe zu ermöglichen, durch die Ausgewählte von den offengelegten DDL-Menükonstrukten aus der zweiten Gerätebeschreibung zu der grafischen DDL-Benutzeroberfläche hinzugefügt werden, und um Ausgewählte von den offengelegten DDL-Menükonstrukten aus der zweiten Gerätebeschreibung als Reaktion auf eine zweite Eingabe, durch welche die Ausgewählten von den offengelegten DDL-Menükonstrukten aus der zweiten Gerätebeschreibung zu der grafischen DDL-Benutzeroberfläche hinzugefügt werden, zu der grafischen DDL-Benutzeroberfläche hinzuzufügen.
    15. Verfahren zum Konfigurieren eines Device Description Language(DDL)-Menüs auf einem DDL-basierten Host-System in einer Prozessanlage, wobei das Host-System mit mehreren Prozesssteuergeräten verbunden ist, die in der Prozessanlage verwendet werden, wobei das Verfahren umfasst: Präsentieren eines Menükonstrukt-Templates, das grafische Darstellungen mehrerer DDL-Menükonstrukte für ein Ausgewähltes von mehreren Prozesssteuergeräten einschließt, und Ermöglichen einer ersten Eingabe, die ein Ausgewähltes von den DDL-Menükonstrukten anfordert, wobei die DDL-Menükonstrukte dem Host-System gegenüber aus der Gerätebeschreibung für das Ausgewählte von den mehreren Prozesssteuergeräten offengelegt werden, wobei die Gerätebeschreibung Daten und Betriebsabläufe für das Ausgewählte von den mehreren Prozesssteuergeräten umfasst, einschließlich von Variablen, Verfahren, Befehlen, Menüs oder Anzeigeformaten, die mit einem oder mehreren Merkmalen des Ausgewählten von den mehreren Prozesssteuergeräten assoziiert sind; als Reaktion auf eine erste Eingabe, durch die eines von den DDL-Menükonstrukten ausgewählt wird, Präsentieren eines Oberflächenkonfigurations-Templates einschließlich einer grafischen Darstellung einer grafischen DDL-Benutzeroberfläche und der grafischen Darstellung des Ausgewählten von den DDL-Menükonstrukten und Ermöglichen einer zweiten Eingabe, durch die das Ausgewählte von den DDL-Menükonstrukten innerhalb der grafischen DDL-Benutzeroberfläche konfiguriert wird; und als Reaktion auf eine zweite Eingabe, die das Ausgewählte von den DDL-Menükonstrukten innerhalb der grafischen DDL-Benutzeroberfläche konfiguriert, Ermöglichen der ersten Eingabe, die ein Ausgewähltes von den DDL-Menükonstrukten anfordert, und Ermöglichen einer dritten Eingabe, mit der die grafische DDL-Benutzeroberfläche einschließlich des konfigurierten DDL-Menükonstrukts als DDL-Dateidatenstruktur am Host-System separat von der Gerätebeschreibung gespeichert wird.
    16. Verfahren nach Anspruch 15, ferner umfassend: Präsentieren eines Menüstil-Templates einschließlich von Darstellungen von DDL-Menüstilen für das Ausgewählte von den mehreren Prozesssteuergeräten und Ermöglichen einer vierten Eingabe, mit der ein Ausgewählter von den DDL-Menüstilen angefordert wird; und als Reaktion auf eine vierte Eingabe, mit der ein DDL-Menüstil ausgewählt wird, Präsentieren des Oberflächenkonfigurations-Templates einschließlich einer grafischen Darstellung der grafischen DDL-Benutzeroberfläche und der grafischen Darstellung des Ausgewählten von den DDL-Menüstilen.
    17. Verfahren nach einem der Ansprüche 15 oder 16, insbesondere nach Anspruch 15, ferner umfassend: Präsentieren eines Prozesssteuergeräte-Templates einschließlich von Darstellungen der mehreren Prozesssteuergeräte und Ermöglichen einer vierten Eingabe, durch die ein Ausgewähltes von den mehreren Prozesssteuergeräten angefordert wird; und Präsentieren des Menükonstrukt-Templates als Reaktion auf eine vierte Eingabe, durch die eines von den mehreren Prozesssteuergeräten ausgewählt wird, und/oder ferner umfassend: als Reaktion auf eine vierte Eingabe, durch die eines von den mehreren Prozesssteuergeräten ausgewählt wird, Abrufen einer Gerätebeschreibungsidentifikation aus dem Ausgewählten von den mehreren Prozesssteuergeräten, wobei die Gerätebeschreibungsidentifikation die Gerätebeschreibung für das Ausgewählte von den mehreren Prozesssteuergeräten identifiziert. Aktualisieren des Host-Systems mit der Gerätebeschreibung, die durch die empfangene Gerätebeschreibungsidentifikation identifiziert wird, um die Daten und Betriebsabläufe für das Ausgewählte von den mehreren Prozesssteuergeräten, das in der durch die Gerätebeschreibungsidentifikation identifizierten Gerätebeschreibung beschrieben wird, einzubeziehen; und Offenlegen der DDL-Menükonstrukte aus der Gerätebeschreibung gegenüber dem Host-System.
    18. Verfahren nach einem der Ansprüche 15 bis 17, insbesondere nach Anspruch 15, ferner umfassend: als Reaktion auf eine erste Eingabe, mit der ein DDL-Menükonstrukt ausgewählt wird, Bestimmen, ob eines oder mehrere von den mehreren DDL-Menükonstrukten von dem Ausgewählten von den DDL-Menükonstrukten abhängt; als Reaktion auf eine Bestimmung, dass eines oder mehrere von den mehreren DDL-Menükonstrukten von dem Ausgewählten von den DDL-Menükonstrukten abhängt, Präsentieren des Menükonstrukt-Templates, das nur die grafischen Darstellungen der abhängigen DDL-Menükonstrukte einschließt, als auswählbare Optionen und Ermöglichen einer vierten Eingabe, die ein Ausgewähltes von den abhängigen DDL-Menükonstrukten anfordert; und als Reaktion auf eine vierte Eingabe, mit der ein abhängiges DDL-Menükonstrukt ausgewählt wird, Präsentieren des Oberflächenkonfigurations-Templates einschließlich einer grafischen Darstellung des Ausgewählten von den DDL-Menükonstrukten und Ermöglichen einer fünften Eingabe, mit der das Ausgewählte von den DDL-Menükonstrukten innerhalb der grafischen DDL-Benutzeroberfläche konfiguriert wird, und/oder ferner umfassend: als Reaktion auf eine Bestimmung, dass eines oder mehrere von den mehreren DDL-Menükonstrukten von dem Ausgewählten von den DDL-Menükonstrukten abhängen, Nichtzulassen der dritten Eingabe, mit der die grafische DDL-Benutzeroberfläche gespeichert werden soll; und Ermöglichen der dritten Eingabe, mit der die grafische DDL-Benutzeroberfläche gespeichert wird, als Reaktion auf eine vierte Eingabe, mit der ein abhängiges DDL-Menükonstrukt ausgewählt wird und/oder ferner umfassend: als Reaktion auf eine Bestimmung, dass eines oder mehrere von den mehreren DDL-Menükonstrukten von dem Ausgewählten von den DDL-Menükonstrukten abhängt, Ermöglichen einer sechsten Eingabe, mit der eine Auswahl keines der abhängigen DDL-Menükonstrukte angefordert wird; und als Reaktion auf eine sechste Eingabe, durch die kein abhängiges DDL-Menükonstrukt ausgewählt wird, Präsentieren des Menükonstrukt-Templates einschließlich von grafischen Darstellungen der mehreren DDL-Menükonstrukte für das Ausgewählte von den mehreren Prozesssteuergeräten und Ermöglichen der ersten Eingabe, durch die ein Ausgewähltes von den DDL-Menükonstrukten angefordert wird und/oder wobei ein DDL-Menükonstrukt von einem anderen DDL-Menükonstrukt abhängt, das auf einem DDL-Konditional basiert, wobei ein DDL-Konditional die Beziehung zwischen einem DDL-Menükonstrukt und einem anderen DDL-Menükonstrukt diktiert.
    19. Verfahren nach einem der Ansprüche 15 bis 18, insbesondere nach Anspruch 15, wobei die mehreren DDL-Menükonstrukte für das Ausgewählte von den mehreren Prozesssteuergeräten mehrere erste DDL-Menükonstrukte für das Ausgewählte von den mehreren Prozesssteuergeräten umfassen, wobei das Verfahren ferner umfasst: als Reaktion auf eine erste Eingabe, durch die ein DDL-Menükonstrukt aus den mehreren ersten DDL-Konstrukten ausgewählt wird, Präsentieren des Menükonstrukt-Templates einschließlich von grafischen Darstellungen mehrerer zweiter DDL-Menükonstrukte für das Ausgewählte von den mehreren Prozesssteuergeräten und Ermöglichen einer vierten Eingabe, durch die ein Ausgewähltes von den mehreren zweiten DDL-Menükonstrukten angefordert wird; und als Reaktion auf eine vierte Eingabe, mit der eines von den mehreren zweiten DDL-Menükonstrukten ausgewählt wird, Präsentieren des Oberflächenkonfigurations-Templates einschließlich einer grafischen Darstellung des Ausgewählten von den mehreren zweiten DDL-Menükonstrukten und Ermöglichen einer fünften Eingabe, durch die das Ausgewählte von den mehreren zweiten DDL-Menükonstrukten innerhalb der grafischen DDL-Benutzeroberfläche konfiguriert wird.
    20. Verfahren nach einem der Ansprüche 15 bis 19, insbesondere nach Anspruch 15, ferner umfassend: als Reaktion auf eine vierte Eingabe, durch die eine grafische Darstellung eines DDL-Menükonstrukts, das im Oberflächenkonfigurations-Template dargestellt wird, ausgewählt wird, Ermöglichen des Löschens des ausgewählten DDL-Menükonstrukts von der grafischen DDL-Benutzeroberfläche und Präsentieren des Oberflächenkonfigurations-Templates einschließlich der grafischen Darstellung der grafischen DDL-Benutzeroberfläche ohne die grafische Darstellung des gelöschten DDL-Menükonstrukts .
    21. Verfahren nach einem der Ansprüche 15 bis 20, insbesondere nach Anspruch 15, ferner umfassend: als Reaktion auf eine vierte Eingabe, durch die eine grafische Darstellung eines DDL-Menükonstrukts ausgewählt wird, das im Oberflächenkonfigurations-Template präsentiert wird, Ermöglichen einer fünften Eingabe, durch welche der Wert der ausgewählten grafischen Darstellung des DDL-Menükonstrukts geändert wird; und Ändern des Wertes des DDL-Menükonstrukts in der grafischen DDL-Benutzeroberfläche als Reaktion auf eine fünfte Eingabe, mit welcher der Wert des DDL-Menükonstrukts in der grafischen DDL-Benutzeroberfläche geändert wird.
    22. Verfahren nach einem der Ansprüche 15 bis 21, insbesondere nach Anspruch 15, ferner umfassend: Präsentieren des Menükonstrukt-Templates, das grafische Darstellungen mehrerer zweiter DDL-Menükonstrukte für ein zweites Ausgewähltes von den mehreren Prozesssteuergeräten einschließt, und Ermöglichen einer vierten Eingabe, die ein Ausgewähltes von den zweiten DDL-Menükonstrukten anfordert, wobei die zweiten DDL-Menükonstrukte dem Host-System gegenüber aus der Gerätebeschreibung für das ausgewählte Zweite von den mehreren Prozesssteuergeräten offengelegt werden, wobei die Gerätebeschreibung Daten und Betriebsabläufe für das ausgewählte Zweite von den mehreren Prozesssteuergeräten umfasst, einschließlich von Variablen, Verfahren, Befehlen, Menüs oder Anzeigeformaten, die mit einem oder mehreren Merkmalen des Ausgewählten von den mehreren Prozesssteuergeräten assoziiert sind; als Reaktion auf eine vierte Eingabe, mit der eines von den zweiten DDL-Menükonstrukten ausgewählt wird, Präsentieren des Oberflächenkonfigurations-Templates einschließlich einer grafischen Darstellung des Ausgewählten von den zweiten DDL-Menükonstrukten und Ermöglichen einer fünften Eingabe, durch die das Ausgewählte von den zweiten DDL-Menükonstrukten innerhalb der grafischen DDL-Benutzeroberfläche konfiguriert wird.
    23. Computer-lesbares Speichermedium, welches Instruktionen enthält, die mindestens einen Prozessor dazu veranlassen, ein Verfahren nach einem der Ansprüche 15 bis 22 zu implementieren, wenn die Instruktionen durch mindestens einen Prozessor ausgeführt werden.
    DE102017124551.0A 2016-10-21 2017-10-20 Vorrichtung und verfahren für dynamische gerätebeschreibungssprachmenüs Pending DE102017124551A1 (de)

    Applications Claiming Priority (2)

    Application Number Priority Date Filing Date Title
    US15/299,679 2016-10-21
    US15/299,679 US10359911B2 (en) 2016-10-21 2016-10-21 Apparatus and method for dynamic device description language menus

    Publications (1)

    Publication Number Publication Date
    DE102017124551A1 true DE102017124551A1 (de) 2018-04-26

    Family

    ID=60481644

    Family Applications (1)

    Application Number Title Priority Date Filing Date
    DE102017124551.0A Pending DE102017124551A1 (de) 2016-10-21 2017-10-20 Vorrichtung und verfahren für dynamische gerätebeschreibungssprachmenüs

    Country Status (5)

    Country Link
    US (1) US10359911B2 (de)
    JP (1) JP7239248B2 (de)
    CN (1) CN107976965B (de)
    DE (1) DE102017124551A1 (de)
    GB (1) GB2556454B (de)

    Families Citing this family (14)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    US20200209822A1 (en) * 2018-12-28 2020-07-02 Johnson Controls Technology Company Systems and methods for automatic interaction with a flexible number of devices
    US9703276B2 (en) 2014-04-11 2017-07-11 Johnson Controls Technology Company Systems and methods for creating and using equipment definitions
    KR101791335B1 (ko) * 2016-03-25 2017-10-27 엘에스산전 주식회사 Hmi시스템
    DE102016124326A1 (de) * 2016-12-14 2018-06-14 Endress+Hauser Conducta Gmbh+Co. Kg Verfahren zum Betreiben eines Messumformers und entsprechender Messumformer
    DE102017109711A1 (de) * 2017-05-05 2018-11-08 Endress+Hauser Conducta Gmbh+Co. Kg Verfahren zur Aufstellung einer Menüstruktur auf einem Messumformer und Messumformer
    JP7063009B2 (ja) * 2018-03-01 2022-05-09 オムロン株式会社 表示装置、画面生成方法、および画面生成プログラム
    US10812967B2 (en) * 2018-03-29 2020-10-20 Honeywell International Inc. Wireless field devices having embedded device description data
    JP6746003B2 (ja) * 2018-06-22 2020-08-26 三菱電機株式会社 管理装置、管理方法及びプログラム
    US20200210869A1 (en) * 2018-12-28 2020-07-02 Siemens Aktiengesellschaft Gateway and method for transforming a description of an industrial process equipment into a data information model
    US11340921B2 (en) * 2019-06-28 2022-05-24 Snap Inc. Contextual navigation menu
    US11281684B2 (en) * 2019-12-17 2022-03-22 Fisher-Rosemount Systems, Inc. Electronic device description language (EDDL) search and navigation assistant
    US11023659B1 (en) 2020-07-09 2021-06-01 Jamison HILL Systems and methods for generating a style configuration file with and without parameters
    US11368587B1 (en) * 2021-02-18 2022-06-21 Capital One Services, Llc Systems and methods for generating customized customer service menu
    CN113949601B (zh) * 2021-11-12 2023-04-28 杭州和利时自动化有限公司 一种控制器站间通信方法、装置及计算机可读存储介质

    Family Cites Families (24)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    US5251125A (en) * 1990-04-30 1993-10-05 Eaton Corporation User interface for a process control device
    JP2007536634A (ja) 2004-05-04 2007-12-13 フィッシャー−ローズマウント・システムズ・インコーポレーテッド プロセス制御システムのためのサービス指向型アーキテクチャ
    US20060218506A1 (en) * 2005-03-23 2006-09-28 Edward Srenger Adaptive menu for a user interface
    US7665028B2 (en) * 2005-07-13 2010-02-16 Microsoft Corporation Rich drag drop user interface
    US7636889B2 (en) * 2006-01-06 2009-12-22 Apple Inc. Controlling behavior of elements in a display environment
    US8266602B2 (en) * 2006-05-31 2012-09-11 Honeywell International Inc. Apparatus and method for converting between device description languages in a process control system
    DE102007047061B4 (de) * 2007-10-01 2019-08-08 Endress + Hauser Process Solutions Ag Verfahren zum Bedienen von Feldgeräten der Prozessautomatisierungstechnik mit einem geräteunabhängigen Bedienprogramm
    US9207666B2 (en) 2010-08-31 2015-12-08 Fisher-Rosemount Systems, Inc. Methods and apparatus to display localized process control objects
    US8717374B2 (en) 2010-09-13 2014-05-06 Fisher-Rosemount Systems, Inc. Methods and apparatus to display process control information
    JP5370376B2 (ja) 2011-01-13 2013-12-18 横河電機株式会社 機器情報表示装置、機器情報表示プログラム、及び記録媒体
    DE102011008941A1 (de) * 2011-01-19 2012-07-19 Vega Grieshaber Kg System zur Visualisierung von Statusinformationen von Feldgeräten
    US9182757B2 (en) 2011-03-30 2015-11-10 Fisher-Rosemount Systems, Inc. Methods and apparatus to transmit device description files to a host
    US8893261B2 (en) * 2011-11-22 2014-11-18 Vmware, Inc. Method and system for VPN isolation using network namespaces
    GB2513709B (en) * 2013-03-15 2021-06-16 Fisher Rosemount Systems Inc Method and apparatus for managing a work flow in a process plant
    US20160132046A1 (en) * 2013-03-15 2016-05-12 Fisher-Rosemount Systems, Inc. Method and apparatus for controlling a process plant with wearable mobile control devices
    GB2513706B (en) 2013-03-15 2020-09-23 Fisher Rosemount Systems Inc Method for initiating or resuming a mobile control session in a process plant
    US10691281B2 (en) * 2013-03-15 2020-06-23 Fisher-Rosemount Systems, Inc. Method and apparatus for controlling a process plant with location aware mobile control devices
    CN104679498A (zh) * 2013-12-02 2015-06-03 艾默生网络能源有限公司 一种生成组态监控界面的方法及装置
    US10139998B2 (en) * 2014-10-08 2018-11-27 Weebly, Inc. User interface for editing web content
    CN104932456B (zh) * 2015-04-27 2019-02-19 小米科技有限责任公司 智能场景实现方法和装置、智能终端及控制设备
    CN105278339B (zh) * 2015-10-30 2021-11-16 青岛海尔智能家电科技有限公司 复合家电的子设备描述信息生成、控制方法和装置
    CN105487389B (zh) * 2015-11-17 2020-02-07 小米科技有限责任公司 控制智能设备的方法和装置
    CN105700365B (zh) * 2016-01-22 2018-12-07 深圳市飞比电子科技有限公司 移动终端的家电控制界面的生成方法和装置
    CN105975390A (zh) * 2016-04-28 2016-09-28 浪潮电子信息产业股份有限公司 一种基于复杂测试场景下的恢复测试数据方法

    Also Published As

    Publication number Publication date
    GB2556454A (en) 2018-05-30
    CN107976965A (zh) 2018-05-01
    CN107976965B (zh) 2022-08-23
    US10359911B2 (en) 2019-07-23
    JP7239248B2 (ja) 2023-03-14
    GB2556454B (en) 2022-12-28
    JP2018106687A (ja) 2018-07-05
    US20180113573A1 (en) 2018-04-26
    GB201717314D0 (en) 2017-12-06

    Similar Documents

    Publication Publication Date Title
    DE102017124551A1 (de) Vorrichtung und verfahren für dynamische gerätebeschreibungssprachmenüs
    DE60223593T2 (de) Graphische konfiguration von programmaktievirungsbeziehungen
    DE102018124420A1 (de) Systeme und verfahren zur erleichterung des grafischen anzeigedesign-workflows in einer prozesssteuerungsanlage
    EP2789145B1 (de) Vorrichtung zur bedienung von mindestens einem feldgerät der automatisierungstechnik
    DE60207155T2 (de) Objektorientiertes Internetschnittstellensystem für eine industrielle Steuereinrichtung
    DE112012006925B4 (de) Systemkonstruktions-Unterstützungswerkzeug und System
    DE112005001031B4 (de) Grafisches Bildschirmkonfigurationsgerüst für vereinheitlichte Prozesssteuerungssystemoberfläche
    DE112013004915T5 (de) Konfigurierbare User-Displays in einem Prozessleitsystem
    DE102010037702A1 (de) Dynamisch verknüpfte grafische Nachrichten für Prozesssteuerungssysteme
    JP7412117B2 (ja) プロセスプラント内のフィールド装置の一括立上げ
    DE102010038146A1 (de) Verfahren zum Auswählen von Formen in einer Grafikanzeige
    DE102015100024A1 (de) Wiederverwendbare Grafikelemente mit schnell bearbeitungsfähigen Merkmalen zur Verwendung in Benutzeranzeigen von Anlagenüberwachungssystemen
    DE102011001460A1 (de) Verfahren und Gerät für eine datengesteuerte Schnittstelle basierend auf Relationen zwischen Prozesssteuerungsetiketten
    DE102010036914A1 (de) Systemkonfiguration unter Verwendung von Vorlagen
    DE10049025A1 (de) Process control configuration system for use with an AS-inferface device network
    DE102010037750A1 (de) Dynamische Hyperlinks für Prozessregelsysteme
    DE10394033T5 (de) Verfahren und Vorrichtung zum Importieren von Vorrichtungsdaten in ein in einer Prozessanlage verwendetes Datenbanksystem
    DE102017117038A1 (de) Anlagenbausystem mit integrierter simulation und kontrollsystem-konfiguration
    DE102018124414A1 (de) Systeme und verfahren zur einfachen entwicklung der grafischen anzeigekonfiguration in einer prozesskontrollanlage
    DE102010036511A1 (de) Prozesssteuerungssystem mit integrierten externen Datenquellen
    DE10051645A1 (de) Verfahren und Vorrichtung zur Versionskontrolle und Protokollierung in einem Prozesssteuersystem
    DE102015108243A1 (de) Verfahren und Vorrichtung zur Konfiguration von Prozesssteuerungssystemen basierend auf generischen Prozesssystembibliotheken
    DE102015122002A1 (de) Verfahren und Apparatur zur Bereitstellung einer rollenbasierten Benutzerschnittstelle
    DE102018124358A1 (de) Systeme und verfahren zur grafischen konfigurationsdesignprüfung in einer prozessanlage
    DE10250836A1 (de) System und Verfahren zum Zugreifen auf entfernte Lesezeichenlisten und Verwenden derselben

    Legal Events

    Date Code Title Description
    R012 Request for examination validly filed