Centralized virtualized management node in a process control system

Abstract

The multi-purpose dynamic simulation and runtime control platform includes a virtual process environment coupled to a physical process environment, and components / nodes of the virtual and physical process environments cooperate to dynamically perform runtime process control of an industrial process plant and / or its simulation. The virtual components may include virtual runtime nodes and / or simulation nodes. The MPDSC includes an I / O switch that virtualizes physical I / O process data transfer, for example, by using a publish / subscribe mechanism to transfer I / O data between virtual nodes and / or physical nodes. The nodes served by the I / O switch may include corresponding component behavior modules that are unaware of whether they are utilized on a virtual or physical node. The simulation can be performed in real time and even in conjunction with the runtime operation of the plant, and / or the simulation can be operated as needed (speed, numerical values, management, etc.). The platform supports both simulation and runtime operations and the interactions / intersections between them.

Description

[0001] Cross - Reference to Related Applications

[0002] 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 incorporated herein by reference in its entirety. Technical Field

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

[0004] Process or industrial control systems (such as those used in chemical, petroleum, or other industrial process plants to produce physical products from materials) typically include one or more process controllers that are communicatively coupled to one or more field devices via analog, digital, or combined analog / digital buses, or via wireless communication links or networks. Field devices, which can be, for example, valves, valve positioners, switches, and transmitters (e.g., temperature, pressure, level, and flow rate sensors), are located within the process environment and typically perform physical or process control functions (e.g., opening or closing valves, measuring process parameters, etc.) to control one or more processes being executed within the process plant or system. Smart field devices (such as those compliant with well - known field - bus protocols) 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 distributed throughout the plant environment, receive signals indicating process measurements made by the field devices and / or other information related to the field devices, and execute controller applications, such as running different control modules that make process control decisions, generate control signals based on the received information, and coordinate with control modules or blocks executed within the field devices (such as Wireless and field - bus field devices). The control modules in the controller send control signals to the field devices via communication lines or links to control the operation of at least a portion of the process plant or system.

[0005] Information from field devices and controllers can typically be provided from the controller to one or more other hardware devices via a data highway, e.g., an operator workstation, a personal computer or computing device, a data historian, a report generator, a centralized database, or other centralized management computing device, which are typically located in a control room or other location remote from the harsher 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 execute applications that can, for example, enable an engineer to configure portions of the process, or enable an operator to perform functions regarding controlling the process and / or operating the process plant, such as changing settings of process control routines, modifying the operation of control modules within the controller or field devices, viewing the current state of the process, viewing alarms generated by the field devices and controllers, simulating the operation of the process for the purpose of training personnel or testing process control software, maintaining and updating a configuration database, etc. The data highway used 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.

[0006] As an example, DeltaV sold by Emerson Process Management TMThe control system includes multiple applications stored in and executed by different devices located at different positions within a process plant. A configuration application residing in one or more workstations or computing devices enables a user to create or change 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, which are objects of an object-oriented programming protocol that execute functions within a control scheme based on inputs thereto and provide outputs to other function blocks within the control scheme. The configuration application may also allow a configuration designer to create or change an operator interface used by a viewing application to display data to an operator, and enable the operator to change settings within a process control routine, such as set points. Each dedicated controller and, in some cases, one or more field devices store and execute a corresponding controller application that runs the control modules allocated and downloaded to it to implement actual process control functions. A viewing application, which may be executed on one or more operator workstations (or on one or more remote computing devices communicatively coupled to the operator workstations and the data highway), receives data from the controller application via the data highway and uses a user interface to display the data to a process control system designer, operator, or user, and may provide any of a plurality of 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 the data highway, while a configuration database application may run in another computer attached to the data highway to store the current process control routine configuration and data associated therewith. Alternatively, the configuration database may be located in the same workstation as the configuration application.

[0007] The architectures of currently known process control plants and process control systems are strongly influenced by limited controller and device memory, communication bandwidth, and controller and device processor capabilities. 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), a user or configuration engineer typically must select which data in the controller is to be archived or saved, how often it is to be saved, and whether compression is to be used, and configure the controller accordingly using this limited set of data rules. Thus, data that may be useful in troubleshooting and process analysis is often not archived, and if it is collected, useful information may be lost due to data compression.

[0008] In addition, to minimize controller memory usage in currently known process control systems, selected data to be archived or saved (as indicated by the controller's configuration) is reported to a workstation or computing device for storage at an appropriate data historian or data silo. Current techniques for reporting data poorly utilize communication resources and result in excessive controller loading. Additionally, due to time delays in sampling and communication at the historian or silo, data collection and time stamping are typically out of sync with the actual process.

[0009] Similarly, in a batch process control system, to minimize controller memory usage, snapshots of batch recipes and controller configurations are typically kept stored at a centralized management computing device or location (e.g., at a data silo or historian) and are only transferred to the controller when needed. This strategy introduces significant bursty loads in the controller as well as in the communication between the workstation or centralized management computing device and the controller.

[0010] Furthermore, the current architecture of industrial control systems such as process control systems is largely hardware-driven because various functions such as control functions, input / output (I / O) functions, user interface functions, etc. are executed in specific hardware (e.g., user workstations or interface devices, process controllers, safety system controllers, dedicated I / O devices, grouped I / O devices, field devices, safety logic solvers, etc.), are bound to the specific hardware, and are always kept stored in the specific hardware. For example, in current process control systems, the interconnection between a controller and I / O devices (e.g., a single I / O device or a library of grouped I / O devices) is configured based on specific hardware, and thus, the physical I / O relationships are tightly bound, most commonly in a one-to-one fashion, e.g., an I / O device to a controller, another I / O device to another controller, etc. This architecture design limits the resilience, reliability, availability, responsiveness, and flexibility of control systems because these systems are difficult to quickly change or reconfigure, are tightly tied to proprietary hardware for implementing proprietary control software, require hardware redundancy on a device-by-device basis (which can be expensive to implement), and are not easily expandable or upgradable without adding additional hardware that needs to be configured in a specific way, e.g., due to size limitations of a single device (e.g., a physical process controller), specific characteristics and capabilities of I / O devices, etc.

[0011] Some attempts to address these issues include virtualizing physical controllers; however, controller virtualization has been limited to offline development and test systems and has not been widely used (if at all) for runtime process control in physical plants and / or production environments. Additionally, virtualized controllers and physical controllers are still limited by physical I / O devices such as performance, bandwidth, throughput, etc. Summary of the Invention

[0012] A novel multi-purpose hardware / software architecture or platform for dynamic simulation and / or runtime production process control, which makes the industrial or process control system of an industrial process plant more resilient, responsive, and flexible compared to known industrial or process control systems. More specifically, this novel architecture or platform largely separates the hardware used in the control system from the software that governs the behavior of the hardware, making the system easier to expand, reconfigure, and change, and improving the overall system reliability, availability, and performance. For ease of discussion, the novel multi-purpose dynamic simulation and runtime control platform or architecture is interchangeably referred to herein as "MPDSC", "MPDSC platform", "MPDSC system", or "MPDSC architecture".

[0013] Generally, MPDSC includes a virtual process environment coupled to a physical process environment, where the components of the virtual and physical environments cooperate to perform dynamic simulation of an industrial process plant and / or runtime (e.g., actual or operational) production process control. For runtime process control, the MPDSC platform supports a process control system (PCS), which can include virtual components, physical components, and / or both virtual and physical components, that can cooperate to monitor and control batch and / or continuous industrial processes during the runtime of the plant. In certain arrangements, the MPDSC platform also supports a safety instrumented system (SIS), which can have both virtual and physical components that cooperate to maintain safe operation and provide fail-safe operation of the plant during runtime. Virtual nodes that perform runtime, operational process control and / or related runtime functions (e.g., in conjunction with one or more physical devices or components located in the physical environment of the process plant) are referred to herein as "virtual runtime nodes".

[0014] The MPDSC platform can additionally or alternatively support a simulation environment or space, which can be used for testing, inspection, verification, and / or checking of control and / or safety systems and / or components, operator training, case studies, continuous process improvement, etc. For simulation purposes, the MPDSC platform provides virtual nodes that simulate one or more physical devices, modules, or components that can be deployed in the physical process environment. Virtual nodes that simulate various devices, modules, and / or components that can be deployed in the physical environment of a process plant are referred to herein as "simulation nodes".

[0015] The simulations provided by the MPDSC platform are "dynamic" because simulations of a process plant or parts thereof can be executed in real time, thus mirroring the timing and other behaviors that (may) occur during runtime, and / or the simulations can be manipulated to execute faster or slower than real time, using different values, initial conditions, intermediate conditions, etc. The simulation space provides various features such as the ability to save / restore various simulation scenarios, editable initial and / or intermediate conditions for various scenarios, coordination with third-party simulators via various protocols, testing and inspection of operator display views, real-time simulation of one or more parts of the PCS, speeding up and slowing down of simulations of one or more parts of the PCS, simulation of simulation components including operation in conjunction with actual (e.g., non-simulated) virtual and / or physical components, change management, and synchronization with plant configurations, etc. The MPDSC platform is capable of supporting both simulation and runtime operations simultaneously, as well as various interactions and intersections between simulation and runtime operations (e.g., testing upgrades, patches, "what-if" scenarios, configuration changes, user input changes, etc.). Additionally, with the MPDSC platform, system redundancy, fault tolerance, switching, scheduled maintenance, etc. can be achieved seamlessly and easily.

[0016] One of the key components of the MPDSC architecture is referred to herein as an "I / O switch" or "I / O server", which generally abstracts the I / O of a process plant from the I / O that is 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 transfers I / O data between virtual nodes and / or physical nodes of a process plant during runtime. Each node (whether virtual or physical) is generally a component of a process plant that is identified in the MPDSC system by a unique name, label, or identifier. 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 grouped 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 other types of components. Generally speaking, the I / O switch operates as a data proxy between virtual nodes and / or physical nodes, where the I / O switch transfers or exchanges I / O data (also interchangeably referred to herein as "process I / O data" or "PIO data") between a source node (whether virtual or physical) and a target node (whether virtual or physical). In a sense, rather than tightly and / or specifically coupling a physical I / O card to different source and target nodes to transfer process I / O, the I / O switch virtualizes the physical transfer mechanism of process I / O data between the nodes of the MPDSC system and loosens the binding between the hardware components for the purpose of transferring I / O data. In addition, the I / O switch is configured to transfer I / O data fast enough (e.g., with a small enough latency) to support runtime, actual production process control and / or real-time simulation of production process control.

[0017] Generally speaking, the virtual and physical nodes / components served by an I / O switch or I / O server include corresponding modules that govern 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 control modules in controllers, safety logic in safety logic solvers, and other types of modules that govern the behavior and operation of components of modules in which they are stored and executed and that at least partially operate on I / O data. In the MPDSC system, the CBMs that operate on the process-related payload of I / O data are agnostic or unaware of the I / O switch and its role in transferring I / O data to / from component behavior modules. That is, the CBMs are unaware that the corresponding I / O transfer mechanism to / from their host nodes is a physical I / O card or an I / O switch.

[0018] In this way, the I / O switch can be regarded as an I / O data switching structure, router, and / or transmission mechanism that is transparent to the component behavior modules of the MPDSC system. To this end, the I / O switch transfers I / O data between virtual / physical nodes via the corresponding publish / subscribe layer of the nodes (which may also be interchangeably referred to as the "Pub / Sub layer" herein) and via the virtual communication network through which its I / O payload or data is transmitted between nodes. For example, a sending or publishing node may include a corresponding Pub / Sub layer that publishes data generated by the component behavior module of the sending node to the virtual communication network. The I / O switch can transfer or exchange the published data to a node that is the recipient or subscriber of the data, and each subscriber node can recover the data via its corresponding Pub / Sub layer for consumption by its corresponding component behavior module. In this way, the I / O switch brokers data between the publisher node and the subscriber node on demand according to the defined relationships of the nodes within the MPDSC system.

[0019] 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 used to convert physical materials into physical products through a runtime-controlled process. Thus, the "physical environment" may be interchangeably referred to as the "plant environment" of the industrial process plant herein. As described above, the physical or plant environment includes a front-end portion where physical or hardware components of the MPDSC system (e.g., field devices, sensors, transmitters, switches, positioners, tanks, heaters, etc.) are installed and operate on physical materials to produce physical products. Thus, the "front-end" portion of the physical environment may be interchangeably referred to as the "field" or "site" portion of the physical environment of the process plant herein.

[0020] The physical or plant environment of the MPDSC system also includes a back-end portion where 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) management computing devices execute applications to, for example, configure the process plant and / or its components, view and monitor the runtime operations of the plant, respond to alarms or alerts during the runtime operations of the plant, adjust parameters during the runtime operations of the plant, generate reports, store and analyze data, etc. The back-end portion of the physical environment of the MPDSC system may be located in an area protected from the harsh field environment, such as on-site, in a closed room, and / or in a non-site or off-site location away from the field environment.

