Process Control or Automation System Architecture

Abstract

The process plant and industrial control system architecture includes a general-purpose computational fabric that is independent of or independent of the physical location where the computational fabric is implemented, includes one or more physical control or field devices located at one or more specific sites where a product or process is manufactured, and further includes a transport network that securely provides communication between the computational fabric and the pool of physical devices. The computational fabric includes one or more devices, control strategies, and control loops, an application layer that includes configured containers or containerized software modules that perform various control, monitoring, and configuration activities with respect to the site, plant, or facility where the control is performed, and a physical layer that includes computer processing and data storage equipment that can be located in any desired location, including at or near the site, plant, or facility where the control is performed, a dedicated location remote from where the control is performed, reassignable computing equipment provided in the cloud, or any combination thereof. This control architecture allows both a significant amount of the computing and IT infrastructure used to support a process plant, industrial control facility, or other automation facility to be implemented in a shared, off-site, and / or virtualized fashion, mitigating many of the communication and security issues present in current process and industrial control systems that attempt to implement control using shared or virtualized computing resources set up according to the well-known Purdue model. The industrial control system architecture is protected through more secure and customizable technology compared to that used in Purdue model-based control systems. For example, communications between any (and possibly all) endpoints of the system can be protected through one or more virtual private networks to which authenticated endpoints must be authorized for access. Endpoints may include, for example, containerized components, physical components, devices, sites or locations, compute fabrics, etc., and VPNs may include mutually exclusive and / or nested VPNs.External applications and services, whether automated or running under the authority of a human operator, may access the information and services provided by the system solely through APIs, and different sets of APIs may be exposed to different users who are authenticated and authorized to access each set of APIs. A configuration system operates within the computational fabric to enable users to easily make configuration changes to the computational fabric, so that users generally do not need to specify which computer hardware within the computational fabric to use to make configuration changes, allowing users to deploy new components with simple programming steps, and in some cases with the push of a button.

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims priority to U.S. Provisional Patent Application No. 63 / 390,238, entitled "Next Generation Process Control and Automation System," filed July 18, 2022; U.S. Provisional Patent Application No. 63 / 398,441, entitled "Securing Next Generation Process Control and Automation Systems," filed August 16, 2022; U.S. Provisional Patent Application No. 63 / 417,861, entitled "Configuration Features of Next Generation Process Control and Automation Systems," filed October 20, 2022; and U.S. Provisional Patent Application No. 63 / 418,006, entitled "Enterprise-Level Features Provided by the NGPCAS," filed October 20, 2022, the entire disclosures of each of which are expressly incorporated herein by reference.

[0002] FIELD OF THE INVENTION This application relates generally to industrial process control and automation systems for industrial process plants, and more particularly to next generation architectures for industrial process control and automation systems. [Background technology]

[0003] For decades, distributed process control and automation systems from various companies (such as distributed or scalable process control and / or automation systems used in power generation, chemical, petroleum, or other industrial processes such as pharmaceutical or other types of manufacturing) have typically included one or more dedicated process controller devices communicatively coupled to each other via a process control network, to at least one host or operator workstation, and to one or more instrumentation or field devices via analog, digital, or combined analog / digital buses.

[0004] Field devices perform functions within a process or plant, such as opening and closing valves, switching devices on and off, and measuring process parameters. Examples of field devices include valves, valve positioners, switches, and transmitters (e.g., devices that include sensors for measuring temperature, pressure, or flow rate, and transmitters for transmitting the sensed temperature, pressure, and flow rate). In many industrial processes, there may be hundreds, thousands, or even tens of thousands of field devices that operate to send data to and / or receive commands from one or more dedicated controller devices.

[0005] A process controller, which is typically located within a plant environment (i.e., within the physical boundaries of the plant, particularly in the vicinity of the field devices), receives signals indicative of process measurements made by the field devices (or other information related to the field devices) and executes a controller application that executes different control modules that, for example, make process control decisions and generate control signals based on the received information, and that interface with control modules or blocks implemented in smart field devices (e.g., HART®, WirelessHART®, and FOUNDATION® Fieldbus field devices).

[0006] Execution of the control modules causes the process controller to send control signals over communication links or signal paths to the field devices to thereby control the operation of at least a portion of the process plant or system (e.g., control at least a portion of one or more industrial processes running or executing within the plant or system). For example, a first set of controllers and field devices may control a first portion of a process being controlled by the process plant or system, and a second set of controllers and field devices may control a second portion of the process.

[0007] Input / output (I / O) cards (sometimes called "I / O devices" or "I / O modules"), also typically located within a plant environment, are generally disposed between a controller and one or more field devices to enable communication therebetween (e.g., by converting electrical signals to digital values ​​and vice versa). Typically, an I / O card acts as an intermediate device between a process controller and one or more field devices that have inputs or outputs configured for the same communication protocol used by the I / O card.

[0008] Field devices, controllers, and I / O devices are generally collectively referred to as "process control devices" and are generally located, disposed, or installed in the physical field environment of a process control system or plant. The network formed by one or more controllers, field devices communicatively connected to the one or more controllers, and intermediate devices that facilitate communication between the controllers and field devices may be referred to as an "I / O network" or "I / O subsystem."

[0009] Information from the I / O network can be made available via a data highway or communication network ("process control network") to one or more other hardware devices, such as operator workstations, personal computers or computing devices, handheld devices, data historians, report generators, centralized databases, or other centralized management computing devices that are typically located in a control room or other location away from the plant's more harsh field environment, for example, in the back-end environment of a process plant.

[0010] Information communicated over a process control network enables an operator or maintenance personnel to perform desired functions with respect to a process via one or more hardware devices connected to the network. These hardware devices may run applications that enable an operator or other user, such as a configuration engineer or maintenance personnel, to, for example, configure process controllers, I / O devices, and field devices; change settings on process control routines; modify the operation of control modules in a process controller or smart field device; view the current state of a process or the status of specific devices in a process plant; view alarms generated by field devices and process controllers; simulate the operation of a process for purposes of training personnel or testing process control software; diagnose problems or hardware failures in a process plant; and the like. The process control network, or data highway, used by the hardware devices, controllers, and field devices may include wired communication paths, wireless communication paths, or a combination of wired and wireless communication paths.

[0011] Generally speaking, a communication network (e.g., an I / O network in a process control environment) includes communication nodes that are senders and receivers of data, as well as communication links or pathways that connect the communication nodes. Additionally, communication networks typically include dedicated routers (including firewalls) responsible for directing traffic between the communication nodes, and, optionally, dedicated devices responsible for configuring and managing the network. Some or all of the communication nodes may also be adapted to function as routers to direct traffic sent between other network devices. Network devices may be interconnected in a wired or wireless manner, and network devices may have different routing and forwarding capabilities. For example, a dedicated router may be capable of transmitting large amounts of traffic, while some communication nodes may be capable of sending and receiving relatively small amounts of traffic in the same period of time. Additionally, connections between communication nodes on a network may have different throughput capabilities and attenuation characteristics. For example, fiber optic cable may be able to provide orders of magnitude higher bandwidth than a wireless link due to differences in the physical or fundamental limitations inherent in the medium.

[0012] For many years, industrial control system providers and users have organized control systems for industrial processes around the Purdue Model for Control Hierarchy logic framework standardized by ISA (International Society of Automation) 95.01-IEC (International Electrotechnical Commission) 62264-1 (the "Purdue Model") The Purdue Model is a network segmentation model for industrial control systems that helps conceptualize and organize industrial process architecture concepts, particularly the security of various network segments within an industrial process.

[0013] Similar to how the OSI model for network communications conceptually organizes computer communication networks into layers, the Purdue model divides industrial process architectures into a number of levels and zones. Levels 0, 1, 2, and 3 represent the physical process (e.g., physical equipment, which are controlled field devices and associated physical I / O devices), basic control (e.g., controllers, PLCs, etc. that monitor and control Level 0 equipment and safety instrumented systems), area supervisory control (e.g., supervisor and data acquisition (SCADA) functions and other control logic that analyzes and acts on Level 1 data, along with operator workstations and human machine interfaces (HMIs), historian databases, configuration, etc.), and field operations (e.g., plant-wide control and monitoring, data aggregation, reporting, etc.), respectively, and are part of the manufacturing zone. Levels 4 and 5 represent the enterprise's business and logistics systems (e.g., database servers, application servers, file servers, etc.) and the enterprise or internal network (e.g., a broader set of enterprise information technology (IT) systems, including connections to the public Internet), respectively, and are part of the enterprise zone. The demilitarized zone (DMZ) is located between the enterprise zone and the manufacturing zone. Process control levels 0-2 generally require a high degree of trust in the security and validity of messages, packets, and other communications, while manufacturing, internal, and enterprise systems at levels 3-5 generally require a lower level of trust. For example, process plant systems, networks, and devices at security levels 0-3 can be protected against threats from the enterprise network at security levels 4-5 and / or from any external network higher than security level 5 that utilizes the enterprise network, for example, by using a DMZ and / or one or more firewalls.

[0014] As industrial processes and the associated control systems for those processes have become more complex, the operation technology (OT) that enables industrial control (i.e., systems that monitor events, processes, and devices and make adjustments in industrial operations) has begun to converge with the information technology (IT) that was developed around it (i.e., systems used for data-centric computing and analytics). Data from OT systems is now sought and analyzed for various IT systems. For example, data from the operational level of a plant can be used by various IT systems (e.g., at the enterprise level) to monitor plant efficiency, create or update production schedules, product delivery schedules, and input material deliveries, as well as for countless other uses. However, achieving the desired level of security within the Purdue model has been extremely difficult because it requires substantial infrastructure and, correspondingly, arduous configuration during plant commissioning, which can take a month or more. Transferring data between tiers of the Purdue model (e.g., sending data from tier 2 to tier 3 or 4), while retaining some degree of security, has required numerous security workarounds, including an increase in data relays, data diodes, and firewall devices. In some implementations, to mitigate communication issues caused by these complex security features, system providers and / or field engineers have circumvented the Purdue model and transmitted data directly from control devices to the cloud, which undermines the plant security features provided by the Purdue model.

[0015] Further complicating matters, OT networks are often designed without IT security in mind, resulting in OT systems that are often legacy systems incompatible with commonly accepted principles of good security hygiene on IT networks. For example, OT systems typically do not support modern identification and authentication / authorization protocols or practices, at least at the field device and controller level. This often leads to various data transfer practices that are incompatible with highly secure networks. For example, there may be three or more domains between Layer 2 and Layer 4 of a process, and security policies may differ for each such domain. As a result, cross-layer connectivity can be difficult, leading to implementations where firewalls are punched to obtain data between layers, credentials are hard-coded into devices or applications, and / or passed in unencrypted form to maintain connectivity. Furthermore, third-party software integration is difficult, error-prone, and often insecure for the reasons explained above. Because the required downtime incurs substantial costs for plant operators, vulnerabilities are often left unrepaired. As a result of these shortcomings, process control networks are, at best, complex, chaotic, and extremely difficult to maintain, and, at worst, insecure.

[0016] More recently, some providers and users of industrial control systems have attempted to move portions of their industrial control systems to general-purpose computing resources, such as the cloud, and virtualize certain aspects of their industrial control systems. Such attempts have sought, for example, to capture and analyze the ever-expanding amounts of data generated in industrial control systems and to create virtualized redundancies. However, compliance with the Purdue Model and the associated security practices it requires has resulted in each of these attempts suffering from one or more of the drawbacks detailed above, while also having side effects. Integrating cloud-based components into the Purdue Model can dramatically complicate security issues by requiring data from lower levels of the Purdue Model (e.g., OT systems) to traverse IT infrastructure that it was never intended to traverse. The resulting additional security infrastructure required, when added to traversing IT infrastructure (whether on-premises or off-premises), can increase latency, sometimes to unacceptable levels, particularly with respect to control signals.

[0017] Additionally, some providers of industrial control systems have attempted to decouple (e.g., virtualize) the control algorithms that control industrial processes from the dedicated controller hardware. To that end, entire controllers are virtualized so that they can run on less specialized hardware (e.g., servers or shared computing hardware), allowing multiple copies of the control algorithm to run in parallel on different hardware, thereby allowing one instance to serve as a backup for another primary instance. If the primary instance fails or becomes unstable, control can be shifted to the backup instance, and the original primary instance can be shut down and re-instantiated on the same or different hardware. While such systems have some advantages with respect to controller redundancy, because the entire controller can be instantiated multiple times on different hardware and even moved between hardware, they remain subject to the limitations imposed by the Purdue model. Furthermore, these systems require all of the elements of the virtualized device (e.g., the controller) to be replicated or moved together or simultaneously, which limits the flexibility of these systems. Summary of the Invention [Means for solving the problem]

[0018] The new process plant and industrial control and / or automation system architecture enables both a significant amount of the computing and IT infrastructure used to support a process plant, industrial control facility, or other automation facility (referred to herein as the compute fabric) to be implemented in a shared, off-site, and / or virtualized manner, mitigating many of the communication and security issues present in current process and industrial control systems that attempt to implement control using shared or virtualized computing resources, such as cloud-based computing or system resources. In particular, the new control system (which may be used to implement control, monitoring, and configuration activities in any process plant or industrial manufacturing or automation facility) does not attempt to follow the well-known, commonly followed, and accepted Purdue model when integrating and providing communications between plant devices (such as field devices), equipment controllers, supervisory controllers, field operations, and enterprise operations. As a result, the system architecture can implement control functions, communications, and security measures in a manner that can effectively use communication and security features developed for general-purpose computing use outside of the process plant environment in a more effective manner when supporting control functions associated with a process plant or industrial automation facility.

[0019] More particularly, the new control system architecture includes a general-purpose computational fabric that is independent of or independent of the physical location where the computational fabric is implemented, includes one or more physical control devices (referred to herein as a pool of physical devices), such as valves, transceivers, I / O devices, etc., located at one or more specific plants, facilities, sites, or physical locations where a product or process is manufactured or implemented, and further includes a transport network that enables or provides communication between the computational fabric and the pool of physical devices in a robust and secure manner.

[0020] Generally speaking, a computational fabric includes a physical layer comprising one or more computing and / or storage devices, and an application layer including computer-implemented software modules that can be implemented on the physical layer to perform various control, monitoring, and configuration activities using the pool of physical devices. In some cases, the application layer of a computational fabric can be implemented as one or more sets of configured containers or as a containerized system in which various different configured containers and container types perform different computer-implemented functions for the facility or enterprise in which the control system is implemented. The physical layer of a computational fabric can be implemented on any desired computing, storage, and networking equipment, such as on one or more computing processors and computer databases in a cloud, on one or more dedicated off-site locations separate from the plant, facility, or field where the pool of physical devices is located, on computing equipment located at the physical plant or facility where the pool of physical devices is located, or any combination thereof. The new control system architecture also includes a networking layer, disposed between the physical layer and the application layer, that provides for the operation, management, and use of physical layer resources and logic (e.g., software-based) resources as needed for application layer activity, particularly to support timing and other needs specific to and required by industrial process control and automation.

[0021] Furthermore, various components of the application layer, e.g., various configured containers that make up the application layer, may be executed on any desired computing equipment associated with the physical layer in any desired configurable manner. Thus, configured containers of the application layer may be implemented in a redundant manner on various of the same or different computer processing equipment of the physical layer, may be moved between different computer processing equipment of the physical layer to provide better computing and communication performance, may be replicated on various different processors or databases of the physical layer to provide redundancy and / or control the replicated physical equipment, etc.

[0022] A pool of physical devices may include devices that perform physical functions utilized to control industrial or automation processes performed at various different locations, sites, or facilities of an enterprise. For example, a pool of physical devices, which may include field devices such as valves, valve positioners, actuators, switches, regulators, sensors, etc., are located at one or more manufacturing facilities of an enterprise and perform physical functions, control, and / or other types of functions associated with controlling an industrial or automation process using physical hardware that interacts with the process materials or products being manufactured and provides measurement and control of the physical phenomena being controlled / implemented as part of the manufacturing or automation process. A pool of physical devices may be located or physically located at different physical locations or environments associated with an enterprise, or may be located or located entirely in only a single physical location or environment.

[0023] In operation, the compute fabric may be communicatively connected to a pool of physical equipment located at one or more physical locations using one or more transport networks. The transport networks may use any desired communications infrastructure and protocols, including any desired wired and / or wireless communications devices / protocols. Such protocols may be any of a variety of process control protocols, such as HART, WirelessHART, Foundation Fieldbus, Profibus, OPC UA, and / or any of a variety of general-purpose computing communications protocols. For example, the transport networks may use any IP-based or packetized protocol, including protocols that utilize publication and subscription, such as MQ Telemetry Transport (MQTT) and Advanced Message Queueing Protocol (AMQP). Furthermore, the transport networks may use or include any desired communications network physical layer, such as Ethernet, 802.11, advanced physical layer (APL), and other physical layers. In this manner, a pool of physical devices may send data or information to and receive data or information from one or more configured containers in the compute fabric in packetized form over one or more transport networks to enable the compute fabric to implement process control, monitoring, and configuration activities with respect to the pool of physical devices. Additionally, in some embodiments, a virtual network such as a VNet may be used to communicatively connect different remote infrastructures (which may be implemented, for example, via different cloud computing systems and / or via other suitable means) and to communicatively connect different physical locations (e.g., on-premise infrastructure) with remote infrastructure. For network security reasons, virtual networks may be routed through a Virtual Private Network (VPN).For reliability, different VNets may be used for different network providers (e.g., AT&T and Verizon). A more detailed description of VPNs is provided elsewhere herein.

[0024] The computational fabric may be implemented on a scalable hardware platform, portions of which may be physically located across one or more physical locations that may or may not be the same physical locations associated with the pool of physical devices. Thus, in some embodiments, at least a portion of the computational fabric may be implemented on a cloud computing platform, the hardware of which may be located remotely from the physical locations of the field environments in which the pool of physical devices is located.

[0025] Generally speaking, a compute fabric supports the creation, execution, removal, maintenance, operation, and management of multiple containerized applications, containerized services, or other containerized components (e.g., configured containers). A pool of containerized components may include containerized applications and / or containerized services, each of which provides specific functions and / or operations utilized by a control system to control, monitor, and / or configure one or more of a pool of physical devices, support process and / or automation control and systems management, and operate, maintain, and manage the system and its components over its lifetime. Generally speaking, containerized components provide the functionality that traditional process control and automation technologies implement across multiple systems, networks, computing devices, DMZs, firewalls, and applications that typically operate across levels 2 through 5 of the Purdue model, from overseeing, monitoring, and controlling physical industrial processes and data acquisition at level 2 to enterprise-level IT functions providing business direction and functionality related to the systems at level 5. Additionally, containerized components may provide higher level functionality, such as coordination and / or management among multiple systems of an enterprise, and even coordination among multiple enterprises. Thus, advantageously, rather than utilizing the cumbersome and resource-costly traditional architectures of Purdue Levels 2-5, and all of the numerous data diodes, firewalls, DMZs, etc., required to secure a process control or automation system in such architectures, the control architecture described herein simply utilizes a set of containerized components running in a compute fabric to perform the same or similar set of process control and automation core functions and related functions without compromising the security of the system, and in some configurations providing greater security than is possible with traditional architectures.

[0026] Furthermore, different functions may be implemented by different containerized components within the compute fabric, and thus a single application or service may be composed into multiple different containerized components (e.g., different instances of the application or service implemented in each container). In this manner, similar or related composed containers may run with different physical devices, e.g., on different portions of the hardware platform of the compute fabric to create redundancy or hot spares, etc. Advantageously, various containerized components may be created (e.g., spun up) and / or removed as or when needed, and collectively, a group of containerized components may operate to form or provide a logical process control or automation system that may be implemented as a "virtual process control system" for controlling one or more industrial or physical processes.

[0027] Furthermore, during execution, each containerized component may communicatively connect to a particular physical component or device, or to another containerized component, via a respective packet-based connection on the transport network, such that each containerized component and each physical component may be identified within the system by a unique name or identification, which may be associated with a particular address (e.g., an IP address) within the transport network. To maintain a high level of communication security, the containerized component and the physical component may be authorized and authenticated, on a component-by-component basis, and optionally pairwise, with each other, for example, by using keys or any other suitable authorization and authentication technique. Upon successful authorization and authentication, the two endpoint components may communicate data, instructions, and other information with each other during a session that the two endpoint components establish over one or more transport networks.

[0028] To further secure the system, the one or more transport networks may include one or more virtual private networks (VPNs), such that, for example, a particular containerized component communicatively connects with a particular physical component or other containerized components using point-to-point or peer-to-peer connections, such as VPNs, that are exclusive to only the particular containerized component and the particular physical component. In this manner, components may securely communicate data, messages, instructions, and / or other information with each other via the exclusive point-to-point or peer-to-peer connections. The exclusive point-to-point or peer-to-peer connections may be established and / or disconnected as needed or as needed. Furthermore, multipoint connections (e.g., VPNs or other suitable implementations) may be used to provide highly secure communications between multiple containerized and / or physical components. In some implementations, point-to-point or peer-to-peer networking connections may be utilized instead of or in addition to one or more point-to-point or peer-to-peer connections to further secure the system. The transport network point-to-point connections, peer-to-peer connections, and VPNs may be implemented over one or more public and / or private networks, including private corporate networks and / or the public Internet.

[0029] Advantageously, the compute fabric architecture abstracts (e.g., decouples) higher-level business logic services, subsystems, and other software components at the application layer from the particular computing platform or hardware associated with the compute fabric, enabling the higher-level software-defined services, subsystems, and other software components to dynamically, automatically, and responsively direct and cause changes in the usage of hardware and software resources of the computing platform nodes and clusters, without any human intervention or direction, using, for example, APIs, operating system (OS) support, and other services at the networking layer. Thus, management of the computing platform's resources can dynamically respond to changes in configuration and the needs of the higher-level software-defined services, subsystems, and other software components at the application layer.

[0030] In one example, industrial process control, automation, and other associated business logic is implemented by higher-level software-defined services, subsystems, and other software components associated with the compute fabric, e.g., at the application layer. For example, a set of software-defined application layer components may collectively form a logical process control or automation system that executes with physical components deployed at one or more physical locations or fields to implement an industrial process. Additionally, a set of third-party business logic services may also execute at the compute fabric application layer, and these third-party services may be generated by a software development kit associated with the compute fabric through which users can develop, generate, install, and manage third-party services at the application layer.

[0031] In another example, a controller or control service within a compute fabric may be configured with one or more process control module services, parameters, and values ​​associated with an industrial process plant, such as input and output tags, reference values, etc., thereby forming a configured or programmed controller service. A controller or control service may be functionally equivalent to a traditional dedicated hardware controller device as understood in the Purdue model, or a controller service may be functionally equivalent to a control routine or control module configured within and executed by a traditional dedicated hardware controller device. A container may be configured with an instance of a configured controller service, thereby forming a container image or instance of the configured controller service that, when so configured, is executable to implement a particular configured set of process control logic, for example, by using the configured control module containers, tags, reference values, etc. Multiple instances or container images of a configured controller service (or other configured applications and services) may be instantiated and executed by the compute fabric.

[0032] Some configured containers in the compute fabric can be distributed or assigned to respective compute nodes of the compute fabric by a software-defined compute service and dynamically reassigned to different compute nodes based on the dynamically changing configuration, performance requirements, and other needs of the logic process control or automation system. In some circumstances, configured containers can be assigned (and reassigned) to run by specific processors or specific processor cores of one or more compute nodes. However, some configured containers can be pinned to respective compute nodes and therefore not dynamically reassigned by the compute service due to dynamically occurring conditions. Configured containers can additionally or alternatively be pinned to other physical or logical components of the compute fabric. For example, a configured container can be pinned to another configured container, a specific data cluster, a specific processing resource (e.g., a specific physical processor or specific physical processor core of a compute node), 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 compute nodes), etc. Furthermore, configured containers can be nested within other configured containers, which is particularly useful for configuring and organizing logic process control or automation systems.

[0033] The application layer of the compute fabric may include other types of application layer services, such as operator displays and interfaces, diagnostics, analytics, safety routines, reporting, data historizing, service configuration, communication with external or other systems, enterprise-level applications, etc. Additionally, a set of subsystems in the application layer of the compute fabric may provide or implement virtual or logic process control related subsystems of a logic process control system. For example, a historian subsystem may include a read service, a write service, and a search service, each of which configured containers are nested within a configured historian subsystem container. In another example, a batch process control subsystem may include a unit procedure service, a recipe service, and a regulatory record generation service, which may be nested within a configured batch process control system container.

[0034] In general, subsystems allow control services and other services to be easily and consistently grouped and / or managed. In some cases, each compute node in a compute fabric hosts a respective instance of each subsystem in a set of subsystems, thereby making the subsystem services readily available in close proximity to other application layer services running on each compute node. Accordingly, changes to one or more of the subsystems can be coordinated among the corresponding instances of the subsystems running on each compute node. Thus, the set of subsystems is highly available in close proximity to any application layer services running on the compute node, and in the event of a compute node failure, a compute node component failure, or a specific subsystem failure, the functionality provided by the set of subsystems can be easily maintained for the logic process control system. The subsystems may include continuous process control, event-driven process control, batch process control, state-based control, ladder logic control, historian, process user, alarm, license, event, version control, process configuration, and process I / O, to name a few.

[0035] Furthermore, in some implementations, the compute fabric may implement digital twins of various software-defined application services, entire software-defined application layers, various software-defined support services, and / or the entire software-defined networking layer. The digital twins of target components / layers may execute on the computing platform in coordination with the active target components / layers, thereby receiving runtime data from the field environment of the industrial process plant and operating accordingly with the same logic, state, timing, etc. as the active target components / layers. However, I / O and other types of data generated by the digital twins are prevented from being delivered to the field environment. In this way, if an active target / component fails, the runtime operation of the industrial process plant can be seamlessly maintained by simply activating the digital twin of the fielded target / component. Furthermore, in some implementations, the compute fabric may implement digital twins of physical components that may serve as proxies for the physical components during runtime operation.

[0036] Similarly, the computational fabric may be used to support various enterprise-level services and functions, such as real-time monitoring of enterprise functions across multiple facilities associated with the enterprise, real-time monitoring of one or more physical locations of the enterprise, providing or implementing plant or facility operator displays to allow operator input from any location, providing containerized services from any location, providing and instantiating control, other enterprise services, portions or even the entire process control system from any location, moving the execution of services across different locations or sites, providing subscription or third-party services for the enterprise, providing centralized upgrades for the enterprise, and centralized monitoring of the computational fabric associated with the enterprise. [Brief explanation of the drawings]

[0037] [Figure 1A] FIG. 1 is a block diagram of an example architecture of a Next Generation Process Control and Automation System (NGPCAS) that may be utilized to control industrial and / or automation processes. [Figure 1B] FIG. 1 is a block diagram of an example architecture of a Next Generation Process Control and Automation System (“NGPCAS”) that may be utilized to control industrial and / or automation processes having installed or legacy distributed control systems. [Figure 2A] FIG. 1C illustrates a portion of an example architecture of the next generation process control and automation system of FIGS. 1A and 1B including a digital twin. [Figure 2B] FIG. 1C illustrates a portion of an example architecture of the next generation process control and automation system of FIGS. 1A and 1B including a digital twin. [Figure 2C] FIG. 1C illustrates a portion of an example architecture of the next generation process control and automation system of FIGS. 1A and 1B including a digital twin. [Figure 3A] FIG. 1 is a block diagram of an exemplary multi-enterprise framework for different next generation process control and automation systems from different companies. [Figure 3B] 1A and 1B illustrate exemplary enterprise-level compute fabric functions that may be provided by the compute fabric of FIG. [Figure 4] FIG. 1C is a block diagram of an example architecture of a computational fabric that may be included in the NGPCAS of FIGS. 1A and 1B. [Figure 5A] FIG. 1 is a block diagram illustrating a smart field device that implements embedded device identification (EDID). [Figure 5B] FIG. 1 is a block diagram of a sensor / transmitter device that implements EDID. [Figure 5C]FIG. 1 is a block diagram of an I / O device that implements EDID. [Figure 5D] 1 illustrates exemplary information that may be stored as an EDID. [Figure 5E] FIG. 1 is a block diagram illustrating components within a computational fabric that may enable a process control system to use EDID to secure and / or commission a process plant. [Figure 5F] 1 is an exemplary method for implementing EDID in a process plant. [Figure 5G] 1C is an exemplary resource security technique that may be utilized in the NGPCAS of FIGS. 1A and 1B. [Figure 6A] Illustrates an exemplary manner in which an enterprise may implement the NGPCAS described herein using a compute fabric hub and communication spoke configuration to support multiple different physical locations that may use different data and execution governance rules. [Figure 6B] 1 is a chart illustrating an example system hierarchy associated with an enterprise using the NGPCAS described herein. [Figure 7] FIG. 1C illustrates an interconnection between an architecture provider / manager and multiple different enterprise systems, each using the NGPCAS of FIGS. 1A and 1B, allowing manager oversight of the different enterprise systems and quick and easy configuration changes to the different enterprise systems. [Figure 8A] FIG. 8 illustrates a configuration system that allows configuration activity in one of the enterprise systems of FIG. 7 to add, upgrade, or otherwise change the operation of the enterprise system. [Figure 8B] 1 is an illustration of an exemplary user interface display that allows users at an enterprise to make hardware and software configuration changes to the enterprise. [Figure 9]FIG. 8 illustrates a development system used to develop and roll out new functionality, such as containers or products, in one or more of the enterprise systems of FIG. 7 in a manner that shortens development and rollout times associated with new control system functionality while providing enterprise system managers the ability to control the timing and selection of changes to the enterprise systems. [Figure 10A] 1 illustrates an exemplary NGPCAS control / operation graphical user interface (GUI) for a physical site. [Figure 10B] 10 illustrates another exemplary control / operation GUI for a physical site in NGPCAS. [Figure 10C] 1 illustrates an exemplary enterprise-level view GUI. [Figure 10D] 1 illustrates an exemplary process entity development GUI. [Figure 10E] 1 illustrates an exemplary control loop GUI for a physical site in NGPCAS. [Figure 10F] 1 illustrates an exemplary diagnostic GUI for multiple physical sites in NGPCAS. [Figure 10G] 10 illustrates another exemplary diagnostic GUI for multiple physical sites in NGPCAS. [Figure 10H] 10 illustrates yet another exemplary diagnostic GUI for multiple physical sites in NGPCAS. [Figure 11A] 1 illustrates an exemplary marketplace GUI for browsing and acquiring services / applications in NGCPAS. [Figure 11B] 10 illustrates another exemplary marketplace GUI for browsing and acquiring specific services / applications. [Figure 12A] 1 illustrates an exemplary data capture GUI for multiple physical sites of an enterprise. [Figure 12B] 10 illustrates another exemplary data capture GUI for multiple physical sites of an enterprise. [Figure 12C] 1 illustrates a diagnostic GUI for the enterprise NGPCAS. DETAILED DESCRIPTION OF THE INVENTION

