Industrial control system hyper-converged architecture

Abstract

To disclose a hyper-converged industrial process control architecture for controlling an industrial process within a physical process environment using a software definition decentralized control system (DCS) environment.SOLUTION: A software definition DCS environment is implemented by virtualizing a hardware configuration element of a DCS architecture on a server group, and both a software definition process controller and a back end DCS application can be enabled to run within the server group. A software definition DCS network architecture reduces a hardware requirement of a process control system by implementing a control component and an upper level component in a common environment within the server group, and reduces configuration complexity.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] This patent application relates generally to industrial and process control systems, and more particularly to industrial control systems that use a software-defined architecture to provide run-time process control. [Background technology]

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

[0003] Information from the field devices and controllers is typically made available from the controllers over a data highway to one or more other hardware devices, such as operator workstations, personal computers or computing devices, data historians, report generators, centralized databases, or other centralized computing devices, typically located in a control room or other location away from the more austere plant environment. Each of these hardware devices is typically centralized across the process plant or across a portion of the process plant. These hardware devices run applications that may enable, for example, an engineer to configure a portion of the process or an operator to perform functions related to the control of the process and / or operation of the process plant, such as changing settings of process control routines, changing the operation of control modules in 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 purposes of training personnel or testing process control software, maintaining and updating configuration databases, etc. The data highways utilized by the hardware devices, controllers, and field devices may include wired communication paths, wireless communication paths, or a combination of wired or wireless communication paths.

[0004] As an example, the DeltaV™ control system sold by Emerson Process Management includes multiple applications stored in and executed by different devices located at various locations in a process plant. Configuration applications residing in one or more workstations or computing devices allow users to create or modify process control modules and download these process control modules over a data highway to dedicated distributed controllers. Typically, these control modules are composed of communicatively interconnected function blocks that are objects in an object-oriented programming protocol that perform functions in a control scheme based on inputs thereto and provide outputs to other function blocks in the control scheme. The configuration application may also allow the configuration designer to create or modify operator interfaces that are used by the visibility application to display data to an operator and to allow the operator to change settings, such as set points, in the process control routines. Each dedicated controller, and in some cases, one or more field devices, stores and executes a respective controller application that runs the control modules assigned to and downloaded thereto to implement the actual process control functions. A visibility application may run on one or more operator workstations (or one or more remote computing devices communicatively connected to the operator workstations and the data highway) and may receive data from the controller application via the data highway and display this data to a process control system designer, operator, or user using a user interface to provide any of a number of different views, such as an operator's view, an engineer's view, a technician's view, etc.While a data historian application is typically stored on and executed by a data historian device that collects and stores some or all of the data provided over the data highway, a configuration database application may be run on an even further remote 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.

[0005] Currently known process control plant and process control system architectures are heavily 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 the controller is typically minimized or at least carefully managed. As a result, during system configuration (e.g., a priori), a user or configuration engineer must typically select which data in the controller should be archived or stored, how often it will be stored, and whether compression is used or not, and thus the controller is configured with this limited set of data rules. As such, data that may be useful for troubleshooting and process analysis is often not archived, and if collected, useful information may have been lost due to data compression.

[0006] Additionally, to minimize controller memory usage in currently known process control systems, data selected to be archived or stored (when dictated by the controller's configuration) is reported to a silo workstation or computing device for storage in an appropriate data historian or data silo. Current techniques used to report data underutilize communication resources and induce excessive controller load. Additionally, data collection and time stamps are often out of sync with the actual process due to time delays in communication and sampling in the historian or silo.

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

[0008] Additionally, current architectures of industrial control systems, such as process control systems, are primarily hardware-driven in that various functions, such as control functions, input / output (I / O) functions, user interface functions, etc., are embodied in and tied to a particular piece of hardware (e.g., user workstations or interface devices, process controllers, safety system controllers, dedicated I / O devices, marshaled I / O devices, field devices, safety logic solvers, etc.), and remain stored within a particular piece of hardware at all times. For example, in current process control systems, the interconnections between controllers and I / O devices (e.g., either individual I / O devices or banks of marshaled I / O devices) are configured based on specific hardware, and as a result, the physical I / O relationships are tightly coupled, most commonly in a one-to-one manner (e.g., from an I / O device to a controller, another I / O device to another controller, etc.). This architectural design limits the resiliency, reliability, availability, responsiveness, and elasticity of the control systems because these systems are difficult to change or reconfigure quickly, are tightly tied to the proprietary hardware used to implement the proprietary control software, require hardware redundancy per device that can be expensive to implement, are not easily scalable or cannot be upgraded (e.g., due to size limitations of individual devices, such as physical process controllers, or the specific characteristics and capabilities of I / O devices) without adding additional hardware that must be configured in specific ways.

[0009] Additionally, current control system architectures separate online process control applications and other related applications into multiple functional devices that communicate over a process plant communication network. Thus, process control systems require additional hardware devices that must be individually configured to communicate with the other devices with which they interact. For example, replacing or reconfiguring a field device in a process plant may require reconfiguring numerous controllers that interact with the field device, and numerous workstations and higher-level applications that monitor data associated with such field devices. Summary of the Invention

[0010] Described herein is a hyper-converged distributed control system (DCS) architecture for industrial process control that implements in a software-defined DCS environment that combines software-defined process controllers and associated applications. The software-defined DCS environment may enable hardware components of the DCS architecture to be virtualized in a software-defined virtual network that runs on standard hardware components and to manage such components as software components. Such software-defined DCS environments may be implemented in a server group, such as a private cloud computing system, which may reduce both the hardware requirements of the system and the configuration required to set up the system. Described herein are systems, methods, and computer-readable media that store executable instructions for controlling an industrial process in a physical process environment. Such systems, methods, and instructions may include or be implemented by a server group configured to implement a software-defined DCS environment that includes one or more software-defined process controllers configured to control at least a portion of an industrial process in real time by communicating with a plurality of field devices in the physical process environment, and one or more DCS applications configured to interact with the software-defined process controllers.

[0011] The server group includes a plurality of server devices that operate together to implement the software-defined DCS environment. In some embodiments, the server group is communicatively connected to a plurality of field devices via one or more input / output (I / O) connections configured to communicate process data over a process control network using an industrial process control communication protocol. In further embodiments, the software-defined DCS environment further includes one or more virtual network components configured to replicate one or more of the physical network components, such as a network switch, router, or firewall.

[0012] In some embodiments, at least one of the DCS applications is configured to coordinate the operation of the software-defined process controller. In further embodiments, the DCS applications may provide various functionality within the software-defined DCS environment. The DCS applications may include a virtual architecture configuration application having a user interface configured to enable a user to define a virtual DCS network architecture by specifying a plurality of virtual nodes and connections between the virtual nodes within the virtual DCS network architecture. Such virtual nodes may include virtual representations of a plurality of field devices. Additionally or alternatively, the DCS applications may further include a data historian application configured to automatically store process data within the software-defined DCS environment during operation of the industrial process. In still further embodiments, the DCS applications may include one or more functions of an operator interface, an engineering workstation, an asset management system, a manufacturing execution system, or an advanced process control system. In further embodiments, the DCS applications may include a network gateway for communicating with an external data network.

[0013] In further embodiments, the server group may be configured to provide load balancing or redundancy using multiple server devices. In such embodiments, the one or more software-defined process controllers include multiple instances of a virtual DCS controller running simultaneously on different server devices of the server group. Thus, the server group may be configured to perform automatic load balancing among the multiple instances of the virtual DCS controller based on the status of the multiple server devices in the server group. In further embodiments, the DCS application may include an application configured to predict an optimal number of server devices for the server group based on the resource usage of the server group and the resource availability of the multiple server devices.

[0014] In accordance with one aspect of the systems, methods, and computer-readable media storing executable instructions for controlling an industrial process in a physical process environment described herein, a technique for controlling an industrial process in a physical process environment includes (i) connecting a plurality of field devices in the physical process environment via one or more I / O connections to a server group of a plurality of server devices configured to implement a software-defined DCS environment; (ii) controlling at least a portion of the industrial process in real time by one or more software-defined process controllers operating in the software-defined DCS environment on the server group, by communicating with the plurality of field devices in the physical process environment; and (iii) coordinating operation of the one or more software-defined process controllers by one or more DCS applications running in the software-defined DCS environment on the server group and configured to interact with the software-defined process controllers.

[0015] The server group may receive process data from the multiple field devices via one or more I / O connections and send process control signals to the multiple field devices for controlling portions of an industrial process via one or more I / O connections. In some embodiments, the DCS application may detect a type of process data associated with the field devices of the multiple field devices based on the data traffic on the one or more I / O connections and determine an adjustment to the operation of one or more software-defined process controllers based on the type of process data. In further embodiments, the DCS application may provide load balancing by detecting a change to a status of one of the multiple server devices of the server group and adjusting load distribution among the multiple server devices based on the change to the status. In some such embodiments, redundancy of the software-defined process controller may also be provided by simultaneously implementing multiple instances of a virtual DCS controller on different server devices of the server group, such that control may be transferred between the instances in the event of a failure of control by one of the server devices.

[0016] In some embodiments, the DCS application may include a virtual architecture configuration application that generates a user interface for a user including multiple options for configuring virtual components within the software-defined DCS environment and receives user input from a user to define a virtual DCS network architecture by specifying multiple virtual nodes and connections between the virtual nodes in the virtual DCS network architecture. Such virtual nodes may include one or more virtual representations of multiple field devices. In further embodiments, the DCS application may include a data historian that automatically monitors process data within the software-defined DCS environment during operation of the industrial process and automatically stores the process data in a data store associated with the server group. [Brief description of the drawings]

[0017] [Figure 1] FIG. 1 is a block diagram illustrating an example physical process plant environment in which a distributed control system (DCS) controls at least a portion of a process of an industrial or process plant. [Figure 2A] 2 illustrates a block diagram of an example process plant of FIG. 1 in which a software-defined DCS environment running on a group of servers controls at least a portion of the process plant. [Figure 2B] 2 illustrates a block diagram of an example process plant of FIG. 1 in which a software-defined DCS environment running on a group of servers controls at least a portion of the process plant. [Diagram 3] 2A and 2B show block diagrams of example redundant server groups implementing a software-defined DCS environment, such as the server groups of FIGS. 2A and 2B. [Figure 4] FIG. 1 is a flow diagram illustrating an example software-defined DCS architecture configuration and control method. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0018] The hyperconverged industrial process control system architecture described herein provides a software-defined distributed control system (DCS) architecture for controlling industrial processes within a physical process plant. Such software-defined DCS architectures provide a hardware-independent, scalable control network by pooling resources within a process control system in a manner that allows the components to be defined, managed, and controlled as software components. For example, software-defined DCS architectures allow for the implementation of software-defined process controllers and back-end DCS applications on the same hardware, such as a server group forming a private cloud computing network. This combination of controllers and high-level applications within a software-defined DCS environment has many advantages. For example, the architecture allows for the use of standard server hardware rather than system-specific hardware for the process controllers, thereby enabling scalability of the process control system through the addition or removal of servers within the server group. Also, implementing a virtual representation of many DCS process controllers (along with other DCS applications) within a server group eliminates the need for separate hardware for each controller and other back-end systems. Additionally, a software-defined combination of software-defined process controllers and DCS applications in a server group eliminates the need to route process data to numerous controllers, reducing the complexity of the control system and the effort required to configure or update the system architecture. Load balancing and failover capabilities are also improved by implementing software-defined process controllers as virtual DCS controllers in a server group, allowing redundant virtual DCS controllers to be implemented in a resource-efficient manner on various servers in the server group.These advantages are merely exemplary, and additional advantages to the software-defined DCS architecture described herein will become apparent to those of ordinary skill in the art based on the following disclosure.

