DE9300562U1

DE9300562U1 - Steuerungssystem eines Vermittlungssystems

Info

Publication number: DE9300562U1
Application number: DE9300562U
Authority: DE
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 1992-08-27
Filing date: 1993-01-18
Publication date: 1993-03-04
Anticipated expiration: 2003-01-19
Also published as: US5513355A; CA2104804A1; CA2104804C

Description

G 1 5 k 7 DE O 1

Siemens Aktiengesellschaft

Steuerungssystem eines Vermittlungssystems

Die Leistungsfähigkeit und Weiterentwicklungsfähigkeit bzw. Veränderbarkeit eines Vermittlungssystems sind in starkem Maße von der Flexibilität des Steuerungssystems abhängig.

Der Erfindung liegt die Aufgabe zu Grunde, ein flexibles Steuerungssystem eines Vermittlungssystems anzugeben.

Diese Aufgabe wird durch die Merkmale des Anspruchs 1 gelöst.

Mit Hilfe des erfindungsgemäßen Dienstemanagementsystems können die Dienstleistungsmodule einen Dienst bzw. genauer gesagt einen Kommunikationspfad zu einem Dienst nunmehr in einfacher Weise durch Angabe des Namens des Dienstes anfordern, ohne seinen Ort innerhalb des Steuerungssystems zu kennen. Eine Kommunikationsbeziehung zwischen einem aufrufenden Dienst und einem aufgerufenen Dienst wird somit dynamisch aufgebaut. Damit ist die Grundlage für eine unproblematische Veränderbarkeit der Konfiguration des Steuerungssystems während des Betriebs geschaffen.

Eine Ausgestaltung der Erfindung ist durch Anspruch 2 angegeben. Durch diese Ausgestaltung ist es möglich, das Steuerungssystem dynamisch aufzurüsten oder zu erweitern. Des weiteren können bei dieser Ausgestaltung alte Dienstleistungsmodule dynamisch aus dem System entfernt werden, indem die Schritte zur Installation neuer Dienstleistungsmodule in umgekehrter Richtung angewandt werden.

Eine weitere Ausgestaltung der Erfindung ist durch Anspruch 3 angegeben. Durch diese Ausgestaltung ist es möglich, die örtliche Verteilung der installierten Dienstleistungsmodu-

G 1 5 hl DE O 1

le dynamisch zu verändern, indem die Dienstleitungsmodule auf die neuen Orte vervielfältigt werden, während die Dienstleistungsmodule auf dem ursprünglichen Ort außer Betrieb genommen werden.

Eine weitere Ausgestaltung der Erfindung ist durch Anspruch A angegeben. Bei dieser Ausgestaltung wird zum einen eine gleichmäßigere Verteilung der Last zwischen den Verarbeitungsplattformen des Steuerungssystems erreicht und zum anderen eine größere Unabhängigkeit bezüglich des Ausfalls bzw. Außerbetriebnehmen eines Dienstleistungsmoduls erreicht.

Eine weitere Ausführungsform der Erfindung ist durch Anspruch 5 angegeben. Durch diese Ausführungsform wird eine asynchrone Kommunikation zwischen dem aufrufenden Dienstleistungsmodul und dem aufgerufenen Dienstleistungsmodul ermöglicht.

Eine weitere Ausführungsform der Erfindung ist durch Anspruch 6 angegeben. Durch diese Ausführungsform wird eine synchrone Kommunikation zwischen dem aufrufenden Dienstleistungsmodul und dem aufgerufenen Dienstleistungsmodul ermöglicht.

Eine weitere Ausgestaltung der Erfindung ist durch Anspruch 7 angegeben. Durch die für eine Dienstleistungskapsel mögliche individuelle Zuteilung von Betriebsmitteln kann erreicht werden, daß die Betriebsmittel für solche Funktionen, die für die Integrität und den Betrieb des Systems notwendig sind, in ausreichendem Maße gegenüber solchen Funktionen reserviert werden, die weniger dringend sind und viele Betriebsmittel benötigen (z.B. Verkehrsmessung)

G 1 5WDE 01

Im folgenden wird die Erfindung anhand der Zeichnung näher erläutert.

FIG 1 zeigt ein Schalenmodell für Verarbeitungsplattformen mit System- und Anwendungs-Software, FIG 2 zeigt die Anforderung eines bestimmten Dienstes durch einen entsprechenden Aufruf an das Dienstemanagementsystem des Betriebssystems,
FIG 3 zeigt die Kommunikation zwischen zwei Dienstinstanzen

mit Hilfe von Meldungen,

FIG 4 zeigt die Kommunikation zwischen zwei Dienstinstanzen mit Hilfe von Remote-Prozedur-Aufrufen, FIG 5 zeigt die Dienstetabelle sowie den Ablauf zur Veränderung der Dienstetabelle.

FIG 1 zeigt ein Schalenmodell für Verarbeitungsplattformen eines Steuerungssystems, das folgende Schalen aufweist: Eine erste Schale, die der Hardware der betrachteten drei Verarbeitungsplattformen entspricht,

einer zweiten Schale, die der Firmware (Urlader, Hardware-Schnittstelle, Fehlererkennung, usw.) der Verarbeitungsplattformen entspricht,

eine dritte Schale, die der Betriebssystem-Software (Betriebssystemkern, Fehlerbehandlung) entspricht,

eine vierte Schale, die der Basis-Software (Datenbasis, Überlaststeuerung usw.) der Verarbeitungsplattform entspricht und die mehrere Dienstleistungskapseln DLK umfaßt, eine fünfte Schale, die der System-Software (Konfigurations-Software, Recovery-Software usw.) der Verarbeitungsplattform entspricht und die ebenfalls mehrere Dienstleistungskapseln DLK umfaßt,

