Time sensitive network simulator

Abstract

A Time-Sensitive Networking (TSN) simulator (3) is used to connect a first device (1) of a distributed control system (DCS) for an industrial facility to at least one second device (2) of the DCS configured as a TSN client. The TSN simulator (3) includes: a first interface (31) connectable to the first device (1); a second interface (32) connectable to the second device (2) and / or a TSN (5), the second device (2) being attached to the TSN (5); and a simulation unit (34) configured to forward network traffic (33) between the first interface (31) and the second interface (32), and modify and / or delay network traffic during forwarding, thereby simulating the behavior of a real, imperfect TSN providing communication between the first device (1) and the second device (2). A programmable logic controller (PLC) (4) with the TSN simulator (3). A method (100) for troubleshooting an abnormal operating state (A) in the cooperation between the first device (1) and the second device (2) using the TSN simulator (3). A method (200) for deploying a distributed control system DCS using a TSN simulator (3), the DCS having multiple devices (51, 52, 53) to be connected to a given time-sensitive network TSN (5).

Description

Technical Field

[0001] This invention relates to the field of Time-Sensitive Networks (TSNs), which can be used as communication media in distributed control systems (DCS) in industrial facilities, for example. Background Technology

[0002] A distributed control system (DCS) for an industrial facility includes multiple controllers, sensors, and actuators. For example, sensors can deliver measurements from an industrial process being executed on the facility. Controllers can then, for example, communicate with actuators that physically act on the process with the aim of maintaining the measurements (such as temperature or pressure) at a desired setpoint value.

[0003] Communication within a DCS requires fast and reliable delivery of data streams. Dedicated fieldbus networks are designed to provide the necessary low latency and reliability, but they aim to replace multiple proprietary fieldbus systems with a standardized, high-performance network. For this purpose, Time-Sensitive Networking (TSN) built on traditional Ethernet is well-known in the art. WO 2020 / 136 487A2 discloses a controller for processing facilities capable of communicating with a mix of TSN and non-TSN devices within a network.

[0004] Configuring a TSN as a whole can be quite complex and time-consuming, depending on the number of participants.

[0005] US2020 / 310 394A1 discloses systems and methods for implementing software-defined industrial systems. The coordinated system of distributed nodes can run applications, including modules implemented on the distributed nodes. In response to node failure, modules can be redeployed to replacement nodes.

[0006] In their paper "An Efficient Configuration Scheme of OPC UA TSN in Industrial Internet" (Chinese Automation Congress, IEEE, 1548-1551, doi: 10.1109 / CAC48633.2019.8996369) presented at the 2019 Chinese Automation Congress, Z. Zhou et al. disclosed a configuration scheme for an OPC UA Time-Sensitive Network (TSN). This TSN includes verification that the configuration scheme can meet the bounded delay requirements of periodic time-sensitive data streams.

[0007] J. Jiang et al.'s paper, "A Time-sensitive Networking (TSN) Simulation Model Based on OMNET++" (Proceedings of the 2018 IEEE International Conference on Mechatronics and Automation, pp. 643-648, ISBN: 978-1-5386-6074-4, doi: 10.1109 / ICMA.2018.8484302), discloses a TSN simulation model based on OMNET++. The model models a TSN-enabled switch that uses a gated list (GCL) to schedule services. Simulations verify that the model guarantees deterministic end-to-end latency.

[0008] WO 2021 / 079 599A1 discloses a method for arranging services in a TSN for supporting distributed control systems.

[0009] Purpose of the invention

[0010] The purpose of this invention is to provide a tool that can facilitate the deployment and troubleshooting of TSN networks.

[0011] This objective is achieved entirely by the TSN simulator, programmable logic controller (PLC), method for troubleshooting abnormal states in a DCS, and method for deploying a DCS, all provided by the present invention. Further advantageous embodiments are described in detail in the corresponding dependent claims. Summary of the Invention

[0012] This invention is defined by the dependent claims. Embodiments and examples not covered by the claims are presented for illustration and to facilitate an understanding of the claimed invention.

[0013] This invention provides a simulator for Time-Sensitive Networking (TSN). The simulator is configured to connect a first device of a Distributed Control System (DCS) to at least one second device of the DCS. The DCS is used to perform control tasks in an industrial facility. At least one second device is configured as a TSN client, enabling it to connect to the TSN. The first device can also be configured as a TSN client, but it can also be configured to use any other communication standard, such as one of the known proprietary fieldbus standards.

[0014] The simulator includes a first interface connectable to a first device and a second interface connectable to a second device and / or a TSN, to which the second device is attached. The simulator also includes a simulation unit configured to forward network traffic between the first and second interfaces. The simulation unit is further configured to modify and / or delay network traffic during this forwarding. In this way, the behavior of a real, imperfect TSN providing communication between the first and second devices is simulated.

