TECHNICAL FIELD

This patent application relates generally to industrial and process control systems and, more particularly, to an industrial control system that provides simulation of process control and/or run-time actual process control using virtualized components.

BACKGROUND

Process or industrial control systems, like those used in chemical, petroleum or other industrial process plants to produce physical products from materials, typically include one or more process controllers communicatively coupled to one or more field devices via analog, digital or combined analog/digital buses, or via a wireless communication link or network. The field devices, which may be, for example, valves, valve positioners, switches and transmitters (e.g., temperature, pressure, level and flow rate sensors), are located within the process environment and generally perform physical or process control functions such as opening or closing valves, measuring process parameters, etc., to control one or more processes executing within the process plant or system. Smart field devices, such as the field devices conforming to the well-known FOUNDATION® Fieldbus protocol may also perform control calculations, alarming functions, and other control functions commonly implemented within the controller. The process controllers, which may be centrally located but which may also be located within the plant environment in a distributed manner, receive signals indicative of process measurements made by the field devices and/or other information pertaining to the field devices and execute a controller application that runs, for example, different control modules that make process control decisions, generate control signals based on the received information and coordinate with the control modules or blocks being performed in the field devices, such as HART®, WirelessHART®, and FOUNDATION® Fieldbus field devices. The control modules in the controller send the control signals over the communication lines or links to the field devices to thereby control the operation of at least a portion of the process plant or system.

Information from the field devices and the controller is usually made available from the controllers over a data highway to one or more other hardware devices, such as operator workstations, personal computers or computing devices, data historians, report generators, centralized databases, or other centralized administrative computing devices that are typically placed in control rooms or other locations away from the harsher plant environment. Each of these hardware devices typically is centralized across the process plant or across a portion of the process plant. These hardware devices execute applications that may, for example, enable an engineer to configure portions of the process or an operator to perform functions with respect to controlling a process and/or operating the process plant, such as changing settings of the process control routine, modifying the operation of the control modules within the controllers or the field devices, viewing the current state of the process, viewing alarms generated by field devices and controllers, simulating the operation of the process for the purpose of training personnel or testing the process control software, keeping and updating a configuration database, etc. The data highway utilized by the hardware devices, controllers and field devices may include a wired communication path, a wireless communication path, or a combination of wired and wireless communication paths.

As an example, the DeltaV™ control system, sold by Emerson Process Management, includes multiple applications stored within and executed by different devices located at diverse places within a process plant. A configuration application, which resides in one or more workstations or computing devices, enables users to create or change process control modules and to download these process control modules via a data highway to dedicated distributed controllers. Typically, these control modules are made up of communicatively interconnected function blocks, which are objects in an object-oriented programming protocol that perform functions within the control scheme based on inputs thereto and that provide outputs to other function blocks within the control scheme. The configuration application may also allow a configuration designer to create or change operator interfaces that are used by a viewing application to display data to an operator and to enable the operator to change settings, such as set points, within the process control routines. Each dedicated controller and, in some cases, one or more field devices, stores and executes a respective controller application that runs the control modules assigned and downloaded thereto to implement actual process control functionality. The viewing applications, which may be executed on one or more operator workstations (or on one or more remote computing devices in communicative connection with the operator workstations and the data highway), receive data from the controller application via the data highway and display this data to process control system designers, operators, or users using the user interfaces, and may provide any of a number of different views, such as an operator's view, an engineer's view, a technician's view, etc. A data historian application is typically stored in and executed by a data historian device that collects and stores some or all of the data provided across the data highway while a configuration database application may run in a still further computer attached to the data highway to store the current process control routine configuration and data associated therewith. Alternatively, the configuration database may be located in the same workstation as the configuration application.

The architecture of currently known process control plants and process control systems is strongly influenced by limited controller and device memory, communications bandwidth, and controller and device processor capability. For example, in currently known process control system architectures, the use of dynamic and static non-volatile memory in the controller is usually minimized or, at the least, managed carefully. As a result, during system configuration (e.g., a priori), a user or configuration engineer typically must choose which data in the controller is to be archived or saved, the frequency at which it will be saved, and whether or not compression is used, and the controller is accordingly configured with this limited set of data rules. Consequently, data which could be useful in troubleshooting and process analysis is often not archived, and if it is collected, the useful information may have been lost due to data compression.

Additionally, to minimize controller memory usage in currently known process control systems, selected data that is to be archived or saved (as indicated by the configuration of the controller) is reported to the workstation or computing device for storage at an appropriate data historian or data silo. The current techniques used to report the data poorly utilizes communication resources and induces excessive controller loading. Additionally, due to the time delays in communication and sampling at the historian or silo, the data collection and time stamping is often out of sync with the actual process.

