Secure connection of process control or automation system

Abstract

In one embodiment, a process plant and industrial control system architecture includes a general purpose computing fabric that is agnostic or irrelevant to a physical location that implements the computing fabric; comprising one or more physical control or field devices located at one or more specific sites for manufacturing a product or process; and also includes a transport network that securely provides communication between the computing fabric and the pool of physical devices. The computing fabric includes an application layer that includes a configuration container or containerized software module that performs various control, monitoring and configuration activities regarding one or more devices, control policies and control loops, sites, plants or facilities that perform the control; the present invention relates to a data storage system, and includes a physical layer that includes computer processing and data storage equipment that can be located at any desired location, the method may be applied to the cloud, including at or near a site, plant, or facility that performs the control, at a dedicated location remote from the location that performs the control, in reassignable computer equipment provided in the cloud, or any combination thereof. The control architecture enables a large number of computer processing and IT infrastructures for supporting process plants, industrial control facilities, or other automation facilities to be implemented in a shared, off-site, and / or virtualized manner, this mitigates a number of communication and security issues present in current processes and industrial control systems that attempt to achieve control with shared or virtualized computing resources established according to a well-known Precious Model. The industrial control system architecture is protected via techniques that are safer and customizable compared to those used in a Pru Model-based control system. For example, communications between any (and, in some cases, all) endpoints of the system may be protected via one or more virtual private networks that the authenticated endpoint must be authorized to access. The endpoints may include, for example, containerized components, physical components, devices, sites or locations, computing structures, etc., and the VPNs may include mutually exclusive and / or nested VPNs. External applications and services, whether being automatic or executing under human rights, may access information and services provided by the system only via APIs, and different sets of APIs may be exposed to different users that have been authenticated and authorized to access the respective sets of APIs. A configuration system operates within the computing structure to enable a user to easily make a configuration change to the computing structure because the user does not generally need to specify computer hardware within the computing structure for making the configuration change, this makes it possible for the user to deploy new configuration elements with simple programming steps and in some cases with pressing of buttons.

Description

[0001] Cross - Reference to Related Applications

[0002] This application claims priority to the following applications: U.S. Provisional Patent Application Serial No. 63 / 390,238, filed July 18, 2022, entitled "Next Generation Process Control and Automation System"; U.S. Provisional Patent Application Serial No. 63 / 398,441, filed August 16, 2022, entitled "Securing Next Generation Process Control and Automation Systems"; U.S. Provisional Patent Application Serial No. 63 / 417,861, filed October 20, 2022, entitled "Configuration Features of Next Generation Process Control and Automation Systems"; and U.S. Provisional Patent Application Serial No. 63 / 418,006, filed October 20, 2022, entitled "Enterprise - Level Features Provided by the NGPCAS". The entire disclosure of each of these applications is hereby expressly incorporated by reference herein. Technical Field

[0003] This application generally relates to industrial process control systems and automation systems for industrial process plants, and more particularly to a next - generation architecture for industrial process control and automation systems. Background Art

[0004] For decades, distributed process control systems and automation systems in various enterprises (such as distributed or scalable process control and / or automation systems used in power generation, chemical, petroleum, or other industrial processes such as pharmaceuticals or other types of manufacturing) have generally included one or more dedicated process controller devices that are communicatively coupled to each other via a process control network, coupled to at least one host or operator workstation, and coupled to one or more instruments or field devices via an analog bus, a digital bus, or a combined analog / digital bus.

[0005] Field devices perform processes or functions within a plant, such as opening or closing valves, turning equipment on and off, and measuring process parameters. Example 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 operating to send data to and / or receive commands from one or more dedicated controller devices.

[0006] A process controller, typically located within a plant environment (i.e., within the physical confines of the plant and specifically near the field devices), receives signals (or other information related to the field devices) indicative of process measurements made by the field devices; and executes a controller application that runs different control modules, such as making process control decisions, generating control signals based on the received information, and coordinating with control modules or blocks implemented in intelligent field devices (e.g., and Fieldbus field devices).

[0007] Execution of the control module causes the process controller to send control signals to the field devices via a communication link or signal path, thereby controlling the operation of at least a portion of the process plant or system (e.g., controlling at least a portion of one or more industrial processes operating or being executed within the plant or system). For example, a first set of controllers and field devices may control a first portion of a process controlled by the process plant or system, and a second set of controllers and field devices may control a second portion of the process.

[0008] Input / output (I / O) cards (sometimes referred to as "I / O devices" or "I / O modules"), which are also typically located within the plant environment, are generally communicatively disposed between the controller and one or more field devices, enabling communication therebetween (e.g., by converting electrical signals to digital values and vice versa). Typically, the I / O cards serve as intermediate devices between the process controller and one or more field devices, where the process controller and one or more field devices have inputs or outputs configured for one or more communication protocols that are the same as those utilized by the I / O cards.

[0009] Field devices, controllers, and I / O devices are generally collectively referred to as "process control devices" and are typically located, set, or installed in the field environment of a process control system or plant. A network formed by one or more controllers, field devices communicatively connected to the one or more controllers, and intermediate devices facilitating communication between the controller and the field devices may be referred to as an "I / O network" or "I / O subsystem".

[0010] Information from the I / O network can be provided to one or more other hardware devices via a data highway or a communication network (“process control network”), such as operator workstations, personal computers or computing devices, handheld devices), data historians, report generators, central databases or other central management computing devices typically located in a control room or other locations in a harsher field environment away from the plant (e.g., in a back-end environment of a process plant).

[0011] The information transmitted through the process control network enables an operator or maintenance personnel to perform desired functions regarding the process via one or more hardware devices connected to the network. These hardware devices can run application programs that enable an operator or other users (such as configuration engineers or maintenance personnel) to, for example, configure process controllers, I / O devices and field devices, change the settings of process control routines, modify the operation of control modules within a process controller or intelligent field device, view the current state of the process or the state of a specific device within a process plant, view alarms generated by field devices and process controllers, simulate the operation of the process for the purpose of training personnel or testing process control software, diagnose problems or hardware failures within a process plant, etc. The process control network or data highway utilized by the hardware devices, controllers and field devices can include a wired communication path, a wireless communication path or a combination of a wired communication path and a wireless communication path.

[0012] 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 and communication links or paths connecting the communication nodes. Additionally, a communication network typically includes dedicated routers (including firewalls) responsible for directing traffic between communication nodes, and optionally dedicated devices responsible for configuring and managing the network. Some or all of the communication nodes can also be adapted to function as routers to direct traffic sent between other network devices. The network devices can be interconnected in a wired or wireless manner, and the network devices can have different routing and transmission capabilities. For example, dedicated routers are capable of high-capacity transmissions, while some communication nodes can send and receive relatively less traffic within the same time period. Additionally, the connections between communication nodes on the network can have different throughput capabilities and different attenuation characteristics. For example, due to different physical or fundamental limitations inherent in the medium, fiber optic cables can provide bandwidth that is several orders of magnitude higher than wireless links.

[0013] Industrial control system providers and users have for years organized control systems for industrial processes around the Purdue Model for the control hierarchical logic framework standardized by ISA (International Society of Automation) 95.01 - IEC (International Electrotechnical Commission) 62264 - 1 (“Purdue Model”). The Purdue Model is a network segmentation model for industrial control systems that helps conceptualize and organize the concept of industrial process architecture, particularly the security of individual network segments within an industrial process.

[0014] Very similar to how the OSI model for network communication conceptually organizes computer communication networks into layers, the Purdue Model divides industrial process architecture into multiple levels and zones. Levels 0, 1, 2, and 3 represent, respectively, the physical process (e.g., physical devices as controlled field devices and attached 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., operator workstations and human - machine interfaces (HMIs), historical databases, configuration, etc., and supervisory control and data acquisition (SCADA) functionality and other control logic that analyze and act on Level 1 data), and plant operations (e.g., plant - wide control and monitoring, data aggregation, reporting, etc.) and are part of the manufacturing area. Levels 4 and 5 represent, respectively, the business and logistics systems of the enterprise (e.g., database servers, application servers, file servers, etc.) and the enterprise or corporate network (e.g., a broader collection of enterprise information technology (IT) systems, including connections to the public Internet) and are part of the enterprise area. A demilitarized zone (DMZ) is located between the enterprise area and the manufacturing area. Process control Levels 0 - 2 typically require a higher level of trust in the security and validity of messages, packets, and other communications, while manufacturing, company, and enterprise systems in Levels 3 - 5 typically require a lower level of trust. For example, process plant systems, networks, and devices at security levels 0 - 3 can be protected from threats from the enterprise network at security levels 4 - 5 and / or any external network above security level 5 that utilizes the enterprise network, e.g., by using a DMZ and / or one or more firewalls.

[0015] As industrial processes and the associated control systems for these processes become more complex, the operational 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) around which it was developed (i.e., systems for data-centric computing and analysis). Data from OT systems are now sought and analyzed by various IT systems. For example, data at the operational level from a factory can be used by various IT systems (e.g., at the enterprise level) to monitor factory efficiency, create or update production schedules, product delivery schedules, and the delivery of input materials, and for many other purposes. However, it is extremely difficult to achieve the desired level of security within the Purdue model because the desired level of security requires significant infrastructure and correspondingly difficult configuration, which can take up to a month or more during factory commissioning. Transferring data between the layers of the Purdue model (e.g., sending data from layer 2 to layer 3 or 4) while maintaining some security requires many security solutions including a proliferation of data relays, data diodes, and firewall devices. In some specific implementations, to mitigate communication issues caused by these complex security features, system providers and / or site engineers have avoided the Purdue model from directly sending data from control devices to the cloud, which undermines the factory security features provided by the Purdue model.

[0016] Adding to the complexity, OT systems are often older systems that are incompatible with the generally accepted principles of good security hygiene on IT networks because OT networks were often designed without considering IT security. For example, OT systems typically do not support modern identity and authentication / authorization protocols or practices, at least at the level of field devices and controllers. 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 at each such domain. Thus, cross-layer connectivity can be challenging, leading to specific implementations where holes are punched in firewalls to get data between layers, credentials are hard-coded into devices or applications, and / or are passed in unencrypted form to maintain connectivity. In addition, due to the above reasons, the integration of third-party software is difficult, error-prone, and often insecure, and vulnerabilities are often not patched because the required downtime would result in significant costs for factory operators. These drawbacks result in process control networks that are, at best, complex, chaotic, and extremely difficult to maintain, and, at worst, insecure.

[0017] Recently, some providers and users of industrial control systems have attempted to move parts of the industrial control system to general-purpose computing resources such as the cloud and virtualize certain aspects of the industrial control system. The purpose of these attempts is to capture and analyze the growing amount of data generated in the industrial control system and to create, for example, virtualized redundancy. However, following the Purdue model and the associated security practices it requires has led each of these attempts to suffer from one or more of the drawbacks detailed above, along with ancillary effects. Integrating cloud-based components into the Purdue model can greatly 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. When added to the traversal of the IT infrastructure (whether local or remote), the resulting additional security infrastructure required can increase latency (especially with respect to control signals) to sometimes unacceptable levels.

[0018] In addition, some providers of industrial control systems have attempted to decouple the control algorithms that control industrial processes from dedicated controller hardware (e.g., virtualize). To this end, entire controllers have been virtualized so that they can be executed on less specialized hardware (e.g., on servers or shared computing hardware), allowing multiple copies of the control algorithms to be executed in parallel on different hardware, such that one instance can be used as a backup for another primary instance. If the primary instance fails or becomes unstable, control can be transferred to the backup instance, and the original primary instance can be shut down and reinstantiated on the same or different hardware. While such systems have some advantages in terms of controller redundancy since entire controllers can be instantiated multiple times on different hardware and even moved between hardware, they continue to suffer from the limitations imposed by the Purdue model. Additionally, these systems require all 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

[0019] New process plants and industrial control and / or automation system architectures enable a large amount of computer processing and IT infrastructure (referred to herein as a compute fabric) that supports process plants, industrial control facilities, or other automation facilities to be implemented in a shared, off-site, and / or virtualized manner, which alleviates many communication and security issues present in current process and industrial control systems that attempt to use shared or virtualized computing resources such as cloud-based computing or system resources for control. Specifically, when integrating and providing communication between factory devices such as field devices, device controllers, supervisory controllers, site business operations, and enterprise operations, the new control system (which can 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 recognized Purdue model. Thus, when supporting control functions related to a process plant or industrial automation facility, the system architecture can implement control functions, communication, and security measures in a more efficient manner by effectively using communication and security features developed for general computing purposes outside of the process plant environment.

[0020] More specifically, the new control system architecture includes a compute fabric that is agnostic or irrelevant to the physical location where the compute fabric is implemented, and includes one or more physical controlled devices (referred to herein as a physical device pool) located at one or more specific factories, facilities, sites, or physical locations where a product or process is manufactured or implemented, such as valves, transmitters, I / O devices, etc., and also includes a transport network that implements or provides communication between the compute fabric and the physical device pool in a robust and secure manner.

[0021] Generally speaking, a computing architecture includes a physical layer and an application layer. The physical layer includes one or more computer processing and / or storage devices, and the application layer includes computer-implemented software modules that can be implemented on the physical layer to perform various control, monitoring, and configuration activities using a pool of physical devices. In one case, the application layer of the computing architecture can be implemented as a set or multiple sets of configuration containers or as a containerized system, where various different configuration containers and different types of containers perform different computer-implemented functions with respect to the facilities or enterprises in which the control system is implemented. The physical layer of the computing architecture can be implemented in any desired computer processing, storage, and networking equipment, such as on one or more computer processors and computer databases in the cloud, on one or more dedicated off-site locations separate from the factory, facility, or site where the pool of physical devices is located, on computer equipment located at the physical factory or facility where the pool of physical devices is located, or any combination thereof. The new control system architecture also includes a network layer that is disposed between the physical layer and the application layer and provides supervision, management, and use of physical layer resources and logical (e.g., software-based) resources once application layer activities require them, and specifically supports the timing and other requirements specific to and required for industrial process control and automation.

[0022] In addition, various components of the application layer (e.g., the various configuration containers that make up the application layer) can be executed in any desired and configurable manner in any desired computing equipment associated with the physical layer. Thus, the configuration containers of the application layer can be implemented in a redundant manner in each of the computer processing equipments in the same or different computer processing equipments of the physical layer, can be moved between different computer processing equipments of the physical layer to provide better computing and communication performance, can be replicated in various different processors or databases of the physical layer to provide redundancy and / or control the replicated physical equipment, etc.

[0023] The pool of physical devices can include devices that perform physical functions for controlling industrial or automated processes implemented at various different locations, sites, or facilities of an enterprise. For example, a pool of physical devices that can include field devices such as valves, valve positioners, actuators, switches, regulators, sensors, etc. uses physical hardware to perform physical functions, control, and / or other types of functionality associated with controlling industrial or automated processes. The physical hardware is located at one or more manufacturing facilities of the enterprise and interacts with the process materials or products being manufactured to provide measurement and control of physical phenomena that are controlled / implemented as part of the manufacturing or automated process. The pool of physical devices can be set or physically located at different physical locations or environments associated with the enterprise, or can be entirely set or only located at a single physical location or environment.

[0024] During operation, the computing structure may be communicatively coupled to a pool of physical devices located at one or more physical locations using one or more transmission networks. The transmission network may use any desired communication infrastructure and communication protocols, including any desired wired and / or wireless communication equipment / protocols. Such protocols may be any of a variety of process control protocols, such as HART, WirelessHART, Foundation Fieldbus, Profibus, OPC UA, etc., and / or may be any of a variety of general computing communication protocols. For example, the transmission network may use any IP-based or packet-based protocol, including protocols that utilize publish and subscribe such as MQ Telemetry Transport (MQTT) and Advanced Message Queuing Protocol (AMQP). Additionally, the transmission network may use or include any desired physical layer of a communication network, such as Ethernet, 802.11, Advanced Physical Layer (APL), etc. In this way, the pool of physical devices may send data or information in packet form to one or more configuration containers in the computing structure via one or more transmission networks and may receive data or information therefrom, enabling the computing structure 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 couple different remote infrastructures (e.g., which may be implemented via different cloud computing systems and / or via other suitable means) as well as to communicatively couple different physical locations (e.g., local infrastructure) to remote infrastructure. For network security reasons, the virtual network may be routed through a Virtual Private Network (VPN). For reliability purposes, different VNets may be used for different network providers (e.g., AT&T and Verizon). A more detailed description of the VPN is provided elsewhere in this document.

[0025] The computing structure may be implemented on a scalable hardware platform, portions of which may be physically located across one or more physical locations, which 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 computing structure may be implemented on a cloud computing platform, the hardware of which may be located remote from the physical location of the field environment where the pool of physical devices is located.

[0026] Generally, a computing structure supports the creation, execution, removal, maintenance, supervision, and management of multiple containerized applications, containerized services, or other containerized components (e.g., configuration containers). A pool of containerized components can include applications and / or services that have been configured into containers, each of the applications and / or services executing to provide specific functionality utilized by a control system and / or operations to control, monitor, and / or configure one or more pools of physical devices, support process and / or automation control and system management, and supervise, maintain, and manage the system and its components during the life of the system. Generally, containerized components provide functionality that traditional process control and automation technologies typically achieve via multiple systems, networks, computing devices, DMZs, firewalls, and applications operating at levels 2-5 of the Purdue model, such as the supervision, monitoring, and control of physical industrial processes and data acquisition at level 2 to enterprise-level IT functionality providing business direction and functionality related to the system at level 5. Additionally, containerized components can provide even higher levels of functionality, such as the coordination and / or management between multiple systems of an enterprise or even the coordination between multiple enterprises. Thus, and advantageously, rather than utilizing the cumbersome and resource-intensive traditional architectures of the Purdue levels 2-5 and all of the numerous digital diodes, firewalls, DMZs, etc. necessary to secure process control or automation systems in traditional architectures, the control architecture described herein utilizes only a set of containerized components executing within the computing structure to perform a set of the same or similar process control and automation core functionality and related functionality without compromising the security of the system, and in some arrangements, provides a higher level of security than may be provided by traditional architectures.

[0027] Furthermore, different functionality can be implemented by different containerized components within the computing structure, and thus a single application or service can be configured into multiple different containerized components (e.g., different instances of an application or service implemented in respective containers). In this way, similar or related configuration containers can execute in conjunction with different physical devices and can execute on different parts of the hardware platform of the computing structure, e.g., to create redundancy or hot backups, etc. Advantageously, various containerized components can be created (e.g., launched) and / or removed as needed or when needed, and a set of containerized components can operate together to form or provide a logical process control or automation system, which can be implemented as a "virtual process control system" for controlling one or more industrial or physical processes.

[0028] In addition, during execution, each containerized component can be communicatively connected to a specific physical component or physical device or another containerized component via a respective packet-based connection on a delivery network, such that each containerized component and each physical component can be identified within the system by a unique name or identity that can be associated with a specific address (e.g., an IP address) within the delivery network. To maintain a high level of communication security, containerized components and physical components can be authorized and authenticated on a per-component basis and optionally pairwise with each other, for example by using keys or any other suitable authorization and authentication techniques. After successful authorization and authentication, two endpoint components can transmit data, instructions, and other information to each other during a session established between the two endpoint components via one or more transport networks.

[0029] To further protect the system, one or more transport networks can include one or more virtual private networks (VPNs), such that for example a specific containerized component is communicatively connected to a specific physical component or to other containerized components using a point-to-point or peer-to-peer connection (such as a VPN) that is dedicated only to the specific containerized component and the specific physical component. In this way, components can securely transmit data, messages, instructions, and / or other information to each other via exclusive, point-to-point or peer-to-peer connections. Unique point-to-point or peer-to-peer connections can be established and / or torn down as needed or when needed. Further still, multi-point connections (e.g., VPNs or other suitable implementations) can be used to provide highly secure communication between multiple containerized and / or physical components. In some implementations, as an alternative or supplement to one or more point-to-point or peer-to-peer connections, point-to-point or peer-to-peer network connections can be utilized to further protect the system. The point-to-point connections, peer-to-peer connections, and VPNs of the transport network can be implemented via one or more public and / or private networks (including private enterprise networks and / or the public Internet).

[0030] Advantageously, the architecture of the computing fabric abstracts (e.g., decouples) from a specific computing platform or hardware associated with the computing fabric higher-level, business logic services, subsystems, and other software components of the application layer, and enables the higher-level software-defined services, subsystems, and other software components to use services such as APIs, operating system (OS) support, and other services of the network layer to dynamically, automatically, and reactively direct and cause changes in the use of the hardware and software resources of the nodes and clusters of the computing platform without any human intervention or guidance. Thus, the management of the resources of the computing platform can respond dynamically to changes in configuration and the requirements of higher-level software-defined services, subsystems, and other software components of the application layer.

[0031] In one example, industrial process control, automation, and other associated business logic are performed by higher-level software-defined services, subsystems, and other software components associated with a computing fabric, such as at the application layer. For example, a set of software-defined application layer components can collectively form a logical process control or automation system that executes in conjunction with physical components located at one or more physical locations or sites to implement an industrial process. Additionally, a set of third-party business logic services can also be executed at the application layer of the computing fabric, and these third-party services can be generated by a software development kit associated with the computing fabric, through which users can develop, generate, install, and manage third-party services at the application layer.

[0032] As another example, a controller or control service in the computing fabric can be configured with one or more process control module services, parameters, and values (such as input and output tags, reference values, etc.) associated with an industrial process plant, thereby forming a configured or programmed controller service. The controller or control service can be functionally equivalent to a traditional dedicated hardware controller device as understood in the Purdue model, or the controller service can be functionally equivalent to a control routine or control module configured into and executed by a traditional dedicated hardware controller device. A container can be configured with an instance of the configured controller service, thereby forming a container image or instance of the configured controller service that, when so configured, can execute to perform a specific set of configured process control logic, for example, by using configured control module containers, tags, reference values, etc. Multiple instances or container images of the configured controller service (or other configured applications and services) can be instantiated and executed by the computing fabric.

[0033] Some of the configured containers in the computing fabric can be assigned or allocated to corresponding computing nodes of the computing fabric and dynamically reassigned to different computing nodes by software-defined computing services based on the dynamically changing configuration, performance requirements, and other needs of the logical process control or automation system. In some cases, the configured containers can be assigned (and reassigned) to be executed by a specific processor or specific processor core of one or more computing nodes. However, some configured containers can be fixed to the corresponding computing nodes and thus not be dynamically reassigned by the computing services due to dynamically occurring conditions. The configured containers can additionally or alternatively be fixed to other physical or logical components of the computing fabric. For example, a configured container can be fixed 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 computing node), a physical rack or a portion of a physical rack served by a specific power supply (where the physical rack physically houses the hardware of one or more computing nodes), etc. Additionally, configured containers can be nested within other configured containers, which is particularly useful in configuring and organizing a logical process control or automation system.

[0034] The application layer of the computing architecture may include other types of application layer services, such as operator displays and handovers, diagnostics, analytics, security routines, reporting, data historian, service configuration, communication with external or other systems, enterprise-level applications, etc. Additionally, a set of subsystems at the application layer of the computing architecture may provide or implement other virtual or logic process control-related subsystems of a logic process control system. For example, the historian subsystem may include read services, write services, and search services, each of whose configuration containers is nested within the configured historian subsystem container. In another example, the batch process control subsystem may include unit program services, recipe services, and regulatory record generation services, which may be nested within the configured batch process control system container.

[0035] Generally speaking, subsystems allow control services and other services to be easily and consistently grouped and / or managed. In one case, each computing node of the computing architecture hosts a corresponding instance of each subsystem in the set of subsystems, such that the subsystem services are readily and easily available to other application layer services executing on each computing node. Thus, changes to one or more subsystems can be coordinated among their corresponding instances executing at each computing node. Accordingly, the set of subsystems is highly available and readily available to any application layer service executing on a computing node, and in the event of a computing node failure, a computing node component failure, or a particular subsystem failure, the functionality provided by the set of subsystems can be easily maintained for the logic process control system. Subsystems may include continuous process control, event-driven process control, batch process control, state-based control, ladder logic control, historian, process user, alarm, permission, event, version control, process configuration, process I / O, etc.

[0036] Additionally, in some specific implementations, the computing architecture may implement digital twins of various software-defined application services, an entire software-defined application layer, various software-defined support services, and / or an entire software-defined network layer. The digital twin of the target component / layer may execute in concert with the active target component / layer above the computing platform, and thus receive runtime data from the field environment of the industrial process plant and operate accordingly with the same logic, state, timing, etc. as the active target component / layer. However, I / O and other types of data generated by the digital twin are prevented from being delivered to the field environment. In this way, if the active target / component fails, the digital twin of the field target / component can be simply activated to seamlessly maintain the runtime operation of the industrial process plant. Additionally, in some specific implementations, the computing architecture may implement digital twins of physical components, which may be used as proxies for the physical components during runtime operation.

[0037] Similarly, the computing fabric can be used to support a variety of enterprise-level services and functions, such as real-time monitoring of enterprise functionality across multiple facilities associated with the enterprise, real-time monitoring of one or more physical locations of the enterprise, providing or implementing a plant or facility operator display to enable an operator to input from any location, providing containerized services from any location, providing and instantiating control from any location, other enterprise services, portions of a process control system or even an entire process control system, 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 providing centralized monitoring of the computing fabric associated with the enterprise, among others. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] Figure 1A is a block diagram of an example architecture of a next-generation process control and automation system (“NGPCAS”) that can be used to control industrial and / or automation processes.

[0039] Figure 1B is a block diagram of an example architecture of a next-generation process control and automation system (“NGPCAS”) that can be used to control industrial and / or automation processes in which an installed or legacy distributed control system is present.

[0040] Figures 2A to 2C shows a portion of an example architecture of a next-generation process control and automation system that includes a digital twin Figure 1A and Figure 1B thereof.

[0041] Figure 3A is a block diagram of an example multi-enterprise framework for different next-generation process control and automation systems for different enterprises.

[0042] Figure 3B shows example enterprise-level computing fabric functionality that can be provided by Figure 1A and Figure 1B the computing fabric.

[0043] Figure 4 is a block diagram of an example architecture of a computing fabric that can be included in the Figure 1A and Figure 1B NGPCAS.

[0044] Figure 5A is a block diagram showing an intelligent field device that implements an Embedded Device Identity (EDID).

[0045] Figure 5B is a block diagram of a sensor / transmitter device that implements an EDID.

