Verfahren zur Daten-Kommunikation in einem insbesondere in dustriellen Netzwerk, Steuerungsverfahren, Vorrichtung, Com puterprogramm und computerlesbares Medium

Die Erfindung betrifft ein Verfahren zur Daten-Kommunikation in einem insbesondere industriellen Netzwerk, bei dem Daten zwischen wenigstens zwei Geräten von denen wenigstens ein Ge rät an einem Feldbus liegt, übertragen werden. Darüber hinaus betrifft die Erfindung ein Steuerungsverfahren, eine Vorrich tung, ein Computerprogramm sowie ein computerlesbares Medium.

In der industriellen Automatisierung kommen zur automatisier ten Steuerung bzw. Regelung beispielsweise von Maschinen, An lagen bzw. industriellen Prozessen spezielle Steuersysteme, insbesondere sogenannten speicherprogrammierbaren Steuerun gen, abkürzt SPS (englisch: Programmable Logic Controller, PLC) zum Einsatz. Eine SPS ist in der Regel über eine Mehr zahl von Eingangswerte liefernden Sensoren und eine Mehrzahl von Steuerwerten empfangenden Aktoren an die Maschine, Anlage bzw. einen Prozess angebunden.

Rein beispielhaft seien für Sensoren Druck- und Temperatur aufnehmer, Inkrementalgeber sowie Füllstandssensoren genannt. Aktoren können beispielsweise in Form von Schaltschützen, elektrischen Ventile und Module für Antriebssteuerungen gege ben sein. Die Sensoren und Aktoren sind nahe an dem bzw. den zu automatisierenden Prozess (en) angeordnet, um die benötig ten Messwerte an den relevanten Stellen zu erfassen bzw. an erforderlichen Stellen auf den Prozess einwirken zu können. Die Position der Aktoren ist auch durch den Aufbau der Ma schine bzw. Anlage festgelegt.

Im Betrieb erhält das Steuersystem von den Sensoren mittels dieser erfasste Messwerte, berechnet (u.a.) auf deren Basis Steuerwerte für die Aktoren und sendet diese an die Aktoren. Um nicht für jeden Sensor und/oder Aktor ein eigenes Kabel zum Steuersystem legen zu müssen, sind Kommunikationsnetzwer ke, sogenannte Feldbusse, entwickelt worden.

Feldbusse für industrielle Anwendungen betreffende Normen sind beispielsweise IEC 61158, IEC 61784-1 bis IEC 61784-5.

Angefangen hat dies mit einfachen Bus-Systemen. Ein einfaches Bus-System zeichnet sich in der Regel dadurch aus, dass die an ihn angeschlossenen einzelnen Geräte über eine Sammellei tung miteinander verbunden sind. Dabei ist typischerweise von dem Steuersystem, insbesondere der SPS, ein Bus-Netzwerk zu allen Sensoren und Aktoren, die Feldgeräte darstellen, ver legt worden. Über einen Feldbus können auch weitere Geräte, beispielsweise Bedien- und/oder Anzeigeeinrichtungen mit dem Steuersystem verbunden sein, um Daten von oder für diese zu übertragen. Als Beispiel für ein solches physisches Bus-Sys tem sei PROFIBUS genannt.

Heutzutage basieren viele Feldbusse auf Ethernet (zu Ethernet siehe IEEE 802, insbesondere IEEE 802.3), wie es beispiels weise bei PROFINET RT der Fall ist. Gegebenenfalls sind pro prietäre Erweiterungen vorgesehen, um eine gewünschte Perfor mance/Qualität in der Übertragung zu erreichen. Das gesamte logische Grundkonzept mit einem Bus zwischen Steuerung und Sensoren/Aktoren ist jedoch im Engineering erhalten geblie ben. Das in Form des Feldbusses gegebene, auf Ethernet basie rende Kommunikationsnetzwerk wird weiterhin wie ein einziges logisches Kabel (Bus Netzwerk) betrachtet. Die verfügbare Bandbreite (in der Regel 100 Mbit/s) wird zumeist fest auf eine Hälfte (in der Regel 50 Mbit/S) für Echtzeit-Daten und eine weitere Hälfte (in der Regel 50 Mbit/s) für anderen Ver kehr aufgeteilt. Die Einhaltung der Bandbreite muss dann durch die Auslegung der Echtzeit-Anwendung sichergestellt werden. Netzwerkgeräte erkennen die Echtzeitdaten anhand von proprietären Erweiterungen oder durch die Verwendung von spe ziellen Adressen und ordnen diese den entsprechenden Ressour- cen zu. Die bisherigen Feldbusse lassen sich so nicht problemlos in neue, standardisierte Ethernet-Netzwerke integrieren. Vor al lem durch die bekannten AVB- und TSN-Erweiterungen wären die Netzwerke jedoch leistungsfähig genug, um die Anforderungen, insbesondere an eine Echtzeit-Datenübertragung, zu erfüllen.

Insbesondere die Verwendung von mehreren Feldbussen in einem Ethernet-Netzwerk stellt sich problematisch dar.

Industrielle Feldbusse (beispielsweise PROFINET) sind bisher für 100 Mbit/s Ethernet Netzwerke ausgelegt. Der Anmelderin ist bekannt, dass bei der Projektierung eine Bus-Topologie für das gesamte Ethernet-Netzwerk angenommen wird. Es wird ferner bei der Auslegung angenommen, dass alle Ressourcen im Netzwerk exklusiv genutzt werden können. Für den Fall, dass eine dieser Annahmen nicht zutrifft, muss per Hand eine Res- sourcen-Planung durchgeführt werden, was mit nicht unerhebli chem Aufwand verbunden ist und umfangreicher Erfahrung be darf. Bisher gibt es nach Kenntnis der Anmelderin keinen Me chanismus, der die Planung mit der Wirklichkeit vergleicht und die geplanten Grenzen kontrolliert und bei einer Verlet zung reagiert. Dadurch kann das gesamte Netzwerk ausfallen. Ein Schutz während des Betriebs ist nicht möglich, da die Ressourcen-Planung im Netzwerk nicht bekannt ist.

Durch die Weiterentwicklung von Ethernet stehen immer höhere Bandbreiten zur Verfügung. Die Feldbusse sind jedoch typi scherweise nur für 100 Mbit/s-Netzwerke ausgelegt. Durch die höheren Bandbreiten entsteht der Wunsch, mehrere Feldbus- Systeme in einem Ethernet-Netzwerk zu verwenden. Einen Schutz eines logischen Feldbusses gibt es ohne Anpassung der einzel nen Systeme jedoch nicht. Alle Echtzeit-Anwendungen teilen sich die Ressourcen gleichberechtigt.

Im Rahmen der IEEE-Standardisierung wurde in der Arbeitsgrup pe AVB (Audio-Video-Bridging) die Technologie Ethernet (s. IEEE 802) um Mechanismen zur Erreichung von garantierter QoS ("Quality of Service" - auch als Dienstgüte bezeichnet) er- weitert. Dabei wurde eine neue Art von Verkehr definiert, die sogenannten Streams, über welche die Qualität (QoS) in einem Netzwerk garantiert werden kann. Ein Stream gemäß diesen Standards stellt eine geschützte, unidirektionale Kommunika tionsverbindung von einem auch als Talker bezeichneten, eine Datenquelle bildenden Gerät zu einem oder mehreren auch als Listener bezeichneten, die Datensenken, also Empfänger dar stellenden Gerät (e) dar.

Time Sensitive Networking (TSN) bezeichnet eine Reihe von Standards, die den Bridging Standard IEEE 802. IQ um Mechanis men zur Übertragung echtzeitkritischer Daten über Ethernet- Netze erweitert. Zu den genannten Standards gehören bei spielsweise Zeitsynchronisation (IEEE 802. lAS-Rev) , Frame Preemption (IEEE 802.1Qbu) und Reservierung (IEEE 802.1Qca, IEEE 802.1Qcc) sowie weitere Standards.

Vor der eigentlichen Datenübertragung via Stream erfolgt eine Registrierung und Reservierung, um von dem Netzwerk Garantien für einen verlustfreien Echt-Zeit-Transfer von Datenframes und eine pünktliche Lieferung zu erhalten. Für einen Stream wird eine Reservierung insbesondere durch ein sogenanntes Stream-Reservation-Protokoll (SRP) durchgeführt. Jeder Stream hat eine eigene Adresse, um die Weiterleitung zu kontrollie ren .

