DE69132012T2

DE69132012T2 - Objektorientierte architektur für fabrikverwaltung

Info

Publication number: DE69132012T2
Application number: DE69132012T
Authority: DE
Inventors: Leroy Hess; Alexander Lozier; Unmesh Mashruwala; Subbash Belman Tantry
Original assignee: Consilium Inc
Current assignee: Consilium Inc
Priority date: 1990-10-16
Filing date: 1991-10-15
Publication date: 2000-11-16
Anticipated expiration: 2011-10-16
Also published as: EP0553285A1; US5548756A; AU9030391A; DE69132012D1; EP0553285A4; EP0553285B1; WO1992007331A1; US5398336A

Description

Bereich der Erfindung

Die vorliegende Erfindung bezieht sich auf den Bereich einer Architektur für ein Softwaresystem; insbesondere auf objektorientierte Architekturen, welche für die Entwicklung komplexer Softwaresysteme gestaltet sind.

Hintergrund der Erfindung

Zumal die Software Industrie reift und die verfügbare Rechenleistung anwächst, werden Softwareentwickler mit Problemen von unvermeidlicher Komplexität herausgefordert. Das bedeutet, daß die Probleme, welchen Forscher versuchen mit Software zu begegnen, von solcher Komplexität sind, daß es für einen einzelnen Entwickler schwierig - wenn nicht unmöglich- ist, alle Einzelheiten eines speziellen Designs zu verstehen. In manchen Fällen übersteigt die Komplexität solcher Systeme die menschliche intellektuelle Kapazität.
Man stelle sich die Anforderungen eines Software-Systems vor, welches den Entwicklungs- und Herstellungsprozeß eines kommerziellen Flugzeugs mit mehreren Motoren verwalten muß; oder die Herstellung eines sehr umfassenden integrierten Mikroprozessor-Schaltkreises (VLSI). Diese Probleme sind typisch für diejenigen, welche bei der Verwaltung der Arbeit eines Fabrikbereichs auftreten. Wie dem Fachmann bekannt ist, ist die Verwaltung einer Fabrikbereichsumgebung eine der eindrucksvolleren Aufgaben, mit welchen Computerwissenschaftler heute konfrontiert sind. Das gewaltige Maß an Anforderungen eines Software- Systems für einen Fabrikbereich hat Forscher dazu gebracht, nach alternativen Architekturen zu suchen, welche den Zweck haben, die umfassende Komplexität der berührten Aufgaben handzuhaben und zu steuern.
In der Vergangenheit, umfaßten Softwaresysteme für Fabrikbereiche traditionell zentralisierte Systeme. Der Grundansatz dieser Ansätze nach dem Stand der Technik ist, daß alle funktionellen Programme auf einem zentralisierten Hauptcomputersystem laufen. Nach diese Architekturen waren die technischen Funktionen eines Fabrikbereichs in ausführbaren Unterprogrammen angelegt. Das Hauptproblem, was jedoch solchen Architekturen innewohnt, ist daß sie eine grundlegende Tatsache der Fabrikbereichsumgebung ignorieren: nämlich, daß der Fabrikbereich seiner Natur nach verteilt ist; verteilt in dem Sinne, daß Maschinen, Vorräte, Arbeitskraft, Arbeitsanweisungen etc. alle physikalisch in unterschiedlichen Abschnitten des Fabrikbereichs lokalisiert sind. Dazu kommt, daß die Aufgabe, ein Produkt herzustellen eine komplexe Koordination aller oben aufgeführten Objekte erfordert. Somit widerspricht die Natur des Problems den konventionellen Architekturlösungen. Wegen der verteilten Natur der Fabrikbereichsumgebung, hat die Ausführung von Softwarefunktionen bei Systemen nach dem Stand der Technik inhärentermaßen Konflikte bei der Kontrolle einer Fabrikbereichsumgebung hervorgerufen.
Die Druckschrift PROCEEDINGS IFIP; Datenbanken für die Produktionsverwaltung, 10. Mai 1989, Barcelona, Spanien; D. Weber & C. Moodie "Von Datenbanksystemen zu Informationsverwaltungssystemen - Eine Anforderung an computerin tegrierter Herstellung und Montage" präsentiert ein Modell für ein Informationssystem in einer Herstellungs- oder Montageumgebung. Das objektorientierte Datenmodell, Techniken künstlicher Intelligenz und Techniken verteilter Datenbanken werden in Kombination mit anderen Techniken benutzt. Das Modell zeigt das Potential, einige der Nachteile relationaler Datenbanken und des objektorientierten Datenmodells zu überwinden.
Wie aus dem folgenden hervorgeht, sieht die vorliegende Erfindung eine objektorientierte Prozeßarchitektur für die Software zur Verwaltung eines Fabrikbereichs vor, welche in der Lage ist, alle Aspekte der Fabrikumgebung zu verfolgen, zu überwachen und zu steuern - nicht einfach nur die gerade stattfindende Arbeit. Wichtig ist, daß die Architektur der vorliegenden Erfindung mit der verteilten Natur des Fabrikbereichs kompatibel ist, da sie in ihrer Aufmachung selbst verteilt ist. Im Ergebnis produziert die vorliegende Erfindung substantielle Ersparnisse im Hinblick auf die Leistung und die Entwicklung eines Softwaresystems für einen Fabrikbereich. Außerdem weist die Architektur, zumal die vorliegende Erfindung in einer objektorientierten Weise implementiert ist, die Fähigkeit auf, Ereignisse aus der echten Welt und Objekte unmittelbar in der Software zu modellieren. Andere Vorteile und Verfahren der vorliegenden Erfindung werden zu Tage treten, wenn man die folgende detaillierte Diskussion ließt.

Zusammenfassung der Erfindung

Das objektorientierte verteilte Computersystem gemäß der vorliegenden Erfindung ist in den beigefügten Ansprüchen definiert.
Eine objektorientierte Architektur für ein Softwaresystem zum Verwalten eines Fabrikbereichs wird beschrieben. Entsprechend der vorliegenden Erfindung werden Fabrikbe reichsentitäten als Fabrikobjekte in einer relationalen Datenbank modelliert. Diese Datenbank umfaßt eine Bibliothek, welche Objekte enthält, die alle Fabrikelemente modellieren.
In einer Ausführungsform umfaßt die vorliegende Erfindung Schnittstellen-Server-Mittel, welche einem Nutzer Interaktionen mit dem Softwaresystem über eine oder mehrere Fabrikbereichsentitäten ermöglichen. Diese Entitäten schließen Operatoren, Aufseher und andere Nutzer ein. Zumeist umfassen die Schnittstellen-Server-Mittel eine X- Terminal Vorrichtung oder einen Arbeitsstations-Computer welcher an einem X-Server betrieben wird. In anderen Beispielen können die Schnittstellen-Server-Mittel auch eine Strichcodevorrichtung einschließen, welche an einen anderen Arbeitsstations-Computer gekoppelt ist, der einen Strichcodevorrichtungsserver betreibt.
Die vorliegende Erfindung umfaßt außerdem Anwendungsmaschinenmittel, um Nutzerinteraktion von Ereignissen zu verarbeiten und Anwendungsservice-Anforderungen als Ergebnis zu erzeugen. Anwendungs-Servicemittel sind auch enthalten, um die Anwendungsservice-Anforderungen zu verarbeiten und eine Datenbankservice-Abfrage im Gegenzug zu erzeugen. Diese Datenbankservice-Abfragen werden genutzt, um Daten zu empfangen, zu manipulieren und zu aktualisieren, welche in der relationalen Datenbank gespeichert sind. Ein Datenbank-Servicemittel erlaubt einen indirekten Zugriff auf die relationale Datenbank als Antwort auf eine Anwendungsservice-Anforderung. Alle diese Mittel bringen Informationen zusammen, welche aus dem Fabrikbereich in der Gestalt von Nutzereingaben gewonnen werden.
Schließlich wird ein Kommunikationsmanagermittel verwendet, um die Zwischenprozeßkommunikation zwischen den Anwendungsmaschinenmitteln, den Anwendungsservermitteln und den Datenbankservermitteln zu koordinieren.
Wichtig ist, daß die Architektur der vorliegenden Erfindung es für jede der oben beschriebenen wichtigeren Komponenten erlaubt, über Computerressourcen verteilt zu werden, welche über den Fabrikbereich und auch über mehrere Fabrikanlagen vernetzt sind.

Kurze Beschreibung der Zeichnung

Die vorliegende Erfindung wird vollständiger verstanden werden anhand der nachstehenden detaillierten Beschreibung und der beigefügten Zeichnung bevorzugter Ausführungsbeispiele der Erfindung, welche jedoch nicht als Limitierung der Erfindung auf diese speziellen Ausführungsformen verstanden werden sollen, sondern zur Erklärung und zum Verständnis.
Fig. 1 stellt ein Blockdiagramm eines konventionellen Ansatzes zur Softwareorganisation dar.
Fig. 2 ist ein Diagramm eines Beispiels einer Hierarchie ausgewählter Objekte, welche üblicherweise in einer Fabrikbereichs-Betriebsbereichs-Umgebung gefunden werden.
Fig. 3 illustriert die Beziehung zwischen verschiedenen Fabrikbereichsobjekten in Übereinstimmung mit der dargestellten bevorzugten Ausführungsform der vorliegenden Erfindung.
Fig. 4 illustriert ein einfaches Fertigungsplanungsbeispiel für die Herstellung eines Produktes als eine Folge von arbeitsbezogenen Operationen.
Fig. 5 zeigt die Hierarchie von Fabrikbereichsobjekten in Übereinstimmung mit der gegenwärtig bevorzugten Ausführungsform der vorliegenden Erfindung.
Fig. 6 illustriert die verteilte Natur der Architektur der gegenwärtig bevorzugten Ausführungsform der vorliegenden Erfindung.
Fig. 7 illustriert die architektonischen Schichten, welche von der vorliegenden Erfindung aufrechterhalten werden.
Fig. 8 ist ein Diagramm der objektorientierten Prozeßarchitektur der gegenwärtig bevorzugten Ausführungsform.
Fig. 9 illustriert die Funktionalitätsniveaus, welche in die gegenwärtig bevorzugte Ausführungsform der vorliegenden Erfindung eingearbeitet sind.
Fig. 10 zeigt, wie eine Gruppe von Anwendungsknoten zusammengruppiert ist, um einen Bereich in Übereinstimmung mit der gegenwärtig bevorzugten Ausführungsform der vorliegenden Erfindung zu bilden.

Beschreibung der bevorzugten Ausführungsform(en)

Eine objektorientierte Architektur, welche in einer Fabrikbereichs-Verwaltungssoftware Anwendung findet, wird beschrieben. In der folgenden Beschreibung werden zahlreiche spezifische Details dargestellt, wie zum Beispiel spezifische Objektarten, Aufgaben, Routinen etc., um ein vollständiges Verständnis der bevorzugten Ausführungsform der vorliegenden Erfindung zu ermöglichen. Es wird jedoch für den Fachmann offensichtlich sein, daß die vorliegende Erfindung auch ohne, diese Details ausgeführt werden kann. Umgekehrt wurden wohlbekannte Elemente nicht im Detail dargestellt um zu vermeiden, daß die vorliegende Erfindung unnötig verdunkelt wird.
Während der Beschreibung der vorliegenden Erfindung wird häufig auf die Verwendung der vorliegenden Erfindung im Zusammenhang mit einen Fabrikbereichsverwaltungs- Softwaresystem Bezug genommen. Es ist zu verstehen, daß diese Implementierung nur die gegenwärtig bevorzugte Ausführungsform der vorliegenden Erfindung berücksichtigt, und nicht als Limitierung des Bereichs der erfundenen Architektur verstanden werden soll. Es sollte auch verstanden werden, daß die Konzepte, welche in der vorliegenden Erfindung verkörpert sind, auf andere Implementierungen, Softwaresysteme, Anwendungen etc. anwendbar oder darauf ausweitbar sind. Das heißt, die neue Architektur, welche nachstehend beschrieben wird, ist von grundlegender Natur, welche eine beachtliche Anwendbarkeit außerhalb des Bereichs der Fabrikbereichsumgebung aufweist.

Ein kurzer Überblick über Objektorientierung

