Patent Description:
Industrial controllers are specialized computer systems used for the control of industrial processes or machinery, for example, in a factory environment. Generally, an industrial controller executes a stored control program that reads inputs from a variety of sensors associated with the controlled process or machine and, sensing the conditions of the process or machine, and based on those inputs and a stored control program, calculates a set of outputs used to control actuators controlling the process or machine.

Industrial controllers differ from conventional computers in a number of ways. Physically, they are constructed to be substantially more robust against shock and damage and to better resist external contaminants and extreme environmental conditions than conventional computers. The processors and operating systems are optimized for real-time control and are programmed with languages designed to permit rapid development of control programs tailored to a constantly varying set of machine control or process control applications.

Generally, industrial controllers have a highly modular architecture, for example, that allows different numbers and types of input and output modules to be used to connect the controller to the process or machinery to be controlled. This modularity is facilitated through the use of special "control networks" suitable for highly reliable and available real-time communication. Such control networks (for example, EtherNet/IP, DeviceNet and ControlNet) differ from standard communication networks (such as Ethernet) by guaranteeing maximum communication delays by pre-scheduling the communication capacity of the network, and/or providing redundant communication capabilities for high-availability.

As part of their enhanced modularity, industrial controllers may employ I/O modules or devices dedicated to a particular type of electrical signal and function, for example, detecting input AC or DC signals or controlling output AC or DC signals. Each of these <NUM>/O modules or devices may have a connector system allowing them to be installed in different combinations in a housing or rack along with other selected I/O modules or devices to match the demands of the particular application. Multiple or individual I/O modules or devices may be located at convenient control points near the controlled process or machine to communicate with a central industrial controller via the control network.

Emulation of industrial control devices is often desirable for logic validation of such devices prior to commissioning. Emulation typically involves replicating the behavior of one or more hardware devices in a software emulation environment executed by a host. The emulation environment is intended to mimic the actual automation hardware as closely as possible. Accordingly, an industrial control system and control program may be tested and validated in a more cost effective virtual environment prior to implementation in an actual physical environment. However, once the industrial control system is implemented in the physical environment, maintaining emulation in the virtual environment may be time consuming and may require significant resources and expense. <CIT> relates to a simulation apparatus, simulation method, and simulation program. The simulation apparatus includes a processor configured to execute simulation of a control program executed on a controller, the controller being configured to control motion of a machine that handles an object. The processor includes: a motion control means configured to control, following to the control program, motion of a virtual machine based on a motion command to move the virtual machine in a virtual space, the virtual machine corresponding to the machine; a determination means configured to determine, based on model data of a virtual object and model data of the virtual machine, whether or not a volume of a region where a work space in which the virtual machine works overlaps with the virtual object is equal to or greater than a predetermined reference value, the virtual object being handled by the virtual machine and corresponding to the object; and a follow-up means configured to make the virtual object follow the motion of the virtual machine based on the motion command when the volume is equal to or greater than the reference value. <CIT> relates to a control program development support apparatus. A simulation unit simulates an operation of a mechanism, in a simulation cycle shorter than a control cycle, for a time corresponding to the control cycle, and outputs a state variable of the mechanism to a holding circuit. When the state variable is held in the holding circuit, a simulation control unit makes the simulation unit shift to a response waiting state and makes a control program executing unit calculate a controlled variable. When the controlled variable is held in the holding circuit, the simulation control unit makes the control program execution unit shift to a response waiting state and makes the simulation unit initiate a simulating operation. <CIT> relates to an automation control system including one or more processors and memories with an application stored on the one or more memories and implemented by the one or more processors. The application includes an interface configured to communicate with automation devices via a communication subsystem. Further, the application includes an operation environment, a programming environment, and an emulation environment. The programming environment is configured to generate device elements corresponding to the automation devices within the operation environment in which the device elements are configured to functionally interact with the automation devices. The emulation environment is configured to automatically host an emulation model of the automation devices based on the device elements generated within the operation environment. <CIT> relates to methods and systems for creating and running and industrial control system simulation. The simulation may include animation of a complex machine linked with the industrial control device controlling the complex machine. The simulation may also include links to the physical I/O and other modules of the industrial controller to enhance the functionality of the simulation.

