METHOD FOR DATA COMMUNICATION IN A NETWORK

Abstract

A method and system is provided for data communication in a network, with one or more nodal for data transfer between a plurality of data-providing transmitters and a receiver receiving the data provided by the plurality of transmitters via a stream with which, to establish the stream, the receiver issues a listener advertise message for the stream, that comprises a stream description, and the listener advertise message is transmitted to at least one nodal point in the network.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of EP18154319.0 filed on Jan. 31, 2018, which is hereby incorporated by reference in its entirety.

FIELD

Embodiments relate to a method for data communication in a network, particularly in an industrial network.

BACKGROUND

Distributed industrial control applications require a guaranteed quality of service (QoS) in the communication network connecting the terminals to one another to provide time-sensitive tasks to be performed by the network alongside non-real-time-relevant traffic. The terminals may, for example, be programmable logic controllers (PLCs), IO devices or protective equipment.

Every connection for every application in the network that provides time-sensitive traffic between terminals is registered and reserved in order to obtain guarantees from the network for loss-free real-time transfer of data frames and on-time delivery. To this end, 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 must provide access for real-time traffic.

Within the network, it is necessary to store control information on registrations, reservations and routing information for each real-time data flow. The status of each reservation is retained. The increasing number of terminals and their real-time traffic in the same network is accompanied by an increased amount of network control information. Since the storage and processing capacity of network nodal points, for example bridges or switches, is limited, the increase represents a serious scaling problem. The scaling problem is problematic in the event of a nodal point and a terminal being merged in a single product, for example in an IO module with two switched ports for use in linear/ring topologies, as found in present-day Ethernet factory floor solutions.

The IEEE802.1 TSN Working Group defines extensions of the Ethernet Standard IEEE802.1/.3 for a convergent time-sensitive network (TSN). Previous work by the Audio Video Bridging (AVB) Working Group is used as the basis for further improving the quality of service for real-time data flows with respect to guaranteed latency. However, it is still necessary for the status for each real-time data flow to be retained in the network.

The concept of “multiple listeners per stream” was introduced into AVB in order to reduce the number of real-time data flows (IEEE802 calls this a “stream”) from one source (talker) to a plurality of destinations (listeners). The requirement to transmit data from one source to a plurality of destinations is a typical AV (audio video) application, specifically for the distribution of audio data from a single source to a plurality of loudspeakers. The reservation model AVB/TSN “Multiple Stream Reservation Protocol” (MSRP) supports a plurality of listeners. A “talker advertise” message emanating from the source may be followed by a stream of a plurality of “listener join” reservations thus resulting in a single stream control information entry. Routing from the one talker to its listeners takes place via a single tree where the roots of the tree represent the talker. Then only one single routing entry is required for all stream listeners in the network nodal points. A single Ethernet frame is distributed from the one talker via the network to the plurality of listeners.

In industrial automation, the model might be used to reduce the number of streams from a PLC representing the talker to a plurality of IO devices representing listeners. The data for all the “listening”, e.g. receiving, IO devices may be transferred from the PLC using a single stream. The number of streams in the network and hence the amount of control information is then greatly reduced compared to a case in which an independent stream is established for each IO device for the reception of data from the PLC. Depending upon the amount of data from the individual IO devices, the advantage of the simplified control information may be more excessive usage of network bandwidth since individual IO devices only require a part (subset) of the information in the frames transmitted via stream.

Since a closed-loop control circuit also requires a back channel from each IO device to the PLC, it is still necessary to establish an overall higher number of streams in the network; one from each IO device to the PLC, e.g. for the “return direction”. An Ethernet frame requiring 64+ octets must be sent in each stream, even if the JO device only provides a few bits of input information for the PLC.

A real-time data flow in AVB may have several frames in one period. However, AVB real-time flows are linked to the credit-based shaper (CBS), that distributes the frames uniformly over the entire period. TSN provides the use of other shapers, for example a strict priority shaper, with highest priority for the real-time data flow and bandwidth limitation in order to overcome the CBS limitations for this application. A burst of a plurality frames in a TSN network is no longer uniformly distributed over the period. As a result, all the IO data may also be transmitted by the network directly in sequence in a plurality of frames, as is typical in closed-loop control applications.

SUMMARY AND DESCRIPTION

The scope of the present disclosure is defined solely by the appended claims and is not affected to any degree by the statements within this summary. The present embodiments may obviate one or more of the drawbacks or limitations in the related art.

