DE102005058218A1 - Verfahren und Vorrichtung zur Erzeugung von Dialogen für ein Bedien- und Beobachtungssystem - Google Patents

Verfahren und Vorrichtung zur Erzeugung von Dialogen für ein Bedien- und Beobachtungssystem Download PDF

Info

Publication number
DE102005058218A1
DE102005058218A1 DE200510058218 DE102005058218A DE102005058218A1 DE 102005058218 A1 DE102005058218 A1 DE 102005058218A1 DE 200510058218 DE200510058218 DE 200510058218 DE 102005058218 A DE102005058218 A DE 102005058218A DE 102005058218 A1 DE102005058218 A1 DE 102005058218A1
Authority
DE
Germany
Prior art keywords
user interface
scheme
dialogue
control
interface language
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.)
Ceased
Application number
DE200510058218
Other languages
English (en)
Inventor
Marc Holz
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.)
Siemens AG
Original Assignee
Siemens AG
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 Siemens AG filed Critical Siemens AG
Priority to DE200510058218 priority Critical patent/DE102005058218A1/de
Publication of DE102005058218A1 publication Critical patent/DE102005058218A1/de
Ceased legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/30Creation or generation of source code
    • G06F8/38Creation or generation of source code for implementing user interfaces

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • User Interface Of Digital Computer (AREA)

Abstract

Durch die Erfindung wird ein verbessertes Verfahren zur Erzeugung eines funktionsfähigen Dialogs für ein Bedien- und Beobachtungssystem geschaffen, wobei der Dialog aus mindestens einem Bedienelement besteht, wobei in einem Lasten- oder Pflichtenheft der Name und der Typ des mindestens einen Bedienelements spezifiziert sind und wobei der Name und der Typ des mindestens einen Bedienelements in einem vorgegebenen ersten Schema angeordnet werden und wobei ein zweites Schema einer Benutzeroberflächensprache aus dem ersten Schema erzeugt wird. Dabei weist das zweite Schema die dem Typ des mindestens einen Bedienelements entsprechenden Steuerzeichen auf, und ferner weist das zweite Schema Steuerzeichen zur Zuordnung des Namens zu dem Bedienelement auf. Der Name und der Typ des mindestens einen Bedienelements werden in das zweite Schema der Benutzeroberflächensprache integriert und es folgt eine Konversion des zweiten Schemas in eine Datei mit einem Format der Benutzeroberflächensprache. Die Datei mit dem Format der Benutzeroberflächensprache wird ausgeführt, wobei der Dialog auf einer Benutzeroberfläche, die zur Benutzeroberflächensprache kompatibel ist, angezeigt wird, wodurch der Dialog funktionsfähig wird.

