Method for communicating data in an industrial network in particular, device for carrying out the method, computer program and computer-readable medium

0001Method for data communication in an, in particular, industrial network, device for carrying out the method, computer program and computer-readable medium. The invention relates to a method for data communication in an industrial network as described in claim 1. The invention also relates to a device for carrying out the method as described in claim 12. Finally, the invention relates to a computer program and a computer-readable medium as described in claims 14 and 15.

0002Distributed industrial control applications require a guaranteed Quality of Service (QoS) in the communication network that connects the terminals with one another so that time-sensitive tasks can be carried out by the network in addition to data traffic that is not relevant in real time. The end devices can be, for example, programmable logic controllers (PLC), IO devices or protective devices.

0003Every connection for every application in the network that enables time-sensitive data traffic between end devices must be registered and reserved in order to receive guarantees from the network for a loss-free real-time transfer of data frames and punctual delivery. The network must verify the availability of network resources (e.g. address table entries, frame buffers, transmit time slices) and allocate resources - if available - for each real-time data flow, and it must grant access for real-time data traffic.

0004The control information on registrations, reservations and forwarding information for each real-time data flow must be stored within the network. The status of each reservation must be maintained. With an increasing number of end devices and their real-time data traffic in the same network, the amount of network control information increases. Since the storage and processing power of network nodes such as Brigdes or Switches, is limited, this represents a serious scaling problem. Especially in the event that a node and a terminal are combined in a single product, for example in an IO module with two switched ports for use in line / ring topologies, as found in today's Ethernet factory floor solutions, this is problematic.

0005The IEEE802.1 TSN working group defines extensions to the Ethernet standard IEEE802.1 / .3 for a converging 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 will be further improved in terms of guaranteed latency. However, the status for each real-time data flow must still be maintained in the network.

0006"Multiple Listeners per Stream" was introduced in AVB to reduce the number of real-time data flows (IEEE802 calls this "Stream") from one source (talker) to multiple destinations (listener). The typical AV (audio video) application, specifically for the distribution of audio data from a single source to several loudspeakers, is that data has to be transmitted from one source to several destinations. It is known that this AVB / TSN "Multiple Stream Reservation Protocol" (MSRP) reservation model supports multiple listeners. In this context, following a "Talker Advertise" message originating from the source, several "listener join" reservations can be made for a stream, which results in a single stream control information entry. The forwarding from one talker to its listeners goes along a single tree, the root of which is represented by the talker, in which case only a single forwarding entry is required for all stream listeners in the network nodes. A single Ethernet frame is distributed from one talker to the multiple listeners over the network.

0007In the feature proposal "<nplcit id="ncit0001" npl-type="b"><text>Resource Allocation Protocol (RAP) based on 802.1CS Link-local Registration Protocol "by Marcel Kiessling and Franz-Josef Götz from Siemens AG, which was presented at the IEEE802.1 Interim Meeting in May 2017 in Stuttgart</text></nplcit> was presented, both MSRP and the Stream Reservation Protocol (SRP) are covered.

0008This model could be used in the context of industrial automation in order to use the number of streams from a PLC representing the talker to several IO devices representing the listener. The data for all "listening", ie receiving IO devices can be transferred from the PLC using a single stream. 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 receiving data from the PLC is set up for each IO device. Depending on the amount of data of the individual IO devices, the advantage of the simplified control information can be an excessive use of the network bandwidth, since individual IO devices only need a part (subset) of the information of the frame transmitted via stream.

0009Since a closed loop control also requires a return channel from each IO device to the PLC, a large number of streams must then be set up in the network, one from each IO device to the PLC, i.e. for the " Reverse direction ". Each stream must contain an Ethernet frame that requires 64+ octets. even if the IO device only provides a few bits of input information for the PLC.

0010A real-time data flow in AVB can have several frames in one period. However, AVB real-time flows are tied to the Credit Based Shaper (CBS), which distributes the frames evenly over the entire period. TSN enables the use of other shapers, for example Strict Priority, with the highest priority for real-time data flow and bandwidth limitation in order to overcome the CBS limitations for this use case. A burst of several frames is no longer evenly distributed over the period in a TSN network. This means that all IO data can also be transmitted from the network in several frames one after the other, as is typical for control loop applications.