[0019] Physical Process Plants and Process Control Systems 1 is a block diagram of an example physical process plant 100 environment in which a distributed control system (DCS) controls at least a portion of a process in an industrial or process plant. The DCS system of the physical process plant 100 controls (or in some embodiments operates in conjunction with a virtual plant environment to control) an industrial process, which may be said to have one or more "process outputs" that characterize the state of the process (e.g., tank levels, flow rates, material temperatures, etc.) and one or more "process inputs" (e.g., various environmental conditions and actuator states, the operation of which may change the process outputs). The physical process plant 100 includes a field environment 102 and a back-end environment 105, each of which are communicatively connected to one another by a process control backbone or data highway 108, which may include one or more wired and / or wireless communication links and / or networks, which may be implemented using any desired or suitable communication protocol, such as, for example, an Ethernet protocol, an IP protocol, or another packet protocol.

[0020] At a high level, the field environment 102 includes physical components (e.g., process control devices, networks, network elements, etc.) that are installed and interconnected to operate in combination to control an industrial process during runtime. Generally, these physical components are located, disposed, or otherwise contained within the field environment 102 of the physical process plant 100, where raw materials are received and processed using the physical components disposed therein, thereby producing 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, databases or data banks, that are shielded and / or protected from the harsh conditions and materials of the field environment 102. In some embodiments, the various computing devices, databases, and other components and devices 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 process plant 100 and some of which may be remote.

[0021] A field environment 102 of a physical process plant 100 As shown in FIG. 1 , the field environment 102 includes one or more process controllers 110 communicatively connected to a data highway 108. Each of the process controllers 110 may be connected to one or more intermediate nodes, such as I / O devices 112, 115 (e.g., I / O cards, I / O devices, I / O systems, etc.), that facilitate communication between the controllers 110 and the field devices. Generally speaking, in the process control industry, the term “I / O” may be used in several related, but distinct, contexts. The term generally refers to a 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 to refer to several other concepts, such as the physical device utilized to transmit signals to or receive signals from the field device via the I / O channel (e.g., “I / O device” or “I / O card”) and a connector or terminal associated with the I / O device (e.g., “I / O connector”). The I / O devices and I / O cards 112, 115 may be standalone individual physical devices, each connected to a respective controller and one or more respective field devices, as shown. In some configurations (not shown in FIG. 1), the I / O devices, cards, connectors, and other I / O related components, such as terminal blocks, module processors, etc., are included in an I / O electronic marshalling system that enables flexible I / O distribution 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 which are expressly incorporated herein by reference.Thus, for clarity of discussion and as utilized herein, the term "I / O device" generally includes physical I / O devices, cards, electronic marshalling systems, and those components by which I / O channels are implemented to communicatively couple field devices and controllers. Additionally, the term "I / O connection" generally refers to physical I / O devices and other physical components that connect various components for communicating I / O data between such components.

[0022] In the process control industry, the term "I / O" may be used generally to refer to a signal transmitted on an I / O channel (e.g., an "I / O signal"), a variable or command represented by a signal (e.g., an "I / O parameter"), or a value of the variable or command carried by a signal (e.g., an "I / O parameter value" or "I / O data payload"). Thus, for clarity of discussion, as utilized herein, I / O signals, I / O parameters, and I / O parameter values ​​are collectively and generally referred to herein as "I / O data" or "process I / O data."

[0023] To the extent that the term "I / O" is referenced herein without a modifier, the context should make clear which of these concepts are being discussed. Additionally, it should be understood that an "I / O channel" refers to a particular type of "communications channel" or "channel." That is, unless the context suggests otherwise, references in this description to the term "channel" or the term "communications channel" without the "I / O" modifier may, in some embodiments, refer to a communications link that may be an I / O channel, but may, in some embodiments, refer to a communications link other than an I / O channel.

[0024] Using the process I / O data, 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 operation modules) that may be stored in the memory of the controller 110. As the controller's processor executes the one or more control routines, the controller sends control signals (i.e., "control outputs") to one or more field devices over a wired or wireless process control communication link or network to control the operation of a process within the process plant 100. The controller may generate the control signals based on (i) one or more received signals (e.g., one or more received signals representing measurements taken by a field device), which may be referred to as "control inputs," and (ii) the logic of the one or more control routines, which may be defined by one or more software elements (e.g., function blocks). Typically, a controller manipulates process inputs (which may be referred to as "manipulated variables") to change a particular process output (which may be referred to as a "controlled variable" or simply a "process variable") based on feedback (i.e., measurements of the controlled variables) and a desired value (i.e., set point) of the process output.

[0025] Generally, at least one field device performs a physical function (e.g., opening or closing a valve, raising or lowering a temperature, taking a measurement, sensing a condition, etc.) to control the operation of a process implemented in the process plant 100. Some types of field devices communicate with a controller using I / O devices. The process controllers, field devices, and I / O devices may be wired or wireless, and any number and combination of wired and wireless process controllers, field devices, and I / O devices may be included in the physical process plant 100.

[0026] 1 illustrates a process controller 110 that is communicatively coupled to wired field devices 125-132 via input / output (I / O) devices 112 and 115, and 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 coupled to the wireless gateway 168 by using one or more communications networks other than the data highway 108, such as, for example, any number of other wired or wireless communications links supporting one or more communications protocols, such as Wi-Fi or other IEEE 802.11 compliant wireless local area network protocols, mobile communications protocols (e.g., WiMAX, LTE, or other ITU-R compatible protocols), Bluetooth®, HART®, WirelessHART®, Profibus, FOUNDATION® Fieldbus, etc.

[0027] The controller 110, which may be, by way of example, a DeltaV™ controller sold by Emerson Process Management, may operate to implement a batch or continuous industrial process using at least some of the field devices 125-132 and 140-146. In one embodiment, in addition to being communicatively connected to the process control data highway 108, the controller 110 is communicatively connected to at least some of the field devices 125-132 and 140-146 using any desired hardware and software associated with, for example, standard 4-20 mA devices, I / O devices 112, 115, and / or any smart communication protocol, such as the FOUNDATION® Fieldbus protocol, the HART® protocol, the WirelessHART® protocol, etc. As illustrated, 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 may conform to any other desired standard(s) or protocol, such as any wired or wireless protocol, including any standard or protocol developed in the future.

[0028] The process controller 110 includes a processor 120 that implements or oversees one or more process control routines 118 (e.g., executes computer-readable instructions of the process control routines 118 stored in the memory 122 of the controller 110). The processor 120 is configured to communicate with the field devices 125-132 and 140-146, as well as other nodes communicatively coupled to the controller 110. It should be noted that any control routine or module described herein may have portions implemented or performed by different controllers, processors, or other devices, if so desired. Similarly, the control routines or modules 118 described herein implemented within the physical process plant 100 may take any form, including software, firmware, hardware, etc. The control routines may be implemented in any desired software format, such as using object-oriented programming, ladder logic, sequential function charts, function block diagrams, or any other software programming language or design paradigm. The control routines 118 may be stored in any desired type of memory 122, such as random access memory (RAM) or read only memory (ROM). Similarly, the control routines 118 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 the control strategies or control routines in any desired manner.

[0029] The controller 110 implements control strategies using what are generally referred to as function blocks, each of which is an object or other portion (e.g., a subroutine) of an overall control routine and operates with other function blocks (through communications called links) to implement process control loops within the process control system. A control-based function block typically performs one of the following: i) an input function, such as those associated with transmitters, sensors or other process parameter measurement devices (sometimes referred to as "input blocks"); (ii) a control function (sometimes referred to as a "control block"), such as those associated with a control routine that performs PID, fuzzy logic, etc.; or (iii) an output function (sometimes referred to as an "output block") that controls the operation of some device, such as a valve, to perform some physical function within the physical process plant 100. Of course, hybrid and other types of function blocks exist.

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

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