eine sechste Schale, die der Anwender-Software (Vermittlungstechnik, ATM-Cross-Connect, Protokollabwicklung usw.) der Verarbeitungsplattform entspricht, und die ebenfalls mehrere Dienstleistungskapseln DLK umfaßt.

G 1 5 4 7 DE O 1

Nur die oberhalb der zweiten Schale ablaufende Software wird in Dienstleistungsmoduln SPU zusammengefaßt und in Dienstleistungskapseln DLK gekapselt. Die Schalen 1 bis 3 stellen zusammen die Grundverarbeitungsplattform dar und sind für jeden Verarbeitungsplattformtyp gleich.

Mit dem Dienstleistungsmodul steht dem Entwickler ein größerer und zweckmäßigerer Container als der heutige Prozess zur Verfugung. Ein Dienstleistungsmodul ist eine Menge von Modulen und Prozessen, die eine starke funktionale Beziehung zueinander haben und zusammen eine Gruppe von Diensten für die übrige Software oder den Teilnehmer des Vermittlungssystems zur Verfugung stellen. Seine Komponenten (Module und Prozesse) befinden sich garantiert im selben Adressraum des Speichers. Deshalb können für die Kommunikation innerhalb eines Dienstleistungsmoduls lokale Prozeduraufrufe und gemeinsame Speichermechanismen benützt werden.

Das Dienstleistungsmodul ist eine relozierbare Einheit, d.h. es kann von einer Dienstleistungskapsel zu einer anderen Dienstleistungskapsel und ebenso von einer Verarbeitungsplattform zu einer anderen Verarbeitungsplattform zur Produktionszeit des Steuerungssystems bewegt werden. Daraus ergibt sich, daß die Schnittstellen eines Dienstleistungsmoduls durch Ausdrücke der Inter-Prozeß-Kommunikation definiert werden müssen (z.B. CAST, Remote-Prozeduren). Jede Aktion oder jeder Steuerungsdatenfluß zwisehen zwei Dienstleistungsmodulen wird durch die Übergabe von Meldungen ausgelöst. Die Kommunikation zwischen zwei Dienstleistungsmodulen erfolgt somit ausschließlich über das Betriebssystem. Darüber hinaus ist das Design und die Implementation eines Dienstleistungsmoduls "location transparent", d.h. ein Dienstleistungsmodul braucht keine

G 1 5 A 7 DE O 1

Kenntnis davon zu haben auf welcher Verarbeitungsplattform es abläuft und auf welchen Verarbeitungsplattformen eventuelle Kommunikationspartner laufen. 5

Ein Dienstleistungsmodul kann weiterhin vervielfältigt werden, so daß dasselbe Dienstleistungsmodul sowohl auf mehreren Steuerungsprozessoren als auch mehrmals auf einem einzigen Steuerungsprozessor auftreten kann. Die Vervielfältigung kann sowohl zum Produktionszeitpunkt des Systems stattfinden oder sogar während der Laufzeit des Systems. Durch die genannte Vervielfältigbarkeit eines Dienstleistungsmoduls wird die Flexibilität des Systems bezüglich der Lastverteilung und der Erweiterbarkeit unterstützt.

Das Dienstleistungsmodul spielt innerhalb des Systems zwei unterschiedliche Rollen. Es kann zum einen Dienstleistungen für andere Dienstleistungsmodule ausführen, oder zum anderen Dienstleistungen von anderen Dienstleistungsmodulen anfordern. In dem erstgenannten Fall handelt es als Server, während es im zweitgenannten Fall als Client handelt. Einige Dienstleistungsmodule können ausschließlich als Server handeln, während andere wiederum als ausschließliche Clienten handeln. Im allgemeinen jedoch spielt ein Dienstleistungsmodul beide Rollen.

Damit ein Dienstleistungsmodul die Dienstleistungen eines anderen Dienstleistungsmodul in Anspruch nehmen kann, muß es wissen, welche Dienstleistungen von dem Server-Dienstleistungsmodul zur Verfügung gestellt werden. Zu diesem Zweck stellt jedes Dienstleistungsmodul sogenannte Dienstschnittstellen zur Verfugung, in der die Dienste beschrieben sind, die das Dienstleistungsmodul innerhalb des Systems zur Verfügung stellt. Diese Dienstschnittstellen werden, nachdem ein Dienstleistungsmodul in

G 1 5 4 7 DE O 1

das System geladen worden ist, gegenüber dem Betriebssystem bekannt gemacht, so daß andere Dienstleistungsmodule die Dienstleistungen des geladenen Dienstleistungsmoduls über das Betriebssysstem ab diesem Zeitpunkt in Anspruch nehmen können.

Eine Dienstschnittstelle beinhaltet den Namen und Typ des Dienstes, eine Gruppe von Remote-Prozeduren und Remote-Puffern, sowie weitere den zugehörigen Dienst spezifizierende Datenobjekte, z.B. Partition.

Das Dienstleistungsmodul stellt einen eigenständigen Baustein zur Systemerstellung dar, der über seine Dienstschnittstellen von anderen Dienstleistungsmodulen aufgerufen werden kann. Nach der Installierung dieses Bausteins innerhalb des Systems kann man ihn auf verschiedene Art mit anderen Dienstleistungsmodulen zusammenfassen, um neue Systemleistungen bereitzustellen. Dieses Prinzip ist auch die Basis für Standardbausteine zur Software-Erstellung, die der momentanen Standardisierung intelligenter Netze entsprechen.