[0021] The virtual environment of the MPDSC system is implemented using specially configured and interconnected physical or hardware computing devices to provide a platform that supports the virtualization of various physical process plant components, as will be described in more detail in subsequent portions of this disclosure. Generally, the physical computing devices that provide and support the virtualization platform can be physically located at the plant site (e.g., in a protected enclosed area of the on-site environment), can be physically located off-site, or can be physically and distributedly located between various on-site and off-site locations. 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, the physical computing devices, data links, and communication / data networks form a computing platform on which various logical or virtual components of the MPDSC system reside, where the various logical or virtual components can be combined with components of the physical process environment for runtime process control and / or for process simulation purposes.

[0022] The logical or virtual components residing in the virtual environment of the MPDSC system can operate to provide a simulation of one or more actual or planned physical portions of the MPDSC system (e.g., in real time, at a faster speed, and / or if desired, at a slower speed). In some implementations, the logical or virtual components residing in the virtual environment of the MPDSC system and the physical components residing in the physical environment of the MPDSC system can cooperate 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, where 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 independent virtual real-time simulation and 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 subsequent portions of this disclosure.

[0023] In addition, the virtual and physical environments of the MPDSC platform use 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 the virtual and physical environments, and the intersection between simulation and runtime operations (e.g., testing, switching, etc.) can be accomplished seamlessly and easily.

[0024] In an embodiment, a system (such as a multi-purpose dynamic simulation and runtime industrial or process control (MPDSC) system) includes a process control system. The process control system includes a plurality of virtual nodes disposed in a virtual environment of the industrial process plant, and a plurality of physical nodes disposed in a physical environment of the industrial process plant. The system further includes an I / O switch communicatively disposed between the plurality of virtual nodes and the plurality of physical nodes to transfer data between the plurality of virtual nodes and the plurality of physical nodes through publication and subscription by the I / O switch. At least some of the plurality of virtual nodes and at least some of the plurality of physical nodes operate in combination during runtime operation of the industrial process plant to control an industrial process. The system also includes a virtualization management node that manages the plurality of virtual nodes of the process control system during runtime operation of the industrial process plant.

[0025] In an embodiment, a method of managing a virtual environment of an industrial process plant at a virtualization management node includes: accessing, by the virtualization management node, one or more system configuration databases of the industrial process plant, the one or more system configuration databases storing one or more configurations of the physical environment of the industrial process plant, and obtaining, by the virtualization management node, information indicating at least one configuration of the industrial process plant based on the access. Additionally, the method includes: automatically determining, by the virtualization management node, a number and / or corresponding types of one or more virtual nodes based on the obtained configuration information to support the at least one configuration of the industrial process plant. The virtualization management node creates the one or more virtual nodes in the virtual environment of the industrial process plant; and the virtualization management node configures an I / O switch to communicatively interconnect the one or more virtual nodes. The method further includes: initializing, by the virtualization management node, the one or more virtual nodes and the I / O switch to form a virtual communication network in the virtual environment of the industrial process plant. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1 is a block diagram of an exemplary multi-purpose dynamic simulation and runtime industrial or process control (MPDSC) system that provides dynamic simulation and / or runtime industrial or process control of a process plant.

[0027] Figure 2 is an illustration of Figure 1 an embodiment of an exemplary virtual node architecture that may be included in the MPDSC system of

[0028] Figure 3 is Figure 1Exemplary arrangements of physical plant environments that can be supported by the MPDSC system.

[0029] Figure 4 Depicts an exemplary arrangement of multiple I / O switches, which can be implemented at least in part in Figure 1 the MPDSC system.

[0030] Figure 5 Is a block diagram illustrating an exemplary virtualization management system through which at least a portion of the Figure 1 MPDSC system can be configured and managed.

[0031] Figure 6 Is a flowchart of an exemplary method 400 for managing a virtual environment of an industrial process plant. Detailed Description

[0032] Figure 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 and / or runtime process control of an industrial or process plant. The exemplary MPDSC platform 10 uses virtualized devices to support dynamic simulation and / or real-time process control of an industrial process plant. For example, the MPDSC platform 10 can use virtualized devices for physical production purposes during the runtime of a process plant. As Figure 1 shown, the MPDSC platform 10 includes a virtual plant environment portion 12 and a physical plant environment portion 15; however, in embodiments where the MPDSC platform 10 is used only for real-time simulation purposes, the physical plant environment portion 15 can be omitted. Generally, the virtual plant environment portion 12 and the physical plant environment portion 15 together form one or more operational technology (OT) layers 18 of an industrial process plant, which can provide generated data to one or more information technology (IT) layers 20 associated with the industrial process plant and / or a network external to the IT layer, e.g., 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 executed 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 corresponding third parties and executed in a remote network accessible via the Internet or other public network.

[0033] The enterprise's IT layer 20 can be implemented in any number of locally and / or remotely located computing devices (such as one or more local and / or remote server farms, one or more computing clouds, etc.), 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 Figure 1 shown, 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, where the edge gateway system 28 provides security and efficiency for data transfer between the OT layer 18 / MPDSC platform 10 and the IT layer 20. Additionally, one or more edge gateway systems 28 can provide security and efficiency for data transfer between the MPDSC platform 10 and external networks and / or external applications 22.

[0034] In Figure 1 , the virtual factory environment 12 of the MPDSC platform 10 includes one or more virtual nodes (VNs) 30a, 30b, 30c,..., 30p, which communicate with 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 emulates or virtualizes the behavior of a corresponding physical component that can operate in a physical factory environment 15. In other words, each virtual node 30x within the virtual factory environment 12 processes data and behaves in the same manner as its physical counterpart would process data and behave in the physical factory environment 15.

[0035] Specifically, each virtual node 30x includes a framework and one or more subsystems 32, which allow the VN 30x to communicate with other virtual nodes 30x in the virtual factory environment 12 and / or with one or more physical nodes (PNs) in the physical factory environment 15 (such as physical nodes 40a, 40b, 40c and the edge gateway system 28 (where the edge gateway 28 can be regarded as a specific type of PN)), each physical node including a corresponding framework and a corresponding one or more subsystems 42x, which allow communication with the virtual node 30x. Additionally, the MPDSC platform 10 can include any number of other physical nodes or components (e.g., PNa - PNk).