[0032] The wireless field devices 140-146 communicate over the wireless process control communication network 165 using a wireless protocol, such as the WirelessHART® protocol. Such wireless field devices 140-146 may communicate directly with one or more other devices or nodes of the wireless network 165 that are also configured to communicate wirelessly (e.g., using the 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 to another process control communication network. The wireless gateway 168 provides access to the various wireless devices 140-158 of the wireless communication network 165. In particular, the wireless gateway 168 provides a communicative 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 a communicative link by using the process control data highway 108 and / or by using one or more other communication networks of the physical process plant 100 .

[0033] 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 taking measurements of a process parameter. However, the wireless field devices 140-146 are configured to communicate using the wireless protocol of the network 165. In this manner, 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.

[0034] In some configurations of the process plant 100, the wireless network 165 includes non-wireless devices. For example, in FIG. 1, the field device 148 is a conventional 4-20 mA device and the field device 150 is a wired HART® device. To communicate within the network 165, the field devices 148 and 150 are connected to the wireless communication network 165 via wireless adapters 152a, 152b. The wireless adapters 152a, 152b support wireless protocols such as WirelessHART, and may also support one or more other communication protocols such as Foundation® 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 in wired communication with a wireless gateway 168 or may be provided within the wireless gateway 168 as an integrated device. Additionally, the wireless network 165 may also include one or more routers 58 for forwarding packets from one wireless device to another within the wireless communication network 165. In this manner, the wireless devices 140 - 146 and 152 - 158 communicate with each other and with the wireless gateway 168 via wireless links 160 of the wireless communication network 165 and / or through the process control data highway 108 .

[0035] 1 illustrates only a single process controller 110, wireless gateway 168, wireless adapter 152, access point 155, router 158, and wireless process control communications network 165, including a finite number of field devices 125-132 and 140-146, included within the exemplary process plant 100, it should be noted that this is merely an exemplary and non-limiting embodiment. Any number of controllers 110 may be included in the physical process plant 100, and any number of controllers 110 may communicate with any number of wired or wireless devices and networks 125-132, 140-146, 168, 152, 155, 158, 165 to control processes within the physical process plant 100.

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

[0037] The operator workstations 170a and other user interface devices 170b may be utilized by an operator to view and monitor the run-time operation of the physical process plant 100, as well as to take any diagnostic, corrective, maintenance, and / or other actions that may be required. At least some of the operator workstations 170a may be located in various protected areas within or near the plant 100, and in some circumstances, at least some of the user interface devices 170b may be located in remote locations yet communicatively connected to the plant 100. The operator workstations and user interface devices 170a, 170b may be wired or wireless computing devices configured to implement operator interface programs or applications to enable an operator to monitor and control the operation of the physical process plant 100.

[0038] The configuration application 172a and configuration database 172b may be utilized to configure certain aspects of the control and / or communication of the physical process plant 100 through initial configuration and reconfiguration of control modules / routines, user interfaces, data monitoring / analysis, etc. For example, various instances of the configuration application 172a may be executed on one or more computing devices (not shown) to enable a user to create or modify process control modules and download those modules to the controller 110 via the data highway 108, create or modify operator interfaces that allow an operator to view data and change data settings within the process control routines, create or modify data monitoring / analysis routines and functions that can be downloaded to various physical components in the field environment 102, etc. The configuration database 172b stores the created (e.g., configured) modules, operator interfaces, data monitoring / analysis, etc. Typically, configuration application 172a and configuration database 172b are centralized and have a single logical appearance for a DCS environment (e.g., a DeltaV™ control system sold by Emerson Process Management, Inc.) for physical process plant 100, although multiple instances of configuration application 172a may run simultaneously within the DCS environment and configuration database 172b may be implemented across multiple physical data storage devices. Thus, configuration application 172a and configuration database 172b (including their user interfaces) comprise configuration or development systems 172 for various types of modules, e.g., control modules, display or operator interface modules, and / or analysis modules.Typically, but not necessarily, the user interface for the configuration system 172 differs from the operator workstation / user interface device 170 because the user interface for the configuration system 172 is utilized by configuration and development engineers regardless of whether the physical process plant 100 is operating in a production mode, whereas the operator workstation / user interface device 170 is utilized by an operator during runtime operation of the physical process plant 100.

[0039] With respect to commissioning of the physical components of the field environment 102, the configuration database 172b may store data and other information that specifically identifies and / or addresses various physical devices or components and their interconnections that are planned or desired to be implemented on the process plant floor or field environment 102. Some of this commissioning data may be provided to the components in the field environment 102 for use in commissioning the devices and loops therein, and some of this data may be utilized in the back-end environment 105 for example, for designing, developing and preparing control modules, operator interface modules and / or analytical modules that will operate in conjunction with the field environment 102 during live operation of the physical process plant 100. In one example, approved control modules are downloaded from the configuration database 172b to the process controller 110 such that, when executed during live operation, the process controller 110 operates according to its resident control modules to send and receive various signals to / from other components in its loop (and possibly to / from other process controllers) and thereby control at least a portion of the process in the physical process plant 100.

[0040] The configuration database 172b may store some logical identifiers of components in the field environment 102, allowing the controller 110 and other devices to refer to the components and signals associated with the components by the logical identifiers. For example, for a given field device, the configuration database 172b may store information mapping or binding the logical identifier to a specific hardware address or I / O channel. The hardware address may identify a specific controller, a specific I / O device connected to a specific controller, and / or a specific address for an I / O channel connecting a specific I / O device to a field device. In some cases, this mapping or binding may be stored in 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 a logical identifier). After a logical identifier is bound to a hardware address or I / O channel, the identifier is considered "assigned." In some embodiments, the physical process plant 100 includes "unassigned" logical identifiers, which are identifiers that software elements (e.g., control routines and / or function blocks) reference but are not bound to. That is, a logical identifier is considered "unassigned" when plant 100 and configuration database 172b have no hardware addresses or I / O channels that are not bound to a tag. Thus, when an unassigned logical identifier is referenced by a control routine, no values ​​carried by signals in physical process plant 100 are read and no commands are sent via signals to field devices in physical process plant 100.

[0041] Examples of such logical identifiers include device tags (DTs), each of which represents a particular instrument, controller, valve, or other physical field device, and device signal tags (DSTs), each of which represents a particular signal received or generated by a particular device and typically corresponds to a particular parameter utilized by the field device. In some devices, the DST includes a combination of the device's DT and an identifier of a particular signal received or generated by the device, e.g., an identifier of a particular parameter referenced by a control module. In some devices, such as legacy or dumb devices, the DT represents both the physical device and the signal generated by the device. Generally speaking, the logical identifiers of the device are used by the physical process plant 100 in both the field environment 102 and the back-end environment 105 to uniquely identify the device. The DTs and DSTs may be referred to as "tags," "system tags," or "system identifiers."

[0042] In some cases, the smart field devices 129-132 may also store logical identifiers that are unique to the smart field devices 129-132. These logical identifiers may be separate from the system tags utilized by the plant 100 to identify the field devices 129-132 and may be referred to as "source identifiers" or "source tags." The source tags may or may not be stored in the configuration database 172b, depending on the implementation. The configuration database 172b may store data and other information that specifically identifies and / or addresses various virtual devices or components (e.g., various virtual nodes) that are planned or desired to be implemented in the virtual DCS environment, as described below. As with physical devices and components, the configuration database 172b may store logical identifiers for each of the components of the virtual DCS environment, thereby allowing other devices and / or components (whether physical or virtual) to reference the virtual components. For example, similar to physical nodes in the field environment 102, the various virtual nodes may be uniquely identified within a DCS environment operating within the backend environment 105 via their respective device tags (DTs), device signal tags (DSTs), source tags, and / or other types of unique identifiers. Further sections of this disclosure discuss the configuration and identification of virtual devices and components in more detail.

[0043] Other applications 175a and databases 175b may include instances of applications used to monitor or analyze aspects of the operation of physical 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. In general, other applications 175a and databases 175b may include one or more applications and their associated databases that execute in an operations technology layer of physical process plant 100. Additionally or alternatively, other applications 175a and databases 175b may include one or more applications and their associated databases that execute in an IT layer associated with process plant 100, such as inventory management applications, human resources management applications, supply chain management applications, other types of enterprise-related applications, weather / environmental applications, etc. For example, other applications 175a and databases 175b may include Internet of Things (IoT) and / or Industrial Internet of Things (IIoT) applications and their associated databases. Additionally or alternatively, other applications 175a and databases 175b may include one or more applications that run remotely from physical process plant 100 and / or its enterprise, e.g., simulation applications, analytical applications, and the like, and their associated databases. Other applications 175a and databases 175b may include third party applications and / or applications provided by an enterprise associated with physical process plant 100. At least some of other applications 175a and databases 175b may be accessed via edge gateway system 182 and / or some other type of security and / or firewall system.

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

[0045] The gateway nodes or systems 180, 182 may interface with systems external to the instantaneous physical process plant 100. Typically, such systems are customers or providers of information generated by or acted upon by the physical process plant 100. For example, the physical process plant 100 may include a plant gateway node 180 for communicatively connecting the instantaneous physical process plant 100 with another process plant. Additionally or alternatively, the physical process plant 100 may include an edge gateway node or system 182 for communicatively connecting the physical process plant 100 with external public or private systems, such as a laboratory system (e.g., a laboratory information management system or LIMS), an operator round database, a data integration and viewing system, a data analysis system, a material handling system, an asset management system, a maintenance management system, a product inventory management system, a production scheduling system, a weather data system, a shipping and handling system, a packaging system, the Internet, an IoT application, an IIOT application, or other external systems.

[0046] In general, the edge gateway system 182 enables secure delivery of communications between the physical process plant 100 and other networks 185. In an exemplary architecture, the edge gateway system 182 includes an internal facing or plant facing engine (which may be referred to as a “field gateway”) and an external facing or externial facing engine (which may be referred to as an “edge gateway”), where the plant facing engine and the externial facing engine cooperate to securely deliver process plant data (e.g., data generated by the operations technology layer) to external networks and / or applications (e.g., IT layer and / or external networks and / or systems) that are consumers of the plant data. In one of many embodiments, the plant facing engine collects data generated by various components of the process plant 100 and securely transmits the collected data to the externial facing engine over one or more secure communication links, for example, via a first publication set. The externial facing engine subscribes to various publications generated by the plant facing engine and obtains the collected plant data therefrom. The outward facing engine then securely transmits the resulting plant data to one or more external client applications in the network 185, for example, via a second set of publications. The publications and subscriptions at the plant facing engine and / or the outward facing engine, respectively, may be configured as needed. Typically, however, the publications / subscriptions, encryption, and / or other secure data distribution mechanisms utilized between the plant facing engine and the outward facing engine are different than the publications / subscriptions, encryption, and / or other secure data distribution mechanisms utilized between the outward facing engine and the external applications. In some embodiments, for added security, the edge gateway system 182 includes a one-way data diode disposed between the plant facing engine and the outward facing engine to prevent data from flowing from the external network 185 to the process plant 100.Examples of edge gateway systems are described in U.S. Patent Publication Nos. 2018 / 0115516, 2018 / 0115528, 2018 / 0115517, and 2018 / 0113442, the entire disclosures of which are incorporated herein by reference. Of course, other edge gateway systems may additionally or alternatively be utilized by physical process plant 100.