Im folgenden wird ein weiterer Software-Container, nämlich eine Dienstleistungskapsel DLK näher erläutert.

Die Dienstleistungskapsel umfaßt eine Gruppe von Dienstleistungsmoduln, denen gemeinsam ein bestimmtes Budget von Betriebsmitteln (z.B. geschützter Adressraum, zwei Speieher, Zeitgeber) zur Verfügung gestellt ist. Eine Dienstleistungskapsel kann on-line, d.h. ohne Betriebsunterbrechung, in das System eingebracht oder durch eine aufgerüstete Version ersetzt werden.

Durch das Zusammenfassen von Dienstleistungsmodulen in

G 1 5 W DE O 1

Dienstleistungskapseln lassen sich neue Systeme oder kundenspezifische Leistungsmerkmale schaffen. Darüber hinaus ist es möglich, bestehenden Dienstleistungskapseln geänderte oder vollständig neue Dienstleistungsmodule hinzuzufügen. Die Tatsache, daß Dienstschnittstellen gewartet werden können, ermöglicht das Erstellen neuer Kombinationen zu niedrigen Kosten und in kürzerer Zeit. Darüber hinaus können die Prüfung und Wartung eines Dienstleistungsmoduls als isolierbare Funktionseinheiten ausgeführt werden. Dadurch werden übergreifende Funktionstests in Umfang und Komplexität vermindert, was die Entwicklungskosten weiter reduziert.

Das Aufrüsten von Betriebsvermittlungsstellen durch Hinzufügen von Dienstleistungskapseln ist ein Mittel, Entwicklungskosten zu vermindern und dadurch Wettbewerbsvorteile zu erhalten. Auf diese Weise kann der Netzbetreiber neue Leistungsmerkmale mit verringerter Logistik schnell in das Netz einbringen. Die neuen Merkmale lassen sich in bestehenden oder neuen Verarbeitungsplattformen hinzufügen. In beiden Fällen sind folgende Schritte erforderlich:

In einem ersten Schritt werden die Dienstleistungskapsel off-line durch Zusammenfassen mehrerer Dienstleistungsmodule erstellt und anschließend an die entsprechenden Vermittlungsstellen ausgeliefert. In einem zweiten Schritt werden in einer entsprechenden Vermittlungsstelle on-line neue Verarbeitungsplattformtypen erstellt.

In einem dritten Schritt vollzieht sich das Laden neuer Kapseln in bestehende Verarbeitungsplattformen, um neue Verarbeitungsplattformtypen zu vervollständigen, oder das Laden vollständiger Verarbeitungsplattformtypen in neue

G 1 54 7DE O 1

Verarbeitungsplatt formen.

In einem vierten Schritt vollzieht sich schließlich das Aktivieren neuer Kapseln oder eines neuen Verarbeitungsplalttformtyps auf der bestehenden bzw. neuen Verarbeitungsplatt form.

Durch die genannten Schritte kann eine neue Kombination bestehender Funktionen ohne Betriebsstörung in das System eingefügt werden. Neue Leistungsmerkmal-Software läßt sich auf dieselbe Weise einbringen, weil das Betriebssystem jede Dienstleistungskapsel als eigene Verarbeitungseinheit behandelt.

Wie bereits vorher erwähnt, werden Kommunikationsbeziehungen zwischen den Dienstleistungsmoduln dynamisch hergestellt. Diese Funktion wird im folgenden als Diensteadressierung bezeichnet und durch ein Dienstemanagementsystem innerhalb der Betriebssystem-Software zur Verfügung gestellt.

Jede Implementierung eines bestimmten Dienstes innerhalb eines Dienstleistungsmoduls wird als Instanz eines bestimmten Dienstes (Diensttyp) oder abgekürzt einfach als Dienstinstanz bezeichnet. Die von einem Dienstleistungsmodul durch entsprechende Dienstinstanzen zur Verfugung gestellten Dienstleistungen werden dem System in bereits erwähnten Dienstschnittstellen bekanntgegeben. Dabei liegt für jede Dienstinstanz eine entsprechende Dienstschnittstelle vor, die von dem jeweiligen Dienstleistungsmodul exportiert und in einer Spezifikation (Kurzerklärung mit Syntax und Semantik) erläutert wird.

Immer wenn eine Dienstinstanz eines Dienstleistungsmoduls eine Kommunikationsbeziehung mit einer anderen Dienstin-

G 1 5 4 7 DE O 1

stanz eines anderen Dienstleistungsmoduls zwecks Ausführung eines Dienstes herstellen will, so führt sie über das Betriebssystem einen Aufruf an das Dienstemanagementsystem durch, in welchem der Name des Typs des angeforderten Dienstes und gegebenenfalls zusätzliche Kriterien für die Auswahl eines Server-Dienstleistungsmoduls angegeben werden.

Mögliche zusätzliche Auswahlkriterien sind

- eigene Verarbeitungsplattform, d.h. geringster dynamischer Aufwand,

- Partitionen, die den Dienst auf einen bestimmten Daten-Bereich oder Ressourcen-Bereich eingrenzen, - explizite Angabe der Verarbeitungsplattform und/oder der Dienstleistungskapsel.