0011The object of the present invention is to provide a method of the type mentioned at the beginning which enables data communication in a network with reasonable effort, in particular also in an industrial network in which terminals have to communicate with one another in a closed control loop.

0012A further object of the present invention is to specify a device for carrying out such a method.

0013This object is achieved by a method for data communication in an industrial network as described in claim 1.

0014It is provided in particular that the listener advertise message is distributed in the network, in particular transmitted to several, preferably all, nodes in the network. Furthermore, the listener advertise message is preferably transmitted to several senders, the transmission to the respective sender preferably taking place via that node or those node points which is or are on the network path connecting the respective sender and recipient.

0015In particular, it is provided that a talker join message and a talker join reservation at the nodes on a network path between the respective sender are sent from several senders who want to transmit data to the recipient via the stream in response to the recipient's listener advertise and the recipient.

0016The (respective) Talker Join message furthermore preferably comprises a stream ID and / or a reservation status. It should be noted that - as previously known from the prior art for the stream facility between a sender and one or more receivers - the reservation may or may not be successful, depending on whether network resources are available, in particular network resources that meet the requirements comply with a stream description issued by the recipient or not.

0017In other words, the present invention proposes, in order to reduce the number of streams in the event that data are to be sent from several sources / senders to exactly one destination / receiver, to improve existing reservation models, specifically in such a way that they become a "multiple talker support via listener "configuration.

0018For this purpose, it is provided according to the invention that a listener advertise message is issued by at least one terminal that wants to receive data from several other terminals in the network, i.e. that represents the one receiver while the other data-providing devices form the several senders, and in particular in the network is distributed. With the listener advertise message, the end device forming the recipient announces that it wants to receive data via the one stream. The listener advertise message preferably includes a description of the stream, via which several senders can then send data to the recipient, in particular in the form of cyclically transmitted frames. The stream description includes, for example, a forwarding address and bandwidth information.

0019In order to make "multiple talker per listener" possible, a new attribute or data object is introduced according to the invention with the "listener advertise" which can be used in the context of a reservation model.

0020The newly provided attribute or data object of the "listener advertise" corresponds, if one makes a comparison with the prior art, to the "talker advertise" for the previously known case of a data transfer from a sender / talker to one or more receivers / listeners via stream. It differs from the prior art in that the one recipient who wants to receive data via a stream issues the "advert", whereas in the prior art one sender advertises, that is, a "talker advert" is issued by this and via the node points in the network are distributed to possible recipients. With the procedure according to the state of the art, the stream advertise takes place along a network tree, whose origin or Root that forms a sender / talker and which is defined in particular by the entirety of the network paths over which data go to the multiple recipients / listeners.

0021The data transmission via stream, in particular the cyclical transmission of frames from one sender to the multiple receivers via one stream, then takes place in the same direction as the advertise stream, i.e. from the sender to the recipients along the network paths of the tree. According to the invention, on the other hand, the stream advert is carried out by the one recipient and is in particular distributed to a plurality of senders. In the newly provided attribute according to the invention, the root of the network tree is the one listener.

0022After one recipient has issued a listener advertise message and this is preferably distributed via the nodes in the network and transmitted to devices providing data, i.e. potential senders, the devices that want to transmit data to this recipient or from which the sender can receive data would like to receive, register on the stream, and a resource reservation is made. For this purpose, a further new attribute or data object is provided in a particularly preferred embodiment of the invention, the "talker join" for reserving the resources, which is issued by the respective transmitter and the reservation (s) at the node or nodes on a network path between the corresponding transmitter and the receiver causes.

0023It should be noted that the information about which devices in the network the recipient wishes to receive data from may have been obtained beforehand in another way. This is comparable to the AVB model, in which the listeners receive a stream ID from the application that is used in the Talker Advertise. In the industrial environment, the information can come, for example, from the application that generates the program of the PLC and the IO devices and, for example obtains a free stream ID from a network service.