[0047] A Software-Defined DCS Environment for Physical Process Plants 2A and 2B show block diagrams of the example physical process plant 100 of FIG. 1 in which a software-defined DCS environment 200 executing on a server group 210 controls at least a portion of the process plant. In both illustrated embodiments of the software-defined DCS environment 200, the controller 110 of the physical process plant 100 is implemented as a software-defined process controller (virtual DCS controller 212) within the server group 210 of the back-end environment 105. In addition to the virtual DCS controller 212, the server group 210 also implements various DCS applications 221-225, 229 to provide higher level functionality, configuration, monitoring, and analysis of the process and the virtual DCS controller 212. The server group 210 also includes one or more databases or data stores for process data related to the virtual DCS controller 212 and the DCS applications 221-225, 229. Although the exemplary software-defined DCS environment 200 is illustrated as implementing multiple virtual DCS controllers 212, this should be understood as an example of a software-defined infrastructure implementation in which hardware and software resources are pooled within the software-defined environment to facilitate policy-based infrastructure provisioning.

[0048] Software-defined DCS control of processes in the server group 210 provides numerous advantages, including enabling load balancing, improving system robustness by protecting against component failures, reducing device requirements by combining controllers in the same hardware, and reducing configuration effort by reducing network complexity. FIG. 2A illustrates an embodiment of a software-defined DCS environment 200 in which I / O connections 240 are handled by components in the field environment 102, and FIG. 2B illustrates an embodiment of a software-defined DCS environment 200 in which I / O connections 240 are handled by the server group 210 in the back-end environment 105. Further embodiments may include a combination of I / O connections 240 in both the field environment 102 and the back-end environment 105 (e.g., smart field devices may be able to communicate directly with the server group 210 over a data communications network, while legacy field devices may require I / O devices to hide between the industrial process control communications protocols used by the field devices and the general IT communications protocols used by the servers).

[0049] As discussed above with respect to FIG. 1, a number of field devices 125-132, 140-150 in the field environment 102 control at least a portion of an industrial process based on control signals from a DCS controller. In the software-defined DCS environment 200, such control signals are generated by a virtual DCS controller 212 implemented by one or more servers in the server group 210. The virtual DCS controller 212 operates in substantially the same manner as a (physical) controller 110 to implement process control logic configured to monitor and control a process in real time. However, the virtual DCS controller 212 is implemented as computer-executable instructions in the server group 210 rather than in a special purpose hardware controller 110 of the field environment 102. For example, the virtual DCS controller 212 may be a virtual instance of a control program operating in a real time operating environment implemented by one or more hypervisors operating on the server group 210 to simulate the native operating environment of each of the virtual DCS controllers 212. Each virtual DCS controller 212 in the software-defined DCS environment 200 implements a process control loop using one or more function blocks to monitor and control a process via field devices 125-132, 140-150. In this manner, the virtual DCS controllers 212 are integrated within the server group 210 to control a process (or a portion thereof) from one location, enhancing communication between the control modules. In some embodiments, multiple virtual DCS controllers 212 may be implemented to control different portions of a process, similar to the use of multiple physical controllers in a physical DCS network. As discussed further below, load balancing and redundancy may be achieved by implementing multiple instances of each virtual DCS controller 212 on different servers in the server group 210.

[0050] In addition to the virtual DCS controller 212, in some embodiments, other network components may be virtualized within the software-defined DCS environment 200 to generate a virtual network defined by software executing on the server group 210. Such a virtual network includes a number of virtual nodes associated with physical nodes in the physical process plant 100. Such virtual nodes may include virtual components that represent various hardware components present in the communication network of the field environment 102, such as network switches, routers, firewalls, and other network devices. These virtual nodes may include network components such as the wireless gateway 168, wireless adapter 152, access point 155, or router 158, as described above. In further embodiments, the virtual network may include virtual representations of field devices for control and communication with the field devices 125-132, 140-150. The virtual representations of the field devices may be implemented within the virtual DCS controller 212 using device function blocks, shadow function blocks, or other such techniques used in DCS environments. Thus, in such an embodiment, the software-defined DCS environment 200 includes a virtual representation of the physical components of a process control system in a field environment (e.g., field devices and necessary networking components), and a virtual DCS controller 212 that replaces the physical controller.

[0051] To maintain communication connections with the field devices 125-132, 140-150, the software-defined DCS environment 200 may include or be connected to I / O connections 240 configured to provide communication links between the server group 210 and physical components of the communication network of the field environment 102. The I / O connections 240 include physical networking components that directly or indirectly connect the server group 210 to the field devices 125-132, 140-150. Such components may include ports, switches, or routers. The I / O connections 240 pass process data between the virtual DCS controller 212 and the field devices 125-132, 140-150. Thus, the I / O connections 240 receive process data from the field devices 125-132, 140-150 and transmit such process data to the virtual DCS controller 212, and the I / O connections 240 also receive process control signals from the virtual DCS controller 212 and transmit such process control signals to the field devices 125-132, 140-150.

[0052] In some embodiments, the I / O connections 240 may include an I / O server configured to map physical nodes in the field environment 102 to virtual nodes in the software-defined DCS environment 200, thereby allowing the virtual DCS controllers 212 to communicate with the virtual nodes maintained by the I / O server without detailed knowledge of the physical network in the field environment 102. For example, the I / O server may map the physical nodes associated with the field devices 125-132, 140-150 to the virtual nodes associated with the corresponding virtual field devices by publication / subscription mapping to provide real-time communication of data between the server group 210 and the components of the field environment 102 (e.g., the field devices 125-132, 140-150). By routing all communications to the server group 210, the I / O connections 240 decouple the hardware and software communication configurations, thereby allowing all virtual DCS controllers 212 in the server group 210 to access any process data without requiring configuration of separate hardware connections from each controller to each data source.

[0053] In further embodiments, the I / O connections 240 may also translate process data (including process control signals) between a server communication protocol used by the virtual DCS controller 212 and an industrial process control communication protocol used by the field devices 125-132, 140-150. For example, the server group 210 may be configured to communicate data using a common IT communication protocol (e.g., an Ethernet protocol, an IP protocol, or another packet protocol), and the field devices 125-132, 140-150 may be configured to communicate using an industrial process control communication protocol (e.g., Profibus, DeviceNet, Foundation Fieldbus, ControlNet, Modbus, HART, etc.).

[0054] Although shown in FIG. 2A as separate from the server group 210, the I / O connections 240 may alternatively be incorporated into the server group 210, as shown in FIG. 2B. Similarly, the I / O connections 240 may connect the server group 210 with only a subset of the field devices (e.g., field devices 125-132, as shown in FIG. 2A) or may connect the server group 210 with all of the field devices in the field environment 102 (e.g., field devices 125-132 and 140-150, as shown in FIG. 2B). As shown in FIG. 2A, other networking components (e.g., wireless gateway 168) may directly connect some of the field devices (e.g., field devices 140-150) to the server group 210, such as by direct physical connection, via a local area network (not shown) in the backend environment 105. For example, within a server room of the backend environment 105, the wireless gateway 168 may be physically connected via wired communication cables to one or more server racks that make up the server group 210.

[0055] In addition to the virtual DCS controller 212, the software-defined DCS environment 200 also includes one or more DCS applications 221-225, 229 operating on servers in the server group 210. These DCS applications 221-225, 229 are configured to interact with the virtual DCS controller 212 to configure, monitor, control, and / or analyze the operation of a process in the physical process plant 100. The DCS applications operate in a manner similar to the various applications and gateways of the back-end environment 105 in a traditional DCS configuration (such as that illustrated in FIG. 1 ) to obtain data from the virtual DCS controller 212 and coordinate the operation of the virtual DCS controller 212 in controlling a physical process. However, implementing the DCS applications 221-225, 229 in the server group 210 along with the virtual DCS controller 212 simplifies configuration and communication. In some embodiments, the software-defined DCS environment 200 may implement one or more operating systems on which one or more of the DCS applications 221-225, 229 run natively, in addition to the real-time environment in which the virtual DCS controller 212 runs.

[0056] The DCS applications 221-225, 229 may include multiple applications for implementing control, configuration, communication, or analytical functionality. One or more user interface devices 170b (e.g., a workstation, desktop computer, or mobile computing device) may be used by one or more operators to interact with the DCS applications 221-225, 229 of the software-defined DCS environment 200. For example, an operator may interact with the DCS applications 221-225, 229 using a desktop computer or a smartphone to obtain information about a process, adjust the operation of the virtual DCS controller 212, or analyze the condition of the process or the physical process plant 100.

[0057] The edge gateway application 221 may be configured to provide communication with other networks 185, similar to the edge gateway system 182 of FIG. 1. Such other networks may include external networks remote from the process plant. The operator interface application 222 may be configured to provide an operator interface or workstation interface to an operator to enable the operator to monitor and control the run-time operation of the process, similar to the operator workstation 170a. For example, an operator may use the user interface device 170b to access the operator interface application 222 running on the server group 210 to perform any diagnostic, corrective, maintenance, and / or other actions that may be required to operate the physical process plant 100. Such actions may include setting or adjusting operating parameters, control setpoints, or control schemes used by the virtual DCS controllers 212. Because the virtual DCS controllers 212 all operate within the software-defined DCS environment 200 and the server group 210, the operator interface application 222 may be configured to apply global changes to all virtual DCS controllers 212 or other components of the software-defined DCS network architecture. For example, operator interface application 222 may be configured to apply a system-wide lock to prevent the downloading of control modules to virtual DCS controller 212 (e.g., to prevent accidental or unauthorized changes while a process is running). Asset management application 223 may be configured to provide information about assets in physical process plant 100 and information about asset utilization.