Als Resultat des Aufrufs erhält die aufrufende/Kunden-Dienstinstanz einen sogenannten Kommunikationspfad zurück, mit Hilfe dessen die Kommunikation zu der ausgewählten Server-Dienstinstanz aufgenommen werden kann. Bei dem Kommunikationspfad handelt es sich um ein Datenfeld, das im wesentlichen Remote-Referenzen (RPCs und CAST) zu der ausgewählten Server-Dienstinstanz enthält. Die eigentliehe Kommunikation wird sodann durch Senden von Meldungen (Cast) oder Aufrufen von Remote-Prozeduren (RPC) durchgeführt.

FIG 2 zeigt die Anforderung eines bestimmten Dienstes durch den Aufruf "Connect-Service" an das Dienste-Management System eines Betriebssystem BS. In Fig. 2 erfolgt der genannte Aufruf innerhalb einer Verarbeitungsplattform GP3 eines Steurungssystems, das noch zwei weitere Verarbeitungsplattformen GPl und GP2 aufweist. Als Resultat des genannten Aufrufs erhält die aufrufende Dienst-

G 1 5 4 7 DE O 1

&iacgr;&ogr;

instanz des Dienstleistungsmoduls SPUO eine Referenz auf die Dienstschnittstelle einer Dienstinstanz, die den angeforderten Dienst ausführen kann. Die genannte Dienstschnittstelle enthält u.a.eine Sammlung von Remote-Referenzen, mit deren Hilfe in Form von Meldungen (Cast) und Remote-Prozedur-Aufrufen (RPC) die Kommunikation mit der vom Dienstemanagement ausgewählten Dienstinstanz durchgeführt werden kann.

Bei der Auswahl einer geeigneten Dienstinstanz berücksichtigt das Dienstemanagementsystem Last-/und Maintenance-Zustände derjenigen Plattformen, auf denen sich geeignete Dienstinstanzen befinden. Die Informationen über die genannten Plattformzustände entnimmt das Dienstmanagementsystem einer eigenen lokalen Zustandstabelle, die durch das Überlastbehandlungssystem und das Maintenance-System regelmäßig aufdatiert wird.

FIG 3 zeigt die Kommunikation zwischen zwei Dienstinstanzen mit Hilfe von Meldungen. Bei dem Steuerungssystem auf der linken Seite von FIG 3 befindet sich die anfordernde Dienstinstanz in dem Dienstleistungsmodul SPUO des Steuerungsprozessors GP3 und die ausgewählte Dienstinstanz innerhalb des Dienstleistungsmoduls SPUl desselben Steuerungsprozessors. Bei dem Steuerungssystem auf der rechten Seite von FIG 3 befindet sich die anfordernde Dienstinstanz in dem Dienstleistungsmodul SPUO des Steuerungsprozessors GP3 und die ausgewählte Dienstinstanz in dem Dienstleistungsmodul SPUl des Steuerungsprozessors GPl.

FIG 4 zeigt die Kommunikation zwischen zwei Dienstinstanzen mit Hilfe von Remote-Prozedur-Aufrufen (RPC). Die örtliche Lage der anfordernden Dienstinstanz und der angeforderten Dienstinstanz innerhalb der beiden dargestellten

G 1 5 17 DE O 1

11

Steuerungssysteme ist zu der in FlG 3 bereits angegebenen örtlichen Lage identisch.

Eine Client-Dienstinstanz und eine Server-Dienstinstanz sind in der Lage, Statusinformationen über ihren Kommunikationsablauf zu speichern, da anderenfalls jeder Kommunikationsvorgang zwischen den beiden durch einen erneuten Aufruf "Connect-Service" eingeleitet werden müßte. Es kann nun Situationen geben, in denen zum Zeitpunkt eines Ausfalls oder einer Außerbetriebnahme der Server-Dienstinstanz wegen einer Wartung die Kommunikationsbeziehung zwischen der Server-Dienstinstanz und der Client-Dienstinstanz noch bestehen kann. Versucht in einem solchen Fall die Client-Dienstinstanz einen weiteren Kommunikationsvorgang, z.B. durch Senden von Meldungen zur Server-Dienstinstanz durchzuführen, so erhält sie von der Inter-Prozeß-Kommunikation eine entsprechende Fehlermeldung zurück. Dies bedeutet, daß die Kommunikationsbeziehung von Seiten der Server-Dienstinstanz aufgelöst worden ist. Die Client-Dienstinstanz muß nun erneut eine Kommunikationsbeziehung mit einer geeigneten Server-Dienstinstanz aufbauen, um die Durchführung des Dienstes fortzusetzen. Die genannte Fehlermeldung der Inter-Prozeß-Kommunikation enthält eine Angabe darüber, ob es sich um eine Nichtverfügbarkeit der Server-Dienstinstanz (wegen Wartung oder Überlast) oder um einen Fehler des angesprochenen Puffers (z.B. wegen Abschluß einer sanften Außerbetriebnahme) handelt.

im Falle eines sanften Außerbetriebnehmens eines Dienstleistungsmoduls wegen Erweiterung können alte bestehende Kommunikationsbeziehungen während eines Überspannungszeitraumes erhalten bleiben, während eine Client-Dienstinstanz zur Aufnahme einer erstmaligen Kommunikationsbeziehung durch den Aufruf "Connect-Service" außer dem Kommunikationspfad als optionalen Parameter ein sogenanntes Erwei-

G 1 5 4 7 DE O 1

terungszeichen zurückerhält. Das genannte Erweiterungszeichen ist dann Teil des Nachrichten-Headers jeder Nachricht in der Inter-ProzeQ-Kommunikation. Bei der genannten sanften Erweiterung sind während des Erweiterungszeitraums somit sowohl die alte Dienstinstanz als auch die neue Dienstinstanz verfügbar und das genannte Erweiterungszeichen wird benützt, um anzuzeigen, ob mit der alten Server-Dienstinstanz oder der neuen Server-Dienstinstanz kommuniziert werden soll.

