Gateway module for industrial safety protocols, related processing and / or monitoring station, industrial plant and method

Abstract

A gateway module (40) is described. The gateway module (40) is configured to receive via a first communication interface (402) a first communication in accordance with the CIP Safety industrial safety protocol and determine whether the first communication comprises a read request for first safety data (SD1 ) or a write request for second safety data (SD2). In response to determining that the first communication comprises a read request for the first safety data (SD1 ), the gateway module sends via the first communication interface (402) a second communication in accordance with the CIP Safety industrial safety protocol, wherein the second communication comprises the first safety data (SD1 ). Instead, in response to determining that the first communication comprises a write request for the second safety data (SD2), the gateway module stores the second safety data (SD2). Furthermore, the gateway module is configured to receive via a second communication interface (404) a third communication in accordance with the openSAFETY industrial safety protocol and determine whether the third communication comprises a read request for the second safety data (SD2) or a write request for the first safety data (SD1 ). In response to determining that the third communication comprises a read request for the second safety data (SD2), the gateway module sends via the second communication interface (404) a fourth communication in accordance with the openSAFETY industrial safety protocol, wherein the fourth communication comprises the second safety data (SD2). Instead, in response to determining that the third communication comprises a write request for the first safety data (SD1 ), the gateway module stores the first safety data (SD1).

Description

[0001] "Gateway module for industrial safety protocols, related processing and / or monitoring station, industrial plant and method"

[0002] * * *

[0003] Technical field

[0004] Various embodiments of the present disclosure relate to solutions for exchanging data between two industrial safety protocols.

[0005] Background

[0006] Many industrial network protocols are known, typically in the form of a fieldbus. These protocols are designed to ensure reliable and efficient communications between devices in industrial environments. For example, the main protocols are EtherNet / IP, PROFINET, Modbus, Profibus, DeviceNet, EtherCAT, OPC-UA and POWERLINK.

[0007] For example, Figure 1 shows a typical industrial plant 1 comprising a plurality of stations 2. For example, the stations 2 can be industrial robots, or other processing and / or monitoring stations.

[0008] As shown in Figure 1 , typically a station 2 comprises a control system 22, for example comprising a PLC (Programmable Logic Controller). Said control system 22 is connected by means of a communication system 20 to one or more actuators and / or sensors of the station 2 (not shown in the figure). For example, the actuators and sensors can be associated with a robot arm. For example, processing stations 2 often use the POWERLINK protocol, particularly in Europe. For example, in the context of the POWERLINK protocol, the control system 22, i.e., the controller node, is identified as "Managing Node" and the controlled peripheral node is identified as "Controlled Node".

[0009] The processing stations 2 are often connected by means of a further communication system 10 to a further control system 12, which performs plant-level controls. For example, industrial plants often use the EtherNet / IP protocol, particularly in the United States of America. In particular, in the context of the EtherNet / IP protocol, the control node 12 is identified as "Scanner Node" and the controlled peripheral node is identified as "Adapter node."

[0010] Therefore, an industrial plant 1 can employ different communication protocols. For example, for this purpose, each control system 22 of a station 2 can comprise two communication interfaces, respectively for connection to the network 20 and to the network 10.

[0011] Alternatively, as shown in Figure 1 , the industrial plant 1 can comprise one or more gateway nodes 30 that are configured to exchange data between the network 10 and the network 20.

[0012] Figure 2 schematically shows the EtherNet / IP™ protocol. In particular, EtherNet / IP is based on the TCP / IP protocol suite and uses Ethernet as the physical layer.

[0013] In particular, Figure 2 shows the physical layer 100 and the Medium Access Control (MAC) layer 102 of the Ethernet protocol. Essentially, data transmission occurs via data frames in accordance with the Ethernet protocol, so-called Ethernet packet / frame. For example, such a frame comprises (among other data) a destination MAC address, a source MAC address and a payload comprising the transmitted data.

[0014] In the context of the Internet Protocol (IP) 104, the payload of the Ethernet frame comprises IP data packets which in turn comprise a destination IP address, a source IP address and a related payload of the IP packet.

[0015] For example, typical transmission protocols based on the IP protocol are the Transmission Control Protocol (TCP) 108 and the User Datagram Protocol (UDP) 106. For example, in this case, the payload of the IP packet can in turn comprise a TCP or UDP protocol packet, which ultimately comprises the application data to be transmitted. For example, the TCP and UDP protocols allow specifying a port. The differences between the TCP and UDP protocols are well known. For example, the TCP protocol also allows implementing data transmission control.

[0016] Therefore, layers 100 to 108 of the EtherNet / IP protocol are implemented with the IP protocol over Ethernet (IPoE). For example, in the EtherNet / IP protocol, the TCP protocol is typically used for asynchronous communication, while UDP is typically used for cyclic data exchange. In this context, using the Ethernet and IP protocols, EtherNet / IP can use VLAN (Virtual Local Area Network) tagging and / or scheduling based on QoS (Quality of Service) criteria, for example to separate EtherNet / IP traffic from the rest of the network traffic and / or to guarantee real-time data delivery. Cyclic multicast data transmission, on the other hand, is typically handled by multicast IP addresses and the IGMP (Internet Group Management Protocol).

[0017] At the application level 110, EtherNet / IP primarily uses the Common Industrial Protocol (CIP). The CIP protocol is based on abstract object modeling: every device in a CIP network is modeled as a collection of objects. An object provides an abstract representation of a particular component within the device and, consequently, anything not described in the form of an object is not visible through CIP. The idea behind CIP's object modeling is the same as an object-oriented programming language: the objects implemented by a CIP node are instances of different classes that define a set of related attributes and methods. From the user's point of view, an object is uniquely identified by its class identifier (ID) and the instance ID. The object's attributes are further identified by an "Attribute-ID". According to the CIP protocol, the exposed objects can be divided into categories. In particular, application objects are used to represent user data, while communication objects are used to manage node connections and I / O mapping. The details of the EtherNet / IP protocol are well known, and for example available at the following link: https: / / www.odva.org / technology- standards / key-technologies / ethernet-ip / .

[0018] Instead, Figure 3 schematically shows the POWERLINK protocol. The POWERLINK protocol also uses Ethernet at the physical level. However, POWERLINK is not compatible with the standard Ethernet protocol.

[0019] In particular, Figure 3 shows the physical layer 200 of the Ethernet protocol and a Medium Access Control (MAC) layer 202. In particular, while the POWERLINK protocol adopts the same Ethernet frame format, the protocol implements a different MAC layer, thus not allowing standard devices to operate on the same network. In the case of POWERLINK, in fact, the control of access to the physical medium is completely the responsibility of the controller node, which is the only one that can explicitly initiate a communication transaction, while the peripheral nodes can only respond to the master's queries. In particular, the controller node periodically queries the peripheral nodes for cyclic data exchange and reserves a bus idle time to allow asynchronous communications. This is also shown by an additional layer 204 that implements a data link layer.

[0020] POWERLINK can therefore comprise applications 214 that directly access the layer 204. However, applications 212 that use the IP protocol 206, and the TCP protocol 210 and / or the UDP protocol 208, to send TCP / IP or UDP / IP data packets to the layer 204 can also be provided.

[0021] For example, in the case of POWERLINK applications, the application data is typically organized in an object dictionary that collects all the data that a node exposes on the network. Objects are addressed by a unique index and, for aggregated objects, by sub-indexes. Objects can only be accessed in R / W mode, but other actions are not permitted. The node behaves accordingly, depending on the values of the objects. Although all objects in the dictionary are accessible uniformly, two types of objects have been provided: "pure data objects" and "communication data objects". The "pure data objects" represent the actual data that a node can exchange (for example, the motor reference torque), while the "communication data objects" represent the configuration of communication parameters, for example the mapping of Process Data Objects (PDO). The details of the POWERLINK protocol are well known, and for example available at the following link: https: / / www.br-automation.com / it-it / prodotti / networks-and- fieldbus-modules / powerlink / .

[0022] Therefore, unlike POWERLINK, data transmission on EtherNet / IP can occur at any time and is not bound by the network communication cycle. On the other hand, due to the non-determ inistic nature of the underlying layers, the minimum cycle that can be achieved with EtherNet / IP is much higher than that of POWERLINK.

[0023] Recently, industrial safety protocols have been implemented in addition to fieldbus protocols. These protocols are used to transfer data relevant from the point of view of functional safety, i.e. , with reference to the reliability of the communication. For example, these safety protocols (safety protocol) are typically used when errors in the communication can create risks of harming people and / or objects.