„Multiple Listeners per Stream" wurde in AVB eingeführt, um die Anzahl von Echtzeit-Datenflüssen von einer Quelle (Tal ker) zu mehreren Zielen (Listenern) zu reduzieren. Konkret wird die Datenübertragung von einem Talker an mehrere Liste ner über nur einen Stream ermöglicht. In der auf die Anmelde rin zurückgehenden europäischen Patentanmeldung mit dem Ak tenzeichen EP 18 15 4319 ist ferner ein Stream-Reservierungs- Modell offenbart, welches „Multiple Talker per Listener" er möglicht, konkret die Übertragung von Daten von mehreren Talkern an einen Listener über nur einen Stream. Aufgabe der vorliegenden Erfindung ist es, ein Verfahren zur Datenkommunikation insbesondere zwischen Komponenten bzw. Ge räten einer industrielle Automatisierungsanwendung anzugeben, welches eine zuverlässige Echtzeit-Kommunikation ermöglicht, sich gleichzeitig mit vertretbarem Aufwand durchführen lässt und dabei insbesondere auch die weitere Verwendung von beste henden Konzepten der Feldbus-Technologie ermöglicht.

Diese Aufgabe wird gelöst durch ein Verfahren zur Daten-Kom- munikation in einem insbesondere industriellen Netzwerk, bei dem Daten zwischen wenigstens zwei Geräten, von denen wenigs tens ein Gerät an einem Feldbus liegt, übertragen werden, wo bei die Datenübertragung zumindest abschnittsweise über ein AVB- oder TSN-Netzwerk erfolgt, in dem für den Feldbus we nigstens ein Stream eingerichtet ist bzw. wird, wobei für den wenigstens einen Stream an einem oder mehreren Knotenpunkten, insbesondere Switches und/oder Bridges, des Netzwerks Res sourcen reserviert sind und/oder werden, und Datenframes, die von wenigstens einem an dem Feldbus liegenden Gerät stammen und/oder für wenigstens ein an dem Feldbus liegendes Gerät bestimmt sind, über den wenigstens einen Stream übertragen werden .

Bei den wenigstens zwei Geräten handelt es sich bevorzugt um Geräte/Komponenten einer industriellen Automatisierungsanwen dung, beispielsweise um Feldgeräte und/oder Steuergeräte, wo bei ein Steuergerät insbesondere in Form einer speichergro- grammierbaren Steuerung (SPS) (engl.: Programmable Logic Con troller, PLC) vorliegen kann. Feldgeräte können beispielswei se in Form von IO-Geräten gegeben sein, die einen oder mehre re Sensoren und/oder Aktoren umfassen, oder diesem bzw. die sen zugeordnet bzw. mit diesem oder diesen verbunden sind.

Der Erfindung liegt mit anderen Worten die Idee zugrunde, die neuen standardisierten Ethernet-Mechanismen zur Abbildung ei nes oder mehrerer logischer Feldbusse - insbesondere als gan zes System - auf eine Kommunikationsstrecke in einem Ether net-Netzwerk zu nutzen. Dadurch wird es insbesondere möglich, bestehende Konzepte der Feldbus-Technologie weiterhin zu ver wenden. Bestandsgeräte können weiter genutzt werden, dies zu sammen mit den neuen Standards, insbesondere AVB bzw. dessen Erweiterung TSN. Dabei werden bevorzugt nicht alle Bestands geräte, etwa Sensoren und/oder Aktoren, einzeln an das AVB- oder TSN-Netzwerk angeschlossen, sondern es verbleiben insbe sondere mehrere Geräte an einem bestehenden Feldbus bzw. an einem Teil/Segment eines bestehenden Feldbusses, und werden mit einem oder mehreren weiteren Feldbus-Geräten, die an we nigstens einem weiteren Feldbus-Teil bzw. -Segment liegen, über das AVB- oder TSN-Netzwerk und via Stream(s) verbunden.

Bei dem Feldbus oder - sofern mehrere vorhanden - den Feld bussen kann es sich um physische Feldbusse (beispielsweise PROFIBUS) und/oder auf einem Ethernet-Netzwerk ohne AVB- oder TSN-Erweiterung basierende logische Feldbusse (beispielsweise PROFINET) handeln.

Innerhalb des jeweiligen Feldbusses bzw. Teils/Segments des Feldbusses können die Geräte bzw. Komponenten weiterhin nach dem bestehenden, zu dem Feldbus gehörigen Standard kommuni zieren. Im Falle eines PROFINET-Feldbusses werden etwa inner halb des Feldbusses weiterhin Ethernet-Datenframes (gemäß IEEE 802, insbesondere IEEE802.3) ohne AVB- oder TSN- Erwei terung also nicht über einen Stream gesendet. Zu physikali schen Feldbussen, etwa PROFIBUS, gehören andere Codierungen für die Datenframes, die ebenfalls weiterhin innerhalb des (jeweiligen) Feldbusses bzw. (jeweiligen) Feldbussegmentes verwendet werden können. Die Feldbus-Geräte müssen daher nicht für das AVB- oder TSN-Netzwerk, welches den neuen Stan dards genügt, verändert werden.

In dem AVB- der TSN-Netzwerke wird erfindungsgemäß wenigstens ein Stream, das heißt eine geschützte Verbindung mit gesi cherten, reservierten Ressourcen und insbesondere einer defi nierten Latenz, eingerichtet. Bei dem AVB- oder TSN-Netzwerk handelt es sich entsprechend um ein solches, welches die Ein- richtung von Streams durch Ressourcen-Reservierung unter stützt .

Sämtliche für das Einrichten des bzw. der Streams benötigten Parameter sind in der Regel ohnehin im Engineering eines Feldbusses vorhanden, insbesondere in dem TIA Portal, und können auf einfache Weise verwendet werden. Als Beispiele für diese Parameter seien die Paketgröße, Paketanzahl, die Band breite, der update-Cycle, das Sendeintervall und die Latenz genannt .

Insbesondere ist der (jeweilige) logische Feldbus bereits in den Engineering-Programmen zur Konfiguration der Teilnehmer enthalten. Bei PROFINET beispielsweise kann dies im TIA-Por- tal erfolgen. Durch die logische Verschaltung von projektier ten Baugruppen im Hardware-Konfigurator entsteht ein logi scher Feldbus. Zur Konfiguration von allgemeinen Netzwerkpa rametern hat das logische Bussystem meist einen Namen und zur internen Verwendung eine eindeutige ID (Beispielsweise einen UUID - Universally Unique Identifier) . Falls notwendig, kann z.B. die Datenrate des physikalischen Busses oder des unter liegenden Ethernet-Netzwerkes (ohne AVB- oder TSN-Erweite- rung) , welches den logischen Bus abbildet, eingestellt wer den. Über den Namen bzw. die eindeutige ID können Datenframes des jeweiligen Feldbusses einem oder mehreren Streams zuge ordnet werden. Die Adaption bzw. Einrichtung des als "Tunnel" verwendeten Streams im AVB- oder TSN-Ethernet-Netzwerk ist dadurch möglich, was sich die vorliegende Erfindung zu Nutze macht. Über einen Feldbus-Namen und/oder eine zugehörige ein deutige ID sind auch zusammengehörende Feldbussegmente bzw. Feldbusgeräte identifizierbar.

Insbesondere durch den Einsatz von Preemption (IEEE 802.1Qbu) in einem TSN-Netzwerk kann beispielsweise auch die Latenzan forderung von sehr zeitkritischen Anwendungen in den Feldbus sen eingehalten werden. Bei 100 MBit/s beispielsweise würde die benötigte Zeit zum Senden eines Frames mit der maximalen Datenmenge ca. 125 Mikrosekunden dauern, was bereits größer als ein kleiner Bus-Zyklus von 64 Mikrosekunden ist.

Die AVB- und die TSN-Technologie ist vor allem durch den be reits erfolgten Einsatz im Automobilbereich und/oder die Her kunft von AVB (Audio Video Bridging) aus Heimnetzwerken in vergleichsweise preiswerten Netzwerkkomponenten verfügbar. Durch die erfindungsgemäße Nutzung vergleichsweise kosten günstiger und standardisierter AVB- bzw. TSN-Mechanismen (Streams) kann auf andere Mechanismen zum Tunneln einer Da tenübertragung in Ethernet-Netzwerken, wie etwa VXLAN, Mac- in-Mac, SPB-V, die bisher nur in teureren Hardwarekomponenten vorhanden sind, und zudem keinen Ressourcenschutz bieten, verzichtet werden.

