Modular Process Control Systems

Abstract

To provide a use of containers and / or other techniques to achieve greater modularity and / or other benefits with respect to a process plant and a process control system, more specifically, within a process control system.SOLUTION: A micro-service control architecture 120 provides a modular type and flexible platform for designing, diagnosing, updating and / or extending a process control system. Each service is containerized to provide portability and separability from other components of the process control system. In another aspect, a functional block diagram contains a "shadow" block that functions as an interface to an external custom computation engine, thus allowing the custom computation engine to operate synchronously with respect to other functional blocks in the functional block diagram.SELECTED DRAWING: Figure 3

Description

[Technical field]

[0001] The present disclosure relates generally to process plants and process control systems, and more specifically to the use of containers and / or other technologies to achieve greater modularity and / or other benefits within process control systems. [Background technology]

[0002] Distributed process control systems, such as those used in chemical, petroleum, industrial, or other process plants for manufacturing, refining, transforming, creating, or producing physical substances or products, typically include one or more process controllers communicatively coupled to one or more field devices via an analog bus, a digital bus, or a combined analog / digital bus, or via a wireless communication link or network. The field devices, which may be, for example, valves, valve positioners, switches, transmitters, sensors, etc., are located within the process control environment and generally perform physical or process control functions, such as opening and closing valves, measuring process and / or environmental parameters (e.g., temperature or pressure), to control one or more processes performed within the process plant or system. Smart field devices, such as field devices conforming to the well-known Fieldbus protocol, may also perform control calculations, alarm functions, and / or other control functions typically implemented within a controller. A process controller is also typically located within the plant environment and executes a controller application that receives signals indicative of process measurements made by the field devices and / or other information related to the field devices, and executes, for example, different control modules. The control modules make process control decisions and generate control signals based on the received information and coordinate with control modules or blocks executing in the field devices, e.g., HART®, WirelessHART®, or Foundation® Fieldbus field devices. The control modules implemented in the controller send control signals over communication lines or links to the field devices, thereby controlling the operation of at least a portion of a process plant or system, e.g., controlling at least a portion of one or more industrial processes operating or performed within the plant or system.I / O devices are also typically located within the plant environment and are typically placed between a controller and one or more field devices to enable communication, for example by converting electrical signals to digital values ​​and vice versa.

[0003] Information from the field devices and controllers is typically made available via a communications network to one or more other hardware devices, such as operator workstations, personal computers or computing devices, data historians, report generators, centralized databases, or other centralized computing devices typically located in a control room or other location away from the harsher field environment of the plant. These hardware devices execute applications that enable operators to perform functions related to the control of the process and / or operation and monitoring of the process plant (e.g., changing settings of process control routines, modifying the operation of control modules in the controllers or field devices, viewing the current state of the process, viewing alarms generated by the field devices and controllers, simulating the operation of the process for purposes of training personnel or testing process control software, maintaining and updating configuration databases, etc.). The communications networks utilized by the hardware devices, controllers, and field devices may 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 Automation Solutions includes multiple applications stored in and executed by different devices located at various locations within a process plant. Configuration applications resident in one or more workstations or computing devices within the back-end environment of the process control system or plant allow users to create or modify process control modules and download these process control modules over a communication network to dedicated distributed controllers. Typically, these control modules are composed of communicatively interconnected function blocks that are objects in an object-oriented programming protocol that perform functions within a control scheme based on inputs thereto and provide outputs to other function blocks in the control scheme. The configuration application may also allow the configuration designer to create or modify operator interfaces that are used by a viewing application to display data to an operator and to allow the operator to change settings such as set points within a process control routine. Each dedicated controller, and in some cases one or more field devices, stores and executes a respective controller application that runs the control modules assigned to and downloaded thereto to implement the actual process control functions. The display application may execute on one or more operator workstations (or one or more remote computing devices communicatively coupled to the operator workstations and the communications network) and receive data from the controller application via the communications network and display this data to a designer, operator, or other user of the process control system using a user interface, and may provide any of a number of different views, such as an operator's view, an engineer's view, a technician's view, etc. A data historian application typically stores the configuration of the current process control routines and data associated therewith.

[0005] Typically, process control systems such as those discussed above are complex and contain a large number of software components. Over time, these software components tend to become highly interdependent, such that a component cannot be changed independently without taking into account a large number of other software components. This difficulty is often exacerbated by efforts to facilitate development in the short term, accompanied by efforts to address project management and delivery timing issues by introducing dependencies on other software components in the long term. As a result, the deployment of new services within traditional control systems is not truly modular. This can be particularly problematic with the recent move towards distributed control systems.

[0006] The difficulty of modifying existing software components makes introducing new functionality within a control system more difficult because there are likely to be a large number of "integrated" software components with which a new control system feature or function must interface. Typically, developers must manually discover all of the necessary application programming interface (API) hooks, understand their interdependencies, and develop the new control system feature or function as yet another set of integrated software components. This not only exacerbates the problem of future maintenance of the software components, but also reduces the overall ability of the control system software to support new technologies over time.

[0007] Some process control systems require custom calculations / algorithms that cannot be implemented within the control system platform, because the ability to execute the control algorithm depends on the support capabilities of the particular control system and the contextual configuration of the control strategy. Currently, developers rely on external interface protocols (e.g., Modbus, Modbus / TCP, EtherNet / IP, OPC, OPC-UA, IEC61850, etc.) to manually wire up custom calculation engines that execute such control algorithms. However, this process of using traditional external interface protocols to drive control systems with custom calculations is fraught with complexity and instability. Although external interface protocols are designed for this purpose, the mechanisms by which data is read (e.g., network, inter-process communication (IPC), etc.) can be unreliable. In addition, the platform that executes the custom calculation engine may have synchronization issues (e.g., sampling issues, aliasing, etc.) for both the ingress and egress data paths as the custom calculation engine processes and makes the data available. Furthermore, it is generally difficult to validate these types of external interfaces with agencies such as the FDA or EPA. Summary of the Invention

[0008] Disclosed are techniques, systems, apparatus, components, devices, and methods for increasing the modularity and / or providing other benefits (e.g., increased design freedom) of process control systems, thereby facilitating the development, modification, troubleshooting, and / or other aspects of such systems. Such techniques, systems, apparatus, components, devices, and methods may be applied to industrial process control systems, environments, and / or plants, which are also referred to interchangeably herein as "industrial control," "process control," or "process" systems, environments, and / or plants. Typically, such systems and plants control in a distributed manner one or more processes that operate to manufacture, refine, transform, generate, or produce physical materials or products.

[0009] In one aspect of the disclosure, a process control system utilizes a "microservices" architecture in which containerized control system services are modular and independently deployable. These control system services are supported by a control system service framework and communicate via a service message bus. In some embodiments, the service message bus and service message protocol are independent of the underlying communication network protocol.

[0010] Each control system service is associated with its own interface, which defines how other control system services can interact with it (e.g., send data to it or receive data from it). In some implementations, the interface of each control system service is independent of all other control system services, and each control system service does not require the presence of other control system services. A process control system may be decomposed into modular, independently deployable control system services, for example, according to subdomains of business capabilities or similar components. As used herein, the term "control system service" may refer to a service that is essential to the control of a physical process (e.g., control logic services or control execution services) or a service associated with a physical process in some other manner (e.g., diagnostic services, data historian services, operator console services, etc.). Each control system service may be deployed "at run time" to meet the needs of a customer site, and customization of a particular process control system may be achieved by modifying the combination of control system services deployed to that process control system.

[0011] In some implementations, each control system service is instantiated within a container, which may be any independent self-deployable computational vessel (e.g., an instance of a Docker or LXD image, a virtual machine, etc.). Each container is standalone and can run by itself or in combination with other standalone containers. A single hardware device may host only a single service (i.e., may implement / store a single service container) or may host multiple service containers, depending on the embodiment. Data flow through a given service container is defined by the message protocol and service message bus applied within the process control system.

[0012] Control system services can share and maintain a standard mechanism for defining and supporting common functionality that applies to all control system service instances (i.e., "cross-cutting concerns"). This framework may provide, for example, the ability to develop, test, debug, and deploy control services in a common manner, and may be malleable to facilitate the implementation of different or newer control system services.

[0013] In some embodiments, each control system service maintains a dedicated database of information specific to that service. Additionally or alternatively, one or more of the control system services may provide other control system services with access to a central database.

[0014] To facilitate delivery of service messages between multiple services (i.e., "service endpoints"), a process control system may include a service message router responsible for forwarding message traffic on a service message bus. The service message router may also connect to service message routers of other process control systems to connect and forward communications between process control systems on a first-class basis such that communications between process control systems may be consumed with the same importance / priority / etc. as first-class communications originated and consumed within a single process control system. "First-class" communications, and quality of service in general, are discussed in more detail below with reference to FIG. 2. The service message router may also enable delivery of messages to newly discovered control system services. Discovery of control system services may be centralized or decentralized, depending on the embodiment.

[0015] To prevent malicious actors from interfacing with the process control system via the service message bus, messages destined for the service endpoints and the service message bus may be scrutinized for their authentication, authorization, privilege level, and accuracy, and users of the system may be logged for every major action performed. To further enhance security, message traffic may be encrypted by the service endpoints that originate the messages.

[0016] In some implementations, a control system service can encapsulate one or more other control system services, where the encapsulated service maintains the ability to communicate on a first-class basis with other control system services within the process control system.

[0017] Leveraging a modular microservices control architecture greatly simplifies the development, modification, extension, and debugging of process control systems. For example, developers can introduce new control system services, update existing services, and troubleshoot them without having to manually discover the various API hooks and their interdependencies. This may also make it much more feasible for third parties to develop their own control system services, fostering a robust marketplace for services.

[0018] Additionally, the use of containerized services can significantly mitigate the impact of certain hardware limitations. For example, for load balancing or other reasons, a control system service may be migrated from one hosting device (e.g., server, field device, etc.) to another hosting device in a process control system. To accomplish this, the new hosting device may create an instance / container of the migrating control system service, and the original service instance / container may transfer all state and runtime data to the new service instance / container. A service message bus may enable control system services to communicate regardless of the physical location or type of the service host.

[0019] As another example, to maintain redundancy of a control system service, the active and backup devices may run redundant instances of a single control system service. The redundancy scheme may be, for example, a hot standby approach or a dual drive mechanism. Redundancy may be applied to any control system service and any service host device, regardless of the function of the host device within the process control system. For example, a data historian service may be hosted by a dedicated historian server, a gateway device, or a valve field device, etc.

[0020] In some embodiments, N (>1) instances or copies of a particular service are hosted by N respective hardware servers (and / or other physical devices), which handle message traffic by implementing the respective service instances / copies in parallel in a load-balanced manner. In addition to providing the bandwidth-related benefits of load balancing, fault tolerance is improved. For example, if one server fails, N-1 other copies of the service remain and can still be utilized. In other embodiments, similar to the hot-standby approach described above, only one service instance handles message traffic, and the other copies of the service are not utilized until a particular event (e.g., device failure) "activates" one of the other copies.

[0021] In another aspect of the present disclosure, the process control system integrates a custom computation engine that executes control algorithms outside of the process control system. The term "custom" as used herein may refer broadly to anything that is not native to the process control system or to a particular portion of the process control system. A custom control algorithm may be, for example, an algorithm that the process control system cannot implement itself. In this aspect, the process control system generally utilizes function blocks to control a physical process, with each function block representing a specific control algorithm and each function block having configurable inputs and outputs. The order of execution is determined by the connections between the inputs and outputs of the various function blocks. The function blocks may be, for example, blocks of a function block diagram according to the IEC 61131-3 specification.

[0022] To incorporate an external custom calculation engine, the process control system includes a “shadow” function block (also referred to herein as a “shadow block”) that provides an interface to the custom calculation engine. In this way, in some embodiments, the control algorithms of the external engine affect the process control system in a first-class manner, i.e., in a manner similar to any other function block defined in the function block diagram. In some embodiments, the custom calculation engine is containerized (e.g., an instance of a Docker or LXD image, etc.), in which case the shadow block forwards its own input(s) to the container and receives output(s) from the container to use as its own output(s). In some embodiments, the containerization provides isolation of the custom calculation engine from other software entities, except for interfacing with the shadow block (e.g., via the API of the custom calculation engine container).

