DE19910863A1 - Vorrichtung und Verfahren zum Verarbeiten von Aufträgen - Google Patents

Abstract

Herkömmliche verteilte Prozessorsysteme weisen eine Vielzahl von Prozessoreinheiten auf, auf denen ein Standardprotokoll für die sicherheitstechnischen Abläufe von jedem Schnittstellenpartner eigenständig implementiert werden müssen. Das kann zu Fehlern der Meldekette führen. Der Erfindung liegt daher die Aufgabe zugrunde, die Zuverlässigkeit zu erhöhen. Mit der Erfindung werden außerdem die Vorteile eines festen Protokollrahmens, eines systemweit definierten Verhaltens bei Verletzung des Job-Protokolls und eine robuste Software, d. h. eine einfache Wartung und hohe Testeffizienz, erreicht. DOLLAR A Erfindungsgemäß umfassen die Prozessoreinheiten (8-24) erste und zweite Mittel zum Empfangen und Bearbeiten von Nachrichten, wobei die ersten Mittel Teil des Anwendungsprogramms sind und die zweiten Mittel anwendungsunabhängig und in allen Prozessoreinheiten in gleicher Weise vorhanden sind. Das erfindungsgemäße Verfahren umfaßt den Schritt des Bearbeitens einer empfangenen Nachricht auf anwendungsunabhängige und für alle Prozessoreinheiten gleiche Weise. DOLLAR A Telekommunikation, insbesondere Vermittlungsstellen, insbesondere ATM-Systeme.

Description

Die Erfindung bezieht sich auf eine Vorrichtung und ein Verfahren zum Verarbeiten von Aufträgen und insbesondere auf eine Vielzahl von Prozessoreinheiten, die untereinander Nachrichten austauschen.

In der Telekommunikation kommen verteilte Prozessorsysteme für echtzeitkritische Anwendungen zum Einsatz. Diesen Prozessorsystemen liegt eine Softwarearchitektur zugrunde, die multitaskingfähig sein muß, d. h. es den Prozessoren ermöglicht, den auf sie wirkenden Anreizen und Anforderungen gleichzeitig und in Echtzeit gerecht zu werden.

Solche Systeme empfangen Anreize bzw. Anforderungen von außen beispielsweise über Schnittstellenkarten. Diese Anreize werden dann innerhalb des Systems für die Weiterverarbeitung verteilt. Diese reine Informationsweiterleitung macht einen Anteil von etwa 30% des internen Prozeßkommunikationsaufkommens aus.

Der restliche Anteil von ca. 70% dient der Unterstützung sicherheitstechnischer Abläufe. Darunter sind beispielsweise standardisierte Quittungsmeldungen, Wiederholungen von Nachrichten und Überwachungsmeldungen zu verstehen, die dazu dienen, die Kommunikationssicherheit zu erhöhen. Dadurch können Software- und Hardwarefehler, wie beispielsweise Ausfälle einzelner oder mehrerer Prozessorplattformen schnell erkannt werden. Dies optimiert die System-Antwortzeit und erhöht die Leistungsfähigkeit und Robustheit eines Systems.

In herkömmlichen Systemen muß von jedem Kommunikationspartner in seiner eigenen Anwendung das Empfangen, Senden und Bearbeiten von Quittungsmeldungen, Nachrichtenwiederholungen, Überwachungsmeldungen etc. unterstützt werden. Dies setzt ein Standardprotokoll voraus, das von jedem Schnittstellenpartner eigenständig implementiert werden muß. Da die im System verteilten Prozessoren auf verschiedenen und verschiedenartigen Plattformen liegen können, unterschiedlichen Anwendungen unterworfen sein können und in verschiedenen Client-Server-Konstellationen eingerichtet sein können, läßt sich eine fehlerfreie Meldekette unter Umständen nicht erzielen, denn eine fehlerfreie Meldekette setzt ein gleichartiges Verhalten der einzelnen Partner voraus.

Der Erfindung liegt daher die Aufgabe zugrunde, eine Vorrichtung und ein Verfahren zur Verarbeitung von Aufträgen mit größerer Zuverlässigkeit anzugeben.

