AT522898A1 - Übertragung von Datenpaketen - Google Patents

Übertragung von Datenpaketen Download PDF

Info

Publication number
AT522898A1
AT522898A1 ATA50740/2019A AT507402019A AT522898A1 AT 522898 A1 AT522898 A1 AT 522898A1 AT 507402019 A AT507402019 A AT 507402019A AT 522898 A1 AT522898 A1 AT 522898A1
Authority
AT
Austria
Prior art keywords
tsn
network
ethernet
stream
frame
Prior art date
Application number
ATA50740/2019A
Other languages
English (en)
Original Assignee
B & R Ind Automation Gmbh
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by B & R Ind Automation Gmbh filed Critical B & R Ind Automation Gmbh
Priority to ATA50740/2019A priority Critical patent/AT522898A1/de
Priority to EP20764060.8A priority patent/EP4005163A1/de
Priority to PCT/EP2020/073721 priority patent/WO2021037837A1/de
Priority to CN202080073600.4A priority patent/CN114631290B/zh
Priority to US17/638,433 priority patent/US20230031236A1/en
Publication of AT522898A1 publication Critical patent/AT522898A1/de

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46Interconnection of networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/28Flow control; Congestion control in relation to timing considerations
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46Interconnection of networks
    • H04L12/4604LAN interconnection over a backbone network, e.g. Internet, Frame Relay
    • H04L12/462LAN interconnection over a bridge based backbone
    • H04L12/4625Single bridge functionality, e.g. connection of two networks over a single bridge
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46Interconnection of networks
    • H04L12/4641Virtual LANs, VLANs, e.g. virtual private networks [VPN]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/24Traffic characterised by specific attributes, e.g. priority or QoS
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/24Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2441Traffic characterised by specific attributes, e.g. priority or QoS relying on flow classification, e.g. using integrated services [IntServ]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/02Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40Network security protocols

Abstract

Um in einem Mischnetzwerk (1) ein Datenpaket (D1) von einer Ethernet-Komponente (E1, E2, E3), in einem Ethernet-Netzwerk (3) an ein Industrielles Kommunikationsnetzwerk zu übertragen, wird ein nach den Standards der Arbeitsgruppe IEEE 802.1 TSN konfiguriertes Industriellen Kommunikationsnetzwerk (2) verwendet und für das Datenpaket (D1) zumindest eine in den Standards der Arbeitsgruppe IEEE 802.1 TSN definierte Garantie vergeben, indem ein das Datenpaket (D1) beinhaltende Frame (F1) im nach den Standards der Arbeitsgruppe IEEE 802.1 TSN konfigurierten Industriellen Kommunikationsnetzwerk (2) von einer TSN-Bridge (TSN-F) identifiziert, in einen das Datenpaket (D1) beinhaltende TSN- Stream (S1) umgewandelt und das Datenpaket (D1) im TSN-Stream (S1) an eine TSN- Komponente (TSN-C) übermittelt wird.

Description