Description

  • Verfahren und Vorrichtung zur Erzeugung von Dialogen für ein Bedien- und Beobachtungssystem Die Erfindung betrifft ein Verfahren und eine Vorrichtung zur Erzeugung von funktionsfähigen Dialogen für ein Bedien- und Beobachtungssystem.
  • Für ein Automatisierungssystem, z. B. zur Durchführung eines verfahrenstechnischen oder fertigungstechnischen Prozesses, z. B. für eine Energieerzeugungsanlage oder für eine Logistikanlage wird in der Regel zur Beobachtung bzw. zur Steuerung ein Bedien- und Beobachtungssystem verwendet. Dieses weist einen oder mehrere Dialoge auf. Die Dialoge werden z. B. verwendet, um einzelne Abläufe in einem verfahrenstechnischen Prozess verfolgen zu können, oder um eine Logistikanlage zu überwachen und auf aktuellem Stand zu halten.
  • Die Dialoge werden in der Regel auf einer graphischen Benutzeroberfläche des Bedien- und Beobachtungssystem visualisiert. Ein Dialog besteht dabei aus einem oder mehreren Bedienelementen, wie z. B. Fenstern, Knöpfen, Textfenstern usw. Ein Benutzer kann somit über die einzelnen Bedienelemente eines Dialoges das Automatisierungssystem bedienen, steuern und warten.
  • Bei der Planung eines Bedien- und Beobachtungssystems werden die Dialoge, die für das Bedien- und Beobachtungssystem benötigt werden, in einem Lasten- bzw. Pflichtenheft spezifiziert. Im Lasten- oder Pflichtenheft wird z.B. festgelegt, welche Bedienelemente ein Dialog enthalten muss, d.h. wie der Dialog aufgebaut ist. Des Weiteren wird die Bedien- und Anzeigelogik des Dialogs festgelegt.
  • Die Spezifikationen der Dialoge erfolgen im Lasten- bzw. Pflichtenheft mittels so genannter Parameter, mit denen die einzelnen jeweils in einem Dialog enthaltenen Bedienelemente spezifiziert werden. Ein Parameter ist z.B. der Typ, der einem Bedienelement zugewiesen wird oder ein anderer Parameter ist z.B. der Name, der einem Bedienelement zugewiesen wird.
  • Bei der Implementierung eines Dialogs in das Bedien- und Beobachtungssystem muss sichergestellt werden, dass dessen Inhalt, Aufbau und dessen Bedien- und Anzeigelogik mit den entsprechenden Spezifikationen im Lasten- oder Pflichtenheft übereinstimmen. Dabei ist ein Dialog funktionsfähig, wenn er graphisch auf der Benutzeroberfläche dargestellt wird, und wenn dessen Inhalt, Aufbau und Bedien- und Anzeigelogik mit den Spezifikationen im Lasten- oder Pflichtenheft übereinstimmen.
  • Je mehr Dialoge und dazugehörige Parameter im Lasten- oder Pflichtenheft definiert sind, desto aufwendiger ist die Übernahme der Parameter für die Entwicklung funktionsfähiger Dialoge des Bedien- und Beobachtungssystems und desto schwieriger ist eine Überprüfung auf Abweichungen.
  • Nach dem Stand der Technik wird ein Dialog basierend auf den Spezifikationen bzw. den Parametern aus dem Lasten- oder Pflichtenheft manuell erstellt. Alternativ werden parallel zum Lasten- oder Pflichtenheft Dokumentparameterlisten definiert, aus denen bei Erstellung der Dialoge Parameter kopiert werden.
  • Der Erfindung liegt die Aufgabe zu Grunde, ein verbessertes Verfahren und eine verbesserte Vorrichtung zur Erzeugung von Dialogen für ein Bedien- und Beobachtungssystem anzugeben.
  • Die der Erfindung zu Grunde liegenden Aufgaben werden jeweils mit den Merkmalen der unabhängigen Patentansprüche gelöst. Ausführungsformen der Erfindung sind in den abhängigen Patentansprüchen angegeben.
  • Durch die Erfindung wird ein verbessertes Verfahren zur Erzeugung eines funktionsfähigen Dialogs für ein Bedien- und Beobachtungssystem geschaffen, wobei der Dialog aus mindestens einem Bedienelement besteht, wobei in einem Lasten- oder Pflichtenheft der Name und der Typ des mindestens einen Bedienelements spezifiziert sind, und wobei der Name und der Typ des mindestens einen Bedienelements in einem vorgegebenen ersten Schema angeordnet werden und wobei ein zweites Schema einer Benutzeroberflächensprache aus dem ersten Schema erzeugt wird. Dabei weist das zweite Schema Steuerzeichen zur Visualisierung des mindestens einen Bedienelements gemäß dem Typ auf, und ferner weist das zweite Schema Steuerzeichen zur Zuordnung des Namens zu dem Bedienelement auf. Der Name und der Typ des mindestens einen Bedienelements werden in das zweite Schema der Benutzeroberflächensprache integriert. Es folgt eine Konversion des zweiten Schemas in eine Datei mit einem Format der Benutzeroberflächensprache. Die Datei mit dem Format der Benutzeroberflächensprache wird ausgeführt, wobei der Dialog auf einer Benutzeroberfläche angezeigt wird, wodurch der Dialog funktionsfähig wird. Die Benutzeroberfläche ist dabei zur Benutzeroberflächensprache kompatibel.
  • Nach der Ermittlung des Namens und des Typs des Bedienelements aus dem Lasten- oder Pflichtenheft werden beispielsweise der Name und der Typ in einem vorgegebenen ersten Schema angeordnet. Aus dem ersten Schema wird ein zweites Schema erzeugt in das der Name und der Typ des Bedienelements integriert werden. Dabei enthält das zweite Schema Steuerzeichen, so dass nach Umwandlung des zweiten Schemas in eine Datei mit dem Format der Benutzeroberflächensprache das Bedienelement bei der Ausführung der Datei entsprechend seinem in Lasten- oder Pflichtenheft definierten Typ dargestellt wird.
  • Das erfindungsgemäße Verfahren ist besonders vorteilhaft einsetzbar bei der Erstellung von Dialogen während der Erstellung des Lastenhefts, also in der so genannten Lastenheftphase.
  • In der Lastenheftphase können in einfacher Weise Änderungen der dem Dialog zugrunde liegenden Parameter vorgenommen werden. Da mit dem Verfahren schon während der Lastenheftphase funktionsfähige Dialoge erstellt werden können, können somit während der Lastenheftphase die Änderungen anhand funktionsfähiger Dialoge überprüft werden.
  • Darüber hinaus kann die Möglichkeit der Dialogerzeugung während der Lastenheftphase die Gesamtdauer, die für die Erstellung des Bedien- und Beobachtungssystems benötigt wird, verkürzt werden. Dadurch wird eine Kosteneinsparung erzielt.
  • Ein anderer Vorteil ist, dass zu jedem Zeitpunkt während der Erstellung des Bedien- und Beobachtungssystems ein aktueller Stand der Dialoge erzeugt werden kann.
  • Nach einer Verfahrensvariante wird die Datei in einer Datenbank gespeichert. Das hat den Vorteil, dass die funktionsfähigen Dialoge auf einem Computersystem an irgendeinem Standort erzeugt werden können, und dass diese zu einem späteren Zeitpunkt auf ein Bedien- und Beobachtungssystem, das an einem anderen, möglicherweise weit entfernten Standort, z.B. mittels Internet oder Intranet, übertragen werden können.
  • Nach einer vorteilhaften Verfahrensvariante wird das zweite Schema in mehrere Dateien mit Formaten von verschiedenen Benutzeroberflächensprachen konvertiert. Anschließend werden die mehreren Dateien in einer Datenbank gespeichert.
  • Dies hat den Vorteil, dass die Dialoge für unterschiedliche Arten von Bedien- und Beobachtungssystemen (z. B. HMI-Panel oder auch Mobiltelefone) erstellt werden können und bei Bedarf die Dialoge auf die gewünschten Bedien- und Beobachtungssysteme geladen werden können.
  • Nach einer Verfahrensvariante werden im Lasten- oder Pflichtenheft weitere Parameter des mindestens einen Bedienelements spezifiziert. Die weiteren Parameter werden in dem vorgegebe nen ersten Schema angeordnet und das zweite Schema weist Steuerzeichen zur Zuordnung der weiteren Parameter zu dem Bedienelement auf.
  • Ein weiterer Parameter ist z.B. Text mit dessen Hilfe ein Bedienelement für einen Benutzer näher spezifiziert wird.
  • Dieser Parameter tritt typischerweise dann auf, wenn der Typ des dazugehörigen Bedienelements ein Textfeld ist. Ein anderer weiterer Parameter ist z.B. die Position an der das Bedienelement auf der graphischen Benutzeroberfläche dargestellt werden soll. Die Position ist typischerweise in Form von Koordinaten spezifiziert. Das zweite Schema weist Steuerzeichen auf, so dass die Parameter entsprechend ihrer Bedeutung dem Bedienelement zugeordnet werden. Spezifiziert z.B. der weitere Parameter die Position des Bedienelements, dann wird das zweite Schema so erzeugt, dass nach der Ausführung der aus dem zweiten Schema generierten Datei das Bedienelement, dessen Position spezifiziert ist, an der entsprechenden Position auf der Benutzeroberfläche dargestellt wird.
  • Nach einer Verfahrensvariante besteht der Dialog aus mindestens zwei Bedienelementen, wobei für jedes Bedienelement der Name, der Typ und weitere Parameter im Lasten- oder Pflichtenheft vorgegeben sind, wobei ferner für den Dialog im Lasten- oder Pflichtenheft eine Bedien- und Anzeigelogik vorgegeben ist, wobei die Namen, die Typen und die weiteren Parameter der Bedienelemente gemäß der Bedien- und Anzeigelogik des Dialogs im vorgegebenen ersten Schema angeordnet werden.
  • Nach einer Verfahrensvariante entspricht das vorgegebene erste Schema einer Tabelle, wobei in jeder Zeile der Tabelle ein Bedienelement des Dialogs mit seinem Namen, seinem Typ und den weiteren Parametern spezifiziert wird. Dabei bestimmt die Anordnung der Spezifikationen der Bedienelemente in der Tabelle die Bedien- und Anzeigelogik des Dialogs.
  • Nach einer Verfahrensvariante entspricht das zweite Schema einem Schema der Extensible Markup Language (XML) und die Steuerzeichen entsprechen ferner XML-Knoten.
  • Nach einer Verfahrensvariante weist das Verfahren ferner den Schritt der Konversion des zweiten Schemas im XML Format in eine Datei mit dem Format der Extensible Application Markup Language (XAML) auf. Eine Datei im XAML Format kann direkt von z.B. Microsoft Windows XP SP2 oder den Nachfolgeprodukten wie etwa Microsoft Windows Vista ausgeführt werden, wobei die im XAML Format spezifizierten Dialoge graphisch dargestellt werden. Durch eine einfache Konversion, z.B. mittels Extensible Stylesheet Language Transformation (XSLT), kann also eine XML Datei so umgewandelt werden, dass die darin enthaltenen Daten direkt graphisch visualisiert werden können.
  • In einem anderen Aspekt betrifft die Erfindung ein Computerprogrammprodukt mit computerausführbaren Instruktionen, um das erfindungsgemäße Verfahren auszuführen.
  • In einem weiteren Aspekt betrifft die Erfindung eine Vorrichtung zur Erzeugung eines funktionsfähigen Dialogs für ein Bedien- und Beobachtungssystem, wobei der Dialog aus mindestens einem Bedienelement besteht, wobei in einem Lasten- oder Pflichtenheft der Name und der Typ des mindestens einen Bedienelements spezifiziert sind, und wobei die Vorrichtung Mittel zur Anordnung des Namens und des Typs des mindestens einen Bedienelements in einem vorgegebenen ersten Schema und Mittel zur Erzeugung eines zweiten Schemas einer Benutzeroberflächensprache aus dem ersten Schema aufweist.
  • Dabei weist das zweite Schema Steuerzeichen zur Visualisierung des mindestens einen Bedienelements gemäß dem Typ auf, und ferner weist das zweite Schema Steuerzeichen zur Zuordnung des Namens zu dem Bedienelement auf. Die Vorrichtung weist ferner Mittel zur Integration des Namens und des Typs des mindestens einen Bedienelements in das zweite Schema der Benutzeroberflächensprache auf, sowie Mittel zur Konversion des zweiten Schemas in eine Datei mit einem Format der Benutzeroberflächensprache. Darüber hinaus weist die Vorrichtung Mittel zur Ausführung der Datei mit dem Format der Benutzeroberflächensprache auf, wobei der Dialog angezeigt wird.
  • Bevorzugte Ausführungsformen der Erfindung werden nachfolgend anhand der Zeichnungen näher erläutert.
  • 1 zeigt ein Blockdiagramm eines Computersystems, das zur Erzeugung eines funktionsfähigen Dialogs verwendet wird,
  • 2 zeigt ein Flussdiagramm eines Verfahrens zur Erzeugung eines funktionsfähigen Dialogs,
  • 3 zeigt ein vorgegebenes erstes Schema,
  • 4 zeigt vereinfacht wie das zweite Schema aus dem ersten Schema erzeugt wird aus Sicht eines Benutzers.
  • 5 zeigt die markierten Spezifikationen, für die ein Dialog erstellt wird,
  • 6 zeigt die in einem XML-Schema eingebetteten Spezifikationen,
  • 7 zeigt den Schritt zur Konversion des XML-Schemas in ein XAML-Schema,
  • 8 zeigt das vorgegebene erste Schema mit dem dazugehörigen Dialog.
  • 1 zeigt ein Blockdiagramm eines Computersystems 100, das zur Erzeugung eines funktionsfähigen Dialogs 102 verwendet wird. Das Computersystem 100 weist dabei einen Mikroprozessor 114, ein Eingabegerät 118, einen flüchtigen Speicher 120, ei nen nicht-flüchtigen Speicher 122 sowie einen Monitor 126 auf.
  • Der Mikroprozessor 114 führt ein Computerprogrammprodukt 112 mit Instruktionen zur Durchführung des erfindungsgemäßen Verfahrens aus. Zusätzlich führt der Mikroprozessor eine Benutzeroberflächensprache 110 aus. Verfahrensgemäß wird der Name 106 und der Typ 107 eines zu erstellenden Bedienelements 104 in ein auf der Benutzeroberfläche 116 vorgegebenes erstes Schema 124 eingebettet. Mittels des Computerprogrammprodukts 112 wird ein zweites Schema 128 erzeugt. Das zweite Schema 128 enthält Steuerzeichen 130 so dass das Bedienelement 104 entsprechend seinem Typ 107 in einer späteren Visualisierung dargestellt wird und Steuerzeichen 132, so dass dem Bedienelement 104 bei der Visualisierung der Name 106 zugeordnet wird. Dies wird weiter unten näher erläutert. Der Name 106 bzw. der Typ 107 wird innerhalb der Steuerzeichen 132 bzw. 130 integriert. Anschließend wird das zweite Schema 128 in eine Datei 108 mit einem Format der Benutzeroberflächensprache 110 konvertiert.
  • Die Datei wird auf dem nicht-flüchtigen Speicher 122 oder alternativ auf dem flüchtigen Speicher 120 gespeichert.
  • Die Datei 108 mit dem Format der Benutzeroberflächensprache 110 wird ausgeführt, wodurch der Dialog 102 funktionsfähig wird, d.h. wodurch der Dialog 102 mit dem Bedienelement 104 auf der Benutzeroberfläche 116 visualisiert wird.
  • 2 zeigt ein Flussdiagramm eines Verfahrens zur Erzeugung eines funktionsfähigen Dialogs. In Schritt 200 werden die Spezifikationen des mindestens einen Bedienelements des Dialogs aus dem Lasten- oder Pflichtenheft ermittelt und im ersten vorgegebenen Schema angeordnet. Dabei umfasst der Begriff Spezifikation den Typ, den Namen, die Position und weitere Parameter, die zur Beschreibung des Bedienelements verwendet werden. In Schritt 202 wird das zweite Schema erzeugt, in dessen Steuerzeichen die Spezifikationen integriert werden.
  • In Schritt 204 wird das zweite Schema in eine Datei konvertiert. In Schritt 206 wird die Datei ausgeführt. Durch die Ausführung wird der Dialog mit seinem mindestens einen Bedienelement dargestellt und damit funktionsfähig.
  • 3 zeigt ein vorgegebenes erstes Schema 300. Das vorgegebene erste Schema 300 hat die Form einer Tabelle und wird deshalb im Folgenden auch so benannt.
  • In den Zeilen 308, 310, 312, 314 und 316 ist jeweils ein Bedienelement für den aus dem vorgegebenen ersten Schema 300 zu erstellenden Dialog spezifiziert.
  • Jedes Bedienelement wird mit seinem Namen in Spalte 302 spezifiziert, mit seinem Typ in Spalte 304, und mit einem weiteren Parameter, in diesem Falle einer Beschreibung, in Spalte 306. In dem gezeigten Beispiel tritt der Typ „txt" auf, der ein Textfeld spezifiziert sowie der Typ „cbo", der ein Auswahlelement wie etwa eine Combobox spezifiziert.
  • Weitere Parameter für die Spezifikation eines Bedienelements sind denkbar. Z.B. könnte man die Tabelle um zwei Spalten erweitern, wobei in der ersten der zwei Spalten die horizontale Position des entsprechenden Bedienelements auf der graphischen Benutzeroberfläche spezifiziert würde, und wobei in der anderen Spalte die vertikale Position des entsprechenden Bedienelements auf der graphischen Benutzeroberfläche spezifiziert würde.
  • 4 stellt vereinfacht den Schritt dar, in dem das zweite Schema aus dem ersten Schema erzeugt wird. Dies geschieht in dieser Ausführungsform in der Art, dass die Tabelle 400, die die in 3 beschriebenen Bedienelemente umfasst, markiert wird. In einem dann erscheinenden Fenster 402 kann dann in dieser Ausführungsform ein Dialogname 404: „Lager pflegen" und eine textuelle Beschreibung 406 sowie ein Typ des Dialog 408: „Pflege" festgelegt werden.
  • Weil das erste Schema z.B. in tabellarischer Form vorgegeben ist, können nun systemintern vom Computerprogrammprodukt die Steuerzeichen um die Spezifikationen der einzelnen Bedienelemente angebracht werden.
  • 5 zeigt dem Benutzer graphisch, dass systemintern ein zweites Schema in einer Benutzeroberflächensprache erstellt worden ist. Dies geschieht in der dargestellten Ausführungsform, indem um Tabelle 500 ein fett markierter Rand 502 dargestellt wird. Damit wird für den Benutzer erkennbar, dass die umrandeten Spezifikationen, die mehrere Bedienelemente betreffen, systemintern in ein Schema, z. B. in ein XML-Schema, eingebettet wurden.
  • 6 zeigt die in ein XML-Schema 600 eingebetteten Spezifikationen.
  • Der Name, der Typ, und die Beschreibung jedes einzelnen Bedienelements wird von Steuerzeichen in Form von XML-Knoten umschlossen.
  • Das XML-Schema 600 ordnet dabei den einzelne Feldern der Tabelle XML-Knoten zu, so dass die in der Tabelle spezifizierten Bedienelemente ihrem Typ entsprechend und ihrer Platzierung in der Tabelle, wodurch eine Anzeigelogik vorgegeben wird, entsprechend in dem zu erstellenden Dialog dargestellt werden.
  • Die Tabelle wird dabei von den „dialog" Knoten 602 und 604 umfasst.
  • Die erste Zeile 606 der Tabelle entspricht der Kopfzeile.
  • In jedem Feld des Tabellenkopfes wird der Typ dem die in der darunter liegenden Spalte spezifizierten Parameter zugeordnet sind, spezifiziert.
  • Im Feld 608 wird der Feldname von den "fielheader"-Knoten 614 bzw. 616 umschlossen. Entsprechend wird im Feld 610 der Typ von den "fieldtypeheader"-Knoten 618 bzw. 620 umschlossen und im Feld 612 wird die Beschreibung von dem "fielddescheader"-Knoten 622 bzw. 624 umschlossen. Ein Bedienelement wird jeweils von dem "field"-Knoten umschlossen. Z. B. wird das Bedienelement in Zeile 626 von dem "field"-Knoten 628 und 630 umschlossen. Der Name "Anzahl Gassen" wird von den "fieldname"-Knoten 632 bzw. 634 umschlossen und der Typ "txt" wird von dem "fieldtype"-Knoten 636 und 638 umschlossen. Des Weiteren wird die textuelle Beschreibung Anzahl der Lagegassen durch die "fielddesc"-Knoten 640 bzw. 642 umschlossen. Entsprechendes gilt für die anderen Zeilen der Tabelle, in dem die anderen Bedienelemente des Dialogs spezifiziert sind.
  • Unterhalb der Tabelle, aber noch von den „dialog" Knoten 602 und 604 umschlossen, befinden sich die „dialogid" Knoten 644 bzw. 646, die „dialogname"-Knoten 648 bzw. 650 sowie die „dialogdesc"-Knoten 652 bzw. 654, die zur Einbettung der Tabelle an sich in das XML-Schema verwendet werden. Durch die Verfügbarkeit eines Schemas für ein Dialogelement bräuchte man nur den Namen und die Beschreibung der jeweiligen Bedienelemente im Lasten- und Pflichtenheft an eine bestimmte Sprache anpassen (z.B. chinesisch oder englisch). Durch Verwendung desselben Schemas könnten dann Dialoge erstellt werden, in denen alle Texte auf chinesisch bzw. auf englisch angegeben sind.
  • 7 zeigt schematisch den Schritt zur Konversion des XML-Schemas in ein XAML-Format. Dabei ist die Tabelle 700 mit den Spezifikationen der einzelnen Bedienelemente, für die ein Dialog bestimmt werden soll, dargestellt. Wie in der vorhergehenden Abbildung beschrieben, ist die Tabelle 700 in ein XML-Schema eingebettet. Die im XML-Schema integrierten oder eingebetteten Spezifikationen werden nun systemintern in eine XAML-Datei umgewandelt, z.B. durch Erzeugung einer XML-Datei und anschließender XSLT, wobei die XAML-Datei ausgeführt werden kann, wodurch der Dialog lauffähig wird. Dazu wird in dieser Verfahrensvariante mittels einen Fenster 702 die Möglichkeit bereitgestellt, per Klick in Zeile 706 das XML-Schema als XAML-Datei abzuspeichern bzw. per Klick in Zeile 704 die eingebetteten Parameter der Tabelle 700 als XAML-Dialog anzuzeigen.
  • 8 zeigt die Tabelle 800 mit den Spezifikationen, für die ein XAML-Dialog 802 erstellt wurde. Der Name 804 wird wie in 4 spezifiziert mit "Lager pflegen" angezeigt. Ebenso wird die Beschreibung 806, wie in 4 spezifiziert, mit "Beschreibung des Dialogs" angezeigt. Des Weiteren werden die einzelnen Bedienelemente angezeigt. Das in Zeile 808 mit dem Namen „Lager" spezifizierte Bedienelement wird z.B. entsprechend seinem Typ "txt" – einem Textfeld – mit „Lager" 810 und der Beschreibung „Lagerbereich, Bezeichnung des Lagers" 812 angezeigt.