[0038] The following disclosure describes a new process plant and industrial control and / or automation system architecture that relies on a shared computational fabric to implement control, monitoring, and configuration activities in any process plant or industrial manufacturing or automation facility. The computational fabric is a high-performance computing system consisting of loosely coupled storage, resource management, security, networking, and parallel processing capabilities linked by a high-bandwidth interconnect (e.g., 10 Gigabit Ethernet), and may include any one or more of the following: a commercial general-purpose platform such as Microsoft's Azure Services platform; a platform owned, operated, and maintained by a company or system provider and dedicated to implementing process control in one or more companies; a computational cluster located on-premises and local to the process plant; etc. The shared resources of the computational fabric, which may be shared among process plants within an enterprise or by multiple enterprises each operating one or more process plants, and the fact that the new architecture does not attempt to follow the well-known, commonly followed, and accepted Purdue model, enable various improvements and innovations in system configuration, control, monitoring, and management.

[0039] While the architecture is described in detail below, the following examples illustrate some scenarios for implementing the concepts described herein in a system and highlight the benefits of such implementations. These examples should not be considered limiting in terms of available functionality, personnel performing various tasks, physical separation or location of various elements, or in any other manner. Instead, these examples are intended to introduce various system elements and aspects of the system's operation, each of which is described in more detail elsewhere herein.

[0040] Example 1 The system provider provides and manages a computational fabric that serves one or more enterprises and offers various tools and programs for configuring, commissioning, controlling, and monitoring one or more process plants using the computational fabric. These tools and programs include, among other things, tools for configuring control modules and control strategies to control the process plant, tools for configuring operator workstations to monitor and control the process plant, tools for performing asset management (e.g., tracking calibration, maintenance, etc.), and tools for instantiating and managing the control modules that ultimately control the process plant after being configured and instantiated in the computational fabric. Each enterprise within the multiple enterprises has access to and utilizes the computational fabric and available tools and programs to implement one or more enterprise-owned and / or operated industrial processes in one or more respective process plants. Each of the process plants implements various aspects of its process control via various containerized applications and services instantiated in the computational fabric. These include, among other things, control algorithms, input-output, and security functions, and the use of containerized applications and services can facilitate various quality-of-service (QoS) features, including load balancing, fault tolerance, and redundancy, implemented and managed either by the system provider or the enterprise, or by the enterprise with assistance from the provider.

[0041] With these tools available, a first business owner implements a continuous process for producing various products by refining petroleum products at a first process plant, a refinery. The process plant is equipped with various field devices (e.g., valves, tanks, distillation columns, sensors / transceivers, etc.) that sense parameters within the refinery and perform control actions in response to control algorithms that use the sensed parameters as inputs. Each field device has a corresponding input / output device that receives signals from the field device, converts the signals to a common format (e.g., Ethernet packets), and transmits data from the field device to a compute fabric. A pre-configured gateway / router / aggregator that facilitates secure communication between the first process plant (e.g., I / O devices and field devices, collectively comprising a set of physical devices) and the compute fabric is among the only non-field or I / O device hardware located on the premises of the first process plant.

[0042] Configuration engineers of an enterprise and / or process plant access tools made available by system providers to configure the operation of the process plant. The configuration engineers create the required control algorithms by instantiating function blocks to receive data from field devices via I / O devices, send commands and data to the field devices via the I / O devices, instantiate various processing function blocks that utilize the data received from the field devices as inputs to the control algorithms and generate outputs that are sent to the field devices, and implement operator workflows that enable plant operators to monitor and respond to conditions within the runtime process plant. However, in contrast to known, customary, or traditional systems, these function blocks and control modules are not downloaded to dedicated hardware controllers in the process plant. Instead, once the process plant is commissioned (e.g., physical devices are installed and wired in the process plant), the function blocks and control modules are instantiated as containerized services and / or other types of micro-encapsulated execution environments ("MEEEs," also referred to herein as "microservices" or "granules") in the compute fabric.

[0043] In general, a microservice, granule, or MEEE instantiated within a compute fabric may be an independent software process that can run on its own development schedule and can be updated independently of other microservices. Examples of MEEEs may include function blocks, control modules, control applications, and other applications and services related to and / or otherwise supporting the business logic of a process plant, to name a few. A group of microservices or MEEEs may interact in a coordinated manner to achieve some desired result. For example, to control a reactor, multiple strategies, such as feed, reactor, product, utility, and flare, may be defined by respective MEEEs, and this set of multiple MEEEs may operate in a coordinated manner (e.g., in conjunction with each other) during process plant runtime to implement the desired reactor control strategy. In another example, for a process control analytics application, various MEEEs may be defined to perform respective statistical calculations and / or statistical algorithms, and the various MEEEs may be combined and executed in combination as desired to provide an overall predictive analytics application. A single individual microservice or MEEE, as discussed in more detail elsewhere herein, can be configured to run applications ranging from very broad (e.g., a system- or plant-wide control strategy) to very fine-grained (e.g., only a portion of a control routine or control module). Thus, due to its flexibility in being configurable to run a variety of process control and process control-related applications ranging from broad to fine-grained, a microservice or MEEE is referred to herein interchangeably as a "granule."

[0044] In any case, configuration engineers may also use configuration tools to specify various QoS metrics for each function block and control module, for individual signals or variables, and for the entire process. Each microservice, MEEE, or granule communicates with each other and with I / O devices via one or more secure point-to-point (PTP) and / or peer-to-peer (P2P) connections (which may include one or more types of secure, encrypted PTP and / or P2P connections, such as VPNs), each authenticated via digital security certificates. These secure point-to-point and / or peer-to-peer connections and security certificates are managed automatically within the compute fabric with minimal or no input from personnel at the enterprise.

[0045] With respect to QoS metrics, orchestration services operating within the computing fabric (and provided by the system provider) implement various load balancing and redundancy schemes to ensure that the plant's QoS metrics are met. For example, the orchestration service ensures that a redundant configured container is always instantiated for any configured container executing any portion of the control algorithm, and that the redundant configured container maintains corresponding inputs and outputs (i.e., maintains parallel state) to the primary configured container, so that in the event of a failure of the primary container, control can be shifted to the redundant container almost instantly (e.g., within milliseconds). The orchestration service ensures that configured containers run on separate hardware and are powered by separate power sources to maintain sufficient redundancy according to policies set by the enterprise. For some microservices, composed containers, MEEEs, or granules, the orchestration service instead maintains a redundant state database that stores the state of the microservice / composed container / MEEE / granule, so that if a microservice / composed container / MEEE / granule fails or is otherwise taken offline, a new microservice / composed container / MEEE / granule can be instantiated near-instantaneously (e.g., within a few milliseconds) and restored to the state of operation of the previous instantiation of the composed container when it was taken offline.

[0046] The orchestration service also provides load balancing services to maintain sufficient memory, processing, and network resources to meet the QoS requirements for individual microservices / MEEEs / granules and the plant as a whole. For example, a maximum latency requirement may necessitate that a particular configured container be executed on a compute fabric resource that is physically closer to the process plant and / or has greater network bandwidth between the resource and the process plant.

[0047] To maintain security, and as described above, all containerized applications and services communicate through one or more secure, encrypted point-to-point connections, such as VPNs. In some cases, a pair of endpoints (e.g., a pair of containerized applications or services, or a containerized application / service and a physical component) communicates through a dedicated VPN, while other VPNs include multiple containerized applications / services that communicate with each other through respective sessions established over the VPN. Other VPNs facilitate communication between enterprise-level containerized applications / services and plant-level containerized applications / services, still other VPNs facilitate communication between provider-level containerized applications / services and containerized applications / services at the enterprise and / or plant level, and still other VPNs facilitate communication between user interface devices and systems. In any case, any human users and any third-party applications that run to facilitate services within the enterprise or process plant interact with the system through one or more APIs, where necessary actions can be performed after the user or third-party application is authenticated (e.g., using multi-factor authentication).

[0048] In this way, relative to known systems, control of the first process plant is implemented with fewer dedicated computing resources while maintaining (or improving) QoS metrics, maintaining (or further improving) security, and eliminating or reducing the need to periodically and manually adjust the type or amount of local computing resources according to changes in the process plant.

[0049] Example 2 At some point after commissioning the first process plant, the first company owner decides to replicate the first process plant in a second process plant. Because the control algorithms and necessary software are already configured for use in the first process plant, setting up the field devices and I / O hardware in the second process plant is one of the most time-consuming parts of commissioning a process plant.

[0050] In this case, the business owner chooses to remove physical I / O devices from the process plant setup and instead implement the I / O device's functionality as microservices, MEEEs, or granules instantiated in the compute fabric. The business owner installs field devices on-site at the second process plant. Each field device is configured, as is typical, with a device tag, range, limits, scale, and other data for operating the field device. Because the second process plant is a replica of the first process plant, each field device is configured and programmed according to its corresponding device in the first process plant using an automated process to reduce the time required for commissioning. Each device is coupled by its corresponding communication medium to a media converter that converts between the device's native communication medium (e.g., Foundation Fieldbus, HART, WirelessHART, OPC UA, 4-20mA, Ethernet, etc.) and the Ethernet protocol. Each media converter packetizes (in Ethernet packets) various data received from the corresponding field device and sends the packets to a pre-configured on-site gateway at the second process plant. The gateway facilitates secure communication between the second process plant (media converter) and the compute fabric and is one of the only non-field device hardware located on the premises of the second process plant.

[0051] A configuration engineer opens the stored configuration of a first process plant in a user interface application provided by the computational fabric, drags a loop on the computational fabric canvas (a workspace showing the configured containers instantiated in the computational fabric for the first process plant) to select all of the configured containers, and copies the set of configured containers (e.g., containerized applications and services) instantiated in the first process plant to a second process plant by dragging the selected configured containers to a new computational fabric canvas.

[0052] For each field device in the second process plant, the configuration engineer instantiates a digital twin of the field device and corresponding I / O microservices / MEEEs / granules in the compute fabric that take the place of the physical I / O devices that previously coupled the physical field device to the controller. To the rest of the process control software running in the compute fabric, this digital twin is indistinguishable from the hardware field devices operating in the process plant. The digital twin is identically configured and maintains, to the extent necessary (and as described below, possible), the same data that exists in the field device itself. That is, when a field device updates measured parameter values ​​or status values, those values ​​are uploaded to the digital twin in the compute fabric via a media converter. However, it is the digital twin that interacts with the function blocks, control modules, and other control algorithms instantiated in the compute fabric. Similarly, function blocks, control modules, and other control algorithms instantiated in the compute fabric (or hardware controller) send commands and data to the digital twin, which communicates those commands and data back to the hardware field devices of the second process plant via a media converter.

[0053] With the hardware field devices in place and coupled to the digital twin running in the computational fabric via media converters, a configuration engineer commands the computational fabric to bring the process online in the second process plant, for example, by activating a single user control. In response, the computational fabric initializes the process control system, and the system comes online and is then ready to begin testing and / or operation within minutes, greatly simplifying the process of bringing the second process plant online.

[0054] In addition to simplifying its commissioning, the digital twin contributes to the robustness of the operation of the second process plant. If a particular field device becomes unavailable (momentarily or otherwise), the digital twin can prevent abnormal conditions in the operation of the process plant as a whole. For example, a momentary loss of connectivity or increased latency between the process plant and the computational fabric may not affect the overall process because the digital twin can continue to provide data (e.g., simulation data, estimated steady-state data, etc.) to the control algorithm during the momentary anomaly (within safety parameters, of course). Similarly, if a self-reported (or system-determined) state change for a sensor indicates that the sensor value is no longer reliable, the digital twin can be programmed to provide data from another source (e.g., simulated values, values ​​calculated based on other measured parameters, etc.) in place of the unreliable sensor data.

[0055] The use of digital twins also contributes to cost-effective maintainability of process plants: if a hardware sensor (e.g., a thermocouple or pressure sensor) fails, the sensor can often be replaced without stopping or interrupting process operation because the digital twin can continue to provide data (simulated or otherwise) to the control algorithm even when the hardware sensor is offline.

[0056] Example 3 With the first and second process plants operational, the enterprise owner (or its users) may manage both of them at an enterprise level using various tools available from the system provider. Because the various facilities owned by the enterprise run within the compute fabric, the enterprise owner can securely access data related to the process plants individually or the entire enterprise from anywhere, at any time. As noted above, all human and / or third-party application access to the system is provided via APIs, and access to the APIs requires multi-factor authentication. Thus, after authentication, users can access tools, metrics, and other functionality that enable management of the enterprise and its various process plants.

[0057] An enterprise-level user can create or use any number of dashboards and tools to facilitate an enterprise-level view of process plants individually or collectively. The enterprise-level user may decide to view real-time production metrics (e.g., production volume, quality metrics, etc.) for a single plant, or may decide to compare real-time metrics between plants and chart the metrics of each plant over time for comparison. Upon noticing that one plant is performing differently from another (e.g., outputting a higher quality product, operating more efficiently, etc.), the enterprise-level user may decide to dig deeper into why the plants are performing differently. Turning to an application or service marketplace hosted by the system provider, the enterprise-level user may purchase or subscribe to analytical services or tools, which, once purchased or subscribed to, may be instantiated in the computational fabric and used by the enterprise-level user to analyze the performance of the process plants.

[0058] The analysis may indicate that tuning of one of the process plants could be optimized to operate better and recommend a different tool that can retune and optimize the process plant. An enterprise-level user can contact the plant's control operators to inform them of available tools. The tools are then subscribed to or purchased for the enterprise, or simply for individual plants, and instantiated in the compute fabric at the plant and / or enterprise level.

[0059] The tool may determine that the process plant requires retuning in a manner that requires updated copies of one or more control algorithms. In that case, the tool proceeds to create updated control algorithms (with input from the operator). The updated control algorithms are instantiated in the computational fabric but are not initially placed under control of the process plant. Instead, the updated control algorithms are implemented in parallel (e.g., in simulation mode) with the active control algorithms to ensure that they do not adversely affect the operation of the process plant and actually improve the operation of the process plant. Then, when the operator is satisfied that the updated control modules are functioning properly, they immediately switch control of the process to the new control algorithms (e.g., without interrupting the process).

[0060] At the same time, an operator of one of the process plants may notice that the tuning of the process for which he or she is responsible appears to be fluctuating. The operator contacts a customer service representative from the system provider for assistance in determining what is causing the tuning fluctuations, and using dashboards available to the system provider representative, determines that the tuning fluctuations may be the result of several related factors within the compute fabric, including the movement of microservices / MEEEs / granules between hardware resources for load balancing, changes in available processing and network bandwidth, and the physical distance between the compute fabric resources and the process plant in question. The customer service representative may recommend the use of a real-time tuning application.

[0061] The real-time tuning application monitors the latency between the compute fabric and the physical resources in the process plant and automatically adjusts the tuning of the control algorithms to account for changes in latency as a result of network conditions, physical distance, and processor bandwidth. In this example, after implementing the real-time tuning application, the operator notices that the target process is generally more stable.

[0062] However, if the real-time tuning application indicates that there is one control loop that the real-time tuning application cannot automatically tune, the operator and customer service representative, working together, can determine that the control loop in question requires minimum latency, and as a result, the customer service representative can "pin" the configured container associated with the control loop to physical hardware resources in the compute fabric that meet the latency requirements, particularly those that meet the latency requirements due to their physical proximity to the process plant in question. For good measure, the customer service representative can additionally dedicate specific hardware resources to the configured container associated with the control loop to prevent those resources from being loaded to the extent that they would cause latency to detune the process.

[0063] Example 4 Now, a company owner operating multiple process plants may decide that it would be more efficient to consolidate the operators who manage the various processes. While some maintenance and other personnel must be physically present at each process plant, the fact that the compute fabric is essentially securely accessible from any location with sufficient network connectivity allows operators to be located anywhere. Thus, the company owner may decide that they can consolidate all of their operations into three operations centers, spaced approximately equally around the world, so that their operations can continue 24 hours a day without any of their employees having to work outside of their first shift at each location.

[0064] The company owner staffs each operations center with enough operators to operate all of the plants operating worldwide. As a result of the consolidated operations center, the number of staff required is reduced for redundancy (e.g., to account for staff illness, vacation, etc.).

[0065] Example 5 Separately, a second company seeking to improve efficiency in its conventionally designed (first) process plant and expand to add additional process plants wishes to do so by implementing a system provided by a system provider. The system provider establishes an account with the second company, and personnel at the second company subscribe to and / or purchase the necessary and desired tools and packages. Configuration engineers at the second company use tools available from the system provider to convert the configuration files currently running the legacy controllers in the first process plant into configurations of containerized services (e.g., microservices, MEEEs, or granules) running on the compute fabric. Simultaneously, the system provider arranges for the installation of pre-configured gateways at the first process plant site that securely couple I / O devices to the compute fabric. After ensuring that the compute fabric is configured to meet the required QoS metrics, the configuration engineers and operators at the first process plant simulate the operation of the process plant using the configured compute fabric to confirm that it appears properly configured, and then bring the process plant online using the compute fabric.

[0066] When the newly reconfigured process plant is operating using the compute fabric and the legacy controller hardware is no longer powering the process plant, the second business owner maintains the legacy controller configuration rather than retiring it. In fact, the system provider assists business personnel in configuring the legacy configuration of the first process plant so that control of the process plant can fail over to local control using the legacy system if the compute fabric (or network connection to it) becomes unavailable or unstable. Thus, the legacy system runs in parallel as a backup control solution.

[0067] At the same time, the second company owner may decide to keep the safety-instrumented systems (SIS) for the process in place at the first process plant rather than moving them to the computational fabric.

[0068] As the second business owner moves to expand to add new process plants, the second business owner purchases the field devices necessary to install and operate those process plants. Each field device contains a burned-in hardware ID that indicates the manufacturer, model, options, etc. Upon purchasing the field devices, the burned-in hardware IDs of the purchased devices are registered with the second business owner in a database that facilitates configuration of the field devices in the new process plant. A configuration engineer, while configuring the control module, can select each device from the database, causing the compute fabric to create a digital twin for each device that is programmed accordingly. A plant engineer configuring the physical field devices in the new process plant scans each device and places each device according to its hardware ID. As the physical devices connect to the compute fabric through their respective media converters, each is automatically associated with its digital twin based on its hardware ID and programmed (if programmable) according to the programming of that digital twin.

[0069] While additional process plants are configured to operate on the remote compute fabric, the second enterprise owner determines that because only one network provider serves some of the process plant locations, it is still prudent to have a control solution that can maintain safety, if not full operation, of the process plant locations if network connectivity to the remote compute fabric becomes unavailable. Therefore, the enterprise owner physically deploys certain compute fabric resources on-site so that the on-premises compute fabric can maintain safety and / or operation of the process plant in the event of a communication failure between the process plant and the remote compute fabric. The on-premises compute fabric resources run redundant containerized services, microservices, MEEEs, or granules (orchestrated by an orchestrator service in the compute fabric) so that control of the process plant can fail over to the on-premises compute fabric if necessary.

[0070] Exemplary Next Generation Process Control and Automation System Architecture 1A is a block diagram of an example architecture of a next generation process control and automation system ("NGPCAS") 100 that may be utilized to control industrial and / or automation processes. For example, NGPCAS 100 may be used by chemical, petroleum, industrial, manufacturing, filling and packaging, or other types of businesses to manufacture, refine, convert, create, or produce physical materials or products. For ease of reading, NGPCAS 100 will be referred to interchangeably herein as "architecture 100" or "system 100."

[0071] The NGPCAS 100 includes a computational fabric 102 communicatively connected to a plurality (e.g., a pool) of physical devices 105, 108. The plurality of physical devices 105, 108 or pool thereof includes devices that perform physical functions utilized to control industrial or automation processes provided by an enterprise. For example, the plurality of physical devices 105, 108 may include field devices such as valves, valve positioners, actuators, switches, regulators, sensors (e.g., temperature, pressure, level, and flow sensors), spectroscopic devices, pumps, motors, transmitters, etc., some of which may be intelligent field devices. Some of the physical devices 105, 108 may have respective on-board processors, memory, and computer-executable instructions stored in the memory that are executable by the on-board processors to perform, for example, control and / or other types of calculations, alarm functions, and / or other functions associated with controlling an industrial or automation process using the physical devices 105, 108. Physical devices 105, 108 may responsively operate and / or change their behavior based on control signals and / or other instructions received from computational fabric 102, as described in more detail elsewhere herein.

[0072] The pool of physical devices 105, 108 of system 100 may be disposed or physically located at different physical locations, sites, plants, or environments 115, 118 (as illustrated in FIG. 1A ), or the pool of physical devices 105, 108 may be disposed or located entirely at only a single physical location, site, plant, or environment (not shown). The one or more physical locations 115, 118 at which physical devices 105, 108 are disposed are collectively referred to herein as the “field environment 120” of system 100. For example, the field environment 120 of NGPCAS 100 may include one or more buildings, fields or outdoor sites, plants, oil rigs or platforms, rooms, cabinets, etc., in which at least one physical device 105, 108 of system 100 is physically located, and in which the at least one physical device 105, 108 operates with the computational fabric 102 to control an industrial or automation process. The term "field environment 120" is referred to herein interchangeably as the "process environment 120," "automation environment 120," "plant environment 120," or "physical environment 120" of the NGPCAS 100.

[0073] Each physical location or environment 115, 118 in which at least one physical device 105, 108 of system 100 is disposed includes one or more on-premises physical I / O (input / output) interfaces 125, 128 configured to receive, condition, and deliver (e.g., to the computational fabric 102 via one or more transport networks 130) I / O signals or I / O data generated by the on-premises physical device 105, 108, and optionally provide control signals, instructions, and / or other information generated by the computational fabric 102 and received at the location 115, 118 to a designated receiving on-premises physical device 105, 108 via the one or more transport networks 130. Each on-premises physical device 105, 108 physically connects to the on-premises physical I / O interface 125, 128, e.g., via a respective wired or wireless link. Thus, in one embodiment, the on-premises physical I / O interfaces 125, 128 may comprise a pool of I / O hardware ports (which may include wired and / or wireless ports or interfaces) and / or other I / O hardware resources shared among multiple on-premises physical devices 105, 108 at their respective locations 115, 118. Additionally or alternatively, the on-premises physical I / O interfaces 125, 128 may comprise individual instances of I / O hardware resources, each individual instance contained in or exclusively connected to only one on-premises physical device 105, 108. Generally speaking, this disclosure uses the term “physical component” 135, 138 to collectively refer to the combination of a single physical device 105, 108 (e.g., a single field device) and the physical I / O interfaces 125, 128 utilized by the single physical device to communicate information over the transport network 130 (e.g., the associated physical I / O interfaces of the single physical device 105, 108).Thus, in terms of terminology, the NGPCAS 100 includes a pool of physical components 135, 138, each of which includes an individual field device 105, 108 and a respective physical I / O interface resource 125, 128 that the individual field device 105, 108 utilizes to communicate with the compute fabric 102. Generally speaking, the physical components 135, 138 of the NGPCAS 100 operate at or are included within Level 0 of the Purdue model of a conventional process control system.

[0074] 1A , the physical components 135, 138 at each location 115, 118 communicatively connect to the computational fabric 102 via one or more transport networks 130. The one or more networks 130 may include one or more wired and / or wireless networks. Furthermore, the one or more networks 130 may typically include one or more packet networks, such as one or more Ethernet-compatible packet networks, each of which may or may not include an advanced physical layer (APL). Thus, the physical I / O interfaces 125, 128 enable I / O data or information generated by the physical devices 105, 108 to be delivered in packetized form over the one or more transport networks 130. For example, the physical I / O interfaces 125, 128 may convert I / O data or information generated by the physical devices 105, 108 into packets, wrap the I / O data or information in packets, or otherwise convert the I / O data or information into a packetized format for delivery over the packet network 130 to the compute fabric 102.

[0075] In some embodiments, the physical venue or location 115 may include a gateway / router / aggregator 148, referred to herein as a “gateway 148” for ease of explanation. Generally speaking, the gateway / router / aggregator 148 receives outgoing data and information to be sent to the computational fabric 102 and causes the outgoing data and information to be transmitted over the transport network 130 (e.g., in individual packets and / or in packets where data / information generated by multiple physical components 138 are aggregated into a single packet), and the gateway / router / aggregator 148 receives incoming data and information received from the computational fabric 102 (e.g., in individual packets and / or in aggregated packets) and routes the information, instructions, and / or data contained therein to a designated receiving physical component 138 at the venue 115. A physical location may include a respective gateway 148 (e.g., location 115), a physical location may exclude any gateway 148 (e.g., location 118), and in some configurations, for example, multiple physical locations may share a single gateway 148 (not shown in FIG. 1A).

[0076] Referring now to the computational fabric 102 of the NGPCAS 100, the computational fabric 102 is implemented on a scalable hardware platform, portions of which may be physically located across one or more physical locations (not shown in FIG. 1A ). The physical locations where at least a portion of the hardware platform of the computational fabric 102 is physically located may or may not be the physical locations 115, 118 where the physical devices 105, 108 of the system 100 are physically located. For example, the entire hardware platform on which the computational fabric 102 is implemented may be located remotely from any of the locations 115, 118 of the field environment 120 of the system 100 (e.g., as illustrated in FIG. 1A ), or respective portions of the hardware platform on which the computational fabric 102 is implemented may be located at one or more of the physical device locations 115, 118 of the field environment 120 (not shown in FIG. 1A ). In some embodiments, at least a portion of the computational fabric 102 may be implemented on a cloud computing platform, the hardware of which may be remote from and / or located at the physical locations 115, 118 of the field environment 120 of the system 100.

[0077] The compute fabric 102 of the NGPCAS 100 supports the creation, execution, removal, maintenance, operation, and management of containerized applications and / or services or pools thereof 140, which are generally referred to interchangeably herein as “containerized components 140 or pools thereof,” “microencapsulated execution environments 140 (MEEEs 140) or pools thereof,” or “granules 140 or pools thereof” of the NGPCAS 100. That is, the containerized components / pools of microencapsulated execution environments / granules 140 may include applications and / or services configured in containers and / or other types of microencapsulated execution environments or granules, each of which may execute to provide specific functions and / or operations utilized by the system 100 to control physical devices 105, 108, support process and / or automation control and system management, and operate, maintain, and manage the system 100 and its components over its lifetime. Generally speaking, the containerized components / MEEEs / granules 140 of the NGPCAS 100 provide the functionality that traditional process control and automation technologies implement across multiple systems, networks, computing devices, DMZs, firewalls, and applications that typically operate across Levels 1-5 of the Purdue model, from, for example, basic control of the physical industrial equipment and processes of the system 100 at Level 1 to enterprise-level IT functions providing business direction and functionality related to the system 100 at Level 5. Additionally, the containerized components / MEEEs / granules 140 may provide even higher-level functionality, such as coordination and / or management among multiple systems 100 of an enterprise, and even coordination among multiple enterprises.Thus, advantageously, rather than utilizing the cumbersome and resource-costly traditional architecture of Purdue Levels 1-5, and all of the numerous data diodes, firewalls, DMZs, etc. required to secure a process control or automation system in such traditional architectures, NGPCAS 100 simply utilizes a set of containerized components / MEEEs / granules 140 running within the compute fabric 102 to perform the same or similar set of core and related process control and automation functions, without compromising, and in many cases increasing, the security of the system 100. A more detailed discussion of the security techniques utilized within the architecture of NGPCAS 100 is provided elsewhere within this disclosure.

[0078] Typically, different functions are implemented by different containerized components / MEEEs / granules 140 within the computational fabric 102. A single application or service may be configured into multiple different containerized components / MEEEs / granules 140 (e.g., different instances of the application or service implemented in each container) as needed, for example, to run with different physical devices, to run on different portions of the computational fabric 102 hardware platform, to create redundancy or hot spares, etc. Various containerized components / MEEEs / granules 140 may be created (e.g., spun up) and / or removed as needed or required by the system 100. Collectively, a group of containerized components / MEEEs / granules 140 may operate to form or provide a logical process control or automation system 145 (also interchangeably referred to herein as a “virtual process control system” 145) for controlling one or more industrial or physical processes by controlling and utilizing physical components 105, 108 disposed within the field environment 120 of the NGPCAS 100. Typically, but not necessarily, the group of containerized components / MEEEs / granules 140 that form the logic process control system 145 is a subset of the total number of containerized components / MEEEs / granules 140 provided by the computational fabric 102.

