Modular process control systems

Abstract

In one aspect, a microservice control architecture provides a modular, flexible platform for designing, diagnosing, updating, and / or extending a process control system. Each service is containerized to provide portability and isolation from other components of the process control system. In another aspect, a functional block diagram includes "shadow" blocks that act as an interface to an external custom computing engine, enabling the custom computing engine to operate synchronously with respect to other functional blocks of the functional block diagram.

Description

Technical Field

[0001] The present disclosure relates generally to process plants and process control systems and, more particularly, to using containers and / or other technologies to achieve greater modularity and / or other benefits within process control systems. Background Art

[0002] Distributed process control systems, such as those used in chemical, petroleum, industrial or other process plants for manufacturing, refining, converting, generating or producing physical materials or products, typically include one or more process controllers that are communicatively coupled to one or more field devices via an analog, digital or combined analog / digital bus, or via a wireless communication link or network. Field devices may be, for example, valves, valve positioners, switches and transmitters, sensors, etc., that are located within a process control environment and typically perform physical or process control functions, such as opening or closing a valve, or measuring process and / or environmental parameters (e.g., pressure, temperature, etc.) to control one or more processes performed within a process plant or system. Intelligent field devices, such as those that conform 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, also typically located within a plant environment, receives signals indicating process measurements obtained by the field devices and / or other information related to the field devices and executes controller applications that run, for example, different control modules. The control modules make process control decisions based on the information received, generate control signals, and communicate with field devices (such as and The controller coordinates control modules or blocks implemented in a fieldbus (Fieldbus field devices). The control module implemented in the controller sends control signals to the field devices via communication lines or links, thereby controlling the operation of at least a portion of a process plant or system, for example, controlling at least a portion of one or more industrial processes running or executing within the plant or system. I / O devices, also typically located in a factory environment, are typically provided between the controller and one or more field devices to enable communication, for example, by converting electrical signals into digital values ​​and vice versa.

[0003] Information from field devices and controllers is typically made available via a communication 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 management computing devices, which are typically located in a control room or other location away from the harsher field environment of the plant. These hardware devices run applications that, for example, enable an operator to perform functions related to controlling a process and / or operating and monitoring a process plant (e.g., changing settings for process control routines, modifying the operation of control modules within a controller or field device, viewing the current state of a process, viewing alarms generated by field devices and controllers, simulating the operation of a process for the purpose of training personnel or testing process control software, maintaining and updating a configuration database, etc.). The communication network used by the hardware devices, controllers, and field devices may include wired communication paths, wireless communication paths, or a combination of wired and wireless communication paths.

[0004] As an example, the DeltaV sold by Emerson Automation Solutions TM The control system includes multiple applications stored in and executed by different devices located in different locations within the process plant. Configuration applications residing in one or more workstations or computing devices in the back-end environment of the process control system or plant enable users to create or change process control modules and download these process control modules to dedicated distributed controllers via a communication network. Typically, these control modules are composed of interconnected function blocks, which are objects in an object-oriented programming protocol that perform functions within the control scheme based on their inputs and provide outputs to other function blocks within the control scheme. The configuration application can also allow the configuration designer to create or change the operator interface, which is used by the viewing application to display data to the operator and enable the operator to change settings within the process control routine, such as set points. Each dedicated controller, and in some cases, one or more field devices, stores and executes a corresponding controller application, which runs the control modules assigned and downloaded to it to implement the actual process control functions. A viewing application, which may be executed on one or more operator workstations (or on one or more remote computing devices communicatively coupled to the operator workstations and the communication network), receives data from the controller application via the communication network and displays the data to a process control system designer, operator, or other user 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. The data historian application typically stores the current process control routine configuration and data associated therewith.

[0005] Typically, process control systems such as those discussed above are complex and include many software components. Over time, these software components often become highly interdependent, making it impossible to modify these components independently without considering multiple other software components. This difficulty is often compounded by efforts to simplify development in the short term and to address project management and delivery timeliness issues that introduce dependencies on other software components in the long term. As a result, the deployment of new services within traditional control systems is not truly modularized. With the recent move towards distributed control systems, this can be particularly problematic.

[0006] This difficulty in modifying existing software components also makes introducing new functionality into a control system more difficult, as there may be many "solidified" software components with which new control system features or functions must interface. Typically, developers must manually discover all necessary application programming interface (API) hooks, understand their interdependencies, and develop the new control system feature / function as another set of solidified software components. This not only complicates the problem of maintaining software components in the future, but also reduces the overall ability of the control system software to support newer technologies over time.

[0007] Some process control systems require custom calculations / algorithms that cannot be implemented within the control system platform. This is because the ability to run the control algorithm is determined by the support capabilities of the specific control system and the situation configuration of the control strategy. Currently, developers rely on external interface protocols (e.g., Modbus, Modbus / TCP, EtherNet / IP, OPC-UA, IEC 61850, etc.) to manually combine the custom calculation engine that executes such control algorithms. However, using conventional external interface protocols to drive the control system with custom calculations is full of complexity and instability. Although external interface protocols are designed for this purpose, the mechanism for obtaining data (e.g., network, inter-process communication (IPC), etc.) may be unreliable. In addition, when the custom calculation engine processes data and makes the data available for both inlet and outlet data paths, the platform that executes the custom calculation engine may have synchronization issues (e.g., sampling issues, aliasing, etc.). In addition, it is usually more difficult to verify such external interfaces with agencies such as the FDA and EPA. Summary of the Invention

[0008] Disclosed are techniques, systems, devices, components, equipment, and methods for increasing the modularity of process control systems and / or providing other benefits (e.g., increased design flexibility) to facilitate development, modification, troubleshooting, and / or other aspects of such systems. The techniques, systems, devices, components, equipment, and methods can be applied to industrial process control systems, environments, and / or plants, which are interchangeably referred to herein as "industrial control," "process control," or "process" systems, environments, and / or plants. Typically, such systems and plants control one or more processes in a distributed manner that operate to manufacture, refine, convert, generate, or produce a physical material or product.

[0009] In one aspect of the present 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 services framework and communicate via a service message bus. In some embodiments, the service message bus and service message protocol are independent of any underlying communication network protocol.

[0010] Each control system service is associated with its own interface that defines how other control system services can interact with the control service (e.g., send data to and receive data from the control service). 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 existence of any other control system services. For example, a process control system can be decomposed into modular and independently deployable control system services based on subdomains of business capabilities or similar components. As used herein, the term "control system service" can refer to a service that is integrated into the control of a physical process (e.g., a control logic service or a control execution service), or a service that is associated with a physical process in some other way (e.g., a diagnostic service, a data historian service, an operator console service, etc.). Each control system service can be deployed at "runtime" to meet the needs of a customer site, and customization of a particular process control system can be achieved by modifying the combination of control system services deployed on the process control system.

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

[0012] Control system services can share and maintain standard mechanisms for defining and supporting common functionality (i.e., "cross-cutting concerns") that can be applied to all control system service instances. This framework can provide, for example, the ability to develop, test, debug, and deploy control services in a generic manner, and can be extensible to facilitate the implementation of different and 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 control system services may provide access to a central database to other control system services.

[0014] To facilitate the transmission of service messages between multiple services (i.e., "service endpoints"), a process control system may include a service message router that is responsible for forwarding message traffic on a service message bus. The service message router may also be connected to service message routers of other process control systems to connect and forward communications between process control systems on a first-class basis so that communications between process control systems can be consumed with the same importance / priority, etc. as first-class communications initiated and consumed within a single process control system. "First-class" communications and general quality of service will be referenced below. Figure 2 The service message router can also allow messages to be delivered to newly discovered control system services. The discovery of control system services can be centralized or decentralized, depending on the implementation.

[0015] To prevent bad actors from interfacing with the process control system via the service message bus, service endpoints and messages used for the service message bus can be carefully checked for authentication, authorization, privilege levels, and correctness. All major actions taken by system users can be logged. To further enhance security, message traffic can be encrypted by the service endpoint that initiates the message.

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

[0017] By leveraging a modular microservices control architecture, the development, modification, extension, and debugging of process control systems can be greatly simplified. For example, developers can introduce new control system services, or update or troubleshoot existing services, without having to manually discover various API hooks and their interdependencies. This, in turn, makes it more feasible for third parties to develop their own control system services, which can promote a robust service marketplace.

[0018] In addition, the use of containerized services can greatly reduce the impact of certain hardware limitations. For example, for load balancing or other reasons, a control system service can be migrated from one hosting device (e.g., server, field device, etc.) within a process control system to another hosting device. To achieve this, the new hosting device can create an instance / container of the migrated control system service, and the original service instance / container can transfer all state and runtime data to the new service instance / container. The service message bus can allow control system services to communicate regardless of the physical location or type of the service host.

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

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

[0021] In another aspect of the present disclosure, a process control system integrates a custom computing engine that runs control algorithms external to the process control system. As used herein, the term "custom" can broadly refer to anything that is not inherent to the process control system or is not inherent to a specific part of the process control system. For example, a custom control algorithm can be an algorithm that the process control system cannot implement on its own. In this regard, a process control system typically controls a physical process by utilizing function blocks, where each function block represents a specific control algorithm and each function block has configurable inputs and outputs. The order of execution is dictated by the connections between the inputs and outputs of each function block. For example, a function block can be a block of a functional block diagram according to the IEC 61131-3 specification.

[0022] To incorporate an external custom compute engine, the process control system includes a "shadow" functional block (also referred to herein as a "shadow block") that provides an interface to the custom compute engine. In this manner, in some embodiments, the control algorithm of the external engine affects the process control system in a first-class manner, i.e., similar to any other functional block defined within a functional block diagram. In some embodiments, the custom compute engine is containerized (e.g., an instance of a Docker or LXD image, etc.), in which case the shadow block transmits its own inputs to the container and receives outputs from the container for use as its own outputs. In some embodiments, containerization provides isolation of the custom compute engine from any other software entities other than the interface with the shadow block (e.g., via the custom compute engine container's API).

[0023] Furthermore, by using the shadow block interface, custom calculation engines can be represented, instantiated, and executed in a functional block diagram (e.g., as defined in IEC 61131-3). This allows control system engineers to interact with custom calculation engines when configuring or monitoring a system without any formal or specialized training. For example, process alarms, historical library interactions, data acquisition, and the like can occur without the need for specialized custom interfaces. Furthermore, because the shadow block forces the custom calculation engine to actually execute synchronously through the shadow block interface, the functional block diagram executes in a more deterministic and predictable manner. This avoids or at least reduces the likelihood of problems caused by asynchronous execution of the custom calculation engine, such as sampling rate issues, aliasing, system noise, and the like, and facilitates the implementation of the desired execution order. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 is a block diagram of an exemplary process plant or process control system;

[0025] Figure 2 is a block diagram of an exemplary microservice control architecture for a process control system;

[0026] Figure 3 yes Figure 2 A block diagram of a first exemplary implementation of a microservice control architecture;

[0027] Figure 4 yes Figure 2 A block diagram of a second exemplary implementation of a microservice control architecture, wherein the process control system implements service redundancy;

[0028] Figure 5 yes Figure 2 a block diagram of a third exemplary implementation of a microservices control architecture in which a service of one process control system can interact with a service of another process control system;

[0029] Figure 6 yes Figure 2A block diagram of a fourth exemplary implementation of a microservice control architecture, wherein a service of a process control system encapsulates other services of the process control system;

[0030] FIG7 illustrates a prior art configuration for interfacing with a custom computing engine;

[0031] Figure 8 is a block diagram of an exemplary control execution flow for interfacing with a custom compute engine using shaded blocks;

[0032] Figure 9 is a block diagram of an exemplary control execution flow utilizing specific function blocks;

[0033] Figure 10 is a block diagram of an exemplary process control system architecture utilizing shaded blocks;

[0034] Figure 11 is a flow chart of an exemplary method for implementing a modular control system architecture; and

[0035] Figure 12 is a flow chart of an exemplary method for incorporating custom calculations in a process control system.

[0036] Specific implementation method

[0037] Figure 1 is a block diagram of an exemplary process control system 10 that can utilize any one or more of the novel techniques described herein. Generally, the process control system 10 processes signals indicative of process measurements obtained by field devices to implement control routines and generates control signals that are sent to other field devices via wired or wireless process control communication links or networks 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., opens or closes a valve, raises or lowers a temperature, takes a measurement, senses a condition, etc.) to control the physical process. Some types of field devices use I / O devices to communicate with other devices (e.g., controllers).

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

[0039] Whether or not the process control system 10 includes a controller 11, the communication network 80 may include one or more wired and / or wireless communication links and may be implemented using any desired or suitable communication protocol or protocols (e.g., an Ethernet protocol). In some configurations (not shown) that include a controller 11, the controller 11 may be communicatively connected to the wireless gateway 35 using one or more communication networks in addition to the network 80, such as by using a wireless network that supports one or more communication protocols (e.g., Wi-Fi or other IEEE 802.11 compliant wireless local area network (WLAN) protocols, mobile communication protocols (e.g., WiMAX, LTE or other ITU-R compliant protocols), Profibus, Fieldbus, etc.)

[0040] One or more devices of the process control system 10 (possibly including the controller 11) host control system services to implement a batch process or a continuous process using at least some of the field devices 15-22 and 40-46. Figures 2 to 6 Discussing exemplary control system services. In an embodiment, in addition to being communicatively connected to the network 80, the controller 11 is also communicatively connected to at least some of the field devices 15-22 and 40-46 using any desired hardware and software that interface with, for example, standard 4-20 mA devices, I / O cards 26, 28, and / or any intelligent communication protocol (e.g., Fieldbus protocol, protocol, Protocol, etc.). Figure 1 In the example shown, the controller 11, the field devices 15-22, and the input / output cards 26 and 28 are wired devices, while the field devices 40-46 are wireless field devices. Of course, the wired field devices 15-22 and the wireless field devices 40-46 can conform to any other desired standards or protocols (e.g., any wired or wireless protocols), including any standards or protocols developed in the future.

[0041] Figure 1 The process controller 11 in the example of FIG 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)) can store computing machines (e.g., containers) executed by the processor 30 to provide certain control system services, as discussed further below. Although Figure 1 Not shown, but Figure 1Any one or more of the other devices shown (e.g., field devices 15-22 or 40-46, wireless gateway 35, or any of devices 7a, 7b, 7c, 8, or 12 discussed below) may also include memory and processors that enable those devices to similarly host one or more control system services.