[0046] Figure 5C is a block diagram of an I / O device that implements an EDID.

[0047] Figure 5D Shows example information that can be stored as an EDID.

[0048] Figure 5E Is a block diagram showing components in a computing structure that allow a process control system to use an EDID to ensure and / or commission components of a process plant.

[0049] Figure 5F Is an example method for implementing an EDID in a process plant.

[0050] Figure 5G Is Figure 1A and Figure 1B An example resource security technique utilized by NGPCAS.

[0051] Figure 6A Shows an example way in which an enterprise can use a computing structure center and communication spoke configuration to support multiple different physical locations that can use different data and enforce governance rules to implement the NGPCAS described herein.

[0052] Figure 6B Is a diagram showing an example system hierarchy associated with an enterprise using the NGPCAS described herein.

[0053] Figure 7 Is a diagram showing the interconnection between an architecture provider / manager and multiple different enterprise systems each using Figure 1A and Figure 1B The NGPCAS, which enables the manager to oversee different enterprise systems and make quick and easy configuration changes to different enterprise systems.

[0054] Figure 8A Is a diagram showing a configuration system that enables Figure 7 Configuration activities at one of the enterprise systems to add, upgrade, or otherwise change the operation of the enterprise system.

[0055] Figure 8B Is an illustration of an example user interface display that enables a user at an enterprise to make hardware and software configuration changes to that enterprise.

[0056] Figure 9 Is a diagram showing a development system for developing and rolling out new features such as containers or products in one or more of the enterprise systems in Figure 7 The enterprise system in a way that shortens the development and rollout time associated with new control system features while providing the enterprise system manager with the ability to control the timing and selection of changes to the enterprise system.

[0057] Figure 10AShows an example NGPCAS control / operation graphical user interface (GUI) for a physical site.

[0058] Figure 10B Shows another example control / operation GUI for a physical site in NGPCAS.

[0059] Figure 10C Shows an example enterprise-level viewing GUI.

[0060] Figure 10D Shows an example process entity deployment GUI.

[0061] Figure 10E Shows an example control loop GUI for a physical site in NGPCAS.

[0062] Figure 10F Shows an example diagnostic GUI for multiple physical sites in NGPCAS.

[0063] Figure 10G Shows another example diagnostic GUI for multiple physical sites in NGPCAS.

[0064] Figure 10H Shows yet another example diagnostic GUI for multiple physical sites in NGPCAS.

[0065] Figure 11A Shows an example marketplace GUI for viewing and obtaining services / applications in NGCPAS.

[0066] Figure 11B Shows another example marketplace GUI for viewing and obtaining a specific service / application.

[0067] Figure 12A Shows an example data ingestion GUI for multiple physical sites of an enterprise.

[0068] Figure 12B Shows another example data ingestion GUI for multiple physical sites of an enterprise.

[0069] Figure 12C Shows a diagnostic GUI for enterprise NGPCAS. Detailed Description

[0070] The following disclosure describes new process plant and industrial control and / or automation system architectures that rely on a shared computing fabric to implement control, monitoring, and configuration activities in any process plant or industrial manufacturing or automation facility. The computing fabric is a high-performance computing system composed of loosely coupled storage, resource management, security, networking, and parallel processing functions linked by a high-bandwidth interconnect such as 10 Gigabit Ethernet, and may include any one or more of the following: commercial multi-purpose platforms such as Microsoft's Azure service platform; platforms owned, operated, and maintained by an enterprise or system provider and dedicated to implementing process control at one or more enterprises; computing clusters located locally and at the process plant; and so on. The sharing of resources by the computing fabric, which can be shared between 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 allow for various improvements and innovations in system configuration, control, monitoring, and management.

[0071] While the architecture will be described in detail below, the following examples illustrate several scenarios for implementing the concepts described in this specification in a system and highlight the advantages of such implementations. These examples should not be considered as limiting the available functionality, the personnel performing various tasks, the physical separation or location of various elements, or in any other way. Instead, these examples are intended to introduce the various system elements and operational aspects of the system, each of which will be described in more detail elsewhere in this specification.

[0072] Example 1

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

[0074] Using these available devices, a first enterprise owner implements a continuous process for producing various products by refining petroleum products in a first process plant, a refinery. The process plant is provided with various field devices (e.g., valves, tanks, distillation columns, sensors / transmitters, etc.), which sense parameters in the refinery and perform control actions in response to control algorithms using the sensed parameters as inputs. Each field device has a corresponding input / output device, which receives signals from the field device, converts the signals into a common format (e.g., Ethernet packets), and transmits data from the field device to a computing structure. A preconfigured gateway / router / aggregator that facilitates secure communication between the first process plant (e.g., collectively including I / O devices and field devices that form a set of physical devices) and the computing structure is the only non-field device or I / O device hardware located on the premises of the first process plant.

[0075] Configuration engineers for the enterprise and / or process plant access tools provided by the system provider to configure the operation of the process plant. The configuration engineers create the necessary control algorithms by: instantiating function blocks for receiving data from field devices via I / O devices and sending commands and data to field devices via I / O devices, instantiating various processing function blocks that use the data received from field devices as inputs to the control algorithm and generate outputs to be sent to field devices, and implementing an operator workflow that allows plant operators to monitor and respond to the conditions of the runtime process plant. However, compared to known, conventional, or traditional systems, these function blocks and control modules are not downloaded to a dedicated hardware controller of the process plant. Instead, once the process plant is commissioned (e.g., physical devices are installed and wired at the process plant), the function blocks and control modules are instantiated as containerized services and / or other types of micro-packaged execution environments (“MEEES,” also referred to herein as “microservices” or “grains”) in the computing structure.

[0076] Generally speaking, the microservices, particles, or MEEEs instantiated in a computing structure can be independent software processes that can run on their own deployment schedules and can be updated independently of other microservices. Examples of MEEEs can include functional blocks, control modules, control applications, and business logics related to process plants and / or other applications and services that support process plants in other ways. Groups of microservices or MEEEs can interact with each other collaboratively to achieve some desired results. For example, to control a reactor, multiple strategies such as feed, reactor, product, utility, and flare systems can be defined by the corresponding MEEEs, and the group of multiple MEEEs can operate collaboratively (e.g., in combination with each other) during the runtime of the process plant to implement the desired reactor control strategy. Another example is that for a process control analysis application, various MEEEs can be defined to perform corresponding statistical calculations and / or statistical algorithms, and various MEEEs can be combined and executed as needed to provide an overall predictive analysis application. A single microservice or MEEE can be configured to execute applications ranging from very broad (e.g., control strategies for the entire system or plant) to very fine-grained (e.g., only a part of a control routine or control module), as will be discussed in more detail elsewhere in this document. Therefore, due to its flexibility to be configured to execute various process control and process control-related applications from broad to fine-grained, the microservice or MEEE can be interchangeably referred to as a "particle" in this document.

[0077] In any case, the configuration engineer can also use configuration tools to specify various QoS metrics for each functional block and control module, for individual signals or variables, and for the entire process. Each of the microservices, MEEEs, or particles 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 can include one or more types of secure, encrypted PTP and / or P2P connections, such as VPNs), and each is authenticated via a digital security certificate. These secure, point-to-point and / or peer-to-peer connections and security certificates are automatically managed within the computing structure with little or no input from enterprise personnel.

[0078] Regarding QoS metrics, the orchestration service operating within the computing fabric (and provided by the system provider) implements various load balancing and redundancy schemes to ensure that the factory's QoS metrics are met. For example, the orchestration service ensures that redundant configured containers are always instantiated for any configured container that executes any part of the control algorithm, and the redundant configured containers maintain corresponding inputs and outputs to the primary configured container (i.e., maintain a parallel state), such that if the primary container fails, control can transfer to the redundant container almost immediately (e.g., within a few milliseconds). The orchestration service ensures that configured containers execute on separate hardware and are powered by separate power supplies to maintain sufficient redundancy according to policies set by the enterprise. For some microservices, configured containers, MEEEs, or particles, the orchestration service instead maintains a redundant state database that stores the state of the microservice / configured container / MEEE / particle, such that if the microservice / configured container / MEEE / particle fails or otherwise goes offline, a new microservice / configured container / MEEE / particle can be instantiated almost immediately (e.g., within milliseconds) and restored to the previously instantiated operating state of the configured container when it goes offline.

[0079] The orchestration service also provides a load balancing service to maintain sufficient memory, processing, and network resources to meet the QoS requirements of individual microservices / MEEEs / particles and the entire factory. For example, maximum latency requirements necessitate that certain configured containers execute physically closer to the process factory and / or on computing fabric resources with greater network bandwidth between the resources and the process factory.

[0080] To maintain security, and as described above, all containerized applications and services communicate via 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) communicate via a dedicated VPN, while other VPNs include multiple containerized applications / services that communicate with each other via corresponding sessions established over the VPN. Other VPNs facilitate communication between enterprise-level containerized applications / services and factory-level containerized applications / services, other VPNs still facilitate communication between vendor-level containerized applications / services and enterprise-level and / or factory-level containerized applications / services, and still other VPNs facilitate communication between user interface devices and the system. In any case, any human user and any third-party application that executes to facilitate services in an enterprise or process factory interact with one or more APIs of the system, and after the user or third-party application is authenticated (e.g., using multi-factor authentication), necessary actions can be performed through the one or more APIs.

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

[0082] Example 2

[0083] At some point after the commissioning of the first process plant, the first enterprise owner decides to replicate the first process plant in the second process plant. Since the control algorithms and the necessary software have been configured to be used with the first process plant, setting up the field devices and I / O hardware at the second process plant is one of the most time-consuming parts of commissioning the process plant.

[0084] In this case, the enterprise owner chooses to remove the physical I / O devices from the process plant setup and, instead, implement the functions of the I / O devices as microservices, MEEEs, or particles instantiated in the computing fabric. The enterprise owner installs the field devices at the site of the second process plant. Each field device is configured in the normal way, i.e., with device tags, ranges, limits, scales, and other data for operating the field device. Since the second process plant is a copy of the first process plant, each field device is configured and programmed according to its corresponding device in the first process plant, and an automated process is used to reduce the time required for commissioning. Each device is coupled to a media converter via its corresponding communication medium, and the media converter converts between the device's local 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) the various data received from the corresponding field device and transmits the packets to a pre-configured field gateway in the second process plant. The gateway facilitates secure communication between the second process plant (media converters) and the computing fabric and is the only non-field device hardware located on the site of the second process plant.

[0085] The configuration engineer who has opened the stored configuration of the first process plant within the user interface application provided by the computing fabric drags loops on the computing fabric canvas (the workspace showing the configuration containers instantiated in the computing fabric for the first process plant) to select all the configuration containers and copies the set of configuration containers (e.g., containerized applications and services) instantiated in the first process plant to the second process plant by dragging the selected configured containers to a new computing fabric canvas.

[0086] The configuration engineer instantiates digital twins of field devices and corresponding I / O microservices / MEEE / granules for each field device of the second process plant within the computing fabric, replacing the previous physical I / O devices that couple the physical field devices to the controller. For the remainder of the process control software executed within the computing fabric, the digital twins are indistinguishable from the hardware field devices operating in the process plant. The digital twins are identically configured and maintain the same data as the data present on the field devices themselves to the extent necessary (and possible, as described below). That is, when the field devices update the values of the measured parameters or the status values, those values are uploaded via the media converter to the digital twins within the computing fabric. However, the digital twins interact with the instantiated function blocks, control modules, and other control algorithms within the computing fabric. For the same reason, the function blocks, control modules, and other control algorithms instantiated within the computing fabric (or within the hardware controller) send commands and data to the digital twins, which convey those commands and data back to the hardware field devices of the second process plant via the media converter.

[0087] In the case where the hardware field devices are in place and coupled via the media converter to the digital twins executed within the computing fabric, the configuration engineer instructs the computing fabric to bring the process online at the second process plant, for example, by activating a single user control. In response, the computing fabric initializes the process control system, and the system is online and ready to begin testing and / or operation within the next few minutes, greatly simplifying the process of bringing the second process plant online.

[0088] In addition to simplifying its commissioning, the digital twins contribute to the robustness of the operation of the second process plant. In the case where a particular field device becomes unavailable (temporarily or otherwise), the digital twins can prevent abnormal conditions in the operation of the entire process plant. For example, a brief loss of connectivity or an increase in latency between the process plant and the computing fabric may have no impact on the overall process because the digital twins can continue to provide data (e.g., simulated data, assumed steady-state data, etc.) to the control algorithms (within the safety parameters, of course) during the brief anomaly. Similarly, if the self-reported (or system-determined) status of a sensor changes to indicate that the sensor value is no longer reliable, the digital twins can be programmed to provide data from another source (e.g., simulated values, values calculated based on other measured parameters, etc.) to replace the unreliable sensor data.

[0089] The use of digital twins also contributes to the cost-effective maintainability of the process plant. In the case where a hardware sensor (e.g., a thermocouple or a pressure sensor) fails, in many instances, the sensor can be replaced without stopping or interrupting the operation of the process because the digital twins can continue to provide data (simulated or otherwise) to the control algorithms even when the hardware sensor is offline.

[0090] Example 3

[0091] With the first process plant and the second process plant up and running, the business owner (or their user) can manage both of them at the enterprise level using various tools available from the system provider. Since the various facilities owned by the business are executed within the computing fabric, the business owner can securely access data related to the process plants or data related to the entire enterprise individually, at any time and from anywhere. As described above, access to the system is provided to all persons and / or third-party applications via an API, and access to the API requires multi-factor authentication. Thus, after authentication, the user can access tools, metrics, and other functions that allow for the management of the enterprise and its various process plants.

[0092] Enterprise-level users can create or use any number of dashboards and tools to facilitate an enterprise-level view of the process plants, either individually or collectively. Enterprise-level users can decide to view real-time production metrics for a single plant (e.g., production output, quality metrics, etc.), and can also decide to compare real-time metrics between plants, plotting the metrics for each plant over time for comparison. Upon noticing that one plant is performing differently from another (e.g., producing higher-quality products, operating more efficiently, etc.), the enterprise-level user can decide to dig deeper into the reasons for the difference in plant performance. Going to the application or service marketplace hosted by the system provider, the enterprise-level user can purchase or subscribe to an analytics service or tool that is instantiated within the computing fabric upon purchase or subscription and can be used by the enterprise-level user to analyze the performance of the process plants.

[0093] The analysis indicates that the tuning of one of the process plants can be optimized for better performance, and recommends different tools for retuning and optimizing the process plants. The enterprise-level user can contact the control operators of the plants to inform them of the available tools. The tool is then subscribed to or purchased for the enterprise or for individual plants only, and is instantiated within the computing fabric at the plant level and / or the enterprise level.

[0094] The tool can determine that the process plant needs to be retuned in a way that requires an updated copy of one or more control algorithms. In such a case, the tool proceeds (using input from the operator) to create the updated control algorithms. The updated control algorithms are instantiated within the computing fabric but are not initially placed under the control of the process plant. Instead, the updated control algorithms are implemented in parallel with the active control algorithms (e.g., in a simulation mode) to ensure that they do not adversely affect the operation of the process plant and, in fact, will improve the operation of the process plant. Then, when it is determined that the updated control module will function properly, the operator immediately switches the control of the process to the new control algorithms (e.g., without interrupting the process).

[0095] Meanwhile, an operator at one of the process plants may notice that the adjustments to the process for which the operator is responsible appear to be fluctuating. The operator contacts a customer service representative from the system provider to help determine what is causing the fluctuations in the adjustments and, using the dashboards available to the system provider's representatives, they determine that the fluctuations in the adjustments may be the result of several related factors in the computing fabric, including the movement of microservices / MEEEs / granules between the hardware resources used for load balancing, changes in available processing and network bandwidth, and the physical distance between the computing fabric resources and the process plant in question. The customer service representative may recommend using a real-time adjustment application.

[0096] The real-time adjustment application monitors the latency between the computing fabric and the physical resources in the process plant and automatically adjusts the adjustments to the control algorithms to account for changes in latency due to network conditions, physical distance, and processor bandwidth. In this example, after implementing the real-time adjustment application, the operator notices that the subject process is generally more stable.

[0097] However, if the real-time adjustment application indicates that there is a control loop that the real-time adjustment application cannot automatically adjust, the operator and the customer service representative working together can determine that the control loop in question requires minimum latency and, therefore, the customer service representative can "pin" the configuration container associated with the control loop to the physical hardware resources in the computing fabric that meet the latency requirements and, in particular, are physically close to the process plant in question. Additionally, the customer service representative can additionally dedicate specific hardware resources to the configuration container associated with the control loop to prevent those resources from being loaded to the extent that the latency will cause the process to malfunction.

[0098] Example 4

[0099] The owner of an enterprise with multiple process plants in operation can determine that consolidating the operators who manage the various processes will be more efficient. Although a certain number of maintenance and other personnel must be physically present at each process plant, the fact that the computing fabric is essentially able to be securely accessed from anywhere with sufficient network connectivity allows the operators to be located anywhere. Therefore, the enterprise owner can determine that all of its operations can be consolidated into three operations centers that are roughly equally spaced around the world such that its operations can be sustained 24 hours a day without any of its employees having to work outside of their respective site's first shift (business) hours.

[0100] The enterprise owner staffs each operations center with a number of operators sufficient to operate all of the plants it operates worldwide. As a result of consolidating the operations centers, the number of employees required for redundancy (e.g., considering employee illness, vacations, etc.) is reduced.

[0101] Example 5

[0102] Individually, a second enterprise that wishes to improve the efficiency of its traditional architecture (first) process plant and expand to add additional process plants expects to do so by implementing a system provided by a system provider. The system provider creates an account for the second enterprise, and the second enterprise personnel subscribe to and / or purchase the necessary and desired tools and software packages. The configuration engineer of the second enterprise uses tools available from the system provider to convert the configuration file of the traditional controller currently operating in the first process plant into the configuration of a containerized service (e.g., microservice, MEEE, or particle) to be executed on a computing fabric. Meanwhile, the system provider arranges for the on-site installation in the first process plant of a pre-configured gateway that securely couples the I / O devices to the computing fabric. After ensuring that the computing fabric is configured to meet the necessary QoS metrics, the configuration engineer and operator of the first process plant use the configured computing fabric to simulate the operation of the process plant to confirm that it appears to be properly configured, and then bring the process plant online using the computing fabric.

[0103] When the newly reconfigured process plant is operating using the computing fabric and the traditional controller hardware is no longer operating the process plant, the second enterprise owner maintains the process plant rather than ceasing to operate the traditional controller configuration. In fact, the system provider helps the enterprise personnel configure the traditional configuration of the first process plant such that in the event that the computing fabric (or its network connection) becomes unavailable or unstable, control of the process plant can fail over to local control using the traditional system. Thus, the traditional system runs in parallel as a backup control solution.

[0104] Meanwhile, the second enterprise owner can decide to keep the safety instrumented systems (SISs) for the process in place at the first process plant rather than migrating them to the computing fabric.

[0105] When the second enterprise owner tends to expand to add new process plants, the second enterprise owner purchases the necessary field devices to install in and operate these process plants. Each field device includes a burned-in hardware ID indicating its brand, model, options, etc. When purchasing field devices, the burned-in hardware IDs of the purchased devices are registered to the second enterprise owner in a database that facilitates the configuration of the field devices in the new process plants. When configuring the control module, the configuration engineer can select each device from the database such that the computing fabric creates a digital twin for each device that is programmed accordingly. The plant engineer who configures the physical field devices in the new process plant scans each device and places each device based on its hardware ID. When the physical devices are connected to the computing fabric via their respective media converters, they are automatically associated with their digital twins based on their hardware IDs and are programmed according to the programming of their digital twins (if programmable).

[0106] When an additional process plant is configured to operate on a remote computing infrastructure, the second enterprise owner determines that since only one network provider serves some of the process plant locations, a control solution that can maintain the security (if not full operation) of the process plant locations is still advisable in the event that the network connection to the remote computing infrastructure becomes unavailable. To this end, the enterprise owner physically locates certain computing infrastructure resources on-site such that in the event of a communication failure between the process plant and the remote computing infrastructure, the local computing infrastructure can maintain the security and / or operation of the process plant. The local computing infrastructure resources execute redundant containerized services, microservices, MEEE, or particles (orchestrated by an orchestration service in the computing infrastructure) such that control of the process plant can fail over to the local computing infrastructure when necessary.

[0107] Example Next Generation Process Control and Automation System Architecture

[0108] Figure 1A is a block diagram of an example architecture of a next-generation process control and automation system (“NGPCAS”) 100 that can be used to control industrial and / or automation processes. For example, the NGPCAS 100 can be used by chemical, petroleum, industrial, manufacturing, filling and packaging, or other types of enterprises for manufacturing, refining, converting, generating, or producing physical materials or products. For ease of reading, the NGPCAS 100 may be referred to interchangeably herein as “architecture 100” or “system 100”.

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

[0110] The pool of physical devices 105, 108 of system 100 may be set or physically located at different physical locations, sites, factories, or environments 115, 118 (such as Figure 1A shown), or the pool of physical devices 105, 108 may be set entirely or only located at a single physical location, site, factory, or environment (not shown). One or more physical locations 115, 118 where the physical devices 105, 108 are located are generally and 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, sites, or outdoor areas, factories, oil rigs or platforms, rooms, cabinets, etc. where at least one physical device 105, 108 of system 100 is physically located and where at least one physical device 105, 108 operates in conjunction with the computing fabric 102 to control an industrial process or an automated process. The term "field environment 120" may be interchangeably referred to herein as the "process environment 120", "automation environment 120", "factory environment 120", or "physical environment 120" of NGPCAS 100.

[0111] Each physical location or environment 115, 118 at which at least one physical device 105, 108 of system 100 is disposed includes one or more local physical I / O (input / output) interfaces 125, 128 configured to receive, condition, and deliver (e.g., to computing fabric 102 via one or more transport networks 130) I / O signals or I / O data generated by local physical devices 105, 108 and optionally provide control signals, instructions, and / or other information generated by computing fabric 102 and received at locations 115, 118 via one or more transport networks 130 to designated receiving local physical devices 105, 108. Each local physical device 105, 108 is physically connected to local physical I / O interfaces 125, 128, e.g., via respective wired or wireless links. Thus, in one embodiment, local physical I / O interfaces 125, 128 may include I / O hardware ports (which may include wired and / or wireless ports or interfaces) and / or a pool of other I / O hardware resources shared among multiple local physical devices 105, 108 at respective locations 115, 118. Additionally or alternatively, local physical I / O interfaces 125, 128 may include individual instances of I / O hardware resources, where each individual instance is included in and exclusively connected to one and only one local physical device 105, 108. Generally, the present 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 interface 125, 128 used by the single physical device to convey information via transport network 130 (e.g., the attendant physical I / O interface of a single physical device 105, 108). Thus, in terms of terminology, NGPCAS 100 includes a pool of physical components 135, 138, each physical component including respective field devices 105, 108 and respective physical I / O interface resources 125, 128 used by the respective field devices 105, 108 to communicate with computing fabric 102. Generally, physical components 135, 138 of NGPCAS 100 operate or will be included at level 0 of the Purdue model of a conventional process control system.

[0112] As Figure 1AAs shown, physical components 135, 138 at each location 115, 118 are communicatively connected to computing fabric 102 via one or more transport networks 130. The one or more networks 130 can include one or more wired and / or wireless networks. Additionally, the one or more networks 130 can generally 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, physical I / O interfaces 125, 128 enable I / O data or information generated by physical devices 105, 108 to be delivered in packetized form via one or more transport networks 130. For example, physical I / O interfaces 125, 128 can convert I / O data or information generated by physical devices 105, 108 into packets, can encapsulate the I / O data or information in packets, or can otherwise convert the I / O data or information into a packetized format for delivery to computing fabric 102 via packet network 130.

[0113] In some embodiments, physical site or location 115 can include a gateway / router / aggregator 148, which for ease of discussion is referred to herein as "gateway 148". Generally, gateway / router / aggregator 148 receives outgoing data and information to be sent to computing fabric 102 and causes the outgoing data and information to be sent via transport network 130 (e.g., in individual packets and / or in packets in which data / information generated by multiple physical components 138 are aggregated into a single packet), and gateway / router / aggregator 148 receives incoming data and information received from computing fabric 102 (e.g., in individual packets and / or aggregated packets) and routes the information, instructions, and / or data included therein to the designated receiving physical component 138 at site 115. A physical location can include a corresponding gateway 148 (e.g., location 115), a physical location can exclude any gateway 148 (e.g., location 118), and in some configurations, multiple physical locations can share, for example, a single gateway 148 ( Figure 1A not shown in figure).

[0114] Turning now to computing fabric 102 of NGPCAS 100, computing fabric 102 is implemented on a scalable hardware platform, portions of which can be physically located at one or more physical locations ( Figure 1A not shown in figure). The physical location(s) at which at least a portion of the hardware platform of computing fabric 102 is physically located may or may not be the physical locations 115, 118 at which physical devices 105, 108 of system 100 are physically located. For example, the entire hardware platform on which computing fabric 102 is implemented can be located away from any of the locations 115, 118 of the in-field environment 120 of system 100 (e.g., as Figure 1Aas shown), or the corresponding portions of the hardware platform on which the computing structure 102 is implemented may be located at one or more of the physical device locations 115, 118 of the on-site environment 120 ( Figure 1A not shown). In some embodiments, at least a portion of the computing structure 102 may be implemented on a cloud computing platform, the hardware of which may be located remotely from and / or at the physical locations 115, 118 of the on-site environment 120 of the system 100.

