VERFAHREN ZUR DATEN-KOMMUNIKATION IN EINEM INSBESONDERE INDUSTRIELLEN NETZWERK, VORRICHTUNG ZUR DURCHFÜHRUNG DES VERFAHRENS, COMPUTERPROGRAMM SOWIE COMPUTERLESBARES MEDIUM

Abstract

 Die Erfindung betrifft ein Verfahren zur Daten-Kommunikation in einem insbesondere industriellen Netzwerk mit einem oder mehreren Knotenpunkten (2), für einen Datentransfer zwischen mehreren Daten bereitstellenden Sendern (11) und einem die von den mehreren Sendern (11) bereitgestellten Daten über einen Stream empfangenden Empfänger (1), bei dem für die Einrichtung des Streams von dem Empfänger (1) eine Listener Advertise Nachricht für den Stream herausgegeben wird, die bevorzugt eine Streambeschreibung umfasst, und die Listener Advertise Nachricht an wenigstens einen Knotenpunkt (2) des Netzwerkes übertragen wird. Darüber hinaus betrifft die Erfindung eine Vorrichtung zur Durchführung des Verfahrens. Schließlich betrifft die Erfindung ein Computerprogramm und ein computerlesbares Medium.

Beschreibung

[0001] Die Erfindung betrifft ein Verfahren zur Daten-Kommunikation in einem insbesondere industriellen Netzwerk. Darüber hinaus betrifft die Erfindung eine Vorrichtung zur Durchführung des Verfahrens. Schließlich betrifft die Erfindung ein Computerprogramm und ein computerlesbares Medium.

[0002] Verteilte industrielle Steuerungsanwendungen erfordern eine garantierte Quality of Service (QoS) oder Dienstgüte in dem Kommunikationsnetzwerk, welches die Endgeräte miteinander verbindet, damit zeitsensitive Aufgaben neben nicht-Echtzeitrelevantem Datenverkehr (traffic) von dem Netzwerk ausgeführt werden können. Bei den Endgeräten kann es sich beispielsweise um speicherprogrammierbare Steuerungen (SPS, englisch: Programmable Logic Controller, PLC) IO-Geräte oder Schutzeinrichtung handeln.

[0003] Jede Verbindung für jede Anwendung in dem Netzwerk, die zeitsensitiven Datenverkehr zwischen Endgeräten ermöglicht, muss registriert und reserviert werden, um von dem Netzwerk Garantien für einen verlustfreien Echt-Zeit-Transfer von Datenframes und eine pünktliche Lieferung zu erhalten. Das Netzwerk muss dafür die Verfügbarkeit von Netzwerkressourcen (beispielsweise Adresstabelleneinträge Framebuffer, transmit time slices) verifizieren und Ressourcen - sofern verfügbar - zuweisen, dies für jeden Echtzeit-Datenfluss, und es muss Zugang für Echtzeit-Datenverkehr gewähren.

[0004] Innerhalb des Netzwerkes muss die Kontrollinformation über Registrierungen, Reservierungen und Weiterleite-Informationen für jeden Echtzeit-Datenfluss gespeichert werden. Der Status von jeder Reservierung muss aufrechterhalten werden. Mit einer zunehmenden Anzahl von Endgeräten und ihrem Echtzeit-Datenverkehr in demselben Netzwerk wächst die Menge von Netzwerkkontrollinformationen an. Da die Speicher- und Verarbeitungsleistung von Netzwerkknotenpunkten, beispielsweise Brigdes bzw. Switches, begrenzt ist, stellt dies ein gravierendes Skalierungsproblem dar. Insbesondere für den Fall, dass ein Kontenpunkt und ein Endgerät in einem einzelnen Produkt kombiniert sind, beispielsweise in einem IO-Modul mit zwei geswitchten Ports zur Verwendung in Linien-/Ring-Topologien, wie sie in heutigen Ethernet Fabrikhallenlösungen gefunden werden, ist dies problematisch.

[0005] Die IEEE802.1 TSN Arbeitsgruppe definiert Erweiterungen des Ethernet Standards IEEE802.1/.3 für ein konvergierendes zeitsensitives Netzwerk (Time Sensitive Network, TSN). Basierend auf vorangegangener Arbeit der Audio-Video-Bridging (AVB) Arbeitsgruppe wird der Quality of Service für Echtzeit-Datenflüsse, was die garantierte Latenz angeht weiter verbessert. Der Status für jeden Echtzeit-Datenfluss muss dabei jedoch weiterhin im Netzwerk aufrecht erhalten werden.

[0006] "Multiple Listeners per Stream" wurde in AVB eingeführt, um die Anzahl von Echtzeit-Datenflüssen (IEEE802 nennt dies "Stream") von einer Quelle (Talker) zu mehreren Zielen (Listener) zu reduzieren. Dass Daten von einer Quelle an mehrere Ziele zu übertragen sind ist der typische AV (Audio Video) Anwendungsfall, konkret für die Verteilung von Audiodaten von einer einzelnen Quelle an mehrere Lautsprecher. Es ist bekannt, dass dieses Reservierungsmodell von AVB/TSN "Multiple Stream Reservation Protocol" (MSRP) mehrere Listener unterstützt. Dabei kann im Anschluss an eine von der Quelle abgehenden "Talker Advertise"-Nachricht für eine Stream mehrere "Listener join"-Reservierungen durchgeführt werden, was in einen einzelnen Streamkontroll-Informationseintrag resultiert. Die Weiterleitung von dem einen Talker zu seinen Listenern geht entlang eines einzelnen Baumes, dessen Wurzel (root) der Talker darstellt, wobei dann nur ein einzelner Weiterleite-Eintrag für alle Stream-Listener in den Netzwerkknotenpunkten erforderlich ist. Ein einzelner Ethernet-Frame wird von dem einen Talker über das Netzwerk an die mehreren Listener verteilt.

[0007] Dieses Modell könnte im Rahmen der industriellen Automatisierung Verwendung finden, um die Anzahl von Streams von einer den Talker darstellenden SPS zu mehreren Listener darstellenden IO-Geräten Verwendung finden. Die Daten für alle "hörenden" (listening), also empfangenden IO-Geräte können unter Verwendung eines einzelnen Streams von der SPS transferiert werden. Die Anzahl der Streams im Netzwerk und somit die Menge an Kontrollinformationen ist dann gegenüber dem Fall, dass für jedes IO-Gerät ein eigener Stream für den Empfang von Daten von der SPS eingerichtet wird, deutlich reduziert. Abhängig von der Menge an Daten der einzelnen IO-Geräte, kann der Vorteil der vereinfachten Kontrollinformation eine exzessivere Benutzung von Bandbreite des Netzwerk sein, da individuelle IO-Geräte nur einen Teil (subset) der Information des in dem via Stream übertragenen Frames benötigen.

[0008] Da ein Regelkreis (closed loop control) auch einen Rückkanal von jedem IO-Gerät zu der SPS benötigt, muss dann doch eine insgesamt hohe Anzahl von Streams in dem Netzwerk eingerichtet werden, einer von jedem IO-Gerät zu der SPS, also für die "Rückrichtung". In jedem Stream muss ein Ethernet Frame, der 64+ Oktette (octets) erfordert. gesendet werden, selbst wenn das IO-Gerät nur ein paar Bits von Eingabeinformationen für die SPS bereitstellt.

[0009] Ein Echtzeit-Datenfluss in AVB kann mehrere Frames in einer Periode haben. AVB Echtzeitflüsse sind jedoch an den Credit Based Shaper (CBS) gebunden, welcher die Frames gleichmäßig über die gesamte Periode verteilt. TSN ermöglicht die Verwendung anderer Shaper, beispielsweise Strict Priority, mit höchster Priorität für den EchtzeitDatenfluss und Bandbreitenlimitierung, um die CBS-Limitierungen für diesen Anwendungsfall zu überwinden. Ein Burst von mehreren Frames wird in einem TSN Netzwerk nicht mehr gleichmäßig über die Periode verteilt. Dadurch können alle IO Daten auch in mehreren Frames direkt hintereinander vom Netzwerk übermittelt werden, wie es für Regelkreis-Anwendungen typisch ist.

