Enterprise engineering and configuration framework for advanced process control and monitoring systems

Abstract

An enterprise engineering and configuration system includes a common configuration database and a support service stored in and executed in a computing structure of an enterprise. The configuration database and support services use and implement a common configuration data schema to support the configuration of hardware and software in the computing fabric and at multiple different sites or physical locations of the enterprise, even when different control and automation systems are used at these different sites or physical locations. The configuration system enables hardware or software configuration changes to various different sites or locations of an enterprise to be implemented centrally or locally from a configuration device directly connected to the computing structure of the enterprise or from any physical location or site of the enterprise, a single integrated enterprise configuration database storing configuration data for each of a plurality of sites of the enterprise is simultaneously maintained. The configuration system is flexible because it enables a user to make engineering and configuration changes anywhere in the enterprise for any site of the enterprise and across different sites of the enterprise.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Provisional Patent Application Serial No. 63 / 417,861, filed on October 20, 2022, entitled “Configuration Features of NextGeneration Process Control and Automation Systems,” and U.S. Provisional Patent Application Serial No. 63 / 418,006, filed on October 20, 2022, entitled “Enterprise-Level Features Provided by the NGPCAS,” and is a continuation-in-part of U.S. Patent Application Serial No. 18 / 223,416, filed on July 18, 2023, entitled “Monitoring and Operational Functionalities for an Enterprise Using Process Control or Automation System,” the entire disclosure of each of which is hereby expressly incorporated herein by reference. Technical Field

[0003] The present application relates generally to industrial process control systems and automation systems for industrial process plants, and particularly to a framework for performing enterprise engineering and configuration activities in a next generation architecture for industrial process control and automation systems. Background Art

[0004] For decades, distributed process control systems and automation systems of various enterprises (such as distributed or scalable process control and / or automation systems used in power generation, chemical, petroleum, or other industrial processes such as pharmaceutical or other types of manufacturing) have typically included one or more sites (physical locations) at which one or more dedicated process controller devices 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] Generally speaking, each different site of an enterprise is considered a separate process control or automation system that is managed separately. In each system, field devices perform functions within a specific process or plant, such as opening or closing valves, connecting and disconnecting equipment, and measuring process parameters. Example field devices include valves, valve positioners, switches, and transmitters (e.g., devices that include: sensors for measuring temperature, pressure, or flow rate; and transmitters for transmitting the sensed temperature, pressure, and flow rate). In many industrial processes, there may be hundreds, thousands, or even tens of thousands of field devices operating to send data to and / or receive commands from one or more dedicated controller devices.

[0006] A process controller, typically located within a plant environment (i.e., within the physical 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 smart 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 for 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 segment model for industrial control systems that helps conceptualize and organize the concepts of industrial process architecture, particularly the security of various 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), zone 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 can be protected from threats originating from the 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. However, again, these systems are organized on a site-by-site basis, making it difficult for an enterprise (e.g., a particular company) with multiple different sites (e.g., multiple different processing or automation plants at different physical locations) to have an integrated and comprehensive data collection and configuration manipulation system covering the multiple different sites.

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

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

[0017] U.S. patent application serial number 18 / 233,416, filed on July 18, 2023, the disclosure of which is incorporated herein by reference in its entirety, describes a new process plant and industrial control and / or automation system architecture that enables a large amount of computer processing and IT infrastructure (referred to herein as a compute fabric) used to support a process plant, industrial control facility, or other automation facility to be implemented in a shared, off-site, and / or virtualized manner, which alleviates many of the communication and security issues that exist in current process and industrial control systems that attempt to implement control using shared or virtualized computing resources (such as cloud-based computing or system resources). Specifically, this new control system (which can be used to implement control, monitoring, and configuration activities in any process plant or industrial manufacturing or automation facility) does not attempt to follow the well-known, commonly followed, and recognized Purdue model when integrating and providing communications between plant devices (such as field devices), equipment controllers, supervisory controllers, site business operations, and enterprise operations. Thus, when supporting control functions associated with a process plant or industrial automation facility, the system architecture is able to implement control functions, communications, and security measures in a more efficient manner that effectively uses communication and security features developed for general computing uses outside of a process plant environment.

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

[0019] 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 at one or more sites. 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 new control system architecture also includes a network layer that is positioned between the physical layer and the application layer and provides supervision, management, and use of physical layer resources and logical (e.g., software-based) resources once required by application layer activities, and specifically supports timing and other requirements that are specific to and required for industrial process control and automation.

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

[0021] A pool of physical devices may include devices that perform physical functions used to control industrial or automated processes implemented at various different sites, such as locations 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 (i.e., sites), or may be located entirely or solely at a single physical location or environment (i.e., a single site).

[0022] During operation, the computing structure can use one or more transmission networks to communicate with a pool of physical equipment located at one or more physical locations. The transmission network can use any desired communication infrastructure and communication protocol, including any desired wired and / or wireless communication equipment / protocol. Such protocols can be any of a variety of process control protocols, such as HART, WirelessHART, Foundation Fieldbus, Profibus, OPC UA, and / or can be any of a variety of general-purpose computing communication protocols. For example, the transmission network can use any IP-based or packet-based protocol, including protocols that utilize publish and subscribe protocols such as MQ Telemetry Transport (MQTT) and Advanced Message Queuing Protocol (AMQP). In addition, the transmission network can use or include any desired communication network physical layer, such as Ethernet, 802.11, Advanced Physical Layer (APL), and other physical layers. In this way, the physical device pool can send data or information to one or more configuration containers in the computing structure in packet form via one or more transmission networks and can receive data or information from them, so that the computing structure can implement process control, monitoring, and configuration activities regarding the physical device pool. Furthermore, 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 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.

[0023] The computing structure may be implemented on a scalable hardware platform, portions of which may be physically located across one or more physical locations, which may or may not be the same physical locations associated with the physical device pools. Thus, at least a portion of the computing structure 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.

[0024] 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 legacy 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 legacy architecture, the control architecture utilizes only a collection of containerized components executing in a compute fabric 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 might be possible with the legacy architecture.

[0025] 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 standby, 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.

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

[0027] 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. In addition, 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).

[0028] Advantageously, such an architecture uses a computing fabric to abstract (e.g., disconnect) 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 dynamically respond to configuration changes and the needs of higher-level software-defined services, subsystems, and other software components of the application layer.

[0029] As will be appreciated, this new process control and monitoring system enables enterprises, such as pharmaceutical manufacturing companies, oil refineries, and the like, to set up, control, and monitor processes at various sites (e.g., physical locations or physical zones located at any desired geographic location) using computing infrastructure located in a computing structure and using physical devices (e.g., control devices such as controllers and field devices) located at physical locations. Because each physical site is connected to the computing structure, the enterprise has access to all of its assets via the computing structure and can view, control, and manage these assets from any geographic location and using any desired computing device (e.g., a business computer, laptop, phone, etc.) via the computing structure.

[0030] However, in order to provide great flexibility in such process control and monitoring systems, it is important to be able to configure (i.e., set up) various different enterprise components, especially those located at different physical sites of the enterprise, both from an enterprise configuration device or computer directly connected to the computing structure and from an enterprise configuration device or computer located at various physical locations or sites. However, such a dual-mode configuration can be difficult to implement because it requires tracking and updating configuration changes made to devices or systems at the enterprise's physical locations, regardless of whether the changes are made by users at the physical locations or by users accessing the physical locations via the computing structure. Furthermore, because different types of control systems (e.g., different types of process control devices, process control system hardware, and process control communication systems) can be located in and used at different physical locations of the same enterprise, it can be difficult to manage the configuration of each different physical location (or a subset thereof) because the underlying hardware / software models used at each physical location may be completely different, requiring the configuration system to understand and support multiple different configuration data schemas. Summary of the Invention

[0031] The enterprise engineering and configuration system described herein enables engineering and configuration activities (such as implementing hardware or software configuration changes) to be performed centrally from configuration devices directly connected to an enterprise's computing fabric, or locally at any physical location or site of the enterprise using configuration devices connected to or located at a physical location, while maintaining a single, integrated configuration database that stores configuration data for each of the enterprise's multiple sites. This dual-mode configuration system is flexible because it enables users to perform engineering and configuration changes for any site of the enterprise from anywhere in the enterprise. More specifically, the engineering and configuration system described herein includes a common configuration database located within the computing fabric that accepts and manages configuration changes associated with multiple different physical locations or sites, thereby making configuration data for the entire enterprise available to any authorized user. Furthermore, the configuration data in the configuration database is integrated in such a way that configuration data from different physical locations can be accessed, viewed, and changed together. The configuration system described herein may use a common configuration framework for the configuration data, wherein the common configuration framework includes a configuration data model that is abstracted from the data or data model used at any physical location or site, thereby enabling a centralized configuration database to support, store, and change configuration data for multiple different control systems at different physical locations or sites, or even at different parts of the same physical location or site.

[0032] The configuration system described herein includes a centralized configuration database stored in the computing fabric of the enterprise, wherein the configuration database uses a common configuration schema or data model to store configuration data for each of a plurality of systems (e.g., control systems or control system components) located at different physical sites of the enterprise. The configuration system also includes a collection of configuration database services or modules that manage reading from and writing to the enterprise configuration database to enable users to access any desired data from the enterprise configuration database via one or more computing devices located in or connected to the computing fabric of the enterprise. These configuration database services can also enable reading from and writing to the configuration database from one or more devices (or users) located at various different physical locations or sites of the enterprise.

[0033] In some embodiments, users or hardware / software at these physical locations or sites can access a centralized enterprise configuration database and can perform configuration activities (or software that can be stored in the computing structure and executed therein, which performs control or other activities at these physical locations or sites) of the equipment or software (e.g., control modules) at these physical locations or sites. In this case, the user or device at the physical location can access the computing structure via a bridging device located at the physical location and can send one or more configuration messages to the enterprise configuration database via the bridging device. These configuration messages may include configuration changes made to the equipment or software at the physical location and may include a read request from the enterprise configuration database or some combination of these two situations. Thereafter, the configuration message is processed by a translation service that can be located in the computing structure or at the physical location. In some examples, the translation service may be located in a computer device at the physical location, but may still be located in the computing structure, or may be located in a computer device that is located in a cloud or other shared computing resources. In other cases, the translation service may be located in a computing device at the physical location. In any case, the translation service translates the configuration data within the configuration message from the configuration data schema used at the physical location (at the local configuration database) to the configuration data schema used in the enterprise configuration database, so that the configuration database services can understand the exact configuration data being requested, changed, or written in the enterprise configuration database. Likewise, when configuration data is read from or sent to the physical location from the enterprise configuration database, the translation services translate the configuration data from the public configuration data schema to the configuration data schema used at the physical location (e.g., to the configuration schema or data model used by the control or monitoring system at the physical location).

[0034] In a similar manner, configuration viewing devices located within or directly connected to the computing structure can connect and communicate with these configuration database service applications within the computing structure and can send configuration changes to the centralized enterprise configuration database or request configuration data from it. Here, these configuration viewing devices can use any desired type of configuration application, which uses any desired configuration data schema to enable the user to make configuration changes and request configuration data. These enterprise configuration database services then translate these data reads and writes into the common configuration data schema to understand what configuration data in the enterprise configuration database is being read or written, and use this common configuration data schema to read and write data to the enterprise configuration database. Furthermore, configuration data read from the enterprise configuration database can be translated by these enterprise configuration database services into the specific data schema used by the configuration viewing device or application. In this way, these enterprise configuration database services can support different configuration viewing programs (e.g., produced or provided by different control system manufacturers) and enable any of these different configuration devices or programs to make configuration changes and read data from the enterprise configuration database. Thus, for example, different users within the enterprise may use different configuration applications (e.g., a DeltaV configuration application, a Honeywell configuration application, an OPC UA configuration application, etc.) to access and make configuration changes to the enterprise configuration database, and thereby access and make configuration changes to different devices or components at different physical locations (which may include control system hardware manufactured by different control system equipment manufacturers or supporting different control system communication and control paradigms).

[0035] Furthermore, these enterprise configuration database services may include a communication interface that communicates with various configuration viewing (or changing) applications within the enterprise's computing fabric or connected to the computing fabric, for example, via one or more application programming interfaces (APIs). These enterprise configuration database services may also include a configuration data model that defines the configuration data schema used within the enterprise configuration database and uses this data model to map configuration data and configuration data requests sent from the configuration viewing application or other configuration viewer to access the correct configuration data within the configuration database, as defined by the configuration application or viewer. Furthermore, these enterprise configuration database services may include a database storage abstraction layer that defines the details and methods for actually storing and accessing data within the enterprise configuration database. This component enables different types of databases (which may use different database storage schemes, structures, or technologies) to be used as the enterprise configuration database, and manages the actual reading and writing of data to and from the database using the structures, data calls, and data formats required by the specific database technology used. This component makes the enterprise configuration database technology agnostic to the database storage technology used within the computing fabric because it enables different types of databases using different data storage and retrieval technologies or underlying technologies to be used as the enterprise configuration database. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] Figure 1 is a block diagram of an example architecture of a next generation process control and automation system ("NGPCAS") that may be used to control industrial and / or automation processes and in which advanced engineering and configuration systems may be implemented.

[0037] Figure 2 is a block diagram of an example architecture of a Next Generation Process Control and Automation System ("NGPCAS") in which a high-level engineering and configuration system may be implemented to support industrial and / or automation processes having installed or legacy distributed control systems therein.

[0038] Figure 3 Can be included in Figure 1 and Figure 2 A block diagram of an example architecture of the computing structure in NGPCAS.

[0039] Figure 4 It is available in Figure 1 and Figure 2 Diagram of the enterprise engineering and configuration system used in the system.

[0040] Figure 5 yes Figure 4 FIG2 is a diagram of an enterprise configuration system of FIG2 showing the enterprise configuration database service in more detail.

[0041] Figure 6 is a diagram illustrating an example set of facets for supporting a configuration system for a process control system.

[0042] Figure 7 is a diagram showing an extended S88 hierarchy that supports enterprise configuration activities using enterprise, department, and region categories.

[0043] Figure 8 is to show that process control elements can be used as Figure 4 and Figure 5 Diagram of an example organization or data schema for a portion of a common data model or configuration data schema in a configuration system.

[0044] Figure 9 is a diagram illustrating an example domain model that may be used to organize configuration elements of an enterprise control system.

[0045] Figures 10A to 10C It is shown that it can be used in Figure 4 and Figure 5 Figure 1 is a diagram of an example data element hierarchy for performing communications in an enterprise configuration system.

[0046] Figure 11 It shows that Figure 4 and Figure 5 Diagram of an example organization of change sets used in an enterprise configuration system to implement and coordinate configuration changes.

[0047] Figure 12 Illustrated are example ways in which an enterprise may implement the configuration system described herein to support the enterprise using a computing fabric hub and communication spoke configuration to support multiple different enterprise sites that may use different data and execution governance rules and different process control systems.

[0048] Figure 13 A diagram of a configuration organization system that enables configuration activities to be performed at an enterprise to add, upgrade, or otherwise change the operation of an enterprise system is shown.

[0049] Figure 14 is an illustration of an example configuration system user interface display that enables a user at any of multiple locations in an enterprise to make hardware and software configuration changes to various different elements of the enterprise.

[0050] Figure 15 is shown for the Figure 1 and Figure 2Illustration of a development system for developing and rolling out new features, such as containers or products, in one or more of an enterprise system in an enterprise system in a manner that shortens the development and rollout time associated with new control system features while providing enterprise system administrators with the ability to control the timing and selection of configuration changes to the enterprise system. DETAILED DESCRIPTION

[0051] This article describes an engineering and configuration system (generally referred to as a configuration system) that can be used in process plant and industrial control and / or automation system architectures that rely on a shared computing fabric to implement control, monitoring, and configuration activities in any enterprise with one or more process plants or industrial manufacturing or automation facilities. Generally speaking, the computing fabric of these systems is a high-performance computing system that includes loosely coupled storage, resource management, security, networking, and parallel processing capabilities linked by a high-bandwidth interconnect (such as 10 Gigabit Ethernet) and can 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 the enterprise or system provider and dedicated to implementing process control at one or more enterprises; a computing cluster located locally and at the process plant; and the like. Because the resources of the computing fabric can be shared between process plants or sites within an enterprise or by multiple enterprises each operating one or more process plants, and because the system architecture does not attempt to follow the well-known, commonly followed, and recognized Purdue model, the control and configuration system described herein enables various improvements and innovations in system configuration, control, monitoring, and management.

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

[0053] Example 1

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

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

[0056] 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. However, a user or engineer at an enterprise can access a configuration application operating in the computing fabric to view or make configuration changes at one or more physical sites of the enterprise, and can also access a configuration application operating at one or more physical sites to make configuration changes at the sites. In both cases, the configuration changes are sent to and stored in a configuration database that can be evaluated from both the computing fabric and each physical site of the enterprise.

