Location-specific communication gateway for multi-site enterprise

Abstract

A process plant and industrial control system architecture includes a general purpose computing fabric that is agnostic or irrelevant to a physical location where the computing fabric is implemented; comprising one or more physical control or field devices located at one or more specific plant sites for manufacturing a product or process; and also includes a transport network securely providing communication between the computing fabric and the pool of physical devices using a communication gateway device at each plant site that provides secure communication between the computing fabric and the one or more physical control or field devices at each plant site. The communication gateway at each plant site implements one or more secure peer-to-peer or peer-to-peer communication networks between the computing fabric and the plant site using one or more virtual private networks.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application is a continuation-in-part of U.S. patent application serial number 18 / 223416, filed on July 18, 2023, entitled “Monitoring and Operational Functionalities for an Enterprise Using Process Control or Automation System,” which claims priority to: U.S. provisional patent application serial number 63 / 417861, filed on October 20, 2022, entitled “Configuration Features of Next Generation Process Control and Automation Systems,” and U.S. provisional patent application serial number 63 / 418,006, filed on October 20, 2022, entitled “Enterprise-Level Features Provided by the NGPCAS,” the entire disclosure of each of which is hereby expressly incorporated herein by reference. Technical Field

[0003] The present application relates generally to industrial process control systems and automation systems for industrial process plants, and 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 of 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 pharmaceutical or other types of manufacturing) have typically included one or more dedicated process controller devices that are communicatively coupled to each other, to at least one host computer or operator workstation via a process control network, and 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 functions within a process or plant, such as opening or closing valves, connecting and disconnecting equipment, and measuring process parameters. Example field devices include valves, valve positioners, switches, and transmitters (e.g., a device that includes a sensor for measuring temperature, pressure, or flow rate and a transmitter 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 constraints of the plant and, specifically, in the vicinity of field devices), receives signals indicative of process measurements made by field devices (or other information related to the field devices); and executes a controller application that runs, for example, various control modules that make process control decisions, generates control signals based on the received information, and communicates with smart field devices (e.g., and Fieldbus field devices) in the control module or block coordination.

[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 running or executing within the plant or system). For example, a first set of controllers and field devices may control a first portion of a process 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"), also typically located within a plant environment, are typically communicatively disposed between a controller and one or more field devices to enable communication therebetween (e.g., by converting electrical signals to digital values ​​and vice versa). Typically, an I / O card serves as an intermediary device between a process controller and one or more field devices, which have inputs or outputs configured for one or more communication protocols that are the same as the communication protocol utilized by the I / O card.

[0009] Field devices, controllers, and I / O devices are often collectively referred to as "process control equipment" and are typically located, arranged, 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 intermediary devices that facilitate communication between the controllers and the field devices may be referred to as an "I / O network" or "I / O subsystem."

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

[0011] Information transmitted over a process control network enables an operator or maintenance personnel to perform desired functions with respect to a process via one or more hardware devices connected to the network. These hardware devices may run applications that enable an operator or other user (such as a configuration engineer or maintenance personnel) to, for example, configure process controllers, I / O devices, and field devices, change settings for process control routines, modify the operation of control modules within a process controller or intelligent field device, view the current state of a 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 a 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 may include wired communication paths, wireless communication paths, or a combination of wired and wireless communication paths.

[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. In addition, a communication network typically includes dedicated routers (including firewalls) responsible for directing traffic between the communication nodes, and optionally dedicated devices responsible for configuring and managing the network. Some or all of the communication nodes may also be adapted to act as routers to direct traffic sent between other network devices. Network devices may be interconnected in a wired or wireless manner, and network devices may have different routing and transmission capabilities. For example, dedicated routers may be capable of high-capacity transmission, while some communication nodes may be capable of sending and receiving relatively less traffic within the same time period. In addition, the connections between communication nodes on the network may have different throughput capabilities and different attenuation characteristics. For example, fiber optic cables may provide bandwidths several orders of magnitude higher than wireless links due to differences in the physical or fundamental limitations inherent in the medium.

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

[0014] Much like the OSI model for network communications, which conceptually organizes computer communication networks into layers, the Purdue model divides industrial process architectures into multiple levels and zones. Levels 0, 1, 2, and 3, respectively, represent physical processes (e.g., physical equipment and accompanying physical I / O devices acting as controlled field devices), basic control (e.g., controllers, PLCs, etc. that monitor and control Level 0 equipment and safety instrumented systems), regional supervisory control (e.g., operator workstations and human-machine interfaces (HMIs), historians, configuration, etc., as well as Supervisory Control and Data Acquisition (SCADA) functionality and other control logic that analyzes and acts on Level 1 data), and field operations (e.g., plant-wide control and monitoring, data aggregation, reporting, etc.), and are part of the manufacturing zone. Levels 4 and 5, respectively, represent the enterprise's business and logistics systems (e.g., database servers, application servers, file servers, etc.) and the enterprise or corporate network (e.g., the broader collection of enterprise information technology (IT) systems, including connections to the public internet), and are part of the enterprise zone. A demilitarized zone (DMZ) lies between the enterprise zone and the manufacturing zone. Process control levels 0-2 generally require a higher level of trust in the security and validity of messages, packets, and other communications, while manufacturing, corporate, and enterprise systems in levels 3-5 generally require a lower level of trust. For example, process plant systems, networks, and equipment at security levels 0-3 may be protected from threats originating from an enterprise network at security levels 4-5 and / or from any external network above security level 5 that utilizes the enterprise network, such as by using a DMZ and / or one or more firewalls.

[0015] As industrial processes and the associated control systems used for these processes become more complex, operational technology (OT) that enables industrial control (i.e., systems that monitor events, processes, and equipment and make adjustments within industrial operations) has begun to merge with the information technology (IT) that has been developed around it (i.e., systems for data-centric computing and analysis). Data from OT systems is now sought and analyzed by various IT systems. For example, data from the operational level of a factory can be used by various IT systems (e.g., at the enterprise level) to monitor factory efficiency, create or update production plans, product delivery plans, and the delivery of input materials, among many other purposes. However, achieving the desired level of security within the Purdue model is extremely difficult 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. Transmitting 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 a number of security solutions, including a proliferation of data relays, data diodes, and firewall devices. In some implementations, to mitigate communication issues caused by these complex safety features, system providers and / or site engineers have prevented the Purdue model from sending data directly from control devices to the cloud, which undermines the plant safety features provided by the Purdue model.

[0016] Further complicating matters, OT systems are often older systems incompatible with generally accepted principles of good security hygiene on IT networks, as OT networks are often designed without IT security in mind. For example, OT systems typically do not support modern identity and authentication / authorization protocols or practices, at least not at the level of field devices and controllers. This often leads to various data transmission practices that are incompatible with highly secure networks. For example, there may be three or more domains between Layers 2 and 4 of a process, and security policies may differ for each of these domains. Consequently, cross-layer connectivity can be challenging, leading to implementations where holes are punched in firewalls to access data between layers, credentials are hard-coded into devices or applications, and / or passed in unencrypted form to maintain connectivity. Furthermore, for the reasons mentioned above, integrating third-party software is difficult, error-prone, and often insecure, and vulnerabilities are often left unpatched because the resulting downtime would result in significant costs to plant operators. These shortcomings 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 portions of the industrial control systems to general-purpose computing resources such as the cloud, and to virtualize certain aspects of the industrial control systems. The purpose of these attempts has been to capture and analyze the ever-expanding amounts of data generated in industrial control systems, as well as to create, for example, virtualization redundancy. However, adhering to the Purdue Model and the associated security practices it requires has caused these attempts to each suffer from one or more of the disadvantages detailed above, while also having 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 IT infrastructure (whether locally or remotely), 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., virtualization). To this end, entire controllers have been virtualized so that they can be executed on less specialized hardware (e.g., on a server or shared computing hardware), allowing multiple copies of the control algorithm to be executed in parallel on different hardware, so that one instance can be used as a backup for another master instance. If the master instance fails or becomes unstable, control can be transferred to the backup instance, and the original master instance can be shut down and re-instantiated on the same or different hardware. Although such systems have some advantages in terms of controller redundancy, because the entire controller 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. In addition, these systems require that all elements of the virtualized device (e.g., controller) be copied or moved together or simultaneously, which limits the flexibility of these systems. Summary of the Invention

[0019] The new process plant and industrial control and / or automation system architecture enables a large amount of computer processing and IT infrastructure (referred to herein as a compute fabric) used to support a process plant, industrial control facility, or other automation facility to be implemented in a shared, off-site, and / or virtualized manner, which alleviates many of the communication and security issues that exist in current process and industrial control systems that attempt to implement control using shared or virtualized computing resources (such as cloud-based computing or system resources). Specifically, when integrating and providing communications between plant devices (such as field devices), equipment 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. Therefore, when supporting control functions associated with a process plant or industrial automation facility, the system architecture can implement control functions, communications, and security measures in a more efficient manner using communication and security features developed for general computing uses outside of the process plant environment.

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

[0021] In general, a computing structure includes a physical layer that includes one or more computer processing and / or storage devices, and an application layer that 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 structure can be implemented as one or more groups of configuration containers or as a containerized system, where various different configuration containers and different types of containers perform different computer-implemented functions relative to the facility or enterprise in which the control system is implemented. The physical layer of the computing structure 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 computer processors and databases at one or more dedicated off-site locations separate from the plant, facility, or site where the physical device pool is located, on computer equipment located at the physical plant or facility where the physical device pool is located, or any combination thereof. The new control system architecture also includes a network layer that is positioned 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 required by application layer activities, and specifically supports timing and other requirements that are specific to and required for industrial process control and automation.

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

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

[0024] During operation, the computing structure can use one or more transmission networks to communicate with a pool of physical equipment located at one or more physical locations. The transmission network can use any desired communication infrastructure and communication protocol, including any desired wired and / or wireless communication equipment / protocol. Such protocols can be any of a variety of process control protocols, such as HART, WirelessHART, Foundation Fieldbus, Profibus, OPC UA, and / or can be any of a variety of general-purpose computing communication protocols. For example, the transmission network can use any IP-based or packet-based protocol, including protocols that utilize publish and subscribe protocols such as MQ Telemetry Transport (MQTT) and Advanced Message Queuing Protocol (AMQP). In addition, the transmission network can use or include any desired communication network physical layer, such as Ethernet, 802.11, Advanced Physical Layer (APL), and other physical layers. In this way, the physical device pool can send data or information to one or more configuration containers in the computing structure in packet form via one or more transmission networks and can receive data or information from them, so that the computing structure can implement process control, monitoring, and configuration activities regarding the physical device pool. Furthermore, in some embodiments, virtual networks such as VNets can be used to communicatively connect different remote infrastructures (e.g., which can be implemented via different cloud computing systems and / or via other suitable means) and to communicatively connect different physical locations (e.g., local infrastructure) with remote infrastructure. For network security reasons, virtual networks can be routed through virtual private networks (VPNs). For reliability purposes, different VNets can be used for different network providers (e.g., AT&T and Verizon). A more detailed description of VPNs is provided elsewhere in this document.

[0025] A single communication gateway device may be used at each of the physical locations or plant sites where physical devices are located to implement a variety of different communication networks established between the computing fabric and the plant site or physical devices at the plant site, including secure point-to-point or peer-to-peer networks, each of which may be implemented as a virtual network or VNET. These networks may be protected by a communication gateway device that may implement or use different secure communication networks for different purposes, such as for control networks, monitoring networks, management networks (including enterprise management networks and computing fabric provider or manager management networks), and the communication gateway device may establish different networks for different containers or containerized components within the computing fabric and the physical devices at the plant site.

[0026] The computing fabric 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 physical device pools. Thus, in some embodiments, at least a portion of the computing fabric may be implemented on a cloud computing platform, the hardware of which may be located remotely from the physical location of the on-site environment where the physical device pools are located.

[0027] In general, the computing fabric 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 may include applications configured into containers and / or services configured into containers, each of which executes to provide specific functionality and / or operations utilized by a control system 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. In general, containerized components provide the functionality that traditional process control and automation technologies typically implement via a variety of systems, networks, computing devices, DMZs, firewalls, and applications operating across levels 2-5 of the Purdue model, such as supervision, monitoring, and control of physical industrial processes and data acquisition at level 2 to enterprise-level IT functionality at level 5 that provides business direction and functionality related to the system. In addition, containerized components can provide even higher levels of functionality, such as coordination and / or management between multiple systems of an enterprise or even coordination between multiple enterprises. Thus, and advantageously, rather than utilizing the cumbersome and resource-consuming traditional architecture of Purdue Levels 2-5 and all of the numerous digital diodes, firewalls, DMZs, etc. necessary to secure the process control or automation system in the traditional architecture, the control architecture described herein utilizes only a set of containerized components executed in a computing structure to perform the same or similar set of process control and automation core functionality and related functionality without compromising the security of the system and, in some arrangements, providing greater security than what might be provided by the traditional architecture.

[0028] Furthermore, different functionalities can be implemented by different containerized components within the computing fabric, and thus a single application or service can be configured into multiple different containerized components (e.g., different instances of the application or service implemented in corresponding containers). In this way, similar or related configuration containers can be executed in conjunction with different physical devices and can be executed on different parts of the hardware platform of the computing fabric, for example, to create redundancy or hot backup, etc. Advantageously, various containerized components can be created (e.g., started) and / or removed as needed or when needed, and a group 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.

[0029] Furthermore, during execution, each containerized component may be communicatively connected to a particular physical component or physical device or another containerized component via a corresponding packet-based connection over a transport network, such that each containerized component and each physical component may be identified within the system by a unique name or identity that may be associated with a particular address (e.g., an IP address) within the transport network. To maintain a high level of communication security, the containerized components and the physical components may 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. Upon successful authorization and authentication, the two endpoint components may transmit data, instructions, and other information to each other during a session established between the two endpoint components over one or more transport networks.

[0030] To further protect the system, one or more transport networks may include one or more virtual private networks (VPNs), allowing, for example, specific containerized components to communicatively connect to specific physical components or other containerized components using point-to-point or peer-to-peer connections (such as VPNs) that are dedicated only to specific containerized components and specific physical components. 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 required. Furthermore, 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, point-to-point or peer-to-peer network connections can be utilized in place of or in addition to one or more point-to-point or peer-to-peer connections 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).

[0031] Advantageously, the architecture of the computing fabric abstracts (e.g., disconnects) higher-level, business logic services, subsystems, and other software components of the application layer from the specific computing platform or hardware associated with the computing fabric, and enables higher-level software-defined services, subsystems, and other software components to dynamically, automatically, and responsively direct and cause changes in the use of hardware and software resources of the nodes and clusters of the computing platform using, for example, APIs, operating system (OS) support, and other services of the network layer, without requiring any human intervention or guidance. Thus, management of the computing platform's resources can be dynamically responsive to configuration changes and the needs of higher-level software-defined services, subsystems, and other software components of the application layer.

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

[0033] As another example, a controller or control service in a computing structure may 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 may be functionally equivalent to a traditional dedicated hardware controller device as understood in the Purdue model, or the controller service may be functionally equivalent to a control routine or control module configured into and executed by a traditional dedicated hardware controller device. A container may be configured with an instance of a configured controller service, thereby forming a container image or instance of the configured controller service, which, when so configured, is capable of executing to perform a specific configured set of process control logic, such as by using configured control module containers, tags, reference values, etc. Multiple instances or container images of a configured controller service (or other configured applications and services) may be instantiated and executed by the computing structure.

[0034] Some configuration containers in the computing structure can be allocated or assigned to the corresponding computing nodes of the computing structure, and dynamically reassigned to different computing nodes by the software-defined computing service based on the dynamically changing configuration, performance requirements and other needs of the logical process control or automation system. In some cases, the configuration container can be assigned (and reassigned) to be executed by a specific processor or specific processor core of one or more computing nodes. However, some configuration containers can be fixed to the corresponding computing nodes and are therefore not dynamically reassigned by the computing service due to dynamically occurring conditions. The configuration container can be additionally or alternatively fixed to other physical or logical components of the computing structure. For example, a configuration container can be fixed to another configuration container, a specific data cluster, a specific processing resource (e.g., a specific physical processor or a specific physical processor core of a computing node), a physical rack or a portion of a physical rack (wherein the physical rack physically accommodates the hardware of one or more computing nodes) served by a specific power supply, etc. In addition, configuration containers can be nested within other configuration containers, which is particularly useful in configuring and organizing logical process control or automation systems.

[0035] The application layer of the computing structure may include other types of application layer services, such as operator display and handover, diagnostics, analysis, safety routines, reporting, data historians, service configuration, communication with external or other systems, enterprise-level applications, etc. In addition, a set of subsystems at the application layer of the computing structure may provide or implement other virtual or logical process control-related subsystems of the logical process control system. For example, the historian subsystem may include read services, write services, and search services, whose corresponding configuration containers are nested within the configured historian subsystem container. In another example, the batch process control subsystem may include unit procedure services, recipe services, and supervisory record generation services, which may be nested within the configured batch process control system container.

[0036] Generally speaking, subsystems allow control services and other services to be easily and consistently grouped and / or managed. In one case, each compute node of the compute structure hosts a corresponding instance of each subsystem in the set of subsystems, so that the subsystem services are readily available and easily available to other application layer services executed on each compute node. Therefore, changes to one or more subsystems can be coordinated between their corresponding instances executed at each compute node. Therefore, the group of subsystems is highly available and readily available to any application layer service executed on the compute node, and the functionality provided by the group of subsystems can be easily maintained for the logical process control system in the event of a compute node failure, a compute node component failure, or a specific subsystem failure. Subsystems may include continuous process control, event-driven process control, batch process control, state-based control, ladder logic control, history logs, process users, alarms, permissions, events, version control, process configuration, process I / O, etc.

[0037] In addition, in some specific implementations, the computing structure may implement digital twins of various software-defined application services, the entire software-defined application layer, various software-defined support services and / or the entire software-defined network layer. The digital twin of the target component / layer may execute consistently with the active target component / layer on the computing platform, and thereby 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 blocked 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. In addition, in some specific implementations, the computing structure may implement a digital twin of a physical component, which can be used as a proxy for the physical component during runtime operation.

[0038] Similarly, the computing structure can be used to support various 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 plant or facility operator displays to enable operator input from any location, providing containerized services from any location, providing and instantiating controls, other enterprise services, portions of process control systems or even entire process control systems from any location, moving the execution of services across different locations or sites, providing subscriptions or third-party services about the enterprise, providing centralized upgrades for the enterprise, and providing centralized monitoring of computing structures associated with the enterprise, etc. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0040] Figure 1B is a block diagram of an example architecture of a next generation process control and automation system ("NGPCAS") that may be used to control industrial and / or automation processes having an installed or legacy distributed control system therein.

[0041] Figures 2A to 2C Shown including digital twin Figure 1A and Figure 1B Portions of an example architecture for a next generation process control and automation system.

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

[0043] Figure 3B Shows that the Figure 1A and Figure 1B The computing structure provides example enterprise-level computing structure functionality.

[0044] Figure 4 Can be included in Figure 1A and Figure 1B A block diagram of an example architecture of the computing structure in NGPCAS.

[0045] Figure 5A is a block diagram illustrating a smart field device implementing embedded device identification (EDID).

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

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

[0048] Figure 5D Example information that may be stored as EDID is shown.

[0049] Figure 5E is a block diagram illustrating components in a computing architecture that may allow a process control system to secure and / or debug a process plant using EDID.

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

[0051] Figure 5G It is available in Figure 1A and Figure 1B An example of resource security technology utilized by NGPCAS.

[0052] Figure 6A An example manner is shown in which an enterprise may implement the NGPCAS described herein using a computing fabric hub and communication spoke configuration to support multiple different physical locations that may use different data and execution governance rules.

[0053] Figure 6B is a diagram illustrating an example system hierarchy associated with an enterprise using the NGPCAS described herein.

[0054] Figure 7 This shows the architecture provider / manager and their respective use Figure 1A and Figure 1B A diagram of the interconnection between multiple different enterprise systems of NGPCAS, which enables managers to supervise different enterprise systems and make quick and easy configuration changes to different enterprise systems.

[0055] Figure 8A is shown so that Figure 7 A diagram of a configuration system in which configuration activities at one of the enterprise systems can add, upgrade, or otherwise change the operation of the enterprise system.

[0056] 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 the enterprise.

[0057] Figure 9 is shown for the Figure 7 Illustration of a development system for developing and rolling out new features, such as containers or products, in one or more of an enterprise system's enterprise systems in a manner that shortens development and rollout time associated with new control system features while providing enterprise system administrators with the ability to control the timing and selection of changes to the enterprise systems.

[0058] Figure 10A An example NGPCAS control / operation graphical user interface (GUI) for a physical site is shown.

[0059] Figure 10B Another example control / operation GUI for a physical site in NGPCAS is shown.

[0060] Figure 10C An example enterprise-level viewing GUI is shown.

[0061] Figure 10D An example process entity deployment GUI is shown.

[0062] Figure 10E An example control loop GUI for a physical site in NGPCAS is shown.

[0063] Figure 10F An example diagnostic GUI is shown for multiple physical sites in NGPCAS.

[0064] Figure 10G Another example diagnostic GUI for multiple physical sites in NGPCAS is shown.

