DE19711958A1 - Netzwerkkommunikation - Google Patents

Description

Die Erfindung bezieht sich auf ein Verfahren zur Netzwerkkom­ munikation, insbesondere zur Kommunikation innerhalb eines elektrischen Niederspannungsnetzwerkes, bei dem von einem Ma­ ster an eine Vielzahl von Slaves in einer Anzahl von Netzweg­ strecken eine Statusabfrage ausgesendet wird (Status-Pol­ ling) Sie bezieht sich weiter auf ein derartiges kommunika­ tionsfähiges Netzwerk.

Bei einem kommunikationsfähigen Netzwerk, bei dem die Kommu­ nikation über stark gedämpfte Medien mit zeitvarianten Stö­ rungen erfolgt, wird üblicherweise eine adaptive und selbst­ lernende Kommunikationssoftware eingesetzt, die auf den Me­ chanismen einer Kollisionserkennung und/oder Kollisionsver­ meidung basiert. Derartige Mechanismen sind jedoch für die sogenannte PLC-Kommunikation (PLC = Power Line Carrier) in einem Energieversorgungsnetz ungeeignet, da zwei Endgeräte auf verschiedenen Kabeln senden können ohne sich zu hören. Daher wird für die PLC-Kommunikation oder -Übertragung im Energieversorgungsnetz der Einsatz einer Master-Slave-Archi­ tektur bevorzugt.

Ein kommunikationsfähiges Netzwerk mit einer derartigen Ma­ ster-Slave-Architektur ist z. B. aus der EP 0 598 297 A2 be­ kannt. Dabei sendet der Master über das Netzwerk einen Anmel­ deaufruf (Logon Request) an alle im Netzwerk neu installier­ ten Geräte (Slaves), so daß nach Empfang der Antwort dieser neu installierten Slaves die Kommunikation des Masters mit diesen Slaves erfolgen kann. Ein derartiges kommunikationsfä­ higes Netzwerk ermöglicht insbesondere das Auslesen von Elek­ trizitätszählern und das automatische Erkennen eines zusätz­ lich an das Netzwerk angeschlossenen Zählers oder Gerätes ohne zusätzlichen Installationsaufwand. Nachteilig ist je­ doch, daß lediglich vom Master direkt erreichbare Slaves (Geräte) identifiziert und in das Netzwerk aufgenommen werden können.

Der Erfindung liegt daher die Aufgabe zugrunde, ein Verfahren zur Kommunikation innerhalb eines Netzwerkes mit Master- Slave-Architektur sowie ein derartiges kommunikationsfähiges Netzwerk anzugeben, daß die Kommunikation auch eines solchen Gerätes mit dem Master ermöglicht, welches den Master nicht direkt empfangen kann. Dieses Verfahren und dieses Netzwerk sollen insbesondere die Aufnahme von zusätzlich installierten Geräten in das Netzwerk unabhängig von deren Entfernung zum Master ermöglichen.

Bezüglich des Verfahrens wird diese Aufgabe erfindungsgemäß gelöst durch die Merkmale des Anspruchs 1. Dabei wird jeder vom Master nicht direkt, sondern nur indirekt erreichbare Slave über einen benachbarten Slave identifiziert und in das Netzwerk aufgenommen. Der Master kann anschließend den nur indirekt erreichbaren Slave über diesen, als Router-Slave priorisierten benachbarten Slave abfragen und dessen Antwort empfangen.

Dieses Verfahren eignet sich besonders für die Aufnahme neuer Geräte und damit zusätzlicher Slaves in das Netzwerk. Dabei wird von dem neu installierten Slave während einer oder im Anschluß an eine von diesem empfangenen Statusabfrage des Ma­ sters eine Anzahl benachbarter Slaves als Router-Slaves (beste Nachbarn) priorisiert. Der neue Slave wird anschlie­ ßend von dem oder jedem priorisierten Router-Slave beim Ma­ ster angemeldet, wobei eine dem neu installierten Slave zuge­ ordnete Adresse in ein entsprechendes Register oder in eine Datentabelle aufgenommen wird. In diese Datentabelle werden auch diejenigen Router-Slaves und diejenigen Netzwegstrecken oder Netzrouten aufgenommen, über die der zusätzlich instal­ lierte Slave entsprechend der jeweils zugeordneten Zuverläs­ sigkeitspriorität erreicht werden kann.