Aus funktionaler Sicht kann unter den Dienstinstanzen zwischen vervielfältigten Dienstinstanzen eines Dienstes und partitionierten Dienstinstanzen eines Dienstes unterschieden werden. Vervielfältigte Dienstinstanzen entstehen jeweils durch die Vervielfältigung eines gesamten Dienstleistungsmoduls. Partitionierte Dienstinstanzen eines Dienstes weisen denselben Dienstschnittstellentyp wie vervielfältigte Dienstinstanzen desselben Dienstes auf, führen den Dienst jedoch für einen unterschiedlichen Bereich von Daten oder eine unterschiedliche Menge von Ressourcen durch (z.B. kann ein "File-Dienst" für einen Halbleiterspeicher oder einen Magnetspeicher ausgeführt werden). Die Server-Dienstinstanzen weisen eine sog.

Partitionskennung auf, um zwischen partitionierten Dienstinstanzen unterscheiden zu können.

Vervielfältige Dienstinstanzen weisen denselben Dienstschnittstellentyp auf und besitzen dieselbe Partitionskennung, da sie den entsprechenden Dienst für denselben Bereich von Daten oder dieselbe Menge von Ressourcen durchführen. Vervielfältige Dienstinstanzen können auf unterschiedlichen Verarbeitungsplattformen vorhanden sein und eine identische oder unterschiedliche Implementation aufweisen. Das Dienstemanagement benützt für die Auswahl einer Dienstinstanz einen bestimmten Auswahl-Algorithmus, der Lastzustände und Recoveryzustände der Verarbeitungs-

G 1 5 4 7 DE O 1

plattformen berücksichtigt, um eine optimale Lastverteilung und Fehlertoleranz zu unterstützen. Diese Auswahl-Algorithmen sind für die anforderndenden Dienstinstanzen nicht sichtbar. Die Client-Dienstinstanz braucht somit zwischen mehreren vervielfältigen Dienstinstanzen desselben Dienstes nicht zu unterscheiden.

Aus der Sichtweise der Programmiersprache handelt es sich bei einer Dienstschnittstelle um einen speziellen Datentyp, durch den ein Dienst bzw. genauer gesagt ein bestimmter Diensttyp beschrieben wird. Der genannte Datentyp enthält u.a. eine vom Diensttyp abhängige Sammlung von Remote-Referenzen (Remote-Prozedur-Aufrufe RPC und Puffer), die im folgenden auch als Kommunikationspfad bezeichnet wird. Jede Deklaration einer Variable des Datentyps "Diensttyp" entspricht der Erzeugung einer Dienstinstanz. Diese Erzeugung umfaßt die statische Initialisierung der genannten Remote-Referenzen.

Eine Dienstinstanz ist innerhalb des Systems durch eine Diensttypkennung, eine Partitionskennung, eine Kapselkennung und eine Dienstleistungsmodulkennung eindeutig spezifiziert.

Die Diensttypkennung wird durch die Support-Software, genauer gesagt durch den sogenannten Systembinder (Linker) während der Produktionszeit oder Laufzeit des Systems erzeugt. Eine solche Diensttypkennung wird jeder deklarierten Dienstvariablen zugeordnet. Aufgrund der Zuordnung ist die deklarierte Dienstvariable nun innerhalb des Systems als Instanz eines bestimmten Dienstes bekannt. Alle Dienstinstanzen, deren Variablentyp (Diensttyp) und Variablen-Name gleich ist, erhalten innerhalb des Systems dieselbe Diensttypkennung. Eine Instanz eines bestimmten

G 1 5 k 7 DE O 1

14

Dienstes kann seine Diensttypkennung niemals ändern.

Die Partitionskennung einer Dienstinstanz wird ebenfalls zur Produktionszeit (statisches Bekanntmachen) oder zur Laufzeit (dynamisches Bekanntmachen) erzeugt. Der Typ der Partitionskennung ist ein Bereich von Daten oder eine Menge von Ressourcen und wird innerhalb der ersten Komponente des Datentyps "Diensttyp" definiert.

Die Partitionskennung ermöglicht es der Anwender-Dienstinstanz zwischen mehreren Dienstinstanzen zu unterscheiden. Alle Dienstinstanzen eines bestimmten Dienstes, die dieselbe Partitionskennung aufweisen, stellen aus der Sichtweise des Dienstemanagementsystems vervielfältigte Dienstinstanzen dar. Alle Dienstinstanzen eines bestimmten Dienstes mit unterschiedlichen Partitionskennungen stellen aus der Sichtweise des Dienstemanagementsystems partitionierte Dienstinstanzen dar.

Es ist möglich, eine vorher zugeordnete Partitionskennung für eine Dienstinstanz während der Laufzeit zu ändern. Dies ist allerdings nur für solche Dienstinstanzen möglich, deren Zuordnung einer Partitionskennung auf dynamische Weise (dynamisches Bekanntmachen) erfolgt ist.

Die Kapselkennung und die Dienstleistungsmodulkennung beschreiben die Lage einer Dienstinstanz innerhalb des gesamten Systems. Jede Dienstinstanz hat innerhalb des Systems somit eine eindeutige örtliche Lage. Es ist nicht erlaubt, dieselbe Instanz eines Dienstes innerhalb eines Dienstleistungsmoduls mehrmals zu erzeugen (Restriktion für den Compiler). Es ist allerdings erlaubt, einer bestimmten Dienstinstanz eine zusätzliche Partitionskennung zuzuordnen. Die genannte Restriktion bedeutet