[0065] Figure 10H Yet another example diagnostic GUI for multiple physical sites in NGPCAS is shown.

[0066] Figure 11A An example marketplace GUI for viewing and acquiring services / applications in NGCPAS is shown.

[0067] Figure 11B Another example marketplace GUI for viewing and acquiring specific services / applications is shown.

[0068] Figure 12AAn example data ingestion GUI for multiple physical sites of an enterprise is shown.

[0069] Figure 12B Another example data ingestion GUI for multiple physical sites of an enterprise is shown.

[0070] Figure 12C A diagnostic GUI for enterprise NGPCAS is shown. DETAILED DESCRIPTION

[0071] The following disclosure describes a new process plant and industrial control and / or automation system architecture that relies 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 consisting of loosely coupled storage, resource management, security, networking, and parallel processing capabilities linked by a high-bandwidth interconnect (such as 10 Gigabit Ethernet) and may include any one or more of the following: a commercial multi-purpose platform, such as Microsoft's Azure service platform; a platform owned, operated, and maintained by an enterprise or system provider and dedicated to implementing process control at one or more enterprises; a computing cluster located locally and at the process plant; and the like. The shared resources of 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 recognized Purdue model, allow for various improvements and innovations in system configuration, control, monitoring, and management.

[0072] 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 specific implementations. These examples should not be considered as limiting the available functionality, the personnel who perform various tasks, the physical separation or positioning of various elements, or in any other way. Instead, these examples are intended to introduce various system elements and operational aspects of the system, each of which will be described in more detail elsewhere in this specification.

[0073] Example 1

[0074] The system provider provides and manages a computing structure that serves one or more enterprises and provides various tools and programs for configuring, debugging, controlling, and monitoring one or more process plants using the computing structure. These tools and programs include tools for configuring control modules and control strategies to control the process plant, tools for configuring operator workstations to monitor and control the process plant, tools for performing asset management (e.g., tracking calibration, maintenance, etc.), and tools for instantiating and managing control modules that ultimately control the process plant after being configured and instantiated in the computing structure. Each enterprise included in the plurality of enterprises accesses and utilizes the computing structure and available tools and programs to implement industrial processes owned and / or operated by one or more enterprises in one or more corresponding process plants. Each process plant implements various aspects of its process control via various containerized applications and services instantiated in the computing structure. 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) features, including load balancing, fault tolerance, and redundancy, which are implemented and managed by the system provider or the enterprise, or by the enterprise with assistance from the provider.

[0075] Utilizing these available devices, a first business owner implements a continuous process for producing various products from refined petroleum products at a first process plant, a refinery. Various field devices (e.g., valves, tanks, distillation columns, sensors / transmitters, etc.) are located within the process plant. These field devices sense parameters within the refinery and execute control actions in response to control algorithms that use the sensed parameters as input. Each field device has a corresponding input / output device that 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., I / O devices and field devices, collectively comprising 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.

[0076] Configuration engineers for enterprises and / or process plants access tools provided by system providers 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 utilize the data received from the field devices as input to the control algorithms and generate outputs to be sent to the field devices, and implementing operator workflows that allow plant operators to monitor and respond to conditions of the process plant at runtime. However, in contrast 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., the 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-encapsulated execution environments (“MEEES”, also referred to herein as “microservices” or “granules”) in a computing fabric.

[0077] Generally speaking, a microservice, particle, or MEEE instantiated in a computing structure can be an independent software process that can run on its own deployment schedule and can be updated independently of other microservices. Examples of MEEEs may include function blocks, control modules, control applications, and other applications and services related to the business logic of a process plant and / or otherwise supporting the process plant. Groups of microservices or MEEEs can interact 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 corresponding MEEEs, and the group of multiple MEEEs can operate collaboratively (e.g., in conjunction with each other) during the runtime of the process plant to achieve the desired reactor control strategy. For another example, for process control analysis applications, various MEEEs can be defined to perform corresponding statistical calculations and / or statistical algorithms, and the various MEEEs can be combined and executed in combination 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., the control strategy of an entire system or plant) to very detailed (e.g., only a portion of a control routine or control module), as will be discussed in more detail elsewhere in this document. Therefore, microservices or MEEEs are interchangeably referred to herein as “granules” due to their flexibility in being able to be configured to execute a variety of process control and process control-related applications, from broad to granular.

[0078] Regardless, configuration engineers 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 may 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 fabric with little or no input from enterprise personnel.

[0079] Regarding QoS metrics, the orchestration service operating within the compute fabric (and provided by the system provider) implements various load balancing and redundancy schemes to ensure that the plant's QoS metrics are met. For example, the orchestration service ensures that a redundant configuration container is always instantiated for any configuration container executing any part of a control algorithm, and that the redundant configuration container maintains corresponding inputs and outputs to the primary configuration container (i.e., maintains parallel state) so that if the primary container fails, control can be transferred to the redundant container almost immediately (e.g., within a few milliseconds). The orchestration service ensures that the configuration 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, configuration containers, MEEEs, or particles, the orchestration service instead maintains a redundant state database that stores the state of the microservice / configuration container / MEEE / particle so that if a microservice / configuration container / MEEE / particle fails or otherwise goes offline, a new microservice / configuration container / MEEE / particle can be instantiated almost immediately (e.g., within milliseconds) and restored to the operational state of the previously instantiated configuration container when it went offline.

[0080] The orchestration service also provides load balancing services to maintain sufficient memory, processing, and network resources to meet the QoS requirements of individual microservices / MEEE / granules and the entire plant. For example, maximum latency requirements may require that certain configuration containers execute on compute fabric resources that are physically closer to the process plant and / or have greater network bandwidth between the resources and the process plant.

[0081] 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 communicating with each other via corresponding sessions established on the VPN. Other VPNs facilitate communication between enterprise-level containerized applications / services and plant-level containerized applications / services, still other VPNs facilitate communication between vendor-level containerized applications / services and enterprise-level and / or plant-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 executed to facilitate services in the enterprise or process plant interacts with one or more APIs of the system and, after the user or third-party application is authenticated (e.g., using multi-factor authentication), can perform necessary actions through the one or more APIs.

[0082] In this way, relative to known systems, fewer dedicated computing resources are utilized to achieve control of the first process plant 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 based on changes in the process plant.

[0083] Example 2

[0084] At some point after commissioning the first process plant, the first business owner decides to replicate the first process plant in a second process plant. Since the control algorithms and necessary software have already been configured for use 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 a process plant.

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

[0086] A configuration engineer, having opened a stored configuration of a first process plant within a user interface application provided by a computing structure, drags a loop on a computing structure canvas (a workspace showing configuration containers instantiated in the computing structure for the first process plant) to select all 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 structure canvas.

[0087] The configuration engineer instantiates a digital twin of the field device and corresponding I / O microservice / MEEE / particle for each field device in the second process plant within the computing structure, replacing the physical I / O devices that previously coupled the physical field device to the controller. To the rest of the process control software executed in the computing structure, the digital twin is indistinguishable from the hardware field devices operating in the process plant. The digital twin is configured identically and, to the extent necessary (and possible, as described below), maintains the same data as that present on the field device itself. That is, when the field device updates the value or status of the measured parameter, those values ​​are uploaded to the digital twin within the computing structure via the media converter. However, the digital twin interacts with the instantiated function blocks, control modules, and other control algorithms in the computing structure. For the same reason, the function blocks, control modules, and other control algorithms instantiated in the computing structure (or in the hardware controller) send commands and data to the digital twin, which transmits these commands and data back to the hardware field devices in the second process plant via the media converter.

[0088] With the hardware field devices in place and coupled to the digital twin executing in the computing fabric via media converters, 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 minutes, greatly simplifying the process of bringing the second process plant online.

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

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

[0091] Example 3

[0092] With the first and second process plants up and running, the business owner (or its users) can manage both at the enterprise level using various tools available from the system provider. Because the various facilities owned by the enterprise are executed in the computing structure, the business owner can securely access data related to the process plants alone or to the entire enterprise at any time and from anywhere. As described above, access to the system is provided to all owners and / or third-party applications via an API, access to which requires multi-factor authentication. Thus, after authentication, the user can access tools, metrics, and other functionality that allow management of the enterprise and its various process plants.

[0093] Enterprise users can create or use any number of dashboards and tools to facilitate an enterprise-level view of the process plant, either individually or collectively. An enterprise user 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 of the respective plants over time for comparison. Upon noticing that one plant is performing differently than another (e.g., outputting higher quality products, operating more efficiently, etc.), the enterprise user can decide to dig deeper into why the plants are performing differently. Going to an application or service marketplace hosted by the system provider, the enterprise user can purchase or subscribe to an analytical service or tool, which is instantiated in the computing structure at the time of purchase or subscription and can be used by the enterprise user to analyze the performance of the process plant.

[0094] This analysis indicates that adjustments to one of the process plants could be optimized for better performance and recommends different tools that could be used to realign and optimize the process plant. Enterprise-level users can contact the plant's control operators to notify them of the available tools. The tools are then subscribed to or purchased for the enterprise or for individual plants only, and instantiated in the computing infrastructure at the plant and / or enterprise level.

[0095] The tool may determine that the process plant needs to be retuned in a manner that requires updated copies of one or more control algorithms. In this case, the tool proceeds to create the updated control algorithms (using input from the operator). The updated control algorithms are instantiated in the computational structure, but are not initially placed under control of the process plant. Instead, the updated control algorithms are implemented in parallel with the active control algorithms (e.g., in simulation mode) to ensure that they will not adversely affect the operation of the process plant and will actually improve the operation of the process plant. Then, when it is satisfied that the updated control algorithms will function appropriately, the operator immediately switches control of the process to the new control algorithms (e.g., without interrupting the process).

[0096] Meanwhile, an operator at one of the process plants may notice that the tuning of the process for which the operator is responsible appears to be fluctuating. The operator contacts a customer service representative from the system provider to help determine what is causing the fluctuations in tuning. Using a dashboard available to the system provider representative, the operator determines that the fluctuations in tuning are likely the result of several interrelated factors in the compute fabric, including the movement of microservices / MEEEs / granules between hardware resources used for load balancing, variations in available processing and network bandwidth, and the physical distance between the compute fabric resources and the process plant in question. The customer service representative may recommend using a real-time tuning application.

[0097] The real-time tuning application monitors the latency between the computing fabric and the physical resources in the process plant and automatically adjusts the control algorithm's tuning to account for variations in latency due to network conditions, physical distance, and processor bandwidth. In this example, after implementing the real-time tuning application, operators noticed that the subject process was generally more stable.

[0098] However, if the real-time tuning application indicates that there is a control loop that the real-time tuning application cannot automatically tune, the operator and customer service representative working in conjunction can determine that the control loop in question requires minimal latency, and therefore, the customer service representative can "pin" the configuration container associated with the control loop to physical hardware resources in the computing structure that meet the latency requirements, and particularly meet the latency requirements due to their physical proximity to the process plant in question. Furthermore, 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 point where latency would cause the process to go out of tune.

[0099] Example 4

[0100] A business owner with multiple process plants currently in operation may determine that consolidating the operators managing the various processes would be more efficient. While a certain number of maintenance and other personnel must be physically present at each process plant, the fact that the computing infrastructure can be securely accessed from essentially anywhere with a sufficient network connection allows operators to be located anywhere. Thus, the business owner may determine that all of its operations can be consolidated into three operating centers spaced approximately equally around the world, allowing it to operate 24 hours a day without requiring any of its employees to work outside of the first shift (business hours) at their respective sites.

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

[0102] Example 5

[0103] Separately, a second enterprise that wishes to improve the efficiency of its legacy 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 establishes an account for the second enterprise, and the second enterprise personnel subscribe to and / or purchase the necessary and desired tools and software packages. Configuration engineers at the second enterprise use tools available from the system provider to convert configuration files for legacy controllers currently operating in the first process plant into configurations for containerized services (e.g., microservices, MEEE, or granules) that will be executed on the compute fabric. Simultaneously, the system provider arranges for on-site installation of a pre-configured gateway that securely couples I / O devices to the compute fabric at the first process plant. After ensuring that the compute fabric is configured to meet the necessary QoS metrics, the configuration engineers and operators of the first process plant simulate the operation of the process plant using the configured compute fabric to confirm that it appears to be properly configured, and then bring the process plant online using the compute fabric.

[0104] When the newly reconfigured process plant was operating using the computing fabric and the legacy controller hardware was no longer operating the process plant, the second business owner maintained the process plant rather than discontinuing the legacy controller configuration. In effect, the system provider helped business personnel configure the legacy configuration of the first process plant so that if the computing fabric (or its network connection) became unavailable or unstable, the process plant's control could fail over to local control using the legacy system. Thus, the legacy system operated in parallel as a backup control solution.

[0105] At the same time, the second business owner may decide to keep the safety instrumented systems (SIS) for the process in place at the first process plant, rather than migrating them to the computing structure.

[0106] As the second business owner tends to expand to add new process plants, the second business 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 the field devices are purchased, the burned-in hardware IDs of the purchased devices are registered to the second business owner in a database that facilitates the configuration of the field devices in the new process plants. When configuring the control modules, the configuration engineer can select each device from the database so that the computing structure 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 according to its hardware ID. When the physical devices are connected to the computing structure via their corresponding media converters, each is automatically associated with its digital twin based on the hardware ID and is programmed (if programmable) according to the programming of its digital twin.

[0107] When additional process plants are configured to operate on a remote computing fabric, the second business owner determines that, because only one network provider serves some process plant locations, it is still wise to have a control solution that can maintain the security (if not full operation) of the process plant locations in the event that the network connection to the remote computing fabric becomes unavailable. To this end, the business owner physically locates certain computing fabric resources on-site so that in the event of a communication failure between the process plant and the remote computing fabric, the local computing fabric can maintain the security and / or operation of the process plant. The local computing fabric resources execute redundant containerized services, microservices, MEEEs, or granules (orchestrated by an orchestration service in the computing fabric) so that control of the process plant can fail over to the local computing fabric when necessary.

[0108] Example Next-Generation Process Control and Automation System Architecture

[0109] Figure 1A The present invention 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 automated processes. For example, the NGPCAS 100 can be used by chemical, petroleum, industrial, manufacturing, filling and packaging, or other types of businesses to manufacture, refine, convert, generate, or produce physical materials or products. For ease of reading, the NGPCAS 100 is referred to herein interchangeably as "architecture 100" or "system 100."

[0110] NGPCAS100 includes a computing structure 102 that is 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 the pool of physical devices) include devices that perform physical functions for controlling an industrial or automated process provided by an enterprise. For example, the plurality of physical devices 105, 108 may include field devices such as valves, valve positioners, actuators, switches, regulators, sensors (e.g., temperature, pressure, liquid level, and flow rate sensors), spectrometric devices, pumps, motors, transmitters, etc., some of which may be smart field devices. Some of the physical devices 105, 108 may have corresponding onboard processors, memory, and computer-executable instructions stored on the memory, wherein the stored computer-executable instructions are executable by the onboard processor to perform, for example, control and / or other types of calculations, alarm functions, and / or other functionality associated with controlling an industrial or automated process using the physical devices 105, 108. The physical devices 105 , 108 may responsively operate and / or change their behavior based on control signals and / or other instructions received from the computing structure 102 , as described in greater detail elsewhere herein.

[0111] The pools of physical devices 105, 108 of the system 100 may be arranged or physically located at different physical locations, sites, plants, or environments 115, 118 (such as Figure 1A ), or the pool of physical devices 105, 108 may be fully set up or located only at a single physical location, site, plant or environment (not shown). The 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 the system 100. For example, the field environment 120 of the NGPCAS 100 may include one or more buildings, field or outdoor sites, plants, oil rigs or platforms, rooms, cabinets, etc., in which or at which at least one physical device 105, 108 of the system 100 is physically located and in which at least one physical device 105, 108 operates in conjunction with the computing structure 102 to control an industrial process or an automated process. The term "field environment 120" is interchangeably referred to herein as the "process environment 120," "automation environment 120," "plant environment 120," or "physical environment 120" of the NGPCAS 100.

[0112] Each physical location or environment 115, 118 at which at least one physical device 105, 108 of the 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 the computing fabric 102 via one or more transport networks 130) I / O signals or I / O data generated by the local physical device 105, 108, and optionally provide control signals, instructions, and / or other information generated by the computing fabric 102 and received at the location 115, 118 via the one or more transport networks 130 to a designated recipient local physical device 105, 108. Each local physical device 105, 108 is physically connected to the local physical I / O interface 125, 128, e.g., via a corresponding wired or wireless link. Thus, in one embodiment, the local physical I / O interfaces 125, 128 may comprise a pool of I / O hardware ports (which may include wired and / or wireless ports or interfaces) and / or other I / O hardware resources shared among multiple local physical devices 105, 108 at the respective locations 115, 118. Additionally or alternatively, the local physical I / O interfaces 125, 128 may comprise individual instances of I / O hardware resources, wherein each individual instance is included in or exclusively connected to one and only one local physical device 105, 108. In general, this disclosure utilizes the term "physical component" 135, 138 to collectively refer to a combination of a single physical device 105, 108 (e.g., a single field device) and a physical I / O interface 125, 128 (e.g., an accompanying physical I / O interface of a single physical device 105, 108) used by the single physical device to transmit information over a transport network 130. Thus, in terms of terminology, the NGPCAS 100 includes a pool of physical components 135, 138, each of which includes a respective field device 105, 108 and corresponding physical I / O interface resources 125, 128 that the respective field device 105, 108 uses to communicate with the computing fabric 102. Generally speaking, the physical components 135, 138 of the NGPCAS 100 operate or would be included in Level 0 of the Purdue model of a traditional process control system.

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

[0114] In some embodiments, a physical site or location 115 may include a gateway / router / aggregator 148, which for ease of discussion will be referred to herein as a "gateway 148." Generally speaking, the gateway / router / aggregator 148 receives outgoing data and information to be sent to the computing fabric 102 and causes the outgoing data and information to be sent over the 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 the gateway / router / aggregator 148 receives incoming data and information received from the computing fabric 102 (e.g., in individual packets and / or in aggregated packets) and routes the information, instructions, and / or data included therein to a designated recipient physical component 138 at the site 115. A physical location may include a corresponding gateway 148 (e.g., location 115), a physical location may exclude any gateway 148 (e.g., location 118), and in some configurations, multiple physical locations may share, for example, a single gateway 148 (e.g., location 118). Figure 1A not shown).