Im Anschluß an jede Statusabfrage des Masters wird die Grup­ pierung der Adressen der an das Netzwerk angeschlossenen Sla­ ves in der Datentabelle hinsichtlich der Netzrouten und der­ jenigen Router-Slaves aktualisiert, über die der jeweilige Slave erreichbar ist. Dabei wird jedem Slave mindestens ein Router-Slave zugeordnet, wobei auch die Adresse des Masters als Routeradresse in diese Routing-Tabelle aufgenommen werden kann. In diesem Fall ist der entsprechende Slave vom Master direkt erreichbar.

Bezüglich des kommunikationsfähigen Netzwerks mit einem Ma­ ster und mit einer Vielzahl von Slaves in eine Anzahl von mit dem Master verbundenen Netzrouten oder Netzwegstrecken wird die genannte Aufgabe erfindungsgemäß gelöst durch eine Netz­ werk-Management-Software zur Zuordnung von Router-Slaves zu dem oder jedem Slave sowie zum Verbindungsaufbau zwischen be­ nachbarten Slaves. Die Netzwerk-Management-Software dient darüber hinaus vorteilhafterweise auch zur Generierung von Netzrouten, insbesondere von Ersatzrouten, zwischen dem Ma­ ster und jedem Slave.

Die Architektur der Netzwerk-Management-Software basiert auf dem ISO-Kommunikationsprotokoll (ISO = International Standar­ disation Organisation), wobei die untersten drei Schichten dieses Kommunikationsprotokolls oder -modells zur Gewährlei­ stung der Routerfunktionalität innerhalb der Netzwerk-Manage­ ment-Software realisiert sind.

Das in sieben aufeinanderaufbauende Ebenen oder Protokoll­ schichten gegliederte ISO-Kommunikationsprotokoll ist ein quasi normiertes Modell für die Entwicklung von Schnittstel­ len für den Kommunikationsprozeß innerhalb eines Kommunika­ tionsnetzes. Dabei legt die unterste, erste Schicht (Physical Layer) die Art und Weise der Übertragung von Signalen oder einzelnen Bits fest, aus denen sich z. B. Modulations- oder Verstärkungsdaten aufbauen. Die zweite Schicht (Data Link Layer) legt die Verfahren zur Sicherung einer fehlerfreien Übertragung auf den einzelnen Netzrouten oder Netzwegstrecken der Systeme (Slaves) zur Vermeidung von Kollisionen fest. Die dritte Schicht (Network Layer) gewährleistet den richtigen Aufbau der einzelnen Streckenabschnitte zwischen Master (Sen­ der) und Slave (Empfänger). Die vierte Schicht (Transport Layer) legt die Funktion und die Art und Weise fest, wie sich die Systeme (Master, Slaves) innerhalb des Netzes oder Netz­ werks während des Datentransportes verhalten sollen. Die un­ teren vier Schichten stellen das Transportprotokoll dar und sind heute weitestgehend in den Systemen nach dem ISO-Kommu­ nikationsprotokoll festgelegt.

Die fünfte Schicht (Connection Layer) legt die bei einer durchzuführenden Verbindung zu verwendenden Einzelheiten der Kommunikation zwischen den Systemen, d. h. zwischen dem Master und den Slaves sowie zwischen den Slaves, fest. In die sech­ ste Schicht (Presentation Layer) werden die zu treffenden Vereinbarungen über die Bedeutung ausgetauschter Daten ge­ legt. In der obersten, siebten Schicht (Application Layer) sind Vereinbarungen über die zulässigen Anwendungen zwischen den kommunizierenden Systemen fixiert. Diese drei oberen Schichten werden auch als Anwendungsprotokoll bezeichnet, in dem die Vereinbarungen über diejenigen möglichen und zulässi­ gen Operationen getroffen werden, die der Master im System des Slaves veranlaßt. Für die Realisierung der Routerfunktion ist daher vorteilhafterweise lediglich eine Datenumsetzung innerhalb der drei untersten Schichten des ISO-Kommunika­ tionsprotokolls erforderlich.

