System and method for hierarchical organization of software-defined process control systems for industrial process plants

Abstract

To provide a novel architecture for a process control system in an industrial process plant.SOLUTION: A software defined control system comprises: a data cluster that includes a plurality of computing nodes, wherein each of the computing nodes includes a processor executing the instance of an operating system, a memory, and a communication resource coupled to one or more other computing nodes in the data cluster; a first container that is instantiated on a first computing node; and a second container that is instantiated on the first computing node. The second container is a second isolated execution environment executing one or more first services on the first computing node within the instance of the operating system of the first computing node, and is in the first container.SELECTED DRAWING: None

Description

Technical Field

[0001] Cross - Reference to Related Applications This application claims the priority and benefit of U.S. Provisional Patent Application No. 63 / 211,535, titled "Software Defined Process Control System for Industrial Process Plants," filed on June 16, 2021, the entire disclosure of which is incorporated herein by reference.

[0002] This application generally relates to an industrial process control system for an industrial process plant, and more particularly, to an industrial process control system that is a data center of an industrial process plant defined by software.

Background Art

[0003] Current distributed industrial process control systems, such as those used to manufacture, refine, transform, generate, or produce physical materials or products in chemical, petroleum, industrial, or other process plants, typically include one or more process controllers communicably coupled to one or more field devices via a physical layer that may be an analog bus, a digital bus, or an analog / digital composite bus, or via a physical layer that may include one or more wireless communication links or networks. The field devices may be, for example, valves, valve positioners, switches, and transmitters (e.g., temperature, pressure, water level, and flow rate sensors), located within the process environment of an industrial process plant (hereinafter interchangeably referred to as the "field environment" or "plant environment" of the industrial process plant), and generally perform physical process control functions such as opening and closing valves, and measuring process and / or environmental parameters such as flow rate, temperature, or pressure, thereby controlling one or more processes running within the process plant or system. Smart field devices, such as field devices conforming to the well-known FOUNDATION® Fieldbus protocol, may also perform control calculations, warning functions, and other control functions typically implemented within the controller. Process controllers are typically located within the plant environment, but may also be located in a protected backend environment associated with the plant. They receive signals indicating process measurements taken by field devices and / or other information related to field devices, and execute control routines or applications that activate various control modules that make process control decisions, for example, by utilizing various control algorithms. They generate process control signals based on the received information and work in conjunction with control modules or control blocks performed within field devices such as HART® field devices, WirelessHART® field devices, and FOUNDATION® Fieldbus field devices.

[0004] Other types of field devices may include spectroscopic measuring devices that can be used, for example, in specialized chemical and pharmaceutical process plants for quality control and purity verification. Examples of spectroscopic field devices include NIR (near-infrared), UV-VIS (ultraviolet-visible), and Raman spectrometers. Spectroscopic field devices are typically controlled or managed by a controller or device manager that instructs the spectroscopic device on when to collect data, when to transmit the collected data, and so on.

[0005] I / O devices positioned between field devices and controllers enable communication between them. For example, a control module within a process controller sends control signals to various different input / output (I / O) devices, and then transmits these control signals to actual field devices via dedicated communication lines or links (communication physical layer), 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 (e.g., physical processes) operating or performing within the plant or system. In another example, a spectroscopic manager or controller sends commands to various I / O devices, which then transmit commands to a physical spectroscopic device located within the industrial process plant via dedicated communication lines or links. In response to the commands, the spectroscopic device transmits the collected data in the reverse direction via a similar route through the I / O devices to other receiving devices within the manager / controller and / or process control system. Also, I / O devices typically located within a plant environment are generally positioned between a controller and one or more field devices, enabling communication between them, for example, by converting electrical signals to digital values ​​and vice versa. Different I / O devices are provided to support field devices that use different proprietary communication protocols. More specifically, different I / O devices are provided between the controller and each field device that uses a specific communication protocol, so that a first I / O device is used to support HART field devices, a second I / O device is used to support Fieldbus field devices, a third I / O device is used to support Profibus field devices, and so on. Field devices, controllers, and I / O devices are generally referred to as “process control devices” and are generally located, deployed, or installed in the field environment of a process control system or plant.

[0006] Furthermore, information from field devices and their respective controllers is typically made available through the controller, via a data highway or 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 typically located in a control room or other location away from the plant's harsher and / or hazardous field environment, for example, in the backend environment of a process plant. Each of these hardware devices is typically centralized across the process plant or across a portion of the process plant. These hardware devices operate applications that may enable operators to perform functions related to controlling the process and / or operating the process plant, such as changing the settings of process control routines, changing the operation of control modules in controllers or field devices, displaying the current state of the process, displaying alarms generated by field devices and controllers, simulating process operation for the purpose of training personnel or testing process control software, and maintaining and updating configuration databases. Data highways used by hardware devices and process controllers may include wired communication paths, wireless communication paths, or a combination of wired and wireless communication paths, and typically use packet-based communication protocols and non-time-dependent communication protocols such as Ethernet® or IP protocols.

[0007] As an example, the DeltaV(trademark) control system, sold by Emerson Process Management, includes multiple applications stored in different devices located in various locations within a process plant and executed by those different devices. A configuration application residing in one or more workstations or computing devices allows users to create or modify process control modules and download these process control modules to dedicated distributed controllers via a data highway. Typically, these control modules consist of functional blocks that are interconnected and can communicate with each other, and these functional blocks may also be objects in an object-oriented programming protocol, which performs functions within the control scheme based on inputs to the control scheme and provides outputs to other functional blocks within the control scheme. The configuration application may also allow a configuration engineer to create or modify an operator interface used by a browsing application to display data to operators and to allow operators to change settings such as setpoints within process control routines. Each dedicated controller, and optionally one or more field devices, stores and runs their respective controller applications that execute the control modules assigned to and downloaded to them in order to implement the actual process control functions. The viewing application may run on one or more operator workstations (or one or more remote computing devices communicating with the operator workstations and the data highway), receive data from the controller application via the data highway, and display this data to process control system designers, operators, or users using a user interface, providing one of several different views such as the operator's view, the engineer's view, or the technician's view.A data historian application is typically stored and executed on a data historian device that collects and stores some or all of the data provided across the data highway, while a configuration database application may run on a more remote computer attached to the data highway to store the current process control routine configuration and its associated data. Alternatively, the configuration database may reside on the same workstation as the configuration application.

[0008] As distributed industrial process control systems have evolved over time, various hardware, communication, and networking technologies have been developed and added. As a result, current process control systems typically include countless inflexible, hardware-centric devices, such as dedicated operator consoles, configuration stations, dedicated controllers, and I / O cards, to name a few. This multitude of different types of hardware devices within a process control system requires multiple levels of configuration and exposure to users of the underlying system, which usually leads to increased costs for initial engineering work and change management. Furthermore, the installation and expansion of process plants are susceptible to cost overruns and supply chain delays because they rely on dedicated hardware.

[0009] In a more general sense, the information technology (IT) sector suffers from similar problems. Within the IT sector, a recent trend is to abstract the infrastructure layer, including physical hardware requirements, away from user-borne business logic, in order to allow for flexibility in hardware installation. Typically, in IT systems, IT administrators design, direct, or otherwise define the hardware requirements they deem necessary to implement the target user-borne business logic, and then adjust the configuration and utilization of the hardware platform when changes to the business logic are required. [Overview of the project]

[0010] Industrial Software-Defined Process Control Systems (SDCSs) provide a novel architecture for process control systems in industrial process plants, which, in most cases, decouple the software and hardware of the process control system. Generally, the business logic of process control system automation is implemented as a logical abstraction in addition to software and hardware computer resources. The management of these resources for industrial process control can be implemented in a hyperconverged computer system infrastructure environment, in which software-defined (SD) components or elements are managed and distributed by the software-defined process control system using some or all of the technologies described herein. Advantageously, the software-defined process control system dynamically and automatically manages software and hardware resources during the uptime of the software-defined process control system, taking into account the dynamically occurring states of the process control system and the industrial process plant (e.g., responsively and / or predictively), to support the dynamic demands of the business logic of the process control system.

[0011] A software-defined process control system (SDCS) may include a software-defined network layer, a software-defined application layer, and a software-defined storage layer, all supported by a physical layer. The physical layer may or may not be included in the SDCS. Generally, the physical layer includes hardware interfaces (e.g., one or more network interfaces or ports) to which the SDCS communicates with the field environment of an industrial process plant and the physical devices or components located therein. For example, the hardware interfaces may include input / output (I / O) interfaces. The physical layer may also include routing components, which may be implemented via software and / or hardware to route data to and from specific interface ports. In some embodiments, the SDCS includes a physical layer, while in other embodiments, the SDCS excludes a physical layer and communicates with a separate set of computing devices or computing platform that provides the physical layer.

[0012] The software-defined network layer of SDCS includes a computing platform comprising one or more data computing clusters, which operate at least partially, if not fully, over the internet. Each cluster may include one or more nodes, at least partially networked with each other via their respective networking resources, and each node may include its own set of processors and / or processor core resources and memory resources. For example, a node may be implemented on a computing device or server. A computing device or server may include multiple processors, and a processor may include multiple cores.

[0013] In the SD network layer, the software-defined operating system monitors and manages the creation of software-defined application layer components, as well as the utilization or use of available application layer components (both individually and collectively) on computing platform nodes, including potentially dynamically changing hardware and software resources, during SDCS startup and uptime. For example, the SD operating system assigns application layer components to run on specific nodes of the computing platform and / or to utilize specific processor resources, processing core resources, and / or memory resources of those nodes. Generally, the SD operating system in the SD network layer, in conjunction with monitoring and managing node hardware and software resources to support software-defined application layer components, provides support services (some of which are consumed by the SD application layer components) for distributing, allocating, reallocating, reallocating, and load balancing SD application layer components to and from various nodes (and potentially various processing and / or memory resources on specific nodes) and between these nodes, according to process control system business logic, timing, and performance requirements. Furthermore, the software-defined network layer connects and manages the networking or distribution of data between software-defined application layer components and their respective endpoints (which may be other software-defined application layer components, devices located in the process plant field environment, user interface devices, external systems, etc.).

[0014] The software-defined application layer contains the business logic of the process control system, which is typically implemented via a container, virtual machine, or other suitable encapsulated execution environment. For example, the process control system business logic may be implemented as a set of application layer services, each application layer service may be configured for a specific set of business logic, and each instance of a configured service may run in a separate encapsulated execution environment. For example, SDCS application layer services may include, to name a few, process control controllers, user interfaces, diagnostics, analytics, I / O networks, and historians. SD application layer services may consist of control routines, tags, device identifiers, device signal identifiers, parameters, values, etc., forming configured instances of services, each of which may run in its own encapsulated execution environment (e.g., a configured container, virtual machine, etc.). The configured encapsulated execution environments are allocated or distributed by the SD network layer (and possibly reassigned or redistributed based on dynamically occurring states within the industrial process plant) and run on the software and / or hardware resources of each node of the computing platform.

[0015] The software-defined storage layer includes process control system data storage that can be utilized by the software-defined application layer. Similar to the software-defined application layer, the software-defined storage layer provides logical storage entities or locations used by applications in the SD application layer, which are allocated and / or distributed (and potentially reallocated and / or redistributed) to various resources on the nodes of the computing platform by the SD network layer. Furthermore, the SD network layer may provide redundancy for various logical storage entities as needed.

[0016] Methods and systems for controlling industrial process control plants utilize SDCS application layer services to facilitate process control using software-defined controllers, software-defined input / output resources, software-defined storage, and / or software-defined networking. The SDCS application layer includes one or more containers running one or more services. An orchestrator operates as part of a hyperconverged infrastructure, controlling the instantiation of one or more containers and facilitating load balancing and fault tolerance by replicating and / or moving (e.g., re-instantiating) containers across different hardware resources. For example, to ensure all services are functioning correctly, individual containers running each service may be moved between hardware resources as hardware resources (e.g., processors, processor cores, memory devices, network capacity) are loaded. As another example, multiple copies of a particular container (i.e., multiple copies of a service that serves a particular part of a process plant) may be instantiated on different hardware resources so that if a single copy of the container becomes unstable or unavailable, or if a hardware resource fails, control can be transferred to another copy of the container with no time required to ensure continuous control of the process (or, for example, as little as milliseconds). Services implemented in this manner and controlled by the orchestrator may include I / O server services, controller services, historians, subsystems (e.g., batch control, continuous control, event control, alarm subsystem, diagnostic subsystem, etc.), network services (e.g., software firewall), and any other containerized services within SDCS. Hardware resources that can implement hardware diversity between identical containers include data clusters, power supplies, server nodes, processors, processor cores, memory devices, etc., and can be dynamically added or removed as needed or requested.

[0017] Another aspect of the system currently described involves nested computing containers operating within the SDCS. Each container instantiated on a computing node is an isolated execution environment running within the computing node's operating system, but a given container may be instantiated within another container and / or may have one or more containers that are internally instantiated. Thus, for example, it is possible to replicate the physical or logical hierarchy within a process plant, thereby replicating the physical and logical configuration of elements within the process plant in the SDCS setup. For example, plant areas, units within areas, and process modules within units can be replicated in nested containers within the SDCS.

[0018] Furthermore, in the SDCS described herein, containers may be anchored to other elements of the process control environment. By anchoring containers to another element of the process control system or plant, configuration engineers or operators can ensure that certain parameters are met, even though the orchestrator enjoys some degree of autonomy. For example, containers may be anchored to computing resources, storage resources, network resources, and power resources, etc., to ensure that certain aspects of fault tolerance are maintained, even if containers are "moved" for load balancing purposes (e.g., a container may be moved between computing resources coupled to a power supply, but may remain on a computing resource coupled to a particular power supply). Containers may also be anchored to other containers or groups of containers (so that they are moved / instantiated together), regardless of nesting, or to the hardware of the process control plant itself (e.g., this associates a particular controller container with a particular unit of process control hardware).

[0019] In exemplary operation, the SDCS I / O Server service interfaces with multiple containerized controller services, each implementing the same control routines to control the same part of the same plant. The I / O Server service may provide the same controller inputs to each of the containerized controller services (e.g., controller outputs representing measurements taken by field devices and sent by the field devices to the I / O Server service). Each containerized controller service executes the same control routines to generate a set of controller outputs. The I / O Server service receives each set of controller outputs and forwards the "active" set of controller outputs to the appropriate field devices. Sets of outputs from other controller services may not be sent to field devices. Other services in the system, such as the I / O Server service and orchestrator services, continuously evaluate the performance and resource utilization of the control system and may dynamically activate and deactivate controller services as needed to optimize performance. The I / O Server service may be containerized as needed. Furthermore, there may be two or more instances of the same containerized I / O Server service. In this implementation, one of these instances is considered "active" and acts as a fully functional intermediary for I / O traffic between the field device and the containerized controller service. An "inactive" I / O server service may receive the same I / O traffic as an "active" I / O server service and implement the same logic for that I / O traffic. However, if necessary, an "inactive" I / O server service may not forward the I / O traffic, or if it does, it may not be received and processed by the target service or device (for example, a network switch may receive the traffic, determine it to be "inactive" I / O traffic, and therefore not forward it to the target).

[0020] Containerized controller services and containerized I / O server services can be distributed in any desired manner across physical resources in a plant or other location. Furthermore, if necessary, one or more of the implemented containers are not permanently tied or fixed to any particular computer cluster or node / server they happen to be running on at any given time. Containers can be dynamically instantiated, deleted, and re-instantiated on different computers as needed (e.g., during or near real-time) to balance computing and network loads and mitigate computing or networking inefficiencies (e.g., when a given physical resource becomes excessively burdened by computing or network traffic). Furthermore, the total number of instances of a given container can be dynamically increased or decreased as needed, and any one of these instances (e.g., each implementing the same controller service) can be activated or deactivated as needed. This "juggling" between containers can be useful when the computing and networking workloads of physical resources fluctuate significantly. Each controller service can be containerized in a dedicated container, thereby providing a relatively isolated, consistent, and predictable environment in which each controller service is implemented, regardless of the broader software environment present on the node implementing the container. For example, a container may include the software dependencies and libraries required for a given controller service. Without containers, ensuring a consistent environment for a controller service might require properly configuring all nodes on which the controller service might run. Furthermore, ensuring proper configuration of nodes can become complex if a given node needs to be able to implement various different types of services (each of which may have different environment requirements).In contrast, the controller service container described makes it easy to instantiate each controller service on any given node and move it easily between nodes / servers or between computing clusters (for example, by an I / O server service).

[0021] Another aspect of the system currently described involves security services within the SDCS. At the SD network layer, SD network services can operate and manage logical or virtual networking utilized by the logical process control system, which may be implemented by SD network services across physical nodes. SD network services can deploy and manage instances of network appliances such as virtual routers, virtual firewalls, virtual switches, virtual interfaces, and virtual data diodes, as well as instances of network services such as packet inspection services, access control services, authorization services, authentication services, encryption services, certificate authority services, and key management services within the SDCS.

[0022] For example, an SD network service might deploy a service for role-based authorization within the SDCS. When a user requests authorization to access a service within the SDCS (e.g., a control service), the authorization service might determine the user's authorization level based on the request and determine whether the user is authorized to access other services. More specifically, the authorization service might determine the minimum threshold authorization level for accessing the control service and determine whether the user's authorization level meets or exceeds that minimum threshold authorization level. If the user is not authorized, the authentication service might prevent access to the control service.

[0023] SD network services may also deploy Certificate Authority (CA) services. CA services may generate digital certificates for physical or logical assets to authenticate those assets. The certificates may indicate that the CA service has verified the identity of the physical or logical asset, eliminating the need to verify the asset's identity each time it communicates with an SDCS service or node.

[0024] SDCS may also include discovery services that run via containers on SDCS compute nodes. When a physical or logical asset joins the process plant network, the physical or logical asset announces its presence. The discovery service then generates and stores a record of the identity, capabilities, and / or location of each physical or logical asset within the process plant, which is used during the process plant's uptime to control at least a portion of the industrial process. In this way, the discovery service can assist in the commissioning of physical assets within the process plant, such as field devices, and logical assets, such as containers, services, and microservices. Physical or logical assets in SDCS may be automatically commissioned upon discovery without manual input.

[0025] The discovery service can also perform fault recovery by broadcasting a request to announce the existence of each physical or logical asset in the network if the records of the physical or logical assets within the process plant are corrupted or destroyed. In this way, the records of the physical or logical assets can be automatically recovered without the need to manually enter information about each physical or logical asset within the process plant.

[0026] Furthermore, unlike current process control data exchange standards such as OPC (also referred to herein as “primary variables”), which at best identify capabilities announced by physical or logical assets, the discovery service described herein is configured to automatically infer additional capabilities of a physical or logical asset that are not announced to the discovery service when the physical or logical asset is discovered (also referred to herein as “context variables”). Additional capabilities may include additional parameters or services provided by the physical or logical asset, or services configured to communicate with the physical or logical asset. The discovery service can then provide instructions on the capabilities of the physical or logical asset to another node or service in the SDCS requesting information about the physical or logical asset. In this way, the discovery service can store a more complete record of the physical or logical assets in the process plant and their respective capabilities than previous process control systems. Thus, nodes and services in the SDCS can obtain detailed information about the capabilities of the physical or logical assets in the process plant from the discovery service without having to directly poll the physical or logical assets to identify additional capabilities.

[0027] Further, to assist the user in visualizing the runtime operation of the SDCS, the visualization service interfaces with the orchestrator and the configuration database to obtain configuration data and current runtime operation data that define the current established or operational interrelationships between various logical elements of the control system, such as control and subsystem containers, both with each other and with physical elements within the system. The visualization service can create any number of different user displays that show these relationships (as currently configured and operating in the SDCS) and also provide key performance or health parameters regarding one or more of the displayed logical and / or physical elements. For example, the visualization service can create a runtime operation hierarchy that shows, in a hierarchical view, the way various logical elements, such as a control container and its subunits, are nested and fixed to each other. This hierarchy can also show the way various logical elements are fixed to, simply running on, or assigned to various physical elements of the control system. The hierarchical display can also enable the user to move or dynamically reassign various logical elements to other logical elements or physical elements within the system. Still further, the visualization service can create and present a display that shows the physical hardware within the control system (e.g., servers, nodes, compute clusters, processors, etc.) and the logical elements (e.g., control containers, third-party containers, subsystem containers, etc.) currently running on those physical elements. The display can also include performance or health indicators that show various performance and / or health measurements of the physical and logical elements within the display. In other cases, the visualization service can create and present a display that shows various logical elements, and the way these logical elements are nested or fixed to each other, and the physical elements currently being used to execute each of the logical elements during the current runtime of the control system. These displays can also provide or show various performance measurements of the different logical and physical elements displayed therein to enable the user to easily view or visualize the current operation and operational health of the control system or various parts thereof.

Brief Description of Drawings

[0028] [Figure 1] Draw a block diagram of an exemplary physical industrial process plant including a software-defined control system (SDCS). [Figure 2] Draw a block diagram of an exemplary software-defined control system that may be included in the industrial process plant of FIG. 1. [Figure 3] A block diagram showing the principles of fault tolerance and load distribution. [Figure 4A] A block diagram conceptually showing load distribution. [Figure 4B] A block diagram showing an implementation form of load distribution at the primary container and container level. [Figure 5A] A block diagram showing an implementation form of fault tolerance at the container level. [Figure 5B] A block diagram showing an implementation form of fault tolerance at the server level. [Figure 6] An exemplary data structure maintained by an orchestrator to track instantiated services and containers. [Figure 7] A block diagram depicting a software-defined storage service. [Figure 8] A block diagram showing the logical and physical hierarchical configurations of a process plant. [Figure 9] A block diagram showing an exemplary implementation form of nested containers in a process control system. [[ID=3s]] [Figure 10] A block diagram showing the use of nested containers for fault tolerance and load distribution. [Figure 11] A block diagram showing containers individually instantiated within a nested hierarchical system. [Figure 12] A block diagram depicting another example of container nesting. [Figure 13] A block diagram showing a first example of container fixation within a process control system. [Figure 14] This block diagram shows a second example of container fixation within a process control system. [Figure 15] This is a block diagram of the I / O network, including containerized services for implementing control of a portion of the plant area shown in Figure 1. [Figure 15-1] This is a block diagram of the I / O network, including containerized services for implementing control of a portion of the plant area shown in Figure 1. [Figure 16] This is a block diagram of a computer cluster including physical resources (e.g., computers, servers, networking equipment, etc.), on which one or more of the various containers, microcontainers, services, and / or routines described herein may be implemented, dynamically allocated, and load-balanced to optimize computer resource usage and performance. [Figure 17] Figures 15 and 16 illustrate exemplary embodiments of physical servers on which containerized services, such as those shown, may be implemented. [Figure 18] These are flowcharts illustrating methods for implementing I / O server services, such as one of those shown in Figures 15 to 17. [Figure 19] Figures 15-17 show flowcharts of methods for evaluating and migrating between containerized controller services, such as one of the examples shown. [Figure 20] Figure 1 shows a block diagram of exemplary containers, services, and / or subsystems related to network security included in SDCS. [Figure 21] Figure 1 shows another block diagram of an exemplary container, service, and / or subsystem related to network security, which is included in the SDCS. [Figure 22] Figure 1 shows a block diagram of an exemplary container configured to run a virtual router within SDCS. [Figure 23]This diagram shows an exemplary virtual firewall block diagram associated with each control service, including a set of firewall rules specific to the associated control service. [Figure 24] The image depicts an exemplary block of containers configured to run a virtual controller, and includes nested containers configured to run the virtual controller's security services. [Figure 25] Figure 1 shows another block diagram of an exemplary container configured to run a virtual router within the SDCS, which contains nested containers configured to run a virtual field gateway, a virtual data diode, and a virtual edge gateway, respectively. [Figure 26] Draw a block diagram of an exemplary container configured to run a Certificate Authority service. [Figure 27] Draw a block diagram of an exemplary container, service, and / or subsystem included in the SDCS in Figure 1, configured to perform authentication and authorization services. [Figure 28] Draw a block diagram of an exemplary container configured to run a storage service. [Figure 29] Draw a flowchart illustrating an exemplary method for protecting the process control system of a process plant. [Figure 30] Draw a flowchart illustrating an exemplary method for role-based approval within a software-defined process control system (SDCS). [Figure 31] A flowchart illustrates an exemplary method for generating digital certificates by a certification authority service to authenticate the physical or logical assets of a process plant. [Figure 32] Draw a flowchart illustrating an exemplary method for authenticating the physical or logical assets of a process plant. [Figure 33] Figure 1 shows a block diagram of an exemplary container, service, and / or subsystem related to discovery included in the SDCS. [Figure 34] Draw a block diagram of an exemplary container configured to run a discovery service. [Figure 35] Draw a block diagram of an exemplary container configured to run a context dictionary service. [Figure 36] Draw a block diagram of an example context that could be included in a context dictionary container. [Figure 37] Draw a flowchart illustrating an exemplary method for providing discovery software as a service within a process plant. [Figure 38] Draw a flowchart illustrating an exemplary method for inferring information about the physical or logical assets of a process plant using a contextual dictionary. [Figure 39] A flowchart is drawn to illustrate an exemplary method for mapping a set of capabilities to each type of physical or logical asset within a process plant and determining the functionality of the discovered physical or logical asset. [Figure 40] Draw a flowchart illustrating an example of a fault recovery method for an item found within a process plant. [Figure 41] Draw a flowchart illustrating an exemplary method for automatically commissioning SDCS. [Figure 42] The diagrams depict visualization services or utilities connected to the configuration database and orchestrator, which can be used to provide users with current logical and physical configuration and uptime information, in addition to various performance metrics associated with the system's physical and logical elements. [Figure 43] To illustrate the configured uptime interactions of the logical and physical elements within the control system in a hierarchical view, a first screen display that can be presented by the visualization service in Figure 42 is shown. [Figure 44] To illustrate the configured uptime interaction of the logical elements currently implemented in a particular set of physical elements within the control system, a second screen display that may be presented by the visualization service in Figure 42 is shown. [Figure 45]To illustrate the interaction of configured operating times of physical elements associated with a specific or selected set of logical elements within a control system, a third screen display that may be presented by the visualization service in Figure 42 is shown. [Figure 46] In addition to various performance indicators for each element, a fourth screen display, which may be presented by the visualization service in Figure 42, is shown to illustrate the interaction of configured operating times of the logical and physical elements within the control system. [Modes for carrying out the invention]

