DE4303094A1

DE4303094A1 - Verfahren zur Konfiguration austauschbarer Moduln eines Netzwerks

Info

Publication number: DE4303094A1
Application number: DE19934303094
Authority: DE
Inventors: Ulrich Apel
Original assignee: Alcatel SEL AG
Current assignee: Alcatel Lucent Deutschland AG
Priority date: 1993-02-04
Filing date: 1993-02-04
Publication date: 1994-08-11

Description

Die Erfindung betrifft ein Verfahren zur Konfiguration austauschbarer Moduln eines Netzwerks, bei dem jedem Modul eine Identifikationsnummer zugeordnet ist, unter der zu dem Betrieb des Moduls kennzeichnende Angaben in einem Konfigurator gespeichert sind, das den Modul nach Prüfung dieser Angaben freigibt.

Ein derartiges Verfahren ergibt sich aus der Veröffentlichung von P. Kuhn, "Das ist der IBM-Mikro-Kanal-Bus" in: mc 8/1987, S. 42 bis 47, sowie aus der Veröffentlichung von C. G. Denenberg und J. H. Newey, "System 12, Unterstützungssysteme" in: Elektrisches Nachrichtenwesen, Band 56, Nummer 2/3 1981, S. 274 bis 282.

Ein solches Verfahren dient der sog. Konfigurationsverwaltung, die Bauelemente, Baugruppen, Geräte, sowie Programmodulen umfaßt und folgende Aufgaben hat:

- Führen der Nummernliste für alle Konfigurationsbestandteile.
- Festlegen der Sachnummern zusammen mit Hinweisen auf die begleitenden Beschreibungen mit Angabe des Freigabe-, Änderungs- und Qualifikationszustandes;
- Überwachen der Zusammenhänge zwischen einer Sache und ihren Bestandteilen sowie deren Versionen;
- Überwachen der Beziehungen zwischen einer Sache und der zugehörigen Dokumentation sowie den Ausgabenummern;
- Steuern von Änderungsvorgängen;
- Überwachen der Beziehungen zwischen einer Änderung und der daraus resultierenden neuen Ausgabe der Beschreibung;
- Ausgabe von Berichten und Gesamtübersichten über die Konfigurationsverwaltung.

Bei den bekannten Systemen gelangen die Identifikationsnummern systemabhängig und auf Abfrage an den Konfigurator. Nachteilig ist, daß u. a. ein Austausch einzelner Modulen erfolgen kann, ohne daß rechtzeitig vor erneuter Inbetriebnahme eine neue Konfiguration stattfindet. Daß hat dann zur Folge, daß sich im System Modulen befinden können, die in das System nicht integriert sind und deshalb dessen Betrieb stören. Außerdem handelt es sich hierbei um anwendungsspezifische Lösungen, die nicht allgemeingültig und somit nicht standardisierbar sind.

Der Erfindung liegt daher die Aufgabe zugrunde, das eingangs genannte Verfahren so zu verbessern, daß keine Fehler im Betrieb eines Netzwerkes mehr dadurch entstehen können, daß nach Austausch eines Moduls eine erneute Konfiguration, die an sich notwendig gewesen wäre, nicht vorgenommen wird.

Erfindungsgemäß wird diese Aufgabe dadurch gelöst, daß der Modul nach Start des Netzwerks, ausgelöst durch den ersten Betriebslauf, seine Identifikationsnummer an den Konfigurator übermittelt.

Es findet also auch ohne vom Konfigurator her veranlaßte Abfrage bei Inbetriebnahme automatisch eine Selbstidentifikation statt. Dies kann, falls der Modul ein (Hardware-) Bauelement ist, dadurch erfolgen, daß der Modul eine standardisierte Konfigurationslogik (Konfigurations-"Chip") aufweist, in dem die Identifikationsnummer gespeichert ist und von dem sie dann an den Konfigurator übermittelt wird. Dies gilt auch im Falle einer Backplane bzw. eines PCB Board. Falls der Modul Teil eines Programmes ist, wird bei Kompilierung des Programms durch den Kompiler dem kompilierten Programm ein Standard-Abschnitt vorangestellt, der die Identifikationsnummer enthält und sie an den Konfigurator übermittelt. Es erfolgt also während der Kompilierung eine automatische Einbindung eines allgemeingültigen Identifikationsmoduls.