[0057] Generally speaking, the microservices, particles or MEEEs instantiated in the computing structure can be independent software processes that can be run on their own deployment schedule and can be updated independently of other microservices. The example of MEEE can include function blocks, control modules, control applications and the business logic related to the process plant and / or other applications and services that otherwise support the process plant. Grouped microservices or MEEEs can interact collaboratively to achieve some desired results. For example, in order to control a reactor, a plurality of strategies such as feed, reactor, product, utility and flare systems can be defined by corresponding MEEEs, and this set of multiple MEEEs can operate collaboratively (for example, combine with each other) to achieve desired reactor control strategies during the runtime of the process plant. In another example, for process control analysis applications, various MEEEs can be defined as performing corresponding statistical calculations and / or statistical algorithms, and 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 (for example, the control strategy of the entire system or plant) to very fine (for example, only a portion of a control routine or control module). 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.

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

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

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

[0061] 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 an enterprise or process plant interacts with one or more APIs of the system and can perform necessary actions through the one or more APIs after the user or third-party application is authenticated (e.g., using multi-factor authentication).

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

[0063] Example 2

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

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

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

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

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

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

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

[0071] Example 3

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

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

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

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

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

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

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

[0079] Example 4

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

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

[0082] Example 5

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

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

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

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

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

[0088] As will be appreciated, in each of these examples, a robust engineering and configuration system is required to enable users of an enterprise (where such users may be engineers or automated tools, such as auto-tuning applications) to make configuration changes to the enterprise's various software and hardware elements, including those located and executed within the enterprise's computing infrastructure and at one or more of the enterprise's physical locations or sites. It is desirable that the configuration system be integrated in that it stores, manages, and integrates configuration data from all elements of the enterprise, including those executing within the computing infrastructure and those located and / or executed at each of the physical locations or sites. Furthermore, because in some of the above examples, one or more different pieces of process control system hardware (such as control hardware manufactured by different manufacturers) may be located at different sites within the enterprise (or even at the same site within the enterprise), it is desirable that the configuration system be able to integrate and manage configuration data generated or used in different types of control systems that utilize different underlying data or configuration schemas. It is also desirable that the configuration system enable configuration changes to be made from any physical location within the enterprise, including from configuration viewing or management devices directly connected to the enterprise's computing infrastructure and from configuration viewing or management devices located at the enterprise's physical locations or sites.

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

[0090] Figure 1The present invention is a block diagram of an example architecture of a next-generation process control and automation system ("NGPCAS") 100, which can be used to control industrial and / or automated processes and in which the advanced configuration system can reside. For example, the NGPCAS 100 can 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. For ease of reading, the NGPCAS 100 is interchangeably referred to herein as the "architecture 100" or the "system 100."

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

[0092] 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), or the pool of physical devices 105, 108 may be entirely located or located only at a single physical location, site, plant, or environment (not shown). The one or more physical locations 115, 118 (also referred to as "sites") at which 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 automation process. The term "field environment 120" is interchangeably referred to herein as the "process environment 120," "automation environment 120," "plant environment 120," "physical environment 120," or a physical site or physical location of an enterprise of the NGPCAS 100.

[0093] Each physical location or site 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 an individual field device 105, 108 and corresponding physical I / O interface resources 125, 128 that the individual field devices 105, 108 use 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.

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

[0095] 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 a single gateway 148 (e.g., location 118). Figure 1 not shown).

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

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

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

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

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

[0101] In one embodiment, a single physical location 115, 118 may be communicatively connected to the computing fabric 102 via a secure, encrypted location-to-location PTP or P2P connection (such as a location-to-location VPN or other suitable implementation) dedicated to the specific location 115 / 118 and the computing fabric 102 (not shown). The physical components 135 / 138 located at the specific location 115 / 118 and the containerized components / MEEEs / granules 140 executing on the computing fabric 102 may communicate data and information to each other via the location-to-location PTP or P2P connection. For illustration, in Figure 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, architecture 100 can support subnets within the location-to-location VPN, such that various physical components 135 / 138 and various containerized components / MEEEs / granules 140 located at location 115 can communicate with each other via one or more subnets within the location-to-location VPN. Furthermore, in the foregoing description, secure, encrypted PTP and / or P2P connection types other than VPN can additionally or alternatively be utilized.

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

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

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

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

[0106] 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 users 155 depicted in FIG. 1 may be equated to people and applications / services accessing data and information related to a traditional process control or automated plant at any of Levels 1-5 of the Purdue Model.

[0107] 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 interact 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. In another example, the 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. The automated user 155 may not provide any user interface for a human user, but may still establish a communication connection with the NGPCAS 100 via the VPN 158 to obtain or provide data and / or other information. Examples of automated users 155 include third-party generated applications, external data sources (such as weather data sources, material management systems, etc.), etc. In some cases, the 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 (such as an automated adjustment application).

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

[0109] 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 collection 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 collection of containerized components / MEEEs / 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 this 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; and so on. Each application or service created, configured, and utilized by the architecture provider / manager 161 can be implemented by one or more containerized components / MEEE / granules 140. In addition, as Figure 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 interact 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.

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

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

[0112] 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) such containerized components provide lower level logical functionality that can be utilized by or relative to other containerized components / MEEEs / particles 140 as needed. Such lower level logical functionality may include, for example, a collection of APIs 160, 165 used by users 155 to interact 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 provided 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, time synchronization, service location, console support, life cycle management, etc.); etc.

[0113] 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 layer and the network layer 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.

[0114] in addition, Figure 1 Location n 118 is depicted as including a backup control system 169 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 169 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.

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

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

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

[0118] Importantly, if Figure 1As shown, one or more of the containerized components / MEEE / granules 140 can be used together to implement a portion of a configuration system 166, which can include various elements or subcomponents described in more detail herein, including a configuration database, an enterprise configuration database service application, one or more translation service applications, and one or more configuration viewing applications, to name a few. In addition, the configuration system 166 can include components located at various physical locations or sites 115, 118, including a bridging device 167 and a local configuration database service application 168 at each location. In general, the configuration system 166 located in the computing structure 102 includes a centralized or public configuration database and a collection of enterprise configuration database services. The enterprise configuration database can be a centralized or public configuration database that stores configuration data for each of the various enterprise elements (such as control elements) implemented in the computing structure 102 and / or at one or more of the physical locations 115, 118. Likewise, the enterprise configuration database service may enable a user (who may be a configuration engineer or other human user, or who may be an automated user, such as an automated tuning application or service) to access data in the configuration database and / or make changes to the configuration database from a configuration viewing device connected via the computing structure. In general, the enterprise configuration database service manages the enterprise configuration database, accesses the enterprise configuration database to read configuration data stored in the enterprise configuration database and make changes thereto, and tracks configuration changes made to the enterprise configuration database from configuration viewing (and changing) devices directly connected to the computing structure or from one or more of the local database configuration service applications 168. In a similar manner, the local configuration service applications 168 at the physical locations 115, 118 enable users at the physical locations to access (via the bridging device 167) the centralized enterprise configuration database to read configuration data stored in the configuration database and make changes thereto. This document will reference Figure 4 and Figure 5 Configuration system 166 is described in more detail.

[0119] For example, Figure 2 A block diagram illustrating an example architecture of a Next Generation Process Control and Automation System ("NGPCAS") 100A having Figure 1 The basic components of the system 100 are configured to support a conventional distributed control system such as Control systems for industrial and / or automated processes. In this case, the NGPCAS100A includes Figure 1 All components of the system 100 are connected to one or more plants or physical locations 115A and 118A where a conventional control system has been implemented. Figure 2As shown, locations 115A and 118A may have a distributed controller 170, such as a DeltaV controller, connected to various field devices 174, such as smart field devices, through various input / output (I / O) devices 172. The field devices may communicate with the I / O devices 172 using any desired or typical wired or wireless communication network. The field devices 174 may be, for example, 4-20 mA, Fieldbus, Profibus, Canbus, APL, or any other communication protocol compatible field device that communicates using any standard or known communication network or physical layer and communication protocol, including process control communication protocols (e.g., HART, fieldbus, etc.). Here, the process controller 170 may store and implement a conventional control program that may control the field device 174 using, for example, function blocks, control blocks, etc. Figure 2 As shown, controller 170 may be coupled to one or more databases, including a local configuration database 176 that stores configuration data for the system at the physical site where local configuration database 176 is located. Both controller 170 and local configuration database 176 may be connected to a local database configuration service or application 168.

[0120] However, if Figure 2 As shown, the process controller 170 may also 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 may be connected to elements within the computing structure 102 via secure VPN links 130. The VPN gateway 180 operates as a data aggregator to collect data from the process controller 170, or in another embodiment, directly from the I / O devices 172 (shown by the dashed lines at location 115A) to obtain, manage, convert, aggregate, and collect data from the field devices 174. The VPN gateway 180 also operates to encrypt the collected data and provide it to other components in the computing structure 102 (which use the data to perform control or other services) via the VPN or other secure and encrypted communication link 130. With respect to location 115A, the NGPCAS 100A may simply bypass the controller 170 to perform a similar operation to the NGPCAS 100A. Figure 1 The controller 170 can be operated and programmed to back up the control system 169, such as Figure 1As shown, the controller 170 at location 115A takes over control of the field devices 174 at location 115A in a failover or backup situation. However, in another example, the controller 172 may be or implement the primary control of the processes at locations 115A and 118A. In some cases, the bridging device 167 may be separate from the data aggregator and VPN gateway 180, or may be implemented in or as part of the data aggregator and VPN gateway.

[0121] On the other hand, as regards Figure 2 As shown in the physical location 118A of FIG. 1 , the controller 170, the local database configuration service 168, and the bridge device 167 can 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 (of location 118A), the local database configuration service 168, and the bridge device 167 are part of the computing structure 102, which is indicated by the extension down into the physical location 118A to include these elements. 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.

[0122] 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 installed legacy control system hardware (such as process controllers, field devices, I / O devices, etc.), which makes the NGPCAS described herein easier and cheaper to install and use in factories or other physical locations where control hardware is already installed. Thus, the VPN gateway 180 enables the NGPCAS system 100A described herein to be used to quickly and easily convert standard legacy control systems (such as distributed control systems) to NGPCAS. Of course, although Figure 2 A conventional or installed control system is shown as a distributed control system, but other conventional or installed control systems may be used in the same or similar manner to support NGPCAS.

[0123] However, similar to Figure 1 control system, Figure 2The system includes one or more of the containerized components / MEEE / granules 140, which can be used together to implement a portion of the configuration system 166, including a configuration database, an enterprise configuration database service application, one or more translation service applications, and one or more configuration viewing applications. In addition, as Figure 2 As shown, the configuration system 166 may include components located at various physical locations or sites 115A, 118A, including a bridging device 167 and a local configuration database service application 168 at each location. Generally speaking, the configuration system 166 located in the computing structure 102 includes a centralized or public configuration database and a set of enterprise configuration database services. The configuration database can be a centralized or public configuration database that stores configuration data for each of the various enterprise elements (such as control elements) implemented in the computing structure 102 and / or at one or more of the physical locations 115A, 118A. Similarly, the enterprise configuration database service (which can be a module) can enable a user (who can be a configuration engineer or other human user, or who can be an automated user, such as an automatic tuning application or service) to access data in the enterprise configuration database and make changes to the enterprise configuration database from a configuration viewing device connected via the computing structure. In general, the enterprise configuration database service manages the enterprise configuration database, accesses the enterprise configuration database to read and make changes to configuration data stored in the enterprise configuration database, and tracks configuration changes made to the enterprise configuration database from configuration viewing (and changing) devices directly connected to the computing fabric or from one or more of the local configuration service applications 168. In a similar manner, the local configuration service applications 168 at the physical locations 115A, 118A enable users at the physical locations (via the bridge device 167) to access the centralized enterprise configuration database to read and make changes to configuration data stored in the enterprise configuration database. In this case, the configuration system 166 supports a variety of different installed process control systems at the various different locations 115A and 118A, where the different process control systems at the different locations 115A and 118A can be different types of control systems, such as a distributed control system and a programmable logic control (PLC) system, control systems manufactured by different manufacturers (such as an Emerson control system and a Honeywell or ABB control system), control systems that use different data models to perform communication (such as a control system based on DeltaV communication and a control system that supports OPC UA communication), and generally can be control systems that use different data models or different data and configuration schemas to perform operations.

[0124] Example computing structure architecture

[0125] In the description can be Figure 1 and Figure 2 Before configuring the system used in an enterprise, describe Figure 1 and Figure 2 The general structure of the computational structure of will be helpful. Specifically, Figure 1 and Figure 2 The computing structure 102 of the next generation process control and automation system 100, Figure 3 A block diagram of an example architecture 200 of the computing structure 102 is depicted. Of course, the example architecture 200 can be utilized in computing structures and / or in process control and automation systems other than the computing structure 102 of the NGPCAS 100. However, for the purpose of facilitating the discussion herein and not for the purpose of limitation, reference will be made to the example architecture 200 herein. Figure 1 To describe the architecture 200. Additionally, for ease of reading, the architecture 200 of the computing structure 102 is interchangeably referred to herein as "computing structure architecture 200" or simply "computing structure 200."

[0126] In general, and as described below, the computing structure 200 utilizes a layered architecture in which the business logic of the computing structure 200 is abstracted from the physical computing platform of the computing structure 200. For example, the computing structure 200 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,” which was published as U.S. Patent Application Publication No. 2022 / 0404798 on Dec. 22, 2022, 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 200 is described with reference to the system 100; however, this is for illustrative purposes only and is not limiting.

[0127] like Figure 3 As shown, the computing fabric 200 is communicatively connected to the on-site environment 120 via one or more networks 202. For example, in an embodiment where the computing fabric 102 of the NGPCAS 100 utilizes the computing fabric architecture 200, the one or more networks 202 may be included in Figure 1The networks 202 typically include high-bandwidth data or communication links that support packet delivery to and from the computing structure 200 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 one or more networks 202 may include an advanced physical layer (APL) or some other type of physical layer or other protocol layer that supports Ethernet and / or other packet-based protocols.

[0128] Physical layer of computing architecture

[0129] As further shown, the example architecture of the computing fabric 200 includes a computing platform 205 that supports the higher-level hardware and software resources of the computing fabric 200. Therefore, the computing platform 205 is interchangeably referred to herein as the "physical layer 205" of the computing fabric 200 because it contains physical processors, processor cores, memory, and network interfaces. The computing platform or physical layer 205 of the computing fabric 200 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 the corresponding nodes Ny within each data center cluster Cx that 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.

[0130] 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 physical devices 105, 108 of NGPCAS100 are set, and / or at one or more other locations where physical devices of 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 205.

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

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

[0133] The example architecture of the computing fabric 200 also includes a software-defined (SD) network layer 210 that enables the physical layer 205 of the computing fabric 200 to interact with the software-defined application layer 212 of the computing fabric 200. Therefore, the software-defined network layer 210 is interchangeably referred to herein as the "operating system (OS) 210" of the computing fabric 200. In general, the OS 210 of the computing fabric 200 can assign, designate, or allocate various computing fabric nodes Ny to perform corresponding roles or functions in supporting the computing fabric 200, 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 200 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 200 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 210. Advantageously, the computing platform 205 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 200, and in particular, as required by other higher-level requirements of the computing fabric 200. For example, different nodes Ny of the computing fabric 200 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.

[0134] The operating system 210 of the computing fabric 200 executes on the computing platform 205 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 210 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 200 of the next-generation process control and automation system 100, the OS support services dynamically respond to the logical or abstract process control or automation system and other software components provided by the software-defined application layer 212 of the computing fabric 200. That is, as the performance, resource requirements, and configuration of the various application layer services, subsystems, and other software components of the application layer 212 dynamically change (and / or are dynamically predicted to change by services within the application layer 212), the operating system 210 can automatically and responsively adjust and / or manage the use of the hardware and / or software resources of the physical layer 205 to support the needs and requirements of the application layer 212 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 210 may include a collection of support services, including, for example, software-defined (SD) computing services 215, SD storage services 218, SD networking services 220, SD orchestration services 222 (also interchangeably referred to herein as "orchestrator 222"), and optionally one or more other process control and / or automation-specific SD OS support services and / or functions 225. For example, process control and / or automation specific SD OS support services and / or functions 225 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 210 and / or by the physical layer 205 of the computing fabric 200, such as virtual machines, containers, networks, network security groups, clusters, servers, etc.Thus, in one embodiment, the operating system 210 of the computing fabric 200 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 215, SD storage services 218, SD networking services 220, SD orchestration services 222, and other process control and / or automation SD OS support services and / or functionality 225, wherein the collection of SD support services 215-225 automatically responds to and specifically supports application layer software components 212 of the computing fabric 200, which include process control and / or automation specific applications and services as previously discussed.

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