Eine Grundkonzept, welches früheren architektonischen Ansätzen unterliegt, ist, daß der gesamte Softwarecode auf einem einzigen Hauptcomputer abläuft. Das bedeutet, daß Anweisungen seriell in einer zentralen Rechenmaschine ausgeführt werden, wobei es sich üblicherweise um einen sehr großen, zentralisierten Computer handelt. Dieses Systeme gehen typischerweise von einem funktionalen Ansatz auf die Weise, wie Programme implementiert werden, aus. Das bedeutet, daß die funktionalen Aspekte des Programms damit identifiziert werden, wie das Programm auf die zentrale Datenbank zugreifen kann, um die Daten zu erhalten, welche es benötigt, um eine bestimmte Funktion auszuführen. Das Architekturdiagramm aus Fig. 1 illustriert diesen Ansatz nach dem Stand der Technik.
Angenommen, ein Nutzer möchte eine Maschine als eine Entität repräsentieren, welche bestimmte Attribute aufweist. Beispielsweise kann die Maschine ein Attribut namens "NAME" haben, welches die Kennung der Maschine repräsentiert. Andere wünschenswerte Attribute können den "ZUSTAND" umfassen, d. h. den Zustand der Maschine - ob die Maschine gegenwärtig stillsteht, in Reparatur ist, im Betrieb ist, etc. Alle Attribute der Maschine repräsentieren Daten. Diese Daten werden als lokalisiert in Block 10 in Fig. 1 dargestellt.
Auch mit der Maschine verknüpft ist ein Set von Funktionen, welche jeweils in Fig. 1 durch Blöcke 11-13 dargestellt werden. Beispielsweise kann Funktion F1, dargestellt durch Block 11, der Funktion "DIE MASCHINE STAR- TEN" entsprechen. In anderen Worten überführt die Ausführung der Funktion F1 den Zustand der Maschine von stillstehend in den Betrieb. Ähnlich kann Funktion F2 als Funktion "DIE MASCHINE ANHALTEN" definiert sein; und Funktion FN kann der Funktion "DIE MASCHINE ZUR REPARATUR HERUNTERFAHREN" entsprechen.
Was im wesentlichen jede der Funktionen repräsentiert durch die Blöcke 11-13 tut, ist, daß bei einer gegebenen bestimmten Maschinenidentität (d. i. NAME), die Funktion auf den Zustand der Maschine (d.i. ZUSTAND) einwirkt. Somit ist nach den Softwareansätzen nach dem Stand der Technik jede der Funktionen F1-FN in einem gesonderten Unterprogramm angesiedelt.
Der wesentliche Nachteil dieses Ansatzes besteht darin, daß für eine beliebige Anzahl dieser Unterprogramme die Möglichkeit besteht, zu jeder Zeit miteinander in Konflikt zu geraten. Außerdem läßt man beim Laufenlassen eines solchen Programms auf einem zentralen Computer die Tatsache außer Acht, daß in der Realität viele Systeme ihrer Natur nach verteilt sind und aus diesem Grund eine Architektur erforderlich machen, welche in der Lage ist, sich dieser verteilten Charakteristik anzupassen.
Objektorientiertes Software Design ist die Konstruktion von Softwaresystemen als strukturierte Sammlungen von abstrakten Datentyp-Implementierungen. Wichtig ist, daß objektorientierte Softwarekonstruktion es erlaubt, eine Entität als ein Objekt zu modellieren, welches bestimmte Charakteristiken und bestimmte Verhaltensweisen aufweist. In Übereinstimmung mit der vorliegenden Erfindung, werden Maschinen, welche in einer Fabrikbereichsumgebung benutzt werden, durch ein zugehöriges Set von Charakteristiken und Funktionen, welche sie ausführen, modelliert. In diesem Sinne sind die Charakteristiken der Maschine (welche zu den Datenaspekten der Software korrespondieren) und das Verhalten (welches zu den funktionalen Aspekten der Software korrespondiert) vollständig in einem einzelnen Konzept eingeschlossen, welches "Objekt" genannt wird. Einer der Vorteile der Objektorientierung besteht darin, daß durch das Einschließen der Charakteristiken und des Verhaltens in einem Konzept, welches "Objekt" genannt wird, ein hohes Maß an Übereinstimmung zwischen dem Softwaremodell und der Wirklichkeit erreicht wird. Objektorientierung ist auch ideal für eine verteilte Systemarchitektur geeignet, welche sich auf eine Anzahl getrennter Computer stützt (d. h. Knoten), welche alle miteinander über ein gemeinsames Netzwerk verbunden sind; und welche alle gleichzeitig Programme ablaufen lassen (natürlich in Abhängigkeit von den speziellen Funktionen, welche von einem Nutzer angefordert werden).
Ein zweites wichtiges Konzept bei der Objektorientierung ist das Konzept der Vererbung. Dies wird anhand des Beispiels aus Fig. 2 demonstriert. In Fig. 2 wird ein Objekt namens "AUSSTATTUNG" durch eine Ellipse 15 repräsentiert. Dieses Objekt besitzt bestimmte Charakteristiken wie Gewicht, Ausmaß etc. Unterklassen des Stammobjektes "AUSSTATTUNG" sind die Objekte 16 und 17 welche mit "STATIONÄR" bzw. "MOBIL" bezeichnet sind. Im wesentlichen abstrahiert die Hierarchie aus Fig. 2 die gemeinsamen Charakteristiken aus den beweglichen und den stationären Klassen in die höhere, weiter verallgemeinerte Klasse der Objektklasse welche als "AUSSTATTUNG" bezeichnet wird.
Zu beachten ist, daß die "MOBIL" Unterklasse die Charakteristiken und das Verhalten des Oberklassenobjektes erbt, aber jedes Unterklassenobjekt zusätzliche Charakteristiken einschließt, welche sie voneinander unterscheiden. Im Ergebnis stellt die Hierarchie aus Fig. 2 eine Art Taxonomie dar, bestehend aus zunehmend höheren Graden der Differenzierung von oben nach unten und von zunehmend höheren Graden der Abstraktion von unten nach oben. Beispielsweise gibt es weitere Unterklassen des Objektes "MOBIL" wie Werkzeuge, (Montage-)Vorrichtungen etc. Ähnlich schließt je eine Unterklasse der "STATIONÄR" Ausstattung Maschine, Sensor oder andere ähnliche Objekte ein. Somit kann man sehen, wie die objektorientierte Natur der vorliegenden Erfindung hilft, einige Objekte wieder zu benutzen, welche zuvor als ein übergeordnetes Objekt definiert wurden. Von einem Softwareentwicklungs- Gesichtspunkt erzeugt dieser Ansatz wesentliche Ersparnisse im Hinblick auf Leistung und Entwicklungszeit.
Zu beachten ist, daß das objektorientierte Schema, welches durch das Beispiel aus Fig. 2 dargestellt wird, sich deutlich von dem funktionalem Ansatz unterscheidet, welcher typisch für den Stand der Technik ist. In einem rein funktionalem Ansatz ist jede Entität in ihre Daten und in ein Set korrespondierender Funktionen oder Unterprogramme aufgebrochen, wobei die gemeinsamen Charakteristiken außer Acht gelassen werden, welche auf effiziente Weise wiederbenutzt werden könnten. Eines der weiteren Hauptattribute des objektorientierten Ansatzes der vorliegenden Erfindung bei der Anwendung auf Fabrikbereichsverwaltungs-Softwaresysteme, ist die Fähigkeit, ein bestimmtes Verhalten dynamisch zu verlinken. Das bedeutet, daß, weil gemeinsame Charakteristiken unter aufsteigende Abstraktionsniveaus in der Objektniveauhierarchie subsumiert werden, Verhalten, die gemeinsam auf unterschiedliche Objekte angewandt werden können, innerhalb dieser Gruppierung dynamisch verlinkt werden können. Beispielsweise kann der Nutzer ein Verhalten namens "DRUCKEN" als Stammobjekt definieren. Das Stammobjekt selbst könnte in unterschiedliche Druckertypen unterklassiert werden, so wie Laserdrucker, Zeilendrucker etc. Wenn ein Kommando "DRUCKEN" an die jeweilige Vorrichtung ausgegeben wird, hat die Software die Fähigkeit zu erkennen, daß das Druckkommando sich für jedes der unterschiedlichen Druckerobjekte unterscheidet, wobei sie jeweils die richtigen Verfahren und Routinen, welche spezifisch für jedes Objekt sind, aufruft.
Dieses Beispiel verdeutlicht einen der wesentlichen Vorteile von Objekten; das ist ihre Wiederverwendbarkeit. Kombinationen von Objekten und Nachrichten an Objekte erlauben es, eine allgemeinere Funktionalität zu konstruieren. Somit schließt die objektorientierte Natur der vorliegenden Erfindung Funktionalität auf den Objektbibliotheks-, Anwendungsmaschinen- und Serverniveaus ein, wie in Kürze detailliert beschrieben werden wird.
Für eine vollständigere Beschreibung objektorientierter Softwarekonstruktion siehe "Object-Oriented Design With Applications" von Grady Booch, Kapitel 1-7, 1991, was hiermit durch Bezugnahme als Bestandteil der Beschreibung aufgenommen wird. Andere Nachweisstellen, in welchen das objektorientierte Paradigma diskutiert wird umfassen: "The C++ Programming Language" von Bjarne Strostrup, 1986; und "Object-Oriented Software Construction" von Bertrand Meyer, 1988.

Die Fabrikbereichsumgebung

