Authentication / authorization framework for process control or automation system

Abstract

An architecture that supports a process control or automation system may include an authentication service that determines whether an entity (e.g., a human entity, an automation entity, a virtual entity, or a physical entity) is a party claimed by the entity, and an authorization service that determines whether to allow the entity to access a request for a resource. The authentication service provides a unique identity of the entity and corresponding security credentials, such as tokens used during authorization. The authorization service authorizes the entity to access the requested resource based on the role-based rights of the role to which the entity is assigned and the resource access rights to protect the requested resource. The role-based rights and / or the resource access rights may be ranked, respectively, to limit or constrain actions, activities, operations, and / or resource access based on specified criteria. Each entity may be authenticated, and each request of the authenticated entity may be authorized.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to and the benefit of U.S. non-provisional patent application No. 18 / 223,395, filed on July 18, 2023, entitled “Securing Access of a Process Control or Automation System,” the entire disclosure of which is hereby expressly incorporated herein by reference. Technical Field

[0003] The present application generally relates to an industrial process control system and / or automation system for an industrial process plant and specifically to an authentication and authorization framework or architecture for a next generation industrial process control and / or automation system, the authentication and authorization framework or architecture comprising: a general computing structure that is agnostic or unrelated to the physical location where the computing structure is implemented; one or more physical control or field devices located at one or more specific sites where a product or process is manufactured; and a transmission network that securely provides communication between the computing structure and a pool of physical devices. 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. Exemplary 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 a 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 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 next generation process plant and industrial control or automation system architecture enables a large amount of computer processing and IT infrastructure (referred to herein as computing 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 next generation 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 next generation control or automation 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 products or processes are 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 fabric 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 fabric can be implemented as one or more collections 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 fabric 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 next generation 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 be communicatively connected to a pool of physical equipment located at one or more physical locations using one or more transmission networks. 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] 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.

[0026] 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 collection 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.

[0027] 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.

[0028] In addition, during execution, each containerized component can be communicatively connected to a particular physical component or physical device or to another containerized component via a corresponding packet-based connection on a transport network, such that each containerized component and each physical component can be identified within the system by a unique name or identity that can be associated with a particular address (e.g., IP address, endpoint address) within the transport network. To maintain a high level of communication and resource security, containerized components, physical components, and other entities (e.g., human users, third-party users, other applications, etc.) can be authenticated and authorized to each other in pairs, for example on a per-entity basis, and / or authenticated and authorized to access various resources using implementations of the authentication and / or authorization techniques described herein. Upon successful authentication and authorization, the two endpoint components or entities can transmit data, instructions, and other information to each other during a session established between the two endpoint components or entities over the one or more transport networks.

[0029] 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).

[0030] 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.

[0031] 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 collection 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.

[0032] 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.

[0033] 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.

[0034] 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, the collection 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.

[0035] 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 computing 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 set of subsystems is highly available and readily available to any application layer service executed on the compute node, and the functionality provided by the set 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.

[0036] 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, authentication services, authorization services, other enterprise services, parts of process control systems or even entire process control systems from any location, execution of mobile services across different locations or sites, providing subscriptions or third-party services about the enterprise, providing centralized upgrades of the enterprise, and providing centralized monitoring of computing structures associated with the enterprise, etc.

[0037] In addition, the next generation process control or automation system may include and / or utilize an authentication and authorization framework (e.g., which may include authentication and / or authorization systems, architectures, methods, and / or techniques) to maintain a high level of security for communications and resources within the process control or automation system. For example, entities associated with the process control or automation system (such as containerized components, virtual components, logical components, physical components, human users, automated users, third-party human users, third-party automated users, etc.) may authenticate to the system, to a transport network, to a physical location, to a specific API, etc., and may be authorized on a per-entity basis, in pairs, and / or for access to various resources within the system. For example, a specific entity (and / or its corresponding API) may be authorized to communicate with another specific entity (and / or its corresponding API), for example, to access resources via the other specific entity.

[0038] In one embodiment, a system for authenticating and / or authorizing an entity to access resources in a process control or automation system includes an authorization service and an authorization database that stores an indication of a corresponding set of role permissions for each of a plurality of roles in the process control or automation system. The authorization service includes a set of computer-executable instructions stored on one or more computer-readable media that, when executed by one or more processors, cause the system to perform the following operations upon an entity's request for access to a resource of the process control or automation system: determining the role of the requesting entity and accessing the authorization database to determine a set of role permissions for the role of the requesting entity. When the set of role permissions and the set of resource access permissions for the resource are consistent, the system grants the requesting entity access to the resource, and when the set of role permissions and the set of resource access permissions are inconsistent, the system denies the requesting entity access to the resource. Additionally or alternatively, the system may include an authentication service that authenticates the entity to the process control or automation system, to a secure transport network, to a virtual private network (VPN), to a point-to-point connection, a peer-to-peer connection, a multipoint connection, a service, or the like. For example, when an entity initially accesses a client service of the system or communicates with the client service of the system (e.g., via a corresponding application programming interface (API)), the client service calls the authentication service to authenticate the identity of the accessing entity. The client service can be accessed via the corresponding API, and the client service may or may not be associated with access to resources and / or other entities of, for example, the process control or automation system. After successfully authenticating the entity, the client service establishes a session between the requesting entity and the second service. Within the session, the entity may request access to one or more resources associated with the client service, at which point the authorization service may be called to authorize the entity to utilize the requested resources. In some specific implementations, the authorization service may be called separately to authorize the entity to utilize each requested resource. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] Figure 1 is a block diagram of an example architecture of a next generation process control or automation system (“NGPCAS”) that may be used to control industrial and / or automation processes and in which the techniques of the present disclosure may be implemented.

[0040] Figure 2 is a block diagram of an example architecture of a next generation process control or automation system (“NGPCAS”) that may be used to control industrial and / or automation processes having an installed or legacy distributed control system and in which the techniques of the present disclosure may be implemented.

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

[0042] Figure 3B Describes the Figure 1 and Figure 2 The computing structure provides example enterprise-level computing structure functionality.

[0043] Figure 4 can be included in Figure 1 and Figure 2 A block diagram of an example architecture of the computing structure in NGPCAS.

[0044] Figure 5A It is available in Figure 1 and Figure 2 Block diagram of example security techniques utilized in NGPCAS.

[0045] Figure 5B It is available in Figure 1 and Figure 2 Block diagram of example security techniques utilized in NGPCAS.

[0046] Figure 5C It is available in Figure 1 and Figure 2 Utilized in or by the NGPCAS and / or by Figure 4 Block diagram of an example authentication framework or architecture utilized by a computing structure.

[0047] Figure 5D It is available in Figure 1 and Figure 2 Utilized in or by the NGPCAS and / or by Figure 4 A block diagram of an example authorization framework or architecture utilized by a computing structure.

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

[0049] In general, the next generation of process plant and industrial control and / or automation system architectures rely on a shared computing fabric to enable 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 high-bandwidth interconnects (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 enabling 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 shared by multiple enterprises each operating one or more process plants, and the fact that the next generation 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.

[0050] 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 construed as limiting the functionality available, 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 aspects of the various system elements and system operation.

[0051] Example 1

[0052] 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 process plants, tools for configuring operator workstations to monitor and control process plants, tools for performing asset management (e.g., tracking calibration, maintenance, etc.), and tools for instantiating and managing control modules that ultimately control process plants 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 implemented and managed by the system provider or the enterprise, or by the enterprise with assistance from the provider.

[0053] 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, which 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 collection 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.

[0054] 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 inputs 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.

[0055] 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.

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

[0057] 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.

[0058] 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.

[0059] 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.

[0060] 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.

[0061] Example 2

[0062] 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.

[0063] 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.

[0064] 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.

[0065] 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.

[0066] 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.

[0067] 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.

[0068] 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.

[0069] Example 3

[0070] 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.

[0071] 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.

[0072] 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.

[0073] 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).

[0074] 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.

[0075] The real-time tuning application monitors the latency between the computing structure 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.

[0076] 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.

[0077] Example 4

[0078] 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.

[0079] 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.

[0080] Example 5

[0081] 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.

[0082] 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.

[0083] 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.

[0084] 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.

[0085] 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 orchestrator service in the computing fabric) so that control of the process plant can fail over to the local computing fabric when necessary.

[0086] Example Next Generation Process Control or Automation System Architecture

[0087] Figure 1 is a block diagram of an example architecture of a next generation process control or automation system ("NGPCAS") 100, which can be used to control industrial and / or automated processes and in which embodiments of the authentication and / or authorization techniques described herein can be implemented. In some use cases, NGPCAS 100 may be used by chemical, petroleum, industrial, manufacturing, filling and packaging, or other types of enterprises to manufacture, refine, convert, generate, or produce physical materials or products. In an example implementation, NGPCAS 100 may utilize one or more techniques and / or features described in U.S. non-provisional patent application No. 18 / 223,395, entitled "Securing Access of a Process Control or Automation System," filed on July 18, 2023, the entire disclosure of which is hereby expressly incorporated herein by reference. For ease of reading, NGPCAS 100 may be referred to interchangeably herein as "system 100."

[0088] 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 105, 108). The plurality of physical devices 105, 108 (or the pool of physical devices 105, 108) 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.

[0089] 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 1 exemplified), or the pool of physical devices 105, 108 may be entirely 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.

[0090] 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.

[0091] like Figure 1As 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.

[0092] 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 1 not shown).

[0093] 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 1 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 1exemplified), 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 1 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.

[0094] The computing fabric 102 of the NGPCAS 100 supports the creation, execution, removal, maintenance, supervision, and management of a plurality of containerized applications and / or services 140 or a pool of containerized applications and / or services 140, which are generally referred to herein interchangeably as “a plurality of containerized components 140 or a pool of containerized components 140,” “a plurality of microencapsulated execution environments 140 (MEEEs 140) or a pool of microencapsulated execution environments 140,” or “a plurality of granules 140 or a pool of granules 140” of the NGPCAS 100. That is, a pool of containerized components / microencapsulated execution environments / granules 140 may include applications and / or services that have been configured into containers and / or other types of microencapsulated execution environments or granules, 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 collection of containerized components / MEEEs / granules 140 executing in a compute fabric 102 to execute 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.