[0024] These protocols satisfy the same needs as industrial protocols (controller-peripheral networks, asynchronous communication and cyclic communication) and add communication mechanisms to guarantee the integrity of the provided data and monitor the actual state of the connection. The concept of a safety protocol is typically based on the "black-channel" approach, i.e., the safety communication mechanism does not depend on the underlying industrial protocol, but is directly implemented in the safety protocol itself. For example, EP 2 587 738 B1 describes a bus device for a fieldbus for the transmission of safety-oriented data of a safety protocol using an industrial Ethernet protocol, wherein the safety protocol is implemented in the bus device and the session layer and / or the presentation layer of the safety protocol, independent of the industrial Ethernet protocol, is implemented in the bus device instead of the session layer and / or the presentation layer of the industrial Ethernet protocol.

[0025] For example, the most commonly used safety protocols are the extension "CIP Safety" of the CIP protocol and openSAFETY. Both safety protocols can be implemented on POWERLINK or EtherNet / IP. The most frequent scenario, however, is the one in which CIP Safety works on EtherNet / IP and openSAFETY on POWERLINK. For example, with reference to Figure 2, the CIP protocol 110 can comprise the CIP Safety extension 112. Instead, with reference to Figure 3, POWERLINK can use an additional safety protocol 216 in the application layer.

[0026] For example, CIP Safety and openSAFETY provide mechanisms for duplicating safety-relevant data and doubling control sequences to guarantee data integrity, uniquely identify a safety device (whether master or slave). For example, the unique identifier (typically worldwide) is stored in the device's memory, thus allowing to detect if a network node has been replaced, removed or added to the network. Furthermore, these protocols allow verifying the freshness of the safety data, for example to monitor the performance of the underlying industrial bus, and manage the device parameters safely, verifying the actual integrity of the transfer.

[0027] Currently, there are no gateways capable of realizing the exchange of safety data between the CIP Safety and openSAFETY protocols. In fact, the safety concept implies that the gateway module itself should guarantee a safety level that excludes any errors in the data exchange, for example due to a malfunction of the gateway module itself.

[0028] Summary

[0029] Therefore, various embodiments of the present description concern a gateway module configured to implement communication between two industrial safety protocols, such as for example CIP Safety and openSAFETY. According to one or more embodiments, this object is achieved through a gateway module having the distinctive elements set forth specifically in the claims that follow. The embodiments also concern a related processing and / or monitoring station, industrial plant and method.

[0030] The claims are an integral part of the technical teaching of the description provided here.

[0031] As mentioned before, various embodiments of the present description concern a gateway module for industrial safety protocols. The gateway module comprises a first communication interface configured to be connected to a first communication system in accordance with a respective industrial safety protocol, such as for example the CIP Safety industrial safety protocol. The gateway module further comprises a second communication interface configured to be connected to a second communication system in accordance with a respective industrial safety protocol, such as for example the openSAFETY industrial safety protocol.

[0032] Therefore, in various embodiments, the gateway module is configured to receive via the first communication interface a first communication in accordance with the CIP Safety industrial safety protocol. Subsequently, the gateway module analyzes the first communication to determine whether the first communication comprises a read request for first safety data or a write request for second safety data. In response to a determination that the first communication comprises a read request for first safety data, the gateway module sends via the first communication interface a second communication in accordance with the CIP Safety industrial safety protocol, wherein the second communication comprises the first safety data. Instead, in response to a determination that the first communication comprises a write request for the second safety data, the gateway module stores the second safety data.

[0033] Similarly, in various embodiments, the gateway module is configured to receive via the second communication interface a third communication in accordance with the openSAFETY industrial safety protocol. Subsequently, the gateway module analyzes the third communication to determine whether the third communication comprises a read request for the second safety data or a write request for the first safety data. In response to a determination that the third communication comprises a read request for the second safety data, the gateway module sends via the second communication interface a fourth communication in accordance with the openSAFETY industrial safety protocol, wherein the fourth communication comprises the second safety data. Instead, in response to a determination that the third communication comprises a write request for the first safety data, the gateway module stores the first safety data.

[0034] In particular, in various embodiments, this operation is implemented with at least two processing circuits, such as for example microprocessors. In particular, in various embodiments, the gateway module comprises a first processing circuit and a second processing circuit connected by means of a communication channel, such as for example a serial communication channel. For example, in various embodiments, the first processing circuit and the second processing circuit are connected by means of one or more Universal Asynchronous Receiver-Transmitter, Serial Peripheral Interface, or Inter Integrated Circuit communication channels.

[0035] For example, in various embodiments, the first processing circuit is configured to receive via the first communication interface the first communication in accordance with the CIP Safety industrial safety protocol and analyze the first communication to determine whether the first communication comprises the read request for first safety data or the write request for second safety data. In response to a determination that the first communication comprises the read request for first safety data, the first processing circuit sends via the first communication interface the second communication in accordance with the CIP Safety industrial safety protocol, wherein the second communication comprises the first safety data. Instead, in response to a determination that the first communication comprises the write request for the second safety data, the first processing circuit sends the received second safety data via the communication channel to the second processing circuit.

[0036] Similarly, the second processing circuit is configured to receive via the second communication interface the third communication in accordance with the openSAFETY industrial safety protocol and analyze the third communication to determine whether the third communication comprises the read request for the second safety data or the write request for the first safety data. In response to a determination that the third communication comprises the read request for the second safety data, the second processing circuit sends via the second communication interface the fourth communication in accordance with the openSAFETY industrial safety protocol, wherein the fourth communication comprises the second safety data. Instead, in response to a determination that the third communication comprises the write request for the first safety data, the second processing circuit sends the received first safety data via the communication channel to the first processing circuit.

[0037] In particular, in various embodiments, the first communication interface and the first processing circuit implement an EtherNet / IP Adapter node and a CIP Safety Target node, and the second communication interface and the second processing circuit implement a POWERLINK Controlled node and an openSAFETY Safety slave node.

[0038] In various embodiments, the gateway module also comprises a first monitoring circuit and a second monitoring circuit, for example implemented with respective microprocessors, wherein the first monitoring circuit is configured to monitor the operation of the first processing circuit and the second monitoring circuit is configured to monitor the operation of the second processing circuit.

[0039] Brief description of the figures

[0040] The embodiments of the present description will now be described with reference to the accompanying drawings, which are provided by way of non-limiting example only, and in which:

[0041] - Figure 1 shows an example of an industrial plant comprising a plurality of stations;

[0042] - Figure 2 schematically shows the EtherNet / IP protocol;

[0043] - Figure 3 schematically shows the POWERLINK protocol;

[0044] - Figure 4 shows an embodiment of an industrial plant according to the present description;

[0045] - Figure 5 shows an embodiment of a gateway module for the plant of Figure 4;

[0046] - Figures 6 and 7 show embodiments of the operation of the gateway module of Figure 5;

[0047] - Figures 8 and 9 show embodiments of the management of inputs and outputs of the gateway module of Figure 5; and - Figures 10A to 10D show embodiments of the data exchanged with the gateway module of Figure 5.

[0048] Detailed Description

[0049] In the following description, numerous specific details are given to provide a thorough understanding of the embodiments. The embodiments can be implemented without one or several specific details, or with other procedures, components, materials, etc. In other cases, well-known operations, materials or structures are not shown or described in detail so as not to obscure aspects of the embodiments.

[0050] A reference throughout this description to "an embodiment" means that a particular feature, distinctive element or structure described in connection with the embodiment is included in at least one embodiment. Thus, the appearances of the phrases "in one embodiment" in various places throughout this description do not necessarily all refer to the same embodiment. Furthermore, the particular features, distinctive elements or structures can be combined in any suitable manner in one or more embodiments.

[0051] The references used herein are provided merely for convenience and therefore do not define the scope of protection or the scope of the embodiments.

[0052] In the following Figures 4 to 10, the parts, elements or components that have already been described with reference to Figures 1 to 3 are indicated with the same references used previously in those Figures; the description of such previously described elements will not be repeated hereafter in order not to overload the present detailed description.

[0053] As mentioned previously, various embodiments of the present description concern a gateway module configured to implement communication between two industrial safety protocols, such as for example CIP Safety and openSAFETY.

[0054] Figure 4 shows an embodiment of an industrial plant 1 a according to the present description. In particular, the industrial plant 1 a comprises one or more stations 2a. For example, the stations 2a can be industrial robots, or other processing and / or monitoring stations.

