Industrial control system hyperconverged architecture

Abstract

An ultra-converged industrial process control architecture is disclosed for controlling an industrial process within a physical process environment using a software-defined distributed control system (DCS) environment. The software-defined DCS environment can be implemented by virtualizing hardware components of a DCS architecture on a server farm to enable both software-defined process controllers and backend DCS applications to run within the server farm. This software-defined DCS network architecture reduces hardware requirements and configuration complexity of a process control system by implementing control components and higher-level components within a common environment within the server farm.

Description

TECHNICAL FIELD

[0001] The present patent application relates generally to industrial and process control systems, and more specifically, to industrial control systems that use a software-defined architecture to provide runtime process control. BACKGROUND

[0002] Process or industrial control systems, like those used in chemical, petroleum or other industrial process plants to manufacture physical products from materials, typically include one or more process controllers communicatively coupled to one or more field devices via analog, digital or combined analog / digital buses or via a wireless communication link or network. The field devices, which can be, for example, valves, valve positioners, switches and transmitters (e.g., temperature, pressure, level and flow rate sensors), are located within the process plant environment and generally perform physical or process control functions within the process. Smart field devices, such as field devices compatible with the Fieldbus protocol, can also perform control calculations, alarm functions, and other control functions commonly implemented within a controller. The process controllers, which can be Wireless and The controllers receive signals indicative of process measurements made by the field devices and / or other information related to the field devices from the communication buses or wireless communication links and use this information to

[0003] Information from the field devices and controllers is typically provided 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 management, computing, or planning devices, through data highways from the controllers. Each of these hardware devices is typically centralized relative to the process plant or a portion thereof. These hardware devices execute applications, for example, that can enable an engineer to configure a portion of the process, or that can enable an operator to execute functions related to controlling a process and / or operating a process plant (such as changing settings of process control routines, modifying the operation of control modules within the controllers or field devices, viewing the current status of a process, viewing alarms generated by field devices and controllers, simulating operation of the process for the purposes of training personnel or testing the process control software, maintaining and updating configuration databases, etc.). Data highways used by the hardware devices, controllers, and field devices can include wired communications paths, wireless communications paths, or a combination of wired and wireless communications paths.

[0004] As an example, the DeltaV™ control system, sold by Emerson Process Management includes a suite of applications and tools for designing and operating DCS and skid-mounted rack TMThe control system includes a number of applications that are stored and executed within different devices located at different places within the process plant. A configuration application resident on one or more workstations or computing devices enables a user to create or change process control modules and to download these process control modules to dedicated distributed controllers via a data highway. Typically, these control modules are made up of function blocks that are communicatively interconnected, that are objects in an object-oriented programming protocol, that perform functions within control schemes based upon inputs thereto, and that provide outputs to other function blocks within the control scheme. The configuration application can also allow the configuration designer to create or change operator interfaces used by a viewing application to display data to an operator, and to enable the operator to change settings within the process control routines, such as set points. Each dedicated controller, and in some cases one or more field devices, stores and executes a respective controller application that runs the control modules distributed and downloaded thereto to implement the actual process control functionality. A viewing application, which can be executed on one or more operator workstations (or on one or more remote computing devices that are communicatively coupled to the operator workstations and to the data highway), receives data from the controller application via the data highway and uses user interfaces to display the data to process control system designers, operators, or users, and can provide any of a number of different views, such as operator views, engineer views, technician views, etc. A data historian application is typically stored and executed on a data historian device that collects and stores some or all of the data provided across the data highway, and a configuration database application can run on another computer attached to the data highway to store current process control routine configurations and data associated therewith. Alternatively, the configuration database can be located in the same workstation as the configuration application.

[0005] Current known process control plant and process control system architectures are strongly influenced by limited controller and device memory, communication bandwidth, and controller and device processor capabilities. For example, in current known process control system architectures, the use of dynamic and static non-volatile memory in controllers is typically minimized or at least carefully managed. As a result, during system configuration (e.g., a priori), a user or configuration engineer must typically select the data to be archived or saved in the controller, the frequency at which it will be saved, and whether compression will be used, and the controller is configured accordingly with this limited set of data rules. As a result, data that can be useful in troubleshooting and process analysis is typically not archived, and if data is collected, useful information can be lost due to data compression.

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

[0007] Similarly, in batch process control systems, to minimize controller memory usage, snapshots of batch recipes and controller configurations are typically kept stored at a centrally managed computing device or location (e.g., at a data warehouse or historian) and are only transferred to the controller when needed. Such a strategy introduces significant burst loads in communication in the controller and between the workstation or centrally managed computing device and the controller.

[0008] Furthermore, current architectures of industrial control systems, such as process control systems, are largely hardware driven, as various functions such as control functions, input / output (I / O) functions, user interface functions, etc. are executed in and bound to specific hardware (e.g., user workstations or interface devices, process controllers, safety system controllers, dedicated I / O devices, grouped I / O devices, field devices, safety logic solvers, etc.) and remain stored in that specific hardware at all times. For example, in current process control systems, the interconnections between controllers and I / O devices (e.g., individual I / O devices or groups of grouped I / O devices) are configured based on specific hardware, and thus the physical I / O relationships are tightly bound, typically in a one-to-one fashion (e.g., I / O device to controller, another I / O device to another controller, etc.). Such architectural design limits the resilience, reliability, availability, responsiveness, and elasticity of control systems, as these systems are difficult to quickly change or reconfigure and are tightly tied to proprietary hardware used to implement proprietary control software, requiring hardware redundancy on a device-by-device basis, which can result in high implementation costs and are not easily scalable or upgradeable without adding additional hardware that needs to be configured in a specific manner (e.g., due to size limitations of individual devices such as physical process controllers, or specific characteristics and capabilities of I / O devices).

[0009] Additionally, current control system architectures separate online process control applications and other related applications into multiple function-specific devices that communicate over a process plant communication network. As a result, process control systems require additional hardware devices that must be individually configured to communicate with other devices with which they interact. For example, replacing or reconfiguring a field device within a process plant can require reconfiguring multiple controllers that interact with that field device, as well as multiple workstations and higher-level applications that monitor data associated with this field device. SUMMARY

[0010] Described herein is a hyper-converged distributed control system (DCS) architecture for industrial process control that implements software-defined process controllers and related applications in a combined software-defined DCS environment. The software-defined DCS environment can virtualize hardware components of the DCS architecture within a software-defined virtual network that operates on standard hardware components, thereby allowing these components to be managed as software components. Such a software-defined DCS environment can be implemented within a server group, such as a privately-hosted cloud computing system, which reduces the hardware requirements of the system and the configuration required to establish the system. Described herein are systems, methods, and computer-readable media storing executable instructions for controlling an industrial process within a physical process environment. Such systems, methods, and instructions can 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 within a 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 the 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 also includes one or more virtual networking components configured to replicate one or more of the following physical network components: a network switch, a router, or a firewall.

[0012] In some embodiments, at least one of the DCS applications is configured to adjust operation of the software-defined process controller. In further embodiments, the DCS applications can provide various functionality within the software-defined DCS environment. The DCS applications can 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 within the virtual DCS network architecture and connections between the virtual nodes. Such virtual nodes can include virtual representations of the plurality of field devices. Additionally or alternatively, the DCS applications can also include a data historian application configured to automatically store process data within the software-defined DCS environment during operation of the industrial process. In further embodiments, the DCS applications can include one or more of the following functionalities: 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 can include a network gateway to communicate with external data networks.

[0013] In further embodiments, the server group can be configured to use the plurality of server devices to provide load balancing or redundancy. In such embodiments, the one or more software-defined process controllers include a plurality of instances of a virtual DCS controller running concurrently on different server devices of the server group. The server group can thus be configured to perform automatic load balancing between the plurality of instances of the virtual DCS controller based on a status of the plurality of server devices in the server group. In further embodiments, the DCS applications can include an application configured to predict an optimal number of server devices of the server group based on resource usage of the server group and resource availability of the plurality of server devices.

[0014] According to aspects of the systems, methods, and computer-readable media storing executable instructions for controlling an industrial process within a physical process environment described herein, techniques for controlling an industrial process within a physical process environment can include: (i) connecting a plurality of field devices within the physical process environment to a server group comprising a plurality of server devices, the server group configured to implement a software-defined DCS environment through one or more I / O connections; (ii) controlling, in real-time, at least a portion of the industrial process by one or more software-defined process controllers running in the software-defined DCS environment on the server group through communication with the plurality of field devices within the physical process environment; (iii) adjusting 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 can receive process data from the plurality of field devices via the one or more I / O connections and send process control signals to the one or more field devices via the one or more I / O connections to control the portion of the industrial process. In some embodiments, the DCS applications can detect a type of process data associated with a field device of the plurality of field devices based on data traffic at the one or more I / O connections and determine an adjustment to operation of the one or more software-defined process controllers based on the type of process data. In further embodiments, DCS applications can provide load balancing by detecting a change in a state of one of the plurality of server devices of the server group and adjusting a load distribution among the plurality of server devices based on the change in the state. In some such embodiments, redundancy of the software-defined process controllers can also be provided by simultaneously implementing multiple instances of a virtual DCS controller on different server devices of the server group such that control can be transferred between the instances in the event of a control failure of one of the server devices.

[0016] In some embodiments, the DCS application can include a virtual architecture configuration application that generates a user interface for a user, the user interface including a plurality of options for configuring virtual components within the software-defined DCS environment, and receiving user input from the user to define a virtual DCS network architecture by specifying a plurality of virtual nodes within the virtual DCS network architecture and connections between the virtual nodes. Such virtual nodes can include one or more virtual representations of the plurality of field devices. In further embodiments, the DCS application can 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 DRAWINGS