[0023] Furthermore, the use of the shadow block interface allows custom calculation engines to be represented, instantiated, and executed in function block diagrams (e.g., as defined in IEC 61131-3). This allows control system engineering personnel to interact with custom calculation engines when configuring or monitoring the system without formal or specialized training. For example, process alarms, historian interaction, data acquisition, etc. can occur without the need for specialized custom interfaces. Furthermore, since the shadow block forces the custom calculation engine to execute in a virtually synchronous manner via the shadow block interface, the function block diagram executes in a more deterministic and predictable manner. This avoids, or at least reduces the likelihood of, problems resulting from asynchronous execution of custom calculation engines, such as sampling rate issues, aliasing, and system noise, and makes it easier to enforce the desired execution order. [Brief description of the drawings]

[0024] [Figure 1] FIG. 1 is a block diagram of an example process plant or process control system. [Diagram 2] FIG. 1 is a block diagram illustrating an example of a microservices control architecture for a process control system. [Diagram 3] FIG. 3 is a block diagram of a first example of the microservices control architecture of FIG. [Figure 4] FIG. 3 is a block diagram of a second example of the microservices control architecture of FIG. 2 in which the process control system implements service redundancy. [Diagram 5] FIG. 3 is a block diagram of a third example embodiment of the microservices control architecture of FIG. 2 in which services in one process control system can interact with services in another process control system. [Figure 6] FIG. 4 is a block diagram of a fourth example embodiment of the microservices control architecture of FIG. 2 in which one service of the process control system encapsulates another service of the process control system. [Figure 7] 1 illustrates a prior art arrangement for interfacing with a custom calculation engine. [Figure 8] FIG. 13 is a block diagram of an example of control execution flow utilizing a shadow block to interface with a custom calculation engine. [Figure 9] FIG. 2 is a block diagram showing an example of a control execution flow using a specific functional block. [Figure 10] FIG. 1 is a block diagram illustrating an example of a process control system architecture utilizing shadow blocks. [Figure 11] FIG. 1 is a flow diagram of an exemplary method for implementing a modular control system architecture. [Figure 12] FIG. 1 is a flow diagram of an example method for incorporating custom calculations in a process control system. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0025] 1 is a block diagram of an example process control system 10 that may utilize any one or more of the novel techniques described herein. The process control system 10 generally processes signals indicative of process measurements made by field devices to implement control routines and generates control signals that are transmitted over wired or wireless process control communication links or networks to other field devices to control the operation of a physical process within the process control system 10. Typically, at least one field device performs a physical function (e.g., opening or closing a valve, raising or lowering a temperature, taking measurements, sensing a condition, etc.) to control the physical process. Some types of field devices communicate with other devices (e.g., controllers) using I / O devices.

[0026] 1, the process controller 11 is communicatively connected to wired field devices 15-22 via input / output (I / O) cards 26 and 28, and to wireless field devices 40-46 via a wireless gateway 35 and a communications network 80. However, in some embodiments of the "microservices" architecture described herein, the process control system 10 need not include dedicated process control devices. For example, as discussed in further detail below, the control functionality (e.g., control logic / execution) of the process controller 11 may be implemented purely as a service that is distributed (hosted) partially or wholly among other physical devices (e.g., field devices, operator workstations, etc.) having other dedicated functionality.

[0027] Regardless of whether the process control system 10 includes a controller 11, the communications network 80 may include one or more wired and / or wireless communications links and may be implemented using any desired or suitable communications protocol(s), such as, for example, an Ethernet protocol. In some configurations (not shown) that include a controller 11, the controller 11 may be communicatively coupled to the wireless gateway 35 using one or more communications networks other than the communications network 80 and may be implemented using any number of other wired or wireless communications links supporting one or more communications protocols, such as, for example, Wi-Fi or other IEEE 802.11 compliant wireless local area network (WLAN) protocols, mobile communications protocols (e.g., WiMAX, LTE, or other ITU-R compatible protocols), Bluetooth®, HART®, WirelessHART®, Profibus, Foundation®, Fieldbus, etc.

[0028] One or more devices of the process control system 10 (possibly including the controller 11) host control system services for implementing a batch or continuous process using at least some of the field devices 15-22 and 40-46. Exemplary control system services are discussed below in conjunction with FIGS. 2-6. In one embodiment, in addition to being communicatively connected to the network 80, the controller 11 is communicatively connected to at least some of the field devices 40-46 using any desired hardware and software associated with, for example, standard 4-20 mA devices, I / O cards 26, 28, and / or any smart communication protocol such as Foundation®, Fieldbus protocol, HART® protocol, WirelessHART® protocol, etc. In the example of FIG. 1, the controller 11, field devices 15-22, and I / O cards 26, 28 are wired devices and the field devices 40-46 are wireless field devices. Of course, the wired field devices 15-22 and the wireless field devices 40-46 may conform to any other desired standard(s) or protocol, such as any wired or wireless protocol, including any standard or protocol developed in the future.

[0029] The process controller 11 in the example of FIG. 1 includes a processor 30 and a memory 32. The processor 30 is configured to communicate with the field devices 15-22 and 40-46, and with other nodes communicatively connected to the controller 11. The memory 32 (e.g., random access memory (RAM) and / or read-only memory (ROM)) may store computing vessels (e.g., containers) executed by the processor 30 to provide certain control system services, as discussed further below. Although not shown, any one or more of the other devices depicted in FIG. 1 (e.g., the field devices 15-22 or 40-46, the wireless gateway 35, or any of the devices 7a, 7b, 7c, 8, or 12 discussed below) may also include memory and processors that enable those devices to host one or more control system services as well.

[0030] In some embodiments, the process control system 10 (i.e., the controller 11 and / or other devices) implements a control strategy using what are commonly referred to as function blocks, where each function block operates in conjunction with other function blocks (through communications called links) to implement a process control loop within the process control system 10. A control-based function block typically performs one of an input function (e.g., associated with a transmitter, sensor, or some other process parameter measurement device), a control function (e.g., associated with a control routine that performs control such as PID control, fuzzy logic, etc.), or an output function that controls the operation of some device (e.g., a valve or pump) to perform some physical function within the process control system 10. Of course, hybrid and other types of function blocks exist. The function blocks may be stored in and executed by the controller 11 (as is typical when these function blocks are used for standard 4-20 mA devices or associated with some types of smart field devices such as HART® devices), may be stored in and implemented in the field devices themselves (as might be the case for Foundation® Fieldbus devices), and / or may be stored or implemented by other devices in the process control system 10. The function blocks are discussed further below in connection with the aspects of the invention discussed in Figures 8-10 and 12.

[0031] Wired field devices 15-22 may be any type of device, such as sensors, valves, transmitters, positioners, etc., while I / O cards 26 and 28 may be any type of I / O device conforming to any desired communication or controller protocol. In Fig. 1, field devices 15-18 are standard 4-20 mA or HART® devices that communicate via analog lines or combined analog and digital lines to I / O card 26, while field devices 19-22 are smart devices, such as Foundation® Fieldbus field devices, that communicate via a digital bus to I / O card 28 using the Foundation® Fieldbus communication protocol. However, in some embodiments, at least some of the wired field devices 15, 16 and 18-21 and / or at least one of the I / O cards 26, 28 additionally or alternatively communicate with the controller 11 using the network 80 and / or other suitable control system networks and protocols (e.g., Profibus, DeviceNet, Foundation®, Fieldbus, ControlNet, Modbus, HART®, etc.).

[0032] In FIG. 1 , the wireless field devices 40-46 communicate over a wireless process control communication network 70 using a wireless protocol such as the WirelessHART® protocol. Such wireless field devices 40-46 may communicate directly with one or more other devices or nodes of the wireless network 70 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 not configured to communicate wirelessly, the wireless field devices 40-46 may utilize a wireless gateway 35 connected to the network 80 or another process control communication network. The wireless gateway 35 provides access to the various wireless devices 40-58 of the wireless communication network 70. In particular, the wireless gateway 35 provides a communication coupling between the wireless devices 40-58, the wired devices 15-28, and / or other nodes or devices of the process control system 10. For example, the wireless gateway 35 may provide a communication coupling using the network 80 and / or one or more other communication networks of the process control system 10.

[0033] Similar to the wired field devices 15-22, the wireless field devices 40-46 of the wireless network 70 perform physical control functions within the process control system 10, such as opening or closing a valve or measuring a process parameter. However, the wireless field devices 40-46 are configured to communicate using the wireless protocol of the network 70. In this manner, the wireless field devices 40-46, the wireless gateway 35, and the other wireless nodes 52-58 of the wireless network 70 are producers and consumers of wireless communication packets.

[0034] In some configurations of the process control system 10, the wireless network 70 also includes non-wireless devices. For example, in FIG. 1, the field device 48 of FIG. 1 is a conventional 4-20 mA device, and the field device 50 is a wired HART® device. To communicate within the network 70, the field devices 48 and 50 are connected to the wireless communication network 70 via wireless adapters 52A, 52B. The wireless adapters 52A, 52B support wireless protocols such as WirelessHART® and may also support one or more other communication protocols such as Foundation® Fieldbus, Profibus, DeviceNet, etc. Additionally, in some embodiments, the wireless network 70 includes one or more network access points 55A, 55B, which may be separate physical devices in wired communication with the wireless gateway 35 or may be provided with the wireless gateway 35 as an integral device with the wireless gateway 35. Additionally, the wireless network 70 may also include one or more routers 58 for forwarding packets from one wireless device to another within the wireless communication network 70. In FIG. 1, wireless devices 40 - 46 and 52 - 58 communicate with each other and with wireless gateway 35 via wireless links 60 of wireless communication network 70 and / or via network 80 .

[0035] 1, the process control system 10 includes one or more operator workstations or user interface devices 8 communicatively connected to a network 80. Through the operator workstations 8, an operator can view and monitor the runtime operation of the process control system 10, as well as take any diagnostic, corrective, maintenance, and / or other actions that may be required. At least some of the operator workstations 8 may be located in various protected areas within or near the process control system 10, and in some embodiments, at least some of the operator workstations 8 may be located remotely but still communicatively connected to the process control system 10. The operator workstations 8 may be wired or wireless computing devices.

[0036] In some configurations, the process control system 10 includes one or more other wireless access points 7a that communicate with other devices using other wireless protocols, such as Wi-Fi or other IEEE 802.11 compliant WLAN protocols, mobile communication protocols such as WiMAX (Worldwide Interoperability for Microwave Access), LTE (Long Term Evolution) or other International Telecommunication Union Radiocommunication Sector (ITU-R) compatible protocols, shortwave wireless communications such as Near Field Communication (NFC) and Bluetooth® protocols, or other suitable wireless communication protocols. Typically, the wireless access point(s) 7a enable handheld or other portable computing devices to communicate over a respective wireless process control communication network that supports a different wireless protocol than the wireless network 70. For example, the wireless or portable user interface device 8 may be a portable workstation or diagnostic test device utilized by an operator within the process control system 10. In some scenarios, in addition to the portable computing device, one or more process control devices (e.g., controller 11, one or more of field devices 15-22, and / or one or more of wireless devices 35, 40-58) also communicate using the wireless protocol supported by access point 7a.

[0037] In some configurations, the process control system 10 includes one or more gateways 7b, 7c to systems (also referred to herein as "edge gateways") that are external to the process control system 10. Typically, such systems are associated with customers or providers of information generated or acted upon by the process control system 10. For example, the process control system 10 may include a gateway node 7b for communicatively connecting the process plant that includes the process control system 10 with another process plant. Additionally or alternatively, the process control system 10 may include a gateway node 7c for communicatively connecting the process control system 10 with external public or private systems, such as, for example, a process control system of another provider, a third party provider of a custom calculation engine (e.g., as discussed in more detail below), a laboratory system (e.g., a Laboratory Information Management System or LIMS), an operator round database, a material handling system, a maintenance management system, a product inventory management system, a production scheduling system, a weather data system, a shipping and handling system, a packaging system, the Internet, and / or other external systems.

[0038] 1 illustrates a particular arrangement of a particular number (of particular types) of devices, it should be noted that this is merely an exemplary, non-limiting embodiment. For example, the process control system 10 may omit the controller 11, as described above, or may include multiple controllers similar to the controller 11. As another example, the process control system 10 may include any number of wired and / or wireless field devices similar to field devices 15-22 and / or 40-50, any number of other devices (e.g., devices 7a, 7b, 7c, 8, 12, 52a, 52b, 55a, 55b, etc.).