Claims (18)

  1. Verfahren zur Erzeugung eines funktionsfähigen Dialogs (102) für ein Bedien- und Beobachtungssystem, wobei der Dialog (102) aus mindestens einem Bedienelement (104) besteht, wobei in einem Lasten- oder Pflichtenheft der Name (106) und der Typ (107) des mindestens einen Bedienelements (104) spezifiziert sind, und wobei das Verfahren die folgenden Schritte aufweist: – Anordnung des Namens (106) und des Typs (107) des mindestens einen Bedienelements (104) in einem vorgegebenen ersten Schema (124); – Erzeugung eines zweiten Schemas (128) einer Benutzeroberflächensprache (110) aus dem ersten Schema (124), wobei das zweite Schema (128) Steuerzeichen (130) zur Visualisierung des mindestens einen Bedienelements (104) entsprechend seinem Typ (107) aufweist, und wobei das zweite Schema (128) Steuerzeichen (132) zur Zuordnung des Namens (106) zu dem Bedienelement (104) aufweist; – Integration des Namens (106) und des Typs (107) des mindestens einen Bedienelements (104) in das zweite Schema (128) der Benutzeroberflächensprache (110); – Konversion des zweiten Schemas (128) in eine Datei (108) mit einem Format der Benutzeroberflächensprache (110); – Ausführung der Datei (108) mit dem Format der Benutzeroberflächensprache (110), wobei der Dialog (102) auf einer Benutzeroberfläche (116) angezeigt wird, wodurch der Dialog (102) funktionsfähig wird und wobei die Benutzeroberfläche (116) zur Benutzeroberflächensprache (110) kompatibel ist.
  2. Verfahren nach Anspruch 1, wobei das Verfahren ferner den Schritt der Speicherung der Datei (108) mit dem Format der Benutzeroberflächensprache (110) in einer Datenbank aufweist.
  3. Verfahren nach Anspruch 1 mit den Schritten: – Konversion des zweiten Schemas in mehrere Dateien mit Formaten verschiedener Benutzeroberflächensprachen; – Speicherung der mehreren Dateien in einer Datenbank.
  4. Verfahren nach einem der Ansprüche 1 bis 3, wobei das Verfahren ferner den Schritt der Implementierung der Datei in das Bedien- und Beobachtungssystem aufweist.
  5. Verfahren nach einem der Ansprüche 1 bis 4, wobei im Lasten- oder Pflichtenheft weitere Parameter des Bedienelements spezifiziert sind, wobei die weiteren Parameter in dem vorgegebenen ersten Schema angeordnet werden, und wobei das zweite Schema Steuerzeichen zur Zuordnung der weiteren Parameter zu dem Bedienelement aufweist.
  6. Verfahren nach einem der Ansprüche 1 bis 5, wobei der Dialog aus mindestens zwei Bedienelementen besteht, wobei für jedes Bedienelement der Name, der Typ und weitere Parameter im Lasten- oder Pflichtenheft vorgegeben sind, wobei ferner für den Dialog im Lasten- oder Pflichtenheft eine Bedien- und Anzeigelogik vorgegeben ist, wobei die Namen, die Typen und die weiteren Parameter der Bedienelemente gemäß der Bedien- und Anzeigelogik des Dialogs im vorgegebenen ersten Schema angeordnet werden.
  7. Verfahren nach einem der Ansprüche 1 bis 6, wobei das vorgegebene erste Schema einer Tabelle (300) entspricht, wobei in jeder Zeile der Tabelle (308, 310, 312, 314, 316) ein Bedienelement des Dialogs mit seinem Namen, seinem Typ und den weiteren Parametern spezifiziert wird, und wobei die Anordnung der Spezifikationen der Bedienelemente in der Tabelle (300) die Bedien- und Anzeigelogik des Dialogs bestimmt.
  8. Verfahren nach einem der Ansprüche 1 bis 7, wobei das zweite Schema (600) einem Schema der Extensible Markup Language (XML) entspricht und wobei die Steuerzeichen (614,..., 624; 628,..., 642) XML-Knoten entsprechen.
  9. Verfahren nach Anspruch 8, wobei das Verfahren ferner den Schritt der Konversion des zweiten Schemas im XML Format in eine Datei mit dem Format der Extensible Application Markup Language (XAML) aufweist.
  10. Computerprogrammprodukt mit computerausführbaren Instruktionen, um ein Verfahren gemäß einem der vorhergehenden Ansprüche auszuführen.
  11. Vorrichtung zur Erzeugung eines funktionsfähigen Dialogs (102) für ein Bedien- und Beobachtungssystem, wobei der Dialog (102) aus mindestens einem Bedienelement (104) besteht, wobei in einem Lasten- oder Pflichtenheft der Name (106) und der Typ (107) des mindestens einen Bedienelements (104) spezifiziert sind, und wobei die Vorrichtung folgende Mittel aufweist: – Mittel zur Anordnung des Namens (106) und des Typs (107) des mindestens einen Bedienelements (104) in einem vorgegebenen ersten Schema (124); – Mittel zur Erzeugung eines zweiten Schemas (128) einer Benutzeroberflächensprache (110) aus dem ersten Schema (124), wobei das zweite Schema (128) Steuerzeichen (130) zur Visualisierung des mindestens einen Bedienelements (104) entsprechend seinem Typ (107) aufweist, und wobei das zweite Schema (128) Steuerzeichen (132) zur Zuordnung des Namens (106) zu dem Bedienelement (104) aufweist; – Mittel zur Integration des Namens (106) und des Typs (107) des mindestens einen Bedienelements (104) in das zweite Schema (128) der Benutzeroberflächensprache (110); – Mittel zur Konversion des zweiten Schemas (128) in eine Datei (108) mit einem Format der Benutzeroberflächensprache (110); – Mittel zur Ausführung der Datei (108) mit dem Format der Benutzeroberflächensprache (110), wobei der Dialog (102) auf einer Benutzeroberfläche (116) angezeigt wird, wodurch der Dialog (102) funktionsfähig wird und wobei die Benutzeroberfläche (116) zur Benutzeroberflächensprache (110) kompatibel ist.
  12. Vorrichtung nach Anspruch 11 ferner mit Mitteln zur Speicherung der Datei (108) mit dem Format der Benutzeroberflächensprache (110) in einer Datenbank.
  13. Vorrichtung nach Anspruch 11 mit: – Mitteln zur Konversion des Schemas in mehrere Dateien mit Formaten verschiedener Benutzeroberflächensprachen; – Mitteln zur Speicherung der mehreren Dateien in einer Datenbank.
  14. Vorrichtung nach einem der Ansprüche 11 bis 13, wobei die Vorrichtung ferner Mittel zur Implementierung der Datei in das Bedien- und Beobachtungssystem aufweist.
  15. Vorrichtung nach einem der Ansprüche 11 bis 14, wobei im Lasten- oder Pflichtenheft weitere Parameter des Bedienelements spezifiziert sind, wobei die weiteren Parameter in dem vorgegebenen ersten Schema angeordnet werden, und wobei das zweite Schema Steuerzeichen zur Zuordnung der weiteren Parameter zu dem Bedienelement aufweist.
  16. Vorrichtung nach einem der Ansprüche 11 bis 15, wobei der Dialog aus mindestens zwei Bedienelementen besteht, wobei für jedes Bedienelement der Name, der Typ und weitere Parameter im Lasten- oder Pflichtenheft vorgegeben sind, wobei ferner für den Dialog im Lasten- oder Pflichtenheft eine Bedien- und Anzeigelogik vorgegeben ist, wobei die Vorrichtung Mittel zur Anordnung der Namen, der Typen und der weiteren Parameter der Bedienelemente gemäß der Bedien- und Anzeigelogik des Dialogs im vorgegebenen ersten Schema aufweist.
  17. Vorrichtung nach einem der Ansprüche 11 bis 16, wobei das zweite Schema (600) einem Schema der Extensible Markup Language (XML) entspricht und wobei die Steuerzeichen (614,..., 624; 628,..., 642) XML-Knoten entsprechen.
  18. Vorrichtung nach Anspruch 17, wobei die Vorrichtung ferner Mittel zur Konversion des zweiten Schemas im XML Format in eine Datei mit dem Format der Extensible Application Markup Language (XAML) aufweist.
