Real-time high-speed clock signal for industrial network simulation

Abstract

This application relates to real-time high-speed clock signals for industrial network simulation. An industrial simulation system exchanges data between a virtualized industrial system and an industrial controller at high frequency and high accuracy without requiring additional network simulation hardware. Rather than using an operating system clock to time the sending of simulation device data packets from the simulation system to the industrial controller, the simulation system uses the arrival event of a data packet received from the industrial controller as a driving clock signal for sending data packets from the virtual system to the controller. Using the arrival time of a data packet from the industrial controller as a clock signal rather than the operating system's system clock can produce high-accuracy, low-jitter data exchange during simulation.

Description

Technical Field

[0001] The topics disclosed in this article generally relate to industrial automation systems, and more specifically to the simulation and testing of industrial automation systems. Background Technology

[0002] In many control system development scenarios, system designers can virtually test the control program that will be executed on the controller before putting it into field use. Summary of the Invention

[0003] The following is a brief overview to provide a basic understanding of some of the aspects described in this paper. This overview is neither a comprehensive review nor intended to identify key / important elements or define the scope of the various aspects described in this paper. Its sole purpose is to present some ideas in a simplified form as a prelude to the more detailed descriptions that follow.

[0004] In one or more embodiments, a system for simulating an industrial system is provided, the system comprising: a simulation component configured to perform a simulation of the industrial system under the control of an industrial controller based on a virtual model of the industrial system; and a communication control component configured to: receive controller data directed to an emulated device of the virtual model from the industrial controller, and transmit simulated device data generated by the emulated device to the industrial controller, wherein the communication control component is configured to: designate a subset of the controller data directed to one of the emulated devices as a clock signal, and transmit the simulated device data to the industrial controller in response to receiving a controller data packet corresponding to the subset of controller data.

[0005] Furthermore, one or more embodiments provide a method comprising: performing a simulation of an industrial system under the control of an industrial controller based on a digital model of the industrial system by a system including a processor, wherein the execution includes: receiving controller data from the industrial controller directed to a simulation device of the digital model; and, in response to receiving a controller data packet corresponding to a subset of the controller data designated as a clock signal, sending simulation device data generated by the simulation device to the industrial controller.

[0006] Furthermore, according to one or more embodiments, a non-transitory computer-readable medium is provided, on which instructions are stored, the instructions causing the system to perform operations in response to execution, the operations including: performing a simulation of the industrial system under the control of an industrial controller based on a virtual model of the industrial system, wherein the execution includes: receiving controller data from the industrial controller pointing to a simulation device of a digital model; and sending simulation device data generated by the simulation device to the industrial controller in response to receiving a controller data packet corresponding to a subset of the controller data designated as a clock signal.

[0007] To achieve the foregoing and related objectives, certain illustrative aspects are described herein in conjunction with the following description and accompanying drawings. These aspects indicate various modes that can be practiced, all of which are intended to be covered herein. Other advantages and novel features may become apparent when considered in conjunction with the accompanying drawings, based on the detailed description below. Attached Figure Description

[0008] Figure 1 This is a block diagram of an example industrial environment.

[0009] Figure 2 It is a general diagram showing the data connections between industrial equipment and industrial controllers associated with industrial equipment.

[0010] Figure 3 This is a diagram illustrating the virtual commissioning of the control program relative to the virtual system.

[0011] Figure 4 This is a diagram illustrating an example industrial simulation architecture.

[0012] Figure 5 This is an example data exchange timing diagram illustrating the periodic data exchange between an industrial controller and industrial equipment.

[0013] Figure 6 This is a block diagram of an example industrial simulation system that uses the arrival time of data packets from the industrial controller to trigger the sending of analog device data packets to the controller.

[0014] Figure 7 This diagram illustrates the exchange of analog data between the simulation system and the industrial controller during the simulation of an industrial system.

[0015] Figure 8 This is an example data exchange timing diagram showing the use of data packets from an industrial controller as a clock signal to trigger the sending of data packets from an analog system to the controller.

[0016] Figure 9This is a flowchart of an example method for exchanging analog controller and device data between a hardware industrial controller and a virtualized industrial system running on an analog platform.

[0017] Figure 10 This is an example computing environment.

[0018] Figure 11 This is an example network environment. Detailed Implementation

[0019] This disclosure will now be described with reference to the accompanying drawings, wherein similar reference numerals are used throughout to refer to similar elements. In the following description, numerous specific details are set forth for illustrative purposes to provide a thorough understanding of this disclosure. However, it will be apparent that this disclosure can be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form to aid in the description of this disclosure.

[0020] As used herein, the terms “component,” “system,” “platform,” “layer,” “controller,” “terminal,” “station,” “node,” and “interface” are intended to refer to a computer-related entity or an entity associated with or part of an operating device having one or more specific functions, wherein such an entity may be hardware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to: a process running on a processor; a processor; a hard disk drive; multiple storage drives (optical or magnetic storage media) including those attached (e.g., secured with screws or bolts) or removably attached solid-state storage drives; an object; an executable file; an executing thread; a computer-executable program, and / or a computer. By way of illustration, both an application running on a server and the server itself can be components. One or more components may reside within an executing process and / or thread, and components may reside on one computer and / or be distributed among two or more computers. Furthermore, components as described herein may be executed from various computer-readable storage media on which various data structures are stored. Components can communicate via local and / or remote processes, for example, based on signals having one or more data packets (e.g., data from a component interacting with a local system, another component in a distributed system, and / or other systems across a network such as the Internet). As another example, a component can be a device having specific functions provided by mechanical components operating through an electrical or electronic circuitry system operated by software or firmware applications executed by a processor, wherein the processor may be internal or external to the device and execute at least a portion of the software or firmware application. As yet another example, a component can be a device providing specific functions without mechanical components via electronic components, which may include a processor to execute software or firmware that at least partially provides the functions of the electronic components. As yet another example, an interface can include input / output (I / O) components and associated processors, applications, or application programming interface (API) components. While the foregoing examples relate to aspects of components, the aspects or features illustrated also apply to systems, platforms, interfaces, layers, controllers, terminals, etc.

[0021] As used herein, the terms "to infer" and "inference" generally refer to the process of reasoning or inferring the state of a system, environment, and / or user based on a set of observations captured via events and / or data. For example, inference can be used to identify specific situations or actions, or it can generate probability distributions of states. Inference can be probabilistic, i.e., calculating a probability distribution about the state of interest based on considerations of data and events. Inference can also refer to techniques used to construct higher-level events from a set of events and / or data. Such inference leads to the construction of new events or actions from a set of observed events and / or stored event data, regardless of whether these events are closely related in time or whether the events and data come from a single event and data source or several event and data sources.