[0058] The data historian application 224 may be configured to store process data within the software-defined DCS environment 200 during operation of the process for later use in process analysis or control. By implementing the data historian application 224 in the server group 210 along with the virtual DCS controller 212, it is possible to store more detailed process data than would otherwise be possible. Because all process data used and generated by the virtual DCS controller 212 is available in the server group 210, no further communication outside of the server group 210 is required to historize the data. Thus, the data historian application 224 may be configured to automatically store high fidelity data during process operation. Such process data may be stored in a database or data store 230 of the server group 210, which may store configuration or other data used by the virtual DCS controller 212 or the DCS applications 221-225, 229.

[0059] The virtual architecture configuration application 225 may be configured to define a software-defined DCS network architecture (e.g., a virtual DCS network architecture) by specifying a plurality of software-defined virtual nodes and connections between such nodes in the software-defined DCS network architecture, similar to the definition of the network architecture of the physical process plant 100 by the configuration application 172a. For example, the virtual nodes in the virtual DCS network architecture may be used to represent the physical network architecture of the components of the field environment 102 to enable the virtual DCS controller 212 to control a process. In this manner, the virtual nodes may include virtual representations of a plurality of field devices. To define the software-defined DCS network architecture, the virtual architecture configuration application 225 may provide a user interface configuration to enable an operator to define the virtual nodes. In some embodiments, the virtual architecture configuration application 225 may configure I / O connections 240 to facilitate communication between the server group 210 and the field devices 125-132, 140-150. In further embodiments, information regarding the type of process data received from components of the field environment 102 over the I / O connections 240 may be provided to the virtual architecture configuration application 225 to automatically determine some or all of the software-defined DCS network architecture based on the type of process data received. However defined or determined, the software-defined DCS network architecture may be stored as configuration data in one or more databases or data stores 230, similar to the configuration database 172b.

[0060] In some embodiments, other DCS applications 229 may be implemented within software-defined DCS environment 200 on server group 210 to provide additional or alternative functionality. Such other DCS applications 229 may include human-machine interface applications, engineering workstation applications, manufacturing execution system applications, advanced process control system applications, network communication applications, security applications, or other applications for performing process control, monitoring, testing, maintenance, optimization, or analysis related to processes of physical process plant 100. As an example, other DCS applications 229 may include emulator applications configured to execute third party software applications within server group 210 by emulating the native operating environment of such third party software applications within software-defined DCS environment 200. In this manner, legacy or other software applications may be integrated into the software-defined DCS environment as if they were executing on separate computing devices within physical process plant 100. As another example, other DCS applications 229 may include a real-time process model application configured to optimize, tune, or otherwise adjust a process control loop of the virtual controller 212 during operation of the process (e.g., by performing adaptive process control to select or adjust a process model based on variable plant parameters).As yet another example, other DCS applications 229 may include a security policy manager application configured to set software-defined security permissions or policies for various components of software-defined DCS environment 200, such as operating environments (e.g., hypervisor environments or software containers), virtual nodes (e.g., field devices, routers, or switches), software-defined process controllers (e.g., virtual DCS controller 212, control modules, function blocks), or other DCS applications. As yet another example, other DCS applications 229 may include a network architecture configuration application configured to automatically discover physical networking components (e.g., switches or routers) in field environment 102 and configure such physical networking components for communication within a communication network in field environment 102. In some such embodiments, the network architecture configuration application may further configure I / O connections 240 for communication between field environment 102 and server group 210.

[0061] In some such embodiments, server group 210 may be communicatively coupled to one or more additional server groups 210 associated with physical process plant 100, or may be communicatively coupled to one or more additional server groups 210 associated with other process plants or other systems. In some such embodiments, the other server groups 210 may be configured to operate portions of physical process plant 100. Similarly, in further embodiments, virtual DCS controller 212 of server group 210 may be configured to control only a portion of physical process plant 100, with one or more physical controllers 110 communicatively coupled to server group 210 to control other portions of physical process plant 100, in a hybrid control architecture. In some such hybrid control architectures, physical controllers 110 may nevertheless be represented as nodes within software-defined DCS environment 200 for purposes of enabling hardware-independent interaction between such controllers 110 and other components within the software-defined DCS architecture.

[0062] Server Groups for Software-Defined DCS Environments FIG. 3 illustrates a block diagram of an exemplary redundant server group 300 implementing a software-defined DCS environment 200, such as the server group 210 illustrated in FIGS. 2A and 2B. As described above, the software-defined DCS environment 200 implemented by the server group 210 may include multiple virtual DCS controllers 212 (or other software-defined process controllers) and multiple DCS applications 221-225, 229. To implement these software components, the server group 210 may include multiple servers 350a-n controlled by a control manager 352, as illustrated in the redundant server group 300 of FIG. 3. By implementing the virtual DCS controller 212 and the DCS applications 221-225, 229 on multiple servers 350a-n, the redundant server group 300 facilitates both efficient distribution of load among the servers 350a-n and robust failover capabilities in the event any of the servers 350a-n fail. Thus, multiple instances of each of virtual DCS controller 212 may run simultaneously on different servers 350a-n, and an instance of virtual DCS controller 212 may include control modules 314a-n and redundancy modules 318a-n coordinated by control manager 352. Based on the status (e.g., availability) of servers 350a-n, control manager 352 may perform automatic load balancing among servers 350a-n by allocating modules among servers 350a-n.

[0063] In some embodiments, the servers 350a-n and the control manager 352 may each include one or more blades connected to one or more server racks to form the redundant server group 300. Each of the blades 350a-n, 352 may be a thin electronic circuit board having one or more processors and memory. The processor within each of the blades 350a-n, 352 may include multi-core hardware, such as a multi-core processor or another type of parallel processor. Additionally, the memory within each of the blades 350a-n, 352 may include high density memory storage technologies, such as solid state drive memory, semiconductor memory, optical memory, molecular memory, biological memory, or any other suitable high density memory technology. In some embodiments, the memory storage may include flash memory. The memory storage (and, in some embodiments, the flash memory) may be configured to temporarily store or cache data generated, received, or otherwise observed by the respective blades 350a-n, 352.

[0064] In any event, each server 350a-n includes control routines or modules corresponding to a subset of the field devices 125-132, 140-150 to control at least a portion of the process in the physical process plant 100. Although multiple servers 350a-n in the redundant server group 300 may provide control signals to the same subset of the field devices 125-132, 140-150, multiple servers 350a-n may not provide control signals to the same field devices and / or to the same parameters within the same time interval. For example, a first server 350a and a second server 350b may not provide control signals to the same valves instructing them to open or close within the same time interval. In some embodiments, the control manager 352 assigns control modules to the servers 350a-n such that multiple servers 350a-n cannot provide control signals to the same field devices and / or to the same parameters within the same time interval. Additionally or alternatively, a control monitor module in the redundant server group 300 may monitor the control outputs from the servers 350a-n to determine if any two control outputs are going to the same field device and / or are for the same parameter within the same time interval. If this occurs, the control monitor module may override the control signals so that only one of the control signals is provided to the field device. The control monitor module may also submit a request to one of the servers 350a-n or the control manager 352 to stop providing the control signals to the field device during the time interval. However, multiple servers 350a-n may receive outputs from the same field device, such as percentage valve opening from the same valve, within the same time interval.

[0065] In some embodiments, for each control routine or module executed by the servers 350a-n, one of the servers 350a-n may include a redundancy module. The redundancy module may cause the server 350b executing the redundant module to stay synchronized with the server 350a executing the control module such that if the server 350a currently executing the control module fails, the server 350b executing the redundant module can take over and execute the control module. To stay synchronized with the server 350a executing the control module, the redundancy module may cause the server 350b executing the redundant module to receive the same inputs, outputs, set points, etc. as are received and provided by the server 350a executing the control module. The server 350a executing the control module may be a different server or blade than the server 350b executing the redundant module. Like the control modules, the redundancy modules may be software, firmware, hardware, etc. The redundancy modules may be implemented in any desired software format, such as using object-oriented programming, ladder logic, sequential function charts, function block diagrams, or any other software programming language or design paradigm.

[0066] Also, in some embodiments, each server 350a-n includes a DCS application module 316a-n for implementing the DCS applications 221-225, 229 discussed above. Like the control modules 314a-n, the DCS application modules 316a-n may be software, firmware, hardware, etc. The DCS application modules 316a-n may be implemented in any desired software format, such as using object oriented programming, ladder logic, sequential function charts, functional block diagrams, or any other software programming language or design paradigm.

[0067] In addition to the servers 350a-n, the redundant server group 300 includes a control manager 352 that assigns control modules, redundant modules, DCS application modules, and any other suitable operations to the servers 350a-n. In some embodiments, the control manager 352 is implemented in hardware and is one of the blades in a blade server. In other embodiments, the control manager 352 is a software application and may be implemented on any of the blades 350a-n in the redundant server group 300. The redundant server group 300 may include a single control manager 352 implemented on a single blade that manages control of each of the controllers in the multiple blade servers. In other embodiments, the control manager 352 may be implemented across multiple blades. In still other embodiments, the redundant server group 300 may include one or more rack servers, each having multiple mounting slots such that the blades 350a-n, 352 correspond to bays 350a-n, 352 in the rack server.

[0068] In other embodiments, redundant server group 300 includes cloud servers of a cloud computing environment, fog servers of a fog computing environment, where the fog computing environment is hosted, for example, by an organization that operates physical process plant 100, or any suitable combination thereof. For example, a cloud computing environment may include servers that control processes in process plants across the United States or even around the world, while a fog computing environment may include servers that control processes in physical process plants 100 in a particular city or town.

[0069] A control manager 352 communicates with multiple servers 350a-n in the redundant server group 300. Each of the servers 350a-n and the control manager 352 may be a physical machine (e.g., hardware) or a virtual machine (e.g., software). Thus, a single blade may host multiple guest virtual machines or servers. In any case, the control manager 352 includes a control executive 354, a load balancer 302, a shadow database 304, a redundancy manager 306, and a control module 308. Each of the servers 1-n (referenced 350a-n) includes a processor 310a-n, such as a multi-core processor or another type of parallel processor, and a memory 312a-n, which may be a high-density memory. Each of the memories 312a-n may store various routines assigned to the respective server 350a-n, including the control modules 314a-n, the DCS application modules 316a-n, and the redundancy modules 318a-n.