Diese Aufgabe wird erfindungsgemäß durch die Gegenstände der Patentansprüche 1 und 18 gelöst.

Die anwendungsunabhängige und für alle Prozessoreinheiten in gleicher Weise erfolgende Bearbeitung einer Nachricht hat zunächst den Vorteil, daß dem Benutzer eine Realisierung von Standardabläufen in einem festen Protokollrahmen angeboten werden kann. Dies ermöglicht es, daß der sicherheitstechnische Aufwand bei der Implementierung einer Anwendung verringert wird. Dieser Aufwand übersteigt bei Verwendung herkömmlicher Vorrichtungen und Verfahren in der Regel den Aufwand für die eigentliche Implementierung anwenderbezogene Aktionen.

Zusätzlich wird durch die anwendungsunabhängige und in allen Prozessoreinheiten in gleicher Weise erfolgende Bearbeitung von Nachrichten ein systemweit definiertes Verhalten bei Verletzung des Protokolls gewährleistet, z. B. beim Ausbleiben von Quittungen oder Progreßreports und bei gezieltem Abbrechen von Anforderungen. Dies birgt den weiteren Vorteil in sich, daß die Systemantwortzeit weiter optimiert wird.

Darüber hinaus wird erfindungsgemäß in vorteilhafter Weise eine Vorrichtung und ein Verfahren geschaffen, die eine effiziente Wartung ermöglichen, da sicherheitstechnische Abläufe nicht mehr durch die einzelnen Anwendungsprogramme erledigt werden. Dies ermöglicht eine Wartung an zentraler Stelle, ohne daß die einzelnen Anwendungen erneut implementiert werden müssen.

Schließlich läßt sich gegenüber herkömmlichen Systemen in kürzerer Zeit eine hohe Robustheit der sicherheitstechnischen Abläufe in dem verteilten Prozessorsystem erreichen, da erfindungsgemäß für diese Abläufe anwendungsunabhängige Routinen verwendet werden, die in allen Prozessoreinheiten in gleicher Weise vorhanden sind und daher von den einzelnen Benutzern immer wieder getestet und ggf. korrigiert werden.

Bevorzugte Ausführungen der Erfindung sind in den Unteransprüchen definiert.

Die Erfindung wird im folgenden anhand von bevorzugten Ausgestaltungen unter Zuhilfenahme der Figuren näher erläutert, in denen:

Fig. 1 ein verteiltes Prozessorsystem darstellt, auf das die Erfindung Anwendung findet;

Fig. 2 ein Zeitprotokoll der Verarbeitung eines Auftrages zeigt; und

Fig. 3 ein Flußdiagramm ist, das eine Prozeßstruktur darstellt.

In der Fig. 1 ist eine vorteilhafte Ausgestaltung eines verteilten Prozessorsystems dargestellt. Eine Anzahl n von Prozessorplattformen 2, 4, 6 umfaßt jeweils eine Vielzahl von Prozessoreinheiten 8-24, die eine Anzahl m von Prozessen auf jeder Plattform ausführen kann. Die Prozessoreinheiten sind vorteilhafterweise in Client-Server-Konfiguration ausgeführt.

Bevorzugterweise weisen die Plattformen eine gleiche oder ähnliche Konfiguration auf. Sie können aber auch von grundsätzlich anderer Gestalt sein. Beispielsweise kann die Zahl von Prozessoreinheiten pro Plattform stark variieren. Auch können die Prozessoren verschiedener Plattformen sowie verschiedener Prozessoreinheiten einer Plattform baugleich, aber auch von verschiedener Konstruktion sein.

Die Prozessoreinheiten werden vorzugsweise durch virtuelle Prozessoren von dem Betriebssystem bereitgestellt. Dabei läuft nur ein Prozess auf einem virtuellem Prozessor ab.

Diese Technik, einen physikalischen Prozessor in mehrere virtuelle Prozessoren aufzuteilen, findet in multitasking­ fähigen Betriebssystemen Anwendung. Vorzugsweise laufen daher mehrere oder alle Prozesse nach einem Multitaskingprinzip in Echtzeit. Schnittstellenkarten werden in der Regel mit einem Prozessor aufgebaut, der aufgrund von sicherheitstechnischen Maßnahmen auch gedoppelt sein kann (Redundanz).