[0115] Turning now to the computing structure 102 of the NGPCAS 100, the computing structure 102 is implemented on a scalable hardware platform, parts of which may be physically located in one or more physical locations ( Figure 1A 100). The physical location at which at least a portion of the hardware platform of the computing structure 102 is physically located may or may not be the physical location 115, 118 at which the physical devices 105, 108 of the system 100 are physically located. For example, the entirety of the hardware platform on which the computing structure 102 is implemented may be remote from any location 115, 118 of the on-site environment 120 of the system 100 (e.g., Figure 1A), or 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 field environment 120 ( Figure 1A 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.

[0116] 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 referred to interchangeably herein as "multiple containerized components 140 or a pool of containerized components," "multiple microencapsulated execution environments 140 (MEEEs 140) or a pool of microencapsulated execution environments," or "multiple particles 140 or a pool of particles" of the NGPCAS 100. That is, the pool of containerized components / microencapsulated execution environments / particles 140 may include applications and / or services that have been configured into containers and / or other types of microencapsulated 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 process and / or automation control and system management, and to supervise, maintain, and manage the system 100 and its components during the life of the system 100. In general, the containerized components / MEEE / granules 140 of the NGPCAS 100 provide the functionality that traditional process control and automation technologies typically implement via a variety of systems, networks, computing devices, DMZs, firewalls, and applications operating across Levels 1-5 of the Purdue Model, e.g., from basic control of the physical industrial equipment and processes of the system 100 at Level 1 to enterprise-level IT functionality at Level 5 that provides business direction and functionality related to the system 100. Furthermore, the containerized components / MEEE / granules 140 may provide even higher-level 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-intensive legacy architecture of Purdue Levels 1-5 and all of the numerous digital diodes, firewalls, DMZs, etc. necessary to secure a process control or automation system in a legacy architecture, NGPCAS 100 utilizes only a set of containerized components / MEEEs / granules 140 executing in a compute fabric 102 to perform the same or similar set of process control and automation core 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 techniques utilized within the architecture of NGPCAS 100 is provided elsewhere within this disclosure.

[0117] Typically, different functions are implemented by different containerized components / MEEEs / particles 140 within the computing structure 102. If desired, a single application or service can be configured into multiple different containerized components / MEEEs / particles 140 (e.g., different instances of the application or service implemented in corresponding containers), for example, 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. Various containerized components / MEEEs / particles 140 can be created (e.g., started) and / or removed as needed by the system 100 or when the system needs it. A group of containerized components / MEEEs / particles 140 can operate together 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 utilizing physical components 105, 108 set in the field environment 120 of the NGPCAS100. Typically, but not necessarily, the set of containerized components / MEEEs / granules 140 that form the logical process control system 145 is a subset of all containerized components / MEEEs / granules 140 provided by the computing fabric 102 .

[0118] During execution, each containerized component / MEEE / particle 140 can be communicatively connected to a particular physical component 135 / 138 or another containerized component / MEEE / particle 140 via a corresponding packet-based connection over the transport network 130. Thus, each containerized component / MEEE / particle 140 and each physical component 135 / 138 of the NGPCAS 100 is 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, a physical component 135 / 138 can be a sender or provider of I / O data and information received or consumed by one or more containerized components / MEEE / particles 140. In some cases, a containerized component / MEEE / particle 140 can be a sender or provider of control signals or other instructions received or consumed by a physical component 135 / 138. In some cases, a containerized component / MEEE / particle 140 can be a sender or provider of data received or consumed by another containerized component / MEEE / particle 140. To maintain the security of NGPCAS 100, containerized components / MEEE / granules 140 and physical components 135 / 138 can be authorized and authenticated on a per-component basis and optionally in pairs with each other, for example by using keys or any other suitable authorization and authentication techniques. Upon successful authorization and authentication, the two endpoint components 140, 135 / 138 can communicate data, instructions, and other information to each other during a session established between the two endpoint components 140, 135 / 138 over one or more networks 130.

[0119] To further protect the NGPCAS 100, one or more transport networks 130 may include one or more secure, point-to-point (PTP) and / or peer-to-peer (P2P) connections, which may include one or more secure, encrypted point-to-point and / or peer-to-peer connections, such as virtual private networks (VPNs) and other types of secure, encrypted PTP and / or P2P connections. In one embodiment, a specific containerized component / MEEE / particle 140 is communicatively connected to a specific 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 specific containerized component / MEEE / particle 140 and the specific physical component 135 / 138. For example, a particular physical component 135 / 138 and a particular containerized component / MEEE / particle 140 can 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 communicate data, messages, instructions, and / or other information with each other via the exclusive point-to-point VPN. In a similar manner, a particular containerized component / MEEE / particle 140 can be communicatively connected to another particular containerized component / MEEE / particle 140 using a secure, encrypted point-to-point (P2P) connection 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 communicate data, instructions, and / or other information with each other via their dedicated, secure, and encrypted point-to-point connection. Dedicated point-to-point and / or peer-to-peer connections between a single containerized component / MEEE / particle 140 and a single physical component 135 / 138 or a single other containerized component / MEEE / particle 140 can be established as needed or when needed and can be torn down when needed (e.g., when data exchange is completed, when system resources need to be freed, etc.).

[0120] 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) dedicated to the specific location 115 / 118 and the computing fabric 102 (not shown). The physical components 135 / 138 located at the specific location 115 / 118 and the containerized components / MEEEs / granules 140 executing on the computing fabric 102 may communicate data and information to each other via the location-to-location PTP or P2P connection. For illustration, in Figure 1AIn the illustrated example arrangement, location 1 (referenced as 115) includes a local gateway / router / aggregator 148 that establishes a location-to-location VPN with computing fabric 102, e.g., such that local gateway 148 is one endpoint of the location-to-location VPN and VPN gateway application 150 executing on computing fabric 102 is the other endpoint of the location-to-location VPN. Containerized components / MEEEs / granules 140 and physical components 105 located at location 115 can authenticate to the location-to-location VPN and establish corresponding sessions over the location-to-location VPN (e.g., via VPN gateway application 150 and local gateway 148) to communicate data and information with each other. Additionally or alternatively, architecture 100 can support subnets within the location-to-location VPN, such that various physical components 135 / 138 and various containerized components / MEEEs / granules 140 located at location 115 can communicate with each other via one or more subnets within the location-to-location VPN. Furthermore, in the foregoing description, secure, encrypted PTP and / or P2P connection types other than VPN can additionally or alternatively be utilized.

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

[0122] In one embodiment, all containerized components / MEEEs / granules 140 of the computing fabric 102 and all physical components 135 / 138 of 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 / granule 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 over the secure, encrypted system-level connection (e.g., via a corresponding local gateway 148 and one or more gateway applications 150) to send and receive data and information to / from the other components 140, 135, 138.

[0123] Furthermore, if desired, various secure, encrypted PTP, P2P, PTM, and / or multi-point connection technologies can be combined (e.g., by utilizing subnets) to provide even greater 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 a location-to-location VPN, a group of containerized components / MEEE / particles 140 can be included in a subnet supported by the computing fabric 102, and so on. Furthermore, any secure, encrypted connection technology used within the NGPCAS 100 can be used in conjunction with endpoint authorization and authentication technologies to provide even greater security for the NGPCAS 100.

[0124] In addition, in some specific implementations and as described above, in addition to or in lieu of using a VPN, one or more transport networks 130 may utilize one or more point-to-point private connections (such as point-to-point and / or peer-to-peer Ethernet connections through 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, a point-to-point private connection may be established between two components 138, 140, between a physical site 115, 118 and a computing structure 102, and the like. However, for ease of discussion herein, the description references "VPN" technology (not for limiting purposes), and instead generally and categorically describes secure transmission on the network 130, but it should be understood that any of the systems, methods, and techniques described herein may additionally or alternatively utilize other types of secure, encrypted point-to-point, peer-to-peer, and / or multipoint connections for secure transmission.

[0125] A user 155 of the NGPCAS 100 may authenticate to the VPN 158 in order to interact with the NGPCAS 100 (e.g., interact with the 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 and other aspects of the configuration of the system 100, etc. As used herein, a "user" 155 may be a person or human user, or the user 155 may 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 illustrated users 155 may equate to people and applications / services accessing data and information related to traditional process control or automated plants at any of Levels 1-5 of the Purdue Model.

[0126] The human user 155 may 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 may 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, or the like. Typically, the human user 155 interacts with the NGPCAS 100 via a computing device operated by the user (e.g., a laptop, a tablet, a mobile computing device, an in-vehicle computing device, etc.), on which an application, a web browser, or a similar executable program is executed to provide both 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, in order to interface with the NGPCAS 100 using his or her computing device, the human user 155 may utilize a specific MEEE 140 that has been configured and authorized to execute at the computing device operated by the user (e.g., an application that has been downloaded from the computing structure 102), or the human user 155 may utilize a web browser executed at the computing device operated by the user. As another example, user 155 may be an automated user, such as an external application or service, for example, an application or service executed on an external computing device or system. Automated user 155 may not provide any user interface for a human user, but may still establish a communication connection with NGPCAS 100 via VPN 158 to obtain or provide data and / or other information. Examples of automated users 155 include applications generated by third parties, external data sources (such as weather data sources, material management systems, etc.), etc. In some cases, automated user 155 may be a specific containerized component or MEEE 140 that has been configured and authorized to execute on a remote computing device or system.

[0127] Regardless, whether the user 155 is a human user or an automated user, the user 155 securely accesses data and / or other information at the NGPCAS 100 using an API (application programming interface) 160 (via a VPN 158 to which the user 155 has been authenticated). In an example implementation, the user 155 may utilize different APIs 160 to access different containerized components / MEEEs / granules 140 and physical components 135 / 138 of the computing structure 400. In additional or alternative embodiments, the user 155 may utilize a single API 160 to access the NGPCAS 100, and the API 160 may establish communication connections with the containerized components / MEEEs / granules 140 and physical components 135 / 138 within the NGPCAS 100 as needed to obtain or provide the required data and / or information to / from the user 155. For example, one or more of the APIs 160 may themselves be containerized components / MEEEs / granules 140 of the computing structure 102.

[0128] Figure 1A The specific user of interest 155 shown separately in the figure is the architecture provider / administrator 161 of NGPCAS100. Generally speaking, the architecture provider / administrator 161 provides supervision, management and support of NGPCAS100 and, optionally, other systems 100 of the enterprise and / or one or more systems of other enterprises (e.g., the system's corresponding architecture, hardware and software resources, etc.). For example, the architecture provider / administrator 161 may be within the scope of the provider of the system 100. The architecture provider / administrator 161 may have exclusive access to a set of applications and services that can be created, configured and / or executed by the provider and / or administrator 161 of NGPCAS100 (e.g., in one embodiment, it may be a subset of the entire set of containerized components / MEEE / granules 140 provided by the computing structure 102). In a sense, the architecture provider / manager 161 oversees and manages the architecture platform resources utilized by one or more NGPCAS100 via the collection of applications and services, and therefore, can generally perform a wider range of logical functions, such as engineering across various enterprise systems; providing an application / service "store" that includes a library of various applications and / or services, and the architecture provider / manager 161 can configure and distribute instances of these applications and / or services to the NGPCAS100 for their 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 can be implemented by one or more containerized components / MEEE / granules 140. In addition, as Figure 1AAs shown, a fabric provider / administrator 161 (whether a human user or an application or service executing on a remote computing device) can authenticate to the VPN 162 and can utilize one or more APIs 165 to securely read and / or write data and / or other information, send instructions, and / or otherwise interface with various other containerized components / MEEEs / granules 140 and physical components 135 / 138 of the NGPCAS 100. For example, the one or more APIs 165 can themselves be containerized components / MEEEs / granules 140 of the computing fabric 102.

[0129] In one embodiment, different subsets of containerized components / MEEEs / granules 140 may communicate with specific physical components 135 / 138, specific locations 115, specific sets of multiple locations, the entirety of all physical locations of an enterprise, or corresponding physical components and / or corresponding physical locations of multiple different enterprises via corresponding VPNs 162. For example, containerized components / MEEEs / granules 140 utilized exclusively by an infrastructure provider / administrator 161 may be communicatively connected to other containerized components / MEEEs / granules 140 and / or physical components 135 / 138 of the enterprise via a different provider-specific VPN 162 than the VPN utilized by other containerized components / MEEEs / granules 140 of the enterprise to communicate with physical components 135 / 138 at enterprise locations. For another example, the containerized components / MEEE / granules 140 provided by the architecture provider / administrator 161 can communicate with the containerized components / MEEE / granules 140 and physical components 135 / 138 of the first enterprise using a first enterprise-specific VPN 162, and can communicate with the containerized components / MEEE / granules 140 and physical components 135 / 138 of a second enterprise (not shown) using a different, mutually exclusive enterprise-specific VPN. Thus, the architecture provider / administrator 161 is able to securely and independently oversee and manage the corresponding resources of different parts of a single enterprise and / or different enterprises in a highly secure manner. In fact, by using one or more VPN technologies described herein, alone or in combination, the security of the NGPCAS 100 (and in some cases, multiple NGPCAS 100 supported by the architecture provider / administrator 161) can be customized as desired or needed.

[0130] Thus, in accordance with the above discussion, the containerized components / MEEEs / granules 140 provided by the computing structure 102 of the NGPCAS 100 include runtime logic functionality (e.g., control and automation logic, data acquisition, etc.) that traditional process control and automation systems typically implement at levels 1 and 2 of the Purdue model. The containerized components / MEEEs / granules 140 also include other logic functions related to runtime logic and that traditional process control and automation systems typically implement at levels 2 and 3 of the Purdue model, such as: system and component deployment; engineering; configuration; provisioning; debugging; 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; fault and performance degradation detection and repair / recovery; operator interface; redundancy, backup, and other functionality related to the availability of the system 100 and its components and equipment; data history; compliance; management of manufacturing or production workflows, execution, and operations; and the like. Additionally, containerized components / MEEEs / granules 140 may include logic functionality typically provided in traditional process control systems at higher levels 4-5 of the Purdue model, such as enterprise resource planning, production scheduling, material usage, transportation, inventory levels, and other enterprise-level functionality. Furthermore, such containerized components / MEEEs / granules 140 may include logic functionality introduced into the computing fabric 102 via a third party, such as applications and / or services that have been authored by the third party and approved and authorized by the enterprise for utilization within the NGPCAS 100.

[0131] Additionally, the collection of containerized components / MEEEs / granules 140 provided by the computing fabric 102 may include the networking layer of the computing fabric 102 ( Figure 1A Containerized components / MEEEs / particles 140 (not shown), wherein such containerized components provide lower-level logical functionality that can be utilized by or relative to other containerized components / MEEEs / particles 140 as needed. Such lower-level logical functionality may include, for example, a set of APIs 160, 165 used by users 155 to interface with the various containerized components / MEEEs / particles 140 and physical components 135 / 138 of the NGPCAS 100; compute functionality (e.g., for assigning and reassigning various containerized components to compute fabric nodes Ny and / or data center clusters Cx, which are discussed in more detail elsewhere in this document); storage functionality (such as managing and allocating storage areas for work data associated with executing containerized components); networking functionality (e.g., for data and information delivery between various containerized components, its mechanisms, timing, etc.); and functionality that can be implemented by the application layer ( Figure 1AOther services utilized by the containerized component / MEEE / granule 140 executed at (not shown) (e.g., discovery, security, encryption, certificate authority, key management, authentication, time synchronization, service location, console support, life cycle management, etc.); etc.

[0132] In addition, the collection of containerized components / MEEEs / granules 140 provided by the compute fabric 102 may also include lower-level logical functionality (such as calculations, utilities, primitives, etc.) that may be utilized by the containerized components / MEEEs / granules 140 at the application and network layers of the compute fabric 102. Examples of such functionality include computational 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 analysis); and process control-specific or automation-specific computations (e.g., function blocks, shadow blocks, control module operations, etc.), among others.

[0133] in addition, Figure 1A Location n 118 is shown as including a backup control system 168 that can partially or completely fail over to maintain runtime operation of the process control system 100 at location n 118 when one or more remote portions of the system 100 (e.g., the transport network 130, the computing structure 102, etc.) are damaged, out of communication, 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.

[0134] Thus, in accordance with the foregoing, the computing structure 102 of the NGPCAS 100 provides process control and automation functionality and related functionality that is required to be performed by different equipment and systems distributed across Purdue Levels 1-5 in traditional process control systems, and also provides additional lower-level functionality available system-wide (e.g., from networking and platform resource management to computing and primitives). Furthermore, advantageously, the NGPCAS 100 eliminates the need for DMZs at Levels 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.

[0135] Specifically, as described above, any data or information transmission between two components of NGPCAS100 (e.g., two different containerized components / MEEE / particles 140, or a containerized component / MEEE / particle 140 and a physical component 125 / 135) can be implemented via a private session on a VPN (e.g., a VPN utilized by the physical location 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. In addition, 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. In addition, all users may be required to be multi-factor authenticated before obtaining access to the system 100 via the API 162 / 165. In this way, system data is exposed only to non-public addresses (e.g., addresses of components, computing structure nodes, etc.) via the VPN and authorized, authenticated entities. Applications can be exposed as websites or services, such that computing devices utilized by users access the system 100 via a "thin" client and do not have any system-related software executing on them (perhaps with the exception of thin clients such as portal applications). Furthermore, all applications can be containerized, including applications that execute locally at the physical location where the physical device is located, and any system data can be encrypted at rest.

[0136] Additionally, within the NGPCAS 100, all communications transmitted and received over the network 130 may be signed and encrypted, and the use of clear text 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.

[0137] Figure 1B A block diagram illustrating an example architecture of a Next Generation Process Control and Automation System ("NGPCAS") 100A having Figure 1A The basic components of the system 100 are configured to support a conventional distributed control system such as Control systems for industrial and / or automated processes. In this case, the NGPCAS100A includes Figure 1A All components of the system 100 are connected to one or more plants or physical locations 115A and 118A where a conventional control system has been implemented. Figure 1BAs shown, locations 115A and 118A may have a distributed controller 170, such as a DeltaV controller, connected to various field devices 174, such as smart 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-20 mA, 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 conventional control programs that may control the field devices 174 using, for example, function blocks, control blocks, etc.

[0138] However, if Figure 1B As shown, the process controller 170 may be connected to a data aggregator and VPN gateway 180 installed or located at physical locations or plants 115A and 118A, and the VPN gateway 180 is connected to elements within the computing structure 102 via secure VPN links 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 lines at location 115A) to obtain, manage, convert, aggregate, and collect data from the field devices 174. The VPN gateway 180 also operates to encrypt the collected data and provide it to other components in the computing structure 102 (which use the data to perform control or other services) via the VPN or other secure and encrypted communication link 130. With respect to location 115A, the NGPCAS 100A may simply bypass the controller 170 to perform a similar operation to the NGPCAS 100A. Figure 1A The controller 170 can be operated and programmed to backup the control system 168, such as Figure 1A As shown, the controller 170 at the location 115A takes over control of the field device 174 at the location 115A in a failover or backup situation.

[0139] On the other hand, as regards Figure 1BAs shown in physical location 118A, controller 170 can operate as part of computing structure 102 and have software modules (such as containers, etc.) associated with computing structure 102 stored and operating therein. In this case, controller 170 (at location 118A) is part of computing structure 102, which is indicated by the controller extending downward into physical location 118A to include controller 170. Figure 1B 102. Thus, in this case, the computing structure 102 may include cloud-based computing devices and computing devices (e.g., controller 170) located at a physical plant location that is not within the cloud. Furthermore, in this case, the controller 170 at location 118A may operate in conjunction with other computer equipment within the computing structure 102 (such as computer equipment within a cloud environment) to perform control of the field devices 174 at the physical location 118A.

[0140] exist Figure 1B In both examples, the data aggregator and VPN gateway 180 are included to enable the NGPCAS described herein to connect to and use installed legacy control system hardware (such as process controllers, field devices, I / O devices, etc.), which makes the NGPCAS described herein easier and cheaper to install and use in factories or other physical locations 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 standard legacy control systems (such as distributed control systems) to NGPCAS. Of course, although Figure 1B A conventional or installed control system is shown as a distributed control system, but other conventional or installed control systems may be used in the same or similar manner to support NGPCAS.

[0141] As will be appreciated, the communication gateway device 180 (and Figure 1AThe communication gateway device 148 of the computing structure 100, 100A operates to enable networked communications between the computing structure 100, 100A and the physical devices at each plant site or location 115, 188, 115A, 118A. More specifically, the gateway device 148, 180 implements one or more secure transport networks to establish communications between each containerized component 140 (e.g., MEEE) in the computing structure 100, 100A and each physical device at the plant site 115, 115A, 118, 188A. Here, the physical device can be a field device, an I / O device, a process controller device, a database, etc. As described above, the communication gateway device at a particular plant site can implement one or more secure PTP or P2P connections between the computing structure and multiple physical devices at the particular plant site, and different PTP or P2P connections or networks can be used to connect different MEEEs (i.e., containerized elements) in the computing structure to the same or different physical devices at the physical site 115, 115A, 118, 118A. Furthermore, as described above, the communication gateway device may use one or more virtual private networks (VPNs) to implement or establish one or more secure point-to-point (PTP) or peer-to-peer (P2P) connections, and may use, for example, different VPNs to establish different secure networks for each of the different secure point-to-point (PTP) or peer-to-peer (P2P) connections. In addition, the communication gateway device at a specific plant site may use a first secure point-to-point (PTP) or peer-to-peer (P2P) connection to implement a control network that enables the MEEE in the computing structure to implement online process control using multiple physical devices at the specific plant site, and may use a second or additional secure point-to-point (PTP) or peer-to-peer (P2P) connection to implement a network that does not perform online process control. Such additional PTP or P2P networks may be established to implement one or more additional transmission networks that perform, for example, maintenance functions, equipment or network monitoring functions, enterprise management functions (management functions implemented by an enterprise manager), computing structure provider or manager functions (management functions performed by or associated with a computing structure provider or manager, which may be an entity different from the enterprise), etc., with respect to equipment or networks at a particular plant site.

[0142] Example NGPCAS architecture including digital twin

[0143] As described above, in some implementations of NGPCAS 100 , the computing structure 102 may facilitate the use of a “digital twin” of one or more of the local physical devices 105 , 108 . Figure 2AA system 200 representing a portion of an example NGPCAS 100 is shown, wherein a plurality of local physical devices 202A-202D communicate with corresponding media converters 206A-206D via corresponding physical interfaces 204A-204D. Figure 2A In FIG. 1 , Foundation Fieldbus device 202A is coupled to media converter 206A via Foundation Fieldbus interface 204A. The media converter converts signals received from and sent to device 202A between the Foundation Fieldbus protocol and an Ethernet-compatible or other suitable packetized protocol. Similarly, HART device 202B is coupled to media converter 206B via HART interface 204B. The media converter converts signals received from and sent to device 202B between the HART protocol and an Ethernet-compatible / packetized protocol. As will be appreciated, other transmitters, sensors, and field devices may utilize other protocols. For example, devices 202C and 202D may each be a 4-20mA device, and media converters 206C and 206D may convert signals from 4-20mA to an Ethernet-compatible / packetized protocol (e.g., by packetizing the values ​​of the 4-20mA signal and placing them on the network).

[0144] Ethernet connections 208A-208D couple media converters 206A-206D to computing fabric 102, and specifically to corresponding digital twins 210A-210D of local physical devices 202A-202D, respectively. In an embodiment, Ethernet connections 208A-208D may each be directly connected to computing fabric 102 (e.g., Figure 2A ), or perhaps more likely, Ethernet connections 208A-208D may each be connected to 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)).

[0145] 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 emulates the electronic functionality of one or more sensors, transmitters, actuators, etc., rather than physical functions such as sensing and actuation. A digital twin can correspond to a single device (e.g., a pressure transmitter, a temperature transmitter, an actuator, etc.), a group of devices (e.g., a valve with upstream and downstream pressure transmitters and a valve position sensor), or a class of devices (e.g., a mass flow device). Figure 2BThis concept is described in more detail with respect to the Foundation Fieldbus local physical device 202A. Figure 2B As shown, device 202A has stored in memory therein a plurality of parameters and variables 220A-220J, which are generally addressable and / or retrievable and / or otherwise available by a process control system and, in particular, are usable in a control algorithm for controlling device 202A. Of course, Fieldbus devices such as device 202A include one or more of a generally known set of parameters and values, including a measurement value 220A, a setpoint value 220B, upper and lower limits 220E, an alarm 220D, one or more device states 220C, a device ID 220H, a device tag 220I, a device description 220G, a scale 220F, and / or other information 220J such as range information, status information, etc., while other types of devices may additionally or alternatively include other parameters and values, and still other devices may be capable of providing only a single transmitter value (e.g., pressure, temperature, etc.). The digital twin 210A corresponding to the device 202A is implemented in the computing fabric 102 (or in a non-computing fabric implementation if desired) and maintains up-to-date copies of the data 220A-220J stored in the device 202A. Figure 2B Additionally, the digital twin 210A writes any setpoint values, other relevant data, and / or other commands 220A'-220J' it receives to the device 202A.

[0146] See again Figure 2A Each of the digital twins 210A-210D is coupled via the computing fabric 102 to function blocks, control modules, and other control algorithms that typically receive data from (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 where data typically flows 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 algorithms 216 operate on the data, receiving and sending data from the digital twins 210A-210D, regardless of whether the digital twins 210A-210D are physical devices or logical devices. In this manner, the ultimate hardware (eg, physical devices 202A- 202D) is abstracted from the control algorithms 216 that operate the process plant via the digital twins 210A- 210D.

[0147] In the contemplated system implementing the computing fabric 102, the digital twins 210A-210D may be implemented as microservices (or other micro-encapsulated execution environments) that execute in federated or separate containers, in one embodiment. In one embodiment, each digital twin 210A-210D self-identifies within the system 100 using a unique network identifier or address of the corresponding physical device 202A-202D that the digital twin 210A-210D mirrors. Thus, other containerized components of the computing fabric 102 can communicate with the intended physical device 202A-202D by using the physical device's unique identifier and remain unaware or unaware of 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 a proxy for the corresponding physical device 202A-202D that the digital twin 210A-210D mirrors within the system 100. In further embodiments, and in a manner similar to the other containerized components / MEEEs / granules 140 of the compute fabric 102 , containerized digital twins may be nested based on, for example, area of ​​the process plant, type of equipment, associated control modules, etc. Of course, AI, AO, and control algorithm modules may similarly be executed as containerized services or microservices.

[0148] In an embodiment, the digital twins 210A-210D may be automatically created based on the descriptions of the corresponding physical devices 202A-202D that they represent.

[0149] Use as described herein and Figure 2A and Figure 2B The digital twin approach shown can achieve a variety of advantages. One advantage is that the digital twins 210A-210D can be programmatically configured to prevent abnormal conditions in the process plant that might otherwise be caused by minor faults in the physical devices 202A-202D. For example, if the measurements in the physical devices become unreliable, the digital twins 210A-210D can maintain the most recent values ​​of the measurements (or provide expected or simulated values) to maintain stable, safe operation of the process plant, even in the absence of the actual measurements provided by the physical devices 202A-202D. By the same token, devices (particularly transmitters) that fail, require maintenance, or require 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 not present or is not sending accurate (or any) data.

[0150] Another potential advantage of using digital twins is that it can facilitate the ability to debug the systems described herein with less effort, expense, and time. By way of example and not limitation, a new plant (or portion thereof) that is identical to an existing plant (or portion thereof) can be instantiated almost entirely in the computing fabric, with physical devices 202A-202D coupled thereto via Ethernet. If systems other than physical devices 105, 108 are instantiated in the computing fabric 102, the entire process control plant (or at least the elements in the computing fabric 102) can be instantiated in 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, MEEEs, or particles instantiated in the computing fabric 102.

[0151] Yet another advantage of employing a digital twin is that a digital twin, with or without direct connection to a control algorithm (i.e., whether the control algorithm interfaces with the digital twin or directly with the physical equipment (e.g., 202A-202D) in the process plant), can be used to generate predictions about the future state of the process and / or physical equipment. 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 / MEEEs / particles) can receive data from the physical equipment and control algorithms and provide assessments of the control system (e.g., a control system that is trending towards an abnormal state), field equipment (e.g., a sensor that appears to be failing or has failed), etc. This information can then be used to provide recommended mitigation or remedial actions to operators, maintenance personnel, or others.

[0152] Another advantage afforded by the use of digital twins is the introduction of new sources of soft sensor data. Just as a group of physical devices (e.g., upstream and downstream sensors and a valve position sensor) can be represented by a single digital twin of a valve embodying these three elements, a group of measurements (collected by the corresponding physical devices) can be collected by a digital twin and used as a "soft sensor" that provides an indirect measurement of another value. For example, a digital twin can receive values ​​from four transmitters—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.

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

[0154] Example multi-enterprise NGPCAS architecture

[0155] The Next Generation Process Control and Automation System (NGPCAS) 100 described in the preceding sections of this disclosure provides numerous enterprise-level benefits to any particular enterprise utilizing one or more NGPCAS 100 to implement industrial and / or automated processes. Examples of such benefits will be discussed in detail herein. Figure 3A and Figure 3B Have a discussion.

[0156] Figure 3A The logical arrangement of an example multi-enterprise framework 300 including different enterprises 302 and 304 is shown. Each enterprise 302 and 304 utilizes a corresponding NGPCAS to implement an industrial or automated process (or, in some cases, multiple different industrial and / or automated processes) across physical device locations 312 / 314 and 316 / 318. In one embodiment, the corresponding NGPCAS of the enterprises 302 and 304 can be a corresponding instance of NGPCAS 100, each of which can be specifically configured for the enterprise 302 and 304. Therefore, this disclosure refers to the enterprises 302 and 304 interchangeably as "enterprise NGPCAS 302 and 304" or simply as "NGPCAS 302 and 304". The NGPCAS 302, 304 each include enterprise-level computing fabric functionality 320.1-320.2, which is composed of containerized applications and / or services that operate in the respective computing fabrics of the NGPCAS 302, 304 to control process equipment and provide other process functionality to serve the processes implemented via the NGPCAS 302, 304 (e.g., operation, maintenance, diagnostics, monitoring, etc.). For example, at least some of the enterprise-level computing fabric functionality 320.1-320.2 may be provided by the infrastructure provider / administrator 161 via subscription, download from an application or service store, etc. The enterprise-level computing fabric functionality 320.1, 320.2 may be provided, for example, in the form of containerized applications and / or services related to the control of process equipment and other process functionality. Figure 1A The containerized component / MEEE / particle 140 is executed in the described manner.

[0157] In some embodiments, the compute fabric functionality 320.1, 320.2 executes in different portions of a shared compute fabric (e.g., at least some compute fabric nodes are shared between the enterprises 302, 304), wherein security for the compute fabric functionality 320.1, 320.2 is pinned to the respective enterprises 302, 304 using the security mechanisms of the present disclosure (e.g., even if components of the compute fabric functionality 320.1, 320.2 execute on the same compute fabric nodes, such components run as separate containerized components, where security and access are managed independently for each separate containerized component). At least a portion of the compute fabric functionality 320.1, 320.2 is accessible to authenticated users / computing devices (e.g., Figure 1Aaccessed and operated by human or automated users 155 and / or architecture providers / administrators 161).

[0158] Example enterprise-class computing functionality

[0159] Figure 3B shows what can be included in the representative Figure 3A Example enterprise-level computing fabric functionality 320 in computing fabric functionality 320.1, 320.2 executed by enterprises 302, 304. The computing fabric functionality 320 includes real-time process monitoring functionality ( Figure 3B 332 in). Any of the enterprises 302, 304 may actually implement two, three, four or more NGPCAS, each of which may operate across a corresponding set of one, two, three, four or more physical equipment locations. Since the location of monitoring a process in an NGPCAS is not limited to the physical equipment location where the process is physically performed, a single user at a single computing device may perform remote monitoring of a process across two, across two, three, four or more NGPCAS (and / or across multiple physical equipment locations associated with each NGPCAS). For example, a single enterprise may operate multiple NGPCAS, which typically involve the operation of a specific type of boiler unit. A technician or operator familiar with the operation of the boiler unit may monitor the runtime operation of the boiler unit across multiple NGPCAS by receiving process information associated with the operation of each boiler unit included in the multiple NGPCAS at the technician's computing device via the computing structure (e.g., device identifiers, device configuration information, process measurements, process set points, alarms, etc.). A technician (and / or a technician's computing device) may be provided with a degree of authorization to view, obtain, and act upon monitored process information (e.g., to send process commands, implement configuration changes, and / or provide other responses) to manage the operation of boiler units across multiple NGPCAS. Similar monitoring functionality may 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 of the multiple NGPCAS.

[0160] 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 NGPCASs, 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 groups, control loops, 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 a different physical device location, 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 138 associated with the components 135, 138 of the NGPCAS). 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 (e.g., to advance steps in the process or modify a control loop in the process, where the control loop itself is potentially implemented in the form of a containerized component at the same or different location via a computing structure). In addition, authorization to monitor any specific function of the NGPCAS (e.g., monitoring a specific industrial process or portion thereof, a physical device location, a device, a group of devices, etc.) can be transferred on demand (e.g., at the request of a user and / or another containerized component) or automatically between personnel located in various physical locations, which are 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 portion thereof can be transferred between personnel when personnel change shifts, where the personnel handing 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 portion thereof. This ability to transfer authorization for monitoring operations between physical locations can enable the functionality of actively monitoring runtime process operations to "follow the sun," for example by moving the monitoring of operations of an industrial process (or portion 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.

[0161] The disclosed NGPCAS architecture may also enable control of an NGPCAS process or portions thereof (e.g., a device, a group of devices, a control loop, etc.) from any physical location (340). Configuration and execution of control loops may be implemented as containerized components in a location-agnostic NGPCAS computing structure, rather than being implemented locally at the physical device location of the controlled operation as in traditional process control architectures. Portions of the control system may be distributed among containerized components executed at the same physical device location, at different physical device locations, and / or at other physical locations not associated with the physical implementation of the process.

[0162] In practice, any containerized component (e.g., containerized services and applications) in a computing fabric can be executed 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 that implements at least a portion of the process) (338). Similarly, a containerized component in a computing fabric can be instantiated from any physical location (342). A containerized component can be instantiated, for example, via human and / or automated operation at a first physical location, and the instantiated containerized component runs or executes on a compute node (of the computing fabric) located at a second physical location. Furthermore, the execution of a containerized component can be transferred between various physical locations on demand or automatically (344, for example, via Figure 4 Orchestration service 422). In some specific implementations, the containerized components of the NGPCAS are moved globally across various physical locations to place the execution of the containerized components at any given time in proximity to the monitoring / control / operation workstations serving the NGPCAS (e.g., to "follow the sun" by executing the containerized components at the corresponding locations during daylight hours at the various locations). For example, the containerized components may be moved to execute multiple times a day at different physical locations to "follow the sun" so as to be executed at any given time in proximity to the personnel providing daytime services to the NGPCAS. The containerized components may also be moved between compute fabric nodes and / or physical locations for load management purposes, such as to avoid overloading the processing power of any particular compute fabric node or the communication bandwidth of any particular communication link in the compute fabric. In addition, in the event of a failure of a compute fabric node or portion thereof in the compute fabric, the execution of the containerized component may be moved, for example, by activating digital twin instances of the containerized components that execute operations on different compute fabric nodes and / or at different physical locations.

[0163] NGPCAS can be provided with 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) can 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 the containerized components implementing the selected functionality can be instantiated and executed on-demand or as needed to support the scale of operations required by the enterprise's NGPCAS.