6 1 5 h 7 DE O 1

also, daß es nicht möglich ist, mehr als eine Dienstinstanz eines bestimmten Dienstes innerhalb eines bestimmten Dienstleistungsmoduls zu haben.
5

Die Dienstleistungsmodulkennung wird durch den Linker erzeugt und dem off-line-Systembauer übergeben. Die Kapselkennung wird durch den off-line-Systembauer erzeugt. Die Kapselkennung und die Dienstleistungsmodulkennung werden vom off-line-Systembauer zum on-line-Systembauer in Form von Tabellen übergeben. Diese Tabellen werden vom on-line-Systembauer benützt, wenn er eine sogenannte Dienstetabelle erzeugt.

Jede Dienstinstanz hat innerhalb des Systems eine eindeutige örtliche Lage. Diese örtliche Lage wird durch eine Ortskennung (Kapselkennung und Dienstleistungsmodulkennung) beschrieben. Das Dienstemanagement erlaubt es, daß mehrere Dienstinstanzen eines bestimmten Dienstes, d.h. eines bestimmten Dienstschnittstellentyps dieselbe Ortskennung besitzen, solange sie nicht dieselbe Partitionskennung aufweisen.

Eine Dienstinstanz kann durch einen Remote-Prozedur-Aufruf RPC oder eine Nachricht (Cast) in einem der Puffer der genannten Dienstinstanz angerufen werden. Der Anruf einer Dienstinstanz eines bestimmten Dienstes über die Grenzen einer Dienstleistungskapsel hinaus ist durch ein entsprechendes Feld von Remote-Referenzen (Puffer-Referenzen und RPC-Referenzen) und den Gebrauch von entsprechenden Kommunikationseinrichtungen des Betriebssystems implementiert. Der Anruf einer Instanz eines bestimmten Dienstes innerhalb einer Dienstleistungskapsel ist durch den Gebrauch eines Feldes auf Local-Referenzen (Zeiger auf Puffer und Prozeduren) implementiert. Die Größe eines solchen Feldes hängt von der Anzahl der Komponenten eines Dienstes ab.

G 1 5 * 7 DE O 1

Die Aufgabe des Dienstemanagementsystems ist es aufgrund einer Anforderung eines Dienstes eine entsprechende Dienstinstanz zur Durchführung des angeforderten Dienstes auszuwählen und deren Kommunikationspfad (Feld von Referenzen) der anfordernden Dienstinstanz zu übergeben. Die genannte Anforderung eines Dienstes wird mit Hilfe des Betriebssystem-Aufrufs "Connect Service" bewirkt. Der genannte Betriebssystem-Aufruf ermittelt den genannten Kommunikationspfad, indem er in verschiedenen Tabellen nachsieht. Die in diesem Zusammenhang wichtigsten Tabellen sind eine statische Dienstetabelle und eine transiente Dienstetabelle. Die Elemente dieser Tabellen sind die Dienstkennungen, die Kapselkennungen, die Dienstleistungsmodulkennungen, die Partitionskennungen und schließlich die Kommunikationspfade.

Die Diensttypkennung ist als ein Parameter innerhalb des Betriebssystems-Aufrufs "Connect Service" unbedingt nötig.

Andere Parameter, wie z.B. die Partitionskennung oder die Kennungen bezüglich der örtlichen Lage (Kapselkennung und Dienstleistungsmodulkennung) sind optionale Parameter. Wenn der genannte Betriebssystem-Aufruf erfolgreich ist, wird - wie bereits erwähnt - ein Datenfeld mit Remote-Referenzen (Kommunikationspfad), der aufrufenden Dienstinstanz zurückgegeben.

Das Dienstemanagementsystem benützt zur Durchführung seiner Aufgabe die genannten Diensttabellen, welche Informationen über die verfügbaren Dienste des Systems, die zur Durchführung der Dienste vorhandenen Dienstinstanzen und die zu den Dienstinstanzen zugehörigen Kommunikatispfade beinhalten. Diese Diensttabellen werden durch Werkzeuge (Tools) der Support-Software erzeugt, die sowohl off-line als auch on-line arbeiten.

G 1 5 k 7 DE O 1

Die erzeugten Diensttabellen enthalten Informationen über die verschiedenen Verarbeitungsplattformen des Steuerungssystems und die verfügbaren Dienstinstanzen auf den vorhandenen Verarbeitungsplattformen.

Insbesondere die Ortskennungen werden durch ein On-Line-Werkzeug erzeugt. Die Ortskennungen werden von der InterProzess-Kommunikation und der Inter-Prozessor-Kommunikation des Betriebssystems benutzt. Das Dienstemanagementsystem macht keine weiteren Annahmen über die erzeugten Ortskennungen. Es geht davon aus, daß die erzeugten Ortskennungen gültig sind und bietet der Inter-Prozess-Kommunikation, der Inter-Prozessor-Kommunikation und dem internen Transportprotokoll anhand der Ortskennungen die von diesen Systemen benötigten Informationen über die Zielbestimmungen an.

Um die genannten Diensttabellen zu erzeugen, ist eine Informationsweitergabe über verschiedene Werkzeuge der Support-Software notwenig, die im folgenden näher erläutert wird.