Embodiments provide a method that provides data communication in a network for a justifiable outlay, for example in an industrial network in which terminals communicate with one another in a closed-loop control system.

Embodiments provide a method for data communication in a network, for example in an industrial network with one or more nodal points, for data transfer between a plurality of data-providing transmitters and a receiver receiving the data provided by the plurality of transmitters via a stream with which, to establish the stream, the receiver issues a listener advertise message for the stream, that includes a stream description, and the listener advertise message is transmitted to at least one nodal point of the network.

The listener advertise message is propagated in the network, for example transmitted to a plurality of, e.g. all, nodal points in the network.

The listener advertise message is transmitted to a plurality of transmitters. The transmission to the respective transmitter takes place via the nodal point or nodal points lying on the network path connecting the respective transmitter and receiver.

In an embodiment of the method, in response to the receiver's listener advertise, at least one transmitter, that wishes to transmit data to the receiver via the stream, sends a talker join message that makes a talker join reservation at the nodal points on the network path between the transmitter and the receiver. In response to the receiver's listener advertise, a plurality of transmitters, each wishing to transmit data to the receiver via the stream, each send a talker join message and make a talker join reservation at the nodal points on a network path between the respective transmitter and the receiver.

The (respective) talker join message may further include a stream ID and/or a reservation status.

The reservation may be successful or unsuccessful depending on whether network resources are available, for example, network resources satisfying or failing to satisfy the requirements of a stream description issued by the receiver.

To reduce the number of streams in the event that data is to be sent from a plurality of sources/transmitters to exactly one destination/receiver, existing reservation models are improved, specifically in that they support a “multiple talker per listener” configuration.

At least one terminal, that wishes to receive data from a plurality of other terminals in the network, e.g. that represents the one receiver, while the other, data-providing devices, that form a plurality of transmitters, issue a listener advertise message and that is distributed in the network. With the listener advertise message, the terminal forming the one receiver announces that it wishes to receive data via the one stream. The listener advertise message includes a description of the streams via which a plurality of transmitters may then send data to the receiver data, for example in the form of cyclically transmitted frames. The stream description includes, for example, a routing address and broadband information.

In order to provide “multiple talker per listener”, the “listener advertise” introduces a new attribute or data object, that may be used in the context of a reservation model.

The newly provided “listener advertise” attribute or data object corresponds to the “talker advertise” in the previously known case of data transfer from one transmitter/talker to one or more receivers/listeners via stream. A difference is that the one receiver, that wishes to receiver data via a stream, issues the “advertise”, as opposed to where the one transmitter that advertised, e.g. a “talker advertise” was issued by the transmitter and distributed to possible receivers via the nodal points in the network. With the opposing procedure, the stream advertises travels along a network tree the origin or root of which forms the one transmitter/talker and that is defined by the total number of networks via which the data passes to the plurality of receivers/listeners.

Data transmission via stream, for example, the cyclic transmission of frames from the one transmitter to the plurality of receivers via the one stream then takes place in the same direction as the stream advertise, e.g. from the transmitter to the receivers along the network path of the tree.

The stream advertise takes place by the one receiver and is distributed to a plurality of transmitters. With the newly provided attribute the root of the network tree is the one listener.

When the one receiver has issued a listener advertise message that is distributed in the network via the nodal points and transmitted to data-providing devices, e.g. potential transmitters, the devices that wish to transmit data to the receiver or from which the transmitter wishes to receive data may register with the stream and thus a resource reservation is made. In an embodiment, a further new attribute or data object is provided, the “talker join” for the reservation of resources, that is issued by the respective transmitter and effects the reservation(s) at the nodal point or nodal points on a network path between the corresponding transmitter and the receiver.

The information regarding the devices in the network from which the one receiver wishes to receive data may be obtained in advance in another way which is comparable with the AVB model with which the listeners receive a stream ID from the application used in the talker advertise. In the industrial environment, the information may, for example, come from the application that creates the program for the PLC and the IO devices and obtains a free stream ID, for example, from a network service.

The resource reservation process following the listener advertise then takes place in the reverse direction to that in the prior art, specifically, it does not start at the receiver side, but at the transmitter side. The reservation along the respective network path starts at the nodal point located closest to the respective transmitter and “propagates” in the direction of the receiver, while, in the prior art (listener join) the reservation is commenced at the nodal point closest to the respective receiver and continued in the direction of the transmitter.