Die vorliegende Erfindung ist in dieser Beschreibung in eine Fabrikbereichsverwaltungssoftware für die Einzel- und Chargenfertigung eingebettet. Bevor man jedoch mit einer detaillierteren Diskussion dieses bevorzugten Ausführungsbeispiels fortfährt, ist es hilfreich, kurz die Organisation einer typischen Fabrikbereichsumgebung zu beschreiben.
Die überragende Mehrzahl von Fabriken kann modelliert werden, indem man eine kleine Anzahl von Basiskonzepten verwendet. Die Software, welche diese Konzepte modelliert, muß geeignet sein, all die verschiedenen Aktivitäten des Fabrikbereichs zu verfolgen, zu überwachen und zu steuern. Die vorliegende Erfindung implementiert diese Konzepte durch ihre Verwendung objektorientierter Architektur als Fabrikobjekte. Von einem Funktionalitätsgesichtspunkt aus ist das Softwaresystem durch das Verhalten dieser Objekte definiert.
In dem gegenwärtig bevorzugten Ausführungsbeispiel, besteht das Referenzmodell des Fabrikbereichs aus vier verschiedenen Schichten: der Arbeitsplatz, welcher Arbeitszentren, Arbeitszellen und Arbeitsstationen einschließt; Inventar, welches sowohl Vorrats- als auch laufendes Arbeitsinventar umfaßt; physikalische Ressourcen, einschließlich Maschinen, Arbeitskraft und Operatoren; und logische Ressourcen, welche Arbeitsanweisungen, testpläne und Teilprogramme umfassen. Jede dieser vier Schichten ist mit Hilfe von Ressourcenlisten (Bills of Resources, BOR) und Materiallisten (Bills of Material, BOM) verlinkt, welche die unverbrauchbaren Ressourcen und Materialien spezifizieren, welche benötigt werden, um eine bestimmte Operation auszuführen. Die Schichten sind außerdem mittels einer Fertigungsplanung verlinkt, welche die Folge von Operationen spezifiziert, welche ein hergestelltes Stück während des Produktionsprozesses durchlaufen muß.
Die vollständige Beziehung dieser vier Schichten wird in Fig. 3 gezeigt. Zu beachten ist, daß die laufende Arbeitsbestandsliste (Work In Progress, WIP) aus einem hergestelltem Stück besteht, welches eine Fertigungsplanung hat und eine Anzahl von Operationen umfaßt. Jede Operation nutzt eine oder mehrere BOMs und/oder BORs. Die Ressourcen und Materialien werden an Arbeitsstationen kombiniert, welche in Arbeitszellen gruppiert sind. Jede der Arbeitszellen kann weiter in Arbeitszentren abstrahiert sein, welche schließlich so gruppiert sind, daß sie die Fabrik als solche umfassen.
Das Softwaresystem, welches in Verbindung mit der vorliegenden Erfindung benutzt wird, arbeitet als zentrales Stück der Fabrikbereichsverwaltung. Das bedeutet, daß Softwareprogramme die drei Operationszentren verwalten - das Arbeitszentrum, die Arbeitszelle und die Arbeitsstationen. Insgesamt ist das System eine Schnittstelle für alle automatisierten Ausstattungsstücke, Zellensteuerungen und Arbeitsbereichs-Datensammlungsvorrichtungen um eine nahtlose Integration aller Vorrichtungen, welche in der Fabrik operieren, zu erhalten.
Eine Arbeitsstation ist eine stationäre Lokation, an welcher Arbeit verrichtet wird. Eine Montagearbeitsbank, eine Walzstation, und eine Inspektionsstation sind Beispiele für Arbeitsstationen. Allgemein impliziert Arbeit die Weiterleitung von Material, wie in Montage-, Herstellungs-, Test- oder Packprozessen. Vorzugsweise ist das Arbeitskonzept ausgeweitet um jede Art von Arbeit zu bezeichnen, einschließlich der Maschinenreparatur, dem Setup und dem Operatorentraining. Um Arbeit an einer Arbeitsstation auszuführen, sind Ressourcen wie Maschinen und Arbeitskraft an einer Arbeitsstation angeordnet. Sobald die Arbeit abgeschlossen ist, werden die Ressourcen anderweitig angeordnet und die Arbeitsanforderung wird an eine andere Arbeitsstation gerichtet.
Eine Arbeitszelle ist definiert als eine geeignete Gruppe von Arbeitsstationen. Die Arbeitszelle wird basierend auf vielen Faktoren formiert, wie etwa Bearbeitungsfluß und gemeinsames Lager. Ein synchronisiertes oder getaktetes Fertigungsband, ein Testbereich oder ein kleines Montageband sind nach dem gegenwärtig bevorzugtem Ausführungsbeispiel der vorliegenden Erfindung jeweils als Arbeitszelle modelliert.
Ein Arbeitszentrum ist eine geeignet organisierte Gruppe von Arbeitszellen. Ein Arbeitszentrum wird im allgemeinen basierend auf der Annahme geformt, daß ein bestimmtes Stück in einem Arbeitszentrum hergestellt wird. In einer Arbeitsanforderungsumgebung, wird eine Arbeitsanforderung innerhalb eines Arbeitszentrums geöffnet und geschlossen. Wenn ein Stück mehr als ein Arbeitszentrum erfordert, geht die Fertigungsplanung dieses Stücks von einem zum nächsten Arbeitszentrum in sequentieller Weise.
Fig. 4 illustriert ein Beispiel eines Fertigungspfades, welcher bei der Herstellung eines bestimmten Stücks benutzt werden kann. Jeder Knoten (d.i. 28-34) in Fig. 4 stellt einen gesonderten Bearbeitungspunkt dar, welcher auch als Operation bezeichnet wird. Sobald eine Operation abgeschlossen ist, wird eine Entscheidung über die Anordnung des Materials gemacht. Die Anordnung bestimmt die nächste Operation, zu welcher das Material übertragen wird. Wenn eine Operation erfolgreich war, wird das Material zur nächsten Operation im Fertigungsprozeß fortschreiten. Beispielsweise repräsentiert der Fortschritt von Operationen A-B-C-D einen normalen Fluß für ein Objekt welches gemäß Fig. 4 hergestellt wird.
Wenn eine Anordnung beispielsweise am Knoten 31 nicht zum gewünschten Ergebnis führte, dann kann eine Nachbearbeitung erforderlich sein. Dies ist in dem Fertigungsplanungsdiagramm durch den Nachbearbeitungspfad von Knoten 31 zurück zu Knoten 29 (d. i. von D nach B) dargestellt. Eine Auswahl von alternativen Pfaden, wie etwa manuelle vs. automatische Montage, wird in Fig. 4 durch zwei separate Pfade dargestellt: einer unmittelbar von Knoten 31 zu Knoten 34, und der andere von Knoten 31 zu Knoten 34 über Knoten 32 und 33.
Zu verstehen ist, daß das gesamte Konzept der Arbeitsbereichssteuerung, welches die Architektur der vorliegenden Erfindung benutzt, es einem Nutzer erlaubt, den gesamten Fertigungsprozeß zu verfolgen. In anderen Worten, während der Produktion etwa von 10,000 WIDGETS (s. u.) wird aufgezeichnet, welche Maschine die WIDGETS bearbeitet hat, an welchem Punkt, wie der Zustand der Umgebung während dieser Arbeit war, welches die Arbeitsanweisungen waren, welche befolgt wurden etc. Die gesamte Geschichte der Ereignisse wird aufgezeichnet, so daß man Information über jede Operation erhalten kann, welche zu einer beliebigen Zeit während des Herstellungsprozesses ausgeführt wurde.
Diese Information ist aus mehreren Gründen von Bedeutung. Angenommen, ein Teil versagt während eines Normalgebrauchs. Hier kann es entscheidend sein, zu verstehen wie und warum dieses Teil versagte und eine Herstellungsgeschichte wird unbezahlbar. In anderen Fällen ist der Herstellungsprozeß als solcher instabil und die Saftwaresteuerung der Betriebsbereichsumgebung erlaubt eine Analyse des Herstellungsprozesses mit dem Zweck, die Konsistenz und Effizienz zu erhöhen. Ein Beispiel dieser letzteren Situation tritt oft bei der Herstellung von integrierten Halbleiterschaltkreisen auf, wobei Ausbeuten durch nachdrückliche Analyse einer Vielzahl von Prozeßparametern verbessert werden müssen.

Architektonischer Überblick

Die objektorientierte Prozeßarchitektur der gegenwärtig bevorzugten Ausführungsform basiert auf den fabrikbereichs-anwendungsabhängigen Annahmen, welche oben erörtert wurden. Diese Annahmen sind kategorisiert als Aktionen oder Anforderungen an den Fabrikbereich, die Arbeitszentren, Arbeitsstationen, Arbeitszellen, Aufgaben und Nutzer.
Bezugnehmend auf Fig. 5, wird eine Hierarchie von Fabrikbereichsobjekten gezeigt. Beispielsweise verkörpert der Betriebsbereichsblock 39 den Fabrikbereich als sol chen. Innerhalb des Betriebsbereichs 39 ist eine Anzahl an Arbeitszentren 40 angesiedelt. Jedes Arbeitszentrum besteht aus einer spezialisierten, wohldefinierten und konzentrierten Herstellungsfunktion, welche in Synchronisierung mit anderen Arbeitszentren ausgeführt wird, um die Fertigungsziele der Fabrik zu erreichen. Alle Arbeitszentren haben die Eigenart, daß sie miteinander kommunizieren und in der Lage sein müssen, auf die jeweils anderen Datenbanken zuzugreifen.
Jede der Herstellungsfunktionen in einem Arbeitszentrum sind hierarchisch in Aufgaben unterteilt. Der Beginn einer Aufgabe, die Erfüllung einer Aufgabe und (wenn die Aufgabe unterteilbar ist) der Start und die Erfüllung der Unteraufgaben dazwischen, sind als Ereignisse dargestellt.
Jedes Arbeitszentrum 40 besteht aus einer Mehrzahl von Arbeitszellen 41. Arbeitszellen 41 bestehen aus einer Gruppe von Aufgaben, welche in synchronisierter und gesteuerter Weise ausgeführt werden. Die einzelnen Aufgaben können asynchron ausgeführt werden, sind aber typischerweise unter der Kontrolle einer Arbeitszellensteuerung in einer automatisierten Umgebung, oder eines Gruppenleiters/Operators im Falle einer manuellen Umgebung. Arbeitszellen werden weiter in Arbeitsstationen 42 unterteilt, worin einzelne Aufgaben physikalisch unter der Kontrolle einer Arbeitszellensteuerung ausgeführt werden.
Zu beachten ist, daß in Fig. 5 der große Buchstabe "N" anzeigt, daß mehr als eine Einheit auf dem jeweiligen Niveau sein könnte. Beispielsweise wird ein Fabrikbereich üblicherweise von zehn oder mehr Arbeitszentren unterstützt. (Die Punkte auf den Seiten von jedem Block 40 bis 42 stellen diese "N" Einheiten dar, welche auf einem parallelem Niveau in der Hierarchie vorhanden sein könnten.)
Die Arbeitsstation ist die physikalische Repräsentation einer interaktiven Umgebung, welche eine Herstellungsaufgabe ausführt. Typischerweise ist die Interaktion auf Produktionsfaktoren begrenzt: einschließlich Materialien, Operator/Aufseher, Werkzeuge, Arbeitsstationsumgebung und Arbeitsaufgabendefinitionen und Arbeitsanweisungen. Aufgaben werden ausgeführt durch, auf oder unter Benutzung von beliebigen dieser Faktoren. Beispielsweise, kann die Aufgabe ein Produkt in einer Herstellungsoperation zu bauen, die Verwendung spezifischer Stückteile erfordern, einen Operator mit einem spezifischen Geschicklichkeitsniveau, und Maschinen mit besonderen Set-Ups, welche verschiedene Werkzeuge involvieren. Einige Herstellungsoperationen können im Hinblick auf die Arbeitsstationsumgebung empfindlich sein, in welcher die Operation ausgeführt wird. Produktionsfaktoren werden an den Arbeitsstationen angeordnet, um eine Aufgabe wie in der Ressourcenliste für die Aufgabe definiert, auszuführen.
Die Aufgabendefinition umfaßt die Produktionsfaktoren, welche erforderlich sind, um die Aufgabe auszuführen und ihre Unterteilung in Unteraufgaben. Die Aufgaben, welche in einem Arbeitszentrum erledigt werden, müssen geplant, festgesetzt, gesteuert und mitverfolgt werden. Die Planung kann wöchentlich, täglich oder Schichtweise erfolgen. Die Festsetzung kann von einem Job auf den nächsten in Echtzeit erfolgen müssen.
Es wird betont, daß das Softwaresystem, welches in Verbindung mit der vorliegenden Erfindung benutzt wird, jede der Arbeitsstationen überwacht und steuert, welche in einen Arbeitsprozeß involviert ist. Auf diese Weise versieht die Architektur der vorliegenden Erfindung den Endnutzer mit einer integrierten Ansicht des Fabrikbereichs, welche als solche als so nahe an der Realität wie möglich definiert bzw. modelliert werden kann. Die Integration ist nicht auf die Produktionsfaktoren limitiert, sondern durchkreuzt die Grenzen von Fabrikarbeitszentren und erlaubt eine einfache Integration anderer Softwaresysteme.
Die architektonische Prämisse der vorliegenden Erfindung basiert auf Nutzeranforderungen. Diese Anforderungen umfassen Einfachheit der Benutzung, die Fähigkeit des Nutzers, das System zu konfigurieren, Objektorientierung, die Fähigkeit Komponenten zu verteilen, und die Fähigkeit die Software auf verschiedene Hardwareplattformen zu portieren. Auf diese Weise stellt die Architektur der vorliegenden Erfindung sicher, daß die Endnutzerschnittstelle des Softwaresystems einfach, elegant und reich an anwendungsabhängiger Funktionalität mit Relevanz für den Fabrikbereich ist.

Hardware/Software Architektur