[0039] Additionally, it should be noted that the process control system 10 of FIG. 1 may include a field environment (e.g., a “process plant floor”) and a back-end environment (e.g., including the server 12) that are communicatively connected by a communication network 80. As shown in FIG. 1, the field environment includes physical components (e.g., process control devices, networks, network elements, etc.) that are disposed, installed, and interconnected therein and operate to control a process during run-time. For example, the controller 11, I / O cards 26, 28, field devices 15-22, and other devices and network components 35, 40-50, 52, 55, 58, and 70 are located, disposed, or included within the field environment of a plant that includes the process control system 10. Generally speaking, in the field environment of the process control system 10, raw materials may be received and processed using the physical components disposed therein to produce one or more products.

[0040] The back-end environment of a process plant, including the process control system 10, includes various components that are shielded and / or protected from the harsh conditions and materials of the field environment. For example, the back-end environment may include operator workstations 8, servers 12, and / or functionality that supports the runtime operation of the process control system 10. In some embodiments, the various computing devices, databases, and other components and devices included in the back-end environment of a plant, including the process control system 10, may be physically located in different physical locations, some of which may be located locally to the process plant and some of which may be located remotely.

[0041] Figure 2 is a block diagram of an example microservices control architecture 100 that may be implemented in a process control system, such as, for example, the process control system 10 of Figure 1. The microservices control architecture 100 is described below with reference to devices / components of the process control system 100, although it will be understood that other systems and / or devices may instead implement the architecture 100.

[0042] The exemplary microservices control architecture 100 includes multiple control system services 102-1 through 102-N, where N may be any suitable integer (e.g., units, tens, hundreds, etc.). Each of the control system services 102-1 through 102-N is associated with a respective one of N service interfaces 104-1 through 104-N and a respective one of N service databases 106-1 through 106-N. For ease of notation, the control system services 102-1 through 102-N, the service interfaces 104-1 through 104-N, and the service databases 106-1 through 106-N may be generally referred to herein as services 102, service interfaces 104, and service databases 106, respectively.

[0043] The services 102 may include any type of service associated with a process control system. For example, the services 102 may include a number of services essential to the control of a physical process. As an example, the services 102-1 and 102-2 may be control logic services, and the service 102-3 (not shown in FIG. 2 ) may be a control execution service that, when activated or invoked, directs the execution sequence of the control logic of the services 102-1, 102-2, and possibly other control logic services. As another example, the services 102 may include a control configuration service and a control communication service. The services 102 may also, or instead, include a number of services associated with the physical process in some other manner, such as monitoring services, diagnostic services, analytics services, etc. For example, the services 102 may include an operator console service, an alarm management service, an event management service, a diagnostic service, a remote access service, an edge gateway service, an input / output service, a data historian service, an external and / or peripheral input / output conversion service, a key performance display service, a data monitoring service, a message pass-through service, a safety logic service, and / or other suitable types of services associated with a control system. Some or all of the services 102 may be deployed at run time to suit the needs of a customer site, and customization of a particular process control system (e.g., system 10) may be relatively easily achieved by modifying the combination of services 102 deployed to that process control system.

[0044] In some embodiments, one or more of the services 102 are machine learning or artificial intelligence (AI) services. For example, the services 102 may include analytics services that predict future performance and / or problems associated with a control system, and / or services that predict / infer parameters that cannot be directly measured within the control system (e.g., providing "soft sensing" of physical parameters), and the like. For example, one or more of the services 102 may employ machine learning models, such as neural networks, that are trained according to supervised or unsupervised learning techniques. In some embodiments, the machine learning or AI service 102 may provide an interface 104 that enables the service 102 to obtain training data in order to create and / or update (tune) models implemented by that service 102.

[0045] Each of the services 102 is "containerized," i.e., instantiated within a container. As used herein, the term "container" refers to any independent, self-deployable compute container, such as an instance of a Docker or LXD image, a Windows container, a BSD jail, a chroot jail, a process, a thread of execution, or a virtual machine (e.g., a virtual machine), where each container is standalone and can run by itself or in combination with other standalone containers.

[0046] The containerized services 102 are modular and independently deployable and can communicate with each other via a service message bus 108. As used herein, the term "service message bus" may refer to a computer network and / or other means of communication, such as direct API libraries, inter-process communication, intra-process communication, remote procedure calls, shared memory, etc., and may include or be layered on top of wired and / or wireless (e.g., radio frequency) networks. The service message bus 108 may be independent of the underlying communication network protocol(s) in some embodiments. For example, with reference to the process control system 10 of FIG. 1, the service message bus 108 may operate on top of the communication network 70 and / or network 80, as discussed above, independent of any protocols associated with those networks (e.g., IEEE 802.11 compliant WLAN, WiMAX, LTE, Bluetooth, HART, WirelessHART, Profibus, Foundation, Fieldbus, etc.).

[0047] The service message bus 108 and the service message router 110 may support different quality of service (QoS) levels for different communications. For example, critical service messages (e.g., messages used to control physical processes in real time) and certain other service messages may be "first class" messages that are less time-sensitive. As an example, if the communication bandwidth of the service message bus 108 (e.g., as defined by the bandwidth of an underlying network such as network 70 or 80) is fully utilized, the service message router 110 may determine which messages to send, or which messages to send first, based on a priority corresponding to the QoS level of each message. The router 110 may delay or even drop certain message types, such as historia service messages or diagnostic service messages, for example, if higher priority service messages must be transmitted within the limited available bandwidth. A service 102 attempting to transmit lower priority messages may compensate for this degraded operation by using reliable messaging techniques, such as, for example, retransmitting messages, skipping older messages, or slowing down the transmission rate of messages to the communication endpoint service 102.

[0048] Each service 102 may be hosted by any of a number of different physical devices (e.g., any device with sufficient processor, memory, and communication capabilities). A device may “host” a service by, for example, storing in memory all code and all dependencies necessary to support the service and executing the stored instructions as necessary to implement the service and any related functionality (e.g., discovery-related functionality, discussed below). In some embodiments, for example, a device hosts a service 102 by storing an instance of an image (e.g., a Docker or LXD image) corresponding to that service. Each physical device that hosts one or more services may implement a “service host” entity that represents the physical device to the rest of the process control system and manages the redundancy lifecycle of the service(s) hosted by the physical device (e.g., manages state transfer for redundancy switching and / or performs considerations regarding service migration, as discussed in more detail below).

[0049] 1, the controller 11 may host all of the services 102, and / or other devices in the system 10 may host some or all of the services 102. As just one example, the controller 11 may host the control logic and execution services of the services 102, the operator workstation 8 may host the operator console services of the services 102, and the server 12 may host the control configuration services of the services 102. As another example, different ones of the field devices 15-22 and / or 40-50, and / or other devices of the system 10, may host all of the control logic and execution services of the services 102, and the system 10 may omit the controller 11 entirely.

[0050] Each of the service interfaces 104 may be an API, where the service interface 104 defines how other services 102 can interact with the corresponding service 102 (e.g., send messages to and receive messages from the service 102). For example, the service interface 104-1 may include an API that allows some or all of the services 104-2 through 104-n to exchange messages with the service 104-1. Each API of the interface 104 may be associated with, for example, a particular syntax and list of parameters specific to the corresponding service 102. In some embodiments, the interface 104 of each service 102 is independent of all other services 102, and each service 102 does not require the presence of the other services 102. The data flow through the container of a given service 102 via each interface 104 is defined by the message protocol of the service message bus 108. The messages communicated via the service message bus 108 may be, for example, data messages or management messages (e.g., heartbeat messages).

[0051] Each of the service databases 106 is a dedicated database that stores information specific to a corresponding one of the services 102 and may be any suitable type of data storage mechanism using any suitable type of data structure (e.g., raw data files, relational databases, transactional databases, text database files, structured text mechanisms, etc.). In other embodiments, one or more of the services 102 may not include a respective, dedicated database 106. In some embodiments, for example, at least one of the services 102 provides a centralized database service available to some or all of the other services 102 (e.g., a centralized database that replaces or supplements one or more dedicated databases 106).

[0052] Services 102 may share and maintain a standard mechanism for defining and supporting common functionality (i.e., "cross-cutting concerns") that apply to all control system service instances. This framework may provide, for example, the ability to develop, test, debug, and deploy control services in a common manner, and may be malleable to facilitate the implementation of different and newer control system services.

[0053] To facilitate the delivery of service messages between multiple services 102 via the service message bus 108, the architecture 100 may include a service message router 110 responsible for forwarding message traffic on the service message bus 108. The service message router 110 may be a physical component / device of the control system or may be a software component. The service message router 110 facilitates fan-out and fan-in messaging, such that one of the services 102 can request the service message router 110 to send a message to one or multiple other services 102. Furthermore, in some embodiments, the service message router 110 can bundle messages from multiple services 102 (e.g., services 102-1 and 102-2) and send the bundled message to a single other service 102 (e.g., service 102-3, not shown in FIG. 2).

[0054] Although shown in FIG. 2 (and in some subsequent figures) as an intermediate point / connection between two different portions of the service message bus 108, the service message router 110 and the service message bus 108 may be arranged according to any suitable network configuration. In various embodiments, for example, the service message router 110 may be arranged as an additional parallel node on the service message bus 108 (e.g., similar to each of the services 102), the service message router 110 and the services 102 may be arranged as a mesh network, with all the services 102 communicatively coupled to the service message router 110 in a star network configuration. However, the service message bus 108 may be agnostic to the network topology (star, mesh, etc.) of any underlying communication network(s). The service message router 110 may use any suitable routing technique (e.g., flooding, multiplexing, etc.) suitable for the network configuration used.

[0055] With reference to the process control system 10 of FIG. 1, the service message router 110 may be implemented by any device, such as, for example, the controller 11, the wireless gateway 35, or the server 12. In some embodiments, the functionality of the service message router 110 is distributed among two or more physical devices (e.g., the controller 11 and the wireless gateway 35). In some embodiments, the service message router 110 may also connect (e.g., via the gateway 7c) to other, similar service message routers to enable delivery of messages to and from other control system services (similar to the service 102) hosted by another process control system. In this manner, the service message router 110 may connect and route communications between different process control systems on a first-class basis, such that communications between the process control systems can be consumed with the same importance / priority / etc. as first-class communications that occur and are consumed within a single process control system. An example of control system interconnectivity is discussed below with reference to FIG. 5. In some embodiments (e.g., those that access cloud-based services), the use of external services is limited to services associated with less stringent timing requirements, such as data analytics services.

[0056] In some embodiments and / or scenarios, a third party may develop a service for implementation in the process control system. For example, a computing device (e.g., server 12) of the process control system 10 may obtain (e.g., upload or download) an image corresponding to a particular service (e.g., a control logic service) from a third party via the gateway 7c and an Internet link. That computing device, or another device (e.g., controller 11) of the process control system 10, may then create an instance of the image to host the service.

[0057] In some embodiments, the microservices control architecture 100 implements auto-discovery techniques to support the initialization, modification, and / or extension of the set of services 102. Discovery of services 102 may be centralized or decentralized, depending on the embodiment. FIG. 2 illustrates an embodiment in which the architecture 100 utilizes a centralized mechanism for service discovery. To this end, the architecture 100 includes a service registry 112 that maintains a registry of control system services. The service registry 112 may be implemented / maintained by any physical device in the process control system (e.g., the controller 11, the gateway 35, any of the field devices 15-22, 40-50 in the process control system 10). The service registry 112 monitors (and in some embodiments controls) the presence of each service 102 and notifies each service 102 of other newly installed services 102. Alternatively, each existing service 102 may query (e.g., periodically) the service registry 112 to learn the current complete set of services 102, or a specific subset.

[0058] In an alternative embodiment, the process control system employs a decentralized mechanism for control service discovery. In one such embodiment, each newly added service 102 broadcasts / announces its availability to all other existing services 102 on the service message bus 108 (e.g., via the service message router 110). In this embodiment, the existing services 102 are responsible for maintaining a record of the new service 102 and its connectivity and serviceability.

[0059] In some embodiments where multiple service message routers communicate on the same interconnected network (e.g., as in the exemplary embodiment of FIG. 4 discussed below), the routers may automatically discover each other and all services connected to the service message router. For example, each service message router may be responsible for sending a complete list of available services 102 known to it (e.g., obtained from a service registry such as service registry 112) to other discovered service message routers.

