Method, device and system for sending messages in a network

Abstract

The invention relates to a method for sending a message in a network having a communication mode involving a publisher device and a subscriber device on the network, the method comprising: extracting a payload of a received message (dataset message) and concatenating said payload within a same combined message; adding a header to said combined message, said header comprising a single identifier of the publisher device (publisher ID = k), said publisher identifier being predetermined in order to send the combined message to at least one selected subscriber device.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to a method, device and system for sending messages in a network having a communication pattern involving publisher devices and subscriber devices on the network. BACKGROUND

[0002] The Open Platform Communications Unified Architecture (OPC UA) is widely used for flexible best effort communication in automation, gradually replacing OPC Classic as well as many vendor specific protocols. OPC UA is designed to enable uniform standardization and secure communication across application domains and automation control levels.

[0003] Based on the principle of publish / subscribe data exchange (hereinafter referred to as “PubSub”), the OPC UA specification is extended by communication, opening up new usage scenarios, including “many-to-many” communication. In addition, the integration of OPC UA PubSub with Time-Sensitive Networking (TSN) is designed to enable communication with critical real-time requirements.

[0004] Further details on OPC UA are shown below. OPC UA is a client-server protocol for industrial communication over TCP / IP, standardized as IEC 62541. An OPC UA server provides access to data and functions structured in an object-oriented information model. Clients interact with the information model using a set of standardized services. Each service defines request and response messages for the interaction. However, a subscription mechanism can also be used to push notifications only when a notification occurs.

[0005] Further details on so-called “Time-Sensitive Networking (TSN)” are given below. In the IEEE 802.1 standard family, the Ethernet enhancements for real-time communication (originally developed as Audio Video Bridging (AVB)) were recently extended to Time-Sensitive Networking (TSN). The clock synchronization scheme specified in IEEE 802.1 AS and the transmission of capacity through time slot reservation by IEEE 802.1 Qbv are basic standards used in automation networks with real-time constraints.

[0006] Industrial communication traffic types have been defined to meet different common use cases in industrial applications, including their relationship to the TSN standards. The introduction of TSN in industrial communication brings some technical and performance improvements in addition to the benefits of providing an open standard framework:

[0007] • potentially higher throughput,

[0008] • flexibility to mix connections with differentiation and guaranteed quality of service through multi-hop in bridged networks,

[0009] • Economies of scale for a broad technology for industrial use cases and consumer devices.

[0010] The "publish / subscribe" mechanism in OPC UA allows many subscribers to register for a topic, and published messages are forwarded to all subscribers of the message topic. This feature allows many subscribers to receive the same message in a similar way as the communication schemes implemented in traditional fieldbuses. The content of the published message is defined by a so-called Published dataset, which represents a collection of variables and event sources in the information model of an OPC UA server. The Published dataset can be configured flexibly and its description can be looked up in the server to interpret the semantics of the published information.

[0011] The OPC UA standard specification (section 14) defines a mapping of OPC UA PubSub to existing publish / subscribe protocols, in particular MQTT (Message Queue Telemetry Transport) and AMQP (Advanced Message Queuing Protocol). These protocols define a central broker for message distribution and are typically used in the public internet. The standard also defines a custom distribution protocol based on UDP and a corresponding message layout (UADP), which relies on the multicast mechanism provided by the IP standard. When using UADP, the subscriber registration identifies a multicast group by a specific IP multicast address.

[0012] This transmission with binary encoded messages is well suited for production environments with frequent transmission of small amounts of data. PubSub messages sent to this address are forwarded to all members of the group. This mapping delegates a large part of the publisher complexity to the existing network infrastructure (routers, switches, etc.). Finally, the standard also defines the transmission of PubSub messages with the same UADP layout directly over the data link layer (i.e. Ethernet).

[0013] In this configuration, OPC UA PubSub can be integrated with TSN for real-time transmission, and Ethernet frames carrying the UADP payload are identified by a specific Ethernet type (0xB62C). This mapping to Ethernet TSN opens the possibility for a very lightweight OPC UA PubSub implementation that assumes a fixed Published dataset and directly generates the required network messages without the software and network switching overhead to discover the OPC UA server.

[0014] More details on the Pub / Sub principles in OPC UA are given below. A dataset constitutes the payload of a message provided by a publisher and consumed by a subscriber. Publisher and subscriber are loosely coupled, their main relationship is a shared understanding of a dataset s, the publishing characteristics of messages including these data and the message-oriented middleware. PubSub messages are called network messages. They include:

[0015] - header information (e.g. identifiers and security data), and

[0016] - one or more dataset messages (payload).