[0055] In various embodiments, similar to what was described with reference to Figure 1 , the station 2a comprises a control system 22, for example comprising a PLC. Said control system 22 is connected by means of a communication system 20 to one or more actuators and / or sensors of the station (not shown in the figure). For example, the actuators and sensors can be associated with a robot arm. In various embodiments, the communication system 20 is based on the POWERLINK protocol.

[0056] Furthermore, the industrial plant 1a comprises a further communication system 10 and a further control system 12 which performs plant-level controls. In various embodiments, the communication system 10 is based on the EtherNet / IP protocol.

[0057] In particular, in various embodiments the plant 1 a is configured to exchange safety information between the communication system 10 and one or more of the communication systems 20. For example, in various embodiments, each station 20 has associated (for example comprises) a gateway module 40 configured to exchange safety data between the communication systems 10 and 20.

[0058] In particular, as shown in Figure 5, in various embodiments, the gateway module 40 comprises a circuit comprising a first communication interface 402 for the communication system 10 and a processing circuit 406 comprising, for example, a microprocessor programmed via software code and / or a Field Programmable Gate Array (FPGA).

[0059] As mentioned previously, the communication system 10 can use EtherNet / IP. Therefore, in various embodiments, the communication interface 402 and the processing circuit 406 are configured to implement the various layers of the EtherNet / IP protocol as shown in Figure 2. For example, in various embodiments, the communication interface 402 is configured to implement the physical layer 100 and the MAC layer 102 of the Ethernet protocol. In this case, the upper layers of the protocol, in particular the IP 104, UDP 106 and / or TCP 108 protocols, can be implemented in the processing circuit 406. In various embodiments, the MAC layer 102 can be implemented in the processing circuit 406, or the IP protocol 104, the UDP protocol 106 and / or the TCP protocol 108 can be implemented in the communication interface 402. For example, in various embodiments, the communication interface 402 is an Ethernet communication interface (without the IP layers 104, 106 and 108). or an EtherNet / IP communication interface (with the IP layers 104, 106 and 108). In various embodiments, the processing circuit 406 is also configured to implement the safety protocol of the communication system 10. For example, for this purpose, the processing circuit 406 can implement the CIP protocol 110, in particular at least the related CIP Safety extension 112. In particular, CIP Safety communication is not encapsulated in existing CIP objects. CIP Safety, instead, adds dedicated classes (and related instances) to manage safety communication.

[0060] For example, an object is associated with a Safety Validator. The main role of this object is to operate as a manager of the safety transport of multiple low-level CIP connections that together form a complete safety connection. In particular, in various embodiments, the processing circuit 406 is configured to manage two objects: a first object corresponds to a client configured to control incoming data and a second object corresponds to a server configured to assemble the messages that the gateway node must produce.

[0061] In this context, in various embodiments, the processing circuit 406 manages an object associated with so-called Safety Assemblies. In particular, a first instance of this object defines the sets of application objects that are input to the Safety Validator client to assemble the safety frames, i.e. , the mapping between the objects and the safety frame to be sent. Another instance of the Safety Assembly object performs the same role for the reverse path, i.e., it defines how to disassemble the received data once validated by the Safety Validator server.

[0062] In various embodiments, the processing circuit 406 manages an object associated with a Safety supervisor configured to manage asynchronous safety tasks, for example communication, connection properties and node status.

[0063] The CIP Safety protocol uses the low-level CIP connection to transport data. Therefore, in various embodiments, the (client and server) instances of Safety Validator use the CIP connection (CIP I / O Connection), while asynchronous communications are carried out via explicit messages. The details of the CIP Safety protocol are well known and available at the following link: https: / / www.odva.org / technology-standards / distinct-cip- services / cip-safety / .

[0064] In various embodiments, the circuit of the gateway module 40 also comprises a second communication interface 404 for the communication system 20 and a processing circuit 408 comprising, for example, a microprocessor programmed via software code and / or an FPGA.

[0065] As mentioned before, the communication system 20 can use POWERLINK. Therefore, in various embodiments, the communication interface 404 and the processing circuit 408 are configured to implement the various layers of the POWERLINK protocol as shown in Figure 3. For example, in various embodiments, the communication interface 404 is configured to implement the physical layer 200, the MAC layer 202 and the data link layer 204 of the POWERLINK protocol. In this case, the upper layers of the protocol, in particular the IP protocol 206, the UDP protocol 208 and / or the TCP protocol 210, can be implemented in the processing circuit 408. In various embodiments, the MAC layer 202 and the data link layer 204 can also be implemented in the processing circuit 404, or the IP protocol 206, the UDP protocol 208 and / or the TCP protocol 210 can be implemented in the communication interface 404. For example, in various embodiments, the communication interface 404 is a POWERLINK communication interface (with or without IP stack 206, 208 and 210).

[0066] In various embodiments, the processing circuit 408 also implements the safety protocol of the communication system 20. For example, for this purpose, the processing circuit 408 can implement the openSAFETY protocol 216.

[0067] For this purpose, openSAFETY messages are encapsulated in POWERLINK objects. The details of the openSAFETY protocol are well known and for example available at the following link: https: / / opensafety.sourceforge.io / doc / html / . For example, in various embodiments, a Receive Process Data Object RxSPDO of the openSAFETY protocol is associated with a first POWERLINK object, for example 0x4000 / 0x01 , where 0x4000 corresponds to the object index and 0x01 corresponds to the sub-index. Similarly, a Transmit Process Data Object TxSPDO of the openSAFETY protocol is associated with a second POWERLINK object, for example 0x4001 / 0x01. Therefore, in various embodiments, both RxSPDO and TxSPDO are mapped onto generic container objects to allow an arbitrary frame size based on the actual size of the transported safety data. In various embodiments, the response address of the safety Service Data Object (SDO), also identified as SSDO, is associated with a third POWERLINK object, for example 0x2110 / 0x01. Therefore, to encapsulate the SSDO response produced by the safety nodes, no-objects (dummy object entries) are assigned. In this case the received payload is forwarded directly to the recipient node using the coordinates, i.e., the node address and object index / sub-index, for example 0x2110 / 0x01 .

[0068] In various embodiments, the request of the SSDO object is associated with a fourth POWERLINK object, for example 0x2130 / 0x01. The data written in this object is forwarded to the safety node.

[0069] In particular, in various embodiments, the communication interface 402 and the processing circuit 406 implement a slave node of the safety protocol used for the communication system 10. For example, in various embodiments, the gateway 40 is configured to implement a peripheral node of the communication system 10, such as for example an Adapter node of the EtherNet / IP protocol and a Target node of the CIP Safety protocol. For example, the communication interface 402 can implement the EtherNet / IP Adapter node and the processing circuit 406 can implement the CIP Safety Target node.

[0070] Furthermore, in various embodiments, the communication interface 404 and the processing circuit 408 implement a slave node of the safety protocol used for the communication system 20. For example, in various embodiments, the gateway 40 is configured to implement a peripheral node of the communication system 20, such as for example a Controlled node of the POWERLINK protocol and a Safety slave node of the openSAFETY protocol. For example, the communication interface 404 can implement a POWERLINK Controlled node and the processing circuit 408 can implement the openSAFETY Safety slave node.

[0071] Therefore, as also shown in Figure 4, in various embodiments, the station 2a comprises a controller / master node 24 configured to send through the communication system 20 a request to the interface 404 of the gateway 40. For example, in various embodiments, the controller node 24 is configured to send openSAFETY communications through a POWERLINK communication system 20, i.e., the controller node 24 is a Safety Master Node of the openSAFETY protocol. In various embodiments, the controller node 24 can be implemented in the control system 22.

[0072] In various embodiments, the plant 1 a comprises a controller / master node 14 configured to send through the communication system 10 requests to the communication interface 402 of the gateway 40. For example, in various embodiments, the controller node 14 is configured to send CIP Safety communications through an EtherNet / IP communication system 10, i.e. , the controller node 14 is an Originator Node of the CIP Safety protocol. In various embodiments, the controller node 14 can be implemented in the control system 12.

[0073] In various embodiments, the requests can be read requests or write requests. In particular, as will be described in greater detail below, in various embodiments, the communication interface 402 and the processing circuit 406 are configured to receive from the controller node 14 via the respective safety protocol a write request comprising first safety data, and store the first safety data. Subsequently, in response to a read request received from the controller node 24 via the respective safety protocol, the communication interface 404 and the processing circuit 408 provide the first safety data to the controller node 24. Additionally or alternatively, in various embodiments, the communication interface 404 and the processing circuit 408 are configured to receive from the controller node 24 via the respective safety protocol a write request comprising second safety data, and store the second safety data. Subsequently, in response to a read request received from the controller node 14 via the respective safety protocol, the communication interface 402 and the processing circuit 406 provide the second safety data to the controller node 14. For example, this is schematically shown in Figure 5, wherein the processing circuits 406 and 408 exchange safety data SD.