[0164] In some embodiments, the architecture provider / manager (e.g., Figure 1A 161) provides subscription-based access rights (346) to process functionality, whereby an enterprise purchases a particular 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 rights 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. 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 purchase or subscription) for their own respective use. Additionally, 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 securely, appropriately, and efficiently on the enterprise's NGPCAS prior to actual implementation in the context of the enterprise's own process architecture.

[0165] See again Figure 3A According to the NGPCAS architecture, the multi-enterprise framework 300 enables the architecture provider / manager (e.g., Figure 1A 161) is able to perform centralized management of upgrades (350) of applications / services utilized by enterprise NGPCAS 302, 304. Upgrades to applications / services are reflected in new instances of the applications / services executed in the 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.

[0166] In addition to providing centralized management of application / service upgrades, the infrastructure provider / manager (e.g., Figure 1A 161) can provide a central monitoring point (352) for the operation of the computing fabric of an enterprise NGPCAS 302 and / or 304. The fabric provider / administrator can monitor NGPCAS operations, for example, to implement fault handling or fault protection measures, perform load balancing of NGPCAS functionality, and / or identify performance improvements for the same NGPCAS 302, 304 and / or for different NGPCASs of other enterprises.

[0167] Other enterprise-level benefits of the NGPCAS architecture of the present disclosure will be appreciated from the remainder of this specification.

[0168] Example computing structure architecture

[0169] Relative to Figure 1A The computing structure 102 of the next generation process control and automation system 100, Figure 4 A block diagram of an example architecture 400 of the computing structure 102 is shown. Of course, the example architecture 400 can be utilized in computing structures and / or in process control and automation systems other than the computing structure 102 of the NGPCAS 100. However, for the purpose of facilitating the discussion herein and not for the purpose of limitation, reference will be made to the example architecture 400 herein. Figure 1A To describe the architecture 400. Additionally, for ease of reading, the architecture 400 of the computing structure 102 is interchangeably referred to herein as "computing structure architecture 400" or simply "computing structure 400."

[0170] In general, 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 platform of the computing structure 400. For example, the computing structure 400 can utilize one or more techniques and / or features described in U.S. patent application Ser. No. 17 / 487,609, filed on Sep. 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 purposes of this discussion, reference is also made to Figure 1A The computing structure 400 is described with reference to the system 100; however, this is for exemplary purposes only and is not limiting.

[0171] like Figure 4As shown, the computing structure 400 is communicatively connected to the on-site environment 120 via one or more networks 402. For example, in an embodiment in which the computing structure 102 of the NGPCAS 100 utilizes the computing structure architecture 400, the one or more networks 402 may be included in Figure 1A The networks 402 typically include high-bandwidth data or communication links that support packet delivery to and from the computing structure 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 some portion of the 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.

[0172] Physical layer of computing architecture

[0173] like Figure 4 As further shown, the 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. Therefore, the computing platform 405 is 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 of which includes a corresponding plurality of computing fabric nodes N1, N2, ..., Nn (which are generally referred to herein as nodes Ny for readability purposes), including that the corresponding nodes Ny within each data center cluster Cx can be at least partially (if not completely) interconnected. Each different cluster C1, C2, ..., Cn can 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 connect the node Ny to one or more other nodes Ny of the data center cluster Cx. For example, the node Ny may be implemented on a single server, or may be implemented on a server group or server farm.

[0174] Each cluster Cx includes a plurality of nodes Ny that are communicatively interconnected with each other. In addition, different clusters Cx may be physically set at the same or different physical locations (e.g., at different locations 115, 118 where the physical devices 105, 108 of the NGPCAS100 are set, and / or at one or more other locations where the physical devices of the system 100 are not set). A specific cluster Cx may be implemented only at a single physical location or across multiple physical locations. In addition, 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.

[0175] Note that although the physical layer 405 associated with the computing structure 400 is described above as being implemented using physical data center clusters C1-Cn, in some embodiments, at least a portion of the physical layer 405 may be implemented as a virtualized physical layer 405. For example, the data center clusters C1-Cn (or a subset thereof) may be implemented as virtual machines, e.g., executing on a computing resource platform such as a cloud computing system.

[0176] Software-defined networking layer of the computing fabric

[0177] The example architecture of the computing fabric 400 also includes a software-defined (SD) network layer 410 that interfaces the physical layer 405 of the computing fabric 400 with the software-defined application layer 412 of the computing fabric 400. Therefore, the software-defined network layer 410 is interchangeably referred to herein as the "operating system (OS) 410" of the computing fabric 400. In general, the OS 410 of the computing fabric 400 can assign, designate, or allocate various computing fabric nodes Ny to perform corresponding roles or functions in support of the computing fabric 400, such as computing (e.g., via the node's corresponding processor and / or processing core) or data storage (e.g., via the node's corresponding memory). The computing fabric nodes Ny that are assigned, designated, or allocated to perform computing activities of the 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 storage activities of the computing fabric 400 are referred to herein as "storage nodes," respectively. Individual nodes Ny can function as only compute nodes, only storage nodes, or both compute and storage nodes, and the role of each individual node Ny can change dynamically over time, e.g., as directed by the OS 410. Advantageously, the 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 the computing fabric 400, and in particular, as required by other higher-level requirements of the computing fabric 400. For example, different nodes Ny of the computing fabric 400 can be assigned and reassigned to different clusters Cx, and / or different nodes Ny and / or different clusters Cx can be physically located at different physical locations 115, 118 of the NGPCAS 100, as needed.

[0178] The operating system 410 of the computing fabric 400 executes on the computing platform 405 and, in one embodiment, can be built based on any suitable general-purpose hyperconverged infrastructure (HCI) operating system (OS), such as Microsoft Azure Stack, VMWare HCI, Nutanix AOS, Kubernetes Orchestration, including Linux Containers (LXC / LXD), Docker Containers, Kata Containers, etc. 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, in contrast to a general-purpose HCI OS, and advantageously, in the computing fabric 400 of the next-generation process control and automation system 100, the OS support services dynamically respond 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 dynamically change (and / or are dynamically predicted to change by services within the application layer 412), the operating system 410 can automatically and responsively 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, as well as for other functionality related to industrial process control and automation. To this end, the computing fabric operating system 410 may include a set of supporting 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, process control and / or automation specific SD OS support services and / or functions 425 may include computing fabric individual resource and / or resource group management services that manage individual resources and / or resource groupings provided by the software-defined networking 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 structure 400 includes a general-purpose HCI operating system platform (e.g., Microsoft Azure Stack, VMWare HCI, etc.) that has been specifically customized to include SD compute services 415, SD storage services 418, SD networking services 420, SD orchestration services 422, and other process control and / or automation SDOS support services and / or functions 425, wherein the set of SD support services 415-425 automatically responds to and specifically supports the application layer software components 412 of the computing structure 400, which include process control and / or automation specific applications and services as previously discussed.

[0179] The interface between the software-defined network layer and the application layer of the computing fabric

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

[0181] Therefore, unlike the generalized layered IT (information technology) system architecture in which business logic applications are abstracted from the hardware and software computing platform and the management of its computing platform resources is primarily managed and designed by human IT administrators, the architecture of the computing structure 400 not only abstracts the higher-level business logic services, subsystems and other software components of the application layer 412 from the hardware and software computing platform 405, but also enables the higher-level software-defined services, subsystems and other software components 412 to dynamically, automatically and responsively guide and cause changes in the use of hardware and software resources of nodes Ny and clusters Cx of the physical layer 405 and the software-defined network layer 410, for example via APIs 428 and SD OS support services 415, 418, 420, 422, 425, without any human intervention or guidance. Specifically and advantageously, management of resources of the physical layer 405 and the software-defined networking layer 410 dynamically responds to changes in the configuration and requirements of these higher-level SD services, subsystems, and other software components of the application layer 412, and specifically, with respect to the specific requirements, boundaries, and limits of industrial process control and automation systems, such as timing, synchronization, and / or other control or automation specific constraints.

[0182] Containers and other types of micro-encapsulated execution environments

[0183] like Figure 4 As 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 the application layer 412. For ease of reading this document, the present disclosure categorically and interchangeably refers to these higher-level SD services, subsystems and other software components 435-448 as "software-defined application layer components" or "application layer software components" of the 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 the application layer 412) may collectively form a logical process control or automation system 445 (also interchangeably referred to herein as a "virtual" process control or automation system 445) that executes in conjunction with the physical components 135, 138 of the 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 445. In general, application layer software components may be provided by the enterprise (eg, via the architecture provider / manager 160), a user 155 acting as an agent for or associated with the enterprise 155, a third party, and / or other sources.

[0184] The application layer software components 435-448 of the application layer 412 can be executed in a container and / or in another suitable type of micro-encapsulated execution environment (MEEE) or particle, for example, 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 particle 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 particle.

[0185] In general, 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 a collection of containerized / micro-encapsulated components 140 of the NGPCAS 100 and are therefore isolated from other containerized / micro-encapsulated services and applications (e.g., other containerized / micro-encapsulated components 140) executing on the same node Ny. Thus, the terms "configuration container," "container image," and "containerized component" are used interchangeably herein and, for ease of discussion and not for purposes of limitation, are used generally and categorically herein to refer to any one or more suitable types of instantiated micro-encapsulated execution environments or particles, such as software containers, virtual machines, software agents, scripts, functions, calls, roles (e.g., lightweight processes such as Erlang, Scala, Akka, etc.), monolithic kernels (e.g., machine images that run on bare metal and contain all the 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 intermediary management software, such as a hypervisor or other type of container / package manager), and / or other types of micro-encapsulated execution environments or particles.