Die erfindungsgemäße Nutzung eines oder mehrerer Streams führt zu einer robusten, garantierten Übertragung mit gesi cherten Ressourcen und garantiert die Einhaltung von einer geforderten Latenz für Echtzeit-Anwendungen . Die zu übertra genden Daten sind durch die Reservierung vor einer zu großen Einwirkung von anderen Echt _Z eitanwendungen und/oder sonstigen Anwendungen im Netzwerk geschützt. Andere Anwendungen haben dann insbesondere nur eine kleine, aber genau bekannte Aus wirkung auf die Übertragungszeit. Durch die Ressourcenreser vierung kommt es nicht zum Verlust von Echtzeitdaten .

Um Ethernet-Geräte, welche in einem Feldbus liegen, also in einen Feldbus integriert sind, transparent anbinden zu kön nen, kann die Paketauswahl auf die zu dem (jeweiligen) Feld bus gehörende Pakete begrenzt werden. Diese Erkennung kann beispielsweise unter Rückgriff auf den Ethertype erfolgen.

Der Ethertype ist dabei ein definierter Bestandteil eines Ethernet-Datenframes und definiert das Protokoll, welches die Daten sendet und am Zielort nach dem Empfang verarbeitet. Bei PROFINET RT beispielsweise ist der Ethertype 0x8892.

Für den oder jeden Feldbus wird der wenigstens eine Stream bevorzugt automatisiert eingerichtet. Für den Erhalt einer oder mehrere geschützter Verbindungen, also eines oder mehrerer Streams werden in an sich bekannter Weise vor der eigentlichen Übertragung der Daten Ressourcen in einem oder mehreren Knotenpunkten des Netzwerkes reser viert, was bevorzugt unter Verwendung eines Reservierungspro tokolls erfolgt. Durch die Verwendung eines Reservierungspro tokolls für den Echtzeit-Fluss kann die komplexe Konfigurati on automatisch im Netzwerk durchgeführt werden, wobei die je weils vorliegende Topologie genutzt wird.

Bei Ressourcen, die reserviert sind und/oder werden, kann es sich beispielsweise um Adresstabelleneinträge, Framebuffer, transmit time slices, Bandbreite, Jitter, Latenz etc. han deln .

In bevorzugter Ausgestaltung ist vorgesehen, dass als Res sourcen für den wenigstens einen Stream Adresstabelleneinträ ge und/oder Framebuffer und/oder Bandbreite an einem oder mehreren Knotenpunkten des Netzwerkes reserviert sind und/oder werden. Besonders bevorzugt sind und/oder werden an wenigstens einem Knotenpunkten zumindest ein Adresstabellen- eintrag und Framebuffer und Bandbreite reserviert.

Die Zuordnung von Datenframes zu einem Tunnel bzw. Stream kann in den Endpunkten anhand des Protokolls erfolgen. Bei PROFINET beispielsweise kann auch zusätzlich die Frame ID, also ID innerhalb der Ethernet-Datenframes verwendet werden. Dadurch wird es möglich, dass für jeden Service eines Feld busses, insbesondere PROFINET-Service, ein eigener Tunnel, also Stream ausgewählt wird.

Insbesondere unter Verwendung eines Reservierungsprotokolls und/oder Rückgriff auf Parameter aus einem vorhandenen Feld bus-Engineering, insbesondere TIA-Portal, kann eine automati sche Konfiguration des bzw. der Streams auf einfache Weise erfolgen, was die Handhabung erleichtert und den Einsatz durch Anwender auch ohne spezielles IT Wissen ermöglicht. Im Rahmen des erfindungsgemäßen Verfahrens kann einer oder können mehrere Streams der Datenübertragung zwischen zwei oder mehreren Geräten innerhalb eines Feldbusses dienen und/oder der Datenübertragung zwischen Geräten, die an zwei oder mehr verschiedenen Feldbussen liegen, also zwischen zwei oder mehr Feldbussen, und/oder der Datenübertragung zwischen Geräten, von denen wenigstens eines an einem Feldbus liegt und wenigstens eines nicht an einem Feldbus liegt.

Ener oder mehrere Streams werden in einem AVB- bzw. TSN-Netz- werk eingerichtet. Unter einem AVB- bzw. TSN-Netzwerk ist da bei ein solches zu verstehen, welches einem oder mehreren Au dio Video Bridging (AVB) oder Time Sensitive Networking (TSN) Standards genügt, insbesondere einen oder mehrere AVB- bzw. TSN-fähige Knotenpunkte, etwa Switches und/oder Bridges um fasst. Das Netzwerk bzw. die Knotenpunkte sind insbesondere ausgebildet und/oder eingerichtet, um einem oder mehreren AVB- bzw. TSN-Standards zu genügen. Zu den AVB-Standards ge hören insbesondere IEEE802.1AS, IEEE802. lQat, IEEE802. lQav, IEEE802.1BA und zu den TSN-Standards gehören beispielsweise Zeitsynchronisation (IEEE 802. lAS-Rev) , Frame Preemption (IEEE 802.1Qbu) und Reservierung (IEEE 802.1Qca, IEEE

802.1Qcc) sowie weitere Standards.

Die erfindungsgemäße Vorgehensweise bietet mehrere Vorteile. Einerseits können Feldbusse als logische Feldbusse weiterhin existieren. Der Anwender kann wie bisher die Kommunikation als Bus betrachten und die Geräte logisch miteinander verbin den .

Die Übertragung im AVB- oder TSN-Ethernet-Netzwerk ist über den Stream bzw. Streams geschützt und kann von anderen Anwen dungen nicht mehr gestört werden. Darüber hinaus ist eine Än derung der Endgeräte nicht erforderlich. Vielmehr können be stehende Endgeräte bzw. Systeme, insbesondere einer industri ellen Automatisierungsanwendung, weiterhin problemlos genutzt werden. Gleichzeitig kann auf die neuen, standardisierten Ethernet-Mechanismen AVB- bzw. TSN zurückgegriffen werden. Der Feldbus bzw. die Feldbusse werden darüber hinaus durch die erfindungsgemäße Vorgehensweise als Verbindung im AVB- oder TSN-Netzwerk sichtbar, durch die Reservierung von we nigstens einem Stream, was es auch möglich macht, Fehler und Ressourcen-Engpässe im AVB- oder TSN-Netzwerk auf sehr einfa che Weise zu diagnostizieren. Insbesondere wird in der Diag nose des AVB- bzw. TSN-Netzwerkes der logische Feldbus, bzw. werden die logischen Feldbusse in Form wenigstens eines Streams, bevorzug in Form von genau zwei Streams für eine bi direktionale Kommunikation, sichtbar. Jeder Stream, insbeson dere jede Übertragungsrichtung der getunnelten Kommunikation (logischer Bus) ist dann im Netzwerk-Management mit den be legten Ressourcen erkennbar. Beispielsweise können Bridges mit einer nicht ausreichenden Anzahl von FDB Einträgen so im AVB-bzw. TSN-Netzwerk erkannt werden. Diese Diagnose für Streams ist Bestandteil des Reservierungsprotokolls SRP (in IEE 802.I Q).

Die Übertragung von Datenframes über den wenigstens einen Stream ist insbesondere derart, dass durch einen Shaper, ins besondere gemäß IEEE802.1, die Einhaltung der Bandbreite ga rantiert wird. Durch die garantierte Bandbreiteneinhaltung kann auf dem Weg in jedem Knotenpunkt, etwa jeder Bridge eine maximale Latenz garantiert werden. Durch den Credit Based Shaper (CBS) gemäß IEEE 802.1Qav wird bei einem AVB- oder TSN-Stream beispielsweise bei der Übertragung bzw. Weiterlei tung jedes Datenframes eine Pause gemacht, deren Länge von der Größe des Datenframes und der reservierten Bandbreite ab hängt. Dabei gilt, dass die Pause umso länger ist, je größer der vor der Pause übertragene bzw. weitergeleitete Datenframe war, also umso größer die weitergeleitete bzw. übertragene Datenmenge war. Der Zusammenhang ist dabei insbesondere line ar. Die Länge der Pause entspricht insbesondere der Länge der für die Übertragung des jeweiligen Datenframes erforderlichen Zeit multipliziert mit einem von der reservierten Bandbreite abhängigen Faktor. Sind beispielsweise 25 % der Bandbreite für einen Stream reserviert, wird insbesondere nach jedem Da tenframe eine Pause gemacht, die dreimal so lang ist, wie die für dessen Übertragung erforderliche Zeit. Sind 50% reser viert, ist die Pause so lang, wie die Übertragungszeit und so weiter. Der Faktor für die Länge der Pause ist aufgrund der Reservierung bekannt und wird fest eingerichtet. Über diese Vorgehensweise wird garantiert, dass die Bandbreite eingehal ten wird. Frames, die an einem Knotenpunkt, insbesondere ei ner Bridge bzw. einem Switch des AVB- bzw. TSN-Netzwerkes an kommen, können immer sofort weitergeleitet werden.

