Method for transmitting messages in an industrial

communication network of an industrial automation system and communication device for an industrial communication network

An industrial automation system usually comprises a multi ^¬ plicity of automation devices networked to one another via an industrial communication network and, within the scope of production or process automation, is used to control or regu ^¬ late installations, machines or devices. On account of time- critical boundary conditions in technical systems automated using industrial automation systems, real-time communication protocols such as Profinet, Profibus or real-time Ethernet are predominantly used in industrial communication networks for communication between automation devices.

Interruptions in communication connections between computer units of an industrial automation system or automation de- vices may result in undesirable or unnecessary repetition of the transmission of a service request. This causes additional utilization of communication connections of the industrial automation system, which may result in further system faults or errors. In addition, messages which have not been trans- mitted or have not been completely transmitted may prevent an industrial automation system from changing to or remaining in a safe operating state, for example. This may finally result in failure of a complete production installation and costly production downtime. A particular problem regularly results in industrial automation systems from message traffic with a comparatively large number of, but relatively short, mes ^¬ sages, thus intensifying the above problems. WO 2008/119649 Al discloses a method for reconfiguring a packet-switched communication network comprising a first subnetwork and a second subnetwork. Whereas a first network pro ^¬ tocol is used in the first subnetwork, a second network pro- tocol different from the first network protocol is used in the second subnetwork. Both subnetworks are connected to one another by means of at least three redundant data links, only one of which is respectively activated for the purpose of in ^¬ terchanging useful data. In this case, a master data link is activated in a preset manner, while at least two slave data links are deactivated in a preset manner. Failure of the mas ^¬ ter data link or a slave data link is monitored by means of a master bridge of the second subnetwork, which master bridge is connected to the master data link. In the event of such failure, the master bridge generates a first data packet and transmits it to a slave bridge of the second subnetwork, which slave bridge is connected to a slave data link. The slave bridge is selected by the master bridge according to a predefinable selection rule. The first data packet is then processed by the selected slave bridge. The first data packet comprises logical information which is used to at least par ^¬ tially execute the first network protocol on a port of the slave bridge connected to the slave data link and to activate the slave data link using the first network protocol executed on the port of the slave bridge.

EP 2 343 857 Al describes a network node for a communication network comprising a first subnetwork and a second subnetwork connected to the latter. Whereas a spanning tree protocol is used in the first subnetwork, a second protocol which differs from the protocol of the first subnetwork is used in the sec ^¬ ond subnetwork. The network node is set up as an element for the second subnetwork and is designed for communication inside the second subnetwork. In addition, the network node is designed and set up as a spanning tree main node for monitor ^¬ ing and controlling the second subnetwork by means of a spanning tree functionality. The second subnetwork can therefore be treated as a virtual network node by the spanning tree protocol used in the first subnetwork by virtue of the net ^¬ work node, as the spanning tree main node, applying a spanning tree protocol for other network nodes of the second sub ^¬ network . WO 2010/105828 Al discloses a method for operating a communi ^¬ cation network which has redundancy properties and has a ring network topology. Inside the communication network, the data ports of communication devices are connected to one another via data lines and said communication devices interchange control data and useful data via the data lines on the basis of communication protocols. In order to avoid endless circu ^¬ lation of messages in meshes of the communication network, the communication protocols are used to prevent transmission of messages via selected data ports of individual communica- tion devices, with the exception of messages for controlling or monitoring media redundancy. Two different communication protocols are used in a parallel manner in the communication devices inside the communication network. Parallel use of the different communication protocols is achieved, for example, by allocating control of data ports to be blocked to an indi ^¬ vidual communication protocol. Alternatively, parameters may be selected for the communication protocols in such a manner that a first communication protocol does not block any con ^¬ nections which are considered to be active in accordance with a second communication protocol.

The present invention is based on the object of specifying a method for transmitting messages in an industrial communica ^¬ tion network which allows for an efficient routing in time sensitive networks, and of providing a communication device suitable for carrying out the method.