DE200510058218 2005-12-06 2005-12-06 Verfahren und Vorrichtung zur Erzeugung von Dialogen für ein Bedien- und Beobachtungssystem Ceased DE102005058218A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE200510058218 DE102005058218A1 (de) 2005-12-06 2005-12-06 Verfahren und Vorrichtung zur Erzeugung von Dialogen für ein Bedien- und Beobachtungssystem

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE200510058218 DE102005058218A1 (de) 2005-12-06 2005-12-06 Verfahren und Vorrichtung zur Erzeugung von Dialogen für ein Bedien- und Beobachtungssystem

Publications (1)

Publication Number Publication Date
DE102005058218A1 true DE102005058218A1 (de) 2007-06-14

Family

ID=38055773

Family Applications (1)

Application Number Title Priority Date Filing Date
DE200510058218 Ceased DE102005058218A1 (de) 2005-12-06 2005-12-06 Verfahren und Vorrichtung zur Erzeugung von Dialogen für ein Bedien- und Beobachtungssystem

Country Status (1)

Country Link
DE (1) DE102005058218A1 (de)

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
Frischalowski,D.: Das Programmiermodell von Long- horn. dot.net magazin. Ausgabe 9.2005. Online Ar- tikel Archiv. <http://www.dotnet-magazin.de/itr/on line_artikel/psecom,id,750,nodeid,31.html> (rech. am 06.09.06)
Frischalowski,D.: Das Programmiermodell von Long- horn. dot.net magazin. Ausgabe 9.2005. Online Ar- tikel Archiv. <http://www.dotnet-magazin.de/itr/online_artikel/psecom,id,750,nodeid,31.html> (rech. am 06.09.06) *