[0029] Figure 1 shows a block diagram of an exemplary physical industrial process plant 10, including an exemplary software-defined control system (SDCS) 100. The process plant 10 includes a field environment 12 (e.g., the process plant floor) that is communicatively connected to a backend environment 15. The backend environment 15 of the plant 10 is typically shielded from the harsh conditions and materials of the field environment 12 and may include, for example, a separate room, building, or site location adjacent to the field environment 12, any number of devices located remotely from the plant site, and / or any number of applications running remotely on devices or systems located remotely from the plant site. The backend environment 15 includes the SDCS 100 and typically also includes one or more physical workstations and / or user interfaces 20a-20e that are communicatively connected to the SDCS 100. For example, one or more operator and / or configuration workstations 20a may be located in a shielded room at the site of plant 10 and communicate with SDCS 100 via wired data or communication link 22 (e.g., Ethernet® or some other suitable wired link), and one or more operator tablets 20b used by on-site personnel may communicate with SDCS 100 via wireless link 25 (e.g., a cellular communication system link such as Wi-Fi, WirelessHART, 4G LTE, 5G, or 6G, or some other type of suitable wireless link) and wired link 22. Other user interfaces 20c-20e associated with process plant 10 may be located outside plant 10 and communicate with SDCS 100 via last-mile link 30 and / or wireless link 32 and / or via one or more network private and / or public networks 35.For example, laptops 20c, mobile devices 20d, and / or process plant-related applications running on laptops 20c, mobile devices 20d, and / or vehicle systems 20e may be communicably connected to the SDCS 100 via their respective wireless links 32, one or more public and / or private data or communication networks 35, and direct or last-mile links 30 to the SDCS 100 (which typically do not necessarily have to be wired links). Remote user interfaces and devices 20c-20e may be utilized, for example, by plant operators, configuration engineers, and / or other personnel associated with the industrial process plant 10 and its components.

[0030] As shown in Figure 1, the SDCS 100 communicates with components in the field environment 12 via an I / O (input / output) interface system or gateway 40. Generally, the field-facing portion of the I / O interface system 40 includes a set of physical ports or physical hardware interfaces through which various types of I / O data are delivered to and from components located in the field environment, connecting to and / or supporting process plant communication links or data links 42-58 through which the I / O data is delivered. The I / O interface system 40 translates and / or routes physical I / O received via links 42-58 from components in the field environment 12 to receiver components of the SDCS 100 (not shown in Figure 1), and conversely, the I / O interface system 40 translates communications generated by the SDCS 100 into corresponding physical I / O and routes the physical I / O to their respective receiver components located within the field environment 12, for example, via the corresponding links 42-58. For this reason, the I / O interface system 40 is interchangeably referred to herein as the "I / O gateway" 40. In the embodiment shown in Figure 1, at least a portion of the SDCS 100 and the I / O gateway 40 are implemented using a common set of hardware and software computing resources, e.g., the same computing platform. That is, in the embodiment shown in Figure 1, at least a portion of the SDCS 100 and the I / O gateway 40 (e.g., the portion of the I / O gateway 40 that performs translation, routing, switching, etc.) shares at least some computing hardware and software resources, but the I / O gateway 40 further includes physical I / O ports or I / O hardware interfaces to data or communication links 42-58.However, in other embodiments, the SDCS 100 and the I / O gateway 40 may be implemented on separate, communicably connected computing platforms, each utilizing a separate set of hardware and software computing resources, as depicted in Figure 2, for example.

[0031] Now, turning our attention to the field environment 12, Figure 1 depicts various physical components and / or devices (e.g., process control devices, field devices, network elements, etc.) that are placed, installed, and interconnected within the field environment 12, which operate during the operating hours of the plant 10, for example, by collectively communicating and physically operating to control industrial processes (e.g., physical processes) by converting raw materials or input materials into desired products or output materials. Various field devices 60, 62, 70, 80, 90, and other field components 68, 72, 82 can communicate process I / O to and from the SDCS 100 via the I / O gateway 40 by utilizing different types of process I / O.

[0032] For example, one or more wired field devices ("FDs") 60 may be placed in the field environment 12 and may communicate using standard (e.g., conventional) wired physical I / O types such as analog output (AO), analog input (AI), discrete output (DO), and discrete input (DI). The wired field devices 60 may include, for example, valves, actuators, pumps, sensors, etc., which generate data signals and receive control signals to control their respective physical operation in the plant 10, as well as providing status, diagnostics, and other information. The wired field devices 60 may be connected to the I / O gateway 40 via a wired link 42 using any known industrial automation wired protocol such as 4-20mA, Fieldbus, Profibus, Modbus, HART, etc. Thus, the I / O gateway 40 may include respective I / O cards or devices (not shown) that serve to receive and transmit communications via link 42. Additionally or alternatively, in some configurations, one or more wired field devices 60 may be directly connected to separate I / O cards or devices 61, and communication to / from the separate I / O cards or devices 61 may be delivered to / from the I / O gateway 40 via a data highway 58 such as Ethernet® or other suitable high-bandwidth transport medium.

[0033] The field environment 12 may include one or more wireless field devices 62, some of which may be inherently wireless, and some of which may be wired field devices connected to their respective wireless adapters. The wireless field devices and adapters 62 may communicate via their respective wireless links 65 via any known industrial automation wireless protocol such as WirelessHART, or via general-purpose wireless protocols such as Wi-Fi, 4G LTE, 5G, or 6G. One or more wireless gateways 68 may convert wireless signals received from wireless devices 62 via the wireless link 65 into wired signals distributed to I / O gateways 40 via one or more links 48, convert signals received from I / O gateways 40 via links 48 into wireless signals, and transmit the wireless signals to appropriate receiving devices 62 via the wireless link 65. Thus, links 48 may support wireless I / O types, and I / O gateways 40 may include respective wireless I / O cards or devices (not shown) that serve the communications transmitted and received via links 48. In embodiments (not shown in Figure 1), at least some of the links 48 may be directly connected to each wireless I / O card or device, which may then be communicably connected to the I / O gateway 40 via a data highway (for example, in a similar manner to wired device 60 and I / O card / device 61), where the data highway may be included in data highway 58 or may be different data highways.

[0034] The process plant 10 may include a set of field devices 70 that are communicatively connected to the I / O gateway 40 via one or more links 50, each of the terminals 72, one or more remote or marshalling I / O cabinets or systems 75. That is, each of the field devices 70 may communicate with the remote I / O marshalling system 75 via the corresponding physical connection and terminal 72 using standard or conventional wired I / O types (e.g., AO, DO, AI, DI, etc.). One or more processors 78 of the remote I / O system 75 may function as a local switch of the remote I / O system 75 and thus, for example, can switch or route communication to / from the physical terminals 72 (and their respective connected field devices 70) and the I / O interface system 40 via the links 50. Thus, the links 50 may support marshalling or remote I / O types, and the I / O gateway 40 may include respective I / O cards or devices to service the communication delivered via the links 50. In embodiments (not shown in Figure 1), at least some of the links 50 may be directly connected to their respective remote I / O cards or devices, which may then be communicatively connected to the I / O gateway 40, and communication to and from the remote I / O cards or devices may be delivered to and from the I / O gateway 40 via a data highway (for example, in a similar manner to wired device 60 and I / O card / device 61), where the data highway may be included in data highway 58 or may be a different data highway.

[0035] In some implementations, the process plant 10 includes a set of wired and / or wireless field devices 80 that are communicably connected to the I / O gateway 40 via an APL (Advanced Physical Layer) switch 82. Generally, the APL switch 82 and its link 85 provide power to the field devices 80 and, optionally, to other devices such as a wireless router 88, in a manner that meets, for example, the governing power safety requirements of a hazardous field environment 12. Typically, the APL-compatible link 85 provides data transport to and from the field devices 80 and the wireless router 88 via high-bandwidth transport media and packet protocols such as Ethernet® and IP protocols, or other preferred high-bandwidth transport media and packet protocols. Some of the field devices 80 may be next-generation or APL-compatible field devices, and some of the field devices 80 may be standard field devices connected to the link 85 via their respective APL adapters. Similar to link 85, link 55, which connects the APL switch 82 and the I / O gateway 40 in a communicative manner, may also utilize APL-compatible transport media and / or packet protocols such as high-bandwidth Ethernet® and IP protocol, and therefore link 55 may support APL I / O types. As a result, the I / O gateway 40 may include respective I / O cards or devices to service communications delivered over link 55.

[0036] Furthermore, in some configurations, the APL switch 82, or another APL switch (not shown) communicatively connected to the I / O gateway 40, may provide a direct connection to a remote I / O bus, such as a remote I / O bus included in a remote I / O cabinet or marshalling system 75, or to another remote I / O bus included in another remote I / O cabinet or marshalling system (not shown). In these configurations, the APL switch may provide power to the remote I / O cabinet or marshalling system.

[0037] In some configurations, the process plant 10 may include a set of field devices 90 that are communicatively connected to the I / O gateway 40 via standard or non-APL Ethernet® connections 52. For example, the field devices 90 may communicate with the SDCS 100 via the I / O gateway 40 by using an industrial control IP protocol such as HART-IP or other suitable industrial control IP protocol, over one or more high-bandwidth Ethernet® links 52 that are shielded from the hazardous field environment 12 but do not provide power to the field devices 90. Thus, the links 52 may support standard Ethernet® or packet I / O types, and the I / O gateway 40 may include respective I / O cards or devices to service the communications delivered over the links 52. In embodiments (not shown in Figure 1), at least some of the links 52 may be directly connected to their respective IP-compatible (Standard Ethernet®) I / O cards or devices, which may then be communicably connected to the I / O gateway 40 via a data highway (for example, in the same manner as wired device 60 and I / O card / device 61), which may be part of data highway 58 or a different data highway.

[0038] Of course, the field devices 60, 62, 70, 80, 90 and field components 68, 72, 82 shown in Figure 1 are merely examples. Other types of field devices and field components in the industrial process plant 10 may be used additionally or interchangeably within the process plant 10 and may communicate with the SDCS 100 via the I / O gateway 40 by utilizing suitable links, protocols, and process I / O types.

[0039] Figure 2 shows a block diagram of the architecture of an exemplary software-defined control system (SDCS) 200 that may be included in the industrial process plant of Figure 1. For example, at least a portion of the architecture 200 may be utilized by the SDCS 100 in Figure 1. In general, as will be discussed later, the SDCS 200 utilizes a layered architecture in which the business logic of the SDCS 200 is abstracted from the physical computing platform of the SDCS 200. For the sake of clarity, the SDCS 200 is described with simultaneous reference to various parts of the industrial process plant 10 in Figure 1, but this is for illustrative purposes only and is not limiting.

[0040] Figure 2 depicts the SDCS 200, which is communicably connected to the field environment 12 via an I / O interface system or I / O gateway 202. Unlike the I / O interface system 40 in Figure 1, this utilizes a different set of hardware and software computing resources than those utilized by the SDCS 200. Functions 202a provided by the I / O interface system 202, such as switching, routing, and translating communications delivered between the SDCS 200 and devices or components located in the field environment 12 of the process plant 10, are performed, for example, by utilizing the hardware and / or software computing resources of the I / O gateway 202. Therefore, these functions 202a are classified and collectively referred to as “network switches” 202a in this specification. The software and hardware resources utilized by the network switches 202a may be implemented on one or more memories and processors of the I / O gateway 202. For example, the network switches 202a may be implemented on one or more servers, such as a bank of networked computing devices, a cloud computing system, or one or more data clusters. However, similar to the interface system 40 in Figure 1, the I / O interface system 202 includes a set of physical ports or interfaces 202b through which various types of I / O links 42-58 deliver physical I / O from the SDCS 200 to components in the field environment 12, or vice versa. The I / O interface system 202 and the SDCS 200 may be communicated via one or more links 205, which are typically high-bandwidth data or communication links.

[0041] As shown in Figure 2, the architecture of SDCS 200 includes a computing platform 208 of hardware and software resources that support the upper layers of the architecture. Therefore, the computing platform 208 includes physical processors, processor cores, memory, and networking interfaces, and is therefore interchangeably referred to herein as the “physical layer 208” of SDCS 200. The computing platform, or SDCS physical layer 208, includes a set of data center clusters C1, C2, ..., Cn, each of which includes multiple nodes, and the nodes contained within each data center cluster may be interconnected, if not fully, at least partially. Each node in each data center cluster includes one or more respective processors and / or processor cores, one or more respective memories, and networking resources such as one or more respective physical communication interfaces that connect the node to one or more other nodes in the data cluster in a communicative manner. For example, a node may be implemented in a single server or in a bank or group of servers.

[0042] Furthermore, each data center cluster is connected or networked to communicate with one or more other data center clusters of platform 208. Therefore, this disclosure also interchangeably refers to the computing platform 208 of SDCS 200 as a “data center cluster,” a “computing platform node,” or a “node” 208. In Figure 2, the SDCS hyperconverged infrastructure (HCI) operating system (OS) 210 of SDCS 200 (interchangeably referred to herein as “SD HCI OS” 210) may assign, designate, or allocate various nodes 208 to perform their respective roles in supporting SDCS 200, such as computing (e.g., via the respective processors and / or processing cores of the nodes) or data storage (e.g., via the respective memory of the nodes). Nodes 208 assigned, designated, or allocated to perform computing activities of SDCS 200 are referred herein, respectively, as “computing nodes.” Similarly, nodes 208 assigned, designated, or allocated to perform storage activities of SDCS 200 are each referred to herein as “storage nodes”. Individual nodes 208 may be used as compute nodes only, storage nodes only, or both compute and storage nodes, and the role of each individual node 208 may change dynamically over time, for example, as directed by SD HCI OS 210. Advantageously, the computing platform 208 is scalable and, in order to support the software-defined process control system 200, individual nodes 208 and / or individual cluster C as needed, in accordance with other, higher-tier requirements of SDCS 200. x It may be easily added, deleted, replaced, etc.

[0043] The SDCS hyperconverged infrastructure (HCI) operating system 210 runs on the computing platform 208 and can be built upon any suitable general-purpose HCI operating system (OS), such as Microsoft Azure Stack, VMware HCI, Nutanix AOS, Kubernetes Orchestration (including Linux® containers (LXC / LXD), Docker containers, and Kata containers). Therefore, the SDCS HCI OS 210 provides a suite of computing, storage, and networking support services in a manner somewhat similar to a general-purpose HCI operating system. However, in contrast to, and advantageously, a general-purpose HCI OS, in the SDCS 200, these SD HCI OS support services dynamically respond to the logical or abstracted process control system of the SDCS 200, such as the software components of the application layer 212 of the SDCS 200. In other words, as the performance, resource needs, and configuration of various application layer services, subsystems, and other software components of application layer 212 change dynamically (and / or are dynamically predicted to change by services within application layer 212), the SDCS HCI operating system 210 can automatically and responsively adjust and / or manage the usage of hardware and / or software resources 208 of SDCS 200 to support the needs and requirements of SDCS 200 for computing, storage, and networking, as well as other functions related to industrial process control. For this purpose, the SD HCI operating system 210 may include, for example, software-defined (SD) computing (or compute) services 215, SD storage services 218, SD network services 220, a set of support services including SD, orchestrator services 222, and optionally one or more other SDCS HCI OS support services and / or functions 225.Therefore, in the embodiments, the SDCS HCI operating system 210 includes a general-purpose HCI operating system platform (e.g., Microsoft Azure Stack, VMWare HCI, etc.), which is specifically customized to include SD computing services 215, SD storage services 218, SD network services 220, SD orchestrator services 222, and other SDCS HCI OS support services and / or functions 225, the set of support services 215-225 automatically respond to and specifically support the SDCS application layer software components 212 of the software-defined control system 200. Generally, the SD HCI OS 210 and the SD support services 212-225 provided by the SD HCI OS 210 are collectively and generally referred to herein as the “software-defined network layer” 210 of the SDCS 200.

[0044] In particular, the SDCS HCI OS support services 215-225 can function as interface services between the SDCS HCI OS 210 and higher-level services, subsystems, and other software components of the application layer 212 of the SDCS 200, and / or provide a framework for higher-level services, subsystems, and other software components of the application layer 212 of the SDCS 200, so that the SDCS HCI OS 210 manages the allocation of hardware and software resources to the physical layer 208 nodes via the SDCS HCI OS support services 215-225. The HCI adapter layer 230 enables the SDCS application layer 212 to access support services 215, 218, 220, 222, and 225, while being agnostic to the specifics of generic HCI operating systems (e.g., Microsoft Azure Stack, VMware HCI, etc.) customized with such SD-specific services 215-225 to form the SD HCI OS 210. Thus, the HCI adapter 230 translates or transforms the API 228 used by the SDCS application layer 212 into a set of APIs 232 that are understood by, or otherwise known or compatible with, the customized or adapted generic HCI operating system 210 of SDCS 200.

[0045] Thus, unlike typical layered IT (information technology) system architectures where business logic applications are abstracted from the hardware and software computing platform, and the management of computing platform resources is largely managed and designed by human IT administrators, the SDCS 200 architecture not only abstracts higher levels of business logic services, subsystems, and other software components of the application layer 212 from the hardware and software computing platform 208, but also enables higher-level SD services, subsystems, and other software components 212 to dynamically, automatically, and responsively direct and cause changes in the usage of hardware and software resources of nodes and clusters of the computing platform 208, for example, via APIs 228 and SD support services 215, 218, 220, 222, and 225, without requiring any human intervention or instruction. Particularly and advantageously, the management of resources on the computing platform 208 dynamically responds to changes in the configuration and needs of these higher-level SD services, subsystems, and other software components of the application layer 212, and especially to the specific requirements, limits, and boundaries of industrial process control systems.

[0046] In SDCS 200, industrial process control and other related business logic are performed in the application layer 212 of SDCS 200 by higher-level SD services, subsystems, and other software components 235, 238, 240, 242, and 248. For readability herein, this disclosure classificatively refers to these higher-level SD services, subsystems, and other software components 235-248 as the software-defined “application layer software components” of SDCS 200. Collectively, the set of SD application layer components 235, 238, 240, and 242 (and optionally at least some of the third-party services 248) forms a logical process control system 245 (also interchangeably referred to herein as a “virtual process control system” 245) for controlling one or more industrial or physical processes performed in, for example, an industrial process plant 10. As shown in Figure 2, the SD application layer software component 212 includes a set of process control services 235 and a set of process control subsystems 238, and optionally may include a set of other SDCS business logic services 240. In Figure 2, the I / O server service 242 is depicted separately for the purpose of clarity (not limiting), however, the I / O server service 242 may be included in subsystem 238 of SDCS 200 or in a set of other SDCS business logic services 240. In fact, in other embodiments of SDCS 200 (not shown), at least each part or all of the I / O server service 242 may even be implemented in the HCI adapter 230, the SD HCI operating system 210, and / or the network switch 202a. Furthermore, in some implementations of SDCS 200, a set of third-party business logic services 248 may also run in the SDCS application layer 212, and may or may not operate as part of the logical process control system 245.For example, the third-party service 248 may be generated by the SDCS 200 software development kit (not shown), through which the user can develop, generate, install, and manage the third-party service 248 in the SD application layer 212. A more detailed description of the I / O server service 242 and the third-party service 248 is provided elsewhere in this disclosure.

[0047] In this embodiment, at least some of the SD application layer software components 235-248 may be deployed as microservices that are communicably connected via a microservices bus (not shown), so that the microservices 235-248 can transfer data to and receive data from other microservices 235-248. The distribution of data between the microservices 235-248 and therefor may be supported and / or managed by the I / O server service 242 and / or by the SD HCI operating system 210 and its SD support services 215-225. Thus, the SD application layer software components 235-248 may run on any suitable hardware platform 208 capable of running the SD HCI operating system 210, such as server-class hardware and embedded hardware. Therefore, the microservices 235-248 may be business logic components of the SDCS 200 abstracted from the computing platform 208.

[0048] Within the SDCS 200 architecture, application tier software components 235-248 can run as instantiated software components (ISCs) in containers, thick-provisioned virtual machine environments, thin-provisioned virtual machine environments, and / or other preferred types of encapsulated execution environments. For example, an ISC may consist of instances of a particular application tier software component 235-248 to form a configured container or container image of that particular application tier software component 235-248, and the container image of that particular application tier software component 235-248 may be instantiated to run on a particular node 208 as a particular ISC. In another example, an ISC may be a particular application tier software component 235-248 implemented as an instance of a virtual machine (e.g., a process virtual machine or an application virtual machine) to form a virtual machine image of that particular application tier software component 235-248, and the virtual machine image of that particular application tier software component 235-248 may be instantiated to run on a particular node 208 as a particular ISC. In any case, whether container-based or virtual machine-based, the encapsulated execution environment of the SD application tier software components 235-248 isolates the instantiated and running software components 235-248 from other services and applications running on the same node 208. However, for the sake of simplicity (and not for limiting purposes), the execution environment of the SD application tier software components 235-248 is referred to herein as a “container,” but those skilled in the art will understand that the principles and techniques described herein with respect to containers can be readily applied to virtual machines as desired.

[0049] In SDCS 200, instances of application layer services 235, 240, and 248 may run in their respective containers, each subsystem 238 may be provided or run in its respective container, and the I / O server service 242 may run in its respective container, thereby forming each configured container or container image. For example, controller service 235 may consist of one or more process control module services 235, parameters, and values ​​for the industrial process plant 10, such as input and output tags, reference values, etc., thereby forming a configured or programmed controller service. A container may consist of instances of a configured controller service, thereby forming a container image of a configured controller service. In other words, a configured container contains instances of a configured controller service, and instances of a configured controller service are executable to perform a specific, configured set of process control logic using configured control module containers, tags, reference values, etc. Multiple instances of a configured controller service (or other configured service) may be instantiated and run by SDCS 200 as described elsewhere in this disclosure.

[0050] Container images (or instances of controller services configured within a container) can be allocated, fixed, or dynamically assigned, for example via the SD Compute Service 215, to run on each SD node and / or data center cluster 208. The SD Compute Service 215 may dynamically change, update, maintain, and / or manage container images to the compute nodes 208 and their respective assignments as needed or when required, for example, to load balance among compute nodes 208, for scheduled maintenance of compute nodes 208 and / or their physical components, to address detected performance issues, to support expansion or contraction of the logical process control system 245, or to support expansion or contraction of the compute platform 208. In some implementations, containers on which application layer software components 235-248 run (e.g., configured containers or container images) may be assigned or fixed (or otherwise run on) I / O devices outside of the SDCS 200 (e.g., isolated from the SDCS 200), such as devices included in the I / O interface system 202. In these implementations, the SDCS 200 discovers such configured containers running on other devices / systems (referred to herein as “microcontainers”), including microcontainers discovered in other embodiments corresponding to the network scheduling and logical process control system 245.

[0051] Within the SDCS 200, several configured containers may be distributed or assigned to their respective SD compute nodes 208 by the SD Computation Service 215, and dynamically reassigned to different SD compute nodes 208, based on dynamically changing configurations, performance, and the needs of the Logical Process Control System 245. In some situations, a container may be assigned (and reassigned) to run on a specific processor or a specific processor core of an SD compute node 208. However, some configured containers may be fixed to their respective SD compute nodes 208 (e.g., by the SD Computation Service 215, by configuration, by user, etc.) and not dynamically reassigned by the SD Computation Service 215 due to dynamically occurring conditions. That is, a fixed configured container may run on the SDC compute node 208 to which it is fixed, regardless of the dynamic state of the Logical Process Control System 245 (except perhaps a failure of the compute node 208 to which the configured container is fixed), until the configured container is unfixed from the compute node 208. In other words, the software-defined network layer 210 can restrict use by a fixedly configured container to only the hardware and / or software resources it is fixed to, and when the configured container is unfixed, the SD network layer 210 removes the restriction. A container may be fixed to additional or alternative to other physical or logical components of the SDCS 200 as needed. For example, a container may be fixed to another container, a specific data cluster, a specific processing resource (e.g., a specific physical processor or specific physical processor core of an SD compute node 208), a physical rack, or a portion of a physical rack serviced by a specific power supply (if the physical rack physically houses the hardware of one or more nodes), etc.

[0052] Furthermore, configured containers can be nested within other configured containers, which is particularly useful for configuring and organizing the logical process control system 245. For example, if a particular process control subsystem 238 provides a particular set of control services 235 and / or other SDCS services 240, the configured containers for each provided service 235,240 in that particular set can be nested within the configured containers of the particular process control system 238. The distribution / assignment of configured containers to compute nodes 208, the fixing of configured containers, and nesting are described in more detail elsewhere in this disclosure.

[0053] For the sake of clarity and ease of explanation in this specification, the term “container” is used herein to generally refer to an instantiated software component (ISC) that is a configured container or container image, such as a container configured to contain the respective SDCS controller service, SDCS subsystem, or other services provided by SDCS 200. Semantically speaking, within this disclosure, a “container” may be instantiated and assigned to run on computing node 208, a “container” may be fixed to a particular computing node or other container, and a “container” may be nested within another “container.”

[0054] In any case, in a similar manner to how the computing resources of the computing platform 208 were described, containers can be dynamically allocated and / or assigned, fixed, and / or nested to various SDC storage nodes 208, for example, via the SD storage service 218, thereby supporting the various storage needs of the logical process control system 245. For example, the SD storage service 218 can operate and manage the logical storage resources used by the containers of the logical process control system 245 across various physical hardware memory resources of one or more nodes 208. For example, the memory required for a configured container and its operation (e.g., random access memory or similar) can be stored in a specific SD storage node 208 or a specific memory device, or in the space of an SD storage node 208. Examples of types of physical hardware memory resources 208 may include, but are not limited to, a pool of volume file systems across multiple hard drive (and / or flash drive) devices, NRAM, MRAM, FRAM®, PRAM, and / or other types of NVRAM, NVMe memory. Furthermore, if necessary, some containers may be pinned to their respective SD storage nodes 208 and / or specific memory devices or memory areas of the SD storage nodes 208. The SD storage service 218 may modify, update, or otherwise manage the physical hardware memory or memory 208 to support the logical storage resources of the SDCS 200, for example, due to scheduled maintenance resulting from disk or other types of errors, or due to the addition / expansion of available physical memory in the computing platform 208.

[0055] Furthermore, the SD network service 220 can operate and manage logical or virtual networking utilized by the logical process control system 245, which may be implemented by the SD networking service 220 across the nodes 208. For example, the SD network service 220 can support logical networking functionality included in the logical or virtual process control system 245, such as virtual interfaces, virtual switches, virtual private networks, and virtual firewall rules, and can also operate and manage the networking and hardware resources of the computing platform 208 to support the necessary networking between various containers or container images of the logical process control system 245. Since the logical process control system 245 serves the industrial process plant 10, the timing and synchronization of the logical and physical components of the SDCS 200, as well as the networking between them, are critically important because missed and / or lost messages or communications could cause the industrial or physical process to become uncontrollable, potentially leading to catastrophic consequences such as overflow, gas leaks, explosions, equipment loss, and, in some cases, loss of life. Fortunately, the SD network service 220 responds to critical process I / O timing and synchronization of the SDCS 200, so that communications (particularly communications to and from the control service 235) can be reliably delivered in a timely and deterministic manner. For example, the SD network service 220 can support sub-millisecond time synchronization of the data center cluster 208 to ensure necessary synchronization between the process control service 235, the process control subsystem 238, the I / O server 242, and other SDCS services 240, 248 in the SDCS application layer 212.