15
20
25
30
35
BN-4109 AT
Übertragung von Datenpaketen
Die gegenständliche Erfindung betrifft ein Verfahren zur Übertragung eines, vorzugsweise zyklischen, Datenpakets von einer Ethernet-Komponente, welche in einem EthernetNetzwerk innerhalb eines Mischnetzwerks angeordnet ist, an eine TSN-Komponente, die in einem nach den Standards der Arbeitsgruppe IEEE 802.1 TSN konfigurierten Industriellen
Kommunikationsnetzwerk angeordnet ist.
Ein reines Ethernet-Netzwerk, welches ausschließlich aus Standard-Ethernet-Komponenten besteht, ist nicht deterministisch, womit keine Zeitgarantien für gesendete/empfangene Datenpakete abgeben werden können - selbst wenn alle vorhandenen Quality-of-ServiceMechanismen ausgereizt werden. In Industriellen Kommunikationsnetzwerken hingegen können Datenpakete zyklisch und mit Garantien versehen übertragen werden. Um dies zu ermöglichen, werden Industrielle Kommunikationsnetzwerke meist durch spezielle IndustrialEthernet-Komponenten, d.h. spezielle Industrial-Ethernet-Software-Stacks und spezielle Industrial-Ethernet-Hardware aufgebaut. Industrielle Kommunikationsnetzwerke zeichnen sich üblicherweise durch geringe Bitfehlerraten, sowie spezielle Frameformate und zeitlich
genau organisiertes Versenden von zyklischen Frames aus.
Endpoints und Controller stellen Komponenten eines Netzwerks dar, wobei ein Endpoint nur über eine Verbindung Datenpakete empfangen kann und ein Controller über mehrere Verbindungen. Eine Bridge wird auch Switch genannt und dient einer Verbindung von Komponenten eines Netzwerks. Eine Edge Bridge dient der Verbindung eines Netzwerks (z.B. eines Industriellen Kommunikationsnetzwerks) mit einem zweiten Netzwerk (z.B. eines Standard-Ethernet-Netzwerks). Somit können Bridges reine Netzwerkinfrastrukturgeräte darstellen, es können jedoch auch als Endpoints bzw. Controller als Bridged Endpoints bzw. Bridged Controller verwendet werden, was bedeutet, dass sie auch der Verbindung weiterer
Komponenten dienen können.
Spezielle Industrial-Ethernet-Komponenten, insbesondere spezielle Industrial-EthernetHardware sind natürlich teurer als Standard-Ethernet-Komponenten. Aus diesem Grund kann anstatt eines reinen Industriellen Kommunikationsnetzwerks ein Mischnetzwerk vorgesehen sein, welches ein Industrielles Kommunikationsnetzwerk und ein (Standard)Ethernet-Netzwerk umfasst. Hierzu können Ethernet-Komponenten über ein Gateway mit dem Industriellen Kommunikationsnetzwerk verbunden werden. Die (Standard-)EthernetKomponenten unterstützen jedoch keine für einen zyklischen Datenverkehr notwendigen Funktionen für gesendete/empfangene Datenpakete, beispielsweise die Vergabe von Garantien, insbesondere Zeitgarantien. Es ist somit in einem derartigen Mischnetzwerk ohne besondere Vorkehrungen nicht vorhersehbar, wie lange ein von einer Standard-Ethernet-
Komponente gesendetes Datenpaket im Mischnetzwerk unterwegs ist. Es kann auch nicht
2126"
15
20
25
30
35
BN-4109 AT
vorhergesehen werden, ob ein Datenpaket, beispielsweise aufgrund eines Überlaufs eines
Bridge-Buffers, verloren geht.
Als bekannte Industrielle Kommunikationsnetzwerke mit spezieller Industrial-EthernetHardware seien PROFINET IRT, POWERLINK, EtherCAT, SERCOS etc. genannt. Derartige Industrielle Kommunikationsnetzwerke weisen jeweils spezielle Mechanismen auf, um Mischnetzwerke zu realisieren. Im Rahmen dieser Mechanismen wird jedoch grundlegend eine Einbringung an Nichtechtzeitverkehr beschränkt, um die Echtzeitfähigkeit nicht zu
gefährden.
Ethernet/IP und Profinet/IO hingegen stellen Industrielle Kommunikationsnetzwerke dar, welche aus Standard Ethernet Komponenten aufgebaut werden. Damit weisen diese Industriellen Kommunikationsnetzwerke jedoch längere Zykluszeiten und eine geringere Robustheit gegenüber Nicht-Echtzeitverkehr auf, da Echtzeitverkehr und NichtEchtzeitverkehr nicht anhand ihrer zugehörigen Frames unterschieden werden können und somit von den Bridges gleichbehandelt werden. Daher kann der Fall eintreten, dass Echtzeitverkehr durch Nicht-Echtzeitverkehr verdrängt wird. So kann insbesondere bei einem hohen Auftreten von Nicht-Echtzeitverkehr ein Teil des Echtzeitverkehrs in einen folgenden Zyklus verschoben werden. Damit erhält der Empfänger zumindest in einem Zyklus keine Datenpakete und schaltet in einen Fehlermodus und/oder extrapoliert die zuvor erhaltenen Datenpakete. In einem der darauffolgenden Zyklen erhält der Empfänger dann mehrere Datenpakete. Diese multiplen Datenpakete müssen wiederum speziell behandelt werden. Ist ein geringer Anteil an Nicht-Echtzeitverkehr vorgesehen, so das genannte Problem natürlich selten auf. Eine Wahl einer derart großen Zykluszeit, dass die für Echtzeitverkehr erforderliche Bandbreite im Verhältnis klein ist, kann der Steigerung der Robustheit dienen. Bestenfalls tritt durch diese Maßnahme keine Verschiebung einzelner Frames in den
nächsten Zyklus auf.
Um in Industriellen Kommunikationsnetzwerken, welche auf Standard-EthernetKomponenten basieren, überhaupt zyklischen Datenverkehr zu ermöglichen, müssen Angaben zur Laufzeit der gesendeten zyklischen Datenpakete gemacht werden. Eine bekannte Möglichkeit dies zu realisieren ist die Verwendung von „Network Calculus“. Ein „Network Calculus“ ist eine gängige Methode um in einem nicht-echtzeitfähigem Netzwerk Latenzen zu berechnen bzw. zu schätzen. Damit können Grenzwerte für die Laufzeit der Datenpakete angegeben werden, womit die erforderlichen Bandbreiten für eine Übertragung eines Datenpakets berechnet werden. Diese Angaben werden entsprechend statistischer Bereichsabschätzungen gewählt. Daher müssen Netzwerke, die diese Methode verwenden, großzügig überdimensioniert werden. Die korrekte Dimensionierung des Netzwerks ist somit stark von der Erfahrung des Netzwerkingenieurs abhängig, da das Netzwerk bei einer
mangelhaften Planung nicht oder nur eingeschränkt funktionsfähig sein kann und/oder das
31267
15
20
25
30
35
BN-4109 AT
Einhalten einer notwendigen Zykluszeit nicht garantiert werden kann, womit Datenpakete
verloren gehen können.
Es ist daher eine Aufgabe der gegenständlichen Erfindung, ein Verfahren anzugeben, welches ein Versenden von Datenpaketen zwischen Standard-Ethernet-Komponenten in einem Ethernet-Netzwerk und Komponenten in einem Industriellen Kommunikationsnetzwerk
ermöglicht, wobei eine bessere Echtzeitfähigkeit gewährleistet ist.
Diese Aufgabe wird erfindungsgemäß durch ein Verfahren zur Übertragung eines, vorzugsweise zyklischen, Datenpakets von einer Ethernet-Komponente, welche in einem Ethernet-Netzwerk innerhalb eines Mischnetzwerks angeordnet ist, an eine TSNKomponente, die in einem nach den Standards der Arbeitsgruppe IEEE 802.1 TSN konfigurierten Industriellen Kommunikationsnetzwerk innerhalb des Mischnetzwerks angeordnet ist, gelöst, wobei für das Datenpaket zumindest eine in den Standards der Arbeitsgruppe IEEE 802.1 TSN definierte Garantie vergeben wird, indem ein das Datenpaket beinhaltende Frame F1 im nach den Standards der Arbeitsgruppe IEEE 802.1 TSN konfigurierten Industriellen Kommunikationsnetzwerk von einer TSN-Bridge identifiziert, in einen das Datenpaket beinhaltende TSN-Stream umgewandelt und das Datenpaket im TSN-
Stream an die TSN-Komponente übermittelt wird.
Erfindungsgemäß wird somit das Industrielle Kommunikationsnetzwerk nach den Standards der Arbeitsgruppe IEEE 802.1 TSN konfiguriert, womit eine Vergabe von Garantien, z.B. für zyklische Datenpakete, ermöglicht wird. Das Industrielle Kommunikationsnetzwerk, welches nach den Standards der Arbeitsgruppe IEEE 802.1 TSN konfiguriert ist, wird in Folge der Einfachheit halber verkürzt als TSN-Netzwerk bezeichnet. Die im TSN-Netzwerk befindlichen Komponenten werden als TSN-Komponenten bezeichnet. Die in den Standards der Arbeitsgruppe IEEE 802.1 TSN konfigurierten Streams werden in Folge als TSN-Streams bezeichnet. Der außerhalb des TSN-Netzwerks befindliche Teil des Netzwerks wird allgemein als Ethernet-Netzwerk bezeichnet. Komponenten, die sich nicht im TSN-Netzwerk (oder anderen Industriellen Kommunikationsnetzwerken), sondern im (Ethernet-)Netzwerk befinden, werden als Ethernet-Komponenten bezeichnet. Ethernet-Frames werden der
Einfachheit halber als Frames bezeichnet.
Wird ein Frame, welches ein Datenpaket beinhaltet, ohne weitere Behandlung vom EthernetNetzwerk in das TSN-Netzwerk geschickt, so erfolgt dies definitionsgemäß als „best effort“, wodurch keine Garantie für das Datenpaket abgegeben werden kann. Aus diesem Grunde werden erfindungsgemäß TSN-Streams verwendet, womit die Kommunikation der TSNKomponenten mit den Ethernet-Komponenten verbessert wird. In einem TSN-Stream wird
ein Datenpaket von einer TSN-Komponente als Sender (Talker) über eine oder mehrere
4126”
15
20
25
30
35
BN-4109 AT
entsprechend konfigurierten TSN-Bridges an eine oder weitere TSN-Komponenten als
Empfänger (Listeners) übermittelt.
Eine Verwendung von TSN-Streams hat den Vorteil der einfacheren Abschätzung der benötigten Bandbreite zur Übertragung der Datenpakete im TSN-Netzwerk, da die Bandbreite von unverplanten Zeitfenstern und/oder die freie Bandbreite der TSNKomponenten bekannt ist. Somit kann die freie Bandbreite für weitere TSN-Streams verplant werden, indem weitere Zeitfenster für TSN-Streams vorgesehen werden, wie es die in IEEE 802.1Qcc eingeführten TSN Konfigurationsmöglichkeiten beschreiben. Die weiteren TSN-
Streams transportieren erfindungsgemäß weitere Datenpakete.
Wird z.B. eine Netzwerkgarantie eines TSN-Streams S1 überschritten, da diese zu viel Bandbreite benötigt, so wird ein anderer garantierter TSN-Stream davon nicht beeinflusst. Wenn an der TSN-Bridge nicht-reservierte Bandbreite frei ist, so kann diese (auf Kosten
von,„best effort“- Traffic) zur Verfügung gestellt werden.
Grundlegend könnte auch das gesamte Netzwerk ausschließlich aus TSN-Komponenten aufgebaut werden, womit nur ein globales TSN-Netzwerk existiert. Da die TSN-Funktionen der TSN-Komponenten jedoch nur bei Hochleistungsanwendungen, die nur einen Teil der Aufgaben umfassen, benötigt werden, ist ein nur teilweiser Aufbau durch TSN-Komponenten vorteilhaft. Insbesondere ist ein derartiger Aufbau als Mischnetzwerk wesentlich
kostengünstiger als ein reines TSN-Netzwerk.
Ethernet-Komponenten dienen in einem Mischnetzwerk somit als Zubringer zum TSNNetzwerk. Die Kommunikation innerhalb des Ethernet-Netzwerks (und außerhalb des TSNNetzwerks) kann in bekannter Weise durch Versand von Frames mit Datenpaketen erfolgen. Dabei können jedoch natürlich außerhalb des TSN-Netzwerks keine Garantien, sondern bestenfalls Schätzungen, für das jeweilige Datenpaket abgegeben werden. Dies betrifft auch Frames mit Datenpaketen, die an das TSN-Netzwerk gesendet werden, bevor sie im TSN-
Netzwerk eintreffen und in TSN-Streams umgewandelt werden.
Es können im Ethernet-Netzwerk (außerhalb des TSN-Netzwerks) zudem weiterhin entsprechende Maßnahmen, wie Isolierung, Überdimensionierung und „Network Calculus“, vorgesehen sein. Als Isolierung wird allgemein eine Verwendung einzelner Subnetzwerke, durch welche jeweils nur ein Teil des Datenverkehrs geführt wird, bezeichnet. Dadurch sind die potentiellen Störeinflüsse für den Echtzeitverkehr durch einen auftretenden NichtEchtzeitverkehr geringer. Für ein Ethernet-Netzwerk mit Isolierung wird natürlich mehr Netzwerkinfrastruktur, d.h. mehr Bridges und Verkabelung benötigt, als für ein EthernetNetzwerk ohne Isolierung. Eine Verwendung derartiger Maßnahmen im Ethernet-Netzwerk (außerhalb des TSN-Netzwerks) ist jedoch weiterhin weniger kostenintensiv als der Betrieb
eines reinen TSN-Netzwerks.
5126"
15
20
25
30
35
BN-4109 AT
Ein weiterer Vorteil eines Mischnetzwerks ist es, dass zusätzliche Ethernet-Komponenten mit dem Ethernet-Netzwerk als Teil des Mischnetzwerks verbunden werden können, ohne die bereits vorhandenen TSN-Streams zu beeinflussen, da die TSN-Streams nur im TSN-
Netzwerk als Teil des Mischnetzwerks existieren.
Ein Aufbau eines Mischnetzwerks ist weiters in einfacher Weise bewerkstelligbar, da Industrial Ethernet-Komponenten oftmals mit einem Standard-Ethernet-Anschluss versehen sind und das TSN-Netzwerk in einfacher Weise um weitere Ethernet-Komponenten erweitert werden kann, womit eine „Ethernet Insel“ im TSN-Netzwerk erzeugt werden kann. Das TSNNetzwerk stellt eine Erweiterung eines Ethernet-Netzwerks dar und ist daher voll rückwärtskompatibel. Die zusätzlichen Ethernet-Komponenten können jedoch bereits
vorhandene „best effort“ Frames beeinflussen.
Vorzugsweise erfolgt die Identifikation des TSN-Streams nach dem Standard IEEE 802.1CB. Es kann der TSN-Stream im TSN-Netzwerk somit mit dem Time-Aware Shaper des TSNStandards IEEE 802.1Qbv geshaped werden. Dies ist besonders vorteilhaft, wenn
beispielsweise ein Empfangszeitpunkt oder eine Bandbreite als Garantie vergeben wird.
Es können grundlegend zyklische Prozessdaten, Audio/Video-Daten und andere Streamingdienste, Konfigurationen, Netzwerktraces, Firmware-Downloads etc. als Datenpakete gesendet werden. Um die Frames dieser Datenpakete beim Eintritt in das TSNNetzwerk richtig erkennen zu können, kann eine Stream-Identifikationsfunktion, wie sie im Standard IEEE 802.1CB definiert ist, verwendet werden. Im Standard 802.1CB werden vier Stream-Identifikationsfunktionen definiert, wobei auch ein Zugriff auf die Headerinformationen von höheren Protokollen (IP, UDP, TCP, OPC UA etc.) möglich ist.
Für eine garantierte Bandbreite, Burstfähigkeit und/oder Latenz können ebenso der CreditBased Shaper (aus IEEE 802.1Q) oder der Asynchronous Traffic Shaper aus IEEE 802.1Qecr verwendet werden. Sehr oft werden diese Egress-Features (die den Traffic am Ausgang einer Bridge „shapen“) noch durch Ingress-Policing (IEEE 802.1Qci) unterstützt, um
fehlerhaft „geshapte“ oder gesendete TSN-Frames am Eingang einer Bridge auszusortieren.
Vorzugswiese wird der Frame beim Eintreffen in das nach den Standards der Arbeitsgruppe IEEE 802.1 TSN konfigurierten Industriellen Kommunikationsnetzwerk von einer TSN-EdgeBridge identifiziert, in den TSN-Stream umgewandelt und an die TSN-Komponente übermittelt. Eine TSN-Edge-Bridge ist eine TSN-Bridge, welche auch mit einer StandardEthernet-Komponente verbunden ist. Alternativ kann der Frame aber auch von einer TSNEdge-Bridge als „best effort“ entlang der Kommunikationsverbindung an weitere TSNBridges weitergesendet werden und erst von einer darauffolgenden TSN-Bridge in den TSN-
Stream umgewandelt und wiederum als solcher weitergeleitet werden.
6126”
15
20
25
30
35
BN-4109 AT
Vorzugsweise wird bei der Umwandlung des Frames in den TSN-Stream ein EthernetHeader des Frames durch einen TSN-Header ersetzt, was besonders vorzugsweise mittels
einer Retagging-Funktion nach dem Standard IEEE 802.1Qci erfolgt.
Der TSN-Header umfasst dann eine Stream-Adresse anstelle einer von Ethernet verwendeten (unicast) Destination-MAC-Adresse. Der Frame, welches das Datenpaket enthält, kann also einerseits aufgrund eines Ethernet-Headers identifiziert werden und andererseits kann der Ethernet-Header des ursprünglichen Frames bei der darauffolgenden
Umwandlung in den TSN-Stream durch einen TSN-Header ersetzt werden.
Eine häufig verwendete Funktion in managed Ethernet-Netzwerken sind virtuelle LANs (VLANS), wobei jede Ethernet-Komponente Mitglied in einem oder mehreren VLANs werden kann. Die zwischen Ethernet-Komponenten eines VLANs versendeten Frames werden mit einem entsprechenden Tag versehen (tagged Frames). Die Netzwerkinfrastruktur trägt dafür Sorge, dass diese Frames von Ethernet-Komponenten, die Mitglieder in anderen VLANs sind, nicht gesehen werden - auch nicht, wenn diese als Broadcast versendet werden. Die TSN-Streams im TSN-Netzwerk können als Erweiterung dieses Konzept gesehen werden, da mit VLANs Teilnetzwerke gekapselt werden und mit TSN-Streams konkrete Kommunikationsbeziehungen gekapselt werden. Daher kann das VLAN-Feld als Teil der Stream-Adresse von TSN-Streams verwendet werden. So schreibt ein TSN-Stream einen VLAN-Tag vor, welcher fixer Bestandteil der Stream-Adresse ist. Hierzu kann eine Retagging-Funktion, wie sie im Standard IEEE 802.1Qci beschrieben ist, verwendet werden. Das identifizierte Frame erhält somit einen neuen Header mit Stream-ID, womit das
Datenpaket als TSN-Stream und nicht als unspezifizierter „best effort“-Traffic behandelt wird.
Die Standards der Arbeitsgruppe IEEE 802.1 TSN erfordern einen VLAN-Tag und definieren (als eine der Möglichkeiten) DMAC + VLAN-Tag als Stream-Adresse. Diese Stream-Adresse umfasst insgesamt 10 Byte und wird beim Retagging überschrieben. Die anderen HeaderFelder (in diesem Fall Source-MAC-Adresse und Ethertype bleiben vorzugsweise unverändert). Der Ethernet-Standard erlaubt nur optional den 4 Byte großen VLAN-Tag, in welchem VLANs und Prioritäten definiert werden können. Wenn dieser VLAN-Tag nicht vorhanden war, so kann er beim Retagging eingefügt werden, wodurch der Frame
entsprechend verlängert wird.
Vorzugsweise wird eine minimale Bandbreite des TSN-Streams und/oder eine maximale Latenz des TSN-Streams und/oder eine definierte Burstfähigkeit des TSN-Streams und/oder ein definierter Empfangszeitpunkt des TSN-Streams als Garantie vergeben. Dies ist in auf Standard-Ethernet Komponenten basierenden Industrial Ethernet-Netzwerken nicht möglich und wird daher durch die Verwendung eines TSN-Netzwerks als Industrielles
Kommunikationsnetzwerk ermöglicht.
7126”
15
20
25
30
35
BN-4109 AT
Als Burst wird ein möglichst rasches Versenden einer großen Menge an Daten bezeichnet. Dabei ist es jedoch ohne entsprechende Vorkehrungen sehr wahrscheinlich, dass einzelne Frames des Bursts mit anderem Traffic im Netzwerk kollidieren. In einem TSN-Netzwerk kann der Standard IEEE 802.1 TSN Qav verwendet werden, welcher für einen Burst den sogenannten Credit-Based-Shaper definiert. Ein Sender kann in einem TSN-Netzwerk durch „Ruhe“ bzw. „Nicht-Versenden“ Credits ansparen, die er dann beim Versenden von TSNFrames ausgeben muss. Dadurch wird die maximale Größe eines möglichen Bursts definiert. Wenn der Sender keine Credits mehr hat, muss er jeweils nach einem Frame warten, bis er genug Credits für den nächsten Frame beisammen hat. Dadurch werden seine Frames
ziemlich gleichmäßig über die Zeit verteilt.
Die Standards der Arbeitsgruppe IEEE 802.1 TSN umfassen verschiedene Traffic-ShapingMechanismen. Der Standard (802.1) QAbv kann beispielsweise zeitliche Garantien abgeben. Es kann auch der Standard (802.1) Qav verwendet werden, um Latenzen und Bandbreiten zu reservieren. Der Standard (802.1) Qci kann wiederum verwendet werden, um Bandbreiten zu beschränken. Es können natürlich auch alle (relevanten) weiteren in IEEE 802.1 TSN enthaltenen/referenzierten Standards für die Implementierung von Traffic-Garantien
verwendet werden (wie Ach, Qcr etc.).
Die Garantien können für zyklisch gesendete Datenpakete, aber auch für „unregelmäßige“ (sporadisch gesendete) Datenpakete wie Videostreams oder für Internetdownloads etc. vergeben werden. Welchen Inhalt das Datenpaket aufweist, ist für die Vergabe von Garantien nicht relevant, wobei die Wahl der Konfiguration natürlich an den angenommenen
Anforderungen der Datenpakete orientiert werden kann.
Werden zyklischen Prozessdaten als Datenpakete versendet, so werden vorzugsweise Garantien auf den Empfangszeitpunkt oder auf die Latenz vergeben. Bei Audio/Video-Daten oder Konfigurationsdaten als Datenpakete werden vorzugsweise Garantien auf die Bandbreite vergeben. Bei Traces und/oder Downloads als Datenpakete werden
vorzugsweise Garantien auf Burstfähigkeit und Latenz vergeben.
Die Standards der Arbeitsgruppe IEEE 802.1 TSN definieren unter anderem ShapingMechanismen für Echtzeit, Bandbreite, Burstfähigkeit und Latenz. Vorzugsweise werden somit für die Vergabe von Garantien für den TSN-Stream TSN-Shaping-Mechanismen verwendet. Damit können jegliche Garantien, die in den Standards der Arbeitsgruppe IEEE 802.1 TSN definiert werden, vergeben werden. Dies kann erfolgen, indem in der TSN-Bridge, welche eine Umwandlung in den TSN-Stream durchführt, eine Shaper-Konfiguration vorgenommen wird. Weiters wird die Shaper-Konfiguration in allen weiteren TSN-Bridges,
über welche der TSN-Stream geführt wird, vorgenommen.
8/26"
15
20
25
30
35
BN-4109 AT
Die Vergabe eines Empfangszeitpunkts als Garantie kann erfolgen, indem das Datenpaket in einem TSN-Stream während eines vorgegebenen Zeitfensters eines Zyklus an die TSNKomponente übermittelt wird. Für das Verschicken von zyklischen Daten mit Empfangszeitpunktgarantie werden im TSN-Netzwerk bei jeder TSN-Bridge, über welche der TSN-Stream geleitet wird, Zeitfenster exklusiv für diesen TSN-Stream konfiguriert. Garantiert der Sender (Talker) darüber hinaus seinen Sendezeitpunkt zu jedem Zyklus, so kann der Versand des TSN-Streams optimiert werden, da die Zeitfenster im TSN-Netzwerk sehr eng
und ohne große Puffer aneinandergelegt werden können.
Wird in einem TSN-Netzwerk ein Shaping Mechanismus gleichzeitig mit „best effort“ Traffic oder mehreren Shaping-Mechanismen verwendet, dann wird dies allgemein als „converged“ bezeichnet, womit sich ein sogenanntes „Converged Netzwerk“ ergibt. In einem „Converged Netzwerk“ werden verschiedene Arten von Datenverkehr mit unterschiedlichen Anforderungen (Laufzeit, Bandbreite, Burst-Fähigkeit etc.) gleichzeitig auf einer
Netzwerkinfrastruktur abgebildet.
Werden mehrere Traffic-Shaping-Mechanismen in einem TSN Netzwerk verwendet, so sind in der Regel nicht immer alle Arten von Traffic mit voller reservierter Bandbreite aktiv. Somit kann zu Optimierungszwecken nicht genutzte Bandbreite von einem Shaper einem anderen Shaper zur Mitbenutzung überlassen werden. Es können auch TSN-Streams mit niedriger Priorität durch TSN-Streams mit höherer Priorität unterbrochen werden, wenn dadurch die TSN-Streams mit niedriger Priorität ihre Garantien einhalten können (wie in IEEE 802.1Qbu und IEEE 802.3br beschrieben).
Vorzugsweise wird bei einem Übertragen eines Datenpakets von der im nach den Standards der Arbeitsgruppe IEEE 802.1 TSN konfigurierten Industriellen Kommunikationsnetzwerk befindlichen TSN-Komponente an eine im Ethernet-Netzwerk, außerhalb des nach den Standards der Arbeitsgruppe IEEE 802.1 TSN konfigurierten Industriellen Kommunikationsnetzwerk, befindliche Ethernet-Komponente ein das Datenpaket beinhaltender TSN-Stream von einer TSN-Bridge in ein das Datenpaket beinhaltenden
Frame umgewandelt und das Datenpaket im Frame an die Ethernet-Komponente übermittelt.
Bei der Umwandlung des TSN-Streams in den Frame kann der TSN-Header des TSNStreams durch einen Ethernet-Header, vorzugweise durch ein Retagging-Funktion nach dem Standard IEEE 802.1Qci, ersetzt werden.
Es kann bei der Umwandlung des TSN-Streams in den Frame der TSN-Header des TSNStreams der VLAN-Tag entfernt werden oder der TSN-Header des TSN-Streams für den
Frame weiterverwendet werden.
Wird der VLAN Tag gelöscht, so gehen natürlich die Features der des VLAN-Tags, d.h. die
Definition von Prioritäten von Frames und der Konfiguration von virtuellen Netzwerken,
9/26”
15
20
25
30
BN-4109 AT
verloren. Damit können nur Komponenten, die das gleiche VLAN konfiguriert haben, Frames
aneinander versenden.
Wird der TSN-Header weiterverwendet, so wird der TSN-Header von unkonfigurierten Ethernet-Komponenten als Frame-Header interpretiert. Im TSN-Header ist konventionsgemäß das Multicast-Bit gesetzt, was dazu führt, dass im Ethernet-Netzwerk das Frame überallhin geschickt wird. Somit muss der jeweilige Empfänger so konfiguriert sein, dass er die Multicast-Adresse empfängt. Weiters wird das Ethernet-Netzwerk mit solchen
Multicast-Frames stärker belastet.
Wird der TSN-Stream unverändert ins Ethernet-Netzwerk geschickt, so wird dort die vom TSN-Stream verwendete Multicast Destination-MAC-Adresse als Broadcast interpretiert und die Bridges des Ethernet-Netzwerks verschicken den Frame an alle Ethernet-Komponenten. Durch diese Vorgehensweise wird jedoch ein Teil des Netzwerks mit überflüssigen Daten überflutet. Daher ist es grundlegend vorteilhaft, den TSN-Stream in einen Frame
umzuwandeln.
Vorteilhafterweise kann beim Übertragen eines TSN-Streams von der im Industriellen Kommunikationsnetzwerk befindlichen TSN-Komponente an eine im Ethernet-Netzwerk, außerhalb des Industriellen Kommunikationsnetzwerks, befindliche Ethernet-Komponente
der TSN-Stream von einer TSN-Bridge in einen Frame umgewandelt werden.
Vorzugsweise wird der TSN-Stream beim Verlassen des nach den Standards der Arbeitsgruppe IEEE 802.1 TSN konfigurierten Industriellen Kommunikationsnetzwerk von
einer TSN-Edge-Bridge in das das Datenpaket beinhaltende Frame umgewandelt.
Anstatt der TSN-Edge-Bridge kann auch eine weiter im Inneren des TSN-Netzwerks angeordnete TSN-Bridge die Umwandlung in einen Frame übernehmen. In diesem Fall wird der Frame auf der Kommunikationsverbindung von der umwandelnden TSN-Bridge bis zur TSN-Edge-Bridge als „best effort“ versandt, obwohl er sich eigentlich noch im TSN Netzwerk befindet.
Die Standards der Arbeitsgruppe IEEE 802.1 TSN umfassen insbesondere den Standard IEEE 802.1Q-2018, welcher die TSN-Funktionen beschreibt. Weiters umfassen die Standards der Arbeitsgruppe IEEE 802.1 TSN den Standard IEEE 802.1CB-2017.
Die Standards IEEE 802.1Qbv-2015, IEEE 802.1Qci-2017, IEEE 802.1Qch-2017, IEEE 802.1Qbu-2016 stellten bis 2018 Amendments des Standard IlEEE.802.1Q-2014 dar und stellten somit eigenständige Standards dar und wurden in den Standard IEEE 802.1Q-2018 aufgenommen. IEEE 802.1Qav-2009 wurde schon in den Standard in IlEEE.802.1Q-2014
aufgenommen.
„9
15
20
25
30
BN-4109 AT
Der Standard IEEE 802.1Qcc-2018 wurde erst im Jahr 2018 veröffentlicht und stellt somit ein Amendment zum Standard IEEE 802.1Q-2018 dar.
Der Standard IEEE 802.1Qav war im Standard IEEE 802.1Qav-2009 enthalten und ist nunmehr ebenfalls im Standard IEEE 802.1Q-2018 enthalten.
Das Projekt IEEE 802.1Qcr ist zum Zeitpunkt des Einreichens der gegenständlichen Patentanmeldung noch nicht als Standard veröffentlicht und hat die Projektnummer IEEE P802.1Qcr.
Der Standard IEEE Std. 802.3br-2016 ist ein Amendment des Standards IEEE Std. 802.32015 und nun im Standard IEEE 802.3-2018 enthalten.
Die gegenständliche Erfindung wird nachfolgend unter Bezugnahme auf die Figuren 1 bis 3 näher erläutert, die beispielhaft, schematisch und nicht einschränkend vorteilhafte
Ausgestaltungen der Erfindung zeigen. Dabei zeigt Fig.1 ein Ethernet-Netzwerk und ein eingebettetes TSN-Netzwerk, Fig.2 eine Umwandlung eines Frames in einen TSN-Stream,
Fig.3 einen Empfangszeitpunkt als zeitliche Garantie.
Fig. 1 zeigt ein Mischnetzwerk 1, welches ein Ethernet-Netzwerk 3 umfasst. Das EthernetNetzwerk 3 umfasst wiederum eine Anzahl Ethernet-Komponenten E1, E2, E3. Es werden Netzwerk-Komponenten, die zwar nach IEEE 802.1Q (und den weiteren üblicherweise anzuwendenden Standards für Ethernet Bridges), aber nicht entsprechend den Standards der Arbeitsgruppe IEEE 802.1 TSN konfiguriert sind, als Ethernet-Komponenten E1, E2, E3 bezeichnet. Es ist im Ethernet-Netzwerk 3 beispielhaft ein Ethernet-Controller als EthernetKomponente E1 vorgesehen, welcher mit einem Ethernet-Feldgerät als zweite EthernetKomponente E2 und mit einem Ethernet-Drucker als dritte Ethernet-Komponente E3 verbunden ist. Der Ethernet-Controller E1 und das Ethernet-Feldgerät E2 können zyklischen Datenverkehr verarbeiten, der Ethernet-Drucker E3 hingegen nicht. Die applikative Funktion der Ethernet-Komponenten E1, E2, E3 ist für die Funktion der Erfindung jedoch nicht maßgeblich. Ethernet-Controller E1, Ethernet-Feldgerät E2 und Ethernet-Drucker E3 werden daher allgemein als Ethernet-Komponenten E1, E2, E3 bezeichnet. Die Kommunikationsverbindungen zwischen den Ethernet-Komponenten E1, E2, E3 sind in den Fig. 1 und 2 als Balken dargestellt und verbinden Ports der jeweiligen EthernetKomponenten E1, E2, E3.
11/26”
15
20
25
30
35
BN-4109 AT
Es werden im Ethernet-Netzwerk 3 zwischen den Ethernet-Komponenten E1, E2, E3 Frames F2, F3 versendet, welche jeweils Datenpakete D2, D3 beinhalten. So kommuniziert die Ethernet-Komponente E2 über eine verbindende Kommunikationsverbindung mit der Ethernet-Komponente E1 (und umgekehrt) über ein im Frame F2 enthaltenes Datenpaket D2. Weiters kommuniziert die Ethernet-Komponente E3 über eine verbindende Kommunikationsverbindung mit der Ethernet-Komponente E1 (und umgekehrt) über ein im Frame F3 enthaltenes Datenpaket D3. Diese Kommunikation ist in Fig. 1 durch die Pfeile entlang der jeweiligen Kommunikationsverbindungen zwischen den Ethernet-Komponenten E1, E2, E3 angedeutet. Innerhalb des Ethernet-Netzwerks 3 kann der Versand der
Datenpakete D2, D3 nur in Frames F2, F3 und damit ohne Angabe von Garantien erfolgen.
Die Ethernet-Komponenten E1, E2, E3 können managed (verwaltet) oder auch unmanaged (nicht verwaltet) ausgeführt sein. Unmanaged Ethernet-Komponenten E1, E2, E3 können in einfacher Weise mit dem Ethernet-Netzwerk 3 verbunden werden (Plug-and-Play), bieten jedoch keine Möglichkeit zur Konfiguration oder Verwaltung. Eine unmanaged EthernetKomponente E1, E2, E3 erlernt die Zieladresse einer weiteren, über einen Port erreichbaren, Ethernet-Komponente E1, E2, E3 selbständig durch Auswertung von Quelladressen von Frames F2, F3, welche von dieser weiteren Ethernet-Komponente E1, E2, E3 gesendet werden. Ist eine Zieladresse eines Frames F2, F3 noch unbekannt (da von der weiteren Ethernet-Komponente E1, E2, E3 noch kein Frame F2, F3 erhalten wurde), so wird der Frame F2, F3 an alle Ports und damit an alle Ethernet-Komponenten E1, E2, E3 weitergeschickt, was als Flooding bezeichnet wird. Managed Ethernet-Komponenten E1, E2, E3 können hingegen beispielsweise durch ein externes Gerät konfiguriert, verwaltet und/oder überwacht werden. So kann beispielsweise eine Adresstabelle konfiguriert werden oder das Ethernet-Netzwerk 3 mittels VLANs in unabhängige Segmente geteilt werden. Es können im Rahmen der gegenständlichen Erfindung managed und/oder unmanaged Ethernet-
Komponenten E1, E2, E3 und/oder VLANs verwendet werden.
Die im Rahmen des dargestellten Ausführungsbeispiels beschriebenen EthernetKomponenten E1, E2, E3 und TSN-Komponenten TSN-A, TSN-F, TSN-C sind in der Lage Datenpakete zu erzeugen und zu empfangen und sind weiters Teil der Netzwerkinfrastruktur mit mehr als einem Port. Es handelt sich somit in IEEE Nomenklatur um Bridged Endpoints. Ohne Beschränkung der Allgemeinheit gelten aber alle Endpoint-spezifischen Aussagen ebenfalls für Endpoints mit nur einem Port und alle Netzwerkinfrastruktur-spezifischen
Aussagen ebenfalls für reine Netzwerkinfrastrukturgeräte, d.h. reine Bridges.
Zusätzlich zum Ethernet-Netzwerk 3 umfasst das Mischnetzwerk 1 zumindest ein Industrielles Kommunikationsnetzwerk, vorzugsweise mit zyklischem Datenverkehr, welches erfindungsgemäß derart konfiguriert wird, dass Funktionen nach den Standards der
Arbeitsgruppe IEEE 802.1 TSN unterstützt werden. Dieser Teil wird in Folge als TSN-
„11
15
20
25
30
35
BN-4109 AT
Netzwerk 2 bezeichnet kann als „TSN-Insel“ vom Ethernet-Netzwerk 3 umgeben sein. Das TSN-Netzwerk 2 kann auch an das Ethernet-Netzwerk 3 angrenzen, wie es in Fig. 1 und 2 dargestellt ist. Das TSN-Netzwerk 2 umfasst die TSN-Komponenten TSN-A, TSN-F und TSN-C, beispielsweise als Feldgeräte, wobei die TSN-Komponente TSN-F auch als TSNEdge-Bridge dient. Die Kommunikationsverbindungen zwischen den TSN-Komponenten TSN-A, TSN-F, TSN-C sind ebenso als Balken dargestellt und verbindet die Ports der jeweiligen TSN-Komponenten TSN-A, TSN-F, TSN-C. Ebenso besteht im Mischnetzwerk 1 eine Kommunikationsverbindung zwischen dem Ethernet-Netzwerk 3 und dem TSNNetzwerk 2 in Form einer Kommunikationsverbindung zwischen der Ethernet-Komponente E1 und der TSN-Komponente TSN-C über die TSN-Edge-Bridge TSN-F.
Es könnten im Mischnetzwerk 1 natürlich auch ein oder mehrere weitere Ethernet-Netzwerke 3 und/oder ein oder mehrere weitere industrielle Netzwerke, vorzugsweise mit zyklischem Datenverkehr, vorgesehen sein. Diese ein oder mehreren weiteren Industriellen Netzwerke können ebenso nach den Standards der Arbeitsgruppe IEEE 802.1 TSN konfiguriert sein und damit ein oder mehrere TSN-Netzwerke 2 darstellen. Jegliche Industrielle Netzwerke, bzw. TSN-Netzwerke können im Mischnetzwerk 1 an andere Ethernet-Netzwerke 3 und/oder TSN-Netzwerke 2 angrenzen und/oder als „TSN-Insel“ von anderen Ethernet-Netzwerken 3
und/oder TSN-Netzwerken 2 umgeben sein.
Wird ein Datenpaket D2, D3 in einem Frame F2, F3 von einer Ethernet-Komponente E1, E2, E3 zu einer weiteren Ethernet-Komponente E1, E2, E3 gesendet, so kann das besagte Frame F2, F3 statt einer direkten Übertragung über die direkt verbindende Kommunikationsverbindung auch durch das TSN-Netzwerk 2 durchgeroutet werden. Dabei würde jedoch keine Umwandlung in einen TSN-Stream und keine Vergabe von Garantien
erfolgen.
Innerhalb eines TSN-Netzwerks 2 kann die Übertragung von TSN-Datenpaketen DO, D4 zwischen den jeweiligen TSN-Komponenten TSN-C, TSN-F, TSN-A mit bekannten TSN Traffic-Shaping-Mechanismen konfiguriert werden. So kann beispielsweise die TSNKomponente TSN-F einem TSN-Stream SO mit einem Datenpaket DO an die TSNKomponente TSN-C senden (wie in Fig. 2 angedeutet) und umgekehrt (nicht in Fig. 2 dargestellt). Dabei können für die Übertragung des Datenpakets DO Garantien abgegeben werden, beispielsweise eine maximal benötigte Bandbreite, eine maximale Latenz, ein garantierter Sendezeitpunkt und/oder Empfangszeitpunkt etc. Die maximal zur Verfügung stehenden Garantien müssen sich selbstverständlich den Randbedingungen der TSNKomponenten TSN-C, TSN-F, TSN-A, wie senderseitig auftretende Netzwerklast, Weiterleitungs-Latenzen, verfügbare Bandbreite bzw. Datenübertragungsrate (z.B. Gigabit) etc., im TSN-Netzwerk 2 unterordnen. Diese Überprüfung ist eine Aufgabe des
Konfigurationstools und für die Erfindung nicht maßgeblich.
13/56”
15
20
25
30
35
BN-4109 AT
Weiters wird in Fig. 2 beispielhaft ein weiterer TSN-Stream S4 mit einem Datenpaket D4 von der TSN-Komponente TSN-A über die TSN-Komponente TSN-F an die TSN-Komponente TSN-C gesendet. Die Konfiguration des TSN-Netzwerks 2 sorgt dafür, dass der TSN-Stream S4 und der TSN-Stream SO von der TSN-Komponente TSN-F zur TSN-Komponente TSN-C gesendet werden können. Dabei stört weder der TSN-Stream S4 den TSN-Stream SO, noch umgekehrt, obwohl dieselbe Kommunikationsverbindung verwendet wird. Dies ist selbst dann möglich, wenn der weitere TSN-Stream S4 und der TSN-Stream SO die gleichen
Garantien (Empfangszeitpunkt, Bandbreite, Latenz etc.) fordern.
Würde hingegen innerhalb des Ethernet-Netzwerks 3 ein weiterer Frame mit einem bereits vorgesehenen Frame F2, F3 zusammentreffen, d.h. zum gleichen Zeitpunkt an den gleichen Port weiter geleitet werden, so würde der weitere Frame den Frame F2, F3 stören und verzögern, selbst wenn dies nicht über die gleiche Kommunikationsverbindung erfolgt. Der auftretende Jitter würde dazu führen, dass einmal der weitere Frame und einmal der vorgesehene Frame F2, F3 bearbeitet werden. Im Gegenzug dazu kann im TSN-Netzwerk genau konfiguriert werden, wann welcher Frame weitergeleitet werden soll und die
Weiterleitung ist daher trotz Jitter nach außen immer gleich.
In Fig. 2 erfolgt zusätzlich zu den TSN-Streams SO, S4 die Übertragung eines Datenpakets D1 von der Ethernet-Komponente E1 über die TSN-Komponente TSN-F (als TSN-EdgeBridge) an die TSN-Komponente TSN-C. Dieses trifft ungefähr zeitgleich mit der Übertragung der TSN-Streams SO, S4 bei der TSN-Komponente TSN-F ein. Im Gegensatz zur Übertragung eines TSN-Streams SO, S4 von der TSN-Komponente TSN-F an die TSNKomponente TSN-C, kann für eine Übertragung eines Frames F1 selbst grundlegend keine zeitliche Garantie abgegeben werden. Je nach Eintreffzeitpunkt würde der Frame F1 noch vor den beiden TSN-Streams SO, S4 oder erst danach weitergeleitet. Es wird daher erfindungsgemäß der Frame F1, welcher das Datenpaket D1 enthält, im TSN-Netzwerk 2 von einer TSN-Bridge identifiziert, was hier durch die TSN-Komponente TSN-F in Form einer TSN-Edge-Bridge erfolgt. Ab dieser Identifizierung sind die notwendigen Übertragungseigenschaften des zu übertragenden Datenpakets D1 bekannt, da diese vorkonfiguriert sind. Nach der Identifizierung wird der Frame F1 in einen TSN-Stream $S1 umgewandelt und im TSN-Netzwerk 2 entsprechend verarbeitet. Diese Umwandlung erfolgt beispielsweise, Indem entsprechend der Konfiguration der Ethernet-Header des Frames F1 durch einen TSN-Header vom TSN-Stream $S1 ersetzt wird. Der TSN-Stream $S1 wird daraufhin von der TSN-Bridge (hier TSN-Komponente TSN-F) an die adressierte(n) TSNKomponente(n) (hier TSN-Komponente TSN-C) über die vorgesehenen Kommunikationsverbindungen gesendet und entsprechend der Konfiguration behandelt. Dadurch wird der weitere Datenverkehr (hier in Form der TSN-Streams SO, S4 mit den
Datenpaketen DO, D4) auf derselben Kommunikationsverbindung nicht beeinflusst — im
14/36”
15
20
25
30
35
BN-4109 AT
converged Netzwerk werden somit die Garantien für alle TSN-Streams SO, S1, S4 eingehalten. In Fig. 2 dient beispielhaft lediglich eine Kommunikationsverbindung von der TSN-Komponente TSN-F zur TSN-Komponente TSN-C als Kommunikationsverbindung. Natürlich könnte der TSN-Stream S1 auch über weitere Kommunikationsverbindungen und
TSN-Komponenten geleitet werden.
Die Identifizierung des Frames F1 und die Umwandlung des Frames F1 in einen TSNStream S1 kann wie in diesem Ausführungsbeispiel beschrieben sofort beim Eintreffen im TSN-Netzwerk 2 an einer TSN-Edge-Bridge (hier an der TSN-Komponente TSN-F) des TSN-
Netzwerks 2 erfolgen.
Es könnte jedoch stattdessen, insbesondere in größeren Netzwerken, auch der Frame F1 von einer TSN-Edge-Bridge erst als „best effort“ weitergeleitet werden und von einer der darauffolgenden TSN-Bridges identifiziert und in einen TSN-Stream S1 umgewandelt werden. Dies kann insbesondere vorteilhaft sein, wenn die Konfigurationskapazitäten der
TSN-Edge-Bridge nicht ausreichen.
Mit der erwähnten Retagging-Methode können alle aus dem Ethernet-Netzwerk 3 stammenden Frames in TSN-Streams umgewandelt werden, vorausgesetzt, es ist im TSN-
Netzwerk 2 ausreichend Bandbreite vorhanden.
Wird ein Frame mit einem Datenpaket als „best effort“ in das TSN-Netzwerk 2 verschickt, so erfolgt das ohne Garantie, insbesondere ohne Zeitgarantie, sofern im TSN-Netzwerk 2 keine Umwandlung in einen TSN-Stream erfolgt. Das betreffende Frame wird dann auch nach dem Eintreffen im TSN-Netzwerk 2 als Frame behandelt. Es werden also keine Garantien abgegeben, da keine entsprechenden Mechanismen konfiguriert sind. Das kann dazu führen, dass das Datenpaket mit unvorhersehbaren Verzögerungszeiten ankommt. Je mehr Bandbreite im TSN Netzwerk 2 für TSN-Streams SO, S1, S4 reserviert ist, desto weniger Bandbreite bleibt für Frames womit die (Ethernet-)Frames ohne Umwandlung in TSNStreams auch im TSN-Netzwerk 2 unvorhersehbare Verzögerungen erfahren oder sogar
ganz verworfen werden können.
Fig. 3 zeigt einige Kommunikationsbeziehungen innerhalb des Mischnetzwerks 1. Auf der linken Seite ist das TSN-Netzwerk 2, hier in Form der TSN-Komponenten TSN-A, TSN-C und TSN-F, beispielhaft ausgeführt als Feldgeräte, dargestellt. Auf der rechten Seite ist das Ethernet-Netzwerk 3 dargestellt, wobei hier beispielhaft nur die Ethernet-Komponente E1
betrachtet wird.
Es wird entsprechend Fig. 2 im TSN-Netzwerk 2 ein Datenpaket DO als TSN-Stream SO von der TSN-Komponente TSN-F an die TSN-Komponente TSN-C übertragen. Weiters wird ein Datenpaket D4 als TSN-Stream S4 von der TSN-Komponente TSN-A über die TSNKomponente TSN-F an die TSN-Komponente TSN-F übertragen.
15/56"
15
20
25
30
35
BN-4109 AT
Da für die TSN-Streams SO, S4 im TSN-Netzwerk 2 entsprechend Ressourcen freigehalten werden, können für die TSN-Streams SO, S4 Garantien, insbesondere zeitliche Garantien,
abgegeben werden.
Für die Bereitstellung einer Zeitgarantie können im Rahmen der Konfiguration künstliche Zyklen z1, z2 mit einer Zykluszeit (von beispielsweise 10ms) eingeführt werden. In Fig. 3 sind zwei zeitliche Zyklen z1, z2 entlang der Zeitachse t dargestellt. Im TSN-Netzwerk 2 sind in jedem Zyklus z1, z2 einzelne Zeitfenster tO, t1, t2 vorgesehen. Das Zeitfenster tO ist hier für den TSN-Stream SO mit dem Datenpaket DO vorgesehen. Das Zeitfenster t2 ist für den TSN-Stream S4 mit dem Datenpaket D4 vorgesehen. Das Zeitfenster t1 ist für den TSNStream S1 vorgesehen und wird weiter unter behandelt. Es wird für die TSN-Streams SO, S1, S4 eine Zeitgarantie abgegeben, indem für die Kommunikationsverbindung zwischen den TSN-Komponenten TSN-F und TSN-C in jedem Zyklus z1, z2 ein exklusives Zeitfenster tO, t1, t2 für einen zugehörigen TSN-Stream SO, S1, S4 konfiguriert wird. Es wird somit im jeweiligen Zeitfenster tO, t1, t2 nur der reservierte TSN-Stream SO, S1, S4 weiterleitet. Daraus kann ermittelt werden, wann der jeweilige TSN-Stream SO, S1, S4 samt
beinhaltendem Datenpaket DO, D1, D4 empfangen wird, womit eine Zeitgarantie realisiert ist.
Für den TSN-Stream SO sind die Empfangszeitpunkte für die TSN-Komponente TSN-C im Zeitfenster tO des jeweiligen Zyklus z1, z2 garantiert, wenn die TSN-Komponente TSN-F die vorgesehenen Sendezeitpunkte des TSN-Streams SO einhalten kann. Sendet also die TSNKomponente TSN-F den TSN-Stream SO zum vorgesehenen Sendezeitpunkt an die TSNKomponente TSN-C, so wird der TSN-Stream SO im gleichen Zeitfenster t0 des aktuellen Zyklus z1, z2 an die TSN-Komponente TSN-C gesendet. Es wird im TSN-Netzwerk 2 für den das Datenpaket DO beinhaltenden TSN-Stream SO auf der Kommunikationsverbindung zwischen der TSN-Komponente TSN-F und der TSN-Komponente TSN-C die entsprechende Bandbreite freigehalten. Wird der Sendezeitpunkt für einen TSN-Stream SO mit dem Datenpaket DO eingehalten, so kommt dieser also immer im selben Zyklus z1, z2 an der TSN-Komponente TSN-C an.
Es kann aufgrund eines Fehlers in einer oder einer falschen Konfiguration einer TSNKomponente TSN-A, TSN-F, TSN-C, der Fall eintreten, dass der vorgesehene Sendezeitpunkt für den TSN-Netzwerk 2 internen TSN-Stream SO nicht eingehalten wird. Damit kann keine Garantie für einen Empfang im Zeitfenster tO0 des aktuellen Zyklus z1 abgegeben werden. Kann jedoch zumindest die maximale Größe des im TSN-Stream SO enthaltenen Datenpakets DO eingehalten werden, so kann ein Zyklus als maximale Latenz garantiert werden. Es wird dabei das Datenpaket DO bis zum Zeitfenster t0 des folgenden Zyklus z2 gepuffert und dann in diesem Zeitfenster tO verschickt. Es ist somit in diesem Fall
keine Garantie für das Zeitfenster t0 im aktuellen Zyklus z1 möglich. Daher wird jedoch eine
16/56”
15
20
25
30
35
BN-4109 AT
Garantie für das Zeitfenster t0 im nächsten Zyklus z2 abgegeben. Gleiches gilt für den TSNStream S4 mit dem Datenpaket D4.
Es wird nun von der Ethernet-Komponente E1 ein Datenpaket D1 in einem Frame F1 an das TSN-Netzwerk 2 gesendet. Dabei wird der Frame F1 von der TSN-Komponente TSN F als TSN-(Edge)-Bridge identifiziert und in einen TSN-Stream S1 gewandelt. Das Datenpaket D1 wird nach der Umwandlung des Frames F1 in den TSN-Stream S1 an die TSN-Komponente TSN-C gesendet. Durch diese Umwandlung kann auch für das von einer EthernetKomponente E1 an eine TSN-Komponente TSN-C gesendete Datenpaket D1 eine Garantie vergeben werden. Eine Zeitgarantie kann vergeben werden, indem für den TSN-Stream S1
in jedem Zyklus z1, z2 das Zeitfenster t1 reserviert wird.
Kommt das Datenpaket D1 ohne Verzögerung im TSN-Netzwerk 2 an und wird das zugehörige Frame F1 in einen TSN-Stream S1 gewandelt, so kann dieser im selben Zyklus z1, z2 im dafür vorgesehenen Zeitfenster t1 übertragen werden. Mit der Umwandlung in einen TSN-Stream S1 und der Konfiguration eines zugehörigen Zeitfensters t1 wird also sichergestellt, dass das Datenpaket D1 als TSN-Stream S1 immer im Zeitfenster t1 eines Zyklus z1, z2 an der TSN-Komponente TSN-C ankommt. Es wird damit verhindert, dass das Datenpaket D1 durch zu umfangreichen Datenverkehr (z.B. von anderen TSN-
Komponenten) verworfen wird.
Wie oben anhand der TSN-Streams DO und D4 erwähnt kann für einen TSN-Netzwerk „Internen“ TSN-Stream der Fall eintreten, dass ein Sendezeitpunkt nicht eingehalten wird. Dieser Fall tritt jedoch selten ein. Im Gegensatz dazu stammt das Datenpaket D1 jedoch nicht aus dem TSN-Netzwerk 2, sondern aus dem umliegenden Ethernet-Netzwerk 3. Daher kann es (im Gegensatz zu den aus dem TSN-Netzwerk 2 stammenden TSN-Streams SO, S4) zu nicht vorhersehbaren Verzögerungen kommen, bevor der Frame F1 mit dem Datenpaket D1 das TSN-Netzwerk 2 erreicht, wie in Fig. 3 dargestellt. Das Datenpaket D1 kann zwar in einen TSN-Stream S1 gewandelt, jedoch nicht mehr im aktuellen Zyklus z1 in das vorgesehene Zeitfenster t1 eingeordnet werden. Es ist somit keine Garantie für das Zeitfenster t1 im aktuellen Zyklus z1 möglich. Daher wird jedoch eine Garantie für das Zeitfenster t1 im nächsten Zyklus z2 abgegeben. Vorteilhafterweise wird daher das Versenden von F1 im Ethernet-Netzwerk 3 möglichst an den Anfang des Zyklus z1, z2 gelegt und das reservierte Zeitfenster t1 im TSN-Netzwerk 2 möglichst ans Ende des Zyklus z1, z2. Dadurch wird erreicht, dass ein hoher Anteil der Datenpakete DO, D4 noch innerhalb des
gleichen Zyklus z1, z2 ihr Ziel erreicht.
Für den zweiten Zyklus z2 wird durch den späteren Start des Frames F1 an der EthernetKomponente E1 ein Jitter angedeutet. Das bedeutet, dass der Frame F1 im folgenden Zyklus
noch später ankommt. Der Jitter entsteht durch einen nicht genauen Sendezeitpunkt an der
17/26"
15
20
25
30
35
BN-4109 AT
Ethernet-Komponente und individuelle Weiterleitungs-Verzögerungen (beispielsweise durch andere Frames) bei jeder Bridge entlang der Kommunikationsverbindung, über welche der
Frame F1 geleitet wird. Es ist somit analog zum ersten Zyklus z1 auch im zweiten Zyklus z2 keine Garantie für das Zeitfenster t1 möglich, weshalb eine eine Garantie für das Zeitfenster
t1 im folgenden Zyklus abgegeben wird (nicht mehr dargestellt).
Es kann der Fall eintreten, dass das Datenpaket D1 nicht mehr im aktuellen Zyklus z1, z2 in das TSN-Netzwerk 2 gelangt und zudem im darauf folgenden Zyklus zwei Datenpakete D1, das verzögerte und das aktuelle, ankommen und jeweils der zugehörige Frame F1 in einen TSN-Stream S1 gewandelt wird. Da das Zeitfenster t1 jedoch nur für ein Datenpaket D1 dimensioniert ist, kann nur ein Datenpaket D1 an die TSN-Komponente TSN-C weitergeleitet werden. Das zweite Datenpaket D1 muss im Speicher der TSN-Bridge TSN-F bis auf einen folgenden Zyklus abwarten. Diese Verzögerung um einen Zyklus setzt sich somit immer weiter fort, da immer erst das „alte“ Datenpaket D1 im Speicher vor dem aktuellen Datenpaket D1 geschickt wird. Um hier Abhilfe zu schaffen, kann der Speicher im aktuellen Zyklus z1, z2 (oder auch alle paar Zyklen) geleert werden, beispielsweise indem über einen vorgegebenen Zeitraum alle Datenpakete D1 in Frames anstatt von TSN-Streams mit „best effort“ in das TSN-Netzwerk 2 versendet werden, oder der Speicher einfach gelöscht wird und das alte Frame damit verworfen wird. Bei größeren Mischnetzwerken 1, in welchen mehrere Datenpakete in einem Zeitfenster t1 geschickt werden kann das Zeitfenster um die Größe eines Datenpakets vergrößert werden, so dass pro Zyklus z1, z2 ein solcher Fehler
korrigiert werden kann.
Würde im Mischnetzwerk 1 von einer weiteren (Ethernet-)Komponente Ey (nicht in den Figuren eingezeichnet), beispielsweise einem Drucker, während eines Zeitfensters tO, t1, t2 über die gleiche Kommunikationsverbindung ein weiteres Frame Fy (ohne Umwandlung in einen TSN-Stream) über die TSN-Komponente TSN-F an die TSN-Komponente TSN-C geschickt, so sorgt die Konfiguration des TSN-Netzwerks 2 dafür, dass das besagte weitere Frame Fy bis zum Ablauf der Zeitfenster tO, t1, t2 „aufgehalten“ wird und erst nach dem Ablaufen der Zeitfenster tO, t1, t2 weitergeleitet wird. Die jeweiligen Zeitfenster tO, t1, t2 sind somit jeweils exklusiv für einen TSN-Stream SO, $S1, S4 reserviert, unabhängig davon, ob der TSN-Stream SO, S1, S4 überhaupt gesendet wird. Sind die Zeitfenster tO, t1, t2 wie in Fig. 3 dargestellt aneinandergereiht, so muss das von der weiteren Ethernet-Komponente Ey gesendete weitere Frame Fy warten, bis alle Zeitfenster tO, t1, t2 abgelaufen sind. Ist auf der Kommunikationsverbindung zwischen der TSN-Komponente TSN-F und der TSNKomponente TSN-C jedoch für den weiteren Frame Fy genug Bandbreite vorhanden und gerade kein Zeitfenster tO, t1, t2 reserviert, dann wird der weitere Frame Fy sofort an die TSN-Komponente TSN-C weitergeleitet. Diese Weiterleitung erfolgt jedoch nicht garantiert,
insbesondere wenn zusätzlicher Datenverkehr an der TSN-Komponente TSN-F auftritt.
18/56"
15
20
BN-4109 AT
Ein TSN-Stream S1 verwendet virtuelle Ethernet-Multicast-Empfänger-Adressen, welche im TSN-Netzwerk 2 richtig interpretiert werden, und kann somit im TSN-Netzwerk 2 an die jeweilige TSN-Komponente TSN-A, TSN-C, TSN-F als Empfänger geschickt werden. Es ist möglich, einen TSN-Stream S1 vom TSN-Netzwerk 2 in das Ethernet-Netzwerk 3 zu übermitteln, wobei im Ethernet-Netzwerk 3 bei Verwendung einer Multicast Adresse der TSN-Stream S1 an jede Ethernet-Komponente E1, E2, E3 geschickt würde. Dies ist üblicherweise nicht erwünscht, da zudem eine hohe Bandbreite beansprucht wird. Es könnte auch der Fall eintreten, dass eine Ethernet-Komponente E1, E2, E3 Multicast-Nachrichten gar nicht richtig empfangen kann. Ebenso kann der Fall eintreten, dass eine EthernetKomponente E1, E2, E3 alle Multicast-Nachrichten empfängt, und dann unter der Last „zusammenbricht“. Vorteilhafterweise wird daher der TSN-Stream S1 beim Verlassen des TSN-Netzwerks 2 in ein Frame F1 umgewandelt, wobei dessen TSN-Header durch einen Ethernet-Header ersetzt wird. Damit werden vorzugsweise lediglich die (Einzel-)Zieladresse und ein VLAN Tag entsprechend neu geschrieben. Der VLAN-Tag kann auch gelöscht
werden, wenn er nicht anderweitig gebraucht wird.
Die dargestellte Ausgestaltung beschreibt die Verwendung eines TSN-Streams $1 für den permanenten, zyklischen Austausch eines Datenpakets D1. Es sind im TSN-Netzwerk 2 jedoch grundlegend auch andere, nicht-zyklische, Anwendungen von TSN-Streams, selbst temporäre TSN-Streams, möglich. Beispielsweise könnte zwischen einem TSN-Feldgerät und einem TSN-Drucker im Falle eines (größeren) Druckauftrags ein TSN-Stream mit einer Bandbreitengarantie kreiert werden, der danach wieder abgebaut wird. Wenn mehrere TSNStreams auf einer TSN-Bridge aktiv sind, hält das TSN-Netzwerk 2 alle gegebenen
Garantien gleichzeitig ein.
19/56”