[0017] Each dataset message is created from a dataset. A component of the publisher called dataset writer generates a continuous sequence of dataset messages. The syntax and semantics of a dataset are described by the dataset metadata. The information and data collection parameters selected for a dataset in the publisher are called a Published dataset.

[0018] Figure 1 These different roles and entities are shown. A dataset is created from an event or a variable value sample. The configuration of the application data collector is called a Published dataset. A dataset field can represent: an internal variable in the publisher, an event from or collected by the publisher, network data or data from a child device. The structure and content of a dataset are defined by the dataset metadata.

[0019] For publication, a dataset is encoded into a dataset message, which can be further combined with other dataset messages to form the payload of a network message, as shown in Figure 2 The dataset writer is configured to encode and transmit dataset messages containing dataset data. The way a dataset is configured and the data is acquired for publication can be configured using the PubSub configuration model defined in the OPC UA PubSub standard specification.

[0020] Figure 3 The different layers in network message construction are shown, including dataset message fields, dataset messages, network messages and transport protocols.

[0021] A dataset message field can be defined as a representation of a specific dataset field in a dataset message. A dataset field contains the actual value as well as additional information associated with the value, such as status and timestamp. A dataset message is generated from a dataset and includes the encoded fields of the dataset and a header. Depending on the configuration, the dataset message header can contain additional information, such as:

[0022] - an identifier dataset writer Id, which identifies the dataset writer and indirectly the Published dataset,

[0023] - sequence number,

[0024] - timestamp,

[0025] - version ID,

[0026] - "keep-alive" status.

[0027] The dataset metadata (as a data contract) defines the fields contained in the dataset message. The header settings of the dataset message and the network message define the communication contract between the publisher and the subscriber. The network message is a container for the dataset message, which includes a header that conveys information common to the dataset message:

[0028] - Publisher ID: identifies the publisher.

[0029] - security data: only applies to encodings that support message security.

[0030] The relevant information is specified in the message mapping.

[0031] - promoted fields: selected fields in the dataset are also sent in the header.

[0032] - payload: one or more dataset messages.

[0033] The payload, which includes the dataset message, can be encrypted according to the configured message security. Individual fields of the dataset message can be "promoted" to "escape" encryption, so they can be used for filtering and forwarding. The configuration of the promoted fields depends on the network message format and the protocol used. In any case, the network message header is not encrypted to enable filtering and forwarding.

[0034] Now, regarding the entities involved in this message exchange, the publisher is the PubSub entity that sends the network message (as shown in Figure 2 ). It is an arbitrary entity and is not necessarily a specific network node (e.g., with a specific IP or MAC address) or application. The publisher is usually composed of one or more network nodes that send the message.

[0035] A single publisher can support multiple Published datasets and multiple dataset writers. The dataset writer is a logical component of the publisher. For message sending, the creation of the message starts from the dataset (dataset) to be published, and according to the Published dataset, the individual fields of the dataset are generated.

[0036] The dataset writers then create dataset messages from the datasets. Dataset messages from dataset writers belonging to the same writer group can be inserted into a single network message. The format and encoding of the dataset messages is fixed by some configuration parameters (not defined here).

[0037] The network message is created from the dataset messages, the dataset writer Id, the dataset category ID, the configuration version obtained from the dataset metadata and the publisher ID defined on the PubSub connection. The structure of the message is protocol specific.

[0038] The network message can be sent cyclically based on the publishing interval (Publishingln terval) associated with the writer group and from the start of each publishing interval with a given offset (PublishingOffset).

[0039] The subscribers are configured and / or use discovery mechanisms to determine which dataset messages to subscribe to and which message-oriented middleware to subscribe to. The unencrypted data in the network message header is used by the subscribers to identify and filter relevant publishers, dataset messages and dataset categories.

[0040] Once a dataset message is determined to be relevant, it is forwarded to the corresponding dataset reader in order to be decoded into a dataset. The resulting dataset is then further processed or dispatched within the subscriber.

[0041] The subscribers register to the distribution groups supported by the message-oriented middleware by establishing a connection (e.g. by joining a UDP multicast group or an Ethernet multicast group).

[0042] The subscribers dispatch the dataset messages of interest in the relevant network messages to each dataset reader, which decodes them into datasets using the information provided in the dataset metadata.

[0043] Figure 4 The relationship between the PubSub components and their role in the creation of different message encoding phases is outlined. The following description can be given as an example in the context of UADP encoding of messages that can be transported on UDP / IP or Ethernet, relative to the PubSub message mapping. The UADP message mapping defines different optional header fields, field settings as well as different message types and data encodings.

[0044] The generic UADP network message layout is shown in Figure 5 According to the PubSub communication configuration parameters, different headers and fields are present or not. When security is used, the payload and padding fields will be encrypted and the whole network message is signed if signing and encryption are configured to be active. The network message is only signed when signing is active.