Entsprechend der vorliegenden Erfindung wird die komplexe Umgebung des Fabrikbereichs in kleinere Stücke unterteilt, welche als Fabrikobjekte bezeichnet werden. Eines der architektonischen Ziele der vorliegenden Erfindung ist es, ein vertrautes Set von Fabrikobjekten zu identifizieren und eine Softwarefunktionalität, Datenrepräsentation und die Nutzerschnittstelle um die Kreation, Manipulation Steuerung, Datensammlung, Analyse und Verwaltung dieser Objekte zu bauen. Fabrikobjekte können jeder der fünf zuvor diskutierten Produktionsfaktoren sein, repräsentiert als Arbeitsaufträge, Lots, Serienidentifikationsnummern, Komponenten, Maschinen-/Werkzeugs- /Operatortypen etc. Fabrikobjekte können auch solche Dinge wie Konzepte, Teildefinitionen, BOM, Spezifikationen, Fertigungsplanung, oder auch Datenanzeigeobjekte, wie etwa Qualitätskontrollcharts, etc. sein.
Wichtig ist, daß die Architektur der vorliegenden Erfindung es erlaubt, jede ihrer wesentlichen Komponenten über Computerressourcen zu verteilen, welche über den Fabrikbereich und über viele Fabrikanlagen vernetzt sind. Das wesentliche Motiv für diesen Ansatz ist, daß der Prozeß der Herstellung eines Produktes - wie er in all die Arbeitszentren eines Fabrikbereichs integriert ist- eine verteilte Umgebung erfordert. Zumal die Architektur der vorliegenden Erfindung es erlaubt, jede der wesentlichen architektonischen Komponenten auf jeder geeigneten Computerressource auszuführen, welche im Netzwerk verfügbar ist, kann die Architektur als eine verteilte Prozeßfähigkeit habend charakterisiert werden. Auf dieselbe Weise stellt die Architektur der vorliegenden Erfindung eine verteilte Datenbankfähigkeit zur Verfügung, welche den Nutzer in die Lage versetzt, Daten überall im Netzwerk zu sammeln und darauf zuzugreifen. Außerdem ist die Verteilung im wesentlichen für den Nutzer transparent.
Form, Funktion, Daten und Kommunikation sind vier wichtige Aspekte eines jeden Softwaresystems. Form definiert "Aussehen und Gefühl" der Nutzerinteraktion und hilft zu bestimmen, wie Daten repräsentiert und an einen Ausgabemechanismus weitergereicht werden. Der Ausgabemechanismus umfaßt üblicherweise eine bit-map Arbeitsstation, ein Zeichenzellen Terminal, oder eine Art von Datenbufferspeicher, welcher im Speicher oder auf einer Speicherplatte angesiedelt ist.
Der funktionale Softwareaspekt bezieht sich auf Fähigkeiten, welche anwendungsabhängig sind. Beispielsweise ist der größte Teil des Betriebsbereichssteuerungs- Anwendungscodes, welcher im Verbindung mit der vorliegenden Erfindung benutzt wird, mit der Kreation, Manipulation, Steuerung, Datensammlung, Analyse und Verwaltung von Fabrikobjekten befaßt. In anderen Fällen repräsentiert der funktionale Softwareaspekt die aktuelle Anwendung, welche an der Nutzerschnittstelle läuft.
Im Kontext der vorliegenden Spezifikation bedeutet Daten die Repräsentation und physikalische Speicherung von Daten, welche während der Kreation, Manipulation, Analyse und Verwaltung von Fabrikobjekten gesammelt werden. In anderen Worten, Daten repräsentiert die Fähigkeit, dauerhafte Einträge in das Softwaresystem zu machen.
Schließlich etabliert der Kommunikationsaspekt der Software einen Dialog zwischen den Form-, Funktions- und Datenaspekten der Software. Kommunikation ist in die vorliegende Erfindung durch eine Nachrichtweiterleitungsarchitektur eingefügt, welche es erlaubt, Nachrichten über das Netzwerk von einem Programm oder einer Anwendung zu einem anderen Programm oder einer anderen Anwendung zu schicken, welche auf einer entfernten Maschine oder Knoten läuft. In Übereinstimmung mit dem gegenwärtig bevorzugten Ausführungsbeispiel hat die Kommunikationskomponente die vorrangige Aufgabe, Nachrichten, welche von einer der architektonischen Komponenten erzeugt werden, zu einer anderen Empfängerkomponente zu senden.
Eine Schlüsseleigenschaft der vorliegenden Erfindung ist die Tatsache, daß jeder der oben beschriebenen vier Softwareaspekte in das Architekturdiagramm aus Fig. 6 eingefügt ist, welches die verteilte Architektur des gegenwärtig bevorzugten Ausführungsbeispiels illustriert. Wie dort zu sehen ist, interagiert ein Nutzer, dargestellt durch Block 49 (41), mit einem Fabrikbereichsverwaltungs- Softwaresystem über eine Schnittstelle mit Fenstern vor einem X-Terminal 50. Der Nutzer kann Daten eingeben, empfangen oder manipulieren, oder einfach den Fertigungsprozeß überwachen. Ein zweiter Nutzer 56 wird auch bei der Interaktion mit einem anderen Terminal gezeigt - in diesem Fall ist die Dateneingabevorrichtung jedoch eine Strichcode-Lesevorrichtung 57.
Während einer gewöhnlichen Operationssitzung interagiert der Nutzer 41 mit dem Anzeigefenster, welches effektiv durch sein eigenes X-Server Programm 51 gesichert wird. Programm 51 läuft auf einer Endstellenmaschine, welche Fenster 50 anzeigt, und welche vorzugsweise einen Knoten des Netzwerks enthält. Dasselbe gilt für die Strichcodevorrichtung 57. Das bedeutet, daß es einen Strichcodeserver 58 gibt, welcher auf einem Endstellencomputer oder Knoten läuft. Auf beiden Maschinen, welche mit den Servern 51 und 58 assoziiert sind, laufen Softwareprogramme, welche einen Code ausführen, um Eingaben entweder von der Strichcodevorrichtung 57 oder von dem X-Terminal Fenster 50 zu erhalten. Diese Eingaben werden über das Netzwerk zu verschiedenen Anwendungen weitergereicht, welche die Funktionalität des Softwaresystems zur Fabrikbereichsverwaltung umfassen. Auf diese Weise implementieren die Schnittstellen-Services den Formaspekt der Software. Eine primäre Funktion der Schnittstellenservices ist es, Mittel zur Verfügung zu stellen, um Serviceanforderungen an die Anwendungsservices zu veranlassen, welche im Gegenzug Services von den Datenbankservices anfordern können. Es wird betont, daß in dem Ausführungsbeispiel aus Fig. 6 alle Objekte (einschließlich der Datenbankserver) über die Computer-Netzwerkressourcen verteilt sein können.
In dem X-Terminal Fenster 50 gibt es verschiedene Eingabemittel, wie etwa Knöpfe, eine Tastatur, getippte Kommandos, Graphiken, Icons etc., von welchen jede vorzugsweise als Objekt modelliert ist. Beispielsweise wird, die Aktivität, wenn der "RETURN" Knopf auf der Tastatur gedrückt wird, als ein Objekt behandelt, welches effektiv ein Verfahren aufruft, welches sich aufmacht und eine bestimmte Charakteristik verändert. Zum Beispiel kann das Verfahren darin bestehen, zunächst den Anzeigeschirm auszublenden und dann eine Anwendung auszuführen, welche in einer Hintergrundumgebung läuft.
Es ist zu verstehen, daß jedes der Elemente oder Objekte, welche in Fig. 6 illustriert werden, als separate Prozesse verteilt sind, welche auf verschiedenen Computerknoten im Netzwerk laufen. Um eine angemessene Leistungsfähigkeit des Systems zu gewährleisten, ist es notwendig, für jeden Endnutzer eine für ihn zweckgebundene Schnitt stellenservice- und Anwendungsservicekomponente zu haben. Um die Interaktion dieser Services besser zu verstehen, ist es hilfreich in das Konzept der Anwendungsmaschinen eingeführt zu werden, welche Teil der Nutzerschnittstelle sind.
Die Anwendungsmaschine hält den Kontext einer Transaktion aufrecht, nämlich daß die Anwendungsserviceanforderungen durch die lokalen Kommunikationsmanager zu Anwendungsservern gelangen und dort abgeschlossen werden. Eine Anwendungsmaschine, welche eine Eingabe von einem Endnutzer erfordert (über ein X-Fenster) wird üblicherweise als X- Anwendungsmaschine (X-Application-Engine, XAE) bezeichnet.
Die Anwendungsarchitektur der vorliegenden Erfindung unterstützt interaktive und nicht-interaktive (Rechen-) Anwendungen. Eine typische Anwendung besteht aus einer Anwendungsmaschine und einer oder mehreren Anwendungsservern. Die primäre Unterscheidung zwischen einer Anwendungsmaschine und einem Anwendungsserver ist, daß die Anwendungsmaschinen nicht unmittelbar mit Fabrikobjekten interagieren. Statt dessen bringen sie Anwendungsserver dazu, Fabrikobjekte zu erzeugen oder zu modifizieren. Anwendungsmaschinen formen die primäre Interaktion mit dem Endnutzer. Anwendungsserver interagieren niemals direkt mit dem Nutzer.
Jede Anwendungsmaschine umfaßt einen separaten Prozeß, welche wenigstens einen Event-Handler und etwas anwendungsspezifischen Code enthält. Der Event-Handler ist ein Prozeß, welcher auf Ereignisnachrichten (d. i. Anforderungen) reagiert, welche vom Kommunikationsmanager geliefert werden und auf X-Fensterereignissignale, welche von der X-Schnittstelle geliefert werden. Jede Anwendungsmaschine enthält auch nicht wiederverwendbaren, anwendungsspezifischen Code, welcher den Anwendungskontext/Zustand aufrecht erhält und Anwendungsserviceanforderungen erzeugt.
Diese Anforderungen werden zu dem Kommunikationsmanager weitergeleitet, welcher die Anforderung an einen geeigneten Anwendungsserver weiterleitet.
Im wesentlichen sind Anwendungsmaschinen die Hintergrundprozesse, welche die Nutzerinteraktion weiter verarbeiten. Als solche sind die Anwendungsmaschinen normalerweise jeweils auf einem separatem Knoten im Netzwerk angeordnet. Beispielsweise ist in Fig. 6 die Anwendungsmaschine 52 für das X-Terminal Fenster 50 zweckgebunden, wohingegen die Strichcode-Anwendungsmaschine (Bar code Application Engine, BAE) 60 für die Verwendung mit der Strichcodevorrichtung 57 zweckgebunden ist.
Interaktive Anwendungsmaschinen werden X-basierte Anwendungsmaschinen (X-based Application Engines, XAEs)genannt. (Zu beachten ist, daß eine Anwendungsmaschine, welche keine Nutzerschnittstelle hat, einfach als Anwendungsmaschine bezeichnet wird.) Eine X- Anwendungsmaschine enthält X-Nutzer-Schnittstellencode (X-User Interface code, XUI code), welcher den gesamten Nutzerdialog und Päsentationskomponenten des Softwaresystems enthält. Zur Zeit basiert dieser Code auf dem XUI Tool Kit der Digital Equipment Corporation, welcher unter der DEC Windows Umgebung läuft.
Der XUI Code in einer Anwendungsmaschine erzeugt das oder die Anwendungsfenster und versieht es mit "Widgets" (der Ausdruck "Widgets" bezieht sich auf Nutzerschnittstellenabstraktionen, wie Knöpfe, Menüs, Textfelder, Graphiken etc.) aus dem XUI Tool Kit. Die XUI Widgets interpretieren X-Ereignisse, welcher vom X-Server des Nutzers kommen, und erzeugen Rufe zu den Rückrufroutinen in der Anwendungsmaschine. Rückrufroutinen bilden Nutzerinteraktionen vom X-Server (X-Ereignisse) auf eine spezielle Anwendungsmaschinen-Funktionalität ab. Somit verknüpfen Anwendungsmaschinen die Nutzerschnittstellen-Widgetbiblio thek mit der Fabrikservices/Fabrikobjektbibliothek (was bald weiter erörtert wird).
Der Script-Anwendungsserver, welcher in Fig. 6 durch Ellipse 54 dargestellt ist, ist ein Beispiel für einen spezialisierten Anwendungsserver. Mit dem Script-Anwendungsserver wählt der Nutzer einen bestimmten Script-Code und führt ihn aus. Der Script-Anwendungsserver erzeugt X- Anwendungsmaschinen-Anforderungen und gibt die Anforderungen an den Kommunikationsmanager weiter, wie etwa den Kommunikationsmanager 53 in Fig. 6. Der Kommunikationsmanager ruft im Gegenzug XAEs auf. Weil andere X- Anwendungsmaschinen erzeugt werden können, kann ein Anwendungsprogrammierer das Skript benutzen, um eine Sequenzkontrolle über die Ausführung einer Ansammlung von X-Anwendungsmaschinen zu erhalten. Um eine X-Anwendungsmaschine aufzurufen, muß der Nutzer ein Identifizierungsmittel (X-Identifier, XID) für die Anzeige vorsehen. Wenn eine "Aufrufs"-Anforderung für eine X-Anwendungsmaschine zum ersten Mal von einem Kommunikationsmanager empfangen wird, wird die angeforderte X-Anwendungsmaschine erzeugt und die Prozeß-ID in eine aktive Prozeßtafel eingetragen. Die angeforderte XID (das Identifizierungsmittel für die Anzeige) wird ebenfalls in der aktiven Prozeßtafel gespeichert. Die Aufrufsanforderung für die X-Anwendungsmaschine wird dann an den Prozeß-Event- Handler der neu erzeugten X-Anwendungsmaschine weitergereicht. Dieser Event-Handler öffnet eine X-Verbindung zu der angeforderten X-Anzeige und erzeugt die geeigneten Anwendungsfenster.
Sobald die Transaktion beendet ist, entfernt der X- Anwendungsmaschinen-Prozeß die Anwendungsfenster von der X-Anzeige und kehrt zurück in einen Ruhezustand. Wenn dieser Zustand eingetreten ist, erzeugt die X- Anwendungsmaschine ein X-Anwendungsmaschinen "inaktiv" Ereignis, welches an den lokalen Kommunikationsmanager gesendet wird.
Im Beispiel von Fig. 6, agiert der Prozeß 53 als der lokale Kommunikationsmanager (Communications Manager, cm) für die Prozesse 52, 54 und 55. Wenn eine andere Aufrufsanforderung für eine X-Anwendungsmaschine empfangen wird für dieselbe Art von X-Anwendungsmaschinen-Prozeß, wird der ruhende "inaktive" Prozeß reaktiviert. Die Anwendungsmaschine zeigt ihre Anwendungsfenster an und ist sofort bereit, eine Transaktion durchzuführen.
Funktionalität wird erreicht, indem Anwendungsserverprozesse verwendet werden. Diese Programme bringen Information (d. i. Nutzereingaben) zusammen, welche vom Fabrikbereich eingesammelt werden. Diese Funktionalität umfaßt Maschinen- und Ausstattungsverfolgung, Arbeitskraftverfolgung, Arbeit-im-Inventar-Verfolgung, Ansetzen von Ressourcen in kurzen Intervallen, Arbeit und Erledigung, nutzerdefinierte Alarme und Untersuchungen, statistische Prozeßkontrolle und Fabrikbereichsmail. Jeder dieser weiten Bereiche besteht aus Transaktionen, welche spezifische Aufgaben ausführen. Jede dieser Transaktionen wird aus einem oder mehreren Anwendungsserverprozessen gebildet, welche ein wohldefiniertes wiederverwendbares Systemniveau an Service zur Verfügung stellen. In diesem Kontext bedeutet Systemniveau, daß der Service für jeden Nutzer des Systems transparent ist; dabei sieht der Nutzer nur die Notation der Transkription. Der Service ist jedoch unabhängig gepackt, da er in vielen verschiedenen Transaktionen genutzt wird. In dieser Hinsicht kann man sich Anwendungsserver als Untertransaktionen vorstellen, welche, wenn sie zusammengefügt werden, die Basis der Anwendungsmaschine formen.
Die Anwendungsserver (AS) implementieren die funktionalen Aspekte des Softwaresystems und sind die einzigen Services, welche auf Datenbankservices zugreifen können. Ein Anwendungsserver führt eine Anwendungsfunktion auf Anforderung der Nutzerschnittstelle aus, spezifisch eine Anwendungsmaschine. Jede On-Line Transaktion steht unter der Kontrolle einer Anwendungsmaschine. Die Anforderungen werden vom Kommunikationsmanager an den Knoten weitergeleitet, an welchem der Anwendungsserver läuft. Jede Anforderung wird von dem Anwendungsserver automatisch behandelt, ohne eine Kontextinformation zwischen der Serviceanforderung einer Anwendungsmaschine aufrechtzuerhalten.
Beispielsweise in Fig. 6 können Anwendungsserver 54 und 55 Anwendungsfunktionen auf Anforderung von Anwendungsmaschine 52 ausführen. Diese Anforderungen werden durch den Kommunikationsmanager 53 weitergeleitet, und laufen, im Falle einer Datenbankserviceanforderung, durch Kommunikationsmanager 62 zum Datenbankserver 65. Zu beachten ist, daß manche funktionale Aspekte, welche von Anwendungsservern ausgeführt werden, im Softwaresystem global erforderlich sind. Das bedeutet, daß man viele Anwendungsserver auf einem einzigen Knoten im Netzwerk laufen lassen kann, ebenso wie man viele Anwendungsmaschinen auf einem einzelnen Knoten laufen lassen könnte.
Jeder Anwendungsserver ist ein separater Prozeß, welcher von dem Kommunikationsmanager erzeugt wurde. Die Funktion kann von vielen unabhängigen Anwendungsservern oder Anwendungsmaschinen benutzt werden. Die Anwendungsmaschine kann auch gleichzeitig Services von vielen Anwendungsservern anfordern. Der Anwendungsmaschinen-Ereigniskreislauf ist geschrieben, um die Rückgaben, wenn es welche gibt, von vielen Anwendungsserverprozessen unterzubringen. Unabhängige Anwendungsserver erlauben dem Kommunikationsmanager Serviceanforderungen zu priorisieren.
Um Wiederverwendbarkeit und Gleichzeitigkeit zu erreichen, ist jeder Anwendungsserver als zustandslose Prozedur geschrieben. Das bedeutet, daß, anders als die Anwen dungsmaschinen, welche den Zustand des Nutzerdialogs und den Zustand der Transaktion aufrecht erhalten, jeder Anwendungsserver nur einen einfachen Service zur Verfügung stellt. Dieser Service könnte ein Satz zurückgegebener Werte sein, oder die erfolgreiche Operation an einem Satz von Objekten und die Niederschrift dieser Veränderungen in die Datenbank. Um dieses Ziel zu erreichen hat jeder Anwendungsserver einen einfachen Event-Handler, welcher Anforderungen seiner Services annimmt und dann eine Antwortnachricht zusammenstellt. Nach der Rückgabe sitzt er in einem unbeschäftigten Wartezustand für die nächste Anforderung. Diese Kapselung einer Viel-Objekt-Interaktion stellt ein einzelnes Funktionalitätselement zur Verfügung. Dies ist nützlich für viele unterschiedliche Transaktionen und stellt das Serviceniveau funktionaler Granularität zur Verfügung.
Es gibt zwei speziell zweckgebundene Anwendungsserverprozesse auf jedem Anwendungsknoten: den Fernobjektserver und den Skriptserver. Der Fernobjektserverprozeß ist der einzige Prozeß auf jedem Knoten, der Anforderungen von Operationen auf nicht-anhaltenden geteilten Objekten handhabt. Der Fernobjektserver enthält eine Liste nichtanhaltender geteilter Objekt-IDs und ihrer Lokalisierungen. Zumal es nur einen einzigen Fernobjektserverprozeß pro Knoten gibt, muß der Kommunikationsmanager Anforderungen aufreihen, wenn mehr als eine Anforderung zur selben Zeit ankommt. In jeder anderen Hinsicht ist der Fernobjektserver nur ein weiterer Anwendnungsserverprozeß.
Der zweite zweckgebundene Anwendungsserverprozeß ist der Skriptserver - ein Service, welcher vom Nutzer geschriebene Skripten liest, interpretiert und ausführt. Der Skriptserver ist in der Lage, ein Skript in objektbezogene Nachrichten zu untergliedern, fordert verschiedene Anwendungsmaschinen an und führt Programmiersprachenoperationen aus.
Im wesentlichen enthält jeder Anwendungsserver ein oder mehreres von dem folgenden: Anwendungsknoten, welcher die transaktionsspezifischen Integritätsprüfungen zwischen Fabrikobjekten ausführt, Datenbankaktualisierungen macht, welche Änderungen an den bleibenden Fabrikobjekten bewirken; Fabrikobjekte, welche Nachrichten vom transaktionsspezifischen Anwendungscode empfangen, um die Spezialfallvariablen von Fabrikobjekten abzufragen oder auf einen neuen Stand zu bringen; oder einen Fernobjektservice, welcher einen reinen Lesezugriff auf bestimmte nichtanhaltende Objekte in den lokalen geteilten Speichercache auf Anforderung eines Fernkommunikationsmanagers zur Verfügung stellt.
Ein Fernkommunikationsmanager bringt typischerweise eine solche Leseanforderung an den lokalen Kommunikationsmanager, welcher die Anforderung an seinen lokalen Fernobjektserver weiterleitet. Beispielsweise kann in Fig. 6 ein Anwendungsserver 64 vorhanden sein, um eine Menge Material zu versenden, während ein anderer Anwendungsserver (nicht dargestellt) eine Maschine startet. Die Architektur der vorliegenden Erfindung erlaubt es bei einer komplexen Anwendungsmaschine Anwendungsserviceanforderungen zu erzeugen, asynchron ausgeführt werden können. Dies impliziert, daß jeder Anwendungsserver seinen eigenen Prozeßraum betreibt, um eine Mehrpfadbetriebsfähigkeit zu erreichen. In dieser Hinsicht ist es für eine Anwendungsmaschine möglich, anzufordern, daß der "Start Maschine" Anwendungsservice parallel zu dem des Versendens oder dem "BRINGE DAS LOT HEREIN"-Anwendungsservice ausgeführt wird.
Im Beispiel aus Fig. 6 stellen die Kommunikationsmanager 53, 61, 62 und 63 eine strukturierte, ortsunabhängige Zwischenprozeßkommunikation über die Knoten hinweg zur Verfügung. Sie integrieren auch das erforderliche Netzwerkmanagement mit heterogener Netzwerkunterstützung. Somit läuft jeder Kommunikationsmanager als separater Pro zeß auf jedem Knoten, welcher Zwischenprozeßkommunikation in oder über Knoten erfordert. Die Flexibilität der vorliegenden Erfindung besteht in der Trennung von Verantwortlichkeiten und der Kapselung von Funktionalität. Ein großer Vorteil dieser Trennung liegt in der Formung eines einmaligen Prozesses. Zu diesem Zweck wird ein zentraler Koordinator (d.i. der Kommunikationsmanager) benötigt, um Serviceanforderungen und Antworten zwischen Transaktionen weiterzuleiten. Dieser zentrale Mechanismus muß auch die verschiedenen Prozesse erzeugen und verwalten. Entsprechend der vorliegenden Erfindung ist der Kommunikationsmanager ein separater Prozeß, welcher Datenkommunikation zwischen Anwendungsmaschine, Anwendungsservices und Datenbankserviceprozessen koordiniert. Auf jedem Anwendungsknoten gibt es nur einen Kommunikationsmanager.
Es ist zu berücksichtigen, daß die Wechselbeziehung und die Anzahl von Prozessen, welche für jede Transaktion zur Verfügung stehen, durch die verteilte Architektur der vorliegenden Erfindung kompliziert wird. Wenn die Anzahl der möglichen Kombinationen vergrößert wird, werden auch die Probleme und die Komplexität des Kommunikationsmanagers vergrößert. Um dies zu begrenzen, ist die Architektur des gegenwärtig bevorzugten Ausführungsbeispiels moderat begrenzt, wie anhand des Diagramms in Fig. 10 dargestellt, so daß jeder Datenbankknoten nur einen Untersatz von Anwendungsknoten bedient. Diese Anwendungsknoten unterstützen im Gegenzug einen Untersatz von X-Server- Knoten. Eine Gruppe von Anwendungsknoten wird als Datenbankdomäne bezeichnet, welche in Fig. 10 durch die gestrichelte Linie 90 dargestellt ist.
Datenbankserver haben Schnittstellen mit dem Datenbanksystem auf ihrem Knoten und Kommunikation mit anderen Datenbankservern von anderen Domänen, um verteilte Daten zu empfangen. Datenbankservices unternehmen keine direkte Kommunikation mit Anwendungsknoten, welche von anderen Datenbanken bedient werden. Ähnlich können die Anwen dungsknoten, welche sie bedient, nur mit anderen Anwendungsknoten innerhalb der Domäne kommunizieren. Anwendungsknoten mit unterschiedlichen Datenbankdomänen kommunizieren nur über Anforderung eines Objektnachrichtsaufrufes über den Fernobjektserver.
Unter weiterer Bezugnahme auf Fig. 6 kommunizieren die X-Anwendungsmaschinen auf einem Knoten mit Anwendungsservern über den lokalen Kommunikationsmanager, wie oben erörtert. Beispielsweise kommuniziert die Strichcode- Anwendungsmaschine 60 mit dem Anwendungsserver 64 über die Kommunikationsmanager 61 und 63. Außerdem gibt es einen Kommunikationsmanager 62, welcher auf dem Datenbancknoten läuft, welcher Nachrichten an die Datenbankserver 64 von den Anwendungsservern weiterleitet.
Man stelle sich nun vor, was geschieht, wenn eine normale Operationssitzung beginnt. Wenn das Fabrikbereichssoftwaresystem gestartet ist, ist es die erste Aufgabe des Kommunikationsmanagers, einen Anzeigemanagerprozeß für jeden X-Server zu erzeugen, welcher physikalisch mit dem Knoten verbunden ist. Der Kommunikationsmanager unterhält eine Tafel, welche während der Konfiguration des Softwaresystems erzeugt wird, welche die Netzwerktopologie enthält. Die X-Server, andere Anwendungsknoten und der lokale Datenbankknoten sind aufgelistet. Diese Liste wird sowohl während des Start-Ups als auch während es Normalbetriebs benutzt. Nachdem die Anzeigemanagerprozesse gestartet sind, erzeugt der Kommunikationsmanager einen Satz von Anwendungsservices, welche den Nutzer-Login handhaben. Der Knoten ist nun bereit zur Benutzung.
Wenn jeder X-Server ein Login akzeptiert, wird eine Liste gültiger Transaktionen zurückgegeben. Wenn diese Transaktionen ausgewählt sind, werden Anwendungsmaschinenprozesse von dem Kommunikationsmanager erzeugt. Wenn ein Service angefordert ist, erzeugt der Kommunikationsmanager einen neuen Anwendungsservice der angeforderten Art. Die se Prozesse werden niemals abgeschlossen, sondern von der Anwendungsmaschine wiederverwendet, welche die Art Service anfordert, die sie zu bieten hat.
Der Kommunikationsmanager unterhält eine Tafel, welche die Prozeß-ID mit der Serviceart eines jeden Anwendungsservers in Beziehung setzt. Diese Services sind nicht nur auf die Verwendung durch Anwendungsmaschinen beschränkt. Jeder Anwendungsserver kann die Services eines anderen Anwendungsservers benutzen. Der Kommunikationsmanager macht diese Serviceanforderungen unabhängig von der anfordernden Prozeßart. Dies stellt die Basis für die unterschiedlichen Funktionalitätsniveaus zur Verfügung: der Kommunikationsmanager und die Anwendungsmaschine führen Anforderungsservices von Anwendungsservices aus und stellen Transaktions "start" und "Festschreibungs" Datenbank Servicenachrichten zur Verfügung. Das Anwendungsservice- Niveau leitet die Objektbenachrichtigung und das Schreiben in die Datenbank. Der Kommunikationsmanager leitet alle Nachrichten transparent weiter.
Nachrichtenweiterleitung ist eine der wesentlichen Funktionen des Kommunikationsmanagers. Während des Logins leitet er die Anzeigemanageranforderung zu einem Loginanwendungsserver weiter. Danach leitet er Anwendungsmaschinen- oder Anwendungsserveranforderungen an verfügbare Anwendungsservices basierend auf dem Servernamen weiter. Er leitet dann die Antworten zurück zu der bzw. dem anfordernden Anwendungsmaschine oder Server.
Der Kommunikationsmanager betreibt auf transparente Weise diese vorübergehende Prozeßverlinkung. Wenn kein Anwendungsserver der angeforderten Art verfügbar ist, speichert der Kommunikationsmanager die Anforderung in einem Pufferspeicher, bis einer zur Verfügung steht. Der Kommunikationsmanager hat einen Prioritätensetzmechanismus, welcher es erlaubt, Nachrichten mit Priorität sofort zu bedienen, unabhängig vom Prozeßlimit.
Insgesamt verkörpert der Kommunikationsmanager den Kommunikationsaspekt der Software und stellt folgendes zur Verfügung: Aufreihen Prioritätensetzung von Serviceanforderungen; Nachrichtenweiterleitung; Prozessorverwaltung und -zuweisung für Anwendungsmaschine, Anwendungsserver und Datenbankserver; Transaktions-ID-Erzeugung; und Aussendung von Anforderungen für Services, welche er nicht zur Verfügung stellen kann, an andere Kommunikationsmanager.
Datenbankserver implementieren die Datenaspekte der Software und stellen Datenbankservices zur Verfügung, welche in ihrem eigenen Prozeßkontext laufen. In der Architektur der vorliegenden Erfindung, gibt es üblicherweise einen Pool von Datenbankservern 65, welche darauf warten, Nachrichten von verschiedenen Anwendungsservern zu verarbeiten, welche über das Netzwerk verteilt sind.
Ein Datenbankserver umfaßt Prozeduren, welche Nachrichten von einem Anwendungsserver verwalten, um auf eine relationale Datenbank 66 zuzugreifen. Diese Prozeduren sind Verfahren, welche in Datenobjekten eingebettet sind. Ein Datenbankserver betreibt den kompletten Kontext einer Datenbanktransaktion, wie er von einer entsprechenden Anwendungsmaschine definiert ist, welche gerade bedient. Zu beachten ist, daß es nach dem bevorzugten Ausführungsbeispiel nur eine Art von Datenbankserver gibt; jedoch könnte es viele Spezialfälle von Datenbankservern geben, welche viele Anwendungsserver zur selben Zeit in einem Datenbankknoten eines Arbeitszentrums bedienen.
Es sollte offensichtlich sein, daß, weil die Architektur der vorliegenden Erfindung Komponenten über vernetzte Computerressourcen verteilt, es das Erfordernis für ein Datenbanksubsystem gibt, welches eine vernetzte Verbindung zu Clientanwendungen unterstützen kann. Somit erstreckt sich das Verteilungskonzept auch auf die Daten selbst. Innerhalb des Netzwerks speichern viele für Datenbankzwecke bestimmte zentrale Prozeßeinheiten (central processing units, CPUs)unterschiedliche Untersätze von Daten in eine Grundstruktur. Dies wird als horizontale Fragmentierung bezeichnet. Die Datenbankservices-Schicht verwaltet auf transparente Weise die Untersätze und agiert wie andere Datenbankknoten wie es erforderlich ist, um eine Anwendungsanforderung zu erfüllen.
Mit den Datenbankservices kann der Nutzer Datenbankelemente zum Standardgerüst hinzufügen. Anwendungsniveauunterstützung, wie etwa eine Kommandosprache und spezielle Objekte, fügen diese neuen Dateneinheiten in die Arbeiten der Anwendungen ein. Mit Datenbankservices kann der Nutzer diese neuen Entitäten definieren und sie in die Grundrahmensdefinition in kontrollierter und unterstützter Weise einfügen. Der Nutzer kann auch dynamisch abgeleitete Attribute definieren. Diese Werte werden aus Berechnungen, Tafeln oder Nachschlagmitteln erhalten und drücken Beziehungen zwischen Attributen aus, welche der Nutzer möglicherweise überwachen möchte. Diese Werte können auch für die Anwendungen mittels der Kommandosprache verfügbar gemacht werden.
Weil die gegenwärtig bevorzugte Ausführungsform der vorliegenden Erfindung für eine Arbeitsauftrags- und wiederholte Herstellungsumgebung ausgebildet ist, ist die Datenmenge, welche in dieser Umgebung für eine individuelle Einheit aufrechterhalten und aktualisiert wird, relativ klein. Das Ziel besteht darin, die Laufrate der Fertigungsstraße zu maximieren. Infolgedessen gibt es einen hohen Anteil an Abfrägetransaktionen in den Anwendungen, wie etwa Statusanzeigen und Alarmbedingungsprüfungen. Um die Datenbankintegrität zu bewahren, bringt eine gegebene Aktualisierungs-Transaktion eine Anzahl von Datenbankauslesungen mit sich. Beispielsweise würde es für einen Auslesevorgang, welcher durchgeführt wird, um die Existenz wechselbezogener Daten zu verifizieren, wesentlich auf die Geschwindigkeit der Anfrageverarbeitung ankommen. Integrierte Systeme wie Sensoren und Strichcodeleser hängen nicht davon ab, daß eine Datenbanktransaktion abgeschlossen wird, bevor sie ihre Pufferspeicher löschen, um eine neue Eingabe aufzunehmen. Diese Faktoren verdeutlichen, daß die Anfrageleistungsfähigkeit mit Nachdruck optimiert werden sollte.
Ein anderer Zweck der Datenbankservices besteht darin, eine transparente Übersetzung zwischen dem relationalen Datenbankmodell und dem objektorientierten Anwendungsmodell zur Verfügung zu stellen. Aus Effizienzgründen sind gewisse Parallelen erforderlich. Beispielsweise korrespondiert jedes Fabrikobjekt so weit wie möglich mit einer einzelnen Datenrelation, um die Datenzugriffe zu minimieren, welche beim Spezialisieren (d. i. bauen) eines Objektes erforderlich sind. Einige Situationen machen es erforderlich, Unterschiede, wie etwa die Übersetzung von Speicherpointern zwischen verknüpften Objekten im Anwendungsbereich, in Referenzen auf primäre und fremde Kennbegriffsfelder und Datenbankentitäten zu modellieren. Somit ist es ein primäres Ziel des Softwaresystems den Prozeß des Baus von Fabrikobjekten aus dem Inhalt der Datenbank zu automatisieren.
In seiner einfachsten Form kann man sich für jeden Datenbankserver vorstellen, daß er bleibende Objekte, welche permanent in der Datenbank gespeichert sind, verwaltet. Selbstverständlich unterstützt der Datenbankserver auch den verteilten Datenzugriff. Dieser Ansatz ist vorteilhaft, da es der Realität der Fabrikumgebung entspricht, daß viele Fabrikobjekte in unterschiedlichen Bereichen des Fabrikbereichs lokalisiert sind. Somit wird es notwendig, Objektdaten in der Nähe des Ortes zu speichern, an welchem das jeweilige Objekt physikalisch angesiedelt ist. Dies macht es für den Datenbankserver erforderlich, verteilten Datenzugriff über unterschiedliche Datenbanken zur Verfügung zu stellen, und vorzugsweise auch eine verteiltes Datenaktualisierung.
Es ist interessant, festzustellen, daß entsprechend der Architektur der vorliegenden Erfindung jeder der vier Softwareaspekte (d.i. Form, Funktion, Kommunikation und Daten) auf jedem gegebenen Knoten oder zu jeder Zeit nur auf einem Knoten laufen kann - abhängig davon, wie der Nutzer sein System konfigurieren möchte. Beispielsweise könnte es ein Szenario sein, alle Anwendungsmaschinen, Anwendungsserver, einen Kommunikationsmanager und eine Datenbank auf einem großen Hauptrechner mit einer Mehrzahl von Anzeigevorrichtungen kleinerer Kapazität zur Nutzerinteraktion zu haben. Ein gewöhnlicheres Szenario besteht darin, alles über die Fabrikbereichsumgebung zu verteilen. Das bedeutet, daß sich Datenbankserver auf einer Maschine befinden würden, Anwendungsserver auf anderen, und Frontanwendungsmaschinen würden auf noch anderen separaten Knoten laufen. Auf dieses Weise hängt das System niemals völlig von einem Computer ab. In anderen Beispielen mag es erwünscht sein, Datenbanken aufgrund ihrer großen Größe über viele Knoten zu verteilen. Offensichtlich entspricht die Idee die vier Softwareaspekte auf diese Weise zu verteilen der Tatsache, daß der Fabrikbereich von Natur aus verteilt ist.
In Übereinstimmung mit der gegenwärtig bevorzugten Ausführungsform der vorliegenden Erfindung, laufen die Anwendungsmaschinen normalerweise auf einem VAX-3100 Computer, welcher zusammen mit seinem assoziierten Server einen Netzwerkknoten ergibt. Ein VAX-4000 Computer wird vorzugsweise als Datenbankserver verwendet, während die Anwendungsserver auf einer weiteren VAX-3100 Maschine angesiedelt sind.
Bei der Implementierung der Hardware-Architektur wird angenommen, daß ein fabrikweites Netzwerk mit hoher Bandweite und Schrittgeschwindigkeit zur Verfügung steht. Na türlich könnte es andere Computer geben, welche Firmeninformationssystembedürfnisse auf demselben Netzwerk abdecken, oder es könnte einen anderen Computer auf demselben Netzwerk geben, welcher als ein Firmengateway zu einem firmenweiten Netzwerk fungiert. Ein typisches Netzwerk ist DECnet und/oder Transportkontrollprotokoll (Transport Control Protocol)/Internet Protokoll (TCP/IP) kompatibel.
Jedes Arbeitszentrum wird normalerweise von einem Netzwerk von Superminicomputer, Supermikrocomputern, Arbeitsstationscomputern und Industrie-PCs unterstützt. Der Superminicomputer kann als Firmengateway fungieren. Ferner hat jedes Arbeitszentrum vorzugsweise einen Supermikrocomputer, welcher als zentrale Datenbankmaschine fungiert und welcher auch als ein Startknoten für das Arbeitszentrum funktionieren kann. Alle Computer, welche zu einem Arbeitszentrum gehören, sind gewöhnlich lokalbereichsvernetzt.
Vorzugsweise wird jede Arbeitsstation in einem Arbeitszentrum von einer Strichcodevorrichtung oder einem Arbeitsstationscomputer unterstützt. Alle Strichcodevorrichtungen sind üblicherweise mit einem Industrie-PC verbunden, welcher als Datensammlungs-Zusammenfasser für ein Arbeitszentrum fungiert. Offensichtlich kann ein Aufseher einen Arbeitsstationscomputer benötigen, welcher für seine oder ihre Bedürfnisse zweckgebunden ist.
Zu beachten ist, daß die Grundarchitektur, welche so weit beschrieben ist, von einer beliebigen Anzahl von Anwendungssoftwaresystemen unterstützt werden könnte. Zumal die Architektur der vorliegenden Erfindung Merkmale einbringt, welche sowohl flexibel als auch ausweitbar sind, ist sie ideal geeignet für die Fabrikbereichsverwaltung, Steuerung und Automatisierung. Jedoch sollte verstanden werden, daß andere Anwendungen auch von der bisher beschriebenen Architektur profitieren könnten.
Bezugnehmend auf Fig. 7 wird nun die Taxonomie der verschiedenen architektonischen Schichten der gegenwärtig bevorzugten Ausführungsform der vorliegenden Erfindung gezeigt. Der größte Teil der Online und/oder Echtzeit- Anwendungssoftware ist in den Anwendungsmaschinen implementiert, welche die Services eines X-Servers erfordern oder nicht erfordern können. Denkbar ist, daß ein Ereignis-Scheduler oder eine Anwendung nicht die Services eines X-Servers erfordern. Auf der anderen Seite kann es Anwendungsmaschinen geben, welche sich auf einen Strichcode-Service stützen. Zur Wiederholung: Anwendungsmaschinen, welche die Services eines X-Servers erfordern sind bekannt als X-Anwendungsmaschinen. Diese Anwendungsmaschinen halten den Kontext für eine Transaktion im Hinblick auf Anwendungsservice-Anforderungen über den Kommunikationsmanager an die und ausgeführt bei den Anwendungsservern aufrecht.
Faßt man die bisherigen Ausführungen zusammen, so folgt die verteilte, objektorientierte Architektur der vorliegenden Erfindung einem Meldungsweitergabe-Paradigma. Die Architektur ist charakterisiert als verteilt über drei Typen von Computerknoten - den Schnittstellenserverknoten, den Anwendungsknoten und den Datenbankknoten. Die Anwendungsmaschinen, die Anwendungsserver, der Kommunikationsmanager und andere Fernserver oder Manager (d.i. Anzeigemanager) laufen alle auf dem Anwendungsknoten. Der Schnittstellenserverknoten ist typischerweise eine X- Terminal-Vorrichtung, wie etwa ein Arbeitsstationscomputer, welcher einen X-Server betreibt. Strichcodevorrichtungen können auch mit einem Arbeitsstationscomputer verknüpft sein, welcher einen Strichcodevorrichtungsserver betreibt. Schließlich enthalten Datenbankknoten Datenbankserver, welche Zugriff auf eine relationale Datenbank zur Verfügung stellen, welche eine Bibliothek von Fabrikbereichsentitäten speichert, die als Fabrikobjekte modelliert sind.
Um die vorliegende Erfindung besser zusammenzufassen, stelle man sich das folgende Architektur-Interaktions- Beispiel vor. Man nehme an, ein Nutzer möchte eine Sitzung starten, indem er ein Kommando an einer X-Terminal- Arbeitsstation eingibt. Die Startup-Nachricht wird zu dem Kommunikationsmanager auf dem Anwendungsknoten gesendet, welcher mit dem X-Server des Nutzers assoziiert ist. (Es wird angenommen, daß der X-Server auf einem Schnittstellenserverknoten läuft.) Sobald der Kommunikationsmanager diese Nachricht empfängt, etabliert er eine Verbindung mit dem X-Server und präsentiert dem Nutzer ein Login- Fenster. Das Login-Fenster ist eine spezielle Anwendung, welche es für den Nutzer erforderlich macht, einen Nutzernamen und ein Paßwort einzugeben, um Zugang zu dem System zu erhalten. Die Login-Anwendung -wie andere Anwendungsmaschinen- erzeugt Anwendungsservice-Anforderungen an den Kommunikationsmanager um den Nutzer-Login durchzuführen. Nach einem erfolgreichen Login wird dem Nutzer ein Menü geeigneter Anwendungen präsentiert, welche er nun aufrufen kann. Jede Online-Transaktion entspricht einer speziellen Anwendung.
Sobald eine Anwendung aufgerufen ist, empfängt der Kommunikationsmanager einen Anforderung für eine spezifische Anwendung. Im Gegenzug erzeugt der Kommunikationsmanager dann einen Anwendungsmaschinenprozeß, welcher die aufgerufene Anwendung enthält. Die Anwendungsmaschine fordert dann einen offenen Datenbankservice an einem Datenbancknoten an, zeigt das Anwendungsfenster an und wartet auf eine Nutzerantwort. Danach fährt die Anwendungsmaschine fort, nachfolgende Nutzerinteraktions-Ereignisse von Eingabevorrichtungen zu verarbeiten und Anwendungsservice- Anforderungen an den Kommunikationsmanager zu erzeugen. Die Anwendungsmaschine gibt auch die offenen und festgeschriebenen Datenbankservice-Anforderungen heraus.
Somit steht jede Online-Transaktion unter der Kontrolle einer Anwendungsmaschine. Zusätzlich steuert die Anwendungsmaschine, wann die Datenbank geöffnet wird und wann Änderungen festgeschrieben werden. Sie kann eine Datenbank beliebig oft öffnen und ändern. Zwischen einem Öffnen und Festschreiben einer Datenbank erzeugt die Anwendungsmaschine Anwendungsservice-Anforderungen, welche von Anwendungsservern verarbeitet werden.
Wenn der Nutzer mit dem Anwendungsfenster interagiert, fährt der X-Server fort, X-Ereignisse zu erzeugen. Die X- Ereignisse werden über das Netzwerk vom X-Server zur Anwendungsmaschine transportiert. Jedes X-Ereignis, welches von einer Anwendungsmaschine empfangen wird, wird entweder ignoriert oder verarbeitet. Relevante Ereignisse werden verarbeitet, indem C-Sprache-Funktionen aufgerufen werden, welche als Rückfragen bekannt sind. Jedes relevante X-Ereignis ist mit einer Rückfrage verknüpft. Wenn eine Rückfrage den Service eines Anwendungsservers erfordert, sendet die Anwendungsmaschine eine Anwendungsservice-Anforderung an den Kommunikationsmanager. Die Anwendungsmaschine kann sich dann selbst blockieren und auf eine Antwort auf die Anforderung warten.
Jede Anwendungsservice-Anforderung wird von einem Anwendungsservice-Prozeß verarbeitet. Der Kommunikationsmanager legt fest, welcher Anwendungsserver die Anwendungsservice-Anforderungen erfüllen kann. Wenn der entsprechende Anwendungsserver bereits vorhanden ist, leitet der Kommunikationsmanager die Anwendungsservice-Anforderung an den Anwendungsserver weiter. Der Kommunikationsmanager erzeugt einen Anwendungsserver-Prozeß, wenn der Anwendungsserver nicht existiert. Als nächstes verarbeitet der Anwendungsserver die Anwendungsservice-Anforderung und sendet die entsprechende Abschluß/Fehlernachricht an den Kommunikationsmanager, welcher im Gegenzug diese zurück zu der Anwendungsmaschine leitet, welche die ursprüngliche Anforderung machte.
Zu beachten ist, daß der Anwendungsserver, während eine Anwendungsservice-Anforderung verarbeitet wird, die Datensegmente der Fabrikobjekte, welche er benötigt, spezialisiert, die in einem geteilten Cache-Speicher gespeichert sind (geteilt über das Netzwerk). Nachdem das Fabrikobjekt in dem geteilten Speicher spezialisiert worden ist, manipuliert der Anwendungsserver die Datensegmente des Objektes indem er Fabrikobjekt-Verfahren aufruft. Jeder Anwendungsserver macht Datenbankservice- Anforderungen, um Daten zu erhalten, welche er von der Datenbank benötigt, um die Daten zu manipulieren, und, vor Abschluß des Anwendungsservices, eine Datenbankservice-Anforderung zu machen, um die Daten in der Datenbank zu aktualisieren. Wenn ein Anwendungsserver einen Service abschließt, wird eine Datenaktualisierungsservice- Anforderung an den Datenbankserver gesandt. Diese Anforderung enthält alle Fabrikobjekt-Datensegment-Änderungen, welche der Anwendungsserver gemacht hat und die in der relationalen Datenbank dauerhaft gemacht werden müssen.
Der Datenbankknoten betreibt seinen eigenen Kommunikationsmanager in einem Satz von Datenbankservern. Jeder Datenbankserver kann aktiv oder inaktiv sein. Aktive Datenbankserver sind für eine Anwendungsmaschine zweckbestimmt bis eine Festschreibeservice-Anforderung von der Anwendungsmaschine verarbeitet ist. Sobald diese verarbeitet ist, geht der Datenbankserver in einen inaktiven Zustand über. Der Datenbankserver wechselt von inaktiv auf aktiv, wenn er eine offene Datenbankserviceanforderung von einer Anwendungsmaschine über ihren Kommunikationsmanager erhält. Wie erwähnt, kann der Datenbankknoten ein Arbeitsstationscomputer, ein Minicomputer oder ein Cluster aus vielen Computern sein. Die Datenbankserver auf dem Datenbankknoten empfangen Datenbankservice-Anforderungen, welche von den Anwendungsservern auf dem Anwendungsknoten gemacht werden. Diese Serviceanforderungen werden zu einem Datenbankserver durch den Kommunikationsmanager auf dem Datenbankknoten weitergeleitet. Somit aktualisieren die Datenbankserver physikalisch die Datenbank und schreiben die Aktualisierung auf Anforderung der Anwendungsmaschine fest.
Es ist zu beachten, daß jeder Datenbankserver eine Mehrzahl von Datenbankobjekten speichert. Jedes Datenbankobjekt ist nach einer Relation oder einem Blick in die zugrundeliegende relationale Datenbank modelliert. Jedes Fabrikobjekts-Datensegment entspricht einem Datenbankobjekt. Jede Serviceanforderung, welche an den Datenbankserver gerichtet ist, wird aufgeteilt in Aufrufe von Datenbankverfahren in Abhängigkeit davon, welche Fabrikobjekte von einem Anwendungsserver geändert, erzeugt oder zerstört wurden, welcher die Datenbankserviceanforderung machte. In die Datenbankobjekt-Verfahren sind Anweisungen implementiert, welche Relationen in der zugrundeliegenden relationalen Datenbank manipulieren. Alle Änderungen an der Datenbank werden nicht festgeschrieben, bevor nicht die entsprechende Anwendungsmaschine eine Festschreibung anfordert.

