Method for data communication in a particularly industrial network, control method, device, computer program and computer-readable medium
Abstract
This record has no abstract on file.
Term
12.3 yearsto projected expiry
Projected expiry 22 January 2039, counted from filing; an application has no term until it is granted.
- Priority
- Filed
- Published
- Today
- Projected expiry
20 claims: 12 independent, 8 dependent
- 1Claims of equivalent WO 2019149577 A1 Patentansprüche1. Verfahren zur Daten-Kommunikation in einem insbesondere industriellen Netzwerk mit einem oder mehreren Knotenpunkten (2), insbesondere Switches und/oder Bridges, via Stream, bei dem für die Datenübertragung zwischen Streamteilnehmern (1, 3, 31) über einen oder mehrere Knotenpunkte (2) des Netz werks unter Nutzung eines Reservierungsprotokolls Ressourcen an dem oder den Knotenpunkten (2) reserviert und anschließend Daten via Stream übertragen werden,dadurch gekennzeichnet, dassfür eine Übertragung von Daten von einem Sender (1) an mehre re Empfänger (3) von dem Sender (1) ein Datenframe (4) gesen det wird, der mehrere, für verschiedene Empfänger (3) be stimmte Unterdatensätze (11) aufweist, und an wenigstens ei nem Ausgangsport (18, 19) wenigstens eines Knotenpunktes (2) wenigstens ein Unterdatensatz (11) aus dem Datenframe (4) her ausgefiltert wird, und/oder dass für eine Übertragung von Da ten von mehreren Sendern (31) an einen Empfänger (1) der Emp fänger (1) einen Datenframe (4) erhält, der mehrere, von ver schiedenen Sendern stammende Unterdatensätze (11) aufweist.
- 2Verfahren nach Anspruch 1,dadurch gekennzeichnet, dassan zumindest einem Knotenpunkt (2) die Größe eines Datenfra mes (4) verändert wird, so dass die Größe des Datenframes (4) an einem Eingangsport (17, 32, 33) des Knotenpunktes (2) von der Größe des Datenframes (4) an wenigstens einem Ausgangs port (18, 19, 34) des Knotenpunktes (2) verschieden ist.
- 3Verfahren nach Anspruch 1 oder 2,dadurch gekennzeichnet, dassbei der Übertragung von Daten von den mehreren Sendern (31) an den einen Empfänger (1) an wenigstens einem Knotenpunkt (2) Datenframes (4) an zwei oder mehr Eingangsports (32, 33) mit verschiedenen Unterdatensätzen (11) ankommen, und die von zwei oder mehr Eingangsports (32, 33) stammenden Unterdaten sätze (11) insbesondere zusammengefasst werden und ein Daten- frame (4) mit den zusammengefassten Unterdatensätzen (11) be vorzugt über wenigstens einen, insbesondere genau einen Aus gangsport (34) des Knotenpunktes (2) weitergeleitet wird.
- 4Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dassdie Übertragung von Daten von dem einen Sender (1) an die mehreren Empfänger (3) über genau einen Stream erfolgt, und/oder dass die Übertragung von Daten von den mehreren Sen dern (31) an den einen Empfänger (1) über genau einen Stream erfolgt .
- 5Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dassjeder Unterdatensatz (11) Nutzdaten (14) und eine Unterdaten- satz-ID (12) und/oder eine Angabe (13) zu der Länge des Un terdatensatzes (11) umfasst.
- 6Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass Datenframes (4) für die Datenübertragung von dem einen Sender (1) an die mehreren Empfänger (3) einen Header (5) mit einer designierten Adresse (6) umfassen, und/oder dass Datenframes(4) für die Datenübertragung von den mehreren Sendern (31) an den einen Empfänger (1) einen Header (5) mit einer designier ten Adresse (6) umfassen.
- 7Verfahren nach Anspruch 6,dadurch gekennzeichnet, dassdie Übertragung von Daten von dem einen Sender (1) an die mehreren Empfänger (3) über Datenframes (4) erfolgt, welche die gleiche designierte Adresse (6) und insbesondere die gleiche Priorität und/oder VLAN ID und/oder den gleichen Ethertype in ihren Headern (5) , bevorzugt identische Header(5) aufweisen, und/oder dass die Übertragung von Daten von den mehreren Sendern (31) an den einen Empfänger (1) über Da tenframes (4) erfolgt, welche die gleiche designierte Adresse(6) und insbesondere die gleiche Priorität und/oder VLAN ID und/oder den gleichen Ethertype in ihren Headern (5), bevor zugt identische Header (5) aufweisen.
- 8Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dassfür die Reservierung von Ressourcen an einem oder mehreren Knotenpunkten (2) wenigstens ein Reservierungsprotokoll ver wendet wird, insbesondere ein standardisiertes Reservierungs protokoll, welches bevorzugt um wenigstens ein Datenobjekt erweitert ist.
- 9Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dassfür die Datenübertragung von dem einen Sender (1) an die meh reren Empfänger (3) wenigstens eine Talker Unterdatensatz Advertise Nachricht im Netzwerk verbreitet, insbesondere an mehrere, bevorzugt alle Knotenpunkte (2) im Netzwerk übertra gen wird, und/oder für die Datenübertragung von den mehreren Sendern (31) an den einen Empfänger (1) eine Listener Unter datensatz Advertise Nachricht im Netzwerk verbreitet, insbe sondere an mehrere, bevorzugt alle Knotenpunkte (2) im Netz werk übertragen wird.
- 10Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dassfür die Datenübertragung von dem einen Sender (1) an die meh reren Empfänger (3) von einem oder mehreren Empfängern (3) , welche über den Stream wenigstens einen Unterdatensatz (11) von dem einen Sender (1) erhalten wollen, eine Listener Un terdatensatz Join Nachricht gesendet und für diese eineListener Unterdatensatz Join Reservierung an dem oder den Knotenpunkten (2) auf dem Netzwerkpfad zwischen dem Sender (1) und dem jeweiligen Empfänger (3) durchgeführt wird, und/oder für die Datenübertragung von den mehreren Sendern (31) an den einen Empfänger (1) von einem oder mehreren Sen dern (31), die jeweils über den Stream wenigstens einen Un terdatensatz (11) an den einen Empfänger (1) übermitteln wol len, jeweils eine Talker Unterdatensatz Join Nachricht gesen- det und eine Talker Unterdatensatz Join Reservierung an dem oder den Knotenpunkten (2) auf dem Netzwerkpfad zwischen dem jeweiligen Sender (31) und dem Empfänger (1) durchgeführt wird .
- 11Verfahren nach Anspruch 10,dadurch gekennzeichnet, dassdie jeweilige Listener Unterdatensatz Join Nachricht, eine Stream-ID und/oder eine Unterdatensatz-ID und/oder einen Re servierungsstatus umfasst, und/oder dass die jeweilige Talker Unterdatensatz Join Nachricht eine Stream-ID und/oder eine Unterdatensatz-ID und/oder einen Reservierungsstatus umfasst.
- 12Verfahren nach Anspruch 8 und einem der Ansprüche 9 bis11,dadurch gekennzeichnet, dassdie Listener Unterdatensatz Advertise Nachricht und/oder die Talker Unterdatensatz Join Nachricht und/oder die Talker Un terdatensatz Join Reservierung das Reservierungsprotokoll er weiternde Datenobjekte darstellen.
- 13Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dassfür die Datenübertragung von den mehreren Sendern (31) an den einen Empfänger (1) an wenigstens einem Knotenpunkt (2), ins besondere an mehreren Knotenpunkten (2), ein Reservierungs status eines ersten Portes (32) in Richtung eines oder mehre rer Sender (31) und ein Reservierungsstatus eines zweiten Portes (33) in Richtung eines oder mehrerer weiterer Sender (31) zusammengefasst werden, und insbesondere der zusammenge fasste Reservierungsstatus über einen Port (34) in Richtung des Empfängers (1) weitergeleitet wird.
- 14Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dassfür die Datenübertragung von dem einen Sender (1) an die meh reren Empfänger (31) insbesondere unter Verwendung des Rapid Spanning Tree Protocols der Netzwerkbaum bestimmt wird, der durch Netzwerkpfade gebildet wird, über die der eine Sender (1) mit den Empfängern (3) verbunden ist, und/oder für die Datenübertragung von den mehreren Sendern (31) an den einen Empfänger (1) insbesondere unter Verwendung des RapidSpanning Tree Protocols der Netzwerkbaum bestimmt wird, der durch Netzwerkpfade gebildet wird, über die die mehreren Sen der (31) mit dem einen Empfänger (1) verbunden sind.
- 15Verfahren nach Anspruch 8 und 14,dadurch gekennzeichnet, dassder wenigstens eine bestimmte Netzwerkbaum ein das wenigstens eine Reservierungsprotokoll erweiterndes Datenobjekt dar stellt .
- 16Steuerungsverfahren für einen industriellen technischen Prozess oder ein Fahrzeug, bei dem zwischen wenigstens zwei Komponenten eines Steuerungssystems, insbesondere einem oder mehreren Sensoren (31) einer industriellen Automatisierungs anlage oder eines Fahrzeuges als Sender und einem, bevorzugt genau einem Controller, insbesondere einer SPS (1) einer in dustriellen Automatisierungsanlage oder eines Fahrzeuges als Empfänger, Daten unter Durchführung des Verfahrens nach einem der vorhergehenden Ansprüche ausgetauscht werden und auf Ba sis der ausgetauschten Daten eine Steuerung des industriellen technischen Prozesses oder Fahrzeugs erfolgt.
- 17Vorrichtung umfassend - wenigstens einen, bevorzugt mehrere Knotenpunkte (2 ) , ins besondere Bridges und/oder Switche,und - mehrere, jeweils einen Sender bildende Endgeräte, insbe sondere Sensoren (31) , und - ein einen Empfänger bildendes Gerät, insbesondere einen Controller (1) einer industriellen Automatisierungsanlage oder eines Fahrzeuges,und/oder - mehrere, jeweils einen Empfänger bildende Endgeräte, ins besondere Aktoren (3) , und - ein einen Sender bildendes Gerät, insbesondere einen Con troller (1) 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.
- 18Steuerungssystem für einen industriellen technischen Pro zess umfassend eine Vorrichtung nach Anspruch 17.
- 19Computerprogramm umfassend Programmcode-Mittel zur Durch führung des Verfahrens nach einem der Ansprüche 1 bis 16.
- 20Computerlesbares Medium, das Instruktionen umfasst, die, wenn sie auf wenigstens einem Computer ausgeführt werden, den wenigstens einen Computer veranlassen, die Schritte des Ver fahrens nach einem der Ansprüche 1 bis 16 durchzuführen.
Independent claims20
150 paragraphs, as filed
Translation of description of equivalent WO 2019149577 A1
0001description
0002Method for data communication in a particular industrial network, control method, device, computer program and computer-readable medium
0003The invention relates to a method for data communication in a particular industrial network with one or more nodes, in particular switches and / or bridges, via stream, in which for the data transmission between stream participants via one or more nodes of the network using a reservation protocol Reserved resources at the node (s) and then transferring data via stream. Moreover, the invention relates to a control method, a Vorrich device, a computer program and a computer-readable medium.
0004Distributed industrial control applications require a guaranteed quality of service (QoS) or quality of service in the communication network interconnecting the terminals to allow time-sensitive tasks to be performed alongside non-real-time relevant traffic from the network. The terminal devices may be, for example, programmable logic controllers (PLCs), IO devices or protective devices.
0005Any application in the network with time-sensitive data traffic between terminals can be registered and reserved to obtain guarantees from the network for lossless real-time transfer of data frames and on-time delivery. The network must verify the availability of network resources (for example, address table entries, frame buffers, transmit time slices) and allocate resources, if available, for each real-time data flow, and grant access for real-time traffic. Within the network, the control information about registrations, reservations and forwarding information must be stored for each real-time data flow. The status of each reservation must be maintained. With an increasing number of terminals and their real-time data traffic on the same network, the amount of network control information is growing. The memory and processing power of network nodes, example as bridges or switches, is limited.
0006Another problem is to provide all information from all terminals in a timely manner. In industrial control applications, a single PLC is typically connected to a variety of I / O devices that require real-time data exchange. The "make span" of the sampled I / O device data to be sent from many I / O devices to a PLC must be minimized.
0007The latest data frame of an input sample cycle to be processed by the PLC or an output update cycle received from an output device determines the quality of the control loop.
0008The IEEE802.1 TSN working group defines extensions to the IEEE802.1 / .3 Ethernet standard for a Time Sensitive Network (TSN). Based on the previous work of the Audio-Video-Bridging (AVB) working group, the quality of service for real-time data flows is further improved in terms of guaranteed latency. However, the status for each real-time data flow must still be maintained in the network.
0009"Multiple Listeners per Stream" was introduced in AVB to control the number of real-time data flows (IEEE802 calls this "stream") from one source (talker) to multiple destinations
0010(Listener) to reduce. Transferring data from one source to multiple destinations is the typical use of the AV (audio video) application, specifically for distributing audio data from a single source to multiple speakers. The reservation model of AVB / TSN "Multiple Stream Reservation Protocol" (MSRP) supports multiple listeners. Here, following a source-originating Talker Advertise message for a stream, multiple listener join reservations may be made resulting in a single streaming control information entry. The forwarding from one talker to its listeners goes along a single tree whose root represents the talker, in which case only one single forwarding entry is required for all the stream listeners in the network nodes. A single Ethernet frame is distributed by the one talker across the network to the multiple listeners. The data is packed into a frame and is transmitted to each listener, with each link being used at most once.
0011This model could be used in industrial automation to reduce the number of streams from a talker-representing PLC to multiple listeners representing the IO devices. The data for all "listening", ie receiving, IO devices can be sent from the sending ("talking") using a single stream.
0012PLC are transferred. The number of streams in the network and thus the amount of control information is then significantly reduced compared to the case where a separate stream for the reception of data from the PLC is set up for each IO device.
0013Depending on the amount of data of the individual IO devices, the disadvantage of the simplified control information, however, ei ne excessive use of bandwidth of the network, since individual I / O devices only a part (English: subset) of the information in the via Stream transmitted frames need gen.
0014Since a closed loop also requires a return channel from each I / O device to the PLC, a large number of frames must also be sent to the PLC. Well-formed Ethernet frames require that 64+ octets be sent, even though the I / O device only hosts a few bits of input information. This results in a large number of streams, each with a small frame containing the required information.
0015Packing just a few input / output bytes into a 64+ octet Ethernet data frame causes overhead, and because of this additional transfer delays are caused by a negative impact on the Makespan.
0016Applicant is aware that specialized real-time Ethernet solutions such as EtherCAT and PROFINET IRT exist to pack I / O data from various Makespan reduction devices into a single frame, also referred to as a sum frame. However, these specialized solutions have their limitations. On the one hand, they are application-specific, especially limited to the packed transport of special fieldbus I / O data.
0017EtherCAT builds on a logical ring topology, regardless of the physical network topology. This can result in the simultaneous forwarding of frames in branches, especially in star topologies, is prevented. This leads to increased latency due to serialization.
0018PROFINET IRT supports a total frame. However, the use of this option is limited to the time-scheduled PROFINET IRT in the line and comb topology.
0019Proceeding from this, the object of the present inven tion is to provide a method which allows a Datenkommu nication in a particular industrial network at a reasonable cost without being limited to specific applications, certain topologies and / or other aspects. It is another object of the present invention to provide an apparatus for carrying out such a method.
0020This object is achieved in a method of the type mentioned above in that for a transmission of data from a transmitter to a plurality of receivers from the transmitter, a data frame is sent, which has a plurality of sub-records intended for different recipients, and at least one output port at least a node at least one subset of data from the data frame is filtered out, and / or that for a transmission of data from a plurality of transmitters to a receiver, the receiver holds a data frame he, which has a plurality of subordinate data sets from different transmitters.
0021According to the invention, a combination of a stream reservation, which is preferably described on the "Multiple Listeners by Talker" model and / or in the European patent application with the file number EP 18154319.0, the content of which is hereby incorporated in its entirety, described "Multiple Talkers per Listener "model for the real-time flow reservation, and a sum frame principle, as it is in similar form
0022PROFINET IRT is used.
0023The data originating from in particular exactly one transmitter and intended for different receivers and / or the data originating from several transmitters and destined in particular for exactly one receiver can be transmitted in a data frame over a stream. For this purpose, the invention provides that data frames are transmitted, which comprise sub-sets, which originate from different transmitters and are summarized in particular along the network paths, or are intended for different receivers, and are divided at one or more nodes, in particular on various output ports. The node (s) are preferably TSN-capable node points, in particular TSN-capable switches and / or bridges.
0024Starting from the term "payload" for the payload of a frame, the sub-data sets which the data frame comprises according to the invention can also be referred to as "paylets".
0025In a particularly preferred embodiment, each sub-data record comprises a sub-data record ID and / or an indication of the length of the sub-data record as well as the user data belonging to the sub-data record. The sub-record ID makes it possible to identify from which sender the respective sub-data record originates or for which recipient it is intended. The length specification is used in particular for administrative purposes in order to define the beginning of a following sub-data record in the payload. With a defined fixed length for all sub-data records contained in the payload, the length specification can also be omitted.
0026The introduction of sub-data sets according to the invention makes it possible to combine the information from different sources or for different destinations into one frame, which in particular increases in size along network paths in the direction of the one receiver or along network paths in the direction of the multiple receivers can decrease in size. Accordingly, in particular, it is provided that the size of a data frame is changed on at least one node, so that the size of the data frame at an input port of the node differs from the size of the data frame at at least one output port of the node. This may apply to data frames sent by the one sender to the multiple receivers and / or for data frames,
0027By the use according to the invention of data frames with a plurality of sub-data sets or paylets, the performance of the network is significantly improved by reducing the overhead and the avoidance of padding. The use of bandwidth and / or other resources (in particular the memory in the nodes) is optimized. The number of real-time flows can be reduced. In particular, the number of Filtering Database entries in the node points is reduced. The scalability is significantly improved verbes sert, since in particular more devices such as sensors and / or actuators can be supported in a network. Another significant advantage of the inventive approach is that it is completely independent of a given network topology. The disadvantages of a restriction to a particular topology are thus completely avoided. An automatic communication configuration takes place using an improved real-time flow reservation protocol. The communication function configuration is thereby considerably simplified.
0028For the data transmission from a transmitter to a plurality of receivers, it is preferred that a filtering of at least one sub-data set from a data frame takes place at at least one node point at which the data frame is forwarded via at least two output ports. Thus, the data frame can be sent with different sub-data sets in the direction of different receivers.
0029Furthermore, the filtering of sub-data records at at least one node preferably takes place such that at least one sub-data record which is filtered out at an output port of a node is forwarded to at least one other output port of this node. It can also be provided that the sub-data sets are distributed or divided between two or more output ports from an incoming data frame, in particular such that no sub-data set is forwarded via two output ports of the node. It can be provided that when data is transmitted from the multiple transmitters to the one receiver at at least one node, data frames arrive at two or more input ports with different sub-data sets, and the sub-data sets originating from two or more input ports are in particular combined ("merging") and a data frame with the combined sub-data sets is forwarded via we least one, in particular exactly one output port of this node. Subset data sets originating from different transmitters and directed to a receiver are combined according to this embodiment in at least one, in particular a plurality of nodes located between the receivers and the transmitter, which is realized by a "subset of merge function" in the nodes can be. in particular, exactly one output port of this node is forwarded. Subset data sets originating from different transmitters and directed to a receiver are combined according to this embodiment in at least one, in particular a plurality of nodes located between the receivers and the transmitter, which is realized by a "subset of merge function" in the nodes can be. in particular, exactly one output port of this node is forwarded. Subset data sets originating from different transmitters and directed to a receiver are combined according to this embodiment in at least one, in particular a plurality of nodes located between the receivers and the transmitter, which is realized by a "subset of merge function" in the nodes can be.
0030The functionality for filtering (especially for data transmission from one sender to several receivers)
0031and / or merging, ie merging (in particular for the data transmission from multiple transmitters to a receiver) of sub-data sets, for example, integrated into the existing IEEE802.1 node or Bridging model who, by a function block for a sub-record handling on the egress page is set up. The egress page is to be understood in a manner known per se as that side of a node at which data leaves the node.
0032A further embodiment of the method according to the invention is characterized in that data frames for the data transmission from the one transmitter to the multiple receivers comprise a header with a designated address. Alternatively or additionally, data frames for data transmission from the plurality of transmitters to the one receiver may include a header having a designated address. The header may also have a destination address and possibly further information. The header of a data frame is generally followed by the payload of the packet of the intermediary layer, which is also referred to as "payload." In particular, the payload area of the data frames is subdivided according to the invention into subdata sets originating from different senders or for different receivers The Nutzdatenbe rich or
0033Furthermore, it is preferably provided that the transmission of data from the one transmitter to the multiple receivers via Da tenframes done which the same designated address for the stream and in particular the same priority and / or VLAN ID and / or the same Ethertype in their headers respectively. Particularly preferably, the data frames have identical headers. Alternatively or additionally, it can be provided in an analogous manner that the transmission of data from the meh eral transmitters to the one receiver via data frames he follows, which the same designated address for the stream and in particular the same priority and / or VLAN ID and / or the same Ethertype in their headers. Particularly preferably, they have identical headers.
0034For the transmission of data from the one transmitter to the multiple receivers, a data frame is sent (cyclically) and in particular forwarded to at least one node via two or more output ports, so that behind the at least one node on at least two Netzwerkpfa each one data frame is transmitted , Then, preferably, the header of the two or more data frames on the two or more network paths leading to different receivers is identical, characterized at least by the same designated address and / or VLAN priority and / or the same Ethertype.
0035For the transmission of data from a plurality of transmitters to a receiver, a data frame is sent (cyclically) from each of the several transmitters in the direction of the receiver, in which case it is particularly preferred that the headers of all the data frames leaving the various transmitters, which differ from one another dene line sections (links), the same designier te address and / or VLAN priority and / or include the same Ethertype, the headers are identical in particular. On at least one network path section, the data frame comprises less than the sum of all individual frames, since the paylets from several data frames have been combined together in a payload of at least one data frame.
0036At the end of the data frames, a checksum, such as a frame check sequence (FCS) or a CRC for a cyclic redundancy check can be located in a manner known per se. Furthermore, in the beginning of the frame, possibly even before a destination and / or source address, a preamble may be provided.
0037To obtain a protected connection, in a manner known per se, prior to the actual transmission of the data, resources are reserved in the node (s) which are in each case between the stream subscribers involved in a data exchange, which is possible using a reservation protocol. By using a real-time flow reservation protocol, the full configuration is automatically performed on the network, using the topology that exists. Resources may include, for example, address table entries, frame buffers, transmit time slices, bandwidth, jitter, and / or latency.
0038The transmission of data from one transmitter to the plurality of receivers preferably takes place via exactly one stream, and / or the transmission of data from the plurality of transmitters to the one receiver preferably takes place via exactly one stream. Whether exactly one stream for the one direction and / or exactly one stream for the other direction exists can be identified in particular by the fact that (for each direction) exactly one stream ID is present and several transmitters have data over a stream with the one ID transmit to a receiver and / or multiple receivers receive data via a stream with the one ID from a transmitter.
0039To the real<sub>Z</sub>It is preferable to use an extended reservation protocol, whereby an extended reservation protocol is to be understood in particular to mean that corresponds to a previously known, in particular standardized reservation protocol, that is one or more data objects or attributes is extended.
0040In particular, an automatic configuration of the inventively provided Unterdatensatz- or Paylet mechanism of the tenebene level (English: data plane) can be achieved via an extension of the reservation mechanism.
0041Examples of known, standardized reservation protocols that can be used in the context of the method according to the invention in a particularly expanded form are the Stream Reservation Protocol (SRP) or the Multiple Stream Registration Protocol (MSRP) and / or the Resource Reservation Protocol (RSVP). SRP represents the known change or extension of the IEEE802.1Q standard, which has been separately standardized as IEEE802.1Qat.
0042One or more new attributes or data objects can be introduced into existing, standardized flow reservation protocols without having to change the fundamental principle of real-time flow reservation.
0043While the Multiple Stream Registration Protocol (MSRP) can be used in a preferably extended form for the exchange of data from a sender to several receivers, for the data transmission from several receivers to a sender, in particular the "multiple talker per listener" is used. Model from the aforementioned application EP 18154319.0, again accessed in particular extended form accessed.
0044According to the application with the file number EP 18154319.0, in order to make "Multiple Talker per Listener" possible, with the "Listener Advertise" a new attribute or data object introduced, which can be used in the context of a particular prior art, stan dardisierten reservation model.
0045The "Listener Advertise" data object corresponds, if one wishes to draw a comparison to the standardized protocols, to the "Talker Advertise" for the previously known case of a data transfer from one source / talker forming the source to one or more Recipients forming "receiver / listener" via stream.
0046The difference to multiple listeners via talker is that not an advertiser issues an advertisement, but a receiver who wants to receive data via a stream.
0047With the new reservation, which allows "multiple talkers per listener", the stream-advertisement takes place in particular along a network tree (Trees) whose origin or root (root), which forms a transmitter / talker and which in particular by the The network paths are defined by which data is passed to the multiple receivers / listeners.
0048For a real-time data transfer from multiple transmitters to egg nen receiver comes in the context of the present invention preferably be the "multiple talker per listener" enabling new reservation type in combination with the data transfer via data frames with multiple sub-data sets, which come from various which transmitters / talkers, for use.
0049As an example of such a data transfer, the real-time transmission from the sensor values of a plurality of sensors of an automation system to the PLC (English: PLC) may be mentioned.
0050For the reverse direction, in particular the data transmission of control values determined on the basis of the sensor values from the PLC to a plurality of actuators of the automation system, then, for example, the multiple stream registration protocol (MSRP), in particular in an expanded form, can be used again in combination with the data transmission over a single data frame with several sub-records, which are then intended for different receivers ger.
0051Particularly preferably, both the data transmission from a transmitter to a plurality of receivers, in particular from a PLC to multiple actuators, as well as the data transmission from several ren transmitters to a receiver, in particular of several sensors to one, preferably the same PLC, under imple tion of the invention process.
0052A further embodiment of the method according to the invention is characterized in that, for the data transmission from the one transmitter to the plurality of receivers, at least one talker subset of message messages propagates in the network, in particular to several, preferably all, nodes in the network.
0053The Talker Subset Advertise message particularly represents an attribute or data object which enhances a reservation protocol used for the reservation. In particular, the "Multiple Stream Re serving Protocol" (MSRP) can be used, which is then extended at least to the data object of the "Talker sub record Advertise", preferably even more data objects.
0054Alternatively or additionally, it may be provided that, for the data transmission from the multiple transmitters to the one receiver, a listener subset of messages is transmitted in the network, in particular to several, preferably all, nodes in the network.
0055The Listener Unterdatensatz Advertise message represents FITS preferred an attribute or data object, which extends a reservation protocol used for the reservation. It can, for example, the "multiple talker per listener" enabling reservation model according to the application of the file number EP 18 15 4319 be used which is then extended at least to the data object of the "Listener Un terdatensatz Advertise".
0056Furthermore, it can be provided that, for the data transmission from the one transmitter to the multiple receivers of one or more receivers, which want to receive at least one subset of data from the one transmitter, a listener sub-record Join message is sent and for this a listener sub-record Join Reservation at the node points on the network path between the sender and the respective recipient is performed.
0057Alternatively or additionally, it may be provided that, for the data transmission from the several transmitters to the one receiver, one or more transmitters each transmitting over the stream at least one sub-data set to the one receiver sends a talker sub-record Join message and one Talker Subset Join Reser- vation is performed at the nodes on the network path between the respective sender and the receiver.
0058The Listener Subset Join message allows a listener to log in to obtain one or more sub records from a data frame. The Talker Subset Join message allows a talker to log in to send one or more sub records to a recipient. A further embodiment is characterized in that the respective listener sub-record join message comprises a stream ID and / or a sub-record ID and / or a reservation status. Alternatively or additionally, it may be provided that the respective talker sub-record Join message comprises a stream ID and / or a sub-record ID and / or a reservation status.
0059The talker sub-record Join message and / or the list ner sub-record Join message can - in analogy to the corresponding advertisements - represent attributes or data objects that extend a reservation protocol used.
0060The sub-record data objects receive the data necessary for the identification of the sub-records / pay-lists in the payload. These are in particular the Paylet ID and the Paylet length. Since the paylets form part of the payload of a stream, the stream ID is needed for assignment. So far, in the known data objects (Talker Advertise, Listener Join and in the European patent application with the file number EP 18154319.0 introduced Talker Join and Listener Advertise) the assignment via the Stream ID. The data objects can be used in addition to the familiar talker and listener data objects, or can be used as a complete alternative with the general stream data in the data objects.
0061A further advantageous embodiment of the method according to the invention is characterized in that for the data transmission from the several transmitters to the one receiver at at least one node, in particular at several nodes, a reservation status of a first port towards one or more transmitters and a reservation station in the direction of one or more broadcasters, and in particular the summarized reservation status is forwarded via a port in the direction of the recipient. This corresponds to the procedure which is previously known from the European patent application with the file number EP 18154319.0.
0062In complete analogy, it may be provided that for the data transmission from one transmitter to several receivers to at least one node, in particular at several nodes, a reservation status of a first port in the direction of one or more receivers and a reservation status of a second port in FIG Direction of one or more other receivers are summarized, and in particular the summarized reservation status is forwarded via a port in the direction of the sender. For the data transmission from one transmitter to a plurality of receivers, the reservation statuses according to this embodiment are forwarded in the direction of the transmitter / talker, as is already known from standardized reservation protocols.
0063In a further preferred embodiment of the method according to the invention it is provided that for the data transmission from the one transmitter to a plurality of receivers, in particular using the Rapid Spanning Tree Protocol, the network form is determined, which is formed by the network paths through which the one transmitter connected to the recipients.
0064Alternatively or additionally, it may be provided that for the data transmission from the multiple transmitters to one Emp catcher, in particular using the Rapid Spanning Tree Protocol, the network tree is determined, which is formed by network factory paths through which the multiple transmitters with the one Receivers are connected.
0065The network tree determined for the one and / or other direction then preferably represents an attribute or data object which extends a used reservation protocol. A further subject of the present invention is a control method for an industrial technical process or a vehicle in which between at least two components of a control system, in particular one or more sensors of an industrial automation system or a vehicle as transmitter and one, preferably exactly one controller, in particular a PLC of an industrial automation system or of a vehicle as receiver,
0066The invention further relates to a device comprising
0067at least one, preferably a plurality of nodes, in particular bridges and / or switches,
0068and
0069- Several, each forming a transmitter terminals, in particular special sensors, and
0070a device forming a receiver, in particular a controller of an industrial automation system or of a vehicle,
0071and or
0072- Several, each forming a receiver terminals, in particular actuators, and
0073a device forming a transmitter, in particular a controller of an industrial automation system or of a vehicle,
0074wherein the device is designed and set up for carrying out the method according to the invention for data communication or the control method according to the invention.
0075The device according to the invention may constitute part of a control system for an industrial technical process, which then constitutes a further subject of the present invention. Furthermore, the invention relates to a computer program, the program code means for performing the steps of the inventions to the invention process for data communication and he inventive control method comprises.
0076Finally, the subject matter of the invention is a computer-readable medium comprising instructions which, when executed on at least one computer, cause the at least one computer to perform the steps of the method according to the invention for data communication or the inventive control method.
0077The computer-readable medium may be, for example, a CD-ROM or DVD or a USB or flash memory. It should be noted that under a computer-readable medium is not only a physical medium to be ver, but such example meadow also in the form of a data stream and / or a signal representing a data stream may be present.
0078Other features and advantages of the present invention will become apparent from the following description of an embodiment form of the method of the present invention with reference to the accompanying drawings. That's it
00791 shows a schematic partial representation of an industrial
0080Network to illustrate the case that a transmitter transmits data via a stream to multiple recipients;
00812 shows a purely schematic representation of a data frame with a plurality of sub-data sets;
00823 shows an overview with data objects of the reservation protocols;
00834 shows a purely schematic representation of a bridge at which sub-data sets are distributed from an input port to two output ports (filtering);
00845 shows a purely schematic representation of the simplified
0085IEEE.802.2 bridge model with integrated subset of merging and filtering functions;
00866 shows a schematic partial representation of an industrial
0087Network for illustrating the case that a receiver receives data from several transmitters via a stream; and
00887 shows a purely schematic representation of a bridge at which sub-data sets of two input ports are summarized together (Merging).
00891 shows a purely schematic partial representation of an industrial Ethernet-based network. Specifically, a terminal can be seen, which represents a transmitter / talker 1, and which is connected via a plurality of bridges 2, of which only four are shown in FIG 1, with a plurality of further terminals, each a recipient ger / Listener 3 represent. Of the receivers 3, three can be seen in FIG. The three points on the right in FIG. 1 are intended to clarify that further bridges 2 and terminals follow (can) behind the bridge 2 at the top right.
0090As can be seen from FIG. 1, the Ethernet-based network with the multiplicity of bridges 2 in the illustrated embodiment is distinguished by a tree topology. Of course, another known from the prior art network topology, such as a line, star or ring topology, be provided.
0091In which the transmitter forming terminal is vorlie ing to a PLC 1 of an industrial automation system and the terminals forming the receiver are actuators 3 of the automation system, which cyclically require control signals from the PLC 1 to a not shown in the figures, industrial technical Process cyclically.
0092The control signals are transmitted via the Ethernet-based network from the PLC 1 to the actuators 3. The communication of the control signals from the PLC 1 to the actuators 3 takes place via data frames 4 which are transmitted via the stream in the network and which comprise a plurality of sub-data sets 11 for the plurality of receivers 3.
0093The data frames 4 are indicated in FIG 1 at different positions in the network purely schematically by provided with the reference numeral 4 block pixels. The FIG 2, a purely schematic, enlarged view of a data frame 4 are taken, which shows the structure of the data frames 4 by way of example. Concretely, the frames 4 comprise a header 5 with a designated stream address 6, a destination address 7, a VLAN tag 8 according to IEEE802.1 Q with a priority and the VLAN ID and an ET (Ethertype) 9
0094Ethertype. The header 5 is adjoined by an area 10, in which the payload data is contained in the previously known data frames, and which is subdivided according to the invention into a plurality of sub-data records 11 in the exemplary embodiment described here. In FIG. 2, of the six sub-data sets 11, only two are shown and the others are indicated by. It is understood that a different number of sub-records 11 can be seen easily, depending on the specific application depends.
0095Each sub-data set 11 comprises - as shown by way of example in FIG 2 for only one of the sub-records 11 - a Unterda tensatz ID 12, a length 13 indicating the length of the respective sub-record 11, and the payload 14 of each sub-record 11. About the sub-record ID, it becomes possible to identify for which receiver (s) 3 the respective sub-record 11 is intended. The length specification 13 makes it possible to determine the beginning of the respectively next sub-data record 11.
0096At the end of the data frame 4 is finally - as in previously known data frames - a CRC 15 for a "Cyclic Redundancy Check".
0097The data frame 4 with six sub-data sets 11 is transmitted cyclically from the one transmitter 1 to a plurality of, in the present case, specifically six actuators 3. In FIG 1, the direction of data transfer is indicated by arrows 16.
0098The frame forwarding takes place via a protected connection, a so-called stream. In particular, data communication over a stream known from the AVB and TSN (Time Sensitive Networking) standard (TSN) ensures, in particular, that a given latency, which may vary from stream to stream, and more particularly from the depends on the application. This ensures that the control signals arrive at the actuators 3 within a predetermined maximum latency time, ie, between the feeding of the data into the network, at least the PLC 1 passes a maximum latency period until the data is received by the actuators 3. Thus, for example, a real-time critical communication between the PLC 1 and the actuators 3 can be ensured.
0099In this case, a stream as defined, for example, by the Audio / Video Bridging (AVB) task group and in particular by the TSN task group in the international standard IEE802.1, using a stream reservation protocol (in this case, for example, Stream Reservation Protocol - SRP or the extension MSRP), whereby a stream between a sender and a receiver or even a stream between a sender 1 and a plurality of receivers 3 can be obtained. The latter configuration corresponds to that of FIG. 1, in which case in particular the multiple-stream registration protocol (MSRP) for the resource reservation in a multiple listener per talker configuration can be accessed.
0100For the establishment of a stream between the PLC 1 and the actuators 3 - in complete analogy to the prior art approach - a reservation of resources at each node 2, which forwards the data frame 4, where the MSRP in expanded form is used to allow automatic configuration of the data plane subset or paylet mechanism.
0101The process is such that in a first step of the embodiment described here by the transmitter, so the PLC 1 is a talker sub record Advertise message forth issued. With the Talker subset of Advertise, the SPS 1 announces the stream over which the data frame 4 is transmitted with the multiple sub records 11 in the network, and describes the properties of the stream. In particular, the SPS 1 specifies a stream ID, a forwarding address and bandwidth information for the data transfer that it issues. In this case, for each sub-record 11, the respective ID and the length are announced for each stream.
0102The announcement of the stream is distributed to all nodes, before lying Bridges 2 in the network, in which case each bridge 2 received the information of the receiving port, ie the port in the direction of Talkers 1, on which the announcement received, and later the data be leads. Since the data source is also referred to as Talker 1, this port also carries the name Talker Port. The ports in the direction of the listener (s) are also referred to as sender or listener ports.
0103At the stream offered by the SPS 1, one or more listeners, in the present case the actuators 3, register. For this purpose, a listener sub-record Join message is sent by the respective actuator 3, which includes an indication of which sub-record or possibly which sub-records of the respective respective actuator 3 would like to receive. For this purpose, the subset record ID is contained in the listener sub record Join message together with the login status.
0104At those Bridges 2, which are between the PLC 1 and the respective actuator 3, a reservation at the port in the direction of the actuator 3, that is the listener port ge according to the streaming description of the Talker representing the SPS 1 for each reserved sub records 11 for the actuators located on the Egress port 3, provided that the available resources at the respective bridge 2 are sufficient. Each node 2 checks whether its internal resources are sufficient for the performance required in the context of the stream to be established (in particular with regard to data volume and data throughput). If this is the case, node 2 reserves these resources for the stream to be established for the desired sub-records 11 and forwards a positive reservation status to the subsequent bridge 2, or
0105Each reservation point 2 can ensure that the required performance is guaranteed during the subsequent data transfer. This is where streams differ from unprotected connections.
0106If sufficient resources are not available, a negative reservation status will be passed on.
0107The reservation starts here at the respective receiver / listener, ie actuator 3 nearest bridge 2 and "per paged" along the respective network path to the data source / to the talker, ie the PLC 1.
0108The reservation is based on the also as a talker tree (T<sub>Tree)</sub> designated forwarding tree associated with the Rapid
0109Spanning Tree Protocol (RSTP) can be established. At those bridges 2 which form branches, that is, which must forward the data via two listener-side ports, a "merge" of the incoming listener reservation stati takes place for each sub-data record 11. This is realized via the "Status merge" function of the used reservation protocol.
0110For the reservation, a reservation protocol is used, which is extended by the new data objects Talker Sub record Advertise and Listener Sub record Join.
0111An overview of the new data objects Talker Subdata Set Advertise T-PL<sub>Aclve</sub>rtise ("PL" for the paylet, which is used as synonymous to "subset" as mentioned above) and listener subrecord Join L-PL<sub>j0</sub>in FIG 3 ent taken, in each case in juxtaposition with the korres pondierenden data objects of the known standard, ie the Talker Advertise T.<sub>Aclve</sub>rtise and Listener Join L<sub>j0</sub>in. The lower quantity bracket contains the real-time flow registration reservation and with the upper quantity bracket the sub-data record or
0112Paylet registration reservation per real-time flow (Pay List Registration Reservation per real-time flow) marked.
0113Following a successful reservation, the data frame 4 with the plurality of sub-data sets 11 is cyclically transmitted from the PLC 1 to the actuators 3.
0114It is true that at several nodes 2 via different ne output ports 18, 19 of the respective node 2 ver different sub-records 11 are forwarded, which is achieved via a subset of data filtering at the output ports. At several nodes 2, the size of the data frame 4 is changed, so that the size of the data frame 4 at an input port 17 of the node 2 on the size of the data frame 4 at least one output port 18, 19 of the node 2 is different. Specifically, at the first node seen from the PLC 1 point 2 of the data frame 4 is still passed unchanged via only one output port of the bridge. At the next, from the point of view of the SPS 1 second bridge 2, however, a filtering of sub-data sets 11 takes place. Concretely, the data frame 4 arrives at the transmitter-side input port 17 (see FIG. 4) with all six sub-data sets 11, and is forwarded at one output-side, ie receiver-side port 18 with other sub-data sets 11 than at the other one , second output gangsport 19 of the bridge 2. The is in FIG 4 - purely cal matically - illustrated for a bridge 2. While at the lower in Figure 4 output port 18 five of the six sub-data sets 11 filtered out of the data frame 4 and the data frame 4 is thus forwarded with only one sub-data set 11, at the top in Figure 4 output port 19 only the egg ne, at the Bottom port 18 filtered subset 11 filtered and thus the or the sub records 11 going out at the port 19 is not forwarded to the port 18 and vice versa.
0115At the lowest in FIG 1 Bridge 2 of the incoming data frame 4 is forwarded with a subset of data 11 via only one output port and reaches the underlying receiver, ie actuator 4th
0116On the other hand, in the upper right in Figure 1 Bridge 2 fin det, as behind this in turn several actuators 4 are located, want to receive the various sub-data sets 11 of the incoming data frame 4, again filtering instead. Concretely who, as schematically indicated by the associated block pixels, filtered out at the top in FIG 1 and the Un in Figure 1 Unte ren output port four of the five incoming at the input port sub-records 11 and lying between the upper and the lower output port output port two of the five sub-data sets 11. Accordingly, a data frame 4 with a sub-data set 11 emerges from the upper and lower ports, the sub-data sets 11 of the frames 4 differing from the upper and lower ports,
0117are only indicated, are destined to get out. The frames 4 behind all three output ports of the node 2 have the same header 5.
0118As a result, achieved in the described Ausführungsbei game each actor 3 only exactly one sub-record 11. Under different data from a transmitter 1 to a plurality of receivers 3 via exactly one stream and data frames 4 with multiple sub-records 11 whose size in the direction of each receiver decreases, transfers.
0119The functionality for filtering sub-data sets 11 at the nodes 2 is in the illustrated Ausführungsbei play in the existing IEEE802.1 node or
0120Bridging model has been integrated by setting up a function block for sub-record handling on the egress page. Which is in FIG 5 - again purely schematically - illustrated. In addition to an input 17 and an output port 18, the following is shown: MAC Relay Entity 20 and both for ingress and egress sides, MAC entities 21, stream classification / identification 22,
0121SyncRecognition 23, MACsec 24, 802.3ah OAM 25, 802.3X Pause 26, 802.3bf Time Stamping 27, PHY 28. The Stream Paylet Filtering / Merging 29 feature is provided on the Egress side. The merging function will be discussed in more detail below. The Stream Paylet Filtering / Merging function 29 is also schematically shown in FIG
0122Block picture element shown. Similarly indicated schematically is the MAC Relay 30.
0123In addition to the situation shown in FIG 1, according to the data to be distributed before lying control signals from one terminal to several other network participants is found - in particular in industrial applications - but also the reverse te case, namely that of two or more sources of data to a (common) destination. This is the case, for example, when in an automation system of egg ner plurality of sensors 31 detected actual values to a central control, which in turn can be given by a PLC 1, are to be transmitted real-time critically.
0124This situation is illustrated in FIG. 6, which once again shows a purely schematic partial representation of an industrial Ethernet-based network, wherein in turn a terminal is given by the PLC 1, which now however represents the receiver / listener, and a plurality of Transmitters / talkers are present, specifically a plurality of sensors 31, of which a total of three can be seen in FIG. It should be noted that the network topology is shown in FIGS. 1 and 6 in the same way, since in the present case the actuators 3, which can be seen in FIG. 1, and the sensors 31, which can be seen in FIG. 6, are each contained in a terminal, but of course this is by no means the case have to be. The PLC 1 and the sensors 31 are accordingly also interconnected via a plurality of bridges 2 in - the purely optional - tree topology.
0125According to the prior art, a separate stream would have to be set up for the transmission of actual values acquired by the sensors 31 to the PLC 1 for each sensor 31, and thus a network management and processing effort would be significantly increased compared to the situation according to FIG the .
0126To reduce the number of streams in the event that data from multiple sources / transmitters 31 to exactly one
0127Target / receiver 1 to be sent, is described in the European patent application with the file number EP 18 15 4319 a new type of reservation, which allows a "multiple talker per listener" configuration, so that the multiple sensors 31 via only one stream with a stream ID data to the PLC 1 can transmit.
0128In the present case, this reservation mechanism is used in combination with a data transmission in data frames 4 with a plurality of sub-data sets 11, which has already been described above for the other direction.
0129For the reservation, the listener, ie the PLC 1, issues a listener sub-record Advertise message for the stream which comprises a stream description and the sub-records 11 with the respective length and ID therein, and the listener sub-record Advertise message is transmitted via the Bridges 2 distributed in the network and transmitted to the sensors 31. With the Listener Sub Record Advertise message, the PLC 1 in the network announces that it wants to receive data over a stream. It should be noted that the information that the sensors 31 can provide actual values for the PLC 1 has been provided by other means. This is also necessary in FIG. 1 according to the prior art and can be carried out, for example, in the industrial environment during the programming of the PLC 1 and the IO modules.
0130After the PLC 1 has output the listener sub-record Advertise and has been distributed, a message sub-record Join message is output from each sensor 31 from which the acquired actual values are to be transmitted to the PLC 1. In the illustrated embodiment, all sensors 31 send a talker sub-record join message. For each sensor 31, a talker sub record of reservation reservation is then performed on the bridges 2 on the network path between the respective sensor 31 and the PLC 1. The Talker Subset Join message includes a stream ID, a sub record ID, and a reservation status.
0131The reservation of resources in the bridges 2 takes place at in deviation from the scenario shown in FIG 1, starting from the respective talker, so respective sensor 31, in the direction of a listener 1, so the PLC 1, and thus in the same direction as the forwarding of the actual values from the sensors 31 to the PLC 1, which will take place via the stream as data frame 4 if the reservation at the bridges 2 was successful. The direction of the later data transmission is indicated by arrows 16 in FIG. 5-in analogy to FIG.
0132At those bridges 2 that form branches, that is, at which data will arrive via two talker-side ports, a "merge" of the incoming talker subset record reservation statuses takes place. This is realized - in analogy to the procedure described in connection with FIG. 1 - via the "status merge" function of the reservation protocol used. In this case, a reservation protocol is used, which is erwei tert to the new data objects Listener Un terdatensatz Advertise and Talker Subrecord record, and which uses the well-known for the receiver / listener before known listener status merge function protocols, since the actual reservation of resources at the node (s) in principle equal or
0133In contrast to the prior art, the talker states are merged in the direction of the listener tree to the exactly one receiver, that is to say the PLC 1.
0134Also the listener tree, which is from the other new
0135Listener Advertise The data object of the extended reservation protocol used is determined here using the Rapid Spanning Tree Protocol. The tree is created from the saved port of the Listener Advertise.
0136An overview of the new data objects Listener Subdata Set Advertise L-PL<sub>Aclve</sub>rtise<sub>/</sub> Talker sub record Join T-PL<sub>j0</sub>in and the listener tree L resulting from the advertisement<sub>Tree</sub> 3 can be taken from the right-hand side of FIG. 3, in each case in opposition to the corresponding data objects for the other direction according to FIG. 1.
0137Following a successful reservation, the data frame 4 is cyclically transmitted from the sensors 31 to the PLC 1.
0138The data transmission from a plurality of transmitters 31 to a Empfän ger 1 takes place via data frames 4, which have at least egg nem node 2, in this case at several nodes 2 more, from different transmitters 31 derived sub-data sets 11.
0139Again, it is true that at several nodes 2, the size of the data frames 4 is changed, and the size of a data frame 4 at an input port 32, 33 of the node 2 from the size of the data frame 4 at least one output port 34 of the node 2 is different ,
0140Concretely, at two nodes, 2 data frames 4 arrive at two or more input ports 32, 33 with different sub-data sets 11, and the sub-data sets 11 originating from two or more input ports 32, 33 are merged and a data frame 4 with the merged sub-data sets 11 is written to exactly one Output port 34 of this node 2 forwarded (see FIG 6).
0141According to FIG. 6, the respective data frame 4, when it is sent away from the respective sensor 31, in each case comprises a data record 11, which is indicated schematically in FIG. 6 by the block picture elements representing the frame 4, which are the smallest size immediately behind the respective sensor 31 have. At the upper right node 2 in FIG. 6, the data frames 4 from different transmitters 31 arrive via three input ports, each with different sub-data sets 11, and these are combined, which is achieved via the stream paylet merging function 29, which in the illustrated embodiment, just like the Stream paylet filtering feature - integrated into the existing IEEE802.1 node / bridging model,
0142At the lower right in FIG 6 node 2 of the incoming data frame 4 is forwarded unchanged, con kret with a sub-data set 11, which arrives at the input port. At the following node 2 in the direction of the PLC 1, sub-data sets 11 are again combined, specifically the five sub-data sets 11 coming from the upper sensors 31 with the one sub-data set 11 from the lower sensor 31. The data frame 4 originating from the node 2 then comprises correspondingly six sub-data records 11, and is forwarded unchanged at the next node 2 closest to the PLC 1 and reaches the PLC 1.
0143In FIG. 7, this is illustrated - by analogy with FIG. 4 - by way of example for this node 2, wherein the data frame 4 with five sub-data records 11 arrives at the upper input port 33 in the FIG and a data record 11 at the lower of the data frame 4 the sub-data sets 11 are combined via the Stream Paylet Filtering / Merging Fubation 29 and at the output port 34 a data frame 4 with all six sub-data sets 11 goes out in the direction of the PLC 1.
0144As a result, the data coming from all the sensors 31 are transmitted via exactly one stream and data frames whose size increases in the direction of the one receiver, that is to say the PLC 1, the data. The receiver, ie the PLC 1, receives a data frame 4 which comprises a plurality of sub-data records 11 originating from different transmitters, in the present case sensors 31.
0145Through the introduction and use of sub-records 11, it becomes possible to combine the information from different sources or for different destinations in a frame 4. The performance of a network can be significantly improved by reducing the overhead and avoiding padding. The use of bandwidth and resources (in particular the memory in the nodes 2) is optimized. The number of real time flows can be reduced. In particular, the number of Filtering Database entries in nodes 2 is reduced. The scalability is significantly improved Lich, in particular more devices such as sensors 31 and / or actuators 3 can be supported in a network. A further considerable advantage of the procedure according to the invention is that that there is complete independence from a given network topology. The disadvantages of a restriction to a specific topology are thus completely avoided. There is an automatic communication configuration using an improved real-time flow reservation protocol. The communication function configuration is thereby considerably simplified.
0146That can be significantly reduced by the procedure according to the invention to be transported data amount is also illustrated by the following purely exemplary calculation. Assuming that a transmission of data from 1000 sensors 31 with 4 bytes of data to a PLC 1 is required, and an 1 Gbit / s Ethernet network is present (with a minimum frame size of 64 bits and 12 bits of interframe). Gap), results in the previously known case of one frame per record a Makespan of 1000 * (64 + 12) * 8 * Ins = 608m3. If, on the other hand, the data sets are combined in a frame 4, as provided by the invention, a Makespan of only one is obtained
01474024 * 8 * lns = 32.2 me.
0148The industrial network with the bridges 2 and terminals 1, 3, 31 of Figures 1 and 6 is part of a Ausfüh tion of a device according to the invention for the implementation of the method according to the invention.
0149Although the invention has been further illustrated and described in detail by the preferred embodiment, the invention is not limited by the disclosed examples, and other variations can be derived therefrom by those skilled in the art without departing from the scope of the invention.
29 members in 4 offices
Priority claims5
| Document | Office | Kind | Date |
|---|---|---|---|
| 18154319 | European Patent Office (EPO) | – | |
| 18154319 | European Patent Office (EPO) | A | |
| 18181209 | European Patent Office (EPO) | – | |
| 18181209 | European Patent Office (EPO) | A | |
| 2019051504 | European Patent Office (EPO) | W |
Members29
| Document | Office | Kind | |
|---|---|---|---|
| US2019238441A1 | United States of America | A1 | |
| CN110099093A | China | A | |
| EP3522477A1 | European Patent Office (EPO) | A1 | |
| EP3522480A1 | European Patent Office (EPO) | A1 | |
| EP3522481A1 | European Patent Office (EPO) | A1 | |
| EP3522482A1 | European Patent Office (EPO) | A1 | |
| EP3522483A1 | European Patent Office (EPO) | A1 | |
| WO2019149466A1 | World Intellectual Property Organization (WIPO) | A1 | |
| WO2019149576A1 | World Intellectual Property Organization (WIPO) | A1 | |
| WO2019149577A1 | World Intellectual Property Organization (WIPO) | A1 | |
| WO2019149578A1 | World Intellectual Property Organization (WIPO) | A1 | |
| EP3695576A1 | European Patent Office (EPO) | A1 | |
| EP3695577A1This record | European Patent Office (EPO) | A1 | |
| EP3522482B1 | European Patent Office (EPO) | B1 | |
| CN111670566A | China | A | |
| CN111670567A | China | A | |
| CN111684776A | China | A | |
| US2021067571A1 | United States of America | A1 | |
| US2021075838A1 | United States of America | A1 | |
| US2021120065A1 | United States of America | A1 | |
| EP3695577B1 | European Patent Office (EPO) | B1 | |
| EP3522477B1 | European Patent Office (EPO) | B1 | |
| EP3695576B1 | European Patent Office (EPO) | B1 | |
| US11296968B2 | United States of America | B2 | |
| CN110099093B | China | B | |
| CN111670566B | China | B | |
| CN111670567B | China | B | |
| US11477107B2 | United States of America | B2 | |
| CN111684776B | China | B |
76 legal events, as 9 offices reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | Office | |
|---|---|---|---|
| Annual fee paid to national office [announced via postgrant information from national office to epo]GrantedPGFP | PGFP | EP | |
| Annual fee paid to national office [announced via postgrant information from national office to epo]GrantedPGFP | PGFP | EP | |
| Annual fee paid to national office [announced via postgrant information from national office to epo]GrantedPGFP | PGFP | EP | |
| Annual fee paid to national office [announced via postgrant information from national office to epo]GrantedPGFP | PGFP | EP | |
| Annual fee paid to national office [announced via postgrant information from national office to epo]GrantedPGFP | PGFP | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapse because of not paying annual feesLapsedMM01 | MM01 | AT | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Gb: european patent ceased through non-payment of renewal feeCeasedGBPC | GBPC | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed because of non-payment of the annual feeLapsedMM | MM | BE | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Patent ceasedCeasedPL | PL | CH | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| No opposition filedOpposition26N | 26N | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| No opposition filed within time limitOppositionORIGINAL CODE: 0009261PLBE | PLBE | EP | |
| Information on the status of an ep patent application or granted ep patentGrantedSTATUS: NO OPPOSITION FILED WITHIN TIME LIMITSTAA | STAA | EP | |
| No opposition filed against granted patent, or epo opposition proceedings concluded without decisionGrantedR097 | R097 | DE | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Patent invalid in the netherlands as no translation has been filedMP | MP | NL | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Invalidation of extension of european patentsMG9D | MG9D | LT | |
| European patents granted designating irelandGrantedLANGUAGE OF EP DOCUMENT: GERMANFG4D | FG4D | IE | |
| Reference to at number (ep patent validated in austria)REF | REF | AT | |
| Dpma publication of mentioned ep patent grantGrantedR096 | R096 | DE | |
| European patent takes effect as a national patent in ch/liEP | EP | CH | |
| Designated contracting statesAK | AK | EP | |
| European patent grantedGrantedNOT ENGLISHFG4D | FG4D | GB | |
| (expected) grantORIGINAL CODE: 0009210GRAA | GRAA | EP | |
| Information on the status of an ep patent application or granted ep patentGrantedSTATUS: THE PATENT HAS BEEN GRANTEDSTAA | STAA | EP | |
| Grant fee paidORIGINAL CODE: EPIDOSNIGR3GRAS | GRAS | EP | |
| Request for validation of the european patent (deleted)DAV | DAV | EP | |
| Request for extension of the european patent (deleted)DAX | DAX | EP | |
| Intention to grant announcedINTG | INTG | EP | |
| Information provided on ipc code assigned before grantRIC1 | RIC1 | EP | |
| Information provided on ipc code assigned before grantRIC1 | RIC1 | EP | |
| Information provided on ipc code assigned before grantRIC1 | RIC1 | EP | |
| Despatch of communication of intention to grant a patentORIGINAL CODE: EPIDOSNIGR1GRAP | GRAP | EP | |
| Information on the status of an ep patent application or granted ep patentGrantedSTATUS: GRANT OF PATENT IS INTENDEDSTAA | STAA | EP | |
| Amendment of ipc main classPREVIOUS MAIN CLASS: H04L0029060000R079 | R079 | DE | |
| Information on inventor provided before grant (corrected)RIN1 | RIN1 | EP | |
| Information on inventor provided before grant (corrected)RIN1 | RIN1 | EP | |
| Information on inventor provided before grant (corrected)RIN1 | RIN1 | EP | |
| Request for examination filed17P | 17P | EP | |
| Designated contracting statesAK | AK | EP | |
| Request for extension of the european patentAX | AX | EP | |
| Public reference made under article 153(3) epc to a published international application that has entered the european phaseORIGINAL CODE: 0009012PUAI | PUAI | EP | |
| Information on the status of an ep patent application or granted ep patentGrantedSTATUS: REQUEST FOR EXAMINATION WAS MADESTAA | STAA | EP | |
| Information on the status of an ep patent application or granted ep patentGrantedSTATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADESTAA | STAA | EP | |
| Information on the status of an ep patent application or granted ep patentGrantedSTATUS: UNKNOWNSTAA | STAA | EP |
Numbers
- Publication
- 3695577
- Application
- 197042054
Titles3
- German
- VERFAHREN ZUR DATEN-KOMMUNIKATION IN EINEM INSBESONDERE INDUSTRIELLEN NETZWERK, STEUERUNGSVERFAHREN, VORRICHTUNG, COMPUTERPROGRAMM SOWIE COMPUTERLESBARES MEDIUM
- English
- METHOD FOR DATA COMMUNICATION IN A PARTICULARLY INDUSTRIAL NETWORK, CONTROL METHOD, DEVICE, COMPUTER PROGRAM AND COMPUTER-READABLE MEDIUM
- French
- PROCÉDÉ DE COMMUNICATION DE DONNÉES DANS UN RÉSEAU, EN PARTICULIER UN RÉSEAU INDUSTRIEL, PROCÉDÉ DE COMMANDE, DISPOSITIF, PROGRAMME INFORMATIQUE ET SUPPORT LISIBLE PAR ORDINATEUR
Classification
- CPC, 12
- H04L65/80
- H04L43/10
- H04L67/12
- H04L65/1093
- H04L12/462
- G05B19/4185
- H04L65/61
- H04L65/65
- H04L43/0858
- H04L43/026
- H04L12/40
- H04L47/76
- IPC, 3
- H04L29 06
- H04L29 08
- H04L47 76
Designated states2
- Contracting states, 1
- Türkiye
- Extension states, 1
- Montenegro