[0015] It has been found that when a DCS is deployed, it is often assumed that the TSN network is operating as specified. That is, the TSN is considered an "ideal" TSN. In actual deployments, depending on the complexity of the TSN and the number of participants, it may be difficult to guarantee ideal TSN performance. In particular, the deployment of a new DCS, or the expansion or upgrade of an existing DCS, often requires the use of an existing TSN with multiple connected devices. Typically, the DCS, expansion, or upgrade vendor completes the entire deployment off-site in advance. It aims to bring the complete "recipe" to the customer's site and put it into practice. However, if any assumptions about the on-site TSN prove invalid at this point, the deployment may exhibit unexpected behavior or may not work as planned at all. Then, a hasty temporary solution needs to be developed, which may lead to further problems later.

[0016] Using a TSN simulator, it's possible to determine in advance how the DCS will behave if the TSN performance is not ideal. The DCS configuration can then be "hardened" because it depends less on the ideal functionality of the TSN and tolerates some deviation from that ideal state.

[0017] Furthermore, if the TSN simulator reveals that a certain deviation of the TSN from the ideal state will cause certain behaviors in the DCS, and these behaviors occur during actual deployment in the industrial facility, then the problem in the TSN of the industrial facility can be precisely located. After the problem is resolved, the deployment of the DCS can continue as planned.

[0018] Therefore, the analog unit that causes TSN communication to occur in a "realistic" rather than an "idealistic" way is the main difference between a TSN simulator and an adapter or software driver that simply connects a non-TSN-aware first device to the TSN.

[0019] The first interface, the second interface, and the simulation unit can be embodied in hardware, software, firmware, or any combination thereof. For example, they can be embodied in a programmable circuit system of an Application-Specific Integrated Circuit (ASIC) or a Field-Programmable Gate Array (FPGA). However, they can also be implemented in software running on general-purpose computer hardware. Hardware solutions (such as ASICs or FPGAs) can provide higher throughput and better energy efficiency, at the cost of requiring more effort for any changes or updates.

[0020] There are many advantageous options regarding how the simulation unit can modify and / or delay network services.

[0021] In one example, at least one raw message received on a first or second interface can be reserved for a predetermined and / or randomized time, and then the raw message can be forwarded to the second interface and the first interface, respectively. This can simulate deviations from ideal TSN behavior (i.e., guaranteed message delivery within a predetermined time). In this way, the critical dependence of the DCS on the timing of message delivery can be revealed. For example, there can be a "race condition" where a control action is attempted even though a required prerequisite has not been met because the message that triggers the provision of that prerequisite has not arrived in time. For example, the heater of the reaction vessel may be turned on even if the inlet valve of the substance to be heated has not been opened and the vessel is empty, which could cause the vessel and / or heater to overheat and be damaged.

[0022] Specifically, the simulation unit can be configured to retain at least one message that intentionally contradicts the TSN priority and / or TSN preemption division applied to the original message and / or another original message, in order to simulate an erroneous implementation of TSN priority and / or preemption processing.

[0023] In another example, the original message stream received on the first or second interface can be expanded with additional messages, and the mixture of the original and additional messages can be delivered to the second interface and the first interface respectively. In this way, the presence of other participants in the TSN can be simulated. For example, while the presence of only certain participants in the TSN can be planned, there may be unexpected additional participants because the documentation for equipment in the industrial facility is not up-to-date, the TSN is misconfigured, or the equipment has been plugged into the wrong switch port or even the wrong switch. This could cause problems if the DCS assumes that the TSN only carries messages exchanged between a certain group of participants.

[0024] In another example, a subset of messages from the original message stream received on either the first or second interface can be suppressed. The stream of original messages minus the suppressed messages can then be delivered to the second interface and the first interface, respectively. In this way, message loss during transmission through the TSN can be simulated. For example, the queues of a TSN switch with each TSN priority have a finite size. If lower-priority messages are preempted and must wait, and the queue size is exhausted due to an influx of too many such messages, the oldest message in the queue must be evicted, or the newest message must be rejected from the queue.

[0025] In another example, individual messages in the original message stream received on either the first or second interface can be modified. The modified message replaces the original message in the message stream and can then be delivered to the second interface or the first interface, respectively. That is, if a particular message is not modified, the original version is sent; but if a modified version exists, that modified version is sent instead of the original. In this way, unwanted and accidental changes to message content can be simulated.