In einem bevorzugten Ausführungsbeispiel wird das in Fig. 1 dargestellte verteilte Prozessorsystem zur Verarbeitung von Aufträgen im Gebiet der Telekommunikation verwendet.

Vorzugsweise ist das verteilte Prozessorsystem von Fig. 1 Teil einer Vermittlungsstelle. Eine besonders vorteilhafte Ausführungsform einer solchen Vermittlungsstelle ist ein solches System, das den ATM-Standard unterstützt.

Generell läßt sich das in Fig. 1 dargestellte verteilte Prozessorsystem auch für andere Formen der Gerätesteuerung verwenden. Dabei werden die Prozesse vorteilhafterweise als Software implementiert.

Wie in Fig. 1 dargestellt ist, erhält der Server S der Prozessoreinheit 8 ein Triggersignal. Dieses Signal kann ein Anreiz bzw. eine Anforderung von außen sein, kann aber auch das Ausgangssignal einer anderen Plattform darstellen. In dem in Fig. 1 dargestellten Beispiel wird der Informationsgehalt dieses empfangenen Anreizes über den Client der Prozessoreinheit 8 an den Server der Prozessoreinheit 10 und in gleicher Weise an die Prozessoreinheiten 14 und 16 der Plattform 4 weitergeleitet. Dadurch entsteht eine Meldekette.

In Fig. 2 ist ein Beispiel eines Zeitprotokolls einer Auftragsabwicklung in einem der in Fig. 1 dargestellten Server gezeigt. Wie aus der Figur ersichtlich, verfügt der Server über generische Routinen 30, 34, 36, 38, 42 und spezifische Routinen 32, 40. Dabei sind spezifische Routinen Teil des Anwendungsprogramms und generische Routinen solche, die anwendungsunabhängig und für alle Prozessoreinheiten in gleicher Weise vorhanden sind.

Erhält der Server vom Client oder mittels eines Triggersignals einen Auftrag bzw. einen Job, so wird im Server eine generische Routine 30 zur Quittierung dieses Auftrages ausgeführt. In der Folge sendet der Server eine Quittung bzw. ein Acknowledgement an den Client zurück. Unabhängig von dieser generischen Routine verarbeitet eine anwendungsspezifische Routine 32 den Auftrag.

Diese spezifische Bearbeitung kann in der Weiterleitung des Auftrages an einen anderen Client liegen. Eine Kommunikation findet in diesem Fall zwischen einem Client und einem Server statt. Bei einer Weiterleitung eines Auftrags nimmt der ursprüngliche Server (Auftragseingang) die Position des Clients ein. Von dieser Position aus wird der Auftrag an einen weiteren Server geschickt. Dabei nimmt ein Kommunikationspartner bei Weiterleitung eines Auftrags immer beide Positionen (Server/Client) ein.

Kommt als Antwort auf den weitergeleiteten Auftrag eine Quittung zurück, so wird eine generische Routine 34 zur Quittierungsüberwachung gestartet. Diese Routine stellt standardmäßig fest, ob die Quittung von ihrem Informationsgehalt her sowie bezüglich ihrer Empfangszeit den Anforderungen des Protokolls genügt. Ist dies der Fall, so wird die generische Routine 34 beendet.

Ein weiterer Umstand kann auftreten, wenn von einer überwachten Schnittstelle ein Bericht bzw. ein Progreßreport zurückgeschickt wird. Der Server nimmt dann die Position des Clients ein, um Aufträge weiterzuleiten, und der (Ziel-) Server schickt einen Bericht bzw. einen Prozeßreport an den Client zurück. In diesem Falle führt der Client eine generische Routine 36 zur Schnittstellenüberwachung aus. Diese generische Routine quittiert zunächst den empfangenen Bericht und überprüft sodann, ob Informationsgehalt und Zeitrahmen des Progreßreports einer Reaktion bedürfen. Ist dies nicht der Fall, so wird die generische Routine 36 zur Schnittstellenüberwachung beendet.