An embodiment provides that for at least one nodal point at a plurality of nodal points, 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 merged and the merged reservation status is routed via a port in the direction of the receiver.

The nodal point located closest to the receiver routes a merged reservation status for all the transmitters to the receiver. The reservation status arriving at the receiver includes the information that a reservation of the transmitter-side ports of all the nodal points on the network paths connecting the transmitters and the receiver was successful or that a reservation of the transmitter side ports of all the nodal points on the network paths connecting the transmitters and the receiver was unsuccessful or that a reservation of at least one transmitter side port of at least one nodal point on the network paths connecting the transmitters and the receiver was unsuccessful and a reservation of at least one transmitter side port of at least one nodal point on the network paths connecting the transmitters and the receiver was successful.

The status merge function for listener statuses is known from the prior art where, for example in an AVB network, the reservation is based on a single routing tree constructed with RSTP (Rapid Spanning Tree Protocol). The listener statuses are merged in the upward direction of the tree toward the one transmitter.

With the above-described embodiments the talker statuses are merged in the upward direction of the tree toward the exactly one receiver.

While according to the procedure known from the prior art, there is a merging of the reservation statuses of nodal points that arrive at the respective nodal point via the receiver-side, e. g. listener-side, ports, and for data distribution to a plurality of destinations, there is a duplication of the frames in the relevant nodal points, it is talker statuses, not listener statuses, that are merged.

Known protocols may be utilized for the previously known status-merge function for receivers/listeners or to use the protocols as a basis since the actual reservation of resources at the nodal point or nodal points may, in principle, take place in the same or a similar way to the previously known procedure.

At least one reservation protocol is used for the reservation of resources at one or more nodal points. It is possible to utilize a previously known, for example, standardized, reservation protocol, that is then extended by at least one data objects. Examples of known standardized reservation protocols, that may be used in the context of method in extended form, are the Stream Reservation Protocol (SRP) and/or the Multiple Stream Registration Protocol (MSRP) and/or the Resource Reservation Protocol (RSVP).

SRP is the known amendment or extension of the IEEE802.1Q standard, that was standardized separately as IEEE802.1Qat.

The listener advertise message and/or the talker join message and/or the talker join reservation then represent data objects that extend the reservation protocol, for example SRP and/or MSRP and/or RSVP.

The new attributes or data objects for the multiple talker reservations provided may be introduced into existing, standardized flow reservation protocols without having to the change the fundamental principle of real-time flow reservation.

It may also be provided that using the Rapid Spanning Tree Protocol, there is a determination of the network tree that is formed by network paths connecting the one receiver to the transmitters that wish to send data to the receiver via the stream and from which in each case a talker join message was sent.

The network tree determined, that belongs to the stream between the plurality of transmitters and the one receiver, that may also be called a listener tree represents a data object that expands a reservation protocol used for the resource reservation, for example SRP and/or MSRP.

The listener tree results from the listener advertise and includes information on one listener port per nodal point, for example bridge, and the numerous possible talker ports. The listener advertise emanating from a listener in effect serves as a new logical root of a tree for the reservations.

The data transmission following the listener advertise and the talker joins, for example reservations, from a plurality of transmitters to the receiver, in the form of cyclically transmitted frames, then takes place in the opposite direction to the listener advertise namely from the respective transmitter to the one receiver, e.g. in the “reservation direction”.

In an embodiment, the listener advertise message includes a stream description that specifies the stream type. The stream type is specified as an accumulated stream or a multiplexed stream.

With the accumulated stream type, in each period a frame is transmitted from all the transmitters participating in the stream transmitters to the receiver. The “data accumulation” results in a larger bandwidth but provides a low latency since all the transmitters may transmit “simultaneously”. However, with the accumulated stream type, frames must be cached in the bridges since it only the reserved number of frames may be routed via the listener-side port in each period.

According to the multiplexed stream type, the frame of only one transmitter is transmitted in each period, e.g. there is a wait. The multiplexed stream type copes with a smaller bandwidth that takes longer for the data for the data to arrive at a receiver since it is transmitted successively. The decision for one type or the other depends on the specific requirements of a given application.