[0045] Figure 6 A general format of the payload and the payload header of the network message is further illustrated. Here, the header and fields can be present or ignored depending on the data set message layout configuration.

[0046] Two transport protocols are specified for the transmission of network messages: OPC UA UDP and OPC UA Ethernet. In the following detailed description, only OPC UA Ethernet is described. UADP network messages are transmitted as payload of VLAN-tagged Ethernet II frames with a maximum size of 1522 bytes. The IEEE-registered OPC UA Ethernet type for UADP communication is 0xB62C.

[0047] In case of transmission over TSN, network messages created by the writer group are sent over a TSN stream, which can be identified by the stream identification functionality specified in IEEE 802.1CB. A typical identification functionality uses the destination or source MAC address in combination with the VLAN-ID of the Ethernet frame encapsulating the network message.

[0048] The mapping of PubSub level timing parameters (publishing interval and publish offset) to TSN timing parameters is mainly done by using the scheduling scheme provided by IEEE 802.1Qbv, which allows to define transmission cycles and, within these cycles, transmission times, i.e. transmission offsets.

[0049] The network message format for periodic communication with fixed layout data is described in the following. The UADP header format of network messages and data set messages is designed to be flexible and supports different use cases by enabling or disabling individual fields in the header.

[0050] The number of possible header field combinations thus increases the complexity of its implementation. In contrast, some application domains with specific use cases can rely on a configuration in which the header layout comprises a reasonable set of header options to provide a trade-off between flexibility, interoperability, and support for different use cases.

[0051] Appendix C of OPC UA Part 14 Appendix C illustrates one of these use cases: the use of PubSub in the cyclic exchange of real-time data. In this configuration, the layout of the data transmitted per publishing interval is fixed and known from the publisher and the subscriber by configuration. When the size of the data set message is constant, even further optimizations can be pushed.

[0052] The following conditions are then assumed:

[0053] - each network message contains the same number of data set messages,

[0054] - The sequence of dataset messages within a network message is identical at each publication interval.

[0055] - The field layout in each dataset message is the same across all publication intervals.

[0056] The Publisher ID and WriterGroupID identify the writer group. The network message number is used for the writer group that sends their datasets in multiple network messages. Group versioning allows subscribers to verify the expected layout of the dataset message and its dataset fields.

[0057] Figure 7 The header layout shown illustrates this use case when security is not implemented. When security is implemented (e.g., signature only), the header layout includes an additional security header and signature, such as... Figure 8a As shown. The dataset message header has been reduced to Figure 8b The fields shown.

[0058] The following provides examples of message layouts. The first example is a fixed message layout without security. This configuration ensures that each network message has a constant header and dataset field layout. Since the offsets of all fields are constant, message encoding and decoding are simplified. The payload header is omitted; the information it typically contains is obtained by the subscriber from the dataset metadata, dataset writer, and writer group settings. This configuration assumes that the size of each dataset message is constant, which can be guaranteed by the configuration.

[0059] Proper configuration can also ensure that the number of dataset messages and their order in network messages remain the same across all sent network messages. These attributes include... Figure 9 As shown.

[0060] The second example is a fixed message layout with security features. The same configuration can be extended with security features, and this results in… Figure 10 The compressed network message format shown.

[0061] The problem to be solved:

[0062] OPC UA provides a highly flexible scheme for information exchange between entities in complex systems, supporting a variety of application domains. This flexibility is reflected in the communication protocols that support these exchanges.

[0063] like Figure 5 As shown in the basic network message format, this flexibility comes at the cost of potential scaling overhead. Figure 19 A table is shown that summarizes the overhead caused by the different headers that may be found in PubSub network messages without security.

[0064] For (N+1) data set writers, this layout can result in a maximum message length of:

[0065] 21 + 11 + [1 + (N+1) x 2] + 10 + PF + (N+1) x 2 + PL bytes.

[0066] This results in a potential overhead of 47 + 4N bytes, considering that no field is promoted (not copied in the non-encrypted part of the network message).

[0067] When sending cyclic data using the above compressed UADP layout, the overhead is reduced, as outlined in the white background shown in Figure 20 .

[0068] Regardless of the number of data set writers, the compressed layout without security can result in a maximum message length of:

[0069] 4 + 11 + PL bytes,

[0070] giving a potential overhead of 15 bytes.

[0071] While the compressed UADP layout greatly reduces the PubSub overhead, the PubSub overhead needs to be considered in its application environment, especially for the overhead of TSN-based control over high-speed Ethernet, where the payload is usually limited to about 100 bytes.