[0079] During execution, each containerized component / MEEE / granule 140 may be communicatively connected to a particular physical component 135 / 138 or another containerized component / MEEE / granule 140 via a respective packet-based connection over the transport network 130. Accordingly, each containerized component / MEEE / granule 140 and each physical component 135 / 138 of the NGPCAS 100 is identified within the system 100 by a unique name, identifier, or identification that may be associated with a particular address (e.g., an IP address) within the transport network 130. Generally speaking, a physical component 135 / 138 may be a sender or provider of I / O data and information that is received or consumed by one or more containerized components / MEEE / granules 140. In some scenarios, a containerized component / MEEE / granule 140 may be a sender or provider of control signals or other instructions that are received or consumed by a physical component 135 / 138. In some scenarios, a containerized component / MEEE / granule 140 may be a sender or provider of data that another containerized component / MEEE / granule 140 receives or consumes. To maintain security of the NGPCAS 100, the containerized component / MEEE / granule 140 and the physical component 135 / 138 may be authorized and authenticated, component by component, and optionally pairwise with each other, for example, by using keys or any other suitable authorization and authentication technique. Upon successful authorization and authentication, the two endpoint components 140, 135 / 138 may communicate data, instructions, and other information with each other during a session that the two endpoint components 140, 135 / 138 establish over one or more networks 130.

[0080] To further secure the NGPCAS 100, the one or more transport networks 130 may include one or more secure point-to-point (PTP) and / or peer-to-peer (P2P) connections, which may include one or more secure, encrypted point-to-point and / or peer-to-peer connections, such as a virtual private network (VPN), as well as other types of secure, encrypted PTP and / or P2P connections. In one embodiment, a particular containerized component / MEEE / granule 140 communicatively connects to a particular physical component 135 / 138 using a secure, encrypted point-to-point or peer-to-peer connection (such as a VPN or other suitable implementation) that is exclusive to only the particular containerized component / MEEE / granule 140 and the particular physical component 135 / 138. For example, a particular physical component 135 / 138 and a particular containerized component / MEEE / granule 140 may be endpoints of an exclusive point-to-point VPN utilized only by the two endpoint components 135 / 138 and 140 (e.g., not utilized by other components of system 100), such that the components 135 / 138, 140 may securely communicate data, messages, instructions, and / or other information with each other via the exclusive point-to-point VPN. In a similar manner, a particular containerized component / MEEE / granule 140 may communicatively connect to another particular containerized component / MEEE / granule 140 using a secure, encrypted peer-to-peer (P2P) connection (which may or may not be implemented via a VPN) that is exclusive to only the two containerized components / MEEE / granules, and the two containerized components / MEEE / granules may securely communicate data, instructions, and / or other information with each other via their exclusive, secure, encrypted peer-to-peer connection.Exclusive point-to-point and / or peer-to-peer connections between a single containerized component / MEEE / granule 140 and either a single physical component 135 / 138 or a single other containerized component / MEEE / granule 140 may be established as needed or when needed, and may be dismantled when desired (e.g., upon completion of data exchange, when system resources need to be freed, etc.).

[0081] In one embodiment, a single physical location 115, 118 may be communicatively connected to the compute fabric 102 via a secure, encrypted inter-location PTP or P2P connection (such as an inter-location VPN or other suitable implementation) that is exclusive to the particular location 115 / 118 and the compute fabric 102 (not shown). The physical components 135 / 138 disposed at the particular location 115 / 118 and the containerized components / MEEEs / granules 140 executing on the compute fabric 102 may communicate data and information with each other via the inter-location PTP or P2P connection. To illustrate, in the exemplary arrangement shown in FIG. 1A , location 1 (reference numeral 115) includes an on-premises gateway / router / aggregator 148 that establishes an inter-location VPN with the compute fabric 102; e.g., such that the on-premises gateway 148 is one endpoint of the inter-location VPN and the VPN gateway application 150 executing on the compute fabric 102 is the other endpoint of the inter-location VPN. The containerized components / MEEEs / granules 140 and physical components 105 located at locations 115 may authenticate to the inter-location VPN and establish respective sessions over the inter-location VPN (e.g., via VPN gateway application 150 and on-premise gateway 148) to communicate data and information with each other. Additionally or alternatively, architecture 100 may support inter-location VPN subnets, such that various physical components 135 / 138 and various containerized components / MEEEs / granules 140 located at locations 115 communicate with each other over one or more subnets within the inter-location VPN. Furthermore, in the above examples, types of secure encrypted PTP and / or P2P connections other than VPNs may additionally or alternatively be utilized.

[0082] In one embodiment, a multiple-location (e.g., multi-point) secure encrypted connection may exclusively service the compute fabric 102 and physical components 135 / 138 located at multiple selected physical locations 115, 118 of the system 100, where the selected physical locations are a subset of all physical locations serviced by the system 100. In this embodiment, each of the multiple physical locations 115, 118 may include a respective on-premises gateway 148 to the multiple-location secure encrypted connection and may be associated with one or more gateway applications 150 executing on the compute fabric 102. The various physical components 135 / 138 located at the multiple locations and the containerized components / MEEEs / granules 140 corresponding to the multiple locations may authenticate to the multiple-location secure encrypted connection and establish sessions (e.g., via one or more gateway applications 150 and respective on-premises gateways 148) over the multiple-location secure encrypted connection to send and receive data and information to and from the other components 140, 135, 138. Secure encrypted connections between multiple locations may be implemented using VPNs or other suitable mechanisms, as desired, including multiple PTP and / or P2P connections, point-to-multipoint (PTM) connections, etc.

[0083] In one embodiment, all of the containerized components / MEEEs / granules 140 of the compute fabric 102 and all of the physical components 135 / 138 of all of the physical locations 115 / 118 of the NGPCAS 100 may be served by a single system-wide secure encrypted connection, which may be implemented as a system-wide VPN or other suitable type of system-wide secure encrypted connection. Each of the containerized components / MEEEs / granules 140 and physical components 135 / 138 of the system 100 may authenticate to the system-wide connection and establish sessions with the other components 140, 135, 138 (e.g., via respective on-premises gateways 148 and one or more gateway applications 150) over the secure encrypted system-wide connection to send and receive data and information to and from the other components 140, 135, 138.

[0084] Furthermore, as desired, various secure encrypted PTP, P2P, PTM, and / or multipoint connectivity technologies may be combined (e.g., by utilizing subnets) to provide even greater security. For example, certain physical components 135 / 138 and certain containerized components / MEEEs / granules 140 may establish and utilize an exclusive point-to-point VPN as a subnet of a location-to-location VPN, and a group of containerized components / MEEEs / granules 140 may be included in a subnet supported by the computing fabric 102, etc. Still further, any of the secure encrypted connectivity technologies used within the NGPCAS 100 may be utilized in conjunction with endpoint authorization and authentication technologies, thereby providing even greater security for the NGPCAS 100.

[0085] Still further, in some implementations, in addition to or instead of using a VPN as discussed above, one or more transport networks 130 may utilize one or more point-to-point private connections (such as point-to-point and / or peer-to-peer Ethernet connections over a private enterprise network and / or other types of secure, encrypted PTP, P2P, MTP, and / or multipoint connections) to securely deliver information between one or more components of the NGPCAS system 100. For example, a point-to-point private connection may be established between two components 138, 140, between a physical site 115, 118 and the compute fabric 102, etc. However, for ease of discussion herein, the description will refer to “VPN” technology (and not by way of limitation) but is intended to generally and categorically describe secure transport over the network 130, with it being understood that any of the systems, methods, and techniques described herein may additionally or alternatively utilize other types of secure, encrypted point-to-point, peer-to-peer, and / or multipoint connections for secure transport.

[0086] Users 155 of NGPCAS 100 may authenticate to VPN 158 to interact with NGPCAS 100 (e.g., interact with components 140, 135 / 138 of NGPCAS 100), for example, to view or obtain data and / or other information, change parameter values, configure or modify the configuration of control routines and other aspects of system 100, etc. As used herein, "user" 155 may be a personnel or human user, or user 155 may be an application or service, e.g., an automation user, running on an external computing device not included in system 100. Users 155 illustrated in FIG. 1A may be equivalent to people and applications / services that have access to data and information associated with a traditional process control or automation plant, for example, at any of Levels 1-5 of the Purdue Model.

[0087] Human user 155 may be personnel who are agents of an enterprise that owns, manages, operates, or is otherwise associated with NGPCAS 100. For example, user 155 may be an enterprise configuration engineer, system operator, asset manager, supply chain manager, project or product manager, technician, installer, authorized third party (e.g., contractor), business manager, etc. Typically, human user 155 interacts with NGPCAS 100 via a user-operated computing device (e.g., laptop, tablet, mobile computing device, in-vehicle computing device, etc.) on which an application, web browser, or similar executable runs to provide both a user interface operable by human user 155 and a secure communications connection with NGPCAS 100 via VPN 158. For example, a human user 155 may utilize their computing device to interface with the NGPCAS 100 using a particular MEEE 140 (e.g., an app downloaded from the compute fabric 102) configured and authenticated to run on the user-operated computing device, or the human user 155 may utilize a web browser running on the user-operated computing device. In another example, the user 155 may be an automated user of an external application or service, e.g., an application or service running on an external computing device or system. The automated user 155 may not present any user interface to the human user, but may still establish a communications connection with the NGPCAS 100 via the VPN 158 to obtain or provide data and / or other information. Examples of automated users 155 include third-party generated applications, external data sources (such as weather data sources, material management systems, etc.), etc.In some circumstances, the automated user 155 may be a particular containerized component or MEEE 140 that is configured and authorized to run on a remote computing device or system.

[0088] In any event, regardless of whether user 155 is a human user or an automated user, user 155 utilizes APIs (application programming interfaces) 160 (via a VPN 158 authenticated by user 155) to securely access data and / or other information in NGPCAS 100. In an exemplary implementation, different APIs 160 may be utilized by user 155 to access different containerized components / MEEEs / granules 140 and physical components 135 / 138 of computational fabric 400. In additional or alternative implementations, a single API 160 may be utilized by user 155 to access NGPCAS 100, and API 160 may form communication connections within NGPCAS 100 with containerized components / MEEEs / granules 140 and physical components 135 / 138 as needed to obtain or provide desired data and / or information to / from user 155. One or more APIs 160 may themselves be, for example, containerized components / MEEEs / granules 140 of the compute fabric 102.

[0089] 1A is the architecture provider / manager 161 of the NGPCAS 100. Generally, the architecture provider / manager 161 provides the operations, management, and support of the NGPCAS 100 and, optionally, of other systems 100 of the enterprise and / or one or more systems of other enterprises (e.g., the systems' respective architectures, hardware, and software resources, etc.). For example, the architecture provider / manager 161 may be under the authority of the provider of the system 100. The architecture provider / manager 161 may have exclusive access to a set of applications and services (e.g., which in one embodiment may be a subset of the overall set of containerized components / MEEEs / granules 140 provided by the compute fabric 102) that may be created, configured, and / or executed by the provider and / or manager 161 of the NGPCAS 100. In a sense, the architecture provider / manager 161 operates and manages the architecture platform resources utilized by one or more NGPCASs 100 through this set of applications and services, and thus may perform a broader range of logic functions, such as engineering across various enterprise systems, providing an application / service "store" containing a library of various applications and / or services, instances of which the architecture provider / manager 161 may configure and distribute to NGPCASs 100 for their use, distributing and / or reallocating system resources among different physical locations, etc. Each application or service created, configured, and utilized by the architecture provider / manager 161 may be implemented by one or more containerized components / MEEEs / granules 140.1A , architecture provider / manager 161 (whether a human user or an application or service running on a remote computing device) may authenticate to VPN 162 and utilize one or more APIs 165 to securely read and / or write data and / or other information, send instructions, and / or interface with various other containerized components / MEEEs / granules 140 and physical components 135 / 138 of NGPCAS 100. One or more APIs 165 may themselves be, for example, containerized components / MEEEs / granules 140 of compute fabric 102.

[0090] In one embodiment, different subsets of containerized components / MEEEs / granules 140 may communicate with specific physical components 135 / 138, specific locations 115, a specific set of multiple locations, all physical locations across an enterprise, or each physical component and / or each physical location of multiple different enterprises via respective VPNs 162. For example, containerized components / MEEEs / granules 140 utilized exclusively by architecture provider / manager 161 may communicatively connect with other containerized components / MEEEs / granules 140 and / or physical components 135 / 138 of the enterprise via a provider-specific VPN 162 that is different from the VPN utilized by other containerized components / MEEEs / granules 140 of the enterprise to communicate with the physical components 135 / 138 at the enterprise locations. In another example, containerized components / MEEEs / granules 140 provided by architecture provider / manager 161 may utilize a first enterprise-specific VPN 162 to communicate with containerized components / MEEEs / granules 140 and physical components 135 / 138 of a first enterprise and may use a different, mutually exclusive, enterprise-specific VPN to communicate with containerized components / MEEEs / granules 140 and physical components 135 / 138 of a second enterprise (not shown). Thus, architecture provider / manager 161 can securely and independently operate and manage resources of different parts of a single enterprise and / or different enterprises in a highly secure manner. Indeed, by using one or more of the VPN techniques described herein, alone or in combination, the security of NGPCAS 100 (and in some circumstances, of multiple NGPCASs 100 supported by architecture provider / manager 161) can be customized as desired or needed.

[0091] Thus, in view of the above discussion, the containerized components / MEEEs / granules 140 provided by the compute fabric 102 of the NGPCAS 100 include runtime logic functions (e.g., control and automation logic, data acquisition, etc.) that traditional process control and automation systems typically implement at Levels 1 and 2 of the Purdue model. The containerized components / MEEEs / granules 140 also relate to runtime logic and include other logic functions that traditional process control and automation systems typically implement at Levels 2 and 3 of the Purdue model, such as: system and component deployment, engineering, configuration, provisioning, commissioning, system, device, application / service, and user security, safety logic and systems, networking, monitoring, analytics, industrial process and equipment / asset maintenance and diagnostics, simulation, testing, fault and performance degradation detection and repair / recovery, operator interface, redundancy, backup, other functions related to the availability of the system 100 and its components and equipment, data historization, regulatory compliance, manufacturing or production workflow, execution, and operation management, etc. Additionally, containerized components / MEEEs / granules 140 may include logic functions typically provided in traditional process control systems at higher levels 4-5 of the Purdue model, such as enterprise resource planning, production scheduling, material usage, shipping, inventory levels, and other enterprise-level functions. Still further, such containerized components / MEEEs / granules 140 may include logic functions introduced into the compute fabric 102 via a third party, such as applications and / or services created by a third party and approved and licensed by the enterprise for use within the NGPCAS 100.

[0092] Additionally, the set of containerized components / MEEEs / granules 140 provided by the compute fabric 102 may include containerized components / MEEEs / granules 140 in the networking layer (not shown in FIG. 1A ) of the compute fabric 102, where such containerized components provide lower-level logic functionality that can be utilized by or in conjunction with other containerized components / MEEEs / granules 140 as needed. Such lower-level logic functions may include, for example, a set of APIs 160, 165 utilized by a user 155 to interface with the various containerized components / MEEEs / granules 140 and physical components 135 / 138 of the NGPCAS 100; computational functions (e.g., for allocating and re-allocating various containerized components to compute fabric nodes Ny and / or data center clusters Cx, as discussed in more detail elsewhere herein); storage functions (e.g., for managing and allocating storage area for working data associated with running containerized components); networking functions (e.g., for data and information delivery between various containerized components, their mechanisms, timing, etc.); other services (e.g., discovery, security, encryption, certificate authority, key management, authentication, time synchronization, service location, console support, service lifecycle management, etc.) that may be utilized by containerized components / MEEEs / granules 140 executing at the application layer (not shown in FIG. 1A ) of the compute fabric 102;

[0093] Furthermore, the set of containerized components / MEEEs / granules 140 provided by the compute fabric 102 may include further lower-level logic functionality (e.g., calculations, utilities, primitives, etc.) that may be utilized by the containerized components / MEEEs / granules 140 in the application and networking layers of the compute fabric 102. Examples of such functionality include computational functions (e.g., data aggregations and / or manipulations such as average, max, min, etc.), more complex calculations or algorithms (e.g., principal component analysis (PCA), partial least squares (PLS) predictions, and other types of statistical calculations and / or analyses), process control or automation specific calculations (e.g., function blocks, shadow blocks, control module operations, etc.), to name a few.

[0094] 1A illustrates location n 118 as including a backup control system 168 that may be partially or fully failed over to maintain runtime operation of the process control system 100 at location n 118 when one or more remote portions of the system 100 (e.g., transport network 130, compute fabric 102, etc.) are impaired, incommunicative, or otherwise inoperable. For example, the backup control system 168 may include a conventional legacy control system and / or may include a backup copy or virtual twin of at least a portion of the virtual process control system 145 running on a computing platform located on-premise with location n 118.

[0095] Therefore, in view of the above, the computational fabric 102 of the NGPCAS 100 provides the process control and automation functions and related functionality that must be performed in a traditional process control system by different equipment and systems distributed across Purdue Levels 1-5, and also provides additional lower-level functionality (e.g., from networking and platform resource management to computation and primitives) that is available throughout the system. Additionally, the NGPCAS 100 advantageously eliminates the need for a DMZ at Level 3.5 and other levels, as well as the need for firewalls, data diodes, and other architectural security devices and mechanisms utilized in traditional process control and automation systems, while simultaneously providing a more secure system 100.

[0096] In particular, as described above, any data or information transfer between two components of the NGPCAS 100 (e.g., two different containerized components / MEEEs / granules 140, or a containerized component / MEEE / granule 140 and a physical component 125 / 135) may be accomplished via a VPN, e.g., a private session on a VPN utilized by the physical locations where the compute fabric 102 and the physical component 102 are located, a private VPN utilized only by the endpoint components, and / or one or more other types of VPNs. Furthermore, for security purposes, any and all users 155 / 160 may be required to access the system 100 via one or more APIs 162 / 165 and a private VPN 158 / 162 established between the users 155 / 160 and the compute fabric 102. Furthermore, all users may be required to undergo multi-factor authentication before gaining access to the system 100 via the APIs 162 / 165. In this manner, system data is exposed only to private addresses (e.g., addresses of components, compute fabric nodes, etc.) via VPNs and authorized and qualified entities. Applications may be exposed as websites or services, such that computing devices utilized by users access system 100 via "thin" clients and do not have any system-related software running thereon (except perhaps thin client applications such as portal applications). Furthermore, all applications, including those running locally at the physical location where the physical device is located, may be containerized, and any system data may be encrypted at rest.

[0097] Additionally, within NGPCAS 100, all communications sent and received over network 130 may be signed and encrypted, and plaintext protocols may be prohibited. Furthermore, each NGPCAS 100 may have a single certificate authority (which may be associated with a company, for example), and self-signed certificates and / or other forms of custom authentication may be prohibited.

[0098] FIG. 1B illustrates a block diagram of an example architecture for a next-generation process control and automation system (“NGPCAS”) 100A having the basic components of system 100 of FIG. 1A but configured to support industrial and / or automation processes having installed or legacy distributed control systems, such as a DeltaV® control system. In this case, NGPCAS 100A includes all of the components of system 100 of FIG. 1A but is connected to one or more plants or physical locations 115A and 118A that already have installed legacy control systems implemented therein. As illustrated in FIG. 1B, locations 115A and 118A may have a distributed controller 170, such as a DeltaV controller, connected via various input / output (I / O) devices 172 to various field devices 174, such as smart field devices, which may communicate with I / O devices 172 using any desired or typical wired or wireless communication network. The field devices 174 may be, for example, 4-20 mA, HART®, WirelessHART®, FOUNDATION® Fieldbus, Profibus, Canbus, APL, or any other communication protocol compatible field devices that communicate using any standard or known communication network or physical layer and communication protocol, including process control communication protocols (e.g., HART, Fieldbus, etc.), wherein the process controller 170 may store and implement legacy control programs that may use, for example, function blocks, control blocks, etc., to control the field devices 174.

[0099] 1B , the process controllers 170 may be connected to a data aggregator and VPN gateway 180 installed or located at the physical locations or plants 115A and 118A, which in turn are connected to elements within the computational fabric 102 via secure VPN links 130. The VPN gateway 180 operates as a data aggregator to collect data from the process controllers 170, or in another embodiment, directly from the I / O devices 172 (illustrated by dotted lines at location 115A) to acquire, manage, transform, aggregate, and collect data from the field devices 174. The VPN gateway 180 also operates to encrypt the collected data and provide it to other components within the computational fabric 102 (which use the data to perform control or other services) via the VPN or other secure, encrypted communication links 130. In the case of location 115A, NGPCAS 100A may simply bypass controller 170 to obtain data from field devices 174 and I / O devices 172 in a manner similar to that illustrated with I / O interfaces 125 and 128 and field devices 135 and 138 in Figure 1A. In this case, controller 170 may be operated and programmed to be a backup control system 168 as illustrated in Figure 1A, such that controller 170 at location 115A takes over control of field devices 174 at location 115A in a failover or backup situation.

[0100] On the other hand, as illustrated with respect to physical location 118A in FIG. 1B , controller 170 may operate as part of computational fabric 102, in which software modules, such as containers, associated with computational fabric 102 may be stored and operated. In this case, controller 170 (at location 118A) is part of computational fabric 102, as illustrated by the computational fabric box in FIG. 1B extending into physical location 118A to include controller 170. Thus, in this case, computational fabric 102 may include cloud-based computing devices and computing devices (e.g., controller 170) located at physical plant locations that are not in the cloud. Furthermore, in this case, controller 170 at location 118A may operate with other computing equipment in computational fabric 102 (e.g., computing equipment in a cloud environment) to implement control of field devices 174 at physical location 118A.

[0101] In both examples of FIG. 1B , data aggregator and VPN gateway 180 is included to enable the NGPCAS described herein to connect to and use installed legacy control system hardware (e.g., process controllers, field devices, I / O devices), making it easier and less expensive to install and use the NGPCAS described herein in a plant or other physical location where control hardware is already installed. Thus, VPN gateway 180 enables the NGPCAS system 100A described herein to be used to quickly and easily convert a standard legacy control system, such as a distributed control system, to an NGPCAS. Of course, while FIG. 1B illustrates the legacy or installed control system as a distributed control system, other legacy or installed control systems may be used in the same or similar manner to support an NGPCAS.

[0102] Exemplary NGPCAS Architecture Including Digital Twin As mentioned above, in some implementations of the NGPCAS 100, the computational fabric 102 may facilitate the use of a “digital twin” of one or more of the on-premises physical devices 105, 108. FIG. 2A illustrates a system 200 representing a portion of an example NGPCAS 100 in which multiple on-premises physical devices 202A-202D communicate with respective media converters 206A-206D via respective physical interfaces 204A-204D. For example, in FIG. 2A, Foundation Fieldbus device 202A is coupled via Foundation Fieldbus interface 204A to media converter 206A, which converts signals received from and transmitted to device 202A between the Foundation Fieldbus protocol and an Ethernet-compatible or other suitable packet protocol. Similarly, HART device 202B is coupled to media converter 206B via HART interface 204B, which converts signals received from and transmitted to device 202B between the HART protocol and an Ethernet-compatible / packet protocol. Other transmitters, sensors, and field devices may use other protocols, as will be understood. For example, devices 202C and 202D may each be a 4-20 mA device, and media converters 206C and 206D may convert the signal from 4-20 mA to an Ethernet-compatible / packet protocol (e.g., by packetizing the value of the 4-20 mA signal and placing it on the network).

[0103] Ethernet connections 208A-208D couple media converters 206A-206D to computational fabric 102, and in particular to digital twins 210A-210D of respective on-premise physical devices 202A-202D. Ethernet connections 208A-208D may each, in an embodiment, be directly connected to computational fabric 102 (as shown in FIG. 2A ), or perhaps more likely, Ethernet connections 208A-208D may each, in an embodiment, be connected to computational fabric 102 via one or more network switches (not shown), including via one or more APL switches (not shown) and / or one or more on-premise gateways (e.g., gateway 148).

[0104] Each of the digital twins 210A-210D, as the name implies, is a “virtual twin” of the on-premises physical device, device, or group of devices to which it is coupled (and which it represents). That is, each digital twin mimics electronic functions, rather than physical functions, such as sensing and actuation of one or more sensors, transmitters, actuators, etc. A digital twin may correspond to a single device (e.g., a pressure transmitter, a temperature transmitter, an actuator, etc.), a group of devices (e.g., a valve with upstream and downstream pressure transmitters and a valve position sensor), or a class of devices (e.g., a mass flow device). FIG. 2B illustrates this concept in more detail with respect to a Foundation Fieldbus on-premises physical device 202A. As illustrated in FIG. 2B, the device 202A generally has stored in memory several parameters and variables 220A-220J that are addressable and / or retrievable and / or otherwise available to the process control system, and in particular, available to the control algorithms that control the device 202A. Of course, a Fieldbus device such as device 202A includes one or more commonly known sets of parameters and values, including measurements 220A, setpoints 220B, upper and lower limits 220E, alarms 220D, one or more device statuses 220C, a device ID 220H, a device tag 220I, a device description 220G, a scale 220F, and / or other information 220J, such as range information, state information, etc., while other types of devices may additionally or alternatively include other parameters and values, and still other devices may be capable of providing only a single transmitter value (e.g., pressure, temperature, etc.). A digital twin 210A corresponding to device 202A is implemented in the computational fabric 102 (or in a non-computational fabric implementation, if desired) and maintains an up-to-date copy of the data 220A-220J stored in device 202A, which are indicated in FIG. 2B by reference characters 220A′-220J′.Additionally, digital twin 210A writes to device 202A any settings, other relevant data, and / or other commands 220A'-220J' that it receives.

[0105] 2A , each of the digital twins 210A-210D is typically coupled via the computational fabric 102 to function blocks, control modules, and other control algorithms that receive data from (and / or send data to) the devices 202A-202D. For example, the AI / DI function blocks 212A-212D may receive raw data from the digital twins 210A-210D, and as data typically flows to the devices 202A-202D, the AO / DO function blocks 214A, 214B may send data to the digital twins 210A, 210B, which then sends this data back to the physical devices 202A, 202B. The control algorithm 216 receives data from and sends data to the digital twins 210A-210D to operate on the data, regardless of whether the digital twins 210A-210D are physical or logic devices. In this way, the final hardware (e.g., physical devices 202A-202D) is abstracted from the control algorithms 216 that operate the process plant via the digital twins 210A-210D.

[0106] In contemplated systems implementing the computational fabric 102, the digital twins 210A-210D may, in embodiments, be implemented as microservices (or other microencapsulated execution environments) running together or in separate containers. In one embodiment, each digital twin 210A-210D identifies itself within the system 100 using the unique network identifier or address of the respective physical device 202A-202D that the digital twin 210A-210D mirrors. Thus, other containerized components of the computational fabric 102 may communicate with an intended physical device 202A-202D by using the physical device's unique identifier and may remain unaware of whether the entity with which it is communicating is the actual physical device 202A-202D or its digital twin 210A-210D. Thus, in a sense, each digital twin 210A-210D may serve as a proxy within system 100 for the respective physical device 202A-202D that it mirrors. In further embodiments, in a similar manner to other containerized components / MEEEs / granules 140 of the compute fabric 102, containerized digital twins may be nested according to, for example, area of ​​the process plant, type of device, associated control modules, etc. Of course, AI, AO, and control algorithm modules may similarly be implemented as containerized services or microservices.

[0107] Digital twins 210A-210D may, in an embodiment, be created automatically from descriptions of the respective physical devices 202A-202D that they represent.

[0108] As described herein and illustrated in FIGS. 2A and 2B, there are various advantages that can be realized using digital twins. One advantage is that the digital twins 210A-210D can be programmatically configured to prevent abnormal conditions within the process plant that might otherwise be caused by minor malfunctions within the physical devices 202A-202D. For example, if measurements within the physical devices become unreliable, the digital twins 210A-210D can maintain up-to-date values ​​of the measurements (or provide predicted or simulated values) to maintain stable and safe operation of the process plant, even in the absence of actual measurements provided by the physical devices 202A-202D. Similarly, devices (particularly transmitters) that are malfunctioning, needing maintenance, or requiring calibration can be replaced, repaired, or calibrated without necessarily having to shut down the entire process, because the control algorithm 216 is unaware that the device is absent or not transmitting accurate (or any) data.

[0109] Another potential benefit of using a digital twin is that it can contribute to the ability of the systems described herein to be commissioned with less effort, expense, and time. By way of example and not limitation, a new plant (or portion thereof) identical to an existing plant (or portion thereof) can be almost completely instantiated within the computational fabric 102 with physical devices 202A-202D coupled thereto by Ethernet. If systems other than physical devices 105, 108 are instantiated within the computational fabric 102, the entire process control plant (or at least elements within the computational fabric 102) can be instantiated within minutes, and automatic discovery (e.g., using device tags, including hard-coded device tags) can determine which devices to connect to the various containerized applications, containerized services, microservices, MEEEs, or granules instantiated within the computational fabric 102.

[0110] Yet another advantage of employing a digital twin is that the digital twin, whether directly connected to a control algorithm (i.e., whether the control algorithm interfaces directly with the digital twin or with physical devices (e.g., 202A-202D) within the process plant), can be used to generate predictions regarding the future state of processes and / or physical devices. These future predictions can be generated using statistical models, mechanistic models, or a combination of statistical and mechanistic models. These models, running within the digital twin (e.g., as nested, containerized components / MEEEs / granules), receive data from the physical devices and control algorithms and can provide assessments of control systems (e.g., a control system trending toward an abnormal condition), field devices (e.g., a sensor is likely failing or appears to have failed), etc. This information can then be used to provide recommended mitigation or corrective actions to operators, maintenance personnel, or others.

[0111] Yet another benefit afforded by the use of digital twins is the introduction of new sources of soft-sensor data. Just as a group of physical devices (e.g., upstream and downstream sensors and a valve position sensor) can be represented by a single digital twin of a valve that embodies those three elements, a group of measurements (acquired by each physical device) can be collected by the digital twin and used as a "soft sensor" that provides an indirect measurement of another value. For example, a digital twin might receive values ​​from four transmitters—two pressure transmitters, a pressure transmitter, and a temperature transmitter—that together provide a differential pressure measurement and combine them into a soft-sensor measurement for mass flow rate.

[0112] Furthermore, the digital twins described above can also be implemented in traditional process plant environments. For example, an on-premise computing device may instantiate digital twins of various physical devices within a process plant, even if the process plant implements traditional I / O and controllers. One such exemplary arrangement is illustrated in FIG. 2C.

[0113] Exemplary Multi-Enterprise NGPCAS Architecture The Next Generation Process Control and Automation System (NGPCAS) 100 described in the preceding sections of this disclosure provides several enterprise-level benefits to any particular enterprise utilizing one or more NGPCASs 100 to implement industrial and / or automation processes. Examples of such benefits will be discussed herein with respect to Figures 3A and 3B.

[0114] 3A illustrates the logic arrangement of an exemplary multi-enterprise framework 300 including different enterprises 302, 304. Each enterprise 302, 304 utilizes a respective NGPCAS to implement an industrial or automation process (or, in some cases, multiple different industrial and / or automation processes) across physical device locations 312 / 314 and 316 / 318. In one embodiment, each NGPCAS of an enterprise 302, 304 may be a respective instance of NGPCAS 100, each of which may be specifically configured for that enterprise 302, 304. Accordingly, this disclosure will refer to the enterprises 302, 304 interchangeably as "enterprise NGPCAS 302, 304" or simply "NGPCAS 302, 304." NGPCASs 302, 304 each include enterprise-level compute fabric functions 320.1-320.2, which are comprised of containerized applications and / or services that operate within the compute fabric of each NGPCAS 302, 304 to control process devices and provide other process functions (e.g., operations, maintenance, diagnostics, monitoring, etc.) that service the processes implemented via NGPCASs 302, 304. For example, at least some of enterprise-level compute fabric functions 320.1-320.2 may be provided by architecture provider / manager 161 via subscription, download from an application or service store, etc. Enterprise-level compute fabric functions 320.1, 320.2 may be implemented, for example, in the manner described with respect to containerized components / MEEEs / granules 140 of FIG. 1A .

[0115] In some embodiments, the computational fabric functions 320.1, 320.2 execute in different portions of a shared computational fabric (e.g., sharing at least some computational fabric nodes between enterprises 302, 304), and security for the computational fabric functions 320.1, 320.2 is secured to each enterprise 302, 304 using the security mechanisms of this disclosure (e.g., even if components of the computational fabric functions 320.1, 320.2 execute on the same computational fabric nodes, such components operate as separate containerized components, and security and access are managed independently for each separate containerized component). At least a portion of the computational fabric functions 320.1, 320.2 may be accessed and operated by authorized users / computing devices (e.g., human or automated users 155 and / or architecture providers / managers 161 of FIG. 1A ) associated with each enterprise 302, 304.

[0116] Exemplary Enterprise-Level Calculation Functions FIG. 3B illustrates an exemplary enterprise-level compute fabric function 320 that may be included in compute fabric functions 320.1, 320.2 executing on behalf of enterprises 302, 304 of FIG. 3A. Compute fabric function 320 includes real-time process monitoring functionality across multiple NGPCASs for a single enterprise (332 in FIG. 3B). Either enterprise 302, 304 may actually implement two, three, four, or more NGPCASs, each of which may operate across a respective set of one, two, three, four, or more physical device locations. Because the location of process monitoring in an NGPCAS is not limited to the physical device location where the process is physically implemented, a single user on a single computing device may perform remote monitoring of processes across two, two, three, four, or more NGPCASs (and / or across multiple physical device locations associated with each NGPCAS). As an example, a single enterprise may operate multiple NGPCASs, which typically involve the operation of a particular type of boiler unit. A technician or operator familiar with the operation of the boiler units may monitor the runtime operation of the boiler units across the multiple NGPCASes by receiving, via the computational fabric at the technician's computing device, process information (e.g., device identifiers, device configuration information, process measurements, process set points, alerts, etc.) associated with the operation of each boiler unit included in the multiple NGPCASes. The technician (and / or the technician's computing device) may be provided with a level of authorization to view, retrieve, and act upon the monitored process information, for example, to send process commands, effect configuration changes, and / or provide other responses to manage the operation of the boiler units across the multiple NGPCASes. Similar monitoring capabilities may be provided to configuration engineers, operators, supply chain managers, and / or other personnel authorized to monitor at least a portion of the operation of each of the multiple NGPCASes.