[0070] In addition to storing and executing routines for controlling and monitoring operations within the physical process plant 100, the servers 350a-n may provide availability or status indicators to the control manager 352. In some embodiments, each of the servers 350a-n provides an availability metric for a particular time interval to the control manager 352 based on the load at the server 350a-n, the available amount of memory at the server 350a-n, and the bandwidth for transmitting data from the server 350a-n for the particular time interval. In other embodiments, each of the servers 350a-n provides an indicator of the load at the server 350a-n, the available amount of memory at the server 350a-n, and the bandwidth for transmitting data from the server 350a-n for the particular time interval. The control manager 352 then determines an availability metric for each server 350a-n for the particular time interval based on this information. The load on a server 350a-n may indicate the amount of processing being performed by the server 350a-n, as well as the processing capabilities of the server 350a-n (e.g., single core, dual core, quad core, etc.). The availability metric may also take into account servers that have failed or are otherwise unavailable based on the server's inability to provide instructions or respond to the control manager 352.

[0071] Operations to be performed by the servers 350a-n of the redundancy server group 300 may be received by a control executive 354 of the control manager 352. In some embodiments, the redundancy manager 306 generates a redundancy module for each control module 308 retrieved by the control manager 352. The redundancy module may be such that the server 350a-n executing the redundancy module receives the same inputs, outputs, set points, etc. received and provided by the server 350a-n executing the control module without executing a control loop or function contained in the control module. In some embodiments, the control executive 354 provides each of the retrieved control modules 308 to the redundancy manager 306 for the redundancy manager to generate a corresponding redundancy module.

[0072] Also, in some embodiments, the control executive 354 assigns a priority level to each of the control modules, redundancy modules, and DCS application modules and ranks the modules in order of decreasing priority. The priority levels may be assigned automatically based on a predefined set of priority rules (e.g., a redundancy module has the same priority level as the corresponding control module, a control module has a higher priority level than a DCS application module, etc.). Additionally or alternatively, a user may assign a priority level to each of the modules. For example, when a configuration engineer creates a control module via a configuration application, the configuration engineer may assign a priority level for the control module.

[0073] The control executive 354 may communicate with the load balancer 302 to determine which servers 350a-n should execute which control modules 308, redundant modules, and DCS application modules within a particular time interval. In some embodiments, the load balancer 302 receives availability metrics for each of the servers 350a-n and a list of the control modules, redundant modules, and DCS application modules to be executed within a particular time interval, which may include a respective priority level for each of the modules. The load balancer 302 then assigns a server 350a-n in the redundant server group 300 to execute each of the modules. In some scenarios, a single server 350a-n may execute multiple modules within the same time interval, depending on the parallel processing capabilities and memory density of the servers 350a-n. In another example scenario, the load balancer 302 identifies two different servers 350a-n running a control module and a redundant module, and enables the server 350a-n running the redundant module to run the redundant module in place of the server 350a-n running the control module in the event of a controller failure.

[0074] In some embodiments, the load balancer 302 identifies characteristics of each of the modules, such as whether each module is executed periodically or based on the occurrence of an event (event-driven), the execution time of each module, or other suitable characteristics. The load balancer 302 then identifies a server 350a-n on which to run the module based on the availability metrics of the servers 350a-n and the priority level and characteristics of the module. More specifically, the load balancer 302 uses a load balancing algorithm to assign a server 350a-n to run the module.

[0075] For example, the load balancer 302 may rank each of the servers 350a-n according to their respective availability metrics, with the servers 350a-n with the highest availability metrics having the most availability and ranking highest. The load balancer 302 may also rank each of the modules based on a combination of each module's priority and each module's characteristics. In some embodiments, the periodic modules are ranked higher than the event-driven modules, and then each of the periodic modules is sorted based on priority level, and each of the event-driven modules is sorted based on priority level. Each of the periodic modules in the high priority category may be ranked higher than each of the periodic modules in the medium priority category. Periodic or event-driven modules within the same priority category may also be further ranked based on execution time. More specifically, if there are three priority categories (high, medium, low) and there are periodic and event-driven modules, then the high priority periodic modules are ranked first, where each module in this category may be further ranked in order of execution time, followed by medium priority periodic modules, low priority periodic modules, high priority event-driven modules, etc.

[0076] Thus, the load balancer 302 may rank the servers 350a-n and may rank the modules. In the above example, the servers 350a-n are ranked in order of availability metrics and the modules are ranked in order of priority level and module characteristics, but the servers 350a-n and modules may be ranked in any suitable manner.

[0077] The load balancer 302 may then use a reverse round robin mechanism to first assign the highest ranked module (e.g., the high priority periodic module with the longest execution time) to the highest ranked server 350a-n (e.g., the controller with the highest availability metric). The second highest ranked module may be assigned to the second highest ranked server 350a-n, and the algorithm may continue in this manner until a module has been assigned to the lowest ranked server 350a-n. If there are more modules to assign, the load balancer 302 continues assigning modules in reverse order. For example, the load balancer 302 may also assign the next module to the lowest ranked server 350a-n, then assign the module ranked below the next module to the second lowest ranked server 350a-n, and continue in increasing order until the highest ranked server 350a-n has two modules assigned. The load balancer 302 then again reverses the order of assigning the modules in decreasing order and continues in reverse round robin fashion until each of the modules has been assigned to a server 350a-n.

[0078] Although the load balancer 302 may use a reverse round robin mechanism to rank the servers 350a-n and the modules and assign the modules to the servers 350a-n, the load balancer 302 may assign the modules to the servers 350a-n in any suitable manner to distribute the modules among the servers 350a-n in the redundant server group 300. In other embodiments, the modules are distributed equally or at least similarly among the servers 350a-n without regard to priority level or characteristics. In yet another embodiment, the load balancer 302 assigns modules to the same server 350a until processing on the server 350a reaches capacity. The load balancer 302 may then assign the modules to another server 350b until processing on the other server 350b reaches capacity, and the load balancer 302 may continue to assign modules in this manner.

[0079] In any event, the control executive 354 provides the assigned modules to the corresponding servers 350a-n so that each server 350a-n can execute the assigned modules. In some embodiments, the control executive 354 may analyze the assignments and adjust some of the assignments to ensure that multiple servers 350a-n do not provide control signals for the same field devices and / or the same parameters within the same time interval.

[0080] In an example scenario, during a first time interval, server 350a may be assigned a first set of modules. Control executive 354 may download control module 314a, DCS application module 316a, and redundancy module 318a to server 350a during the first time interval. Then, during a second time interval, server 350a may be assigned a second set of modules that are different from the first set of modules. Control executive 354 may download new control module 314a, DCS application module 316a, and redundancy module 318a to server 350a during the second time interval.

[0081] In another exemplary scenario, during a particular time interval, the control manager 352 assigns a first control module to the first server 350a, where the first control module corresponds to a first subset of the field devices 125-132, 140-150. The control manager 352 assigns a second control module to the second server 350b, where the second control module corresponds to a second subset of the field devices 125-132, 140-150. Thereafter, the first server 350a executes the first control module and the second server 350b executes the second control module during the same time interval. During a later time interval, the first server 350a is no longer assigned the first control module and the second server 350b is assigned both the first and second control modules. For example, the first server 350a may fail to execute the first control module or may not have the processing resources during the later time interval. And, the second server 350b executes the first and second control modules of the first and second subsets of the field devices 125-132, 140-150, respectively, during the later time interval.

[0082] In some embodiments, periodic modules remain assigned to the same server 350a-n for several time intervals, while event-driven modules may be reassigned to servers 350a-n at each time interval based on the availability metrics of the server 350a-n at the particular time interval. In other embodiments, each of the control modules, DCS application modules, and redundancy modules are downloaded to each of the servers 350a-n prior to execution (e.g., when the modules are created) and stored in the respective memory 212a-n. Once the control executive 354 selects a server 350a to execute a particular module, the control manager 352 provides an indication of the particular module to the selected server 350a, and the selected server 350a retrieves the particular module from memory 212a and executes the particular module via the processor 310a.

[0083] In some embodiments, the control manager 352 includes a shadow database 304 that stores input data for the control modules, redundancy modules, and DCS application modules. The input data for the modules may be obtained from the user interface device 170b, for example, when the modules are configured or created. The input data may also be obtained from the servers 350a-n when the servers 350a-n execute the control modules 314a-n and DCS application modules 316a-n. Output from the control modules 314a-n and DCS application modules 316a-n may be received in the shadow database 304 from the servers 350a-n and stored as input data for the control modules, redundancy modules, and DCS application modules executed at subsequent time intervals.

[0084] In some embodiments, the control manager 352 may further provide availability information regarding the status or availability of the servers 350a-n. Such information may include total load or availability metrics of the redundant server group 300, availability metrics of the individual servers 350a-n, operational status of the individual servers 350a-n (e.g., operational or non-operational), or other similar metrics. In some embodiments, the control manager 352 may further provide usage information regarding resource usage within the redundant server group 300, such information indicating the processing resources required or expected to be required to run the control modules, redundant modules, and DCS application modules within the servers 350a-n. From the availability and usage information, the control manager 352 may further calculate or predict optimal resource allocations for the redundant server group 300, such as the number or type of servers 350a-n to be connected within the redundant server group 300. Such calculations or predictions may be presented to an operator to enable adjustment of the hardware configuration of the redundant server group 300 (e.g., adding or replacing a server). In some embodiments, such calculations or predictions may be performed by a DCS application, such as asset management application 223 or other DCS application 229.

[0085] Configuring and operating a software-defined DCS environment 4 illustrates a flow diagram of an exemplary software-defined DCS configuration and control method 400 for a physical process plant 100 controlled by a software-defined process controller of software-defined DCS environment 200. Virtual DCS configuration and control method 400 may be performed to configure, operate, monitor, and tune a process control system for operating a process in physical process plant 100 using software-defined DCS environment 200 as described above. Some aspects of software-defined DCS configuration and control method 400 may be performed manually or, in some embodiments, automated. Alternative embodiments may include additional, fewer, or alternative aspects.