[0072] In this configuration, the minimum MAC layer Ethernet overhead includes:

[0073] - MAC destination address (6 bytes),

[0074] - MAC source address (6 bytes),

[0075] - VLAN tag (4 bytes),

[0076] - Ethernet (2 bytes),

[0077] adding another 18 bytes to the OPC UA message. SUMMARY

[0078] The present invention aims at improving this situation. To this end, the present invention aims at providing a method for sending a message in a network having a communication pattern involving a publisher device and a subscriber device on the network, the method comprising:

[0079] - extracting a payload of the received message and concatenating said payload within the same combination of messages,

[0080] - adding a header to the combined message, the header comprising a single identifier of the publisher device, the publisher identifier being predetermined in order to intend the combined message to at least one selected subscriber device.

[0081] The following comments are made Figure 14 An example of such an implementation is shown, in particular showing the structure of the combined message (with one header, but multiple concatenated payloads from the various devices) described above. This implementation mode in particular enables to reduce the overhead of the usual controller device.

[0082] Generally, in one implementation mode, the selected subscriber device described above can be the controller device. The controller device controls the devices of the network that emit the received messages described above.

[0083] In particular, one of these network devices can be selected to implement the method based on criteria related to the controller device and / or to the emitting devices. More specifically, the method described above can be implemented by one of these emitting devices or by one device connected to these emitting devices and related to their controller device.

[0084] Typically, the criteria described above can comprise at least the current topology of the network (to be taken into account in order to designate the best intermediate device between the emitting devices on the one hand and the controller device of the other hand, to perform the method described above).

[0085] In one implementation mode, the received messages comprise a header with the same publisher identifier as the publisher ID = k in Figure 14 and the received messages are emitted by a plurality of different publisher devices. Then, the device performing the method can identify these messages and collect them in one single combined message, as Figure 14 shown.

[0086] Each received message can comprise an identifier related to the device that emits said received message (it can be another identifier than the usual publisher ID, for example a so-called "writer group ID" (= 1, 2, 3... in Figure 14 ) that can define the reception order of these messages). Moreover, this emitter identifier defines in this implementation mode the order of the payloads of the received messages in the concatenation of the payloads described above. These identifiers are known from the standard specification "Open Platform Communications Unified Architecture".

[0087] More generally, in one implementation mode, the network of devices involved in the connection method operates according to a standard of the "Open Platform Communications Unified Architecture" type and the single identifier of the publisher device described above is the publisher ID identifier.

[0088] More particularly, the network can be further operated according to a "time sensitive network" type of standard.

[0089] Typically as mentioned above, the transmitter identifier can be of the type of a writer group ID defining a timing of the publication offset, thereby defining an order of the payload of the received message in a concatenation of said payload.

[0090] Furthermore, as Figure 14 illustrated, the concatenated payload can be extracted from messages received in a same predetermined cycle duration. Typically, in Figure 15 the illustrated embodiment, the cycle duration can correspond to a publication time distance of the multiplexer device.

[0091] The invention is also a network device selected to function as a multiplexer device and configured to implement the method as described above. The device can be selected according to criteria such as a current topology (e.g. its centrality in the network with respect to other devices) and / or according to a respective specific function of the device as illustrated hereafter.

[0092] The invention is also a system comprising a network device emitting a message and a multiplexer device receiving said message and configured to implement the method as described above.

[0093] The invention is also a controller device of such a system and configured to:

[0094] - receive a message having a combination of predetermined publisher identifiers, and

[0095] - interpret a concatenation of payloads.

[0096] The invention is also a computer program comprising instructions which, when executed by a processor of a network device, cause the network device to implement the method as described above. The invention is also a non-transitory computer storage medium storing such instructions.

[0097] As the reception of a signal comprising a message structure as described above including a combination at a device of the network (e.g. typically a controller device) causes the device to interpret the signal in a specific way, the invention is also such a signal. The signal typically comprises data of a message published in a network having a communication pattern involving publisher devices and subscriber devices of the network, wherein the signal comprises:

[0098] - data of a header comprising a single identifier of a publisher device, and

[0099] - data of a plurality of concatenated payloads initiated by respective devices of the network.

[0100] Further details and advantages of possible embodiments of the present application will be described below with reference to the accompanying drawings. BRIEF DESCRIPTION OF DRAWINGS

[0101] [ Figure 1 ]

[0102] Figure 1 A classic publish / subscribe scheme is shown.

[0103] [ Figure 2 ]

[0104] Figure 2 A dataset and dataset message are shown.

[0105] [ Figure 3 ]

[0106] Figure 3 PubSub message layers and encapsulation are shown.

[0107] [ Figure 4 ]