Similar Documents

Publication Publication Date Title
DE10351351B4 (de) Verfahren und System zur dynamischen Generierung von User Interfaces
EP1638028A2 (de) Rechnergestützte Erzeugung und Änderungsmanagement für Bedienoberflächen
EP1701258A1 (de) Darstellung hierarchischer Softwarestrukturen
WO2004034254A2 (de) Verfahren und schaltungsanordnung zum rechnergestützten erzeugen einer grafischen benutzeroberfläche
EP1640826B1 (de) Darstellung von Prozesswerten in der Automatisierungstechnik
EP1634130B1 (de) Vorrichtung und verfahren zur programmierung und/oder ausführung von programmen für industrielle automatisierungssysteme
EP2171582B1 (de) Fernbedienung eines browser-programms
DE102007014271A1 (de) Verfahren und Vorrichtung zur Bedienung und Steuerung einer maschinentechnischen Anlage mit Hilfe einer grafischen Entwicklungsoberfläche und automatischer Code-Generierung
EP3438774B1 (de) Verfahren zur bereitstellung von funktionen innerhalb eines industriellen automatisierungssystems und automatisierungssystem
DE102005058218A1 (de) Verfahren und Vorrichtung zur Erzeugung von Dialogen für ein Bedien- und Beobachtungssystem
EP2515229A1 (de) Softwarewerkzeug für die Automatisierungstechnik
EP1655663A1 (de) Datenflussmodellierung in Engineering-Systemen
EP1265751B1 (de) Verfahren und vorrichtung zur erstellung einer druckvorlage
DE102009010908A1 (de) Verfahren und Anordnung zur Steuerung des Einfügens von Registerblättern in einen Druckauftrag sowie ein entsprechendes Computerprogramm und ein entsprechendes computerlesbares Speichermedium
DE102019131814A1 (de) Verfahren zum Verknüpfen von Objekten eines Steuerprogramms einer Steuereinheit eines Automatisierungssystems und Entwicklungsumgebung
EP2012227A1 (de) Programmieroberfläche zum Programmieren von Computern
EP2645229A1 (de) Abarbeitung von Arbeitsschritten eines Druckproduktherstellungsverfahrens
EP1674953B1 (de) System und Verfahren zur Wiederverwendung von Projektierungsdaten
EP3048777B1 (de) Verfahren zum webbasierten zugriff auf ein automatisierungsgerät, computerprogramm zur ausführung des verfahrens und system
EP2149844B1 (de) Verfahren und Computerprogrammprodukt zum automatischen Einfügen von Daten aus einem Datenbanksystem in eine Datenstruktur
EP1691275B1 (de) Verfahren und Vorrichtung zum rechnergestützten Erzeugen einer graphischen Benutzeroberfläche
EP1043657A1 (de) Softwareobjekt, System und Verfahren für ein Automatisierungsprogramm mit Funktionsregeln mit Mehrfachnutzung für verschiedene Programmierwerkzeuge
EP2010974B1 (de) Engineeringsystem und verfahren zur projektierung eines automatisierungssystems
WO2008077359A1 (de) Verfahren zur generierung eines maschinenausführbaren zielcodes aus einem quellcode, zugehöriges computerprogramm und computersystem
WO2018206346A1 (de) Verfahren zum rechnergestützten verarbeiten von digitalen produktionsdaten zur herstellung eines oder mehrerer produkte

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
8131 Rejection