[0017] Figure 1 A block diagram of an example physical process plant environment is illustrated in which a distributed control system (DCS) controls at least a portion of a process in an industrial or process plant.

[0018] Figure 2A and Figure 2B A block diagram of an example process plant is illustrated in Figure 1 which a software-defined DCS environment running on a server group controls at least a portion of the process plant.

[0019] Figure 3 A block diagram of an example redundant server group implementing a software-defined DCS environment (e.g., the server group shown in Figure 2A and 2B is illustrated.

[0020] Figure 4 A flow diagram of an example software-defined DCS architecture configuration and control method is illustrated. DETAILED DESCRIPTION

[0021] 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 a software-defined DCS architecture provides a hardware-independent and scalable control network by pooling resources within a process control system in a manner that allows components to be defined, managed, and controlled as software components. For example, a software-defined DCS architecture enables a software-defined process controller and backend DCS applications to be implemented on the same hardware (e.g., a group of servers forming a private cloud computing network). This combination of controllers and high-level applications in a software-defined DCS environment has a number of advantages. For example, this architecture allows standard server hardware to be used for process controllers instead of system-specific hardware, enabling scalability in a process control system by adding or removing servers in a server group. Further, implementing a virtual representation of multiple DCS process controllers (along with other DCS applications) in a server group eliminates the need for separate hardware for each controller and other backend systems. Additionally, the software-defined combination of software-defined process controllers and DCS applications within a server group eliminates the need to route process data to multiple controllers, reducing the complexity of the control system and the amount of work required to configure or update the system architecture. By implementing software-defined process controllers as virtual DCS controllers in a server group, load balancing and failover functionality can also be improved so that redundant virtual DCS controllers can be implemented in a resource-efficient manner across the servers of the server group. These advantages are merely exemplary, and other advantages of the software-defined DCS architecture described herein will be apparent to those of skill in the art based upon the disclosure below.

[0022] Physical process plant and process control system

[0023] Figure 1 is a block diagram of an exemplary 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 an industrial process (or, in some embodiments, operates in conjunction with a virtual plant environment to control an industrial process), where the industrial process can be said to have one or more“process outputs” (e.g., tank level, flow rate, material temperature, etc.) and one or more“process inputs” (e.g., various environmental conditions and states of actuators that are operated upon which can cause the process outputs to change) that characterize the state of the process. The physical process plant 100 includes a field environment 102 and a backend environment 105 that are each communicatively connected to one another by a process control backbone or data highway 108, which can include one or more wired and / or wireless communication links and / or networks, and can be implemented using any desired or suitable communication protocol (e.g., an Ethernet protocol, an IP protocol, or other packet protocol).

[0024] At the high level, the field environment 102 includes physical components (e.g., process control equipment, networks, network elements, etc.) that are installed and interconnected to operate in combination to control industrial processes during operation. In general, these physical components are located, set up, or otherwise included in the field environment 102 of the physical process plant 100, where raw materials are received and processed to produce one or more physical products (e.g., paper, finished oil products, pharmaceuticals, etc.). In contrast, the back-end environment 105 of the physical process plant 100 includes various physical components (e.g., computing devices, operator workstations, databases or data banks, etc.) that are shielded and / or protected from the harsh conditions and materials of the field environment 102. In some configurations, the various computing devices, databases, and other components and equipment included 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.

[0025] Physical process plant 100 site environment 102

[0026] like Figure 1 As shown, the field environment 102 includes one or more process controllers 110, which are communicatively connected to a high-speed data channel 108. Each process controller 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 controller 110 and the field devices. In general, in the process control industry, the term "I / O" is sometimes used in many related but different contexts. The term typically refers to a logical link or communication channel (e.g., an "I / O channel") that communicatively couples a field device to an I / O card or controller, but can be used when referring to many other concepts (such as physical devices used to send signals to or receive signals from field devices via an I / O channel (e.g., an "I / O device" or "I / O card") and connectors or terminals associated with the I / O device (e.g., an "I / O connector"). The I / O devices and I / O cards 112, 115 may be independent, single physical devices, each connected to a corresponding controller and one or more corresponding field devices, as shown. In some arrangements ( Figure 1I / O devices, cards, connectors, and other I / O related components (such as terminal blocks, modules, processors, etc.) are included in the I / O electronic marshalling system, which enables flexible I / O transmission between various types of multiple controllers and multiple field devices, as 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 the discussion to be clear and as used herein, the term “I / O device” generally includes physical I / O devices, cards, electronic marshalling systems, and components thereof, through 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 the various components to pass I / O data between the components.

[0027] In the process control industry, the term “I / O” can be used generally to refer to signals transmitted on I / O channels (e.g., “I / O signals”), variables or commands represented by the signals (e.g., “I / O parameters”), or values of the variables or commands carried by the signals (e.g., “I / O parameter values” or “I / O data payloads”). Thus, for the discussion to be clear and as used herein, I / O signals, I / O parameters, and I / O parameter values are collectively referred to herein as “I / O data” or “process I / O data.”

[0028] To the extent the term “I / O” is referenced herein without a qualifier, the context of the sentence should make clear which of these concepts is being discussed. Further, it should be understood that “I / O channels” represent a particular type of “communication channel” or “channel.” In other words, unless the context of the sentence dictates otherwise, a reference to the term “channel” or the term “communication channel” in this description without the qualifier “I / O” can refer in certain embodiments to a communication link that can be an I / O channel, but can also refer in certain embodiments to a communication link that is other than an I / O channel.

[0029] Using 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 behavior modules) that can be stored in the memory of the controller 110. When the processor of the controller executes the one or more control routines, the controller sends control signals (i.e., "control outputs") over wired or wireless process control communication links or networks to one or more field devices to control operation of the process in the plant 100. The controller can generate the control signals based on (i) one or more received signals, which can be referred to as "control inputs" (e.g., one or more received signals that represent measurements obtained by the field devices, and (ii) the logic of the one or more control routines, which can be defined by one or more software elements (e.g., function blocks). Typically, the controller manipulates a process input (which can be referred to as a "manipulated variable") based on feedback (i.e., a measurement of a controlled variable) and a desired value for a process output (i.e., a set point) to alter a particular process output (which can be referred to as a "controlled variable" or simply a "process variable").

[0030] Typically, at least one field device performs a physical function (e.g., opens or closes a valve, raises or lowers a temperature, makes a measurement, senses a condition, etc.) to control operation of a process implemented in the physical process plant 100. Certain types of field devices communicate with controllers by using I / O devices. Process controllers, field devices, and I / O devices can be wired or wireless, and any number and combination of wired and wireless process controllers, field devices, I / O devices can be included in the physical process plant 100.

[0031] For example, Figure 1 Process controllers 110 are illustrated that are communicatively connected to wired field devices 125-132 via input / output (I / O) devices 112 and 115, and to wireless field devices 140-146 via wireless gateway 168 and data highway 108. In some configurations (not shown), controllers 110 can communicatively connect to wireless gateway 168 using one or more communication networks other than data highway 108, such as by using any number of other wired or wireless communication links that support one or more communication protocols, such as, for example, Wi-Fi or other IEEE 802.11 compliant wireless local area network protocols, mobile communication protocols (e.g., WiMAX, LTE, or other ITU-R compliant protocols), Profibus, Fieldbus, etc.

[0032] For example, controllers 110 can be, for example, DeltaV TMA controller, which can be operable to implement a batch industrial process or a 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 (e.g., HART®, Fieldbus protocol, FOUNDATION® Fieldbus protocol, WirelessHART® protocol, PROFIBUS® protocol, etc.). As shown, the controller 110, field devices 125-132, and I / O devices 112, 115 are wired devices, and field devices 140-146 are wireless field devices. Of course, the wired field devices 125-132 and wireless field devices 140-146 can conform to any other desired standard or protocol, such as any wired or wireless protocol, including any standards developed in the future.

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

[0034] The controller 110 implements control strategies using what are commonly referred to as function blocks, where each function block is an object or other portion of an overall control routine (e.g., a sub-routine) that operates in conjunction with other function blocks (via communications called links) to implement process control loops within the process control system. Control-based function blocks typically perform one of the following: (i) an input function, such as that associated with a transmitter, a sensor, or other process parameter measurement device (sometimes referred to as an "input block"); (ii) a control function, such as that associated with a control program that performs PID, fuzzy logic, etc. (sometimes referred to as a "control block"); or (iii) an output function that controls the operation of some device, such as a valve, to perform some physical function within the physical process plant 100 (sometimes referred to as an "output block"). Of course, there are hybrid and other types of function blocks.

[0035] The function blocks can be stored in and executed by the controller 110, as is typically the case with standard 4-20 mA devices or some types of smart field devices (e.g., HART® devices) or associated therewith, or the function blocks can be stored in and implemented by the field devices themselves, as can be the case with, for example, Fieldbus devices. The one or more control routines 118 can implement one or more control loops by executing one or more function blocks. In a sense, the control routines 118 can be viewed as component behavior modules of the controller 110.

[0036] The wired field devices 125-132 can be any type of device, such as sensors, valves, transmitters, positioners, etc., while the I / O devices 112 and 115 can be any type of process control I / O devices 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 devices that communicate with the I / O devices 112 over analog lines or combined analog and digital lines, while the field devices 129-132 can be smart devices, such as Fieldbus devices, that use The Fieldbus communication protocol is used to communicate with the I / O devices 115 over the digital bus. However, in some embodiments, at least some of the wired field devices 125, 126, and 128-131 and / or at least some of the I / O devices 112, 115 additionally or alternatively communicate with the controller 110 using the process control data highway 108 and / or by using other suitable industrial process control communication protocols (e.g., Profibus, DeviceNet, Foundation Fieldbus, ControlNet, Modbus, HART, etc.). In some arrangements (not shown in FIG. 1), at least some of the field devices 125-132 can communicate with the controller 110 via an electronic I / O marshalling system rather than via individual I / O devices 112, 115. Figure 3

[0037] The wireless field devices 140-146 communicate via the wireless process control communication network 165 using a wireless protocol such as HART® protocol. Such wireless field devices 140-146 can 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 can utilize a wireless gateway 168 that is connected to the process control data highway 108 or another process control communication network. The wireless gateway 168 provides access to the various wireless devices 140-158 of the wireless communication network 165. In particular, the wireless gateway 168 provides a 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 can provide the communicative coupling by using the process control data highway 108 and / or by using one or more other communication networks of the physical process plant 100.

[0038] 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 a measurement of a process parameter. However, the wireless field devices 140-146 are configured to communicate using the wireless protocol of the network 165. As such, 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.

[0039] In some configurations of the physical process plant 100, the wireless network 165 includes non-wireless devices. For example, in Figure 1 ​In the diagram, field device 148 is a traditional 4-20mA device, while field device 150 is a wired device. Devices. To communicate within network 165, field devices 148 and 150 are connected to the wireless communication network 165 via wireless adapters 152a and 152b. Wireless adapters 152a and 152b support wireless protocols (such as WirelessHART) and may also support one or more other communication protocols, such as... Fieldbus, PROFIBUS, DeviceNet, etc. Additionally, in some configurations, the wireless network 165 includes one or more network access points 155a, 155b, which can be separate physical devices communicating with the wireless gateway 168 via wired connections, or can be provided as a single integrated device with the wireless gateway 168. The wireless network 165 may also include one or more routers 58 to forward packets from one wireless device to another within the wireless communication network 165. Therefore, wireless devices 140-146 and 152-158 communicate with each other and with the wireless gateway 168 via the wireless link 160 of the wireless communication network 165 and / or via the process control data high-speed channel 108.

[0040] Note that, although Figure 1 Only a single controller 110 is illustrated, along with a limited number of field devices 125-132 and 140-146, a wireless gateway 168, a wireless adapter 152, an access point 155, a router 158, and a wireless process control communication network 165 included in the exemplary physical process plant 100. This is merely an illustrative and non-limiting embodiment. The physical process plant 100 may include any number of controllers 110, and any controller 110 may communicate with any number of wired or wireless devices and networks 125-132, 140-146, 168, 152, 155, 158, and 165 to control processes within the physical process plant 100.

[0041] Backend environment 105 of physical process plant 100

[0042] As noted above, the back-end environment 105 can include various components (such as computing devices, operator workstations, databases or repositories, etc.) 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 can include any one or more of the following, each of which can be communicatively connected to the data highway 108: (i) one or more operator workstations 170a and / 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 can include, for example, tools, diagnostics, asset management systems, simulators, and / or other types of applications; (iv) one or more other wireless access points 178 that communicate with other devices associated with the plant 100 (e.g., 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., an enterprise’s IT network / systems and / or external data networks / systems, which can be implemented on cloud computing and / or other suitable platforms); and / or (vii) other physical components that are specifically configured by hardware and software to support the process plant 100.

[0043] Operators can use the operator workstations 170a and other user interface devices 170b to view and monitor the runtime operation of the physical process plant 100, as well as to take any diagnostics, corrections, maintenance, and / or other actions that can be needed. At least some of the operator workstations 170a can be located in various protected areas within or near the plant 100, and in some cases, at least some of the user interface devices 170b can be located remotely but still communicatively connected with the plant 100. The operator workstations 170a and user interface devices 170b can be wired or wireless computing devices configured to implement operator interface programs or applications to enable operators to monitor and control the operation of the physical process plant 100.

[0044] Configuration application 172a and configuration database 172b can be used to configure certain aspects of control and / or communication of the physical process plant 100, such as initial configuration and reconfiguration via control modules / routines, user interfaces, and data monitoring / analysis. For example, instances of configuration application 172a can be executed on one or more computing devices (not shown) to enable users to create or modify process control modules and download these modules to controller 110 via high-speed data channel 108 to create or modify operator interfaces through which operators can view data in process control routines and modify data settings to create or modify data monitoring / analysis routines and functions that can be downloaded to various physical components in the field environment 102, etc. 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 configured for the DCS environment of physical process plant 100 (e.g., DeltaV sold by Emerson Process Management). TM The control system has a unified logical appearance, although multiple instances of configuration application 172a can be executed simultaneously in the DCS environment, and configuration database 172b can be implemented across multiple physical data storage devices. Therefore, configuration application 172a and configuration database 172b (including their user interfaces) comprise a configuration or development system 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 of configuration system 172 differs from that of operator workstation / user interface device 170, because configuration and development engineers use the user interface of configuration system 172 regardless of whether the physical process plant 100 is operating in production mode, while the operator workstation / user interface device 170 is used by operators during the runtime operation of the physical process plant 100.

[0045] With respect to commissioning of the physical components of the field environment 102, the configuration database 172b can store data and other information that specifically identifies and / or addresses the various physical devices or components and their interconnections that are planned or intended to be implemented on the process plant floor or field environment 102. Some of this commissioning data can be provided to the components in the field environment 102 for commissioning of the devices and loops therein, and certain of this data can be used in the back-end environment 105, e.g., for designing, developing, and preparing control modules, operator interface modules, and / or data analysis modules that are to be operated in conjunction with the field environment 102 during real-time operation of the physical process plant 100. In an example, an approved control module is downloaded from the configuration database 172b to the process controller 110 so that, when executed during real-time operation, the process controller 110 operates in accordance with its resident control module to send and receive various signals to / from other components in its loops (and, in some cases, to / from other process controllers) to thereby control at least a portion of the process in the physical process plant 100.

[0046] The configuration database 172b can store a plurality of logical identifiers for components in the field environment 102, thereby enabling the controllers 110 and other devices to reference components and signals associated with the components by logical identifiers. For example, for a given field device, the configuration database 172b can store information that maps or binds a logical identifier to a particular hardware address or I / O channel. The hardware address can identify a particular controller, a particular I / O device connected to a particular controller, and / or a particular address for an I / O channel used to connect a particular I / O device to a field device. In some cases, this mapping or binding can be stored at the controller 110, the user interface device 170b, the operator workstations 170a, or any other desired device (e.g., any device that needs to resolve logical identifiers). After a logical identifier has been bound to a hardware address or I / O channel, the identifier is considered to be "allocated." In some cases, the physical process plant 100 includes "unallocated" logical identifiers, which are identifiers that are referenced by software elements (e.g., control routines and / or function blocks) but have not been bound. That is, a logical identifier is considered to be "unallocated" when the plant 100 and the configuration database 172b do not have a hardware address or I / O channel that has been bound to the tag. Thus, when a control routine references an unallocated logical identifier, the value carried by the signal in the physical process plant 100 will not be read, and a command will not be sent to a field device in the physical process plant 100 through the signal.

[0047] Examples of such logical identifiers include device tags (DTs) and device signal tags (DSTs), each device tag representing a particular instrument, controller, valve, or other physical field device, and each device signal tag representing a particular signal received or generated by a particular device, and typically corresponding to a particular parameter used by the field device. For certain devices, the DST contains a combination of the DT of the device and an identifier of a particular signal received or generated by the device (e.g., an identifier of a particular parameter referenced by the control module). For certain devices (e.g., legacy or dumb devices), the DT represents both the physical device and the signal generated by the device. In general, the physical process plant 100 uses the logical identifier of a device to uniquely identify that device in both the field environment 102 and the back-end environment 105. DTs and DSTs can be referred to as "tags," "system tags," or "system identifiers."

[0048] In certain cases, the smart field devices 129-132 can also store logical identifiers that are unique to the smart field devices 129-132. These logical identifiers can be different from the system tags used by the plant 100 to identify the field devices 129-132, and can be referred to as "source identifiers" or "source tags." The source tags can or can not be stored in the configuration database 172b, depending on the implementation. The configuration database 172b can 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 intended to be implemented in the virtual DCS environment, as described below. Similar to physical devices and components, the configuration database 172b can store respective logical identifiers of the components of the virtual DCS environment, thereby enabling other devices and / or components (whether physical or virtual) to reference the virtual components. For example, similar to the physical nodes within the field environment 102, the various virtual nodes operating within the DCS environment in the back-end environment 105 can be uniquely identified by their respective device tags (DTs), device signal tags (DSTs), source tags, and / or other types of unique identifiers. Other portions of this disclosure discuss the configuration and identification of virtual devices and components in greater detail.

[0049] Other applications 175a and databases 175b can include instances of applications for monitoring or analyzing aspects of the operation of the 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, the other applications 175a and databases 175b can include one or more applications and their associated databases that are executed at the operations technology layer of the physical process plant 100. Additionally or alternatively, the other applications 175a and databases 175b can include one or more applications and their associated databases that are executed at the IT layer associated with the process plant 100, such as inventory management applications, personnel management applications, supply chain management applications, other types of enterprise-related applications, weather / environmental applications, etc. For example, the other applications 175a and databases 175b can include Internet of Things (IoT) and / or Industrial Internet of Things (IIoT) applications and their associated databases. Still additionally or alternatively, the other applications 175a and databases 175b can include one or more applications and their associated databases that are executed outside of and / or remotely from the physical process plant 100 and / or its enterprise, such as simulation applications, analysis applications, etc. The other applications 175a and databases 175b can include third-party applications and / or can include applications provided by the enterprise associated with the physical process plant 100. At least some of the other applications 175a and databases 175b can be accessible through the edge gateway system 182 and / or some other type of security and / or firewall system.

[0050] One or more access points 178 enable devices in the back-end environment 105 (sometimes in 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 (e.g., WiMAX (Worldwide Interoperability for Microwave Access), LTE (Long-Term Evolution), or other ITU-R (International Telecommunications Union - Radio) compliant protocols), short wave radio communication (e.g., near field communication (NFC) and Bluetooth), or other wireless communication protocols. Typically, such access points 178 allow handheld or other portable computing devices (e.g., user interface devices 170b) to communicate over a respective wireless process control communication network that is different from and supports a different wireless protocol than the wireless network 165. For example, a wireless or portable user interface device 170b can be a mobile workstation or diagnostic test equipment used by an operator in the physical process plant 100 (e.g., an instance of one of the operator workstations 170a). In certain scenarios, in addition to portable computing devices, one or more process control devices (e.g., controllers 110, field devices 125-132, or wireless devices 168, 140-158) also communicate using the wireless protocol supported by the access points 174.

[0051] Gateway nodes or systems 180 and 182 can interface with systems that are external to the immediate physical process plant 100. Typically, such systems are customers or suppliers of information generated by or operated by the physical process plant 100. For example, the physical process plant 100 can include a plant gateway node 180 to communicatively connect the immediate physical process plant 100 with another process plant. Additionally or alternatively, the physical process plant 100 can include an edge gateway node or system 182 to communicatively connect the physical process plant 100 with an external public or private system, such as a laboratory system (e.g., a laboratory information management system or LIMS), an operator rounds 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 control system, a production scheduling system, a weather data system, a transportation handling system, a packaging system, the Internet, an IOT application, an IIOT application, or other external system.

[0052] Generally, the edge gateway system 182 allows for secure communication transfer between the physical process plant 100 and other networks 185. In the example architecture, the edge gateway system 182 includes an internal- or plant-facing engine (which can be referred to as a “field gateway”) and an external- or outward-facing engine (which can be referred to as an “edge gateway”), where the plant-facing engine and the external-facing engine cooperate to securely transfer process plant data (e.g., data generated by the operational 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 external-facing engine across one or more secure communication links, e.g., via a first set of publications. The external-facing engine has subscribed to various publications generated by the plant-facing engine and obtains the collected plant data therefrom. In turn, the external-facing engine securely transmits the obtained plant data to one or more external client applications within the network 185, e.g., via a second set of publications. The publications and subscriptions at the plant-facing engine and / or the external-facing engine can be configured as desired. However, generally, the publication / subscription, encryption, and / or other secure data transfer mechanisms used between the plant-facing engine and the external-facing engine are different than the publication / subscription, encryption, and / or other secure data transfer mechanisms used between the external-facing engine and the external applications. In some embodiments, for additional security, the edge gateway system 182 includes a one-way data diode disposed between the plant-facing engine and the external-facing engine to prevent data from flowing from the external network 185 into the process plant 100. Examples of edge gateway systems can be found in U.S. Patent Publication Nos. 2018 / 0115516, 2018 / 0115528, 2018 / 0115517, and 2018 / 0113442, the entire disclosures of which are hereby incorporated by reference. Of course, the physical process plant 100 can additionally or alternatively utilize other edge gateway systems.

[0053] Software-defined DCS environment for a physical process plant

[0054] Figure 2A and Figure 2B is illustrated Figure 1a block diagram of an exemplary physical process plant 100 in which a software-defined DCS environment 200 running on a server farm 210 controls at least a portion of the process plant. In both of the illustrated embodiments of the software-defined DCS environment 200, the controllers 110 of the physical process plant 100 are implemented as software-defined process controllers (virtual DCS controllers 212) in the server farm 210 in the back-end environment 105. In addition to the virtual DCS controllers 212, the server farm 210 also implements various DCS applications 221-225 and 229 to provide higher-level functionality, configuration, monitoring, and analysis of the processes and the virtual DCS controllers 212. The server farm 210 also includes one or more databases or data stores for process data related to the virtual DCS controllers 212 and the DCS applications 221-225 and 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 an implementation of software-defined infrastructure in which hardware and software resources are pooled within a software-defined environment to facilitate policy-based infrastructure provisioning.

[0055] Software-defined DCS control of the processes in the server farm 210 provides a number of advantages, including improved robustness of the system by implementing load balancing and preventing component failure, reduced equipment requirements by combining controllers with the same hardware, and reduced configuration effort by reducing network complexity. Figure 2A Embodiments of the software-defined DCS environment 200 are illustrated in which the I / O connections 240 are handled by components in the field environment 102, while Figure 2B Embodiments of the software-defined DCS environment 200 are illustrated in which the I / O connections 240 are handled by the server farm 210 in the back-end environment 105. Other embodiments can include a combination of I / O connections 240 in the field environment 102 and the back-end environment 105 (e.g., smart field devices are able to communicate directly with the server farm 210 over a data communications network, while legacy field devices can require I / O devices to translate between the industrial process control communication protocols used by the field devices and the general IT communication protocols used by the servers.

[0056] As described above with reference to FIG. 1, the software-defined DCS environment 200 can be implemented in a number of different ways. For example, the virtual DCS controllers 212 can be implemented as virtual machines running on the server farm 210, or as containers running on the server farm 210. In some embodiments, the virtual DCS controllers 212 are implemented as virtual machines running on the server farm 210, while the DCS applications 221-225 and 229 are implemented as containers running on the server farm 210. In other embodiments, the virtual DCS controllers 212 and the DCS applications 221-225 and 229 are implemented as virtual machines running on the server farm 210. Figure 1As described, the plurality of field devices 125-132, 140-150 in the field environment 102 control at least a portion of the industrial process based on control signals from the DCS controller. In the software-defined DCS environment 200, such control signals are generated by virtual DCS controllers 212 implemented by one or more servers within the server group 210. The virtual DCS controllers 212 operate in substantially the same manner as the (physical) controllers 110 to implement process control logic configured to monitor and control the process in real-time. However, the virtual DCS controllers 212 are implemented as computer-executable instructions in the server group 210 rather than in the dedicated hardware controllers 110 in the field environment 102. For example, the virtual DCS controllers 212 can be virtual instances of control programs operating in a real-time operating environment implemented by one or more hypervisors running on the server group 210 to emulate the local operating environment of each virtual DCS controller 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 the process via the field devices 125-132, 140-150. Thus, the virtual DCS controllers 212 are integrated within the server group 210 to control the process (or portions thereof) from one location, enhancing communication between control modules. In some embodiments, similar to using multiple physical controllers in a physical DCS network, multiple virtual DCS controllers 212 can be implemented to control different portions of the process. As discussed further below, load balancing and redundancy can be achieved by implementing multiple instances of each virtual DCS controller 212 in different servers of the server group 210.

[0057] In addition to the virtual DCS controller 212, in some embodiments, other network components can be virtualized in the software-defined DCS environment 200 to produce a software-defined virtual network running on the server group 210. Such a virtual network includes a plurality of virtual nodes associated with the physical nodes in the process plant 100. Such virtual nodes can include virtual components representing various hardware components present in the communication network of the field environment 102, such as networking switches, routers, firewalls, and other network equipment. As noted above, these virtual nodes can include networking components such as the wireless gateway 168, wireless adapter 152, access point 155, or router 158. In further embodiments, the virtual network can include virtual representations of field devices used to control and communicate with the field devices 125-132, 140-150. The virtual representations of the field devices can be implemented in the virtual DCS controller 212 using device function blocks, shadow function blocks, or other such techniques used in DCS environments. Thus, in such embodiments, the software-defined DCS environment 200 includes virtual representations of the physical components of the process control system in the field environment (e.g., the field devices and necessary networking components) as well as the virtual DCS controller 212 in place of the physical controller.

[0058] To maintain a communication connection with the field devices 125-132, 140-150, the software-defined DCS environment 200 can include or be connected to an I / O connection 240 configured to provide a communication link between the server group 210 and the physical components of the communication network of the field environment 102. The I / O connection 240 includes physical networking components that directly or indirectly connect the server group 210 to the field devices 125-132, 140-150. Such components can include ports, switches, or routers. The I / O connection 240 communicates process data between the virtual DCS controller 212 and the field devices 125-132, 140-150. Thus, the I / O connection 240 receives process data from the field devices 125-132, 140-150 and sends such process data to the virtual DCS controller 212, and the I / O connection 240 also receives process control signals from the virtual DCS controller 212 and sends such process control signals to the field devices 125-132, 140-150.

[0059] In some embodiments, the I / O connection 240 can include an I / O server configured to map physical nodes within the field environment 102 to virtual nodes within the software-defined DCS environment 200, thereby enabling the virtual DCS controllers 212 to communicate with the virtual nodes maintained by the I / O server without requiring detailed knowledge of the physical network in the field environment 102. For example, the I / O server can map physical nodes associated with the field devices 125-132, 140-150 and virtual nodes associated with corresponding virtual field devices through publish / subscribe mapping to provide real-time data communication between the server group 210 and components of the field environment 102 (e.g., the field devices 125-132, 140-150). By routing all communication to the server group 210, the I / O connection 240 decouples hardware and software communication configurations, thereby enabling all virtual DCS controllers 212 in the server group 210 to access any process data without requiring a separate hardware connection configured for each controller to each data source.

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

[0061] Although illustrated in Figure 2A as separate from the server group 210, the I / O connection 240 can instead be incorporated into the server group 210 as shown in Figure 2B Likewise, the I / O connection 240 can connect only the server group 210 with a subset of the field devices (e.g., the field devices 125-132 as shown in Figure 2A , or can connect the server group 210 with all of the field devices in the field environment 102 (e.g., the field devices 125-132 and 140-150 as shown in Figure 2B . As Figure 2AAs shown, other networking components (e.g., wireless gateway 168) can connect some field devices (e.g., field devices 140-150) directly to server group 210, such as through a direct physical connection or through a local area network (not shown) in backend environment 105. For example, within a server room in backend environment 105, wireless gateway 168 can be physically connected to one or more server racks including server group 210 through wired communication cables.

[0062] In addition to virtual DCS controller 212, software-defined DCS environment 200 includes one or more DCS applications 221-225, 229 running on servers of server group 210. These DCS applications 221-225, 229 are configured to interact with virtual DCS controller 212 to configure, monitor, control, and / or analyze the operation of processes within physical process plant 100. The DCS applications operate in a manner similar to the various applications and gateways of backend environment 105 in a traditional DCS configuration (e.g., as shown in Figure 1 However, implementing DCS applications 221-225, 229 within server group 210 along with virtual DCS controller 212 simplifies configuration and communication. In some embodiments, in addition to a real-time environment in which virtual DCS controller 212 operates, software-defined DCS environment 200 can implement one or more operating systems in which one or more of DCS applications 221-225, 229 locally operate.

[0063] DCS applications 221-225, 229 can include a plurality of applications for implementing control, configuration, communication, or analysis functions. One or more user interface devices 170b (e.g., workstations, desktop computers, or mobile computing devices) can be used by one or more operators to interact with DCS applications 221-225, 229 of software-defined DCS environment 200. For example, an operator can use a desktop computer or a smartphone to interact with DCS applications 221-225, 229 to obtain information about a process, adjust the operation of virtual DCS controller 212, or analyze a process or condition of physical process plant 100.

[0064] Edge gateway application 221 can be configured to provide communication with other networks 185, similar to Figure 1The other networks can include external networks that are remote from the process plant. Similar to operator workstations 170a, operator interface application 222 can be configured to provide an operator interface or workstation interface to an operator to enable the operator to monitor and control runtime operation of the process. For example, an operator can use user interface devices 170b to access operator interface application 222 running on server group 210 to take any diagnostic, corrective, maintenance, and / or other actions that can be needed to operate physical process plant 100. Such actions can include setting or adjusting operating parameters, control setpoints, or control schemes used by virtual DCS controllers 212. Because virtual DCS controllers 212 all operate within software-defined DCS environment 200 and server group 210, operator interface application 222 can 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 can be configured to apply system-wide locks to prevent control modules from being downloaded to virtual DCS controllers 212 (e.g., to prevent accidental or unauthorized changes during process runtime). Asset management application 223 can be configured to provide information about assets within physical process plant 100 and information about utilization of the assets.

[0065] Data historian application 224 can be configured to store process data within software-defined DCS environment 200 during operation of the process for subsequent use in process analysis or control. By implementing data historian application 224 in server group 210 along with virtual DCS controllers 212, more detailed process data can be stored than might otherwise be possible. Because all process data used by and generated by virtual DCS controllers 212 is available at server group 210, no additional communication outside of server group 210 is needed to historize the data. Thus, data historian application 224 can be configured to automatically store high-fidelity data during process operation. Such process data can be stored in a database or datastore 230 of server group 210, which can also store configuration or other data used by virtual DCS controllers 212 or DCS applications 221-225, 229.

[0066] The virtual architecture configuration application 225 can 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 within the software-defined DCS network architecture and connections between the nodes, 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 can be used to represent the physical network architecture of the components of the field environment 102 in order to enable the virtual DCS controller 212 to control the process. Thus, the virtual nodes can include virtual representations of a plurality of field devices. To define the software-defined DCS network architecture, the virtual architecture configuration application 225 can provide a user interface configured to enable an operator to define the virtual nodes. In some embodiments, the virtual architecture configuration application 225 can configure the I / O connections 240 to facilitate communication between the server group 210 and the field devices 125-132, 140-150. In further embodiments, information about the types of process data received from the components of the field environment 102 through the I / O connections 240 can be provided to the virtual architecture configuration application 225 in order to automatically determine portions or all of the software-defined DCS network architecture based on the types of process data received. Whether defined or determined, the software-defined DCS network architecture can be stored as configuration data in one or more databases or data stores 230, similar to the configuration database 172b.

[0067] In some embodiments, other DCS applications 229 can be implemented within the software-defined DCS environment 200 on the server group 210 to provide additional or alternative functionality. Such other DCS applications 229 can 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 the processes of the physical process plant 100. As an example, the other DCS applications 229 can include a simulator application configured to run third-party software applications in the server group 210 by simulating a local operating environment of such third-party software applications within the software-defined DCS environment 200. Thus, legacy or other software applications can be integrated into the software-defined DCS environment as if they were running in separate computing devices in the physical process plant 100. As another example, the other DCS applications 229 can include a real-time process model application configured to optimize, tune, or otherwise adjust process control loops of the virtual controllers 212 during process operation (e.g., by performing adaptive process control to select or adjust process models based on variable plant parameters). As an additional example, the other DCS applications 229 can include a security policy manager application configured to set software-defined security permissions or policies for various components of the software-defined DCS environment 200 (e.g., 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 controllers 212, control modules, function blocks), or other DCS applications). As yet another example, the other DCS applications 229 can include a network architecture configuration application configured to automatically detect physical networking components (e.g., switches or routers) within the field environment 102 and configure such physical networking components for communication within a communication network in the field environment 102. In some such embodiments, the network architecture configuration application can also configure the I / O connections 240 for communication between the field environment 102 and the server group 210.

[0068] In some embodiments, server group 210 may be communicatively coupled to one or more additional server groups 210 associated with physical process plant 100 or with other process plants or other systems. In some such embodiments, other server groups 210 may be configured to operate portions of physical process plant 100. Similarly, in other embodiments, the virtual DCS controller 212 of server group 210 may control only a portion of physical process plant 100, wherein one or more physical controllers 110 are communicatively connected 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 still be represented as nodes within software-defined DCS environment 200 to enable hardware-independent interaction between such controllers 110 and other components in the software-defined DCS architecture.

[0069] Server group for a software-defined DCS environment

[0070] Figure 3 An exemplary redundant server group 300 (e.g., implementing a software-defined DCS environment 200) is illustrated. Figure 2A and Figure 2B The diagram shows a block diagram of server group 210. As described above, the software-defined DCS environment 200 implemented by 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, server group 210 may include multiple servers 350a-n controlled by control manager 352, such as... Figure 3 The redundant server group 300 is shown in the diagram. By implementing virtual DCS controllers 212 and DCS applications 221-225, 229 across multiple servers 350a-n, the redundant server group 300 facilitates efficient load balancing and robust failover capabilities among the servers 350a-n should any one of them fail. Therefore, multiple instances of each virtual DCS controller 212 can run simultaneously on different servers 350a-n, and each instance of the virtual DCS controller 212 may include control modules 314a-n and redundant modules 318a-n coordinated by a control manager 352. Based on the status (e.g., availability) of the servers 350a-n, the control manager 352 can perform automatic load balancing among the servers 350a-n by distributing modules among them.

[0071] In some embodiments, the servers 350a-n and the control manager 352 can each include one or more blades connected in one or more server racks to form the redundant server group 300. Each blade 350a-n, 352 can be a thin electronic circuit board having one or more processors and memory. The processors within each blade 350a-n, 352 can include multi-core hardware, such as a multi-core processor or another type of parallel processor. Additionally, the memory within each blade 350a-n, 352 can include high-density memory storage technology, for example, 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 can also include flash memory. The memory storage (and in some cases, the flash memory) can be configured to temporarily store or cache data generated by, received at, or observed by the respective blade 350a-n, 352.

[0072] In any case, 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 can provide control signals to the same subset of field devices 125-132, 140-150, the multiple servers 350a-n can not provide control signals to the same field devices and / or for the same parameters in the same time interval. For example, a first server 350a and a second server 350b can not provide control signals to the same valve in the same time interval instructing the valve to open or close. In some embodiments, the control manager 352 assigns control modules to the servers 350a-n such that the multiple servers 350a-n cannot provide control signals to the same field devices and / or for the same parameters in the same time interval. Additionally or alternatively, a control monitoring module in the redundant server group 300 can monitor control outputs from the servers 350a-n to determine whether any two control outputs go to the same field device and / or for the same parameter in the same time interval. When this occurs, the control monitoring module can override the control signals to ensure that only one of the control signals is provided to the field device. The control monitoring module can also provide a request to one of the servers 350a-n or to the control manager 352 to stop providing control signals to the field device during that time interval. However, the multiple servers 350a-n can receive outputs from the same field device in the same time interval, for example, a valve percentage open from the same valve.

[0073] In some embodiments, for each control routine or module executed by the servers 350a-n, one of the servers 350a-n can include a redundant module. The redundant module can keep the server 350b executing the redundant module 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 be used to take over and execute the control module. To keep synchronized with the server 350a executing the control module, the redundant module can cause the server 350b executing the redundant module to receive the same inputs, outputs, set points, etc. that are received and provided by the server 350a executing the control module. The server 350a executing the control module can be a different server or blade than the server 350b executing the redundant module. Similar to the control module, the redundant module can be software, firmware, hardware, etc. The redundant module can be implemented in any desired software format, such as using object oriented programming, ladder logic, sequential function charts, function block diagrams, or using any other software programming language or design paradigm.

[0074] Further in some embodiments, each server 350a-n includes a DCS application module 316a-n to implement the DCS applications 221-225, 229 described above. Similar to the control modules 314a-n, the DCS application modules 316a-n can be software, firmware, hardware, etc. The DCS application modules 316a-n can be implemented in any desired software format, such as using object oriented programming, ladder logic, sequential function charts, function block diagrams, or using any other software programming language or design paradigm.

[0075] In addition to the servers 350a-n, the redundant server group 300 includes a control manager 352 that allocates 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 within the blade server. In other embodiments, the control manager 352 is a software application that can be implemented in any of the blades 350a-n, 352 in the redundant server group 300. The redundant server group 300 can include a single control manager 352 implemented on a single blade that manages control to each of the controllers within the multiple blade servers. In other embodiments, the control manager 352 can be implemented across multiple blades. In other embodiments, the redundant server group 300 can include one or more rack servers each having a plurality of mounting slots such that the blades 350a-n, 352 correspond to bays 350a-n, 352 in the rack servers.

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

[0077] The control manager 352 is in communication with a plurality of servers 350a-n in the redundant server group 300. Each of the servers 350a-n and the control manager 352 can be a physical machine (e.g., hardware) or a virtual machine (e.g., software). In this way, a single blade can host multiple guest virtual machines or servers. In any case, the control manager 352 includes a control enforcer 354, a load balancer 302, a shadow database 304, a redundancy manager 306, and a control module 308. Each server 1-N (reference numerals 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 can be a high-density memory. Each of the memories 312a-n can store individual routines assigned to the respective server 350a-n, including a control module 314a-n, a DCS application module 316a-n, and a redundancy module 318a-n.

[0078] In addition to storing and executing routines to control and monitor operations within the physical process plant 100, the servers 350a-n can provide an indication of availability or status to the control manager 352. In some embodiments, each of the servers 350a-350n provides an availability metric for a particular time interval to the control manager 352 based on a load at the server 350a-n, an amount of available storage at the server 350a-n, and a 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 indication of a load at the server 350a-n, an amount of available storage at the server 350a-n, and a 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 at the server 350a-n can indicate an amount of processing performed by the server 350a-n and a processing capacity of the server 350a-n (e.g., single core, dual core, quad core, etc.). The availability metric can also be based on a server failing to provide an indication or respond to the control manager 352 to account for a server that is malfunctioning or otherwise unavailable.

[0079] The control executor 354 at the control manager 352 can receive operations to be performed by the servers 350a-n in the redundant server group 300. In some embodiments, the redundancy manager 306 generates a redundancy module for each control module 308 obtained by the control manager 352. The redundancy module can cause the server 350a-n executing the redundancy module to receive the same inputs, outputs, set points, etc. that are received and provided by the server 350a-n executing the control module without executing the control loop or function included in the control module. In some embodiments, the control executor 354 provides each of the obtained control modules 308 to the redundancy manager 306 to cause the redundancy manager to generate a corresponding redundancy module.

[0080] Additionally in some embodiments, the control executor 354 assigns a priority level to each of the control modules, redundancy modules, and DCS application modules and ranks the modules in order of priority. The priority level can be assigned automatically based on a predetermined set of priority rules (e.g., redundancy modules have the same priority level as the corresponding control module, control modules have a higher priority level than DCS application modules, etc.). Additionally or alternatively, a user can assign a priority level to each module. For example, when a configuration engineer generates a control module through a configuration application, the configuration engineer can also assign a priority level to the control module.

[0081] The control executor 354 can communicate with the load balancer 302 to determine which server 350a-n should execute which control module 308, redundancy module, and DCS application module during a particular time interval. In some embodiments, the load balancer 302 receives an availability metric for each server 350a-n as well as a list of control modules, redundancy modules, and DCS application modules to be executed during a particular time interval, which can include a priority level for each of these modules. The load balancer 302 then assigns the servers 350a-n in the redundant server group 300 to execute each of these modules. In some scenarios, depending on the parallel processing capabilities and memory density of the servers 350a-n, a single server 350a-n can execute multiple modules during the same time interval. In another example scenario, the load balancer 302 identifies two different servers 350a-n to execute a control module and a redundancy module, such that the server 350a-n executing the redundancy module can take over for the server 350a-n executing the control module in the event of a failure at the controller.

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

[0083] For example, the load balancer 302 can rank each server 350a-n according to its respective availability metric, where the server 350a-n with the highest availability metric has the greatest amount of availability and is ranked the highest. The load balancer 302 can also rank each module based on a combination of the priority level and the characteristic of each module. In some embodiments, periodic modules are ranked above event-driven modules, then each periodic module is sorted based on the priority level, and each event-driven module is sorted based on the priority level. Each periodic module in the high priority category can be ranked above each periodic module in the medium priority category, and so on. Periodic or event-driven modules in the same priority category can be further ranked based on execution time. More specifically, when there are three priority categories (high, medium, and low) and periodic modules and event-driven modules, high priority periodic modules can be ranked first, where each module in the category is further ranked in order of execution time, followed by medium priority periodic modules, followed by low priority periodic modules, followed by high priority event-driven modules, and so on.

[0084] Accordingly, the load balancer 302 can rank the servers 350a-n and can rank the modules. Although the servers 350a-n are ranked in order of availability metrics and the modules are ranked in order of priority levels and module characteristics in the above example, the servers 350a-n and the modules can be ranked in any suitable manner.

[0085] The load balancer 302 can then use a reversing 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 can be assigned to the second highest ranked server 350a-n, and the algorithm can continue in this manner until the lowest ranked server 350a-n is assigned a module. If there are more modules to assign, the load balancer 302 continues to assign modules in the reverse order. For example, the load balancer 302 also assigns the next module to the lowest ranked server 350a-n, then assigns modules ranked below the next module to the second lowest ranked server 350a-n, and continues in ascending order until the highest ranked server 350a-n is assigned two modules. The load balancer 302 then again reverses the order to assign modules in descending order and continues in the reverse round-robin manner until each module is assigned to a server 350a-n.

[0086] While the load balancer 302 can rank the servers 350a-n and the modules and assign the modules to the servers 350a-n using a reverse round-robin mechanism, the load balancer 302 can 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 can all be distributed equally or at least similarly among the servers 350a-n regardless of priority level or characteristics. In other embodiments, the load balancer 302 assigns modules to the same server 350a until processing at the server 350a reaches capacity. The load balancer 302 then assigns modules to another server 350b until processing at the other server 350b reaches capacity, and the load balancer 302 can continue assigning modules in this manner.

[0087] In any case, the control executor 354 then 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 executor 354 analyzes the assignments and can adjust some of the assignments to ensure that multiple servers 350a-n are not providing control signals to the same field device and / or for the same parameter at the same time interval.

[0088] In an example scenario, during a first time interval, a first set of modules can be assigned to server 350a. Control enforcer 354 can 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, a second set of modules different from the first set of modules can be assigned to server 350a. Control enforcer 354 can download new control module 314a, DCS application module 316a, and redundancy module 318a to server 350a during the second time interval.

[0089] In another example scenario, during a particular time interval, control manager 352 assigns a first control module to first server 350a, where the first control module corresponds to a first subset of field devices 125-132, 140-150. Control manager 352 assigns a second control module to second server 350b, where the second control module corresponds to a second subset of field devices 125-132, 140-150. Then, during the same time interval, first server 350a executes the first control module, and second server 350b executes the second control module. During a later time interval, first server 350a is no longer assigned the first control module, and second server 350b is assigned both the first control module and the second control module. For example, during the later time interval, first server 350a can have failed or can not have processing resources to execute the first control module. Then, second server 350b executes the first control module and the second control module during the later time interval for the first subset and the second subset of field devices 125-132, 140-150, respectively.

[0090] In some embodiments, periodic modules remain assigned to the same server 350a-n for multiple time intervals, while event-driven modules can be reassigned to servers 350a-n for each time interval based on the availability metric of servers 350a-350b at the particular time interval. In other embodiments, each of the control modules, DCS application modules, and redundancy modules are downloaded to each server 350a-n prior to execution (e.g., when the modules are generated) and stored in their respective memories 212a-n. When control enforcer 354 selects a server 350a to execute a particular module, 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 312a and executes the particular module through processor 310a.

[0091] In some embodiments, the control manager 352 includes a shadow database 304 that stores input data for control modules, redundancy modules, and DCS application modules. For example, input data for a module can be obtained from the user interface device 170b when the module is configured or generated. Input data can also be obtained from the servers 350a-n when the servers 350a-n execute the control modules 314a-n and the DCS application modules 316a-n. Outputs from the control modules 314a-n and the DCS application modules 316a-n can be received from the servers 350a-n in the shadow database 304 and stored as input data for control modules, redundancy modules, and DCS application modules executed during subsequent times.

[0092] In some embodiments, the control manager 352 can further provide availability information regarding the status or availability of the servers 350a-n. Such information can include a total load or availability metric for the redundancy server group 300, an availability metric for individual servers 350a-n, an operational status for individual servers 350a-n (e.g., operable or inoperable), or other similar metrics. In some embodiments, the control manager 352 can further provide usage information regarding resource usage within the redundancy server group 300, such information indicating processing resources required or desired for execution of control modules, redundancy modules, and DCS application modules in the servers 350a-n. From the availability information and the usage information, the control manager 352 can further calculate or predict an optimal resource allocation for the redundancy server group 300, such as a number or type of servers 350a-n to be connected within the redundancy server group 300. Such calculations or predictions can be presented to an operator to enable adjustment of the hardware configuration of the redundancy server group 300 (e.g., addition or replacement of servers). In some embodiments, such calculations or predictions can be performed by a DCS application such as the asset management application 223 or other DCS application 229.

[0093] Configuration and operation of a software-defined DCS environment

[0094] Figure 4 A flowchart 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 a software-defined DCS environment 200 is illustrated. The virtual DCS configuration and control method 400 can be performed to set up, operate, monitor, and adjust a process control system to operate a process within a physical process plant 100 using a software-defined DCS environment 200 such as described above. In some embodiments, some aspects of the software-defined DCS configuration and control method 400 can be performed manually or can be automated. Alternative embodiments can include additional, fewer, or alternative aspects.

[0095] The software-defined DCS configuration and control method 400 begins by connecting at least some of the field devices 125-132, 140-150 to the server group 210 through the I / O connections 240 (block 402). This can include physically connecting the field devices 125-132, 140-150 during physical installation within a factory or when adding field devices to an existing process control network. In some embodiments, the field devices 125-132, 140-150 can be connected by establishing software-defined communication connections via the I / O connections 240 after installation within a factory, such as by establishing publish / subscribe connections in the I / O servers. In some embodiments, not all of the field devices 125-132, 140-150 can need to be connected to the server group 210 to control a process, and certain field devices 140-150 can instead be directly connected to the server group 210 through the wireless gateway 168 in some embodiments.

[0096] Once the relevant 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 within the software-defined DCS environment 200 (block 404). To configure the software-defined DCS network architecture, the virtual architecture configuration application 225 can generate and present a user interface to a user (e.g., an engineer configuring the process control system) that can include a plurality of options for configuring the components and connections within the software-defined DCS network. Accordingly, the user can be presented with options for adding, removing, editing, connecting, and specifying parameters of the software-defined components through the user interface. Upon receiving user input from the user, the virtual architecture configuration application 225 can define the software-defined DCS network architecture by specifying the nodes and connections within the software-defined DCS network based on the user input. Additionally or alternatively, the virtual architecture configuration application 225 can automatically determine portions or all of the software-defined DCS network architecture based on information received from the components (e.g., field devices 123-132, 140-150) of the field environment 102 regarding the type of process data. The information regarding the type of process data is determined based on data traffic from the field devices 123-132, 140-150 at the I / O connections 240. In some such embodiments, the information regarding the type of process data received from the components in the field environment 102 can be obtained by the virtual architecture configuration application 225 from the I / O connections 240 (e.g., from the I / O servers). In further such embodiments, the determined type of process data can be presented to an operator via the user interface of the virtual architecture configuration application 225 for confirmation or adjustment. The software-defined DCS network architecture is then stored in the 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 controllers 212 and the DCS applications 221-225, 229).

[0097] In some embodiments, the software-defined DCS network architecture provides a plurality of service classes for individual components using the software-defined DCS environment in order to ensure that resource demands are properly handled. For example, real-time processes (e.g., process control of control modules) are assigned a high priority class to ensure that time-sensitive process control routines are given priority over analysis processes of the DCS applications. In further embodiments, a plurality of classes of real-time processes can be used to give higher priority to critical or safety-essential processes. Similarly, classes can be based on or used to differentiate bandwidth requirements of processes within the software-defined DCS environment 200.

[0098] The server group 210 then prepares to execute process control. During operation of the physical process plant 100, the software-defined process controllers (e.g., the virtual DCS controllers 212) receive process data from the field devices 125-132, 140-150 (block 406) and implement process control logic to control the process in real-time (block 408). The process data can be generated by one or more of the field devices 125-132, 140-150 and received therefrom via the I / O connections 240. At least a portion of this process data is then used by the software-defined process controllers to generate process control signals to control the process in the physical process plant 100. These process control signals are then sent to one or more of the field devices 125-132, 140-150 to implement control actions to control the process (e.g., adjust a valve position or control a heating element). The process control signals can be sent to the relevant field devices 125-132, 140-150 via the I / O connections 240.

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

[0100] In some embodiments, as described above, the server group 210 can also perform load balancing between servers or other server devices in the server group 210 during operation of the process (block 412). To perform such load balancing, the server group 210 can implement multiple instances of each software-defined process controller (or control modules thereof) on different servers within the server group 210 concurrently. Upon detecting a change in status of one of the servers (e.g., a server failure, an addition of a server, a jump in load at a server, or a drop in load at a server), the server group 210 adjusts the distribution of load between the multiple servers in the server group 210 based on the detected change to maintain effective control of the process by the software-defined process controller. Such adjustment of the distribution of load can include, for example, transferring control of a portion of the process from an instance of the virtual DCS controller 212 operating on a first server to another instance of the virtual DCS controller 212 operating on a second server. In some such embodiments, a new instance of the virtual DCS controller 212 can also be launched on a third server of the server group 210 to maintain redundancy, thereby preventing a subsequent failure of the second server.

[0101] In further embodiments, the server group 210 can receive an indication of a modification to the network architecture of the field environment 102 (block 414) and modify the software-defined DCS network architecture to reflect such modification (block 416). Similar to the initial configuration of the software-defined DCS network architecture, the indication of the modification to the network architecture can be received from an operator via the virtual architecture configuration application 225 or can be automatically generated based on detecting a change in the type of process data received at the I / O connections 240 as data traffic. For example, a user can indicate through user input that one or more of the field devices 125-132, 140-150 is being replaced with a new field device, or such replacement can be detected based on a change in the data traffic received from the new field device. In response to such indication of a modification to 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 modified physical network architecture. Such adjustment can include adding, removing, or modifying nodes or connections within the software-defined DCS network architecture. This modification to the software-defined DCS network architecture is then stored in the 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 software-defined process controllers can also be determined based on the adjustment to the software-defined DCS network architecture. For example, control loops within a software-defined process controller can be adjusted based on the addition, replacement, or removal of a field device within the field environment 102 that changes the process data available for process control.

[0102] The software-defined DCS configuration and control method 400 can continue to perform process control as described above until it is determined that the controlled process within the physical process plant 100 is no longer in progress (block 418). When the process terminates, the software-defined DCS configuration and control method 400 can also end.

[0103] Other considerations

[0104] The following additional notes apply to the foregoing discussion. Throughout the specification, actions described as being performed by any device or routine are generally intended to refer to actions or processes of a processor manipulating or transforming data according to machine-readable instructions. The machine-readable instructions can be stored on and retrieved from a storage device communicatively coupled to the processor. That is, the methods described herein can be embodied by a set of machine-executable instructions stored on a computer-readable medium (i.e., a storage device). The instructions cause a processor to perform the method 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.). The words “stored” and “saved” are not inclusive of transitory signals in the context in which instructions, routines, modules, processes, services, programs, and / or applications are referred to as being stored or saved on a computer-readable memory or computer-readable medium.

[0105] Further, although the terms “operator,” “personnel,” “person,” “user,” “technician,” “engineer,” and other terms are used to describe a person who can use or interact with the systems, devices, and methods described herein in a process plant environment, these terms are not intended to be limiting. Where a particular term is used in the specification, the term is used in part due to the traditional activities engaged in by plant personnel, but is not intended to limit the personnel who can engage in that particular activity.

[0106] Additionally, throughout the specification, unless otherwise indicated by the context, multiple instances can implement a component, operation, or structure described as a single instance. Although individual operations of one or more methods are illustrated and described as separate operations, one or more of the separate operations can be performed concurrently and the operations do not need to be performed in the order illustrated. Structures and functionality presented as separate components in the exemplary configuration can be implemented as a combined structure or component. Similarly, structures and functionality presented as a single component can be implemented as separate components. These and other variations, modifications, additions, and improvements fall within the scope of the subject matter herein.

[0107] Unless specifically stated otherwise, discussions herein using terms such as "processing," "computing," "calculating," "determining," "identifying," "presenting," "rendering," "displaying," "showing," or the like can refer to actions or processes of a machine (e.g., a computer) that manipulates or transforms data represented as physical (e.g., electronic, magnetic, biological, or optical) quantities within one or more memories (e.g., volatile memory, non-volatile memory, or a combination thereof), registers or other machine component(s) that receive, store, communicate, or display information.

[0108] When implemented in software, any of the applications, controllers, services, or engines described herein can be stored in any non-transitory, tangible computer-readable memory medium (e.g., on a disk, in a laser disk, in a solid-state storage device, in a molecular memory storage device, or other storage medium in the RAM or ROM of a computer or processor, etc.). While the example systems disclosed herein are disclosed as including software and / or firmware executed on hardware, it is noted that such systems are merely illustrative and should not be considered limiting in scope. For example, it is contemplated that any or all of these hardware, software, and firmware components could be embodied exclusively in hardware, exclusively in software, or in any combination of hardware and software. Accordingly, those of ordinary skill in the art will readily recognize that the examples provided are not the only ways of implementing such systems.

[0109] Accordingly, although the present application has been described in reference to particular examples, these specific examples are merely illustrative of the present application and are not to be construed as limiting the present application in any manner. For a description of further embodiments of the application, reference is made to the following clauses:

[0110] It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting, unless explicitly stated otherwise herein. In particular, unless expressly identified as such, no aspect of the description herein is intended to be a limitation on the scope of the present application. It is further noted that the use of "a" or "an", which means "one or more", throughout this document and in its claims (if any) are not to be construed as limiting. In addition, the use of "comprising" or "including" or "having" or "frontier" or variants thereof in the description set forth herein is not intended to exclude other additives, components, integers or steps. Furthermore, "exemplary" or "for example" are used herein to mean "an example of. Thus, it is intended that the application be construed as including all aspects and permutations of the disclosure recited herein, including those presented in or peripheral to the detailed description and examples. It is intended that the application cover all alternatives, modifications and equivalents of the described examples falling within the scope of the claims.

[0111] Furthermore, although the foregoing text sets forth a detailed description of numerous different embodiments, it is to be understood that the scope of the patent is defined by the claims set forth in this patent. The detailed description is to be construed as exemplary only and does not describe every conceivable embodiment since describing every conceivable embodiment would be impractical, if not impossible. Numerous alternative embodiments could be implemented using the same or similar techniques, and other embodiments could be derived from a combination of the disclosed embodiments without departing from the scope of the claims.

Claims

1. A process control system for controlling an industrial process within a physical process environment, the process control system comprising: A server group comprising multiple server devices is configured to implement a software-defined distributed control system (DCS) environment by executing computer-readable instructions by one or more processors of each server device, the software-defined DCS environment including: One or more software-defined virtual process controllers, executing in corresponding virtual machines on the server group, are configured to control at least a portion of the industrial process in real time by communicating with multiple virtual nodes representing multiple physical field devices within the physical process environment in a software-defined DCS environment. An input / output (I / O) server is configured to communicateally couple the plurality of virtual nodes with each of the plurality of physical field devices within the physical process environment by mapping each virtual node of the plurality of virtual nodes to a physical I / O connection of the physical I / O server that connects the physical I / O server to a corresponding physical field device among the plurality of physical field devices, and by routing real-time communication signals between the plurality of virtual nodes and the plurality of physical field devices via the corresponding physical I / O connection; One or more DCS applications configured to interact with the software-defined virtual process controller, wherein at least one of the DCS applications is configured to adjust the operation of the software-defined virtual process controller; and One or more connection components, including one or more ports, switches, or routers, are configured to (i) connect to at least one physical I / O connection of the I / O server to send and receive the real-time communication signals using a general computer communication protocol for communication between the server devices of the server group, (ii) convert the real-time communication signals between the general computer communication protocol and an industrial process control communication protocol used for communication between the plurality of physical field devices via a process control network within the physical process environment, and (iii) connect to at least one corresponding physical field device via the process control network to send and receive the real-time communication signals using the industrial process control communication protocol.

2. The process control system according to claim 1, wherein, The software-defined DCS environment also includes one or more virtual networking components, which are configured to replicate one or more of the following physical network components: network switches, routers, or firewalls.

3. The process control system according to claim 1, 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 by specifying multiple virtual nodes within the virtual DCS network architecture and the logical connections between the virtual nodes and the multiple physical field devices.

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

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

6. The process control system according to claim 1, wherein, The one or more DCS applications include one or more of the following functions: manufacturing execution system or advanced process control system.

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

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

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

10. The process control system according to claim 1, wherein, The one or more DCS applications include those configured to predict the optimal number of server devices in the server group based on the resource usage of the server group and the resource availability of the plurality of server devices.

11. The process control system according to claim 1, wherein, The I / O server is configured as follows: Receive process data from the plurality of physical field devices via the physical I / O connections; The process data is routed to the plurality of virtual nodes, so that the one or more software-defined virtual process controllers receive the process data; Receive process control signals for the plurality of virtual nodes from the one or more software-defined virtual process controllers; as well as The process control signals are routed to the plurality of physical field devices via physical I / O connections, enabling the one or more software-defined virtual process controllers to control the portion of the industrial process.

12. A non-transitory computer-readable medium storing executable instructions for controlling an industrial process within 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 virtual process controllers, executing in corresponding virtual machines on the server group, are configured to control at least a portion of the industrial process in real time by communicating with multiple virtual nodes representing multiple physical field devices within the physical process environment in a software-defined DCS environment. An input / output (I / O) server is configured to communicatively couple the plurality of virtual nodes with each of the plurality of physical field devices within the physical process environment by mapping each virtual node of the plurality of virtual nodes to a physical I / O connection of the physical I / O server that connects the physical I / O server to a corresponding physical field device among the plurality of physical field devices, and by routing real-time communication signals between the plurality of virtual nodes and the plurality of physical field devices via the corresponding physical I / O connection, wherein the I / O server is configured to communicate with the plurality of field devices via one or more connection components, the one or more connection components including one or more terminals. An I / O port, switch, or router configured to (i) connect to at least one physical I / O connection of the I / O server to send and receive the real-time communication signals using a general computer communication protocol for communication between the server devices of the server group; (ii) convert the real-time communication signals between the general computer communication protocol and an industrial process control communication protocol used for communication between the plurality of physical field devices via a process control network within the physical process environment; and (iii) connect to at least one corresponding physical field device via the process control network to send and receive the real-time communication signals using the industrial process control communication protocol; and One or more DCS applications are configured to interact with the software-defined process controller, wherein at least one of the DCS applications is configured to adjust the operation of the software-defined virtual process controller.

13. The non-transitory computer-readable medium according to claim 12, wherein, The software-defined DCS environment also includes one or more virtual networking components, which are configured to replicate one or more of the following physical network components: network switches, routers, or firewalls.

14. The non-transitory computer-readable medium according to claim 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 by specifying the plurality of virtual nodes within the virtual DCS network architecture and the connections between the virtual nodes and the plurality of field devices.

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

16. The non-transitory computer-readable medium according to claim 12, wherein, When the executable instructions are executed by the processors of the plurality of server devices in the server group, the plurality of server devices in the server group implement multiple instances of each virtual DCS controller in the one or more software-defined virtual process controllers, and the multiple instances run simultaneously on different server devices in the server group.

17. The non-transitory computer-readable medium according to claim 16, wherein, When the executable instructions are executed by the processors of the plurality of server devices in the server group, the server group causes the server group to perform automatic load balancing among the plurality of instances of the software-defined virtual process controller based on the state of the plurality of server devices in the server group.

18. A method for controlling an industrial process within a physical process environment, the method comprising: Multiple physical field devices within the physical process environment are connected to a server group comprising multiple server devices via one or more input / output (I / O) connections of a physical I / O server. The server group is configured to implement a software-defined distributed control system (DCS) environment, wherein the field devices are connected to the physical I / O server via one or more connection components, the connection components including one or more ports, switches, or routers, configured to (i) connect to at least one physical I / O connection of the I / O server to send and receive real-time communication signals using a general computer communication protocol for communication between the server devices in the server group, (ii) convert the real-time communication signals between the general computer communication protocol and an industrial process control communication protocol used by the multiple physical field devices to communicate via a process control network within the physical process environment, and (iii) connect to at least one corresponding physical field device via the process control network to send and receive the real-time communication signals using the industrial process control communication protocol. Using an I / O server running on the server group, the communication of the multiple physical field devices is coupled to the virtual nodes in the software-defined DCS environment by mapping each virtual node of the multiple virtual nodes to a corresponding I / O connection of one or more I / O connections that connect the I / O server to the corresponding physical field devices in the multiple physical field devices, and by routing the real-time communication signals between the multiple virtual nodes and the multiple physical field devices via the one or more I / O connections. One or more software-defined virtual process controllers running in corresponding virtual machines within the software-defined DCS environment on the server group control at least a portion of the industrial process in real time by communicating with the plurality of virtual nodes within the software-defined DCS environment; and The operation of the one or more software-defined virtual process controllers is adjusted 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 virtual process controllers.

19. The method of claim 18, further comprising: Process data is received from the plurality of physical field devices via one or more I / O connections at the I / O server; The process data is routed to the plurality of virtual nodes using the I / O server; The I / O server receives process control signals for the plurality of virtual nodes. The I / O server is used to route the process control signals to the plurality of physical field devices to control the portion of the industrial process.

20. The method according to claim 18, wherein, The one or more DCS applications include virtual architecture configuration applications, and also include: The virtual architecture configuration application generates a user interface for the user, the user interface including multiple options for configuring virtual components within the software-defined DCS environment; and User input from the user is received at one or more DCS applications to define the virtual DCS network architecture by specifying the plurality of virtual nodes within the virtual DCS network architecture and the connections between the virtual nodes and the plurality of field devices.

21. The method of claim 18, further comprising: A data history database running in the software-defined DCS environment on the server group is used to automatically monitor process data within the software-defined DCS environment during the operation of the industrial process. as well as The process data monitored by the data history database application is automatically stored in the data storage associated with the server group.

22. The method of claim 18, further comprising: The one or more DCS applications detect the type of process data associated with the field devices among the plurality of field devices based on the data services at the one or more I / O connections; as well as The one or more DCS applications determine adjustments to the operation of the one or more software-defined virtual process controllers based on the type of process data.

23. The method according to claim 18, wherein, The one or more software-defined virtual process controllers include multiple instances of each virtual process controller in one or more software-defined virtual process controllers running simultaneously on different server devices in the server group, and the method further includes: The state change of one of the plurality of server devices in the server group is detected by the one or more DCS applications; and The load distribution among the plurality of server devices is adjusted by the one or more DCS applications based on the changes in the state.

Images