Claims (15)

15 20 25 30 BN-4109 AT Patentansprüche
1. Verfahren zur Übertragung eines, vorzugsweise zyklischen, Datenpakets (D1) von einer Ethernet-Komponente (E1, E2, E3), welche in einem Ethernet-Netzwerk (3) innerhalb eines Mischnetzwerks (1) angeordnet ist, an eine TSN-Komponente (TSN-C), die in einem nach den Standards der Arbeitsgruppe IEEE 802.1 TSN konfigurierten Industriellen Kommunikationsnetzwerk (2) innerhalb des Mischnetzwerks (1) angeordnet ist, wobei für das Datenpaket (D1) zumindest eine in den Standards der Arbeitsgruppe IEEE 802.1 TSN definierte Garantie vergeben wird, indem ein das Datenpaket (D1) beinhaltende Frame (F1) im nach den Standards der Arbeitsgruppe IEEE 802.1 TSN konfigurierten Industriellen Kommunikationsnetzwerk (2) von einer TSN-Bridge (TSN-F) identifiziert, in einen das Datenpaket (D1) beinhaltende TSN-Stream (S1) umgewandelt und das Datenpaket (D1) im TSN-Stream ($S1) an die TSN-Komponente (TSN-C) übermittelt wird.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Frame (F1) beim Eintreffen in das nach den Standards der Arbeitsgruppe IEEE 802.1 TSN konfigurierten Industriellen Kommunikationsnetzwerk (2) von einer TSN-Edge-Bridge (TSN-F) identifiziert, in den TSN-Stream ($1) umgewandelt und an die TSN-Komponente (TSN-C) übermittelt
wird.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Identifikation des TSN-Streams (S1) nach dem Standard IEEE 802.1CB erfolgt.
4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass bei der Umwandlung des Frames (F1) in den TSN-Stream ($1) ein Ethernet-Header des Frames (F1) durch einen TSN-Header ersetzt wird.
5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass das Ersetzen des Ethernet-Header des Frames (F1) durch den TSN-Header mittels einer Retagging-Funktion nach dem Standard IEEE 802.1Qci erfolgt.
6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass eine
minimale Bandbreite des TSN-Streams (S1) als Garantie vergeben wird.
7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass eine
maximale Latenz des TSN-Streams (S1) als Garantie vergeben wird.
8. Verfahren nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass eine
definierte Burstfähigkeit des TSN-Streams (S1) als Garantie vergeben wird.
9. Verfahren nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass ein
definierter Empfangszeitpunkt des TSN-Streams ($1) als Garantie vergeben wird.
20/56"
15
20
25
BN-4109 AT
10. Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass der TSN-Stream ($1) in einem vorgegebenen Zeitfenster (t1) zumindest eines Zyklus (z1, z2) an die TSN-
Komponente (TSN-C) übermittelt wird.
11. Verfahren nach einem der Ansprüche 1 bis 10, dadurch gekennzeichnet, dass beim Übertragen eines Datenpakets (D1) von der im nach den Standards der Arbeitsgruppe IEEE 802.1 TSN konfigurierten Industriellen Kommunikationsnetzwerk (2) befindlichen TSNKomponente (TSN-C) an eine im Ethernet-Netzwerk (3), außerhalb des nach den Standards der Arbeitsgruppe IEEE 802.1 TSN konfigurierten Industriellen Kommunikationsnetzwerk (2), befindliche Ethernet-Komponente (E1, E2) ein das Datenpaket (D1) beinhaltender TSNStream (S1) von einer TSN-Bridge (TSN-F) in ein das Datenpaket (D1) beinhaltenden Frame (F1) umgewandelt und das Datenpaket (D1) im Frame (F1) an die Ethernet-Komponente (E1, E2) übermittelt wird.
12. Verfahren nach Anspruch 11, dadurch gekennzeichnet, dass bei der Umwandlung des TSN-Streams (S$1) in den Frame (F1) der TSN-Header des TSN-Streams (S$1) durch einen Ethernet-Header, vorzugweise durch ein Retagging-Funktion nach dem Standard IEEE 802.1Qci, ersetzt wird.
13. Verfahren nach Anspruch 11, dadurch gekennzeichnet, dass bei der Umwandlung des TSN-Streams (S$1) in den Frame (F1) der VLAN-Tag des TSN-Headers des TSNStreams (S$1) gelöscht wird.
14. Verfahren nach Anspruch 11, dadurch gekennzeichnet, dass bei der Umwandlung des TSN-Streams ($1) in den Frame (F1) der TSN-Header des TSN-Streams (S$1) für den
Frame (F1) weiterverwendet wird.
15. Verfahren nach einem der Ansprüche 11 bis 14, dadurch gekennzeichnet, dass der TSN-Stream ($1) beim Verlassen des nach den Standards der Arbeitsgruppe IEEE 802.1 TSN konfigurierten Industriellen Kommunikationsnetzwerk (2) von einer TSN-Edge-Bridge
(TSN-F) in das das Datenpaket (D1) beinhaltende Frame (F1) umgewandelt wird.
ATA50740/2019A 2019-08-27 2019-08-27 Übertragung von Datenpaketen AT522898A1 (de)

