DE69429740T2

DE69429740T2 - Integriertes automatisches Entwicklungssystem und zugehöriges Verfahren

Info

Publication number: DE69429740T2
Application number: DE69429740T
Authority: DE
Inventors: Thomas E. Byrd; Stephen F. Moore
Original assignee: Texas Instruments Inc
Current assignee: Texas Instruments Inc
Priority date: 1993-04-30
Filing date: 1994-04-27
Publication date: 2002-09-26
Anticipated expiration: 2014-04-28
Also published as: EP0622714B1; MY134707A; KR100326745B1; EP0622714A1; KR940024605A; DE69429740D1; JPH07146844A; TW265499B; US5528503A

Description

TECHNISCHES GEBIET DER ERFINDUNG

Diese Erfindung bezieht sich allgemein auf das Gebiet der Automatisierungssysteme. Insbesondere bezieht sich die vorliegende Erfindung auf ein integriertes Automatisierungs-Entwicklungssystem und -verfahren.

HINTERGRUND DER ERFINDUNG

Die Aufgabe der Automatisierung erfordert typischerweise die koordinierte Steuerung zahlreicher Entitäten zum Erreichen eines gemeinsamen Ziels. Wegen des Wesens der Automatisierungsumgebung und -anforderungen ist diese Aufgabe komplex. Die Automatisierungsentitäten können real wie etwa eine Fabrikanlage, lokale Netze, Datenbanken und Anwenderterminals oder abstrakt wie etwa Daten, Steuersoftware und Kommunikationsnachrichten und -protokolle sein.
Eine erste Schwierigkeit bei der Automatisierungsintegration ist die Kommunikation. Typischerweise können die Automatisierungsentitäten nicht direkt miteinander kommunizieren, so daß für die Kommunikation zwischen den Entitäten Schnittstellen benötigt werden. Es ist aber offensichtlich, daß die Lösung nicht darin besteht, eine Schnittstelle α für Kommunikationen zwischen den Entitäten X und Y, eine Schnittstelle β für Kommunikationen zwischen den Entitäten Y und Z und eine Schnittstelle y für Kommunikationen zwischen den Entitäten Z und X usw. zu formulieren. Ein solches System würde doppelte Anstrengungen für die Anfangssystemkonfiguration und für nachfolgende Neukonfigurationen erfordern.
Die Aufgabe der Automatisierungsintegration muß außerdem häufige Systemneukonfigurationen und -abwandlungen erleichtern. Häufig werden Anlagen zu einer Verarbeitungslinie oder -zelle hinzugefügt oder von ihr weggelassen, die automatischen Verarbeitungslinien oder -zellen können häufig neu konfiguriert werden usw. Somit muß sich das Automatisierungssystem leicht an diese Änderungen anpassen.
Außerdem ist für Automatisierungssysteme typisch, daß die durch viele der Entitäten ausgeführten Aufgaben parallel erledigt werden. Somit muß sich das Automatisierungssystem zur Erfüllung dieser Anforderung auch auf Parallelausführungen einstellen.
EP-A-0 162 670 offenbart eine automatische Industrieverarbeitungs- oder Fertigungsfabrik mit einer Reihe computergesteuerter Einrichtungen wie etwa Werkzeugmaschinen, Werkstück- und Werkzeugfördereinrichtungen und Lagervorrichtungen, die durch ein Computersystem gesteuert werden, bei dem die Steuersoftware als eine Reihe von elementaren Funktionsmodulen strukturiert ist, die mittels einer höheren Kommunikationsschnittstelle miteinander kommunizieren. Die Funktionen sind so strukturiert, daß sie in eine der Kategorien Job-Weg-Ablaufsteuerung, Aktivitäts-Manager, Controller und Server fallen, wobei ein Weg-Sequentialisierungsmodul die Sequenz steuert, in der verschiedene Aktivitäten in bezug auf einen Verarbeitungs- oder Fertigungs-Job, der durch die Einrichtung durchgeführt wird, ausgeführt werden, während jeder Aktivitäts-Manager die Aktivitäten einer Gruppe von Controllern, für die er verantwortlich ist, verteilt, und während die Controller für die Ausführung von Aktivitäten falls und wenn sie von dem zugeordneten Manager empfangen wurden, verantwortlich sind, während die Server unterdessen allgemeine Dienste für das andere Element des Systems liefern.
Gemäß der vorliegenden Erfindung werden ein integriertes Automatisierungs- Entwicklungssystem und -verfahren geschaffen, die die mit früheren Anordnungen verknüpften Nachteile und Probleme im wesentlichen beseitigen oder verringern.
Die vorliegende Erfindung schafft ein integriertes Automatisierungs- Entwicklungssystem zum Steuern und Koordinieren einer Fertigungsanlage, wobei das System mehrere Server-Prozesse umfaßt, wovon jeder enthält:
einen Nachrichten-Manager, der von den mehreren Server-Prozessen ASCII- Nachrichten empfängt, wobei der Nachrichten-Manager Mittel zum Ausführen von kommunikationsbezogenen Tasks umfaßt;
einen Sprachen-Interpretierer, der Mittel umfaßt, die für eine veränderliche Anzahl der Server-Prozesse die empfangenen ASCII-Nachrichten, die Befehle enthalten, die in einer textbasierten Programmiersprache ausgedrückt sind, bewerten, wobei der Interpretierer Mittel umfaßt, die die Befehle in den ASCII-Nachrichten erkennen;
einen Befehls-Manager, der die Befehle empfängt und ausführt, wobei der Befehls-Manager Mittel, die die Ausführung der Befehlsanforderungen managen und steuern, Mittel für die Datenspeicherung sowie Mittel für die Ereignisprotokollierung umfaßt; und
einen Logik-Controller, der das Management des logischen Ablaufs der Befehlsausführung durch den Befehls-Manager ausführt.
Die Server können weitere anwendungsspezifische Befehle enthalten, die ermöglichen, daß sie als Warteschlangen-Server, als Terminal-Server und als andere anwendungsspezifische Server-Prozesse dienen.
Die vorliegende Erfindung schafft außerdem ein Verfahren zur Integration eines Automatisierungs-Entwicklungssystems für die Steuerung und die Koordination einer Fertigungsanlage unter Verwendung mehrerer Server-Prozesse nach Anspruch 1, wobei das Verfahren die folgenden Schritte umfaßt: Prüfen auf und Empfangen von ASCII- Nachrichten von anderen Server-Prozessen; Bewerten der empfangenen Nachrichten, die wenigstens einen Befehl enthalten, der in einer textbasierten Programmiersprache ausgedrückt ist, für eine veränderliche Anzahl der Server-Prozesse und Erkennen der Befehle in den ASCII-Nachrichten. Die Befehle werden ausgeführt, und der Server-Prozeß setzt die Prüfung auf weitere ASCII-Nachrichten fort.
In einem nochmals weiteren Aspekt der vorliegenden Erfindung enthält ein integriertes Automatisierungs-Entwicklungssystem einen Steuerungs-Client zum Erzeugen von Nachrichten, die Befehle enthalten. Ein Anlagen-Server, der als Schnittstelle zu einer Fertigungsanlage dient, empfängt die Nachrichten von dem Steuerungs-Client-Prozeß, steuert die Fertigungsanlage nach Anweisung durch die Befehle in den Nachrichten und erzeugt Nachrichten als Antwort auf sie.
Ferner ist ein Warteschlangen-Server vorgesehen, der das Lenken der Nachrichten zwischen dem Steuerungs-Client und dem Anlagen-Server ermöglicht.

KURZBESCHREIBUNG DER ZEICHNUNG

Für ein besseres Verständnis der vorliegenden Erfindung kann auf die beigefügte Zeichnung Bezug genommen werden, in der:
Fig. 1 ein vereinfachter Systemblockschaltplan einer Ausführungsform der Erfindung auf der obersten Ebene ist;
Fig. 2 ein Diagramm ist, das die Komponenten einer Ausführungsform eines Server- Shell-Moduls zeigt;
Fig. 3 ein vereinfachtes Diagramm der Haupt-Server-Komponenten ist;
Fig. 4 ein vereinfachtes Diagramm ist, das die Datenstruktur der dynamischen Variablen zeigt;
Fig. 5 ein vereinfachtes Diagramm ist, das das nachrichtenbasierte Kommunikationsprotokoll zeigt;
Fig. 6 ein weiteres vereinfachtes Diagramm ist, das das nachrichtenbasierte Kommunikationsprotokoll zeigt;
Fig. 7 ein vereinfachtes Datenflußdiagramm ist, das den nachrichtenbasierten Kommunikationsprozeß zeigt;
Fig. 8 ein vereinfachter Ablaufplan der Verarbeitung von Befehlsnachrichten ist;
Fig. 9 ein vereinfachter Ablaufplan eines grundlegenden Server-Steuerungsablaufs ist;
Fig. 10 ein vereinfachter Ablaufplan der Serverinitialisierung ist;
Fig. 11 ein vereinfachter Ablaufplan der Server-Nachrichtenverarbeitung ist;
Fig. 12 ein vereinfachter Ablaufplan der Nichtstandard-Nachrichtenverarbeitung des Servers ist;
Fig. 13 ein vereinfachter Ablaufplan der Befehlsnachrichtenverarbeitung des Servers ist; und
Fig. 14 ein vereinfachtes Datenflußdiagramm der verteilten Nachrichtenkommunikation ist.

