DE69938216T2

DE69938216T2 - Integriertes netzwerkmanagement-verfahren für ein echelon netzwerk

Info

Publication number: DE69938216T2
Application number: DE69938216T
Authority: DE
Inventors: Robert A. Midlothian ADAMS; Ottie E. Mechanicsville ALLGOOD; Andrew T. Richmond SAUNDERS
Original assignee: TAC LLC
Current assignee: TAC, LLC, LOVES PARK, ILL., US
Priority date: 1998-05-05
Filing date: 1999-05-03
Publication date: 2009-04-30
Anticipated expiration: 2019-05-04
Also published as: EP1000392B1; US6654750B1; DE69938216D1; CA2296100A1; WO1999057621B1; US6185566B1; EP1000392A2; WO1999057621A3; CA2296100C; WO1999057621A2; EP1000392A4

Description

TECHNISCHES GEBIET DER ERFINDUNG
Die Erfindung betrifft allgemein Netzwerkverwaltungssysteme. Insbesondere betrifft die vorliegende Erfindung ein Verfahren und Systeme zur Netzwerkverwaltung in einem ECHELON-Netzwerk.
TECHNISCHER HINTERGRUND DER ERFINDUNG
Die Anwendung von Computervernetzungsverfahren ist in schnellem Wachstum begriffen. Computernetze werden gegenwärtig verwendet, um viele verschiedene Geräte von industriellen Steuerungssystemen bis zu Haushaltsgeräten miteinander zu verbinden. In diesen entstehenden Netzwerken werden viele "eingebettete" Computer an Netzwerke angeschlossen. Der Begriff "eingebetteter" Computer, wie er hier gebraucht wird, bezieht sich auf ein Gerät, das einen Prozessor und in einigen Fällen eine begrenzte Anwender-E/A ("Eingabe und/oder Ausgabe") aufweist, dem aber eine komplexe Anwenderschnittstelle fehlt, wie z. B. ein großer Bildschirm und eine Volltastatur. Der Begriff "Knoten" bezieht sich auf eine Einrichtung, die mit dem Netzwerk verbunden und mit anderen Netzwerkeinrichtungen kommunikationsfähig ist. Entsprechend bezieht sich der Begriff "eingebetteter Knoten" auf eine Einrichtung, die einen eingebetteten Computer enthält, der mit einem Netzwerk verbunden und mit anderen Netzwerkeinrichtungen oder Knoten kommunikationsfähig ist. Der Begriff "lokal" oder "lokale Kopplung" bezieht sich auf direkte Kopplung zu anderen Netzwerkknoten durch einen Kommunikationsbus ohne dazwischenliegende Einrichtungen. Umgekehrt bezieht sich der Begriff "entfernt" oder "Fernkopplung" auf eine indirekte Kopplung zu anderen Knoten, d. h. über eine andere Einrichtung, wie z. B. durch "Tunnelung" durch ein an deres Netzwerk oder eine andere Einrichtung, oder durch ein Modem.
Zum Beispiel offenbart das Dokument US 5 453 924 ein verteiltes Netzwerk-Produktanwendersteuerungssystem mit Anwendung objektorientierter Software, Windows-Ankopplung, verteilter und ECHELON LonWorks-Netzwerktechnologie.
Eingebettete Computer haben zwar in der Vergangenheit über Netzwerke kommuniziert, aber die sie unterstützenden Netzwerkverwaltungssysteme wiesen verschiedene Beschränkungen auf. Der Begriff "Netzwerkverwaltung", wie er hier gebraucht wird, bezieht sich auf die Verwaltung von Konfigurationen, Verbindungen und anderen Parametern, die mit dem jeweiligen Netzwerk verbunden sind. In den meisten Fällen, wo eine Netzwerkverwaltungsfunktionalität erforderlich ist, sind größere Computer (z. B. eine Nutzer-Workstation) eingesetzt worden, um eine solche Funktionalität bereitzustellen. In Netzwerkumgebungen, in denen solche größeren Computer unpraktisch oder unausführbar sind, ist dies problematisch. Zum Beispiel ist es in einem kleinen bis mittleren HVAC-System (d. h. Heizungs-, Lüftungs- und Klimatisierungssystem) wirtschaftlich nicht klug, einen größeren Computer am Netzwerk mit der eingebetteten Steuereinrichtung einzubauen. Daher ist es für die Durchführung jeder Netzwerkverwaltungsfunktion üblich, daß ein Techniker mit einem tragbaren Computer ankommt und ihn an das Netzwerk anschließt, wodurch bestimmte Netzwerkverwaltungsfunktionen erleichtert werden.
Als ein Vernetzungsbeispiel werden ECHELON-Netzwerke (entwickelt von der ECHELON Corporation, Palo Alto, CA) in einer Vielzahl von Anwendungen mit eingebettetem Prozessor eingesetzt und eignen sich besonders gut für Vernetzungsprozess- und Umweltschutzeinrichtungen. Der Begriff "ECHELON-Netzwerk", wie er hier gebraucht wird, bezieht sich auf ein Netzwerk, das aus Einrichtungen oder Knoten besteht, die ein LONTALK-Protokoll implementieren. LONTALK ist ein Warenzeichen der oben erwähnten ECHELON Corporation und bezeichnet ein Protokoll, das durch Anwendungen zur Kommunikation mit Knoten in einem ECHELON-Netzwerk angewandt wird. Eine Übersicht des LONTALK-Protokolls wird beschrieben in Abschnitt 8 von Motorola LonWorks Technology Device Data, Rev. 3.1 (nachstehend "Lon-Works Tech. Publication"), veröffentlicht 1997 durch Motorola Corporation, Palatine, Illinois. Das LONTALK-Protokoll stellt ein Mittel zum Datenaustausch zwischen Einrichtungen unter Verwendung von Netzwerkvariablen bereit, wie in den Abschnitten 7.2 und 7.3 der LonWorks Tech. Publication beschrieben. Innerhalb einer Echelon-Einrichtung gibt es verschiede Datenstrukturen, die richtig konfiguriert werden müssen, damit die Einrichtung einwandfrei funktioniert. Diese Datenstrukturen werden in Anhang A der LonWorks Tech. Publication beschrieben. Die im LONTALK-Protokoll definierten Nachrichten, die benötigt werden, um diese verschiedenen Datenstrukturen zu konfigurieren und im übrigen die Einrichtung zu steuern und zu überwachen, werden im Anhang B beschrieben. Ein Beispiel einer Netzwerkverwaltungseinrichtung für ein ECHELON-Netzwerk ist das in 1 dargestellte Modell NSS-10 von ECHELON Corp. Das NSS-10 enthält einen in einer Host-Station untergebrachten ECHELON-Knoten (d. h. einen ECHELON-Chipsatz mit einem Prozessor, der für die Ausführung von Nutzeranwendungen verfügbar ist), der eine Netzwerkdatenbank und eine lokal daran angeschlossene, einzelne Clientanwendung enthält. Es wird nur eine einzige, lokale Clientanwendung unterstützt. Ein weiteres Beispiel eines Netzwerkverwaltungssystems nach dem Stand der Technik für ein ECHELON-Netzwerk ist das in 2 dargestellte Modell LNS-System von ECHELON Corp. LNS ist eine nicht eingebettete Lösung und ist zu teuer und unpraktisch für viele ECHELON-Netzwerke. Zum Beispiel müßte das LNS, da es nicht eingebettet ist, an das ECHELON-Netzwerk ferngekoppelt werden, um die in der HVAC-Industrie üblichen Netzwerkarchitekturen zu unterstützen, d. h. durch "Tunnelung" durch andere Netzwerke oder durch ein Modem mit serieller Schnittstelle. Eine derartige Fernkopplung führt im allgemeinen einen Signaltakt und andere Komplexitäten in das System ein.
Daher existiert kein Netzwerkverwaltungssystem für ein ECHELON-Netzwerk, das einbettungsfähig und kostengünstig ist und mehrere Clients unterstützen kann. Die vorliegende Erfindung bietet eine Lösung für dieses Problem.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Der als die vorliegende Erfindung betrachtete Gegenstand wird im abschließenden Teil der vorliegenden Patentbeschreibung besonders aufgezeigt und explizit beansprucht. Die Erfindung läßt sich jedoch, sowohl bezüglich der Organisation als auch bezüglich des praktischen Ausführungsverfahrens, zusammen mit weiteren Aufgaben und Vorteilen der Erfindung, am besten durch Bezugnahme auf die nachstehende ausführliche Beschreibung in Verbindung mit den beigefügten Zeichnungen verstehen. Dabei zeigen:
die 1–2 Netzwerkverwaltungs-Implementierungen in ECHELON-Netzwerken nach dem Stand der Technik;
die 3–5 Systemdiagramme von Komponenten von Netzwerkverwaltungssystemen gemäß Ausführungsformen der vorliegenden Erfindung;
6 ein Datenflußdiagramm des Nachrichtenflusses durch den Netzwerkdatenbankverwaltungsystem gemäß einer Ausführungsform der vorliegenden Erfindung;
7 ein Datenflußdiagramm des Nachrichtenflusses durch den Netzwerk-Dienstanbieter gemäß einer Ausführungsform der vorliegenden Erfindung;
8 ein Sitzungszustandsdiagramm gemäß einer Ausführungsform der vorliegenden Erfindung;
9 eine Darstellung von Verbindungstabellen gemäß einer Ausführungsform der vorliegenden Erfindung; und
10 eine Darstellung von Adreßbüchern bzw. Adressentabellen gemäß einer Ausführungsform der vorliegenden Erfindung.
AUSFÜHRLICHE BESCHREIBUNG EINER BEVORZUGTEN AUSFÜHRUNGSFORM
In den Figuren sind verschiedene Elemente eines ECHELON-Netzwerkverwaltungsystems gemäß der vorliegenden Erfindung abgebildet. Ein wichtiger Aspekt der vorliegenden Erfindung ist die Erkenntnis, daß in einem ECHELON-Netzwerkverwaltungsystem ein besonders hohes Signalverkehrsvolumen zwischen einer Netzwerkdatenbank und den Knoten erzeugt werden kann, wenn ein Dienst ausgeführt wird. Die vorliegende Erfindung enthält daher einen eingebetteten Knoten 10, 10', 16 (3, 4 bzw. 5), der die Netzwerkdatenbank und Kommunikationselemente enthält und lokal an ein ECHELON-Netzwerk 14 gekoppelt ist (3 und 5). Diese lokale Kopplung bietet einen Anschluß mit relativ großer Bandbreite, um den relativ hohen Verkehr zwischen der Netzwerkdatenbank und den Knoten für eine verbesserte Systemleistung gegenüber Konfigurationen nach dem Stand der Technik unterzubringen. Die lokale Kopplung der Netzwerkdatenbank an das Netzwerk beseitigt die Notwendigkeit der Tunnelung verschiedener Meldungen, die benötigt werden, um einen Netzwerkdienst auszuführen, wenn eine gestufte Architektur verwendet wird, die in der HVAC-Industrie üblich ist.
Genauer gesagt, wie in 3 dargestellt, enthält der eingebettete Knoten 10 eine Netzwerkdatenbank (Netzwerk-DB) 11, die an einen Netzwerkdatenbank-Manager (Netzwerk-DBMS) 13 gekoppelt ist. Eine Kommunikationsschicht 31 enthält serielle bzw. COM-Schnittstellen 32 und 33, die so angepaßt sind, daß sie den Knoten 10 über ein herkömmliches Netz 15 an eine Workstation 12 bzw. an ein ECHELON-Netzwerk 14 ankoppeln. Wie dargestellt, dient die Kommunikationsschicht 31 zum Anbschluß der Netzwerkdatenbank (Netzwerk-DB) über Netzwerk-DBMS 13 an diese Netzwerke. Der Netzwerk-DBMS 13 ist für die Vernetzung von Verwaltungs- bzw. Management-Meldungen im ECHELON-Netzwerk 14 oder der Workstation 12 verantwortlich, so daß die Anschließbarkeit bzw. Konnektivität des Netzwerks, variable und andere Informationen entsprechend der LONTALK-Spezifikation aufrechterhalten werden.
In einer in 4 dargestellten alternativen Ausführungsform enthält der Knoten 10' eine Kommunikationsschicht 31', die eine einzelne COM-Schnittstelle 33 enthalten kann, die einen LONCOM-(Warenzeichen der SIEBE Corporation) Kommunikationsstapel 45 enthält, der mit einem ECHELON-Netzwerk 14 gekoppelt ist, das seinerseits mit einer Workstation 12' gekoppelt ist.
Die Workstations 12 und 12' enthalten weitere Elemente, die in den 3 und 4 abgebildet sind. Insbesondere kommunizieren ein oder mehrere Anwendungsprogramme 39 mit einem Netzwerkdienstanbieter (Netzwerk-SP) 35 über eine Netzwerkdienstanbieter-Anwendungsprogrammierschnittstelle 37 (Netz werk-SP-API). Der Netzwerkdienstanbieter (Netzwerk-SP) 35 ist an eine Kommunikationsschicht gekoppelt. Wie in 3 dargestellt, kann eine Kommunikationsschicht 34 verschiedene Kommunikationsstapel enthalten, wie z. B. einen BACNET-Kommunikationsstapel 43 (Warenzeichen von 'ASHRAE' (der American Society of Heating, Refrigeration and Air Conditioning Engineers)), einen seriellen Kommunikationsstapel 41 und irgendeinen anderen geeigneten Kommunikationsstapel 44, so daß verschiedene Kommunikationsprotokolle durch die Workstation 12 unterstützt werden. In der in 4 dargestellten Ausführungsform enthält eine Kommunikationsschicht 34' einen LONCOM-Kommunikationsstapel 45 zum Verbinden der Workstation 12' mit einem ECHELON-Netzwerk 14.
Obwohl die Netzwerkdatenbank-Manager (Netzwerk-DBMS) 13, die Netzwerkdatenbank (Netzwerk-DB) und der Netzwerkdienstanbieter (Netzwerk-SP) vorzugsweise eingebettet sind, wie hierin diskutiert, können sie in einem einzigen Computer resident sein, z. B. in einer Workstation 16, wie in 5 dargestellt. Die Netzwerk-DB 11 ist über Netzwerk-DBMS 13 an die Kommunikationsschicht 31' gekoppelt. Ferner enthält, wie oben diskutiert, die Kommunikationsschicht 31' einen LONCOM-Kommunikationsstapel 45 für die Verbindung mit einem ECHELON-Netzwerk (nicht dargestellt).
Funktionell sind die 6–7 Nachrichtenflußdiagramme, die den Netzwerk-DBMS und dem Netzwerk-SP entsprechen. Wie zunächst aus 6 erkennbar, enthält ein Netzwerkdatenbank-Managersystem (Netzwerk-DBMS-System) 61 eine Warteschlange 63 zur Verarbeitung eines Nachrichtenflusses. Nachrichten treffen über zwei Mechanismen ein, wobei der erste eine Netzwerkdatenbank-Manager-Empfangsfunktion/-prozedur 65 für Netzwerknachrichten (NDBMReceiveNetMsg()) ist, die für den Empfang von Netzwerk-DBMS-Anforderungen und Feldantworten von der Kommunikationsschicht verantwortlich ist. Zeitüberschreitungssignale für nicht empfangene Nachrichten/Antworten werden durch die Netzwerkdatenbank-Manager-Zeitüberschreitungsprozedur 67 (NDBMtimeout ()) zum Netzwerkdatenbank-Managersystem (Netzwerk-DBMS-System) 61 übermittelt. Zeitüberschreitungssignale werden durch das Betriebssystem des Hauptrechners gene riert. Das Netzwerk-DBMS-System 61 sendet Nachrichten an ECHELON-Einrichtungen unter Verwendung der Netzwerk-DBMS-Nachrichtensendefunktion 69 (NDBMSendMsg ()), die über die Kommunikationsschicht kommuniziert.
Der Netzwerk-SP-Nachrichtenfluß ist in 7 dargestellt. Ein Netzwerk-SP-System 71 empfängt Nachrichten über eine Warteschlange 73 von verschiedenen Quellen. Zunächst treffen ankommende Antworten von lokalen und entfernten Client-Anwendungen und den Netzwerk-DBMS über die Netzwerk-SP-Empfangsfunktion/-prozedur 75 für Feldnachrichten (NSPReceive-FieldMsg ()) ein. Dienstaufrufe treffen über die Netzwerkdienstaufruffunktion/-prozedur 77 (NSPInvokeService ()) ein. Dienstaufrufe sind Netzwerkverwaltungs-Dienstanforderungen von Client-Anwendungen. Ferner treffen Zeitüberschreitungssignale für vom Netzwerkdienstanbieter gesendete unbestätigte Meldungen (vom Betriebssystem) über die Netzwerkdienstanbieter-Zeitüberschreitungsfunktion/-prozedur 79 (NSPTimeout ()) ein.
Abgehende Meldungen vom Netzwerk-SP-System 71 können verschiedene Wege einschlagen. Eine Feldnachrichtensendefunktion/-prozedur 81 (NSPSendLonMessage ()) bearbeitet das Senden von Netzwerk-DBM-Anforderungen an das Netzwerk (die Netzwerk-DBMS können lokal oder entfernt sein). Dienstergebnisse werden unter Verwendung einer Client-Rückruffunktion/-prozedur 83 (NSPClientCallback ()) an Clients zurückgegeben.
Die Softwarestrukturen und Funktionsaufrufe, die im Betrieb der Netzwerk-DBMS und des Netzwerk-SP verwendet werden, werden in dem beigefügten Anhang ausführlich beschrieben und im folgenden zusammengefaßt.
Die Netzwerkdienstanbieter-Anwendungsprogrammierschnittstelle (Netzwerk-SP-API) wird in den Abschnitten 6.n des Anhangs erwähnt. Kurz gesagt, ist die Netzwerk-SP-API der Satz von Funktionen, die Anwendungen den Zugriff auf die Dienste des Netzwerkdienstanbieters (Netzwerk-SP) und indirekt der Netzwerkdatenbank-Manager (Netzwerk-DBMS) ermöglichen. Beginnend im Abschnitt 6.2.1, initialisiert die Funktion NSPInit() den Netzwerk-SP. Dadurch können mehrere Exemplare des Netzwerk-SP erzeugt werden, um mehrere logische Netze zu verarbeiten.
Die Funktion NSPClose () wird im Abschnitt 6.2.2 beschrieben. Diese Funktion schreibt eine Ende-Meldung in den Network-SP ein. Der Network-SP räumt dann auf und beendet das Programm.
Bevor irgendwelche Netzwerkverwaltungsdienste angefordert werden, muß sich eine Anwendung mit einem Anruf an NSPRegisterClient () als Client registrieren, wie in Abschnitt 6.2.3 beschrieben, und eine Client-Zugriffsnummer empfangen. Diese Zugriffsnummer wird durch den Netzwerk-SP 35 aufgerufen, um Antworten auf Dienstaufrufe zu geben oder Ausnahmemeldungen weiterzuleiten, die von den Netzwerk-DBMS 13 empfangen werden. Ein Zeiger auf eine Funktion vom Typ NSP_CLIENT_CALLBACK wird gleichfalls zum Netzwerk-SP weitergeleitet. Diese Funktion wird durch den Netzwerk-SP aufgerufen, um Antworten auf Dienstaufrufe zu geben oder Dienst-Pin-Meldungen von den Netzwerk-DBMS weiterzuleiten. Durch die erfolgreiche Registrierung wird außerdem der Client zur Liste der registrierten Netzwerk-SP-Clients hinzugefügt. Umgekehrt wird durch die im Abschnitt 6.2.4 beschriebene Funktion NSPDeregisterClient () der Client aus der Liste der registrierten Netzwerk-SP-Clients entfernt.
Ein Client ruft einen Dienst über den Netzwerk-SP auf, indem er einen Anruf an die im Abschnitt 6.2.5 beschriebene Funktion NSPInvokeService () durchführt. Als Antwort auf den Aufruf leitet der Netzwerk-SP den Aufruf entweder den Netzwerk-DBMS zu, oder der Netzwerk-SP verarbeitet den Aufruf direkt. Antworten werden vom Netzwerk-SP an den aufrufenden Client zurückgegeben.
Jede Client-Anwendung, die Netzwerkverwaltungsdienste aufruft, liefert eine Rückruffunktion, die Antworten auf Dienstaufrufe verarbeitet. Die Rückruffunktion wird bei einem Aufruf von NSPRegisterClient () zusammen mit der Rückrufzugriffsnummer zum Netzwerk-SP weitergeleitet. Diese Client-Rückruffunktionen werden im Abschnitt 6.2.6 diskutiert.
Der Netzwerkdienstanbieter (Netzwerk-SP) wird in den Abschnitten 7.n des Anhangs erwähnt. Kurz beschrieben, wird der Netzwerk-SP-Prozeßstrang gestartet, wenn die Anwendung NSPInit () aufruft. Nach der Initialisierung wartet der NSP-Prozeßstrang darauf, daß Meldungen in seiner Warteschlange eintreffen. Meldungen können als Anforderungen von der Anwendung (die durch NSPInvokeService () in die Warteschlange eingereiht werden), Zeitüberschreitungsanzeigen von den Transaktionszeitgebern und als Antworten oder Ereignisse vom Netzwerk-DBMS eintreffen.
Wie in Abschnitt 7.3 diskutiert, startet die Initialisierung des Netzwerk-SP mit der Erzeugung einer Nachrichtenwarteschlange für den Empfang und die Sendung von Nachrichten. Als nächstes wird eine Kommunikations- bzw. Nachrichtenverbindungsschicht initialisiert und verarbeitet die Übertragung von Informationen vom Netzwerk-SP zu einem entfernten Netzwerk-DBMS 13. Als nächstes wird der Netzwerk-DBMS lokalisiert, da er entweder lokal oder entfernt bzw. abgesetzt sein kann. Wenn kein Netzwerk-DMBS gefunden werden kann, mißlingt die Initialisierung. Im allgemeinen wird der Netzwerk-DBMS vor der Initialisierung des Netzwerk-SP initialisiert.
Die Funktionsweise des Netzwerk-SP wird in Abschnitt 7.4 beschrieben. In Zusammenfassung seiner Funktionsweise bleibt der Netzwerk-SP im Ruhezustand, bis eine Meldung eintrifft. Dann werden in Abhängigkeit von der Art der Meldung unterschiedliche Ausführungswege eingeschlagen. Wenn die Meldung eine Dienstanforderung von einer Anwendung ist, dann wird die Anforderung an das Netzwerk weitergeleitet. Ein Zeitgeber wird gestartet, der auf die Beendigung der Anforderung mittels einer Bestätigungsantwort wartet. Der Zeitgeber ist konfigurierbar, und konkrete Wartezeiten sind von der jeweiligen Konfiguration abhängig.
Wenn die Meldung eine Antwort ist (z. B. auf eine Dienstanforderung), dann wird der Zeitgeber gestoppt, und die Antwort wird an die Anwendung zurückgesandt. Wenn eine Zeitüberschreitung auftritt (z. B. wenn der Antwortzeitgeber abläuft), dann wird über die Client-Rückruffunktion/-prozedur 83 eine Zeitüberschreitungs-Antwort an die Anwendung zurückgesandt.
In den Abschnitten 7.5.n werden verschiedene wahlfreie Netzwerk-SP-Dienste dargestellt, die benutzt werden können, um zusätzliche Funktionalität für den Netzwerk-SP bereitzustellen. Zu diesen Diensten gehören NS_EXTRACT_XIF (Abschnitt 7.5.1) der eingesetzt werden kann, um die externe Schnittstelle eines Knotens aus seinen Eigenidentifizierungs-/Eigendokumentationsdaten zu extrahieren.
NS_DOWNLOAD_APPLICATION (Abschnitt 7.5.2) kann benutzt werden, um eine neue Anwendung in einen Knoten herunterzuladen. NS_READ_CP, (7.5.3), kann benutzt werden, um einen Lon-Mark-(Warenzeichen der ECHELON Corp.) Konfigurationseigenschaftswert aus einem Knoten auszulesen. Umgekehrt kann NS_WRITE_CP (7.5.4) benutzt werden, um einen LonMark-Konfigurationseigenschaftswert in einen Knoten einzuschreiben.
In den Abschnitten 8.n des Anhangs werden Operationen und Funktionsaufrufe des Netzwerk-DBMS beschrieben. Kurz beschrieben, wird der Netzwerk-DBMS mit einem Aufruf von NetDB-MInitialize () gestartet. Er besteht aus einem einzigen Prozeßstrang und zwei Warteschlangen: einer Nachrichtenschlange und einer Warteschlange. Die Warteschlange dient zum Speichern von anstehenden Dienstaufrufen. Die Nachrichtenschlange empfängt Dienstaufrufe vom Netzwerk-SP, antwortet auf Netzwerkverwaltungsbefehle, die vom Netzwerk-DBMS (NDBM) gegeben wurden, Transaktions-Zeitüberschreitungen und Dienst-Pin-Anzeigen. Der Netzwerkdatenbank-Manager (NDBM) führt nur einen Dienst auf einmal durch. Wenn er sich im Prozeß der Verarbeitung eines Dienstes befindet und ein weiterer Dienstaufruf eintrifft, werden der zweite und alle nachfolgenden Aufrufe in die Warteschlange eingereiht. Nachdem der erste Dienst beendet ist, entfernt der NDBM den zweiten Aufruf aus der Warteschlange und beginnt mit seiner Verarbeitung.
Beginnend im Abschnitt 8.3, wird die Netzwerk-DBMS-Initialisierung beschrieben. Während der Initialisierung werden die Nachrichtenschlange und eine Warteschlange erzeugt, die Kommunikationsverbindungsschicht wird geöffnet, und es wird eine Konfliktprüfung durchgeführt, um sicherzustellen, daß nur ein Netzwerk-DBMS existiert.
Die Funktionsweise des Netzwerkdatenbank-Managers (Netzwerk-DBMS) wird im Abschnitt 8.4 beschrieben. Um die Funktionsweise zusammenzufassen; eine Hauptschleife beginnt damit, daß der Netzwerk-DBMS auf das Eintreffen von Meldungen in der Nachrichtenschlange wartet. In Abhängigkeit vom Typ der empfangenen Meldung werden unterschiedliche Maßnahmen ergriffen. Wenn die Meldung ein Dienstaufruf ist, und wenn gerade ein Dienst ausgeführt wird, dann wird der Aufruf in die Warteschlange eingereiht. Wenn gerade kein aktueller Dienst ausgeführt wird, dann wird die geeignete Netzwerkdatenbank- oder Netzwerkmaßnahme ergriffen. Wenn im Fall einer Antwort der Netzwerkverwaltung der betreffende Befehl abgeschlossen ist, wird die Antwort zu der Anwendung gesendet, andernfalls wird der nächste Befehl der Netzwerkverwaltung gesendet. Ferner kann ein Meldungstyp eine Zeitüberschreitung für eine nicht gegebene Antwort sein, oder eine Dienst-Pin nach dem LONTALK-Standard oder -Protokoll.
Die Anweisung WHILE state==IDLE wird einmal abgearbeitet, da der Zustand in der nachfolgenden Anweisung modifiziert wird. Es gibt bestimmte Dienste, die viele Transaktionen erfordern (d. h. die Erzeugung von Meldungen der ECHELON-Netzwerkverwaltung, die an einen Knoten zu senden sind, der das Warten auf eine Antwort erfordert). Es gibt auch einige Dienste, die keine Transaktionen erfordern und daher den Zustand sofort auf IDLE (Ruhezustand) zurückführen. Im letzteren Fall verarbeitet die WHILE-Schleife, die in der DO-Schleife enthalten ist, eine weitere Meldung aus der Warteschlange, wenn sich dort eine Meldung befindet.
Die Abschnitte 8.5 und 8.6 des Anhangs enthalten Dienstmeldungsformate des Netzwerkdatenbank-Managers bzw. Anforderungs-/Antwortformate des Netzwerk-DBMS.
In den Abschnitten 8.6.n werden die Funktionsaufrufe des Netzwerkdatenbank-Managers beschrieben, die zur Durchführung von Netzwerkdatenbank-Diensten benutzt werden. Zunächst fügt die Dienstanforderung NS_ADD_NODE einen Knoten in die Knotentabelle ein, wie im Abschnitt 8.6.1 beschrieben. Der Algorithmus zum Hinzufügen eines Knotens zur Netzwerkdatenbank beginnt mit der Prüfung, ob der Knoten bereits in der Netzwerkdatenbank existiert (d. h. um eine Redundanz zu beseitigen). Danach wird die Existenz des Geräts im Netzwerk überprüft, und die relevanten ECHELON-bezogenen Informationen werden ermittelt. Der Knoten wird dann vom Netz getrennt bzw. off-line geschaltet, konfiguriert, und danach an das Netz angeschlossen bzw. on-line geschaltet.
Die Entfernung eines Knotens wird mit der im Abschnitt 8.6.2 beschriebenen Dienstanforderung NS_REMOVE_NODE durchgeführt. Gemäß dieser Funktion wird der Knoten aus der Knotentabelle entfernt und in einem nichtkonfigurierten Zustand gebracht. Zusammenfassend wird ein Knoten entfernt, indem zunächst überprüft wird, ob er gegenwärtig ein Element der Datenbank und nicht Teil einer Verbindung ist. Dann wird er aus allen Adressengruppen entfernt, in denen er enthalten ist, in einen nichtverbundenen bzw. off-line und nichtkonfigurierten Zustand gebracht und aus der Netzwerkdatenbank entfernt.
Ein Knoten kann mit der Dienstanforderung NS_REPLACE_NODE von Abschnitt 8.6.3 durch ein neues Gerät ersetzt werden. Diese Dienstanforderung kann benutzt werden, wenn ein Gerät ausfällt und ausgetauscht werden muß. Dadurch kann das neue Gerät als der gleiche Knoten mit den gleichen Netzwerkverbindungen wie das ausgefallene Gerät konfiguriert werden. Algorithmisch ist der Austausch eines Knotens ähnlich dem Hinzufügen eines Knotens, jedoch werden zusätzlich zu dem Verbinden bzw. on-line-Schalten und Konfigurieren des neuen Knotens dem neuen Knoten Netzwerkvariable zugewiesen.
Die in den Abschnitten 8.6.4 und 8.6.5 beschriebenen Netzwerkverwaltungs-Dienstanforderungen NS_ADD_CONNECTION und NS_REMOVE_CONNECTION werden benutzt, um innerhalb der LONTALK-Konfiguration Netzwerkvariablenverbindungen hinzuzufügen und zu entfernen. Um eine Verbindung hinzuzufügen, wird überprüft, ob die Knoten, zwischen denen die Verbindung existiert, in der Netzwerkdatenbank existieren und aktiv sind. Danach werden Formatanpassungsprobleme der Variablen gelöst, und Adreßbücher und Netzwerkvariablentabellen werden so aktualisiert, daß sie die hinzugefügte Verbindung widerspiegeln. Entsprechend enthält das Entfernen einer Verbindung die Überprüfung, ob die Verbindung existiert, die Abtrennung jedes Ziels und die Entfernung der Netzwerkvariablen des Ziels aus der Netzwerkdatenbank. Wenn alle Ziele innerhalb der Verbindung gelöscht sind, dann wird die gesamte Verbindung aus der Netzwerkdatenbank entfernt.
Die explizite Erzeugung von Adressengruppen wird durch die Dienstanforderung NS_ADD_ADDRESS_GROUP von Abschnitt 8.6.6 und die Dienstanforderung NS_REMOVE-ADDRESS_GROUP von Abschnitt 8.6.7 erleichtert. Die Dienstanforderung NS_ADD_ADDRESS_GROUP kann genutzt werden, um eine Adressengruppe hinzuzufügen oder zu modifizieren. Dies kann notwendig sein, falls sich eine Anwendung in irgendeinem Knoten befindet, die eine explizite Meldung unter Verwendung einer Gruppenadressierung senden muß. Die Dienstanforderung NS_REMOVE_ADDRESS_GROUP kann benutzt werden, um eine Adressengruppe aus der AddressGroupTable (Adressengruppentabelle) der Netzwerkdatenbank zu entfernen.
Zum Hinzufügen einer Adressengruppe wird zunächst ermittelt, ob die Gruppe gegenwärtig existiert. Wenn die Gruppe nicht existiert, wird die Gruppe in der Netzwerkdatenbank erzeugt. Dann wird die Adressentabelle in jedem betroffenen Knoten aktualisiert. Im Hinblick auf die Löschung einer Adressengruppe wird zunächst festgestellt, daß keine Verbindungen diese Gruppenadresse gegenwärtig nutzen. Wenn die Gruppenadresse nicht genutzt wird, dann wird die Gruppe aus der Datenbank entfernt, und die Adressentabelle wird in jedem betroffenen Knoten aktualisiert.
Gelegentlich benötigt die Netzwerkdatenbank eine Rekonstruktion. Die im Abschnitt 8.6.8 beschriebene Dienstanforderung NS_RECOVER_DATABASE rekonstruiert die Netzwerkdatenbank durch eine Abfrage der Netzwerktopologie. Kurz gesagt, "erlernt" diese Funktion die Topologie und Konfiguration des Netzwerks. Diese Dienstanforderung wird aufgerufen, wenn die Netzwerkdatenbank fehlt, verdächtig ist oder ein neues Netzwerk installiert worden ist. Funktionell sendet die Dienstanforderung eine allgemeine Netzwerkmeldung, die Antworten von jedem Knoten anfordert, und konstruiert dementsprechend die Knotentabelle. Sobald die Knotentabelle aufgebaut worden ist, wird jeder Knoten abgefragt, um alle Adressentabellen und Zuweisungsinformationen zu ermitteln.
Eine nächste Gruppe von Funktionsanrufen wird benutzt, um Verbindungsbeschreibungen innerhalb der Netzwerkdatenbank zu bearbeiten. Zunächst werden unter Verwendung der Dienstan forderung NS_ADD_CONN_DESC von Abschnitt 8.6.9 Verbindungsbeschreibungen hinzugefügt. Dieser Funktionsaufruf prüft zunächst, ob die maximale Anzahl von Verbindungen überschritten worden ist, und wenn nicht, fügt er die Verbindungsbeschreibung der Netzwerkdatenbank hinzu. Die Dienstanforderung NS_MODIFY_CONN_DESC (Abschnitt 8.6.10) wird benutzt, um eine Verbindungsbeschreibung in der Netzwerkdatenbank zu modifizieren. Die Netzwerkdatenbank wird geprüft, um zu bestätigen, daß die Verbindungsbeschreibung existiert. Die Netzwerkdatenbank wird dann modifiziert, und alle betroffenen Knoten werden modifiziert. Schließlich werden mit der Dienstanforderung NS_REMOVE_CONN_DESC von Abschnitt 8.6.11 Verbindungsbeschreibungen aus der Netzwerkdatenbank entfernt. Funktionell beinhaltet die Entfernung eine Überprüfung der Existenz der Verbindungsbeschreibung, die Kontrolle, ob sie gegenwärtig genutzt wird, und wenn sie nicht genutzt wird, wird sie aus der Netzwerkdatenbank entfernt.
Ein nächster Satz von Befehlen wird verwendet, um Eigenschaften von Objekten innerhalb der Netzwerkdatenbank zu "holen" (laden) und zu "setzen". Das Dienstprogramm NS_GET_PROPERTY von Abschnitt 8.6.12 wird benutzt, um eine Eigenschaft eines Objekts innerhalb der Netzwerkdatenbank abzurufen. Dem Funktionsaufruf werden eine Eigenschaftsbeschreibung und ein Objektbezeichner übergeben, und er gibt den entsprechenden Eigenschaftswert zurück. Umgekehrt werden dem Funktionsaufruf NS_SET_PROPERTY von Abschnitt 8.6.13 ein Objekt, eine Eigenschaft und ein Wert übergeben, auf den er die Objekteigenschaft einstellt.
Gelegentlich kann es nützlich sein, die Netzwerkdatenbank entweder zu importieren oder zu exportieren. Dieses Merkmal ist für Sicherungszwecke (Backup) oder für die Übertragung der Netzwerkdatenbank zu einem anderen Knoten verwendbar. Die Dienstanforderungen NS_EXPORT_DATABASE bzw. NS_IMPORT_DATABASE von Abschnitt 8.6.14 bzw. 8.6.15 können benutzt werden, um den Export und Import einer Netzwerkdatenbank durchzuführen.
Um die Kommunikation zwischen dem Netzwerkdienstanbieter (Netzwerk-SP) und dem Netzwerkdatenbank-Manager (Netzwerk-DBMS) zu erleichtern, registriert sich der Netzwerk-SP bei dem Netzwerk-DBMS. Die Dienstanforderung NS_REGISTER_NSP von Abschnitt 8.6.16 erleichtert es dem Netzwerk-SP, sich zu registrieren und dadurch Ereignismitteilungen (d. h. Ausnahmen) vom Netzwerk-DBMS zu empfangen.
Ausnahmemeldungen des Netzwerk-DBMS sind in Abschnitt 8.7 des Anhangs zusammengefaßt. Diese Meldungen sind ereignisgesteuert und werden durch den Netzwerk-DBMS generiert. Aus der Sicht eines Netzwerkdienstanbieters (Netzwerk-SP) sind alle anderen Mitteilungen Anforderungen/Antworten, wobei der Dienstanbieter anfordert und der Netzwerkdatenbank-Manager eine Antwort/einen Fehler generiert. Für diese Mitteilungen sind zwei Ausnahmen definiert. Die in 8.7.1 diskutierte Ausnahme NS_XCP_NETWORK_SP_ADDED läßt alle anderen aktuell registrierten Netzwerkdienstanbieter wissen, daß sich ein anderer Nutzer im Netz befindet. Die in 8.7.2 diskutierte Ausnahme NS_XCP_SERVICE_PIN wird generiert, wenn eine Dienst-Pin für irgendeinen an das Netz angeschlossenen Knoten vorgeschrieben ist und die Dienst-Pin-Meldung durch den Netzwerkdatenbank-Manager empfangen wird.
Interne Softwarekomponenten werden im Abschnitt 8.8 diskutiert, einschließlich der im Abschnitt 8.8.1 beschriebenen Sitzungs-/Transaktions-Ablaufsteuereinheit. Der Netzwerkdatenbank-Manager muß jede Dienstanforderung in die entsprechenden Modifikationen an der Netzwerkdatenbank untergliedern und die entsprechenden Änderungen in den betroffenen Knoten ausführen. Einige Dienste erfordern den Abruf von Informationen von verschiedenen Knoten, bevor eine weitere Verarbeitung ausgeführt werden kann. In Abhängigkeit von der Komplexität der Dienste wird eine Sitzungs-Ablaufsteuereinheit, wie z. B. die in 8 dargestellte, mit einer Anzahl von Transaktionen verwendet, die für jeden Zustand erforderlich sind. In den meisten Fällen führt eine einzelne Transaktion dazu, daß eine einzelne Meldung der ECHELON-Netzwerkverwaltung an ein Gerät gesendet wird.
Falls eine Modifikation an einem Gerät, das zur Verarbeitung bestimmter Dienste der Netzwerkverwaltung erforderlich ist, nicht abgeschlossen werden konnte, können gelegentlich Fehler entstehen. Die Korrektur solcher Fehler wird in 8.8.2 diskutiert.
Modifikationen an Adressentabellen werden in 8.8.3 dargestellt. Diese Funktion wird benutzt, um die Adressengruppe für eine bestimmte Verbindung zu ermitteln. Die Adressengruppen werden auf einen Treffer abgetastet, und wenn dieser nicht gefunden wird, dann wird eine existierende Gruppe modifiziert, oder eine neue Gruppe wird erzeugt.
In Abschnitt 9 ist die Netzwerkdatenbankstruktur enthalten. Die Netzwerkdatenbank enthält vier Tabellen, eine Knotentabelle, Verbindungstabellen (einschließlich HubData (Verteilerdaten) und TargetData (Zieldaten)) und eine Gruppentabelle. Die Knotentabelle wird in Abschnitt 9.2.1 beschrieben und enthält Informationen über die vollständige Netzwerkdatenbank und Informationen für jeden verwalteten Knoten, der durch den Netzwerkdatenbank-Manager zur Verarbeitung von angeforderten Diensten benötigt wird.
Informationen über die Netzwerkbindung sind in zwei Verbindungstabellen enthalten, die im 9.2.2 diskutiert und in 9 dargestellt werden. Netzwerkbindungen können von einem zu einem Knoten, von einem zu vielen Knoten oder von vielen zu einem Knoten bestehen. Um dies darzustellen, wird ein Verteiler ausgewählt, der das Ende der Verbindung mit nur einer Netzwerkvariablen (NV) ist. Informationen über die Verteiler-NV werden in der ConnectionHub-Tabelle oder HubData-Tabelle 91 verwaltet und durch eine Selektornummer indiziert. Informationen über eine oder viele Ziel-Netzwerkvariable (Ziel-NV(s)) werden in der ConnectionTarget-Tabelle oder TargetData-Tabelle 93 verwaltet. Die Verknüpfungen zwischen diesen Tabellen sind in 9 dargestellt.
Die Gruppentabelle wird in 9.2.3 diskutiert und in 10 dargestellt. Die Knoten innerhalb einer gegebenen Domain können in 255 Gruppen organisiert werden. Ein Knoten kann zu bis zu 15 Gruppen gehören. Eine Gruppe kann mehrere Teilnetze überspannen. Eine Gruppe kann aus einer Teilmenge von MAX_NUM_NODES-Knoten bestehen. Für quittierte LONTALK-Meldungsdienste wird eine Gruppe auf 64 Knoten beschränkt. Die Adressengruppen-Informationen werden in zwei Feldern gespei chert. Das asAddrGroup []-Feld 95 wird durch die Nummer der Adressengruppe indiziert und enthält den Index des ersten Elements der Gruppe in dem asGroupMember []-Feld 97. Die Gruppentabelle enthält außerdem ein Feld von Verbindungsbeschreibungen.
Anhang
5. ARCHITEKTUR
5.1 Übersicht
Die SEC NGS Network Management-Software hat vier Komponenten:

1. Network SP API
2. Network SP
3. Network DBM
4. Network DB

Die beigefügten Diagramme veranschaulichen, wie jede dieser Komponenten miteinander und mit anderen Teilen des Systems in Wechselwirkung tritt. Die Funktionen und Verantwortlichkeiten jeder Komponente werden in den folgenden Abschnitten weiter beschrieben.
Network SP und Network DBM müssen mit anderen Anwendungen koexistieren, die gemeinsame Kommunikationsstapel nutzen. Diese Anwendungen und Kommunikationsstapel werden über eine in SDS-S-011 beschriebene Controller Message Router-Schicht (Meldungsverteilerschicht der Steuereinheit) miteinander verbunden.
6. NETZWERKDIENSTANBIETER-ANWENDUNGSPROGRAMMIERSCHNITTSTELLE (NETZWERK-SP-API)
6.1 Übersicht
Dies ist ein Satz von Funktionen, die Anwendungen den Zugriff auf Dienste des Netzwerkdienstanbieters und indirekt auf die Netzwerkdatenbank ermöglichen.
6.2 Anwendungsprogrammierschnittstelle (API)
6.2.1 NSPInit()
Funktionsprototyp
Parameterbeschreibung

phNSP – Zeiger auf zurückgegebene Netzwerkdienstanbieter-Zugriffsnummer
Network – logische Netzwerknummer des Netzwerks, das dieser Dienstanbieter (SP) handhabt
bLocalNetDBM – WAHR, wenn NetDBM im gleichen Prozeß läuft.