[0026] For example, at least one individual message can be modified by perturbing it with noise samples to simulate noisy physical transmission. In another example, a message can be rewritten and / or recast to violate the TSN or any other communication standard used on the path between the first and second devices. This simulates a faulty implementation of the corresponding communication standard.

[0027] The simulation unit can also be more complex. For example, the simulation unit may include representations of at least two TSN bridges and / or switches and is configured to: feed at least one message from a first interface to a selected port of one of the TSN bridges or switches, process the message through the TSN bridges and / or switches, and feed the result from another selected port of one of the TSN bridges and / or switches to a second interface. The message is then modified, delayed, or suppressed based on the behavior of the TSN bridges and / or switches included in the simulation unit.

[0028] In another advantageous embodiment, the first and second interfaces may include different system clocks configured to operate at time offsets and / or at different speeds. In this way, clock skew can be simulated. This is a major source of errors in TSN networks and can cause problems that are difficult to diagnose in DCS. In particular, message transmission may be delayed, or messages may collide and be lost due to poor synchronization within the TSN.

[0029] Message modification and / or delay can be performed randomly to simulate spurious errors. However, modification and / or delay can also be performed in response to the original message streams received on the first interface and the second interface respectively satisfying at least one predetermined rule. In this way, system errors, such as software errors in a participant of TSN, can be simulated.

[0030] For example, at least one rule can cause at least one message response to be modified and / or delayed in the following ways:

[0031] • The message originates from or is destined for a specific network address;

[0032] • The message originates from or is destined for a specific type of device; and / or

[0033] • The message originates from or is destined for a device belonging to a specific vendor; and / or

[0034] • The message payload meets the predetermined conditions.

[0035] In another advantageous embodiment, at least the second interface is configured to communicate with the second device according to the Open Platform Communications Unified Access OPC UA standard. Specifically, if the first interface is configured to communicate with the first device according to a different standard, the TSN emulator can be used to utilize new features of the OPC UA on behalf of the first device, even if the first device is unaware of such features. For example, the TSN emulator can provide an OPC server accessible to OPC client devices within the TSN. This OPC server can expose symbols, tags, or any other handles to OPC client devices within the TSN, which can be used to access the functionality of the first device.

[0036] The present invention also provides a programmable logic controller (PLC). This PLC is configured as a TSN (Transportation Service Network) in an industrial facility, uses control logic to process input data into actuation signals, and sends these actuation signals to at least one device connected to the TSN network.

[0037] For example, a PLC can be configured to communicate with real-time devices, such as:

[0038] Input and output modules;

[0039] • Drivers or other actuators;

[0040] • Human-machine interface (HMI), such as SCADA for monitoring and data acquisition, software and / or hardware panels;

[0041] • Robots or vehicles; or

[0042] • One or more other third-party PLCs.

[0043] As mentioned above, in addition to enabling the PLC to communicate with the TSN network and optionally utilizing OPC UA capabilities, the TSN simulator primarily allows for the study of the behavior of the PLC and the DCS to which the PLC belongs, even when the TSN is performing less than ideally. In particular, a wide variety of errors and incompatibilities can be simulated.

[0044] Like the TSN simulator, the PLC can be embodied in hardware, software, firmware, or any combination thereof. In a particularly advantageous embodiment, the PLC and the TSN simulator are implemented in a single common software package. This is particularly economical in terms of hardware, as such a common software package makes good use of the capacity of a typical general-purpose industrial PC. That is, the hardware is underutilized because it consists of a separate PC for the PLC on one hand and a TSN simulator on the other.

[0045] The term "software package" does not imply that the PLC and TSN simulator need to be merged into a single piece of software. Rather, they can be different applications running on the same physical hardware and communicating with each other through any suitable means for inter-process communication. For example, different applications can run as daemons or other services and communicate with each other via sockets, named pipes, or TCP / IP communication via a local loopback interface.

[0046] Public software packages are also advantageous during the facility's engineering design process. For example, the software package can run simultaneously with the DCS's engineering tools on a single PC or another PC within an engineer's local network. In this way, if simulations of undesirable operating conditions of the TSN indicate that the DCS's engineering should be modified, that modification can be developed and tested within a short turnaround time.

[0047] Furthermore, because PCs have greater processing power than typical dedicated PLC hardware, they can be retained in the DCS as a permanent solution. In particular, a PC can complete reading input data from other devices, performing control calculations according to the facility's control scheme, and writing output data back to other devices within a single TSN communication cycle ("intra-cycle control").

[0048] As mentioned earlier, one advantage of the TSN simulator is its ability to simulate abnormal operational states of a TSN. This can be used to track down problems in a real TSN.