[0060] In some embodiments, a process control system (e.g., system 10) may relocate various services 102 from one hosting device to another hosting device within the process control system. This service "migration" may be performed, for example, for load balancing purposes. Conceptually, this may be thought of as a single service 102 (e.g., service 102-1) moving to a new hosting device or as a first service 102 being removed from the process control system and a second, identical service 102 being added.

[0061] In one such embodiment, the migration service 102, while still hosted by the original device, notifies the service message router 110 that the migration service 102 intends to leave its current host device in favor of another "target" host device. The service message router 110 may then notify the service host entity of the target hosting device of the migration attempt. In response, the target hosting device creates an instance / container of the migrating service 102, and the service 102 transfers all state and runtime data from the original hosting device to the new instance of the service 102 on the target hosting device. Once this transfer is complete, the service message router 110 reroutes all messages to the new instance and notifies the service host entity of the original hosting device that the original service 102 may be terminated. Of note, the service 102 is not necessarily specific to a particular type of physical device. For example, a particular service 102 may move from a physical control device (e.g., any of field devices 15-22, 40-50) to a workstation (e.g., user interface device 8) or an edge gateway device (e.g., gateways 7b or 7c), etc. The service message bus 108 allows the services 102 to communicate regardless of the physical location or type of host device.

[0062] For the purpose of maintaining redundancy of a particular service 102, different physical devices may run redundant versions of the same service 102. The redundancy scheme may be a hot standby approach (e.g., a first physical device is actively providing the service 102-1, and a second physical device can provide the service 102-1 as a backup with no or minimal data loss if the first physical device fails) or a dual drive mechanism (e.g., the first and second physical devices provide the service 102-1 simultaneously), depending on the embodiment and / or user configuration. In some embodiments (e.g., in the case of a data historian service), a larger amount of delay (e.g., several cycles) is tolerated when switching to the backup service / host. In general, 1:N redundancy of physical devices providing the same service 102 is possible. Redundancy may be applied to any service 102 and any type of host device, regardless of the function of the service 102 or device within the process control system. In some embodiments, redundant history services, redundant operator panels, and redundant control devices exist within the same process control system. A service host entity in each hosting device may negotiate and transfer the redundancy state for each service 102. An example of a process control system having redundant services is discussed below with reference to FIG.

[0063] In some embodiments, the microservices control architecture 100 provides additional design freedom by allowing a first service 102 (e.g., service 102-1) to encapsulate one or more other services 102 (e.g., services 102-2, 102-3, etc.) of the process control system. For example, the decomposition of the service 102 and / or business needs may require such encapsulation. The encapsulating service 102 may be responsible for providing routing of service messages to and from the encapsulated service(s) 102. In one such embodiment, this is done by instantiating a service message router (e.g., router 112) within the encapsulating service 102. There is no logical limit to the amount of potential recursion allowed for the encapsulating service 102. In some embodiments, the encapsulating service 102 communicates first-class with other services 102 in the process control system (i.e., other services 102 that are not encapsulated or encapsulated within the same encapsulating service 102). An example of a process control system having encapsulated services is discussed below with reference to FIG. 6.

[0064] The microservices control architecture 100 may also provide various security features. For example, one or more entities (e.g., a security service of the service 102 and / or the service message router 110, etc.) may scrutinize the intended service endpoints on the service message bus 108 and the authentication, authorization, privilege level, and / or correctness of the service messages to prevent "bad actors" from interfacing with the process control system via the service message bus 108. Additionally, in some embodiments, the entities (e.g., a security service of the service 102) may log all actions (or all major actions, etc.) taken by all users of the process control system. Additionally, the service 102 may encrypt messages before sending them on the service message bus 108.

[0065] In the microservices control architecture 100 discussed above, control system services such as service 102 may be deployed as self-contained, standalone services. Each service 102 is equipped with the knowledge to communicate with other services 102 to achieve associated control and / or business goals. Future modifications to a given service 102 may be limited to the scope of responsibility of that service 102 and do not affect the concerns of other unrelated services 102. Dependency concerns of services 102 on each other are ignored for service interfaces 104 used between communicating services 102. For example, the dependency of service 102-1 on service 102-2 (and vice versa) is ignored for interfaces 104-1 and 104-2.

[0066] Various examples of services 102 and examples of communication between those services 102 will now be discussed with reference to Figures 3-6. In classical control engineering, input I / O control data is processed through control algorithms, which drive corresponding outputs. As will be seen in the examples below, this can be accomplished using communication between control system services (e.g., services 102) within a single process control system or across multiple process control systems.

[0067] Referring initially to FIG. 3, an exemplary microservices control architecture 120 includes a control service 122-1, an I / O service 122-2, an event management service 122-3, an operator console service 122-4, a configuration service 122-5, an edge gateway service 122-6, an alarm management service 122-7, a diagnostic service 122-8, a remote access service 122-9, and a historian service 122-10. The services 122-1 through 122-10 may be different ones of the services 102 (i.e., containerized services as discussed above) and are coupled to a service message bus 124 (e.g., similar to bus 108) and a service message router 126 (e.g., similar to router 110). Although not shown in FIG. 3, the microservices control architecture 120 may include a service registry similar to the service registry 112.

[0068] The control services 122-1 may, for example, implement classical proportional-integral-derivative (PID) control of a physical process, and the I / O services 122-2 may be used to "read" data from or "write" data to physical devices (e.g., sensors) (e.g., driving valves, or pumps, etc.). The event management services 122-3 may record and / or process responses to various predefined "events" that occur within the process control system. The operator console services 122-4 may provide and / or generate a GUI (e.g., on a display of the user interface device 8) that an operator can use for configuration, runtime monitoring, diagnostics, etc. of the process control system, and may interact with other services to present information on the GUI and / or forward input entered by the operator via the GUI. The configuration services 122-5 may enable a user (e.g., in response to user input via the operator console services 122-4) to create or modify process control algorithms (e.g., add or remove various control services), create or modify operator interfaces, modify set points within the process control system, and / or perform other configuration operations.

[0069] The edge gateway service 122-6 may provide a secure link to external devices and / or systems via a public or private cloud network 128. The alarm management service 122-7 may monitor various parameters (e.g., sensed temperature and / or pressure, etc.) within the process control system and utilize algorithms and / or thresholds to determine when one or more alarms should be triggered. The diagnostic service 122-8 may collect information (e.g., generate and / or collect diagnostic codes) from various devices and / or other services for diagnostic purposes. The historian service 122-9 may store current process control routine configurations, and data associated therewith. The remote access service 122-10 may transfer communications to and from one or more other devices and / or systems via a wireless (e.g., radio frequency) link / network. Thus, for example, the process control system may invoke / utilize containerized services present on the remote system and / or provide any of the containerized services 122-1-122-9 to the remote process control system via a wireless link, via what is essentially a wireless extension of the service message bus 124.

[0070] During operation (e.g., to implement PID control), the control service 122-1 may send a request message for specific I / O data to the I / O service 122-2. The service message router 126 forwards the request message from the control service 122-1 to the I / O service 122-2 via the service message bus 124. The I / O service 122-2 processes the request, which may be, for example, a request to obtain process input data from an external physical asset. The I / O service 122-2 responds to the request message by generating a response message containing the requested data, which the service message router 126 forwards to the control service 122-1 via the service message bus 124. Alternatively, the control service 122-1 may send a subscription request message (e.g., a request for periodic / published I / O data) to the I / O service 122-2 via the service message router 126 and the service message bus 124. In either case, the I / O service 122-2 sends the I / O data via the service message router 126 and the service message bus 124 to the control service 122-1 for consumption.

[0071] Control algorithms executing within control service 122-1 process the I / O inputs and proceed to write to the associated I / O outputs. Control service 122-1 may construct a "write" message to I / O service 122-2 via service message router 126 and service message bus 124. I / O service 122-2 then drives a particular physical output device (e.g., a pump, a valve, etc.) in response to the I / O output.

[0072] Continuing with reference to FIG. 4, the microservices control architecture 130 provides an example of service host redundancy. Specifically, in this example, the microservices control architecture 130 includes a primary controller 132-1 and a backup controller 132-2, which may be physical controller devices (e.g., each device similar to the controller 11 of FIG. 1). Each of the controllers 132-1, 132-2 hosts the same set of services. In particular, the primary controller 132-1 includes a control service 140-1 (e.g., similar to the control service 122-1), an I / O service 140-2 (e.g., similar to the I / O service 122-2), and an event management service 140-3 (e.g., similar to the event management service 122-3), all of which are coupled to a service message router 142 (e.g., similar to the router 110) via a service message bus (e.g., similar to the bus 108). Primary controller 132-1 also includes a service host entity 144 that manages the redundancy lifecycle of services 140-1-140-3. Backup controller 132-2 may include identical or nearly identical software / components, including control service 145-1, I / O service 145-2, event management service 145-3, service message router 147, and service host entity 149. For example, control service 145-1 may be identical to control service 140-1, with both services configured to control the same device or type of device (e.g., valves).

[0073] The primary controller 132-1 and the backup controller 132-2 reside within a larger microservices control architecture 130 and are both communicatively coupled to another service message router 134 via a service message bus 136. The microservices control architecture 130 may also include other services 138 on the service message bus 136.

[0074] During operation, the primary controller 132-1 is initially the active control device and can respond to service messages received on the service message bus 136. In this example, the backup controller 132-2 is a backup control device in a "hot standby" mode. The services of the backup controller 132-2 (i.e., services 145-1, 145-2, 145-3) do not actively respond to service messages, but may receive copies of service messages sent to the controller 132-1. The controller 132-1 monitors the service message bus 136 for a request to switch to the backup controller 132-2. This request may be active (i.e., a particular control system service requests a switch) or passive (e.g., the controller 132-1 monitors for fault conditions via one or more control system services, such as the event management service 140-3).

[0075] Controller 132-1 then sends a message containing information (e.g., an indication) about the redundancy switch request to backup controller 132-2. Backup controller 132-2 acknowledges the switch request and initiates the switch. Controller 132-1 is notified (e.g., by controller 132-2) that controller 132-2 has taken over, causing controller 132-1 (i.e., service host entity 144) to reset its redundancy state.

[0076] The backup controller 132-2 notifies all services it manages (i.e., services 145-1, 145-2, 145-3) of the "takeover" and begins responding to messages intended for the primary controller 132-1. All other devices sending messages to the controller 132-2 may need to tolerate duplicate messages coming from the primary controller 132-1 and the backup controller 132-2 until the negotiation of the active and backup roles is complete.

[0077] In other embodiments, controllers 132-1 and 132-2 (and possibly one or more other similar controllers) provide their respective services in parallel in a load-balanced manner. This provides the bandwidth-related benefits of load balancing, as well as fault tolerance similar to the example above. For example, controller 132-2 can continue to provide its services (145-1, 145-2, 145-3) if controller 132-1 fails, and vice versa.

[0078] 5, a microservices control architecture 150 provides an example of inter-system communication / monitoring. Specifically, in this example, the microservices control architecture 150 includes a first control system 152-1 ("Control System A") and a second control system 152-2 ("Control System B") coupled by a service message bus 154. As mentioned above, the service message bus 154 may be overlaid on any type or types of underlying communication network. Thus, for example, the control system 152-1 may be coupled to the control system 152-2 by a wired network (e.g., HART®, Ethernet, etc.) and / or a wireless network (e.g., WirelessHART®, WiFi, etc.).

[0079] 5, the control system 152-1 includes a control service 160-1 (e.g., similar to the control service 122-1), an I / O service 160-2 (e.g., similar to the I / O service 122-2), an operator console service 160-3 (e.g., similar to the operator console service 122-4), a configuration service 160-4 (e.g., similar to the configuration service 122-5), and an edge gateway service 160-5 (e.g., similar to the edge gateway service 122-6), all of which are coupled to a service message router 162 (e.g., similar to the router 110) via a service message bus (e.g., similar to the bus 108). The edge gateway service 160-5 is further coupled to a public or private cloud 164 external to the process control systems 152-1 and 152-2.

[0080] Also in this example, control system 152-2 includes a control service 165-1 (e.g., similar to control service 122-1), an I / O service 165-2 (e.g., similar to I / O service 122-2), an operator console service 165-3 (e.g., similar to operator console service 122-4), a diagnostic service 165-4 (e.g., similar to diagnostic service 122-8), and a remote access service 165-5 (e.g., similar to remote access service 122-10), all of which are coupled to a service message router 167 (e.g., similar to router 110) via a service message bus (e.g., similar to bus 108).