[0095] Typically, different functionalities 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 .

[0096] 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 authenticated and authorized on a per-component basis and optionally pairwise with each other, for example, by using keys or any other suitable authentication and authorization techniques. Upon successful authentication and authorization, 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.

[0097] 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.).

[0098] 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 / MEEE / 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 purposes of illustration, Figure 1In 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, system 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 may additionally or alternatively be utilized.

[0099] 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 the totality 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.

[0100] 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.

[0101] 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 utilized in conjunction with endpoint authentication and authorization technologies to provide even greater security for the NGPCAS 100.

[0102] 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.

[0103] 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 1 The depicted 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 through 5 of the Purdue Model.

[0104] 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, etc. Typically, the human user 155 interacts with the NGPCAS 100 via a computing device operated by the user (e.g., a laptop computer, a tablet computer, a mobile computing device, an in-vehicle computing device, etc.), and an application, a web browser, or a similar executable program is executed on the computing device 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 a 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.

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

[0106] Figure 1 The specific user of interest 155 depicted 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 functionality, 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; etc. 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. Additionally, as Figure 1As shown, a fabric provider / administrator 161 (whether a human user or an application or service executing on a remote computing device) can authenticate to 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 NGPCAS 100. For example, one or more APIs 165 can themselves be containerized components / MEEEs / granules 140 of computing fabric 102.

[0107] 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.

[0108] 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 functionality 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.

[0109] 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 1 Containerized components / MEEEs / particles 140 (not shown) that 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 1Other services utilized by the containerized component / MEEE / granule 140 executed at (not shown) (e.g., discovery, security, encryption, certificate authority, key management, authentication, authorization, time synchronization, service location, console support, life cycle management, etc.); etc.

[0110] 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.

[0111] Additionally, Figure 1 Location n 118 is depicted 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 conventional legacy control system and / or may include a backup copy or virtual twin of at least a portion of the virtual process control system 145 executed on a computing platform local to location n 118.

[0112] 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.

[0113] Specifically, as discussed above, any data or information transmission between two components of the NGPCAS 100 (e.g., two different containerized components / MEEEs / particles 140, or a containerized component / MEEE / particle 140 and a physical component 135 / 138) may be implemented via a private session on a VPN (e.g., a VPN utilized by the computing structure 102 and the physical location where the physical component 102 is located), via a proprietary VPN utilized only by the endpoint components, and / or one or more other types of VPNs. Additionally, for security purposes, any and all users 155 / 161 may be required to access the system 100 via one or more APIs 160 / 165 and a proprietary VPN 158 / 162 established between the user 155 / 161 and the computing structure 102. Furthermore, all users may be required to authenticate (e.g., multi-factor authentication) before gaining access to the system 100 via the APIs 160 / 165. In this way, system data is exposed only to non-public addresses (e.g., addresses of components, computing fabric nodes, etc.) via VPN and authorized, authenticated entities. In addition, in some implementations, the containerized components / MEEE / particles 140 and the physical components 135, 138 may be authenticated to communicate within the system 100, on a transport network, with a physical location, etc. Additionally or alternatively, in some implementations, the containerized components / MEEE / particles 140 and the physical components 135, 138 may be authorized to communicate with other entities associated with the NGPCAS 100 and / or access resources when requested by the containerized components / MEEE / particles 140 and the physical components 135, 138. A more detailed description of authentication and authorization techniques is provided elsewhere within this disclosure. In addition, applications may be exposed as websites or services so that computing devices utilized by users access the system 100 via a "thin" client and do not have any system-related software executed thereon (perhaps with the exception of a thin client such as a portal application). Nonetheless, 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.

[0114] 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.

[0115] Figure 2 A block diagram illustrating an example architecture of a next generation process control or automation system ("NGPCAS") 100A having Figure 1The basic components of the system 100 are configured to support systems with installed or legacy distributed control systems such as control system) of an industrial and / or automated process, and in this next generation process control or automation system, the embodiments of the authentication and authorization technology described herein can be implemented. In this case, NGPCAS100A includes Figure 1 All components of the system 100 are connected to one or more plants or physical locations 115A and 118A where an installed traditional control system has been implemented. Figure 2 As illustrated, 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, which 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.

[0116] However, if Figure 2 As illustrated, the process controllers 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 fabric 102 via secure VPN links 130. The VPN gateway 180 operates as a data aggregator to collect data from the process controllers 170, or in another embodiment, directly from the I / O devices 172 (illustrated by the dashed lines at location 115A) to obtain, manage, transform, aggregate, and collect data from field devices 174. The VPN gateway 180 also operates to encrypt the collected data and provide it to other components in the computing fabric 102 (which use the data to perform control or other services) via the VPN or other secure and encrypted communication link 130. In the case of location 115A, the NGPCAS 100A may simply bypass the controller 170 to perform a similar operation to the NGPCAS 100A. Figure 1 The controller 170 obtains data from the field device 174 and the I / O device 172 in the manner illustrated by the I / O interfaces 125 and 128 and the field devices 135 and 138. In this case, the controller 170 can be operated and programmed to back up the control system 168, such as Figure 1As illustrated, the controller 170 at the location 115A is enabled to take over control of the field devices 174 at the location 115A in a failover or backup situation.

[0117] On the other hand, as regards Figure 2 118A, the controller 170 may operate as part of the computing structure 102 and have software modules (such as containers, etc.) associated with the computing structure 102 stored and operating therein. In this case, the controller 170 (at location 118A) is part of the computing structure 102, which is indicated by the controller 170 extending downward into the physical location 118A to include the controller 170. Figure 2 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.

[0118] exist Figure 2 In both examples, the data aggregator and VPN gateway 180 are included to enable the NGPCAS described herein to connect to and use already installed legacy control system hardware (such as process controllers, field devices, I / O devices, etc.), which makes the NGPCAS described herein easier and less expensive to install and use in a plant or other physical location where control hardware is already installed. Thus, the VPN gateway 180 enables the NGPCAS system 100A described herein to be used to quickly and easily convert a standard legacy control system (such as a distributed control system) to an NGPCAS. Of course, while Figure 2 A conventional or installed control system is illustrated as a distributed control system, but other conventional or installed control systems may be used in the same or similar manner to support NGPCAS.

[0119] Example multi-enterprise NGPCAS architecture

[0120] The Next Generation Process Control or Automation System (NGPCAS) 100 described in the previous 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.

[0121] Figure 3AThe 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 are 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., operations, 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 a containerized application or service related to the process equipment. Figure 1 The containerized component / MEEE / particle 140 is executed in the described manner.

[0122] 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 1 accessed and operated by human or automated users 155 and / or architecture providers / administrators 161).

[0123] Example enterprise-class computing functionality

[0124] Figure 3B shows what can be included in the representative Figure 3AExample 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 a process monitored 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, 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 involves 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, warnings, 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 issue 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.

[0125] 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 physical device location, a second physical device location, a third physical device location, etc., 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 among the first physical device location, the second physical device location, the third physical device location, etc. 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 1 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.

[0126] 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.

[0127] 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.

[0128] 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.