[0042] 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 (via communications referred to as links) to implement a process control loop within the process control system 10. A control-based function block typically performs one of the following: an input function (e.g., associated with a transmitter, sensor, or other process parameter measurement device); a control function (e.g., associated with a control routine that performs PID, fuzzy logic, etc. control); 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. Function blocks may be stored in and executed by the controller 11 (this is typically the case when these function blocks are used for standard 4-20mA devices and devices such as some type of intelligent field device of the device or associated with them), stored in and implemented by the field device itself (this can be Fieldbus device) and / or stored in and implemented by other devices of the process control system 10. Figures 8 to 10 as well as Figure 12 The aspects of the invention discussed in further detail below discuss functional blocks.

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

[0044] exist Figure 1 In the wireless field devices 40-46, wireless protocols such as The 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 that are not configured to communicate wirelessly, the wireless field devices 40-46 may utilize a wireless gateway 35 that is connected to the network 80 or to 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 communicative coupling between the wireless devices 40-58, the wired devices 11-29, and / or other nodes or devices of the process control system 10. For example, the wireless gateway 35 may provide communicative coupling by using the network 80 and / or by using one or more other communication networks of the process control system 10.

[0045] 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 taking a measurement of a process parameter. However, the wireless field devices 40-46 are configured to communicate using the wireless protocol of the network 70. Thus, 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.

[0046] In some configurations of the process control system 10, the wireless network 70 also includes non-wireless devices. Figure 1 middle, Figure 1 Field device 48 is a conventional 4-20mA device, while field device 50 is a wired 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 and can also support Fieldbus, Profibus, DeviceNet, etc. In addition, in some configurations, the wireless network 70 may include 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 as an integrated device with the wireless gateway 35. The wireless network 70 may also include one or more routers 58 to forward packets from one wireless device to another wireless device within the wireless communication network 70. Figure 1 In FIG. 8 , wireless devices 40 - 46 and 52 - 58 communicate with each other and with wireless gateway 35 through wireless links 60 of wireless communication network 70 and / or via network 80 .

[0047] exist Figure 1 In the embodiment of the present invention, the process control system 10 includes one or more operator workstations or user interface devices 8 that are communicatively connected to a network 80. Via 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 in or near the process control system 10, and in some cases, at least some of the operator workstations 8 may be remotely located, but still communicatively connected to the process control system 10. The operator workstations 8 may be wired or wireless computing devices.

[0048] In some configurations, the process control system 10 includes one or more other wireless access points 7a that use other wireless protocols (e.g., Wi-Fi or other wireless local area network protocols compliant with IEEE 802.11, mobile communication protocols (e.g., WiMAX (Worldwide Interoperability for Microwave Access), LTE (Long Term Evolution), or other protocols compliant with ITU-R (International Telecommunication Union Radiocommunication Sector)), short wavelength radio communications (e.g., near field communication (NFC), and ), or other wireless communication protocols) to communicate with other devices. Typically, the wireless access point 7a allows a handheld or other portable computing device to communicate over a corresponding wireless process control communication network that is different from the wireless network 70 and supports a different wireless protocol than the wireless network 70. For example, the wireless or portable user interface device 8 may be a mobile workstation or diagnostic test device used by an operator within the process control system 10. In some cases, in addition to the portable computing device, one or more process control devices (e.g., the controller 11, one or more of the field devices 15-22, and / or one or more of the wireless devices 35, 40-58) also communicate using the wireless protocol supported by the access point 7a.

[0049] In some configurations, the process control system 10 includes one or more gateways 7b, 7c (also referred to herein as "edge gateways") to systems external to the process control system 10. Typically, such systems are associated with consumers or providers of information generated or manipulated by the process control system 10. For example, the process control system 10 may include a gateway node 7b to communicatively connect a process plant containing the process control system 10 with another process plant. Additionally or alternatively, the process control system 10 may include a gateway node 7c to maintain a communicative connection between the process control system 10 and external public or private systems, such as a process control system of another provider, a third-party provider of a custom computing engine (e.g., as discussed in further detail below), a laboratory system (e.g., a laboratory information management system or LIMS), an operator rounds database, a material handling system, a maintenance management system, a product inventory control system, a production scheduling system, a weather data system, a shipping and handling system, a packaging system, the Internet, and / or other external systems.

[0050] Note that although Figure 1 A specific arrangement of a specific number of devices (of a specific type) is shown, but this is merely an exemplary and non-limiting embodiment. For example, the process control system 10 may omit the controller 11 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 the 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.), and so on.