Similarly, in batch process control systems, to minimize controller memory usage, batch recipes and snapshots of controller configuration typically remain stored at a centralized administrative computing device or location (e.g., at a data silo or historian), and are only transferred to a controller when needed. Such a strategy introduces significant burst loads in the controller and in communications between the workstation or centralized administrative computing device and the controller.

Further, the current architecture of industrial control systems, such as process control systems, is largely hardware driven in that various functions, such as control functions, input/output (I/O) functions, user interface functions, etc. are performed in and are tied to specific pieces of hardware (e.g., user workstations or interface devices, process controllers, safety system controllers, dedicated I/O devices, marshalled I/O devices, field devices, safety logic solvers, etc.) and remain stored in the specific hardware at all times. For example, in current process control systems, interconnections between controllers and I/O devices (e.g., either individual I/O devices, or banks of marshalled I/O devices) are configured based on particular hardware, and consequently, physical I/O relationships are tightly bound, most commonly in a one-to-one manner, e.g., I/O device to controller, another I/O device to another controller, etc. This architectural design limits the resiliency, reliability, availability, responsiveness, and the elasticity of the control system, as these systems are difficult to change or reconfigure quickly, are tightly tied to proprietary hardware used to implement proprietary control software, require hardware redundancy on a device by device basis that can be expensive to implement, and are not easily scalable or able to be upgraded without adding additional hardware that needs to be configured in particular manners, for example, due to size limitations of individual devices such as physical process controllers, particular characteristics and capabilities of I/O devices, etc.

Some attempts at addressing these issues include virtualizing physical controllers; however, controller virtualization has been limited to off-line development and test systems, and has not been widely utilized, if at all, for run-time process control in physical plant and/or production environments. Moreover, both virtualized controllers and physical controllers remain subject to the limitations of physical I/O devices, such as performance, bandwidth, throughput, etc.

SUMMARY

A novel, multi-purpose hardware/software architecture or platform for dynamic simulation and/or run-time production process control that enables an industrial or process control system of an industrial process plant to be more resilient, responsive, and elastic as compared to known industrial or process control systems. More particularly, this novel architecture or platform, to a large extent, decouples the hardware used in the control system from the software that governs the behavior of the hardware, making the system easier to scale, reconfigure, and change, as well as improving overall system reliability, availability, and performance. For ease of discussion, the novel Multi-Purpose Dynamic Simulation and run-time Control platform or architecture is referred to interchangeably herein by the “MPDSC,” “the MPDSC platform,” “the MPDSC system, or “the MPDSC architecture.”

Generally speaking, the MPDSC includes a virtual process environment coupled to a physical process environment, where components of the virtual and physical environments cooperate to perform dynamic simulation and/or run-time (e.g., actual or operational) production process control of the industrial process plant. For run-time process control, the MPDSC platform supports Process Control Systems (PCSs) which may include virtual components, physical components, and/or both virtual and physical components that cooperate to monitor and control batch and/or continuous industrial processes during run-time of the plant. In some arrangements, the MPDSC platform also supports Safety Instrumented Systems (SISs) which may have both virtual and physical components that cooperate to maintain safe operations and provide failsafe operations of the plant during run-time. Virtual nodes that perform run-time, operational process control and/or related run-time functions (e.g., in conjunction with one or more physical devices or components disposed in the physical environment of the process plant) are referred to herein as “virtual run-time nodes.”

The MPDSC platform may additionally or alternatively support a simulation environment or space which may be utilized for control and/or safety system and/or component testing, validation, verification, and/or check out, operator training, case studies, on-going process improvements, etc. For simulation purposes, the MPDSC platform provides virtual nodes that simulate one or more physical devices, modules, or components that are deployable within the physical process environment. Virtual nodes that simulate various devices, modules, and/or components that are deployable in the physical environment of the process plant are referred to herein as “simulated nodes.”