[0036] A virtual node can virtualize different types of physical nodes. Generally speaking, as used herein, a "physical node" is a physical device or component of the MPDSC platform 10 that includes hardware and sends data to and / or receives data from other devices or components (whether virtual or physical). Examples of the types of physical nodes that can be represented by corresponding virtual nodes 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), etc.), and various components of an I / O electronic marshalling system (such as characterization modules (CHARMs), termination 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, etc.; user interface devices, including local and / or remote physical operator workstations, mobile devices, and / or other computing devices that provide a user interface for runtime operations and / or other purposes related to 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 viewing tools, data analysis and analysis configuration tools, display view configuration tools, diagnostic tools, asset management tools, application stations, etc.; various types of gateways within and / or used by the MPDSC platform 10, such as wireless gateways, safety gateways, firewalls, edge gateways, field gateways, system - to - system gateways, etc.; and other types of physical nodes that can be used in a physical plant environment 15.

[0037] In some embodiments, a single VN 30x may represent or virtualize an entire physical node. In some embodiments, a single VN 30x may represent or virtualize one or more portions of a particular physical node. For example, a single VN 30x may represent or virtualize a particular module or group of modules that execute at or reside at a particular PN, where 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 that executes on a particular PN (e.g., all of a control module that may execute on a physical process controller), a second VN may represent or virtualize a subset of an entire application that executes on a particular PN (e.g., a particular control model, function, or routine used by a 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 a PN sub-component in fine-grained fashion as a hardware sub-component of a particular PN (e.g., a port or other interface, a bus, a transceiver, a chip, a substrate, etc.), or a firmware or software sub-component of a particular PN (e.g., a module, a routine, a function, or behavior, a network address of a particular PN, such as a MAC (Media Access Control) address or other type of address, etc.).

[0038] Examples of types of physical I / O cards that may be used in a physical plant environment 15 and that may be represented and / or virtualized by virtual nodes 30x of the MPDSC 10 include, but are not limited to:

[0039] Discrete output cards, including high-density, intrinsically safe, and redundant discrete output cards;

[0040] Discrete input cards, including high-density, intrinsically safe, and redundant discrete input cards;

[0041] Analog input cards, including analog input cards that support (High-Speed Channel Addressable Remote Transducer) communication protocol, redundant analog input cards that support HART, high-density redundant analog input cards that support HART, and fast analog input cards;

[0042] Analog output cards, including analog output cards that support HART, redundant analog output cards that support HART, high-density redundant analog output cards that support HART, and fast analog output cards;

[0043] Serial cards, including redundant, programmable, and redundant programmable serial cards;

[0044] Interface cards for discrete actuators and / or sensors, RTD (Resistance Temperature Detector) cards, thermocouple cards, millivolt cards, isolated temperature cards, multifunction cards, event sequence cards that support fieldbus communication protocols, redundant fieldbus - supported cards, cards that support Profibus communication protocols, redundant Profibus - supported cards, and other types of physical cards.

[0045] As Figure 1 shown, VN 30a, 30b, 30c, …, 30p communicate with each other and with the I / O switch 25 via respective publish / subscribe layers 32a, 32b, 32c, …, 32p and 35. The publish / subscribe layers may be interchangeably referred to herein as the “Pub / Sub layer” and are represented in Figure 1 by the respective marked - line portions 32x, 35 of each VN 30x and the I / O switch 25. In embodiments of the MPDSC platform 10 that include physical nodes, for example as Figure 1 shown, at least some of the PN 28, 40a, 40b, 40c disposed in the physical plant environment 15 may include respective Pub / Sub layers 38, 42a, 42b, 42c. In a sense, the Pub / Sub layers 32x, 35 (and in some arrangements, the Pub / Sub layers 38, 42x) act as a virtual communication network 45 through which various virtual nodes 30x and the I / O switch 25 (and in some arrangements, physical nodes 40x) can transmit abstracted I / O data. In an exemplary implementation, each Pub / Sub layer 32x, 35, 38, 42x is a respective interface to the virtual communication network 45.

[0046] The virtual communication network 45 can be implemented by one or more physical communication and / or data links and / or networks, which can include wired and / or wireless networks and can be implemented using any suitable technologies such as Ethernet, fiber optic, IP, and other types of packet networks. Data is transmitted between nodes via the virtual communication network 45 through publish and subscribe, and any one or more suitable communication protocols that support publish and subscribe can be used to transfer data in the virtual communication network 45. For example, private packet protocols and / or public or standardized packet protocols (such as IPv6, IoT, and / or IIoT protocols) can be used for publishing and subscribing to I / O data that is transferred between the various nodes 30x, 28, 40x of the virtual communication network 45 and optionally to other applications 21x, 22x (e.g., via the edge gateway system 28).

[0047] 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 corresponding 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 corresponding Pub / Sub layer (e.g., via Pub / Sub layers 32x, 35, 38, 42x, etc.). Generally, the 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 only accepts subscriptions from the I / O switch 25 and not from other nodes, and each node 30x, 28, 40x only subscribes to the I / O data published by the I / O switch 25 (where the I / O data published by the I / O switch 25 can be the data generated by other nodes that has been forwarded and to which the I / O switch 25 has subscribed), and does not subscribe to the I / O data published by other nodes. Thus, in this preferred one-to-one embodiment, compared to an embodiment that allows a node to have multiple subscriptions with multiple other nodes, the undirected graph of the publish / subscribe relationships is restricted, thereby reducing network complexity, simplifying network diagnosis and management, and reducing network load / utilization. To further reduce network complexity, simplify network diagnosis and management, and reduce network load / utilization, additionally or alternatively, each node 30x, 28, 40x of the virtual communication network 45 can send, via publishing, the data that is only to be forwarded by the I / O switch 25 to other nodes of the MPDSC platform 10 to the I / O switch 25. Of course, in some embodiments, at least a portion of the undirected graph can be implemented with one-to-many, many-to-one, and / or many-to-many relationships (if needed).

[0048] Generally, within the MPDSC platform 10, process-related payload data (e.g., as generated by CBM and / or physical components of the process plant) is abstracted and published as I / O data and can be passed to subscriber nodes of the virtual communication network 45 as needed. That is, when a publishing node determines that a data payload related to a process requires a new publishing event, the I / O data can be passed (e.g., via publishing). For example, when the data value generated by a sensor changes, the publishing node can automatically publish the data generated by a particular type of sensor as I / O data to the virtual communication network. Optionally, even when the data value generated by a sensor does not change, the publishing node can periodically (e.g., every five seconds, ten seconds, one minute, etc.) publish the data value generated by the sensor as I / O data, e.g., to mitigate possible lost message and other fidelity issues. Thus, in some embodiments, subscriber nodes do not require and / or do not use an explicit subscription rate. Accordingly, the execution of the processing logic (e.g., component behavior module) at each subscriber node is driven by incoming data subscribed to and received via the virtual communication network 45, and thus the resources used by each node and the virtual communication network 25 can be utilized more efficiently.

[0049] In an exemplary illustrative scenario, VN 30a can generate a particular set of process-related payload data (e.g., “Data1”) during runtime and publish it as I / O data to the Pub / Sub layer 32a of VN 30a. The I / O switch or server 25 can have a subscription to the I / O data including Data1 and can obtain the process-related payload Data1 via the virtual communication network 45, its corresponding Pub / Sub layer 35, and its corresponding subscription. In turn, the I / O switch or server 25 can publish the obtained process-related payload Data1 as I / O data to the virtual communication network 45 for receipt by those nodes having a subscription to the I / O data including Data1. For example, VN 30b can have a subscription to the I / O data including Data1, and after Data1 is published as I / O data via the Pub / Sub layer 35 of the I / O switch 25, VN 30b can obtain the process-related payload Data1 via the virtual communication network 45, its corresponding Pub / Sub layer 32b, and its subscription. Subsequently, VN 30b can operate on the obtained process-related payload Data1 value.

[0050] Thus, the MPDSC platform 10 abstracts multiple different types of I / O used in and inherent to various physical components (e.g., discrete outputs, discrete inputs, analog outputs, analog inputs, serial I / O, Railbus, HART, WirelessHART, fieldbus, Profibus, Ethernet, advanced physical layer, and / or any other type of I / O) so as to be transmitted between virtual nodes and physical nodes via the I / O switch 25 and the virtual communication network 45 through publish and subscribe. Each node of the virtual communication network 45 can perform corresponding abstraction and de-abstraction (e.g., restoration) on the I / O data sent and received via its corresponding Pub / Sub layer and optionally other subsystems.

[0051] Virtual node

[0052] To illustrate I / O abstraction and de-abstraction, Figure 2 Two exemplary architectural embodiments 52a, 52b of the virtual node 30x are illustrated. Generally speaking, the virtual node 30x simulates and / or virtualizes physical nodes or physical components that can be used and operated within the physical plant environment 15. Each VN 52a, 52b includes a corresponding Pub / Sub layer 55a, 55b through which the VN 55a, 55b communicates with the I / O switch 25. In addition, each VN 52a, 52b includes a corresponding component behavior module 58a, 58b, which may be interchangeably referred to herein as "component business logic module" 58a, 58b or "CBM" 58a, 58b. Generally speaking, the CBM 58x is the module that executes, for example, the operation behavior that dominates its corresponding virtual node 30x at the application level. For example, the CBM 58x of a virtual controller node can be a specific instance of a control module, where other instances of the control module can be downloaded to the physical controllers arranged in the physical plant environment 15 for execution during the runtime of the physical plant 15. In another example, the CBM 58x of a virtual CIOC node can be a specific instance of a remote I / O module, where other instances of the remote I / O module can be executed at the physical CIOC arranged therein during the runtime of the physical plant environment 15.

[0053] Since the CBM 58x can execute within a physical component, the CBM is typically inherently familiar with one or more corresponding native I / O types (e.g., analog input / output, fieldbus, Raibus, etc.). In addition, the CBM 58x typically does not know whether they are executing on a virtual node 30x of the virtual factory environment 12, on a physical node 40x set within the physical factory environment 15, or on another physical component (e.g., nodes PNa - PNk) set within the physical factory environment 15. Thus, the CBM 58x sends and receives data in the same manner and using the same processing logic and I / O types, regardless of whether the CBM 58x is executing in the virtual factory environment 12 or in the physical factory environment 15.

[0054] In an embodiment of the virtual node 52a, the process - related payload data sent and received by the CBM 58a is abstracted to be passed to or from the VN 52a via the virtual process I / O (PIO) subsystem 60. Generally speaking, the virtual PIO subsystem 60 emulates the native physical PIO transfer of the virtual node 52a. That is, during the runtime of the virtual node 52a, the virtual PIO subsystem 60 transfers I / O process values and events to / from the CBM 58a using its native I / O, for example, as if the I / O process values and events originated from / are being transferred to physical hardware. In this way, the virtual PIO subsystem 60 can be customized for a specific type of virtual node 52a, where the virtual node type is governed by its CBM 58a. For example, if the VN 52a 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 control routine CBM 58a in the form used by a Railbus I / O card. If the VN 52a represents a CIOC, the virtual PIO subsystem 60 provides I / O data to / from the remote I / O CBM 58a in the form used by CHARM.

[0055] In addition, the virtual PIO subsystem 60 can handle data publishing and subscribing on behalf of the virtual node 52a. That is, the virtual PIO subsystem 60 can publish data generated by the CBM 58a to the Pub / Sub layer 55a, and the virtual PIO subsystem 60 can subscribe to data generated by other nodes (and forwarded by the I / O switch 25) through the Pub / Sub layer 55a. In an embodiment, the subscription and publishing of data can be based on unique tags or other identifiers 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 an embodiment, the tags and / or identifiers can be assigned during configuration and / or debugging.

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

[0057] In Figure 2 In the illustrated embodiment of the virtual node 52b, the virtual PIO subsystem 60 is omitted or not used. Generally, the types of virtual nodes using the VN architecture 52b are those whose CBM 58b is inherently capable of communicating with the physical components and technologies via which the virtual communication network 45 is implemented. For example, if the virtual communication network 45 is implemented via the IP protocol over Ethernet, the virtual node 52b that emulates an EIOC includes a CBM 58b that is inherently configured to communicate using the IP protocol over Ethernet. Thus, the EIOC virtual node 52b can exclude the virtual PIO subsystem 60 (or can turn off or ignore the operation of the virtual PIO subsystem 60), and the EIOC virtual node 52b can handle data transfer to / from the virtual node 52b by using only the CBM 58b and the Pub / Sub layer 55b.

[0058] Physical node

[0059] Figure 3 is a block diagram of an exemplary physical plant environment 100 in which the MPDSC platform 10 can operate in conjunction with Figure 1 . For example, Figure 1 the physical environment portion 15 of the illustrated MPDSC platform 10 can include at least a portion of the physical plant environment 100.

[0060] The physical plant 100 controls an industrial process (or, in some embodiments, operates in conjunction with a virtual plant environment (e.g., the virtual plant environment 12) to control an industrial process), where the industrial process can be said to have one or more "process outputs" that characterize the process state (e.g., tank level, flow rate, material temperature, etc.) and one or more "process inputs" (e.g., various environmental conditions and the states of actuators, manipulations that may cause the process output to change). Figure 3The physical process plant 100 includes a field environment 102 and a back-end environment 105, each of which is communicatively connected to the other via a process control backbone or data highway 108, which 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 (e.g., Ethernet protocol, IP protocol, or other packet protocol).

[0061] At a high level (and as Figure 3 shown), the field environment 102 includes physical components (e.g., process control devices, networks, network elements, etc.) that are installed and interconnected to operate during runtime to control an industrial process. Generally speaking, these physical components are located, disposed within, or included in the field environment 102 of the physical process plant 100, where raw materials are received and processed using the physical components disposed therein to produce one or more physical products (e.g., paper, refined oil, pharmaceuticals, etc.). In contrast, the back-end environment 105 of the physical process plant 100 includes various physical components, such as computing devices, operator workstations, repositories or databases, etc., which 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 in the back-end environment 105 of the physical process plant 100 may be physically located in different physical locations, some of which may be local to the physical plant 100 and some of which may be remote.

[0062] As Figure 3 shown, the field environment 102 includes one or more process controllers 110 communicatively connected to the data highway 108. Each process controller 110 may be connected to one or more intermediate nodes 112, 115 (e.g., I / O cards, I / O devices, I / O systems, etc.), which facilitate communication between the controller 110 and the field devices. Generally speaking, in the process control industry, the term "I / O" is sometimes used in many related but different contexts. This term typically refers to the logical link or communication channel (e.g., "I / O channel") that communicatively couples a field device to an I / O card or controller, but may also be used when referring to many other concepts (e.g., the physical device (e.g., "I / O device" or "I / O card") used to send signals to or receive signals from a field device via an I / O channel and the connectors or terminals associated with the I / O device (e.g., "I / O connector")). The I / O devices and I / O cards 112, 115 may be separate individual physical devices, each of which is connected to a corresponding controller and one or more corresponding field devices, as Figure 3 shown. In some arrangements ( Figure 3In (not shown in the figure), the I / O electronic grouping system includes I / O devices, cards, connectors, and other I / O-related components (such as termination blocks, modules, processors, etc.). The I / O electronic grouping system enables flexible I / O transfer between multiple controllers and multiple field devices of various types, such as those described in U.S. Patent 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 these patents are hereby expressly incorporated by reference. Thus, for the sake of clarity in the discussion and as used herein, the term "I / O device" generally refers to physical I / O devices, cards, the electronic grouping system, and its components through which the I / O channel 5 is implemented to communicatively couple field devices and controllers.

[0063] In addition, in the process control industry, the term "I / O" is often used to refer to the signal transmitted on the I / O channel (e.g., "I / O signal"), the variable or command represented by the signal (e.g., "I / O parameter"), or the value of the variable or command carried by the signal (e.g., "I / O parameter value" or "I / O data payload"). Therefore, for the sake of clarity in the discussion and 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".

[0064] To the extent that the term "I / O" is referenced herein without a qualifier, the context of the sentence should make clear which of these concepts is being discussed. Additionally, it should be understood that an "I / O channel" represents a specific type of "communication channel" or "channel". That is, unless the context of the sentence otherwise implies, a reference to the term "channel" or the term "communication channel" in this specification without the qualifier "I / O" may, in some implementations, refer to a communication link that may be an I / O channel, but in some implementations may also refer to a communication link other than an I / O channel.

[0065] In any case, return Figure 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), which may be stored in the memory of the controller 110. When the processor of the controller executes one or more control routines, the controller sends control signals (i.e., "control outputs") to field devices via a wired or wireless process control communication link or network to other field devices to control the operation of the processes in the plant 100. The controller can generate control signals based on: (i) one or more received signals, which may 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, which may be defined by one or more software elements (e.g., function blocks). Generally, the controller manipulates process inputs (which may be referred to as "manipulated variables") based on feedback (i.e., measurements of the controlled variable) and the desired value of the process output (i.e., the set point) to change a particular process output (which may be referred to as the "controlled variable" or simply the "process variable").

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

[0067] The front-end environment 102 of the plant 100

[0068] For example, Figure 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 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 may be communicatively connected to the wireless gateway 168 using one or more communication networks other than the backbone network 108, e.g., by using any number of other wired or wireless communication links that support one or more communication protocols (e.g., 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), Wireless Profibus, fieldbus, etc.).

[0069] For example, the controller 110 may be a DeltaV Controller sold by Emerson Process Management. TM The controller 110 may use at least some of the field devices 125-132 and 140-146 to implement a batch industrial process or a continuous industrial process. In an embodiment, in addition to being communicatively connected to the process control data highway 108, the controller 110 also uses communication with, for example, standard 4-20mA devices, I / O devices 112, 115, and / or any smart communication protocol (e.g., Fieldbus protocols, Protocol, Wireless Any desired hardware and software associated with the FPGA (such as FPGA protocols) is communicatively connected to at least some of the field devices 125-132 and 140-146. Figure 3 In the embodiment, the controller 110, the field devices 125-132 and the I / O devices 112, 115 are wired devices, and the field devices 140-146 are wireless field devices. Of course, the wired field devices 125-132 and the wireless field devices 140-146 can conform to any other desired standards or protocols, such as any wired or wireless protocols, including any standards or protocols developed in the future.

[0070] Figure 3 The process controller 110 includes a processor 120 that implements or supervises one or more process control routines 118 (e.g., stored in a memory 122 of the controller 110). The processor 120 is configured to communicate with the field devices 125-132 and 140-146 and to communicate with other nodes that are communicatively connected to the controller 110. It should be noted that any control routine or module described herein can have its parts implemented or executed by different controllers or other devices if desired. Similarly, the control routine or module 118 described herein to be implemented within the process control plant 100 can take any form, including software, firmware, hardware, etc. The control routine can be implemented in any desired software format (e.g., using object-oriented programming, ladder logic, sequential function charts, functional block diagrams, or using any other software programming language or design paradigm). The control routine 118 can be stored in any desired type of memory 122 (e.g., random access memory (RAM) or read-only memory (ROM)). Likewise, the control routine 118 may be hard-coded into, for example, one or more EPROMs, EEPROMs, application specific integrated circuits (ASICs), or any other hardware or firmware elements. Thus, the controller 110 may be configured to implement a control strategy or control routine in any desired manner.

[0071] The controller 110 implements control strategies using what are commonly referred to as functional blocks, where each functional block is an object or other part (e.g., a subroutine) of an overall control routine and operates in conjunction with other functional blocks (through communication referred to as links) to implement a process control loop within the MPDSC platform 10. Control-based functional blocks generally perform one of the following: (i) an input function, such as an input function associated with a transmitter, sensor, or other process parameter measurement device (sometimes referred to as an “input block”); (ii) a control function, such as a control function associated with a control routine that performs PID, fuzzy logic, etc. (sometimes referred to as a “control block”); or (iii) an output function that controls the operation of some device (e.g., a valve) to perform some physical function within the process control plant 100 (sometimes referred to as an “output block”). Of course, there are hybrid functional blocks and other types of functional blocks.

[0072] The functional blocks can be stored in and executed by the controller 110, which is typically the case for these functional blocks associated with or for standard 4-20 mA devices or certain types of smart field devices (e.g., devices), or the functional blocks can be stored in and implemented by the field device itself, which can be the case for fieldbus devices. One or more control routines 118 can implement one or more control loops, and one or more control loops are executed by performing one or more functional blocks. In a sense, the control routines 118 can be regarded as component behavior modules of the controller 110.

[0073] The wired field devices 125 - 132 can be any type of device, such as sensors, valves, transmitters, positioners, etc., while the I / O devices 112 and 115 can be any type of process control I / O device that complies with 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 Figure 3 this case, the field devices 125 - 128 are standard 4-20 mA devices or devices that communicate with the I / O device 112 via an analog line or a combined analog and digital line, while the field devices 129 - 132 are smart devices, such as fieldbus field devices, which use The fieldbus communication protocol communicates with the I / O devices 115 via a digital bus. 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 additionally or alternatively communicate with the controller 110 using the process control data highway 108 and / or by using other suitable control system protocols (such as Profibus, DeviceNet, FOUNDATION Fieldbus, ControlNet, Modbus, HART, etc.). In some arrangements ( Figure 3 not shown), at least some of the field devices 125 - 132 may communicate with the controller 110 via an electronic I / O marshalling system rather than via the separate I / O devices 112, 115.

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

[0075] 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 plant 100, such as opening or closing a valve, or making measurements 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 producers and consumers of wireless communication packets.

[0076] In some configurations of the physical process plant 100, the wireless network 165 includes non-wireless devices. For example, in Figure 3 the Figure 3 field device 148 is a traditional 4-20 mA device, and the field device 150 is a wired 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 (e.g., WirelessHART), and may also support one or more other communication protocols (e.g., Fieldbus, PROFIBUS, DeviceNet, etc.). Additionally, in some configurations, the wireless network 165 includes one or more network access points 155a, 155b, which may be separate physical devices that communicate with the wireless gateway 168 in a wired manner, or may be provided as an integral device with the wireless gateway 168. The wireless network 165 may also include one or more routers 58 for forwarding packets from one wireless device within the wireless communication network 165 to another wireless device. In Figure 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.

[0077] The backend environment 105 of the plant 100

[0078] As noted, the backend environment 105 can include various components (such as computing devices, operator workstations, repositories or databases, 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 any one or more of the following, each of which can be communicatively connected to the data highway 108: (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, which 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, which communicate with other devices (such as user interface devices 170b or other devices) associated with the factory 100 using various wireless protocols; (v) one or more factory gateway systems 180 to other factories; (vi) one or more edge gateway systems 182 to systems 185 outside the immediate OT layer of the physical process control platform 100 (such as the enterprise's IT network / system and / or external data network / system, which can be implemented on cloud computing and / or other suitable platforms); and / or (vii) other physical components specifically configured by hardware and software to support the process factory 100.

[0079] Operator workstations and user interface devices 170a, 170b

[0080] The operator workstations 170a and other user interface devices 172b can be used by operators to view and monitor the runtime operations of the physical process factory 100, and to take any diagnostic, corrective, maintenance, and / or other actions that may be required. At least some of the operator workstations 172a can be located in various protected areas within or near the factory 100, and in some cases, at least some of the operator workstations 172b can be located remotely, but still communicatively connected to the factory 10. The operator workstations 172a, 172b can be wired or wireless computing devices.

[0081] Configuration applications 172a and configuration database 172b

[0082] The configuration application 172a and the configuration database 172b can be used to configure certain aspects of the plant 100, such as control modules / routines, user interfaces, data monitoring / analysis, etc. For example, various instances 172a of the configuration application can be executed on one or more computing devices (not shown) to enable a user to create or change process control modules and download these modules to the controller 110 via the data highway 108, create or change an operator interface through which an operator can view data and change data settings within the process control routines, create or change data monitoring / analysis routines and functions that can be downloaded into various physical components in the field environment 102, and so on. The configuration database 172b stores the created (e.g., configured) modules, operator interfaces, data monitoring / analysis, etc. Generally, the configuration application 172a and the configuration database 172b are centralized and have a unified logical appearance for the physical process control platform 100, but multiple instances of the configuration application 172a can be executed simultaneously within the physical process control platform 100, and the configuration database 172b can be implemented across multiple physical data storage devices. Thus, the configuration application 172a, the configuration database 172b, and the user interface thereto (not shown) include a configuration or development system 172 for various types of modules (e.g., control modules, display or operator interface modules, and / or analysis modules). Generally (but not necessarily), the user interface of the configuration system 172 is different from the operator workstation / user interface device 170 because the user interface of the configuration system 172 is used by configuration and development engineers regardless of whether the plant 100 is operating in production mode, while the operator workstation / user interface device 170 is used by operators during the runtime operation of the physical process plant 100.

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

[0084] The configuration database 172b can store multiple logical identifiers of the components in the field environment 102, enabling the controller 110 and other devices to reference the components and the signals associated with the components by the logical identifiers. For example, for a given field device, the configuration database 172b can store or map or bind the logical identifier to information about a specific hardware address or I / O channel. The hardware address can identify a specific controller, a specific I / O device connected to the specific controller, and / or a specific address of the I / O channel that connects the specific I / O device to the field device. In some cases, this mapping or binding can be stored at the controller 110, the user interface device 170b, the operator workstation 170a, or any other desired device (e.g., any device that needs to resolve the logical identifier). After the logical identifier has been bound to the hardware address or I / O channel, the identifier is considered "assigned". In some cases, the plant 100 includes "unassigned" logical identifiers that are referenced by software elements (e.g., control routines and / or function blocks) but do not have a bound identifier. That is, when the plant 100 and the configuration database 172b do not have a hardware address or I / O channel that has been bound to the label, the logical identifier is considered "unassigned". Thus, when a control routine references an unassigned logical identifier, the value carried by the signal in the plant 100 will not be read, nor will a command be sent to the field device in the plant 100 via the signal.

[0085] Examples of such logical identifiers include device tags (DTs) and device signal tags (DSTs), where each device tag (DT) represents a particular instrument, controller, valve, or other physical field device, and each device signal tag (DST) represents a particular signal received or generated by a particular device and typically corresponding to a particular parameter used by the field device. For some devices, the device signal tag includes a combination of the device's device tag and an identifier of the 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 "dumb" devices), the device tag represents both the physical device and the signals generated by that device. In general, the physical process plant 100 uses logical identifiers of devices to uniquely identify the devices in both the field environment 102 and the backend environment 105. DTs and DSTs may be referred to as "system tags" or "system identifiers".

[0086] In some cases, the intelligent field devices 129 - 132 may also store logical identifiers unique to the intelligent field devices 129 - 132. These logical identifiers may be different from the system tags used by the plant 100 to identify the field devices 129 - 132 and may be referred to as "source identifiers" or "source tags". The source tags may or may not be stored in the configuration database 172b, depending on the implementation.

[0087] The configuration database 172b may store data and other information that specifically identify and / or address various virtual devices or components (e.g., various virtual nodes 30) 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 corresponding logical identifiers of the components of the virtual environment 12, enabling other devices and / or components (whether physical or virtual) to reference the virtual components. For example, similar to the physical nodes 40x, the 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. Other portions of the present disclosure discuss the configuration and identification of virtual devices and components in more detail.

[0088] Other applications 175a and databases 175b

[0089] 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 at the OT layer 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 at 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 away 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 may include applications provided by the 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 certain other types of security and / or firewall systems.

[0090] Wireless access point 178

[0091] One or more other wireless access points 178 enable devices in the backend environment 105 (and sometimes in the field environment 102) to communicate with other devices using wireless protocols such as Wi-Fi or other IEEE 802.11-compliant wireless local area network protocols, mobile communication protocols such as WiMAX (Worldwide Interoperability for Microwave Access), LTE (Long Term Evolution), or other ITU-R (International Telecommunication Union Radiocommunication Sector)-compatible protocols, shortwave radio communication such as near field communication (NFC) and Bluetooth, or other wireless communication protocols. Typically, such wireless access points 178 allow handheld or other portable computing devices (e.g., user interface device 170b) to communicate via a corresponding wireless process control communication network that is different from the wireless network 165 and supports a wireless protocol different from that of the wireless network 165. For example, the wireless or portable user interface device 170b can be a mobile workstation or diagnostic test equipment used by an operator within the physical process plant 100 (e.g., an instance of one of the operator workstations 170a). In some cases, in addition to portable computing devices, one or more process control devices (e.g., controllers 110, field devices 125 - 132, or wireless devices 168, 140 - 158) also communicate using the wireless protocol supported by the access point 174.

[0092] Gateway systems 180, 182

[0093] The gateway nodes or systems 180 and 182 can interface with systems external to the immediate physical process control plant 100. Typically, such systems are customers or suppliers 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 to communicatively connect the immediate physical process plant 100 with another process plant. Additionally or alternatively, the process control plant 100 can include an edge gateway node or system 182 to communicatively connect the immediate physical process plant 100 with external public or private systems such as laboratory systems (e.g., laboratory information management system or LIMS), operator tour databases, data integration and viewing systems, data analysis systems, materials handling systems, asset management systems, maintenance management systems, product inventory control systems, production scheduling systems, weather data systems, transportation and handling systems, packaging systems, the Internet, IoT applications, IIoT applications, or other external systems.

[0094] In general, the edge gateway system 182 allows for the secure transfer of communications 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 outside-facing engine (which may be referred to as an "edge gateway"), where the plant-facing engine and the external-facing engine cooperate to securely transfer process plant data (e.g., data generated by the OT layer) to external networks and / or applications (e.g., the IT layer and / or external networks and / or systems) that are consumers of the plant data. In one embodiment among many, the plant-facing engine collects data generated by various components of the process plant 100 and securely transfers the collected data across one or more secure communication links to the external-facing engine, e.g., via a first publish set. The external-facing engine has subscribed to the various publishes generated by the plant-facing engine and obtains the collected plant data therefrom. In turn, the external-facing engine securely transfers 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 publish set. The publishes and subscriptions at the plant-facing engine and / or the external-facing engine can be configured separately as needed. Generally, though, the publish / subscribe, encryption, and / or other secure data transfer mechanisms used between the plant-facing engine and the external-facing engine are different from the publish / subscribe, encryption, and / or other secure data transfer mechanisms used between the external-facing engine and external applications. In some embodiments, for additional security, the edge gateway system 182 includes a unidirectional data diode that is disposed between the plant-facing engine and the external-facing engine to prevent data from flowing from the external network 185 into the process plant 100. Examples of edge gateway systems can be found in U.S. Patent Publication Nos. 20180115516, 20180115528, 20180115517, and 20180113442, the entire disclosures of which are incorporated herein by reference. Of course, the process plant 100 may additionally or alternatively use other edge gateway systems.

[0095] Note that although Figure 3Only a single controller 110, a limited number of field devices 125 - 132 and 140 - 146, a wireless gateway 168, a wireless adapter 152, an access point 155, a router 158, and a wireless process control communication network 165 included in the exemplary physical process plant 100 are illustrated, which is merely an illustrative rather than a restrictive embodiment. Any number of controllers 110 may be included in the process control plant or platform 100, and any of the controllers 110 may communicate with any number of wired or wireless devices and networks 125 - 132, 140 - 146, 168, 152, 155, 158, and 165 to control the processes in the plant 100.

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

[0097] I / O switch

[0098] As described above, Figure 1The I / O switch 25 shown serves as a data broker, switching fabric, or router for process I / O data between nodes of the virtual communication network 45. That is, the switch 25 forwards I / O data generated by a publishing node to nodes that have subscribed to that data on behalf of the publishing node. Generally, the I / O switch 25 may maintain (and update) a record of which nodes have published which I / O data and which nodes have subscribed to which published I / O data. In an embodiment, the I / O data may be identified within the record by a unique identifier, name, or label unique to the MPDSC platform 10, or by a corresponding indication thereof. For example, the unique identifier may identify the process-related payload data included in the I / O data and / or its publishing node. In an embodiment, the unique identifier, name, or label is assigned during configuration and / or debugging. The I / O switch 25 utilizes the stored record to route incoming published data to subscribers of the published data. For example, the I / O switch 25 may subscribe to I / O data published by various nodes 28, 30x, 40x, and after receiving the published I / O data via its subscription, the I / O switch 25 itself may publish the received I / O data to 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 any I / O data and / or process-related payload data published by other nodes of the virtual communication network 45.

[0099] Importantly, the I / O switch 25 is configured to switch or forward received process I / O data with minimal latency. In fact, in a prototype, the I / O switch 25 is capable of forwarding received process I / O data through the I / O switch 25 at time intervals measured in hundreds of microseconds (e.g., below 500 microseconds, below 200 microseconds, and below 100 microseconds, depending on the load).

[0100] Generally, the I / O switch 25 may be implemented via hardware, firmware, and / or software. In an 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 functions of the I / O switch 25 described herein; that is, the I / O switch 25 may 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 may be installed on or executed by a group of computing devices or servers to provide at least some of the functions of the I / O switch 25 described herein. In yet another example, the I / O switch 25 is implemented via virtualization (e.g., as a virtual machine, a container (such as Docker, LXD, etc.), or another type of virtualization implementation).

[0101] The Pub / Sub layer 35 of the I / O switch 25 is generally similar in configuration and function to the Pub / Sub layers 32x, 38, 42x, 55x described elsewhere in this disclosure. However, the Pub / Sub layer 35 of the I / O switch 25 is also configured to accept and maintain subscription requests for various identified process I / O data. As described above, subscriptions are recorded and maintained at the I / O switch 25, such as in one or more tangible non-transitory memories. Additionally, the Pub / Sub layer 35 of the I / O switch 25 is configured to forward published process I / O data to subscription nodes that may include other I / O switches.

[0102] For illustration, Figure 4 depicts an exemplary arrangement 200 of a plurality of I / O switches 202, 205, 208, 210 that may be included in Figure 1 the MPDSC platform 10. In the example, each I / O switch 202, 205, 208, 210 has a corresponding architecture similar to that of the I / O switch 25, including a corresponding Pub / Sub layer (as indicated by the respective marked line portions). 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 a respective set of VNs and / or PNs 212a - 212n, 215a - 215m, 218a - 218p, and 220a - 220q, where the respective I / O switches 202, 205, 208, 210 forward process I / O data between the respective sets of VNs and / or PNs by publishing and subscribing (e.g., in the manner described above). Although the arrangement 200 includes four I / O switches 202, 205, 208, 210, the concepts discussed herein with respect to the arrangement 200 can be readily applied to more or fewer numbers of I / O switches interconnected in a mesh topology.

[0103] In Figure 4In this case, each of the I / O switches 202, 205, 208, 210 can also forward process I / O data to each of the other I / O switches 202, 205, 208, 210 via the virtual communication network 225. By interconnecting multiple I / O switches 202, 205, 208, 210, the number of virtual nodes and / or physical nodes of the service can be extended to support a larger system 10 and provide additional transfer bandwidth. In the arrangement 200, each of the I / O switches 202, 205, 208, 210 can publish data to the other I / O switches 202, 205, 208, 210 on behalf of its corresponding set of VNs / PNs. Similarly, each of the I / O switches 202, 205, 208, 210 can subscribe to the data forwarded by the other I / O switches 202, 205, 208, 210 on behalf of their corresponding sets of VNs / PNs 212a - 212n, 215a - 215m, 218a - 218p, 220a - 220q.

[0104] The arrangement 200 illustrates each of the I / O switches 202, 205, 208, 210 as 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 one implementation of this arrangement 200, the maximum transmission delay from a publisher node to a subscriber node is constrained because the maximum number of hops that a particular process I / O data payload can experience is three. In other implementations of the arrangement 200, the maximum number of hops can be different. For example, when using a time-sequencing capability such as time-sequencing networking or other suitable time-sequencing capabilities, the maximum number of hops can be increased, such as for monitoring traffic. If needed, the maximum number of hops within the arrangement 200 can be configured and modified.

[0105] Of course, in addition to or in lieu of the mesh topology for the virtual communication network 225, other interconnection topologies (e.g., hub-and-spoke, star, ring, tree, hybrid, etc.) are possible. Generally speaking, subscriptions to process I / O data published by a particular publishing node (e.g., node 215a) are made 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 of the particular data requested for subscription, the I / O switch 205 may forward the subscription request to other I / O switches 202, 208, 210. The particular I / O switch corresponding to the node publishing the requested data (e.g., the I / O switch 210 corresponding to the publishing node 220q) will have a record corresponding to the requested data and its publishing node 220q, and will respond to the I / O switch 205 corresponding to the requesting node 215a, and the I / O switch 105 may create and store a corresponding record for the requested data on the requesting node 215a. In this manner, a traversal route for the requested data from the publishing node 220q to the subscribing node 215a via the I / O switches 210, 205 may be established.

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

[0107] Real-time virtual control and associated operations

[0108] As described above, the virtual nodes 30x can virtualize the behavior of various physical components that can operate in the physical factory environment 15. In addition, due to the characteristics of the MPDSC platform 10, the virtualized components 30x of the virtual factory environment 12 can operate in conjunction with the physical components of the physical factory environment 15 to perform real-time control of the industrial process plant during runtime to generate physical products from raw materials. Figure 1 , Figure 2 and Figure 3For illustration purposes, the process controller 110 can be virtualized as a virtual node 30a with architecture 52a. In this way, 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 and executes the corresponding control module or routine 118 during runtime, which can include sending signals to and receiving signals from various field devices disposed within the physical environment 15 via the I / O switch 25.

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

[0110] In another example, during the runtime of the industrial process plant 100, the virtual controller 110 / 30a can receive data generated by the wireless field device 142a. In this example, the physical wireless field device 142a is in Figure 1is represented by the physical node PNa, and the physical wireless gateway 168 is represented by PN 40c. The wireless gateway PN 40c receives the payload data generated by the wireless field device PNa. Since PN 40c is a node of the virtual communication network 45, PN 40c publishes to the I / O switch 25 the payload data generated by the wireless field device PNa that the I / O switch 25 has subscribed to. In turn, the I / O switch 25 can publish the payload data generated by the field device PNa to the virtual node 30b, where the virtual node 30b is configured as a representation of an I / O device such as the I / O device 115. The virtual I / O device 30b has subscribed to the payload data generated by the field device PNa and forwarded by the I / O switch 25. In this way, the virtual I / O device 30b obtains the payload data generated by the wireless field device PNa through its subscription, and republishes the obtained payload data generated by the field device PNa to the I / O switch 25 for forwarding to the appropriate subscribers. The I / O switch 25 can in turn publish the obtained payload data of the field device PNa published by the virtual I / O device 30b to its corresponding subscribers, which (in this example) includes the virtual controller 30a. After receiving the payload data via subscription to the payload data at the virtual controller 30a, the CBM 58a (e.g., control module / routine 118) of the virtual controller 30a can operate on the payload data generated by the wireless field device PNa. The CBM 58a can generate output payload data to be passed through the virtual communication network 45 to another virtual or physical node.

[0111] The virtualization of the physical components of an industrial process plant provides many benefits over an industrial process plant implemented entirely using physical components. The virtualized components allow the industrial process plant to flexibly scale up and / or down the size and quantity of the components with minimal change to the hardware footprint and reduced installation costs. Since virtual nodes can represent all or only a part of a physical device, control can be easily scaled, for example, across multiple virtual nodes as needed. Additionally, for example, the MPDSC platform 10 provides I / O flexibility through the abstraction of I / O, such that the controller has less dependence on the actual configuration and the allocation of downloaded I / O modules. That is, at least due to the I / O switch 25, the I / O binding decisions between physical I / O devices and controllers and field devices can be eliminated. Furthermore, through the use of virtual physical components, software upgrades to the virtualized physical components can be easily achieved. Even further, through the use of the MPDSC platform 10, the simulation and online testing of the behavior of physical components are also easily achievable and improved over currently known techniques.

[0112] Virtualization management node

[0113] Figure 5 It is an example of support Figure 1 A block diagram of an exemplary architecture for configuration, commissioning, management, and governance of an MPDSC system 10. For the sake of clarity and not for the purpose of limitation, reference is also made herein to Figures 1 - 4 Let's discuss Figure 5 .like Figure 5 As shown, a virtualization management node 300 (interchangeably referred to herein as "VMN 300" or "virtual node 300") creates, configures, and manages virtualized components of the MPDSC system 10, such as the I / O switch 25, various virtual nodes 30x, virtual PIO subsystem 60, publish / subscribe layers 32x, 35, 38, 42x, etc. The VMN 300 automatically performs at least some of the creation, configuration, and management of the virtual components. Additionally or alternatively, the VMN 300 performs at least some of the creation, configuration, and management of the virtual components based on manual instructions (e.g., manual instructions received via a user interface 302 of the VMN 300), which can be a local or remote user interface. In addition, the virtualization management node 300 drives and / or coordinates simulation activities of the virtual process environment 12, which can be performed during simulation with and / or without online user input, as described in more detail below.

[0114] Configuration, governance and management of virtual components

[0115] In an embodiment, during configuration and / or commissioning of the virtual environment 12 and its components, the VMN 300 accesses the system configuration database of the plant (e.g., the VMN 300 accesses the configuration database 172b of the plant 100 via the data highway 108), and based on the configuration obtained, the VMN 300 determines the type and quantity of virtual nodes, virtual templates and / or subsystems, I / O switches and / or other virtual components that best support (or are expected to support) the plant configuration. The VMN 300 creates various types and quantities of virtual nodes 30x, and configures the I / O switches 25 and virtual nodes 30x to communicate via the virtual communication network 45 (e.g., via the corresponding publish / subscribe layer 32x and, for certain VNs 30x, via the virtual PIO subsystem 60). For certain plant configurations, the VMN 300 can create instances of the publish / subscribe layer 42x (and, optionally, instances of the virtual PIO subsystem 60) and dispatch them to various physical components 40x of the physical plant environment 15. In this way, the VMN 300 can create, configure, and manage any number of nodes 25, 28, 30x, 40x of a virtual communication network 45, which may include virtual components that operate in conjunction with physical components of a physical plant to perform real-time control and / or dynamic simulation.

[0116] 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 can be locally stored in the virtual environment configuration database 305. In some implementations, the master version of the configuration of the virtual factory environment 12 is stored in the system configuration database 172b (along with the configuration of the physical factory environment 15), and a copy of the master configuration of the virtual factory environment 12 is locally stored in the virtual environment configuration database 305. In some implementations, the master version of the configuration of the virtual factory environment 12 is stored in the virtual environment configuration database 305, and a copy of the master configuration of the virtual factory environment 12 is stored in the system configuration database 172b (along with the configuration of the physical factory environment 15). The VMN 300 coordinates 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.

[0117] When the factory 100 performs operation process control during the runtime of the process factory 100, the VMN 300 can monitor the I / O switch 25, the virtual nodes 30x, the virtual communication network 45, and any associated nodes (such as the physical nodes 40x, 28) regarding, for example, the resource loading situation, resource availability, resource bandwidth, occurrence of faults, and other performance issues of the hardware and / or software resources provided by the physical computing platform that supports the virtual environment 12 (e.g., the platform of the hardware computing devices that support the virtual environment 12). Based on the detected conditions and / or predicted conditions, the VMN 300 can automatically perform mitigation actions (such as adjusting resource allocation, activating standby virtual nodes, creating and / or deleting virtual nodes, etc.) during the runtime operation, for example, for load balancing, fault recovery, and other performance purposes. As an example, the VMN 300 can analyze performance bottlenecks and perform automatic balancing operations to mitigate any detected bottlenecks. For example, the VMN 300 can perform automatic balancing at the process data level in response to the virtual network traffic on the virtual communication network 45, and / or the VMN 300 can perform automatic balancing at the physical computing device level, such that the CPU and / or physical network utilization is balanced across the physical computing devices, physical data links, and / or physical networks on which the virtual environment 12 is implemented.

[0118] In terms of management, the VMN 300 can perform operations such as saving, snapshotting, backing up, migrating, and restoring various virtual nodes, virtual templates, subsystems, and associated process data. Moreover, the VMN 300 can perform operations such as saving, snapshotting, backing up, migrating, and restoring the entire virtual environment 12 itself. In an embodiment, each management action performed by the VMN 300 can be applied to all of the logic simulated by an object (subject) virtual node (e.g., all of the logic performed by the collective set of CBMs 58 of the object virtual node). For example, when creating and saving a snapshot of a virtual controller, the VMN 300 can not only save the data received, operated on, generated, and indicated by the virtual controller, as well as its interconnections and operational states, but the VMN 300 can also save the associated data of the modules executed in conjunction with the virtual controller as part of the snapshot, even if such modules are hosted on other nodes and / or simulate other physical components. In another example, when creating and saving a snapshot of a virtual CIOC, the VMN 300 can save the data corresponding to the virtual machine level of the virtual CIOC, and / or the VMN 300 can save the process simulation values observed by the virtual CIOC.

[0119] Dynamic simulation

[0120] As described above, the MPDSC system 10 supports the dynamic simulation of the entire process plant 100 and / or portions thereof. For example, the MPDSC system 10 provides real-time simulation, where the real-time simulation mirrors at least part of the runtime timing, values, and / or other behaviors of the corresponding physical components and / or physical operation processes. As used herein, the terms "simulation" and "simulation run" are used interchangeably, and a simulation or simulation run is bounded. That is, each simulation or simulation run has a corresponding start and a corresponding end, which may need to be defined, for example, based on time, parameter values, states, user commands, and / or other criteria.

[0121] In addition, the MPDSC system 10 provides control over simulations, such as accelerating or decelerating the speed of simulation execution, pausing the simulation, inserting and / or modifying various values, changing initial conditions, etc. 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 combination with one or more physical components (e.g., the configuration of a controller simulated by a virtual node in the virtual environment 12 can communicate with a physical field device located in the physical environment 15 to test the behavior of the simulated controller). 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, study process improvements, conduct operator training, perform case studies, etc. The VMN 300 manages, coordinates, and drives the simulation activities supported by the MPDSC system 10.

[0122] In particular, the VMN 300 creates, configures, and manages virtual nodes 25, 30x, and other virtual components 28, 32, 35, 38, 42x, 60 that simulate at least a portion of the simulated physical plant 100. Virtual nodes 25, 30x that are only used for simulation purposes (as opposed to runtime control purposes) are interchangeably referred to herein as "simulation nodes". For example, the VMN 300 can generate a mirror simulation system of the entire runtime control system described by the plant configuration database 172b, such as by using simulation nodes that simulate integrated physical hardware components, such as controllers 110, workstations 170a, and / or other physical devices, and their corresponding network interconnections (in some implementations, down to the MAC address level). In another example, the VMS 300 can generate corresponding simulations of one or more individual physical components, each of which can be executed in stand-alone mode or in combination with one or more other simulated, virtual, and / or physical components. For example, the VMS 300 can generate a virtual twin of a physical component currently operating within the physical environment 15 within the virtual environment 12, such as to test new control configurations, upgrades, patches, etc. to be applied to the physical component. In another example, the VMS 300 can generate a simulation of the MAC address level behavior of a particular physical component. In yet another example, the VMS 300 can generate a single (e.g., solitary) simulation 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).

[0123] Regarding the types of data values used within the virtual environment 12 and the physical environment 15 of the process control system 100, in an 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) to simulate for use within the process plant 100, and the VMS 300 assigns corresponding data tags (e.g., identifiers) to the data values (and / or their types) to be simulated. For example, the VMS 300 can automatically assign data tags to at least some of the data values and / or data types to be simulated, and / or the VMS 300 can receive, for example via the user interface 302, manually generated data tags for at least some of the data values and / or data types to be simulated. The assigned data tags for the simulated data values and / or data types can be stored in the virtual environment configuration database 305 and / or the system configuration database 172b.

[0124] Additionally, the VMN 300 drives and / or coordinates the simulation of the entire physical plant 100 and / or portions thereof. To this end, the virtual environment 12 provides a simulator API (Application Programming Interface) 310 or other suitable access mechanism, via which applications such as the user interface 302, the IT layer application 21x, and / or third-party or external applications 22x can interface with the virtual environment 12 for simulation purposes. In an embodiment, the VMN 300 or other computing device within the virtual environment 12 hosts the simulator API 310 and / or exposes the simulator API 310 to other applications.

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

[0126] The simulator API 310 is configured with the names, data tags, identifiers, data definitions, channel data, etc. of the simulation components within the virtual environment 12 (e.g., based on 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 communication / data protocols, which may be standardized protocols such as OPC, Ethernet, IPv6, etc. Thus, the simulator API 310 serves as a data transfer and transmission mechanism between the simulation components within the virtual environment 12 and other applications 302, 21x, 22x, which are consumers and / or providers of simulation data and use one or more industrial and / or general communication / data protocols. For example, a third-party simulation application can use the simulator API 310 to inject test values for use by the simulation components, change the initial conditions of the simulation run, etc.

[0127] Additionally or alternatively, the simulator API 310 processes simulation commands provided via the user interface 302 and / or by other applications 21x, 22x. For example, the simulator API 310 can receive simulation commands to speed up and / or slow down the execution of modules (where at least some are simulated within the virtual environment 12) and / or speed up and / or slow down the I / O processing, and can drive the timing and actions of the associated simulation nodes 30x, 28, and / or the virtual communication network 45 accordingly. In another example, the simulator API 310 can receive simulation commands to inject and / or change various data values during the simulation. Additionally, the simulator API 310 can receive management simulation commands to, for example, save snapshots, obtain saved snapshots, restore from saved data, etc., and can perform corresponding actions in response. For example, the simulator API 310 can receive and respond to simulation commands to save, obtain, restore the 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), etc., and save, obtain, restore the simulation of one or more nodes or components of the process plant 100, etc.

[0128] Generally speaking, the simulation API 310 is stateful. That is to say, when the simulation is executed, the simulation API 310 knows the various states of the simulation and the components associated therewith (for example, virtual, physical, and / or simulated devices; virtual, physical, and / or simulated modules; other types of virtual, physical, and / or simulated components; the process at least partially simulated by the simulation; the overall state of the simulation; etc.), and responds to the received commands based on the various states. For example, in response to a save command, the simulation API 310 may save the process data together with the data indicating the state of the associated components. In another example, when simulating a modified control module executed within a controller for testing purposes, the simulation API 310 may allow the user to change the state of the associated module to determine how the modified control module will respond to different states of the associated module.

[0129] Figure 6 is a flowchart of an exemplary method 400 for managing a virtual environment of an industrial process plant. In an embodiment, the method 400 may be performed at least in part by a virtualization management node such as Figure 5 the virtualization management node 300. Additionally or alternatively, at least a portion of an embodiment of the method 400 may be performed by: Figure 1 one or more parts of a multi-purpose dynamic simulation and runtime industrial or process control (MPDSC) system or platform 10 such as Figure 2 one or more parts of an embodiment of virtual nodes 52a, 52b; Figure 3 one or more parts of an embodiment of a physical plant environment 100 and / or any one or more of its components; Figure 4 one or more parts of an embodiment of an I / O switch arrangement 200; and / or Figure 5 one or more parts of an embodiment of the virtualization management node 300. For purposes of illustration and not limitation, the method 400 is described herein with reference to Figures 1 - 5 parts. Additionally, in an embodiment, in addition to the steps described herein, the method 400 may include more, fewer, and / or alternative steps.

[0130] As Figure 6 shown, the method 400 includes, at block 402, accessing one or more system configuration databases of an industrial process plant, wherein the one or more system configuration databases store at least one configuration of the physical environment of the industrial process plant. The method 400 further includes, at block 405, obtaining information indicating at least one configuration of the industrial process plant based on the access.

[0131] At block 408, method 400 includes automatically determining, based on the obtained configuration information, the number of virtual nodes (e.g., one or more virtual nodes) and / or the corresponding types of virtual nodes required to support at least one configuration of the industrial process plant. In some embodiments, method 400 also determines one or more virtual templates, one or more virtual subsystems, and / or one or more other virtual components of the virtual environment based on the obtained configuration information.

[0132] In some embodiments, block 408 includes automatically determining the corresponding configurations of one or more virtual nodes based on the obtained configuration information and storing the corresponding configurations of the one or more virtual nodes in a virtual environment configuration database. The virtual environment configuration database may be included in one or more system configuration databases, which are generally (but not necessarily) not included in the virtual environment, and / or the virtual environment configuration database may be locally included within the virtual environment. As described above, when instances of the virtual environment configuration database are stored in the virtual environment and stored together with one or more system configuration databases, one of these instances may be the primary virtual configuration database, and another of these instances may be a copy of the primary virtual configuration database. For example, these instances may be synchronized, and change management of data may be performed between the two instances.

[0133] At block 410, method 400 includes creating one or more virtual nodes within the virtual environment of the industrial process plant. For example, the one or more virtual nodes may include at least one virtual runtime node and / or at least one simulation node. In some embodiments, block 410 may include creating at least some of the one or more virtual nodes based on one or more virtual templates and / or one or more virtual subsystems, e.g., as created at block 408. Creating the one or more virtual nodes (block 410) may include creating a corresponding publish / subscribe layer for each of the one or more virtual nodes. For some of the one or more virtual nodes, block 410 may include creating a corresponding virtual process I / O (PIO) subsystem.

[0134] In some arrangements, method 400 also includes creating a corresponding publish / subscribe layer for one or more physical devices and / or components disposed within the physical environment of the industrial process plant and assigning the corresponding publish / subscribe layer to the one or more physical devices and / or components.

[0135] At block 412, method 400 includes configuring an I / O switch to communicatively interconnect one or more virtual nodes, e.g., via respective publish / subscribe layers of the I / O switch and the one or more virtual nodes. In some embodiments, method 400 further includes configuring the I / O switch to communicatively interconnect one or more physical nodes disposed in a physical environment of an industrial process plant and virtual environments and / or components disposed in a virtual environment, e.g., via associated publish / subscribe layers. For example, the I / O switch may communicatively connect a physical node disposed in the physical environment and a virtual runtime node disposed in the virtual environment, both of which are included in a process control loop of the industrial process plant, e.g., as defined in a system configuration database of the industrial process plant, where the process control loop operates during runtime of the plant to control at least a portion of the industrial process.

[0136] In some embodiments of block 412, method 400 may include configuring multiple I / O switches. For example, block 408 may include determining, e.g., based on the obtained configuration information, that multiple I / O switches are needed to support at least one configuration of the industrial process plant, and thus, block 412 may include configuring multiple I / O switches. In some implementations, block 410 may include creating at least some of the multiple I / O switches.

[0137] At block 415, method 400 includes initializing one or more virtual nodes and the I / O switch to form a virtual communication network in the virtual environment of the industrial process plant. In some embodiments, block 415 may further include initializing the I / O switch and any physical nodes communicatively connected to the virtual environment via the I / O switch.

[0138] In some embodiments, method 400 optionally includes monitoring one or more components of the virtual environment (block 418), e.g., when one or more virtual components are executing during runtime operation of the industrial process plant. For example, at block 418, method 400 may include monitoring at least one of the following: resource load, resource availability, resource bandwidth, occurrence of faults, or another type of hardware and / or software performance issue of the physical computing platform supporting the virtual environment. Block 418 may optionally include automatically performing mitigation actions based on the monitoring, e.g., adjusting resource allocation, activating standby virtual nodes, creating another virtual node, deleting one of the one or more virtual nodes, automatically balancing the load among the one or more virtual nodes, automatically balancing data processing of at least some of the one or more virtual nodes based on network traffic on the virtual communication network, automatically balancing physical network utilization across multiple physical computing devices, multiple physical data links, and / or multiple physical networks of the physical computing platform supporting the virtual environment, etc.

[0139] In some embodiments, method 400 optionally includes managing any virtual components of the virtual environment (e.g., virtual runtime nodes, simulation nodes, virtual communication networks, I / O switches, and / or other virtual components) (block 420). Managing the virtual components can include saving relevant data, saving snapshots of the corresponding states and / or operations, backing up one or more virtual components, restoring one or more virtual components from the backup, migrating one or more virtual components to another part of the virtual environment and / or to another part of the physical computing platform that supports the virtual environment, etc. Managing the virtual components (block 420) can be performed automatically and can be performed based on input from another application (e.g., a user interface application, a third-party application, or another application).

[0140] Accordingly, in view of the foregoing, the novel multi-purpose platform and runtime control platform 10 for dynamic simulation provides numerous benefits and advantages over known process control systems. For example, since the MPDSC platform 10 supports both simulation and runtime control through virtual components, tests for changes (e.g., upgrades, patches, etc.) can be performed on the simulation components in the virtual environment 12, and after satisfactory checks, the simulation components can be easily activated as virtual components of the process plant 100 (e.g., "load, evaluate, run", seamless or hot switching, etc.). In this way, the switching from simulation components to runtime components can be accomplished more easily, and the downtime due to upgrades, patches, and scheduled maintenance is reduced. In addition, the amount of resources used to provide virtual hot spares for various components and to bring the virtual hot spares online in case of failures or errors is also significantly reduced.

[0141] Furthermore, providing runtime virtual components by the MPDS platform 10 allows for independence between the hardware and software within the plant 100. For example, the controller software used during the runtime of the process control system 100 can be upgraded in the runtime virtual controller without upgrading or changing any physical controller hardware. Similarly, due to the hardware / software independence, the MPDS platform 10 allows the hardware of the process plant 100 to be upgraded independently of software upgrades.

[0142] In addition, providing runtime virtual components and their governance and / or management (e.g., through the VMS 300 of the MPDSC platform 10) also allows for simple and lower-cost system scalability, since additional virtual components can be easily implemented in the virtual environment 12 without having to pay for, install, test, debug, and inspect different physical hardware components and the required cabinets, wiring, etc. In fact, when additional virtual components are needed to support the system 100, virtual components can be created as needed until the processing and / or memory limits of the physical computing devices and / or hardware on which the virtual environment 12 is implemented, after which additional physical computing devices and / or hardware can be simply added to it.

[0143] The virtual environment 12 provided by the MPDS platform 10 enables the creation of digital twins of individual components and / or virtual simulation of the entire process plant 100, for example, for testing, hot spares, upgrades, patches, scheduled maintenance, and / or other purposes. The digital twins (e.g., digital twins of specific components and the entire process plant 100) can be updated in a lock-step manner 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 cases, incorporates the runtime virtual and / or physical components of the process plant 100. Since the general MPDS platform 10 (especially the virtual environment 12 of the MPDS platform 10) is built for both simulation and runtime control purposes, off-simulation can be easily accomplished without any configuration changes.

[0144] In addition, since the MPDS platform 10 abstracts the I / O of the process plant from the specific direct association of I / O with specific hardware, the I / O configuration in the plant 100 is more flexible and is easy to change and adapt not only during runtime but also during upgrades, maintenance, faults, etc. Importantly, the communication connections between I / O devices and other components (such as CIOCs and controllers) are no longer limited by the physical ports available on the physical I / O devices. When I / O is abstracted within the MPDS platform 10, any number of communication connections between virtual I / O devices and other components are logically possible, up to the processing and / or storage limitations of the physical computing device and / or hardware on which the virtual environment 12 is implemented, after which additional physical computing devices and / or hardware can simply be added to it. Similarly, due to the abstraction of I / O within the MPDS platform 10, control modules and / or other CBMs 58 can be assigned to any virtual host device or component without concern for the I / O location and / or loading of the host device or component, which is required when using physical host devices or components. That is, as previously mentioned, virtual components (whether for simulation or for runtime control purposes) can operate using I / O from physical components or other virtual components. In this way, the MPDS platform 10 is able to abstract (e.g., by utilizing the I / O switch 25) redundancy, retry, and other mechanisms currently associated with specific implementations within the current state of the art, so that the abstractions can be utilized across a variety of different types of applications, scenarios, and implementations, for example, for selected customization and specialization of the various abstractions for a specific implementation and / or application. Therefore, the MPDS platform 10 is able to support a greater number and type of I / O systems (compared to current state-of-the-art technologies) in a consistent and easily extensible manner.

[0145] When implemented in software, any application, service, virtual device, vertical machine, virtual entity, 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, on the storage medium, in the RAM or ROM of a computer or processor, and so on. Although the exemplary systems disclosed herein are disclosed as including software and / or firmware executed on hardware in addition to other components, it should be noted that such systems are merely illustrative and should not be considered limiting. For example, it is contemplated that any one or all of these hardware, software, and firmware components can be embodied solely in hardware, solely in software, or in any combination of hardware and software. Thus, although the exemplary systems described herein are described as being implemented in software executed on a processor of one or more computer devices, those of ordinary skill in the art will readily understand that the examples provided are not the only way to implement such systems.

[0146] Accordingly, although the invention has been described with reference to specific examples, these specific examples are for illustrative purposes only and not for limiting the invention, but it will be apparent to those of ordinary skill 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. A system for an industrial process plant, the system comprising: A process control system, the process control system including a plurality of virtual nodes disposed in a virtual environment of the industrial process plant, a plurality of physical nodes disposed in a physical environment of the industrial process plant, and an I / O switch communicatively disposed between the plurality of virtual nodes and the plurality of physical nodes to transmit data between the plurality of virtual nodes and the plurality of physical nodes via publish and subscribe when at the I / O switch, the plurality of virtual nodes including a plurality of virtual process controllers, and the plurality of physical nodes including field devices, the virtual process controllers and the field devices being included in a process control loop that is executed during runtime operation of the industrial process plant to control at least a portion of an industrial process; And A virtualization management node, the virtualization management node performing the following operations: Create and configure each virtual node in at least one of the plurality of virtual nodes to have a corresponding instance of a publish / subscribe layer; Configure the I / O switch to have a corresponding instance of a publish / subscribe layer, the I / O switch maintaining a set of records indicating corresponding publishers of corresponding I / O data and corresponding subscribers of the published corresponding I / O data; And Manage the plurality of virtual nodes of the process control system during the runtime operation of the industrial process plant, during which the I / O switch and each virtual node utilize the corresponding instances of the publish / subscribe layer to transfer data between each virtual node and the I / O switch via corresponding publishes and corresponding subscribes to control the industrial process, including the I / O switch utilizing the corresponding instance of the publish / subscribe layer of the I / O switch to obtain a first publish of a control signal based on the set of records and a subscription by the I / O switch to a publish of the control signal generated by the virtual process controller, and based on the obtained first publish and the set of records, publishing a second publish indicating the control signal, such that the field device obtains the control signal via the second publish based on a selected subscription node's subscription to the publish of the control signal indicated by the I / O switch to control the at least a portion of the industrial process, wherein the selected subscription node is configured to have a corresponding instance of a publish / subscribe layer and is a physical node communicatively connected to the field device.

2. The system according to claim 1, wherein: The plurality of virtual nodes includes at least one virtual runtime node, and the at least one virtual runtime node further includes at least one of the following: another virtual process controller, a virtual safety controller; a virtual safety logic solver; a virtual I / O card, device, or node; a virtual wireless device; a virtual Ethernet device; a virtual operator workstation; a virtual user interface device; a virtual tool; a virtual gateway; a virtual electronic marshalling cabinet or system; or virtualization of another type of physical device or component disposed within the physical environment of the industrial process plant; and The plurality of physical nodes includes at least one of the following: a process controller; a safety controller; a safety logic solver; an I / O node, card, or device; a wireless device; another field device; an Ethernet device; an operator workstation; a user interface device; a tool; a gateway; an electronic marshalling cabinet; a network connection; or another type of physical device or component disposed within the physical environment of the industrial process plant.

3. The system according to any one of the preceding claims, wherein: The process control loop uses an I / O switch in place of any physical I / O device.

4. The system according to any one of claims 1-2, wherein, The virtualization management node manages the plurality of virtual nodes in response to one or more conditions of a physical computing platform that supports the virtual environment of the industrial process plant, the physical computing platform including one or more computing devices.

5. The system according to claim 4, wherein The one or more conditions corresponding to the physical computing platform that supports the virtual environment include at least one of the following: the occurrence of a fault, the corresponding usage of one or more resources of the physical computing platform, the corresponding loading of the one or more resources, the corresponding availability of the one or more resources, the corresponding bandwidth of the one or more resources, the corresponding metrics of the performance of the one or more resources, the corresponding state of the one or more resources, or another type of condition of at least a portion of the physical computing platform.

6. The system according to claim 5, wherein The one or more resources of the physical computing platform include at least one of the following: hardware resources or software resources.

7. The system according to any one of claims 1-2, wherein, The management of the plurality of virtual nodes by the virtualization management node includes at least one of the following: deletion of a specific virtual node included in the plurality of virtual nodes, creation of another virtual node, activation of a standby virtual node, reallocation of resources, or another management action.

8. The system according to any one of claims 1-2, wherein, The management of the plurality of virtual nodes by the virtualization management node includes the management of a specific virtual node by the virtualization management node, and the management of the specific virtual node includes at least one of the following: storing the corresponding configuration of at least a portion of the specific virtual node, storing runtime data corresponding to at least a portion of the specific virtual node, storing simulation data corresponding to at least a portion of the specific virtual node, storing the state of at least a portion of the specific virtual node, or storing other data corresponding to at least a portion of the specific virtual node.

9. The system according to claim 8, wherein, The management of the specific virtual node performed by the virtualization management node further includes: restoring at least a part of the specific virtual node from the stored data accordingly.

10. The system according to claim 1, wherein: The multiple virtual nodes of the process control system include multiple virtual runtime nodes; The system further includes a simulation system disposed in the virtual environment of the industrial process plant, The simulation system includes the I / O switch and another multiple virtual nodes, and the another multiple virtual nodes include one or more simulation nodes, Each of the one or more simulation nodes simulates at least a part of one or more physical devices or components that can be deployed in the physical environment of the industrial process plant, and The one or more physical devices or components include at least one of the following: Process controller; safety controller; safety logic solver; I / O node, card or device; wireless device; Ethernet device; operator workstation; user interface device; tool; gateway; Electronic marshalling cabinet; network connection; or another type of physical device or component disposed within the physical environment of the industrial process plant; and The virtualization management node manages the simulation system.

11. The system according to claim 10, wherein, The at least a part of the one or more physical devices or components simulated by each simulation node includes a part of a specific physical device or component, and the part of the specific physical device or component includes at least one of the following: a module, routine, function or behavior, MAC address, or hardware sub-component of the specific physical device or component.

12. The system according to any one of claims 10-11, wherein, A single integrated simulation node simulates multiple physical devices or components that can be deployed to operate together during the runtime operation of the industrial process plant.

13. The system according to any one of claims 10-11, wherein, The one or more simulation nodes include multiple simulation nodes that operate together to simulate the functions or behaviors of the runtime operation of the industrial process plant.

14. The system according to any one of claims 10-11, wherein: The simulation system performs a simulation run including a specific simulation node among the one or more simulation nodes; The simulation run includes communication between the specific simulation node and at least one of the following: a specific virtual runtime node of the process control system, or a specific physical node of the process control system; and At least one of the specific virtual runtime node or the specific physical node is configured to operate during the runtime operation of the industrial process plant.

15. The system according to claim 14, wherein: The specific simulation node includes a corresponding component behavior module; and The virtualization management node causes the corresponding component behavior module of the specific simulation node to be downloaded into the corresponding physical node disposed in the physical environment of the industrial process plant after the simulation run is completed.

16. The system according to claim 15, wherein The virtualization management node causes the corresponding component behavior module of the specific simulation node to be downloaded into the corresponding physical node after the approved simulation run is completed.

17. The system according to claim 10, wherein, The simulation system further includes a simulator access mechanism through which an application provides and / or receives one or more simulation values used in a simulation run executed by the simulation system.

18. The system according to claim 17, wherein, The simulator access mechanism includes an application programming interface.

19. The system according to claim 17, wherein, The simulator access mechanism interfaces with the I / O switch to provide and / or receive the one or more simulation values.

20. The system according to claim 17, wherein, The simulator access mechanism is configured to communicate with the application via a standardized data or communication protocol.

21. The system according to claim 17, wherein, The simulator access mechanism uses the respective identifiers of the one or more simulation nodes stored in the system configuration database of the industrial process plant, and the system configuration database of the industrial process plant stores at least one physical configuration of the industrial process plant.

22. The system according to claim 17, wherein The simulator access mechanism is configured to operate on one or more simulation commands to perform at least one of the following: execute the simulation run at a runtime speed, accelerate the simulation run to execute at a speed faster than the runtime speed, slow down the simulation run to execute at a speed slower than the runtime speed, set the simulation values of the simulation run, set the initial conditions of the simulation run; pause the simulation run, set the intermediate conditions of the simulation run, modify the speed of execution of the simulation, or modify the simulation values associated with the simulation run, save or store data associated with at least a portion of the simulation run, obtain at least a portion of the saved or stored simulation run, save or store the configuration of the simulation run, or obtain the saved or stored configuration of the simulation run.

23. The system according to claim 17, wherein At least one simulation command to which the simulator access mechanism responds is provided via a user interface.

24. The system according to claim 17, wherein, At least one simulation command to which the simulator access mechanism responds is provided via a third-party application.

25. The system according to claim 17, wherein The simulator access mechanism maintains one or more states respectively associated with the respective portions of the simulation run.

26. The system according to claim 25, wherein, The one or more states correspond to at least one of the following: the state of a virtual component, the state of a physical component, the state of a simulation component, the state of a virtual device, the state of a physical device, the state of a simulation device, the state of a virtual module, the state of a physical module, the state of a simulation module, the state of a process at least partially simulated by the simulation run, or the state of the simulation run.

27. The system according to any one of claims 17-26, wherein, The simulator access mechanism is provided by the virtualization management node.

28. The system according to any one of claims 10-11 or 17-26, wherein, The simulation system operates during the runtime operation of the industrial process plant.

29. The system according to any one of claims 10 - 11 or 17 - 26, wherein, The simulation system interfaces with the process control system during the runtime operation of the industrial process plant.

30. The system according to any one of claims 1-2 or 10-11 or 17-26, wherein The virtualization management node interfaces with one or more other applications on behalf of the virtual environment.

31. The system according to claim 30, wherein, The one or more applications include at least one of the following: a user interface application, an application executed in an information technology (IT) layer associated with the industrial process plant, an application executed in an operational technology (OT) layer of the industrial process plant, an Internet of Things (IoT) application, an Industrial Internet of Things (IIoT) application, an application executed in a computing cloud, an application communicatively connected to the virtualization management node via one or more public networks, or a third-party application.

32. The system according to claim 30, wherein, The one or more applications include at least one of the following: a diagnostic application, a data historian application, a system-level health monitoring application, a user interface application, or an application executed on a mobile device.

33. The system according to any one of claims 1-2 or 10-11 or 17-26, wherein The virtualization management node automatically manages at least a portion of the plurality of virtual nodes of the process control system and any other virtual nodes disposed in the virtual environment of the industrial process plant without any online user input.

34. The system according to claim 33, wherein, The virtualization management node automatically manages all of the plurality of virtual nodes of the process control system and any other virtual nodes disposed in the virtual environment of the industrial process plant without any online user input.

35. The system according to claim 33, wherein The virtualization management node automatically performs at least a portion of the creation, configuration, and management of the plurality of virtual nodes and any other virtual nodes without any online user input.

36. The system according to claim 35, wherein, The virtualization management node automatically performs all of the creation, configuration, and management of the plurality of virtual nodes and any other virtual nodes without any online user input.

37. A method for managing a virtual environment of an industrial process plant at a virtualization management node, the method comprising: accessing, by the virtualization management node, one or more system configuration databases of the industrial process plant, the one or more system configuration databases storing one or more configurations of a physical environment of the industrial process plant; obtaining, based on the access, by the virtualization management node, information indicative of at least one configuration of the industrial process plant; automatically determining, by the virtualization management node based on the obtained configuration information, a number and / or a corresponding type of virtual nodes to support the at least one configuration of the industrial process plant, the virtual nodes being a plurality of virtual nodes including virtual process controllers; creating, by the virtualization management node, the plurality of virtual nodes within the virtual environment of the industrial process plant, including configuring each of the plurality of virtual nodes to have a respective instance of a publish / subscribe layer; The virtualization management node configures an I / O switch to communicatively interconnect the multiple virtual nodes and one or more physical nodes disposed in a physical environment of the industrial process plant, the one or more physical nodes including field devices, the field devices and the virtual process controller being included in a process control loop that is executed during runtime operation of the industrial process plant to control at least a portion of an industrial process, and configuring the I / O switch includes configuring the I / O switch to have a corresponding instance of a publish / subscribe layer, the I / O switch maintaining a set of records indicating corresponding publishers of corresponding I / O data and corresponding subscribers of the published corresponding I / O data; and The virtualization management node initializes the multiple virtual nodes and the I / O switch, thereby forming a virtual communication network in the virtual environment of the industrial process plant via the I / O switch and the corresponding instances of the publish / subscribe layer of each virtual node, the multiple virtual nodes and the I / O switch using the virtual communication network to transfer data between the multiple virtual nodes and the I / O switch via corresponding publishing and subscribing to control the industrial process, including the I / O switch using the corresponding instance of the publish / subscribe layer of the I / O switch to obtain a first publication of a control signal based on the set of records and the I / O switch's subscription to the publication of the control signal generated by the virtual process controller, and based on the obtained first publication and the set of records, publishing a second publication indicating the control signal, thereby enabling the field device to obtain the control signal via the second publication based on a selected subscription node's subscription to the publication of the control signal indicated by the I / O switch to control the at least a portion of the industrial process, wherein the selected subscription node is configured to have a corresponding instance of a publish / subscribe layer and is a physical node communicatively connected to the field device.

38. The method according to claim 37, wherein, The virtual process controller is a virtual runtime node, and the method further includes creating at least one other virtual runtime node, and wherein initializing the multiple virtual nodes includes: initializing the at least one other virtual runtime node to operate in conjunction with at least one physical node disposed in the physical environment of the industrial process plant to control an industrial process during runtime operation of the industrial process plant.

39. The method according to claim 38, wherein, The at least one other virtual runtime node and the at least one physical node are included in a process control loop defined in one or more system configuration databases of the industrial process plant.

40. The method according to claim 37, Also includes: The virtualization management node automatically determines one or more virtual templates based on the obtained configuration information; and wherein creating the multiple virtual nodes includes: creating at least one virtual node based on the one or more virtual templates.

41. The method according to claim 37, Also includes: Automatically determine, by the virtualization management node, one or more virtual subsystems based on the obtained configuration information; And wherein, creating the multiple virtual nodes includes: creating at least one virtual node of at least one virtual subsystem among the one or more virtual subsystems.

42. The method according to claim 37, wherein, The I / O switch is a first I / O switch, and the method further includes: Automatically determine, by the virtualization management node, that the virtual communication network includes multiple I / O switches based on the obtained configuration information, the multiple I / O switches including the first I / O switch; and Configure, by the virtualization management node, the multiple I / O switches.

43. The method according to claim 37, further comprising: Create, by the virtualization management node, a corresponding virtual process I / O (PIO) subsystem for each of at least some of the multiple virtual nodes.

44. The method according to claim 37, further includes: Create, by the virtualization management node, a corresponding publish / subscribe layer for each of one or more physical nodes disposed in the physical environment of the industrial process plant; Assign, by the virtualization management node, the corresponding publish / subscribe layer to the one or more physical nodes; And Configure, by the virtualization management node, the I / O switch to communicatively connect the one or more physical nodes with the virtual environment of the industrial process plant via the corresponding publish / subscribe layer.

45. The method according to claim 37, further includes: Automatically determine, by the virtualization management node, the corresponding configurations of the multiple virtual nodes based on the obtained configuration information; And Store the corresponding configurations of the multiple virtual nodes in a virtual environment configuration database.

46. The method according to claim 45, further comprising: Create, by the virtualization management node, at least one other virtual component of the virtual environment of the industrial process plant, and store the corresponding configuration of the at least one other virtual component in the virtual environment configuration database.

47. The method according to claim 45, further comprising: Store the configuration of the virtual communication network in the virtual environment configuration database.

48. The method according to claim 45, wherein The virtual environment configuration database is included in the one or more system configuration databases of the industrial process plant.

49. The method according to claim 48, further includes: Store, by the virtualization management node, the virtual environment configuration database as a primary virtual environment configuration database in the one or more system configuration databases of the industrial process plant; And Store, by the virtualization management node, a copy of the primary virtual environment configuration database within the virtual environment of the industrial process plant.

50. The method according to claim 48, further includes: Store, by the virtualization management node, the virtual environment configuration database as a primary virtual environment configuration database within the virtual environment of the industrial process plant; And Store, by the virtualization management node, a copy of the primary virtual environment configuration database in the one or more system configuration databases of the industrial process plant.

51. The method according to any one of claims 49 - 50, further comprising: Synchronize, by the virtualization management node, the primary virtual environment configuration database with the copy of the primary virtual environment configuration database. The method according to any one of claims 49 - 50, further comprising: The virtualization management node coordinates the change management of data stored in one of the primary virtual environment configuration databases or the replicas of the primary virtual environment configuration database with the data stored in the other of the primary virtual environment configuration databases or the replicas of the primary virtual environment configuration database.

53. The method according to any one of claims 45 - 50, wherein: At least one of the virtual environment configuration database or the one or more system configuration databases stores a system process data simulation definition that defines a set of data values and / or a set of types of data values for simulation; The method further includes: the virtualization management node assigns corresponding data tags to the set of data values and / or the set of types of data values for simulation, and stores the assigned corresponding data tags in at least one of the virtual environment configuration database or the one or more system configuration databases; and The assigned corresponding data tags are used during a simulation run executed in the virtual environment of the industrial process plant.

54. The method according to claim 37, further comprising: When the industrial process plant operates during runtime to control an industrial process, the following are performed: The virtualization management node monitors at least one of the following: the I / O switch, the plurality of virtual nodes, the virtual communication network, any other virtual component of the virtual environment, or any physical node communicatively connected to the virtual environment via the I / O switch; and The virtualization management node automatically performs mitigation actions based on the monitoring.

55. The method according to claim 54, wherein, The monitoring includes monitoring at least one of the following: resource loading, resource availability, resource bandwidth, occurrence of a fault, or another type of hardware and / or software performance issue of the physical computing platform supporting the virtual environment.

56. The method according to any one of claims 54 - 55, wherein, Automatically performing the mitigation actions includes at least one of the following: adjusting resource allocation, activating standby virtual nodes, creating another virtual node, deleting one virtual node from the plurality of virtual nodes, or automatically balancing the load of the plurality of virtual nodes.

57. The method according to claim 56, wherein, Automatically balancing the load of the plurality of virtual nodes includes: automatically balancing the data processing of at least some of the plurality of virtual nodes based on network traffic on the virtual communication network.

58. The method according to claim 56, wherein, Automatically balancing the load of the plurality of virtual nodes includes: automatically balancing physical network utilization across a plurality of physical computing devices, a plurality of physical data links, and / or a plurality of physical networks of the physical computing platform supporting the virtual environment.

59. The method according to any one of claims 37-50 or 54-55 further comprises: The virtualization management node manages at least one of the following: the I / O switch, the plurality of virtual nodes, the virtual communication network, or any other virtual component of the virtual environment, and the management includes at least one of the following: Saving data associated with at least one of the following: the I / O switch, the plurality of virtual nodes, the virtual communication network, or any other virtual component of the virtual environment; Save a snapshot of the corresponding state and / or operations of at least one of: the I / O switch, the plurality of virtual nodes, the virtual communication network, or any other virtual component of the virtual environment; Back up at least one of: the I / O switch, the plurality of virtual nodes, the virtual communication network, or any other virtual component of the virtual environment; Migrate at least one of: the I / O switch, the plurality of virtual nodes, the virtual communication network, or any other virtual component of the virtual environment to another part of the virtual environment; or Restore at least a portion of at least one of: the I / O switch, the plurality of virtual nodes, the virtual communication network, or any other virtual component of the virtual environment from a corresponding backup.

60. The method according to claim 59, wherein, Manage at least one of: the I / O switch, the one or more virtual nodes, the virtual communication network, or any other virtual component of the virtual environment by the virtualization management node, including: managing the entirety of the virtual environment.

61. The method according to any one of claims 37 to 50 or 54 - 55, wherein: Creating the plurality of virtual nodes by the virtualization management node includes: creating one or more simulated nodes; Each of the one or more simulated nodes simulates at least a portion of one or more physical devices or components that can be deployed in the physical environment of the industrial process plant; and The one or more physical devices or components include 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; or another type of physical device or component disposed within the physical environment of the industrial process plant.

62. The method according to claim 61, wherein, The at least a portion of the one or more physical devices or components simulated by each simulated node includes a portion of a specific physical device or component, and the portion of the specific physical device or component includes at least one of: a module, routine, function, or behavior, a MAC address, or a hardware sub-component of the specific physical device or component.

63. The method according to claim 61 further comprises: Execute a simulation run including at least some of the one or more simulated nodes via the virtualization management node.

64. The method according to claim 63, wherein, Executing the simulation run includes: executing the simulation run to mirror the run-time timing, values, and / or other behaviors of at least a portion of the one or more physical devices or components simulated by at least some of the one or more simulated nodes.

65. The method according to claim 63 further comprises: Manipulate the simulation run, including at least one of: Speeding up the speed of the simulation run; Slowing down the speed of the simulation run; Pausing the simulation run; Inserting and / or modifying one or more values associated with the simulation run; or Changing the initial conditions associated with the simulation run.

66. The method according to claim 63, wherein, Performing the simulation run includes: performing the simulation run in combination with at least one physical node, the at least one physical node being disposed in the physical environment of the industrial process plant and communicatively connected to the virtual environment via the I / O switch.

67. The method according to claim 66, wherein, Performing the simulation run in combination with the at least one physical node includes: performing the simulation run in combination with the at least one physical node while the at least one physical node is operating during the runtime operation of the industrial process plant.

68. The method according to claim 63, wherein Performing the simulation run including at least some of the one or more simulation nodes includes: performing the entire simulation run of the process control system of the industrial process plant defined in the one or more system configuration databases of the industrial process plant, and the one or more simulation nodes collectively simulate the entire process control system.

69. The method according to claim 63, wherein: Performing the simulation run including at least some of the one or more simulation nodes includes: performing the simulation run of a set of simulation nodes, the set of simulation nodes simulating physical components operating within the physical environment of the industrial process plant during runtime, the set of simulation nodes being the virtual twin of the physical components; and The method further includes: after approving the performed simulation run, downloading the component behavior module executed by the virtual twin of the physical component into the physical component operating within the physical environment of the industrial process plant.

70. The method according to claim 61, wherein: The virtual environment provides a simulator access mechanism, and an application accesses the virtual environment via the simulator access mechanism for simulation; The simulator access mechanism is communicatively connected to the I / O switch; and The method further includes: based on the simulator access mechanism, performing the simulation run including at least some of the one or more simulation nodes.

71. The method according to claim 70, wherein, Performing the simulation run includes: transferring simulator runtime process data between at least some of the one or more simulation nodes and the simulator access mechanism.

72. The method according to claim 70, further comprising: The simulator access mechanism is hosted by the virtualization management node and exposed to the application.

73. The method according to claim 70, wherein The simulator access mechanism includes an application programming interface (API).

74. The method according to claim 70, wherein, The application includes at least one of the following: a user interface application, an application executed in the information technology (IT) layer associated with the industrial process plant, an application executed in the operational technology (OT) layer of the industrial process plant, an Internet of Things (IoT) application, an industrial Internet of Things (IIoT) application, an application executed in a computing cloud, an application communicatively connected to the virtualization management node via one or more public networks, or a third-party application.

75. The method according to claim 70, further comprising: Configuring the simulator access mechanism to use the respective identifiers of any simulation components included in the virtual environment.

76. The method according to claim 70, wherein, The simulator access mechanism communicates with the application via one or more industrial and / or communication protocols.

77. The method according to claim 70, wherein, Performing the simulation run includes: performing the simulation run based on one or more simulation commands received via one of the applications through the simulator access mechanism.

78. The method according to claim 77, wherein, The one or more simulation commands include respective simulation commands for performing at least one of the following: Speeding up the simulation run; Slowing down the simulation run; Pausing the simulation run; Inserting and / or modifying one or more values associated with the simulation run; or Changing the initial conditions associated with the simulation run.

79. The method according to claim 77, wherein, The one or more simulation commands include respective simulation commands for performing at least one of the following: Saving data associated with the simulation run; Saving a snapshot of the respective states and operations of at least one simulation node associated with the simulation run and any virtual runtime nodes and / or physical nodes; Backing up the simulation run; or Obtaining and / or restoring data of the backed-up simulation run.

80. The method according to claim 70, wherein, The simulator access mechanism maintains one or more states associated with at least some of the one or more simulation nodes, and the simulator access mechanism updates the one or more states associated with at least some of the one or more simulation nodes during the simulation run.

81. The method according to claim 80, wherein: The simulator access mechanism maintains one or more states associated with one or more other components of the virtual environment of the industrial process plant and / or the physical environment of the industrial process plant while maintaining the one or more states associated with at least some of the one or more simulation nodes; and The simulator access mechanism updates the one or more states corresponding to the one or more other components of the industrial process plant during the simulation run.

82. The method according to claim 80, wherein The one or more states corresponding to the simulation run include at least one of the following: the state of a virtual component, the state of a physical component, the state of a simulation component, the state of a virtual device, the state of a physical device, the state of a simulation device, the state of a virtual module, the state of a physical module, the state of a simulation module, the state of a process at least partially simulated by the simulation run, the state of the simulation run, and / or another type of state associated with the simulation run.

Images