[0049] Therefore, the present invention also provides a method for troubleshooting abnormal operating states in the cooperation between a first device and a second device in a distributed control system (DCS) of an industrial facility. The first device and the second device communicate via a time-sensitive network (TSN) of the industrial facility.

[0050] The method begins by providing the aforementioned TSN emulator. A first device or an agent configured to behave identically to the first device is connected to a first interface of the TSN emulator. A second device or an agent configured to behave identically to the second device is connected to a second interface of the TSN emulator.

[0051] The proxy for the first and / or second device may be, for example, another hardware instance of the corresponding device with the same brand, model, and version. Except in cases where the actual first and / or second device's hardware is faulty, this hardware proxy should exhibit exactly the same behavior as the original first and / or second device, including timing, processing of input data into output data using that timing, and transmission of the output data from the corresponding device.

[0052] In another example, the agents for the first and / or second devices can be implemented in software. This is cheaper than purchasing another instance of physical hardware as an agent, especially when the physical device whose behavior the agent is meant to simulate is old and discontinued. On the other hand, it is more difficult to accurately simulate the behavior of physical devices in software, including the timing of any responses. For example, the PC on which the PLC emulator or other agent runs may have faster hardware than the physical PLC and therefore can perform control calculations much faster. In the case of a software agent in the control loop, problems caused by the physical PLC not being able to perform its control calculations fast enough may not be reproducible.

[0053] On the TSN simulator, candidate configurations are implemented. These candidate configurations determine when and how the TSN simulator modifies and / or delays network services. The candidate configurations also indicate potential root causes of abnormal operational states.

[0054] In response to the candidate configuration causing a given abnormal operating state to be troubleshooted, determine the candidate root cause as a possible root cause of the abnormal operating state.

[0055] For example, a given abnormal operating state to be troubleshooted in a DCS could include a situation where, when a process step should be initiated in the facility, preconditions are not met because some actions commanded by the PLC have not yet been executed. It is suspected that control commands from the PLC are lost during transmission to the corresponding actuators in the facility, but it is unclear why this occurs. One possible explanation is that the queue of a TSN switch with a certain TSN priority is full at some point, causing the loss of control commands. A candidate configuration for the TSN simulator could be set to precisely trigger this queue overflow in one of the TSN switches or bridges simulated within the TSN simulator. This could cause messages carrying control commands to be suppressed en route through the simulation unit. If this behavior further leads to the occurrence of an abnormal operating state to be troubleshooted, the queue overflow can be identified as a likely root cause of the abnormal operating state.

[0056] This is somewhat similar to aircraft or spacecraft accident investigations, where laboratory and simulator tests are used to determine whether a suspected root cause could actually escalate to a given accident. For example, after the Columbia space shuttle crash, the assumption that the impact of the insulating foam was the root cause was only accepted after laboratory tests showed that the soft material could indeed impact the hard material that penetrated the heat shield.

[0057] As mentioned earlier, the TSN simulator can also facilitate DCS deployment because it can be used to make planning more accurate. In particular, because planning begins with conditions that better reflect the actual situation in the facility where the DCS will be deployed, fewer unexpected situations occur during actual deployment. Furthermore, one objective in DCS planning can be to intentionally "harden" the DCS to prevent deviations between TSN operation and its ideal operation.

[0058] Therefore, the present invention also provides a method for deploying a distributed control system (DCS) in an industrial facility, the DCS having multiple devices to be connected to a given time-sensitive network (TSN).

[0059] This method begins by providing a TSN or an agent configured to behave identically to a given TSN. Like the agent for a device, the agent for a TSN can be implemented using hardware, software, or any suitable combination thereof.

[0060] Multiple devices are connected to the TSN or a TSN agent. Here, at least one device is connected to the first interface of the aforementioned TSN emulator. The second interface of the TSN emulator is connected to the TSN or agent.

[0061] Candidate configurations for implementing the expected functions of the DCS can be implemented on multiple devices. For example, control logic can be implemented on one or more PLCs that are devices, enabling the PLCs to read input data from other devices, perform control calculations according to the control logic, and output the results to other devices.

[0062] On the TSN simulator, multiple test configurations are implemented. These test configurations determine when and how the TSN simulator modifies and / or delays network services. Each such test configuration corresponds to an expected abnormal operating state of the TSN in an industrial facility's TSN.

[0063] For each test configuration, determine whether the arrangement of multiple devices performs the expected functions of the DCS, regardless of any abnormal operational states caused by the test configuration. If this determination is affirmative for all test configurations, then a candidate DCS configuration is determined to be suitable for deployment in the industrial facility.