[0086] The software-defined DCS configuration and control method 400 begins with connecting at least some of the field devices 125-132, 140-150 to the server group 210 via I / O connections 240 (block 402). This may include physically connecting the field devices 125-132, 140-150 while they are physically installed in the plant or when the field devices are added to an existing process control network. In some embodiments, the field devices 125-132, 140-150 may be connected after installation in the plant by establishing software-defined communication connections via the I / O connections 240, such as by establishing publication / subscription connections in an I / O server. In some embodiments, it is not necessary for all field devices 125-132, 140-150 to be connected to the server group 210 for control of the process, and some field devices 140-150 may instead be directly connected to the server group 210 via a wireless gateway 168 in some embodiments.

[0087] Once the associated field devices 125-132, 140-150 are connected to the server group 210, the software-defined DCS network architecture is configured to represent the process control network of the field environment 102 as a software-defined network of nodes and connections in the software-defined DCS environment 200 (block 404). To configure the software-defined DCS network architecture, the virtual architecture configuration application 225 may generate and present a user interface to a user (e.g., a technician configuring a process control system), which may include multiple options for configuring the components and connections in the software-defined DCS network. In this manner, the user may be presented with options for adding, deleting, editing, connecting, and specifying parameters for the software-defined components via the user interface. Upon receiving user input from the user, the virtual architecture configuration application 225 may define the software-defined DCS network architecture by specifying the nodes and connections in the software-defined DCS network based on the user input. Additionally or alternatively, some or all of the software-defined DCS network architecture may be automatically determined by the virtual architecture configuration application 225 based on information regarding the type of process data received from components of the field environment 102, such as the field devices 123-132, 140-150, etc. The information regarding the type of process data may be determined based on data traffic from the field devices 123-132, 140-150 on the I / O connections 240. In some such embodiments, the information regarding the type of process data received from such components of the field environment 102 may be obtained by the virtual architecture configuration application 225 from the I / O connections 240 (e.g., from an I / O server).In further such embodiments, the determined types of process data may be presented to an operator for review or adjustment via a user interface of the virtual architecture configuration application 225. The software-defined DCS network architecture is then stored in a database or data store 230 of the server group 210 for use by the software-defined process controllers and DCS applications (e.g., the virtual DCS controller 212 and the DCS applications 221-225, 229).

[0088] In some embodiments, the software-defined DCS network architecture provides multiple classes of service to various components that comprise the software-defined DCS environment to ensure proper handling of resource requirements. For example, real-time processes (e.g., process control by control modules) are assigned a high priority class to ensure that time-sensitive process control routines are prioritized over analytical processes of the DCS application. In further embodiments, multiple classes of real-time processes may be used to give higher priority to process-critical or safety-critical processes. Similarly, classes may be used based on or to differentiate between bandwidth requirements of processes within the software-defined DCS environment 200.

[0089] Subsequently, the server group 210 prepares to execute the process control in advance. During operation of the physical process plant 100, the software-defined process controller (e.g., the virtual DCS controller 212) receives process data from the field devices 125-132, 140-150 (block 406) and implements process control logic for controlling the process in real time (block 408). The process data may be generated by and received by one or more of the field devices 125-132, 140-150 via the I / O connections 240. At least a portion of such process data is then used by the software-defined process controller to generate process control signals for controlling the process in the physical process plant 100. Such process control signals are then sent to one or more of the field devices 125-132, 140-150 to implement a control action (e.g., adjusting a valve position or controlling a heating element) for controlling the process. The process control signals may be sent via I / O connections 240 to the associated field devices 125-132, 140-150.

[0090] Also, during operation of the process, the server group 210 implements one or more DCS applications 221-225, 229 to interact with the software-defined process controller (block 410). The DCS applications 221-225, 229 may execute within the server group 210. In some embodiments, the operator interface application 222 may operate to adjust the operation of one or more of the software-defined process controllers, such as adjusting set points or adjusting control modules used by the software-defined process controllers to improve process control. Such adjustments may be made automatically by the DCS applications 221-225, 229 or in response to user input. Of course, any combination of the DCS applications 221-225, 229 may be executed while the process is running within the physical process plant 100, or at other times before, after, or during the execution of the process. As an example, the data historian application 224 may operate while a process is ongoing to monitor process data within the software-defined DCS environment 200 and store such process data for later analysis in the database or data store 230. Such monitoring may include selecting a subset of the available process data (e.g., by sampling the process data or by selecting relevant data received from the field environment 102 or generated by the virtual DCS controller 212), or the data historian application 224 may be configured to automatically monitor and store all available process data during operation of the physical process plant 100.

[0091] In some embodiments, the server group 210 may also perform load balancing among the servers or other server devices in the server group 210 during operation of the process (block 412), as discussed above. To perform such load balancing, the server group 210 may simultaneously implement multiple instances of each of the software-defined process controllers (or their control modules) on different servers in the server group 210. Upon detecting a change to the status of one of the servers (e.g., a server failure, addition of a server, a server load jump-in, or a server load drop-in), the server group 210 adjusts the load distribution among the multiple servers in the server group 210 based on the detected change to maintain efficient control of the process by the software-defined process controller. Such adjustments to the load distribution may include, for example, shifting control of a portion of the process from an instance of the virtual DCS controller 212 running on a first server to another instance of the virtual DCS controller 212 running on a second server. In some such embodiments, a new instance of the virtual DCS controller 212 may be started on a third server in the server group 210 to maintain redundancy and protect against a subsequent failure of the second server.

[0092] In a further embodiment, the server group 210 may receive an indication of a change to the network architecture of the field environment 102 (block 414) and modify the software-defined DCS network architecture to reflect such change (block 416). As with the initial configuration of the software-defined DCS network architecture, an indication of the change to the network architecture may be received from an operator via the virtual architecture configuration application 225, or the indication of the change may be generated automatically based on detecting a change in the type of process data received as data traffic at the I / O connections 240. For example, a user may indicate via user input that one or more of the field devices 125-132, 140-150 will be replaced with a new field device, and such replacement may be detected based on detecting a change in the data traffic received from the new field device. In response to such an indication of a change in the physical network architecture in the field environment 102, the virtual architecture configuration application 225 adjusts the software-defined DCS network architecture to represent the changed physical network architecture. Such adjustments may include adding, removing, or modifying nodes or connections in the software-defined DCS network architecture. Such modifications to the software-defined DCS network architecture are then stored in a database or data store 230 of the server group 210 for use by the software-defined process controllers and DCS applications. In some embodiments, adjustments to one or more of the software-defined process controllers may be determined based on the adjustments to the software-defined DCS network architecture. For example, a control loop in a software-defined process controller may be adjusted based on the addition, replacement, or removal of a field device in the field environment 102 that changes the process data available for process control.

[0093] The software-defined DCS configuration and control method 400 may continue to perform process control as described above until it is determined that the controlled process in the physical process plant 100 is no longer in progress (block 418). Once the process has terminated, the software-defined DCS configuration and control method 400 may also terminate.

[0094] Other considerations The following additional considerations apply to the above discussion: Throughout this specification, actions described as being performed by any device or routine generally refer to the actions or processes of a processor that manipulates or transforms data according to machine-readable instructions. The machine-readable instructions may be stored on and retrieved from a memory device communicatively coupled to the processor. In other words, the methods described herein may be embodied by a series of machine-executable instructions stored on a computer-readable medium (i.e., on a memory device). The instructions, when executed by one or more processors of a corresponding device (e.g., a server, an operator workstation, a controller, a control manager, a user computing device, etc.), cause the processor to perform the method. When instructions, routines, modules, processes, services, programs, and / or applications are referred to herein as being stored or saved on a computer-readable memory or on a computer-readable medium, the terms "stored" and "stored" exclude transient signals.

[0095] Additionally, terms such as "operator," "personnel," "people," "users," "technicians," "engineers," and the like are used to describe persons in a process plant environment who may use or interact with the systems, devices, and methods described herein, but these terms are not intended to be limiting. When particular terms are used in the description, the terms are used in part for traditional activities engaged in by plant personnel, but are not intended to limit the personnel who may engage in a particular activity.

[0096] Additionally, throughout this specification, unless expressly or implicitly limited by the context of the description, multiple instances may implement components, operations, or structures described as a single instance. Although individual operations of one or more methods have been illustrated and described as separate operations, one or more of the individual operations may be performed simultaneously, and the operations need not be performed in the order illustrated. Structures and functions presented as separate components in an exemplary configuration may be implemented as a combined structure or component. Similarly, structures and functions presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements are within the scope of the subject matter of this specification.

[0097] Unless specifically stated otherwise, discussions herein using words such as "processing," "operating," "calculating," "determining," "identifying," "presenting," "causing to present," "displaying," "displaying," and the like may refer to the actions or processes of a machine (e.g., a computer) that manipulates or transforms data represented as physical (e.g., electrical, magnetic, biological, or optical) quantities in one or more memories (e.g., volatile memory, non-volatile memory, or a combination thereof), registers, or other mechanical components that receive, store, transmit, or display information.

[0098] When implemented in software, any of the applications, controllers, services, or engines described herein may be stored in any tangible, non-transitory computer-readable memory, such as a magnetic disk, laser disk, solid-state memory device, molecular memory storage device, or other storage medium, such as in the RAM or ROM of a computer or processor. It should be noted that while the exemplary systems disclosed herein are disclosed to include software and / or firmware running on hardware, among other components, such systems are merely exemplary and should not be considered limiting. For example, it is contemplated that any or all of these hardware, software, and firmware components may be embedded solely in hardware, solely in software, or in any combination of hardware and software. Thus, one skilled in the art will readily appreciate that the examples provided are not the only ways to implement such a system.

[0099] Thus, while the invention has been described with reference to specific examples, it will be apparent to those skilled in the art that these examples are illustrative only and are not intended to be limitations of the invention, and that modifications, additions, or deletions may be made to the disclosed embodiments without departing from the spirit and scope of the invention.