AUSFÜHRLICHE BESCHREIBUNG DER ERFINDUNG

Fig. 1 zeigt anhand der Zeichnung eine Ausführungsform des allgemein mit 10 bezeichneten und gemäß der Lehre der vorliegenden Erfindung konstruierten integrierten Automatisierungs-Entwicklungssystems und -verfahrens. Wie gezeigt ist, beruht das integrierte Automatisierungs-Entwicklungssystem 10 allgemein auf einem Client-Server- Modell, das eine Systemmodularität und das Verfahren zur Kommunikation zwischen Modulen definiert. Das System 10 umfaßt eine Gruppe Clients und Server genannter zusammenarbeitender Tasks. In Fig. 1 arbeitet ein graphischer Steuerungs-Client 14 mit einem SMS-Server (Halbleiter-Fertigungssystem-Server) 16, mit einem Anlagen-Server 22 und mit einem Terminal-Server 28 zusammen und wirkt mit diesen. Außerdem führen weitere Server - der Warteschlangen-Server 34 und der Zeitserver 36 - für die Gesamtfunktionen des Systems erforderliche Tasks aus.
Ein Server managt und steuert allgemein ein reales oder abstraktes Objekt oder eine abstrakte Entität in dem System. Durch das Beantworten von Befehlsanfragen repräsentiert er eine höhere Nachrichtenschnittstelle zu seinen Clients. Beispielsweise schafft der Anlagen-Server 22 Schnittstellen zu einer Fabrikanlage 24, während der SMS-Server 16 Schnittstellen zu einem Fabrik-Host-System (dem Halbleiterfertigungssystem 20) schafft und der Terminal-Server 28 Schnittstellen zu den Betreiber-Terminals 30 und zu der auf dem Terminal 30 laufenden Anwendungssoftware schafft.
Andererseits ist der graphische Steuerungs-Client 14 eine Task in dem System 10, die Befehlsanforderungen an die Server 16, 22 und 28 sendet, um auf die Funktionalität des dem Server zugrundeliegenden Objekts oder der Entität zuzugreifen. Somit wird die Automatisierung durch Koordination und Steuerung einer Gruppe von Objekten über ihre Server ausgeführt. Das Steuerungsobjekt ist selbst eine abstrakte Entität, die als ein Client-Prozeß realisiert ist.
Im allgemeinen haben Server keine vorherige Kenntnis anderer Server, die höhere Objekte in dem System repräsentieren. Beispielsweise sollte der Anlagen-Server 22 keine Befehle an einen Fabrik-Host-Server 1b senden, da dies in dem Anlagen-Server 22 unnötige Abhängigkeiten von dem besonderen Fabrik-Host 16 und seiner Befehlssyntax aufbauen würde. Solche Integrationsaktivitäten sollten von einem Steuerungs-Client, beispielsweise dem graphischen Steuerungs-Client 14, behandelt werden.
Wie in Fig. 2 gezeigt ist, können die Server 16, 22, 28, 34 und 36 und der Client 14 durch eine allgemeine Struktur repräsentiert werden, die der Server 40 genannt wird. Jeder Server 40 wird durch Hinzufügen von anwendungsspezifischem Code und anwendungsspezifischen Befehlen 48 zu Server-Shells 42 genannten vorher bestehenden Softwaremodulen erzeugt. Diese Server-Shells 42 sind ausführbare Dateien, die beim Start mit Textdateien konfiguriert werden, um einzigartige Anwendungs-Server und -Clients zu erzeugen. Die Server-Shells 42 werden vorzugsweise durch Laden von Befehlen, die in einer interpretierten textbasierten Programmiersprache oder auch in einer sogenannten Shell-Skript-Sprache zur Laufzeit oder durch Binden von C++-Befehlen zur Kompilierungszeit ausgedrückt werden, als Anwendungsprogramme konfiguriert. Die Server- Shells 42 enthalten vorzugsweise zwei Grundbausteine: den Grund-Code 44 und die gemeinsamen Befehle 46. Wenn ein neuer Anwendungs-Server benötigt wird, beginnt seine Realisierung somit mit der Server-Shell 42, auf der anwendungsspezifischer Code gebaut werden soll.
Anhand von Fig. 3 ist der Serverprozeß 40 mit seinen verschiedenen Hauptfunktionskomponenten gezeigt. Der Server 40 enthält die Server-Shell 42 und die weiteren anwendungsspezifischen Befehle und den Code-Manager 48. Die Server-Shell 42 selbst enthält viele Funktionsmodule, die Grund-Tasks ausführen. Die Server-Shell 42 enthält einen Befehls-Manager oder ein gemeinsames Befehlsmodul 41, das als Prozeßebenen- Betriebssystem für Befehle arbeitet. Der Befehls-Manager 41 managt und steuert die Ausführung der Befehlsanforderungen und schafft Einrichtungen zur Datenspeicherung und Ereignisprotokollierung. Die Server-Shells 42 sind nur Grundlagen für den Bau tatsächlicher Anwendungs-Server oder -Clients wie etwa des Anlagen-Servers 22, des Terminal-Servers 28 und des Warteschlangen-Servers 34. Die Server-Shells 42 enthalten Befehle, die die Entwicklung von Spezialanwendungen erleichtern. Diese Organisation trägt zur Modularität und Neukonfigurierbarkeit des Automatisierungs- Entwicklungssystems 10 bei.
Die Server-Shell 42 enthält außerdem einen Skript- oder Shell-Sprachen- Interpretierer 43, der es erlaubt, zur Laufzeit neue Befehle in der Skript-Sprache zu erzeugen. Die Skript-Sprache kann ein generischer höherer Shell-Code sein, den Personen, die mit dem Betriebssystem UNIX vertraut sind, allgemein verstehen. Die Skript-Sprache kann Bedingungen, Schleifenkonstrukte, die Ausdrucksbewertung und Umgebungsvariable enthalten. Da die Skript-Sprache zeilenweise interpretiert wird, beseitigt die Verwendung der Skript-Sprache anstelle der Sprache C++ beispielsweise die Notwendigkeit, den Code vor der Ausführung neu zu kompilieren und zu binden. Während der Interpretation nimmt der Skript-Sprachen-Interpretierer 43 im wesentlichen die Einträge in der Skript- Sprache und übersetzt sie in dynamische Variablenstrukturen, die für die Server verständlich und zugreifbar sind.
Die Server-Shell 42 enthält ferner einen Nachrichten-Manager 45. Der Nachrichten- Manager 45 führt Nachrichtenkommunikations-bezogene Tasks wie etwa eine Nachrichten-Syntax-Validierung und -Lenkung durch. Die Server-Shell 42 schafft außerdem einen Shell-Logik-Controller 47 für das Management des Grund-Steuer- und -Logikflusses des Servers 40. Ein weiterer Manager 49 für dynamische Variable dient der Überwachung der Speicherung und des Zugriffs auf die in Fig. 4 gezeigte dynamische Variablenstruktur. Die Funktionen des Nachrichten-Managers 45, des Shell-Server- Logik-Controllers 47 und des Managers für dynamische Variable werden unten ausführlicher diskutiert.
Die weiteren anwendungsspezifischen Befehle 48 führen Aktionen an dem Server oder an dem Objekt, das er bedient, aus oder ändert deren Zustand. Server, die vom gleichen ablauffähigen Shell-Programm gestartet werden, können außerdem Laufzeit- Textsegmente oder -Code gemeinsam nutzen und somit die Laufzeitspeichernutzung verringern. Beispielsweise nutzen acht Operator-Schnittstellen, die durch Laden von Konfigurationsdateien in das gleiche ablauffähige Terminal-Server-Shell-Programm erzeugt werden, zur Laufzeit nur eine Kopie des tatsächlichen Terminal-Server-Shell-Codes. Jeder Prozeß kann einen getrennten Datenbereich im Speicher halten, während er aber den gleichen Block des ausführbaren Programms im Speicher nutzt.
Anhand von Fig. 4 ist eine beispielhafte Datenstruktur für dynamische Variable gezeigt. Durch diese interne Hierarchie dynamischer symbolischer Textvariabler nutzen in dem Server 40 Befehle Daten gemeinsam. Vereinbarungsgemäß ist der Zustand des Servers 40 in diesen Variablen definiert. Das Programmieren in dem integrierten Automatisierungs-Entwicklungssystem 10 besteht somit hauptsächlich aus dem Manipulieren der dynamischen Variablen und dem Senden von Nachrichten. Die Komplexität eines Algorithmus hängt häufig von der Struktur der ihm zugrundeliegenden Daten ab. Die dynamischen Variablen 49 unterstützen den Entwickler beim Bau von Datendarstellungen, für die es klare Algorithmen gibt. Das folgende ist ein Beispiel für in der Skript- Sprache ausgedrückte dynamische Variable:
Das obenstehende Beispiel ist in Fig. 4 graphisch dargestellt. Die dynamische Variablenstruktur 49 zeigt beispielsweise, daß der Name des Servers "EQUIPA" ist und daß er einige Temperatur- oder "TEMP"-Messungen dreier Orte (LOCA, LOCB und LOCC) überwacht und aufgezeichnet hat. Der Zustand der dynamischen Variablen 49 besagt außerdem, daß dieser Anlagen-Server durch den Wert seiner dynamischen Variablen "SYS> PROTOCOL" Nachrichten in dem SECS-Format (SEMI Equipment Communications Standard-Format) verarbeiten kann. Somit ist zu sehen, daß die dynamischen Variablen 49 für jeden Server-Prozeß 40 eine ordentliche und hierarchische Organisation der Daten oder Werte schaffen, die leicht zugreifbar ist.
Anhand von Fig. 5 wird das Kommunikationsschema zwischen Clients und Servern gezeigt. Der Client 52 möchte, daß ein Betriebsmittel 62 eine spezifische Task ausführt. Der Client 52 teilt diesen Wunsch durch Senden einer Befehlsanforderungsnachricht 56 dem Server 54 mit, der mit einer Antwort und mit einer optionalen Datennachricht 58 oder 60 antwortet. Alle Nachrichten sind aus lesbaren ASCII-Zeichenketten zusammengesetzt. Die Datennachrichten 60 sind als jene Nachrichten definiert, die weder Befehle noch Antworten sind. Die Datennachrichten werden verwendet, um nach dem Senden der Antwort 58 auf die Befehlsnachricht 56 Daten an einen Clients 52 zu senden. Der Server 54 repräsentiert somit eine Schnittstelle zu dem Betriebsmittel oder Objekt 62. Dieser befehlsgetriebene Austausch bestimmt sämtliche Aktionen in dem Automatisierungs- Entwicklungssystem 10. Somit finden Aktionen in dem oder durch das Betriebsmittel 62 im Ergebnis ankommender Nachrichten statt. Alle ankommenden Nachrichten werden zunächst in einer Nachrichtenwarteschlange gespeichert. Aus der Warteschlange werden die Nachrichten auf einer FIFO-Grundlage (Zuerst-Einlesen/Zuerst-Ausgeben- Grundlage) gelesen. Das Management der Nachrichtenwarteschlangen in dem System 10 wird durch den Warteschlangen-Server 34 ausgeführt, dessen Einzelheiten unten beschrieben werden.
Anhand von Fig. 6 ist ein alternatives Kommunikationsschema 70 gezeigt. Ein Client 72 kommuniziert durch Senden eines Befehls 76 mit einem Server 74, wobei der Server 74 mit einer Antwort 78, d. h. mit einer Antwortnachricht 58 oder mit einer Datennachricht 60, antwortet (Fig. 5). Der Server 74 kann die Betriebsmittel 80 zum Ausführen der von dem Client 72 geforderten Task besitzen oder als Client für einen anderen Server 82 wirken, der den Befehl 86 empfängt und dementsprechend mit einer Antwort 88 und geeigneten durch sein Betriebsmittel 84 ausgeführten Aktionen antwortet. Außerdem kann der Server 74 auch eine Schnittstelle zu einer Entität oder zu einem Teilsystem besitzen, das nicht das von den Servern verwendete Nachrichtenprotokoll verwendet.
Nach der Beschreibung der Grundfunktionen der Server-Shell ist es aufschlußreich, bestimmte auf der Server-Shell aufgebaute Server zu diskutieren. Beispielsweise ist der Warteschlangen-Server 34 ein Server 40, der wichtig für die Operationen des Automatisierungs-Entwicklungssystems ist. Um Transparenz in bezug auf Kommunikationen unter sämtlichen Client- und Server-Prozessen in dem System 10 zu schaffen, managt der Warteschlangen-Server 34 eine Tabelle benannter Nachrichtenwarteschlangen und überwacht Kommunikationen mit dem integrierten Automatisierungs-Entwicklungssystem 10. Der Warteschlangen-Server 34 schafft eine niedere Nachrichtenschnittstelle für Client- und Server-Prozesse, die ermöglicht, daß die Prozesse höhere Kommunikationen betreiben.
Die primäre Funktion des Warteschlangen-Servers ist die, ASCII-Namen, beispielsweise dem Zeit-Server 36 und dem SMS-Server 16, durch das Betriebssystem wie etwa durch UNIX oder durch andere Betriebssysteme zugeordnete Warteschlangen-Identifizierungsnummern oder -schlüssel zuzuordnen. Dies ermöglicht, daß die Server in dem System anstatt durch Warteschlangen-Identifizierungsnummern durch wohlbekannte Namen aufeinander Bezug nehmen. Lediglich der Warteschlangen-Server 34 braucht die Tabelle der Warteschlange-Namen und ihre entsprechenden Betriebssystem- Warteschlangen-Identifizierungsnummern zu speichern.
Anhand von Fig. 7 ist das Nachrichtenprotokoll mit einem Server A 90 und einem Server B 91 gezeigt. Wie durch die Pfeile 92 und 93 gezeigt ist, melden sich die Server A und B beim Start beide bei dem Warteschlangen-Server 34 an bzw. registrieren sich bei ihm. Der Warteschlangen-Server 34 zeichnet darauf die Prozeß- oder Server-Namen in einer Tabelle auf und ordnet erforderlichenfalls jedem der Server 90 und 91 eine Warteschlangen-ID oder -Identifizierungsnummer zu. Außerdem erzeugt der Warteschlangen- Server 34 für jeden Server-Prozeß 90 und 91, falls sie noch nicht vorhanden ist, eine Warteschlange 94 und 95 und gibt daraufhin, wie mit den Pfeilen 96 und 97 gezeigt ist, die Identifizierungsnummer der Warteschlangen an den neu gestarteten Prozeß 90 und 91 zurück. Daraufhin können die neuen Prozesse A 90 und B 91 ihre jeweilige Warteschlange 94 und 95 zum Empfang von Nachrichten nutzen. Dementsprechend ist die Verwendung von Warteschlangen-Identifizierungsnummern gegenüber dem System transparent.
Wenn der Server A 90 beispielsweise eine Nachricht an den Server B 91 senden möchte, bittet er den Nachrichten-Server 34 um die Warteschlangen-ID des Servers 8, indem er, wie mit dem Pfeil 98 gezeigt ist, den Warteschlangennamen des Servers B liefert. Der Warteschlangen-Server 34 schlägt daraufhin den Namen des Servers B in seinen Tabellen nach und gibt, wie mit dem Pfeil 99 gezeigt ist, die entsprechende Warteschlangen-ID an den Server A 90 zurück. Wie mit dem Pfeil 100 gezeigt ist, kann der Server A 90 daraufhin die Warteschlangen-ID des Servers B nutzen, um Nachrichten an die Warteschlange 95 des Servers B zu senden. Jeder Server-Prozeß hält vorzugsweise die Namen- und die entsprechenden ID-Informationen anderer Server-Prozesse in einer lokalen Tabelle, so daß er nicht jedesmal, wenn eine Nachricht an die anderen Prozesse gesendet werden muß, den Warteschlangen-Server 34 zu bitten braucht.
Wenn kein Prozeß fordert, daß der Warteschlangen-Server 34 seine Warteschlange beim Abschluß des Servers aus dem System 10 entfernt, hält der Warteschlangen-Server 34 den Warteschlangen-Namen und die ID zur zukünftigen Verwendung in seinen Tabellen. Dies ermöglicht, daß ein Prozeß vorübergehend beendet wird, während es weiter ermöglicht, daß andere Prozesse Nachrichten in seiner Warteschlange einreihen. Wenn ein Prozeß neugestartet wird und sich bei dem Warteschlangen-Server anmeldet, wird ihm die bestehende Warteschlangen-ID zugewiesen. Der Prozeß kann daraufhin irgendwelche Nachrichten, die sich in seiner Warteschlange angesammelt haben, während er außer Betrieb war, lesen und beantworten. Somit entfernen vorzugsweise nur kurzlebige Clients beim Beenden ihre Warteschlangen.
Da der Warteschlangen-Server 34 das Warteschlangen-Management für sämtliche Server und Clients in dem System 10 schafft, muß er als Hintergrundprozeß laufen, bevor irgendwelche anderen Prozesse gestartet werden. Der Warteschlangen-Server 34 kann durch Eingabe des entsprechenden Befehls auf der Befehlszeile von Hand gestartet werden, wobei der Warteschlangen-Server 34 vorzugsweise aber jedes Mal, wenn die CPU gestartet oder gebootet wird, automatisch gestartet wird.
Der Grundablauf für die Befehlsnachrichtenverarbeitung wird zusätzlich zu den Fig. 2 und 7 anhand von Fig. 8 gezeigt. Da praktisch sämtliche Aktionen in dem System 10 nachrichtengesteuert sind, prüft der Server B 91, wie im Block 101 gezeigt ist, beispielsweise zunächst seine Warteschlange 95, um ankommende Nachrichten zu erfassen. Die Nachrichten enthalten von einem Client oder von einem anderen Server ausgegebene Befehle zum Aufruf einer Aktion. Wie in den Blöcken 103 und 104 gezeigt ist, decodiert oder analysiert die Server-Shell 42 des Servers B 91 die Nachricht in Felder und lokalisiert den in der Nachricht angegebenen Befehl in einer Befehlsliste 102. Die Befehlsliste 102 repräsentiert sämtliche Befehle oder Aktionen, die ihr Server ausführen kann.
Außerdem gibt die Befehlsliste 102 die richtige Syntax des Befehls einschließlich seiner Parameter und den Ort des Codes, der die Task des angegebenen Befehls ausführt, an. Somit verifiziert die Server-Shell 42, wie im Block 105 gezeigt ist, erforderlichenfalls die Befehlsyntax in der Nachricht. Wie oben diskutiert wurde, sind die in dem integrierten Automatisierungssystem 10 verwendeten Nachrichten aus einer lesbaren ASCII- Zeichenkette mit einem wohldefinierten, aber flexiblen Format zusammengesetzt. Daraufhin lenkt die Server-Shell 42 die Nachricht anhand eines Namens oder spezieller Lenkungsparameter an den Befehlscode. Der Befehlscode wird, wie im Block 106 gezeigt ist, unter Verwendung der Nachricht als Eingabe ausgeführt. Nach der Ausführung des Codes erzeugt die Server-Shell 42, wie im Block 107 gezeigt ist, erforderlichenfalls eine Antwortnachricht. Die Antwortnachricht ist eine als Antwort auf die durch den Client gesendete Befehlsnachricht durch einen Server an einen Client zurückgegebene Nachricht.
Nachrichten zwischen Servern 54 und Clients 52 werden durch Warteschlangennamen gelenkt. Der Warteschlangen-Server 34 (Fig. 1) managt die Warteschlangennamenzuordnungen und wird von allen anderen Clients 52 und Servern 54 verwendet, um einander Nachrichten zuzusenden. Die Nachrichten werden in den Servern 54 durch den Befehlsnamen oder durch den Nachrichtenkontext gelenkt. Wenn ein Server 54 eine Befehlsnachricht empfängt, beruht die unternommene Aktion auf dem gegebenen Befehlsnamen.
Ein Nachrichtenkontext oder "ctxt =" ist ein von den Clients 52 in den Befehlsnachrichten angeordneter eindeutiger Identifizierer. Dieser Nachrichtenkontextidentifizier muß durch die Server 54 aufbewahrt und in irgendwelchen resultierenden Antwort- oder Datennachrichten zurückgegeben werden. Der Nachrichtenkontext in den Antwort- und Datennachrichten ermöglicht, daß der Client 52 ankommende Ergebnisse selbst dann identifiziert, wenn mehrere ähnliche Befehle an mehr als einen Server 54 ausgesendet wurden.
Wie oben diskutiert wurde, sind sämtliche Nachrichten in dem Automatisierungs- Entwicklungssystem 10 ASCII-Textzeichenketten. Diese Textzeichenketten können irgendwelche Daten enthalten, die in dem Zeichenkettenformat dargestellt werden können. Die einzelnen Positionen der Daten in einer Nachricht sind durch Leerräume getrennt, die SPACES, LINEFEEDS, CARRIAGE RETURNS und TABS umfassen.
Diese Datenpositionen sind Parameter oder Felder, die in zwei Kategorien fallen: Tag- und Nicht-Tag-Parameter, wobei Tag-Parameter ein Tag und die Daten oder den Wert enthalten, die durch ein Gleichheitszeichen oder = getrennt sind, während Nicht- Tag-Parameter Datenpositionen sind, die keine Gleichheitszeichen enthalten.
Alle Nachrichten des Automatisierungs-Entwicklungssystems 10 müssen mit einem Tag-Parameter "fr" beginnen. Mit anderen Worten, die ersten drei Zeichen irgendeiner Nachricht müssen "fr =" sein. Dies sind die einzigen Daten in den Nachrichten, die eine feste Position haben müssen. Dieses "fr"-Tag identifiziert den Absender der Nachricht und identifiziert die Nachricht außerdem in Servern, die andere Nachrichtenformate verstehen müssen, als Automatisierungs-Entwicklungssystem-Nachricht.
Alle Nachrichtenlenkungsinformationen sind in dem Text einer Nachricht enthalten. Die Tag-Parameter "fr =" und "to =" geben Lenkungsinformationen für die Kommunikation zwischen den Servern 54 und den Clients 52 an, während die Tag-Parameter "do ="- und "ctxt ="-Nachrichten an spezifische Code-Blöcke in Servern lenken. Die reservierten Tag-Namen und ihre Funktionen sind zusammengefaßt und unten aufgeführt:

