DE19882116T5

DE19882116T5 - System zum Konfigurieren einer Prozesssteuerumgebung mit grafischen Elementen

Info

Publication number: DE19882116T5
Application number: DE1998182116
Authority: DE
Inventors: Andrew P. Austin Dove; Larry O. Round Rock Jundt; Stephen G. Austin Hammack; J. Clint Pflugerville Fletcher
Original assignee: Fisher Rosemount Systems Inc
Current assignee: Fisher Rosemount Systems Inc
Priority date: 1997-02-14
Filing date: 1998-02-06
Publication date: 2004-11-18
Also published as: GB2336923B; GB2336923A; JP2014116027A; JP2001512599A; WO1998036353A1; US5980078A; USRE40817E1; JP5936180B2; JP2012084162A; AU6252198A; WO1998036335A3; GB2336977A; GB2336446B; JP2001512598A; DE19882113T1; GB2336446A; GB2336977B; AU6045498A; JP2001512593A; GB9918410D0

Abstract

Verfahren zum Konfigurieren einer Prozeßsteuerumgebung, wobei die Prozeßsteuerumgebung ein Computersystem enthält, welches einen Prozessor aufweist, der an eine Anzeigevorrichtung gekoppelt ist, wobei das Verfahren umfaßt:
Präsentieren einer Schablonenansicht, die ein Schablonenobjekt enthält, an der Anzeigevorrichtung, wobei das Schablonenobjekt (stencil object) eine Prozeßsteuermodul repräsentiert;
Präsentieren einer Diagrammansicht an der Anzeigevorrichtung, wobei die Diagrammansicht die Prozeßsteuerumgebungskonfiguration repräsentiert;
Ziehen des Schablonenobjekts von der Schablonenansicht zu der Diagrammansicht;
Ablegen des Schablonenobjekts auf der Diagrammansicht an einer Position, die eine Stelle des Prozeßsteuermoduls in der Prozeßsteuerumgebung anzeigt; und
Konfigurieren der Prozeßsteuerumgebung in Einklang mit der Diagrammansicht.

Description

