Ease of Node Switchover within a Process Control System

Abstract

To provide simulation for actual process control by using virtualized elements.SOLUTION: Through a virtual node of a control system, a runtime behavior of physical elements which can be installed to a plant is reflected. The reflection includes a process for acquiring a first data published by an I / O by a virtual pair through subscription to publish a second data subscribed by the I / O. The reflection occurs while the I / O carries out, during its plant operation, controls processes by routing I / O data among run time nodes through subscription and publication. The run time node includes a controller and a device included in a control loop of the control system, and switches over the virtual pair to its execution as a virtual execution node of the control system operating in association with the I / O from execution as the virtual pair in order to carry out process control during the plant operation.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] Cross - Reference to Related Applications This application claims the benefit of priority and the filing date of U.S. Provisional Patent Application No. 62 / 859,508, filed on June 10, 2019, entitled "Industrial Control System Architecture for Real - Time Simulation and Control", the entire disclosure of which is hereby expressly incorporated by reference herein.

[0002] This patent application generally relates to industrial and process control systems, and more specifically, to industrial control systems that use virtualized components to provide process control and / or simulation of actual process control at runtime.

Background Art

[0003] Process or industrial control systems, such as those used in chemical, petroleum, or other industrial process plants that 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 wireless communication links or networks. For example, field devices, which can be valves, valve positioners, switches, and transmitters (e.g., temperature, pressure, level, and flow sensors), are located within the process environment and generally perform physical or process control functions, such as opening and closing valves and measuring process parameters, to control one or more processes being executed within the process plant or system. Smart field devices, such as field devices compliant with the well-known FOUNDATION™ fieldbus protocol, can also perform control calculations, alarm functions, and other control functions typically implemented within a controller. Process controllers, which can be centrally located but can also be located within the plant environment in a distributed fashion, receive signals that instruct process measurements performed by field devices and / or other information regarding the field devices, make, for example, process control decisions, generate control signals based on the received information, and execute controller applications that operate different control modules that cooperate with control modules or blocks implemented within field devices, such as HART™, WirelessHART™, and FOUNDATION™ fieldbus field devices. Control modules within the controller transmit control signals to the field devices via communication lines or links, thereby controlling the operation of at least a portion of the process plant or system.

[0004] Information from field devices and controllers is typically made available from the controller 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 managed computing devices that are typically located away from the control room or other locations with a more severe plant environment. Each of these hardware devices is typically centralized across a process plant or across a portion of a process plant. These hardware devices can perform functions related to the control of the process and / or the operation of the process plant, such as allowing an engineer to configure a portion of the process, or an operator to change the settings of process control routines, change the operation of control modules within the controller or field device, view the current state of the process, view alarms generated by the field device and controller, simulate the operation of the process for the purpose of training personnel or testing process control software, maintain and update the configuration database, etc. The data highway utilized by the hardware devices, controllers, and field devices can include a wired communication path, a wireless communication path, or a combination of wired and wireless communication paths.

[0005] As an example, the DeltaV™ control system sold by Emerson Process Management includes multiple applications stored within different devices located at various locations within a process plant and executed by those different devices. Configuration applications residing within one or more workstations or computing devices enable a user to create or modify process control modules and download these process control modules to dedicated distributed controllers via a data highway. Typically, these control modules are composed of communicatively interconnected function blocks that are objects within an object-oriented programming protocol that perform functions within a control scheme based on inputs thereto and provide outputs to other function blocks within the control scheme. Also, the configuration applications may enable a configuration designer to create or modify an operator interface used by a visualization application to display data to an operator and to enable the operator to change settings such as setpoints within a process control routine. Each dedicated controller, and in some cases one or more field devices, stores and executes a respective controller application that operates the control modules assigned and downloaded thereto to implement actual process control functions. The visualization application may execute on one or more operator workstations (or one or more remote computing devices communicatively connected to the operator workstations and the data highway), and this visualization application receives data from the controller applications via the data highway and uses the user interface to display this data to a process control system designer, operator, or user, providing any one of several different views such as an operator view, an engineer view, a technician 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 a data highway, while a configuration database application can operate on a further remote computer attached to the data highway to store the current process control routine configuration and associated data. Alternatively, the configuration database can be located within the same workstation as the configuration application.

[0006] The architectures of currently known process control plants and process control systems are strongly affected by the limited memory of controllers and devices, communication bandwidth, and the processor capabilities of controllers and devices. For example, in currently known process control system architectures, the use of dynamic and static non-volatile memory in controllers is typically minimized or at least carefully managed. As a result, during system configuration (e.g., a priori), the user or configuration engineer typically has to select which data within the controller should be archived or stored, how often it will be stored, and whether compression will be used, and thus the controller is configured with this limited set of data rules. Therefore, data that could be useful for troubleshooting and process analysis is often not archived, and when collected, useful information may be lost due to data compression.

[0007] Furthermore, in order to minimize the memory usage of a controller in currently known process control systems, data selected to be archived or stored (when directed by the controller's configuration) is reported to a silo workstation or computing device for storage in an appropriate data historian or data silo. Current techniques used to report data do not fully utilize communication resources and induce excessive controller load. Additionally, due to communication and sampling time delays in the historian or silo, data collection and timestamps are often not synchronized with the actual process.

[0008] Similarly, in a batch process control system, to minimize the memory usage of a controller, batch recipes and snapshots of the controller configuration typically remain stored at a centralized management computing device or location (such as a data silo or historian) and are transferred to the controller only when needed. Such a strategy results in significant burst loads on the controller and on the communication between the workstation or centralized management computing device and the controller.

[0009] Furthermore, the current architecture of industrial control systems such as process control systems is mainly hardware-driven in that various functions such as control functions, input / output (I / O) functions, user interface functions, etc. are implemented and associated with specific parts of the hardware (e.g., user workstations or interface devices, process controllers, safety system controllers, dedicated I / O devices, marshaled I / O devices, field devices, safety logic solvers, etc.) and always remain stored within specific hardware. For example, in current process control systems, the interconnection between a controller and an I / O device (e.g., either an individual I / O device or a bank of marshaled I / O devices) is configured based on specific hardware, and as a result, the physical I / O relationships are tightly coupled, most commonly in a one-to-one fashion, e.g., an I / O device is coupled to a controller, another I / O device is coupled to another controller, etc. This architecture design makes it difficult for these systems to change or reconfigure quickly, is tightly coupled to the specific hardware used to implement its own control software, requires hardware redundancy for device-based devices which can be expensive to implement, and is not easily extensible or upgradable without adding additional hardware that is required to be configured in a specific manner due to, for example, size limitations of individual devices such as physical process controllers, specific characteristics and capabilities of I / O devices, thus limiting the resilience, reliability, availability, responsiveness, and adaptability of the control system.

[0010] Some attempts to address these issues include virtualizing physical controllers. However, controller virtualization is limited to offline development and test systems and has not been widely used, even if it has been used for runtime process control in physical plants and / or production environments. Furthermore, both virtualized and physical controllers remain subject to the limitations of physical I / O devices such as performance, bandwidth, throughput, etc.

Summary of the Invention

[0011] A novel multi-purpose hardware / software architecture or platform for dynamic simulation and / or runtime production process control that enables an industrial or process control system of an industrial process plant to have better resilience, responsiveness, and adaptability compared to known industrial or process control systems. More specifically, this novel architecture or platform generally decouples the hardware used in a control system from the software that controls the behavior of the hardware, making it easier to scale, reconfigure, and change the system, while improving the overall system's reliability, availability, and performance. For ease of discussion, the novel multi-purpose dynamic simulation and runtime control platform or architecture is referred to interchangeably herein as "MPDSC", "MPDSC platform", "MPDSC system", or "MPDSC architecture".

[0012] Generally speaking, MPDSC includes a virtual process environment linked to a physical process environment, and the components of the virtual and physical environments cooperate to perform dynamic simulation of industrial processes and / or runtime (e.g., actual or operable) production process control. For runtime process control, the MPDSC platform supports a process control system (PCS) that 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 the runtime of the plant. In some configurations, the MPDSC platform also supports a safety instrumented system (SIS) that may have both virtual and physical components that cooperate to maintain the safe operation of the plant and provide fail-safe operation of the plant during runtime. Virtual nodes that perform runtime, operable process control, and / or related runtime functions (e.g., in cooperation with one or more physical devices or components disposed within the physical environment of a process plant) are referred to herein as "virtual runtime nodes".

[0013] The MPDSC platform may additionally or alternatively support a simulation environment or space that can be used for testing, validating, verifying, and / or inspecting control and / or safety systems and / or components, operator training, case studies, improvement of ongoing processes, etc. For the purpose of simulation, the MPDSC platform provides virtual nodes that simulate one or more physical devices, modules, or components that can be deployed within a physical process environment. Virtual nodes that simulate various devices, modules, and / or components that can be deployed within the physical environment of a process plant are referred to herein as "simulated nodes".

[0014] The simulations provided by the MPDSC platform are "dynamic" because the simulation of a process plant or a part thereof is executed in real time, thereby reflecting the timing and other behaviors that occur (will occur) during runtime, and / or because the simulation can be operated to execute at a pace faster or slower than real-time execution in order to use various values, initial conditions, intermediate conditions, etc. The simulation space provides various features such as, for example, the ability to save / restore various simulated scenarios, editable initial conditions and / or intermediate conditions for various scenarios, coordination with third-party simulators via various protocols, testing and inspection of the operator display view, real-time simulation of one or more parts of the PCS, speeding up and / or slowing down the simulation of one or more parts of the PCS, simulation of simulated components that operate in conjunction with actual (e.g., non-simulated) virtual and / or physical components, change management and synchronization with the plant configuration, etc. The MPDSC platform can support both simulation and runtime operation, as well as various interactions and common parts between simulation and runtime operation (e.g., testing of upgrades, patches, "what-if" scenarios, configuration changes, user input changes, etc.). Furthermore, according to the MPDSC platform, system redundancy, fault tolerance, switchover, planned maintenance, etc. can be achieved seamlessly and easily.

[0015] One of the main components of the MPDSC architecture is what is referred to herein as an "I / O switch" or "I / O server", which generally abstracts the I / O of a process plant away from being specifically and directly associated with particular hardware and performs other functions related to I / O for simulation and / or runtime process control. The I / O switch or I / O server is a node that distributes I / O data among the virtual and / or physical nodes of a process plant during runtime. Each node (either virtual or physical) is typically a component of a process plant identified by a unique name, tag, or identifier within the MPDSC system. For example, a node can 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 marshaled I / O cabinet or its components, etc.), an operator workstation, another type of user interface device, a tool (e.g., a diagnostic tool, a simulation tool, etc.), a gateway, a data storage device, or another type of component. Generally speaking, the I / O switch operates as a data broker between virtual and / or physical nodes that distributes or switches I / O data (also referred to herein interchangeably as "process I / O data" or "PIO data") between a source node (either virtual or physical) and a destination node (either virtual or physical). In a sense, rather than rigidly and / or specifically connecting physical I / O cards to different source and destination nodes to distribute process I / O data, the I / O switch virtualizes the physical distribution mechanism of process I / O data among the nodes of the MPDSC system and loosens the coupling between the hardware components utilized for the purpose of distributing I / O data. Further, the I / O switch is configured to be able to distribute I / O data quickly enough (e.g., with a sufficiently small delay) to support the actual production process control at runtime and / or the real-time simulation of the production process control.

[0016] Generally speaking, the virtual and physical nodes / components served by an I / O switch or an I / O server include respective modules that control the behavior of the virtual and physical nodes or components. Such modules are referred to herein as "component behavior modules" or "CBMs", examples of which include the control module of a controller, the safety logic of a safety logic solver, and other types of modules that control the behavior and operation of the components in which the modules are stored and executed by operating, at least in part, on I / O data. In an MPDSC system, a CBM that operates on the process-related payload of I / O data is agnostic or unaware of its role in delivering I / O data to / from the I / O switch and the component behavior operation module. That is, the CBM does not recognize whether each I / O delivery mechanism of the CBM to / from the CBM's host node is a physical I / O card or an I / O switch.

[0017] Therefore, the I / O switch can be regarded as a switching fabric, router, and / or distribution mechanism for I / O data that is transparent to the component behavior modules of the MPDSC system. For this reason, the I / O switch distributes I / O data between virtual and / or physical nodes via each publisher / subscriber layer (also interchangeably referred to herein as the "Pub / Sub layer") of the nodes and the virtual communication network through which the I / O payload or data is transferred between nodes. For example, a transmitting or publishing node may include a respective Pub / Sub layer that publishes data generated by the component behavior module of the transmitting node to the virtual communication network. The I / O switch can deliver or switch the published data to a node that is the recipient or subscriber of the data, and each subscriber node can retrieve the data via its respective Pub / Sub layer for consumption by its respective component behavior module. Thus, the I / O switch mediates data on demand between the publisher node and the subscriber node according to the defined relationships of the nodes within the MPDSC system.

[0018] As used herein, the "physical environment" of the MPDSC platform or system refers to a production plant or environment in which physical tangible components (e.g., field devices, tanks, valves, actuators, heaters, evaporators, sensors, etc.) are utilized to convert physical materials into physical goods via a runtime-controlled process. Thus, the "physical environment" is interchangeably referred to herein as the "plant environment" of the industrial process plant. As discussed above, the physical environment or plant environment includes the front-end portion where 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. Thus, 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.