Trifft ein Ergebnis beim Client ein, so führt der Client zunächst eine generische Routine 38 zur Quittierung dieser Ergebnisnachricht aus. Eine derartige Ergebnisnachricht besteht vorzugsweise in der Benachrichtigung darüber, daß der Auftrag vom Empfänger ordnungsgemäß ausgeführt worden ist. Im Falle eine Fehlers enthält die Ergebnisnachricht ggf. eine Fehlermeldung. Nachdem die generische Routine 38 die Ergebnisnachricht quittiert hat, wird das Ergebnis an den vorhergehenden Kommunikationspartner weitergereicht, d. h. vom Server zum Client. Dabei wird intern die Ergebnisnachricht, zuvor aufgenommen vom Client, an die Serverschnittstelle weitergeleitet. Es wird eine spezifische Routine 40 ausgeführt, die die Ergebnisnachricht im Sinne des Anwendungsprogramms bearbeitet. Vorzugsweise wird die spezifische Routine die Ergebnisnachricht an den Vorläuferclient weiterleiten.

Beim Verschicken der Ergebnisnachricht wird eine generische Routine 42 zur Quittierungsüberwachung, die vorzugsweise der Routine 34 entspricht, gestartet. Schließlich empfängt der Server von dem Client, der die Ergebnisnachricht empfangen hat, eine Quittung und beendet daraufhin die Quittierungsüberwachung.

Die generischen Routinen 30, 34, 36, 38, 42 können als Teil eines generischen Job-Handlers betrachtet werden, der dem Anwendungsprogramm die Abarbeitung von Standardabläufen erleichtert, indem der Job-Handler Anreize bzw. Ereignisse verarbeitet und entsprechende Standardabläufe vorgibt. Wie an dem in Fig. 2 gezeigten Beispiel gesehen werden kann, führt der generische Job-Handler nach Empfang einer Nachricht automatisch eine Quittierung an den Kommunikationspartner aus.

Vorzugsweise wird der generische Job-Handler weitere generische Routinen enthalten, die beispielsweise das Senden einer Nachricht wiederholen, wenn eine Quittung ausbleibt. Eine solche Routine wird vorzugsweise von den generischen Routinen 34, 42 zur Quittierungsüberwachung gestartet.

Vorzugsweise enthält der generische Job-Handler auch eine Routine zur Abbruchbehandlung, die von den generischen Routinen 34, 42 zur Quittierungsüberwachung gestartet werden können, wenn eine Quittung ausbleibt und eine wiederholte Sendung der Ursprungsnachricht nicht sinnvoll oder vom Anwendungsprogramm nicht gewünscht ist.

Wie der Fig. 2 entnommen werden kann, führt der Server sowohl generische als auch spezifische Routinen aus, wobei die zeitlichen Abläufe der Routinen ineinandergreifen können. In dem in Fig. 2 gezeigten Beispiel wird eine Routine zunächst beendet, bevor eine weitere Routine ausgeführt wird. Es können jedoch auch mehrere Routinen gleichzeitig, d. h. im Multitaskingbetrieb, ausgeführt werden, wobei dann Teile verschiedener Routinen ineinandergreifen.

Zu diesem Zweck wird der generische Job-Handler anwenderneutral gehalten, während anwenderspezifische Daten in einer sogenannten Instanzierung deklariert bzw. definiert werden. Unter Instanzierung wird in diesem Zusammenhang die Erzeugung einer computerinternen Datenstruktur zur Repräsentation eines Objektes auf der Basis einer generischen Beschreibung verstanden. Dabei werden die Eigenschaften der generischen Beschreibung im allgemeinen auf das konkrete Objekt, die Instanz, übertragen.

Die Schnittstelle zwischen dem Anwender und dem generischen Job-Handler bildet eine sogenannte DO-Liste, die allgemein­ gültige Anweisungen enthält. Mit ihrer Hilfe wird der Anwender in die Lage versetzt, Standardabläufe, die durch den generischen Job-Handler vorgegeben sind, in seiner Anwendung spezifisch umzusetzen. Ein Beispiel hierfür wird anhand von Fig. 3 erläutert.