[0081] During operation, the operator console service 160-3 of the control system 152-1 is configured to monitor and record I / O data from the other control system 152-2. To this end, the operator console service 160-3 may send a subscription request to the I / O service 165-2 of the control system 152-2. The service message router 162 in the control system 152-1 forwards the request message to the service message router 167 of the control system 152-2. The service message router 167 then forwards the subscription request to the I / O service 165-2. In response, the I / O service 165-2 begins issuing periodic updates of the requested I / O values ​​via the service message routers 167, 162 (and the service message bus) that are consumed by the operator console service 160-3 of the control system 152-1 (e.g., presented to the operator via a GUI generated and / or generated by the operator console service 160-3).

[0082] Throughout the life of a given process control system, the corresponding service message router may maintain a record of all available service endpoints and provide addressing semantics to the different systems connected to their respective service message bus. Any new system or service endpoint that appears on the process control system's service message bus may be verified, authenticated for security purposes, and made available to any service endpoint for communication (e.g., on a first-class basis).

[0083] 6, a microservices control architecture 170 provides an example of service encapsulation. In this example, the microservices control architecture 170 includes a control service 172-1 (e.g., similar to control service 122-1), an I / O service 172-2 (e.g., similar to I / O service 122-2), an operator console service 172-3 (e.g., similar to operator console service 122-4), an alarm management service 172-4 (e.g., similar to alarm management service 122-7), an event management service 172-5 (e.g., similar to event management service 122-3), a diagnostic service 172-6 (e.g., similar to event management service 122-7), and a diagnostic service 172-8 (e.g., similar to diagnostic service 122-9). The edge gateway services 172-8 include a service message router 176 (e.g., similar to the router 110) via a service message bus 174 (e.g., similar to the bus 108), a configuration service 172-7 (e.g., similar to the configuration service 122-5), an edge gateway service 172-8 (e.g., similar to the edge gateway service 122-6), and a remote access service 172-9 (e.g., similar to the remote access service 122-10), all of which are coupled to a service message router 176 (e.g., similar to the router 110) via a service message bus 174 (e.g., similar to the bus 108). The edge gateway services 172-8 are further coupled to a public or private cloud 178 external to the process control system.

[0084] In this example, the I / O service 172-2 encapsulates another control service 180-1 and another event management service 180-2. The services 180-1 and 180-2 may be, for example, services 172-1 and 172-5 (respectively), different versions of the services 172-1 and 172-5, or completely different services. Also coupled to the bus 182 is a service message router 184 and a service host entity 186 that manages the redundancy lifecycle of the services 180-1 and 180-2. The I / O service 172-2, the encapsulated services 180-1, 180-2, the service message router 184, and the service host entity 186 may all be hosted or implemented by, for example, a single physical device or multiple physical devices within a process control system.

[0085] In some embodiments, the encapsulated services 180-1, 180-2 are fully addressable, discoverable, and available for communication with the rest of the control system. Additionally, the encapsulated services 180-1, 180-2 may communicate within the control system as first-class services (i.e., on a first-class basis, as discussed above), but all traffic passing to the encapsulated services 180-1 or 180-2 is addressed through the encapsulating service 172-2.

[0086] Modularity, process control capabilities, and / or design freedom can be increased not only by utilizing a microservices control architecture, but also (or instead) by incorporating custom calculation engines that execute control algorithms outside the process control system. The control algorithms may be, for example, ones that the process control system cannot implement itself. FIG. 7 illustrates a conventional configuration 200 in which a control system 202 interfaces with a custom calculation engine 204 via an external interface protocol 206 (e.g., OPC-UA, IEC61850, ModBus / TCP, etc.). The external interface protocol 206 requires a control system interface engine 210 and an external system interface engine 212, which exchange run-time data via a run-time value database 214.

[0087] 7, this conventional configuration 200 includes four independent zones of synchronicity. In the first zone, the control system 202 is configured to process inputs and drive final control elements (field devices) according to a customer-defined control scheduler. In the second zone, independently and periodically, the control system interface engine 210 transfers process control data from the control system 202 for storage in a runtime value database 214, and the control system interface engine 210 transfers process control data from the runtime value database 214 to the control system 202.

[0088] In a third zone, again independently and periodically, the external system interface engine 212 transfers process control data from the custom calculation engine 204 for storage in the runtime values ​​database 214, and the external system interface engine 212 transfers process control data from the runtime values ​​database 214 to the custom calculation engine 204. In a fourth zone, the custom calculation engine 204 algorithmically processes inputs and generates outputs according to a customer-defined control scheduler. Each step introduces latency and asynchronous operation, which can cause a variety of problems during operation that can be difficult to diagnose and / or correct.

[0089] A novel solution to these problems is described with reference to FIGS.

[0090] 8, an example control execution flow 300 utilizes a "shadow block" technique to interface with a container 302 that includes a custom calculation engine 304 that executes a control algorithm. The custom calculation engine 304 may execute any type of control algorithm used, for example, to drive any type of control element (e.g., used to drive any of the field devices 15-22, 40-50). In some embodiments, the custom calculation engine 304 implements a machine learning or AI model (e.g., similar to the machine learning / AI model discussed above with reference to FIG. 2).

[0091] The control execution flow 300 may or may not utilize the microservices control architecture 100 of Figure 2, for example, by the process control system 10 of Figure 1. In the example of Figure 8, the process control system generally controls a physical process using multiple function diagrams 306, each including multiple function blocks 310. Although Figure 8 shows three function diagrams 306, one of which includes four function blocks 310-1 through 310-4, any suitable number of function diagrams 306 and any suitable number of function blocks 310 per diagram 306 may be implemented.

[0092] Each of the function blocks 310-1 through 310-4 (for ease of notation, also referred to herein simply as "function blocks 310") represents a particular control algorithm, or a portion of a control algorithm, supported by the process control system and has one or more configurable inputs and outputs. As used herein, the term "control algorithm" may include operations (e.g., integrating, summing, filtering, etc.) performed on input data to generate output data, or may include other operations necessary to control a physical process, such as obtaining input data from a sensor, outputting data that drives a field device, or interfacing with another component (e.g., as in the case of the shadow block discussed herein). The function blocks 310 and the function block diagram 306 may be arranged, for example, according to the IEC 61131-3 specification.

[0093] The order of execution is defined by the connections between the inputs and outputs of the various function blocks 310. In the example configuration of FIG. 8, for example, the output of function block 310-1 drives / triggers function block 310-2 (i.e., causes function block 310-2 to generate its own output by acting on the output of function block 310-1), the output of function block 310-2 drives / triggers function block 310-3, the output of function block 310-3 drives / triggers function block 310-4, the output of function block 310-4 drives / triggers function block 310-1 in a feedback loop. It is understood that one or more of the function blocks 310 may include additional inputs and / or outputs not shown in FIG. 8 (e.g., inputs from sensor devices to function block 310-1 and / or outputs from function block 310-4 driving field devices, etc.).

[0094] The function blocks 310-1, 310-2, 310-4 implement control algorithms that are executed internally by the process control system (e.g., by the controller 11 of the process control system 10). For example, the function block 310-1 may acquire sensor data, the function block 310-2 may process (e.g., pre-filter) the sensor data, and the function block 310-4 may use the output of the function block 310-3 to drive a field component. However, the function block 310-3 operates as a "shadow block." That is, the function block 310-3 (also referred to herein as "shadow block 310-3") serves as an interface to the container 302. In particular, the shadow block 310-3 forwards its input data 314 (i.e., data output by the function block 310-2) via the container 302 to the custom calculation engine 304, which operates based on the input data 314 to generate the output data 316. The shadow block 310-3 then obtains the output data 316 from the custom calculation engine 304 via the container 302 and applies the output data 316 to the function block 310-4 as its own output data. In other embodiments, the shadow block 310-3 includes some pre-processing and / or post-processing of the data communicated to the custom calculation engine 304.

[0095] Generally, a shadow block, such as shadow block 310-3, represents an algorithm or calculation that is executed outside of the function block diagram (e.g., diagram 306) that contains the shadow block, as an abstraction for the function block diagram. In this manner, shadow blocks allow custom calculations to affect the process control system in a first-class manner. Thus, for example, the custom calculation engine 304 (via shadow block 310-3) executes in the same manner as any function block 310 defined within the function block diagram 306.

[0096] The shadow block 310-3 provides isolation of the custom calculation engine 304 from any software entity of the process control system, except for the interface with the shadow block 310-3 itself. Furthermore, this arrangement forces the custom calculation engine 304 to operate synchronously with respect to the function block diagram 306. In other words, the custom calculation engine 304 executes synchronously through the interface of the shadow block 310-3. This allows for a more deterministic and predictable execution of the function block diagram 306 without having to worry about asynchronous execution of the custom calculation engine 304 and related issues (e.g., sampling rate, aliasing, system noise).

[0097] As mentioned above, the custom compute engine 304 shown in FIG. 8 is containerized (e.g., using an instance of a Docker or LXD image, a Windows container, a BSD or chroot jail, or a virtual machine, etc., as discussed above). In some embodiments, the custom compute engine 304 is implemented as a control system service (e.g., similar to one of the control system services 102 of FIG. 2, but external to the process control system) having a service API as discussed above. In this manner, the shadow block 310-3 may act as an execution interface to the software container. In some embodiments, the custom compute engine 304 is “uploaded” as a securely verified container image for consumption by the control system. The container image may then be immediately available for instantiation following a successful upload operation.

[0098] By using the shadow block interface, the custom calculation engine 304 may be represented, instantiated, and executed in the function block diagram 306. This is advantageous because control system engineering personnel may interact with the custom calculation engine 304 when configuring or monitoring the system without having formal or specialized training. Thus, process alarms, historian interaction, data acquisition, and / or other functionality may occur without the need for specialized custom interfaces.

[0099] The execution time of the shadow block 310-3 naturally depends on the execution time of the custom calculation engine 304 and has a direct and linear impact on the total execution time of the function block diagram 306. Care should be taken to ensure that the custom calculation engine 304 does not have such computational complexity that the function block diagram 306 exceeds the boundaries of acceptable execution times. One way to address this is to reduce or limit the algorithmic complexity of the custom calculation engine 304. Another approach is to configure the custom calculation engine 304 for asynchronous operation. Asynchronous operation allows the custom calculation engine 304 to execute its computational logic in parallel with the function block diagram 306, freeing the execution of the function block diagram 306 from the custom calculation engine 304 (which may take a long time to execute). However, because the custom calculation engine 304 is no longer operating in sync with the function block diagram 306, problems with sampling and aliasing may arise. This may cause the control strategy to operate on stale or invalid data, so care must be taken to ensure that the execution time of the custom calculation engine 304 is taken into account within the control strategy.

[0100] In some embodiments, failures and problems within the custom calculation engine 304 (or associated containerized services) are reflected to the control strategy via the “block status” interface of the shadow block 310-3. Additionally, the shadow block 310-3 may experience what is colloquially known as “mode shedding,” which means that the shadow block 310-3 changes its operating mode to reflect the state of the custom calculation engine 304 or its containerized services. This allows the control strategy to handle failures within the custom calculation engine 304 in a predefined manner appropriate for the process control system.

[0101] Custom computation engines and containers, such as engine 304 and container 302, may be verified by the control system manufacturer or another entity to ensure that the custom computation engines and containers do not negatively impact the execution of the functional block diagrams or associated control strategies. The validation analysis may include, for example, (1) analyzing the computational complexity of the custom control algorithm; (2) analyzing dependencies between the container and the custom compute engine (for static and / or dynamic dependencies); (3) analyzing the worst-case execution times of dynamic compute algorithms that run within the container; (4) analyzing information security to ensure that the container does not record, redirect, or consume data other than that defined within the shadow block interface with the container; (5) analyzing compile-time runtime analysis of the custom compute engine and container instances to ensure that the deployed container image instance of the custom compute engine behaves well during execution (e.g., to prevent a potential third party from injecting malicious logic into the custom compute engine container and exposing the control system to an information security breach); and / or (6) verifying that the custom compute engine container was created, instantiated, signed, and deployed by the manufacturer of the control system or another known entity (e.g., again to prevent a potential third party from injecting malicious logic into the custom compute engine container and exposing the control system to an information security breach).