[0019] The physical or plant environment of the MPDSC system also includes 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 partially centralized) managed computing devices that execute applications to, for example, configure process plants and / or their components, display and monitor the runtime operation of the plant, respond to warnings or alarms during the runtime operation of the plant, adjust parameters during the runtime operation of the plant, generate reports, store and analyze data, etc. The backend portion of the physical environment of the MPDSC system may be located in an area protected from the harsher field environment, such as on-site, in a sealed room, and / or a location remote from or far from the field environment.

[0020] The virtual environment of the MPDSC system is implemented using physical or hardware computing devices that are specifically configured and interconnected to provide a platform that supports the virtualization of various physical process plant components, as will be described in more detail in a later section of this disclosure. Generally speaking, the physical computing devices that provide and support the virtualization platform can be physically located at the plant site (e.g., within a protected and sealed area of the field environment), can be physically located away from the site, or can be physically and dispersedly located at various locations at the site and away from the site. The physical computing devices that provide and support the virtualization platform can be interconnected via any number of physical data links and / or communication / data networks. Generally speaking, the physical computing devices, data links, and communication / data networks form a computing platform in which various logical or virtual components of the MPDSC system exist, and the various logical or virtual components can be utilized in combination with the components of the physical process environment for runtime process control or for process simulation purposes.

[0021] The logical or virtual components that exist within the virtual environment of the MPDSC system can operate (e.g., in real-time, at high speed, and / or at low speed as needed) to provide a simulation of one or more actual or planned physical parts of the MPDSC system. In some embodiments, the logical or virtual components that exist within the virtual environment of the MPDSC system, and the physical components that exist within the physical environment of the MPDSC system, can operate in cooperation to provide simulation and / or runtime actual production process control. Thus, in some embodiments, the physical and virtual environments of the MPDSC platform are communicatively connected via one or more communication links and / or networks, and the communication links and / or networks can 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 simulations, as well as embodiments of the cooperation between the logical / virtual and physical components of an industrial control system and the communication connections therebetween, are described in more detail in later sections of this disclosure.

[0022] 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." Thus, via the MPDSC system configuration database, various virtual and physical components can be uniquely identified within the MPDSC platform across both the virtual and physical environments, and common aspects between simulation and runtime operation (e.g., testing, switchover, etc.) can be achieved seamlessly and easily.

[0023] In one embodiment, a method for switching over nodes of a process control system of an industrial process during runtime includes simulating the runtime behavior of at least a portion of the physical components of the process control system of the industrial process plant via virtual nodes disposed within a virtual environment of the industrial process plant, where the physical components are deployable within the physical environment of the industrial process plant and the virtual nodes are the simulated nodes. Simulating at least a portion of the physical components includes obtaining first data published by an I / O switch that communicatively connects the virtual environment and the physical environment of the industrial process plant by the simulated nodes via a subscription, operating on the obtained first data by the simulated nodes, and publishing second data subscribed to by the I / O switch by the simulated nodes based on the operation. The obtaining, operating, and publishing by the simulated nodes occur while the I / O switch is operating to control the industrial process by routing I / O data between runtime nodes via subscriptions and publications during the runtime operation of the process control system. Additionally, the method includes activating the simulated nodes as virtual runtime nodes of the process control system that operate in cooperation with the I / O switch to control at least a portion of the industrial process during the runtime operation of the process control system.

[0024] In one embodiment, a system for switching over nodes of a process control system of an industrial process plant during runtime operation includes an I / O switch, a virtual node, and a virtualization management node. The I / O switch is included within the process control system. The I / O switch communicatively connects the virtual environment of the industrial process plant to the physical environment of the industrial process plant. The I / O switch operates during the runtime operation of the process control system to control the industrial process by routing I / O data between runtime nodes via subscriptions and publications. The virtual node is disposed within the virtual environment of the industrial process plant and simulates the runtime behavior of at least a portion of the physical components that can be deployed within the physical environment of the industrial process plant. Thus, the virtual node is a simulated node. The simulation of the runtime behavior of at least a portion of the physical components by the simulated node includes obtaining third data published by the I / O switch by the simulated node via a corresponding subscription, and generating fourth data subscribed to by the I / O switch by the simulated node based on the third data. Upon approval corresponding to the simulated node, the virtualization management node activates the simulated node as a virtual runtime node of the process control system that operates in cooperation with the I / O switch to control at least a portion of the industrial process during the runtime operation of the process control system.

Brief Description of the Drawings

[0025]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Best Mode for Carrying Out the Invention

[0026] FIG. 1 is a block diagram of an exemplary multi-purpose dynamic simulation and runtime industrial or process control (MPDSC) system or platform 10 that provides dynamic simulation of an industrial or process plant and / or runtime process control. The exemplary MPDSC platform 10 supports dynamic simulation of process control of an industrial process plant and / or real-time process control using virtualized devices. For example, the virtualized devices can be utilized by the MPDSC platform 10 for physical production purposes during runtime of the process plant. As shown in FIG. 1, the MPDSC platform 10 includes a virtual plant environment portion 12 and a physical plant environment portion 15, although in embodiments where the MPDSC platform 10 is utilized for real-time simulation purposes only, the physical plant environment portion 15 can be omitted. Generally speaking, the virtual plant environment portion 12 and the physical plant environment portion 15 collectively form one or more operational technology (OT) layers 18 of an industrial process plant, which can provide the generated data to one or more information technology (IT) layers 20 associated with the industrial process plant and / or, for example, to a network external to the IT layer for enterprise and / or external use by one or more applications 21a - 21n, 22a - 22m. For example, applications 21a - 21m can be provided by an enterprise that owns / operates the MPDSC platform 10 and can be implemented in the IT layer associated with the enterprise, and applications 22a - 22m can be Internet of Things (IoT) and / or Industrial Internet of Things (IIoT) applications provided by respective third parties that execute on a remote network accessible via the Internet or other public network.

[0027] The enterprise's IT layer 20 can be implemented on any number of locally and / or remotely deployed computing devices, such as one or more local and / or remote server banks, one or more computing clouds, and can include any number of applications or consumers 21a - 21n of data generated by the enterprise's OT layer 18. Typically (but not necessarily), as shown in FIG. 1, the OT layer 18 is communicatively coupled to the IT layer 20 via one or more public and / or private communication networks 24 and one or more edge gateway systems 28, and the edge gateway system 28 provides security and efficiency for data delivery between the OT layer 18 / MPDSC platform 10 and the IT layer 20. Further, one or more edge gateway systems 28 can provide security and efficiency for data delivery between the MPDSC platform 10 and external networks and / or external applications 22.

[0028] In FIG. 1, the virtual plant environment 12 of the MPDSC platform 10 includes one or more virtual nodes (VN) 30a, 30b, 30c - 30p communicatively connected to an I / O switch (interchangeably referred to herein as an "I / O server") 25. Generally speaking, each virtual node 30x is a virtual machine that simulates or virtualizes the behavior of each physical component that can operate within the physical plant environment 15. In other words, each virtual node 30x within the virtual plant environment 12 processes and behaves in the same manner as its physical counterpart within the physical plant environment 15 processes and behaves with respect to data.

[0029] In particular, each virtual node 30x includes a framework and one or more subsystems 32 that enable the VN30x to communicate with other virtual nodes 30x within the virtual plant environment 12 and / or one or more physical nodes (PNs) within the physical plant environment 15 such as physical nodes 40a, 40b, 40c and edge gateway system 28 (the edge gateway 28 can be regarded as a specific type of PN). Each of the physical nodes includes a framework and respective one or more subsystems 42x that enable communication with the virtual node 30x. Additionally, the MPDSC platform 10 may include any number of other physical nodes or components (e.g., PNa - PNk).

[0030] A virtual node can virtualize various types of physical nodes. Generally speaking, when used in this specification, a "physical node" includes hardware and is a physical device or component of the MPDSC platform 10 that transmits and / or receives data to / from other devices or components (virtual or physical). Examples of the types of physical nodes that can be represented by each virtual node include, but are not limited to, various types of process control controllers, various types of local and / or remote I / O devices or cards (such as wireless I / O cards (WIOCs), Ethernet I / O cards (EIOCs)), as well as various components of an I / O electronic marshalling system (characterization modules (CHARM), terminal blocks, CHARM I / O cards (CIOCs), etc.), various types of safety instrumented system (SIS) nodes such as safety controllers, safety logic solvers, SIS repeaters, safety network bridges, safety network gateways, local and / or remote physical operator workstations, mobile devices, and / or user interface devices that provide a user interface for other purposes related to runtime operation and / or the MPDSC platform 10, local and / or remote physical computing devices that provide tools related to the MPDSC platform 10 such as control configuration tools, data integration and visualization tools, data analysis and analysis configuration tools, display view configuration tools, diagnostic tools, asset management tools, application stations, etc., and various types of gateways within and / or utilized by the MPDSC platform 10 such as wireless gateways, safety gateways, firewalls, edge gateways, field gateways, system - to - system gateways, and other types of physical nodes that can be utilized within the physical plant environment 15.

[0031] In some embodiments, a single VN30x may represent or virtualize an entire physical node. In some embodiments, a single VN30x may represent or virtualize one or more portions of a particular physical node. For example, a single VN30x may represent or virtualize a particular module or group of modules that execute or reside on a particular PN, and such modules may include software modules or components, firmware module components, and / or hardware modules or components. For example, a first VN may represent or virtualize an entire application (such as an entire control module executable on a physical process controller) executing on a particular PN, a second VN may represent or virtualize a subset of an entire application executing on a particular PN (such as a particular control model, function, or routine utilized by a particular control module), a third VN may represent or virtualize the behavior of a protocol-specific I / O card or device associated with a particular PN, and / or a fourth VN may represent or virtualize PN sub-components of a similar granularity to the hardware sub-components of a particular PN (such as ports or other interfaces, buses, transceivers, chips, boards, etc.) or the firmware or software sub-components of a particular PN (such as modules, routines, functions or behaviors, network addresses of a particular PN such as MAC (Media Access Control) addresses or other types of addresses, etc.).

[0032] Examples of types of physical I / O cards that may be utilized within the physical plant environment 15 and that may be represented and / or virtualized by the virtual nodes 30x of the MPDSC 10 include, but are not limited to, discrete output cards, including high density, intrinsically safe, and redundant discrete output cards, and discrete input cards, including high density, intrinsically safe, and redundant discrete input cards, and Analog input cards, including an analog input card that supports the HART (registered trademark) (Highway Addressable Remote Transducer) communication protocol, a redundant analog input card that supports HART, a high-density redundant analog input card that supports HART, and a high-speed analog input card, and Analog output cards, including an analog output card that supports the HART communication protocol, a redundant analog output card that supports HART, a high-density redundant analog output card that supports HART, and a high-speed analog output card, and Serial cards, including redundant, programmable, and redundant programmable serial cards, and Interface cards for discrete actuators and / or sensors that support fieldbus communication protocols, RTD (Resistance Temperature Detector) cards, thermocouple cards, millivolt cards, isolated temperature cards, multifunction cards, a series of event cards, redundant fieldbus support cards that support the Profibus communication protocol, redundant Profibus support cards, and other types of physical cards.

[0033] As illustrated in FIG. 1, VN30a, 30b, 30c - 30p communicate with each other and with the I / O switch 25 via their respective publication / subscription layers 32a, 32b, 32c - 32p and 35. The publication / subscription layers are interchangeably referred to herein as the "Pub / Sub layers" and are shown in FIG. 1 by the respective hashed portions 32x, 35 of each VN30x and the I / O switch 25. In an embodiment of the MPDSC platform 10 that includes physical nodes as illustrated in FIG. 1, at least some of the PN28, 40a, 40b, 40c disposed within the physical plant environment 15 may include their respective Pub / Sub layers 38, 42a, 42b, 42c. In a sense, the Pub / Sub layers 32x, 35 (and, in some configurations, the Pub / Sub layers 38, 42x) function as a virtual communication network 45 through which various virtual nodes 30x and I / O switch 25 (and, in some configurations, physical nodes 40x) can communicate abstracted I / O data. In an exemplary embodiment, each Pub / Sub layer 32x, 35, 38, 42x is a respective interface to the virtual communication network 45.

[0034] The virtual communication network 45 may include wired and / or wireless networks and may be implemented by one or more physical communications and / or data links and / or networks using any suitable technology such as Ethernet, optical, IP, or other packet networks of another type. Data is communicated between nodes via the virtual communication network 45 via publications and subscriptions, and any or more suitable communication protocols that support publications and subscriptions may be utilized within the virtual communication network 45 for the delivery of data. For example, private packet protocols, and / or public or standardized packet protocols (such as IPv6, IoT, and / or IIoT protocols) may be utilized by publishers and subscribers of I / O data that is delivered between various nodes 30x, 28, 40x of the virtual communication network 45 and, optionally, to other applications 21x, 22x, for example, by the edge gateway system 28.