[0115] The computing structure 102 of the NGPCAS 100 supports the creation, execution, removal, maintenance, supervision, and management of multiple containerized applications and / or services 140 or a pool of containerized applications and / or services, which are generally interchangeably referred to herein as the "multiple containerized components 140 or pool of containerized components", "multiple micro-encapsulated execution environments 140 (MEEE 140) or pool of micro-encapsulated execution environments", or "multiple particles 140 or pool of particles" of the NGPCAS 100. That is, the pool of containerized components / micro-encapsulated execution environments / particles 140 may include applications and / or services that have been configured into containers and / or other types of micro-encapsulated execution environments or particles, each of which may be executed to provide specific functionality and / or operations utilized by the system 100 to control the physical devices 105, 108, support processes and / or automation control and system management, and supervise, maintain, and manage the system 100 and its components during the lifetime of the system 100. Generally speaking, the containerized components / MEEE / particles 140 of the NGPCAS 100 provide functionality that traditional process control and automation technologies typically achieve via operations at levels 1-5 of the Purdue model, such as basic control of the physical industrial devices and processes of the system 100 at level 1 to enterprise-level IT functionality that provides business direction and functionality related to the system 100 at level 5. In addition, the containerized components / MEEE / particles 140 may provide even higher levels of functionality, such as coordination and / or management between multiple systems 100 of an enterprise or even coordination between multiple enterprises. Thus, and advantageously, rather than utilizing the cumbersome and resource-consuming traditional architecture of the Purdue levels 1-5 and all of the numerous digital diodes, firewalls, DMZs, etc. necessary to ensure process control or automation systems in the traditional architecture, the NGPCAS 100 only utilizes a set of containerized components / MEEE / particles 140 executed in the computing structure 102 to perform a set of the same or similar process control and automation cores and related functionality without compromising the security of the system 100 and generally with increased security of the system 100. A more detailed discussion of the security technologies utilized within the architecture of the NGPCAS 100 is provided elsewhere in this disclosure.

[0116] Typically, different functions are implemented by different containerized components / MEEE / particles 140 within the computing structure 102. If needed, a single application or service can be configured into multiple different containerized components / MEEE / particles 140 (e.g., different instances of an application or service implemented in respective containers), such as to execute in conjunction with different physical devices, execute on different parts of the hardware platform of the computing structure 102, create redundancy or hot standby, etc. The various containerized components / MEEE / particles 140 can be created (e.g., launched) and / or removed as needed by or when needed by the system 100. A set of containerized components / MEEE / particles 140 can cooperate to form or provide a logical process control or automation system 145 (also interchangeably referred to herein as a "virtual process control system" 145) to control one or more industrial or physical processes by controlling and leveraging the physical components 105, 108 disposed in the field environment 120 of the NGPCAS 100. Typically but not necessarily, the set of containerized components / MEEE / particles 140 forming the logical process control system 145 is a subset of all the containerized components / MEEE / particles 140 provided by the computing structure 102.

[0117] During execution, each containerized component / MEEE / particle 140 can be communicatively connected via the transport network 130 to a specific physical component 135 / 138 or another containerized component / MEEE / particle 140 via a respective packet-based connection. Thus, each containerized component / MEEE / particle 140 and each physical component 135 / 138 of the NGPCAS 100 are identified within the system 100 by a unique name, identifier, or identity that can be associated with a specific address (e.g., an IP address) within the transport network 130. Generally speaking, the physical components 135 / 138 can be the sender or provider of I / O data and information received or consumed by one or more containerized components / MEEE / particles 140. In some cases, the containerized component / MEEE / particle 140 can be the sender or provider of control signals or other instructions received or consumed by the physical component 135 / 138. In some cases, the containerized component / MEEE / particle 140 can be the sender or provider of data received or consumed by another containerized component / MEEE / particle 140. To maintain the security of the NGPCAS 100, the containerized components / MEEE / particles 140 and the physical components 135 / 138 can be authorized and authenticated on a per-component basis and optionally pairwise with each other, such as by using keys or any other suitable authorization and authentication techniques. After successful authorization and authentication, the two endpoint components 140, 135 / 138 can transmit data, instructions, and other information to each other during a session established between the two endpoint components 140, 135 / 138 via one or more networks 130.

[0118] To further protect the NGPCAS 100, one or more transmission 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 virtual private networks (VPNs) and other types of secure, encrypted PTP and / or P2P connections. In one embodiment, a particular containerized component / MEEE / particle 140 is communicatively connected 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 dedicated only to the particular containerized component / MEEE / particle 140 and the particular physical component 135 / 138. For example, the particular physical component 135 / 138 and the particular containerized component / MEEE / particle 140 may be endpoints of an exclusive point-to-point VPN that is utilized only by the two endpoint components 135 / 138 and 140 (e.g., and not by other components of the system 100), such that the components 135 / 138, 140 can securely transfer data, messages, instructions, and / or other information to each other via the exclusive point-to-point VPN. In a similar manner, a particular containerized component / MEEE / particle 140 may be communicatively connected to another particular containerized component / MEEE / particle 140 using a secure, encrypted point-to-point (P2P) connection that is dedicated only to the two containerized components / MEEE / particles (which may or may not be implemented via a VPN), and the two containerized components / MEEE / particles can securely transfer data, instructions, and / or other information to each other via their dedicated, secure, and encrypted point-to-point connection. The dedicated point-to-point and / or peer-to-peer connection between a single containerized component / MEEE / particle 140 and a single physical component 135 / 138 or a single other containerized component / MEEE / particle 140 may be established as needed or when needed, and may be torn down when needed (e.g., upon completion of data exchange, when system resources need to be released, etc.).

[0119] In one embodiment, a single physical location 115, 118 may be communicatively connected to the computing fabric 102 via a secure, encrypted location-to-location PTP or P2P connection (such as a location-to-location VPN or other suitable implementation) that is dedicated to the particular location 115 / 118 and the computing fabric 102 (not shown). Physical components 135 / 138 disposed at the particular location 115 / 118 and containerized components / MEEE / particles 140 executing on the computing fabric 102 may transfer data and information to each other via the location-to-location PTP or P2P connection. For illustration, in Figure 1AIn the example arrangement shown, location 1 (label 115) includes a local gateway / router / aggregator 148 that establishes a location-to-location VPN with computing fabric 102, such that the local gateway 148 is one endpoint of the location-to-location VPN and the VPN gateway application 150 executing on computing fabric 102 is the other endpoint. The containerized components / MEEE / granules 140 and physical components 105 disposed at location 115 can authenticate to the location-to-location VPN and establish corresponding sessions (e.g., via VPN gateway application 150 and local gateway 148) through the location-to-location VPN to transfer data and information to each other. Additionally or alternatively, architecture 100 can support subnets of the location-to-location VPN such that the various physical components 135 / 138 and various containerized components / MEEE / granules 140 disposed at location 115 communicate with each other via one or more subnets within the location-to-location VPN. Further, in the foregoing description, secure, encrypted PTP and / or P2P connection types other than VPN can be additionally or alternatively utilized.

[0120] In one embodiment, a multi-location (e.g., multi-point) secure encrypted connection can exclusively serve computing fabric 102 and physical components 135 / 138 disposed at multiple selected physical locations 115, 118 of system 100, where the selected physical locations are a subset of all the physical locations served by system 100. In this embodiment, each of the multiple physical locations 115, 118 can include a corresponding local gateway 148 to the multi-location secure encrypted connection and can be associated with one or more gateway applications 150 executing on computing fabric 102. The various physical components 135 / 138 disposed at the multiple locations and the containerized components / MEEE / granules 140 corresponding to the multiple locations can authenticate to the multi-location secure and encrypted connection and can establish sessions (e.g., via one or more gateway applications 150 and corresponding local gateways 148) through the multi-location secure and encrypted connection to send and receive data and information to / from other components 140, 135, 138. The multi-location secure encrypted connection can be implemented as needed by using a VPN or other suitable mechanisms, such as multiple PTP and / or P2P connections, point-to-multipoint (PTM) connections, etc.

[0121] In one embodiment, all containerized components / MEEE / particles 140 of the computing structure 102 and all physical components 135 / 138 at all physical locations 115 / 118 of the NGPCAS 100 can be served by a single system-level secure encrypted connection, which can be implemented as a system-level VPN or other suitable type of system-level secure encrypted connection. Each containerized component / MEEE / particle 140 and physical component 135 / 138 of the system 100 can authenticate to the system-level connection and can establish sessions with other components 140, 135, 138 through a secure, encrypted system-level connection (e.g., via the respective local gateways 148 and one or more gateway applications 150) to send and receive data and information to / from other components 140, 135, 138.

[0122] In addition, if desired, various secure, encrypted PTP, P2P, PTM, and / or multipoint connection technologies can be combined (e.g., by leveraging subnets) to provide even more security. For example, a specific physical component 135 / 138 and a specific containerized component / MEEE / particle 140 can establish and utilize a dedicated point-to-point VPN as a subnet of the location-to-location VPN, a group of containerized components / MEEE / particles 140 can be included in a subnet supported by the computing structure 102, and so on. Additionally, any secure, encrypted connection technology used within the NGPCAS 100 can be used in combination with endpoint authorization and authentication technologies to provide even greater security for the NGPCAS 100.

[0123] Furthermore, in some specific implementations and as described above, as a supplement or alternative to using a VPN, one or more transport networks 130 can 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 components of one or more NGPCAS systems 100. For example, point-to-point private connections can be established between two components 138, 140, between the physical sites 115, 118 and the computing structure 102, and so on. However, for ease of discussion herein, the description refers to "VPN" technology (not for limiting purposes), but rather generally and categorically describes secure transmission over the network 130, it should be understood that any of the systems, methods, and technologies described herein can additionally or alternatively utilize other types of secure, encrypted point-to-point, peer-to-peer, and / or multipoint connections for secure transmission.

[0124] A user 155 of the NGPCAS 100 can authenticate with the VPN 158 to interact with the NGPCAS 100 (e.g., interact with components 140, 135 / 138 of the NGPCAS 100) to, for example, view or obtain data and / or other information, change parameter values, configure or modify control routines of the system 100, and other aspects of the configuration, etc. As used herein, the "user" 155 can be a person or a human user, or the user 155 can be an application or service executing on an external computing device not included in the system 100, such as an automated user. For example, Figure 1A the user 155 shown can be equivalent to a person and an application / service that access data and information related to traditional process control or an automation plant at any level of levels 1 - 5 of the Purdue model.

[0125] The human user 155 can be a person acting as an agent of an enterprise that owns, manages, operates, or is otherwise associated with the NGPCAS 100. For example, the user 155 can be an enterprise configuration engineer, a system operator, an asset manager, a supply chain manager, an engineering or product manager, a technician, an installer, an authorized third party (e.g., a contractor), a business manager, etc. Generally, the human user 155 interacts with the NGPCAS 100 via a computing device operated by the user (e.g., a laptop computer, a tablet computer, a mobile computing device, an in-vehicle computing device, etc.), and an application, a web browser, or a similar executable program executes on the computing device to provide a user interface that can be operated by the human user 155 and a secure communication connection with the NGPCAS 100 via the VPN 158. For example, to interface with the NGPCAS 100 using his or her computing device, the human user 155 can utilize a specific MEEE 140 (e.g., an application downloaded from the computing fabric 102) that has been configured and authorized to execute at the computing device operated by the user, or the human user 155 can utilize a web browser that executes at the computing device operated by the user. As another example, the user 155 can be an automated user, such as an external application or service, e.g., an application or service executing on an external computing device or system. The automated user 155 may not provide any user interface for a human user, but can still establish a communication connection with the NGPCAS 100 via the VPN 158 to obtain or provide data and / or other information. Examples of the automated user 155 include third-party generated applications, external data sources (such as weather data sources, material management systems, etc.). In some cases, the automated user 155 can be a specific containerized component or MEEE 140 that has been configured and authorized to execute on a remote computing device or system.

[0126] In any case, regardless of whether user 155 is a human user or an automated user, user 155 securely accesses data and / or other information at NGPCAS 100 by utilizing an API (Application Programming Interface) 160 (via VPN 158 authenticated by user 155). In an example specific implementation, user 155 may utilize different APIs 160 to access different containerized components / MEEE / particles 140 and physical components 135 / 138 of computing structure 400. In an additional or alternative implementation, user 155 may utilize a single API 160 to access NGPCAS 100, and API 160 may form communication connections with containerized components / MEEE / particles 140 and physical components 135 / 138 within NGPCAS 100 as needed to obtain or provide the required data and / or information to / from user 155. For example, one or more of the APIs 160 themselves may be containerized components / MEEE / particles 140 of computing structure 102.

[0127] Figure 1A The specific user 155 of interest shown separately in is the architecture provider / manager 161 of NGPCAS 100. Generally speaking, the architecture provider / manager 161 provides supervision, management, and support for NGPCAS 100 and optionally other systems 100 of the enterprise and / or one or more systems of other enterprises (e.g., the corresponding architecture, hardware, and software resources of the systems, etc.). For example, the architecture provider / manager 161 may be within the scope of the provider of system 100. The architecture provider / manager 161 may have exclusive access rights to a set of applications and services that can be created, configured, and / or executed by the provider and / or manager 161 of NGPCAS 100 (e.g., in one implementation, it may be a subset of the entire set of containerized components / MEEE / particles 140 provided by computing structure 102). In a sense, the architecture provider / manager 161 supervises and manages the architecture platform resources utilized by one or more NGPCAS 100s via this set of applications and services, and thus, can generally perform a wider range of logical functions, such as engineering across various enterprise systems; providing an application / service "store" including a library of various applications and / or services, which the architecture provider / manager 161 can configure and distribute instances of these applications and / or services to NGPCAS 100 for its use; distributing and / or reallocating system resources between different physical locations; and so on. Each application or service created, configured, and utilized by the architecture provider / manager 161 may be implemented by one or more containerized components / MEEE / particles 140. Additionally, as Figure 1AAs shown, the architecture provider / manager 161 (whether a human user or an application or service executing on a remote computing device) can authenticate to the VPN 162 and can securely read and / or write data and / or other information, send instructions, and / or otherwise interface with various other containerized components / MEEE / particles 140 and physical components 135 / 138 of the NGPCAS 100 using one or more APIs 165. For example, one or more of the APIs 165 can itself be a containerized component / MEEE / particle 140 of the computing fabric 102.

[0128] In one embodiment, different subsets of the containerized components / MEEE / particles 140 can communicate via respective VPNs 162 with specific physical components 135 / 138, specific locations 115, a specific set of multiple locations, the entirety of all physical locations of an enterprise, or the corresponding physical components and / or corresponding physical locations of multiple different enterprises. For example, the containerized components / MEEE / particles 140 exclusively utilized by the architecture provider / manager 161 can be communicatively connected via a provider-specific VPN 162 different from the VPNs utilized by other containerized components / MEEE / particles 140 of the enterprise to the other containerized components / MEEE / particles 140 and / or physical components 135 / 138 of the enterprise to communicate with the physical components 135 / 138 at enterprise locations. As another example, the containerized components / MEEE / particles 140 provided by the architecture provider / manager 161 can communicate with the containerized components / MEEE / particles 140 and physical components 135 / 138 of a first enterprise using a first enterprise-specific VPN 162 and can communicate with the containerized components / MEEE / particles 140 and physical components 135 / 138 of a second enterprise (not shown) using a different, mutually exclusive enterprise-specific VPN. Thus, the architecture provider / manager 161 is able to securely and independently supervise and manage the respective resources of individual enterprises and / or different parts of different enterprises in a highly secure manner. In fact, by using one or more of the VPN technologies described herein either individually or in combination, the security of the NGPCAS 100 (and in some cases, multiple NGPCAS 100s supported by the architecture provider / manager 161) can be customized according to desire or need.

[0129] Thus, based on the above discussion, the containerized components / MEEE / particles 140 provided by the computing structure 102 of the NGPCAS 100 include the runtime logic functionality (e.g., control and automation logic, data acquisition, etc.) typically implemented by traditional process control and automation systems at levels 1 and 2 of the Purdue model. The containerized components / MEEE / particles 140 also include other logic functions related to the runtime logic and typically implemented by traditional process control and automation systems at levels 2 and 3 of the Purdue model, such as: system and component deployment; engineering; configuration; provisioning; commissioning; security of systems, devices, applications / services, and users; security logic and systems; networking; monitoring; analysis; maintenance and diagnostics of industrial processes and equipment / assets; simulation; testing; detection and repair / restoration of faults and performance degradation; operator interfaces; redundancy, backup, and other functionality related to the availability of the system 100 and its components and devices; historical recording of data; compliance; management of manufacturing or production workflows, execution, and operations; and so on. In addition, the containerized components / MEEE / particles 140 may include logic functions typically provided in traditional process control systems at the higher levels 4-5 of the Purdue model, such as enterprise resource planning, production scheduling, material usage, transportation, inventory levels, and other enterprise-level functions. In addition, such containerized components / MEEE / particles 140 may include logic functionality introduced into the computing structure 102 via a third party, such as applications and / or services that have been created by a third party and approved and authorized by the enterprise for utilization within the NGPCAS 100.

[0130] In addition, the collection of containerized components / MEEE / particles 140 provided by the computing structure 102 may include containerized components / MEEE / particles 140 of the network layer ( Figure 1A not shown in) of the computing structure 102, where such containerized components provide lower-level logic functionality that can be utilized by or with respect to other containerized components / MEEE / particles 140 as needed. Such lower-level logic functionality may include, for example, a collection of APIs 160, 165 used by the user 155 to interface with the various containerized components / MEEE / particles 140 and physical components 135 / 138 of the NGPCAS 100; computing functionality (e.g., for assigning and reassigning various containerized components to computing structure nodes Ny and / or data center clusters Cx, which is discussed in more detail elsewhere in this document); storage functionality (such as managing and allocating storage areas for working data associated with the execution of containerized components); networking functionality (e.g., for data and information delivery between various containerized components, its mechanisms, timing, etc.); that can be used by applications in the application layer of the computing structure 102 ( Figure 1AOther services utilized by the containerized component / MEEE / particle 140 (e.g., discovery, security, encryption, certificate authority, key management, authentication, time synchronization, service location, console support, life cycle management, etc.) executed at (not shown in the figure); and so on.

[0131] In addition, the set of containerized components / MEEE / particles 140 provided by the computing architecture 102 may also include lower-level logic functionality (such as computing, utilities, primitives, etc.) that can be utilized by the containerized components / MEEE / particles 140 at the application layer and network layer of the computing architecture 102. Examples of such functionality include computing functions (e.g., data aggregation and / or manipulation, such as average, maximum, minimum, etc.); more complex computations or algorithms (e.g., principal component analysis (PCA), partial least squares (PLS) prediction, and other types of statistical computations and / or analyses); and process control-specific or automation-specific computations (e.g., function blocks, shadow blocks, control module operations, etc.); and so on.

[0132] In addition, Figure 1A Location n 118 is shown as including a backup control system 168 that can partially or fully fail over to maintain the runtime operation of the process control system 100 at location n 118 when one or more remote parts of the system 100 (e.g., the transmission network 130, the computing architecture 102, etc.) are damaged, not communicating, or otherwise inoperable. For example, the backup control system 168 may include a traditional 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 executed on a computing platform local to location n 118.

[0133] Therefore, based on the above, the computing architecture 102 of the NGPCAS 100 provides process control and automation functionality as well as the relevant functionality required to be executed by different devices and systems dispersed across Purdue levels 1-5 in traditional process control systems, and also provides additional lower-level functionality available across the system (e.g., from networking and platform resource management to computing and primitives). In addition, advantageously, the NGPCAS 100 eliminates the need for DMZs at level 3.5 and other levels, and eliminates the need for firewalls, digital diodes, and other building security equipment and mechanisms used in traditional process control and automation systems, while providing a more secure system 100.

[0134] Specifically, as described above, any data or information transfer between two components of the NGPCAS 100 (e.g., two different containerized components / MEEE / particles 140, or a containerized component / MEEE / particle 140 and a physical component 125 / 135) can be achieved via a private session over a VPN (e.g., a VPN utilized by the physical locations where the computing structure 102 and the physical component 102 are located), via a private VPN utilized only by the endpoint components, and / or one or more other types of VPNs. Additionally, 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 proprietary VPN 158 / 162 established between the user 155 / 160 and the computing structure 102. Furthermore, all users may be required to be multi-factor authenticated before obtaining access to the system 100 via the APIs 162 / 165. In this way, system data is only exposed to non-public addresses (e.g., the addresses of components, computing structure nodes, etc.) via the VPN and authorized, authenticated entities. Applications may be exposed as websites or services such that the computing devices utilized by users access the system 100 via a "thin" client and do not have any system-related software executed thereon (possibly except for a thin client such as a portal application). Additionally, all applications may be containerized, including applications executed locally at the physical locations where the physical devices are located, and any system data may be statically encrypted.

[0135] Additionally, within the NGPCAS 100, all communications transmitted and received over the network 130 may be signed and encrypted, and the use of plaintext protocols may be prohibited. Furthermore, each NGPCAS 100 may have a single certification authority (e.g., which may be associated with an enterprise), and self-signed certificates and / or other forms of custom authentication may be prohibited.

[0136] Figure 1B A block diagram showing an example architecture of a next-generation process control and automation system ("NGPCAS") 100A, which has Figure 1A the basic components of the system 100, but is configured to support industrial and / or automation processes in which an installed or traditional distributed control system such as a control system is present. In this case, the NGPCAS 100A includes Figure 1A all the components of the system 100, but is connected to one or more factories or physical locations 115A and 118A where a traditional control system has been installed. As Figure 1BAs shown, positions 115A and 118A may have a distributed controller 170, such as a DeltaV controller, which is connected to various field devices 174, such as intelligent field devices, through various input / output (I / O) devices 172. The field devices may communicate with the I / O devices 172 using any desired or typical wired or wireless communication network. The field devices 174 may be, for example, 4-20ma, Fieldbus, Profibus, Canbus, APL, or any other communication protocol-compatible field device that communicates using any standard or known communication network or physical layer and communication protocol, including process control communication protocols (e.g., HART, fieldbus, etc.). Here, the process controller 170 may store and implement traditional control programs that can control the field devices 174 using, for example, function blocks, control blocks, etc.

[0137] However, as Figure 1B shown, the process controller 170 may be connected to a data aggregator and VPN gateway 180 installed at or located in the physical locations or plants 115A and 118A, and the VPN gateway 180 is connected to components within the computing structure 102 via a secure VPN link 130. The VPN gateway 180 operates as a data aggregator to collect data from the process controller 170, or in another embodiment, directly from the I / O devices 172 (shown by the dashed line at location 115A) to obtain, manage, transform, aggregate, and collect data from the field devices 174. The VPN gateway 180 also operates to encrypt the collected data via a VPN or other secure and encrypted communication link 130 and provide it to other components in the computing structure 102 (which use the data to perform control or other services). Regarding location 115A, the NGPCAS 100A may simply bypass the controller 170 to obtain data from the field devices 174 and I / O devices 172 in a manner similar to that shown by the I / O interfaces 125 and 128 and the field devices 135 and 138 Figure 1A . In this case, the controller 170 may be operated and programmed as a backup control system 168, for example Figure 1A shown, such that the controller 170 at location 115A takes over the control of the field devices 174 at location 115A in the event of a failover or backup.

[0138] On the other hand, as regarding Figure 1BAs shown in the physical location 118A, the controller 170 can operate as part of the computing structure 102 and has software modules (such as containers, etc.) associated with the computing structure 102 stored therein and operating therein. In this case, the controller 170 (at location 118A) is part of the computing structure 102, as shown by the computing structure box extending downward into the physical location 118A to include the controller 170. Figure 1B Thus, in this case, the computing structure 102 can include cloud-based computing devices and computing devices (e.g., the controller 170) located at physical plant locations outside the cloud. Additionally, in this case, the controller 170 at location 118A can operate in conjunction with other computer equipment within the computing structure 102 (such as computer equipment within the cloud environment) to perform control of the field device 174 at the physical location 118A.

[0139] In Figure 1B both examples, a data aggregator and a VPN gateway 180 are included such that the NGPCAS described herein can connect to and use installed legacy control system hardware (such as process controllers, field devices, I / O devices, etc.), which makes it easier and cheaper to install and use the NGPCAS described herein in a factory or other physical location where control hardware is already installed. Thus, the 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, although Figure 1B the legacy or installed control system is shown as a distributed control system, other legacy or installed control systems can be used in the same or a similar manner to support the NGPCAS.

[0140] Example NGPCAS Architecture including Digital Twin

[0141] As described above, in some specific implementations of the NGPCAS 100, the computing structure 102 can facilitate the use of "digital twins" of one or more of the local physical devices 105, 108. Figure 2A A system 200 representing a portion of an example NGPCAS 100 is shown, where multiple local physical devices 202A - 202D communicate with respective media converters 206A - 206D via respective physical interfaces 204A - 204D. For example, in Figure 2AIn this case, the Foundation Fieldbus device 202A is coupled to the media converter 206A via the Foundation Fieldbus interface 204A, and this media converter converts the signals received from the device 202A and the signals sent to this device between the Foundation Fieldbus protocol and an Ethernet-compatible or other suitable packet protocol. Similarly, the HART device 202B is coupled to the media converter 206B via the HART interface 204B, and this media converter converts the signals received from the device 202B and the signals sent to this device between the HART protocol and an Ethernet-compatible / packet protocol. As should be understood, other transmitters, sensors, and field devices may use other protocols. For example, the devices 202C and 202D can each be 4-20mA devices, and the media converters 206C and 206D can convert the signals from 4-20mA to an Ethernet-compatible / packet protocol (e.g., by packetizing the value of the 4-20mA signal and placing it on the network).

[0142] The Ethernet connections 208A - 208D couple the media converters 206A - 206D to the computing fabric 102 respectively, and specifically to the corresponding digital twins 210A - 210D of the local physical devices 202A - 202D. In an embodiment, the Ethernet connections 208A - 208D can each be directly connected to the computing fabric 102 (as Figure 2A shown), or perhaps more likely, the Ethernet connections 208A - 208D can each be connected to the computing fabric 102 via one or more network switches (not shown) (in an embodiment, including via one or more APL switches (not shown) and / or one or more local gateways (e.g., gateway 148)).

[0143] As the name implies, each of the digital twins 210A - 210D is a "virtual twin" of the local physical device, device, or group of devices to which it is coupled (and which it represents). That is, each digital twin simulates the electronic functions of one or more sensors, transmitters, actuators, etc., rather than physical functions such as sensing and actuation. The digital twin can correspond to a single device (e.g., a pressure transmitter, a temperature transmitter, an actuator, etc.), can correspond to a group of devices (e.g., a valve with upstream and downstream pressure transmitters and a valve position sensor), or can correspond to a device category (e.g., a mass flow device). Figure 2B This concept is described in more detail with respect to the Foundation Fieldbus local physical device 202A. As Figure 2BAs shown, the device 202A stores multiple parameters and variables 220A - 220J in its memory. Generally speaking, these parameters and variables can be addressed and / or retrieved and / or otherwise obtained by the process control system, and specifically can be used for the control algorithm that controls the device 202A. Of course, Fieldbus devices such as device 202A include one or more parameters and values from a generally known set of parameters and values, including measured values 220A, setpoint values 220B, upper and lower limits 220E, alarms 220D, one or more device states 220C, device ID 220H, device label 220I, device description 220G, scale 220F, and / or other information 220J such as range information, status information, etc. Other types of devices may additionally or alternatively include other parameters and values, and still other devices can only provide a single transmitter value (e.g., pressure, temperature, etc.). The digital twin 210A corresponding to the device 202A is implemented in the computing structure 102 (or in a non - computing structure implementation if required), and maintains an up - to - date copy of the data 220A - 220J stored in the device 202A. These copies are represented by reference numerals 220A' - 220J' in Figure 2B In addition, the digital twin 210A writes any setpoint values, other relevant data, and / or other commands 220A' - 220J' it receives to the device 202A.

[0144] Referring again to Figure 2A , each of the digital twins 210A - 210D is coupled via the computing structure 102 to function blocks, control modules, and other control algorithms that would typically receive data (and / or send data to) the devices 202A - 202D. For example, the AI / DI function blocks 212A - 212D can receive raw data from the digital twins 210A - 210D, and in the case where data would typically flow to the devices 202A - 202D, the AO / DO function blocks 214A, 214B can send data to the digital twins 210A, 210B, which is then transmitted back to the physical devices 202A, 202B. The control algorithm 216 operates on the data, receiving data from and sending data to the digital twins 210A - 210D, regardless of whether the digital twins 210A - 210D are physical devices or logical devices. In this way, the final hardware (e.g., physical devices 202A - 202D) is abstracted from the control algorithm 216 that operates the process plant via the digital twins 210A - 210D.

[0145] In the envisioned system implementing the computing fabric 102, the digital twins 210A - 210D can be implemented as microservices (or other micro - encapsulated execution environments) executing in joint or separate containers in an implementation. In one implementation, each of the digital twins 210A - 210D self - identifies within the system 100 using the unique network identifier or address of the corresponding physical device 202A - 202D that the digital twins 210A - 210D mirror. Thus, other containerized components of the computing fabric 102 can communicate with the intended physical devices 202A - 202D by using the unique identifiers of the physical devices and can remain unaware or oblivious to whether the entity with which they are communicating is the actual physical device 202A - 202D or its digital twin 210A - 210D. Thus, in a sense, each digital twin 210A - 210D can act as an agent for the corresponding physical device 202A - 202D that the digital twins 210A - 210D mirror within the system 100. In additional implementations, and in a manner similar to other containerized components / MEEE / particles 140 of the computing fabric 102, containerized digital twins can be nested according to, for example, the regions of a process plant, the type of equipment, the associated control modules, etc. Of course, AI, AO, and control algorithm modules can similarly be executed as containerized services or microservices.

[0146] In an implementation, the digital twins 210A - 210D can be automatically created according to the descriptions of the corresponding physical devices 202A - 202D that they represent.

[0147] Using the digital twin scheme as described herein and Figure 2A and Figure 2B shown can achieve multiple advantages. One advantage is that the digital twins 210A - 210D can be programmatically configured to prevent abnormal conditions in a process plant that might otherwise be caused by minor faults in the physical devices 202A - 202D. For example, if a measured value in a physical device becomes unreliable, the digital twins 210A - 210D can maintain the most recent value of the measured value (or provide an expected or simulated value) to maintain the stable and safe operation of the process plant, even in the absence of the actual measured value provided by the physical devices 202A - 202D. For the same reason, a device (especially a transmitter) that has failed, needs maintenance, or needs calibration can be replaced, repaired, or calibrated without necessarily shutting down the entire process, because the control algorithm 216 will not know that the device is absent or not sending accurate (or any) data.

[0148] Another potential advantage of using digital twins is that it can help with the ability to debug the systems described herein with less effort, cost, and time. By way of example and not limitation, a new factory (or a portion thereof) that is identical to an existing factory (or a portion thereof) can be instantiated almost entirely within a computing fabric, where the physical devices 202A - 202D are coupled thereto via Ethernet. If the system except for the physical devices 105, 108 is instantiated within the computing fabric 102, the entire process control factory (or at least the elements within the computing fabric 102) can be instantiated within minutes, and automatic discovery (e.g., using device tags, including hard - coded device tags) can determine which devices are connected to the various containerized applications, containerized services, microservices, MEEE, or particles instantiated within the computing fabric 102.

[0149] Another advantage of employing digital twins is that digital twins that are directly or not directly connected to a control algorithm (i.e., whether the control algorithm interfaces with the digital twin or directly with the physical devices (e.g., 202A - 202D) in the process factory) can be used to generate predictions about the future state of the process and / or physical devices. These future predictions can be generated using statistical models, mechanical models, or a combination of statistical and mechanical models. These models executed within the digital twin (e.g., as nested containerized components / MEEE / particles) can receive data from the physical devices and the control algorithm and provide an assessment of the control system (e.g., a control system tending towards an abnormal state), field devices (e.g., sensors that may appear to be failing or have failed), etc. This information can then be used to provide recommendations to operators, maintenance personnel, or other mitigating or remedial actions.

[0150] Another advantage conferred by using digital twins is the introduction of new soft - sensor data sources. Just as a group of physical devices (e.g., upstream and downstream sensors and valve - position sensors) can be represented by a single digital twin of a valve embodying these three elements, a group of measurements (collected by the corresponding physical devices) can be collected by the digital twin and used as a “soft sensor” giving an indirect measurement of another value. For example, the digital twin can receive values from four transmitters, namely two pressure transmitters that together provide a differential - pressure measurement, a pressure transmitter, and a temperature transmitter, and combine these values into a soft - sensor measurement of mass flow.

[0151] In addition, digital twins as described above can also be implemented in a traditional process - factory environment. For example, a local computing device can instantiate digital twins of the various physical devices in a process factory, even if the process factory implements traditional I / O and controllers. One such example arrangement is shown in Figure 2C in.

[0152] Example Multi-Enterprise NGPCAS Architecture

[0153] The Next Generation Process Control and Automation System (NGPCAS) 100 described in the foregoing part of the present disclosure provides many enterprise-level benefits for any particular enterprise that utilizes one or more NGPCAS 100s to implement industrial and / or automation processes. Examples of such benefits will be discussed herein with respect to Figure 3A and Figure 3B discussed.

[0154] Figure 3A shows a logical arrangement of an example multi-enterprise framework 300 including different enterprises 302, 304. Each enterprise 302, 304 utilizes its respective NGPCAS to implement industrial or automation processes (or, in some cases, multiple different industrial and / or automation processes) across physical device locations 312 / 314 and 316 / 318. In one embodiment, the respective NGPCASs of enterprises 302, 304 may be respective instances of NGPCAS 100, each instance being specifically configured for enterprises 302, 304. Thus, the present disclosure will refer to enterprises 302, 304 interchangeably as "enterprise NGPCAS 302, 304" or simply "NGPCAS 302, 304". NGPCAS 302, 304 respectively include enterprise-level computing structure functionality 320.1-320.2, which consists of containerized applications and / or services operating in the respective computing structures of NGPCAS 302, 304 to control process equipment and provide other process functionality to serve the processes implemented via NGPCAS 302, 304 (e.g., operation, maintenance, diagnosis, monitoring, etc.). For example, at least some of the functionality in enterprise-level computing structure functionality 320.1-320.2 may be provided by the architecture provider / manager 161 via subscription, download from an application or service store, etc. Enterprise-level computing structure functionality 320.1, 320.2 may be executed, for example, in a manner described with respect to Figure 1A the containerized components / MEEE / granules 140.

[0155] In some embodiments, the computing structure functionality 320.1, 320.2 is executed in different parts of a shared computing structure (e.g., at least some computing structure nodes are shared between enterprises 302, 304), where the security for the computing structure functionality 320.1, 320.2 is fixed to the respective enterprises 302, 304 using the security mechanisms of the present disclosure (e.g., even if the components of the computing structure functionality 320.1, 320.2 execute on the same computing structure node, such components operate as separate containerized components, where security and access are independently managed for each separate containerized component). At least a portion of the computing structure functionality 320.1, 320.2 may be provided by an authenticated user / computing device associated with the respective enterprises 302, 304 (e.g., Figure 1Aaccessed and operated by a human or automated user 155 and / or an architecture provider / manager 161).

[0156] Example Enterprise-Level Computing Functionality

[0157] Figure 3B illustrates example enterprise-level computing structure functionality 320 that can be included in computing structure functionality 320.1, 320.2 implemented by enterprises 302, 304 representative of Figure 3A The computing structure functionality 320 includes real-time process monitoring functionality ( Figure 3B 332 in ) across multiple NGPCASs of a single enterprise. Either of the enterprises 302, 304 can actually implement two, three, four, or more NGPCASs, each of which can operate across a corresponding set of one, two, three, four, or more physical device locations. Since the location for monitoring processes in the NGPCASs is not limited to the physical device locations where the processes are physically executed, a single user at a single computing device can perform remote monitoring of processes across two, three, four, or more NGPCASs (and / or across multiple physical device locations associated with each NGPCAS). For example, a single enterprise can operate multiple NGPCASs, which typically involves the operation of a specific type of boiler unit. A technician or operator familiar with the operation of the boiler unit can monitor the runtime operation of the boiler unit across multiple NGPCASs by receiving, via the computing structure, process information (such as device identifiers, device configuration information, process measurements, process setpoints, warnings, etc.) associated with the operation of each boiler unit included in the multiple NGPCASs at the technician's computing device. A certain degree of authorization can be provided to the technician (and / or the technician's computing device) to view, obtain, and act on the monitored process information (such as to send process commands, implement configuration changes, and / or provide other responses) to handle the operation of the boiler unit across multiple NGPCASs. Similar monitoring functionality can be provided for configuration engineers, operators, supply chain managers, and / or other personnel authorized to monitor at least a portion of the operation of each NGPCAS among the multiple NGPCASs.