In zweckmäßiger Ausgestaltung umfaßt die Netzwerk-Management- Software ein dem Master zugeordnetes (erstes) Softwaremodul sowie ein jedem Slave zugeordnetes (zweites) Softwaremodul auf. Dabei dient das Softwaremodul des Masters zur Generie­ rung mindestens eines Router-Slaves für den oder jeden Slave. Vorzugsweise generiert dieses Softwaremodul mindestens eine zusätzliche Netzwegstrecke oder Ersatzroute, über die dieser Slave ersatzweise erreichbar ist. Das Softwaremodul des Slaves dient zur Identifizierung eines benachbarten Slaves. Dabei generiert dieses Softwaremodul eine Prioritäts- oder Qualitätsliste der bezüglich der Empfangsqualität "besten Nachbarn", über deren Softwaremodule diese Liste an den Ma­ ster weitergeleitet wird.

Die mit der Erfindung erzielten Vorteile bestehen insbeson­ dere darin, daß durch die geeignete Durchbrechung der an sich bekannten Master-Slave-Architektur derart, daß ein vom Master nur indirekt erreichbarer Slave über einen benachbarten Slave (Router) in das Netzwerk aufgenommen wird, auch neue Geräte (Slaves), die vom Master nicht direkt empfangen werden kön­ nen, in einfacher Weise ohne zusätzlichen Installationsauf­ wand automatisch in ein kommunikationsfähiges Netzwerk aufge­ nommen werden können.

Das Verfahren eignet sich besonders vorteilhaft zur Kommuni­ kation innerhalb eines elektrischen Niederspannungsnetzwer­ kes, bei dem von einem Datenkonzentrator (Master) zur Samm­ lung und Speicherung von Zählerdaten einer Vielzahl von Elek­ trizitätszählern (Slaves) in einer Anzahl von Netzrouten an diese zyklisch Statusabfragen gesendet werden. Dabei werden vom Datenkonzentrator nur indirekt erreichbare Geräte über die "besten Nachbarn" (Router) in das Netzwerk aufgenommen.

Ein Ausführungsbeispiel der Erfindung wird anhand einer Zeichnung näher erläutert. Darin zeigen:

Fig. 1 schematisch eine Master-Slave-Architektur innerhalb eines vermaschten kommunikationsfähigen Netzwerks,

Fig. 2 die Software-Architektur eines Netzwerk-Management- Systems zur Generierung einer Routerfunktionalität innerhalb eines Netzwerkes gemäß Fig. 1, und

Fig. 3, 4 die Routerfunktionalität beschreibende Datentabel­ len eines Masters bzw. eines Slaves.

Fig. 1 zeigt die Systemarchitektur eines PLC-Untersystems (Power Line Carrier Subsystem) eines kommunikationsfähigen Netzwerkes NW mit im Ausführungsbeispiel zwei Mastern M_1,2 und einer Anzahl von mit diesen über das vermaschte Netzwerk NW kommunikationsfähig verbundenen Slaves S_{S1. . .n} in drei unter­ schiedlichen Entfernungsebenen E1, E2, E3 relativ zu den Standorten der Master M_1,2. Im Ausführungsbeispiel handelt es sich um eine Master-Slave-Architektur innerhalb eines Ener­ gieversorgungsnetzes. Dabei sind die auf unterschiedlichen Kanälen arbeitenden Master M_1,2 jeweils einer nicht näher dar­ gestellten Transformatorstation zugeordnet, während die Slaves S_{1. . .n} übliche in Haushalten installierte Elektrizi­ tätszähler - nachfolgend auch als Geräte bezeichnet - sind.

Jeder Master M_1,2 stellt einen Datenkonzentrator (Distribution Data Unit) für die diesem zugeordneten Geräte oder Slaves S_{1. . .n} dar. Eine anhand der Fig. 2 näher erläuterte Netzwerk- Management-Software richtet Verbindungen vom jeweiligen Ma­ ster M_1,2 zu den jeweiligen Slaves S_{1. . .n} ein. Aufgrund der vermaschten Netzwerktopologie müssen die Master M_1,2 auf un­ terschiedlichen Kanälen kommunizieren, um eine gegenseitige Überlagerung bei der Datenübertragung zu vermeiden. Die Her­ stellung der Verbindung eines jeden Slaves S_{1. . .n} zu dessen Master M₁ bzw. M₂ kann entweder direkt oder unter Nutzung ei­ ner Anzahl von Slaves S_{1. . .n} als sogenannte "Router" herge­ stellt werden. Dabei erlaubt die Vermaschung die Verbindung eines Slaves S_n zu verschiedenen Mastern M_1,2, wobei ein Slave S_n während des Betriebs von einem Master M_1,2 zum ande­ ren Master M_2,1 wechseln kann.