[0035] For example, each node of the virtual communication network 45 (e.g., virtual node 30x, I / O switch 25, physical node 28, 40x, etc.) can publish I / O data to the virtual communication network 45 via its respective Pub / Sub layer (e.g., via Pub / Sub layers 32x, 35, 38, 42x, etc.), and each node of the virtual communication network 45 (e.g., virtual node 30x, I / O switch 25, physical node 28, 40x, etc.) can subscribe to and obtain the I / O data published to the virtual communication network 45 via its respective Pub / Sub layer (e.g., via Pub / Sub layers 32x, 35, 38, 42x, etc.). Typically, subscriptions to various published data have a one-to-one correspondence between the I / O switch 25 and each of the other nodes 30x, 28, 40x. In a preferred embodiment, each node 30x, 28, 40x of the virtual communication network 45 accepts subscriptions only from the I / O switch 25 and not from other nodes, and each node 30x, 28, 40x subscribes only to the I / O data published by the I / O switch 25 (the I / O data published by the I / O switch 25 can be data generated by other nodes and transferred after being subscribed to by the I / O switch 25) and does not subscribe to the I / O data published by other nodes. Thus, in this preferred one-to-one embodiment, the undirected graph of the publication / subscription relationship is restricted compared to embodiments that allow a node to have multiple subscriptions by multiple other nodes, thereby reducing network complexity, simplifying network diagnosis and management, and reducing network load / usage. To further reduce network complexity, simplify network diagnosis and management, and reduce network load / usage, additionally or alternatively, each node 30x, 28, 40x of the virtual communication network 45 can send to the I / O switch 25 via publication only the data that will be transferred by the I / O switch 25 to other nodes of the MPDSC platform 10.Of course, in some embodiments, at least a portion of the undirected graph may be implemented in a one-to-many, many-to-one, and / or many-to-many relationship, as needed.

[0036] Generally speaking, within the MPDSC platform 10, process-related payload data (e.g., generated by CBM and / or physical components of the process plant) is abstracted, published as I / O data, and can be delivered to subscriber nodes of the virtual communication network 45 upon request. That is, the I / O data can be delivered (e.g., via publication) when the publish node determines that the process-related data payload requires a new publish event. For example, the publish node can automatically publish a particular type of sensor-generated data as I / O data to the virtual communication network when the sensor-generated data value changes. Optionally, the publish node can also publish the sensor-generated data value periodically (e.g., every 5 seconds, every 10 seconds, every minute, etc.) as I / O data even when the sensor-generated data value has not changed, e.g., thereby reducing lost messages and other fidelity issues that may occur. Thus, in some embodiments, an explicit subscription ratio is not required and / or is not utilized by subscriber nodes. As a result, the execution of processing logic (e.g., the component behavior module) at each subscriber node is subscribed to and driven by incoming data received via the virtual communication network 45, and thus the resources utilized by each node and the virtual communication network 45 can be utilized more efficiently.

[0037] In one example of an exemplary scenario, VN30a may generate, as I / O data during runtime, a specific process-related payload dataset, e.g., “Data1”, and publish it to its Pub / Sub layer 32a. The I / O switch or server 25 may have a subscription to the I / O data including Data1 and may obtain the process-related payload Data1 via the virtual communication network 45, its respective Pub / Sub layer 35, and its respective subscription. Next, the I / O switch or server 25 may publish the obtained process-related payload Data1 as I / O data via the virtual communication network 45, its Pub / Sub layer 35, for reception by those nodes having a subscription to the I / O data including Data1. For example, VN30b may have a subscription to the I / O data including Data1, and upon publication of Data1 as I / O data via the Pub / Sub layer 35 of the I / O switch 25, VN30b may obtain the process-related payload Data1 via the virtual communication network 45, its respective Pub / Sub layer 32b, and its subscription to the I / O data. Subsequently, VN30b may operate on the obtained process-related payload Data1 value.

[0038] Accordingly, the MPDSC platform 10 is utilized for the distribution between virtual and physical nodes via the I / O switch 25 and between virtual communication networks 45 via publication and subscription for various physical components of an industrial process plant (e.g., discrete outputs, discrete inputs, analog outputs, analog inputs, serial I / O, rail bus, HART, Wireless HART, field bus, Profibus, Ethernet, advanced physical layer, and / or any other type of I / O) and abstracts a plurality of different types of I / O derived therefrom. Each node of the virtual communication network 45 may perform the respective abstraction and de-abstraction (e.g., recovery) of the I / O data that it transmits and receives via its respective Pub / Sub layer and, optionally, other subsystems.

[0039] Virtual Node To illustrate I / O abstraction and de-abstraction, FIG. 2 illustrates two exemplary architectural embodiments 52a, 52b of virtual node 30x. Generally speaking, virtual node 30x simulates and / or virtualizes a physical node or physical component that can be utilized and operate within physical plant environment 15. Each VN 52a, 52b includes respective Pub / Sub layers 55a, 55b through which the VNs 52a, 52b communicate with I / O switch 25. Additionally, each VN 52a, 52b includes respective component behavior modules 58a, 58b, interchangeably referred to herein as "component business logic modules" 58a, 58b or "CBM" 58a, 58b. Generally speaking, CBM 58x is a module whose execution controls the operating behavior of its respective virtual node 30x, for example, at the application level. For example, the CBM 58x of a virtual controller node can be a particular instance of a control module, and other instances of the control module can be downloaded to a physical controller disposed within physical plant environment 15 for execution during runtime of physical plant 15. In another example, the CBM 58x of a virtual CIOC node can be a particular instance of a remote I / O module, and other instances of the remote I / O module can be executed at a physical CIOC disposed therein during runtime of physical plant environment 15.

[0040] Since the CBM58x can be executed within a physical component, the CBM typically communicates natively with one or more corresponding proprietary I / O types, such as analog input / output, fieldbus, railbus, etc. Further, the CBM58x typically has no awareness of whether they are running on virtual nodes 30x in the virtual plant environment 12, physical nodes 40x disposed within the physical plant environment 15, or another physical component disposed within the physical plant environment 15, e.g., on nodes PNa to PNk. Thus, regardless of whether the CBM58x is running within the virtual plant environment 12 or within the physical plant environment 15, the CBM58x transmits and receives data using the same processing logic and I / O types in the same manner.

[0041] In an embodiment of the virtual node 52a, the process-related payload data transmitted and received by the CBM58a is abstracted for delivery to / from the VN52a via the virtual process I / O (PIO) subsystem 60. Generally speaking, the virtual PIO subsystem 60 simulates the native physical PIO delivery of the virtual node 52a. That is, during the runtime of the virtual node 52a, the virtual PIO subsystem 60 communicates I / O process values and events to / from the CBM58a using its native I / O, as if the I / O process values and events originated from / were delivered to the physical hardware. Thus, the virtual PIO subsystem 60 can be adjusted according to the specific type of the virtual node 52a, and the virtual node type is controlled by its CBM58a. For example, if the VN52a represents a physical controller that communicates with other devices using railbus I / O, the virtual PIO subsystem 60 provides I / O data to / from the CBM58a of the control routine in the form utilized by the railbus I / O card. If the VN52a represents a CIOC, the virtual PIO subsystem 60 provides I / O data to / from the CBM58a of the remote I / O in the form utilized by CHARM.

[0042] Furthermore, the virtual PIO subsystem 60 can handle data publication and subscription on behalf of the virtual node 52a. That is, the virtual PIO subsystem 60 can publish the data generated by the CBM 58a to the Pub / Sub layer 55a, and the virtual PIO subsystem 60 can subscribe to the data generated by other nodes (and transferred by the I / O switch 25) via the Pub / Sub layer 55a. In one embodiment, the subscription to and publication of data can be based on tags or other identifiers that are unique within the MPDSC platform 10. The tags or other identifiers can uniquely identify, for example, the data, nodes, devices, or components of the MPDSC platform 10. In one embodiment, the tags and / or identifiers can be assigned during configuration and / or commissioning.

[0043] Accordingly, within each virtual node 52a in the virtual environment 12, the virtual PIO subsystem 60 maintains a logical separation between the CBM 58a and the corresponding physical I / O, similar to the logical separation maintained within the physical environment 15 in each physical node having the on-board CBM 58a and its corresponding physical I / O (e.g., via a physical I / O card or a marshaled I / O configuration) (e.g., via the Pub / Sub layer 55a, the virtual communication network 45, and the other Pub / Sub layers 32, 35, 38, 42). Generally speaking, the virtual PIO subsystem 60 of any virtual node 30 maintains a logical separation between the I / O subscribers (such as the CBM 58a, another module, another type of I / O consumer, etc.) included in the virtual node 30 and its corresponding physical I / O.

[0044] In the embodiment of the virtual node 52b shown in FIG. 2, the virtual PIO subsystem 60 is omitted or not utilized. Typically, the type of virtual node that utilizes the VN architecture 52b is a node where the physical components and technologies in which the virtual communication network 45 is implemented and the CBM 58b can communicate natively. For example, when the virtual communication network 45 is implemented via the IP protocol over Ethernet, the virtual node 52b that simulates the EIOC includes a CBM 58b that is natively configured to communicate using the IP protocol over Ethernet. As a result, the EIOC virtual node 52b may not include (or may turn off or ignore the operation of) the virtual PIO subsystem 60, and the EIOC virtual node 52b can handle the delivery of data to / from the virtual node 52b by using only the CBM 58b and the Pub / Sub layer 55b.

[0045] Physical node FIG. 3 is a block diagram of an exemplary physical plant environment 100 that can operate in conjunction with the MPDSC platform 10 of FIG. 1. For example, the physical environment portion 15 of the MPDSC platform 10 illustrated in FIG. 1 may include at least a portion of the physical plant environment 100.

[0046] The physical plant 100 controls an industrial process (or, in some embodiments, operates in conjunction with a virtual plant environment, such as the virtual plant environment 12, to control the industrial process), and the industrial process can be said to have one or more "process outputs" (e.g., tank level, flow rate, material temperature, etc.) that characterize the state of the process, and one or more "process inputs" (e.g., various environmental conditions and the state of actuators, operations that can change the process output). The physical process plant 100 of FIG. 3 includes a field environment 102 and a backend environment 105, each of which is communicatively connected to each other by a process control backbone or data highway 108, and may include one or more wired and / or wireless communication links and / or networks, and may be implemented using any desired or suitable communication protocol, such as Ethernet protocol, IP protocol, or another packet protocol.

[0047] At a high level (and as shown in FIG. 3), the field environment 102 includes physical components (e.g., process control devices, networks, network elements, etc.) that are grounded and interconnected to operate to control the industrial process during runtime. Generally, these physical components are located, disposed, or otherwise included within the field environment 102 of the physical process plant 100, and raw materials are received and processed using the physical components disposed therein, thereby generating one or more physical products (e.g., paper, refined oil, drugs, etc.). In contrast, the backend environment 105 of the physical process plant 100 includes various physical components such as computing devices, operator workstations, databases or data banks that are shielded and / or protected from the harsh conditions and materials of the field environment 102. In some configurations, the various computing devices, databases, and other components and equipment included within the backend environment 105 of the physical process plant 100 may be physically located at different physical locations, some of which may be local to the physical plant 100 and some of which may be remote.

[0048] As shown in FIG. 3, the field environment 102 includes one or more process controllers 110 communicatively connected to a data highway 108. Each of the process controllers 110 may be connected to one or more intermediate nodes 112, 115 (e.g., I / O cards, I / O devices, I / O systems, etc.) that facilitate communication between the controller 110 and field devices. Generally speaking, in the process control industry, the term "I / O" may be used in several related but different contexts. This term generally refers to a logical link or communication channel (e.g., an "I / O channel") that communicatively couples a field device to an I / O card or controller, but may also be used to refer to several other concepts, such as a physical device utilized to transmit signals to or receive signals from a field device via an I / O channel (e.g., an "I / O device" or an "I / O card") and connectors or terminals associated with the I / O device (e.g., an "I / O connector"). The I / O devices and I / O cards 112, 115 may be stand-alone individual physical devices, each of which is connected to its respective controller and one or more respective field devices, as illustrated in FIG. 3. In some configurations (not shown in FIG. 3), the I / O devices, cards, connectors, and terminal blocks, module processors, and other I / O-related components are included within an I / O electronic marshalling system that enables flexible I / O distribution between multiple controllers and multiple field devices of various types, as described in U.S. Pat. Nos. 7,684,875, 8,332,567, 8,762,618, 8,977,851, 9,083,548, 9,411,769, 9,495,313, and 9,946,240, the entire contents of each of which are hereby expressly incorporated by reference.Accordingly, for purposes of clarification of the discussion, as used herein, the term "I / O device" generally refers to physical I / O devices, cards, electronic marshalling systems, and their components, through which an I / O channel is implemented to communicatively couple field devices and controllers thereby.

[0049] Also, in the process control industry, the term "I / O" may generally be used to refer to signals transmitted on an I / O channel (e.g., "I / O signals"), variables or commands represented by the signals (e.g., "I / O parameters"), or values of variables or commands carried by the signals (e.g., "I / O parameter values" or "I / O data payloads"). Accordingly, for purposes of clarification of the discussion, as used herein, I / O signals, I / O parameters, and I / O parameter values are collectively and generically referred to herein as "I / O data" or "process I / O data".

[0050] As long as the term "I / O" is referenced herein without a modifier, the context should make clear which of these concepts is being considered. Further, it should be understood that an "I / O channel" represents a particular type of "communication channel" or "channel". That is, unless the context otherwise suggests, referring to the term "channel" or the term "communication channel" without the "I / O" modifier in this description may, in some embodiments, refer to a communication link that may be an I / O channel, but in some embodiments may also refer to a communication link other than an I / O channel.