[0051] Also, note that Figure 1 The process control system 10 may include a field environment (eg, a "process plant site") and a backend environment (eg, including the server 12) communicatively connected via a communication network 80. Figure 1 As shown, the field environment includes physical components (e.g., process control devices, networks, network elements, etc.) that are located, installed, and interconnected therein to operate during runtime to control the process. 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, located, or otherwise included in the field environment of the plant that includes the process control system 10. Generally speaking, raw materials are received and processed in the field environment of the process control system 10 using the physical components located therein to produce one or more products.

[0052] The backend 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 backend environment may include operator workstations 8, servers 12, and / or functionality that supports the runtime operation of the process control system 10. In some configurations, the various computing devices, databases, and other components and devices included in the backend environment of a plant containing the process control system 10 may be physically located in different physical locations, some of which may be local to the process plant and some of which may be remote.

[0053] Figure 2 is a process control system (e.g. Figure 1 1. Although the microservices control architecture 100 is described below with reference to devices / components of the process control system 100, it should be understood that other systems and / or devices may alternatively implement the architecture 100.

[0054] The exemplary microservice control architecture 100 includes a plurality of control system services 102-1 through 102-N, where N can be any suitable integer (e.g., a few, dozens, hundreds, etc.). Each of the control system services 102-1 through 102-N is associated with a corresponding one of N service interfaces 104-1 through 104-N and a corresponding one of N service databases 106-1 through 106-N. To simplify 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 collectively referred to herein as services 102, service interfaces 104, and service databases 106, respectively.

[0055] Services 102 may include any type of service associated with a process control system. For example, services 102 may include multiple services integrated into the control of a physical process. As an example, services 102-1 and 102-2 may be control logic services, while service 102-3 ( Figure 21, 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 alternatively include a plurality of services associated with the physical process in some other manner, such as monitoring services, diagnostic services, analysis services, and the like. 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 indicator service, a data monitoring service, a messaging service, a security logic service, and / or any other suitable type of service associated with a control system. Some or all of the services 102 may be deployed at runtime to meet 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 on the process control system.

[0056] 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 analytical services that predict future performance and / or problems associated with a control system, and / or services that predict / estimate parameters that cannot be directly measured within the control system (e.g., to provide "soft sensing" of physical parameters), etc. For example, one or more of the services 102 may employ a machine learning model (such as a neural network) that is 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 for creating and / or updating (adjusting) the model implemented by the service 102.

[0057] Each service 102 is "containerized," i.e., instantiated within a container. As used herein, the term "container" refers to any independent and self-deployable computing container, such as an instance of a Docker or LXD image, a Windows container, a BSD jail, a chroot jail, a process, an execution thread, or a virtual machine (e.g., a virtual controller), where each container is independent and can execute independently or in conjunction with other independent containers.

[0058] 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" can refer to a computer network and / or other communication means, such as direct API libraries, inter-process communication, intra-process communication, remote procedure calls, shared memory, etc., and can include or be layered on wired and / or wireless (e.g., radio frequency) networks. In some embodiments, the service message bus 108 can be independent of any underlying communication network protocol. Reference Figure 1 The process control system 10, for example, the service message bus 108 can be independent of the networks described above (e.g., WLAN, WiMAX, LTE, IEEE 802.11 compliant Profibus, Fieldbus, etc.) and operates over the communication network 70 and / or network 80.

[0059] The service message bus 108 and the service message router 110 can 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 can be "first-class" messages that are handled differently from other service messages that are less time-sensitive (e.g., second-class, third-class, etc.). As an example, if the communication bandwidth of the service message bus 108 (e.g., dictated by the bandwidth of an underlying network such as network 70 or 80) is fully utilized, the service message router 110 can decide which messages to send, or which messages to send first, based on the priority corresponding to each message's QoS level. For example, if higher-priority service messages must be sent within the limited available bandwidth, the router 110 can delay or even discard certain message types, such as history repository service messages or diagnostic service messages. A service 102 attempting to send a lower-priority message can compensate for this degradation by using reliable messaging techniques, such as message retransmission, skipping stale messages, or reducing the transmission rate of messages to the communication endpoint service 102.

[0060] Each service 102 can be hosted by any one of a number of different physical devices (e.g., any device with sufficient processor, memory, and communication capabilities). A device can "host" a service, for example, by storing in memory all code and all dependencies required to support the service and executing the stored instructions as needed to implement the service and any related functionality (e.g., discovery-related functionality, as discussed below). In some embodiments, for example, a device hosts a service 102 by storing an instance of an image corresponding to the service 102 (e.g., a Docker or LXD image). Each physical device that hosts one or more services can 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 services hosted by the physical device (e.g., managing state transfer for redundancy switchover and / or considerations regarding service migration, as discussed in further detail below).

[0061] refer to Figure 1 In a process control system 10, 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, the server 12 may host the control configuration services of the services 102, and so on. As another example, different ones of the field devices 15-22 and / or 40-50 and / or other devices in 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.

[0062] Each service interface 104 may be an API that defines how other services 102 may interact with (e.g., send messages to and receive messages from) the corresponding service 102. For example, service interface 104-1 may include an API that enables some or all of services 104-2 through 104-N to exchange messages with service 104-1. Each API of an interface 104 may be associated with, for example, a specific syntax and parameter list that is 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 any other services 102. The flow of data through the container of a given service 102 via the corresponding interface 104 is defined by the message protocol of the service message bus 108. The messages transmitted via the service message bus 108 may be, for example, data or management messages (e.g., heartbeat messages).

[0063] Each service database 106 is a dedicated database that stores information specific to a corresponding one of the services 102 and can be any suitable type of data storage mechanism that uses 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 corresponding dedicated database 106. In some embodiments, for example, at least one of the services 102 provides a centralized database service (e.g., a central database that replaces or supplements one or more of the dedicated databases 106) that can be used by some or all of the other services 102.

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

[0065] To facilitate the transmission of service messages between multiple services 102 via the service message bus 108, the architecture 100 may include a service message router 110 that is 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 a software component. The service message router 110 facilitates fan-out and fan-in messaging, such that one of the services 102 may request that the service message router 110 send a message to one or more other services 102. Furthermore, in some embodiments, the service message router 110 may bundle messages from multiple services 102 (e.g., services 102-1 and 102-2) together and then send the bundled message to a single other service 102 (e.g., to Figure 2 Service 102-3 not shown).

[0066] Despite Figure 2(and some subsequent figures) are shown as an intermediate point / connection between two different parts of the service message bus 108, but the service message router 110 and the service message bus 108 can be arranged according to any suitable network configuration. In various embodiments, for example, the service message router 110 can be arranged as an additional parallel node on the service message bus 108 (e.g., similar to each service 102), the service message router 110 and the services 102 can be arranged as a mesh network, all services 102 can be communicatively coupled to the service message router 110 in a star network configuration, etc. However, the service message bus 108 can be unaware of the network topology (star, mesh, etc.) of any (one or more) underlying communication networks. The service message router 110 can use any appropriate routing technology (e.g., flooding, multiplexing, etc.) that is suitable for the network configuration used.

[0067] refer to Figure 1 In the process control system 10, the service message router 110 can be implemented by any device (e.g., the controller 11, the wireless gateway 35, or the server 12). In some embodiments, the functionality of the service message router 110 is distributed across two or more physical devices (e.g., the controller 11 and the wireless gateway 35). In some embodiments, the service message router 110 can also be connected to other similar service message routers (e.g., via the gateway 7c) to allow messages to be transmitted to and from other control system services (similar to the service 102) hosted by another process control system. In this way, the service message router 110 can connect and forward communications between different process control systems on a first category basis so that communications between process control systems can be consumed with the same importance / priority, etc. as first category communications initiated and consumed within a single process control system. Reference below Figure 5 An example of control system interconnectivity is discussed. In some embodiments (eg, embodiments accessing cloud-based services), the use of external services is limited to services associated with less stringent timing requirements, such as data analysis services.

[0068] In some embodiments and / or scenarios, a third party may develop a service for implementation in a 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 7 c and an Internet link. The 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.

[0069] In some embodiments, the microservices control architecture 100 implements automatic discovery techniques to support initialization, modification, and / or expansion of a collection of services 102. Depending on the embodiment, discovery of services 102 can be centralized or decentralized. Figure 2 1 represents 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 can be implemented / maintained by any physical device in the process control system (e.g., the controller 11 in the process control system 10, the gateway 35, one of the field devices 15-22 or 40-50, etc.). The service registry 112 monitors (and in some embodiments, controls) the presence or absence of each service 102 and notifies each service 102 of any newly installed other services 102. Alternatively, each existing service 102 can query the service registry 112 (e.g., periodically) to learn about the current complete set of services 102 or a specific subset.

[0070] In an alternative embodiment, the process control system employs a decentralized mechanism for discovering control services. 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.

[0071] In some embodiments where multiple service message routers communicate on the same interconnection network (e.g., as discussed below), Figure 4 112), those routers can automatically discover each other and all services connected to the service message routers. For example, each service message router can be responsible for sending a complete list of available services 102 known to the router (e.g., obtained from a service registry such as service registry 112) to any other discovered service message routers.

[0072] In some embodiments, a process control system (e.g., system 10) can relocate various services 102 from one hosting device to another within the process control system. For example, this service "migration" can be performed for load balancing purposes. Conceptually, this can be viewed as moving a single service 102 (e.g., service 102-1) to a new hosting device, or as removing a first service 102 from the process control system and adding a second, identical service 102.

[0073] 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 hosting device in favor of another "target" hosting device. The service message router 110 can 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 migration service 102, and the service 102 transfers all state and runtime data from the original hosting device to the new instantiation of the service 102 at 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 it can terminate the original service 102. It is worth noting that services 102 are not necessarily unique to a particular type of physical device. For example, a particular service 102 can be moved from a physical control device (e.g., one of the field devices 15-22 or 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 services 102 to communicate regardless of the physical location or type of the hosting device.

[0074] In order to maintain redundancy for certain services 102, different physical devices may run redundant versions of the same service 102. Depending on the embodiment and / or user configuration, the redundancy scheme may be a hot standby approach (e.g., where a first physical device is actively providing service 102-1, and a second physical device may provide service 102-1 as a backup in the event of a failure of the first physical device, with no or minimal data loss), or may be a dual-drive mechanism (e.g., where a first and a second physical device simultaneously provide service 102-1). In some cases (e.g., for a data historian service), a larger amount of latency (e.g., several cycles) may be acceptable when switching to a backup service / host. Typically, 1:N redundancy of physical devices providing the same service 102 is possible. Redundancy can be applied to any service 102 and any type of hosting device, regardless of the functionality of the service 102 or the device within the process control system. In some embodiments, redundant historian services, redundant operator panels, and redundant control devices exist in the same process control system. The service host entity within each hosting device may negotiate and transmit the redundancy status of each service 102. Reference below Figure 4 Discuss an example of a process control system with redundant services.

[0075] In some embodiments, the microservice control architecture 100 provides additional design flexibility by enabling 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 a process control system. For example, decomposition of the services 102 and / or business requirements may require such encapsulation. The encapsulation service 102 can be responsible for providing routing of service messages to and from the encapsulation service(s) 102. In one such embodiment, this is accomplished by creating an instance of a service message router (e.g., router 112) within the encapsulation service 102. There is no logical limit on the amount of potential recursion allowed for the encapsulation service 102. In some embodiments, the encapsulation service 102 communicates with other services 102 within the process control system (i.e., other services 102 that are not encapsulated or that are not encapsulated within the same encapsulation service 102) on a first class basis. Figure 6 An example of a process control system with encapsulated services is discussed.

[0076] The microservices control architecture 100 can also provide various security features. For example, one or more entities (e.g., the security service of the service 102 and / or the service message router 110, etc.) can scrutinize service endpoints and service messages used for the service message bus 108 for authentication, authorization, privilege levels, and / or correctness, thereby preventing "bad actors" from interfacing with the process control system via the service message bus 108. Furthermore, in some embodiments, an entity (e.g., the security service of the service 102) can log all actions (or all major actions, etc.) taken by all users of the process control system. Furthermore, the service 102 can encrypt messages before transmission on the service message bus 108.

[0077] Utilizing the microservice control architecture 100 discussed above, control system services such as service 102 can be deployed as self-contained, independent services. Each service 102 is equipped with the knowledge to communicate with other services 102 to achieve associated control and / or business objectives. Future modifications to a given service 102 can be confined to the responsibility of that service 102 and do not affect the focus on other unrelated services 102. The dependency issues of services 102 on each other are marginalized to the service interfaces 104 used between the communicating services 102. For example, the dependency of service 102-1 on service 102-2 (and vice versa) is marginalized to interfaces 104-1 and 104-2.

[0078] Now refer to Figures 3 to 6Various examples of services 102 and communication between these services 102 are discussed. In classic control engineering, input I / O control data is processed by a control algorithm and then drives the corresponding output. As seen in the following examples, this can be achieved using communication between control system services (such as services 102) within a single process control system or across multiple process control systems.

[0079] First reference Figure 3 , the exemplary microservice 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. Services 122-1 through 122-10 can be different services in services 102 (i.e., containerized services as described 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 in Figure 3 Not shown, but the microservices control architecture 120 may include a service registry similar to the service registry 112 .

[0080] The control service 122-1 can implement, for example, classic proportional-integral-derivative (PID) control of a physical process, and the I / O service 122-2 can be used to "read" data from a physical device (e.g., a sensor) or "write" data to a physical device (e.g., actuate a valve or pump, etc.). The event management service 122-3 can record and / or process responses to various predefined "events" that occur within the process control system. The operator console service 122-4 can provide and / or populate 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 interact with other services to present information on the GUI and / or forward input entered by the operator via the GUI. The configuration service 122-5 can (e.g., in response to user input via the operator console service 122-4) enable a user to create or change a process control algorithm (e.g., add or remove various control services), create or change an operator interface, modify set points within the process control system, and / or perform other configuration operations.

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

[0082] In 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 with 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 to the control service 122 - 1 via the service message router 126 and the service message bus 124 for consumption.

[0083] The control algorithm running within the control service 122-1 processes the I / O input and proceeds to write to the associated I / O output. The control service 122-1 can construct a "write" message to the I / O service 122-2 via the service message router 126 and the service message bus 124. The I / O service 122-2 will then drive a specific physical output device (e.g., a pump, valve, etc.) based on the I / O output.

[0084] Next reference Figure 4, the microservice control architecture 130 provides an example of service host redundancy. Specifically, in this example, the microservice control architecture 130 includes a primary controller 132-1 and a backup controller 132-2, which can be physical controller devices (e.g., each similar to Figure 1 11). Each of controllers 132-1, 132-2 hosts the same set of services. Specifically, primary controller 132-1 includes control services 140-1 (e.g., similar to control services 122-1), I / O services 140-2 (e.g., similar to I / O services 122-2), and event management services 140-3 (e.g., similar to event management services 122-3), all of which are coupled to a service message router 142 (e.g., similar to router 110) via a service message bus (e.g., similar to bus 108). Primary controller 132-1 also includes a service host entity 144 that manages the redundant lifecycle of services 140-1 through 140-3. Backup controller 132-2 may include identical or nearly identical software / components, including control services 145-1, I / O services 145-2, event management services 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 , where both services are configured to control the same device or the same type of device (eg, a valve).

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

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

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

[0088] 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 primary controller 132-1. All other devices sending messages to controller 132-2 may need to tolerate duplicate messages from primary controller 132-1 and backup controller 132-2 until the negotiation of the active and backup roles is complete.

[0089] 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 not only provides the bandwidth-related benefits of load balancing, but also provides fault tolerance similar to the above example. For example, if controller 132-1 fails, controller 132-2 can continue to provide its services (145-1, 145-2, 145-3), and vice versa.

[0090] Next reference Figure 5 , the microservice control architecture 150 provides an example of inter-system communication / monitoring. Specifically, in this example, the microservice control architecture 150 includes a first control system 152-1 ("control system A") and a second control system 152-2 ("control system B") coupled via a service message bus 154. As described above, the service message bus 154 can be overlaid on any type or types of underlying communication networks. Thus, for example, the control system 152-1 can communicate with the control system 152-2 via a wired network (e.g., Ethernet, etc.) and / or wireless networks (e.g. WiFi, etc.) is coupled to the control system 152-2.

[0091] exist Figure 5In the example of FIG. 1 , 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.

[0092] Also in this example, the 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).

[0093] In operation, the operator console service 160-3 of the control system 152-1 is configured to monitor and log I / O data from the other control system 152-2. To do so, 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 within 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 publishing periodic updates of the requested I / O values ​​via the service message routers 167, 162 (and the service message bus) for consumption by the operator console service 160-3 of the control system 152-1 (e.g., for presentation to an operator via a GUI generated and / or populated by the operator console service 160-3).

[0094] Throughout the lifecycle of a given process control system, a corresponding service message router can maintain a record of all available service endpoints and provide semantics for addressing different systems connected to the corresponding service message bus. Any new system or service endpoint that appears on the service message bus of the process control system can be authenticated and validated for security and can be used by any service endpoint for communication (e.g., on a first-class basis).

[0095] Next reference Figure 6 , the microservice 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 diagnostic service 122-8), a configuration service 172-7 (e.g., similar to configuration service 122-5), an edge gateway service 172-8 (e.g., similar to edge gateway service 122-6), and a remote access service 172-9 (e.g., similar to remote access service 122-10), all of which are coupled to a service message router 176 (e.g., similar to router 110) via a service message bus 174 (e.g., similar to bus 108). The edge gateway service 172 - 8 is further coupled to a public or private cloud 178 external to the process control system.

[0096] In this example, an I / O service 172-2 encapsulates another control service 180-1 and another event management service 180-2. Services 180-1 and 180-2 can be, for example, services 172-1 and 172-5 (respectively), different versions of services 172-1 and 172-5, or entirely different services. Also coupled to bus 182 is a service message router 184 and a service host entity 186 that manages the redundant lifecycles of 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 can all be hosted or implemented by, for example, a single physical device within a process control system or by multiple physical devices.

[0097] In some embodiments, the encapsulation services 180-1, 180-2 are fully addressable, discoverable, and usable for communication with the rest of the control system. Furthermore, the encapsulation services 180-1, 180-2 can communicate as first-class services within the control system (i.e., on a first-class basis as described above), but all traffic passed to the encapsulation service 180-1 or 180-2 is addressed through the encapsulation service 172-2.

[0098] Modularity, process control capabilities, and / or design flexibility can be increased not only by utilizing a microservices control architecture, but also (or alternatively) by incorporating a custom computation engine that runs a control algorithm external to the process control system. For example, the control algorithm can be an algorithm that the process control system cannot implement on its own. FIG7 illustrates a conventional configuration 200 in which a control system 202 interfaces with a custom computation engine 204 via an external interface protocol 206 (e.g., OPC-UA, IEC 61850, ModBus / TCP, etc.). The external interface protocol 206 requires a control system interface engine 210 and an external system interface engine 212 that exchange runtime data via a runtime value database 214.

[0099] As shown in FIG7 , the conventional configuration 200 includes four independent synchronization regions. In the first region, the control system 202 is configured to process inputs and drive final control elements (field devices) according to a customer-defined control schedule. In the second region, on an independent periodic basis, the control system interface engine 210 transmits process control data from the control system 202 for storage in the runtime value database 214, and the control system interface engine 210 transmits process control data from the runtime value database 214 to the control system 202.

[0100] In the third area, the external system interface engine 212 transmits process control data from the custom calculation engine 204 to the runtime value database 214, again on an independent, periodic basis. The external system interface engine 212 transmits the process control data from the runtime value database 214 to the custom calculation engine 204. In the fourth area, the custom calculation engine 204 algorithmically processes inputs and generates outputs according to a customer-defined control schedule. Each step introduces latency and asynchronous behavior, which can lead to various problems that can be difficult to diagnose and / or remedy during operation.

[0101] Now refer to Figures 8 to 10 Describe novel solutions to these problems.

[0102] First reference Figure 8, the exemplary control execution process 300 utilizes a "shadow block" technique to interface with a container 302 containing a custom computing engine 304 that runs a control algorithm. For example, the custom computing engine 304 can execute any type of control algorithm for driving any type of control element (e.g., for driving any of the field devices 15-22 or 40-50). In some embodiments, the custom computing engine 304 implements a machine learning or AI model (e.g., similar to the above referenced Figure 2 Machine learning / AI models discussed).

[0103] The control execution flow 300 may be performed by Figure 1 The process control system 10 is implemented, for example, with or without Figure 2 In the case of microservice control architecture 100. Figure 8 In the example of FIG, a process control system generally controls a physical process by utilizing a plurality of functional block diagrams 306, each of which includes a plurality of functional blocks 310. Figure 8 Three functional block diagrams 306 are shown, with one of these functional block diagrams 306 containing four functional blocks 310 - 1 through 310 - 4 , although any suitable number of functional block diagrams 306 and any suitable number of functional blocks 310 per diagram 306 may be implemented.

[0104] Each of the function blocks 310-1 to 310-4 (also referred to herein as "function blocks 310" for ease of presentation) represents a specific control algorithm, or portion of a control algorithm, supported by a process control system and having one or more configurable inputs and outputs. As used herein, the term "control algorithm" may include operations performed on input data to generate output data (e.g., integration, addition, filtering, etc.), or may include other operations required to control a physical process, such as obtaining input data from a sensor, outputting data to drive a field device, or interfacing with another component (e.g., as in the case of the shaded blocks discussed herein). For example, the function blocks 310 and the functional block diagram 306 may be arranged according to the IEC 61131-3 specification.

[0105] The order of execution is dictated by the connections between the inputs and outputs of the various function blocks 310. Figure 8 In an example configuration, for example, the output of function block 310-1 drives / triggers function block 310-2 (i.e., by operating on the output of function block 310-1, causing function block 310-2 to generate its own output), 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, and the output of function block 310-4 drives / triggers function block 310-1 in a feedback loop. It will be appreciated that one or more function blocks 310 may include Figure 8 Additional inputs and / or outputs not shown (eg, inputs from sensor devices to function block 310 - 1 , and / or outputs from function block 310 - 4 that drives field devices, etc.) may be provided.

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

[0107] Typically, shaded blocks, such as shaded block 310-3, represent algorithms or calculations that are executed outside of a functional block diagram, as an abstraction of the functional block diagram (e.g., diagram 306) that includes the shaded blocks. In this manner, shaded blocks enable custom calculations to impact the process control system in a first-class manner. Thus, for example, the custom calculation engine 304 (via shaded block 310-3) is executed just like any function block 310 defined within the functional block diagram 306.

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

[0109] As mentioned above, Figure 8The custom compute engine 304 shown in FIG is containerized (e.g., using an instance of a Docker or LXD image, Windows container, BSD or Chroot jail, or virtual machine, etc., as described above). In some embodiments, the custom compute engine 304 is implemented as a control system service with a service API as described above (e.g., similar to Figure 2 102, but external to the process control system). Thus, shadow block 310-3 can serve as an execution interface to a software container. In some embodiments, custom compute engine 304 is "uploaded" as a securely verified container image for consumption by the control system. Following a successful upload operation, the container image can then be immediately available for instantiation.

[0110] By using the shaded block interface, the custom calculation engine 304 can be represented, instantiated, and executed in the functional block diagram 306. This is an advantage because control system engineering personnel can interact with the custom calculation engine 304 when configuring or monitoring the system without any formal or specialized training. Thus, process alarms, historian interactions, data acquisition, and / or other functions can occur without the need for specialized custom interfaces.

[0111] The execution time of shaded block 310-3 is of course dependent on the execution time of custom calculation engine 304 and has a direct and linear impact on the total execution time of functional block diagram 306. Care should be taken to ensure that custom calculation engine 304 does not have a computational complexity that causes functional block diagram 306 to exceed the time limit for acceptable execution. One way to address this problem is to reduce or limit the algorithmic complexity of custom calculation engine 304. Another approach is to configure custom calculation engine 304 for asynchronous operation. Asynchronous operation allows custom calculation engine 304 to execute its computational logic in parallel with functional block diagram 306, thereby releasing the execution of functional block diagram 306 from custom calculation engine 304 (which may take a long time to execute). However, because custom calculation engine 304 no longer operates synchronously with functional block diagram 306, sampling and aliasing problems may occur. This in turn may cause the control strategy to operate on outdated or invalid data, so care must be taken to ensure that the execution time of custom calculation engine 304 is considered within the control strategy.

[0112] In some embodiments, faults and problems within the custom compute engine 304 (or associated containerized service) are reflected to the control strategy through the "block state" of the shadow block 310-3 interface. In addition, the shadow block 310-3 can undergo what is commonly known as "mode shedding," meaning that the shadow block 310-3 changes its operating mode to reflect the state of the custom compute engine 304 or its container service. This allows the control strategy to handle faults within the custom compute engine 304 in a predetermined manner appropriate to the process control system.

[0113] A control system manufacturer or another entity may validate custom computing engines and containers (eg, engine 304 and container 302 ) to ensure that the custom computing engines and containers do not adversely affect the execution of functional block diagrams or associated control strategies. The verification analysis may include, for example, (1) analyzing the computational complexity of the custom control algorithm; (2) analyzing the dependencies of the container and the custom compute engine (for static and / or dynamic dependencies); (3) analyzing the worst-case execution time of the dynamic compute algorithm executed within the container; (4) analyzing information security to ensure that the container does not log, redirect, or consume data other than that defined within the shadow block interface with the container; (5) analyzing compile-time and runtime analysis of the custom compute engine and container instantiations to ensure that the deployed custom compute engine container image instance behaves well during execution (e.g., to prevent potential third parties from inserting malicious logic into the custom compute engine container, thereby exposing the control system to information security vulnerabilities); and / or (6) verifying that the custom compute engine container was created, instantiated, signed, and deployed by the control system manufacturer or another known entity (e.g., again, to prevent potential third parties from inserting malicious logic into the custom compute engine container, thereby exposing the control system to information security vulnerabilities).

[0114] For demonstration purposes, Figure 9 A control execution flow 320 utilizing more specific types of function blocks is shown. Specifically, the control execution flow 320 includes a function block diagram 322 (e.g., an IEC 61131-3 function block diagram) containing function blocks 326-1 through 326-4. Function block 326-1 is an analog input function block that acquires analog sensor data and outputs the sensor data (or data indicative thereof). Function block 326-2 performs a PID algorithm on the output of function block 326-1 (and setpoint data fed back from function block 326-4) to generate a control signal and an error signal. 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. Function block 326-4 is a shaded block that interfaces with a container 332 containing a custom computation engine 332 running externally to the function block diagram 322. Custom computation engine 332 may provide functionality not provided by any functional block included in functional block diagram 322 , for example.

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

[0116] As above combined Figure 8 As described above, shaded block 326-4 may generally represent custom compute engine 332 as an abstraction within functional block diagram 322 and implement synchronous execution on custom compute engine 332. In some embodiments, shaded block 326-4 enables custom compute engine 332 to operate in a first-category manner (i.e., similar to any of functional blocks 326-1 through 326-3).

[0117] Figure 10 A more detailed process control system architecture 350 utilizing shaded blocks is shown, according to one embodiment. The exemplary architecture 350 includes a control subsystem 352, which contains a plurality of functional block diagrams 354, at least one of which includes (among other functional blocks) one or more shaded blocks 356. The control system 352 also includes a control scheduler 358. The architecture 350 also includes one or more custom compute engines 360 in one or more corresponding containers 362 (e.g., Docker or LXD containers), and a container subsystem 370 communicatively coupled to the control subsystem 352, the custom compute engines 360 (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 plurality of runtime processes 380.

[0118] The container subsystem 370 manages objects 376 that are presented to the control subsystem 352 (e.g., Figure 1Containers 362 of the system 10 or a portion of the system 10 are instantiated. Container wrapper objects 376 serve as interface objects for sending data to and getting data from corresponding containers in the containers 362. Runtime processes 380 can access attribute data specific to the container 362 through a namespace (e.g., a Docker namespace) for each instantiated container 362. The namespace can be the same as the identifier of the shadow block 356 associated with the container 362, but targeted at the container subsystem 370.

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

[0120] The custom compute engine 360 ​​can also be "uploaded" as a secure, verified image of a container 362 for consumption by a field gateway or other device. The container 362 image can be sent to the field gateway or other device via a secure file copy or another suitable secure file transfer protocol. The container 362 image can contain 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 the unique namespace of the custom compute engine container 362 and the associated shadow block 356, and include any runtime database configuration changes necessary for the custom compute engine 360 ​​to properly consume the new container 362 image.

[0121] In some embodiments, the function of the container 362 is similar to a batch stage, whereby the container 362 and the associated shadow block 356 will be instantiated into the system runtime when the field gateway or other device is downloaded. The download script of the container 362 can indicate whether the container 362 is executed synchronously or asynchronously with the shadow block 356 (e.g., on a one-element deep queue requirement). If asynchronous execution is selected for the container 362, and the shadow block 356 has been executed twice (or other predefined threshold number of times) before the container 362 is able to complete the custom calculation logic of the first execution, an output transfer failure may occur for the shadow block 356, and a hardware warning will be activated to indicate the slip of the container 362.

[0122] The relationship of shadow blocks 356 to containers 362 can be defined as "stateful" or "stateless". In some embodiments, if the containers 362 of the custom compute engine 360 ​​maintain state during normal execution (i.e., stateful operation), then the shadow blocks 356 must maintain a 1:1 cardinality with the corresponding containers 362. However, if the containers 362 do not maintain state during normal execution (i.e., stateless operation), it is possible to have an N:1 cardinality of shadow blocks 356 to a single container 362 (image instance). Each shadow block 356 will send its input for stateless computation, as well as associated output transmissions, when executed. This approach allows for a more efficient design whereby containers 362 do not require multiple instantiations for stateless operation.

[0123] Like other functional blocks, each shaded block 356 will execute in the order defined within the corresponding functional block diagram 354. In one embodiment, the shaded blocks 356 have three different modes of operation and maintain the block state appropriate to the execution mode, as follows:

[0124] "Out of Service" Mode: Shadow block 356 will not process inputs to shadow block 356, and all outputs will have a "bad" status. Configuration logic wired to the outputs of shadow block 356 interprets this output status as an indication that the custom compute engine 360 ​​within the corresponding container 362 did not execute and / or the output should not be trusted. Container subsystem 370 can drive the shadow block mode to "Out of Service" for the following conditions:

[0125] 1. The container 362 is no longer reachable via the corresponding RESTful API 372 .

[0126] 2. The container 362 has been deleted or removed as reflected in the corresponding container API 374.

[0127] 3. The container 362 has requested the shaded block 356 to reflect the “out of service” mode via the corresponding RESTful API 372 .

[0128] "Manual" mode: A shaded block 356 will not execute the logic of the corresponding container 362, but will allow inputs and outputs to be manually controlled by an operator. This is similar to the "Out of Service" mode discussed above, but the output values ​​and states are configurable by the operator. This is useful for debugging or testing control logic downstream of the shaded block 356.

[0129] "Automatic" mode: Shadow block 356 passes input values ​​and status to corresponding container 362 for processing. The output of the corresponding custom calculation engine 360 ​​will be passed to shadow block 356 along with the value and status defined by the custom calculation engine 360. This can be considered a "normal" block mode for executing a custom calculation engine 360 ​​via shadow block 356.

[0130] The RESTful API 372 enables the custom calculation engine 360 ​​within the container 362 to specify the value and output state of the corresponding shadow block 356. The corresponding shadow block 356 will also allow the state to be specified by the custom calculation engine 360 ​​via the corresponding RESTful API 372.

[0131] The container subsystem 370 acts as a proxy for each actual container 362 object and provides access to the data by converting it into a runtime-specific data format (e.g., into a DeltaV-specific TM 362) to interpret the interface of the data from the container 362. In some embodiments, each container wrapper object 376 maintains the following:

[0132] - The shaded block 356 and control module (functional block diagram) 354 are assigned to an associated container 362 instance. The namespace of the container 362 may be the same as the shaded block 356 name defined within the download script.

[0133] - The most recently sent (cached) input value to the associated container 362 and the most recently received output value from the associated container 362.

[0134] - Property wrappers and cache data specific to the allocated container 362.

[0135] - The assigned license status and implementation of the container 362. In one embodiment, if a license has expired, the corresponding shaded block 356 will transition to "out of service" mode as defined above, the block status will become "bad," and all outputs will be marked as "bad." For example, the license for a particular container 362 with an associated custom compute engine 360 ​​may be on-demand, subscription-based, or perpetual.

[0136] - Diagnostic data about the allocated container 362, including (1) total container 362 execution time since boot, (2) maximum container 362 execution time, (3) whether in synchronous mode or asynchronous mode, (4) memory utilization, (5) custom diagnostic parameters, (6) slips in asynchronous mode, (7) impact on block status and mode shedding, and / or (8) license status.

[0137] The RESTful API 372 allows bidirectional communication between the corresponding container 362 and the control subsystem 352 to perform custom calculations and drive execution in coordination with the associated shadow block 356. The container subsystem 370 can directly manage communication with the container 362. In some embodiments, the RESTful API 372 includes the following interfaces:

[0138] - Input transfer: The container 362 consumes its input using this interface and starts executing custom computation logic. The input value may include state and is considered by the custom computation engine 360 ​​of the container 362.

[0139] Output transport: The container 362 delivers the output of a computation as requested by the most recent input transport. The value and state can be defined by a custom computation engine 360.

[0140] - Shadow block mode state: The container 362 can drive the corresponding shadow block 356 into any supported block mode (eg, as defined above).

[0141] -Shadow Block Status: The container 362 can drive the corresponding shadow block 356 overall status to any functional block status value to, for example, represent a good status or a problem within the corresponding custom compute engine 360 ​​.

[0142] In some embodiments and / or scenarios, a signed custom compute engine 360 ​​may be instantiated on a remote control device and operate with normal behavior as long as the corresponding RESTful API 372 is able to communicate in a reliable manner over an intervening data network.

[0143] Figure 11 A flow chart showing an exemplary method 400 for implementing a modular, microservice control system architecture is shown. The method 400 may be implemented by a process control system (e.g., Figure 1 The method 400 may be performed by one or more physical devices of the process control system 10. For example, the method 400 may be implemented by the controller 11 and / or by one or more other physical devices in 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.).

[0144] At block 402, containerized control system services are deployed. The control system services are configured to perform different functions associated with the process control system, and each service provides a corresponding interface (e.g., interface 104) that defines interactions with other control system services. The containerized services can be, for example, instances of Docker or LXD images, or any other independent and self-deployable computing containers. For example, services can be deployed by creating image instances corresponding to various services within the physical device hosting the corresponding services. The service type (e.g., control logic service, control execution service, diagnostic service, etc.) can be, for example, a combination of the above. Figures 2 to 6 Any of the types of services discussed, or any other types of services related to process control systems, may include encapsulated and / or redundant services as described above.

[0145] At block 404, at least in part, by communicating via a service message bus (e.g., Figure 2 The service message bus 108 of block 402 exchanges messages between the control system services deployed to control, monitor and / or analyze the physical process. The messages exchanged conform to the corresponding interface of the control system service. For example, if the interface is an API, the messages exchanged conform to the syntax and parameters of the corresponding API. For example, a message exchanged can be used such as Figure 2 Furthermore, any suitable type of wired and / or wireless network and associated communication protocols (e.g., WiFi, However, the service-based control protocol of the message can be independent of the communication protocol of the wired and / or wireless network.

[0146] In some embodiments, method 400 includes Figure 11 One or more additional blocks not shown in the method 400. 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 added to the process control system. The method may also include a second additional block in which each control system service (e.g., by the same physical device) is notified when a new service is added to the registry. Alternatively, the method 400 may include an additional block in which, for each control system service, the corresponding physical device hosting the service notifies all other services that the service is available.

[0147] As another example, the method 400 may include additional blocks 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 (eg, via service message routers of both process control systems).

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

[0149] Figure 12 A flow chart illustrating an exemplary method 500 for incorporating custom calculations into a process control system is shown. The method 500 may be implemented by a process control system (e.g., Figure 1The method 500 may be performed by one or more physical devices of the process control system 10. For example, the method 500 may be implemented by the controller 11 and / or by one or more other physical devices in 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.).

[0150] At block 502, a physical process is controlled using a plurality of function blocks (e.g., function blocks arranged in a function block diagram in accordance with IEC 61131-3). Each function block has one or more corresponding inputs and / or one or more corresponding outputs and implements a corresponding control algorithm. Block 502 includes, at 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. For example, the function blocks may include Figure 8 or a similar functional block to functional block 310 or 326 of 9.

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

[0152] In some embodiments, block 506 includes transferring data received at one or more inputs of the shadow block to a container (e.g., an instance of a Docker or LXD image, etc.) that includes the custom compute engine (e.g., via the container's API), and transferring data output by the custom compute engine from the container to one or more outputs of the shadow block (e.g., via the container's API). In some embodiments, the shadow block provides an interface via the container's API and a container wrapper object that converts the container data into runtime data that can be interpreted by the process control system. For example, the container wrapper object can maintain the shadow block's assignment to the container, cached values ​​for data transferred to and / or from the container, properties of the container, the container's permission status, and / or diagnostic data associated with the container.

[0153] In some embodiments exhibiting N:1 cardinality (as described above), block 502 further includes executing one or more additional shaded blocks in the plurality of functional blocks, the one or more additional shaded blocks providing one or more additional corresponding interfaces to the input and output of the custom compute engine.

[0154] In some embodiments, method 500 includes Figure 12For example, prior to block 502, method 500 may include a first additional block in which an image of a custom compute 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 at a physical device of the process control system (e.g., at a physical device implementing some or all of method 500).

[0155] As another example, method 500 may include additional blocks in which a state or mode of the shadow block is changed to match / mirror a state or mode of the custom compute engine (eg, based on information transmitted by the custom compute engine via a RESTful API).

[0156] As yet another example, method 500 may include additional boxes where the status of the shaded block indicates at least one of: (1) whether the custom computing engine is available, (2) whether the custom computing engine is manually overridden, or (3) whether the custom computing engine is operating within the process control system.

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

[0158] 1. A method for implementing a modular control system architecture, the method comprising: deploying a plurality of containerized, independently executable control system services, the plurality of containerized, independently executable control system services being 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 corresponding 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 corresponding interfaces of the plurality of control system services.

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

[0160] 3. The method of clause 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.

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

[0162] 5. The method of clause 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.

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

[0164] 7. The method according to any one of aspects 1 to 6 includes implementing a centralized discovery process at least in part by the following steps: maintaining a registry by at least one physical device of the process control system, wherein the registry records each control system service added to the process control system; and notifying each of the multiple control system services by the at least one physical device when a new control system service is added to the registry.

[0165] 8. The method according to any one of aspects 1 to 6 includes implementing a distributed discovery process at least in part by the following steps: for each service in the multiple control system services, the corresponding physical device hosting the service notifies all other services in the multiple control system services that the service is available.

[0166] 9. A method according to any one of aspects 1 to 8, wherein each of the plurality of control system services is associated with a different database containing information specific to that service.

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

[0168] 11. The method of any one of aspects 1 to 10, wherein exchanging 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.

[0169] 12. The method according to any one of aspects 1 to 11 includes: exchanging additional messages between (i) at least one control system service among the multiple control system services and (ii) at least one control system service deployed in another process control system, wherein exchanging the additional messages includes: using a service message router of the process control system and a service message router of another process control system to exchange the additional messages.

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

[0171] 14. A method according to any one of aspects 1 to 13, wherein the corresponding interfaces of the multiple control system services are corresponding application programming interfaces (APIs), and wherein all interdependencies between the multiple control system services are marginalized to the corresponding APIs of the multiple control system services.

[0172] 15. A method according to any one of aspects 1 to 14, wherein: the process control system includes multiple physical devices; and deploying the multiple control system services includes: for each service in the multiple control system services, creating an instance of an image corresponding to the service at a corresponding one of the multiple physical devices.

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

[0174] 17. A method according to any one of aspects 1 to 16, wherein the process control system includes multiple physical devices, and wherein the method includes: migrating the first service from a first device among the multiple control system services to a second device at least in part by creating an instance of an image corresponding to the first service among the multiple control system services at a second device among the multiple control system services.

[0175] 18. A method according to any one of aspects 1 to 17, wherein the process control system includes multiple physical devices, and wherein deploying the multiple control system services includes: creating multiple instances corresponding to the first service of the multiple control system services at corresponding devices among the multiple physical devices.

[0176] 19. The method of clause 18, wherein controlling, monitoring and / or analyzing the physical process comprises: collectively implementing a first service in parallel by the respective devices in a load-balanced manner.

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

[0178] 21. A method according to any one of aspects 1 to 20, wherein exchanging the messages between the multiple control system services via the service message bus includes: exchanging the messages via one or more communication networks associated with one or more corresponding communication protocols, and wherein the messages conform to a service-based control protocol independent of the one or more corresponding communication protocols.

[0179] 22. The method of clause 21, wherein the one or more communication networks comprises a wireless communication network.

[0180] 23. A method according to any one of aspects 1 to 22, wherein the plurality of control system services comprises 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.

[0181] 24. A method according to aspect 23, wherein the multiple 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; data historian services; external and / or peripheral input / output conversion services; key performance indicator services; data monitoring services; machine learning services; artificial intelligence (AI) services; messaging services; and security logic services.

[0182] 25. A method according to aspect 23, wherein: the multiple control system services include the control logic service; and deploying the multiple control system services includes the following steps: (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 at a physical device of the process control system.

[0183] 26. A process control system comprising: a plurality of physical devices, including one or more field devices, wherein the one or more field devices are configured to perform physical operations within a physical process implemented by the process control system; and one or more communication networks, which communicatively couple at least some of the plurality of physical devices to each other and support a service message bus, wherein one or more of the plurality of physical devices jointly host a plurality of containerized, independently executable control system services, wherein the containerized, independently executable control system services are configured to perform different functions associated with the process control system, each of the plurality of control system services provides a corresponding interface, wherein the corresponding interface defines interactivity with other control system services, and the process control system controls, monitors and / or analyzes the physical process at least in part by exchanging messages between the plurality of control system services via the service message bus, and the exchanged messages conform to the corresponding interfaces of the plurality of control system services.

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

[0185] 28. The process control system of aspect 26, 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 Chrootjail, or a virtual machine.

[0186] 29. A process control system according to any one of aspects 26 to 28, wherein: at least one device among the multiple physical devices hosts a registry, and the registry records each control system service added to the process control system; and when a new control system service is added to the registry, the at least one device notifies each control system service among the multiple control system services.

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

[0188] 31. A process control system according to any one of aspects 26 to 30, comprising: for each of the plurality of control system services, a corresponding memory associated with a corresponding device hosting the service, wherein the corresponding memory stores a database containing information specific to the service.

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

[0190] 33. A process control system according to any one of aspects 26 to 32, wherein: a physical device among the plurality of physical devices implements a service message router; and the plurality of control system services use the service message router to exchange the messages via the service message bus.

[0191] 34. A process control system according to any one of aspects 26 to 33, wherein the corresponding interfaces of the multiple control system services are corresponding application programming interfaces (APIs), and wherein all interdependencies between the multiple control system services are marginalized to the corresponding APIs of the multiple control system services.

[0192] 35. A process control system according to any one of aspects 26 to 34, wherein each physical device that hosts one of the multiple control system services implements a corresponding service host entity, and the corresponding service host entity manages the redundant life cycle of the control system service hosted by the physical device.

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

[0194] 37. A process control system according to any one of aspects 26 to 36, wherein the plurality of control system services comprises two or more services selected from the group consisting of: control logic services; control execution services; control communication services; and control configuration services.

[0195] 38. A process control system according to aspect 37, 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; data historian services; external and / or peripheral input / output conversion services; key performance indicator services; data monitoring services; machine learning services; artificial intelligence (AI) services; messaging services; and security logic services.

[0196] 39. A method for incorporating custom computing into a process control system, the method comprising: using a plurality of function blocks to control a physical process, wherein each of the plurality of function blocks (i) has one or more corresponding inputs and / or one or more corresponding outputs, and (ii) implements a corresponding control algorithm, controlling the physical process comprising: executing the plurality of function blocks in an order dictated by the arrangement of connections between inputs and outputs of different ones of the plurality of function blocks, and executing the plurality of function blocks comprising: executing a shaded block among the plurality of function blocks, the shaded block providing an interface to at least one input and at least one output of a custom computing engine running external to the plurality of function blocks.

[0197] 40. A method according to aspect 39, wherein executing the shadow block includes: transferring data received at one or more inputs of the shadow block to a container including the custom compute engine; and transferring data output by the custom compute engine from the container to one or more outputs of the shadow block.

[0198] 41. The method of clause 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.

[0199] 42. A method according to aspect 40, wherein: the shadow block provides an interface to at least one input and at least one output of the custom computing engine via an application programming interface (API) of the container; and data received at one or more inputs of the shadow block is transferred to the container, and data output by the custom computing engine is transferred from the container to the one or more outputs of the shadow block, both of which include transferring data via the API of the container.

[0200] 43. A method according to aspect 42, wherein the shadow block provides the interface to the at least one input and the at least one output of the custom compute engine via: (i) the API of the container and (ii) a container wrapper object that converts container data into runtime data that can be interpreted by the process control system.

[0201] 44. The method according to aspect 43 includes maintaining, by the container wrapper object, one or more of: the allocation of the shadow block to the container; the cached value of data transmitted to and / or from the container; the properties of the container; the permission status of the container; and diagnostic data associated with the container.

[0202] 45. The method according to any one of aspects 40 to 44 includes performing the following operations before controlling the physical process: obtaining an image of the customized computing engine from a third party via an Internet link; and creating an instance of the image of the customized computing engine at a physical device of the process control system.

[0203] 46. ​​The method of any one of clauses 39 to 45, wherein: the plurality of functional blocks are functional blocks of a functional block diagram specified by the International Electrotechnical Commission (IEC) 61131-3 specification; and the custom computing engine is implemented outside of the functional block diagram.

[0204] 47. A method according to any one of aspects 39 to 46, wherein: at least the first function block among the multiple function blocks is an input block, which obtains sensor data generated by a first field device of the process control system; and at least the second function block among the multiple function blocks is an output block that drives a second field device of the process control system.

[0205] 48. A method according to any one of aspects 39 to 47, wherein executing the shadow block includes implementing an execution order in which the shadow block does not provide data from the at least one output of the custom computing engine to a subsequent functional block among the multiple functional blocks until after the shadow block provides data from the previous functional block among the multiple functional blocks to the at least one input of the custom computing engine.

[0206] 49. A method according to any one of clauses 39 to 48, comprising changing the state or mode of the shadow block to match the state or mode of the custom compute engine.

[0207] 50. A method according to any one of aspects 39 to 49, wherein controlling the physical process includes: executing one or more additional shadow blocks among the multiple functional blocks, and the one or more additional shadow blocks provide one or more additional corresponding interfaces to the at least one input and the at least one output of the custom computing engine.

[0208] 51. The method according to any one of aspects 39 to 50 includes: maintaining a state of the shaded block, the state indicating at least one of the following: (i) whether the custom computing engine is available, (ii) whether the custom computing engine is manually overridden, or (iii) whether the custom computing engine is operating within a process control system.

[0209] 52. One or more control devices configured to: control a physical process of a process control system using a plurality of function blocks, wherein each of the plurality of function blocks (i) has one or more corresponding inputs and / or one or more corresponding outputs, and (ii) implements a corresponding control algorithm, controlling the physical process comprises executing the plurality of function blocks in an order dictated by the arrangement of connections between inputs and outputs of different ones of the plurality of function blocks, and executing the plurality of function blocks comprises executing shaded blocks of the plurality of function blocks, the shaded blocks providing an interface to at least one input and at least one output of a custom computing engine running external to the plurality of function blocks.

[0210] 53. One or more control devices according to aspect 52, wherein executing the shadow block includes: transmitting data received at one or more inputs of the shadow block to a container including the custom computing engine; and transmitting data output by the custom computing engine from the container to one or more outputs of the shadow block.

[0211] 54. One or more control devices according to clause 53, wherein the container is an instance of a Docker image or an instance of an LXD image.

[0212] 55. One or more control devices according to aspect 53, wherein: the shadow block provides an interface to the at least one input and the at least one output of the custom computing engine via an application programming interface (API) of the container; and data received at the one or more inputs of the shadow block is transmitted to the container, and data output by the custom computing engine is transmitted from the container to the one or more outputs of the shadow block, both of which include transmitting data via the API of the container.

[0213] 56. One or more control devices according to aspect 55, wherein the shadow block provides the interface to the at least one input and the at least one output of the custom compute engine via: (i) the API of the container and (ii) a container wrapper object that converts container data into runtime data that can be interpreted by the process control system.

[0214] 57. One or more control devices according to aspect 56, wherein the container wrapper object maintains one or more of: the allocation of the shadow block to the container; the cached value of data transmitted to and / or from the container; properties of the container; the permission status of the container; and diagnostic data related to the container.

[0215] 58. One or more control devices according to any one of aspects 53 to 57, wherein: the multiple functional blocks are functional blocks of the functional block diagram specified by the International Electrotechnical Commission (IEC) 61131-3 specification; and the custom computing engine is outside the functional block diagram and is implemented by one or more devices other than the one or more control devices.

[0216] 59. One or more control devices according to any one of aspects 52 to 58, wherein: at least a first functional block among the multiple functional blocks is an input block, which obtains sensor data generated by a first field device of the process control system; and at least a second functional block among the multiple functional blocks is an output block that drives a second field device of the process control system.

[0217] 60. One or more control devices according to any one of aspects 52 to 59, wherein executing the shadow block includes implementing an execution sequence in which the shadow block does not provide data from the at least one output of the custom computing engine to a subsequent functional block among the multiple functional blocks until after the shadow block provides data from the previous functional block among the multiple functional blocks to at least one input of the custom computing engine.

[0218] 61. One or more control devices according to any one of aspects 52 to 60, wherein one of the one or more control devices maintains a state of the shaded block, the state indicating at least one of the following: (i) whether the custom computing engine is available, (ii) whether the custom computing engine is manually overridden, or (iii) whether the custom computing engine is operating within the process control system.

[0219] 62. One or more control devices according to any one of aspects 52 to 61, wherein the one or more control devices each include a corresponding processor and a corresponding memory, and the corresponding processor executes instructions stored in the corresponding memory to implement the multiple functional blocks.

[0220] 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 on a magnetic disk, a laser disk, a solid-state memory device, a molecular memory storage device, or other storage medium, in RAM or ROM of a computer or processor, etc. Although the exemplary systems disclosed herein are disclosed as comprising software and / or firmware and other components executed on hardware, it should be noted that such systems are merely illustrative and should not be considered restrictive. For example, it is contemplated that any or all of these hardware, software, and firmware components may be embodied exclusively in hardware, exclusively in software, or in any combination of hardware and software. Thus, although the exemplary systems described herein are described as being implemented in software executed on a processor of one or more computer devices, it will be readily understood by those of ordinary skill in the art that the examples provided are not the only way to implement such systems.

[0221] Therefore, although the present invention has been described with reference to specific examples, these examples are only intended to illustrate rather than limit the present invention, and it will be obvious to those skilled in the art that changes, additions or deletions may be made to the disclosed embodiments without departing from the spirit and scope of the present invention.

Claims

1. A method for implementing a modular control system architecture, the method comprising: deploying a plurality of containerized, independently executable control system services, the plurality of containerized, independently executable control system services configured to perform different functions associated with a process control system that implements a physical process in a field environment of a process plant, each control system service in the plurality of control system services providing a respective interface defining interactivity with the 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; and The decentralized discovery process is achieved, at least in part, by the following steps: For each of the plurality of control system services, the corresponding physical device hosting the service notifies all other of the plurality of control system services that the service is available.

2. The method according to claim 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.

3. The method according to claim 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.

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

5. The method according to claim 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.

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

7. The method of claim 1 , comprising implementing a centralized discovery process at least in part by: maintaining, by at least one physical device of the process control system, a registry recording each control system service added to the process control system; and When a new control system service is added to the registry, each of the plurality of control system services is notified by the at least one physical device.

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

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

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

11. The method according to claim 10, comprising: Additional messages are exchanged between (i) at least one control system service among the plurality of control system services and (ii) at least one control system service deployed in another process control system, wherein exchanging the additional messages comprises: using the service message router of the process control system and the service message router of the other process control system to exchange the additional messages.

12. The method according to claim 10, wherein: Deploying the plurality of control system services includes: A first service of the plurality of control system services is encapsulated within a second service of the plurality of control system services at least in part by creating an instance of the service message router within the second service.

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

14. The method of claim 1, wherein: The process control system includes a plurality of physical devices; as well as Deploying the plurality of control system services includes, for each of the plurality of control system services, creating an instance of an image corresponding to the service at a corresponding one of the plurality of physical devices.

15. The method according to claim 14, wherein Each physical device hosting one of the plurality of control system services implements a corresponding service host entity that manages a redundant lifecycle of the control system service hosted by the physical device.

16. The method according to claim 1, wherein The process control system includes a plurality of physical devices, and wherein the method comprises: Migrating a first service from a first device of the plurality of physical devices to a second device of the plurality of control system services is performed at least in part by creating an instance of an image corresponding to the first service at a second device of the plurality of control system services.

17. The method according to claim 1, wherein The process control system includes a plurality of physical devices, and wherein deploying the plurality of control system services includes: A plurality of instances corresponding to a first service of the plurality of control system services are created at respective devices of the plurality of physical devices.

18. The method according to claim 17, wherein: Controlling, monitoring and / or analyzing the physical process includes: The first service is implemented in parallel by the respective devices in a load-balanced manner.

19. The method according to claim 17, wherein Controlling, monitoring and / or analyzing the physical process includes: implementing the first service at a first device of the corresponding device; and In response to a failure of the first device, the first service is implemented at a second device of the corresponding device.

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

21. The method according to claim 20, wherein The one or more communication networks include a wireless communication network.

22. The method according to claim 1, wherein The plurality of control system services include two or more services selected from the group consisting of: Control logic services; Control execution services; Controlling communications services; and Control configuration services.

23. The method according to claim 22, wherein The plurality of control system services include one or more services selected from the group consisting of: Operator console services; Alarm management services; incident management services; diagnostic services; Remote access services; Edge gateway services; Input / output services; Data historian services; external and / or peripheral input / output conversion services; Key Performance Indicator Services; Data monitoring services; Machine learning services; Artificial intelligence (AI) services; messaging services; as well as Security logic services.

24. The method of claim 22, wherein: said plurality of control system services including said control logic service; and Deploying the plurality of control system services includes the steps of: (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 at a physical device of the process control system.

25. 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 in a field environment of a process plant implemented by the process control system; as well as one or more communication networks that communicatively couple at least some of the plurality of physical devices to each other and support a service message bus, wherein One or more of the plurality of physical devices jointly hosts a plurality of containerized, independently executable control system services, the containerized, independently executable control system services being configured to perform different functions associated with the process control system, each of the plurality of control system services providing a respective interface defining interactivity with the other control system services, the process control system controls, monitors, and / or analyzes the physical process at least in part by exchanging messages between the plurality of control system services via the service message bus, the exchanged messages conforming to the respective interfaces of the plurality of control system services, and For each service in the plurality of control system services, the respective device hosting the service notifies all other services in the plurality of control system services that the service is available.

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. The process control system of claim 25, 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 Chrootjail, or a virtual machine.

28. The process control system of claim 25, wherein: at least one device of the plurality of physical devices hosts a registry that records each control system service added to the process control system; as well as 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. The process control system of claim 25, comprising: For each of the plurality of control system services, a respective memory is associated with a respective device hosting the service, wherein the respective memory stores a database containing information specific to the service.

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

31. The process control system of claim 25, wherein: A physical device in the plurality of physical devices implements a service message router; and The plurality of control system services exchange the messages via the service message bus using the service message router.

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 wherein all interdependencies between the plurality of control system services are marginalized to the respective APIs of the plurality of control system services.

33. The process control system of claim 25, wherein: Each physical device hosting one of the plurality of control system services implements a corresponding service host entity that manages a redundant lifecycle of the control system service hosted by the physical device.

34. The process control system of claim 25, wherein: The one or more communication networks include a wireless communication network.

35. The process control system of claim 25, wherein: The plurality of control system services include two or more services selected from the group consisting of: Control logic services; Control execution services; Controlling communications services; and Control configuration services.

36. The process control system of claim 35, wherein: The plurality of control system services include one or more services selected from the group consisting of: Operator console services; Alarm management services; incident management services; diagnostic services; Remote access services; Edge gateway services; Input / output services; Data historian services; external and / or peripheral input / output conversion services; Key Performance Indicator Services; Data monitoring services; Machine learning services; Artificial intelligence (AI) services; messaging services; as well as Security logic services.

Images