Prozeßarchitektur (Objektorientiert)

Zumal die vorliegend erfundene Architektur ihrer Natur nach verteilt ist, wird jeder der vier zuvor beschriebenen Softwareaspekte vorzugsweise als separater Prozeß modelliert. Beispielsweise sind Anwendungsmaschinen Objekte, welcher dem Formaspekt der Software entsprechen, Anwendungsserver modellieren den funktionalen Aspekt, und Kommunikationsmanager und Datenbankserver sind als separate Prozesse modelliert, welche dem Kommunikations- bzw. Datenaspekt des Softwaresystems entsprechen.
Bestimmte Charakteristiken aller dieser vier Prozesse sind weiter abstrahiert in einen Obersatz Prozeß, welcher als "PROZESS" bezeichnet wird. Dieser Obersatz Prozeß ist in Fig. 8 als Objekt 70 dargestellt. Von dort aus können all die anderen Objekte innerhalb des Systems (wie etwa Anwendungsmaschinen, Anwendungsserver, Datenbankserver etc.) effektiv unterklassiert werden, weil sie alle die gemeinsamen Attribute des "PROZESSES" teilen.
Beispielsweise werden in Fig. 8 Objekte 71-74 (korrespondierend zu Ereignishandler (EH), Anwendungsserver (AS), Datenbankserver (DBS) bzw. Anwendungsmaschine (Application Engine, AE)) als unterklassiert von Objekt 70 gezeigt. (Man beachte, daß Anwendungsserver 75 als unterklassiert von Anwendungsserver 72 gezeigt wird.) Die Charakteristiken und das Verhalten, welche im Objekt 70 verkapselt sind, schließen die Fähigkeit ein, einen Prozeß zu erzeugen und auszuführen, zusammen mit der Fähigkeit, Nachrichten über das Ereignishandler-Objekt 71 zu verschicken, und der Fähigkeit, Antworten zu empfangen. In dieser Hinsicht hat der Prozeß 70 die Fähigkeit, ein Ereignis 85 oder jede Unterklasse von Ereignissen 86-89 zu erzeugen, welche alle Unterklassen von Objekt 84 sind.
Man beachte, daß in dem objektorientierten Prozeßdiagramm von Fig. 8 eine Netzwerknachricht als ein Ereignisobjekt modelliert ist, welches von einem Ereignishandler 71 gehandhabt wird. Eine Nutzerschnittstelle in einem Softwaresystem, welche X-Window basiert ist, hat die Fähigkeit, auf Ereignisse zu reagieren, welche von dem X-Server erzeugt werden. Das bedeutet, daß eine Notwendigkeit für eine spezielle Ereignishandhäbungsfähigkeit besteht, welche typisch für Anwendungsmaschinen ist. Aus diesem Grund wird das Eventhandler-Objekt 71 als Unterklasse von Objekt 70 gezeigt, während die Anwendungsmaschine 74 als Unterklasse von Ereignishandler-Objekt 71 gezeigt wird. Von dort aus sind Objekte 76-78 von Objekt 74 unterklassiert, welche Window-basierenden Anwendungsmaschinen (XAE), Strichcode Anwendungsmaschinen (Barcode Application Engines, BAE) und Nicht-Anzeige-Arten von Schnittstellen entsprechen (Eine Nicht-Anzeige-Schnittstelle könnte einfach losgehen, ein File lesen und darauf rea gieren.) X-Anwendungen 79 & 80 und Transaktionen 81-83 werden als weiter unterklassiert von Objekt 76 gezeigt.