Embodiment provide “multiple talkers for one real time flow/stream.” The number of real-time flows, e.g. streams in a network is reduced that is accompanied by a reduction in the control overheads for the registration and reservation of the streams and a reduction in the number of filter database entries in the nodal points and the same overheads are achieved for both data transfer directions. Furthermore, scalability is improved since more terminals, for example, sensors/actuators may be supported. Furthermore, the procedure is dependent upon the given network topology. Thus, embodiments are not limited to, for example, a linear topology, but it may equally possibly be used in the presence of other network topologies, for example a ring or star topology. Furthermore, the communication configuration is simplified by the procedure. It is also possible to simplify the engineering of control applications; for example, an automatic communication configuration is possible without engineering and the control information may be simplified for field bus applications.

It is possible to identify whether a stream exists between one receiver and a plurality of transmitters if exactly one stream ID is present and a plurality of transmitters data transmit data via the one stream with the one ID to the one receiver. The same stream destination address may be used for the data from a plurality of transmitters.

It is possible to establish in a network a plurality of streams via which in each case data may be exchanged in a group of communication partners formed by exactly one receiver and two or more transmitters, e.g. a plurality of streams in the manner according to one or more of the present embodiments with listener advertise and talker join(s).

Embodiments provide a method for data communication in a network, for example in an industrial network with one or more nodal points with which a stream is established between a plurality of transmitters and one receiver and/or data is sent by a plurality of transmitters to one receiver via a stream.

Embodiments also provide a control method for an industrial technical process or a vehicle with which data are exchanged between at least two components of a control system, for example one or more sensors of an industrial automation plant or a vehicle as a transmitter and a controller, in particular a PLC of an industrial automation plant or a vehicle as a receiver, while carrying out the method for data communication and the industrial technical process or vehicle is controlled based on the exchanged data.

Embodiments further provide an apparatus including at least one, preferably more, nodal point(s), bridges, and/or at least one terminal(s) in each case forming a transmitter, sensors, and/or a device forming a receiver, for example, a controller in an industrial automation plant or a vehicle. The apparatus is configured to carry out the method for data communication or the control method.

The apparatus may, for example, represent part of a control system for an industrial technical process.

Embodiments further provide a computer program including program code for carrying of the steps of the method for data communication or of the control method and a computer-readable medium including instructions, that, when executed on at least one computer, prompt the at least one computer to carry out the steps of the method for data communication or the control method.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 depicts an example schematic partial representation of an industrial network in which a transmitter transmit data to a plurality of receivers via a stream.

FIG. 2 depicts an example schematic partial representation of an industrial network in which a receiver receives data from a plurality of transmitters via a stream.

FIG. 3 depicts an example schematic representation of a bridge on which two listener statuses are merged.

FIG. 4 depicts an example schematic representation of a bridge on which two talker statuses are merged.

FIG. 5 depicts an overview with new example data objects.

FIG. 6 depicts an example schematic representation with the accumulated stream type and the multiplexed stream type.

DETAILED DESCRIPTION

FIG. 1 is a schematic partial representation of an industrial Ethernet-based network. Specifically, a terminal may be identified, that represents a transmitter/talker 1 and that is connected via a plurality of bridges 2, only four of which are depicted in FIG. 1, to a plurality of further terminals, that in each case represent a receiver/listener 3. Three of the receivers 3 may be identified in FIG. 1. The three dots on the right of the figure are intended to indicate that the top bridge 2 is followed by further bridges 2 and terminals.

As may be derived from FIG. 1, in the embodiment depicted, the Ethernet-based network with the plurality of bridges 2 is characterized by a linear topology. It is also possible for another network topology to be provided, for example a tree, star or ring topology.

The terminal forming the transmitter 1 is a PLC in an industrial automation plant and the terminals forming the receivers 3 are actuators of the automation plant, that require control signals from the PLC in a cyclic manner in order to act on a technical process, that is not depicted in the figures, in a cyclic manner.

The 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 in the form of frames, that are transmitted via stream in the network is known, for example, from the AVB and TSN standards and provides compliance with a prespecified latency, that may vary from stream to stream, and depends on the respective application. The control signals arrive at the actuators 3 within a predetermined maximum latency, e.g. there is a maximum latency between the injection of the data into the network by PLC 1 and the arrival of the data at the actuators 3. It is possible to provide a real-time critical communication between the PLC 1 and the actuators 3.