Besonders bevorzugt ist vorgesehen, dass wenigstens ein

Stream zwischen zwei Segmenten eines Feldbusses, eingerichtet ist bzw. wird, wobei bevorzugt an zumindest einem Feldbusseg ment mehrere Geräte liegen. Im einfachsten Falle kann ein Feldbussegment auch ein einzelnes Gerät umfassen bzw. durch ein solches gegeben sein. Das bedeutet, es können beispiels weise auch Daten via Stream zwischen einem Feldbussegment, an welchem zwei oder mehr Geräte anliegen, und einem einzelnen Feldbus-Gerät ausgetauscht werden.

Eine weitere bevorzugte Ausführungsform des erfindungsgemäßen Verfahrens zeichnet sich dadurch aus, dass zwei oder mehr Feldbusse, an denen jeweils wenigstens ein Gerät liegt, vor gesehen sind, und für jeden Feldbus wenigstens ein dem jewei ligen Feldbus zugeordneter Stream in dem AVB- oder TSN-Netz- werk eingerichtet ist bzw. wird, wobei für jeden Stream an einem oder mehreren Knotenpunkten, insbesondere Switches und/oder Bridges, des Netzwerkes Ressourcen reserviert sind und/oder werden, und Datenframes, die von wenigstens einem an dem jeweiligen Feldbus liegenden Gerät stammen und/oder für wenigstens ein an dem jeweiligen Feldbus liegendes Gerät be stimmt sind, in dem AVB- oder TSN-Netzwerk über den jeweili gen wenigstens einen Stream übertragen werden.

Sofern es die Bandbreite des AVB- oder TSN-Netzwerkes zu lässt, beispielsweise ein Gigabit-Netzwerk zur Verfügung steht, können auch mehrere logische Feldbusse, für die dann zum Beispiel jeweils 50 Mbit/s als maximale Bandbreite für eine Echtzeit-Datenübertragung angenommen wird, im Netzwerk kombiniert werden. Es lassen sich also im Rahmen des erfin dungsgemäßen Verfahrens auch mehrere Feldbusse über ein Netz werk verbinden. Dann existieren gesicherte Ressourcen für je den Feldbus im schnelleren AVB- bzw. TSN-basierten Netzwerk durch Streams. Die Reservierung kann beispielsweise anhand der maximalen physikalischen Feldbus-Geschwindigkeit im TSN- Backbone-Netzwerk erfolgen. Es kann eine niedrige Latenz durch schnellere Linkspeed erzielt werden und optional kann auf Preemption für Echtzeit-Anwendungen insbesondere mit ver gleichsweise niedrigem Zyklus, beispielsweise unterhalb von 250 Mikrosekunden, zurückgegriffen werden.

Besonders bevorzugt werden für den oder jeden Feldbus wenigs tens zwei Streams eingerichtet, und insbesondere über wenigs tens einen Stream Datenframes in Richtung des jeweiligen Feldbusses und über wenigstens einen weiteren Stream Daten frames, die aus dem jeweiligen Feldbus stammen, übertragen. Dann kann die gesamte Datenübertragung in insbesondere beide Richtungen über zwei oder mehr Streams erfolgen, für die an einem oder mehreren auf dem Stream-Netzwerkpfad liegenden Knotenpunkten, insbesondere Switches und/oder Bridges, Res sourcen reserviert sind oder werden.

Ob wenigstens ein Stream für die eine Richtung und/oder we nigstens ein Stream für die andere Richtung vorliegt, kann insbesondere daran ausgemacht werden, dass (für jede Rich tung) wenigstens eine Stream-ID vorliegt.

Im Rahmen des erfindungsgemäßen Verfahrens werden insbesonde re Datenframes via Stream übertragen, welche als Nutzdaten von Sensoren einer Automatisierungsanlage erfasste Messwerte bzw. diese repräsentierende Daten und/oder für Aktoren einer Automatisierungsanlage bestimmte Stellwerte bzw. diese reprä sentierende Daten umfassen. Alternativ oder zusätzlich werden Daten zur Konfiguration des Netzwerkes und eines oder mehre rer an einem Feldbus liegender Geräte, insbesondere Sensoren und/oder Aktoren, und/oder Daten zur periodischen Überwachung eines oder mehrerer an einem Feldbus liegender Geräte, über tragen .

Eine weitere bevorzugte Ausführungsform des erfindungsgemäßen Verfahrens zeichnet sich dadurch aus, dass für den oder jeden Feldbus der wenigstens eine Stream unter Rückgriff auf Konfi gurationsdaten des (jeweiligen) Feldbusses, insbesondere auf Konfigurationsdaten des TIA-Portals des (jeweiligen) Feldbus ses, eingerichtet wird bzw. worden ist. Die in der Regel oh nehin im Engineering eines Feldbusses vorhanden Konfigurati onsdaten können auf einfache Weise verwendet werden. Als Bei spiele für diese Parameter seien die Paketgröße, Paketanzahl, die Bandbreite, der update-Cycle, das Sendeintervall und die Latenz genannt.

In weiterer besonders bevorzugter Ausgestaltung kann ferner vorgesehen sein, dass der oder jeder Feldbus über wenigstens einen Verbindungsknotenpunkt an das AVB- oder TSN-Netzwerk angebunden ist, wobei der wenigstens eine Verbindungsknoten punkt einen Feldbus-Port in Richtung des jeweiligen Feldbus ses und einen Stream-Port in Richtung des AVB- oder TSN-Netz- werkes aufweist, und der wenigstens eine Verbindungsknoten punkt ausgebildet und eingerichtet ist, um Datenframes, die an dem Feldbus-Port ankommen, wenigstens einen Stream-Parame- ter, insbesondere eine designierte Stream Adresse und/oder eine VLAN ID und/oder eine Priorität zuzuweisen, insbesondere voranzustellen, und/oder um aus Datenframes, die an dem

Stream-Port ankommen, wenigstens einen Stream-Parameter, ins besondere eine designierte Stream Adresse und/oder eine VLAN ID und/oder eine Priorität zu entfernen.

Daten zwischen einem oder mehreren an dem jeweiligen Feldbus bzw. Feldbussegment liegenden Geräten und dem oder jeden Ver bindungsknotenpunkt können gemäß dem bestehenden Feldbus- Standard, im Falle von PROFINET beispielsweise via Ethernet ohne AVB- oder TSN-Erweiterung (insbesondere gemäß IEEE

802.3) übertragen werden. Auch kann vorgesehen sein, dass der oder jeder Feldbus über wenigstens zwei Verbindungsknotenpunkte an das AVB- oder TSN- Netzwerk angebunden ist, und jeder Verbindungsknotenpunkt ei nen Feldbus-Port in Richtung des jeweiligen Feldbusses und einen Stream-Port in Richtung des AVB- oder TSN-Netzwerkes aufweist, und jeder Verbindungsknotenpunkt ausgebildet und eingerichtet ist, um Datenframes, die an dem Feldbus-Port an kommen, wenigstens einen Stream-Parameter, insbesondere eine designierte Stream Adresse und/oder eine VLAN ID und/oder ei ne Priorität zuzuweisen, insbesondere voranzustellen,

und/oder um aus Datenframes, die an dem Stream-Port ankommen, wenigstens einen Stream-Parameter, insbesondere eine desig nierte Stream Adresse und/oder eine VLAN ID und/oder eine Priorität zu entfernen.