[0056] In addition to the SD Computing Service 215, SD Storage Service 218, and SD Network Service 220, the SD HCI operating system 210 may provide other OS support services 225 accessible via a set of APIs 228, 232 and utilized or accessed by the application layer 212 to support the logical process control system 245. For example, other SD HCI OS services 225 may include, to name a few, service lifecycle management services, discovery services, security services, cryptographer services, certification authority subsystem services, key management services, authentication services, time synchronization services, service location services, and / or console support services (all not shown in Figure 2). A more detailed description of these other process control system-related OS support services 225 is provided elsewhere in this disclosure. In some embodiments of the SDCS 200, one or more of the support services may be executed in the application layer 212, for example, as other SDCS services 240, instead of being executed in the software-defined network layer 210 as OS support services 225.

[0057] Now, looking at the application layer 212 of the SDCS 200, a set of SD process control services 235 provides the process control business logic of the logical process control system 245. Each different control service 235 may consist of desired parameters, values, etc., and optionally other control services 235, and each instance of a configured control service 235 may run in its own container, and each container may be assigned (or fixed) to run on its own node or cluster. Thus, each configured control service 235 may be a logical or software-defined control entity that can be functionally configured and performed in a similar manner to conventional hardware-implemented process controller devices, process control modules, process control function blocks, etc. However, unlike conventional hardware-implemented process controller devices, conventional control modules, and conventional control function blocks, and advantageously, the SDCS 200 can easily replicate multiple instances of the same configured control service 235 for various purposes such as performance, fault tolerance, and recovery. For example, a controller service (running in its own container) may be configured to run a control module service (running in its own container), and the control module service may be configured to run a set of control function block services (each of which runs in its own container, each of which may consist of its own parameters, values, etc.). Thus, a set of containers corresponding to a configured set of control function block services may be nested within a control module service container, and a control module service container may be nested within a controller service container. A set of containers corresponding to a configured set of function block services may be allocated to run on different cores of the physical layer processor 208, for example, for performance load balancing purposes. When the load changes, one or more of the function block service containers may be moved to run on different processor cores, different processors, or different nodes in an attempt to rebalance the load.However, the moved functional block service container will still be nested under the control module service container and will run accordingly.

[0058] In addition to the software-defined control services 235, the SDCS application layer 212 may include other types of SDCS application layer services 240, such as, but not limited to, operator displays and interfaces, diagnostics, analysis, safety routines, reporting, data history, service configuration, container configuration, and communication of information with external or other systems. Generally, any module or process control system-related function or business logic configured in a conventional process control system and which can be downloaded and / or instantiated to specific physical devices of the conventional process control system to run during the uptime of an industrial process plant may be logically implemented in the SDCS 200 as their respective services 235, 240, which run in their respective containers. Furthermore, any of the containerized SD control services 235 may be communicated via, for example, the SD network layer 210 to one or more devices located in the field environment 12 of an industrial process plant (e.g., process control field devices 60, 62, 70, 80, 90, user interface devices, and / or other field environment devices) and / or one or more user interfaces / user interface devices 20a-20e, and may transfer I / O data and / or other types of data between them when requested by the business logic of the containerized SD control service 235 and / or by the receiving devices (or applications or services running on the receiving devices). Depending on the circumstances, different containerized SD control services 235 may be communicated via (e.g., the SD network layer 210, I / O server service 242, microservice bus, etc.) to transfer data between them when requested by their respective business logic.

[0059] A set of SD subsystems 238 in the application layer 212 of the SDCS 200 provides virtual or logical process control-related subsystems of the logical process control system 245. Each different SD subsystem 238 may be provided by or run within its own container. In some cases (not shown in Figure 2), a subsystem 238 may provide or include one or more application layer services, and therefore the containers of the services 235, 238 provided by the subsystem may be nested within the subsystem container. For example, the historian subsystem 238 may include read, write, and lookup services, and the containers of each of them may be nested within the historian subsystem container. In another example, the batch process control subsystem 238 may include unit procedure services, recipe services, and a regulatory record generation service which may be nested within the batch process control system container. In general, the set of SD subsystems 238 allows the SDCS control services 235 and other SDCS services 240 to be easily and consistently grouped and / or managed. In a preferred embodiment, each node 208 of the SDCS 200 hosts an instance of each subsystem of the set of SD subsystems 238, so that, for example, subsystem services are readily available in close proximity to other application layer services 235, 240, 248 currently running on each node 208. Thus, changes to one or more of the subsystems 238 can be coordinated among their corresponding instances running on each node 208 (for example, under the direction of the SD HCI OS 210). Thus, the set of SD subsystems 238 are not only readily available in close proximity to any SD services 235, 240, 248 running on the same node 208, but the functionality provided by the set of SD subsystems 238 can also be readily maintained for the logical process control system 245 in the event of a node failure, node component failure, or failure of a particular subsystem instance on a node.Examples of SD subsystem 238 include, but are not limited to, continuous process control, event-driven process control, batch process control, state-based control, ladder logic control, historians, edge connectivity, process users, alarms, licenses, events, version control, process configuration, and process I / O.

[0060] For example, a set of SD subsystems 238 may include a continuous process control subsystem. The continuous process control subsystem may include a set of control services 235 responsible for performing process control tailored for continuous production and operation. For example, the control services 235 provided by the continuous process control subsystem may perform modular control (e.g., control module services) that can be executed periodically with I / O allocation. The business logic of control system entities (both logical and physical) that can be managed within the continuous process control subsystem may include, but are not limited to, controllers, I / O allocation, control modules, functional blocks, ladder logic, and structured text-based control algorithms. Continuous control module services may be scheduled periodically, with or without module chains. For example, continuous control module services may form a chain of executions, resulting in a user-defined set of continuous control module services being executed sequentially in a chained manner. The continuous control module service chain may be executed in an allocated (periodic) execution amount in a best-effort evaluation of the control logic contained within the module service chain. Non-chained continuous control module services can run in parallel with chained continuous control module services during the same periodic execution time.

[0061] In another example, the set of SD subsystems 238 may include a state-based process control subsystem. The state-based process control system may include a set of state-based control services 235 responsible for tracking, assigning, and deriving the state of the process control system 245 as a whole. Generally, state-based operations of a process control system may include operations aimed at automatically or semi-automatically changing the state of a process (or part thereof) on a set of process units in the plant infrastructure. Each state operation may have the ability, for example, to derive the current state of a process unit, determine the current state, analyze the difference between the current process state and a recorded normalization for known process states, and drive the process to achieve the process state.

[0062] For example, a state-based process control subsystem can automatically derive intermediate process I / O or control changes and drive at least a portion of the process control system 245 from one state to another. The states of the SDCS 200 can be saved and restored, along with the automatically derived transitions between states, respecting boundary conditions corresponding to process safety and process profitability. For example, in an exemplary scenario, a set of process instructions may be generated (e.g., by one or more application layer services 235 included in the state-based process control system) to safely drive the state of process unit A from known state B to known state B', and the generated process instructions respect the process safety constraint that the boiler unit's burner must be below 200 degrees Celsius. Furthermore, the automatically derived process instructions can also respect a profitability constraint that limits the change in burner output to 1 degree per second to prevent environmental emissions due to sudden combustion and / or to prevent the burner itself from over-operating, so that profitability can be maintained by minimizing the amount of fuel used per period affecting the state change and minimizing the monetary costs associated with reporting environmental emissions.

[0063] Furthermore, the state-based process control subsystem may recognize unknown states within the process plant and provide application layer services 235 to resolve these unknown states. Generally, unknown states in a process plant can occur when the process plant's I / O and process tags deviate from known states by a predefined amount. Additionally or alternatively, unknown process plant states can occur when process I / O or process devices have unreadable or uncertain statuses or values, for example, when a sensor has an out-of-range state or when a sensor is not communicating at all. The application layer services provided by the state-based process control subsystem may record the last known process state of various parts and / or components of the process control system 245 and present the last known state to the user for comparison with unknown states. Nevertheless, the state-based process control subsystem may also include application layer services 235 to estimate the state of a process unit when a process device contained therein is not communicating but is still operating, i.e., when all other control and I / O tag values ​​except those related to the non-communicating process device match the known state. An example of this situation might be a field valve that has stopped communicating, but whose location has not changed from the last known process unit state. An application layer service 235 included in the state-based process control subsystem may determine that the field valve location can be estimated to be in a previously reported known state, since all other process I / O and sensor tags are still reporting valid process values ​​for a given state. A state visualization tool may indicate a discrepancy between the estimated state and the actual process value to alert the user, for example, to initiate maintenance work to bring the system to a known, recorded, verifiable (e.g., not estimated) state.

[0064] Furthermore, the state-based process control subsystem may provide application layer services 235 that automatically assist the user in creating and saving state definitions. Generally, process states can be defined by the user, typically by referring to state transition diagrams. To assist the user in creating state definitions, the application layer services 235 provided by the state-based process control subsystem may automatically create state definitions by taking the current values ​​of the running process or digital twin system and processing those values ​​into state ranges for specific named states defined by the user, for example. For example, when a plant process is shut down, the application layer services 235 provided by the state-based process control subsystem may create a state definition labeled as a shutdown state by creating a state range based on the currently read process I / O and device tag values. Any deviations that occur (whether autonomously generated or intentionally inserted) may be recorded, and state ranges may be created to capture those deviations as part of the state definition. For example, if a level deviation occurs due to vibration or temperature of 10% during the data acquisition period, the automatic state definition creation application layer service 235 provided by the state-based process control subsystem may generate a range of ±10% for that process value to define as the validation range for a given process state definition. The process state definition may be automatically derived from the operating process using the current process value, or it may be derived based on a specific time segment of a given state as indicated by a comprehensive process historian.

[0065] In another example, an event-based process control subsystem may include a set of application-layer control services 235 that can be triggered to run based on the occurrence of one or more events. For example, an event-based control module service may run when an I / O condition reaches a specific value or status. The service execution chain of a control module can also be triggered on an event basis. Furthermore, various control module services and / or control module service chains may be configured to run when an event timeout occurs, for example, when the control logic is primarily event-driven and a trigger event has not occurred within a certain period. In these situations, in embodiments, a periodic scheduler may run the control module services and / or control module service chains after an event timeout has occurred. Other events within the SDCS 200 may trigger the execution of various control module services, and these other events may include diagnostic events or states, process download changes, or other SDCS events.

[0066] In yet another example, the batch process control subsystem may include a set of application layer control services 235 that perform batch control and tracking of regulated items (for example, for government traceability). The application layer control services 235 provided by the batch process control subsystem may provide, for example, unit procedures, recipes, phases, phase transitions, etc. Furthermore, the application layer control services 235 provided by the batch process control subsystem may manage regulated records related to the generated batch process control.

[0067] The set of SDCS subsystems 238 may include a historian subsystem that provides a set of application layer services 240 for recording time-series data of process I / O and events within the software-defined control system 200. For example, various application layer services 240 provided by the historian subsystem may subscribe to process I / O and / or event data for recording purposes. Other application layer services 235 provided by the historian subsystem may include a source timestamp service, a time compression service (e.g., a constant value may be recorded once and the time range updated accordingly), and conventional time-series database functionality. The recorded historical data may be replicated and made available to all nodes 208 within the SDCS 200. Furthermore, in embodiments, the historical data may be categorized by source subsystem (e.g., the service or subsystem that generated the historical data), production asset, production tag, SDCS data path, and / or any other desired category.

[0068] Additionally or alternatively, the set of SDCS subsystems 238 may include an edge connectivity subsystem, which may provide a set of edge protocols that enable process control data to be sent to and received from various third-party components outside the process control system via each set of application layer services 240. Examples of such edge protocols include, to name a few, OPC-UA and MQTT. The edge connectivity subsystem may include one or more application layer services 240 that provide cloud connectivity to the SDCS 200, and the cloud-based application may support a variety of functions, such as monitoring of the industrial process plant for plant status and asset health, as well as other types of functions. At least some of the application layer services 240 provided by the edge connectivity subsystem may generate a logical representation of the SDCS 200 and corresponding process I / O data as a data model specific to the edge protocol being used. Such a data model allows for secure third-party access to selected process data as needed.

[0069] In some embodiments, the set of SDCS subsystems 238 includes a diagnostic subsystem, which may provide a set of application layer services 240 for collecting and providing diagnostic data from various other SD application layer services 235, 240, 248, various other SD subsystems 238, from node 208, and from the SD network layer component 210 of SDCS 200.

[0070] The SDCS subsystem 238 may include a process I / O subsystem that provides a set of application layer services 240 for managing I / O connectivity and configuration of process I / O within the process control system 245. As previously mentioned, the process I / O subsystem may, in embodiments, provide I / O server services 242.

[0071] The SDCS subsystem 238 may include a process user subsystem that provides a set of application layer services 240 for verifying and / or confirming user credentials when a user logs in to SDCS 200. Furthermore, the services 240 of the process user subsystem may provide user information to other services 235, 240, and 248, for example, authorization. User data may be replicated within the data center cluster 208 as needed.

[0072] Nevertheless, the set of SDCS subsystems 238 may include an alarm subsystem that provides a set of application layer services 240 for defining, stating, and maintaining the state of alarms within SDCS 200. Alarms may include, for example, process alarms, hardware alarms, maintenance alarms, unit alarms, network layer alarms, I / O alarms, hardware asset alarms, software asset alarms, and diagnostic alarms.

[0073] In some implementations, the set of SDCS subsystems 238 may include a licensing subsystem that provides a set of application tier services 240 to verify or ensure that users have privileges according to their SDCS 200 license level. License levels may be available across all SDCS services 235, 240, and subsystems 238, and may take the form of perpetual licenses, time-subscription licenses, consumption-based licenses, or remote licenses (e.g., license data from the cloud or a dedicated license). The application tier services 240 provided by the licensing subsystem are particularly important because if the SDCS 200 license expires or becomes invalid, the SDCS 200 may operate processes that are critical or dangerous to human health. In such situations, the licensing enforcement services can prevent unlicensed activity from occurring while ensuring that licensing enforcement does not create a dangerous environment for users. For example, in one embodiment, when the SDCS 200 is delicensed, all user applications, operator graphics, and workstations may be overlaid with a watermark or translucent banner text indicating that the system has been delicensed, and all services except those provided by the control subsystem may be denied any changes or modifications to them. Thus, some licensed functions may be reduced or deactivated while ensuring that the execution of processes does not become uncontrollable or dangerous.

[0074] To manage licenses, in embodiments, the licensing subsystem may include an application tier service 240 that provides only one primary administrator console session or user session authorized to control plant operations with respect to license-based restrictions, and all other console and / or user sessions may be prevented from affecting any changes initiated by the user. Therefore, the licensing subsystem may provide an application tier service 240 that provides a mechanism for determining that only one session with administrator privileges can perform control operations unlicensed (e.g., at one time). For example, if an active administrator console or session fails or becomes unresponsive, the licensing subsystem may allow a subsequent active administrator session to control plant operations. All other console and user sessions may be prevented from making changes to the process control system until their licenses are restored.

[0075] Furthermore, in some embodiments, the licensing subsystem may provide an application tier service 240 configured to remotely report license status and / or activity to the manufacturer's system, for example, for enforcement and / or legal remedies. In configurations where remote reporting is not provided by the manufacturer, the licensing subsystem may maintain a log of all license-related events for future retrieval via one or more application tier services 240.

[0076] The set of SDCS subsystems 238 may include a distributed event subsystem that provides a set of application layer services 240 for distributing generated events (or notifications thereof) to all nodes 208 of the SDCS 200, along with corresponding timestamps indicating the occurrence time at each event source. In this way, consistent record keeping can be provided across all nodes 208.

[0077] Furthermore, each node 208 of the SDCS 200 may contain an instance of a configuration subsystem 238, which stores the configuration of the control services performed by the SDCS 200 (e.g., all control services 235) in a configuration database provided by the configuration subsystem 238. As a result, when a control strategy is modified and saved (e.g., as each updated control service 235), the configuration subsystem may update the corresponding configuration in the configuration database accordingly via the respective application tier service 240. Since each instance of the configuration database is stored in each node 208, the SDCS 200 provides fault tolerance for the configuration database across all nodes of the SDCS. Therefore, writes to the database (e.g., performed by a configuration database write service provided by the configuration subsystem) can be atomic across all fault-tolerant instances of the SDCS. That is, a database write transaction is not completed until all fault-tolerant instances of the configuration subsystem in all nodes 208 have received and processed the write operation. Atomic writes can be granular with respect to the accessed item or a particular configuration. Therefore, when one entity in the database is written, the scope of the synchronous lock mechanism may be limited to each item or object (entry) being written, so that other entities in the database may also be written in a multi-threaded manner (e.g., at the same time or overlapping time). Furthermore, lock and unlock operations may be atomic across all instances of the configuration database, and therefore, acquiring an object lock is not considered successful until all copies of that object are locked across all instances of the configuration database. In addition, the configuration subsystem may provide one or more application tier services 240 to manage version control of the configuration database.For example, a version control service can track changes to the configuration database, when those changes occurred, and which parties examined the changes.

[0078] Reads from the configuration database (for example, those performed by a configuration database read service provided by the configuration subsystem) may originate from a single local instance of the configuration database. However, in some situations, database read requests may be distributed across multiple nodes 208, for example, so that large read requests are segmented and results are provided in parallel from multiple nodes 208.

[0079] As mentioned above, the I / O server service 242 of SDCS 200 may be included in the process I / O subsystem or another subsystem 238. Alternatively, the I / O server service 242 may be in its own standalone subsystem or be an SDCS service 240 not associated with any subsystem. In any case, the I / O server service 242 generally acts as a service responsible for transferring I / O data (and, in some scenarios, other types of data) between endpoints of the logical process control system 245, for example, from field devices to instantiated container images of application layer services 235, 240, 248 (such as controller, operator interface, diagnostic, analysis, historian, or third-party services), from the instantiated container images of application layer services 235, 240, 248 to field devices, and from the instantiated container image of control service 235 to another instantiated container image of another type of SDCS service 240 (e.g., operator interface, diagnostic, analysis, historian, third-party services). For example, the I / O server service 242 can connect each endpoint in a communicative manner, where it can transfer data using any preferred data delivery or data transfer paradigm, including request / response, issue / subscribe, etc.

[0080] Therefore, the I / O server service 242 may be accessed by other application layer software components 235, 238, 240, and 248 for the purpose of data transfer or data distribution, and the I / O server service 242 may utilize API 228 to thereby trigger I / O data and / or other types of data transfer, for example, via SD HCI OS support services 215-225. Depending on the circumstances, the I / O server service 242 may cause data to be transferred via a microservices bus. In effect, the I / O server service 242 functions as a logical or API gateway, thereby routing process I / O and / or other types of data between containers in SDCS 200, and thereby allowing process I / O to be routed between containers in SDCS 200 and devices deployed in the field environment 12 of the industrial process plant 10. Advantageously, the I / O server service 242 may drive industrial process output by automatically managing fault tolerance and quality of service of process control services and subsystem containers, as described in more detail elsewhere in this specification.

[0081] Furthermore, in the application layer 212 of SDCS 200, at least some physical process control devices or components of a conventional process control system (e.g., controllers, safety logic solvers or devices, data storage devices, edge gateways, etc.) may be logically implemented in the logical process control system 245 as respective services 235, 240, or subsystems 238 that run in their respective containers. Such logical or virtual instances of process control devices or components may be configured in a manner similar to their physical counterparts by configuring the logical devices with control routines, other application layer software components 212, parameters, reference values, lists, and / or other data, as needed. For example, a particular logical edge gateway service may consist of an allow list and connections to a particular logical data diode service, and a controller service may consist of multiple control modules, etc. A configured logical or virtual process control device or component (e.g., a container instance of a process control device or component) may be identified within the logical process control system 245, for example, through its respective device tag or identifier, and each signal received and generated by a configured logical or virtual instance of a process control device may be identified within the logical process control system 245 by its respective device signal tag or identifier.

[0082] Furthermore, the SDCS 200 provides containers within the SD application layer 212 used to represent and / or logically organize the physical and / or logical areas, regions, and components of the industrial process plant 10. For example, units, areas, etc., may be represented by their respective containers, and the containers corresponding to the physical and / or logical components of each unit, area, etc., may be nested within or fixed to their respective organizational containers. For example, the fractional distillation area container of the industrial process plant 10 may include a depropane column unit container and a debutane column unit container, i.e., the depropane column unit container and the debutane column unit container may be nested within or fixed to the fractional distillation area container. Within the depropane column unit container, the controller container may consist of a control routine container configured to operate based on flow rate measurements from a physical measuring field device located at the output port of the physical debutane column in the field environment 12 of the process plant 10. Based on the received flow rate measurements, a control routine executed within the configured control routine container may generate a control output, which the controller container may provide to the actuators of valves that serve the output ports of the depropane tower. The physical actuators and valves are also located in the field environment 12 of the plant 10. Thus, within the SDCS 200, the configured control routine container may be nested within or fixed to the controller container, and the controller container may be nested within or fixed to the depropane tower unit container. The control routine service container may consist of signal tags for flow rate measurements received from field devices and signal tags for control output signals delivered to actuators. If necessary, the controller service container may further consist of device tags or identification information for physical measurement field devices and physical actuators.For example, with respect to the configuration of the control service 235, the user interface service container may communicate with, or be executed through, a process control configuration service container, which allows the user to configure the controller service and control routine service to include desired tags, identifiers, values, and control routines.

[0083] In the SD application layer 212, the SDCS 200 also includes software-defined storage entities or components 213 that provide abstracted data storage (and access to it) to the services and subsystems 235-248 of the SD application layer 212. For example, historian databases, configuration databases, and other types of process control system databases and data storage entities, as well as temporary storage used by various process control application services 235-248 during execution, may be provided by the SD-defined storage entities 213. SD storage databases, areas, devices, etc., may be virtualized or logical storage entities or components that can be allocated or distributed (and reallocated and redistributed) by the SD HCI operating system 210 to various storage resources of the nodes of the computing platform 208. For example, a single SD-defined logical database may be implemented on the hardware memory resources of multiple nodes 208. Furthermore, the SD storage service 218 of the SD HCI operating system 210 may allocate / redistribute the SD storage entities 213 of the SDCS application layer 212 to various storage resources provided by the node 208, based on the performance, resource, and configuration needs of the SD storage entities or components 213 and optionally other components of the SD application layer 212.

[0084] Now, returning to the software-defined network layer 210 of SDCS 200, Figure 2 depicts a specific SD HCI OS service, namely the SD Orchestrator service 222, separately from the depiction of the other SD HCI OS services 215-220, 225, for the purpose of simplifying the explanation. Generally, the SD Orchestrator service 222 instantiates container images (e.g., Application Layer Control Service 235, subsystem 238, third-party services 248, and other SDCS services 240) into container processes operating or running on their respective hardware and / or software physical computing resources 208, and also allocates various SD data storage entities residing on their respective hardware storage and / or software storage resources 208. For example, the SD Orchestrator 222 can instantiate and allocate various instantiated container images that run on and / or utilize various specific sets of hardware and / or software computing resources 208, which may be single-node resources or resources of two or more nodes. Furthermore, the SD orchestrator 222 may assign various SD data storage entities or components 213 to reside on physical layer storage resources 208, such as a single node or multiple nodes, for purposes such as ease and speed of access by resident containers, redundancy, and balancing memory usage across the entire physical platform. In doing so, the SD orchestrator service 222 not only establishes the operational container process but also manages fault tolerance, load balancing, QoS, and / or other performance aspects of the operational container process of the SDCS 200 through, for example, the Quality of Service (QoS) configuration service 252, fault tolerance service 255, load balancing service 258, and optionally other performance-related services 260 provided by the SD HCI OS 210.Therefore, the SD orchestrator service 222 may be called or accessed by other SD HCI OS services 215, 218, 220, and 225, and the SD orchestrator service 222 may then call or access one or more of the performance-related services 252-260. In general, the SD orchestrator service 222 allocates resources to the containers and SD data storage entities of the logical process control system 245, thereby enabling the control of industrial processes at, for example, at least the best performance level, so that the containers can operate efficiently and securely.

[0085] To this end, the performance-related services 252-260 of the SD HCI OS 210 monitor performance parameters, resource usage, and / or criteria during uptime, detect any relevant conditions that occur and / or are expected to occur, and may provide and / or implement any changes in the allocation of SD application layer software components (e.g., containers) 212 to hardware and / or software resources on the computing platform 208. Thus, if various expected and / or unexpected hardware and / or software conditions occur and are detected during the uptime of the industrial process plant 10, the SD orchestrator service 222 will responsively adjust the allocation of hardware and / or software resources of the various nodes 208 to the instantiated container images to maintain (or attempt to maintain) the target or best level of performance and operational fidelity. Conditions detected by the SD Orchestrator 222 that cause changes in the distribution and / or allocation between containers 212 and node resources 208 may include, for example, hardware failure or malfunction, software failure or malfunction, overload on a particular node, increased or decreased bandwidth of various networking components, adding or removing nodes and / or node clusters, hardware and / or software upgrades, container pinning and / or unpinning, diagnostics, maintenance, and other routines (which may temporarily make hardware and / or software resources unavailable for uptime use). Possible response and / or mitigation management actions taken by the SD Orchestrator service may include, for example, reassigning containers to run using different software and / or hardware resources (possibly on different nodes), activating and / or deactivating software and / or hardware resources, and changing the access priority of different containers to different software and / or hardware resources.A more detailed description of the SD Orchestrator Service 222 is provided elsewhere in this disclosure.