[0117] Similarly, the disclosed NGPCAS architecture allows real-time monitoring (334) and operation functions (336) of an NGPCAS to be performed from multiple physical locations. That is, just as one operator or technician can remotely monitor the operation of multiple NGPCASs, various personnel across different physical locations can remotely monitor the operation of a single NGPCAS (or a single physical device location). In embodiments, an operator or technician at an operator workstation located at a first, second, third, etc. physical device location, or even at another location not associated with any physical device location, can monitor and perform operations associated with the runtime of portions of an industrial process (e.g., a device, group of devices, control loop, etc.) executing at different ones of the first, second, third, etc. physical device locations. The workstation can be located at any physical location, e.g., the physical device location where the process being monitored / operated executes, a different physical device location, a dedicated operations center, a home office, in a vehicle, etc., and the workstation can be a fixed or mobile device. An operator or technician may monitor the runtime operation of an industrial process, for example, by receiving various information associated with the operation of the process (e.g., device configuration information, operator displays, process status information, equipment status information, and operating parameters, process measurements, set points, alerts, and / or other information associated with components 135, 138 of FIG. 1A ) at an operator workstation via the computational fabric. The operator or technician may then modify or adjust various aspects of the operation of the process by sending commands from the workstation to modify aspects of the process (e.g., to advance a step in the process or to modify a control loop in the process, with the control loop potentially itself implemented in the form of a containerized component in the same or a different location via the computational fabric).Additionally, authorization to monitor any particular function of the NGPCAS (e.g., to monitor a particular industrial process or portion thereof, a physical device location, a device, a group of devices, etc.) may be passed on demand (e.g., at the request of a user and / or another containerized component) or automatically between personnel located at various physical locations that are not geographically limited to the physical location where the monitored function of the NGPCAS is performed. For example, in some embodiments, authorization to monitor the operation of the NGPCAS or portion thereof may be passed between personnel at personnel shift changes, and the personnel passing monitoring access are not necessarily located at the same physical location as each other or with respect to the NGPCAS or portion thereof being monitored. This ability to pass authorization to monitor operations between physical locations may enable the functionality of active monitoring of runtime process operations to “chase the sun,” for example, by moving monitoring of the operation of an industrial process (or portion thereof) between multiple locations around the world throughout the day, with each respective location having monitoring and operation responsibilities during its respective location's day.

[0118] The NGPCAS architecture of the present disclosure may further enable control of an NGPCAS process or portions thereof (e.g., a device, a group of devices, a control loop, etc.) from any physical location (340). Configuration and execution of a control loop may be implemented as containerized components within a location-independent NGPCAS computational fabric, rather than having to be implemented on-premise at the physical device location of the controlled operation, as in traditional process control architectures. Portions of the control system may be distributed among containerized components running at the same physical device location, different physical device locations, and / or other physical locations not associated with the physical implementation of the process.

[0119] Indeed, any containerized component (e.g., containerized services and applications) in the compute fabric may be executed at any physical location, e.g., the physical device location to which the containerized component pertains, a different physical device location, and / or even another physical location independent of any physical device that implements at least a portion of a process (338). Similarly, a containerized component in the compute fabric may be instantiated from any physical location (342). For example, a containerized component may be instantiated via human and / or automated action in a first physical location, while the instantiated containerized component runs or executes on a compute node (of the compute fabric) located in a second physical location. Furthermore, execution of a containerized component may be transferred between various physical locations on demand or automatically (344, e.g., via orchestration service 422 of FIG. 4). In some implementations, containerized components of the NGPCAS are moved globally across various physical locations to place the execution of the containerized components in proximity to the monitoring / control / operation workstations that service the NGPCAS at any given time (e.g., to "chase the sun" by running the containerized components at various locations during the day at each location). For example, the containerized components may be moved to run at different physical locations multiple times each day to "chase the sun," thereby running in proximity to personnel that service the NGPCAS during the day at any given time. Containerized components may also be moved between compute fabric nodes and / or physical locations for load management purposes, e.g., to avoid overloading the processing power of any particular compute fabric node or the communications bandwidth of any particular communications link within the compute fabric.Furthermore, the execution of a containerized component may be moved in the event of a failure of a compute fabric node or portion thereof within the compute fabric, for example, by activating a digital twin instance of the containerized component operating at runtime on a different compute fabric node and / or in a different physical location.

[0120] NGPCAS access to specific containerized applications / services may be provided on a per-application or per-service basis (“a la carte” 348). In other words, an enterprise (e.g., one or more agents of the enterprise) can individually select specific monitoring applications, operational applications, control applications, dashboard applications, control modules, diagnostic applications, and / or other process functions to implement in the enterprise's NGPCAS to support the operation of the process. Instances of the containerized components to implement the selected functions may be instantiated and executed on demand or as needed to support the scale of operation required by the enterprise's NGPCAS.

[0121] In some embodiments, the architecture provider / manager (e.g., 161 in FIG. 1A ) offers subscription-based access to process functions (346), whereby enterprises purchase particular process functions at a price determined based, for example, on the number of functions purchased, the number of instances of the purchased functions running on the enterprise's NGPCAS compute fabric, and / or the length of time the purchased process functions operate on the enterprise's NGPCAS compute fabric. Third parties may similarly offer subscription-based or one-time purchase-based access to process functions, enabling, for example, a first enterprise to create and distribute a process function to another one or more enterprises, enabling the other one or more enterprises to run instances of the same process function for their own respective use via their respective NGPCAS containerized and physical components. To support subscription-based and one-time purchase-based distribution of process functions, the architecture provider / manager may offer an application / service “store” containing a library of various process applications and / or services available for purchase (i.e., one-time purchase or subscription) by enterprises for their own respective use. Additionally, in some embodiments, the architecture provider / manager implements virtualized testing and simulation of any of the application / service library on the enterprise NGPCAS to ensure that the purchased application / service runs securely, properly, and effectively on the enterprise NGPCAS prior to actual implementation in the context of the enterprise's own process architecture.

[0122] Referring again to Figure 3A, the multi-enterprise framework 300 considering the NGPCAS architecture enables an architecture provider / manager (e.g., 161 of Figure 1A) to perform centralized management 350 of upgrades to applications / services utilized by enterprise NGPCASs 302, 304. Upgrades to the applications / services are reflected in new instances of the applications / services running in the enterprise NGPCASs 302, 304, thus enabling each enterprise 302, 304 to automatically access the latest version of any process functionality provided to the enterprise 302, 304.

[0123] In addition to providing centralized management of application / service upgrades, an architecture provider / manager (e.g., 161 in FIG. 1A ) within multi-enterprise framework 300 may provide a central point for monitoring (352) the operation of the compute fabric for enterprise NGPCAS 302 and / or 304. The architecture provider / manager may monitor NGPCAS operation, for example, to implement fault handling or fault protection measures, to perform load balancing of NGPCAS functionality, and / or to identify performance improvements for different NGPCASs of the same NGPCAS 302, 304 and / or even other enterprises.

[0124] Further enterprise-level benefits to the NGPCAS architecture of the present disclosure will be realized from elsewhere herein.

[0125] Exemplary Compute Fabric Architecture With respect to the computational fabric 102 of the next-generation process control and automation system 100 of FIG. 1A, FIG. 4 illustrates a block diagram of an exemplary architecture 400 of the computational fabric 102. Of course, the exemplary architecture 400 may be utilized in computational fabrics other than the computational fabric 102 of the NGPCAS 100 and / or in process control and automation systems. For ease of discussion herein, but not by way of limitation, the architecture 400 is described below with simultaneous reference to FIG. 1A. Additionally, for ease of readability, the architecture 400 of the computational fabric 102 will be referred to interchangeably herein as the "computational fabric architecture 400" or simply the "computational fabric 400."

[0126] Generally speaking, as described below, computational fabric 400 utilizes a layered architecture in which the business logic of computational fabric 400 is abstracted from the physical computing platform of computational fabric 400. For example, computational fabric 400 may utilize one or more techniques and / or features described in U.S. patent application Ser. No. 17 / 487,609, filed September 28, 2021, and entitled "Software Defined Process Control System and Methods for Industrial Process Plants," the disclosure of which is incorporated herein by reference in its entirety. For ease of discussion herein, computational fabric 400 will be described with simultaneous reference to system 100 of FIG. 1A, for purposes of illustration only and not limitation.

[0127] 4, the computational fabric 400 communicatively connects to the field environment 120 via one or more networks 402. The one or more networks 402 may be included in the network 130 of FIG. 1A, for example, in embodiments in which the computational fabric 102 of the NGPCAS 100 utilizes the computational fabric architecture 400. The network 402 typically includes high-bandwidth data or communication links supporting packet delivery to and from the computational fabric 400 and may include one or more wired and / or wireless networks, which may include public networks (such as the Internet, public Wi-Fi networks, cellular networks) and / or private networks. At least some portions of the one or more networks 402 may include an advanced physical layer (APL) or some other type of physical or other protocol layer supporting Ethernet and / or other packet-based protocols.

[0128] Compute Fabric Physical Layer As further shown in FIG. 4 , the exemplary architecture of compute fabric 400 includes a computing platform 405 of hardware and software resources that support the upper layers of compute fabric 400. Accordingly, computing platform 405 is interchangeably referred to herein as the “physical layer 405” of compute fabric 400, as it includes physical processors, processor cores, memory, and networking interfaces. The computing platform or physical layer 405 of compute fabric 400 includes a set of data center clusters C1, C2, ..., Cn (for ease of reading, generally referred to herein as data center clusters Cx), each of which includes a respective plurality of compute fabric nodes N1, N2, ..., Nn (for ease of reading, generally referred to herein as nodes Ny), and each node Ny included within each data center cluster Cx may be at least partially, if not fully, interconnected. Each different cluster C1, C2, ..., Cn may include a different total number of nodes N1, N2, ..., Nn. Each node Ny of each data center cluster Cx includes one or more respective processors and / or processor cores, one or more respective memories, and one or more respective networking resources, such as one or more respective physical communication interfaces that communicatively connect the node Ny to one or more other nodes Ny of the data cluster Cx. For example, a node Ny may be implemented in a single server or in a bank or group of servers.

[0129] Each cluster Cx includes multiple nodes Ny communicatively interconnected with each other. Furthermore, different clusters Cx may be physically located at the same or different physical locations (e.g., different locations 115, 118 of NGPCAS 100 where physical devices 105, 108 are located, and / or one or more other locations where no physical devices of system 100 are located). A particular cluster Cx may be implemented only in a single physical location or across multiple physical locations. Additionally, each data center cluster C1, C2, ..., Cn is communicatively connected or networked with one or more of the other data center clusters C1, C2, ..., Cn of computing platform 405.

[0130] Although the physical layer 405 associated with the compute fabric 400 is described above as being implemented using physical data center clusters C1-Cn, in some embodiments, at least a portion of the physical layer 405 may be implemented as a virtualized physical layer 405. For example, the data center clusters C1-Cn (or a subset thereof) may be implemented as virtual machines running on a computing resource platform, such as, for example, a cloud computing system.

[0131] Software-defined networking layer of the compute fabric The exemplary architecture of the compute fabric 400 also includes a software-defined (SD) networking layer 410 that interfaces the physical layer 405 of the compute fabric 400 with a software-defined application layer 412 of the compute fabric 400. Accordingly, the software-defined networking layer 410 is referred to interchangeably herein as the “operating system (OS) 410” of the compute fabric 400. Generally speaking, the OS 410 of the compute fabric 400 may assign, designate, or allocate various compute fabric nodes Ny to perform respective roles or functions to support the compute fabric 400, such as computing (e.g., via the nodes' respective processors and / or processing cores) or data storage (e.g., via the nodes' respective memory). The compute fabric nodes Ny that are assigned, designated, or allocated to perform computing activities of the compute fabric 400 are referred to herein as “compute nodes” or “computing nodes,” respectively. Similarly, each compute fabric node Ny that is assigned, designated, or allocated to perform storage activities of the compute fabric 400 is referred to herein as a “storage node.” Individual nodes Ny may be utilized solely as compute nodes, solely as storage nodes, or as both compute and storage nodes, and the role of each individual node Ny may change dynamically over time, for example, as directed by the OS 410. Advantageously, the computing platform 405 is scalable, such that individual nodes Ny and / or individual clusters Cx may be easily added, removed, replaced, etc., as needed to support the compute fabric 400, particularly in accordance with other, higher-level requirements of the compute fabric 400. For example, different nodes Ny of the compute fabric 400 may be assigned and reassigned to different clusters Cx, and / or different nodes Ny and / or different clusters Cx may be physically located in different physical locations 115, 118 of the NGPCAS 100, as desired.

[0132] The operating system 410 of the compute fabric 400 runs on the computing platform 405 and, in one embodiment, may be built on any suitable general-purpose Hyper Converged Infrastructure (HCI) operating system (OS), such as Microsoft Azure Stack, VMWare HCI, Nutanix AOS, Kubernetes Orchestration (including Linux® Containers (LXC / LXD), Docker Containers, Kata Containers), etc. The OS 410 thus provides a set of compute, storage, and networking support services in a manner somewhat similar to a general-purpose HCI operating system. However, in contrast to a general-purpose HCI OS, advantageously in the compute fabric 400 of the next-generation process control and automation system 100, the OS support services dynamically respond to logic or abstraction process control or automation system and other software components provided by the software-defined application layer 412 of the compute fabric 400. That is, as the performance, resource needs, and configuration of the various application layer services, subsystems, and other software components of application layer 412 dynamically change (and / or are dynamically predicted to change by the services within application layer 412), operating system 410 may automatically and responsively adjust and / or manage the use of hardware and / or software resources of physical layer 405 to support the needs and requirements of application layer 412 for computing, storage, and networking, and other functionality related to industrial process control and automation.To this end, compute fabric operating system 410 may include, for example, software-defined (SD) computing (or compute) services 415, SD storage services 418, SD networking services 420, SD orchestration services 422 (interchangeably referred to herein as “orchestrator 422”), and optionally one or more other process control and / or automation-specific SD OS support services and / or functions 425. For example, process control and / or automation-specific SD OS support services and / or functions 425 may include compute fabric individual resource and / or resource group management services that manage individual resources and / or groupings of resources provided by software-defined networking layer 410 and / or physical layer 405 of compute fabric 400, such as, for example, virtual machines, containers, networks, network security groups, clusters, servers, etc. Thus, in one embodiment, operating system 410 of compute fabric 400 comprises a general-purpose HCI operating system platform (e.g., Microsoft Azure Stack, VMWare HCI, etc.) that has been specifically customized to include SD-Compute Services 415, SD-Storage Services 418, SD-Networking Services 420, SD-Orchestration Services 422, and other process control and / or automation SD-OS support services and / or functions 425, where the set of SD-Support Services 415-425 automatically responds to and specifically supports application layer software components 412 of compute fabric 400, including process control and / or automation-specific applications and services, as discussed above.

[0133] The interface between the software-defined networking layer of the compute fabric and the application layer In particular, just as the compute fabric operating system 410 manages the allocation of hardware and software resources of the node Ny of the computing platform 405 through the SD OS support services 415-425, the SD OS support services 415-425 may also serve as interface services between the OS 410 and higher-level services, subsystems, and other software components in the application layer 412 of the compute fabric 400, and / or may provide a framework for these higher-level services, subsystems, and other software components in the application layer 412. Accordingly, the software components in the compute fabric application layer 412 may interface with the OS 410 (and possibly with one or more of the SD-specific support services 415, 418, 420, 422, 425, among others, provided by the OS 410) through a set of application programming interfaces (APIs) 428, either through an HCI adapter 430 (also referred to herein as the “HCI adapter layer” 430) and a separate set of APIs 432, or directly (not shown in FIG. 4 ). HCI adapter layer 430 enables compute fabric application layer 412 to access SD OS support services 415, 418, 420, 422, 425 without relying on the particularities of a general-purpose HCI operating system (e.g., Microsoft Azure Stack, VMWare HCI, etc.) that has been customized with such SD-specific services 415-425 to form OS 410. Thus, HCI adapter 430 translates or transforms APIs 428 utilized by compute fabric application layer 412 into a set of APIs 432 that are understood or otherwise known or compatible with the customized or adapted general-purpose HCI operating system 410 of compute fabric 400.

[0134] Thus, unlike typical layered IT (information technology) system architectures in which business logic applications are abstracted from the hardware and software computing platform and management of computing platform resources is largely managed and designed by human IT administrators, the architecture of compute fabric 400 not only abstracts higher-level, business logic services, subsystems, and other software components of application layer 412 from the hardware and software computing platform 405, but also enables the higher-level software-defined services, subsystems, and other software components 412 to dynamically, automatically, and responsively direct and cause changes in the use of hardware and software resources of nodes Ny and clusters Cx (and, optionally, groups of those hardware and / or software resources) of physical layer 405 and software-defined networking layer 410, e.g., via APIs 428 and SD OS support services 415, 418, 420, 422, 425, and without the need for any human intervention or direction. In particular, and advantageously, management of resources in the physical layer 405 and in the software-defined networking layer 410 dynamically responds to the changing configurations and needs of these above-mentioned SD services, subsystems, and other software components in the application layer 412, and is particularly responsive to the specific requirements, limits, and boundaries of industrial process control and automation systems, such as timing, synchronization, and / or other control- or automation-specific constraints.

[0135] Containers and other types of microencapsulated execution environments 4 , industrial process control, automation, and other related business logic are implemented by higher-level software-defined services, subsystems, and other software components 435-448 provided by the application layer 412. For ease of reading herein, this disclosure categorically and interchangeably refers to these higher-level SD services, subsystems, and other software components 435-448 as “software-defined application layer components” or “application layer software components” of the compute fabric 400. In one embodiment, the set of software-defined application layer components 435-442 (and optionally at least a portion of the third-party services 448 executing in the application layer 412) may collectively form a logical process control or automation system 445 (also interchangeably referred to herein as a “virtual” process control or automation system 445) that executes with the physical components 135, 138 of the NGPCAS 100 to control industrial (e.g., process control or automation) processes. For example, logic process control or automation system 145 of Figure 1A may include logic process control system 445 of Figure 4. Generally speaking, application layer software components may be provided by an enterprise (e.g., via architecture provider / manager 160), a user 155 that is an agent of or associated with enterprise 155, a third party, and / or other source.

[0136] The application layer software components 435-448 of the application layer 412 can execute in containers and / or other suitable types of microencapsulated execution environments (MEEEs) or granules, e.g., as instantiated software components (ISCs). For example, an ISC can be a container configured with instances of particular application layer software components 435-448 to form a configured container, container image, or other type of microencapsulated execution environment or granule for the particular application layer software components 435-448, and the container image of the particular application layer software component 435-448 can be instantiated for execution on a particular compute fabric node Ny as a particular instantiated MEEE or ISC. Stated another way, a configured container can be an instance of the application layer software component 435-448 configured into a respective container or other type of microencapsulated execution environment or granule.

[0137] Generally speaking, containerized or microencapsulated software components or MEEEs / granules (e.g., in the application layer 412, HCI adapter layer 430, and software-defined networking layer 410) are included in a set of containerized / microencapsulated components 140 of the NGPCAS 100 and are therefore isolated from other containerized / microencapsulated services and applications (e.g., other containerized / microencapsulated components 140) running on the same node Ny. Accordingly, the terms "configured container," "container image," and "containerized component" are used interchangeably herein and, for ease of discussion and not by way of limitation, are used generically and categorically herein to refer to any one or more suitable types of instantiated micro-encapsulated execution environments or granules, such as a software container, a virtual machine, a software agent, a script, a function, an invocation, an actor (e.g., a lightweight process such as Erlang, Scala, Akka, etc.), a unikernel (e.g., a machine image that runs on bare metal and includes all components necessary to run an application, including operating system components), other types of bare-metal software (e.g., software that runs directly on hardware without any intermediate management software such as a hypervisor or other type of container / encapsulation manager), and / or other types of micro-encapsulated execution environments or granules.

[0138] Various MEEEs or granules may be configured (e.g., when instantiated) to perform a variety of broad to fine-grained operations within NGPCAS 100. Illustrating using an example, a control routine may include multiple control modules that operate in conjunction to execute the control routine, each control module may include multiple function and other types of blocks that operate in conjunction to implement the control module, and each function block may include multiple fine-grained operations that operate in conjunction to execute the function block. Thus, in one implementation of this example, a single MEEE may be configured to execute the entire control routine (e.g., when instantiated). In another implementation of this example, each MEEE of a group of MEEEs may be configured to execute (e.g., when instantiated) a different control module or portion of the control routine, and the group of instantiated MEEEs may operate in conjunction to thereby execute the entire control routine as a group. Indeed, in some implementations, a second group of MEEEs may each be configured (e.g., when instantiated) to perform different fine-grained operations or portions of the control module (e.g., input function blocks, error detection function blocks, control function blocks, logic function blocks, scripts, output function blocks, etc.), and this second group of MEEEs may operate cooperatively when instantiated to thereby execute the entire control module as a group. In yet other implementations, a single MEEE may be configured (e.g., when instantiated) to execute a process controller, process control subsystem, unit, area, or even the process control system 445 as a whole.

[0139] In another example, a single individual MEEE may be configured (e.g., when instantiated) to execute the entire complex data analysis routine for the entire NGPCAS 100. Alternatively, each MEEE of a group of MEEEs may be configured (e.g., when instantiated) to execute a different simple data analysis routine (or other respective portions of a portion of a complex data analysis routine), and execution of the instantiated group of cooperating MEEEs may thereby cause execution of the entire complex data analysis routine. In some implementations, separate groups of MEEEs, when instantiated, may cooperatively perform respective fine-grained actions or operations of the simple data analysis routine (or respective fine-grained actions of other types of simple data analysis routines), thereby causing execution of the entire simple analysis routine (or possibly the entire portion of a complex data analysis routine). For example, granular analysis actions or operations may include computational functions (e.g., data aggregations and / or manipulations such as average, maximum, minimum, etc.), simple data analysis routines may include more advanced statistical calculations or algorithms (e.g., principal component analysis (PCA), partial least squares (PLS) prediction, and other types of statistical calculations and / or analyses), and complex data analysis routines may include combinations of statistical calculations or algorithms, possibly in combination with other types of non-statistical calculations or algorithms.

[0140] Generally speaking, the MEEE, granule, or configured container may be provided by an enterprise (e.g., via architecture provider / manager 160, via an application / service store, out-of-the-box, etc.), a user 155 that is an agent of or associated with enterprise 155, a third party, and / or other source. Various instantiated MEEEs may be assigned to run on various compute nodes Ny of system 400, which may be located in different physical and / or geographic locations. Furthermore, instantiated MEEEs may be dynamically migrated from running on one node to running on another node based on, for example, detected and / or predicted resource usage, jurisdictional requirements and / or regulations, and / or other criteria. Still further, instantiated MEEEs may be allocated, pinned, dynamically allocated, and / or dynamically migrated, for example, via SD-Compute Services 415, to run on respective nodes Ny and / or data center clusters Cx. SD compute services 415 may dynamically change, update, maintain, and / or manage container images and their respective assignments to compute nodes Ny as needed or as needed to support the expansion or contraction of computing platform 405, to support the expansion or contraction of logic process control or automation system 445, to load balance across compute nodes Ny, for scheduled maintenance of compute nodes Ny and / or their physical components, based on jurisdictional rules and / or requirements, etc. Accordingly, NGPCAS 100 may be viewed as a dynamic and highly distributed set or dynamic mesh of MEEEs, where the MEEEs may be located or distributed across multiple physical and / or geographic locations, one or more of which may be dynamically reassigned and migrated during runtime operation of NGPCAS 100 to another node and / or another physical and / or geographic location while maintaining execution of the runtime operation of NGPCAS 100.Furthermore, components of the dynamic mesh of MEEEs that form a particular application, control routine, analysis routine, etc. may be dynamically moved or migrated or reassigned to other hardware within the computational fabric individually, in sets or groups, or collectively if desired, without affecting or disrupting the operation of the application, routine, etc. Thus, individual components of the dynamic mesh of MEEEs for a particular application or use may be managed in the computational fabric separately from other components of the same application or use.