[0108] Figure 4 PubSub entities and exchanged messages are shown.

[0109] [ Figure 5 ]

[0110] Figure 5 A general UADP network message format is shown.

[0111] [ Figure 6 ]

[0112] Figure 6 Network message payload details and dataset message header format are shown.

[0113] [ Figure 7 ]

[0114] Figure 7 A network message format without security compression for round-robin PubSub communication is shown.

[0115] [ Figure 8a ]

[0116] Figure 8a A compressed network message format with only signature for round-robin PubSub communication is shown.

[0117] [ Figure 8b ]

[0118] Figure 8b A compressed network message format with only signature for round-robin PubSub communication is shown.

[0119] [ Figure 9 ]

[0120] Figure 9 Fixed compressed message layout without security is shown.

[0121] [ Figure 10 ]

[0122] Figure 10 Fixed compressed message layout with security (signature only) is shown.

[0123] [ Figure 11 ]

[0124] Figure 11 Network topology of industrial control and use of specific topology (lower part of Figure 11 ) to implement the invention according to an example of an embodiment is shown.

[0125] [ Figure 12 ]

[0126] Figure 12 Independent network message towards controller device PLC according to prior art is shown.

[0127] [ Figure 13 ]

[0128] Figure 13 Network message according to the combination of the invention is shown.

[0129] [ Figure 14 ]

[0130] Figure 14 Multiplexer operation is shown.

[0131] [ Figure 15 ]

[0132] Figure 15 Network message scheduling for minimal multiplexing delay in an example of an embodiment is shown.

[0133] [ Figure 16 ]

[0134] Figure 16 System with multiple devices and in this example with multiple controllers in the network is shown schematically.

[0135] [ Figure 17 ]

[0136] Figure 17A corresponding table is shown, built according to the topology of the network and / or the functions of the devices in the network, and for each group of devices linked to a specific controller, defined as a subscriber of the messages published by the group of devices, the possible multiplexer devices are defined.

[0137] [ Figure 18 ]

[0138] Figure 18 Possible steps of the method according to the application are shown (possibly representing a general algorithm of a computer program according to the application).

[0139] [ Figure 19 ]

[0140] Figure 19 A table is shown summarizing the overhead caused by different headers that can be found in PubSub network messages without security.

[0141] [ Figure 20 ]

[0142] Figure 20 A table is shown summarizing the overhead caused by different headers that can be found in PubSub network messages without security when sending cyclic data using the compressed UADP layout. DETAILED DESCRIPTION

[0143] The present application proposes to reduce the overhead in PubSub communication by combining independent network messages sent by a group of devices (typically sensors and / or actuators as communication devices in a network) into a single network message. As shown below, a multiplexer device (reference multiplexer-lower part) Figure 11 can implement the following functions:

[0144] - an adapted configuration using the PubSub publish function of the devices,

[0145] - implementing a PubSub multiplexing function, the multiplexing possibly depending in particular on the location in the network topology,

[0146] - implementing a network message scheduling function.

[0147] This implementation allows to combine multiple network messages initially generated by a group of devices into a single network message to be received by a subscriber. In one embodiment, the subscriber can be a single entity, preferably a controller device, for example a so-called "Programmable Logic Controller" (hereafter PLC), which locally controls a group of devices (sensors and / or actuators) in the network topology (through the PLC links shown). Figure 11

[0148] Figure 11 ​A typical implementation of a control topology that can be found within an industrial production line or machine is shown, in which a PLC (Programmable Logic Controller) controls a set of devices (sensors and / or actuators). Information and commands between the controller and the devices are exchanged in a loop, and each device typically handles short information data (e.g. 16-bit commands, 8-bit counter values, etc.).

[0149] In the prior art solution, when using OPC UA PubSub communication, a simple configuration can be to make each device include a publisher and / or a subscriber. In this mapping, the publisher includes a writer group that generates network messages containing the dataset messages that the device wants to send. Then, each device sends its own independent network message, generating a series of messages on the PLC link, as shown in Figure 12 .

[0150] The number of devices addressable within each cycle is a function of:

[0151] - the duration of the cycle,

[0152] - the length of the network messages.

[0153] The total amount of network message overhead (i.e. Ethernet and PubSub overhead) occupies a portion of the link capacity that has two double effects:

[0154] - a limitation of the control cycle duration for a given number of devices,

[0155] - a limitation of the number of devices controlled within one cycle.

[0156] When implementing OPC UA PubSub on an Ethernet TSN network, the overhead caused by the Ethernet frame header is not compressible: the MAC address, VLAN tag and Ethernet type are needed by the TSN bridge to process the corresponding flow. Therefore, the only reduction of the PubSub overhead allows to overcome the above-mentioned prior art limitations.