[0102] 9 depicts a control execution flow 320 that utilizes more specific types of function blocks. In particular, control execution flow 320 includes a function block diagram 322 (e.g., an IEC 61131-3 function block diagram) that includes function blocks 326-1 through 326-4, where function block 326-1 is an analog input function block that acquires analog sensor data and outputs the sensor data (or data indicative of that data), function block 326-2 performs a PID algorithm on the output of function block 326-1 (and set point data fed back from function block 326-4) to generate control and error signals, function block 326-3 is an analog output function block that processes the output of function block 326-2 to drive a field device (e.g., one of field devices 15-22 or 40-50) and provides feedback to function block 326-4, and function block 326-4 is a shadow block that interfaces with a container 330 that includes a custom calculation engine 332 that operates outside of function block diagram 322. The custom calculation engine 332 may, for example, provide functionality not provided by any of the function blocks available for inclusion in the function block diagram 322 .

[0103] Shadow block 326-4 receives output data from both function block 326-1 and function block 326-3 as input and provides it as input data 334 to custom calculation engine 330. In the depicted example, custom calculation engine 332 processes its input data 334 to generate output data 336 representing the current set point and provides the output data 336 to shadow block 326-4. Shadow block 326-4 then uses its output data 336 as its own output, which drives the set point input of PID function block 326-2. In the example depicted in FIG. 9, custom calculation engine 332 is implemented as a containerized service with service API 338 as an interface.

[0104] 8, shadow block 326-4 generally represents custom calculation engine 332 as an abstraction within function block diagram 322 and may enforce synchronous execution for custom calculation engine 332. In some embodiments, shadow block 326-4 allows custom calculation engine 332 to execute in a first-class manner (i.e., like any of function blocks 326-1 through 326-3).

[0105] 10 illustrates a more detailed process control system architecture 350 utilizing shadow blocks, according to one embodiment. The exemplary architecture 350 includes a control subsystem 352 that includes a number of functional block diagrams 354, at least one of which includes one or more shadow blocks 356 (among other functional blocks). The control system 352 also includes a control scheduler 358. The architecture 350 also includes one or more custom compute engines 360 within one or more respective containers 362 (e.g., Docker containers or LXD containers), a container subsystem 370 communicatively coupled to the control subsystem 352, the custom compute engines 360, the containers 362 (via a RESTful API 372), and the containers 362 (via a container API 374). The container subsystem 370 includes one or more container wrapper objects 376 and a synchronous execution queue 378. The control subsystem 352 and the container subsystem 370 communicate with a number of runtime processes 380.

[0106] The container subsystem 370 manages objects 376 that represent containers 362 to the control subsystem 352 (e.g., to system 10 of FIG. 1 or to a portion thereof). The container wrapper objects 376 serve as interface objects to send data to and read data from each of the containers 362. The runtime process 380 may access attribute data specific to a particular container 362 through a namespace (e.g., a Docker namespace) for each instantiated container 362. The namespace may be identical to the identifier of the shadow block 356 associated with the container 362, but scoped to the container subsystem 370.

[0107] As an example, a container definition may be installed on a field gateway (or other suitable device) via a firmware update to install the container 362 and shadow block 356. The container may exist on a file system, for example, as a Docker or LXD package file. To ensure security and integrity, the package file may be verified using an asymmetric key pair signature (e.g., as supported by Docker). If this signature check fails, any downloads attempting to instantiate the associated shadow block 356 may be prevented and an appropriate failure indicator / status may be triggered.

[0108] The custom calculation engine 360 ​​may also be "uploaded" as a securely verified image of the container 362 for consumption by a field gateway or other device. The image of the container 362 may be transmitted to the field gateway or other device via secure file copy or another suitable secure file transfer protocol. The container 362 image may include import data that enables the field gateway (or other device) to instantiate the container 362, handle the download of the associated shadow block 356, register a unique namespace for the custom calculation engine container 362 and associated shadow block 356, and include any runtime database configuration changes necessary to properly consume the new container 362 image for the custom calculation engine 360.

[0109] In some embodiments, the container 362 functions similarly to a batch phase, whereby the container 362 and associated shadow block 356 are instantiated at system runtime upon download of a field gateway or other device. The download script of the container 362 may dictate whether the container 362 executes synchronously with the execution of the shadow block 356 or executes asynchronously (e.g., with a one element deep queue request). If asynchronous execution is selected for the container 362 and the shadow block 356 executes twice (or some other predefined threshold number of times) before the container 362 can finish the custom computation logic for the first execution, an output forwarding failure may occur for that shadow block 356 and a hardware alert will be activated to indicate the delay of the container 362.

[0110] The relationship between shadow blocks 356 and containers 362 may be defined as "stateful" or "stateless." In some embodiments, if the containers 362 of the custom computation engine 360 ​​maintain state during normal execution (i.e., stateful operation), the shadow blocks 356 must maintain a 1:1 cardinality with each container 362. However, if the containers 362 do not maintain state during normal execution (i.e., stateless operation), it is possible for the shadow blocks 356 to have an N:1 cardinality with a single container 362 (image instance). Each shadow block 356, at run time, sends inputs for stateless computation along with associated output transfers. This approach allows for a more efficient design in which the containers 362 do not require a large number of instances for stateless computation.

[0111] Like other function blocks, each shadow block 356 executes in the order defined within its respective function block diagram 354. In one embodiment, the shadow block 356 has three different modes of operation and maintains a block status appropriate to the execution mode, as follows: "Out of Service" mode: Shadow block 356 does not process inputs to shadow block 356 and all outputs are in "bad" status. Configuration logic wired to the output of shadow block 356 treats this output status as an indication that the custom computation engine 360 ​​in the respective container 362 is not running and / or the output should not be trusted. Container subsystem 370 may drive the shadow block mode to "out of service" if the following conditions are true: 1. The containers 362 are no longer reachable via their respective RESTful APIs 372. 2. A container 362 has been deleted or removed as reflected in the respective container API 374. 3. The container 362 requests that the shadow block 356 reflect the “out of service” mode via its respective RESTful API 372. "Manual" mode: The shadow block 356 does not execute the logic of its respective container 362, but allows inputs and outputs to be manually controlled by an operator. This is similar to the "out-of-service" mode discussed above, but output values ​​and status are configurable by the operator. This is useful for debugging or testing control logic downstream of the shadow block 356. "Auto" mode: Shadow block 356 passes input values ​​and status to each container 362 for processing. The output of each custom calculation engine 360 ​​is passed to shadow block 356 along with values ​​and status defined by custom calculation engine 360. This may be considered the "normal" blocking mode for running custom calculation engine 360 ​​through shadow block 356.

[0112] The RESTful API 372 allows the custom calculation engines 360 in the container 362 to specify values ​​and output status for their respective shadow blocks 356. Each shadow block 356 also allows its status to be indicated by the custom calculation engines 360 via their respective RESTful APIs 372.

[0113] The container subsystem 370 acts as a proxy for each actual container 362 object and serves as an interface that interprets data from the container 362 by converting it into data specific to the runtime data's format (e.g., DeltaV™ specific runtime data). In some embodiments, each container wrapper object 376 maintains the following: The shadow block 356 and the control module (functional block diagram) 354 are assigned to an instance of an associated container 362. The namespace of the container 362 may be the same as the name of the shadow block 356 defined in the download script. - The most recently sent (cached) input value and the most recently received output value to and from the associated container 362. - Attribute wrappers and cached data specific to the allocated container 362. - Status and enforcement of assigned licenses for containers 362. In one embodiment, if a license expires, each shadow block 356 transitions to "out of service" mode as defined above, the block status becomes "bad", and all outputs are marked with a "bad" status. Licenses for a particular container 362 with an associated custom computation engine 360 ​​may be, for example, on-demand, subscription-based, or perpetual. -diagnostic data about the assigned container 362, including (1) the total runtime of the container 362 since launch, (2) the maximum runtime of the container 362, (3) whether the container 362 is in synchronous or asynchronous mode, (4) memory usage, (5) custom diagnostic parameters, (6) slippage in asynchronous mode, (7) impact on block status or mode shed, and / or (8) license status.

[0114] The RESTful API 372 enables bidirectional communication between each container 362 and the control subsystem 352, performs custom calculations, and drives execution in coordination with associated shadow blocks 356. The container subsystem 370 may also manage communication with the containers 362 directly. In some embodiments, the RESTful API 372 includes the following interfaces: - Input forwarding: The container 362 consumes input at this interface and initiates the execution of the custom calculation logic. The input value, which may include status, is taken into account by the custom calculation engine 360 ​​of the container 362. - Output forwarding: The container 362 provides the computed output as required by the most recent input forwarding. Value and status may be defined by the custom calculation engine 360. Shadow block mode state: The container 362 can drive each shadow block 356 into any of the supported block modes (eg, as defined above). - Shadow block status: The container 362 may drive the overall status of each shadow block 356 to the status value of any functional block, for example to indicate good status or problems within each custom calculation engine 360.

[0115] In some embodiments and / or scenarios, the signed custom calculation engine 360 ​​can be instantiated on a remote control device and run in normal operation as long as the respective RESTful APIs 372 are capable of communicating over the intervening data network in a reliable manner.

[0116] 11 is a flow diagram depicting an example method 400 of implementing a modular microservices control system architecture. The method 400 may be performed by one or more physical devices of a process control system implementing a physical process, such as the process control system 10 of FIG. 1. For example, the method 400 may be performed by the controller 11 and / or by one or more other physical devices of the process control system 10 (e.g., the operator workstation 8, the server 12, one or more of the field devices 15-22 and / or 40-50, the I / O devices 26 and / or 28, the network device 35, etc.).

[0117] At block 402, containerized control system services are deployed. The control system services are configured to perform different functions associated with a process control system, with each service providing a respective interface (e.g., interface 104) that defines interactivity with other control system services. The containerized services may be, for example, instances of Docker or LXD images, or any other independent self-deployable computational vessel. The services may be deployed, for example, by creating instances of images corresponding to the various services within the physical device(s) that host the respective services. The service types (e.g., control logic services, control execution services, diagnostic services, etc.) may be, for example, any of the service types discussed above in connection with FIGS. 2-6 or any other service types associated with a process control system, and may include encapsulated services and / or redundant services as discussed above.

[0118] At block 404, the physical process is controlled, monitored, and / or analyzed, at least in part, by exchanging messages between the control system services deployed at block 402 via a service message bus (e.g., service message bus 108 of FIG. 2). The exchanged messages conform to the respective interfaces of the control system services. If the interface is an API, for example, the exchanged messages conform to the syntax and parameters of the respective API. The messages may be exchanged using a router, such as, for example, the service message router 110 of FIG. 2. Furthermore, the messages may be exchanged using any suitable type of wired and / or wireless network and associated communication protocol (e.g., HART®, WirelessHART®, WiFi, Bluetooth®, etc.). However, the service-based control protocol of the messages may be independent of the communication protocol of the wired and / or wireless network.

[0119] In some embodiments, the method 400 includes one or more additional blocks not shown in FIG. 11 . For example, the method 400 may include a first additional block in which a registry is maintained by at least one physical device of the process control system. The registry (e.g., the service registry 112) may record each control system service that is added to the process control system. The method may also include a second additional block in which each of the control system services is notified (e.g., by the same physical device) when a new service is added to the registry. Alternatively, the method 400 may include a second additional block in which, for each control system service, the respective physical device that hosts that service notifies all other services that the service is available.

[0120] As another example, the method 400 may include an additional block in which additional messages are exchanged between at least one of the control system services and at least one control system service of another process control system (e.g., via service message routers of both process control systems).

[0121] As another example, the method 400 may further include a block in which a first one of the control system services is migrated from a first physical device to a second physical device of the process control system (e.g., by creating an instance of an image corresponding to the first service on the second physical device).

[0122] 12 is a flow diagram illustrating an example method 500 for incorporating custom calculations in a process control system. The method 500 may be performed by one or more physical devices of a process control system that implements a physical process, such as the process control system 10 of FIG. 1. For example, the method 500 may be performed by the controller 11 and / or by one or more other physical devices of the process control system 10 (e.g., one or more of the field devices 15-22 and / or 40-50, the operator workstation 8, the I / O devices 26 and / or 28, the network device 35, etc.).

[0123] In block 502, a physical process is controlled using a plurality of function blocks (e.g., function blocks arranged in a function block diagram, according to IEC 61131-3). Each of the function blocks has one or more respective inputs and / or one or more respective outputs and implements a respective control algorithm. Block 502 includes, in block 504, executing the function blocks in an order dictated by the arrangement of connections between the inputs and outputs of the different function blocks. The function blocks may include, for example, function blocks similar to function blocks 310 or 326 of FIG. 8 or FIG. 9.