TECHNISCHES GEBIET
Die Erfindung betrifft die Prozeßüberwachung und Steuersysteme. Spezifischer betrifft die vorliegende Erfindung ein System zum Erzeugen einer Steuerschablone einer Vielzahl von Steuerschablonen, einer individuellen Steuerschablone mit zugeordneten Attributen, Verfahren und grafischen Ansichten, die durch einen Anwender ausgewählt werden, um Konstruktionsprozeßsteuerlösungen zu erzeugen.
STAND DER TECHNIK
Gegenwärtige Prozeßsteuer- oder Regelsysteme verwenden Instrumente, Steuervorrichtungen und Kommunikationssysteme, um Steuerelemente zu überwachen und zu manipulieren, wie beispielsweise Ventile und Schalter, um einen oder mehrere Prozeßvariable bei ausgewählten Sollwerten zu halten, inklusive Temperatur, Druck, Strömung und ähnlichem. Die Prozeßvariablen werden so ausgewählt und gesteuert, um eine gewünschte Prozeßobjektive zu erreichen, wie beispielsweise den sicheren und effizienten Betrieb der Maschinen und der Ausrüstung, die in dem Prozeß verwendet werden. Prozeßsteuersysteme haben weit verbreitete Anwendungen in der Automatisierung von industriellen Prozessen, wie beispielsweise Prozessen, die in der chemischen, Erdöl- und Herstellungsindustrie verwendet werden.
Die Steuerung des Prozesses wird häufig unter Verwendung von mikroprozessor-gestützten Kontrollern, Computern oder Workstations realisiert, welche den Prozeß dadurch überwachen, indem sie Befehle und Daten zu Hardwarevorrichtungen senden und von diesen empfangen, um entweder einen bestimmten Aspekt des Prozesses oder den gesamten Prozeß als Ganzes zu steuern oder zu regeln. Die spezifischen Prozeßsteuerfunktionen, die durch Softwareprogramme in diesen Mikroprozessoren, Computern oder Workstations implementiert werden, können individuell ausgelegt sein, können modifiziert oder geändert werden, und zwar durch Programmierung, wobei keine Modifikationen der Hardware erforderlich sind. Beispielsweise kann ein Ingenieur veranlassen, daß ein Programm geschrieben wird, derart, daß der Kontroller einen Flüssigkeitsstand von einem Flüssigkeitssensor in einem Tank liest, den Flüssigkeitsstand mit einem vorbestimmten gewünschten Flüssigkeitsstand vergleicht und dann ein Zuführventil öffnet oder schließt, basierend darauf, ob der tatsächliche Flüssigkeitsstand niedriger oder höher war als der vorbestimmte gewünschte Flüssigkeitsstand. Die Parameter können in einfacher Weise dadurch geändert werden, indem eine ausgewählte Ansicht des Prozesses dargestellt wird und indem dann das Programm unter Verwendung der ausgewählten Ansicht modifiziert wird. Der Ingenieur wird dabei in typischer Weise die Parameter dadurch ändern, indem er eine ingenieurmäßige Darstellung des Prozesses zur Anzeige bringt und modifiziert.
Zusätzlich zur Durchführung der Steuerung der Prozesse überwachen Softwareprogramme auch eine Ansicht der Prozesse bzw. stellen diese dar, liefern eine Rückkopplung in Form einer bedienungsmäßigen Ansicht oder Darstellung hinsichtlich des Status der speziellen Prozesse. Die überwachenden Softwareprogramme liefern auch ein Signal gemäß einem Alarm, wenn ein Problem auftritt. Einige Programme stellen Befehle oder Vorschläge für eine Bedienungsperson optisch dar, wenn ein Problem auftritt. Die Bedienungsperson, die für die Steuerung des Prozesses verantwortlich ist, muß dann den Prozeß von seiner Sicht aus betrachten. Eine Anzeige oder Konsole wird in typischer Weise als ein Interface zwischen dem mikroprozessor-gestützten Kontroller oder Computer, der die Prozeßsteuerfunktion durchführt, und der Bedienungsperson vorgesehen und auch zwischen dem Programmierer oder Ingenieur und dem mikroprozessor-gestützten Kontroller oder Computer, der die Prozeßsteuerfunktion ausführt.
Systeme, die eine Überwachungs-, Steuer- und Rückkopplungsfunktion in Prozeßsteuerumgebungen ausführen, sind in typischer Weise durch eine Software implementiert, die in hochrangigen Computerprogrammiersprachen, wie beispielsweise Basic, Fortran oder C geschrieben sind und die auf einem Computer oder Kontroller ausgeführt werden. Obwohl diese hochrangigen Sprachen für die Prozeßsteuerprogrammierung effektiv sind, werden sie gewöhnlich nicht durch die Prozeßingenieure, Wartungsingenieure und Regelingenieure, Bedienungspersonen und Überwachungspersonen verstanden. Es wurden hochwertige grafische Darstellungssprachen für derartiges Personal entwickelt, wie beispielsweise ein kontinuierlicher Funktionsblock und eine Kettenlogik (ladder logic). Daher benötigt jeder der Ingenieure, des Wartungspersonals, der Bedienungspersonen, der Laborpersonen und ähnlichen, eine grafische Ansicht der Elemente des Prozeßsteuer- oder Regelsystems, welches sie dazu befähigt, das System in Ausdrücken zu sehen, die für deren Zuständigkeiten relevant sind.
Beispielsweise kann ein Prozeßsteuerprogramm in Fortran geschrieben sein und erfordert zwei Eingangsgrößen, das Be rechnen eines Mittelwertes der Eingangsgrößen und das Erzeugen eines Ausgangswertes gleich dem Mittelwert der zwei Eingangsgrößen. Dieses Programm kann als die MITTELWERT-Funktion bezeichnet werden und kann über eine grafische Darstellung für die Steuer- oder Regelingenieure aufgerufen und als Bezug verwendet werden. Eine typische grafische Darstellung kann aus einem rechteckförmigen Block mit zwei Eingängen, einem Ausgang und einer Aufschrift bestehen, die den Block als MITTELWERT bezeichnet. Ein abweichendes Programm kann dazu verwendet werden, um eine grafische Repräsentation dieser gleichen Funktion für eine Bedienungsperson zu erzeugen, um den Mittelwert zu betrachten. Bevor das System an den Verbraucher ausgeliefert wird, werden diese Softwareprogramme in eine Bibliothek mit vordefinierten, vom Anwender wählbaren Merkmalen plaziert. Die Programme werden durch Funktionsblöcke identifiziert. Ein Anwender kann dann eine Funktion aktivieren und die vorbestimmte grafische Wiedergabe auswählen, um unterschiedliche Ansichten für die Bedienungsperson, den Ingenieur usw. zu erzeugen, indem einer einer Vielzahl von Funktionsblöcken aus der Bibliothek für die Verwendung bei der Definition einer Prozeßsteuerlösung ausgewählt wird, anstatt ein vollständig neues Programm, beispielsweise in Fortran, entwickeln zu müssen.
Eine Gruppe von standardisierten Funktionen, von denen jede durch einen zugeordneten Funktionsblock bezeichnet ist, kann in einer Steuerbibliothek gespeichert sein. Ein Konstrukteur, der mit solch einer Bibliothek ausgestattet ist, kann Prozeßsteuerlösungen dadurch konstruieren, indem er auf einem Computeranzeigebildschirm verschiedene Funktionen oder Elemente miteinander verbindet, die mit Hilfe der Funktionsblöcke ausgewählt werden, um bestimmte Aufgaben oder Aufträge auszuführen. Der Mikroprozessor oder Computer unterstützt dabei jede der Funktionen oder Elemente, die durch die Funktionsblöcke definiert wurden, und zwar mit vordefinierten Schablonen oder Masken, die in der Bibliothek gespeichert sind, und er bezieht jede der Programmfunktionen oder Elemente miteinander gemäß den Verbindungen, die durch den Konstrukteur gewünscht werden. Im Idealfall kann ein Konstrukteur ein gesamtes Prozeßsteuerprogramm konstruieren unter Verwendung von grafischen Ansichten vordefinierter Funktionen, ohne jemals eine Zeile des Kodes in Fortran oder in einer anderen hochrangigen Programmiersprache zu schreiben.
Ein Problem, das bei der Verwendung von grafischen Darstellungen für die Prozeßsteuerprogrammierung auftritt, besteht darin, daß bestehende Systeme lediglich den Gerätehersteller, jedoch nicht einem Anwender dieser Ausrüstung ermöglichen, seine eigenen Steuerfunktionen zu erzeugen, und zwar zusammen mit zugeordneten grafischen Darstellungen oder die vorbestimmten Funktionen innerhalb der vorgesehenen Bibliothek zu modifizieren.
Neue Prozeßsteuerfunktionen werden primär von Gesellschaften gewünscht, die Konstruktionssysteme vertreiben und nicht durch Endverbraucher, die einen bestimmten Bedarf für eine Funktion haben können, die nicht ein Teil des Standardsatzes der Funktionen ist, die von der Gesellschaft geliefert werden. Die standardisierten Funktionen sind innerhalb einer Steuerbibliothek enthalten, die mit dem System an den Endverbraucher ausgeliefert wird. Der Endverbraucher muß entweder bestehende Funktionen verwenden, die mit der Konstruktionsumgebung geliefert werden oder muß sich auf die Gesellschaft verlassen, daß diese eine Konstruktionsumgebung liefern kann, um irgendeine gewünschte spezielle zu gebrauchende Funktion für sie zu entwickeln. Wenn der Konstrukteur gefragt wird, die Parameter der ingenieurmäßigen Ansicht zu modifizieren, so müssen alle anderen Ansichten, welche solchen Parameter verwenden, neu geschrieben werden und entsprechend modifiziert werden, da das Funktionspro gramm und das Anzeigeprogramm häufig unabhängig entwickelt werden und nicht Teil einer integrierten Entwicklungsumgebung sind. Es ist offensichtlich, daß eine solche Prozedur sehr mühsam, kostspielig und zeitaufwendig ist.
Was benötigt wird, ist eine einheitliche, universale Konstruktionsumgebung, die in einfacher Weise verwendet werden kann, und zwar nicht nur durch einen Konstrukteur oder Hersteller, sondern auch durch einen Anwender, um eine existierende Lösung anwendergerecht zu gestalten, um dessen spezifischen Bedürfnisse zu befriedigen, um Prozeßsteuerfunktionen zu entwickeln.
OFFENBARUNG DER ERFINDUNG
Es wurde herausgefunden, daß eine Prozeßsteuerumgebung in einfacher Weise und schnell konfiguriert oder modifiziert werden kann, indem man ein Steuerstudioobjektsystem erzeugt, welches einen Schabloneabschnitt (der als ein Palettenabschnitt bezeichnet wird) mit Schablonepunkten, die in Einklang mit Algorithmen stehen, und einem Diagrammabschnitt enthält, indem die Schablonepunkte über eine Drag- und Drop-Operation kopiert werden können. Da die Schabloneposten (stencil items) Gegenstände sind, die alle Informationen enthalten, die von einem Diagrammabschnitt gefordert werden, um ein Objekt zu erzeugen, welche alle die Informationen enthält, die zum Programmieren einer Prozeßsteuerumgebung erforderlich sind, reflektiert der komplette Diagrammabschnitt die aktuelle oder tatsächliche Konfiguration der Prozeßsteuerumgebung. Es wurde herausgefunden, daß das Vorsehen der Schabloneposten als Objekte die Möglichkeit bietet, daß die diagrammäßige Umgebung direkt an Knotenpunkten installiert werden kann, ohne daß das Programm kompiliert oder neu geschrieben werden muß, und zwar in einer Sprache, die in Einklang mit dem Knotenpunkt (node) steht.
Gemäß einem Aspekt ist die Erfindung mit einem Verfahren befaßt, um eine Prozeßsteuerumgebung zu konfigurieren, wobei die Prozeßsteuerumgebung ein Computersystem enthält, welches einen Prozessor aufweist, der an eine Anzeigevorrichtung gekoppelt ist. Das Verfahren enthält die folgenden Schritte: Präsentieren auf einer Anzeigevorrichtung eine Schabloneansicht, enthaltend ein Modulobjekt, wobei das Modulobjekt einen Prozeßsteuermodul wiedergibt; Darstellen auf der Anzeigevorrichtung einer Prozeßsteuerumgebungsansicht, wobei die Prozeßsteuerumgebungsansicht die Prozeßsteuerumgebungskonfiguration wiedergibt; Ziehen des Modulobjekts von der Schabloneansicht in die Prozeßsteuerumgebungsansicht; Fallenlassen des Modulobjekts auf die Prozeßsteuerumgebungsansicht an einer Position, die eine Stelle des Prozeßsteuermoduls anzeigt, und zwar in der Prozeßsteuerumgebung, und konfigurieren der Prozeßsteuerumgebung in Einklang mit der Prozeßsteuerumgebungsansicht.
Die beschriebene Konstruktionsumgebung ermöglicht es einem Prozeßsteuerkonstrukteur oder Anwender, eine Standardprozeßsteuerfunktion zu modifizieren oder eine einzigartige anwenderspezifische Prozeßsteuerfunktion zu erzeugen und grafische Ansichten zu erzeugen, die der modifizierten oder neu erzeugten Prozeßsteuerfunktion zugeordnet sind, und zwar alles innerhalb einer gemeinsamen Umgebung. Die Konstruktionsumgebung enthält ein gemeinsames Interface für sowohl die Erzeugung der Funktion und für Ingenieure, Bedienungspersonen, Labor- und Wartungspersonal oder andere gewünschte Anwender, die dieser zugeordnet sind, derart, daß dann, wenn die Ingenieursfunktion modifiziert oder erzeugt wird, sich die Modifikation oder Kreation selbst in allen anderen grafischen Ansichten der Funktion manifestiert. Zusätzlich besitzt die Konstruktionsumgebung eine gemeinsame Datenbankstruktur von Attributen und Verfahren und den grafischen Mitteln, die der Prozeßsteuerfunktion zugeordnet sind, um dadurch modifizierte oder erzeugte Pro zeßsteuerfunktionen, in was immer für einer grafischen Methodologie dargestellt wird, zu erlauben, die gewünscht wird, ob nun durch die Kettenlogik (ladder logic), den kontinuierlichen Funktionsblock oder anderen Konstruktionssprachen, die durch verschiedene Ingenieure, Bedienungspersonen, Laborpersonal und Wartungspersonal benötigt werden, oder andere gewünschte grafische Darstellungen.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Die Merkmale der Erfindung, welche als neu betrachtet werden, sind spezifisch in den anhängenden Ansprüchen angegeben. Jedoch kann die Erfindung selbst sowohl hinsichtlich ihrer Struktur und ihres Betriebsverfahrens am besten unter Hinweis auf die folgende Beschreibung und beigefügten Zeichnungen verstanden werden.
1 ist ein schematisches Blockschaltbild, welches eine Workstation in Einklang mit einer verallgemeinerten Ausführungsform der vorliegenden Erfindung zeigt, die eine Fähigkeit zeitigt, um eine neue Steuerschablone zu erzeugen und eine Fähigkeit besitzt, um eine existierende Steuerung oder Regelung zu modifizieren.
2 ist ein schematisches Blockschaltbild, welches die Prozeßsteuerumgebung in einer Konfigurationsimplementierung und in einer Laufzeitimplementierung zeigt.
3 ist ein schematisches Blockschaltbild, welches eine hierarchische Beziehung unter den Systemobjekten eines Konfigurationsmodells in Einklang mit einer Ausführungsform der vorliegenden Erfindung herausgreift.
4 ist eine Bildschirmpräsentation eines Steuerstudioobjektsystems gemäß einer Ausführungsform der vorliegenden Erfindung.
5a–5f sind Bildschirmpräsentationen zur Installation eines vollständigen Prozeßsteuerdiagramms an einem Knotenpunkt einer Prozeßsteuerumgebung in Einklang mit einer Ausführungsform der vorliegenden Erfindung.
6 ist ein Blockschaltbild, welches die Klassenhierarchie einer Steuerstudioobjektsystemdiagrammansicht darstellt.
7 ist ein Blockschaltbild, welches die Klassenhierarchie von Steuerstudioobjektsystemschablonenklassen zeigt.
8 ist ein Blockschaltbild, welches die Klassenhierarchie von Steuerstudioobjektleichtgewichtsklassen zeigt, die von der Klasse CObject aus absteigen.
9 ist ein Blockschaltbild, welches die Klassenhierarchie von Steuerstudioobjektsystemverbindungsklassen zeigt, die von der Klasse CObject aus absteigen.
10 ist ein Blockschaltbild, welches die Klassenhierarchie eines Diagrammabschnitts der Steuerstudioobjektsystem-Drag- und Drop-Klassen darstellt.
11 ist ein Blockschaltbild, welches die Klassenhierarchie der ursprünglichen Steuerstudioobjektsystem-Drag- und Drop-Objektklassen zeigt.
12A–12E sind Flußdiagramme, die eine Schablonen-Drag- und Drop-Operation eines Steuerstudioobjektsystems gemäß der vorliegenden Erfindung zeigen.
13A–13D sind Flußdiagramme, die einen ursprünglichen Drag and Drop zu einem Diagrammabschnitt eines Steuerstudioobjektsystems gemäß der vorliegenden Erfindung zeigen.
14A–14D sind Flußdiagramme, die ursprüngliche Schnitt-, Kopier- und Vergangenheitsoperationen in einem Diagrammabschnitt eines Steuerstudioobjektsystems gemäß der vorliegenden Erfindung zeigen.
15 ist ein Flußdiagramm, welches die Operation der Installation eines Diagramms an einem Knotenpunkt in Einklang mit der vorliegenden Erfindung darstellt.
BETRIEBSARTEN, UM DIE ERFINDUNG AUSZUFÜHREN
Eine Prozeßsteuerumgebung 100 ist in 1 gezeigt und veranschaulicht eine Steuerumgebung zum Implementieren eines digitalen Steuersystems, Prozeßkontroller oder ähnlichem. Die Prozeßsteuerumgebung 100 enthält eine Betreiberworkstation 102 und eine Ingenieurworkstation 106, die durch ein örtliches Bereichsnetzwerk ("LAN") 108 elektrisch miteinander verbunden sind oder durch irgendein anderes bekanntes Kommunikationsmittel verbunden sind, um Daten und Steuersignale unter den verschiedenen Workstations und einer Vielzahl von Kontrollern/Multiplexern 110 zu übertragen und zu empfangen. Die Workstations 102 und 106 bestehen beispielsweise aus Computern, die in Einklang mit der IBMkompatiblen Architektur stehen. Die Workstations 102 und 106 sind so dargestellt, daß sie durch das LAN 108 mit einer Vielzahl von Kontrollern/Multiplexern 110 verbunden sind, die eine elektrische Kopplung zwischen den Workstations und einer Vielzahl von Prozessen 112 bilden. Bei vielen verschiedenen Ausführungsformen enthält das LAN 108 eine einzelne Workstation, die direkt an einen Kontroller/Multiplexer 110 angeschlossen ist, oder enthält alternativ eine Vielzahl von Workstations, beispielsweise zwei Workstations 102 und 106, und viele Kontroller/Multiplexer 110, was von den Zielen und Anforderungen der Prozeßsteuerumgebung 100 abhängig ist. Bei einigen Ausführungsformen steuert ein einzelner Prozeßkontroller/Multiplexer 110 mehrere unterschiedliche Prozesse 112 oder steuert alternativ einen Abschnitt eines einzelnen Prozesses.
Bei der Prozeßsteuerumgebung 100 wird eine Prozeßsteuerstrategie dadurch entwickelt, indem eine Softwaresteuerlösung an der Ingenieurworkstation 106 als Beispiel erzeugt wird und indem die Lösung über das LAN 108 zu der Anwenderworkstation 102, der Lab-Workstation 104 und einem Kontroller/Multiplexer 110 zum Zwecke der Ausführung übertragen wird. Die Anwenderworkstation 102 schickt Interfaceanzeigen zu der Steuer-/Überwachungsstrategie, die in dem Kontroller/Multiplexer 110 implementiert ist und kommuniziert mit einem oder mit mehreren der Kontroller/Multiplexer 110, um die Prozesse 112 zu betrachten und um Steuerattributwerte gemäß den Anforderungen der gewünschten Lösung zu ändern. Die Prozesse 112 werden von einer oder mehreren Bereichsvorrichtungen (field devices) gebildet, die aus intelligenten Bereichsvorrichtungen oder herkömmlichen (nicht intelligenten) Bereichsvorrichtungen bestehen können.
Zusätzlich kommuniziert die Anwenderworkstation 102 visuell und gemäß einer Audiorückkopplung mit dem Anwender hinsichtlich des Status und der Bedingungen der gesteuerten Prozesse 112. Die Ingenieurworkstation 106 enthält einen Prozessor 116, eine Anzeige 115 und einen oder mehrere Ein/Ausgänge oder Anwenderinterfacevorrichtung 118, wie beispielsweise ein Keyboard, Lichtgriffel und ähnliches. Die Workstation enthält auch einen Speicher 117, der sowohl einen flüchtigen als auch nichtflüchtigen Speicher enthält. Der Speicher 117 enthält ein Steuerprogramm, welches auf dem Prozessor 116 ausgeführt wird, um die Steueroperationen und -funktionen der Prozeßsteuerumgebung 100 zu implementieren. Der Speicher 117 enthält auch ein Steuerschablonensystem 120 und ein Steuerstudioobjektsystem 130. Die Anwenderworkstation 102 und andere Workstations (nicht gezeigt) innerhalb der Prozeßsteuerumgebung 100 enthält bzw. enthalten wenigstens eine zentrale Verarbeitungseinheit (nicht gezeigt), die elektrisch mit einer Anzeige (nicht gezeigt) und einer Anwenderinterfacevorrichtung (nicht gezeigt) verbunden ist, um eine Interaktion zwischen einem Anwender und dem Prozessor zuzulassen.
Die Prozeßsteuerumgebung 100 enthält auch einen Schablonen- oder Masken-generator 124 und eine Steuerschablonenbibliothek 123, die in Kombination das Steuerschablonensystem 120 bilden. Eine Steuerschablone ist als eine Gruppierung von Attributfunktionen definiert, die dazu verwendet werden, um einen Prozeß zu steuern und auch die Methodologie, die für eine bestimmte Prozeßsteuerfunktion, Steuerattribute, Variable, Eingangsgrößen und Ausgangsgrößen für die bestimmte Funktion und die grafischen Ansichten oder Darstellungen der Funktion verwendet werden, wie sie benötigt werden, wie beispielsweise eine Ingenieurdarstellung und eine Anwenderdarstellung.
Das Steuerschablonensystem 120 enthält eine Steuerschablonenbibliothek 123, die mit dem Schablonengenerator 124 kommuniziert. Die Steuerschablonenbibliothek 123 enthält Daten, die Sätze von vordefinierten oder existierenden Steuerschablonenfunktionen wiedergeben, und zwar für die Ver wendung in den Prozeßsteuerprogrammen. Die Steuerschablonenenfunktionen sind Schablonen (templates), die im allgemeinen mit dem System von dem Systemkonstrukteur zu dem Anwender gelangen.Der Schablonengenerator 124 besteht aus einem Interface, welches einem Anwender in vorteilhafter Weise die Möglichkeit bietet, neue Steuerschablonenfunktionen zu erzeugen oder bestehende Steuerschablonenfunktionen zu modifizieren. Die erzeugten und modifizierten Schablonenfunktionen werden selektiv in der Steuerschablonenbibliothek 123 abgespeichert.
Der Schablonengenerator 124 enthält einen Attribute- und Verfahrenssprachegenerator 126 und einen Grafikgenerator 128. Der Attribute- und Verfahrenssprachegenerator 126 liefert Bildschirmanzeigen, die es dem Anwender ermöglichen, eine Vielzahl von Attributdefinitionen zu definieren, die der Erzeugung einer neuen Steuerschablonenfunktion zugeordnet sind oder der Modifizierung einer bestimmten existierenden Steuerschablonenfunktion zugeordnet sind, wie beispielsweise Eingangsgrößen, Ausgangsgrößen, anderen Attributen als auch Vorsehen von Bildschirmdarstellungen oder Anzeigen, um dem Anwender zu ermöglichen, Verfahren oder Programme auszuwählen, welche die neue oder modifizierte Funktion für die bestimmte Steuerschablone ausführen. Der Grafikgenerator 128 versorgt einen Anwender mit der Fähigkeit, grafische Darstellungen zu konstruieren, die bestimmten Steuerschablonen zugeordnet sind. Ein Anwender verwendet die durch den Attribute- und Verfahrenssprachegenerator 126 gespeicherten Daten und den Grafikgenerator 128, um vollständig die Attribute, Verfahren und grafischen Ansichten für eine Steuerschablone zu definieren. Die Daten, welche die erzeugte Steuerschablonenfunktion wiedergeben, werden allgemein in der Steuerschablonenbibliothek 123 gespeichert und stehen anschließend für eine Auswahl und Verwendung durch einen Ingenieur zum Konstruieren von Prozeßsteuerlösungen zur Verfügung.
Das Steuerstudioobjektsystem 130 bietet einem Anwender ein freundliches Interface, welches es einem Anwender ermöglicht, grundlegende Erzeugungsblöcke eines Diagramms, die als Schablonenposituionen oder -posten, Palettenposten oder Schablonen bezeichnet werden, zu erzeugen, zu modifizieren, zu verwenden und wegzulassen. Das Steuerstudioobjektsystem 130 kann von einem Anwender verstanden werden, der keine vorausgehende Erfahrung in der Manipulation von Grundbausteinen des Schablonengenerators besitzt. Das Steuerstudioobjektsystem 130 und speziell der Schablonenabschnitt des Steuerstudioobjektsystems 130 haben eine Wechselwirkung mit dem Schablonengenerator 120.
Die Prozeßsteuerumgebung 100 existiert in einem Konfigurationsmodell oder einer Konfigurationsimplementierung 210 und einem Laufzeitmodell oder einer Laufzeitimplementierung 220, die in 2 gezeigt ist. In der Konfigurationsimplementierung 210 werden die Komponentenvorrichtungen, Objekte, Zwischenverbindungen und Zwischenbeziehungen innerhalb der Prozeßsteuerumgebung 100 festgelegt. In der Laufzeitimplementierung 220 werden die Operationen der verschiedenen Komponentenvorrichtungen, Objekte, Zwischenverbindungen und Zwischenbeziehungen ausgeführt. Die Konfigurationsimplementierung 210 und die Laufzeitimplementierung 220 sind durch eine ASCII-gestützte Downloadsprache verbunden. Die Downloadsprache erzeugt Systemobjekte gemäß den Definitionen, die durch einen Anwender geliefert werden und erzeugt Momente aus den zugelieferten Definitionen. Zusätzlich zu den Downloaddefinitionen lädt die Downloadsprache auch Momente und Momentwerte nach oben. Die Konfigurationsimplementierung 210 wird aktiviert, um die Laufzeitimplementierung 220 unter Verwendung einer Installationsprozedur auszuführen.
Die Prozeßsteuerumgebung 100 enthält Vielfachsubsysteme, wobei mehrere der Subsysteme sowohl eine Konfigurations- als auch Laufzeitimplementierung haben. Beispielsweise liefert ein Prozeßgrafiksubsystem 230 anwenderdefinierte Ansichten und eine Operatorkopplung zur Architektur der Prozeßsteuerumgebung 100. Das Prozeßgrafiksubsystem 230 besitzt einen Prozeßgrafikeditor 232, einen Teil der Konfigurationsimplementierung 210 und einen Prozeßgrafikbetrachter 234, einen Abschnitt der Laufzeitimplementierung 220. Der Prozeßgrafikeditor 232 ist mit dem Prozeßgrafikbetrachter 234 durch ein Zwischensubsysteminterface 236 in der Downloadsprache verbunden. Die Prozeßsteuerumgebung 100 enthält auch ein Steuersubsystem 240, welches Steuermodule und Ausrüstungsmodule in einem Definitions- und Moduleditor 242 konfiguriert und installiert, welches die Steuermodule und Ausrüstungsmodule in einem Laufzeitkontroller 244 ausführt. Der Definitions- und Moduleditor 242 arbeitet innerhalb der Konfigurationsimplementation 210 und der Laufzeitkontroller 244 arbeitet innerhalb der Laufzeitimplementation 220, um kontinuierliche und sequenzmäßige Steuerfunktionen zu liefern. Der Definitions- und Moduleditor 242 ist mit dem Laufzeitkontroller 244 durch ein Zwischensysteminterface 246 in der Downloadsprache verbunden. Die vielfachen Subsysteme sind durch ein Subsysteminterface verbunden.
Die Konfigurationsimplementierung 210 und die Laufzeitimplementierung 220 sind mit einer Hauptdatenbank 260 gekoppelt, um einen Zugriff auf gemeinsame Datenstrukturen zu unterstützen. Verschiedene örtliche (nicht Haupt-)Datenbänke 262 sind mit der Hauptdatenbank 260 beispielsweise gekoppelt, um Konfigurationsdaten von der Hauptdatenbank 260 zu den örtlichen Datenbanken 262, wie durch einen Anwender bestimmt; zu transferieren. Ein Teil der Hauptdatenbank 260 besteht aus einer dauerhaften Datenbank 270. Die dauerhafte Datenbank 270 ist ein Objekt, welches die Zeit transzendiert, so daß die Datenbasis weiter existiert, nachdem der Erzeuger der Datenbank nicht mehr existiert, und welches den Raum transzendiert, so daß die Datenbank in einen Adressenraum zurück bewegbar ist, der von dem Adressenraum verschieden ist, in welchem die Datenbank erzeugt wurde. Die gesamte Konfigurationsimplementierung 210 wird in der dauerhaften Datenbank 270 gespeichert. Die Laufzeitimplementierung 220 führt eine Kopplung zu der dauerhaften Datenbank 270 und zu den örtlichen Datenbanken 262 durch, um auf Datenstrukturen zuzugreifen, die durch die Konfigurationsimplementierung 210 gebildet sind. Insbesondere ruft die Laufzeitimplementierung 220 ausgewählte Ausrüstungsmodule, Anzeigen und ähnliches von den örtlichen Datenbänken 262 und der dauerhaften Datenbank 270 ab. Die Laufzeitimplementierung 220 führt eine Kopplung zu anderen Subsystemen zu Installationsdefinitionen durch, wodurch Objekte installiert werden, die zum Erzeugen von Momenten verwendet werden, wenn die Definitionen noch nicht existieren, um Laufzeitmuomente oder Objekte zu spezialisieren und um Information von verschiedenen Quellen zu den Bestimmungsobjekten zu transferieren.
Gemäß 3 veranschaulicht ein schematisches Blockschaltbild die hierarchische Beziehung unter den Systemobjekten eines Konfigurationsmodells 300. Das Konfigurationsmodell 300 enthält viele Konfigurationsaspekte, mit einer Steuereinheit, I/O, Prozeßgrafiken, Prozeßausrüstung, Alarmeinrichtungen, Geschichte und Ereignisse. Das Konfigurationsmodell 300 enthält auch eine Vorrichtungsbeschreibung und ein Netzwerktopologielayout.
Die Konfigurationsmodellhierarchie 300 ist für die Verwendung durch einen bestimmten Satz von Anwendern definiert, um Systemobjektbeziehungen und Örtlichkeiten zu sichten und um Wartungsinformationen unter den verschiedenen Systemobjekten zu übertragen oder zu navigieren. Beispielsweise ist eine Konfigurationsmodellhierarchie 300, spezifisch eine physikalische Anlagehierarchie, für die Verwendung durch die Wartungsingenieure und -techniker festgelegt, um physi kalische Anlagebeziehungen und Lokalitäten zu sichten und um Wartungsinformationen unter den verschiedenen Instrumenten und Ausrüstungen in einer physikalischen Anlage zu kommunizieren oder zu lenken bzw. zu navigieren. Eine Ausführungsform einer Konfigurationsmodellhierarchie 300, die eine physikalische Anlagehierarchie bildet, unterstützt einen untergeordneten Satz der physikalischen SP88-Ausrüstungsstandardhierarchie und enthält einen Konfigurationsmodellstandort 310, einen oder mehrere physikalische Anlagebereiche 320, Ausrüstungsmodule 330 und Steuermodule 340.
Die Konfigurationsmodellhierarchie 300 ist als einzelne Prozeßörtlichkeit 310 definiert, die in einen oder mehrere benannte physikalische Anlagebereiche 320 aufgeteilt ist, die innerhalb der Konfigurationsmodellhierarchie 300 definiert sind. Die physikalischen Anlagebereiche 320 enthalten optional etikettierte Module (tagged modules), von denen jeder innerhalb der Konfigurationsmodellhierarchie 300 einmalig spezialisiert ist. Der physikalische Anlagebereich 320 enthält optional einen oder mehrere Ausrüstungsmodule 330. Ein Ausrüstungsmodul 330 enthält optional andere Ausrüstungsmodule 330, Steuermodule 340 und Funktionsblöcke. Ein Ausrüstungsmodul 330 enthält eine Steuerschablone und wird durch diese gesteuert, die gemäß einer oder einer Anzahl von unterschiedlichen grafische Prozeßsteuerprogrammiersprachen erzeugt wird, enthaltend den kontinuierlichen Funktionsblock, die Kontaktlogik oder die sequentielle Funktionsgrafik ("SFC"). Die Konfigurationsmodellhierarchie 300 enthält optional einen oder mehrere Steuermodule 340. Ein Steuermodul ist in einem Objekt, wie beispielsweise einem physikalischen Anlagebereich 320, einem Ausrüstungsmodul 330 oder einem anderen Steuermodul 340 enthalten. Ein Steuermodul 340 enthält optional Objekte, wie beispielsweise andere Steuermodule 340 oder Funktionsblöcke.
Das Steuerstudioobjektsystem 130 befähigt einen Anwender, Objekte zu den Diagrammen hinzuzufügen, Objekte nach dem Drag-and-Drop-Verfahren zwischen Diagrammen und Anwendungen einer dritten Partei zu verschieben, Objekte zu schneiden und zwischen Diagrammen und anderen Anwendungen einzufügen und Prozeßsteuerumgebungen zu installieren, die durch die Diagramme herausgegriffen werden und Objekte für die Prozeßsteuerumgebung enthalten.
Anwenderinterfaceaspekte des Steuerstudioobjektsystems
Gemäß 4 enthält ein Hauptsteuerfenster des Steuerstudioobjektsystems 130 textmäßige Pulldown-Menüs 402, ein piktografisches Menü 404, eine Schablonenabschnittspräsentation 406 und eine Diagrammabschnittsbildschirmpräsentation 408. Die Schablonenpositionen oder -posten 420 werden innerhalb der Schablonenabschnittspräsentation 406 dargestellt. Das Diagramm des Anwenders der Prozeßsteuerumgebungskonstruktion wird durch die Diagrammabschnittsbildschirmpräsentation dargeboten. Dieses Diagramm der Prozeßsteuerkonstruktionsumgebung wird als eine Prozeßsteuerumgebungsansicht bezeichnet. Jede der Präsentationen in dem Hauptfenster ist in der Größe neu einstellbar und neu plazierbar, und zwar durch den Anwender in Einklang mit bekannten Window-Techniken. Das Steuerstudiosystem 130 verfolgt die Örtlichkeit und Größe der Ebenen des Hauptfensters durch Aufrechterhalten bestehender Objektdaten, welche die Koordinaten enthalten, innerhalb einer zweidimensionalen Darstellung als auch den Stil und andere Informationen.
Wenn eine Prozeßsteuerumgebung konstruiert wird, betätigt der Anwender einfach einen Schablonenposten aus der Schablonenabschnittspräsentation 408, zieht den aktuellen Schablonenposten zu einer gewünschten Stelle innerhalb der Diagrammabschnittsbildschirmpräsentation 408 und läßt den ak tuellen Schablonenposten an einer gewünschten Stelle fallen. Das Steuerstudioobjektsystem 130 erzeugt dann einen Diagrammposten, welches es dem Diagramm ermöglicht, ein Objekt zu erzeugen, und zwar mit all den Informationen, die zum Konfigurieren einer Prozeßsteuerumgebung erforderlich sind. Da die Schablonenposten Objekte sind, die all die erforderlichen Informationen für das Diagramm enthalten, um eine Prozeßsteuerumgebung zu konfigurieren, wenn die Konstruktion der Prozeßsteuerumgebung innerhalb eines Diagrammabschnitts abgeschlossen oder vervollständigt ist, kann diese Konstruktion direkt zu den geeigneten Abschnitten der Prozeßsteuerumgebung downgeloaded werden.
Gemäß den 5a–5f ist ein Prozeß zum Installieren eines vervollständigten Prozeßsteuerdiagramms an einem Knotenpunkt gezeigt. Spezifischer gesagt, wählt ein Anwender, wie dies in 5a gezeigt ist, dann, wenn der Anwender wünscht, ein Prozeßsteuerdiagramm an einem Knotenpunkt zu installieren, den Installieren-am-Knotenpunkt-Posten von dem Dateimenü aus. Die Auswahlen, die dem Anwender geboten werden, bestehen darin, ob der gesamte Modul oder lediglich Änderungen installiert werden sollen, seit die letzte Installationsoperation durchgeführt worden ist. Wenn der Anwender die Installation des gesamten Moduls auswählt, wird ein Fenster präsentiert, welches den Anwender darüber informiert, daß der Modul nicht einem Knotenpunkt zugeordnet worden ist, wobei er gefragt wird, ob der Anwender wünscht, den Modul an einem Knotenpunkt zu installieren (siehe 5b). Als nächstes wird dem Anwender eine Liste von Knotenpunkten präsentiert, von der er den geeigneten Knotenpunkt für die Konfigurierung auswählen kann (siehe 5c). Nachdem der Anwender den Knotenpunkt für die Konfigurierung ausgewählt hat, wird dem Anwender ein Fenster dargeboten, indem er gefragt wird, ob er wünscht, den Modul auf den neuesten Stand zu bringen (siehe 5d). Der Anwender wird dann gefragt, den Modul zu benennen (siehe 5e).
Nachdem der Anwender einen Namen ausgewählt oder erzeugt hat, wird der Anwender gefragt, ob der Anwender sicher ist, daß er wünscht, die Installationsprozedur durchzuführen (siehe 5f). Indem er mit ja antwortet, führt das Steuerstudioobjektsystem 130 automatisch die Installation zu dem ausgewählten Modul durch.
Implementierung des Steuerstudioobjektsystems
Die Prozeßsteuerumgebung 100 und spezifisch das Steuerstudioobjektsystem 130 wird unter Verwendung eines objektorientierten Gerüstes implementiert. Ein objektorientiertes Gerüst verwendet objektorientierte Konzepte, wie beispielsweise Klassenhierarchien, Objektzustände und Objektverhalten. Diese Konzepte, die im folgenden kurz erläutert werden, sind auf dem Gebiet gut bekannt. Das vorhandene objektorientierte Gerüst wird geschrieben unter Verwendung der objektorientierten C++-Programmiersprache, die auf dem Gebiet gut bekannt ist.
Der Herstellungsblock eines objektorientierten Gerüstes ist ein Objekt. Ein Objekt ist durch einen Zustand und ein Verhalten definiert. Der Zustand eines Objekts wird durch Felder des Objekts angegeben. Das Verhalten eines Objekts wird durch Verfahren des Objekts angegeben. Jedes Objekt bildet einen Moment einer Klasse, die eine Schablone für das Objekt schafft. Eine Klasse definiert null oder mehrere Felder und null oder mehrere Verfahren.
Die Felder bestehen aus Datenstrukturen, welche Informationen enthalten, welche Objektdaten definieren oder einen Abschnitt des Zustands eines Objekts definieren. Objekte, die Momente der gleichen Klasse sind, haben die gleichen Felder. Jedoch können die speziellen Informationen, die innerhalb der Felder der Objekte enthalten sind, von Objekt zu Objekt variieren. Jedes Feld kann Informationen enthalten, die aus direkten Informationen, wie beispielsweise einem ganzzahligen Wert bestehen, oder indirekten Informationen, wie beispielsweise eine Bezugnahme auf ein anderes Objekt.
Ein Verfahren ist eine Sammlung von Computerbefehlen, die in dem Prozessor 116 durch die Computersystemsoftware ausgeführt werden können. Die Befehle eines Verfahrens werden ausgeführt, das heißt es wird das Verfahren durchgeführt, wenn die Software anfragt, daß das Objekt, für welches das Verfahren definiert ist, das Verfahren ausführt. Ein Verfahren kann durch ein Objekt ausgeführt werden, welches eine Zahl der Klasse ist, die das Verfahren enthält. Ein bestimmtes Objekt, welches das Verfahren durchführt, besteht aus dem Antwortgeber oder dem antwortenden Objekt. Wenn das Verfahren ausgeführt wird, verbraucht der Antwortgeber ein oder mehrere Argumente, das heißt Eingangsdaten, und erzeugt eine Null oder ein Ergebnis, das heißt ein Objekt, welches als Ausgangsdaten zurückgeleitet wird. Die Verfahren für ein bestimmtes Objekt definieren das Verhalten dieses Objekts.
Die Klassen eines objektorientierten Gerüstes sind in einer Klassenhierarchie organisiert. In einer Klassenhierarchie vererbt eine Klasse die Felder und Verfahren, die durch die Superklassen dieser Klasse definiert sind. Zusätzlich werden die Felder und Verfahren, die durch eine Klasse definiert sind, durch irgendwelche Subklassen der Klasse vererbt. Das heißt, ein Moment einer Subklasse enthält die Felder, die durch die Superklasse definiert sind, und kann die Verfahren, die durch die Superklasse definiert sind, ausführen. Wenn demzufolge ein Verfahren eines Objekts aufgerufen wird, kann das Verfahren, auf das zugegriffen wird, in der Klasse definiert werden, von der das Objekt ein Mitglied ist, oder in irgendeiner der Superklassen der Klasse, von der das Objekt ein Mitglied ist. Wenn ein Verfahren eines Objektes aufgerufen wird, wählt die Prozeßsteuerumge bung 100 das Verfahren aus, welches laufen soll, indem die Klasse des Objekts geprüft wird, und, wenn dies erforderlich ist, irgendwelche Superklassen des Objekts.
Eine Subklasse kann einer Verfahrensdefinition übergeordnet sein oder diese überstimmen, die von einer Superklasse vererbt wird, um das Verhalten der Subklasse zu erhöhen oder zu ändern. Jedoch kann eine Subklasse nicht über der Signatur des Verfahrens überwiegen. Die Signatur eines Verfahrens enthält den Verfahrensidentifizierer, die Zahl und den Typ der Argumente, ob ein Ergebnis zurückgeführt oder zurückgeleitet wird, und, wenn dies der Fall ist, den Typ des Ergebnisses. Die Superklasse überwiegt gegenüber einer vererbten Verfahrensdefinition, und zwar durch redefinieren der Computerbefehle, die bei der Ausführung des Verfahrens durchgeführt werden.
Klassen, welche die Fähigkeit der Momente haben (instances) sind konkrete Klassen. Klassen, die keine Momente haben, sind abstrakte Klassen. Abstrakte Klassen können Felder und Verfahren definieren, die durch Subklassen der abstrakten Klassen vererbt werden. Die Subklassen einer abstrakten Klasse können aus anderen abstrakten Klassen bestehen; jedoch sind ultimativ innerhalb der Klassenhierarchie die Subklassen konkrete Klassen.
Alle Klassen, die in der offenbarten bevorzugten Ausführungsform definiert sind, ausgenommen den eingemischten Klassen, die weiter unten beschrieben werden, sind Subklassen einer Klasse CObject. Somit vererbt jede Klasse, die hier beschrieben ist und die nicht aus einer eingemischten Klasse besteht, die Verfahren und Felder der Klasse CObject, die eine grundlegende Klasse innerhalb des Microsoft-Grundklassengerüstes darstellt.
Spezifischer gesagt, wird das Steuerstudioobjektsystem 130 unter Verwendung der Grundklassenversion 4.0 des Microsoft-Entwicklerkits für Visual C++ für Windows NT, Version 3.51, implementiert.
Gemäß 6 enthält das Steuerstudioobjektsystem 130 eine Vielzahl von Klassen, die von der Grundklasse CMDIChildWnd 602 aus absteigen und diese betreffen. Die Klasse CMdeMDI-ChildWnd 604 fällt von der Klasse CMDIChildWnd 602 aus ab bzw. steigt von dieser aus ab. Die Klasse CSplittChildWnd 606 steigt von der Klasse CMDIChildWnd 604 aus ab. Die Klassen CStencilView 608, CSplitterWnd 610 und CDiagramOcx-View 612 sind mit der Klasse CSplitChildWnd 606 zusammengefaßt. Die Klassen CStencilView 608 und CDiagramOCXView steigen von der Grundklasse CFormView 614 aus ab.
Die Klasse CMDIChildWnd 602 ist ein Rahmenfenster für ein Kindfenster für eine Vielfachdokumentinterfaceanwendung. Die Klasse CMdeMDIChildWnd 604 entfernt den Titeltext von der Bildschirmpräsentation. Die Klasse CSplitChildWnd 606 erzeugt das Management des Kindes in einer gesplitteten Window-Weise, wie dies auf dem Gebiet bekannt ist. Die Klasse CStencilView 608 hält eine CList-Schablonensteuerung aufrecht und managt das Schablonenanwenderinterface des Schablonenabschnitts. Die Klasse CDiagramOcxView 612 managt das Diagrammanwenderinterface des Diagrammabschnitts und enthält ein Moment oder einen Punkt einer Diagramm-Alt-Anwendersteuerung (OCX). Die Klasse CSplitterWnd 610 ist eine Grundklasse, die das Aufteilen von Teilfenstern (pans) steuert, wie dies auf dem Gebiet gut bekannt ist. Die Klasse CFormView 614 ist eine Grundklasse für die Aufnahme von Steuerklassen.
Gemäß 7 enthält das Steuerstudioobjektsystem 130 eine Vielzahl von Klassen, die von Grundklassen CListCtrl 702 und CImageList 704 aus absteigen und darauf gezogen sind.
Spezifischer gesagt, steigen die Klassen CStencilListCtrl 706 von der Klasse CListCtrl 702 aus ab. Die Klassen CFbStencilView 708 und CSfcStencilView 710 sind mit CStencilListCtrl 706 gepackt. Die Klassen CFbStencilView 708 und CSfcStencilView 710 steigen von der Klasse CStencilView 712 ab. Die Grundklasse CImageList 704, die Klasse CStencilItem 714 und die Klasse CStencilDropTarget 716 sind der Klasse CStencilListCtrl 706 zugeordnet. Die Klasse CStencilDrop-Target 716 fällt von der Klasse COleDropTarget 718 aus ab. Die Klasse CStencilItem 714 ist von der Grundklasse CObject 720 aus absteigend.
Die Klasse CListCtrl 702 ist eine Grundklasse, die die Funktionalität einer Listenbetrachtungssteuereinheit einschließt. Die Klasse CImageLst 704 ist eine Grundklasse, welche die Funktionalität einer Bildliste einschließt. Die Klasse CStencilListCtrl 706 managt Schablonenposten, erzeugt eine Ansicht oder Darstellung der Schablonenposten und erzeugt die Drag-Quellenfähigkeit. Die Klasse CFBStencilView 708 steuert die Schablone oder die Schablonen, die dazu verwendet werden, um Funktionsblockdiagramme zu erzeugen. Die Klasse CSfcStencilView 710 steuert die Schablone oder die Schablonen, die zum Erzeugen der SFC-Diagramme verwendet werden. CStencilItem 714 enthält die Drag-/Drop-Information für einen einzelnen Posten in der Schablonenlistensteuereinheit. CStencilDropTarget 716 steuert die Drag- and-Drop-Benachrichtigungsnachrichten für die Klasse CStencilListCtrl f06. COleDropTarget 718 ist eine Grundklasse, welche die Funktionalität des Ablegens in einer Drag-/Drop-Operation einschließt.
Gemäß 8 enthält das Steuerstudioobjektsystem 130 eine Vielzahl von Klassen, die von der Grundklasse CObject 802 aus absteigen. Spezifischer gesagt, steigt die Klasse C1twtBase 804 von der Klasse CObject 802 aus ab. Die Klassen C1twtAttribute 806, C1twtUsage 808, CLtwtSfcStepData 810, CLtwtSFCTransistionData 812 und CLtwtGraphic 814 steigen von der Klasse C1twtBase 804 aus ab. Jede dieser Klassen repräsentiert unterschiedliche Typen von Diagrammposten, die in einer Drag-and-Drop-Operation verwendet werden können. Die Klasse GLtwtUsageAll 822 steigt von der Klasse CLtwtUsage 808 aus ab. Die Klassen CLtwtUsageConnectorAttrs 820 und GLtwtUsageAll 822 sind auch mit der Klasse CLtwtAttribute 806 gepackt. Die Klasse CLtwtConnNameAttrName 826 ist mit der Klasse CLtwtUsageAll 822 gepackt. Die Klasse CLtwtSfcStepActionData 832 steigt von der Klasse CLtwtSfcStepData 810 aus ab. Die Klasse CLtwtSfcStepAction-Data 832 ist mit der Klasse CLtwtSfcStepsAndRctions 830 gepackt. Die Klassen CLtwtComment 840 und CLtwtBox 842 steigen von der Klasse CLtwtGraphic 814 aus ab.
Die Klasse CLtwtAttribute 806 speichert Daten von der Datenbank oder schreibt Daten in die Datenbank ein, und zwar zu den Attributen der Klasse CLtwtUsage 808, die einen Lichtgewichtsdatenhalter für Verwendungsinformationen darstellt, die dazu verwendet werden, um Daten zwischen der Datenbank und Anwendungen zu transferieren; diese Klasse wird in erster Linie durch Funktionsblockdiagramme verwendet, jedoch verwenden sequentielle Funktionsdiagrammalgorithmen diese Klasse in einer begrenzten Weise. Die Klasse CLtwtUsageAll 822 ist eine Subklasse von CLtwtUsage und enthält zusätzliche Informationen, inklusive einer Liste von Eingangs- und Ausgangs-CLtwtConnNameAttrName-Objekten und einer Liste von CLtwtAttributes-Objekten; diese Klasse wird beim Drag and Drop verwendet, um irgendein Attribut oder Verbindung einzustellen, welches gegenüber demjenigen überwiegt, welches der Anwender für eine spezifische Verwendung erstellt haben kann. Die Klasse CLtwtSfcStepData 810 ist ein Leichtgewichtsdatenhalter, der einen Schritt in einem sequentiellen Funktionsdiagrammalgorithmus wiedergibt. Die Klasse CLtwtGraphic 814 implementiert das Verhalten, welches allen Grafikobjekten gemeinsam ist, wie bei spielsweise Kästchen und Erläuterungen. Die Klasse CLtwtSfcStepActionDate 832 ist eine Repräsentation einer einzelnen sequentiellen Funktionsdiagrammaktion. Die Klasse CLtwtStepsAll 830 ist eine spezifische Repräsentation eines Schrittes, der Aktionen enthält, die für Drag and Drop verwendet werden. Die Klasse CLtwtBox 842 ist eine Subklasse der CLtwtGraphic-Klasse, die ein Datenbankobjekt repräsentiert, welches seinerseits ein Kästchen oder Rechteck an einem Algorithmus wiedergibt. Die Klasse CLtwtComment 840 ist eine Subklasse von CLtwtGraphic, die ein Datenbankobjekt repräsentiert, welches seinerseits den Text repräsentiert, den ein Anwender an einem Algorithmus eingegeben hat. Die Klasse CLtwtBase 804 ist eine abstrakte Basisklasse, die einen Weg liefert, um eine Repräsentation von solchen Datenbankobjekten zu managen, die in einem Diagramm erscheinen können. Die Klasse CLtwtSFCTransistionData 812 ist eine Repräsentation eines Übergangsobjektes in einem SFC-Algorithmus. Die Klasse CLtwtConnNameAddrName 826 ist eine Repräsentation eines Attributs und des Namens des Anschlusses oder Steckers, der dem Attribut zugeordnet ist lediglich bestimmte Attribute haben Stecker, welche diesen zugeordnet sind.
Gemäß 9 enthält das Steuerstudioobjektsystem eine Vielzahl von Klassen, die ebenfalls von der Grundklasse CObject 802 aus absteigen und die sich auf das Verbinden anderer Posten beziehen. Spezifischer gesagt, fällt die Klasse CLtwtConnectionBase 904 von der Klasse CObject 802 aus ab. Die Klassen CLtwtSFCConnection 906 und CLtwtFBCConnection 908 steigen von der Klasse CLtwtConnectionBase 904 aus ab.
Die Klasse CLtwtConnectionBase 904 ist eine Repräsentation eines Verbindungsobjektes. Bei der bevorzugten Ausführungsform bilden zwei Typen von Bindungsobjekten einen Funktionsblock oder sequentielle Funktionsdiagrammverbindungen.
CLtwtSfcConnection 906 schafft eine Repräsentation einer Verbindung an einem sequentiellen Funktionsdiagrammalgorithmus in der Datenbank. Die Klasse CLtwtFbConnection 908 erzeugt eine Repräsentation einer Verbindung an einem Funktionsblockalgorithmus in der Datenbank.
Gemäß 10 enthält das Steuerstudioobjektsystem 130 eine Klasse, die von der Grundklasse COleDropTarget 1002 aus absteigt. Spezifischer gesagt, steigt die Klasse CDiagram-DropTarget 1004 von der Grundklasse COleDropTarget 1002 aus ab. Die Klassen CDiagramCtrl 1006 und CClipboardFormats 1008 sind mit der Klasse CDiagramDropTarget 1004 gepackt. Die Klasse CDiagramCtrl 1006 steigt von der Klasse COleControl 1010 aus ab. Die Klasse CDiargramCtrl 1006 ist mit der Klasse CDiagramOcxView 1012 gepackt.
Die Klasse CDiagramCtrl 1006 erzeugt eine grafische Repräsentation und eine Einrichtung zur Manipulation von Objekten für den Funktionsblock und den sequentiellen Funktionsblockdiagrammalgorithmus; diese Klasse ist eine OLE-Steuerklasse. Die Klasse CDiagramDropTarget 1004 repräsentiert ein Zielfenster einer Diagramm-Drag-and-Drop-Operation; diese Klasse bestimmt, ob irgendwelche Daten angenommen werden sollen, die auf diese fallengelassen werden und sie ruft das OnDrop-Verfahren des CDiagramCtrl-Objekts auf (welches seinerseits den OnDrop-Event zu dem Behältnis feuert, welches tatsächlich das abgelegte oder fallengelassene Objekt in der Datenbank erzeugt). Die Klasse CClipboardFormats 1008 hält ein Array von registrierten Formaten, die für ein Ablegen durch OCX unterstützt werden. Die Klasse COleControl 1010 ist eine Grundklasse zum Entwickeln von OLE-Steuerungen. Die Klasse CDiagrmOcxView 1012 wurde in Verbindung mit 6 erläutert.
Gemäß 11 enthält das Steuerstudioobjektsystem 130 eine Klasse, die von der Klasse CObject 802 aus absteigt und welche die Funktion des Aufnehmens und Ablegens von Posten betrifft oder das Zerschneiden und Aufteilen von Posten betrifft, die bereits in dem Diagramm existieren. Die Klasse CNativeDragDrop 1104 steigt von der Klasse CObject 1102 aus ab. Die Klassen CLtwtConnectionBase 904 und C1twtBase 1108 sind mit der Klasse CNativeDragDrop 1104 gepackt.
Die Klasse CNativeDragDrop 1104 ist eine Sammelklasse, die eine Liste von CLtwtBase- und CLtwtConnectionBase-Objekten hält, die momentan an dem Diagramm existieren und die nach dem Drag-and-Drop-Verfahren zu behandeln sind oder die geschnitten/kopiert und zusammengefügt werden; dieses Objekt speichert auch einen Positionsoffset, der dazu beiträgt, die geeignete Lokalität während der Zusammenfüge-/Ablegeoperation einzustellen. Eine Klasse-CNativeDragDrop-1104-Objekt schafft Verfahren, um sich selbst in einem Serienformat zu und von einer gemeinsam verwendeten Datei umzusetzen und um Daten von den COleDataSource- und COleDataObject-Objekten einzustellen und zu bekommen. Die Klasse CLtwtBase 1108 ist eine abstrakte Grundklasse für Objekte, die Datenobjekte in der Datenbank repräsentieren. Die Klasse CLtwtConnectionBase 904 wurde oben unter Hinweis auf 9 erläutert.
Betrieb des Steuerstudioobjektsystems
Das Steuerstudioobjektsystem 130 enthält eine Vielzahl von Betriebsmodi zum Hinzufügen von Objekten zu einem Diagrammabschnitt des Objektsystems 130. Diese Betriebsmodi enthalten das Hinzufügen eines Objektes zu einem Diagrammabschnitt und das Hinzufügen eines Objektes zu einem Schablonenabschnitt.
Wenn ein Schablonenobjekt von dem Schablonenabschnitt zu dem Diagrammabschnitt hinzugefügt wird, positioniert der Anwender einen Cursor (nicht gezeigt) über ein Schablo nenobjekt in dem Quellenschablonenfenster, das heißt dem Schablonenabschnitt, und betätigt eine Zeigervorrichtung, wie beispielsweise eine Maus. Das Schablonenobjekt in dem Schablonenfenster wird hell erleuchtet, um die Auswahl anzuzeigen. Wenn sich der Cursor über dem ausgewählten Schablonenobjekt befindet, hält der Anwender die linke Maustaste gedrückt und beginnt mit dem Ziehen des Cursors, indem er die Maus bewegt. Die Workstation antwortet dann, indem sie ein Drag-Bild der Schablone darstellt, welches sich mit dem Cursor bewegt. Der Anwender positioniert als nächstes den Cursor über den Diagrammabschnitt. Indem der Anwender damit fortfährt, den Cursor über das Diagrammfenster zu ziehen, veranlaßt das Objektsystem 130 den Cursor, auf den neuesten Stand gebracht zu werden, um zu zeigen, daß er sich über einem Drop-Ziel befindet, indem ein Cursorpfeil wiedergegeben wird, und zwar mit einem Rechteck, welches daran gekoppelt ist. Wenn der Anwender den Cursor außerhalb des Randes des Diagrammabschnittfensters bewegt, so stellt das System den Cursor mit einem Kreis dar, mit einer diagonalen Linie durch denselben, um anzuzeigen, daß sich der Cursor nicht über einem Ablegeziel befindet. Wenn der Anwender den Cursor zu der Position bewegt hat, bei der das neue Objekt zu dem Diagramm hinzuzufügen ist, läßt der Anwender die linke Maustaste los. Als Antwort entfernt das System das dargestellte Drag-Bild und stellt den Cursor neu dar, und zwar in normaler Form, und erzeugt ein entsprechendes Diagrammobjekt in dem Diagrammfenster bzw. stellt dieses dar. Wenn der Anwender anstelle des Loslassens der Maustaste die Escapetaste an dem Keyboard drückt, so löscht das System den Drag-and-Drop-Vorgang. Wenn der Anwender die Maustaste losläßt, während er sich noch in dem Schablonenabschnittsfenster befindet, antwortet das System durch Bewegen des ausgewählten Schablonenobjektes zu der neuen Position in dem Schablonenabschnittfenster und stellt den Cursor auf den normalen Zustand zurück. Die Klassen, die zum Implementieren dieser Funktionalität verwendet werden, sind CStencilListCtrl, CImageList, CDiagramDropTarget, CStencilDropTarget, CStencilItem und CDiagramCtrl, CDiagramOcxView, CNativeDragDrop.
Gemäß 12A ist die Betriebsweise des Steuerstudioobjektsystems 130 während einer Schablonen-Drag-/-Drop-Operation gezeigt. Eine Drag-/Drop-Operation startet bei dem Schritt 1202, wenn der Anwender ein Schablonenobjekt mit der linken Maustaste auswählt und damit beginnt, das Schablonenobjekt zu ziehen. Die Steuerung verläuft dann zu Übergängen zu dem Verarbeitungsschritt 1204, während welchem das OnBeginDrag-Verfahren der Klasse CStencilListCtrl f06 aufgerufen wird. Das Verfahren OnBeginDrag erzeugt ein Ziehbild des Schablonenobjekts 1205. Bei der Vervollständigung des Schrittes 1204 wechselt die Steuerung zu dem Verarbeitungsschritt 1206, während welchem das Verfahren CStencilListCtrl die COleDataSource- und COleDropSource-Objekte erzeugt. Bei dem Schritt 1206 werden dann die Daten von dem ausgewählten Schablonenobjekt in eine CSharedFile 1207 eingelesen. Von dem Schritt 1206 aus verläuft die Steuerung dann zu dem Schritt 1208, während welchem das Do-DragDrop-Verfahren des COleDataSource-Objektes aufgerufen wird. Die Steuerung verläuft dann zu dem Entscheidungsschritt 1210.
Gemäß 12B bestimmt das Steuerstudioobjektsystem 130 während des Entscheidungsschrittes 1210, ob die linke Maustaste weiterhin durch den Anwender gedrückt wird. Wenn die Maustaste gedrückt wird, verläuft die Steuerung zu dem Entscheidungsschritt 1212 (siehe 12C).
Wenn die Maustaste nicht gedrückt gehalten wird, so geht das Steuerstudioobjektsystem 130 in den Entscheidungsschritt 1214 über. Während des Entscheidungsschrittes 1214 bestimmt das Steuerstudioobjektsystem 130, ob der Cursor über dem Schablonenabschnitt positioniert ist, der als eine StencilListControl (Schablonenlistensteuerung) funktioniert. Wenn der Cursor über dem Schablonenabschnitt positioniert wird, wechselt die Steuerung zu dem Prozeßschritt 1216, während welchem das Stencils-OnDrop-Ereignis aktiviert wird. Nachdem das Stencils-OnDrop-Ereignis aktiviert worden ist, geht die Steuerung in den Entscheidungsschritt 1220 über (siehe 12e).
Wenn der Cursor nicht über der Schablonenlistensteuerung positioniert ist, so wechselt die Steuerung zu dem Entscheidungsschritt 1222. Während des Entscheidungsschrittes 1222 bestimmt das Steuerstudioobjektsystem 130, ob der Cursor sich über einem Diagrammabschnitt befindet. Wenn sich der Cursor über einem Diagrammabschnitt befindet, wechselt die Steuerung zu dem Verarbeitungsschritt 1224 und es wird das Diagram-OnDrop-Ereignis aktiviert. Nachdem das Diagram-OnDrop-Ereignis aktiviert worden ist, verläuft die Steuerung zu dem Schritt 1226 (siehe 12d). Wenn der Cursor sich nicht über einem Diagramm bei dem Entscheidungsschritt 1222 befindet, dann wechselt die Steuerung zu dem Beendigungsschritt 1228 und die Drag-and-Drop-Operation wird beendet.
Gemäß 12C bestimmt das Steuerstudioobjektsystem 130 während des Entscheidungsschrittes 1212, ob der Cursor über der Schablonenlistensteuereinheit positioniert ist. Wenn der Cursor nicht über der Schablonenlistensteuereinheit positioniert ist, dann wechselt die Steuerung zu dem Entscheidungsschritt 1230. Während des Entscheidungsschrittes 1230 bestimmt das Steuerstudioobjektsystem 130, ob der Cursor über der Schablonenlistensteuereinheit positioniert war, und zwar zu dem letzten Zeitpunkt, als die Cursorposition überprüft wurde. Wenn der Cursor nicht über der Schablonensteuerliste positioniert war, dann wechselt die Steuerung zu dem Entscheidungsschritt 1210. Wenn der Cursor über der Schablonensteuerliste positioniert war, und zwar zu dem letzten Zeitpunkt, zu dem die Cursorposition überprüft wurde, dann schreitet die Steuerung zu dem Schritt 1232 voran. Während des Schrittes 1232 aktiviert das Steuerstudioobjektsystem 130 das OnDropLeave-Ereignis, um anzuzeigen, daß der Cursor die Schablonenlistensteueransicht verlassen hat. Nachdem das OnDropLeave-Ereignis aktiviert worden ist, verläuft die Steuerung zu dem Entscheidungsschritt 1210.
Wenn während des Entscheidungsschrittes 1212 der Cursor über der Schablonensteuerliste positioniert ist, verläuft die Steuerung zu dem Entscheidungsschritt 1234. Während des Entscheidungsschrittes 1234 bestimmt das Steuerstudioobjektsystem 130, ob der Cursor über der Schablonensteuerliste positioniert war, und zwar zu dem letzten Zeitpunkt, bei dem das Objektsystem 130 die Cursorposition überprüft hat. Wenn der Cursor nicht über der Schablonensteuerliste positioniert war, und zwar zu dem letzten Zeitpunkt, zu dem die Cursorposition überprüft wurde, dann verläuft die Steuerung zu dem Verarbeitungsschritt 1236. Während des Verarbeitungsschrittes 1236 wird das OnDragEnter-Schablonenereignis aktiviert; OnDragEnter zeigt dem System an, daß der Cursor das Schablonenlistensteuerfenster betreten hat. Wenn der Cursor über der Schablonensteuerliste positioniert war, und zwar zu dem letzten Zeitpunkt, zu dem die Cursorposition überprüft worden ist, verläuft die Steuerung zu dem Verarbeitungsschritt 1238. Während des Verarbeitungsschrittes 1238 aktiviert das Objektsystem 130 das OnDragOver-Ereignis; OnDragOver wird durch das Objektsystem 130 dazu verwendet, um den Ablegeffekt zu bestimmen. Die Steuerung verläuft dann zu dem Entscheidungsschritt 1210, und zwar von sowohl dem Verarbeitungsschritt 1236 aus, als auch dem Verarbeitungsschritt 1238 aus, nachdem deren jeweilige Ereignisse aktiviert worden sind.
Gemäß 12D wird während des Verarbeitungsschrittes 1226 das OnDrop-Ereignis für CDiagramDropTarget 104 aktiviert. Nachdem das OnDrop-Ereignis aktiviert worden ist, verläuft die Steuerung zu dem Verarbeitungsschritt 1240, während welchem Schritt das OnDrop-Ereignis für CDiagramCtrl aktiviert wird. Nach der Aktivierung des OnDrop-Ereignisses verläuft die Steuerung zu dem Verarbeitungsschritt 1242. Während des Verarbeitungsschrittes 1242 wird das Verfahren CDiagramOcxView aufgerufen oder wachgerufen, und zwar mit COleDataObject als ein Parameter. Das Steuerstudioobjektsystem erhält dann eine Handhabe zu CSharedFile 1207 und wechselt zu dem Verarbeitungsschritt 1244. Während des Verarbeitungsschrittes 1244 erzeugt das Verfahren CdiagramOcx-View ein neues CStencilItem-Objekt und füllt dieses mit Daten von CSharedFile 1207. Bei der Vervollständigung des Schrittes 1244 wechselt die Steuerung zu dem Verarbeitungsschritt 1246. Während des Verarbeitungsschrittes 1246 erzeugt CDiagramOcxView einen Diagrammposten 1248, der an der Cursorposition gelegen ist. Nachdem der Diagrammposten erzeugt worden ist, ist die Drag-and-Drop-Operation des Schablonenobjekts vervollständigt.
Gemäß 12E bestimmt das Steuerstudioobjektsystem 130 während des Entscheidungsschrittes 1220, ob das Schablonenobjekt von dieser Schablonenlistensteuereinheit stammt; was anzeigt, ob der Schablonenposten seinen Ursprung von der CStencilListCtrl hat, über der der Cursor positioniert ist. Wenn das Schablonenobjekt von dieser Schablonenlistensteuereinheit stammt, so wechselt die Steuerung zu dem Verarbeitungsschritt 1250. Während des Verarbeitungsschrittes 1250 bewegt das Objektsystem 130 das Schablonenobjekt von seiner momentanen Position in die Schablonenlistensteuereinheit zu der Cursorposition. Nachdem die Bewegung des Schablonenobjekts vervollständigt worden ist, wechselt die Steuerung zu dem Vervollständigunqsschritt 1252 und die Drag-and-Drop-Operation ist dann vervollständigt. Wenn das Schablonenobjekt nicht von dieser Schablonenlistensteuereinheit stammt, so wechselt die Steuerung zu dem Verarbeitungsschritt 1254. Während des Verarbeitungsschrittes 1254 wird das Verfahren CStencilListCtrl mit dem COleDataObject aufgerufen, welches dazu verwendet wird, eine Handhabe für CSharedFile 1207 zu erhalten. Nachdem die Handhabe erhalten worden ist, verläuft die Steuerung zu dem Verarbeitungsschritt 1256. Während des Verarbeitungsschrittes 1256 erzeugt das Verfahren CStencilListCtrl ein neues CStencilItem-Objekt und füllt das Objekt mit den Schablonenobjektdaten von CSharedFile 1207. Die Steuerung schreitet dann zu dem Verarbeitungsschritt 1258 voran. Während des Verarbeitungsschrittes 1258 wird das Schablonenobjekt zu der Schablonenlistensteuereinheit 1260 an der Cursorposition addiert. Die Steuerung geht dann zu dem Vervollständigungsschritt 1252 über.
Gemäß 13A ist der Betrieb des Aufnehmens bzw. Ziehens und Ablegens von einem oder mehreren ausgewählten Posten innerhalb oder zwischen Diagrammen gezeigt. Spezifischer gesagt, wird bei einem Schritt 1302 eine Zieh- und Ablegeoperation initialisiert, indem der Anwender die Maus bei einem ausgewählten Posten betätigt und hält. Die Steuerung geht dann zu dem Verarbeitungsschritt 1304 über. Während des Verarbeitungsschrittes 1304 wird das OnBeginDrag.-Ereignis der CDiagramCtrl-Klasse aktiviert. Die Aktivierung dieses Ereignisses erzeugt COleDataSource- und COleDrop-Source-Objekte und aktiviert den OnBeginDrag-Event. Nach der Aktivierung des OnBeginDrag-Events bzw. -Ereignisses, wechselt die Steuerung zu dem Verarbeitungsschritt 1306 über. Während des Verarbeitungsschrittes 1306 erzeugt das Steuerstudioobjektsystem 130 ein CNativeDragDrop-Objekt, welches das OnBeginDrag-Verfahren des CNativeDragDrop-Objekts aufruft. Die Steuerung wechselt dann zu dem Verarbeitungsschritt 1308: Während des Verarbeitungsschrittes 1308 sichert das OnBeginDrag-Verfahren die Daten von all den ausgewählten Objekten in dem gemeinsam verwendeten Speicher bzw. Datei CSharedFile 1310. Die Steuerung verläuft dann zu dem Verarbeitungsschritt 1312, während welchem das CDiagramCtrl-Ereignis das DOragDrop-Verfahren des COleDataSource-Objektes aufruft. Die Steuerung geht dann in den Entscheidungsschritt 1320 über (siehe 13B).
Gemäß 13B bestimmt das Steuerstudioobjektsystem 130 während des Entscheidungsschrittes 1320, ob die Maustaste noch betätigt ist. Wenn die Maustaste noch betätigt ist, verläuft die Steuerung zu dem Entscheidungsschritt 1322. Während des Entscheidungsschrittes 1322 bestimmt das Objektsystem 130, ob der Cursor über einer gültigen Ablegestelle positioniert ist. Wenn der Cursor nicht über einer gültigen Ablegestelle positioniert ist, so wechselt die Steuerung zu dem Verarbeitungsschritt 1324. Während des Verarbeitungsschrittes 1324 erneuert CDiagramCtrl i06 den Cursor, um zu zeigen, daß die Drag-and-Drop-Operation stattfindet, und stellt auch ein umschließendes ausgezogenes Rechteck dar. Die Steuerung geht dann zurück zu dem Entscheidungsschritt 1320.
Wenn während des Entscheidungsschrittes 1322 das Objektsystem 130 bestimmt, daß der Cursor über einer gültigen Ablegestelle positioniert ist, so geht die Steuerung zu dem Verarbeitungsschritt 1326 über. Während des Verarbeitungsschrittes 1326 erneuert das Objektsystem 130 den Cursor, um anzuzeigen, daß er sich nicht über einer gültigen Ablegestelle befindet. Die Steuerung verläuft dann zurück zu dem Entscheidungsschritt 1320.
Wenn während des Entscheidungsschrittes 1320 die Klasse CDiagramCtrl i06 bestimmt, daß die Maustaste losgelassen worden ist, geht die Steuerung zu dem Entscheidungsschritt 1328 über. Während des Entscheidungsschrittes 1328 bestimmt das Objektsystem 130, ob der Cursor über einer gültigen Ab legestelle positioniert ist. Wenn der Cursor nicht über einer gültigen Ablegestelle positioniert ist, wechselt die Steuerung zu dem Beendigungssymbol 1330 und die Drag-and-Drop-Operation wird beendet. Wenn der Cursor über einer gültigen Ablegestelle positioniert ist, wechselt die Steuerung zu dem Verarbeitungsschritt 1332. Während des Verarbeitungsschrittes 1332 wird das OnDrop-Verfahren von CDiagramDropTarget aufgerufen. Das CDiagramDropTarget OnDrop-Verfahren ruft das CDiagramCtrl OnDrop-Verfahren bei dem Schritt 1342, welches dann das OnDrop-Ereignis zündet (siehe 13C).
Gemäß 13C ruft das Objektsystem 130 während des Verarbeitungsschrittes 1340 das OnDrop-Verfahren der CDiagram-Ctrl-Klasse auf. nachdem das OnDrop-Verfahren aufgerufen worden ist, verläuft die Steuerung zu dem Verarbeitungsschritt 1342. Während des Verarbeitungsschrittes 1342 zündet das Objektsystem 130 das OnDrop-Ereignis. Nachdem das OnDrop-Ereignis aktiviert worden ist, wechselt die Steuerung zu dem Verarbeitungsschritt 1344 über. Während des Verarbeitungsschrittes 1344 erzeugt das Objektsystem 130 ein CNativeDragDrop-Objekt und wechselt zu dem Verarbeitungsschritt 1346 über. Während des Verarbeitungsschrittes 1346 ruft das Objektsystem 130 das OnDrop-Verfahren des CNativeDragDrop-Objekts auf. Die Steuerung verläuft dann zu dem Verarbeitungsschritt 1348. Während des Verarbeitungsschrittes 1348 liest das OnDrop-Verfahren die Daten, die an früherer Stelle serialisiert worden sind, in eine gemeinsam benutzte Datei 1310 ein. Die Steuerung verläuft dann zu dem Verarbeitungsschritt 1350. Während des Verarbeitungsschrittes 1350 versetzt das Verfahren CNativeDragDrop die Positionen der abgelegten Objekte. Die Steuerung wechselt dann zu dem Verarbeitungsschritt 1352. Während des Verarbeitungsschrittes 1352 erzeugt das Objektsystem 130 ein neues Objekt in der Datenbank. Die Steuerung geht dann zu dem Entscheidungsschritt 1360 über (siehe 13D).
Gemäß 13D bestimmt das Objektsystem während des Entscheidungsschrittes 1360, ob ein anderes abgelegtes Objekt vorhanden ist. Wenn ein anderes abgelegtes Objekt vorhanden ist, verläuft die Steuerung zu dem Verarbeitungsschritt 1362. Während des Verarbeitungsschrittes 1362 erzeugt das Objektsystem 130 das abgelegte Objekt in dem Diagrammabschnitt. Die Steuerung verläuft dann zu dem Verarbeitungsschritt 1364. Während des Verarbeitungsschrittes 1364 wählt das Objektsystem 130 das neu erzeugte Diagrammobjekt aus und es erfolgt ein Übergang zu dem Entscheidungsschritt 1360, um zu bestimmen, ob ein anderes abgelegtes Objekt vorhanden ist. Wenn keine abgelegten Objekte mehr vorhanden sind, verläuft die Steuerung zu dem Verarbeitungsschritt 1366. Während des Verarbeitungsschrittes 1366 erneuert das Objektsystem 130 alle sichtbaren Fenster, um Änderungen, die in dem Diagramm vorgenommen wurden, zu reflektieren. Die Steuerung wechselt dann zu dem Beendigungssymbol 1368 über und die Drag-and-Drop-Operation ist vervollständigt.
Gemäß den 14A–14D ist der Betrieb des Zerschneidens, Kopierens und Einfügens von einem oder mehreren Objekten von dem Diagramm gezeigt. Spezifischer gesagt, wählt ein Anwender während einer Schneidoperation den Schneidbefehl aus, wie dies bei dem Schritt 1402 gezeigt ist. Nachdem der Schneidbefehl ausgewählt worden ist, geht die Steuerung zu dem Entscheidungsschritt 1404 über. Während des Entscheidungsschrittes 1404 bestimmt das Objektsystem 130, ob alle ausgewählten Typen durch die Schneidoperation unterstützt werden. Wenn all die ausgewählten Typen nicht durch die Schneidoperation unterstützt werden, verläuft die Steuerung zu dem Verarbeitungsschritt 1406. Während des Verarbeitungsschrittes 1406 warnt das Objektsystem 130 den Anwender und fragt, ob der Anwender wünscht, fortzufahren. Die Steuerung wechselt dann zu dem Entscheidungsschritt 1408. Während des Entscheidungsschrittes 1408 bestimmt das Ob jektsystem 130, ob der Anwender wünscht, fortzufahren. Wenn der Anwender nicht fortfahren auswählt, wechselt die Steuerung zu dem Beendigungsschritt 1409 und die Schneidoperation wird fallengelassen. Wenn der Anwender fortfahren wählt oder wenn alle ausgewählten Objekttypen durch die Schneidoperation unterstützt werden, wie dies durch den Entscheidungsschritt 1404 bestimmt wurde, so wechselt die Steuerung zu dem Verarbeitungsschritt 1410 (siehe 14B).
Gemäß 14B erzeugt das Objektsystem 130 während des Verarbeitungsschrittes 1410 CNativeDragDrop- und COleDataSource-Objekte und ruft das OnBeginDrag-Verfahren des CNativeDragDrop-Objekts auf. Die Steuerung wechselt dann zu dem Verarbeitungsschritt 1412. Während des Verarbeitungsschrittes 1412 serialisiert das OnBeginDrag-Verfahren die Daten der ausgewählten Objekte für eine gemeinsam verwendete Datei 1414. Die Steuerung geht dann in den Verarbeitungsschritt 1416 über. Während des Verarbeitungsschrittes 1416 ruft das OnBeginDrag-Verfahren die Daten zu der COle-DataSource ab. Die Steuerung wechselt dann in den Verarbeitungsschritt 1418. Während des Verarbeitungsschrittes 1418 wird das CopyObject-Verfahren des CDiagramCtrl-Objekts aufgerufen. Die Steuerung wechselt dann zu dem Verarbeitungsschritt 1420. Während des Verarbeitungsschrittes 1420 kopiert das Verfahren CopyObject die Objekte in verschiedenen Formaten in das Clipboard. Bei der Vervollständigung wechselt das Objektsystem 130 zu der Aufruffunktion und der Kopiervorgang wird vervollständigt. Das Steuerstudioobjektsystem 130 wechselt dann in den Verarbeitungsschritt 1333, bei dem alle ausgewählten Objekte freigegeben oder weggelassen werden und wechselt dann zu dem Vervollständigungsschritt 1435, woraufhin der Schneidvorgang vervollständigt ist.
Gemäß 14C wählt ein Anwender während einer Kopieroperation den Kopierbefehl, wie dies bei dem Schritt 1432 ge zeigt ist. Nachdem der Kopierbefehl ausgewählt worden ist, verläuft die Steuerung zu dem Verarbeitungsschritt 140, der oben beschrieben ist (siehe 14B).
Gemäß 14D wählt ein Anwender während einer Einfüge- oder Zusammenfügeoperation den Einfügebefehl, wie dies bei dem Schritt 1440 gezeigt ist. Nachdem der Einfügebefehl ausgewählt worden ist, verläuft die Steuerung zu dem Verarbeitungsschritt 1442. Während des Verarbeitungsschrittes 1442 erzeugt das Objektsystem 130 CNativeDragDrop- und COleDataObject-Objekte. Die Steuerung verläuft dann zu dem Verarbeitungsschritt 1446 (siehe 13C).
Gemäß 15 ist die Betriebsweise des Steuerstudioobjektsystems 130 gezeigt. Spezifischer gesagt, wenn ein Anwender wünscht, ein Prozeßsteuerdiagramm bei einem Knotenpunkt (node) zu installiere, so wählt der Anwender den Installiere-zu-Knotenpunkt-Posten von dem Dateimenü aus. Basierend auf der Eingabe des Anwenders bestimmt das Objektsystem 130 dann, ob der gesamte Modul oder lediglich die Änderungen installiert werden, und zwar seit die letzte Installationsoperation vorgenommen worden ist. Wenn der Anwender Installieren des gesamten Moduls wählt, wo wurde der Modul noch nicht zu einem Knotenpunkt zugeordnet und das Objektsystem 130 informiert den Anwender darüber, daß der Modul noch nicht zu einem Knotenpunkt zugeordnet worden ist und fragt, ob der Anwender wünscht, den Modul zu einem Knotenpunkt zu installieren. Das Objektsystem 130 präsentiert dem Anwender eine Liste von Knotenpunkten, aus der der Anwender den geeigneten Knotenpunkt für die Konfiguration auswählen kann. Nachdem der Anwender den Knotenpunkt für die Konfiguration ausgewählt hat, präsentiert das Objektsystem 130 dem Anwender ein Fenster, wobei bestätigt wird, ob der Anwender wünscht, den Modul zu erneuern. Das Objektsystem 130 fragt dann den Anwender, den Modul zu benennen. Nachdem der Anwender den Namen ausgewählt hat oder einen Namen erzeugt hat, fragt das Objektsystem 130 den Anwender, ob dieser sicher ist, daß er die Installationsprozedur auszuführen wünscht. Indem er dann mit ja antwortet, führt das Steuerstudioobjektsystem 130 automatisch die Installationsoperation durch, indem die Informationen, die innerhalb der Datenbank gespeichert sind, zu dem ausgewählten Modul downgeloaded werden.
Andere Ausführungsformen
Andere Ausführungsformen fallen innerhalb des Rahmens der folgenden Ansprüche.
Spezifischer gesagt, obwohl spezielle Ausführungsformen der vorliegenden Erfindung gezeigt und beschrieben wurden, ist es für einen Fachmann offensichtlich, daß Änderungen und Modifikationen vorgenommen werden können, ohne den Rahmen der Erfindung in ihren breitesten Aspekten zu verlassen, so daß daher die anhängenden Ansprüche den Rahmen all solche Änderungen und Modifikationen umreißen, die in den Rahmen der Erfindung fallen, inklusive, jedoch nicht beschränkt auf Implementationen in anderen Programmiersprachen. Obwohl darüber hinaus die bevorzugte Ausführungsform in Form einer Softwareimplementierung offenbart ist, sei darauf hingewiesen, daß Hardwareimplementierungen, wie beispielsweise anwendungsspezifische integrierte Schaltungsimplementierungen, ebenfalls in den Rahmen der folgenden Ansprüche fallen.
ZUSAMMENFASSUNG
Es wird ein Verfahren zum Konfigurieren einer Prozeßsteuerumgebung aufgezeigt, wobei die Prozeßsteuerumgebung ein Computersystem enthält, welches einen Prozessor aufweist, der an eine Anzeigevorrichtung gekoppelt ist. Das Verfahren umfaßt folgende Schritte:
Präsentieren einer Schablonenansicht, die ein Schablonenobjekt enthält, an der Anzeigevorrichtung, wobei das Schablonenobjekt (stencil object) eine Prozeßsteuermodul repräsentiert;
Präsentieren einer Diagrammansicht an der Anzeigevorrichtung, wobei die Diagrammansicht die Prozeßsteuerumgebungskonfiguration repräsentiert;
Ziehen des Schablonenobjekts von der Schablonenansicht zu der Diagrammansicht;
Ablegen des Schablonenobjekts auf der Diagrammansicht an einer Position, die eine Stelle des Prozeßsteuermoduls in der Prozeßsteuerumgebung anzeigt; und
Konfigurieren der Prozeßsteuerumgebung in Einklang mit der Diagrammansicht.