[0186] Various MEEEs or particles can be configured to perform (e.g., when instantiated) various operations ranging from broad to detailed within NGPCAS100. To illustrate using an example, a control routine may include multiple control modules that operate collaboratively to perform the control routine, the control modules may respectively include multiple functional blocks and other types of blocks that operate collaboratively to implement the control modules, and the functional blocks may respectively include multiple granular operations that operate collaboratively to perform the functional blocks. Therefore, in one specific implementation of this example, a single MEEE may be configured to execute (e.g., when instantiated) the entire control routine. In another specific implementation of this example, each MEEE in a group of MEEEs may be respectively configured to execute (e.g., when instantiated) a different control module or part of a control routine, and the group of instantiated MEEEs may operate collaboratively to execute the control routine as a group as a whole. In fact, in some specific implementations, the second set of MEEEs can be respectively configured to execute (e.g., when instantiated) different granular operations or parts of the control module (such as input function blocks, error detection function blocks, control function blocks, logic function blocks, scripts, output function blocks, etc.), and the second set of MEEEs can operate in coordination when instantiated to execute the control module as a group. In other specific implementations, a single MEEE can be configured to execute (e.g., when instantiated) as a process controller, a process control subsystem, a unit, a region, or even the entire process control system 445.

[0187] In another example, a single MEEE may be configured to execute (e.g., when instantiated) an entire complex data analysis routine for the entire NGPCAS100. Alternatively, each MEEE in a set of MEEEs may be separately configured to execute (e.g., when instantiated) a different simple data analysis routine (or some other corresponding portion of a complex data analysis routine), and the collaborative execution of the instantiated set of MEEEs may therefore result in the execution of the entire complex data analysis routine. In some specific implementations, another set of MEEEs, when instantiated, may collaboratively execute corresponding granular actions or operations of the simple data analysis routine (or other types of corresponding granular actions of the simple data analysis routine), thereby resulting in the execution of the entire simple analysis routine (or the entire complex data analysis routine portion, as the case may be). For example, granular analysis actions or operations may include computational functions (e.g., data aggregation and / or manipulation, such as mean, maximum, minimum, etc.), simple data analysis routines may 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 may include combinations of statistical calculations or algorithms, and in some cases in combination with other types of non-statistical calculations or algorithms.

[0188] In general, MEEE, granule or configuration container can be provided by the enterprise (for example, via architecture provider / manager 160, via application / service store, out of the box, etc.), as an agent of enterprise 155 or associated user 155, third party and / or other source. Various instantiated MEEE can be assigned to execute on various computing nodes Ny of system 400, which can be arranged in different physical and / or geographical locations. In addition, instantiated MEEE can be dynamically migrated from executing at one node to executing at another node, for example, based on detected and / or predicted resource usage, jurisdiction requirements and / or regulations, and / or other standards. In addition, instantiated MEEE can be allocated, fixed, dynamically assigned and / or dynamically migrated to execute on corresponding node Ny and / or data center cluster Cx, for example, via SD computing service 415. The SD compute service 415 may dynamically change, update, maintain, and / or otherwise manage the container images and their corresponding assignments to the compute nodes Ny as needed or as required, for example, to perform load balancing across the compute nodes Ny, for scheduled maintenance of the compute nodes Ny and / or their physical components, in response to detected and / or predicted resource usage and / or performance issues, to support expansion or contraction of the logical process control or automation system 445, to support expansion or contraction of the computing platform 405, based on jurisdictional regulations and / or requirements, etc. Thus, the NGPCAS 100 may be viewed as a dynamic, highly distributed collection of MEEEs or a dynamic grid of MEEEs, wherein the MEEEs may be located or arranged across multiple physical and / or geographic locations, and wherein one or more MEEEs may be dynamically reassigned and migrated to another node and / or another physical and / or geographic location during runtime operation of the NGPCAS 100 while maintaining execution of the runtime operations of the NGPCAS 100. Furthermore, the components forming the MEEE dynamic grid for a particular application, control routine, analysis routine, etc., can be dynamically moved or migrated or reassigned individually, in sets or groups, or together (if necessary) to other hardware in the computing fabric without affecting or interrupting the operation of the application, routine, etc. Thus, individual components of the MEEE dynamic grid for a particular application or use can be managed in the computing fabric separately from other components of the same application or use.

[0189] Within the computing fabric 400, some configuration containers, granules, or instantiated MEEEs may be allocated or assigned to respective compute nodes Ny by the SD compute service 415 and dynamically reassigned to different compute nodes Ny based on the dynamically changing configuration, performance, and requirements of the logical process control or automation system 445. In some cases, a configuration container may be assigned (and reassigned) to be executed by a specific processor or processor core of an SD compute node Ny. However, some configuration containers may be pinned to respective SD compute nodes Ny (e.g., by the SD compute service 415, by configuration, by a user, etc.) and not dynamically reassigned by the SD compute service 415 due to dynamically occurring conditions. That is, a pinned configuration container may execute on the compute node Ny to which the configuration container is pinned until the configuration container is unpinned from the compute node Ny, e.g., regardless of the dynamic conditions of the logical process control or automation system 445 (perhaps with the exception of a failure of the compute node Ny to which the configuration container is pinned). In other words, the software-defined networking layer 410 can restrict the pinned configuration container to utilize only the hardware and / or software resources to which it is pinned, and when the configuration container is unpinned, the SD networking layer 410 removes the restriction. If desired, the configuration container can additionally or alternatively be pinned to other physical or logical components of the compute fabric 400. For example, a configuration container can be pinned to another configuration container, a specific data cluster, a specific processing resource (e.g., a specific physical processor or a specific physical processor core of a compute node Ny), a physical rack or a portion of a physical rack served by a specific power source (where the physical rack physically houses the hardware of one or more compute fabric nodes), etc.

[0190] Furthermore, configuration containers, instantiated MEEEs, or particles can be nested within other configuration containers and / or pinned to other configuration containers, which is particularly useful in configuring and organizing a logical 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 configuration container for each provided service 435, 440 of that particular set can be nested within the configuration container of that particular process control system 438. For another example, multiple control routines and / or control module configuration containers can be nested within a particular controller service 435, and a particular controller service 435 can be nested within a particular process control subsystem 438. For 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 the industrial process plant 10, thereby forming a configured or programmed controller service. The controller or control service 435 may be functionally equivalent to a traditional dedicated hardware controller device as understood in the Purdue model, or the controller service 435 may be functionally equivalent to a control routine or control module configured into and executed by a traditional dedicated hardware controller device. A container may be configured with an instance of a configuration controller service, thereby forming a container image or instance of the configuration controller service that, when so configured, can execute to perform a specific set of configured process control logic, such as by using configuration control module containers, tags, reference values, etc. Multiple instances or container images of the configuration controller service (or other configuration applications and services) may be instantiated and executed by the computing structure 400.

[0191] As another example, containers, granules, or instantiated MEEEs within the SD application layer 412 may be used to represent and / or logically organize the physical and / or logical regions, areas, and components of the NGPCAS 100. For example, units, areas, etc. may be represented by corresponding configuration containers, and configuration containers corresponding to the physical and / or logical components of each unit, area, etc. may be nested within and / or pinned to their corresponding configuration organization containers. Thus, within the computing structure 400, a configured control routine container may be nested within or pinned to a configured controller container, and a configured controller container may be nested within or pinned to another configuration container, such as a container configured for a depropanizer.

[0192] For clarity and to facilitate the discussion herein, the term “container” is used herein to generally refer to an instantiated software component (ISC), which is a configured container, container image, containerized component, or other type of microencapsulated execution environment (MEEE) or particle, such as a container or other type of microencapsulated execution environment that has been configured to include instances of corresponding controller services, subsystems, or other services or applications provided by the application layer 412 of the computing structure 400.

[0193] Regardless, and in a manner similar to that discussed with respect to the computing resources of the computing platform 405, the containerized / micropackaged 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 needs of the logical process control or automation system 445. For example, the SD storage service 418 can oversee and manage the logical storage resources utilized by the configuration container of the logical process control or automation system 445 across the various physical hardware memory resources of one or more nodes Ny. For example, the configuration container and the memory required for its operation (e.g., random access memory, etc.) can be stored on a specific SD storage node Ny or a specific memory device or space of the SD storage node Ny. Additionally, if desired, some containerized components / MEEEs / granules 140 can be pinned to corresponding SD storage nodes Ny and / or to specific memory devices or memory regions of the SD storage node Ny. The SD storage service 418 may change, update, or otherwise manage one or more physical hardware memories of the computing platform 405 to support the logical storage resources of the computing structure 400 when and as needed, such as due to disk or other types of errors, for scheduled maintenance, due to addition / expansion of available physical memory in the computing platform 405, etc.

[0194] Still similarly, the SD networking service 420 can oversee and manage logical or virtual networks utilized by the containerized components / MEEEs / granules 140 of the logical process control or automation system 445 and / or by other containerized components / MEEEs / granules 140, which can be implemented by the SD networking service 420 across the compute fabric nodes Ny. For example, the SD networking service 420 can oversee and manage the networking and hardware resources of the compute platform 405 to support logical network functionality included in the logical process control system 445, such as virtual interfaces, virtual switches, virtual private networks, virtual firewall rules, etc., as well as to support the required networking between various configured containers or container images executing on the compute fabric 400. Furthermore, 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 / granules 140 of the computing fabric 400, the physical components 135, 138 of the field environment 120, and the networking therebetween are critical because missed and / or lost messages or communications can cause the industrial or physical process to become uncontrolled, which in turn can 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 so 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.

[0195] In addition to the SD compute services 415, SD storage services 418, and SD networking services 420, the compute fabric operating system 410 may also provide other OS support services 425 that are accessible via a set of APIs 428, 432 and that may be utilized or accessed by the application layer 412 to support a logical process control system 445 and other containerized components / MEEEs / granules 140 of the application layer 412 of the compute fabric 400. For example, the other OS services 425 may include life cycle management services, discovery services, security services, cipher 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 described in detail in the original text). Figure 4 In some embodiments of the computing structure 400, one or more support services may be executed at the application layer 412, for example as other software-defined services 440, rather than being executed at the software-defined network layer 410 as OS support services 425.

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

[0197] Application layer of computing structure

[0198] Turning now in more detail to the application layer 412 of the computing structure 400, and as Figure 4 As 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 software-defined process control or automation subsystems), 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 structure 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 structure 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, a third party, a supplier, an end user 155, and / or other sources. For example, one or more of applications 435 - 448 may be built on APIs 160 , 165 provided by computing fabric 102 , and / or one or more of applications 435 - 558 may be packaged as containers and distributed by orchestrator 422 .

[0199] Each different control service 435 can be configured with desired parameters, values, etc., and optionally with other control services 435; each instance of a configured control service 435 can execute in a corresponding container; and each configured container can be assigned (or pinned) to execute on a corresponding compute 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 executed in a manner similar to traditional hardware-implemented process controller devices, control modules, process control function blocks, etc. However, unlike traditional hardware-implemented process controller devices, traditional control modules, and traditional control function blocks, and advantageously, the computing structure 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 a control module service can be configured to execute a set of control function block services (each of which executes in its own container and each of which can be configured with corresponding parameters, values, etc.). Thus, the set of configuration containers corresponding to the set of configured control function block services can (although not necessarily) be nested within the configured control module services container, and the configured control module services container can be nested within the configured controller services container. The set of configuration 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. As the load changes, one or more configured function block service containers can be moved to execute on different processor cores, different processors, or even different compute fabric nodes in an attempt to rebalance the load; however, the moved function block service containers will still be nested under the configured control module services container and will execute accordingly.

[0200] In addition to the control services 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, diagnostics, analysis, safety routines, reporting, data historians, service configuration, container configuration, communication with external or other systems, enterprise-level applications, process control and / or automation resource and / or resource group management, etc. For example, process control and / or automation resource group management services may allow users 155 to group and / or isolate various resources based on NGPCAS 100 and / or other process control or automation considerations. For example, resource groups may be formed as follows: based on physical characteristics, such as site or physical location, group of sites / physical locations, subset of sites or physical locations, geographic 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 groupings corresponding to NGPCAS 100 and / or combinations thereof. In general, any process control or automation system-related functionality or business logic executed during the runtime of NGPCAS100 to control industrial processes, support NGPCAS100 and / or be associated with NGPCAS100 can be logically implemented in the computing structure 400 as corresponding application layer services 435, 440 executed in corresponding containers. For example, any one or more of the enterprise-level computing structure functionality 320 can be implemented in corresponding containers or as containerized services. In addition, when the business logic of the services 435, 440 and / or the recipient physical components 135 / 138 require this, any of the containerized services 435, 440 can be communicatively connected to the corresponding physical components 135 / 138 located in the physical location of the NGPCAS100, for example, via the SD network layer 410. In addition, any of the containerized services 435, 440 can be communicatively connected to any other containerized services 435, 440 to transfer data and / or information therebetween when their corresponding business logic requires this.

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

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

[0203] -Continuous process control subsystem for managing the scheduling and execution of business logic for logical and physical control system entities (such as controllers, I / O assignments, control modules, function blocks, ladder logic, and structured text-based control algorithms);

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

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

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

[0207] - A historian subsystem, which includes various application layer services to record time series data of process I / O and events within the system 100;

[0208] a diagnostic subsystem comprising various application layer services for collecting and providing diagnostic data from various other application layer services, other subsystems, computing fabric nodes Ny, components of the software defined networking layer 410, and / or other components of the system 100;

[0209] - a process I / O subsystem, which includes various application layer services to manage I / O connections and configurations for process I / O within a process control system 445 , such as packet router / switch services 442 ;

[0210] - a user subsystem, which includes various application layer services 440 to authenticate and / or validate user credentials when a user attempts to access the computing structure 400, e.g., via the APIs 160, 165;

[0211] - an alarm subsystem, which includes various application layer services for maintaining the definition, status, and state of alarms within the system 100, such as process alarms, hardware alarms, maintenance alarms, unit alarms, network layer alarms, I / O alarms, hardware asset alarms, software asset alarms, diagnostic alarms, etc.;

[0212] - a licensing subsystem that includes application layer services 440 to verify or ensure that users have privileges according to the licensing level of the computing structure 400 and / or system 100 (such as perpetual licensing, time subscription licensing, consumption-based licensing, remote licensing, etc.), enforce licensing and prevent unauthorized activities from occurring, provide management of licensing, report and log licensing status and activities, etc.;

[0213] a distributed event subsystem comprising various application layer services to distribute generated events (or notifications thereof) and corresponding timestamps indicating respective times of occurrence at respective event sources across all nodes Ny of the computing fabric 400 so that consistent record keeping can be provided across all nodes Ny; and

[0214] A configuration subsystem that manages the storage, updating, and versioning of a configuration database that stores configurations for various services provided by the application layer 412, such as control configurations. A corresponding instance of the configuration database can be stored at each compute fabric node Ny, so that the compute 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 come from a single local instance of the configuration database. In some cases, large read requests can be segmented and the results provided in parallel from multiple nodes Ny.

[0215] Furthermore, the application layer 412 of the computing structure 400 may include additional or alternative subsystems 438 that may be utilized by the system 100. For example, the subsystems 438 may include: a control strategy subsystem for higher-level and / or overall control strategies, e.g., to achieve product and process performance and quality goals; an analysis subsystem; an optimization subsystem; a mass and energy balance subsystem; a security subsystem, which may include one or more specialized algorithms for detecting security intrusions; and the like.

[0216] Software-defined router / switch services

[0217] 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 endpoints of the NGPCAS 100, such as from physical components 135 / 138 to containerized components / MEEE / granules 140 at the application layer 412 of the computing fabric 400, and vice versa; from physical components 135 / 138 to containerized components / MEEE / granules 140 at the network layer 410 of the computing fabric 400, and vice versa. granule 140 at the application layer 412 and vice versa; from a containerized component / MEEE / granule 140 at the application layer 412 to another containerized component / MEEE / granule 140 at the application layer 412; from a containerized component / MEEE / granule 140 at the network layer 410 to another containerized component / MEEE / granule 140 at the network layer 410; from a containerized component / MEEE / granule 140 at the application layer 412 to a containerized component / MEEE / granule 140 at the network layer 410 and vice versa, etc. For example, the packet router / switch service 442 can communicatively couple the respective endpoints and transmit data therebetween using any suitable data delivery or data transmission 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 a microservice / MEEE / granule communicatively connected via a microservice / MEEE / granule bus (not shown), the packet router / switch service 442 (in some cases, in conjunction with the OS 410 and its supporting services 415-425) can support and / or manage the microservice / MEEE / granule and the microservice / MEEE / granule bus so that the microservice / MEEE / granule can transmit data and / or information (e.g., in packetized format) therebetween. In additional or alternative embodiments, the software-defined packet router or switch service 442 can use any one or more packet-based networks or links (such as the network 402 and / or software-defined links provided by the computing fabric 400) to transmit packetized data and information between one or more containerized components / MEEE / granules 140 and / or physical components 135 / 138 of the NGPCAS 100.

[0218] Please 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 clarity of discussion (and not limitation). In other embodiments, the packet router / switch service 442 can be included in the subsystem 438 of the compute fabric 400, and / or at least a corresponding portion or all of the software-defined packet router / switch service 442 can be implemented in the HCI adapter 430 or in the compute fabric operating system 410. Alternatively, the packet router / switch service 442 can 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. Regardless, and generally speaking, the software-defined packet router / packet switch service 442 can generally be implemented as a containerized component / MEEE / granule 140 of the compute fabric 400.

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

[0220] As will be appreciated, a significant advantage of the system described herein is that it reduces the data movement and data storage required to support applications or other uses executing in real time in the computing structure. Specifically, due to the secure, real-time communication structure provided in the NGPCAS described herein, including the use of secure, encrypted data links (e.g., VPNs) between various software and hardware elements in the computing structure and in a physical location (e.g., a factory), elements in the computing structure, such as MEEEs, can access data in real time from anywhere in the system (i.e., from any other element where data is created or resides). This feature means that applications and other applications executed in or through higher-level system elements or platforms (e.g., control applications, maintenance applications, data entry or tracking applications, fleet management applications, etc.), or any individual MEEE or particle thereof, can access the data in real time anywhere the data resides (e.g., in another MEEE or particle anywhere in the system, in a computing structure database, in a physical location database or server, in a field device at a physical location, etc.) using, for example, publish / subscribe communications, dedicated data calls, etc. In fact, each MEEE or other computing element (granule) that forms or realizes specific application or uses can include pointer or reference to the data needed for its operation, wherein this data resides in the system, and granule can access this data in real time when it is needed or used by MEEE or granule.Therefore, for example, as long as data is created and / or initially stored, granule just can access and use this data.This feature means that before data can be used or accessed in real time by the application program or element (for example, granule) in the computing structure, data does not need to be moved from the server in the physical location to the server based on the cloud in the computing structure.Therefore, this feature accelerates computing operation and reduces the data flow that was executed in the past only for moving data from one location to another location so that this data can be used in real time for the application program that uses this data.Therefore system as described herein enables data to be used in any position that it resides in or generates by direct data call or publish / subscribe communication, no matter this data resides in the equipment in the computing structure or is generated by the equipment in the computing structure or by the equipment at physical location or factory.

[0221] Logical / virtual components

[0222] Furthermore, at the application layer 412 of the computing architecture 400, at least some physical process control devices or components of a conventional process control system (e.g., controllers, safety logic solvers or devices, data storage devices, etc.) can be logically implemented in a logical process control system 445 as corresponding services 435, 440, or subsystems 438 executing in corresponding containers. Such logical or virtual instances of process control devices or components can be configured in a manner similar to their physical counterparts by configuring the logical devices with control routines, other application layer software components 412, parameters, reference values, lists, and / or other data, as desired. For example, a controller service can be configured with several control modules, a display view service can be configured with user access controls and graphical elements, etc. The configured logical or virtual process control devices or components (e.g., container images of process control devices or components) can be identified within the logical process control system 445, for example, via corresponding device tags or identifiers, and 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. A logical or virtual instance of a process control device may be uniquely identified within the system 100 and operate as a single entity in place of any corresponding physical device of the system 100, or a logical or virtual instance of a process control device may be a proxy or digital twin of a physical device included in the system 100, such as previously described.