This object is achieved, according to the present invention, by a method having the features stated in claim 1 and by a communication device having the features stated in claim 11. Advantageous embodiments of the present invention are stated in the dependent claims. In accordance with the method according to the invention, messages are transmitted within a multicast data stream from at least one source network node to a plurality of destina ^¬ tion network nodes of the industrial communication network. Each multicast data stream is associated with a data stream identification, a specification of source and destination network nodes, and a multicast network address. Moreover, upon connection with a multicast data stream, source and des ^¬ tination network nodes each transmit a stream connection announcement to neighbour network nodes by means of a message comprising updated network topology information according to a link-state routing protocol. Based on a received stream connection announcement, switch network nodes of the indus ^¬ trial communication network each recalculate its respective routing table comprising information for forwarding messages. Switch network nodes may comprise e.g. routers, switches or bridges. Preferably, routing tables are calculated for multi ^¬ cast data streams only.

A link-state routing protocol is commonly used in packet switching networks by network infrastructure devices. Exam ^¬ ples of link-state routing protocols are open shortest path first (OSPF) and intermediate system to intermediate system (IS-IS) . Usually, the link-state routing protocol is per ^¬ formed by every switching network node in a communication network. Basically, every network node derives a connectivity map of the communication network from link-state advertise ^¬ ments transmitted by other network nodes. These connectivity maps preferably show which network nodes are connected with each other. The link-state advertisements may be implemented by short messages sent periodically or in case of connec ^¬ tivity changes, respectively and identify the originating network node as well as all other network nodes to which it is directly connected. Preferably, each network node inde- pendently calculates next best logical paths originating from the respective network node to every possible destination network node resulting in a routing table of the respective network node. According to an advantageous embodiment of the present inven ^¬ tion, said stream connection announcement comprises a speci ^¬ fication of an originating network node transmitting the stream connection announcement. Moreover, said stream connection announcement may comprise information on a respective role of the originating network node as a source network node or as a destination network node, and the respective data stream identification. The data stream identification may be e.g. a unique identifier of the respective multicast data stream according to standard IEEE 802.1Q AVB .

According to another advantageous embodiment of the present invention, said stream connection announcement additionally comprises the multicast network address of the respective multicast data stream. Furthermore, said stream connection announcement may also comprise a traffic specification ac ^¬ cording to standard IEEE 802.1 AVB.

According to yet another advantageous embodiment of the pre ^¬ sent invention, said stream connection announcement comprises b a specification of a plurality of multicast data streams the originating network node is connected with. Moreover, said stream connection announcement may also comprise a specifica ^¬ tion of a virtual local area network which the originating network node is associated with, wherein the multicast net ^¬ work address is unique within the respective virtual local area network.

According to a preferred embodiment of the present invention, said source network node transmits a stream connection an ^¬ nouncement for notifying other network nodes of an available multicast data stream. Thereby, destination network nodes subscribe to an available multicast data stream by means of corresponding stream connection announcement.

In accordance with the communication device according to the invention for carrying out a method as described above, the communication device comprises a plurality of network ports for a respective connection with further communication de- vices within the industrial communication network, and a switching element selectably connecting the network ports with each other. The communication device is set up and configured to transmit messages within a multicast data stream from at least one source network node to a plurality of des- tination network nodes of the industrial communication network. Each multicast data stream is associated with a data stream identification, a specification of source and destination network nodes, and a multicast network address. Upon connection with a multicast data stream, source and destina- tion network nodes each transmit a stream connection announcement to neighbour network nodes by means of a message comprising updated network topology information according to a link-state routing protocol. Thereby, the communication de ^¬ vice is set up and configured to, based on a received stream connection announcement, recalculate its routing table com ^¬ prising information for forwarding messages.

The present invention is explained in more detail below using an exemplary embodiment with reference to the drawing, in which figure 1 shows an industrial communication network with a plurality of network nodes acting as source or des- tinations of a multicast data stream, figure 2 shows a schematic representation of a stream connection announcement, figure 3 shows a schematic representation of a stream con ^¬ nection announcement comprising an available traf ^¬ fic specification flag, figure 4 shows a schematic representation of a traffic