Ausführungsbeispiele der Erfindung und ihre vorteilhafte Weiterbildungen werden im folgenden anhand der beigefügten Zeichnungen beschrieben. Es stellen dar:

Fig. 1 die Systemarchitektur;

Fig. 2 die Ausbildung eines Moduls, der ein Hardware-Element ist;

Fig. 3 die Ausbildung eines Moduls, der Teil eines Programms ist.

Fig. 1 zeigt den Konfigurator 1, mit dem im Austausch drei verschiedene Typen von Modulen verbunden sind, nämlich Bauelemente 2 und intelligente Backplanes 4 (Hardware-Modulen), sowie Programmteile 3 (Software-Modulen). Über die eingezeichneten Verbindungen laufen typischerweise Anforderungen für eine Konfiguration, Identifikationen, Put-In- Service, Take-out-of-Service, und Fault Reports). Die oberhalb des Konfigurators 1 eingezeichneten Verbindungsleitungen schließen an das System an und dienen zur Anforderung bzw. Bestätigung der Konfiguration.

Fig. 2 zeigt ein Bauelement 2, daß eine standardisierte Konfigurationslogik 5 aufweist. Dies kann ein "Konfigurations-Chip" sein, in den die Identifikationsnummer im Laufe des Bestückungsprozesses eingebrannt wird. Die Leitung 6 stellt die Verbindung zum Konfigurator 1 her. Bei Inbetriebnahme des Bauelements gibt die Konfigurationslogik 5 die ihm inhärente Identifikationsnummer, durch die seine Eigenschaften, sofern sie für die Integration in ein Netzwerk erforderlich sind, charakterisiert sind an den Konfigurator 1 ab, der dann die Konfiguration durchführt. Über die Leitung 7 erfolgt nach Überprüfung im Konfigurator die Freigabe der für den Betrieb erforderlichen Ausgangs-Leitungen 8. Diese Freigabe erfolgt, wenn im Konfigurator nach entsprechender Überprüfung festgestellt wird, daß das Bauelement mit den durch die Identifikationsnummer angegebenen Eigenschaften in dem Netzwerk betrieben werden kann bzw. integrierbar ist. Wichtig ist, daß der Modul bei seinem ersten Betriebslauf nach Start des Netzwerks seine Identifikationsnummer von sich aus - also "aktiv" - an den Konfigurator übermittelt, der nach Prüfung dieser Angaben den Modul freigibt. Bei weiteren Betriebsabläufen erfolgen Abfrage und Freigabe jeweils automatisch. Die Angabe, daß nach Start des Netzwerkes beim ersten Betriebslauf die Identifikationsnummer von dem Konfigurationsabschnitt 5 an den Konfigurator 1 abgegeben wird, kann dergestalt realisiert sein, daß die vom Modul selbst ausgehende Übermittlung der Identifikationsnummer an den Konfigurator erfolgt, sobald die Stromversorgung des betreffenden Moduls eingeschaltet wird.

Fig. 3 zeigt die Durchführung des erfindungsgemäßen Verfahrens bei Anwendung auf den Teil eines Programms. Dieser Modul wird durch das Feld 9 dargestellt. Die Befehle Startmodul und Endmodul sind eingetragen. Dazwischen befindet sich der Benutzercode. Das Programm wird über einen Kompiler 10 in die Form überführt, die durch das Feld 11 dargestellt ist. Das Feld 11 stellt also den kompilierten Benutzercode dar. Diesem wird von dem Kompiler ein standardisierter Abschnitt 11′ vorangestellt, der die Konfiguration initialisiert, d. h. die Identifikationsnummer dieses Moduls an den Konfigurator 1 weitergibt, und nach Bestätigung den Start des kompilierten Benutzercodes freigibt. Durch das Feld 11′′ erfolgt ein Reset der Konfiguration.