[0064] The DCS configuration determined in this way is at least "hardened" for the abnormal operating state of the TSN represented by the test configuration. Given a certain test configuration on the TSN simulator, the candidate configuration fails to function properly, which provides guidance on how to further "harden" the DCS configuration. For example, if the test configuration corresponds to congestion on a specific segment of the TSN, the control strategy on at least one PLC can be updated to rely less on reliable communication over that specific segment. This could include acquiring and using additional sensor data from sensors that can arrive without using the congested segment. The additional sensor data can be used as a short-term replacement where sensor data from the main sensor is delayed in transmission over the congested segment.

[0065] Advantageously, the DCS is deployed within the TSN based on candidate configurations that have already been identified as suitable for deployment. As mentioned earlier, this increases the probability that the DCS will fully perform its intended functions, even if the TSN performs poorly.

[0066] The ability to test DCS configurations using the TSN simulator before deployment facilitates DCS deployment, eliminating the need to travel to the industrial facility where the DCS will be deployed. Following successful pre-testing, customers can be provided with a detailed "recipe" for a completed DCS configuration, which can be deployed by the customer themselves or by a local contractor. This saves time and costs associated with traveling to industrial facilities, and is particularly useful during pandemics where most international business travel requires mandatory quarantine or is completely prohibited.

[0067] As previously stated, the TSN simulator, PLC, and methods can be implemented wholly or partially in software. Therefore, the present invention also relates to one or more computer programs that, when executed by one or more computers and / or virtualization execution environments, cause one or more computers and / or virtualization execution environments to function as the aforementioned TSN simulator and / or PLC, and / or execute one of the aforementioned methods.

[0068] For example, a virtualized execution environment can be configured to run software containers in which applications can be deployed in a self-contained manner.

[0069] The present invention also provides one or more non-transitory storage media and / or downloadable products having one or more computer programs. A downloadable product is a product that can be sold in an online store and is immediately available through download. The present invention also provides one or more computer programs and / or one or more non-transitory machine-readable storage media and / or downloadable products for one or more computers and / or virtualized execution environments. Attached Figure Description

[0070] The invention is illustrated below with reference to the accompanying drawings, but is not intended to limit the scope of the invention.

[0071] These figures show:

[0072] Figure 1 Exemplary embodiment of TSN emulator 3;

[0073] Figure 2 Exemplary embodiment of PLC 4 with TSN simulator 3;

[0074] Figure 3 An exemplary embodiment of a method 100 for troubleshooting abnormal operating state A;

[0075] Figure 4 An exemplary embodiment of the method 200 for deploying DCS. Detailed Implementation

[0076] Figure 1 This is a schematic diagram of an exemplary embodiment of the TSN emulator 3. The TSN emulator 3 is configured to connect a first device 1 of the DCS to a second device 2 of the DCS configured as a TSN client.

[0077] TSN emulator 3 includes a first interface 31 that can be connected to a first device 1. A second interface 32 of TSN emulator 3 can be connected to a second device 2 and / or TSN 5, with the second device 2 attached to TSN 5. Network traffic 33 between the first device 1 and the second device 2 passes through the first interface 31 and the second interface 32 in both directions. The first interface 31 and the second interface 32 include different system clocks 31a and 32a configured to operate at time offsets and / or at different speeds.

[0078] On the path between the first interface 31 and the second interface 32, network service 33 can be modified and / or delayed by the simulation unit 34. Figure 1 In the example shown, this is achieved by simulating the entire TSN, including multiple TSN switches and / or bridges 34a, 34b, within the simulation unit 34. Messages from network service 33 are fed to a first selected port of the switches and / or bridges 34a, 34b, and the processing results of the simulated TSN are obtained from a second port of the switches and / or bridges 34a and 34b.

[0079] Figure 2 This is a schematic diagram of an exemplary embodiment of a PLC 4 connected to a TSN 5 via an integrated TSN simulator 3. Figure 2 In the example shown, TSN 5 includes three devices 51, 52, and 53. The control logic 43 of PLC 4 obtains input data 41 from device 51, processes this input data 41 into actuation signals 42, and sends the actuation signals to device 52 via TSN simulator 3 and TSN 5.

[0080] Figure 3 This is an exemplary flowchart of a method 100 for troubleshooting an abnormal operating state A in the collaboration between a first device 1 and a second device 2 in a distributed control system (DCS) of an industrial facility.

[0081] In step 110, TSN simulator 3 is provided.

[0082] In step 120, the first device 1 or its agent is connected to the first interface 31 of the TSN simulator 3.

[0083] In step 130, the second device or its agent is connected to the second interface 32 of the TSN simulator 3.