specification as a separate data entity, figure 5 shows a schematic representation of a traffic

specification as a separate data entity with multi ^¬ ple stream identifiers per traffic specification.

The industrial communication network shown in figure 1 comprises a plurality of network nodes 101-115 whose associated communication devices have individual communication func ^¬ tions. In the present exemplary embodiment, network node 106 represents a source network node of a multicast data stream, whereas network nodes 101-102, 110, 114-115 represent desti ^¬ nation network nodes of the multicast data stream. Moreover, the communication devices associated with network nodes 103- 105, 107-109, 111-113 show a switching or routing communica- tion function, respectively. This also applies to source net ^¬ work node 106 and to destination network node 110 which have multiple communication functions according to the present ex ^¬ emplary embodiment.

The communication devices associated with network nodes 103- 113 each comprise a plurality of network ports for a respec ^¬ tive connection with further communication devices within the industrial communication network, and a switching element se- lectably connecting the network ports with each other. Each communication device is set up and configured to transmit messages within the multicast data stream from source network node 106 to destination network nodes 101-102, 110, 114-115. Generally, each multicast data stream is associated with a data stream identification, a specification of source and destination network nodes, and a multicast network address. Upon connection with the multicast data stream, source node 106 and destination network nodes 101-102, 110, 114-115 each transmit a stream connection announcement to neighbour net- work nodes by means of a message comprising updated network topology information according to a link-state routing proto ^¬ col. Moreover, the communication devices associated with net ^¬ work nodes 103-113 are each set up and configured to, based on a received stream connection announcement, recalculate its respective routing table comprising information for forwarding messages within the industrial communication network.

Generally, the present invention is applicable to any link- state routing protocol, although exemplary embodiment will be based on IS-IS as basic link-state routing protocol of Short ^¬ est Path Bridging (SPB) . Hereinafter, source network node 106 is referred to as talker within the multicast data stream, whereas destination network nodes 101-102, 110, 114-115 are referred to as listeners. A multicast data stream can be de- scribed by several different attributes, amongst which are as an example:

- network-wide unique stream ID,

- talkers of the stream,

- listeners of the stream,

- multicast or stream MAC address as destination MAC or group address,

- traffic specification (TSpec) , if available. Data transmitted within a stream connection announcement re ^¬ lating to a the multicast data stream may comprise:

- identifier of the network node originating the stream connection announcement,

- role of the network node originating the stream connec- tion announcement, e.g. talker or listener,

- identifier of the multicast data stream.

The identifier of the network node is usually represented by a MAC address of the node or by the MAC address of an inter- face of this node. The role of the node is usually repre ^¬ sented by one or more flags. In case of a single two-value flag, one value indicates the node is a talker and the other value indicates the node is a listener. A single two-value flag may be used for uni-directional streams. In case of two two-value flags, one flag indicates whether the node is a talker or not and the other flag indicates whether the node is a listener or not. This allows for uni-directional streams as well as for bi-directional streams. Alternative represen ^¬ tations for the role of the node may be separate data struc- tures, e.g. type-length-values (TLVs) in the messages that are specific for talkers and listeners. TLVs can be distin ^¬ guished by different data structure identifiers such as a type. Moreover, the identifier of the stream has to be unique within the network and may be represented by:

- unique stream ID, e.g. according to IEEE 802.1Q AVB, clause 35.2.2.8.2,

- stream MAC address as a network-wide unique multicast

MAC address to which the frames of the stream are sent.

Generally, it is sufficient to have at least one network-wide unique identifier of a stream. However, it is also possible to have multiple identifiers of a stream, e.g. the unique stream ID for stream management and accounting on the one hand and the stream MAC address for communication aspects on the other hand.

Usually, messages for distributing link-state information have a very flexible structure. A message itself is only a container for a set of flexible data structures that contain the actual information. Such flexible data structures are e.g. TLVs . Also the information of the stream connection announcement can be structured as a TLV. Depending on applica ^¬ tion-specific requirements, such a TLV may contain data only for a single stream connection or for multiple stream connections of the same node or even of different nodes. This choice is not limiting functionality, since multiple stream connections can always be represented by multiple TLVs within the same message.