Funktionalitätsniveaus

Man erinnere sich, daß die Softwaresysteme, welche von der vorliegenden Architektur unterstützt werden, aus vier Funktionalitätsniveaus bestehen. Die Struktur dieser Funktionalitätsniveaus wird in Fig. 9 gezeigt. Das Nutzer- oder Sitzungsniveau wird durch einen Nutzer-Login gestartet und umfaßt alle anderen Niveaus aus der Nutzerperspektive. Auf der anderen Seite, ist das Transaktionsniveau mit der Ausführung einer spezifischen Aufgabe betraut. Transaktionen können nutzerdefiniert (Skript) oder eingebaute Funktionen sein. Jenseits des Transaktionsniveaus ist das Servicefunktions-Niveau zusammengesetzt aus einzelnen, wohldefinierten und wiederverwendbaren Bausteinen, welche zu Transaktionen zusammengesetzt werden können. Üblicherweise umfassen diese Bausteine Anwendungsservices oder einen Anwendungskript-Server, welcher es dem Nutzer erlaubt, Transaktionen als Skript zu schreiben. Schließlich stellt das Objektniveau das feinste Granularitätsniveau von Funktionalität dar.
Objekte sind Abstraktionen der Fabrikbereichsentitäten und werden aus Daten modelliert, welche in der Datenbank gespeichert sind. In dem Softwaresystem existiert typischerweise eine Objektbibliothek, welche Objekte benutzt, um die Fabrik zu modellieren. Daten werden in der Datenstruktur dieser Objekte gefunden (d. i. die Spezialisierungsvariablen). Diese Objekte enthalten auch den assoziierten ausführbaren Code (d. i. Verfahren), welche aufgerufen werden können, um auf die Strukturen einzuwirken (d. i. Verschicken von Nachrichten). Diese Daten können nur von Nachrichten, welche zu den Objekten gesendet werden, manipuliert werden; das bedeutet, daß auf die Datenbank niemals unmittelbar zugegriffen wird. Eine Teilliste von Fabrikobjekten, welche in das gegenwärtig bevorzugte Ausführungsbeispiel eingeschlossen ist, ist in Tabelle 1 angegeben: Objektklassen - Tabelle 1
Eine Anwendung zu bauen ist ein Prozeß des Sendens geeigneter Nachrichten. Diese Objekte werden geschrieben, um das äußerste Basisniveau an Funktionalität in dem System zur Verfügung zu stellen. Offensichtlich ist der primäre Vorteil von Objekten ihre Wiederverwendbarkeit. Kombinationen von Objekten und Nachrichten an die Objekte erlauben es, allgemeinere Funktionalität zu konstruieren. Diese Funktionalität ist eingekapselt entsprechend der vorliegenden Erfindung in der Objektbibliothek und den Anwendungsserver-Niveuas. Obwohl die Objekte die Basis der festcodierten Anwendungsservices-Funktionen formen, können sie auch unmittelbar über Skript benachrichtigt werden.
Obwohl die vorliegende Erfindung in Verbindung mit einer Anwendung in einem Fabrikbereichsverwaltungs- Softwaresystem beschrieben wurde, erfordert es Wiederholung, daß die vorliegende Erfindung in eine große Vielzahl von Anwendungen und Systemen implementiert werden kann. Daher ist zu verstehen, daß die speziellen Ausführungsbeispiele, welche zur Illustration gezeigt und beschrieben wurden, auf keine Weise zur Limitierung gedacht sind. Bezugnahme auf Details der bevorzugten Ausführungsform sollen nicht den Bereich der Ansprüche limitieren.
Somit wurde eine objektorientierte Architektur zur Benutzung in einem komplexen Softwaresystem beschrieben.