[0141] Within the compute fabric 400, some configured containers, granules, or instantiated MEEEs may be distributed or assigned to respective compute nodes Ny and dynamically reassigned to different compute nodes Ny by the SD compute services 415 based on the dynamically changing configuration, performance, and needs of the logic process control or automation system 445. In some circumstances, configured containers may be assigned (and reassigned) to run by specific processors or specific processor cores of the SD compute node Ny. However, some configured containers may be pinned to respective SD compute nodes Ny (e.g., by the SD compute services 415, by configuration, by a user, etc.) and may not be dynamically reassigned by the SD compute services 415 due to dynamically occurring conditions. That is, a pinned configured container may run on the compute node Ny to which it was pinned regardless of the dynamic state of the logic process control or automation system 445 (other than perhaps a failure of the compute node Ny to which it was pinned), for example, until the configured container is unpinned from the compute node Ny. In other words, the software-defined networking layer 410 can restrict utilization by a pinned configured container to only the hardware and / or software resources to which it is pinned, and when the configured container is unpinned, the SD networking layer 410 removes the restriction. A configured container may additionally or alternatively be pinned to other physical or logical components of the compute fabric 400, if desired. For example, a configured container may be pinned to another configured container, a particular data cluster, a particular processing resource (e.g., a particular physical processor or particular physical processor core of a compute node Ny), a physical rack, or a portion of a physical rack served by a particular power source (where the physical rack physically houses the hardware of one or more nodes), etc.

[0142] Additionally, configured containers, instantiated MEEEs, or granules may be nested within and / or pinned to other configured containers, which is particularly useful for configuring and organizing a logic process control or automation system 445. For example, if a particular process control subsystem 438 provides a particular set of control services 435 and / or other services 440, then the configured container for each provided service 435, 440 of the particular set may be nested within the configured container of the particular process control system 438. In another example, multiple control routine and / or control module configured containers may be nested within a particular controller service 435, which may be nested within a particular process control subsystem 438. In yet another example, a controller or control service 435 may be configured with one or more process control module services 435, parameters, and industrial process plant 10 values, such as input and output tags, reference values, etc., thereby forming a configured or programmed controller service. The controller or control service 435 may be functionally equivalent to a traditional dedicated hardware controller device as understood in the Purdue model, or the controller service 435 may be functionally equivalent to a control routine or control module configured within and executed by a traditional dedicated hardware controller device. A container may be configured with an instance of a configured controller service, thereby forming a container image or instance of the configured controller service that, when so configured, is executable to implement a particular configured set of process control logic, for example, by using the configured control module containers, tags, reference values, etc. Multiple instances or container images of the configured controller service (or other configured applications and services) may be instantiated and executed by the compute fabric 400.

[0143] In yet a further example, containers, granules, or instantiated MEEEs in the SD application layer 412 may be utilized to represent and / or logically organize physical and / or logical areas, regions, and components of the NGPCAS 100. For example, units, areas, etc. may be represented by respective configured containers, and configured containers corresponding to the physical and / or logical components of each unit, area, etc. may be nested and / or pinned within their respective configured, organized containers. Thus, within the computational fabric 400, a configured control routine container may be nested within or pinned to a configured controller container, which may be nested within or pinned to another configured container, e.g., a configured container for a depropanizer.

[0144] For clarity and ease of discussion herein, the term “container” is used herein to generally refer to an instantiated software component (ISC), which is a configured container, container image, containerized component, or other type of micro-encapsulated execution environment (MEEE) or granule, e.g., a container or other type of micro-encapsulated execution environment configured to contain an instance of a respective controller service, subsystem, or other service or application provided by application layer 412 of compute fabric 400.

[0145] In any event, in a manner similar to that discussed for the computing resources of the computing platform 405, the containerized / microencapsulated components 140 of the system 100 may be dynamically allocated and / or assigned, pinned, and / or nested to various compute fabric storage nodes Ny, e.g., via the SD storage service 418, to thereby support the various storage needs of the logic process control or automation system 445. For example, the SD storage service 418 may manage and administer the logic storage resources utilized by the configured containers of the logic process control system 445 across the various physical hardware memory resources of one or more nodes Ny. For example, the configured containers and the memory (e.g., random access memory or the like) required for their operation may be stored on a particular SD storage node Ny or a particular memory device or space on an SD storage node Ny. Additionally, if desired, some containerized components / MEEEs / granules 140 may be pinned to respective SD storage nodes Ny and / or particular memory devices or memory areas on the SD storage node Ny. SD storage service 418 may change, update, or otherwise manage the physical hardware memory or memory of computing platform 405 to support the logical storage resources of compute fabric 400 when and as needed, for example, due to a disk or other type of error, for scheduled maintenance, due to adding / expanding available physical memory in computing platform 405, etc.

[0146] Similarly, SD networking services 420 may operate and manage logic or virtual networking utilized by containerized components / MEEEs / granules 140 of logic process control or automation system 445 and / or by other containerized components / MEEEs / granules 140, which may be implemented by SD networking services 420 across compute fabric nodes Ny. For example, SD networking services 420 may operate and manage the networking and hardware resources of computing platform 405 to support logic networking functions included in logic process control system 445, such as virtual interfaces, virtual switches, virtual private networks, virtual firewall rules, etc., as well as the necessary networking between various configured containers or container images executing on compute fabric 400. Additionally, because the logic process control system 445 provides services to the physical components 135, 138 of the NGPCAS 100, the timing and synchronization of the containerized components / MEEEs / granules 140 of the compute fabric 400, the physical components 135, 138 of the field environment 120, and the networking between them is critical, as missed and / or lost messages or communications can lead to uncontrollable industrial or physical processes, which in turn can lead to catastrophic results such as overflows, gas leaks, explosions, loss of equipment, and, in some circumstances, loss of life. Fortunately, the SD networking services 420 are responsible for critical process I / O timing and synchronization of the compute fabric 400, so that communications (particularly communications to / from the control services 435) can be reliably delivered in a timely and deterministic manner. For example, SD networking services 420 may support time synchronization within 1 millisecond of the data center cluster Cx to ensure necessary synchronization between process control services 435, process control subsystems 438, packet router / switch services 442, and other software-defined services 440, 448 in the software-defined application layer 412.

[0147] In addition to SD compute services 415, SD storage services 418, and SD networking services 420, the compute fabric operating system 410 may provide other OS support services 425 accessible via a set of APIs 428, 432 and that may be utilized or accessed by the application layer 412 to support the logic process control system 445 and other containerized components / MEEEs / granules 140 of the application layer 412 of the compute fabric 400. For example, the other OS services 425 may include service lifecycle management services, discovery services, security services, encryptor services, certificate authority subsystem services, key management services, authentication services, time synchronization services, resource and / or resource group management services, service location services, and / or console support services (all not shown in FIG. 4 ), to name a few. In some embodiments of the compute fabric 400, one or more of the support services may execute in the application layer 412, e.g., as other software-defined services 440, instead of executing in the software-defined networking layer 410 as OS support services 425.

[0148] Indeed, in one embodiment, one or more of the software-defined components 415-425 and 452-460 of the software-defined networking layer 410 are implemented as respective configured containers or container images of the compute fabric 400. That is, one or more services and other functionality provided in the software-defined networking layer 410 of the compute fabric 400 (and in some implementations, all of the services and functionality provided in the software-defined networking layer 410) may be implemented as respective containerized components / MEEEs / granules 140 of the NGPCAS 100. Thus, in a manner similar to that discussed herein for the containerized components / MEEEs / granules 140 of the application layer 412, the containerized components / MEEEs / granules 140 of the software-defined networking layer 410 may be uniquely identified within the NGPCAS 100 by their respective addresses, may be communicatively connected to other containerized components / MEEEs / granules 140 of the NGPCAS 100 and optionally to the physical components 135, 138 of the NGPCAS 100, and may be spun up and removed as needed or when needed, etc.

[0149] The application layer of the compute fabric Referring now more specifically to the application layer 412 of the compute fabric 400, as shown in FIG. 4 , the application layer software components 412 may include a set of software-defined services or applications 435 (e.g., software-defined process control or automation-related services 435) and a set of subsystems 438 of the NGPCAS 100 (e.g., subsystems for software-defined process control or automation), and may optionally include a set of other software-defined business logic services 440 of the NGPCAS 100 (e.g., enterprise business logic services related to process control or automation). In some implementations of the compute fabric 400, the application layer software components 412 may include a set of third-party business logic services 448. For example, the third-party services 448 may be generated by a software development kit (not shown) of the compute fabric 400, through which a user may develop, generate, install, and manage the third-party services 448 in the SD application layer 412. Generally speaking, the services and applications 435-448 provided in the application layer 412 form the logic process control system 445 and provide related functionality. Generally speaking, the applications 435-448 may be provided by the system 100 itself, a third party, a supplier, an end user 155, and / or other sources. For example, one or more of the applications 435-448 may be built on APIs 160, 165 provided by the compute fabric 102, and / or one or more of the applications 435-448 may be packaged as containers and distributed by the orchestrator 422.

[0150] Each different control service 435 may be configured with desired parameters, values, etc., and optionally other control services 435; each instance of the configured control service 435 may run within a respective container; and each configured container may be assigned (or pinned) to run on a respective compute node Ny and / or cluster Cx. Thus, each configured control service 435 may be a logic or software-defined control entity that may be functionally configured and performed in a manner similar to conventional hardware-implemented process controller devices, 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 compute fabric 400 may easily replicate multiple instances of the same configured control service 435 for various purposes, such as performance, fault tolerance, and recovery. For example, a controller service (running within its own container) may be configured to run a control module service (running within its own container), which may be configured to run a set of control function block services (each of which runs within its own container and each of which may be configured with respective parameters, values, etc.). Thus, a set of configured containers corresponding to a set of configured control function block services may be nested in a configured control module service container, which may be nested in a controller service container, etc. The set of configured containers corresponding to a set of configured function block services may be assigned to run on different cores of a particular processor of the computing platform 405, for example, for performance load balancing purposes.When the load changes, one or more of the configured function block service containers may be moved to run on a different processor core, a different processor, or even a different compute fabric node to attempt to rebalance the load, but the moved function block service container will still be nested under the configured control module service container and will run accordingly.

[0151] In addition to control services 435, other types of application layer services 440 related to industrial process control may be provided by application layer 412, such as, but not limited to, operator displays and interfaces, diagnostics, analytics, safety routines, reporting, data historizing, service configuration, container configuration, information communication with external or other systems, enterprise-level applications, process control and / or automation resource and / or resource group management. For example, process control and / or automation resource group management services may enable users 155 to group and / or isolate various resources based on NGPCAS 100 and / or other process control or automation considerations. For example, resource groups may be formed based on physical characteristics such as sites or physical locations, groups of sites / physical locations, subsets of sites or physical locations, geographic regions, etc.; based on logical characteristics such as categories, containers and / or container types, control strategies, capabilities, timing, performance, user characteristics, etc.; based on functionality such as storage items, networking items, etc.; and / or other types of groupings and / or combinations thereof corresponding to NGPCAS 100. Generally speaking, any process control or automation system related functionality or business logic that executes during runtime of the NGPCAS 100 to control an industrial process, support the NGPCAS 100, and / or is related to the NGPCAS 100 may be logically implemented within the compute fabric 400 as respective application layer services 435, 440 running within respective containers. For example, any one or more of the enterprise-level compute fabric functions 320 may be implemented in respective containers or as containerized services.Additionally, any of the containerized services 435, 440 may communicatively couple with a respective physical component 135 / 138 disposed at a physical location of the NGPCAS 100, e.g., via the SD networking layer 410, when required to do so by the business logic of the service 435, 440 and / or by the receiving physical component 135 / 138. Still further, any of the containerized services 435, 440 may communicatively couple with any other containerized service 435, 440 to transfer data and / or information therebetween, when required to do so by the respective business logic.

[0152] Similarly, each different subsystem 438 in the application layer 412 of the compute fabric 400 may be provided by or run in a respective container. The set of subsystems 438 provides the virtual or logic process control-related subsystems of the logic process control system 445. In some cases (not shown in FIG. 4 ), a subsystem 438 may provide or include one or more application layer services, such that configured containers of services 435, 438 provided by the subsystem may be nested within the configured subsystem container. In general, the set of subsystems 438 allows the control services 435 and other services 440 to be easily and coherently grouped and / or managed. In a preferred embodiment, each node Ny of the compute fabric 400 hosts a respective instance of each subsystem in the set of subsystems 438, thereby, for example, ensuring that the subsystem services are readily available in proximity to the other application layer services 435, 440, 448 currently running on each node Ny. Thus, changes to one or more of the subsystems 438 may be coordinated among their corresponding instances executing at each node Ny (e.g., under the direction of the OS 410). Thus, not only is the set of subsystems 438 highly and proximally available to any application layer services 435, 440, 448 executing on the same node Ny, but the functionality provided by the set of subsystems 438 may be easily maintained for the logic process control system 445 in the event of a compute fabric node failure, a failure of a compute fabric node component, or a failure of a particular subsystem instance at a compute fabric node.

[0153] Examples of subsystems 438 that may be provided by the application layer 412 of the compute fabric 400 include, but are not limited to: a continuous process control subsystem for managing the scheduling and execution of business logic of logic and physical control system entities such as controllers, I / O assignments, control modules, function blocks, ladder logic, and structured text-based control algorithms; a state-based process control subsystem for managing, tracking, assigning, modifying, deriving, transitioning, analyzing, visualizing, recording, etc., the state of the process control system 445 as a whole, the state of containerized components / MEEEs / granules 140 of the process control system 445, and / or the state of physical components 105, 108 controlled by the process control system 445, and for driving the industrial process to achieve a desired process state within defined constraints, such as safety, environmental, and / or profitability constraints; an event-based process control subsystem including various control services that can be triggered to execute based on the occurrence of one or more events; a batch process control subsystem including various control services that perform batch control and tracking of regulatory items (e.g., for government traceability) and may manage regulatory records related to batch process control and generated during batch execution and at other times; a historian subsystem that includes various application layer services for recording time series data about process I / O and events within the system 100; a diagnostic subsystem including various application layer services for collecting and providing diagnostic data from various other application layer services, other subsystems, compute fabric nodes Ny, components of the software-defined networking layer 410, and / or other components of the system 100; a process I / O subsystem including various application layer services for managing I / O connections and configurations for process I / O within a process control system 445, such as a packet router / switch service 442; a user subsystem including various application layer services 440 for validating and / or verifying user credentials when a user attempts to access the computational fabric 400, e.g., via APIs 160, 165; an alarm subsystem including various application layer services for maintaining the definitions, status, and state of alarms in the system 100, such as, for example, process alarms, hardware alarms, maintenance alarms, unit alarms, networking layer alarms, I / O alarms, hardware asset alarms, software asset alarms, diagnostic alarms, etc.; a licensing subsystem including application layer services 440 for verifying or ensuring that users have privileges (e.g., perpetual license, time-subscription license, consumption-based license, remote license) according to the license level of the compute fabric 400 and / or system 100, enforcing licenses, preventing unlicensed activity from occurring, providing license administration, reporting and logging license status and activity, etc.; a distributed event subsystem including various application layer services for distributing generated events (or notifications thereof) across all nodes Ny of the computational fabric 400, along with corresponding timestamps indicating the respective times of occurrence at the respective event sources, such that consistent record-keeping can be provided across all nodes Ny; and a configuration subsystem that manages the storage, updates, and version control of a configuration database that stores configurations for various services provided by the application layer 412, such as control configurations. A respective instance of the configuration database may be stored on each compute fabric node Ny, such that the compute fabric 400 provides fault tolerance of the configuration database across all nodes Ny. Writes to the configuration database may be atomic across all fault-tolerant instances across the system 100, and reads from the configuration database may be from a single local instance of the configuration database. In some situations, large read requests may be segmented, and results may be provided in a parallel manner from multiple nodes Ny.

[0154] Additionally, application layer 412 of computational fabric 400 may include additional or alternative subsystems 438 that may be utilized by system 100. For example, subsystems 438 may include, for example, a control strategy subsystem directed at higher level and / or overall control strategies to achieve product and process performance and quality objectives, an analysis subsystem, an optimization subsystem, a mass and energy balance subsystem, a security subsystem that may include one or more specialized algorithms for detecting security intrusions, etc.

[0155] Software-defined router / switch services The software-defined packet router / switch service 442 generally routes packetized I / O data (and in some scenarios, other types of packetized data or information) between endpoints of the NGPCAS 100, e.g., from the physical components 135 / 138 to the containerized components / MEEE / granules 140 in the application layer 412 of the compute fabric 400, and vice versa; from the physical components 135 / 138 to the containerized components / MEEE / granules 140 in the networking layer 410 of the compute fabric 400, and vice versa. The packet router / switch service 442 may operate as an application or service responsible for forwarding data from a containerized component / MEEE / granule 140 to another containerized component / MEEE / granule 140 in the application layer 412 and vice versa, from a containerized component / MEEE / granule 140 in the networking layer 410 to another containerized component / MEEE / granule 140 in the networking layer 410 and vice versa, from a containerized component / MEEE / granule 140 in the application layer 412 to a containerized component / MEEE / granule 140 in the networking layer 410 and vice versa, etc. For example, the packet router / switch service 442 may be communicatively coupled to the respective endpoints and forward data therebetween using any suitable data delivery or data transfer paradigm, including request / response, publish / subscribe, etc.In one embodiment, if at least some of the software-defined application layer software components 435-448 are deployed as microservices / MEEE / granules communicatively connected by a microservices / MEEE / granule bus (not shown), then the packet router / switch service 442 (possibly in cooperation with the OS 410 and its support services 415-425) may support and / or manage the microservices / MEEE / granules and the microservices / MEEE / granule bus such that the microservices / MEEE / granules may transfer data and / or information (e.g., in a packetized format) between them. In additional or alternative embodiments, the software-defined packet router or switch service 442 may transfer packetized data and information between one or more containerized components / MEEE / granules 140 and / or physical components 135 / 138 of the NGPCAS 100 using any one or more packet-based networks or links (e.g., software-defined links provided by the network 402 and / or the compute fabric 400).

[0156] 4 illustrates the software-defined packet router / packet switch service 442 as being a separate service in the application layer 412, it should be noted that this is for purposes of clarity of discussion (and not limitation). In other embodiments, the packet router / switch service 442 may be included in a subsystem 438 of the compute fabric 400, and / or at least a portion or all of the software-defined packet router / switch service 442 may be implemented in the HCI adapter 430 or the compute fabric operating system 410. Alternatively, the packet router / switch service 442 may be in its own standalone subsystem in the application layer 412, or may be an application layer software-defined service 440 that is not associated with any subsystem. In any event, generally speaking, the software-defined packet router / packet switch service 442 may typically be implemented as a containerized component / MEEE / granule 140 of the compute fabric 400.

[0157] Thus, the containerized packet router / switch service 442 can be accessed by other containerized components / MEEEs / granules 140 of the compute fabric 400 (both at the application layer 412 and the networking layer 410) for data forwarding or data delivery. In some circumstances, the packet router / switch service 442 can utilize the API 428, thereby causing the forwarding of packetized I / O data and / or other types of packetized data, for example, via OS support services 415-425. In some circumstances, the packet router / switch service 442 can cause data to be forwarded via the microservice / MEEE / granule bus. In effect, the packet router / switch service 442 serves as logic or a gateway (e.g., an API gateway) that routes packetized process I / O and / or other types of packetized data between configured containers of the compute fabric 400, and routes packetized process I / O, packetized control signals or instructions, and other types of packetized information between configured containers of the compute fabric 400 and physical components 135, 138 deployed in the field environment 120 of the NGPCAS 100.

[0158] As will be appreciated, one significant advantage of the system described herein is the reduction in data movement and data storage required to support applications or other uses running in real time in the computational fabric. In particular, because of the secure real-time communication structure provided in the NGPCAS described herein, including the use of secure encrypted data links (e.g., VPNs) between various software and hardware elements both in the computational fabric and in the physical location (e.g., the plant), elements such as MEEEs in the computational fabric can access data in real time from anywhere in the system (i.e., from any other element where that data was created or resides). This feature allows applications and other application uses executed within or by higher-level system elements or platforms (e.g., control applications, maintenance applications, data logging or tracking applications, fleet management applications, etc.), or any individual MEEE or its granules, to access the data wherever the data resides (e.g., in another MEEE or granule anywhere in the system, in a computational fabric database, in a database or server at a physical location, in a field device at a physical location, etc.). Indeed, each MEEE or other computational element (granule) that constitutes or implements a particular application or use may contain pointers or references to where the data required for its operation resides within the system, and the granule may access that data in real time as it is needed or used by the MEEE or granule. Thus, a granule can access and use data regardless of, for example, where the data was created and / or originally stored. This feature means that data does not need to be moved, for example, from a server in a physical location to a cloud-based server within the computational fabric before it can be used or accessed in real time by an application or element (e.g., a granule) within the computational fabric.This feature thereby speeds up computing operations and reduces data flows that were previously performed simply to move data from one location to another and make that data available for real-time use to applications that use that data. Thus, the systems described herein enable data to be used by direct data calls or publish / subscribe communications regardless of where the data resides or is generated, whether the data resides in or is generated by devices in a computational fabric or devices at a physical location or plant.

[0159] Logic / Virtual Components Additionally, in the application layer 412 of the compute fabric 400, at least some physical process control devices or components (e.g., controllers, safety logic solvers or devices, data storage devices, etc.) of a traditional process control system may be logically implemented in the logic process control system 445 as respective services 435, 440 or subsystems 438 running in respective containers. Such logic or virtual instances of process control devices or components may be configured in a manner similar to their physical counterparts by configuring the logic devices with control routines, other application layer software components 412, parameters, reference values, lists, and / or other data, as needed. For example, a controller service may be configured with several control modules, a display view service may be configured with user access controls and graphical elements, etc. The configured logic or virtual process control devices or components (e.g., container images of the process control devices or components) may be identified within the logic process control system 445 via, for example, respective device tags or identifications, and respective signals received and generated by the configured logic or virtual instances of the process control devices may be identified within the logic process control system 445 by respective device signal tags or identifiers. The logic or virtual instance of a process control device may be uniquely identified within system 100 and may act as an individual entity in place of any corresponding physical device in system 100, or the logic or virtual instance of a process control device may be a proxy or digital twin of a physical device included in system 100, as described above.

[0160] In the software-defined application layer 412, the compute fabric 400 also includes software-defined storage entities or components 413 that can provide abstracted data storage (and access thereto) to the services and subsystems 435-448 of the SD application layer 412. For example, historian databases, configuration databases, and other types of process control system databases and data storage entities, as well as temporary storage utilized by the various process control application services 435-448 during runtime, can be provided by the software-defined storage entities 413. Storage databases, areas, devices, etc. can be virtualized or logic storage entities or components that can be allocated or distributed (and re-allocated and re-distributed) by the compute fabric operating system 410 to various storage resources of the nodes Ny of the computing platform 405. For example, a single software-defined logic database can be implemented on the hardware memory resources of multiple nodes Ny. Additionally, the SD storage service 418 of the compute fabric operating system 410 may allocate / reallocate and reallocate / redistribute the software-defined storage entities 413 of the application layer 412 to different storage resources provided by the node Ny based on the performance, resource, and configuration needs of the storage entities or components 413 and, optionally, other components of the SD application layer 412.

[0161] Orchestration Returning now to the software-defined networking layer 410 of the compute fabric 400, for ease of discussion, FIG. 4 illustrates a particular compute fabric OS service, namely, orchestration service 422, separately from the depiction of the other compute fabric OS services 415-420, 425. Generally speaking, orchestration service 422 instantiates container images (e.g., application layer control service 435, subsystems 438, third-party services 448, and other software-defined services 440) into containerized applications or services running or executing on respective hardware and / or software physical compute nodes Ny, and allocates various SD data storage entities that reside on respective hardware storage and / or software storage nodes Ny. For example, orchestration service 422 may instantiate and allocate the various instantiated container images to run and / or utilize the resources of a single node Ny or the resources of two or more nodes Ny. Additionally, orchestration service 422 may allocate various SD data storage entities or components 413 of application layer 412 to reside on physical layer storage resources, such as a single node Ny, multiple nodes Ny, etc., for, e.g., ease and speed of access by resident containerized components, for redundancy purposes, balancing memory usage across the physical platform, etc. In doing so, orchestration service 422 not only establishes running containerized applications and services, but also manages fault tolerance, load balancing, QoS, and / or other performance aspects of running containerized applications and services of compute fabric 400, e.g., via quality of service (QoS) configuration services 452, fault tolerance services 455, load balancing services 458, and optionally other performance-related services 460 provided by OS 410.Thus, the orchestration service 422 may be invoked or accessed by other OS services 415, 418, 420, 425, and the orchestration service 422 may in turn invoke or access one or more of the performance-related services 452-460. Generally speaking, the orchestration service 422 allocates resources to the containerized components and SD data storage entities of the logic process control system 445 so that the containerized components can operate efficiently and securely, e.g., to control an industrial process at least at an optimal performance level.

[0162] To this end, performance-related services 452-460 of OS 410 may monitor performance parameters, resource usage, and / or metrics during run-time, detect any related conditions that occur and / or are predicted to occur, and provide for and / or implement any changes in the allocation of application layer software components (e.g., containerized components) 412 to the hardware and / or software resources of computing platform 405. Thus, as various expected and / or unexpected hardware and / or software conditions occur and are detected during run-time of system 100, orchestration service 422 responsively adjusts the allocation of hardware and / or software resources of various compute fabric nodes Ny relative to the instantiated container images to maintain (or attempt to maintain) targeted or optimal levels of performance and operational fidelity. Detected conditions that may cause the orchestration service 422 to change the allocation and / or allocation between the containerized components 412 and the physical resources of the node Ny may include, for example, hardware failure or fault, software failure or fault, overload of a particular compute fabric node, increasing or decreasing the bandwidth of various networking components, adding or removing nodes and / or clusters of compute fabric nodes, hardware and / or software upgrades, pinning and / or unpinning of containerized services and / or applications, diagnostics, maintenance, and other routines that may make hardware and / or software resources temporarily unavailable for uptime use.Possible response and / or mitigation operational actions that may be taken by the orchestration service may include, for example, reallocating containerized services and / or applications to run using different software and / or hardware resources (possibly on different nodes Ny), activating and / or deactivating software and / or hardware resources, changing the access priorities of various containerized components to various software and / or hardware resources, etc.

[0163] Thus, and generally speaking, the services, subsystems, and other software components of the software-defined application layer 412 (e.g., 435, 438, 440) may determine, define, or specify the processing, containerization, networking, and storage needs of the logic process control system 445 at the individual container level and at an aggregate level (e.g., at the subsystem level, unit level, area level, and / or the process control system 445 as a whole). Through the API 428 (and in some configurations also through the HCI adapter layer 430 and API 432), the OS 410, its support services 415, 418, 420, 422, 425, and its orchestration service 422 operate and manage the hardware and software resources of the compute fabric node Ny to support these needs. For example, in some embodiments, the SD orchestrator 422 may cause different instances of a particular control routine 435 or a particular other service 440 to run on different nodes Ny, e.g., for fault tolerance, quality of service, and / or other performance criteria of the compute fabric 400. Advantageously, as the needs of the logic process control system 445 dynamically change over time, the OS support services 415, 418, 420, 422, 425 and / or orchestration service 422 may modify, change, and adjust the use of the hardware and software resources of the node Ny, e.g., in a reactive and / or predictive manner.

[0164] For example, when logic process control system 445 creates additional instances of control service 435 to run in additional containers, OS support services 415-425 may responsively (via APIS 428 and optionally HCI adapter 430 and API 432) assign the newly created containerized components to run on corresponding compute fabric nodes Ny, may rebalance existing containerized components among nodes Ny, may allocate specific hardware memory resources to support the logic memory resource needs of the additional containerized components, may adjust routing tables utilized by nodes Ny to support the logic routing needs of the newly created containerized components, etc. In another example, if a particular cluster C2 needs to be removed from service (e.g., for maintenance purposes or unexpectedly due to a lightning strike), the OS support services 415-425 may preemptively reallocate containerized components currently assigned to run in cluster C2 to other clusters according to the current needs of the logic process control system 445 and the availability of hardware and / or software resources in the other clusters, and the support services 415-425 may adjust the routing tables utilized by cluster Cx accordingly so that continuity of execution of those containerized components is maintained even when cluster C2 is removed from service.

[0165] Thus, the software-defined networking layer 410 automatically, dynamically, and responsively determines, initiates, and implements changes to the allocation of hardware and software resources of the node Ny of the computing platform 405 to the different application layer software components 412 based on detected conditions, such as an improvement in the performance of an individual logic and / or physical component or group thereof, a degradation in the performance of an individual logic and / or physical component or group thereof, a fault occurrence, a failure of a logic and / or physical component, or a change in configuration (e.g., by user command or by automatic reconfiguration by services of the compute fabric 400). As a result, the compute fabric 400 may automatically redistribute the hardware and software resources of the node Ny in response to changing conditions and components of the compute fabric 400, thereby supporting the process control system 245 and other services running in the application layer 412 of the compute fabric 400.

[0166] simulation In some implementations, the compute fabric 400 may implement simulations of, or changes to, various application services 435, 440, 448, the entire software application layer 412, various support services 415-425, 452-460, and / or the entire software-defined networking layer 410. That is, simulations of target components / layers may execute in coordination with active software-defined components / layers residing on the computing platform 405, thereby receiving uptime data from the field environment of the industrial process plant and operating accordingly, e.g., with the same logic, state, timing, etc. as the active target components / layers, or with simulated test logic, state, timing, etc. However, I / O and other types of data generated by the simulation may be prevented from being delivered to the field environment, and the simulation may be paused, sped up, slowed down, supplied with test inputs, and otherwise managed to observe operation and make modifications to the simulated components / layers. Thus, once a simulated portion of the computational fabric 400 is approved, the simulated portion may simply be activated for use during uptime operation of the industrial process plant without having to suspend or remove any portion of the computational fabric 400 from service to do so.