The representation of a stream connection announcement shown in figure 2 is based on a TLV concept according to link-state routing protocol IS-IS. In addition to traditional TLVs, IS ^¬ IS also defines sub-TLVs contained inside the structure of a TLV. Generally, a stream connection announcement can be rep ^¬ resented in TLVs or sub-TLVs. For simplicity of illustration and explanation, stream connection announcements are hereinafter represented by TLVs .

In a header section 200, the stream connection announcement TLV according to figure 2 comprises a type field 201, a length field 202, a node MAC address field 203 relating to the node originating the stream connection announcement, a reserved field 204, a base ID field 205, and a field 206 for the number of announced stream connections starting from or ending at the originating node. By means of the type field

201, the TLV according to figure 2 can be identified as data structure comprising a stream connection announcement. The length field 202 serves to determine the length of the stream connection announcement TLV.

For each stream connection starting from or ending at the node originating the stream connection announcement, a stream connection section 210, 220 is provided within the stream connection announcement TLV. The stream connection sections 210, 220 contain stream connection tuples each comprising a talker flag 211, 221, a listener flag 212, 222, a reserved field 213, 223, a unique ID field 214, 224, and a stream MAC address field 215, 225. The talker flag 211, 221 and the listener flags 212, 222 determine whether the respective node is a talker or a listener for the stream identified by the unique stream ID or the stream MAC address, respectively. Preferably, stream connec ^¬ tions are identified by means of the unique stream ID as de- fined in IEEE 802.1Q AVB and the stream MAC address. Based on the stream MAC address, frames of stream connections are for ^¬ warded to their destinations. The link-state routing protocol has to setup paths for the stream MAC address based on the talkers and listeners received in the stream connection an ^¬ nouncement TLVs .

The role of the respective node may be a mixture of talker and listener. In this case, talker and listener connection relations can be announced in the same stream connection an ^¬ nouncement TLV. An alternative would be to have separate TLVs for talker stream relations of the node and listener stream relations of the node. In this case, the role of the node needs to be contained in the TLV only once or can be encoded in the TLV type.

The base ID field 205 contains an identifier for a virtual local area network (VLAN) , especially for application cases with multiple virtual LANs within a physical network. A base ID is an optional parameter designed for limiting the scope of the stream MAC address to a single virtual LAN so that the stream MAC address has to be unique only within a single vir ^¬ tual LAN. Without the base ID, the scope of the stream MAC address would be the physical network and the stream MAC ad ^¬ dress had to be unique over multiple virtual LANs.

The number of announced stream connections is an optional pa ^¬ rameter, since the last stream connection section within the stream connection announcement TLV can be determined by means of the length of the stream connection announcement TLV. However, an explicit number of announced stream connections, is preferred since it provides extensibility for the stream con ^¬ nection announcement TLV. Thus, the recipient of the stream connection announcement TLV will recognize the last stream if there are further bytes in the remaining TLV-value, even if those bytes are unspecified to the recipient. In a further exemplary embodiment, the stream connection announcement TLV can contain stream connections of different network nodes. In this case, the node MAC address field 203 is moved from the header section 200 to the respective stream connection section 210, 220. Alternatively, the node MAC ad ^¬ dress field 203 remains in the header section 200 and each of stream connection sections 210, 220 comprises an additional flag that indicates whether the node MAC address for the re ^¬ spective stream connection is given in the header section 200 or whether it is given in an additional node MAC address field within the respective stream connection section 210, 220. The flag for the node MAC address field also indicates the existence or validity of the node MAC address field within the respective stream connection section. In fact, the node MAC address field within the respective stream connec ^¬ tion section 210, 220 might be omitted, in order to reduce the number of transmitted bytes. Moreover, the node MAC ad ^¬ dress field within the respective stream connection section 210, 220 might be simply not used, if the node MAC address is taken from the header section 200.