[0129] In some embodiments, the architecture provider / manager (e.g., Figure 1 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.

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

[0131] In addition to providing centralized management of application / service upgrades, the infrastructure provider / manager (e.g., Figure 1 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.

[0132] Furthermore, in some implementations, the enterprise-level computing fabric functionality 320 may include an authentication service 355 and / or an authorization service 358 to authenticate and authorize various entities, respectively. The computing fabric functionality 320 may also include an entity management service 360 ​​to manage identities, security credentials, roles, scopes, permissions, and / or other information related to authentication and authorization of entities included in and associated with one or more NGPCASs within the enterprise, such as in a manner described in greater detail elsewhere herein.

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

[0134] Example computing structure architecture

[0135] about Figure 1 The computing structure 102 of the next generation process control or automation system 100, Figure 4 A block diagram of an example architecture 400 of the computing structure 102 is depicted. 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 is made hereinafter to the example architecture 400. Figure 1 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."

[0136] 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 may 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 1 The computing structure 400 is described with reference to the system 100; however, this is for exemplary purposes only and is not limiting.

[0137] like Figure 4 As shown, the computing fabric 400 is communicatively connected to the on-site environment 120 via one or more networks 402. For example, in an embodiment where the computing fabric 102 of the NGPCAS 100 utilizes the computing fabric architecture 400, the one or more networks 402 may be included in Figure 1 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.

[0138] Physical layer of computing architecture

[0139] like Figure 4As 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 collection 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.

[0140] 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.

[0141] 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.

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

[0143] 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.

[0144] The operating system 410 of the computing fabric 400 executes on the computing platform 405 and, in one embodiment, may 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 collection 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 or 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 can include a collection of support services, including, for example, software-defined (SD) computing services 415, SD storage services 418, SD networking services 420, SD orchestration services 422 (also interchangeably referred to herein as "orchestrator 422"), and optionally one or more other process control and / or automation-specific SD OS support services and / or functions 425. For example, 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 fabric 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 SD OS support services and / or functionality 425, wherein the collection of SD support services 415-425 automatically responds to and specifically supports application layer software components 412 of the computing fabric 400, which include process control and / or automation specific applications and services as previously discussed.

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

[0146] 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 an interface service 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) 428, via an HCI adapter 430 (also referred to herein as the "HCI adapter layer" 430) and another set of APIs 432, or directly ( Figure 4 The HCI adapter layer 430 interfaces with the OS 410 (and, in some cases, specifically with one or more of the SD-specific support services 415, 418, 420, 422, 425 provided by the OS 410). 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.

[0147] 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.

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

[0149] 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 1 The logical process control or automation system 145 may include Figure 4 445. In general, application layer software components may be provided by an enterprise (eg, via an infrastructure provider / manager 161), a user 155 acting as an agent or associated with the enterprise, a third party, and / or other sources.

[0150] 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.

[0151] 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.

[0152] 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.

[0153] In another example, a single MEEE may be configured to execute (e.g., when instantiated) an entire complex data analysis routine for the entire NGPCAS 100. Alternatively, each MEEE in a set of MEEEs may be respectively 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 coordinated execution of the instantiated set of MEEEs may thereby result in the execution of the entire complex data analysis routine. In some specific implementations, another set of MEEEs, when instantiated, may collaboratively perform 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.

[0154] In general, MEEE, granule or configuration container can be provided by the enterprise (for example, via architecture provider / manager 161, 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.

[0155] 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.

[0156] 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.

[0157] 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 configuration control routine container may be nested within or pinned to a configuration controller container, and a configuration controller container may be nested within or pinned to another configuration container, such as a container configured for a depropanizer.

[0158] 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.

[0159] 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.

[0160] 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.

[0161] 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, authorization 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.

[0162] 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.

[0163] Application layer of computing structure

[0164] 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 collection of software-defined services or applications 435 (such as software-defined process control or automation related services 435) and a collection of subsystems 438 of the NGPCAS100 (such as software-defined process control or automation subsystems), and optionally may include a collection of other software-defined business logic services 440 of the NGPCAS100 (for example, 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 collection 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 a user may develop, generate, install, and manage the third-party services 448 at the SD application layer 412 via the software development kit. In general, the services and applications 435-448 provided at the application layer 412 form a logical process control system 445 and provide related functionality. In general, applications 435-448 may be provided by system 100 itself, third parties, vendors, end users 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-448 may be packaged as containers and distributed by orchestrator 422.

[0165] 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 collection of control function block services (where each control function block service executes in its own container and where each control function block service can be configured with corresponding parameters, values, etc.). Thus, a set of configuration containers corresponding to a set of configuration control module services can (although not necessarily) be nested within a configuration control module service container, and the configuration control module service container can be nested within a configuration controller service container. A set of configuration containers corresponding to a set of configuration control module 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 service container and will execute accordingly.

[0166] 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 of information with external or other systems, enterprise-level applications, process control and / or automation resource and / or resource group management, entity authentication associated with the NGPCAS 100, entity authorization associated with the NGPCAS 100, entity supervision services for the NGPCAS 100, etc. For example, process control and / or automation resource group management services may allow the user 155 to group and / or isolate various resources based on the NGPCAS 100 and / or other process control or automation considerations. For example, resource groups may be formed based on physical characteristics, such as sites or physical locations, groups of sites / physical locations, subsets of sites or physical locations, geographic regions, etc.; based on logical characteristics, such as categories, containers and / or container types, control policies, capabilities, 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 NGPCAS100 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 related to NGPCAS100 may be logically implemented in the computing fabric 400 as corresponding application layer services 435, 440 executed in corresponding containers. For example, any one or more of the enterprise-level computing fabric functionalities 320 may be implemented in corresponding containers or as containerized services. Furthermore, 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 may communicatively connect with the corresponding physical components 135 / 138 disposed in the physical location of the NGPCAS 100, for example, via the SD network layer 410. Furthermore, any of the containerized services 435, 440 may communicatively connect with any other containerized service 435, 440 to transfer data and / or information therebetween when their respective business logic requires this.

[0167] In a similar manner, each of the different subsystems 438 of the application layer 412 of the computing structure 400 may be provided by or executed in a corresponding container. The collection 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 therefore, the configuration containers of the services 435, 438 provided by the subsystem may be nested within the configured subsystem container. Generally speaking, the collection 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 corresponding instance of each subsystem in the collection of subsystems 438, e.g., so that the subsystem services are readily available and easily available to other application layer services 435, 440, 448 currently executing on each node Ny. Thus, changes to one or more subsystems 438 may be coordinated between their corresponding instances executing at each node Ny (e.g., under the guidance of the OS 410). Thus, 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.

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

[0169] -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);

[0170] 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);

[0171] - 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;

[0172] - 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);

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

[0174] 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;

[0175] - 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 ;

[0176] - a user subsystem, which includes various application layer services 440 to authenticate and / or verify user credentials when a user attempts to access the computing structure 400, for example, via the APIs 160, 165;

[0177] - 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.;

[0178] - 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.;

[0179] 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

[0180] 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.

[0181] 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.

[0182] Software-defined router / switch services

[0183] 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.

[0184] 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.

[0185] 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.

[0186] 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.

[0187] Logical / virtual components

[0188] 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.

[0189] 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 history database, a configuration database, other types of process control system databases and data storage entities, an authentication database, an authorization database, and temporary storage utilized by various process control and other types of application services 435-448 during execution can be provided by the software-defined storage entity 413. Storage databases, areas, 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.

[0190] Orchestration

[0191] 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.

[0192] 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.

[0193] 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.

[0194] 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.

[0195] 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.

[0196] simulation

[0197] 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.

[0198] Example safety features of NGPCAS

[0199] Next, various security features of the next generation process control or 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, technicians or other process plant personnel may work remotely via their portable computing devices 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.

[0200] In addition, in today's systems that implement some process control and / or automation functionality 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, cloud-based implementations add additional delays, bottlenecks, and complexity beyond those introduced by the Purdue model implementation. Furthermore, there are no sufficiently secure mechanisms for supporting local communication between process control devices (e.g., field devices) and the cloud.

[0201] 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.

[0202] Example Cybersecurity Features of NGPCAS

[0203] 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.

[0204] See also Figure 1 and Figure 4To illustrate, in an example minimum VPN configuration, communications between the physical or on-site environment 120 of the NGPCAS 100 (e.g., all or all components, devices, etc. of the NGPCAS 100 disposed in the on-site environment 120) and the computing fabric 102 of the 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 the 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 / administrator 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 corresponding VPNs. In an embodiment, the VPN configuration of NGPCAS 100 may include one or more of the following:

[0205] 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;

[0206] 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.;

[0207] 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;

[0208] 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;

[0209] 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;

[0210] 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;

[0211] 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;

[0212] 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 ;

[0213] 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.

[0214] Example User Security Features of NGPCAS

[0215] 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 even 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 .

[0216] 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 authorized to be accessed by different users 155 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. In some implementations, a particular user 155 may be authenticated to the system 100, to a transport network, to a physical location, to a specific API, and / or the like. In some implementations, a particular user 155 may be authorized to communicate with other entities associated with the system 100 (such as containerized components / MEEEs / granules 140, physical components 135 / 138, and / or corresponding APIs of granules 140 and / or physical components 135 / 138) and / or access resources associated with other entities associated with the system 100 (e.g., via corresponding APIs of the resources). A more detailed description of authentication and authorization of users 155, containerized components / MEEEs / granules 140, physical components 135 / 138, and / or other entities associated with the system 100 is provided elsewhere within this disclosure.

[0217] Therefore, by using VPNs to protect communications within NGPCAS 100, 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, NGPCAS 100 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 NGPCAS 100, thereby simplifying the design, engineering, configuration, maintenance, and runtime execution of NGPCAS 100 compared to systems based on the Purdue model. Furthermore, 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 the 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.

[0218] In addition, because user 155 is provided with access to selected functionality provided by NGPCAS100 via API 160, and because user 155 must authenticate to VPN 158 and optionally be authenticated and / or authorized to utilize the specific API 160 discussed 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.

[0219] Example Identity Security Features of NGPCAS

[0220] 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 certificates for authentication and authorized access.

[0221] 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. 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 the NGPCAS 100, in a network manager of the NGPCAS 100, or the like.

[0222] Example Communication Security Features of NGPCAS

[0223] 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.

[0224] Example calculation of structural safety features of NGPCAS

[0225] 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.

[0226] 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.

[0227] 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.

[0228] Sample authentication and authorization service for NGPCAS

[0229] To improve the security of NGPCAS 100 and the security within the NGPCAS, entities associated with NGPCAS 100 may be authenticated and / or authorized via an example authentication and authorization framework or architecture. For ease of illustration and not for purposes of limitation, reference is also made herein to Figure 1 A. Figure 1 B and Figures 2 to 4 An example authentication and authorization framework or architecture is described, but it should be understood that embodiments of at least portions of the authentication and authorization framework / architecture may be utilized within and for other specific implementations of the NGPCAS and / or the computing structure of the NGPCAS. In addition, as used herein, an "entity" that needs to be authenticated and / or authorized with respect to the NGPCAS 100 can be a user (such as a human user or automated user 155), a service or application (such as a containerized component, MEEE or particle 140, a service, subsystem or storage entity included in the software-defined application layer 412, a service included in the software-defined network layer or operating system 410, or a service included in the HCI adapter layer 430), a physical component (such as physical components 135, 138), a physical device (such as physical devices 105, 108), or another type of logical or physical entity associated with the NGPCAS 100. Typically, each entity is uniquely identified within the NGPCAS 100 by a unique name, identity, or identifier.

[0230] An example authentication and authorization framework / architecture associated with NGPCAS100 may include an authentication service, an authorization service, and an entity supervision service. In an example implementation, the authentication service, the authorization service, and the entity supervision service may be implemented at least in part within NGPCAS 100, such as through corresponding particles 140, corresponding enterprise-level computing functionality 355-360, and / or corresponding services 440. In addition, it should be noted that although the authentication service and the authorization service are discussed herein as separate and distinct services, in some cases, the authentication service and the authorization service may be implemented as a single integrated service that provides both authentication and authorization. In addition, although the authentication and authorization framework / architecture are generally referred to herein in the singular, this is merely for ease of reading and not limitation, as the authentication framework and the authorization framework may be implemented separately (rather than as a single integrated framework), or the authentication framework and the authorization framework may at least partially intersect. A more detailed description of the authentication framework and the authentication framework / architecture is provided elsewhere in this disclosure.

[0231] Generally speaking, within NGPCAS100, authentication of an entity by an authentication service determines or ascertains whether the entity is the party / object claimed by the entity, and authorization of an entity by an authorization service (e.g., to communicate with another entity, to access a source associated with another entity, etc.) determines whether the entity's request is allowed or denied. Authentication and authorization can be governed by policies, rules, security credentials, and / or other constraints, such as those specified via an entity management service and stored in one or more data storage entities included in the system 100 (e.g., data storage entity 413 and / or another suitable data storage entity). Each entity associated with NGPCAS100 (whether internal or external) can be authenticated and / or authorized. In fact, if a very high level of security is required within NGPCAS100, all entities associated with NGPCAS100 can be authenticated before being allowed to access NGPCAS100 or any portion thereof, and each authenticated entity associated with NGPCAS100 can be authorized each time it issues a request to communicate with another entity or access a resource of NGPCAS100.

[0232] To illustrate using an example scenario, consider a scenario in which a human user 155 wants to utilize a recipe editor provided by NGPCAS100 to create a batch recipe for manufacturing a drug. The human user 155 logs into the recipe editor (e.g., via a user interface application executed at a computing device utilized by the human user 155, an API 160 provided by the computing structure 102 of NGPCAS100) and provides the credentials of the human user, which may include multi-factor authentication credentials. In this example scenario, the authentication service authenticates the credentials of the human user (e.g., in response to the authentication service being called by the recipe editor or the API, accessing the recipe editor via the API within the computing structure 102). Upon successful authentication, a session corresponding to the authenticated human user 155 may be established, for example, by the recipe editor between the user interface and the recipe configuration server (which protects resources associated with the configuration recipe). In an example implementation, the authentication service may be a first service 440, and the recipe editor may be a second service 440 (e.g., a client service) provided by the application layer 412 of NGPCAS100, each of which may be accessed via its corresponding API (not shown), and the recipe configuration server may be a storage entity 413 provided by the application layer 412 of NGPCAS100, wherein the storage entity 413 may be accessed via its corresponding API (not shown). An authenticated human user 155 may utilize a session via a user interface to access one or more resources in the system 100, such as resources at the recipe configuration server and optionally other resources. In one embodiment, if different resources are stored in or accessed via a server of the system 100, all of the different resources may be accessed using the same session.

[0233] Subsequently, during the established session, the human user 155 requests (via the user interface and API 160) to open a recipe and, therefore, access specific resources (e.g., templates, blocks, functions, connectors, recipe drafts, etc.) provided by the recipe configuration server. Based on the human user's request, the recipe editor may call an authorization service to authorize the user's request. For example, the authorization service may authorize the human user 155 to access the resources associated with the "open recipe" request, where the authorization is based on two different sets of permissions: (i) permissions that have been granted (e.g., assigned to or mapped to) the human, and (ii) permissions associated with allowing access to (e.g., protecting) the requested resources. In some implementations, a security token corresponding to the human user's authentication may be verified during authorization of the human user to access the requested resources.

[0234] When the authorization service determines that the human user is allowed to access the requested resource (e.g., based on a comparison of the permissions associated with / assigned to the human user and the access permissions associated with / protecting the requested resource), human user 155 is granted access to the requested resource within the session, and when the authorization service determines that the human user is not allowed to access the requested resource, human user 155 is denied access to the requested resource within the session. Additionally, in this example scenario, during the established session, human user 155 requests a second resource provided by the recipe configuration server (e.g., to modify or delete the configuration of another recipe). Based on this second request for the second resource, the authorization service may authorize human user 155 to access the second resource, where the authorization is based on both the permissions associated with / assigned to the human user and the access permissions associated with / protecting the second resource. Furthermore, in this example scenario, during the established session, human user 155 requests a third resource provided by another server. Based on the third request for the third resource, the authorization service may authorize the human user 155 to access the third resource, wherein the authorization is based on both the permissions associated with / assigned to the human user and the access permissions associated with / protecting the third resource. Note that although the above example scenario describes the user interface as a first service, the recipe editor as a second service, and the requested resource is accessible via the recipe configuration server and another server, it should be understood that the described security techniques (e.g., authentication of the first entity, session establishment by the second entity, and authorization of the first entity to access one or more requested resources at one or more servers) may be utilized with respect to any entity and any resource of NGPCAS100.

[0235] As indicated above, within the example authentication and authorization framework, the authentication service authenticates the human user's access to various requested resources based on a comparison of the permissions associated with or assigned to the human user and the permissions associated with or protecting various resources. As used herein, the term "resource" generally refers to files, data, information, and / or content types stored in a database (e.g., one or more data repositories in data repository 413) supervised by NGPCAS100 and generated by an application or service (e.g., one or more application / services in application / services 435-438) included in NGPCAS, provided by NGPCAS, and / or otherwise associated with NGPCAS. Therefore, permissions associated with and / or protecting resources are generally referred to as "resource access permissions" or "access permissions" in this article. Resource access permissions generally govern other parties' access to resources (or parts thereof). On the other hand, permissions associated with and / or assigned to a human user (or for that matter, any requesting entity) are generally referred to as "role-based permissions" or "role permissions" in this article because such permissions can be based on or correspond to a role that has been assigned to the requesting entity. That is, within the authentication and authorization framework, each role can be assigned or mapped to a corresponding set of role-based permissions, which indicates the resources that the role is allowed to access within NGPCAS 100. Typically, role-based permissions and resource access rights are defined and / or assigned independently and asynchronously, for example, via an entity regulatory service of the authentication and authorization framework.

[0236] Typically, via the entity supervision service, each entity can be assigned to or mapped (e.g., via the entity supervision service) to one or more roles within the NGPCAS100. A "role," as used within the example authentication and authorization framework, typically refers to a set of actions, operations, and / or activities that the role is allowed to perform or execute relative to an application / service, a set of application services, a type of application service, and / or the entire NGPCAS100. An example of a role is "tuning" (e.g., it can be assigned to a human user or assigned to a service that is a reinforcement learning application), such that an entity assigned to the tuning role is allowed to perform tuning actions. Another example of a role is "controller" (e.g., it can be assigned to a physical controller, a virtual controller, or an MEEE), such that an entity assigned to the controller role is allowed to perform process control functions. The set of actions, operations, and / or activities that a role is allowed to perform or execute can be identified within the authentication and authorization framework, for example, by the corresponding API and / or unique identifier of the action, operation, and / or activity, because the action, operation, and / or activity itself can be implemented as a service, MEEE, granule, etc. within the NGPCAS100. Similarly, each entity assigned to or mapped to a role may be identified within the authentication and authorization framework by its corresponding identity (eg, as stored in the identity provider 548 or equivalent).

[0237] In addition, for a particular entity, a particular role may be restricted to a particular scope (e.g., via an entity regulatory service). "Scope," as used within the example authentication and certification framework, refers to a constraint or restriction that may be applied to a role, for example, on a per-entity or per-assignee basis. Examples of role scopes may include, for example, equipment, units, physical locations or sites, times of day, specific applications or services, enterprises, system performance standards (e.g., load, bandwidth, etc.), and / or other types of limitations and constraints that may vary between entities assigned to the role and / or may vary for different static and / or dynamic conditions of the NGPCAS 100. Thus, the scope of a particular role may be dynamic and / or static, as desired. In some cases, combinations of scopes may restrict a particular role in an "AND" or "OR" manner, as desired. Thus, continuing with the tuning role example above, a particular human user assigned to the tuning role may be assigned or mapped to a corresponding scope for tuning that limits their ability to tune within NGPCAS 100 (e.g., only for certain routines, analyses, and / or equipment, only at certain times of the day, only within certain threshold boundaries, etc.), and a particular reinforcement learning application assigned to the tuning role may be assigned or mapped to a corresponding scope that limits its tuning activities (e.g., to only in the background, as requested by a human user or an identified performance evaluation service, when executed at certain physical locations or on certain clusters, etc.). Role scopes may be implemented and / or defined in any desired and / or suitable manner, e.g., by data fields or metadata, by namespaces, etc.

[0238] To illustrate the concepts of entities, roles, scopes, and their permissions within the authentication and authorization framework, Figure 5A A block diagram depicting an example security technique 500 is provided. Figure 1 and Figure 2 This example security technique is utilized in NGPCAS and can be governed by the entity governance service of the authentication and authorization framework. Figure 5A The security technique 500 is depicted using an object model, however, it should be understood that this depiction is for illustration purposes only and is not intended to be limiting. Figure 5AAs shown, the enterprise 502 may define, specify, identify and / or allow one or more entities 505, each of which may be assigned or mapped 508 to one or more roles 510. Each role 510 may be assigned or mapped to a set of role-based permissions 512, wherein the set of role-based permissions 512 generally specifies a set of resources 515 (e.g., of NGPCAS100 and associated with the enterprise 502) that the role 510 is allowed to operate on. For example, continuing with the tuning role example above, the permissions 512 of the tuning role may indicate various resources (e.g., control routines, analysis routines, etc.) that are allowed to undergo tuning by the entity that has been assigned to the tuning role. In an example implementation, the set of role permissions 512 may be specified by reference to a corresponding API associated with a service (e.g., a client service) that protects the set of resources 515 that the role 510 is allowed to operate on. For example, the set of role-based permissions of the tuning role may indicate an API of the corresponding client service, via which the control routines, analysis routines, etc. are accessed. Such services through which resources are accessed may be implemented as, for example, containerized components, MEEEs, or particles 140; services, subsystems, or storage entities included in the software-defined application layer 412; services included in the software-defined network layer or operating system 410; or services included in the HCI adapter layer 430, each of which is accessible (e.g., can only be accessed) via its corresponding API within the NGPCAS 100. Of course, in other specific implementations, the set of role-based permissions 512 for a role 510 may be defined by other suitable techniques, in addition to or in lieu of APIs for services that reference resources that the role 510 is allowed or permitted to operate on, such as by specifying unique identities of resources within the role-based permissions or other techniques.

[0239] In addition, if Figure 5A As shown, the assignment 508 of an entity 505 to a role 510 may optionally include or be based on one or more role-based scopes 518, wherein the role-based scopes 518 may correspond to one or more static and / or dynamic conditions of or with the NGPCAS 100 that limit or restrict the access of the entity 505 to resources 515 in its assigned role 510. For example, the role-based scope 518 that assigns 508 a human user 505 to the Tune role 510 may limit the human user 505 to tuning the control routine only when the control routine is offline, only at certain physical locations, only at certain times of the day, etc.

[0240] While an entity's access to a resource can be governed through role-based permissions and, optionally, entity-based scopes, the resource itself can be protected (e.g., independently protected) through a corresponding set of access permissions. Access permissions can indicate a set of roles that are allowed or permitted to access the resource, and optionally can indicate a specific set of actions, operations, and / or activities that can be performed by each role on the resource (e.g., read, write, copy, open, save, subscribe, audit, etc.). Additionally, for some resources, access to various roles and / or the corresponding actions, operations, and / or activities that can be performed by the role on the resource can be restricted or scoped based on one or more static and / or dynamic conditions (and / or combinations thereof). In an example, an access permission for a batch recipe configuration can indicate a set of roles that are allowed to access the batch recipe configuration, and access to different roles within the allowed set of roles can be scoped or restricted based on, for example, the type of batch recipe, the stage of the batch recipe, the physical location of the data repository storing the batch recipe, etc. Scope-limiting a role's access to a resource can be implemented and / or defined in any desired and / or suitable manner, such as, for example, by data fields or metadata, by namespaces, etc. Therefore, if Figure 5A As shown, access to a resource 515 of the enterprise 502 (eg, via the resource's corresponding service and / or the service's corresponding API) may be governed by the resource's corresponding service based on a role 510 and by a scope 518 .

[0241] In one embodiment, the resources of system 100 and / or access to the resources may be protected in a hierarchical manner, such as in Figure 5B exemplified in the illustrated example security technique 530. Similar to Figure 5A , using the object model to describe Figure 5B The security technology 530 is shown, however it should be understood that this depiction is for illustration purposes only and is not intended to be limiting. Figure 5B As shown, resources 532 as previously discussed may include hardware and / or software resources, such as physical, virtual and / or logical components, clusters, nodes, services, applications, MEEE, etc. For example, resources 532 may include Figure 5AOne or more resources in the resources 515 shown. At the individual or single resource level, each individual resource 532 can be protected in a manner such as described above (e.g., based on its unique identity, using keys and certificates, etc.). At a higher level, resources can be grouped 535 (e.g., in a manner such as described above), and each resource group 535 can be guaranteed and protected as a group (e.g., by group identity, keys, certificates, etc.). Resource groups can be defined and / or created based on any category or grouping criteria, such as by location (e.g., locally on-site equipment, at a remote location, in a computing structure, etc.), by functionality, by characteristics, by time of day, etc. At a higher level, subscriptions 538 to various individual resources and / or to various resource groups can be utilized as a technology for implementing resource access rights, so that only roles (e.g., roles 510) that have subscribed to a specific resource or resource group can access the specific resource or resource group. That is, access to a specific resource 532 or resource group 535 can be limited to those roles that have a subscription 538 to it, thereby providing further security to NGPCAS100. Note that a single resource 532 can be included in one or more different resource groups 535 and / or accessed via one or more different subscriptions 538. Additionally, note that resource security techniques 530 can be applied locally at the location where the field device is located, non-locally at other physical locations, and / or within the computing fabric, as desired. Of course, other resource security techniques can additionally or alternatively be utilized within NGPCAS 100.

[0242] Figure 5C It is available in Figure 1 and Figure 2 NGPCAS is used in or by the NGPCAS and / or Figure 4 In one embodiment, the authentication architecture 545 may support Figure 5A and Figure 5B In addition, if desired, the authentication architecture 545 may be combined with Figure 5D The authentication framework or architecture 570 is implemented as an embodiment.

[0243] like Figure 5CAs shown, the authentication architecture 545 includes an identity provider 548, an authentication service 550, and an entity management service 552. Turning first to the identity provider 548, the identity provider 548 can store and provide the identity of the entity (which can be a unique identity) and the corresponding credentials of the identity within and / or associated with the NGPCAS 100. As previously discussed, entities can include users (such as human users and automated users 155), services or applications (such as containerized components, MEEEs or particles 140, services included in the software-defined application layer 412, subsystems or storage entities, services included in the software-defined network layer or operating system 410, services included in the HCI adapter layer 430, etc.), physical components (such as physical components 135, 138), physical devices (such as physical devices 105, 108), and other types of logical or physical entities included in or associated with the NGCPAS 100. In an embodiment, the identity provider 548 can be a multi-tenant identity provider. At least one of these tenants may be a system provider tenant 548a, for example, a tenant provided and controlled by the system provider of the NGPCAS 100. The system provider may, for example, provide the identities and credentials of non-human entities (e.g., applications, services, MEEEs, components, etc.) within the NGPCAS 100 or associated with the NGPCAS, as well as the identities and credentials and accounts of one or more human user entities associated with the system provider (such as an agent of the system provider). The system provider may allow an enterprise to create accounts for human users associated with the enterprise directly within the system provider tenant 548a, and / or the system provider may allow the enterprise to create accounts for human users associated with the enterprise within the enterprise-specific tenant 548b of the identity provider 548. In some specific implementations, the system provider may allow an enterprise to create accounts for human users associated with the enterprise via a third-party identity provider tenant 548c of the identity provider 548. For example, the configuration and supervision of the content (e.g., identities, credentials, accounts, etc.) of the identity provider 548 may be performed via the entity supervision service 552 of the authentication architecture 545. For example, a user may access the entity administration service 552 via a corresponding API and / or a front-end entity administration interface (not shown).

[0244] Turning now to authentication service 550, as previously discussed, applications, services, and / or other entities 558 may call authentication service 550 to handle authentication and authentication-related security credentials for applications 558. For example, authentication service 550 may authenticate an identity based on its corresponding security credentials stored in identity provider 548. To further enhance security, authentication service 550 may manage security tokens within NGPCAS 100, for example by providing a back-channel authentication process and a refresh authentication process. For example, in connection with the back-channel authentication process, application 558 may call or invoke authentication service 550 and provide authentication service 558 with an authorization code, a code verifier, and other such information for the purpose of generating a security token. Authentication service 558 may then generate a security token corresponding to application 558 and return the token to application 558. At some later time, application 558 may call or invoke authentication service 550 and provide authentication service 550 with a refresh token and / or other information to refresh the back-channel authentication process. Authentication service 550 may then refresh the back-channel authentication process and return a new token to application 558.

[0245] Additionally, the authentication framework 545 may include a token verification service 560 that operates to provide token verification functionality to entities of the NGPCAS 100. For example, when an application 558 is to establish a session with a candidate application (not shown) or otherwise communicate with the candidate application, before establishing the session or otherwise communicating with the candidate application, the application 558 may verify the token provided by the candidate application via the token verification service 560, and the session and / or communication between the application 558 and the candidate application may be established after or when the token verification service 560 determines that the token is a valid token.

[0246] In an embodiment, the identity provider 548, the authentication service 550, and the entity management service 552 of the authentication framework 545 may be implemented by: corresponding containerized components, MEEEs, or particles 140; services and / or subsystems included in the software-defined application layer 412; services included in the software-defined network layer or operating system 410; and / or services included in the HCI adapter layer 430. Each of the identity provider 548, the authentication service 550, and the entity management service 552 may be accessed (e.g., may only be accessed) via its corresponding API within the NGPCAS 100, for example, in a manner such as described above. In addition, in an embodiment, data repositories included in and / or associated with the authentication framework 545 (such as data repositories of various tenants of the identity provider 548, tokens, etc.) may be implemented by corresponding storage entities 413 at the software-defined application layer 412 and / or by software-defined storage devices 418 at the software-defined network layer / operating system 410 of the computing structure 400.

[0247] Figure 5D It is available in Figure 1 and Figure 2 NGPCAS is used in or by the NGPCAS and / or Figure 4 In one embodiment, the authorization architecture 570 may support Figure 5A and Figure 5B In addition, the authorization architecture 570 may be combined with Figure 5C The authentication framework or architecture 545 is implemented as an embodiment.

[0248] like Figure 5D As shown, the authorization architecture 570 includes an authorization service 572, an authorization database 575, and an entity management service 578. The entity management service 578 provides human users (e.g., agents of system providers, agents of enterprises, etc.) with the ability to create, define, manage, and manage roles, role-based permissions for various applications and services, entities assigned to roles, and any scopes that restrict the role and / or the entities assigned to the role. For example, users can access the entity management service 578 via a corresponding API and / or other front-end entity management interface 580. The entity management service 578 can have read and write access to the authorization database 575, where definitions and configurations of roles, role-based permissions, and scopes can be stored. If desired, the authorization database 575 can be a multi-tenant database.

[0249] The authorization service 572 can authorize an entity's request to access a resource, such as in the manner previously described. For example, an application or service 582 can call the authorization service 572 to authorize a request for a resource, such as in the manner previously described. In one example implementation, the authorization service 572 can authorize any entity (or its corresponding API) to perform operations, such as with respect to another entity (or its corresponding API), based on information stored in the authorization database 575. Typically, the authorization service 572 has read-only access to the information stored in the authorization database 575 to perform authorization functionality.

[0250] In an embodiment, the authorization service 572 and the entity supervision service 578 of the authorization framework 570 may be implemented by the following: corresponding containerized components, MEEEs or particles 140; services and / or subsystems included in the software-defined application layer 412; services included in the software-defined network layer or operating system 410; and / or services included in the HCI adapter layer 430. Each of the authorization service 572 and the entity supervision service 578 may be accessed (e.g., may only be accessed) via its corresponding API within the NGPCAS 100, for example, in a manner such as described above. In some specific implementations, the entity supervision service 578 of the authorization framework 570 and the entity supervision service 552 of the authentication framework 545 may be integrated services. In addition, in an embodiment, the authorization database 575 and / or other data repositories utilized by the authorization framework 570 may be implemented by the corresponding storage entity 413 at the software-defined application layer 412 and / or by the software-defined storage device 418 at the software-defined network layer / operating system 410 of the computing structure 400.

[0251] Additional architectural features of NGPCAS

[0252] Figure 6 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 can be implemented in the structural elements described herein. Specifically, Figure 6 As illustrated, chart 620 includes three columns, a rightmost column 622 including software, hardware, and firmware components associated with the NGPCAS listed in a hierarchical grouping view, a middle column 624 indicating the physical or virtual execution location of the associated elements in column 622, and a leftmost column 626 indicating the purpose or operation of the elements in column 622. Figure 6As illustrated, column 622 includes applications 630 that provide a customer or enterprise view of the NGPCA (as shown in column 626), wherein 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 for providing 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.

[0253] Additionally, if Figure 6As illustrated, NGPCAS includes a collection of application frameworks 640 that support and enable applications 630, in this case implemented in a cloud environment that serves as at least part of the computing fabric of the enterprise NGPCAS. Application frameworks 640 may include, for example, frameworks that provide, manage, and implement security, such as role-based security 641 for application and / or resource access, database access, configuration, and support 642 (such as an event and alarm database, a history log, an authentication data repository, an authorization data repository, etc.), a service mesh framework 643, a material support database 644, business or other rules 645 to be applied by applications 630, and a protocol support framework 646 that supports communication protocol usage and conversion. Rules 645 may, for example, define data governance and application execution rules in a specific implementation of NGPCAS 100 utilizing a computing fabric hub and communication spoke configuration to support multiple different physical locations that can use different data and execute governance rules. Of course, the frameworks 640 described herein are merely an example set of frameworks that may be used and supported in NGPCAS, and other frameworks may also or alternatively be included or used. Furthermore, while the frameworks 640 are configurable and accessible by the enterprise, these frameworks 640 are not directly user-facing, but rather support user-facing applications 630 .

[0254] 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 a computing fabric (as illustrated in column 624) to implement and support application framework 640 and application 630. Platform 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 rule storage and implementation platform (such as rule 645), a cost and subscription tracking platform, etc. Of course, Figure 6 The platform 650 listed or described herein 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.

[0255] In addition, if Figure 6 As illustrated, 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 6 As illustrated, cloud environment 660 (via VPN or other communication connections) provides a control plane, a data plane, and a management plane to edge devices 670, which are located locally in various physical locations, as illustrated in column 624. Edge devices 670 may include, for example, I / O or other servers 672, data, networking, and storage servers 674 (such as data aggregators and / or VPN gateways), and local workload servers 676, which may be connected to local hardware 680, such as local controllers, field devices, and other local hardware, as illustrated 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.

[0256] As will be understood, Figure 6 The hierarchical structure of illustrates 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 illustrated as a cloud environment) and at one or more physical locations or facilities. More specifically, Figure 6 Diagram 620 illustrates how user-facing applications (including control applications, maintenance applications, data storage and tracking applications, process control and configuration applications, management applications, workflow management applications, etc.) can be layered onto and incorporated into an NGPCAS operating in an execution environment.