[0022] Furthermore, the term "or" is intended to indicate an inclusive "or" rather than an exclusive "or". That is, unless otherwise stated or clearly understood from the context, the phrase "X adopts A or B" is intended to mean any natural inclusive permutation. That is, any of the following instances satisfy the phrase "X adopts A or B": X adopts A; X adopts B; or X adopts both A and B. Additionally, unless otherwise stated or clearly understood from the context, the articles "a" and "an" used in this application and the appended claims refer to the singular form, the articles should generally be interpreted as meaning "one or more".

[0023] Furthermore, the term "set" as used herein excludes an empty set, such as a set containing no elements. Therefore, "set" as used in this disclosure includes one or more elements or entities. For example, a set of controllers includes one or more controllers; a set of data resources includes one or more data resources, and so on. Similarly, the term "group" as used herein refers to a collection of one or more entities; for example, a group of nodes refers to one or more nodes.

[0024] Various aspects or features will be presented according to the system, which may include multiple devices, components, modules, etc. It should be understood and recognized that various systems may include additional devices, components, modules, etc., and / or may exclude all devices, components, modules, etc., discussed in conjunction with the accompanying drawings. Combinations of these methods may also be used.

[0025] Figure 1This is a block diagram of an example industrial environment 100. In this example, multiple industrial controllers 118 are deployed throughout the industrial plant environment to monitor and control relevant industrial systems or processes related to product manufacturing, processing, motion control, batch processing, material handling, or other such industrial functions. The industrial controllers 118 typically execute corresponding control programs to facilitate the monitoring and control of industrial equipment 120 that constitutes a controlled industrial asset or system (e.g., industrial machinery). One or more industrial controllers 118 may also include software controllers executing on a personal computer, server blade, or other hardware platform or cloud platform. Some hybrid devices may also combine controller functionality with other functions (e.g., visualization). The control programs executed by the industrial controllers 118 may include any conceivable type of code for processing input signals read from the industrial equipment 120 and controlling output signals generated by the industrial controllers, including but not limited to ladder logic, sequential function charts, function block diagrams, structured text, C++, Python, Javascript, etc.

[0026] Industrial device 120 may include input devices (e.g., sensors), output devices (e.g., effectors), or devices that serve as both input and output devices. The input devices provide data related to the controlled industrial system to industrial controller 118, and the output devices respond to control signals generated by industrial controller 118 to control various aspects of the industrial system. Industrial device 120 may include digital input devices (e.g., pushbuttons, selector switches, safety devices, proximity switches, light sensors, etc.), digital output devices (e.g., solenoid values, indicator lights, motor contactors, etc.), analog input devices (e.g., 4mA to 20mA telemetry devices, 0VDC to 10VDC telemetry devices, or other analog measuring devices), or analog output devices (e.g., frequency converters, flow control valves, speed control devices, etc.).

[0027] While some industrial controllers 118 communicate with industrial equipment 120 via hardwired connections, many industrial controllers 118 exchange data with some or all of the industrial equipment 120 via a network using suitable industrial communication protocols such as CIP Class 1 or Profinet.

[0028] Industrial automation systems typically include one or more Personal Machine Interfaces (HMIs) 114 that allow factory personnel to view telemetry and status data associated with the automation system and control aspects of system operation. The HMI 114 can communicate with one or more industrial controllers 118 via a factory network 116 and exchange data with the industrial controllers to visualize information related to the controlled industrial process on one or more pre-developed operator interface screens. The HMI 114 can also be configured to allow operators to submit data to the memory address or designated data tag of the industrial controller 118, thereby providing operators with a means to issue commands to the controlled system (e.g., cycle start commands, equipment actuation commands, etc.), modify setpoint values, etc. The HMI 114 can generate one or more displays through which operators interact with the industrial controller 118 and thus with the controlled process and / or system. Example displays may use graphical representations of processes displaying measured or calculated values ​​to visualize the current status of the industrial system or its associated equipment, employ status-based color or position animations, present alarm notifications, or use other such techniques to present relevant data to the operator. The data presented in this manner is read from the industrial controller 118 by the HMI 114 and displayed on one or more display screens according to the display format selected by the HMI developer. The HMI may include a fixed-location device or a mobile device having a user-installed or pre-installed operating system and user-installed or pre-installed graphical application software.

[0029] Some industrial environments may also include other systems or devices related to specific aspects of the controlled industrial system. These systems or devices may include, for example, one or more data historians 110 that aggregate and store production information collected from the industrial controller 118 and other industrial equipment.

[0030] Industrial equipment 120, industrial controllers 118, HMIs 114, associated controlled industrial assets, and other factory floor systems, such as data history devices 110, vision systems, and other such systems, operate at the operational technology (OT) level in the industrial environment. More advanced analytics and reporting systems can operate at a higher enterprise level within the information technology (IT) domain of the industrial environment; for example, on office network 108 or on cloud platform 122. Such higher-level systems may include, for example, an enterprise resource planning (ERP) system 104 that integrates and manages high-level business operations, such as finance, sales, order management, marketing, human resources, or other such business functions. Given these higher-level business considerations, a manufacturing execution system (MES) 102 can monitor and manage control operations at the control level. A reporting system 106 can collect operational data from industrial equipment on the factory floor and generate daily or shift reports summarizing operational statistics of the controlled industrial assets.

[0031] Figure 2 This is a schematic diagram illustrating the data connection between industrial equipment 120 (or I / O devices) and industrial controller 118 associated with industrial equipment 210 in the field. As described above, industrial controller 118 controls industrial equipment 210 based on the monitored state of equipment 210, such as one or more machines, production lines, motion systems, or other such equipment that manufacture products or perform batch processing. Sensor 206 or other input devices read the measurement state 216 from equipment 210 and transmit this state information as input data 202 to controller 118. Control program 214 (e.g., ladder logic program or another type of control program) executed by controller 118 processes the input data 202 and sets the value or state of output data 204 of effector 208 based on the current value or state of input data 202 (representing the current measurement state 216 of the equipment). Output data 204 controls the state of effector 208 (e.g., pneumatic or hydraulic actuator, motor contactor, frequency converter, vision indicator, etc.), and the state of effector 208 is translated into control action 212 to control the behavior of equipment 210. In some control architectures, industrial controller 118 uses industrial communication protocols (e.g., CIP Class 1, Profinet, or another industrial protocol) to exchange data with industrial equipment 120 via an industrial network.