0024The resource reservation process following the listener advertise then takes place in the opposite direction to the prior art, and specifically does not begin on the receiver side but on the sender side. The reservation along the respective network path starts in particular at the node closest to the respective sender and "propagates" in the direction of the recipient, whereas according to the prior art (listener join) the reservation begins at the node closest to the respective recipient in the direction of the sender.

0025According to an advantageous embodiment of the method according to the invention, it is provided that a reservation status of a first port in the direction of one or more transmitters and a reservation status of a second port in the direction of one or more further transmitters are combined at at least one node, in particular at several nodes, and in particular the The summarized reservation status is forwarded to the recipient via a port.

0026It is particularly preferred that the node closest to the receiver forwards a reservation status summarized for all transmitters to the receiver, with the reservation status arriving at the receiver including the information that a reservation of the transmitter-side ports of all nodes on the transmitter and the Network paths connecting the recipient was successful, or that a reservation of the sender-side ports of all nodes on the network paths connecting the sender and receiver was unsuccessful, or that a reservation of at least one transmitter-side port of at least one node on the network paths connecting the transmitter and receiver was unsuccessful and a reservation of at least one transmitter-side port of at least one node on the network paths connecting the transmitter and receiver was successful.

0027It should be noted that the status merge function for listener status is known from the prior art. The reservation is based on a single forwarding tree, for example in an AVB network, which is built with RSTP (Rapid Spanning Tree Protocol). The listener statuses are merged in the upward direction of the tree to the one transmitter.

0028In the above embodiments of the present invention, it is - again - exactly the opposite. The talker statuses are merged to exactly one recipient in the upward direction of the tree.

0029While according to the procedure known from the prior art, the reservation statuses of nodes are merged, which arrive at the respective node via the receiver-ie listener-side ports, and for the data distribution to several destinations, a duplication of the frames in takes place at the relevant nodes, the merge is not made of listener but talker states.

0030The status merge function of known protocols known to the receiver / listener can be used or built on, since the actual reservation of resources at the node or nodes can in principle proceed in the same way or analogously to the previously known procedure .

0031In the method according to the invention, it can furthermore be provided that at least one reservation protocol is used for the reservation of resources at one or more nodes. A previously known, in particular standardized, reservation protocol can be used, which is then preferably expanded by at least one, in particular a plurality of data objects. Examples of known, standardized reservation protocols that can be used in particular in an extended form within the scope of the method according to the invention are Stream Reservation Protocol (SRP) and / or Multiple Stream Registration Protocol (MSRP) and / or Resource Reservation Protocol (RSVP).

0032SRP is the well-known change or extension of the IEEE802.1Q standard, which was standardized separately as IEEE802.1Qat. The listener advertise message and / or the talker join message and / or the talker join reservation then particularly preferably represent the reservation protocol, for example SRP and / or MSRP and / or RSVP, expanding data objects.

0033The new attributes or data objects for the multiple talker reservations provided according to the present invention can in particular be introduced into existing, standardized flow reservation protocols without the fundamental principle of real-time flow reservation having to be changed.

0034Furthermore, it can be provided that the network tree is determined, in particular using the Rapid Spanning Tree Protocol, which is formed by network paths that connect one receiver to those transmitters who want to send data to the receiver via the stream and of which in particular one Talker Join message was sent.

0035The specific network tree belonging to the stream between the multiple senders and the one receiver, which can also be referred to as a listener tree, preferably represents a data object that uses a reservation protocol, for example SRP and / or MSRP, expanded.

0036The listener tree results from the listener advertise according to the invention and includes in particular the information about a listener port per node, in particular bridge, and preferably the many possible talker ports. The advertise listener going out from one listener serves practically as the new logical root of a tree for the reservations.

0037The data transmission from several transmitters to the receiver following the listener advertise and the talker joins, in particular reservations, in particular in the form of cyclically sent frames, then takes place in the opposite direction to the listener advertise, namely from the respective transmitter to the one receiver, i.e. in "reservation direction".