Fehlercodes

Betriebssystem-Fehler

Algorithmus

1. Netzwerkdienstanbieter-Daten initialisieren
2. Ereignisflagge (Ereignis-Semaphor) NS_REGISTERED erzeugen, die durch den Netzwerkdienstanbieter zu versenden ist, wenn wir uns beim Netzwerkdatenbank-Manager (Netzwerk-DBM) registriert haben.
3. Netzwerk-SP-Prozeßstrang starten.

6.2.2 NSPClose ()
Funktionsprototyp

ULONG NSPClose (NSP_HANDLE hNSP)

Parameterbeschreibung

hNSP – Netzwerkdienstanbieter-Zugriffsnummer

Fehlercodes

NM-ERROR-INVALID-HANDLE
Betriebssystemfehler

Algorithmus

1. Beendigung ausstehender Transaktionen abwarten.
2. Netzwerkdienstanbieter bei Netzwerkdatenbank-Manager deregistrieren.
3. Anschluß an Kommunikationsschicht schließen, Warteschlange und Semaphor schließen.

6.2.3 NSPRegisterClient()
Funktionsprototyp
Parameterbeschreibung

hNSP – Durch Aufruf an NSPInit zurückgegebene Netzwerkdienstanbieter-Zugriffsnummer
phClientHandle – gibt Zugriffsnummer zurück, zum Gebrauch bei Anforderung von Diensten
pfuncClientCallback – durch Anwendung implementierte Funktion, wird bei Netzwerkdienstanbieter-Dienstantwort oder Ereignismeldung aufgerufen.
hCallBack – in der Rückruffunktion übergebene Zugriffsnummer.