[0032] In many control system development scenarios, system designers can virtually test run the control program 214 that will be executed on the controller 118 before putting the controller 118 into field use. Figure 3This diagram illustrates a virtual trial run of control program 214 relative to a virtual system. The virtual trial run allows control engineers to test and validate control program 214 without needing to interface controller 118 with physical sensors 206 or effectors 208. Instead, controller 118 exchanges analog data with a virtual model or digital twin of the physical industrial system, which simulates the behavior of the mechanical industrial equipment and its associated sensors and effectors. The virtual system replaces the physical industrial equipment 210 with a digital simulation 310 of the equipment, and uses corresponding sensor simulators 302 and effector simulators 304, as well as a network simulator simulating the network between controller 118 and industrial equipment 120. Figure 3 (not shown) instead of the associated industrial equipment 120 (e.g., sensor 206 and effector 208).

[0033] The sensor simulator 302 of the virtual system generates analog input data 306 based on the simulated state and behavior of the industrial equipment, and sends the data 306 to the controller 118. The controller 118 processes the analog input data 306 according to the control program 214, and generates output data 308 for the effector simulator 304 of the virtual system based on the processing. By observing the simulated behavior of the virtual system under the control of the industrial controller 118, the control program 214 can be tested and debugged before being deployed in the factory workshop.

[0034] Figure 4 This is a diagram illustrating an example industrial simulation architecture. In this example, the simulation platform hosting the virtual system 406 can run on a hardware platform 404, such as a Windows box, and the controller 118 can exchange simulation data 408 (including input data 306 and output data 308) with the virtual system 406 via a network 402 that links the controller 118 to the simulation hardware platform 404.

[0035] However, this simulation architecture cannot accurately model the timing of communication between the controller 118 and the physical equipment and devices that constitute the controlled industrial system. Figure 5 This is an example timing diagram illustrating periodic data exchange between an industrial controller 118 and an industrial device 120 (e.g., sensor 206 or effector 208). In a physical control environment, industrial communication protocols such as Common Industrial Protocol (CIP) Class 1 require that, according to a regular periodic schedule with a fixed frequency, the controller 118 sends data packets to each device 120, and the device 120 sends its data packets to the controller 118. Figure 5In the depicted example, industrial controller 118 sends data packets to device 120 at a first frequency corresponding to a first packet interval between data packet transmissions. Industrial device 120 sends its data packets back to controller 118 at a second frequency corresponding to a second packet interval between data packet transmissions.

[0036] Depending on the type or function of device 120, the packet interval of controller 118 may differ from that of device 120. For example, sensor 206 may send input data 202 back to controller 118 at a high frequency (short packet interval), while controller 118 may send data packets to sensor 206 at a lower frequency (with a longer packet interval) to periodically inform sensor 206 that controller 118 is still present. Furthermore, controller 118 may send output data 204 to effector 208 at a high frequency, while effector 208 may send data packets to controller 118 at a lower frequency to indicate that effector 208 is still present. Each of controller 118 and device 120 sends its data packets according to its fixed packet interval, regardless of the timing of incoming packets from another device (i.e., it does not send packets in response to requests received from another device). For a given control application comprising many industrial devices 120, controller 118 will maintain many such data conversations (one conversation with each device 120). In some physical environments, data exchange occurs at very high frequencies, with short network packet intervals sometimes as low as 125 microseconds (i.e., at a rate of one packet every 125 microseconds). For some control applications, such as motion control applications, the timing of these network packets must be extremely precise.

[0037] In the realm of virtual simulation, where industrial controller 118 exchanges data with hardware platform 404 of a virtual system 406 that digitally represents physical equipment, scheduling data packets to be sent at high frequencies and short, precise intervals to represent what is seen in the physical environment can be problematic. This is partly due to limitations imposed by the system clock used by the operating system of hardware platform 404, whose default timer granularity may not be small enough to allow scheduling data packets at the short intervals required in the physical control environment. In the case of a Windows operating system, for example, the default timer granularity may be only 10 milliseconds. Furthermore, the operating system of hardware platform 404 may only be able to schedule data packets with relatively low precision (e.g., approximately 4 milliseconds), many times lower than the high levels of timing precision required by many control applications. Hardware platform 404 cannot support the highly variable data packet timing or jitter that would result from the high-frequency, high-precision data exchange that reflects the physical control system.

[0038] To address these and other issues, one or more embodiments described herein provide an industrial simulation system that can exchange data with an industrial controller 118 at a suitably high frequency and accuracy without requiring additional network emulation hardware, even if the simulation system is executed on a hardware platform whose default timer granularity is insufficient to accurately simulate the communication speeds of a real factory floor. In one or more embodiments, the simulation system uses the arrival event of data packets received from the industrial controller 118 as the clock signal driving the transmission of data packets from the virtual system to the controller 118, instead of using the operating system of the hardware platform or the clock signal of a separate network emulation hardware to time the transmission of data packets from the simulation system to the industrial controller 118. Because controller 118 is a real-time system that sends its data packets to the simulation devices (e.g., sensor simulator 302 and effector simulator 304) at precisely timed intervals controlled by its own internal clock and at the same frequency at which the controller sends output data 204 to physical device 120, a suitable high-frequency data packet stream from controller 118 can be selected as the clock signal. The simulation system will use this clock signal to schedule its data packet transmission to controller 118. Using the arrival time of data packets from industrial controller 118 as the clock signal, instead of the operating system's system clock, can generate high-precision, low-jitter data exchange during simulation.

[0039] Figure 6 This is a block diagram of an example industrial simulation system 602 that uses the arrival time of data packets from an industrial controller to trigger the sending of analog device data packets to the controller. The industrial simulation system 602 may include a user interface component 604, a controller interface component 606, an analog component 608, a communication control component 610, one or more processors 618, and a memory 620. In various embodiments, one or more of the user interface component 604, controller interface component 606, analog component 608, communication control component 610, one or more processors 618, and memory 620 may be electrically and / or communicatively coupled to each other to perform one or more functions of the industrial simulation system 602. In some embodiments, components 604, 606, 608, and 610 may include software instructions stored on memory 620 and executed by processor 618. The industrial simulation system 602 may also be coupled with… Figure 6 It may interact with other hardware and / or software components not depicted herein. For example, processor 618 may interact with one or more external user interface devices, such as a keyboard, mouse, display monitor, touchscreen, or other such interface devices.