0038In a further advantageous embodiment, it is provided that the listener advertise message comprises a stream description which has an indication of the stream type, with an accumulated stream or a multiplex stream preferably being indicated as the stream type.

0039In the case of the accumulated stream type, provision is made in particular that in each period a frame is transmitted from all transmitters participating in the stream to the receiver, this "data accumulation" leading to a larger bandwidth, but allowing a low latency, since all transmitters are "simultaneously" can send. In the case of the accumulated stream type, however, frames must be cached in the bridges, since only the reserved number of frames in each period can be forwarded via the port on the listener side.

0040According to the multiplex stream type, on the other hand, only the frame of one sender is transmitted in each period, that is, there is a wait. The multiplex stream type gets by with a lower bandwidth, but it takes longer for the data to arrive at a recipient because it is transmitted one after the other. Depending on the specific requirements of a given application, a decision can be made on one or the other type.

0041The present invention, which enables "multiple talkers for one real time flow / stream" for the first time, offers a number of considerable advantages. On the one hand, the number of real-time flows, i.e. streams, in a network is reduced. This is accompanied by a reduction in the control overhead for the registration and reservation of the streams and a reduction in the number of filter database entries in the node points, and the same overhead is achieved for both directions of the data transfer. Furthermore, the scalability is improved, since more end devices, in particular sensors / actuators, can be supported. The procedure according to the invention is also independent of the given network topology. It is by no means restricted to a line topology, for example, but can also be used in the case of other network topologies, such as a ring or star topology. Furthermore, the communication configuration is simplified by the procedure according to the invention. The engineering of control applications can also be simplified; in particular, automatic communication configuration without engineering is possible and the control information for fieldbus applications can be simplified.

0042Whether a stream exists between a receiver and several transmitters within the meaning of the invention can be determined in particular from the fact that there is exactly one stream ID and several transmitters transmit data via the one stream with the one ID to the one receiver. The same stream destination address can be used for the data from several senders.

0043It goes without saying that in a network a plurality of streams via which data can be exchanged in a group of communication partners formed by exactly one recipient and two or more senders, i.e. a plurality of streams in the manner according to the invention with listener advertise and talker Join (s) can be set up.

0044Alternatively or additionally, the above object can be achieved by a method for data communication in a particularly industrial network with one or more nodes, in which a stream is set up between several transmitters and a receiver and / or from several transmitters via a stream of data sent to a recipient.

0045Another object 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 a transmitter and one, preferably exactly one controller, in particular one PLC of an industrial automation system or a vehicle as a receiver, Data are exchanged using a method according to the invention for data communication and the industrial technical process or vehicle is controlled on the basis of the exchanged data.

0046Another object of the present invention is a device comprising<ul id="ul0001" list-style="dash" compact="compact"><li>at least one, preferably several nodes, in particular bridges, and / or</li><li>at least one, preferably several terminals, in particular sensors, and / or, each forming a transmitter</li><li>a device forming a receiver, in particular a controller of an industrial automation system or a vehicle,</li></ul>wherein the device is designed and set up to carry out the method according to the invention for data communication or the control method according to the invention.

0047The device according to the invention can, for example, represent part of a control system for an industrial technical process, which then forms a further subject matter of the present invention.

0048Furthermore, the invention relates to a computer program which comprises program code means for performing the steps of the method according to the invention for data communication or the control method according to the invention, as well as a computer-readable medium which comprises instructions which, when they are executed on at least one computer, the at least one Arrange the computer to carry out the steps of the method according to the invention for data communication or to carry out the control method according to the invention. It should be noted that a computer-readable medium should not only be understood to mean a physical medium, but such a medium can also be present, for example, in the form of a data stream and / or a signal that represents a data stream.