A stream, such as that 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, is established with reference to the associated Stream Reservation Protocol (SRP). However, it is possible to receive exclusively a stream between one transmitter and one receiver or also a stream between one transmitter and a plurality of receivers. The latter configuration corresponds to that in FIG. 1.

For the establishment of a stream between the PLC 1 and the actuators 3, a reservation is made with SRP on each of the bridges 2 lying on the network path between the PLC 1 and the respective actuator 3, e.g. via which they are connected. In a first step, the stream is announced by the PLC 1, that represents the data source that is also called a talker, with a talker advertise and the properties of the stream are described by the PLC 1 forming the talker. The PLC 1 specifies a stream ID, a routing address and broadband information for the data transfer outgoing therefrom.

The announcement of the stream is distributed to all the nodal points, e.g. in the present case bridges 2, in the network. Then every bridge 2 carries the information of the receiving port, e.g. the ports in the direction of the talker 1, via which the announcement was received and the data will also be received later. Since, according to the prior art, the data source is also called a talker 1, the port is also called a talker port. Correspondingly, the ports in the direction of the listener(s) are also called transmitter ports or listener ports.

One or more listeners, e.g. the actuators 3, are registered on the stream offered by the PLC 1.

On the bridges 2 lying between the talker 1 and the respective listener 3, in each case a reservation is made on the port in the direction of the listener, e.g. the listener port according to the stream description specified by the PLC 1 representing the talker as long as the available resources on the respective bridge 2 suffice. Each nodal point 2 checks whether internal resources are sufficient for the performance required in the context of the stream to be established (for example, with respect to the data volume and data throughput). If the internal resources are sufficient, the nodal point 2 reserves these resources for the stream to be established and forwards a positive reservation status to the next bridge 2 or the last bridge to the transmitter 1.

By the reservation, each nodal point 2 is able to provide the required performance during the subsequent data transfer which is where streams differ from unprotected connections.

If insufficient resources are available, a negative reservation status is forwarded.

The reservation starts at the bridge 2 lying closest to the respective receiver/listener, e.g. actuator 3, and is “propagated” along the respective network path to the data source/talker, e.g. the PLC 1. The reservation of resources in the bridges 2 takes place in the opposite direction to the routing of the control signals from the PLC 1 to the actuators 3, that will take place the stream if the reservation at the bridges 2 was successful. In FIG. 1, the direction of the later data transmission is indicated by arrows 4 and block diagram elements designated 5 lying thereabove representing the routed frames purely schematically.

The reservation is based on the routing tree, also called the talker tree, that may be constructed using the Rapid Spanning Tree Protocol (RSTP).

At the bridges 2, that form branches, e.g. have to route data via two listener-side ports, there is a “merging” of the incoming listener reservation statuses that is implemented via the “status merge” function of the reservation protocol used.

FIG. 3 is a schematic representation of a bridge 2 of the ports of which two listener-side ports 6 and one talker-side port 7 may be identified.

The “listener status merge” function depicted schematically by a block diagram element in the direction of the talker 1 is designated 8. Arrows designated 9 further represent the (merged) listener reservation status arriving via the listener-side ports 6 and exiting via the talker-side port 7. If only successful reservations (listener ready) arrive at the listener-side ports 6, a successful reservation (listener ready) is forwarded to port 7. If at least one successful reservation (listener ready) and at least one failed reservation (listener asking failed—for example due to insufficient resources at a bridge located behind port 6), a listener ready failed is forwarded as a merged status. In the case of only failed reservations (listener asking failed), a failed status (listener asking failed) is forwarded.

Also indicated schematically in FIG. 3 is the direction of the frame routing, e.g. the data flow, with arrows 10. To provide the frames 5 provided by the PLC 1 to be routed via both listener-side ports 6, 7 of the bridge 2 depicted, the frames 5 are duplicated (multicast).

The above-described procedure may be sued for real-time critical transmission of control signals from the PLC 1 to a plurality of actuators 3. A plurality of listeners may be supplied with data with only one stream with one stream ID providing a justifiable network outlay.

However, in addition to the situation shown in FIG. 1, according to which control signals are to be distributed from one terminal to a plurality of further network subscribers,—for example, in industrial applications—the reverse case also occurs, e.g. that data is to be transmitted from two or more sources to one (common) destination. For example, when, in an automation plant, actual values acquired by a plurality of sensors are to be transmitted in a real-time critical manner to a central controller, that in turn may be provided by a PLC 1.

