DE102015119643A1

DE102015119643A1 - Verfahren und Vorrichtungen zur Bereitstellung von Redundanz in einem Prozesssteuerungssystem

Info

Publication number: DE102015119643A1
Application number: DE102015119643.3A
Authority: DE
Inventors: William Bennett; Joel Nicholas Ohmart; Dirk Thiele
Original assignee: Fisher Rosemount Systems Inc
Current assignee: Fisher Rosemount Systems Inc
Priority date: 2014-11-14
Filing date: 2015-11-13
Publication date: 2016-05-19
Also published as: JP7046473B2; US20160142283A1; GB2536750A; JP7009560B2; JP2020167714A; GB201520094D0; CN105607590B; GB2536750B; JP2016096549A; US10003525B2; CN105607590A

Abstract

Es werden Verfahren und Vorrichtungen zur Bereitstellung von Redundanz in einem Prozesssteuerungssystem offenbart. Ein beispielhaftes Verfahren beinhaltet an einem ersten Netz-Host das Empfangen erster Integritätsnachrichten, die von einem zweiten Netz-Host über ein erstes Netz übertragen werden. Das Verfahren beinhaltet einen Netzausfall über einen ersten Kommunikationsweg zwischen einer ersten Netzschnittstelle des ersten Netz-Hosts und einer zweiten Netzschnittstelle des zweiten Netz-Hosts über erstes Netz, wenn eine erste Netzschnittstelle des ersten Netz-Hosts eine von den ersten von einer ersten Netzschnittstelle des zweiten Netz-Hosts erwarteten Integritätsnachrichten nicht empfängt. Das Verfahren beinhaltet das automatische Einrichten eines Kommunikationswegs zwischen dem ersten Netz-Host und dem zweiten Netz-Host als Antwort auf den detektierten Netzausfall.

Description