0049Further features and advantages of the present invention will become clear from the following description of an embodiment of the method of the present invention with reference to the accompanying drawings. In it is<dl id="dl0001" compact="compact"><dt>FIG 1</dt><dd>a schematic partial representation of an industrial network to illustrate the case that a transmitter transmits data to several receivers via a stream;</dd><dt>FIG 2</dt><dd>a schematic partial representation of an industrial network to illustrate the case that a receiver receives data from several transmitters via a stream;</dd><dt>FIG 3</dt><dd>a purely schematic representation of a bridge at which two listener states are merged (merge);</dd><dt>FIG 4</dt><dd>a purely schematic representation of a bridge at which two talker statuses are merged (merge);</dd><dt>FIG 5</dt><dd>an overview with new data objects compared to the state of the art; and</dd><dt>FIG 6</dt><dd>a schematic representation to illustrate the accumulated and multiplex stream types.</dd></dl>

0050the <figref idref="f0001">FIG 1</figref> 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 that over several bridges 2, of which in the<figref idref="f0001">FIG 1</figref> only four pieces are shown, is connected to a plurality of further terminals, each of which represents a receiver / listener 3. Of the recipients 3 are in the<figref idref="f0001">FIG 1</figref> to recognize three. The three points on the right in the FIG are intended to make it clear that further bridges 2 and terminals (can) follow behind the bridge 2 at the top right.

0051How to get the <figref idref="f0001">FIG 1</figref> As can be seen, the Ethernet-based network with the plurality of bridges 2 is characterized in the illustrated embodiment by a line topology. Of course, another network topology known from the prior art, for example a tree, star or ring topology, can also be provided.

0052In the present case, the terminal device forming the transmitter 1 is a PLC of an industrial automation system and the terminal devices forming the receiver 3 are actuators of the automation system, which cyclically require control signals from the PLC in order to cyclically respond to an industrial technical process not shown in the figures to act.

0053The control signals are transmitted from the PLC 1 to the actuators 3 via the Ethernet-based network. The communication of the control signals from the PLC 1 to the actuators 3 takes place in the form of frames that are transmitted via stream in the network. This type of data communication, known for example from the AVB and TSN standard, ensures in particular that a specified latency period, which can vary from stream to stream and in particular depends on the respective application, is adhered to. This ensures that the control signals arrive at the actuators 3 within a predetermined maximum latency period, i.e. a maximum latency period passes between the data being fed into the network by the PLC 1 and the data being received by the actuators 3. In this way, for example, particularly real-time-critical communication between the PLC 1 and the actuators 3 can be ensured.

0054The rule here is that a stream, as defined, for example, by the Audio / Video Bridging (AVB) task group and in particular by the Time Sensitive Networking (TSN) task group in the international standard IEE802.1, makes use of the associated stream reservation protocol (Stream Reservation Protocol - SRP) is set up, However, only a stream between a sender and a receiver and a stream between a sender and several receivers can also be obtained. The latter configuration clearly corresponds to the one from<figref idref="f0001">FIG 1</figref>.

0055To set up a stream between the PLC 1 and the actuators 3 in accordance with known standards, a reservation is made with SRP at each of the bridges 2 that are on the network path between the PLC 1 and the respective actuator 3, i.e. via which they are connected. In a first step, the stream is announced by the PLC 1, which is the data source also referred to as the talker, with a talker advert and the properties of the stream are described by the PLC 1 forming the talker. The PLC 1 specifies, in particular, a stream ID, a forwarding address and bandwidth information for the data transfer outgoing from it.

0056The announcement of the stream is distributed to all nodes, in this case bridges 2 in the network, with each bridge 2 then receiving the information from the receiving port, i.e. the port in the direction of the talker 1 via which the announcement was received, and later also the data , leads. Since the data source is also referred to as talker 1 according to the prior art, this port is also referred to as talker port. The ports in the direction of the listener (s) are accordingly also referred to as send or listener ports.

0057One or more listeners, in this case the actuators 3, log on to the stream offered by the PLC 1.