[0084] In step 140, based on abnormal operation state A, candidate configurations 35 are implemented on TSN simulator 3 regarding when and how TSN simulator 3 should modify and / or delay network services 33, such as... Figure 1The following is a more detailed description. Candidate configuration 35 indicates the candidate root cause r of abnormal operation state A.

[0085] In step 150, it is checked whether candidate configuration 35 causes abnormal operating state A. In other words, it is checked whether abnormal operating state A can be reproduced by candidate configuration 35. If this is the case (truth value 1), then in step 160, it is determined that candidate root cause r is a possible root cause R(A) of abnormal operating state A.

[0086] Figure 4 This is a schematic flowchart of a method 200 for deploying a DCS in an industrial facility, the DCS having multiple devices 51, 52, 53 to be connected to a given TSN 5.

[0087] In step 210, a proxy for the given TSN or TSN 5 is provided.

[0088] In step 220, devices 51, 52, and 53 are connected to TSN 5 or its agent. At least one device 51 is connected to the first interface 31 of the aforementioned TSN simulator 3, and the second interface 32 of the TSN simulator 3 is connected to TSN 5 or its agent.

[0089] In step 230, candidate configurations c for the intended functions of the DCS are implemented on devices 51, 52, and 53.

[0090] In step 240, multiple test configurations 36 are implemented on the TSN simulator 3 to determine when and how the TSN simulator 3 modifies and / or delays network services 33. Each test configuration 36 corresponds to an abnormal operating state of TSN 5 that is expected in the TSN 5 of the industrial facility.

[0091] In step 250, for each test configuration 36, it is determined whether the arrangement of multiple devices performs the expected function of the DCS, regardless of any abnormal operating states caused by the test configuration 36. In other words, it tests whether the function of the DCS according to candidate configuration c is resistant to interference from the TSN according to test configuration 36. If this is the case for all test configurations 36 (truth value 1), then in step 260, it is determined that candidate configuration c is a suitable configuration for deployment in an industrial facility.

[0092] In step 270, this adapted configuration C of the DCS is deployed in TSN 5.

[0093] List of reference numerals

[0094] 1. First Equipment

[0095] 2. Second equipment

[0096] 3. Time-Sensitive Network (TSN) Simulator

[0097] 31 TSN Emulator 3 First Interface

[0098] 31a Clock of the first interface 31

[0099] 32 TSN Emulator 3 Second Interface

[0100] 32a Second Interface 32 Clock

[0101] 33 Network services between interfaces 31 and 32

[0102] 34. Simulation Units of TSN Simulator 3

[0103] TSN switch / bridge in analog unit 34a, 34b

[0104] 35 Candidate Configurations on TSN Emulator 3

[0105] Test configuration on TSN emulator 3 36

[0106] 4. Programmable Logic Controller (PLC)

[0107] 41 PLC

[0108] 42 from PLC

[0109] 43 PLC

[0110] 5. Time-Sensitive Networking (TSN)

[0111] 51-53 TSN

[0112] 100 Methods for troubleshooting abnormal operating state A

[0113] 110 provides TSN emulator 3

[0114] 120 Connect the first device 1 to the first interface 31

[0115] 130 Connect the second device 2 to the second interface 32

[0116] 140 Implementing candidate configurations on TSN simulator 35

[0117] 150 Test candidate configuration 35 to see if it causes an abnormal state A

[0118] 160. Identify candidate root cause r as possible root cause R.

[0119] 200 Methods for Deploying Distributed Control Systems (DCS)

[0120] 210 provides a given TSN

[0121] 220 Connect devices 51, 52, and 53 to TSN 5 or the agent.

[0122] 230 Implement candidate configuration c on devices 51, 52, and 53

[0123] 240 Implement test configuration 36

[0124] 250 Test whether the expected functionality is executed correctly.

[0125] 260. Determine that configuration c is the appropriate configuration for deployment.

[0126] 270 Deployment suitable for C configuration

[0127] candidate configurations for c DCS

[0128] r Candidate root cause of abnormal state A

[0129] An abnormal state in the collaboration between devices 1 and 2.

[0130] Possible root causes of abnormal state A (R)

Claims