[0223] At the software-defined application layer 412, the computing fabric 400 also includes a software-defined storage entity or component 413 that can provide abstract data storage (and access thereto) for the services and subsystems 435-448 of the SD application layer 412. For example, a historian database, configuration database, and other types of process control system databases and data storage entities, as well as temporary storage utilized by the various process control application services 435-448 during execution, can be provided by the software-defined storage entity 413. Storage databases, regions, devices, etc. can be virtualized or logical storage entities or components that can be assigned or allocated (and 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 using the hardware memory resources of multiple nodes Ny. In addition, the SD storage service 418 of the computing structure 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 node 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.

[0224] Orchestration

[0225] Returning now to the software defined network layer 410 of the computing structure 400, for ease of discussion purposes, Figure 4 A specific computing fabric OS service, namely, orchestration service 422, is shown separately from the depiction of other computing fabric OS services 415-420, 425. In general, orchestration service 422 instantiates container images (e.g., container images of application layer control services 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, orchestration service 422 can instantiate and assign various instantiated container images to execute and / or utilize the resources of a single node Ny or the resources of two or more nodes Ny. In addition, orchestration service 422 can assign various SD data storage entities or components 413 of application layer 412 to reside on physical layer storage resources of a single node Ny, multiple nodes Ny, etc., for example, to facilitate easy and fast access by resident containerized components, 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 fault tolerance, load balancing, quality of service (QoS), and / or other performance aspects of the running containerized applications and services of the computing structure 400, for example, via the QoS configuration service 452, the fault tolerance service 455, the load balancing service 458, and other performance-related services 460 optionally provided by the OS 410. Thus, the orchestration service 422 can be called or accessed by other OS services 415, 418, 420, 425, and the orchestration service 422 can, in turn, call 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 so that the containerized components can operate efficiently and securely, for example, to control an industrial process at least at a best-effort performance level.

[0226] To this end, performance-related services 452-460 of OS 410 may monitor performance parameters, resource usage, and / or metrics during runtime, detect the occurrence and / or predict the occurrence of any associated conditions, 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 computing platform 405. Thus, during runtime of system 100, as various expected and / or unexpected hardware and / or software conditions arise and are detected, orchestration services 422 responsively adjusts the allocation of hardware and / or software resources of various computing fabric nodes Ny to instantiated container images to maintain (or attempt to maintain) a target or best-effort performance level and operational fidelity. Detected conditions that may cause orchestration service 422 to modify the allocation and / or assignment between containerized components 412 and physical resources of node Ny may include, for example, hardware failure or failure, software failure or failure, overloading of a particular compute fabric node, increased or decreased bandwidth of various network components, addition or removal of compute fabric nodes and / or compute fabric node clusters, hardware and / or software upgrades, pinning and / or unpinning of containerized services and / or applications, diagnostics, maintenance, and other routines that may cause hardware and / or software resources to be temporarily unavailable for runtime use, etc. Possible responsive and / or mitigating management actions that orchestration service may take may 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.

[0227] Thus, in general, the 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 both the individual container level and the aggregate level (e.g., at the subsystem level, the unit level, the region 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 supporting services 415, 418, 420, 422, 425, and its orchestration services 422 oversee and manage the hardware and software resources of the compute fabric nodes 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, such as for fault tolerance, quality of service, and / or other performance criteria of the compute fabric 400. Advantageously, as the demands 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 usage of the hardware and software resources of the node Ny, for example, in a responsive and / or predictive manner.

[0228] For example, when the logical process control system 445 creates an additional instance of the control service 435 that executes 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 the corresponding compute fabric node Ny, can rebalance existing containerized components between 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, and so on. For another example, when a particular cluster C2 needs to be taken out of service (e.g., expectedly for maintenance purposes or unexpectedly due to a lightning strike), the OS support services 415-425 may pre-assign containerized components currently assigned to execute on cluster C2 to other clusters based on the current needs of the logical process control system 445 and the availability of hardware and / or software resources of other clusters, and the support services 415-425 may accordingly adjust the routing table utilized by cluster Cx so that the continuity of execution of the containerized component is maintained even when cluster C2 is taken out of service.

[0229] Thus, the software-defined networking layer 410 automatically, dynamically, and responsively determines, initiates, and executes changes to the allocation of hardware and software resources of a node Ny of the computing platform 405 to different application layer software components 412 based on 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 services of the computing fabric 400), etc. Thus, the computing fabric 400 can automatically reallocate the hardware and software resources of the 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.

[0230] simulation

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

[0232] Example safety features of NGPCAS

[0233] 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 disadvantages, including increased complexity (and therefore, more opportunities for component and process failures), reduced performance, and greater risk of network intrusion. For example, in today's process control and automation systems, there are typically at least three different domains 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 may introduce significant delays in data delivery across multiple Purdue levels (e.g., from level 2 to level 4 and above). In addition, the industry is seeking to be able 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 this scenario, outbound firewalls and other currently implemented security mechanisms designed and utilized to prevent the flow of external information into the plant are necessarily compromised as 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), thereby introducing significant additional risks of external parties accessing information and data in the protected lower levels of the plant, as well as other types of network intrusions. Furthermore, 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 pass information between Purdue levels.

[0234] In addition, in today's systems that perform some process control and / or automation functions in the cloud, other undesirable problems 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. In addition, in addition to those introduced by the Purdue model implementation, cloud-based implementations also add additional delays, bottlenecks, and complexity. In addition, there is no sufficiently secure mechanism for supporting local communication between process control devices (e.g., field devices) and the cloud.

[0235] The security features of NGPCAS100 at least address 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 NGPCAS100. Examples of such security features are described below. Any of the security features described 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 NGPCAS100 can be implemented as services 425 provided by the software-defined network layer 410 of the computing structure 400. In addition, the software-defined network layer 410 can provide other services 415 for managing resources and / or groupings of hardware and / or software resources of the software-defined network layer 410 and / or physical layer 405 of the computing structure 400, which are allocated and / or utilized to support the security features of NGPCAS100.

[0236] Example Cybersecurity Features of NGPCAS

[0237] As previously discussed, communications between nodes, configuration containers, locations, devices, and / or other parts of the NGPCAS 100 and the manually operated computing device 155 (if any) can be protected via one or more VPNs, which may include mutually exclusive and / or nested VPNs. As previously indicated, for ease of discussion and not for purposes of 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, 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 through the VPN via corresponding sessions. The VPN configuration of the NGPCAS 100 (e.g., the number of VPNs, the type of VPN, 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.). In addition, the VPN configuration of the NGPCAS 100 can be customized to meet the security needs and requirements of, for example, enterprises and / or architecture provider managers. If desired, at least one of the VPNs of NGPCAS 100 may be a permanent VPN.

[0238] See Figure 1 and Figure 4To illustrate, in an example minimum VPN configuration, communications between the physical or on-site environment 120 of NGPCAS 100 (e.g., all or all components, devices, etc. of NGPCAS 100 disposed in the on-site environment 120) and the computing fabric 102 of NGPCAS 100 (including all or all containerized components included in the computing fabric 102) may be protected via only a single VPN. In an example maximum VPN configuration, communications between any pair of entities of NGPCAS 100 (e.g., exposed APIs 160, 165, other containerized components / MEEEs / granules 140, computing fabric 102, physical components 135, locations 115, 118, the entire physical environment 120, user applications and / or devices 155, infrastructure provider / manager applications and / or devices 161, etc.) may be protected via corresponding VPNs. For example, in a maximum VPN configuration, a configuration container that provides control service functionality that requires the use of utility functionality to execute a control service may communicate with a configuration container that provides utility functionality via a corresponding VPN. In an embodiment, the VPN configuration of NGPCAS 100 may include one or more of the following:

[0239] a point-to-point VPN, e.g., a VPN dedicated to servicing communications between only one physical component 135 and only one containerized component / MEEE / granule 140;

[0240] Point-to-multipoint VPNs, such as a VPN dedicated to servicing communications between only one physical component 135 and multiple containerized components / MEEEs / granules 140, a VPN dedicated to servicing communications between multiple physical components 135 and only one containerized component / MEEE / granule 140, etc.;

[0241] a multipoint-to-multipoint VPN, such as a VPN dedicated to servicing communications between only a subset of all physical components 135 at locations 115 and a subset of all containerized components / MEEEs / granules 140 at compute fabric 120;

[0242] A VPN specifically serving communications between different layers of the computing structure 400, such as communications between the software-defined application layer 412 and the software-defined network layer 410;

[0243] a VPN specifically servicing communications between one or more selected services, subsystems, and functionalities at different layers of the computing fabric 400, such as communications between a selected one or more of the services and / or subsystems 435, 438, 440 at the application layer 412 and a selected one or more of the software-defined services and / or functionalities 415, 418, 420, 425 at the network layer 410;

[0244] a VPN dedicated only to serving instances of the API 160 and user applications 155, and one or more other VPNs dedicated only to serving the API 160 and one or more containerized components / MEEEs / granules 140 and / or physical components 135, 138 required to obtain data or provide data to the user applications 155, e.g., in a point (e.g., API 160)-to-point and / or point (e.g., API 160)-to-multipoint manner;

[0245] a location-to-location VPN, such as a VPN dedicated to servicing communications between only a single location 135 and the entire computing structure 102;

[0246] A multi-location VPN, such as a VPN dedicated to servicing communications between the computing fabric 102 and a plurality of locations 115 , 118 , which collectively are only a subset of the total locations of the NGPCAS 100 ;

[0247] and / or other types of VPNs that protect and secure communications between endpoints specified or defined within NGPCAS 100 (e.g., nodes, configuration containers (which may include APIs 160, 161), locations, devices, and / or other portions of NGPCAS 100). Indeed, in an embodiment, each endpoint may be required to authenticate with each VPN that it will utilize to send and / or receive communications with one or more other entities that have been respectively authenticated with that VPN.

[0248] Example User Security Features of NGPCAS

[0249] As previously mentioned, the users 155 of NGPCAS100 may include human users who operate computing devices, such as operators, configuration engineers, third-party personnel who have been approved by the enterprise to access at least a portion of the system 100, another agent of the enterprise, or an agent of the architecture provider / manager 161, etc., with one or more applications (e.g., a web browser, a thin client, or another user interface) executed at the computing device to communicate with NGPCAS100. Additionally or alternatively, the users 155 may include automated users, such as external applications or services that do not have a user interface and are executed on an external (e.g., remote) computing device or system. The external application / service users 155 may be enterprise-based, such as applications and / or services that have been configured by enterprise personnel, or may be third-party applications and / or services. Some of the external application / service users 155 may 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 legitimate users 155 access system data and / or functionality, in order to protect the system 100 from possible network attacks, 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 users 155 to utilize may be implemented as corresponding containerized components / MEEEs / granules 140 in the computing structure 102, and such containerized components may be exposed to users 155 only via the API 160 (e.g., as a website, service, etc.), where the API 160 can be accessed by users 155, for example, via a web browser or thin client. Typically, any functionality (e.g., all functionality) provided by the NGPCAS 100 for users 155 to utilize can be accessed by users 155 only via one or more corresponding APIs 160. In addition, for further security, communication between users 155 and one or more APIs 160 may be protected via corresponding VPNs 158. For further security, user 155 may be required to first be authenticated to VPN 158 before being able to utilize API 160 , and in particular, a human user may undergo multi-factor authentication in order to gain access to VPN 158 .

[0250] 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 exposed to and / or that different users 155 are authorized to access may differ based on the users' respective credentials. For example, authorization of different users 155 to different APIs 160 may be based on the containerized components 140 (e.g., applications and / or services) to which the APIs 160 provide access. Additionally or alternatively, authorization of different users 155 to different APIs 160 may be implemented on an enterprise basis (e.g., a user 155 at enterprise A is permitted to access a first subset of APIs 160, while a user 155 at enterprise B is permitted to access a second, different subset of APIs 160); on a location basis; on a node basis; on a user credential basis (e.g., a user's role, responsibilities, and / or skills); on a time basis; and / or a combination thereof.

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

[0252] In addition, since user 155 is provided with access rights to selected functionality provided by NGPCAS100 via API 160, and since user 155 must be authenticated to VPN 158 and optionally authenticated to utilize the specific API 160 described above, network security risks are even more significantly reduced compared to the network security risks of today's systems. For example, this security technology used within NGPCAS100 eliminates 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 not have (e.g., zero) installed NGPCAS-specific software, thereby eliminating another possible path to network security vulnerabilities. For another example, a computing device operated by user 155 (human or automated) can be authenticated to VPN 158 that is not utilized by any component of NGPCAS100. 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 other possible avenues of network security vulnerabilities. For another example, any access (including read-only access) to the NPGCAS 100 or portions thereof by unauthorized (but otherwise valid) users 155 can be completely prevented.

[0253] Example Identity Security Features of NGPCAS

[0254] As previously mentioned, each component of NGPCAS 100 (each containerized component / MEEE / granule 140, each physical component 135, each device 105, 125, 108, 128, 148, each location 115, 118, computing fabric 145, infrastructure provider / manager 161, or generally speaking, any component that can serve as an endpoint within the NGPCAS 100 network) can be uniquely identified within NGPCAS 100 by a unique network identifier. In an embodiment, the unique network identifier of the subject component is based on the identity of the subject component as defined within the configuration database of NGPCAS 100. In a manner similar to that discussed above for the user 155 of 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 speaking, components of the NGPCAS 100 that have unique network identifiers (eg, all components of the NGPCAS 100 ) may be discovered within the NGPCAS 100 and may be required to utilize corresponding credentials for authentication and authorized access.

[0255] 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 the enterprise, such as the one described above with respect to Figure 5A In these devices, an indication of the association between the device's unique device identifier and the device's unique network identifier may be stored, for example, within the device itself, in a configuration database of NGPCAS 100, in a network manager of NGPCAS 100, or the like.

[0256] Example Communication Security Features of NGPCAS

[0257] To further protect NGPCAS100, all communications sent and received via the network of NGPCAS100 (e.g., via VPNs 130, 158, 162 between various authentication and authorization components) may be required to be signed and encrypted. Additionally or alternatively, plaintext protocols (such as HTTP) may be prohibited or otherwise prevented from being utilized within NGPCAS100. For further security in an arrangement where the architecture provider / administrator 161 manages multiple NGPCAS100s for multiple enterprises, each enterprise may have a different certificate authority (CA), and the use of self-signed certificates may be prohibited or otherwise prevented. In general, in order to maintain security within NGPCAS100 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.

[0258] Example calculation of structural safety features of NGPCAS

[0259] With particular regard to securing the compute fabric architecture 400 and its components, various security techniques may be employed within the NGPCAS 100. For example, as described above, the containerized components / MEEEs / granules 140 of the compute fabric 102 / 400 (e.g., APIs 160, 165; services and subsystems 435, 438, 440, 448, 413, 442 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.) may be configured for client credential access, where the client may be, for example, another containerized component / MEEE / granule 140, a user 155, or a fabric provider / administrator 161. That is, anonymous access to containerized components / MEEEs / granules 140 may not be allowed, and access to certain containerized components / MEEEs / granules 140 may be provided only to certain clients (e.g., via corresponding client certificates). Furthermore, client certificates may be rotated automatically and frequently. Additionally, in an embodiment, unused features (e.g., applications, services, etc.) may be placed in a disabled (not enabled) state.

[0260] In addition, the containerized components / MEEEs / particles 140 may be signed and scanned periodically for known vulnerabilities. The containerized components / MEEEs / particles 140 may be required to execute or run with minimal privileges (e.g., always run), and the runtime of the containerized components / MEEEs / particles 140 may be required to utilize the maximum level of container isolation (e.g., by default). In some implementations, the definition of groupings of containerized components may be prevented or restricted. For example, the NGPCAS 100 may be 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 may be defined or configured as a bioreactor grouping (e.g., by using a pod or other suitable mechanism provided by the operating system 410 of the computing structure 400) such that the bioreactor groupings of containerized components may be co-located and moved together, for example, to execute on different nodes, clusters, segments, etc.

[0261] At the physical layer 405 of the computing fabric 400 , access to different nodes Ny, different hardware segments, different clusters C1 , . . . , Cn, etc. may be controlled, for example, on a server basis, on an API basis, etc. Additionally, data at rest and disks may be encrypted at rest.

[0262] Example Hardware Security Features of NGPCAS

[0263] In an embodiment, field devices, hardware I / O devices, gateways, and other devices may include one or more forms of embedded device identification ("EDID"). In the same way that a serial number indicates a specific instance of a product and may indicate additional information regarding the model, options, or other data about the product, an 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, EDID may also facilitate faster and less labor-intensive commissioning of process plants.

[0264] Figures 5A to 5C The specific implementation of EDID in various types of hardware devices is shown. For example, Figure 5A is a block diagram illustrating a smart field device 500, such as a Foundation Fieldbus device. As will be appreciated, the smart field device 500 can be any number of device types, including 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, calculations, device tags, etc.). The smart field device 500 includes a processor 502, one or more memories 504 that store various data readable according to the Foundation Fieldbus protocol (e.g., measurements, set point values, status information, scaling information, limits, alarms, device descriptors, device IDs, device tags, etc.), as will be readily appreciated by those skilled in the art. The smart field device 500 also includes one or more sensors and / or actuators 506 and a communication transceiver 508, as will be appreciated. In Figure 5A In the illustrated smart field device 500 , the device also includes an embedded device ID (EDID) 510 .

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