<CIT> relates to a simulation environment which takes into account the configuration of I/O modules into the simulation of a control program, allowing more accurate testing of the exchange of physical I/O signals with the control program under test.

It is the object of the present invention to provide an improved industrial controller for use in an industrial control system, a method for operating the improved industrial controller, and an improved industrial control system comprising the improved industrial controller.

This object is solved by the subject matter of the independent claims which define the present invention.

An emulation module configured to model a logical behavior of an industrial control device is stored or embedded in the industrial control device for subsequent downloading and emulation by another device. The industrial control device storing the emulation module executes firmware for its operation, and the stored emulation module is used to model the logical behavior of the industrial control device executing the firmware. The industrial control device storing the emulation module provides the emulation module to another device using an industry standard bi-directional communication interface, such as an EtherNet/IP control network interface. The industrial control device may also store multiple emulation modules with identifiable revisions, and a revision of an emulation module may correspond to a revision of firmware for execution by the industrial control device.

Multiple devices in an industrial control system may provide respective emulation modules to a host system, which host system may also be one of the devices in the industrial control system or a separate workstation. The host system, in turn, may execute the emulation modules in an emulation environment and may compare one or more parameters, such as counters, timers, variables and/or instructions, to one or more parameters generated by an actual industrial control system executing a controlled process. The host system may also advance execution of the emulation modules to provide an output predicting an action of the actual industrial control system in order to predict a possible undesirable outcome or failure for taking alternative measures.

Accordingly, industrial control hardware components include an emulation model of the physical component. Users may have the ability to extract the emulation model using an industry standard common application interface. The embedded emulation model may be an object of the firmware of the hardware based industrial control component. The emulation model may be locked to the firmware features hosting the emulation model. As a result, emulation in a virtual environment is effectively maintained while an industrial control system is implemented in a physical environment.

Features and advantages of the invention will become apparent to those skilled in the art from the following detailed description and the accompanying drawings. The detailed description describes specific examples and preferred embodiments of the present invention by way of illustration and not of limitation. Many changes and modifications may be made within the scope of the present invention as defined by the appended claims. Examples and embodiments which do not fall under the scope of the appended claims are described for illustration purposes only.

Preferred exemplary embodiments of the invention are illustrated in the accompanying drawings in which like reference numerals represent like parts throughout, and in which:.

Referring now to <FIG>, an industrial control system <NUM> may employ various industrial control devices, such as an industrial controller <NUM> and one or more industrial control I/O modules <NUM> in communication with the industrial controller <NUM> over a high-speed control network <NUM>. The industrial controller <NUM> may be a Programmable Logic Controller (PLC). The I/O modules <NUM> (denoted as modules "<NUM>," "<NUM>" and "<NUM>" in <FIG>), as is understood in the art, may provide for input lines <NUM> and output lines <NUM> to industrial equipment <NUM>, the input lines <NUM> receiving signals from sensors (denoted as "S") associated with the industrial equipment <NUM> and the output lines <NUM> providing signals to actuators (denoted as "A") used in the industrial equipment <NUM>.

The industrial controller <NUM> may utilize a communication interface <NUM> to communicate over the high-speed control network <NUM>. The industrial controller <NUM> may also communicate with a Human Machine Interfaces (HMI) <NUM> over the control network <NUM>, which may display information about the operation of the industrial equipment <NUM> and its associated process. The high-speed deterministic control network <NUM>, for example, may be a well-known bi-directional control network providing highly reliable and available real-time communication, such as such as DeviceNet, ControlNet or EtherNet/IP type networks.

The industrial controller <NUM> includes a multicore processor <NUM> (denoted with processing cores "<NUM>," "<NUM>," "<NUM>" to "n") (controller) which executes computer readable instructions. The processor <NUM> may, in turn, communicate with a chipset <NUM> of the industrial controller <NUM> or similar logic for communicating with other elements of the system. In one aspect, the chipset <NUM> may communicate with a non-transient computer readable first memory <NUM> which may store a control program <NUM> for controlling the I/O modules <NUM> and/or the industrial equipment <NUM>, and may communicate with a non-transient computer readable second memory <NUM> which stores a firmware module <NUM> (denoted as "F0") and an emulation module <NUM> (denoted as "E0") as will be further described. The first memory <NUM> could be, for example, a Dynamic Random Access Memory (DRAM), and may be in communication with a mass storage drive, and the second memory <NUM> could be, for example, a Flash memory. In alternative aspects which are not part of the claimed invention, a single memory or several differing memories and types may be used.