Für jeden zu konfigurierenden Programmabschnitt (Software-Modul) wird automatisch vom Kompiler dieser Identifikationsmodul, der ja in Abschnitt 11′ enthalten ist, mit dem Modulnamen parametrisiert und aktiviert. Der Identifikationsmodul muß folgende Funktionalität zur Verfügung stellen:

- Identifikation des Moduls (sowohl automatisch als auch auf Anforderung);
- Freigabe des Moduls auf Anforderung.

Bei Moduln, die durch Hardware-Bauelemente gebildet werden, erfolgt die Realisierung der Erfindung durch Einfügung eines allgemeingültigen Identifikationschips für jeden zu konfigurierenden Modul. Die Identifikationsbits werden im Laufe des Bestückungsprozesses eingebrannt.

Befindet sich das Bauelement auf einem Rack, so muß für jedes Rack die Identifikation im Laufe des Rackaufbaus inherent erfolgen. Der Chip muß dann die Funktionalität besitzen, daß Rack zu identifizieren, den aktuellen Slot zu identifizieren und den Bestückungszustand des einzelnen Slots anzugeben.

Das erfindungsgemäße Verfahren bietet folgende Vorteile: Die aktuellen Konfigurationsdaten stehen stets automatisch und standardisiert zur Verfügung, da sie in der jeweils verwendeten Modulversion enthalten und somit immer aktuell sind. Die Erfindung stellt ein allgemein gültiges standardisierbares Konzept dar, daß in bereits existierende Systeme ohne deren Änderung integrierbar ist. Ein derartiges System ist vom Grundsatz her erweiterbar und sowohl auf Großsystem als auch auf Teilkomponenten anwendbar. Das Verfahren kann automatisiert - ohne Operatorsupport - ablaufen.

Bezugszeichenliste

1 Konfigurator
2 Bauelement (Hardware-Modul)
3 Programmteil (Software-Modul)
4 Backplane
5 Konfigurationslogik
6 Leitung
7 Leitung
8 Ausgangs-Leitung
9 Feld (Programm-Modul)
10 Kompiler
11 Feld (kompilierter Benutzercode)
11′ Abschnitt 11
11′′ Abschnitt

Claims

1. Verfahren zur Konfiguration austauschbarer Moduln eines Netzwerks, bei dem jedem Modul eine Identifikationsnummer zugeordnet ist, unter der für den Betrieb des Moduls kennzeichnende Angaben in einem Konfigurator gespeichert sind, das den Modul nach Prüfung dieser Angaben freigibt, dadurch gekennzeichnet, daß der Modul (2, 11) nach Start des Netzwerks, ausgelöst durch den ersten Betriebslauf, seine Identifikationsnummer an den Konfigurator (1) übermittelt.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß der Modul ein Bauelement (2) ist, das eine Konfigurationslogik (5) aufweist, in der die Identifikationsnummer gespeichert ist und von der sie an den Konfigurator (1) übermittelt wird.

3. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß der Modul (9) Teil eines Programms ist und daß der Kompiler (10) bei Kompilierung des Programms dem kompilierten Programm (11) einen Abschnitt (11′) voranstellt, der den Konfigurationscode enthält, in dem die Identifikationsnummer gespeichert ist, und sie an den Konfigurator (1) übermittelt.

4. Modul zum Einbau in ein Netzwerk, das dem Modul eine Identifikationsnummer zuordnet und unter dieser für den Betrieb des Moduls kennzeichnende Angaben in einem Konfigurator speichert, der den Modul nach Prüfung dieser Angaben freigibt, dadurch gekennzeichnet, daß der Modul eine Konfigurationslogik (5) aufweist, in der die Identifikationsnummer gespeichert ist, und die ferner Mittel aufweist, um die Identifikationsnummer nach Start des Netzwerks, ausgelöst durch den ersten Betriebslauf, an den Konfigurator zu übermitteln.