In dem (den) Verbindungsknotenpunkt (en) ist bevorzugt eine logische Konfiguration vorgesehen, welche die Anbindung des Feldbusses an den (jeweiligen) Stream ermöglich, z. B. ist bevorzugt eine PRU in den jeweiligen Verbindungsknotenpunkt integriert. Bei einer PRU handelt es sich um eine program mierbare Funktion in einem Gerät mit mindestens 2 Ports, die je nach Programm empfangene oder zu sendende Frames vor der weiteren internen Verarbeitung oder dem Senden manipulieren kann und Inhalte hinzufügen, ändern und/oder entfernen kann. Das Programm der PRU kann dafür sorgen, dass alle ankommenden Frames, die über einen Tunnel gesendet werden müssen, im übergeordneten AVB- oder TSN-Netzwerk als Stream erkennbar sind. Datenframes eines AVB- oder TSN-Streams sind insbeson dere über die verwendete Zieladresse und/oder die VLAN ID und/oder VLAN Priorität erkennbar.

Bevorzugt wird von dem oder jedem Verbindungsknotenpunkt we nigstens ein Stream-Parameter in einem Header von Datenframes aus dem Feldbus, die am Feldbus-Port ankommen, vorgesehen bzw. dem jeweiligen Datenframe ein ( Stream- ) Header mit einem oder mehreren Stream-Parametern vorangestellt. Der bzw. jeder Verbindungsknotenpunkt bildet praktisch einen Connector zwischen dem (jeweiligen) Feldbus (-Netzwerk) und dem AVB- oder TSN-Netzwerk, in dem wenigstens ein Stream ein gerichtet ist bzw. wird bzw. einem zu dem (jeweiligen) Stream gehörigen Netzwerkpfad, der auch als Stream-Netzwerkpfad be zeichnet werden kann. Der wenigstens eine Verbindungsknoten punkt übernimmt insbesondere die Funktion eines Proxys und/oder bildet (jeweils) einen Endpunkt des (jeweiligen) Streams . Bei dem (den) Verbindungsknotenpunkt (en) handelt es sich bevorzugt um ein 2- oder Mehr-Port-Gerät, welches zumin dest einen Port im Feldbus hat und zumindest einen weiteren Port in Richtung des Stream-Netzwerkpfades .

Der Einsatz von Verbindungsknotenpunkten ermöglicht eine rei bungsfreie Überführung von Feldbus-Datenframes, welche bei spielsweise als Ethernet (ohne AVB- oder TSN-Erweiterung)— Frames oder Datenframes mit einer anderen Codierung vorliegen können, in Stream-fähige Datenframes, insbesondere mit einer designierte Stream Adresse und/oder einem VLAN-tag, insbeson dere einer VLAN ID und/oder einer Priorität, und/oder anderen Stream-Parametern, die sich in der Regel in einem Frame- Header befinden, und umgekehrt. Der jeweilige Stream-Daten- frame umfasst dann insbesondere den Header und dem Header folgende Nutzdaten, die auch als "Payload" bezeichnet werden. Die "Payload" des Stream-Datenframes entspricht dann insbe sondere dem Feldbus-Datenframe. In umgekehrter Richtung wird insbesondere wenigstens ein Stream-Parameter bzw. ein Header entfernt .

Es kann auch sein, dass wenigstens ein Verbindungsknoten bzw. dessen Funktion, in ein Gerät, etwa ein Steuergerät bei spielsweise in Form einer SPS, integriert ist.

Sind mehrere Feldbusse auf die erfindungsgemäße Weise an ein AVB- oder TSN-Netzwerk angebunden, ist bevorzugt für jeden Feldbus wenigstens ein Verbindungsknotenpunkt vorgesehen, sind bevorzugt für jeden Feldbus wenigstens zwei Verbindungs knotenpunkte vorgesehen. Ist einer oder sind mehrere Verbindungsknotenpunkte vorgese hen, bilden diese bevorzugt Knotenpunkte, an denen für den wenigstens einen Stream Ressourcen reserviert sind und/oder werden .

Der bzw. die Verbindungsknotenpunkt (e) und/oder gegebenen falls vorhandene weitere Knotenpunkte sind bevorzugt als AVB- oder TSN-fähige Knotenpunkte ausgebildet. Es kann sich bei spielsweise (jeweils) um eine AVB- bzw. TSN-fähige Bridge und/oder einen AVB- bzw. TSN-fähigen Switch oder andere AVB- bzw. TSN-fähige Geräte handeln. Der wenigstens eine Port des Verbindungsknotenpunktes in Richtung des Netzwerkes ist be vorzugt ein AVB- bzw. TSN-Port.

Eine weitere Ausführungsform zeichnet sich dadurch aus, dass eines oder mehrere Geräte des oder jeden Feldbusses mit dem Feldbus-Port des einen Verbindungskotenpunktes und eines oder mehrere weitere Geräte des oder jeden Feldbusses mit dem Feldbus-Port des anderen Verbindungskotenpunktes verbunden sind. Dabei versteht sich, dass die Verbindung des jeweiligen Gerätes mit dem jeweiligen Feldbus-Port direkt oder auch in direkt - über ein oder mehrere weitere Komponenten - sein kann, beispielsweise über einen oder mehrere Feldbus-Knoten punkte, insbesondere Switches und/oder Bridges, des jeweili gen Feldbusses.

Gegenstand der vorliegenden Erfindung ist ferner ein Steue rungsverfahren für einen industriellen technischen Prozess oder ein Fahrzeug, bei dem zwischen wenigstens zwei Geräten einer Automatisierungsanlage Daten unter Durchführung des er findungsgemäßen Verfahrens zur Datenkommunikation ausge tauscht werden und auf Basis der ausgetauschten Daten eine Steuerung des industriellen technischen Prozesses oder Fahr zeugs erfolgt.

Ein weiterer Gegenstand der Erfindung ist eine Vorrichtung, die zur Durchführung des erfindungsgemäßen Verfahrens zur Da- ten-Kommunikation bzw. des erfindungsgemäßen Steuerungsver- fahrens ausgebildet und eingerichtet ist, insbesondere umfas send :

- einen oder mehrere bevorzugt AVB- oder TSN-fähige Knoten punkte, insbesondere Bridges und/oder Switches, und

- wenigstens zwei Geräte, die bevorzugt Bestandteile einer industriellen Automatisierungsanlage sind und von denen we nigstens eines an einem Feldbus anlegbar ist oder an einem Feldbus liegt.

Weiterhin betrifft die Erfindung ein Computerprogramm, das Programmcodemittel zur Durchführung der Schritte des erfin dungsgemäßen Verfahrens zur Daten-Kommunikation bzw. des er findungsgemäßen Steuerungsverfahrens umfasst.

Schließlich ist Gegenstand der Erfindung ein computerlesbares Medium, das Instruktionen umfasst, die, wenn sie auf wenigs tens einem Computer ausgeführt werden, den wenigstens einen Computer veranlassen, die Schritte des erfindungsgemäßen Ver fahrens zur Daten-Kommunikation bzw. des erfindungsgemäßen Steuerungsverfahrens durchzuführen .

Bei dem computerlesbaren Medium kann es sich beispielsweise um eine CD-ROM oder DVD oder einen USB oder Flash Speicher handeln. Es sei angemerkt, dass unter einem computerlesbaren Medium nicht ausschließlich ein körperliches Medium zu ver stehen sein soll, sondern ein solches beispielswiese auch in Form eines Datenstromes und/oder eines Signals, welches einen Datenstrom repräsentiert, vorliegen kann.

Weitere Merkmale und Vorteile der vorliegenden Erfindung wer den anhand der nachfolgenden Beschreibung von Ausführungsfor men des Verfahrens der vorliegenden Erfindung unter Bezugnah me auf die beiliegende Zeichnung deutlich. Darin ist

FIG 1 eine rein schematische Darstellung der logischen

Anordnung eines auf Ethernet basierenden PROFINET- Feldbusses einer industriellen Automatisierungsan lage ; FIG 2 eine rein schematische Darstellung eines Feldbusses einer industriellen Automatisierungsanlage, für den in einem TSN-Netzwerk zwei Streams eingerichtet sind;

FIG 3 eine rein schematische Darstellung eines als 2- Port-Gerät, z.B. mit integrierter PRU ausgebildeten Verbindungsknotenpunktes ;

FIG 4 eine rein schematische Darstellung eines Gerätes mit integriertem Verbindungsknotenpunkt;

FIG 5 eine rein schematische Darstellung eines aus einem

Feldbus stammenden Ethernet-Datenframes, wie er an dem Feldbus-Port eines Verbindungsknotenpunktes an kommt bzw. von diesem abgesendet wird, und eines Stream-Datenframes , wie er am Stream-Port eines Verbindungsknotenpunktes ankommt bzw. von diesem abgesendet wird;

FIG 6 eine rein schematische Darstellung der in einem