[0074] Figures 6 and 7 show an embodiment of the gateway module 40. In particular, Figure 6 shows the part of the circuit used to send safety data from the controller node 14 to the controller node 24, and Figure 7 shows the part of the circuit used to send safety data from the controller node 24 to the controller node 14. Therefore, the gateway module 40 comprises both components, and the same references will be used for common elements.

[0075] In the embodiment considered, the communication interface 402 is configured to be connected via the communication system 10 to the controller node 14 and the communication interface 404 is configured to be connected via the communication system 20 to the controller node 24. For example, for this purpose, the gateway module 40 can comprise a first RJ- 45 socket connected to the communication interface 402 and a second RJ- 45 socket connected to the communication interface 404.

[0076] In particular, in the embodiment considered, the processing circuit 406 comprises a memory, for example one or more registers, preferably with redundant configuration, configured to store first safety data SD1 and second safety data SD2. Similarly, the processing circuit 408 comprises a memory, for example one or more registers, preferably with redundant configuration, configured to store first safety data SD1 and second safety data SD2.

[0077] In the embodiment considered, the processing circuit 406 is configured to receive via the communication interface 402 a data packet of the respective safety protocol, for example a data packet of the CIP Safety protocol. For example, for this purpose, when the communication interface 402 receives a communication, the communication interface 402 generates signals RX1 to send the received data to the processing circuit 406. For example, in various embodiments, the processing circuit 406 implements the CIP Safety protocol 112. Therefore, in this case the communication interface implements the entire EtherNet / IP stack.

[0078] In various embodiments, the processing circuit 406 then analyzes the received data to determine whether the received data packet comprises a read request for safety data or a write request for safety data.

[0079] In particular, in response to a determination that the received data comprises a write request for safety data, the processing circuit 406 can store the received safety data as safety data SD2.

[0080] Furthermore, as shown in Figure 6, in the embodiment considered, the processing circuit 406 generates one or more signals to send the received safety data or the stored safety data SD2 to the processing circuit 408. In particular, in various embodiments, the processing circuit 406 and the processing circuit 408 are connected for this purpose via a communication system SI1 that uses a serial communication protocol (synchronous or asynchronous). For example, in various embodiments, the processing circuits 406 and 408 are connected via a LIART (Universal Asynchronous Receiver-Transmitter), SPI (Serial Peripheral Interface), or l2C (Inter Integrated Circuit) interface.

[0081] Therefore, in various embodiments, the processing circuit 408 receives via the communication SI1 the safety data SD2 sent by the communication circuit 406 and stores this data SD2 in the memory.

[0082] Instead, as shown in Figure 7, in various embodiments, in response to a determination that the received data comprises a read request for safety data, the processing circuit 406 transmits via the communication interface 402 the safety data SD1. For example, for this purpose the processing circuit 406 generates signals TX1 to send the safety data SD1 to the communication interface 402. For example, in various embodiments, the signal TX1 can transmit the CIP Safety data. Therefore, in various embodiments, the processing circuit 406 is configured to transmit the data SD1 to the controller node 14. In various embodiments, the processing circuit 406 can also transmit the data SD2 stored in the processing circuit 406. For example, in this way the controller node 14 can verify the correct writing of the data SD2.

[0083] In various embodiments, a complementary operation is also implemented in the processing circuit 408.

[0084] In particular, as shown in Figure 7, in the embodiment considered, the processing circuit 408 is configured to receive via the communication interface 404 a data packet of the respective safety protocol, for example a data packet of the openSAFETY protocol. For example, for this purpose, when the communication interface 404 receives a communication, the communication interface 404 generates signals RX2 to send the received data to the processing circuit 408. For example, in various embodiments, the processing circuit 408 implements the openSAFETY protocol 216. Therefore, in this case the communication interface implements the entire POWERLINK stack.

[0085] In various embodiments, the processing circuit 408 then analyzes the received data to determine whether the received data packet comprises a read request for safety data or a write request for safety data.

[0086] In particular, in response to a determination that the received data comprises a write request for the safety data, the processing circuit 408 can store the received safety data as safety data SD1 . Furthermore, as shown in Figure 7, in the embodiment considered, the processing circuit 408 generates one or more signals to send the received safety data or the stored safety data SD1 to the processing circuit 406. In particular, in various embodiments, the processing circuit 406 and the processing circuit 408 are connected for this purpose by means of a communication system SI2 that uses a serial communication protocol (synchronous or asynchronous). For example, in various embodiments, the processing circuits 406 and 408 are connected by means of a LIART (Universal Asynchronous Receiver-Transmitter) interface, SPI (Serial Peripheral Interface), or l2C (Inter Integrated Circuit).

[0087] Therefore, in various embodiments, the processing circuit 406 receives via the communication SI2 the safety data SD1 sent by the communication circuit 408 and stores this data SD1 in the memory.

[0088] Instead, as shown in Figure 6, in various embodiments, in response to a determination that the received data comprises a read request for the safety data, the processing circuit 408 transmits via the communication interface 404 the safety data SD2. For example, for this purpose the processing circuit 408 generates signals TX2 to send the safety data SD2 to the communication interface 404. For example, in various embodiments, the signal TX2 can transmit the openSAFETY data. Therefore, in various embodiments, the processing circuit 408 is configured to transmit the data SD2 to the controller node 24. In various embodiments, the processing circuit 408 can also transmit the data SD1 stored in the processing circuit 408. For example, in this way the controller node 24 can verify the correct writing of the data SD1 .

[0089] Therefore, in various embodiments, the processing circuit 406 analyzes the communications in accordance with the safety protocol of the communication system 10 to read the data SD1 and write the data SD2. Instead, the processing circuit 408 analyzes the communications in accordance with the safety protocol of the communication system 20 to read the data SD2 and write the data SD1. Furthermore, the processing circuits 406 and 408 are connected by means of a communication system, for example SI1 and SI2, to exchange the data SD1 and SD2 between the processing circuits 406 and 408.

[0090] However, since the data SD1 and SD2 are safety data, for example data that can cause malfunctions and are relevant for the safety of persons, the gateway module 40 should also guarantee correct operation. For example, the processing circuits 406 and 408 can also present malfunctions. For example, in this case, the exchange of the data SD1 and SD2 between the processing circuits 406 and 408 may not be guaranteed.

[0091] For this reason, in various embodiments, the processing circuit 406 can have associated a monitoring circuit 410 and the processing circuit 408 can have associated a monitoring circuit 412. For example, in various embodiments, each of the circuits 406, 408, 410 and 412 is implemented with a respective microprocessor, for example a respective microcontroller.

[0092] In particular, in various embodiments, the circuit 406 can also send the received CIP Safety requests to the monitoring circuit 410.

[0093] For example, as shown in Figure 6, in response to the reception of a write request for the data SD2, the monitoring circuit 410 can enable the communication SI1 between the processing circuit 406 and the processing circuit 408. For example, in the embodiment considered, the communication

[0094] 511 is an SPI communication, wherein the circuit 406 is configured as an SPI master, and the circuit 408 is configured as an SPI slave. In this case, the processing circuit 408 can comprise an SPI slave interface that is enabled by means of a signal CS1. In a complementary manner, the processing circuit 406 is configured to assert a signal CS1 a when the processing circuit 406 transmits requests / data through the communication channel SI1. Therefore, in the embodiment considered, the gateway 40 comprises a logic gate 4000, for example an AND gate, configured to assert the signal CS1 when the signal CS1 a is asserted and a signal CS1 b is asserted, wherein the monitoring circuit 410 is configured to assert the signal CS1 b when a write request for the data SD2 is received via the CIP Safety communication.

[0095] Similarly, in various embodiments, the circuit 408 can also send the received openSAFETY requests to the monitoring circuit 412.

[0096] For example, as shown in Figure 7, in response to the reception of a write request for the data SD1 , the monitoring circuit 412 can enable the communication SI2 between the processing circuit 408 and the processing circuit 406. In various embodiments, the communication systems SI1 and