GEBIET DER OFFENBARUNG
Diese Offenbarung betrifft allgemein Prozesssteuerungssysteme und insbesondere Verfahren und Vorrichtungen zur Bereitstellung von Redundanz in einem Prozesssteuerungssystem.
STAND DER TECHNIK
Prozesssteuerungssysteme, wie diejenigen, die in chemischen, Erdöl- oder anderen Prozessen verwendet werden, beinhalten typischerweise einen oder mehrere mit einem oder mehreren Feldgeräten über analoge, digitale oder kombinierte Analog-/Digitalbusse kommunikativ gekoppelte Prozessregler. Die Feldgeräte, die zum Beispiel Ventile, Ventilstellungsregler, Schalter und Transmitter (z.B. Temperatur-, Druck- und Fließratensensoren) sein können, führen innerhalb des Prozesses Prozesssteuerungsfunktionen, wie Öffnen oder Schließen von Ventilen und Messen von Prozesssteuerungsparametern durch. Die Prozessregler empfangen Signale, die Prozessmessungen anzeigen, die durch die Feldgeräte gemacht wurden, und verarbeiten dann diese Informationen zur Erzeugung von Steuerungssignalen, um Steuerungsroutinen zu implementieren, andere Prozesssteuerungsentscheidungen zu treffen und Prozesssteuerungssystemalarme auszulösen.
Informationen von den Feldgeräten und/oder den Reglern werden gewöhnlich über eine Datenautobahn oder ein Kommunikationsnetz an eine oder mehrere andere Hardwaregeräte, wie Bedienerarbeitsplätze, PCs, Datenhistorians, Berichtgeneratoren, zentralisierte Datenbanken etc. verfügbar gemacht. Solche Geräte befinden sich typischerweise in Steuerungsräumen und/oder anderen, in Bezug auf das rauere Anlagenumfeld entfernt gelegenen Standorten. Diese Hardwaregeräte führen zum Beispiel Applikationen aus, die es einem Bediener ermöglichen, mit Bezug zu dem Prozess eines Prozessteuerungssystems jede einer Vielfalt an Funktionen durchzuführen, wie das Ansehen des derzeitigen Zustands des Prozesses, das Ändern eines Betriebszustands, das Ändern von Einstellungen einer Prozesssteuerungsroutine, das Modifizieren des Betriebs der Prozessregler und/oder der Feldgeräte, das Ansehen von Alarmen, die durch Feldgeräte und/oder Prozessregler erzeugt wurden, das Simulieren des Betriebs des Prozesses zum Zwecke der Schulung von Personal und/oder des Beurteilens des Prozesses etc.
Die Kombination der Technologiefortschritte in der Computerarchitektur, Vernetzung und Virtualisierung hat die Entwicklung effektiver, leicht zu handhabender, virtualisierter Computerumgebungen ermöglicht, die bestimmte Steuerungssysteme implementieren können. Das heißt, dass die Arbeitsplätze, PCs und anderen Hardwaregeräte, die in einem traditionellen Steuerungssystem verwendet werden, durch in einer virtuellen Prozesssteuerungsumgebung implementierte virtuelle Maschinen ersetzt werden können. Endnutzer nehmen Zugriff auf Applikationen und Software, die auf solchen virtuellen Maschinen über mit dem virtuellen System verbundene Thin Clients implementiert sind. Auf diese Weise können die erheblichen Kosten und Komplexität des Erwerbens, Konfigurierens und Wartens aller Hardwarekomponenten, die herkömmlicherweise erfordert wäre, reduziert werden.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1 ist eine schematische Darstellung eines beispielhaften Prozesssteuerungssystems, in welchem die Lehren dieser Offenbarung implementiert werden können.
2 ist eine schematische Darstellung einer beispielhaften Netzanordnung eines Teils des beispielhaften Prozesssteuerungssystems von 1.
3 ist ein Blockdiagramm einer beispielhaften Implementierung von jedem der Netz-Hosts in dem beispielhaften Prozesssteuerungssystems von 1 und/oder 2.
4 ist eine schematische Darstellung eines beispielhaften Systems von Netz-Hosts, die über zwei gemeinsame Netze verbunden sind.
5 ist eine Tabelle, die den Kommunikationsstatus zwischen den Netz-Hosts von 4 repräsentiert.
6 ist eine schematische Darstellung des beispielhaften Systems von 4 mit einem einem der Netz-Hosts zugeordneten Netzversagen.
7 ist eine Tabelle, die den Kommunikationsstatus zwischen den Netz-Hosts von 6 repräsentiert.
8 ist eine Tabelle, die beispielhafte Änderungen im Zeitraffer an Integritätsnachrichten veranschaulicht, die durch jeden der Netz-Hosts von 4 während einer anfänglichen Entdeckung der Netz-Hosts übertragen wurden, und das Netzversagen von 6 umgeben.
9 ist eine Tabelle, die verschiedene beispielhafte Änderungen im Zeitraffer an Integritätsnachrichten veranschaulicht, die durch jeden der Netz-Hosts von 4 während einer anfänglichen Entdeckung der Netz-Hosts übertragen wurden.
10 ist eine schematische Darstellung eines beispielhaften Systems von zwei beispielhaften Netz-Hosts, die über zwei gemeinsame Netze verbunden sind.
11 und 12 sind schematische Darstellungen des beispielhaften Systems von 10 mit jeweils einem Netzversagen in jedem der zwei Netze.
13A–B sind Ablaufdiagramme, die ein beispielhaftes Verfahren zur Implementierung der beispielhaften Netz-Hosts von 1–4, 6 und/oder 10–12 veranschaulichen, um Redundanz zwischen den Netz-Hosts bereitzustellen.
14 ist eine schematische Darstellung einer beispielhaften Prozessorplattform, die verwendet und/oder programmiert werden kann, um das beispielhafte Verfahren von 13A–B und/oder allgemeiner die beispielhaften Netz-Hosts von 1–4, 6 und/oder 10–12 zu implementieren.
AUSFÜHRLICHE BESCHREIBUNG
Die Verlässlichkeit ist bei der Implementierung von Prozesssteuerungssystemen ein häufiges Anliegen und ist insbesondere ein Anliegen bei virtualisierten Steuerungssystemen, bei denen die vielen herkömmlicherweise getrennten Arbeitsplätze und anderen Computerkomponenten alle als virtuelle Maschinen (VM) auf einem Cluster von Host-Servern implementiert sind. Um diese Anliegen in Angriff zu nehmen, bieten Hardwarehersteller Hardwarelösungen für erhöhte Verlässlichkeit an, wie Speicherbereichsnetz(SAN – storage area network)-Geräte mit redundanten Disk-Arrays, Regler und Netzversorgung. Mehrere Host-Server sind gewöhnlich mit einem hoch redundanten SAN geclustered, um die Verfügbarkeit des Gesamtsystems zu erhöhen und Raum für Wartung, wie Aktualisierung oder Ersatz von Komponenten, zu ermöglichen, ohne dass es erforderlich ist, das ganze physische System herunterzufahren. Betriebssysteme des Stands der Technik, wie Windows Server 2012, erleichtern das Bewegen von VM von einem Teil des physischen Systems (z.B. Festplatte) zu einem anderen Teil des Systems oder sogar zu einem externen Sicherungssystem, während die VM weiter ausführt und tun dies ohne bemerkenswerte Auswirkung auf den Betrieb oder die Kommunikation der Applikationen oder Nutzerinteraktionen, die möglicherweise auf der VM stattfinden. Solche Lösungen erhöhen die Verfügbarkeit einer breiten Vielfalt an virtuellen Maschinen, wie Email-Servern, Web-Servern und anderen nachgeschalteten Servern, auf die über Ethernet durch auf externen Computerknoten oder anderen Netz-Hosts, wie Thin Clients, installierten Software-Klienten zugegriffen werden kann.
Viele traditionelle (d.h. physische) Steuerungssysteme weisen viele betriebszugewandte Softwarekomponenten auf, die ein integraler Bestandteil des Systems sind, wie Bedienerschnittstellenapplikationen, Assetmanagementapplikationen, Alarmmangementapplikationen etc. Diese Komponenten führen einen beachtenswerte Menge an Geschäftslogik aus und verwenden urheberrechtlich geschützte Protokolle, um hohe Verfügbarkeit sicher zu stellen, wenn mit den anderen Komponenten des Steuerungssystems kommuniziert wird. In solchen Beispielen kann ein Bedienerplatz, wenn eine Verbindung zwischen dem Bedienerplatz und einem bestimmten Historian verloren wird, dennoch in der Lage sein, erwünschte historische Daten durch Zugriff auf die Informationen eines anderen Historians abzurufen. Wenn gleichermaßen eine Verbindung zwischen dem Bedienerplatz und einem bestimmten Regler verloren geht, kann der Bedienerplatz dennoch in der Lage sein, die erwünschten Laufzeitdaten von einem anderen Regler mit ähnlichen Messpunkten in dem Steuerungssystem zu beschaffen.
Einige der obigen Redundanzen werden unverfügbar, wenn ein Prozesssteuerungssystem virtualisiert wird, weil das Endnutzerendgerät, an dem die Daten an einen Bediener präsentiert werden, von den die Geschäftslogik (die die Daten erzeugt, die präsentiert werden) ausführenden Applikationen getrennt wird. Das heißt, dass in einigen virtualisierten Steuerungssystemen die Geschäftslogik durch VM ausgeführt wird, die auf einem zentralisierten Host-System implementiert ist, wohingegen die Endgeräte oftmals Thin Clients sind, die unter Verwenden entfernter Anzeigeprotokolle auf die Daten von den VM zur Anzeige zugreifen. Daher ist es unabhängig davon, ob eine VM Daten von einem alternativen Regler oder Historian abrufen kann, wenn sie die Verbindung mit einem primären Regler oder Historian verliert, irrelevant, ob die Daten an einem Thin Client angezeigt werden, wenn die Verbindung zwischen dem Thin Client und der VM ausfällt. Obwohl somit viele Redundanzen und damit verbundene Hardware in die Host-Server eingebaut sind, die die virtualisierte Umgebung implementiert, ist die Verbindung mit dem Endnutzerendgerätknoten (z.B. Thin Client) eine Schwachstelle bei der Verfügbarkeit und/oder Verlässlichkeit eines Systems.
Thin Clients sind oftmals nicht mit vielen redundanten Merkmalen ausgestattet (was zu einzelnen Ausfallpunkten führt), in der Annahme, dass wenn einer der einem virtuellen Steuerungssystem zugeordneten Thin Clients Ausfallzeit erfährt, auf die dem ausgefallenen Thin Client zugeordnete VM von einem anderen Endgerät zugegriffen werden kann. Einige Thin Clients wurden mit redundanten Netzkarten implementiert, sodass, wenn eine Netzverbindung verloren geht, der Thin Client zum Sicherungsnetz umschalten kann. Obwohl dies eine Verbesserung ist, leiden solche Lösungen immer noch an bestimmten Einschränkungen. Zum Beispiel wird die Übermittlung nicht bestätigter Datenübertragungen typischerweise während den erneuten Übertragungen erneut versucht. Wenn jedoch ein Netzausfall vorliegt, wird jeder Versuch der erneuten Übertragung auch fehlgehen und der Prozess wiederholt sich, bis die Netzverbindung abbricht. In einigen solchen Beispielen wird das Ausfallen erst nach dem Abbrechen der Verbindung bestätigt, an welchem Punkt ein alternativer Kommunikationsweg über ein Sicherungsnetz eingerichtet werden kann. Typischerweise kann die Zeit zur Detektion eines solchen Netzausfalls und Wiedereinrichtung einer Verbindung auf einem redundanten Netz weit mehr als eine Minute betragen. In vielen Prozesssteuerungseinstellungen ist eine Minute ohne Kommunikation unakzeptabel. Eine akzeptable Verzögerung ist oftmals weniger als fünf Sekunden. In vielen solcher Umstände ist sich der Endnutzer über die meiste Zeit zwischen dem Ausfall und der Wiederverbindung nicht bewusst, dass der Ausfall eingetreten ist und sieht daher möglicherweise Informationen an oder verlässt sich auf diese, die auf einem Bildschirm am Thin Client angezeigt werden, der nicht mehr aktuell ist. Darüber hinaus gehen außerdem Daten, die nach dem Netzausfall und vor der Einrichtung der neuen Verbindung übermittelt werden sollen, verloren.
Eine Lösung, die einem redundanten Netz nahtlose Ausfallsicherung ohne Verlust von Daten bereitstellt, beinhaltet die Verwendung des parallelen Redundanz-Protokolls (PRP). Das PRP erzielt durch zweimaliges Übertragen jedes Datenpakets, einmal auf jeder Netzschnittstelle von mindestens zwei Netzen, sichere Übermittlung von Datenkommunikationen, selbst wenn ein Netz ausfällt. Ein solcher Ansatz weist keine Verzögerung bei der Ausfallrückgewinnung auf und stellt sicher, dass keine Daten verloren werden. Ein solcher Ansatz beinhaltet jedoch erhebliche Erhöhung des Netzverkehrs und Computerverarbeitung, da doppelt so viele Daten übertragen und empfangen werden.
Andere Redundanzanordnungen wurden unter Verwenden besonderer Hardware, wie externen Schaltern, implementiert, die Redundanz handhaben und/oder mit Netzschnittstellenkarten arbeiten, die Linkaggregation zur Verwendung mit Thin Clients unterstützen. Es bestehen jedoch zusätzliche Kosten bei dem Erwerb und der Wartung zusätzlicher Hardwaregeräte. Darüber hinaus besteht je nach der Netzarchitektur eine zusätzliche Komplexität beim Konfigurieren der Schalter mit virtuellen lokalen Netzen (VLANs – virtual local area nets) und/oder Linkaggregation. Solche Hardwarekomponenten werden darüber hinaus oftmals durch verschiedene Hersteller angeboten, die sich von den Providern der Virtualisierungssoftware unterscheiden.
Die vorliegend offenbarten Beispiele stellen redundante Netzsysteme bereit, die die obigen Einschränkungen ohne den Verlust von Daten und ohne erhebliche Erhöhung der Datenverarbeitung oder Bandbreitenanforderungen überwinden, um schnelle Rückgewinnungszeiten (weniger als fünf Sekunden) bereitzustellen. Die vorliegend offenbarten Beispiele können über jede Gruppe von Netz-Hosts implementiert werden, wobei jede davon zwei Netzschnittstellen aufweist, die beide jeweils mit einem der zwei Netze verbunden sind. Im Sinne der vorliegenden Verwendung bezieht sich der Begriff „Netz-Host“ (oder „Host“) auf jeden Computer oder jedes andere Gerät (unabhängig davon, ob diese virtuell oder über physische Hardware implementiert sind), der/das an ein Netz unter Verwenden der Transmission Control Protocol/Internet Protocol(TCP/IP)-Protokollestapel verbunden ist. Beispielhafte Netz-Hosts beinhalten virtuelle Maschinen, Thin Clients, Thick Clients, eingebettete Regler und/oder jedes andere geeignete Rechnergerät.
Die vorliegend offenbarten Beispiele beinhalten multi-homed (Hosts mit mehreren Adressen) Netz-Hosts. Das heißt, jeder Host, der Teil der vorliegend beschriebenen Redundanz-Schemata sein soll, ist mit zwei unabhängigen Netzen über zwei Netzschnittstellen (z.B. NIC – network interface card – Netzschnittstellenkarte) verbunden. Jeder Host, der an demselben Redundanz-Schemata teilnimmt, ist weiterhin mit denselben zwei Netzen verbunden, wie jeder andere Host in dem Schema. Das heißt, jeder der Netz-Hosts beinhaltet zwei Netzschnittstellen, die verbindungsorientierte Kommunikationen über die zwei getrennten Netze ermöglichen, die allen Hosts gemein sind, die als Teil des Redundanz-Schemata einbezogen sind. Obwohl die Netz-Hosts, die Teil eines Redundanz-Schemas bilden, zwei gemeinsame Netze aufweisen, kann jedes der Netze auch einen oder mehrere andere Hosts beinhalten, die nicht mit dem anderen Netz verbunden sind. Obwohl solche Hosts nicht in dem vorliegend beschriebenen Redundanz-Schema beinhaltet sind, verhindern solche Hosts ein solches Schema nicht. Weiterhin können ein oder mehrere Hosts mit zusätzlichen Netzen verbunden sein, ohne die vorliegend offenbarten Lehren zu beeinträchtigen. Darüber hinaus können in einigen Beispielen außerdem mehrere Gruppen von Netz-Hosts innerhalb eines Prozesssteuerungssystems sein, die jeweils zwei gemeinsame Netze beinhalten. In solchen Beispielen kann jede Gruppe von Netzen die vorliegend offenbarten Lehren getrennt implementieren.
Obwohl die vorliegend beschriebenen Redundanz-Schemata zur Lösung spezifischer Anliegen bezüglich der Verfügbarkeit im Kontext virtueller Prozesssteuerungssysteme nützlich sind, können die vorliegen beschriebenen Lehren alternativ in einer gänzlich physischen Umgebung (d.h. ohne Virtualisierung) implementiert werden. Das heißt, die vorliegend offenbarten Lehren sind auf jeden Satz Netz-Hosts anwendbar, der zwei gemeinsame Netze teilt und basierend auf dem TCP/IP-Protokoll kommuniziert.
Die vorliegend beschriebenen beispielhaften Redundanz-Schemata werden durch Überwachen des Verbindungsstatus zwischen Netz-Hosts über zwei unabhängige Netze bewerkstelligt, die den Netz-Hosts gemein sind. Durch Überwachen der Netzverbindungen im Wesentlichen in Echtzeit werden Netzausfälle schnell detektiert. Sobald ein Netzausfall in einem der Netze detektiert wird, verwendet der zugeordnete Netz-Host gemäß den vorliegend offenbarten Lehren Internet Protokoll(IP)-Routingstandards, um einen alternativen Kommunikationsweg einzurichten, der das ausgefallene Netz umgeht. Insbesondere leitet der Netz-Host Übertragungen von einer der Netzschnittstellen (die mit dem ausgefallenen Netz verbunden ist) durch die andere Netzschnittstelle (die mit dem betriebsfähigen Netz verbunden ist).
In einigen offenbarten Beispielen benötigt die Detektion eines Netzausfalls und die Einrichtung eines alternativen Kommunikationswegs weniger als fünf Sekunden. In einigen Beispielen sind kürzere Zeiten möglich (z.B. 500 Millisekunden oder weniger). Somit stellen die vorliegend offenbarten Beispiele Rückgewinnungszeiten innerhalb der Anforderungen bereit, die für Prozesssteuerungssystemumgebungen benötigt werden, um sicherzustellen, dass den Bedienern und Nutzern verlässliche und aktualisierte Daten verfügbar sind. Die Zeit, die benötigt wird, um einen Netzausfall zu detektieren und einen alternativen Kommunikationsweg einzurichten, ist darüber hinaus geringer als die Dauer der Verbindungsunterbrechung für Datenübertragungen. Das heißt, es wird einen alternativer Leitweg eingerichtet, ehe der Netz-Host aufhört, zu versuchen, die Daten erneut zu übertragen. Somit werden keine Daten verloren und diese werden höchstens um einige Sekunden verzögert.
Die wie vorliegend beschriebene Detektion von Netzausfällen im Wesentlichen in Echtzeit zur Ermöglichung schneller Rückgewinnung von solchen Ausfällen wird durch das fortdauernde Überwachen der Konnektivität zwischen Netz-Hosts über jeweils zwei Netze erreicht, die die Hosts verbinden. In einigen Beispielen bereitet jeder Netz-Host Integritätsnachrichten vor, die häufig über die Netze an jeden der anderen Netz-Hosts übertragen werden. In einigen Beispielen unterscheiden sich die Integritätsnachrichten von typischen Datenübertragungen zwischen den dem normalen Betrieb des Prozesssteuerungssystems zugeordneten Hosts. In einigen Beispielen werden die Integritätsnachrichten über das entsprechende Netz übertragen. In anderen Beispielen werden die Integritätsnachrichten nur zu denjenigen Netz-Hosts im Wege der Multicast-Übertragung gesendet, die zum Empfang der Nachrichten konfiguriert sind. In einigen Beispielen alterniert die Übertragung jeder aufeinander folgenden Integritätsnachricht von jedem Netz-Host zwischen jeder Netzschnittstelle. In einigen Beispielen wird eine Integritätsnachricht von jeder der Netzschnittstellen jedes der verbundenen Hosts übertragen, ehe eine nachfolgende Integritätsnachricht von einer der Netzschnittstellen gesendet wird. Das heißt, einige Beispiele durchlaufen jede Netzschnittstelle jedes Netz-Hosts, ehe sie zum ersten Netz-Host zurückkehren, um den Prozess zu wiederholen. In einigen Beispielen findet das Durchlaufen jeder der Netzschnittstellen jedes Netz-Hosts in einem Bruchteil einer Sekunde statt. Auf diese Weise überträgt jeder Netz-Host eine Integritätsnachricht an jeden anderen Netz-Host über jede Netzschnittstelle auf einer häufigen Basis. Infolgedessen können die Verbindungen zwischen jedem Netz-Host über jede Netzschnittstelle konstant überwacht werden, um einen Ausfall zwischen zwei beliebigen Netz-Hosts schnell zu detektieren. Jede Integritätsnachricht dient dazu, die Konnektivität des übertragenden
Hosts mit jedem der anderen Hosts über das entsprechende Netz zu testen. Wenn jeder der anderen Netz-Hosts eine Integritätsnachricht von einem übertragenden Host über ein bestimmtes Netz empfängt, dann kann jeder der Netz-Hosts bestätigen, dass der Kommunikationsstatus zwischen ihm und dem übertragenden Host über dieses Netz gut ist. Auf der anderen Seite ist die Abwesenheit einer Integritätsnachricht eine Indikation für einen Netzfehler, wenn einer oder mehrere der Netz-Hosts eine von einem bestimmten Host übertragene Integritätsnachricht nicht erhält/erhalten. Die Netz-Hosts, die eine erwartete Integritätsnachricht nicht erhalten, können somit bestätigen, dass der Verbindungsstatus zwischen ihnen selbst und dem Host, von welchem die Nachricht erwartet wurde, schlecht ist.
In einigen Beispielen werden die Integritätsnachrichten periodisch zu einem bekannten Zeitintervall übertragen, sodass ein Netzausfall angenommen werden kann, wenn keine Nachricht von einer bestimmten Netzschnittstelle eines bestimmten Netz-Hosts über einen Zeitraum empfangen wird, der länger als das bekannte Zeitintervall ist. In einigen Beispielen wird ein Netzausfall basierend auf der Abwesenheit einer Integritätsnachricht detektiert, die über einen Schwellenwertzeitraum empfangen wird, der das Dreifache des Zeitintervalls zwischen jeder aufeinanderfolgenden Integritätsnachricht ist, die von derselben Netzschnittstelle desselben Netz-Hosts gesendet wird. In einigen Beispielen kann der Schwellenwertzeitraum länger oder kürzer als das Dreifache des Zeitintervalls sein.
Die periodischen Integritätsnachrichten, die von jedem Host an jeden anderen Host über jedes Netz übertragen werden, dienen als Prüfung oder Test der Verbindung zwischen jedem Netz-Host über jedes Netz. Wenn ein Netz-Host eine Integritätsnachricht empfängt, wird der Verbindungs- oder Kommunikationsstatus zwischen diesem Host und dem Netz-Host, der die Nachricht gesendet hat, als gut bestätigt. Wenn ein Netz-Host eine Integritätsnachricht (nach einem Schwellenwertzeitraum) nicht empfängt, wird der Verbindungsstatus zwischen diesem Host und dem Netz-Host, von welchem eine Nachricht erwartet wurde, als schlecht eingestuft. In einigen Beispielen wird somit der Verbindungs- oder Kommunikationsstatus zwischen jedem Host basierend darauf bestimmt, ob Nachrichten unabhängig von dem in den Nachrichten enthaltenen Inhalt empfangen werden. In einigen Beispielen beinhaltet der Inhalt der Integritätsnachrichten jedoch Integritätsinformationen, um weitere Informationen für jeden der Netz-Hosts bereitzustellen, um die Verbindungsstatus zwischen den unterschiedlichen Hosts über die unterschiedlichen Netze zu bestätigen.
In einigen Beispielen beinhalten die Integritätsnachrichten Host-Informationen, die den Netz-Host identifizieren, von welchem die Integritätsnachricht gesendet wurde. In einigen Beispielen beinhalten die Host-Informationen die IP-Adresse beider Netzschnittstellen des Netz-Hosts, der die Nachricht sendet. Auf diese Weise hat jeder Netz-Host die erforderlichen IP-Informationen, um alternative Kommunikationswege zu erzeugen, wenn ein Netzausfall detektiert wird. In einigen Beispielen werden die Host-Informationen durch jeden Netz-Host zur Auffindung der anderen in dem Netz befindlichen Hosts verwendet.
In einigen Beispielen beinhalten die Integritätsnachrichten zusätzlich Integritätsinformationen, die den Verbindungs- oder Kommunikationsstatus zwischen dem Netz-Host, der die Nachricht überträgt, und jedem der anderen Hosts für beide Netzschnittstellen anzeigt. In einigen Beispielen kann jeder der Netz-Hosts durch Erzeugen dieser Informationen und Empfangen der jedem der anderen Netz-Hosts (wenn diese ihre Integritätsnachrichten übertragen) zugeordneten Kommunikationsstatus eine Integritätstabelle erzeugen, die die Kommunikationsstatus zwischen ihm selbst und jedem anderen Host repräsentiert. In einigen Beispielen ist man auf solche Informationen angewiesen, um einen alternativen Kommunikationsweg zu definieren, wenn eine direkte Verbindung aufgrund eines Netzfehlers ausgefallen ist. In einigen Beispielen werden die in jeder Integritätsnachricht beinhalteten Integritätsinformationen basierend darauf, ob und wann die Integritätsnachrichten von den anderen Hosts empfangen wurden, als eine redundante Prüfung des durch jeden Host bestimmten Kommunikationsstatus verwendet.
Obwohl die häufige Übertragung von Integritätsnachrichten den Netzen eine zusätzliche Last auferlegt, bleibt der gesamte Netzverkehr erheblich unter dem Netzverkehr, der beim Implementieren eines Systems einbezogen ist, das PRP (Parallel-Redundanzprotokoll) verwendet. Wenn beispielsweise ein Netz 10 Hosts beinhaltet, die jede Sekunde jeweils 1000 einem Prozesssteuerungssystem zugeordnete Datenpakete empfangen, verdoppelt sich die an jeden Host übertragene Datenmenge bei Verwenden von PRP auf 2000 Datenpakete pro Sekunde. Im Gegensatz dazu würde, wenn jeder der 10 Hosts jede Sekunde 2 Integritätsnachrichtenpakete gemäß den vorliegend offenbarten Lehren überträgt, die Gesamtmenge an Daten, die an jeden Host übertragen werden würde, 1020 Datenpakete pro Sekunde betragen (1000 Prozesssteuerungsdatenpakete plus die 2 × 10 = 20 Integritätsnachrichtendatenpakete). Die 1020 Datenpakete, die in den offenbarten Beispielen übertragen werden, sind eindeutig wesentlich weniger, als die erforderlichen 2000 Datenpakete, die PRP verwenden. Die Netzlast, die durch die Integritätsnachrichten erzeugt wird, ist eine Funktion der Anzahl von Netz-Hosts und der Frequenz von Integritätsnachrichten, ist jedoch unabhängig von der Menge an über das Netz übertragenen Prozesssteuerungsdaten. Wenn somit jeder Netz-Host in dem obigen Beispiel 5000 Pakete von Prozesssteuerungsdaten pro Sekunde empfangen würde, bliebe die Menge an Integritätspaketen bei 20 Paketen pro Sekunde. Wenn die Integritätsnachrichten jedoch häufiger gesendet werden (z.B. 5 Nachrichten pro Sekunde), um schnellere Detektion von Netzausfällen zu ermöglichen, würde sich die Last aufgrund der Integritätsnachrichten proportional erhöhen (z.B. bis zu 5 × 10 = 50 Datenpakete pro Sekunde) jedoch dennoch einen Gesamtbetrag weit unter der durch PRP auferlegten Last (z.B. 1050 Pakete pro Sekunde im Vergleich zu 2000 Paketen pro Sekunde) zur Folge haben. Wenn die Anzahl von Hosts gleichermaßen erhöht wird (z.B. bis zu 50) jedoch die Häufigkeit von Integritätsnachrichten bei 2 Datenpaketen pro Sekunde gehalten wird, ist die Gesamtmenge an Integritätsdaten, die jede Sekunde an jedem Netz-Host empfangen wird, 2 × 50 = 100 Pakete pro Sekunde (was insgesamt 1100 Datenpakete pro Sekunde beträgt). Obwohl zusätzliche Hosts und/oder häufigere Integritätsnachrichten den Netzen somit zusätzliche Belastung auferlegen, bleibt der Belastungspegel weit unterhalb der Verdoppelung der Menge an Netzverkehr, die erforderlich ist, wenn PRP implementiert wird.
Die vorliegend beschriebenen Lehren sind darüber hinaus Software-basiert, sodass kein Bedürfnis besteht, besondere oder zusätzliche Hardware (z.B. Netzschalter, die Redundanz bereitstellen können) zu erwerben, konfigurieren, auf diese angewiesen zu sein und/oder diese zu pflegen. Die vorliegend offenbarten Beispiele können somit betriebsbereit für jedes geeignete Netz verwendet werden, wobei die Komplexität der Konfiguration und des Aufbaus reduziert wird.
In einigen Beispielen im Kontext der Prozesssteuerungssysteme sind die Redundanzsoftware und die zugeordneten Konfigurationswerkzeuge zur Implementierung der vorliegend offenbarten Lehren in der Virtualisierungssoftware (z.B. DeltaV Virtual Studio^TM) enthalten, um automatisch in virtuelle Maschinen, die die Software erzeugen, einbezogen zu werden. In einigen Beispielen kann das Konfigurationswerkzeug nach dem Zuweisen der IP-Adressen an die Netzschnittstellenkarten (NIC) auf der virtuellen Maschine ausgeführt werden, um Redundanz über zwei beliebige Netze aufzubauen. In einigen Beispielen kann die Virtualisierungssoftware zusätzlich oder alternativ eine Diskette an eine virtuelle Maschine anschließen, die die erforderlichen Dateien und ein Skript enthält, das den Redundanzservice automatisch erzeugt, die Dateien auf die virtuelle Maschine kopiert, das Konfigurationswerkzeug startet und die Diskette auswirft. Die Diskette ermöglicht die Erzeugung solcher Redundanz-Schemata auf virtuellen Maschinen, die mit früheren Versionen der Virtualisierungssoftware erzeugt wurden.
In einigen Beispielen sind sowohl die Netz-Redundanzsoftware als auch das Konfigurationswerkzeug in einem entfernten Desktop-Verbindungsinstallationsprogramm (z.B. DeltaV Remote Desktop Connection) beinhaltet. In solchen Beispielen kann das entfernte Desktop-Verbindungsinstallationsprogramm, wenn es detektiert, dass bereits zwei Netze eingerichtet wurden, automatisch die Redundanz für diese Netze konfigurieren. Ansonsten kann das Konfigurationswerkzeug manuell ausgeführt werden, nachdem jedem Netz-Host die IP-Adressen zugewiesen wurden.
Die vorliegend offenbarten Beispiele können in ein Ausfallsicherheitsüberwachungssystem einbezogen werden, das Nutzer bezüglich Szenarios alarmiert, die die Verfügbarkeit eines Systems kompromittieren können. Wenn beispielsweise einer der redundanten Netzwege unverfügbar oder funktionsunfähig geworden ist (unabhängig davon, ob dies im aktiven oder Standby-Modus passiert), kann eine Warnung oder ein Alarm erzeugt werden, um einen Endnutzer (z.B. einen Bediener oder Wartungstechniker) bezüglich des Ausfalls zu warnen und eine Möglichkeit bereitzustellen, das Problem in Angriff zu nehmen. In einigen Beispielen kann das Eintreten von Netzausfällen zusätzlich in einem Datenhistorian aufgezeichnet werden. In einigen solchen Beispielen beinhaltet das Protokoll den Zeitpunkt des Ausfalls sowie eine Identifikation der betroffenen Netz-Hosts.
Unter ausführlicher Bezugnahme auf die Zeichnungen ist 1 eine schematische Darstellung eines beispielhaften Prozesssteuerungssystems oder verteilten Steuerungssystems (DCS) 100, innerhalb welcher die Lehren dieser Offenbarung implementiert sein können. Im Sinne der vorliegenden Verwendung wird der Ausdruck „Prozesssteuerungssystem“ austauschbar mit dem Ausdruck „verteiltes Steuerungssystem“ verwendet. Das beispielhafte DCS 100 von 1 beinhaltet Prozessregler 102, die kommunikativ mit einer Vielzahl von intelligenten und/oder nicht intelligenten Feldgeräten 104 gekoppelt sind, die jedes erwünschte Kommunikationsmedium (z.B. drahtlos, festverdrahtet etc.) und jede erwünschten Protokolle (z.B. Foundation Fieldbus, Profibus, HART etc.) verwenden. Der beispielhafte Regler 102 von 1 kann zum Beispiel ein DeltaV^TM-Regler sein, der durch Fisher-Rosemount Systems, Inc., einem Emerson Process Management Unternehmen, verkauft wird. Obwohl die vorliegend offenbarten Lehren im Zusammenhang mit DeltaV^TM-Hardware, -Software und/oder -Firmware beschrieben werden, können die Lehren für andere Hardware (z.B. andere Regler), Firmware und/oder Software angepasst werden, die durch andere Institutionen hergestellt und/oder entwickelt wird. Obwohl zwei Regler 102 in 1 gezeigt sind, könnten weiterhin zusätzliche und/oder weniger Regler und/oder Prozesssteuerungsplattformen jedes gewünschten Typs und/oder jeder gewünschten Kombination von Typen in dem beispielhaften DCS 100 implementiert werden.
Typischerweise werden Regler in einem Prozesssteuerungssystem kommunikativ mit einem oder mehreren Bedienerplätzen, Applikationsplätzen und/oder anderen Arbeitsplätzen (vorliegend zusammenfassend als Arbeitsplätze bezeichnet) gekoppelt, die einem oder mehreren Computern zugeordnet sein können. In dem veranschaulichten Beispiel sind jedoch die Regler 102 kommunikativ an eine beispielhafte Prozesssteuerungsumgebung 106 gekoppelt. Die beispielhafte virtuelle Prozesssteuerungsumgebung 106 von 1 beinhaltet einen beispielhaften Domänenregler 108, einen beispielhaften ersten Host-Server 110, einen beispielhaften zweiten Host-Server 112, einen beispielhaften dritten Host-Server 114 und ein beispielhaftes Speicherbereichsnetz (SAN) 116. In dem veranschaulichten Beispiel implementiert die virtuelle Prozesssteuerungsumgebung 106 virtuelle Maschinen, die einer Vielzahl von in einer Tabelle 118 aufgelisteten Arbeitsplätzen 117 entsprechen.
Wie in der Tabelle 118 repräsentiert, beinhalten die für das DCS (100) implementierten virtuellen Arbeitsplätze 117 acht virtuelle Bedienerplätze 120, vier virtuelle Applikationsplätze 122 und einen virtuellen primären Steuerungssystem-Applikationsplatz 124 (z.B. einen DeltaV^TM ProPlus-Arbeitsplatz). In dem veranschaulichten Beispiel implementiert der erste Host-Server 110 insbesondere drei der virtuellen Bedienerplätze 120 und zwei der virtuellen Applikationsplätze 122, der Host-Server 112 implementiert drei andere eine von den virtuellen Bedienerplätzen 120 und einen der virtuellen Applikationsplätze 122 und der dritte Host-Server 114 implementiert die verbleibenden zwei der virtuellen Bedienerplätze 120, den letzten virtuellen Applikationsplatz 122 und den virtuellen primären Steuerungssystem-Applikationsplatz 124. Obwohl eine beispielhafte Unterteilung der beispielhaften virtuellen Arbeitsplätze 117 in der Tabelle 118 gezeigt ist, können die beispielhaften virtuellen Arbeitsplätze 117 an jeden einen der Host-Server 110, 112, 114 in jeder Kombination nach Maßgabe der Anforderungen jeder der Host-Server 110, 112, 114 zugewiesen werden. In einigen Beispielen können zusätzlich oder alternativ doppelte Kopien von einem oder mehreren der virtuellen Arbeitsplätze 117 an getrennten einen der Host-Server 110, 112, 114 implementiert werden.
In dem veranschaulichten Beispiel sind die Host-Server 110, 112, 114 und das SAN 116 kommunikativ miteinander verbunden, um ein Netz zu bilden, das gemeinhin als ein Cluster bezeichnet wird. Der Domänenregler 108 ist in Kommunikation mit dem Cluster und handhabt dieses und steuert den Zugriff auf die innerhalb des Clusters gespeicherten Informationen. In dem veranschaulichten Beispiel dient das SAN 116 als ein gemeinsamer oder geteilter Speicher (z.B. ein clustergeteiltes Volumen), mit welchem jeder der Host-Server 110, 112, 114 Lese-/Schreibvorgänge an derselben Logikeinheit des Speichers (z.B. derselben Logikeinheitsnummer) durchführen kann. Auf diese Weise werden die der Implementierung der virtuellen Arbeitsplätze 117 zugeordneten Daten getrennt von der nativen Festplatte innerhalb jedes Host-Servers 110, 112, 114 gespeichert, um hohe Verfügbarkeit für das System bereitzustellen. Wenn beispielsweise einer der Host-Server 110, 112, 114 ausfällt, können die virtuellen Arbeitsplätze 117, die durch diesen Host-Server implementiert werden, an einem der anderen Host-Server 110, 112, 114 gestartet werden. In einigen Beispielen ist das SAN 116 nicht beinhaltet, sodass jeder Host-Server 110, 112, 114 auf seine örtliche Festplatte angewiesen ist.
In dem veranschaulichten Beispiel von 1 ist jeder der Host-Server 110, 112, 114 (und das zugeordnete SAN 116) der virtuellen Prozesssteuerungsumgebung 106 kommunikativ mit den Reglern 102 über einen Bus und/oder ein lokales Netz (LAN – local area net) 128 gekoppelt, welches gemeinhin als ein Applikationssteuerungsnetz (ACN – application control net) bezeichnet wird. Das beispielhafte LAN 128 von 1 kann unter Verwenden jedes erwünschten Kommunikationsmediums und -protokolls implementiert werden. Das beispielhafte LAN 128 kann zum Beispiel auf einem festverdrahteten und/oder einem drahtlosen Ethernet-Kommunikationsschema basiert sein. Jede/s andere/n geeignete/n Kommunikationsmedium/-medien und/oder Protokoll/e könnte/n jedoch verwendet werden. Obwohl ein einzelnes LAN 128 in 1 veranschaulicht ist, kann/können mehr als ein LAN und/oder andere alternative Teile von Kommunikationshardware verwendet werden, um redundante Kommunikationswege zwischen den beispielhaften Komponenten von 1 bereitzustellen.
In einigen Beispielen ist die virtuelle Prozesssteuerungsumgebung 106 (z.B. der Domänenregler 108, die Host-Server 110, 112, 114 und das SAN 116) kommunikativ an Thin Clients 126 gekoppelt, die auf die virtuellen Arbeitsplätze 117 entfernt Zugriff nehmen können, die innerhalb der virtuellen Prozesssteuerungsumgebung 106 implementiert sind, um es Bedienern, Technikern und/oder anderem Anlagenpersonal zu ermöglichen, auf dieselbe Weise mit den Arbeitsplätzen über eine Benutzerschnittstelle zu interagieren, die auf einer Anzeige der Thin Clients 126 wiedergegeben werden, als ob die virtuellen Arbeitsplätze 117 in einem physischen Computersystem und/oder einer anderen der Anzeige zugeordneten Prozessorplattform implementiert wären.
Obwohl 1 ein beispielhaftes DCS 100 veranschaulicht, innerhalb welchem die vorliegend offenbarten Lehren vorteilhafterweise eingesetzt werden können, können die vorliegend offenbarten Lehren, falls erwünscht, in anderen Prozessanlagen und/oder Prozesssteuerungssystemen von höherer oder geringerer Komplexität (z.B. mit mehr als einer virtuellen Prozesssteuerungsumgebung 106, mit mehr Arbeitsplätzen (physische und/oder virtuelle), über mehr als einen geografischen Standort etc.) vorteilhafterweise eingesetzt werden, als in dem veranschaulichten Beispiel von 1. Die vorliegend offenbarten Lehren können weiterhin in gänzlich physischen Prozesssteuerungssystemen (z.B. Systeme, die keine virtuelle Prozesssteuerungsumgebung 106 aufweisen) eingesetzt werden.
2 ist eine schematische Darstellung einer beispielhaften Netzanordnung 200 von einem Teil des beispielhaften DCS 100 von 1. In dem veranschaulichten Beispiel von 2 sind drei der Thin Clients 126 als kommunikativ mit drei der Arbeitsplätze 117 gekoppelt gezeigt. In dem veranschaulichten Beispiel sind die Arbeitsplätze 117 als virtuelle Maschinen innerhalb der virtuellen Prozesssteuerungsumgebung 106 implementiert, wohingegen die Thin Clients 126 physische Rechnergeräte sind. Wie in 2 gezeigt, ist jeder von den Thin Clients 126 und jeder von den Arbeitsplätzen 117 mit einem primären Netz 202 und einem getrennten sekundären Netz 204 verbunden. Das heißt, jeder von den Thin Clients 126 und den Arbeitsplätzen 117 ist multi-homed mit denselben gemeinsamen Netzen 202, 204. In einigen Beispielen beinhaltet insbesondere jeder der Thin Clients 126 und der Arbeitsplätze 117 eine erste Netzschnittstelle 206 (z.B. einen Netzschnittstellenregler (NIC – network interface controller)), der mit dem primären Netz 202 verbunden ist. In einigen Beispielen beinhaltet weiterhin jeder von den Thin Clients 126 und den Arbeitsplätzen 117 eine zweite Netzschnittstelle 208, die mit dem sekundären Netz 202 verbunden ist. Im Sinne der vorliegenden Verwendung werden die Begriffe „primär“ und „sekundär“ verwendet, um zwischen den Netzen (z.B. den Netzen 202, 204) zu unterscheiden, die unterschiedlichen Netz-Hosts gemein sind und bezwecken nicht, nahe zu legen, dass ein Netz notwendigerweise zuerst verwendet wird, standardmäßig verwendet wird, häufiger verwendet wird oder wichtiger ist.
Aus Gründen der Erklärung werden die Thin Clients 126 und die Arbeitsplätze 117 vorliegend im Allgemeinen als Netz-Hosts 210 bezeichnet, indem sie alle mit denselben Netzen 202, 204 verbunden sind. In einigen Beispielen können andere Typen von Netz-Hosts 210 zusätzlich oder anstatt der in 2 gezeigten Thin Clients 126 und der Arbeitsplätze 117 (z.B. Thick Clients, unabhängige physische Arbeitsplätze, eingebettete Regler etc.) vorliegen. Die Netz-Hosts 210 sind von den oben beschriebenen Host-Servern 110, 112, 114 distinkt, die verwendet werden, um die virtuelle Prozesssteuerungsumgebung 106 zu bilden. Die Host-Server 110, 112, 114 können jedoch virtuelle Maschinen (z.B. die Arbeitsplätze 117) und/oder andere virtuelle Geräte implementieren, die als Netz-Host, wie oben gemäß den vorliegend offenbarten Lehren definiert, betrachtet werden können.
3 ist eine beispielhafte Implementierung eines beispielhaften Netz-Hosts 210, der gemäß den vorliegend offenbarten Lehren konstruiert wurde. In dem veranschaulichten Beispiel von 3 beinhaltet der Netz-Host 210 eine beispielhafte erste Netzschnittstelle 302, eine beispielhafte zweite Netzschnittstelle 304, einen beispielhaften Integritätsnachrichtenanalysator 306, einen beispielhaften Integritätstabellengenerator 308, einen beispielhaften Integritätsnachrichtengenerator 310, einen beispielhaften Kommunikationswegbestimmer 312, einen beispielhaften Kommunikationsmanager 314 und einen beispielhaften Alarmmanager 316.
Der beispielhafte Netz-Host 210 kann verwendet werden, um jeden der Thin Clients 126 oder der Arbeitsplätze 117 des beispielhaften DCS 100 von 1 und/oder 2 zu implementieren. Aus Gründen der Erklärung wird jedoch der Netz-Host 210 in Verbindung mit einem vereinfachten System 400 von Netz-Hosts 402, 404, 406 beschrieben, das in 4 beschrieben ist. Jeder der Hosts 402, 404, 406 kann durch Verwenden des beispielhaften Netz-Hosts 210 von 3 implementiert werden. Wie in dem veranschaulichten Beispiel von 4 gezeigt, ist jeder der Hosts 402, 404, 406 ein multi-homed Netz-Host, der mit einem primären Netz 408 und einem sekundären Netz 410 verbunden ist. Wie in dem veranschaulichten Beispiel weiterhin gezeigt, sind das primäre Netz 408 und das sekundäre Netz 410 jedem der drei Netz-Hosts 402, 404, 406 gemein. Jeder der Netz-Hosts 402, 404, 406 beinhaltet insbesondere eine erste Netzschnittstelle 302, durch welche sich jeder Netz-Host 402, 404, 406 mit dem primären Netz 408 verbindet. In dem veranschaulichten Beispiel beinhaltet weiterhin jeder der Netz-Hosts 402, 404, 406 eine zweite Netzschnittstelle 304, durch welche sich jeder Netz-Host 402, 404, 406 mit dem sekundären Netz 408 verbindet. Infolgedessen können alle der Netz-Hosts 402, 404, 406 direkt miteinander über ihre entsprechenden ersten Netzschnittstellen 302 über das primäre Netz 408 kommunizieren und/oder direkt über ihre entsprechenden zweiten Netzschnittstellen 304 über das sekundäre Netz 410 kommunizieren. In einigen Beispielen können ein oder mehrere Schalter an jedem der Netze 408, 410 zwischen den Hosts 402, 404, 406 vorliegen. Aus Gründen dieser Offenbarung gelten jedoch die Netz-Hosts 402, 404, 406 als „direkt“ kommunizierend, wenn entsprechende Netzschnittstellen 302, 304 über das Netz, mit dem sie verbunden sind, kommunizieren, unabhängig davon, ob die Übertragung beliebige Schalter durchläuft.
Nochmals in Bezug zu 3 wird der beispielhafte Netz-Host 210 (entsprechend jedem der Netz-Hosts 402, 404, 406 von 4) mit der ersten Netzschnittstelle 302 zur Verbindung mit dem primären Netz 408 bereitgestellt, wodurch Kommunikation mit anderen Netz-Hosts (z.B. den Netz-Hosts 402, 404, 406) an dem primären Netz 408 ermöglicht wird. Der beispielhafte Netz-Host 210 wird mit der zweiten Netzschnittstelle 304 zur Verbindung mit dem sekundären Netz 410 bereitgestellt, wodurch Kommunikation mit anderen Netz-Hosts (z.B. den Netz-Hosts 402, 404, 406) an dem sekundären Netz 410 ermöglicht wird. In einigen Beispielen werden die ersten und zweiten Netzschnittstellen 302, 304 über physische Netzschnittstellenkarten (NIC – network interface card) (z.B. in den physischen Thin Clients 126 von 1 und/oder 2) implementiert. In anderen Beispielen werden die ersten und zweiten Netzschnittstellen 302, 304 als virtuelle Komponenten von einer virtuellen Maschine (z.B. in den virtuellen Arbeitsplätzen 117 von 1 und/oder 2) implementiert. In einigen Beispielen wird Internet Protokoll(IP)-Routing zwischen den ersten und zweiten Netzschnittstellen 302, 304 aktiviert, unabhängig davon, ob die ersten und zweiten Netzschnittstellen 302, 304 physisch oder virtuell implementiert sind. Auf diese Weise können die an die erste Netzschnittstelle 302 gelieferten Kommunikationen mit einem für die zweite Netzschnittstelle 304 bezweckten Endziel an die zweite Netzschnittstelle 304 weitergeben werden. In solchen Beispielen wird die erste Netzschnittstelle 302 als ein Router oder Gateway mit Bezug zu der zweiten Netzschnittstelle 304 definiert, um Daten weiterzuleiten, die für die zweite Netzschnittstelle 304 bestimmt sind. In dem veranschaulichten Beispiel können Kommunikationen, die an die zweite Netzschnittstelle 304 mit einem für die erste Netzschnittstelle 302 bezweckten Endziel übermittelt werden, gleichermaßen an die erste Netzschnittstelle 302 über die zweite Netzschnittstelle 304 weitergegeben werden.
In dem veranschaulichten Beispiel von 3 wird der Netz-Host 210 mit dem Integritätsnachrichtenanalysator 306 zur Analyse der von anderen Netz-Hosts empfangenen Integritätsnachrichten bereitgestellt, um einen Verbindungs- oder Kommunikationsstatus zwischen dem Netz-Host 210 und dem anderen Netz-Host zu bestimmen, der die Integritätsnachricht überträgt. Im Sinne der vorliegenden Verwendung bezieht sich ein Kommunikationsstatus auf eine Indikation, ob direkte Kommunikationen zwischen entsprechenden Netzschnittstellen 302, 304 von zwei bestimmten Netz-Hosts 402, 404, 406 über das entsprechende Netz 408, 410 stattfinden können. Wenn direkte Kommunikation zwischen zwei entsprechenden Netzschnittstellen von zwei Netz-Hosts möglich ist, ist der Kommunikationsstatus „gut“. Wenn ein Netzausfall auftritt, sodass solche Daten nicht direkt zwischen den zwei Netzschnittstellen über das entsprechende Netz übertragen werden können, ist der Kommunikationsstatus „schlecht“. Die besondere Natur des Netzausfalls ist für die vorliegend offenbarten Lehren nicht relevant. Unabhängig davon, ob somit ein Kabel abgezogen, defekt (z.B. durchgeschnitten) ist oder ob eine der Netzschnittstellen 302, 304 intern ausgefallen ist und/oder ein anderer Umstand die Kommunikationen zwischen entsprechenden Schnittstellen verhindert, wird ein schlechter Kommunikationsstatus zwischen den betroffenen Schnittstellen festgelegt.
Während jeder Netz-Host 402, 404, 406 die Integritätsnachrichten, die periodisch von den ersten Netzschnittstellen 302 (über das primäre Netz 408) übertragen werden, von jedem der anderen Netz-Hosts empfängt, bestätigt der Integritätsnachrichtenanalysator 306, dass der Kommunikationsstatus über das primäre Netz 408 zwischen dem empfangenden Netz-Host und dem übertragenden Netz-Host gut ist, weil eine Integritätsnachricht erfolgreich empfangen wurde. Während jeder der Netz-Hosts 402, 404, 406 die Integritätsnachrichten, die periodisch von den zweiten Netzschnittstellen 304 (über das sekundäre Netz 410) übertragen wurden, von jedem der anderen Netz-Hosts empfängt, bestätigt der Integritätsnachrichtenanalysator 306 gleichermaßen, dass der Kommunikationsstatus über das primäre Netz 408 zwischen dem empfangenden Netz-Host und dem übertragenden Netz-Host gut ist. Das heißt, in einigen Beispielen dient der Empfang der Nachricht als die Grundlage für die Bestätigung, dass der Kommunikationsstatus gut ist. In einigen Beispielen ist der bestimmte Inhalt jeder Integritätsnachricht somit für die Bestimmung der Verbindung oder des Kommunikationsstatus irrelevant. In einigen Beispielen kann der Inhalt der Integritätsnachricht jedoch eine zweite Ebene der Bestätigung für den Kommunikationsstatus bereitstellen und/oder zusätzliche Einzelheiten bereitstellen, die bei dem Implementieren der vorliegend offenbarten Lehren nützlich sind.
Wenn dagegen ein Netzausfall vorliegt, wie zum Beispiel der Ausfall einer der Netzschnittstellen 302, 304 von einem der Netz-Hosts 402, 404, 406, wird eine Integritätsnachricht, die der Netz-Host mit der ausgefallen Schnittstelle versucht über die ausgefallene Netzschnittstelle zu übertragen, nicht übermittelt. Wenn eine erwartete Integritätsnachricht nicht empfangen wird (z.B. aufgrund eines Netzausfall), bestimmt in einigen Beispielen der Integritätsnachrichtenanalysator 306, dass ein Netzausfall vorliegt und dass somit der Kommunikationsstatus zwischen entsprechenden Netzschnittstellen schlecht ist. In einigen Beispielen werden die Integritätsnachrichten insbesondere über jedes von den primären und sekundären Netzen 408, 410 über die entsprechenden ersten und zweiten Netzschnittstellen 302, 304 periodisch übertragen. In einigen Beispielen wird jede Integritätsnachricht, die von einer bestimmten Netzschnittstelle von einem bestimmten Netz-Host gesendet wird, mit einem bestimmten Zeitintervall ab der vorherigen Integritätsnachricht, die von derselben Netzschnittstelle von demselben Netz-Host gesendet wird, übertragen. Wenn somit das Zeitintervall, das nach Empfangen einer Integritätsnachricht (was angibt, dass der Kommunikationsstatus gut ist) beginnt, überschritten wird, ohne dass eine neue Integritätsnachricht empfangen wird, kann der Integritätsnachrichtenanalysator 306 des empfangenen Netzhosts bestimmen, dass die erwartete Übertragung ausfiel. Das Nichtvorhandensein einer erwarteten Integritätsnachricht gibt in solchen Beispielen einen ausgefallenen oder schlechten Kommunikationsstatus mit Bezug zu der bestimmten Netzschnittstelle des übertragenden Netz-Hosts an. In einigen Situationen können andere Faktoren als ein Netzausfall eine Rolle dabei spielen, ob eine bestimmte Integritätsnachricht innerhalb des konfigurierten Zeitintervalls für aufeinanderfolgende Nachrichten kommuniziert wird. In einigen Beispielen kann der Integritätsnachrichtenanalysator 306 demzufolge nur nach einem Schwellenwertzeitraum, der größer als das erwartete Zeitintervall zwischen aufeinanderfolgenden Nachrichten von derselben Netzschnittstelle von demselben Netz-Host ist, wie zu Beispiel das Dreifache des Zeitintervalls, bestimmen, dass ein Kommunikationsstatus zwischen entsprechenden Netzschnittstellen von zwei unterschiedlichen Netz-Hosts schlecht ist. In anderen Beispielen kann das Zeitintervall der erwarteten Dauer von drei Integritätsnachrichten, die von einem bestimmten Netz-Host zu empfangen sind, unabhängig von der Netzschnittstelle, von welcher die Nachricht gesendet wurde, entsprechen. Jeder Host kann zum Beispiel zwei Integritätsnachrichten (eine über jede Netzschnittstelle) während jedem Zeitintervall senden, das alle Netzschnittstellen von allen der Netz-Hosts durchläuft, an die nicht übermittelt wird, sodass die nächste ausgefallene Übertragung (unabhängig von der Netzschnittstelle) ausreicht, um einen schlechten Kommunikationsstatus anzugeben. In einigen Beispielen analysiert der Integritätsnachrichtenanalysator 306 den Inhalt der von anderen Netz-Hosts 402, 404, 406 empfangenen Integritätsnachrichten, um seine eigenen Integritätsinformationen, wie nachstehend ausführlicher beschrieben, zu bestimmen und/oder zu aktualisieren.
In dem veranschaulichten Beispiel von 3 wird der Netz-Host 210 mit dem Integritätstabellengenerator 308 zur Erzeugung einer Integritätstabelle oder anderen Datenstruktur bereitgestellt, die Integritätsinformationen speichern, die den Verbindungs- oder Kommunikationsstatus zwischen jedem Netz-Host (z.B. den Netz-Hosts 402, 404, 406) über jedes der primären und sekundären Netze 408, 410 (z.B. über jede der ersten und zweiten Netzschnittstellen 302, 304) angeben.
In den veranschaulichten Beispielen wird jeder Netzschnittstelle 302, 304 jedes Netz-Hosts mit Bezug zu jeder anderen Netzschnittstelle 302, 304, die mit demselben Netz verbunden ist, ein getrennter Kommunikationsstatus zugeordnet. In dem veranschaulichten Beispiel von 4 weist somit die erste Netzschnittstelle 302 des ersten Netz-Hosts 402 (Host A) einen getrennten Kommunikationsstatus für jede der ersten Netzschnittstellen 302 des zweiten Netz-Hosts 404 (Host B) und des dritten Netz-Hosts 406 (Host C) auf, weil jede der Netzschnittstellen 302 der Netz-Hosts 402, 404, 406 mit demselben primären Netz 408 verbunden ist. In dem veranschaulichten Beispiel wird jedoch kein Kommunikationsstatus zwischen der ersten Netzschnittstelle 302 des ersten Netz-Hosts 402 und jeder der zweiten Netzschnittstellen 304 der zweiten und dritten Netz-Hosts 404, 406 definiert, weil die erste Netzschnittstelle 302 des ersten Netz-Hosts 402 und die zweite Netzschnittstelle 304 der anderen Netz-Hosts 404, 406 mit unterschiedlichen Netzen verbunden sind und damit nie direkt kommunizieren.
In einigen Beispielen wird die Integritätstabelle basierend auf den wie durch den oben beschriebenen Integritätsnachrichtenanalysator 306 bestimmten Kommunikationsstatus eingepflegt. Das heißt, wenn der Integritätsnachrichtenanalysator 306 eine Integritätsnachricht von einem bestimmten Host empfängt, stellt der Integritätstabellengenerator 308 den Kommunikationsstatus mit dem bestimmten Host (über das Netz, auf welchem die Nachricht empfangen wurde) auf gut. Wenn der Integritätsnachrichtenanalysator 306 bestimmt, dass eine Integritätsnachricht nicht wie erwartet von einem bestimmten Host empfangen wurde (z.B. ein Schwellenwertzeitraum ist ohne Empfangen einer Nachricht abgelaufen), stellt der Integritätstabellengenerator 308 den Kommunikationsstatus mit dem bestimmten Host (über das Netz, auf welchem die Nachricht hätte empfangen werden sollen) auf schlecht. Ausschließlich in dem Verlass darauf, ob die Integritätsnachrichten auf diese Weise empfangen werden, kann der Integritätsnachrichtenanalysator 306 den Kommunikationsstatus zwischen zwei unterschiedlichen Netz-Hosts, außer ihm selbst, nicht direkt bestimmen. In einigen Beispielen erzeugt die durch den Integritätstabellengenerator 308 erzeugte Integritätstabelle demzufolge nur die dem entsprechenden Netz-Host 210 zugeordneten Kommunikationsstatus-Informationen. In anderen Beispielen analysiert der Integritätsnachrichtenanalysator 306 den Inhalt der von anderen Netz-Hosts empfangenen Integritätsnachrichten, um den Kommunikationsstatus zwischen den anderen Hosts zu bestimmen.
Eine beispielhafte Tabelle 500, die Integritätsinformationen für das System 400 von 4 repräsentiert, wird in 5 gezeigt. In einigen Beispielen beinhaltet der Integritätstabellengenerator 308 mindestens einige der in der Tabelle 500 von 5 enthaltenen Informationen, obwohl nicht notwendigerweise alle Informationen und nicht notwendigerweise auf dieselbe Weise organisiert. In der Tabelle 500 von 5 wird jede der Netzschnittstellen 302, 304 (basierend auf dem zugeordneten primären oder sekundären Netz 408, 410) von jedem der Netz-Hosts 402, 404, 406 von 4 entlang der oberen Reihe und herunter zur Spalte auf der linken Seite der Tabelle 500 identifiziert. Der Status des direkten Kommunikationslinks zwischen jedem der zwei Netz-Hosts 402, 404, 406 über beide der entsprechenden Netzschnittstellen 302, 304 wird in dem Kästchen entsprechend der Reihe und Spalte der verbindenden Hosts 402, 404, 406 über das entsprechende Netz 408, 410 angezeigt.
Wie in dem veranschaulichten Beispiel gezeigt, ist die Tabelle 500 in vier Quadranten 502, 504, 506, 508 geteilt. Der erste Quadrant 502 repräsentiert die Kommunikationsstatus zwischen den Netz-Hosts 402, 404, 406 über das primäre Netz 408 (z.B. über die ersten Netzschnittstellen 302). Der vierte Quadrant 508 repräsentiert die Kommunikationsstatus zwischen den Netz-Hosts 402, 404, 406 über das sekundäre Netz 410 (z.B. über die zweiten Netzschnittstellen 304). Wie gezeigt, entsprechen die Kästchen entlang der Diagonalen der Tabelle 500, die die ersten und vierten Quadranten 502, 508 durchlaufen, der derselben Netzschnittstelle desselben Netz-Hosts zugeordneten Reihe und Spalte. Diese Kästchen sind daher grau hinterlegt, weil sie kein Kommunikationslink zwischen verschiedenen Punkten definieren.
Der zweite und dritte Quadrant 504, 506 der beispielhaften Tabelle 500 repräsentiert keine Kommunikationsstatus wie vorliegend beschrieben, weil die entsprechenden Reihen und Spalten nicht denselben Netzen 408, 410 zugeordnet sind und daher keine direkten Kommunikationslinks repräsentieren. Daher sind die meisten der Kästchen in den zweiten und dritten Quadranten 504, 506 durchgestrichen. Die Kästchen in jedem der zweiten und dritten Quadranten 504, 506, die den ersten und zweiten Netzschnittstellen 302, 304 desselben Netz-Hosts 402, 404, 406 zugeordnet sind, werden jedoch mit der Bezeichnung „örtlich“ repräsentiert, um anzugeben, dass die örtliche Kommunikation zwischen den Netzschnittstellen 302, 304 innerhalb des Host-Netzes 402, 404, 406 möglich ist, wenn IP-Routing in den Hosts wie oben beschrieben aktiviert ist. Insofern als örtliche Kommunikationen zwischen Netzschnittstellen desselben Netz-Hosts über keines der Netze 408, 410 erfolgt, sind solche Kommunikationen für die Definition der Kommunikationsstatus für das Netz gemäß den vorliegend offenbarten Lehren jedoch irrelevant. Das heißt, die in der beispielhaften Tabelle 500 repräsentierten örtlichen Kommunikationen werden nur aus Gründen der Erklärung gezeigt. In einigen Beispielen kann die durch den Integritätstabellengenerator 308 erzeugte Integritätstabelle daher die in den zweiten und dritten Quadranten 504, 506 repräsentierten Informationen ausschließen. In einigen Beispielen kann der Integritätstabellengenerator 308 weiterhin nur die Informationen beinhalten, die dem Netz-Host 402, 404, 406 zugeordnet sind, zu welchem der Integritätstabellengenerator 308 gehört. Die Integritätstabelle für Host A kann zum Beispiel nur Informationen in den Reihen und/oder Spalten beinhalten, die Host A zugeordnet sind.
Wie in dem veranschaulichten Beispiel von 5 gezeigt, ist der Kommunikationsstatus zwischen jeder der Netzschnittstellen 302, 304 von jedem der Netz-Hosts 402, 404, 406 „gut“, was angibt, dass keine Netzausfälle bestehen. Das beispielhafte System 400 von 4 wird vergleichsweise in 6 reproduziert, jedoch mit einem der ersten Netzschnittstelle 302 des zweiten Netz-Hosts 404 (Host B) zugeordneten Netzausfall 602, und die entsprechende Tabelle 700 der Kommunikationsstatus wird in 7 gezeigt. Wie in dem veranschaulichten Beispiel von 7 gezeigt, ist der vierte Quadrant 508 mit dem vierten Quadrant in der beispielhaften Tabelle 500 von 5 identisch, indem der Kommunikationsstatus von jeder Netzverbindung gut ist. Der vierte Quadrant 508 ist zwischen der in 5 gezeigten Tabelle 500 und der in 7 gezeigten Tabelle 700 unverändert, weil der vierte Quadrant 508 die Kommunikationsstatus repräsentiert, die dem sekundären Netz 410 zugeordnet sind, und der in 6 gezeigte Netzausfall 602 nur das primäre Netz 408 betrifft. In dem veranschaulichten Beispiel gibt der erste (dem primären Netz 408 zugeordnete) Quadrant 502 der beispielhaften Tabelle 700 von 7 einen schlechten Kommunikationsstatus zwischen dem zweiten Netz-Host 404 und sowohl dem ersten als auch dem dritten Netz-Host 402, 406 an. Der Kommunikationsstatus zwischen den ersten und dritten Netz-Hosts 402, 406 über das primäre Netz 408 verbleibt jedoch gut.
Aufgrund der Topologie der beispielhaften Systeme 400 von 4 und 6 führt der Ausfall, wann immer ein Netzausfall eintritt, dazu, dass einer der Netz-Hosts 402, 404, 406 die Verbindung mit allen anderen Netz-Hosts (z.B. den anderen zwei) verliert, die anderen Netz-Hosts jedoch immer noch in der Lage sind, zu kommunizieren. Andere Beispiele, die mehrere Netz-Hosts und/oder kompliziertere Netz-Topologien (z.B. mit einem oder mehreren Schaltern) beinhalten, können zu unterschiedlichen Unterteilungen der Kommunikationsstatus zwischen den verschiedenen beteiligten Netz-Hosts führen. Ein Netzausfall kann zum Beispiel dazu führen, dass ein Netz-Host die Verbindung mit nur einigen von den anderen Netz-Hosts über ein bestimmtes Netz verliert, während Kommunikationen mit anderen Netz-Hosts über das gleiche Netz beibehalten werden. In einigen Beispielen kann ein Netzausfall gleichermaßen verursachen, dass eine erste Gruppe von Netz-Hosts die Verbindung mit einer zweiten Gruppe von Netz-Hosts verliert, die Netz-Hosts jedoch die Verbindungen mit anderen Netz-Hosts in der entsprechenden Gruppe beibehalten.
Nochmals in Bezug zu 3 wird der beispielhafte Netz-Host 210 mit dem Integritätsnachrichtengenerator 310 zur Erzeugung der Integritätsnachrichten bereitgestellt, die periodisch an andere Netz-Hosts auf jedem der den ersten und zweiten Netzschnittstellen 302, 304 zugeordneten Netze zu übertragen sind. In einigen Beispielen beinhaltet eine Integritätsnachricht Host-Informationen, die dazu dienen, die Quelle oder Herkunft der Integritätsnachricht (z.B. den Netz-Host, von welchem die Integritätsnachricht übertragen wurde) zu identifizieren. In einigen Beispielen beinhalten die Host-Informationen insbesondere eine Indikation der IP-Adressen, die jeder der ersten und zweiten Netzschnittstellen 302, 304 des die Integritätsnachricht übertragenden Netz-Hosts zugewiesen wurden.
In einigen Beispielen beinhaltet eine Integritätsnachricht zusätzlich Integritätsinformationen, die dazu dienen, die Verbindungs- oder Kommunikationsstatus zwischen dem übertragenden Netz-Host (z.B. der Quelle der Integritätsnachricht) und jedem der anderen Netz-Hosts auf jedem der primären und sekundären Netze 408, 410 anzugeben. In einigen Beispielen entsprechen die in der Integritätsnachricht beinhalteten Integritätsinformationen den Informationen, die in der durch den Integritätstabellengenerator 308 erzeugten Identitätstabelle enthalten sind. In einigen Beispielen beinhalten die in jeder Integritätsnachricht gesendeten Integritätsinformationen, die durch den Integritätsnachrichtengenerator 310 eines bestimmten Netz-Hosts vorbereitet wurden, nur die Kommunikationsstatusinformationen, die diesem bestimmten Netz-Host zugeordnet sind. In einigen solchen Beispielen beinhaltet die übertragene Integritätsnachricht die dem Netz-Host für sowohl das primäre Netz 408 als auch das sekundäre Netz 410 zugeordneten Kommunikationsstatusinformationen, obwohl die bestimmte Integritätsnachricht nur zu einem jeweiligen Zeitpunkt über eines der Netze übertragen wird.
In einigen Beispielen analysiert der Integritätsnachrichtenanalysator 306 die Integritätsnachrichten, um andere Netz-Hosts auf jedem von den primären und sekundären Netzen 408, 410 basierend auf den ursprünglichen von jedem der anderen Netz-Hosts empfangenen Integritätsnachrichten automatisch aufzufinden. Wie oben beschrieben beinhaltet jede Integritätsnachricht Host-Informationen, die den Netz-Host identifizieren, der die Integritätsnachricht überträgt. In einigen Beispielen erzeugt dementsprechend der Integritätsnachrichtenanalysator 306 des empfangenden Netz-Hosts eine neue Eintragung in der IP-Routingtabelle für den Host basierend auf den empfangenen Host-Informationen (IP-Adressen für die zugeordneten Netzschnittstellen 302, 304 des Netz-Hosts, der die Nachricht übertrug), wenn eine Integritätsnachricht empfangen wird, die einen neuen Netz-Host identifiziert (d.h. einen Netz-Host, von welchem keine vorherige Integritätsnachricht empfangen wurde). In einigen Beispielen stellt der Integritätsnachrichtenanalysator 306 zusätzlich die Host-Informationen dem Integritätstabellengenerator 308 zur Aktualisierung und/oder Erweiterung der Integritätstabelle zur Verfügung, um den Status der Kommunikationen zwischen dem neu aufgefundenen Netz-Host, der die Integritätsnachricht überträgt, und dem Netz-Host, der die Integritätsnachricht empfängt, zu speichern. Das Auffinden neuer Netz-Hosts und die daraus folgenden nachfolgenden Integritätsnachrichten werden in 8 wie nachstehend beschrieben demonstriert.
8 ist eine Tabelle 800, die beispielhafte Änderungen im Zeitraffer an den durch jeden der Netz-Hosts 402, 404, 406 von 4 übertragenen Integritätsnachrichten während einer ursprünglichen Auffindung der Netz-Hosts 402, 404, 406, und die das Auftreten des Netzausfalls 602 von 6 umgeben, veranschaulicht. In dem veranschaulichten Beispiel von 8 entspricht jede Reihe der Tabelle 800 einem unterschiedlichen Zeitpunkt, wobei untere Reihen späteren Zeitpunkten, wie in der ersten Spalte 802 angegeben, entsprechen. Zeit T1 (in der ersten Reihe) ist daher ein erster Zeitpunkt, der von Zeit T2 (in der zweiten Reihe) gefolgt wird, der von Zeit T3 (in der dritten Reihe) gefolgt wird, und so fort. In dem veranschaulichten Beispiel überträgt eines der Host-Netze 402, 404, 406 zu jedem diskreten Zeitpunkt (z.B. T1, T2, T3 etc.) eine Integritätsnachricht über eines von jedem der primären Netze 408 oder der sekundären Netze 410 über die entsprechende Netzschnittstelle 302, 304 des übertragenden Host-Netzes 402, 404, 406. In der beispielhaften Tabelle 800 von 8 wird der Netz-Host 402, 404, 406, der die Integritätsnachricht zu einem bestimmten Zeitpunkt überträgt, in der zweiten Spalte 804 identifiziert, während das Netz 408, 410, über welches die Integritätsnachricht übertragen wird, in der dritten Spalte 806 angegeben wird. In dem veranschaulichten Beispiel ist die Netzschnittstelle 302, 304, die mit dem Netz 408, 410 verbunden ist, das in der Tabelle 800 aufgelistet ist, die Schnittstelle, von welcher jede entsprechende Integritätsnachricht gesendet wird.
Wie in dem veranschaulichten Beispiel gezeigt, durchlaufen die Quelle oder die Herkunft der zu aufeinander folgenden Zeitpunkten übertragenen Integritätsnachrichten jede der Netzschnittstellen 302, 304 jedes Netz-Hosts 402, 404, 406 über jedes Netz 408, 410, ehe dieselbe Netzschnittstelle 302, 304 zur Übertragung einer nachfolgenden Integritätsnachricht verwendet wird. Zur Zeit T1 überträgt zum Beispiel der erste Netz-Host 402 (Host A) eine erste Integritätsnachricht über das primäre Netz 408 (über die erste Netzschnittstelle 302). Erst zur Zeit T7 überträgt dieselbe Netzschnittstelle 302 desselben Netz-Hosts 402 eine Integritätsnachricht erneut, weil die Integritätsnachrichten von beiden Netzschnittstellen 302, 304 der zweiten und dritten Netz-Hosts 404, 406 und der zweiten Netzschnittstelle 304 des ersten Netz-Hosts 402 zu den Zeiten T2–T6 übertragen werden. In einigen Beispielen ist das Zeitintervall zwischen jedem in der beispielhaften Tabelle 800 repräsentierten Zeitpunkt ungefähr dasselbe. Somit ist der ungefähre Zeitplan oder das Timing jeder aufeinanderfolgenden Integritätsnachricht bekannt, sodass das Zeitintervall zwischen jeder aufeinanderfolgenden Integritätsnachricht von derselben Netzschnittstelle desselben Netz-Hosts gleichermaßen bekannt ist. Anders ausgedrückt ist in einigen Beispielen das Zeitintervall bekannt, über welches das System 400 jede der Netzschnittstellen jeder der Netzknoten durchläuft, um eine Integritätsnachricht zu übertragen. Infolgedessen kann der Zeitraum seit Empfang der letzten Integritätsnachricht von einer bestimmten Netzschnittstelle eines bestimmten Netz-Hosts überwacht werden, um zu bestimmen, wann eine nächste Integritätsnachricht von derselben Quelle erwartet wird. In einigen Beispielen wird ein Netzausfall detektiert, wenn keine Integritätsnachricht innerhalb des erwarteten Zeitraums empfangen wird. Der Zeitraum zum Durchlaufen jeder Netzschnittstelle jedes Netz-Hosts kann sich von System zu System je nach der Natur und Größe der beteiligten Netze und der Frequenz, auf welcher die Integritätsnachrichten übertragen werden, unterscheiden. In einigen Beispielen kann der Zeitraum eines Durchlaufs 100 Millisekunden betragen. Infolgedessen können Netzausfälle detektiert und dann schnell darauf reagiert werden (z.B. im Wesentlichen in Echtzeit), ehe wichtige Daten verloren gegen. Eine Durchlaufperiode von beispielsweise 500 Millisekunden hat eine Umschaltzeit von weniger als 2 Sekunden zur Folge.
Die beispielhafte Tabelle 800 von 8 gibt auch den Inhalt jeder Integritätsnachricht an, die zu jedem Zeitpunkt gesendet wurde. Die vierte Spalte 808 gibt insbesondere die identifizierenden Informationen an, die mit jeder Integritätsnachricht gesendet werden. Wie oben beschrieben beinhaltet jede Integritätsnachricht Host-Informationen, die den Netz-Host identifizieren, der die Nachricht sendet, einschließlich einer Indikation der IP-Adressen jeder von den Netzschnittstellen 302, 304 des Netz-Hosts. Während somit eine Integritätsnachricht von dem ersten Netz-Host 402 über das primäre Netz 408 in dem veranschaulichten Beispiel zu Zeiten T1 und T7 gesendet wird, werden dieselben Host-Informationen auch zu den anderen Netz-Hosts 404, 406 zur Zeit T4 über das sekundäre Netz 410 gesendet.
In der fünften Spalte 810 der beispielhaften Tabelle 800 sind die in jeder Integritätsnachricht enthaltenen Integritätsinformationen repräsentiert. Wie oben beschrieben können sich die Netz-Hosts 402, 404, 406 in einigen Beispielen basierend auf den von einander empfangenen Integritätsnachrichten auffinden. In solchen Beispielen können die Integritätsnachrichten, ehe die Netz-Hosts aufgefunden werden, keine Integritätsinformationen (z.B. Kommunikationsstatus zwischen den Hosts) beinhalten, weil solche Informationen unbekannt sind. Wie in 8 gezeigt, überträgt der Host A zu Zeit T1 eine Integritätsnachricht, die die Host-Informationen für Host A beinhaltet jedoch keine Integritätsinformationen beinhaltet. Weil Host B die zur Zeit T1 übertragene Integritätsnachricht von Host A empfangen hat, wird der Integritätsnachrichtenanalysator 306 von Host B aktiviert, um Host A (basierend auf den übertragenen Host-Informationen) zu identifizieren und somit einen neuen Eintrag für Host A (und die entsprechenden Netzschnittstellen 302, 304) in einer IP-Routingtabelle zu erzeugen. Weil Host B zusätzlich die vom Host A über das primäre Netz 408 übertragene Integritätsnachricht empfing, bestätigt der Integritätsnachrichtenanalysator 306 von Host B, dass Kommunikationen über das primäre Netz 408 möglich sind, um den Integritätstabellengenerator 308 von Host B dazu zu aktivieren, den Kommunikationsstatus auf gut zu stellen. Demzufolge beinhaltet die vom Host B zu Zeit T2 übertragene Integritätsnachricht Integritätsinformationen, die das Vorhandensein von Host A angeben (wie durch Host B aufgefunden) und angeben, dass der Kommunikationsstatus zwischen ihnen über das primäre Netz 408 gut ist (angegeben durch den Buchstaben „G“).
Zur Zeit T3 beinhaltet die vom Host C übertragene Integritätsnachricht Integritätsinformationen mit Bezug zu sowohl Host A als auch Host B basierend auf zuvor übertragenen Integritätsnachrichten, die von jedem Host jeweils zur Zeit T1 und Zeit T2 gesendet wurden. Sobald die Integritätsnachricht zur Zeit T3 vom Host C gesendet wurde, wurden die Host-Informationen von jedem Netz-Host einmal übertragen, sodass jeder Host nun in Bezug zu den anderen Hosts aufgefunden ist, um ggf. direkte Datenkommunikationen (z.B. durch Verwenden der IP-Informationen, die von jedem der anderen Netz-Hosts bereitgestellt wurden) zu ermöglichen.
Wie in dem veranschaulichten Beispiel von 8 gezeigt, wird jede der ersten drei Integritätsnachrichten (zu Zeiten T1, T2, und T3) über das primäre Netz 408 übertragen. Somit werden die Kommunikationsstatus, die zwischen jedem der Netz-Hosts 402, 404, 406 (Host A, Host B, Host C) angezeigt werden, wie sie in jeder Integritätsnachricht bereitgestellt sind, nur mit Bezug auf das primäre Netz 408 bereitgestellt. Erst wenn die erste Integritätsnachricht über das sekundäre Netz 410 (zur Zeit T4) vom Host A gesendet wird, bestätigt der Integritätsnachrichtenanalysator 306 von Host B, dass Kommunikationen zwischen Hosts A und B über das sekundäre Netz 410 möglich sind. Die Bestätigung solch einer Verbindung wird in den nachfolgenden Integritätsinformationen reflektiert, die von Host B zur Zeit T5 gesendet werden. Host C empfängt auch die von Host A zur Zeit T4 gesendete Integritätsnachricht, um Kommunikationen dazwischen auch über das sekundäre Netz 410 zu bestätigen. Sobald die Integritätsnachricht zur Zeit T6 von Host C gesendet wurde, hat jede Netzschnittstelle 302, 304 jedes Netz-Hosts 402, 404, 406 eine Integritätsnachricht übertragen, sodass jeder Netz-Host 402, 404, 406 seinen Verbindungsstatus mit Bezug zu jedem anderen Host in dem System 400 bestätigen kann. Nachfolgende Integritätsnachrichten, die von jedem Host (beginnend zur Zeit T7) gesendet wurden, befähigen Netz-Hosts 402, 404, 406 zur fortdauernden Überprüfung der Kommunikationsstatus untereinander und Bereitstellung einer Aktualisierung von Änderungen an den Integritätsinformationen.
Wenn jede der Netzschnittstellen 302, 304 jedes Netz-Hosts 402, 404, 406 eine funktionierende Verbindung beibehält, bleiben die Integritätsinformationen, die als Teil jeder nachfolgenden Integritätsnachricht gesendet werden, dieselben, wobei alle Kommunikationsstatus gut sind, wie zu Zeiten T7, T8, und T9 gezeigt. Wenn jedoch ein Netzausfall eintritt, werden die nachfolgenden Integritätsnachrichten der betroffenen Netz-Hosts schließlich aktualisiert, um die Änderung im Kommunikationsstatus zwischen den betroffenen Netz-Hosts zu reflektieren.
In dem veranschaulichten Beispiel von 8 tritt der Netzausfall 602 von 6 zwischen Zeiten T8 und T9 (z.B. zur Zeit T8.5) ein. Wie in dem veranschaulichten Beispiel gezeigt, werden die Kommunikationsstatus von allen Kommunikationen, die durch die Integritätsinformationen angezeigt werden, die zu Zeiten T9 und T10 (jeweils von Host C und Host A) gesendet wurden, nichtsdestotrotz als gut gezeigt, obwohl die Kommunikationen zu oder von Host B (dem zweiten Netz-Host 404) aufgrund des Ausfalls 602 nicht mehr möglich sind. Wie oben beschrieben, basiert die Detektion einer schlechten Verbindung (z.B. ein Netzausfall) in einigen Beispielen mit Bezug zu einer bestimmten Netzschnittstelle auf einem Schwellenwertzeitraum, der nach der letzen (z.B. jüngst erfolgten) Übertragung von der bestimmten Netzschnittstelle empfangen wurde, ohne eine neue Übertragung zu empfangen. In dem veranschaulichten Beispiel fand die letzte von Host B über das primäre Netz 408 (vor dem Netzausfall 602) erfolgreich übertragene Integritätsnachricht zur Zeit T8 statt. Da es sechs unterschiedliche Netzschnittstellen zu durchlaufen gilt, wird die Integritätsnachricht, die von Host B über das primäre Netz 408 übertragen wird, erst zur Zeit T14 erwartet. Somit repräsentieren die Integritätsnachrichten, die zu Zeiten T9 und T10 übertragen werden, weiterhin alle Kommunikationsstatus basierend auf der zur Zeit T8 empfangenen Nachricht als gut. In einigen Beispielen beträgt die Zeit zwischen Zeit T8 und Zeit T14 weniger als eine Sekunde, sodass dieser Fehler im Kommunikationsstatus schnell behoben werden kann.
In dem veranschaulichten Beispiel geben die zur Zeit T11 gesendeten Integritätsinformationen an, dass der Kommunikationsstatus zwischen Host B (dem Netz-Host, der die Integritätsnachricht sendet) und Host C über das primäre Netz 408 schlecht ist (angegeben durch den Buchstaben „B“), obwohl der Kommunikationsstatus zwischen Host B und Host A noch gut ist. Die unterschiedlichen mit Bezug zu Hosts A und C angegebenen Kommunikationsstatus sind eine Folge des Netzausfalls 602 im Verhältnis zum Timing der letzten Integritätsnachricht, die an Host B von jedem der Hosts A und B über das primäre Netz 408 empfangen wurden. Wie in der beispielhaften Tabelle 800 gezeigt, war die letzte von Host A über das primäre Netz 408 übertragene Integritätsnachricht zur Zeit T7, was vor dem Netzausfall 602 zur Zeit T8.5 war. Die nächste von Host A über das primäre Netz erwartete Integritätsnachricht wird erst zur Zeit T13 erwartet. Somit ist zur Zeit T11 das Zeitintervall bis zur nächsten von Host A erwarteten Integritätsnachricht noch nicht abgelaufen, sodass der Integritätsnachrichtenanalysator 306 von Host B noch nicht bestätigt, dass das Netz zwischen den Hosts ausgefallen ist. Im Gegensatz dazu übertrug Host C eine Integritätsnachricht zur Zeit T9, was nach dem Netzausfall 602 zur Zeit T8.5 eintrat. Infolgedessen würde die Integritätsnachricht, die von Host C zur Zeit T9 gesendet wurde, nicht wie erwartet an Host B geliefert werden, sodass der Integritätsnachrichtenanalysator 306 bestimmt, dass die Verbindung zwischen den Hosts schlecht ist.
Wie oben beschrieben analysiert der Integritätsnachrichtenanalysator 306 in einigen Beispielen den Inhalt jeder Integritätsnachricht (z.B. die Integritätsinformationen), um die Kommunikationsstatus zwischen den Netz-Hosts zu aktualisieren, die in einer nachfolgenden Integritätsnachricht zu präsentieren sind. Dies wird durch die Integritätsnachricht veranschaulicht, die durch Host C zur Zeit T12 gesendet wird. Wie oben beschrieben, wurde die durch Host B zur Zeit T8 gesendete Integritätsnachricht erfolgreich an Host C empfangen, weil der Netzausfall 602 noch nicht eingetreten war. Die nächste Integritätsnachricht von Host B über das primäre Netz 408 wird weiterhin erst zur Zeit T14 erwartet. In einigen Beispielen identifiziert der Integritätsnachrichtenanalysator 306 von Host C jedoch den schlechten Kommunikationsstatus, der durch die von Host B über das sekundäre Netz 410 (zur Zeit T11) gesendeten Integritätsinformationen angezeigt wird. In einigen solchen Beispielen bestimmt der Integritätsnachrichtenanalysator 306, dass der Kommunikationsstatus zwischen ihm selbst und Host B über das primäre Netz 408 schlecht ist.
Die durch Host A zur Zeit T13 bereitgestellten Integritätsinformationen geben immer noch an, dass der Kommunikationsstatus zwischen Hosts A und B gut ist, weil sich die nächtet erwartete Integritätsnachricht von Host B noch in der Zukunft befindet (zur Zeit T14) und keine andere Integritätsnachricht die schlechte Verbindung zwischen Hosts A und B anderweitig angibt. Während Host A jedoch die Integritätsnachricht zur Zeit T13 überträgt, empfängt Host B die Nachricht aufgrund des Netzausfalls 602 nicht. Der Integritätsnachrichtenanalysator 306 von Host B bestimmt daher, dass der Kommunikationsstatus zur Zeit T13 schlecht ist, weil das die Zeit ist, zu der die nächste Integritätsnachricht von Host A erwartet jedoch nie empfangen wurde.
Zur Zeit T14 kann der Host B versuchen, eine Integritätsnachricht zu übertragen, die den Kommunikationsausfall zwischen Hosts A und B (bestimmt zur Zeit T13) und zwischen Hosts B und C (bestimmt zur Zeit T9) angibt. Aufgrund des Netzausfalls 602 scheitert jedoch die Übermittlung der Integritätsnachricht von Host B, sodass nichts an Hosts A und C übermittelt wird. In einigen solchen Beispielen kann die Übertragung während Host B versucht, die Integritätsnachricht (z.B. zur Zeit T14) zu übertragen, unerkannt bleiben, wodurch an Host B angegeben wird, dass unabhängig davon, ob der Schwellenwertzeitraum seit dem Empfang einer Übertragung von den anderen Hosts überschritten wurde, ein Netzausfall eingetreten ist. In Bezug auf Hosts A und C wurde eine neue Nachricht zur Zeit T14 erwartet, dem Zeitraum zwischen Zeit T8, als die letzte erfolgreich übertragene Integritätsnachricht von Host B über das primäre Netz 408 (fehlender Satzteil im Ausgangstext), und Zeit T15 überschreitet den Schwellenwertzeitraum, während welchem eine andere Integritätsnachricht erwartet wird. In einigen solchen Beispielen bestimmt der Integritätsnachrichtenanalysator 306 von Host C, dass ein Netzausfall zwischen Host B und Host C über das primäre Netz 408 besteht und aktualisiert die Integritätsinformationen demgemäß (gesendet zur Zeit T15). In anderen Beispielen kann der Integritätsnachrichtenanalysator 306 von Host C den ausgefallenen Kommunikationsstatus basierend auf den von Host B (zur Zeit T11) wie oben beschrieben empfangenen Integritätsinformationen bereits bestimmt haben. In solchen Beispielen reflektieren demzufolge die in der durch Host C (zur Zeit T15) übertragenen Integritätsnachricht beinhalteten Integritätsinformationen weiterhin den schlechten Kommunikationsstatus. In dem veranschaulichten Beispiel bestimmt der Integritätsnachrichtenanalysator 306 von Host A gleichermaßen, dass zwischen Host A und Host B über das primäre Netz 408 ein Netzausfall besteht, weil eine Integritätsnachricht von Host B zur Zeit T14 erwartet wurde. Somit werden die durch Host A zur Zeit T16 bereitgestellten Integritätsinformationen aktualisiert, um den schlechten Kommunikationsstatus zu reflektieren. Zur Zeit T16 haben somit alle der Netz-Hosts den Netzausfall 602 detektiert und eine Integritätsnachricht übertragen, die die Änderung im Kommunikationsstatus reflektiert. Die Integritätsinformationen in jeder nachfolgenden Integritätsnachricht von jedem Host bleibt weiterhin dieselbe bis eine andere Änderung detektiert wird (z.B. der Netzausfall 602 wird repariert und/oder ein anderer Netzausfall tritt zwischen mindestens zwei der Netz-Hosts ein). Obwohl das veranschaulichte Beispiel den Kommunikationsstatus als nach nur einem einzigen Zeitintervall aktualisiert zeigt (z.B. ein Zyklus durch alle Netzschnittstellen), kann der Schwellenwertzeitraum in einigen Beispielen länger sein, wie zum Beispiel die Dauer von zwei oder drei vollen Zyklen durch die Netzschnittstellen.
Obwohl die beispielhafte Tabelle 800 zeigt, dass Host A eine Integritätsnachricht zu Zeiten T13 und T19 über das primäre Netz überträgt, und dass Host C eine Integritätsnachricht zu Zeiten T9 und T15 über das primäre Netz überträgt, werden die Nachrichten von Hosts A und C aufgrund des Netzausfalls 602 mit Bezug zu Host B nur gegenseitig erfolgreich übermittelt. Das heißt, während Hosts A und C die durch den anderen übertragene Integritätsnachricht empfangen hätten, hätte Host B keine der Integritätsnachrichten empfangen.
In einigen Beispielen, wie in der beispielhaften Tabelle 800 von 8 gezeigt, alternieren die von jedem Netz-Host 402, 404, 406 gesendeten Integritätsnachrichten zwischen dem primären Netz 408 und dem sekundären Netz 410. Das heißt, jeder der Hosts A, B, und C überträgt eine Integritätsnachricht über das primäre Netz 408 gefolgt von dem Übertragen einer Integritätsnachricht über das sekundäre Netz 410 durch jeden der Hosts A, B, und C. Andere Anordnungen sind möglich. 9 ist zum Beispiel eine Tabelle 900, die unterschiedliche beispielhafte Änderungen im Zeitraffer an den durch jeden der Netz-Hosts von 4 übertragenen Integritätsnachrichten während einer ursprünglichen Auffindung der Netz-Hosts veranschaulicht. In dem veranschaulichten Beispiel von 9 überträgt jeder Netz-Host 402, 404, 406 eine Integritätsnachricht über jedes Netz 408, 410, ehe ein anderer Netz-Host dasselbe tut. Das heißt Host A überträgt eine erste Integritätsnachricht über das primäre Netz 408 (zur Zeit T1), gefolgt von einer zweiten Integritätsnachricht über das sekundäre Netz 410 (zur Zeit T2), ehe Host B eine Integritätsnachricht (beginnend zur Zeit T3) überträgt. Die daraus folgenden Integritätsinformationen in aufeinanderfolgenden Integritätsnachrichten während der Auffindung jeder der Netz-Hosts wird in der beispielhaften Tabelle 900 von 9 gezeigt.
Wie oben beschrieben, kann in einigen Beispielen jeder Netz-Host den Kommunikationsstatus zwischen ihm selbst und den anderen Netz-Hosts basierend darauf bestimmen, ob Integritätsnachrichten von den anderen Hosts erwartungsgemäß empfangen werden oder nicht. Somit sind die Host-Informationen in einigen Beispielen das Einzige, was in jeder Integritätsnachricht beinhaltet ist. In solchen Beispielen entsprechen die in der fünften Spalte 810 gezeigten Integritätsinformationen den in der durch den Integritätstabellengenerator 308 erzeugten Integritätstabelle gespeicherten Informationen. Diese Informationen können jedoch den anderen Netz-Hosts nicht mitgeteilt werden. Das heißt, in einigen Beispielen erzeugt jeder Host seine eigene Integritätstabelle, ohne die daraus folgenden Integritätsinformationen mitzuteilen. In anderen Beispielen werden die Integritätsinformationen zwischen Hosts geteilt, um den Vergleich von zwischen jedem von den Netz-Hosts bestimmten Kommunikationsstatus zu ermöglichen. In einigen Beispielen werden die von einem Netz-Host von anderen Netz-Hosts empfangenen Integritätsinformationen verwendet, um eine Integritätstabelle (z.B. wenn die Integritätstabelle die Kommunikationsstatus aller Netzverbindungen aufweisen soll) zu aktualisieren oder zu vervollständigen. In einigen Beispielen werden die durch einen Netz-Host von einem anderen Host empfangenen Integritätsinformationen weiterhin verwendet, um die in der nächsten Integritätsnachricht, die der Netz-Host senden soll, beinhalteten Integritätsinformationen zu aktualisieren.
Nochmals in Bezug zu 3 wird der beispielhafte Netz-Host 210 mit dem beispielhaften Kommunikationswegbestimmer 312 bereitgestellt, um den Weg für Datenkommunikationen zwischen dem Netz-Host 210 und anderen Netz-Hosts zu bestimmen und einzustellen. In einigen Beispielen bestimmt der Kommunikationswegbestimmer 312 den Kommunikationsweg als das den verbundenen Netzschnittstellen zugeordnete Netz übergehend, wenn der Kommunikationsstatus zwischen einer bestimmten Netzschnittstelle (z.B. die erste Netzschnittstelle 302) und einer entsprechende Schnittstelle eines anderen Netz-Hosts über dem zugeordneten Netz (z.B. dem primären Netz 408) gut ist. Somit kommuniziert der Netz-Host direkt über das entsprechende Netz. Wenn jedoch der Integritätsnachrichtenanalysator 306 einen Netzausfall zwischen den Netzschnittstellen detektiert (z.B. einen schlechten Kommunikationsstatus), kann der Kommunikationswegbestimmer 312 einen alternativen Weg zwischen den Netzschnittstellen identifizieren. Wenn zum Beispiel ein Netzausfall zwischen zwei Netz-Hosts über das primäre Netz 408 vorliegt, kann der Kommunikationswegbestimmer 312 definieren, dass der alternative Kommunikationsweg durch das sekundäre Netz 410 läuft, das die zwei Netz-Hosts verbindet. Beispielhafte Kommunikationswege werden ausführlicher in Verbindung mit 10–12 beschrieben.
In einigen Beispielen richtet der Kommunikationswegbestimmer 312 einen alternativen Kommunikationsweg ein, sobald ein schlechter Kommunikationsstatus detektiert wird. In anderen Beispielen richtet der Kommunikationswegbestimmer 312 einen alternativen Kommunikationsweg ein, nachdem eine Schwellenwertanzahl misst, dass ein Kommunikationsweg als schlecht bestätigt wird. In einigen Beispielen richtet der Kommunikationswegbestimmer 312 eines bestimmten Netz-Hosts einen alternativen Kommunikationsweg mit Bezug zu einem anderen Host ein, nachdem eine Schwellenwertanzahl von aufeinanderfolgenden Integritätsnachrichten von dem bestimmten Host-Netz angibt, dass der Kommunikationsstatus zwischen den Hosts schlecht ist. Die Schwellenwertanzahl von Integritätsnachrichten mit einem schlechten Kommunikationsstatus kann zum Beispiel drei sein. Wie in dem veranschaulichten Beispiel von 8 gezeigt, wird die erste von Host B gesendete Integritätsnachricht, die einen schlechten Kommunikationsstatus mit Bezug zu Host C zeigt, zur Zeit T11 über das sekundär Netz 410 gesendet. Die zweite Integritätsnachricht mit denselben Informationen (ein schlechter Kommunikationsstatus zwischen Hosts B und C) wird zur Zeit T14 über das primäre Netz 408 gesendet, die die anderen Hosts wegen des Netzausfalls 602 nie erreicht (weshalb die Tabelle 800 angibt, dass nichts übermittelt wurde). Die dritte von Host B gesendete Integritätsnachricht, die mit Bezug zu Host C einen schlechten Kommunikationsstatus angibt, wird zur Zeit T17 über das sekundäre Netz 410 gesendet. In solchen Beispielen richtet daher der Kommunikationswegbestimmer 312 von Host B einen alternativen Kommunikationsweg zwischen Host B und Host C zur Zeit T17 ein.
Der Kommunikationswegbestimmer 312 von Host B richtet im Gegensatz dazu in dem obigen Beispiel einen alternativen Kommunikationsweg zwischen Host B und Host A zur Zeit T20 ein, weil dies die dritte von Host B gesendete (jedoch nie übermittelte) Integritätsnachricht ist, die einen schlechten Kommunikationsstatus zwischen Hosts B und Hosts A angibt. Die erste gesendete Integritätsnachricht (über das primäre Netz 408 versucht) von Host B mit solchen Informationen ist zur Zeit T14 und die zweite gesendete (und erfolgreich über das sekundär Netz 410 übermittelte) Integritätsnachricht ist zur Zeit T17. Mit Bezug zu Host A sind die drei aufeinanderfolgende Integritätsnachrichten, die die ausgefallene Verbindung zu Host B angeben, zu den Zeiten T16, T19 und T22 (nicht gezeigt). Der Kommunikationswegbestimmer 312 von Host A richtet somit einen Kommunikationsweg zwischen Host A und Host B zur Zeit T20 ein. Mit Bezug zu Host C sind die drei Integritätsnachrichten, die die ausgefallene Verbindung mit Host B angeben, zu den Zeiten T12, T15 und T18. Der Kommunikationswegbestimmer 312 von Host C richtet somit einen alternativen Kommunikationsweg zwischen Host C und Host B zur Zeit T18 ein.
10 ist eine schematische Darstellung eines beispielhaften Systems 1000 mit zwei beispielhaften Netz-Hosts 1002, 1004, die über ein primäres Netz 1006 und ein sekundäres Netz 1008 verbunden sind. In einigen Beispielen funktionieren die Netz-Hosts 1002, 1004 ähnlich wie der oben beschriebene Netz-Host 210 (entsprechend den Thin Clients 126 und/oder der Arbeitsplätze 117 von 1 und/oder 2 und/oder den Netz-Hosts 402, 404, 406 von 4 und/oder 6). Wie in dem veranschaulichten Beispiel gezeigt, weist somit jeder der Netz-Hosts 1002, 1004 eine erste mit dem primären Netz 1006 verbundene Netzschnittstelle 1010 und eine zweite mit der sekundären Schnittstelle 1008 verbundene Netzschnittstelle 1012 auf. Die primären und sekundären Netze 1006, 1008 von 10 können den primären und sekundären Netzen 408, 410 von 4 entsprechen.
In dem veranschaulichten Beispiel von 10 wird das primäre Netz 1006 mit einer IP-Netznummer identifiziert, die als X.X.X repräsentiert wird. Die ersten Netzschnittstellen 1010 des ersten Netz-Hosts 1002 und des zweiten Netz-Hosts 1004 sind mit dem primären Netz 1006 mit zugewiesenen IP-Adressen von jeweils X.X.X.1 und X.X.X.2 verbunden. Das sekundäre Netz 1008 des veranschaulichten Beispiels wird mit einer IP-Netznummer identifiziert, die als Y.Y.Y repräsentiert ist, und die zweiten Netzschnittstellen 1012 des ersten Netz-Hosts 1002 und des zweiten Netz-Hosts 1004 sind mit dem sekundären Netz 1006 mit zugewiesenen IP-Adressen von jeweils Y.Y.Y.1 und Y.Y.Y.2 verbunden.
Wie in dem veranschaulichten Beispiel gezeigt, gibt es zwei direkte Kommunikationswege von dem ersten Netz-Host 1002 zu dem zweiten Netz-Host 1004. Beide Kommunikationswege sind direkt von entweder der ersten Netzschnittstelle 1010 des ersten Netz-Hosts 1002 zu der ersten Netzschnittstelle 1010 des zweiten Netz-Hosts 1002 über das primäre Netz 1006 oder von der zweiten Netzschnittstelle 1012 des ersten Netz-Hosts 1002 zu der zweiten Netzschnittstelle 1012 des zweiten Netz-Hosts 1004 über das sekundäre Netz 1006. Gleichermaßen gibt es zwei direkte Wege, die von dem zweiten Netz-Host 1004 zu dem ersten Netz-Host 1002 gehen, die die umgekehrten der oben erläuterten Wege sind. Diese direkten Kommunikationswege sind in der Tabelle 1014 von 10 zusammengefasst.
Wenn an einem von den Netzen 1006, 1008 ein Netzausfall auftritt, sind direkte Kommunikationen zwischen den mit dem ausgefallenen Netz verbundenen Netzschnittstellen 1010, 1012 nicht mehr verfügbar. Ein Ausfall in einem Netz beeinträchtigt jedoch das andere Netz nicht derart, dass direkte Kommunikationen noch über das andere (ordnungsgemäß funktionierende) Netz verfügbar sind. In einigen solchen Beispielen werden Kommunikationen zwischen den Netzschnittstellen, die dem ausgefallenen Netz zugeordnet sind, indirekt durch das gute Netz erzielt. 11 veranschaulicht zum Beispiel das beispielhafte System 1000 mit einem Netzausfall 1102 in dem primären Netz 1006. Obwohl die zweiten Netzschnittstellen 1012 der ersten und zweiten Netz-Hosts 1002, 1004 direkt über das sekundäre Netz 1008 kommunizieren können, können die ersten Netzschnittstellen 1010 der ersten und zweiten Netz-Hosts 1002, 1004 wegen des Netzausfalls 1102 nicht direkt über das primäre Netz 1006 kommunizieren.
In einigen Beispielen wird der obige Netzausfall 1102 durch Verwenden internen oder örtlichen Routings 1104 innerhalb jedem der Netz-Hosts 1002, 1004 zwischen den Netzschnittstellen 1010, 1012 jedes Netz-Hosts 1002, 1004 durch Aktivieren von IP-Routing umgangen. Mit innerhalb eines Netz-Hosts aktiviertem IP-Routing definiert der Kommunikationswegbestimmer 312 in einigen Beispielen, wenn ein schlechter Kommunikationsstatus mit Bezug zu einer der Netzschnittstellen und einer entsprechenden Netzschnittstelle von einem anderen Netz-Host detektiert wird, einen neuen oder alternativen Weg, der auf das gute Netz angewiesen ist, mit welchem der Netz-Host verbunden ist. In einigen Beispielen aktualisiert der Kommunikationswegbestimmer 312 insbesondere automatisch die IP-Routingtabelle für die mit dem ausgefallen Netz verbundene Netzschnittstelle mit einer Eingabe, die die andere Netzschnittstelle desselben Netz-Hosts als ein Gateway oder einen Router zwischen der Netzschnittstelle mit einer schlechten Verbindung und dem Netz, das eine gute Verbindung hat, definiert. Da sowohl die Netz-Host übertragenden Daten als auch die Netz-Host empfangenden Daten den Netzausfall detektieren, wird die Netzschnittstelle an jedem Host, der mit dem guten Netz verbunden ist, jeweils als Gateway für die andere Netzschnittstelle des entsprechenden Netz-Hosts definiert, um zu ermöglichen, dass Datenkommunikationen ggf. zum Endziel weitergeleitet werden.
Die erste Netzschnittstelle 1010 des ersten Netz-Hosts 1002 kann versuchen, Daten (z.B. dem Betrieb des Prozesssteuerungssystems zugeordnete Daten) an die erste Netzschnittstelle 1010 des zweiten Netz-Hosts 1002 zu übertragen. In der in 11 repräsentierten Situation scheitern solche Datenkommunikationen wegen des Netzausfalls 1102. Wie oben beschrieben, überwachen jedoch die Netz-Hosts 1002, 1004 die häufige Übertragung von Integritätsnachrichten, die von dem anderen Host gesendet werden, sodass der Netzausfall 1102 sehr schnell detektiert werden kann (z.B. innerhalb weniger Sekunden oder darunter). In einigen Beispielen definiert der Kommunikationswegbestimmer 312 des ersten Netz-Hosts 1002, sobald der Netzausfall 1102 detektiert wird, einen neuen Kommunikationsweg, in welchem die zweite Netzschnittstelle 1012 als ein Gateway zum Zwecke von Kommunikationen von der ersten Netzschnittstelle 1010 des ersten Netz-Hosts 1002 definiert ist. Infolgedessen werden Kommunikationen, die von der ersten Netzschnittstelle 1010 des ersten Netz-Hosts 1002 stammen, (z.B. über internes Routing 1104) zu der zweiten Netzschnittstelle 1012 geroutet und über das sekundäre Netz 1008 übertragen. In solchen Beispielen definiert der Kommunikationswegbestimmer 312 des zweiten Netz-Hosts 1004 gleichzeitig die zweite Netzschnittstelle 1012 gleichermaßen als ein Gateway zu Zwecken der der ersten Netzschnittstelle 1010 des zweiten Netz-Hosts 1004 zugeordneten Kommunikationen. Infolgedessen werden Kommunikationen, die an der zweiten Netzschnittstelle 1012 des zweiten Netz-Hosts 1004 empfangen werden, die an die erste Netzschnittstelle 1010 adressiert sind, zu der ersten Netzschnittstelle 1010 (z.B. via internem Routing 1104) weitergeleitet. In dem veranschaulichten Beispiel von 11 gibt es somit einen direkten Kommunikationsweg und einen indirekten Kommunikationsweg zwischen den Netz-Hosts 1002, 1004, wie in der Tabelle 1106 zusammengefasst.
Sobald der Kommunikationswegbestimmer 312 den neuen Kommunikationsweg wie oben beschrieben einrichtet, können die Datenkommunikationen zwischen den ersten Netzschnittstellen 1010 der ersten und zweiten Netz-Hosts 1002, 1004 wieder aufgenommen werden. In einigen Beispielen ist die Zeit zwischen einem Netzausfall und der Einrichtung eines alternativen Kommunikationswegs weniger als fünf Sekunden. In einigen Beispielen ist sie weniger als zwei Sekunden. Dies ist demzufolge eine erhebliche Verbesserung im Vergleich zu bestehenden Verfahren, die eine Minute oder mehr benötigen, um einen Netzfehler zu detektieren, und dann einen neuen Kommunikationsweg einrichten müssen, ehe die Datenübertragungen wieder beginnen können.
In einigen Beispielen werden Integritätsnachrichten, die von der ersten Netzschnittstelle 1010 stammen, obwohl die Kommunikationen über den alternativen durch den Kommunikationswegbestimmer 312 definierten Kommunikationsweg definiert werden, dennoch über den direkten durch das primäre Netz 1006 definierten Weg übertragen. In solchen Beispielen sind die Integritätsnachrichtenübertragungen nicht erfolgreich, solange der Netzausfall 1102 anhält. Die anderen Host-Netze, die eine solche Integritätsnachricht erwarten, fahren somit damit fort, den Kommunikationsstatus für die Verbindung zwischen den jeweiligen Netzschnittstellen als schlecht zu bestätigen. Sobald der Netzausfall jedoch repariert ist, wird die nächste Integritätsnachricht erfolgreich geliefert, sodass die Netz-Hosts, die die Nachricht empfangen, bestätigen können, dass die Verbindung wiederhergestellt wurde. In einigen Beispielen kann der Kommunikationswegbestimmer 312 die IP-Routingtabelle für die zugeordnete Netzschnittstelle anpassen, um die Prozesssteuerungsdaten wiederum über den direkten Weg des nun reparierten primären Netzes 1006 zu übertragen, sobald der Netz-Host bestimmt, dass ein Netzausfall repariert ist (d.h. der Kommunikationsstatus ändert sich von schlecht zu gut).
12 veranschaulicht das beispielhafte System 1000 mit einem Netzausfall 1202 in dem sekundären Netz 1008. In einigen Beispielen wird die Detektion und Einrichtung von einem alternativen Kommunikationsweg zwischen den sekundären Netzschnittstellen 1012 der Netz-Hosts 1002, 1004 auf dieselbe Weise bewerkstelligt, wie oben in Bezug auf den Netzausfall 1102 von 11 beschrieben, wobei jedoch die Kommunikationen zwischen den zweiten Netzschnittstellen 1012 durch das primäre Netz 1006 geroutet werden. Die Tabelle 1204 in 12 fasst die direkten und indirekten Kommunikationswege, die eine Folge des Netzausfalls 1202 von 12 sind, zusammen.
Nochmals in Bezug zu 3 wird der beispielhafte Netz-Host 210 mit dem beispielhaften Kommunikationsmanager 314 zur Handhabung der Übertragung der Integritätsnachrichten von dem Netz-Host 210 bereitgestellt. Der Kommunikationsmanager 314 steuert zum Beispiel den Zeitpunkt, zu dem eine Integritätsnachricht über die erste Netzschnittstelle 302 zu übertragen ist und zu dem eine Integritätsnachricht über die zweite Netzschnittstelle 304 zu übertragen ist. Wie oben beschrieben, alterniert die Übertragung der Integritätsnachrichten in einigen Beispielen zwischen den ersten und zweiten Netzschnittstellen 302, 304. In einigen Beispielen steuert der Kommunikationsmanager 314 den Zeitablauf jeder Integritätsnachricht, sodass er sich innerhalb des für jede aufeinanderfolgende Nachricht eingestellten Zeitintervalls befindet.
In einigen Beispielen handhabt der Kommunikationsmanager 314 die Übertragung von Daten (z.B. Prozesssteuerungsdaten) zusätzlich von dem Netz-Host 210 an jede bezeichnete Adresse auf jedem der Netze 408, 410. Der Kommunikationsmanager bereitet zum Beispiel Datenpakete mit den ordnungsgemäßen Routinginformationen vor, die an das richtige Ziel zu übertragen sind. In einigen Beispielen veranlasst der Kommunikationsmanager 314, wenn erstmals ein Netzausfall detektiert wird, dass Daten, die zu kommunizieren sind, ehe der Weg eingerichtet ist (typischerweise nur einige wenige Sekunden) zur erneuten Übertragung in die Warteschlange gestellt werden. Sobald ein alternativer Weg eingerichtet ist, können in der Warteschlange befindliche Daten zusammen mit nachfolgenden Daten erneut übertragen werden. Die vorliegend offenbarten Lehren detektieren und lösen somit nicht nur Netzausfälle viel schneller als viele bekannte Verfahren, die vorliegend offenbarten Beispiele erzielen auch zusätzliche Vorteile des Sicherstellens, dass keine Daten verloren gehen sondern ordnungsgemäß übermittelt werden.
Obwohl eine beispielhafte Weise des Implementierens des Host-Netzes 210 (entsprechend jedem der Arbeitsplätze 117, der Thin Clients 126, der Netz-Hosts 402, 404, 406 und/oder der Netz-Hosts 1002, 1004 von 1–2, 4, 6 und/oder 10–12) in 3 veranschaulicht ist, können eine oder mehrere in 3 veranschaulichte Elemente, Prozesse und/oder Geräte in 3 kombiniert, unterteilt, neu angeordnet, weggelassen, eliminiert und/oder auf jede andere Weise implementiert werden. Die beispielhafte erste Netzschnittstelle 302, die beispielhafte zweite Netzschnittstelle 304, der beispielhafte Integritätsnachrichtenanalysator 306, der beispielhafte Integritätstabellengenerator 308, der beispielhafte Integritätsnachrichtengenerator 310, der beispielhafte Kommunikationswegbestimmer 312, der beispielhafte Kommunikationsmanager 314, der beispielhafte Alarmmanager 316 und/oder allgemeiner der beispielhafte Netz-Host 210 von 3 können durch Hardware, Software, Firmware und/oder jede Kombination von Hardware, Software und/oder Firmware implementiert werden. Jede/r der beispielhaften ersten Netzschnittstelle 302, der beispielhaften zweiten Netzschnittstelle 304, des beispielhaften Integritätsnachrichtenanalysators 306, des beispielhaften Integritätstabellengenerators 308, des beispielhaften Integritätsnachrichtengenerators 310, des beispielhaften Kommunikationswegbestimmers 312, des beispielhaften Kommunikationsmanagers 314, des beispielhaften Alarmmanagers 316 und/oder allgemeiner des beispielhaften Netz-Hosts 210 könnte durch einen oder mehrere analoge oder digitale(n) Schaltkreis(e), logische Schaltkreise, programmierbare(n) Prozessor(en), applikationsspezifische(n) integrierte(n) Schaltkreis(e) (ASIC – application specific circuit), programmierbare(s) Logikgerät(e) (PLD – programmable logic device) und/oder feldprogrammierbare(s) Logikgerät(e) (FPLD – field programmable logic device) implementiert werden. Beim Lesen jedes der Vorrichtungs- oder Systemansprüche dieses Patents, die eine reine Software- und/oder Firmware-Implementierung abdecken sollen, ist/sind mindestens eine/r der beispielhaften ersten Netzschnittstelle 302, der beispielhaften zweiten Netzschnittstelle 304, des beispielhaften Integritätsnachrichtenanalysators 306, des beispielhaften Integritätstabellengenerators 308, des beispielhaften Integritätsnachrichtengenerators 310, des beispielhaften Kommunikationswegbestimmers 312, des beispielhaften Kommunikationsmanagers 314 und/oder des beispielhaften Alarmmanagers 316 hiermit ausdrücklich als ein greifbares computerlesbares Speichergerät oder eine Speicher-Disk, wie einen Speicher, eine digitale versatile Disk (DVD), eine Compact-Disk (CD), eine Blu-ray-Disk etc., die Software und/oder Firmware speichern, beinhaltend definiert. Der beispielhafte Netz-Host 210 von 3 kann darüber hinaus weiterhin ein oder mehrere Elemente, Prozesse und/oder Geräte zusätzlich zu oder anstatt denjenigen beinhalten, die in 3 veranschaulicht sind, und/oder kann mehr als eines/n oder alle der veranschaulichten Elemente, Prozesse und Geräte beinhalten.
Ein Ablaufdiagramm 1300, das repräsentativ für beispielhafte Verfahren zum Implementieren des Netz-Hosts 210 von 3 ist, wird in 13A und 13B gezeigt. In diesem Beispiel können die Verfahren unter Verwenden von maschinenlesbaren Anweisungen implementiert werden, die ein Programm zur Ausführung durch einen Prozessor umfassen können, wie der in der beispielhaften Prozessorplattform 1400 gezeigte und nachstehend in Verbindung mit 14 erörterte Prozessor 1412. Das Programm kann in auf einem greifbaren computerlesbaren Medium, wie einer CD-ROM, einer Floppy Disk, einer Festplatte, einer digitalen versatilen Disk (DVD), einer Blu-ray-Disk oder einem dem Prozessor 1412 zugeordneten Speicher gespeicherter Software ausgeführt werden, das ganze Programm und/oder Teile davon könnten jedoch alternativ durch ein anderes Gerät als den Prozessor 1412 ausgeführt werden und/oder in Firmware oder zweckgebundener Hardware ausgeführt werden. Obwohl das beispielhafte Programm weiterhin mit Bezug zu dem in 13A und 13B veranschaulichten Ablaufdiagramm beschrieben ist, können viele andere Verfahren zum Implementieren des beispielhaften Netz-Hosts 210 alternativ verwendet werden. Die Reihenfolge der Blocks kann zum Beispiel verändert werden und/oder einige der beschriebenen Blocks können geändert, eliminiert oder kombiniert werden.
Wie obenerwähnt, können die beispielhaften Prozesse von 13A und 13B unter Verwenden von kodierten Anweisungen (z.B. computer- und/oder maschinenlesbare Anweisungen) auf einem greifbaren computerlesbaren Speichermedium, wie einem Festplattenlaufwerk, einem Flash-Speicher, einem Nur-Lese-Speicher (ROM – read-only memory), einer Compact Disk (CD), einer digitalen versatilen Disk (DVD), einem Cache, einem Direktzugriffsspeicher (RAM – random-access memory) und/oder jeder Speichervorrichtung oder Speicherdisk, in welcher Informationen für jede beliebige Dauer (z.B. für längere Zeiträume, permanent, für kurze Augenblicke, zum zeitweisen Puffern und/oder zum Cachen der Informationen) gespeichert sind, implementiert sein. Im Sinne der vorliegenden Verwendung wird der Begriff greifbares computerlesbares Speichermedium ausdrücklich als jeden Typ von greifbarem computerlesbarem Speichermedium und/oder Speicherdisk beinhaltend definiert und als sich ausbreitende Signale und Übertragungsmedien ausschließend definiert. Im Sinne der vorliegenden Verwendung werden „greifbares computerlesbares Speichermedium“ und „greifbares maschinenlesbares Speichermedium“ austauschbar verwendet. Die beispielhaften Verfahren von 13A und 13B können zusätzlich oder alternativ unter Verwenden von kodierten Anweisungen (z.B. computer- und/oder maschinenlesbaren Anweisungen) implementiert werden, die auf einem nicht transitorischen computer- und/oder maschinenlesbaren Medium gespeichert sind, wie einem Festplattenlaufwerk, einem Flash-Speicher, einem Nur-Lese-Speicher, einer CD, einer digitalen versatilen Disk, einem Cache, einem Direktzugriffsspeicher und/oder jeder Speichervorrichtung oder Speicherdisk, in welcher Informationen für jede beliebige Dauer (z.B. für längere Zeiträume, permanent, für kurze Augenblicke, zum zeitweisen Puffern und/oder zum Cachen der Informationen) gespeichert sind. Im Sinne der vorliegenden Verwendung wird der Begriff nicht transitorisches computerlesbares Speichermedium ausdrücklich als jeden Typ von computerlesbarem Speichermedium und/oder Speicherdisk beinhaltend definiert und als sich ausbreitende Signale und Übertragungsmedien ausschließend definiert. Im Sinne der vorliegenden Verwendung ist die Verwendung des Ausdrucks „mindestens“ als der Übergangsbegriff in einer Präambel eines Anspruchs auf dieselbe Weise ein offener Begriff, wie der Begriff „umfassend“ ein offener Begriff ist.
Das beispielhafte Verfahren 1300 von 13A und 13B beginnt an Block 1302, wo der beispielhafte Integritätsnachrichtenanalysator 306 bestimmt, ob eine erwartete Integritätsnachricht von einem Netz-Host (z.B. einem anderen als dem Integritätsnachrichtenanalysator 306 zugeordneten Netz-Host) über eine spezifizierte Netzschnittstelle (z.B. jeder von den ersten oder zweiten Netzschnittstellen 302, 304) empfangen wird. Ob die spezifizierte Netzschnittstelle der ersten Netzschnittstelle 302 oder der zweiten Netzschnittstelle 304 entspricht, hängt davon ab, wie die Netz-Hosts jede der Netzschnittstellen jedes über zwei gemeinsame Netze verbundenen Netz-Hosts durchlaufen. In einigen Beispielen wird eine Integritätsnachricht basierend auf einem Schwellenwertzeitraum erwartet, ab welchem eine letzte Integritätsnachricht von derselben Netzschnittstelle empfangen wurde. In einigen Beispielen entspricht der Schwellenwertzeitraum der Dauer eines einzigen Zyklus durch jede der Netzschnittstellen. In anderen Beispielen ist der Schwellenwertzeitraum länger, wie zum Beispiel die Dauer der drei Zyklen durch jede der Netzschnittstellen.
Wenn der Integritätsnachrichtenanalysator 306 bestimmt, dass eine Integritätsnachricht empfangen wird (Block 1302), rückt die Steuerung zu Block 1304 vor, wo der beispielhafte Integritätsnachrichtenanalysator 306 bestimmt, ob die Integritätsnachricht von einem neuen Netz-Host ist. Der Integritätsnachrichtenanalysator 306 bestimmt solche (fehlendes Wort im Ausgangstext) basierend auf den in der Integritätsnachricht beinhalteten Host-Informationen. Wenn die Host-Informationen einen Netz-Host identifizieren, von welchem der Nachrichtenanalysator 306 zuvor keine Integritätsnachricht empfangen hat, bestimmt der Integritätsnachrichtenanalysator 306 den Netz-Host als neu. Wenn der Integritätsnachrichtenanalysator 306 bestimmt, dass der Netz-Host neu ist (Block 1304), rückt die Steuerung zu Block 1306 vor, wo der beispielhafte Integritätsnachrichtenanalysator 306 einen neuen Eintrag für den neuen Netz-Host in einer IP-Routingtabelle erzeugt. An Block 1307 erzeugt der beispielhafte Integritätstabellengenerator 308 einen Eintrag in einer Integritätstabelle für den neuen Netz-Host. An Block 1308 stellt der beispielhafte Integritätstabellengenerator 308 eine Indikation eines Kommunikationsstatus mit dem Netz-Host über die spezifizierte Netzschnittstelle innerhalb der Integritätstabelle auf gut ein. Das heißt, weil eine Integritätsnachricht empfangen wurde (wie an Block 1302 bestimmt), wird die Verbindung mit dem Host-Netz, das die Integritätsnachricht überträgt, als gut bestätigt und die Integritätstabelle wird demgemäß eingepflegt. Nochmals in Bezug zu Block 1304 rückt die Steuerung direkt zu Block 1308 vor, wenn der Integritätsnachrichtenanalysator 306 bestimmt, dass der Netz-Host nicht neu ist.
An Block 1309 bestimmt der beispielhafte Kommunikationswegbestimmer 312, ob der (an Block 1330 wie nachstehend beschrieben eingestellte) Kommunikationsstatus zuvor schlecht war. Ist das der Fall, rückt die Steuerung zu Block 1310 vor, wo der beispielhafte Kommunikationswegbestimmer den direkten Kommunikationsweg (von dem nachstehend beschriebenen alternativen an Block 1338 eingerichteten Kommunikationsweg) auf die spezifizierte Netzschnittstelle des Netz-Hosts erneut eingerichtet hat. Das heißt, wenn der Kommunikationsstatus zwischen der spezifizierten Netzschnittstelle und dem Netz-Host schlecht war aber nun als gut angegeben wird (d.h. die Netzverbindung wurde gerade repariert), kann der Kommunikationswegbestimmer 312 die direkten Kommunikationen zwischen der spezifizierten Netzschnittstelle und dem Netz-Host, von welchem die Integritätsnachricht empfangen wurde, wieder herstellen. In einigen Beispielen richtet der Kommunikationswegbestimmer 312 den direkten Kommunikationsweg durch Aktualisieren der der spezifizierten Netzschnittstelle zugeordneten IP-Routinginformationen erneut ein, um die direkte Übertragung mit anderen Netz-Hosts zu ermöglichen. An Block 1311 entfernt der beispielhafte Alarmmanager 316 eine (an Block 1332 wie nachstehend erzeugte) Warnung und protokolliert die Netzrückgewinnung. Die Steuerung rückt dann zu Block 1312 vor. Nochmals in Bezug zu Block 1309 rückt die Steuerung direkt zu Block 1312 vor, wenn der beispielhafte Kommunikationswegbestimmer 312 bestimmt, dass der Kommunikationsstatus zuvor nicht schlecht war.
An Block 1312 überträgt der beispielhafte Kommunikationsmanager 314 die Prozesssteuerungsdaten an den Netz-Host direkt über die spezifizierte Netzschnittstelle. Das heißt, die Prozesssteuerungsdaten werden direkt von den entsprechenden Netzschnittstellen über das zugeordnete Netz übertragen, weil die Kommunikationen über diesen Weg als gut bestimmt wurden.
An Block 1314 bestimmt der beispielhafte Kommunikationsmanager 314, ob eine Integritätsnachricht über die erste Netzschnittstelle 302 zu übertragen ist. Ist dies der Fall, rückt die Steuerung zu Block 1316 vor, wo der beispielhafte Integritätsnachrichtengenerator 310 eine Integritätsnachricht generiert. In einigen Beispielen beinhaltet die Integritätsnachricht Host-Informationen, die die IP-Adressen der ersten und zweiten Netzschnittstellen 302, 304 identifizieren. In einigen Beispielen beinhaltet die Integritätsnachricht zusätzlich Integritätsinformationen, die den Kommunikationsstatus zwischen jeder von den Netzschnittstellen 302, 304 und die entsprechenden Netzschnittstellen von anderen Netz-Hosts angeben. An Block 1318 überträgt der beispielhafte Kommunikationsmanager 314 die Integritätsnachricht an die anderen Netz-Hosts über die erste Netzschnittstelle 302. Die Steuerung rückt dann zu Block 1326 vor, um zu bestimmen, ob das beispielhafte Verfahren von 13A und 13B fortzuführen ist. Ist das der Fall, kehrt die Steuerung zu Block 1302 zurück, um den Prozess mit einer nachfolgend empfangenen Integritätsnachricht zu wiederholen. Ansonsten endet das beispielhafte Verfahren von 13A und 13B.
Nochmals in Bezug zu Block 1314 rückt die Steuerung zu Block 1320 vor, wenn der beispielhafte Kommunikationsmanager 314 bestimmt, eine Integritätsnachricht nicht über die erste Netzschnittstelle 302 zu übertragen. An Block 1320 bestimmt der beispielhafte Kommunikationsmanager 314, ob eine Integritätsnachricht über die zweite Netzschnittstelle 304 zu übertragen ist. Wenn der beispielhafte Kommunikationsmanager 314 bestimmt, eine Integritätsnachricht nicht über die zweite Netzschnittstelle 304 zu übertragen, kehrt die Steuerung zu Block 1302 zurück. Wenn der beispielhafte Kommunikationsmanager 314 bestimmt, eine Integritätsnachricht über die zweite Netzschnittstelle 304 zu übertragen, rückt die Steuerung zu Block 1322 vor, wo der beispielhafte Integritätsnachrichtengenerator 310 eine Integritätsnachricht generiert. An Block 1324 überträgt der beispielhafte Kommunikationsmanager 314 die Integritätsnachricht an die anderen Netz-Hosts über die zweite Netzschnittstelle 304. Die Steuerung rückt dann zu Block 1326 vor, um zu bestimmen, ob zu Block 1302 zurückzukehren ist, um das Verfahren zu wiederholen oder das beispielhafte Verfahren zu beenden.
Nochmals in Bezug zu Block 1302 rückt die Steuerung zu Block 1328 vor, wo der beispielhafte Integritätsnachrichtenanalysator 306 bestimmt, ob der Schwellenwertzeitraum seit Empfang der letzten Integritätsnachricht von der spezifizierten Netzschnittstelle überschritten wurde, wenn der Integritätsnachrichtenanalysator 306 bestimmt, dass eine erwartete Integritätsnachricht nicht empfangen wurde. Wenn der Schwellenwertzeitraum nicht überschritten wurde, kehrt die Steuerung zu Block 1312 zurück, um die Prozesssteuerungsdaten zu übertragen. Wenn der Schwellenwertzeitraum überschritten wurde, rückt die Steuerung zu Block 1330 vor. An Block 1330 stellt der beispielhafte Integritätstabellengenerator 308 die Indikation des Kommunikationsstatus mit dem Netz-Host über die spezifizierte Netzschnittstelle innerhalb der Integritätstabelle auf schlecht ein. An Block 1332 generiert der beispielhafte Alarmmanager 316 eine Warnung und protokolliert den Netzausfall. In einigen Beispielen wird die Warnung an einen Nutzer (z.B. einen Bediener) bereitgestellt, um anzugeben, dass der Netzausfall eingetreten ist.
An Block 1334 bestimmt der beispielhafte Kommunikationswegbestimmer 312, ob ein alternativer Kommunikationsweg eingerichtet wurde (z.B. während einer vorherigen Iteration des beispielhaften Verfahrens). Ist dies der Fall, rückt die Steuerung direkt zu Block 1342 vor, wie nachstehend beschrieben. Wenn der beispielhafte Kommunikationswegbestimmer 312 bestimmt, dass ein alternativer Kommunikationsweg nicht eingerichtet worden ist, rückt die Steuerung zu Block 1336 vor. An Block 1336 speichert der beispielhafte Kommunikationsmanager 314 ausgefallene Prozesssteuerungsdatenkommunikationen, die an den Netz-Host (z.B. an Block 1312) gesendet wurden, in einer Warteschlange zur erneuten Übertragung. An Block 1338 richtet der beispielhafte Kommunikationswegbestimmer 312 einen alternativen Kommunikationsweg zu der spezifizierten Netzschnittstelle des Netz-Hosts ein. In einigen Beispielen ist der alternative Weg auf das örtliche Routing innerhalb jedes der Quellennetz-Hosts und dem Zielnetz-Host zwischen den ersten und zweiten Netzschnittstellen 302, 304 angewiesen. In solchen Beispielen wird der Weg als das der Netzschnittstelle zugeordnete Netz mit Ausnahme der spezifizierten Netzschnittstelle übergehend definiert.
Sobald der alternative Kommunikationsweg eingerichtet ist (Block 1338), überträgt der beispielhafte Kommunikationsmanager 314 an Block 1340 die Prozesssteuerungsdatenkommunikationen in der Warteschlange an den Netz-Host erneut über den alternativen Kommunikationsweg. An Block 1342 überträgt der beispielhafte Kommunikationsmanager 314 Prozesssteuerungsdaten (z.B. andere Daten, als die zuvor in die Warteschlange gestellten) an den Netz-Host über den alternativen Kommunikationsweg. Die Steuerung rückt dann zu Block 1314 vor, um mit dem wie oben beschriebenen beispielhaften Verfahren fortzufahren.
14 ist ein Blockdiagramm einer beispielhaften Prozessorplattform 1400, die in der Lage ist, Anweisungen auszuführen, um die Verfahren von 13A und 13B durchzuführen, um den Netz-Host 210 von 3 zu implementieren. Die Prozessorplattform 1400 kann zum Beispiel ein Server, ein PC, ein Mobilgerät (z.B. ein Mobiltelefon, ein Smartphone, ein Tablet wie ein iPad^TM), ein persönlicher digitaler Assistent (PDA), ein Internetgerät, ein DVD-Player, ein CD-Player oder jeder andere Typ von Rechnergerät sein.
Die Prozessorplattform 1400 des veranschaulichten Beispiels beinhaltet einen Prozessor 1412. Der Prozessor 1412 des veranschaulichten Beispiels ist Hardware. Der Prozessor 1412 kann zum Beispiel durch eine oder mehrere integrierte Schaltkreise, Logikschaltkreise, Mikroprozessoren oder Regler von jeder/m erwünschten Familie oder Hersteller implementiert werden.
Der Prozessor 1412 des veranschaulichten Beispiels beinhaltet einen örtlichen Speicher 1413 (z.B. einen Cache). Der Prozessor 1412 des veranschaulichten Beispiels ist über einen Bus 1418 in Kommunikation mit einem Hauptspeicher, einschließlich einem flüchtigen Speicher 1414 und einem nicht flüchtigen Speicher 1416. Der flüchtige Speicher 1414 kann durch Schreib-Lesespeicher mit doppelter Datenübertragungsrate (SDRAM – Synchronous Dynamic Random Access Memory), dynamische Direktzugriffsspeicher (DRAM – Dynamic Random Access Memory), dynamische RAMBUS-Direktzugriffspeicher (RDRAM – RAMBUS Dynamic Random Access Memory) und/oder jeden anderen Typ von Direktzugriffsspeichergerät implementiert sein. Der nicht flüchtige Speicher 1416 kann durch Flash-Speicher und/oder jeden anderen gewünschten Typ von Speichergerät implementiert sein. Der Zugriff auf den Hauptspeicher 1414, 1416 wird durch einen Speicherregler gesteuert.
Die Prozessorplattform 1400 des veranschaulichten Beispiels beinhaltet auch einen Schnittstellenschaltkreis 1420. Der Schnittstellenschaltkreis 1420 kann durch jeden Typ von Schnittstellenstandard implementiert sein, wie eine Ethernet-Schnittstelle, einen universeller Serienbus (USB) und/oder eine PCI-Express-Schnittstelle.
In dem veranschaulichten Beispiel sind eine oder mehrere Eingabegeräte 1422 mit dem Schnittstellenschaltkreis 1420 verbunden. Das/die Eingabegerät/e 1422 erlaubt/erlauben einem Nutzer, Daten und Befehle in den Prozessor 1412 einzugeben. Das/die Eingabegerät/e kann/können zum Beispiel durch einen Audiosensor, ein Mikrofon, eine Kamera (Foto oder Video), eine Tastatur, eine Schaltfläche, eine Maus, einen Berührungsbildschirm, einen Track-Pad, einen Trackball, Isopoint und/oder ein anderes Stimmenerkennungssystem implementiert werden.
Ein oder mehrere Ausgabegeräte 1424 sind auch mit dem Schnittstellenschaltkreis 1420 des veranschaulichten Beispiels verbunden. Die Ausgabegeräte 1424 können zum Beispiel durch Anzeigegeräte (z.B. eine lichtemittierende Diode (LED), eine organisches Licht emittierend Diode (OLED), eine Flüssigkristallanzeige, eine Kathodenstrahlröhrenanzeige (CRT – cathode ray tube display), einen Berührungsbildschirm, ein taktiles Ausgabegerät, eine Licht emittierende Diode (LED), einen Drucker und/oder Lautsprecher) implementiert werden. Der Schnittstellenschaltkreis 1420 des veranschaulichten Beispiels beinhaltet somit typischerweise eine grafische Driver-Karte, einen grafischen Driver-Chip oder einen grafischen Driver-Prozessor.
Der Schnittstellenschaltkreis 1420 des veranschaulichten Beispiels beinhaltet auch ein Kommunikationsgerät, wie einen Sender, einen Empfänger, einen Sende-Empfänger, ein Modem und/oder eine Netzschnittstellenkarte, um den Austausch von Daten mit externen Maschinen (z.B. Rechnergeräte jeder Art) über ein Netz 1426 (z.B. eine Ethernet-Verbindung, eine digitale Teilnehmeranschlussleitung (DSL – digital subscriber line), eine Telefonleitung, ein Koaxialkabel, ein Mobiltelefonsystem etc.) zu unterstützen.
Die Prozessorplattform 1400 des veranschaulichten Beispiels beinhaltet auch ein oder mehrere Massenspeichergeräte 1428 zum Speichern von Software und/oder Daten. Beispiele solcher Massenspeichergeräte 1428 beinhalten Diskettenlaufwerke, Festplattenlaufwerke, CD-Laufwerke, Blu-ray-Disk-Laufwerke, RAID-Systeme und digitale versatile Disk(DVD)-Laufwerke.
Kodierte Anweisungen 1432 zur Implementierung der Verfahren von 13A und 13B können in dem Massenspeichergerät 1428, in dem flüchtigen Speicher 1414, in dem nicht flüchtigen Speicher 1416 und/oder auf einem entfernbaren greifbaren computerlesbaren Speichermedium, wie einer CD oder DVD, gespeichert werden.
Aus dem Vorstehenden ist ersichtlich, dass die oben offenbarten Verfahren, Vorrichtungen und Herstellungsartikel eine Reihe von Vorteilen im Gegensatz zu bestehenden Redundanz-Schemata bereitstellen, die in Prozesssteuerungssystemen (unabhängig davon, ob sie physisch und/oder virtuell implementiert werden) verwendet werden. Die vorliegend offenbarten Beispiele sind insbesondere nicht auf die dem Erwerben Konfigurieren und/oder Warten von externer Hardware zur Unterstützung der Redundanz zugeordneten Kosten und/oder Komplexität angewiesen. Die vorliegend offenbarten Beispiele überwachen zusätzlich fortlaufend die Integrität der Kommunikationsnetze, um viel schneller als andere bestehende Verfahren Ausfälle zu detektieren und alternative Kommunikationswege als Antwort auf solche Ausfälle einzurichten. Die vorliegend offenbarten Beispiele stellen darüber hinaus die Netzkonnektivität in einer für die Ermöglichung der erneuten Übertragung von Daten nach einem Netzausfall ausreichenden Zeit wieder her, sodass keine Daten verloren gehen. Obwohl es einige bekannte Ansätze gibt, die verlässliche Verbindungen ohne den Verlust von Daten aufgrund eines Netzausfalls bereitstellen, indem alle Daten zweimal über getrennte Netze gesendet werden, vermeiden die vorliegend offenbarten Beispiele das Bedürfnis zur Auferlegung solch einer zusätzlichen Last auf die Netze, wodurch mehr Daten übertragen werden können und/oder dies zu schnelleren Geschwindigkeiten ermöglicht wird.
Obwohl bestimmte beispielhafte Verfahren, Vorrichtungen und Herstellungsartikel vorliegend offenbart wurden, ist der Geltungsbereich der Deckung dieses Patents darauf nicht beschränkt. Im Gegenteil, dieses Patent deckt alle Verfahren, Vorrichtungen und Herstellungsartikel ab, die angemessenerweise innerhalb des Geltungsbereichs der Ansprühe dieses Patents fallen.