Feldbus übertragenen Daten;

FIG 7 eine rein schematische Darstellung eines TSN-Netz- werkes, das drei Feldbusse miteinander verbindet;

FIG 8 eine rein schematische Darstellung eines TSN-Netz- werkes, das zwei Feldbussegmente und ein einzelnes Feldgerät miteinander verbindet;

FIG 9 eine rein schematische Darstellung von an dem Feld bus-Port eines Verbindungsknotenpunktes ankommenden Daten und einem von diesem abgehenden Stream-Daten- frame ;

FIG 10 eine rein schematische Darstellung von vier an dem

Feldbus-Port eines Verbindungsknotenpunktes ankom- menden Feldbus-Datenframes und den zugehörigen Stream-Datenframes ;

FIG 11 eine rein schematische Darstellung zur Weiterlei tung der Stream-Datenframes im TSN-Netzwerk;

FIG 12 eine rein schematische Darstellung zur Weiterlei tung von Feldbus-Datenframes in einem Netzwerk mit höherer Bandbreite in vorgegebenen Zeitfenstern .

Die FIG 1 zeigt in rein schematischer Darstellung vier Geräte einer industriellen Automatisierungsanlage für einen in den Figuren nicht weiter dargestellten technischen Prozess, die für einen Datenaustausch untereinander über einen Ethernet basierten Feldbus 1, konkret einen PROFINET-Feldbus , mitei nander verbunden sind. Gezeigt ist dabei der logische Bus, der auf einem in der FIG 1 nicht weiter dargestellten Ether net-Netzwerk basiert.

Bei den vier Geräten handelt es sich um eine speicherprogram miere Steuerung 2, die im Weiteren als SPS bezeichnet wird, eine Anzeige-Vorrichtung in Form eines Bildschirmes 3, ein Bediener-Panel 4 und ein Eingabe/Ausgabe-, also I/O-Gerät 5, das einen oder mehrere in der Figur nicht dargestellte Senso ren und/oder Aktoren der Automatisierungsanlage umfasst bzw. mit einem solchen oder solchen verbunden ist. Es sei betont, dass der eine Bildschirm 3, das eine Bediener-Panel 4 und insbesondere das eine I/O-Gerät 5 beispielhaft gezeigt sind und viele weitere Feldgeräte, insbesondere I/O-Geräte 5, an den Feldbus 1 angeschlossen sind bzw. werden können.

Im Betrieb der nicht weiter gezeigten Automatisierungsanlage werden in an sich bekannter Weise Daten zwischen der SPS 2 und den Feldgeräten 3, 4, 5 ausgetauscht. Insbesondere werden von den I/O-Geräten 5 im Betrieb mittels Sensoren erfasste Messwerte an die SPS 2 gesendet und von dieser u.a. auf Basis der Messwerte ermittelte Steuerwerte für Aktoren der Automa tisierungsanlage werden von der SPS 2 an I/O-Geräte 5 gesen- det. Auch werden Daten von der SPS 2 an den Bildschirm 3 ge sendet, um dort für einen Benutzer visualisiert zu werden und es werden Daten, die insbesondere Benutzerbefehle repräsen tieren, von dem Bediener-Panel 4 an die SPS 2 gesendet.

Die FIG 2 zeigt die SPS 2, den Bildschirm 3, das Bediener- Panel 4 und I/O-Gerät 5, wobei der Feldbus 1 in zwei Segmente la, lb unterteilt ist, und die beiden Feldbussegmente la, lb über ein TSN-Netzwerk 6 miteinander verbunden sind. Das TSN- Netzwerk 6 ist in FIG 2 schematisch durch eine Wolke angedeu tet. Die Feldbussegment-Netzwerke ebenfalls.

In dem TSN-Netzwerk 6 sind in einem Schritt des hier be schriebenen Ausführungsbeispiels des erfindungsgemäßen Ver fahrens zur Daten-Kommunikation zwei Streams 7, 8 für eine schnelle, gesicherte Datenübertragung mit garantierter Quali tät, insbesondere Latenz, zwischen an dem einen Feldbusseg ment la liegenden Geräten 2, 3 und an dem andere Feldbusseg ment lb liegenden Geräten 4, 5 eingerichtet worden.

Für jeden der beiden Streams 7, 8 sind für das Einrichten der

Streams an mehreren Knotenpunkten, vorliegend Switches des TSN-Netzwerks 6 Ressourcen reserviert worden.

Die beiden Streams 7, 8 sind unter Rückgriff auf Konfigurati onsdaten des Feldbusses 1 automatisiert eingerichtet worden. Sämtliche für die Einrichtung der Streams 6, 7 benötigten Pa rameter sind ohnehin im Engineering des Feldbusses 1 vorhan den, konkret in dem TIA Portal, und können auf einfache Weise verwendet werden. Als Beispiele für diese Parameter seien die Paketgröße, Paketanzahl, die sich dadurch ergebende Bandbrei te, der update-Cycle, das Sendeintervall und die Latenz ge nannt .

Datenframes, die von der SPS 2 stammen und/oder Datenframes, die von dem Bildschirm 3 stammen, werden über den Stream 7 in Richtung des Feldbussegmentes lb übertragen, und Datenframes, die von dem Bedienerpanel 4 stammen und/oder Datenframes, die von dem IO-Gerät 5 stammen, werden über den Stream 8 in Rich tung des Feldbussegmentes la übertragen.

Für eine reibungsfreie Überführung der von dem jeweiligen Ge rät 2, 3, 4, 5, abgehenden Feldbus-Datenframes, welche als Ethernet—Frames (gemäß IEEE 802.3) vorliegen können und bei dem dargestellten Ausführungsbeispiel vorliegen, in Stream- fähige Datenframes, und umgekehrt, sind vorliegend zwei Ver bindungsknotenpunkte 9, 10 vorgesehen. Jedes der beiden Feld bussegmente la, lb ist über jeweils einen Verbindungsknoten punkt 9, 10 an das TSN-Netzwerk 6 angebunden, konkret das Segment la über den Verbindungsknotenpunkt 9 und das Segment lb über den Verbindungsknotenpunkt 10.

Beide Verbindungsknotenpunkte 9, 10 sind als 2-Port-Geräte ausgebildet und haben einen Feldbus-Port 11 in Richtung des jeweiligen Feldbussegmentes la, lb und einen Stream-Port 12 in Richtung des TSN-Netzwerkes 6. Die Ports 11, 12 können der FIG 3 entnommen werden, die beispielhaft eine vergrößerte, rein schematische Darstellung eines als 2-Port-Gerät ausge bildeten Verbindungsknotenpunktes 9, 10 zeigt. In der FIG 2 sind nur die Feldbus-Ports 11 gezeigt, nicht jedoch die

Stream-Ports 12 in Richtung des TSN-Netzwerkes 6.

Alternativ zu dem dargestellten Ausführungsbeispiel kann die Funktion eines Verbindungsknotenpunktes 9, 10 auch direkt in ein Gerät 2, 3, 4, 5 integriert sein, was dann unmittelbar an das TSN-Netzwerk 6 angeschlossen werden kann. Diese alterna tive Ausgestaltung ist rein schematisch in der FIG 4 darge stellt. Das Gerät 2, 3, 4, 5 hat dann einen Stream-Port 12, über den es an ein TSN-Netzwerk 6 angeschlossen werden kann. Diese Ausgestaltung kann insbesondere in demjenigen Falle zum Einsatz kommen, dass nicht zwei Feldbussegmente la, lb via Stream miteinander verbunden werden, sondern beispielsweise ein Feldbus 1 oder Feldbussegment la, lb mit einem Gerät 2,

3, 4,5, das nicht an einem Feldbus 1 liegt. Bei dem hier beschriebenen Ausführungsbeispiel ist eine logi sche Konfiguration in den Verbindungsknotenpunkten 9, 10 vor gesehen, welche die Überführung von Feldbus- in Stream-Da- tenframes und umgekehrt ermöglicht, konkret ist eine entspre chend ausgestaltete, in den Figuren nicht dargestellte PRU in jeden der beiden Verbindungsknotenpunkte 9, 10 integriert, welche durch ihr Programm die Pakete gezielt manipuliert und die benötigte Kennzeichnung der Datenframes (vgl. FIG 5) hin zufügt oder entfernt.

Die Verbindungsknotenpunkte 9, 10 sind dabei ausgebildet und eingerichtet, um Ethernet-Datenframes 13, die von Geräten 2,