[0157] In fact, as shown in the comparison of Figure 12 and Figure 13 , a single network message:

[0158] - collects the payloads of different devices, and has

[0159] - a single header identifying a single publisher, and

[0160] - Figure 13 a single Ethernet header in the example of

[0161] According to the present application and as shown in Figure 13 , this makes it possible to limit the above-mentioned overhead.

[0162] On the other side of this single network message reading reader, the reader group of the subscriber entity of the PLC is configured to correctly interpret and demultiplex the dataset message received in this single network message, as described in the present specification below.

[0163] Regarding the device publisher configuration, in one embodiment, the configuration related to the network message header is such that all devices that must combine the network message are considered to form a distributed publisher and are configured with the same publisher ID.

[0164] The configuration related to the group header is such that each device sends its network message with a specific writer group ID that identifies the device in the publisher.

[0165] Under the constraint that each publisher time distance or cycle of a given writer group sends only one network message, the network message number can be ignored. If the writer group sends multiple network messages per publisher time distance, a consistent network message number is used to send them back.

[0166] The sequence number is monotonically increasing when each network message is transmitted by the writer group.

[0167] The configuration related to the network message payload is such that the layout of the payload is maintained as described in OPC UA Part 14 Annex C (a predetermined series of fixed format dataset messages).

[0168] The individual dataset fields within the dataset message are kept unchanged.

[0169] One dataset field in each dataset message can be reserved for the insertion of an integrity check code computed over the entire dataset message. This integrity code (e.g. CRC-16) can then be used by the dataset reader in the destination subscriber entity to check the validity of the dataset message.

[0170] The multiplexing function is described below.

[0171] The PubSub multiplexer can receive Ethernet encapsulated network messages over its network inputs and send combined Ethernet encapsulated network messages over its network outputs. The PubSub multiplexer has at least two inputs and a single output as shown in the lower part of Figure 11 .

[0172] When integrated in a device, at least one input of the multiplexer receives raw network messages generated by an application co-located with the multiplexer, i.e. not encapsulated in an Ethernet frame.

[0173] As shown in Figure 14 , the multiplexer relies on a number of data structures and variables to perform network message combination:

[0174] • Payload transmit buffer (PLTxBuf) associated with each publisher ID (i.e. each publisher from which network messages will be combined),

[0175] • Payload offset (PLOffset) associated with each writer group contained in the publisher, from which network messages will be combined.

[0176] PLTxBuf k associated with publisher k.

[0177] PLOffset k i associated with writer group i (writer group ID = i) contained in publisher k (publisher ID = k). PLOffset k i represents the offset, with reference to the base of PLTxBuf k where the payloads (dataset messages) of the network messages received with publisher ID = k and writer group ID = i are stored.

[0178] The network message generated by the multiplexer includes the following information:

[0179] • In the network message header: publisher ID = k

[0180] • In the group header:

[0181] o writer group ID = mux, where mux is the value associated with the multiplexer

[0182] o group version = value associated with the multiplexer entity, fixed by configuration

[0183] o network message number = 1 : assuming that no more than one network message per publish time is generated from the combination of network messages

[0184] o sequence number = value incremented by the network message generation function of the multiplexer each time a new In network message is generated.

[0185] The payload layout in the combined network message (in particular the order of the dataset messages) is defined by the multiplexer configuration.

[0186] A preferred configuration includes grouping the dataset messages associated with a particular writer group as they were originally in the incoming network messages to avoid additional reordering by the multiplexer.

[0187] The network message scheduling is as follows Figure 15as shown. Typically, the latency of the network message composition operation can be reduced by exploiting the publication time interval common to the device and the multiplexer. This can be achieved by configuring an appropriate publication offset for each writer group included in the device. It is reminded that the mapping of the PubSub level timing parameters (publication time interval and publication offset) to the TSN timing parameters is mainly done by using the scheduling scheme provided by IEEE 802.1Qbv, which allows to define transmission cycles and transmission times within these cycles, i.e. transmission offsets. Thus, the cyclic timing of the transmissions can be defined by such offset standard constraints.

[0188] As Figure 15 shown (this illustration does not take into account possible delays due to network or internal propagation delays), the publication offset of the device writer groups can be configured so as to provide the minimum headroom required by the multiplexer to perform the network message composition, thus guaranteeing a minimum multiplexing delay.

[0189] Reference is now made to Figure 16 , a plurality of devices DEVi, DEVj,... can be linked to a controller PLC-A, such that the PLC-A is a subscriber when the devices DEVi, DEVj,... are publishers. Other controllers (PLC-B, etc.) are possible in the network and can be linked to other publisher devices DEVk, DEVl, etc. Of course, one or more of the devices DEVi, DEVj,... can be publishers of a second controller PLC-B, and conversely, one or more of the devices DEVk, DEVl, etc. can be publishers of the controller PLC-A.