[0136] Specifically, when the compute fabric operating system 210 manages the allocation of hardware and software resources of the node Ny of the compute platform 205 via the SD OS support services 215-225, the SD OS support services 215-225 may also serve as an interface service between the OS 210 and higher-level services, subsystems, and other software components of the application layer 212 of the compute fabric 200 and / or may provide a framework for these higher-level services, subsystems, and other software components of the application layer 212. Thus, the software components of the compute fabric application layer 212 may access the hardware and software resources of the node Ny of the compute platform 205 via a set of application programming interfaces (APIs) 228, via an HCI adapter 230 (also referred to herein as the "HCI adapter layer" 230) and another set of APIs 232, or directly ( Figure 3 The HCI adapter layer 230 enables the compute fabric application layer 212 to access the SD OS support services 215, 218, 220, 222, 225 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 215-225 to form the OS 210. Thus, the HCI adapter 230 converts or translates the API 228 utilized by the compute fabric application layer 212 into a set of APIs 232 that are understood or otherwise known to or compatible with the customized or adapted general-purpose HC operating system 210 of the compute fabric 200.

[0137] 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 200 not only abstracts the higher-level business logic services, subsystems and other software components of the application layer 212 from the hardware and software computing platform 205, but also enables the higher-level software-defined services, subsystems and other software components 212 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 205 and software-defined network layer 210 (and optionally, their hardware and / or software resource groups) via, for example, APIs 228 and SD OS support services 215, 218, 220, 222, 225 without any human intervention or guidance. Specifically and advantageously, management of resources of the physical layer 205 and the software-defined networking layer 210 dynamically responds to changes in the configuration and requirements of these higher-level SD services, subsystems and other software components of the application layer 212, 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.

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

[0139] like Figure 3 As shown, industrial process control, automation and other associated business logic are performed by higher-level software-defined services, subsystems and other software components 235-248 provided by the application layer 212. For ease of reading this document, the present disclosure categorically and interchangeably refers to these higher-level SD services, subsystems and other software components 235-248 as "software-defined application layer components" or "application layer software components" of the computing structure 200. In one embodiment, a collection of software-defined application layer components 235-242 (and optionally at least some third-party services 248 executed at the application layer 212) may collectively form a logical process control or automation system 245 (also interchangeably referred to herein as a "virtual" process control or automation system 245) that executes in conjunction with the physical components 135, 138 of the NGPCAS 100 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 3 245. In general, application layer software components may be provided by the enterprise (eg, via the architecture provider / manager 160), a user 155 acting as an agent for or associated with the enterprise 155, a third party, and / or other sources.

[0140] The application layer software components 235-248 of the application layer 212 can be executed in containers and / or other suitable types of micro-encapsulated execution environments (MEEEs) or particles, for example, as instantiated software components (ISCs). For example, an ISC can be a container that is configured with an instance of a specific application layer software component 235-248 to form a configuration container, container image, or other type of micro-encapsulated execution environment or particle for the specific application layer software component 235-248, and the container image of the specific application layer software component 235-248 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 235-248 that is configured into a corresponding container or other type of micro-encapsulated execution environment or particle.

[0141] In general, containerized or micro-encapsulated software components or MEEEs / granules (e.g., at the application layer 212, HCI adapter layer 230, and software-defined network layer 210) 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.

[0142] 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 zone, or even the entire process control system 245.

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

[0144] 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 the agent of the enterprise or the user 155 associated therewith, third party and / or other source. Various instantiation MEEEs can be assigned to execute on various computing nodes Ny of system 200, which can be arranged in different physical and / or geographical locations. In addition, the instantiation 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, the instantiation 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 215. The SD compute service 215 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 245, to support expansion or contraction of the computing platform 205, 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 of the 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.

[0145] Within the computing fabric 200, some configuration containers, granules, or instantiated MEEEs may be allocated or assigned to respective compute nodes Ny and dynamically reassigned to different compute nodes Ny by the SD compute service 215 based on the dynamically changing configuration, performance, and requirements of the logical process control or automation system 245. 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 215, by configuration, by a user, etc.) and not dynamically reassigned by the SD compute service 215 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 245 (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 210 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 210 removes the restriction. If desired, the configuration container can additionally or alternatively be pinned to other physical or logical components of the compute fabric 200. 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 supply (where the physical rack physically houses the hardware of one or more compute fabric nodes), etc.

[0146] Furthermore, configuration containers, instantiated MEEEs, or particles can be nested within other configuration containers and / or pinned to other configuration containers, which can be particularly useful in configuring and organizing a logical process control or automation system 245. For example, when a particular process control subsystem 238 provides a particular set of control services 235 and / or other services 240, the configuration container for each provided service 235, 240 of that particular set can be nested within the configuration container of that particular process control system 238. In another example, multiple control routines and / or control module configuration containers can be nested within a particular controller service 235, and a particular controller service 235 can be nested within a particular process control subsystem 238. In yet another example, a controller or control service 235 can be configured with one or more process control module services 235, 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 235 may be functionally equivalent to a traditional dedicated hardware controller device as understood in the Purdue model, or the controller service 235 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 configured set of 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 200.

[0147] In yet another example, containers, granules, or instantiated MEEEs within the SD application layer 212 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, regions, etc. may be represented by corresponding configuration containers, and configuration containers corresponding to the physical and / or logical components of each unit, region, etc. may be nested within and / or pinned to their corresponding configuration organization containers. Thus, within the computing structure 200, a configured control routine container may be nested within or pinned to a configured controller container, and a configured controller container may be nested within or pinned to another configuration container, such as a container that has been configured for a depropanizer.

[0148] 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 212 of the computing structure 200.

[0149] Regardless, and in a manner similar to that discussed with respect to the computing resources of the computing platform 205, 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 218, to support the various storage needs of the logical process control or automation system 245. For example, the SD storage service 218 can oversee and manage the logical storage resources utilized by the configuration container of the logical process control or automation system 245 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 areas of the SD storage node Ny. The SD storage service 218 may change, update, or otherwise manage one or more physical hardware memories of the computing platform 205 to support the logical storage resources of the computing structure 200 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 205, etc.

[0150] Still similarly, the SD networking service 220 can oversee and manage logical or virtual networks utilized by the containerized components / MEEEs / granules 140 of the logical process control or automation system 245 and / or by other containerized components / MEEEs / granules 140, which can be implemented by the SD networking service 220 across the compute fabric nodes Ny. For example, the SD networking service 220 can oversee and manage the networking and hardware resources of the compute platform 205 to support logical network functionality included in the logical process control system 245, 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 200. Furthermore, when the logical process control system 245 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 200, the physical components 135, 138 of the field environment 120, and the networking therebetween are critical, as missed and / or lost messages or communications may cause the industrial or physical process to become uncontrolled, which in turn may lead to catastrophic consequences such as spills, gas leaks, explosions, equipment loss, and in some cases, loss of human life. Fortunately, the SD networking service 220 is responsive to the critical process I / O timing and synchronization of the computing fabric 200, so that communications (and specifically, communications to / from the control service 235) can be reliably delivered in a timely and deterministic manner. For example, the SD networking service 220 can support time synchronization within 1 millisecond for the data center cluster Cx to ensure the required synchronization between the process control service 235, the process control subsystem 238, the packet router / switch service 242, and other software-defined services 240, 248 of the software-defined application layer 212.

[0151] In addition to the SD compute services 215, SD storage services 218, and SD networking services 220, the compute fabric operating system 210 may also provide other OS support services 225 that are accessible via a set of APIs 228, 232 and that may be utilized or accessed by the application layer 212 to support a logical process control system 245 and other containerized components / MEEEs / granules 140 of the application layer 212 of the compute fabric 200. For example, the other OS services 225 may include life cycle management services, discovery services, security services, cipher services, certificate authority subsystem services, key management services, authentication services, time synchronization services, resource and / or resource group management services, service location services, and / or console support services (none of which are described in detail in the original text). Figure 3 In some embodiments of the computing structure 200, one or more support services may be executed at the application layer 212, for example as other software-defined services 240, rather than being executed at the software-defined network layer 210 as OS support services 225.

[0152] In fact, in one embodiment, one or more of the software-defined components 215-225 and 252-260 of the software-defined networking layer 210 are implemented as corresponding configuration containers or container images of the computing fabric 200. That is, one or more services and other functionalities provided at the software-defined networking layer 210 of the computing fabric 200 (and in some specific implementations, all services and functionalities provided at the software-defined networking layer 210) 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 212, the containerized components / MEEEs / granules 140 of the software-defined networking layer 210 can be uniquely identified within the NGPCAS 100 by corresponding addresses, 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.

[0153] Application layer of computing structure

[0154] Turning now in more detail to the application layer 212 of the computing structure 200, and as Figure 3 As shown, the application layer software components 212 include a collection of software-defined services or applications 235 (such as software-defined process control or automation related services 235) and a collection of subsystems 238 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 240 of the NGPCAS100 (for example, enterprise business logic services related to process control or automation). In some specific implementations of the computing structure 200, the application layer software components 212 may include a collection of third-party business logic services 248. For example, the third-party services 248 may be generated by a software development kit (not shown) of the computing structure 200, and a user may develop, generate, install and manage the third-party services 248 at the SD application layer 212 via the software development kit. In general, the services and applications 235-248 provided at the application layer 212 form a logical process control system 245 and provide related functionality. In general, the applications 235-248 may be provided by the system 100 itself, a third party, a supplier, an end user 155, and / or other sources. For example, one or more of the applications 235-248 may be built on the APIs 160, 165 provided by the computing structure 102, and / or one or more of the applications 235-248 may be packaged as a container and distributed by the orchestrator 222.

[0155] Each different control service 235 can be configured with desired parameters, values, etc., and optionally with other control services 235; each instance of a configured control service 235 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 235 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 200 can easily replicate multiple instances of the same configured control service 235 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 services container, and the configuration control module services container can be nested within a configuration control module services 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 205, for example, for performance load balancing purposes. As the load changes, one or more configured function block service containers can be moved to execute on different processor cores, different processors, or even different compute fabric nodes in an attempt to rebalance the load; however, the moved function block service containers will still be nested under the configured control module services container and will execute accordingly.

[0156] In addition to the control services 235, other types of application layer services 240 related to industrial process control may be provided by the application layer 212, such as, but not limited to, operator display and interaction, diagnostics, analysis, safety routines, reporting, data historians, service configuration, container configuration, communication with external or other systems, enterprise-level applications, process control and / or automation resource and / or resource group management, and the like. For example, process control and / or automation resource group management services may allow users 155 to group and / or isolate various resources based on NGPCAS 100 and / or other process control or automation considerations. For example, resource groups may be formed based on physical characteristics, such as sites or physical locations, groups of sites / physical locations, subsets of sites or physical locations, geographic regions, and the like; based on logical characteristics, such as categories, containers and / or container types, control policies, capabilities, timing, performance, user characteristics, and the like; based on functionality, such as storage items, networking items, and the like; and / or based on other types of groupings corresponding to NGPCAS 100 and / or combinations thereof. In general, any process control or automation system-related functionality or business logic (including one or more configuration services or applications) executed during the runtime of NGPCAS100 to control industrial processes, support NGPCAS100 and / or be associated with NGPCAS100 can be logically implemented in the computing structure 200 as corresponding application layer services 235, 240 executed in corresponding containers. For example, any one or more of the enterprise-level computing structure functionalities can be implemented in corresponding containers or as containerized services. In addition, when the business logic of the services 235, 240 and / or the recipient physical components 135 / 138 require this, any of the containerized services 235, 240 can be communicatively connected to the corresponding physical components 135 / 138 set in the physical location of NGPCAS100, for example, via the SD network layer 210. In addition, any of the containerized services 235, 240 can be communicatively connected to any other containerized services 235, 240 to transfer data and / or information therebetween when their corresponding business logic requires this.

[0157] In a similar manner, each of the different subsystems 238 of the application layer 212 of the computing structure 200 may be provided by or executed in a corresponding container. The collection of subsystems 238 provides a virtual or logical process control-related subsystem of the logical process control system 245. In some cases ( Figure 3), a subsystem 238 may provide or include one or more application layer services, and therefore, the configuration containers of the services 235, 238 provided by the subsystem may be nested within the configured subsystem container. Generally speaking, the collection of subsystems 238 allows the control service 235 and other services 240 to be easily and consistently grouped and / or managed. In a preferred embodiment, each node Ny of the computing structure 200 hosts a corresponding instance of each subsystem in the collection of subsystems 238, for example, so that the subsystem services are readily available and easily available to other application layer services 235, 240, 248 currently executing on each node Ny. Thus, changes to one or more subsystems 238 can be coordinated between their corresponding instances executing at each node Ny (e.g., under the guidance of OS 210). Thus, not only is the set of subsystems 238 highly available and readily available to any application layer services 235, 240, 248 executing on the same node Ny, but the functionality provided by the set of subsystems 238 can be easily maintained for the logical process control system 245 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.

[0158] Examples of subsystems 238 that may be provided by the application layer 212 of the computing fabric 200 include, but are not limited to:

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

[0160] 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 245, the states of the containerized components / MEEE / granules 140 of the process control system 245, and / or the states of the physical components 105, 108 controlled by the process control system 245, and for driving the industrial process to achieve a desired process state within defined constraints (such as safety, environmental, and / or profitability constraints);

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

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

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

[0164] 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 210, and / or other components of the system 100;

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

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

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

[0168] - a licensing subsystem that includes application layer services 240 to verify or ensure that users have privileges according to the licensing level of the computing structure 200 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.;

[0169] 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 200 so that consistent record keeping can be provided across all nodes Ny; and

[0170] - 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 212, 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 200 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.

[0171] Furthermore, the application layer 212 of the computing structure 200 may include additional or alternative subsystems 238 that may be utilized by the system 100. For example, the subsystems 238 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.

[0172] Software-defined router / switch services

[0173] The software-defined packet router / switch service 242 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 212 of the computing fabric 200, and vice versa; from physical components 135 / 138 to containerized components / MEEE / granules 140 at the network layer 210 of the computing fabric 200, and vice versa. granule 140 at the application layer 212 and vice versa; from a containerized component / MEEE / granule 140 at the application layer 212 to another containerized component / MEEE / granule 140 at the application layer 212; from a containerized component / MEEE / granule 140 at the network layer 210 to another containerized component / MEEE / granule 140 at the network layer 210; from a containerized component / MEEE / granule 140 at the application layer 212 to a containerized component / MEEE / granule 140 at the network layer 210 and vice versa, etc. For example, the packet router / switch service 242 can communicatively couple the respective endpoints and transfer data therebetween using any suitable data delivery or data transfer paradigm, including request / response, publish / subscribe, etc. In one embodiment, when at least one of the software-defined application layer software components 235-248 is deployed as a microservice / MEEE / granule communicatively connected via a microservice / MEEE / granule bus (not shown), the packet router / switch service 242 (in some cases, in conjunction with the OS 210 and its supporting services 215-225) 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 242 can use any one or more packet-based networks or links (such as the network 202 and / or software-defined links provided by the computing fabric 200) 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.

[0174] Please note that Figure 3 The software-defined packet router / packet switch service 242 is depicted as a separate service at the application layer 212; however, this is for purposes of clarity of discussion (and not limitation). In other embodiments, the packet router / switch service 242 can be included in the subsystem 238 of the compute fabric 200, and / or at least a corresponding portion or all of the software-defined packet router / switch service 242 can be implemented in the HCI adapter 230 or in the compute fabric operating system 210. Alternatively, the packet router / switch service 242 can be an application-layer software-defined service 240 that is in its own independent subsystem within the application layer 212, or that is not associated with any subsystem. Regardless, and generally speaking, the software-defined packet router / packet switch service 242 can generally be implemented as a containerized component / MEEE / granule 140 of the compute fabric 200.

[0175] Thus, the containerized packet router / switch service 242 can be accessed by other containerized components / MEEE / granules 140 of the computing fabric 200 (at both the application layer 212 and the network layer 210) for data transmission or data delivery purposes. In some cases, the packet router / switch service 242 can utilize the API 228 to cause the transmission of packetized I / O data and / or other types of packetized data, for example, via the OS support services 215-225. In some cases, the packet router / switch service 242 can cause data to be transmitted via the microservices / MEEE / granule bus. In practice, the packet router / switch service 242 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 200, 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 200 and the physical components 135, 138 deployed in the field environment 120 of the NGPCAS 100.

[0176] 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 both the computing structure and the 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 program 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 to the cloud-based server in the computing structure from the server in the physical location.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 device in the computing structure or is generated by the device in the computing structure or by the device at physical location or factory.

[0177] Logical / virtual components

[0178] Furthermore, at the application layer 212 of the computing architecture 200, at least some physical process control devices or components of a conventional process control system (e.g., controllers, safety logic solvers or devices, data storage devices, etc.) can be logically implemented in a logical process control system 245 as corresponding services 235, 240, or subsystems 238 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 212, 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 245, 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 245 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.

[0179] At the software-defined application layer 212, the computing fabric 200 also includes a software-defined storage entity or component 213 that can provide abstract data storage (and access thereto) for the services and subsystems 235-248 of the SD application layer 212. For example, a historian database, configuration database, and other types of process control system databases and data storage entities, as well as temporary storage utilized by the various process control application services 235-248 during execution, can be provided by the software-defined storage entity 213. Storage databases, zones, 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 210 to various storage resources of the nodes Ny of the computing platform 205. 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 218 of the computing structure operating system 210 can assign / reassign and reassign / reallocate the software-defined storage entity 213 at the application layer 212 to different storage resources provided by the node Ny based on the performance, resource and configuration requirements of the storage entity or component 213 and optionally other components of the SD application layer 212.

[0180] Orchestration

[0181] Returning now to the software defined network layer 210 of the computing structure 200, for ease of discussion purposes, Figure 3 A specific compute fabric OS service, namely, orchestration service 222, is depicted separately from the depictions of other compute fabric OS services 215-220, 225. Generally speaking, orchestration service 222 instantiates container images (e.g., container images of application layer control services 235, subsystems 238, third-party services 248, and other software-defined services 240) to run or execute containerized applications or services on corresponding hardware and / or software physical compute 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 222 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 222 can assign various SD data storage entities or components 213 of application layer 212 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 222 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 200, for example, via the QoS configuration service 252, the fault tolerance service 255, the load balancing service 258, and other performance-related services 260 optionally provided by the OS 210. Thus, the orchestration service 222 can be called or accessed by other OS services 215, 218, 220, 225, and the orchestration service 222 can, in turn, call or access one or more of the performance-related services 252-260. Generally speaking, the orchestration service 222 allocates resources to the containerized components and SD data storage entities of the logical process control system 245 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.

[0182] To this end, the performance-related services 252-260 of the OS 210 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) 212 to the hardware and / or software resources of the computing platform 205. Thus, during runtime of the system 100, as various expected and / or unexpected hardware and / or software conditions arise and are detected, the orchestration service 222 responsively adjusts the allocation of hardware and / or software resources of the various computing fabric nodes Ny to the instantiated container images to maintain (or attempt to maintain) a target or best-effort performance level and operational fidelity. Detected conditions that may cause orchestration service 222 to modify the allocation and / or assignment between containerized components 212 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 222 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.