RESERVIERTE TAG-NAMEN

fr Identifiziert Absender und Standardformat
to Identifiziert beabsichtigen Empfänger
do Identifiziert auszuführenden Befehl
ctxt Identifiziert eine besondere Reply- oder Data-Nachricht
reply Identifiziert Rückgabe-Code eines Befehls
command Identifiziert das cmd, das eine Reply- oder Data-Nachricht erzeugt hat
comment Erläutert einen Rückkehr-Code eines Befehls

RESERVIERTE NICHT-TAG-PARAMETER

noreply Wird in Cmd-Nachrichten zur Unterdrückung der Reply-Nachricht angeordnet
nosyntax Wird in Cmd-Nachrichten zur Unterdrückung der Syntax-Prüfung angeordnet
Anhand von Fig. 6 ist ein vereinfachter Ablaufplan gezeigt, der die Server-Logik für die Befehlsnachrichtenverarbeitung darstellt. Ein Server 54 muß auf ankommende Befehlsnachrichten von irgendeiner Client-Task 52 antworten. Der Server 54 besitzt keine vorherige Kenntnis dessen, welcher Client 52 seine Befehle senden kann. Ankommende Befehlsnachrichten umfassen den durch das Tag "fr =" angegebenen Namen der Task des sendenden Client. Somit muß der Server benannte Tasks, die vor der Laufzeit nicht bekannt sind, beantworten können. Dies wird durch die Kommunikation mit dem Warteschlangen-Server 34 (Fig. 1), der die benannten Warteschlangen managt, ausgeführt. Die Server 54 und die Clients 52 müssen ihren Namen beim Start bei dem Warteschlangen- Server registrieren, um sich selbst dem System 10 bekannt zu machen. Dies ist im Block 122 als ANMELDUNG gezeigt. Wenn die Anmeldung nicht erfolgreich war, tritt der Server im Block 126 aus und darf keine Nachrichten empfangen. Wenn die Anmeldung erfolgreich war, geht die Ausführung zum Block 128 über, wo sie auf ankommende Befehlsnachrichten von irgendwelchen Clients wartet.
Wie im Block 130 gezeigt ist, muß ein Server 54, wenn er eine Befehlsnachricht durch Rückgabe einer Antwortnachricht oder Datennachricht an einen Client 52 beantwortet, den Nachrichtenkontext aufbewahren, wenn der Kontext in der Befehlsnachricht von dem Client gegeben wurde. Wie im Block 132 gezeigt ist, sucht der Server 54 daraufhin in seiner Befehlsliste, um zu bestimmen, ob er den Befehl ausführen kann. Wenn der Befehl nicht in der Befehlsliste gefunden werden kann, wird, wie im Block 138 gezeigt ist, eine Fehlerantwortnachricht erzeugt. Andernfalls wird, wie in den Blöcken 134 und 136 gezeigt ist, der Befehl ausgeführt und eine Antwort erzeugt. Wie in den Blöcken 140 und 142 gezeigt ist, wird der Befehlskontext, der im Block 130 aufbewahrt wurde, daraufhin in die erzeugte Antwortnachricht aufgenommen und die Nachricht gesendet. Außerdem gibt es Situationen, in denen keine Antwortnachrichten erforderlich sind. Wenn der Server 54 beispielsweise eine Befehlsnachricht empfängt, die den Nicht-Tag- Parameter "noreply" enthält, sollte er den Befehl normal verarbeiten, aber keine Antwortnachricht für diese Befehlsnachricht erzeugen. Wie in den Blöcken 144 und 146 gezeigt ist, bleibt der Server 54, bis er austritt, in der Schleife und wartet auf Befehlsnachrichten, die die Befehle ausführen und Antwortnachrichten zurückschicken. Beim Austritt wird der Server-Prozeß abgeschlossen, wobei der Warteschlangen-Server 34 (Fig. 1) optional die entsprechende Warteschlange aus seinen Warteschlangen-Tabellen löschen kann.
Fig. 7 zeigt eine ausführlichere Darstellung des logischen Steuerungsablaufs des Servers. Sämtliche Server 54 führen, wenn sie erstmals gestartet werden, bestimmte Aktionen aus (Block 160). Diese Aktionen ermöglichen die Initialisierung der Server 54 beim Start. Dies ermöglicht, eine ausführbare Datei für mehrere verschiedene, aber ähnliche Anwendungen zu verwenden, was die Menge des redundanten Codes und die mit dem Neukompilieren verschiedener Versionen von Servern verbrachte Zeit verringert. Wie im Block 162 gezeigt ist, werden sämtliche gemeinsamen Serverbefehle 46 (Fig. 2) einschließlich anwenderspezifizierter Befehle beim Start erzeugt. Da diese Befehle sofort nach dem Start erzeugt werden, können sie von der Befehlszeile der Server-Shell oder an irgendeinem Punkt in einer Startdatei aufgerufen werden. Dies ist auch die Stelle, an der die Befehlsliste erzeugt wird.
Wie im Block 164 gezeigt ist, stellt die Server-Shell Software-Abfangroutinen für vorgegebene Signale ein, die durch die Server-Shell abgefangen werden, um zu ermöglichen, daß der Server einen kontrollierten Austritt vornimmt. Ein kontrollierter Austritt ist ein Austritt, in dem der Server irgendwelchen durch den Server-Entwickler oder durch die Server-Shell definierten Austritts-Code ausführt. Außerdem führen die Server einen kontrollierten Austritt aus, wenn sie einen Austrittsbefehl von einem Client empfangen.
Im Block 166 werden die dynamischen Shell-Variablen erzeugt. Jeder auf der Server- Shell 42 aufgebaute Server 54 enthält einige vordefinierte dynamische Variable. Die dynamischen Variablen werden initialisiert, bevor die Befehlszeilenargumente für den Server verarbeitet werden, so daß ihre Werte erforderlichenfalls durch Befehlszeilenbefehle oder Startdateien überschrieben werden können. Vorzugsweise sind die dynamischen Variablen, die initialisiert werden, der aus dem Befehlszeilennamen des Prozesses abgeleitete Servername; das momentane Arbeitsverzeichnis, das den Weg des Verzeichnisses enthält, von dem aus der Prozeß gestartet wurde; die Startdateivariable, die auf der Befehlszeile eingestellt werden kann, um der Server-Shell mitzuteilen, daß sie einige Startbefehle in einer Datei ausführen soll; und die Server-Shell-Versionsnummer, die die Version der Server-Shell, auf der dieser Server aufgebaut ist, widerspiegelt.
Die Server des integrierten Automatisierungs-Entwicklungssystems enthalten außerdem mehrere (nicht gezeigte) Standardprotokolle. Wie im Block 168 gezeigt ist, werden die Namen und die Merkmale dieser Protokolle zu diesem Zeitpunkt zugewiesen. Vorzugsweise können der Dateiname und die Standardmerkmale durch Befehlszeilenbefehle oder Startbefehle zurückgesetzt werden. Wenn der Server-Prozeß gestartet und diese Befehle ausgeführt werden, können nachfolgend im Block 170 einer oder mehrere Befehle auf der Betriebssystem-Befehlszeile eingegeben werden. Falls die Befehlszeilen-Befehle irgendwelche Fehler enthalten, tritt der Server, wie in den Blöcken 172 und 174 gezeigt ist, aus.
Im Block 176 meldet sich die Server-Shell beim Warteschlangen-Server an, um eine Nachrichtenübermittlung zu ermöglichen. Der Anmeldeprozeß ist oben mit Bezug auf Fig. 7 beschrieben. Da die Nachrichten durch Server-Namen gemanagt und gelenkt werden, muß jeder Server für das System 10 eindeutig sein. Wenn der Warteschlangen- Server nicht läuft oder wenn das Anmelden aus irgendeinem Grund fehlschlägt, wird, wie in den Blöcken 178 und 180 gezeigt ist, eine Fehlermeldung gedruckt oder angezeigt und der Server beendet.
Wie im Block 182 gezeigt ist, wird an dieser Stelle, falls er vorhanden ist, ein Befehl namens srv_init aufgerufen. Der Befehl srv_init ist ein ortsspezifischer und serverspezifischer Initialisierungs-Hook-Befehl. Allgemein werden die Server 54 des Automatisierungs-Entwicklungssystems dadurch erzeugt, daß zu der Server-Shell 42 anwendungsspezifische Befehle hinzugefügt werden, die durch Clients aufgerufen werden können. Die anwendungsspezifischen Befehle werden im Ergebnis einer ankommenden Befehlsnachricht verarbeitet und haben keine Wirkung auf die Steuerlogik der Server-Shell. Jedoch kann ein spezieller Typ von Befehlen als Möglichkeit für einen Server-Entwickler bereitgestellt werden, um an vorgegebenen Orten in dem Steuerungsablauf Code zu der Steuerlogik der Server-Shell hinzuzufügen. Standardmäßig führen diese Befehle keine Aktion aus und haben keine Wirkung auf die Server-Ausführung. Diese Spezialbefehle werden ausgeführt, wenn die Server-Shell in dem Steuerungsablauf eine spezifische Stelle erreicht. Diese ortsspezifischen Befehle oder Hook-Befehle sind in den Ablaufplänen der Fig. 7-10 als punktierte und gestrichelte Blöcke angegeben.
Wenn die dynamische Variable, die den Startdateinamen enthält, wie im Block 184 gezeigt ist, auf der Befehlszeile oder mit dem srv_init-Befehl eingestellt wurde, sucht die Server-Shell in dem momentanen Arbeitsverzeichnis nach der durch die dynamische Variable benannten Startdatei. Wie in den Blöcken 186 und 188 gezeigt ist, werden daraufhin so lange Befehle aus der Datei gelesen und ausgeführt, bis keine mehr vorhanden sind.
Der gesamte Dateizugriff innerhalb eines Servers erfolgt in bezug auf das momentane Arbeitsverzeichnis des Servers. Das momentane Arbeitsverzeichnis ist standardmäßig das Verzeichnis, von dem aus der Server gestartet wurde. Durch Einstellen der dynamischen Variablen CWD mit einem Befehlszeilen-Befehl, einem srv_init-Befehl oder einem Befehl in einer Startdatei kann das momentane Arbeitsverzeichnis aber auf ein anderes Verzeichnis eingestellt werden. Nach dem Laden der Startdatei ändert die Server- Shell, wie im Block 190 gezeigt ist, erforderlichenfalls ihr tatsächliches momentanes Arbeitsverzeichnis, um es an das durch die dynamische Variable CWD spezifizierte anzupassen. Falls die Server-Shell nicht in das angegebene Verzeichnis übergehen kann, wird der Server, wie in den Blöcken 192 und 194 angegeben ist, beendet, wobei er eine Fehlermeldung protokolliert.
Wenn der Server seinen Initialisierungsprozeß abschließt, tritt er, wie im Block 196 gezeigt ist, in eine Schleife ein, in der er eine Nachricht aus der Warteschlange liest, sie verarbeitet und daraufhin zum Lesen einer weiteren Nachricht zurückkehrt. Die Fig. 8-10 zeigen die Steuerlogik für die Nachrichtenverarbeitungsschleife.
In Fig. 11 stellt der Block 200 den in Fig. 7 gezeigten Initialisierungsprozeß dar. Falls ein durch einen Befehl erzeugtes Alarmsignal empfangen wird, während die Server-Shell auf eine Nachricht wartet, wird, wie in den Blöcken 202 und 204 gezeigt ist, der Hook- Befehl srv_alarm aufgerufen. Wie im Block 206 gezeigt ist, wartet die Server-Shell daraufhin weiter durch Prüfen der Warteschlange auf eine Nachricht. Falls zu diesem Zeitpunkt ein Alarmsignal empfangen wird, kehrt sie zum Block 204 zurück, wo der Hook- Befehl srv_alarm aufgerufen wird. Wenn andernfalls, wie im Block 210 gezeigt ist, keine Nachrichten in der Warteschlange sind, wird, wie im Block 212 gezeigt ist, der Hook- Befehl srv_rcverr aufgerufen. Standardmäßig wartet die Server-Shell auf unbestimmte Zeit auf das Eintreffen einer Nachricht in der Warteschlange. Wenn eine Nachricht eintrifft, wird der Ablauf fortgesetzt und die Nachricht, wenn möglich, verarbeitet.
Wenn aber eine dynamische Variable definiert ist, die angibt, daß der Server nicht ständig auf Nachrichten warten soll, prüft der Server einmal die Nachrichtenwarteschlange und verarbeitet die empfangene Nachricht, wenn eine gewartet hat. Wenn das nicht der Fall ist, versucht die Server-Shell den Hook-Befehl srv_rcverr aufzurufen. Diese Prozedur wird verwendet, um Server wie etwa den Terminal-Server 28 (Fig. 1) zu ermöglichen, die zusätzlich zu der Nachrichtenwarteschlange bei Vorrichtungen sperren. Wenn diese dynamische Variable nicht definiert ist und während des Versuchs des Lesens einer Nachricht aus der Warteschlange ein Fehler auftritt, ruft die Server-Shell, falls vorhanden, srv_rcverr auf, protokolliert eine Nachricht für das Fehlerprotokoll und kehrt, wenn sie nicht angewiesen wird auszutreten, zurück, um auf eine weitere Nachricht zu warten. Vorzugsweise können Vorkehrungen getroffen werden, damit die Server-Shell, wenn eine angegebene Anzahl von Fehlern aufeinanderfolgend auftritt, eine Nachricht in das Fehlerprotokoll schreibt und beendet wird.
Wenn nachfolgend, wie im Block 210 gezeigt ist, eine Nachricht empfangen wird, wird die Nachricht geprüft, um zu ermitteln, ob sie in dem richtigen Automatisierungs- Entwicklungssystem-Format ist. Das richtige Nachrichtenformat ist vorzugsweise als eine Nachricht definiert, die mit dem "fr"-Tag beginnt. Wenn im Block 214 ermittelt wird, daß die ankommende Nachricht eine Nicht-Automatisierungs-Entwicklungssystem- Nachricht ist, wird sie im Block 216, der in Fig. 12 fortgesetzt und unten diskutiert wird, als Nicht-Standardformat-Nachricht behandelt und verarbeitet. Wenn die Nachricht das richtige Format hat, sucht die Server-Shell, wie im Block 218 gezeigt ist, nach einem "to"-Tag in der Nachricht. Falls das "to"-Tag in der Nachricht vorhanden ist, während der Wert des "to"-Parameters nicht mit dem Namen dieses empfangenden Servers übereinstimmt, ruft die Server-Shell, wie in den Blöcken 220 und 222 gezeigt ist, falls er definiert ist, den Hook-Befehl srv_baddr auf. Wenn der "to"-Tag-Wert der gleiche wie der Server-Name ist oder wenn kein srv_baddr-Hook definiert ist, wird die Nachricht normal verarbeitet. Der srv_baddr-Hook-Befehl wird durch den Warteschlangen-Server 34 (Fig. 1) verwendet, um Nachrichten an andere CPUs zu lenken.
Um die Nachricht zu verarbeiten, wird sie, wie im Block 224 gezeigt ist, in Tag- und Nicht-Tag-Parameter analysiert. Das Analysieren ermöglicht, daß in der Sprache C++ und in der Skript-Sprache geschriebene Befehle auf die Nachrichtenparameter zugreifen. Falls während des Analysierens der Nachrichten ein Fehler wegen fehlangepaßter Anführungszeichen auftritt, wird, wie in den Blöcken 226 und 228 gezeigt ist, an den Client eine Antwortnachricht zurückgegeben, die den Fehler angibt. Wie im Block 230 gezeigt ist, ruft die Server-Shell daraufhin, falls er definiert ist, den Hook-Befehl srv_parseerr auf.
Falls die Nachrichtenanalyse fehlerfrei abgeschlossen wurde und in der ankommenden Nachricht ein "reply"-Tag gefunden wird, wird sie, wie im Block 234 gezeigt ist, als Antwortnachricht behandelt. Falls die Nachricht außerdem einen "ctxt"-Parameter enthält, sucht die Server-Shell daraufhin in einer Warteliste nach einem Eintrag mit einem passenden Kontextwert. Falls ein Eintrag gefunden wird, wird, wie im Block 240 gezeigt ist, der dem Eintrag zugeordnete Befehl aufgerufen. Falls die Nachricht keinen "ctxt"- Parameter enthält oder falls das "ctxt" in der Nachricht nicht in der Warteliste vorhanden ist, ruft die Server-Shell, wie im Block 238 gezeigt ist, falls er vorhanden ist, den Hook- Befehl srv_reply auf. Falls er nicht vorhanden ist, wird die Nachricht ohne Ausführung des Befehls in der Nachricht verworfen.
Eine Befehlsnachricht ist als eine Nachricht definiert, die ein "do"-Tag, aber kein "reply"-Tag enthält. Wenn im Block 234 kein "reply"-Tag gefunden wird, sucht die Server- Shell somit, wie im Block 242 gezeigt ist, nach dem "do"-Tag und -Parameter. Wenn das "do"-Tag und der "do"-Parameter vorhanden sind, ist es eine Befehlsnachricht, wobei die Verarbeitung wie im Block 244 und in Fig. 13 gezeigt fortgesetzt wird. Die Verarbeitung der Befehlsnachricht wird unten in Verbindung mit Fig. 13 ausführlich beschrieben.
Falls eine Nachricht kein "do"- oder "reply"-Tag enthält, wird angenommen, daß sie eine Datennachricht ist. Die Verarbeitung von Datennachrichten ist im Block 246 gezeigt. Die Server-Shell sucht in der Nachricht nach einem "ctxt"-Parameter und prüft, wie im Block 248 gezeigt ist, die Warteliste auf einen Eintrag mit dem gleichen Kontextparameter. Falls die Nachricht kein "ctxt"-Tag enthält oder ein "ctxt"-Tag enthält, das nicht auf der Warteliste vorhanden ist, ruft die Server-Shell, wie im Block 250 gezeigt ist, falls er vorhanden ist, einen Hook-Befehl srv_data auf. Falls der Befehl srv_data nicht vorhanden ist, wird die Nachricht verworfen und ignoriert. Falls ein Eintrag mit einem passenden Kontextwert gefunden wird, wird der mit dem Eintrag verknüpfte Befehl, wie im Block 252 gezeigt ist, ausgeführt.
Die Server-Shell verarbeitet weiter Nachrichten, bis sie mit einem Austrittssignal oder mit einem "exit"-Befehl von einem Client beendet wird. Der Austrittsbefehl setzt vorzugsweise einen Austrittsmerker in der Server-Shell. Wie im Block 254 gezeigt ist, wird der Austrittsmerker am Ende jeder Nachrichtenverarbeitungsschleife geprüft. Falls er gesetzt worden ist, ruft die Server-Shell, wie im Block 256 gezeigt ist, wenn sie austritt, falls er vorhanden ist, einen Hook-Befehl srv_exit auf und wird daraufhin beendet.
Anhand von Fig. 12 ist die Verarbeitung von Nicht-Standardformat-Nachrichten 216 gezeigt. Wenn eine Nicht-Standardformat-Nachricht empfangen wird, prüft die Server- Shell zweckmäßig eine spezifische dynamische Variable, beispielsweise SYS> PROTOCOL (in Fig. 4 gezeigt), um zu entscheiden, wie die Nachricht zu verarbeiten ist. Wie in den Blöcken 260 und 264 gezeigt ist, kann die dynamische Variable SYS> PROTOCOL beispielsweise angeben, daß die Nachricht im SECS-Format (SEMI Equipment Communications Standard-Format) oder im ASCII-Format ist. Falls diese Variable nicht vorhanden ist oder keinen Wert hat, wird die Nachricht, wie im Block 268 gezeigt ist, falls er vorhanden ist, an den Hook-Befehl srv_msg übergeben. Falls srv_msg nicht vorhanden ist, wird die Nachricht verworfen und ignoriert.
Wenn die dynamische Variable SYS> PROTOCOL auf SECS gesetzt ist, verarbeitet die Server-Shell die Nachricht durch Aufruf eines Hook-Befehls sxdecode. Der Hook- Befehl sxdecode koppelt Daten aus der SECS-Nachricht aus und speichert sie in dynamischen Variablen. Falls die dynamische Variable SYS> PROTOCOL auf ASCII gesetzt worden ist, führt die Server-Shell den Hook-Befehl cut aus, um die Nachricht zu verarbeiten. Der cut-Befehl koppelt Daten aus ASCII-Nachrichten aus und speichert die ausgekoppelten Daten in dynamischen Variablen. In beiden Fällen muß das Format der SECS- und ASCII-Nachrichten zuvor definiert worden sein. Beide Befehle sind auch in der Anlagen-Server-Shell für die SECS- und ASCII-Nachrichtenverarbeitung definiert.
Nachdem eine Nicht-Standardformat-Nachricht durch sxdecode oder cut decodiert worden ist, prüft die Server-Shell die Warteliste auf einen Eintrag, der die Nachricht, wie im Block 270 gezeigt ist, zu einem Befehl für die Verarbeitung leitet. Falls ein Eintrag gefunden wird, wird, wie im Block 272 gezeigt ist, der entsprechende Befehl aufgerufen. Falls kein Kontexteintrag gefunden wird und srv_msg definiert ist, wird, wie im Block 268 gezeigt ist, srv_msg aufgerufen, um die Nachricht zu verarbeiten. Daraufhin kehrt die Ausführung in Fig. 11 zum Block 254 zurück.
Falls eine Standardformat-Nachricht ein "do"-Tag, aber kein "reply"-Tag enthält, wird angenommen, daß sie eine Befehlsnachricht ist. Anhand von Fig. 13 ist die Befehlsnachrichtenverarbeitung 244 gezeigt. Vorzugsweise nimmt die Server-Shell an, daß das "do"-Tag den auszuführenden Befehl identifiziert. Wie in Block 280 gezeigt ist, durchsucht sie die Befehlsliste des Servers nach einem Befehl, dessen Name mit dem Wert des "do"-Tags übereinstimmt. Falls der Befehl in der Befehlsliste des Servers nicht gefunden wird, führt die Server-Shell, wie in den Blöcken 282 und 284 gezeigt ist, falls er vorhanden ist, einen Hook-Befehl srv_command aus. Falls srv_command nicht vorhanden ist, konstruiert die Server-Shell eine Fehlerantwortnachricht und sendet sie, wie in Block 286 gezeigt ist, an den Client.
Falls der mit dem "do"-Tag identifizierte Befehl in der Befehlsliste gefunden wird, wird die Syntax der Befehlsnachricht, wie im Block 288 gezeigt ist, gegenüber der in der Befehlsliste gespeicherten Syntaxzeichenkette geprüft. Wenn in der ankommenden Nachricht aber ein Nicht-Tag-Parameter "nosyntax" oder eine dynamische Variable nosyntax vorhanden ist, wird die Syntaxprüfung nicht ausgeführt. Falls ein Syntaxfehler erfaßt wird, wird, wie in den Blöcken 290 und 286 gezeigt ist, durch die Server-Shell eine Fehlerantwortnachricht an den Client zurückgegeben und der Befehl nicht ausgeführt. Falls die Syntax der Befehlsnachricht richtig ist, ruft die Server-Shell, wie im Block 292 gezeigt ist, den Code des Befehls auf. Der Befehls-Code kann in der Sprache C++ oder in der Skript-Sprache geschrieben sein. Wenn C++-Befehle aufgerufen werden, wird die dem Befehl beigefügte vorkompilierte C++-Funktion gerufen. Wenn ein Skript- Sprachen-Befehl aufgerufen wird, wird der Skript-Sprachen-Code zeilenweise interpretiert.
Ob der Befehls-Code in C++ oder als Skript geschrieben wurde, muß er einen ganzzahligen Wert und optionale Zeichenkettendaten zurückgeben. Die zurückgegebene ganze Zahl und die Zeichenkettendaten werden zur Konstruktion einer Antwortnachricht verwendet, die an den Client zurückgegeben wird. Falls die Befehlsnachricht, die den Befehl aufgerufen hat, einen "noreply"-Parameter enthält, ist, wie im Block 294 gezeigt ist, keine Antwort erforderlich und wird keine Antwort an den Client gesendet. Der "noreply"-Parameter wird verwendet, wenn der erfolgreiche Abschluß eines besonderen Befehls für den Client nicht wesentlich ist. Falls eine Antwort erforderlich ist und die Befehlsnachricht, die den Befehl aufgerufen hat, einen "ctxt"-Parameter enthält, nimmt die Server-Shell das Kontext-Tag und seinen Wert in die resultierende Antwortnachricht auf. Daraufhin kehrt die Ausführung zum Block 254 in Fig. 11 zurück.
In dem Automatisierungs-Entwicklungssystem 10 sind auch Vorkehrungen zur Kommunikation mit Entitäten getroffen worden, die nicht durch das Automatisierungs- Entwicklungssystem 10 erzeugt wurden. Da der Warteschlangen-Server keine Kontrolle über diese Warteschlangen hat, muß ihm mitgeteilt werden, welche Namen er diesen Warteschlangen zuweisen soll. Der Warteschlangen-Server hält somit eine Tabelle oder Datei fester Schlüssel, die die Namen vordefinierter Warteschlangen und ihre entsprechenden Schlüssel oder IDs verzeichnet, und eine automatische Warteschlangentabelle, die die Warteschlangennamen und die Schlüssel der Server, die sich angemeldet haben, verzeichnet. Wenn ein Warteschlangenschlüssel in einer der Schlüsseltabellen registriert worden ist, kann auf ihn genauso wie auf irgendeine andere Warteschlange in dem System über den Namen Bezug genommen werden.
Der Warteschlangen-Server unterstützt ferner das Senden und Empfangen von Nachrichten zwischen Clients und Servern in getrennten CPUs. In jeder CPU kann ein getrenntes Automatisierungs-Entwicklungssystem jeweils mit einem Warteschlangen- Server und einem weiteren, Netz-Server genannten, Prozeß laufen. Der Warteschlangen- Server wird verwendet, um Nachrichten über ein Netz an andere CPUs zu senden, während der Netz-Server verwendet wird, um Nachrichten aus dem Netz zu empfangen und an den Bestimmungsprozeß zu senden.
Fig. 14 zeigt den Prozeß, mit dem verteilte Nachrichten geliefert werden. Ein Server A, der in der CPU1 läuft, möchte eine Nachricht an einen Server B senden, der in der CPU2 läuft:
1. Der Server A bittet den Warteschlangen-Server, wie mit dem Pfeil 301 gezeigt ist, um die Warteschlangen-ID des Servers B.
2. Da der Warteschlangen-Server den Server B nicht in der Liste der automatischen Warteschlangen findet, sucht er nach ihr in der Datei fester Schlüssel.
3. Der Warteschlangen-Server findet den Server B in der Datei fester Schlüssel und sendet den Schlüssel mit dem Warteschlangen-Wert des Warteschlangen- Servers, beispielsweise 9657, wie mit dem Pfeil 302 gezeigt ist, an den Server A.
4. Der Server A sendet, wie mit dem Pfeil 303 gezeigt ist, eine Nachricht an die Warteschlange 9657.
5. Der Warteschlangen-Server in der CPU1 empfängt die Nachricht vom Server A, bemerkt aber, daß das "to"-Tag nicht mit seinem Warteschlangen-Wert übereinstimmt.
6. Der Warteschlangen-Server sucht in einer Lenkungstabelle nach dem Server B. Die Lenkungstabelle ist vorzugsweise eine dynamische Variablenstruktur, die Namen von Prozessen und die ferne Maschine, auf denen sie vorhanden sind, enthält.
7. Der Warteschlangen-Server findet den Server B und den Namen der CPU des Servers B in der Lenkungstabelle und sendet die Nachricht, wie mit dem Pfeil 304 gezeigt ist, vom Server A über das Netz an die CPU 2.
8. Der Netzprozeß in der CPU2 empfängt, wie mit dem Pfeil 305 gezeigt ist, die Nachricht aus dem Netz.
9. Der Netzprozeß registriert den Server A, wie mit dem Pfeil 306 gezeigt ist, bei dem Warteschlangen-Server der CPU2.
10. Der Netzprozeß bittet den Warteschlangen-Server der CPU2 um die Warteschlangen-ID des Servers B. Wie mit dem Pfeil 307 gezeigt ist, gibt der Warteschlangen-Server die Warteschlangen-ID, die dem Server B beim Anmelden zugewiesen wurde, beispielsweise 5003, zurück.
11. Der Netzprozeß sendet die Nachricht, wie mit dem Pfeil 308 gezeigt ist, an den Server B.
12. Der Server B empfängt die Nachricht genauso, als ob sie von einem lokalen Prozeß gesendet worden wäre.
Neben dem Warteschlangen-Server 34 kann das integrierte Automatisierungs- Entwicklungssystem 10 auch einen Zeit-Server 36 (Fig. 1) enthalten, um zeitspezifische oder zeitabhängige Aktivitäten für Server und Clients zu koordinieren. Beispielsweise kann ein Zeitgeber verwendet werden, um alle 24 Stunden eine Wartungsbefehlsnachricht zu senden, oder er kann verwendet werden, um in 30 Sekunden eine "timeout"- Nachricht zu senden. Der Zeit-Server ist eine Server-Verbindung zu einer Uhr oder zu einer Zeitnahmeeinrichtung. Der Zeit-Server muß außerdem wie der Warteschlangen- Server im Hintergrund laufen.
Der Anlagen-Server 22 (Fig. 1) schafft Verfahren oder Server-Befehle zur Definition einer Server-Schnittstelle für einen spezifischen Fertigungsanlagentyp. Der Anlagen- Server enthält den gesamten Code oder sämtliche Befehle der Server-Shell zuzüglich weiterer Befehle, die die als Schnittstelle zu der Fertigungsanlage benötigte Funktionalität schaffen. Außer den Anlagen-Server-Befehlen, die die Definition und Verwendung eines Anlagen-Servers ermöglichen, definiert der Anlagen-Server außerdem zwei obenbeschriebene Spezialbefehle namens sxdecode und cut, die von der Fertigungsanlage empfangene SECS- und ASCII-Nachrichten verarbeiten. Ferner schafft der Anlagen- Server vorzugsweise ein Protokollieren der Daten von der Anlage.
Jedem durch einen Anlagen-Server bedienten Anlagenstück muß eine eindeutige SECS-Identifizierungsnummer oder ID zugewiesen werden. Die SECS-Anlage erfordert, daß diese ID in sämtlichen Nachrichten an die und von der Anlage angeordnet wird, so daß sie der Anlagen-Server zum Unterscheiden und Identifizieren ankommender SECS- Nachrichten nutzt. Der Anlagen-Server enthält mehrere Befehle zum Lenken, Decodieren, Codieren und Senden von SECS-Nachrichten. Wegen einer ausführlichen Diskussion der SECS-Nachrichtenformate wird auf die relevante SECS-Dokumentation verwiesen.
Der graphische Steuerungs-Client 14 aus Fig. 1 kann als ein Automatisierungs- Steuer-Server realisiert sein, der die sequentielle Funktionstafel- bzw. SFC-Schreibweise verwendet. Die SFC-Schreibweise ist aus einer internationalen Norm für die graphische Darstellung von Steuersystemen abgeleitet, die durch die International Electrotechnical Commission definiert ist. Der graphische Steuerungs-Client 14 schafft und definiert dann den Steuerungsablauf des Automatisierungs-Entwicklungssystems. Er schafft Befehle zur Definition und zum Austesten einer Steueranwendung. Die Steueranwendungsdefinition wird daraufhin verwendet, um die Server und Clients in dem System zu koordinieren, so daß sie die Anwendung ausführen.
Um Schnittstellenfunktionen mit anderen Entitäten wie etwa Datenbanken auszuführen, können in dem integrierten Automatisierungs-Entwicklungssystem 10 auch andere Server-Prozesse realisiert werden. Um die Integration zu erleichtern, können Server wie etwa ein Austest-Server, der bestimmte Aktionen und Funktionen überwacht, um eine Fehlcodierung in dem System zu erfassen, ein Gesprächs-Server, der Entwicklern eine Befehlszeilenschnittstelle zu sämtlichen anderen Servern in dem System liefert, und ein SFC-Editor, der SFC-Editierfähigkeiten schafft, realisiert sein. Wie oben diskutiert wurde, werden alle diese Server durch Hinzufügen von anwendungsspezifischen Befehlen zu dem Grund-Code und zu den Grund-Befehlen der Server-Shell 42 (Fig. 2) realisiert, so daß die zugrundeliegende Steuerungsablauflogik, das Nachrichten-Management, das Befehlsmanagement, die Skript-Interpretation und das Management der dynamischen Variablen bereits vorhanden sind. Somit wird die Automatisierungsintegration erleichtert, während die Realisierung und Abwandlungen schneller erfolgen können.

