Verfahren und Vorrichtung zur zeitgesteuerten Datenübertragung in einem TSN

Durch die Erweiterungen der IEEE Arbeitsgruppe TSN (Time Sensitive Networking, IEEE 802.1) wird Echtzeitkommunikation in Netzwerken, die gemäß Ethernet Standard arbeiten, ermöglicht. Die aktuellen, sich in Entwicklung befindenden IEEE Standards für TSN berücksichtigen besonders die Anforderungen der Automobilindustrie und Steuerungen in Automatisierungsanlagen mit ihren Anforderungen an die Netzwerke bezüglich Echtzeitverhalten. Es werden Mechanismen und Protokolle definiert, um deterministische Dienste anbieten zu können für das zeit- sensitives Streaming durch ein Netwerk gemäß Ethernet Standard .

Der sogenannte Time-Aware-Shaper (TAS) ist im Standard IEEE 802.1Qbv definiert und kann zeitlich vorgeplanten,

geschedulten Datentransfer vor Störungen aus anderem Datenverkehr schützen, indem festgelegte Zeitfenster verwendet werden und so eine deterministische niedrige Latenz erreicht wird. Falls das sogenannte „cut-through" Routing in Kombina ^¬ tion mit TAS angeboten wird, so kann die beste Echtzeit- Leistungsfähigkeit mit niedrigster Latenz und geringstern Verzögerungs-Varianz erreicht werden.

Ein TAS Netzwerk für einen geschedulten Datentransfer anzuwenden erfordert, dass alle Netzelemente, also sowohl die Vermittlungsstationen / Bridges als auch die Endteilnehmer- Stationen zeitsynchronisiert sind, so dass die TAS-

Zeitfenster auf der selben Zeitbasis gescheduled werden.

Das Scheduling von TAS Fenstern hängt von der globalen Netzinformation ab, beispielsweise von der Netzwerk-Topologie, und benötigt daher ein vollständig verwaltetes Netzwerk. We ^¬ gen des hohen Planungs- und Verwaltungsaufwands und ineffi ^¬ zienter Bandbreiten-Ausnutzung für den verbleibenden Datenverkehr werden diese Netze, so wie beispielsweise bereits PROFINET IRT ( I sochrounous Real Time) Netz, hautpsächlich für Harte Echtzeitsysteme und Motion-Control-Anwendungen verwendet, die höchste Anforderungen an die Echtzeitfähigkeit und Zuverlässigkeit stellen.

Für solche Echtzeit-Systeme, die nicht diese höchsten Anfor ^¬ derungen mit niedrigster Latenz fordern, werden andere Verkehrsflußregelungen mit weniger Planungsaufwand als TAS be ^¬ vorzugt, solange der benötigte Determinismus angeboten wird. Der sogenante Credit-Based Shaper (CBS) , wurde in dem IEEE Standard 802.1Qav von der AVB (Audio-Video-Bridging) Task Group definiert und ist vorgesehen für Audio-Video Streams mit begrenzter Latenz und Verlustfreiheit bei Datenstau. CBS glättet den Datentransfer der Streams durch gleichmäßige Ver- teilung der Datenpakete über die Zeit. Die Idee dahinter ist, die Konzentration von Datenframes zu verhindern, was eine Überlastung der Datenpuffer der Bridges zur Folge haben könnte und damit den Verlust von Datenframes. Die Begrenzung der Konzentration hat den Vorteil, dass der in den Bridges benö- tigte Daten-Puffer am Ausgangsport kleiner dimensioniert sein kann und einen niedrigeren maximalen Delay im Ausgangs-Stream der Bridge erzeugt.

AVB verwendet das Stream-Reservation Protokoll (SRP) , das in IEEE 802.1Qat definiert ist, für die Reservierung von Res ^¬ sourcen im Netzwerk für jeden einzelnen AVB Stream, kalkuliert auf Basis eines Worst-case Delays und mit einem Spei ^¬ cherbedarf berechnet für die Bridges basierend auf Traffic Classes .