[0051] In any case, when returning to FIG. 3, each process controller 110 of the physical process plant 100 implements a control strategy defined by one or more control routines (e.g., one or more component behavior modules) that can be stored in the memory of the controller 110. When the processor of the controller executes one or more of the control routines, the controller transmits a control signal (i.e., a "control output") to other field devices in the plant 100 to control the operation of the processes therein via a wired or wireless process control communication link or network. The controller can generate a control signal based on (i) one or more received signals that can be referred to as "control inputs" (e.g., one or more received signals representing measurements obtained by field devices), and (ii) the logic of one or more control routines that can be defined by one or more software elements (e.g., function blocks). Typically, the controller manipulates process inputs (which can be referred to as "manipulated variables") to vary a particular process output (which can be referred to as a "controlled variable" or simply a "process variable") based on feedback (i.e., measurements of the controlled variable) and desired values of the process output (i.e., setpoints).

[0052] Generally, at least one field device performs a physical function (e.g., opening or closing a valve, increasing or decreasing a temperature, obtaining a measurement, detecting a condition, etc.) to control the operation of the processes implemented in the process plant 100. Some types of field devices communicate with the controller using I / O devices. The process controller, field devices, and I / O devices can be wired or wireless, and any number and combination of wired and wireless process controllers, field devices, and I / O devices can be included within the process plant environment or platform 100.

[0053] The front - end environment 102 of the plant 100 For example, FIG. 3 illustrates a process controller 110 that is communicatively connected to wired field devices 125-132 via input / output (I / O) devices 112 and 115 and is communicatively connected to wireless field devices 140-146 via a wireless gateway 168 and a data highway 108. In some configurations (not shown), the controller 110 can be communicatively connected to the wireless gateway 168 using one or more communication protocols, such as Wi-Fi or other IEEE 802.11-compliant wireless local area network protocols, mobile communication protocols (e.g., WiMAX, LTE, or other ITU-R compatible protocols), Bluetooth®, HART®, WirelessHART®, Profibus, FOUNDATION® Fieldbus, etc., by using any number of other wired or wireless communication links other than the backbone 108.

[0054] As an example, a controller 110, which may be a DeltaV™ controller sold by Emerson Process Management, may operate to implement a batch industrial process or a continuous industrial process using at least some of field devices 125 - 132 and 140 - 146. In one embodiment, in addition to being communicatively coupled to process control data highway 108, controller 110 may also be communicatively coupled to at least some of field devices 125 - 132 and 140 - 146 using any desired hardware and software associated with, for example, standard 4 - 20 mA devices, I / O cards 112, 115, and / or any smart communication protocol such as FOUNDATION™ fieldbus protocol, HART™ protocol, WirelessHART™ protocol. In FIG. 3, controller 110, field devices 125 - 132, and I / O devices 112, 115 are wired devices and field devices 140 - 146 are wireless field devices. Of course, wired field devices 125 - 132 and wireless field devices 140 - 146 can be adapted to any other desired standard(s) or protocol, for example any wired or wireless protocol including any standard or protocol developed in the future.

[0055] The process controller 110 of FIG. 3 includes a processor 120 that implements or oversees one or more process control routines 118 (e.g., stored in the memory 122 of the controller 110). The processor 120 is configured to communicate with the field devices 125 - 132 and 140 - 146, as well as with other nodes communicatively coupled to the controller 110. Note that any control routine or module described herein may, if so desired, have a portion thereof implemented or executed by a different controller or other device. Similarly, the control routines or modules 118 described herein that are to be implemented within the process control plant 100 can take any form, including software, firmware, hardware, etc. The control routines can be implemented in any desired software form, such as using object - oriented programming, ladder logic, sequential function charts, function block diagrams, or any other software programming language or design paradigm. The control routines 118 can be stored in any desired type of memory 122, such as random access memory (RAM) or read - only memory (ROM). Similarly, the control routines 118 can be hard - coded, for example, in one or more EPROMs, EEPROMs, application - specific integrated circuits (ASICs), or any other hardware or firmware element. Thus, the controller 110 can be configured to implement control strategies or control routines in any desired manner.

[0056] The controller 110 implements control strategies using what are generally referred to as function blocks, each of which is an object or other part (e.g., a subroutine) of the overall control routine and operates in cooperation with other function blocks (via a communication called a link) to implement a process control loop within the MPDSC platform 10. Control-based function blocks typically implement one of (i) an input function (sometimes called an "input block") such as one associated with a transmitter, sensor, or other process parameter measurement device, (ii) a control function (sometimes called a "control block") such as one associated with a control routine implementing PID, fuzzy logic, etc., or (iii) an output function (sometimes called an "output block") that controls the operation of some device such as a valve to implement some physical function within the process control plant 100. Of course, there are hybrid and other types of function blocks.

[0057] The function blocks may be stored and thereby executed within the controller 110, which is typically the case when these function blocks are used or associated with some types of smart field devices such as standard 4 - 20 mA devices and HART® devices, or the function blocks may be stored and thereby implemented within the field device itself, which can be the case for FOUNDATION® Fieldbus devices. One or more of the control routines 118 may implement one or more control loops by executing one or more of the function blocks. In a sense, the control routines 118 may be regarded as the component behavior modules of the controller 110.

[0058] The wired field devices 125 - 132 can be any type of device such as sensors, valves, transmitters, positioners, etc., while the I / O cards 112 and 115 can be any type of process control I / O device that conforms to any desired communication or controller protocol. For example, the I / O devices 112, 115 can be included in an I / O electronic marshalling system. In FIG. 3, the field devices 125 - 128 are standard 4 - 20 mA devices or HART (registered trademark) devices that communicate with the I / O card 112 via an analog line or a combined analog and digital line, while the field devices 129 - 132 are smart devices such as FOUNDATION (registered trademark) fieldbus field devices that communicate with the I / O device 115 via a digital bus using the FOUNDATION (registered trademark) fieldbus communication protocol. However, in some embodiments, at least some of the wired field devices 125, 126, and 128 - 131, and / or at least some of the I / O devices 112, 115 communicate with the controller 110 additionally or alternatively using the process control data highway 108 and / or by using other suitable control system protocols (e.g., Profibus, DeviceNet, Foundation Fieldbus, ControlNet, Modbus, HART, etc.). In some configurations (not shown in FIG. 3), at least some of the field devices 125 - 132 can communicate with the controller 110 via an electronic I / O marshalling system instead of via the individual I / O devices 112, 115.

[0059] In FIG. 3, wireless field devices 140 - 146 communicate via a wireless process control communication network 165 using a wireless protocol such as the WirelessHART® protocol. Such wireless field devices 140 - 146 can communicate directly with one or more other devices or nodes of a wireless network 165 that are also configured to wirelessly communicate (e.g., using the wireless protocol or another wireless protocol). To communicate with one or more other nodes that are not configured to wirelessly communicate, wireless field devices 140 - 146 can utilize a wireless gateway 168 connected to the process control data highway 108 or to another process control communication network. The wireless gateway 168 provides access to the various wireless devices 140 - 158 of the wireless communication network 165. Specifically, the wireless gateway 168 provides a communication link between wireless devices 140 - 158, wired devices 125 - 132, and / or other nodes or devices of the physical process control plant 100. For example, the wireless gateway 168 can provide a communicable link by using the process control data highway 108 and / or by using one or more other communication networks of the physical process plant 100.

[0060] Similar to the wired field devices 125 - 132, the wireless field devices 140 - 146 of the wireless network 165 perform physical control functions within the physical process control plant 100, such as opening and closing valves or acquiring measured values of process parameters. However, the wireless field devices 140 - 146 are configured to communicate using the wireless protocol of the network 165. Thus, the wireless field devices 140 - 146, the wireless gateway 168, and the other wireless nodes 152 - 158 of the wireless network 165 are both producers and consumers of wireless communication packets.

[0061] In some configurations of the process plant 100, the wireless network 165 includes non-wireless devices. For example, in FIG. 3, the field device 148 of FIG. 3 is a legacy 4-20 mA device, and the field device 150 is a wired HART® device. To communicate within the network 165, the field devices 148 and 150 are connected to the wireless communication network 165 via wireless adapters 152a, 152b. The wireless adapters 152a, 152b support a wireless protocol such as WirelessHART and may also support one or more other communication protocols such as Foundation® Fieldbus, PROFIBUS, DeviceNet. Additionally, in some configurations, the wireless network 165 can be an independent physical device that communicates with a wired gateway 168 or can be provided within the wireless gateway 168 as an integrated device and includes one or more network access points 155a, 155b. Also, the wireless network 165 can also include one or more routers 58 for forwarding packets from one wireless device in the wireless communication network 165 to another. In FIG. 3, the wireless devices 140-146 and 152-158 communicate with each other and with the wireless gateway 168 via the wireless links 160 of the wireless communication network 165 and / or via the process control data highway 108.

[0062] The back-end environment 105 of the plant 100 As described, the backend environment 105 can include various components such as computing devices, operator workstations, databases or databanks, etc., which are typically shielded and / or protected from the harsh conditions and materials of the field environment 102. For example, the backend environment 105 can include (i) one or more operator workstations 170a and other local or remote user interface devices 170b, (ii) one or more configuration applications 172a and configuration databases 172b, (iii) one or more other types of applications 175a and / or databases 175b that can include, for example, tools, diagnostics, asset management systems, simulators, and / or other types of applications, (iv) one or more other wireless access points 178 that communicate with other devices (e.g., user interface devices 170b or other devices) associated with the plant 100 using various wireless protocols, (v) one or more plant gateway systems 180 to other plants, (vi) one or more edge gateway systems 182 to a system 185 (e.g., a corporate IT network / system and / or an external data network / system that can be implemented on cloud computing and / or other suitable platforms) outside the direct OT layer of the physical process control platform 100, and / or (vii) any one or more of other physical components that are dedicatedly configured via hardware and software to support the process plant 100, each of which can be communicatively connected to the data highway 108.

[0063] Operator workstations and user interface devices 170a, 170b Operator workstations 170a and other user interface devices 172b can be utilized by an operator to visually observe and monitor the runtime operation of the physical process plant 100 and to take any diagnostic, corrective, maintenance, and / or other measures that may be required. At least some of the operator workstations 172a may be located within various protected areas within or near the plant 100, and in some situations, at least some of the operator workstations 172b may be located remotely but still in a connection state that enables communication with the plant 10. The operator workstations 172a, 172b can be wired or wireless computing devices.

[0064] Configuration applications 172a and configuration databases 172b Configuration application 172a and configuration database 172b can be utilized to configure specific aspects of plant 100, such as control modules / routines, user interfaces, data monitoring / analysis, etc. For example, various instances of configuration application 172a enable a user to create or modify process control modules, download these modules to controller 110 via data highway 108, create or modify an operator interface, and via the operator interface, an operator can view data, change data settings within process control routines, and create or modify data monitoring / analysis routines and functions, etc. that can be downloaded to various physical components within field environment 102. Configuration database 172b stores the created (e.g., configured) modules, operator interfaces, data monitoring / analysis, etc. Generally, configuration application 172a and configuration database 172b are centralized and have an integrated logical appearance, but multiple instances of configuration application 172a can be executed simultaneously within physical process control platform 100, and configuration database 172b can be implemented across multiple physical data storage devices. Thus, configuration application 172a, configuration database 172b, and a user interface (not shown) therefor include a configuration or development system 172 for various types of modules, such as control modules, display or operator interface modules, and / or analysis modules. Typically, although not essential, the user interface for configuration system 172 is utilized by configuration and development engineers regardless of whether plant 100 is operating in production mode, whereas operator workstation / user interface device 170 is different in that it is utilized by an operator during the runtime operation of physical process plant 100.

[0065] Regarding the commissioning of the physical configuration of the MPDSC platform 100, the configuration database 172b can store data and other information that specifically identifies and / or addresses various physical devices or components and their interconnections that are planned or desired to be implemented on the process plant floor or field environment 102. Some of this commissioning data can be provided to components within the field environment 102 for use in commissioning the devices and loops therein, and some of this data can be utilized in the backend environment 105 for the design, development, and preparation of control modules, pelleter interface modules, and / or analysis modules that will operate in conjunction with the field environment 102 during the live operation of the physical process plant 100. In one example, an approved control module is downloaded from the configuration database 172b to the process controller 110, such that when executed during live operation, the process controller 110 operates according to its resident control module to send and receive various signals to / from other components within its loop (and, in some cases, to / from other process controllers), thereby controlling at least a portion of the process within the physical process plant 100.

[0066] Configuration database 172b may store some logical identifiers of components within field environment 102, enabling controller 110 and other devices to reference components and signals associated with the components by the logical identifiers. For example, for a given field device, configuration database 172b may store information that maps or associates a logical identifier to a specific hardware address or I / O channel. The hardware address may identify a specific controller, a specific I / O device connected to the specific controller, and / or a specific address for an I / O channel that connects the specific I / O device to the field device. In some cases, this mapping or association may be stored in controller 110, user interface device 170b, operator workstation 170a, or any other desired device (e.g., any device that needs to resolve logical identifiers). After the logical identifier is associated with a hardware address or I / O channel, the identifier is considered "assigned." In some cases, plant 100 may include "unassigned" logical identifiers, which are identifiers that software elements (e.g., control routines and / or function blocks) reference but do not have an association. That is, a logical identifier is considered "unassigned" when plant 100 and configuration database 172b do not have a hardware address or I / O channel that is associated with the tag. Thus, when an unassigned logical identifier is referenced by a control routine, the value carried by the signal within plant 100 will not be read, and commands will not be sent through the field devices within plant 100.