[0100] It should also be understood that unless a term is expressly defined in this patent using the sentence "As used herein, the term '_____' is defined herein to mean ..." or a similar sentence, there is no intention, either expressly or by implication, to limit the meaning of the term beyond its plain or ordinary meaning, and such term should not be construed as limited in scope based on any statement made in any section of this patent (other than the claim language). To the extent that any term recited in the final claims of this patent is referred to in this patent in a manner consistent with a single meaning, it is done merely for clarity so as not to confuse the reader, and it is not intended that such claim term be limited, by implication or otherwise, to that single meaning. Finally, unless the claim element is defined by the words "means" and a recitation of a function without any recitation of structure, the scope of any claim element is not intended to be construed under application of 35 U.S.C. § 112(f).

[0101] Moreover, although the above text describes detailed descriptions of many different embodiments, it should be understood that the scope of this patent is defined by the language of the claims set forth at the end of this patent. The detailed description should be construed as merely exemplary and does not describe all possible embodiments, as describing all possible embodiments would be impractical, if not impossible. Many alternative embodiments could be implemented using either current technology or technology developed after the filing date of this patent, which would still fall within the scope of the claims.

Claims

1. 1. A server group including a plurality of server devices configured to implement a software-defined distributed control system (DCS) environment by executing computer-readable instructions by one or more processors of each of the server devices, the software-defined DCS environment comprising: one or more software-defined process controllers configured to control at least a portion of an industrial process in real time by communicating with a plurality of field devices in a physical process environment, wherein controlling the plurality of field devices includes: (i) generating control signals in the software-defined DCS environment; and (ii) transmitting the control signals to the plurality of field devices by transmitting the control signals to a plurality of virtual nodes in the software-defined DCS environment that represent the plurality of field devices; an I / O server configured to communicatively couple the plurality of virtual nodes to each of the plurality of field devices in the physical process environment by mapping each virtual node in the software-defined DCS environment to a corresponding physical node associated with a corresponding field device in the physical process environment; one or more DCS applications configured to interact with the software-defined process controller, at least one of the DCS applications configured to coordinate operation of the software-defined process controller; one or more connection components, including one or more ports, switches, or routers, configured to: (i) connect to the server group and send and receive the control signals using a general purpose computer communication protocol used for communication between the server devices of the server group; (ii) convert the control signals between the general purpose computer communication protocol and an industrial process control communication protocol used for communication by the plurality of field devices over a process control network in the physical process environment; and (iii) connect to the plurality of field devices over the process control network and send and receive the control signals using the industrial process control communication protocol; a process control system for controlling an industrial process within said physical process environment, said process control system including a server group including:

2. 10. The process control system of claim 1, wherein the software-defined DCS environment further includes one or more virtual networking components configured to replicate one or more physical network components of a network switch, a router, or a firewall.

3. 3. The process control system of claim 1 or claim 2, wherein the one or more DCS applications include a virtual architecture configuration application having a user interface configured to enable a user to define the virtual DCS network architecture representing the process control system architecture of a physical process control system in the software-defined DCS environment by specifying the plurality of virtual nodes in a virtual DCS network architecture as identifiers of respective devices or components in the physical process environment and connections between the virtual nodes, such virtual nodes including virtual representations of the plurality of field devices as identifiers of respective field devices in the virtual DCS network architecture.

4. 4. The process control system of claim 1, wherein the one or more DCS applications include a data historian application configured to automatically store process data within the software-defined DCS environment during operation of the industrial process.

5. The process control system of claim 1 , wherein the one or more DCS applications include one or more functions of an operator interface, an engineering workstation, or an asset management system.

6. The process control system of claim 1 , wherein the one or more DCS applications include one or more functions of a manufacturing execution system or an advanced process control system.

7. The process control system of claim 1 , wherein the one or more DCS applications include a network gateway for communicating with an external data network.

8. The process control system of claim 1 , wherein the one or more software-defined process controllers include multiple instances of a virtual DCS controller running simultaneously on different server devices of the server group.

9. 9. The process control system of claim 8, wherein the server group is configured to perform automatic load balancing among the multiple instances of the virtual DCS controller based on a status of the multiple server devices in the server group.

10. The process control system of any one of claims 1 to 9, wherein the one or more DCS applications include an application configured to predict an optimal number of server devices for the server group based on resource usage of the server group and resource availability of the plurality of server devices.

11. 1. A non-transitory computer readable medium having executable instructions stored thereon for controlling an industrial process in a physical process environment, the instructions, when executed by processors of a plurality of server devices in a server group, causing the server group to implement a software-defined distributed control system (DCS) environment, the software-defined DCS environment comprising: one or more software-defined process controllers configured to control at least a portion of the industrial process in real time by communicating with a plurality of field devices in the physical process environment, where controlling the plurality of field devices includes: (i) generating control signals in the software-defined DCS environment; and (ii) sending the control signals to the plurality of field devices by sending the control signals to a plurality of virtual nodes in the software-defined DCS environment that represent the plurality of field devices; an I / O server configured to communicatively couple the plurality of virtual nodes to each of the plurality of field devices in the physical process environment by mapping each virtual node in the software-defined DCS environment to a corresponding physical node associated with a corresponding field device in the physical process environment; one or more DCS applications configured to interact with the software-defined process controller, at least one of the DCS applications configured to coordinate operation of the software-defined process controller; The executable instructions further cause the server group to communicate with the plurality of field devices through one or more connection components, including one or more ports, switches, or routers, configured to: (i) connect to the server group and send and receive the control signals using a general purpose computer communication protocol used for communication among the server devices of the server group; (ii) convert the control signals between the general purpose computer communication protocol and an industrial process control communication protocol used for communication by the plurality of field devices over a process control network in the physical process environment; and (iii) connect to the plurality of field devices over the process control network and send and receive the control signals using the industrial process control communication protocol. Non-transitory computer-readable medium.

12. 12. The non-transitory computer-readable medium of claim 11, wherein the software-defined DCS environment further includes one or more virtual networking components configured to replicate one or more physical network components of a network switch, a router, or a firewall.

13. 13. The non-transitory computer-readable medium of claim 11 or 12, wherein the one or more DCS applications include a virtual architecture configuration application having a user interface configured to enable a user to define the virtual DCS network architecture representing a process control system architecture of a physical process control system in the software-defined DCS environment by specifying the plurality of virtual nodes and connections between the virtual nodes in a virtual DCS network architecture as identifiers of respective devices or components in the physical process environment, such virtual nodes including virtual representations of the plurality of field devices as identifiers of respective field devices in the virtual DCS network architecture.

14. 14. The non-transitory computer-readable medium of claim 11, wherein the one or more DCS applications include a data historian application configured to automatically store process data within the software-defined DCS environment during operation of the industrial process.

15. 15. The non-transitory computer-readable medium of claim 11, wherein the executable instructions cause the multiple server devices of the server group to implement multiple instances of each of one or more virtual DCS controllers as the one or more software-defined process controllers, the multiple instances running simultaneously on different server devices of the server group.

16. 16. The non-transitory computer-readable medium of claim 15, wherein the executable instructions cause the server group to perform automatic load balancing among the multiple instances of the virtual DCS controller based on a status of the multiple server devices in the server group.

17. 1. A method for controlling an industrial process within a physical process environment, comprising: connecting a plurality of field devices in the physical process environment via one or more input / output (I / O) connections to a server group of a plurality of server devices configured to implement a software-defined distributed control system (DCS) environment; the field devices are connected to a physical I / O server via one or more connection components, including one or more ports, switches, or routers, the connection components being configured to: (i) connect to the server group and send and receive control signals using a general purpose computer communication protocol used for communication among the server devices of the server group; (ii) translate the control signals between the general purpose computer communication protocol and an industrial process control communication protocol used for communication by the plurality of field devices over a process control network in the physical process environment; and (iii) connect to the plurality of field devices over the process control network and send and receive the control signals using the industrial process control communication protocol; configuring an I / O server of the server group to communicatively couple a plurality of virtual nodes in the software-defined DCS environment representing the plurality of field devices to each of the plurality of field devices in the physical process environment by mapping each virtual node in the software-defined DCS environment to a corresponding physical node associated with a corresponding field device in the physical process environment in the server group; receiving process data from the plurality of field devices at the server group via the one or more input / output (I / O) connections; controlling at least a portion of the industrial process in real time by one or more software-defined process controllers operating in the software-defined DCS environment on the server group by communicating with the plurality of field devices in the physical process environment, wherein controlling the plurality of field devices includes: (i) generating control signals in the software-defined DCS environment; and (ii) transmitting the control signals to the plurality of field devices by transmitting the control signals to the plurality of virtual nodes; and coordinating operation of the one or more software-defined process controllers by one or more DCS applications configured to operate in the software-defined DCS environment on the server group and interact with the software-defined process controllers.

18. the one or more DCS applications include a virtual architecture configuration application; generating, by the virtual architecture configuration application, a user interface for a user, the user interface including a plurality of options for configuring virtual components within the software-defined DCS environment; 20. The method of claim 17, further comprising: receiving user input from the user to define, in the one or more DCS applications, the virtual DCS network architecture representing a process control system architecture of a physical process control system in the software-defined DCS environment by specifying the plurality of virtual nodes in a virtual DCS network architecture as identifiers of respective devices or components in the physical process environment and connections between the virtual nodes.

19. 20. The method of claim 18, wherein the virtual node comprises one or more virtual representations of the plurality of field devices as identifiers of respective field devices within the virtual DCS network architecture.

20. automatically monitoring process data within the software-defined DCS environment during operation of the industrial process by a data historian application running in the software-defined DCS environment on the server group; The method of claim 17 , further comprising automatically storing the process data monitored by the data historian application in a data store associated with the server group.

21. detecting, by the one or more DCS applications, a type of process data associated with a field device of the plurality of field devices based on data traffic on the one or more I / O connections; 21. The method of claim 17, further comprising determining, by the one or more DCS applications, to adjust the operation of the one or more software-defined process controllers based on the type of the process data.

22. the one or more software-defined process controllers include multiple instances of each of one or more virtual DCS controllers executing simultaneously on different server devices of the server group; detecting, by the one or more DCS applications, a change in the status of one of the plurality of server devices of the server group; 22. The method of claim 17, further comprising: adjusting, by the one or more DCS applications, load distribution among the plurality of server devices based on the change in status.

Images