Bei der üblicherweise im Master-Slave-Modus erfolgenden Kom­ munikation werden Datenkollisionen aufgrund einer Datenüber­ tragung von unterschiedlichen Netzwerkpunkten zur selben Zeit vermieden. Durch die nachfolgend näher beschriebene Router­ funktionalität des oder jedes Slaves S_n ist darüber hinaus gewährleistet, daß eine von einem Slave S_n gesendete Antwort infolge einer Statusabfrage des entsprechenden Masters M_1,2 von den anderen Slaves S_{1. . .n-1} empfangen wird. Aufgrund dieser Durchbrechung des üblichen Master-Slave-Mechanismus werden - unter Vermeidung eines zusätzlichen Installationsaufwandes - als zusätzliche Funktionen eine automatische Aufnahme und eine automatische Netzwegzuordnung (Routing) infolge eines sogenannten "Logon-Request" auch solcher Slaves S_{1. . .n} reali­ siert, die keinen direkten Zugang zu einem der Master M_1,2 ha­ ben. Dies ist insbesondere für die Installation neuer, zu­ sätzlicher Geräte in das Netzwerk von besonderer Bedeutung, da diese im Anschluß an deren Installation noch keine logi­ sche Verbindung zu einem der Master M_1,2 aufweisen und somit von diesen zu diesem Zeitpunkt weder identifiziert noch em­ pfangen werden können. Dies gilt im Ausführungsbeispiel für die in den Entfernungsebenen E2 und E3 angeordneten oder dort neu installierten Slaves S_{6. . .10} bzw. S_{11. . .n}.

Zur Realisierung dieser zusätzlichen Routerfunktionalität weisen jeder Slave S_n ein Softwaremodul PLC und jeder Ma­ ster M_1,2 ein Softwaremodul PLC' auf. Das Softwaremodul PLC jedes Slaves S_n ist an eine zu dem entsprechenden Gerät ge­ führte Verbindungsleitung L_n zur Leistungsübertragung inklu­ sive der gesamten Netzwerkfunktionalität angeschlossen. Dabei werden in diesem Softwaremodul PLC eines jeden Slaves S_n zur Realisierung der Routerfunktionalität die untersten drei Schichten des ISO-Kommunikationsprotokolls umgesetzt. Die da­ rüberliegenden Schichten des ISO-Kommunikationsprotokolls werden in einem Anwendungsmodul MA (Meter Applications) des entsprechenden Slaves S_n umgesetzt. Dabei ist die Funktiona­ lität dieses Anwendungsmoduls MA unabhängig von der Funktio­ nalität des Softwaremoduls PLC, so daß jede Netzwerk-Manage­ ment-Funktion über diese Softwaremodule PLC abläuft.

Jeder Master M_1,2 weist einen Datenkonzentrator DC und ein le­ diglich auf Master-Ebene arbeitendes erstes Kommunikationsmo­ dul KM1 sowie ein zweites Kommunikationsmodul KM2 für eine funktional von dem Softwaremodul PLC' unabhängige Kommunika­ tion auf. Dabei ist das Softwaremodul PLC' zusätzlich in die Masterfunktionalität integriert.

Die Architektur einer in dem Softwaremodul PLC des oder jedes Slaves S_n und in dem Softwaremodul PLC' des oder jedes Ma­ sters M_1,2 realisierten Netzwerk-Nanagement-Software ist in Fig. 2 schematisch dargestellt. Dargestellt ist die Umsetzung der Netzwerk-Management-Software NMS und einer tabellarischen Netzwerk-Datenbank oder Datentabelle DT innerhalb der Schich­ ten des ISO-Kommunikationsprotokolls. Dabei realisiert die Netzwerk-Management-Software NMS einerseits über die dritte Schicht oder Netzwerkebene NL (Network Layer) die Weichen­ stellung für einen Datentransport entweder zu den nächst hö­ heren Schichten bis zur Anwendungsebene AL (Application Layer) oder zur nächst niedrigen, die Datentransport- oder Datenverbindungsebene DL (Data Link Layer) repräsentierenden Schicht des ISO-Kommunikationsprotokolls. Auf die Netzwerk­ ebene NL greift auch die Datentabelle DT zu, auf die wiederum die Netzwerk-Management-Software NMS zugreift. Dabei ist die Netzwerkebene NL transparent zu den darüberliegenden Schich­ ten.