[0067] Examples of such logical identifiers include a device tag (DT), each representing a particular instrument, controller, valve, or other physical field device, and a device signal tag (DST), each representing a particular signal typically corresponding to a particular parameter received or generated by a particular device and utilized by a field device. For some devices, the device signal tag includes a combination of the device's device tag and an identifier of a particular signal received or generated by that device, e.g., an identifier of a particular parameter referenced by a control module. For some devices, typically legacy or dam devices, the device tag represents both the physical device and the signal generated by the device. Generally speaking, the logical identifier of a device is used by the physical process plant 100 in both the field environment 102 and the backend environment 105 to uniquely identify the device. The DT and DST may be referred to as "system tags" or "system identifiers".

[0068] In some cases, the smart field devices 129-132 may also store a logical identifier unique to the smart field devices 129-132. These logical identifiers may be separate from the system tags utilized by the plant 100 to identify the field devices 129-132 and may be referred to as "source identifiers" or "source tags". Depending on the implementation, the source tags may or may not be stored in the configuration database 172b.

[0069] The configuration database 172b may store data and other information that specifically identifies and / or addresses various virtual devices or components (e.g., various virtual nodes 30) that are planned or desired to be implemented in the virtual plant environment 12. Similar to physical devices and components, the configuration database 172 may store the respective logical identifiers of the components of the virtual environment 12, thereby enabling other devices and / or components (regardless of whether they are physical or virtual) to reference the virtual components. For example, similar to the physical node 40x, various virtual nodes 30x may be uniquely identified within the MPDSC platform 10 (e.g., across both the virtual environment 12 and the physical environment 15) via their respective device tags (DTs), device signal tags (DSTs), source tags, and / or other types of unique identifiers. Further sections of this disclosure will consider the configuration and identification of virtual devices and components in more detail.

[0070] Other applications 175a and databases 175b Other applications 175a and databases 175b may include instances of applications specific to the process plant 100, such as diagnostic applications / databases, data historian applications / databases, system-level health monitoring applications / databases, local and / or remote user interfaces, etc. Generally speaking, other applications 175a and databases 175b may include one or more applications executed on the OT layer 18 of the process plant 100 and their associated databases. Additionally or alternatively, other applications 175a and databases 175b may include one or more applications executed in the IT layer 20 associated with the process plant 100, such as inventory management applications, personnel management applications, supply chain management applications, other types of enterprise-related applications, weather / environment applications, etc., and their associated databases. For example, other applications 175a and databases 175b may include applications 21a - 21n and their associated databases. Further additionally or alternatively, other applications 175a and databases 175b may include one or more applications executed outside and / or remotely from the process plant 100 and / or its enterprise, such as simulation applications, analysis applications, IoT applications, IIoT applications, etc., and their associated databases. For example, other applications 175a and databases 175b may include applications 22a - 22m and their associated databases. Other applications 175a and databases 175b may include third-party applications and / or applications provided by an enterprise associated with the process plant 100. At least some of other applications 175a and databases 175b may be accessed via the edge gateway system 28 and / or some other types of security and / or firewall systems.

[0071] Wireless access point 178 One or more other wireless access points 178 enable devices within the backend environment 105 (and, optionally, within the field environment 102) to communicate with other devices using a wireless protocol such as Wi-Fi or other IEEE 802.11 compliant wireless local area network protocol, a mobile communication protocol such as WiMAX (Worldwide Interoperability for Microwave Access), LTE (Long Term Evolution) or other ITU-R (International Telecommunication Union Radio Communication Sector) compatibility protocol, a short-range wireless communication such as Near Field Communication (NFC) and Bluetooth, or other wireless communication protocol. Typically, such a wireless access point 178 enables a handheld or other portable computing device (e.g., user interface device 170b), which may be different from the wireless network 165, to communicate via its respective wireless process control communication network that supports a wireless protocol different from the wireless network 165. For example, the wireless or portable user interface device 170b can be a mobile workstation or diagnostic test equipment (e.g., one instance of the operator workstations 170a) utilized by an operator within the physical process plant 100. In some scenarios, in addition to the portable computing device, one or more process control devices (e.g., controller 110, field devices 125 - 132, or wireless devices 168, 140 - 158) also communicate using the wireless protocol supported by the access point 174.

[0072] Gateway systems 180, 182 The gateway nodes or systems 180 and 182 can interface with a system external to the direct physical process control plant 100. Typically, such a system is a consumer or provider of information generated or operated by the physical process plant 100. For example, the process control plant 100 can include a plant gateway node 180 for communicably connecting the direct physical process control plant 100 to another process plant. Additionally or alternatively, the process control plant 100 can include an edge gateway node or system 182 for communicably connecting the direct physical process control plant 100 to an external public or private system such as a research institute system (e.g., a research institute information management system or LIMS), an operator round database, a data integration and visualization system, a data analysis system, a materials handling system, an asset management system, a maintenance management system, a product inventory control system, a production scheduling system, a weather data system, a shipping and handling system, a packaging system, the Internet, an IoT application, an IIoT application, or other external systems.

[0073] Generally speaking, the edge gateway system 182 enables communication to be securely delivered between the process plant 100 and other networks 185. In an exemplary architecture, the edge gateway system 182 includes an internal or plant-facing engine (which may be referred to as a "field gateway") and an external or outward-facing engine (which may be referred to as an "edge gateway"), and the plant-facing engine and the external-facing engine cooperate to securely deliver process plant data (e.g., data generated by the OT layer) to external networks and / or applications (e.g., the IT layer, as well as / or external networks and / or systems), which are consumers of the plant data. In one of many embodiments, the plant-facing engine collects data generated by various components of the process plant 100 and securely transmits the collected data to the external-facing engine via one or more secure communication links, e.g., via a first publication set. The external-facing engine subscribes to various publications generated by the plant-facing engine and obtains the collected plant data therefrom. Next, the external-facing engine securely transmits the obtained plant data to one or more external client applications (e.g., applications 21a - 21n, 22a - 22m) within the network 185, e.g., via a second publication set. The publications and subscriptions at the plant-facing engine and / or the external-facing engine can each be configured as needed. However, typically, the publication / subscription, encryption, and / or other secure data delivery mechanisms utilized between the plant-facing engine and the external-facing engine are different from the publication / subscription, encryption, and / or other secure data delivery mechanisms utilized between the external-facing engine and the external applications.In some embodiments, for additional safety, the edge gateway system 182 includes a one-way data diode disposed between the plant-facing engine and the outside-facing engine to prevent data from flowing from the external network 185 to the process plant 100. Examples of edge gateway systems can be found in U.S. Patent Publications Nos. 2018 / 0115516, 2018 / 0115528, 2018 / 0115517, and 2018 / 0113442, the entire disclosures of which are incorporated herein by reference. Of course, other edge gateway systems can be additionally or alternatively utilized by the process plant 100.

[0074] FIG. 3 illustrates only a single process controller 110, a wireless gateway 168, a wireless adapter 152, an access point 155, a router 158, and a wireless process control communication network 165 that includes a finite number of field devices 125 - 132 and 140 - 146 included within an exemplary process plant 100, but it should be noted that this is merely an exemplary and non-limiting embodiment. Any number of controllers 110 can be included within the process control plant or platform 100, and any one of the controllers 110 can communicate with any number of wired or wireless devices and networks 125 - 132, 140 - 146, 168, 152, 155, 158, and 165 to control processes within the plant 100.

[0075] Here, referring to FIGS. 1 and 3 together with respect to the physical nodes, each of the physical nodes 40a to 40c and PNa to PNk shown in FIG. 1 can be one of the physical components or devices considered with respect to the process control plant 100 of FIG. 3. For example, PN40b can be a process controller that has its respective Pub / Sub layer 42b and is communicatively connected to the field device PNh via the I / O card PNg. In another example, PN40c can be a CIOC (having its respective Pub / Sub layer 42c) to which six different field devices PNa to PNf are communicatively connected, or PN40c can be a wireless access point 178 or an EIOC (having its respective Pub / Sub layer 40c) to which various other physical components PNa to PNf without a Pub / Sub layer are communicatively connected. In yet another example, PN40a can be an I / O marshalling device or an I / O hub device that distributes process I / O data via its Pub / Sub layer 42a instead of a plurality of other PNs without Pub / Sub, for example, PNi to PNk. The I / O marshalling or hub device 40a can be a stand-alone device or can be included within another physical component disposed within the physical plant environment 15, such as within the controller 110, I / O devices 112, 115 (e.g., CIOC, ECOC, WIOC, etc.), access point 178, gateways 180, 182. Further, in some embodiments, the edge gateway system 28 and its Pub / Sub layer 38 can be physical nodes (not shown in FIG. 1) that are communicatively connected to various physical components (e.g., PN40a to 40c and PNa to PNk) of the physical plant environment 15 in a manner as considered with respect to FIG. 3, for example.

[0076] I / O switch As described above, the I / O switch 25 shown in FIG. 1 functions as a data broker, switching fabric, or router for processing I / O data between nodes of the virtual communication network 45. That is, the I / O switch 25 transfers the I / O data generated by the publish node to the nodes subscribing to the data, instead of the publish node. Generally speaking, the I / O switch 25 can maintain (and update) a record regarding which node publishes which I / O data and which node subscribes to which published I / O data. In one embodiment, the I / O data can be identified within the record by a unique identifier, name, or tag that is unique across the MPDSC platform 10, or by respective indications thereto. The unique identifier can identify, for example, the I / O data and / or the process-related payload data included in its publish node. In one embodiment, the unique identifier, name, or tag is assigned during configuration and / or commissioning. The I / O switch 25 utilizes the stored record to route the incoming published data to the subscribers of the published data. For example, the I / O switch 25 can subscribe to I / O data published by various nodes 28, 30x, 40x, and when the I / O switch 25 receives the published I / O data via its subscription, the I / O switch 25 can publish the received I / O data to the selected subscriber nodes 28, 30x, 40x according to the stored record. Typically, but not necessarily, the I / O switch 25 does not maintain, record, or store I / O data and / or process-related payload data published by other nodes of the virtual communication network 45.

[0077] Importantly, the I / O switch 25 is configured to switch or transfer the received process I / O data with minimal latency. In fact, in the prototype, the I / O switch 25 was able to transfer the received process I / O data through the I / O switch 25 at time intervals measured in hundreds of microseconds, such as less than 500 microseconds, less than 200 microseconds, and less than 100 microseconds, depending on the load.

[0078] Generally speaking, the I / O switch 25 can be implemented via hardware, firmware, and / or software. In one example, the I / O switch 25 is implemented using one or more physical hardware devices on which dedicated software is installed to provide at least some of the I / O switch 25 functions described herein, i.e., the I / O switch 25 can be implemented as an appliance. In another example, the I / O switch 25 is implemented as software (e.g., a program, routine, application, etc.) that can be installed on and executed by a server or a bank of computing devices to provide at least some of the I / O switch 25 functions described herein. In yet another example, the I / O switch 25 is implemented via virtualization, such as a virtual machine, a container (e.g., Docker, LXD, etc.), or another type of virtualized implementation.

[0079] The Pub / Sub layer 35 of the I / O switch 25 generally has the same configuration and functionality as the Pub / Sub layers 32x, 38, 42x, 55x described elsewhere within the present disclosure. However, the Pub / Sub layer 35 of the I / O switch 25 is further configured to receive and maintain subscription requests for various identified process I / O data. As discussed above, subscriptions are recorded and thereby maintained in, for example, one or more tangible non-transitory memories within the I / O switch 25. Further, the Pub / Sub layer 35 of the I / O switch 25 is configured to transfer published process I / O data to subscribed nodes that may include other I / O switches.

[0080] For purposes of illustration, FIG. 4 illustrates an exemplary configuration 200 of a plurality of I / O switches 202, 205, 208, 210 that may be included in the MPDSC platform 10 of FIG. 1. In one example, each I / O switch 202, 205, 208, 210 includes its own Pub / Sub layer (as indicated by their respective hashed portions) and has a respective architecture similar to that of the I / O switch 25. Also similar to the I / O switch 25, each I / O switch 202, 205, 208, 210 is associated with and interconnected via a virtual communication network 225 to respective sets of VNs and / or PNs 212a - 212n, 215a - 215m, 218a - 218p, and 220a - 220q, between which each I / O switch 202, 205, 208, 210 transfers process I / O data via publish and subscribe in the manner described above. Configuration 200 includes four I / O switches 202, 205, 208, 210, but the concepts discussed herein with respect to configuration 200 are readily applicable to more or fewer I / O switches interconnected in a mesh topology.

[0081] In FIG. 4, each of the I / O switches 202, 205, 208, 210 can further transfer process I / O data to each of the other I / O switches 202, 205, 208, 210 via the virtual communication network 225. By interconnecting the plurality of I / O switches 202, 205, 208, 210, the number of virtual nodes and / or physical nodes served can be expanded to support a larger system 10 and provide additional distribution bandwidth. In configuration 200, each of the I / O switches 202, 205, 208, 210 can publish data to the other I / O switches 202, 205, 208, 210 instead of their respective VN / PN sets. Similarly, each of the I / O switches 202, 205, 208, 210 can subscribe to data transferred by the other I / O switches 202, 205, 208, 210 instead of their respective VN / PN sets 212a~212n, 215a~215m, 218a-218p, 220a-220q.