[0167] NGPCAS Exemplary Security Features Next, various security features of the next-generation process control and automation system (NGPCAS) 100 are described. As discussed above, today's process control and automation systems designed around the Purdue model suffer from many drawbacks, including increased complexity (and therefore more opportunities for component and process failure), reduced performance, and a greater risk of cyber intrusion, to name a few. For example, in today's process control and automation systems, at least three different domains may typically exist between Levels 2, 3, and 4, and the security policies for each domain may differ and require different security management techniques. Therefore, cross-level connectivity can be difficult to implement and can introduce significant delays in the delivery of data across multiple Purdue levels, e.g., from Level 2 to Level 4 and above. Furthermore, the industry is interested in being able to deliver instructions, commands, and / or other information from higher levels to lower levels in the Purdue model. For example, a technician or other process plant personnel may be working remotely via his or her portable computing device and may wish to monitor runtime process plant operations and adjust configurations, parameter values, settings, etc. within the process control system in response to monitored conditions. In such a situation, as commands and information move from higher to lower levels in the Purdue model (e.g., through "holes" added to established security mechanisms for these purposes), outbound firewalls and other currently implemented security mechanisms designed and utilized to prevent the inflow of external information into the plant will inevitably be compromised, thereby introducing significant additional risks of outsiders gaining access to the plant's protected lower-level information and data, as well as other types of cyber intrusion. Furthermore, the numerous security mechanisms implemented between Purdue tiers, either as originally designed or with any added "holes," create a highly complex network that is difficult to design, maintain, and utilize to efficiently deliver information between Purdue levels.

[0168] Furthermore, current systems that perform some process control and / or automation functions in the cloud introduce other undesirable problems. For example, if a process plant in such a system loses internet connectivity, it cannot access the cloud, and any control or automation functionality provided by the cloud becomes unavailable. Additionally, cloud-based implementations add additional latency, bottlenecks, and complexity beyond those introduced by Purdue model implementations. Furthermore, no sufficiently secure mechanism exists to support native communication between process control devices (e.g., field devices) and the cloud.

[0169] The security features of NGPCAS100 address at least these known security issues of Purdue model implementations and provide additional security, improved performance, easier engineering and maintenance of NGPCAS100, and other benefits and advantages. Examples of such security features are described below. Any of the described security features may be used as a standalone security feature or in combination with any other one or more security features. In some embodiments, various security features of NGPCAS100 may be implemented as services 425 provided by software-defined networking layer 410 of compute fabric 400. Additionally, software-defined networking layer 410 may provide other services 415 that manage groupings of software-defined networking layer 410 and / or physical layer 405 resources and / or hardware and / or software resources of compute fabric 400 that are allocated and / or utilized to support the security features of NGPCAS100.

[0170] NGPCAS Exemplary Network Security Features As noted above, communications between nodes, configured containers, locations, devices, and / or other portions of the NGPCAS 100 and the human-operated computing device 155 (if present) may be secured via one or more VPNs, which may include mutually exclusive and / or nested VPNs. As noted above, for ease of discussion and not by way of limitation, the term “VPN” is utilized herein to refer generically and categorically to various types of secure, encrypted point-to-point (PTP), peer-to-peer (P2P), and / or point-to-multipoint (PTM) connections. In any event, each VPN, nested or not, may block traffic from nodes, components, etc. not included in the VPN, and VPN endpoints may communicate with each other via the VPN through respective sessions. The VPN configuration of the NGPCAS 100 (e.g., number of VPNs, type of VPNs, VPN nesting, etc.) may be implemented over one or more public and / or private networks, including private corporate networks, the public Internet, etc. Additionally, the VPN configuration of NGPCAS 100 may be customized to meet the security needs and requirements of, for example, an enterprise and / or architecture provider manager. If desired, at least one of the VPNs of NGPCAS 100 may be a permanent VPN.

[0171] 1 and 4 for illustration, in an exemplary minimum VPN configuration, communications between the physical or field environment 120 of the NGPCAS 100 (e.g., all or all of the components, devices, etc. of the NGPCAS 100 disposed within the field environment 120) and the compute fabric 102 of the NGPCAS 100 (including all or all of the containerized components included within the compute fabric 102) may be secured via only a single VPN. In an exemplary maximum VPN configuration, communications between any pair of entities of the NGPCAS 100 (e.g., exposed APIs 160, 165, other containerized components / MEEEs / granules 140, compute fabric 102, physical components 135, locations 115, 118, the physical environment 120 as a whole, user applications and / or devices 155, architecture provider / manager applications and / or devices 161, etc.) may be secured via their respective VPNs. For example, in a maximum VPN configuration, configured containers providing control service functions that require the use of utility functions to perform control services may communicate with configured containers providing utility functions via their respective VPNs. In an embodiment, the VPN configuration of the NGPCAS 100 is: a point-to-point VPN, e.g., a VPN that exclusively serves communication between only one physical component 135 and only one containerized component / MEEE / granule 140; Point-to-multipoint VPNs, e.g., VPNs that exclusively serve communications between only one physical component 135 and many containerized components / MEEEs / granules 140, VPNs that exclusively serve communications between many physical components 135 and only one containerized component / MEEE / granule 140, etc. a multipoint-to-multipoint VPN, e.g., a VPN that exclusively serves communications between only a subset of the physical components 135 at the location 115 and a subset of the containerized components / MEEEs / granules 140 in the compute fabric 120; a VPN exclusively serving communication between different layers of the compute fabric 400, e.g., between the software-defined application layer 412 and the software-defined networking layer 410; a VPN exclusively servicing communication between one or more selected services, subsystems, and functions of different layers of the compute fabric 400, for example, between a selected one or more of the services and / or subsystems 435, 438, 440 in the application layer 412 and a selected one or more of the software-defined services and / or functions 415, 418, 420, 425 in the networking layer 410; a VPN that exclusively services only the API 160 and the user application 155 instance, and one or more other VPNs that exclusively service the API 160 and one or more containerized components / MEEEs / granules 140 and / or physical components 135, 138 needed to obtain or provide data to the user application 155, e.g., in a point-to-point and / or point-to-multipoint manner; Inter-location VPNs, e.g., VPNs that exclusively serve communications between a single location 135 and the compute fabric 102 as a whole; a multi-location VPN, e.g., a VPN exclusively serving communications between the compute fabric 102 and a multiplicity of locations 115, 118 that collectively represent only a subset of the total locations of the NGPCAS 100; and / or may include one or more other types of VPNs that protect and secure communications between designated or defined endpoints (e.g., nodes, configured containers (which may include APIs 160, 161), locations, devices, and / or other parts of NGPCAS 100) within NGPCAS 100. Indeed, in embodiments, each endpoint may be required to authenticate to each VPN that the endpoint will utilize to send and / or receive communications with one or more other entities that are each authenticated to that VPN.

[0172] NGPCAS Exemplary User Security Features As mentioned above, users 155 of NGPCAS 100 may include human users operating computing devices running one or more applications (e.g., a web browser, thin client, or another user interface) to communicate with NGPCAS 100, such as an operator, a configuration engineer, a third party authorized by the enterprise to access at least a portion of system 100, another agent of the enterprise, or an agent of architecture provider / manager 161, to name a few. Additionally or alternatively, users 155 may include automated users, such as external applications or services, that do not have a user interface and run on an external (e.g., remote) computing device or system. External application / service users 155 may be enterprise-based, e.g., applications and / or services configured by enterprise personnel, or may be third-party applications and / or services. Some of external application / service users 155 may be applications and / or services provided by architecture provider / manager 161 for use by architecture provider / manager 161 and / or the enterprise. In any event, to secure system 100 against possible cyber-attacks when legitimate users 155 access system data and / or functionality, each user 155 may be required to interface with and / or access system data and / or functionality provided by NGPCAS 100 using one or more exposed APIs 160. For example, functionality provided by NGPCAS 100 for use by users 155 may be implemented within computational fabric 102 as respective containerized components / MEEEs / granules 140, and such containerized components may be exposed to users 155 only via APIs 160 (e.g., as websites, services, etc.), which may be accessed by users 155, for example, via a web browser or thin client.Typically, any functionality (e.g., all functionality) provided by NGPCAS 100 for use by user 155 is accessible to user 155 only through one or more respective APIs 160. Furthermore, for added security, communications between user 155 and one or more APIs 160 may be secured via respective VPNs 158. For even further security, user 155 may be required to first authenticate to VPN 158 before being able to utilize API 160; in particular, human users may undergo multi-factor authentication to gain access to VPN 158.

[0173] In some situations, a particular user 155 may be authenticated and / or authorized to utilize only a subset of the available exposed APIs 160. That is, the set of APIs 160 exposed to and / or authorized to be accessed by different users 155 may differ based on the user's respective credentials. For example, authorization of different users 155 to different APIs 160 may be based on the containerized components 140 (e.g., applications and / or services) to which the APIs 160 provide access. Additionally or alternatively, authorization of different users 155 to different APIs 160 may be implemented on an enterprise basis (e.g., a user 155 at company A may be enabled to access a first subset of APIs 160, while a user 155 at company B may be enabled to access a second, different subset of APIs 160), location-based, node-based, user credential-based (e.g., the user's role, responsibilities, and / or skills), time-based, and / or combinations thereof.

[0174] Thus, by using a VPN to secure communications within the NGPCAS 100, security mechanisms (e.g., firewalls, data diodes, DMZs, and other mechanisms) utilized between layers of Purdue model-based systems to secure cross-level communications can be eliminated. Indeed, in one embodiment, the NGPCAS 100 does not include (e.g., excludes) any firewalls, data relays, data diodes, and DMZs utilized to secure communications and data delivery to, from, and within the NGPCAS 100, thereby simplifying the design, engineering, configuration, maintenance, and runtime performance of the NGPCAS 100 compared to Purdue model-based systems. Furthermore, because each VPN blocks or does not process any traffic originating from outside the VPN, and any and all human and / or automated users 155 of the VPN must be authenticated to the VPN, data utilized within the process control or automation system is exposed only to components / entities authorized to access the VPN to which the data is delivered. Thus, the opportunity for externally initiated cybersecurity breaches and malware proliferation is significantly reduced compared to today's systems, or even potentially eliminated.

[0175] Furthermore, because access to selected functionality provided by NGPCAS 100 is provided to user 155 via API 160, and user 155 must be authenticated to VPN 158 and, optionally, authenticated to utilize certain APIs 160 as described above, cybersecurity risks are further significantly reduced compared to those of today's systems. For example, such security techniques utilized within NGPCAS 100 eliminate the need for any NGPCAS-specific software to be installed on some external computing devices (such as those operated by human users). That is, such external computing devices may have no (e.g., zero) NGPCAS-specific software installed, thereby eliminating another possible avenue for cybersecurity breach. In another example, a computing device operated by user 155 (human or automated) may be authenticated to a VPN 158 that is not utilized by any component of NGPCAS 100. That is, the VPN utilized by the user 155 (and optionally by the API 160 exposed to the user 155) and the VPN utilized by other non-user components and / or entities of the NPGCAS 100 may be mutually exclusive VPNs, thereby further eliminating other possible avenues for cybersecurity breach. In yet another example, an unauthorized (but otherwise valid) user 155 may be prevented from any access (including read-only access) to the NPGCAS 100 or portions thereof.

[0176] NGPCAS Exemplary Identity Security Features As described above, each component of the NGPCAS 100 (each containerized component / MEEE / granule 140, each physical component 135, each device 105, 125, 108, 128, 148, each location 115, 118, compute fabric 145, architecture provider / manager 161, or generally any component that may serve as an endpoint in the NGPCAS 100 network) may be uniquely identified within the NGPCAS 100 by a unique network identifier. In an embodiment, the unique network identifier of a given component is based on the component's identity defined in the configuration database of the NGPCAS 100. Similar to the above description for users 155 of the NGPCAS 100, each component may be authenticated and authorized based on its unique network identifier in order for the component to access one or more VPNs, communicate with one or more nodes, configured containers, locations, devices, and / or other components, etc. Generally speaking, components of the NGPCAS100 that have a unique network identifier (e.g., all components of the NGPCAS100) may be discovered within the NGPCAS100 and may be required to utilize respective certificates to be authenticated and authorized for access.

[0177] At least some of the physical devices 105, 125, 108, 128, 148 included in NGPCAS 100 may also include device identifiers that are unique across the enterprise, as described above with respect to FIG. 5A_5?. For these devices, an indication of the association between the device's unique device identifier and the device's unique network identifier may be stored, for example, within the device itself, within a configuration database of NGPCAS 100, within a network manager of NGPCAS 100, etc.

[0178] NGPCAS Exemplary Communication Security Features To further secure the NGPCAS 100, all communications sent and received over the NGPCAS 100's network (e.g., via VPNs 130, 158, 162 between various authenticated and authorized components) may be required to be signed and encrypted. Additionally or alternatively, plaintext protocols (such as HTTP) may be prohibited or otherwise prevented from being used within the NGPCAS 100. For further security in deployments where an architecture provider / manager 161 manages multiple NGPCASs 100 for multiple companies, each company may have a different Certificate Authority (CA), and self-signed certificates may be prohibited or otherwise prevented from being used. Generally speaking, to maintain security within the NGPCAS 100 over time, certificates may support revocation, have configurable key sizes (e.g., to support system growth), and be automatically refreshed without any company intervention.

[0179] NGPCAS Exemplary Compute Fabric Security Features In particular, various security techniques may be used within the NGPCAS 100 with respect to securing the compute fabric architecture 400 and its components. For example, as described above, the containerized components / MEEEs / granules 140 of the compute fabric 102 / 400 (e.g., APIs 160, 165; services and subsystems 435, 438, 440, 448, 413, 442 in the software-defined application layer 412; services and functions 415, 418, 420, 422, 425, 452, 455, 458, 460 in the software-defined network layer 410; APIs 428, 432 and / or other services provided in the adapter layer 430, etc.) may be configured for client certificate access, where the client may be, for example, another containerized component / MEEE / granule 140, a user 155, or an architecture provider / manager 161. That is, anonymous access to containerized components / MEEEs / granules 140 may not be enabled, and only specific clients may be provided access to specific containerized components / MEEEs / granules 140 (e.g., via corresponding client certificates). Furthermore, client certificates may be automatically and frequently rotated. Additionally, in embodiments, unused features (e.g., applications, services, etc.) may be placed in a disabled (not enabled) state.

[0180] Additionally, containerized components / MEEEs / granules 140 may be signed and periodically scanned for known vulnerabilities. Containerized components / MEEEs / granules 140 may be required to run or operate with least privileges (e.g., always), and the runtime of a containerized component / MEEE / granule 140 may be required to utilize the maximum level of container isolation, e.g., by default. In some implementations, the definition of groupings of containerized components may be prevented or restricted. For example, the NGPCAS 100 may be enabled to define only groups of containerized components that are specifically related to process control system components. For example, a group of containerized components utilized for bioreactors may be defined or configured as a bioreactor grouping (e.g., by using pods or other suitable mechanisms provided by the operating system 410 of the compute fabric 400) such that the bioreactor grouping of containerized components may be co-located and moved together to run, e.g., on different nodes, clusters, segments, etc.

[0181] At the physical layer 405 of the compute fabric 400, access to different nodes Ny, different segments of hardware, different clusters C1, ...Cn, etc. may be controlled, for example, server-based, API-based, etc. Furthermore, static data and disk may be encrypted at rest.

[0182] NGPCAS Example Hardware Security Features In embodiments, field devices, hardware I / O devices, gateways, and other devices may include one or more forms of Embedded Device Identification ("EDID"). Similar to how a serial number indicates a particular instance of a product and may indicate additional information about the model, options, or other data about the product, an EDID may be associated with and / or indicate an individual instance of a device or product and / or may be associated with and / or indicate additional information. As described below, EDID may facilitate faster and less labor-intensive commissioning of process plants, in addition to various security and other benefits.

[0183] 5A-5C illustrate implementations of EDID in various types of hardware devices. For example, FIG. 5A is a block diagram illustrating a smart field device 500, such as a Foundation Fieldbus device. As will be appreciated, the smart field device 500 can be any number of device types, including a valve, a valve controller, a sensor, a transmitter, or any other type of field device having a process, memory, and a communication channel capable of communicating numerous types of data (e.g., settings, measurements, calculations, device tags, etc.). The smart field device 500 includes a processor 502 and one or more memories 504 that store various data readable according to the Foundation Fieldbus protocol (e.g., measurements, settings, status information, scale information, limits, alarms, device descriptors, device IDs, device tags, etc.), as will be readily appreciated by those skilled in the art. The smart field device 500 also includes one or more sensors and / or actuators 506 and a communication transceiver 508, as will be appreciated. In the smart field device 500 illustrated in FIG. 5A, the device also includes an embedded device ID (EDID) 510 .

[0184] 5B is a block diagram illustrating a sensor / transmitter device 512. The sensor / transmitter device 512 includes a transducer 514 operable to measure a parameter and a transmitter 516 operable to transmit an indication of the measured parameter to a receiving device (e.g., an I / O card, a smart field device, a gateway, a service running on a computing fabric, etc.). The sensor / transmitter 512 also includes an EDID 520.

[0185] The I / O device 522 is illustrated in the block diagram of FIG. 5C. The illustrated I / O device 522 is of a type commonly known in process control (except for the inclusion of one or more EDIDs) and may facilitate the conversion of one or more I / O signals from one or more respective field devices into signals that can be forwarded to a control device or service (e.g., a controller service operating in a computational fabric), and the conversion of one or more signals from the control device or service into signals that can be forwarded to the respective field devices. The I / O device includes a processor 524, a memory 526, and a bank 528 of I / O modules 530A-530D, each of which couples a respective field device to the process control system via the I / O device 522. The I / O device 522 also includes one or more EDIDs 540, 550, 560. The EDIDs 540, 550, 560 included on the I / O device 522 may include a single EDID 540 associated with the I / O device 522 as a whole, an EDID 560 associated with the I / O module bank 528 (e.g., a set of terminals each configured to accept a respective I / O module 530A-530D that couples a respective field device to the I / O device 522), and / or one or more EDIDs 550A-550D each associated with a respective one of the I / O modules 530A-530D. In some embodiments, each individual component, the I / O device 522, the I / O modules 530A-530D, and the I / O module bank 528, may have an EDID, while in other embodiments, only the I / O device 522 may have an EDID, etc. Additionally, although I / O device 522 is illustrated as having four I / O modules 530A-530D, in various embodiments I / O device 522 may have more or fewer I / O modules 530, and in other embodiments I / O device 522 may utilize other means (i.e., other than I / O modules) for coupling field devices to I / O device 522.

[0186] Each EDID 510, 520, 530, 540, 560 is a built-in unique identification for a device. In embodiments, the EDIDs 510, 520, 530, 540, 560 may contain a multitude of information, but in preferred embodiments, each EDID 510, 520, 530, 540, 560 is simply a unique identifier that is associated with other relevant information about the device in a relational database. The EDIDs 510, 520, 530, 540, 560 may be embedded on the respective devices in any number of ways. For example, in embodiments, the EDIDs 510, 520, 530, 540, 560 are burned into non-volatile read-only memory (e.g., EEPROM, UV-ROM, etc.). In other embodiments, the EDIDs 510, 520, 530, 540, and 560 are hardwired into the devices at the printed circuit board (PCB) level, for example, by a series of short and / or open signals. In still other embodiments, the EDIDs 510, 520, 530, 540, and 560 may be embedded into a chip during manufacturing. In still other embodiments, the EDIDs 510, 520, 530, 540, and 560 may be the result of a physically non-replicable function that utilizes variations in the manufacturing process of one or more components to generate what are essentially random values. Regardless of the means by which the EDIDs 510, 520, 530, 540, and 560 are embedded into their respective devices, the EDIDs 510, 520, 530, 540, and 560 are generally difficult to modify and / or overwrite, at least without opening the device to access its internal hardware.

[0187] 5D illustrates an exemplary EDID 562 that may be embedded on a hardware device. The EDID 562 may include only, or at least, a unique identifier 564. However, if the EDID 562 includes multiple pieces of information, the information may be stored on the device as a series of values. Example optional values ​​(denoted by dashed boxes) that may be included in the EDID 562 include values ​​indicating an owner / company / customer associated with the device 565, a model of the device 566, a facility associated with the device 567, a geographic region associated with the device 568, a manufacturer of the device 569, a registry associated with the device 570, one or more options present on the device 571, a manufacturing date of the device 572, etc.

[0188] In particular, in embodiments in which the EDID on a device includes only a unique ID, the database 580 may, as desired, associate each EDID with values ​​indicative of various information 565-572, as illustrated in FIG. 5E. The various information 565-572 associated with each EDID may be stored in the database 580 at the time of sale of the device, when the device is shipped, or dynamically upon first use of the device. The database 580 may be stored, for example, on the compute fabric 102 and accessed by an EDID service 582, which may be responsible, collectively or in cooperation with other services, for authenticating and / or determining whether a device is allowed to operate in a particular process control system.

[0189] In an embodiment, upon connection to the compute fabric 102 (e.g., upon commissioning, process startup, reboot, etc.), each hardware device must authenticate to the system. A discovery service running on the compute fabric 102 requests and / or receives and / or discovers its EDID from each hardware device. The discovery service sends each received EDID to an EDID service 582 (which, in an embodiment, may or may not be separate from the discovery service), which queries a database to determine one or more pieces of information associated with the EDID and determines whether to validate the EDID, and therefore the device associated with the EDID. As non-limiting examples, the EDID service 582 may determine whether a given EDID is associated with an owner / company / customer associated with the process plant in which the device is located, whether a given EDID is associated with the geographic region in which it is currently operating, whether a given EDID is installed in its intended facility, etc. If the EDID service 582 determines that the device is valid / verified, the EDID service 582 may communicate to other services (e.g., security services, certificate authority services, etc.) that the device should be allowed to operate within the system (or operate as a whole). Alternatively, if the EDID service 582 determines that the device is invalid, stolen, counterfeit, off-site, in the wrong plant, in the wrong geographic area, etc., the EDID service 582 may communicate to other services not to allow the device to operate within the system, and in some embodiments may remotely disable the device, rendering it completely inoperable.

[0190] In this manner, EDID may be used to increase security by increasing the likelihood that devices operating in the secure environment of a process plant are of known origin before issuing a security credential that enables the device to connect to the secure network over which devices and services communicate across the compute fabric 102. That is, unverified devices will not be granted a certificate by the certificate authority. EDID may also be used to prevent black market sales of devices (e.g., to violate sanctions or trade restrictions), deter theft, prevent reverse engineering, prevent counterfeiting, etc., by disabling or otherwise preventing operation of any device that is off-site (not owned by the associated customer, not at the associated plant, not within the associated geographic region, stolen, etc.).

[0191] Implementation of EDIDs 510, 520, 530, 540, 560 may also facilitate improved commissioning of process plants. In embodiments, information associated with each EDID may include information about the configuration of the field device and / or options installed on the field device. In embodiments, information associated with each EDID may include one or more device tags and / or one or more control modules associated with the field device. Thus, based solely on the EDID, a discovery / EDID service may be able to determine, for a particular process, which services should send data to and receive data from the field device, configure I / O services for the field device, set up appropriate secure connections between the device and other components, and so on. Simply put, the use of EDID may enable process plants to ramp up and produce products more quickly (and therefore more cheaply).

[0192] 5F illustrates an example method 590 for implementing the use of EDID in a process control system. The method includes receiving data indicative of an EDID (block 592), looking up the received EDID in a database (block 594), and determining from the lookup results whether the device is enabled to operate in the system (block 596).

[0193] Other exemplary security features of NGPCAS In addition to the security functions described above, NGPCAS 100 may include one or more other security features that protect other functions and aspects of system 100, at least some of which may be provided out-of-the-box, at least some of which may be customized and tailored, for example, by an enterprise agent, a system provider agent, etc. Such security features may include, for example, role-based access control (RBAC) for various applications and human users, service principles, security policies, security audit logs (and optionally analysis and optimization of the data contained therein), network security groups (e.g., by application, location, human user, and / or other category), firewalls, and access control lists (ACLs), to name a few. Additionally, secrets (e.g., keys, certificates, etc.) utilized by system 100 may be stored in one or more secure vaults.

[0194] Furthermore, resources of system 100 may be secured in a leveled manner, as illustrated in the example resource security technique 599 illustrated in FIG. 5G . Resources may include hardware and / or software resources, such as components, clusters, nodes, and services (e.g., configured containers), as described above. At the individual or single resource level, each individual resource may be protected in the manner described above (e.g., based on its identity, using keys and certificates, etc.). At a higher level, resources may be grouped (e.g., in the manner described above), and each resource group may be secured and protected as a group (e.g., by group identity, keys, certificates, etc.). Resource groups may be defined and / or created based on any category, such as by location (e.g., field devices and on-premise, remote locations, within a compute fabric, etc.), by function, by time, etc. At an even higher level, subscriptions to various individual resources and / or various resource groups may be utilized so that only users who have subscribed to a particular resource or resource group may access the particular resource or resource group. That is, access to particular resources or resource groups may be limited to only users with subscriptions to them, thereby providing additional security to the system 100. Note that individual resources may be included in one or more different resource groups and / or accessed via one or more different subscriptions. Additionally, note that resource security techniques 599 may be applied on-premise at the location where the field devices are located, off-premise at other physical locations, and / or within the compute fabric, as desired. Of course, other resource security techniques may additionally or alternatively be utilized in the NGPCAS 100.

[0195] Additional Architectural Features of NGPCAS Due to the distributed and highly configurable nature of the NGPCAS computational fabric described herein, an NGPCAS for a particular enterprise can be configured or set up by the enterprise to enable new types of data management and execution management to be implemented within the computational fabric, allowing the enterprise to uniquely configure global or inter-plant data flow and execution management in a manner not possible with previous control systems. In particular, the computational fabric of an enterprise with multiple physical plants or locations can be set up in a hub-and-spoke configuration, where multiple different computational fabric "hubs" can be created to support various different physical locations or plants connected to the hubs via a communication network implementing the communication "spokes." Each hub can have computational resources limited to or implemented in a particular geographic or sovereign region. These regions can be, for example, a continent (e.g., North or South America, Europe, Africa, etc.), a country (e.g., the United States, Russia, China, Australia, Germany, France, etc.), a state or defined region of a particular country (e.g., California, Florida, etc.), or any other geographic or geopolitical region. In this case, the compute fabric hardware may be implemented in a cloud environment or other physical location physically located within or contained within a particular region (or set of regions) to form a compute hub. Each compute hub may be connected to one or more physical locations or plants of an enterprise via a communications infrastructure described herein, forming spokes from the compute fabric hub to the physical locations. In some cases, two or more compute fabric hubs may be connected to the same physical location, and each such compute fabric hub may receive all or a subset of data from that physical location. Furthermore, in some cases, a compute fabric hub may connect to one or more physical locations within the same region as the hub via one or more communication spokes, and / or to physical locations in one or more regions different from the hub via other communication spokes.

[0196] FIG. 6A illustrates an example enterprise NGPCAS system 600 having several compute fabric hubs 602 located in various regions—in this case, countries or a common political territory (e.g., the European Union)—connected to various physical locations via one or more communication spokes 603. In this example, the enterprise includes two compute fabric hubs 602A and 602B located in the United States, one compute fabric hub 602C located in Europe (e.g., one or more countries associated with the European Union (EU)), one compute fabric hub 602D located in Russia, and one compute fabric hub 602E located in Africa. Each of the compute fabric hubs 602 includes one or more terminal communication spokes 603, each terminal communication spoke 603 proceeding from the hub 602 to a physical location 604. As will be appreciated, the spokes 603 associated with a particular hub 602 may connect the hub 602 to different physical locations that may be within the same region as the hub 602 or a different region. Additionally, if desired, one or more communication spokes 603I may be disposed or configured to provide communications between two hubs 602 to enable direct inter-hub communications. In this manner, data received from a particular physical location 604 at a first hub 602 via a communication spoke 603 at that hub 602 may be routed to a second compute fabric hub 602 via an inter-hub spoke 603I. Similarly, a communication (e.g., control signal, data request, configuration change, etc.) from a first hub 602 may be transmitted to a particular physical location 604 by the first hub 602 by transmitting the data to the second hub 602 via an inter-hub spoke 603I, which may then provide the communication to the physical location 604 via a communication spoke 603 established between the second hub 602 and the physical location 604. As illustrated in FIG. 6A , a particular compute fabric hub 602, such as hub 602A, may in some cases only include terminal spokes 603 to physical locations 604 within the same region (e.g., the United States). Of course, in other cases, a particular compute fabric hub 602, such as hub 602B, may include terminal spokes 603 that go to physical locations 604 in multiple different regions (e.g., physical locations in both the United States and the EU).Similarly, multiple different hubs 602 may be connected to the same physical location 604 via different spokes, such as in the case of hubs 602B and 602C and physical location 604A.

[0197] Importantly, this hub-and-spoke configuration allows data and execution controls to be configured and maintained separately at each compute fabric hub 602, enabling enterprises with physical locations in multiple different regions to comply with various different laws or data governance regulations within the particular region in which the physical locations and / or compute fabric hubs 602 are located. For example, different regions (such as the United States and the EU) may have different data privacy, data export, and data management laws and regulations, and therefore, it may be important to segregate and track different data transmitted to and stored at a particular compute fabric hub 602 for processing and handling in a manner that complies with the hub 602's appropriate laws and regulations. However, these laws and regulations typically apply only to data at rest, not data in motion. Thus, the hub-and-spoke structure described herein also enables data collected by devices at a particular physical location (either all of the data or some subset of the data) to be transmitted to and stored only at compute fabric hubs 602 located in regions where data privacy laws and regulations apply, thereby enabling the collected data to be governed by the set of data privacy laws associated with one particular region. Thus, data collected at a physical location 604A located in the EU may be transmitted directly to, for example, a compute fabric hub 602B in the United States without being stored in a hub 602C in the EU. In this case, a direct communication spoke 603A may be established between the hub 602B in the United States and the physical location 604A in the EU, and this data may or may not be transmitted or stored in the hub 602C in the EU. However, in another case, data from the physical location 604B in the EU may first be transmitted to the hub 602C in the EU via spoke 603B. However, the compute fabric hub 602C in the EU may immediately transmit the data to the hub 602B in the United States via inter-hub communication spoke 603I without storing the data, thereby ensuring that the data is not governed by EU data laws and regulations.