[0158] Similarly, the NGPCAS architecture of the present disclosure enables real-time monitoring (334) and operational functionality (336) of the NGPCAS to be performed from multiple physical locations. That is, just as one operator or technician can remotely monitor the operation of multiple NGPCAS, various personnel at different physical locations can remotely monitor the operation of a single NGPCAS (or a single physical device location). In an embodiment, an operator or technician at an operator workstation located at a first, second, third, etc. physical device location or even at other locations not associated with any physical device location can monitor and perform operations associated with the runtime of an industrial process portion (e.g., equipment, equipment group, control loop, etc.) performed at different locations in the first, second, third, etc. physical device location. The workstation may be located at any physical location, such as at the physical device location where the monitored / operated process is performed, at different physical device locations, at a dedicated operation center, at a home office, in a vehicle, etc., and the workstation may be a fixed or mobile device. An operator or technician may, for example, receive various information associated with the operation of the process (e.g., equipment configuration information, operator displays, process status information, equipment status information and operating parameters, process measurements, set points, alarms, and / or other information) via a computing structure at an operator workstation. Figure 1A Components 135, 138 associated with the components) to monitor the runtime operation of the industrial process. The operator or technician can then modify or adjust various aspects of the operation of the process by sending commands from the workstation to modify various aspects of the process (for example, to advance steps in the process or modify control loops in the process, where the control loops themselves are potentially implemented in the form of containerized components at the same or different locations via computing structures). In addition, authorization to monitor any specific function of the NGPCAS (for example, monitoring a specific industrial process or part thereof, physical equipment location, equipment, equipment group, etc.) can be transferred on demand (for example, at the request of a user and / or another containerized component) or automatically between personnel located in various physical locations, and the physical location is not geographically limited to the physical location of the monitored function of the NGPCAS. For example, in some embodiments, authorization to monitor the operation of the NGPCAS or part thereof can be transferred between personnel when personnel change shifts, where the personnel who hand over monitoring access rights are not necessarily located in the same physical location as each other or are not necessarily located at the monitored NGPCAS or part thereof. This ability to transfer authorization for monitoring operations between physical locations can enable functionality for actively monitoring runtime process operations to "follow the sun," for example by moving monitoring of operations of an industrial process (or portions thereof) between multiple locations around the world over the course of a day, such that each respective location has monitoring and operating responsibilities during daylight hours at the respective location.

[0159] The NGPCAS architecture of the present disclosure also enables the control of the NGPCAS process or portions thereof (e.g., devices, groups of devices, control loops, etc.) (340) from any physical location. The configuration and execution of control loops can be implemented as containerized components in a location-agnostic NGPCAS computing fabric, without the need for local implementation at the physical device location of the controlled operation as in traditional process control architectures. Portions of the control system can be distributed among containerized components executing at the same physical device location, different physical device locations, and / or other physical locations not associated with the physical implementation of the process.

[0160] In fact, any containerized component (e.g., containerized services and applications) in the computing fabric can execute (338) at any physical location (e.g., at the physical device location to which the containerized component belongs, at a different physical device location, and / or at another physical location independent of any physical device implementing at least a portion of the process). Similarly, containerized components in the computing fabric can be instantiated from any physical location (342). A containerized component can be instantiated, for example, via a human and / or automated operation at a first physical location, while the instantiated containerized component runs or executes on a computing node (of the computing fabric) located at a second physical location. Additionally, the execution of containerized components can be transferred between various physical locations on demand or automatically (344, e.g., via Figure 4 an orchestration service 422). In some embodiments, the containerized components of NGPCAS move globally across various physical locations to place the execution of the containerized components adjacent to the monitoring / control / operation workstations serving NGPCAS at any given time (e.g., to "follow the sun" by executing containerized components at the respective locations during the daytime hours at each location). For example, a containerized component can be moved to execute multiple times at different physical locations each day to "follow the sun," such that it executes adjacent to the personnel providing daytime services to NGPCAS at any given time. Containerized components can also be moved between computing fabric nodes and / or physical locations for load management purposes, e.g., to avoid overloading the processing capacity of any particular computing fabric node or the communication bandwidth of any particular communication link in the computing fabric. Additionally, in the event of a failure of a computing fabric node or a portion thereof in the computing fabric, the execution of the containerized components can be moved, for example, by activating digital twin instances of the containerized components that perform operations on different computing fabric nodes and / or at different physical locations.

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

[0162] In some embodiments, the architecture provider / manager (e.g. Figure 1A 161) provides subscription-based access to process functionality (346), whereby an enterprise purchases specific process functionality at a price determined, for example, based on the quantity of functionality purchased, the number of instances of the purchased functionality running in the enterprise's NGPCAS computing structure, and / or the length of time the purchased process functionality operates in the enterprise's NGPCAS computing structure. A third party may similarly provide subscription-based or one-time purchase-based access to process functionality, thereby allowing a first enterprise, for example, to generate process functionality and distribute it to another or more enterprises to allow the other or more enterprises to run instances of the same process functionality via the containerized components and physical components of their respective NGPCAS for their own respective use. In order to support subscription-based and one-time purchase-based distribution of process functionality, the architecture provider / administrator may provide an application / service "store" that includes a library of various process applications and / or services that are available for purchase by enterprises (i.e., one-time purchases or subscriptions) for their own respective use. Furthermore, in some embodiments, the architecture provider / manager implements virtualization testing and simulation of any library of applications / services on the enterprise's NGPCAS to ensure that the purchased applications / services will run safely, appropriately, and efficiently on the enterprise's NGPCAS prior to actual implementation in the context of the enterprise's own process architecture.

[0163] See again Figure 3A According to the NGPCAS architecture, the multi-enterprise framework 300 enables architecture providers / managers (e.g., Figure 1A 161) is able to perform centralized management of upgrades (350) of applications / services utilized by enterprise NGPCAS 302, 304. Upgrades of applications / services are reflected in new instances of said applications / services executed in enterprise NGPCAS 302, 304, thus allowing each enterprise 302, 304 to automatically access the latest version of any process functionality provided to the enterprise 302, 304.

[0164] In addition to providing centralized management of application / service upgrades, the architecture provider / manager in the multi-enterprise framework 300 (e.g., Figure 1A 161) can provide a central monitoring point (352) for the operation of the computing structures of enterprise NGPCASs 302 and / or 304. The architecture provider / manager can monitor NGPCAS operations, for example, to implement fault handling or fail-safe measures, perform load balancing of NGPCAS functionality, and / or identify performance improvements for the same NGPCASs 302, 304 and / or for different NGPCASs of other enterprises.

[0165] Other enterprise-level benefits of the NGPCAS architecture of the present disclosure will be recognized from other parts of this specification.

[0166] Example Computing Structure Architecture

[0167] Relative to Figure 1A the computing structure 102 of the next-generation process control and automation system 100, Figure 4 FIG. shows a block diagram of an example architecture 400 of the computing structure 102. Of course, the example architecture 400 can be utilized in the computing structure and / or in process control and automation systems other than the computing structure 102 of NGPCAS 100. However, for the sake of facilitating the discussion herein and not for purposes of limitation, the architecture 400 is described below with reference to Figure 1A simultaneously. Additionally, for ease of reading, the architecture 400 of the computing structure 102 may be referred to interchangeably herein as the "computing structure architecture 400" or simply as the "computing structure 400".

[0168] Generally speaking, and as described below, the computing structure 400 utilizes a layered architecture in which the business logic of the computing structure 400 is abstracted from the physical computing platforms of the computing structure 400. For example, the computing structure 400 may utilize one or more techniques and / or features described in U.S. Patent Application No. 17 / 487,609, filed on September 28, 2021, 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 the sake of facilitating the discussion herein, the computing structure 400 is described with reference to Figure 1A the system 100 simultaneously; however, this is for illustrative purposes only and not limiting.

[0169] As Figure 4As shown, the computing fabric 400 is communicatively coupled to the field environment 120 via one or more networks 402. For example, in an implementation where the computing fabric 102 of the NGPCAS 100 utilizes the computing fabric architecture 400, one or more networks 402 may be included in Figure 1A the network 130. The network 402 generally includes high-bandwidth data or communication links that support packet delivery to and from the computing 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, etc.) and / or private networks. At least a portion of one or more networks 402 may include an Advanced Physical Layer (APL) or some other type of physical or other protocol layer that supports Ethernet and / or other packet-based protocols.

[0170] Physical Layer of the Computing Structure

[0171] As Figure 4 further shown, an example architecture of the computing fabric 400 includes a computing platform 405 that supports the higher-level hardware and software resources of the computing fabric 400. Thus, the computing platform 405 may be interchangeably referred to herein as the "physical layer 405" of the computing fabric 400 because it includes physical processors, processor cores, memory, and network interfaces. The computing platform or physical layer 405 of the computing fabric 400 includes a set of data center clusters C1, C2, …, Cn (which are generally referred to herein as data center clusters Cx for readability purposes), each data center cluster including a corresponding plurality of computing fabric nodes N1, N2, …, Nn (which are generally referred to herein as nodes Ny for readability purposes), where the corresponding nodes 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 corresponding processors and / or processor cores, one or more corresponding memories, and corresponding network resources, such as one or more corresponding physical communication interfaces that communicatively couple the node Ny to one or more other nodes Ny of the data cluster Cx. For example, the node Ny may be implemented on a single server, or may be implemented on a group or cluster of servers.

[0172] Each cluster Cx includes a plurality of nodes Ny that are communicatively interconnected with each other. Additionally, different clusters Cx may be physically located at the same or different physical locations (e.g., at different locations 115, 118 of the physical devices 105, 108 of the NGPCAS 100, and / or at one or more other locations where the physical devices of the system 100 are not provided). A particular cluster Cx may be implemented at only 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 the computing platform 405.

[0173] Note that although the physical layer 405 associated with the computing fabric 400 has been described above as being implemented by using the 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, such as those that execute on a computing resource platform such as a cloud computing system.

[0174] Software-Defined Network Layer of the Computing Structure

[0175] An example architecture of computing fabric 400 further includes a software-defined (SD) network layer 410 that interfaces the physical layer 405 of computing fabric 400 with the software-defined application layer 412 of computing fabric 400. Thus, the software-defined network layer 410 may be interchangeably referred to herein as the “operating system (OS) 410” of computing fabric 400. Generally, the OS 410 of computing fabric 400 may assign, designate, or allocate various computing fabric nodes Ny to perform corresponding roles or functions in support of computing fabric 400, such as computing (e.g., via the respective processors and / or processing cores of the nodes) or data storage (e.g., via the respective memories of the nodes). The computing fabric nodes Ny that are assigned, designated, or allocated to perform the computing activities of computing fabric 400 are referred to herein as “compute nodes” or “computing nodes,” respectively. Similarly, the computing fabric nodes Ny that are assigned, designated, or allocated to perform the storage activities of computing fabric 400 are referred to herein as “storage nodes,” respectively. A single node Ny may be used only as a compute node, only as a storage node, or as both a compute node and a storage node, and the role of each individual node Ny may change dynamically over time, e.g., as directed by OS 410. Advantageously, computing platform 405 is scalable such that individual nodes Ny and / or individual clusters Cx can be easily added, removed, swapped out, etc. as needed to support computing fabric 400 and, in particular, in accordance with other higher-level requirements of computing fabric 400. For example, different nodes Ny of computing 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 at different physical locations 115, 118 of NGPCAS100 as needed.