1. A method (100) for troubleshooting abnormal operating states in collaboration between a first device (1) and a second device (2) in a distributed control system (DCS) for an industrial facility, wherein the second device (2) is configured as a TSN client, and the first device (1) and the second device (2) communicate via a time-sensitive network (TSN) (5) of the industrial facility, the method (100) comprising the following steps: • Provide (110) a Time-Sensitive Network (TSN) simulator (3) for connecting the first device (1) to at least one of the second devices (2), the TSN simulator (3) comprising: • The first interface (31) is capable of being connected to the first device (1); • A second interface (32) is capable of connecting to the second device (2) and / or the TSN (5), the second device (2) being attached to the TSN (5); and • The simulation unit (34) is configured to forward network traffic (33) between the first interface (31) and the second interface (32), and modify and / or delay network traffic during the forwarding, thereby simulating the behavior of a real, imperfect TSN providing communication between the first device (1) and the second device (2), wherein the behavior of the imperfect TSN includes deviations from the specifications of the TSN; • Connect the first device (1) or agent (120) to the first interface (31) of the TSN simulator (3), wherein the agent is configured to behave in the same manner as the first device (1); • Connect the second device (2) or agent (130) to the second interface (32) of the TSN emulator (3), wherein the agent is configured to behave in the same manner as the second device (2); • Implement (140) on the TSN simulator (3) a candidate configuration (35) regarding when and how the TSN simulator (3) modifies and / or delays network services (33), wherein the candidate configuration (35) indicates a candidate root cause of the abnormal operating state; and • In response to the candidate configuration (35) causing (150) the abnormal operating state, determine (160) the candidate root cause as a possible root cause of the abnormal operating state.

2. The method (100) according to claim 1, wherein the simulation unit (34) is configured to modify and / or delay network services (33) in the following manner: • At least one original message received on the first interface (31) or the second interface (32) will be reserved for a predetermined or randomized time, and then the at least one original message will be forwarded to the second interface (32) and the first interface (31) respectively; and / or • The stream of the original message received on the first interface (31) or the second interface (32) is augmented with additional messages, and a mixture of the received original message and the additional messages is delivered to the second interface (32) and the first interface (31) respectively; and / or • Suppress a subset of messages from the stream of original messages received on the first interface (31) or the second interface (32), and deliver the stream of received original messages minus the suppressed messages to the second interface and the first interface, respectively; and / or • Modify individual messages in the original message stream received on the first interface (31) or the second interface (32), and deliver message streams to the second interface (32) and the first interface (31) respectively, in which the modified messages replace the original messages.

3. The method (100) according to claim 2, wherein the simulation unit (34) is configured to modify at least one individual message in the following manner: • Disrupt at least one individual message with noise samples to simulate noisy physical transmission, and / or • Rewrite and / or recast the at least one individual message such that the message violates TSN or any other communication standard used on the path between the first device (1) and the second device (2), thereby simulating a faulty implementation of the corresponding communication standard.

4. The method (100) according to any one of claims 2 to 3, wherein the simulation unit (34) is configured to retain at least one message that is intentionally contradictory to the TSN priority and / or TSN preemption division applied to the original message and / or another original message, in order to simulate an erroneous implementation of the TSN priority and / or preemption processing.

5. The method (100) according to any one of claims 1 to 3, wherein the simulation unit (34) comprises representations of at least two TSN bridges (34a) and / or switches (34b), and the simulation unit (34) is configured to: • Feed at least one message from the first interface to a selected port of one of the TSN bridges (34a) and / or switches (34b); • The messages are processed via the TSN bridge (34a) and / or the switch (34b); and • Feed the results from another selected port of one of the TSN bridges (34a) and / or switches (34b) to the second interface (32).

6. The method (100) according to any one of claims 1 to 3, wherein the first interface (31) and the second interface (32) include different system clocks (31a, 32a) configured to operate at time offsets from each other and / or at different speeds.

7. The method (100) according to any one of claims 1 to 3 is further configured to randomly modify and / or delay network services, or to modify and / or delay network services in response to the original message streams received on the first interface and the second interface respectively satisfying at least one predetermined rule.

8. The method (100) of claim 7, wherein at least one rule causes at least one message response to be modified and / or delayed as follows: • The message originates from or is destined for a specific network address; • The message originates from or is destined for a specific type of device; and / or • The message originates from or is destined for a device belonging to a specific vendor; and / or • The payload of the message meets predetermined conditions.

9. The method (100) according to any one of claims 1 to 3, wherein at least the second interface (32) is configured to communicate with the second device (2) according to the Open Platform Communications Unified Access OPC UA standard.