Claims

1. Integriertes Automatisierungs-Entwicklungssystem (10) zum Steuern und Koordinieren einer Fertigungsanlage, wobei das System mehrere Server-Prozesse (16, 22, 28) umfaßt, wovon jeder enthält:

einen Nachrichten-Manager (45), der von den mehreren Server-Prozessen ASCII- Nachrichten empfängt, wobei der Nachrichten-Manager (45) Mittel zum Ausführen von kommunikationsbezogenen Tasks umfaßt;

einen Sprachen-Interpretierer (43), der Mittel umfaßt, die für eine veränderliche Anzahl der Server-Prozesse die empfangenen ASCII-Nachrichten, die Befehle enthalten, die in einer textbasierten Programmiersprache ausgedrückt sind, bewerten, wobei der Interpretierer (43) Mittel umfaßt, die die Befehle in den ASCII-Nachrichten erkennen;

einen Befehls-Manager (41), der die Befehle empfängt und ausführt, wobei der Befehls-Manager (41) Mittel, die die Ausführung der Befehlsanforderungen managen und steuern, Mittel für die Datenspeicherung sowie Mittel für die Ereignisprotokollierung umfaßt; und

einen Logik-Controller (47), der das Management des logischen Ablaufs der Befehlsausführung durch den Befehls-Manager (41) ausführt.