Fehlercodes

NM_ERROR_EXCEED_MAX_CLIENTS
NM_ERROR_WAIT_SEM_TIMEOUT
Betriebssystemfehler

Algorithmus

1. Ereignisflagge NS_REGISTERED abwarten.
2. Client zur Registrierliste der Netzwerkdienstanbieter-Clients hinzufügen.
3. Client-Zugriffsnummer zurückgeben.

6.2.4 NSPDeregisterClient()
Beschreibung
Die Funktion NSPDeregisterClient() veranlaßt den Netzwerkdienstanbieter, die während NSPRegisterClient() geöffnete Zugriffsnummer zu schließen, und führt eine etwa notwendige Säuberung durch. Funktionsprototyp
Parameterbeschreibung

hNSP – durch Aufruf von NSPInit zurückgegebene Netzwerkdienstanbieter-Zugriffsnummer.
hClientHandle – Client-Zugriffsnummer zum Deregistrieren.

Fehlercodes

NM_ERROR_INVALID_HANDLE

Algorithmus

1. Client aus der Liste der registrierten Netzwerkdienstanbieter-Clients entfernen.

6.2.5 NSPInvokeService()
Beschreibung
Ein registrierter Client kann einen Dienst aufrufen, indem er NSPInvokeService() aufruft. Der Netzwerkdienstanbieter überprüft die Anforderungsparameter in Abhängigkeit vom Anforderungstyp, leitet die Anforderung zum Netzwerkdatenbank-Manager (Netzwerk-DBM) weiter oder verarbeitet sie direkt. Der Netzwerkdienstanbieter wartet auf eine Antwort, die formatiert ist, und sendet sie zurück, indem er die Rückruffunktion des Clients aufruft. Funktionsprototyp
Parameterbeschreibung

hNSP – Zugriffsnummer zum Netzwerkdienstanbieter
hClientHandle – Zugriffsnummer, die zur Client-Anwendung zurückgegeben wird, wenn diese sich registriert hat.
ulClientTag – vom Client geliefertes Identifizierungskennzeichen, wird mit Dienstantwort zurückgegeben
btServiceCode – Code, der den angeforderten Dienst repräsentiert
pvRequestData – Zeiger zur Anforderung einer Datenstruktur. Jeder Diensttyp hat seine eigenen Anforderungsparameter
usRequestLen – Länge der Anforderungsdaten

Fehlercodes

NM_ERROR_INVALID_HANDLE
Betriebssystemfehler

Algorithmus

1. Dienstanforderung zum Netzwerkdatenbank-Manager weiterleiten.

6.2.6 NSPClientCallback-Funktionen
Parameterbeschreibung

hCallBack – Zugriffsnummer, die übergeben wird, wenn der Client beim Dienstanbieter registriert ist. Diese Zugriffsnummer kann benutzt werden, um zwischen Fällen einer Anwendung zu unterscheiden, die mehrere Netzwerke bedient.
psServMsg – Zeiger auf Dienstmeldung, die Antwortdaten enthält. Siehe Abschnitt 0 zur Beschreibung dieser Struktur.
usLen – Länge der Antwortdaten.

7. NETZWERKDIENSTANBIETER
7.1 Übersicht
7.2 Nachrichtenfluß
7.3 Initialisierung
Algorithmus

1. Nachrichtenwarteschlange erzeugen
2. Nachrichtenverbindungsschicht öffnen.
3. Netzwerkdatenbank-Manager lokalisieren (lokal oder entfernt). Wenn der Netzwerkdatenbank-Manager nicht auffindbar ist, mißlingt die Initialisierung.

7.4 Funktionsweise
Algorithmus

Ankunft einer Meldung abwarten.
SWITCH auf Typ der Meldung einstellen.
CASE Dienstanforderung Anforderung an Netzwerkdatenbank-Manager weiterleiten Zeigeber starten und Antwort abwarten
CASE Antwort Zeitgeber stoppen Antwort zur anfordernden Anwendung zurücksenden
CASE Zeitüberschreitung Antwort 'Zeitüberschreitung' zur anfordernden Anwendung zurücksenden
CASE Ausnahme Ausnahme an alle Client-Anwendungen weiterleiten
CASE Beenden Verlassen

7.5 Dienste des Netzwerkdienstanbieters
7.5.1 NS_EXTRACT_XIF (wahlfrei)
Algorithmus

1. Kommunikation mit Knoten überprüfen.
2. Überprüfen, ob Knoten LonMark-konform ist.
3. SI/SD-Daten abfragen.

7.5.2 NS_DOWNLOAD_APPLICATION (wahlfrei)
Algorithmus

1. Sperre vom Netzwerkdatenbank-Manager anfordern
2. Knoten vom Netz nehmen(offline)?
3. Anwendungsabbild segmentieren/übertragen
4. Verbindungen wiederherstellen?
5. Knoten wieder mit dem Netz verbinden (on-line schalten)?

7.5.3 NS_READ_CP (wahlfrei)
Algorithmus

1. Konfigurationseigenschaftstyp bestimmen (SNVT, SCPT usw.)
2.

7.5.4 NS_WRITE_CP (wahlfrei)
8. NETZWERKDATENBANK-MANAGER
8.3 Initialisierung
Der Prozeßstrang und die Datenbank des Netzwerkdatenbank-Managers werden durch Aufruf von NetDBMInitialize() initialisiert. Diese Funktion nimmt Parameter an, welche die maximale Anzahl von Knoten und Verbindungen festlegen, die in der Netzwerkdatenbank unterstützt werden können. Funktionsprototyp
Parameterbeschreibung

btMaxNumNodes – maximale Anzahl von permanenten Knoten, die durch die Datenbank unterstützt werden können.
usMaxNumHubs – maximale Anzahl von Verteiler, die durch die Datenbank unterstützt werden.
usMaxNumTargets – maximale Anzahl von Verbindungsziel-Verteilern, die durch die Datenbank unterstützt werden.
Network – logische Netzwerknummer des vom Netzwerkdatenbank-Manager verwalteten Netzwerks.

Inbetriebnahme des Netzwerkdatenbank-Managers (NetworkDBM)
Wenn der Netzwerkdatenbank-Manager (Netzwerk-DBM) zum ersten Mal in einer Einrichtung läuft, muß er ermitteln, ob er die einzige Instanz ist, die gegenwärtig an diesem Netzwerk betrieben wird. Wenn er der einzige Netzwerkdatenbank-Manager ist, dann führt er eine AddNode-Anweisung an sich selbst durch. Das folgende Zustandsdiagramm zeigt die Aktionen an, die jedesmal beim Rücksetzen der Einrichtung durch den Netzwerkdatenbank-Manager ausgeführt werden. Die Meldung Service-Pin (Dienst-Pin) wird als einziges zuverlässiges Mittel benutzt, um eine andere Instanz des Netzwerkdatenbank-Managers zu benachrichtigen, daß eine neue Einrichtung anwesend ist. Ein anderer Netzwerkdatenbank-Manager sendet eine Meldung NQAddSP als Antwort auf die Meldung ServicePin. Wenn diese Meldung vor Ablauf des Zeitgebers empfangen wird, dann deaktiviert der Netzwerkdatenbank-Manager sich selbst.
Algorithmus

1. Nachrichtenwarteschlange erzeugen.
2. Nachrichtenverbindungsschicht öffnen.
3. Netzwerk informieren: "Ich bin der Netzwerkdatenbank-Manager" (Siehe Zustandsdiagramm in Error! Reference source not found. (Fehler! Bezugsquelle nicht gefunden.))
4. Auf etwaige gegensätzliche Antworten warten. Wenn I_AM_NETDBM, dann Dienstanforderungen verarbeiten.

8.4 Funktionsweise
Algorithmus
8.5 Dienstmeldung
Die gesamte Kommunikation zwischen dem Netzwerkdienstanbieter und dem Netzwerkdatenbank-Manager nutzt die folgende Dienstmeldung. Dienstmeldungen bestehen aus einem festen Kopf und einer dienstspezifischen Meldung.
Parameterbeschreibung

btTransactionType – Typ der Meldung (Anforderung; Antwort; Fehler; Ausnahme)
btServiceType – Diensttyp (AddNode, AddConnection, ...). Dadurch wird der Typ der Meldungsstruktur in 'Data' definiert.
usTag – Bezeichner, der zur Anpassung von Anforderung und Antwort benutzt wird.
Data – Platzhalter für Daten, die für denn Transaktionstyp und den Diensttyp spezifisch sind. Die spezifischen Datenstrukturen werden im Rest dieses Abschnitts beschrieben.

8.6 Anforderungs-/Antwort-Dienste des Netzwerkdatenbank-Managers
Für Anforderungs-/Antwort-Dienste wird, wenn ein Dienst erfolgreich abgeschlossen wird, die angezeigte Antwortmeldung an das Client-Gerät zurückgesendet. Wenn für einen gegebenen Dienst keine Antwortstruktur definiert ist, werden Daten der Länge null als Antwortdaten für einen erfolgreichen Abschluß des Dienstes zurückgesendet. Beim Auftreten eines Fehlers wird eine Fehlerantwort gesendet. Wenn für einen bestimmten Dienst keine Fehlerantwortstruktur definiert ist, dann ist die Antwort eine allgemeine NRSP_ERROR-Struktur, die den Fehlercode enthält.
Parameterbeschreibung

ulErrorCode – Fehlercode.