The chipset <NUM> may also communicate with the communication interface <NUM> for communicating bi-directionally over a physical medium such as the control network <NUM>. The chipset <NUM> may also receive a clock signal from a real time clock <NUM>, such as a crystal oscillator and related circuitry in the system, for accurately synchronizing events of the industrial controller <NUM>. The industrial controller <NUM> may also communicate with a workstation <NUM> or standard programming terminal that may accept user commands, for example, using a keyboard and mouse, and output data, for example depictions of the actual control system and/or emulation of the control system, by a graphics monitor.

The firmware module <NUM> is executed by the processor <NUM> for controlling a logical behavior of the industrial controller <NUM>. The emulation module <NUM> is used for modeling a logical behavior of the industrial controller <NUM> executing the firmware module <NUM> when executed in an "emulation environment" (or "program environment"). A different firmware module <NUM> (denoted as "F0'"), which could be an older and/ or alternative version to the firmware module <NUM>, and a different emulation module <NUM> (denoted as "E0'"), which could be older or alternative versions to the firmware module <NUM> and the emulation module <NUM>, respectively, may also be stored in the second memory <NUM> or another memory. The emulation module <NUM> corresponds to the firmware module <NUM>, and the different emulation module <NUM> may correspond to the different firmware module <NUM>, for example, according to having common revision designators between the respective firmware and emulation modules.

The I/O modules <NUM> each include a module communication interface <NUM> for communicating over a physical medium such as the control network <NUM>. The module communication interface <NUM> may further allow communication with the industrial equipment <NUM> via the input lines <NUM> and the output lines <NUM>. The I/O modules <NUM> also include a module controller <NUM>, such a processor, microcontroller or other embedded logic, in communication with the module communication interface <NUM> and a module memory <NUM>. The module memory <NUM> stores a firmware module <NUM>, which is executed by the module controller <NUM> for controlling a logical behavior of the I/O module <NUM>, and an emulation module <NUM>, which is used for modeling a logical behavior of the I/O module <NUM> executing the firmware module <NUM> when executed in an emulation environment.

In alternative aspects, single or differing memories of the I/O modules <NUM> may be used, and older and/or alternative versions of the firmware and/or emulation modules may also be stored, similarly to the industrial controller <NUM>. In addition, sensors, actuators, and/or other industrial control devices may be similarly configured with a communication interface, a controller and a stored emulation module for use in the industrial control system <NUM> as desired.

The control program <NUM> may generally be made up of program elements such as instructions, variable names, objects and the like. By way of example, the control program <NUM> may be written in relay ladder language (RLL) comprised of program elements including rungs and various contacts, coils, and function blocks as are generally understood in the art. In other aspects, the control program <NUM> could be written, for example, in Sequential Function Charts (SFC), structured text, "C" programming, and/or any other technique known in the art.

Referring momentarily to <FIG>, by way of example, a fragment of such a control program <NUM> in RLL that may be executed by in the industrial control system of <FIG> is provided. The control program <NUM>, depicted in conventional graphic form, may provide for a first rung 126a and a second rung 126b one above the other and extending between a symbolic positive and ground rails 129a and 129b, respectively, in the manner of the conventional relay structure. In this example, the first rung 126a provides a normally closed (XIO) contact element <NUM> which when closed may provide power to an on timer <NUM> (TON) and a series connected normally open contact <NUM> (XIC) and output coil <NUM> (OTE), with the latter two connected in parallel with the contact element <NUM>. The second rung 126b provides a normally open contact <NUM> (XIC) in series with an arithmetic exponentiation block <NUM> (XPY) and a copy file block <NUM> (COP).