10. A method (200) for deploying a distributed control system (DCS) in an industrial facility, the DCS having multiple devices (51, 52, 53) to be connected to a given time-sensitive network (TSN) (5), the method comprising the steps of: • Provide (210) the given TSN (5) or be configured to behave the same as the given TSN (5); • Connecting (220) the plurality of devices (51, 52, 53) to the TSN (5) or the agent, wherein at least one device (51) is connected to a first interface (31) of the TSN simulator (3) and a second interface (32) of the TSN simulator (3) is connected to the TSN (5) or the agent, for connecting the first device (1) of the DCS for the industrial facility to the TSN simulator (3) configured as a TSN client of at least one second device (2) of the DCS, the TSN simulator (3) includes: • The first interface (31) can be connected to the first device (1); • The second interface (32) is capable of connecting to the second device (2) and / or the TSN (5), wherein the second device (2) is attached to the TSN (5); and • The simulation unit (34) is configured to forward network traffic (33) between the first interface (31) and the second interface (32), and modify and / or delay network traffic during the forwarding, thereby simulating the behavior of a real, imperfect TSN providing communication between the first device (1) and the second device (2), wherein the behavior of the imperfect TSN includes deviations from the specifications of the TSN; • Implement (230) candidate configurations for the intended functions of the DCS on the plurality of devices (51, 52, 53); • Implement (240) multiple test configurations (36) on the TSN simulator (3) regarding when and how the TSN simulator (3) modifies and / or delays network services (33), wherein each test configuration (36) corresponds to an abnormal operating state of the TSN (5) that is expected in the TSN (5) of the industrial facility. • For each test configuration (36), determine (250) whether the arrangement of the plurality of devices performs the intended function of the DCS, regardless of the abnormal operating state caused by the test configuration (36); and • If the determination is positive for all test configurations (36), then it is determined (260) that the candidate configuration is suitable for deployment in the industrial facility.

11. The method (200) of claim 10, wherein the simulation unit (34) is configured to modify and / or delay network services (33) in the following manner: • At least one original message received on the first interface (31) or the second interface (32) will be reserved for a predetermined or randomized time, and then the at least one original message will be forwarded to the second interface (32) and the first interface (31) respectively; and / or • The original message stream received on the first interface (31) or the second interface (32) is augmented with additional messages, and a mixture of the received original messages and the additional messages is delivered to the second interface (32) and the first interface (31), respectively. and / or • Suppress a subset of messages from the stream of original messages received on the first interface (31) or the second interface (32), and deliver the stream of received original messages minus the suppressed messages to the second interface and the first interface, respectively; and / or • Modify individual messages in the original message stream received on the first interface (31) or the second interface (32), and deliver message streams to the second interface (32) and the first interface (31) respectively, in which the modified messages replace the original messages.

12. The method (200) according to claim 11, wherein the simulation unit (34) is configured to modify at least one individual message in such a way as: • Disrupt at least one individual message with noise samples to simulate noisy physical transmission, and / or • Rewrite and / or recast the at least one individual message such that the message violates TSN or any other communication standard used on the path between the first device (1) and the second device (2), thereby simulating a faulty implementation of the corresponding communication standard.

13. The method (200) according to any one of claims 11 to 12, wherein the simulation unit (34) is configured to retain at least one message that is intentionally contradictory to the TSN priority and / or TSN preemption division applied to the original message and / or another original message, in order to simulate an erroneous implementation of the TSN priority and / or preemption processing.

14. The method (200) according to any one of claims 10 to 12, wherein the simulation unit (34) comprises representations of at least two TSN bridges (34a) and / or switches (34b), and the simulation unit (34) is configured to: • Feed at least one message from the first interface to a selected port of one of the TSN bridges (34a) and / or switches (34b); • The messages are processed via the TSN bridge (34a) and / or the switch (34b); and • Feed the results from another selected port of one of the TSN bridges (34a) and / or switches (34b) to the second interface (32).

15. The method (200) according to any one of claims 10 to 12, wherein the first interface (31) and the second interface (32) include different system clocks (31a, 32a) configured to operate at time offsets from each other and / or at different speeds.

16. The method (200) according to any one of claims 10 to 12 is further configured to randomly modify and / or delay network services, or to modify and / or delay network services in response to the original message streams received on the first interface and the second interface respectively satisfying at least one predetermined rule.

17. The method (200) of claim 16, wherein at least one rule causes at least one message response to be modified and / or delayed as follows: • The message originates from or is destined for a specific network address; • The message originates from or is destined for a specific type of device; and / or • The message originates from or is destined for a device belonging to a specific vendor; and / or • The payload of the message meets predetermined conditions.

18. The method (200) according to any one of claims 10 to 12, wherein at least the second interface (32) is configured to communicate with the second device (2) according to the Open Platform Communications Unified Access OPC UA standard.

19. The method (200) according to any one of claims 10 to 12, further comprising: The DCS is deployed (270) in the TSN (5) according to the candidate configuration that has been determined to be suitable for deployment.

20. A computer program product comprising machine-readable instructions that, when executed by one or more computers, cause the one or more computers to: • Perform the method (100, 200) according to any one of claims 1 to 19.

21. A non-transitory storage medium having a computer program product according to claim 20.

22. A computer having a non-transitory storage medium according to claim 21.

Images