Priority Applications (5)

Application Number Priority Date Filing Date Title
ATA50740/2019A AT522898A1 (de) 2019-08-27 2019-08-27 Übertragung von Datenpaketen
EP20764060.8A EP4005163A1 (de) 2019-08-27 2020-08-25 Übertragung von datenpaketen
PCT/EP2020/073721 WO2021037837A1 (de) 2019-08-27 2020-08-25 Übertragung von datenpaketen
CN202080073600.4A CN114631290B (zh) 2019-08-27 2020-08-25 数据分组的传输
US17/638,433 US20230031236A1 (en) 2019-08-27 2020-08-25 Transmission of data packets

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
ATA50740/2019A AT522898A1 (de) 2019-08-27 2019-08-27 Übertragung von Datenpaketen

Publications (1)

Publication Number Publication Date
AT522898A1 true AT522898A1 (de) 2021-03-15

Family

ID=72266288

Family Applications (1)

Application Number Title Priority Date Filing Date
ATA50740/2019A AT522898A1 (de) 2019-08-27 2019-08-27 Übertragung von Datenpaketen

Country Status (5)

Country Link
US (1) US20230031236A1 (de)
EP (1) EP4005163A1 (de)
CN (1) CN114631290B (de)
AT (1) AT522898A1 (de)
WO (1) WO2021037837A1 (de)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3866442B1 (de) * 2020-02-17 2023-06-07 ABB Schweiz AG Schnittstelleneinrichtung zwischen tsn-vorrichtungen und nicht-tsn-vorrichtungen
US20230283560A1 (en) * 2022-03-01 2023-09-07 Ge Aviation Systems Llc Converged avionics data network
CN115086239B (zh) * 2022-08-23 2022-11-04 中国人民解放军国防科技大学 一种共享式tsn整形调度装置
CN115665273B (zh) * 2022-10-17 2024-03-12 重庆邮电大学 一种autbus与时间敏感网络的协议转换方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180237039A1 (en) * 2016-06-30 2018-08-23 General Electric Company Locomotive control system
US20180302330A1 (en) * 2017-04-12 2018-10-18 General Electric Company Time sensitive network (tsn) scheduler with verification
US20180302331A1 (en) * 2017-04-12 2018-10-18 General Electric Company Time-sensitive networking differentiation of traffic based upon content
EP3499805A1 (de) * 2017-12-13 2019-06-19 Siemens Aktiengesellschaft Verfahren zur übertragung und / oder empfang von datenpaketen
EP3522477A1 (de) * 2018-01-31 2019-08-07 Siemens Aktiengesellschaft Verfahren zur daten-kommunikation in einem insbesondere industriellen netzwerk, vorrichtung zur durchführung des verfahrens, computerprogramm sowie computerlesbares medium

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1233180C (zh) * 2001-11-24 2005-12-21 Lg电子株式会社 分组传输调度技术
CN100433702C (zh) * 2003-09-01 2008-11-12 日本电信电话株式会社 分组通信方法
EP1650905A1 (de) * 2004-10-25 2006-04-26 Siemens Aktiengesellschaft Verfahren zur Verwaltung von Bandbreitenprofilen in einem Metro-Ethernet Netz
CN101212424B (zh) * 2006-12-28 2011-03-23 杭州华三通信技术有限公司 融合了电路交换和分组交换的以太网交换方法与设备
US9331962B2 (en) * 2010-06-27 2016-05-03 Valens Semiconductor Ltd. Methods and systems for time sensitive networks
CN102572982B (zh) * 2010-12-08 2014-09-17 同济大学 一种用于异构车辆通信网络的多属性切换判决方法
EP3057273B1 (de) * 2015-02-13 2019-03-27 Mitsubishi Electric R&D Centre Europe B.V. Verfahren zur Verkehrsformung in einem Netzwerk
US10044524B1 (en) * 2015-09-18 2018-08-07 Aquantia Corp. Ethernet controller with integrated TSN/AVB control point and time slave
EP3166255B1 (de) * 2015-11-03 2018-09-26 Robert Bosch Gmbh Schalten von terminierten rahmen in einem ethernet-basierten netzwerk in einem fahrzeug
EP3381219B1 (de) * 2015-11-24 2020-09-09 Telefonaktiebolaget LM Ericsson (PUBL) Vermittlung von datensignalen von mindestens zwei arten zur übertragung über ein transportnetzwerk mit bereitstellung von sowohl backhaul- als auch (fronthaul) xhaul-konnektivität
JP6962697B2 (ja) * 2016-05-27 2021-11-05 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカPanasonic Intellectual Property Corporation of America ネットワークハブ、転送方法及び車載ネットワークシステム
EP3264725B1 (de) * 2016-07-01 2021-08-25 Harman Becker Automotive Systems GmbH Umwandler der stream-reservierungsklasse
CN108173614B (zh) * 2017-12-08 2019-08-06 同济大学 一种车载以太网的时间同步和调度方法
EP3503485B1 (de) * 2017-12-22 2023-01-25 Marelli Europe S.p.A. Verfahren zur verwaltung von netzwerkverkehr in einem auf ethernet switchen basierende netzwerk, fahrzeug, kommunikationsschnittstelle und computerprogrammprodukt

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180237039A1 (en) * 2016-06-30 2018-08-23 General Electric Company Locomotive control system
US20180302330A1 (en) * 2017-04-12 2018-10-18 General Electric Company Time sensitive network (tsn) scheduler with verification
US20180302331A1 (en) * 2017-04-12 2018-10-18 General Electric Company Time-sensitive networking differentiation of traffic based upon content
EP3499805A1 (de) * 2017-12-13 2019-06-19 Siemens Aktiengesellschaft Verfahren zur übertragung und / oder empfang von datenpaketen
EP3522477A1 (de) * 2018-01-31 2019-08-07 Siemens Aktiengesellschaft Verfahren zur daten-kommunikation in einem insbesondere industriellen netzwerk, vorrichtung zur durchführung des verfahrens, computerprogramm sowie computerlesbares medium

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
N. FINN HUAWEI P. THUBERT CISCO B. VARGA J. FARKAS ERICSSON: "Deterministic Networking Architecture; draft-ietf-detnet-architecture-07.txt", DETERMINISTIC NETWORKING ARCHITECTURE; DRAFT-IETF-DETNET-ARCHITECTURE-07.TXT; INTERNET-DRAFT: DETNET, INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1205 GENEVA, SWITZERLAND, no. 07, 3 August 2018 (2018-08-03), Internet Society (ISOC) 4, rue des Falaises CH- 1205 Geneva, Switzerland, pages 1 - 41, XP015127972 *