[0257] Enterprise-level and provider features provided by NGPCAS

[0258] The next generation process control or automation system (NGPCAS) described in the present disclosure may be used to support various enterprise-level services and functionality, as well as enterprise-related services and functionality of providers of NGPCAS, such as those previously described. Figure 3BThe services and functionality discussed and / or other services and functionality. In general, enterprise-level services and functionality can be executed to support one or more industrial and / or automation processes implemented by each enterprise respectively. Each enterprise can implement one or more industrial and / or automation processes respectively, and each process is implemented between one, two, three, four or more physical locations or sites. At a very high level, various enterprise-level services and functionality can support the execution of the processes themselves implemented by the enterprise (e.g., system configuration, control, operation, maintenance, data storage and management, etc.), support the execution of basic services used as functional building blocks of the computing structure (e.g., creating and relocating containerized services), and support the management of the NGPCAS architecture and service / application framework by the system provider of the NGPCAS architecture (e.g., through computing structure monitoring, physical layer resource allocation and monitoring, containerized service management, application distribution and upgrade management, etc.). Enterprise-level services and functionality (also referred to herein as "applications") may be executed at least partially (and in some cases completely) within the computing structure of the NGPCAS architecture of the present disclosure (e.g., the NGPCAS architecture as described with respect to the aforementioned figures, e.g., the services / applications herein are implemented as software modules within the application layer of the NGPCAS computing structure). Generally speaking, provider services and functionality may be executed to support the operation of the NGPCAS (and the processes involved therein) for one, two, three, four, or more enterprises.