0058At those bridges 2 that are between the talker 1 and the respective listener 3, a reservation is made at the port in the direction of the listener, i.e. the listener port according to the stream description specified by the PLC 1 representing the talker, provided that the available resources are available 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 set up (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 set up and forwards a positive reservation status to the following bridge 2, or the last bridge to sender 1.

0059Each node 2 can use the reservation to ensure that it guarantees the required performance during the subsequent data transfer. This is where streams differ from unprotected connections.

0060If insufficient resources are available, a negative reservation status is passed on.

0061The reservation starts at the bridge 2 closest to the respective receiver / listener, ie actuator 3, and "propagates" along the respective network path to the data source / talker, ie the PLC 1. The reservation of resources in the bridges 2 is therefore carried out in the opposite direction on the forwarding of the control signals from the PLC 1 to the actuators 3, which will take place via the stream if the reservation on the bridges 2 was successful. The direction of the later data transmission is in the <figref idref="f0001">FIG 1</figref> outlined with arrows 4 and above, the forwarded frames representing purely schematically, with 5 designated block image elements.

0062The reservation is based on the forwarding tree, also known as the talker tree, which can be set up with the Rapid Spanning Tree Protocol (RSTP).

0063A “merge” of the incoming listener reservation status takes place at those bridges 2 which form branches, that is to say which have to forward the data via two ports on the listener side. This is implemented via the "Status merge" function of the reservation protocol used.

0064the <figref idref="f0002">FIG 3</figref> shows a purely schematic representation of a bridge 2, of whose ports two listener-side ports 6 and one talker-side port 7 can be seen.

0065The “listener status merge” function in the direction of the talker 1, which is shown purely schematically by a block image element, is denoted by 8. Arrows labeled 9 further represent the merged listener reservation status arriving via the listener-side ports 6 and outgoing via the talker-side port 7. If only successful reservations (listener ready) arrive at the listener-side port 6, a successful reservation (listener ready) is passed on to port 7. If there is at least one successful reservation (Listener Ready) and at least one incorrect reservation (Listener Asking Failed - e.g. due to insufficient resources on a bridge behind port 6), a Listener Ready Failed is passed on as a merged status. In the case of only incorrect reservations (Listener Asking Failed), an incorrect status (Listener Asking Failed) is passed on.

0066Still in the <figref idref="f0002">FIG 3</figref> The direction of the frame forwarding, i.e. the flow of data, is indicated purely schematically with arrows 10 Frames 5 (multicast).

0067For a real-time critical transmission of control signals from the PLC 1 to several actuators 3, the above-described way has proven itself. A plurality of listeners can be supplied with data with just one stream with a stream ID, which guarantees a reasonable network overhead.

0068In addition to the in <figref idref="f0001">FIG 1</figref> The situation shown, according to which control signals are to be distributed from a terminal to several other network participants, is also found - especially in industrial applications - but also the reverse case, namely that data are to be transmitted from two or more sources to a (common) destination. This is the case, for example, when actual values ​​recorded by a plurality of sensors in an automation system are to be transmitted in a real-time-critical manner to a central controller, which in turn can be provided by a PLC 1.

0069This situation is in <figref idref="f0001">FIG 2</figref> which again shows a purely schematic partial representation of an industrial Ethernet-based network, with a terminal device again being provided by the PLC 1, which, however, now represents the receiver / listener, and a plurality of transmitters / talkers are present, specifically several sensors 11 , of which in <figref idref="f0001">FIG 2</figref> a total of three can be seen. The industrial network with the bridges 2 and end devices<figref idref="f0001">FIG 2</figref> is part of an embodiment of a device according to the invention for performing the method according to the invention.

0070It should be noted that the network topology in the <figref idref="f0001">FIGS. 1 and 2</figref> is shown consistently, since the present in <figref idref="f0001">FIG 1</figref> recognizable actuators 3 and those in the <figref idref="f0001">FIG 2</figref> recognizable sensors 11 are each contained in a terminal, but of course this does not have to be the case.

0071The PLC 1 and the sensors 11 are correspondingly connected to one another via a plurality of bridges 2 in - the purely optional - line topology.

0072According to the prior art, a separate stream would have to be set up for each sensor 11 for the transmission of actual values ​​recorded with the sensors 11 to the PLC 1. For those in the<figref idref="f0001">FIG 2</figref> recognizable three sensors 11 would accordingly require three separate streams, which is one compared to the situation according to FIG <figref idref="f0001">FIG 1</figref> significantly increased network administration and processing costs would be associated.

0073The present invention proposes, in order to reduce the number of streams in the event that data are to be sent from several sources / senders to exactly one destination / receiver, to implement a new type of reservation that enables a "multiple talker per listener" configuration so that the three transmitters 11 can transmit data to the PLC 1 via just one stream with a stream ID.

0074Specifically, in a first step of the exemplary embodiment of the method according to the invention described here, the recipient, i.e. the PLC 1, issues a listener advertise message for the stream, which includes a stream description, and the listener advertise message is distributed over the bridges 2 in the network and transmitted to the sensors 11. With the listener advertise message, the PLC 1 announces in the network that it would like to receive data via a stream. It should be noted that the information that the sensors 11 can provide actual values ​​for the PLC 1 was provided in another way. This is in<figref idref="f0001">FIG 1</figref> Also necessary according to the state of the art and can be done, for example, in an industrial environment during the programming of the PLC 1 and the IO modules.

0075After the PLC 1 has issued the listener advertise and this has been distributed, a talker join message is issued by each sensor 11 from which recorded actual values ​​are to be transmitted to the PLC 1. In the illustrated embodiment, all three sensors 11 send a talker join message. For each of the three sensors 11, a talker join reservation is then carried out on the bridges 2 on the network path between the respective sensor 11 and the PLC 1. The Talker Join message includes a stream ID and a reservation status.

0076The reservation of resources in the bridges 2 takes place in a departure from the prior art starting from the respective talker, i.e. respective sensor 11, in the direction of one listener 1, i.e. in the same direction as the forwarding of the actual values ​​from the sensors 11 to the SPS 1, which will take place over the stream if the reservation on bridges 2 was successful. The direction of the later data transmission is in the<figref idref="f0001">FIG 2</figref> - In analogy to <figref idref="f0001">FIG 1</figref> - Outlined with arrows 12 and above, the forwarded frames represent purely schematically, with 13, 14, 15, 16 designated block image elements.

0077A “merge” of the incoming talker reservation status takes place at those bridges 2 that form branches, that is to say at which data will arrive via two talker-side ports. This will - by analogy with that related to<figref idref="f0001">FIG 1</figref> procedure described - implemented via the "Status merge" function of the reservation protocol used. A reservation protocol is used, which has been expanded to include the new data objects listener advertise and talker join, and which uses the listener status merge function of known protocols known to the recipient / listener, since the actual reservation of resources begins in principle the same or the same as the node (s) can run analogously to the previously known procedure with a sender / talker and several receivers / listeners.

0078In contrast to the state of the art, the talker statuses are merged in the direction of the listener tree to exactly one recipient, i.e. the PLC 1.

0079The listener tree, which is formed from the further new listener advertise data object of the extended reservation protocol used, is also determined in the present case with the rapid spanning tree protocol. The tree is created from the saved port of the listener advertise.

0080An overview of the new data objects Listener Advertise L_Advertise, Talker Join T_Join and the listener Tree L resulting from the advertise_Tree can be the right side of the <figref idref="f0003">FIG 5</figref> are taken, in each case in comparison with the corresponding data objects from the previously known standard, i.e. the Talker Advertise T_Advertise, Listener Join L._Join and Talker Tree T_Treethat is in the left half of the <figref idref="f0003">FIG 5</figref> are shown. The two upper, new data objects are marked with the quantity bracket.

0081In the <figref idref="f0002">FIG 4</figref> the "merge" of the talker status is purely schematic - and in to <figref idref="f0002">FIG 3</figref> correspondingly the "merge" of the listener states - shown. A bridge 2 can also be seen here, of which two ports 17 on the talker side and one port 18 on the listener side are shown. The “talker status merge” function in the direction of the listener, that is to say the PLC 1, which is denoted by 19 in the FIG.

0082As also from the <figref idref="f0002">FIG 4</figref> As can be seen, the forwarding of the talker reservation status and the data in the procedure according to the invention takes place in the same direction, both in the direction of the one recipient, that is to say the PLC 1.

0083Still in the <figref idref="f0002">FIG 4</figref> The direction of the frame forwarding, i.e. the data flow, is indicated purely schematically, with arrows 20 as well as the merged talker reservation status incoming via the talker-side ports 17 and the merged talker reservation status outgoing via the listener-side port 18 Arrows 21. Via bridge 2, which is closest to the listener, i.e. PLC 1, all reservation statuses of all talkers, i.e. sensors 11, which have joined the stream announced to PLC 1 with the listener advertise (join) to PLC 1, which has the logical root ( root) of the tree. The merge reservation status arriving at the PLC 1 includes either the information that a reservation of the sender-side ports 17 of all bridges 2 on the network paths connecting the sensors 11 and the PLC 1 was successful, or that a reservation of the sender-side ports 17 of all Bridges 2 on the network paths connecting the sensors 11 and the PLC 1 was not successful, or that a reservation of at least one sender-side port 17 of at least one bridge 2 on the network paths connecting the sensors 11 and the PLC 1 was unsuccessful and at least one reservation of a sender-side port 17 was successful.

0084If the talker reservation is successful for all affected nodes, i.e. all bridges 2 on the listener tree, the actual data transfer can begin, i.e. the forwarding of frames 13, 14, 15, 16 with actual values ​​recorded by sensors 11.

0085The forwarding of the frames 13, 14, 15, 16 arriving at the bridge 2 from different sensors 11 via the two talker-side ports 17 via the one listener-side port 6, 7 can take place in different ways, for example according to the accumulated stream Type or the multiplexed stream type. In the first type, all sensors 11 can send a frame 13, 14, 15, 16 in a period, the sum of all frames 13, 14, 15, 16 then having to be reserved, so a larger bandwidth is required. In the case of the multiplexed stream type, the coordination is such that only one of the sensors 11 sends a frame in each period, which is associated with a lower bandwidth requirement but a longer waiting time, since it takes longer until all sensors 11 have sent their data one after the other. The stream type is part of the stream description which the PLC 1 issued together with the listener advert.

0086the <figref idref="f0003">FIG 6</figref> shows, purely schematically, the principle of the accumulated and multiplexed stream types in comparison. Specifically, on the left is the<figref idref="f0003">FIG 6</figref> exemplarily for periods # 1 to # 4 and frames 13, 14, 15 shown that with the accumulated stream type the three frames 13, 14, 15 are transmitted in each period, which is associated with a higher bandwidth 22, and according to the multiplexed Stream type, only one frame 13, 14, 15 is forwarded in each period, the bandwidth 22 corresponding to that of the largest frame 13.

0087On the basis of actual values ​​obtained, the PLC 1 can, in particular, determine control signals in a manner that is well known per se and / or the actual values ​​can be used for evaluation purposes. The PLC 1 acts in particular on the industrial technical process based on the actual values ​​received.

0088The procedure according to the invention described above offers a large number of considerable advantages. On the one hand, the number of real-time flows, i.e. streams, in a network is reduced. It is no longer necessary for a separate stream to be set up for each sensor 11 from which data are to be transmitted to the PLC 1, but rather several sensors 11 can send data via just one stream to a common destination. This is accompanied by a reduction in the control overhead for the registration and reservation of the real-time streams and a reduction in the number of filter database entries in node 2, and the same overhead is required for both directions for the closed-loop control Data transfers achieved. Furthermore, the scalability is improved, since more terminals, in particular sensors / actuators 11, 3, can be supported. The procedure according to the invention is also independent of the given network topology. It is by no means restricted to the line topology shown, but can also be used in the case of other network topologies, such as a ring or star topology. Furthermore, the communication configuration is simplified by the procedure according to the invention. The engineering of control applications can also be simplified; in particular, automatic communication configuration without engineering is possible and the control information for fieldbus applications can be simplified.

0089Although the invention has been illustrated and described in more detail by the preferred exemplary embodiment, the invention is not restricted by the disclosed examples and other variations can be derived therefrom by the person skilled in the art without departing from the scope of protection of the invention as described in the claims.