Claims

1. Online-objektorientiertes-verteiltes Computersystem zum Verwalten eines Fabrikbereiches, wobei das verteilte Computersystem aufweist:

eine Mehrzahl vernetzter Computerknoten (28-34), wobei jeder vernetzte Computerknoten einen Prozessor, einen Speicher und einen Kommunikationsmechanismus aufweist, und die vernetzten Computerknoten gesonderte Schnittstellen-Serviceknoten, Anwendungsknoten und Datenbankknoten umfassen:

wobei eine relationale Datenbank auf den Datenbankknoten gespeichert ist und über diese verteilt wird und die relationale Datenbank Fabrikentitäten darstellende Fabrikobjekte enthält, und die Fabrikobjekte in der relationalen Datenbank Arbeitsorte, Inventar, physische Ressourcen einschließlich Maschinen- und Arbeitsressourcen, und logische Ressourcen darstellen;

wobei jeder der Schnittstellen-Serviceknoten einen Schnittstellen-Server betreibt, um eine Schnittstelle bereitzustellen, die es einem Benutzer erlaubt Online-Transaktionen mittels einer Dialogvorrichtung durchzuführen, wobei die Online- Transaktionen auf die Fabrikobjekte einwirken;

wobei jeder Anwendungsknoten der Anwendungsknoten einen Kommunikationsmanager betreibt, um eine Kommunikation zwischen dem Schnittstellen-Server, den Anwendungsknoten und den Datenbankknoten zu koordinieren,

