-
Technisches
Gebiet
-
Die
vorliegende Erfindung bezieht sich auf Produktionsverarbeitung und
insbesondere auf die Bereitstellung eines Mechanismus', um eine Produktionsanlage
in einer Multi-Protokoll-Umgebung zu steuern.
-
Hintergrundinformation
-
Moderne
Produktionsanlagen beruhen auf hochgradig automatisierten Werkzeugen,
um den Produktionsprozess zu implementieren. Zum Beispiel beinhalten
Halbleiterfabrikations-("fab")-Anlagen hochgradig
automatisierte Werkzeugsätze
für das
Verarbeiten von so genannten Halbleiterwafern. Prozess-Steuerung
und -Überwachung
wird durch einen Satz von Softwareverfahren vermittelt, welche aufgerufen
werden können,
um die Prozesse und die durchzuführende Überwachung
zu implementieren. Die Steuerungs- und Überwachungssoftware läuft auf
einem Werkzeugserver, welcher mit den Werkzeugen über eine
Mehrzahl von Anschlüssen,
so genannten Ports, gekoppelt sein kann, wobei jeder der Ports den
Werkzeugserver mit einem besonderen Werkzeug in einer Punkt-zu-Punkt-Weise
koppelt. Alternativ können
sich die Werkzeuge in dem Werkzeugserver in einem lokalen Netzwerk
(Local Area Network, LAN) befinden. Um den Herstellungsprozess zu
steuern, muss ein Benutzer in der Lage sein, mit dem Werkzeugserver
zu kommunizieren, entweder über
ein Anwendersystem, das sich in dem LAN befindet, oder auf andere
Weise in einer Kommunikation mit dem Werkzeugserver. Insbesondere
erfordert Fernzugriff auf den Werkzeugserver zur Steuerung und Überwachung
des Status' eines
Werkzeugs, in dem Ausmaß,
wie es überhaupt
existiert, die Entwicklung von spezialisiertem Code, der auf jeder Plattform
implementiert ist, für
welche ein Fernzugriff vorzusehen ist. Jedoch offerieren moderne
Datenverarbeitungssysteme typischerweise eine Vielzahl von bereits
existierenden Softwareapplikationen, wie zum Beispiel so genannte
Browser und Kalkulationssoftware, welche Einrichtungen für objektorientierte Inter-Applikation- oder Inter-Prozess-Kommunikation beinhalten.
Diese Einrichtungen sorgen für
Interprozesskommunikation über
verschiedene Plattformen und Softwarumgebungen.
-
Im
Stand der Technik sind Ansätze
für Simulation
und Modellierung von Produktionssystemen offenbart im US Patent
5 826 040 und in "PPS:
An Integrated Object Oriented Approach for Modeling and Simulation
of Manufacturing Systems",
von Bakalem et al. in SYSTEMS, MAN, AND CYBERNETICS, 1994, HUMANS,
INFORMATION AND TECHNOLOGY, 1994 IEEE INTERNATIONAL CONFERENCE ON
SAN ANTONIO, TX, USA, 2.–5.
Oktober 1994, NEW YORK, NY, USA, IEEE, 2. Oktober 1994, Seiten 2184–2189.
-
Demnach
besteht ein Bedarf in dem Stand der Technik für Systeme und Verfahren für das Adaptieren
von koppelnder Applikations-Software an die Produktionsanlage, welche
Software eine Mehrzahl von objektorientierten Interprozesskommunikations-Protokollen
benutzen kann. Zusätzlich
sollten ein solches koppelndes System und solche koppelnde Verfahren ältere Werkzeugsteuerungs- und Überwachungs-Applikationen
sowie durchzuführende
Sicherheitsrichtlinien anpassen.
-
Zusammenfassung
-
Die
Aufgabe wird gelöst
durch ein Verfahren und durch ein System gemäß den Ansprüchen 1 bzw. 15. Die Probleme,
die oben ausgeführt
wurden, können
wenigstens teilweise in manchen Ausführungsformen dadurch gelöst werden,
indem Interprozesskommunikation über
verschiedene Plattformen und Softwareumgebungen erleichtert wird,
die eine Mehrzahl von objektorientierten Interprozesskommunikations-Protokollen
zu der Produktionsanlage verwenden.
-
In
einer Ausführungsform
kann ein Verfahren zum automatisierten Werkzeug-Management den Schritt
umfassen, dass ein Anwender, der eine Applikation verwendet, eine
Mitteilung ausgeben kann gemäß einem
objektorientierten Interapplikations-Kommunikations-Protokoll oder
(äquivalent
Objekt-Zu-Objekt-Protokoll) gemäß beispielsweise "Component Object
Model (COM)", "JavaTM Remote Method
Invocation (RMI)", "Common Object Request Broker
Architecture (CORBA)", "Simple Object Access
Protocol (SOAP)",
oder Netzwerktransfer-Protokoll, wie zum Beispiel das "Hypertext Transfer
Protocol (HTTP)",
in einer breit gefächerten
Art und Weise, beispielsweise "Wide
Area Network (WAN)", "Local Area Network
(LAN)". Die Mitteilung
kann eine Anforderung sein, eine besondere Aktion auszuführen, beispielsweise
besondere Information von einem Werkzeug zu extrahieren, Setzen
einer Variablen oder eines Parameters, die bzw. der mit einem Objekt eines
Werkzeugs assoziiert ist, auf einen bestimmten Wert. Ein Objekt,
das mit einem Werkzeug assoziiert ist, kann den Status eines Werkzeugs
definieren.
-
Die
Mitteilung kann durch eine entsprechende Applikations-Schnittstelleneinheit
empfangen werden. Eine Applikations-Schnittstelleneinheit kann so
konfiguriert sein, eine Verbindung zwischen einem Anlagenmodell,
beispielsweise OBEM und dem Anwender herzustellen. Die Applikations-Schnittstelleneinheit
kann außerdem
so konfiguriert sein, den Inhalt der empfangenen Mitteilung zu extrahieren,
welche Daten aufweisen kann, die von der angeforderten Aktion benötigt werden.
In der Mitteilung kann ein Zeiger zu dem Objekt in dem Anlagenmodell,
welches das Werkzeug repräsentiert,
auf welchem die Aktion durchzuführen
ist, enthalten sein. Die Applikations-Schnittstelleneinheit kann
ein Verfahren des Objekts, auf das durch die Zeiger in der Mitteilung
gezeigt wird, aufrufen und kann die Daten, die den Mitteilungsinhalt
bilden, an das Verfahren leiten. Das Verfahren kann sodann einen
Fernzugriff auf das Objekt vorsehen, welcher eine Ferndiagnose und
-reparatur ermöglichen
kann.
-
Ein
Wert kann dann von dem Anlagenmodell beigebracht werden, in dem
der Wert mit der angeforderten Aktion und mit Daten in der Mitteilung
assoziiert ist. Das heißt,
der Wert kann mit einer bestimmten Information assoziiert sein,
die in der Mitteilung über ein
Werkzeug angefordert wird, beispielsweise Temperatur, Druck, Status
oder eine Notiz, die den Anwender informiert, dass ein Ereignis,
beispielsweise dass ein Alarm losgeht, aufgetreten ist. Das Anlagenmodell
kann den Wert zu dem geeigneten Anwender transferieren, basierend
auf einer Adresse, die durch die Applikation des Anwenders bereitgestellt
wird.
-
Die
vorhergehenden Ausführungen
haben ziemlich allgemein die Merkmale und technischen Vorteile der
vorliegenden Erfindung dargestellt, mit dem Zweck, dass die detaillierte
Beschreibung der Erfindung, die noch folgt, besser verstanden werden kann.
Zusätzliche
Merkmale und Vorteile der Erfindung, welche den Gegenstand der Ansprüche der
Erfindung bilden, werden im Folgenden noch beschrieben werden.
-
Kurze Beschreibung
der Zeichnungen
-
Man
erhält
ein besseres Verständnis
der vorliegenden Erfindung, wenn die folgende detaillierte Beschreibung
in Verbindung mit den folgenden Zeichnungen berücksichtigt wird, in welchen:
-
1 eine
Ausführungsform
eines Systems veranschaulicht, das gemäß der vorliegenden Erfindung
konfiguriert ist;
-
2 eine
Ausführungsform
der vorliegenden Erfindung in Form eines Werkzeugservers veranschaulicht;
-
3 eine
Ausführungsform
einer Softwarearchitektur des Programms der vorliegenden Erfindung
veranschaulicht, die konfiguriert ist, ein automatisiertes Werkzeugmanagement
in einer Multi-Protokoll-Umgebung
bereitzustellen;
-
4 eine "Unified Modeling
Language (UML)"-Darstellung
eines Anlagenmodells veranschaulicht, das gemäß der vorliegenden Erfindung konfiguriert
ist;
-
5 eine "Graphical User Interface (GUI)"-Darstellung eines
beispielhaften Anlagenmodells veranschaulicht, das gemäß der vorliegenden Erfindung
konfiguriert ist;
-
6 einen
Teil eines anderen exemplarischen GUI veranschaulicht, das gemäß der vorliegenden
Erfindung konfiguriert ist;
-
7 ein
Flussdiagramm eines Verfahrens ist zum Abfragen von Information
und/oder zum Ausgeben von Service-Anforderungen von und/oder zu einem
Werkzeug über
ein Anlagenmodell;
-
8 ein
Flussdiagramm eines Verfahrens zur Werkzeugzugriffssteuerung ist;
und
-
9 eine
Ausführungsform
einer Schutzhüllenarchitektur
der vorliegenden Erfindung veranschaulicht.
-
Detaillierte
Beschreibung
-
In
der folgenden Beschreibung werden zahlreiche spezifische Details
ausgeführt,
um ein gründliches
Verständnis
der vorliegenden Erfindung zu vermitteln. Zum Beispiel kann auf
bestimmte Mitteilungsformate und Interapplikationskommunikations-Protokolle
Bezug genommen werden, jedoch würde
es durch einen Fachmann so verstanden werden, dass die vorliegende
Erfindung ohne solche spezifischen Details ausgeführt werden
kann. In anderen Fällen
wurden wohlbekannte Schaltungen in Form von Blockdiagrammen dargestellt,
damit sich die vorliegende Erfindung nicht in unnötigem Detail verliert.
-
Es
wird nun Bezug genommen auf die Zeichnungen, wobei dargestellte
Elemente nicht notwendigerweise maßstabsgerecht gezeigt sind
und wobei ähnliche
oder gleiche Elemente durch das gleiche Bezugszeichen über die
verschiedenen Darstellungen hinweg bezeichnet sind.
-
1 veranschaulicht
eine Ausführungsform
der vorliegenden Erfindung in Form eines Systems 100, das
derart konfiguriert ist, einen Mechanismus bereitzustellen, der
es einem oder mehreren Anwendern 101A–C erlaubt, mit einem oder
mehreren Werkzeugen 103A–C über einen Werkzeugsserver 102 zu
kommunizieren. Die Anwender 101A–C können zusammen oder individuell
als Anwender 101 bzw. der Anwender 101 bezeichnet
werden. Werkzeuge 103A–C
können
zusammen oder individuell als Werkzeuge 103 bzw. das Werkzeug 103 bezeichnet
werden. Es wird darauf hingewiesen, dass das System 100 irgendeine
Anzahl von Anwendern 101 und Werkzeugen 103 beinhalten
kann, und dass 1 veranschaulichend ist. Es
wird ferner bemerkt, dass die Verbindung zwischen Anwendern 101 und Werkzeugserver 102 und
die Verbindung zwischen Werk zeugserver 102 und Werkzeugen 103 irgendeinen
Typ von Medium aufweisen kann, beispielsweise drahtlos, drahtgebunden
ist. Es wird weiterhin bemerkt, dass Anwender 101 ein Anwender
irgendeines Typs von Vorrichtung sein kann, beispielsweise drahtlos,
ein "Personal Digital
Assistant (PDA)",
Mobiltelefon, Personal Computer System, eine Workstation, Internetanwendung,
ausgestattet mit der Fähigkeit,
mit dem Werkzeugserver 102 Verbindung aufzunehmen und folglich
mit Werkzeugen 103 zu kommunizieren.
-
Der
Werkzeugserver 102 kann so konfiguriert sein, bestimmte
Information von den Werkzeugen 103 zu gewinnen, beispielsweise
die Temperatur. Information kann erhalten werden durch Senden einer
Anforderungsmitteilung an ein Werkzeug über den Werkzeugserver, und
die Information wird von dem Werkzeug über den Werkzeugserver in einer Antwortmitteilung
zurückgegeben.
Zusätzlich
kann ein Werkzeug Modifizierungsmitteilungen über den Werkzeugserver an den
Anwender senden. Modifizierungsmitteilungen können beispielsweise den Anwender
warnend hinweisen, dass eine vorgewählte Bedingung in dem Werkzeug
aufgetreten ist. Der Inhalt einer Mitteilung kann gemäß einem
bestimmten Kommunikations-Protokoll formatiert werden. Zum Beispiel
kann in Halbleiterfabrikationswerkzeugen solch ein Kommunikations-Protokoll
das "SEMI Communication
Standard (SECS)",
insbesondere SECS-II sein. (SECS ist veröffentlicht durch die SEMI-Anlagenstandards,
die durch "Semiconductor Equipment
and Materials International (SEMI) veröffentlicht sind). (Dem Fachmann
ist dabei bewusst, dass die vorliegende Erfindung nicht auf die
Halbleiterfabrikations-Industrie limitiert ist, und die Prinzipien
der vorliegenden Erfindung können
auf Werkzeugsautomatisierungssysteme in anderen Produktionsgebieten
angewandt werden, zum Beispiel der Automobilindustrie, wobei solche
Ausführungsformen
innerhalb des Konzepts und des Umfangs der vorliegenden Erfindung
fallen würden.)
Gemäß den Prinzipien
der vorliegenden Erfindung, wie weiter unten beschrieben, können Anwender 101 in
der Lage sein, Werkzeuge 103 zu steuern und bestimmte Information
von den Werkzeugen 103 zu gewinnen, indem eine Mitteilung
von einer Vielzahl von Applikationen an den Werkzeugserver 102 ausgegeben
wird, zum Beispiel Kalkulations-Programmen, Browsern oder Werkzeugsteuerungs-Altapplikationen,
die ein objekt-orientiertes Inter-Applikations-Kommunikations-Protokoll
verwenden, beispielsweise "Component
Object Model (COM)", "JavaTM Remote
Method Invocation (RMI)", "Common Object Request Broker Architecture
(CORBA)", "Simple Object Access
Protocol (SOAP)" oder
ein Netzwerkübertragungs-Protokoll,
wie beispielsweise das "Hypertext
Transfer Protocol (HTTP)".
(Man beachte, wie es dem Fachmann bewusst ist, dass solche Protokolle
geschichtet sein können,
beispielsweise derart, dass SOAP ein Interapplikationsmitteilungs-Protokoll
für das
Einhüllen der
Mitteilung in ein XML-Dokument definiert, das gemäß dem HTTP übertragen
wird). Die Mitteilung kann eine Anforderung sein, eine bestimmte
Information zu gewinnen, zum Beispiel Temperatur, Status, Druck
oder eine Serviceanforderung, beispielsweise einen Werkzeugbetrieb
zu starten/zu stoppen, von einem oder mehreren Werkzeugen 103,
beispielsweise eine Anlage, die in Halbleiterfabrikationseinrichtungen
verwendet wird. Zum Beispiel kann ein Anwender 101 eine
Mitteilung ausgeben, die die Temperatur in einer bestimmten Kammer
anfordert, wobei die bestimmte Kammer ein Werkzeug 103 in
dem Produktionsprozess, beispielsweise ein Halbleiterprozess, repräsentiert.
Eine detailliertere Erörterung
von Anwendern 101, die sich Information auf Werkzeugen 103 über den
Werkzeugserver 102 besorgen, ist in 5 vorgesehen.
Eine detaillierte Erörterung
des Werkzeugservers 102 wird weiter unten vorgesehen.
-
Es
wird nun Bezug genommen auf 2, welche
eine Ausführungsform
des Werkzeugservers 102 der vorliegenden Erfindung veranschaulicht.
Bezugnehmend auf 2 kann der Werkzeugserver 102 eine
zentrale Verarbeitungseinheit ("central
processing unit (CPU)") 210 aufweisen,
die an verschiedene andere Komponenten durch einen Systembus 212 gekoppelt
ist. Ein Betriebssystem 240 läuft auf der CPU 210 und
sieht eine Steuerung vor und koordiniert die Funktion der verschiedenen
Komponenten der 2. Eine Applikation 250,
beispielsweise ein Programm zur Kommunikation von Steuerung und Daten,
das mit einem oder mehreren Werkzeugen 103 auskommt, wie
in 5 beschrieben, oder ein Programm für das Bereistellen
von Sicherheit, wenn Anwender 101 auf den Werkzeugserver 102 zugreifen,
wie in 7 beschrieben, läuft in Verbindung mit dem Betriebssystem 240,
welches die verschiedenen Funktionen, die durch Applikation 250 durchzuführen sind,
implementiert. Ein Lesespeicher "Read
only memory (ROM)" 216 ist
an den Systembus 212 gekoppelt und beinhaltet ein grundlegendes
Eingabe-/Ausgabesystem ("basic
input/output system BIOS"),
welches bestimmte grundlegende Funktionen des Werkzeugservers 102 steuert.
Ein Schreib-Lese-Speicher ("random
access memo ry, RAM") 214,
ein Plattenadapter 218 und ein Kommunikationsadapter 234 sind
ebenso mit dem Systembus 212 gekoppelt. Es sollte erwähnt werden,
dass Softwarekomponenten, die das Betriebssystem 240 und
die Applikation 250 beinhalten, in das RAM 214 geladen
werden, welches der Hauptspeicher des Computersystems ist. Der Plattenadapter 218 kann ein "Small Computer System
Interface (SCSI)"-Adapter
sein, der mit Platteneinheiten 220 kommuniziert, beispielsweise
einem Plattenlaufwerk. Es wird bemerkt, dass das Programm der vorliegenden
Erfindung, das Information von einem oder mehreren Werkzeugen 103 einholt,
wie in 5 beschrieben, in der Platteneinheit 220 gespeichert
werden kann und davon wieder abgerufen und in das RAM durch das
Betriebssystem geladen werden kann, wenn dies angestoßen oder
anderweitig angefordert wird. E wird weiterhin bemerkt, dass das
Programm der vorliegenden Erfindung, das Sicherheit für Anwender 101 bereitstellt,
die auf den Werkzeugserver 102 zugreifen, wie in 7 beschrieben,
in der Platteneinheit 220 gespeichert werden kann und davon
wieder abgerufen und in das RAM durch das Betriebssystem geladen
werden kann, wenn dies angestoßen
oder anderweitig angefordert wird.
-
Der
Kommunikationsadapter 234 verbindet den Bus 212 mit
einem äußeren Netzwerk,
das dem Werkzeugserver 102 ermöglicht, mit anderen solchen
Systemen über
ein "Local Area
Network (LAN)", beispielsweise "Ethernet", "Token Ring", "ARCnet" oder über ein "Wide Area Network
(WAN)", beispielsweise
das Internet, zu kommunizieren.
-
Erfindungsgemäße Implementationen
beinhalten Implementationen als ein Computersystem, das programmiert
ist, das Verfahren oder die Verfahren, die hierin beschrieben sind,
auszuführen
und als ein Computerprogramm-Produkt. Den Computersystem-Implementationen
zufolge sind Sätze
von Instruktionen zur Ausführung
des Verfahrens oder der Verfahren in den Schreib-Lese-Speicher 214 eines oder
mehrerer Computersysteme geladen, die im Allgemeinen konfiguriert
sind, wie oben beschrieben. Bis zum Abrufen durch den Werkzeugserver 102 kann
der Satz von Instruktionen als ein Computerprogramm-Produkt in einer
anderen Vorrichtung gespeichert werden, zum Beispiel in dem Plattenlaufwerk 220 (welches
einen entnehmbaren Speicher enthalten kann, beispielsweise eine
optische Disk oder eine Floppy-Disk für eine letztendliche Benutzung
in dem Plattenlaufwerk 220). Außerdem kann das Computerprogramm-Produkt
ebenso auf einem anderen Computer gespeichert sein und, wenn gewünscht, zu der
Arbeitsstation des Benutzers durch ein Netzwerk oder durch ein externes
Netzwerk, wie beispielsweise dem Internet übertragen werden. Der Fachmann ist
sich bewusst, dass die physikalische Speicherung der Sätze von
Instruktionen physikalisch das Medium verändert, auf welchem sie gespeichert
sind, sodass das Medium computerlesbare Information trägt. Die Veränderung
kann elektrisch, magnetisch, chemisch oder irgendeine andere physikalische
Veränderung sein.
-
3 veranschaulicht
eine Ausführungsform
der erfindungsgemäßen Software-Architektur 300 des
erfindungsgemäßen Programms,
das konfiguriert ist, Information von einem oder mehreren Werkzeugen 103 abzurufen,
wie in 5 beschrieben. Die Software-Architektur 300 kann
eine oder mehrere Applikations-Schnittstelleneinheiten 301A–C aufweisen,
ein Anlagenmodell 302 und eine oder mehrere Werkzeug-Schnittstelleneinheiten 303A–C. Applikations-Schnittstelleneinheiten 301A–C können gemeinsam
oder individuell als Applikations-Schnittstelleneinheiten 301 oder
eine Applikations-Schnittstelleneinheit 301 bezeichnet
werden. Die Werkzeug-Schnittstelleneinheiten 303A–C können gemeinsam
oder individuell als Werkzeug-Schnittstelleneinheiten 303 bzw.
Werkzeug-Schnittstelleneinheit 303 bezeichnet werden. Es
wird bemerkt, dass die Software-Architektur 300 irgendeine
Anzahl von Applikations-Schnittstelleneinheiten 301 und
Werkzeug-Schnittstelleneinheiten 303 aufweisen kann, und
dass 3 veranschaulichend ist.
-
Applikations-Schnittstelleneinheiten 301 können so
konfiguriert sein, ein Applikationsmodell 302 mit Anwendern 101 zu
koppeln. Das Anlagenmodell 302 kann so konfiguriert sein,
eine logische Darstellung von Werkzeugen 103 bereitzustellen,
wobei dadurch Anwendern 101 ermöglicht wird, mit Werkzeugen 103 zu
kommunizieren. Das heißt,
das Anlagenmodell 302 kann ein logisches Abbild von Werkzeugen 103 vorsehen,
der physikalischen Anlage, mit welcher die Werkzeuge aufgebaut sind.
Ein Werkzeuglieferant kann die Anlage in die Objekte des Anlagenmodells
zerlegen, um die physikalische Anlage in die Charakteristiken der
Objekte des Anlagenmodells abzubilden, wie zum Beispiel Anlagenmodell 302.
Ein solches Anlagenmodell ist das Objekt-basierte Anlagenmodell
("Object-Based Equipment Model,
OBEM"), veröffentlicht
durch SEMI als SEMI proviso rische Spezifikation SEMI E 98–1000, was
hiermit durch Bezugnahme hierin mit einbezogen wird. Man beachte,
dass andere Anlagenmodelle in Verbindung mit der vorliegenden Erfindung
benutzt werden können,
wobei solche Ausführungsformen durch
einen Fachmann so verstanden werden würden, dass sie innerhalb des
Konzepts und des Schutzumfangs der vorliegenden Ansprüche fallen.
Eine Beschreibung eines Modellschemas, welches zur Realisierung
des Anlagenmodells 302 benutzt werden kann, ist in 4 verfügbar. Ein
beispielhaftes Anlagenmodell wird in Verbindung mit 5 beschrieben
werden.
-
4 veranschaulicht
eine "Unified Modeling
Language (UML)" Darstellung
eines Anlagenmodellschemas 402, welches mit der vorliegenden
Erfindung benutzt werden kann. Das Anlagenobjekt-Modellschema 402 kann
ein objektorientiertes Modell sein, welches eine Mehrzahl von Objekten
beinhaltet. In Übereinstimmung
mit objektorientierten Software-Architekturen können Objekte aus Sub-Objekten aufgebaut
sein, welche Attribute und Verfahren der Supra-Objekte übernehmen
können.
Das Anlagenmodellschema 402 beinhaltet eine Aggregationshierarchie 404 und
eine Schnittstellen-Vererbungshierarchie 406. Objekte in
der Aggregationshierarchie können
konkrete Objekte sein, während Objekte
der Vererbungshierarchie 406 abstrakte Objekte sein können, welche
die Attribute und Verfahren der konkreten Objekte definieren. (In
einer Implementation der vorliegenden Erfindung in der JavaTM-Programmiersprache können abstrakte Objekttypen
in der Vererbungshierarchie 406 Schnittstellen sein).
-
Die
Aggregationshierarchie 404 beinhaltet ein Anwenderobjekt 408.
Anlagenobjekt 410 kann null oder mehrere Anlagenmodulobjekte 412 (gekennzeichnet
durch einen Kreis) enthalten (gekennzeichnet durch eine offene Raute).
Zusätzlich
kann das Anlagenobjekt 410 null oder mehrere Anlagen-Subsystemobjekte 414 enthalten
sowie Anlagen-I/O-Vorrichtungsobjekte 416. In ähnlicher
Weise kann Anlagen-Subsystemobjekt 414 null oder mehrere
Anlagen-Subsystemobjekte 414 und null oder mehrere Anlagen-I/O-Objekte 416 enthalten.
Die Aggregationshierarchie 406 kann eine abnehmende Komplexität eines
Objekttyps repräsentieren,
von oben bis unten der Hierarchie.
-
Es
wird nun Bezug genommen auf 5, welche
eine Darstellung 500 einer grafischen Benutzerschnittschnelle
("graphical user
interface GUI")
eines exempla rischen Anlagenmodells 502 in Übereinstimmung
mit dem Schema von 4 veranschaulicht. Das Modell 502 ist
für ein
Anlagenmodell veranschaulichend, welches mit der vorliegenden Erfindung
benutzt werden kann, wobei einem Fachmann bewusst sein würde, dass
ein Modell eines Werkzeugs andere Zahlen oder Nummern und Typen
von Objekten entsprechend einer Ausführungsform einer Produktionseinrichtung
haben kann.
-
Das
Modell 502 wird in hierarchischer Form in GUI 500 präsentiert
und beinhaltet einen Ursprungsknoten 504. Das Anlagenobjekt 506 ist
in dem beispielhaften Modell 502 ein Implantierer. Der Ausschnitt 508 des
GUI 500 veranschaulicht einen Satz von Attributen 510 und
entsprechenden Werten 512, die mit Anlagenobjekt 504 assoziiert
sind. Man beachte, dass ein Attribut im Satz 508 objType
(514) ist, welcher den Wert "Anlage" (516) hat. Ein anderes Attribut
ist objID (518), welches den Wert "Implantierer" (520) hat. Der Ausschnitt 508,
der den Attributsatz 510 und die Werte 512 veranschaulicht,
kann im GUI 500 dargestellt werden, indem das Anlagenobjekt 506 selektiert
wird (wie dargestellt durch das "Markieren" des Objektidentifizierers "Implantierer" im Modell 502).
Die Selektion von Objekten in einem GUI, zum Beispiel durch "Maus-Klicken" ist dem Fachmann
bekannt.
-
Das
Anlagenmodulobjekt 522 ist im Modell 502 ein Ionenimplantierer
und ist ein Tochterobjekt des Anlagenobjekts 506. Eine
Attributliste und assoziierte Werte, entsprechend Attributen des
Anlagenmodulobjekts (nicht in 5 dargestellt),
können dargestellt
werden, indem Anlagenmodulobjekt 522 in der gleichen Weise,
wie oben in Verbindung mit Anlagenobjekt 506 beschrieben,
selektiert wird.
-
Andere
Objekte im Modell 502 beinhalten Subsystemobjekt 524 und
Anlagen-I/O-Objekt 526. Das
Subsystemobjekt 524, eine Endstation, ist ein Tochterobjekt
des Ionenimplantierers, das Anlagenmodulobjekt 522 und
I/O-Objekt 526, ein Faraday-Ring ("Faraday Cup"), ist ein Tochterobjekt von Subsystemobjekt 524.
-
Gemäß Prinzipien
von objektorientierter Software sind die Objekte eines Anlagenmodells,
wie zum Beispiel Modell 502, Klasseninstanzen, welche Daten und
Verfahren, die mit den Daten arbeiten, beinhalten. (Der Satz von
Attributen, wie oben erläutert, sind
Beispiele von solchen Daten. Folglich ist ein Objekt eine Datenstruktur,
die Daten und Code für
das Arbeiten mit den Daten beinhaltet. Insbesondere enthalten Objekte
eines Anlagenmodells, welches, zur Erinnerung, eine logische Darstellung
einer Produktionseinrichtung ist, Verfahren zur Retournierung von Tochterobjekten
eines bestimmten Objekts. Mit anderen Worten, kann ein Anwender,
der auf ein Anlagenmodell zugreift, das Modell erkunden, indem zum Beispiel
durch die Hierarchie des Modells 502 hindurch "aufgerissen wird" in ähnlicher
Weise, wie durch eine Hierarchie von Verzeichnissen und Dateien
hindurch aufgerissen wird, was dem Fachmann in der Datenverarbeitungstechnik
geläufig
ist. Auf diese Art erhält
die Client-Applikation des Anwenders Zeiger auf Objekte des Modells.
Diese können
dann durch die Client-Applikation
des Anwenders benutzt werden, um Mitteilungen an das Werkzeug oder
an eine Komponente desselben zu senden, um Daten oder Dienste von
dem Werkzeug über
die Vermittlung des Objekts entsprechend der logischen Darstellung des
Werkzeugs oder der Komponente des Werkzeugs anzufordern. Solche
eine Versendung wird im weiteren Verlauf in Verbindung mit 7 noch
erläutert
werden.
-
6 veranschaulicht
einen Teil eines anderen exemplarischen GUI 600, welches
in einer Ausführungsform
der vorliegenden Erfindung benutzt werden kann. GUI 600 kann
in Verbindung mit einer Client-Tabellenapplikation eines Anwenders
benutzt werden. Zellensätze 602A–C beinhalten
den Satz von Attributen für
ein Implantiererobjekt, Zelle 604. Entsprechende Werte
werden in Zellensätzen 606A–C dargestellt.
Man beachte, dass der Wert von Attribut ObjType, dargestellt im
Zellensatz 602A, den Wert "Anlage" hat, dargestellt im Zellensatz 606A, und
Attribut ObjID den Wert "Implantierer" entsprechend Anlagenobjekt 506, 5,
hat. Man beachte, dass der Satz von Attributen in Zellensätzen 602A–C und Werte
in Zellensätzen 606A–C die Attribute
im Attributsatz 510 und Wertesatz 512, 5,
reflektieren.
-
Zusätzlich enthält GUI 600 eine
Steuerschaltfläche 608.
Eine Selektion der Steuerschaltfläche 608, wie beispielsweise
durch einen "Maus-Klick" oder einer ähnlichen
Operation durch den Benutzer, kann eine Anforderungsmitteilung von der
Tabellenapplikation für
beispielsweise einen selektierten Attributwert initiieren, von dem
Werkzeug über
das Anlagenobjektmodell, welche Mitteilung zu dem Anlagenmodell
unter Benutzung eines vorbestimmten objektorientierten Interprozesskommunikations-Protokolls,
COM beispielsweise, geleitet werden kann.
-
Es
wird nun Bezug genommen auf 7, welche
in Form eines Flussdiagramms ein Verfahren 700 für das Übermitteln
von Mitteilungen zwischen Werkzeugen, wie zum Beispiel Werkzeuge 103 gemäß 1, über ein
Anlagenmodell veranschaulicht.
-
Mit
Bezug wiederum auf 3 kann die Applikations-Schnittstelleneinheit 301 so
konfiguriert sein, Mitteilungen zwischen einem der Anwender 101 und
Werkzeugen 103 zu übermitteln.
Jede Applikations-Schnittstelleneinheit 301 kann so konfiguriert sein,
Mitteilungen von einem Anwender 101 über eine Anwenderapplikation
zu erhalten, die in einem oder mehreren objektorientierten Interapplikations-Protokollen
kommuniziert, beispielsweise COM, RMI, CORBA, SOAP, HTTP oder eine ältere Ursprungsmitteilung,
wie zum Beispiel eine SECS-Mitteilung.
Weiterhin kann jede Applikations-Schnittstelleneinheit 301 so
konfiguriert sein, Mitteilungen von Anwendern 101 in einer
bestimmten Weise, beispielsweise WAN, LAN, Werksystem, zu erhalten. Beispielsweise
kann die Applikations-Schnittstelleneinheit 301A so konfiguriert
sein, Mitteilungen von den Anwendern 101A in einem Protokoll
zu erhalten, wie beispielsweise COM, RMI, CORBA, SOAP und XML über ein
LAN. Die Applikations-Schnittstelleneinheit 301B kann so
konfiguriert sein, Mitteilungen von Anwendern 101B über eine
Altapplikation zu erhalten, beispielsweise MES, in einem Protokoll
wie beispielsweise SECS über
ein Werksystemnetzwerk oder eine andere Kommunikationsverbindung.
Die Applikations-Schnittstelleneinheit 301C kann so konfiguriert
sein, Mitteilungen von Anwendern 101C in einem Protokoll
zu übermitteln,
wie beispielsweise HTTP-Anforderungen über ein WAN oder das Internet,
und Mitteilungen zu empfangen, die in ein Dokument wie beispielsweise
ein HTML oder XML Dokument gehüllt
sind. Eine detaillierte Beschreibung von Verfahren und einer Einrichtung,
welche in solch einer Applikations-Schnittstelleneinheit benutzt
werden können,
können
in der parallel anhängigen
gemeinschaftlich-eigenen US Patent-Anmeldung mit Seriennummer 09/496,009
mit dem Titel "Apparatus
and Method for Web-based Tool Management" gefunden werden.
-
7 veranschaulicht
ein Flussdiagramm einer Ausführungsform
der vorliegenden Erfindung in Form eines Verfahrens 700 für eine Abrufung
von Information, beispielsweise Temperatur, Druck und/oder Ausgeben
von Serviceanforderungen, beispielsweise einer Steuermitteilung,
an ein oder mehrere Werkzeuge 103 über ein Anlagenmodell 302, beispielsweise
OBEMTM. Wie oben erläutert, kann Software in einem
Werkzeugserver 102 eine Software-Architektur enthalten,
die ein Anlagenmodell bildet, beispielsweise OBEM, das eine logische
Darstellung eines Werkzeugs oder von Werkzeugen, wie zum Beispiel
Werkzeuge 103 gemäß 1,
implementiert.
-
Im
Schritt 702 kann ein Anwender 101, beispielsweise
einer der Anwender 101 bis 101C, eine Mitteilung
an eine bestimmte Applikations-Schnittstelleneinheit 301,
beispielsweise Applikations-Schnittstelleneinheit 301A,
ausgeben, wobei Information wie beispielsweise Temperatur, Druck,
Status angefordert wird, und/oder eine Serviceanforderung, beispielsweise
eine Steuermitteilung, von und/oder zu einem bestimmten Werkzeug 103 ausgegeben
wird. Die Mitteilung kann mit dem bestimmten Anwender 101 durch
einen Strang ("thread") in einer "Multitasking"-Umgebung (Umgebung,
in der mehrere Arbeitsgänge
gleichzeitig ausgeführt
werden) oder in einer Mehrfach-Prozess-Umgebung assoziiert sein.
-
Im
Schritt 704 kann die Mitteilung durch eine entsprechende
der Applikations-Schnittstelleneinheiten 301 empfangen
werden. Wie oben erwähnt,
können
Anwender 101 auf bestimmte Applikations-Schnittstelleneinheiten 301 unter
Benutzung einer Applikation zugreifen, welche Mitteilungen gemäß einem
objektorientierten Interapplikations-Kommunikations-Protokoll oder
(äquivalent
Objekt-Zu-Objekt-Protokoll)
gemäß beispielsweise COM,
RMI, CORBA, SOAP, HTTP, etc., in einer Vielfalt von Art und Weisen,
beispielsweise WAN, LAN, übermittelt.
Beispielsweise kann die Applikations-Schnittstelleneinheit 301A so
konfiguriert sein, Mitteilungen von Anwendern 101A in einem
Protokoll zu erhalten, wie beispielsweise COM, RMI, CORBA, SOAP
und HTTP über
ein LAN. Die Applikations-Schnittstelleneinheit 301B kann
so konfiguriert sein, Mitteilungen von Anwendern 101B in
einem ursprünglichen
Protokoll, wie beispielsweise SECS über ein Werkssystemnetzwerk
zu erhalten. Die Applikations-Schnittstelleneinheit 301C kann
so konfiguriert sein, Mitteilungen von Anwendern 101C unter Benutzung
eines Protokolls, wie beispielsweise HTTP über ein WAN oder das Internet
zu erhalten.
-
Wie
vorhergehend beschrieben, können
Mitteilungen, um Kommunikation zwischen einem Werkzeug und einem
Anwender über
verschiedene Datenverarbeitungsplattformen hinweg unter Benutzung
einer Mehrzahl von Applikationsmitteilungen zwischen einem Werkzeug
und einem Anwender, unter Vermittlung durch das Anlagenmodell, zu
erleichtern, über
eine objektorientierte Interprozesskommunikation oder ein Datenaustausch-Protokoll
ausgetauscht werden. Beispiele beinhalten CORBA, RMI, COM und SOAP.
Zusätzlich
kann eine Applikation ein ursprüngliches/vorhandenes
Kommunikations-Protokoll benutzen, wie beispielsweise SECS, oder
die Mitteilung in einer HTTP-Anforderung oder einer XML/HTML-Seite.
-
In
Schritt 706 kann die Applikations-Schnittstelleneinheit 301,
welche die Mitteilung in Schritt 704 erhalten hat, den
Inhalt der empfangenen Mitteilung extrahieren, zum Beispiel Daten,
die von der angeforderten Aktion benötigt werden. Wie oben erwähnt, kann
der Inhalt der erhaltenen Mitteilung eine Anforderung für eine bestimmte
Information sein, beispielsweise Temperatur, Druck, Status, von
einem oder mehreren Werkzeugen 103; oder kann anfordern,
einen bestimmten Parameter zu setzen, beispielsweise einen Steuer-Setzpunkt;
oder kann eine Notifikation von beispielsweise der Wertveränderung eines
Parameters anfordern. In der Mitteilung enthalten ist ein Zeiger
auf das Objekt in dem Anlagenmodell, welches das Werkzeug 103 oder
eine Komponente davon darstellt, auf welchem die Aktion durchzuführen ist,
und die bestimmte, betroffene Variable oder Parameter.
-
Falls
die Anforderung weder eine Anforderung, Daten zu erhalten oder Daten
zu setzen, noch eine Notifikationsanforderung ist, entfallen die
Schritte 710, 741 und 763, wie weiter
unten noch erläutert, durch
ihre Nein-Verzweigungen, wobei Verfahren 700 die Anforderung
verarbeitet, beispielsweise eine Service-Anforderung, wie zum Beispiel
Start oder Stop des Werkzeugs, gemäß Schritt 708, durch
die geeignete Werkzeugschnittstelle.
-
Falls
die Anforderung demgegenüber
eine Anforderung ist, Daten zu erhalten oder Daten zu setzen, oder
eine Notifikations-Anforderung ist, können die durchgeführten Operationen
von den Charakteristiken des Werkzeugs 103 oder einer Komponente davon
abhängen.
-
Ein
Werkzeug 103 kann als eine synchrone Quelle, eine veränderliche
synchrone Quelle und/oder als eine asynchrone Quelle der Daten,
die in Schritt 706 angefordert werden, wie unten beschrieben,
charakterisiert werden. Eine synchrone Quelle kann sich auf ein
Werkzeug beziehen, welches einen Wert auf eine Anforderung des Anwenders 101 für eine bestimmte
Information liefert, beispielsweise Temperatur, Druck, Status. Eine
veränderliche
synchrone Quelle kann sich auf eine Einstellung des Werkzeugs 103 beziehen,
die durch den Anwender 101 gesetzt werden kann. Die Einstellung kann
sich auf einen Benutzer 101 beziehen, der eine bestimmte
Variable oder einen bestimmten Parameter assoziiert mit einem bestimmten
Werkzeug 103 auf einen bestimmten Wert setzt. Eine asynchrone Quelle
kann sich auf ein bestimmtes Werkzeug 103 beziehen, das
den Anwender 101 informiert, wenn ein Ereignis eintritt,
beispielsweise sich ein Wert verändert.
Werkzeug-Schnittstelleneinheiten 303 können so konfiguriert sein,
ihre zugehörigen
Werkzeuge 103 kontinuierlich zu überwachen, im Hinblick darauf, wenn
ein Ereignis eintritt. Wenn das Ereignis eintritt, kann die Werkzeug-Schnittstelleneinheit 303 dem Anlagenmodell 302 anzeigen,
dass das Ereignis eingetreten ist. Das Anlagenmodell 302 kann
dann so konfiguriert sein, ein Verfahren aufzurufen, um einen oder
mehrere interessierte Anwender 101, basierend auf einem
oder mehreren Zeigern zu jenem bzw. jenen Anwendern 101 zu
benachrichtigen.
-
In
Schritt 712 kann durch das Verfahren eine Ermittlung durchgeführt werden,
ob der Parameter des Objekts, der in Schritt 708 bestimmt
wurde, eine asynchrone Quelle hat, wobei der Wert, der durch die asynchrone
Quelle bereitgestellt wird, aktuell ist. Falls der Parameter des
Objekts eine asynchrone Quelle hat, wobei der Wert, der durch die
asynchrone Quelle bereitgestellt wird, aktuell ist, wird sodann
dieser aktuelle Wert von dem lokalen Objekt abgerufen, Schritt 713,
und zu der geeigneten Applikations-Schnittstelle in Schritt 728 transferiert.
Im Schritt 730 kann die geeignete Applikations-Schnittstelleneinheit 301 sodann
derart konfiguriert werden, den empfangenen Datenwert in eine Rücklaufmitteilung an Anwender 101 in Übereinstimmung
mit dem geeigneten Protokoll aufzunehmen. In Schritt 732 kann die
Mitteilung zu dem geeigneten Anwender 101 basierend auf
einer Adresse transferiert werden, die vorhergehend durch die Client-Applikation
des Anwenders bereitgestellt wurde.
-
Bezugnehmend
auf Schritt 710 kann, falls das bestimmte Werkzeug 103 nicht
eine asynchrone Quelle mit augenblicklich gültigen Daten versorgt, sodann
eine Bestimmung dahingehend durchgeführt werden, ob das bestimmte
Werkzeug 103 eine synchrone Quelle in Schritt 734 versorgt.
Falls das bestimmte Werkzeug 103 eine synchrone Quelle
versorgt, kann sodann die geeignete Werkzeug-Schnittstelleneinheit 303 den
Datenwert von dem bestimmten Werkzeug 103 in Schritt 736 abrufen.
Die entsprechende Werkzeug-Schnittstelleneinheit 303 kann
in die Lage versetzt werden, den Datenwert durch ein Verfahren des
Anlagenmodells 302 in Übereinstimmung
mit einem ursprünglichen/vorhandenen
Kommunikationsprotokoll des Anlagenmodells 302, beispielsweise
SECS, abzurufen. Die entsprechende Werkzeug-Schnittstelleneinheit 303 kann
dann den Datenwert an das Anlagenmodell 302 in Schritt 728 transferieren.
Der Wert kann dem Anwender in Schritt 728 mitgeteilt werden,
wie oben erörtert.
-
Falls
das bestimmte Werkzeug 103 keine synchrone Quelle ist,
kann sodann eine Ermittlung dahingehend durchgeführt werden, ob das bestimmte
Werkzeug 103 eine asynchrone Quelle versorgt, für welche
jedoch augenblicklich keine gültigen
Daten existieren, Schritt 737. Falls dies zutrifft, schlägt die Anforderung
fehl, Schritt 739, und eine Fehlerantwort wird an den Anwender
in Schritten 728–739 zurückgegeben,
wie vorhergehend beschrieben.
-
Demgegenüber schreitet
Schritt 737 durch die "Nein"-Markierung zum Schritt 740 fort,
um den Datenwert von dem lokalen Objekt abzurufen. Der Wert kann
dem Anwender in Schritt 728–732 mitgeteilt werden,
wie oben dargestellt.
-
Es
wird nun auf Schritt 710 zurückgekommen, wobei, falls die
Anforderung keine Anforderung für
Daten ist, sodann in Schritt 741 eine Bestimmung dahingehend
durchgeführt
wird, ob die Anforderung eine Anforderung ist, ein Datenelement
zu modifizieren. Falls ja, sind die Operationen, die erneut durchgeführt werden, abhängig von
den Charakteristiken des Werkzeugs 103. In Schritt 751 wird
eine Bestimmung dahingehend durchgeführt, ob das Werkzeug einen
veränderbaren
synchronen Träger
für den
betroffenen Parameter versorgt, wie vorhergehend beschrieben. Falls
ja, setzt der Schritt 753 den Parameter über die
entsprechende Werkzeug-Schnittstelle. Mit Vervollständigung
dieser Operation teilt Schritt 755 allen Anwendern, welche
eine Notifikation angefordert haben, mit, wenn der betroffene Parameter gesetzt
ist, wie es im Nachfolgenden noch beschrieben werden wird in Verbindung
mit Schritt 765. Die Anforderung wird sodann zu dem Anwender
in Schritten 728–732 zurückgeleitet,
wie vorhergehend beschrieben.
-
Zurückkommend
auf Schritt 751 wird, falls bestimmt wurde, dass das Werkzeug
nicht eine veränderliche
synchrone Quelle für
die fragliche Eigenschaft bereitstellt, eine Bestimmung in Schritt 757 dahingehend
durchgeführt,
ob das Werkzeug eine synchrone oder asynchrone Unterstützung für diese
Eigenschaft bereitstellt. Falls ja, schlägt die Anforderung fehl, Schritt 759,
und dieser Status wird zu dem Anwender in Schritten 728–732 zurückgegeben,
wie vorhergehend beschrieben.
-
Zurückkommend
auf Schritt 757 setzt, falls festgestellt wurde, dass das
Werkzeug keine synchrone oder asynchrone Unterstützung für die fragliche Eigenschaft
bereitstellt, sodann Schritt 761 die Eigenschaft in dem
lokalen Objekt auf den angeforderten Wert, Schritt 755,
wobei Anwender von dem Eigenschaftswechsel informiert werden, und
es werden nachfolgende Schritte sodann ausgeführt, wie vorhergehend beschrieben.
-
Zurückkommend
auf Schritt 741 wird, falls festgestellt wurde, dass die
Anforderung nicht eine Anforderung ist, einen Datenwert zu erhalten,
eine Bestimmung dahingehend durchgeführt, gemäß Schritt 763, ob
die Anforderung eine Anforderung ist, mitgeteilt zu bekommen, wenn
ein Ereignis, wie zum Beispiel eine Eigenschaftsveränderung,
auftritt. Falls dies zutrifft, speichert Schritt 765 eine
Referenz zu dem Anwender, auf den die Anforderung zurückgeht, zusammen
mit dem Objekt und dem dazugehörigen Parameter.
Eine Bestätigung
der Anforderung wird dann zu dem Anwender in den vorher beschriebenen Schritten 728–732 zurückgegeben.
-
8 veranschaulicht
ein Flussdiagramm eines Verfahrens 800 für eine Werkzeugzugriffssteuerung
gemäß einer
Ausführungsform
der vorliegenden Erfindung. Das heißt, das Verfahren 800 kann verwendet
werden, um Aktionen zu steuern, die ein Anwender oder Klassen von
Anwendern mit Bezug auf ein bestimmtes Werkzeug vornehmen können.
-
In
Schritt 802 wird eine Anforderungsmitteilung von einem
Anwender empfangen, zum Beispiel von einem der Anwender 101A–C gemäß 1.
Die Mitteilung kann Daten mit Bezug auf das Werkzeug oder eine Komponente
des Werkzeugs anfordern oder kann einen Dienst von dem Werkzeug
anfordern, welche Mitteilung folglich auf das Werkzeug oder die
Komponente zugreift, wie vorhergehend beschrieben.
-
In
Schritt 803 kann das Verfahren 800 ein Objekt
bilden, das assoziiert ist mit dem bestimmten Anwender 101,
beispielsweise Anwender 101A, wie veranschaulicht durch
Anwenderobjekt 950, 9. Das Objekt 950 kann
einen Identifizierer des zugehörigen
Anwenders enthalten, zum Beispiel Anwender 101A.
-
9 veranschaulicht
eine Schutzhüllenarchitektur 900 gemäß den Prinzipien
der vorliegenden Erfindung. Die Software-Architektur 900 kann
weiterhin eines oder mehrere Schutzhüllenobjekte 911–915A in
einer Hüllenebene
oder Hüllenschicht 901 umfassen,
welche mit dem Ursprungsobjekt 912A, dem Anlagenobjekt 912B,
dem Modulobjekt 912C, dem Subsystem-Objekt 912D bzw.
dem I/O-Objekt 912E assoziiert
sind, welche in logischer Weise Werkzeugelemente darstellen, wie
vorhergehend beschrieben. Schutzhüllenobjekte 911A–E können gemeinsam
oder individuell als Schutzhüllenobjekt 911 bzw.
Schutzhüllenobjekte 911 bezeichnet werden.
Eine detaillierte Darstellung der Schutzhüllen 911 wird weiter
unten vorgesehen. Es wird bemerkt, dass die Software-Architektur 900 irgendeine Anzahl
von Schutzhüllen 911 enthalten
kann, und dass mehrere Schutzhüllen 911 mit
mehreren Objekten in einer bestimmten Hierarchie des Anlagenmodells 302 assoziiert
sein können.
Zum Beispiel kann die Software-Architektur 900 eine Mehrzahl
von Schutzhüllen 911 enthalten,
die mit einer Mehrzahl von Anlagenobjekten 912B assoziiert
sind. 8 wird in Verbindung mit 9 weiter
beschrieben werden.
-
Zurückkommend
auf 8 wird in Schritt 804 auf eine Konfigurationsdatei
zugegriffen, welche Zugriffs-Steuerinformation enthalten kann. Insbesondere
kann die Konfigurationsdatei Zugriffs-Steuerinformation in Bezug
auf eine Gruppe von Anwendern einschließlich des Anwenders entsprechend
dem Anwenderobjekt 950, 9, oder
alternativ auf den individuellen Anwender enthalten. Zusätzlich kann
ein Werkzeug selbst oder eine Komponente davon als ein Anwender
angesehen werden, und Anwenderobjekt 950 kann solch einem
Werkzeug oder solch einer Komponente entsprechen. Die Hüllenebene
oder Hüllenschicht 901, 9,
kann in Antwort auf Zugriffsinformation generiert werden, die dem
Anwender entspricht, der mit Anwenderobjekt 950 assoziiert
ist.
-
Eine
Schutzhüllenebene,
wie zum Beispiel Hüllenebene 901, 9,
kann durch Verfahren 800 in Schritten 806–816 generiert
werden. In Schritten 806–816 kann die Schutzhüllenebene 901 in
rekursiver Weise generiert werden. Die gebildeten Schutzhüllenobjekte,
welche zu entsprechenden der Anlagenmodellobjekte parallel laufen,
hängen
ab von der Tiefe in der Anlagenmodellhierarchie des Anlagenobjekts,
auf das zugegriffen wird. In anderen Worten, werden Schutzhüllen gebildet,
so wie sie gemäß der Anforderungsmitteilung
von dem Anwender benötigt werden.
In Schritt 806 wird ein Hüllenobjekt, zum Beispiel eines
der Schutzhüllenobjekte 911A–E gebildet. In
Schritt 808 wird ein Zeiger auf das entsprechende Anlagenmodellobjekt,
zum Beispiel eines der Objekte 912A–912E, in dem Schutzhüllenobjekt
gespeichert, das in Schritt 806 gebildet wurde. Zusätzlich werden,
in Schritt 810, entsprechend dem bestimmten Anwender, das
Werkzeug oder die Werkzeugkomponente, auf die durch das Werkzeugobjektmodell
zugegriffen wird, in dem Schutzhüllenobjekt
gespeichert. In Schritt 812 wird festgelegt, falls das
aktuelle Anlagenmodellobjekt dem Objekt entspricht, für welches
die Zugriffsanforderung durchgeführt wird.
Falls dies nicht zutrifft, schreitet das Verfahren 800 in
Schritt 814 zu dem Tochterobjekt des aktuellen Anlagenmodellobjekts
fort und kehrt zu dem Schritt 806 zurück, um das Schutzhüllenobjekt
für das
Tochterobjekt zu bilden. In anderen Worten, fächern die Schritte 806–814 die
Anlagenmodellhierarchie auf, bis in Schritt 816 das Objekt
erreicht wird, für
welches die Zugriffsanforderung durchgeführt wird. In Schritt 816 wird
dann ein Zeiger zurück
auf das entsprechende Hüllenobjekt
an den Anwender zurückgegeben,
das heißt,
an die Client-Applikation des Anwenders, von welcher die Zugriffsanforderung
herrührt.
In Schritt 818 wird ermittelt, basierend auf den Zugriffsregeln,
die in dem Objekt gespeichert sind, Schritt 810, falls
der Anwender auf die Daten zugreifen kann oder diesen Dienst anfordern
kann, entsprechend der empfangenen Mitteilung. Falls dies zutrifft,
ruft in Schritt 820 das Schutzhüllenobjekt das Verfahren in dem
entsprechenden Anlagenmodellobjekt auf, um die angeforderte Aktion
durchzuführen.
Im anderen Fall wird Zugriff verweigert, Schritt 822.
-
Zurückkommend
auf Schritt 805 wird, falls die Schutzhülle für das Anlagenmodellobjekt,
auf das zugegriffen wird, existiert, in Schritt 807 ein
Zeiger auf das Hüllenobjekt
zurückgegeben,
und in Schritt 818 wird der Zeiger auf das Schutzhüllenobjekt
sodann an das Verfahren weitergegeben, um die bestimmte Aktion mit
Bezug auf das angeforderte Anlagenobjekt durchzuführen. In
Schritt 820 wird festgestellt, falls Zugriff in Übereinstimmung
mit der Zugriffssteuerinformation, die in diesem entsprechenden
Schutzhüllenobjekt
gespeichert ist, zulässig
ist. Falls Zugriff für
die bestimmte Aktion zulässig
ist, wird das entsprechende Verfahren des Anlagenmodellobjekts aufgerufen,
Schritt 822, andernfalls wird Zugriff verweigert, Schritt 824.
-
In
dieser Weise operieren die Schutzhüllenobjekte, wie zum Beispiel
Schutzhüllenobjekte 911A–911E in 9,
als "Filter", um Zugriff auf
ein Werkzeug oder eine Komponente davon zu steuern. Man beachte,
dass zusätzliche
Schutzhüllenebenen, wie
zum Beispiel Ebene 901 gemäß 9, in Übereinstimmung
mit Steuerinformation in der Konfigurationsliste aufgebaut werden
können,
um zusätzliche "Filterung" vorzusehen. Es würde durch
einen Fachmann erkannt werden, dass eine zweite Schutzhüllenebene,
die in dieser Weise errichtet ist, Schutzhüllenobjekte analog zu Objekten 911A–911E, 9, einschließen würde, in
welchen Zeiger auf die entsprechenden Schutzhüllenobjekte in der ersten Ebene
gespeichert werden würden.
Auf diese Weise würde
eine Zugriffsanforderung auf ein bestimmtes Anlagenmodellobjekt
seriell in der Weise gefiltert werden, dass die Zugriffsanforderung
den Zeiger auf das Schutzhüllenobjekt
in der zweiten Ebene an das Verfahren leiten würde, wie in Verbindung mit
Schritt 820 beschrieben, welches Verfahren sodann den Zeiger, der
in dem entspre chenden Schutzhüllenobjekt
in der ersten Schutzhüllenebene
enthalten ist, weiterleiten würde,
nach Durchführung
einer Zugriffsgewährungs-Bestimmung,
wie in Verbindung mit Schritt 820 erörtert, wobei sodann das entsprechende
Schutzhüllenobjekt
in der ersten Ebene, auf das durch den Zeiger gezeigt wird, der
in dem Verfahrensaufruf weitergeleitet wurde, eine Schutzgewährungs-Bestimmung
durchführen
würde,
basierend auf der darin enthaltenen Zugriffssteuerinformation und
würde bei Zugriffsgewährung seinen
Zeiger zu dem Aufruf des Werkzeugs des Anlagenobjektverfahrens weiterleiten.