3, 4, 5 aus dem jeweiligen Feldbussegment la, lb gesendet werden, und an dem Feldbus-Port 11 des jeweiligen Verbin dungsknotenpunktes 9, 10 ankommen, einen Header 14 mit

Stream-Parametern, konkret einer designierten Stream Adresse 15, einer Source-Adresse 16, einer VLAN ID 17 und eine Prio rität 18 voranzustellen, und über den jeweiligen Stream-Port 12 weiterzuleiten. Der Ethernet-Frame 13 mit vorangestelltem Stream-Header 14 bildet einen TSN-Stream-Datenframe 19, wie er in der rechten Hälfte der FIG 5 dargestellt ist.

Der Ethernet-Datenframe 13 umfasst neben den Nutzdaten 20 (auch als "Payload" bezeichnet) , diesen vorangestellt seiner seits eine designierte Adresse 21, eine Source-Adresse 22 ei ne Ethertype 23 und hinter den Nutzdaten 20 eine CRC 24.

Von den Verbindungsknotenpunkten 9, 10 wird eine neue CRC 25 vorgesehen .

Beide Verbindungsknotenpunkte 9, 10 sind ausgebildet und ein gerichtet, um Datenframes, die von Geräten 2, 3, 4, 5 aus dem jeweiligen Feldbussegment la, lb gesendet werden, und an dem Feldbus-Port des jeweiligen Verbindungsknotenpunktes 9, 10 ankommen, Stream-Parameter voranzustellen, und um aus Daten frames, die an dem Stream-Port ankommen, Stream-Parameter zu entfernen . Die Verbindungsknotenpunkte 9, 10 sind darüber hinaus beide ausgebildet und eingerichtet, um aus TSN-Stream-Datenframes 19, welche via Stream 7, 8 an ihrem Stream-Port 12 ankommen, den Stream-Header 14 mit der designierten Stream Adresse 15, Source-Adresse 16, VLAN ID 17 und Priorität 18 zu entfernen und Datenframes 13 ohne die entfernten Parameter, also Ether net-Datenframes 13, über den Feldbus-Port 11 an das jeweilige Feldbussegment la, lb weiterzuleiten.

In der FIG 5 ist beispielhaft ein Verbindungsknotenpunkt 9,

10 zwischen dem Feldbus-Datenframe 13 und Stream-Datenframe 19 dargestellt und über Pfeile 26 ist angedeutet, dass eine entsprechende Manipulation der Datenframes 13, 19 für beide Kommunikationsrichtungen stattfindet .

Es sei angemerkt, dass sowohl an den beiden Verbindungskno tenpunkten 9, 10 als auch an weiteren, zwischen diesen lie genden TSN-fähigen Knotenpunkten des TSN-Netzwerkes , die in den Figuren nicht weiter dargestellt sind, Ressourcen für die beiden Streams 7, 8 reserviert sind.

Bei dem dargestellten Ausführungsbeispiel wurde für die Re servierung für beide Richtungen konkret auf das Stream Reser vation Protocol (SRP) zurückgegriffen, welches als

IEE802.1Qat standardisiert ist.

Durch die Reservierung sind die zu übertragenden Daten vor einer zu großen Einwirkung von anderen Echt _Z eitanwendungen und/oder sonstigen Anwendungen im Netzwerk geschützt. Andere Anwendungen haben insbesondere nur eine kleine, aber genau bekannte Auswirkung auf die Übertragungszeit. Durch die Res sourcenreservierung kommt es nicht zum Verlust von Echtzeit daten .

Innerhalb des jeweiligen Feldbussegmentes la, lb findet die Datenübertragung via Ethernet statt. Bei dem dargestellten Ausführungsbeispiel konkret von dem jeweiligen Gerät 2, 3, 4, 5 zu einem Feldbus-Switch 27 des jeweiligen Feldbussegmentes la, lb und von diesem zu dem jeweiligen Verbindungsknoten punkt 9, 10, der dem Feldbussegment la, lb zugeordnet ist.

In der FIG 2 ist über an das TSN-Netzwerk 6 bzw. das Netzwerk des Feldbussegmentes lb angrenzende "Sprechblasen" die Nut zung der Bandbreite einerseits für das TSN- und andererseits das Feldbus-Netzwerk rein schematisch angedeutet.

Konkret sind für das Feldbus-Netzwerk (rechte "Sprechblase") einerseits eine Link-Bandbreite Bu _nk , eine Bandbreite B ₅ o _% , welche der Hälfte davon entspricht, und eine unterhalb von B _5O% liegende, tatsächlich verwendete Bandbreite B _v einge zeichnet. Vorliegend steht eine Bandbreite von 100 Mbit/s zur Verfügung, die fest auf eine Hälfte B ₅ o _{% (} 50 Mbit/s) für Echt zeit-Daten und eine weitere Hälfte (in der Regel 50 Mbit/s) für anderen Verkehr aufgeteilt ist.

In dem TSN-Netzwerk 6, in welchem eine höhere Bandbreite zur Verfügung steht, ist die Situation derart, dass eine maximale Klassen Bandbreite BK _max zur Verfügung steht und eine Stream- Bandbreite B _str eam, die darunter liegt. Die Stream-Bandbreite kann insbesondere entweder aus der Konfiguration des Feldbus ses 1, insbesondere der TIA-Konfiguration entnommen worden sein, beispielsweise 10 MBit/s betragen, oder auch, insbeson dere im Falle von PROFINET Durch die Systemdefinition auf ei nen Standardwert von 50 Mbit/s festgelegt werden.

Alternativ zu dem in der FIG 2 dargestellten Ausführungsbei spiel mit einem Feldbus 1 mit zwei Feldbussegmenten, la, lb, zwischen denen Daten via Stream 7, 8, übertragen werden, kön nen auch mehrere Feldbusse 1 an einem TSN-Netzwerk 6 liegen und Streams 7, 8 für die mehreren Feldbusse 1 in dem TSN-

Netzwerk 6 eingerichtet sein.

Eine Konstellation für mehr als eines Feldbusses 1 ist bei spielhaft und rein schematisch in der FIG 6 gezeigt. Gleiche Komponenten sind darin mit gleichen Bezugsziffern versehen.

Es sei angemerkt, dass in der FIG 6 die Feldbussegmente la, lb nicht dargestellt sind, sondern nur drei Paare von Verbin dungsknotenpunkten 9, 10 , zwischen denen jeweils zwei

Streams 7, 8 in entgegengesetzter Richtung für jeweils einen

Feldbus 1 mit über die Streams verbundenen Feldbussegmenten la, lb eingerichtet sind. Für jeden einzelnen der drei Feld busse 1 mit jeweils zwei Segmenten la, lb gilt, dass die An ordnung wie in FIG 2 ist.

Man erkennt, dass der Netzwerkpfad für das horizontal und das vertikal schraffierte Paar von Verbindungsknotenpunkten 9, 10 gleich ist, konkret die Streams 7, 8 für beide Verbindungs knotenpunktpaare und somit zugehörigen Feldbusse 1 über die gleichen beiden TSN-Switches 28 des TSN-Netzwerkes 6 verlau fen. Über den linken dieser beiden TSN-Switches 28 gehen auch noch die Streams 7, 8 des dritten Feldbusses 1. An diesem, in der FIG 6 unten links liegenden TSN-Switch 28 liegen somit Reservierungen für alle sechs Streams 7, 8 vor, an dem unten rechts liegenden TSN-Switch 28 für vier Streams 7, 8 und an dem oberen Switch 28 nur für zwei Streams 7, 8.

Es sei betont, dass diese Konfiguration rein beispielhaft ist und das TSN-Netzwerk 6 eine beliebige andere Anzahl von Swit ches 28 umfassen und die Reservierungen auch anders sein kön nen .

Weiterhin kann alternativ zu den bisher beschriebenen Ausfüh rungsbeispielen auch vorgesehen sein, dass mehr als zwei Feldbussegmente la, lb über ein TSN-Netzwerk 6 verbunden und in diesem Streams 7, 8 eingerichtet sein können.

Es sei angemerkt, dass im einfachsten Fall ein Feldbussegment auch von einem einzelnen, dem Feldbus 1 zugeordneten Gerät 2, 3, 4, 5 gebildet sein. Es ist also auch möglich, dass zwei oder mehr Feldbussegmente la, lb und weitere Geräte 2, 3, 4,

5 über ein TSN-Netzwerk 6 verbunden und in diesem Streams 7,