[0183] Thus, generally speaking, the services, subsystems, and other software components (e.g., 235, 238, 240) of the software-defined application layer 212 can determine, define, or specify the processing, containerization, networking, and storage requirements of the logical process control system 245 at both the individual container level and the aggregate level (e.g., at the subsystem level, the unit level, the zone level, and / or the entire process control system 245). Through the API 228 (and in some configurations, also through the HCI adapter layer 230 and API 232), the OS 210, its supporting services 215, 218, 220, 222, 225, and its orchestration services 222 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 222 can cause different instances of a particular control routine 235 or a particular other service 240 to execute on different nodes Ny, such as for fault tolerance, quality of service, and / or other performance criteria of the compute fabric 200. Advantageously, as the demands of the logical process control system 245 change dynamically over time, the OS support services 215 , 218 , 220 , 222 , 225 and / or the orchestration service 222 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.

[0184] For example, when the logical process control system 245 creates additional instances of the control service 235 that execute in additional containers, the OS support services 215-225 can responsively (via the API 228 and optionally the HCI adapter 230 and API 232) assign the newly created containerized components to execute on the corresponding compute fabric node Ny, can rebalance existing containerized components between the nodes Ny, can assign specific hardware memory resources to support the logical memory resource requirements of the additional containerized components, can adjust the routing tables utilized by the node Ny to support the logical routing requirements of the newly created containerized components, and so on. In 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 215-225 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 245 and the availability of hardware and / or software resources of the other clusters, and the support services 215-225 may accordingly adjust the routing table utilized by cluster Cx so that continuity of execution of the containerized component is maintained even when cluster C2 is taken out of service.

[0185] Thus, the software-defined networking layer 210 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 205 to different application layer software components 212 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 200), etc. Thus, the computing fabric 200 can automatically reallocate the hardware and software resources of the node Ny in response to changing conditions and components of the computing fabric 200, thereby supporting the process control system 245 and other services executed at the application layer 212 of the computing fabric 200.

[0186] simulation

[0187] In some implementations, the computing fabric 200 can enable simulation or modification of various application services 235, 240, 248, the entire software application layer 212, various supporting services 215-225, 252-260, and / or the entire software-defined network layer 210. That is, the simulation of the target component / layer can be executed in conjunction with the active software-defined component / layer on the computing platform 205, 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 200 is approved, it can be activated for use during runtime operation of the industrial process plant without requiring that a portion of the computing fabric 200 be paused or taken out of service to do so.

[0188] Example safety features of NGPCAS

[0189] Next, various security features of the next generation process control and automation system (NGPCAS) 100 are described. As previously discussed, today's process control and automation systems designed around the Purdue model have many disadvantages, including increased complexity (and therefore, more opportunities for component and process failures), reduced performance, and greater risk of network intrusion. For example, in today's process control and automation systems, there are typically at least three different domains between levels 2, 3, and 4, and the security policies for each domain may 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 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.

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

[0191] 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 225 provided by the software-defined network layer 210 of the computing structure 200. In addition, the software-defined network layer 210 can provide other services 215 for managing resources and / or groupings of hardware and / or software resources of the software-defined network layer 210 and / or physical layer 205 of the computing structure 200, which are allocated and / or utilized to support the security features of NGPCAS100.

[0192] Example Cybersecurity Features of NGPCAS

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

[0194] See also Figure 1 and Figure 3To 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:

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

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

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

[0198] a VPN specifically servicing communications between different layers of the computing fabric 200 , such as communications between the software-defined application layer 212 and the software-defined network layer 210 ;

[0199] a VPN specifically servicing communications between one or more selected services, subsystems, and functionalities at different layers of the computing fabric 200, such as communications between a selected one or more of the services and / or subsystems 235, 238, 240 at the application layer 212 and a selected one or more of the software-defined services and / or functionalities 215, 218, 220, 225 at the network layer 210;

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

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

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

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

[0204] Example User Security Features of NGPCAS

[0205] 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 cyber attacks, each user 155 may need to utilize one or more exposed APIs 160 to interact with and / or access the system data and / or functionality provided by the NGPCAS 100. For example, the functionality provided by the NGPCAS 100 for users 155 to utilize may be implemented as corresponding containerized components / MEEEs / granules 140 in the computing structure 102, and such containerized components may be exposed to users 155 only via the API 160 (e.g., as a website, service, etc.), where the API 160 can be accessed by users 155, for example, via a web browser or thin client. Typically, any functionality (e.g., all functionality) provided by the NGPCAS 100 for users 155 to utilize can be accessed by users 155 only via one or more corresponding APIs 160. In addition, for further security, communication between users 155 and one or more APIs 160 may be protected via corresponding VPNs 158. For further security, user 155 may be required to first be authenticated to VPN 158 before being able to utilize API 160 , and in particular, a human user may undergo multi-factor authentication in order to gain access to VPN 158 .

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

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

[0208] In addition, because user 155 is provided with access to selected functionality provided by NGPCAS 100 via API 160, and because user 155 must be authenticated to VPN 158 and optionally authenticated to utilize the specific API 160 described above, network security risks are even more significantly reduced compared to the network security risks of today's systems. For example, this security technology used within NGPCAS 100 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 network security vulnerability path. In 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 NGPCAS 100. That is, the VPN utilized by the user 155 (and optionally by the API 160 exposed to the user 155) and the VPN utilized by other non-user components and / or entities of the NPGCAS 100 can be mutually exclusive VPNs, thereby further eliminating other possible avenues of network security vulnerabilities. In yet 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.

[0209] Example Identity Security Features of NGPCAS

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

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

[0212] Example Communication Security Features of NGPCAS

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

[0214] Example calculation of structural safety features of NGPCAS

[0215] With particular regard to securing the compute fabric architecture 200 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 / 200 (e.g., APIs 160, 165; services and subsystems 235, 238, 240, 248, 213, 242 at the software-defined application layer 212; services and functions 215, 218, 220, 222, 225, 252, 255, 258, 260 at the software-defined network layer 210; APIs 228, 232 and / or other services provided at the adapter layer 230, 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.

[0216] 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 210 of the computing structure 200) 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.

[0217] At the physical layer 205 of the computing fabric 200 , 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.

[0218] Example Hardware Security Features of NGPCAS

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

[0220] Configuration system components within NGPCAS

[0221] As will be appreciated, the NGPCAS having a computing fabric configuration as described herein provides or enables its software-implemented components to be highly configurable, transferable, and editable because most control and support components (e.g., control modules, containers, etc.) are located and executed in the computing fabric without being tied to specific or predetermined computer hardware (e.g., a specific server, processor, computer node, etc.). This feature enables system setup and configuration activities to be performed more quickly and easily than with traditional control systems because it enables enterprise system owners or managers to store configuration components for their systems in the computing fabric, access these components from any location, and copy these components to create or add additional control system structures associated with, for example, a new plant or new physical location added to the enterprise, new hardware installed at an existing physical location, etc., without having to specify the location or details of the computer hardware used to implement the additional configuration components. Furthermore, the system can still be used to support multiple different sites, locations, regions, and departments of an enterprise, with the enterprise having plants or processes located at different physical sites, in different regions, associated with different departments, to support the manufacture of one or more different products.

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

[0223] In any case, if Figure 1 and Figure 2 As shown in , each enterprise may include a configuration system (166, 167, 168) having one or more configuration databases (which may be one or more distinct computer databases or memories) that store configuration elements for the enterprise or for portions of the enterprise and one or more configuration applications that enable users to view, change, and manipulate the configuration databases to affect and implement configuration changes for the enterprise, including configuration changes within elements executing in the enterprise's computing fabric and within hardware and software within or associated with one or more physical locations of the enterprise. The enterprise configuration database of the configuration system may, for example, store a library of elements (e.g., containers, modules, applications, products, etc.) used in the enterprise and may store information defining the identity and configuration of each element, group of elements, container, control system, etc., currently operating in the computing fabric or in devices within the enterprise's physical locations. Furthermore, the configuration application can enable an enterprise owner or manager to view and make changes to the configuration of any element of the enterprise, including making changes to the control system, adding or removing logical or physical equipment or components (and even physical locations) to or from the enterprise system, changing the location or fixturing of various resources or components (e.g., containers) within the computing structure, adding new field devices, I / O devices, etc. Additionally, the configuration system's application can, at the user's instruction, implement configuration changes by downloading or changing logical or software elements (e.g., containers) within devices within the computing structure or at physical locations in accordance with the user's changes. The configuration system described herein enables configuration changes to be made from anywhere within the enterprise, including from a configuration interface directly connected to the enterprise's computing structure or from a configuration interface connected to or located at a physical location of the enterprise, where such a configuration interface can be associated with a traditional control or other system at the physical location.

[0224] In any case, since the control elements within the computing structure are generally not bound to specific computer hardware within the computing structure, the configuration system described herein can easily make changes, deletions, additions, etc. to the elements actually running in the computing structure without requiring the user to specify where exactly those components are installed, so that the user can specify the logical configuration changes to be made and press a button to implement those changes in the actual hardware currently operating in the computing structure. The basic computing structure management system can then locate (or assign) the computer hardware that implements the changed or new components and make the changes seamlessly to the user. Although the configuration system described herein is generally shown as being stored in and executed in the computing structure of an enterprise, one or more components of the configuration system may be located in computer hardware at one or more physical locations of the enterprise, located in off-site computing structure resources, distributed or shared between the computing structure at one or more physical locations and off-site or licensed computing structure hardware, stored in a dedicated machine in the computing structure or in one or more physical locations, or in any other manner.

[0225] Figures 4 to 11 and the description associated therewith show and describe the Figures 1 to 3 A configuration system for use in an enterprise-based control and automation system. The configuration system can be used to implement, view, and track configuration changes made to different devices and software components across the entire enterprise, including devices and software components (e.g., containers) at the same or different sites of the enterprise (e.g., factories, areas of factories, physical locations of the enterprise), regions of the enterprise (e.g., geographic areas defined by the enterprise), departments of the enterprise (e.g., product lines or management departments of the enterprise), etc. Figures 12 to 15 and the descriptions associated therewith illustrate some applications or high-level systems that can be used Figures 4 to 11 The underlying configuration system components are used to make configuration changes in various parts of the enterprise in an organized or useful way. Figures 4 to 15 The configuration systems described herein are generally described as being associated with a process control configuration system that is used to configure one or more process control or automation systems associated with an enterprise, but the configuration systems described herein may be associated with any other type of configuration system, such as a configuration system associated with a maintenance or monitoring system that monitors equipment or systems within various zones, location sites, regions, departments, etc. of an enterprise. Therefore, it should be understood that the process control configuration system is described herein merely as an example of a configuration system that may be implemented using the techniques described herein.