wobei jeder Anwendungsknoten wenigstens eine betreibt von:

einer Anwendungsmaschine (52) zum Kontrollieren der Online-Transaktionen durch den Benutzer, wobei die Anwendungsmaschine Anwendungsservice- Anforderungen in Reaktion auf die Online- Transaktionen durch den Benutzer erzeugt, und

einem Anwendungsserver zum Verarbeiten der Anwendung-Serviceabfragen durch Spezialisieren und Manipulieren von Datensegmenten der Fabrikobjekte, wobei der Anwendungsserver Datenbank-Serviceabfragen ausgibt, um Daten in der relationalen Datenbank abzufragen, zu manipulieren und zu aktualisieren; und

wobei die Anwendungsknoten wenigstens einen Anwendungsknoten umfassen, der eine Anwendungsmaschine betreibt und wenigstens einen Anwendungsknoten, der einen Anwendungsserver betreibt; und

wobei die Datenbankknoten einen Datenbankserver betreiben, um die relationale Datenbank in Reaktion auf die Datenbank-Serviceabfragen, die durch den Anwendungsserver an den Anwendungsknoten erzeugt werden, physikalisch zu aktualisieren, wobei das Aktualisieren der Datenbank mittels Transaktionen durchgeführt wird, und die Fabrikobjekte in Reaktion auf die Transaktionen modifiziert werden.

2. System nach Anspruch 1, bei welchem die Dialogvorrichtung ein X-Terminal oder eine Arbeitsstation (50) aufweist, die einen X-Server (51) betreiben.

3. System nach Anspruch 2, bei welchem die Dialogvorrichtung ferner eine Strichcodevorrichtung (57) aufweist, die mit einem Strichcodeserver (58) gekoppelt ist.

4. System nach Anspruch 1, bei welchem der Anwendungsserver auch Aktualisierungsdaten-Serviceabfragen an den Datenbankserver sendet, und die Aktualisierungsdaten-Serviceabfragen alle Veränderungen an den Datensegmenten beinhalten, die durch den Anwendungsserver durchgeführt werden, damit diese in der Datenbank dauerhaft sind.

5. System nach Anspruch 4, bei welchem jedes der Datensegmente, das den Fabrikobjekten zugeordnet ist, einem Datenbankobjekt entspricht.

6. System nach Anspruch 5, bei welchem der Datenbankserver eine Mehrzahl von Datenbankobjekten speichert, und jedes der Datenbankobjekte gemäß einer Relation in der relationalen Datenbank modelliert wird, und wobei die Datenbank-Serviceabfragen in Aufrufe von Datenbankoperationen zerlegt werden, abhängig davon, welche der Fabrikobjekte durch den Anwendungsserver verändert, erzeugt oder gelöscht wurden.

7. System nach Anspruch 1, bei welchem der Kommunikationsmanager die Anwendungsservice-Anforderungen zum Anwendungsserver leitet, und eine geeignete Vollendungs-/Fehler-Meldung zur Anwendungsmaschine vom Anwendungsserver sendet.

8. System nach Anspruch 7, bei welchem die Anwendungsmaschine (52) kontrolliert, wann die Datenbank geöffnet ist und wann Veränderungen in der Datenbank festgeschrieben werden, und die Anwendungsmaschine zwischen einem Öffnen und Festschreiben der Datenbank die Anwendungsservice-Anforderung zur Verarbeitung durch den Anwendungsserver herausgibt.

9. System nach Anspruch 1, bei welchem die Datenbank- Serviceabfrage durch den Kommunikationsmanager auf den Datenbankknoten zum Datenbankserver weitergeleitet wird.

10. Computersystem nach Anspruch 1, bei welchem der Kommunikationsmechanismus eine Mehrzahl von Anwendungsservern erzeugt, die auf die Anwendungsservice- Anforderung ansprechen, und die Mehrzahl von Anwendungsservern den Anwendungsserver umfaßt.

11. Computersystem nach Anspruch 10, bei welchem die Mehrzahl von Anwendungsservern einen Fernobjekt- Serverprozeß aufweist, der zum Abwickeln der Anwendungsservice-Anforderung für Operationen an nicht dauerhaften Objekten dient.

12. Computersystem nach Anspruch 11, bei welchem jeder Anwendungsknoten der Mehrzahl von Anwendungsknoten einen einzelnen Fernobjekt-Serverprozeß betreibt, um mit anderen Knoten der Mehrzahl von vernetzten Computerknoten zu kommunizieren.