[0040] User interface component 604 can be configured to receive user input and present output to the user in any suitable format (e.g., visual, audio, haptic, etc.). In some embodiments, user interface component 604 can present an interactive display screen on a display device (e.g., a display device associated with a desktop computer, laptop computer, tablet computer, smartphone, etc.), wherein the display screen serves as an interface to the simulation platform. The industrial simulation performed by system 602 can be presented by user interface component 604 in any suitable format. For example, in some embodiments, user interface component 604 can display a virtual 3D representation of an automated system being tested relative to industrial control program 214, and the virtual representation can be animated to reflect the substantially real-time simulated behavior of the automated system under the control of the industrial controller executing program 214. Some embodiments of user interface component 604 can also present operational statistics based on simulation results.

[0041] The controller interface component 606 can be configured to connect via a network (e.g., Figure 4 The network 402 shown communicatively interfaces system 602 with hardware industrial controller 118 and exchanges simulation data between controller 118 and a virtualized model of the industrial system simulated by system 602 (also referred to herein as virtual system 406). Simulation component 608 can be configured to simulate the operation of virtual system 406 under the control of industrial control program 214 executed by controller 118. Communication control component 610 can be configured to schedule the transmission of simulation data from virtual system 406 (e.g., from simulated I / O devices such as sensor simulator 302 and effector simulator 304) to industrial controller 118 via network connection based on the arrival time of data packets from industrial controller.

[0042] One or more processors 618 may perform one or more of the functions described herein with reference to the systems and / or methods disclosed herein. Memory 620 may be a computer-readable storage medium storing computer-executable instructions and / or information for performing the functions described herein with reference to the systems and / or methods disclosed herein with reference to the systems.

[0043] Figure 7 This diagram illustrates the exchange of analog data between simulation system 602 and industrial controller 118 during the simulation of an industrial system. Similar to... Figure 3The depicted virtual commissioning scenario uses a simulation system 602 to execute a digital, analog-capable model of an industrial automation system. The digital model includes a digital simulation 310 of industrial equipment (e.g., industrial machines or production lines) and device simulators 302 and 304, which model sensors and effectors respectively. Device simulators 302 and 304 serve as I / O devices for interfacing the industrial equipment with the industrial controller 118. Sensor simulator 302 can simulate digital and analog input devices such as light sensors, proximity switches, telemetry devices (e.g., thermometers, pressure gauges, flow meters, voltmeters, etc.), buttons, safety input devices (e.g., light curtains, safety mats, pull cords, etc.), or other such sensors. Effector simulator 304 can simulate digital and analog output devices such as pneumatic or hydraulic actuators, motor contactors, visual or audible indicators, stack lights or alarms, or other such effectors. From the controller 118's perspective, some simulated devices, such as variable frequency drives or industrial robots, can act as both sensors and effectors (or multiple sensors and effectors).

[0044] As described above, when using industrial communication protocols such as CIP Class 1 in a physical factory workshop environment, the industrial controller 118 maintains a separate data exchange dialogue with each I / O device 120 (sensor 206 and effector 208), whereby the controller 118 sends data packets to the device 120 at a first fixed packet interval, and the device 120 sends data packets to the controller 118 at a second fixed packet interval (e.g., ...). Figure 5 (As shown). During operation of industrial control applications that include many I / O devices, numerous such dialogues occur between the controller 118 and the devices 120 that constitute the controlled system. The frequency at which data packets are sent by the controller 118 or the devices 120 can vary across the control system, as described above. Figure 5 As pointed out.

[0045] Similarly, in the virtual domain, controller 118 maintains separate data conversations with each of device emulators 302 and 304, where the frequency at which data packets are sent by controller 118 or device emulators 302, 304 varies across the analog system. Since industrial controller 118 is a real-time hardware control device with its own internal clock, it sends its data packets (e.g., output data 308 to effector emulator 304) to the analog system at precisely timed intervals controlled by its clock and at a frequency similar to the frequency at which packets will be sent to physical I / O devices 120. For data packets sent from device emulators 302, 304 to controller 118 (e.g., input data 306 generated by sensor emulator 302), the default timer granularity of the operating system on which the analog system 602 operates may not be small enough to drive the high-frequency, short-interval data packet transmissions expected by some physical devices 120. Therefore, in order to accurately simulate the high-frequency data packet transmission of the physical I / O device 120, the simulation system 602 triggers the transmission of data packets from the device simulators 302 and 304 to the controller 118 based on the arrival time of the data packets from the controller 118 rather than the system clock of the operating system.

[0046] Therefore, the communication control unit 610 of the simulation system can select a suitable stream of data packets from the controller 118 to act as a clock signal driving the transmission of data packets from the virtual system to the controller 118. Figure 7 In the depicted example, the data packets that carry output data 3081 to effector emulator 3041 are selected as clock signals. Typically, a stream of any data packets from controller 118 with a sufficiently high frequency (low packet spacing) can be used as a clock signal to drive the transmission of data packets from device emulators 302, 304 to controller 118. The selected clock data packets do not need to be functionally related to the device data packets sent back to controller 118 from emulated devices 302, 304. Instead, the controller data packets selected as clock signals can correspond to the output data 3081 of effector emulator 304, which is not directly related to the emulated device whose data packets will be scheduled by the selected controller data packets.

[0047] Figure 8 This is an example data exchange timing diagram illustrating the use of data packets from controller 118 as a clock signal to trigger the transmission of data packets from the simulation system to controller 118. During the simulation of the virtual system, controller 118 sends data packets to device emulators 302, 304 at a corresponding fixed frequency (e.g., if using...). Figure 4The depicted architecture is via network 402. For a given simulation device, the frequency at which controller 118 sends data packets to the simulation device can depend on the type or function of the device within the industrial system. For example, controller 118 may send data packets to sensor simulator 302 at a relatively low frequency (long packet intervals) because the primary function of sensor simulator 302 is to send high-frequency input data 306 representing the measurement status of the virtualized industrial equipment (digital analog 310) to controller 118, while controller 118 may only send low-frequency data packets back to sensor simulator 302 to indicate that the controller is still present. However, controller 118 may send data packets to effector simulator 304 at a relatively high frequency because these data packets transmit output data 308 used to control the state of effector 304.

[0048] From the available data packet streams to be sent by controller 118 to the corresponding device emulators 302, 304, simulation system 602 can select a stream of data packets 802 from controller 118 that meet the criteria defined for the suitability of the packet stream as a clock signal. For example, system 602 can select data packets 802 with a sufficiently high packet frequency (i.e., a sufficiently short packet interval). Figure 7 In the illustrated example, the output data 3081 is transmitted to the effector simulator 3041 in a stream of data packets, such that packet 802 is suitable for use as a clock signal.

[0049] In some implementations, as an alternative to automatic selection of data streams, system 602 may allow the user to explicitly select the data packet stream to be used as the clock signal. The simulation system 602 uses the arrival time of the data packets 802 from the selected packet stream as the clock signal for sending the data packets from device emulators 302, 304 to controller 118.

[0050] During simulation, in response to the arrival of a controller data packet 802 designated as a clock signal for the detected data stream, simulation system 602 sends any device data packets 804 scheduled for transmission to controller 118 within the current clock cycle. These device data packets may include, for example, packets 804 transmitting analog input data 306 generated by sensor simulator 302, and any lower-frequency data packets 804 transmitting data generated by effector simulator 304 (e.g., data packets indicating the presence of the effector simulator to controller 118 and receiving output data 308 from the controller). The device data packets 804 sent by simulation system 602 do not need to be functionally related to the controller data packet 802 that triggered the transmission of device packet 804. Instead, any device data packet 804 currently scheduled to be sent to controller 118 will be sent upon detection of the arrival of the next controller data packet 802, regardless of the functional relationship between controller data packet 802 and device data packet 804 within the context of the control application being simulated.

[0051] The processing of data packets 804 by the transmitting device, performed by the simulation system 602, can vary depending on the operating system running on the simulation system 602. Figure 8 In the depicted example, in response to detecting the arrival of the next controller data packet 802 in the selected data packet stream, the simulation system 602 may trigger an interrupt (e.g., by calling a Windows interrupt service routine in the case of a Windows operating system), execute device emulators 302, 304 to update device data packet 804, and send device data packet 804 to controller 118. In some implementations, the simulation system 602 will defer processing of the received controller data packet 802 until after device data packet 804 has been sent. This ensures that device data packet 804 is sent at the correct time, since the time required to process controller data packet 802 may be variable.

[0052] Whenever a controller data packet 802, designated as a clock signal, is received, the analog system 602 executes... Figure 8 The sequence depicted. In some control applications, the device data packets 804 sent to controller 118 in response to the arrival of controller data packets 802 may not be the same in each clock cycle, but may depend on which device emulators 302, 304 are scheduled to send data packets 804 to controller 118 in the current clock cycle.

[0053] Since the timing of controller data packets 802 is strictly controlled by the controller's internal clock, and packets 802 are transmitted at a high frequency with short packet intervals reflecting numerous physical I / O devices, triggering the transmission of device data packets 804 based on the arrival time of these controller data packets 802 rather than the operating system clock can more reliably and accurately simulate industrial communication protocols that transmit device data at short packet intervals, thereby reducing or eliminating jitter during simulation. Furthermore, this method does not require additional external hardware or circuitry to emulate industrial networks or replace the operating system clock of the simulation hardware platform.

[0054] While this analog data exchange method is described herein within the context of an industrial simulation architecture in which hardware controller 118 exchanges data with virtualized industrial equipment, some embodiments of simulation system 602 may also use this method to exchange analog data with a simulated (or virtualized) industrial controller that simulates the execution of control program 214. In some such embodiments, the simulated industrial controller may execute on the same hardware platform as simulation system 602, and use the hardware and software resources of the shared hardware platform to exchange analog input and output data between the simulation controller and simulation system 602.

[0055] Figure 9 Methods according to one or more embodiments of this application are illustrated. Although the methods shown herein are illustrated and described as a series of actions for the purpose of simplicity, it should be understood and appreciated that the invention is not limited to the order of actions, as some actions may occur in a different order than those shown and described herein and / or simultaneously with other actions. For example, those skilled in the art will understand and appreciate that the method may alternatively be represented as a series of interrelated states or events, such as in a state diagram. Furthermore, not all of the actions shown may be required to implement the method according to the invention. Additionally, an interaction diagram may represent the method or manner according to this disclosure when different entities perform different parts of the method. Furthermore, two or more of the disclosed example methods may be implemented in combination with each other to achieve one or more features or advantages described herein.

[0056] Figure 9An example method 900 is shown for exchanging analog controller and device data between a hardware industrial controller and a virtualized industrial system running on an analog platform. Initially, at 902, a communication connection is established between the industrial controller and the virtualized industrial system running on the analog platform. In some architectures, the connection can be established via a network connection linking the industrial controller to a hardware platform (e.g., a computer configured with Windows or another operating system) on which the analog platform runs. The virtualized industrial system includes a digital model of a real-world industrial system—e.g., an industrial machine or production line—to be controlled by the industrial controller.

[0057] At 904, a simulation of the virtualized industrial system is performed under the control of the industrial controller. During this simulation, the virtualized industrial system receives controller output data from the industrial controller directed to various simulated I / O devices of the virtualized industrial system, simulates the behavior of the industrial system in response to the controller output data, and sends simulated device data back to the controller based on various simulated real-time states of the virtualized industrial system. The timing of these data exchanges is handled according to steps 906 to 910 of method 900 discussed below.

[0058] At step 906, it is determined whether a controller data packet has been received at the simulation platform. Typically, the controller sends data packets to multiple simulated I / O devices defined as part of the virtualized industrial system. For each simulated I / O device, the controller sends its output data packets at a fixed packet interval, which may vary for different I / O devices. If no controller data packet is received ("No" at step 906), the method returns to step 904 and continues the simulation. Alternatively, if a controller data packet is received ("Yes" at step 906), the method proceeds to step 908, where it is determined whether the controller data packet received at step 906 is a packet designated as a clock signal for sending simulated device data back to the controller. In this regard, a designated stream of controller data packets from the controller to a specific simulated I / O device can be pre-selected as the clock signal driving the sending of device data packets from the virtualized industrial system back to the controller. If the controller data packet received at step 906 is not a data packet from the specified data stream ("No" at step 908), the method returns to step 904 and continues to perform the simulation.

[0059] Alternatively, if the controller data packet received at step 906 is a packet already designated as a clock signal ("Yes" at step 908), the method proceeds to step 910, where device data packets generated by one or more simulated I / O devices of the virtualized industrial system are sent to the industrial controller. The specific device data packets sent at step 910 may be those currently scheduled to be sent to the controller in the current clock cycle. The method then returns to step 904 and continues the simulation.

[0060] The embodiments, systems, and components described herein, as well as the control systems and automation environments capable of performing the various aspects set forth in this specification, may include computer or network components capable of interacting across a network, such as servers, clients, programmable logic controllers (PLCs), automation controllers, communication modules, mobile computers, on-vehicle computers for mobile vehicles, wireless components, control components, etc. Computers and servers include one or more processors—electronic integrated circuits that use electrical signals to perform logical operations—configured to execute instructions stored in a medium, such as random access memory (RAM), read-only memory (ROM), hard disk drives, and removable storage devices, which may include memory sticks, memory cards, flash drives, external hard disk drives, etc.

[0061] Similarly, the term PLC or automation controller as used herein can encompass functionality that can be shared across multiple components, systems, and / or networks. As an example, one or more PLCs or automation controllers can communicate and collaborate with various networked devices across a network. This can essentially include any type of control, communication module, computer, input / output (I / O) device, sensor, actuator, and human-machine interface (HMI) communicating via a network, including control networks, automation networks, and / or public networks. PLCs or automation controllers can also communicate with and control a variety of other devices, such as standard or safety-grade I / O modules including analog, digital, programmable / intelligent I / O modules, other programmable controllers, communication modules, sensors, actuators, output devices, etc.

[0062] Networks can include: public networks such as the Internet; intranets; and automation networks such as Control and Information Protocol (CIP) networks, including DeviceNet, ControlNet, security networks, and Ethernet / IP. Other networks include Ethernet, DH / DH+, remote I / O, fieldbus, Modbus, Profibus, CAN, wireless networks, serial protocols, etc. Additionally, network devices can include a wide range of possibilities (hardware and / or software components). These include components such as: switches with Virtual Local Area Network (VLAN) capabilities, LANs, WANs, agents, gateways, routers, firewalls, Virtual Private Network (VPN) devices, servers, clients, computers, configuration tools, monitoring tools, and / or other devices.

[0063] In order to provide context for the various aspects of the disclosed topic, Figure 10 and Figure 11 The following discussion is intended to provide a brief, general description of suitable environments in which various aspects of the disclosed subject matter can be implemented. Although the various embodiments have been described above in the general context of computer-executable instructions that can run on one or more computers, those skilled in the art will recognize that the embodiments may also be implemented in combination with other program modules and / or as a combination of hardware and software.

[0064] Typically, program modules include routines, programs, components, data structures, etc., that perform specific tasks or implement specific abstract data types. Furthermore, those skilled in the art will understand that the methods of this invention can be practiced using other computer system configurations, including single-processor or multi-processor computer systems, minicomputers, mainframe computers, Internet of Things (IoT) devices, distributed computing systems, and personal computers, handheld computing devices, microprocessor-based or programmable consumer electronics, each of which can be operatively coupled to one or more associated devices.

[0065] The implementations shown herein can also be practiced in distributed computing environments, where certain tasks are performed by remote processing devices linked via a communication network. In a distributed computing environment, program modules can reside on both local and remote memory storage devices.

[0066] Computing devices typically include various media, which can include computer-readable storage media, machine-readable storage media, and / or communication media, as described below. These two terms are used interchangeably herein. A computer-readable storage medium or a machine-readable storage medium can be any available storage medium accessible by a computer, and includes both volatile and non-volatile media, as well as both removable and non-removable media. By way of example, and not limitation, a computer-readable storage medium or a machine-readable storage medium can be implemented in combination with any method or technique for storing information such as computer-readable or machine-readable instructions, program modules, structured or unstructured data.

[0067] Computer-readable storage media may include, but are not limited to: random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD), Blu-ray disc (BD) or other optical disc storage devices, magnetic tape cassettes, magnetic tape, disk storage devices or other magnetic storage devices, solid-state drives or other solid-state storage devices, or other tangible and / or non-transitory media. In this regard, the terms “tangible” or “non-transitory” used herein to describe storage devices, memories, or computer-readable media should be understood as modifiers that exclude only the propagation of transient signals themselves, and do not waive the rights to all standard storage devices, memories, or computer-readable media that do not solely propagate transient signals themselves.