Nach dem Start des Anwendungsprogramms unter Bezugszeichen 50 wird die Nachricht von einer spezifischen Routine 52 empfangen. Anschließend erstellt eine spezifische Routine 54 eine DO-Liste, die allgemeingültige Anweisungen enthält, wie die Quittierung, die Wiederholung von Nachrichten oder die Überwachung von Server-Schnittstellen durch Progreßreports. Die spezifische Routine 56 führt die anwenderneutral gehaltene DO-Liste aus. In der generischen Routine 58 wird verglichen, ob die Anweisungen in der DO-Liste erfolgreich ausgeführt werden konnten. Nur die erfolgreich ausgeführten Anweisungen (DONE-LISTE) werden aus der DO-Liste gestrichen. Anschließend fragt eine generische Routine 60 ein READY- Register ab. Im Falle, daß dieses Register existiert, was unter Bezugszeichen 62 geprüft wird, wird von einer spezifischen Routine 64 der Auftrag gemäß dem READY-Register erledigt. Anschließend vergleicht eine generische Routine 66 wiederum die DO-Liste mit der DONE-Liste und paßt die DONE- Liste entsprechend an.

Die in den Fig. 2 und 3 dargestellten Routinen sind vorzugsweise reine Softwarelösungen.

Claims (34)

1. Vorrichtung zur Verarbeitung von Aufträgen, umfassend eine Vielzahl von Prozessoreinheiten (8-24), die untereinander Nachrichten austauschen und jeweils wenigstens ein Anwendungsprogramm ausführen, das der Verarbeitung der Aufträge dient, wobei die Prozessoreinheiten enthalten:
erste Mittel (32, 40) zum Bearbeiten empfangener Nachrichten, wobei die ersten Mittel Teil des Anwendungsprogramms sind, und
zweite Mittel (30, 34, 36, 38, 42) zum Bearbeiten empfangener Nachrichten, wobei die zweiten Mittel anwendungsunabhängig und in allen Prozessoreinheiten in gleicher Weise vorhanden sind.

2. Vorrichtung nach Anspruch 1, wobei die Vorrichtung eine Vermittlungsstelle ist.

3. Vorrichtung nach Anspruch 2, wobei die Vermittlungsstelle eine ATM-Vermittlungsstelle ist.

4. Vorrichtung nach einem der Ansprüche 1 bis 3, wobei die Aufträge in Echtzeit von den Prozessoreinheiten im Multitasking-Betrieb verarbeitet werden.

5. Vorrichtung nach einem der Ansprüche 1 bis 4, wobei die Prozessoreinheiten eine Client-Server-Konfiguration aufweisen.

6. Vorrichtung nach einem der Ansprüche 1 bis 5, wobei die Aufträge einer Gerätesteuerung dienen.

7. Vorrichtung nach einem der Ansprüche 1 bis 6, wobei die zweiten Mittel sicherheitstechnische Standardabläufe ausführen.

8. Vorrichtung nach Anspruch 7, wobei die sicherheitstechnischen Standardabläufe das Absenden von Quittungen enthalten.

9. Vorrichtung nach Anspruch 7 oder 8, wobei die sicherheitstechnischen Standardabläufe das Empfangen und Absenden von Progreßreports zur Überwachung einer Schnittstelle umfassen.

10. Vorrichtung nach einem der Ansprüche 7 bis 9, wobei die sicherheitstechnischen Abläufe das Weiterleiten einer Nachricht umfassen.

11. Vorrichtung nach einem der Ansprüche 7 bis 10, wobei die sicherheitstechnischen Abläufe eine Fehlerbehandlung umfassen.

12. Vorrichtung nach Anspruch 11, wobei die Fehlerbehandlung ein frühzeitiges Abbrechen eines Auftrages bei einem Fehler veranlaßt.

13. Vorrichtung nach Anspruch 11 oder 12, wobei die Fehlerbehandlung die Wiederholung der Sendung einer Nachricht bei einem Fehler vornimmt.