2. Integriertes Automatisierungs-Entwicklungssystem nach Anspruch 1, in dem der Interpretierer (43) dynamische Variablen in den empfangenen ASCII-Nachrichten erkennt, wobei die dynamischen Variablen hierarchisch strukturiert sind und dazu verwendet werden, während der Befehlsausführung durch den Befehls-Manager (41) Datenwerte zu speichern oder Werte, die vom Befehls-Manager (41) für die Befehlsausführung benötigt werden, zu liefern.

3. Integriertes Automatisierungs-Entwicklungssystem nach Anspruch 1 oder Anspruch 2, in dem der Logik-Controller (47) den Befehls-Manager (41) anweist, ankommende Nachrichten zu prüfen, die Nachrichten zu analysieren, die Befehle in den Nachrichten zu ermitteln, die Syntax der Befehle zu prüfen, die Befehle auszuführen und eine Antwortnachricht zu erzeugen, und in dem der Logik-Controller (47) ferner den Nachrichten-Manager anweist, die Antwortnachricht zu senden.

4. Integriertes Automatisierungs-Entwicklungssystem nach einem vorhergehenden Anspruch, in dem der Befehls-Manager (41) ein anwenderspezifischer Befehls-Manager ist, der anwendungsspezifische Befehle ausführt, um die Fertigungsanlage zu steuern und eine Schnittstelle mit dieser zu bilden, und in dem der Logik-Controller (47) den anwendungsspezifischen Befehls-Manager anweist, ankommende Nachrichten zu prüfen, die Nachrichten zu analysieren, das Format der Nachrichten als SECS-Nachrichten (SEMI Equipment Communications Standard-Nachrichten) zu identifizieren, die SECS- Nachrichten zu verarbeiten und die Prüfung der Nachrichten fortzusetzen.