The situation is depicted in FIG. 2. FIG. 2 depicts a schematic partial representation of an industrial Ethernet-based network. A terminal is provided by the PLC 1, that represents the receiver/listener, and a plurality of transmitters/talkers are present, as depicted a plurality of sensors 11 of which a total of three may be identified in FIG. 2. The industrial network with the bridges 2 and terminals in FIG. 2 is part of an embodiment of an apparatus for carrying out the method.

The network topology is depicted consistently in FIGS. 1 and 2 as the actuators 3 identifiable in FIG. 1 and the sensors 11 identifiable in FIG. 2 are in each case contained in a terminal, but alternative topologies may be used.

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

According to the prior art, for the transmission of actual values acquired with the sensors 11 to the PLC 1, it was necessary to establish a separate stream for each sensor 11. Correspondingly, the three sensors 11 identifiable in FIG. 2 would require separate streams, thus entailing a much greater outlay on network administration and processing compared with the situation according to FIG. 1.

In order to reduce the number of streams in a case in which data is to be sent from a plurality of sources/transmitters to exactly one destination/receiver, the present embodiments suggest a new type of reservation that provides a “multiple talker per listener” configuration so that the three transmitters 11 may only transmit data to the PLC 1 via a stream with one stream ID.

In a first act, the receiver, e.g. the PLC 1, issues a listener advertise message for the stream including a stream description and the listener advertise message is distributed via 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 the PLC 1 wishes to receive data via a stream. The information that the sensors 11 may provide actual values for the PLC 1 was provided in another way. In FIG. 1, this is also necessary in the prior art and may, for example, take place in the industrial environment during the programming of the PLC 1 and the IO modules.

After the PLC 1 has issued the listener advertise and has been distributed, each sensor 11 from which acquired actual values are to be transmitted to the PLC 1 issues a talker join message. In the embodiment depicted, all three sensors 11 send a talker join message. Then, a talker join reservation is made on the bridges 2 on the network path between the respective sensor 11 and the PLC 1 for each of the three sensors 11. The talker join message includes inter alia a stream ID and a reservation status.

Unlike the prior art, the reservation of resources in the bridges 2 prior art proceeds from the respective talker, e.g. respective sensor 11, in the direction of the one listener 1, e.g. in the same direction as the routing of the actual values from the sensors 11 to the PLC 1, that will take place via the stream, if the reservation at the bridges 2 was successful. Similarly, to FIG. 1, in FIG. 2, the direction of the later data transmission is indicated with arrows 12 and block diagram elements designated 13, 14, 15, 16 lying thereabove representing the routed frames purely schematically.

At the bridges 2, that form branches, e.g. at which data will arrive via two talker-side ports, the incoming talker reservation statuses are “merged”. Similarly, to the procedure described in connection with FIG. 1, this is achieved by the “status merge” function of the reservation protocol used. The reservation protocol used is extended by the new data objects listener advertise and talker join and uses the listener status merge function in known protocols previously known for the receivers/listeners since the actual reservation of resources at the nodal point or points may take place in the same way or similarly to the previously known procedure with one transmitter/talker and a plurality of receivers/listener.

Unlike the prior art, the talker statuses are merged in the direction of the listener tree to the exactly one receiver, e.g. the PLC 1.

The listener tree that is formed from the further new listener advertise data object of the extended reservation protocol used, is determined using the Rapid Spanning Tree Protocol. The tree originates from the stored port of the listener advertise.

The right side of FIG. 5 provides an overview of the new data objects listener advertise L_Advertise, talker join T_Join and the listener tree L_Tree resulting from the advertise, in each case in comparison with the corresponding data objects from the previously known standard, e.g. the talker advertise T_Advertise, listener join L_Join and talker tree T_Tree, shown in the left-hand half of FIG. 5. The brace marks the upper two new data objects.

FIG. 4 depicts the “merging” of the talker statuses purely schematically—and the “merging” of the listener statuses in a manner corresponding to FIG. 3 that once again depicts a bridge 2 of which two talker-side ports 17 and one listener-port 18 are depicted. Also depicted schematically by a block diagram element is the “talker status merge” function in the direction of the listener, e.g. the PLC 1, that is designated 19 in FIG. 4.

As also depicted in FIG. 4, the routing of both the talker reservation statuses and the data takes place in the same direction, in the direction of the one receiver, e.g. the PLC 1.