[0198] Of course, the hub-and-spoke configuration described herein can similarly or alternatively be used to manage or direct execution and operational activity at various different hubs and / or various different physical locations using the same concepts. For example, different compute fabric hubs 602 may manage the execution of applications and services and provide or manage user or application authorization differently by storing and applying different sets of rules or policies implemented by each compute hub 602 at the physical location 604 to which the hub 602 is connected. The ability of each compute fabric hub 602 to store and apply different data governance, application, and other system execution rules provides great flexibility within an enterprise in managing and storing data and managing and controlling application execution differently at different physical locations 604 and different compute fabric hubs 602. This feature therefore allows different configuration paradigms to be used at each different hub 602, or even at each different physical location 604, even when the different hubs 602 or physical locations 604 are each associated with the same enterprise.

[0199] Generally speaking, to perform these data and execution management activities, the compute fabric for a particular hub 602 stores a set of rules—data governance rules, execution rules, access authorization rules, etc. (illustrated as components 610A, 610B, 610C, 610D, and 610E in hubs 602A, 602B, 602C, 602D, and 602E, respectively)—which are then automatically implemented or applied by the appropriate compute fabric components in hubs 602A-602E to manage data flow, application and service execution, user and service authorization, etc. Additionally, the architecture provider / manager may provide an interface for each hub 602 to enable an enterprise (e.g., one or more authorized configuration engineers associated with the enterprise) to define, set up, and store the data governance and execution rules 610 used in each of the hubs 602.

[0200] FIG. 6B is a chart 620 illustrating an example system hierarchy associated with an enterprise using the NGPCAS described herein, illustrating the manner in which various different components of an NGPCAS system as described herein may be related and implemented in the structural elements described herein. In particular, as illustrated in FIG. 6B, chart 620 includes three columns: right-most column 622 includes software, hardware, and firmware components associated with the NGPCAS listed in a hierarchical grouping view; middle column 624 indicates the physical or virtual execution location of the associated elements in column 622; and left-most column 626 indicates the purpose or operation of the elements in column 622. Thus, as illustrated in FIG. 6B, column 622 includes applications 630 that provide a customer or enterprise view (as shown in column 626) into the NGPCAS, and applications 630 are stored and executed on the compute fabric (as shown in column 624) within a cloud environment. Applications 630 may include any customer- or enterprise-facing and accessible applications, including, for example, one or more ATMP applications 632 that provide workflow tracking and secure logs for one or more batch process or production facilities, one or more enterprise guardian applications 633 that provide a customer portal to existing functions at the enterprise, one or more enterprise fleet management applications 634 that provide and track real-time health and inventory status of enterprise equipment and can make recommendations for changes, updates, etc., and one or more utility applications 635 (e.g., IEE applications). Further, applications 630 may include one or more enterprise control applications 636 (which may include any of the process control elements described or referenced herein, such as containerized control modules, containerized function blocks, enterprises, or device twins). Similarly, applications 630 may include one or more operations applications 637, engineering applications 638, and data management applications 639.Operational applications 637 may include applications that enable insight into and control of process operations, such as DeltaV Live applications, operator interface applications, alarm management applications, and data historian applications. Similarly, engineering applications 638 may include control and graphics configuration applications for defining and configuring control routines and user interfaces for control operations. Data management applications 639 may include data exchange and data visualization applications for enabling enterprise users to access and / or obtain views of data within the enterprise. Of course, any other desired applications, such as device maintenance applications, may be included and supported by NGPCAS at this level. As described in column 626, applications 630 are user-facing and therefore visible to and directly used by authorized users of the enterprise.

[0201] Additionally, as illustrated in FIG. 6B , NGPCAS includes a set of application frameworks 640 that support and enable applications 630, in this case implemented in a cloud environment used as at least part of the compute fabric for an enterprise NGPCAS. Application frameworks 640 may include, for example, frameworks that provide, manage, and implement role-based security (application access) 641, database (event and alarm database, historian, etc.) access, configuration, and support 642, service mesh framework 643, material support database 644, business or other rules 645 applied by applications 630, and protocol support framework 646 that supports communication protocol usage and translation. Rules 645 may define the data governance and application execution rules described with respect to FIG. 6A . Of course, frameworks 640 described herein are merely an exemplary set of frameworks that may be used and supported by NGPCAS, and other frameworks may be included or used as well or instead. Additionally, although frameworks 640 are configurable and accessible by businesses, these frameworks 640 are not directly user-facing, but instead support user-facing applications 630 .

[0202] Further, the NGPCAS of chart 620 includes one or more platforms 650, which may be implemented as software-as-a-service (SaaS) platforms in a compute fabric cloud environment (as illustrated by column 624) to implement and support the application framework 640 and applications 630. The platforms 650 may include, for example, a Kubernetes (or other) container management and orchestration platform, an observability and platform monitoring platform (used by either or both the enterprise and the architecture provider / manager), an identity and access management platform, a security management platform, a CI / CD pipeline platform, a feature promotion platform, a compliance and governance rules storage and implementation platform (such as rules 610 described with respect to FIG. 6A), a cost and subscription tracking platform, etc. Of course, the platforms 650 listed or described in FIG. 6B are merely examples and may be used to support various features of the NGPCAS described herein. However, other platforms may be used or provided as well. Furthermore, the platforms 650 need not necessarily be implemented as SaaS platforms. As will be appreciated, the platform 650 is managed by an architecture provider / manager with input from the enterprise.

[0203] Further, as illustrated in FIG. 6B, the NGPCAS hierarchy includes cloud support structures 660 for implementing a cloud environment as part of the compute fabric. In particular, the cloud environment support structures 660 include, for example, the Microsoft® AZURE Cloud Operating System, which implements the AKS or deterministic runtime environment and ARC services, as described herein. Of course, other cloud environment support structures or services may also or alternatively be used or provided, and the NGPAS is not limited to the cloud support structures 660 described and listed herein. Of course, as illustrated in FIG. 6B, the cloud environment 660 provides a control, data, and management plane (via a VPN or other communication connection) to edge devices 670, which may be located on-premises in a variety of different physical locations, as illustrated in column 624. Edge devices 670 may include, for example, I / O or other servers 672, data, networking, and storage servers 674 (such as data aggregators and / or VPN gateways), and local workload servers 676, which may be connected to local hardware 680, such as local controllers, field devices, and other on-premises hardware, as illustrated by column 624. Of course, edge elements 672, 674, and 676, as well as local hardware such as controllers, I / O devices, and field devices, are located on-premises to generate, measure, or provide local access to data and to perform other activities, such as control, maintenance, and support activities.

[0204] As will be appreciated, the layered structure of Figure 6B illustrates how all of the necessary applications, services, containers, microservices / MEEEs / granules, platforms, software, etc. described herein as part of an NGPCAS may be embedded to provide a complete process control and application services system for an enterprise, with components of this system distributed within a compute fabric (in this case exemplified as a cloud environment) and across one or more physical locations or facilities. More specifically, graph 620 of Figure 6B illustrates how user-facing applications, including control applications, maintenance applications, data storage and tracking applications, process control and configuration applications, management applications, workflow management applications, etc., may be layered and embedded into an NGPCAS running in an execution environment.

[0205] NGPCAS configuration and support features As will be appreciated, the NGPCAS described herein provides or enables its software-implemented components to be highly configurable, transportable, and editable because the majority of control and support components (e.g., control modules, containers, etc.) are located within and run on the compute fabric without needing to be tied to specific or predetermined computer hardware (e.g., specific servers, processors, computer nodes, etc.). This feature enables system setup and configuration activities to be performed more quickly and easily than with traditional control systems, because enterprise system owners or administrators can store components for their systems in the compute fabric, access these components from anywhere, and copy these components to create or add additional control system structures associated with new plants or new physical locations added to the enterprise, for example, to new hardware installed at existing physical locations, without having to specify the location or details of the computer hardware used to implement the additional components. Furthermore, this architecture enables an architecture provider / manager (also referred to herein as an “APM”) to simultaneously oversee the operation of multiple different enterprise systems while those different enterprise systems are operating, which enables the APM to provide both general and specific support for different enterprise systems. For example, APM may monitor and capture service quality statistics and / or other data related to or defining the operation of various software and hardware components operating in the computational fabric of various different enterprise systems while these systems are executing to perform control and manufacturing activities.APM may provide these measures to different enterprise systems and can ensure better service quality or reduce costs by upgrading or changing the configuration or use of computing equipment in the computational fabric, such as by adding additional computational fabric computing equipment (nodes, servers, computers, processors, etc.), by reducing computational fabric equipment (nodes, servers, computers, processors, etc.), by modifying computational fabric equipment (such as using processors with higher processing speeds, larger memory, etc.), or by taking other actions in the computational fabric based on service quality metrics, if the service quality meets expectations (e.g., meets service quality metrics promised or guaranteed in a particular enterprise license).

[0206] APMs may also provide or implement various data analysis applications on various different enterprise systems to suggest changes to those systems that may improve their operation. Furthermore, APMs may aggregate data from different enterprises, analyze that data to detect trends, problems, etc., and then provide general guidance for particular enterprise systems based on that analysis. For example, APMs may use data analysis to compare the operation of control systems used for the same or similar products or manufacturing steps from the same or different enterprise systems to determine which systems or system configurations perform better or worse than each other, better or worse than an average or baseline system, etc. APMs may then use other data analyses to determine why particular systems are performing better or worse, for example, whether the differences are related to the presence of different equipment, different control routines, different interactions, or configuration setups of virtual control components or actual control system hardware. APMs may then generate general guidance or best actions for one or more enterprise systems based on knowledge determined in these analyses.

[0207] Furthermore, the architecture described herein allows for faster development and testing of components added to a control system because it allows control or other system containers or products to be developed and provided in a container or product registry for downloading and implementation by enterprise systems at the will and timing of the enterprise system or enterprise system manager. Feedback from the operation of these downloaded and implemented containers or products is also automatically provided back to developers from the enterprise's compute fabric, who can test, upgrade, and modify the containers or products as part of the development cycle. This architecture allows for or results in a more rapid development cycle because it provides for faster implementation of new features or products and provides automatic feedback regarding the operation of new or modified components. However, this development is still performed and implemented in a manner that allows each enterprise operator or manager to control when new containers or products are downloaded and implemented into their systems.

[0208] FIG. 7 illustrates an overall NGPCAS architecture 700 that includes multiple distinct enterprise systems 702 (Enterprise 1), 704 (Enterprise 2), ..., 706 (Enterprise n) connected to an architecture provider / manager (APM) 710. In particular, each of the enterprise systems 702, 704, 706 implements an NGPCAS, as described herein, that includes a computational fabric and plant hardware at one or more locations, i.e., physical locations, where gateway devices, I / O devices, and field devices are deployed to perform a manufacturing or factory automation process. As illustrated in the exemplary system of FIG. 7 , enterprise 702 includes a computational fabric 720 connected to two physical locations 722A and 722B, which may be plants, buildings, areas, or other physical locations where gateways, I / O, and field devices are deployed to perform a process, such as a factory automation or manufacturing process. Similarly, the computational fabric 720 of enterprise 702 includes multiple different sets of containers as described herein to implement control and related support features for equipment at locations 722A and 722B. Specifically, in the example of FIG. 7 , computational fabric 720 includes one or more sets of containers 726A that monitor and control physical equipment at location 722A and one or more sets of containers 726B that monitor and control equipment at location 722B. Of course, as described herein, containers 726A and 726B in computational fabric 720 can be set up in any desired manner and using any other desired configuration and need not necessarily be separated or grouped based on the physical locations they control. Furthermore, enterprise 702 may include one or more user interfaces 730 that connect to and interface with computational fabric 720 using one or more APIs 732 in computational fabric 720.The user interface 730 and API 732 operate as described herein to enable owners, operators, configurators, etc. of the enterprise 702 to perform configuration, monitoring, and control activities related to the physical location 722 using the container 726 in the manner previously described herein.

[0209] Similarly, as illustrated in FIG. 7 , enterprise 704 includes a compute fabric 740 connected to multiple physical locations 740, including already installed locations 740A-740C. Physical location 740D is illustrated with a dotted line to indicate that it may be added using the configuration applications and techniques described herein below. Of course, as illustrated in FIG. 7 , enterprise 704's compute fabric 740 includes a set of containers 750 that are installed and executed on the compute fabric 740 to monitor, control, and provide support services for equipment at physical locations 742. Furthermore, a user or operator associated with enterprise 704 may interface with compute fabric 740 via user interface 756 and API 758 to perform monitoring, configuration, and operational activities with respect to containers 750 in compute fabric 740, e.g., to visualize and control the operation of control systems executed or implemented by containers 750 to control equipment at physical locations 742. Of course, the owner, operator, administrator, etc. of enterprise 704 may interface with computational fabric 740 in any desired manner described herein to perform any configuration, control, or monitoring function for enterprise 704.

[0210] Further still, any other number of enterprises (illustrated in FIG. 7 by dots up to enterprise n 706) may each include a computational fabric 760 coupled to multiple different locations, physical locations 762A-762n, and may include a container or grouping of containers 770 for performing control and support activities for locations 762A-762n. Again, enterprise 706 may enable users to interface with computational fabric 760 using one or more user interfaces 772 and one or more APIs 774, as described herein.

[0211] 7, APM 710 is connected to each of the compute fabrics 720, 740, 760 of each of enterprises 702, 704, 706 via a direct secure communications connection 780. Communications connection 780 may be configured to operate with separate security in any manner described herein, such as using separate VPNs for each of the compute fabrics 720, 740, 760. Importantly, communications connection 780 provides APM 710 with information about the ongoing operation, configuration, and related information regarding each of the containers, modules, programs, etc. within each of the compute fabrics 720, 740, and 760. Thus, in this manner, APM 710 has a direct and ongoing connection to the computational fabric of each of enterprises 702, 704, and 706 and can use this connection to spin up, allocate, remove, reduce, or modify computer resources within each of the computational fabrics 720, 740, 760 of each of enterprise systems 702, 704, 706, respectively. APM 710 can use the direct and secure connection 780 to license, provision, configure, or otherwise establish sufficient computer equipment in the computational fabric of each of enterprise systems 702, 704, 706 based on licenses purchased by enterprise systems 702, 704, 706. In some cases, APM 710 can license or use computer equipment in the cloud, for example, as provided by a third-party cloud computing provider such as Microsoft Azure. In other cases, the APM 710 may have its own computer resources at one or more locations owned or operated by the APM 710 that the APM 710 uses to provide computing resources to the computational fabrics 720, 740, 760 of the enterprises 702, 704, 706. In still other cases, the enterprises 702, 704, 706 may provide some or all of the computer resources used in the computational fabrics 702, 704, 706 and allow these resources to be managed by the APM 710.For example, area 779 within enterprise 704's computational fabric 740 marked with a dotted line indicates that elements executing in this portion of computational fabric 740 execute on computer hardware owned by, located at, or provided by enterprise 704, which may be, for example, computer hardware at one of locations 740A-740D or at a different facility associated with enterprise 704.

[0212] As will be appreciated, APM 710 has a direct and secure connection to the operating networks and computational fabrics of each of the enterprises 702, 704, 706, etc. that it manages or supports. Thus, APM 710 may simultaneously control the allocation of computer facilities or resources to each of the computational fabrics of any of the supported enterprises. Additionally, APM 710 may store and execute software or data analysis module 782 that analyzes operational data, such as metadata, from each of the computational fabrics 720, 740, 760 to calculate or determine various service quality measurements or statistics for each of the computational fabrics 720, 740, and 760 of the enterprises 702, 704, and 706. In particular, data analysis module 782 may determine communication latency, CPU usage, and other computing operation statistics that illustrate or define the quality of service being provided or obtained within any of computational fabrics 720, 740, and 760 by the computer hardware used within computational fabrics 720, 740, 760 (regardless of who provides the computer hardware or where the computer hardware is physically located). Such data analysis or service quality measurements may be used by APM 710 to improve or modify the quality of service being provided to an enterprise or portion of an enterprise, for example, to modify the underlying configuration of the computational fabric provided or managed by APM 710 to meet expected, guaranteed, or authorized quality standards, such as those mandated by contracts between APM 710 and the various enterprise owners of enterprises 702, 704, and 706. APM 710 may make these changes by making configuration changes within the computer hardware of compute fabrics 720, 740, 760 over secure connection 780, and / or may interface with any third-party providers of computer hardware or computing capabilities used in compute fabrics 720, 740, and 760, such as cloud computing providers like Microsoft Azure.Of course, APM 710 can change the configuration, quantity, identity, or any other component of the computing equipment used at or licensed from third parties to provide computational fabrics 720, 740, 760 in any desired manner. In this manner, APM 710 has ongoing control over the quality of service and configuration of the computing equipment provided or licensed by APM 710 and provided to enterprises 702, 704, 706, which enables APM 710 to maintain appropriate or expected quality of service for the control systems used or implemented by those enterprises.

[0213] Similarly, APM 710 may interface directly with user interfaces associated with different enterprises 702, 704, 706, such as user interfaces 730, 756, 772, to enable enterprise managers at user interfaces 730, 756, 772 to obtain additional licenses for additional compute fabric equipment, spin up additional compute fabric equipment, and provide additional or new software products or containers (developed by APM 710 or third-party developers) to the enterprise owners or managers.

[0214] In any event, APM 710 can analyze the data it receives from the compute fabrics 720, 740, 760 in any desired manner and at any grouping level. For example, as illustrated by chart 790 in FIG. 7 , APM 710 can obtain and accumulate data from various different compute fabrics 720, 740, 760 of enterprises 702, 704, and 706 and analyze the data from all of these enterprises together to obtain an overall measure of the service quality being provided by APM 710. This combined enterprise data is illustrated in chart 790 by block 792. Additionally, APM 710 can analyze the data from each compute fabric 720, 740, 760 separately to provide statistics or service quality measures for each enterprise and can communicate with each enterprise separately to provide each enterprise with a service quality measure or other statistical measure associated with the enterprise as a whole. Such measurements or data are illustrated by charts 794A, 794B, and 794C for enterprises 702, 704, and 706, respectively. Still further, APM 710 may perform or determine analytical measurements or other analyses (such as service quality measurements) by physical location of a particular enterprise (as illustrated by chart 796 in FIG. 7 ), by control system, by set of containers, by container, by container, or in any other manner, or based on any other grouping of components within or associated with containers, modules, programs, control systems, etc. executing in the compute fabrics 720, 740, 760. Of course, APM 710 may perform or perform analyses in any other desired manner, or perform analyses associated with any other grouping of plant hardware, software, containers, compute fabric hardware, etc. If desired, an enterprise owner may subscribe to or be provided with different reports according to various predetermined or desired groupings (at any level) of hardware and / or software elements within the compute fabric for that enterprise.

[0215] APM710 may additionally perform other types of analyses on any grouping of data associated with one or more of the enterprises to which APM710 is connected and may provide recommendations to the enterprise regarding potential changes to be made within the enterprise to improve performance, quality, etc. within the enterprise or some component of the enterprise (such as a physical location, a set of control systems, a control loop, a group of control loops with similar functionality, etc.). For example, APM710 may analyze the operation of one or more groupings of hardware, software, control systems, control loops, containers, etc. implemented within one or more enterprises to determine changes that may be made to improve control within the enterprise. As a particular example, APM710 may analyze data related to the operation of a control loop or set of control loops within the enterprise, such as a control loop used to control particular hardware at one or more plant locations, and analyze timing signals, process variable measurements, response times, control loop statistics, etc. to determine whether one or more changes to the analyzed component may provide better performance in some manner. APM710 may use the results of the analysis to recommend various hardware and / or software configurations to be made, operations that may be performed, actions that may be taken (such as implementing corrective measures), etc. In some cases, APM710 may suggest new or different types of control or control loop algorithms, new tuning of process control devices or control loops, additional or different control algorithms that may be useful, different equipment that may be used, different control hardware or software configurations such as pinning or changing the allocation of containers or groups of containers running in the compute fabric, etc. Again, the analysis may be performed at any level, such as the enterprise level, the physical plant or location level, the control loop level, the computer device level, etc. Of course, APM710 may perform other types of data analysis using data from multiple different enterprises or control systems, from a single enterprise, from a subset of components within an enterprise, etc.In some cases, APM 710 (which has access to data from multiple different companies) may look for commonalities or differences in performance, looking for commonalities or differences between operation at different locations or on different hardware for the same company, or between operation at different locations or on hardware for different companies. APM 710 may then perform further data analysis to determine the source or cause of those differences, including differences that cause control systems (control loops, controlled plants, etc.) to perform better or worse than each other, or better or worse than a baseline or average. APM 710 may then provide the results of the analysis to the company to make changes. In particular, APM 710 may return a report or analysis to the company to enable the company to consider making changes to the control systems implemented by the company. In some cases, APM 710 may provide one or more products or containers to be used by the company to implement the proposed changes.

[0216] 7 with respect to enterprise 704, each enterprise may include a configuration system 800 having one or more configuration databases (which may be one or more different computer databases or memories) that store components for the enterprise or portions of the enterprise, and one or more configuration applications that enable users to view, modify, and manipulate the configuration databases to make and implement configuration changes for the enterprise, including configuration changes both in elements running in the enterprise's computational fabric and in hardware in or associated with one or more physical locations of the enterprise. The configuration database of configuration system 800 may, for example, store a library of elements (e.g., containers, modules, applications, products, etc.) used in the enterprise and may store information defining the identity and configuration of each element, group of elements, container, control system, etc. currently operating in the computational fabric or devices within the enterprise's physical locations. Further, the configuration application may enable an enterprise owner or manager to view and make changes to the configuration of any of the elements of the enterprise, including making changes to the control system, adding or removing logic or physical equipment or components (and even physical locations) to or from enterprise systems, changing the location or pinning of various different resources or components (e.g., containers) within the compute fabric, adding new field devices, I / O devices, etc. Additionally, the configuration system application, upon command by a user, may implement configuration changes by downloading or modifying logic or software elements (e.g., containers) within devices within the compute fabric or physical locations according to the user's changes.Because control elements within the computational fabric are generally not tied to specific computer hardware within the computational fabric, configuration system 800 can easily modify, remove, add, etc. to elements actually running within the computational fabric, without the user having to specify exactly where those components should be located. The user can specify the logical configuration changes to be made and, with the push of a button, implement those changes on the actual hardware currently running within the computational fabric. The underlying computational fabric management system then targets (or allocates) the computer hardware on which to implement the modified or new components, making the changes seamless to the user. While configuration system 800 is illustrated as being stored and executed within an enterprise's computational fabric, one or more components of configuration system 800 can be located within computer hardware at one or more of the enterprise's physical locations, within off-site computational fabric resources, spread or shared between computational fabrics at one or more physical locations and off-site or licensed computational fabric hardware, stored on dedicated machines within the computational fabric, or at one or more of the physical locations, or in any other manner.

[0217] 8A illustrates the operation of the configuration system 800 in an enterprise in more detail, illustrating the manner in which an enterprise owner, operator, or other user can use the configuration system 800 to make control and configuration changes to the enterprise or any portion thereof in a quick and easy-to-use manner. Indeed, in some cases, configuration changes may be provided essentially via a one-button push mechanism that can be used to install additional software or new software components or to upgrade software within the enterprise's compute fabric. More specifically, FIG. 8A illustrates the configuration system 800 that may be used in one of the enterprises, such as enterprise 704 of FIG. 7, to add, change, or otherwise alter the configuration and operation of one or more process control system elements within or associated with the enterprise in an easy-to-implement manner.

[0218] As can be seen, FIG. 8A illustrates a configuration system 800 for an enterprise communicatively coupled to an APM 805 and a product / container registry 807. Generally speaking, the enterprise configuration system 800 is located at and executed at the enterprise to which it belongs, such as within the enterprise's compute fabric. However, part or all of the configuration system 800 may be stored at and executed on one or more physical locations of the enterprise, one or more dedicated hardware locations for the enterprise outside the compute fabric, or hardware at any other location (which may or may not be part of the enterprise compute fabric). Importantly, however, the enterprise configuration system 800 is connected to or integrated with the enterprise's compute fabric such that changes can be made directly to elements within the enterprise's compute fabric using the management structure of the compute fabric. As illustrated in FIG. 8A , the configuration system 800 includes a configuration database 801, one or more configuration applications 802, and a configuration execution engine 804 communicatively coupled together. Of course, the configuration database 801 stores the enterprise's configuration information as currently configured. The configuration database may include one or more physical databases that host data and relationships, e.g., configurations of control modules and the relationships between them. Importantly, the configuration application 802 may include one or more user interface applications that generate one or more user interfaces, such as the user interface 822 illustrated in more detail in FIG. 8B , that enable a user, such as a configuration engineer at an enterprise, to take various actions regarding modifications or upgrades to the control system or any of its elements or components. As will be appreciated, the user interface 822 may be displayed on any computer at the enterprise or provided to off-site computers associated with the enterprise via an API described above but not shown in FIG. 8A . Furthermore, the configuration engine 804 interfaces with runtime systems (e.g., the orchestrator and associated applications described herein) to implement configuration changes within the enterprise, such as within the enterprise's compute fabric.