Referring now to <FIG> , a simplified block diagram of the industrial controller <NUM> receiving an emulation module from another industrial control device, with the industrial controller <NUM> also hosting an emulation environment, is provided. An industrial control device, such as an I/O module <NUM>, transfers a stored emulation module, such as the emulation module <NUM>, via the industrial control device's communication interface to another industrial control device, in this case to the industrial controller <NUM>. The emulation module <NUM> is transferred over the control network <NUM> (or other industry standard communication interface) between the devices in accordance with network protocol. The I/O module <NUM> transfers the emulation module <NUM> to another industrial control device while executing the firmware module <NUM> for operation of the device and while communicating with the industrial equipment <NUM> to control an industrial or automation process.

The industrial controller <NUM> executes the control program <NUM>, via core <NUM> of the processor <NUM> executing the control program <NUM> in a control operating system running in a first area <NUM> of the first memory <NUM>. Accordingly, the control program <NUM> may load/store control data <NUM> in the first area <NUM> for controlling the I/ O module <NUM> and, in turn, the industrial equipment <NUM>. The control data <NUM> may include counters, timers, variables and/or instructions generated by actual control of the industrial equipment <NUM>.

Meanwhile, the industrial controller <NUM>, also hosting the system emulation, further executes to build an emulation environment <NUM> (or program environment for emulation), via core <NUM> of the processor <NUM> executing to build the emulation environment <NUM> in a second operating system running in a second area <NUM> of the first memory <NUM>. The industrial controller <NUM> receives the emulation module <NUM> from the I/O module <NUM> and runs the emulation module <NUM> with its own emulation module <NUM>, with a simulated interconnect <NUM> in between, as an emulation model <NUM> in the emulation environment <NUM>. The industrial controller <NUM> may also provide a copy of the control program <NUM> in the emulation environment <NUM> for the emulation module <NUM> to execute, and may load/store emulated data <NUM> in the second area <NUM>, analogous to the control data <NUM> for controlling the I/O module <NUM> and the industrial equipment <NUM>. The emulated data <NUM> may receive inputs from the industrial equipment <NUM>, though outputs to the emulated data <NUM> will typically not provide outputs to the industrial equipment <NUM>.

The emulation environment <NUM> may also include a clock management module <NUM> in communication with a time reference <NUM>. The clock management module <NUM> may be in communication with the real time clock <NUM> of the industrial controller <NUM>, via layers of communication in the industrial controller <NUM>, for receiving repeatable (periodic) ticks or events. The time reference <NUM> may provide an empirically derived look up table for timing execution of the emulation to match execution of the actual industrial control device and/or industrial control system <NUM> being modeled.

Accordingly, the emulation environment <NUM> executes in lock step (synchronously) with control of the industrial equipment <NUM>. As a result, a parameter, such as a count, time, variable or instruction, updated in the control data <NUM> is updated at approximately the same time as an equivalently emulated parameter being updated in the emulated data <NUM>. This advantageously allows for comparison of the parameters for determining errors in the system.

Alternatively, the emulation environment <NUM> advances execution of the emulation environment <NUM> to be faster than the control of the industrial equipment <NUM>. Accordingly, the emulation environment <NUM> provides an output predicting an action (or parameter) of control of the industrial equipment <NUM>, such as a count, time, variable or instruction expected to occur. This advantageously allows for predicting a possible undesirable outcome or failure, which may allow taking alternative measures to prevent the undesirable outcome or failure.

The emulation module <NUM> (of the industrial controller <NUM>) and the emulation module <NUM> (of the I/O module <NUM>) may both be transferred to the workstation <NUM> and/or the HMI <NUM>. Accordingly, the workstation <NUM> and/or the HMI <NUM> may host the aforementioned emulation environment, which environment may be in addition to the emulation environment <NUM> of the industrial controller <NUM>. The emulation environment <NUM> may be implemented on a processing core of the industrial controller <NUM>, the workstation <NUM> and/or the HMI <NUM> using an instruction set architecture (such as an instruction set architecture suitable for a Microsoft Windows computing platform) that is different from the instruction set architecture implementing the control program <NUM> in the program environment (such as RLL suitable for industrial control). Accordingly, the same control program <NUM> used to execute on the physical controller may also be used to execute in the program environment, thereby making this aspect a true emulation and not a simulation.