[0190] At least one node of the network can act as a multiplexer to process the PubSub messages sent by the devices DEVi, DEVj, etc. Typically (but not mandatorily), the multiplexer can be a device among the DEVi and DEVj selected according to the network topology and / or according to the respective functions of the nodes, etc. Alternatively, a plurality of multiplexers can be selected to process respectively the messages sent by the devices DEVi,..., DEVm on the one hand and the messages sent by the devices DEVm+1,..., DEVj on the other hand. Here, a third multiplexer can process the PubSub messages received from both groups of devices DEVi,..., DEVm and DEVm+1,...,..., and DEVj to combine them for the common controller PLC-A.

[0191] Thus, at least some nodes of the network can be programmed to have a multiplexing function in order to combine different PubSub messages into a single message, add different payloads (dataset messages), but keep a single header, as Figure 13 and Figure 14 shown. Typically, in Figure 14In the example of Fig. 1, the node entity of the multiplexed message is the device m programmed with this multiplexing function. The other devices 1, 2,..., n can be programmed to publish their messages using the same publisher identifier publisher ID = k, which can be equal or different from m. When device m receives published messages with publisher ID = k, device m is programmed to combine them and, more specifically, concatenate their payloads in order according to the writer group ID indicated in each message header, to account for their respective publication offset, as referred to above with respect to Figure 15 In another embodiment, Figure 14 The publisher devices 1, 2,..., n can be programmed to publish their messages with their own publisher ID (1, 2,..., n) and the multiplexing device m can be programmed to recognize these identifiers publisher ID (1, 2,..., n) to combine the messages received from the respective devices 1, 2,..., n.

[0192] Referring again to Figure 16 , each device can typically comprise a communication interface COMD connected to a processor PROCD cooperating with a memory MEMD storing data such as its publisher’s identifier publisher ID, the identifier of the writer group, etc. and instructions of a computer program to build and send network messages with a payload and especially a header including such identifiers. In some embodiments where its publisher ID is replaced by the multiplexing device publisher IDI, the computer program can apply such a function. More specifically, if one of these devices is designated to be used as a multiplexing device (e.g. according to the topology of the network), the multiplexing function can be used to enhance the computer program (stored in the memory MEMD of this device).

[0193] Moreover, each controller PLC can further comprise a communication interface COMC connected to a processor PROCC cooperating with a memory MEMC storing especially instructions of a computer program to interpret the combined messages (and their combined payloads) published by the multiplexer device.

[0194] Now referring to Figure 17 The corresponding table can be defined (e.g. by a network scheduler) especially according to the network topology and / or the devices functions in the network, etc. Thus, this table can define for each controller PLC-A, PLC-B, etc.:

[0195] - the devices (respectively DEVi, DEVj, etc.; DEVk, DEVl, etc.) which can be the publisher devices of this controller,

[0196] - and multiplexer devices (DEVml; DEVm2) to combine messages published by such publisher devices.

[0197] Thus, the overhead of receiving multiple messages and interpreting their headers by the controllers PLC-A, PLC-B, etc. can be delivered on the multiplexer DEVml, DEVm2, so as to only process the payloads received in a single message at the controller side.

[0198] In addition, each controller can process more messages and then control more devices within one cycle, or for the same amount of data to be sent (or eventually for the same amount of devices to be controlled), the control cycle can be shorter.

[0199] Reference is now made to Figure 18 Thus, the first step S1 can comprise (e.g. at the network scheduler side) defining a correspondence table as previously described with reference to Figure 17 In one embodiment, the instructions of this table can be transmitted at step S2 to each multiplexer device at least storing:

[0200] - the multiplexer device m and the corresponding controller PLC-A are linked to the publisher ID = k of the group, and

[0201] - the writer group ID = m, any future combined network message header will include this writer group ID = m.

[0202] In this step S2, the publisher ID = k can also be transmitted to the devices DEV1, DEV2, etc. so as to use it when messages are to be published with PLC-A as subscriber. The controller PLC-A can also store the publisher ID = k so as to consider combined messages when received with such publisher ID.