[0010] Die Aufgabe der vorliegenden Erfindung besteht darin, ein Verfahren der eingangsgenannten Art anzugeben, welches eine Datenkommunikation in einem Netzwerk mit vertretbare, Aufwand ermöglicht, insbesondere auch in einem industriellen Netzwerk, in welchem Endgeräte in einem geschlossen Regelkreis miteinander kommunizieren müssen.

[0011] Weiterhin ist es Aufgabe der vorliegenden Erfindung, eine Vorrichtung zur Durchführung eines solchen Verfahrens anzugeben.

[0012] Diese Aufgabe wird gelöst durch ein Verfahren zur Daten-Kommunikation in einem insbesondere industriellen Netzwerk mit einem oder mehreren Knotenpunkten, für einen Datentransfer mehreren Daten bereitstellenden Sendern und einem die von den mehreren Sendern bereitgestellten Daten über einen Stream empfangenden Empfänger, bei dem für die Einrichtung des Streams von dem Empfänger eine Listener Advertise Nachricht für den Stream herausgegeben wird, die bevorzugt eine Stream-beschreibung umfasst, und die Listener Advertise Nachricht an wenigstens einen Knotenpunkt des Netzwerkes übertragen wird.

[0013] Es ist insbesondere vorgesehen, dass die Listener Advertise Nachricht im Netzwerk verbreitet wird, insbesondere an mehrere, bevorzugt alle Knotenpunkte im Netzwerk übertragen wird.

[0014] Weiterhin bevorzugt wird die Listener Advertise Nachricht an mehrere Sender übertragen, wobei die Übertragung an den jeweiligen Sender bevorzugt über denjenigen Knotenpunkt oder diejenige Kontenpunkte erfolgt, der oder die auf den dem jeweiligen Sender und Empfänger verbindenden Netzwerkpfad liegt oder liegen.

[0015] In weiterer besonders bevorzugter Ausgestaltung des erfindungsgemäßen Verfahrens ist vorgesehen, dass von wenigstens einem Sender, welcher über den Stream Daten an den Empfänger übermitteln will, in Reaktion auf den Listener Advertise des Empfängers eine Talker Join Nachricht gesendet und für diesen eine Talker Join Reservierung an den Knotenpunkten auf dem Netzwerkpfad zwischen dem Sender und dem Empfänger durchgeführt wird. Insbesondere ist vorgesehen, dass von mehreren Sendern, die jeweils über den Stream Daten an den Empfänger übermitteln wollen, in Reaktion auf den Listener Advertise des Empfängers jeweils eine Talker Join Nachricht gesendet und eine Talker Join Reservierung an den Knotenpunkten auf einem Netzwerkpfad zwischen dem jeweiligen Sender und dem Empfänger durchgeführt wird.

[0016] Die (jeweilige) Talker Join Nachricht umfasst weiterhin bevorzugt eine Stream-ID und/oder einen Reservierungsstatus.

[0017] Es sei angemerkt, dass - wie vom Stand der Technik für die Stream-Einrichtung zwischen einem Sender und einem oder mehreren Empfängern vorbekannt - die Reservierung erfolgreich sein kann oder auch nicht, je nachdem, ob Netzwerkressourcen zur Verfügung stehen, insbesondere Netzwerkressourcen, welche die Anforderungen einer von dem Empfänger herausgegebenen Streambeschreibung genügen oder nicht.

[0018] Die vorliegende Erfindung schlägt mit anderen Worten vor, zur Reduzierung der Anzahl von Streams in demjenigen Falle, dass Daten von mehreren Quellen/Sendern an genau ein Ziel/Empfänger gesendet werden sollen, existierende Reservierungsmodelle zu verbessern, konkret derart, dass sie eine "Multiple Talker per Listener" Konfiguration unterstützen.

[0019] Hierzu ist erfindungsgemäß vorgesehen, dass von wenigstens einem Endgerät, welches Daten von mehreren anderen Endgeräten im Netzwerk empfangen möchte, das also den einen Empfänger darstellt, während die anderen, Daten bereitstellenden Geräte die mehreren Sender bilden, eine Listener Advertise Nachricht herausgegeben und insbesondere im Netzwerk verteilt wird. Mit der Listener Advertise Nachricht kündigt das den einen Empfänger bildende Endgerät an, dass es Daten über den einen Stream empfangen will. Die Listener Advertise Nachricht umfasst bevorzugt eine Beschreibung des Streams, über welchen dann mehrere Sender an den Empfänger Daten, insbesondere in Form von zyklisch übermittelten Frames, senden können. Die Streambeschreibung umfasst beispielsweise eine Weiterleite-Adresse und eine Bandbreiteninformation.

[0020] Um "Multiple Talker per Listener" möglich zu machen, wird mit dem "Listener Advertise" erfindungsgemäß ein neues Attribut bzw. Datenobjekt eingeführt, das im Rahmen eines Reservierungsmodelles Verwendung finden kann.