[0082] Configuration 200 is illustrated with each of the I / O switches 202, 205, 208, 210 being directly linked to each of the other I / O switches 202, 205, 208, 210. That is, the virtual communication network 225 has a fully interconnected or mesh topology. Thus, in an embodiment of this configuration 200, the maximum transmission delay from a publisher node to a subscriber node is limited because the maximum number of hops that a particular process I / O data payload can undergo is 3. In other embodiments of configuration 200, the maximum number of hops can be different. For example, the maximum number of hops can increase when time-series capabilities such as time-series networking or other suitable time-series capabilities are utilized, for example, to monitor traffic. The maximum number of hops within configuration 200 can be configured and changed as needed.

[0083] Of course, other interconnected topologies (e.g., hub and spoke, star, ring, tree, hybrid, etc.) may be possible in addition to or instead of the mesh topology of the virtual communication network 225. Generally speaking, a publish for processing I / O data published by a specific publish node, e.g., node 215a, is performed on and managed by its corresponding I / O switch, e.g., I / O switch 205. However, if the I / O switch 205 does not have a record for the specific data for which a subscription is requested, the I / O switch 205 may forward the subscription request to other I / O switches 202, 208, 210. A specific I / O switch corresponding to the node publishing the requested data, e.g., I / O switch 210 corresponding to the publish node 220q, will have the requested data and the record corresponding to its publish node 220q, and will respond to the I / O switch 205 corresponding to the requesting node 215a, whereupon the I / O switch 105 may create and store the corresponding record for the requested data. In this way, a cross - route for the requested data from the publish node 220q to the subscribe node 215a via the I / O switches 210, 205 may be established.

[0084] In one embodiment, the configuration 200 may be implemented across multiple MPDSC systems 10. For example, the I / O switch 202 may be included in a first MPDSC system, and the I / O switch 205 may be included in a different MPDSC system. Thus, different MPDSC systems may publish and / or subscribe to each other's process I / O data via one or more links of the virtual communication network 225.

[0085] Real - time virtual control and related operations As described above, the virtual node 30x can virtualize the behavior of various physical components that are operable within the physical plant environment 15. Further, due to the functionality of the MPDSC platform 10, the virtualized components 30x of the virtual plant environment 12 operate in conjunction with the physical components of the physical plant environment 15 to perform real-time control of the industrial process plant during runtime, thereby generating physical products from raw materials. For purposes of illustration, simultaneously referring to FIGS. 1, 2, and 3, the process controller 110 can be virtualized as a virtual node 30a having an architecture 52a. Thus, instead of the physical process controller 110 executing its corresponding control module or routine 118 during runtime, the virtual node 110 / 30a includes the control module or routine 118 as its CBM 58a, executes the corresponding control module or routine 118 during runtime, and can include transmitting and receiving signals to / from various field devices disposed within the physical environment 15 via the I / O switch 25.

[0086] For example, during the runtime of the industrial process plant 100, the virtual controller 110 / 30a may receive data generated by the field device 129 via the physical I / O device 115. In this example, the physical I / O device 115 is represented by the physical node PNg in FIG. 1, the field device 129 is represented by the physical node PNh in FIG. 1, and the physical node 40b is an I / O hub device. The data payload generated by the field device PNh is delivered via the I / O device PNg to the I / O hub device 40b which is a node of the virtual communication network 45. The I / O hub device 40b may publish to the I / O switch 25 the data payload generated by the field device PNh and published by the I / O hub device 40b for which the I / O switch 25 has a subscription. Next, the I / O switch 25 may publish the payload data generated by the field device PNh to the virtual controller 110 / 30a, after which the CBM 58a (e.g., control module / routine 118) of the virtual controller 110 / 30a may operate on the payload data generated by the field device PNh. The CBM 58a may generate output payload data that will be delivered to another virtual node or physical node via the virtual communication network 45.

[0087] In another example, during the runtime of the industrial process plant 100, the virtual controller 110 / 30a may receive data generated by the wireless field device 142a. In this example, the physical wireless field device 142a is represented by the physical node PNa in FIG. 1, and the physical wireless gateway 168 is represented by PN40c. The wireless gateway PN40c receives the payload data generated by the wireless field device PNa. Since PN40c is a node of the virtual communication network 45, PN40c publishes the payload data generated by the wireless field device PNa to the I / O switch 25 that has a subscription to the wireless field device PNa. Next, the I / O switch 25 may publish the payload data generated by the field device PNa to the virtual node 30b, which is configured as a representation of an I / O device such as the I / O device 115. The virtual I / O device 30b subscribes to the payload data generated by the field device PNa and transferred by the I / O switch 25. Thus, the virtual I / O device 30b obtains the payload data generated by the wireless field device PNa via its subscription and republishes the obtained payload data generated by the field device PNa to the I / O switch 25 for transfer to the appropriate subscribers. The I / O switch 25 may then publish the obtained payload data of the field device PNa published by the virtual I / O device 30b to its respective subscribers, including (in this example) the virtual controller 30a. Upon receiving the payload data at the virtual controller 30a via the subscription of the virtual controller 30a to the payload data, the CBM58a (e.g., the control module / routine 118) of the virtual controller 30a may operate on the payload data generated by the wireless field device PNa. The CBM58a may generate output payload data that will be distributed to another virtual node or physical node via the virtual communication network 45.

[0088] The virtualization of the physical components of an industrial process plant offers more advantages than an industrial process plant implemented entirely using physical components. The virtualized components enable the industrial process plant to flexibly expand and / or contract in size and number of components with minimal changes to the hardware area and reduced installation costs. Since a virtual node can represent an entire physical device or only a part thereof, control can be easily scaled, for example, across the required number of virtual nodes. Additionally, the MPDSC platform 10 provides I / O flexibility, for example, via I / O abstraction, such that the controller has a low dependency on the assignment of the I / O modules actually configured and downloaded. That is, at least due to the I / O switch 25, the I / O coupling determination between the physical I / O device and the controller and field devices can be eliminated. Further, by using virtual physical components, software upgrades to the virtualized physical components are easily achieved. Still further, by using the MPDSC platform 10, simulation and online testing of the behavior of physical components are also easily achieved and improved over currently known techniques.

[0089] Virtualization management node FIG. 5 is a block diagram illustrating an exemplary architecture that supports the configuration, commissioning, management, and operation of the MPDSC system 10 of FIG. 1. For purposes of clarity and not limitation, FIG. 5 is considered herein with reference to FIGS. 1-4 simultaneously. As shown in FIG. 5, a virtualization management node 300 (referred to interchangeably herein as "VMN300" or "virtual node 300") creates, configures, and manages the virtualized components of the MPDSC system 10, such as the I / O switch 25, various virtual nodes 30x, the virtual PIO subsystem 60, and the publish / subscribe layers 32x, 35, 38, 42x. The VMN300 automatically performs at least some of the creation, configuration, and management of the virtual components. Additionally or alternatively, the VMN300 performs at least some of the creation, configuration, and management of the virtual components based on manual instructions received via a user interface 302 of the VMN300, which can be a local or remote user interface. Further, the virtualization management node 300 drives and / or coordinates the simulation activities of the virtual process environment 12, which can be performed with and / or without in-line user input during the simulation, as described in more detail below.

[0090] Configuration, Operation, and Management of Virtual Components In one embodiment, during the configuration and / or commissioning of the virtual environment 12 and its components, the VMN 300 accesses the plant's system configuration database (e.g., the VMN 300 accesses the configuration database 172b of the plant 100 via the data highway 108), and based on the obtained configuration, the VMN 300 determines the type and number of virtual nodes, virtual templates and / or subsystems, I / O switches, and / or other virtual components that best support (or are desired to support) the plant configuration. The VMN 300 creates various types and numbers of virtual nodes 30x, and configures the I / O switches 25 and the virtual nodes 30x to communicate via the virtual communication network 45, e.g., via their respective publish / subscribe layers 32x, and for some VN 30x, via the virtual PIO subsystem 60. For some plant configurations, the VMN 300 may create instances of the publish / subscribe layer 42x (and optionally, instances of the virtual PIO subsystem 60) and distribute them to various physical components 40x of the physical plant environment 15. Thus, the VMN 300 can create, configure, and operate any number of nodes 25, 28, 30x, 40x of the virtual communication network 45, which may include virtual components that operate in cooperation with the physical components of the physical plant to perform real-time control and / or dynamic simulation.

[0091] The configuration of the virtual communication network 45 and its nodes 25, 28, 30x, 40x can be stored in the system configuration database 172b and / or locally stored in the virtual environment configuration database 305. In some embodiments, the master version of the configuration of the virtual plant environment 12 is stored in the system configuration database 172b (along with the configuration of the physical plant environment 15), and a copy of the master configuration of the virtual plant environment 12 is locally stored in the virtual environment configuration database 305. In some embodiments, the master version of the configuration of the virtual plant environment 12 is stored in the virtual environment configuration database 305, and a copy of the master configuration of the virtual plant environment 12 is stored in the system configuration database 172b (along with the configuration of the physical plant environment 15). The VMN 300 coordinates the change management and synchronization of the data stored in the virtual environment configuration database 305 and the related data stored in the system configuration database 172b.

[0092] While the plant 100 is performing runtime process control during the runtime of the process plant 100, the VMN 300 monitors the I / O switch 25, the virtual nodes 30x, the virtual communication network 45, and any related nodes (such as the physical nodes 40x, 28, etc.) with respect to other performance issues of the hardware and / or software resources provided by, for example, a physical computing platform that supports the resource loading, resource availability, resource bandwidth, occurrence of failures, and the virtual environment 12, such as a platform of hardware computing devices that support the virtual environment 12. Based on the detected and / or predicted conditions, the VMN 300 can automatically perform mitigation measures during runtime operation, such as adjusting resource allocation, activating standby virtual nodes, creating and / or deleting virtual nodes, etc., for load balancing, fault recovery, and other performance purposes. As an example, the VMN 300 can analyze the performance bottleneck and perform an automatic leveling operation to mitigate any detected bottleneck. For example, the VMN 300 can perform automatic leveling at the process data level in response to the amount of virtual network traffic on the virtual communication network 45, and / or the VMN 300 can perform automatic leveling at the physical computing device level such that the CPU and / or physical network utilization is distributed across the computing devices, physical data links, and / or physical networks on which the virtual environment 12 is implemented.

[0093] Operationally, the VMN300 can perform storage, snapshot, backup, migration, restoration, etc. of various virtual nodes, virtual templates and subsystems, as well as related process data. The VMN300 can perform overall storage, snapshot, backup, and migration of the virtual environment 12 itself. In one embodiment, each operation measure performed by the VMN300 can be applied to the entire logic simulated by the target virtual node (e.g., the entire logic performed by the collective CBM set 58 of the target virtual node). For example, when acquiring and saving a snapshot of a virtual controller, the VMN300 not only saves the virtual controller and the data received, generated by, and indicating its interconnections and operating states, but also the related data of the modules executed in cooperation with the virtual controller, even if such modules are hosted on other nodes and / or simulate other physical components, can be saved as part of the snapshot. In another example, when acquiring and saving a snapshot of a virtual CIOC, the VMN300 can save the data corresponding to the virtual machine level of the virtual CIOC, and / or the VMN300 can save the process simulation values observed by the virtual CIOC.

[0094] Dynamic simulation As described above, the MPDSC system 10 supports dynamic simulation of the entire process plant 100 and / or a portion thereof. For example, the MPDSC system 10 provides real-time simulation, which reflects the runtime timing, values, and / or other behaviors of at least a portion of the corresponding physical components and / or physical operation processes. As used herein, the terms "simulation" and "simulation execution" are used interchangeably, and the simulation or simulation execution is finite. That is, each simulation or simulation execution has its respective start and its respective end, which can be defined as needed, for example, based on time, parameter values, states, user commands, and / or other criteria.

[0095] In addition, the MPDSC system 10 provides operations for simulation, such as accelerating or decelerating the pace of simulation execution, pausing the simulation, inserting and / or changing various values, and changing initial conditions. The simulation can be executed entirely within the virtual environment 12 of the MPDSC system 10 and / or the simulation can be executed using one or more virtual or simulated components in cooperation with one or more physical components (for example, the configuration of a controller simulated by a virtual node within the virtual environment 12 can communicate with a physical field device disposed within the physical environment 15 to test the simulated controller behavior). Generally speaking, the MPDSC system 10 provides a platform through which engineers and users can test and inspect draft control strategies and draft operator displays, investigate process improvements, conduct operator training, conduct case studies, and so on. The VMN 300 manages, coordinates, and drives the simulation activities supported by the MPDSC system 10.

[0096] In particular, the VMN300 creates, configures, and operates virtual nodes 25, 30x and other virtual components 28, 32, 35, 38, 42x, 60 that simulate at least a portion of the physical plant 100. Virtual nodes 25, 30x that are utilized only for simulation purposes (not for runtime control purposes) are interchangeably referred to herein as "simulated nodes". For example, the VMN300 can generate a mirror simulation system of the entire runtime control system as described by the plant configuration database 172b by utilizing simulated nodes that simulate integrated physical hardware components such as, for example, the controller 110, the workstation 170a, and / or other physical devices and their corresponding network interconnections (in some embodiments, simulating down to the MAC address level). In another example, the VMS300 can generate a simulation of each of one or more individual physical components, each of which can be executed in stand-alone mode or in cooperation with one or more other simulated, virtual, and / or physical components. For example, the VMS300 can generate a virtual counterpart of a physical component currently operating in the physical environment 15 within the virtual environment 12 to test, for example, new control configurations, upgrades, patches, etc. that are to be applied to the physical component. In another example, the VMS300 can generate a simulation of the MAC address level behavior of a particular physical component. In yet another example, the VMS300 can generate an integrated (e.g., single) simulated node that simulates the real-time operating behavior of a group of physical devices, components, or nodes such as a control loop or an operator display view.