5. Integriertes Automatisierungs-Entwicklungssystem nach einem vorhergehenden Anspruch, in dem der Befehls-Manager (41) ein anwendungsspezifischer Befehls- Manager ist, der anwendungsspezifische Befehle ausführt, um das Management der Nachrichtenlenkung zwischen den Server-Prozessen auszuführen.

6. Integriertes Automatisierungs-Entwicklungssystem nach Anspruch 5, in dem der anwendungsspezifische Befehls-Manager (41) eine Liste vorhandener Server-Prozeß- Namen und entsprechender Nachrichtenwarteschlangen-Adressen hält.

7. Integriertes Automatisierungs-Entwicklungssystem nach einem vorhergehenden Anspruch, in dem der Befehlsmanager (41) anwendungsspezifische Befehle zur Schaffung einer Schnittstelle mit einem Anwender-Terminal ausführt.

8. Integriertes Automatisierungs-Entwicklungssystem nach einem der Ansprüche 1 bis 6, in dem der Befehls-Manager (41) anwendungsspezifische Befehle zur Schaffung einer Schnittstelle mit einem Host-Fertigungscomputersystem ausführt.

9. Integriertes Automatisierungs-Entwicklungssystem nach einem vorhergehenden Anspruch, ferner mit einem Steuerungs-Client (14), der Nachrichten erzeugt;

