DE69530947T2

DE69530947T2 - Netzwerkeinrichtung für ein System zur Herstellung von Glasgegenständen

Info

Publication number: DE69530947T2
Application number: DE69530947T
Authority: DE
Inventors: David K. Hwang
Original assignee: Emhart Glass SA
Current assignee: Emhart Glass SA
Priority date: 1994-02-15
Filing date: 1995-02-14
Publication date: 2003-12-24
Anticipated expiration: 2015-02-15
Also published as: EP0667693A2; EP0667693B1; EP0667693A3; JPH07267653A; DE69530947D1; US5475601A

Description

Eine Fabrik zur Herstellung von Glasartikeln umfasst eine Anzahl von computergesteuerten Maschinen, die zusammen den Formungsprozess des Glasartikels definieren. Diese Maschinen können z. B. eine I.S.-Maschine umfassen, wie sie in der US-A-4,641,269 offenbart ist, und die eine Anzahl von Abschnitten umfasst, von denen jeder von einer unabhängigen Steuerung gesteuert wird. Archivdaten für diese Steuerungen werden zentral von einer Steuerraumkonsole verwaltet. Geformte Flaschen werden von einer Prüfeinrichtung geprüft, die eine oder mehrere diskrete Maschinen umfassen kann, von denen jede ihre unabhängige Steuerung aufweist.
Solche I.S.-Maschinen und Prüfeinrichtungen, wie sie von der vorliegenden Anmelderin vertrieben werden, werden auf einer Nichtstandard-QNX- Plattform (ein Multi-Tasking-, Mehrbenutzer- und Echtzeit-Betriebssystem für Mikrocomputersysteme, das von der Quantum Software Systems, Ltd. vertrieben wird) betrieben. Auf eine solche Nichtstandardplattform haben externe Computer keinen Zugriff, die auf Standardplattformen wie etwa UNIX, VAX/VMS und Novell's Netware in der Standard-Ethernet TCP/IP- (Transmission Control Protocol/Internet Protocol) Netzwerkumgebung betrieben werden, und dementsprechend können solche Arbeitsstationen in der Glasartikelfabrik nicht die Datenbanken dieser I.S.-Maschinen oder der Prüfeinrichtungen verwenden.
Die Erfindung zielt auf ein System eines Typs, wie er in der EP-A-0 381 365 offenbart ist, umfassend mindestens eine ereignisorientierte Datenbank, die mit einem Protokoll arbeitet, sowie mindestens eine Arbeitsstation, die mit einem zweiten Protokoll betrieben wird, umfassend eine Bibliothek von API- (Applications Programming Interface) Aufrufen in diesem einen Protokoll, eine Socket- Bibliothek zum Senden der Aufrufpakete im zweiten Protokoll und eine Gateway-Bibliothek zum Übersetzen eines API-Aufrufs im einen Protokoll, um ein Paket im zweiten Protokoll aufzurufen. Das System umfasst weiterhin ein Netzwerk-Gateway, umfassend eine Socket-Bibliothek zum Empfangen von Aufrufpaketen im zweiten Protokoll sowie einen Gateway-Service zum Übersetzen eines Aufrufpaketes, das von der ersten Netzwerk-Gateway-Socket- Bibliothek im zweiten Protokoll empfangen wurde, in einen API-Aufruf im ersten Protokoll und zum Übermitteln des Übersetzungsaufrufs an die ereignisorientierte Datenbank.
Insbesondere umfasst das in der obigen EP-A offenbarte System nach dem Oberbegriff in Anspruch 1:
ein Netzwerk-Gateway, das auf einer ersten Plattform betrieben wird, und eine Arbeitsstation, die auf einer zweiten Plattform betrieben wird,
wobei das Netzwerk-Gateway eine erste BSD- (Berkeley Socket Distribution) Socket-Bibliothek umfasst und
wobei die Arbeitsstation eine Applikation zum Erstellen und Empfangen von API- (Application Programming Interface) Aufrufen umfasst sowie eine zweite BSD- (Berkeley Socket Distribution) Socket-Bibliothek und
wobei die ersten und zweiten BSD-Socket-Bibliotheken dahingehend angepasst sind, dass sie bidirektional über TCP/IP- (Transmission Control Protocol/Internet Protocol) Pakete kommunizieren.
Nach der vorliegenden Erfindung, wie sie im kennzeichnenden Teil von Anspruch 1 definiert ist,
umfasst die Arbeitsstation weiterhin
eine ereignisorientierte Datenbankbibliothek sowie
eine Gateway-Bibliothek,
wobei die ereignisorientierte Datenbankbibliothek dahingehend angepasst ist, dass sie bidirektional die Applikation und die Gateway-Bibliothek miteinander verbindet, und
wobei die Gateway-Bibliothek dahingehend angepasst ist, dass sie bidirektional die ereignisorientierte Datenbankbibliothek und die zweite BSD- Socket-Bibliothek miteinander verbindet,
wobei das Netzwerk-Gateway weiterhin
eine ereignisorientierte Datenbank umfasst sowie
einen Gateway-Service, der dahingehend angepasst ist, dass er bidirektional die erste BSD-Socket-Bibliothek und die ereignisorientierte Datenbank miteinander verbindet.
Es wird nun auf die beigefügten Zeichnungen Bezug genommen, die eine derzeit bevorzugte Ausführungsform darstellen, die die Prinzipien der Erfindung verwendet.
Fig. 1 ist ein Blockdiagramm und zeigt die Maschinenarchitektur, wobei die Beziehung zwischen dem Netzwerk-Gateway, den lokalen Computern und der externen Applikationsumgebung gezeigt wird;
Fig. 2 ist ein Blockdiagramm und zeigt ein rein ereignisorientiertes Datenbank-API-Design in der QNX-Umgebung;
Fig. 3 ist ein Blockdiagramm und zeigt das verteilte Software-Design des Netzwerk-Gateways;
Fig. 4 ist ein Top-Level-Context-Datenflussdiagramm und zeigt die Netzwerk-Gateway-Software insgesamt, wie sie die Verbindung zwischen den Produktionslinienkonsolen und den Hosts unterstützt;
Fig. 5 ist ein weiteres Level-Datenflussdiagramm für das Netzwerk- Gateway;
Fig. 6 ist ein Datenflussdiagramm und zeigt den Datenfluss zwischen den verschiedenen Modulen der in Fig. 5 gezeigten Gateway-Bibliothek;
Fig. 7 ist ein Datenflussdiagramm und zeigt die Kommunikation zwischen den Tasks und die Datenschnittstellen zwischen dem in Fig. 5 gezeigten Gateway-Service und seinen Ressourcen;
Fig. 8 ist ein Strukturdiagramm und zeigt die Hauptprogrammstruktur für den Gateway-Service;
Fig. 9 ist ein Strukturdiagramm und zeigt die Kommunikationsstruktur für die Tasks auf dem Gateway;
Fig. 10 ist ein Strukturdiagramm und zeigt die Datenstruktur für die Tasks auf dem Gateway; und
Fig. 11 ist ein Strukturdiagramm und zeigt die rushstruktur für die Tasks auf dem Gateway.
Unter Bezugnahme auf Fig. 1 hat eine I.S.-Maschine zum Formen von Glasartikeln eine Anzahl von Produktionslinienkonsolen - jede Konsole umfasst eine ereignisorientierte Datenbank, die alle Überwachungsfunktionen für diese I.S.- Maschine unterstützt. Archivdaten für alle diese ereignisorientierten Datenbanken mehrer Maschinen werden zentral von einer Datenbank auf der Festplatte einer Steuerraumkonsole verwaltet. Weiterhin sind im QNX-Netzwerk die Kaltzustands-Produktionskonsolen verfügbar, auf denen die Prüfverbindungssoftware läuft, die auf die Prüfausrüsttungsdatenbank via ARCnet zugreift. Es ist das Ziel dieser Erfindung, es einer Benutzerapplikation zu ermöglichen, auf diese QNX-basierten Datenbanken von Arbeitsstationen aus, die entweder unter UNIX, VAX/VMS oder Novell's Netware in der Standard-Ethernet-TCP/IP- Netzwerkumgebung laufen, über das Netzwerk-Gateway zuzugreifen.
Das Netzwerk-Gateway ist ein IBM-PC-kompatibler Computer; der aus den folgenden Hardware- und Software-Komponenten besteht: 486/33 MHz IBM- PC mit 8 MB Speicher (keine Festplatte); QNX-Betriebssystem V2.15F oder später; QNXnet-Board; Fastech's TCP/IP Connectivity für QNX-Treiber, umfassend die Berkeley-Socket-Bibliothek und die CMC-640 Ethernet Interface-Kärte; sowie Gateway Server Software für den Zugriff auf die Datenbanken.
Dadurch wird es der Arbeitsstation ermöglicht, über das Ethernet die erforderlichen Datenbankinformationen im QNX-Netzwerk einzuholen. Der Gateway- Verkehr verläuft jedoch in zwei Richtungen, das bedeutet, dass auch das Netzwerk-Gateway veranlassen kann, dass der Datentransfer die Arbeitsstation erreicht. Bei der Implementierung sind die eingeleiteten Ereignisse begrenzt auf Änderungen in Datenbankeinträgen, die von der Arbeitsstation definiert und angefordert werden.
Die Netzwerk-Gateway-Software unterstützt mehrere Benutzer-"Ports", die in mehreren Prozessen innerhalb einer einzigen Arbeitsstation oder in einem einzigen oder mehreren Prozessen zwischen mehreren Arbeitsstationen der Benutzer angesiedelt sein können. Die Netzwerk-Gateway-Software selbst karin auch in einer einzigen CPU oder mehreren PC's, jeweils mit einem anderen Namen, angesiedelt sein.
Die Konsole für die Kaltzustands-Produktionslinie ("Production Line (onsole" - PLC) ist ein weiterer IBM-PC-kompatibler Computer, der sowohl Schnittstellen zum ARCnet als auch zum QNX-Netwerk hat. Die ARCnet-Schnittstelle nimmt die Daten der gesamten Prüfausrüstung auf, während das QNXnet die Kaltzustands-PLC zu einem Knoten im QNX-Netzwerk macht. Die Prüfverbindungs-Software läuft unter QNX auf der Kaltzustands-PLC.
Eine alternative Systemarchitektur besteht darin, die, Kaltzustands-PLC und die Netzwerk-Gateway-Hardware in einem PC-Gehäuse zu kombinieren, indem einfach die ARCnet-Karte in den Gateway-PC gesteckt wird und die Prüfverbindungs- und Gateway-Service-Software auf demselben PC läuft. Bis zu einer gewissen Grenze führt dieser Ansatz zu Vorteilen sowohl im Hinblick auf verringerte Kosten als auch gesteigerte Leistung. Werden dem System mehr als eine Kaltzustandsprüfmaschine hinzugefügt, führt die reguläre Konfiguration mit einem getrennten PC, auf dem die Prüfverbindung läuft, zu einer besseren Benutzerflexibilität beim Hinzufügen weiterer PC's, um den gesteigerten Anforderungen Rechnung zu tragen.
Die Gateway-Software ist in Client- (Arbeitsstation) und Server- (Gateway) Teile partitioniert. Die Client-Software umfasst einen Satz von API- Bibliotheksdateien im "C"-Quell-Code-Format, sodass der Benutzer sie kompilieren und mit seinem Applikations-Code und der TCP/IP-Socket-Bibliothek verbinden kann. Auf dem Gateway läuft unter QNX die Server-Software, die die Datenanfragen (vom Benutzer an die Datenbanken) sowie die Datenbankenänderungsereignisse (der Datenbank an die Benutzerapplikation) verwaltet. Die Server-Software unterstützt mehrere Client-Verbindungen wie auch mehrere Sessions.
Für Entwickler von QNX-Applikationen hat die Anmelderin der vorliegenden Erfindung einen Tool-Kit für die ereignisorientierten Datenbanken ("Event Driven database" - EDDB) veröffentlicht, der Standard- (native) EDDB- Bibliotheken-API's für EDDB-Datenbankzugang in einer QNX-Umgebung (Fig. 2) enthält. In der QNX-Umgebung kann die Applikations-Task EDDB-API- Aufrufe aus der lokalen EDDB-Bibliothek ausgeben, um eine lokale oder entfernte EDDB-Datenbank zu öffnen und danach Daten aus ihr zu entnehmen. In dieser netzwerkintrinsischen Umgebung muss der Benutzer nicht den Ort der Datenbank kennen. Die geografischen Orte der EDDB-Datenbanken werden transparent von der QNX-Netzwerkteinrichtung aufgelöst.
Das Gateway-Design erstreckt die EDDB/IC- ("Inspection Connection") Bibliotheken-API's über das Netzwerk, um es Entwicklern zu ermöglichen, Benutzerapplikationsprogramme unter UNIX, VAX/VMS/Novell-Arbeitsstationen zu entwickeln, wobei dieselbe EDDB/IC-Programmierschnittstelle verwendet wird. Um dieses Ziel zu erreichen, muss die EDDB/IC-Bibliothek auf dem Knoten des Benutzers verbessert werden, indem auf tiefere Ebene eine Software hinzugefügt wird, die den Pakettransfer zwischen Benutzer und Gateway unterstützt. Ein entsprechender Satz von Software muss auch auf dem Gateway- Knoten vorhanden sein, um diese Anfrage zu bearbeiten. Fig. 3 zeigt das verteilte Software-Design dieses Ansatzes doppelt. Ein Teil der Software - die Gateway-Bibliothek - befindet sich auf der Benutzerplattform, während der andere Teil - der Gateway-Service - auf dem Gateway angesiedelt ist, wobei beide die Berkeley Sockets Library (BSD 4.3) verwenden, um ein Low-Level-TCP- Socket-Setup sowie Session-Verbindungs- und Pakettransfer-Tasks auszuführen.
Indem EDDB/IC-Aufrufe gemacht werden, kann das UNIX/VMS/Novell- Applikationsprogramm nun auf die entfernten Datenbanken zugreifen, als ob sie lokal verfügbar wären. Die Benutzerapplikationen machen EDDB/-IC-API- Aufrufe, die Gateway-Bibliothek konvertiert jedoch die "name locate"-, "send"- und "vc release"- Systemaufrufe, die der QNX-Umgebung eigen sind, in TCP/IP-Befehlspakete und schickt die Pakete zum Gateway. Der unter QNX laufende Gateway-Service liefert dann die realen "name locate"-, "send"- und "vc release"-Aufrufe für den Zugang zur EDDB-Datenbankeninformation und sendet die Daten und den Status zurück an das Benutzerapplikationsprogramm über dasselbe Paar von Netzwerk-Sockets. Für den Entwickler ist der gesamte Pakettransfermechanismus transparent, das heißt es erscheint so, als ob die Daten für ihn lokal auf seiner Maschine verfügbar wären. Die Gateway-Bibliothek ist in ANSI "C" geschrieben und erfordert eine minimale Portierarbeit, um sie für das Zielsystem des Entwicklers verfügbar zu machen. Es sind keine Änderungen am Gateway-Service nötig, der nur in ausführbarer Form verfügbar ist und dauerhaft im Gateway-Speicher läuft, solange der Gateway-PC läuft. Vom Blickpunkt der Software aus ist der Gateway eine Nichtstandard-TCP/IP- Protokollapplikation in einer verteilten Umgebung.
Im Gateway-Design ist der Benutzer die Applikation eines Dritten, die die Anfrage zur Kommunikation stellt und auf eine Erwiderung vom Server wartet. Der Benutzer "lebt" in einer Benutzermaschine. Im Vergleich dazu ist ein Server (immer) im Gateway angesiedelt und wartet auf eingehende Kommunikationsanfragen von einem Benutzer. Erhält er eine solche Benutzeranfrage, führt der Server den notwendigen Datenbankzugang aus und gibt das Resultat an den Client zurück. Im Wesentlichen "lebt" der Server also im Gateway und agiert wie eine universelle Datenbank-Engine.
Der Gateway liefert dynamische ereignisorientierte Daten-Updates von einer Datenbank an den Benutzer, solange die Daten von der Benutzerapplikation verwendet werden. Das Benutzerprogramm wird dementsprechend nur dann vom Server (der zuerst von der EDDB/IC-Datenbank informiert wurde) informiert, wenn eine reale Änderung am ausgewählten Datensatz stattgefunden hatte. Diese zusätzliche Anforderung macht ein Paar von zugeordneten Sockets am Gateway- und Benutzerknoten erforderlich, die miteinander kommunizieren (und den Gateway mit dem Benutzer verbinden). Dabei wird das TCP- Transportprotokoll verwendet.
Der Gateway liefert einen Service, der mehrere Benutzerknoten mit den EDDB- Datenbanken verbindet. Jede Verbindung hat ihren eigenen bestimmten Socket, der dem Benutzer während der Session zugeordnet ist. Eine Session ist definiert als eine vom Benutzer hergestellte Verbindung mit dem Gateway zur Informationsanforderung. Ist eine Session vorüber, wird der Socket für das System zur zukünftigen Verwendung freigegeben. Die Anzahl an verfügbaren Sockets ist nur dadurch begrenzt, was der TCP/QNX-Treiber liefern kann.
Das Top-Level-Context-Diagramm, das in Fig. 4 gezeigt ist, zeigt die Gateway- Software insgesamt, wie sie die Verbindung zwischen den Produktionslinienkonsolen (PLC's) und den UNIX/VMX/Novell-Arbeitsstationen der Benutzer unterstützt. Die Benutzerapplikation stellt die EDDB/IC-API-Anfragen, um die EDDB/IC-Datenbank zu orten und auszulesen. Die Funktionsaufrufe geben die Datenbankangaben und den Inhalt an die Benutzerapplikation zurück. Der Gateway unterstützt auch EDDB/IC-Exceptions, die von den PLC's oder der Prüfverbindung als Signale an die Benutzer-Task zum asynchronen Ereignis- Update herrühren. Zum Beispiel könnten diese äußeren Ereignisse Pakete mit Ereigniswinkeländerung oder den Prüfresultaten sein. Es herrschen daher zwei Hauptdatenströme im Gateway-Design: (1) Die Datenakquise von UNIX/VMS/Novell-Arbeitsstationen an die PLC's und (2) die zweiten Ereignis- Updates von den PLC's zurück zu den UNIX/VMS/Novell-Arbeitsstationen. Der Gateway verarbeitet die gesamten Details zur Session-Verbindung und die Datenpakettransfers zwischen zwei unterschiedlichen Betriebssystemen (UNIX/VMS/Novell und QNX) und den Netzwerkumgebungen (TCP/IP bei Ethernet und QNXnet bei ARCnet).
Das Gateway-Design ist in zwei Teilen implementiert, wie in Fig. 5 gezeigt. Die Gateway-Bibliothek (Benutzerapplikationsbibliothek) ist der Teil, der auf dem Client-Knoten "lebt". Er bildet die Schnittstelle zu den Benutzeranwendungen und konvertiert mit dem Gateway-Service (Server-Applikations-Software) im Gateway über TCP-Pakete im Ehternet-Netzwerk. Der Gateway-Service besteht aus einem Satz von Benutzerapplikations-Tasks, um eine EDDB- Datenbank in der QNX-Umgebung zu lokalisieren und auf sie zuzugreifen. Die Server-Applikation gibt die Resultate zurück an die Client-Applikation über TCP-Pakete. Die Resultate können entweder auf einer Datenbankabfrage oder einer EDDB-Exception beruhen.
Die Gateway-Bibliothek ist die Software-Schicht, die der Programmierer der Benutzerapplikation einbindet, um auf die Datenbank zuzugreifen. Fig. 6 zeigt den Datenfluss zwischen verschiedenen Modulen der Gateway-Bibliothek, wie sie von der Applikation verwendet werden.
Die Funktionen für die Benutzerschnittstelle sind in den folgenden Modulen enthalten: Name Locate, Send und PrepareForEvents. Das Client Call Modul bearbeitet den TCP-Pakettransfer, indem "send"- und "recv"-Aufrufe in der Berkeley-Socket-Library gemacht werden. Die PrepareForEvents-Funktion initialisiert den Socket zum Datentransfer am Benutzerknoten und richtet den Mechanismus zum Umgang mit dem Benutzerereignissignal ein, indem ein separater Ereigniswarteschlangen-Socket aufgebaut wird. Nachdem der Client die Verbindung mit dem Gateway-Service hergestellt hat, versucht der Gateway-Service, neben der Erfüllung anderer Aufgaben, seinen eigenen Ereigniswarteschlangen-Socket zu erstellen und eine Verbindung mit dem Ereigniswarteschlangen-Socket des Benutzers herzustellen. Ist diese Verbindung hergestellt, wird jede Änderung an den Datensätzen in der EDDB/IC über den Ereigniswarteschlangen-Socket an den Benutzer zurück gesendet. Die Nachricht erfolgt lokal und wird vom Client zum Gateway-Server gesendet, wo die Pakete entpackt und decodiert werden, bevor die QNX-"send"-Nachricht gegeben wird. Die empfangenen Pakete werden dann in den Task-Speicherraum der Client-Applikation in der EDDB/CI-Bibliothek zurückgesendet und schließlich an die Client-Applikation übergeben.
Fig. 7 zeigt die Kommunikation zwischen Tasks innerhalb des Gateway-Service sowie die Datenschnittstellen zwischen dem Gateway-Service und seinen externen Ressourcen. Der Gateway-Server arbeitet als ein universeller sessionorienfierter Datenbank-Server, und sein Design besteht aus den folgenden koordinierenden Tasks:
- Das Hauptprogramm der "server"-Task beginnt die Ausführung, wenn es aktiviert wird, und läuft die ganze Zeit. Es liefert einen Protokoll-Port, registriert das Programm mit dem Port-Mapper und wartet (lauscht) dann auf den Empfang einer Benutzeranfrage, die in der Form von TCP/IP-Paketen vom Daten-Socket hereinkommt. Aufgrund der Tatsache, dass mehrere Clients auf bis zu sechzehn (16) PLC's zur gleichen Zeit zugreifen können, muss das Hauptprogramm weitere eingehende Verbindungen erwarten, während die Daten im Kanal gleichzeitig von Subprozessen abgearbeitet werden. Der Satz von generierten Subprozessen umfasst "coms" und "data". Einer pro Session-Verbindung. Diese Tasks kommunizieren miteinander über lokale QNX-Namenregistrierungen.
- Die Kommunikations-Task, "coms", hängt sich den lokalen QNX- Clearinghouse-Namen an. Dann verbleibt sie in der Endlosschleife, um alle eingehenden Datenpakete im Blockiermodus zu empfangen. Nach dem Empfang eines Paketes checkt "coms" zunächst den Operationscode, um festzustellen, ob es sich um ein Port-Nummerpaket handelt. Das Port- Nummerpaket wird vom Client zu Beginn des Prozesses, in dem die Session aufgenommen wird, gesendet, um den Gateway-Service darüber zu informieren, an welchen Port die Datenbank-Exception-Ereignisse gesendet werden sollen. Das Port-Nummerpaket führt dazu, dass "coms" die "rush"- Task zum Verbinden mit dem Client am Ereigniswarteschlangen-Socket erzeugt. Andere unterstützte Operationscodes sind: name locate, send oder vc release. Der Unterschied zwischen diesen QNX-Operationen besteht in der Größe des Antwortpaketes. Die Task "coms" sendet dann das Paket an die Task "data" über den QNX-Nachrichtentransfer. Da der QNX-Sendeaufruf auch eine Nachricht zurückempfängt, sobald der Sendeaufruf zurückkehrt, sendet das Programm das Antwort-TCP-Paket über das TCP/IP-Netzwerk zurück zum Client.
- Die Datenbank-Link-Task, "data", beginnt, indem sie sich den Clearinghouse lokal unter dem Namen anhängt. Dann bleibt sie dauerhaft in der Empfangssperrschleife, bis:
-- die "coms"-Task ihr eine Nachricht sendet, nachdem das Datenpaket von der Client-Applikation empfangen wurde, oder
-- die EDDB-IC-Exception anzeigt, dass sich die Datenbankeinträge geändert haben.
Wenn die Task aufwacht, weil "coms" eine Nachricht gesendet hat, decodiert sie zunächst den Operationscode (name locate, send oder vc release) und führt dann dementsprechend die QNX-Operation aus. Die Task antwortet dann der Sende-Task "coms" mit den Resultaten.
Empfängt die Task ein EDDB/IC-Datenbank-Exception-Signal, sendet sie sofort eine QNX-Nachricht an die Task "rush", um die Ereignisquelle zu benachrichtigen.
- Die Ereignisbenachrichtigungs-Task "rush" wird von der "coms"-Task erzeugt und hängt sich zunächst lokal den Clearinghouse an. Dann startet sie den Exception-Ereigniswarteschlangen-Socket auf dem Server zur Ereignisbenachrichtigung. Bei der Ereignisbenachrichtigung agiert der Server tatsächlich wie ein Client, sodass der erzeugte Server einen Verbindungsaufruf () machen muss, um die Verbindung mit dem Ereigniswarteschlangen- Socket auf dem Client-Knoten herzustellen. Dann fällt die Task in eine Endlosschleife, um von der Task "data" auf alle Exception-Ereignisse zu waren. Beim Empfang der Exceptions führt sie sofort zwei Dinge aus:
1. Senden einer Antwortnachricht zurück an die Task "data", nur um sie zu entsperren.
2. Senden eines Ereignisbenachrichtigungspakets über den Ereigniswarteschlangen-Socket an den Client-Knoten zur Verarbeitung.
Fig. 8 zeigt das Programmstrukturdiagramm für das Hauptprogramm, das zunächst den Socket in den "listening-mode" für eine Client- Verbindungsanfrage versetzt. Gerät die Task einmal in die Endlosschleife, um mehrere Verbindungen anzunehmen (), führt jede Verbindung, die hereinkommt, zu einer anderen Socket-ID und Subtask-Extension-Nummer. Diese beiden Parameter werden dann zum Erzeugen eines Satzes von Subtasks, "coms" und "data", verwendet, um eine bestimmte Session zu bedienen. Da am Gateway mehrere Sessions geöffnet werden können, könnten in der Task- Tabelle zur gleichen Zeit mehrere Kopien von "coms" oder "data" existieren.
Task-to-Task-Kommunikationen müssen daher entsprechend dem Task- Registriernamen und nicht dem Task-Namen bearbeitet werden.
Fig. 9 zeigt das Programmstrukturdiagramm für die Task "coms", die als separate Task gestaltet ist, um Pakete vom Client und Antworten über denselben offenen Kanal zu verarbeiten. Der Register-Task-Namen-Abschnitt besteht aus einem QNX-Systemaufruf "name attach", um sich den lokalen Clearinghouse anzuhängen, sodass mit der "data"-Task kommuniziert werden kann. Während des Vorbereitungsstadiums würde "coms" ebenfalls versuchen, den entsprechenden "data"-Tasknamen durch Aufrufen von "name locate" zu orten. Sowohl die Tasknamen-Registrierung als auch die Lokalisierung verwenden dieselben Kommandozeilenparameter, die aus Socket-ID und Subtask- Nummer bestehen.
Die empfangenen Pakete sollen dauerhaft fortlaufen, bis die Socket- Verbindung zum Beispiel durch das Beenden der Client-Applikation unterbrochen wird, in diesem Fall muss die "coms"-Task eine Nachricht an die "data"- Task senden, damit sie beendet wird, bevor die Task selber stirbt. Diese Maßnahme dient dazu, um "Zombie"-Prozesse im System zu vermeiden, wenn eine Session beendet worden ist.
Nach dem Empfang eines Paketes decodiert die Task "coms" zunächst den Operationscode, um zu entscheiden, ob es sich dabei um "name locate", "send" oder "vc-receive" handelt. Die Sende-Nachricht und die Antwortpaketgrößen sind unterschiedlich und müssen dementsprechend spezifiziert werden. Das Programm leitet dann die Nachricht an die "data"-Task zur Verarbeitung weiter, erhält das Resultat zurück und gibt es über das Netzwerk an die Client- Applikation zurück.
Fig. 10 zeigt das Programmstrukturdiagramm Eür die Task "data" zum Verarbeiten entweder der Nachrichten von der "coms"-Task oder der Datenbank (EDDB oder C1) Exceptions. Nach der Task-Registrierung und Ereignisvorbereitung (zum Erzeugen des Exception-Handlers) wird die Get-Events-Routine empfangsblockiert, bis entweder ein Datenbankereignis von den angehängten Datenbankeinträgen hereinkommt oder bis es eine Nachricht von der Task "coms" erhält.
Um das Datenbankereignis zu verarbeiten, versucht "data", die Task "rush" vom Namen her zu lokalisieren und sendet ihr die Exception. Zum Verarbeiten kam die Nachricht möglicherweise von "coms" herein. "data" decodiert zunächst die Befehlsnachricht und führt dann dementsprechend den QNX-Aufruf aus. Das Ergebnis dieser Operation wird an "coms" zurückgesendet als Antwortnachricht, um es zu entsperren.
Sobald "coms" die Antwortnachricht erhält, generiert es ein Paket, das an die Client-Applikation zurückgesendet wird. Im Falle der Task "rush" (Fig. 11) besteht seine Funktion darin, auf den Empfang von Exception-Nachrichten von "data" zu warten, jede Nachricht an die Client-Applikation über den Ereigniswarteschlangen-Socket weiterzuleiten und "data" zu antworten, um den Sender zu entsperren.

BESCHRIFUNG DER ZEICHNUNGEN

Fig. 1
UNIX Workstation UNIX-Arbeitsstation
VAX/VMS Workstation VAX/VMS-Arbeitsstation
Novell NetWare Client PC Novell NetWare-Client-PC
Ethernet (TCP/IP) Ethernet (TCP/IP)
NETWORK GATEWAY Netzwerk-Gateway
QNXnet QNXnet
Control Room Console (CRC) Steuerraumkonsole (CRC)
Hot-end Production Line Console (PLC) Heisszustandsproduktionslinenkonsole
Cold-end Production Line Console (PLC) Kaltzustandsproduktionslinienkonsole
ARCNet ARCNet
I.S.MACHINE I.S.-MASCHINE
INSPECTION MACHINE PRÜFMASCHINE
Fig. 2
QNX Environment QNX-Umgebung
Applications Applikationen
Database API Calls Datenbank-API-Aufrufe
EDDB/IC Library EDDB/IC-Bibliothek
EDDB/IC Databases EDDB/IC-Datenbanken
Fig. 3
UNIX/VMS/NetWare UNIX/VMS/NetWare
QNX Environment QNX-Umgebung
Applications Applikationen
Database API Calls Datenbank-API-Aufrufe
EDDB/IC Library EDDB/IC-Bibliothek
GATEWAY LIBRARY GATEWAY-BIBLIOTHEK
BSD Socket Library BSD-Socket-Bibliothek
TCP/IP Packets TCP/IP-Pakete
Emhart Network Gateway Emhart-Netzwerk-Gateway
GATEWAY SERVICE GATEWAY-SERVICE
EDDB/IC Databases EDDB/IC-Datenbanken
Production Line Consoles Produktionslinienkonsolen Fig. 4
Hot-end and Cold-end Production Line Consoles (PLC) Heisszustands- und Kaltzustands-Produktionslinienkonsolen (PLC)
Database Exceptions Datenbanken-Exceptions
Database Handle and Contents Datenbankbehandlung und Inhalt
Gateway Software Gateway-Software
Database Locate and Send Messages Datenbanklokalisierungs- und -sendenachrichten
Signals to User Application Signale an die Benutzerapplikation
Funktion Call Returns Furiktionsaufrufrückgaben
Database API Calls Datenbanken-API-Aufrufe
Remote User Workstations Entfernte Benutzerarbeitsstation
Fig. 5
Database API Calls Datenbanken-API-Aufrufe
Function Call Returns Funktionsaufrufrückgaben
Signals to User Application Signale an die Benutzerapplikation
Gateway Library Gateway-Bibliothek
TCP Receive Packets TCP-Empfangspakete
Low-level Socket Calls Low-Level-Socket-Aufrufe
TCP Send Packets TCP-Sendepakete
Gateway Service Gateway-Service
Virtual Circuit Release Virtueller Circuit-Release
Database Exceptions Datenbanken-Exceptions
Database Locate Datenbanklokalisierung
Database Handle Datenbankbearbeitung
Send Messages Senden von Nachrichten
Database Contents Datenbankinhalt
Fig. 6
Event ID Ereignis-ID
GetEvents API Call GetEvents-API-Aufruf
Local Host Name Name des lokalen Hosts
Host Port Number Host-Port-Nummer
Preparation Status Vorbereitungsstatus
Remote Server Name Name des entfernten Servers
Database Name Datenbankname
Database Size Datenbankgröße
Database Node Datenbankknoten
Database Handle Datenbankbearbeitung
Message Buffers Nachrichtenspeicher
Message Buffer Sizes Nachrichtenspeichergrößen
Status Status
GetEvents GetEvents
PrepareForEvents PrepareForEvents
Name_Locate Name_Locate
Send Send
Vc_Release Vc_Release
Recv (TCP op_code packet) Recv (TCP-op_Code-Paket)
Name Name
Port Port
Server Name Server-Name
Connect Status Verbindungsstatus
Listen/Accept Status Warten-/Aktzeptieren-Status
Port Port
Name Name
ClientQueinit ClientQueinit
Packet Buffers Paketspeicher
Packet Buffer Sizes Paketspeichergrößen
ClientCall ClientCall
Connect Verbinden
ClientDatainit ClientDatainit
Socketinit Socketinit
Bind Binden
Socket Socket
Listen Warten
Accept Akzeptieren
TCP Data Send Packets TCP-Datensendepakete
TCP Data Receive Packets TCP-Datenempfangspakete
Fig. 7
TCP Exception Send Packet TCP-Exception-Sendepaket
TCP Recv Packet TCP-Empfangspaket
TCP Data Send Packets TCP-Datensendepakete
RUSH Task RUSH-Task
COMS Task COMS-Task
DATA Task DATA-Task
Exception Message Exception-Nachricht
Reply Message Antwortnachricht
Request Message Anforderungsnachricht
Database Locate Datenbank Lokalisieren
Database Handle Datenbank Bearbeiten
Send Messages Senden der Nachrichten
Database Contents Datenbankinhalt
Database Exceptions Datenbank-Exceptions
Fig. 8
Accepting Client TCP Connections Akzeptieren von Client-TCP- Verbindungen
Initialize Data Socket in Listening Mode Initialisieren des Daten-Sockets im Wartemodus
Get Remote Host Name by Address Holen des Host-Namens durch die Adresse
Spawn off Children Tasks Erzeugen von Sub-Tasks
Prepare Child Tasks' Registration Name Vorbereiten des registrierten Namens der Sub-Tasks
Task "coms" Task "coms"
Task "data" Task "data"
Fig. 9
Receive and Reply Data Packets Empfangs- und Antwortdateripakete
From Client vom Client
Input Command Line Parameters Eingabekommandozeilenparameter
Receiving TCP Message Packets Empfangen von TCP-Nachrichten-Paketen
Task and Socket Processing Task- und Socket-Verarbeitung
Send QNX Message to "data" to Exit Senden der QNX-Nachricht an "data" zum Beenden
Decode Op_Code Decodieren von Op_Code
Task Registration Task-Registrierung
Inherit Socket Ownership from "Server" Vererben der Socket-Eigentümerschaft vom "Server"
Locate "data" Task Name Lokalisieren des "data" Task- Namens
Close Data Sockets and Exit Schließen der Daten-Sockets und Beenden
Spawn off Task "rush" for Event Queing Connect Erzeugen der Task "rush" zur Ereigniswarteschlangenverbindung
Prepare Reply Message Buffer and its Size Vorbereiten des Antwortnachrichtenspeichers und dessen Größe
Return TCP Packet to Client with Database Information Zurückgeben des TCP-Pakets an den Client mit Datenbankinformationen
Fig. 10
Process Events and Messages Verarbeiten von Ereignissen und Nachrichten
Input Command Line Parameters Eingabekommandozeilenparameter
Getting Database Events and QNX Messages Holen von Datenbankenereignissen und QNX-Nachrichten
Task and Events Preparations Task- und Ereignisvorbereitungen
Database Exception Events Datenbanken-Exception-Ereignisse
Process QNX Message from Task "coms" Verarbeiten der QNX-Nachricht von der Task "Coms"
Task Registration Task-Registrierung
Prepare for Database Exception Events Vorbereiten auf Datenbanken- Exception-Ereignisse
Locate Corresponding Task "rushxxyy" Lokalisieren der entsprechenden Task "rushxxyy"
NAME_LOCATE NAME_LOCATE
SEND_REPLY SEND_REPLY
VC_RELEASE VC_RELEASE
Reply QNX Message to Task "coms" Antwort der QNX-Nachricht an die Task "coms"
Fig. 11
Receive and Process QNX Messages From Task "data" Empfangen und Verarbeiten der QNX-Nachrichten von der Task "data"
Input Command Line Parameters Eingabekommandozeilenparameter
Receiving Messages Empfangen der Nachrichten
Task and Socket Processing Task- und Socket-Verarbeitung
Size Reply Message Größenantwortnachricht
Close Data Sockets and Exit Schließen der Daten-Sockets und Beenden
Task Registration Task-Registrierung
Make Socket Connection Herstellen der Socket-Verbindung
Locate "data" Task Name Lokalisieren des "data" Task-Namens
Reply Message to Task "data" Antwortnachricht an die Task "data"
Return TCP Packet to Client Zurückgeben des TCP-Pakets an den Client

Claims

1. Formungsmaschine für Glasgegenstände, umfassend ein Netzwerk- Gateway, das auf einer ersten Plattform betrieben wird, und eine Arbeitsstation, die auf einer zweiten Plattform betrieben wird,

wobei das Netzwerk-Gateway eine erste BSD- (Berkeley Socket Distribution) Socket-Bibliothek umfasst und

wobei die Arbeitsstation eine Applikation zum Erstellen und Empfangen von API- (Application Programming Interface) Aufrufen umfasst sowie eine zweite BSD- (Berkeley Socket Distribution) Socket-Bibliothek und

wobei die ersten und zweiten BSD-Socket-Bibliotheken dahingehend angepasst sind, dass sie bidirektional über TCP/IP- (Transmission Control Protocol/Internet Protocol) Pakete kommunizieren,

dadurch gekennzeichnet, dass die Arbeitsstation weiterhin

eine ereignisbetriebene Datenbankbibliothek umfasst sowie

eine Gateway-Bibliothek,

wobei die ereignisbetriebene Datenbankbibliothek dahingehend angepasst ist, dass sie bidirektional die Applikation und die Gateway-Bibliothek miteinander verbindet, und

wobei die Gateway-Bibliothek dahingehend angepasst ist, dass sie bidirektional die ereignisbetriebene Datenbankbibliothek und die zweite BSD- Socket-Bibliothek miteinander verbindet,

wobei das Netzwerk-Gateway weiterhin

eine ereignisbetriebene Datenbank umfasst sowie

einen Gateway-Service, der dahingehend angepasst ist, dass er bidirektional die erste BSD-Socket-Bibliothek und die ereignisbetriebene Datenbank miteinander verbindet.