14. Vorrichtung nach einem der Ansprüche 1 bis 13, wobei anwenderspezifische Daten in einer Instanzierung mittels einer DO-Liste, die allgemeingültige Anweisungen enthält, deklariert werden.

15. Vorrichtung nach einem der Ansprüche 1 bis 14, wobei die ersten und zweiten Mittel die Bearbeitung von Nachrichten zeitlich ineinandergreifend vornehmen.

16. Vorrichtung nach einem der Ansprüche 1 bis 15, wobei die ersten und/oder zweiten Mittel als Software implementiert sind.

17. Vorrichtung nach einem der Ansprüche 1 bis 16, wobei die Prozessoreinheiten als virtuelle Prozessoren implementiert sind.

18. Verfahren zum Verarbeiten von Aufträgen durch eine Vorrichtung mit einer Vielzahl von Prozessoreinheiten (8-24), die untereinander Nachrichten austauschen und jeweils wenigstens ein Anwendungsprogramm ausführen, das der Verarbeitung der Aufträge dient, mit den folgenden Schritten:
Empfangen (52) einer Nachricht in einer Prozessoreinheit,
Bearbeiten (54) der Nachricht auf anwendungsunabhängige und für alle Prozessoreinheiten gleiche Weise, und
Bearbeiten (56, 64) der Nachricht durch das Anwendungsprogramm.

19. Verfahren nach Anspruch 18, wobei die Prozessoreinheiten Teil einer Vermittlungsstelle sind.

20. Verfahren nach Anspruch 19, wobei die Vermittlungsstelle eine ATM-Vermittlungsstelle ist.

21. Verfahren nach einem der Ansprüche 18 bis 20, wobei die Aufträge in Echtzeit von den Prozessoreinheiten im Multitaskingbetrieb verarbeitet werden.

22. Verfahren nach einem der Ansprüche 18 bis 21, wobei die Prozessoreinheiten eine Client-Server-Konfiguration aufweisen.

23. Verfahren nach einem der Ansprüche 18 bis 22, wobei die Aufträge einer Gerätesteuerung dienen.

24. Verfahren nach einem der Ansprüche 18 bis 23, wobei die anwendungsunabhängige Bearbeitung von Nachrichten sicherheitstechnischen Standardabläufen dient.

25. Verfahren nach Anspruch 24, wobei die sicherheitstechnischen Standardabläufe das Senden von Quittungen umfaßt.

26. Verfahren nach Anspruch 24 oder 25, wobei die sicherheitstechnischen Standardabläufe das Empfangen und Senden von Progreßreports zur Überwachung einer Schnittstelle umfassen.

27. Verfahren nach einem der Ansprüche 24 bis 26, wobei die sicherheitstechnischen Standardabläufe das Weiterleiten einer Nachricht umfassen.

28. Verfahren nach einem der Ansprüch 24 bis 27, wobei die sicherheitstechnischen Standardabläufe eine Fehlerbehandlung umfassen.

29. Verfahren nach Anspruch 28, wobei die Fehlerbehandlung das frühzeitige Abbrechen eines Auftrages bei einem Fehler umfaßt.

30. Verfahren nach Anspruch 28 oder 29, wobei die Fehlerbehandlung das wiederholte Senden einer Nachricht bei einem Fehler umfaßt.

31. Verfahren nach einem der Ansprüche 18 bis 30, wobei im Schritt des Bearbeitens der Nachricht durch das Anwendungsprogramm anwenderspezifische Daten in einer Instanzierung mittels einer DO-Liste, die allgemeingültige Anweisungen enthält, deklariert werden.

32. Verfahren nach einem der Ansprüche 18 bis 31, wobei die anwendungsunabhängige Bearbeitung und die Bearbeitung durch das Anwendungsprogramm zeitlich ineinandergreifend erfolgen.

33. Verfahren nach einem der Ansprüche 18 bis 32, wobei die Nachrichten softwaremäßig bearbeitet werden.

34. Verfahren nach einem der Ansprüche 18 bis 32, wobei die Nachricht von virtuellen Prozessoren bearbeitet wird.