In a yet another exemplary embodiment, that is independent from the previous exemplary embodiments, the stream connec ^¬ tion announcement TVL is enhanced with the traffic specifica- tion of the corresponding stream. There are two major ways of doing this, other variants are also possible. Note, the traf ^¬ fic specification of a stream can also be called a stream description. One major way is to add fields for the traffic specification to the stream connection specification in the stream connection announcement TLV. This means that the stream connection announcement TLV contains both the stream connection of the node as well as the corresponding traffic specification of the respective stream. Another way to enhance the stream connection announcement TVL with the traffic specification consists in providing a separate traffic speci ^¬ fication TLV. This traffic specification TLV contains one or more traffic specifications of streams. The traffic specifi ^¬ cation TLV can be associated with the corresponding stream connection announcement TLV by means of the unique ID or the stream MAC address.

In case of using a traffic specification, the stream connection announcement TLV comprises at least one additional flag that indicates whether a traffic specification is available for a stream connection. This flag indicates the existence of a traffic specification within in the stream connection announcement TLV or within a traffic specification TLV. Such an indication might be valid for an entire stream connection an- nouncement TLV or only for a single stream connection section. Figure 3 shows a representation of a stream connection announcement TLV with an additional traffic specification flag 216, 226 in each stream connection section 210, 220. The traffic specification contains parameters that describe and define the traffic characteristics of a stream, such as:

- traffic specification (TSpec) according to IEEE 802.1 AVB, clause 35.2.2.8.4] or a subset of the parameters of such a traffic specification,

— priority,

- rank,

- latency,

- redundancy, e.g. singl- path or multi-path, rerouting,

- stream class,

- status, e.g. reservation status for stream,

- application-specific data,

- data from higher layers, e.g. IP layer,

- service information. Additionally, the traffic specification is associated with an identifier of the respective stream, e.g. stream MAC address. Therefore, a traffic specification section within a traffic specification TLV comprises at least two fields:

- identifier of stream,

- traffic specification.

Figure 4 shows a representation of a traffic specification TLV as a separate data entity in addition to the stream con ^¬ nection announcement TLV. In a header section 300, the traffic specification TLV comprises a type field 301, a length field 302, a reserved field 303, a base ID field 304, and a field 305 for the number of traffic specifications. By means of the type field 301, the TLV according to figure 4 can be identified as data structure comprising a traffic specifica ^¬ tion. The length field 302 serves to determine the length of the traffic specification TLV. For each traffic specification, a traffic specification section 310, 320 is provided within the traffic specification TLV. The traffic specification sections 310, 320 contain traffic specification tuples each comprising a stream MAC address field 311, 321 and a field 312, 322 for traffic speci- fication parameters as mentioned above.

The number of traffic specifications is an optional parame ^¬ ter, since the last traffic specification section within the traffic specification TLV can be determined by means of the length of the traffic specification TLV. However, an explicit number of traffic specifications, is preferred since it pro ^¬ vides extensibility for the traffic specification TLV. Thus, the recipient of the traffic specification TLV will recognize the last traffic specification if there are further bytes in the remaining TLV-value, even if those bytes are unspecified to the recipient. The base ID field 304 contains an identifier for a virtual local area network (VLAN) , especially for application cases with multiple virtual LANs within a physical network. A base ID is an optional parameter designed for limiting the scope of the stream MAC address to a single virtual LAN so that the stream MAC address has to be unique only within a single vir ^¬ tual LAN. Without the base ID, the scope of the stream MAC address would be the physical network and the stream MAC ad ^¬ dress had to be unique over multiple virtual LANs. In a further exemplary embodiment, the traffic specification TLV according to figure 5 comprises traffic specification sections 310, 320 that can contain multiple stream MAS ad ^¬ dress fields 311, 321 associated with the same field 312, 322 for the traffic specification. Additionally, the traffic specification sections 310, 320 according to figure 5 com ^¬ prises a field 313, 323 for the number of stream MAC ad ^¬ dresses which can be used for control and validation purposes. Listeners do not need to generate a traffic specification TLV that describes the traffic specification parameters of the respective stream they are or aim to be connected with. This is because a traffic specification TLV will be received by all network nodes, since the respective talker distributes its stream information in the network.