Der Compiler erkennt bei der Compilierung zunächst die Deklarationen von Dienstvariablen (Dienstinstanzen) und deren Schnittstellenkomponenten (Puffer etc.) innerhalb des Source-Codes. Der Compiler reicht diese Information an den Linker weiter. Nach der Compilierung sind die genannten Dienstinstanzen einem bestimmten Dienstleistungsmodultyp zugeordnet.

Der Linker reicht sodann die genannten Informationen an den off-line Systembauer weiter. Nach dem Binden durch den Linker gehören die genannten Dienstinstanzen zu einem bestimmten Dienstleistungskapseltyp. Die Dienstleistungs-

G 1 5 4 7 DE O 1

modulkennung, die die relative Lage des Dienstleistungsmoduls innerhalb einer Dienstleistungskapsel angibt, ist zu diesem Zeitpunkt festgelegt worden. Außerdem ist zu diesem Zeitpunkt auch die relative Position der Komponenten der Schnittstellen der Dienstinstanzen innerhalb einer Dienstleistungskapsel festgelegt worden.

Der off-line-Systembauer ordnet nun den vom Linker überreichten Dienstinstanzen entsprechende Dienstkennungen zu. Außerdem erzeugt er für jede Verarbeitungsplattform einen bestimmten Ladungstyp, durch den jeweils die Funktion einer Verarbeitungsplattform bestimmt wird. Die relative Position einer Dienstleistungskapsel innerhalb eines Ladungstyps ist nun festgelegt.

Der on-line-Systembauer kennt die vom off-line-Systembauer erzeugte Konfiguration der Hardware und der zugehörigen Ladungstypen der Verarbeitungsplattformen. Er erzeugt daraus die notwendigen Tabellen für das Dienstmanagementsystem. Er kennt die Beziehungen zwischen den Ladungstypen und den spezifischen Ortskennungen einer Verarbeitungsplattform. Die von ihm erzeugte Dienstetabelle enthält die Beziehungen zwischen Dienstinstanzen, deren örtlicher Lage und deren zugehörigen Schnittstellenkomponenten.

FIG 5 zeigt den Gebrauch der Dienstetabelle durch das Dienstemanagementsystem.

Das Dienstemanagementsystem DMS enthält gemäß FIG 5 zur Durchführung seiner Aufgabe eine Dienstetabelle ST, in der die Schnittstellen von Instanzen bereits bekanntgemachter Diensttypen abgespeichert sind. Immer wenn eine Dienstinstanz einen Dienst von einem anderen Diensleistungsmodul anfordern will und noch keine Kommunikationsbeziehung zu

6 1 5 &eeacgr; 7 DE O 1

einer entsprechenden Dienstinstanz besteht, übergibt es an das Dienstemanagementsystem den Namen des angeforderten Diensttyps, z.B. den Namen "Dienst 1". Das Dienstemanagementsystem beinhaltet die Namen der bereits bekanntgemachten Dienste (Diensttypen) in einer Dienstenamenstabelle innerhalb der Dienstetabelle ST, sowie in einer Instanzentabelle die Ortskennungen und Partitionskennungen derjenigen Dienstinstanzen, die den genannten Dienst ausführen. Anhand des vom anfordernden Dienstleistungsmodul übergebenen Namens kann das Dienstemanagementsystem somit aus den möglichen Dienstleistungsmoduln das hinsichtlich einer optimalen Lastverteilung am besten geeignete Dienstleistungsmodul, das den angeforderten Dienst beinhaltet, auswählen und dem anfordernden Dienst den entsprechenden Kommunikationspfad zu einer Dienstinstanz des angeforderten Dienstes übergeben. Die anfordernde Dienstinstanz kann nun die Kommunikation mit der zugehörigen Dienstinstanz aufnehmen.

Anstelle einer bloßen Namensangabe des angeforderten Dienstes kann der anfordernde Dienst auch zusätzliche Auswahlkriterien angeben, z.B. die Angabe eines bestimmten Steuerungsprozessors, die Angabe einer bestimmten Instanz eines bestimmten Dienstes oder einer bestimmten Dienstleistungskapsel .

Ein bestimmter Dienst, z.B." Dienst 1" ist von mehreren verschiedenen Instanzen durchführbar. Jede Instanz führt den Dienst jedoch nur für einen bestimmten Bereich von Daten oder eine bestimmte Menge von Ressourcen durch. Dieser Umstand wird durch eine Partitionskennung ID_p markiert.

In FIG 5 sind drei Dienstleistungsmodule, nämlich SPUl,

S2 G 1 5 H 7 DE O 1

SPU2 und SPU3 in das System eingebracht worden, wobei es sich bei den Dienstleistungsmoduln SPUl und SPU2 um identische Dienstleistungsmodule handelt und somit wenigstens eines von den beiden genannten Dienstleistungsmoduln durch Vervielfältigung entstanden ist. Aufgrund der Identität der beiden Dienstleistungsmoduln besitzen einander entsprechende Dienste der beiden Dienstleistungsmoduln, z.B. "Dienst 1", auch dieselben Partitionskennungen ID_p.

Nach dem Einbringen eines Dienstleistungsmoduls in das System, sei es durch Laden oder Vervielfältigen, erfolgt das Bekanntmachen der Dienste des neu eingebrachten Dienstleistungsmoduls gegenüber dem Dienstemanagementsystem DMS, dessen Ablauf nun näher beschrieben wird.

In einem ersten Schritt wird aufgrund einer Anforderung "Announce Service", die von einer anfordernden Instanz an das Dienstemanagementsystem gestellt wird, die Ortskennung (Kapselkennung und Dienstleistungsmodulkennung) aus dem Prozeßkontrollblock der aufrufenden Instanz entnommen.