[0068] Computer-readable storage media can be accessed by one or more local or remote computing devices, for example via access requests, queries or other data retrieval protocols, for various operations concerning the information stored on the media.

[0069] Communication media typically embody computer-readable instructions, data structures, program modules, or other structured or unstructured data in data signals such as modulated data signals, carrier waves, or other transmission mechanisms, and include any information delivery or transmission medium. The term "modulated data signal" or signal refers to a signal whose characteristics are set or altered in a manner that encodes information in one or more signals. By way of example and not limitation, communication media include wired media such as wired networks or direct wired connections, and wireless media such as acoustic, RF, infrared, and other wireless media.

[0070] Refer again Figure 10An example environment 1000 for implementing various embodiments of the aspects described herein includes a computer 1002, which includes a processing unit 1004, system memory 1006, and a system bus 1008. The system bus 1008 couples system components to the processing unit 1004, including but not limited to the system memory 1006. The processing unit 1004 can be any processor from a variety of commercially available processors. Dual microprocessors and other multiprocessor architectures can also be used as the processing unit 1004.

[0071] System bus 1008 can be any of several types of bus structures that can also interconnect with a memory bus (with or without a memory controller); a peripheral bus; and a local bus using any of a variety of commercially available bus architectures. System memory 1006 includes ROM 1010 and RAM 1012. The Basic Input / Output System (BIOS) can be stored in non-volatile memory such as ROM, erasable programmable read-only memory (EPROM), or EEPROM, containing basic routines that, for example, help transfer information between components within computer 1002 during startup. RAM 1012 may also include high-speed RAM, such as static RAM for caching data.