[0086] Therefore, and generally speaking, the services, subsystems, and other software components of the SDCS application layer 212 (e.g., 235, 238, 240) can determine, define, or specify the processing, containerization, networking, and storage needs of the logical process control system 245 at the individual container level and aggregate level (e.g., subsystem level, unit level, area level, and / or process control system 245 as a whole). Through API 228 (and, in some configurations, also through the HCI adapter layer 230 and API 232), the SD HCI OS 210, its support services 215, 218, 220, 222, 225, and its SD orchestrator service 222 operate and manage the hardware and software resources of node 208 to support these needs. For example, in some embodiments, the SD orchestrator 222 may run different instances of a particular control container 235 or a particular other SDCS service container 240 on different nodes 208 for other purposes, such as fault tolerance, quality of service, and / or performance criteria for SDCS 200. Advantageously, since the needs of the logical process control system 245 change dynamically over time, the SD HCI OS support services 215, 218, 220, 222, 225 and / or the SD orchestrator 222 may modify, change, and adjust the usage of hardware and software resources on node 208, for example, in a responsive and / or predictive manner.For example, when the logical process control system 245 creates an additional instance of the control service 235 that runs in an additional container, the SD HCI OS support services 215-225 may respond by (via APIS 228 and optionally HCI adapters 230 and API 232) assigning the newly created container to run on the corresponding node, rebalancing existing containers across nodes, allocating specific hardware memory resources to support the logical memory resource needs of the additional container, and adjusting the routing table used by node 208 to support the logical routing needs of the newly created container. In another example, if a particular cluster C2 needs to be taken out of service (for example, for maintenance purposes or unexpectedly due to a lightning strike), the SD HCI OS support services 215-225 may, in accordance with the current needs of the logical process control system 245 and the availability of hardware and / or software resources in other clusters, reassign containers currently allocated to run on cluster C2 to other clusters in advance, and the SD HCI support services 215-225 may adjust the routing table used by cluster 208 accordingly to maintain the continuity of execution of those containers even if cluster C2 is taken out of service. Therefore, the SDCS network layer 210 automatically, dynamically, and responsively determines, initiates, and executes changes to the allocation of hardware and software resources of the computing platform 208 nodes to different SD application layer software components 212 based on detected conditions, such as improvements in the performance of individual logical and / or physical components or groups thereof, performance degradation of individual logical and / or physical components or groups thereof, failures, failures of logical and / or physical components, and configuration changes (e.g., via user commands or automatic reconfiguration by the SDCS 200 service).As a result, with SDCS 200, users or system administrators do not need to direct or control the redistribution of hardware and software resources on node 208 to support SDCS 200 or any changes thereto. In fact, in most cases, users or system administrators may not even be aware of the redistribution of hardware and / or software resources on node 208 that is automatically performed by SDCS 200 in response to changes in the state and components of SDCS 200.

[0087] Figure 2 shows a computing platform 208 that supports SDCS 200, but in some configurations, computing platform 208 may support multiple SDCSs. Multiple SDCSs may share a set of hardware and / or software resources of computing platform 208, or the hardware and / or software resources of computing platform 208 may be divided among multiple SDCSs. In embodiments where hardware and / or software resources are shared among multiple SDCSs, the SDC HCI operating system 210 may manage the shared resources among the application layer services of the multiple SDCSs.

[0088] Furthermore, in several implementations, the SDCS 200 can implement digital twins of various SD application services 235, 240, 248, the entire SD application layer 212, various SD support services 215-225, 252-260, and / or the entire SD network layer 210. That is, the digital twin of a target component / layer can run in conjunction with the active target component / layer on the computing platform 208, thereby receiving uptime data from the field environment of the industrial process plant and operating accordingly with the same logic, state, timing, etc. as the active target component / layer. However, I / O and other types of data generated by the digital twin are prevented from being delivered to the field environment. In this way, if the active target / component fails, the uptime operation of the industrial process plant can be seamlessly maintained simply by activating the fielded digital twin of the target / component.

[0089] Furthermore, in some implementations, the SDCS 200 can implement simulation or modification of various SD application services 235, 240, 248, the entire SD application layer 212, various SD support services 215-225, 252-260, and / or the entire SD network layer 210. That is, the simulation of a target component / layer can be performed in conjunction with an active SDCS component / layer on the computing platform 208, thereby receiving uptime data from the field environment of an industrial process plant and operating accordingly with the same logic, state, and timing as the active target component / layer, or with simulated test logic, state, and timing. However, the I / O and other types of data generated by the simulation are prevented from being delivered to the field environment, and the simulation can be paused, accelerated, decelerated, test inputs supplied, and otherwise managed to observe the operation and make modifications to the simulated component / layer. Therefore, once the simulated portion of SDCS 200 is approved, it may be possible to simply activate the simulated portion for use during the operating hours of the industrial process plant, without having to pause or take the SDCS 200 out of service for that purpose.

[0090] Furthermore, although the physical layer 208 associated with SDCS 200 has been described above as being implemented using physical data center clusters C1-Cx, in some embodiments, at least a portion of the physical layer 208 may be implemented as a virtualized physical layer 208. For example, data center clusters C1-Cx (or a subset thereof) may be implemented as virtual machines running on a cloud computing system, for example. Thus, the HCI adapter layer 230 can interface the SD application layer, SD storage layer, and SD network layer 210 with the virtualized physical layer 208.

[0091] As is evident from the above description and should be understood by those skilled in the art, industrial process control systems such as those described herein can, and often are, very complex systems. Industrial process control systems may include hundreds, thousands, or tens of thousands of discrete but interconnected field devices that need to operate in a coordinated manner to control the process. The complexity brought about by the enormous number of devices is doubled by the complexity of commissioning and maintaining the system, which includes creating and maintaining wired and wireless networks to connect all the devices, creating and maintaining control modules that operate to control the field devices based on measurements from the field devices, and ensuring that sufficient resources (network bandwidth, processing power, etc.) are available to ensure that the system's design tolerances (network latency, synchronous messaging, etc.) are continuously met.

[0092] The container implementation in the software-defined control system described herein is useful for various ways of efficiently managing and operating industrial process control environments. Furthermore, as will be discussed later, containerization facilitates a more intuitive organization of control resources that can mimic the physical or logical organization of devices within a process plant, as well as the physical or logical organization of process and computing resources that control those devices within the process plant. Container implementation also facilitates countless possibilities regarding the maintenance of quality-of-service parameters and the creation and maintenance of fault redundancy.

[0093] Figure 3 is a block diagram illustrating the principles of fault tolerance and load balancing. In Figure 3, two compute nodes 300 and 302 provide compute, memory, and networking resources to the SDCS. As should be understood, each of the two compute nodes 300 and 302 may include one compute node or more compute nodes (not shown), and each compute node may, in turn, include one or more processors (not shown), each of which may have one or more processor cores (not shown). The orchestrator 222, in embodiments, manages the instantiation of various containers and the resources allocated to them according to the requirements of a particular system (e.g., according to the requirements of a particular container or process control plant) and / or according to the general requirements of load balancing and fault tolerance (e.g., if no specific requirements for a process control plant are specified).

[0094] More specifically, the container orchestrator service (i.e., orchestrator 222) is responsible for instantiating container images into running container processes using available computing resources. Orchestrator 222 also ensures that each container is properly established and manages container fault tolerance and load balancing issues. Fault tolerance is achieved by using a horizontal scaling approach in which multiple copies of a container are instantiated for multiple inputs and a single output mechanism. In some embodiments, orchestrator 222 selects an "active" container from among multiple redundant copies of a container. As used herein, the term "active" refers to one of several redundant containers selected such that the output of the selected container drives an input to another container, controlling a field device, etc. For example, if multiple redundant copies of a distributed alarm subsystem container are instantiated, orchestrator 222 may select which redundant container is the active container. As another example, if multiple redundant copies of an I / O server container are instantiated, orchestrator 222 may select which I / O server container is the active container. In this case, each redundant I / O server container may receive process data from the process plant's field devices and output from one or more controller containers, but only output from the active I / O server will be sent to the field devices in the process plant via the physical I / O layer, and each controller container will receive only process data from the active I / O server container.

[0095] Communication between fault-tolerant copies of service containers is possible (and sometimes required) to transfer and establish state information. Orchestrator 222 is responsible for maintaining a list of specific service containers in a fault-tolerant deployment, the order of which indicates the next available container to take over (active containers are at the top of the list). This list is continuously updated as the state within the data center changes. In response to an active notification that an active service container is going out of service, orchestrator 222 can make a quick decision about the next available fault-tolerant copy to take over. If an unplanned active container goes out of service (e.g., due to a power failure), the container orchestrator may have a timeout delay to detect that such a "hard" failure has occurred and may move to activate the next available service container. If multiple active states are detected, the recipient of service outputs will receive multiple outputs in a short period of time. The receiving service notifies orchestrator 222 that duplicate output has been received, and in response, orchestrator 222 reconfigures the old active container (or destroys and recreates it if reconfiguration fails) and instantiates it as an inactive container. During this time, the receiving container defaults to being the last known good information source until the duplicate information source is removed.

[0096] In some cases, orchestrator 222 is responsible for selecting the active container, but in certain situations, such as with I / O server containers, the container itself may select the active container based on various parameters, as will be discussed later regarding I / O server containers.

[0097] As used herein, the phrase “load balancing” means the use of compute, memory, and / or communication resources for processes (e.g., containers) operating on the system so that processor cores, processors, compute nodes, and / or servers meet desired quality of service metrics. Load balancing then includes, in some cases, equalizing the use of compute, memory, and / or communication resources, and in other cases ensuring that minimum QoS parameters are met (i.e., ensuring that the maximum network delay for a particular signal does not exceed a programmed value, ensuring that the maximum processing delay for a particular process does not exceed a programmed value, ensuring that the total delay for a particular value does not exceed a programmed value, ensuring that sufficient memory resources are available for a particular process, etc.).

[0098] Load balancing parameters, such as maximum network latency and maximum compute latency, may, in embodiments, be programmed as parameters of one or more containers, and / or as parameters of specific services running within containers, and / or as parameters of specific values ​​received by or sent from services running within containers. Load balancing parameters may also be configured at the system level to provide global parameters or to provide default parameters that may supersede parameters configured within specific containers or services. The orchestrator 222's QoS configuration service 252 may provide interfaces to facilitate the configuration of QoS parameters at the global, default, container, and / or service levels. The QoS configuration service 252 may also read QoS parameters programmed into various containers and / or services to ensure that the parameters are implemented and maintained by the orchestrator 222.

[0099] In embodiments, a fault tolerance service 255 operating within the orchestrator 222 maintains fault tolerance within the SDCS. As used herein, the phrase “fault tolerance” refers to the creation of redundant processes and / or services (e.g., by creating multiple containers), whether instantiated on different processor cores, different processors, or different compute nodes / servers, and includes embodiments in which the orchestrator 222 (i.e., via the fault tolerance service 255) ensures that one or more redundant containers are instantiated on compute resources supplied by separate power sources so that a power failure does not affect all working copies of a particular container. In embodiments, the orchestrator 222 itself may be instantiated as a redundant component to ensure that fault tolerance persists even if an active instance of the orchestrator 222 terminates abnormally due to a processor failure, power failure, etc.

[0100] Referring again to Figure 3, several logical functions are depicted as being implemented across two servers 300 and 302. The logical functions include a first controller (i.e., a controller that controls a first set of equipment in the first part of the associated process plant) 304, a second controller (i.e., a controller that controls a second set of equipment in the second part of the associated process plant) 306, an I / O server 308, and a historian 310. Each of the logical functions 304-310 is implemented by associated services running within one or more corresponding containers. For simplicity, in this explanation we will simply refer to these services running within containers as "containers," but it should be understood that each "container" in Figure 3 runs an associated service, and this service is configured to operate with respect to other containers, services, and / or process control field devices. For example, each controller container has to run a controller service within it that is programmed to control the associated set of equipment. In some embodiments, a controller service may be programmed with one or more control module services, each control module service may be programmed with one or more control function block services, where each control module service and each control function block service may run within their respective containers.

[0101] Figure 3 illustrates that the logical controller 304 contains three controller containers 304A, 304B, and 304C. Each of the controller containers 304A through 304C is instantiated on a different computing resource (i.e., a processor core, processor, compute node, or server) than at least one of the other controller containers 304A through 304C. Specifically, controller container 304A is instantiated on a different server (server 300) than the other controller containers 304B and 304C (which are instantiated on server 302), controller container 304B is instantiated on a different server (302) than controller container 304A (which is instantiated on server 300), and on a different processor or processor core than controller container 304C, and controller container 304C is instantiated on a different server (302) than controller container 304A (which is instantiated on server 300), and on a different processor or processor core than controller container 304B. Figure 3 also depicts three controller containers 306A, 306B, and 306C, instantiated in a similar manner on servers 300 and 302, two I / O server containers 308A and 308B, instantiated on servers 300 and 302 respectively, and two historian containers 310A and 310B, instantiated on servers 300 and 302 respectively.

[0102] Referring to the logical controller 304, it should be clear that by instantiating the controller containers 304A-304C on different computing hardware, only one of the controller containers 304A-304C can be active at a given moment (i.e., provide control output to the controlled device), and a failure in any one of the controller containers 304A-304C will not result in a loss of control of the device controlled by the logical controller 304. If one of the active controllers 304A-304C fails, one of the remaining two controllers becomes the active controller. Since all three controller containers 304A-304C implement the same control algorithm and receive all data received by the active controller, the output provided by each of the controller containers 304A-304C is identical, and if the active controller fails, a new active controller can be selected from controllers 304A-304C. Furthermore, if the failure of the active controller is caused by a power failure on the server where the controller container is instantiated, at least one of the other instances of controller containers 304A-304C may be able to take over as the active controller, provided that at least one of the other instances is instantiated on a computing resource using a different power supply.

[0103] In embodiments, the orchestrator 222 may monitor QoS metrics for various instantiated containers. Examples of QoS metrics may include, but are not limited to, processor load, output latency, network latency, and network bandwidth. If the QoS metrics indicate that one of the containers or a service running in a container is unstable, or if the QoS metrics indicate that one of the containers is not performing within the requirements specified for the container or service, the orchestrator 222 may instantiate further instances of the container, terminate the unstable container instance, and maintain the same level of redundancy while replacing the properly functioning container with the underperforming one. The newly instantiated containers may, in embodiments, be instantiated on different hardware (e.g., a different processor, a different server) than the underperforming container, depending, for example, whether the QoS metrics indicate that the container's performance was poor as a result of the hardware on which it was instantiated. At the same time, if the QoS metric indicates that one hardware resource is underutilized while another hardware resource is fully utilized, the load balancing service 258 may instruct the orchestrator 222 to move one or more containers from the fully utilized resources to the underutilized resources (i.e., create new containers on the underutilized resources and terminate the containers on the fully utilized resources).

[0104] Referring again to Figure 3, orchestrator 222 instantiated four logical functions 304-310 across two servers 300 and 302. As previously mentioned, one instance of controller #1 container 304A resides on the first server 300, while two instances of controller #1 containers 304B and 304C reside on the second server 302. Simultaneously, orchestrator 222 "balanced" the load on the two servers by instantiating two of the three controller #2 containers (306A and 306B) on the first server 300 and only one of the controller #2 containers (306C) on the second server 302. The two containers 308A and 308B run I / O server services on the first server 300 and the second server 302, respectively. Similarly, the two containers 310A and 310B run the historian service on the first server 300 and the second server 302, respectively.

[0105] Figure 4A illustrates the concept of load balancing. In Figure 4A, five containers 312, 314, 316, 318, and 320 are instantiated across three compute nodes 322, 324, and 326. Each of the containers 312, 314, 316, 318, and 320 shown in Figure 4A performs a different service. Although Figure 4A does not depict redundant containers, it should be understood that such redundancy may exist in any embodiment described, even if it is not depicted for the sake of simplifying the diagram of the concept being described. Figure 4A depicts a controller container 312 and a continuous control subsystem container 314 instantiated on the first compute node 322, a distributed alarm subsystem container 316 and an I / O server container 318 instantiated on the second compute node 324, and a safety instrumented system (SIS) controller container 320 instantiated on the third compute node 326.

[0106] Figure 4A shows that the distributed alarm subsystem container 316 is "moved" from the second compute node 324 to the first compute node 322 when the second compute node 324 becomes heavily loaded (for example, when the I / O server container 318 consumes a significant portion of the resources of the second compute node 324), thereby preventing, for example, the QoS metrics of the I / O server container 318 from being maintained, the QoS metrics of the distributed alarm subsystem container 316 from being maintained, or the minimum amount of available resources on the second compute node 324 from being maintained. In such a case, the orchestrator 222 may be instantiated on another compute node (for example, on the first compute node 322 as depicted in Figure 4A) that has sufficient resources for the second instance 316' of the container 316. Once the newly instantiated distributed alarm subsystem 316' stabilizes, the orchestrator 222 may make container 316' an active container, terminate the distributed alarm subsystem container 316 instantiated on the second compute node 324, and free up the resources of the second compute node 324.

[0107] Furthermore, while an inactive instance of a redundant container may not be driving the output of a service (for example, an inactive controller container may not be driving a process), it should be understood that redundant containers can still provide data to parts of the system, provided that the data each of the redundant containers receives is equivalent. For example, while an active controller container is driving a process by providing control signals to a process control field device operating in a process plant, one or more of the redundant controller containers may be providing data to other services in the SDCS, such as the historian service. In this way, the performance load of the system can be distributed among multiple redundant containers, especially if those redundant containers are distributed across multiple hardware resources.

[0108] SDCS100 may also be configured to include “preferred” containers (also known here as “high-priority” containers). Preferred containers are containers running high-priority services and may be designated by the configuration engineer during SDCS configuration or may be designated by default for certain services. For example, container services classified as safety assessments (such as SIS controllers) may be universally designated as preferred containers. In terms of load balancing, preferred containers may be guaranteed computing resources (e.g., processor resources, network bandwidth, memory, storage, etc.).

[0109] Therefore, the orchestrator 222 can perform load balancing to maintain guaranteed resources for the preferred container. Furthermore, referring to Figure 4A, the SIS controller container 320 is depicted as being instantiated on a third compute node 326 (in the figure, a thick container boundary indicates that the container is a preferred container). In this embodiment, the preferred container may, by default, run on a compute node (as depicted in Figure 4A) that has been unloaded in another way, or on a processor core that has been unloaded in another way, in order to ensure that guaranteed resources are available. However, as long as guaranteed resources are provided to the preferred container, it is not required that the preferred container reside on a server, processor, or other hardware component that also does not have other containers (preferred or non-preferred) instantiated thereon.