The simulation provided by the MPDSC platform is “dynamic,” as simulations of the process plant or portions thereof may execute in real-time, thereby mirroring the timing and other behaviors that (would) occur during run-time, and/or simulations may be manipulated to execute at a faster or slower pace than real-time execution, to use different values, initial conditions, intermediate conditions, etc. The simulation space provides various features such as, for example, save/restore capabilities for various simulated scenarios, editable initial and/or intermediate conditions for various scenarios, coordination with third-party simulators via various protocols, testing and checkout of operator display views, real-time simulation of one or more portions of the PCS, speed-up and/or slow-down of the simulation of the one or more portions of the PCS, simulations that include simulated components operating in conjunction with actual (e.g., non-simulated) virtual and/or physical components, change management and synchronization with plant configuration, etc. The MPDSC platform is able to simultaneously support both simulation and run-time operations, various interactions and intersections between simulation and run-time operations (e.g., testing of upgrades, patches, “what-if” scenarios, configuration changes, user input changes, and the like. Further, with the MPDSC platform, system redundancy, fault tolerance, switchovers, planned maintenance, etc. are able to be seamlessly and easily accomplished.

One of the key components of the MPDSC architecture is referred to herein as an “I/O Switch” or an “I/O Server,” which generally abstracts I/O of the process plant away from being specifically and directly associated with particular hardware, as well as performs other functions related to I/O for simulation and/or run-time process control. The I/O Switch or I/O Server is a node that, during run-time, delivers I/O data between virtual and/or physical nodes of the process plant. Each node (whether virtual or physical) is typically a component of the process plant that is identified within the MPDSC system by a unique name, tag, or identifier. For example, a node may be a physical or virtual controller, a field device, a safety information controller, a safety logic solver, an I/O card or device (e.g., a wireless I/O device, an Ethernet I/O device, a marshalled I/O cabinet or components thereof, etc.), an operator workstation, another type of user interface device, a tool (e.g., diagnostic tool, simulation tool, etc.), a gateway, a data storage device, or other type of component. Generally speaking, the I/O Switch operates as a data broker between virtual and/or physical nodes, where the I/O Switch delivers or switches I/O data (also referred to interchangeably herein as “process I/O data,” or “PIO data”) between source nodes (whether virtual or physical) and destination nodes (whether virtual or physical). In a sense, rather than tightly and/or specifically coupling physical I/O cards to different source and destination nodes to deliver process I/O, the I/O Switch virtualizes the physical delivery mechanisms of process I/O data between nodes of the MPDSC system, and loosens the bindings between hardware components that are utilized for the purposes of delivering I/O data. Moreover, the I/O Switch is configured to be able to deliver I/O data quickly enough (e.g., with sufficiently small delay) to support run-time, actual production process control and/or real-time simulation of production process control.

Generally speaking, virtual and physical nodes/components that are serviced by the I/O Switch or I/O Server include respective modules that govern the behavior of virtual and physical nodes or components. Such modules are referred to herein as “component behavior modules” or “CBMs,” examples of which include control modules in controllers, safety logic in safety logic solvers, and other types of modules that govern the behavior and operations of the components in which the modules are stored and executed, and at least in part by operating on I/O data. Within the MPDSC system, CBMs that operate on the process-related payload of the I/O data are agnostic or unaware of the I/O Switch and its role in delivering I/O data to/from the component behavior modules. That is, the CBMs are unaware of whether or not their respective I/O delivery mechanism to/from their host node is a physical I/O card or the I/O Switch.

As such, the I/O Switch may be viewed as a switching fabric, router, and/or delivery mechanism of I/O data that is transparent to Component Behavior Modules of the MPDSC system. To this end, the I/O Switch delivers I/O data between virtual and/or physical nodes via respective publish/subscribe layers of the nodes (also referred to interchangeably herein as a “Pub/Sub layer”) and a virtual communication network via which I/O payload or data is transferred between nodes. For example, a sending or publishing node may include a respective Pub/Sub layer that publishes, to the virtual communication network, data generated by the component behavior module of the sending node. The I/O Switch may deliver or switch the published data to nodes that are receivers of or subscribers to the data, and each subscriber node may recover the data via its respective Pub/Sub layer for consumption by its respective component behavior module. As such, the I/O Switch brokers data between publisher nodes and subscriber nodes on a demand basis, in accordance with the defined relationships of the nodes within the MPDSC system.

As utilized herein, the “physical environment” of the MPDSC platform or system refers to the production plant or environment in which physical, tangible components (e.g., field devices, tanks, valves, actuators, heaters, evaporators, sensors, etc.) are utilized to transform, via run-time controlled processes, physical materials into physical products. Accordingly, the “physical environment” is interchangeably referred to herein as the “plant environment” of the industrial process plant. As discussed above, the physical or plant environment includes a front-end portion in which physical or hardware components of the MPDSC system such as field devices, sensors, transmitters, switches, positioners, tanks, heaters, etc. are disposed and operate on physical materials to produce physical products. As such, the “front-end” portion of the physical environment is interchangeably referred to herein as the “field” or “site” portion of the physical environment of the process plant.

The physical or plant environment of the MPDSC system also includes a back-end portion in which physical or hardware components such as operator workstations, personal computers or computing devices, data historians, report generators, centralized databases, and/or other centralized (or at least partly centralized) administrative computing devices execute applications to, for example, configure the process plant and/or its components, view and monitor run-time operations of the plant, respond to alerts or alarms during run-time operations of the plant, adjust parameters during run-time operations of the plant, generate reports, store and analyze data, and the like. The back-end portion of the physical environment of the MPDSC system may be located in areas that are protected from the harsher field environment, such as in an on-site, enclosed room and/or in locations that are off-site or remote from the field environment.

The virtual environment of the MPDSC system is implemented using physical or hardware computing devices that are particularly configured and interconnected to provide a platform that supports the virtualization of various physical process plant components, as is described in more detail in later sections of this disclosure. Generally speaking, the physical computing devices that provide and support the virtualization platform may be physically located on-site at the plant (e.g., in protected, enclosed areas of the field environment), may be physically located off-site, or may be physically and distributively located among various on-site and off-site locations. The physical computing devices that provide and support the virtualization platform may be interconnected via any number of physical data links and/or or communication/data networks. Generally speaking, the physical computing devices, data links, and communication/data networks form a computing platform on which various logical or virtual components of the MPDSC system reside, where the various logical or virtual components may be utilized for run-time process control in conjunction with components of the physical process environment, and/or for process simulation purposes.

The logical or virtual components residing in the virtual environment of the MPDSC system may operate to provide simulation of one or more actual or planned physical portions of the MPDSC system (e.g., in real-time, at faster speeds, and/or at slower speeds, if desired). In some implementations, the logical or virtual components residing in the virtual environment of the MPDSC system and the physical components residing in the physical environment of the MPDSC system may cooperatively operate to provide simulation and/or run-time, actual production process control. As such, in some embodiments, the physical and virtual environments of the MPDSC platform are communicatively connected via one or more communication links and/or networks, where the communication links and/or networks may include any number of wired links and/or networks, wireless links and/or networks, private links and/or networks, public links and/or networks. Embodiments of stand-alone, virtual real-time simulation and embodiments of cooperation between the logical/virtual and physical components of the industrial control system and communicative connections therebetween are described in more detail in later sections of this disclosure.

Further, the virtual and physical environments of the MPDSC platform utilize or share a common (e.g., the same) system configuration database, which is referred to herein as the “MPDSC system configuration database.” As such, via the MPDSC system configuration database, various virtual and physical components may be uniquely identified within the MPDSC platform across both virtual and physical environments, and intersections between simulation and run-time operations (e.g., testing, switchovers, etc.) are able to be seamlessly and easily accomplished.

In an embodiment, a system, such as a multi-purpose dynamic simulation and run-time industrial or process control (MPDSC) system, comprises a process control system that includes a field device, where the field device is disposed in a physical environment of an industrial process plant and performs a physical function. Additionally, the process control system includes an I/O switch communicatively disposed between the field device and a virtual node, where the virtual node is disposed in a virtual environment of the industrial process plant. The I/O switch is a subscriber to first data that is generated by the field device and that has been published, and the I/O switch is a publisher of second data indicative of the first data generated by the field device. The process control system further includes the virtual node, where the virtual node is a subscriber to the second data corresponding to the field device and published by the I/O switch. The virtual node includes a component behavior module that operates on the second data corresponding to the field device to thereby generate a control signal to modify a behavior of another node of the process control system. The field device, the virtual node, and the another node operate in conjunction during run-time operations of the industrial process plant to control an industrial process, for example.

In an embodiment, a method of controlling a node of a process control system of an industrial process plant includes communicatively connecting a field device and a virtual node via an I/O switch disposed between the field device and the virtual node so that the field device, the I/O switch, and the virtual node operate in conjunction during run-time operations of the industrial process plant to control an industrial process. The field device is disposed in a physical environment of the industrial process plant and performs a physical function. The I/O switch is a subscriber to first data that is generated by the field device and that has been published, and the I/O switch is a publisher of second data indicative of the first data generated by the field device. The virtual node is disposed in a virtual environment of the industrial process plant, and the virtual node is a subscriber to the second data corresponding to the field device and published by the I/O switch. During the run-time operations of the industrial process plant, the method includes receiving, by the virtual node, the second data corresponding to the field device and published by the I/O switch; operating on, by utilizing a component behavior module of the virtual node, the second data, thereby generating a control signal based on the second data; and causing an indication of the control signal to be transmitted to another node of the process control system, thereby modifying a behavior of the another node.