8.6.1 NS_ADD_NODE
Beschreibung
Dieser Dienst fügt einen einzelnen Knoten zur Knotentabelle hinzu, weist ein Teilnetz und eine Knotenadresse zu und aktiviert sie. Der Gerätebezeichner wird als Knotenzugriffsnummer weitergeleitet und in zukünftigen Transaktionen als Verweis auf das Gerät benutzt. Bei erfolgreichem Abschluß des Dienstes werden das Teilnetz/die Knotenadresse des Knotens zurückgegeben.
Dienstparameter
Der AddNode-Dienst wird mit der Struktur NS_ADD_NODE mit den folgenden Parameter aufgerufen:

NeuronID – eindeutige 48-Bit-Neuron-Kennzeichnung des Neuron-Chips in dem hinzuzufügenden Knoten.

Antwortdaten
Wenn der AddNode-Dienst erfolgreich abgeschlossen ist, wird unter Verwendung der Struktur NRSP_ADD_NODE eine Antwort zurückgesendet.

SubNet – die Geräte, die dem Teilnetz innerhalb seiner Domain zugewiesen sind. Gültige Werte sind 1–255. Teilnetz und Knoten sind die Adresse des Geräts für direkte Kommunikation.
Knoten – die Geräte, die dem Knoten innerhalb seiner Domain und seines Teilnetzes zugewiesen sind. Gültige Werte sind 1–127.

Fehlercodes

NM_ERROR_DUPLICATE_NODE (doppelter Knoten)
NM_ERROR_DEVICE NOT_FOUND (Gerät nicht gefunden)
NM_ERROR_COMMISSIONING_FAILED (Aktivierung fehlgeschlagen)

Algorithmus

1. Prüfen, ob der Knoten bereits in der Datenbank existiert.
2. Nachprüfen, daß das Gerät existiert und über den Feldbus zugänglich ist.
3. ReadOnly(Nur-Lese-)Programm ID
4. Knoteninformationen lesen
a) ReadOnly NV Count (Anzahl der Netzvariablen) und pSNVT-Informationen
b) SNVT-Struktur lesen
i) Wenn Gastknoten, dann QuerySNVT Offset (= Startadresse) 0 count (= Anzahl) 6
ii) Wenn neuronenbasiert, dann Read Absolute pSNVTInfo count 6
c) ReadOnly Offset 0x15-0xID-Adressenzähler, zwei Domains ...
d) SNVT-Informationen lesen
i) Wenn Gastknoten, dann QuerySNVT verwenden
ii) Wenn neuronenbasiert, dann Read Absolute von pSNVTInfo
e) NV Config (Netzvariablen-Konfiguration) abfragen
f) NV Fetch (abrufen)
5. Knoten in Offline/nicht konfigurierten Zustand setzen
a) Modus "Application Offline" (Anwendung Offline) setzen
b) Zustand "UnConfigured" (nicht konfiguriert) setzen
c) Zustand löschen
d) Rücksetzen
6. Domain konfigurieren
a) Domain 0 aktualisieren
b) Domain 1 belassen
7. Konfigurationsdaten schreiben
a) ChannelID (Kanalkennung) setzen
b) Slot NodePriority löschen
c) Location String (Adressenfolge) löschen
8. Adressentabelle löschen
9. NV-(Netzvariablen-)Zuweisung aufheben
10. NM-Authentifikation setzen
11. Knoten in Online-/konfigurierten Zustand setzen
a) Zustand "Configured Online" (konfiguriert online) setzen
b) Modus "Application Offline" (Anwendung offline) setzen
c) Modus "Application Online" (Anwendung online) setzen

8.6.2 NS_REMOVE_NODE
Beschreibung
Dieser Dienst löscht einen Knoten aus der Knotentabelle. Das Gerät wird in einen nicht konfigurierten Zustand gebracht. Es sind keine Antwortdaten definiert. Eine Antwort zeigt den Erfolg des Dienstes an.
Alle Verbindungen zu diesem Gerät sind vor dem Entfernen des Knotens zu löschen.
Dienstparameter
Dieser Dienst 'Remove Node' wird mit der Struktur NS_REMOVE_NODE mit den folgenden Parametern aufgerufen:

hNode – die Zugriffsnummer für den Knoten, der aus der Datenbank zu entfernen ist.

Ergebnisdaten

Keine Ergebnisdaten.

Fehlercodes

NM_ERROR_INVALID_NODE (ungültiger Knoten)
NM_ERROR_NODE_STILL_BOUND (Knoten noch gebunden)
NM_ERROR_MODIFYING_ADDRESS_GROUP (Änderung der Adressengruppe)
NM_ERROR_MODIFYING_CONNECTION (Änderung der Verbindung)

Algorithmus

1. Überprüfen, ob Knoten gegenwärtig Element der Datenbank ist
2. Überprüfen, ob dieser Knoten nicht Teil irgendeiner Verbindung ist
3. Knoten aus Adressengruppen entfernen
4. Knoten in Offline-/nichtkonfigurierten Zustand setzen
a) Modus "Application Offline" (Anwendung offline) setzen
b) Zustand "UnConfigured" (nicht konfiguriert) setzen
c) Zustand löschen
d) Rücksetzen
5. Domain-Tabelle löschen
6. Knoten aus Datenbank entfernen

8.6.3 NS_REPLACE_NODE
Beschreibung
Dieser Dienst tauscht einen vorhandenen Knoten gegen ein neues Gerät aus. Die Knotentabelle wird modifiziert, und der Knoten wird aktiviert.
Dienstparameter
Der Dienst Replace Node (Knotenaustausch) wird mit der NS_REPLACE_NODE-Struktur mit den folgenden Parametern aufgerufen:

NeuronID – eindeutige 48-Bit-Neuronenkennzeichnung des Neuronenchips in dem hinzuzufügenden Knoten.
hNode – die eindeutige Knotenzugriffsnummer, die zur Kennzeichnung des Geräts durch den Netzwerkdatenbank- Manager (NetzwerkDBM) benutzt wird. Diese Zugriffsnummer wird zur Anpassung der ursprünglichen Gerätedaten verwendet.

Ergebnisdaten

Keine Ergebnisdaten.

Fehlercodes

NM_ERROR_DEVICE_NOT_FOUND (Gerät nicht gefunden)
NM_ERROR_COMISSIONING_FAILED (Aktivierung fehlgeschlagen)

Algorithmus

1. Gleich Verarbeitung wie bei AddNode, mit der folgenden Ausnahme.
2. NVConfig für alle zugewiesenen Netzvariablen aktualisieren.

8.6.4 NS_ADD_CONNECTION
Beschreibung
Dieser Dienst fügt eine Verbindung hinzu oder modifiziert sie schrittweise. Die Verbindung weist eine Ausgangs-Netzvariable vielen Eingangs-Netzvariablen oder viele Ausgänge einem Eingang zu. Die eine (Netzvariable) wird als Verteiler (Hub) bezeichnet, und die vielen (Netzvariablen) werden als Ziele (Targets) bezeichnet. Ein Verbindungspunkt wird durch ein NV_REFERENCE bezeichnet, das den NV-Index der in die Verbindung einzubeziehenden Netzvariablen (NV) und die Knotenzugriffsnummer des Knotens angibt, der die NV enthält. typedef XBYTE DESCRIPTION_ID;
Dienstparameter
Der Dienst Add Connection wird mit der Struktur NS_ADD_CONNECTION mit den folgenden Parametern aufgerufen:

ConnDescId – gibt die Verbindungsbeschreibung an, die beim Konfigurieren der Bindung zu verwenden ist.
btHubNVDirection – zeigt an, ob die Verteiler-NV eine Eingangs- oder Ausgangs-NV ist.

INPUT (Eingang)	0
OUTPUT (Ausgang)	1

NVHub – der Knoten und NV-Index des Verbindungsverteilers
btTargetCount – Anzahl der Ziele (Targets) in der Verbindung
NVTarget – eine Matrix von usTargetCount-Knoten und NV-Indizes für die Verbindungsziele

Ergebnisdaten

Keine.

Fehlercodes

NM_ERROR_NV_MISMATCH – SNVT-Typen passen nicht, oder Nichtübereinstimmung der NV-Größe
NM_ERROR_DIRECTION_MISMATCH – Nichtübereinstimmung von Eingangs- und Ausgangs-NV
NM_ERROR_POLL_MISMATCH (Abfrage-Nichtübereinstimmung)
NM_ERROR_EXCEED_MAX_CONNECTIONS (max. Verbindungszahl überschritten)

Algorithmus

1. Überprüfen, ob Knoten in der Datenbank existieren.
2. Knotenzustand prüfen.
3. Übereinstimmung der SNVT-Typen überprüfen.
4. Überprüfen, ob Richtungen von Verteiler und Ziel(en) einander ergänzen.
5. SelectAddressGroup() aufrufen.
6. Wenn keine Fehler, dann Zuweisung erzeugen.
a) Adressentabellen nach Bedarf aktualisieren.
b) NV Config-Tabellen aktualisieren.

8.6.5 NS_REMOVE_CONNECTION
Beschreibung
Dieser Dienst entfernt eine oder mehrere Ziel-NV aus einer Verbindung. Die Verteiler-NV dient als Bezugsgröße der Verbindung. Wenn alle Ziel-NV entfernt werden, wird der Verteiler auch entfernt.
Dienstparameter
Der Dienst Remove Connection (Verbindung entfernen) wird mit der Struktur NS_REMOVE_CONNECTION mit den folgenden Parametern aufgerufen:

NVHub – Knoten und NV-Index des Verteilers der Verbindung. Dadurch wird die zu modifizierende Verbindung eindeutig identifiziert.
btTargetCount – gibt die Anzahl der zu löschenden Zielverbindungen an. Wenn der Zähler 0 ist, dann werden alle Zielverbindungen und der Verteiler gelöscht.
NVTarget – dies ist eine Matrix von usTargetCount-Strukturen, die den Knoten und NV-Index der neuen Verbindungen angeben.
NVTarget[].Node – Knoten, der aus der Verbindung zu löschende NV enthält.
NVTarget[].NVIndex – Index der aus der Verbindung zu löschenden NV. Ist dieser 0, dann werden alle NV (Netzvariablen) in dem spezifizierten Knoten gelöscht.

Ergebnisdaten

Keine Daten.

Fehlercodes

NM_ERROR_INVALID_HUB (ungültiger Verteiler)
NM_ERROR_INVALID_TARGET (ungültiges Ziel)

Algorithmus

1. Überprüfen, ob Verbindung existiert und bezeichnete Ziele Elemente sind.
2. Für jedes Ziel
a) NVconfig auf nicht zugewiesenen Zustand setzen
b) Ziel aus Datenbank entfernen
3. Wenn alle Ziele gelöscht sind,
a) Verteiler-NVconfig auf nicht zugewiesenen Zustand setzen
b) Verbindung aus der Datenbank entfernen

8.6.6 NS_ADD_ADDRESS_GROUP
Beschreibung
Dieser Dienst wird benutzt, um eine Adressengruppe hinzuzufügen oder zu modifizieren. Dies kann notwendig sein, wenn es eine Anwendung in irgendeinem Knoten gibt, die eine explizite Meldung mit Gruppenadressierung senden muß.
Dienstparameter
Der Dienst Add Address Group (Adressengruppe hinzufügen) wird mit der Struktur NS_ADD_ADDRESS_GROUP mit den folgenden Parametern aufgerufen:

ConnDescId – Index für diese Adressengruppe in der Adressengruppentabelle
btDeviceCount – Anzahl der Knoten in dieser Gruppe
ahNode – Matrix von btDeviceCount-Knotenzugriffsnummern für die Geräte, welche die Gruppe bilden. Wenn die Gruppe existiert, dann werden etwaige neue Elemente zur Gruppe hinzugefügt.

Ergebnisdaten

GroupId – vom Netzwerkdatenbank-Manager (Netzwerk-DBM) zugewiesene Gruppenkennnummer

Algorithmus

1. Umfang ermitteln –
a) Wenn keine aktuelle Gruppe, dann Adressengruppe zur Tabelle hinzufügen
b) Wenn Gruppe existiert und keine Änderung erfolgt,
i) Gruppenkennung zurücksenden
2. Tabelle modifizieren
3. Knotentabelle aktualisieren
4. Verbindungsliste aktualisieren

Fehlercodes

NM_ERROR_INVALID_NODE (ungültiger Knoten)

8.6.7 NS_REMOVE_ADDRESS_GROUP
Beschreibung
Dieser Dienst entfernt eine Adressengruppe aus der Adressengruppentabelle der Netzwerkdatenbank (Netzwerk-DB).
Dienstparameter
Der Dienst Remove Address Group wird mit der Struktur NS_REMOVE_ADDRESS_GROUP mit den folgenden Parametern aufgerufen:

GroupId – Matrix von ganzen Zahlen, die den Index für die zu löschenden Adressengruppen in der Adressengruppentabelle enthalten.

Ergebnisdaten

Keine.

Fehlercodes

NM_ERROR_INVALID_ADDRESS_GROUP (ungültige Adressengruppe)
NM_ERROR_ADDRESS_GROUP_INUSE (Adressengruppe in Gebrauch)

Algorithmus

1. Überprüfen, ob keine Zuweisungen bestehen, welche diese Gruppe verwenden
2. Datenbanktabellen modifizieren
3. Adressentabellen in betroffenen Knoten modifizieren

8.6.8 NS_RECOVER_DATABASE
Beschreibung
Dieser Dienst wird benutzt, um den Netzwerkdatenbank-Manager anzuweisen, das Netzwerk abzufragen, um eine Netzwerkdatenbank aufzubauen. Der Netzwerkdatenbank-Manager ermittelt die Netzwerktopologie und erkennt die NV-Verbindungen. Dieser Dienst wird aufgerufen, wenn die Datenbank fehlt, verdächtig ist oder ein neues Netzwerk installiert worden ist
Dienstparameter
Dieser Dienst wird mit der Struktur NS_RECOVER_DATABASE mit den folgenden Parametern aufgerufen:

Domain – Die Domain der Geräte, für welche die Datenbank wiederherzustellen ist.