Also indicated schematically in FIG. 4 is the direction of the frame routing, e.g. of data flow, here with arrows 20, and the (merged) talker reservation status arriving via the talker-side ports 17 and exiting via the listener-side port 18, in each case with arrows 21. All the reservation statuses of all the talkers, e.g. sensors 11, that have joined the PLC 1 with the stream announced with the listener advertise are forwarded to the PLC 1 forming the logical root of the tree via the bridge 2 closest to the listener, e.g. the PLC 1. The merged reservation status arriving at the PLC 1 includes the information that a reservation of the transmitter-side ports 17 of all the bridges 2 on the network paths connecting the sensors 11 and the PLC 1 was successful, or that a reservation of the transmitter-side ports 17 of all the bridges 2 on the network paths connecting the sensors 11 and the PLC 1 was unsuccessful or that a reservation of at least one transmitter-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 transmitter-side ports 17 was successful.

If the talker reservation was successful for all the nodal points in question, e.g. all the bridges 2 on the listener tree, the actual data transfer may begin, e.g. the routing of the frames 13, 14, 15, 16 with actual values acquired by sensors 11.

The routing of the frames 13, 14, 15, 16 arriving from different sensors 11 via the two talker-side ports 17 at the bridge 2 via the one listener-side port 6, 7 may take place in different ways, for example according to the accumulated stream type or the multiplexed stream type. With the former type, all the sensors 11 may send a frame 13, 14, 15, 16 in a period. The sum of all the frames 13, 14, 15, 16 is reserved, e.g. a larger bandwidth is required. In the case of the multiplexed stream type, the coordination is such that, in each period only of the sensors 11 sends a frame, thus entailing a lower bandwidth requirement but a higher waiting time since it takes longer for all the sensors 11 to send their data one after the other. The stream type is part of the stream-description that was issued by the PLC 1 together with the listener-advertise.

FIG. 6 is a schematic depiction comparing the principle of the accumulated stream type with that of the multiplexed stream type. Specifically, the left side of FIG. 6 depicts by way of example for periods #1 to #4 and frames 13, 14, 15 that, with the accumulated stream type, the three frames 13, 14, 15 are transmitted in each period, that entails a larger bandwidth 22, and according to the multiplexed stream type in each period only one frame 13, 14, 15 is routed in each case. The bandwidth 22 corresponds to that of the largest frames 13.

Based on the actual values obtained, the PLC 1 may ascertain control signals in a manner that is known per se and/or the actual values may be used for evaluation purposes. The PLC 1 acts in particular inter alia on the basis of the actual values on the industrial technical process.

The above-described procedure offers advantages. The number of real-time flows, e.g. streams, in a network is reduced. It is no longer necessary for a separate stream to be established for each sensor 11 from which data is to be transmitted to the PLC 1, instead a plurality of sensors 11 are able to send data to a common destination via only one stream that entails reduced control overheads for the registration and reservation of the real-time stream and a reduced number of filter database entries in the node points 2 and the overheads are the same for both directions of the data transfer required for the closed-loop control. Furthermore, scalability is improved since more terminals, for example sensors/actuators 11, 3 may be supported. The procedure is furthermore independent of the given network topology and is not restricted to the linear topology depicted but may equally be used in the case of other network topologies, for example a ring topology or star topology. Furthermore, the communication configuration is simplified by the procedure. It is also possible for the engineering of control applications to be simplified, for example an automatic communication configuration without engineering is possible and the control information for field bus applications may be simplified.

It is to be understood that the elements and features recited in the appended claims may be combined in different ways to produce new claims that likewise fall within the scope of the present disclosure. Thus, whereas the dependent claims appended below depend from only a single independent or dependent claim, it is to be understood that these dependent claims may, alternatively, be made to depend in the alternative from any preceding or following claim, whether independent or dependent, and that such new combinations are to be understood as forming a part of the present specification.

While the present disclosure has been described above by reference to various embodiments, it may be understood that many changes and modifications may be made to the described embodiments. It is therefore intended that the foregoing description be regarded as illustrative rather than limiting, and that it be understood that all equivalents and/or combinations of embodiments are intended to be included in this description.

Claims

1. A method for data communication in a network, the method comprising:

establishing a stream for data transfer between a plurality of data providing transmitters and a receiver, the establishing of the stream comprising: issuing, by the receiver, a listener advertise message for the stream; and transmitting the listener advertise message to at least one nodal point in the network.