Referring now to <FIG>, a simplified block diagram of multiple firmware modules <NUM> and multiple emulation modules <NUM>, which are stored in a memory <NUM> of an industrial control device, is provided. Some of the firmware modules <NUM> may represent older and/or alternative versions, and the emulation modules <NUM> may represent versions corresponding to the firmware modules <NUM>. Accordingly, particular emulation modules <NUM> may correspond to particular firmware modules <NUM> according to common revision designators <NUM> among them.

For example, an older version of a firmware module F0' may be stored in an industrial control device with a revision designator "A. " A controller, such as a processor, microcontroller or other logic, may be configured to execute the older version of the firmware module F0' for operation of the industrial control device. In addition, an older version of an emulation module E0' may also be stored in the industrial control device with a revision designator "A. " Upon request, the controller may transfer the older version emulation module E0' to another device, such as via a standard I/O communication interface. When executed, the older version emulation module E0' may be used to model a logical behavior of the controller executing the older version firmware module F0'. The controller may recognize the older version emulation module E0' to correspond to the older version firmware module F0' according to the common designator "A.

Subsequently, a newer version of a firmware module F0 may be received and stored in the industrial control device with a revision designator "B. " The controller may then execute the newer version firmware module F0. Also, a newer version of an emulation module E0 may be received and stored in the industrial control device with a revision designator "B. " The controller may then recognize the newer version emulation module E0 to correspond to the newer version firmware module F0 according to the common revision designator "B. " Accordingly, upon request, the controller may transfer the newer version emulation module E0 to another device (instead of the older version emulation module E0'), such as via the standard I/O communication interface upon request. In another aspect, the device may be configured to select one of the multiple firmware modules <NUM> for alternative purposes, and may provide a corresponding emulation module <NUM> based on the firmware module <NUM> that is selected.

Referring now to <FIG>, a flow chart illustrating synchronization of an emulation environment to an industrial control process for comparing parameters in real-time and/or for predicting an output of the industrial control process is provided. In process block <NUM>, an industrial control device or other host system, such as a workstation or HMI, receives one or more emulation modules representing one or more industrial control devices in an actual industrial control system (block <NUM>). The host system proceeds to build an emulation environment with the received emulation module using additional conventional libraries and modules, such as for standard interconnects, as necessary.

Next, in block <NUM>, the host system synchronizes the emulation environment to the actual industrial control system (block <NUM>) executing to exchange I/O with an industrial or automation process (block <NUM>). Synchronization in block <NUM> may be accomplished by matching a sequence of data and instructions in a control program of the industrial control system in block <NUM> with a sequence of data and instructions in a control program of the emulation environment in block <NUM> at a fixed point. The industrial control system in block <NUM> may continue to execute in an I/O loop with the industrial or automation process in block <NUM> to control the automation process.

Next, after synchronization, in block <NUM> the host system may execute the emulation environment to emulate the actual industrial control system in block <NUM>. In doing so, the host system may receive inputs from the actual industrial or automation process in block <NUM>, though the host system will typically not provide outputs to the industrial or automation process in block <NUM>.

Next, in block <NUM>, the host system may receive a parameter from the emulation environment in block <NUM>, such as a count, time, variable and/or instruction, and an equivalent parameter from the industrial control system in block <NUM>, also indicating the count, time, variable and/or instruction. The host system may compare the parameters from these sources, and in decision block <NUM>, the host system may determine if an expected outcome has been met (such as an exact match between the parameters, or a match between the parameters within an expected range or tolerance). If the expected outcome has not been met, in block <NUM>, an alert may be sent to a user further investigation and/or to the industrial control system (block <NUM>) for taking preventative measures (such as shutting down a portion or all of the industrial or automation process in block <NUM>). However, if the expected outcome has been met, the process may return to block <NUM> to continue emulation of the industrial control system for another, subsequent comparison. This may continue in a looping fashion as long as the industrial control system in block <NUM> executes in the I/O loop with the industrial or automation process in block <NUM>.

In another aspect, following the emulation of the industrial control system in block <NUM>, a separate process may additionally or alternatively proceed to block <NUM> to advance execution of the emulation environment. Accordingly, instead of running in lock step (synchronously) with the industrial control system in block <NUM>, the emulation environment may run faster than the industrial control system in block <NUM>. As a result, the emulation environment may update the parameter faster, and in block <NUM>, the emulation environment may provide an output predicting an action (which prediction may be based on the updated parameter).

Next, in decision block <NUM>, if the predicted output is within an expected range or tolerance, the emulation environment may return to the advanced execution in the block <NUM> to predict a next output for comparison (which prediction may be based on a next updated parameter). However, if the predicted output is not within an expected range or tolerance, an alert may be sent to a user further investigation and/or to the industrial control system (block <NUM>) for taking preventative measures (such as shutting down a portion or all of the industrial or automation process in block <NUM>).

Certain terminology is used herein for purposes of reference only, and thus is not intended to be limiting. For example, terms such as "upper," "lower," "above," and "below" refer to directions in the drawings to which reference is made. Terms such as "front," "back," "rear," "bottom. " "left" and "right" describe the orientation of portions of the component within a consistent but arbitrary frame of reference which is made clear by reference to the text and the associated drawings describing the component under discussion. Such terminology may include the words specifically mentioned above, derivatives thereof, and words of similar import. Similarly, the terms "first," "second" and other such numerical terms referring to structures do not imply a sequence or order unless clearly indicated by the context.

When introducing elements or features of the present disclosure and the exemplary embodiments, the articles "a," "an," "the" and "said" are intended to mean that there are one or more of such elements or features. The terms "comprising," "including" and "having" are intended to be inclusive and mean that there may be additional elements or features other than those specifically noted. It is further to be understood that the method steps, processes, and operations described herein are not to be construed as necessarily requiring their performance in the particular order discussed or illustrated, unless specifically identified as an order of performance. It is also to be understood that additional steps may be employed.

The controller described above may be a microprocessor, a microcontroller or other programmable logic element as known in the art. References to "a microprocessor" and "a processor" or "the microprocessor" and "the processor" can be understood to include one or more microprocessors that can communicate in a stand-alone and/or a distributed environment(s), and can thus be configured to communicate via wired or wireless communications with other processors, where such one or more processors can be configured to operate on one or more processor-controlled devices that can be similar or different devices. Furthermore, references to memory, unless otherwise specified, can include one or more processor-readable and accessible memory elements and/or components that can be internal to the processor-controlled device, external to the processor-controlled device, and/or can be accessed via a wired or wireless network.

Claim 1:
An industrial controller (<NUM>) for use in an industrial control system (<NUM>), the industrial controller (<NUM>) comprising:
a multicore processor (<NUM>);
a communication interface (<NUM>) in communication with the multicore processor (<NUM>), the communication interface (<NUM>) being operable to communicate over a physical medium (<NUM>);
firmware (<NUM>) stored in a non-transient computer readable medium (<NUM>) of the industrial controller (<NUM>) in communication with the multicore processor (<NUM>), wherein a first core of the multicore processor (<NUM>) is configured to execute the firmware for operation of the industrial controller (<NUM>); and
a first emulation module (<NUM>) stored in the non-transient computer readable medium (<NUM>), wherein the first emulation module (<NUM>) is configured to model a logical behavior of the industrial controller (<NUM>) executing the firmware when the first emulation module (<NUM>) is executed,
wherein the industrial controller (<NUM>) is further configured to receive a second emulation module (<NUM>) from an industrial control module (<NUM>) via the communication interface (<NUM>), wherein the second emulation module (<NUM>) is configured to model a logical behavior of the industrial control module (<NUM>) executing a firmware module stored in the industrial control module (<NUM>),
wherein a second core of the multicore processor (<NUM>) is configured to execute the second emulation module (<NUM>) with the first emulation module (<NUM>),
wherein the second core of the multicore processor (<NUM>) is configured to execute the first emulation module (<NUM>) to model the behavior of the industrial controller (<NUM>) executing the firmware by the first core of the multicore processor (<NUM>), and
wherein the second core of the multicore processor (<NUM>) is configured to execute the first emulation module (<NUM>) to perform:
updating a parameter in lock step with the first core of the multicore processor (<NUM>) controlling the industrial control system to update the parameter; or
updating a parameter faster than the first core of the multicore processor (<NUM>) controlling the industrial control system to update the parameter, and providing an output predicting an action of the first core of the multicore processor (<NUM>) controlling the industrial control system.