Ergebnisdaten
Das Ergebnis dieses Dienstes wird in einer Struktur NRSP_RECOVER_DATABASE mit den folgenden Parametern zurückgegeben:

ucNumDevices – Anzahl der Geräte, die in der Knotentabelle wiederherzustellen sind.
ucNumAddressGroups – Anzahl der Gruppen, die in den Gruppentabellen wiederherzustellen sind
usNumBindings – Anzahl der Zuweisungen, die in den Verbindungstabellen wiederherzustellen sind

Fehlercodes

NM_ERROR_NO_DEVICES_DETECTED (keine Geräte erkannt)

Algorithmus

1. Verbundene Knoten erkennen
a) NM-Meldung "Antwort auf Abfrage" rundsenden
b) Antworten zur Belegung der Knotentabelle sammeln
2. Jeden Knoten abfragen
a) Domain-Tabelle abfragen
b) Adressentabelle abfragen
c) NV config-Tabelle abfragen

8.6.9 NS_ADD_CONN_DESC
Beschreibung
Dieser Dienst fügt eine Verbindungsbeschreibung zur Datenbank hinzu.
Dienstparameter
Der Dienst Add Connection Description wird mit der Struktur NS_ADD_CONN_DESC mit den folgenden Parametern aufgerufen:

sConnectDesc. btServiceType –

ACKD	0
UNACKD_RPT	1
UNACKD	2

sConnectDesc. btPriority – zeigt Verwendung von Vorrangverbindungen an.
sConnectDesc. btAuthenticate – zeigt Anwendung der Authentifikation an
sConnectDesc. btRetryCount – Anzahl der erneuten Versuche einer bestätigten Meldung. Gültige Werte sind 0–15. Wird für Diensttyp ACKD (bestätigt) verwendet.
sConnectDesc. btRepeatTimer – Anzahl der Wiederholungen einer wiederholten Meldung. Gültige Werte sind 0–15. Wird für Diensttyp UNACKD_RPT (unbestätigt-Wiederholung) verwendet.
sConnectDesc. btReceiveTimer – codierter Wert des Wiederholungszeitgebers. Gültige Werte sind 0–15. Wird für Diensttyp UNACKD_RPT (unbestätigt-Wiederholung) verwendet.
sConnectDesc. btTransmitTimer – codierter Wert des Empfangszeitgebers. Gültige Werte sind 0–15. Wird für Diensttyp REQUEST/RESPONSE (Anforderung/Antwort) verwendet.

Antwortdaten

ConnDescId – Index der Verbindungsbeschreibungen, wird in anderem Dienst zur Kennzeichnung von Verbindungsbeschreibungen verwendet.

Fehlercodes
Algorithmus

1. Prüfen, ob MAX_NUMBER_CONN_DESC (max. Anzahl der Verbindungsbeschreibungen) erreicht ist.
2. Zur Datenbank hinzufügen.

8.6.10 NS_MODIFY_CONN_DESC
Beschreibung
Dieser Dienst modifiziert eine Verbindungsbeschreibung in der Datenbank.
Dienstparameter
Der Dienst Modify Connection Description (Verbindungsbeschreibung modifizieren) wird mit der Struktur NS_MODIFY_CONN_DESC aufgerufen. Die Parameter sind die gleichen wie im folgenden:

ConnDescId – Zugriffsnummer für die zu modifizierende Verbindungsbeschreibung
sConnectDesc – Parameter der neuen Verbindungsbeschreibung

Ergebnisdaten

Keine

Fehlercodes
Algorithmus

1. Überprüfen, ob Verbindungsbeschreibung existiert.
2. Datenbanktabellen modifizieren.
3. Tabellen in betroffenen Knoten modifizieren.

8.6.11 NS_REMOVE_CONN_DESC
Beschreibung
Dieser Dienst entfernt eine Verbindungsbeschreibung in der Datenbank.
Dienstparameter
Der Dienst Remove Connection Description (Verbindungsbeschreibung entfernen) wird mit der Struktur NS_REMOVE_CONN_DESC aufgerufen. Die Parameter sind die gleichen wie im folgenden:

ConnDescId – Zugriffsnummer für die zu löschende Verbindungsbeschreibung.

Ergebnisdaten

Keine.

Fehlercodes

ERROR_CONN_DESC_INUSE (Verbindungsbeschreibung in Gebrauch)

Algorithmus

1. Überprüfen, ob Verbindungsbeschreibung existiert.
2. Überprüfen, ob die Verbindungsbeschreibung für keine Verbindung in Gebrauch ist.
3. Aus Datenbank löschen.

8.6.12 NS_GET_PROPERTY
Beschreibung
Dieser Dienst wird zum Abruf einer Eigenschaft aus der Netzwerkdatenbank benutzt.
Dienstparameter
Dieser Dienst wird mit der Struktur NS_GET_PROPERTY mit den folgenden Parametern aufgerufen:

eNetObjectType – Typ des Netzwerkobjekts:
NETWORK_OBJECT_NODE
NETWORK_OBJECT_ADDRESS_GROUP
NETWORK_OBJECT_CONNECTION
NETWORK_OBJECT_NETWORKDBM
NetObjectInstance – numerische Bezeichnung für ein be stimmtes Exemplar des spezifizierten NetObjectType.
eNetDBProperty – Typeigenschaft des zu lesenden Ob jekts:
//Knoteneigenschaften
NETWORK_PROPERTY_NEURON_ID
NETWORK_PROPERTY_NODESTATE
NETWORK_PROPERTY_ADDRESSTABLE
//Verbindungseigenschaften
NETWORK_PROPERTY_NODE
NETWORK_PROPERTY_CONNSTATE
NETWORK_PROPERTY_DIRECTION
NETWORK_PROPERTY_SERVICETYPE
NETWORK_PROPERTY_PRIORITY
NETWORK_PROPERTY_AUTHENTICATE
NETWORK_PROPERTY_GROUP
NETWORK_PROPERTY_CONNECTIONLIST
//Eigenschaften der Adressengruppe
NETWORK_PROPERTY_RETRYCOUNT
NETWORK_PROPERTY_REPEATTIMER
NETWORK_PROPERTY_RECEIVETIMER
NETWORK_PROPERTY_TRANSMITTIMER
NETWORK_PROPERTY_GROUP_MEMBERS
//Eigenschaften des Netzwerkdatenbank-Managers
NETWORK_PROPERTY_REVISION
NETWORK_PROPERTY_LAST_UPDATE
NETWORK_PROPERTY_NUM_ADDGROUPS
NETWORK_PROPERTY_NUM_NODES
NETWORK_PROPERTY_NUM_CONNECTS
NETWORK_PROPERTY_CLIENT_LIST
NETWORK_PROPERTY_NETDBM_STATE

Ergebnisdaten
Das Ergebnis dieses Dienstes wird in einer Struktur NRSP_GET_PROPERTY mit den folgenden Parametern zurückgegeben:

eNetObjectType- Typ des Netzwerkobjekts.
NetObjectInstance- die numerische Bezeichnung für ein bestimmtes Exemplar des spezifizierten NetObjectType.
eNetDBProperty – Eigenschaft des gerade gelesenen Objekts.
usDataLength – Länge der zurückgegebenen Daten.
Data – Daten

Fehlercodes

NM_ERROR_INVALID_OBJECT_TYPE (ungültiger Objekttyp)
NM_ERROR_INVALID_OBJECT_INSTANCE (ungültiges Objektexemplar)
NM_ERROR_INVALID_PROPERTY (ungültige Eigenschaft)

Algorithmus

1. Parameter überprüfen
2. Wert zurückgeben

8.6.13 NS_SET_PROPERTY
Beschreibung
Dieser Dienst wird zum Setzen einer Eigenschaft innerhalb der Netzwerkdatenbank benutzt.
Dienstparameter
Dieser Dienst wird mit der Struktur NS_SET_PROPERTY mit den folgenden Parametern aufgerufen:

eNetObjectType – Typ des Netzwerkobjekts (zur Liste von Objekttypen siehe NSGetProperty)
NetObjectInstance – numerische Bezeichnung für ein bestimmtes Exemplar des spezifizierten NetObjectType
eNetDBProperty – Eigenschaft des gerade gelesenen Objekts (zur Liste von Eigenschaftstypen siehe NSGetProperty)
usDataLength – Länge der Daten
Data – Daten

Ergebnisdaten

Keine Daten.

Fehlercodes

NM_ERROR_INVALID_OBJECT TYPE (ungültiger Objekttyp)
NM_ERROR_INVALID_OBJECT_INSTANCE (ungültiges Objektexemplar)
NM_ERROR_INVALID_PROPERTY (ungültige Eigenschaft)

Algorithmus

1. Parameter überprüfen
2. Wert zurückgeben

8.6.14 NS_EXPORT_DATABASE (wahlfrei)
Beschreibung
Dieser Dienst wird benutzt, um die Netzwerkdatenbank aus einem eingebetteten Knoten zu Sicherungszwecken zu extrahieren oder sie in einen anderen Knoten zu verschieben (zum Beispiel Verschieben von einem LC-NM zu einem NP)
Dienstparameter
Dieser Dienst wird mit der Struktur NS_EXPORT_DATABASE mit den folgenden Parametern aufgerufen:

DeviceId – Gerätekennzeichen des Geräts, das die Datenbank liest.
eExportType – Art des Exports. Wenn eExportType = MOVE ist, dann verändert NetworkDBM seinen Zustand, um anzuzeigen, daß dieses Gerät nicht mehr der Netzwerk-Manager ist. Wenn eExportType = BACKUP ist, dann ...

Ergebnisdaten
Das Ergebnis dieses Dienstes wird in einer Struktur NRSP_EXPORT_DATABASE mit den folgenden Parametern zurückgegeben:

Revision – Ausgabe des Netzwerkdatenbank-Managers (NetworkDBM)
usSizeNodeTable – Byte-Zahl in der Knotentabelle
usSizeConnectionTable –
usSizeAddressTable –

Fehlercodes

NM_ERROR_INVALID_EXPORT_TYPE (ungültiger Export-Typ)

Algorithmus

1. Netzwerkdatenbank (NetworkDB) sperren
2. Wenn eExport= MOVE
a) Setze IamNetworkManager = FALSE;

8.6.15 NS_IMPORT_DATABASE (wahlfrei)
Beschreibung
Dieser Dienst wird benutzt, um eine Netzwerkdatenbank mit Daten zu initialisieren, die von einem anderen Knoten gesichert oder verschoben bzw. übertragen wurden.
Dienstparameter
Dieser Dienst wird mit der Struktur NS_IMPORT_DATABASE mit den folgenden Parametern aufgerufen:

DeviceId – Gerätekennzeichen des Geräts, das die Datenbank herunterlädt.
eImportType – Art des Exports
usSizeNodeTable – Platzgröße, die für die Knotentabelle zuzuweisen ist
usSizeConnectionTable – Platzgröße, die für die Verbindungstabelle zuzuweisen ist
usSizeAdressTable – Platzgröße, die für die Adressentabelle zuzuweisen ist

Revision – Ausgabe des Netzwerkdatenbank-Managers (NetworkDBM)

Fehlercodes
Algorithmus

1. Datenbank in gesperrten Zustand bringen
2. Wenn neue Datenbank
a) Platz zuordnen
3. Wenn Datenbank existiert
a) Datenbank löschen
b) Nötigenfalls Größe ändern
4. Auf Herunterladen warten

8.6.16 NS_REGISTER_NSP
Beschreibung
Dieser Dienst registriert einen Netzwerkdienstanbieter beim Netzwerkdatenbank-Manager. Dieser Dienst ermöglicht, daß ein Netzwerkdienstanbieter Ereignisse vom Netzwerkdatenbank-Manager empfängt. Ereignisse werden nach Empfang von Dienst-Pin-Mitteilungen und bei vorhandenen Knoten generiert.
Dienstparameter
Dieser RegisterClient-Dienst wird mit der Struktur NS_REGISTER_CLIENT mit den folgenden Parametern aufgerufen:

hNodeToRegister – Knotenzugriffsnummer des registrierenden Geräts
RegisterType – Typ von Ereignissen und Ausnahmen, die der Client empfangen möchte
REGISTER_ALL 0xFFFF
Dauer – die Dauer der Registrierung. Wenn Dauer = PERMANENT_REGISTER ist, werden die Registrierungen durch Rücksetzen des Geräts aufrechterhalten. Wenn Dauer = TEMPORARY_REGISTER ist, wird die Registrierung nicht durch Rücksetzen des Geräts aufrechterhalten.

Ergebnisdaten

Keine Daten.

Fehlercodes

NM_ERROR_EXCEED_MAX_CLIENTS (Maximale Client-Zahl überschritten)

Algorithmus

1. Gerät registrieren.
2. Wenn Dauer = PERMANENT_REGISTER
a) Registrierungsinformation in Permanentspeicher einschreiben

8.7 Netzwerkdatenbank-Manager-Ausnahmemeldungen
Ausnahmemeldungen werden benutzt, um Informationen in einem Nicht-Anforderungs/Antwort-Format weiterzuleiten.
8.7.1 NS_XCP_NETWORK_SP_ADDED
Beschreibung
Diese Meldung wird vom Netzwerkdatenbank-Manager zu einem Netzwerkdienstanbieter gesendet, um anzuzeigen, daß der Netzwerkdienstanbieter zur Datenbank hinzugefügt und ihm ein gültiges Teilnetz/eine gültige Knotenadresse zugewiesen wurde.
Dienstparameter

Revision – aktuelle Ausgabe des im Netzwerkdatenbank-Manager-Gerät laufenden Netzwerkdatenbank-Managers
NetDBMDevice – Gerät, in dem der Netzwerkdatenbank-Manager läuft.