[0072] Computer 1002 also includes an internal hard disk drive (HDD) 1014 (e.g., EIDE, SATA), one or more external storage devices 1016 (e.g., floppy disk drive (FDD) 1016, memory stick or flash drive reader, memory card reader, etc.), and an optical disc drive 1020 (e.g., capable of reading from or writing to CD-ROMs, DVDs, BDs, etc.). Although the internal HDD 1014 is shown as being located within computer 1002, it can also be configured for external use within a suitable chassis (not shown). Additionally, although not shown in environment 1000, a solid-state drive (SSD) can be used in addition to HDD 1014, or an SSD can be used instead of HDD 1014. HDD 1014, external storage devices 1016, and optical disc drive 1020 can be connected to system bus 1008 via HDD interface 1024, external storage interface 1026, and optical drive interface 1028, respectively. The interface 1024 for the external driver implementation may include at least one or both of Universal Serial Bus (USB) and Institute of Electrical and Electronics Engineers (IEEE) 1394 interface technologies. Other external driver connectivity technologies are within the scope of the embodiments described herein.

[0073] The drive and its associated computer-readable storage medium provide non-volatile storage of data, data structures, computer-executable instructions, etc. For computer 1002, the drive and storage medium are adapted to store any data in a suitable digital format. Although the above description of computer-readable storage media refers to various types of storage devices, those skilled in the art will understand that other types of computer-readable storage media may also be used in the example operating environment, whether such storage media are currently existing or to be developed in the future, and furthermore, any such storage medium may contain computer-executable instructions for performing the methods described herein.