[0097] 512 are two distinct communication systems. For example, in the embodiment considered, the communication SI2 is an SPI communication, wherein the circuit 408 is configured as an SPI master, and the circuit 406 is configured as an SPI slave. In this case, the processing circuit 406 can comprise an SPI slave interface that is enabled by means of a signal CS2. In a complementary manner, the processing circuit 408 is configured to assert a signal CS2a when the processing circuit 408 transmits requests / data through the communication channel SI2. Therefore, in the embodiment considered, the gateway 40 comprises a logic gate 4002, for example an AND gate, configured to assert the signal CS2 when the signal CS2a is asserted and a signal CS2b is asserted, wherein the monitoring circuit 412 is configured to assert the signal CS2b when a write request for the data SD1 is received via the openSAFETY communication.

[0098] Additionally or alternatively, in various embodiments, the monitoring circuit 412 monitors the communication sent from the processing circuit 406 to the processing circuit 408. For example, as shown in Figure 6, in various embodiments, the monitoring circuit 412 comprises an SPI slave interface that receives the data sent through the communication system SI1 , wherein the SPI slave interface is enabled by means of the signal CS1. Therefore, thanks to the data exchange between the processing circuit 408 and the monitoring circuit 412, the circuits 408 and 412 can verify the correct reception of the data SD2.

[0099] Similarly, in various embodiments, the monitoring circuit 410 monitors the communication sent from the processing circuit 408 to the processing circuit 406. For example, as shown in Figure 7, in various embodiments, the monitoring circuit 410 comprises an SPI slave interface that receives the data sent through the communication system SI2, wherein the SPI slave interface is enabled by means of the signal CS2. Therefore, thanks to the data exchange between the processing circuit 406 and the monitoring circuit 410, the circuits 406 and 410 can verify the correct reception of the data SD1 .

[0100] For example, as will be described in greater detail later, when the monitoring circuit 410 detects errors, the monitoring circuit 410 can disable the communication interface 402, as schematically shown by means of a signal EN1 , and / or disable the communication from the processing circuit 406 to the processing circuit 408. Similarly, when the monitoring circuit 412 detects errors, the monitoring circuit 412 can disable the communication interface 404, as schematically shown by means of a signal EN2, and / or disable the communication from the processing circuit 408 to the processing circuit 406.

[0101] In various embodiments, the processing circuits 406 and 408 are configured to send their respective data with redundancy, for example by sending each bit of their respective data SD1 or SD2 at least twice, and / or including one or more parity bits or ECC (Error-correcting code). For example, the processing circuit 406 can send the data SD2 via the communication system SI1 to the circuits 408 and 412 with a data packet that comprises the data SD2 twice and / or additional parity bits or ECC. In this way, each receiving circuit can verify the correct transmission of the data.

[0102] Additionally or alternatively, in various embodiments, the processing circuits 406 and 408 are configured to periodically send a packet that signals that the respective circuit 406 or 408 is still operational. For example, the processing circuit 406 can periodically send a data packet via the communication system SI1 to the circuits 408 and 412. For this purpose, the processing circuit 406 can signal to the monitoring circuit 410 the sending of the data packet, and the monitoring circuit 410 can enable the communication channel SI1 , for example by asserting the signal CS1 b. Therefore, in this way, each receiving circuit can determine that the communication through the respective communication system SI1 or SI2 is still operational, for example by verifying if a new data packet is received within a maximum time.

[0103] In various embodiments, as also shown in Figure 5, the processing circuit 406 and / or the processing circuit 408 can be configured to interface one or more sensors 42 and / or one or more actuators 44.

[0104] For example, in various embodiments, a write request can comprise safety data SD4 for driving the actuator or actuators 44 (see also the description of Figure 9). Conversely, in response to a read request, the gateway 40 can return safety data SD3 indicating the status of the sensor or sensors 42 (see also the description of Figure 8).

[0105] For example, in various embodiments, the processing circuit 406 comprises an interface for connection to one or more sensors and / or actuators. For example, in various embodiments, the write request received from the controller node 14 comprises, in addition to the safety data SD2 to be forwarded to the processing circuit 408, also the data SD4 for driving the actuator or actuators 44. Furthermore, in response to a read request received from the controller node 14, the processing circuit 406 sends a response that comprises, in addition to the safety data SD1 received from the processing circuit 408, also the safety data SD3 indicative of the status of the sensor or sensors 42.

[0106] For example, in this way, a sensor 42 can correspond to an emergency button. Instead, the actuator 44 can be a controllable switch, such as for example a relay or an electronic switch, for example configured to interrupt the power supply of one or more components of the station 2a. For example, in this way, the controller node 14 can receive the data SD3 that comprise the status of the button, by periodically sending read requests to the communication interface 402. Subsequently, in response to a determination that the emergency button has been activated, the controller node 14 can send a write request to the communication interface 402 that comprises data SD4 indicating a request to deactivate the switch 44.

[0107] For example, Figure 8 shows an embodiment of the connection of a sensor 42 to the processing circuit 406. In particular in the embodiment considered, the gateway module 40 comprises a circuit 414 configured to interface the processing circuit 406 with an emergency button 42.

[0108] For example, in the embodiment considered, the emergency button 42 comprises a push-button 420 that allows actuating a switch 422. For example, in various embodiments, the switch 422 is normally closed and the emergency button 42 is configured to open the switch 422 in response to an actuation of the push-button 420.

[0109] In various embodiments, the circuit 414 is configured to provide a signal MS1 indicative of the status of the switch 422. For example, in the embodiment considered, a first terminal INI P of the switch 422 is connected to a power supply 4140, for example 24 VDC, and a second terminal IN1 M of the switch 422 is connected to a sensor configured to provide a signal MS1 indicative of the voltage at the second terminal of the switch 422.

[0110] For example, in the embodiment considered, the sensor is implemented with a voltage divider comprising two resistors R1 and R2 connected in series between the terminal IN1 M and ground. Therefore, the intermediate point between the resistors R1 and R2 provides a voltage that is proportional to the voltage at the second terminal IN1 M of the switch 422. Therefore, the signal MS1 can be determined as a function of the voltage across the resistor R2. For example, in the embodiment considered, the signal MS1 is provided by a comparator 4142 that receives as input the voltage across the resistor R2. Therefore, in various embodiments, the signal MS1 is normally asserted (for example high) and when the pushbutton 420 is actuated, the signal is de-asserted.

[0111] In various embodiments, the circuit 414 can also comprise a test circuit for verifying an erroneous connection of the switch 422. For example, for this purpose, the circuit 414 can be configured to selectively interrupt the connection of the first terminal IN 1 P of the switch 422 to the power supply 4140. For example, in the embodiment considered, the circuit 414 comprises a switch 4142, preferably an electronic switch, connected between the first terminal IN1 P of the switch 422 and the power supply 4140. For example, in this way, the processing circuit 406 can generate a control signal CS1 that drives the switch 4142, for example by means of a driver circuit 4144, so as to open the switch 4142, for example periodically. Subsequently, the processing circuit 406 can verify whether the signal MS1 is also de-asserted when the control signal CS1 opens the switch. In various embodiments, the processing circuit 406 is configured to open the switch 4142 periodically for a short time, for example a time chosen between 1 ms (milliseconds) and 50 ms, preferably between 1 ms and 10 ms. For example, in various embodiments, the processing circuit 406 is configured to open the switch 4142 for 5 ms every 32 ms.

[0112] Therefore, in the embodiment considered, the processing circuit 406 can generate the safety data SD3 as a function of the signal MS1 , and possibly of the control signal CS1 . For example, a first bit of the safety data SD3 can indicate whether the signal MS1 is asserted (the button 42 is not actuated) or de-asserted (the button 42 is actuated). Furthermore, a bit can indicate the result of the tests via the control signal CS1 .

[0113] Therefore, in the embodiment considered, the controller node 14 can send via the communication system 10 and the communication interface 402 a read request for the safety data SD3 to the processing circuit 406. In response to this read request, the processing circuit 406 sends a response that comprises the safety data SD3. As mentioned previously, the processing circuit 406 can send the data SD3 with the data SD1 .

[0114] Therefore, in various embodiments, the processing circuit 406 comprises at least one input terminal (e.g., terminal IN1 M) and for each input terminal a respective bit of the safety data SD3. In this way, the processing circuit 406 is configured to determine the logic level of each input terminal and assert or de-assert the respective bit of the safety data SD3 as a function of the determined logic level. Additionally, in various embodiments, the processing circuit 406 comprises at least one test output terminal (e.g., IN1 P) for generating a pulsed signal useful for verifying the connection of a switch between a respective input terminal and the test terminal. For example, in this case, the processing circuit 406 can assert or de-assert a respective diagnosis bit of the safety data SD3 as a function of the logic level of the respective input terminal during the test, for example, when the pulsed signal is low.