8.7.2 NS_XCP_SERVICE_PIN
Beschreibung
Der Netzwerkdatenbank-Manager leitet alle Dienst-Pin-Meldungen zu allen registrierten Netzwerkdienstanbietern weiter.
Dienstparameter

NeuronId – 6-Byte-MAC-Adresse
ProgramId – 8-Byte-Anwendungsprogrammkennung

8.8 Interne Softwarekomponenten
8.8.1 Sitzungs-/Transaktions-Ablaufsteuereinheit
Wenn eine Dienstanforderung empfangen wird, die mehrere Transaktionen erfordert, wird eine Sitzung eingeleitet. Der Dienst wird dann in eine Anzahl von Transaktionen zerlegt. Die Transaktionen werden mit einer Geschwindigkeit verarbeitet, die durch die Transportschichten bewältigt werden kann. Bei Empfang von Netzwerkverwaltungs-Antwortmeldungen werden diese verarbeitet, um die Transaktion auszuführen. Wenn alle Transaktionen für einen gegebenen Sitzungszustand ausgeführt sind, wird der nächste Zustand in weitere Transaktionen zerlegt, bis der letzte Zustand erreicht ist. Zu diesem Zeitpunkt wird eine Antwort gesendet, und der Netzwerkdatenbank-Manager ist bereit zum Verarbeiten des nächsten Dienstes.
Wenn eine Anforderung bei laufender Sitzung empfangen wird, dann wird sie zur späteren Verarbeitung in die Warteschlange eingereiht.
8.8.2 Fehlerbehebung
Die Verarbeitung bestimmter Netzwerkverwaltungsdienste erfordert eine Anzahl von Änderungen an einem oder mehreren Geräten. Bei der Ermittlung und Verarbeitung der benötigten Modifikationen kann ein Fehler erkannt werden, der darauf schließen läßt, daß eine bestimmte Modifikation nicht abgeschlossen werden konnte. Dies könnte aus einem von zwei Gründen passieren: 1) eine Fehlermeldung bzw. -reaktion auf eine Netzwerkverwaltungsmeldung oder 2) das Gerät geht in einen Offline-Zustand.
Wenn der Ausfall auf einen Fehler zurückzuführen ist, werden, wenn möglich, die übrigen Modifikationen verarbeitet. Die Netzwerkdatenbank wird so modifiziert, daß sie den gewünschten Zustand aller Geräte repräsentiert, wenn der Dienst fehlerfrei ausgeführt worden wäre. Der Zustand des die Anforderungen verletzenden Geräts wird so eingestellt, daß der Fehlerzustand angezeigt wird. Eine Antwort auf die Dienstanforderung wird zurückgesendet, welche die teilweise Ausführung des Dienstes anzeigt. Durch ein Dienstereignis werden andere Netzwerkdienstanbieter über die Nichtübereinstimmung des Datenbank-Geräts informiert. Etwaige weitere Dienstanforderungen, die das die Anforderungen verletzende Gerät betreffen, veranlassen die Rücksendung einer Fehlerreaktion.
Wenn ein Gerät in den Offline-Zustand geht, bevor eine geplante Modifikation abgeschlossen werden kann, dann zeigt der Gerätestatus dies an, und die Dienstantwort zeigt die teilweise Ausführung des Dienstes an. Wenn das Gerät in einen Online-Zustand zurückkehrt, wird die Modifikation abgeschlossen und eine Ablaufunterbrechung generiert. 8.8.3 Änderungen von Adressentabellen
Parameter
pucNodeCount – Zeiger auf die Anzahl der Knoten in dieser Verbindung. Wenn eine bestehende Gruppe modifiziert wird und weitere Adressenfelder hinzugefügt werden, dann wird dieser Zählwert erhöht.

pucNode – Zeiger auf eine Knotenanordnung. pu
cAdressGroup – Zeiger auf eine Adressengruppen-Nummer. Wenn die Auswahl erfolgreich ist, wird eine Adressengruppen-Nummer zurückgegeben.
eResult – Zeiger auf Ergebnis.
SEL_MATCH in allen Knoten wurde eine existierende Gruppe gefunden
SEL_NEW_GROUP eine neue Gruppe wurde erzeugt
SEL_MODIFY_GROUP eine extistierende Gruppe wurde modifiziert

Fehler

NM_ERROR_ADDRESS_CONFLICT (Adressenkonflikt)
NM_ERROR_EXCEED_MAX_ADDRESS_GROUPS (maximale Adressengruppenzahl überschritten)
NM_ERROR_EXCEED_MAX_ADDRESS_IN_NODE (maximale Adressengruppenzahl im Knoten überschritten)

Algorithmus

1. Verbindungsknotenliste für Verbindungsanforderung generieren.
2. Adressentabelle nach Adressengruppe abfragen, welche die meisten Knoten aus der Verbindungsliste enthält.
a) Wenn eine Gruppe gefunden wird, die alle Knoten enthält, dann
i) Gruppe zurückgeben.
b) Wenn mehrere Gruppen gefunden werden, die alle Knoten enthalten, dann
i) Gruppe mit der niedrigsten Knotenzahl zurückgeben
c) Wenn keine Gruppen gefunden werden, die alle Knoten enthalten, dann
i) Gruppe mit den meisten Knoten zurückgeben
3. Wenn Gruppe gefunden wird, die alle Knoten enthält, dann
a) unter Verwendung dieser Gruppe zuweisen
4. Wenn keine Gruppe gefunden wird, die alle Knoten enthält, dann für neue Gruppe oder modifizierte Gruppe auswerten
a) Wenn alle Knoten 4 oder mehr Öffnungen in der Adressentabelle aufweisen, dann
i) neue Gruppe hinzufügen
ii) unter Verwendung dieser Gruppe zuweisen
b) Wenn irgendein Knoten weniger als 4 Öffnungen aufweist, dann
i) Adressengruppe zur Modifikation auswählen
a) Knotenliste nach Anzahl der Öffnungen in der Adressentabelle ordnen
b) unter Verwendung von Gruppen aus ersten Knoten (nach Sortierungsreihenfolge) der Adressentabelle die Gruppe finden, welche die meisten Knoten in Folge enthält
ii) übrige Knoten dieser Gruppe hinzufügen
iii) unter Verwendung dieser Gruppe zuweisen
5. Wenn mehr als ein Knoten eine vollständige Adressentabelle aufweist und keine Gruppe alle diese Knoten enthält, dann
a) Gruppen für Vereinigung auswerten
i) die Liste von Knoten finden, die vollständige Adressentabellen aufweisen
ii) die Menge von alle diese Knoten enthaltenden Gruppen finden, welche die kleinste Anzahl von Knoten enthält
iii) diese Knoten zu einer Gruppe vereinigen
b) alle durch die Umgruppierung beeinflußten Adressentabellen und Zuweisungen modifizieren
c) unter Verwendung der neuen Gruppe zuweisen

9. NETZWERKDATENBANK
9.1 Übersicht
Die Netzwerkdatenbank ist ein Depot für alle Netzwerkverwaltungsinformationen. Auf sie kann nur durch den Netzwerkdatenbank-Manager zugegriffen werden.
Für jeden Feldbus existiert eine getrennte Netzwerkdatenbank. Die Netzwerkdatenbank enthält Informationen über alle an den Feldbus angeschlossenen Knoten, die Adressengruppen und die Verbindungen zwischen an diesen Feldbus angeschlossenen Netzwerkvariablen.
Die Netzwerkdatenbank enthält die folgenden Tabellen:

1. NODE_TABLE (Knotentabelle)
2. HUB_TABLE (Verteilertabelle)
3. TARGET_TABLE (Zieltabelle)
4. GROUP_TABLE (Gruppentabelle)

9.2. Datenbankstrukturen
9.2.1 Knotentabelle
Die Knotentabelle enthält allgemeine Informationen über die vollständige Datenbank. Sie enthält außerdem Informationen für jeden verwalteten Knoten, die vom Netzwerkdatenbank-Manager zur Verarbeitung angeforderter Dienste benötigt werden. Struktur der Knotentabelle
Parameterbeschreibung

usNDBRevision – Revisionsnummer der Datenbankstrukturen
eNDBMState – Auflistung, die den Zustand des Netzwerkdatenbank-Managers anzeigt: NDBM_STATE_UNINITIALIZED = 0 NDBM_STATE_IAM_NETDBM = 1 NDBM_STATE_DISABLED = 2 NDBM_STATE_EXCEPTION = 3
sLastUpdate – Datum/Zeit der letzten Modifikation der Netzwerkdatenbank
sMySubnetNode – Teilnetz-Knotenadresse des Knotens, der den Netzwerkdatenbank-Manager enthält
btMaxNumNodes – maximale Anzahl von Einträgen in der Matrix asNodeData
asNodeData[] – eine Matrix von Datenstrukturen für jeden Knoten in der Datenbank

Struktur der Knotendaten
Parameterbeschreibung

eNodeType – Auflistung, die den Knotentyp anzeigt: NODE_TYPE_UNKNOWN 0 NODE_TYPE_SELF 1 NODE_TYPE_PERMANENT 2 NODE_TYPE_TEMPORARY 3
Node – die Knoten-ID-Nummer.
SubNet – das Teilnetz, dessen Element der Knoten ist. Der derzeitige Vorgabewert ist 1.
NeuronID – die vom Hersteller des Neuron-Chips zugewiesene 48-Bit-ID-Nummer
IdString – Programm-ID-Nummer der Geräte
eNodeState – aktueller Zustand des Knotens. NODE_UNKNOWN 0 NODE_UNCOMMISSIONED 1 NODE_ONLINE 2 NODE_OFFLINE 3
BitAddressCount – Anzahl der Einträge in der Knotenadressentabelle für die ReadOnly-Daten der Knoten
bitAddressesUsed – Anzahl der Einträge in der aktuell genutzten Adressentabelle. Diese (Anzahl) wird bei der Verarbeitung von Gruppen verwendet, um festzustellen, ob der Knoten einer neuen Gruppe hinzugefügt werden kann.
bitHostedNode – WAHR, wenn der Knoten einen Host- bzw. Wirtsrechner aufweist.
bitTwoDomains – WAHR, wenn der Knoten zwei Domains unterstützt.
bitUnused – Ersatzbits.
usNumNVs – Anzahl der Netzwerkvariablen (NV) im Knoten
btVersionSNVTStruct – Versionsnummer der SNVT-Informationsstruktur. Diese wird beim Lesen späterer Datensätze in der SNVT-Informationstabelle benutzt
usSNVTStructAddress – Adresse der SNVT-Struktur aus der ReadOnly-Datenstruktur des Neurons.
sNodeAddress – Adresse, die bei der Kommunikation mit dem Gerät zu benutzen ist.
asAddressTable – Tabelle, die zum Speichern von Informationen benutzt wird, die benötigt werden, um die Adressengruppentabelle im Knoten zu unterhalten.

Datenstruktur der Adressentabelle
Parameterbeschreibung

bitInUse – WAHR, wenn dieser Eintrag in der Adressentabelle aktuell benutzt wird.
bitConnDescId – die für diesen Adresseneintrag benutzte Verbindungsbeschreibung. bitAddressType – Typ des Adresseneintrags. ADDRESS_TYPE_NOT_IN_USE 0 ADDRESS_TYPE_GROUP 1 ADDRESS_TYPE_SUBNET_NODE 2 ADDRESS_TYPE_BROADCAST 3 ADDRESS_TYPE_TURN_AROUND 4
sGroup.btMemberId – wenn bitAddressType == ADDRESS TYPE GROUP, ist die Element-ID-Nr. in der Gruppe enthalten. Gültige Werte: 1–63.
sGroup.GroupId – Gruppenkennzeichner, wenn bitAddressType == ADDRESS_TYPE_GROUP. Gültige Werte: 1–255.
sNode.btSubNet – wenn bitAddressType == ADDRESS_TYPE_SUBNET_NODE, ist das Teilnetz, in dem sich der adressierte Knoten befindet, ein Element.
sNode.btNode – der adressierte Knoten, wenn bitAddress Type == ADDRESS_TYPE_SUBNET_NODE.
sBCast.btSubNet – das Teilnetz, in dem eine bcast-Meldung (allgemeine bzw. Rundmeldung). zu senden ist, wenn bitAddressType == ADDRESS TYPE BROADCAST.
sBCast.btBackLog – wenn bitAddressType == ADDRESS_TYPE_ BROADCAST.

9.2.2 Verbindungstabellen
Struktur der Verbindungsverteilertabelle
Parameterbeschreibung

usMaxNumHubs – Größe der Matrix asHubData.
asHubData [] – eine Matrix von Datenstrukturen für den Verteiler (Hub) jeder Verbindung in der Datenbank.

Verbindungsverteiler-Datenstruktur
Parameterbeschreibung

hNode – Knotenzugriffsnummer des Geräts, das die Verteiler-Netzwerkvariablen (Hub-NV) enthält.
ConnDescId – Die Verbindungsbeschreibung, die zur Beschreibung dieser Verbindung benutzt wird.
bitDirection – Richtung der Hub NV
bitConnState – Zustand der Verbindung: CONNECTION_STATE_UNBOUND CONNECTION_STATE_INPROCESS CONNECTION_STATE_BOUND
bitAddressIndex – Index in der für diese Verbindung benutzten Knotenadressentabelle.
GroupId – Gruppennummer, wenn bei dieser Verbindung Gruppenadressierung benutzt wird, null, wenn Teilnetzknotenadressierung benutzt wird, 0xFFFF, wenn Rundsendeadressierung benutzt wird.
HubNVIndex – Index der Verteiler-Netzwerkvariablen (Hub-NV)
usFirstTarget – Index der Verbindungszieltabelle der ersten Ziel-Netzwerkvariablen (Ziel-NV).
btSNVTType – SNVT-Typ der Verteiler-Netzwerkvariablen (Hub-NV).

Verbindungszieltabellenstruktur
Parameterbeschreibung

