DE69931052T2

DE69931052T2 - Middleware-basiertes echtzeit-kommunikationssystem

Info

Publication number: DE69931052T2
Application number: DE69931052T
Authority: DE
Inventors: Jiandong Plymouth HUANG; Donghui Chen
Original assignee: Honeywell Inc
Current assignee: Honeywell Inc
Priority date: 1998-07-10
Filing date: 1999-06-22
Publication date: 2006-11-02
Anticipated expiration: 2019-06-23
Also published as: DE69931052D1; US6483846B1; CA2336829A1; WO2000003521A1; JP2002520950A; EP1097551B1; EP1097551A1

Description

Ein Teil der Offenbarung dieser Patentschrift enthält Material, das dem Urheberrechtsschutz unterliegt. Der Inhaber des Urheberrechts hat keine Einwände gegen die Faksimile-Reproduktion der Patentoffenbarung, wie sie in den Patentakten oder -aufzeichnungen des Patent- und Warenzeichenamts aufliegt, durch irgendjemanden, behält sich aber anderweitig alle Urheberrechte vor.
GEBIET DER ERFINDUNG
Die Erfindung betrifft Netzdatenübertragungen und insbesondere einen Middleware-Ansatz zur Realisierung von Echtzeit-Ethernet.
ALLGEMEINER STAND DER TECHNIK
Rechnernetze haben sich in der Geschäfts- und Industriewelt weit verbreitet. Sie können verwendet werden, um mehrfache Rechner innerhalb eines Standorts oder über mehrfache Anlagen zu verbinden.
Das Netz stellt einen Übertragungskanal zur Übertragung von Daten oder Verkehr von einem Rechner zu einem anderen bereit. Netzverwendungen sind unbegrenzt und können einfache Daten- oder Dateitransfers, Fernaudio oder Fernvideo, Multimediakonferenzen, industrielle Steuerungen und mehr aufweisen.
Das vielleicht am weitesten verbreitete Netzprotokoll ist Ethernet, eine lokale Netzspezifikation für Hochgeschwindigkeitsübertragungen von Endgerät zu Rechner oder Dateitransfers von Rechner zu Rechner. Das Ethernet-Übertragungsprotokoll erlaubt und adaptiert Datentransfers über einen Datenübertragungskanal oder -bus, normalerweise ein verdrilltes Paar oder ein koaxiales Kabel.
Das Ethernet-Übertragungsprotokoll wurde als der IEEE-Standard 802.3 für Übertragungen über ein lokales Netz (LAN) standardisiert. Dieses Protokoll umfasst ein 1-peristentes Vielfachzugriffsprotokoll mit Trägerkennung und Kollisionserkennung (CSMA/CD für engl. Carrier Sense Multiple Access with Collision Detection), was bedeutet, dass ein oder mehr Knoten eines gemeinsamen benutzten Netzes den Kanal überwachen können, wenn sie ein Datenpaket zu übertragen haben, und dass sie dieses Paket senden können, unmittelbar nachdem sie erkannt haben, dass der Kanal unbelegt ist.
Eine „Kollision" von Datenpaketen kann eintreten, wenn zwei oder mehr Knoten beginnen, gleichzeitig auf dem Netz zu übertragen. Kollidierende Knoten erkennen solch eine Kollision von Daten und beenden ihre Übertragung, wobei sie eine zufällig festgelegte Zeitspanne abwarten, bevor sie erneut eine Übertragung versuchen. Gemäß den aktuellen Standards wird ein Misserfolg erzeugt, nachdem ein Knoten sechs erfolglose Versuche gemacht hat, sein Datenpaket ohne Kollision zu übertragen.
Unter Bedingungen schwacher Belastung sind Kollisionen selten, und die Auflösung erfolgt schnell. Starke Belastungen können jedoch zu unbestimmten Zugriffszeiten führen. Obwohl einige Anwendungen verhältnismäßig unempfindlich für Kollisionen und ihre resultierenden Verzögerungen beim Datentransfer sind, können andere Anwendungen zeitempfindlich sein, derart dass Kollisionen von Daten unerwünscht oder sogar unannehmbar sind. Beispiele für solche zeitempfindlichen oder Echtzeitanwendungen können Fernvideo oder die Steuerung von industriellen Produktionsanlagen aufweisen. Das Erfordernis für einige Anwendungen, Kollisionen zu umgehen und eine erfolgreiche Sendung und einen erfolgreichen Empfang zu gewährleisten, führte zu verschiedenen Verbesserungen am Ethernet.
Eine Ethernet-Verbesserung ist ein tokenbasiertes Protokoll, das unter IEEE 802.4 (Token-Bus) oder 802.5 (Token-Ring) standardisiert wurde. Der Hauptunterschied zwischen diesen beiden Standards liegt in der Netztopologie, an die sie bestimmungsgemäß gerichtet sind. Der Token-Bus ist an ein Netz gerichtet, in welchem die Knoten einen logischen Ring bilden; der Token-Ring ist an ein Netz gerichtet, in welchem die Knoten einen physikalischen Ring bilden.
Tokenbasierte Protokolle erzeugen ein „Token", das an jeden Knoten entlang des Netzes weitergeleitet wird. Diese Protokolle ermöglichen eine Datenübertragung nur dann, wenn der Knoten im Besitz eines Tokens ist, und jedem Knoten wird eine festgesetzte Zeitdauer gewährt, um Daten zu übertragen. Die Übertragungszeit wird in mehrfache Segmente oder Zeitgeber in Zusammenhang mit verschiedenen Prioritätsstufen weiter unterteilt. Diese Prioritätsstufen können verschiedenen Datenströmen in Abhängigkeit von ihrer Kritikalität und Zeitempfindlichkeit zugeordnet werden. Die Knoten können während ihres jeweiligen Zeitgebers nur Daten einer bestimmten Prioritätsstufe übertragen. Gemäß diesem Ansatz kann Echtzeitdaten ein Teil der Bandbreite frei von Kollision zugesichert werden. Einige dieser tokenbasierten Protokolle erlauben einem bestimmten Knoten jedoch möglicherweise nur seinen festgesetzten Anteil an Bandbreite, ungeachtet dessen, ob andere Knoten vollen oder überhaupt Gebrauch von ihrer Bandbreite machen.
Verbesserungen an diesen tokenbasierten Protokollen wurden ebenfalls vorgeschlagen. Als ein Beispiel wurde ein akademischer Prototyp für ein softwareorientiertes Echtzeit-Ethernet vorgeschlagen, das auf einer UNIX-Plattform unter Verwendung eines tokenbasierten Protokolls realisiert wurde (siehe Chitra Venkatramani, „The Design, Implementation and Evaluation of RETHER: A Real-Time Ethernet Protocol", Ph.D. Dissertation, State University of New York, Januar 1997). Das RETHER sorgt jedoch nur für einen Nichtechtzeitverkehr, wenn es keinen Echtzeitverkehr mehr durch irgendeinen Knoten zu senden gibt. In Abhängigkeit von der Art von Verkehr auf dem Netz führte dies zu einem niedrigen Netzdurchsatz und einer geringen Ausnutzung infolge eines Tokenübergabeoverheads für Nichtechtzeitverkehr und unterstützte harten Echtzeitverkehr nicht.
Eine andere Lösung des Standes der Technik ist hardwarebasiert. Gemäß diesem Ansatz werden Datenpaketkollisionen durch Hardware vermieden. Diese hardwarebasierten Lösungen können für bestimmte kritische Echtzeitanwendungen, wie beispielsweise Raum- und Luftfahrt, notwendig sein, um strikten Leistungs- und Zuverlässigkeitsanforderungen gerecht zu werden. Solche Lösungen sind jedoch urheberrechtlich geschützt und anbieterabhängig, wodurch ihre Realisierung schwer und teuer ist. Hardwarebasierte Lösungen können mit vielen bestehenden Ethernet-Netzen inkompatibel sein, wodurch kostspielige und komplizierte Modifikationen erforderlich sind. Obwohl diese Hardwarelösungen Kollisionen verhindern, bieten sie außerdem keine Planung von Echtzeitverkehr in einem Gesamtsystem. Beide Lösungen erfordern auch eine Modifikation von bestehender Hardware oder Software.
Demgemäß besteht ein Bedarf an einem effizienten deterministischen Dienst zum Vermeiden Kollisionen von Echtzeitverkehr über Ethernet und Gewährleisten desselben, der auf bestehenden Ethernet-Netzen realisiert werden kann und mit einer großen Vielfalt von kommerzieller serienmäßig produzierter (COTS für engl. commercial-off-the-shelf) Hardware und ebensolchen Anwendungen kompatibel ist. Solch eine Lösung wird für Prozessleitnetze, sowie zeitempfindliche Multimedia- und Internetanwendungen benötigt.
US-A-5 761 430 offenbart ein System zur Verwendung in einem CSMA-Netz, das isochrone Datenpakete einbezieht.
Das Dokument mit dem Titel „A CSMA/CD-based, Integrated Voice/Data Protocol with Dynamic Channel Allocation" (S. M. Sharrock et al., Computer Networks and ISDN Systems, November 1989) offenbart ein Protokoll für integrierten Sprach/Datenverkehr in einem lokalen Rundfunknetz mit willkürlichem Zugriff.
Das Dokument mit dem Titel „Design, Implementation, and Evaluation of a Software-based Real-Time Ethernet Protocol (C. Venkatramani et al., Computer Communications Review, Oktober 1995) offenbart ein softwarebasiertes Protokoll mit zeitlich gesteuerten Token, das Echtzeitleistungsgarantien für Multimediaanwendungen bereitstellt.
Das Dokument mit dem Titel „An Ethernet compatible protocol to support real time traffic and multimedia applications" (C. Szabo, Computer Networks and ISDN Systems, Februar 1997) offenbart ein Medienzugriffsprotokoll zur Bereitstellung von gleichzeitiger Unterstützung für verschiedene Echtzeit- und/oder Multimediaanwendungen auf einem Ethernet-LAN.
Das Dokument mit dem Titel „A Reservation-based CSMA Protocol for Integrated Manufacturing Networks" (R. Yavatkar et al., Technical Report 216-92, Department of Computer Science, University of Kentucky) offenbart einer Erweiterung für das CSMA/CD-Protokoll, um sowohl herkömmlichen Datagrammverkehr als auch Echtzeitverkehr zu unterstützen.
KURZDARSTELLUNG DER ERFINDUNG
Die vorliegende Erfindung stellt ein Verfahren, wie durch Anspruch 1 definiert, bereit.
Die vorliegende Erfindung stellt auch ein maschinenlesbares Medium, wie durch Anspruch 2 definiert, bereit.
Die vorliegende Erfindung stellt auch ein Datenstromkollisionsvermeidungssystem, wie durch Anspruch 3 definiert, bereit.
Das System kann die Merkmale irgendeines oder mehrerer der unabhängigen Ansprüche 4 bis 7 aufweisen.
Ein Middleware-Ansatz zur Realisierung von Echtzeit-Ethernet stellt deterministische, d.h. vorhersagbare, Kommunikationsdienste sowohl für Echtzeitverkehr als auch für Nichtechtzeitverkehr über ein herkömmliches Ethernet-Netz mit mehreren Koten, welche Pakete von Daten zu übertragen wünschen, bereit. Die Middleware weist eine Computersoftware auf, die sich über einer Netzschnittstelleneinrichtung und dem Einrichtungssteuerprogramm, jedoch unter den Systemnetztransportdiensten und/oder den Benutzeranwendungen befindet. Die Erfindung stellt ein Middleware-Echtzeit-Ethernet oder MRTE (für engl. Middleware Real-Time Ethernet) bereit, welches keine Modifikationen an bestehender Hardware, welche Ethernet realisiert, erfordert.
In einer Ausführungsform wird die Ethernet-Bandbreite in Zyklen unterteilt. Während jedes Zyklus wird ein erstes Zeitintervall für Echtzeitdatenpaketverkehr unter Verwendung eines deterministischen Planungsprotokolls bereitgestellt, wie beispielsweise durch Übergabe eines Tokens, derart dass keine Kollisionen eintreten können. Während eines zweiten Zeitintervalls wird das standardmäßige Ethernet-Protokoll mit Trägerkennung, Vielfachzugriff und Kollisionserkennung für Nichtechtzeitverkehr verwendet. Durch Verwenden dieser beiden Zeitintervalle wird die Bandbreite zwischen dem Echtzeit- und dem Nichtechtzeitverkehr gemeinsam benutzt, wodurch sichergestellt wird, dass beide die gewünschte Bandbreite erhalten.
In einer Ausführungsform werden getrennte Warte schlangen zur deterministischen Planung verwendet, um die Reihenfolge der Paketeinreihung und Übertragung auf jedem Knoten zu bestimmen, derart dass (1) Echtzeitverkehr gewährleistet werden kann, sobald er für den Übertragungsdienst zugelassen ist, (2) Nichtechtzeitverkehr abgewickelt werden kann, und (3) eine Ethernet-Bandbreitenausnutzung optimiert werden kann.
Eine Dienstgüte QoS (für engl. Quality of Service) ermöglicht das Schließen von On-line-Kompromissen zwischen der Netzbandbreitenverfügbarkeit und der Netzübertragungsqualität. QoS-Beispiele umfassen (1) den Grad von Paketkollisionen, wenn das Ethernet durch weiche oder Nichtechtzeitverkehre während bestimmter Zeitschlitze gemeinsam benutzt wird, und (2) die Dauer der Ende-zu-Ende-Paketübertragungslatenzzeit.
Wenn QoS verwendet wird, kann periodischen Daten, wie beispielsweise Video bei 30 Rahmen je Sekunde, eine Priorität oder Kritikalität eingeräumt werden, und ein kumulativer Verlustfaktor, z.B. bis zu vier Rahmen in einer Reihe, kann verworfen werden. Wenn genügend Bandbreite nach Aufgaben höherer Priorität bleibt oder Datenströme abgewickelt werden, wird das Video in der Echtzeitwarteschlange angenommen, wobei mindestens fünf Rahmen je Sekunde gesendet werden. Wenn andere Aufgaben gelöscht oder reduziert werden, erhöht sich diese Rahmenfrequenz.
Eine Softwarestrukturierung ermöglicht das Hosten der Echtzeit-Ethernet-Middleware über der Ethernet-Netzeinrichtung und dem Einrichtungssteuerprogramm und unter der Systemtransportsoftware und/oder den Benutzeranwendungen. Ein spezifisches Beispiel für solch einen Softwarehost ist die Microsoft^® Netzeinrichtungsschnittstellenspezifikation (NDIS für engl. Network Device Interface Specification) mit dem Einrichtungssteuerprogrammsatz (DDK für engl. Device Driver Kit) auf Microsoft^® NT^®-basierten Personalcomputerplatt formen. Viele andere Softwarehosts sind in Abhängigkeit von der gewählten spezifischen Hardware verfügbar.
Ein Kollisionsvermeidungsmodul gewährleistet, dass eine Übertragung nicht zu einer Verkehrskollision führt. Das Kollisionsvermeidungsmodul realisiert ein Kollisionsvermeidungsprotokoll, das die Fähigkeit bereitstellt, zu verhindern, dass der Ethernet-Verkehr kollidiert, was eine Quelle des Problems eines nicht deterministischen Ethernet-Verhaltens ist. Ein spezifisches Beispiel für solch ein Protokoll ist ein tokenbasiertes Protokoll, durch welches ein Token, das zwischen den Ethernet-Knoten zirkuliert, bestimmt, welcher Knoten zu irgendeinem Zeitpunkt Pakete übertragen sollte. Andere Kollisionsvermeidungsprotokolle können mit der Erfindung verwendet werden, wie beispielsweise verschiedene Realisierungen von zeitgestaffeltem Vielfachzugriff (TDMA für engl. Time-Division Multiple Access), einer Technologie, welche Zeitmultiplexbildung (TDM für engl. Time-Division Multiplexing) verwendet. Das Protokoll oder der Standard stellt einen Mechanismus bereit, um einen Konflikt zwischen den Datenübertragungen durch mehr als einen Knoten zu irgendeiner bestimmten Zeit zu vermeiden.
In einer Ausführungsform ist das Kollisionsvermeidungsprotokoll schaltbar, um durch das deterministische Planungsmodul nach Wunsch aktiviert oder deaktiviert zu werden. Dies ermöglicht es der Erfindung, kollisionsfreien Echtzeitverkehr zu gewährleisten und dennoch Kollisionen von weichem und Nichtechtzeitverkehr zu gestatten. Solch ein Mischmodus-Betrieb könnte in Abhängigkeit von der Belastung während Zeitspannen, welche dem weichen und Nichtechtzeitverkehr zugeordnet werden, zu einer erhöhten Bandbreitenausnutzung führen. Schwach belastete CSMA/CD-Systeme können effizienter sein als Systeme, welche auf einem Kollisionsvermeidungsprotokoll arbeiten.
Während das Kollisionsvermeidungsprotokoll aktiv ist, ist die Zeit, die für eine vollständige Rotation von Übertragungsknoten eingestellt ist, begrenzt. Im Falle eines tokenbasierten Protokolls muss das Token innerhalb dieser begrenzten Zeit oder Tokenrotationszeit zurückkehren.
Für jedes Kollisionsvermeidungsprotokoll (tokenbasiert oder TDMA) verwendet ein deterministisches Planungsmodul einen Algorithmus, um den Verkehr zu planen und zu gewährleisten, dass eine Übertragung erfolgt, bevor eine Frist abläuft.
In einer weiteren Ausführungsform der Erfindung wird eine Zuordnung von Bandbreite an eine einzelne Brücke oder einen einzelnen Knoten basierend auf einer Unterausnutzung von Bandbreite durch andere Brücken oder Knoten im Netz erhöht.
Ein Vorteil der Erfindung ist, dass sie mit dem IEEE-Standard 802.3 konform bleibt. Solche eine Konformität ermöglicht es, dass die Erfindung auf einer Vielzahl von standardmäßigen Ethernet-Netzen ausgeführt wird, ohne eine Modifikation von Hardware zu erfordern, wodurch es ein offenes System bleibt.
Ein weiterer Vorteil der Erfindung ist, dass sie modularer Beschaffenheit ist. Entsprechend kann die Erfindung unter Verwendung einer Vielfalt von Kollisionsvermeidungsprotokollen, deterministischen Planungsalgorithmen und QoS-Verhandlungs- und -Anpassungspolitiken und -algorithmen ausgeführt werden.
Als ein Softwareansatz ermöglicht die Erfindung auch die Verwendung aller COTS-Ethernet-Karten und -Steuerprogramme für Echtzeit-Ethernet. Die Verwendung von Ethernet-Karten und -Steuerprogrammen spezifischer Anbieter ist für Anwendungen transparent, wodurch die Erfindung zur Anbieterinteroperabilität, Systemkon figurationsflexibilität und Kostensenkung für Netzbenutzer fähig gemacht wird.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1 ist ein Blockdiagramm eines Ethernet-Netzes mit mehrfachen Knoten, welche die Erfindung enthalten.
2A ist ein Blockdiagramm einer Softwarearchitektur eines Ethernet-Knotens von 1.
2B ist ein Blockdiagramm der Softwarearchitektur von 2, das mehr Einzelheiten von bestimmten Abschnitten bereitstellt.
3 ist ein Diagramm, welches das Verhalten eines Knotens als Reaktion auf eine Anwendungsanfrage auf Zulassung zum Netz veranschaulicht.
4 ist ein Diagramm, welches das Verhalten eines Knotens als Reaktion auf eine Zeitplansteuerungsunterbrechung veranschaulicht, welche die Zulassung zum Netz bewilligt.
5 ist ein Ablaufdiagramm, welches das Verhalten des QoS-Managers einer Ausführungsform der Erfindung veranschaulicht.
6 ist ein Ablaufdiagramm, welches das Verhalten der Zeitplansteuerung der Erfindung veranschaulicht.
7 ist ein Ablaufdiagramm, welches das Verhalten des MRTE-Protokolls der Erfindung veranschaulicht.
8 ist ein Ablaufdiagramm, welches das Unterbrechungssteuerprogramm des MRTE-Protokolls der Erfindung veranschaulicht.
9 ist ein Ablaufdiagramm, welches den Zulassungssteuerprozess der Zeitplansteuerung der Erfindung veranschaulicht.
BESCHREIBUNG DER AUSFÜHRUNGSFORMEN
In der folgenden ausführlichen Beschreibung wird auf die beiliegenden Zeichnungen Bezug genommen, welche einen Teil hiervon bilden und in welchen spezifische Ausführungsformen, in welchen die Erfindung realisiert werden kann, zu Veranschaulichungszwecken dargestellt sind. Gleiche Bezugszeichen in den Figuren beziehen sich auf gleiche Komponenten, was aus dem Zusammenhang der Verwendung ersichtlich sein sollte.
1 stellt eine Entwurfszeichnung eines vereinfachten Ethernet-Netzes, das die Erfindung einbezieht. Das Ethernet-Netz 100 weist einen Ethernet-Kanal 110 auf. Das Ethernet-Netz 100 enthält ferner zwei oder mehr Knoten 120, welche mit dem Ethernet-Kanal 110 über Abzweige 130 zum Datenempfang und zur Datensendung über den Ethernet-Kanal 110 verbunden sind. Die Knoten 120 enthalten eine Anwendungsschicht 140, eine Middleware-Echtzeit-Ethernet- oder MRTE-Schicht 150 und eine Ethernet-Protokollschicht 160. Die Anwendungsschicht 140 und die MRTE-Schicht 150 stehen direkt in Verbindung und die MRTE-Schicht 150 und die Ethernet-Protokollschicht 160 stehen direkt in Verbindung, aber die Anwendungsschicht 140 und die Ethernet-Protokollschicht 160 stehen nur über die MRTE-Schicht 150 in Verbindung.
2A stellt mehr Einzelheiten der Schichten eines Knotens 120 dar. Insbesondere weist die MRTE-Schicht 150 logisch ein Paar von Warteschlangen für den Datenverkehr oder Pakete auf, die in der Anwendungsschicht 140 zur Übertragung an einen anderen Knoten erzeugt werden. Die erste Warteschlange weist eine Echtzeitwarteschlange 152 zum Einreihen von Informationspaketen auf, die zur Übertragung auf einer Echtzeitbasis angenommen wurden. Mit anderen Worten, es wird gewährleistet, dass Pakete in dieser Warteschlange ohne Kollision mit einem anderen Paket gesendet werden, sofern kein Netzfehler vorliegt. Die Echtzeitverkehrswarteschlange 152 weist den Verkehr durch Kritikalität sortiert auf. Eine zweite Warteschlange weist eine Nichtechtzeitwarteschlange für Datenpakete auf, die nicht in Echtzeit, die für den Empfangsknoten von Wert ist, an einem Ziel anzukommen brauchen. Die zweite Warteschlange 154 wird durch Zuerst-rein-zuerst-raus sortiert. Die Warteschlangen können mit der entsprechenden Steuerungssoftware physikalisch getrennt oder kombiniert werden. Beide dieser Warteschlagen münden in eine standardmäßige Ethernet-Kollisionswarteschlange 162 mit einem Zuerstrein-zuerst-raus-Planungsalgorithmus. Anwendungen in der Anwendungsschicht 140 können Daten nach Wunsch jeder dieser Warteschlangen zuordnen.
Ein Bandbreitenteilungsschema wird derart realisiert, dass die MRTE-Schicht 150 für einen bestimmten wiederholten Zeitzyklus eine deterministische Planung für Pakete in der Echtzeitwarteschlange, wo Kollisionen auf dem Netz für eine erste Zeitspanne vermieden werden, und ein standardmäßiges Ethernet-Protokoll während einer zweiten Zeitspanne, um die Übertragung von Nichtechtzeitpaketen zu ermöglichen, die von der Nichtechtzeitwarteschlange 154 erhalten werden, realisiert.
In 2B ist ein Knoten mit einer ausführlicheren Darstellung der MRTE-Schicht 150 veranschaulicht, welche insbesondere zeigt, wie die Echtzeitwarteschlange 152 gesteuert wird, um eine Kollisionsvermeidung bereitzustellen. In der Anwendungsschicht 140 ist eine Anwendung 205 mit einem Diensteanbieter 210 gekoppelt. In der Praxis agiert die Anwendung 205 entweder als eine Endquelle (Sender) oder ein Endziel (Empfänger) von Datenpaketen. Der Diensteanbieter 210 dient als eine Schnittstelle zwischen der Anwendung 205 und der MRTE-Schicht 150.
Die MRTE-Schicht 150 ist weiter in QoS-Anpassungsdienste 215 und deterministische Planungsdienste 220 unterteilt, wobei in einer Ausführungsform beide in Softwaremodulen oder -Objekten realisiert sind. Die QoS-Anpassungsdienste 215 enthalten einen QoS-Manager 225 und einen QoS-Anpassungsalgorithmus 230. Der QoS-Manager 225 und sein zugehöriger QoS-Anpassungsalgorithmus 230 stellen QoS-basierte Verhandlungs- und Anpassungsdienste bereit, wie beispielsweise Ändern der Dauer von Nichtechtzeitdatenverkehr oder Anhalten von Verkehr niedriger Kritikalität, um sicherzustellen, dass genügend kollisionsfreie Bandbreite für Echtzeitverkehr hoher Priorität in Abstimmung mit der Bandbreite für Nichtechtzeitverkehr zur Verfügung gestellt wird.
Die deterministischen Planungsdienste 220 enthalten ein Kollisionsauflösungsprotokoll 235, ein MRTE-Protokoll 240 und eine MRTE-Zeitplansteuerung 245, sowie ihren zugehörigen deterministischen Planungsalgorithmus 250 und ihr zugehöriges MRTE-Verzeichnis 255. Die deterministischen Planungsdienste 220 enthalten ferner eine Softwarestrukturierung 260, um als Host oder Schnittstelle der MRTE-Schicht 150 mit der Ethernet-Protokollschicht 160 zu dienen. Das MRTE-Protokoll 240 stellt mithilfe des Kollisionsauflösungsprotokolls 235 eine Arbitrierung bereit, um Kollisionen von Datenpaketen zu vermeiden. Es gibt ein Protokoll je Ethernet-Konfiguration, das Datenpaketübertragung abwickelt. Die MRTE-Zeitplansteuerung 245 stellt mithilfe des deterministischen Planungsalgorithmus 250 eine Planungsanalyse bereit und koordiniert eine verteilte Planung zwischen einzelnen Knoten. Es gibt einen Planungsalgorithmus je Ethernet-Konfiguration. Die MRTE-Zeitplansteuerung 245 verwendet das MRTE-Verzeichnis 255 zur Speicherung eines lokalen Bildes von globalen Planungsinformationen.
Die Ethernet-Protokollschicht 160 enthält das Ethernet-Steuerprogramm 265, welches die Ethernet-Karte (nicht dargestellt) für physikalische Verbindungen und Übertragungen mit dem Ethernet-Kanal 110 unterstützt. 2B veranschaulicht einen bidirektionalen Datenfluss, welcher den Diensteanbieter 210 mit dem MRTE-Protokoll 240 mit der Softwarestrukturierung 260 mit dem Ethernet-Steuerprogramm 265 verbindet. 2B veranschaulicht ferner einen Steuerfluss, welcher das MRTE-Protokoll 240 mit dem Kollisionsauflösungsprotokoll 235 und der MRTE-Zeitplansteuerung 245 verbindet. Die MRTE-Zeitplansteuerung steuert außerdem die Flussübertragung mit den Anwendungen 205, dem QoS-Manager 225 und dem deterministischen Planungsalgorithmus 250. Der deterministische Planungsalgorithmus steuert den Übertragungsfluss mit dem QoS-Manager 225. Der QoS-Manager steuert ferner den Übertragungsfluss mit den Anwendungen 205 und dem QoS-Anpassungsalgorithmus 230.
Die verschiedenen Komponenten, die in 2B veranschaulicht sind, können ferner als Softwareobjekte beschrieben werden, wie in Tabelle 1 dargestellt. Die einzelnen Softwareobjekte kommunizieren über Anwendungsprogrammierschnittstellen- oder API-Rufe (für engl. application programming interface). Die Rufe, die mit jedem Objekt verbunden sind, sind in Tabelle 1 aufgelistet.
Tabelle 1 Softwareobjekte und API-Rufe
Die Zulassungssteuerung zum Netz kann auf eine von zwei Arten und Weisen eingeleitet werden. Die Zulassung kann durch die Anwendungen angefordert werden, oder sie kann durch eine Zeitplansteuerungsunterbrechung eingeleitet werden. 3 und 4 veranschaulichen das Verhalten der verschiedenen Komponenten beim Steuern der Zulassung.
3 veranschaulicht das Verhalten als Reaktion auf eine Anwendungsanfrage. Die Anwendungen 205 tätigen einen Admit()- oder Zulassen-Ruf an den MRTE-Diensteanbieter 210, um einen Wunsch zur Übertragung von Daten über das Netz anzuzeigen. Der MRTE-Diensteanbieter 210 wiederum leitet den Admit()- oder Zulassen-Ruf an die MRTE-Zeitplansteuerung 245 weiter. Die MRTE-Zeitplansteuerung 245 ruft dann einen GetPermission()- oder Erlaubnis-einholen-Ruf beim MRTE-Protokoll 240 ab, um anzuzeigen, dass eine Anfrage um Zulassung ansteht.
4 veranschaulicht das Verhalten als Reaktion auf eine Zeitplansteuerungsunterbrechung. Eine Unterbrechung wird zuerst durch das MRTE-Protokoll 240 in einer Form empfangen, welche durch das gewählte Kollisionsvermeidungsprotokoll diktiert wird. Für ein tokenbasiertes Protokoll wird die Unterbrechung von der Softwarestrukturierung 260 empfangen und zeigt den Empfang des Tokens durch einen einzelnen Knoten an. Für ein TDMA-basiertes Protokoll wird die Unterbrechung den TDMA-Zeitgeber (nicht dargestellt) erzeugt und zeigt an, dass der Zeitschlitz für eine Datenübertragung durch einen einzelnen Knoten geeignet ist. Nach Empfang der Unterbrechung tätigt das MRTE-Protokoll 240 einen IndicatePermission()- oder Erlaubnis-anzeigen-Ruf an die MRTE-Zeitplansteuerung 245. Die MRTE-Zeitplansteuerung 245 tätigt dann einen Get()- oder Einholen-Ruf an das MRTE-Verzeichnis 255, um Netzzustandsinformationen einzuholen. Dann tätigt die MRTE-Zeitplansteuerung 245 einen Schedule()- oder Zeitplan-Ruf an den deterministischen Planungsalgorithmus 250. Das MRTE-Verzeichnis 255 gibt einen Update()- oder Aktualisieren-Ruf aus, um den Netzzustand an die MRTE-Zeitplansteuerung 245 zu liefern, welcher dann durch einen Update()- oder Aktualisieren-Ruf, der durch die MRTE-Zeitplansteuerung 245 ausgegeben wird, an das MRTE-Protokoll 240 weitergeleitet wird.
Nach dem Aktualisieren des MRTE-Protokolls 240 mit den Netzzustandsinformationen tätigt die MRTE-Zeitplansteuerung 245 einen IndicateAdmit()- oder Zulassunganzeigen-Ruf an den MRTE-Diensteanbieter 210, um zu signalisieren, dass die Zulassung zum Netz ermöglicht wurde. Der MRTE-Diensteanbieter 210 leitet dann den IndicateAdmit()- oder Zulassung-anzeigen-Ruf an die Anwendungen 205 weiter.
5 stellt ein Ablaufdiagramm dar, welches das allgemeine Verhalten des QoS-Managers 225 beschreibt. Das Verhalten wird in Software in einer Ausführungsform in der C++ Sprache realisiert und weist mehrfache Objekte auf, welche den logischen Blöcken, die verwendet werden, um das Verhalten zu beschreiben, genau entsprechen können oder auch nicht. Weitere Sprachen und andere Programmierstile, sowie eine andere Hardware oder Firmware können in anderen Ausführungsformen verwendet werden, wie auf dem Fachgebiet allgemein bekannt ist. Der QoS-Manager ist durch den Startblock oder das Startfeld 510, die Aktionsfelder 515, 525, 535, 550, 555 und 565, sowie die Entscheidungsfelder 520, 530, 540, 545 und 560 dargestellt. Die Initialisierung des QoS-Managers 225 ist durch die Ankunft einer neuen Verkehrssitzung im Startfeld 510 angezeigt. Die ankommende Sitzung, welche eine Anzahl oder Häufigkeit und Größe von Paketen aufweist, die an einen anderen Knoten zu senden sind, wird innerhalb des QoS-Bereichs im Aktionsfeld 515 geplant. Im Entscheidungsfeld 520 wird eine Entscheidung im Hinblick darauf getroffen, ob die Sitzung planbar ist. Wenn die Sitzung planbar ist, wird der Fluss zur Zulassung der Sitzung zum Aktionsfeld 550 überführt.
Wenn die Sitzung an diesem Punkt nicht planbar ist, kann die QoS anderer Sitzungen im Aktionsfeld 525 reduziert werden. Dieser Prozess hängt stark von der jeweiligen Anwendung ab, die bearbeitet wird. Es gibt für gewöhnlich eine Anzahl von verschiedenen Stufen der Kritikalität von Daten, die mit irgendeiner Anwendung verbunden sind und leicht an die QoS angepasst werden können, wie auf dem Fachgebiet bekannt ist. Eine Zulassungsentscheidung wird dann im Entscheidungsfeld 530 getroffen. Wenn die Sitzung planbar ist, wird der Fluss zur Zulassung der Sitzung zum Aktionsfeld 550 über führt. Weitere Einzelheiten über die Planbarkeit und Zulassungsentscheidungsprozesse werden im Folgenden bereitgestellt.
Wenn die Sitzung an diesem Punkt nicht planbar ist, kann der QoS-Manager 225 die Sitzungen niedrigerer Kritikalität anhalten. Es wird dann eine Zulassungsentscheidung im Entscheidungsfeld 540 getroffen. Wenn die Sitzung planbar ist, wird der Fluss zur Zulassung der Sitzung zum Aktionsfeld 550 überführt.
Wenn die Sitzung an diesem Punkt nicht planbar ist, muss im Entscheidungsfeld 545 eine Entscheidung im Hinblick darauf getroffen werden, ob eine Planung mit einer höheren QoS für die Sitzung neu verhandelt werden sollte. Wenn eine Neuverhandlung erforderlich ist, wird der Fluss zum Aktionsfeld 515 überführt, um die Planungsanalyse zu wiederholen. Wenn keine Neuverhandlung erforderlich ist, wird der Fluss zum Entscheidungsfeld 560 überführt, um in einer Warteschlange angeordnet zu werden.
Nach der Zulassung der Verkehrssitzung beim Aktionsfeld 550 wird die Sitzung durch das Aktionsfeld 555 gesendet. Sobald eine Sitzung durch das Aktionsfeld 555 gesendet wurde, beurteilt das Entscheidungsfeld 560, ob es irgendwelche nicht zugelassene oder wartende Sitzungen gibt. Wenn es wartende Sitzungen gibt, wird der Fluss zum Aktionsfeld 565 überführt, wo die kritischste Sitzung gewählt wird. Der Fluss wird dann zum Aktionsfeld 515 überführt, um die Planungsanalyse zu wiederholen. wenn es keine wartenden Sitzungen gibt, ist der Prozess abgeschlossen, bis eine neue Sitzung ankommt.
6 ist ein Ablaufdiagramm, welches das allgemeine Verhalten der MRTE-Zeitplansteuerung 245 beschreibt. Die MRTE-Zeitplansteuerung ist durch das Startfeld 610, die Aktionsfelder 615, 625, 630 und 635, sowie das Entscheidungsfeld 620 dargestellt. Die Initialisierung der MRTE-Zeitplansteuerung 245 ist durch eine Anfrage um Zulassung im Startfeld 610 angezeigt. Die Anfrage wird im Aktionsfeld 615 gemäß dem deterministischen Planungsalgorithmus 250 analysiert. Nach Bestimmen der Planbarkeit im Aktionsfeld 615, muss die MRTE-Zeitplansteuerung 245 im Entscheidungsfeld 620 entscheiden, ob die Anfrage zugesichert werden kann, ohne den bereits zugelassenen Verkehr negativ zu beeinflussen.
Wenn die Anfrage ohne negative Auswirkungen bewilligt werden kann, informiert die MRTE-Zeitplansteuerung 245 im Aktionsfeld 630 das MRTE-Protokoll 240 im Hinblick darauf, wie der Verkehr zerlegt wird.
Die MRTE-Zeitplansteuerung 245 bewilligt dann die Anfrage im Aktionsfeld 635. Wenn der Anfrage nicht ohne negative Auswirkungen bewilligt werden kann, lehnt die MRTE-Zeitplansteuerung 245 die Anfrage beim Aktionsfeld 625 ab. Sobald die Anfrage entweder bewilligt oder abgelehnt wurde, endet der Prozess.
7 ist ein Ablaufdiagramm, welches das allgemeine Verhalten des MRTE-Protokolls 240 beschreibt. Das MRTE-Protokoll 240 ist durch das Starfeld 710, die Aktionsfelder 715, 720, 730, 735, 750 und 755, sowie die Entscheidungsfelder 725, 740, 745 und 760 dargestellt. Das MRTE-Protokoll 240 beginnt den Prozess der Netzzulassung so, wie durch eine Initialisierung im Starfeld 710 angezeigt. Nach der Initialisierung des MRTE-Protokolls 240 werden Systemkonfigurationsinformationen aus dem Kollisionsauflösungsprotokoll 235 gesammelt, wie im Aktionsfeld 715 angezeigt. Das MRTE-Protokoll 240 wartet dann im Aktionsfeld 720 auf eine Benutzeranfrage und eine Systemunterbrechung. Im Entscheidungsfeld 725 wird eine Entscheidung im Hinblick darauf getroffen, ob ein Wartezustand oder beide Wartezustände erfüllt wurden. Wenn beide erfüllt wurden, wird der Fluss zum Aktionsfeld 730 überführt, um eine Netzbelegung zu bewilligen.
Wenn keiner der beiden Wartezustände von Aktionsfeld 720 erfüllt wurde, entscheidet das MRTE-Protokoll 240 im Entscheidungsfeld 745, ob eine Benutzeranfrage empfangen wurde. Wenn nicht, kehrt der Fluss zum Aktionsfeld 720 zurück, um weiter zu warten. Wenn eine Benutzeranfrage empfangen wurde, dann vorverarbeitet das MRTE-Protokoll 240 die Sende- und Zulassungsanfrage im Aktionsfeld 750. Dann wartet es im Aktionsfeld 755 auf die Systemunterbrechung. Sobald die Systemunterbrechung empfangen wurde, wird der Fluss zum Aktionsfeld 730 überführt, um eine Netzbelegung zu bewilligen.
Sobald eine Netzbelegung im Aktionsfeld 730 durch eine Strecke bewilligt wurde, sendet das MRTE-Protokoll 240 im Aktionsfeld 735 die Daten, verarbeitet die Zulassungsanfrage und gibt die Netzbelegung frei. Es stellt dann im Aktionsfeld 740 fest, ob andere Sendeanfragen anstehen. Wenn Sendeanfragen anstehen, wird der Fluss zur Vorverarbeitung zum Aktionsfeld 750 überführt. Wenn keine Sendeanfragen anstehen, wird der Fluss zum Aktionsfeld 720 überführt, um auf weitere Anfragen und Systemunterbrechungen zu warten.
8 ist ein Ablaufdiagramm der Unterbrechungsabwicklung des MRTE-Protokolls 240. Das MRTE-Protokoll 240 ist durch das Startfeld 810, die Aktionsfelder 830, 840, 850, 855, 860, 865, 875 und 880, sowie die Entscheidungsfelder 815, 820, 825, 835, 845 und 870 dargestellt. Der Prozess wird im Starfeld 810 mit dem Empfang einer Unterbrechung eingeleitet. Das MRTE-Protokoll entscheidet dann im Entscheidungsfeld 815, ob die Unterbrechung eine Tokenpaket- oder TDMA-Unterbrechung aus dem Kollisionsauflösungsprotokoll 235 ist. Wenn es eine Unterbrechung aus dem Kollisionsauflösungsprotokoll 235 ist, entscheidet das MRTE-Protokoll 240 im Entscheidungsfeld 820, ob gegenwärtig eine Zulassungsanfrage ansteht.
Wenn die Unterbrechung nicht aus dem Kollisionsauflösungsprotokoll 235 ist, entscheidet das MRTE-Protokoll 240 im Entscheidungsblock 845, ob die Unterbrechung ein MRTE-privates Datenpaket darstellt, das MRTE-Systemzustandsinformationen enthält. Wenn es sich um MRTE-private Daten handelt, aktualisiert das MRTE-Protokoll 240 seinen Systemzustand. Wenn es keine MRTE-privaten Daten sind, entscheidet das MRTE-Protokoll 240, ob es ein gültiges ankommendes MRTE-Datenpaket ist. Wenn es ein gültiges Datenpaket ist, gibt das MRTE-Protokoll 240 das Paket im Aktionsfeld 875 an den MRTE-Diensteanbieter 210 weiter. Wenn die Unterbrechung kein gültiges MRTE-Datenpaket ist, gibt das MRTE-Protokoll 240 das Paket an das Protokoll der betreffenden oberen Schicht weiter, das nicht durch Erfindung definiert wird.
Wenn es beim Entscheidungsfeld 820 keine anstehenden Zulassungsanfragen gibt, ruft das MRTE-Protokoll 240 im Aktionsfeld 855 die MRTE-Zeitplansteuerung 245 ab und tätigt den API-Ruf IndicatePermission() oder Erlaubnisanzeigen. Nach dem Abrufen der MRTE-Zeitplansteuerung 245 oder, wenn es keine anstehenden Zulassungsanfragen gibt, wird der Fluss zum Entscheidungsfeld 825 überführt, um zu festzustellen, ob es irgendwelche MRTE-Sendeanfragen gibt, die anstehen. Wenn Sendeanfragen anstehen, sendet das MRTE-Protokoll im Aktionsfeld 860 ein MRTE-snychrones Nachrichtenpaket. Nach dem Senden des synchronen Pakets oder, wenn es keine Sendeanfragen gibt, die anstehen, wird der Fluss zum Aktionsfeld 830 überführt.
Im Aktionsfeld 830 prüft das MRTE-Protokoll 240 den Zeitgeber und die asynchrone Nachrichtenwarteschlange. Basierend auf der verfügbaren Zeit und der asynchronen Nachrichtenwarteschlange entscheidet das MRTE-Protokoll 240 im Entscheidungsfeld 835, ob es eine Übertragungszeit gibt, die verfügbar ist, und ob es asynchrone Nachrichten gibt, die bereit sind. Wenn Zeit verfügbar ist und asynchrone Datenpakete zur Übertragung bereit sind, sendet das MRTE-Protokoll 240 im Aktionsfeld 865 die asynchronen Datenpakete und gibt dann im Aktionsfeld 840 die Ethernet-Belegung frei. Wenn keine Zeit verfügbar ist oder keine asynchronen Datenpakete zur Übertragung bereit sind, gibt das MRTE-Protokoll 240 im Aktionsfeld 840 die Ethernet-Belegung einfach frei.
9 ist ein Ablaufdiagramm des Zulassungssteuerprozesses der MRTE-Zeitplansteuerung 245 und weist ein Startfeld 910, Aktionsfelder 915, 925, 930, 935 und 940, sowie ein Entscheidungsfeld 920 auf. Der Prozess wird durch den Empfang des IndicatePermission()- oder Erlaubnis-anzeigen-Rufs vom MRTE-Protokoll 240 initialisiert. Nach der Initialisierung erhält die MRTE-Zeitplansteuerung 245 im Aktionsfeld 915 die Netzzustandsinformationen aus dem MRTE-Verzeichnis 255 unter Verwendung des Get()- oder Einholen-Rufs. Die MRTE-Zeitplansteuerung 245 stellt dann durch fest, ob die Sendeanfrage geplant werden kann, indem sie bei 920 den Schedule()- oder Zeitplan-Ruf an den deterministischen Planungsalgorithmus 250 tätigt. Wenn die Anfrage nicht geplant werden kann, erstattet die MRTE-Zeitplansteuerung 245 dem MRTE-Diensteanbieter 210 im Aktionsfeld 940 unter Angabe eines Zulassungsmisserfolgs Bericht, wobei der IndicateReceive()- oder Empfang-anzeigen-Ruf bei 940 verwendet wird. Die Planungs- und Zulassungssteueralgorithmen sind in einer deterministischen Planungspolitikklasse eingekapselt, die auf verschiedenen Protokollen basiert, wie dem tokenbasierten oder TDMA.
Wenn der deterministische Planungsalgorithmus 250 bestimmt, dass die Sendeanfrage geplant werden kann, aktualisiert die MRTE-Zeitplansteuerung 245 im Aktionsfeld 925 das MRTE-Verzeichnis 255 unter Verwendung des Update()- oder Aktualisieren-Rufs. Die MRTE-Zeitplansteuerung 245 aktualisiert dann im Aktionsfeld 930 das MRTE-Protokoll 240 mit Betriebszustandsinformationen unter Verwendung des Update()- oder Aktualisieren-Rufs. Schließlich erstattet die MRTE-Zeitplansteuerung 245 dem MRTE-Diensteanbieter 210 im Aktionsfeld 935 unter Angabe eines Zulassungserfolgs Bericht, wobei der IndicateReceive()- oder Empfanganzeigen-Ruf verwendet wird.
Es gibt zwei Verkehrsmodelle, die in Betracht zu ziehen sind. Das erste ist ein periodischer oder synchroner Nachrichtenstrom. Die Faktoren, die an diesem Verkehrsmodell für jeden Knoten 120 beteiligt sind, sind seine Periode (Pj); Nachrichtenlänge oder Übertragungszeit (Mj); Frist (Dj); QoS (Qj); und Kritikalität oder Bedeutungsgrad (Cj), wobei „j" einen einzelnen Nachrichtenstrom darstellt. Das zweite Verkehrsmodell ist ein unperiodischer oder asynchroner Nachrichtenstrom. Die Faktoren, die an diesem Verkehrmodell für jeden Knoten 120 beteiligt sind, sind dieselben wie im periodischen Modell ohne die Periode (Pj).
In einer Ausführungsform verwendet der deterministische Planungsalgorithmus 250 einen Satz von Gleichungen, um festzustellen, ob eine Anfrage in einer Ausführungsform planbar ist. Die relevanten Gleichungen sind wie folgt:
wobei die folgenden zusätzlichen Definitionen gelten:

TTRT:: Zieltokenrotationszeit
T_RT:: Zeitintervall zum Senden von Echtzeitverkehr
T_NRT:: Zeitintervall zum Senden von weichem oder Nichtechtzeitverkehr
I:: Knotennummer
J:: Datenstromnummer
H_i:: Tokenhaltezeit eines einzelnen Knotens I
O_j:: Softwareoverhead des Sendedatenstroms j
N:: Gesamtzahl von Knoten
m_i:: Gesamtzahl von Echtzeitdatenpaketen zur Übertragung innerhalb von H_i

Eine neue Anfrage ist planbar, wenn Gleichung 4 wahr ist, wenn die Gleichungen 1, 2 und 3 gegeben sind.
SCHLUSSFOLGERUNG
Es wurde ein Middleware-Ansatz zur Realisierung von Echtzeit-Ethernet beschrieben, welcher deterministische, d.h. vorhersagbare, Kommunikationsdienste sowohl für Echtzeitverkehr als auch Nichtechtzeitverkehr über ein herkömmliches Ethernet-Netz mit mehreren Knoten, welche Pakete von Daten zu übertragen wünschen, bereitstellt. Die Middleware weist Computersoftware auf, die sich über einer Netzschnittstelleneinrichtung und dem Einrichtungssteuerprogramm, jedoch unter den Systemtransportdiensten und/oder Benutzeranwendungen befindet. Die Erfindung stellt ein Middleware-Echtzeit-Ethernet oder MRTE bereit, welches keine Modifikation an der bestehenden Hardware erfordert, welche das Ethernet realisiert. Getrennte Warteschlangen werden für eine deterministische Planung verwendet, um die Reihenfolge der Paketeinreihung und Übertragung auf jedem Knoten zu bestimmen, derart dass (1) Echtzeitverkehr gewährleistet werden kann, sobald er für den Übertragungsdienst zugelassen ist, (2) Nichtechtzeitverkehr abgewickelt werden kann, und (3) die Ethernet-Bandbreitenausnutzung optimiert werden kann. Die Dienstgüte QoS ermöglicht das Schließen von On-line-Kompromissen zwischen der Netzbandbreitenverfügbarkeit und der Netzübertragungsqualität. QoS-Beispiele umfassen (1) den Grad von Paketkollisionen, wenn das Ethernet durch weiche oder Nichtechtzeitverkehre während bestimmter Zeitschlitze gemeinsam benutzt wird, und (2) die Dauer der Ende-zu-Ende-Paketübertragungslatenzzeit.
Wenn QoS verwendet wird, kann periodischen Daten, wie beispielsweise Video bei 30 Rahmen je Sekunde, eine Priorität oder Kritikalität eingeräumt werden, und ein kumulativer Verlustfaktor, z.B. bis zu vier Rahmen in einer Reihe, kann verworfen werden. Wenn genügend Bandbreite nach Aufgaben höherer Priorität bleibt oder Datenströme abgewickelt werden, wird das Video in der Echtzeitwarteschlange angenommen, wobei mindestens fünf Rahmen je Sekunde gesendet werden. Wenn andere Aufgaben gelöscht oder reduziert werden, erhöht sich diese Rahmenfrequenz.
Die Softwarestrukturierung ermöglicht das Hosten der Echtzeit-Ethernet-Middleware über der Ethernet-Netzeinrichtung und dem Einrichtungssteuerprogramm und unter der Systemtransportsoftware und/oder den Benutzeranwendungen. Ein spezifisches Beispiel für solch einen Softwarehost ist die Microsoft^® Netzeinrichtungsschnittstellenspezifikation (NDIS) mit dem Einrichtungssteuerprogrammsatz (DDK) auf Microsoft^® NT^®-basierten Personalcomputerplattformen. Viele andere Softwarehosts sind in Abhängigkeit von der gewählten spezifischen Hardware verfügbar.
Die Echtzeit-Ethernet-Middleware weist zwei Hauptfunktionsmodule auf, nämlich ein Kollisionsvermeidungsmodul und ein deterministisches Planungsmodul. Das Kollisionsvermeidungsmodul realisiert ein Kollisionsvermeidungsprotokoll, das die Fähigkeit bereitstellt, zu verhindern, dass der Ethernet-Verkehr kollidiert, was eine Quelle des Problems eines nicht deterministischen Ethernet-Verhaltens ist. Ein spezifisches Beispiel für solch ein Protokoll ist ein tokenbasiertes Protokoll, durch welches ein Token, das zwischen den Ethernet-Knoten zirkuliert, bestimmt, welcher Knoten zu irgendeinem Zeitpunkt Pakete übertragen sollte. Andere Kollisionsvermeidungsprotokolle können mit der Erfindung verwendet werden, wie beispielsweise verschiedene Realisierungen von zeitgestaffeltem Vielfachzugriff (TDMA), einer Technologie, welche Zeitmultiplexbildung (TDM) verwendet. Das Protokoll oder der Standard muss nur einen Mechanismus bereitstellen, um einen Konflikt zwischen den Datenübertragungen durch mehr als einen Knoten zu irgendeiner bestimmten Zeit zu vermeiden. Jede Ausführungsform stellt Vorteile für Echtzeitprozesssteuerung, Multimedia- und Internetanwendungen, sowie andere Anwendungen, welche von der Ankunft von Echtzeitverkehr abhängen können, bereit.
Das deterministische Planungsmodul stellt fest, ob ein Satz von Echtzeitverkehr im verteilten Gesamtsystem in Bezug auf seine Zeitvorgaben, wie beispielsweise Ende-zu-Ende-Übertragungslatenzzeit, gewährleistet werden kann.
In einer Ausführungsform ist das Kollisionsvermeidungsprotokoll schaltbar, um durch das deterministische Planungsmodul nach Wunsch aktiviert oder deaktiviert zu werden. Dies ermöglicht es der Erfindung, kollisionsfreien Echtzeitverkehr zu gewährleisten und dennoch Kollisionen von weichem und Nichtechtzeitverkehr zu gestatten. Solch ein Mischmodus-Betrieb könnte in Abhängigkeit von der Belastung während Zeitspannen, welche dem weichen und Nichtechtzeitverkehr zugeordnet werden, zu einer erhöhten Bandbreitenausnutzung führen. Schwach belastete CSMA/CD-Systeme können effizienter sein als Systeme, welche auf einem Kollisionsvermeidungsprotokoll arbeiten.
Während das Kollisionsvermeidungsprotokoll aktiv ist, ist die Zeit, die für eine vollständige Rotation von Übertragungsknoten eingestellt ist, begrenzt. Im Falle eines tokenbasierten Protokolls muss das Token innerhalb dieser begrenzten Zeit oder Tokenrotationszeit zurückkehren.
In einer weiteren Ausführungsform der Erfindung wird eine Zuordnung von Bandbreite an eine einzelne Brücke oder einen einzelnen Knoten basierend auf einer Unterausnutzung von Bandbreite durch andere Brücken oder Knoten im Netz erhöht.
Obwohl die Erfindung in Verbindung mit verschiedenen Ausführungsformen beschrieben wurde, ist nicht beabsichtigt, die Erfindung auf eine solche Ausführungsform zu beschränken. Viele andere Ausführungsformen sind für die Fachleute bei der Durchsicht der zuvor dargelegten Beschreibung zu erkennen. In einer Ausführungsform der Erfindung wird das QoS-Modul weggelassen. Infolge der modularen Beschaffenheit der Erfindung, ist das System imstande, ein QoS-Modul zu einem späteren Zeitpunkt anzunehmen, falls vom Benutzer gewünscht.
In einer anderen Ausführungsform der Erfindung können mehrfache lokale Ethernet-Netze in Brücken zusammengeschaltet werden. Jede Brücke zwischen Netzen würde Nachrichten oder Ströme von Daten annehmen und planen. Die Datenströme, welche durch eine einzelne Brücke gehalten werden, würden gesendet werden, wenn diese Brücke zur Übertragung bestimmt wird, wie beispielsweise wenn die Brücke in einem tokenbasierten Protokoll in Besitz des Tokens ist. Neue Datenströme können basierend darauf, ob die Brücke genügend Bandbreite aufweisen würde, um die Daten nach dem Senden aller Nachrichten höherer Priorität zu senden, zurückgeweisen werden. Um kollisionsfreiheit für eine bestimmt Zeitspanne zu gewährleisten, müssen alle Brücken während dieser Zeitspanne im Modus des Kollisionsvermeidungsprotokolls arbeiten.

Claims

Verfahren zum Übertragen von Echtzeitverkehr in einem kollisionserkennungsbasierten Kommunikationsnetz (100), aufweisend die folgenden Schritte: Empfangen einer Aufforderung an einem Knoten (120), der an das Kommunikationsnetz gekoppelt ist, mit der Angabe, dass er Echtzeitverkehr zu senden hat; Feststellen, ob eine bestimmte Dienstgüte für den Echtzeitverkehr bereitgestellt werden kann (215); Einstellen eines ersten Zeitintervalls je Kommunikationszyklus, das einem Nichtechtzeitverkehr zugestanden wird, wenn die Dienstgüte nicht bereitgestellt werden kann; Einreihen des Echtzeitverkehrs getrennt vom Nichtechtzeitverkehr; Senden von Echtzeitverkehr während des ersten Zeitintervalls des Kommunikationszyklus bei Verwenden eines deterministischen Planungsprotokolls (220); und Senden von Nichtechtzeitverkehr während eines zweiten Zeitintervalls des Kommunikationszyklus.
Maschinenlesbares Medium mit Befehlen, die darauf gespeichert sind, um zu bewirken, dass ein Rechner die Schritte von Anspruch 1 realisiert.
Datenstromkollisionsvermeidungssystem für ein Kommunikationsnetz (100) zur Übertragung von Echtzeit- und Nichtechtzeitdatenpaketen, wobei das Kommunikationsnetz Netzeinrichtungen, Einrichtungssteuerprogramme (265), Systemnetztransportsoftware und Benutzeranwendungen (205) enthält und das System aufweist: ein Softwarestrukturierungsmodul (150) zum Hosten des Systems über den Netzeinrichtungen und Einrichtungssteuerprogrammen und unter der Systemnetztransportsoftware oder den Benutzeranwendungen; ein deterministisches Planungsmodul (220), das die Datenpakete vom Kommunikationsnetz empfängt und so ausgelegt ist, dass es die Planbarkeit und die Reihenfolge der Zulassung von Datenpaketen zur Übertragung über das Netz bestimmt, wobei das Planungsmodul Echtzeitdatenpakete während eines ersten Zeitintervalls eines Kommunikationszyklus sendet und Nichtechtzeitdatenpakete während eines zweiten Zeitintervalls des Kommunikationszyklus sendet; und ein Kollisionsvermeidungsmodul (235), das die Echtzeitdatenpakete empfängt und während des ersten Zeitintervalls ein Kollisionsvermeidungsprotokoll zum Verhindern von Kollision unter den Echtzeitdatenpaketen, wie vom deterministischen Planungsmodul gefordert, realisiert.
System nach Anspruch 3, wobei das Kollisionsvermeidungsprotokoll tokenbasiert ist.
System nach Anspruch 3, wobei das Kollisionsvermeidungsprotokoll zeitmultiplexzugriffsbasiert ist.
System nach Anspruch 3, ferner aufweisend: ein Dienstgütemodul (215) zum Schließen von Online-Kompromissen zwischen der Netzverfügbarkeit und der Netzübertragungsqualität.
System nach Anspruch 3, wobei das deterministische Planungsmodul (220) die Planbarkeit von Echtzeitdatenpaketen gemäß den folgenden Gleichungen bestimmt:
wobei: TTRT die Zieltokenrotationszeit ist; T_RT das Zeitintervall zum Senden von Echtzeitverkehr ist; T_NRT das Zeitintervall zum Senden von weichem oder Nichtechtzeitverkehr ist; I die Knotennummer ist; j die Datenstromnummer ist; H_i die Tokenhaltezeit eines einzelnen Knotens I ist; O_j das Softwareoverhead des Sendedatenstroms j ist; n die Gesamtzahl von Knoten ist; und m_i ist die Gesamtzahl von Echtzeitdatenpaketen zur Übertragung innerhalb von H_i; und wobei ein Echtzeitdatenpaket planbar ist, wenn Gleichung 4 als wahr gewertet wird, wenn die Gleichungen 1, 2 und 3 gegeben sind.