[0115] In various embodiments, the monitoring circuit 410 can be used to implement redundant monitoring of the emergency button. For this purpose, the button 42 can comprise a second switch 424, wherein a first terminal IN2P of the switch 424 is connected to a power supply 4146, which can also correspond to the power supply 4140, and a second terminal IN2M of the switch 424 is connected to a second sensor configured to generate a signal MS2 indicative of the voltage at the second terminal of the switch 424. For example, in the embodiment considered, the sensor comprises a voltage divider R3 and R4 connected between the terminal IN2M and ground, and a comparator 4148 configured to generate the signal MS2 as a function of the voltage across the resistor R4. For a description of these components, reference can be made to the description of components 422, R1 , R2 and 4142, which applies by analogy.

[0116] In various embodiments, the circuit 414 also comprises a switch 4150, and possibly a driver circuit 4152, configured to selectively interrupt the connection between the first terminal of the switch 424 and the power supply 4146 as a function of a control signal CS2. For a description of these components, reference can be made to the description of components 4142 and 4144, which applies by analogy. Therefore, in various embodiments, the monitoring circuit 410 can generate the control signal CS2 to selectively open the power supply of the switch 424 and verify the status of the measurement signal MS2.

[0117] In various embodiments, a respective diagnosis bit of the data SD3 can be associated with the test performed with the control signal CS2. Alternatively, the processing circuit 406 can determine the value of a single diagnosis bit as a function of the tests performed via the control signal CS1 and (via synchronization with the monitoring circuit 410) the control signal CS2.

[0118] Instead, Figure 9 shows an embodiment of the connection of an actuator 44 to the processing circuit 406. In particular in the embodiment considered, the gateway module 40 comprises a circuit 416 configured to interface the processing circuit 406 with the actuator 44.

[0119] In particular, in the embodiment considered, the actuator 44 is configured to selectively provide a voltage to a terminal 446. For example, the voltage provided via the terminal 446 can be used to power an electromechanical actuator or another electrical load.

[0120] For example, in the embodiment considered, the actuator 44 comprises an electrically controllable switch 444 configured to connect the terminal 446 to a power supply 440 as a function of a control signal CS3. For example, the switch 444 can be a relay or an electronic switch.

[0121] Therefore, in this way, the processing circuit 406 can receive a write request for the safety data SD4 and store the respective received data. As mentioned previously, the write request can also comprise the safety data SD2. Furthermore, the processing circuit 406 can generate the control signal CS3 as a function of the safety data SD4, for example as a function of a respective bit of the safety data SD4.

[0122] In various embodiments, the circuit 416 also comprises a sensor configured to generate a measurement signal MS3 indicative of the state of the output 446. For example, in the embodiment considered, the sensor comprises a voltage divider R5 and R6 connected between the terminal 446 and ground, and a comparator 4160 configured to generate the signal MS3 as a function of the voltage across the resistor R6. For a description of these components, reference can be made to the description of components R1 , R2 and 4142, which applies by analogy. Therefore, in this way, the processing circuit 406 can assert or de-assert a respective bit of the safety data SD3 as a function of the logic level of the signal MS3.

[0123] A redundant configuration can also be used in this case. For example, in the embodiment considered, the actuator 44 comprises a second electrically controllable switch 442 connected in series with the switch 444 between the terminal 446 and the power supply 440, wherein the switch 442 is driven by means of a control signal CS4. For example, the switch 442 can be a relay or an electronic switch.

[0124] In various embodiments, the circuit 416 also comprises a second sensor configured to generate a measurement signal MS4 indicative of the state of the output 446. In particular, in the embodiment considered, the signal MS4 is generated as a function of the voltage at the intermediate node between the switches 442 and 444. For example, in the embodiment considered, the sensor comprises a voltage divider R7 and R8 connected between the intermediate node and ground, and a comparator 4162 configured to generate the signal MS4 as a function of the voltage across the resistor R8. For a description of these components, reference can be made to the description of components R1 , R2 and 4142, which applies by analogy.

[0125] Therefore, in various embodiments, the data SD3 can comprise two diagnosis bits, respectively for the signal MS3 and the signal MS4. Alternatively, the processing circuit 406 can determine the value of a single diagnosis bit as a function of the signal MS3 and (via synchronization with the monitoring circuit 410) the signal MS4, possibly also taking into account the logic level of the bit used to generate the signals CS3 and CS4. For example, in various embodiments, the diagnosis bit is asserted when the signals MS3 and MS4 are high, and the bit of the data SD4 indicates that the output 446 must be powered, or the signals MS3 and MS4 are low, and the bit of the data SD4 indicates that the output 446 must not be powered. Otherwise the diagnosis bit is de-asserted.

[0126] Figures 10A to 10D show an embodiment of the structure of the data that are sent via the safety communications.

[0127] In particular, Figure 10A shows an embodiment of the data received by the processing circuit 406 with a write request. In particular, in the embodiment considered, the data extracted from the safety communication of a write request comprise the safety data SD2 and the data SD4 (if provided). For example, in the embodiment considered, the data packet comprises 64 bits wherein bits 0 to 55 correspond to the safety data SD2 and bits 56 to 63 correspond to the safety data SD4.

[0128] Instead, Figure 10B shows an embodiment of the data sent to the processing circuit 406 in response to a read request. In particular, in the embodiment considered, the data sent via the safety communication comprise the safety data SD1 and the data SD3 (if provided). For example, in the embodiment considered, the data packet comprises 64 bits wherein bits 0 to 55 correspond to the safety data SD1 and bits 57 to 63 correspond to the safety data SD3.

[0129] As explained previously, the processing circuits 406 and 408 are configured to transmit the safety data SD2 from the processing circuit 406 to the processing circuit 408. Similarly, the processing circuits 406 and 408 are configured to transmit the safety data SD1 from the processing circuit 408 to the processing circuit 406. Instead, the data SD3 and SD4 can be used for controlling input and output terminals.

[0130] For example, with reference to Figure 8, the circuit 414 can be integrated into the gateway 40. In this case, the gateway comprises a terminal IN1 P connected via the switch 4142 to the power supply 4140 and a terminal IN1 M connected to the sensor R1 , R2 and 4142, for example the terminal IN1 M is connected via the voltage divider R1 / R2 to ground. Therefore, the switch 422 of the emergency button should be connected between the terminals IN1 P and IN1 M. Similarly, in the embodiment considered, the gateway comprises a terminal IN2P connected via the switch 4150 to the power supply 4146 and a terminal IN2M connected to the sensor R3, R4 and 4148, for example the terminal IN2M is connected via the voltage divider R3 / R4 to ground. Therefore, the switch 424 of the emergency button should be connected between the terminals IN2P and IN2M.

[0131] Therefore, in this case, the processing circuit 406 can be configured to set the logic level of a bit IN1 of the data SD3 as a function of the logic level of the signal MS1 and the monitoring circuit 410 can be configured (via synchronization with the processing circuit 406) to set the logic level of a bit IN2 of the data SD3 as a function of the logic level of the signal MS2. As explained previously, the processing circuit 406 can be configured to periodically drive the switch 4142 via the signal CS1 to open the switch 4142 for a short time. Therefore, in various embodiments, the processing circuit 406 can assert a bit IN1 D when the processing circuit 406 detects that the signal MS1 also becomes low. Instead, when the logic level of the signal MS1 remains high, the processing circuit 406 can de-assert the bit IN1 D.

[0132] Similarly, the monitoring circuit 410 can be configured to periodically drive the driver circuit 4152 via the signal CS2 to open the switch 4150 for a short time. Therefore, in various embodiments, the monitoring circuit 410 can assert (via synchronization with the processing circuit 406) a bit IN2D when the monitoring circuit 410 detects that the signal MS2 also becomes low. Instead, when the logic level of the signal MS2 remains high, the monitoring circuit 410 can de-assert the bit IN2D.

[0133] Instead, with reference to Figure 9, the circuit 416 can also be integrated into the gateway 40. In this case, the gateway 40 comprises an output terminal 446. Therefore, in this case, the processing circuit 406 can be configured to generate the signal CS3 as a function of a bit OUT 1 of the data SD4. Similarly, the monitoring circuit 410 can be configured to set the signal CS4 as a function of a bit OUT1 of the data SD4 (for example via synchronization with the processing circuit 406).