[0110] The guaranteed resources may be specified by the container type (e.g., hierarchical container, controller container, I / O server container), the service type (e.g., I / O server, controller, subsystem, SIS controller), or individual containers (e.g., controller #1 controlling a specific area of ​​a process plant). Regardless of the level at which a preferred container is designated, the designation of a preferred container may include specifying the type and amount of resources reserved for such a container. For example, a preferred container may guarantee one or more of the following: a specific level of processor performance, a minimum amount of system memory, a minimum amount of network bandwidth, a minimum amount of storage memory, and / or a maximum transmission delay.

[0111] Figure 4B illustrates the concept of a preferred container and also demonstrates the additional capabilities of the load balancing service 258 of the orchestrator 222. Specifically, Figure 4B shows that the orchestrator 222 may, in an embodiment, add and / or remove one or more compute nodes, processors, and / or processor cores from the cluster. Figure 4B depicts a first compute node 328 on which the controller container 330, the continuous control subsystem container 332, and the distributed alarm subsystem container 334 are each instantiated. A second compute node 336 has the preferred SIS container 338 and the I / O server container 340 instantiated on it. In the system illustrated in Figure 4B, the I / O server container 340 requires resources from the second compute node 336, which would impose resources guaranteed to the preferred container 338, causing the load balancing service 258 of the orchestrator 222 to release resources for the preferred container 338. In the illustrated example, orchestrator 222 frees up resources by adding a new compute node (i.e., a third compute node) 342 to the cluster and instantiates a duplicate container 340' of the I / O server container 340 on the new compute node 342. Once the newly instantiated I / O server container 340' stabilizes, orchestrator 222 may make container 340' the active I / O server container, terminate the I / O server container 340 instantiated on the second compute node 336, and free up resources on the second compute node 336 to satisfy the guaranteed resources of the preferred container 338.

[0112] An exemplary implementation of fault tolerance is depicted in Figure 5A. In Figure 5A, the first and second compute nodes 344 and 346 each instantiate controller containers 350A and 350B, continuous control subsystem containers 352A and 352B, distributed alarm subsystem containers 354A and 354B, and I / O server containers 356A and 356B, respectively. The third server 348 is idle. Figure 5A shows that controller container 350A has become unstable or has terminated unexpectedly (indicated by a distinguished outline). The orchestrator 222 recognizes that container 350A has become unstable or has terminated, ensures that the remaining controller container 350B is an active controller container, and maintains redundancy by instantiating a further redundant copy of controller container 350C on the third compute node 348.

[0113] A similar process occurs, for example, when an entire computing node becomes inoperable (e.g., due to a power failure). Figure 5B illustrates such a scenario. In Figure 5B, the first and second computing nodes 358 and 360 each instantiate, on them, controller containers 364A and 364B, continuous control subsystem containers 366A and 366B, distributed alarm subsystem containers 368A and 368B, and I / O server containers 370A and 370B, respectively. A third server 362 is idle. Figure 5B shows that either the first computing node 358 becomes unavailable, or in any case, all containers 364A, 366A, 368A, and 370A suddenly terminate (indicated by distinct contours). Orchestrator 222 recognizes that the first compute node 358 is unavailable and proceeds to make containers 364B, 366B, 368B, and 370B active containers, and to instantiate further redundant copies of containers 364C, 366C, 368C, and 370C on the third compute node 362 to ensure maintained redundancy.

[0114] In the embodiment, the orchestrator 222 maintains or accesses a list, table, database, or other data structure that tracks all instantiated services and containers instantiated on the data center 208 (or, in any case, the portion of the data center 208 within the orchestrator's authority 222). The information in the data structure may be input, for example, by services running in the orchestrator 222 (e.g., performance-related services 260), by services (e.g., software-defined services and functions 225 running in the HCI operating system 210), by software-defined computing services 215, by software-defined storage services 218, and / or software-defined network services 220. Figure 6 shows the types of information that the orchestrator 222 maintains or accesses in the data structure in Table 372. Generally, the data structure maintains a list of all containers and services instantiated in the data center (column 373), whether each is an active container or service (column 374), and various information and metrics 376 associated with each container or service. For illustrative purposes only, the information and metrics 376 may include one or more of the following: an instruction 377 indicating which of several power sources is powering the resource on which each container or service is instantiated; an instruction 378 indicating on which of several nodes the container or service is instantiated; an instruction 379 indicating the node load; an instruction 380 indicating on which of several processors the container or service is instantiated; an instruction 381 indicating the processor load; an instruction 382 indicating on which of several processor cores the container or service is instantiated; and an instruction 383 indicating the processor core load.

[0115] Orchestrator 222 may also maintain or access data structures that track information at a higher level than container and service levels. For example, orchestrator 222 may access or maintain statistics on the amount of computing resources, storage resources, and / or network resources available on and for each cluster, node, server, processor core, and / or processor core; various power stability (e.g., voltage stability, non-interruptible power status, etc.); and statistics on the latency of various physical network connections. Using data structure 372 and / or higher-level information from data structure tracking, orchestrator 222 may determine, at any given moment, which of each set of redundant containers is active (e.g., column 374 in Table 372), which of each set of redundant containers is the best or next available container (column 375 in Table 372). In this way, orchestrator 222 can immediately activate a new container if a previously active container becomes unstable, underperforms, or terminates.

[0116] For load balancing, fault tolerance, or failure recovery purposes, the orchestrator 222 (and the services being instantiated) partially relies on a software-defined storage service 218 to instantiate new containers. Figure 7 is a block diagram that further illustrates the software-defined storage service 218 and, in context, shows some of the other components of the HCI operating system 210 and the SDCS application layer 212. As mentioned above, applications (i.e., microservices) running within containers in the SDCS application layer 212 communicate via a microservices bus 384, which is part of the software-defined networking 220 of the HCI operating system 210. In addition to facilitating communication between instantiated containers and between instantiated containers, the microservices bus 384 facilitates communication between containers and the orchestrator 222, between containers and the software-defined storage 218, and between the orchestrator 222 and the software-defined storage 218.

[0117] The software-defined storage 218 includes various storage resources, including three configuration data services broadly categorized as a cold process configuration data service 386 ("Cold PCDS"), a warm process configuration data service 388 ("Warm PCDS"), and a hot process configuration data service 390 ("Hot PCDS"). The Cold PCDS 386 stores data related to the startup configuration of the software-defined control system 100, for example. The data stored in the Cold PCDS 386 may include, for example, the redundancy and fault tolerance requirements of the SDCS 100, which application services 235 to instantiate, which subsystems 238 to instantiate, which other SDCS services and / or applications 240 to instantiate, and which third-party applications 248 to instantiate. Furthermore, the Cold PCDS 386 may store the startup configuration for each of the container services. For example, each instance of a controller container implements a controller service, but the controller service requires configuration information to program the controller service with control module services or control loop services, and other information necessary to implement control of the process plant or part of the process plant that the controller should control. Therefore, the data in the cold PCDS 386 is typically designed by the user (e.g., a configuration engineer) or manufacturer and provides a set of operational instructions specific to each service. Each SDCS service (container) will query the cold PCDS 386 for the stored configuration data. In an embodiment, the data stored in the cold PCDS 386 is stored on a service-specific software-defined disk volume.

[0118] The warm PCDS 388 stores data necessary when a container service is running and needs to recover its operational state from a previous instantiation of the service or when recovering from a service failure. Therefore, data stored in the warm PCDS 388 may include state information for the state of each instantiated service, and state information for the state of each active instantiated service, etc. For example, such state information may include an integral accumulator value if the configuration is performing an ongoing mathematical integral over time, a value that changes rapidly and is therefore unsuitable for storage in the cold PCDS 386. The warm PCDS 376 handles rapidly changing parameter storage for warm restart applications. As a result, in some embodiments, the warm PCDS 388 uses a write-back cache to a mapped volume to capture rapidly changing parameters.

[0119] However, in some situations, an instantiated container may need to have information about the exact operational state of the service. This could be, for example, if a container terminates unexpectedly when there are no redundant containers available for failover. In such cases where the exact operational state of the service is required, data may be stored in a hot PCDS 390 that captures the exact operational state of the SDCS service (i.e., the container), so that the hot PCDS 390 replaces the traditional RAM space available to the microservices. The data stored in the hot PCDS 390 is typically stored in a very fast non-volatile memory volume, such as MRAM or NVMe drive technology. A newly instantiated replacement container can be configured with cold, warm, and hot process data and take over process operations from the terminated predecessor container.

[0120] In large-scale industrial process plants, parallel process flows are commonly used. This means that the equipment required to manufacture a product can be multiplied many times over to produce the same product or variations thereof. As a result, process plants are often divided into different physical hierarchies and areas. For example, a particular group of equipment may form a unit, and this unit may be duplicated multiple times within the physical area of ​​the process plant, allowing different product flows to pass through each unit while maintaining similar groups of equipment within specific areas of the process plant. Similarly, logical hierarchies may exist and, in combination with physical hierarchies, distinguish sets of equipment. For example, in the realm of batch control, a "process cell" is defined as a logical grouping of equipment containing equipment for generating one or more batches. A process cell may contain one or more units, each unit containing one or more equipment modules that make up the unit. Each equipment module may consist of one or more control modules (e.g., field devices).

[0121] In relation to the orchestrator 222, various methods can be implemented within the process plant 10, particularly within the SDCS 100. These methods may include configuring a first container to include services to be run within the first container, and allocating the first container to run on available hardware resources of multiple hardware resources. In this way, the first container may be configured to control process control field devices 60, 70, 80, and 90 operating within the process plant 10. The first container may be configured to run a controller service that receives data from the field devices, determines one or more control outputs from the received data, and transmits one or more control outputs to the multiple field devices. Alternatively, the first container may be configured to run an I / O server service. In yet another embodiment, the first container may be configured to run a historian service, a distributed alarm subsystem service, or a diagnostic subsystem service.

[0122] The allocation of the first container to run on available hardware resources may include the allocation of the first container to run on a specific power supply. Alternatively, available hardware resources may be specified as a specific data cluster, a specific set of data clusters, a specific server rack, or a specific server. In other embodiments, available hardware resources may be specified as a specific processor, a specific processor core, a specific memory device, or a specific memory resource.

[0123] Furthermore, in some embodiments, this method may include dynamically adding or removing hardware resources such as physical servers, data clusters, or nodes.

[0124] In the embodiment, the available hardware resources to which the first container is allocated are selected according to metrics related to the available hardware resources. Allocating the configured first container to run on the available hardware resources may involve moving the configured first container from running on the current hardware resources to running on the available hardware resources, according to metrics related to the current hardware resources, the available hardware resources, or a comparison between the metrics of the current and available hardware resources. In various embodiments, these metrics may include, for example, processing bandwidth, network bandwidth, memory resources, or communication latency between a hardware resource and another component.

[0125] The method may also involve configuring one or more redundant containers to contain services running within each of the one or more containers, and allocating each of the one or more containers to run on their respective available hardware resources. The first container may be allocated as the active container so that the output of the active container drives its output (i.e., to be provided to a field device or to drive its input to another container).

[0126] The method may include maintaining a list of redundant containers (including the active container) and updating the list of redundant containers to indicate which container is active. In such an implementation, allocating each redundant container to run on its respective available hardware resources may include selecting its respective available hardware resources such that each of the one or more redundant containers creates fault tolerance in at least one respect, such as creating processor diversity, server diversity, and / or power diversity.

[0127] In further embodiments, the method may include receiving an instruction that a first container is a preferred container, and maintaining a predetermined threshold of resource availability on the hardware resources to ensure that the preferred container and / or available hardware resources meet or exceed specified performance requirements.

[0128] Figure 8 is a block diagram showing the logical and physical hierarchy arrangement of an exemplary process plant 400. The process plant 400 includes two process cells 402A and 402B, each containing three units 404. Process cell 402A contains units A1, A2, and A3, while process cell 402B contains units B1, B2, and B3. Each unit contains one or more equipment modules, and each equipment module contains one or more control modules. For example, unit A1 of process cell 402A contains two equipment modules 404A and 404B. Equipment module 404A contains control modules 406A and 406B, while equipment module 404B contains control modules 408A and 408B. Other units within process cells 402A and 402B each contain one or more equipment modules (not shown) and one or more control modules (not shown).

[0129] Simultaneously, a physical hierarchy or organization may be used within the process plant 400. For example, if process cells 402A and 402B process similar products, units A1 and B1, A2 and B2, and A3 and B3 may each contain the same set of equipment operating according to the same or different control schemes. As a result, the process plant operator can group similar units within "areas" of the process plant. For example, in process plant 400, units A1 and B1 are in area 1, units A1 and B2 are in area 2, and units A3 and B3 are in area 3.

[0130] Depending on the process plant, various logical and physical hierarchies and arrangements are possible, and it will be understood that the exemplary process plant 400 shown in Figure 8 depicts only one possible organizational scheme. Of course, large-scale industrial processes can include any number of areas, process cells, units, equipment modules, and control modules, and consequently, the logical organization of these modules within the control scheme can be particularly useful.

[0131] As described above, SDCS 100 implements a containerized architecture in which each container is an isolated execution environment that runs within the operating system of the computing node hosting the container (i.e., within the operating system of the computing node where the container is instantiated). Since each container is, if not configured, essentially a "sandbox" that can instantiate services and other items, containers in SDCS 100 can represent logical and / or physical hierarchies within the process plant 10. Specifically, containers within SDCS 100 can be nested to represent the logical and / or physical configuration of the process plant in an exact manner.

[0132] Figure 9 is a block diagram illustrating an exemplary implementation of nested containers in a process control system. A compute node 410 on a data cluster (for example, on data cluster 208) instantiates a container 412 on it, representing a process area "Process Area 1". Process Area 1 contains two units, Unit 1 and Unit 2. Thus, container 412 representing Process Area 1 instantiates a container 414 representing Unit 1 and a container 416 representing Unit 2 within it. In this way, the hierarchy of a process plant can be represented within the organization of computing elements of SDCS 100. In the example depicted in Figure 9, a single continuous control subsystem service running in container 418 within container 412 is responsible for both Unit 1 and Unit 2, and a single historian service running in container 420 within container 412 historians the data for both Unit 1 and Unit 2. The controller service, I / O server service, distributed alarm subsystem service, and diagnostic subsystem service specific to each unit are executed within containers 422, 424, 426, and 428 nested within container 414, and within containers 430, 432, 434, and 436 nested within container 416, respectively.

[0133] In this way, a plant operator can configure SDCS 100 in a manner that represents the logical and / or physical design of the relevant process plant. In this way, a container can also be configured to facilitate the replication of the container structure for the purpose of implementing control over separate, but identical, parts of the process plant, and / or creating redundancy, and / or facilitating load balancing operations. For example, a container may be configured to contain specific subcontainers when instantiated, and each specific subcontainer may, when instantiated, be configured only for specific equipment areas of the process plant to be controlled. Referring again to Figure 9, containers 414 and 416 may be different instances of the same container, where when instantiated, containers 422, 424, 426, and 428 within container 414 are associated with equipment of unit 1, and containers 430, 432, 434, and 436 within container 416 are associated with equipment of unit 2.

[0134] Now, looking at Figure 10, individual and / or nested containers can be replicated to facilitate fault tolerance and / or moved between compute nodes or other resources to facilitate load balancing. Figure 10 illustrates an example where container 412 from Figure 9 is instantiated on compute node 410 (container 412) and a second compute node 440 (container 412'). Containers 412 and 412' are functionally identical, but by being instantiated on different compute nodes, one of the containers (e.g., container 412) can be designated as the active container, and the other (e.g., container 412') can be designated as redundant (as indicated by the container with the dotted line). In this way, if the active container suffers a degradation of service (discussed further later), or if the compute node on which the active container is instantiated suffers a failure (e.g., an unexpected server error, power failure, etc.), the redundant container (e.g., container 412') can be designated as the active container, and the relevant part of the process plant can be continuously and reliably controlled.

[0135] Of course, a container can be configured such that any instantiation of a container necessarily includes all the containers nested within it (for example, an instantiation of the container for unit 1 includes all of containers 422, 424, 426, and 428), but it is also possible to instantiate each container individually. For example, such an implementation is depicted in Figure 11, where two compute nodes 410 and 440 each run a part of the process control system depicted. In the example depicted in Figure 11, container 412 is instantiated on compute node 410. Container 412 instantiates container 418, which runs the continuous control subsystem service, and container 420, which runs the historian service. Container 414, associated with unit 1, is instantiated within container 412, and containers 422, 424, 426, and 428, which run the controller service, I / O server service, distributed alarm subsystem service, and diagnostic subsystem service, respectively, are instantiated within container 414. Simultaneously, container 412' is instantiated on compute node 440. Within container 412', container 418' runs a redundant instance of the continuous control subsystem service (indicated by a dotted line), and container 420' runs a redundant instance of the historian service (indicated by a dotted line). Container 416, associated with unit 2, is instantiated within container 412', and containers 430, 432, 434, and 436, which run the controller service, I / O server service, distributed alarm subsystem service, and diagnostic subsystem service, respectively, are instantiated within container 416'. In this way, load balancing can be achieved by implementing the services associated with unit 2 on compute node 440 and the services associated with unit 1 on compute node 410, and redundancy for the historian and continuous control subsystem services can be achieved.

[0136] Figure 12 illustrates another example of container nesting. In Figure 12, redundant configurations are instantiated on the first and second compute nodes 442 and 444, respectively. In each of the two redundant configurations, containers 446 and 446' corresponding to the same process area 1 are instantiated, and within them, containers 448 and 448' corresponding to the same unit 1 of process area 1 are instantiated. Each of containers 448 and 448' contains a set of containers capable of operating to provide services to unit 1, and this set of containers includes controller containers 450 and 450', historian containers 452 and 452', continuous control subsystem containers 454 and 454', distributed alarm subsystem containers 456 and 456', and diagnostic subsystem containers 458 and 458'. Redundant I / O server containers 460 and 460' are instantiated on the first compute node 442 and the second compute node 444, respectively. The I / O servers implemented by I / O server containers 460, 460' may perform I / O services to other process areas, units, and controllers other than those depicted in Figure 12, and therefore are not depicted as being within containers 446, 446' of process area 1, or containers 448, 448' of unit 1.

[0137] The I / O servers implemented by I / O server containers 460 and 460' may be used by containers other than those depicted in Figure 12, but in the figure, containers 446 and 446' in process area 1 are depicted as "pinned" to I / O server 1. Thus, Figure 12 demonstrates another feature of SDCS 100, namely that pinned elements can operate on the same hardware, or that elements within SDCS 100 can be pinned to each other so that they operate on the hardware they are pinned to. In Figure 12, for example, since containers 446 and 446' in process area 1 are pinned to their respective I / O server containers 460 and 460', container 446 will be instantiated on the same server as I / O server container 460, and container 446' will be instantiated on the same server as I / O server container 460'. Therefore, if process area container 446 is moved to another server, I / O server container 460 will similarly be moved to the same server as process area container 446. The same applies to container 446', which is secured to container 460'.

[0138] A container can be anchored to any of the various components within the process plant 10. As illustrated with reference to Figure 12, in embodiments, a container can be anchored to another container so that, when moved from one part of the processing hardware to another, the container moves as a unit and remains running on the same part of the hardware. This can help ensure, for example, that network latency between anchored containers remains minimal. In embodiments, a container can be anchored to specific processing hardware, including a specific data cluster, a specific compute node of the data cluster, a specific processor on a specific compute node, a specific server rack, a specific processor core of a processor, etc. In some embodiments, a container can be instantiated on a smart field device, and therefore, a container can be anchored to a specific field device. A container can also be anchored to a specific non-computing physical resource. For example, a container may be anchored to a specific physical I / O interface, or even to a specific power supply that powers multiple computing resources. In the latter case, this allows each of two redundant containers to move between computing resources powered by their respective power supplies while maintaining fault tolerance with respect to the power supply.

[0139] Figures 13 and 14 illustrate various examples of anchoring containers to components. In Figure 13, compute node 462 instantiates multiple containers 464-474 on it, including controller container 464, historian container 466, continuous control subsystem container 468, distributed alarm subsystem container 470, diagnostic subsystem container 472, and I / O server container 474. As depicted in Figure 13, the I / O server container 474 is anchored to compute node 462. Therefore, other containers instantiated on compute node 462 can be "moved" (i.e., they can be instantiated on other hardware before the instance instantiated on compute node 462 is terminated), but the I / O server container 464 remains on compute node 462 unless some circumstance (e.g., server instability, abnormal termination, etc.) forces the I / O server container 464 to be moved. At the same time, continuous control subsystem container 468 is anchored to controller container 464. The controller container 464 and the continuous control subsystem container 468 are instantiated as a pair, for example, to ensure that data passing between containers 464 and 468 maintains minimum latency for their instantiation on the same hardware resources.

[0140] When a container is pinned to a specific hardware resource, that pinning may be specific to an instance of the container; that is, it may be clear that one instance of a container is pinned to a first hardware resource, and a second redundant instance of the container is pinned to a second, different hardware resource. In such cases, pinning a container to a hardware resource can promote redundancy and fault tolerance. However, when a container is pinned to another container, that pinning may, in some cases, be carried over to all redundant instances of the container pair. That is, a controller and continuous control subsystem pair may be pinned together regardless of which hardware resource each instance of the pair is pinned to. In this way, pinning one container to another container may be implemented to achieve goals related to network latency and bandwidth management, for example.

[0141] On the other hand, Figure 14 shows an example where two power supplies 476 and 478 power their respective sets of compute nodes. The first power supply 476 powers three compute nodes 479, 480, and 481, while the second power supply 478 powers three other compute nodes 482, 483, and 484. Collectively, each set of servers 479-481 and 482-484 instantiates the same set of containers on it, thereby providing a 1:2 fault tolerance, so that if one of the power supplies 476 or 478 fails, the redundant containers on the other power supply 476 or 478 remain active. Collectively, servers 479-481 instantiate the SIS controller container 485, controller container 486, continuous control subsystem container 487, distributed alarm subsystem container 488, I / O server container 489, historian container 490, and diagnostic subsystem container 491 on it. Similarly, servers 482-484 instantiate the SIS controller container 485', controller container 486', continuous control subsystem container 487', distributed alarm subsystem container 488', I / O server container 489', historian container 490', and diagnostic subsystem container 491' on top of them. In effect, each of the containers 485-491 instantiated on servers 479-481 is pinned to the first power supply 476, the SIS controller container 485 is pinned in particular to the first compute node 479, the historian container is pinned to the third server 481, and the rest of the containers 485-491 are generally pinned to the first power supply 476. Simultaneously, each of the containers 485'~491' instantiated on servers 482~484 is effectively anchored to the second power supply 478, the SIS controller container 485' is specifically anchored to the fourth compute node 482, the historian container is anchored to the sixth server 484, and the rest of the containers 485'~491' are generally anchored to the second power supply 478.With the exception of SIS controller containers 485, 485' and historian containers 490, 490', containers 485-491 may be moved between the first, second, and third servers 479-481, and containers 485'-491' may be moved between the fourth, fifth, and sixth servers 482-484 for load balancing while maintaining fault tolerance.

[0142] Of course, as shown in the paragraph above, container nesting and fixing can be used in combination with each other or separately. Thus, the method may involve instantiating first and second containers of a data cluster within a first compute node, each of which is a separate execution environment within the operating system of the first compute node. The second container may be instantiated within the first container, but the services are instantiated within the second container. Each of the first and second containers corresponds, in an embodiment, to the first and second levels of the hierarchical structure of a process plant, respectively. At the same time, the first container may also run one or more services within it. In an embodiment, the services running within the first container may be I / O services.

[0143] The method may also include instantiating a third container on a first computing node, specifically instantiated within a first container. In embodiments, the service running in the second container may be a controller service that executes control routines configured to control a subset of process control field devices in a first part of an industrial process plant, while the service running in the third container may be a controller service that executes control routines configured to control a different subset of process control field devices in a second part of an industrial process plant. In some embodiments, the services running in the second and third containers may include respective I / O server services configured to communicate data between the process control field devices and their respective controller services. In embodiments, the method may include instantiating redundant nested container structures on one or more different nodes of a data cluster.

[0144] In various embodiments, the method may include instantiating an SDCS 100 to control an industrial process plant, a plurality of process control field devices 60, 70, 80, 90 that operate to control physical processes in a plurality of containers, in a data cluster of the industrial process control system 10. Each of the plurality of instantiated containers may be an isolated execution environment running within the operating system of one of the plurality of compute nodes from which the container is instantiated. The plurality of instantiated containers may cooperate to facilitate the execution of a control strategy in the software-defined control system. The method may also include pinning a first container of the plurality of containers to a component of the software-defined control system. As described above, in some embodiments, one or more of the plurality of containers may correspond to levels of the hierarchical structure of the process plant.

[0145] In embodiments, the method may also include running a service in at least one of a plurality of instantiated containers. The service may include, for example, an I / O server service, a controller service, a historian service, a distributed alarm subsystem service, a diagnostic subsystem service, a third-party service, or a security service. Furthermore, pinning the first container to a component of the SDCS may include pinning the container to another container, which may itself be instantiated within the first container, or the first container may be instantiated within the other container.

[0146] The component to which the container is fixed may be a power supply that provides power to one or more data clusters or a portion of a data cluster, or it may be a data cluster, a compute node of a data cluster, a server rack within a data cluster, a server, a specific processor, or a specific processor core within a processor. Alternatively, the component may be an I / O server container on which an I / O server service is running, a process control field device, or a physical I / O interface. In embodiments, the method may include instantiating redundant container structures fixed to different nodes, servers, power supplies, processors, or processor cores.

[0147] Figure 15 is a block diagram of an I / O subsystem or I / O network 500, which includes containerized services for implementing control of a portion of the processes in area 501 and a portion of the processes in area 502 of plant 10 shown in Figure 1. The I / O subsystem 500 is part of and / or can be connected to the I / O gateway 40 and SDCS 100 / 200 shown in Figures 1 and 2.

[0148] With regard to the term "I / O network," a network formed by one or more controllers or controller services (e.g., containerized ones), field devices communicably connected to one or more controllers or controller services, and intermediary hardware or software nodes (e.g., I / O server services, I / O cards, etc.) that facilitate communication between the controllers or controller services and the field devices may generally be called an "I / O network" or "I / O subsystem."

[0149] At a higher level, the I / O subsystem 500 includes (i) I / O server services (sometimes referred to as "I / O services" or simply "services") 511a in area 501, and (ii) I / O services 511b in area 502. While much of the following description focuses on the configuration and operation of I / O services 511a, it will be understood that I / O services 561a may be similarly configured to provide similar functionality with respect to entities used to implement control of process equipment within area 502.

[0150] The I / O service 511a is a software service implemented on any suitable computing device or node. The service 511a can be thought of as a platform, application, or set of applications that provides I / O functionality related to the I / O subsystem 500 to various routines, modules, services, containers, devices, or nodes within the plant 10 (e.g., over a link or network). For example, a field device (or an I / O card coupled to a field device) may interact with the I / O service 511a by (i) receiving controller outputs from the service 511a, such as commands to activate the field device, and / or (ii) sending field device outputs to the I / O service 511a, such as measured process parameters or indices generated or calculated by the field device. Furthermore, a controller service may interact with the I / O service 511a by (i) providing I / O service 511a controller outputs (e.g., holding commands), and / or (ii) receiving controller inputs from the I / O service 511a (e.g., field device outputs representing measured process parameters). Communication between the I / O service 511a and the entities it provides services to (e.g., field devices, controller servers) can be implemented using any preferred communication model, such as the I / O service 511a being the issuer and the field devices and / or controller services being subscribers, or the I / O service 511a being the subscriber and the field devices and / or controller services being the issuers. Similarly, a pull model can be used in which the I / O service 511a is the requester and the field devices and / or controller services respond to the request, or the I / O service 511a responds to requests from the field devices and / or controller services. If necessary, a hybrid model can be used in which the I / O service 511a performs different communication roles from the field devices (e.g., issuer, subscriber, requester, responder, etc.) and controller services.

[0151] In any case, during exemplary operation, I / O service 511a receives multiple sets of controller outputs from multiple containerized controller services, each implementing the same control routine for controlling area 501. In a typical example, service 501 passes a single "active" set of controller outputs (i.e., outputs from one of the specific containerized controller services) to the relevant field device to control area 501. Furthermore, other "inactive" sets of controller outputs are not forwarded to the relevant field device. I / O server service 561a is configured similarly with respect to area 502 and can handle multiple sets of controller outputs, including an "active" set of controller outputs and one or more "inactive" sets.

[0152] At a higher level, I / O service 511a acts as an intermediary between: (i) a set of field devices 531 that perform some physical control action within the plant (e.g., including pumps, valves, and other actuating devices); a set of field devices 532 that act as transmitters that measure and transmit process variables within the plant (e.g., including sensor-based field devices); and a set of field devices 533 that potentially encapsulate a set of microcontainers that perform “custom” algorithms (such as a spectral processing microcontainer related to spectral processing within a spectrometer device, or an image processing microservice for a camera-equipped device) and generate and transmit processed I / O data for a specific application (which could be a control or maintenance application); and (ii) one or more containerized controller services 521a-c that each operate instances 525a-c of the same control routine #1 (e.g., the same configured control routine service #1), control the same set of field devices 531 and 532, and thereby control area 501. Although field device 531 is shown as a different actuating field device from field device 532, which functions as a different transmitter (e.g., of measured process parameters) from field device 533, which contains a custom algorithm or custom microcontainer for processing or manipulating process variable data, for simplicity it will be understood that for simplicity's sake, the described field devices may be capable of any or all of the following: acting on a control element (e.g., a valve stem) to manipulate process variables, measuring and transmitting measured or calculated field devices or process variables, processing or manipulating collected process data or other measurements and transmitting the processed or manipulated data. For example, a smart valve positioner may be configured to receive a command to actuate a valve and transmit measured flow rate, detected valve position, and health indicators regarding the integrity of the valve, and to process collected image data from the valve positioner's camera to detect a broken valve and transmit the processing or collected data thereof.

[0153] In some embodiments, the I / O service 511a is not containerized. However, if necessary, the I / O service 511a is containerized in an I / O server container (sometimes "I / O container") 505a. In various embodiments, the I / O subsystem 500 includes multiple I / O containers 505a-c. Each of the I / O containers 505a-c receives the same inputs (e.g., from controller services and field devices), produces the same outputs (e.g., to field devices and controller services), and implements the same logic (e.g., to evaluate which containerized controller service needs to be active, to handle transitions between controller services, etc.). Thus, if multiple I / O server containers 505a-c are implemented, one of the I / O server containers 505a-c may be designated as "active". For example, the solid and dotted lines in Figure 15 indicate that I / O container 505a is "active" and I / O server containers 505b and 505c are "inactive". In such an example, I / O container 505a forwards traffic to the controller service and field devices, but containers 505b and 505c do not. In this embodiment, all containers (including "inactive" containers) receive the same I / O data, but only "active" containers send I / O data that is received and processed by the controller service and field devices.

[0154] In some cases, an inactive I / O container does not send traffic. In other cases, each of the I / O containers 505a-c sends I / O traffic (including from inactive I / O containers), but the switch intercepts the traffic and forwards it to its destination only if it originates from an "active" I / O server container. In some cases, an "inactive" I / O server container may send data to other containers even though it is not actively functioning as an intermediate I / O server between field devices and controller services. For example, an "inactive" I / O server container may participate in load balancing operations by sending I / O traffic (e.g., controller inputs, controller outputs, etc.) to a historian or historian container, a user workstation or workstation container, another plant or external network, etc. Thus, an "inactive" I / O server can mitigate the "waste" of processing power or networking capacity that "active" I / O containers would otherwise use to perform such functions. This is particularly advantageous when the I / O containers 505a-c are distributed across two or more physical machines. Each I / O container 505a-c can be implemented on one or more physical servers as shown in Figures 16 and 17.

[0155] As described above, each of the containerized controller services 521a-c operates its respective instance 525a-c of the same control routine #1 within containers 515a-c to control the same set of field devices 531 and 532, and thereby control area 501. In some embodiments, control routine #1 may be implemented, for example, as one or more configured control routine services and / or one or more configured control function block services. Containers 515a-c may be implemented on any suitable computer device, node, or computing cluster. In some cases, one or more of the containers are implemented on a computing device in a plant environment near the field devices configured to be controlled by the corresponding controller services. In some cases, the device implementing the containers may be rack-mounted and have a form factor or housing similar to those typically found in physical process controllers. In other examples, the controller service containers are implemented by servers or computers located at a different location within the plant, such as a control room, data center, computing cluster, or remote site. Simply put, a containerized controller service can establish a suitable network connection with the field devices it controls (for example, via an I / O server service such as service 511a), and the containerized controller service can be implemented on any suitable hardware at any suitable location.

[0156] As mentioned above, each of the containerized controller services 521a-c represents the same conceptual controller implementing the same control routine #1 (each configured to read from and write to the same tag associated with the same field device). At any given time, two of the three containerized controller services 521a-c can be considered duplicate or redundant controller services to the “active” containerized controller service. Generally, each “controller service” represents a software platform or infrastructure similar to that found in a hardware controller. Each controller service is configured to recognize and execute control routines, which often have specialized and expected data formats and structures (e.g., defined by control module services, which consist of control function block services). A controller service can be thought of as a layer between the container running on the physical device and the top-level application (e.g., control routines). For this reason, a “controller service” can be thought of as similar to an operating system implemented within the container of a computing device to enable the container and computing device to properly recognize and execute the control routines. In some cases, a controller service may be an emulator that emulates a particular hardware model of a physical process controller, or may include an emulator.

[0157] A control routine or control module is a set of instructions executable by a processor to perform one or more actions to provide or perform control over at least a portion of a process. Generally, a control routine or control module can be understood as software configured to implement a particular control strategy and may be implemented within SDCS 200 as a configured control module service running in its container. A control routine or control module may include one or more interconnected control function blocks related to various functions. These function blocks may be objects in an object-oriented programming protocol that perform functions within a control scheme based on inputs to them and may provide outputs to other function blocks in the control scheme. In embodiments, a control function block may be implemented within SDCS 200 as a configured control function block service running in its container. More generally, a control routine represents logic that is executed based on one or more controller inputs (e.g., measured process variables such as temperature, pressure, or flow rate) and generates one or more controller outputs (e.g., commands for operating field devices such as control bubbles). The controller output can change or drive a process output (which may be called a "control variable" or simply a "process variable") by manipulating a process input, such as the valve position mentioned earlier (such process inputs are sometimes called "operated variables"). The control variable can be any suitable variable that the control routine intends to control. Staying in the previous example, manipulating the position of the control valve can open the inlet valve and raise the level in the tank (here the level is the control variable). Often, the control variable is measured and returned to the control routine as a controller input. The control routine can also accept as input a desired value for a control variable (i.e., a setpoint) that may be provided by the user or another control routine (e.g., the same control routine or a different control routine).Although Figure 15 does not explicitly show the set values ​​as inputs to any of the control routine instances 525a-c or 575a-c, it should be understood that each control routine instance described or shown may receive set values.

[0158] Remaining in Figure 15, during typical operation, the I / O service 511a receives process output (sometimes referred to as "field device output") or a set of process output from field device 532 via I / O channel 542a, or a set of processing data from field device 533 via I / O channel 542b. The process output can be any suitable process variable and can carry detected or calculated values ​​(e.g., indicating that the tank level variable LT004 has a value of 20% full). The I / O service 511a passes the process output to each control routine instance 525a-c as controller input via I / O channels 543a-c. That is, each of the I / O channels 543a-c is assigned a set of variables that hold the same variable or the same value or set of values ​​(e.g., indicating LT004 = 20%).

[0159] Control routine service instances 525a-c receive controller inputs and generate controller outputs (e.g., a command to open the inlet valve 75%) based on the value of the controller input (e.g., LT004=20%) and the logic of the control routine (e.g., indicating that the tank should be filled to a high level). Controller services 521a-c each send their controller outputs to I / O service 511a via I / O channels 544a-c, respectively. In other words, I / O channel 544a holds a set of outputs from control routine instance 525a, I / O channel 544b holds a set of controller outputs from control routine instance 525b, and I / O channel 544c holds a set of controller outputs from control routine instance 525c. In a typical example, the controller inputs are usually identical and instances 525a-c of control routine #1 are identical, so the sets of controller outputs are often identical (e.g., each I / O channel 544a-c may hold a command to open the inlet valve 75%). That said, if the control routine or network traffic is compromised in any way, the various sets may differ. Therefore, the I / O service 511a may implement various error checks on the received sets. In some cases, the I / O service may perform consensus analysis or a best "n" voting scheme to select a set. For example, if the first two sets received by service 511a are different, service 511a may select one of the two sets to forward based on which of the two received sets matches the third set received by service 511a.

[0160] More specifically, the I / O service 511a analyzes the set of controller outputs received and / or metadata associated with each set of controller outputs. Specifically, the QoS metrics for each set may be analyzed, and the set with the best QoS metrics may be determined to be the “active” set of controller outputs by either the I / O service 511a or some other service (e.g., the orchestrator service). The QoS metrics may be any desirable metrics for analyzing the quality of service provided by the containerized controller service, such as delay, precision, or message rate. Routines, services, containers, and I / O channels corresponding to the “best” QoS metrics may be designated as “active” (explicitly or implicitly). In embodiments, a single control routine service instance 525a-c, a single controller service 521a-c, a single container 521a-c, and a single I / O channel 44a-c may be considered “active” at a given time. The remaining control routine service instances 525a-c, controller services 521a-c, containers 521a-c, and I / O channels 544a-c may be designated or considered "inactive." I / O service 511a forwards a set of controller outputs from "active" containers and controller services to field device 531 via I / O channel 540. A set of controller outputs from "inactive" containers is not forwarded to field device but may be forwarded to other containers and / or services (e.g., data historians) for other purposes (e.g., optimizing the use of computer and / or network resources).

[0161] Remaining in Figure 15, the dotted lines indicate which routines, services, containers, and channels are inactive. As illustrated, container 515c, controller service 521c, routine service 525c, and I / O channel 544c are “active,” meaning that controller outputs generated by routine service instance 525c and passed to I / O service 511a are forwarded by I / O service 511a to field device 531 via I / O channel 540. In contrast, containers 515a and b, controller services 521a and b, routine services 525a and b, and I / O channels 544a and b are “inactive.” As a result, I / O server service 511a does not forward controller outputs from routine services 525a and b to field device 531.

[0162] As previously described, the I / O server service 561a facilitates control of area 502 in a similar manner to that described with respect to I / O service 511a and area 501. For example, service 561a acts as an intermediate node between (i) a set of field devices 581, 582, and 583 and (ii) containerized controller services 571a and 571b, which operate instances 575a and 575b of the same control routine #2, respectively, to control the same set of field devices 581, 582, and 583, thereby controlling part 502 of plant 10. The I / O server service 561a can evaluate the containerized controller services, select one "active" service, and use the controller output from the active service to control the set of field devices (therefore, control can be implemented in the process).

[0163] It will be understood that the containers illustrated in Figure 15 can be distributed across physical resources in plant 10 or other locations in any desired manner. For example, containers 515 and 505 in area 501 may be implemented on computers near or within area 501, and containers 555 and 565 in area 502 may be implemented near or on computers in area 502. However, some or all of containers 505 and / or 515 may be implemented on computers near or within area 502, and / or some or all of containers 555 and / or 565 may be implemented near or in area 501, if necessary. Alternatively, one or more of the aforementioned containers may be implemented on computers in other areas of plant 10, or at locations far from plant 10 (this may be particularly useful to ensure a seamless transition in the event of a power outage or other failure at plant 10). Furthermore, none of the aforementioned containers need to be permanently fixed or anchored to a computer cluster or node / server that happens to be running. Containers can be dynamically instantiated, deleted, and re-instantiated on different computers as needed (e.g., during or near real-time) to balance computing and network loads and mitigate computing or networking inefficiencies (e.g., when a given physical resource becomes excessively burdened by computation or network traffic). Furthermore, the total number of instances of a given container can be dynamically increased or decreased as needed. For example, if the physical resources implementing controller containers 565a and 565b appear to be excessively burdened, a third controller container for the controller #2 service can be instantiated on a new computer or physical resource (and the third container can be activated as needed). The I / O server service 561a can then continue to monitor the three containers for the controller #2 service and continuously activate the container that provides the best performance at any given time.This "juggling" between containers can be useful when computational and network workloads on physical resources fluctuate significantly. Each controller service can be containerized in a dedicated container, thereby providing a relatively isolated, consistent, and predictable environment in which each controller service is implemented, regardless of the broader software environment present on the node implementing the container. For example, a container may include the software dependencies and libraries required for a given controller service. Without containers, ensuring a consistent environment for a controller service might require properly configuring all nodes on which a controller service might run. Furthermore, ensuring proper configuration of nodes can become complex if a given node needs to be able to implement various different types of services (which may have different environment requirements). In contrast, using the controller service containers described, each controller service can be easily instantiated on a given node and easily moved between nodes / servers or between computing clusters.

[0164] Furthermore, while the above description refers to a controller service container that can be instantiated on any given node and moved between nodes / servers or computing clusters, it should be noted that the concepts and techniques can be readily applied to other types of control services, such as control module services and / or control function block services. For example, multiple instances of a configured control function block service may be instantiated on different processor cores and moved between different process cores or between different processors, and an active I / O server may select one of the multiple instances of the configured control function block and provide the output of the selected instance of the configured control function block service to each of the multiple instances of the control module service configured to operate on it. Similarly, an active I / O server may select one of the multiple instances of the configured control module service and provide the output of the selected instance of the configured control module service to each instance of the configured controller service.

[0165] In any case, referring to Figure 15, it will also be understood that each I / O channel 540-544c and 570-574b may be configured to carry a specific variable or set of variables. For example, the field device 531 may be a valve, and I / O channel 540 may always be configured to hold a control valve command (e.g., representing a desired valve position). In some cases, one or more I / O channels may be configured to carry a specific primary variable (e.g., a desired valve position) and one or more secondary variables (e.g., a valve health index, a detected valve position, a measured flow rate, a measured strain on the actuator, etc.). In any case, for example, I / O channel 540 may be referred to as controller output 540.

[0166] Figure 16 is a block diagram of a computer cluster 601 including multiple nodes or physical resources (e.g., computers, servers, networking equipment, etc.), on which one or more of the various containers, microcontainers, services, and / or routines described herein may be implemented, dynamically allocated, and load-balanced to optimize computer resource usage and performance. Specifically, cluster 601 may include physical servers 602 and 604 configured to implement one or more of the containers 515, 505, 555, and / or 565 shown in Figure 15.

[0167] Each of servers 602 and 604 may be any suitable computing device including, for example, a processor, memory, and a communication interface, and each may be located in any suitable location inside or outside plant 10. For example, Figure 17 depicts an exemplary embodiment 700 of server 602 (sometimes referred to as system / server / device 700). As shown, server 700 includes a processor 702, memory 704, and a communication interface 706. The components of server 700 may be housed in any suitable housing (not shown).

[0168] Although it has been shown that the server 700 includes a single processor 702, in various embodiments the server 700 may include multiple processors 702. In this example, a processor 702 may implement a container 505a, an I / O server service 511a, and / or I / O logic 711 (e.g., logic for performing I / O server operations or functions as described herein). A processor 702 may also implement other containers 715 (e.g., any other container shown in Figures 1, 2, 15, or 16). If necessary, any number of containers 505 and / or 715 may be instantiated and implemented in the server 700 (e.g., during uptime while load balancing is in operation).

[0169] Memory 704 may store software and / or machine-readable instructions, such as containers 505 and 715, which may be executed by processor 702. Memory 704 may include volatile and / or non-volatile memory or disks containing non-temporary computer-readable media ("CRM") for storing software and / or machine-readable instructions.

[0170] Server 700 includes one or more communication interfaces 706 configured to enable Server 700 to communicate with, for example, another device, system, host system, or any other machine. The communication interfaces 706 may include network interfaces that enable communication with other systems over one or more networks (for example, enabling Server 700 to communicate with Server 604). The communication interfaces 706 may include any suitable type of wired and / or wireless network interface configured to operate according to any suitable protocol. Examples of interfaces include TCP / IP interfaces, Wi-Fi® transceivers (compliant with the I19E 802.11 family of standards), Ethernet® transceivers, cellular network radios, satellite network radios, coaxial cable modems, wireless HART radios, or other suitable interfaces that implement any communication protocol or standard.

[0171] Returning to Figure 16, either node or server 602 or 604 may contain components similar to server 700 illustrated in Figure 17. As shown in Figure 16, containers 505 and 515 are distributed across servers 602 and 604. Note that controller service 521 may conceptually be referred to as a single “controller.” That is, when someone refers to “controller #1,” they are referring to a group of containers 515 that implement controller service 521, and controller service 521 each runs instances 525 of the same control routine service #1 to control the same set of equipment. Since orchestrator and / or I / O server service 511a may dynamically change the number of containerized controller services 521 present, dynamically change which containerized controller service 521 is active at any given time, and change which physical server implements containerized controller service 521 at any given time, a reference to “controller #1” does not necessarily refer to any specific fixed device or container. Perhaps more accurately, the specific device and container representing "Container 1" may differ at different points in time depending on the various load balancing operations and decisions made by the I / O server service 511a and the orchestrator service. In any case, the containers and servers illustrated in Figure 16 can be distributed across the physical resources and locations of Plant 10 in any desired manner.

[0172] Field device 631 may communicate with one or more of the containers 505 and / or 515 in the same manner as described with reference to field devices 531 and 532 shown in Figure 15, and may be configured in a similar manner. As shown in Figure 6, field device 631 may communicate with cluster 601 via a physical I / O module or card 614 and network switch 612.

[0173] Each I / O module or card 614 can be any suitable I / O card (sometimes referred to as an "I / O device" or "I / O module"). The I / O card 614 is typically located within the plant environment and acts as an intermediate node between the controller service and one or more field devices, enabling communication between them. Specifically, the inputs and outputs of the field devices are typically configured for analog or discrete communication. To communicate with the field devices, the controller or controller service often requires an I / O card configured for the same type of input or output utilized by the field devices. That is, for a field device configured to receive analog control signals (e.g., 4–20 mA signals), the corresponding controller or controller service may require an analog output (AO) I / O card to transmit the appropriate control signals. Similarly, for a field device configured to transmit measurements or other information via analog signals, the controller or controller service may require an analog input (AI) card to receive the transmitted information. Similarly, for field devices configured to receive discrete control signals, the controller or controller service may require discrete output (DO) I / O cards to send the appropriate control signals, and for field devices configured to transmit information via discrete signals, the controller or controller service may require discrete input (DI) I / O cards. Generally, each I / O card can be connected to the inputs or outputs of multiple field devices, and each communication link to a particular input or output is called a "channel." For example, 120-channel DO I / O cards can be communicably connected to 120 individual discrete field device inputs, allowing the controller to send discrete control output signals (via the DO I / O cards) to 120 individual discrete field device inputs.In some cases, any one or more of the I / O cards 614 are reconfigurable and enable communication with field devices configured for any type of I / O (e.g., AI, AO, DO, DI, etc.). Some field devices are not configured for communication via I / O cards. Such devices can still be connected to controller services as shown in the I / O subsystem 500. For example, some field devices communicate with the controller or controller services via Ethernet® ports and links. Some field devices communicate with the controller or controller services via a preferred wireless protocol.

[0174] In any case, the I / O card 614 can communicate with the field device 631 via a given process control protocol (e.g., HART) and with the cluster 601 via any other suitable protocol (e.g., TCP / IP). The I / O card 614 routes messages to the network switch 612 and receives messages from the network switch 612. The network switch 612 can be any suitable network switch configured to route or forward messages between the computer cluster 601 and the field device 631. In some cases, one or more of the I / O cards 614 may implement a microcontainer that implements the I / O card service. Thus, if a particular I / O card device fails and is replaced with a new I / O card device, the I / O card microcontainer can be loaded into that device and thereby quickly configured in the same manner as the previous I / O card device. As an example, in this system, a physical I / O server may have active I / O cards and also have inactive I / O cards with appropriate microcontainers instantiated to quickly take over in the event of a failure of the active I / O card. The active I / O card sends input data received from any connected device to the backup I / O card in a manner similar to the operation of the previous "active" and "inactive" I / O server containers. Importantly, in this case, both the "active" and "inactive" I / O cards (which could be, for example, a typical or known Railbus card or Emerson CHARM I / O card) need to be physically connected to the logical I / O server in order to take over the "inactive" card as the "active" card and begin receiving I / O data from the logical I / O server. An example of a microcontainer is a very lightweight containerization technique called "jailing," a well-known technical term throughout the industry where an operating system isolates microservices in a sandbox environment.

[0175] In some cases, the network switch 612 can be containerized. The container may contain the logic that the switch 612 depends on. This logic may include routing tables containing routes to addresses of field devices, I / O cards (or I / O card containers), and / or controller services. The logic may include forwarding tables that map such addresses to ports on the switch (e.g., regardless of whether the route to reach the address is known). By containerizing the logic of the switch, the network switch 612 can be instantiated on any desired suitable hardware, and the switch hardware can be quickly configured and reconfigured for any desired switch / routing operation (e.g., if the physical device of the network switch 612 is replaced).

[0176] In this embodiment, any suitable container, microcontainer, or I / O can be assigned to the computer cluster 601 and dynamically assigned and instantiated to either server 602 or server 604 depending on resource availability. This dynamic load balancing and resource allocation allows the control system to respond quickly to changes in processing load, resource availability, network constraints, etc., without loss of functionality.

[0177] Although not explicitly shown, it should be noted that the I / O subsystem 500 may include a physical I / O card and / or one or more network switches (for example, similar to those shown in Figure 16) that act as intermediaries between the field devices (531, 532, 581, 582) and the I / O server services 511a and / or 561a.

[0178] In the embodiment, when physical or logical assets are connected to the system, the I / O server service 505 automatically resolves and delegates these assets as soon as they are discovered by the discovery service. For example, a field device may have a unique field device identifier, and the control system may be configured to link the field device to one or more variable tags (e.g., representing commands configured to be received by the field device and / or parameters configured to be sent by the field device) based on the field device's unique identity. Using this unique identifier, the field device may be disconnected and reconnected to the control system, and the control system can automatically route communication between the field device and the controller service that depends on it, regardless of which hardware instantiated and implemented the controller service and where that hardware is geographically located. Similarly, each container may have a unique identifier that enables appropriate container / service routing, regardless of which particular hardware instantiated the container and where that hardware is geographically located.

[0179] Figure 18 is a flowchart of method 800 for implementing I / O server services, such as those shown in Figures 15-17. Method 800 can be implemented, in whole or in part, by the SDCS 100 / 200 and / or I / O gateway 40 shown in Figures 1 and 2, and more specifically by the I / O server services 511 / 61 shown in Figures 15-17. Thus, method 800 can be stored in memory (for example, in memory 704 shown in Figure 17) as one or more instructions or routines. For ease of explanation, the description of Figure 18 refers to service 511a of system 15 as implementing method 1800.

[0180] Method 800 begins in step 805 when a set of field device or process outputs 542a and 542b is received by the I / O server service 511a. For example, the I / O server service 511a may receive a measured flow rate of 10 gallons per minute (gpm) for the variable FT002 from the field device 532.

[0181] In step 810, the I / O server service 511a generates a set of multiple controller inputs (e.g., held via I / O channel 543) corresponding to the received sets of process outputs received via I / O channels 542a and 542b, so that each set of controller inputs holds the same set of values ​​as all other sets within the set of multiple controller inputs. Continuing with the last example, each set of controller inputs may hold the same FT002 parameter with the same value (e.g., 10 gpm). For example, the I / O server service 511a may generate a first set of controller inputs from a set of process outputs (e.g., channel 543a may be the first controller input of controller service 521a, which may represent the parameter FT002 and carry the value 10 gpm). Similarly, the I / O server service 511a may generate a second set of controller inputs from a set of process outputs (for example, channel 543b may represent a second controller input of controller service 521b, similarly representing parameter FT002, which may hold the same value 10 gpm).

[0182] In step 815, the I / O server service 511a sends each set of controller inputs (e.g., sets 543a-c) to one of several different controller services 521a-c. As shown in Figure 15, each controller service 521a-c implements a different instance (including instances 525a-c) of the same controller routine #1. Since each control routine is an instance of the same routine, they are all configured to generate the same set of controller outputs (e.g., the same set of command variables) to control the same part 501 of the process plant 10 via field devices 531 and 532, based on the same set of values ​​for the same set of controller inputs. Note that there may be any number of containerized controller services, and each set of controller inputs (each holding the same parameters and values) may constitute a containerized controller service.

[0183] In step 820, the I / O server service 511a receives sets of multiple controller outputs from one of several controller services 521a to c, each set receiving sets of multiple controller outputs via I / O channels 544a to c.

[0184] In step 825, the I / O server service 511a analyzes multiple sets of controller outputs received via metadata (e.g., delay information) associated with I / O channels 544a-c and / or sets. Specifically, it can analyze the QoS metrics for each set and identify the set with the best QoS metrics. The QoS metrics can be any desired metrics for analyzing the quality of service provided by the containerized controller service, such as delay or precision.

[0185] In step 830, the I / O server service 511a selects an active set of controller outputs based on the analysis. In an embodiment, the I / O server service 511a activates the active set of controller outputs based on the analysis. For example, service 511a may activate set 544c based on the QoS metrics associated with each container 515a~c. Service 511a may, for example, select the container or controller service with the shortest latency. In an embodiment, the service activates a given container, server, or channel after some kind of consensus has been formed. For example, it may activate a first container, server, or channel where a second container provides the same value for the set of controller outputs 544a~c. In the example, service 511a activates a container / controller service / channel using the best voting scheme from "n". In an embodiment, another service, such as an orchestrator service, performs step 830 on behalf of service 511a.

[0186] In some cases, the I / O server service 511a may check the status of one or more of the controller outputs 544a~c (for example, before or after selecting an active container). For example, service 511a may verify that the outputs have been recently updated and are not outdated. This may be done, at least in part, by cross-checking at least one set of outputs 544a~c with another set 544a~c.

[0187] In step 835, the I / O server service 511a sends an active set of controller outputs (including, for example, commands to open or close a valve) to the field device 531 to drive the process output of the industrial process (for example, a flow rate that depends on the state of the operated valve), thereby controlling a particular part 501 of the industrial process.

[0188] The I / O server service 511a may adjust the signals holding the controller input or output in any preferred manner before relaying the controller input or output from the field device to the controller service (or vice versa). The I / O server service 511a may implement analog and / or digital signal adjustment techniques. Exemplary analog signal adjustment techniques that may be implemented by the I / O server service 511a include filtering, amplification, scaling, and linearization techniques. Exemplary digital adjustment techniques that may be implemented by the I / O server service 511a include unit conversion, enumeration, encoding, and adding or editing status values ​​to the signal. Characterization or linearization functions may be implemented by the I / O server service 511a during analog or digital adjustment.

[0189] Figure 19 is a flowchart of Method 900 for evaluating and migrating between containerized controller services (or corresponding I / O channels), such as one of those shown in Figures 15–17. Method 900 can be implemented, in whole or in part, by the SDCS 100 / 200 and / or I / O gateway 40 shown in Figures 1 and 2, more specifically by the I / O server services 511 / 61 shown in Figures 15–17. Thus, Method 900 can be stored in memory (e.g., in memory 704 shown in Figure 17) as one or more instructions or routines. For ease of explanation, the description of Figure 19 refers to service 511a of system 15 as implementing Method 1900.

[0190] In step 905, the I / O server service 511a receives process control traffic via multiple I / O channels 544a to c.

[0191] In step 910, the I / O server service 511a identifies the active first I / O channel (e.g., 544c). As shown in Figure 5, service 521c and I / O channel 544c are active, while services 521a / b and I / O channels 544a / b are inactive. In this embodiment, the I / O server service 511a activates the active service 544c.

[0192] In step 915, the I / O server service 511a controls one or more field devices using process control traffic from the active I / O channel 544c. For example, consistent with the description of method 800, the service 511a may pass the received control traffic (e.g., controller output or commands) to the field device via the I / O channel 540.

[0193] In step 920, the I / O server service 511a evaluates the QoS metrics for each I / O channel 544a-c from the controller service. As already mentioned, the QoS metrics can be any desired metrics for analyzing the quality of service provided by the containerized controller service, such as latency and accuracy.

[0194] In step 925, the I / O server service 511a determines whether the highest or best QoS metric corresponds to an inactive channel. If not (i.e., it corresponds to a currently active I / O channel or controller container), the I / O server service 511a maintains the currently active I / O channel (step 930) and returns to step 910. Alternatively, if the highest or best QoS metric corresponds to an active channel, the I / O server service 511a may, in step 935, designate the inactive channel with the highest or best QoS as the active I / O channel. The I / O server service 511a then returns to step 910.

[0195] In one embodiment, each controller service tracks where each control routine is in the execution process of the control routine. For example, it may be possible to divide the control routine into phases or stages and synchronize the control routines for transitions between controller services. In an embodiment, the controller services are executed in lock steps or relative lock steps. For example, each controller service may stop after executing a particular stage or phase and wait until other controller services (or a threshold number of container services) have finished executing the same given stage before starting the next state or phase of the control routine. This execution of “lock steps” may be useful in situations where the safety of the process is a concern.

[0196] As described above, referring to Figure 2, the SD network service 220 can operate and manage logical or virtual networking utilized by the logical process control system 245, which may be implemented by the SD networking service 220 across nodes 208. The SD network service 220 can deploy and manage instances of network appliances such as virtual routers, virtual firewalls, virtual switches, virtual interfaces, and virtual data diodes, as well as instances of network services such as packet inspection services, access control services, authorization services, authentication services, encryption services, certificate authority services, and key management services, on the SDCS 200. Network services may be implemented as services or microservices.

[0197] Furthermore, the SD network service 220 may nest containers running security appliances / services within other containers running other types of services. For example, the SD network service 220 may nest security containers within a control container to perform security services related to control functions. The SD network service 220 may also nest containers running security appliances / services within other containers running security appliances / services. For example, the SD network service 220 may nest firewall containers and smart switch containers within a router container.

[0198] Furthermore, the SD Network Service 220 may deploy N redundant instances of a container running a security appliance / service within the SDCS 200. For example, the SD Network Service 220 may deploy a first instance of a firewall container to receive incoming data packets and send outgoing data packets, and a second instance of the firewall container to receive incoming data packets and send outgoing data packets. The SD Network Service 220 may deploy both the first and second instances of the firewall container to receive incoming data packets from the same source (e.g., a control service). However, while the first instance of the firewall container may send outgoing data packets to a remote system outside the SDCS 200, the SD Network Service 220 does not configure the second instance of the firewall to send outgoing data packets to a remote system. Instead, the SD Network Service 220 may configure the second instance of the firewall to send outgoing data packets to a monitoring system within the SDCS 200, or to send instructions to the monitoring system within the SDCS 200 on how incoming data packets were processed. In this way, the SD network service 220 can monitor whether the firewall function is being performed properly.

[0199] Figure 20 shows a block diagram of exemplary containers, services, and / or subsystems related to network security. As shown in Figure 20, the SDCS includes a container that runs the network service 1002, similar to the SD network service 220 illustrated in Figure 2. The network service 1002 deploys and manages a first instance of router container 1004 and a second instance of router container 1006. The first router container 1004 runs the first security service 1008, and the second router container 1006 runs the second security service 1010. The network service 1002 may deploy the first router container 1004 and connect it to a first unit container 1012 which has a first tank container 1014 and a first control container 1016. The network service 1002 may also deploy the first router container 1004 and connect it to a first I / O server container 1018. In this way, the first router container 1004 can facilitate communication between the first unit container 1012 and the first I / O server container 1018. The first security service 1008 may include a first set of security rules for routing communication between the first unit container 1012 and the first I / O server container 1018.

[0200] The network service 1002 may deploy a second router container 1006 and connect to a second unit container 1020 having a first mixer container 1022 and a second control container 1024. The network service 1002 may also deploy a second router container 1006 and connect to a second I / O server container 1026. In this way, the second router container 1006 can facilitate communication between the first unit container 1020 and the second I / O server container 1026. The second security service 1010 may include a second set of security rules for routing communication between the second unit container 1020 and the second I / O server container 1026.

[0201] SDCS may also include a container running the Certificate Authority Service 1028. Furthermore, SDCS may include physical or logical assets of the process plant 10 that are utilized during the uptime of the process plant 10 to control at least a portion of the industrial process, such as field devices, controllers, process control devices, I / O devices, compute nodes, containers, services (e.g., control services), and microservices. The physical or logical assets may request a digital certificate, such as a public key infrastructure (PKI) certificate, from the Certificate Authority Service 1028 to prove their authenticity when communicating with the SDCS. When a physical or logical asset requests a certificate, the Certificate Authority Service 1028 obtains the identification information of the physical or logical asset and verifies the identity of the physical or logical asset based on that information. The Certificate Authority Service 1028 then generates a certificate for the physical or logical asset that may include the cryptographic public key or other identifier of the physical or logical asset, the identifier of the Certificate Authority Service 1028, and the digital signature of the Certificate Authority Service 1028 to prove that the certificate was generated by the Certificate Authority Service 1028. Certificate Authority Service 1028 provides certificates to physical or logical assets that can use certificates for authentication purposes when communicating with other nodes or services within SDCS. In some implementations, other services may encrypt communications with the physical or logical asset using the cryptographic public key of the physical or logical asset contained in the certificate.

[0202] In some implementations, users within the SDCS may request a digital certificate from the Certificate Authority service 1028 (such as a plant operator, configuration engineer, and / or other personnel associated with the industrial process plant 10). When a user requests a digital certificate, they may provide identification information such as their name, address, telephone number, role within the industrial process plant 10, username, and password. The Certificate Authority service 1028 may verify the user's identity, for example, by comparing the identification information obtained from the user with the user's identification information obtained from other sources. If the Certificate Authority service 1028 can verify the user, it generates and provides a digital certificate to the user. In this way, the user can provide a digital certificate to access nodes or services within the SDCS without having to enter login information. In some implementations, the Certificate Authority service 1028 may include user authorization information in the certificate. The SDCS may assign an authorization level to the user based on their role within the industrial process plant 10. Next, the Certificate Authority service 1028 may generate different types of certificates for different authorization levels and / or roles within the industrial process plant 10. In this way, a node or service that a user attempts to access may determine the user's authorization level and / or role within the industrial process plant 10 based on the type of certificate provided by the user. The node or service may then determine whether the user is authorized to access the node or service based on the user's authorization level and / or role within the industrial process plant 10. In some implementations, a user may have partial access to a node or service based on their authorization level and / or role within the industrial process plant 10. Thus, a node or service may provide a user with access to some parts of the node or service while preventing the user from accessing other parts of the node or service.

[0203] In some implementations, users may be defined by roles protected by digital certificates. For example, the role of a process manager may correspond to a first authorization level with a first set of digital certificates, which is different from the role of an operator, which corresponds to a second authorization level with a second set of digital certificates.

[0204] Security services 1008 and 1010 are contained within router containers 1004 and 1006, which facilitate communication between the control service and I / O service in Figure 20, but this is merely one example of an implementation. Additionally or alternatively, security services may be nested within containers that run other types of services, such as control services and I / O services. Figure 21 shows a block diagram of an additional or alternative implementation of the SDCS in Figure 20. As shown in Figure 21, in addition to deploying the first security service 1008 and the second security service 1010 within the first and second router containers 1004 and 1006, respectively, the network service 1002 deploys the third security service 1102 within a container (security container) running within the first control container 1116, and the fourth security service 1104 within a container (security container) running within the second control container 1124. The third security container 1102 may have content that defines security conditions, such as a set of security rules. Furthermore, the fourth security container 1104 may also have content that defines security conditions, such as a set of security rules, which may be the same as or different from the content of the third security container 1102. The content may also include the control strategy of the corresponding control container, such as control history and storage.

[0205] In this way, the third security service 1102 may include a third set of security rules specific to the first control container 1116 that do not necessarily apply to other services or nodes connected to the router container. Furthermore, the third security service 1102 may encrypt the data generated by the first control container 1116 before it is transmitted over the communication network. This may provide an additional layer of security before the data reaches the router container. Although security services 1102 and 1104 are nested in the control container in Figure 21, the security services may be nested in any suitable container, such as an I / O server container or an operator workstation container.

[0206] Figure 22 shows a detailed block diagram of the first router container 1004 in Figure 20. The router container may contain security appliances or services nested within it. Furthermore, each security appliance or service may contain additional services nested within it. The router container may include a first firewall container 1202 running a first security service 1204, a first data diode container 1206 running a second security service 1208, a first smart switch container 1210 running a third security service 1212, and a packet inspection service 1214.

[0207] The first security service 1204 may include a first set of security rules for the first firewall container 1202, such as an allow list or accept list that allows data to be sent / received by a given node or service while preventing other connection types or ports. The first set of security rules may only allow authorized traffic to be sent from the first router container 1004. For example, the first security service 1204 may prevent data from an external source to be sent to the control container for the process plant 10.

[0208] The second security service 1208 may allow data traffic to enter and exit the SDCS from the remote system, and may prevent data traffic (e.g., data sent or received from the remote system or other systems) from entering the SDCS. Therefore, the second security service 1208 supports only one-way data flow from the virtual input port to the virtual output port via software, for example, by dropping or blocking any messages received (e.g., from the remote system) at the virtual output port, and / or by dropping or blocking any messages addressed to the virtual input port (e.g., addressed from the remote system to a node or service in the SDCS). The second security service 1208 may also encrypt data sent from the SDCS to the remote system.

[0209] The third security service 1208 can determine the network address of a node or service intended to receive data packets and can send data packets to the node or service via the network address. For example, if a control container sends data to an I / O server container via a router container, the third security service 1208 identifies the network address of the I / O server container and sends the data to the I / O server container via this network address. The third security service 1208 can assign a network address to each node or service connected to the router container and determine the network address assigned to a node or service intended to receive data packets.

[0210] The packet inspection service 1214 can identify patterns in network data flowing through the router container by inspecting the contents of packets as they flow through the router container. Next, the packet inspection service 1214 can use known traffic patterns to determine whether a particular service or node is experiencing abnormal behavior. Then, the packet inspection service 1214 can identify the service or node as suspicious and flag them for action. The packet inspection service 1214 can also perform diagnostic actions to determine possible causes of the abnormal behavior. The router container in Figure 22 includes a first firewall container 1202, a first data diode container 1206, a first smart switch container 1210, and the packet inspection service 1214, but this is merely an example implementation for the sake of illustration. The router container may include any suitable security appliances and / or services.

[0211] In some implementations, the network service may deploy a firewall service along with each control service running within the SDCS. The firewall service may run in a container nested within the container running the corresponding control service. In other implementations, the firewall service may run in a standalone container assigned to the corresponding control service. As shown in Figure 23, the network service deploys a first firewall container 1302 to manage network traffic to and from the first control container 1304, and a second firewall container 1308 to manage network traffic to and from the second control container 1310. A control configuration database 1306, which may be managed by the SD storage service 218, may provide a first control configuration to the first control container 1304. The control configuration database 1306 may also provide a first set of customized firewall rules to the first firewall container 1302 assigned to the first control container 1304. Furthermore, the control configuration database 1306 may provide a second control configuration to the second control container 1310. The control configuration database 1306 may provide a second set of customized firewall rules to the second firewall container 1308 for the assigned second control container 1310. In other implementations, the control configuration service communicates with the control configuration database 1306 to provide control configurations to control containers 1304 and 1310 and customized firewall rules to firewall containers 1302 and 1308.

[0212] For example, a first set of customized firewall rules might include an allow list or accept list that permits the first control container 1304 to receive data and send it to the first I / O server, but does not permit the first control container 1304 to receive or send data to any other node or service. In another example, a first set of customized firewall rules might include an allow list or accept list that allows the first control container 1304 to send and receive data to a specific network address of a remote system outside of the SDCS. In yet another example, a first set of customized firewall rules might include an allow list or accept list of services or nodes permitted to access data from the first control container 1304, and prevent services or nodes not included in the allow list or accept list from accessing data from the control container. Customized firewall rules can be dynamic in that firewall containers 1302 and 1308 may receive different firewall rules from the control configuration service based on future changes to the configuration of control containers 1304 and 1310.

[0213] As described above, the security services described herein may include packet inspection services, access control services, authorization services, authentication services, encryption services, certification authority services, key management services, and the like. Figure 24 shows a detailed block diagram of a security container 1404 nested within a control container 1402, similar to the configuration illustrated in Figure 21. The security container 1404 may include an encryption service 1406, an authentication service 1408, and an authorization service 1410. In this way, the security container 1404 may encrypt data transmitted by the control container 1402. The security container 1404 may also authenticate and / or authorize physical or logical assets or users attempting to access the control container 1402.

[0214] For example, when a physical or logical asset or user attempts to access the control container 1402, the authentication service 1408 may verify the authenticity of the physical or logical asset or user attempting to access the control container 1402. For example, the authentication service 1408 may verify the authenticity of the physical or logical asset or user by obtaining a digital certificate issued by a Certificate Authority from the physical or logical asset or user. The digital certificate may include the cryptographic public key or other identifier of the physical or logical asset, an identifier of the Certificate Authority service, and a digital signature of the Certificate Authority service certifying that the certificate was generated by the Certificate Authority service. In some implementations, the authentication service 1408 analyzes the identifier of the Certificate Authority service and the digital signature of the Certificate Authority service to determine whether the certificate was generated by the Certificate Authority service. In other implementations, the authentication service 1408 sends the digital certificate to the Certificate Authority service in the SDCS to determine whether the certificate was generated by the Certificate Authority service.

[0215] If the authentication service 1408 can verify the authenticity of a physical or logical asset or user, the authorization service 1410 may determine the authentication level of the physical or logical asset or user. On the other hand, if the authentication service 1408 cannot verify the authenticity of a physical or logical asset or user, the authentication service 1408 may deny access to the control container 1402.

[0216] In any case, the authentication service 1410 determines, based on the authentication level of the physical or logical asset or user, whether the physical or logical asset or user is authorized to access the control container 1402. If the physical or logical asset or user has an authentication level that meets or exceeds the minimum authentication level required to access the control container 1402, the authorization service 1410 determines that the physical or logical asset or user is authorized to access the control container 1402. Otherwise, the authorization service 1410 may deny access to the control container 1402.

[0217] In some implementations, the authorization level of a physical or logical asset or user is included in the certificate. Different types of certificates may indicate different authorization levels and / or roles within the industrial process plant 10. Thus, the authorization service 1410 may determine the authorization level of a physical or logical asset or user based on the certificate. In other implementations, the authorization service 1410 retrieves a pre-stored authorization level of a physical or logical asset or user from a logical storage resource and determines the authorization level of the physical or logical asset based on the pre-stored authorization level. In some implementations, a physical or logical asset or user may have partial access to the control container 1402 based on their authorization level. Thus, the control container 1402 may provide a physical or logical asset or user with access to certain parts of the control container 1402 while preventing the physical or logical asset or user from accessing other parts of the control container 1402.

[0218] In any case, in response to authentication and authorization of a physical or logical asset or user, the encryption service 1406 may encrypt data from the control container 1402 to the physical or logical asset or user using the encryption public key contained in the certificate. The physical or logical asset or user may then decrypt the data using the encryption private key paired with the encryption public key. If the physical or logical asset or user does not possess the encryption private key paired with the encryption public key, the physical or logical asset or user cannot decrypt the data, which is another form of authentication.

[0219] The access control service may include, in addition to the authorization or authentication service described above, allow lists or accept lists, and / or other services that permit data to be received / transmitted by a given node or service and prevent other nodes or services from receiving or transmitting data within the process control network. The key management service stores and / or can access a record of the cryptographic public key associated with each physical or logical asset in the process plant 10. In other implementations, the key management service retrieves a record of the cryptographic public key from the discovered item data store, as further described below. Next, if a physical or logical asset needs to be authenticated, the physical or logical asset provides its cryptographic public key to the authentication service. The authentication service calls the key management service to retrieve a record from the discovered item data store and determines whether the cryptographic public key provided to the physical or logical asset matches the cryptographic public key contained in the discovered item data store.

[0220] The key management service may also store encryption private keys and / or PSKs for physical or logical assets within the process plant 10. Furthermore, the key management service may store certificates for physical or logical assets in the process plant 10. The key management service may password-protect and / or encrypt the keys and certificates so that users or physical or logical assets must authenticate themselves before accessing their respective keys or certificates.

[0221] In the exemplary router container of Figure 22, the router container can facilitate communication between nodes or services within the SDCS, or between nodes or services within the SDCS and remote systems outside the SDCS. Figure 25 shows a block diagram of an exemplary router container 1502 for facilitating communication between nodes or services within the SDCS and remote systems outside the SDCS. The router container 1502 may include a field gateway container 1504 running a first encryption service 1506, a data diode container 1508 running a second encryption service 1510, and an edge gateway container 1512 running a firewall service 1514 and an authentication service 1516.

[0222] The field gateway container 1504 can communicate with nodes or services within the field environment 12 of the process plant, such as process control devices, field devices, and control services. For example, the field gateway container 1504 may include firewall service rules with a firewall that allows traffic only from nodes or services in the field environment 12 of the process plant. The field gateway container 1504 may also run a first encryption service 1506 to encrypt data from the field environment 12 of the process plant. The field gateway container 1504 may then transmit the data to the data diode container 1508.

[0223] The data diode container 1508 may allow data traffic to leave the field gateway container 1504 for the remote system and prevent data traffic (e.g., this is sent or received from the remote system or another system) from entering the field gateway container 1504. Thus, the data diode container 1508 supports only one-way data flow from the field gateway container 1504 to the edge gateway container 1512 via software, for example, by dropping or blocking messages received at the edge gateway container 1512 (e.g., from the remote system) and / or by dropping or blocking messages destined for the field gateway container 1504 (e.g., destined for a node or service in the SDCS from the remote system). The second encryption service 1510 may also encrypt data from the field gateway container 1504 in addition to, or instead of, the first encryption service 1506. The data diode container 1508 may then send the encrypted data to the edge gateway container 1512.

[0224] In some implementations, during instantiation, the data diode container 1508 may allow a temporary handshake (e.g., exchange of certificates and pre-shared keys) between entities sending data to and from the process plant 10 via the data diode container 1508 (e.g., field gateway container 1504 and edge gateway container 1512) in order to properly establish an encrypted connection, such as in Datagram Transport Layer Security (DTLS) or other message-oriented security protocols. Once the DTLS handshake is complete, the connection is established, and from that point onward, the data diode container 1508 supports only one-way data flow for the remainder of the data diode container 1508's life, for example, from field gateway container 1504 to edge gateway container 1512. If there are connection problems between entities at the input and output ends of the data diode container 1508, the data diode container 1508 may need to be restarted to allow the DTLS handshake to be performed again.

[0225] The edge gateway container 1512 can communicate with a remote system outside the process plant 10. The edge gateway container 1512 may include a firewall service 1514 with firewall rules that allow only traffic from a given remote system. The edge gateway container 1512 may also perform an authentication service to authenticate remote systems communicating with the edge gateway container 1512. For example, traffic delivered from the edge gateway container 1512 to a remote system may be protected via a Shared Access Signature (SAS) token, which may be managed through a token service provided by the remote system 210. The edge gateway container 1512 authenticates the token service and requests a SAS token, which may be valid only for a limited period, e.g., within 2 minutes, 5 minutes, 30 minutes, or 1 hour. The edge gateway container 1512 receives and uses the SAS token to protect and authenticate the AMQP (Advanced Message Queuing Protocol) connection to the remote system through the transmission of content data from the edge gateway container 1512 to the remote system. Additionally or alternatively, other security mechanisms may be used to protect data passing between the edge gateway container 1512 and the remote system 210, such as X.509 certificates, other types of tokens, or other IoT protocols like MQTT (MQ Telemetry Transport) or XMPP (Extensible Messaging and Presence Protocol). The edge gateway container 1512 can then send the data to the remote system.

[0226] As described above, to prove authenticity when communicating over SDCS, a physical or logical asset or user may request a digital certificate from the Certificate Authority (CA) service. Figure 26 shows a detailed block diagram of a CA container 1602 similar to the CA container 1028 shown in Figure 20. The CA container 1602 may include a certificate generation service 1604 and a certificate verification service 1606.

[0227] The certificate generation service 1604 may generate a digital certificate for a physical or logical asset, for example, when it receives a request from the physical or logical asset. Upon receiving a request, the certificate generation service 1604 retrieves the identification information of the physical or logical asset and verifies the identity of the physical or logical asset based on that identification information. For example, the request may include the name of the physical or logical asset, the manufacturer and model of the physical or logical asset, the cryptographic public key associated with the cryptographic private key owned by the physical or logical asset, or any other suitable identification information. The certificate generation service 1604 may verify the identity of the physical or logical asset, for example, by comparing the identification information obtained from the physical or logical asset with the identification information of the physical or logical asset obtained from another source. If the certificate generation service 1604 cannot verify the identity of the physical or logical asset, the certificate generation service 1604 does not generate a certificate for the physical or logical asset.

[0228] On the other hand, if the certificate generation service 1604 can verify the identity of the physical or logical asset, the certificate generation service 1604 generates a certificate for the physical or logical asset, which may include the cryptographic public key or other identifier of the physical or logical asset, an identifier of the Certificate Authority service 1602 such as the cryptographic public key, and a digital signature by the Certificate Authority service 1602 to prove that the certificate was generated by the Certificate Authority service 1602. The certificate generation service 1604 provides the certificate to the physical or logical asset, which can use the certificate for authentication purposes when communicating with other nodes or services in the SDCS. In some implementations, other services may use the cryptographic public key of the physical or logical asset contained in the certificate to encrypt their communication with the physical or logical asset.

[0229] Furthermore, in some implementations, users within the SDCS may request a digital certificate from the certificate generation service 1604 (such as plant operators, configuration engineers, and / or other personnel associated with the industrial process plant 10). When a user requests a digital certificate, they may provide identification information such as their name, address, telephone number, role within the industrial process plant 10, username, and password. The certificate generation service 1604 may verify the user's identity, for example, by comparing the identification information obtained from the user with the user's identification information obtained from other sources.

[0230] If the certificate generation service 1604 cannot verify the user, the certificate generation service 1604 does not generate a certificate for the user. On the other hand, if the certificate generation service 1604 can verify the user, the certificate generation service 1604 generates a digital certificate and provides it to the user. In this way, the user can provide a digital certificate to access a node or service in SDCS without having to enter login information. In some implementations, the certificate generation service 1604 may include user authorization information in the certificate. SDCS may assign an authorization level to the user based on the user's role within the industrial process plant 10. The certificate generation service 1604 may then generate different types of certificates for different authorization levels and / or roles within the industrial process plant 10. In this way, the node or service that the user attempts to access may determine the user's authorization level and / or role within the industrial process plant 10 based on the type of certificate provided by the user.

[0231] When a physical or logical asset or user attempts to access a node or service within the SDCS, the node or service may submit a request to the certificate verification service 1606 to authenticate the physical or logical asset or user. More specifically, the physical or logical asset or user may provide a certificate to a node or service that can transfer the certificate to the certificate verification service 1606. In some implementations, the certificate verification service 1606 analyzes the identifier of the Certificate Authority (CA) service contained in the certificate and the digital signature of the CA service contained in the certificate to determine whether the certificate was generated by a CA service. For example, the certificate verification service 1606 may determine whether the Cryptographic Public Key of the CA contained in the certificate matches the Cryptographic Public Key of the CA. Furthermore, the certificate verification service 1606 may determine whether the digital signature proves that the entity generating the certificate possesses the Cryptographic Private Key associated with the Cryptographic Public Key. If both of these are true, the certificate verification service 1606 may determine that the certificate was generated by a CA service.

[0232] Next, the certificate validation service 1606 may indicate to a node or service that a physical or logical asset or user has been authenticated. Additionally or alternatively, if the certificate includes an instruction for the user's level of authorization, the certificate validation service 1606 may provide an authorization level instruction to the node or service.

[0233] Figure 27 shows exemplary examples of authentication and authorization services that may be included in a node or service of SDCS, such as a control container and an operator workstation container (e.g., a virtual workstation). As illustrated in Figure 27, the control container 1702 includes a first authentication service 1704, and the operator workstation container 1706 includes a second authentication service 1708 and an authorization service 1710.

[0234] The control container 1702 may receive access requests from physical or logical assets, and these requests may include certificates. Therefore, the first authentication service 1704 may authenticate the physical or logical assets using the certificates. In some implementations, the first authentication service 1704 may provide certificates to a Certificate Authority service, such as the Certificate Authority service 1602 shown in Figure 26, in order to authenticate the physical or logical assets. In any case, when authenticating a physical or logical asset, the first authentication service 1704 may grant access to the control container 1702. Otherwise, the first authentication service 1704 may deny access to the control container 1702.

[0235] The operator workstation container 1706 may receive access requests from users if the requests include certificates. Therefore, the second authentication service 1708 may authenticate the user using the certificates. In some implementations, the second authentication service 1708 may provide certificates to a Certificate Authority service, such as the Certificate Authority service 1602 shown in Figure 26, in order to authenticate the user. In any case, once the user is authenticated, the first authentication service 1704 may provide the operator workstation container 1706 with an indication that the user has been authenticated.

[0236] Next, the authorization service 1710 determines, based on the user's authorization level, whether the user is authorized to access the operator workstation container 1706. If the user has an authorization level that meets or exceeds the minimum authorization level required to access the operator workstation container 1706, the authorization service 1710 determines that the user is authorized to access the operator workstation container 1706. Otherwise, the authorization service 1710 may deny access to the operator workstation container 1706.

[0237] In some implementations, the user's authorization level is included in the certificate. Different types of certificates for different authorization levels and / or roles within the industrial process plant 10. Thus, the authorization service 1710 may determine the user's authorization level based on the certificate. In other implementations, the authorization service 1710 retrieves the user's pre-stored authorization level from a logical storage resource and determines the user's authorization level based on the pre-stored authorization level. In some implementations, the user may have partial access to the operator workstation container 1706 based on their authorization level. Thus, the operator workstation container 1706 may provide the user with access to some parts of the operator workstation container 1706 and prevent the user from accessing other parts of the operator workstation container 1706.

[0238] In addition to encrypting network communications in SDCS, SDCS also encrypts logical storage resources. Figure 28 shows a block diagram of an exemplary storage service 1802, which includes encryption service 1804 and authentication service 1806.

[0239] When the storage service 1802 stores a logical storage resource in the SDCS, the encryption service 1804 encrypts the data contained in the logical storage resource. Next, when a physical or logical asset or user attempts to access the logical storage resource, the authentication service 1806 authenticates the physical or logical asset or user. For example, the authentication service 1806 may authenticate the physical or logical asset or user based on a certificate issued by a certification authority. If the authentication service 1806 can authenticate the physical or logical asset or user, the storage service 1802 may decrypt the data contained in the logical storage resource and provide the decrypted logical storage resource to the physical or logical asset or user. Otherwise, the storage service 1802 does not decrypt the data of the physical or logical asset or user.

[0240] Figure 29 shows a flowchart illustrating an exemplary method 1900 for protecting the process control system of a process plant. The method may be implemented by a software-defined network service, a security container, or any preferred combination thereof.

[0241] In block 1902, the software-defined network service generates a security service configured to run via a container on a compute node within the SDCS. For example, the security service may include a virtual router, virtual firewall, virtual switch, virtual interface, virtual data diode, packet inspection service, access control service, authorization service, authentication service, encryption service, certificate authority service, key management service, or any other suitable security-related service.

[0242] Next, in block 1904, the software-defined network service instantiates an instance of the security container to run in the control container. The instance of the security container can be a primary instance. The software-defined network service can also instantiate, for example, N redundant instances of the security container to simulate operations in the control container without actually controlling access to or data flow from the control container. In some implementations, the software-defined network service nests the security container within the control container. In additional or alternative implementations, the software-defined network service anchors the security container to the same compute node on which the control container runs. In other implementations, the security container is a standalone container assigned to the control container.

[0243] In block 1906, the software-defined network service assigns security conditions to the security container according to the control container. For example, the control configuration service may retrieve the control configuration from the control configuration storage resource and provide the control configuration to the control container. The control configuration storage resource may also include a set of firewall rules customized for the control container. The software-defined network service may retrieve the set of firewall rules customized for the control container from the control configuration service and assign the set of customized firewall rules to the security container as security conditions. The software-defined network service may also assign other security conditions depending on the control container, such as authenticating physical or logical assets or users attempting to access the control container, requiring users to have an authorization level that exceeds or exceeds a minimum threshold authorization level, preventing access from remote systems outside the process plant 10, or preventing incoming data from remote systems outside the process plant 10.

[0244] In some implementations, a software-defined network service may update the contents of a security container by assigning alternative or additional security conditions to it. For example, initially, the software-defined network service may assign a first set of security rules to the security container. Subsequently, the software-defined network service may retrieve the updated control configuration of the control container. The software-defined network service may also retrieve the updated firewall rules of the control container due to a change in the control configuration and assign the updated firewall rules to the security container as security conditions.

[0245] In block 1908, the security container controls access to and / or data flow from the control container based on the security conditions assigned to the security container. For example, the security container may prevent nodes or services not included in an allow list or accept list from communicating with the control container.

[0246] Figure 30 shows a flowchart illustrating an exemplary method for role-based authorization in SDCS. The method can be implemented by a security container or an authorization service.

[0247] In block 2002, a security service running via a container on a compute node within the SDCS obtains requests from the user to access other services or nodes within the SDCS, such as a control container. In some implementations, the security service may obtain requests from physical or logical assets of the process plant 10 controlled by the user. In some implementations, the requests may also include a certificate provided by the user to verify the user's authenticity and to include user authorization information.

[0248] In block 2004, the security service determines the user's authorization level. For example, the user's authorization level may be included in a certificate. Different types of certificates may indicate different authorization levels and / or roles within the industrial process plant 10. Therefore, the security service may determine the user's authorization level based on the certificate. In other implementations, the security service retrieves the user's pre-stored authorization level from a logical storage resource and determines the authorization level of a physical or logical asset based on the pre-stored authorization level.

[0249] In block 2006, the security service determines, based on the authorization level, whether a user is authorized to access other services or nodes. For example, if a user has an authorization level equal to or higher than the minimum authorization level required to access other services or nodes within the SDCS, the security service determines that the user is authorized to access those services or nodes. Therefore, the security service grants the user access to other services or nodes, such as the control container (block 2008). Otherwise, the security service may deny access to those services or nodes (block 2010).

[0250] Figure 31 shows a flowchart illustrating an exemplary method 2100 for generating a digital certificate by a Certificate Authority service to authenticate the physical or logical assets of a process plant 10. The method may be performed by a Certificate Authority service.

[0251] In block 2102, the Certificate Authority (CA) service obtains a certificate request from a physical or logical asset of the process plant 10. Upon receiving the request, the CA service obtains the identification information of the physical or logical asset and verifies the identity of the physical or logical asset based on the identification information (block 2104). For example, the request may include the name of the physical or logical asset, the manufacturer and model of the physical or logical asset, the cryptographic public key associated with the cryptographic private key owned by the physical or logical asset, or any other suitable identification information. The CA service may verify the identity of the physical or logical asset, for example, by comparing the identification information obtained from the physical or logical asset with the identification information of the physical or logical asset obtained from other sources. If the CA service cannot verify the identity of the physical or logical asset, the CA service does not generate a certificate for the physical or logical asset.

[0252] On the other hand, if the Certificate Authority (CA) service can verify the identity of a physical or logical asset, the CA service generates a certificate for the physical or logical asset, which may include the cryptographic public key or other identifier of the physical or logical asset, an identifier of the CA service such as a cryptographic public key, and a digital signature by the CA service to prove that the certificate was generated by the CA service (block 2106). The CA service provides the certificate to the physical or logical asset, which can use the certificate for authentication purposes when communicating with other nodes or services in the SDCS (block 2108). In some implementations, other services may use the cryptographic public key of the physical or logical asset contained in the certificate to encrypt their communication with the physical or logical asset.

[0253] Figure 32 shows a flowchart representing an exemplary method 2200 for authenticating the physical or logical assets of the process plant 10. The method may be performed by security services, authentication services, or a preferred combination thereof.

[0254] In block 2202, a security service running via a container on a compute node within the SDCS receives requests from a physical or logical asset to access another service or node within the SDCS. These requests may include certificates provided by the physical or logical asset to verify its authenticity.

[0255] In block 2204, the authentication service, running via a container on a compute node within the SDCS, verifies the authenticity of physical or logical assets based on certificates. For example, the authentication service analyzes the identifier of the Certificate Authority (CA) service contained in the certificate, and the digital signature of the CA service contained in the certificate, to determine whether the certificate was generated by the CA service. In other implementations, the authentication service provides certificates to the CA service to verify the authenticity of physical or logical assets.

[0256] If the authentication service can verify the authenticity of a physical or logical asset or user (block 2208), the security service may provide access to other services or nodes. On the other hand, if the authentication service cannot verify the authenticity of a physical or logical asset, the security service may deny access to other services or nodes (block 2210).

[0257] SDCS may also include discovery services that run via containers on the SDCS compute nodes. The discovery services store records of the identity, capabilities, and / or location of each physical or logical asset within the process plant 10, which can be used during the uptime of the process plant 10 to control at least a portion of the industrial process, such as field devices, controllers, process control devices, I / O devices, compute nodes, containers, services (e.g., control services), microservices, etc.

[0258] In some implementations, the discovery service may store records in the discovered items datastore. For redundancy / fault tolerance, the SDCS may include multiple instances of the discovered items datastore stored on multiple compute nodes. In other implementations, for ease of access and speed, instances of the discovered items datastore may be stored on each compute node within the SDCS.

[0259] Furthermore, in some implementations, the discovery service may provide records or at least a portion thereof to the I / O server service for commissioning physical or logical assets. For example, when a physical or logical asset joins the network 22, 25, 30, 32, 35, 42-58 of the process plant 10, the physical or logical asset announces its presence. The announcement may include parameters such as the identification information of the physical or logical asset and the location information of the physical or logical asset, such as the network address for communicating with the physical or logical asset. The discovery service or any other suitable service may take the announcement and send the identification information and location information of the physical or logical asset to the I / O server service to automatically commission the physical or logical asset using the identification information and location information.

[0260] Figure 33 shows a block diagram of exemplary containers, services, and / or subsystems related to discovery. As shown in Figure 33, the SDCS includes a container that runs the discovery service 2302. The discovery service 2302 shown in Figure 33 runs within a container (discovery container), but in other implementations, the discovery service 2302 may not be containerized. Also, in some implementations, the SDCS may include multiple instances of the discovery service 2302 in multiple containers for redundancy. In some implementations, the discovery service 2302 may be deployed by the SD network service 220 or nested within the SD network service 220 in Figure 2.

[0261] SDCS also includes a discovered item data store 2304, which is a logical storage resource that stores a record of each physical or logical asset discovered in the process plant 10. When a physical or logical asset is discovered, the discovery service 2302 may store a record of the physical or logical asset in the discovered item data store 2304.

[0262] When a new physical or logical asset is added to the networks 22, 25, 30, 32, 35, 42 to 58 (also referred to as "process plant networks" in this specification) within the process plant 10, the new physical or logical asset may announce its presence, for example, by broadcasting its network address to nodes or services connected to the process plant networks 22, 25, 30, 32, 35, 42 to 58. In other implementations, the new physical or logical asset may announce its presence, for example, by responding to a multicast announcement from a specific node or service connected to the process plant networks 22, 25, 30, 32, 35, 42 to 58. In yet other implementations, the new physical or logical asset may announce its network address to a reserved point-to-point network address or a multicast address. The new physical or logical asset may announce its network address once, periodically, in response to a request, or in any suitable manner.

[0263] Physical assets within the process plant 10 can be physical hardware devices configured to control at least a portion of an industrial process, such as field devices, controllers, process control devices, I / O devices, computing nodes, etc., during the operating hours of the process plant 10. The physical hardware device can include respective sets of processor and / or processor core resources and memory resources. Logical assets within the process plant 10 can be software configured to control at least a portion of an industrial process, such as services like containers, control services, microservices, etc., during the operating hours of the process plant 10. In some implementations, the logical asset can be executed within a physical asset.

[0264] The discovery service 2302 can obtain an announcement and determine the identity of a physical or logical asset based on the parameters of the physical or logical assets included in the announcement. The announcement may include a YAML file that defines each physical or logical asset. The YAML file can be generated manually or automatically, for example, when the SDCS has been previously commissioned / configured. In other implementations, the announcement may include different types of files such as a JSON file, an XML file, or any other data serialization file.

[0265] More specifically, the announcement may include the asset tag of the physical or logical asset, the media access control (MAC) address of the physical or logical asset, the network address of the physical or logical asset, the encryption key asset of the physical or logical asset, the serial number of the physical or logical asset, and / or the name of the service or subsystem associated with the physical or logical asset. Some of the parameters may uniquely identify a physical or logical asset, such as a MAC address, while other parameters, such as a serial number, may correspond to multiple assets with the same manufacturer and model. Therefore, the discovery service 2302 can identify a physical or logical asset based on any suitable combination of the parameters included in the announcement. For example, two physical or logical assets can be valves that have the same serial number, which is a part number. The two valves can be identified based on the combination of the serial numbers and encryption keys of the two valves.

[0266] An asset tag can be a name or number assigned / configured to a physical or logical asset, and can uniquely identify a particular physical or logical asset within the SDCS, or more generally, an asset type. For example, if the physical asset is a control valve, the asset tag might be "control valve," and the process plant 10 may include multiple control valves with the same asset tag. In other implementations, the asset tag might be "control valve-01" to uniquely identify a particular control valve, and other control valves might be "control valve-02," "control valve-03," and so on. In another example, if the logical asset is a control service, the asset tag might be "control service," and the process plant 10 may include multiple control services with the same asset tag. In other implementations, the asset tag might be "control service 01" to uniquely identify that particular control service, and other control services might be "control service 02," "control service 03," and so on.

[0267] A MAC address can be the address of a network card operating on a physical or logical asset. A MAC address can uniquely identify a physical asset. However, in the case of logical assets, the MAC address of services operating on the same compute node is the same, and the MAC address may change if the service operates on a different compute node. Therefore, in some implementations, the MAC address may not be used to identify a logical asset, or it may be used in combination with other parameters to identify a logical asset.

[0268] The network address may be the IP address or other identifier of a physical or logical asset within process plant networks 22, 25, 30, 32, 35, 42-58. The serial number may be a manufacturer-assigned number indicating the manufacturer and model of the physical asset, such as a part number.

[0269] In some implementations, a physical or logical asset may be assigned an asymmetric key pair, which includes an encryption private key and an encryption public key. The asymmetric key pair may be assigned by the user or manufacturer. The physical or logical asset may then store the encryption private key without sharing it with other nodes or services. The physical or logical asset may, for example, share the encryption public key with discovery service 2302, which may store a record indicating that the encryption public key corresponds to a particular asset.

[0270] Next, if a physical or logical asset needs to be authenticated, the physical or logical asset provides its cryptographic public key to the authentication service. The authentication service may be nested within the discovery service, as shown in more detail below with reference to Figure 34. In other implementations, the authentication service may be provided in a separate container of the SDCS that communicates with the discovery service. The authentication service retrieves records from the discovered item datastore 2304 and determines whether the cryptographic public key provided to the physical or logical asset matches the cryptographic public key contained in the discovered item datastore 2304. The physical or logical asset also provides a digital signature to the authentication service to prove that the physical or logical asset possesses the cryptographic private key corresponding to the cryptographic public key. If the authentication service determines that the cryptographic public key provided to the physical or logical asset matches the cryptographic public key contained in the discovered item datastore 2304, and that the digital signature proves that the physical or logical asset possesses the cryptographic private key corresponding to the cryptographic public key, the authentication service authenticates the physical or logical asset.

[0271] In other implementations, a physical or logical asset may be assigned a pre-shared key (PSK) that it shares with the discovery service 2302. The discovery service 2302 may store the PSK in relation to the physical or logical asset in the discovered item data store 2304. The physical or logical asset may then use the PSK to encrypt the communication when communicating with other nodes or services. The discovery service 2302 may then retrieve the PSK stored in relation to the physical or logical asset from the discovered item data store 2304, decrypt the communication, and forward the decrypted communication to the other node or service. In this way, the physical or logical asset is authenticated because the communication is encrypted using a PSK shared only between the physical or logical asset and the discovery service 2302.

[0272] In addition to determining the identity of a physical or logical asset, discovery service 2302 may determine the location of a physical or logical asset within the SDCS. For example, the location may be a network address for the physical or logical asset, such as an IP address or other identifier for the physical or logical asset within process plant networks 22, 25, 30, 32, 35, 42-58. In addition to the network location, the location may also include the physical location of the physical or logical asset, such as the physical location of a specific section of process plant 10 where the physical asset is located, or the physical location of a compute node that stores and / or runs the logical asset. Discovery service 2302 determines the location of the physical or logical asset based on information contained in the announcement, such as a description of the network address or physical location.

[0273] Furthermore, the discovery service 2302 may identify a set of capabilities of a physical or logical asset, such as process parameters provided by the physical or logical asset (e.g., valve open percentage, tank filled percentage), services provided by the physical or logical asset (e.g., authentication, authorization, control, analysis, storage), and / or services configured to communicate with the physical or logical asset. For example, a physical or logical asset may include at least some of the capabilities of the physical or logical asset in the announcement as its primary variables. The discovery service 2302 may also identify capabilities of the physical or logical asset not included in the announcement, i.e., context variables. More specifically, the discovery service 2302 may retrieve context variables from a context dictionary service that infers a set of capabilities from a certain type of physical or logical asset. The discovery service 2302 may provide the context dictionary service with the identity of the physical or logical asset, and the context dictionary service may determine the type of physical or logical asset based on the identity. The context dictionary service then provides the discovery service 2302 with a set of capabilities inferred from the type of physical or logical asset. The context dictionary service is described in more detail below, with reference to Figures 34-36.

[0274] In some implementations, upon identifying a physical or logical asset, the discovery service 2302 notifies the process control configuration service of the newly discovered physical or logical asset for commissioning and / or inclusion in the SDCS topology. The user can then accept or reject the inclusion of the newly discovered physical or logical asset in the SDCS topology by the process control configuration service. Alternatively, in some implementations, the newly discovered physical or logical asset may be automatically included in the SDCS topology by the process control configuration service.

[0275] In any case, the discovery service 2302 stores a record of the physical or logical asset in the discovered item data store 2304, including the identity of the physical or logical asset, the location of the physical or logical asset, and / or a set of capabilities of the physical or logical asset. In this way, the discovered item data store 2304 maintains a record of each physical or logical asset in the process plant 10. Other physical or logical assets may request specific process parameters or services, and the discovery service 2302 may identify the physical or logical asset that provides the requested process parameters or services to the requested physical or logical asset. The discovery service 2302 may also provide location information of the physical or logical asset that provides the requested process parameters or services so that the requested physical or logical asset can obtain the requested process parameters or services. Furthermore, the discovery service 2302 may provide a record of the physical or logical asset to an I / O server or I / O device for commissioning the physical or logical asset, such as when the physical or logical asset is a field device.

[0276] If the discovered item data store 2304 is corrupted or destroyed, the discovery service 2302 may automatically broadcast a request to announce the existence of each physical or logical asset within the process plant 10 via the process plant networks 22, 25, 30, 32, 35, 42-58. The discovery service 2302 may then quickly recover the records of each physical or logical asset within the process plant 10 without manual input and without interrupting the operation of the process plant 10.

[0277] In some implementations, discovery requests from discovery service 2302 for physical or logical assets to announce their presence can be forwarded between physical or logical assets with an intermediary. For example, the remote I / O asset 78 in Figure 1 may forward discovery requests to each of the field devices 70 that are communicably connected to the remote I / O asset 78. The field devices 70 may then respond to the discovery requests by announcing their presence to the remote I / O asset 78, which then forwards its announcement to discovery service 2302.

[0278] Figure 34 shows a detailed block diagram of an exemplary discovery container 2402 configured to perform a discovery service, similar to the discovery service 2302 in Figure 33. The discovery container 2402 includes a discovery service 2404 which may perform an authentication service 2406, a context dictionary container 2408 which may contain a context 2410, and a location service 2412.

[0279] Discovery service 2404 may obtain announcements of physical or logical assets participating in process plant networks 22, 25, 30, 32, 35, 42-58. The announcements may include the asset tag of the physical or logical asset, the MAC address of the physical or logical asset, the network address of the physical or logical asset, the encryption key asset of the physical or logical asset, the serial number of the physical or logical asset, and / or the name of the service or subsystem associated with the physical or logical asset. Based on these parameters included in the announcement, discovery service 2404 may determine the identity of the physical or logical asset.

[0280] Discovery service 2404 may also determine the location of a physical or logical asset within the SDCS. For example, the location may be a network address for the physical or logical asset, such as an IP address or other identifier for the physical or logical asset within process plant networks 22, 25, 30, 32, 35, 42-58. In addition to the network location, the location may also include the physical location of the physical or logical asset, such as the physical location of a specific section of process plant 10 where the physical asset is located, or the physical location of a compute node that stores and / or runs the logical asset. Discovery service 2404 determines the location of the physical or logical asset based on information contained in the announcement, such as a description of the network address or physical location.

[0281] Furthermore, the discovery service 2404 may identify a set of capabilities of a physical or logical asset, including process parameters provided by the physical or logical asset (e.g., valve open percentage, tank filled percentage), services provided by the physical or logical asset (e.g., authentication, authorization), and / or services configured to communicate with the physical or logical asset. For example, a physical or logical asset may include at least some of the capabilities of the physical or logical asset in the announcement. The discovery service 2404 may also automatically infer capabilities of the physical or logical asset that are not included in the announcement. For example, if the physical or logical asset is a field device, the announcement may include primary variables obtainable from the field device, such as the mass flow rate of a fluid. The discovery service 2404 may also automatically infer contextual variables of the field device, such as the fluid speed, velocity, and / or density. For example, if the physical or logical asset is a legacy device, the legacy device may not be configured to announce certain capabilities. Therefore, the legacy device announces primary variables, and the discovery service 2404 automatically infers the remaining capability or context variables not included in the announcement.

[0282] In another example, if a physical or logical asset is a field device, the field device may announce primary variables in the Event-Driven Data Layer (EDDL), such as valve location and air pressure within the valve. Discovery Service 2404 may automatically infer contextual variables of the field device, such as valve health metrics and valve stroke metrics.

[0283] More specifically, the discovery service 2404 may retrieve these capabilities from the context dictionary container 2408. The context dictionary container 2408 includes a context 2410 that infers a set of capabilities from a certain type of physical or logical asset. For each type of physical or logical asset, the context 2410 may include a list of each process parameter provided by the physical or logical asset, each service performed by the physical or logical asset, and each service in the SDCS that requests the physical or logical asset to communicate information.

[0284] The discovery service 2404 may provide the identity of a physical or logical asset to the context dictionary container 2408, which may determine the type of the physical or logical asset based on the identity. For example, the context dictionary container 2408 may store a set of rules for determining the type of a physical or logical asset based on its identity. More specifically, the context dictionary container 2408 may determine the type of a physical or logical asset by analyzing the asset tag, serial number, or the name of a service or subsystem associated with the physical or logical asset. For example, if the asset tag of a physical or logical asset is "control valve-01", the context dictionary container 2408 may determine that the type of the physical or logical asset is a control valve. The context dictionary container 2408 may store a list of physical or logical asset types and asset tags, serial numbers, names, or parts of those corresponding to each physical or logical asset type.

[0285] Next, the context dictionary container 2408 uses the context 2410 to automatically infer a set of capabilities from the type of physical or logical asset and provides the set of capabilities inferred from the type of physical or logical asset to the discovery service 2404. Next, the discovery service 2404 stores a record of the physical or logical asset, including the identity of the physical or logical asset, the location of the physical or logical asset, and / or the set of capabilities of the physical or logical asset, in the discovered item data store.

[0286] When a physical or logical asset requests access to a node or service within the SDCS, the authentication service 2406 within the discovery service 2404 authenticates the physical or logical asset. For example, the authentication service 2406 authenticates the physical or logical asset by searching for the encrypted public key of the physical or logical asset contained in the discovered item data store. Next, the authentication service 2406 can compare the encrypted public key retrieved for the physical or logical asset with the encrypted public key provided by the physical or logical asset in the request for access to the node or service to determine if there is a match. The authentication service 240 can also analyze the digital signature provided by the physical or logical asset in the request for access to the node or service to determine if the digital signature proves that the physical or logical asset owns the encrypted private key corresponding to the encrypted public key. If both of these conditions are met, the authentication service 2406 can authenticate the physical or logical asset.

[0287] In another example, the authentication service 2406 authenticates the physical or logical asset by searching for the PSK of the physical or logical asset from the discovered item data store. Next, the authentication service 2406 can attempt to decrypt the request for access to the node or service using the retrieved PSK. If the authentication service 2406 successfully decrypts the request, the authentication service 2406 can authenticate the physical or logical asset.

[0288] Although the authentication service 2406 is shown nested within the discovery service 2404, this is merely an example implementation for the sake of illustration. In other implementations, the authentication service 2406 is not nested within the discovery service 2404.

[0289] Location service 2412 may receive a request for the location of a physical or logical asset from a node or service within the SDCS. Location service 2412 may then retrieve a record of the physical or logical asset's location from the discovered item datastore. For example, the location could be a network address for the physical or logical asset, such as an IP address or other identifier for the physical or logical asset within process plant networks 22, 25, 30, 32, 35, 42-58. In addition to the network location, the location may also include the physical location of the physical or logical asset, such as the physical location of a specific section of process plant 10 where the physical asset is located, or the physical location of a compute node that stores and / or runs the logical asset. Location service 2412 then provides the location information of the physical or logical asset to the node or service that provided the request in response to the request.

[0290] Figure 35 shows a detailed block diagram of an exemplary context dictionary container 2502, similar to the context dictionary container 2408 in Figure 34. Like the context dictionary container 2408, the context dictionary container 2502 includes a context dictionary service 2504 and a context 2508. The context dictionary service 2504 further includes an asset capability identification service 2506.

[0291] The asset capability identification service 2506 may determine the type of a physical or logical asset based on the identity of the physical or logical asset. For example, the asset capability identification service 2506 may store a set of rules for determining the type of a physical or logical asset based on the identity of the physical or logical asset. More specifically, the asset capability identification service 2506 may determine the type of a physical or logical asset by analyzing an asset tag, serial number, or the name of a service or subsystem associated with the physical or logical asset. For example, if the asset tag of a physical or logical asset is "control valve-01", the asset capability identification service 2506 may determine that the type of the physical or logical asset is a control valve. The asset capability identification service 2506 may store a list of physical or logical asset types and asset tags, serial numbers, names, or parts of those corresponding to each physical or logical asset type.

[0292] Additionally or alternatively, the asset capability identification service 2506 may analyze the primary variables of a physical or logical asset included in the announcement to determine the type of the physical or logical asset, such as the primary variables included in the EDDL. For example, if the primary variable of a physical or logical asset is the valve location, the asset capability identification service 2506 may determine that the physical or logical asset is a valve. In another example, if the primary variable of a physical or logical asset is a control service, the asset capability identification service 2506 may determine that the physical or logical asset is a control container. Some physical or logical assets may include a combination of capabilities, such as valve location capability and control service capability. In this case, the asset capability identification service 2506 may determine the type of physical or logical asset based on the combination of capabilities.

[0293] Next, the asset capability identification service 2506 may use the context 2508 to infer capability from the type of physical or logical asset. For example, for a particular physical or logical asset, the announcement may indicate that the physical or logical asset can provide a first set of parameters related to the control of the physical or logical asset. The context 2508 may further identify additional parameters related to the maintenance of the physical or logical asset. In another example, the context 2508 may include mechanisms for accessing each of the additional parameters or services, such as a mechanism for accessing maintenance parameters. The mechanism for accessing the additional parameters or services may be the format and / or content of a request made to the physical or logical asset to retrieve the additional parameters or services. In another example, the mechanism may be a reference number or identifier corresponding to the additional parameters or services that can be used to retrieve the additional parameters or to have the physical or logical asset perform additional services.

[0294] Figure 36 shows a detailed block diagram of an exemplary context 2602, similar to context 2508 in Figure 35. Context 2602 may include a data table 2604 that associates a device type with a class context. More specifically, data table 2604 may include the device type, primary variables, and context variables. For example, if the device type is a thermocouple, the primary variable is temperature, and the context variables may include the device health metric for the thermocouple and a device allow value indicating the thermocouple's variability. If the device type is a mass flow sens...

Claims

1. It is a device, A data cluster comprising multiple computing nodes, wherein each computing node is A processor that runs an instance of the operating system, Memory and A data cluster comprising a communication resource coupled to one or more other computing nodes within the data cluster, A first container instantiated on a first computing node, wherein the first container is a first isolated execution environment and runs within the instance of the operating system of the first computing node, A second container instantiated on the first computing node, wherein the second container is a second isolated execution environment that runs one or more first services on the first computing node within the instance of the operating system of the first computing node, and the second container comprises a second container located within the first container. An apparatus in which the first and second containers correspond to the first and second levels of the hierarchical structure of a process control system, respectively.

2. The apparatus according to claim 1, further comprising one or more second services performed within the first container.

3. The apparatus according to claim 2, wherein one or more second services performed within the second container include an input / output (I / O) server service.

4. A third container instantiated on the first computing node, wherein the third container is a third isolated execution environment that runs one or more second services on the first computing node within the instance of the operating system of the first computing node, and the third container further comprises a third container located within the first container. The one or more first services include a first controller service that performs a first control routine configured to control a first plurality of process control field devices within a first part of an industrial process plant, The apparatus according to claim 1, wherein the one or more second services include a second controller service that performs a second control routine configured to control a second plurality of process control field devices within a second portion of the industrial process plant.

5. The one or more first services include a first I / O server service configured to communicate data between the first plurality of process control field devices and the first controller service, The apparatus according to claim 4, wherein one or more second services include a second I / O server service configured to communicate data between the second plurality of process control field devices and the second controller service.

6. A third container instantiated on a second computing node, wherein the third container is a third isolated execution environment and runs within the instance of the operating system of the second computing node, A fourth container instantiated on the second computing node, wherein the fourth container is a fourth isolated execution environment that runs one or more second services on the second computing node within the instance of the operating system of the second computing node, and the fourth container further comprises a fourth container located within the third container. The third and fourth containers correspond to the first and second levels of the hierarchical structure of the process control system, respectively. The apparatus according to claim 1, wherein the one or more second services are identical to and redundant to the one or more first services.

7. The apparatus according to claim 1, wherein each of the one or more first services is configured to communicate with a software-defined network layer which is communicably coupled to the physical layer, including I / O hardware which communicably couples the one or more first services to a plurality of corresponding process control field devices which operate to control physical processes in an industrial process plant, via an adapter service.

8. A process control system, Multiple process control field devices that operate to control physical processes within an industrial process plant, A communication infrastructure that connects the plurality of process control field devices to a software-defined control system that receives data from the plurality of process control field devices and transmits commands to the plurality of process control field devices in a communicative manner; A data cluster comprising multiple computing nodes, wherein the data cluster executes the software-defined control system, and each computing node, A processor that runs an instance of the operating system, Memory and A data cluster including a communication resource connected to one or more other computing nodes within the data cluster, A first container instantiated on a first computing node, wherein the first container is a first isolated execution environment and runs within the instance of the operating system of the first computing node, A second container instantiated on the first computing node, wherein the second container is a second isolated execution environment that runs one or more first services on the first computing node within the instance of the operating system of the first computing node, and the second container comprises a second container located within the first container. A process control system in which the first and second containers correspond to the first and second levels of the hierarchical structure of the process control system, respectively.

9. The system according to claim 8, further comprising one or more second services performed within the first container.

10. The system according to claim 9, wherein one or more second services running within the second container include an input / output (I / O) server service.

11. A third container instantiated on the first computing node, wherein the third container is located within the instance of the operating system of the first computing node, and there are one or more such containers on the first computing node. A third isolated execution environment for executing the second service, wherein the third container further includes a third container located within the first container, The one or more first services include a first controller service that executes a first control routine configured to control a first set of process control field devices in a first part of the industrial process plant, The system according to claim 8, wherein one or more second services include a second controller service that performs a second control routine configured to control a second set of process control field devices within a second portion of the industrial process plant.

12. The one or more first services include a first I / O server service configured to communicate data between the first set of process control field devices and the first controller service, The system according to claim 11, wherein one or more second services include a second I / O server service configured to communicate data between a set of process control field devices and the second controller service.

13. A third container instantiated on a second computing node, wherein the third container is a third isolated execution environment and runs within the instance of the operating system of the second computing node, A fourth container instantiated on the second computing node, wherein the fourth container is a fourth isolated execution environment that runs one or more second services on the second computing node within the instance of the operating system of the second computing node, and the fourth container further includes a fourth container located within the third container. The third and fourth containers correspond to the first and second levels of the hierarchical structure of the process control system, respectively. The system according to claim 8, wherein the one or more second services are identical to and redundant to the one or more first services.

14. The system according to claim 8, wherein each of the one or more first services is configured to communicate via an adapter service with a software-defined network layer which is communicably coupled to a physical layer including the communication infrastructure, thereby facilitating the communicative coupling of the one or more first services to the plurality of process control field devices which operate to control the physical processes in the industrial process plant.

15. It is a method, The process involves instantiating a first container on a first computing node of a data cluster, wherein the first container is a first isolated execution environment within the operating system of the first computing node. The process involves instantiating a second container on the first computing node of the data cluster, wherein the second container is a second isolated execution environment within the operating system of the first computing node, and the second container is instantiated within the first container. This includes running one or more first services within the second container. A method wherein the first and second containers correspond to the first and second levels of the hierarchical structure of a process control system, respectively.

16. Further comprising running one or more of the second services within the first container, The method according to claim 15.

17. The method according to claim 16, wherein the one or more second services performed within the second container include an I / O server service.

18. The process involves instantiating a third container on the first computing node of the data cluster, wherein the third container is a third isolated execution environment within the operating system of the first computing node, and the third container is instantiated within the first container. The one or more first services include a first controller service that performs a first control routine configured to control a first plurality of process control field devices within a first part of an industrial process plant, The method according to claim 15, wherein the one or more second services include a second controller service that performs a second control routine configured to control a second plurality of process control field devices within a second portion of the industrial process plant.

19. The one or more first services include a first I / O server service configured to communicate data between the first plurality of process control field devices and the first controller service, The method according to claim 18, wherein the one or more second services include a second I / O server service configured to communicate data between the second plurality of process control field devices and the second controller service.

20. The process involves instantiating a third container on a second computing node of the data cluster, wherein the third container is a third isolated execution environment within the operating system of the second computing node. The instantiation involves instantiating a fourth container on the second computing node of the data cluster, wherein the fourth container is a fourth isolated execution environment that runs one or more second services on the second computing node within the operating system of the second computing node, and the fourth container is instantiated within the third container. The third and fourth containers correspond to the first and second levels of the hierarchical structure of the process control system, respectively. The method according to claim 15, wherein the one or more second services are identical to and redundant to the one or more first services.

21. The method according to claim 15, wherein each of the one or more first services is configured to communicate with a software-defined network layer which is communicably coupled to the physical layer, including I / O hardware which communicably couples the one or more first services to a plurality of corresponding process control field devices which operate to control physical processes in an industrial process plant, via an adapter service.

Images