At some point in time, a network node will be configured with a stream connection, that is, as a talker or listener to one or more streams. Such a configuration might be done manually, by a network management or configuration software, by some centralized or distributed configuration algorithm, or by other means . If a network node has been configured with a stream connec ^¬ tion, the network node constructs the corresponding stream connection announcement TLVs . If traffic specifications are used, the network node also constructs the corresponding traffic specification TLVs, if available. These TLVs are added to the control messages of the link-state routing pro ^¬ tocol that distribute the link-state in the communication network .

If a network node receives stream connection announcement TLVs or traffic specification TLVs, it propagates these TLVs in the same way as it propagates the link-state information of the routing protocol. Eventually, all nodes of the commu ^¬ nication network will have received the information about the stream connections.

The order of the stream connection information for talkers and listeners does not matter. The stream connection informa ^¬ tion is distributed to all network nodes, and the routing process starts to compute the paths if it has the MAC ad- dresses of the talkers and the MAC addresses of the listen ^¬ ers .

Moreover, the described exemplary embodiments can also be used for an announcement-subscribe scheme for streams. In a first step, a talker announces an available stream with the corresponding traffic specification to the network that is to all network nodes. This is done by constructing the corre ^¬ sponding stream connection announcement TLV, and the corresponding traffic specification TLV, if available and used. These TLVs are then added to the control messages of the link-state routing protocol that distribute the link-state in the communication network. In a second step, any network node which wants to become a listener to the stream announced by the talker, sends a corresponding stream connection announcement TLV in the control messages for the distribution of the link-state information. The Node MAC Address field is set to the MAC address of the node which wants to become a listener. Preferably, the talker flag is unset, whereas the listener flag is set. Additionally, the stream MAC destination field is set to the multicast MAC address of the stream to which the node wants to listen. Also the unique ID field, if avail ^¬ able, is set to the corresponding value of the stream to which the node wants to listen.

Eventually, all network nodes know the talkers and listeners for the stream with a certain stream MAC address and the routing process on the network nodes can compute the paths and forwarding information for the forwarding of the frames of the stream.

Each network node can now compute the forwarding paths for the streams based on the received link-state information, stream connection information, and traffic specification in- formation, if available. The independently computed forward ^¬ ing paths are consistent because the network nodes have the very same information on the network topology and stream information. This is also supported by using the same distribu ^¬ tion mechanism for all this information. This same distribu- tion mechanism is the distribution of the link-state informa ^¬ tion by the routing protocol.

The TLVs according to the described exemplary embodiments might be distributed only once at the configuration phase or might be distributed repeatedly, e.g. periodically or always. They might be also distributed after changes to the topology or changes, respectively, to the stream connections. The information distributed according to the described exem ^¬ plary embodiments is required for routing, especially the stream connection information for multipath routing, where often not all paths but only the required paths are calcu ^¬ lated. By re-using the distribution methods of the link-state information, all the information intended for the routing function is distributed by the same mechanism. This simpli ^¬ fies the handling of the distribution of this information.

The combination of stream connection and stream traffic specification allows considering the traffic requirements of the stream already in the routing process. This allows the application of traffic engineering in networks deploying the described exemplary embodiments. The distributed information on the stream connections and traffic specification includes the routable stream MAC ad ^¬ dress. This allows using the distributed information for the routing process without any further lookups. There is no need to take the stream ID and to look up the stream MAC address for this stream ID in some database.

Furthermore, the use of the routable stream MAC address in the stream connection information and the traffic specification allows the use of arbitrary multicast or group addresses for the streams and their simple announcement within the net ^¬ work. There is no need to derive the stream MAC address based on a specified rule from some other stream identifier in order to have a consistent mapping between the stream and its stream MAC address. There is also no need for a separate pro- or distributing the mapping between streams and their MAC addresses.