einem Terminal-Server (28), der mit einem Entwicklerschnittstellen-Terminal gekoppelt ist, um den Entwicklereingang zu empfangen und den Systemstatus anzuzeigen, wobei der Terminal-Server (28) Nachrichten erzeugt und empfängt; und

einen Warteschlangen-Server (34), der die Lenkung der Nachrichten zwischen dem Steuerungs-Client (14), dem Anlagen-Server (22) und dem Terminal-Server (28) ermöglicht.

10. System nach einem vorhergehenden Anspruch, in dem der Interpretierer (43) ferner in den ASCII-Nachrichten dynamische Variablen erkennt, wobei die dynamischen Variablen hierarchisch strukturiert sind und dazu verwendet werden, während der Befehlsausführung durch den Befehls-Manager (41) Datenwerte zu speichern oder Werte, die vom Befehls-Manager (41) für die Befehlsausführung benötigt werden, zu liefern.

11. System nach Anspruch 9 oder Anspruch 10, in dem jeder Client und jeder der Server-Prozesse ferner eine Nachrichtenwarteschlange umfaßt, um ASCII-Nachrichten zu empfangen, und in dem der Logik-Controller (47) den Befehls-Manager (41) anweist, die Nachrichtenwarteschlange auf ankommende Nachrichten zu prüfen, die Nachrichten zu analysieren, das Format der Nachrichten zu identifizieren, die Nachrichten als Antwort auf das identifizierte Format der Nachrichten zu verarbeiten und die Prüfung der Nachrichtenwarteschlange auf Nachrichten fortzusetzen.