Die Netzwerkebene NL benötigt Netzwerk-Informationsdaten, um Anfragen oder Informationen an die jeweils als Router-Slaves adressierten Slaves _{1. . .n} übertragen zu können. Die Funktio­ nen der Netzwerkebene NL sind daher für den Master M_1,2 sowie für jeden Slave S_n stets gleich, während die Netzwerkdaten und damit die Datentabellen DT sowie die Netzwerk-Management- Software NMS des Masters M_1,2 bzw. des Slaves S_n unterschied­ lich sind. Auch die zwischen der Netzwerkebene NL und der physikalischen Ebene PL (Physical Layer) liegende Datenver­ bindungsebene DL (Data Link Layer) ist transparent für die Netzwerk-Management-Software NMS. Innerhalb dieser Datenver­ bindungsebene DL, in der auch die Funktionalität einer Kolli­ sionserkennung und/oder Kollisionsvermeidung realisiert sein kann, werden ohne jegliche Master-Slave-Struktur Punkt- zu Punkt-Verbindungen zwischen den Slaves S_{1. . .n} hergestellt oder "Broadcasts" gesendet.

Die in Fig. 2 dargestellte Software-Architektur gilt sowohl für das Softwaremodul PLC' des Masters M_1,2 als auch für das Softwaremodul PLC des Slaves S_n. Dabei sind lediglich die Funktionalitäten der Netzwerk-Management-Software NMS sowie der Inhalt und die Form der Datentabelle DT für den Ma­ ster M_1,2 und für den Slave S_n unterschiedlich, während die jeweilige Struktur identisch ist. Daher wird nachfolgend durch entsprechende Indizierung auf die Netzwerk-Management- Software NMS_M des Masters M_1,2 bzw. die Netzwerk-Management- Software NMS_S des Slaves S_n bezug genommen. Bezüglich des Softwaremoduls PLC' des Masters M_1,2 dient die Netzwerkebe­ ne NL zur Datenaufnahme aus den höheren Ebenen TL, AL oder von der Netzwerk-Management-Software NNS_M sowie zur Übertra­ gung dieser Daten an die Datentransportebene DL.

Die vom Softwaremodul PLC' des Masters M_1,2 erstellte Datenta­ belle DT_M ist in Fig. 3 dargestellt. Der Rahmen der entspre­ chenden Datenverbindungsebene DL_M beinhaltet eine Adresse (Device Address) des jeweiligen Slaves S_n (Meter), die anhand der in Fig. 3 oberen Liste (Logon List) in eine Netzwerkadres­ se (Network Layer Address) überführt wird. Außerdem enthält der Rahmen der Datenverbindungsebene DL_M eine Anzahl von Fel­ dern für z. B. einen ersten und einen zweiten Router-Slave. Diese Felder werden anhand der in Fig. 3 unteren Liste (Rou­ ting List) mit einer Route zu dem jeweiligen Router-Slave R1, R2 belegt, wobei die hinsichtlich der zuverlässigen Erreich­ barkeit eines benachbarten Slaves S_n besten Router-Slave an­ hand eines Quality-Codes priorisiert werden. Die aufgeführ­ ten, von 0001h bis 7FEFh fort laufenden Adressen sind bei­ spielhaft gewählt, wobei die Adresse 7FFFh einen ungenutzten Router-Slave R1, R2 kennzeichnet.

Der Master M_1,2 gruppiert die mit diesem verbundenen und in der "Logon-Liste" aufgeführten Slaves S_n anhand deren Router- Slaves R1, R2 und legt dabei diese Liste als Netzwerk-Daten­ tabelle DT_M an, die zyklisch aktualisiert wird. Auf diese Weise werden mittels des Softwaremoduls PLC' des Masters M_1,2 jedem Slave S_n jeweils zwei Router-Slaves R1 und R2 in drei Netzwegstrecken oder Netzrouten L_n (Route Nr. 1,2 und 3) zu­ geordnet.