[0021] Das erfindungsgemäß neu vorgesehene Attribut bzw. Datenobjekt des "Listener Advertise" korrespondiert, wenn man einen Vergleich mit dem Stand der Technik zieht, zu dem "Talker Advertise" für den vorbekannten Fall eines Datentransfers von einem Sender/Talker an einen oder mehrere Empfänger/Listener via Stream. Der Unterscheid zum Stand der Technik besteht darin, dass der eine Empfänger, welcher Daten über einen Stream erhalten möchte, den "Advertise" herausgibt, wohingegen nach dem Stand der Technik der eine Sender advertised, also ein "Talker Advertise" von diesem herausgegeben und über die Kontenpunkte im Netzwerk an mögliche Empfänger verteilt wird. Bei der Vorgehensweise nach dem Stand der Technik erfolgt der Stream-Advertise entlang eines Netzwerkbaumes (Tree's), dessen Ursprung bzw. Wurzel (Root) der eine Sender/Talker bildet und welcher insbesondere durch die Gesamtheit der Netzwerkpfade definiert ist, über welche Daten an die mehreren Empfänger/Listener gehen.

[0022] Die Datenübertragung via Stream, insbesondere die zyklische Übertragung von Frames von dem einen Sender an die mehreren Empfänger über den einen Stream erfolgt anschließend in die gleiche Richtung, wie der Stream Advertise, also von dem Sender zu den Empfängern entlang der Netzwerkpfades des Baumes.

[0023] Erfindungsgemäß hingegen erfolgt der Stream-Advertise durch den einen Empfänger und wird insbesondere an mehrere Sender verteilt. Bei dem erfindungsgenmäßen neu vorgesehenen Attribut ist die Wurzel des Netzwerkbaumes dabei der eine Listener.

[0024] Nachdem der eine Empfänger eine Listener Advertise Nachricht herausgegeben hat und diese bevorzugt über die Knotenpunkte im Netzwerk verteilt und an Daten bereitstellende Geräte, also potentielle Sender übermittelt wurde, können sich die Geräte, die Daten an diesen Empfänger übertragen möchten bzw. von denen der Sender Daten empfangen möchte, an dem Stream anmelden, und es wird eine Ressourcen-Reservierung durchgeführt. Hierfür ist in besonders bevorzugter Ausführungsform der Erfindung ein weiteres neues Attribut bzw. Datenobjekt vorgesehen, der "Talker Join" zur Reservierung der Ressourcen, welcher von dem jeweiligen Sender herausgegeben wird und die Reservierung(en) an dem oder den Knotenpunkten auf einem Netzwerkpfad zwischen dem entsprechenden Sender und dem Empfänger bewirkt.

[0025] Es sei angemerkt, dass die Information darüber, von welchen Geräten im Netzwerk der eine Empfänger Daten erhalten möchte, zuvor auf anderem Wege erhalten worden sein kann. Dies ist vergleichbar mit dem AVB Modell, bei dem die Listener eine Stream ID von der Anwendung bekommen, welche im Talker Advertise verwendet wird. Im industriellen Umfeld kann die Information zum Beispiel von der Anwendung kommen, welche das Programm der SPS und der IO Geräte erzeugt und sich z.B. durch einen Netzwerk-Service eine freie Stream ID bezieht.

[0026] Der sich an den Listener Advertise anschließende Ressourcen-Reservierungs-Vorgang erfolgt dann in zum Stand der Technik umgekehrter Richtung, beginnt konkret nicht empfänger- sondern senderseitig. Die Reservierung entlang des jeweiligen Netzwerkpfades startet insbesondere an dem dem jeweiligen Sender am nächsten liegenden Knotenpunkt und "propagiert" in Richtung des Empfängers, wohingegen nach dem Stand der Technik (Listener Join) mit der Reservierung bei dem dem jeweiligen Empfänger am nächsten liegenden Knotenpunkt begonnen und in Richtung des Senders fortgeführt wird.

[0027] Gemäß einer vorteilhaften Ausführungsform des erfindungsgemäßen Verfahrens ist vorgesehen, dass an wenigstens einem Knotenpunkt, insbesondere an mehreren Knotenpunkten ein Reservierungsstatus eines erstes Portes in Richtung eines oder mehrerer Sender und ein Reservierungsstatus eines zweiten Portes in Richtung eines oder mehrerer weiterer Sender zusammengefasst werden, und insbesondere der zusammengefasste Reservierungsstatus über einen Port in Richtung des Empfängers weitergeleitet wird.

[0028] Besonders bevorzugt ist vorgesehen, dass der dem Empfänger am nächsten liegende Knotenpunkt einen für alle Sender zusammengefassten Reservierungsstatus an den Empfänger weiterleitet, wobei insbesondere der bei dem Empfänger ankommende Reservierungsstatus die Information umfasst, dass eine Reservierung der senderseitigen Ports aller Knotenpunkte auf den die Sender und den Empfänger verbindenden Netzwerkpfaden erfolgreich war, oder dass eine Reservierung der senderseitigen Ports aller Knotenpunkte auf den die Sender und den Empfänger verbindenden Netzwerkpfaden nicht erfolgreich war, oder dass eine Reservierung wenigstens eines senderseitigen Ports wenigstens eines Knotenpunktes auf den die Sender und den Empfänger verbindenden Netzwerkpfaden nicht erfolgreich war und eine Reservierung wenigstens eines senderseitigen Ports wenigstens eines Knotenpunktes auf den die Sender und den Empfänger verbindenden Netzwerkpfaden erfolgreich war.

[0029] Es sei angemerkt, dass die Status-Merge-Funktion für Listener-Stati aus dem Stand der Technik vorbekannt ist. Dabei basiert die Reservierung, beispielsweise in einem AVB Netzwerk, auf einem einzelnen Weiterleitungsbaum, welcher mit RSTP (Rapid Spanning Tree Protocol) gebaut wird. Die Listener-Stati werden in Aufwärtsrichtung des Baumes zu dem einen Sender hin zusammengeführt (merged).

[0030] Bei den vorstehenden Ausführungsformen der vorliegenden Erfindung verhält es sich - erneut - genau umgekehrt. Die Talker-Stati werden in Aufwärtsrichtung des Baumes zu dem genau einen Empfänger zusammengeführt (merged).

[0031] Während gemäß der aus dem Stand der Technik bekannten Vorgehensweise die Reservierungs-Stati von Knotenpunkten zusammengefügt (merge) werden, die über die Empfänger- also Listener-seitigen Ports an dem jeweiligen Kontenpunkt ankommen, und für die Datenverteilung an mehrere Ziele eine Duplikation der Frames in den betreffenden Knotenpunkten stattfindet, erfolgt das Zusammenführen (merge) nicht von Listener- sondern Talker-Stati.

[0032] Auf die für die Empfänger/Listener vorbekannte Status-Merge-Funktion bekannter Protokolle kann dabei zurückgegriffen bzw. es kann auf diesen aufgebaut werden, da die eigentliche Reservierung von Ressourcen an dem bzw. den Knotenpunkten prinzipiell gleich bzw. analog zu der vorbekannten Vorgehensweise ablaufen kann.

[0033] Es kann bei dem erfindungsgemäßen Verfahren weiterhin vorgesehen sein, dass für die Reservierung von Ressourcen an einem oder mehreren Knotenpunkten wenigstens ein Reservierungsprotokoll verwendet wird. Es kann auf ein vorbekanntes, insbesondere standardisiertes Reservierungsprotokoll zurückgegriffen werden, welches dann bevorzugt um wenigstens ein, insbesondere mehrere Datenobjekte erweitert ist. Beispiele für bekannte, standardisierte Reservierungsprotokolle, die im Rahmen des erfindungsgemäßen Verfahrens in insbesondere erweiterter Form zum Einsatz kommen können, sind Stream Reservation Protocol (SRP) und/oder Multiple Stream Registration Protocol (MSRP) und/oder Ressource Reservation Protocol (RSVP) .

[0034] SRP ist die bekannte Änderung bzw. Erweiterung des IEEE802.1Q Standards, die separat als IEEE802.1Qat standardisiert wurde.

[0035] Die Listener Advertise Nachricht und/oder die Talker Join Nachricht und/oder die Talker Join Reservierung stellen dann besonders bevorzugt das Reservierungsprotokoll, beispielsweise SRP und/oder MSRP und/oder RSVP, erweiternde Datenobjekte dar.

[0036] Die neuen Attribute bzw. Datenobjekte für die gemäß der vorliegenden Erfindung vorgesehenen Multiple Talker Reservierungen können insbesondere in vorhandene, standardisierte Fluss-Reservierungsprotokolle eingeführt werden, ohne dass das fundamentale Prinzip der Echtzeit-Flussreservierung geändert werden muss.

[0037] Weiterhin kann vorgesehen sein, dass insbesondere unter Verwendung des Rapid Spanning Tree Protocols der Netzwerkbaum bestimmt wird, der durch Netzwerkpfade gebildet wird, die den einen Empfänger mit denjenigen Sendern verbinden, die über den Stream Daten an den Empfänger senden wollen und von denen insbesondere jeweils eine Talker Join Nachricht gesendet wurde.

[0038] Der bestimmte, zu dem Stream zwischen den mehreren Sendern und dem einen Empfänger gehörende Netzwerkbaum, der auch als Listener-Tree bezeichnet werden kann, stellt bevorzugt ein Datenobjekt dar, welches ein für die Ressourcen-Reservierung zum Einsatz kommendes Reservierungsprotokoll, beispielsweise SRP und/oder MSRP, erweitert.

[0039] Der Listener-Tree resultiert aus dem erfindungsgemäßen Listener Advertise und umfasst insbesondere die Information über einen Listener Port je Knotenpunkt, insbesondere Bridge, und bevorzugt die vielen möglichen Talker Ports. Der von den einen Listener ausgehende Listener Advertise dient praktisch als neue logische Wurzel eines Baums für die Reservierungen.

[0040] Die sich an den Listener Advertise und die Talker Joins, insbesondere Reservierungen anschließende Datenübertragung von mehreren Sendern an den Empfänger, insbesondere in Form von zyklisch gesendeten Frames, erfolgt dann in der zum Listener Advertise entgegengesetzten Richtung nämlich von dem jeweiligen Sender zu dem einen Empfänger, also in "Reservierungsrichtung".

[0041] In weiterer vorteilhafter Ausführungsform ist vorgesehen, dass die Listener Advertise Nachricht eine Streambeschreibung umfasst, die eine Angabe des Streamtyps aufweist, wobei bevorzugt als Streamtyp ein akkumulierter Stream oder ein Multiplex-Stream angegeben ist.

[0042] Bei dem akkumulierten Streamtyp ist insbesondere vorgesehen, dass in jeder Periode ein Frame von allen an dem Stream teilnehmenden Sendern an den Empfänger übermittelt wird, wobei diese "Datenakkumulation" zu eine größeren Bandbreite führt, jedoch eine geringe Latenz ermöglicht, da alle Sender "gleichzeitig" senden können. Beim akkumulierten Stream-Typ muss jedoch eine Zwischenspeicherung von Frames in den Bridges erfolgen, da immer nur die reservierte Anzahl an Frames in jeder Periode über den Listener-seitigen Port weitergeleitet werden kann.

[0043] Gemäß dem Multiplex-Streamtyp hingegen wird in jeder Periode nur der Frame eines Senders übermittelt, das heißt, es erfolgt ein warten. Der Multiplex Streamtyp kommt mit einer geringeren Bandbreite aus, wobei es jedoch länger dauert, bis die Daten bei einem Empfänger ankommen, da nacheinander übermittelt wird. Je nachdem, wie die konkreten Anforderungen eines gegebenen Anwendungsfalles liegen, kann eine Entscheidung auf den einen oder den anderen Typ fallen.

[0044] Die vorliegende Erfindung, die erstmals "Multiple Talker for one real time flow/stream" ermöglicht, bietet eine Vielzahl von erheblichen Vorteilen. Einerseits wird die Anzahl der Echtzeitflüsse, also Streams in einem Netzwerk reduziert. Damit geht eine Reduzierung des Control Overheads für die Registrierung und Reservierung der Streams und eine Reduzierung der Anzahl von Filterdatabase-Einträgen in den Kontenpunkten einher und es wird der gleiche Overhead für beide Richtungen des Datentransfers erzielt. Weiterhin wird die Skalierbarkeit verbessert, da mehr Endgeräte, insbesondere Sensoren/Aktoren unterstützt werden können. Die erfindungsgemäße Vorgehensweise ist weiterhin von der gegebenen Netzwerktopologie unabhängig. So ist sie keineswegs auf beispielsweise eine Linientopologie beschränkt, sondern kann gleichermaßen auch bei Vorliegen anderer Netzwerktopologien, etwa einer Ring- oder Sterntopologie, zum Einsatz kommen. Weiterhin wir die Kommunikationskonfiguration durch die erfindungsgemäße Vorgehensweise vereinfacht. Auch kann das Engineering von Kontrollanwendungen vereinfacht werden, insbesondere ist eine automatische Kommunikationskonfiguration ohne Engineering möglich und die Kontrollinformation für Feldbusanwendungen kann vereinfacht werden.

[0045] Ob ein Stream zwischen einem Empfänger und mehreren Sendern im Sinne der Erfindung besteht, kann insbesondere daran ausgemacht werden, dass genau eine Stream-ID vorliegt und mehrere Sender Daten über den einen Stream mit der einen ID an den einen Empfänger übertragen. Dabei kann die gleiche Stream-Zieladresse für die Daten von mehreren Sendern verwendet werden.

[0046] Es versteht sich, dass in einem Netzwerk eine Mehrzahl von Streams, über die jeweils Daten in einer von genau einem Empfänger und zwei oder mehr Sendern gebildeten Gruppe von Kommunikationspartnern ausgetauscht werden können, also eine Mehrzahl von Streams auf die erfindungsgemäße Weise mit Listener Advertise und Talker Join(s) eingerichtet werden können.

[0047] Alternativ oder zusätzlich kann die vorstehende Aufgabe gelöst werden durch ein Verfahren zur Daten-Kommunikation in einem insbesondere industriellen Netzwerk mit einem oder mehreren Knotenpunkten, bei dem ein Stream zwischen mehreren Sendern und einem Empfänger eingerichtet wird und/oder von mehreren Sender über eine Stream Daten an einen Empfänger gesendet werden.

[0048] Ein weiterer Gegenstand der vorliegenden Erfindung ist ein Steuerungsverfahren für einen industriellen technischen Prozess oder ein Fahrzeug, bei dem zwischen wenigstens zwei Komponenten eines Steuerungssystems, insbesondere einem oder mehreren Sensoren einer industriellen Automatisierungsanlage oder eines Fahrzeuges als Sender und einem, bevorzugt genau einem Controller, insbesondere einer SPS einer industriellen Automatisierungsanlage oder eines Fahrzeuges als Empfänger, Daten unter Durchführung eines erfindungsgemäßen Verfahrens zur Daten-Kommunikation ausgetauscht werden und auf Basis der ausgetauschten Daten eine Steuerung des industriellen technischen Prozesses oder Fahrzeugs erfolgt.

[0049] Ein weiterer Gegenstand der vorliegenden Erfindung ist eine Vorrichtung umfassend

• wenigstens ein, bevorzugt mehrere Knotenpunkte, insbesondere Bridges, und/oder
• wenigstens ein, bevorzugt mehrere jeweils einen Sender bildende Endgeräte, insbesondere Sensoren, und/oder
• ein einen Empfänger bildendes Gerät, insbesondere einen Controller einer industriellen Automatisierungsanlage oder eines Fahrzeuges,

wobei die Vorrichtung zur Durchführung des erfindungsgemäßen Verfahrens zur Daten-Kommunikation bzw. des erfindungsgemäßen Steuerungsverfahrens ausgebildet und eingerichtet ist.

[0050] Die erfindungsgemäße Vorrichtung kann beispielsweise Teil eines Steuerungssystems für einen industriellen technischen Prozess darstellen, welches dann einen weiteren Gegenstand der vorliegenden Erfindung bildet.

[0051] Weiterhin betrifft die Erfindung ein Computerprogramm, das Programmcodemittel zur Durchführung der Schritte des erfindungsgemäßen Verfahrens zur Daten-Kommunikation bzw. des erfindungsgemäßen Steuerungsverfahrens umfasst, sowie ein computerlesbares Medium, das Instruktionen umfasst, die, wenn sie auf wenigstens einem Computer ausgeführt werden, den wenigstens einen Computer veranlassen, die Schritte des erfindungsgemäßen Verfahrens zur Daten-Kommunikation bzw. des erfindungsgemäßen Steuerungsverfahrens durchzuführen. Es sei angemerkt, dass unter einem computerlesbaren Medium nicht nur ein körperliches Medium zu verstehen sein soll, sondern ein solches beispielswiese auch in Form eines Datenstromes und/oder eines Signals, welches einen Datenstrom repräsentiert, vorliegen kann.

[0052] Weitere Merkmale und Vorteile der vorliegenden Erfindung werden anhand der nachfolgenden Beschreibung einer Ausführungsform des Verfahrens der vorliegenden Erfindung unter Bezugnahme auf die beiliegende Zeichnung deutlich. Darin ist

FIG 1

eine schematische Teildarstellung eines industriellen Netzwerkes zur Veranschaulichung des Falles, dass ein Sender über einen Stream an mehrere Empfänger Daten übermittelt;

FIG 2

eine schematische Teildarstellung eines industriellen Netzwerkes zur Veranschaulichung des Falles, dass ein Empfänger über einen Stream Daten von mehreren Sendern empfängt;

FIG 3

eine rein schematische Darstellung einer Bridge, an welcher zwei Listener-Stati zusammengeführt werden (merge);

FIG 4

eine rein schematische Darstellung einer Bridge, an welcher zwei Talker-Stati zusammengeführt werden (merge);

FIG 5

eine Übersicht mit gegenüber dem Stand der Technik neuen Datenobjekten; und

FIG 6

eine schematische Darstellung zur Veranschaulichung des akkumulierten und des Multiplex-Streams-Typs.

[0053] Die FIG 1 zeigt eine rein schematische Teildarstellung eines industriellen Ethernet-basierten Netzwerkes. Konkret ist ein Endgerät zu erkennen, welches einen Sender/Talker 1 darstellt, und das über mehrere Bridges 2, von denen in der FIG 1 nur vier Stück dargestellt sind, mit einer Mehrzahl von weiteren Endgeräten verbunden ist, die jeweils einen Empfänger/Listener 3 darstellen. Von den Empfängern 3 sind in der FIG 1 drei zu erkennen. Die drei Punkte rechts in der FIG sollen verdeutlichen, dass hinter der Bridge 2 oben rechts weitere Bridges 2 und Endgeräte folgen (können).

[0054] Wie man der FIG 1 entnehmen kann, zeichnet sich das Ethernet-basierte Netzwerk mit der Vielzahl von Bridges 2 bei dem dargestellten Ausführungsbeispiel durch eine Linientopologie aus. Selbstverständlich kann auch eine andere aus dem Stand der Technik bekannte Netzwerktopologie, z.B. eine Baum-, Stern- oder Ring-Topologie, vorgesehen sein.

[0055] Bei dem den Sender 1 bildenden Endgerät handelt es sich vorliegend um eine SPS einer industriellen Automatisierungsanlage und die die Empfänger 3 bildenden Endgeräte sind Aktoren der Automatisierungsanlage, welche von der der SPS zyklisch Steuersignale benötigen, um auf einen in den Figuren nicht dargestellten industriellen technischen Prozess zyklisch einzuwirken.

[0056] Die Steuersignale werden über das Ethernet-basierte Netzwerk von der SPS 1 an die Aktoren 3 übertragen. Die Kommunikation der Steuersignale von der SPS 1 an die Aktoren 3 erfolgt dabei in Form von Frames, die via Stream im Netzwerk übertragen werden. Diese Art der Datenkommunikation, die etwa von dem AVB- sowie TSN-Standard bekannt ist, stellt insbesondere sicher, dass eine vorgegebene Latenzzeit, die von Stream zu Stream variieren kann, und insbesondere von der jeweiligen Anwendung abhängt, eingehalten wird. Somit wird sichergestellt, dass die Steuersignale binnen einer vorbestimmten maximalen Latenzzeit bei den Aktoren 3 eintreffen, also zwischen dem Einspeisen der Daten in das Netzwerk seitens der SPS 1 bis zum Eingang der Daten bei den Aktoren 3 eine maximale Latenzzeit vergeht. So kann etwa eine insbesondere echtzeit-kritische Kommunikation zwischen der SPS 1 und den Aktoren 3 sichergestellt werden.

[0057] Dabei gilt, dass ein Stream, wie er beispielsweise von der Audio/Video-Bridging (AVB) Taskgroup und insbesondere von der Time Sensitiv Networking (TSN) Taskgroup in der internationalen Norm IEE802.1 festgelegt ist, unter Rückgriff auf das zugehörige Stream-Reservierungsprotokoll (Stream Reservation Protocol - SRP) eingerichtet wird, wobei jedoch ausschließlich ein Stream zwischen einem Sender und einem Empfänger der auch ein Stream zwischen einem Sender und mehreren Empfängern erhalten werden kann. Letztere Konfiguration entspricht erkennbar derjenigen aus FIG 1.

[0058] Für die Einrichtung eines Streams zwischen der SPS 1 und den Aktoren 3 gemäß bekannten Standards erfolgt eine Reservierung mit SRP an jeder der Bridges 2, die auf dem Netzwerkpfad zwischen der SPS 1 und dem jeweiligen Aktor 3 liegen, also über welche diese verbunden sind. Dabei wird der Stream in einem ersten Schritt von der SPS 1, welche die auch als Talker bezeichnet Datenquelle darstellt, mit einem Talker Advertise angekündigt und es werden die Eigenschaften des Streams von der den Talker bildenden SPS 1 beschrieben. Von der SPS 1 werden insbesondere eine Stream-ID, eine Weiterleite-Adresse und eine Bandbreiteninformation für den von ihr abgehenden Datentransfer angegeben.

[0059] Die Ankündigung des Streams wird an alle Knotenpunkte, vorliegend also Bridges 2 im Netzwerk verteilt, wobei dann jede Bridge 2 die Information des Empfangsports, also des Ports in Richtung des Talkers 1, über den die Ankündigung eingegangen ist, und später auch die Daten eingehen werden, führt. Da gemäß dem Stand der Technik die Datenquelle auch als Talker 1 bezeichnet wird, trägt dieser Port auch die Bezeichnung Talker-Port. Die Ports in Richtung des/der Listener werden entsprechend auch als Sende- bzw. Listener-Ports bezeichnet.

[0060] An dem von der SPS 1 angebotenen Stream melden sich einer oder mehrere Listener, vorliegend die Aktoren 3 an.

[0061] An denjenigen Bridges 2, die zwischen dem Talker 1 und dem jeweiligen Listener 3 liegen wird jeweils eine Reservierung an dem Port in Richtung des Listeners, also dem Listener-Port gemäß der von dem den Talker darstellenden SPS 1 angegebenen Streambeschreibung durchgeführt, sofern die verfügbaren Ressourcen an der jeweiligen Bridge 2 ausreichen. Jeder Knotenpunkt 2 prüft, ob seine internen Ressourcen für im Rahmen des einzurichtenden Streams geforderte Performance (insbesondere bezüglich Datenmenge und Datendurchsatz) ausreichen. Ist dies der Fall, reserviert der Knotenpunkt 2 diese Ressourcen für den einzurichtenden Stream und gibt einen positiven Reservierungsstatus an die nachfolgende Bridge 2 weiter, bzw. die letzte Bridge an den Sender 1.

[0062] Über die Reservierung kann jeder Knotenpunkt 2 sicherstellen, dass er beim anschließenden Datentransfer die erforderliche Performance gewährleistet. Hierin unterscheiden sich Streams von ungeschützten Verbindungen.

[0063] Sind keine ausreichenden Ressourcen verfügbar, wird ein negativer Reservierungsstatus weitergegeben.

[0064] Die Reservierung startet dabei an der dem jeweiligen Empfänger/Listener, also Aktor 3 nächstliegenden Bridge 2 und "propagiert" entlang des jeweiligen Netzwerkpfades zur Datenquelle/zum Talker, also der SPS 1. Die Reservierung von Ressourcen in den Bridges 2 erfolgt somit in entgegengesetzter Richtung zu der Weiterleitung der Steuersignale von der SPS 1 zu den Aktoren 3, die über den Stream erfolgen wird, wenn die Reservierung an den Bridges 2 erfolgreich war. Die Richtung der späteren Datenübertragung ist in der FIG 1 mit Pfeilen 4 und darüber liegenden, die weitergeleiteten Frames rein schematisch repräsentierenden, mit 5 bezeichnete Blockbildelementen skizziert.

[0065] Die Reservierung basiert dabei auf dem auch als Talker-Tree bezeichneten Weiterleite-Baum, der mit dem Rapid Spanning Tree Protocol (RSTP) aufgebaut werden kann.

[0066] An denjenigen Bridges 2, welche Abzweigungen bilden, also die Daten über zwei Listener-seitige Ports weiterleiten müssen, findet ein "merge" der ankommenden Listener-Reservierungsstati statt. Dies wird über die "Status merge" Funktion des verwendeten Reservierungsprotokolls realisiert.

[0067] Die FIG 3 zeigt eine rein schematische Darstellung einer Bridge 2, von deren Ports zwei Listener-seitige Ports 6 und ein Talker-seitiger Port 7 zu erkennen sind.

[0068] Die rein schematisch durch ein Blockbildelement dargestellte "Listener status merge"-Funktion in Richtung des Talkers 1 ist mit 8 bezeichnet. Mit 9 bezeichnete Pfeile repräsentieren weiterhin die über die Listener-seitigen Ports 6 ankommenden und über den Talker-seitigen Port 7 ausgehenden, zusammengeführten (merged) Listener-Reservierungsstatus. Bei nur erfolgreichen Reservierungen (Listener Ready) die an den Listener-seitigen Ports 6 ankommen, wird eine erfolgreiche Reservierung (Listener Ready) an Port 7 weitergeben. Bei mindestens einer erfolgreichen Reservierung (Listener Ready) und mindestens einer fehlerhaften Reservierung (Listener Asking Failed - z.B. wegen ungenügenden Ressourcen an einer hinter Port 6 befindlichen Bridge) wird ein Listener Ready Failed als merged Status weitergegeben. Bei nur fehlerhaften Reservierungen (Listener Asking Failed) wird ein fehlerhafter Status (Listener Asking Failed) weitergegeben.

[0069] Weiterhin in der FIG 3 rein schematisch angedeutet ist die Richtung der Frame-Weiterleitung, also des Datenflusses, dies mit Pfeilen 10. Damit die von der SPS 1 bereitgestellten Frames 5 über beide Listener-seitigen Ports 6, 7 der dargestellten Bridge 2 weitergeleitet werden können, findet eine Duplikation der Frames 5 (Multicast) statt.

[0070] Für eine echtzeit-kritische Übertragung von Steuersignalen von der SPS 1 an mehrere Aktoren 3 hat sich die vorbeschriebene Weise bewährt. Mit nur einem Stream mit einer Stream-ID kann eine Mehrzahl von Listenern mit Daten versorgt werden, wodurch ein vertretbarer Netzwerkaufwand gewährleistet ist.

[0071] Neben der in FIG 1 gezeigten Situation, gemäß der Steuersignale von einem Endgerät an mehrere weitere Netzwerkteilnehmer zu verteilen sind, findet sich - insbesondere in industriellen Anwendungen - jedoch auch der umgekehrte Fall, nämlich dass von zwei oder mehr Quellen Daten an ein (gemeinsames) Ziel zu übermitteln sind. Dies ist beispielsweise der Fall, wenn in einer Automatisierungsanlage von einer Mehrzahl von Sensoren erfasste Istwerte an eine zentrale Steuerung, die wiederum durch eine SPS 1 gegeben sein kann, echtzeit-kritisch zu übermitteln sind.

[0072] Diese Situation ist in FIG 2 dargestellt, die erneut eine rein schematische Teildarstellung eines industriellen Ethernet-basierten Netzwerkes zeigt, wobei wiederum ein Endgerät durch die SPS 1 gegeben ist, die nunmehr jedoch den Empfänger/Listener darstellt, und eine Mehrzahl von Sendern/Talkern vorhanden sind, konkret mehrere Sensoren 11, von denen in FIG 2 insgesamt drei zu erkennen sind. Das industrielle Netzwerk mit den Bridges 2 und Endgeräten aus FIG 2 ist Bestandteil eines Ausführungsbeispiels einer erfindungsgemäßen Vorrichtung zur Durchführung des erfindungsgemäßen Verfahrens.

[0073] Es sei angemerkt, dass die Netzwerktopologie in den FIG 1 und 2 übereinstimmend dargestellt ist, da vorliegend die in FIG 1 erkennbaren Aktoren 3 und die in die FIG 2 erkennbaren Sensoren 11 jeweils in einem Endgerät enthalten sind, dies aber natürlich keineswegs der Fall sein muss.

[0074] Die SPS 1 und die Sensoren 11 sind entsprechend über eine Mehrzahl von Bridges 2 in - der rein optionalen - Linientopologie miteinander verbunden.

[0075] Nach dem Stand der Technik müsste für die Übertragung von mit den Sensoren 11 erfassten Istwerten an die SPS 1 für jeden Sensor 11 ein eigener Stream eingerichtet werden. Für die in der FIG 2 erkennbaren drei Sensoren 11 wären entsprechend drei separate Streams erforderlich, womit ein gegenüber der Situation gemäß FIG 1 deutlich erhöhter Netzwerk-Verwaltungs- und- Verarbeitungsaufwand verbunden wäre.

[0076] Die vorliegende Erfindung schlägt vor, zur Reduzierung der Anzahl von Streams in demjenigen Falle, dass Daten von mehreren Quellen/Sendern an genau ein Ziel/Empfänger gesendet werden sollen, eine neue Art der Reservierung durchzuführen, die eine "Multiple Talker per Listener" Konfiguration ermöglicht, so dass die drei Sender 11 über nur einen Stream mit einer Stream-ID Daten an die SPS 1 übermitteln können.

[0077] Konkret wird hierzu in einem ersten Schritt des hier beschriebenen Ausführungsbeispiels des erfindungsgemäßen Verfahrens von dem Empfänger, also der SPS 1, eine Listener Advertise Nachricht für den Stream herausgegeben, die eine Streambeschreibung umfasst, und die Listener Advertise Nachricht wird über die Bridges 2 im Netzwerk verteilt und an die Sensoren 11 übertragen. Mit der Listener Advertise Nachricht kündigt die SPS 1 im Netzwerk an, dass sie über einen Stream Daten empfangen möchte. Es sei angemerkt, dass die Information darüber, dass die Sensoren 11 Istwerte für die SPS 1 bereitstellen können, auf anderem Wege bereitgestellt wurde. Dies ist in FIG 1 nach dem Stand der Technik ebenfalls notwendig und kann z.B. im industriellen Umfeld während der Programmierung der SPS 1 und der IO Module erfolgen.

[0078] Nachdem die SPS 1 den Listener Advertise herausgegeben hat und dieser verteilt wurde, wird von jedem Sensor 11, von dem erfasste Istwerte an die SPS 1 übertragen werden sollen, eine Talker Join Nachricht herausgegeben. Bei dem dargestellten Ausführungsbeispiel senden alle drei Sensoren 11 eine Talker Join Nachricht. Für jeden der drei Sensoren 11 wird dann eine Talker Join Reservierung an den Bridges 2 auf dem Netzwerkpfad zwischen dem jeweiligen Sensor 11 und der SPS 1 durchgeführt. Die Talker Join Nachricht umfasst u.a. eine Stream ID und einen Reservierungsstatus.

[0079] Die Reservierung von Ressourcen in den Bridges 2 erfolgt dabei in Abweichung vom Stand der Technik ausgehend von dem jeweiligen Talker, also jeweiligen Sensor 11, in Richtung des einen Listeners 1, also in der gleichen Richtung wie die Weiterleitung der Istwerte von den Sensoren 11 an die SPS 1, die über den Stream erfolgen wird, wenn die Reservierung an den Bridges 2 erfolgreich war. Die Richtung der späteren Datenübertragung ist in der FIG 2 - in Analogie zu FIG 1 - mit Pfeilen 12 und darüber liegenden, die weitergeleiteten Frames rein schematisch repräsentierenden, mit 13, 14, 15, 16 bezeichneten Blockbildelementen skizziert.

[0080] An denjenigen Bridges 2, welche Abzweigungen bilden, also an denen Daten über zwei Talker-seitige Ports ankommen werden, findet ein "merge" der ankommenden Talker-Reservierungs-Stati statt. Dies wird - in Analogie zu der im Zusammenhang mit FIG 1 beschriebenen Vorgehensweise - über die "Status merge" Funktion des verwendeten Reservierungsprotokolls realisiert. Dabei kommt ein Reservierungsprotokoll zum Einsatz, welches um die neuen Datenobjekte Listener-Advertise und Talker-Join erweitert ist, und welches auf die für die Empfänger/Listener vorbekannte Listener-Status-Merge-Funktion bekannter Protokolle zurückgreift, da die eigentliche Reservierung von Ressourcen an dem bzw. den Knotenpunkten prinzipiell gleich bzw. analog zu der vorbekannten Vorgehensweise mit einem Sender/Talker und mehreren Empfängern/Listenern ablaufen kann.

[0081] Abweichend vom Stand der Technik werden die Talker-Stati dabei in Richtung, des Listener-Trees zu dem genau einen Empfänger, also der SPS 1, zusammengeführt (merged).

[0082] Auch der Listener-Tree, der sich aus dem weiteren neuen Listener Advertise Datenobjekt des verwendeten, erweiterten Reservierungsprotokolls bildet, wird vorliegend mit dem Rapid Spanning Tree Protocol bestimmt. Der Tree entsteht dabei aus dem gespeicherten Port des Listener Advertise.

[0083] Eine Übersicht der neuen Datenobjekte Listener Advertise L_Advertise, Talker Join T_Join und dem aus dem Advertise resultierenden Listener Tree L_Tree kann der rechten Seite der FIG 5 entnommen werden, jeweils in Gegenüberstellung mit den korrespondierenden Datenobjekten vom vorbekannten Standard, also dem Talker Advertise T_Advertise, Listener Join L_Join und Talker Tree T_Tree, die in der linken Hälfte der FIG 5 gezeigt sind. Mit der Mengenklammer sind die beiden oberen, neuen Datenobjekte markiert.

[0084] In der FIG 4 ist der "merge" der Talker-Stati rein schematisch - und in zu FIG 3 korrespondierender Weise der "merge" der Listener-Stati - dargestellt. Man sieht auch hier eine Bridge 2, von der zwei Talker-seitige Ports 17 und ein Listener-seitiger Port 18 gezeigt sind. Weiterhin rein schematisch durch ein Blockbildelement dargestellt ist die "Talker status merge"-Funktion in Richtung des Listeners, also der SPS 1, die in der FIG mit 19 bezeichnet ist.

[0085] Wie auch aus der FIG 4 hervorgeht, erfolgt die Weiterleitung der Talker-Reservierungsstati und der Daten bei der erfindungsgemäßen Vorgehensweise in die gleiche Richtung, beides in Richtung des einen Empfängers, also der SPS 1.

[0086] Weiterhin in der FIG 4 rein schematisch angedeutet ist die Richtung der Frame-Weiterleitung, also des Datenflusses, dies mit Pfeilen 20 sowie die über die Talker-seitigen Ports 17 eingehenden und der über den Listener-seitigen Port 18 ausgehende, zusammengefasste (merged) Talker-Reservierungsstatus, jeweils mit Pfeilen 21. Über den dem Listener, also der SPS 1 am nächsten liegenden Bridge 2 werden alle Reservierungsstati sämtlicher Talker, also Sensoren 11, welche dem der SPS 1 mit dem Listener Advertise angekündigten Stream beigetreten sind (join) an die SPS 1, welche die logische Wurzel (root) des Baumes bildet, weitergeleitet. Der bei der SPS 1 ankommende zusammengefasste (merge) Reservierungsstatus umfasst dabei entweder die Information, dass eine Reservierung der senderseitigen Ports 17 aller Bridges 2 auf den die Sensoren 11 und die SPS 1 verbindenden Netzwerkpfaden erfolgreich war, oder dass eine Reservierung der senderseitigen Ports 17 aller Bridges 2 auf den die Sensoren 11 und die SPS 1 verbindenden Netzwerkpfaden nicht erfolgreich war, oder dass eine Reservierung wenigstens eines senderseitigen Ports 17 wenigstens einer Bridge 2 auf den die Sensoren 11 und die SPS 1 verbindenden Netzwerkpfaden nicht erfolgreich war und wenigstens eine Reservierung eines senderseitigen Ports 17 erfolgreich war.

[0087] Ist die Talker-Reservierung für alle betroffenen Knotenpunkte, also allen Bridges 2 auf dem Listener-Tree erfolgreich, kann der eigentliche Datentransfer beginnen, also die Weiterleitung der Frames 13, 14, 15, 16 mit von den Sensoren 11 erfassten Istwerten.

[0088] Die Weiterleitung der von verschiedenen Sensoren 11 über die beiden Talker-seitigen Ports 17 an der Bridge 2 ankommenden Frames 13, 14, 15, 16 über den einen Listener-seitigen Port 6, 7 kann auf unterschiedliche Weise erfolgen, beispielsweise gemäß dem akkumulierten Stream-Typ oder dem Multiplexed-Stream-Typ. Bei ersterem Typ können alle Sensoren 11 in einer Periode einen Frame 13 ,14,15, 16 senden, wobei dann die Summe aller Frames 13, 14, 15, 16 reserviert werden muss, also eine größere Bandbreite erforderlich ist. Bei dem Multiplexed Stream Typ ist die Koordination derart, dass in jeder Periode nur einer der Sensoren 11 einen Frames sendet, was mit einer geringeren Bandbreitenanforderung jedoch einer höheren Wartezeit verbunden ist, da es länger dauert, bis alle Sensoren 11 nacheinander ihre Daten gesendet haben. Der Stream-Typ ist Teil der Stream-Beschreibung, die die SPS 1 zusammen mit dem Listener-Advertise herausgeben hat.

[0089] Die FIG 6 zeigt rein schematisch das Prinzip des akkumulierten und des Multiplexed-Stream-Typs in Gegenüberstellung.

[0090] Konkret ist auf der linken Seite der FIG 6 beispielhaft für Perioden #1 bis #4 und Frames 13, 14, 15 gezeigt, dass beim akkumulierten Stream-Typ die drei Frames 13, 14, 15 in jeder Periode übertragen werden, was mit einer höheren Bandbreite 22 einhergeht, und gemäß dem Multiplexed-Stream-Typ in jeder Periode jeweils nur eine Frame 13, 14, 15 weitergeleitet wird, wobei die Bandbreite 22 derjenigen des größten Frames 13 entspricht.

[0091] Auf Basis erhaltener Istwerte kann die SPS 1 insbesondere in an sich hinlänglich bekannter Weise Steuersignale ermitteln und/oder die Istwerte können zu Auswertungszwecken herangezogen werden. Die SPS 1 wirkt insbesondere u.a. auf Basis der erhaltenen Istwerte auf den industriellen technischen Prozess ein.

[0092] Die vorstehend beschriebene erfindungsgemäße Vorgehensweise bietet eine Vielzahl von erheblichen Vorteilen. Einerseits wird die Anzahl der Echtzeitflüsse, also Streams in einem Netzwerk reduziert. Es ist nicht mehr nötig, dass für jeden Sensor 11, von dem Daten an die SPS 1 zu übermitteln sind, ein separater Stream eingerichtet wird, sondern mehrere Sensoren 11 können Daten über nur einen Stream an einem gemeinsames Ziel senden. Damit geht eine Reduzierung des Control Overheads für die Registrierung und Reservierung der Echtzeit-Streams und eine Reduzierung der Anzahl von Filterdatabase-Einträgen in den Kontenpunkten 2 einher und es wird der gleiche Overhead für beide Richtungen des für die Closed-Loop-Steuerung erforderlichen Datentransfers erzielt. Weiterhin wird die Skalierbarkeit verbessert, da mehr Endgeräte, insbesondere Sensoren/Aktoren 11, 3 unterstützt werden können. Die erfindungsgemäße Vorgehensweise ist weiterhin von der gegebenen Netzwerktopologie unabhängig. So ist sie keineswegs auf die gezeigte Linientopologie beschränkt, sondern kann gleichermaßen auch bei Vorliegen anderer Netzwerktopologien, etwa einer Ring- oder Sterntopologie, zum Einsatz kommen. Weiterhin wir die Kommunikationskonfiguration durch die erfindungsgemäße Vorgehensweise vereinfacht. Auch kann das Engineering von Kontrollanwendungen vereinfacht werden, insbesondere ist eine automatische Kommunikationskonfiguration ohne Engineering möglich und die Kontrollinformation für Feldbusanwendungen kann vereinfacht werden.

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

Ansprüche

1. Verfahren zur Daten-Kommunikation in einem insbesondere industriellen Netzwerk mit einem oder mehreren Knotenpunkten (2), für einen Datentransfer zwischen mehreren Daten bereitstellenden Sendern (11) und einem die von den mehreren Sendern (11) bereitgestellten Daten über einen Stream empfangenden Empfänger (1), bei dem für die Einrichtung des Streams von dem Empfänger (1) eine Listener Advertise Nachricht für den Stream herausgegeben wird, die bevorzugt eine Streambeschreibung umfasst, und die Listener Advertise Nachricht an wenigstens einen Knotenpunkt (2) des Netzwerkes übertragen wird.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Listener Advertise Nachricht im Netzwerk verbreitet, insbesondere an mehrere, bevorzugt alle Knotenpunkte (2) im Netzwerk übertragen wird.

3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Listener Advertise Nachricht an mehrere Sender (11) übertragen wird, wobei die Übertragung an den jeweiligen Sender (11) insbesondere über denjenigen Knotenpunkt (2) oder diejenigen Knotenpunkte (2) erfolgt, der oder die auf dem den jeweiligen Sender (11) und den Empfänger (1) verbindenden Netzwerkpfad liegt oder liegen.

4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass von wenigstens einem Sender (11), welcher über den Stream Daten an den Empfänger (1) übermitteln will, eine Talker Join Nachricht gesendet und für diesen eine Talker Join Reservierung an den Knotenpunkten (2) auf dem Netzwerkpfad zwischen dem Sender (11) und dem Empfänger (1) durchgeführt wird, insbesondere von mehreren Sendern (11), die jeweils über den Stream Daten an den Empfänger (1) übermitteln wollen, jeweils eine Talker Join Nachricht gesendet und eine Talker Join Reservierung an den Knotenpunkten (2) auf dem Netzwerkpfad zwischen dem jeweiligen Sender (11) und dem Empfänger (1) durchgeführt wird.

5. Verfahren nach Anspruch 4,
dadurch gekennzeichnet, dass
die jeweilige Talker Join Nachricht eine Stream-ID und/oder einen Reservierungsstatus umfasst.

6. Verfahren zur Daten-Kommunikation in einem insbesondere industriellen Netzwerk mit einem oder mehreren Knotenpunkten (2), insbesondere nach einem der vorhergehenden Ansprüche, bei dem ein Stream zwischen mehreren Sendern (11) und einem Empfänger (1) eingerichtet wird und/oder von mehreren Sendern (11) über einen Stream Daten an einen Empfänger (1) gesendet werden.

7. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass an wenigstens einem Knotenpunkt (2), insbesondere an mehreren Knotenpunkten (2)ein Reservierungsstatus eines ersten Portes (17) in Richtung eines oder mehrerer Sender (11) und ein Reservierungsstatus eines zweiten Portes (17) in Richtung eines oder mehrerer weiterer Sender (11) zusammengefasst werden, und insbesondere der zusammengefasste Reservierungsstatus über einen Port (21) in Richtung des Empfängers (1) weitergeleitet wird.

8. Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass der dem Empfänger (1) am nächsten liegende Knotenpunkt (2) einen für alle Sender (11) zusammengefassten Reservierungsstatus an den Empfänger (1) weiterleitet, wobei insbesondere der bei dem Empfänger (1) ankommende Reservierungsstatus die Information umfasst, dass eine Reservierung der senderseitigen Ports (17) aller Knotenpunkte (2) auf den die Sender (11) und den Empfänger (1) verbindenden Netzwerkpfaden erfolgreich war, oder dass eine Reservierung der senderseitigen Ports (17) aller Knotenpunkte (2) auf den die Sender (11) und den Empfänger (1) verbindenden Netzwerkpfaden nicht erfolgreich war, oder dass eine Reservierung wenigstens eines senderseitigen Ports (17) wenigstens eines Knotenpunktes (2) auf den die Sender (11) und den Empfänger (1) verbindenden Netzwerkpfaden nicht erfolgreich war und eine Reservierung wenigstens eines senderseitigen Ports (17) wenigstens eines Knotenpunktes (2) auf den die Sender (11) und den Empfänger (1) verbindenden Netzwerkpfaden erfolgreich war.

9. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass dass für die Reservierung von Ressourcen an einem oder mehreren Knotenpunkten wenigstens ein Reservierungsprotokoll verwendet wird, insbesondere ein standardisiertes Reservierungsprotokoll, welches bevorzugt um wenigstens ein Datenobjekt erweitert ist, wobei besonders bevorzugt die Listener Advertise Nachricht und/oder die Talker Join Nachricht und/oder die Talker Join Reservierung das Reservierungsprotokoll erweiternde Datenobjekte darstellen.

10. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass insbesondere unter Verwendung des Rapid Spanning Tree Protocols der Netzwerkbaum bestimmt wird, der durch Netzwerkpfade gebildet wird, die den Empfänger (1) jeweils mit denjenigen Sendern (11) verbinden, die über den Stream Daten an dem Empfänger (1) senden wollen und von denen insbesondere jeweils eine Talker Join Nachricht gesendet wurde .

11. Verfahren nach Anspruch 9 und 10, dadurch gekennzeichnet, dass der bestimmte Netzwerkbaum ein das Reservierungsprotokoll erweiterndes Datenobjekt darstellt.

12. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Listener Advertise Nachricht eine Streambeschreibung umfasst, die eine Angabe des Stream-typs aufweist, wobei bevorzugt als Streamtyp ein akkumulierter Stream oder ein Multiplex-Stream angegeben ist.

13. Steuerungsverfahren für einen industriellen technischen Prozess oder ein Fahrzeug, bei dem zwischen wenigstens zwei Komponenten eines Steuerungssystems, insbesondere einem oder mehreren Sensoren (11) einer industriellen Automatisierungsanlage oder eines Fahrzeuges als Sender und einem, bevorzugt genau einem Controller, insbesondere einer SPS (1) einer industriellen Automatisierungsanlage oder eines Fahrzeuges als Empfänger, Daten unter Durchführung des Verfahrens nach einem der vorhergehenden Ansprüche ausgetauscht werden und auf Basis der ausgetauschten Daten eine Steuerung des industriellen technischen Prozesses oder Fahrzeugs erfolgt.

14. Vorrichtung umfassend

- wenigstens einen, bevorzugt mehrere Knotenpunkte, insbesondere Bridges (2), und/oder

- wenigstens ein, bevorzugt mehrere jeweils einen Sender bildende Endgeräte, insbesondere Sensoren (11), und/oder

- ein einen Empfänger bildendes Gerät, insbesondere einen Controller (1) einer industriellen Automatisierungsanlage oder eines Fahrzeuges,

wobei die Vorrichtung zur Durchführung des Verfahrens nach einem der vorhergehenden Ansprüche ausgebildet und eingerichtet ist.

15. Steuerungssystem für einen industriellen technischen Prozess umfassend eine Vorrichtung nach Anspruch 14.

16. Computerprogramm umfassend Programmcode-Mittel zur Durchführung des Verfahrens nach einem der Ansprüche 1 bis 13.

17. Computerlesbares Medium, das Instruktionen umfasst, die, wenn sie auf wenigstens einem Computer ausgeführt werden, den wenigstens einen Computer veranlassen, die Schritte des Verfahrens nach einem der Ansprüche 1 bis 13 durchzuführen.

Zeichnung