Es stellt sich jedoch heraus, dass der Worst-Case Delay pro Netzelement (Bridge) bei CBS topologieabhängig ist und die ^¬ selbe Abhängigkeit findet sich beim Speicherbedarf. Das führt dazu, dass die Worst-Case Analyse sehr komplex wird und topologieabhängig ist. Ungenaue Worst-Case Berechnungen füh- ren zu falschen Reservierungen im Netzwerk, es werden entweder zu viele Ressourcen belegt. Der jedoch problematischere Fall wäre die zu geringe Reservierung, die zu unerwarteten Datenverlusten führt aufgrund zu gering dimensionierter Bridge Speicher, was letztendlich ernsthafte Fehler im Echtzeit-System verursacht.

Zur Vermeidung der oben beschriebenen Probleme wurde ein wei- teres Protokoll definiert, das Cyclic Queuing and Forwarding (CQF) Protocol, IEEE 802.1Qch. Es bietet eine Flußkontrolle mit garantierter maximaler Latenz und einer begrenzten Verzögerungsschwankung pro Sprung (sogenannter fixed delivery Jitter an jeder Bridge im Netzwerk) . Das Senden von Datenpa- keten gemäß CQF Protokoll wird exemplarisch in Figur 2 dargestellt .

In jeder Bridge Bl, B2 ist die Zeit aufgeteilt in eine Abfol ^¬ ge von gleich langen Zeitintervallen T. CQF verlangt dabei, dass ein Datenframe PI, P2, P3, der in einem ersten Intervall im Zeitraum zwischen Zeitpunkt tl und t2 empfangen wird im darauffolgenen zweiten Intervall zwischen t2 und t3 an das im Pfad darauffolgende nächste Netzelement übertragen wird. Das bedeutet insbesondere, dass die Anforderung besteht, dass das Netz zeitsynchronisiert ist, d. h. alle Bridges in dem Netz- werk wissen, wann das nächste Intervall beginnt und wie lange es dauert. Synchronisiert wird durch einen zentralen Zeitge ^¬ ber MC, welcher dafür sorgt, dass die einzelnen Netzelemente auf der gleichen Zeitbasis laufen, SYNC. Da bei CQF jeder Datenframe von einer Bridge im Laufe des ak ^¬ tuellen Intervalls genau um einen Hop im Pfad weiter übertra ^¬ gen wird, ist die Verzögerung pro Hop begrenzt auf zweimal die Länge des Zeitintervalls T, der Worst-case Delay.

Die maximale Latenz für die Übertragung eines Frames in dem Netz ist also

LatenzMax = (h + 1) * T wobei h die Anzahl der Hops ist.

Wenn ein Frame bei jedem Hop immer zu Anfang des nächsten

Frames und ohne weitere Verzögerung durch störenden Datenverkehr übertragen wird, abgesehen von der Verzögerung die durch einen Shaper im Netz verursacht wird, dann ist die minimale Latenz wie folgt zu berechnen:

LatenzMin = (h - 1) * T

Der Übertragungsj itter beträgt bei CQF die Zeitdauer 2T, welches ein fester Wert ist, unabhängig von der Anzahl der Hops in der Übertragungsstrecke. CQF erreicht eine deterministi ^¬ sche Latenz und einen topologie-unabhängigen Jitter jedoch für den Preis einer erhöhten Latenz im besten Fall als Resultat von der durch den Shaper erzwungenen Wartezeit in jeder Bridge .

Der größte Vorteil von CQF im Vergleich zu CBS ist die massiv reduzierte Komplexität in der Berechnung der worst-case Ver ^¬ zögerung wegen der fehlenden Abhängigkeit von der Netzwerk- Topologie. Der festgelegte Jitter der CQF Traffic Class führt zu gleichmäßig verteilten Speichergrößen in den CQF Warteschlangen (Queues) aller Bridges, was einen verallgemeinern- den Ansatz im Ressourcen-Berechnungsmodell erlaubt, der ge ^¬ eignet ist für jedes mögliche CQF Szenario.