2. The method of claim 1, wherein the listener advertise message comprises a stream description.

3. The method of claim 1, wherein the network is an industrial network, the industrial network comprising one or more nodal points, the one or more nodal points comprising the at least one nodal point.

4. The method of claim 3, further comprising:

propagating the listener advertise message to all nodal points of the one or more nodal points in the network.

5. The method of claim 1, wherein transmitting the listener advertise message comprises transmitting the listener advertise message to the plurality of data providing transmitters, and

wherein the transmission of the listener advertise message to a respective transmitter of the plurality of data providing transmitters is via a nodal point or nodal points lying on a network path connecting the respective transmitter and the receiver.

6. The method of claim 1, further comprising sending, by at least one transmitter of the plurality of data providing transmitters that wishes to transmit data to the receiver via the stream, a talker join message, the sending of the talker join message comprising making a talker join reservation at nodal points on a network path between the at least one transmitter and the receiver.

7. The method of claim 6, wherein the at least one transmitter comprises a number of transmitters, and

wherein sending the talker join message comprises sending, by each of the number of transmitters, each wishing to transmit data to the receiver via the stream, a respective talker join message and making a respective talker join reservation at the nodal points on the network path between the respective transmitter and the receiver.

8. The method as claimed in claim 6, wherein the talker join message comprises a stream ID, a reservation status, or the stream ID and the reservation status.

9. The method of claim 1, wherein the network is an industrial network for an industrial automation plant.

10. The method of claim 1, further comprising:

merging, at the at least one nodal point, a reservation status of a first port in a direction of one or more transmitters of the plurality of data providing transmitters and a reservation status of a second port in a direction of one or more further transmitters of the plurality of data providing transmitters.

11. The method of claim 10, further comprising routing the merged reservation status via a port in a direction of the receiver

12. The method of claim 10, wherein a nodal point located closest to the receiver routes the merged reservation status for all transmitters of the one or more transmitters and the one or more further transmitters to the receiver, and

wherein the reservation status arriving at the receiver comprises information that a reservation of transmitter-side ports of all the nodal points on the network paths connecting the transmitters and the receiver was successful or that the reservation of the transmitter-side ports of all the nodal points on the network paths connecting the transmitters and the receiver was unsuccessful or that the reservation of at least one transmitter-side port of at least one nodal point on the network paths connecting the transmitters and the receiver was unsuccessful and the reservation of at least one transmitter-side port of at least one nodal point on the network paths connecting the transmitters and the receiver was successful.

13. The method of claim 1, wherein the reservation of resources at one or more nodal points, at least one reservation protocol that is extended by at least one data object is used, and

wherein at least one of the listener advertise message, the talker join message, and the talker join reservation represent data objects expanding the at least one reservation protocol.

14. The method of claim 1, further comprising:

determining, by a Rapid Spanning Tree Protocol, a network tree formed by network paths connecting the receiver to the at least one transmitter that wishes to send data to the receiver via the stream and from which in each case a talker join message was sent.

15. The method of claim 14, wherein the network tree determined represents a data object expanding the reservation protocol.

16. The method of claim 1, wherein the listener advertise message comprises a stream description specifying a stream type, and

wherein the stream type is specified as an accumulated stream or a multiplexed stream.

17. The method of claim 1, wherein the receiver is a PLC of an industrial automation plant or a vehicle, and the plurality of data providing transmitters are one or more sensors in the industrial plant or the vehicle, and

wherein the industrial technical process or vehicle is controlled based on the transmitted data.

18. A network comprising

at least one nodal point;

at least one terminal configured as a transmitter; and

a device configured as a receiver, the device configured to issue a listener advertise message to the at least one nodal point in the network,

wherein the stream is established for transmission of data between the at least one terminal and the device via the at least one nodal point, and

wherein the data is transferred by the at least one nodal point between the at least one terminal and device.

19. A control system for an industrial technical process, the control system comprising:

a controller; and

an industrial network with one or more bridges for data transfer between a plurality of sensors;

wherein the controller is configured to receive the data provided by the plurality of sensors via a stream with which, to establish the stream, the controller is configured to issue a listener advertise message for the stream,

wherein the listener advertise message comprises a stream description, and

wherein the listener advertise message is transmittable to the one or more bridges of the network.