Claims

Verfahren umfassend: das Empfangen erster Integritätsnachrichten, die von einem zweiten Netz-Host über ein erstes Netz übertragen wurden, an einem ersten Netz-Host; das Detektieren, an dem ersten Netz-Host, eines Netzausfalls über einen ersten Kommunikationsweg zwischen einer ersten Netzschnittstelle des ersten Netz-Hosts und einer zweiten Netzschnittstelle des zweiten Netz-Hosts über das erste Netz, wenn die erste Netzschnittstelle des ersten Netz-Hosts eine von den ersten Integritätsnachrichten, die von der ersten Netzschnittstelle des zweiten Netz-Hosts erwartet wird, nicht empfängt; und das automatische Einrichten eines zweiten Kommunikationswegs zwischen der ersten Netzschnittstelle des ersten Netz-Hosts und der ersten Netzschnittstelle des zweiten Netz-Hosts als Antwort auf den detektierten Netzausfall.
Verfahren nach Anspruch 1, wobei der zweite Kommunikationsweg das zweite Netz über die zweite Netzschnittstelle des ersten Netz-Hosts und die zweite Netzschnittstelle des zweiten Netz-Hosts umfasst; genanntes Verfahren weiterhin umfassend das Definieren der zweiten Netzschnittstelle des ersten Netz-Hosts als ein Gateway für die erste Netzschnittstelle des ersten Netz-Hosts, um zu ermöglichen, dass Daten von der ersten Netzschnittstelle des ersten Netz-Hosts zu der zweiten Netzschnittstelle des ersten Netz-Hosts geroutet werden.
Verfahren nach Anspruch 1 oder 2, weiterhin umfassend das Empfangen, an einem ersten Netz-Host, zweiter Integritätsnachrichten, die von dem zweiten Netz-Host über das zweite Netz übertragen wurden, wobei jede der ersten Integritätsnachrichten und der zweiten Integritätsnachrichten Host-Informationen umfasst, die den zweiten Netz-Host und die ersten und zweiten Netzschnittstellen des zweiten Netz-Hosts identifizieren.
Verfahren nach Anspruch 3, weiterhin umfassend: das Detektieren, an dem ersten Netz-Host, des zweiten Netz-Hosts an dem ersten Netz basierend auf den in einer von den ersten Integritätsnachrichten beinhalteten Host-Informationen; und das Erzeugen einer Eintragung in einer Routingtabelle, um den ersten Kommunikationsweg von der ersten Netzschnittstelle des ersten Netz-Hosts zu der ersten Netzschnittstelle des zweiten Netz-Hosts zu definieren.
Verfahren nach Anspruch 3 oder 4, wobei jede der ersten Integritätsnachrichten und der zweiten Integritätsnachrichten Integritätsinformationen umfasst, die einen zwischen dem zweiten Netz-Host und dem ersten Netz-Host über jedes von dem ersten Netz und dem zweiten Netz über die entsprechenden ersten und zweiten Netzschnittstellen bestimmten Kommunikationsstatus angeben, wobei die Integritätsinformationen weiterhin einen zwischen dem zweiten Netz-Host und anderen Netz-Hosts, die kommunikativ an die ersten und zweiten Netz-Hosts über das erste und zweite Netz gekoppelt sind, bestimmten Kommunikationsstatus angeben.
Verfahren nach einem der Ansprüche 3 bis 5, weiterhin umfassend: das Übertragen dritter Integritätsnachrichten von dem ersten Netz-Host über das erste Netz; und das Übertragen vierter Integritätsnachrichten von dem ersten Netz-Host über das zweite Netz, wobei sowohl die dritte Integritätsnachricht als auch die vierte Integritätsnachricht einen Netzausfall zwischen der ersten Netzschnittstelle des ersten Netz-Hosts und der ersten Netzschnittstelle des zweiten Netz-Hosts über das erste Netz als Antwort auf den detektierten Netzausfall angeben.
Verfahren nach einem der Ansprüche 1 bis 6, weiterhin umfassend: das Generieren von mindesten einem von einem Ereignis, einer Warnung oder einem Alarm als Antwort auf den detektierten Netzausfall; und das Protokollieren von mindestens einem von dem Ereignis, der Warnung oder dem Alarm, wobei das mindestens eine von dem Ereignis, der Warnung oder dem Alarm Informationen umfasst, die die erste Netzschnittstelle des ersten Netz-Hosts und die erste Netzschnittstelle des zweiten Netz-Hosts identifizieren.
Greifbares computerlesbares Speichermedium, umfassend Anweisungen, die bei Ausführung einen ersten Netz-Host dazu veranlassen, mindestens: erste von einem zweiten Netz-Host über ein erstes Netz übertragene Integritätsnachrichten zu empfangen; einen Netzausfall über einen ersten Kommunikationsweg zwischen einer ersten Netzschnittstelle des ersten Netz-Hosts und einer ersten Netzschnittstelle eines zweiten Netz-Hosts über das erste Netz zu detektieren, wenn die erste Netzschnittstelle des ersten Netz-Hosts eine der ersten von der ersten Netzschnittstelle des zweiten Netz-Hosts erwartete Integritätsnachricht nicht empfängt; und automatisch einen zweiten Kommunikationsweg zwischen der ersten Netzschnittstelle des ersten Netz-Hosts und der ersten Netzschnittstelle des zweiten Netz-Hosts als Antwort auf den detektierten Netzausfall einzurichten.
Speichermedium nach Anspruch 8, wobei der zweite Kommunikationsweg das zweite Netz über die zweite Netzschnittstelle des ersten Netz-Hosts und die zweite Netzschnittstelle des zweiten Netz-Hosts umfasst, wobei die Anweisungen bei Ausführung weiterhin den ersten Netz-Host dazu veranlassen, die zweite Netzschnittstelle des ersten Netz-Hosts als ein Gateway für die erste Netzschnittstelle des ersten Netz-Hosts zu definieren, um zu ermöglichen, dass Daten von der ersten Netzschnittstelle des ersten Netz-Hosts zu der zweiten Netzschnittstelle des ersten Netz-Hosts geroutet werden.
Speichermedium nach Anspruch 8 oder 9, wobei die Anweisungen bei Ausführung weiterhin den ersten Netz-Host dazu veranlassen, zweite Integritätsnachrichten, die von dem zweiten Netz-Host über das zweite Netz übertragen werden, zu empfangen.
Speichermedium nach Anspruch 10, wobei jede der ersten Integritätsnachrichten und der zweiten Integritätsnachrichten Host-Informationen umfasst, die den zweiten Netz-Host und die erste und zweite Netzschnittstelle des zweiten Netz-Hosts identifizieren, wobei die Anweisungen bei Ausführung weiterhin den ersten Netz-Host dazu veranlassen: den zweiten Netz-Host an dem ersten Netz basierend auf den in einer von den ersten Integritätsnachrichten beinhalteten Host-Informationen zu detektieren; und einen Eintrag in einer Routing-Tabelle zu erzeugen, um den ersten Kommunikationsweg von der ersten Netzschnittstelle des ersten Netz-Hosts zu der ersten Netzschnittstelle des zweiten Netz-Hosts zu definieren; und/oder wobei jede von den ersten Integritätsnachrichten und den zweiten Integritätsnachrichten Integritätsinformationen umfasst, die einen zwischen dem zweiten Netz-Host und dem ersten Netz-Host über jedes von dem ersten Netz und dem zweiten Netz über die entsprechenden ersten und zweiten Netzschnittstellen bestimmten Kommunikationsstatus angeben, wobei die Integritätsinformationen weiterhin einen zwischen dem zweiten Netz-Host und anderen kommunikativ mit den ersten und zweiten Netz-Hosts über die ersten und zweiten Netze gekoppelten Netz-Hosts bestimmten Kommunikationsstatus angeben; und/oder wobei die Anweisungen bei Ausführung weiterhin den ersten Netz-Host dazu veranlassen: dritte Integritätsnachrichten über das erste Netz zu übertragen; und vierte Integritätsnachrichten über das zweite Netz zu übertragen, wobei sowohl die dritten Integritätsnachrichten als auch die vierten Integritätsnachrichten einen Netzausfall zwischen der ersten Netzschnittstelle des ersten Netz-Hosts und der ersten Netzschnittstelle des zweiten Netz-Hosts über das erste Netz als Antwort auf den detektierten Netzausfall angeben.
Speichermedium nach einem der Ansprüche 8 bis 11, wobei die Anweisungen bei Ausführung weiterhin den ersten Netz-Host dazu veranlassen: mindestens eines von einem Ereignis, einer Warnung oder einem Alarm als Antwort auf den detektierten Netzausfall zu generieren; und mindestens eines von einem Ereignis, einer Warnung oder einem Alarm zu protokollieren, wobei das mindestens eine von dem Ereignis, der Warnung oder dem Alarm Informationen umfasst, die die erste Netzschnittstelle des ersten Netz-Hosts und die zweite Netzschnittstelle des zweiten Netz-Hosts identifizieren.
System umfassend einen ersten Netz-Host, der einen Prozessor und einen Speicher beinhaltet, wobei der Prozessor auf dem Speicher gespeicherte Anweisungen auszuführen hat, um: erste Integritätsnachrichten zu empfangen, die von einem zweiten Netz-Host über ein erstes Netz übertragen wurden; einen Netzausfall über einen ersten Kommunikationsweg zwischen einer ersten Netzschnittstelle des ersten Netz-Hosts und einer ersten Netzschnittstelle eines zweiten Netz-Hosts über das erste Netz zu detektieren, wenn die erste Netzschnittstelle des ersten Netz-Hosts eine von den ersten von der ersten Netzschnittstelle des zweiten Netz-Hosts erwarteten Integritätsnachrichten nicht empfängt; und automatisch einen zweiten Kommunikationsweg zwischen der ersten Netzschnittstelle des ersten Netz-Hosts und der ersten Netzschnittstelle des zweiten Netz-Hosts als Antwort auf den detektierten Netzausfall einzurichten.
System nach Anspruch 13, wobei der zweite Kommunikationsweg das zweite Netz über die zweite Netzschnittstelle des ersten Netz-Hosts und die zweite Netzschnittstelle des zweiten Netz-Hosts umfasst, wobei die Anweisungen bei Ausführung weiterhin den ersten Netz-Host dazu veranlassen, die zweite Netzschnittstelle des ersten Netz-Hosts als ein Gateway für die erste Netzschnittstelle des ersten Netz-Hosts zu definieren, um zu ermöglichen, dass Daten von der ersten Netzschnittstelle des ersten Netz-Hosts zu der zweiten Netzschnittstelle des ersten Netz-Hosts geroutet werden.
System nach Anspruch 13 oder 14, wobei die Anweisungen bei Ausführung weiterhin den ersten Netz-Host dazu veranlassen, von dem zweiten Netz-Host über das zweite Netz übertragene zweite Integritätsnachrichten zu empfangen.
System nach Anspruch 15, wobei jede der ersten Integritätsnachrichten und der zweiten Integritätsnachrichten Host-Informationen umfasst, die den zweiten Netz-Host und die ersten und zweiten Netzschnittstellen des zweiten Netz-Hosts identifizieren, wobei die Anweisungen bei Ausführung weiterhin den ersten Netz-Host dazu veranlassen: den zweiten Netz-Host an dem ersten Netz basierend auf den Host-Informationen zu detektieren, die in einer von den ersten Integritätsnachrichten beinhaltet sind; und einen Eintrag in einer Routing-Tabelle zu erzeugen, um den ersten Kommunikationsweg von der ersten Netzschnittstelle des ersten Netz-Hosts zu der ersten Netzschnittstelle des zweiten Netz-Hosts zu definieren; und/oder wobei jede der ersten Integritätsnachrichten und der zweiten Integritätsnachrichten Integritätsinformationen umfasst, die einen zwischen dem zweiten Netz-Host und dem ersten Netz-Host über jedes von dem ersten Netz und dem zweiten Netz über die entsprechenden ersten und zweiten Netzschnittstellen bestimmten Kommunikationsstatus angeben, wobei die Integritätsinformationen weiterhin einen zwischen dem zweiten Netz-Host und anderen kommunikativ mit den ersten und zweiten Netz-Hosts über die ersten und zweiten Netze gekoppelten Netz-Hosts bestimmten Kommunikationsstatus angeben; und/oder wobei die Anweisungen bei Ausführung weiterhin den ersten Netz-Host dazu veranlassen: dritte Integritätsnachrichten über das erste Netz zu übertragen; und vierte Integritätsnachrichten über das zweite Netz zu übertragen, wobei sowohl die dritten Integritätsnachrichten als auch die vierten Integritätsnachrichten einen Netzausfall zwischen der ersten Netzschnittstelle des ersten Netz-Hosts und der ersten Netzschnittstelle des zweiten Netz-Hosts über das erste Netz als Antwort auf den detektieren Netzausfall angeben.
System nach einem der Ansprüche 13 bis 16, wobei die Anweisungen bei Ausführung weiterhin den ersten Netz-Host dazu veranlassen: mindestens eines von einem Ereignis, einer Warnung oder einem Alarm als Antwort auf den detektierten Netzausfall zu generieren; und mindestens eines von dem Ereignis, der Warnung oder dem Alarm zu protokollieren, wobei das mindestens eine von dem Ereignis, der Warnung oder dem Alarm Informationen umfasst, die die erste Netzschnittstelle des ersten Netz-Hosts und die erste Netzschnittstelle des zweiten Netz-Hosts identifizieren.