Analog erzeugt jeder Slave S_n mittels des Softwaremoduls PLC eine in Fig. 4 dargestellte Netzwerk-Datentabelle DT_S. In die in Fig. 4 untere Liste (Logon Request List) der Datentabel­ le D_S werden einerseits die Adressen derjenigen Router- Slaves R1, R2, R3 eingetragen, über die dieser Slave S_n er­ reichbar ist. Dazu sammelt der Slave S_n zunächst in der in Fig. 4 oberen Liste (Best Router List) die Adressen (Addr. Nr. 1, 2, 3) der von diesem über mögliche Kommunikationswege (Routen) empfangenen Slaves S_n, die nicht bereits von zwei Router-Slaves R1, R2 adressiert worden sind. Dabei werden diese Adressen innerhalb eines vorgebbaren Zeitrahmens T von z. B. 15 Minuten gespeichert, bevor der Slave S_n im Rahmen ei­ ner zyklischen Statusabfrage dem Master M_1,2 die drei ersten Adressen der "besten Nachbarn" über die zu diesen Adressen gehörenden Router-Slaves R1, R2 mitteilt. Dabei unterliegen die Zeitrahmen T_Z, d. h. die Wartezeiten, einem Alterungspro­ zeß, damit neuere Ergebnisse stärker berücksichtigt werden.

Somit kann ein zusätzlich installiertes Gerät über dessen Softwaremodul PLC während einer Statusabfrage des zugehörigen Masters M_1,2 zunächst Adressen von als möglichen Router- Slaves R1 bis R5 identifizierten Slaves S_n sammeln und diese hinsichtlich deren jeweiliger Erreichbarkeit priorisieren. Anschließend überträgt dieser Slave S_n die Adressen der prio­ risierten Router-Slaves R1 bis R3 über diese Router-Slaves R1 bis R3 an den entsprechenden Master M_1,2. Dessen Softwaremo­ dul PLC' veranlaßt eine entsprechende Eintragung in seiner Netzwerk-Datentabelle DT_M. Daraufhin veranlaßt der Master M_1,2 den höchst priorisierten Router-Slave R1 den zusätzlich in­ stallierten Slave S über die entsprechende Route (Route Nr. 1) in das Netzwerk NW aufzunehmen. Die weiteren gemelde­ ten Router-Slaves R1, R2 der übrigen Routen (Route Nr. 2 und 3) werden dann entsprechend deren Priorität (Quality) als Er­ satzrouten geführt. Das Softwaremodul PLC jedes Slaves S_n dient somit zur Identifizierung sowohl eines benachbarten Slaves S_n, z. B. eines neu installierten Slaves S_n, als auch mindestens eines benachbarten Slaves S_n als zukünftigen Rou­ ter-Slave R1, R2.

Die Netzwerk-Management-Software NMS - realisiert in den Software-Modulen PLC, PLC' - ermöglicht somit jedem Master M_1,2 die Zuordnung von im Ausführungsbeispiel drei Kommu­ nikationswegen (Routen) zu jedem Slave S_n. Die entsprechende Datentabelle DT_M, die zusätzlich zu diesen Routen oder Netz­ wegstrecken L_n auch die jedem Slave S_n zugeordneten Router- Slaves R1, R2 beinhaltet, wird vorzugsweise dynamisch aktua­ lisiert. Zudem ermöglicht die Netzwerk-Management-Soft­ ware NMS jedem neu installierten Slave S_n dessen benachbarten Slaves S_{1. . .n-1} zu empfangen und sich über die "besten Nach­ barn" - also quasi selbst - zur Aufnahme in das Netzwerk NW zu melden.

Auf diese Weise können ohne zusätzlichen Installationsaufwand in einfacher Weise neu installierte Geräte (Slaves) unabhän­ gig von deren Entfernung zum Datenkonzentrator DC (Master) in das Netzwerk NW aufgenommen werden. Dabei sind z. B. für Slaves S_n der dritten Entfernungsebene E3 jeweils zwei Rou­ ter-Slaves R1, R2 in der Datentabelle DT aufgeführt, während für solche der zweiten Entfernungsebene E2 nur jeweils ein Router-Slave R1 aufgeführt ist. Bei vom Master M_1,2 direkt empfangenen Slaves S_n der ersten Entfernungsebene E1 wird der Master M_1,2 selbst als Router-Slave R1 registriert.

Claims (12)

1. Verfahren zur Kommunikation innerhalb eines Netzwerks (NW), insbesondere zur Kommunikation innerhalb eines elek­ trischen Niederspannungsnetzwerks, bei dem von einem Master (M_1,2) an eine Vielzahl von Slaves (S_{1. . .n}) in einer Anzahl von Netzrouten (L_n) eine Statusabfrage ausgesendet wird, dadurch gekennzeichnet, daß ein vom Master (M_1,2) indirekt erreichbarer Slave (S_n) über einen benachbarten und als Router-Slave (R1, R2) identifizierten Slave (S_{1. . .n-1}) in das Netzwerk (NW) aufgenommen wird.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß eine nachfol­ gende Statusabfrage des Masters (M_1,2) über den Router-Slave (R1, R2) an den indirekt erreichbaren Slave (S_n) weiterge­ leitet wird.