Um sicherzustellen, dass die oben berechneten Latenzgrenzen erreicht werden können, muss die Dauer T der Zeitintervalle groß genug gewählt werden um allen Daten in einem vorgegebe ^¬ nen Klassen-Messintervall Platz zu bieten, plus einem Stör- Frame maximaler Größe von niedrigerer Priorität.

Wenn die in IEEE 802. lbu/802.3.3br definierte Frame

Preemption mit CQF kombiniert wird, dann kann die maximale Größe eines Stör-Fragments weiter reduziert werden auf die

Größe eines maximalen Frame-Fragments. Das bedeutet, dass für die gleiche Intervalldauer T für die Verwendung mit CQF mehr Streamdata reserviert werden kann, wenn Preemption verwendet wird .

Obwohl CQF gegenüber CBS bezüglich der Technologie- Unabhängigkeit und der Einfachheit der Berechnung der Worst- Case Latenz im ungünstigsten Fall überlegen ist, benötigt CQF ebenfalls einen zyklischen Zeitablauf das als Basis ein zeit ^¬ synchronisiertes Netzwerk benötigt. Wenn CQF mit PSFP (per- stream filtering and policing, IEEE 802. lQi) und TAS (IEEE 802. QBv) implementiert wird, dann werden von CQF am Ausgangs- Port zwei Transport-Klasse Warteschlangen pro Datenstream be ^¬ nötigt für eine einzelne SR (Stream Reservation) Class. Die zwei Wartenschlangen werden zyklisch abwechselnd verwendet mit Hilfe von Input und Output Gate Control um sicherzustel ^¬ len, dass die eine Warteschlange im Puffer-Status arbeitet und die andere im Übertragungs-Modus. Weil die Traffic

Classes eine begrenzte Ressource einer Bridge sind (bei einer IEEE 802. IQ konformen Bridge sind es maximal 8), wird der Be ^¬ darf von zwei Warteschlangen pro Traffic Class als Nachteil der CQF angesehen. Der zweite Schwachpunkt von CQF ist, wie bereits erwähnt, die Notwendigkeit einer

Zeitsynchronisiserung .

Es ist daher Aufgabe der Erfindung, ein Verfahren anzugeben, zur Übertragung von zeitkritischen Datenpaketen mit einer garantierten maximalen Latenz, eine topologie-unabhängige La- tenz-Kalkulation und eine begrenzte Schwankung der Verzögerungen (delay) , ohne zentrale Zeitsynchronisation im Netz und/oder in den Endgeräten.

Die Aufgabe wird gelöst durch je ein Verfahren und eine Vor ^¬ richtung mit den Merkmalen der unabhängigen Patentanspruchs.

Das Verfahren betrifft die zeitgesteuerte Datenübertragung von Datenpaketen in einem time-sensitiven Netzwerk gemäß TSN Standard. Das Netzwerk besteht dabei aus einzelnen Netzele ^¬ menten und der Zeitablauf ist in jedem Netzelement einge ^¬ teilt in vorgeplante, gleichgroße Zeitfenster.

Die Netzelemente verfügen jeweils über einen eigenen unabhän- gigen Zeitmesser und diese Zeitfenster beginnen und enden bei allen Netzelementen zu den gleichen Zeitpunkten. Die Übertragung eines Datenpakets von einem ersten Netzelement zu einem darauffolgenden Netzelement erfolgt in dem Zeitfenster, wel- ches dem Zeitfenster folgt, in dem dieses Datenpaket von ei ^¬ nem vorhergehenden Netzelement empfangen wurde.

Jedes Netzelement bestimmt dann basierend auf dem durch eige ^¬ nen unabhängigen Zeitmesser und einem Verzögerungswert, zu welchem Zeitpunkt das nächste Sendefenster beginnt und/oder endet .