[0226] Now refer to Figure 4 , shows in more detail a configuration system 300 for an enterprise having NGPCAS as described herein. In particular, the configuration system 300 includes a computing structure 302 (which may be Figures 1 to 3304. Figure 4 In an example enterprise system, a computing structure 302 is connected to three different sites or physical locations 304A, 304B, and 304C using the techniques described herein. Each of the different sites or physical locations 304 may include a different process control system or portion of a different process control system for controlling and / or monitoring devices (such as field devices) at the physical location 304. Such process control or automation systems may include field devices, input / output (I / O) devices, process controllers, user interfaces, communication networks, local configuration databases, and the like associated with or implementing any desired type of control or automation system. Furthermore, site or physical location 304A may include a first distributed process control system that implements a conventional DeltaV process control system, such as a process control system manufactured by Emerson Electric Co. Site or physical location 304B may include or implement a second distributed process control system, which may be provided by or associated with a different manufacturer, such as a Hive process control system manufactured by Honeywell, or a process control system manufactured by ABB, Siemens, Yokagawa, and the like. Furthermore, in this example, the third site or physical location 304C may include a different type of process control system, such as a PLC-based process control system, and / or may include a process control system that uses the well-known OPC UA communication standard to interface with and provide communications with or within the process control system. Figure 4 Only three sites or physical locations 304A, 304B, 304C are shown in FIG, but the enterprise may include any other number of physical locations, and each of these other sites or physical locations, or portions thereof, may include any type of conventional process control or automation system manufactured by any desired manufacturer, or may include systems such as those described with respect to FIG. Figure 1 and Figure 2 A generally described process control system in which field devices and I / O devices are located at a physical site, and control elements for the physical site are implemented in a computing structure, such as in the cloud or at the physical site.

[0227] Figure 4The configuration system 300 generally includes an enterprise configuration database 306 stored and implemented in a computing structure 302, and the enterprise configuration database 306 is connected to one or more translation services 308 (each of which is in turn connected to one of the sites or physical locations 304) and one or more enterprise configuration database service modules 310. Both the translation services 308 and the enterprise configuration database service modules 310 are stored and executed in the computing structure 302 of the enterprise. Figure 4 As shown, the enterprise configuration database service module 310 is also connected to or accessible by a configuration viewing system, device, or application 312, which may be referred to herein as Figure 1 and Figure 2 The manner described by user 155 is implemented in or connected to the computing structure 302. Because components 310, 306 and 308 are provided within the computing structure 302, these services, applications and database structures can be implemented as Figure 1 and Figure 2 of particles 140 and can be used with respect to Figure 3 The computing architecture is managed, supported, updated, and controlled in the manner described above with respect to these particles.

[0228] Also like Figure 4As shown, configuration system 300 may include one or more components located at each of sites or physical locations 304 that implement control, monitoring, and automation activities at the sites or physical locations. Specifically, configuration system 300 includes a local database configuration service 315 and a bridge device 317 located at each of physical locations 304A, 304B, and 304C. Generally speaking, each local database configuration service 315 is bound to or connected to a (e.g., legacy) process control or automation system 318 at the associated physical location 304 and receives data from users of that system indicating changes to the system or data indicating read requests from an enterprise configuration database 306 in the computing fabric. Each local database configuration service 315 may also be connected to a local configuration database 319 that stores configuration data for devices and systems at a particular physical location 304 (or some portion thereof), and / or each local database configuration service 315 may include, be connected to, or implement a local configuration viewing application 320. This local configuration viewing application 320 may be an application produced or provided by the manufacturer of the process control system at the physical location 304, for example, to enable a user to access the local configuration database 319 to view configuration data associated with devices, software, and systems in the process control system at the physical location 304 and to make configuration changes to such devices, software, and systems. (Such a configuration viewing application may be, for example, the DeltaV Control Studio application for the DeltaV process control system.) As will be appreciated, each local database configuration service 315 resides on top of or is integrated with the process control system at one of the sites 304 and may access data generated in and used by the control system at that site 304. The local database configuration service 315 may also include a user interface device that enables a user at the physical location 304 to view and make changes to the configuration of devices and systems at the physical location or site 304. However, in general, each local database configuration service 315 is limited to viewing and changing configuration data for the process control system devices and software at or associated with the physical location 304 where the local database configuration service 315 is located.

[0229] The bridge device 317 is a communication gateway device that connects the process control system (and database configuration service 315) at each physical location 304 to the computing structure 302, and specifically, to one of the translation services 308 implemented in the computing structure 302 of the enterprise. The bridge device 317 provides a communication structure to connect the physical location 304 to the computing structure 302 and can be implemented as Figure 1 and Figure 2Any of the gateway devices 148, 180 and may include the communication and security features described therewith.

[0230] In general, the enterprise configuration database 306 stores and manages data (i.e., configuration data) from each control system within the plant facility or site 304A, 304B, 304C, as well as any configuration data for control elements implemented in the computing structure 302 of any of the control or automation systems implemented in the physical locations 304A, 304B, 304C. Thus, the enterprise configuration database 306 integrates configuration data from multiple sites or locations 304 of an enterprise into a common database that is generally accessible from anywhere in the enterprise. In some cases, the enterprise configuration database 306 may integrate configuration data for devices and systems across the entire enterprise (i.e., from each of the enterprise's sites 304), and in other cases, may integrate configuration data for devices and systems across a subset of the enterprise's sites 304. In general, the enterprise configuration database 306 stores configuration data in a common framework or uses a common configuration data schema that uses a single data model to manage and understand the types of configuration data from the various different locations, sites, control and automation systems, etc., to which the configuration data belongs, as well as the interrelationships between the configuration data. Additionally, enterprise configuration database 306 and enterprise database services 310 allow users to configure, debug, diagnose, and track configurations across multiple sites 304 (or portions of sites 304). Enterprise configuration system 300 also allows users to develop standardized classes and then apply those classes across all locations, and enables users to track versions of components across systems, compare performance, and the like.

[0231] In general, an enterprise configuration database services module 310 (also referred to herein as enterprise configuration database services 310) receives and manages reads and writes to the enterprise configuration database 306 and operates to enforce a common configuration data schema or data model when reading from or writing to the enterprise configuration database 306. The enterprise configuration database services 310 may additionally include services (applications, containers, granules, etc.) that track configuration data changes made to the enterprise configuration database 306 (such as what data was changed, who made the change, authorization for the change, time of the change, etc.), schedule changes to be made to the enterprise configuration database 306 or to process control and automation systems implemented at sites 304 (and in some cases at least partially in computing fabric 302), enforce data rules for configuration data stored in the enterprise configuration database 306, send notifications to other users of read and / or write requests made to or from the engineering configuration database 306, and the like.

[0232] The configuration viewer application 312 can be a configuration view and change interface or application that enables a user, such as an enterprise configuration engineer, to access the configuration data stored in the enterprise configuration database 306 to read the data and change the data, i.e., write the configuration data, etc. It should be understood that the configuration viewer application 312 can be any type of configuration viewer application and can operate using any desired configuration data schema or data model. Thus, for example, the configuration viewer application 312 can be a configuration viewer application associated with a traditional process control system, such as the DeltaV Control Studio application, a configuration viewer application that is associated with or uses a known common data model to perform data calls, such as those that use or support the OPC UA communication data model, or a configuration viewer application that uses a common data framework or data model used in the enterprise configuration database 306.

[0233] As described above, the translation services 308 additionally interact with the enterprise configuration database 306 to read from and write to the enterprise configuration database 306 using a common configuration data framework or schema. To this end, each translation service 308 is configured to translate configuration data or data calls received from a local database configuration service 315 from the configuration data framework or data schema used by the local database configuration service 315 (e.g., using the configuration data framework or schema used by the process control or automation system at the associated site 304) into the common configuration data framework or data schema used by the enterprise configuration database 306. Similarly, each translation service 308 is configured to translate configuration data and / or data messages received from the enterprise configuration database 306 from the common configuration data schema or schema used by the enterprise configuration database 306 into the configuration data schema or data schema used by a particular local database configuration service in the local database configuration service 315 (e.g., using the configuration data framework or schema used by the process control or automation system at the associated site 304) before sending the data or messages to the local database configuration service 315 via one of the bridge devices 317. Although the translation service 308 is shown as communicating directly with the enterprise configuration database 306 , the translation service 308 may alternatively communicate with the enterprise configuration database 306 via one or more enterprise configuration database services in the enterprise configuration database services module 310 .

[0234] During operation, Figure 4The configuration system 300 enables a user to view and make changes to configuration data stored in the enterprise configuration database 306 using one or more of the configuration viewing applications 312 directly connected to the enterprise's computing structure 302, in order to view and make changes to the configuration of devices or systems implemented at or in one or more of the physical locations 304 (and / or at least partially within the computing structure 302 itself). As will be appreciated, the configuration viewer 312 can be used to read and write configuration data for any system used at or associated with any of the sites 304. Thus, the configuration viewer 312 can be advantageously used by configuration engineers responsible for the configuration of multiple sites 304. More specifically, when a user at the configuration viewer 312 reads configuration data (which reflects the configuration of process control and automation systems within the enterprise) from the configuration database 306, the configuration viewing application 312 sends a read call or message to one of the enterprise configuration database service modules 310, which then parses the message to obtain or determine which configuration data is being read (in addition to implementing security features, such as determining whether the requester has the appropriate permissions to read the data). To perform this function, the enterprise configuration database service module 310 uses a data model associated with or defining a common configuration data schema to translate the configuration data from the configuration data schema used by the configuration view application 312 into a common configuration framework or data schema. The configuration database service module 310 then accesses and reads the appropriate configuration data from the enterprise configuration database 306, translates that data (again using the common configuration schema data model) into the configuration data schema used by the configuration view application 312, and sends that data to the configuration view application 312.

[0235] Similarly, when a user at the configuration view application 312 wants to write or change configuration data within the enterprise configuration database 306, the configuration view application 312 sends a write call or message to the enterprise configuration database service 310, which then parses the message to obtain or determine which configuration data is being changed or overwritten (in addition to implementing security features, such as determining whether the requester has the appropriate permissions to write or change the data). To perform this function, the enterprise configuration database service module 310 uses a data model associated with or defining the common configuration data schema to translate the configuration data from the configuration data schema used by the configuration view application 312 into a common configuration framework or data schema. The configuration database service module 310 then accesses the enterprise configuration database 306 and writes the appropriate configuration data into the enterprise configuration database 306 using the common configuration data schema. The enterprise configuration database service module 310 also sends a configuration data change message to the appropriate local database configuration service 315 via the appropriate translation service 308 and bridge device 317. The appropriate translation service 308 translates configuration data and configuration data change messages from the common configuration data schema used in the enterprise configuration database 306 into the specific configuration data schema or data format used by the control and automation system at the appropriate site 304. The local database configuration service 315 then applies the configuration changes to the appropriate devices or systems at the site 304 (or associated with the control or automation system at the site 304) to implement the configuration changes. In some cases, the configuration changes may be made to elements associated with the control system of the site 304 and providing control services thereto, such as containers or particles within the computing fabric 302. In such cases, the appropriate translation service 308 may make the configuration changes directly to these elements in the computing fabric, or the local database configuration service 315 may make or apply these configuration changes to the appropriate containers or particles in the computing fabric via an associated bridge device 317.

[0236] same, Figure 4 The configuration system 300 enables users to read and write to the enterprise configuration database 306 using one or more of the local database configuration services 315, so that personnel at sites 304 can view and make configuration changes to components at or used by the control and automation systems at those particular sites 304. In this case, the local database configuration services 315 can be advantageously used by configuration engineers responsible for configuring devices or systems at a single site 304 to make configuration changes locally from that site (e.g., on premises). This feature may be necessary, for example, if the communication connection between the local site 304 and the computing fabric 302 is disconnected or temporarily unavailable when a configuration change needs to be made.

[0237] More specifically, when a user at a local database configuration service 315 reads configuration data (which reflects the configuration of process control and automation systems within an enterprise) from a configuration database 306, a configuration viewing application serving as part of or connected to the local database configuration service 315 sends a read call or message to a translation service 308 associated with the local site 304 via an associated bridge device 317. The appropriate translation service 308 then parses the message to obtain or determine which configuration data is being read (in addition to implementing security features, such as determining whether the requester has the appropriate permissions to read the data). To perform this function, the translation service 308 translates the configuration data from the configuration data schema used by the local database configuration service 315 into a common configuration framework or data schema using a data model associated with or defining a common configuration data schema. The translation service 308 then accesses and reads the appropriate configuration data from the enterprise configuration database 306, translates the data (again using the common configuration data schema or data model) into the configuration data schema used by the local database configuration service 315, and provides the data to the configuration viewing application used in or provided as part of the local database configuration service 315.

[0238] Similarly, when a user at one of the local sites 304 wants to write or change configuration data within a system, device, or software module within the local site or associated with the local site 304, the user can use the configuration view application at the local site 304 to make the configuration change at the local site 304. The local database configuration service 315 then sends a write call or message to the enterprise configuration database 306 to reflect the configuration change. Specifically, when a communication connection exists or is possible, the local database configuration service 315 sends a write call or message to the associated or appropriate translation service 308 via the associated bridge device 317. If no such connection currently exists, the local database configuration service 315 (or bridge device 317) can store the change message to be sent and send the message when a communication connection exists or is possible to the computing structure 302. In any case, when the message is received at the translation service 308, the translation service 308 parses the message to obtain or determine which configuration data is being changed or overwritten (in addition to implementing security features, such as determining whether the requester has the appropriate permissions to write or change the data). To perform this function, the translation service 308 uses a data model associated with or defining a common configuration data schema to translate configuration data from the configuration data schema used by the local database configuration service 315 or a configuration viewing application associated therewith into a common configuration framework or data schema. The translation service 308 then accesses the enterprise configuration database 306 and writes the appropriate configuration data into the enterprise configuration database 306 using the common configuration data schema. As described above, the translation service 308 may access the enterprise configuration database 306 directly, or may coordinate access via one of the enterprise configuration database service modules 310.

[0239] In this way, configuration changes can be made from anywhere in the enterprise, including by users remote from the site 304 where the configuration changes are being made, as well as by users located at the site 304 where the configuration changes are being made, thereby making the configuration system robust. Furthermore, because the enterprise configuration database 306 uses a common configuration data schema or framework for configuration data from one of the different process control and automation systems at the various different sites 304 of the enterprise, the enterprise configuration database 306 enables configuration data for all or some of the different sites 304 (or portions of sites) 304 to be integrated into a single or common database, thereby reducing the need to use multiple different configuration databases using different data models or schemas to manage configuration data across the various different sites. This common framework configuration database 306 enables configuration data to be read from anywhere in the enterprise (e.g., from anywhere in the world), and further enables configuration changes to be made from anywhere in the enterprise (e.g., from anywhere in the world), including by users at the site where the configuration changes are to be applied. In this latter example, configuration changes can be applied to the local control system before the changes are made to the enterprise configuration database 306. This feature enables configuration changes to be made locally even when the centralized configuration database 306 is unavailable to the local site for some reason.

[0240] Furthermore, because the configuration system 300 described herein provides translation services between general-purpose configuration viewing systems that directly access the configuration database via the computing fabric and between configuration systems used at or associated with process control and automation systems at physical locations or sites within an enterprise, the configuration system 300 described herein enables integrated support and use of a large number of different types of configuration viewing applications associated with different types of process control and automation systems, even when these systems utilize different or even distinct schemas, formats, etc. Furthermore, as will be explained in greater detail below, the enterprise configuration database service module 310 and translation services are configured in a manner that enables different types of database technologies or structures to be used as, or a portion of, the enterprise configuration database 306, thereby making the enterprise configuration database 306 robust and easily portable, changeable, or movable within the computing fabric 302.

[0241] Figure 5 Shown in more detail Figure 4 300, and in particular, the enterprise database service module 310 and the translation service 308 are shown in more detail. Figure 5 As shown, Figure 5 The configuration system 300 includes a mobile configuration viewer 312 (which may be a mobile configuration viewer) connected to one of the enterprise configuration database service modules 310A through an API gateway 321. Figure 4Configuration viewer 312). Here, API gateway 321 can be about Figures 1 to 3 Any of the APIs 160, etc., and provide secure communications and security within the computing structure 302. Figure 5 As shown, the enterprise configuration database service module 310 is connected to the enterprise configuration database 306, which is connected to the set of translation services 308 ( Figure 5 Only one translation service 308A is shown in detail in FIG. Figure 4 The translation service 308 is connected to the local site 304 ( Figure 4 (only one of which is shown in the figure), the bridging device has access to data at a physical location or site 304, including configuration data generated or present at the physical location 304, including configuration data from one or more local database configuration services 315 and elements of a control system 318 at the site 304.

[0242] like Figure 5 As shown in greater detail by partially hidden dashed boxes (labeled 310B, ..., 310N), the configuration system 300 includes multiple instances of an enterprise configuration database service module 310, wherein each module 310 is associated with a specific use, such as a specific configuration viewing application 312, a specific translation service 308, etc. Figure 5 As shown by partially hidden dashed boxes (labeled 308B, ..., 308N), the configuration system 300 includes multiple instances of a translation service 308, where each translation service 308 is associated with a specific use, such as a specific site 304 or a specific local database configuration service 315.

[0243] As shown for enterprise configuration database service module 310A, one of the enterprise configuration database service modules 310 includes a communication service or communication layer 322, a domain model layer 324 (e.g., including a data model), and a storage service or layer 326, which in turn connects to the enterprise configuration database 306. Generally speaking, the communication service or layer 322 is a communication interface that interacts with and provides communication with one or more configuration viewers 312 (e.g., via API gateway 321). The communication layer 322 provides a specific communication implementation for a particular configuration viewing application 312 or a particular type of configuration viewing application 312, which hooks into the general processing in the domain model layer 324. The communication layer 322 knows how (including logic) to interpret technology-specific data read and write requests sent from the configuration viewer 312 and how to extract the action (e.g., read request, write request, etc.) and the parameters associated with the action from the data message based on the specific data model or schema used by the configuration viewer 312. The communication layer 322 also knows how or has the logic to take the results (data) from the domain model layer 324 and convert the results into a technology specific format or data schema (and message schema or format) used by the configuration viewer 312 .

[0244] In addition, the domain layer 324 includes a domain data model 328 , which defines or implements a general format data structure for configuration data stored in the configuration database 306 , including various types of data in the model, the meanings of different types of data in the model, the relationships between different types of data (e.g., whether a data structure contains or references other data structures, etc.), the structure of the data, etc. In addition, the domain layer 324 includes business logic 329 , which defines how to navigate and parse the domain model 328 , including the relationships between the data in the domain model 328 .

[0245] The storage abstraction layer 326 handles the specific technology required to implement and track storage in the actual enterprise configuration database 306. The storage abstraction layer 326 stores the logic that knows how to read data from and write data to the enterprise configuration database 306 based on the actual database technology used to implement the enterprise configuration database 306. This includes the addressing scheme, data formatting scheme, physical parameters (e.g., voltage and current), and so on, required to actually implement and manage storage in the database 306 using the specific database structure or technology actually used to implement the database 306. Thus, the storage abstraction layer 326 enables different types of computer-implemented databases using different database technologies to be used to implement or provide the actual enterprise configuration database 306. Using this structure, different types of databases can be used to implement different parts or locations of the enterprise configuration database 306 within the computing architecture 302. Furthermore, the storage abstraction layer 326 enables the configuration database 306 to be migrated to different types of databases using different database technologies by simply changing the abstraction layer 326 within the enterprise configuration database service module 310 for the new type of database technology. Thus, storage abstraction layer 326 enables configuration system 300 to be agnostic to the particular type of database technology used to implement configuration database 306 in computing fabric 302 .

[0246] As described above, each enterprise configuration database service module 310 may include a collection of individual module services configured for a specific technology implementation (with respect to a configuration viewer 312 using the module 310 and a configuration database 306 for storing configuration data). Thus, multiple different individual configuration database service modules 310 may be instantiated to support different types of configuration viewing applications 312 using different communication and configuration data formats or schemas and / or to support different configuration database technologies 306. Thus, a first instantiated service module 310A may include a communication layer that supports a first type of configuration viewer (such as a DeltaV configuration application), and a second instantiated service module 310B may include a communication layer that supports a second type of configuration viewer (such as an OPC UA-enabled configuration application). In this case, the various instantiated service modules 310 will include a common data model 328 as part of the domain layer 324 and will generally include the same business logic 329 for managing configuration data as defined in the domain data model 328.

[0247] In addition, each translation service 308 may include components similar to the enterprise configuration database service module 310. Specifically, each translation service 308 may include a communication layer 330, a domain model layer 332, and a storage abstraction layer 334, which operate similarly to the same components 322, 324, 326, respectively, described above for the enterprise configuration database service module 310. Specifically, the communication layer 330 provides a specific communication implementation for a particular site 304 or a particular local database configuration service 315, which hooks into the general processing in the domain model layer 332. The communication layer 330 knows (has the logic) to interpret technology-specific data read and write requests sent from the configuration database service 315, and how to extract the action (e.g., read request, write request, etc.) and parameters associated with the action from the data message based on the specific data model or schema used by the local database configuration service 315. The communication layer 330 also knows how or has the logic to take the results (data) from the domain model layer 332 and convert the results into the technology specific format or data schema (and message schema or format) used by the local database configuration service 315 or the bridge device 317 .

[0248] Furthermore, the domain layer 332 includes a domain data model, which defines or implements the general format data structure of the configuration data stored in the configuration database 306, including the various types of data in the model, the meaning of different types of data in the model, the relationships between different types of data (e.g., whether a data structure contains or references other data structures, etc.), the structure of the data, etc. Furthermore, the domain layer 324 includes business logic, which defines how to navigate and parse the domain model 328, including the relationships between the data in the domain model 328. Note that because the translation services 308 use the same enterprise configuration database 306, these services 308 use the same domain model 328 and business logic 329 as those used in the enterprise configuration database service module 310.

[0249] In a similar manner, the storage abstraction layer 334 of the translation service 308 handles the specific technology required to implement and track storage in the actual enterprise configuration database 306. The storage abstraction layer 334 stores the logic that knows how to read data from and write data to the enterprise configuration database 306, including the addressing scheme, data format scheme, physical parameters (e.g., voltage and current), etc. required to actually implement and manage storage in the database 306 using the specific database structure or technology actually used to implement the database 306 or a portion of the database 306 that stores configuration data for the associated site 304. Likewise, the storage abstraction layer 334 of the translation service 308 is generally identical to the storage abstraction layer 326 of the enterprise configuration database service module 310, as it connects to the same configuration database.

[0250] Please note that Figure 5The translation service 308 is shown as being directly connected to the enterprise configuration database 306 to interact directly with it. However, in another embodiment, the translation service 308 may be connected to different enterprise configuration database service modules 310 and access the configuration database 306 via these service modules 310. In this case, the translation service 308 may include a communication layer 330, which is then connected to or communicates with the domain module layer 324 of the associated enterprise configuration database service module 310 to which the translation service 308 is connected, and the translation service 308 performs the basic functions of the communication layer 322 described above for the enterprise configuration database service module 310. In this example, all communications with the enterprise configuration database 306 are performed via the enterprise configuration database service module 310. Therefore, the translation service 308 is referred to as a subset of the enterprise configuration database service 310 in this article. In addition, in this case, different instantiated service modules 310 can be created for different translation services 308 and used with or to support different translation services. Of course, as described above, different translation services 308 will include different sets of rules for converting between the configuration data schema used in control and automation systems at various different physical locations or sites 304 and the common configuration data schema used in configuration database 306 .

[0251] In any case, similar to how different instantiated enterprise configuration database services 310 support various different configuration viewers 312 that may use different configuration data formats or data schemas, different translation services in the translation services 308 may support different sites (e.g., different process or automation equipment) that use different configuration data formats or schemas. Thus, the translation services 308 and the various enterprise configuration database service modules 310 enable the use of a common or single enterprise configuration database 306 to store configuration data for many, if not all, process control and automation systems associated with an enterprise, even if these process control and automation systems are located in different geographic locations that may include different types of process control and automation system components (e.g., equipment, control systems, etc.) that may be manufactured by completely different manufacturers and may use significantly different data formats or configuration data schemas.

[0252] Additionally, configuration service 310 (and translation service 308) may include other services that provide other management functionality with respect to configuration data, and in particular with respect to reading, writing, and changing configuration data in enterprise configuration database 306. These services are described in Figure 5306 , a tracking or tracing change service 342, and a scheduling service 344, although other management and support services may also be provided or provided instead. Specifically, the change management service 340 can manage or supervise the reading and writing of the enterprise configuration database 306, including enforcing rules on the ongoing reading or writing, such as enforcing rules related to data size, data read and write limits, timing of data reads and writes, managing data read and write queues, managing and implementing data read and write priorities (e.g., applying rules related to implementing priorities within data reads and writes), etc. In addition, the change management service 340 can identify when a user makes changes to the configuration database 306 using the viewer 312, and can coordinate those changes and send them to the appropriate devices, systems, etc. at the physical location 304 to implement those changes to the actual system to which the configuration changes are to be applied. In addition, the tracking change service 342 can store data that tracks changes made to (or even reads from) the enterprise configuration database 306, including when the change (or read) was made, the requester or user (by name or role) of the read or write, the permissions for the read or write, the reason for the change (or read) (e.g., as provided by the user), etc. The tracking change service 342 can store a list of changes made to the database 306, including any of the above information, and provide it to users at a later time so that those users can see the details and timing of the changes made to (or reads from) the configuration database 306. In addition, the scheduling service 344 can schedule changes to be made to the configuration data in the database 306 or reads from the database 306 to control the accessibility of the database 306 and can, for example, implement batch changes at specific times to manage how and when changes are made to the database 306. In a similar manner, the scheduling service 344 can schedule configuration changes to be made to devices and systems within or at a site 304, individually or in a batch or coordinated manner, to make a series of changes in a particular order, or to ensure that a collection of configuration changes are implemented together or simultaneously. The scheduling service 344 can, for example, schedule changes to be made to a particular plant or location (or to a subset of locations, such as a zone, unit, device, etc.) at a particular time or in a particular order, can schedule a group of changes to be sent together to reduce overhead, and to ensure that configuration changes are all implemented together in the plant, to accommodate lost or unavailable communication connections between the computing structure 302 and the plant or site 304, etc., because it cannot always be assumed that a communication connection between the plant and the computing structure 302 will always exist or for other reasons. Of course, other configuration support services may alternatively or similarly be provided in the service module 310 and the translation service 308.

[0253] To better understand this article about Figure 4 and Figure 5The operation of the configuration system 300 is described herein. Figure 6 and Figure 7 Describes the configuration database data model (such as Figure 5 328) of the data model 328) of the example data model layout or composition, and will be about Figure 8 and Figure 9 Describes an example control module configuration data schema (or data model). As will be understood, these data models define the data available in the model, including names and uses, and define the relationships between the data in the model. However, it should be noted that Figures 6 to 9 The general data model layout of is merely an example, and other data layouts or organizational structures may alternatively be used as the general configuration data schema.

[0254] Likewise, for example, configuration database 306 may use data model 350 (which may be Figure 5 A data model 328) includes or supports many different related aspects or data structures. Figure 6 An example data model 350 is shown that includes multiple related facets, including a site facet 352 containing zero, one, or more library components 354 , zones 356 , process control equipment 358 , and safety projects 360 . Figure 6 The darker lines used in the examples (such as the line between the site plane 352 and the library plane 354, the zone plane 356, the process control equipment plane 358, and the safety project plane 360) indicate inclusion, such that in this example, the site plane 352 may include zero, one, or more library planes 354, zero, one, or more zone planes 356, zero, one, or more process control equipment planes 358, and zero, one, or more safety project planes 360. Similarly, Figure 6 The lighter lines between the various faces in the diagram indicate that these interconnected faces can reference each other (but are not contained by each other). Figure 6 As shown, each library facet 354 may contain one or more equipment model definitions 362, control module definitions 364, I / O module definitions 366, device definitions 368, and compounds or classes 370. Generally speaking, the library facet 354 and its subcomponents 362-370 define common versions of various library components that may be stored in the configuration database 306 and provide common definitions for these components. Figure 6 In the case of , the library subcomponents define different types of equipment modules, control modules, I / O modules, devices, and composites and classes. Figure 6As shown, the area 356 (which can implement the control strategy) can include one or more units 372, each unit can include one or more equipment modules 374, and each equipment module can include one or more control modules 376. At least some of these elements are instantiated versions of library elements and are therefore associated with specific equipment, control logic, systems, sites, etc. of the enterprise. Figure 6 As will be appreciated, the control module 376 may reference specific existing I / O blocks 378 and field devices 380. Likewise, according to Figure 6 In the data model of , each process control equipment plane 358 may include one or more networks 382 (defining communication networks within or associated with the enterprise), which may include one or more network devices 384, which may include one or more subsystems 386, which may include one or more physical I / O planes 388 (devices, cards, etc.). Similarly, the security plane 360 ​​may include one or more users 390, which may be defined as people, roles, or any combination thereof, or defined in any other way. In addition, as will be seen through Figure 6 As can be understood from the lighter connecting lines in the data model, each facet in the facet can reference other faces in the facet to define a looser relationship between the faces in the data model. For example, the equipment module 374 and the control module 376 can reference the network device 384 (and therefore be associated with the network device), and the I / O block facet 378 can reference the physical I / O facet 388. Of course, Figure 6 Other reference pairs are shown in . In general, data model 350 defines the various types of elements that can exist in the model and the relationships between them, and can be used as a common data framework for storing and accessing any type of configuration data within an enterprise.

[0255] As will be understood, engineering a process control or automation system involves configuring Figure 6 For example, control operations within an enterprise are engineered using control module definitions 364 and actual instantiated control modules 376, which, by way of example only, may include functional block diagrams, sequential flow charts (SFCs), units, equipment, and, in the case of batch control, processes and operations. Batch control may also include recipes (not in Figure 6 In the past, these control systems were typically engineered individually and separately within an enterprise, either locally (e.g., at a physical location) or in the cloud (one system at a time), and then the configurations were deployed locally. Once the systems were commissioned and running, the configurations were maintained in local configuration databases at each site or location. However, using the configuration system described herein, control and automation systems can be engineered, commissioned, and maintained from a computing infrastructure (e.g., in the cloud), locally, or using a combination of both.

[0256] By way of example only, the following description assumes that a common configuration data model for configuring or defining the configuration of a control system uses control modules and control module configurations. Typically, the well-known S88 hierarchy defines control modules that are commonly used in process control and automation systems, and the hierarchy includes modules in the form of sites, zones, unit modules, equipment modules, and control modules. However, in order to fully support the configuration activities of the entire enterprise as described herein, and in order to create a data model for the entire site, it is advantageous to extend the S88 hierarchy to include some additional modules and module definitions. Specifically, Figure 7 An expanded S88 hierarchy 400 is depicted, including additional modules that relate to or define modules within the enterprise's control hierarchy. Figure 7 The lines connecting modules in the 400 indicate which modules may contain other modules. More specifically, the hierarchical structure 400 includes enterprise modules 402 (which are the companies or legal entities that own, operate, use and / or access the various modules below them). Each enterprise module 402 may contain one or more department modules 404, each of which defines some technical or business unit of the enterprise 402. A department 404 may be a business unit of the enterprise 402, a technical area of ​​the enterprise 402, or any other logical unit of the enterprise 402 defined in any way. Of course, as Figure 7 As shown, each sector 404 may include one or more region modules 406. Each region 406 may be a geographic or geopolitical region, such as a country, continent, state, or local area. Regions may be, but are not necessarily, geographically contiguous in nature. Thus, for example, Alaska and Hawaii may be part of the United States region.

[0257] like Figure 7 As shown, each area 406 may include or contain one or more site modules 408. Each site module 408 defines a particular site or location (or portion of a site or location) of an area 406 of a department 404 of an enterprise 402. For example, each site module 408 may be used to define or implement the scope of a single or separate control system (such as a DeltaV control system). Each site module 408 may include or contain one or more zone modules 410, which are uniquely named or labeled and which define a physical zone at the site 408, such as a building, room, pad, skid, or any other geographic area associated with a particular site 408. In addition, as Figure 7As shown, each zone 410 may include or contain zero, one or more of each of the following: a unit module 412, an equipment module 414, and a control module 416. As is known, a unit module 412 is associated with a specific unit (equipment set) in a zone (and is therefore uniquely named at least in that zone) and may contain zero, one or more equipment modules 414. Control of the unit modules 412 is typically described in terms of SFCs. The equipment modules 414, which may contain other equipment modules 414, control modules 418, and function blocks, define control of a subset of the equipment in the unit modules 412. This control is typically described in terms of SFCs and function blocks. Finally, the control modules 416, which may contain other control modules 416, may also include or contain function blocks and perform lower-level control functions.

[0258] As will be appreciated, the module hierarchy 400, extended with the enterprise module 402, the department module 404, and the region module 406, enables configuration data for different enterprises, different departments of an enterprise, and different regions of an enterprise to be stored in the same directory. Figure 4 and Figure 5 The configuration data from different sites of an enterprise can be stored in a common database and managed and viewed at the enterprise level.

[0259] In another example, a functional block module (such as Figure 7 Function block modules (those used in ) can consist of function blocks such as analog input (AI), analog output (AO), digital input (DI), digital output (DO), PID, and other blocks. Function block modules also include parameters and links that connect function blocks and properties (also called parameters). These links show signal flow and other content and can reference I / O and other devices. Figure 8 An example configuration data model 420 for a functional block is shown, which includes elements (shown on the left) organized into various different levels or organizational structures (listed on the right) separated by dashed lines. Figure 8 The configuration data model 420 of the control module includes an organization level 422, a primitive level 424, a definition and use level 426, an instance level 428, and a device level 430. Here, the organization level 422 includes site elements 432, the primitive level 424 includes functions 434 and parameters 436, the definition and use level 426 includes definitions 438, the instance level 428 includes plant areas 440, modules 442, attributes 444, and PIO blocks 446, and the device level 430 includes devices 448 and I / O 450. The various elements 432 to 450 are related to and connected to each other, as shown by the lines between these various elements.

[0260] Generally speaking, the organization level 422 contains all the "named items" in the system organized by site, such as user accounts, libraries, and other site-wide information. Examples of named items include block definitions, equipment module definitions, control module definitions, plant area names, events, function block names, etc. The primitive level 424 includes the low-level primitives used in the control hierarchy, such as functions 434 and parameters 436. Functions 434 are the lowest level functions in the system. For example, the collection of function blocks in the system are all primitives. Primitive functions have a site-wide name scope. Parameters 436 are the lowest level data in the system. Parameters can be integers, real values, vectors, arrays, etc. Attribute values ​​are mapped to parameters so that they can be used within functions. The definition and use level 426 defines the algorithms and interfaces for function blocks, control modules, equipment modules, units, links, and attributes, and represents or defines the use of one definition within another.

[0261] Instance level 428 defines or includes the actual "tags" or instantiated items in the system. For example, each of plant area 440, module 4442, attribute 444, and PIO block and device 446 is an instance with a tag (e.g., a unique identifier). Instances are generally based on the definitions of definition and usage level 426. More specifically, plant area 440 represents a geographical or logical segment of a process site. Process areas have names. Modules 442, which are module instances, are installable items that can be organized by control strategy. Attributes 444 are visible parameters in a module, device, etc. They can be used for input, output, or data storage. PIO block 446 is an abstraction that represents various I / O devices, networks, and fieldbuses.

[0262] The device level 430 represents the physical process control equipment associated with a plant or site (e.g., devices 448 and I / O 450). Devices 448 are process control equipment in the plant (at the site) and may include controllers, I / O devices, field devices, workstations, consoles, etc. I / O elements 450 are the physical process I / O in the system or site and include measurement devices such as sensors and control devices such as valves, as well as other types of field devices.

[0263] As described herein, additional details of a data model based on the module concept may include a data model for each type of control module within the data model. Specifically, each module may include a module type, module parameters (such as a name, ID, etc.), and links connecting the module to other modules (where such links may define include or reference relationships between modules). As an example, a function block module is a type of module that can be configured in the data model of the configuration system described herein. A function block module is composed of function blocks such as AI, AO, PID, and other blocks, and is further composed of parameters and links connecting the function blocks and attributes.

[0264] Figure 9 An example control module domain model 460 is depicted that may be used as part of a data model in the configuration database 306 to define the control modules (which may include function blocks) available in the configuration database 306. Figure 9 As shown, the control module model 460 includes various blocks defining possible features or components of the module connected with lines defining the interrelationships between the components. Figure 9 A line starting with a diamond in indicates that the component with the diamond adjacent to it may be included in the component at the other end of the line (with an arrow). Figure 9 Lines without diamonds indicate references between components.

[0265] Therefore, if Figure 9 As shown, the control module domain model 460 may include one or more modules 462, each of which may include various parameters such as zone path, assigned node ID, category, (its assigned) controller, detail display, instrument zone display, whether the field is deleted, whether it is a template module, last modified date, last modified user, library path, model class ID, parent equipment ID, parent module name, period (update rate), main control display, subtype, supporting class modules, label, type, attribute, function block algorithm, function block and historical data points, and any other desired type of parameters. Figure 9 As shown, each module element 462 may include a module header 464, which includes an ID, name, type, path, and description. Furthermore, module 462 may include one or more function block uses 466, which may include a definition, a definition ID, a description, an ID, a name, one or more attribute uses, a connector, one or more extensible attributes, and parameters for a rectangle used in the display (which may indicate a graphical element). Furthermore, module 462 may include one or more attribute elements 468, which may include a data type, a definition name, a field value, an indication of whether it is extensible, an indication of whether it is inherent, a path (e.g., a communication path indication), an indication of whether the value can be overwritten, a category, parameters for the field, and the rectangle. Furthermore, module 462 may include one or more function block algorithm elements 470, which may include graphics and lines. Furthermore, function block algorithm elements 470 may include line elements 472, which may include parameters for the destination and source, as well as line segments. Each line element may include one or more line segments 474, each line segment having parameters for an index, a ordinate, and an orientation.

[0266] In addition, the function block usage 466 may include an extension count element 476 (shown with parameters for name and count), a connector 478 (shown with parameters for name and attribute name), and a rectangle element 480 (shown with parameters for X and Y coordinates and height, defining a graphic element such as a rectangle). In addition, the attribute element 468 may also include a rectangle element 480 and one or more field elements 482 and one or more sub-item headers 484. The field element 482 may include an attribute type, a data type, a definition name, an enumeration name, an indication of whether it is a construction parameter, an indication of whether it is a read-only field, an item ID, a name, a path, a value, an indication of whether the value can be overwritten, and parameters for associated fields and attribute fields. In addition, as Figure 9 As shown, field elements 482 can reference other fields and can reference attribute field elements 486 (which can include attribute paths, attribute types, and parameters for the field). Figure 9 As shown, each of the function block usage element 466, extension count element 476, connector element 478, attribute element 468, field element 482 and function block algorithm element 470 may include one or more sub-item header elements 484 (which may include parameters of ID, name, type and path).

[0267] Of course, please note that Figure 9 The control module domain model 460 is only one example of a domain model that defines the elements, parameters of the elements, and relationships between the elements in the control module of the configuration data model. Other data models may also be used or used instead.

[0268] As mentioned above, Figure 4 and Figure 5The enterprise configuration database service 310 includes or is composed of various instantiated module configuration service modules (310A, 310B, etc.) that are operable to interact with the configuration database 306, which contains module configuration data defined in, for example, a data model as described herein. Configuration data (e.g., for control modules) is accessed from a computing fabric-based application such as a configuration viewer 312 and synchronized with a local configuration system 315 via one of the translation services 308. Translation services 308, of course, convert data from data providers into a common form suitable for the domain model used in the enterprise configuration database 306. Furthermore, as described above, a bridge device 317 connects the local database configuration service 315 and other data sources to the configuration framework provided and used in the configuration database 306. Generally speaking, the bridge device 317 enables the configuration of a legacy control system at a site 304 to be migrated to the configuration database 306. The bridge device 317 performs this action by replicating the local configuration to the associated cluster in the computing fabric 302 and managing changes originating from the legacy system (via the local database configuration service 315) or from the computing fabric 302.

[0269] The bridge device 317 can be configured to implement enhanced or efficient communication between the local site 304 and the computing structure 302 using another data model or configuration schema designed to gain access to information in the local database (via the local database configuration service 315), wherein the other data model is designed to be very general, with the flexibility to perform more typing when needed. Specifically, the data model used by the bridge device 317 preferably supports any local process control system schema, including its different versions, including the ability to send the correct amount of data at any given time, including the ability to support change deltas (create, update, delete), and does not hinder the overall performance of the local system.

[0270] To achieve these advantages, the bridge device 317 may be configured to Figures 10A to 10C The described approach maps communications from a local configuration or process control system (at one of the sites 304) into information packets to perform efficient communication between the local process control or automation site 304 and the computing structure 302 or the translation service 308 in the computing structure 302. For example, Figure 10AAs shown, the bridge device 317 can use a communication data model 500 that enables various different types of configuration data from the local site 304 to be mapped into a common configuration data schema used by the enterprise configuration database 306, and vice versa. In particular, the data model 500 converts local data elements into item information, shown as a generic ItemInfo element 502, which can receive or request data related to various different types of data at the site 304 or in the configuration database 306. Figure 10A As shown, the general ItemInfo element 502 can receive or obtain information related to any of the various data model categories, including module information, equipment information, node information, I / O channel information and device signal tag information, which are respectively shown as ModuleInfo element 504, EquipmentInfo element 506, NodeInfo element 508, IOChannelInfo element 510 and DeviceSignalTag element 512.

[0271] Now, Figure 10A Each of the various elements 504 to 512 may have or may be connected to or may contain various sub-elements in the data model to be used. For example, Figure 10B 504 ). In this case, a general ItemInfo element 502 (which may be a collection of data) may be obtained from or via the ModuleInfo element 504. Figure 10B As shown, the data available for or obtained through the ModuleInfo element 504 may include (module) characteristic information, (module) attribute information, (module) project information, and (module) historical data points. Figure 10B 528. As will be appreciated, the ModuleInfo element 504 includes each of one or more elements 522-528. In addition, as shown, the AttributeInfo element 524 may include Figure 10B One or more fields or field information shown in as FieldInfo element 530. Similarly, EquipmentItemInfo element 506 can contain ModuleInfo element 504.

[0272] In any case, based on the database model 520, any information from any of the elements 504, 506, 522, 524, 526, 528, 530 can be obtained from the local site 304 (or from the enterprise configuration database 306) as a generic ItemInfo element 502. This data mapping enables support of local configuration data schemas (such as those used at any site 304) in a very generic manner, with the flexibility of stronger data types when needed. Generally speaking, the generic portion of the data model 520 is based on receiving a combination of data (e.g., data triplets) from various different elements in the model 520 (e.g., ItemInfo 526, PropertyInfo 522, and AttributeInfo 524) as data received or used in the generic ItemInfo element 502. However, stronger data types can be used when needed (e.g., obtaining information from elsewhere in EquipmentItemInfo 506, ModuleInfo 504, FieldInfo 530). Typically, the combination of data requested or obtained in the generic ItemInfo element 502 may be preset or predetermined, for example, as particular information triplets (or other quantities of information), because these types of data are expected to be requested or used together in a large number of data access operations (because in many cases, fixed or common sets of data are required, or used in conjunction with business rules that are essential to process control operations at site 304).

[0273] Thus, a triple-based access model (or any other number of data item accesses, e.g., two, four, six, etc.) allows for fine-grained control over how much data is sent during data access operations via the generic ItemInfo element 502. For example, when a configuration application (such as a DeltaV Explorer-type application) attempts to build its tree to enable viewing of the configuration, the application may retrieve only several types of "header" data (i.e., equipment items and modules in this case), and not the "body" of the data. The "header" data in this case is Figure 10B Of course, when other data is needed, the application can then request that other, more specific data.

[0274] In another example, when a configuration application, such as a DeltaV Control Studio type application, opens a module, the application can retrieve the properties and function block usage required to render the module. Figure 10BThe "header" of the block (AttributeInfo and ItemInfo in the figure) is used. When a user clicks a function block, the "href" attribute of the "header" allows the application to directly retrieve the body of the block. Most use cases that require data retrieval require a significant subset of the configuration data stored in the database. This triple-based communication model allows the precise amount of data required by different use cases to be sent together in an automated manner. This communication structure reduces network utilization and storage I / O at the expense of slightly increased CPU utilization.

[0275] Figure 10C Another data model 540 is shown that can be used to Figure 10A NodeInfo element 508 obtains node information data. Specifically, in model 540, NodeInfo element 508 contains historical data point information and I / O subsystem information, which are shown as HistoryDataPointInfo element 542 and IOSubsystemInfo element 544 respectively. Similarly, IOSubsystemInfo element 544 contains one or more I / O card information (IOCardInfo element 546), each of which contains I / O channel information (IOChannelInfo element 548), and each of which contains device signal tag information (DevieSignalTagInfo element 550). Similarly, in a similar manner, when requested from the local system, any set or subset of predetermined information, such as a triplet, can be obtained in a general manner via NodeInfo element 508 to make communication more efficient.

[0276] Of course, other or similar data models can be used Figure 10A Each of the elements 504 - 512 of to enable the bridging device 317 to perform efficient and very targeted communications between the local site 304 and the computing fabric 302 .

[0277] Furthermore, to enhance communication, the bridging device 317 may use change sets and change deltas in the form of records to communicate changes to be made to the local system 304 (from the computing fabric 302 ) or to the enterprise configuration database 306 when made at the local system 304 . Figure 11 560 is shown as a data or communication model that can be used at the bridge device 317 to manage changes and transmit changes. Specifically, the communication model 560 includes a change set (ChangeSet element 562), each change set can contain one or more change records (ChangeRecord element 564), and each change record can contain one or more item information elements (ItemInfo element 568). Here, the ItemInfo element 568 can be mapped to Figure 10AThe general ItemInfo element 502 of the change record 564 or change set 562 contains a Figure 10A 566 。

[0278] In some cases, when applying changes to the local configuration database at site 304, the bridge device 317 can impersonate the user specified in the change record 564 so as to have security credentials to make the changes. In addition, the change sets 562 can be maintained by the bridge device 317 throughout the lifecycle of a particular local database until these change sets 562 are pruned by user action. The change records 564 can be organized using their ItemInfo "header" and a baseline of the change records 564 can be created during the first initialization of the configuration management device or application at the local site 304. The baseline of the ItemInfo and the change record together reflect the change history of the ItemInfo.

[0279] Furthermore, change records originating from any source, local site 304, or computing fabric 302, can be saved locally (i.e., saved at site 304) before they are sent to computing fabric 302 or committed to the local configuration database, respectively. The former is required because one cannot assume that connectivity to computing fabric 302 will always be available, for example, when making configuration changes locally. The latter is required because one cannot assume that the local database, or the items being changed in the local database, will always be accessible. For example, someone may have a long lock on an object in the local database.

[0280] An advantage of maintaining a record of changes from either or both the local site 304 and the computing fabric 302 is that it enables the bridge device 317 to perform merges / changes and conflict detection. For example, if two different users modify the same ItemInfo, PropertyInfo, and / or AttributeInfo, the bridge device 317 can detect the conflict and develop a predetermined resolution process to manage or resolve the conflict. The bridge device 317 can also or alternatively merge changes, for example, in the order in which they were received or made or based on the time at which the changes were made, to reduce the need to make multiple changes to the same element or to combine changes to related elements, thereby reducing the size or number of change records 564 in the change set 562.

[0281] As will be appreciated, the configuration system 300 described herein manages access to the configuration of various elements of an enterprise from a centralized location. Specifically, during installation, a user role with the ability to modify the installation directory at the local site will be required to install the system, as the bridge device 317 will need to have its data elements managed or added to the same directory as the local database server. Then, after installation, the bridge device 317 will need to register with a service (e.g., translation service 308) within the computing fabric cluster associated with the local site 304. This operation may require a user role with permissions to do so (i.e., one that has access to user and / or role permissions assigned within the computing fabric). A token is generated during this registration process, and this token can subsequently be used to identify and authenticate the bridge device 317 and its cluster within the computing fabric 302, and this token is used to secure future communications between the bridge device 317 and the appropriate computing fabric cluster. Furthermore, during data access operations, the bridge device 317 will need to orchestrate and implement users and permissions for security purposes, such as security permissions for Windows, for the process control system at the local site 304, and for the computing fabric system.

[0282] As will be appreciated, the configuration system 300 described herein enables an enterprise to store configuration data in a central location for both local devices and systems (e.g., at local sites 304) and applications or components used or executed in the enterprise's computing fabric 302 using a common configuration data format or schema (i.e., using a common data model). This feature enables enterprise users to more easily maintain corporate standards and manage the rollout and updates of configurations (e.g., different configuration versions) centrally or in a coordinated manner because configuration data changes made to the central configuration database 306 can be timed and grouped together and automatically made or rolled out together to systems and components at local sites 304, as well as to system components executing in the computing fabric 302. Also, as described above, users can process, view, manage, and change configuration data associated with any system within the enterprise (and, therefore, the configuration of the system) from any location in or associated with the enterprise, or from anywhere in the world where a connection to the computing fabric 302 exists. Furthermore, the enterprise configuration system 300 described herein enables users to manage, compare, and support configurations for many different sites, even for many different types of systems using different configuration data formats or data models at different sites or different parts of the same site. For example, the enterprise configuration system 300 described herein can simultaneously support classic or legacy control systems, such as DeltaV control system configurations, future control systems, and emerging systems using OPC UAFX, as well as other systems that may use different configuration data schemas. Similarly, the enterprise configuration system 300 described herein enables users at an enterprise to partition configurations and configuration data into departments, regions, and sites, as well as lower-level categories such as zones, unit modules, and the like, and to synchronize configurations in both directions (from the compute fabric and from local sites) using change sets. Furthermore, the enterprise configuration system described herein enables centralized authorization and authentication to access and / or change an enterprise's configuration data. Furthermore, the enterprise configuration system 300 described herein enables enterprises to use a compute fabric-based (e.g., cloud-based) configuration tool that can work with an enterprise configuration service.

[0283] In addition, due to the decentralized and highly configurable nature of the computing structure of the NGPCAS described herein, the NGPCAS for a specific enterprise can be configured or set up by the enterprise to enable new types of data management and execution management to be performed within the computing structure, which enables the enterprise to uniquely configure global or intra-plant data flows and execution management in a way that was not possible with previous control systems. Specifically, the computing structure of an enterprise with multiple physical plants or locations can be established in a hub and spoke configuration, where multiple different computing structure "hubs" can be created to support various different physical locations or plants connected to the hub via a communication network that implements communication "spokes". Each center can have computing resources that are limited to or implemented in a specific geographic or sovereign region. These regions can be, for example, continents (e.g., North or South America, Europe, Africa, etc.), countries (e.g., the United States, Russia, China,...

Claims

1. An enterprise configuration system for viewing and changing the configuration of an enterprise system, the enterprise system having a computing structure communicatively connected to one or more plant sites, each plant site having one or more control or automation system components located therein, and the computing structure including computer devices that implement computer-implemented elements for the one or more plant sites, the configuration system comprising: an enterprise configuration database stored and executed in the computing structure of the enterprise to store configuration data for components of each of the one or more plant sites; a configuration support viewing application executing on a computing device, the configuration support viewing application accessing data from the enterprise configuration database via a connection through the computing fabric to the enterprise configuration database; one or more local configuration systems, the one or more local configuration systems stored at each of the one or more plant sites, each local configuration system comprising one or more local database configuration services for viewing or changing configurations of the components of the control or automation system at the plant site; and a set of enterprise configuration database services stored in and executed in the computing structure, the set of enterprise configuration database services (1) interacting between the enterprise configuration database and the configuration support viewing application to enable the configuration support viewing application to view and change the configuration of the one or more local configuration systems at each of the one or more physical sites, and (2) interacting between the enterprise configuration database and the local database configuration support service at each of the plant sites to enable each of the local database configuration support services to view and change the configuration data of the plant site at which each of the local database configuration support services is located. 2 . The enterprise configuration system of claim 1 , wherein each of the local database configuration support services comprises a local configuration database that stores configuration data of the plant site where the local database configuration database is located.

3. An enterprise configuration system according to claim 1, wherein the enterprise configuration database stores the configuration data of each of the plant sites in a first configuration data mode, and at least one of the one or more local database configuration support services uses the configuration data of the plant site using a second configuration data mode that is different from the first configuration data mode.

4. An enterprise configuration system according to claim 3, wherein the enterprise configuration database service set includes a first subset of configuration database services that interact with the configuration support viewing application, and includes a translation service set, wherein at least one translation service in the translation service set interacts between the enterprise configuration database and one of the local database configuration support services and operates to translate configuration data between the first configuration data schema and the second configuration data schema used at the factory site.

5. The enterprise configuration system of claim 1 , wherein one or more of the enterprise configuration database services include an interface layer that interacts with the configuration viewing support application, a domain model layer that stores a data model associated with the first configuration data schema, and a database abstraction layer that interacts with the enterprise configuration database to store configuration data in and read configuration data from the enterprise configuration database.

6. The enterprise configuration system of claim 5 , wherein the enterprise configuration database comprises a plurality of different database components using different database storage technologies, and wherein the abstraction layer for a first configuration database service supports use of a first database storage technology, and wherein the abstraction layer for a second enterprise configuration database service supports use of a second database storage technology that is different from the first database storage technology.

7. The enterprise configuration system of claim 5, wherein the domain model layer translates between a first configuration data schema associated with the data model and a second configuration data schema associated with the configuration support viewing application.

8. The enterprise configuration system of claim 7, wherein the communication layer interacts with the configuration view application using the second data schema and the messaging schema of the configuration view application.

9. The enterprise configuration system of claim 8, wherein the communication layer extracts configuration data sets and actions from messages from a configuration support viewing application using the second configuration data schema of the configuration viewing application, and creates one or more messages to the configuration support viewing application by creating messages including configuration data using the second configuration data schema of the configuration support viewing application.

10. An enterprise configuration system according to claim 1, wherein the enterprise configuration database service set includes a translation service set, wherein each translation service in the translation service set interacts between the enterprise configuration database and one of the local database configuration support services, and operates to translate configuration data between a first configuration data schema used in the enterprise configuration database and a second configuration data schema used at a factory site.

11. The enterprise configuration system according to claim 10 further comprises a bridging device, which is arranged between the local database configuration service at a specific factory site and the translation service for the factory site, wherein the bridging device marshals the communication between the local database configuration service at the specific factory site and the enterprise configuration database.

12. The enterprise configuration system of claim 11, wherein the bridging device stores and implements security authorizations to enable communication between the local database configuration service at the particular plant site and the enterprise configuration database in the computing fabric.

13. The enterprise configuration system of claim 11, wherein the bridging device encapsulates configuration data in messages for transmission between the local database configuration service at the particular plant site and the enterprise configuration database in the computing fabric.

14. The enterprise configuration system of claim 11, wherein the bridging device uses a data model comprising a hierarchical data format, and wherein the bridging device develops messages comprising data from a plurality of different elements of the hierarchical data format.

15. The enterprise configuration system of claim 14, wherein the bridging device automatically groups the various different data from the different elements of the hierarchical data format to create a data message.

16. The enterprise configuration system of claim 11, wherein the bridging device manages changes to an enterprise configuration database using change messages, the change messages comprising a plurality of changes to the configuration data in the configuration database.

17. The enterprise configuration system of claim 16, wherein the bridge device develops a change message comprising change sets, each change set having one or more change records associated with one or more configuration changes.

18. The enterprise configuration system of claim 17, wherein each change set is associated with a plurality of changes to the configuration data.

19. The enterprise configuration system of claim 1 , wherein the configuration database service comprises one or more additional services that manage changes to the enterprise configuration database by storing and implementing one or more rules associated with changes to the configuration database, and that use the one or more rules to analyze one or more changes to the enterprise configuration database.

20. An enterprise configuration system according to claim 1, wherein the configuration database service includes one or more additional services that manage changes to the enterprise configuration database by automatically coordinating changes to the enterprise configuration database and implementing changes to one or more elements at a plant site associated with the changes to the enterprise configuration database.

21. An enterprise configuration system according to claim 1, wherein the configuration database service includes one or more additional services that track changes to the enterprise configuration database by automatically storing information about changes made to the enterprise configuration database, the information including one or more of the following: who made the configuration change, the time of the configuration change, the reason for the configuration change, and authorization for the configuration change.

22. An enterprise configuration system according to claim 1, wherein the configuration database service includes one or more additional services, which coordinate the implementation of changes to the enterprise configuration database or changes to the configuration of the elements at the plant site by coordinating the timing of multiple changes made to the enterprise configuration database or the elements at the plant site.

23. The enterprise configuration system of claim 1, wherein the enterprise configuration database uses a data model that stores and organizes configuration data by enterprise region, each enterprise region including one or more plant sites.

24. The enterprise configuration system of claim 1, wherein the enterprise configuration database uses a data model that stores and organizes configuration data by enterprise department, each enterprise department including one or more plant sites.

25. The enterprise configuration system of claim 1, wherein the enterprise configuration database uses a data model that stores and organizes configuration data of an enterprise having a plurality of plant sites by storing and managing configuration data of each of the plurality of plant sites.

26. The enterprise configuration system of claim 1, wherein the configuration database service includes one or more additional services that perform a search of the enterprise configuration database to search for configuration elements according to provided search criteria.

27. The enterprise configuration system of claim 26, wherein the one or more additional services search for configuration elements across a plurality of different physical sites.

28. The enterprise configuration system of claim 26, wherein the one or more additional services search for configuration elements across multiple different areas of the enterprise.

29. The enterprise configuration system of claim 26, wherein the one or more additional services search for configuration elements across multiple different departments of the enterprise.

30. An enterprise configuration system for viewing and changing the configuration of an enterprise system, the enterprise system having a computing structure communicatively connected to multiple city plant sites, each plant site having components of one or more different control or automation systems located therein, including a first plant site having a first process control or automation system using a first configuration data schema and a second plant site having a second process control or automation system using a second configuration data schema, and the computing structure including computer devices implementing computer-implemented elements for the one or more plant sites, the configuration system comprising: an enterprise configuration database stored and executed in the computing structure of the enterprise to store configuration data for components of each of the one or more plant sites using an additional configuration data schema; one or more local configuration systems stored at each of the one or more plant sites, each local configuration system comprising one or more local database configuration services for viewing or changing configurations of the components of the control or automation system at the plant site, a first local configuration system in the local configuration systems using the first configuration data schema, and a second local configuration system in the local configuration systems using the second configuration data schema; and a set of enterprise configuration database services stored in and executed in the computing structure, the set of enterprise configuration database services interacting between the enterprise configuration database and a local database configuration support service at each of the plant sites to enable each of the local database configuration support services to view and change the configuration data within the enterprise configuration database at the plant site where each of the local database configuration support services is located.

31. An enterprise configuration system according to claim 30, wherein the enterprise configuration system further comprises a configuration support viewing application, wherein the configuration support viewing application is executed on a computer device, wherein the configuration support viewing application accesses data from the enterprise configuration database via a connection to the enterprise configuration database through the computing structure, and wherein an enterprise configuration database support service in a set of enterprise configuration database support services interacts between the enterprise configuration database and the configuration support viewing application to enable the configuration support viewing application to view and change the configuration of the one or more local configuration systems at each of the one or more physical sites.

32. The enterprise configuration system of claim 30, wherein each of the local database configuration support services comprises a local configuration database that stores configuration data for the plant site where the local database configuration database is located.

33. An enterprise configuration system according to claim 30, wherein the enterprise configuration database service set includes a translation service set executed in the computing structure, wherein each translation service in the translation service set interacts between the enterprise configuration database and one of the local database configuration support services, and operates to translate configuration data between the first configuration data mode or one of the second configuration data modes used at the factory site and the additional configuration data mode used in the enterprise configuration database.

34. An enterprise configuration system according to claim 33, wherein one or more of the translation services include an interface layer that interacts with a factory site, a domain model layer that stores a data model associated with the additional configuration data schema, and a database abstraction layer that interacts with the enterprise configuration database to use the additional configuration data schema to store configuration data and read the configuration data from the enterprise configuration database.

35. An enterprise configuration system according to claim 34, wherein the enterprise configuration database includes multiple different database components using different database storage technologies, and wherein the abstraction layer for the first translation service supports the use of the first database storage technology, and the abstraction layer for the second translation service supports the use of a second database storage technology different from the first database storage technology.

36. The enterprise configuration system of claim 34, wherein the domain model layer translates between the additional configuration data schema associated with the data model and one of the first data schema and the second data schema associated with configuration data at one of the plant sites.

37. An enterprise configuration system according to claim 33, wherein the enterprise configuration system further includes a bridging device, which is arranged between the local database configuration service at a specific factory site and the translation service for the specific factory site, wherein the bridging device marshals the communication between the local database configuration service at the specific factory site and the enterprise configuration database.

38. The enterprise configuration system of claim 37, wherein the bridging device stores and implements security authorizations to enable communication between the local database configuration service at the particular plant site and the enterprise configuration database in the computing fabric.

39. The enterprise configuration system of claim 37, wherein the bridging device encapsulates configuration data in messages for transmission between the local database configuration service at the particular plant site and the enterprise configuration database in the computing fabric.

40. The enterprise configuration system of claim 37, wherein the bridging device utilizes a data model comprising a hierarchical data format, and wherein the bridging device develops messages comprising data from a plurality of different elements of the hierarchical format.

41. The enterprise configuration system of claim 40, wherein the bridging device automatically groups data from a plurality of different layers of the hierarchical format to create a data message.

42. The enterprise configuration system of claim 40, wherein the bridging device manages changes to an enterprise configuration database using change messages, the change messages comprising a plurality of changes to the configuration data in the enterprise configuration database.

43. An enterprise configuration system according to claim 30, wherein the configuration database service includes one or more services that manage changes to the enterprise configuration database by storing and implementing one or more rules associated with changes to the configuration database and by analyzing changes to configuration data within the enterprise configuration database using the one or more rules.

44. An enterprise configuration system according to claim 30, wherein the configuration database service includes one or more additional services that manage changes to the enterprise configuration database by automatically coordinating changes to the enterprise configuration database and implementing changes to one or more elements at a plant site associated with the changes to the enterprise configuration database.

45. An enterprise configuration system according to claim 30, wherein the configuration database service includes one or more additional services that track changes to the enterprise configuration database by automatically storing information about changes made to the enterprise configuration database, the information including one or more of the following: who made the configuration change, the time of the configuration change, the reason for the configuration change, and authorization for the configuration change.

46. ​​An enterprise configuration system according to claim 30, wherein the configuration database service includes one or more additional services that coordinate the implementation of changes to the enterprise configuration database or changes to the configuration of the elements at the plant site by coordinating the timing of multiple changes made to the enterprise configuration database or the elements at the plant site.

47. The enterprise configuration system of claim 30, wherein the enterprise configuration database uses a data model that stores and organizes configuration data by enterprise region, each enterprise region including one or more plant sites.

48. The enterprise configuration system of claim 30, wherein the enterprise configuration database uses a data model that stores and organizes configuration data by enterprise department, each enterprise department including one or more plant sites.

49. The enterprise configuration system of claim 30, wherein the enterprise configuration database uses a data model that stores and organizes configuration data of an enterprise having a plurality of plant sites by storing and managing configuration data of each of the plurality of plant sites.

50. An enterprise configuration system according to claim 30, wherein the first of the plant sites uses a first type of process control or automation system, and the second of the plant sites uses a second type of process control or automation system, wherein the second type of process control or automation system is different from the first type of process control or automation system.

51. An enterprise configuration system according to claim 30, wherein the first of the factory sites uses a process control or automation system manufactured by a first manufacturer, and the second of the factory sites uses a second process control or automation system manufactured by a second manufacturer different from the first manufacturer.

52. The enterprise configuration system of claim 30, further comprising one or more search services that perform a search of the enterprise configuration database to search for configuration elements based on provided search criteria.

53. The enterprise configuration system of claim 52, wherein the one or more search services search for configuration elements across a plurality of different physical sites.

54. An enterprise configuration system for viewing and changing the configuration of an enterprise system, the enterprise system having a computing structure communicatively connected to multiple city plant sites, each plant site having components of one or more different control or automation systems located therein, and the computing structure including computer devices implementing computer-implemented elements for the one or more plant sites, the configuration system comprising: an enterprise configuration database stored and executed in the computing structure of the enterprise to store configuration data for components of each of the one or more plant sites using a first configuration data schema, including storing configuration data for elements located at one of the plant sites for controlling or monitoring the one of the plant sites and storing configuration data for one or more elements located in the computing structure for controlling or monitoring the one of the plant sites; a configuration support viewing application executing on a computing device, the configuration support viewing application accessing data from the enterprise configuration database via a connection through the computing fabric to the enterprise configuration database; and a set of enterprise configuration database services stored in and executed in the computing structure, the set of enterprise configuration database services interacting between the enterprise configuration database and the configuration support viewing application to enable the configuration support viewing application to view and change configuration data of elements located at one of the plant sites for controlling or monitoring the one of the plant sites, and to view and change configuration data of the one or more elements located in the computing structure for controlling or monitoring the one of the plant sites.

55. The enterprise configuration system according to claim 54 further comprises one or more local configuration systems, the one or more local configuration systems being stored at each of the one or more plant sites, each local configuration system comprising one or more local database configuration services, the one or more local database configuration services being used to view or change the configuration of the components of the control or automation system at the plant site; and wherein the enterprise configuration database service set interacts between the enterprise configuration database and the local database configuration support service at each of the plant sites so that each of the local database configuration support services is able to view and change the configuration data of the plant site where each of the local database configuration support services is located.

56. An enterprise configuration system according to claim 55, wherein the enterprise configuration database service set includes a translation service set executed in the computing structure, wherein each translation service in the translation service set interacts between the enterprise configuration database and one of the local database configuration support services, and operates to translate configuration data between a first configuration data pattern used by the enterprise configuration database and another configuration data pattern used at one of the factory sites.

57. An enterprise configuration system according to claim 56, wherein one or more of the translation services include an interface layer that interacts with a factory site, a domain model layer that stores a data model associated with the first configuration data schema, and a database abstraction layer that interacts with the enterprise configuration database to store configuration data in the enterprise configuration database and read configuration data from the enterprise configuration database.

58. An enterprise configuration system according to claim 57, wherein the enterprise configuration database includes multiple different database components using different database storage technologies, and wherein the abstraction layer for the first translation service supports the use of the first database storage technology, and the abstraction layer for the second translation service supports the use of a second database storage technology different from the first database storage technology.

59. The enterprise configuration system according to claim 55 further includes a bridging device, which is arranged between the local database configuration service at a specific factory site and the translation service for the specific factory site, wherein the bridging device marshals the communication between the local database configuration service at the specific factory site and the enterprise configuration database.

60. The enterprise configuration system of claim 59, wherein the bridging device stores and implements security authorizations to enable communication between the local database configuration service at the particular plant site and the enterprise configuration database in the computing fabric.

61. The enterprise configuration system of claim 59, wherein the bridging device utilizes a data model comprising a hierarchical data format, and wherein the bridging device develops messages comprising data from a plurality of different elements of the hierarchical format.

62. The enterprise configuration system of claim 61, wherein the bridging device automatically groups the various different data from the plurality of different elements of the hierarchical format to create a data message.

63. The enterprise configuration system of claim 59, wherein the bridging device manages changes to an enterprise configuration database using change messages, the change messages comprising a plurality of changes to the configuration data in the enterprise configuration database.

64. An enterprise configuration system according to claim 54, wherein the configuration database service includes one or more additional services that manage changes to the enterprise configuration database by storing and implementing one or more rules associated with changes to the enterprise configuration database and analyzing changes to the enterprise configuration database using the one or more rules.

65. An enterprise configuration system according to claim 54, wherein the configuration database service includes one or more additional services that manage changes to the enterprise configuration database by automatically coordinating changes to the enterprise configuration database and implementing changes to one or more elements at a plant site associated with the changes to the enterprise configuration database.

66. An enterprise configuration system according to claim 54, wherein the configuration database service includes one or more additional services that track changes to the enterprise configuration database by automatically storing information about changes made to the enterprise configuration database, the information including one or more of the following: who made the configuration change, the time of the configuration change, the reason for the configuration change, and authorization for the configuration change.

67. An enterprise configuration system according to claim 54, wherein the configuration database service includes one or more services that coordinate the implementation of changes to the enterprise configuration database or changes to the configuration of the elements at the plant site by coordinating the timing of multiple configuration changes made to the enterprise configuration database or the elements at the plant site.

68. The enterprise configuration system of claim 54, wherein the enterprise configuration database uses a data model that stores and organizes configuration data by enterprise region, each enterprise region including one or more plant sites.

69. The enterprise configuration system of claim 54, wherein the enterprise configuration database uses a data model that stores and organizes configuration data by enterprise department, each enterprise department including one or more plant sites.

70. The enterprise configuration system of claim 54, wherein the enterprise configuration database uses a data model that stores and organizes configuration data of an enterprise having a plurality of plant sites by storing and managing configuration data for each of the plurality of plant sites.

71. An enterprise configuration system according to claim 54, wherein the first of the plant sites uses a first type of process control or automation system, and the second of the plant sites uses a second type of process control or automation system, wherein the second type of process control or automation system is different from the first type of process control or automation system.

72. The enterprise configuration system of claim 54, further comprising one or more search services that perform a search of the enterprise configuration database to search for configuration elements based on provided search criteria.

73. The enterprise configuration system of claim 72, wherein the one or more search services search for configuration elements across a plurality of different physical sites.

74. An enterprise configuration system for viewing and changing the configuration of an enterprise system, the enterprise system having a computing structure communicatively connected to one or more plant sites, each plant site having one or more control or automation system components located therein, and the computing structure including computer devices implementing computer-implemented elements for the one or more plant sites, the configuration system comprising: an enterprise configuration database stored and executed in the computing structure of the enterprise to store configuration data for components of each of the one or more plant sites; a configuration support viewing application executing on a computing device, the configuration support viewing application accessing data from the enterprise configuration database via a connection through the computing fabric to the enterprise configuration database; one or more local configuration systems, the one or more local configuration systems stored at each of the one or more plant sites, each local configuration system comprising one or more local database configuration services for viewing or changing configurations of the components of the control or automation system at the plant site; and A set of enterprise configuration database services, each of which includes an interface layer for interacting with the configuration viewing support application or plant site, a domain model layer for storing a data model associated with a first configuration data schema, and a database abstraction layer for interacting with the enterprise configuration database to store and read configuration data.

75. An enterprise configuration system according to claim 74, wherein the enterprise configuration database includes multiple different database components using different database storage technologies, and wherein the abstraction layer for a first configuration database service supports the use of a first database storage technology, and the abstraction layer for a second enterprise configuration database service supports the use of a second database storage technology different from the first database storage technology.

76. The enterprise configuration system of claim 74, wherein the domain model layer translates between the first configuration data schema associated with the data model and a second configuration data schema associated with the configuration support viewing application or one of the plant sites.

77. The enterprise configuration system of claim 76, wherein the communication layer interacts with the configuration view application using another data and messaging schema of the configuration view application or one of the plant sites.

78. An enterprise configuration system according to claim 77, wherein the communication layer extracts configuration data sets and actions from messages from a configuration support viewing application or from the factory site using the additional configuration data schema of the configuration viewing application or the factory site, and creates one or more messages to the configuration support viewing application or the factory site by creating messages including configuration data using the additional configuration data schema of the configuration support viewing application or the factory site.

79. The enterprise configuration system of claim 74, further comprising one or more search services that perform a search of the enterprise configuration database to search for configuration elements based on provided search criteria.

80. The enterprise configuration system of claim 74, wherein the one or more search services search for configuration elements across a plurality of different physical sites.

81. An enterprise configuration system for viewing and changing the configuration of an enterprise system, the enterprise system having a computing structure communicatively connected to one or more plant sites, each plant site having one or more control or automation system components located therein, and the computing structure including computer devices implementing computer-implemented elements for the one or more plant sites, the configuration system comprising: an enterprise configuration database stored and executed in the computing structure of the enterprise to store configuration data for components of each of the one or more plant sites, wherein the enterprise configuration database organizes the configuration data stored in the enterprise configuration database by defining the plant site to which particular configuration data belongs; a configuration support viewing application executing on a computer device, the configuration support viewing application accessing data from the enterprise configuration database for each of the different plant sites via a connection through the computing fabric to the enterprise configuration database; and A set of enterprise configuration database services stored in and executed in the computing structure, the set of enterprise configuration database services interacting between the enterprise configuration database and the configuration support viewing application, and between the enterprise configuration database and local database configuration support services at each of the plant sites.

82. The enterprise configuration system of claim 81, wherein the enterprise configuration database organizes the configuration data stored in the enterprise configuration database based on one or more regions to which each plant site belongs.

83. The enterprise configuration system of claim 81, wherein the enterprise configuration database organizes the configuration data stored in the enterprise configuration database based on one or more departments of the enterprise to which each plant site belongs.

84. An enterprise configuration system according to claim 83, wherein each of the one or more departments of the enterprise includes one or more regions of the enterprise, and wherein each region of the enterprise includes one or more factory sites of the enterprise.

85. The enterprise configuration system of claim 81, further comprising one or more search services that perform a search of the enterprise configuration database to search for configuration elements based on provided search criteria.

86. The enterprise configuration system of claim 81, wherein the one or more search services search for configuration elements across a plurality of different physical sites.

Images