[0266] I / O device 522 is shown in Figure 5C. The I / O device 522 shown in the figure is of a type generally known in process control (except for including one or more EDIDs) and can facilitate converting 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 structure), and converting one or more signals from a 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 of which couples a corresponding field device to the process control system via the I / O device 522. The I / O device 522 also includes one or more EDIDs 540, 550, 560. The EDIDs 540, 550, 560 included on the I / O device 522 may include a single EDID 540 associated with the entire I / O device 522, an EDID 560 associated with the I / O module library 528 (e.g., each configured to accept a set of terminals of a respective I / O module 530A-530D that couples a respective field device to the I / O device 522), and / or one or more EDIDs 550A-550D, each associated with a respective one of the I / O modules 530A-530D. In some embodiments, each individual component (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. Furthermore, while 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 device (i.e., other than an I / O module) for coupling a field device to the I / O device 522.

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

[0268] Figure 5D An example EDID 562 that may be embedded on a hardware device is shown. The EDID 562 may include only or at least a unique identifier 564. However, in the event that the EDID 562 includes multiple pieces of information, the information may be stored on the device as a series of values. Example optional values ​​(indicated by dashed boxes) that may be included in the EDID 562 include values ​​indicating the following: the owner / company / customer associated with the device 565, the model number of the device 566, the facility associated with the device 567, the geographic region associated with the device 568, the manufacturer of the device 569, a registry associated with the device 570, one or more options present on the device 571, the date the device was manufactured 572, and the like.

[0269] Particularly in embodiments where the EDID on a device includes only a unique ID, the database 580 may associate each EDID with values ​​indicating various information 565-572 as needed, such as Figure 5EThe various information 565-572 associated with each EDID may be dynamically stored in a database 580 when the device is sold, when the device is shipped, or even when the device is first used. The database 580 may be stored, for example, on the computing structure 102 and accessed by an EDID service 582, which may be responsible for authenticating and / or determining whether a device is allowed to operate in a particular process control system, either in its entirety or in conjunction with other services.

[0270] In an embodiment, upon connecting to the computing structure 102 (e.g., upon commissioning, process startup, reboot, etc.), each hardware device must authenticate with the system. A discovery service operating on the computing structure 102 requests and / or receives and / or discovers the EDID of each hardware device. The discovery service transmits each received EDID to an EDID service 582 (which, in an embodiment, may or may not be separate from the discovery service) and queries a database to determine one or more pieces of information associated with the EDID to determine whether to verify the EDID and, by extension, the device associated with the EDID. As non-limiting examples, the EDID service 582 may determine: whether a given EDID is associated with the owner / enterprise / customer associated with the process plant in which the device is located; whether a given EDID is associated with the geographic region in which it is currently operating; whether a given EDID is installed at the facility for which it is intended; and so on. If the EDID service 582 determines that the device is valid / verified, the EDID service 582 may communicate to other services (e.g., security services, certificate authority services, etc.) that the device should be allowed to operate (or operate at all) within the system. Alternatively, if the EDID service 582 determines that the device is invalid, stolen, counterfeit, off-site, in the wrong factory, in the wrong geographic area, etc., the EDID service 582 may communicate to other services that the device is not allowed to operate within the system, and in some embodiments, may remotely disable the device, rendering it completely inoperable.

[0271] In this way, EDID can be used to increase security by making it more likely that devices operating in the secure environment of a process plant are of known origin before issuing security certificates that allow the devices to connect to the secure network over which devices and services communicate across the computing fabric 102. That is, unverified devices will not be granted certificates by a certificate authority. EDID can also be used to prevent black market sales of devices (e.g., in violation of sanctions or trade restrictions), theft, reverse engineering, counterfeiting, etc. by prohibiting or otherwise preventing the operation of any device that is not on-site (not owned by an associated customer, not at an associated plant, not in an associated geographic area, stolen, etc.).

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

[0273] Figure 5F An example method 590 for implementing the use of EDID 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 the device is allowed to operate in the system (block 596).

[0274] Other example safety features of NGPCAS

[0275] In addition to the security features described above, NGPCAS100 may include one or more other security features that protect other functionality and aspects of the system 100, at least some of which may be provided out-of-the-box, and at least some of which may be customized and adjusted, for example, by an enterprise agent, by a system provider agent, and the like. Such security features may include, for example, role-based access control (RBAC) for various applications and human users, service principles, security policies, security audit logs (and optionally analysis and optimization of the data included therein), network security groups (e.g., by application, location, human user, and / or other categories), firewalls, and access control lists (ACLs), and the like. In addition, secrets (e.g., keys, certificates, etc.) utilized by the system 100 may be stored in one or more security repositories.

[0276] Additionally, the resources of system 100 may be protected in a hierarchical manner, such as in Figure 5GAs shown in the example resource security technology 599 shown. As previously discussed, resources may include hardware and / or software resources, such as components, clusters, nodes, services (e.g., configuration containers), etc. At a single or single resource level, each single resource can be protected (e.g., based on its identity, using keys and certificates, etc.) in a manner such as described above. At a higher level, resources can be grouped (e.g., in a manner such as described above), and each resource group can be ensured and protected (e.g., by group identity, keys, certificates, etc.) as a group. Resource groups can be defined and / or created based on any category, such as by location (e.g., locally at a field device, at a remote location, in a computing structure, 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 so that only users who have subscribed to a specific resource or resource group can access the specific resource or resource group. That is, access to a specific resource or resource group can be limited to those users with a subscription to it, thereby providing further security to system 100. It should be noted that a single resource can be included in one or more different resource groups and / or accessed via one or more different subscriptions. Furthermore, it should be noted that resource security techniques 599 can be applied locally at the location of the field device, non-locally at other physical locations, and / or within the computing structure, as needed. Of course, other resource security techniques may be utilized additionally or alternatively within NGPCAS 100.

[0277] Additional architectural features of NGPCAS

[0278] Due to the decentralized and highly configurable nature of the computing structure of the NGPCAS described herein, the NGPCAS for a specific 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 structure, which enables the enterprise to uniquely configure global or intra-plant data flows and execution management in a way that was not possible with previous control systems. Specifically, the computing structure of an enterprise with multiple physical plants or locations can be established in a hub and spoke configuration, where multiple different computing structure "hubs" can be created to support various different physical locations or plants connected to the center via a communication network that implements communication "spokes". Each center may have computing resources that are limited to or implemented in a specific geographic or sovereign region. These regions can be, for example, continents (e.g., North or South America, Europe, Africa, etc.), countries (e.g., the United States, Russia, China, Australia, Germany, France, etc.), states or limited regions of a specific country (e.g., California, Florida, etc.), or any other geographic or geopolitical region. In this case, the computing structure hardware can be implemented in a cloud environment or at other physical locations that are physically set up in a specific region (or a specific set of regions) or contained within a specific region (or a specific 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 spokes from the computing fabric center to the physical locations. In some cases, more than one computing fabric center can be connected to the same physical location, and each such computing fabric center can receive all or a subset of the data from that physical location. Furthermore, in some cases, a computing fabric center can be connected to one or more physical locations in 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.

[0279] Figure 6AAn example enterprise NGPCAS system 600 is shown having multiple computing fabric centers 602 located in various regions (in this case, countries or public political regions (e.g., the European Union)) connected to various physical locations via one or more communication spokes 603. In this example, the enterprise includes two computing fabric centers 602A and 602B located in the United States, one computing fabric center 602C located in Europe (e.g., one or more countries associated with the European Union (EU)), one computing fabric center 602D located in Russia, and one computing fabric center 602E located in Africa. Each of the computing fabric centers 602 includes one or more terminal communication spokes 603, each of which leads from the center 602 to a physical location 604. As will be appreciated, 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. In addition, if desired, one or more communication spokes 603I can be arranged or configured to provide communication between two centers 602 to enable direct inter-center communication. In this manner, data received from a specific physical location 604 at a first hub 602 via a communication spoke 603 at that hub 602 can be routed to a second computing fabric hub 602 via an inter-hub spoke 603I. Similarly, communications from a first hub 602 (such as control signals, data requests, configuration changes, etc.) can be sent by the first hub to a specific physical location 604 by sending the data via the inter-hub spoke 603I to the second hub 602, which can then provide the communication to the physical location 604 via the communication spoke 603 established between the second hub 602 and the physical location 604. Figure 6A As shown, a particular computing fabric hub 602 (such as hub 602A) may, in some cases, only include 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 fabric hub 602 (such as hub 602B) may include terminal spokes 603 leading to physical locations 604 in multiple different regions (such as leading to physical locations in both the United States and Europe). Similarly, multiple different hubs 602 may be connected to the same physical location 604 via different spokes, such as in the case with hubs 602B and 602C and physical location 604A.

[0280] Importantly, this hub and spoke configuration enables data and execution management to be configured and maintained separately at each computing fabric center 602, so that an enterprise with physical locations in multiple different regions can comply with various different laws or data governance rules within the specific region in which the physical locations and / or computing fabric center 602 are located. 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 therefore it may be important to separate and track different data sent to and stored at a specific computing fabric center 602 so that it is processed and disposed of in a manner that complies with the appropriate laws and regulations of the center 602. However, these laws and regulations generally apply only to static data, not to dynamic data. Therefore, the hub and spoke architecture described herein also enables data (all data or a subset of the data) collected by devices at a specific physical location to be governed by a set of data privacy laws associated with a specific region by enabling the collected data to be sent to and stored only at a computing fabric center 602 located in the region to which the data privacy laws and regulations apply. Thus, data collected at physical location 604A located in the EU can be directly sent to, for example, a computing fabric hub 602B in the United States, without being stored at hub 602C in the EU. In this case, a direct communication spoke 603A can be established between hub 602B in the United States and physical location 604A in the EU, and the data may or may not be sent to or stored at hub 602C in the EU. However, in another case, data from physical location 604B in the EU can first be sent to hub 602C in the EU via spoke 603B. However, computing fabric hub 602C in the EU can immediately send the data to hub 602B in the United States via inter-hub communication spoke 603I without storing the data, thereby ensuring that the data is not subject to EU data laws and regulations.

[0281] 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 centers and / or at various different physical locations using the same concepts. For example, different computing fabric centers 602 can manage the execution of applications and services and provide or manage user or application authorizations in different ways by storing and applying different sets of rules or policies to be implemented by each computing fabric center 602 at the physical locations 604 to which the centers 602 are connected. The ability of each computing fabric center 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 managing and controlling application execution in different ways at different physical locations 604 and different computing fabric centers 602. Therefore, even if each different center 602 or physical location 604 is associated with the same enterprise, this feature enables the use of different configuration paradigms at each different center 602 or even at each different physical location 604.

[0282] Generally speaking, to execute these data and execution management activities, the computing fabric for a particular center 602 stores a set of rules, such as data governance rules, execution rules, access authorization rules, and the like (illustrated as components 610A, 610B, 610C, 610D, and 610E at centers 602A, 602B, 602C, 602D, and 602E, respectively), which are then automatically implemented or applied by the appropriate computing fabric components at centers 602A through 602E to manage data flows, application and service execution, user and service authorizations, and the like. In addition, the architecture provider / administrator may provide an interface for each center 602 to enable an enterprise (e.g., one or more authorized configuration engineers associated with the enterprise) to define, set, and store data governance and execution rules 610 to be used at each center 602.

[0283] Figure 6B is a diagram 620 illustrating an example system hierarchy associated with an enterprise using the NGPCAS described herein and illustrating how various components of the NGPCAS system as described herein are associated and may be implemented in the structural elements described herein. Specifically, Figure 6B As shown, chart 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. Figure 6BAs shown, column 622 includes applications 630 that provide a customer or enterprise view of the NGPCA (as shown in column 626), where the applications 630 are stored and executed in a computing fabric in a cloud environment (as shown in column 624). Applications 630 may include any customer- or enterprise-facing and accessible applications, including, for example, one or more ATMP applications 632 that provide workflow tracking and security logging for, for example, one or more batch processes or production facilities; one or more enterprise monitoring applications 633 that provide a customer portal to existing functionality within the enterprise; one or more enterprise fleet management applications 634 that provide and track the real-time health and inventory status of enterprise equipment and can make recommendations for changes, updates, etc.; and one or more utility applications 635 (such as IEE applications). In addition, applications 630 may include one or more enterprise control applications 636 (which may include any of the process control elements described or mentioned herein, such as containerized control modules, containerized function blocks, enterprise or equipment twins, etc.). Similarly, applications 630 may include one or more operations applications 637, engineering applications 638, and data management applications 639. Operational applications 637 may include applications that enable insight into and control of process operations, such as DeltaV Live applications, operator interface applications, alarm management applications, data historian applications, and the like. Similarly, engineering applications 638 may include control and graphic configuration applications for defining and configuring control routines and user interfaces for control operations. Data management applications 639 may include data exchange and data visualization applications 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) may be included and supported in this level of NGPCAS. As indicated in column 626, applications 630 are user-facing and therefore visible and used directly by authorized users of the enterprise.

[0284] In addition, if Figure 6B As shown, NGPCAS includes a set of application frameworks 640 that support and enable applications 630 and, in this case, are implemented in a cloud environment that is used as at least part of the computing structure of the enterprise NGPCAS. The application frameworks 640 may include, for example, a framework 641 that provides, manages, and implements role-based security (application access), database (such as event and alarm databases, historians, etc.) access, configuration, and support 642, a service grid 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 conversion of communication protocols. The rules 645 may define the rules about Figure 6AThe data governance and application execution rules described herein. Of course, the frameworks 640 described herein are merely an example set of frameworks that can be used and supported in NGPCAS, and other frameworks may also be included or used instead. Furthermore, while the frameworks 640 can be configured and accessed by the enterprise, these frameworks 640 are not directly user-facing, but rather support user-facing applications 630.

[0285] In addition, the NGPCAS of diagram 620 includes one or more platforms 650, which can be implemented as a software as a service (SaaS) platform in a cloud environment of the computing fabric (as shown in column 624) to implement and support the application framework 640 and the application 630. The platforms 650 may include, for example, a Kubernetes (or other) container management and orchestration platform, an observability and platform monitoring platform (used by one or both of the enterprise or the infrastructure 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 for Figure 6A The aforementioned rules 610), cost and subscription tracking platforms, etc. Of course, Figure 6B The platform 650 listed or described in the foregoing is merely an example and may be used to support the various features of the NGPCAS described herein. However, other platforms may also be used or provided. Furthermore, the platform 650 need not be implemented as a SaaS platform. As will be appreciated, the platform 650 is managed by the architecture provider / manager with input from the enterprise.

[0286] In addition, if Figure 6B As shown, the NGPCAS hierarchical structure includes a cloud support structure 660 for implementing a cloud environment as part of a computing structure. Specifically, the cloud environment support structure 660 includes, for example, a system for implementing an AKS or a deterministic runtime environment. AZURE cloud operating system and ARC services, as described herein. Of course, other cloud environment support structures or services may also or alternatively be used or provided, and the NGCPAS described herein is not limited to the listed cloud support structures 660. Of course, as Figure 6BAs shown, cloud environment 660 provides control, data, and management planes (via VPN or other communication connections) to edge devices 670, which are located locally in various physical locations, as shown in column 624. Edge devices 670 may include, for example, I / O or other servers 672, data, networking, and storage servers 674 (such as data aggregators and / or VPN gateways), and local workload servers 676, which may be connected to local hardware 680, such as local controllers, field devices, and other local hardware, as shown in column 624. Of course, edge elements 672, 674, and 676, as well as local hardware such as controllers, I / O devices, and field devices, are located locally to generate, measure, or provide local access to data, as well as to perform other activities such as control, maintenance, and support activities.

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

[0288] Structural and supporting features of NGPCAS

[0289] As will be appreciated, the NGPCAS as described herein provides or enables its software-implemented components to be highly configurable, transferable, and editable because most control and support components (e.g., control modules, containers, etc.) reside and execute within the computing fabric, without being tied to specific or predetermined computer hardware (e.g., a specific server, processor, computer node, etc.). This feature enables system setup and configuration activities to be performed more quickly and easily than with traditional control systems because it enables enterprise system owners or managers to store configuration components for their systems within the computing fabric, access these components from any location, and copy these components to create or add additional control system fabrics associated with, for example, a new plant or new physical location added to the enterprise, new hardware installed at an existing physical location, etc., without having to specify the location or details of the computer hardware used to implement the additional configuration components. Furthermore, the architecture enables architecture providers / managers (also referred to herein as "APMs") to simultaneously oversee the operation of multiple different enterprise systems during their operation, enabling the APMs to provide general and specific support for the different enterprise systems. For example, 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 in a computing fabric of various different enterprise systems while these enterprise systems are executing to perform control and manufacturing activities. APM can provide these measures to different enterprise systems and can upgrade or change the configuration or use of 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 processors with higher processing speeds, more memory, etc.), or by taking other actions in the computing fabric based on quality of service metrics to ensure better quality of service or reduce costs if the quality of service meets expectations (e.g., meets the quality of service metrics promised or guaranteed by a specific enterprise license).

[0290] APM can also provide or implement various data analysis applications on various different enterprise systems to recommend changes to those systems, which can improve the operation of those systems. In addition, APM can aggregate data from different enterprises and analyze the data to detect trends, problems, etc., and then provide general guidance for specific enterprise systems based on the 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 system configurations perform better or worse than each other, which perform better or worse than the average or baseline system, etc. APM can then use other data analysis to determine why a specific system performs better or worse, such as determining whether the change 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. APM can then generate general guidance or best practices for one or more enterprise systems based on the knowledge determined in these analyses.

[0291] Furthermore, the architecture described herein enables faster development and testing of components to be added to a control system because the architecture enables control or other system containers or products to be developed and provided in a container registry or product registry for download and implementation by enterprise systems according to the wishes and timing of the enterprise system or enterprise system administrator. Feedback from the operation of these downloaded and implemented containers or products can also be automatically provided back to developers from the enterprise's computing structure as part of the development cycle to test, upgrade, and change the containers or products. The architecture allows or results in faster development cycles because it provides faster implementation of new features or products and provides automatic feedback on the operation of new or changed components. However, the development is still performed and implemented in a manner that enables each enterprise operator or administrator to control when new containers or products are downloaded to and implemented in their systems.

[0292] 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 the NGPCAS as described herein, including computing structures and factory hardware at one or more locations (i.e., physical locations) where gateway devices, I / O devices, and field devices are located to perform manufacturing or factory automation processes. Figure 7As shown in the example system of FIG, enterprise 702 includes a computing structure 720 connected to two physical locations 722A and 722B, which can be, for example, factories, buildings, areas, or other physical locations where gateways, I / O, and field devices are located to perform processes such as factory automation or manufacturing processes. Likewise, the computing structure 720 of enterprise 702 includes a plurality of different container sets for implementing control and related support features for equipment at locations 722A and 722B as described herein. Specifically, in FIG. Figure 7 In the example of FIG. 7 , computing structure 720 includes one or more container sets 726A for monitoring and controlling physical equipment at location 722A and one or more container sets 726B for monitoring and controlling equipment at location 722B. Of course, as described herein, containers 726A and 726B in computing structure 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. In addition, enterprise 702 can include one or more user interfaces 730 that connect to and interface with computing structure 720 using one or more APIs 732 within computing structure 720. User interfaces 730 and APIs 732 operate as described herein to enable owners, operators, configuration personnel, etc. of enterprise 702 to perform configuration, monitoring, and control activities with respect to physical locations 722 using containers 726 in the manner previously described herein.

[0293] Likewise, Figure 7 As shown, enterprise 704 includes a computing structure 740 connected to multiple physical locations 740 (including already installed locations 740A through 740C). Physical location 740D is shown in dashed lines to indicate that it will be added using the configuration applications and techniques described later herein. Figure 7 As shown, a computing fabric 740 of an enterprise 704 includes a collection of containers 750 that are installed in the computing fabric 740 and executed therein to monitor, control, and provide support services for equipment at a physical location 742. Furthermore, users or operators associated with the enterprise 704 can interface with the computing fabric 740 via a user interface 756 and an API 758 to perform monitoring, configuration, and operational activities with respect to the containers 750 within the computing fabric 740, for example, to visualize and control the operation of a control system executed or implemented by the containers 750 to control the equipment at the physical location 742. Of course, owners, operators, managers, etc. of the 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 the enterprise 704.

[0294] In addition, any other number of enterprises (such as Figure 7Each of the enterprises (shown as points in FIG. 70 through enterprise n 706) includes a computing fabric 760 coupled to a plurality of different physical locations 762A through 762n and includes containers or container groupings 770 for performing control and support activities with respect to the locations 762A through 762n. Again, the enterprise 706 may enable users to interface with the computing fabric 760 using one or more user interfaces 772 and one or more APIs 774, as described herein.

[0295] like Figure 7As shown, APM 710 is connected to each of the computing fabrics 720, 740, and 760 of each of the enterprises 702, 704, and 706 via a direct secure communication connection 780. Communication connection 780 can be configured to operate using separate security in any manner described herein, such as using a separate VPN for each of the computing fabrics 720, 740, and 760. Importantly, communication connection 780 provides APM 710 with information about the ongoing operation, configuration, and associated information of each of the containers, modules, programs, and the like within each of the computing fabrics 720, 740, and 760. Thus, in this manner, APM 710 has a direct and persistent connection to the computing fabrics of each of the enterprises 702, 704, and 706 and can use this connection to activate, allocate, remove, reduce, or change computer resources within each of the computing fabrics 720, 740, and 760 of each of the enterprise systems 702, 704, and 706, respectively. APM 710 can use direct and secure connections 780 to license, provision, configure, or otherwise establish sufficient computer equipment in a computing fabric for each of the enterprise systems 702, 704, 706 based on licenses purchased by the enterprise systems 702, 704, 706. In some cases, 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, APM 710 can have its own computer resources at one or more locations owned or operated by APM 710, which APM 710 uses 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 APM 710. For example, area 779 within computing structure 740 of enterprise 704 marked with a dashed line indicates that the elements executing in that portion of computing structure 740 are executed on computer hardware owned by, located at, or provided by enterprise 704, and may be, for example, computer hardware at one of locations 740A-740D or at a different facility associated with enterprise 704.

[0296] As will be appreciated, APM 710 has a direct and secure connection to the operational networks and computing structures of each of the enterprises 702, 704, 706, etc. that APM 710 manages or supports. Thus, APM 710 can simultaneously control the allocation of computer facilities or resources for each computing structure of any supported enterprise. Additionally, APM 710 can store and execute software or data analysis modules 782 that analyze operational data, such as metadata, from each of the computing structures 720, 740, 760 to calculate or determine various quality of service measurements or statistics for each of the computing structures 720, 740, and 760 of the enterprises 702, 704, and 706. Specifically, data analysis module 782 can determine communication latency, CPU usage, and other computing operation statistics that illustrate or define the quality of service provided or obtained by the computer hardware used in computing fabrics 720, 740, 760 within any of 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 APM 710 to make changes to the underlying configuration of the computing fabric provided or managed by 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 APM 710 and the respective owners of enterprises 702, 704, and 706. APM 710 can make these changes by making configuration changes within the computer hardware of computing fabrics 720, 740, 760 via secure connection 780, and / or can interface with any third-party providers of computer hardware or computing facilities used in computing fabrics 720, 740, and 760, such as with cloud computing providers like Microsoft Azure. Of course, APM 710 can change the configuration, quantity, identification, or any other configuration components of computer equipment used in or licensed from third parties in order to provide computing fabrics 720, 740, 760 in any desired manner. In this way, APM 710 has continuous control over the quality of service and configuration of computer equipment provided or licensed by APM 710 and provided to enterprises 702, 704, 706, which enables APM 710 to maintain an adequate or expected quality of service for the control systems used or implemented in those enterprises.

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

[0298] In any case, the APM 710 may analyze the data it receives from the computing structures 720, 740, 760 in any desired manner and at any grouping level. Figure 7 As shown in chart 790 in FIG, APM 710 may obtain and accumulate data from the various different computing structures 720, 740, and 760 of enterprises 702, 704, and 706, and analyze the data from all of these enterprises together to obtain an overall measure of the quality of service provided by APM 710. This combined enterprise data is shown by box 792 in chart 790. In addition, APM 710 may analyze the data from each computing structure 720, 740, 760 separately to provide statistics or service quality measurements on an enterprise-by-enterprise basis, and may communicate with each enterprise separately to provide each enterprise with a measure of service quality or other statistical measures associated with the enterprise as a whole. Such measurements or data are shown by charts 794A, 794B, and 794C for enterprises 702, 704, and 706, respectively. In addition, APM 710 may analyze the data from each computing structure 720, 740, 760 separately to provide statistics or service quality measurements on an enterprise-by-enterprise basis, and may communicate with each enterprise separately to provide each enterprise with a measure of service quality or other statistical measures associated with the enterprise as a whole. Such measurements or data are shown by charts 794A, 794B, and 794C for enterprises 702, 704, and 706, respectively. In addition, APM 710 may analyze the data from each computing structure 720, 740, 760 separately to provide statistics or service quality measurements on a enterprise-by-enterprise basis, such as Figure 7 796 ), on a control system by control system basis, on a container collection by container basis, on a container by container basis, or in any other manner, or based on any other grouping of components within or associated with containers, modules, programs, control systems, etc., executed in the computing fabric 720, 740, 760. Of course, the APM 710 may prepare or perform analyses in any other desired manner, or in association with any other grouping of plant hardware, software, containers, computing fabric hardware, etc. If desired, an enterprise owner may agree to or be provided with different reports based on various predetermined or desired groupings of hardware and / or software elements (at any level) within the enterprise's computing fabric.

[0299] APM 710 may also perform other types of analysis on any grouping of data associated with one or more of the enterprises to which APM 710 is connected, and may provide recommendations to the enterprise regarding potential changes to be made within the enterprise to improve performance, quality, etc., within the enterprise or a component of the enterprise (such as at a certain physical location, a group of control systems, a certain control loop, a group of control loops with similar functionality, etc.). For example, APM 710 may analyze the operation of one or more groups 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, APM 710 may analyze data related to the operation of a control loop or a group of control loops within the enterprise (such as a control loop used to control specific hardware at one or more plant locations), and may analyze timing signals, process variable measurements, response times, control loop statistics, etc. to determine whether one or more changes to the analyzed component may provide better performance in some manner. The APM 710 can use the results of the analysis to recommend various hardware and / or software configuration changes to be made, operations to be performed, or actions to be taken (such as running a tuning process) to provide better control operation, such as better control of signal timing, fluctuations, product quality, operating costs, etc. In some cases, the APM 710 can recommend new or different types of control or control loop algorithms, new tuning of process control devices or control loops, additional or different control algorithms that may be useful, different equipment that may be used, different control hardware or software configurations, such as changing the pinning or assignment of containers or groups of containers executed in a computing architecture, etc. Likewise, the analysis can be performed at any level, such as at the enterprise level, the physical plant or location level, the control loop level, the control module level, the container level, the container group level, the computer device level, etc. Of course, the APM 710 can perform other types of data analysis using data from multiple different enterprises or control systems, from a single enterprise, from a subset of components within an enterprise, etc. In some cases, APM 710 (which has access to data from multiple different enterprises) may look for commonalities or differences in operations at different locations or different hardware within the same enterprise, or at different locations or hardware within different enterprises, to find commonalities or differences in performance. APM 710 may then perform further data analysis to determine the sources or causes of those differences, including differences that cause control systems (control loops, control plants, etc.) to operate better or worse than one another or better or worse than a baseline or average. APM 710 may then provide the results of the analysis to the enterprise for changes to be made. Specifically, APM 710 may provide a report or analysis back to the enterprise to enable the enterprise to consider making changes to the control system implemented by the enterprise. In some cases, APM 710 may provide one or more products or containers for the enterprise to use to implement the recommended changes.

[0300] In addition, if Figure 7 As shown with respect to enterprise 704, each enterprise may include a configuration system 800 having one or more configuration databases (which may be one or more distinct computer databases or memories) and one or more configuration applications that store configuration elements for the enterprise or for portions of the enterprise, and that enable users to view, change, and manipulate the configuration databases to implement and enforce configuration changes for the enterprise, including configuration changes within elements executing in the enterprise's computing fabric and within hardware within or associated with one or more physical locations of the enterprise. The configuration database of configuration system 800 may, for example, store a library of elements (e.g., containers, modules, applications, products, etc.) used in the enterprise and may store information defining the identity and configuration of each element, group of elements, container, control system, etc., currently operating in the computing fabric or in devices within the enterprise's physical locations. Furthermore, the configuration applications may enable enterprise owners or managers to view and make changes to the configuration of any element of the enterprise, including making changes to the control system, adding or removing logical or physical equipment or components (and even physical locations) from the enterprise system, changing the location or placement of various resources or components (e.g., containers) within the computing fabric, adding new field devices, I / O devices, and the like. In addition, the application of the configuration system can implement configuration changes by downloading or changing the logical or software elements (e.g., containers) within the device in the computing structure or at the physical location according to the user's changes under the user's instructions. Since the control elements within the computing structure are generally not bound to the specific computer hardware within the computing structure, the configuration system 800 can easily change, delete, add, etc. the elements actually running in the computing structure without requiring the user to specify where to install those components accurately, so that the user can specify the logical configuration changes to be made and press a button to implement those changes in the actual hardware currently operating in the computing structure. The basic computing structure management system can then locate (or assign) the computer hardware that implements the changed or new components and make the changes seamlessly to the user. Although the configuration system 800 is shown as being stored in the computing structure of the enterprise and executed therein, one or more components of the configuration system 800 can be located in the computer hardware at one or more physical locations of the enterprise, located in off-site computing structure resources, distributed or shared between the computing structure at one or more physical locations and off-site or licensed computing structure hardware, stored in a dedicated machine in the computing structure or in one or more physical locations, or in any other manner.

[0301] Figure 8AThe operation of the configuration system 800 in an enterprise is shown in greater detail to illustrate how an enterprise owner, operator, or other user can use the configuration system 800 to make control and configuration changes to the enterprise or any portion thereof in a quick and easy-to-use manner. Indeed, in some cases, configuration changes can essentially be provided via a one-click push mechanism that can be used to install additional software or new software components or upgrade software within the enterprise's computing infrastructure. More specifically, Figure 8A A configuration system 800 is shown that can be used, for example, in one of the enterprises (such as Figure 7 The system is used at an enterprise 704 to add, change, or otherwise modify the configuration and operation of one or more process control system elements within or associated with the enterprise in an easily implementable manner.

[0302] 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 speaking, the enterprise configuration system 800 is located and executed in the enterprise to which it belongs, such as within the computing structure of the enterprise to which it belongs. However, some or all of the configuration system 800 may be stored and executed in hardware at one or more physical locations of the enterprise (which may or may not be part of the enterprise computing structure), at one or more dedicated hardware locations for the enterprise external to the computing structure, or in any other location. However, it is important that the configuration system 800 of the enterprise is connected to or integrated into the computing structure of the enterprise so that changes can be made directly to elements in the computing structure of the enterprise using the management structure of the computing structure. As Figure 8A As shown, the configuration system 800 includes a configuration database 801, one or more configuration applications 802, and a configuration execution engine 804 that are communicatively coupled together. Of course, the configuration database 801 stores configuration information for the enterprise, as currently configured. The configuration database may include one or more physical databases that contain data and relationships, such as the configuration of control modules and the relationships between them. Importantly, the configuration application 802 may include one or more user interface applications that generate one or more user interfaces, such as in Figure 8B , which enables a user, such as a configuration engineer at an enterprise, to take various actions with respect to changing or upgrading a control system or any element or component thereof. As will be understood, the user interface 822 may be displayed at any computer in the enterprise and may be accessed via the previously discussed but not yet described user interface. Figure 8A The API shown in is provided to off-site computers associated with the enterprise. In addition, the configuration engine 804 interfaces with the runtime system (e.g., the orchestrator and associated applications described herein) to implement configuration changes within the enterprise (such as within the enterprise's computing structure).

[0303] like Figure 8A As shown, the configuration system 800 is configured via Figure 7 The communication connections shown and described are connected to APM 805 and can coordinate with APM 805 to make certain types of configuration changes, such as licensing new software or hardware components in a computing fabric managed or licensed from APM or a third party, reducing, adding, or changing the hardware configuration within a computing fabric provided by APM (or a third-party hardware provider), etc. In addition, configuration system 800 is connected to a product or container registry 807 from which it can obtain new components, such as new containers, products, upgrades, etc. Configuration system 800 can access the product registry (which is external to the enterprise's computing fabric) using any of the security features previously discussed. In general, configuration system 800 includes components that interact with each other and with APM 805 and product / container registry 807 to enable users to specify and implement configuration changes in the enterprise. These configuration changes may include adding new physical locations, adding new or changed computer 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 structure, changing fixed or other specified relationships between logical components within the computing structure and / or between logical components and specific computing structure hardware, etc.

[0304] As an example, one or more of the configuration applications 802 of the configuration system 800 can be used to view the current configuration of various different elements (including both hardware and software elements) of an enterprise. In addition, 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 how one or more software elements, such as containers, are secured 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 a computing structure of an enterprise or a portion of an enterprise, and / or implementing any other desired configuration changes.

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

[0306] like Figure 8B As shown, the hierarchical structure portion 834 may include a hierarchical display that shows the various different configuration elements (or any other component groupings) of the enterprise at each level or sub-level of the enterprise to illustrate the configuration elements of the enterprise, which are currently present in an organized and easily located manner. For example, the enterprise hierarchical structure 834 may include a library portion 840 that includes a storage of copies of configuration elements such as control modules, control routines, function blocks, containers, and / or any other configuration elements stored as library elements in the configuration database. These library elements can be copies or general versions (i.e., uninstantiated versions) of control elements that exist in the enterprise system (such as at one of the enterprise's physical locations or in the computing structure). In addition, the hierarchical structure portion 834 may include a configuration database portion 841 for accessing the enterprise's actual configuration database, a physical network portion 842 that includes information about each disabled node or location and each currently debugged physical location of the enterprise 843. As shown for physical location 1, each physical location may include configuration and identifier information about the gateway, I / O device, field device, communication network, etc. at that physical location. Such elements may include, for example, I / O devices and gateway devices at each physical location, field devices and communication devices provided at each physical location, databases, communication structures, etc. Additionally, other physical I / O networks, such as wireless networks, may be listed under section 844. Additionally, the hierarchical structure section 834 may include a hierarchy of installed configuration elements, such as configuration elements associated with each physical location, with each control routine or control module in a collection of control routines or control modules, or any other control structure, etc.

[0307] In addition, the hierarchical structure 834 may include an indication of the control logic or control elements (e.g., containers) in the computing structure under the computing structure portion 845. The elements in the computing structure may include, for example, logical or virtual controllers, control modules, containers, etc., and may indicate how 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 supporting elements, such as one or more batch or continuous history records, batch execution programs, recipes, advanced control elements, data analysis programs or software (such as artificial intelligence (AI) programs or algorithms), monitoring software, etc., which are bound to the enterprise (such as in the enterprise's computing structure) and operate therein. Of course, it should be understood that the user can 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.

[0308] The diagram or programming area 836 of display 822 can be used to add, change, delete, reconfigure, program and / or otherwise create configuration elements to be installed in an enterprise (such as in the computing structure of the enterprise or in the equipment at one or more physical locations of the enterprise). Specifically, the user can select and view one or more elements of the hierarchical structure 834, and place these elements (or their copi...

Claims

1. A process control or automation system, comprising: a computing structure located remotely from and communicatively connected to one or more factory sites, the computing structure comprising computer equipment implementing computer-implemented elements for the one or more factory sites, the computer-implemented elements comprising a plurality of instantiated microencapsulated execution environments (MEEEs); a plurality of physical devices located at the one or more plant sites, the plurality of physical devices performing respective physical functions to implement one or more industrial or automated processes of the enterprise at respective ones of the one or more plant sites; as well as A communication gateway device located at each of the one or more factory sites, wherein each of the communication gateway devices implements networked communication between the multiple physical devices at the factory site and the MEEE of the computing structure that communicates with the physical devices at the factory site.

2. A process control or automation system according to claim 1, wherein the first plurality of instantiated MEEEs communicate with the plurality of physical devices at a specific plant site using one or more secure point-to-point (PTP) or peer-to-peer (P2P) connections, and wherein the communication gateway device at the specific plant site implements the one or more secure PTP or P2P connections between the computing structure and the plurality of physical devices at the specific plant site.

3. The process control or automation system of claim 2, wherein the communication gateway device uses one or more virtual private networks (VPNs) to implement the one or more secure point-to-point (PTP) or peer-to-peer (P2P) connections.

4. A process control or automation system according to claim 2, wherein a second plurality of instantiated MEEEs communicate with the plurality of physical devices at the specific plant site using a second set of one or more secure point-to-point (PTP) or peer-to-peer (P2P) connections, and wherein the communication gateway device at the specific plant site implements the second set of one or more secure PTP or P2P connections between the second plurality of instantiated MEEEs of the computing structure and the plurality of physical devices at the specific plant site.

5. A process control or automation system according to claim 1, wherein the communication gateway device at a specific plant site uses multiple different secure point-to-point (PTP) or peer-to-peer (P2P) connections to achieve communication between the multiple physical devices at the specific plant site and the MEEE of the computing structure.

6. The process control or automation system of claim 5, wherein the communication gateway device establishes a different secure network for each of the different secure point-to-point (PTP) or peer-to-peer (P2P) connections.

7. A process control or automation system according to claim 6, wherein the communication gateway device establishes a different virtual private network for each of the secure networks established for each of the different secure point-to-point (PTP) or peer-to-peer (P2P) connections.

8. A process control or automation system according to claim 1, wherein the communication gateway device at a specific plant site: uses a first secure point-to-point (PTP) or peer-to-peer (P2P) connection to implement a control network, which enables the MEEE of the computing structure to use the multiple physical devices at the specific plant site to implement online process control; and uses a second secure point-to-point (PTP) or peer-to-peer (P2P) connection to implement a network that does not perform online process control.

9. The process control or automation system of claim 8, wherein the second point-to-point (PTP) or peer-to-peer (P2P) connection implements a network that performs maintenance functions.

10. The process control or automation system of claim 8, wherein the second point-to-point (PTP) or peer-to-peer (P2P) connection implements a network that performs enterprise management functions with respect to devices or networks at the particular plant site.

11. The process control or automation system of claim 8, wherein the second point-to-point (PTP) or peer-to-peer (P2P) connection implements a network that performs a device or network monitoring function.

12. The process control or automation system of claim 8, wherein the second point-to-point (PTP) or peer-to-peer (P2P) connection implements a network that performs computing fabric provider or manager functions.

13. The process control or automation system of claim 1, wherein a particular plant site comprises one or more process controllers and one or more field devices, wherein the one or more process controllers control the one or more field devices to implement online process control at the physical site.

14. A process control or automation system according to claim 1, wherein a specific plant site includes one or more field devices connected to the communication gateway via one or more input / output devices, and wherein the first plurality of MEEEs of the computing structure use the one or more field devices to implement online process control at the specific plant site.

15. A method of performing process control or automation, the method comprising: storing and executing a plurality of instantiated microencapsulated execution environments (MEEEs) using a computing structure located remotely from and communicatively connected to one or more factory sites, the computing structure including a computer device implementing the MEEE to perform functions with respect to the one or more factory sites; operating a plurality of physical devices located at the one or more of the plant sites, the plurality of physical devices performing respective physical functions to implement one or more industrial or automated processes of an enterprise at respective ones of the one or more plant sites; as well as The multiple MEEEs are communicatively connected to the multiple physical devices at one of the factory sites via a communication gateway device located at one of the factory sites, and networked communication is achieved between the multiple physical devices at the factory site and the MEEEs of the computing structure via the communication gateway device.

16. A method according to claim 15, wherein executing multiple instantiated MEEEs using the computing structure includes executing a first plurality of instantiated MEEEs that communicate with the multiple physical devices at the one of the factory sites using one or more secure point-to-point (PTP) or peer-to-peer (P2P) connections, and includes enabling the communication gateway device at the one of the factory sites to implement the one or more secure PTP or P2P connections between the computing structure and the multiple physical devices at the one of the factory sites.

17. The method of claim 16, further comprising causing the communication gateway device to implement the one or more secure point-to-point (PTP) or peer-to-peer (P2P) connections using one or more virtual private networks (VPNs).

18. The method according to claim 16 further includes executing a second plurality of instantiated MEEEs to communicate with the plurality of physical devices at the one of the factory sites using a second set of one or more secure point-to-point (PTP) or peer-to-peer (P2P) connections, and includes enabling the communication gateway device at the one of the factory sites to implement the second set of one or more secure PTP or P2P connections between the second plurality of instantiated MEEEs of the computing structure and the plurality of physical devices at the one of the factory sites.

19. The method according to claim 15 further includes enabling the communication gateway device at one of the factory sites to use multiple different secure point-to-point (PTP) or peer-to-peer (P2P) connections to achieve communication between the multiple physical devices at one of the factory sites and the MEEE of the computing structure.

20. The method of claim 19, further comprising causing the communication gateway device to use a different security network for each of the different secure point-to-point (PTP) or peer-to-peer (P2P) connections.

21. The method of claim 20 further comprising causing the communication gateway device to use a different virtual private network for each of the secure networks established for each of the different secure point-to-point (PTP) or peer-to-peer (P2P) connections.

22. The method according to claim 15 includes enabling the communication gateway device at the one of the factory sites to: use a first secure point-to-point (PTP) or peer-to-peer (P2P) connection to implement a control network, wherein the control network enables the MEEE of the computing structure to use the multiple physical devices at the one of the factory sites to implement online process control; and use a second secure point-to-point (PTP) or peer-to-peer (P2P) connection to implement a network that does not perform online process control at the one of the factory sites.

23. The method of claim 22, wherein the second point-to-point (PTP) or peer-to-peer (P2P) connection implements a network for performing maintenance functions.

24. The method of claim 22, wherein the second point-to-point (PTP) or peer-to-peer (P2P) connection implements a network for performing enterprise management functions with respect to devices or networks at the particular plant site.

25. The method of claim 22, wherein the second point-to-point (PTP) or peer-to-peer (P2P) connection implements a network for performing a device or network monitoring function.

26. The method of claim 22, wherein the second point-to-point (PTP) or peer-to-peer (P2P) connection implements a network for performing computing fabric provider or manager functions.

27. A method according to claim 15, wherein the one of the plant sites includes one or more process controllers and one or more field devices, wherein the one or more process controllers control the one or more field devices to implement online process control at the one of the plant sites, and wherein the MEEE of the computing structure is interfaced with the one or more process controllers at the one of the plant sites via the communication gateway device.

28. A method according to claim 15, wherein the one of the plant sites includes one or more field devices connected to the communication gateway device via one or more input / output devices, and wherein the first plurality of MEEEs of the computing structure uses the one or more field devices to implement online process control at the one of the plant sites.

29. A control and communication system for use in process control or automation, the process control or automation operating in a computing structure located remotely from one or more plant sites, the computing structure comprising computer equipment implementing computer-implemented elements for the one or more plant sites, and each of the one or more plant sites comprising a plurality of physical devices performing respective physical functions to implement one or more industrial or automation processes of an enterprise at a respective one of the one or more plant sites, the control and communication system comprising: a plurality of instantiated micro-encapsulated execution environments (MEEEs) for executing functions with respect to one or more of the plurality of physical devices at one or more of the factory sites; as well as A communication gateway device located at each of the one or more factory sites, the communication gateway device being communicatively connected to the computing structure and the multiple physical devices at the corresponding factory site, wherein the communication gateway device implements networked communication between the multiple physical devices at the corresponding factory site and the MEEE that communicates with the physical devices at the corresponding factory site, wherein the networked communication is secure communication guided between one or more MEEEs in the MEEE and the multiple physical devices at the corresponding factory site.

30. A control and communication system according to claim 29, wherein the first plurality of instantiated MEEEs communicate with the plurality of physical devices at a specific plant site using one or more secure point-to-point (PTP) or peer-to-peer (P2P) connections, and wherein the communication gateway device at the specific plant site implements the one or more secure PTP or P2P connections between the computing structure and the plurality of physical devices at the specific plant site.

31. The control and communication system of claim 30, wherein the communication gateway device uses one or more virtual private networks (VPNs) to implement the one or more secure point-to-point (PTP) or peer-to-peer (P2P) connections.

32. A control and communication system according to claim 30, wherein a second plurality of instantiated MEEEs communicate with the plurality of physical devices at the specific factory site using a second set of one or more secure point-to-point (PTP) or peer-to-peer (P2P) connections, and wherein the communication gateway device at the specific factory site implements the second set of one or more secure PTP or P2P connections between the second plurality of instantiated MEEEs and the plurality of physical devices at the specific factory site.

33. A control and communication system according to claim 29, wherein the communication gateway device at a specific plant site uses multiple different secure point-to-point (PTP) or peer-to-peer (P2P) connections to achieve communication between the multiple physical devices at the specific plant site and the MEEE.

34. A control and communication system according to claim 33, wherein the communication gateway device establishes a different security network for each of the different secure point-to-point (PTP) or peer-to-peer (P2P) connections.

35. A control and communication system according to claim 34, wherein the communication gateway device establishes a different virtual private network for each of the secure networks established for each of the different secure point-to-point (PTP) or peer-to-peer (P2P) connections.

36. A control and communication system according to claim 29, wherein the communication gateway device at a specific plant site: uses a first secure point-to-point (PTP) or peer-to-peer (P2P) connection to implement a control network, which enables MEEE to use the multiple physical devices at the specific plant site to implement online process control; and uses a second secure point-to-point (PTP) or peer-to-peer (P2P) connection to implement a network that does not perform online process control.

37. The control and communication system of claim 36, wherein the second point-to-point (PTP) or peer-to-peer (P2P) connection implements a network that performs maintenance functions.

38. The control and communication system of claim 36, wherein the second point-to-point (PTP) or peer-to-peer (P2P) connection implements a network that performs enterprise management functions with respect to devices or networks at the particular plant site.

39. The control and communication system of claim 36, wherein the second point-to-point (PTP) or peer-to-peer (P2P) connection implements a network that performs a device or network monitoring function.

40. The control and communication system of claim 36, wherein the second point-to-point (PTP) or peer-to-peer (P2P) connection implements a network that performs computing fabric provider or manager functions.

41. The control and communication system of claim 29, wherein a particular plant site comprises one or more process controllers and one or more field devices, wherein the one or more process controllers control the one or more field devices to implement online process control at the physical site.

42. A control and communication system according to claim 29, wherein a specific plant site includes one or more field devices connected to the communication gateway via one or more input / output devices, and wherein a first plurality of the MEEEs use the one or more field devices to implement online process control at the specific plant site.

Images