Also Published As

Publication number Publication date
EP4005163A1 (de) 2022-06-01
US20230031236A1 (en) 2023-02-02
CN114631290B (zh) 2024-03-22
WO2021037837A1 (de) 2021-03-04
CN114631290A (zh) 2022-06-14

Similar Documents

Publication Publication Date Title
WO2021037837A1 (de) Übertragung von datenpaketen
EP3695577B1 (de) Verfahren zur daten-kommunikation in einem tsn netzwerk, steuerungsverfahren und vorrichtung
DE60118799T2 (de) Netzwerksvorrichtung zum selektiven datenzeitschlitz verwerfen
EP2676409B1 (de) Schleifen von mpls pfaden auf weiterleitungsebene für verbindungslose mpls netze
EP1554839B1 (de) Verfahren und knoten zur parallelen nutzung eines kommunikationsnetzwerkes für echtzeitanwendungen und nicht-echtzeitanwendungen
EP3183851A1 (de) Verteilerknoten, automatisierungsnetz und verfahren zum übertragen von echtzeitrelevanten und nicht-echtzeitrelevanten datenpaketen
DE102020207426A1 (de) Auflistung einer CNP-Erzeugung durch eine Vermittlungsstelle
WO2019007516A1 (de) Verfahren zur performanten datenübertragung in einem datennetz mit teilweise echtzeit-anforderungen und vorrichtung zur durchführung des verfahrens
DE102017125086A1 (de) Datenübertragungsverfahren und Kommunikationsnetzwerk
DE102012207952A1 (de) Verfahren zur Übertragung von Daten in einem paketorientierten Kommunikationsnetzwerk und entsprechend eingerichtetes Teilnehmergerät an dem Kommunikationsnetzwerk
EP3035606A1 (de) Verfahren zur Datenübermittlung in einem zumindest 2 virtuelle lokale Netze umfassenden Kommunikationsnetz und Kommunikationsgerät für ein industrielles Automatisierungssystem
EP2137893A1 (de) Paketvermittlungsvorrichtung und lokales kommunikationsnetz mit einer solchen paketvermittlungsvorrichtung
WO2016110326A1 (de) Verfahren und vorrichtung zum übertragen von daten in einem datennetz mit zumindest zweierlei übertragungsmodi mit fragmentierung
EP3854035B1 (de) Datenübertragungsverfahren und automatisierungskommunikationsnetzwerk
DE102010000995B3 (de) Erhöhung der Echtzeitfähigkeit von Ethernetnetzwerken
DE102012220784A1 (de) Verfahren zum Übertragen von Datenpaketen zwischen zwei Kommunikationsmodulen und Kommunikationsmodul zum Senden von Datenpaketen sowie Kommunikationsmodul zum Empfangen von Datenpaketen
DE102009050767B4 (de) Verfahren und Vorrichtung zur Datenübertragung
DE102017130167A1 (de) Verfahren zur Optimierung der Ausfallerkennung von Redundanz-Protokollen mit Testdatenpaketen
AT517778B1 (de) Verfahren zur Datenkommunikation mit reduziertem Overhead in einem echtzeitfähigen Ethernet-Datennetzwerk
DE102005003016B4 (de) Verfahren und Vorrichtungen zur Datenübertragung
EP3917089A1 (de) Verfahren zum betrieb eines kommunikationssystems zur übermittlung zeitkritischer daten und switch
EP1453252B1 (de) Übertragung von Daten in einem schaltbaren Datennetz
EP3716537A1 (de) Verfahren zur datenkommunikation, netzwerkknoten, computerprogramm und computerlesbares medium
DE10160844B4 (de) System zur Übertragung eines Datenstroms über ein Netzwerk an unterschiedliche Netzwerkprotokolle unterstützende Empfänger
WO2020169280A1 (de) Verfahren zur datenübertragung, gerät, computerprogramm und computerlesbares medium