[0203] In this embodiment, in step S3, the multiplexer device MUX receives messages published by the devices DEV1, DEV2, DEV3, etc. of the publisher ID = k (so that the multiplexer device considers them), and their own writer group ID = 1, 3, 2, etc. Based on these respective identifiers writer group ID = 1, 3, 2, the multiplexer device is configured to manage the order of the payloads of these messages with a respective offset in step S4 and possibly rearrange this order (the order of the payloads for example becomes #1, then #2, then #3).

[0204] Steps S3 and S4 of receiving messages from the group (publisher ID = k) and combining their payloads can be performed until the end of one cycle in step S5. Preferentially, the payloads are combined as soon as a message is received from the devices DEV1, DEV2 and DEV3, without waiting for the end of the cycle to achieve the payload combination. The duration of the cycle can be defined by the publication time distance of the multiplexer device, as shown in Figure 15 The publication offset defines the time relative to the beginning of the cycle at which a network message can be sent. To this end, the publication time distance and the publication offset can be other data stored by the multiplexer device in step S2.

[0205] Before the end of the cycle (arrow KO from test S5), the multiplexer can send a concatenated network message comprising the successive payloads of the messages received from the devices DEV1, DEV2, DEV3 in this order, arranged in this order, and to which the multiplexer adds at least:

[0206] - the publisher ID of the group (= k) so that the controller PLC-A will consider the message resulting from the combination of these payloads arranged in this order,

[0207] - its own writer group ID (= m) so that any other multiplexer or controller that needs to arbitrate the priority among multiple combined messages can use the offset given by the writer group ID = m.

[0208] It is reminded that this information writer group ID does indeed manage the publication offset of the PubSub messages in a generic way.

[0209] Finally, in step S7, the multiplexer device publishes the new combined message with this header so as to be considered as a subscriber by the controller PLC-A.

[0210] The arrow OK from test S5 corresponds to the case when the current cycle ends, and in order to start a new cycle, the multiplexer device waits for new messages received from the devices DEV1, DEV2, DEV3 or possibly from other devices.

[0211] It thus becomes clear that the present invention uses different mechanisms specified in the IEEE 802.1 TSN and OPC UA Part 14 (PubSub) standards, and that its implementation does not require any further standardization.

[0212] Since this optimization allows to improve the OPC UA Pub communication performance, the present application can of course be advantageously applied to OPC UA-PubSub based control systems, thereby providing high performance (short control loop) OPC UA PubSub based factory automation products. However, the same principles can be applied to other communication protocols using the same type of information organization.

Claims

1. A method for sending network messages in a network, the network operating according to a standard of the "Open Platform Communication Unified Architecture" type, the network having communication modes involving publisher devices and subscriber devices on the network, the method comprising the following steps: - Extract the payload of the received network messages. Each received network message includes an identifier writer group ID, which defines the timing of the publication offset associated with the device that sent the received network message. - The payload cascaded within the same combination of network messages. The transmitter identifier writer group ID defines the timing of the publication offset, thereby defining the order of the payloads of the received network messages in the concatenation of payloads. - Add a header to the combined network message, the header including a single identifier of the publisher device, the publisher identifier being of type Publisher ID and predefined, so as to reserve the combined network message for at least one selected subscriber device.

2. The method according to claim 1, wherein, The selected subscriber device is the controller device of the network device that transmits the received network message.

3. The method according to claim 2, wherein, The method is implemented by selecting a device from the network devices based on standards associated with the controller device and / or the transmitting device.

4. The method according to claim 3, wherein, The standard includes at least the current topology of the network.

5. The method according to any one of claims 1 to 4, wherein, The received network messages have headers that include the same publisher identifier, and the received network messages are transmitted by multiple different publisher devices.

6. The method according to any one of claims 1 to 4, wherein, The network also operates according to the standards of a "time-sensitive network" type.

7. The method according to claim 5, wherein, The network also operates according to the standards of a "time-sensitive network" type.

8. The method according to any one of claims 1 to 4 and 7, wherein, The cascaded payload is extracted from network messages received within the same predetermined cycle duration.

9. The method according to claim 5, wherein, The cascaded payload is extracted from network messages received within the same predetermined cycle duration.

10. The method according to claim 6, wherein, The cascaded payload is extracted from network messages received within the same predetermined cycle duration.

11. A network device selected for use as a multiplexer device, and the network device comprising: Communication interface; A memory that stores data and instructions for computer programs; A processor connected to the communication interface, and configured to implement the method according to any one of claims 1 to 10 when executing the computer program.

12. A system comprising a network device for transmitting network messages and a multiplexer device for receiving the network messages and configured to perform the method according to any one of claims 1 to 10.

13. A controller device comprising, in the system of claim 12, the controller device comprising: Communication interface; A memory that stores data and instructions for computer programs; A processor connected to the communication interface, and configured to receive network messages having a combination of predetermined publisher identifiers when executing the computer program, and to interpret the cascading of the payloads.

14. A computer program product comprising instructions that, when executed by a processor of a network device, cause the network device to perform the method according to any one of claims 1 to 10.

Images