[0097] Regarding the configuration of the types of data values used within the virtual environment 12 and the physical environment 15 of the process control system 100, in one embodiment, the system process data definition (which can be configured via the system configuration application 172a and / or via the VMS 300) defines which data values (and / or their types) used within the process plant 100 will be simulated, and the VMS 300 assigns each data tag (e.g., identifier) to the data value (and / or its type) that will be simulated. For example, the VMS 300 can automatically assign data tags to at least some of the data values and / or data types that will be simulated, and / or the VMS 300 can receive manually generated data tags for at least some of the data values and / or data types that will be simulated, for example, via the user interface 302. The assigned data tags for the simulated data values and / or data types can be stored within the virtual environment configuration database 305 and / or within the system configuration database 172b.

[0098] In addition, the VMN 300 drives and / or coordinates the simulation of the entire physical plant 100 and / or a portion thereof. For this purpose, the virtual environment 12 provides a simulator API (application programming interface) 310 or other suitable access mechanism through which applications such as the user interface 302, the IT layer application 21x, and / or the third party or external application 22x can interface with the virtual environment 12 for simulation purposes. In one embodiment, the VMN 300 or other computing device within the virtual environment 12 hosts and / or exposes the simulator API 310 to other applications.

[0099] As shown in FIG. 5, the simulator API 310 communicates simulated data values (also interchangeably referred to herein as "simulation data values", "simulated values", and / or "simulation values") to and from the virtual environment 12 and the simulated components contained therein via the I / O switch 25. Generally speaking, simulated runtime process data is delivered between 28, 30x and the simulator API 310 via the respective Pub / Sub layers of the nodes. For example, the simulated nodes 28, 30x, 310 may publish runtime process data to one or more other simulated nodes 28, 30x, 310 via the I / O switch 25, and the simulated nodes 28, 30x, 310 may subscribe to real-time process data generated by one or more other simulated nodes 28, 30x, 310 and received via the I / O switch 25. On the other hand, in one embodiment, simulated data values that are not runtime process data (e.g., data values that are configurable and typically assigned during the download time in the physical environment 15) may be delivered between the simulated nodes 28, 30x, 310 on a change basis, e.g., only when the respective values of the data change.

[0100] The simulator API 310 is composed of the names, data tags, identifiers, data definitions, channel data, etc. of the components simulated within the virtual environment 12 (e.g., based on the data stored in the virtual configuration database 305), and the simulator API 310 is also configured to communicate using one or more industrial and / or general-purpose communication / data protocols that are standardized protocols such as OPC, Ethernet, IPv6, etc. Thus, the simulator API 310 is a consumer and / or provider of the virtual environment 12 and simulation data, and functions as a data distribution and transmission mechanism between other applications 302, 21x, 22x that utilize one or more industrial and / or general-purpose communication / data protocols. For example, a third-party simulation application can utilize the simulator API 310 to inject test values for use by the simulated components, change the initial conditions of the simulation execution, etc.

[0101] Additionally or alternatively, the simulator API 310 handles simulation commands provided via the user interface 302 and / or by other applications 21x, 22x. For example, the simulator API 310 may receive simulation commands that speed up and / or slow down the pace of module execution (at least a portion of which is simulated within the virtual environment 12), and / or speed up and / or slow down the pace of I / O processing, and may appropriately drive the timing and actions of the associated simulated nodes 30x, 28 and / or the virtual communication network 45. In another example, the simulator API 310 may receive simulation commands for injecting and / or changing various data values during the simulation. Further, the simulator API 310 may receive operational simulation commands such as, for example, saving a snapshot, searching for a saved snapshot, restoring from saved data, and may perform corresponding actions accordingly. For example, the simulator API 310 may receive a simulation command and, in response, save, search for, restore a simulation of the entire process plant 100 (e.g., to / from the virtual environment configuration database 305 and / or to / from the system configuration database 172b). Together with the system configuration database 172b, it may perform actions such as saving, searching for, restoring a simulation of one or more nodes or components of the process plant 100.

[0102] Generally speaking, the simulation API 310 is stateful. That is, the simulation API 310 recognizes various states of the simulation and its associated components during simulation execution (e.g., virtual, physical, and / or simulated devices, virtual, physical, and / or simulated modules, other types of virtual, physical, and / or simulated components, processes at least partially simulated by the simulation, the state of the entire simulation, etc.), and responds to commands received based on the various states. For example, in response to a save command, the simulation API 310 may save process data along with data indicating the state of the relevant components. In another example, when simulating a modified control module executed within a controller for testing purposes, the simulation API 310 may enable a user to change the state of the relevant module to determine how the modified control module responds to different states of the relevant module.

[0103] FIG. 6 is a flow diagram of an exemplary method for switching nodes of a process control system of an industrial process plant during runtime operation. At least a portion of method 400 can be implemented by one or more portions of the multi-purpose dynamic simulation and runtime industrial or process control (MPDSC) system or platform 10 of FIG. 1, and / or by any one or more of its components. For example, at least a portion of method 400 can be implemented by any one of virtual nodes 30a-30p of FIG. 1. In an embodiment, method 400 is at least partially implemented by, or in cooperation with, one or more portions of the embodiments of virtual nodes 52a, 52b of FIG. 2, one or more portions of the embodiment of physical plant environment 100 of FIG. 3 and / or one or more of its components, one or more portions of the embodiment of I / O switch configuration 200 of FIG. 4, and / or one or more portions of the embodiment of virtualization management node 300 of FIG. 5. For example, at least a portion of method 400 can be implemented by VMN300 of FIG. 5. For ease of illustration and not for purposes of limitation, method 400 is described herein with simultaneous reference to the portions of FIGS. 1-5. Further, method 400 can include more, fewer, and / or alternative steps than those described herein, in an embodiment.

[0104] As illustrated in FIG. 6, method 400 includes simulating (block 402) the runtime behavior of at least a portion of the physical components of a process control system disposed within or deployable within an industrial process plant via virtual nodes disposed within a virtual environment of the industrial process plant and by utilizing an I / O switch. The virtual nodes whose runtime behavior of at least a portion of the physical components is simulated are simulated nodes (and thus not virtual runtime nodes operating to control respective portions of the industrial process), and the simulated nodes are communicatively connected to the I / O switch, which communicatively connects the virtual environment of the industrial process plant to the physical environment of the industrial process plant. For example, the I / O switch may be similar to I / O switch 25 or configuration 200 of the I / O switch. The I / O switch operates or executes as part of a process control system, for example, by routing I / O data between various runtime nodes via at least subscriptions and publications in a manner similar to the manner described elsewhere herein to control the industrial process.

[0105] At least a portion of the simulated physical nodes via the simulated nodes can be disposed or deployable within the physical environment of the industrial process plant. For example, at least a portion of the physical nodes can be a process controller, a safety controller, a safety logic solver, an I / O node, card, or device, a wireless device, an Ethernet device, an operator workstation, a user interface device, a tool, a gateway, an electronic marshalling cabinet, a network connection, a specific physical device or component deployable and / or disposed within the physical environment of the industrial process plant, or a module, routine, function or behavior, a MAC address of the specific physical device or component, a hardware sub-component of the specific physical device or component, or another part of the specific physical device or component.

[0106] As shown in FIG. 6, simulating the runtime behavior of at least a portion of the physical components (block 402) includes obtaining the first data published by the I / O switch by the simulated nodes and corresponding subscriptions (block 405). For example, a simulated node may obtain the published first data to which it is subscribed via the publish / subscribe layer of the simulated node. Simulating the runtime behavior of at least a portion of the physical components (block 402) further includes operating on the obtained first data by the simulated node, thereby generating second data (block 408), and publishing, by the simulated node based on the operation, the second data to which the I / O switch is subscribed (block 410). For example, a simulated node may include a component behavior module (CBM) that is executed on the obtained first data to generate a corresponding output, and the simulated node may publish the content of the output of the CBM as the second data to which the I / O switch is subscribed via the publish / subscribe layer of the simulated node.

[0107] In some embodiments, simulating the runtime behavior of at least a portion of the physical components (block 402) is performed via the simulated nodes in cooperation with another virtual runtime node and / or another physical runtime node. The other virtual runtime node and / or another physical runtime node may, for example, operate to control respective portions of the industrial process while participating in the simulation. Thus, real-time process data generated by the other virtual runtime node and / or another physical runtime node may be received in real time, for example, at the simulated node that is to be operated.

[0108] In some embodiments, simulating (block 402) the runtime operation of at least a portion of the physical components may include manipulating the simulation. For example, the pace of the simulation may be slowed down, sped up, and / or changed for real-time execution, values may be inserted at several points during the simulation, values may be changed at several points during the simulation, the initial conditions of the simulation may change, the intermediate conditions of the simulation may change, and so on.

[0109] In some configurations, simulating (block 402) the runtime behavior of at least a portion of the physical components is via a simulator access mechanism such as the simulated nodes, and the simulator access mechanism 310. The simulator access mechanism 310 can be an API or other suitable access mechanism that is exposed to one or more applications, such as a user interface application, a third-party application, other simulation applications, and the like. In these configurations, simulating may respond to one or more instructions provided by one or more applications via the simulation access mechanism. The instructions can include, for example, instructions to manipulate the simulation, such as changing the pace of the simulation, inserting values, changing values, changing initial conditions, changing intermediate conditions, and so on. Additionally or alternatively, the instructions can include instructions related to the operation of the simulation, such as saving information associated with the simulation, retrieving previously saved information associated with one or more previous simulations for use in the simulation, restoring at least a portion of the simulation based on a previously saved simulation associated with one or more previous simulations, and the like.

[0110] The simulator access mechanism can maintain (and update) various states corresponding to the simulation as the simulation progresses. For example, indications of the states of various data, components, parts of components, systems, subsystems, etc. corresponding to the runtime nodes associated with the simulation can be passed to the simulator access mechanism for maintenance and / or update via, for example, an I / O switch, or provided otherwise. Accordingly, the various states during the simulation can be saved and / or changed via, for example, the simulator access mechanism.

[0111] Returning now to FIG. 6, method 400 can include activating a node simulated as a virtual runtime node of a process control system, where the virtual runtime node operates in cooperation with an I / O switch to control at least a portion of an industrial process during the runtime operation of the process control system (block 412). For example, activating a simulated node as a virtual runtime node can occur during the approval or inspection of one or more simulations involving the simulated node. In this way, the simulated node can be tested and inspected to verify its runtime behavior and, upon approval, can simply be activated or switched over to be implemented or executed as a virtual runtime node within the process control system without requiring significant (if any) downtime to the runtime process control operation. Generally speaking, the activated virtual runtime node is a virtualization of at least a portion of a physical component and operates as appropriate to perform and / or support real-time process control (e.g., in cooperation with an I / O switch).

[0112] Advantageously, in some situations, the simulated nodes can be virtual counterparts of specific instances of physical components or portions thereof. The specific instance may be a physical instance disposed within the physical environment of an industrial process plant, or a virtual instance disposed within the virtual environment of an industrial process plant. In either case, the specific instance is being executed to perform and / or support runtime process control, and the simulated node operating as the virtual counterpart of the specific instance reflects the runtime behavior (e.g., content, data, messaging, timing, state, etc.) of the specific instance when the specific instance is being executed in real time. Thus, in block 412, activating the virtual counterpart that will be the virtualization of the specific instance essentially activates a hot spare of the specific instance, which enables a seamless or "bump-less" switchover from the previously executed specific instance to the virtual counterpart for real-time operation.

[0113] In some embodiments (not shown in FIG. 6), method 400 may include simulating at least a portion of a second physical component via a second simulated node disposed within a virtual environment of an industrial process plant. Simulating at least a portion of the second physical component via the second simulated node may include obtaining fifth data published by an I / O switch via the second simulated node and a corresponding subscription, generating sixth data by the second simulated node based on the fifth data, and optionally publishing the sixth data. The sixth data may be generated, for example, by a component operation module of the second simulated node operating on the fifth data. In these embodiments, upon approval corresponding to the second simulated node, method 400 may include causing an instance of the second physical component disposed within the physical environment of the industrial process plant to download or otherwise be provided with the CBM of the second simulated node. Thus, when the CBM is downloaded and executed by an instance of the second physical component during runtime operation, the instance of the second physical component may be operated in accordance with the CBM, thereby providing control (or support for control) of respective portions of the industrial process.

[0114] Therefore, from the above, the new multi-purpose platform for the dynamic simulation and runtime control platform 10 provides many benefits and advantages over known process control systems. For example, the MPDSC platform 10 supports both simulation and runtime control via virtual components, so that testing of changes (e.g., upgrades, patches, etc.) can be performed in the virtual environment 12 via the simulated components, and upon successful testing, the simulated components can be easily activated as virtual components of the process plant 100 (e.g., seamless or warm switchover of "read, evaluate, execute"). Thus, the switchover of simulated components to runtime components is more easily achieved, and downtime due to upgrades, patches, and scheduled maintenance is reduced. Further, providing virtual hot spares for various components and the amount of resources utilized to bring the virtual hot spares online during a failure or error scenario are also significantly reduced.