[0259] When executing any one or more services / applications on behalf of an enterprise or provider, the computing structure may be communicatively connected to a pool of physical process equipment in one or more physical locations via one or more transport networks as described herein. The transport network may, for example, include one or more point-to-point, peer-to-peer, and / or point-to-multipoint connections (such as VPNs) to securely connect any containerized software component to another containerized component and / or a specific physical component to exchange information required by the service / application (e.g., real-time and / or historical process data, physical site or process configuration information, site personnel information, etc.). Human users may interact with the service / application via one or more client computing devices (e.g., laptops, tablets, mobile computing devices, etc.) using a secure communication connection with the portion of the computing structure that implements the service / application. The communication connection may, for example, utilize a VPN, and execution of the service / application at the client device may include executing a specific containerized component of the computing structure that has been configured and authorized to run the service / application at the client device. Therefore, without further repetition of the description of NGPCAS as provided in the preceding sections of this disclosure, it should be understood that the execution of the services / applications described in that section may utilize any suitable one of the structures, features, and functionality of NGPCAS previously described in this disclosure (e.g., containerized services, digital twins, VPN and / or other communication / security features, user identity / access security features, authentication features, authorization features, process hardware security features, etc.).

[0260] Real-time control, operation, monitoring and supervision features

[0261] The services / applications supported by NGPCAS may include, at a high level, various services / applications that support real-time control, operation, and / or monitoring of one or more physical sites operated by an enterprise (each having the enterprise's physical equipment), one or more NGPCAS of the enterprise, or the entire enterprise (e.g., including multiple physical sites and / or multiple NGPCAS). While some of these services / applications support automatic control / operation / monitoring of physical sites (e.g., without intervention by a human user), the various services / functionalities described herein may also include exposing selected information to one or more human users (e.g., via a dashboard) and / or receiving commands from one or more human users to further support the control / operation / monitoring of physical sites. The term "enterprise user" will be used herein to refer to a human user in an enterprise that has purchased NGPCAS resources / capabilities from a system provider of NGPCAS. As used herein, "provider" or "administrator" may refer to a human user who may have exclusive access to certain services or applications associated with the management / supervision of NGPCAS of multiple enterprises. It should be understood that access by an enterprise user or provider to these services / functionality may be subject to various authentication / authorization controls for the enterprise user or provider and for the client computing device used by the enterprise user or provider to access the service / functionality. Generally speaking, an enterprise user will typically have access to services / functionality associated with the enterprise to which the user belongs, while a provider / administrator user may have access to services or applications associated with many NGPCAS or enterprises. An enterprise user and a provider / administrator user may have different permissions to access, view and / or manipulate data at different times, with each of the enterprise user and provider / administrator user permissions being defined based on policies that may be defined by the enterprise, the system provider, or some combination thereof.

[0262] Client devices may access these services / functionality via the computing structure from any location (e.g., from within the physical site to which the services / functionality resides, from within another physical site operated by the enterprise, from another physical location that is agnostic to any particular physical site (e.g., a home office or remote service center that serves one, two, three, or more sites simultaneously), or otherwise from various remote locations (e.g., mobile devices).

[0263] Computing fabric-based control, operation, and maintenance services / functionality contemplated herein include, but are not necessarily limited to:

[0264] - Enterprise-level viewing functionality for allowing enterprise users to navigate and view (and in some cases, modify) real-time representations of site areas, sites, and / or sub-sites operated by the enterprise;

[0265] - Site-level viewing functionality for allowing a user to navigate and view real-time representations of process entities operating in any one or more specific sites (e.g., a hierarchical view of physical process equipment, control loops, I / O networks, etc.), where, in some embodiments, the real-time representations of process entities include real-time operational information associated with the process entities (e.g., setpoints, parameters, observed process variables, events, alarms, control inputs / outputs, diagnostics, production output quantities, quality metrics, etc.), and / or enable modification of the operation of the process entities (e.g., responding to events or alarms, activating or shutting down a process or specific equipment involved therein, modifying control behavior, etc.);

[0266] - simulation and / or testing functionality for simulating the operation of any particular site (e.g., the operation of a process performed at that site) and providing a view of the simulated operation and / or its results (e.g., simulated set points, process variables, events, alarms, control inputs / outputs, process inputs / outputs, etc.);

[0267] - Personnel viewing and / or management functionality for viewing, creating and / or modifying information associated with personnel associated with one, two, three, four or more sites (e.g., for viewing, adding and / or removing authorizations and / or task assignments for process engineers, operators, maintenance personnel, etc.);

[0268] - Personnel shift assistance functionality for providing real-time information, task assignments, and / or instructions to client devices of personnel (e.g., process engineers, operators, maintenance personnel, etc.) associated with the operation of process entities in at least a portion of one or more sites for which the personnel are responsible (e.g., a site at which the personnel is located or a site remote from where the personnel is located);

[0269] - Process configuration template functionality for allowing a user to create, define, store, modify and / or push through an enterprise a library of template objects representing process entities (e.g., field devices, controllers, I / O devices, data storage devices, etc.), which template objects may thereafter be used to define instances of process entities installed and / or operated in one, two, three, four, or more physical sites operated by the enterprise (e.g., to import, copy and / or reuse various templates enterprise-wide in various process display interfaces, operator interfaces, etc.);

[0270] - Enterprise-level standards management functionality for allowing users to define fonts, naming standards, configuration practices, graphics, and / or other standards for use on part or all of an enterprise NGPCAS, and to push standards across part or all of the enterprise NGPCAS to modify enterprise functionality to utilize the defined standards;

[0271] - Process entity configuration functionality for defining any particular process entity installed or operating in any particular physical site (e.g., by importing the entity from a template object library or from another site and defining various parameters of the entity, such as device name, device tag, set points, data input / output, process material input / output, event behavior, alarm conditions, etc.);

[0272] - Site-level configuration functionality, used to define the relative arrangement of two or more process entities installed or operating in any particular physical site (e.g., forming a control loop, the flow or exchange of process materials between two or more pieces of process equipment, etc.);

[0273] - Control algorithm configuration functionality for defining parameters of a control loop or other control function (e.g., defining one or more inputs to a control algorithm, one or more outputs of a control algorithm, one or more mathematical functions included in a control algorithm, etc.);

[0274] - Process display creation functionality for creating and / or modifying process displays to be used by process technicians (e.g., operators, engineers, maintenance personnel) to view real-time information associated with the operation of one or more process entities in a single physical site or in two, three, four, or more physical sites simultaneously operated by an enterprise (e.g., to view operating parameters, diagnostics, alarms, events, etc.);

[0275] - Enterprise-level diagnostic functionality for providing a real-time view of high-level diagnostics of two or more physical sites operated by an enterprise (e.g., indicating whether processes at each site are online, whether the site network is in a normal operating state, etc.);

[0276] - Site-level diagnostic functionality for providing a real-time view of diagnostic information (e.g., operating parameters, events, alarms, data logs, etc.) associated with process entities in the site and / or enabling a user to take action in response to the provided diagnostic information;

[0277] - Site comparison functionality that enables a user to compare the configuration and performance parameters of two or more sites of an enterprise (e.g., compare the operation of similar process equipment in multiple sites to determine whether differences in site configuration can be correlated to different performance parameters observed at the multiple sites);

[0278] - Data governance functionality for allowing users to define data management policies (e.g., defining data storage, retention, distribution, access requirements for personnel, etc.) for part or all of an enterprise NGPCAS at a corresponding physical site or across multiple sites;

[0279] - Entity administration functionality to allow automated or human users to create, define, modify, administer, and manage authentication and authorization accounts, identities, security credentials, roles, role assignments (e.g., the assignment or mapping of identities to roles, or specifications thereof), scopes (e.g., the assignment or mapping of scopes of access that limit or restrict identities and / or roles, or specifications thereof), and / or the assignment or mapping of scopes of access allowed to resources, or specifications thereof), role-based permissions (e.g., the assignment or mapping of roles to corresponding role-based permissions, or specifications thereof), resource access permissions (e.g., the mapping of resources to roles that are allowed to access the resources, or specifications thereof); and / or

[0280] -As for Figure 4 Any other functionality or functionalities of the control services 435, subsystems 438, and other services 440 of the application layer 412 of the computing structure 400, and / or any other enterprise-level or provider-oriented control, operation, and / or monitoring functionality described in the present disclosure, which may be executed in real time during runtime and / or in an offline or asynchronous manner relative to runtime operations.

[0281] Other considerations

[0282] When implemented in software, any application, module, etc. described herein may be stored, for example, as a set of computer-executable instructions in any one or more tangible, non-transitory computer-readable memories, such as on a magnetic disk, a laser disk, a solid-state memory device, a molecular memory storage device, or other storage medium, in the RAM or ROM of a computer or processor, etc. Additionally, the set of computer-executable instructions may be executed by one or more processors of the system. Furthermore, while the example systems disclosed herein are disclosed as including software and / or firmware and other components executed on hardware, it should be noted that such systems are merely illustrative and should not be considered limiting. For example, it is contemplated that any or all of these hardware, software, and firmware components may be embodied exclusively in hardware, exclusively in software, or in any combination of hardware and software. Thus, while the example systems described herein are described as being implemented in software executed on processors of one or more computer devices, a person of ordinary skill in the art will readily appreciate that the examples provided are not the only way to implement such systems.

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

[0284] The specific features, structures and / or characteristics of any particular embodiment can be combined with one and / or more other embodiments in any suitable manner and / or in any suitable combination, including using selected features and using or not using other features accordingly. In addition, many modifications can be made to adapt specific applications, situations and / or materials to the basic scope or essence of the application. It should be understood that other variations and / or modifications of the embodiments of the application described and / or illustrated herein are possible, and should be considered as part of the essence or scope of the application, according to the teachings herein. Some aspects of the application are described in this article as the following example aspects.

[0285] 1. A system for authorizing an entity to access resources in a process control or automation system, the system comprising: an authorization database storing an indication of a respective set of role permissions for each of a plurality of roles in the process control or automation system; and an authorization service for the process control or automation system. The authorization service comprises a set of computer-executable instructions stored on one or more computer-readable media, which, when executed by one or more processors, cause the system to, upon an entity's request for access to a resource of the process control or automation system, perform the following operations: determine a role of the requesting entity and access the authorization database to determine a set of role permissions for the role of the requesting entity. When the set of role permissions and a set of resource access permissions for the resource are consistent, grant the requesting entity access to the resource, and when the set of role permissions and the set of resource access permissions are inconsistent, deny the requesting entity access to the resource.

[0286] 2. The system of the preceding aspects, wherein the requesting entity is one of: a human user, a physical or virtual device associated with the process control or automation system, a service provided by the process control or automation system, a service provided by a third party, an application provided by the process control or automation system, an application provided by the third party, a physical component of the process control or automation system, a virtual or logical component of the process control or automation system, or a microencapsulated execution environment (MEEE).

[0287] 3. A system according to the previous aspect, wherein at least one of the following is true: the physical or virtual device is a field device, a process control device or a safety instrument device; or at least one of the following is implemented using the corresponding MEEE: the service provided by the process control or automation system, the service provided by the third party, the application provided by the process control or automation system, the application provided by the third party or the virtual or logical component of the process control or automation system.

[0288] 4. A system according to any one of the preceding aspects, wherein the authorization service compares the set of role permissions corresponding to the requesting entity with the set of resource access permissions corresponding to the resource, and grants or denies the requesting entity's access to the resource based on the comparison.

[0289] 5. A system according to any one of the preceding aspects, wherein the resource or the client service through which the resource is accessed compares the set of role permissions corresponding to the requesting entity with the set of resource access permissions corresponding to the resource, and grants or denies the requesting entity's access to the resource based on the comparison.

[0290] 6. The system according to any of the preceding aspects, wherein the set of resource access rights for the resource indicates at least one of: a subset of the plurality of roles that are the only roles allowed to access the resource, or a scope of access to the resource.

[0291] 7. A system according to any of the preceding aspects, wherein at least some of the multiple roles are respectively restricted to accessing the resource based on one or more corresponding access scopes, and the one or more corresponding access scopes include at least one of the following: equipment, unit, physical location, time of day, time interval or another constraint.

[0292] 8. A system according to any of the preceding aspects, wherein: the authorization service has read-only access to the authorization database; the entity supervision service has read and write access to the authorization database; and the entity supervision service is called by an agent of the process control or automation system to define at least one of the following: a mapping of the resource to the unique role that is allowed to access the resource, and the corresponding access scope of at least some of the multiple roles to the resource.

[0293] 9. The system according to the previous aspect, wherein at least one of the following is true: the entity management service is called via a corresponding application programming interface (API); or the entity management service is implemented via a corresponding micro-encapsulated execution environment (MEEE).

[0294] 10. The system according to any one of the preceding aspects, wherein:

[0295] The authorization database further stores an indication of a respective set of roles for each of a plurality of entities of the process control or automation system;

[0296] The requesting entity is included in the plurality of entities;

[0297] The plurality of entities include two or more of: a human user, a physical or virtual device associated with the process control or automation system, a service provided by the process control or automation system, a service provided by a third party, an application provided by the process control or automation system, an application provided by the third party, a physical component of the process control or automation system, a virtual or logical component of the process control or automation system, or a micro-encapsulated execution environment (MEEE); and

[0298] The accessing of the authorization database is further used to determine the corresponding set of roles for the requesting entity, the corresponding set of roles for the requesting entity including the role of the requesting entity.

[0299] 11. A system according to the previous aspect, wherein: the authorization service has read-only access to the authorization database; the entity supervision service has read and write access to the authorization database; and the entity supervision service is called by an agent of the process control or automation system via a corresponding application programming interface (API) to perform at least one of the following: defining at least one role included in the multiple roles; defining a mapping of each role to the corresponding set of role permissions; defining a mapping of each entity to a corresponding set of roles in the multiple roles; or defining corresponding access scopes of one or more roles to one or more resources.

[0300] 12. The system according to the preceding aspect, wherein the entity management service is invoked via a corresponding application programming interface (API) and implemented via a corresponding micro-encapsulated execution environment (MEEE).

[0301] 13. A system according to any one of the preceding aspects, wherein the system further includes a session, wherein the session is established by a client service between the requesting entity and a second service corresponding to the resource, and the resource is accessed via the session; and wherein the request of the requesting entity to access the resource is received by the client service, and after receiving the request of the requesting entity, the authorization service is called within the session.

[0302] 14. A system according to any one of the preceding aspects, wherein at least one of the following is true: at least one of the client service, the authorization service, or the second service corresponding to the resource is accessed or called via a corresponding application programming interface (API); or at least one of the client service, the authorization service, or the second service corresponding to the resource is implemented via a corresponding microencapsulated execution environment (MEEE).

[0303] 15. A system according to any one of the preceding aspects, wherein: the client service is accessed by the requesting entity via the corresponding API of the client service; the second service corresponding to the resource is accessed by the requesting entity via the corresponding API of the second service within the session; the authorization service is called via the corresponding API of the authorization service within the session; and the authorization service, the client service and the second service are implemented via a corresponding microencapsulated execution environment (MEEE).

[0304] 16. A system according to any of the preceding aspects, wherein within the session: the authorization service provides an indication of the set of role permissions for the role of the requesting entity; and grants or denies the requesting entity's access to the resource based on a comparison of the set of role permissions corresponding to the requesting entity with the set of resource access permissions corresponding to the resource.

[0305] 17. A system according to any one of the preceding aspects, wherein the system further includes an authentication service, which authenticates the identity of an entity to the process control or automation system; and wherein when the requesting entity initially accesses the client service via a corresponding application programming interface (API): the client service calls the authentication service to authenticate the identity of the requesting entity; and after the authentication service successfully authenticates the requester, the client service establishes the session between the requesting entity and the second service.

[0306] 18. The system according to the preceding aspect, wherein:

[0307] The requesting entity is one of: a human user, a physical or virtual device associated with the process control or automation system, a service provided by the process control or automation system, a service provided by a third party, an application provided by the process control or automation system, an application provided by the third party, a physical component of the process control or automation system, a virtual or logical component of the process control or automation system, or a micro encapsulated execution environment (MEEE); and

[0308] At least one of the following is true: the authentication service is called via a corresponding application programming interface (API); or the authentication service is implemented via a corresponding MEEE.

[0309] 19. A system according to any one of the preceding aspects, wherein: upon successful authentication of the identity of the requesting entity, the authentication service generates a token corresponding to the requesting entity and the client service; and further grants or denies the requesting entity's access to the resource based on the validity of the token within the session.

[0310] 20. According to any one of the preceding aspects, the system further includes a token verification service for determining the validity of the token, and at least one of the following is true: the token verification service is called via a corresponding application programming interface (API); or the token verification service is implemented via a corresponding microencapsulated execution environment (MEEE).

[0311] 21. A system according to any one of the preceding aspects, wherein the system further includes a multi-tenant identity provider, and wherein: the authentication service authenticates the identities of at least a first part of the devices, services, applications and multiple users of the process control or automation system based on a first tenant of the multi-tenant identity provider; and the authentication service authenticates the identities of at least a second part of the multiple users of the process control or automation system based on a second tenant of the multi-tenant identity provider.

[0312] 22. Any one of the preceding aspects in combination with any other one of the preceding aspects.

Claims

1. A system for authorizing an entity to access resources in a process control or automation system, the system comprising: an authorization database storing an indication of a respective set of role permissions for each of a plurality of roles of the process control or automation system; and An authorization service for the process control or automation system, the authorization service comprising a set of computer-executable instructions stored on one or more computer-readable media, the set of computer-executable instructions, when executed by one or more processors, causing the system to perform the following operations based on a request by an entity to access a resource of the process control or automation system: determining a role of the requesting entity and accessing the authorization database to determine a set of role permissions for the role of the requesting entity; When the set of role permissions and the set of resource access permissions of the resource are consistent, granting the requesting entity access to the resource; and When the set of role permissions and the set of resource access permissions are inconsistent, the requesting entity is denied access to the resource.

2. The system of claim 1 , wherein the requesting entity is one of: a human user, a physical or virtual device associated with the process control or automation system, a service provided by the process control or automation system, a service provided by a third party, an application provided by the process control or automation system, an application provided by the third party, a physical component of the process control or automation system, a virtual or logical component of the process control or automation system, or a micro encapsulated execution environment (MEEE).

3. The system of claim 2, wherein at least one of the following is true: The physical or virtual device is a field device, process control device, or safety instrumented device; or At least one of the following is implemented using the corresponding MEEE: the service provided by the process control or automation system, the service provided by the third party, the application provided by the process control or automation system, the application provided by the third party, or the virtual or logical component of the process control or automation system.

4. A system according to any one of the preceding claims, wherein the authorization service compares the set of role permissions corresponding to the requesting entity with the set of resource access permissions corresponding to the resource, and grants or denies the requesting entity's access to the resource based on the comparison.

5. A system according to any one of the preceding claims, wherein the resource or the client service through which the resource is accessed compares the set of role permissions corresponding to the requesting entity with the set of resource access permissions corresponding to the resource, and grants or denies the access to the resource by the requesting entity based on the comparison.

6. A system according to any of the preceding claims, wherein at least some of the multiple roles are respectively restricted to accessing the resource based on corresponding one or more access scopes, and the corresponding one or more access scopes include at least one of the following: equipment, unit, physical location, time of day, time interval or another constraint.

7. A system according to any one of the preceding claims, wherein the set of resource access rights for the resource indicates at least one of: (i) a subset of the multiple roles that are the only roles allowed to access the resource, or (ii) a scope of access to the resource.

8. The system of claim 7, wherein: The authorization service has read-only permission to the authorization database; The entity administration service has read and write access to the authorization database; and The entity administration service is invoked by an agent of the process control or automation system to define at least one of: a mapping of the resources to the unique roles allowed to access the resources, and respective access scopes to the resources for at least some of the plurality of roles.

9. The system of claim 8, wherein at least one of the following is true: The entity supervision service is invoked via a corresponding application programming interface (API); or The entity management service is implemented via a corresponding micro-encapsulated execution environment (MEEE).

10. A system according to any one of the preceding claims, wherein: The authorization database further stores an indication of a respective set of roles for each of a plurality of entities of the process control or automation system; The requesting entity is included in the plurality of entities; The plurality of entities include two or more of: a human user, a physical or virtual device associated with the process control or automation system, a service provided by the process control or automation system, a service provided by a third party, an application provided by the process control or automation system, an application provided by the third party, a physical component of the process control or automation system, a virtual or logical component of the process control or automation system, or a micro-encapsulated execution environment (MEEE); and The accessing of the authorization database is further used to determine the corresponding set of roles for the requesting entity, the corresponding set of roles for the requesting entity including the role of the requesting entity.

11. The system of claim 10, wherein: The authorization service has read-only permission to the authorization database; The entity administration service has read and write access to the authorization database; and The entity supervision service is called by an agent of the process control or automation system via a corresponding application programming interface (API) to perform at least one of the following: defining at least one role included in the plurality of roles; Defining a mapping of each role to the corresponding set of role permissions; defining a mapping of each of the entities to a corresponding set of roles in the plurality of roles; or Define the corresponding access scope of one or more roles to one or more resources.

12. The system according to claim 11, wherein the entity management service is called via a corresponding application programming interface (API) and is implemented via a corresponding micro-encapsulated execution environment (MEEE).

13. The system according to any one of the preceding claims, The system further includes a session established by a client service between the requesting entity and a second service corresponding to the resource, and the resource is accessed via the session; and The request by the requesting entity to access the resource is received by the client service, and after receiving the request by the requesting entity, the authorization service is invoked within the session.

14. The system of claim 13, wherein at least one of the following is true: At least one of the client service, the authorization service, or the second service corresponding to the resource is accessed or called via a corresponding application programming interface (API); or At least one of the client service, the authorization service, or the second service corresponding to the resource is implemented via a corresponding micro encapsulated execution environment (MEEE).

15. The system according to any one of claims 13 to 14, wherein: The client service is accessed by the requesting entity via the corresponding API of the client service; The second service corresponding to the resource is accessed by the requesting entity via the corresponding API of the second service within the session; The authorization service is called within the session via the corresponding API of the authorization service; and The authorization service, the client service, and the second service are implemented via corresponding micro encapsulated execution environments (MEEEs).

16. The system according to any one of claims 13 to 15, wherein within the session: The authorization service provides an indication of the set of role permissions for the role of the requesting entity; and The access to the resource by the requesting entity is granted or denied based on a comparison of the set of role permissions corresponding to the requesting entity and the set of resource access permissions corresponding to the resource.

17. The system of any one of claims 13 to 16, further comprising an authentication service that authenticates an entity's identity to the process control or automation system; and wherein when the requesting entity initially accesses the client service via a corresponding application programming interface (API): The client service calls the authentication service to authenticate the identity of the requesting entity; and After the authentication service successfully authenticates the requester, the client service establishes the session between the requesting entity and the second service.

18. The system of claim 17, wherein: The requesting entity is one of: a human user, a physical or virtual device associated with the process control or automation system, a service provided by the process control or automation system, a service provided by a third party, an application provided by the process control or automation system, an application provided by the third party, a physical component of the process control or automation system, a virtual or logical component of the process control or automation system, or a micro encapsulated execution environment (MEEE); and At least one of the following is true: the authentication service is called via a corresponding application programming interface (API); or the authentication service is implemented via a corresponding MEEE.

19. The system according to any one of claims 17 to 18, wherein: Upon successful authentication of the identity of the requesting entity, the authentication service generates a token corresponding to the requesting entity and the client service; and The access to the resource by the requesting entity is granted or denied further based on the validity of the token within the session.

20. The system of claim 19, further comprising a token validation service for determining the validity of the token, and at least one of the following holds true: The token verification service is called via a corresponding application programming interface (API); or The token verification service is implemented via a corresponding micro-encapsulated execution environment (MEEE).

21. The system of any one of claims 17 to 20, further comprising a multi-tenant identity provider, and wherein: The authentication service authenticates at least a first portion of identities of devices, services, applications, and a plurality of users of the process control or automation system based on a first tenant of the multi-tenant identity provider; and The authentication service authenticates identities of at least a second portion of the plurality of users of the process control or automation system based on a second tenant of the multi-tenant identity provider.

22. Any one of the preceding aspects in combination with any other one of the preceding aspects.

Images