[0074] Multiple program modules, including an operating system 1030, one or more application programs 1032, other program modules 1034, and program data 1036, can be stored in the driver and RAM 1012. All or part of the operating system, applications, modules, and / or data can also be cached in RAM 1012. The systems and methods described herein can be implemented using various commercially available operating systems or combinations of operating systems.

[0075] Computer 1002 may optionally include emulation technology. For example, a hypervisor (not shown) or other intermediate program may emulate the hardware environment used for operating system 1030, and the emulated hardware may optionally be different from the hardware used for operating system 1030. Figure 10 The hardware shown is illustrated. In such an implementation, the operating system 1030 may include one of a plurality of virtual machines (VMs) hosted at the computer 1002. Furthermore, the operating system 1030 may provide the application 1032 with a runtime environment such as a Java runtime environment or a .NET Framework runtime environment. A runtime environment is a consistent execution environment that allows the application 1032 to run on any operating system that includes that runtime environment. Similarly, the operating system 1030 may support containers, and the application 1032 may be in the form of a container, which is a lightweight, standalone, executable software package that includes, for example, code, runtime, system tools, system libraries, and application settings.

[0076] Furthermore, security modules such as Trusted Processing Modules (TPMs) can be used to enable computer 1002. For example, using a TPM, the bootloader hashes the next bootloader in time and waits for the result to match a security value before loading the next bootloader. This process can occur at any level of the code execution stack of computer 1002, such as at the application execution level or at the operating system (OS) kernel level, thereby achieving security at any level of code execution.

[0077] Users can input commands and information into computer 1002 through one or more wired / wireless input devices (e.g., keyboard 1038, touchscreen 1040, and pointing devices such as mouse 1042). Other input devices (not shown) may include microphones, infrared (IR) remote controls, radio frequency (RF) remote controls, or other remote controls, joysticks, virtual reality controllers and / or virtual reality headsets, gaming pads, styluses, image input devices (e.g., camera devices), gesture sensor input devices, visual motion sensor input devices, emotion or face detection devices, biometric input devices (e.g., fingerprint or iris scanners), etc. These and other input devices are typically connected to processing unit 1004 via input device interface 1022, which can be coupled to system bus 1008, but may also be connected via, for example, parallel ports, IEEE 1394 serial ports, gaming ports, USB ports, IR interfaces, etc. Connect to other interfaces such as the interface itself.

[0078] Monitor 1044 or other types of display devices can also be connected to system bus 1008 via an interface such as video adapter 1046. In addition to monitor 1044, the computer typically includes other peripheral output devices (not shown), such as speakers, printers, etc.

[0079] Computer 1002 can operate in a networked environment using logical connections to one or more remote computers, such as remote computer 1048, via wired and / or wireless communications. Remote computer 1048 can be a workstation, server computer, router, personal computer, portable computer, microprocessor-based entertainment device, peer-to-peer device, or other public network node, and typically includes many or all of the elements described with respect to computer 1002; however, for brevity, only memory / storage device 1050 is shown. The depicted logical connections include wired / wireless connections to a local area network (LAN) 1052 and / or a larger network (e.g., a wide area network (WAN) 1054). Such LAN and WAN networking environments are common in offices and companies and facilitate enterprise-wide computer networks such as intranets, all of which can connect to global communication networks such as the Internet.

[0080] When used in a LAN networking environment, computer 1002 can connect to local network 1052 via a wired and / or wireless communication network interface or adapter 1056. Adapter 1056 can facilitate wired or wireless communication with LAN 1052, which may also include a wireless access point (AP) disposed thereon for communicating with adapter 1056 in wireless mode.

[0081] When used in a WAN networking environment, computer 1002 may include modem 1058, or may be connected to a communication server on WAN 1054 via other means (e.g., via the Internet) for establishing communication over WAN 1054. Modem 1058, which may be an internal or external device and may be a wired or wireless device, may be connected to system bus 1008 via input device interface 1022. In a networking environment, program modules or portions of program modules depicted with respect to computer 1002 may be stored in remote memory / storage device 1050. It should be understood that the network connection shown is an example, and other means for establishing communication links between computers may be used.

[0082] When used in a LAN or WAN networking environment, in addition to, or instead of, the external storage device 1016 described above, computer 1002 can access cloud storage systems or other network-based storage systems. Typically, a connection between computer 1002 and the cloud storage system can be established, for example, via adapter 1056 or modem 1058 through LAN 1052 or WAN 1054. After connecting computer 1002 to the associated cloud storage system, external storage interface 1026 can manage the storage provided by the cloud storage system, just as other types of external storage, with the help of adapter 1056 and / or modem 1058. For example, external storage interface 1026 can be configured to provide access to cloud storage sources as if these sources were physically connected to computer 1002.

[0083] Computer 1002 can be operated to communicate with any wireless device or entity operably arranged wirelessly, such wireless device or entity being, for example, a printer, scanner, desktop and / or portable computer, portable data assistant, communications satellite, any equipment or location associated with a wirelessly detectable tag (e.g., kiosks, newsstands, store shelves, etc.), and telephone. This can include Wi-Fi and Wireless technology. Therefore, communication can be a predefined structure like a regular network or simply ad hoc communication between at least two devices.

[0084] Figure 11This is a schematic block diagram of a sample computing environment 1100 that can interact with the disclosed subject matter. The sample computing environment 1100 includes one or more clients 1102. Clients 1102 can be hardware and / or software (e.g., threads, processes, computing devices). The sample computing environment 1100 also includes one or more servers 1104. Servers 1104 can also be hardware and / or software (e.g., threads, processes, computing devices). For example, server 1104 can accommodate threads to perform transformations by employing one or more implementations as described herein. One possible communication between client 1102 and server 1104 can be in the form of data packets suitable for transmission between two or more computer processes. The sample computing environment 1100 includes a communication framework 1106 that can be used to facilitate communication between client 1102 and server 1104. Client 1102 is operatively connected to one or more client data storage devices 1108 that can be used to store information locally on client 1102. Similarly, server 1104 is operatively connected to one or more server data storage devices 1110 that can be used to store information locally on server 1104.