3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß der Router- Slave (R1, R2) vom Master (M_1,2) zur Abfrage des indirekt er­ reichbaren Slaves (S_n) adressiert wird.

4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, daß jedem Slave (S_n) mindestens ein Router-Slave (R1, R2) zugeordnet wird, wobei zyklisch jeder Slave hinsichtlich dessen Router-Slave (R1, R2) abgefragt wird, und wobei der Adresse dieses Slaves (S_n) eine entsprechende Adresse des oder jedes Router-Slaves (R1, R2) zugeordnet wird.

5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, daß von einem zu­ sätzlich installierten und indirekt erreichbaren Slave hin­ sichtlich dessen Erreichbarkeit eine Anzahl benachbarter Slaves (S_n) als Router-Slaves (R1, R2) priorisiert wird, wo­ bei der zusätzlich installierte Slave (S_n) über den Router- Slave (R1, R2) mit der höchsten Priorität in das Netzwerk aufgenommen wird.

6. Verfahren nach Anspruch 5, dadurch gekennzeichnet,

• - daß während der Statusabfrage vom zusätzlich installierten Slave (S_n) zunächst Netzwerk-Adressen einer Anzahl benach­ barter Slaves (S_{1. . .n-1}) gespeichert werden,
• - daß über mindestens einen der benachbarten Slaves (S_{1. . .n-1}) der zusätzlich installierte Slave (S_n) beim Master (M_1,2) angemeldet wird, und
• - daß dem zusätzlich installierten Slave (S_n) vom Master (M_1,2) die Netzwerk-Adresse des oder jedes Router- Slaves (R1, R2) zugeordnet wird.

7. Verfahren nach Anspruch 5 oder 6, dadurch gekennzeichnet, daß dem zusätz­ lich installierten Slave (S_n) vom Master (M_1,2) eine Netzwerk- Adresse zugewiesen wird.

8. Kommunikationsfähiges Netzwerk mit einem Master und mit einer Vielzahl von Slaves (S_n) in einer Anzahl von mit dem Master (M_1,2) verbundenen Netzrouten (L_n), wobei der Master zur Statusabfrage jedes Slaves (S_n) ausgelegt ist, gekennzeichnet durch eine Netzwerk-Manage­ ment-Software (NMS) zur Zuordnung von Router-Slaves (R1, R2) zu dem oder jedem Slave (S_n) und zum Verbindungsaufbau zwi­ schen benachbarten Slaves (S_n).

9. Kommunikationsfähiges Netzwerk nach Anspruch 8, dadurch gekennzeichnet, daß die Netzwerk- Management-Software (NMS) ein dem Master (M_1,2) zugeordnetes Softwaremodul (PLC') zur Generierung mindestens eines Router- Slaves (R1, R2) für den oder jeden Slave (S_n) und ein dem oder jedem Slave (S_n) zugeordnetes Softwaremodul (PLC) zur Identifizierung eines benachbarten Slaves (S_n) aufweist.

10. Kommunikationsfähiges Netzwerk nach Anspruch 9, dadurch gekennzeichnet, daß das Software­ modul (PLC') des Masters (M_1,2) zur Generierung mindestens ei­ ner Ersatzroute (L_n) ausgelegt ist.

11. Kommunikationsfähiges Netzwerk nach Anspruch 9 oder 10, dadurch gekennzeichnet, daß das Software­ modul (PLC') des Masters (M_1,2) zur Zuordnung einer Netzwerk- Adresse zu einem zusätzlich installierten Slave (S_n) ausge­ legt ist.

12. Kommunikationsfähiges Netzwerk nach einem der Ansprüche 8 bis 11, dadurch gekennzeichnet, daß das Software­ modul (PLC) des Slaves (S_n) zur Generierung einer Prioritä­ tenliste mit Netzwerk-Adressen benachbarter Slaves (S_{1. . .n}) sowie zur Weiterleitung einer solchen von einem benachbarten Slave (S_n) erstellten Liste an den Master (M_1,2) ausgelegt ist.