Die Diensttypkennung und die Partitionskennung werden als Parameter in der Anforderung "Announce Service" mitübergeben. Für Dienste, die dynamisch, d.h. zur Laufzeit des Systems bekanntgegeben werden, steht in jedem Dienstleistungsmodul ein separater Prozeß zur Verfügung, der jeweils nur Dienste seines eigenen Dienstleistungsmoduls anmelden kann. Der genannte Prozeß kann pro Dienstinstanz mehrere Partitionskennungen anmelden.

In einem zweiten Schritt wirft das Dienstemanagement nun anhand der übergebenen Diensttypkennung und der Ortskennung einen Blick in die bezüglich des Diensttyps relevante Instanzentabelle innerhalb der Dienstetabelle.

6 1 5 kl DE O 1

Wenn die in der Anforderung übergebene Partitionskennung in der Instanzentabelle bereits definiert ist, geschieht nichts und es wird ein entsprechender Rückgabewert der aufrufenden Instanz zurückgegeben. Wenn in der genannten Instanzentabelle jedoch keine korrespondierende Dienstinstanz mit derselben Partitionskennung gefunden wird, wird die Anforderung ausgeführt, d.h. die neue Partitionskennung wird in die Partitionsliste innerhalb der Instanzentabelle eingetragen und daraufhin der die Bekanntmachung anfordernden Instanz ein entsprechender Rückgabewert zurückgegeben.

In einem dritten Schritt muß die soeben innerhalb einer bestimmten Verarbeitungsplattform erfolgte Bekanntmachung einer Dienstinstanz auch auf die übrigen Verarbeitungsplattformen verteilt werden. Die Bekanntmachungsinformationen der neuen Dienstinstanz müssen dazu zunächst in einer lokalen Zwischenspeichertabelle abgespeichert werden, bevor sie nach einer angemessenen Zeitspanne durch eine Multicast-Kommunikation zu den Dienstemanagementsystemen der anderen Verarbeitungsplattformen gesandt werden. Wenn die genannte lokale Zwischenspeicherungstabelle bereits vor der genannten angemessenen Zeitspanne einen bestimmten Anfüllungsgrad überschritten haben sollte, wird ebenfalls eine Multicast-Kommunikation auf Betriebssystemebene ausgelöst.

Zu dem soebenen beschriebenen Vorgang des Bekanntmachens einer neuen Dienstinstanz innerhalb des Steuerungssystems existiert ein umgekehrter Vorgang zum Löschen der Bekanntmachung einer neuen Dienstinstanz. Dieser umgekehrte Vorgang wird durch den Betriebssystemaufruf "Withdraw Service" ausgelöst und in analoger Weise zu dem vorher erläuterten Vorgang des Bekanntmachens durchgeführt.

Claims

G 1 5 <t 7 DE O 1

22
1

Schutzansprüche

1. Steuerungssystem eines Vermittlungssystems mit

a) wenigstens einem Steuerungsprozessor

b) jeweils einem Betriebssystem pro Steuerungsprozessor, das die Betriebsmittel des Vermittlungssystems steuert, verwaltet und überwacht,

c) wenigstens einem Dienstleistungsmodul (SPU) pro Steuerungsprozessor, das jeweils wenigstens einen Dienst beinhaltet, das auf mehreren Steuerungsprozessoren und/oder mehrmals auf einem Steuerungsprozessor eingebracht sein kann und das zur Ausführung eines seiner Dienste einen Dienst eines anderen Dienstleistungsmodul anfordern kann,

d) einem Dienstemanagementsystem, das jeweils im Betriebssystem enthalten ist und das einem Dienstleistungsmodul, das einen bestimmten Dienst anfordert, den Kommunikationspfad mitteilt, über den die Kommunikation zu einem ausgewählten Dienstlei-

stungsmodul aufgenommen werden kann, das den angeforderten Dienst beinhaltet.

2. Steuerungssystem nach Anspruch 1,

dadurch gekennzeichnet,

daß ein Dienstleistungsmodul auf mehreren Steuerungsprozessoren und/oder mehrmals auf einem Steuerungsprozessor in das Steuerungssystem einbringbar ist, ohne den Betrieb der Steuerungsprozessoren zu unterbrechen.

3. Steuerungssystem nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß ein eingebrachtes Dienstleistungsmodul auf mehreren Steuerungsprozessoren und/oder mehrmals auf einem Steuerungsprozessor vervielfältigbar ist, ohne den Betrieb der Steuerungsprozessoren zu unterbrechen.

S 1 5 4 7 DE O 1

A. Steuerungssystem nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, daß das Dienstemanagementsystem die Auswahl eines Dienstleitungsmoduls für einen angeforderten Dienst in Abhängigkeit der Lastzustände der Steuerungsprozessoren durchführt.

5. Steuerungssystem nach einem der Ansprüche 1 bis A, dadurch gekennzeichnet, daß die Dienstleistungsmoduln die Kommunikation über den genannten Kommunikationspfad durch Senden von Meldungen realisieren.

6. Steuerungssystem nach nach einem der Ansprüche 1 bis A, dadurch gekennzeichnet, daß die Dienstleistungsmoduln die Kommunikation über den genannten Kommunikationspfad durch Aufrufen von Remote-Prozeduren realisieren.

7. Steuerungssystem nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, daß

a) mehrere Dienstleistungsmoduln zu einer Dienstleistungskapsel zusammengefaßt sind,

b) einer Dienstleistungskapsel jeweils ein bestimmtes Budget an Betriebsmitteln zugeordnet ist.