[0176] The operating system 410 of the computing fabric 400 executes on the computing platform 405 and, in one embodiment, can be built on any suitable general-purpose hyperconverged infrastructure (HCI) operating system (OS), such as Microsoft AzureStack, VMWare HCI, Nutanix AOS, Kubernetes Orchestration, including Linux Containers (LXC / LXD), Docker Containers, Kata Containers, etc. Thus, the OS 410 provides a set of computing, storage, and networking support services in a manner somewhat similar to a general-purpose HCI operating system. However, contrary to and advantageously over general-purpose HCI OSs, in the computing fabric 400 of the next-generation process control and automation system 100, the OS support services respond dynamically to the logical or abstract process control or automation system and other software components provided by the software-defined application layer 412 of the computing fabric 400. That is, as the performance, resource requirements, and configuration of the various application layer services, subsystems, and other software components of the application layer 412 change dynamically (and / or are dynamically predicted to change by services within the application layer 412), the operating system 410 can automatically and reactively adjust and / or manage the use of the hardware and / or software resources of the physical layer 405 to support the needs and requirements of the application layer 412 for computing, storage, and networking and for other functionality related to industrial process control and automation. To this end, the computing fabric operating system 410 can include a set of support services, including, for example, software-defined (SD) computing services 415, SD storage services 418, SD networking services 420, SD orchestration services 422 (also 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, the process control and / or automation-specific SD OS support services and / or functions 425 can include computing fabric individual resource and / or resource group management services that manage the individual resources and / or resource groupings provided by the software-defined network layer 410 and / or by the physical layer 405 of the computing fabric 400, such as virtual machines, containers, networks, network security groups, clusters, servers, etc.Thus, in one embodiment, the operating system 410 of the computing fabric 400 includes a general HCI operating system platform (e.g., Microsoft Azure Stack, VMWare HCI, etc.) that has been specifically customized to include SD computing services 415, SD storage services 418, SD networking services 420, SD orchestration services 422, and other process control and / or automation SDOS support services and / or functions 425, where the set of SD support services 415-425 automatically respond to and specifically support the application layer software components 412 of the computing fabric 400, and the application layer software components include process control and / or automation specific applications and services as previously discussed.

[0177] Interface between the Software-Defined Network Layer and the Application Layer of the Computing Structure

[0178] Specifically, when the computing fabric operating system 410 manages the allocation of hardware and software resources of node Ny of the computing platform 405 via the SD OS support services 415-425, the SD OS support services 415-425 also serve as interface services between the OS 410 and higher-level services, subsystems, and other software components of the application layer 412 of the computing fabric 400, and / or may provide a framework for these higher-level services, subsystems, and other software components of the application layer 412. Thus, the software components of the computing fabric application layer 412 can interface with the OS 410 (and in some cases, specifically with one or more of the SD-specific support services 415, 418, 420, 422, 425 provided by the OS 410) via a set of application programming interfaces (APIs) 430, via the HCI adapter 430 (also referred to herein as the "HCI adapter layer" 428) and another set of APIs 432, or directly ( Figure 4 not shown in the figure). The HCI adapter layer 430 enables the computing fabric application layer 412 to access the SD OS support services 415, 418, 420, 422, 425 while remaining agnostic to the details of the general HCI operating system (e.g., Microsoft Azure Stack, VMWare HCI, etc.) that has been customized with such SD-specific services 415-425 to form the OS 410. Thus, the HCI adapter 430 converts or translates the APIs 428 utilized by the computing fabric application layer 412 into a set of APIs 432 that are understood by or otherwise known to or compatible with the customized or adapted general HC operating system 410 of the computing fabric 400.

[0179] Thus, unlike a general hierarchical IT (Information Technology) system architecture in which business logic applications are abstracted from hardware and software computing platforms and the management of computing platform resources is mainly managed and designed by human IT administrators, the architecture of computing structure 400 not only abstracts higher-level business logic services, subsystems, and other software components of application layer 412 from hardware and software computing platform 405, but also enables 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 of physical layer 405 and software-defined network layer 410, for example, via API 428 and SD OS support services 415, 418, 420, 422, 425, without any manual intervention or guidance. Specifically and advantageously, the management of resources of physical layer 405 and software-defined network layer 410 dynamically responds to changes in the configuration and requirements of these higher-level SD services, subsystems, and other software components of application layer 412, and specifically, with respect to the specific requirements, boundaries, and limitations of industrial process control and automation systems, such as timing, synchronization, and / or other control or automation-specific constraints.

[0180] Containers and Other Types of Micro-Encapsulated Execution Environments

[0181] As Figure 4 shown, industrial process control, automation, and other associated business logic are performed by higher-level software-defined services, subsystems, and other software components 435 - 448 provided by application layer 412. For ease of reading in this document, the present disclosure classifies 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 computing structure 400. In one embodiment, a set of software-defined application layer components 435 - 442 (and optionally at least some third-party services 448 executed at application layer 412) may together form a logical process control or automation system 445 (also interchangeably referred to herein as a "virtual" process control or automation system 445), which executes in conjunction with physical components 135, 138 of NGPCAS100 to control an industrial (e.g., process control or automation) process. For example, Figure 1A the logical process control or automation system 145 may include Figure 4 the logical process control system 445. Generally, application layer software components may be provided by an enterprise (e.g., via architecture provider / manager 160), a user 155 acting as an agent of or associated with enterprise 155, a third party, and / or other sources.

[0182] The application layer software components 435-448 of the application layer 412 can execute in a container and / or in other suitable types of micro-encapsulated execution environments (MEEEs) or granules, such as an instantiated software component (ISC). For example, an ISC can be a container configured with an instance of a specific application layer software component 435-448 to form a configuration container, container image, or other type of micro-encapsulated execution environment or granule for the specific application layer software component 435-448, and the container image of the specific application layer software component 435-448 can be instantiated to execute as a specific instantiated MEEE or ISC on a specific computing fabric node Ny. In other words, a configuration container can be an instance of an application layer software component 435-448 configured into a corresponding container or other type of micro-encapsulated execution environment or granule.

[0183] Generally, containerized or micro-encapsulated software components or MEEEs / granules (e.g., at the application layer 412, HCI adapter layer 430, and software-defined network layer 410) are included in the set of containerized / micro-encapsulated components 140 of the NGPCAS 100 and are thus isolated from other containerized / micro-encapsulated services and applications (e.g., other containerized / micro-encapsulated components 140) executing on the same node Ny. Accordingly, the terms "configuration container", "container image", and "containerized component" are used interchangeably herein and are generally and generically used herein, for purposes of discussion and not limitation, to refer to any one or more suitable types of instantiated micro-encapsulated execution environments or granules, such as software containers, virtual machines, software agents, scripts, functions, calls, roles (e.g., lightweight processes, such as Erlang, Scala, Akka, etc.), unikernels (e.g., a machine image that runs on bare metal and includes all components necessary to execute 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.

[0184] Various MEEEs or particles can be configured to perform (e.g., when instantiated) various operations ranging from broad to detailed within the NGPCAS100. For illustrative purposes using examples, a control routine can include multiple control modules that operate cooperatively to execute the control routine, the control modules can each include multiple functional blocks and other types of blocks that operate cooperatively to implement the control module, and the functional blocks can each include multiple particle operations that operate cooperatively to execute the functional block. Thus, in one specific implementation of this example, a single MEEE can be configured to perform (e.g., when instantiated) the entire control routine. In another specific implementation of this example, each MEEE in a group of MEEEs can be separately configured to perform (e.g., when instantiated) a different control module or a portion of the control routine, and the group of instantiated MEEEs can operate cooperatively so as to perform the control routine as a group as a whole. In fact, in some specific implementations, a second group of MEEEs can be separately configured to perform (e.g., when instantiated) different particle operations or portions of control modules (such as input functional blocks, error detection functional blocks, control functional blocks, logic functional blocks, scripts, output functional blocks, etc.), and the second group of MEEEs can operate cooperatively when instantiated so as to perform the control module as a group as a whole. In other specific implementations, a single MEEE can be configured to perform (e.g., when instantiated) as a process controller, a process control subsystem, a unit, a zone, or even an entire process control system 445.

[0185] In another example, a single MEEE can be configured to perform (e.g., when instantiated) an entire complex data analysis routine for the entire NGPCAS100. Alternatively, each MEEE in a group of MEEEs can be separately configured to perform (e.g., when instantiated) different simple data analysis routines (or some other corresponding portions of the complex data analysis routine), and the cooperative execution of the group of instantiated MEEEs can thus result in the execution of the entire complex data analysis routine. In some specific implementations, another group of MEEEs can cooperatively execute the corresponding particle actions or operations of the simple data analysis routine (or other types of corresponding particle actions of the simple data analysis routine) when instantiated, thereby resulting in the execution of the entire simple analysis routine (or the entire portion of the complex data analysis routine, as the case may be). For example, particle analysis actions or operations can include computational functions (e.g., data aggregation and / or manipulation such as mean, maximum, minimum, etc.), simple data analysis routines can include more complex statistical calculations or algorithms (e.g., principal component analysis (PCA), partial least squares (PLS) prediction, and other types of statistical calculations and / or analysis), and complex data analysis routines can include combinations of statistical calculations or algorithms and, in some cases, combinations with other types of non-statistical calculations or algorithms.

[0186] Generally, MEEEs, particles, or provisioning containers may be provided by an enterprise (e.g., via an infrastructure provider / manager 160, via an application / service store, out-of-the-box, etc.), a user 155 acting as an agent for or associated with an enterprise 155, a third party, and / or other sources. Various instantiated MEEEs may be assigned to execute on various computing nodes Ny of the system 400, which may be located in different physical and / or geographical locations. Additionally, an instantiated MEEE may be dynamically migrated from executing at one node to executing at another node, for example, based on detected and / or predicted resource usage, jurisdictional requirements and / or regulations, and / or other criteria. Further, an instantiated MEEE may be allocated, pinned, dynamically assigned, and / or dynamically migrated, for example, via the SD computing service 415 to execute on the corresponding nodes Ny and / or data center clusters Cx. The SD computing service 415 may dynamically change, update, maintain, and / or otherwise manage the container images and their corresponding assignments to the computing nodes Ny as needed or when needed, for example, for load balancing across the computing nodes Ny, for scheduling maintenance of the computing nodes Ny and / or their physical components, in response to detected and / or predicted resource usage and / or performance issues, to support the scaling out or in of the logic process control or automation system 445, to support the scaling out or in of the computing platform 405, based on jurisdictional regulations and / or requirements, etc. Thus, the NGPCAS 100 may be considered a dynamic, highly distributed collection of MEEEs or a dynamic grid of MEEEs, where MEEEs may be located or provisioned across multiple physical and / or geographical locations, and where one or more MEEEs may be dynamically reassigned and migrated to another node and / or another physical and / or geographical location during the runtime operation of the NGPCAS 100 while maintaining the execution of the runtime operation of the NGPCAS 100. Additionally, the components forming the MEEE dynamic grid for a particular application, control routine, analysis routine, etc. may be individually, in sets or groups, or together (if needed) dynamically moved or migrated or reassigned to other hardware in the computing fabric without affecting or interrupting the operation of the application, routine, etc. Thus, the individual components of the MEEE dynamic grid for a particular application or use may be managed separately in the computing fabric from other components of the same application or use.

[0187] Within the computing fabric 400, some configuration containers, granules, or instantiated MEEEs may be allocated or assigned by the SD computing service 415 to corresponding computing nodes Ny based on the dynamically changing configuration, performance, and requirements of the logic process control or automation system 445 and dynamically reassigned to different computing nodes Ny. In some cases, a configuration container may be assigned (and reassigned) to be executed by a specific processor or specific processor core of an SD computing node Ny. However, some configuration containers may be fixed to corresponding SD computing nodes Ny (e.g., by the SD computing service 415, by configuration, by the user, etc.) and not be dynamically reassigned by the SD computing service 415 due to conditions that occur dynamically. That is, a fixed configuration container may be executed on the computing node Ny to which the configuration container is fixed until the configuration container is unfixed from the computing node Ny, e.g., regardless of the dynamic conditions of the logic process control or automation system 445 (possibly except for the failure of the computing node Ny to which the configuration container is fixed). In other words, the software-defined network layer 410 may restrict the utilization of a fixed configuration container to only the hardware and / or software resources to which it is fixed, and when the configuration container is unfixed, the SD network layer 410 removes this restriction. If desired, a configuration container may additionally or alternatively be fixed to other physical or logical components of the computing fabric 400. For example, a configuration container may be fixed to another configuration container, a specific data cluster, a specific processing resource (e.g., a specific physical processor or specific physical processor core of a computing node Ny), a physical rack or a portion of a physical rack served by a specific power supply (where the physical rack physically houses the hardware of one or more computing fabric nodes), etc.

[0188] In addition, configured containers, instantiated MEEEs, or particles can be nested within other configured containers and / or attached to other configured containers, which is particularly useful in configuring and organizing a logic process control or automation system 445. For example, when a particular process control subsystem 438 provides a particular set of control services 435 and / or other services 440, the configured containers for each of the provided services 435, 440 in that particular set can be nested within the configured container of that particular process control subsystem 438. As another example, multiple control routine and / or control module configured containers can be nested within a particular controller service 435, and the particular controller service 435 can be nested within a particular process control subsystem 438. As yet another example, a controller or control service 435 can be configured with one or more process control module services 435, parameters, and values (such as input and output tags, reference values, etc.) of an industrial process plant 10 to form a configured or programmed controller service. The controller or control service 435 can be functionally equivalent to a traditional dedicated hardware controller device as understood in the Purdue model, or the controller service 435 can be functionally equivalent to a control routine or control module configured into and executed by a traditional dedicated hardware controller device. A container can be configured with an instance of a configured controller service to form a container image or instance of the configured controller service, which, when so configured, can execute, for example, by using configured control module containers, tags, reference values, etc., to perform a particular set of configured process control logic. Multiple instances or container images of a configured controller service (or other configured applications and services) can be instantiated and executed by a computing structure 400.

[0189] As yet another example, containers, particles, or instantiated MEEEs within the SD application layer 412 can be used to represent and / or logically organize the physical and / or logical areas, regions, and components of the NGPCAS 100. For example, cells, regions, etc. can be represented by corresponding configured containers, and the configured containers for the physical and / or logical components corresponding to each cell, region, etc. can be nested within their respective configured organizing containers and / or attached to their respective configured organizing containers. Thus, within the computing structure 400, a configured control routine container can be nested within or attached to a configured controller container, and the configured controller container can be nested within or attached to another configured container, such as a container that has been configured for a depropanizer tower.

[0190] For clarity and for the purposes of discussion herein, the term "container" is used herein generally to 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, such as a container or other type of micro-encapsulated execution environment that has been configured to include an instance of a corresponding controller service, subsystem, or other service or application provided by the application layer 412 of the computing fabric 400.

[0191] In any case, and in a manner similar to that discussed for the computing resources of the computing platform 405, the containerized / micro-encapsulated components 140 of the system 100 can be dynamically allocated and / or assigned, pinned and / or nested to various computing fabric storage nodes Ny, for example via the SD storage service 418, to support the various storage requirements of the logic process control or automation system 445. For example, the SD storage service 418 can oversee and manage the logical storage resources utilized by the configured containers of the logic process control or automation system 445 across the various physical hardware memory resources of one or more nodes Ny. For example, the configured containers and the memory required for their operation (e.g., random access memory, etc.) can be stored on a particular SD storage node Ny or on a particular memory device or space of an SD storage node Ny. Additionally, if needed, some of the containerized components / MEEEs / granules 140 can be pinned to the corresponding SD storage node Ny and / or pinned to a particular memory device or memory region of the SD storage node Ny. The SD storage service 418 can alter, update, or otherwise manage one or more physical hardware memories of the computing platform 405 to support the logical storage resources of the computing fabric 400 when needed and as needed, such as due to disk or other types of errors, for scheduling maintenance, due to the addition / expansion of available physical memory in the computing platform 405, etc.

[0192] Still similarly, the SD networking service 420 can supervise and manage the logical or virtual network utilized by the containerized components / MEEE / particles 140 of the logical process control or automation system 445 and / or by other containerized components / MEEE / particles 140, which can be implemented by the SD networking service 420 across the computing fabric nodes Ny. For example, the SD networking service 420 can supervise and manage the networking and hardware resources of the computing platform 405 to support the logical network functionality included in the logical process control system 445, such as virtual interfaces, virtual switches, virtual private networks, virtual firewall rules, etc., and support the required networking between various configuration containers or container images executed on the computing fabric 400. In addition, when the logical process control system 445 serves the physical components 135, 138 of the NGPCAS 100, the timing and synchronization of the containerized components / MEEE / particles 140 of the computing fabric 400, the physical components 135, 138 of the field environment 120, and the networking therebetween are crucial because missed and / or lost messages or communications may cause the industrial or physical process to become uncontrolled, which in turn may lead to catastrophic consequences such as spills, gas leaks, explosions, equipment loss, and in some cases loss of human life. Fortunately, the SD networking service 420 responds to the critical process I / O timing and synchronization of the computing fabric 400 such that communications (and specifically, communications to / from the control service 435) can be reliably delivered in a timely and deterministic manner. For example, the SD networking service 420 can support time synchronization within 1 millisecond for the data center cluster Cx to ensure the required synchronization between the process control service 435, the process control subsystem 438, the packet router / switch service 442, and other software-defined services 440, 448 of the software-defined application layer 412.

[0193] In addition to the SD compute service 415, the SD storage service 418, and the SD networking service 420, the computing fabric operating system 410 can also provide other OS support services 425 that can be accessed via a set of APIs 428, 432 and can be utilized or accessed by the application layer 412 to support the logical process control system 445 and other containerized components / MEEE / particles 140 of the application layer 412 of the computing fabric 400. For example, the other OS services 425 can include life cycle 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 (none of which are shown in Figure 4 ). In some embodiments of the computing fabric 400, one or more support services can be executed at the application layer 412, such as other software-defined services 440, rather than as OS support services 425 at the software-defined network layer 410.

[0194] In fact, in one embodiment, one or more of the software-defined components 415-425 and 452-460 of the software-defined network layer 410 are implemented as corresponding configuration containers or container images of the computing fabric 400. That is, one or more services and other functionality provided at the software-defined network layer 410 of the computing fabric 400 (and in some specific implementations, all services and functionality provided at the software-defined network layer 410) can be implemented as corresponding containerized components / MEEE / particles 140 of the NGPCAS 100. Thus, in a manner similar to that discussed herein for the containerized components / MEEE / particles 140 of the application layer 412, the containerized components / MEEE / particles 140 of the software-defined network layer 410 can be uniquely identified within the NGPCAS 100 by corresponding addresses, communicatively connected to other containerized components / MEEE / particles 140 of the NGPCAS 100 and optionally connected to the physical components 135, 138 of the NGPCAS 100, and started and removed as needed or when needed, etc.

[0195] Application Layer of the Computing Structure

[0196] Turning now more specifically to the application layer 412 of the computing fabric 400, and as Figure 4 shown, the application layer software components 412 include a set of software-defined services or applications 435 (such as software-defined process control or automation-related services 435) and a set of subsystems 438 of the NGPCAS 100 (such as subsystems of software-defined process control or automation), and optionally may 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 specific implementations of the computing 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 computing fabric 400, and users may develop, generate, install, and manage the third-party services 448 at the SD application layer 412 via the software development kit. Generally speaking, the services and applications 435-448 provided at the application layer 412 form a logical process control system 445 and provide related functionality. Generally speaking, the applications 435-448 may be provided by the system 100 itself, third parties, vendors, end users 155, and / or other sources. For example, one or more of the applications 435-448 may be built on the APIs 160, 165 provided by the computing fabric 102, and / or one or more of the applications 435-558 may be encapsulated as containers and distributed by the orchestrator 422.

[0197] Each different control service 435 can be configured with desired parameters, values, etc., and optionally configured with other control services 435; each instance of the configured control service 435 can execute in its own container; and each configured container can be assigned (or pinned) to execute on a corresponding computing node Ny and / or cluster Cx. Thus, each configured control service 435 can be a logical or software-defined control entity that can be functionally configured and can execute in a manner similar to a traditional hardware-implemented process controller device, control module, process control function block, etc. However, unlike traditional hardware-implemented process controller devices, traditional control modules, and traditional control function blocks, and advantageously, the computing fabric 400 can easily replicate multiple instances of the same configured control service 435 for various purposes, such as performance, fault tolerance, recovery, etc. For example, a controller service (executing in its own container) can be configured to execute a control module service (executing in its own container), and the control module service can be configured to execute a set of control function block services (where each one executes in its own container and where each one can be configured with corresponding parameters, values, etc.). Thus, the set of configured containers corresponding to the set of configured control function block services can (although not necessarily) be nested within the configured control module service container, and the configured control module service container can be nested within the configured controller service container. The set of configured containers corresponding to the set of configured function block services can be assigned to execute 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 can be moved to execute on different processor cores, different processors, or even different computing fabric nodes to attempt to rebalance the load; however, the moved function block service containers will still be nested under the configured control module service container and will execute accordingly.

[0198] In addition to the control service 435, other types of application layer services 440 related to industrial process control may be provided by the application layer 412, such as but not limited to operator display and handover, diagnosis, analysis, security routines, reporting, data history, service configuration, container configuration, transmitting information to external or other systems, enterprise-level applications, process control and / or automation resource and / or resource group management, etc. For example, the process control and / or automation resource group management service may allow the user 155 to group and / or isolate various resources based on the NGPCAS 100 and / or other process control or automation considerations. For example, resource groups can be formed as follows: based on physical characteristics, such as site or physical location, group of sites / physical locations, subset of sites or physical locations, geographical region, etc.; based on logical characteristics, such as category, container and / or container type, control strategy, capability, timing, performance, user characteristics, etc.; based on functionality, such as storage items, networking items, etc.; and / or based on other types of grouping corresponding to the NGPCAS 100 and / or combinations thereof. Generally speaking, the functionality or business logic related to controlling an industrial process, supporting the NGPCAS 100, and / or any process control or automation system related to the NGPCAS 100 executed during the runtime of the NGPCAS 100 can be logically implemented in the computing structure 400 as the corresponding application layer services 435, 440 executed in the corresponding containers. For example, any one or more of the enterprise-level computing structure functionality 320 can be implemented in the corresponding containers or implemented as containerized services. In addition, when the business logic of the services 435, 440 and / or the receiving physical components 135 / 138 require it, any one of the containerized services 435, 440 can be communicatively connected to the corresponding physical components 135 / 138 disposed at the physical location of the NGPCAS 100, for example, via the SD network layer 410. In addition, any one of the containerized services 435, 440 can be communicatively connected to any other containerized services 435, 440 to transfer data and / or information between them when their respective business logics require it.

[0199] In a similar manner, each different subsystem 438 of the application layer 412 of the computing structure 400 can be provided by or executed in a corresponding container. This group of subsystems 438 provides virtual or logical process control-related subsystems of the logical process control system 445. In some cases ( Figure 4(not shown in the figure), subsystem 438 may provide or include one or more application layer services, and thus, the configuration containers of services 435 and 438 provided by the subsystem may be nested within the configured subsystem container. Generally speaking, this set of subsystems 438 allows control services 435 and other services 440 to be easily and consistently grouped and / or managed. In a preferred embodiment, each node Ny of computing structure 400 hosts a corresponding instance of each subsystem in the set of subsystems 438, such that the subsystem services are readily and easily available to other application layer services 435, 440, 448 currently executing on each node Ny. Thus, changes to one or more subsystems 438 can be coordinated among their corresponding instances executed at each node Ny (e.g., under the guidance of OS 410). Therefore, not only is this set of subsystems 438 highly available and readily available to any application layer service 435, 440, 448 executing on the same node Ny, but also the functionality provided by this set of subsystems 438 can be easily maintained for the logical process control system 445 in the event of a computing structure node failure, a computing structure node component failure, or a failure of a specific subsystem instance at a computing structure node.

[0200] Examples of subsystems 438 that may be provided by application layer 412 of computing structure 400 include, but are not limited to:

[0201] - A continuous process control subsystem for managing the scheduling and execution of the business logic of logical and physical control system entities (such as controllers, I / O assignments, control modules, function blocks, ladder diagram logic, and structure text-based control algorithms, etc.);

[0202] - A state-based process control subsystem for managing, tracking, assigning, changing, exporting, transitioning, analyzing, visualizing, recording, etc. the state of the entire process control system 445, the state of the containerized components / MEEE / granules 140 of the process control system 445, and / or the state of the physical components 105, 108 controlled by the process control system 445, and for driving an industrial process to achieve a desired process state within defined constraints (such as safety, environmental, and / or profitability constraints);

[0203] - An event-based process control subsystem that includes various control services that can be triggered to execute based on the occurrence of one or more events;

[0204] - A batch process control subsystem that includes various control services and can perform batch control and tracking of regulatory items (e.g., for government traceability and management of regulatory records related to batch process control and generated during batch execution and at other times);

[0205] - A historical record subsystem that includes various application layer services to record time - series data of process I / O and events within system 100;

[0206] - A diagnostic subsystem that includes various application layer services for collecting and providing diagnostic data from various other application layer services, other subsystems, computational fabric nodes Ny, components of the software - defined network layer 410, and / or other components of system 100;

[0207] - A process I / O subsystem that includes various application layer services to manage I / O connections and configurations for process I / O within the process control system 445, such as the packet router / switch service 442;

[0208] - A user subsystem that includes various application layer services 440 to authenticate and / or validate user credentials when a user attempts to access the computational fabric 400, for example, via APIs 160, 165;

[0209] - An alert subsystem that includes various application layer services for maintaining the definition, condition, and status of alerts within system 100, such as process alerts, hardware alerts, maintenance alerts, unit alerts, network - layer alerts, I / O alerts, hardware asset alerts, software asset alerts, diagnostic alerts, etc.;

[0210] - A licensing subsystem that includes application layer services 440 to verify or ensure that a user has privileges, enforce licenses, prevent unauthorized activities from occurring, provide management of licenses, report and record license status and activities, etc., according to the license levels of the computational fabric 400 and / or system 100 (such as perpetual licenses, time - subscription licenses, consumption - based licenses, remote licenses, etc.);

[0211] - A distributed event subsystem that includes various application layer services to distribute generated events (or their notifications) and corresponding timestamps indicating the corresponding occurrence times at the respective event sources across all nodes Ny of the computational fabric 400, such that consistent record - keeping can be provided across all nodes Ny; and

[0212] - A configuration subsystem that manages the storage, update, and version control of a configuration database that stores the configurations of various services provided by the application layer 412, such as control configurations. Corresponding instances of the configuration database can be stored at each computational fabric node Ny, such that the computational fabric 400 provides fault tolerance for the configuration database across all nodes Ny. Writes to the configuration database can be atomic across all fault - tolerant instances of the entire system 100, and reads from the configuration database can be from a single local instance of the configuration database. In some cases, large read requests can be segmented and the results provided from multiple nodes Ny in a parallel manner.

[0213] In addition, the application layer 412 of the computing fabric 400 may include additional or alternative subsystems 438 that may be utilized by the system 100. For example, the subsystem 438 may include: a control strategy subsystem for higher-level and / or overall control strategies, such as to achieve product and process performance and quality goals; an analysis subsystem; an optimization subsystem, a quality and energy balance subsystem, a safety subsystem, which may include one or more dedicated algorithms for detecting security intrusions, etc.

[0214] Software-Defined Router / Switch Service

[0215] The software-defined packet router / switch service 442 generally operates as an application or service responsible for transporting packetized I / O information (and in some cases, other types of packetized data or information) between the endpoints of the NGPCAS 100, such as from the physical components 135 / 138 to the containerized components / MEEE / granules 140 at the application layer 412 of the computing fabric 400 and vice versa; from the physical components 135 / 138 to the containerized components / MEEE / granules 140 at the network layer 410 of the computing fabric 400 and vice versa; from the containerized components / MEEE / granules 140 at the application layer 412 to another containerized component / MEEE / granules 140 at the application layer 412; from the containerized components / MEEE / granules 140 at the network layer 410 to another containerized component / MEEE / granules 140 at the network layer 410; from the containerized components / MEEE / granules 140 at the application layer 412 to the containerized components / MEEE / granules 140 at the network layer 410 and vice versa, and so on. For example, the packet router / switch service 442 may communicatively couple the various endpoints and transfer data therebetween using any suitable data delivery or data transfer paradigm (including request / response, publish / subscribe, etc.). In one embodiment, when at least one of the software-defined application layer software components 435-448 is deployed as microservices / MEEE / granules communicatively connected via a microservices / MEEE / granule bus (not shown), the packet router / switch service 442 (in some cases, in conjunction 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 can transfer data and / or information (e.g., in packetized format) therebetween. In additional or alternative embodiments, the software-defined packet router or switch service 442 may use any one or more packet-based networks or links (such as the network 402 and / or the software-defined links provided by the computing fabric 400) to transfer packetized data and information between one or more containerized components / MEEE / granules 140 and / or physical components 135 / 138 of the NGPCAS 100.

[0216] Note that Figure 4 The software-defined packet router / packet switch service 442 is shown as a separate service at the application layer 412; however, this is for purposes of clear discussion (and not limitation). In other embodiments, the packet router / switch service 442 may be included in the subsystem 438 of the computing fabric 400, and / or at least corresponding portions or all of the software-defined packet router / packet switch service 442 may be implemented in the HCI adapter 430 or in the computing fabric operating system 410. Alternatively, the packet router / switch service 442 may be an application layer software-defined service 440 that is in its own independent subsystem within the application layer 412 or that is not associated with any subsystem. In any case, and generally speaking, the software-defined packet router / packet switch service 442 may typically be implemented as a containerized component / MEEE / particle 140 of the computing fabric 400.

[0217] Accordingly, the containerized packet router / switch service 442 may be accessed by other containerized components / MEEE / particles 140 of the computing fabric 400 (both at the application layer 412 and the network layer 410) for the purpose of data transfer or data delivery. In some cases, the packet router / switch service 442 may utilize the API 428 to cause, for example, the transmission of packetized I / O data and / or other types of packetized data via the OS support services 415-425. In some cases, the packet router / switch service 442 may cause data to be transmitted via the microservice / MEEE / particle bus. In effect, the packet router / switch service 442 acts as a logic or gateway (e.g., an API gateway) that causes packetized process I / O and / or other types of packetized data to be routed between the configured containers of the computing fabric 400 and that causes packetized process I / O, packetized control signals or instructions, and other types of packetized information to be routed between the configured containers of the computing fabric 400 and the physical components 135, 138 deployed in the field environment 120 of the NGPCAS 100.

[0218] As will be appreciated, a significant advantage of the systems described herein is that it reduces the data movement and data storage required to support applications or other uses that execute in real time in a computing fabric. Specifically, due to the secure, real-time communication fabric provided in the NGPCAS described herein, including the use of secure, encrypted data links (e.g., VPNs) between various software and hardware elements in the computing fabric and at physical locations (e.g., factories), elements in the computing fabric such as MEEEs can access data in real time from any location in the system (i.e., from any other element that creates or hosts the data). This feature means that applications and other applications that execute in or through a higher-level system element or platform (e.g., a control application, a maintenance application, a data entry or tracking application, a fleet management application, etc.), or any individual MEEE or particle thereof, can use, for example, publish / subscribe communication, dedicated data calls, etc. to access the data in real time at any location where the data resides (e.g., in another MEEE or particle anywhere in the system, in a computing fabric database, in a physical location database or server, in a field device at a physical location, etc.). In fact, the individual MEEEs or other computing elements (particles) that compose or implement a particular application or use can include pointers or references to the data required for their operation, where the data resides in the system, and the particles can access the data in real time when it is needed or used by the MEEE or particle. Thus, for example, the particles can access and use the data as soon as the data is created and / or initially stored. This feature means that data does not need to be moved from, for example, a server in a physical location to a cloud-based server in the computing fabric before it can be used or accessed in real time by an application or element (e.g., a particle) in the computing fabric. Thus, this feature accelerates computing operations and reduces the data flow that has been performed in the past simply to move data from one location to another so that the data can be used in real time by an application that uses the data. The systems described herein thus enable data to be used at any location where it resides or is generated through direct data calls or publish / subscribe communication, whether the data resides in a device within the computing fabric or is generated by a device within the computing fabric or by a device at a physical location or factory.

[0219] Logical / Virtual Components

[0220] In addition, at the application layer 412 of the computing fabric 400, at least some of the physical process control devices or components of a traditional process control system (e.g., controllers, safety logic solvers or devices, data storage devices, etc.) may be logically implemented in the logical process control system 445 as corresponding services 435, 440, or subsystems 438 executing in corresponding containers. If desired, by utilizing control routines, other application layer software components 412, parameters, reference values, lists, and / or other data to configure the logical devices, such logical or virtual instances of the process control devices or components can be configured in a manner similar to their physical counterparts. For example, a controller service can be configured with a number of control modules, and a display view service can be configured with user access control and graphical elements, etc. The configured logical or virtual process control devices or components (e.g., container images of the process control devices or components) can be identified within the logical process control system 445, for example, via corresponding device tags or identifiers, and the corresponding signals received and generated by the configured logical or virtual instances of the process control devices can be identified within the logical process control system 445 via corresponding device signal tags or identifiers. The logical or virtual instances of the process control devices can be uniquely identified within the system 100 and operate as a single entity in place of any corresponding physical devices of the system 100, or the logical or virtual instances of the process control devices can be an agent or digital twin of the physical devices included in the system 100, as previously described.

[0221] At the software-defined application layer 412, the computing fabric 400 also includes software-defined storage entities or components 413, which can provide abstract data storage (and access thereto) for the services and subsystems 435 - 448 of the SD application layer 412. For example, historical databases, configuration databases, and other types of process control system databases and data storage entities, as well as the temporary storage utilized by various process control application services 435 - 448 during execution, can be provided by the software-defined storage entity 413. The storage databases, regions, devices, etc. can be virtualized or logical storage entities or components, which can be assigned or allocated (and can be reassigned and reallocated) by the computing fabric operating system 410 to various storage resources of the nodes Ny of the computing platform 405. For example, a single software-defined logical database can be implemented via the hardware memory resources of multiple nodes Ny. Additionally, the SD storage service 418 of the computing fabric operating system 410 can assign / reassign and reassign / reallocate the software-defined storage entity 413 at the application layer 412 to different storage resources provided by the nodes Ny based on the performance, resource, and configuration requirements of the storage entity or component 413 and optionally other components of the SD application layer 412.

[0222] Orchestration

[0223] Now returning to the software-defined network layer 410 of the computing architecture 400, for purposes of facilitating discussion, Figure 4 a particular computing architecture OS service, namely, the orchestration service 422, is shown separate from the depiction of other computing architecture OS services 415 - 420, 425. Generally speaking, the orchestration service 422 instantiates container images (e.g., container images of the application layer control service 435, subsystems 438, third-party services 448, and other software-defined services 440) to run or execute containerized applications or services on corresponding hardware and / or software physical computing nodes Ny, and assigns various SD data storage entities to reside on corresponding hardware storage and / or software storage nodes Ny. For example, the orchestration service 422 may instantiate and assign various instantiated container images to execute and / or utilize the resources on the resources of a single node Ny or the resources of two or more nodes Ny. In addition, the orchestration service 422 may assign various SD data storage entities or components 413 of the application layer 412 to reside on the physical layer storage resources of a single node Ny, multiple nodes Ny, etc., for example, so that the resident containerized components can be easily and quickly accessed, for redundancy purposes, to balance memory usage across physical platforms, etc. In doing so, the orchestration service 422 not only establishes running containerized applications and services, but also manages the fault tolerance, load balancing, quality of service (QoS), and / or other performance aspects of the running containerized applications and services of the computing architecture 400, for example, via the QoS configuration service 452, fault tolerance service 455, load balancing service 458, and optionally other performance-related services 460 provided by the OS 410. Thus, the orchestration service 422 can be invoked or accessed by other OS services 415, 418, 420, 425, and the orchestration service 422 in turn can 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 logical process control system 445 such that the containerized components can operate efficiently and securely, for example, to control an industrial process at least at a best-effort performance level.

[0224] To this end, the performance-related services 452-460 of the OS 410 can monitor performance parameters, resource usage, and / or criteria during runtime, detect any associated conditions that occur and / or are predicted to occur, and provide and / or implement any changes to the assignment of application-layer software components (e.g., containerized components) 412 to the hardware and / or software resources of the computing platform 405. Thus, during the runtime of the system 100, when various expected and / or unexpected hardware and / or software conditions occur and are detected, the orchestration service 422 responsively adjusts the allocation of the hardware and / or software resources of the various computing fabric nodes Ny to the instantiated container images to maintain (or attempt to maintain) a target or best-effort performance level and operational fidelity. The detected conditions that can cause the orchestration service 422 to modify the allocation and / or assignment between the containerized component 412 and the physical resources of the node Ny can include, for example, hardware failures or malfunctions, software failures or malfunctions, overload of a particular computing fabric node, increased or decreased bandwidth of various network components, addition or removal of computing fabric nodes and / or clusters of computing fabric nodes, hardware and / or software upgrades, pinning and / or unpinning of containerized services and / or applications, diagnostics, maintenance, and other routines that can cause the hardware and / or software resources to be temporarily unavailable for runtime use. Possible responsive and / or mitigating management actions that the orchestration service can take can include, for example, reassigning containerized services and / or applications to execute using different software and / or hardware resources (in some cases, on different nodes Ny), activating and / or deactivating software and / or hardware resources, changing the priority of access of various containerized components to various software and / or hardware resources, etc.

[0225] Thus, in general, services, subsystems, and other software components of the software-defined application layer 412 (e.g., 435, 438, 440) can determine, define, or specify the processing, containerization, networking, and storage requirements of the logical process control system 445 at the individual container level and the aggregated level (e.g., at the subsystem level, unit level, area level, and / or the entire process control system 445). 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 supervise and manage the hardware and software resources of the computing fabric node Ny to support those requirements. For example, in some embodiments, the SD orchestrator 422 can cause different instances of a particular control routine 435 or a particular other service 440 to execute on different nodes Ny, e.g., for fault tolerance, quality of service, and / or other performance criteria of the computing fabric 400. Advantageously, when the requirements of the logical process control system 445 change dynamically over time, the OS support services 415, 418, 420, 422, 425, and / or the orchestration service 422 can modify, change, and adjust the use of the hardware and software resources of the node Ny, e.g., in response and / or in a predictive manner.

[0226] For example, when the logical process control system 445 creates an additional instance of the control service 435 to execute in an additional container, the OS support services 415 - 425 can responsively (via the API 428 and optionally the HCI adapter 430 and API 432) assign the newly created containerized component to execute on a corresponding computing fabric node Ny, can rebalance the existing containerized components among the nodes Ny, can assign specific hardware memory resources to support the logical memory resource requirements of the additional containerized component, can adjust the routing table utilized by the node Ny to support the logical routing requirements of the newly created containerized component, etc. As another example, when a particular cluster C2 needs to stop service (e.g., expectedly for maintenance purposes or unexpectedly due to a lightning strike), the OS support services 415 - 425 can pre-reassign the containerized components currently assigned to execute on the cluster C2 to other clusters based on the current requirements of the logical process control system 445 and the availability of the hardware and / or software resources of other clusters, and the support services 415 - 425 can adjust the routing table utilized by the cluster Cx accordingly, such that the continuity of the execution of the containerized components is maintained even when the cluster C2 stops service.

[0227] Accordingly, the software-defined network layer 410 automatically, dynamically, and reactively determines, initiates, and executes changes to the allocation of the hardware and software resources of node Ny of the computing platform 405 to different application layer software components 412 based on the detected conditions such as performance improvement of individual logical and / or physical components or groups thereof, performance degradation of individual logical and / or physical components or groups thereof, occurrence of a fault, failure of a logical and / or physical component, configuration change (e.g., due to a user command or due to automatic reconfiguration by a service of the computing fabric 400), etc. Thus, the computing fabric 400 can automatically reallocate the hardware and software resources of node Ny in response to changing conditions and components of the computing fabric 400, thereby supporting the process control system 245 and other services executed at the application layer 412 of the computing fabric 400.

[0228] Simulation

[0229] In some embodiments, the computing fabric 400 can implement simulations or changes to various application program services 435, 440, 448, to the entire software application layer 412, to various support services 415 - 425, 452 - 460, and / or to the entire software-defined network layer 410. That is, the simulation of the target component / layer can be executed in cooperation with the active software-defined components / layers on the computing platform 405, and thereby receive runtime data from the field environment of the industrial process plant and operate accordingly using, for example, the same logic, state, timing, etc. as the active target component / layer or using simulated test logic, state, timing, etc. However, the I / O and other types of data generated by the simulation are prevented from being delivered to the field environment, and the simulation can be paused, accelerated, slowed down, fed test inputs, and otherwise managed to observe behavior and make modifications to the simulated component / layer. Thus, after approval of the simulation portion of the computing fabric 400, only that simulation portion can be activated for use during the runtime operation of the industrial process plant without requiring a portion of the computing fabric 400 to be paused or taken out of service to do so.

[0230] Example Security Features of NGPCAS

[0231] Next, various security features of the Next Generation Process Control and Automation System (NGPCAS) 100 are described. As previously discussed, today's process control and automation systems designed around the Purdue model have many drawbacks, including increased complexity (and thus, more components and opportunities for process failures), reduced performance, and a greater risk of network intrusion. For example, in today's process control and automation systems, there are typically at least three different domains that can exist between levels 2, 3, and 4, and the security policies for each domain can be different and require different security management techniques. Therefore, it is challenging to achieve cross-level connectivity and can introduce significant delays in data delivery across multiple Purdue levels (e.g., from level 2 to level 4 and above). Additionally, the industry is seeking the ability to deliver instructions, commands, and / or other information from higher levels of the Purdue model to lower levels. For example, a technician or other process plant personnel may work remotely via his or her portable computing device and may want to monitor runtime process plant operations and adjust configurations, parameter values, settings, etc. within the process control system in response to the monitored conditions. In such a case, when instructions and information move from higher levels of the Purdue model to lower levels (e.g., via "holes" added to the established security mechanisms for these purposes), the outbound firewalls and other currently implemented security mechanisms designed and utilized to prevent external information from flowing into the plant are necessarily compromised, thereby introducing a significant additional risk of external parties accessing the information and data in the protected lower levels of the plant and other types of network intrusion. Additionally, the multiple security mechanisms implemented between Purdue layers (as originally designed or with any added "holes") create a highly complex network that is difficult to design, maintain, and utilize to efficiently transfer information between Purdue levels.

[0232] Furthermore, in today's systems that perform some process control and / or automation functions in the cloud, other undesirable issues are introduced. For example, when the process plant of such a system loses Internet connectivity, the cloud cannot be accessed, and any control or automation functionality provided by the cloud is unavailable. Additionally, cloud-based implementations add additional delays, bottlenecks, and complexity in addition to those introduced by the specific implementation of the Purdue model. Moreover, there is no sufficiently secure mechanism for supporting local communication between process control devices (e.g., field devices) and the cloud.

[0233] The security features of the NGPCAS100 address at least these known security issues of the Purdue model implementation, and provide additional security, improved performance, easier engineering and maintenance, and other benefits and advantages of the NGPCAS100. Examples of such security features are described below. Any one of the described security features can be used as an independent security feature or in combination with any other one or more security features. In some embodiments, the various security features of the NGPCAS100 can be implemented as services 425 provided by the software-defined network layer 410 of the computing structure 400. Additionally, the software-defined network layer 410 can provide other services 415 for managing resources and / or grouping the hardware and / or software resources of the software-defined network layer 410 and / or the physical layer 405 of the computing structure 400, where these resources and / or groups are allocated and / or utilized to support the security features of the NGPCAS100.

[0234] Example Network Security Features of NGPCAS

[0235] As previously discussed, communication between nodes, configuration containers, locations, devices, and / or other parts of the NGPCAS100 and the manually operated computing device 155 (if any) can be protected via one or more VPNs, which can include mutually exclusive and / or nested VPNs. As previously indicated, for purposes of discussion and not limitation, the term "VPN" is used herein to generally and categorically refer to various types of secure, encrypted point-to-point (PTP), peer-to-peer (P2P), and / or point-to-multipoint (PTM) connections. In any case, each VPN, whether nested or otherwise, can block traffic from nodes, components, etc. not included in the VPN, and the endpoints of the VPN can communicate with each other via corresponding sessions through the VPN. The VPN configuration of the NGPCAS100 (e.g., the number of VPNs, the type of VPNs, the nesting of VPNs, etc.) can be implemented via one or more public and / or private networks (including private enterprise networks, the public Internet, etc.). Additionally, the VPN configuration of the NGPCAS100 can be customized to meet the security needs and requirements of, for example, enterprise and / or architecture provider administrators. If needed, at least one of the VPNs of the NGPCAS100 can be a permanent VPN.

[0236] See FIGS. 1 and Figure 4For illustration, in the example minimum VPN configuration, the communication between the physical or on-site environment 120 of the NGPCAS 100 (e.g., all or all components, devices, etc. of the NGPCAS 100 set in the on-site environment 120) and the computing structure 102 of the NGPCAS 100 (including all or all containerized components included in the computing structure 102) can be protected only via a single VPN. In the example maximum VPN configuration, the communication between any pair of entities of the NGPCAS 100 (e.g., exposed APIs 160, 165, other containerized components / MEEE / particles 140, computing structure 102, physical components 135, locations 115, 118, the entire physical environment 120, user applications and / or devices 155, architecture provider / administrator applications and / or devices 161, etc.) can be protected via the corresponding VPN. For example, in the maximum VPN configuration, a configuration container providing control service functionality that needs to use utility functionality to execute control services can communicate with a configuration container providing utility functionality via the corresponding VPN. In an embodiment, the VPN configuration of the NGPCAS 100 may include one or more of the following:

[0237] Point-to-point VPN, such as a VPN dedicated to the communication between only one physical component 135 and only one containerized component / MEEE / particle 140;

[0238] Point-to-multipoint VPN, such as a VPN dedicated to the communication between only one physical component 135 and multiple containerized components / MEEE / particles 140, a VPN dedicated to the communication between multiple physical components 135 and only one containerized component / MEEE / particle 140, etc.;

[0239] Multipoint-to-multipoint VPN, such as a VPN dedicated to the communication between only a subset of all physical components 135 at location 115 and only a subset of all containerized components / MEEE / particles 140 at the computing structure 120;

[0240] A VPN dedicated to the communication between different layers of the computing structure 400, such as the communication between the software-defined application layer 412 and the software-defined network layer 410;

[0241] A VPN dedicated to the communication between one or more selected services, subsystems, and functionality of different layers of the computing structure 400, such as the communication between one or more selected ones of the services and / or subsystems 435, 438, 440 at the application layer 412 and one or more selected ones of the software-defined services and / or functionality 415, 418, 420, 425 at the network layer 410;

[0242] A VPN that serves only instances of API 160 and user application 155, and one or more other VPNs that serve API 160 and one or more containerized components / MEEE / particles 140 and / or physical components 135, 138 required to obtain data or provide data to user application 155, for example, in a point (e.g., API 160) - to - point and / or point (e.g., API 160) - to - multi - point manner;

[0243] A location - to - location VPN, such as a VPN that serves only the communication between a single location 135 and the entire computing structure 102;

[0244] A multi - location VPN, such as a VPN that serves the communication between the computing structure 102 and multiple locations 115, 118, where the multiple locations together are only a subset of all the locations of the NGPCAS100;

[0245] And / or other types of VPNs that protect and secure communications between specified or defined endpoints (e.g., nodes, configuration containers (which may include APIs 160, 161), locations, devices, and / or other parts of the NGPCAS100) within the NGPCAS100. In fact, in an implementation, each endpoint may be required to authenticate to each VPN that the endpoint will use to send and / or receive communications with one or more other entities that have already authenticated to that VPN.

[0246] Example User Security Features of NGPCAS

[0247] As previously mentioned, the user 155 of the NGPCAS 100 can include a human user operating a computing device, such as an operator, a configuration engineer, a third-party person approved by the enterprise to access at least a part of the system 100, another agent of the enterprise, or an agent of the architecture provider / manager 161, etc. One or more application programs (e.g., a web browser, a thin client, or another user interface) are executed at the computing device to communicate with the NGPCAS 100. Additionally or alternatively, the user 155 can include an automated user, such as an external application or service that does not have a user interface and is executed on an external (e.g., remote) computing device or system. The external application / service user 155 can be enterprise-based, e.g., an application and / or service configured by enterprise personnel, or can be a third-party application and / or service. Some of the external application / service users 155 can be applications and / or services provided by the architecture provider / manager 161, used by the architecture provider / manager 161 and / or by the enterprise. In any case, when a legitimate user 155 accesses system data and / or functionality, in order to protect the system 100 from possible cyberattacks, each user 155 may need to utilize one or more exposed APIs 160 to interface with and / or access the system data and / or functionality provided by the NGPCAS 100. For example, the functionality provided by the NGPCAS 100 for the user 155 to utilize can be implemented as corresponding containerized components / MEEE / granules 140 in the computing fabric 102, and such containerized components can be exposed to the user 155 only via the API 160 (e.g., as a website, a service, etc.), where the API 160 can be accessed by the user 155, for example, via a web browser or a thin client. Generally, any functionality (e.g., all functionality) provided by the NGPCAS 100 for the user 155 to utilize can be accessed by the user 155 only via one or more corresponding APIs 160. Additionally, for further security, the communication between the user 155 and one or more APIs 160 can be protected via a corresponding VPN 158. For further security, it can be required that the user 155 be first authenticated to the VPN 158 before being able to utilize the API 160, and specifically, a human user can perform multi-factor authentication in order to obtain access to the VPN 158.

[0248] In some cases, 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 that are exposed to different users 155 and / or to which different users are authorized to access may vary based on the respective credentials of the users. For example, the 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, the authorization of different users 155 to different APIs 160 may be implemented on an enterprise basis (e.g., users 155 of enterprise A are permitted to access a first subset of APIs 160, while users 155 of enterprise B are permitted to access a different second subset of APIs 160); on a location basis; on a node basis; on a user credential basis (e.g., the role, responsibilities, and / or skills of the user); on a time basis; and / or based on a combination thereof.

[0249] Accordingly, by using a VPN to secure communications within the NGPCAS 100, security mechanisms used to secure cross-level communications between the layers of a Purdue model-based system (e.g., firewalls, digital diodes, DMZs, and other mechanisms) can be eliminated. In fact, in one embodiment, the NGPCAS 100 does not include (e.g., excludes) any firewalls, data relays, data diodes, and DMZs for securing communications to, from, and within the NGPCAS 100, thereby simplifying the design, engineering, configuration, maintenance, and runtime execution of the NGPCAS 100 as compared to a Purdue model-based system. Further, since each VPN blocks or does not process any traffic originating outside of the VPN, and since any and all human users and / or automated users 155 of the VPN must be authenticated to the VPN, the data utilized within a process control or automation system is only exposed to those components / entities that have been authorized to access the VPN through which the data is being delivered. Accordingly, the opportunity for externally initiated cybersecurity vulnerabilities and the propagation of malware is significantly reduced, or even eliminated in some cases, as compared to today's systems.

[0250] In addition, since access to the selected functionality provided by the NGPCAS 100 is provided to the user 155 via the API 160, and since the user 155 must be authenticated to the VPN 158 and optionally authenticated to utilize the specific API 160 as described above, the network security risk is even more significantly reduced compared to the network security risks of today's systems. For example, such security techniques used within the NGPCAS 100 eliminate the need to install any NGPCAS-specific software 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 network security vulnerabilities. As another example, the computing devices operated by the user 155 (human or automated) can be authenticated to a VPN 158 that is not utilized by any component of the 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 can be mutually exclusive VPNs, thereby further eliminating possible avenues for other network security vulnerabilities. As yet another example, any access (including read-only access) by unauthorized (but otherwise valid) users 155 to the NGPCAS 100 or portions thereof can be completely prevented.

[0251] Example Identity Security Features of NGPCAS

[0252] As previously mentioned, each component of the NGPCAS 100 (each containerized component / MEEE / particle 140, each physical component 135, each device 105, 125, 108, 128, 148, each location 115, 118, the computing fabric 145, the architecture provider / manager 161, or generally any component that can serve as an endpoint within the NGPCAS 100 network) can be uniquely identified within the NGPCAS 100 by a unique network identifier. In an implementation, the unique network identifier of the subject component is based on the identity of the subject component as defined in the configuration database of the NGPCAS 100. In a manner similar to that discussed above for the user 155 of the NGPCAS 100, each component can be authenticated and authorized based on its unique network identifier so that the component can access one or more VPNs, communicate with one or more nodes, configuration containers, locations, devices, and / or other components, etc. Generally, the components of the NGPCAS 100 that have unique network identifiers (e.g., all components of the NGPCAS 100) can be discovered within the NGPCAS 100 and can be required to utilize corresponding certificates for authentication and authorization of access.

[0253] At least some of the physical devices 105, 125, 108, 128, 148 included in the NGPCAS 100 may also include a device identifier that is unique across enterprises, such as that described above with respect to Figure 5A _5. In these devices, an indication of the association between the unique device identifier of the device and the unique network identifier of the device may be stored, for example, within the device itself, in the configuration database of the NGPCAS 100, in the network manager of the NGPCAS 100, and the like.

[0254] Example Communication Security Features of NGPCAS

[0255] To further secure the NGPCAS 100, all communications sent and received via the network of the NGPCAS 100 (e.g., via the VPNs 130, 158, 162 between various authentication and authorization components) may be required to be signed and encrypted. Additionally or alternatively, cleartext protocols such as HTTP may be prohibited or otherwise blocked from being utilized within the NGPCAS 100. To provide even further security in an arrangement where the architecture provider / manager 161 manages multiple NGPCAS 100s for multiple enterprises, each enterprise may have a different certificate authority (CA), and the use of self-signed certificates may be prohibited or otherwise blocked. Generally, to maintain security within the NGPCAS 100 over time, certificates may support revocation, have a modifiable key size (e.g., to support system growth), and may be automatically refreshed without any enterprise intervention.

[0256] Example Computing Structure Security Features of NGPCAS

[0257] In particular, regarding the protection of the computing architecture 400 and its components, various security techniques can be employed within the NGPCAS 100. For example, as described above, the containerized components / MEEE / granules 140 of the computing architecture 102 / 400 (e.g., APIs 160, 165; services and subsystems 435, 438, 440, 448, 413, 442 at the software-defined application layer 412; services and functions 415, 418, 420, 422, 425, 452, 455, 458, 460 at the software-defined network layer 410; APIs 428, 432 and / or other services provided at the adapter layer 430, etc.) can be configured for client certificate access, where the client can be, for example, another containerized component / MEEE / granule 140, a user 155, or an architecture provider / manager 161. That is, anonymous access to the containerized components / MEEE / granules 140 can be disallowed, and access to certain containerized components / MEEE / granules 140 can be provided only to certain clients (e.g., via corresponding client certificates). Additionally, client certificates can be rotated automatically and frequently. Further, in an implementation, unused features (e.g., applications, services, etc.) can be placed in a disabled (not enabled) state.

[0258] Furthermore, the containerized components / MEEE / granules 140 can be signed and scanned regularly for known vulnerabilities. The containerized components / MEEE / granules 140 can be required to execute or run with minimum privilege (e.g., always running), and the containerized components / MEEE / granules 140 can be required to utilize the maximum level of container isolation during runtime (e.g., by default). In some specific implementations, the definition of groups of containerized components can be blocked or restricted. For example, the NGPCAS 100 can be allowed to define only groups of containerized components that are particularly relevant to process control system components. For example, a group of containerized components for a bioreactor can 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 computing architecture 400), such that the bioreactor grouping of containerized components can be co-located and moved together, e.g., to execute on different nodes, clusters, segments, etc.

[0259] At the physical layer 405 of the computing architecture 400, access to different nodes Ny, different hardware segments, different clusters C1, …, Cn, etc. can be controlled, for example, on a server basis, on an API basis, etc. Additionally, static data and disks can be encrypted statically.

[0260] Example Hardware Security Features of NGPCAS

[0261] In an embodiment, field devices, hardware I / O devices, gateways, and other devices may include one or more forms of Embedded Device Identity (“EDID”). In the same way that a serial number indicates a specific instance of a product and may indicate additional information about the model number, options, or other data about the product, the EDID is associated with and / or indicates a single instance of a device or product and / or may be associated with and / or indicate additional information. As will be described below, in addition to various security and other benefits, the EDID can also facilitate faster and less labor-intensive commissioning of a process plant.

[0262] Figures 5A to 5C The specific implementation of the EDID in various types of hardware devices is shown. For example, Figure 5A is a block diagram showing a smart field device 500 such as a Foundation Fieldbus device. As should be understood, the smart field device 500 can be any number of device types, including valves, valve controllers, sensors, transmitters, or any other type of field device having a process, memory, and a communication channel capable of transmitting various types of data (settings, measurements, calculated values, device tags, etc.). The smart field device 500 includes a processor 502, one or more memories 504 storing various data readable according to the Foundation Fieldbus protocol (e.g., measurements, setpoint values, status information, scaling information, limit values, alarms, device descriptors, device IDs, device tags, etc.), as will be readily understood 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 understood. In Figure 5A the smart field device 500 shown, the device also includes an Embedded Device ID (EDID) 510.

[0263] Figure 5B is a block diagram showing 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 operating on a computing structure, etc.). The sensor / transmitter 512 also includes an EDID 520.

[0264] The I / O device 522 is shown in Figure 5Cin the block diagram. The I / O device 522 shown in the figure is of a type commonly known in process control (except for including one or more EDIDs), and can facilitate the conversion of one or more I / O signals from one or more corresponding field devices into signals that can be forwarded to a control device or service (e.g., a controller service operating in a computing fabric), and the conversion of one or more signals from the control device or service into signals that can be forwarded to the corresponding field devices. The I / O device includes a processor 524, a memory 526, and a library 528 of I / O modules 530A - 530D, each I / O module coupling a corresponding field device to the process control system through 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 entire I / O device 522, an EDID 560 associated with the I / O module library 528 (e.g., each configured to receive a set of terminals of the corresponding I / O modules 530A - 530D that couple the corresponding field devices to the I / O device 522), and / or one or more EDIDs 550A - 550D each associated with a corresponding one of the I / O modules 530A - 530D. In some embodiments, each individual component (I / O device 522, I / O modules 530A - 530D, and I / O module library 528) may have an EDID, while in other embodiments, only the I / O device 522 may have an EDID, etc. Additionally, although the I / O device 522 is shown as having four I / O modules 530A - 530D, in various embodiments, the I / O device 522 may have more or fewer I / O modules 530, and in other embodiments, the I / O device 522 may utilize another means (i.e., different from an I / O module) to couple the field devices to the I / O device 522.

[0265] Each EDID 510, 520, 530, 540, 560 is a unique identifier built into the device. Although in an embodiment, the EDIDs 510, 520, 530, 540, 560 may include multiple pieces of information, in a preferred embodiment, each EDID 510, 520, 530, 540, 560 is merely a unique identifier associated with other relevant information about the device in a relevant database. The EDIDs 510, 520, 530, 540, 560 can be embedded in their respective devices in any number of ways. For example, in an embodiment, 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, 560 are hardwired into the device at the printed circuit board (PCB) level through, for example, a series of short and / or open signals. In other embodiments, the EDIDs 510, 520, 530, 540, 560 can be embedded within the chip during manufacturing. In other embodiments, the EDIDs 510, 520, 530, 540, 560 can be the result of a physically unclonable function that generates a substantially random value using variations in the manufacturing process of one or more components. Regardless of the manner in which the EDIDs 510, 520, 530, 540, 560 are embedded in the respective devices, the EDIDs 510, 520, 530, 540, 560 are generally difficult to modify and / or rewrite without at least opening the device to access the internal hardware of the device.

[0266] Figure 5D An example EDID 562 that can be embedded on a hardware device is shown. The EDID 562 can include only or at least include a unique identifier 564. However, in the case where the EDID 562 includes multiple pieces of information, the information can be stored on the device as a series of values. Example optional values (indicated by the dashed box) that can be included in the EDID 562 include values indicating the following: the owner / enterprise / customer 565 associated with the device, the model number 566 of the device, the facility 567 associated with the device, the geographical region 568 associated with the device, the manufacturer 569 of the device, the registry 570 associated with the device, one or more options 571 present on the device, the manufacturing date 572 of the device, etc.

[0267] Particularly in embodiments where the EDID on the device includes only a unique ID, the database 580 can associate each EDID with values indicating various information 565 - 572 as needed, as Figure 5EAs shown. Various information 565 - 572 associated with each EDID can be dynamically stored in database 580 when the device is sold, when the device is shipped, or even when the device is first used. Database 580 can be stored, for example, on computing structure 102 and accessed by EDID service 582, which can be responsible, either wholly or in cooperation with other services, for authenticating and / or determining whether to permit a device to operate in a particular process control system.

[0268] In an embodiment, when connected to computing structure 102 (e.g., during commissioning, process startup, restart, etc.), each hardware device must authenticate to the system. The discovery service operating on computing structure 102 requests and / or receives and / or discovers its EDID from each hardware device. The discovery service transmits each received EDID to EDID service 582 (which, in an embodiment, may or may not be separate from the discovery service), and queries the database to determine one or more pieces of information associated with the EDID to determine whether to validate the EDID and, by extension, the device associated with the EDID. As a non - limiting example, EDID service 582 can determine: whether a given EDID is associated with the owner / enterprise / customer associated with the process plant where the device is located; whether a given EDID is associated with the geographical region where the operation is currently taking place; whether a given EDID is installed at the facility for which it is intended; etc. In the case where EDID service 582 determines that the device is valid / authenticated, EDID service 582 can communicate to other services (e.g., security service, certificate authority service, etc.) that the device should be permitted to operate (or fully operate) within the system. Alternatively, if EDID service 582 determines that the device is invalid, stolen, forged, not on - site, in the wrong plant, in the wrong geographical region, etc., EDID service 582 can communicate to other services that the device is not permitted to operate within the system and, in some embodiments, can remotely disable the device, rendering it completely inoperable.

[0269] In this way, the EDID can be used to increase security by making it more likely that devices operating in the secure environment of a process plant are devices of known origin before a security certificate is issued that permits the device to connect to a secure network over which devices and services communicate across computing structure 102. That is, unauthenticated devices will not be granted a certificate by the certificate authority. The EDID can also be used to prevent the black - market sale of devices (e.g., in violation of sanctions or trade restrictions), prevent theft, prevent reverse engineering, prevent forgery, etc. by prohibiting or otherwise blocking the operation of any off - site (not owned by the associated customer, not at the associated plant, not in the associated geographical region, stolen, etc.) devices.

[0270] The specific implementation of EDIDs 510, 520, 530, 540, 560 can also facilitate improved commissioning of process plants. In an implementation, the information associated with each EDID can include information about the configuration of field devices and / or options installed on the field devices. In an implementation, the information associated with each EDID can include one or more device tags and / or one or more control modules associated with the field devices. Thus, the discovery / EDID service can determine which services should send data to and receive data from field devices for a particular process based only on the EDID, can configure I / O services for field devices, can establish appropriate secure connections between devices and other components, etc. In short, the use of EDIDs can allow process plants to produce products online in less time (and thus at less cost).

[0271] Figure 5F An example method 590 for implementing the use of EDIDs in a process control system is shown. The method includes receiving data indicating an EDID (block 592), querying a database for the received EDID (block 594), and determining from the query results whether to allow a device to operate in the system (block 596).

[0272] Other Example Security Features of NGPCAS

[0273] In addition to the above security features, the NGPCAS 100 can include one or more other security features that protect other functionality and aspects of the system 100, where at least some of the security features can be provided out-of-the-box and where at least some of the security features can be customized and adjusted, for example, by an enterprise agent, by a system provider agent, etc. Such security features can 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 included therein), network security groups (e.g., by application, location, human user, and / or other categories), firewalls, and access control lists (ACLs), etc. In addition, the secrets utilized by the system 100 (e.g., keys, certificates, etc.) can be stored in one or more secure vaults.

[0274] In addition, the resources of the system 100 can be protected in a hierarchical manner, such as in Figure 5Gas shown in the example resource security technique 599 shown. As previously discussed, resources can include hardware and / or software resources, such as components, clusters, nodes, services (e.g., configured containers), etc. At the single or individual resource level, each individual resource can be protected in a manner such as described above (e.g., based on its identity, using keys and certificates, etc.). At a higher level, resources can be grouped (e.g., in a manner such as described above), and each resource group can be secured and protected as a group (e.g., through group identity, keys, certificates, etc.). Resource groups can be defined and / or created based on any category, such as by location (e.g., local to field devices, at remote locations, in computing fabrics, etc.), by functionality, by time of day, etc. At a higher level, subscriptions to various individual resources and / or to various resource groups can be utilized such that only users who have subscribed to a particular resource or resource group can access that particular resource or resource group. That is, access to a particular resource or resource group can be limited to those users who have a subscription to it, thereby providing further security to system 100. Note that an individual resource can be included in one or more different resource groups and / or accessed via one or more different subscriptions. Additionally, note that the resource security technique 599 can be applied locally at the location where the field device is located, non-locally at other physical locations, and / or in a computing fabric as needed. Of course, other resource security techniques can be additionally or alternatively utilized in the NGPCAS 100.

[0275] Additional Architecture Features of NGPCAS

[0276] Due to the decentralized and highly configurable nature of the computing architecture of the NGPCAS described herein, the 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 performed within the computing architecture, which enables the enterprise to uniquely configure global or in-plant data flows and execution management in ways not possible with previous control systems. Specifically, the computing architecture of an enterprise having multiple physical plants or locations can be established in a hub-and-spoke configuration, where multiple different computing architecture "hubs" can be created to support various different physical locations or plants connected to the hubs via communication networks implementing the communication "spokes". Each hub can have computing resources restricted to or implemented within a particular geographic or sovereign region. These regions can be, for example, continents (such as North America or South America, Europe, Africa, etc.), countries (such as the United States, Russia, China, Australia, Germany, France, etc.), states or defined regions of a particular country (such as California, Florida, etc.) or any other geographic or geopolitical region. In such cases, the computing architecture hardware can be implemented in a cloud environment or physically located in a particular region (or a particular set of regions) or other physical locations contained within a particular region (or a particular set of regions) to form a computing center. Each computing center can be connected to one or more physical locations or plants of the enterprise via the communication infrastructure described herein, which forms the spokes from the computing architecture center to the physical locations. In some cases, more than one computing architecture center can be connected to the same physical location, and each such computing architecture center can receive all or a subset of the data from that physical location. Additionally, in some cases, the computing architecture center can be connected to one or more physical locations within the same region as the center via one or more communication spokes, and / or can be connected to physical locations in one or more regions different from the center via other communication spokes.

[0277] Figure 6AIllustrates an example enterprise NGPCAS system 600 having a plurality of computing structure centers 602 located in various regions (in this case, national or public political regions (e.g., the European Union)) and connected to various physical locations via one or more communication spokes 603. In this example, the enterprise includes two computing structure centers 602A and 602B located in the United States, one computing structure center 602C located in Europe (e.g., one or more countries associated with the European Union (EU)), one computing structure center 602D located in Russia, and one computing structure center 602E located in Africa. Each of the computing structure centers 602 includes one or more terminal communication spokes 603, where each terminal communication spoke 603 leads from the center 602 to a physical location 604. As will be understood, the spokes 603 associated with a particular center 602 can connect the center 602 to different physical locations, which can be in the same region as the center 602 or in different regions. Additionally, if desired, one or more communication spokes 603I can be provided or configured to provide communication between two centers 602 for direct inter-center communication. In this way, data received from a particular physical location 604 at the first center 602 via a communication spoke 603 at that center 602 can be routed via an inter-center spoke 603I to a second computing structure center 602. Similarly, communication from the first center 602 (such as control signals, data requests, configuration changes, etc.) can be sent by the first center to a particular physical location 604 by sending the data via an inter-center spoke 603I to the second center 602, and then the second center can provide the communication to the physical location 604 via a communication spoke 603 established between the second center 602 and the physical location 604. As Figure 6A shown, a particular computing structure center 602 (such as center 602A) may, in some cases, include only terminal spokes 603 leading to physical locations 604 in the same region (e.g., the United States). Of course, in other cases, a particular computing structure center 602 (such as center 602B) may include terminal spokes 603 leading to physical locations 604 in multiple different regions (such as physical locations in both the United States and Europe). Similarly, in a situation such as having centers 602B and 602C and a physical location 604A, multiple different centers 602 can be connected to the same physical location 604 via different spokes.

[0278] Importantly, this hub and spoke configuration enables data and execution management to be separately configured and maintained at each computing fabric hub 602 such that an enterprise with physical locations in multiple different regions can comply with the various different laws or data governance rules of the physical location and / or the particular region in which the computing fabric hub 602 resides. For example, different regions (such as the United States and Europe) may have different data privacy, data export, and data management laws and regulations, and thus it may be important to separate and track different data sent to and stored at a particular computing fabric hub 602 in order to process and dispose of it in a manner that complies with the appropriate laws and regulations of the hub 602. However, these laws and regulations typically only apply to static data and not to dynamic data. Thus, the hub and spoke architecture described herein also enables data (all data or a subset of the data) collected by a device at a particular physical location to be governed by a set of data privacy laws associated with a particular region by enabling the collected data to be sent to and stored only at a computing fabric hub 602 located in the region where the data privacy laws and regulations will be applied. Thus, data collected at a physical location 604A set in the EU can be sent directly to, for example, a computing fabric hub 602B in the United States without being stored at the EU hub 602C. In such a case, a direct communication spoke 603A can be established between the hub 602B in the United States and the physical location 604A in the EU, and the data may or may not be sent to or stored in the EU hub 602C. However, in another case, data from a physical location 604B in the EU may first be sent via a spoke 603B to the EU hub 602C. However, the EU computing fabric hub 602C may immediately send the data via an inter-hub communication spoke 603I to the hub 602B in the United States without storing the data, thus ensuring that the data is not governed by the EU's data laws and regulations.

[0279] Of course, the hub and spoke configuration described herein can also or alternatively be used to manage or direct execution and operational activities at various different hubs and / or at various different physical locations using the same concepts. For example, different computing fabric hubs 602 can manage the execution of applications and services and provide or manage user or application authorization in different ways by storing and applying at the physical locations 604 to which the hubs 602 are connected different sets of rules or policies to be implemented by each computing hub 602. The ability of each computing fabric hub 602 to store and apply different data governance, application, and other system execution rules provides great flexibility in managing and storing data within an enterprise and in managing and controlling application execution in different ways at different physical locations 604 and different computing fabric hubs 602. Thus, even though each different hub 602 or physical location 604 is associated with the same enterprise, this feature enables the use of different configuration paradigms at each different hub 602 or even at each different physical location 604.

[0280] Generally speaking, to perform these data and execution management activities, a computing fabric for a particular hub 602 stores a set of rules, such as data governance rules, execution rules, access authorization rules, etc. (shown as components 610A, 610B, 610C, 610D, and 610E at hubs 602A, 602B, 602C, 602D, and 602E, respectively), which are then automatically implemented or applied by appropriate computing fabric components at hubs 602A through 602E to manage data flow, application and service execution, user and service authorization, etc. In addition, the architecture provider / manager can 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, and store the data governance and execution rules 610 to be used at each hub 602.

[0281] Figure 6B is a diagram 620 showing an example system hierarchy associated with an enterprise using the NGPCAS described herein and showing the ways in which the various different components of the NGPCAS system are associated and can be implemented in the structural elements described herein. Specifically, as Figure 6B shown, diagram 620 includes three columns, the rightmost column 622 includes software, hardware, and firmware components associated with the NGPCAS listed in a hierarchical grouping view, the middle column 624 indicates the physical or virtual execution location of the associated elements in column 622, and the leftmost column 626 indicates the purpose or operation of the elements in column 622. Thus, as Figure 6BAs shown, column 622 includes an application 630 that provides a customer or enterprise view of NGPCA (as shown in column 626), where the application 630 is stored in and executed within a computing fabric in a cloud environment (as shown in column 624). The application 630 can include any customer- or enterprise-facing and accessible application, including, for example, one or more ATMP applications 632 for providing workflow tracking and security logging for, e.g., one or more batch processes or production facilities; one or more enterprise monitoring applications 633 that provide a customer portal for existing functionality in the enterprise; one or more enterprise fleet management applications 634, and one or more utility applications 635 (such as IEE applications), where the enterprise fleet management applications provide and track the real-time health and inventory status of enterprise equipment and can make recommendations for changes, updates, etc. Additionally, the application 630 can include one or more enterprise control applications 636 (which can include any of the process control elements described or mentioned herein, such as containerized control modules, containerized function blocks, enterprise or device twins, etc.). Similarly, the application 630 can include one or more operations applications 637, engineering applications 638, and data management applications 639. The operations applications 637 can include applications that enable insights and control of process operations, such as DeltaV Live applications, operator interface applications, alarm management applications, data historian applications, etc. Similarly, the engineering applications 638 can include control and graphical configuration applications for defining and configuring control routines and control operations. The data management applications 639 can include data exchange and data visualization applications to enable enterprise users to gain access to and / or view data within the enterprise. Of course, any other desired applications (such as equipment maintenance applications) can be included in and supported at this level of the NGPCAS. As noted in column 626, the application 630 is user-facing and thus visible and directly used by authorized users of the enterprise.

[0282] Additionally, as Figure 6B shown, the NGPCAS includes a set of application frameworks 640 that support and enable the application 630 and, in this case, are implemented in a cloud environment that is at least part of the computing fabric used as the enterprise NGPCAS. The application frameworks 640 can include, for example, a framework 641 for providing, managing, and implementing role-based security (application access), database (such as event and alarm databases, historian, etc.) access, configuration, and support 642, a service mesh framework 643, a material support database 644, business or other rules 645 to be applied by the application 630, and a protocol support framework 646 that supports the use and translation of communication protocols. The rules 645 can define regarding Figure 6AThe data governance and application execution rules described above. Of course, the framework 640 described herein is merely an example set of frameworks that can be used and supported in NGPCAS, and may also alternatively include or use other frameworks. Additionally, while the frameworks 640 can be configured and accessed by an enterprise, these frameworks 640 are not directly user-facing, but rather support user-facing applications 630.

[0283] In addition, the NGPCAS of the diagram 620 includes one or more platforms 650, which can be implemented as software-as-a-service (SaaS) platforms (as shown in column 624) in a cloud environment of a computing structure to implement and support the application framework 640 and the application 630. The platform 650 can include, for example, a Kubernete (or other) container management and orchestration platform, an observability and platform monitoring platform (used by one or both of the enterprise or 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 regarding Figure 6A the rules 610 described above), a cost and subscription tracking platform, etc. Of course, Figure 6B the platforms 650 listed or described in

[0284] are merely examples and can be used to support various features of the NGPCAS described herein. However, other platforms can also be used or provided. Additionally, the platform 650 does not have to be implemented as an SaaS platform. As will be understood, the platform 650 is managed by the architecture provider / manager using inputs from the enterprise. Figure 6B In addition, as shown, the NGPCAS hierarchy includes a cloud support structure 660 for implementing the cloud environment as part of the computing structure. Specifically, the cloud environment support structure 660 includes, for example, the AZURE cloud operating system and the ARC service that implement AKS or a deterministic runtime environment, as described herein. Of course, other cloud environment support structures or services can also be used or provided alternatively, and the NGCPAS described herein is not limited to the listed cloud support structure 660. Of course, as Figure 6BAs shown, the cloud environment 660 provides control, data, and management planes (via VPN or other communication connections) to edge devices 670, as shown in column 624, which are local to various different physical locations. The edge devices 670 can 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 can be connected to local hardware 680, such as local controllers, field devices, and other local hardware, as shown in column 624. Of course, the edge components 672, 674, and 676, as well as local hardware such as controllers, I / O devices, and field devices, are local to generate, measure data, or provide local access to data and perform other activities such as control, maintenance, and support activities.

[0285] As will be appreciated, Figure 6B the hierarchical structure shows a way in which all the required applications, services, containers, microservices / MEEE / granules, platforms, software, etc. that can be implanted as part of what is described herein as NGPCAS can be provided to an enterprise to provide a complete process control and application service system, the components of which are distributed within a computing structure (shown in this case as a cloud environment) and at one or more physical locations or facilities. More specifically, Figure 6B the diagram 620 shows the way in which user-facing applications (including control applications, maintenance applications, data storage and tracking applications, process control and configuration applications, management applications, workflow management applications, etc.) can be layered onto and incorporated into NGPCAS operating in an execution environment.

[0286] Construction and Support Features of NGPCAS

[0287] As will be appreciated, the NGPCAS as described herein provides its software-implemented components or enables such software-implemented components to be highly configurable, transportable, and editable because most of the control and support components (e.g., control modules, containers, etc.) are located within and execute within a computing fabric without being bound to a particular or predetermined computer hardware (e.g., a particular server, processor, computer node, etc.). This feature enables system setup and configuration activities to be performed more quickly and easily than traditional control systems because it enables an enterprise system owner or administrator to store configuration components for their system within the computing fabric, access these components from any location, copy these components to create or add additional control system architectures associated with, for example, a new factory or new physical location added by the enterprise, new hardware installed at an existing physical location, etc., without specifying the location or details of the computer hardware for implementing the additional configuration components. Additionally, this architecture enables the architecture provider / manager (also referred to herein as the "APM") to simultaneously oversee the operation of multiple different enterprise systems during their operation, which enables the APM to provide general and specific support for the different enterprise systems. For example, the APM can monitor and capture quality of service statistics and / or other data related to or defining the operation of various software and hardware components operating within the computing fabric of various different enterprise systems while these enterprise systems are executing to perform control and manufacturing activities. The APM can provide these measures to the different enterprise systems and can upgrade or change the configuration or use of the computer equipment within the computing fabric, such as by adding additional computing fabric computer equipment (nodes, servers, computers, processors, etc.), by reducing computing fabric equipment (nodes, servers, computers, processors, etc.), by changing computing fabric equipment (such as using a processor with a higher processing speed, larger memory, etc.) or by taking other actions within the computing fabric based on quality of service metrics to ensure better quality of service or to reduce costs where the quality of service meets expectations (e.g., meets the quality of service metrics promised or guaranteed by a particular enterprise license).

[0288] APM can also provide or implement various data analysis applications on a variety of different enterprise systems to recommend changes to those systems, which can improve the operation of those systems. Additionally, APM can aggregate data from different enterprises and analyze that data to detect trends, problems, etc., and then provide general guidance for a particular enterprise system based on that analysis. APM can, for example, use data analysis to compare the operation of control systems for the same or similar products or manufacturing steps from the same or different enterprise systems to determine which systems or which system configurations are operating better or worse than each other, which are operating better or worse than an average or baseline system, etc. Then, APM can use other data analysis to determine why a particular system is operating better or worse, such as determining whether the variation is related to the presence of different equipment, different control routines, different interactions or configuration settings of virtual control components or actual control system hardware, etc. Then, APM can generate general guidance or best practices for one or more enterprise systems based on the knowledge determined in these analyses.

[0289] In addition, the architecture described herein enables the faster development and testing of components to be added to control systems because the architecture enables the development and provision of control or other system containers or products in a container registry or product registry for download and implementation by an enterprise system at the will and timing of the enterprise system or enterprise system administrator. Feedback on the operation of the containers or products from these downloads and implementations can also be automatically provided back to the developer from the enterprise's computing fabric as part of the development cycle to test, upgrade, and change the containers or products. The architecture allows or results in a faster development cycle because it provides for the faster implementation of new features or products and provides automatic feedback on the operation of new or changed components. However, the development is still carried out and implemented in such a way that each enterprise operator or administrator can control when new containers or products are downloaded into their systems and implemented in their systems.

[0290] Figure 7 An overall NGPCAS architecture 700 is shown, which includes a plurality of different enterprise systems 702 (Enterprise 1), 704 (Enterprise 2)......706 (Enterprise n), which are connected to an architecture provider / manager (APM) 710. Specifically, each of the enterprise systems 702, 704, 706 implements NGPCAS as described herein, including a computing fabric and plant hardware at one or more locations (i.e., physical locations), where gateway devices, I / O devices, and field devices are located at the one or more locations to perform manufacturing or factory automation processes. As Figure 7As shown in the example system, enterprise 702 includes a computing fabric 720 connected to two physical locations 722A and 722B, which can be, for example, factories, buildings, regions, or other physical locations where gateways, I / O, and field devices are located to perform processes such as factory automation or manufacturing processes. Similarly, the computing fabric 720 of enterprise 702 includes multiple different sets of containers as described herein for implementing control and related support features for the equipment at locations 722A and 722B. Specifically, in Figure 7 the example, the computing fabric 720 includes one or more sets of containers 726A that monitor and control the physical equipment at location 722A and one or more sets of containers 726B that monitor and control the equipment at location 722B. Of course, as described herein, the containers 726A and 726B in the computing fabric 720 can be arranged in any desired manner and using any other desired configuration, and do not necessarily need to be separated or grouped based on the physical locations they control. Additionally, enterprise 702 can include one or more user interfaces 730 that are connected to and interface with the computing fabric 720 using one or more APIs 732 within the computing fabric 720. The user interfaces 730 and APIs 732 operate as described herein to enable the owners, operators, configurators, etc. of enterprise 702 to perform configuration, monitoring, and control activities regarding the physical location 722 using the containers 726 in the manner previously described herein.

[0291] Similarly, as Figure 7 shown, enterprise 704 includes a computing fabric 740 connected to multiple physical locations 740 (including the already installed locations 740A to 740C). The physical location 740D is shown in dashed lines to indicate that it will be added using the configuration applications and techniques described later herein. Of course, as Figure 7 shown, the computing fabric 740 of enterprise 704 includes a set of containers 750 that are installed in and execute within the computing fabric 740 to monitor, control the equipment at physical location 742, and provide support services for the equipment. Additionally, a user or operator associated with enterprise 704 can interface with the computing fabric 740 via the user interface 756 and API 758 to perform monitoring, configuration, and operation activities regarding the containers 750 within the computing fabric 740, such as visualizing and controlling the operation of a control system implemented or executed by the containers 750 to control the equipment at physical location 742. Of course, the owners, operators, managers, etc. of enterprise 704 can interface with the computing fabric 740 in any desired manner as described herein to perform any configuration, control, or monitoring functions for enterprise 704.

[0292] In addition, any other number of enterprises (such as Figure 7The dots in [Enterprise n 706] each include a computing structure 760 coupled to a plurality of different physical locations 762A through 762n, and include a container or group of containers 770 to perform control and support activities regarding locations 762A through 762n. Again, enterprise 706 may enable a user to interface with computing structure 760 using one or more user interfaces 772 and one or more APIs 774, as described herein.

[0293] As Figure 7As shown, the APM 710 is connected to each of the computing fabrics 720, 740, 760 of enterprises 702, 704, 706 via a direct secure communication link 780. The communication link 780 can be configured to operate with separate security in any of the ways described herein, such as using a separate VPN for each of the computing fabrics 720, 740, 760. Importantly, the communication link 780 provides the APM 710 with information about the ongoing operations, configurations, and associated information of each of the containers, modules, programs, etc. within each of the computing fabrics 720, 740, and 760. Thus, in this way, the APM 710 has a direct and continuous connection to the computing fabrics in each of the enterprises 702, 704, and 706, and can use this connection to start, allocate, remove, reduce, or change the computer resources within each of the computing fabrics 720, 740, 760 of each of the enterprise systems 702, 704, 706, respectively. The APM 710 can use the direct and secure connection 780 to license, provide, configure, or otherwise establish sufficient computer equipment in the computing fabric for each of the enterprise systems 702, 704, 706 based on the licenses purchased by the enterprise systems 702, 704, 706. In some cases, the APM 710 can license or use computer equipment in the cloud, such as computer equipment provided by a third-party cloud computing provider (e.g., Microsoft Azure). In other cases, the APM 710 can have its own computer resources at one or more locations owned or operated by the APM 710, and the APM 710 uses these computer resources to provide computing resources for the computing fabrics 720, 740, 760 of the enterprises 702, 704, 706. In other cases, the enterprises 702, 704, 706 can provide some or all of the computer resources used in the computing fabrics 702, 704, 706 and enable these resources to be managed by the APM 710. For example, the area 779 within the computing fabric 740 of enterprise 704 marked with a dashed line indicates that the elements executed in this part of the computing fabric 740 are executed on computer hardware owned by enterprise 704, located at the enterprise, or provided by the enterprise, and can be, for example, computer hardware at one of locations 740A - 740D or at a different facility associated with enterprise 704.

[0294] As will be appreciated, the APM 710 has a direct and secure connection to the operational network and computing fabric of each of the enterprises 702, 704, 706, etc. that the APM 710 manages or supports. Thus, the APM 710 can simultaneously control the allocation of computer facilities or resources for each computing fabric for any supported enterprise. Additionally, the APM 710 can store and execute software or data analysis modules 782 that analyze operational data such as metadata from each of the computing fabrics 720, 740, 760 to calculate or determine various quality of service measurements or statistics for each of the computing fabrics 720, 740, and 760 of the enterprises 702, 704, and 706. Specifically, the data analysis module 782 can determine communication latency, CPU usage, and other computing operation statistics that indicate or define the quality of service provided or obtained within any one of the computing fabrics 720, 740, 760 by the computer hardware used in the computing fabrics 720, 740, 760 (regardless of who provides the computer hardware or where the computer hardware is physically located). Such data analysis or quality of service measurements can be used by the APM 710 to make changes to the underlying configuration of the computing fabrics provided or managed by the APM 710 in order to increase or change the quality of service provided to an enterprise or a portion of an enterprise, for example, to meet expected, guaranteed, or licensed quality standards such as those enforced by agreements between the APM 710 and the respective enterprise owners of the enterprises 702, 704, and 706. The APM 710 can make these changes by making configuration changes within the computer hardware of the computing fabrics 720, 740, 760 via the secure connection 780, and / or can interface with any third-party provider of the computer hardware or computing facilities used in the computing fabrics 720, 740, and 760, such as interfacing with a cloud computing provider like Microsoft Azure. Of course, the APM 710 can change the configuration, quantity, identity, or any other configuration component of the computer equipment used in or licensed from a third party in order to provide the computing fabrics 720, 740, 760 in any desired manner. In this way, the APM 710 has continuous control over the quality of service and configuration of the computer equipment provided or licensed by the APM 710 and provided to the enterprises 702, 704, 706, which enables the APM 710 to maintain an adequate or expected quality of service for control systems used or implemented in those enterprises.

[0295] Similarly, the APM 710 can interface directly with user interfaces (such as user interfaces 730, 756, and 772) associated with different enterprises 702, 704, 706 so that enterprise managers at user interfaces 730, 756, 772 can obtain additional licenses for additional computing infrastructure equipment, initiate the additional computing infrastructure equipment, and provide additional or new software products or containers (developed by the APM 710 or by third-party developers) to the enterprise owners or managers.

[0296] In any case, the APM 710 can analyze the data it receives from computing structures 720, 740, 760 in any desired manner and at any grouping level. For example, as shown in chart 790 of Figure 7 , the APM 710 can obtain and accumulate data from various different computing structures 720, 740, and 760 of enterprises 702, 704, and 706 and analyze the data from all these enterprises together to obtain an overall measurement of the quality of service provided by the APM 710. The combined enterprise data is shown by box 792 in chart 790. Additionally, the APM 710 can analyze the data from each computing structure 720, 740, 760 separately to provide per-enterprise statistics or quality of service measurements and can communicate separately with each enterprise to provide quality of service measurements or other statistical measurements associated with the entire enterprise. Such measurements or data are shown by charts 794A, 794B, and 794C for enterprises 702, 704, and 706 respectively. Furthermore, the APM 710 can perform or determine analytical measurements or other analyses (such as quality of service measurements) on a per-enterprise basis at a per-physical location basis (as shown in chart 796 of Figure 7 ), on a per-control system basis, on a per-container set basis, on a per-container basis, or in any other way or based on any other grouping of components within or associated with containers, modules, programs, control systems, etc. executing in computing structures 720, 740, 760. Of course, the APM 710 can prepare or perform the analysis in any other desired manner or perform analyses associated with any other grouping of factory hardware, software, containers, computing structure hardware, etc. If desired, the enterprise owner can agree to or be provided with different reports based on various predefined or desired groupings of hardware and / or software elements (at any level) within the computing structure of the enterprise.

[0297] The APM 710 can also perform other types of analysis on any grouping of data associated with one or more of the enterprises connected to the APM 710, and can provide enterprises with suggestions regarding potential changes to be made within the enterprise to improve performance, quality, etc. within the enterprise or a component of the enterprise (such as at a physical location, a group of control systems, a control loop, a group of control loops with similar functions, etc.). For example, the APM 710 can 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 can be made to improve control within the enterprise. As a specific example, the APM 710 can analyze data related to the operation of a control loop or a group of control loops within an enterprise (such as a control loop for controlling specific hardware at one or more plant locations), and can analyze timing signals, process variable measurements, response times, control loop statistics, etc. to determine whether one or more changes to the analyzed components can provide better performance in some way. The APM 710 can use the results of the analysis to suggest various hardware and / or software configuration changes, operations to be performed, or actions to be taken (such as running an adjustment process, etc.) to provide better control operations, such as better control of signal timing, fluctuations, product quality, operating costs, etc. In some cases, the APM 710 can suggest new or different types of control or control loop algorithms, new adjustments to process control equipment or control loops, additional control algorithms or different control algorithms that may be useful, different equipment that may be used, different control hardware or software configurations, such as changing the fixing or assignment of containers or groups of containers executed within a computing structure. Similarly, the analysis can be performed at any level, such as at the enterprise level, physical plant or location level, control loop level, control module level, container level, container group level, computer equipment level, etc. Of course, the APM 710 can use data from multiple different enterprises or control systems, from a single enterprise, from a subset of components within an enterprise, etc. to perform other types of data analysis. In some cases, the APM 710 (which has access to data from multiple different enterprises) can look for commonalities or differences between operations at different locations or different hardware within the same enterprise or at different locations or hardware of different enterprises to look for commonalities or differences in performance. Then, the APM 710 can perform further data analysis to determine the sources or causes of those differences, including differences that make control systems (control loops, control plants, etc.) operate better or worse than each other or better or worse than a baseline or average. Then, the APM 710 can provide the enterprise with the analysis results for making changes. Specifically, the APM 710 can return a report or analysis to the enterprise so that the enterprise can consider making changes to the control systems implemented by the enterprise. In some cases, the APM 710 can provide one or more products or containers for the enterprise to use to implement the suggested changes.

[0298] In addition, as Figure 7 shown for 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) and one or more configuration applications. The configuration databases store configuration elements for the enterprise or for portions of the enterprise, and the configuration applications enable a user to view, change, and manipulate the configuration databases to effect and implement configuration changes for the enterprise, including configuration changes within components executed within the computing fabric of the enterprise and within or associated with hardware within one or more physical locations of the enterprise. The configuration databases of the configuration system 800 may store, for example, a library of elements (such as, containers, modules, applications, products, etc.) used within the enterprise, and may store information defining the identity and configuration of each element, group of elements, container, control system, etc. currently operating within the computing fabric or within devices within the physical locations of the enterprise. Additionally, the configuration applications may enable an enterprise owner or manager to view the configuration of any element of the enterprise and make changes thereto, including making changes to control systems, adding or deleting logical or physical equipment or components (and even physical locations) from the enterprise system, changing the location or fixation of various different resources or components (such as, containers) within the computing fabric, adding new field devices, I / O devices, etc. Further, the applications of the configuration system may effect configuration changes by downloading or changing logical or software elements (such as, containers) within devices within the computing fabric or at physical locations in accordance with the user's changes upon the user's instruction. Since the control elements within the computing fabric are generally not bound to specific computer hardware within the computing fabric, the configuration system 800 can easily make changes, deletions, additions, etc. to the elements actually operating within the computing fabric without the user specifying exactly where to install those components, enabling the user to specify the logical configuration changes to be made and press a button to effect those changes in the actual hardware currently operating within the computing fabric. The underlying computing fabric management system may then locate (or assign) the computer hardware for the components implementing the changes or the new components and effect the changes seamlessly for the user. Although the configuration system 800 is shown as stored within and executed within the computing fabric of the enterprise, one or more components of the configuration system 800 may be located in computer hardware at one or more physical locations of the enterprise, in off-site computing fabric resources, distributed or shared between the computing fabric at one or more physical locations and off-site or licensed computing fabric hardware, stored in a dedicated machine within the computing fabric or at one or more physical locations, or in any other manner.

[0299] Figure 8AThe operation of the configuration system 800 in an enterprise is shown in more detail to show how an enterprise owner, operator, or other user can use the configuration system 800 to control and make configuration changes to the enterprise or any part thereof in a quick and easy-to-use manner. In fact, in some cases, the configuration changes can be provided, in essence, via a one-click push mechanism that can be used to install additional software or new software components or upgrade the software within the enterprise's computing fabric. More specifically, Figure 8A a configuration system 800 is shown that can be used at, for example, one of the enterprises (such as Figure 7 enterprise 704) 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 easily achievable manner.

[0300] As will be seen, Figure 8A a configuration system 800 for an enterprise is shown communicatively coupled to an APM 805 and a product / container registry 807. Generally, the enterprise configuration system 800 is located in and executes within the enterprise to which it belongs, such as within the computing fabric of the enterprise to which it belongs. However, some or all of the configuration system 800 can be stored and executed in hardware (which may or may not be part of the enterprise computing fabric) at one or more physical locations of the enterprise, at one or more dedicated hardware locations for the enterprise external to the computing fabric, or at any other location. However, importantly, the enterprise's configuration system 800 is connected to or integrated into the enterprise's computing fabric so as to be able to make changes directly to elements within the enterprise's computing fabric using the management fabric of the computing fabric. As Figure 8A shown, 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 configuration information of the enterprise, as currently configured. The configuration database can include one or more physical databases that house data and relationships, such as the configuration of control modules and the relationships between them. Importantly, the configuration applications 802 can include one or more user interface applications that generate one or more user interfaces, such as the user interface 822 shown in more detail in Figure 8B which enables a user (such as a configuration engineer at the enterprise) to take different actions regarding changing or upgrading the control system or any of its elements or components. As will be understood, the user interface 822 can be displayed on any computer of the enterprise and can be provided to off-site computers associated with the enterprise via the APIs discussed previously but not shown in Figure 8A . In addition, the configuration engine 804 interfaces with the runtime system (such as the orchestrator and associated applications described herein) to effect configuration changes within the enterprise (such as within the computing fabric of the enterprise).

[0301] AsFigure 8A As shown, configuration system 800 is connected to APM 805 via communication connections such as those shown and described with respect to Figure 7 those shown and described, and can coordinate with APM 805 to make certain types of configuration changes, such as permitting new software or hardware components from an APM or third-party managed or licensed computing fabric, reducing, increasing, or changing the hardware configuration within a computing fabric provided by the APM (or third-party hardware provider), etc. Additionally, configuration system 800 is connected to a product or container registry 807, and the configuration system can obtain new components, such as new containers, products, upgrades, etc., from the product or container registry. Configuration system 800 can access the product registry (which is outside the enterprise's computing fabric) using any of the security features previously discussed. Generally speaking, configuration system 800 includes components that interact with each other and with APM 805 and product / container registry 807 to enable a user to specify and implement configuration changes within the enterprise. These configuration changes can include adding new physical locations, adding new or changed computers or field device hardware (e.g., field devices, I / O devices, gateway devices, etc.) at new or existing physical locations, adding, deleting, or changing logical components (e.g., containers, control modules, control routines, monitoring routines, etc.) within the enterprise's computing fabric, changing fixed or other specified relationships between logical components within the computing fabric and / or between logical components and specific computing fabric hardware, etc.

[0302] As an example, one or more configuration applications 802 within configuration system 800 can be used to view the current configuration of various different elements of the enterprise (including both hardware and software elements). Additionally, one or more configuration applications 802 can be used to enable a user to make changes to the configuration of the enterprise, such as adding new hardware and / or software elements, changing one or more hardware or software elements, deleting one or more hardware or software elements, changing the way one or more software elements such as containers are fixed to other software or hardware elements, adding new physical locations or hardware at one or more physical locations, changing the configuration of elements at one or more physical locations, specifying or changing the configuration of computer hardware within or associated with the computing fabric of the enterprise or a part of the enterprise, and / or implementing any other desired configuration changes.

[0303] In one example, as Figure 8BAs shown in more detail, the user interface 822 can provide a configuration display screen that enables a user to view and make changes to the configuration of components within an enterprise. In this example, the display screen 822 includes a configuration hierarchy section 834 and a diagramming or programming section 836 that a configuration engineer or other user can use to graphically represent one or more configuration components and / or enable the configuration engineer (or other authorized user) to graphically program or make changes to the enterprise configuration at any level. For example, a user can make changes to the configuration at the enterprise level (i.e., across the entire enterprise), at the sub-enterprise level (such as at one of the physical locations of the enterprise, at any grouping of components within the enterprise's computing structure, etc.).

[0304] As Figure 8B shown, the hierarchy section 834 can include a hierarchy display that shows the various different configuration components (or any other grouping of components) of the enterprise at the various levels or sub-levels of the enterprise to show the configuration components of the enterprise that currently exist in an organized and easily locatable manner. For example, the enterprise hierarchy 834 can include a library section 840 that includes a storage of configuration components such as control modules, control routines, function blocks, containers, and / or copies of any other configuration components stored as library components in a configuration database. These library components can be copies or generic versions (i.e., non-instantiated versions) of control components that exist within the enterprise system (such as at one of the physical locations of the enterprise or within the computing structure). In addition, the hierarchy section 834 can include a configuration database section 841 for accessing the actual configuration database of the enterprise, a physical network section 842 that includes information about each deactivated node or location and each currently debugged physical location of the enterprise 843. As shown for physical location 1, each physical location can include configuration and identifier information about the gateway, I / O devices, field devices, communication networks, etc. at that physical location. Such components can include, for example, the I / O devices and gateway devices at each physical location, the field devices and communication devices set at each physical location, databases, communication structures, etc. In addition, other physical I / O networks such as wireless networks can be listed under section 844. In addition, the hierarchy section 834 can include a hierarchy of installed configuration components, such as configuration components associated with each physical location, with each control routine or control module in a set of control routines or control modules, or any other control structure, etc.

[0305] In addition, the hierarchical structure 834 may include an indication of control logic or control elements (e.g., containers) in the computing structure under the computing structure part 845. Elements in the computing structure may include, for example, logical or virtual controllers, control modules, containers, etc., and may indicate the manner in which these elements are fixed or otherwise associated or grouped (e.g., assigned) with each other during runtime. The control elements may also include or show digital twins associated with iOS devices or field devices in various locations, and may include any grouping or configuration grouping of containers or other elements. Similarly, other groupings of containers or control elements in the computing structure may be listed, such as assigned I / O and third-party containers. Similarly, the configuration hierarchical structure 834 may show support elements, such as one or more batch or continuous histories, batch executors, recipes, advanced control elements, data analysis programs or software (such as artificial intelligence (AI) programs or algorithms), monitoring software, etc., which are bound to and operate within an enterprise (such as within the computing structure of an enterprise). Of course, it should be understood that the user may drill down into each part of the hierarchical structure 834 to view or access more information and details about these elements and the sub-elements listed therein.

[0306] The diagram or programming area 836 of the display 822 can be used to add, change, delete, reconfigure, program, and / or otherwise create configuration elements to be installed within an enterprise (such as within the computing structure of an enterprise or in devices at one or more physical locations of an enterprise). Specifically, the user can select and view one or more elements of the hierarchical structure 834 and place these elements (or copies thereof) in the programming area 836. Then, the user can graphically make changes to these elements to indicate the changes to be made to the configuration of these elements. In other cases, the user can add or copy library elements within the hierarchical structure part 834 to the programming area 836 and then edit these elements to create new configuration elements for the control system within the enterprise. In other cases, the user can download or obtain one or more new configuration elements from an external source or database (such as from the product / container registry 807). Of course, the configuration application 802 can also enable the user to add, change, delete, or otherwise modify configuration elements in any other way.

[0307] For another example, the user interface 822 may provide a pop-up window 850, which can display various actions that can be taken by a configuration engineer or user in the diagram or programming area 836 to perform configuration activities. Specifically, the window 850 may include a copy button 852, an add button 854, and an upgrade button 856, an assign button 858, an import new hardware button 860, a change button 862, a deploy button 864, an implement button 866, etc. Although Figure 8BWindow 850 shows these various specific buttons associated with the specific configuration actions to be taken, but window 850 may provide or list other configuration actions that can be enabled via pop-up window 850. Additionally, display 822 may enable these or other configuration actions via other types of input or commands, such as using drop-down menus, radial buttons, new screens, drag-and-drop actions, etc.

[0308] In any case, a user such as a configuration engineer of an enterprise can access or select some elements in enterprise hierarchy 834, such as library elements or...

Claims

1. A method for a process control or automation system, the method comprising: communicatively connecting a physical device and an instantiated micro - encapsulated execution environment (MEEE) by the process control or automation system and via a secure point - to - point (PTP) or peer - to - peer (P2P) connection, the physical device performing physical functions for controlling an industrial or automation process provided by an enterprise; and delivering information between the physical device and the instantiated MEEE by the process control or automation system and via the secure PTP or P2P connection to control at least a portion of the industrial or automation process.

2. The method according to claim 1, wherein the secure PTP or P2P connection is a secure, encrypted PTP or P2P connection.

3. The method according to any one of the preceding claims, wherein the secure PTP or P2P connection is a virtual private network (VPN).

4. The method according to any one of the preceding claims, wherein the secure PTP or P2P connection is a secure P2P connection.

5. The method according to any one of the preceding claims, wherein the secure PTP or P2P connection (i) serves only the instantiated MEEE and the physical device exclusively, or (ii) serves only the instantiated MEEE and an intermediate device communicatively disposed between the physical device and the instantiated MEEE.

6. The method according to any one of the preceding claims, wherein: communicatively connecting the instantiated MEEE and the physical device via the secure PTP or P2P connection includes: communicatively connecting the instantiated MEEE and the physical device via a plurality of secure connections, the plurality of secure connections including the secure PTP or P2P connection and at least one of the following: another secure, encrypted PTP or P2P connection, a secure point - to - multi - point (PTM) connection, or a secure multi - point - to - multi - point (MTM) connection.

7. The method according to claim 6, wherein at least two of the plurality of secure connections are at least partially nested secure connections.

8. The method according to any one of claims 6 to 7, wherein two or more of the plurality of secure connections are mutually exclusive secure connections.

9. The method according to any one of claims 6 to 8, wherein the plurality of secure connections includes a plurality of virtual private networks (VPNs).

10. The method according to any one of the preceding claims, wherein the instantiated MEEE is an endpoint of the secure PTP or P2P connection.

11. The method according to any one of the preceding claims, wherein communicatively connecting the physical device and the instantiated MEEE via the secure PTP or P2P connection comprises: Communicatively connecting the physical device and the instantiated MEEE via a gateway communicatively disposed between the physical device and the instantiated MEEE.

12. The method according to claim 11, wherein the gateway and the physical device are disposed at a first physical location or site, and the instantiated MEEE is executed on a hardware platform disposed at a second physical location or site.

13. The method according to any one of claims 11 to 12, wherein the instantiated MEEE is the first endpoint of the secure PTP or P2P connection, and the gateway is the second endpoint of the secure PTP or P2P connection.

14. The method according to any one of claims 1 to 12, wherein: the process control or automation system further includes I / O hardware, which is communicatively arranged 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 physical component uniquely identified in the process control or automation system; the instantiated MEEE is the first endpoint of the secure PTP or P2P connection; and the physical component is the second endpoint of the secure PTP or P2P connection.

15. The method according to any one of the preceding claims, further comprising: authenticating and / or authorizing, by the process control or automation system for the first time, the identity of the physical device or the identity of an intermediate device communicatively arranged between the physical device and the instantiated MEEE to communicate via the secure PTP or P2P connection; and authenticating and / or authorizing, by the process control or automation system for the second time, the identity of the instantiated MEEE to communicate via the secure PTP or P2P connection, and wherein communicatively connecting the instantiated EE and the physical device via the secure PTP or P2P connection is based on the first authentication and / or authorization and the second authentication and / or authorization.

16. The method according to the preceding claim, further comprising at least one of the following: not authenticating and / or authorizing the identity of the physical device or the identity of the intermediate device to communicate via another secure PTP or P2P connection within the process control or automation system; or not authenticating and / or authorizing the identity of the instantiated MEEE to communicate via another secure PTP or P2P connection within the process control or automation system.

17. The method according to any one of the preceding claims, wherein: communicatively connecting the physical device and the instantiated MEEE via the secure PTP or P2P connection includes: establishing a session between the physical device and the instantiated MEEE via the secure PTP or P2P connection; and delivering the information includes: delivering the information via the established session.

18. The method according to any one of the preceding claims, wherein: the instantiated MEEE is included in a plurality of instantiated MEEEs of the process control or automation system; and The method further includes communicatively connecting, by the process control or automation system and via a respective secure PTP or P2P connection, each instantiated MEEE of the plurality of instantiated MEEEs to at least one of: a respective physical device, a respective intermediate device communicatively disposed between the respective physical device and each instantiated MEEE, or another instantiated MEEE.

19. The method of claim 18, wherein the respective secure PTP or P2P connection is a respective secure, encrypted PTP or P2P connection.

20. The method of claim 19, wherein the respective secure encrypted PTP or P2P connection is a respective virtual private network (VPN).

21. The method of any one of claims 18 to 20, wherein the respective secure PTP or P2P connection serves only the respective instantiated MEEE and at least one of the respective physical device, the respective intermediate device, or the other instantiated MEEE.

22. The method of any one of claims 18 to 19, wherein each instantiated MEEE is a first endpoint of the respective secure PTP or P2P connection and at least one of the respective physical device, the respective intermediate device, or the other instantiated MEEE is a second endpoint of the respective secure PTP or P2P connection.

23. The method of any one of claims 18 to 22, further includes authenticating and / or authorizing, by the process control or automation system, the respective identity of each instantiated MEEE to communicate via the respective secure PTP or P2P connection; and wherein communicatively connecting each instantiated MEEE via the respective secure PTP or P2P connection is based on the authentication and / or authorization of the respective identity of each instantiated MEEE.

24. The method of any one of claims 18 to 23, wherein each instantiated MEEE of the plurality of instantiated MEEEs is identified within the process control or automation system by a respective unique identifier.

25. The method of any of the preceding claims, wherein: the physical device is included in a plurality of physical devices; and the method further includes communicatively connecting, by the process control or automation system and via a respective secure PTP or P2P connection, each physical device of the plurality of physical devices to a respective instantiated MEEE.

26. The method of claim 25, further includes authenticating and / or authorizing at least one of: the respective identity of each physical device, or the respective identity of a respective intermediate device communicatively disposed between each physical device and a respective receiving device; and Each of the physical devices is communicatively connected to the respective instantiated MEEE via the respective secure PTP or P2P connection based on authentication and / or authorization of at least one of the respective identities of each of the physical devices or the respective identities of the respective intermediate devices.

27. The method according to any one of claims 25 to 26, wherein a first portion of the plurality of physical devices is disposed at a first physical location or site, a second portion of the plurality of physical devices is disposed at a second physical location or site, and the instantiated MEEE is included in a plurality of instantiated MEEEs that are executed on a hardware platform disposed at one or more other physical locations or sites.

28. The method according to any one of claims 25 to 27, wherein each of the plurality of physical devices is identified within the process control or automation system by a respective unique identifier.

29. The method according to any one of the preceding claims, wherein the physical device is a field device configured to perform a physical function in response to a control signal generated by the instantiated MEEE or by another instantiated MEEE.

30. The method according to any one of the preceding claims, wherein the instantiated MEEE is a virtual process controller or a virtual safety controller that operates on the received data to generate a control signal to which the physical device can operatively respond.

31. The method according to any one of the preceding claims, wherein the instantiated MEEE operates on the information received from the physical device to generate a control signal to which the physical device or another physical device can operatively respond.

32. The method according to any one of the preceding claims, wherein the instantiated MEEE is included in a plurality of instantiated MEEEs, and the plurality of instantiated MEEEs includes at least one of the following: 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 wiring 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 providing a subsystem of the process control or automation system; or a service providing the business logic of the process control or automation system.

33. The method according to the preceding claim, wherein the business logic of the process control or automation system comprises at least one of the following: monitoring application or service, operating application or service, diagnostic application or service, dashboard application or service, user interface application or service, analytics application or service, security routine application or service, reporting application or service, history application or service, configuration application or service, simulation application or service, process control resources and / or resource management services, automation resources and / or resource management services, external communication applications or services, alert applications or services, licensing applications or services, or third-party applications or services.

34. The method according to any one of the preceding claims, wherein the instantiated MEEE is included in a plurality of instantiated MEEEs, and the plurality of instantiated MEEEs comprises a packet router or switch service.

35. The method according to any one of the preceding claims, wherein the instantiated MEEE is included in a plurality of instantiated MEEEs, and the plurality of instantiated MEEEs comprises at least one of the following: software-defined computing service, software-defined storage service, or software-defined networking service.

36. The method according to any one of the preceding claims, wherein the instantiated MEEE is included in a plurality of instantiated MEEEs, and the plurality of instantiated MEEEs comprises at least one of the following: life cycle management service, discovery service, security service, encryptor service, certificate authority subsystem service, key management service, authentication service, time synchronization service, resource and / or resource group management service, service location service, and / or console support service.

37. The method according to any one of the preceding claims, wherein the instantiated MEEE is an instantiation of a packaged software component that has been configured by the process control or automation system.

38. The method according to the preceding claim, wherein the packaged software component is a software container, a software agent, or bare-metal software.

39. The method according to any one of claims 37 to 38, the method further comprising: The packaged software component is configured by the process control and automation system based on a configuration database of the process control or automation system.

40. The method according to any one of claims 37 to 38, the method further comprising: By the process control or automation system, and in response to a condition detected or predicted by the process control or automation system, perform at least one of the following: Create the packaged software component; Configure the packaged software component; or Instantiate the configured, packaged software component.

41. Any combination of any one of the preceding claims and any other of the preceding claims.

42. A process control or automation system configured to perform the method according to any one of the preceding claims.

Images