Weitere vorteilhafte Ausführungsformen der Erfindung sind durch die Merkmale der Unteransprüche angegeben.

Beschrieben wird eine neue Traffic Shaping Methode für zeit ^¬ sensitive Datenstreams , die im Folgenden auch „Packet Delay Variation Compensation (PDVC)" genant wird. Es ist das Ziel, die gleiche Echtzeit-Performanz und Konfigurations- Komplexität zu bieten wie CQF aber ohne die Notwendigkeit ei ^¬ ner Zeitsynchronisierung des kompletten Netzwerks.

Der PDVC Shaper sorgt ebenfalls dafür, dass ein Datenframe, der durch eine Bridge in einem ersten Zeitintervall empfangen wird, durch diese Bridge in dem nächsten Zeitintervall an den nächstliegenden Hop/Bridge weiter gereicht wird.

Ein wesentlicher Unterschied zu CQF besteht darin, wie diese Zeitintervalle in den Bridges realisiert werden. CQF reali ^¬ siert die Intervallen in der Bridge in einer bestimmten Weise durch Verwendung von einem zyklischen Netz-zentralen Timer und formt die Streams einer vorgegebenen Transport-Klasse ba ^¬ sierend auf dem selben Schedule (eine Abfolge von aufeinander folgenden Zeitintervallen) . Der zyklische Timer der CQF Bridges im Netzwerk muss dabei auf einer gemeinsamen Zeitbasis laufen, damit die Zeitintervalle auf die gleiche Startzeit synchronisiert werden können.

Das hier beschriebene Verfahren kommt ohne die im Verfahren gemäß dem Stand der Technik unverzichtbare zentrale Zeitbasis aus. Jede Bridge kennt die Startzeit des Zeitintervalls, das zu einem bestimmten Datenstream gehört. Dieser ist durch die Quelle des Streams definiert, (StreamID) , durch Verfolgung des Zeitablaufs jedes Frames an jedem Hop entlang des Daten ^¬ pfads von der Quelle zur Senke. Jeder Datenframe muss einen sogenannten „Delay Wert" enthalten, also einen Verzögerungs ^¬ wert, der durch jede Bridge gemessen wird unter Verwendung einer lokalen Uhr die die Verzögerungszeit misst, die der Da ^¬ tenframe in der Warteschlange am ausgehenden Port verbringt. Abhängig von der Implementierung sollte der gemessene Delay Wert jeden Delay herausrechnen, der durch den PDVC Shaper verursacht wird, und widerspiegelt, wie die tatsächliche Übertragungszeit AT abweicht von der geplanten Übertragungs ^¬ zeit. Die geplante Übertragungszeit für einen Datenframe, üb- licherweise als Eligilibility Time ET bezeichnet, wird vom PDVC Shaper zum frühest möglichen Zeitpunkt ermittelt, wenn der Daten-Frame in der Wartenschlage des Ausgangsübertra ^¬ gungsports eingetragen wird.

Der Verzögerungswert, Delay Value DV, der an der Bridge ge- messen wird, berechnet sich wie folgt:

DV (i) = AT (i) - ET (i)

Wenn die nächste Bridge im Übertragungspfad i+1 einen Daten- frame mit DV(i) erhält, dann berechnet es ET (i+1) für den Da ^¬ tenframe

ET (i + 1) = T - (DV (i) + CD) wobei T das Klassen-Messintervall welches zu dem Stream die ^¬ ses Datenframes gehört und das Übertragungsintervall des Streams an seiner Quelle repräsentiert. Als konstanter Para ^¬ meter von PDVC für eine SR Klasse muss der Wert von T an je ^¬ der Bridge konfiguriert werden, entweder durch ein Netz- Management oder während der Stream Reservierung mit SRP.

CD ist ein Verzögerungswert bestehend aus den folgenden Kom ^¬ ponenten, die abhängig von der Hardware und Framegrößenspezi- fisch sind:

- Der Verzögerungswert des Datenframes (delay) gemessen von AT(i), welches die tatsächliche Startzeit der Daten ^¬ übertragung am Ausgangsport der Bridge i zum Zeitpunkt wenn der vollständige Datenframe beim Eingangsport der nächstfolgenden Bridge i+1 empfangen wurde. Der Hauptteil dieses Verzögerungswerts kann in Bridge i+1 einfach berechnet werden basierend auf der Geschwindigkeit des Übertragungslinks und der Framegröße. Der verbleibende Teil ist abhängig von der Hardware, inclusive dem Verzö ^¬ gerungswert des Kabels (link propagation delay) zwischen der sendenden Bridge i und der empfangenden Bridge i+1, der ebenfalls durch das Netzmanagement festgelegt oder durch Messungen durch ein Zeitsynchronisierungsprotokoll ermittelt werden, beispielswese gPTP of 802.1AS, sofern geeignet .

- Der Verzögerungswert des Vermittlungsvorgangs in der

Bridge i+1, üblicherweise handelt es sich hier um einen festen Wert, der sich in der Hardware Spezifikation der Bridge findet.

Wie in der zweiten Formel angedeutet, stellt PDVC den ET für einen Datenframe auf der aktuellen Bridge fest, basierend auf der Verzögerungsinformation des Datenframes am vorherigen Hop. Solch ein Shaping-Ansatz basiert auf der Information aus dem vorhergehenden Hop, und wird auch als „Route based Traf- fic Shaping" bezeichnet.

Im Folgenden wird die Erfindung durch Figuren erläutert.

Figur 1 das erfindungsgemäße Vorgehen und

Figur 2 zeigt das Vorgehen gemäß dem Stand der Technik.

Figur 2 wurde bereits in der Beschreibungseinleitung näher erläutert.

Figur 1 zeigt ein Beispiel des erfindungsgemäßen Vorgehens, unter Verwendung des PDVC Shapers für die Übertragung eines eineinen Datenstreams von der Quelle Source durch 2 Bridges Bl, B2 zu einer Datensenke, Sink. Jedes dieser Netzelemente hat eine eigene Zeitmesser Cl bis C4, welche autark ist und nicht synchronisiert mit einer der anderen Zeitquellen. Wie dargestellt, generiert die Datenquelle, Source, perio ^¬ disch einen Frame PI, P2, P3, P4 zu den Zeitpunkten tl, t2, t3, t4 wobei zwischen den Zeitpunkten tl bis t4 jeweils ein gleichbleibendes Zeitintervall T liegt. Der StartZeitpunkt des jeweiligen Zeitintervalls ist in der Figur durch eine ge ^¬ strichelte senkrechte Linie dargestellt. Die Datenpakete in gestrichelten Linien zeigen den Zeitpunkt, an dem das Paket geplant abgesendet werden soll, die Pakete mit durchgezogener Linie unterhalb der jeweiligen Zeitlinie t des jeweiligen Netzelementes dann den tatsächlichen Zeitpunkt, an dem das Paket - optimalerweise im selben Zeitfenster - abgesendet wird. Mit der Hilfe vom Verzögerungswert DVO, DV1, DV2, der durch den Aufenthalt in der ausgehenden Warteschlange des Ausgangsports der jeweiligen Netzelemente entsteht, der bei jedem Hop gemessen wird und als zusätzliches Datenfeld im

Frame mit zum nächsten Netzelement übertragen wird, kann jede darauffolgende empfangende Bridge Bl, B2 den Zeitpunkt der Übertragung des Datenframes zeitlich neu ausrichten. Der Übertragungszeitpunkt berechnet sich dabei gemäß der Formel für ET(i+l) von oben.

CD bezeichnet einen zusätzlichen konstanten Delay pro Sprung. Dieses Feature von PDVC ist vorteilhaft für die Kontrollan ^¬ wendung, wo eine Anzahl von Streams in das Netzwerk aus verschiedenen Datenquellen zu verschwiedenen Zeitpunkten in ei- ner koordinierten Art und Weise. PDVC kann die gleichen Übertragungsreihenfolgen bei allen Streams beim Ausgangsport jeder Bridge entlang des Datenübertragungspfads.