[0134] Instead the signals MS3 and MS4 can be used to generate a diagnosis bit OUT1 D of the data SD3. For example, in various embodiments, the processing circuit 406 is configured to assert the bit OUT1 D in response to a determination that the signal MS3 is high and (via synchronization with the monitoring circuit 410) the signal MS4 is high. Instead, the processing circuit 406 is configured to de-assert the bit OUT1 D in response to a determination that the signal MS3 is low or (via synchronization with the monitoring circuit 410) the signal MS4 is low. As mentioned previously, the processing circuit can also take into account the logic level of the bit OUT1 .

[0135] In various embodiments, the gateway 40 can comprise a plurality of circuits 414 and / or 416. For example, in Figure 10A and 10B, bits OUT2 and OUT2D are shown which can be used as described previously for bits OUT 1 and OUT1 D. In various embodiments, the data SD1 can have an associated bit DVAL1 , for example bit 56. For example, the processing circuit 408 can be configured to assert this bit when the data received from the controller node 24 can be decoded by means of the safety protocol of the communication system 20. Instead, when the received data comprises errors, the processing circuit 408 can de-assert the bit DVAL1. For example, the bit DVAL1 can correspond to the bit "Module OK' of the openSAFETY protocol. Therefore, in various embodiments, the processing circuit 408 can transmit the bit DVAL1 together with the data SD1 to the processing circuit 406, and the processing circuit 406 can be configured to transmit the bit DVAL1 with the data SD1 to the controller node 14. In various embodiments, the bit DVAL1 can also be determined for a plurality of data SD1 transmissions, for example, the processing circuit 406 can be configured to assert the bit DVAL1 when the "Module OK" bit is zero for at least three consecutive transmissions.

[0136] Instead, Figure 10C shows an embodiment of the data received by the processing circuit 408 with a write request. In particular, in the embodiment considered, the data extracted from the safety communication of a write request comprises the safety data SD1. For example, in the embodiment considered, the data packet comprises 64 bits wherein bits 0 to 55 correspond to the safety data SD1 . As explained previously, in various embodiments, the circuits 414 and 416 are only provided on the side of the processing circuit 406.

[0137] Instead, Figure 10D shows an embodiment of the data sent to the processing circuit 408 in response to a read request. In particular, in the embodiment considered, the data sent by means of the safety communication comprises the safety data SD2 and optionally the data SD3. For example, in the embodiment considered, the data packet comprises 64 bits wherein bits 0 to 55 correspond to the safety data SD2.

[0138] In various embodiments, the data SD2 can have an associated bit DVAL2, for example bit 56. For example, the processing circuit 406 can be configured to assert this bit when the data received from the controller node 14 can be decoded by means of the safety protocol of the communication system 10. Instead, when the received data comprises errors, the processing circuit 406 can de-assert the bit DVAL2. For example, the bit DVAL2 can correspond to the bit "RUN / IDLE' of the CIP Safety protocol. Therefore, in various embodiments, the processing circuit 406 can transmit the bit DVAL2 together with the data SD2 to the processing circuit 408, and the processing circuit 408 can be configured to transmit the bit DVAL2 with the data SD2 to the controller node 24. In various embodiments, the bit DVAL2 can be determined for a plurality of data SD2 transmissions, for example, the processing circuit 406 can be configured to assert the bit DVAL2 when the "RUN / IDLE" bit is zero for at least three consecutive transmissions.

[0139] Therefore, in various embodiments, the processing circuit 406 writes the data SD2 and reads the data SD1 , and the processing circuit 408 writes the data SD1 and reads the data SD2. Therefore, these circuits do not analyze the data SD1 and SD2, but only forward this data, and the mapping of bits to respective functionalities is managed by the controller nodes 14 and 24.

[0140] In this context, the monitoring circuits 410 and 412 monitor the communications received by means of the interfaces 402 and 404 and exchanged between the processing circuits 406 and 408. However, the gateway module 40 can also have malfunctions, for example there can be malfunctions in the communications between the processing circuits 406 and 408, or in at least one of the communications through the communication systems 10 or 20.

[0141] In this context, the master node of an industrial safety protocol typically periodically monitors the availability of the peripheral nodes. Therefore, when a communication with the gateway module 40 is interrupted, the respective controller node 14 or 24 is able to determine the interruption and can perform operations to put the related system into a safe state. However, this also implies the fact that the gateway can no longer exchange safety data between the controller nodes 14 and 24. In various embodiments, to also signal the malfunction to the other controller node, the processing circuits 406 and 408 are configured to interrupt any communication with the controller nodes when a malfunction of the gateway module is detected, for example when a malfunction is detected in one of the processing circuits 406 and 408, one of the monitoring circuits 410 and 412, in the communications exchanged between the processing circuits 406 and 408 and in the communications exchanged through the communication interfaces 402 and 404. In fact, in this way, each of the controller nodes 14 and 24 detects the absence of response from the gateway module 40 and can take appropriate countermeasures.

[0142] Furthermore, in various embodiments, to signal the malfunction, the monitoring circuit 410 is configured to interrupt by means of the signal EN1 the communication with the controller node 14 and / or by means of the signal CS1 b the communication with the processing circuit 408. Similarly, the monitoring circuit 412 is configured to interrupt by means of the signal EN2 the communication with the controller node 24 and / or by means of the signal CS2b the communication with the processing circuit 406.

[0143] In various embodiments, the gateway module 40 comprises two network connectors connected to the communication interface 402 and two network connectors, typically RJ45 connectors, connected to the communication interface 404. In this case, the communication interface 402 can be configured as an Ethernet switch and the communication interface 404 can be configured as an Ethernet switch. Essentially, in this way, the communication interface 402 can be connected between two nodes of the communication system 10, thus reducing the cabling. Similarly, the communication interface 404 can be connected between two nodes of the communication system 20.

[0144] In various embodiments, the gateway module 40 can also provide further information by means of the communication interface 402 and / or 404. For example, the processing circuit 408 can provide diagnostic data on the processing circuit 406, such as, for example, the IP address, the IP subnet and the MAC address associated with the communication interface 402, and / or the status of the inputs and / or additional outputs managed by the processing circuit 406. Such data can also be managed only at the POWERLINK protocol level. For example, in various embodiments, the data is provided by means of a POWERLINK SDO.

[0145] Of course, without prejudice to the underlying principles of the invention, the construction details and the embodiments can vary widely with respect to what has been described and illustrated here purely by way of example, without thereby departing from the scope of the present invention, as defined by the appended claims.

Claims

CLAIMS1. Gateway module (40) for industrial safety protocols, the gateway module (40) comprising:- a first communication interface (402) configured to be connected to a first communication system (10) in accordance with the CIP Safety industrial safety protocol;- a second communication interface (404) configured to be connected to a second communication system (20) in accordance with the openSAFETY industrial safety protocol; wherein said gateway module (40) is configured to:- receive via said first communication interface (402) a first communication in accordance with the CIP Safety industrial safety protocol;- analyze said first communication to determine whether said first communication comprises a read request for first safety data (SD1 ) or a write request for second safety data (SD2);- in response to determining that said first communication comprises a read request for first safety data (SD1 ), send by means of said first communication interface (402) a second communication in accordance with the CIP Safety industrial safety protocol, wherein said second communication comprises said first safety data (SD1 );- in response to determining that said first communication comprises a write request for said second safety data (SD2), store said second safety data (SD2);- receive via said second communication interface (404) a third communication in accordance with the openSAFETY industrial safety protocol;- analyze said third communication to determine whether said third communication comprises a read request for said second safety data (SD2) or a write request for said first safety data (SD1 );- in response to determining that said third communication comprises a read request for said second safety data (SD2), send by means of said second communication interface (404) a fourth communication in accordance with the openSAFETY industrial safety protocol, wherein said fourth communication comprises said second safety data (SD2); and- in response to determining that said third communication comprises a write request for said first safety data (SD1), store said first safety data (SD1 ).