usMaxNumTargets – Anzahl der Elemente in der Matrix asTargetData.
usFreeTarget – Index des ersten freien Ziels.
usTargetsAvailable – Anzahl unbenutzter Zieleinträge.
asTargetData[] – Matrix von Datenstrukturen zur Beschreibung jedes Ziels.

Datenstruktur des Verbindungsziels
Parameterbeschreibung

hNode – Zugriffsnummer für den Knoten, der diese Ziel-Netzwerkvariable (Ziel-NV) enthält.
usNVIndex – Index der Ziel-NV
btAddressIndex – Index in der für diese Verbindung benutzten Knotenadressentabelle.
usNextTarget – Index der nächsten Abschlußeinrichtung in der TermTable, null für die letzte Abschlußeinrichtung in der Liste.

9.2.3 Gruppentabelle
Gruppentabellenstruktur
Parameterbeschreibung

btNumConnDesc – Anzahl – der Verbindungsbeschreibungen, die so definiert ist, daß sie MAX_NUMBER_CONN_DESC nicht übersteigt. Aktuell = 10.
asConnDescription[] – Matrix von Verbindungsbeschreibungen, auf die durch den Matrixindex verwiesen wird. btHighestAddressGroup – Höchste aktuell definierte Adressengruppe. Gültige Werte 1 – MAX_NUMBER_ADDRESS GROUPS, aktuell = 255.
usMaxMemberIndex – Größe der Matrix GroupMember.
usHighestMemberIndex – höchster aktuell benutzter GroupMember-Index.
asAddrGroup[] – Matrix von Daten zur Beschreibung jeder Adressengruppe. GroupId ist der Matrixindex.
asGroupMember[] – Matrix von Daten für jedes Element. Gruppenelemente werden in sequentiellen Matrixelementen in aufsteigender Reihenfolge nach Knotenzugriffsnummer gehalten.

Adressengruppen-Datenstruktur
Parameterbeschreibung

btNumberOfMembers – Gesamtzahl der Elemente in dieser Gruppe
usGroupMemberIndex – Index des ersten Gruppenelements in der Matrix GroupMember.
ConnDescId – für diese Adressengruppe benutzte Verbindungsbeschreibung.

Tabelle der Gruppenelemente
Parameterbeschreibung

bitNodeInitialize – WAHR, wenn Elementdaten eingesetzt werden.
bitAddressIndex – Index in der Adressentabelle, die zum Speichern dieser Gruppenadresse benutzt wird.
hNode – der betreffende Knoten.

Struktur der Verbindungsbeschreibung
Parameterbeschreibung

btServiceType – für Aktualisierungsmeldungen benutzte Dienstart. SERVICE_TYPE_ACKD SERVICE_TYPE_UNACKD_RPT SERVICE_TYPE_UNACKD SERVICE_TYPE_REQUEST
btPriority – WAHR, wenn Aktualisierungsmeldungen einen Prioritätskanal nutzen.
btAuthenticate – WAHR, wenn Aktualisierungsmeldungen die Authentifikation nutzen.
btRetryCount – Wiederholungszahl, die für quittierte Dienste und für Abfragen verwendet wird.
btRepeatTimer – Zeit zwischen Wiederholungen bei Verwendung eines Dienstes mit Meldungswiederholung.
btReceiveTimer – Zeitspanne, während der Wiederholungsknoten Meldungen mit der gleichen Quelle behandeln und auf ID-Nummern als Duplikatmeldungen verweisen (2^7+(n/2) ms).
btTransmitTimer – Zeit zwischen Wiederholungen für Wiederholungs- und quittierte Dienste (2^4+(n/2) ms).

Claims

ECHELON-Netzwerk (14), welches aufweist: einen eingebetteten Knoten (10, 10', 16) mit einem Netzwerkdatenbank-Manager (13), der auf Netzwerkverwaltungsdienstanforderungen von mehreren Clientanwendungen anspricht, mindestens eine ECHELON-Verbindung (33, 45), die kommunikationsfähig mit mindestens einem anderen Knoten zu den mehreren Clientanwendungen und mit mindestens einem Netzwerkdienstanbieter verbunden ist, wobei der eingebettete Knoten eine Netzwerkdatenbank (11) aufweist, die Verbindbarkeitsinformationen für die mindestens eine ECHELON-Verbindung (33, 45) aufweist, wobei der mindestens eine Netzwerkdienstanbieter mit dem Netzwerkdatenbank-Manager verbunden ist.
ECHELON-Netzwerk nach Anspruch 1, wobei der mindestens eine andere Knoten eine Workstation (12) aufweist.
ECHELON-Netzwerk nach Anspruch 2, wobei die Workstation die mehreren Clients aufweist.
ECHELON-Netzwerk nach Anspruch 1, welches weiter mehrere ECHELON-Verbindungen aufweist, die zur Verbindung mit mehreren anderen Knoten ausgelegt sind, wobei die Netzwerkdatenbank Verbindbarkeitsinformationen für jede der mehreren ECHELON-Verbindungen aufweist.
ECHELON-Netzwerk nach Anspruch 4, wobei die mehreren anderen Knoten weiter mehrere Workstations aufweisen, die jeweils mindestens einen Client aufweisen.
ECHELON-Netzwerk nach Anspruch 1, welches für einen Betrieb alternativ mit dem damit verbundenen Netzwerkdienstanbieter oder ohne diesen ausgelegt ist.
ECHELON-Netzwerk nach Anspruch 1, wobei die mehreren Clients integral mit dem mindestens einen Netzwerkdienstanbieter verbunden sind und der mindestens eine Netzwerkdienstanbieter dafür ausgelegt ist, fern mit dem eingebetteten Knoten verbunden zu werden.
ECHELON-Netzwerk nach Anspruch 1, welches weiter mehrere ECHELON-Verbindungen aufweist, die zur Verbindung mit mehreren anderen Knoten ausgelegt sind, wobei die Netzwerkdatenbank Verbindbarkeitsinformationen für jede der mehreren ECHELON-Verbindungen aufweist.
ECHELON-Netzwerk nach Anspruch 8, wobei die mehreren anderen Knoten weiter mindestens einen ersten Knoten und mindestens einen zweiten Knoten aufweisen, wobei der mindestens eine erste Knoten den Netzwerkdienstanbieter aufweist, wobei der eingebettete Knoten mit dem mindestens einen zweiten Knoten durch einen Netzwerkbus verbunden ist und der eingebettete Knoten dafür ausgelegt ist, durch eine Verbindung, die von dem Netzwerkbus diskret ist, mit dem mindestens einen ersten Knoten verbunden zu werden.
ECHELON-Netzwerk nach Anspruch 9, welches weiter mehrere der ersten Knoten aufweist, die jeweils einen diskreten Netzwerkdienstanbieter aufweisen.
ECHELON-Netzwerk nach Anspruch 8, wobei der eingebettete Knoten mit den mehreren anderen Knoten durch einen Netzwerkbus verbunden ist.
ECHELON-Netzwerk nach Anspruch 8, wobei die mehreren anderen Knoten weiter mindestens einen ersten Knoten und mindestens einen zweiten Knoten aufweisen, wobei der mindestens eine erste Knoten den Netzwerkdienstanbieter aufweist, wobei der eingebettete Knoten lokal mit dem mindestens einen zweiten Knoten verbunden ist, so dass Netzwerkverkehr zwischen dem Netzwerkdatenbank-Manager und dem mindestens einen zweiten Knoten unabhängig von einem Netzwerkdienstanbieter behandelt wird.
ECHELON-Netzwerk nach Anspruch 12, wobei der eingebettete Knoten dafür ausgelegt ist, fern mit dem mindestens einen ersten Knoten verbunden zu werden.
ECHELON-Netzwerk nach Anspruch 1, wobei der mindestens eine andere Knoten weiter mit der mindestens einen ECHELON-Verbindung verbunden ist, wobei der mindestens eine andere Knoten einen Netzwerkdienstanbieter und mehrere Clients aufweist.
ECHELON-Netzwerk nach Anspruch 14, wobei der mindestens eine Knoten ferner mindestens einen ersten Knoten und mindestens einen zweiten Knoten aufweist, wobei der mindestens eine erste Knoten den Netzwerkdienstanbieter aufweist, wobei der eingebettete Knoten lokal mit dem mindestens einen zweiten Knoten verbunden ist und der eingebettete Knoten fern mit dem mindestens einen ersten Knoten verbunden ist.
ECHELON-Netzwerk nach Anspruch 1, wobei der eingebettete Knoten keinen Netzwerkdienstanbieter aufweist.
ECHELON-Netzwerk nach Anspruch 16, wobei der eingebettete Knoten dafür ausgelegt ist, mit einem Netzwerkdienstanbieter verbunden zu werden.
Eingebetteter Knoten (10, 10', 16) zur Verwendung in einem ECHELON-Netzwerk (14), wobei der Knoten aufweist: einen Netzwerkdatenbank-Manager (13), eine Netzwerkdatenbank (11), die mit dem Netzwerkdatenbank-Manager (13) verbunden ist, wobei der Netzwerkdatenbank-Manager (13) auf Netzwerkverwaltungsdienstanforderungen von mehreren Clients anspricht, die sich in dem ECHELON-Netzwerk (14) befinden können, und die Netzwerkdatenbank (11) Verbindungstabellen (91, 93) zur Wartung variabler Verbindungen für mehrere Clients innerhalb des ECHELON-Netzwerks aufweist.
ECHELON-Netzwerk, welches aufweist: einen ersten Knoten, der ein eingebetteter Knoten (10, 10', 16) ist und einen Netzwerkdatenbank-Manager (13) und eine damit verbundene Netzwerkdatenbank (11) aufweist, wobei der Netzwerkdatenbank-Manager (13) auf Netzwerkverwaltungsdienstanforderungen anspricht, einen zweiten Knoten, der eine Betreiber-Workstation (12) ist und einen Netzwerkdienstanbieter (35) aufweist, der dafür ausgelegt ist, die Netzwerkverwaltungsdienstanforderungen zu erzeugen, wobei der zweite Knoten mehrere Clients aufweist, die dafür ausgelegt sind, die Netzwerkverwaltungsdienstanforderungen zu erzeugen, wobei der erste Knoten und der zweite Knoten durch eine Netzwerkverbindung (14, 15) kommunikationsfähig verbunden sind, um die ECHELON-Netzwerkverwaltung zu erleichtern.
ECHELON-Netzwerk nach Anspruch 19, welches weiter mehrere der zweiten Knoten aufweist.
ECHELON-Netzwerk nach Anspruch 20, wobei mindestens einer der mehreren zweiten Knoten fern mit dem ersten Knoten verbunden ist.
ECHELON-Netzwerk nach Anspruch 20, wobei mindestens einer der mehreren zweiten Knoten lokal mit dem ersten Knoten verbunden ist.
Verfahren zum Betrieb in einem ECHELON-Netzwerk (14), wobei das Verfahren aufweist: Ausführen mehrerer Anwendungsprogramme (39) in einem ersten Computer (12), Ausführen eines Netzwerkdienstanbieters (35) in dem ersten Computer, wobei der Netzwerkdienstanbieter beim Bereitstellen von Netzwerkverwaltungsdiensten kommunikationsfähig mit dem Anwendungsprogramm (39) verbunden wird, und Ausführen eines Netzwerkdatenbank-Managers (13) in einem zweiten eingebetteten Computer (10, 10', 16), wobei der Netzwerkdatenbank-Manager (13) durch das ECHELON-Netzwerk (14) beim Bereitstellen der Netzwerkdatenbankverwaltung für den Netzwerkdienstanbieter (35) kommunikationsfähig mit dem Netzwerkdienstanbieter (35) verbunden wird.
Verfahren nach Anspruch 23, wobei der eingebettete Knoten betrieben wird durch: Erzeugen einer Nachrichtenwarteschlange, Erzeugen einer Warteschlange, Empfangen von Netzwerkverwaltungsdienstanforderungs-Nachrichten, Empfangen von LONTALK-Nachrichten über das ECHELON-Netzwerk, Verarbeiten von LONTALK-Nachrichten, die sich auf eine aktuelle Netzwerkverwaltungsdienstanforderung beziehen, über die Nachrichtenwarteschlange und Speichern von Nachrichten, die sich auf andere als aktuelle Netzwerkverwaltungsdienstanforderungen beziehen, in der Warteschlange.
Verfahren zum Betrieb eines ECHELON-Netzwerks (14) mit einem eingebetteten Knoten (10, 10', 16) und mindestens zwei anderen Knoten, wobei das Verfahren die folgenden Schritte aufweist: Aufnehmen einer Netzwerkdatenbank (11), die Informationen in Bezug auf die mindestens zwei anderen Knoten enthält, ansprechend auf eine Kommunikation von mehreren Clients, in den eingebetteten Knoten (10, 10', 16), Empfangen einer ersten LONTALK-Nachricht von einem ersten Knoten der mindestens zwei anderen Knoten, wobei die Nachricht ein Vorläufer einer ersten Netzwerkdatenbankaktion durch den eingebetteten Knoten (10, 10', 16) ist, durch den eingebetteten Knoten (10, 10', 16), Beginnen der Netzwerkdatenbankaktion, die sich aus der ersten LONTALK-Nachricht ergibt, durch den eingebetteten Knoten (10, 10', 16) und Empfangen einer zweiten LONTALK-Nachricht von einem zweiten Knoten der mindestens zwei anderen Knoten, wobei die Nachricht ein Vorläufer einer anderen Netzwerkdatenbankaktion durch den eingebetteten Knoten (10, 10', 16) ist, durch den eingebetteten Knoten (10, 10', 16) und Abschließen der ersten Netzwerkdatenbankaktion vor dem Verarbeiten der anderen Netzwerkdatenbankaktion durch den eingebetteten Knoten (10, 10', 16).