Um sicherzustellen, dass PDVC korrekt arbeitet, muss PDVC auf allen Bridges Bl, B2 entlang des Datenübertragungspfades an ^¬ gewendet werden, ebenso wie in den Datenquellen, wenn diese Datenquellen ausserdem noch anderen Datenverkehr erzeugen, welcher sich mit dem ersten Datenverkehr in Konflikt befindet und die geplante Übertragung zeitlich verzögern.

Die maximale Verzögerung pro Bridge und die maximale End-to- End Latenz von PDVC sind ähnlich zu CQF wegen der Abhängigkeit von dem Intervall T und der Anzahl der Hops h. PDVC per bridge Delay < 2T

per Hop delivery Jitter = 2T

(h - 1) * T < PDVC end-to-end latency < h * T Die oben genannten Grenzwerte sind berechnet unter der Bedin ^¬ gung von Formel 2, dass der Wert von T immer kleiner als jeder möglicher Wert von (DV(i) + CD), der auftreten kann. Um sicherzustellen, dass die Bedingung immer erfüllt wird, gelten dieselben Bedingungen bei CQF für die Auswahl von T durch Berücksichtigung der maximalen Menge von Stream Daten, die während dem Zeitintervall T beobachtet plus einen maximal großen störenden Datenframe. Ähnlich zu CQF hilft eine kombi ^¬ nierte Verwendung von Frame Preemption und PDVC die Anzahl der möglichen Streamdata für ein festes Zeitintervall T, oder das Zeitintervall T verkleinern für dieselbe Menge von

Streamdaten resultierend in einer reduzierten Worst-Case Latenz .

In dem Beispiel von Figur 1 werden weitere Zeitabweichungen der einzelnen lokalen Zeitmesser, die man für Zeitberechungen des Shapers verwendet, ignoriert. Solche Abweichungen zwi ^¬ schen den verteilten Uhren stören den Betrieb von PDVC nicht, jedoch kann zu Verletzungen der gewünschten Verzögerungsgrenzen in den übertragenen Streams führen. Um diesen Effekt zu vermeiden darf die maximale Zeitabweichung, die zwischen zwei lokalen Uhren im Netzwerk auftreten kann, als zusätzlicher Faktor in der Konfiguration von PDVC berücksichtigt werden, indem entweder der Wert von T erhöht wird oder die Anzahl der reservieren Streams reduziert.

Der hier beschriebene Traffic Shaper bietet eine ähnlich gute Echtzeit-Performanz mit fester maximaler Latenz und festem Delivery Jitter wie CQF. Diese Leistungsfähigkeit wird in ei ^¬ ner Vielzahl von Industrieanwendungen und -Steuerungen benö- tigt, die nicht allerhöchste Anforderungen an die Echtzeit stellen. Der größte Vorteil gegenüber der standardisierten Lösung ist, dass die Lösung auf ein zeitsynchronisiertes Netz wie PTP IEEE 1588 oder IEEE 802.1AS verzichten und damit die dafür sonst benötigten Kosten sparen kann.

Die Hauptmethode die zur Anwendung kommt ist das sogenannte Traffic Shaping um eine deterministische Leistung zu erhal ^¬ ten, die einen Delay für jeden Datenframe bei jedem Hop erzwingt, um so sicherzustellen dass der periodische Stream Traffic durch das Netz mit einer festen per-hop Verzögerung. Anders als bei CQF, das den Wert der Shaper-bedingten Verzö- gerung basierend auf einem globalen Timer berechnet, trifft PDVC diese Entscheidungen basierend auf vorangegangener Hop- Information, die gemessen wird mit Hilfe von lokalen Uhren, und in jedem Frame von Bridge zu Bridge übertragen wird.