[0219] As illustrated in FIG. 8A , configuration system 800 may be connected to APM 805 via communication connections, such as those shown and described with respect to FIG. 7 , and may coordinate with APM 805 to make certain types of configuration changes, such as licensing new software or hardware components in the compute fabric managed or licensed from APM or a third party, or reducing, increasing, or changing the configuration of hardware in the compute fabric provided by APM (or a third-party hardware provider). Furthermore, configuration system 800 may be connected to product or container registry 807 from which it may obtain new components, such as new containers, products, upgrades, etc. Configuration system 800 may access a product registry (located outside the enterprise's compute fabric) using any of the security features described above. Generally speaking, configuration system 800 includes components that interact with each other and with APM 805 and product / container registry 807 to enable users to specify and implement configuration changes in an enterprise. These configuration changes may include adding new physical locations, adding new or changing computer or field device hardware (e.g., field devices, I / O devices, gateway devices, etc.) to new or existing physical locations, adding, removing, or changing logic components (e.g., containers, control modules, control routines, monitoring routines, etc.) within the enterprise's compute fabric, changing pinned or other specified relationships between logic components within the compute fabric and / or between logic components and particular compute fabric hardware, etc.

[0220] As an example, one or more of the configuration applications 802 of the configuration system 800 may be used to view the current configuration of various different elements of the enterprise, including both hardware and software elements. Additionally, one or more of the configuration applications 802 may be used to enable a user to make changes to the configuration of the enterprise, such as adding new hardware and / or software elements, modifying one or more hardware or software elements, removing one or more hardware or software elements, changing the way one or more software elements, such as containers, are pinned to other software or hardware elements, adding hardware in a new physical location or in one or more physical locations, modifying the configuration of elements in one or more physical locations, specifying or modifying the configuration of computer hardware in or associated with the computational fabric of the enterprise or portion of the enterprise, and / or implementing any other desired configuration change.

[0221] 8B , user interface 822 may provide a configuration display screen that allows a user to view and make changes to the configuration of elements within the enterprise. In this example, display screen 822 includes a configuration hierarchy section 834 and a diagram or programming section 836 that may be used by a configuration engineer or other user to graphically illustrate one or more components and / or to allow the configuration engineer (or other authorized user) to graphically program or make changes to the enterprise configuration at any level. A user may make changes to the configuration at, for example, the enterprise level (i.e., affecting the entire enterprise), at a sub-enterprise level such as one of the enterprise's physical locations, at any group of components within the enterprise's compute fabric, etc.

[0222] As illustrated in FIG. 8B , hierarchy section 834 may include a hierarchical view illustrating various different components of the enterprise at various levels or sublevels (or any other grouping of components) of the enterprise, illustrating the enterprise's components as they currently exist in an organized and easily locatable manner. For example, enterprise hierarchy 834 may include library section 840, which includes storage of copies of components, such as control modules, control routines, function blocks, containers, and / or any other components stored in a configuration database as library elements. These library elements may be copies or generic versions (i.e., uninstantiated versions) of control elements that exist within an enterprise system, such as one of the physical locations or within the enterprise's compute fabric. Additionally, hierarchy section 834 may include configuration database section 841 for accessing the enterprise's actual configuration database and physical network section 842, which includes information about each of the decommissioned nodes or locations and each of the enterprise's currently commissioned physical locations. As illustrated with respect to physical location 1, each physical location may include configuration and identification information regarding gateways, I / O devices, field devices, communication networks, etc. at the physical location. Such elements may include, for example, I / O devices and gateway devices for each physical location, field devices and communication devices disposed at each physical location, databases, communication structures, etc. Still further, other physical I / O networks, such as wireless networks, may be listed under section 844. Additionally, hierarchy section 834 may include a hierarchy of installed components, such as components associated with each physical location, each of a set of control routines or control modules, or any other control structure, etc.

[0223] Further, tier 834 may include indications of control logic or control elements (e.g., containers) within the compute fabric under compute fabric section 845. Elements within the compute fabric may include, for example, logic or virtual controllers, control modules, containers, etc., and may indicate how these elements are pinned or otherwise associated or grouped (e.g., assigned) with one another during runtime. Control elements may also include or exemplify digital twins associated with iOS devices or field devices in various locations and may include any grouping or configured grouping of containers or other elements. Similarly, other groupings of containers or control elements within the compute fabric may be enumerated, such as assigned I / O and third-party containers. Similarly, configuration tier 834 may exemplify support elements tied to and operating within the enterprise, such as the enterprise's compute fabric, including one or more batch or continuous historians, batch executives, recipes, advanced control elements, data analysis programs or software (e.g., artificial intelligence (AI) programs or algorithms), monitoring software, etc. Of course, it will be appreciated that a user can drill down into each of the sections of the hierarchy 834 to see or access more information and details about those elements and the sub-elements listed therein.

[0224] The diagramming or programming area 836 of the display 822 may be used to add, change, delete, reconfigure, program, and / or otherwise create components installed in the enterprise, such as within the enterprise's computing fabric or within devices at one or more of the enterprise's physical locations. In particular, a user may select and view one or more elements in the hierarchy 834 and place these elements (or copies thereof) in the programming area 836. The user may then make changes to these elements to graphically indicate the changes to the configuration of these elements. In other cases, a user may add or copy library elements in the hierarchy section 834 to the programming area 836 and then edit those elements to create new components for control systems within the enterprise. In still other cases, a user may download or obtain one or more new components from an external source or database, such as from the product / container registry 807. Of course, the configuration application 802 may enable a user to add, change, delete, or otherwise modify components in any other manner as well.

[0225] As a further example, user interface 822 may provide a pop-up window 850 that may display various actions that may be taken by a configuration engineer or user in diagram or programming area 836 to perform configuration activities. In particular, window 850 may include a Duplicate button 852, an Add button 854, an Upgrade button 856, an Assign button 858, an Import New Hardware button 860, a Modify button 862, a Deploy button 864, an Implement button 866, etc. Although window 850 in FIG. 8B illustrates these various specific buttons associated with specific configuration actions to be taken, window 850 may provide or list other configuration actions that may be enabled via pop-up window 850. Furthermore, display 822 may enable these or other configuration actions through other types of input or commands, such as using drop-down menus, radial buttons, new screens, drag-and-drop actions, etc.

[0226] In any event, a user, such as an enterprise configuration engineer, can access or select some of the elements in enterprise hierarchy 834, such as library elements or actual components, and display or copy those elements in configuration screen area 836, e.g., using duplicate button 852. The user or configuration engineer can then edit these elements, which may be, for example, control modules and entire control systems, containers, groups of containers, etc., and, using, for example, assign feature 858, assign these edited or new elements to the compute fabric, to one or more new or existing devices in already installed physical locations, in one or more new physical locations, to one or more virtual controllers in the compute fabric, etc. Of course, the configuration engineer can bind or assign these elements to devices (e.g., field devices) or other hardware in the enterprise. As another example, a user can use configuration programming area 836 and / or library 834 to assign or pin control elements or components to each other, to specific hardware, to the same hardware, or to the same virtual element (e.g., controller) in the enterprise's compute fabric. Of course, the user can drag and drop new or modified components within the hierarchy section 834 to assign containers such as control modules to specific virtual or physical elements.

[0227] In one example, a set of control routines or modules 880 and containers 882 are illustrated as being located in programming area 836. A user can then select particular elements within the control loops 880 or containers 882 and make changes to them as needed (via pop-up windows, drop-down menus, etc.) to create different control loops for new elements or new hardware, change the configuration of existing control loops, change where one or more of the control loops 880 or containers 882 are assigned within the computational fabric, etc. Once edits are complete, the user can use one of the buttons in window 850 to assign or deploy the components 880, 882 or implement them within the computational fabric.

[0228] Furthermore, as illustrated in FIG. 8A , a user at user interface 822 may have access to product / container registry 807, which may contain new container elements, control system data analytics, control elements, or other products or modules that may be provided by architecture providers / managers or third-party developers for use in downloading to an enterprise's compute fabric or other hardware. In some cases, a user may use user interface 822 to obtain from product registry 807 one or more containers or products or other software provided or used in the enterprise, such as the enterprise's compute fabric, download these elements, and install them using configuration screen 822. In particular, such containers or products may be provided as upgrades or modifications to other containers or products already in use or already installed on the compute fabric or hardware at the enterprise's physical location. In this case, the new elements may be deployed to the compute fabric using deploy button 864 (or by dragging and dropping these elements to the desired location in hierarchy 834). In some cases, the user must subscribe to or obtain licenses for these products or containers, in which case the user may interface with APM 805 (and possibly a third party) to obtain the licenses. Of course, upon pressing the deploy button, the system may check to ensure that the updated or new elements are available for deployment within the enterprise system, and if so, the configuration engine 804 of the configuration system 800 may deploy the new elements in a manner that is seamless to the user. Because the computer hardware of the computational fabric on which the elements are deployed is inherently separate from, or not specifically tied to, these elements in a one-to-one manner, the configuration engine 804 of the configuration system 800 may upload these new or changed elements to the computational fabric without input from the user regarding where to run these elements.

[0229] As another example, a user may want to add a new physical location to the enterprise. In this case, the user can create a new location within the configuration system by selecting the New Hardware button 860 and filling in various fields in a pop-up window. Here, the user can specify one or more hardware IDs for the new hardware, such as a gateway ID, and the configuration system or engine 804 can access that gateway and then perform automatic hardware discovery at the gateway. The configuration system can automatically populate the hardware specifications for the new physical location within the configuration system 800. In some cases, the user can select the Duplicate button 852 to duplicate hardware from another physical location for the new physical location, where the new physical location is designed to implement processes using the same basic hardware or field devices as the existing physical location. The addition of a new physical location is illustrated by dotted line 740D in FIG. 7, where the new location illustrated by dotted line 740D has been added to include all new hardware or new hardware with a gateway connecting to the enterprise's compute fabric. In this case, the user can use buttons 852, 854 to additionally copy or duplicate (or create new) control routines, modules, or containers for the new physical location, and use button 858 to assign these new components to new hardware in the new physical location. When finished, the user can use deploy button 864 to deploy the new routines or containers within the computational fabric. If desired, a new node can be added (e.g., licensed) to the computational fabric to run the new containers in the new physical location, although this is not strictly required. This new node is illustrated by dotted line portion 788 of enterprise 704's computational fabric 740 in FIG. 7.In any event, after modifying or copying hardware and / or control containers and other information from one of the other locations to the configuration programming screen, or after otherwise creating control routines and / or containers for new hardware, the user can assign those elements to the new hardware or physical location to which they belong using the assign button 858. The user can then use the deploy button 864 to run the configuration engine 804 to deploy those elements to the compute fabric in a configured manner to control the new hardware in the new physical location, which allows the process control system to begin operating and functioning in the new location 740D.

[0230] In another example, a user may simply wish to add additional hardware to one of already established locations, such as location 740C in FIG. 7 , as illustrated by the dotted box within location 740C. In this case, the user can also provide a new set of control routines or containers or modify the current configuration of that new hardware using application 802 and screen 822 in FIG. 8B . In other cases, the user can do so by starting with add button 854 to add a new component, such as a container, control loop, etc., for the new hardware. Still further, a user may, in another example, wish to upgrade an existing component, such as a container or product, with new functionality provided by an APM or third-party provider. In this case, the user may obtain a copy of the upgraded version of the container or control loop with the new features to be implemented from the product registry or container registry 807. The user can then place these new or upgraded elements in the configuration locations identified in configuration screen 822 and identify the elements they replace in the already installed compute fabric. The user can then press the upgrade button 856 to instruct the configuration engine 804 to upgrade that element in the computational fabric with the new component.

[0231] Furthermore, a user can use other buttons, such as change button 862, to reallocate or change the assignment of one or more elements within the computer fabric to assign those elements to specific hardware, a specific location, etc. For example, as illustrated in FIG. 7, a user may desire to assign components to run on compute fabric hardware physically located at one of the enterprise's physical locations instead of running or executing on licensed compute fabric hardware. This configuration is illustrated by dotted line 779 in the compute fabric associated with or owned by the actual enterprise system. Again, the user can use assign button 858 and then select the compute fabric hardware on which the selected components will run, thereby assigning operation of tho...

Claims

1. 1. A process control or automation system comprising: a physical device that performs a physical function utilized in the control of an industrial or automation process provided by the enterprise; an instantiated Micro-Encapsulated Execution Environment (MEEE) communicatively connected to the physical device and configured to at least one of send information to or receive information from the physical device, thereby controlling at least a portion of the industrial or automation process.

2. 10. The process control or automation system of claim 1, wherein the physical device and the instantiated MEEE are communicatively connected via a secure point-to-point (PTP) or peer-to-peer (P2P) connection.

3. 3. A process control or automation system according to claim 2, wherein the secure PTP or P2P connection is a secure encrypted PTP or P2P connection.

4. 4. A process control or automation system according to claim 2 or 3, wherein the instantiated MEEE is an endpoint of the secure PTP or P2P connection.

5. A process control or automation system according to any one of claims 2 to 4, wherein the secure PTP or P2P connection comprises a virtual private network (VPN).

6. 6. The process control or automation system of claim 5, wherein the VPN is a point-to-point (PTP) VPN that exclusively serves only the physical device and the instantiated MEEE.

7. 6. The process control or automation system of claim 5, wherein the physical devices and the instantiated MEEEs are communicatively connected via multiple VPNs.

8. 8. The process control or automation system of claim 7, wherein at least two of the multiple VPNs are nested VPNs.

9. The process control system according to any one of claims 7 to 9, wherein two or more VPNs of the multiple VPNs are mutually exclusive VPNs.

10. A process control or automation system according to any one of claims 2 to 9, further comprising a gateway communicatively connecting said physical devices and said instantiated MEEEs.

11. 11. The process control or automation system of claim 10, wherein the gateway and the physical device are located at a first physical location or site, and the instantiated MEEE executes on a hardware platform located at a second physical location or site.

12. 12. A process control or automation system according to claim 10 or 11, wherein the instantiated MEEE is a first endpoint of the secure PTP or P2P connection and the gateway is a second endpoint of the secure PTP or P2P connection.

13. the process control or automation system further comprising I / O hardware communicatively disposed between the physical device and the instantiated MEEE; the physical device is physically connected to a physical I / O interface included in the I / O hardware; the combination of the physical device and the physical I / O interface is a uniquely identified physical component in the process control or automation system; the instantiated MEEE is a first endpoint of the secure PTP or P2P connection; A process control or automation system according to any one of claims 2 to 11, wherein the physical component is a second endpoint of the secure PTP or P2P connection.

14. 14. A process control or automation system according to any one of claims 2 to 13, wherein the physical device and the instantiated MEEE are communicatively connected via the secure PTP or P2P connection and via at least one of another secure encrypted PTP or P2P connection, a secure point-to-multipoint (PTM) connection, or a secure multipoint-to-multipoint (MTM) connection.

15. the process control or automation system authenticates and / or authorizes the physical devices to communicate over the secure PTP or P2P connection; or 15. A process control or automation system as claimed in any one of claims 2 to 14, wherein the process control or automation system at least one of authenticates and / or authorizes the instantiated MEEEs to communicate over the secure PTP or P2P connection.

16. A process control or automation system according to any one of claims 2 to 15, wherein the physical device and the instantiated MEEE communicate via a session established over the secure PTP or P2P connection.

17. 17. The process control or automation system of claim 2, wherein the instantiated MEEE is included in a plurality of instantiated MEEEs of the process control or automation system, and each instantiated MEEE of the plurality of instantiated MEEEs is communicatively coupled to at least one of a respective physical device, a respective intervening device communicatively disposed between the respective physical device and the respective instantiated MEEE, or another instantiated MEEE via a respective secure PTP or P2P connection.

18. 18. The process control or automation system of claim 17, wherein the respective secure encrypted PTP or P2P connections are respective virtual private networks (VPNs).

19. 19. A process control or automation system according to claim 17 or 18, wherein the plurality of instantiated MEEEs and the plurality of secure PTP or P2P connections is a mesh of MEEEs of the process control or automation system.

20. 20. The process control or automation system of claim 19, wherein at least one of the MEEEs of the process control system or automation mesh is dynamically reassigned and migrated to another node, another physical location, or another geographic location by the process control or automation system during runtime operation while the process control or automation system is executing at runtime to control the industrial or automation process.

21. 21. The process control or automation system of any one of claims 17 to 20, wherein the process control or automation system dynamically distributes the plurality of instantiated MEEEs across a plurality of nodes of a hardware platform while the process control or automation system executes at run-time to control the industrial or automation process, and the process control or automation system subsequently re-distributes the plurality of instantiated MEEEs across the plurality of nodes while the process control or automation system continues to execute at run-time to control the industrial or automation process.

22. 22. A process control or automation system according to any preceding claim, wherein the process control or automation system authenticates at least one of an identifier of the physical device or an identifier of the instantiated MEEE, and the transfer of information between the physical device and the instantiated MEEE is based on the authentication.

23. 23. The process control or automation system of claim 22, wherein the process control or automation system authenticates both the identifier of the physical device and the identifier of the instantiated MEEE.

24. the process control or automation system authorizes the physical device to at least one of send and receive communications within the process control or automation system; or 24. The process control or automation system of any one of claims 1 to 23, wherein the process control or automation system at least one of authorizes the instantiated MEEE to at least one of send and receive communications within the process control or automation system.

25. the process control or automation system authorizes the physical device to at least one of send and receive communications with a first set of nodes of the process control or automation system and does not authorize the physical device to at least one of send and receive communications with a second set of nodes of the process control or automation system; the first set of nodes includes the instantiated MEEE or an intervening device communicatively disposed between the physical device and the instantiated MEEE; 25. The process control or automation system of claim 24, wherein the second set of nodes includes at least one other instantiated MEEE.

26. the process control or automation system authorizes the instantiated MEEE to at least one of send and receive communications with a third set of nodes of the process control or automation system and does not authorize the instantiated MEEE to at least one of send and receive communications with a fourth set of nodes of the process control or automation system; the third set of nodes includes the physical device or an intervening node communicatively disposed between the instantiated MEEE and the physical device; 26. A process control or automation system according to claim 24 or 25, wherein the fourth set of nodes comprises at least one of another instantiated MEEE or another physical device.

27. the physical device and the instantiated MEEE are communicatively connected via a secure point-to-point (PTP) or peer-to-peer (P2P) connection; the process control or automation system authorizes the physical device, or an intermediary device communicatively disposed between the physical device and the instantiated MEEE, to communicate via the secure PTP or P2P connection; or 27. A process control or automation system as claimed in any preceding claim, wherein the process control or automation system authorises the instantiated MEEEs to communicate over the secure PTP or P2P connection.

28. the instantiated MEEE is included in a plurality of instantiated MEEEs of the process control or automation system; the process control or automation system authenticating a respective identifier of each instantiated MEEE of the plurality of instantiated MEEEs; 28. A process control or automation system as described in any one of claims 1 to 27, wherein based on the authentication, the process control or automation system authorizes each instantiated MEEE to communicate with at least one of a respective physical device, a respective intervening device communicatively disposed between the respective physical device and the respective instantiated MEEE, or a respective other instantiated MEEE.

29. the physical device is included in a plurality of physical devices; the process control or automation system authenticating at least one of a respective identifier of each physical device of the plurality of physical devices or a respective identifier of each intervening device communicatively disposed between each physical device and a respective receiving device; A process control or automation system according to any preceding claim, wherein based on the authentication, the process control or automation system authorises each of the physical devices to communicate with the respective recipient device.

30. 30. A process control or automation system according to any preceding claim, wherein the physical device is included in a plurality of physical devices, each physical device of the plurality of physical devices being communicatively connected to a respective instantiated MEEE configured to at least one of send signals to or receive signals from the respective physical device.

31. 31. The process control or automation system of claim 30, wherein a first portion of the plurality of physical devices is disposed at a first geographic location, a second portion of the plurality of physical devices is disposed at a second geographic location, and the plurality of instantiated MEEEs execute on hardware platforms disposed at one or more other geographic locations.

32. 32. The process control automation system of claim 31 , wherein the first portion of the plurality of physical devices is communicatively connected to the one or more other geographic locations via a first gateway disposed at the first geographic location, and the second portion of the plurality of physical devices is communicatively connected to the one or more other geographic locations via a second gateway disposed at the second geographic location.

33. 33. A process control or automation system according to any preceding claim, wherein the physical device is a field device configured to perform a physical function in response to control signals generated by the instantiated MEEE or by another instantiated MEEE.

34. 34. A process control or automation system as claimed in any preceding claim, wherein the instantiated MEEE is a virtual process controller or virtual safety controller that operates on received data to generate control signals to which the physical devices are operatively responsive.

35. 35. A process control or automation system as described in any one of claims 1 to 34, wherein the instantiated MEEE is a virtual process controller or a virtual safety controller that operates on the information received from the physical device and thereby generates control signals to which the physical device or another physical device operatively responds.

36. 36. The process control or automation system of any one of claims 1 to 35, wherein the instantiated MEEE is included in a plurality of instantiated MEEEs, the plurality of instantiated MEEEs including at least one of: a virtual process controller; a virtual safety controller; a virtual safety logic solver; a virtual I / O card, device, or node; a virtual wireless device; a virtual Ethernet device; a virtual operator workstation; a virtual user interface device; a virtual tool; a virtual gateway; a virtual electronic marshalling cabinet or system; a virtualization of another type of physical device or component disposed within the physical environment of an industrial process plant; a control service; a service that provides a subsystem of the process control or automation system; or a service that provides business logic of the process control or automation system.

37. 37. The process control or automation system of claim 36, wherein the business logic of the process control or automation system includes at least one of a monitoring application or service, an operational application or service, a diagnostic application or service, a dashboard application or service, a user interface application or service, an analytics application or service, a safety routine application or service, a reporting application or service, a historizing application or service, a configuration application or service, a simulation application or service, a process control resource and / or resource management service, an automation resource and / or resource management service, an external communication application or service, an alarm application or service, a licensing application or service, or a third party application or service.

38. 38. A process control or automation system according to any preceding claim, wherein the instantiated MEEE is included in a plurality of instantiated MEEEs, the plurality of instantiated MEEEs including a packet router or switch service.

39. 39. The process control system of claim 1, wherein the instantiated MEEE is included in a plurality of instantiated MEEEs, and the plurality of instantiated MEEEs includes at least one of a software-defined compute service, a software-defined storage service, or a software-defined networking service.

40. 40. The process control system of claim 1, wherein the instantiated MEEE is included in a plurality of instantiated MEEEs, and the plurality of instantiated MEEEs include at least one of a service lifecycle management service, a discovery service, a security service, an encryption service, a certificate authority subsystem service, a key management service, an authentication service, a time synchronization service, a resource and / or resource group management service, a service location service, or a console support service.

41. 41. The process control system of claim 1, wherein the instantiated MEEE is included in a plurality of instantiated MEEEs, the plurality of instantiated MEEEs including function blocks or other types of function blocks utilized in executing control modules or routines.

42. 42. A process control or automation system according to any preceding claim, wherein the instantiated MEEE is an instantiation of an encapsulated software component configured by the process control or automation system.

43. 43. The process control or automation system of claim 42, wherein the encapsulated software component is a software container, a software agent, or bare metal software.

44. 44. The process control or automation system of claim 42 or 43, wherein the process control or automation system configures the encapsulated software components based on a configuration database of the process control or automation system.

45. 45. The process control or automation system of any one of claims 42 to 44, wherein the process control or automation system at least one of creates the encapsulated software component, configures the encapsulated software component, or instantiates the configured encapsulated software component in response to a condition detected by the process control or automation system.

46. a plurality of physical devices that perform respective physical functions for controlling the industrial or automation process, the plurality of physical devices being distributed across multiple physical locations or sites, and the physical device being included in the plurality of physical devices; 46. ​​The process control or automation system of claim 1, further comprising: a computational fabric executing on a hardware platform distributed across one or more physical locations or sites, at least one of the one or more physical locations or sites being excluded from the multiple physical locations or sites in which the plurality of physical devices are distributed, the computational fabric including a plurality of instantiated MEEEs including the instantiated MEEE.

47. 47. The process control or automation system of claim 46, wherein the plurality of physical devices includes two or more field devices.

48. 48. A process control or automation system according to claim 46 or 47, wherein the multiple physical locations or sites corresponding to the plurality of physical devices are distributed across multiple geographic regions.

49. 49. A process control or automation system as described in any one of claims 46 to 48, wherein the one or more physical locations or sites corresponding to the plurality of instantiated MEEEs include a plurality of physical locations or sites distributed across a plurality of geographic regions.

50. 50. A process control or automation system as described in any one of claims 46 to 49, wherein the multiple physical locations or sites corresponding to the plurality of physical devices and the one or more physical locations or sites corresponding to the plurality of instantiated MEEEs are mutually exclusive sets of physical locations or sites.

51. 50. The process control or automation system of any one of claims 46 to 49, wherein each physical device of the plurality of physical devices and each instantiated MEEE of the plurality of instantiated MEEEs is identified within the process control system by a respective unique identifier.

52. 52. The process control or automation system of claim 51, wherein the process control or automation system authenticates and / or authorizes each unique identifier of a particular physical device or instantiated MEEE before granting permission to the particular physical device or instantiated MEEE to communicate within the process control or automation system.

53. the process control or automation system comprising: authenticating and / or authorizing the respective unique identifier of each physical device of the plurality of physical devices before authorizing each physical device to communicate within the process control or automation system; 53. The process control or automation system of claim 52, wherein the respective unique identifier of each instantiated MEEE of the plurality of instantiated MEEEs is authenticated and / or authorized before granting permission to each instantiated MEEE to communicate within the process control or automation system.

54. 54. A process control or automation system according to any preceding claim, further comprising a set of exposed application programming interfaces (APIs) via which users communicate with the process control or automation system.

55. 55. The process control or automation system of claim 54, wherein the set of exposed APIs is the only mechanism provided by the process control or automation system for any user to communicate with the process control or automation system.

56. 56. A process control or automation system as described in claim 54 or 55, wherein different subsets of the set of exposed APIs are utilized by the user to communicate with different instantiated MEEEs and / or different types of instantiated MEEEs of the process control or automation system.

57. 57. A process control or automation system according to any one of claims 54 to 56, wherein the user comprises at least one of a person, a user interface operated by the person, an external application, or a third party application.

58. 58. A process control or automation system according to any one of claims 54 to 57, wherein the process control or automation system authenticates and / or authorizes the identity of a user before granting the user permission to communicate with the process control or automation system.

59. 59. A process control or automation system as claimed in any one of claims 54 to 58, wherein communications between a particular user and the process control or automation system are delivered over a particular secure point-to-point (PTP) or peer-to-peer (P2P) connection.

60. 60. A process control or automation system according to claim 59, wherein the particular secure PTP or P2P connection is a particular secure encrypted PTP or P2P connection.

61. 61. A process control or automation system according to claim 59 or 60, wherein the particular secure PTP or P2P connection comprises a virtual private network (VPN).

62. 62. A process control or automation system according to any one of claims 59 to 61, wherein an end point of the particular secure PTP or P2P connection is a particular instantiated MEEE of the process control or automation system.

63. A process control or automation system according to any one of claims 59 to 62, wherein the particular secure PTP or P2P connection is a particular secure PTP connection.

64. A process control or automation system according to any one of claims 59 to 62, wherein the particular secure PTP or P2P connection is a particular secure P2P connection.

65. A process control or automation system according to any one of claims 2 to 5 and 12 to 24, wherein the secure PTP or P2P connection is a secure PTP connection.

66. A process control or automation system according to any one of claims 2 to 5 and 12 to 24, wherein the secure PTP or P2P connection is a secure P2P connection.

67. A combination of any one of claims 1 to 66 with any other one of claims 1 to 66.

68. 1. A process control or automation system comprising: Physical devices located at and utilized in physical locations within industrial or automation processes provided by the enterprise; and an application environment including an application usage, the application environment including a plurality of communicatively connected instantiated microencapsulated execution environments (MEEEs), the plurality of MEEEs cooperating in real time to implement the application usage, at least one of the plurality of MEEEs being communicatively connected to the physical device and configured to at least one of send information to the physical device or receive information from the physical device, and the at least one of the plurality of MEEEs obtaining data for the application usage directly from the physical device at the physical location in real time while implementing the application usage.

69. 69. The process control or automation system of claim 68, wherein the physical device and the at least one of the plurality of instantiated MEEEs are communicatively connected via a secure point-to-point (PTP) or peer-to-peer (P2P) connection, and wherein the at least one of the plurality of MEEEs obtains data for the application usage directly from the physical location in real time while implementing the application usage using the secure PTP or P2P connection.

70. 70. The process control or automation system of claim 69, wherein the secure PTP or P2P connection is a secure encrypted PTP or P2P connection.

71. 71. A process control or automation system according to claim 69 or 70, wherein at least one of a plurality of instantiated MEEEs is an endpoint of the secure PTP or P2P connection.

72. A process control or automation system according to any one of claims 68 to 71, wherein the secure PTP or P2P connection comprises a virtual private network (VPN).

73. 73. A process control or automation system according to any one of claims 68 to 72, wherein the application usage is a control or automation application that controls one or more physical devices at the physical location to control the operation of the process or automation system.

74. 73. The process control or automation system of any one of claims 68 to 72, wherein the application usage is a maintenance application that uses data from the one or more physical devices at the physical location to perform one or more device maintenance functions with respect to the one or more physical devices.

75. 73. The process control or automation system of any one of claims 68 to 72, wherein the application usage is a fleet management application that uses data from the one or more physical devices at the physical location to perform one or more fleet tracking or management functions with respect to the one or more physical devices.

76. 73. The process control or automation system of any one of claims 68 to 72, wherein the application usage is an operation tracking or logging application that uses data from the one or more physical devices at the physical location to perform one or more process tracking or data logging functions relating to processes implemented by the one or more physical devices.

77. 77. A process control or automation system as described in any one of claims 68 to 76, wherein at least one of the plurality of instantiated MEEEs includes a data reference to the one or more data objects created on one or more of the physical devices at the physical location where the one or more data objects are stored, the data reference enabling the at least one of the plurality of instantiated MEEEs to directly retrieve the one or more data objects from the one or more physical devices at the physical location where the one or more data objects are stored in real time during execution of the application usage.

78. 78. The process control or automation system of claim 77, wherein the at least one of the plurality of instantiated MEEEs retrieves the one or more data objects directly from the one or more physical devices at the physical location where the one or more data objects are stored in real time during execution of the application use using publish / subscribe communications.

79. 78. The process control or automation system of claim 77, wherein the at least one of the plurality of instantiated MEEEs retrieves the one or more data objects directly from the one or more physical devices at the physical location where the one or more data objects are stored in real time during execution of the application usage using one or more addressed or direct data calls.

80. 77. A process control or automation system as described in any one of claims 68 to 76, wherein at least one of the plurality of instantiated MEEEs obtains the one or more data objects directly from the one or more physical devices at the physical location where the one or more data objects are stored in real time during execution of the application usage using publish / subscribe communication.

81. 77. A process control or automation system as described in any one of claims 68 to 76, wherein at least one of the plurality of instantiated MEEEs retrieves the one or more data objects directly from the one or more physical devices at the physical location where the one or more data objects are stored in real time during execution of the application usage using one or more addressed or direct data calls.

82. 82. A process control or automation system as described in any one of claims 68 to 81, wherein the at least one of the plurality of instantiated MEEEs executes on hardware in a computational fabric that is located remotely relative to the physical location.

83. 83. The process control or automation system of claim 82, wherein the computational fabric comprises a cloud computing environment.

84. 84. The process control or automation system of claim 82 or 83, wherein the at least one of the plurality of instantiated MEEEs retrieves the one or more data objects directly from the one or more physical devices at the physical location where the one or more data objects are stored in real time during execution of the application usage without first storing the one or more data objects on a computing device within the computational fabric.

85. A process control or automation system according to any one of claims 68 to 84, wherein the physical devices at the physical location include a server device.

86. A process control or automation system according to any one of claims 68 to 84, wherein the physical devices at the physical location include a communications gateway device.

87. A process control or automation system according to any one of claims 68 to 84, wherein the physical devices at the physical location perform physical functions at the physical location.

88. 85. A process control or automation system as claimed in any one of claims 68 to 84, wherein the physical devices at the physical location include input / output devices at the physical location connected to field devices.

89. 85. A process control or automation system according to any one of claims 68 to 84, wherein the physical devices at the physical location include field devices that perform physical functions at the physical location.

90. 85. A process control or automation system according to any one of claims 68 to 84, wherein the physical devices at the physical location include a database device coupled to the one or more field devices.

91. 85. The process control or automation system of any one of claims 68 to 84, wherein a number of the plurality of instantiated MEEEs execute on hardware in a computational fabric that is located remotely from the physical location, and wherein each of the number of the plurality of instantiated MEEEs obtains data in real time from a data source that is not co-located with the instantiated MEEE, and wherein the at least one of the plurality of MEEEs obtains data from a physical device that is located at the physical location.

92. 92. The process control or automation system of claim 91, wherein the multiple ones of the plurality of instantiated MEEEs operate together in real time to implement one of a control function, a maintenance function, a data logging or tracking function, or a fleet management function.

93. 93. The process control or automation system of claim 91 or 92, wherein the majority of the plurality of instantiated MEEEs includes the at least one of the plurality of instantiated MEEEs, and the at least one of the plurality of instantiated MEEEs operates to implement one of a control function, a maintenance function, a data logging or tracking function, or a fleet management function.

94. A combination of any one of claims 1 to 93 with any other one of claims 1 to 93.

Images