12. Verfahren zur Integration eines Automatisierungs-Entwicklungssystems für die Steuerung und die Koordination einer Fertigungsanlage unter Verwendung mehrerer Server-Prozesse, wovon jeder umfaßt:

einen Logik-Controller (47), der das Management des logischen Ablaufs der Befehlsausführung durch den Befehls-Manager (41) ausführt,

wobei das Verfahren die folgenden Schritte umfaßt:

Prüfen auf und Empfangen von ASCII-Nachrichten von anderen Server- Prozessen;

Bewerten der empfangenen Nachrichten, die wenigstens einen Befehl enthalten, der in einer textbasierten Programmiersprache ausgedrückt ist, für eine veränderliche Anzahl der Server-Prozesse und Erkennen der Befehle in den ASCII-Nachrichten;

Ausführen der Befehle; und

Fortsetzen der Prüfung auf weitere ASCII-Nachrichten.

13. Verfahren nach Anspruch 12, ferner mit den Schritten des Erkennens dynamischer Variablen in den empfangenen ASCII-Nachrichten, des hierarchischen Strukturierens der dynamischen Variablen und des Verwendens der dynamischen Variablen, um Datenwerte während der Befehlsausführung zu speichern oder Werte, die für die Befehlsausführung benötigt werden, zu liefern.

14. Verfahren nach Anspruch 12 oder Anspruch 13, ferner mit den Schritten des Analysierens der ASCII-Nachrichten, des Ermittelns der Befehle in den ASCII- Nachrichten, des Prüfens der Syntax der Befehle, des Ausführens der Befehle, des Erzeugens einer Antwortnachricht und des Richtens der Antwortnachricht an ein geeignetes Ziel.

15. Verfahren nach einem der Ansprüche 12 bis 14, ferner mit den Schritten des Prüfens einer Nachrichtenwarteschlange auf ankommende Nachrichten, des Analysierens der Nachrichten, des Identifizierens des Formats der Nachrichten, des Verarbeitens der Nachrichten als Antwort auf das identifizierte Nachrichtenformat und des Fortsetzens der Prüfung der Nachrichtenwarteschlange auf Nachrichten.

16. Verfahren nach einem der Ansprüche 12 bis 15, ferner mit den Schritten des Ausführens anwendungsspezifischer Befehle zum Steuern und zum Bilden einer Schnittstelle mit der Fertigungsanlage, des Prüfens auf ankommende Nachrichten, des Analysierens der Nachrichten, des Identifizierens des Formats der Nachrichten als SECS-Nachrichten (SEMI Equipment Communications Standard-Nachrichten), des Verarbeitens der SECS- Nachrichten und des Fortsetzens der Prüfung auf Nachrichten.

17. Verfahren nach einem der Ansprüche 12 bis 16, ferner mit den Schritten des Ausführens anwendungsspezifischer Befehle zur Ausführung des Managements der Nachrichtenlenkung zwischen den Server-Prozessen und des Haltens einer Liste vorhandener Server-Prozeß-Namen und entsprechender Nachrichtenwarteschlangen-Adressen.