[0115] Furthermore, the provision of runtime virtual components by the MPDS platform 10 enables independence between the hardware and software within the plant 100. For example, the controller software utilized during the runtime of the process control system 100 can be upgraded within the runtime virtual controller without the need to upgrade or change any physical controller hardware. Similarly, due to the hardware / software independence, the MPDS platform 10 enables the hardware of the process plant 100 to be upgraded independently of software upgrades.

[0116] In addition, the provision of runtime virtual components as well as their operation and / or management (e.g., via the VMS300 of the MPDSC platform 10) also enables easy and low-cost system scalability because additional virtual components can be easily implemented within the virtual environment 12 without the need to pay for the installation, testing, commissioning, and inspection of different physical hardware components and the required cabinets, wiring, etc. In fact, when additional virtual components are required to support the system 100, the virtual components can be created as needed up to the processing and / or memory limitations of the physical computing devices and / or hardware on which the virtual components 12 are implemented, and then additional physical computing devices and / or hardware can simply be added thereto.

[0117] The virtual environment 12 provided by the MPDS platform 10 enables the creation of digital twins of various components and / or virtual simulations of the entire process plant 100, for example, for testing, hot spare, upgrade, patching, planned maintenance, and / or other purposes. The digital twins (e.g., of specific components and of the entire process plant 100) can be updated in lockstep with updates to their respective specific physical components. That is, status information can be passed from physical nodes to virtual nodes via the MPDSC platform 10. In fact, the MPDSC platform 10 provides enhanced online testing of changes and / or different scenarios (e.g., “what-if” scenarios) and, in some situations, provides in cooperation with the runtime virtual and / or physical components of the process plant 100. Due to the common MPDS platform 10 (and, in particular, the virtual environment 12 of the MPDS platform 10) being architected and utilized for both simulation and runtime control purposes, offsimulation is easily achieved without any configuration changes.

[0118] Furthermore, since the MPDS platform 10 is decoupled from being specifically directly associated with a particular hardware to abstract the I / O of the process plant 100, the I / O configuration within the plant 100 is more flexible and can be easily changed and adapted not only during runtime but also during upgrades, maintenance, failures, etc. Importantly, the communication connection between the I / O devices and other components (e.g., CIOC and controllers) is no longer restricted by the physical ports available on the physical I / O devices. The I / O is abstracted within the MPDS platform 10, and any number of communication connections between the virtual I / O devices and other components are logically possible up to the processing and / or memory limitations of the physical computing devices and / or hardware on which the virtual environment 12 is implemented, and then additional physical computing devices and / or hardware can simply be added thereto. Similarly, due to the abstraction of the I / O within the MPDS platform 10, the control modules and / or other CBMs 58 can be assigned to any virtual host device or component without concern for the I / O locations and / or the loading of the host devices or components required when using the physical host devices or components. That is, as discussed above, the virtual components (regardless of whether they are used for simulation or runtime control purposes) can operate using I / O from physical components or from other virtual components. Thus, the MPDS platform 10 can abstract redundancy, retry, and other mechanisms currently associated with specific implementations of the currently known art (e.g., by using the I / O switch 25), and as a result, the abstraction can be utilized across multiple different types of applications, scenarios, and implementations, involving various selected customizations and specializations of the abstraction for a particular implementation and / or application. As a result, the MPDS platform 10 can consistently and easily scale to support a greater number and types of I / O systems (compared to the currently known art).

[0119] When implemented in software, the applications, services, virtual devices, virtual machines, virtual entities, etc. described herein can be stored in any tangible non-transitory computer-readable memory, such as on a magnetic disk, a laser disk, a solid-state memory device, a molecular memory storage device, or other storage media, or within the RAM or ROM of a computer or processor. The exemplary systems disclosed herein are disclosed as including software and / or firmware executed on hardware among other components, but it should be noted that such systems are merely exemplary and should not be considered limiting. For example, any or all of these hardware, software, and firmware components are contemplated to be embedded either only in hardware, only in software, or in any combination of hardware and software. Accordingly, although the exemplary systems described herein are described as being implemented in software executed by a processor of one or more computer devices, those skilled in the art will readily understand that the examples provided are not the only way to implement such systems.

[0120] Accordingly, while the invention has been described with reference to specific examples, these examples are merely illustrative and are not intended to be limiting of the invention, and it will be apparent to those skilled in the art that changes, additions, or deletions can be made to the disclosed embodiments without departing from the spirit and scope of the invention.

Claims

1. 1. A method for seamless switchover in a process control system of an industrial process plant during run-time operation, comprising: reflecting runtime behavior of at least a portion of deployable physical components in the industrial process plant via virtual nodes of the process control system, the virtual nodes being virtual counterparts of the at least a portion of the physical components, the reflecting comprising: Obtaining, via a subscription, first data published by an input / output (I / O) switch by the virtual pair; operating on the obtained first data by the virtual pair; and publishing, based on the operation, by the virtual pair, second data to which the I / O switch subscribes; Including, the obtaining, operating, and publishing by the virtual pair occurs while the I / O switch is operating to control an industrial process by routing I / O data between runtime nodes via subscriptions and publications during the runtime operation of the industrial process plant, the runtime nodes including process controllers and field devices that are together included in a process control loop of the process control system; The method further comprises: and switching over the virtual pair from running as the virtual pair to running as a virtual runtime node of the process control system operating in conjunction with the I / O switch to control at least a portion of the industrial process during the runtime operation of the industrial process plant.

2. reflecting the runtime behavior of at least the portion of the physical component includes reflecting the runtime behavior of a process controller, a safety controller, a safety logic solver, an I / O node, card, or device, a wireless device, an Ethernet device, an operator workstation, a user interface device, a tool, a gateway, an electronic marshalling cabinet, a network connection, another type of physical device or component that can be deployed and / or is disposed within the physical environment of the industrial process plant, a module, routine, function, or behavior of a particular physical device or component that can be deployed and / or is disposed within the physical environment of the industrial process plant, a Media Access Control (MAC) address of the particular physical device or component, a hardware sub-component of the particular physical device or component, or another portion of the particular physical device or component; 2. The method of claim 1, wherein switching over the virtual pair from execution as the virtual pair to execution as the virtual runtime node comprises activating the virtual pair as a virtualization of at least the portion of the physical component.

3. 2. The method of claim 1, wherein switching over the virtual pair from execution as the virtual pair to execution as the virtual runtime node comprises activating the virtual pair as the virtual runtime node upon receiving an acknowledgment of the reflection.

4. Reflecting the runtime behavior of the at least a portion of the physical components deployable in the industrial process plant includes reflecting virtual instances of the at least a portion of the physical components, the virtual instances being placed in a virtual environment of the industrial process plant; 2. The method of claim 1 , further comprising: switching over from the virtual instances of the at least a portion of the physical components to the virtual runtime nodes corresponding to the at least a portion of the physical components during the runtime operation of the industrial process plant.

5. The method of any one of claims 1 to 4, wherein the reflecting of the runtime behavior of the at least a portion of the physical component includes reflecting the runtime behavior of the at least a portion of the physical component in coordination with behavior of at least one of another virtual runtime node or another physical node of the process control system.

6. 6. The method of claim 5, wherein the at least one of the other virtual runtime node or the other physical node is operating during the runtime operation of the process control system to control a respective portion of the industrial process.

7. 5. The method of claim 1, further comprising: running a simulation, the running of the simulation comprising at least one of: saving information associated with the reflection, retrieving previously saved information associated with a previous reflection for use in the simulation, or restoring at least a portion of the simulation based on the previously saved information associated with the previous reflection.

8. The virtual pair is a first virtual pair and the physical component is a first physical component, and the method further comprises: reflecting a runtime behavior of at least a portion of a second physical component deployable in a physical environment of the industrial process plant via a second virtual pair disposed in a virtual environment of the industrial process plant, the reflecting via the second virtual pair comprising: obtaining, via each subscription, third data published by the I / O switch by the second virtual pair; operating on the obtained third data by the second virtual pair; and publishing, based on the operation, by the second virtual pair, fourth data to which the I / O switch subscribes; Including, 5. The method of claim 1, further comprising: upon approval of the reflection of the runtime behavior of the at least a portion of the second physical component, downloading a component behavior module (CBM) of the second virtual counterpart to an instance of the second physical component disposed within the physical environment of the industrial process plant, whereby the second physical components execute in accordance with the downloaded CBM to control respective portions of the industrial process during the runtime operation of the process control system.

9. the virtual pair being a virtual pair of particular instances of the physical components, the particular instances executing within the industrial process plant during the run-time operation of the process control system to control respective portions of the industrial process; 5. The method of claim 1, wherein reflecting the runtime behavior of the at least a portion of the physical components via the virtual pairing comprises reflecting the runtime behavior of the particular instance of the physical component as the particular instance of the physical component executes during the runtime operation of the process control system to control the respective portion of the industrial process.

10. 10. The method of claim 9, wherein reflecting the runtime behavior of the particular instance of the physical component comprises obtaining state information associated with the runtime behavior of the particular instance of the physical component by the virtual pair and passed to the virtual pair.

11. The process control system further includes a virtualization management node; The method further includes creating, by the virtualization management node, the virtual counterpart of the process control system and any other virtual runtime nodes disposed within a virtual environment of the industrial process plant and operating in conjunction with the I / O switch to control the industrial process during the runtime operation of the process control system; 5. The method of claim 1, wherein switching over the virtual pair from running as the virtual pair to running as the virtual runtime node comprises activating, by the virtualization management node, the virtual pair as the virtual runtime node.

12. 1. A system for switching over a node of a process control system of an industrial process plant during run-time operation, the system comprising: a virtual node disposed in the virtual environment of the industrial process plant and reflecting a runtime behavior of at least a portion of a physical component deployable in a physical environment of the industrial process plant, the virtual node being a virtual counterpart of the at least a portion of the physical component; Including, The reflection is Obtaining first data published by an input / output (I / O) switch via a subscription; Operating on the obtained first data; and publishing second data to which the I / O switch subscribes based on the operation; and Including, The obtaining, operating, and publishing occur while the I / O switch is operating to control an industrial process by routing I / O data between runtime nodes via subscriptions and publications during the runtime operation of the industrial process plant, the runtime nodes including process controllers and field devices that are together included in a process control loop of the process control system; The system further comprises: a virtualization management node that switches over the virtual pair from running as the virtual pair to running as a virtual runtime node of the process control system that operates in conjunction with the I / O switch to control at least a portion of the industrial process during the runtime operation of the industrial process plant.

13. the physical component corresponding to the virtual pair comprises at least one of a process controller, a safety controller, a safety logic solver, an I / O node, card, or device, a wireless device, an Ethernet device, an operator workstation, a user interface device, a tool, a gateway, an electronic marshalling cabinet, a network connection, another type of physical device or component that can be deployed and / or is disposed within the physical environment of the industrial process plant, a module, routine, function, or behavior of a particular physical device or component that can be deployed and / or is disposed within the physical environment of the industrial process plant, a Media Access Control (MAC) address of the particular physical device or component, a hardware subcomponent of the particular physical device or component, or another portion of the particular physical device or component; The system of claim 12 , wherein the virtual runtime node that is switched over from the virtual pair is a virtualization of the at least a portion of the physical component.

14. 13. The system of claim 12, wherein the virtual pair operates in conjunction with at least one of a particular virtual runtime node or a particular physical node of the process control system to reflect the runtime behavior of the at least a portion of the physical components while operating during the runtime operation of the process control system such that the particular virtual runtime node or the particular physical node controls the industrial process.

15. 13. The system of claim 12, wherein the virtualization management node creates a plurality of virtual nodes disposed in the virtual environment, the plurality of virtual nodes including the virtual counterpart of the process control system and any other virtual runtime nodes that operate in conjunction with the I / O switch to control the industrial process during the runtime operation of the process control system.

16. the virtual pair is a first virtual pair and the physical component is a first physical component; The system further includes a second virtual pair disposed in the virtual environment of the industrial process plant, the second virtual pair reflecting a runtime behavior of at least a portion of a second physical component deployable in the physical environment of the industrial process plant, the reflecting of the at least a portion of the second physical component including obtaining third data published by the I / O switch and generating fourth data subscribed to by the I / O switch based on the third data; 13. The system of claim 12, wherein based on the reflection of the at least a portion of the second physical component, the virtualization management node causes a component behavior module (CBM) of the second virtual pair to be downloaded to an instance of the second physical component disposed within the physical environment of the industrial process plant, such that the instance of the second physical component executes as part of the process control system in accordance with the downloaded CBM to control a respective portion of the industrial process.

17. the virtual pair being a virtual pair of particular instances of the physical components, the particular instances executing in the industrial process plant during the run-time operation of the process control system to control respective portions of the industrial process; 17. The system of claim 12, wherein reflecting the runtime behavior of the at least a portion of the physical components includes reflecting the runtime behavior of the particular instance of the physical component as the particular instance of the physical component executes during the runtime operation of the process control system to control the respective portion of the industrial process.

18. 20. The system of claim 17, wherein reflecting the runtime behavior of the particular instance of the physical component includes receiving, by the virtual pair, state information associated with the runtime behavior of the particular instance of the physical component to the virtual pair.

19. The system of any one of claims 12 to 16, wherein switching over the virtual pair from execution as the virtual pair to execution as the virtual runtime node comprises activating the virtual pair as the virtual runtime node.

20. 20. The system of claim 19, wherein the activation is in response to approval of the reflection.

Images