[0085] The above description includes examples of the invention. It is certainly impossible to describe every conceivable combination of components or methods in order to describe the disclosed subject matter, but those skilled in the art will recognize that many other combinations and substitutions of the invention are possible. Therefore, the disclosed subject matter is intended to cover all such changes, modifications, and variations that fall within the spirit and scope of the appended claims.

[0086] In particular, with respect to the various functions performed by the components, devices, circuits, systems, etc., described above, unless otherwise indicated, the terminology used to describe such components (including references to "means") is intended to correspond to any component that performs the specified function of the described component (e.g., any functionally equivalent component), even if the component is not structurally equivalent to the disclosed structure, but the component still performs the functions of the exemplary aspects of the disclosed subject matter shown herein. In this regard, it should also be recognized that the disclosed subject matter includes computer-readable media and systems having computer-executable instructions for actions and / or events of various methods for performing the disclosed subject matter.

[0087] Furthermore, while a particular feature of the disclosed subject matter may be disclosed for only one of several implementations, such features may be combined with one or more other features of other implementations if they are desirable and advantageous for any given application or particular application. Moreover, with regard to the use of the terms "includes" and "including" and their variations in the detailed description or claims, these terms are intended to be inclusive in a manner similar to the term "comprising."

[0088] In this application, the word "exemplary" is used to indicate that it is used as an example, instance, or illustration. Any aspect or design described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other aspects or designs. Rather, the use of the word "exemplary" is intended to present the concept in a specific manner.

[0089] The various aspects or features described herein can be implemented as methods, apparatus, or articles of art using standard programming and / or engineering techniques. As used herein, the term "article of art" is intended to include computer programs accessible from any computer-readable device, carrier, or medium. For example, computer-readable media may include, but are not limited to: magnetic storage devices (e.g., hard disks, floppy disks, magnetic stripes...), optical discs [e.g., compact discs (CDs), digital versatile discs (DVDs)...], smart cards, and flash memory devices (e.g., cards, sticks, key drives...).

Claims

1. A system for simulating an industrial system, comprising: Memory that stores executable components; as well as A processor operatively coupled to the memory, the processor executing the executable component, the executable component comprising: Simulation components, configured to perform simulations of the industrial system under the control of an industrial controller, based on a virtual model of the industrial system; and A communication control component, configured to: receive controller data from the industrial controller pointing to the simulation device of the virtual model, and send simulation device data generated by the simulation device to the industrial controller. The communication control component is configured to designate a subset of controller data, pointing to one of the simulation devices, as a clock signal. Controller data packets associated with the subset of controller data are transmitted to the simulation device at a frequency that meets a defined standard, the defined standard being the minimum frequency for simulating device data packet intervals supported by industrial network protocols. The communication control component is further configured to send the analog device data to the industrial controller in response to receiving a controller data packet corresponding to a subset of the controller data.

2. The system according to claim 1, wherein, The communication control unit is configured to specify the subset of controller data based on determining that controller data packets associated with a subset of the controller data are transmitted by the industrial controller at a frequency that meets the defined standard.

3. The system according to claim 1, wherein, The simulation device that generates the simulation device data in response to receiving the controller data packet includes at least one simulation device that is different from the one simulation device to which the subset of the controller data points.

4. The system of claim 1, further comprising a user interface component configured to receive user input selecting a subset of the controller data to be designated as the clock signal.

5. The system according to claim 1, wherein, The simulation equipment includes digital simulations of at least one of the following: optical sensor, proximity switch, telemetry device, button, safety input device, frequency converter, pneumatic or hydraulic actuator, motor contactor, industrial robot, or vision indicator.

6. The system according to claim 1, wherein, The grouping interval of the subset of the controller data defines the corresponding clock period, and In one clock cycle of the clock cycle, the communication control component sends the analog device data before the analog component processes the controller data packet.

7. The system of claim 1, further comprising a user interface component configured to present a graphical representation of the simulation on a client device based on the values ​​of the virtual model, the controller data, and the simulation device data.

8. The system according to claim 1, wherein, The industrial controller is either a hardware industrial controller or a simulated industrial controller.

9. A method comprising: The simulation of the industrial system, performed by a system including a processor based on a digital model of the industrial system and under the control of an industrial controller, includes: Receive controller data from the industrial controller, which is directed to the simulation device of the digital model; A subset of the controller data, directed to one of the simulation devices, is selected as the subset of the controller data designated as a clock signal. Controller data packets associated with this subset of controller data are transmitted to the simulation device at a frequency that meets a defined criterion, which is the minimum frequency at which device data packet intervals supported by industrial network protocols are simulated. In response to receiving a controller data packet corresponding to a subset of the controller data designated as a clock signal, analog device data generated by the simulation device is sent to the industrial controller.

10. The method of claim 9, further comprising: The system selects the subset of controller data to be designated as the clock signal based on determining that controller data packets associated with a subset of the controller data are sent by the industrial controller at frequencies that meet the defined criteria.

11. The method according to claim 9, wherein, The transmission includes: transmitting simulation device data generated by at least one simulation device that is different from the one simulation device to which the subset of the controller data is directed.

12. The method according to claim 9, further comprising: The system selects the subset of controller data to be designated as the clock signal based on the receipt of user input that selects a subset of the controller data.

13. The method according to claim 9, wherein, The simulation equipment includes digital simulations of at least one of the following: optical sensor, proximity switch, telemetry device, button, safety input device, frequency converter, pneumatic or hydraulic actuator, motor contactor, industrial robot, or vision indicator.

14. The method according to claim 9, wherein, The grouping interval of the subset of the controller data defines the corresponding clock period, and The simulation is performed by sending the simulated device data in one of the corresponding clock cycles before processing the controller data packets.

15. A non-transitory computer-readable medium storing instructions thereon, the instructions causing a system including a processor to perform operations in response to execution, the operations including: The simulation of the industrial system is performed based on a virtual model of the industrial system under the control of an industrial controller, wherein the execution includes: Receive controller data from the industrial controller, which is directed to the simulation device of the virtual model; A subset of the controller data, directed to one of the simulation devices, is selected as the subset of the controller data designated as a clock signal. Controller data packets associated with this subset of controller data are transmitted to the simulation device at a frequency that meets a defined criterion, which is the minimum frequency at which device data packet intervals supported by industrial network protocols are simulated. In response to receiving a controller data packet corresponding to a subset of the controller data designated as a clock signal, analog device data generated by the simulation device is sent to the industrial controller.

16. The non-transitory computer-readable medium according to claim 15, wherein, The transmission includes: transmitting simulation device data generated by at least one simulation device that is different from the one simulation device to which the subset of the controller data is directed.

Images