2. The gateway module according to Claim 1 , comprising a first processing circuit (406) and a second processing circuit (408) connected by means of a communication channel (SI1 , SI2), wherein said first processing circuit (406) is configured to:- receive via said first communication interface (402) said first communication in accordance with the CIP Safety industrial safety protocol;- analyze said first communication to determine whether said first communication comprises said read request for first safety data (SD1 ) or said write request for second safety data (SD2);- in response to determining that said first communication comprises said read request for first safety data (SD1 ), send via said first communication interface (402) said second communication in accordance with the CIP Safety industrial safety protocol, wherein said second communication comprises said first safety data (SD1 );- in response to determining that said first communication comprises said write request for said second safety data (SD2), send said received second safety data (SD2) to said second processing circuit (408); wherein said second processing circuit (408) is configured to:- receive via said second communication interface (404) said third communication in accordance with the openSAFETY industrial safety protocol;- analyze said third communication to determine whether said third communication comprises said read request for said second safety data (SD2) or said write request for said first safety data (SD1 );- in response to determining that said third communication comprises said read request for said second safety data (SD2), send via said second communication interface (404) said fourth communication in accordance with the openSAFETY industrial safety protocol, wherein said fourth communication comprises said second safety data (SD2); and- in response to determining that said third communication comprises said write request for said first safety data (SD1 ), send said received first safety data (SD1 ) to said first processing circuit (406).

3. The gateway module according to Claim 2, wherein said first processing circuit (406) and said second processing circuit (408) are connected by means of a serial communication channel.

4. The gateway module according to Claim 3, wherein said first processing circuit (406) and said second processing circuit (408) are connected by means of a Universal Asynchronous Receiver-Transmitter, Serial Peripheral Interface, or Inter Integrated Circuit communication channel.

5. The gateway module according to any one of the preceding claims from 2 to 4, wherein said first communication interface (402) and said first processing circuit (406) implement an EtherNet / IP Adapter node and a CIP Safety Target node, and said second communication interface (404) and said second processing circuit (408) implement a POWERLINK Controlled node and an openSAFETY Safety slave node.

6. The gateway module according to any one of the previous claims 2 to 5, comprising a first monitoring circuit (410) and a second monitoring circuit (412), wherein said first monitoring circuit (410) is configured to monitor the operation of said first processing circuit (406) and said second monitoring circuit (412) is configured to monitor the operation of said second processing circuit (408).

7. The gateway module according to Claim 6, comprising a first terminal (IN1 P), a second terminal (IN1 M), a third terminal (IN2P) and a fourth terminal (IN2M), wherein said first processing circuit (406) is configured to send via said first communication interface (402) a communication comprising third safety data (SD3); wherein said first processing circuit (406) is configured to:- connect (CS1 , 4140) said first terminal (IN1 P) to a first supply voltage (4140);- determine (R1 , R2, 4142) whether the voltage at said second terminal (IN1 M) is greater than a first threshold;- in response to determining that the voltage at said secondterminal (IN1 M) is greater than said first threshold, assert a first bit (IN1 ) of said third safety data (SD3);- in response to determining that the voltage at said second terminal (IN1 M) is not greater than said first threshold, de-assert said first bit (IN1 ) of third safety data (SD3); wherein said first monitoring circuit (410) is configured to:- connect (CS2, 4150) said third terminal (IN2P) to a second supply voltage (4146);- determine (R3, R4, 4148) whether the voltage at said fourth terminal (IN2M) is greater than a second threshold;- in response to determining that the voltage at said fourth terminal (IN2M) is greater than said second threshold, assert a second bit (IN2) of said third safety data (SD3);- in response to determining that the voltage at said fourth terminal (IN2M) is not greater than said second threshold, de-assert said second bit (IN2) of said third safety data (SD3).

8. The gateway module according to Claim 7, wherein said first processing circuit (406) is configured to:- periodically disconnect said first terminal (IN1 P) from said first supply voltage (4140);- determine (R1 , R2, 4142) whether the voltage at said second terminal (IN1 M) is greater than said first threshold;- in response to determining that the voltage at said second terminal (IN1 M) is not greater than said first threshold, assert a third bit (IN1 D) of said third safety data (SD3);- in response to determining that the voltage at said second terminal (IN1 M) is greater than said first threshold, de-assert said third bit (IN1 D) of third safety data (SD3); wherein said first monitoring circuit (410) is configured to:- periodically disconnect (CS2, 4150) said third terminal (IN2P) from said second supply voltage (4146);- determine (R3, R4, 4148) whether the voltage at said fourth terminal (IN2M) is greater than said second threshold;- in response to determining that the voltage at said fourth terminal (IN2M) is not greater than said second threshold, assert afourth bit (IN2D) of said third safety data (SD3); and- in response to determining that the voltage at said fourth terminal (IN2M) is greater than said second threshold, de-assert said fourth bit (IN2D) of said third safety data (SD3);9. The gateway module according to any of Claims 6 to 8, comprising a fifth terminal (446), and a first controllable switch (444) and a second controllable switch (442) connected in series between a power supply (440) and said fifth terminal (446), wherein said first processing circuit (406) is configured to receive via said first communication interface (402) a communication comprising fourth safety data (SD4), wherein said first processing circuit (406) is configured to:- drive said first controllable switch (444) to close said first controllable switch (444) when a given bit (OLIT1 ) of said fourth safety data (SD4) is asserted;- drive said first controllable switch (444) to open said first controllable switch (444) when said given bit (OLIT1 ) of said fourth safety data (SD4) is de-asserted; wherein said first monitoring circuit (410) is configured to:- drive said second controllable switch (442) to close said second controllable switch (442) when said given bit (OLIT1 ) of said fourth safety data (SD4) is asserted; and- drive said second controllable switch (442) to open said second controllable switch (442) when said given bit (OLIT1 ) of said fourth safety data (SD4) is de-asserted.

10. The gateway module according to Claim 9, wherein said first processing circuit (406) is configured to send via said first communication interface (402) a communication comprising third safety data (SD3), wherein said first processing circuit (406) and said first monitoring circuit (410) are configured to:- determine (R5, R6, 4160) whether the voltage at said fifth terminal (446) is greater than a third threshold;- determine (R7, R8, 4162) whether the voltage between said first controllable switch (444) and said second controllable switch (442) is greater than a fourth threshold;- when said data bit (OUT 1 ) is asserted:- in response to determining that said voltage at said fifth terminal (446) is greater than said third threshold and said voltage between said first controllable switch (444) and said second controllable switch (442) is greater than said fourth threshold, assert a fifth bit (OLIT1 D) of said third safety data (SD3);- in response to determining that said voltage at said fifth terminal (446) is not greater than said third threshold or said voltage between said first controllable switch (444) and said second controllable switch (442) is not greater than said fourth threshold, deassert said fifth bit (OLIT1 D) of said third safety data (SD3);- when said data bit (OUT 1 ) is de-asserted:- in response to determining that said voltage at said fifth terminal (446) is not greater than said third threshold and said voltage between said first controllable switch (444) and said second controllable switch (442) is not greater than said fourth threshold, assert said fifth bit (OUT1 D) of said third safety data (SD3);- in response to determining that said voltage at said fifth terminal (446) is greater than said third threshold or said voltage between said first controllable switch (444) and said second controllable switch (442) is greater than said fourth threshold, deassert said fifth bit (OUT1 D) of said third safety data (SD3).

11. A processing and / or monitoring station (2a), such as an industrial robot, comprising:- a gateway module (40) according to one of the preceding claims 1 to 10; and- a controller node (24) connected to the second communication interface (404) of said gateway module (40).

12. An industrial plant (1 a) comprising:- a plurality of processing and / or monitoring stations (2a) according to claim 11 ; and- a further controller node (14) connected to the first communication interface (402) of the gateway module (40) of each processing and / or monitoring station (2a).

13. A method for operating a gateway module according to one of the preceding claims 1 to 10, comprising:- receiving via said first communication interface (402) a first communication in accordance with the CIP Safety industrial safety protocol;- analyzing said first communication to determine whether said first communication comprises a read request for first safety data (SD1 ) or a write request for second safety data (SD2);- in response to determining that said first communication comprises a read request for first safety data (SD1 ), sending via said first communication interface (402) a second communication in accordance with the CIP Safety industrial safety protocol, wherein said second communication comprises said first safety data (SD1 );- in response to determining that said first communication comprises a write request for said second safety data (SD2), storing said second safety data (SD2);- receiving via said second communication interface (404) a third communication in accordance with the openSAFETY industrial safety protocol;- analyzing said third communication to determine whether said third communication comprises a read request for said second safety data (SD2) or a write request for said first safety data (SD1 );- in response to determining that said third communication comprises a read request for said second safety data (SD2), sending via said second communication interface (404) a fourth communication in accordance with the openSAFETY industrial safety protocol, wherein said fourth communication comprises said second safety data (SD2); and- in response to determining that said third communication comprises a write request for said first safety data (SD1 ), storing said first safety data (SD1 ).

Images