8 eingerichtet sein können. Eine Konstellation, in der zwei Feldbussegmente la, lb und ein weiteres Feldbus-Gerät 3 über das TSN-Netzwerk 6 verbun den sind und über dieses kommunizieren, ist in den Figuren 7 und 8 rein beispielhaft und schematisch dargestellt. In die sen Figuren sind wiederum gleiche Bezugszeichen verwendet worden .

In einem solchen Fall werden drei Verbindungsknotenpunkte 9, 10, 29 für den Feldbus 1 vorgesehen und drei Streams 7, 8, 30 in dem TSN-Netzwerk 6 eingerichtet.

In FIG 7 sind dabei - in Analogie zu FIG 6 - nur die Verbin dungsknotenpunkte 9, 10, 29 und Streams 7, 8, 30 für die drei Feldbusse 1, von denen einer drei über das TSN-Netzwerk 6 verbundenen Feldbussegmente la, lb, lc aufweist und dem somit drei Verbindungsknotenpunkte 9, 10, 29 zugeordnet und für den drei Streams 7, 8, 30 eingerichtet sind, gezeigt. Die FIG 8 zeigt - in Analogie zu der FIG 2 - die Situation nur eines Feldbusses 1 aus der FIG 7, konkret den Feldbus 1 mit drei Segmenten la, lb, lc, wobei das dritte Feldbussegment lc durch eine einzelnes Gerät, konkret einen Bildschirm 3 gebil det wird.

Von jedem Feldbussegment la, lb, lc geht ein Stream 7, 8, 30 ab, über den jeweils an beide anderen Feldbussegmente la, lb, lc Daten gesendet werden (vgl. auch die Pfeile in FIG 7 und 8) . Dies ist eine Multiple Listener per Talker Konstellation und für die Ressourcen-Reservierung wurde bei dem dargestell ten Ausführungsbeispiel auf das Stream Reservation Protocol (SRP) zurückgegriffen, welches dies unterstützt.

Die FIG 9 zeigt zur weiteren Veranschaulichung in rein sche matischer Darstellung Daten 31, die im Feldbus 1, insbesonde re bis zu einem Verbindungsknotenpunkt 9, 10, 29 oder ab ei nem solchen übertragen werden (angedeutet durch den Doppel pfeil 32), rechts von den Daten 30 einen Verbindungsknoten punkt 9, 10, 29 mit Feldbus-Port 11 und wiederum rechts davon nochmals einen Stream-Datenframe 19 mit Stream-Header 14 und Nutzdatenbereich bzw. "Payload" 13 und CRC 25. Die Anbindung des Verbindungsknotenpunktes 9, 10, 29 an das TSN-Netzwerk 6 ist auch in der FIG 6 schematisch durch eine Wolke angedeu tet .

In den Figuren 10 und 11 wird ist die Frame-Weiterleitung nä her veranschaulicht, wobei in FIG 10 vier nacheinander an ei nem Verbindungsknotenpunkt 9, 10, 29 ankommenden Feldbus-Da- tenframes schematisch über die Zeit t dargestellt sind. Die Feldbus-Datenframes sind in der FIG 10 mit FDo, FDi, FD ₂ und FD3 bezeichnet. Die Feldbus-Datenframes FDo, FDi, FD2, FD3 können mit der maximal möglichen Bandbreite ankommen.

Darunter dargestellt sind die dazu korrespondierenden vier Stream-Datenframes (welche durch die streamfähig "eingepack ten" Feldbus-Datenframes gegeben sind) die mit SDo, SDi, SD ₂ und SD3 bezeichnet sind. Links des ersten Stream-Datenframes SDo ist mit gestrichelter Linie ein vorangegangene Stream-Da- tenframe angedeutet. Man erkennt, dass die Stream-Datenframes SDo, SDi, SD ₂ , SD ₃ eine geringere Ausdehnung in Richtung der Zeitachse 34 aufweisen, was auf die im TSN-Netzwerk 6 gegen über dem Feldbus-Netzwerk höhere Badbreite zurückzuführen ist. Die Stream-Datenframes SDo, SDi, SD2 _, SD3 können mit der höheren Bandbreite übertragen werden.

In der FIG 11 sind die vier Stream-Datenframes SDo, SDi _, SD2 _,

SD3 oben nochmals dargestellt, wobei darunterliegend skiz ziert ist, dass die Weiterleitung derart erfolgt, dass nach dem Senden jedes Stream-Datenframes SDo, SDi _, SD2 _, SD3 eine Pau se Po, Pi, P2, P3 gemacht wird, deren Länge von der gesendeten Datenmenge, die in der FIG als Größe Go, Gi, G2, G ₃ des jewei ligen Stream-Datenframes SDo, SDi _, SD2 _, SD3 angedeutet ist, und der Bandbreite, welche für den jeweiligen Stream 7, 8, 30 re serviert ist, abhängt. Sind beispielsweise 25 % der Bandbrei te für einen Stream 7, 8, 30 reserviert, ist die nach jedem Datenframe SDo, SDi _, SD ₂ , SD ₃ folgende Pause dreimal so lang, wie die Übertragungszeit für den Frame SDo, SDi _, SD ₂ , SD ₃ . Je größer der jeweilige Stream-Datenframe SDo, SDi _, SD2 _, SD3 ist, je länger ist auch die Pause Po, Pi, P ₂ , P3. Über die jeweili ge Pause wird die Einhaltung der Bandbreite garantiert. Wurde die Bandbreite vorher eingehalten, kann der nächste Frame SDo, SDi _, SD ₂ , SD ₃ immer direkt übertragen werden, wenn er an kommt .

Diese Vorgehensweise entspricht dem AVB- bzw. dem TSN-Model mit Reserved Traffic für Streams unter Verwendung des CBS (Credit Based Shaper) Mechanismus (IEE 802.1Qav) . Für die Streams sind Netzwerkressourcen, u.a. die Bandbreite, reser viert .

Es sei angemerkt, dass in der FIG 11 unterhalb des jeweiligen Streams SDo, SDi, SD ₂ , SD ₃ mit der "gezackten" Linie der

"Credit" angedeutet ist, der sich nach der Übertragung eines Frames SDo, SDi, SD ₂ , SD ₃ aus dem negativen Bereich während der Pause wieder bis auf Null "erholen" muss, damit der nächste Frame SDo, SDi, SD ₂ , SD ₃ übertragen werden darf.

Eine der Anmelderin bekannte Alternative der Übertragung von Feldbus-Datenframes FDo, FDi, FD2, FD3 in einem Netzwerk mit höherer Bandbreite, welche diese Vorteile nicht bietet, ist in der FIG 12 - wiederum rein schematisch - dargestellt.

Dabei sind in der FIG 12 oben - in Analogie zu der FIG 10 - vier Feldbus-Datenframes FDo, FDi, FD2, FD3 in einem Feldbus- Netzwerk mit geringerer Bandbreite und darunter in einem Netzwerk mit höherer Bandbreite gezeigt. Die Feldbus-Daten frames FDo, FD _I , FD ₂ , FD ₃ werden nicht, wie unter Bezugnahme auf FIG 11 beschrieben, über Streams mit über Reservierungen gesicherten Ressourcen übertragen, sondern es ist in jedem Netzwerkzyklus 35 ein festes Zeitfenster F für die Übertra gung der Frames FDo, FDi, FD2, FD3 vorgesehen. Ist die Daten menge insbesondere eines Frames zu groß, um innerhalb des Fensters F vollständig übertragen zu werden, muss die Über tragung im nächsten Zyklus erfolgen bzw. fortgesetzt werden, was in der FIG 12 durch die in den jeweils folgenden Zyklus weisenden Pfeile 36 angedeutet ist, und es kommt zu einem Stau von Paketen. Die Bandbreite kann nie ganz ausgenutzt werden. Ein weiteres Problem dieser zeitbasierten Weiterlei tung besteht darin, dass ein unterschiedlicher Takt im Feld bussystem (Anwendung ist Zeittreiber) und dem Netzwerk höhe- rer Bandbreite (Systemzeit im Netzwerk) kommen kann.

Obwohl die Erfindung im Detail durch das bevorzugte Ausfüh rungsbeispiel näher illustriert und beschrieben wurde, so ist die Erfindung nicht durch die offenbarten Beispiele einge- schränkt und andere Variationen können vom Fachmann hieraus abgeleitet werden, ohne den Schutzumfang der Erfindung zu verlassen .