[0124] Block 504 includes executing a shadow block of the plurality of function blocks that provides an interface to at least one input and at least one output of a custom calculation engine that executes external to the plurality of function blocks (i.e., executes external to the function block diagram) at block 506. Executing the shadow block may include enforcing an execution order in which the shadow block does not provide data from an output of the custom calculation engine to a subsequent function block until after the shadow block has provided data from a previous function block to an input of the custom calculation engine.

[0125] In some embodiments, block 506 includes forwarding (e.g., via the container's API) data received at one or more inputs of the shadow block to a container (e.g., an instance of Docker, or an LXD image, etc.) that includes the custom compute engine, and forwarding (e.g., via the container's API) data output from the container by the custom compute engine to one or more outputs of the shadow block. In some embodiments, the shadow block provides a container wrapper object that provides an interface via the container's API and converts the container data into runtime data interpretable by the process control system. The container wrapper object may maintain an assignment of the shadow block to the container, e.g., cached values ​​of data forwarded to and / or from the container, attributes of the container, license status of the container, and / or diagnostic data associated with the container, etc.

[0126] In some embodiments exhibiting N:1 cardinality (as discussed above), block 502 further includes executing one or more additional shadow blocks of the plurality of function blocks, which provide one or more additional, respective interfaces to the inputs and outputs of the custom calculation engine.

[0127] In some embodiments, the method 500 includes one or more additional blocks not shown in Figure 12. For example, prior to block 502, the method 500 may include a first additional block in which an image of the custom calculation engine is obtained from a third party via an internet link, and a second additional block in which an instance of the image is created on a physical device of the process control system (e.g., a physical device that implements some or all of the method 500).

[0128] As another example, method 500 may further include a block in which the status or mode of the shadow block is changed to match / mirror the status or mode of the custom calculation engine (e.g., based on information the custom calculation engine communicates via the RESTful API).

[0129] As yet another example, the method 500 may further include a block in which a status of the shadow block indicates at least one of: (1) whether a custom calculation engine is available, (2) whether the custom calculation engine has been manually overridden, or (3) whether a custom calculation engine is running within the process control system.

[0130] Embodiments of the technology described in this disclosure may include any number of the following aspects, either alone or in combination.

[0131] 1. A method for implementing a modular control system architecture, the method including: deploying a plurality of containerized, independently executable control system services configured to perform different functions associated with a process control system implementing a physical process, each of the plurality of control system services providing a respective interface that defines interactivity with other control system services; and controlling, monitoring, and / or analyzing the physical process, at least in part, by exchanging messages between the plurality of control system services via a service message bus, the exchanged messages conforming to the respective interfaces of the plurality of control system services.

[0132] 2. The method of aspect 1, wherein deploying the plurality of control system services includes deploying each of the plurality of control system services as an instance of a Docker image.

[0133] 3. The method of aspect 1, wherein deploying the plurality of control system services includes deploying each of the plurality of control system services as an instance of an LXD image.

[0134] 4. The method of aspect 1, wherein deploying the plurality of control system services includes deploying each of the plurality of control system services as a Windows container.

[0135] 5. The method of aspect 1, wherein deploying the plurality of control system services includes deploying each of the plurality of control system services as a BSD jail or a chroot jail.

[0136] 6. The method of aspect 1, wherein deploying the plurality of control system services includes deploying each of the plurality of control system services as a virtual machine.

[0137] 7. The method of any one of aspects 1 to 6, comprising implementing a centralized discovery procedure, at least in part, by maintaining a registry that records each control system service added to the process control system by at least one physical device of the process control system, and notifying each of the plurality of control system services by the at least one physical device when a new control system service is added to the registry.

[0138] 8. The method of any one of aspects 1 to 6 comprising, at least in part, for each service of the plurality of control system services, performing a distributed discovery procedure by a respective physical device hosting the service notifying all other services of the plurality of control system services that the service is available.

[0139] 9. The method of any one of aspects 1-8, wherein each service of the plurality of control system services is associated with a different database that includes information specific to the service.

[0140] 10. The method of any one of aspects 1-9, wherein deploying a plurality of control system services includes deploying a database service that provides the other control system services with access to a shared database.

[0141] 11. The method of any one of aspects 1 to 10, wherein exchanging messages between the plurality of control system services via a service message bus includes exchanging messages using a service message router of the process control system.

[0142] 12. The method of any one of aspects 1 to 11, exchanging an additional message between (i) at least one of the plurality of control system services and (ii) at least one control system service deployed in another process control system, wherein exchanging the additional message includes exchanging the additional message using a service message router of the process control system and a service message router of the other process control system.

[0143] 13. The method of aspect 11, wherein deploying the plurality of control system services includes, at least in part, encapsulating a first service of the plurality of control system services within a second service of the plurality of control system services by creating an instance of a service message router within the second service.

[0144] 14. The method of any one of aspects 1-13, wherein the respective interfaces of the plurality of control system services are respective application programming interfaces (APIs), and all interdependencies between the plurality of control system services are ignored for the respective APIs of the plurality of control system services.

[0145] 15. The method of any one of aspects 1-14, wherein the process control system includes a plurality of physical devices, and deploying the plurality of control system services includes, for each service of the plurality of control system services, creating an instance of an image corresponding to the service on a respective one of the plurality of physical devices.

[0146] 16. The method of aspect 15, wherein each physical device hosting one of the plurality of control system services implements a respective service host entity that manages the redundant lifecycle of the control system service hosted by the physical device.

[0147] 17. The method of any one of aspects 1-16, wherein the process control system includes a plurality of physical devices, and the method includes migrating a first service of the plurality of control system services from a first device of the plurality of physical devices to a second device of the plurality of physical devices by creating an instance of an image corresponding to the first service at the second device.

[0148] 18. The method of any one of aspects 1-17, wherein the process control system includes a plurality of physical devices, and deploying the plurality of control system services includes creating, at each of the plurality of physical devices, a plurality of instances corresponding to a first service of the plurality of control system services.

[0149] 19. The method of aspect 18, wherein controlling, monitoring, and / or analyzing the physical process includes collectively implementing the first service in parallel in a load-balanced manner at each device.

[0150] 20. The method of aspect 18, wherein controlling, monitoring and / or analyzing a physical process includes implementing a first service at a first one of the devices and, in response to a failure of the first device, implementing the first service at a second one of the respective devices.

[0151] 21. The method of aspects 1-20, wherein exchanging messages between the plurality of control system services via the service message bus includes exchanging messages over one or more communication networks associated with the one or more respective communication protocols, and the messages conform to a service-based control protocol that is independent of the one or more respective communication protocols.

[0152] 22. The method of aspect 21, wherein the one or more communication networks include a wireless communication network.

[0153] 23. The method of any one of aspects 1-22, wherein the plurality of control system services includes two or more services selected from the group including a control logic service, a control execution service, a control communication service, and a control configuration service.

[0154] 24. The method of aspect 23, wherein the plurality of control system services include one or more services selected from the group consisting of operator console services, alarm management services, event management services, diagnostic services, remote access services, edge gateway services, input / output services and data historian services, external and / or peripheral input / output translation services, key performance assessment services, data monitoring services, machine learning services, artificial intelligence (AI) services, message pass-through services, and safety logic services.

[0155] 25. The method of aspect 23, wherein the plurality of control system services includes a control logic service, and deploying the plurality of control system services includes (i) obtaining an image of the control logic service from a third party via an Internet link, and (ii) creating an instance of the image of the control logic service on a physical device of the process control system.

[0156] 26. A process control system comprising: a plurality of physical devices, including one or more field devices configured to perform physical operations within a physical process implemented by the process control system; and one or more communications networks communicatively coupling at least some of the plurality of physical devices to one another and supporting a service message bus, wherein one or more of the plurality of physical devices collectively host a plurality of containerized, independently executable control system services associated with the process control system and configured to perform different functions, each of the plurality of control system services providing a respective interface that defines interactivity with the other control system services, wherein the process control system controls, monitors, and / or analyzes the physical process by the plurality of control system services exchanging messages via the service message bus and the exchanged messages conforming to the respective interfaces of the plurality of control system services.

[0157] 27. The process control system of aspect 26, wherein each of the plurality of control system services is an instance of a Docker image or an instance of an LXD image.

[0158] 28. The process control system of aspect 26, wherein deploying the plurality of control system services includes deploying each of the plurality of control system services as a Windows container, a BSD jail, a chroot jail, or a virtual machine.

[0159] 29. A process control system as described in aspects 26-28, wherein at least one of the plurality of physical devices hosts a registry that records each control system service added to the process control system, and the at least one device notifies each of the plurality of control system services when a new control system service is added to the registry.

[0160] 30. The process control system of any one of aspects 26 to 28, wherein for each service of the plurality of control system services, a respective device hosting the service notifies all other devices of the plurality of control system services that the service is available.

[0161] 31. A process control system as described in aspects 26 to 30, wherein for each of the plurality of control system services, there is a respective memory associated with a respective device hosting the service, and each memory stores a database containing information specific to the service.

[0162] 32. The process control system according to any one of aspects 26 to 31, wherein the plurality of control system services includes a database service that provides other control system services with access to a shared database.

[0163] 33. A process control system as described in aspects 26 to 32, wherein one of the plurality of physical devices implements a service message router, and the plurality of control system services exchange messages via a service message bus using the service message router.

[0164] 34. The process control system of any one of aspects 26 to 33, wherein each interface of the plurality of control system services is a respective application programming interface (API), and all interdependencies between the plurality of control system services are ignored for each API of the plurality of control system services.

[0165] 35. The process control system of aspects 26-34, wherein each physical device that hosts one of the plurality of control system services implements a respective service host entity that manages the redundancy lifecycle of the control system service hosted by the physical device.

[0166] 36. The process control system of any one of embodiments 26 to 35, wherein the one or more communication networks includes a wireless communication network.

[0167] 37. The process control system according to any one of aspects 26 to 36, wherein the plurality of control system services includes two or more services selected from the group consisting of a control logic service, a control execution service, a control communication service, and a control configuration service.

[0168] 38. The process control system of aspect 37, wherein the plurality of control system services include one or more services selected from the group consisting of an operator console service, an alarm management service, an event management service, a diagnostic service, a remote access service, an edge gateway service, an input / output service, a data historian service, an external and / or peripheral input / output translation service, a key performance assessment service, a data monitoring service, a machine learning service, an artificial intelligence (AI) service, a message pass-through service, and a safety logic service.

[0169] 39. A method for incorporating custom calculations in a process control system, comprising controlling a physical process using a plurality of function blocks, each of the plurality of function blocks (i) having one or more respective inputs and / or one or more respective outputs, and (ii) implementing a respective control algorithm; and controlling the physical process comprises executing the plurality of function blocks in an order specified by an arrangement of connections between inputs and outputs of different function blocks of the plurality of function blocks, and executing the plurality of function blocks comprises executing a shadow block of the plurality of function blocks that provides an interface to at least one input and at least one output of a custom calculation engine executing outside of the plurality of function blocks.

[0170] 40. The method of aspect 39, wherein executing the shadow block includes forwarding data received at one or more inputs of the shadow block to a container that includes the custom calculation engine, and forwarding data output by the custom calculation engine from the container to one or more outputs of the shadow block.

[0171] 41. The method of embodiment 40, wherein the container is an instance of a Docker image, an instance of an LXD image, a Windows container, a BSD jail, a chroot jail, or a virtual machine.

[0172] 42. The method of aspect 40, wherein the shadow block provides an interface to at least one input and at least one output of the customer compute engine via an application programming interface (API) of the container, and wherein forwarding data received at one or more inputs of the shadow block to the container and forwarding data output by the custom compute engine from the container to one or more outputs of the shadow block both include forwarding the data via the container's API.

[0173] 43. The method of embodiment 42, wherein the shadow block provides an interface to at least one input and at least one output of the customer compute engine via (i) a container API and (ii) a container wrapper object that converts the container data into runtime data interpretable by the process control system.

[0174] 44. The method of aspect 43, comprising maintaining, by the container wrapper object, one or more of: an allocation of shadow blocks to the container; cached values ​​of data transferred to and / or from the container; attributes of the container; a license status of the container; and diagnostic data associated with the container.

[0175] 45. The method of any one of aspects 40-44, comprising obtaining an image of the custom calculation engine from a third party via an internet link prior to controlling the physical process, and creating an instance of the image of the custom calculation engine on a physical device of the process control system.

[0176] 46. ​​A method according to any one of aspects 39 to 45, wherein the multiple functional blocks are functional blocks of a functional block diagram defined in the International Electrotechnical Commission (IEC) 61131-3 specification, and the custom calculation engine is implemented outside the functional block diagram.

[0177] 47. A method as described in aspects 39 to 46, wherein at least a first function block of the plurality of function blocks is an input block that reads sensor data generated by a first field device of the process control system, and at least a second function block of the plurality of function blocks is an output block that drives a second field device of the process control system.

[0178] 48. The method of any one of aspects 39-47, wherein executing the shadow block includes enforcing an execution order in which the shadow block does not provide data from at least one output of the custom calculation engine to a subsequent function block of the plurality of function blocks until after the shadow block has provided data from a previous function block of the plurality of function blocks to at least one input of the custom calculation engine.

[0179] 49. The method of any one of aspects 39-48, comprising changing a status or mode of the shadow block to match a status or mode of the custom calculation engine.

[0180] 50. The method of any one of aspects 39 to 49, wherein controlling the physical process includes executing one or more additional shadow blocks of the plurality of function blocks that provide one or more additional respective interfaces to at least one input and at least one output of the custom calculation engine.

[0181] 51. The method of any one of aspects 39-50, comprising maintaining a shadow block status indicating at least one of: (i) whether the custom calculation engine is available, (ii) whether the custom calculation engine has been manually overridden, or (iii) whether the custom calculation engine is operating within the process control system.

[0182] 52. One or more control devices configured to control a physical process of a process control system using a plurality of function blocks, each of the plurality of function blocks (i) having one or more respective inputs and / or one or more respective outputs and (ii) implementing a respective control algorithm, wherein controlling the physical process includes executing the plurality of function blocks in an order specified by an arrangement of connections between inputs and outputs of different function blocks of the plurality of function blocks, and executing the plurality of function blocks includes executing a shadow block of the plurality of function blocks that provides an interface to at least one input and at least one output of a custom calculation engine executing outside of the plurality of function blocks.

[0183] 53. The one or more control devices of aspect 52, wherein executing the shadow block includes forwarding data received at one or more inputs of the shadow block to a container including the custom calculation engine, and forwarding data output by the custom calculation engine from the container to one or more outputs of the shadow block.

[0184] 54. The one or more control devices of aspect 53, wherein the container is an instance of a Docker image or an instance of an LXD image.

[0185] 55. The one or more control devices of aspect 53, wherein the shadow block provides an interface to at least one input and at least one output of the customer compute engine via an application programming interface (API) of the container, and forwarding data received at one or more inputs of the shadow block to the container and forwarding data output by the custom compute engine from the container to one or more outputs of the shadow block both include forwarding data via the API of the container.

[0186] 56. The one or more control devices of aspect 55, wherein the shadow block provides an interface to at least one input and at least one output of the customer compute engine via (i) an API for the container and (ii) a container wrapper object that converts the container data into runtime data interpretable by the process control system.

[0187] 57. One or more control devices according to aspect 56, wherein the container wrapper object maintains one or more of an allocation of shadow blocks to the container, cached values ​​of data transferred to and / or from the container, attributes of the container, a license status of the container, and diagnostic data associated with the container.

[0188] 58. One or more control devices described in any one of aspects 53 to 57, wherein the multiple functional blocks are functional blocks of a functional block diagram defined in the International Electrotechnical Commission (IEC) 61131-3 specification, and the custom calculation engine is implemented outside the functional block diagram by one or more devices other than the one or more control devices.

[0189] 59. One or more control devices described in any one of aspects 52 to 58, wherein at least a first function block of the plurality of function blocks is an input block that reads sensor data generated by a first field device of the process control system, and at least a second function block of the plurality of function blocks is an output block that drives a second field device of the process control system.

[0190] 60. The one or more control devices of any one of aspects 52-59, wherein executing the shadow block includes enforcing an execution order such that the shadow block does not provide data from at least one output of the custom calculation engine to a subsequent function block of the plurality of function blocks until after the shadow block has provided data from a previous function block of the plurality of function blocks to at least one input of the custom calculation engine.

[0191] 61. One or more control devices of any one of aspects 52-60, wherein one of the one or more control devices maintains a shadow block status indicating at least one of: (i) whether a custom calculation engine is available, (ii) whether the custom calculation engine has been manually overridden, and (iii) whether the custom calculation engine is operating within the process control system.

[0192] 62. One or more control devices described in any one of aspects 52 to 61, each of which comprises a respective processor and a respective memory, and each processor executes instructions stored in the respective memory to implement a plurality of functional blocks.

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

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

Claims

1. 1. A method of implementing a modular control system architecture, comprising: deploying a plurality of containerized, independently executable control system services configured to perform different functions associated with a process control system that implements a physical process, each of the plurality of control system services providing a respective interface that defines interactivity with other control system services; controlling, monitoring, and / or analyzing the physical process, at least in part, by exchanging messages between the plurality of control system services via a service message bus, the exchanged messages conforming to the respective interfaces of the plurality of control system services; At least in part, implementing, for each service of the plurality of control system services, by a respective physical device hosting said service, a distributed discovery procedure by notifying all other services of said plurality of control system services that said service is available. method.

2. The method of claim 1 , wherein deploying the control system services includes deploying each of the control system services as an instance of a Docker image.

3. The method of claim 1 , wherein deploying the plurality of control system services comprises deploying each of the plurality of control system services as an instance of an LXD image.

4. The method of claim 1 , wherein deploying the plurality of control system services comprises deploying each of the plurality of control system services as a Windows container.

5. The method of claim 1 , wherein deploying the plurality of control system services comprises deploying each of the plurality of control system services as a BSD jail or a chroot jail.

6. The method of claim 1 , wherein deploying the plurality of control system services comprises deploying each of the plurality of control system services as a virtual machine.

7. At least in part: maintaining a registry that records each control system service that has been added to the process control system by at least one physical device of the process control system; 7. The method of claim 1, further comprising: implementing a centralized discovery procedure by notifying each of the plurality of control system services by the at least one physical device when a new control system service is added to a registry.

8. The method of claim 1 , wherein each service of the plurality of control system services is associated with a different database containing information specific to that service.

9. The method of claim 1 , wherein deploying the plurality of control system services includes deploying a database service that provides other control system services with access to a shared database.

10. The method of claim 1 , wherein exchanging the messages between the plurality of control system services via the service message bus comprises exchanging the messages using a service message router of the process control system.

11. 11. The method of claim 10, further comprising: exchanging an additional message between (i) at least one of the plurality of control system services and (ii) at least one control system service deployed in another process control system, wherein exchanging the additional message includes exchanging the additional message using the service message router of the process control system and a service message router of the other process control system.

12. 11. The method of claim 10, wherein deploying the plurality of control system services includes, at least in part, encapsulating a first service of the plurality of control system services within a second service of the plurality of control system services by creating an instance of the service message router within the second service.

13. 13. The method of claim 1, wherein the respective interfaces of the plurality of control system services are respective application programming interfaces (APIs), and all interdependencies between the plurality of control system services are ignored for the respective APIs of the plurality of control system services.

14. The process control system includes a plurality of physical devices; 14. The method of claim 1, wherein deploying the plurality of control system services comprises, for each service of the plurality of control system services, creating an instance of an image corresponding to the service on a respective one of the plurality of physical devices.

15. 15. The method of claim 14, wherein each physical device hosting one of the plurality of control system services implements a respective service host entity that manages a redundancy lifecycle of the control system service hosted by the physical device.

16. The process control system includes a plurality of physical devices, and the method further comprises:

16. The method of claim 1, comprising migrating a first one of the plurality of control system services from a first one of the plurality of physical devices to a second one of the plurality of physical devices by creating an instance of an image corresponding to the first service on the second device.

17. The process control system includes a plurality of physical devices, and deploying the plurality of control system services includes: The method of claim 1 , further comprising creating a plurality of instances corresponding to a first one of the plurality of control system services on each of the plurality of physical devices.

18. Controlling, monitoring and / or analyzing the physical process includes:

20. The method of claim 17, comprising collectively implementing the first service in parallel in a load-balanced manner by the respective devices.

19. Controlling, monitoring and / or analyzing the physical process includes: implementing the first service on a first one of the respective devices; 20. The method of claim 17, comprising implementing the first service on a second one of the respective devices in response to a failure of the first device.

20. 20. The method of claim 1, wherein exchanging the messages between the plurality of control system services via the service message bus includes exchanging the messages over one or more communication networks associated with one or more respective communication protocols, the messages conforming to a service-based control protocol that is independent of the one or more respective communication protocols.

21. 21. The method of claim 20, wherein the one or more communication networks comprises a wireless communication network.

22. The plurality of control system services include A control logic service; A control execution service; A control communication service; 22. The method of claim 1, further comprising two or more services selected from the group consisting of: a control configuration service;

23. The plurality of control system services include Operator console services; Alarm management services; Event management services; Diagnostic services, Remote access services, Edge Gateway Services and Input / output services; Data historian services and External and / or peripheral input / output translation services; Key performance evaluation services and Data monitoring services, Machine learning services, Artificial intelligence (AI) services, A message pass-through service; 23. The method of claim 22, further comprising one or more services selected from the group consisting of: a secure logic service; and

24. the plurality of control system services includes the control logic service; 23. The method of claim 22, wherein deploying the plurality of control system services comprises: (i) obtaining an image of the control logic services from a third party via an internet link; and (ii) creating an instance of the image of the control logic services on a physical device of the process control system.

25. 1. A process control system comprising: a plurality of physical devices including one or more field devices configured to perform physical operations within a physical process implemented by the process control system; one or more communication networks communicatively coupling at least some of the plurality of physical devices to one another and supporting a service message bus; one or more of the plurality of physical devices collectively host a plurality of containerized, independently executable control system services configured to perform different functions associated with the process control system, each of the plurality of control system services providing a respective interface that defines interactivity with other control system services; the process control system controls, monitors, and / or analyzes the physical process, at least in part, by the plurality of control system services exchanging messages over the service message bus, the exchanged messages conforming to the respective interfaces of the plurality of control system services; for each service of the plurality of control system services, each of the devices hosting the service notifies all other services of the plurality of control system services that the service is available; Process control systems.

26. 26. The process control system of claim 25, wherein each of the plurality of control system services is an instance of a Docker image or an instance of an LXD image.

27. 26. The process control system of claim 25, wherein deploying the plurality of control system services comprises deploying each of the plurality of control system services as a Windows container, a BSD jail, a chroot jail, or a virtual machine.

28. At least one of the plurality of physical devices hosts a registry that records each control system service that has been added to the process control system; 28. The process control system of claim 25, wherein the at least one device notifies each of the plurality of control system services when a new control system service is added to the registry.

29. 29. The process control system of claim 25, further comprising, for each of the plurality of control system services, a respective memory associated with the respective device hosting the service, the respective memory storing a database containing information specific to the service.

30. 30. The process control system of claim 25, wherein the plurality of control system services includes a database service that provides other control system services with access to a shared database.

31. one of the plurality of physical devices implementing a service message router; The process control system of any of claims 25 to 30, wherein the plurality of control system services exchange the messages over the service message bus using the service message router.

32. 32. The process control system of claim 25, wherein the respective interfaces of the plurality of control system services are respective application programming interfaces (APIs), and all interdependencies between the plurality of control system services are ignored for the respective APIs of the plurality of control system services.

33. 33. The process control system of claim 25, wherein each physical device that hosts one of the plurality of control system services implements a respective service host entity that manages the redundancy lifecycle of the control system service hosted by the physical device.

34. 34. The process control system of claim 25, wherein the one or more communications networks includes a wireless communications network.

35. The plurality of control system services include A control logic service; A control execution service; A control communication service; 35. The process control system of any of claims 25 to 34, further comprising two or more services selected from the group consisting of: a control configuration service;

36. The plurality of control system services include Operator console services; Alarm management services; Event management services; Diagnostic services, Remote access services, Edge Gateway Services and Input / output services; Data historian services and External and / or peripheral input / output translation services; Key performance evaluation services and Data monitoring services, Machine learning services, Artificial intelligence (AI) services, A message pass-through service; 36. The process control system of claim 35, further comprising one or more services selected from the group consisting of: a. a safety logic service.

Images